From xen-devel-bounces@lists.xenproject.org Sun Jun 01 16:33:18 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 01 Jun 2025 16:33:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1002582.1382148 (Exim 4.92) (envelope-from ) id 1uLlcG-0001VF-KF; Sun, 01 Jun 2025 16:32:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1002582.1382148; Sun, 01 Jun 2025 16:32: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 1uLlcG-0001Ux-FO; Sun, 01 Jun 2025 16:32:56 +0000 Received: by outflank-mailman (input) for mailman id 1002582; Sun, 01 Jun 2025 16:32: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 1uLlcF-0001Uq-Tk for xen-devel@lists.xenproject.org; Sun, 01 Jun 2025 16:32:55 +0000 Received: from rein-hpcbdc09 (unknown [1.7.42.26]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 0f4ee3b5-3f06-11f0-a300-13f23c93f187; Sun, 01 Jun 2025 18:32:53 +0200 (CEST) Received: by rein-hpcbdc09 (Postfix, from userid 1000) id 5852280C03EA; Sun, 1 Jun 2025 22:02:48 +0530 (IST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0f4ee3b5-3f06-11f0-a300-13f23c93f187 From: Jahan Murudi To: xen-devel@lists.xenproject.org Cc: Jahan Murudi , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v2] arm/vgic-v2: Fix undefined behavior in vgic_fetch_itargetsr() Date: Sun, 1 Jun 2025 22:02:12 +0530 Message-Id: <20250601163212.2988162-1-jahan.murudi.zg@renesas.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The current implementation performs left shift operations that may trigger undefined behavior when the target value is too large. This patch: 1. Changes the shift from signed (1) to unsigned (1U) to ensure well-defined behavior for all valid target values 2. Maintains identical functionality while fixing the UBSAN warning The issue was detected by UBSAN: (XEN) UBSAN: Undefined behaviour in arch/arm/vgic-v2.c:73:56 (XEN) left shift of 128 by 24 places cannot be represented in type 'int' (XEN) Xen WARN at common/ubsan/ubsan.c:174 Signed-off-by: Jahan Murudi --- Changed since v1: * Added space after subject line --- xen/arch/arm/vgic-v2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c index a19d610178..642407fd5b 100644 --- a/xen/arch/arm/vgic-v2.c +++ b/xen/arch/arm/vgic-v2.c @@ -70,7 +70,7 @@ static uint32_t vgic_fetch_itargetsr(struct vgic_irq_rank *rank, offset &= ~(NR_TARGETS_PER_ITARGETSR - 1); for ( i = 0; i < NR_TARGETS_PER_ITARGETSR; i++, offset++ ) - reg |= (1 << read_atomic(&rank->vcpu[offset])) << (i * NR_BITS_PER_TARGET); + reg |= (1U << read_atomic(&rank->vcpu[offset])) << (i * NR_BITS_PER_TARGET); return reg; } -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 02 06:49:50 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 06:49:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1002771.1382158 (Exim 4.92) (envelope-from ) id 1uLyzI-0004oJ-Mz; Mon, 02 Jun 2025 06:49:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1002771.1382158; Mon, 02 Jun 2025 06: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 1uLyzI-0004oA-I3; Mon, 02 Jun 2025 06:49:36 +0000 Received: by outflank-mailman (input) for mailman id 1002771; Mon, 02 Jun 2025 06:49: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 1uLyzG-0004o4-Cx for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 06:49:34 +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 bce224de-3f7d-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 08:49:32 +0200 (CEST) Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-3a361b8a66cso2337907f8f.2 for ; Sun, 01 Jun 2025 23:49:32 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-747afed4c0dsm6920862b3a.78.2025.06.01.23.49.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 01 Jun 2025 23:49:31 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: bce224de-3f7d-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1748846972; x=1749451772; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=m2RxsPqHpa5wh8pm65f/H2m2AcFGOITAGjFZl22tFVQ=; b=L3b1hVxjSV9rGsP7dI9hWcCjTzEN2tIF9F0TEnooP5fT4nhNb2BFJPVTDVQuappTO2 0QON+ib+ZEj/Z9YOLChqIDtol8oj0GX3g5w49r+mxhzrRZRtBF2x1TuN3b0D9N0Ks+T5 pXNBEb3Jh5UUBBHRgJJzEwaK//IhWuebHdTwNq0OpRTI6lHHjRTJu+bcKOAm0wfdp816 nMTxEQ0aIil3B07/5HoTXA7Ic9Z/6lITY+ZAAjqZDBJx5L0s4RPQBwfCQPCiKVXV0Nk5 OdjwZ3ByU2mnAmGTjgyRHgH+anvCo5U+VZbnbQo7lZSi/xgvYEMjAEQoaZP9fpYd1Uw6 6GXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748846972; x=1749451772; 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=m2RxsPqHpa5wh8pm65f/H2m2AcFGOITAGjFZl22tFVQ=; b=YSX78gcs9+49g1pddfq0mOyeoZ5ppHbnV36I/EaXvysLMKSP2LFVRR6n0OlIDYdyrp 9f+JCqB9AulODX9UNY9cFhQjE3/keJcBCpzxqITtdZSblZi6SHxnvVZv2JfYBSS9mSMR Hbezh2ozRnYBAPLAl3LtXKltUpb054Xc2x0LN/qOojTTzTpgC3NpU7b5NyyH9pQDnH/y sQUDimhGaEhQ2JN18oZ2D/hayiMrVQtr2FV0ZhOruYtehUEfSmC2WXZDXwSR9zgkoaBm e4P1Dmvqj9RtKGeddl5LqSJXKwQAQc45M0VDB/S9JzRtrCvfGJe80bTh+4avfdSouIb0 NJjA== X-Forwarded-Encrypted: i=1; AJvYcCUORgIPDKMv3n5FWT6SeTbhvF/IEZeHpBXiGiXTsFvCYYFA1xhhCPfOPzZu1JQGVlrmudg0QVol1+s=@lists.xenproject.org X-Gm-Message-State: AOJu0YydhoTkRTCGTdIZnWbNB+v2r+hwDiMx9C4MhsXRedqBqAb8fgrw LAe2IFrbI5IEiUcabHZNF8v6NsTVBY4mAORMvlHlvTvTq6DsDeyUOvYBX59/q/Gl8Q== X-Gm-Gg: ASbGncsFM7dMDL2+Jtb6ycbYEno3mBWEkC3Ux7kOHn7kYUIMpRFhCQAjFvf7miqzfsy QFfbNjKnl+q+2nKwUgvmSXcvkw6h33gECX4f2uxxA4HTuq8TgCpA2YLIpTaeoDNUiseXDU64VXl UgFg3vdTsX7vINweR9rBPTlyszhla4vQhbjSzbpW3vqvT8b5QnSV5Wn91hfO5GqW9+vy7HRhakO oTj0qh6t7JgFqqb2Y05uIaiE7pAJXe/hmamTIkOGfGCof+hOdPYv7zZ18DYw6WrvMhmI4l6C0oJ G4XCMZxoAes0pKVXqzEKG4m0lAfutdngnLvGsG6e6LC9OI2BJgYXBpN0Ve8HBo+ULYgSrk0xJV/ IQTrzxiyGrBtPDNiMLhkL3Za/cLjJkOTV/L5f X-Google-Smtp-Source: AGHT+IGrT2DIP96VTQfFcdTuFxnn7mT9xAQmQ2RhxvdFjYHVaTvbPjBFmlurqNHaEL6hv2qip9DBgg== X-Received: by 2002:a05:6000:178b:b0:3a3:6415:96c8 with SMTP id ffacd0b85a97d-3a4fe398e60mr4990761f8f.41.1748846971610; Sun, 01 Jun 2025 23:49:31 -0700 (PDT) Message-ID: <968ed926-41cb-4ba2-a312-a11e0a812e72@suse.com> Date: Mon, 2 Jun 2025 08:49:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v10 6/7] xen/arm: enable dom0 to use PCI devices with pci-passthrough=no To: Mykyta Poturai Cc: Stewart Hildebrand , 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: 7bit On 27.05.2025 10:14, Mykyta Poturai wrote: > On 29.04.25 15:20, Jan Beulich wrote: >> On 29.04.2025 13:52, Mykyta Poturai wrote: >> I further notice that you didn't adjust the "reset" sub-op handling, despite >> my earlier hint in that direction. Looking at the commit message, you only >> mention PHYSDEVOP_pci_device_add anyway. I think all three need mentioning >> there, which would then (hopefully) clarify what the deal is with >> PHYSDEVOP_pci_device_reset. >> >> Jan > > PHYSDEVOP_pci_device_reset doesn't check if PCI passthrough is enabled > or not, And you're convinced this is correct this way? Jan > so there is no reason to add special clauses. I will add this to > the commit message to be clear. > From xen-devel-bounces@lists.xenproject.org Mon Jun 02 06:54:21 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 06:54:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1002776.1382168 (Exim 4.92) (envelope-from ) id 1uLz3s-0006H7-4T; Mon, 02 Jun 2025 06:54:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1002776.1382168; Mon, 02 Jun 2025 06:54:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uLz3s-0006H0-1j; Mon, 02 Jun 2025 06:54:20 +0000 Received: by outflank-mailman (input) for mailman id 1002776; Mon, 02 Jun 2025 06:54:19 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uLz3r-0006Gs-8E for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 06:54:19 +0000 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on20626.outbound.protection.outlook.com [2a01:111:f403:2416::626]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 66443776-3f7e-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 08:54:16 +0200 (CEST) Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22) by MN0PR12MB5713.namprd12.prod.outlook.com (2603:10b6:208:370::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.30; Mon, 2 Jun 2025 06:54:11 +0000 Received: from BN9PR12MB5273.namprd12.prod.outlook.com ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8769.037; Mon, 2 Jun 2025 06:54: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: 66443776-3f7e-11f0-b894-0df219b8e170 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=W9xFAWaBzy0hhzVacfDY9G1vxWyDLALYxTznFaSYOrVNba+jpUq347cwlUEiIvw+8iQT3nO7mCy/NEM999MBVygidQdkKFuuK5KXyCGrx5VUOsEEDcg94x+4kKaiU0xjLXm1LCzvKuBg78lNNsDP88u+wklM+aC860WeaH722LZ/TqiA4YriYAqCYTVztN5hBNRTN+PHFGsqSge33Hy79OPBg1K78ODEo2SPi9BifVRM1atIDxadKrDf75fAjOCZzmPKRdwfUBjelvNBcBBYkXlMRBT2CMVcSRBzfV/Q7FWN+0/YeAUxK4cCi4PCy0VTxLC5JzWPGDTwuQuI9RFKUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=xBAgPyn6HzTm/4YpoVVOEcj5/JuxWsqz64rHlPDUomY=; b=DSh/upPBQj6iF94N5u1hzRmn2+bh0A8wktKb/QW9HV7/2VBVyz7dQl0QRCe9vECq60UZtlDYFmGWEQ4QTBeNW1f7vdGObmno4E+W5oSGN8BProfkwzcK64SZTR8nxIVwbpH6H4vw7d+OTDsNC7TRmC37oJDxAcPuhEwie0lKG88bJP3Ty6W+jwgQTsC/VKhOqZoLI+fwBTT8+V7eFLtCD1zOx0kr3Eo86jX4H1vD6XVJPi5TaCPvScfFxs7jdWRlIEgv8odqvHEGElotVCdZqzenPpZqT+caP6oOzebYrw2TL5y8hHHpWiEovZF+op2tpUuDLEzWBe6V7kmmjJL1dQ== 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=xBAgPyn6HzTm/4YpoVVOEcj5/JuxWsqz64rHlPDUomY=; b=T3sKPwr0/SY5bV6IlorGmqlZi/gs2es1FIHLVNVENzNwiT0gWPgOa9cYEeTdtJEJjbr2qffHNEIygMcPYgz/syBMQgZXz0KCp96I35VBU3wp/N0yu3TPgaCTRuPhPLuNZOxDRDXWAAsC2bXOcIx02zBYtaCx4aev/DMz4jG0Zaw= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Message-ID: <01c5ad19-2add-4270-948d-ecdf3d5e8bd6@amd.com> Date: Mon, 2 Jun 2025 08:54:06 +0200 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] arm/vgic-v2: Fix undefined behavior in vgic_fetch_itargetsr() To: Jahan Murudi , xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk References: <20250601163212.2988162-1-jahan.murudi.zg@renesas.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20250601163212.2988162-1-jahan.murudi.zg@renesas.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: FR4P281CA0012.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:c8::20) To BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|MN0PR12MB5713:EE_ X-MS-Office365-Filtering-Correlation-Id: 1017dfd2-48b6-42e8-b07c-08dda1a2464e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?TzFHNFhNMmlySVA5UU1ZaXpqUWpuQzArci9mVUVPMmtzQVhMMGJZNmNnSTVQ?= =?utf-8?B?a295UFV0bGY1NEczUDdvUC81MGxjVWtBcldRWFk5b2YyZFlSd0JPWUJ3L0lC?= =?utf-8?B?Zm9hRWg4dENTY3A0SktINkFhc2w3dFI2QmhieEFxNDJGMFRSZjB1TFFYMkJn?= =?utf-8?B?bllxM2M5Z1RFajdyVmphanl6SGhGM2pLaDdWRGpSQmVDc0N2ekVVSWJpdWhS?= =?utf-8?B?TEplU1ZRK1laWWx1MC93RWFUWHdCWk8rODRVYWU0QlFIcEsrUHlNSDNhejVR?= =?utf-8?B?eXJWMGx4MndoVjdHMjRxZ2NzUGtyeEZKZkR0Rng4U1g3dkRpV0RtUWtyRnlQ?= =?utf-8?B?ZkRTTWZFZjUrc3VXYUR6SGNGenJEcDkvZ1Uzc2YwejJMYXg3eHQ5NUFWZjZr?= =?utf-8?B?ZHpLWUdMWXJTeWNZSVI2cUlqaDR5WG01ZHgrL1ZOaHA2a2JyWVU2OCtoSVdj?= =?utf-8?B?RkpuZnBmaXF0eWlPckx0VnNsdlV6TnRBcStWTk9NWDRONWZsYVVJNENTSnl2?= =?utf-8?B?SlRkaW12Ymo1cGRaLzNaQ2JhdWg4QTJFdGxIc3NXWGFBZkU2MUswVkFKcUpE?= =?utf-8?B?WTNEeFhxWXBTRGZRUFB1SXlNMEtFQ2hiT3FQYVNTSnYzalZFWDBmTC9qUjhY?= =?utf-8?B?NGptejRvSCtPSlFFbVo5SU9IRlo0QTlyL05NVUNVYWU2VTVRLzZsTS9qOUJ3?= =?utf-8?B?a1B3NlB1aHllSTNPWVJFTEZKeUV3Yy9DbzBVSmlPa05oeTNEUzNYTFlqWVlz?= =?utf-8?B?bnNlMlpZbFFIem0yS2l2cVhNU3VodCtSMksxN3gzS2RMNVJVZnFFL3BWb3pD?= =?utf-8?B?d2lTYVcvU0U1NEhhSUgrZnZaOFRXWi8xQS9BSmxxcmtuQTlEVGpieXpPYXZM?= =?utf-8?B?ZEFKc3dKclVvanE0WE1HV0dTWDhmZFBKRHBOdENaYU53ZFJvY0pZQ0JCZFYy?= =?utf-8?B?VURsZmFxK0tZRy9lS0ZzK2QraXhkdFBNc2hoeTJOTUU1aTFzNloxMjEvM2dn?= =?utf-8?B?b3RERjFkYnNiemxFSDl6RHNqaVI3VGZuNk00NERRRDNjeTd1YldsRkFQZU1F?= =?utf-8?B?MmdRaUVldnJIVUpRSDF5bno3SDI1OCtnOWV5NjJ0Qm5DSHgrY1Y3MW5LQkx4?= =?utf-8?B?d0NDTmsyMmNDT2ozQzRrQjRadlE3V2JMQkRrRS9HLy9FUjhRWkhhM2VYNGJI?= =?utf-8?B?b0pUVXBwRXVIKzhWZGZTbkJwKzRJZ05wZ3VUUEYycDdKNFNzYkp5MU00MHBU?= =?utf-8?B?L0pWa091SGJKQVhTbGtuelZNS1B4WGxLTnBmOTM0S2dhWG5ibHQ5UFpRTmk4?= =?utf-8?B?cEIyQisvTzZXN0MwK3ZhMTUwWlErUENpamhyOWRRdStsUUdtQVdBZ1MzUExm?= =?utf-8?B?RW5WbXM2VW4wbjJ3aWtPMlM1UWV5NUt6Wk1vUklBOW5ram4zNVJRMjNPaXF5?= =?utf-8?B?TGtnRWovUlhZMy9na2N3OTNpcFpDT0VXSyszSVZXTm02NzR5ZDZDWGsxOWtk?= =?utf-8?B?dUgydFo1TXNkTzlEREpzb280d0xnOWVQdmdoNmNJQzJtVmVweWFEb0liMzZn?= =?utf-8?B?R1NHbnN3cjExV2xRSEg2SjFZc05HR25nOXlDZXFja3JCWFFDR2RGRzVEZGJz?= =?utf-8?B?bDJ5N3NRT1VaMWY0VkMxbVZRU1BxdEtNamhKWllLUnZlbUFjK1NHTlBOenJ4?= =?utf-8?B?WU5jY2JlWmlxWDFiVnNNWU1lWGpUaEdGTGlHRDgwZFVFall6Rmw5MTdEU0M0?= =?utf-8?B?YmdrREVSU3liVy9rTjNQOVN1L1AreXg5TjJnY3FiZHpGQi9DTE1xM2Q5NW5r?= =?utf-8?B?eE1NWHFwdEF0OEdaZ1RqbEZMdzh1NUsrcmg0L1lsalN2bElaSll3enpXTi8z?= =?utf-8?B?TmJ0bUpFU1JkN2FnakZUV2VQcXpCZU9RdEVORGxmVnF3ZHplMmhVa1RpVU5B?= =?utf-8?Q?T8yweKOEDWI=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?S09iT2NCMWRkVEY3bTlCWHZsemo5N1J6YTc2TURnSTdXbE9OZ2k3eHR0cEVI?= =?utf-8?B?VW9HK2xlZWhIeW9VdTJqTGNTaU5RNHgzaGFhT0I1TmpWNzF0aytEaHJXdi9J?= =?utf-8?B?YjRMYjV5dW4vNStuRUUyTzlMb1V5NmpHNWxDZTNheExyZUdHY0wyRmF1U01K?= =?utf-8?B?OGxZWUw5V0QvK3J3Y3VuRUlpaWhLWFZJL2JubTBNUm5ROE1WSjQrbTZrQy9F?= =?utf-8?B?OVBaOEd5UGtpUDFZRC9EVjgxN3FUNlZqRGxQVHoxaDBVUU1DVHBtTjk4UU5z?= =?utf-8?B?aElMejFPVjBuVWM5N29uMDI3ZUduSS9tQ3VKOUZKUDNIZkptQ0hyM3BpZTdF?= =?utf-8?B?NHVjODVLdUZsb2pkcGNudzBNeThNbjRLQmtXNWRqMTRLKzdJTW9PZEx6alMz?= =?utf-8?B?MEFXUFovNHVWbXJtS00yR3NvZ2srRm9hWWpMWXovWjFaSmNYNlExWDJpK21s?= =?utf-8?B?ZTdZRzYrWW9RUXZqMnh6Ym5jQ2d3YTc1ZUI1VEh5U0huT0I3Y2dlbFFqQ2lN?= =?utf-8?B?RHZJMlE4NzBFZlVRdW55RnhoSHIrelZ3cDZDU3pzVVhwUktQVDlac0wyb3VH?= =?utf-8?B?VUZWQi9sWjJEc1Bhb09odEFPanhGZDNyb3ZJcVdvV3RBWStqUndzUThMVTJi?= =?utf-8?B?eDVDVHZmVEw2OFppbmJJbjhOWTBTQk1xamZqS0JKU3ArdW4ycDZUVmtlaTlp?= =?utf-8?B?cTdXNHRSRUpkTnh2TkwwWUllMjZSNHdwcmZlL0tFdVhKRmdTcEpFWjNYMmJU?= =?utf-8?B?emNiNGZHS2hWSEFRMHVSMHovNTF2bkVTdmRjT3NCMGJ5WEluSXQvdDFia2tt?= =?utf-8?B?RmdiU2llSFgySW5CWk1NUEMrQWozRlpZNldJK3EwLzJRbUh1cDJwTXpqcUVY?= =?utf-8?B?TUhJUmFXN0wrSGF0eHl1TkFPcE1qWnlwdlN6RkpkLzZrRTE3VHhiS3VJdzd3?= =?utf-8?B?NXFTejh4U3dsUUN3V0FuLzNUY3cwakZndnFFSUNZYWVMNFdxSjJXNFdkYmpw?= =?utf-8?B?czY1UDZyOGYxZG1LUnNDZlRwcW00TmxEOFlMNE9wTjI5bDYvenZscklsUjRv?= =?utf-8?B?SkNYNE45R0JMcGZ1WklHaHZxazByK2FsL2lUTm1OYlhjV0x0L1R2TTR2dDh1?= =?utf-8?B?UUVVMEVVVWZpUklCaHV2MkNpbnc5V1E3U1lnK2RHR25uaVBVcnh3WFZUK1Ux?= =?utf-8?B?T043dU8vNTJnZTQremNsQmJ6SFdhNTlrQ3FsejU5VlR0bmNwK3hGYlAzbXMr?= =?utf-8?B?MkZ4QkgzZ0Rxb3hTRnlkVFpveFYvL3FmTEZtejNYMDZCZVd4ZlMrQlRCbEVz?= =?utf-8?B?eU1DR20yNTMrM1BNQWR1Mmt6K3J5UXl3R2xvTTdXUzR5WWhJYVplRExVRS9Z?= =?utf-8?B?UWV4VWZNOGt1VTA4blpPTmhzaGZBODBodm9tM292NGwzLzhPUmswNFFvZG9P?= =?utf-8?B?cmIxNnhMaGxwQUZyT1lCZ0pBZnExUHZMZ01IUVc5V01XRzN4NXFtbERDNm5W?= =?utf-8?B?ZzA2cTN0bThLc2dZWjFYY0NmWU9RdVdQdFFnR25UMTNIUTgzSTdCcDlwQUpw?= =?utf-8?B?ZWE2ZHl3NmM3bVczMGllUy9xOUJ6VEg0WitwcW93T2Z1N1Q4ZHdvbmJMd3pG?= =?utf-8?B?SlNsZk1NcnFYMDhkL0VxcktpaDE5U0JTRldPd2NmMGZSaEgrZit0Tjc5YUIw?= =?utf-8?B?TWRiVFowLzV0aksxUGM2aE1tSGNQaXcyQ0s4aDgyZlI3RkNCS1Z6ZUoxemw0?= =?utf-8?B?bkVRWkd0bWd1K2lsQXNLRXZ2WVZKQkg5OGIxeEJuVFlBbXNUblN0NmNiTzFs?= =?utf-8?B?U0xwdUJ2Rm1kUmJ1WGxuQnRLM25TYUpmR1kvVHA4Z3dTMUpOaEZySUc0OVE5?= =?utf-8?B?aFJjWHo0QzYxaytuKzZIOVJza3Z0VVdwcW5EeGhtRWZTaXRtQ0U1aTBReGJj?= =?utf-8?B?NkRyQzl4VzFCQnd4YW1UajJ3NC9PaUFZa3NjR1JMZ1hIZjRhejYzbXBYRnJM?= =?utf-8?B?WlRNVnQ2dzBySzVYZ1h1RTc1ZFl1ODBMZ05YRkJvdVpnNWlsRlFCbGJsVXZX?= =?utf-8?B?c29LUmVKRnZiczZmNUNkZlg2Z1luNDhtY3d5STVoc2dVcGNFNEhieGlqV0NS?= =?utf-8?Q?SA4s=3D?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1017dfd2-48b6-42e8-b07c-08dda1a2464e X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jun 2025 06:54:10.1245 (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: 3N1yREqgUYzZobNh8Q9e58SmLDMWnaqgeqt9E0SgrMq8hF5IoPKGd0t1vLNIPkYr X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB5713 On 01/06/2025 18:32, Jahan Murudi wrote: > The current implementation performs left shift operations that may trigger > undefined behavior when the target value is too large. This patch: > > 1. Changes the shift from signed (1) to unsigned (1U) to ensure well-defined NIT for the future: Use imperative mood > behavior for all valid target values > 2. Maintains identical functionality while fixing the UBSAN warning > > The issue was detected by UBSAN: > (XEN) UBSAN: Undefined behaviour in arch/arm/vgic-v2.c:73:56 > (XEN) left shift of 128 by 24 places cannot be represented in type 'int' > (XEN) Xen WARN at common/ubsan/ubsan.c:174 > > Signed-off-by: Jahan Murudi Reviewed-by: Michal Orzel ~Michal > > --- > Changed since v1: > * Added space after subject line > --- > xen/arch/arm/vgic-v2.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c > index a19d610178..642407fd5b 100644 > --- a/xen/arch/arm/vgic-v2.c > +++ b/xen/arch/arm/vgic-v2.c > @@ -70,7 +70,7 @@ static uint32_t vgic_fetch_itargetsr(struct vgic_irq_rank *rank, > offset &= ~(NR_TARGETS_PER_ITARGETSR - 1); > > for ( i = 0; i < NR_TARGETS_PER_ITARGETSR; i++, offset++ ) > - reg |= (1 << read_atomic(&rank->vcpu[offset])) << (i * NR_BITS_PER_TARGET); > + reg |= (1U << read_atomic(&rank->vcpu[offset])) << (i * NR_BITS_PER_TARGET); > > return reg; > } From xen-devel-bounces@lists.xenproject.org Mon Jun 02 07:10:57 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 07:10:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1002790.1382178 (Exim 4.92) (envelope-from ) id 1uLzJq-0000cg-J2; Mon, 02 Jun 2025 07:10:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1002790.1382178; Mon, 02 Jun 2025 07:10: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 1uLzJq-0000cZ-F8; Mon, 02 Jun 2025 07:10:50 +0000 Received: by outflank-mailman (input) for mailman id 1002790; Mon, 02 Jun 2025 07:10: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 1uLzJo-0000cT-RZ for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 07:10:48 +0000 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2061f.outbound.protection.outlook.com [2a01:111:f403:2412::61f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b3b966b5-3f80-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 09:10:46 +0200 (CEST) Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22) by SJ0PR12MB8115.namprd12.prod.outlook.com (2603:10b6:a03:4e3::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.34; Mon, 2 Jun 2025 07:10:42 +0000 Received: from BN9PR12MB5273.namprd12.prod.outlook.com ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8769.037; Mon, 2 Jun 2025 07:10: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: b3b966b5-3f80-11f0-a300-13f23c93f187 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=pny9ONUV1SxPtKl8TXN4Yeu6C7MzlLxeeqCiMA+eSAa43JRf81904CTV/SsFNcDXc3FQ5eboCyXEJJAZOUYNZWw/f/2TFiGEODU/CT476/Xbr1mxITehvxfCGJjpByjdN/4DVkLCwbXDZyRKo0oGafg5D/BAPB75rF7a3Pz7yQyMn//VeDUB74CkrOJxdMiFfyS59wOvZcuUWxPC7xpl/QBhiD3gs3PzwNYncu3fiRL/cmbwgCGE+Vs+aXi8zfs5/Evm5ro9STBR/bMuZdoTgOMluUAuyWPszsxwvAuq5LFUiF6sTNOd/VljFMAMkbICn4+MvAFwfMGIovOYLrggSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hyUNW9kSP/98q59S4vT6keD2i0uxNIIX6C152C3yvdE=; b=irAOPO9K12cm2yxT1gDal/Byx448vDDVVGTaDSF5X8B7K8ojAhvE1qOYAsBGc/bNgKkBfUvgVUxAYgFogvcGswA+R1yHML6u+hd+EqTmV1024ZBZ+Dk5FZK88QDA5CdMhof1eDpwNAGPvRfrXYcRjLw4XKN6jmDtTf1IG8mRSLKj3Hl0P6kX5iq32lp6z8dcJ/ggjkxNQLx7XzjQSlky6iJkYXSU7QT2wCnDaUiCm661qF98aFvEb6bNsPSU5GSL2oF69Amddfp9R2V9IVck6yJHPtShFrzFuRddvI+VUQnI6N4uMEn9KMl3A9s6J8a9K1CpjaAeXBY+vMMLwDn2jQ== 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=hyUNW9kSP/98q59S4vT6keD2i0uxNIIX6C152C3yvdE=; b=OoZ0a/p1sCyuLQ75m7vWJrq/Tv2ZsgJGCNwUQmFieBShLNeilXUbX2NCWrxiNVDCXN3f61laLfcCZo0DtILA7DFB64PvLicVn+SUJYtOdNHcE/Ap96REV6S78eOf4ZBP92TxpRF/eI/WD+9huXCxjNv1rJW4KHSzqF+2mOndYX8= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Message-ID: <26d614da-3fb4-4209-8123-096512911897@amd.com> Date: Mon, 2 Jun 2025 09:10:37 +0200 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/arm64: head: document missing input registers for MMU functions To: Mykola Kvach , xen-devel@lists.xenproject.org Cc: Mykola Kvach , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk References: <9b1f50a40e3634f859ad8e7446c24e43caaa38eb.1748637004.git.mykola_kvach@epam.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <9b1f50a40e3634f859ad8e7446c24e43caaa38eb.1748637004.git.mykola_kvach@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: GVX0EPF0001A04D.SWEP280.PROD.OUTLOOK.COM (2603:10a6:158:401::49a) To BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|SJ0PR12MB8115:EE_ X-MS-Office365-Filtering-Correlation-Id: 048e4f34-aab2-42b6-eabf-08dda1a49636 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?Wm5oWmttYi9DTjkrRXZHZFBrKzZpaEZ6ZVRZN2NES1pxdGtlY3dmczhGOHFr?= =?utf-8?B?U2xrN21RVjJwZDV5dnM3SzZ6NFF5ZHUxakxqbWJkZ2lwemJmdWFyZ0VQcGlN?= =?utf-8?B?V1c3cWk0Q0xFOVNSQkJVSWhCaEVvU0dsMlBuOXpTQmNSTXhVaWdXS1lObmVJ?= =?utf-8?B?RTh0KzNnNjd1c1RtbEc5b1VPNUpJNVA4VVJCMklKOXVKUlRXQUZjQkNsRHZQ?= =?utf-8?B?cFhvZ1o2cndLNnM1a0dNV2l2d255ZXlrNzMraDV5WXBSOVcvZ3VuTUxBeFFo?= =?utf-8?B?YnJORG9rRzlZUU1EcFpJTGdTMzFQVUNqQU1FV1JXQ0Urckc3Um5xMTVJVFp4?= =?utf-8?B?QjF1WDlhdkY3OE1mUzNYYVNHTlRWWG45WDVrTmVQSVgrMkJLSDQrNFBKYmZv?= =?utf-8?B?eURneXBQc1VyRmxiSXJ6TC8xZ0dvdFJTSzBmODR5YVdWWVdoTXZLZ2RoTG1P?= =?utf-8?B?djd6eVNKR0xwRGZPR0JNU09neDA0ZDRxRlFDdTZaM1JNT3N4Zk1CS0xUSmNa?= =?utf-8?B?bU1GV2M2QnljV1cyUFVyUGY0Z3daOFJZMXZJWVNHTGNXb1BvSG1DQmNhUlBi?= =?utf-8?B?dlVHQzlRMWxpZzdvbHV6dVl1d3pqdlBhMVZ6eVFUOFhnRDBqY0FoV1dWZmMy?= =?utf-8?B?QWUwUldYTmtIUktPQkR2aElwaXlNU1Y5cjUrNG12NC9Qa2pIa1BoczhRajJM?= =?utf-8?B?ejJBbkVXdi9pRTYycHhTRHRBLzZoUnpjM2VwWjd6UXV6TVFqMWZPNnIxU29a?= =?utf-8?B?dnZwNGlXNE9oMXhqMmVtc3BFdXE4U0Fsc280dXdtdUtGQmxCRFU2ZlY2ODh6?= =?utf-8?B?YVlhYkJXSHIvSXh5RC9Ra2ROd2RBaTNFWjd2bzg3UGlSenRBclcxUVg0b1lZ?= =?utf-8?B?blJMWVptZS9WNWNMOS91L2t2R2R0d1ZodXdscXdZWGMxV2diR0xwbG5zbW84?= =?utf-8?B?d2gwaWZWYTh0VXB5U2NNZkhOSTVuK3JKQzd6Vk1xcm4xOGdyQXFLZ0VXVmpN?= =?utf-8?B?a04wTXRvUDFOVnJFRUNUWHMzdUtiQXYwTEo2RDYxMFV5SXdaRUtxKzdDL0hw?= =?utf-8?B?anlrVC90ckROY3NhZDI0eTFudkg5TWNlNjl2T3BTKzh0UFlJK2d6NVRxeHkz?= =?utf-8?B?aHBlTzB4NXRNdFRkaUhnZnc2Q3JiRTJSTDM2UmI1Qi9STjUvSFhURHZHWk9B?= =?utf-8?B?ODl5TUx1TEZlMS9PZXM1ZnJiMHNSb0RTWVhTWEtObmRMcXRwRndMd1dHMy9S?= =?utf-8?B?MkdKNVZuN0hsMUpPR0tDdXRKeWJZYUhMWXVkQ0JWaUhKT0NMMUVQTVg1WDN6?= =?utf-8?B?ODJkbE4zRk1hcFR0ZkxEd2xadG42TzZ1MTNkRFRiTUxhTDlxbkdpTGtwV1Q0?= =?utf-8?B?a3lJWGViS2V1WmhFTXQ5Zk1WZkt3cnJRVUliUEV4NWI0bmxZR2pWNGV4Z05h?= =?utf-8?B?a1dTMGc0WGIzcmJDK2M2UDI1WTZuRy8xeE5hRU10U09HN1RQY0lZZjBKTElH?= =?utf-8?B?SmV2emI0VUt5UDl0SmlNc1FEdklPWXlmZU9salJ1Rk9jYXU5VzdVOUplZVM0?= =?utf-8?B?NWtYeGZnRHY2K0ltZ1ZObG05ejEvWkdMZEpEVnk3dEZvd0k4c3VuK0luU2Rl?= =?utf-8?B?d3RnTnNDOEhCMzV2Y0ZzRy9hd0VrTTNUeXJ1K3BSK1k4bnRtMWx3NzREa0NQ?= =?utf-8?B?d2FabkMzR2pqN3Zla053TmZ6TmpRQzJnSllKSDFKKzhwRE50bU9GaU84ZHJR?= =?utf-8?B?U2llL3FqQ05XOGxJRk5ZU3NBUGZ5K21PNEZlWFMzRFR1VkNWZGFSamFNTS9V?= =?utf-8?B?bVZFYW5zdUV3RjhwNno1eUhEUVhvejJXUDNEQzBsaEhKRlNlRnpCeGFXc2JX?= =?utf-8?B?djhheXkxNVJaZGRyaXJ5cUdEQlA4Z0RNMWY3OHY3Qjlvcmk0N2lCVUlHaFV1?= =?utf-8?Q?WEqq+wCKL1s=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.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?RXh4Qzh3Nld6Ry9LcDJxMUQrK0FzM1Z0c1pNTWFJeUYvelVQU0MwQ2YxNXIx?= =?utf-8?B?SGNjTXRoQ1NScVYrS2ZKeWpqWXlQQVptTG95ZEI2ZW9idFlUVWs1dExmMzlt?= =?utf-8?B?enJDZDR5cGdTaDBMcDV0Uk1VU3NDT3podUU1TG9wTjJvUXFobnZjSlpzUWN0?= =?utf-8?B?ek5kM2RKK1ZTOTdCc0tpa3NFd0FIZlVWT2Z3a0lVS0dLUndmUE1mOUMyRFNF?= =?utf-8?B?WHJ3MUJTc2JYa1NhUFVqRUszYXd1UTFCTitmMk9YZytUazVyVHp5akYyVWRS?= =?utf-8?B?Ulg2YUI0bFZISHpPWFpYRXhDY25hUWJyN25GQnhNNnUxa3p0V0Z5aVpEcFV6?= =?utf-8?B?SjdFUlF0KytUY2NpaVVhT1ZCMlNEM21nelZ1dE4wMkdWRnF6enlQdm5ndnIx?= =?utf-8?B?YzhWRFRGQ3B4b2k2a055dWZCWjU1V28xUTRMMHZmZ0V3TlBqQ0JQamNmYldw?= =?utf-8?B?ckxoaHRlRDQzU2N1bjlicHRvRlRlQ1NhN0pGbVpma1JuVlZNRU1aQ2N3c2Yr?= =?utf-8?B?V1hkaVQxL2xVb1V1MXdxdVZoaCt1QVNNRld5SGlZb0I0Sk5XVmQ4YVU1U1h4?= =?utf-8?B?aWh0cXJSOEJFNndOMUY3UVpHMFhSMWJtc0ZMTGdzNmJPSFBPNzVPT2VWTHJp?= =?utf-8?B?WllWcHQ4TFlMSlZ5WjRVcWszbmhncTZ2NFp1bWRDbjZvcFh4VTd1YldGWUNt?= =?utf-8?B?Qm5VcFBTOGx2T0wwWTk3MlBTdk5hWVhxM25RTlpwVzFBL0JsWlVXNjJURWhi?= =?utf-8?B?SDRpV0ZSU1cxNzhaUFJydzZGUDczQ2ZKQkJGcXFVWEdRdU1pcHBncHVFNkl1?= =?utf-8?B?Qm5PQTMvM1FUMERMMVR3dVVwdnEwWXBOVGFSYjl5SHFvNVpheDRzc0pYczFI?= =?utf-8?B?TGV6ZktMd3hjQ203dUtDVk9qYWFNUWVDa3hORE0yRkNJVDN3QTdjZVRib3Np?= =?utf-8?B?MUhOZEFKZG54eE1NL3RrOGNxbDRRNGRBR2hsNHZMYlBWYlpaMnVEMm5RU0Jh?= =?utf-8?B?ZytoZm10VU1xaVpjWk9XSzdXQjM5VzRHSHFtdkFiN09qZmU1SlVybm50eStJ?= =?utf-8?B?ZS8zUzJiVUp5aGRFUXhoeHlpaWhGUmxHR3AvNEFhSTJ1djkvZ3pHMjdzVWIx?= =?utf-8?B?OEQ5VUQ4UFN0d3dLVmVka1VhTHRUdC9yeVlUbUthdnBvN3VWQ29GejRQOHV2?= =?utf-8?B?MU9BcXFobGRKajRoN3VPb05sUVdSS2gxMm9Qc20wKzM0ZU1XUmpDRC9PUXlP?= =?utf-8?B?enJWWWh2cjIrZ3dISDlLNmx5eVFIU3drbEliUXA1QXhxKy9WeW1DSzdPTzhV?= =?utf-8?B?MFlQSjF2Wi9RSVBOOUMxejM5cytHK2IxUDdwOHBLSHJQeGt0elpndlZnUlAz?= =?utf-8?B?ZlZpOXRZVVh6dWF3Q0pta1I4UHVKYjFhb1ZBNGp1cnB2QlVwVmVtUk9UdWc4?= =?utf-8?B?WjBDb0JqV3pCN3pKSjMrUjVJMGVkTmRjNFlmMlk1cFBIL1FVZTZjdjN3VGxr?= =?utf-8?B?TUpwdEp1U2lVMGNmdW5EYjNxcGFKZldwdm9XcUZHMno3dWhiRnJBN3d5dDBp?= =?utf-8?B?NnVtbEpWWmdDaHQ2NFVZVEtUSW1CaWx5OXN5UnhuT253NXkvVVplN3cvSzBC?= =?utf-8?B?ak5ZZWU5V096QkhjdkNSbWlpZ3pKNmg1YnZ4RVpkSVZHNEtuTmhqcjhaTHRw?= =?utf-8?B?WlM4dEp6QmM0dmpqNmJhUkJUZTFiN0xPS3VmK252LzVOSnRzckNTL04yQU1G?= =?utf-8?B?c2YvZlIzSnorUUE2NnlUN0VBRzNzQllMMTZXSXI4ZEpHOGhKUktESlVtSXVi?= =?utf-8?B?VGlDUFNxUC9hYnVMOHBwWE9zR0VySEpnY01lZDdMZmV1OEVIWlJGZWlpd01n?= =?utf-8?B?azdsajhXdzA3VDE3M3dMTXgrMUR6QmNlczlhWTlYUUxZUGEvTUpWcmNYeks0?= =?utf-8?B?Q05kN1R5eGp3cHRKUi8yVDJFMFRkT2pqWWxTN21tbFRDTmxCRkdGWXBTTFpt?= =?utf-8?B?UFNvR0I5aStvc0ZHM1pSbnBEcjF1Nkdid3J4ZFp2OVpUVFg0dFEvc1JiOG04?= =?utf-8?B?MnJPSFFkenZJOFZmODROZDNCdWh1QWwyRm1QQkRvQUJTdVZaL25hY3BiOCtu?= =?utf-8?Q?wn8M=3D?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 048e4f34-aab2-42b6-eabf-08dda1a49636 X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jun 2025 07:10:42.5194 (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: aU/tZGL3NEFEatkKhXMwZFeA42//AGWXAi1G0nU+L54JtwdRgYCtGox6ojSnMydy X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB8115 On 30/05/2025 22:31, Mykola Kvach wrote: > From: Mykola Kvach > > Add missing input register descriptions to enable_secondary_cpu_mm > and enable_boot_cpu_mm functions. > > Specifically: > - x19 is used in enable_boot_cpu_mm as physical start address. > - x20 is used in both functions for physical offset passed to load_paddr. I'm not sure if we need to document register usage that is part of a comment in so called "Common register usage". It's repeating information for me. That said, I can see that Arm32 does that too so no objection. > > This update improves code clarity and consistency in comments. > > No functional changes are introduced by this patch. > > Signed-off-by: Mykola Kvach > --- > xen/arch/arm/arm64/mmu/head.S | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/xen/arch/arm/arm64/mmu/head.S b/xen/arch/arm/arm64/mmu/head.S > index 634156f83d..033b3a018a 100644 > --- a/xen/arch/arm/arm64/mmu/head.S > +++ b/xen/arch/arm/arm64/mmu/head.S > @@ -313,6 +313,7 @@ END(enable_mmu) > * > * Inputs: > * lr : Virtual address to return to. > + * x20: phys offset (used by load_paddr) > * > * Clobbers x0 - x6 > */ > @@ -337,6 +338,8 @@ END(enable_secondary_cpu_mm) > * > * Inputs: > * lr : Virtual address to return to. > + * x19: paddr(start) (used by remove_identity_mapping) AFAICT it's also used by create_page_tables. I don't see it beneficial to mention the places the register is used. It can easily go stale. With the remark addressed: Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Mon Jun 02 07:13:26 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 07:13:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1002804.1382188 (Exim 4.92) (envelope-from ) id 1uLzML-0001EG-1r; Mon, 02 Jun 2025 07:13:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1002804.1382188; Mon, 02 Jun 2025 07: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 1uLzMK-0001E9-VV; Mon, 02 Jun 2025 07:13:24 +0000 Received: by outflank-mailman (input) for mailman id 1002804; Mon, 02 Jun 2025 07: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 1uLzMJ-0001D2-C3 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 07:13:23 +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 10ab03da-3f81-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 09:13:21 +0200 (CEST) Received: by mail-wr1-x435.google.com with SMTP id ffacd0b85a97d-3a35c894313so3738235f8f.2 for ; Mon, 02 Jun 2025 00:13:21 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-23506bd94b2sm64566975ad.72.2025.06.02.00.13.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 00:13:20 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 10ab03da-3f81-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1748848401; x=1749453201; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=ysYu7/nTavhdXsRNUmlSp5Kk8buLrns0p+bBB/DCuB4=; b=IBMgMQC35aCRotovJ5Xr+fEyAYxTZuUK1qcm20L0hW5J5wWZtnRJ4PjByIFhssMhVZ rMuu3/5AgrV/yNVfd+Qi5PzfoqK1iNo358vNsnstNponerdSPZJFD+LytxHXBRyU/bKm NpIEF4T9lq5PnjLYikKPNes7mKvZ7AkFmG5eQbhPwSTODQTQ0QQKcMLGrtuBJMRrZ9ql 83DlBlrPFN59iqd28LuIwybxeKZfTKOrb22WrBBAjeLWzMB4gq6lO1HT5c9H/lPx6KvX +YxTZmo+OsnYhsBZrYzTND+GgsTB+pLA/RHGvBIND9ceoU4TaIzNElbLCO+enTpsYKx3 2plw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748848401; x=1749453201; 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=ysYu7/nTavhdXsRNUmlSp5Kk8buLrns0p+bBB/DCuB4=; b=rGayjt8QyraGWBps2PKVouYcgGyvYulgmn3O6lIEBMrPV7ibkXFITZiGYGmUNoAYC4 Aoekdqh+jVq49S2/dg2t9x5nDhDdqozN9ggtqeS1TyUsIrBbyrYI2tUOC5UvbVSudia1 fMBCGXoejw8sMpFru24HdN/aLWO3zA/ZxwJ8QSLUUuJo94SmRdwFCtkQ+m2PThzEDdB6 LpsmPPPh8+XB36WedQ4adAzIs2ze/Qm+XraEyQeUXzlCLbI+iuxCllyrGBg7ojgh148o cKI2nTMI82A0wVB/4rpGlKuQ4xFePWiojbiJ6Xv9fEBRZA6utlgbBINpDEPrCLsziGKO rnBA== X-Forwarded-Encrypted: i=1; AJvYcCXnJzLyLV8ccKNvpah9vKtsInlPeAI1P4oFiF5m7xp1trVnolfMJpJ5qktUFSsHKii9JjsMDs+J6bE=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy6yfegy23pCLFjX1ayRfgmaPoCdRswM0kH9urVOl/DKlvg0wDV luznLcrXXik4yJsTVx0JsAwIbZEWacOjGxXCvXlLisZO2odekka4px9GX5StdFq+yw== X-Gm-Gg: ASbGnctgF1zwCIk00Twp6HMJyl15RP5vIrX1Z+t58zVsHPseYcQ//ciGJjLxkdmfhsf LDAc94B59hLDxrFzoOCXAR4sv5qmnhr1U4jatKjGUmenMfGL5EFo45c3pZhfecclIdOOnS+RsRm DpnwZaKEgNcJICeti418lIaOO5JLmo1TxDmr4fLZ+W69M3ZI3d6dCyRXlZKHtvVsN+rx2nykMOf ZH6rRDqp5A8Qdv+wrxRKUEAehl6M3cPCkcl2jjS60JcRK1OF094dDeb/XNMzZhUQC35trxSTLic TpIJ24WzmLbrNh16dBPf6yb9gnuJqvJ4g8L5vqT0+uyO44HYsEbiMQDbLhj43tGTji98Pvq9wfZ UBmGvaR+tk6YGdsXQ4ukxDY+qfwA6LbGaTd5d X-Google-Smtp-Source: AGHT+IHNod+xfvxIR1KRV7KJVgc4dGt9nRaEdg+gkPFzwZDivLGa8sx1ca1SDxBE2GXkdyku4DY5vg== X-Received: by 2002:a05:6000:1acd:b0:3a4:ee3f:e9a6 with SMTP id ffacd0b85a97d-3a4fe3a6edemr5509470f8f.54.1748848400968; Mon, 02 Jun 2025 00:13:20 -0700 (PDT) Message-ID: <2b004c3e-b9b8-4ed5-b54c-0f00f6b78da6@suse.com> Date: Mon, 2 Jun 2025 09:13:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 3/3] xen/domain: introduce CONFIG_MAX_DOMID To: dmkhn@proton.me Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com, xen-devel@lists.xenproject.org References: <20250521000024.2944685-1-dmukhin@ford.com> <20250521000024.2944685-4-dmukhin@ford.com> <54945bd5-333e-4ffd-8ff1-bb89d22c7ef4@suse.com> <3b203f39-756b-4fb3-b0e5-0f790701c23a@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 22.05.2025 20:08, dmkhn@proton.me wrote: > On Thu, May 22, 2025 at 09:01:51AM +0200, Jan Beulich wrote: >> On 22.05.2025 02:09, dmkhn@proton.me wrote: >>> On Wed, May 21, 2025 at 09:31:34AM +0200, Jan Beulich wrote: >>>> On 21.05.2025 02:00, dmkhn@proton.me wrote: >>>>> --- a/xen/common/Kconfig >>>>> +++ b/xen/common/Kconfig >>>>> @@ -576,4 +576,11 @@ config BUDDY_ALLOCATOR_SIZE >>>>> Amount of memory reserved for the buddy allocator to serve Xen heap, >>>>> working alongside the colored one. >>>>> >>>>> +config MAX_DOMID >>>>> + int "Maximum number of user domains" >>>>> + range 1 32752 >>>>> + default 32752 >>>>> + help >>>>> + Specifies the maximum number of domains a user can create. >>>> >>>> My prior comment remains: The description and help needs to be accurate, in >>>> order to not cause any confusion. In a true dom0less environment I'm not >>>> sure the "user" can create any domains (post boot, that is). And when there >>>> is Dom0 (or late hwdom), the number specified already isn't the number of >>>> domains one can create (again, post boot, which is how I understand "user >>>> domains"). If someone picked 1 as the value here, it's unclear to me how >>>> late hwdom or dom0less would work in the first place. >>> >>> Do you think something like the following will be more accurate? >>> >>> config MAX_DOMID >>> int "Maximum number of domains" >>> range 1 32752 >>> default 32752 >>> help >>> Specifies the maximum number of domains: dom0 or late hwdom, >>> predefined domains, post-boot domains, excluding Xen system domains >>> (domid >= DOMID_FIRST_RESERVED). >> >> Especially the mention of DOMID_FIRST_RESERVED is too much of an implementation >> detail here, imo. Beyond that - maybe, but I'm not overly happy this way either. > > Will the following description will be satisfactory? > > config MAX_DOMID > int "Maximum domain ID" > range 1 32752 > default 32752 > help > Specifies the maximum domain ID (dom0 or late hwdom, predefined > domains, post-boot domains, excluding Xen system domains). This is better, yes, yet ... >> As an aside - MAX_DOMID and "Maximum number of domains" are conflicting >> with one another, too: Do you mean "maximum ID" or "maximum number of"? The two >> are different by 1. > > That would be "maximum ID", thank you. ... imo asking for "maximum" of something is perhaps a little odd. Asking for "number of" is the more usual thing imo. Yet as before - I remain unconvinced we need such a Kconfig setting in the first place. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 02 07:17:40 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 07:17:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1002812.1382198 (Exim 4.92) (envelope-from ) id 1uLzQO-0001nI-GW; Mon, 02 Jun 2025 07:17:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1002812.1382198; Mon, 02 Jun 2025 07:17: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 1uLzQO-0001nB-DP; Mon, 02 Jun 2025 07:17:36 +0000 Received: by outflank-mailman (input) for mailman id 1002812; Mon, 02 Jun 2025 07:17: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 1uLzQN-0001n5-AB for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 07:17:35 +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 a6c71e15-3f81-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 09:17:33 +0200 (CEST) Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-3a50fc7ac4dso79298f8f.0 for ; Mon, 02 Jun 2025 00:17:33 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-747afeabc6asm7211856b3a.53.2025.06.02.00.17.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 00:17:31 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a6c71e15-3f81-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1748848652; x=1749453452; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=MBNE0WMUvarYwLkTpc6pA2ckZ9CoSB6Ya1Gn/flLcnA=; b=IOjuXXxILBIN9d9+/yN46u4x+I4tgEOHzB+pShVyoKKmdsLxg9w9+faX+nzeJRf4Nq TZ/TuVHrr5Ilsrt2sYcAp4x47iQvVcsIhn9S91Ieg9LWBIyyXvn4XlNjMxFIdmCDIsLz jLrmSxGEpEWBAVTzjbSUD+NQDQTvley1DRQAyGLzbh39t6dSrnPPcj4g/waNZWkzZo5D P5ubknsqAJ40I0MyGdKCbK8VFBxca6uBkv5/V4gBk1ltFAKafDz3wggqbgxd543L5VmH DHDEyTUmiDZwImNfVDLlL2J318BTU6dTZdEWd2pyNolWdIv2FLD2EUh/6JlZZGEGswJe sW1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748848652; x=1749453452; 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=MBNE0WMUvarYwLkTpc6pA2ckZ9CoSB6Ya1Gn/flLcnA=; b=q2W1greYo4xBRESkRfdAhT8EYRWphm9ijYLJhpwjey/mGOTL09hVso0Tp2gg//t6yj q5Gh/6hYefW6Y+DYcNdE9Jw8GH5gwj5PKBdfBDXlP80k/I2JPY8Td7h69CCPnjLcVagO TGoWHZUSwmEa8yoWv4VXM+Bod9FE3ozFrP5iHVCi7BN4pgZB4VubMmv3iucwrpC2c8qV P5Jo+HTiJFMGtFQrHXIWl25J2MWRgKyaPciRQikAETZXbxTMfMiywXl5Qx/Bp452+qmU C3T3ZMVC9VE6lulFPVbsNKbk7hBDk5c0z+EVd6hJt+OBhjsWFKJJfZ+1hhe/iCwl1e5g b/lA== X-Forwarded-Encrypted: i=1; AJvYcCUGuzFar+FT/jl9dzemZ3E5xZN6gb5XMn/rl6Jl/teL7vgVGuM1VWRs1d44CyTvZdIf6oIcRE+AT5U=@lists.xenproject.org X-Gm-Message-State: AOJu0YxSBsCyO8i75Ct5SAgse4MvOhHeLcGawb2XM0isdAtMaIQWvRzF a0NgGGfVLjQ2h0i5bEVFt6E6HYr7NOE89J+gTmVdiuYBQAUrwhtJnYwbcrr7RbxZuQ== X-Gm-Gg: ASbGncus50zF9RBOrbVeJMSYTC7VzE/8c/Xd0D/j/luL9gSw6Me1CEdrbrETyL2GPqu 1Fe+e56sxGHVCA/VsFsX0xy6WglmK/5caUbccgbkW3MQcnYTIoq68O9VGOLB32KZlDSqAiPHa1T v0Iax1nVKGUDtpmb/rLA5lvb6xdGeZQGo9PiCa8KBikgJpEOgpCJKk3jrNZv1vv5eVhWIfeKI0D CUTlfoePXrGxjRAn13SvR1Fm/ToJFrq4G5VY0WXGq4r+D3ui7O7P+nyGQ1FSQ96z9kF8C09xI0p 2miobCB9As0EUX+iMqazEfXRfazmpO2htqibEpbUSrYHtlH8MiKMNDibqsVU2Q2PdC0fdVSM1Nl BIOqcYlfscwba3WGVX5zFk0FTgHWXAs9sxmIxDAASidIIwR5H3gZKtASCUQ== X-Google-Smtp-Source: AGHT+IFsT4MR1Zj3Rc92bGRXe/kVD0xAK/1FUYonEqZOHZe8p/1N9q5nzHEkCAjesKtnuzKgtFmdYQ== X-Received: by 2002:a05:6000:18ab:b0:3a4:ea40:4d3f with SMTP id ffacd0b85a97d-3a4f7aafa70mr10891201f8f.53.1748848652480; Mon, 02 Jun 2025 00:17:32 -0700 (PDT) Message-ID: <31c7faf1-d393-40d5-87f9-1a01d1ab39cb@suse.com> Date: Mon, 2 Jun 2025 09:17:37 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 01/22] x86/include/asm/intel-txt.h: constants and accessors for TXT registers and heap To: Sergii Dmytruk Cc: "Daniel P. Smith" , Ross Philipson , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Lukasz Hawrylko , =?UTF-8?Q?Mateusz_M=C3=B3wka?= , trenchboot-devel@googlegroups.com, 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 23.05.2025 21:51, Sergii Dmytruk wrote: > On Wed, May 21, 2025 at 05:19:57PM +0200, Jan Beulich wrote: >>> +/* >>> + * Secure Launch defined OS/MLE TXT Heap table >>> + */ >>> +struct txt_os_mle_data { >>> + uint32_t version; >>> + uint32_t reserved; >>> + uint64_t slrt; >>> + uint64_t txt_info; >>> + uint32_t ap_wake_block; >>> + uint32_t ap_wake_block_size; >>> + uint8_t mle_scratch[64]; >>> +} __packed; >> >> This being x86-specific, what's the __packed intended to achieve here? > > This structure is passed to Xen by a bootloader, __packed makes sure the > structure has a compatible layout. And it won't have a compatible layout without the attribute? >>> +/* >>> + * TXT specification defined BIOS data TXT Heap table >>> + */ >>> +struct txt_bios_data { >>> + uint32_t version; /* Currently 5 for TPM 1.2 and 6 for TPM 2.0 */ >>> + uint32_t bios_sinit_size; >>> + uint64_t reserved1; >>> + uint64_t reserved2; >>> + uint32_t num_logical_procs; >>> + /* Versions >= 3 && < 5 */ >>> + uint32_t sinit_flags; >>> + /* Versions >= 5 with updates in version 6 */ >>> + uint32_t mle_flags; >>> + /* Versions >= 4 */ >>> + /* Ext Data Elements */ >>> +} __packed; >> >> It does affect sizeof() here, which I'm unsure is going to matter. > > It doesn't hurt anything and makes sure offsets match those in the > specification. It similarly doesn't appear to hurt anything if the attribute was omitted. Imo we ought to use compiler extensions on when there is a need to do so. >>> +static inline uint64_t txt_bios_data_size(void *heap) >> >> Here, below, and in general: Please try to have code be const-correct, i.e. >> use pointers-to-const wherever applicable. > > I assume this doesn't apply to functions returning `void *`. The > approach used in libc is to accept pointers-to-const but then cast the > constness away for the return value, but this header isn't a widely-used > code. Which is, from all I know, bad practice not only by my own view. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 02 07:18:22 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 07:18:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1002818.1382208 (Exim 4.92) (envelope-from ) id 1uLzR8-0002H1-Pd; Mon, 02 Jun 2025 07:18:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1002818.1382208; Mon, 02 Jun 2025 07: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 1uLzR8-0002Gu-Lv; Mon, 02 Jun 2025 07:18:22 +0000 Received: by outflank-mailman (input) for mailman id 1002818; Mon, 02 Jun 2025 07: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 1uLzR6-0001n5-UC for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 07:18:21 +0000 Received: from AS8PR03CU001.outbound.protection.outlook.com (mail-westeuropeazlp170120005.outbound.protection.outlook.com [2a01:111:f403:c201::5]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c00fea5f-3f81-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 09:18:15 +0200 (CEST) Received: from DU2P250CA0007.EURP250.PROD.OUTLOOK.COM (2603:10a6:10:231::12) by DU2PR08MB10187.eurprd08.prod.outlook.com (2603:10a6:10:46d::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.37; Mon, 2 Jun 2025 07:18:07 +0000 Received: from DU2PEPF00028D0C.eurprd03.prod.outlook.com (2603:10a6:10:231:cafe::d9) by DU2P250CA0007.outlook.office365.com (2603:10a6:10:231::12) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.31 via Frontend Transport; Mon, 2 Jun 2025 07:18:06 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by DU2PEPF00028D0C.mail.protection.outlook.com (10.167.242.20) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.29 via Frontend Transport; Mon, 2 Jun 2025 07:18:06 +0000 Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24) by GV2PR08MB9422.eurprd08.prod.outlook.com (2603:10a6:150:dd::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.24; Mon, 2 Jun 2025 07:17:29 +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.8792.033; Mon, 2 Jun 2025 07:17: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: c00fea5f-3f81-11f0-b894-0df219b8e170 ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=LitSMbD+Zu+QTJms2V2alI6tgiI8c1JDEjOGGUZP7mROCXDguiLX6VkL17TcgS3Xgui2b5AwHtAzHyMwPZgB3EGNNkGFXSTomslFGu46cG3um+Hi5KFe/QFK9EHV6YSO3Vzri9rboEdlOfTOwnCfXM2WjB1QJpVE59uTwlmjBx47QaJL3R0+SOgGawzIuVfJH0N2+9IWEmoD73zubcjHjOHES1uq7YT5YraOqYj6KdwP8GdN55ffHyycgKT5cghCyAT012SNTKk1QoYmFR0HTnjRI+58qsfO/e1uiojGIeV7zaFgjlWJW9JFyDdIuxbFLWYlgriwwe3q95cxkiVHBg== 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=8365uYGqRfP9UxX4VmuZlIYfBAKeVIqmmmcqVV9tR6Y=; b=lFppGJ7NjcrB505OLWydO8nOw1k8x9AnTAhSoaxDAzhfYkZVKkOEvw3CX4niWAZL84kxzWLvTh7KZLJtCAMNcwlewyTJKMUzyWCVagif5KETVmZVZ9y+A+Oq+CoBlwgub4vacl3e4OElv4n0P/gz4Y08HRVhE15ry688rqbjbMh+tErZpfRO/NFMZn1SEkI5082VXQEDAIM3bKoQ1av6TtllpssHWlJH+nIXB53xynVATVpw5UHk0pDi6Sz2yEjsPHCjJ9EfknPhmo9K3+S5M+JKU05xICTfGTi4FxIEiK5v+vneZX+SzzruBU4TZZy2ROj3P6nNprzu640cslgEzQ== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=kernel.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8365uYGqRfP9UxX4VmuZlIYfBAKeVIqmmmcqVV9tR6Y=; b=niLhBBpjeqinl/GpFBoYzohaTo8WfmVwfMCBMJv6coIBUzMk0YxPU2mGNjy7tP+H/WI+D6OdFtkEv/43lDkdwxvA66D0luEbINQqJ0fd7geqRjd7CEdSsXTCR+yQ642aVdrE4SuJKr2WGW9VWVvu4pEBFHyIAO6qNs1DCVq8xVE= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=arm.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 4.158.2.129 as permitted sender) receiver=protection.outlook.com; client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Dmjb/k6xYrpdgNcyG8jUtqbtr3VUTtNn51O43qeJYElE/GWjPZMKrqR70O5v6yw6WDG/UbuHwYQee3DwudAYes6li1/brV2g0Ha9M9jV+O+hC/v0sjsHgCKpcM7l4/2Ca5VTuWiUBotNl/HaXomGRRI/gJz75lWhuJT6TLJiTxggXufrWNPKec/ZW/Iqo7yOqPYIvN6T9TX8hxaZCW6TfrSVjP8ocXUO6Rbc53to7gGckOvfyi7zqu5Xa5VaAtmH8n0fjVwGldyQnNO6OMHJxzK7jMUUNRZSeLu3rHnu+Guduli5Hge2hlrr3j7OERXgQVlRx+RpjRQI/qWIsVVbFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8365uYGqRfP9UxX4VmuZlIYfBAKeVIqmmmcqVV9tR6Y=; b=PYfCQBx3jVpwKC1MsX8C0kfGKJmxIONDdl1A+a4HUZSuLdJ87KyMzrORvX4FT6B+6by6LIAHCx0gX7g+QXq++7tadPgDhBtmCObIp1pWLZzrxsCnHOOXKdvJsDNU8ga6L/OwVW3c4cpyG1sOQW2yaGWiYmTD7rzwVOKIxSf3Y3SWRr0ysulj56PyhNQEOgPA6ugpAF1GUbJeGNSdfDb+/NblbhP+AU8GxftZoyQP/swNtp6LcIYd9zpu4t0ll2upitSlykQt81QB5ym1t+xG8m1Q6F3URCTwNWwyfVX4HTDui2Z42xzKJcukmXwoQkGcofRRdIqZWYGYbI/1oYGmgw== 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=8365uYGqRfP9UxX4VmuZlIYfBAKeVIqmmmcqVV9tR6Y=; b=niLhBBpjeqinl/GpFBoYzohaTo8WfmVwfMCBMJv6coIBUzMk0YxPU2mGNjy7tP+H/WI+D6OdFtkEv/43lDkdwxvA66D0luEbINQqJ0fd7geqRjd7CEdSsXTCR+yQ642aVdrE4SuJKr2WGW9VWVvu4pEBFHyIAO6qNs1DCVq8xVE= From: Bertrand Marquis To: Stefano Stabellini CC: Oleksii Moisieiev , "xen-devel@lists.xenproject.org" , Andrew Cooper , Anthony PERARD , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Volodymyr Babchuk , Grygorii Strashko Subject: Re: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Topic: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Index: AQHbyNXUPX94A4OrRkGo4Yj0v+1L6LPgqpIAgA7ggoA= Date: Mon, 2 Jun 2025 07:17:29 +0000 Message-ID: <04B1F737-5E6B-47C0-B2B9-74288C68E68A@arm.com> References: <318044ae12f13b6b297b3f5fda577a1a6cd143da.1747669845.git.oleksii_moisieiev@epam.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.600.51.1.1) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: DB9PR08MB6588:EE_|GV2PR08MB9422:EE_|DU2PEPF00028D0C:EE_|DU2PR08MB10187:EE_ X-MS-Office365-Filtering-Correlation-Id: b5ccc60c-686b-4bfa-95ee-08dda1a59f0d 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|7416014|376014|366016|38070700018; X-Microsoft-Antispam-Message-Info-Original: =?iso-8859-1?Q?z7OcDfOOlSLTs8354HtJt1ItZOfX1Od3w1AZJoywNSOd5mBMqWMi32RCXF?= =?iso-8859-1?Q?HL6fdN2OzzoEz8RccPQJO9dhrNeLbGNBn3eka+ZEpUYWQ6Zcg2nT5XgR73?= =?iso-8859-1?Q?frfq2wVrdhVBfL9h2M4VdcJqVaK3HtWXDeal0lTwgUrTpKL+3l6WE8fWlc?= =?iso-8859-1?Q?WoAAIJL9wWUFeeCTHtrRb2jaqiiUP8OPz4a7bYisyZuQAU/idYipHx2nEr?= =?iso-8859-1?Q?lidqGNrvWtG2hSlxlw2ySY7yxm5q7tgp9hrRv73JYAhznWwpSbJCZZDjJd?= =?iso-8859-1?Q?27HVln5s/GQuEqf2siPgNZlNCnPBWIK3vy1J8T7M2gl7xnb9LS5Udv+2pw?= =?iso-8859-1?Q?1vzId3UocsX+E/KfLhJo5aSfubgdWa3/p92SFsBOCCQ8f3LhWPfjnb5Pw1?= =?iso-8859-1?Q?CYX8jZPFwKB52LsNIldZ0Qb3L4LBKnUKeScQVO0sZFqbcRiCxcw6GIUKiW?= =?iso-8859-1?Q?EUBk5G9sQddOxGW3F2A8q5xB5NyKCfJOa/GWs29Y4MsQCNfhFRKE2FVmR0?= =?iso-8859-1?Q?9SnamO5MDb03ZqZ6PwRvFfC/eRvpcRGpT/cwpGHbtwsZNYwJXnSg0/4MqY?= =?iso-8859-1?Q?QlcoHqULopEO+MXn7A1YwWnuK1AmrjgMbO1gZdk4kUWwOAfziqobiW8t8B?= =?iso-8859-1?Q?2RKzI7dV4GemkS0GmR54udOqWgKQeO5AsUlyOUQKOXMyNi9YfONT4AnSxK?= =?iso-8859-1?Q?j1b0EgEPJfqRDfuCz/r/qTCgoBpjlwitYa3S7e+aBIMZ4Y88yorXXva2od?= =?iso-8859-1?Q?CSfMre5y7HzhF3a1ed8Z+QWt7LQcOwIlxE5hFW7zUisXP87d3JPTjHRiqD?= =?iso-8859-1?Q?DCVhTPx+eNDuXznw46GJW5K1hdzdC18Yx129BySSQIUf4B/qrTjKtxA0Nh?= =?iso-8859-1?Q?7v9aGSgk/6U4ZNIiKw6ED20DeIOcP5qihaTy9TkgM6CVWZ1Bz8S+m4VY4j?= =?iso-8859-1?Q?4xy5p2bQqMEYa6HtZBDgB5RVHgm5HumB3y12oZR19noZbuOUbmXstMC6hF?= =?iso-8859-1?Q?ip8+W24Up/mwtnA+7Dr9jvuPfBeU5Zwbi0NF7+CSWLyKigwfqp5IFGLjuR?= =?iso-8859-1?Q?VM3Y0SMIMgp1hj1P9Dt2rfdrSeMskRdETrgJbafmyZCRIM3ZFfUUcgODzO?= =?iso-8859-1?Q?U1LZ85C7oR55Hyz3MMZC6xQs8ZiZPfk39i6jDzn3+3zk0709oEAbRGMN0E?= =?iso-8859-1?Q?yaLKxMW9RDVsgHSuUymOiXJDnCkHB958CbdgeM8pxGAAE2ruzqYAKMNxF0?= =?iso-8859-1?Q?cmDtn2bfrp4BV2nqkyS22W8UI7pY2EolEEOCsCfHaWqL+iBQhyWsXm7jeS?= =?iso-8859-1?Q?Uzpya8iOLyn6qM8JSi7WhH7RVcVnEKARslfZedbwaD6jYz+KejAe6JI4hH?= =?iso-8859-1?Q?WWAE0I5PJSWKFXMjZZfQ3u8oYTOlgyxMIkCHpwC2ORG/97VTo9WJPZ6ujJ?= =?iso-8859-1?Q?Z2NmtXtMeNfKMstu7fAPt3n5InqPepxF4aBnq0pHsWX25Cg4wZlZ2w9aTt?= =?iso-8859-1?Q?4rCUG38bdTWvzxJORwNnlG?= 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)(7416014)(376014)(366016)(38070700018);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="iso-8859-1" Content-ID: <35856A384109AC459F38951C86D3883B@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR08MB9422 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DU2PEPF00028D0C.eurprd03.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: ea2e1b38-0e4d-43a4-2d5f-08dda1a588fa X-Microsoft-Antispam: BCL:0;ARA:13230040|14060799003|36860700013|7416014|376014|35042699022|1800799024|82310400026|7053199007|13003099007; X-Microsoft-Antispam-Message-Info: =?iso-8859-1?Q?P4k5ntiZOBKt5m+GaQHSeHAQxZgCGhrjUPSPLssfoIhXgE3FE3tUWeqaLN?= =?iso-8859-1?Q?0e+7Ar/OAd53gRJOC2chbuoFO1h6vfVbyNc6jAB8BGdkcuDvNa+xzHHQmL?= =?iso-8859-1?Q?Adl/oSsHRcU4SBPJyB1UABwC/8U621DZKMVjTy+hz7qZTIHPXepbIfK5sT?= =?iso-8859-1?Q?NAQVe6gUPGCYp2Yz6ntajVnRr2iD9kgsevjK4VV1gsdNJnrWNNqMBub3Hq?= =?iso-8859-1?Q?7J0gf6z4BAMi+bUnZDIVI+If98mEjjFEH8TuF1vJr8pYdnEGindwqW3Kmp?= =?iso-8859-1?Q?h5ZLkaGj51k/H/8M5EU6L/gzwvqgtcjLpOWNTApw2Fo2GU6CDST+mG4422?= =?iso-8859-1?Q?a6PPsVy0hWUN0IGJ/9Xr7yeR/YS0zkonEmp6dpoqvNuZGqBef9sqa87GL0?= =?iso-8859-1?Q?2q8HQJRyLwnvlL9tIK4DyiKymdQI6eEDNA4+JioWRwexA03PVmpoukB9XL?= =?iso-8859-1?Q?D0TnIoAdVCGRwQLQknI0etsFxLeZhY3d6YziG0tVBwhG2p43EI/TDEK3yk?= =?iso-8859-1?Q?Yg3GjcjDox6e3qB//lkD/kxNkW/Ajl2I/U1XdCa7NyfIF27Q65Gn6Uqqa4?= =?iso-8859-1?Q?0nXXDgzHuS2bAaWHb+XMsVop+t3go410JST8NysTVKoQC08NDBTDrl13d6?= =?iso-8859-1?Q?6GpjGb1tZ112FeKCpNYXTeiT2EkUJOng3F8HfD3Cxbr7G/Wu8InQ9u0x7s?= =?iso-8859-1?Q?nMDdWjRxgpAl5MfV18G4O3UrM08dKAbVk9/hyk7uKFANOQW9iCAJDPFk2T?= =?iso-8859-1?Q?2ZFF6moyYzesZrtz9/iqTTKl2TVi3k3ht++tU3Ydn3NEVNSfl8nd04qv2E?= =?iso-8859-1?Q?6G+Jg5qM3EEfbMaVSId1wCzlFWAxLOLLrm9L1wSbCk8aWKzAcgM0uVaqNX?= =?iso-8859-1?Q?G2tu19DUiLwpMjf4vJWugXwE0MdKeRLAcKXnZdRk2UitJc3bQV3hVImbWS?= =?iso-8859-1?Q?2qrL6CtR4w2pqgNy+RoEvRxpcd88OAVZzvM4a1KlRHZh6ONr581YRxf2gB?= =?iso-8859-1?Q?MA5OW+NHtngFc0jv7Tlt/UBWzxHYRgg+fEsqSDL9ia35wCH6kqB7nXaBEN?= =?iso-8859-1?Q?9fgsKrF+cnQtbVczBz4koTQM04l9vrDN76qplOvy45NkS31/kWBIM1O952?= =?iso-8859-1?Q?9FXIYmnC5d8QwnljWOoCjNrTkoJ9suM6MlFmJTsVIwMpSSJ2VhBdR/iOkV?= =?iso-8859-1?Q?NPXMAeQ6GQ/niy5vcv5k8fW859kdYH5vxBqa4MkA25svrkxbjp/MvVV8Om?= =?iso-8859-1?Q?3vqx+YRbZzeU5kC+KWn5FRG9erMb8t1YF0itGWjiGEgVpF135JK4nAcoCF?= =?iso-8859-1?Q?btIwvVK18+jMcToFhDzrQuarW89G1UXNjpgclmbZRbE4+DrxoqT6jnaFuA?= =?iso-8859-1?Q?0HMiYo/HNjznBkKkA1ZFPEvaKclGplBTvv3mYb/ZDZiZBOMi2VVLMruAV3?= =?iso-8859-1?Q?c8lXajWlHNa3M46i7ZenMP+RqgC9a77L3CKZk6Lw/kFSW3mk2M9TegUSNE?= =?iso-8859-1?Q?OmATBWN9eAuC3SbvmnezkurAFL2yM6e1VNT+h9ZpMDpw=3D=3D?= X-Forefront-Antispam-Report: CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(14060799003)(36860700013)(7416014)(376014)(35042699022)(1800799024)(82310400026)(7053199007)(13003099007);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jun 2025 07:18:06.5552 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b5ccc60c-686b-4bfa-95ee-08dda1a59f0d X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com] X-MS-Exchange-CrossTenant-AuthSource: DU2PEPF00028D0C.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU2PR08MB10187 Hi Stefano and Oleksii, > On 23 May 2025, at 22:06, Stefano Stabellini wro= te: >=20 > One question for Bertrand below >=20 >=20 > On Mon, 19 May 2025, Oleksii Moisieiev wrote: >> This patch introduces SCI driver to support for ARM EL3 Trusted Firmware= -A >> (TF-A) which provides SCMI interface with multi-agnet support, as shown >> below. >>=20 >> +-----------------------------------------+ >> | | >> | EL3 TF-A SCMI | >> +-------+--+-------+--+-------+--+-------++ >> |shmem0 | |shmem1 | |shmem2 | |shmemX | >> +-----+-+ +---+---+ +--+----+ +---+---+ >> smc-id0 | | | | >> agent0 | | | | >> +-----v--------+---------+-----------+----+ >> | | | | | >> | | | | | >> +--------------+---------+-----------+----+ >> smc-id1 | smc-id2| smc-idX| >> agent1 | agent2 | agentX | >> | | | >> +----v---+ +--v-----+ +--v-----+ >> | | | | | | >> | Dom0 | | Dom1 | | DomX | >> | | | | | | >> | | | | | | >> +--------+ +--------+ +--------+ >>=20 >> The EL3 SCMI multi-agent firmware expected to provide SCMI SMC/HVC share= d >> memory transport for every Agent in the system. >>=20 >> The SCMI Agent transport channel defined by pair: >> - smc-id: SMC/HVC id used for Doorbell >> - shmem: shared memory for messages transfer, Xen page aligned, >> p2m_mmio_direct_nc. >>=20 >> The follwoing SCMI Agents expected to be defined by SCMI FW to enable SC= MI >> multi-agent functionality under Xen: >> - Xen manegement agent: trusted agents that accesses to the Base Protoco= l >> commands to configure agent specific permissions >> - OSPM VM agents: non-trusted agent, one for each Guest domain which is >> allowed direct HW access. At least one OSPM VM agent has to be provided >> by FW if HW is handled only by Dom0 or Driver Domain. >>=20 >> The EL3 SCMI FW expected to implement following Base protocol messages: >> - BASE_DISCOVER_AGENT >> - BASE_RESET_AGENT_CONFIGURATION (optional) >> - BASE_SET_DEVICE_PERMISSIONS (optional) >>=20 >> The SCI SCMI SMC multi-agent driver implements following functionality: >> - It's initialized based on the Host DT SCMI node (only one SCMI interfa= ce >> is supported) which describes Xen management agent SCMI interface. >>=20 >> scmi_shm_0 : sram@47ff0000 { >> compatible =3D "arm,scmi-shmem"; >> reg =3D <0x0 0x47ff0000 0x0 0x1000>; >> }; >> firmware { >> scmi: scmi { >> compatible =3D "arm,scmi-smc"; >> arm, smc - id =3D <0x82000002>; // Xen manegement agent smc-id >=20 > some extra spaces, it might be a copy/paste error >=20 >=20 >> \#address-cells =3D < 1>; >> \#size-cells =3D < 0>; >> \#access-controller - cells =3D < 1>; >> shmem =3D <&scmi_shm_0>; // Xen manegement agent shmem >>=20 >> protocol@X{ >> }; >> }; >> }; >>=20 >> - It obtains Xen specific SCMI Agent's configuration from the Host DT, >> probes Agents and build SCMI Agents list; The Agents configuration is ta= ken from: >>=20 >> chosen { >> xen,scmi-secondary-agents =3D < >> 1 0x82000003 &scmi_shm_1 >> 2 0x82000004 &scmi_shm_2 >> 3 0x82000005 &scmi_shm_3 >> 4 0x82000006 &scmi_shm_4>; >> } >>=20 >> /{ >> scmi_shm_1: sram@47ff1000 { >> compatible =3D "arm,scmi-shmem"; >> reg =3D <0x0 0x47ff1000 0x0 0x1000>; >> }; >> scmi_shm_2: sram@47ff2000 { >> compatible =3D "arm,scmi-shmem"; >> reg =3D <0x0 0x47ff2000 0x0 0x1000>; >> }; >> scmi_shm_3: sram@47ff3000 { >> compatible =3D "arm,scmi-shmem"; >> reg =3D <0x0 0x47ff3000 0x0 0x1000>; >> }; >> } >> where first item is "agent_id", second - "arm,smc-id", and third - "arm= ,scmi-shmem" for >> this agent_id. >>=20 >> Note that Xen is the only one entry in the system which need to know >> about SCMI multi-agent support. >>=20 >> - It implements the SCI subsystem interface required for configuring and >> enabling SCMI functionality for Dom0/hwdom and Guest domains. To enable >> SCMI functionality for domain it has to be configured with unique suppor= ted >> SCMI Agent_id and use corresponding SCMI SMC/HVC shared memory transport >> [smc-id, shmem] defined for this SCMI Agent_id. >> - Once Xen domain is configured it can communicate with EL3 SCMI FW: >> -- zero-copy, the guest domain puts SCMI message in shmem; >> -- the guest triggers SMC/HVC exception with smc-id (doorbell); >> -- the Xen driver catches exception, do checks and synchronously forwar= ds >> it to EL3 FW. >> - the Xen driver sends BASE_RESET_AGENT_CONFIGURATION message to Xen >> management agent channel on domain destroy event. This allows to reset >> resources used by domain and so implement use-case like domain reboot. >>=20 >> Dom0 Enable SCMI SMC: >> - pass dom0_scmi_agent_id=3D in Xen command line. if not provi= ded >> SCMI will be disabled for Dom0 and all SCMI nodes removed from Dom0 DT= . >> The driver updates Dom0 DT SCMI node "arm,smc-id" value and fix up shm= em >> node according to assigned agent_id. >>=20 >> Guest domains enable SCMI SMC: >> - xl.cfg: add configuration option as below >>=20 >> arm_sci =3D "type=3Dscmi_smc_multiagent,agent_id=3D2" >>=20 >> - xl.cfg: enable access to the "arm,scmi-shmem" which should correspond = assigned agent_id for >> the domain, for example: >>=20 >> iomem =3D [ >> "47ff2,1@22001", >> ] >=20 > Looking at the code and the configuration options, it looks like it is > possible to map a scmi-shmem channel at a different address for the > guest. It seems like it would work. Is that correct? >=20 >=20 >> - DT: add SCMI nodes to the Driver domain partial device tree as in the >> below example. The "arm,smc-id" should correspond assigned agent_id for = the domain: >>=20 >> passthrough { >> scmi_shm_0: sram@22001000 { >> compatible =3D "arm,scmi-shmem"; >> reg =3D <0x0 0x22001000 0x0 0x1000>; >> }; >>=20 >> firmware { >> compatible =3D "simple-bus"; >> scmi: scmi { >> compatible =3D "arm,scmi-smc"; >> arm,smc-id =3D <0x82000004>; >> shmem =3D <&scmi_shm_0>; >> ... >> } >> } >> } >>=20 >> SCMI "4.2.1.1 Device specific access control" >>=20 >> The XEN SCI SCMI SMC multi-agent driver performs "access-controller" pro= vider function >> in case EL3 SCMI FW implements SCMI "4.2.1.1 Device specific access cont= rol" and provides the >> BASE_SET_DEVICE_PERMISSIONS command to configure the devices that an age= nts have access to. >> The DT SCMI node should "#access-controller-cells=3D<1>" property and DT= devices should be bound >> to the Xen SCMI. >>=20 >> &i2c1 { >> access-controllers =3D <&scmi 0>; >> }; >>=20 >> The Dom0 and dom0less domains DT devices will be processed automatically= through >> sci_assign_dt_device() call, but to assign SCMI devices from toolstack t= he xl.cfg:"dtdev" property >> shell be used: >>=20 >> dtdev =3D [ >> "/soc/i2c@e6508000", >> ] >>=20 >> xl.cfg:dtdev will contain all nodes which are under SCMI management (not= only those which are behind IOMMU). >>=20 >> [1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.g= it/tree/Documentation/devicetree/bindings/firmware/arm,scmi.yaml >> [2] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.g= it/tree/Documentation/devicetree/bindings/access-controllers/access-control= lers.yaml >> Signed-off-by: Oleksii Moisieiev >> Signed-off-by: Grygorii Strashko >=20 > Thanks for the long explanation, great work! I am really looking forward > to have this feature in the tree soon. >=20 >=20 >> --- >>=20 >> Changes in v4: >> - toolstack comments from Anthony PERARD >> - added dom0less support >> - added doc for "xen,scmi-secondary-agents" >>=20 >> docs/man/xl.cfg.5.pod.in | 13 + >> docs/misc/arm/device-tree/booting.txt | 60 ++ >> docs/misc/xen-command-line.pandoc | 9 + >> tools/libs/light/libxl_arm.c | 4 + >> tools/libs/light/libxl_types.idl | 4 +- >> tools/xl/xl_parse.c | 12 + >> xen/arch/arm/dom0less-build.c | 11 + >> xen/arch/arm/domain_build.c | 3 +- >> xen/arch/arm/firmware/Kconfig | 11 + >> xen/arch/arm/firmware/Makefile | 1 + >> xen/arch/arm/firmware/scmi-proto.h | 164 ++++ >> xen/arch/arm/firmware/scmi-shmem.c | 173 ++++ >> xen/arch/arm/firmware/scmi-shmem.h | 45 + >> xen/arch/arm/firmware/scmi-smc-multiagent.c | 860 ++++++++++++++++++++ >> xen/include/public/arch-arm.h | 3 + >> 15 files changed, 1371 insertions(+), 2 deletions(-) >> create mode 100644 xen/arch/arm/firmware/scmi-proto.h >> create mode 100644 xen/arch/arm/firmware/scmi-shmem.c >> create mode 100644 xen/arch/arm/firmware/scmi-shmem.h >> create mode 100644 xen/arch/arm/firmware/scmi-smc-multiagent.c >>=20 >> diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in >> index 1ccf50b8ea..302c46d8bc 100644 >> --- a/docs/man/xl.cfg.5.pod.in >> +++ b/docs/man/xl.cfg.5.pod.in >> @@ -3122,8 +3122,21 @@ single SCMI OSPM agent support. >> Should be used together with B Xen command li= ne >> option. >>=20 >> +=3Ditem B >> + >> +Enables ARM SCMI SMC multi-agent support for the guest by enabling SCMI= over >> +SMC calls forwarding from domain to the EL3 firmware (like Trusted Firm= ware-A) >> +with a multi SCMI OSPM agent support. The SCMI B should be >> +specified for the guest. >> + >> =3Dback >>=20 >> +=3Ditem B >> + >> +Specifies a non-zero ARM SCI agent id for the guest. This option is man= datory >> +if the SCMI SMC support is enabled for the guest. The agent ids of doma= ins >> +existing on a single host must be unique and in the range [1..255]. >> + >> =3Dback >>=20 >> =3Dback >> diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/devic= e-tree/booting.txt >> index 8943c04173..c8923ab8b2 100644 >> --- a/docs/misc/arm/device-tree/booting.txt >> +++ b/docs/misc/arm/device-tree/booting.txt >> @@ -296,6 +296,20 @@ with the following properties: >> Should be used together with dom0_scmi_smc_passthrough Xen command l= ine >> option. >>=20 >> + - "scmi_smc_multiagent" >> + >> + Enables ARM SCMI SMC multi-agent support for the guest by enabling = SCMI over >> + SMC calls forwarding from domain to the EL3 firmware (like ARM >> + Trusted Firmware-A) with a multi SCMI OSPM agent support. >> + The SCMI agent_id should be specified for the guest with "xen,sci_a= gent_id" >> + property. >> + >> +- "xen,sci_agent_id" >> + >> + Specifies a non-zero ARM SCI agent id for the guest. This option is >> + mandatory if the SCMI SMC "scmi_smc_multiagent" support is enabled = for >> + the guest. The agent ids of guest must be unique and in the range [= 1..255]. >> + >> Under the "xen,domain" compatible node, one or more sub-nodes are presen= t >> for the DomU kernel and ramdisk. >>=20 >> @@ -764,3 +778,49 @@ The automatically allocated static shared memory wi= ll get mapped at >> 0x80000000 in DomU1 guest physical address space, and at 0x90000000 in D= omU2 >> guest physical address space. DomU1 is explicitly defined as the owner d= omain, >> and DomU2 is the borrower domain. >> + >> +SCMI SMC multi-agent support >> +=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 >> + >> +For enabling the ARM SCMI SMC multi-agent support (enabled by CONFIG_SC= MI_SMC_MA) >> +the Xen specific SCMI Agent's configuration shell be provided in the Ho= st DT >> +according to the SCMI compliant EL3 Firmware specification with >> +ARM SMC/HVC transport using property "xen,scmi-secondary-agents" under >> +the top-level "chosen" node: >> + >> +- xen,scmi-secondary-agents >> + >> + Defines a set of SCMI agents configuration supported by SCMI EL3 FW= and >> + available for Xen. Each Agent defined as triple consisting of: >> + SCMI agent_id, >> + SMC/HVC function_id assigned for the agent transport ("arm,smc-id")= , >> + phandle to SCMI SHM assigned for the agent transport ("arm,scmi-shm= em"). >> + >> +As an example: >> + >> +chosen { >> + xen,scmi-secondary-agents =3D < >> + 1 0x82000003 &scmi_shm_1 >> + 2 0x82000004 &scmi_shm_2 >> + 3 0x82000005 &scmi_shm_3 >> + 4 0x82000006 &scmi_shm_4>; >> +} >=20 > NIT: it should be }; >=20 > Looking at scmi_probe, collect_agents, and the following SCMI > SCMI_BASE_DISCOVER_AGENT request, I wonder: do we actually need this > information? >=20 > It looks like we can discover the agend_ids for every channel, I guess > what we need to know is the shmem location for every channel? But the > full list of shmem channel is available below thanks to the scmi-shmem > nodes. >=20 > So, we have the list of scmi-shmem anyway, and we can probe the > agent_id. The only parameter left is the smc_id/func_id. >=20 > Or maybe smc_id/func_id can be calculated from agent_id? >=20 > I am asking mostly because if a user is supposed to add this > xen,scmi-secondary-agents property, where are they supposed to find the > smc_id/func_id information? >=20 > It is important that we write down in this document how the user is > expected to find out what 1 is 0x82000003 which is scmi_shm_1. >=20 >=20 >> +/{ >> + scmi_shm_1: sram@47ff1000 { >> + compatible =3D "arm,scmi-shmem"; >> + reg =3D <0x0 0x47ff1000 0x0 0x1000>; >> + }; >> + scmi_shm_2: sram@47ff2000 { >> + compatible =3D "arm,scmi-shmem"; >> + reg =3D <0x0 0x47ff2000 0x0 0x1000>; >> + }; >> + scmi_shm_3: sram@47ff3000 { >> + compatible =3D "arm,scmi-shmem"; >> + reg =3D <0x0 0x47ff3000 0x0 0x1000>; >> + }; >> + scmi_shm_3: sram@47ff4000 { >> + compatible =3D "arm,scmi-shmem"; >> + reg =3D <0x0 0x47ff4000 0x0 0x1000>; >> + }; >=20 > Are these scmi_shm_1 - scmi_shm_3 under the top level device tree node? > Or are under /firmware? Or are they under /chosen? >=20 > I take they are under the top level node together with scmi_shm_0? >=20 > Can you please also clarify in the document as well? >=20 >=20 >> +} >> diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-l= ine.pandoc >> index 8e50f6b7c7..bc3c64d6ec 100644 >> --- a/docs/misc/xen-command-line.pandoc >> +++ b/docs/misc/xen-command-line.pandoc >> @@ -1091,6 +1091,15 @@ which serves as Driver domain. The SCMI will be d= isabled for Dom0/hwdom and >> SCMI nodes removed from Dom0/hwdom device tree. >> (for example, thin Dom0 with Driver domain use-case). >>=20 >> +### dom0_scmi_agent_id (ARM) >> +> `=3D ` >> + >> +The option is available when `CONFIG_SCMI_SMC_MA` is compiled in, and a= llows to >> +enable SCMI functionality for Dom0 by specifying a non-zero ARM SCMI ag= ent id. >> +The SCMI will be disabled for Dom0 if this option is not specified >> +(for example, thin Dom0 or dom0less use-cases). >> +The agent ids of domains existing on a single host must be unique. >> + >> ### dtuart (ARM) >>> `=3D path [:options]` >>=20 >> diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c >> index 28ba9eb787..7712f53cd4 100644 >> --- a/tools/libs/light/libxl_arm.c >> +++ b/tools/libs/light/libxl_arm.c >> @@ -229,6 +229,10 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc= , >> case LIBXL_ARM_SCI_TYPE_SCMI_SMC: >> config->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC= ; >> break; >> + case LIBXL_ARM_SCI_TYPE_SCMI_SMC_MULTIAGENT: >> + config->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SM= C_MA; >> + config->arch.arm_sci_agent_id =3D d_config->b_info.arch_arm.arm= _sci.agent_id; >> + break; >> default: >> LOG(ERROR, "Unknown ARM_SCI type %d", >> d_config->b_info.arch_arm.arm_sci.type); >> diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_t= ypes.idl >> index aa2190ab5b..11e31ce786 100644 >> --- a/tools/libs/light/libxl_types.idl >> +++ b/tools/libs/light/libxl_types.idl >> @@ -553,11 +553,13 @@ libxl_sve_type =3D Enumeration("sve_type", [ >>=20 >> libxl_arm_sci_type =3D Enumeration("arm_sci_type", [ >> (0, "none"), >> - (1, "scmi_smc") >> + (1, "scmi_smc"), >> + (2, "scmi_smc_multiagent") >> ], init_val =3D "LIBXL_ARM_SCI_TYPE_NONE") >>=20 >> libxl_arm_sci =3D Struct("arm_sci", [ >> ("type", libxl_arm_sci_type), >> + ("agent_id", uint8) >> ]) >>=20 >> libxl_rdm_reserve =3D Struct("rdm_reserve", [ >> diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c >> index bd22be9d33..81aa3797e3 100644 >> --- a/tools/xl/xl_parse.c >> +++ b/tools/xl/xl_parse.c >> @@ -1306,6 +1306,18 @@ static int parse_arm_sci_config(XLU_Config *cfg, = libxl_arm_sci *arm_sci, >> } >> } >>=20 >> + if (MATCH_OPTION("agent_id", ptr, oparg)) { >> + unsigned long val =3D parse_ulong(oparg); >> + >> + if (!val || val > 255) { >> + fprintf(stderr, "An invalid ARM_SCI agent_id specified = (%lu). Valid range [1..255]\n", >> + val); >> + ret =3D ERROR_INVAL; >> + goto parse_error; >> + } >> + arm_sci->agent_id =3D val; >> + } >> + >> ptr =3D strtok(NULL, ","); >> } >>=20 >> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build= .c >> index 0a00f03a25..43d21eb889 100644 >> --- a/xen/arch/arm/dom0less-build.c >> +++ b/xen/arch/arm/dom0less-build.c >> @@ -835,6 +835,17 @@ int __init domu_dt_sci_parse(struct dt_device_node = *node, >> d_cfg->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE; >> else if ( !strcmp(sci_type, "scmi_smc") ) >> d_cfg->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC; >> + else if ( !strcmp(sci_type, "scmi_smc_multiagent") ) >> + { >> + uint32_t agent_id =3D 0; >> + >> + if ( !dt_property_read_u32(node, "xen,sci_agent_id", &agent_id)= || >> + !agent_id ) >=20 > shouldn't we check that agent_id <=3D 255 ? >=20 >=20 >> + return -EINVAL; >> + >> + d_cfg->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC= _MA; >> + d_cfg->arch.arm_sci_agent_id =3D agent_id; >> + } >> else >> { >> printk(XENLOG_ERR "xen,sci_type in not valid (%s) for domain %s\= n", >> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c >> index 36d28b52a4..0c9274a2b3 100644 >> --- a/xen/arch/arm/domain_build.c >> +++ b/xen/arch/arm/domain_build.c >> @@ -616,7 +616,8 @@ static int __init write_properties(struct domain *d,= struct kernel_info *kinfo, >> dt_property_name_is_equal(prop, "linux,uefi-mmap-start"= ) || >> dt_property_name_is_equal(prop, "linux,uefi-mmap-size")= || >> dt_property_name_is_equal(prop, "linux,uefi-mmap-desc-s= ize") || >> - dt_property_name_is_equal(prop, "linux,uefi-mmap-desc-= ver")) >> + dt_property_name_is_equal(prop, "linux,uefi-mmap-desc-= ver") || >> + dt_property_name_is_equal(prop, "xen,scmi-secondary-ag= ents") ) >> continue; >>=20 >> if ( dt_property_name_is_equal(prop, "xen,dom0-bootargs") ) >> diff --git a/xen/arch/arm/firmware/Kconfig b/xen/arch/arm/firmware/Kconf= ig >> index 5c5f0880c4..6b051c8ada 100644 >> --- a/xen/arch/arm/firmware/Kconfig >> +++ b/xen/arch/arm/firmware/Kconfig >> @@ -29,6 +29,17 @@ config SCMI_SMC >> driver domain. >> Use with EL3 firmware which supports only single SCMI OSPM agent. >>=20 >> +config SCMI_SMC_MA >> + bool "Enable ARM SCMI SMC multi-agent driver" >> + select ARM_SCI >> + help >> + Enables SCMI SMC/HVC multi-agent in XEN to pass SCMI requests from D= omains >> + to EL3 firmware (TF-A) which supports multi-agent feature. >> + This feature allows to enable SCMI per Domain using unique SCMI agen= t_id, >> + so Domain is identified by EL3 firmware as an SCMI Agent and can acc= ess >> + allowed platform resources through dedicated SMC/HVC Shared memory b= ased >> + transport. >> + >> endchoice >>=20 >> endmenu >> diff --git a/xen/arch/arm/firmware/Makefile b/xen/arch/arm/firmware/Make= file >> index 71bdefc24a..37927e690e 100644 >> --- a/xen/arch/arm/firmware/Makefile >> +++ b/xen/arch/arm/firmware/Makefile >> @@ -1,2 +1,3 @@ >> obj-$(CONFIG_ARM_SCI) +=3D sci.o >> obj-$(CONFIG_SCMI_SMC) +=3D scmi-smc.o >> +obj-$(CONFIG_SCMI_SMC_MA) +=3D scmi-shmem.o scmi-smc-multiagent.o >> diff --git a/xen/arch/arm/firmware/scmi-proto.h b/xen/arch/arm/firmware/= scmi-proto.h >> new file mode 100644 >> index 0000000000..3f4b9c5d6b >> --- /dev/null >> +++ b/xen/arch/arm/firmware/scmi-proto.h >> @@ -0,0 +1,164 @@ >> +/* SPDX-License-Identifier: GPL-2.0-only */ >> +/* >> + * Arm System Control and Management Interface definitions >> + * Version 3.0 (DEN0056C) >> + * >> + * Copyright (c) 2024 EPAM Systems >> + */ >> + >> +#ifndef XEN_ARCH_ARM_SCI_SCMI_PROTO_H_ >> +#define XEN_ARCH_ARM_SCI_SCMI_PROTO_H_ >=20 > NIT: ARM_FIRMWARE_SCMI_PROTO_H >=20 >=20 >> +#include >> + >> +#define SCMI_SHORT_NAME_MAX_SIZE 16 >> + >> +/* SCMI status codes. See section 4.1.4 */ >> +#define SCMI_SUCCESS 0 >> +#define SCMI_NOT_SUPPORTED (-1) >> +#define SCMI_INVALID_PARAMETERS (-2) >> +#define SCMI_DENIED (-3) >> +#define SCMI_NOT_FOUND (-4) >> +#define SCMI_OUT_OF_RANGE (-5) >> +#define SCMI_BUSY (-6) >> +#define SCMI_COMMS_ERROR (-7) >> +#define SCMI_GENERIC_ERROR (-8) >> +#define SCMI_HARDWARE_ERROR (-9) >> +#define SCMI_PROTOCOL_ERROR (-10) >> + >> +/* Protocol IDs */ >> +#define SCMI_BASE_PROTOCOL 0x10 >> + >> +/* Base protocol message IDs */ >> +#define SCMI_BASE_PROTOCOL_VERSION 0x0 >> +#define SCMI_BASE_PROTOCOL_ATTIBUTES 0x1 >> +#define SCMI_BASE_PROTOCOL_MESSAGE_ATTRIBUTES 0x2 >> +#define SCMI_BASE_DISCOVER_AGENT 0x7 >> +#define SCMI_BASE_SET_DEVICE_PERMISSIONS 0x9 >> +#define SCMI_BASE_RESET_AGENT_CONFIGURATION 0xB >> + >> +typedef struct scmi_msg_header { >> + uint8_t id; >> + uint8_t type; >> + uint8_t protocol; >> + uint32_t status; >> +} scmi_msg_header_t; >> + >> +/* Table 2 Message header format */ >> +#define SCMI_HDR_ID GENMASK(7, 0) >> +#define SCMI_HDR_TYPE GENMASK(9, 8) >> +#define SCMI_HDR_PROTO GENMASK(17, 10) >> + >> +#define SCMI_FIELD_GET(_mask, _reg) = \ >> + ((typeof(_mask))(((_reg) & (_mask)) >> (ffs64(_mask) - 1))) >> +#define SCMI_FIELD_PREP(_mask, _val) = \ >> + (((typeof(_mask))(_val) << (ffs64(_mask) - 1)) & (_mask)) >> + >> +static inline uint32_t pack_scmi_header(scmi_msg_header_t *hdr) >> +{ >> + return SCMI_FIELD_PREP(SCMI_HDR_ID, hdr->id) | >> + SCMI_FIELD_PREP(SCMI_HDR_TYPE, hdr->type) | >> + SCMI_FIELD_PREP(SCMI_HDR_PROTO, hdr->protocol); >> +} >> + >> +static inline void unpack_scmi_header(uint32_t msg_hdr, scmi_msg_header= _t *hdr) >> +{ >> + hdr->id =3D SCMI_FIELD_GET(SCMI_HDR_ID, msg_hdr); >> + hdr->type =3D SCMI_FIELD_GET(SCMI_HDR_TYPE, msg_hdr); >> + hdr->protocol =3D SCMI_FIELD_GET(SCMI_HDR_PROTO, msg_hdr); >> +} >> + >> +static inline int scmi_to_xen_errno(int scmi_status) >> +{ >> + if ( scmi_status =3D=3D SCMI_SUCCESS ) >> + return 0; >> + >> + switch ( scmi_status ) >> + { >> + case SCMI_NOT_SUPPORTED: >> + return -EOPNOTSUPP; >> + case SCMI_INVALID_PARAMETERS: >> + return -EINVAL; >> + case SCMI_DENIED: >> + return -EACCES; >> + case SCMI_NOT_FOUND: >> + return -ENOENT; >> + case SCMI_OUT_OF_RANGE: >> + return -ERANGE; >> + case SCMI_BUSY: >> + return -EBUSY; >> + case SCMI_COMMS_ERROR: >> + return -ENOTCONN; >> + case SCMI_GENERIC_ERROR: >> + return -EIO; >> + case SCMI_HARDWARE_ERROR: >> + return -ENXIO; >> + case SCMI_PROTOCOL_ERROR: >> + return -EBADMSG; >> + default: >> + return -EINVAL; >> + } >> +} >> + >> +/* PROTOCOL_VERSION */ >> +#define SCMI_VERSION_MINOR GENMASK(15, 0) >> +#define SCMI_VERSION_MAJOR GENMASK(31, 16) >> + >> +struct scmi_msg_prot_version_p2a { >> + uint32_t version; >> +} __packed; >> + >> +/* BASE PROTOCOL_ATTRIBUTES */ >> +#define SCMI_BASE_ATTR_NUM_PROTO GENMASK(7, 0) >> +#define SCMI_BASE_ATTR_NUM_AGENT GENMASK(15, 8) >> + >> +struct scmi_msg_base_attributes_p2a { >> + uint32_t attributes; >> +} __packed; >> + >> +/* >> + * BASE_DISCOVER_AGENT >> + */ >> +#define SCMI_BASE_AGENT_ID_OWN 0xFFFFFFFF >> + >> +struct scmi_msg_base_discover_agent_a2p { >> + uint32_t agent_id; >> +} __packed; >> + >> +struct scmi_msg_base_discover_agent_p2a { >> + uint32_t agent_id; >> + char name[SCMI_SHORT_NAME_MAX_SIZE]; >> +} __packed; >> + >> +/* >> + * BASE_SET_DEVICE_PERMISSIONS >> + */ >> +#define SCMI_BASE_DEVICE_ACCESS_ALLOW BIT(0, UL) >> + >> +struct scmi_msg_base_set_device_permissions_a2p { >> + uint32_t agent_id; >> + uint32_t device_id; >> + uint32_t flags; >> +} __packed; >> + >> +/* >> + * BASE_RESET_AGENT_CONFIGURATION >> + */ >> +#define SCMI_BASE_AGENT_PERMISSIONS_RESET BIT(0, UL) >> + >> +struct scmi_msg_base_reset_agent_cfg_a2p { >> + uint32_t agent_id; >> + uint32_t flags; >> +} __packed; >> + >> +#endif /* XEN_ARCH_ARM_SCI_SCMI_PROTO_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/arch/arm/firmware/scmi-shmem.c b/xen/arch/arm/firmware/= scmi-shmem.c >> new file mode 100644 >> index 0000000000..dd613ee0b5 >> --- /dev/null >> +++ b/xen/arch/arm/firmware/scmi-shmem.c >> @@ -0,0 +1,173 @@ >> +/* SPDX-License-Identifier: GPL-2.0-only */ >> +/* >> + * SCI SCMI multi-agent driver, using SMC/HVC shmem as transport. >> + * >> + * Oleksii Moisieiev >> + * Copyright (c) 2025 EPAM Systems >> + */ >> +/* SPDX-License-Identifier: GPL-2.0-only */ >> + >> +#include >> +#include >> + >> +#include "scmi-proto.h" >> +#include "scmi-shmem.h" >=20 > This code is written more generically than the description implies. If > we only want to make SMC calls to TF-A on EL3 and exchange data with it > over shared memory, then I think: > - we don't need the __iomem tag, as there is no MMIO agree > - we only need a DMB, not a DSB (readl and writel imply DSB, use only > readl_relaxed and writel_relaxed) agree >=20 > On the other hand, if we also want to handle the case where the SCMI > server could be on a separate co-processor, then what this code is doing > is not sufficient because we also need a dcache flush, in addition to > the DSB. >=20 > Bertrand, can you double-check? If we want to handle a case where the memory is accessible to a coprocessor but there is no cache coherency, we need to flush the dcache definitely. Seeing the amount of data here, I do agree with Stefano that it would be a = good idea to make the provision to flush the data cache in all cases. Even if th= e data is accessed by a secure partition or the firmware coherently, flushing in a= ll cases would have very limited performance impact here. There is the other solution to have some kind of parameter to say if the ac= cessor has coherent cache access but I do not think the performance impact here wo= uld justify such a complexity. Cheers Bertrand >=20 >=20 >> +/* >> + * Copy data from IO memory space to "real" memory space. >> + */ >> +static void __memcpy_fromio(void *to, const volatile void __iomem *from= , >> + size_t count) >> +{ >> + while ( count && !IS_ALIGNED((unsigned long)from, 4) ) >> + { >> + *(u8 *)to =3D readb_relaxed(from); >> + from++; >> + to++; >> + count--; >> + } >> + >> + while ( count >=3D 4 ) >> + { >> + *(u32 *)to =3D readl_relaxed(from); >> + from +=3D 4; >> + to +=3D 4; >> + count -=3D 4; >> + } >> + >> + while ( count ) >> + { >> + *(u8 *)to =3D readb_relaxed(from); >> + from++; >> + to++; >> + count--; >> + } >> +} >> + >> +/* >> + * Copy data from "real" memory space to IO memory space. >> + */ >> +static void __memcpy_toio(volatile void __iomem *to, const void *from, >> + size_t count) >> +{ >> + while ( count && !IS_ALIGNED((unsigned long)to, 4) ) >> + { >> + writeb_relaxed(*(u8 *)from, to); >> + from++; >> + to++; >> + count--; >> + } >> + >> + while ( count >=3D 4 ) >> + { >> + writel_relaxed(*(u32 *)from, to); >> + from +=3D 4; >> + to +=3D 4; >> + count -=3D 4; >> + } >> + >> + while ( count ) >> + { >> + writeb_relaxed(*(u8 *)from, to); >> + from++; >> + to++; >> + count--; >> + } >> +} >=20 > I don't understand why we need __memcpy_fromio and __memcpy_toio: can't > we use a simple memcpy? >=20 >=20 >> +static inline int >> +shmem_channel_is_free(const volatile struct scmi_shared_mem __iomem *sh= mem) >> +{ >> + return (readl(&shmem->channel_status) & >> + SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE) ? 0 : -EBUSY; >> +} >> + >> +int shmem_put_message(volatile struct scmi_shared_mem __iomem *shmem, >> + scmi_msg_header_t *hdr, void *data, int len) >> +{ >> + int ret; >> + >> + if ( (len + sizeof(shmem->msg_header)) > SCMI_SHMEM_MAPPED_SIZE ) >> + { >> + printk(XENLOG_ERR "scmi: Wrong size of smc message. Data is inv= alid\n"); >> + return -EINVAL; >> + } >> + >> + ret =3D shmem_channel_is_free(shmem); >> + if ( ret ) >> + return ret; >> + >> + writel_relaxed(0x0, &shmem->channel_status); >> + /* Writing 0x0 right now, but "shmem"_FLAG_INTR_ENABLED can be set = */ >> + writel_relaxed(0x0, &shmem->flags); >> + writel_relaxed(sizeof(shmem->msg_header) + len, &shmem->length); >> + writel(pack_scmi_header(hdr), &shmem->msg_header); >> + >> + if ( len > 0 && data ) >> + __memcpy_toio(shmem->msg_payload, data, len); >> + >> + return 0; >> +} >> + >> +int shmem_get_response(const volatile struct scmi_shared_mem __iomem *s= hmem, >> + scmi_msg_header_t *hdr, void *data, int len) >> +{ >> + int recv_len; >> + int ret; >> + int pad =3D sizeof(hdr->status); >> + >> + if ( len >=3D SCMI_SHMEM_MAPPED_SIZE - sizeof(shmem) ) >> + { >> + printk(XENLOG_ERR >> + "scmi: Wrong size of input smc message. Data may be inva= lid\n"); >> + return -EINVAL; >> + } >> + >> + ret =3D shmem_channel_is_free(shmem); >> + if ( ret ) >> + return ret; >> + >> + recv_len =3D readl(&shmem->length) - sizeof(shmem->msg_header); >> + >> + if ( recv_len < 0 ) >> + { >> + printk(XENLOG_ERR >> + "scmi: Wrong size of smc message. Data may be invalid\n"= ); >> + return -EINVAL; >> + } >> + >> + unpack_scmi_header(readl(&shmem->msg_header), hdr); >> + >> + hdr->status =3D readl(&shmem->msg_payload); >> + recv_len =3D recv_len > pad ? recv_len - pad : 0; >> + >> + ret =3D scmi_to_xen_errno(hdr->status); >> + if ( ret ) >> + { >> + printk(XENLOG_DEBUG "scmi: Error received: %d\n", ret); >> + return ret; >> + } >> + >> + if ( recv_len > len ) >> + { >> + printk(XENLOG_ERR >> + "scmi: Not enough buffer for message %d, expecting %d\n"= , >> + recv_len, len); >> + return -EINVAL; >> + } >> + >> + if ( recv_len > 0 ) >> + __memcpy_fromio(data, shmem->msg_payload + pad, recv_len); >> + >> + return 0; >> +} >> + >> +/* >> + * 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/firmware/scmi-shmem.h b/xen/arch/arm/firmware/= scmi-shmem.h >> new file mode 100644 >> index 0000000000..2f8e23ff76 >> --- /dev/null >> +++ b/xen/arch/arm/firmware/scmi-shmem.h >> @@ -0,0 +1,45 @@ >> +/* SPDX-License-Identifier: GPL-2.0-only */ >> +/* >> + * Arm System Control and Management Interface definitions >> + * Version 3.0 (DEN0056C) >> + * Shared Memory based Transport >> + * >> + * Copyright (c) 2024 EPAM Systems >> + */ >> + >> +#ifndef XEN_ARCH_ARM_SCI_SCMI_SHMEM_H_ >> +#define XEN_ARCH_ARM_SCI_SCMI_SHMEM_H_ >=20 > NIT: ARM_FIRMWARE_SCMI_SHMEM_H >=20 >=20 >> +#include >> + >> +#define SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE BIT(0, UL) >> +#define SCMI_SHMEM_CHAN_STAT_CHANNEL_ERROR BIT(1, UL) >> + >> +struct scmi_shared_mem { >> + uint32_t reserved; >> + uint32_t channel_status; >> + uint32_t reserved1[2]; >> + uint32_t flags; >> + uint32_t length; >> + uint32_t msg_header; >> + uint8_t msg_payload[]; >> +}; >> + >> +#define SCMI_SHMEM_MAPPED_SIZE PAGE_SIZE >> + >> +int shmem_put_message(volatile struct scmi_shared_mem __iomem *shmem, >> + scmi_msg_header_t *hdr, void *data, int len); >> + >> +int shmem_get_response(const volatile struct scmi_shared_mem __iomem *s= hmem, >> + scmi_msg_header_t *hdr, void *data, int len); >> +#endif /* XEN_ARCH_ARM_SCI_SCMI_SHMEM_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/arch/arm/firmware/scmi-smc-multiagent.c b/xen/arch/arm/= firmware/scmi-smc-multiagent.c >> new file mode 100644 >> index 0000000000..e023bca3a1 >> --- /dev/null >> +++ b/xen/arch/arm/firmware/scmi-smc-multiagent.c >> @@ -0,0 +1,860 @@ >> +/* SPDX-License-Identifier: GPL-2.0-only */ >> +/* >> + * SCI SCMI multi-agent driver, using SMC/HVC shmem as transport. >> + * >> + * Oleksii Moisieiev >> + * Copyright (c) 2025 EPAM Systems >> + */ >> + >> +#include >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#include >> +#include >> + >> +#include "scmi-proto.h" >> +#include "scmi-shmem.h" >> + >> +#define SCMI_AGENT_ID_INVALID 0xFF >> + >> +static uint8_t __initdata opt_dom0_scmi_agent_id =3D SCMI_AGENT_ID_INVA= LID; >> +integer_param("dom0_scmi_agent_id", opt_dom0_scmi_agent_id); >> + >> +#define SCMI_SECONDARY_AGENTS "xen,scmi-secondary-agents" >> + >> +#define HYP_CHANNEL 0x0 >> + >> +struct scmi_channel { >> + uint32_t agent_id; >> + uint32_t func_id; >> + domid_t domain_id; >> + uint64_t paddr; >> + uint64_t len; >> + struct scmi_shared_mem __iomem *shmem; >> + spinlock_t lock; >> + struct list_head list; >> +}; >> + >> +struct scmi_data { >> + struct list_head channel_list; >> + spinlock_t channel_list_lock; >> + uint32_t func_id; >> + bool initialized; >> + uint32_t shmem_phandle; >> + struct dt_device_node *dt_dev; >> +}; >> + >> +static struct scmi_data scmi_data; >> + >> +static int send_smc_message(struct scmi_channel *chan_info, >> + scmi_msg_header_t *hdr, void *data, int len= ) >> +{ >> + struct arm_smccc_res resp; >> + int ret; >> + >> + ret =3D shmem_put_message(chan_info->shmem, hdr, data, len); >> + if ( ret ) >> + return ret; >> + >> + arm_smccc_1_1_smc(chan_info->func_id, 0, 0, 0, 0, 0, 0, 0, &resp); >> + >> + if ( resp.a0 ) >> + return -EOPNOTSUPP; >=20 > Why if repo.a0 !=3D 0 then we assume -EOPNOTSUPP? Is this part of the SCM= I > specification? >=20 >=20 >> + return 0; >> +} >> + >> +static int do_smc_xfer(struct scmi_channel *chan_info, scmi_msg_header_= t *hdr, >> + void *tx_data, int tx_size, void *rx_data, int r= x_size) >> +{ >> + int ret =3D 0; >> + >> + ASSERT(chan_info && chan_info->shmem); >> + >> + if ( !hdr ) >> + return -EINVAL; >> + >> + spin_lock(&chan_info->lock); >> + >> + printk(XENLOG_DEBUG >> + "scmi: agent_id =3D %d msg_id =3D %x type =3D %d, proto =3D = %x\n", >> + chan_info->agent_id, hdr->id, hdr->type, hdr->protocol); >> + >> + ret =3D send_smc_message(chan_info, hdr, tx_data, tx_size); >> + if ( ret ) >> + goto clean; >> + >> + ret =3D shmem_get_response(chan_info->shmem, hdr, rx_data, rx_size)= ; >> + >> +clean: >> + printk(XENLOG_DEBUG >> + "scmi: get smc response agent_id =3D %d msg_id =3D %x proto = =3D %x res=3D%d\n", >> + chan_info->agent_id, hdr->id, hdr->protocol, ret); >> + >> + spin_unlock(&chan_info->lock); >> + >> + return ret; >> +} >> + >> +static struct scmi_channel *get_channel_by_id(uint32_t agent_id) >> +{ >> + struct scmi_channel *curr; >> + bool found =3D false; >> + >> + spin_lock(&scmi_data.channel_list_lock); >> + list_for_each_entry(curr, &scmi_data.channel_list, list) >> + { >> + if ( curr->agent_id =3D=3D agent_id ) >> + { >> + found =3D true; >> + break; >> + } >> + } >> + >> + spin_unlock(&scmi_data.channel_list_lock); >> + if ( found ) >> + return curr; >> + >> + return NULL; >> +} >> + >> +static struct scmi_channel *acquire_scmi_channel(struct domain *d, >> + uint32_t agent_id) >> +{ >> + struct scmi_channel *curr; >> + struct scmi_channel *ret =3D ERR_PTR(-ENOENT); >> + >> + spin_lock(&scmi_data.channel_list_lock); >> + list_for_each_entry(curr, &scmi_data.channel_list, list) >> + { >> + if ( curr->agent_id =3D=3D agent_id ) >> + { >> + if ( curr->domain_id !=3D DOMID_INVALID ) >> + { >> + ret =3D ERR_PTR(-EEXIST); >> + break; >> + } >> + >> + curr->domain_id =3D d->domain_id; >> + ret =3D curr; >> + break; >> + } >> + } >> + >> + spin_unlock(&scmi_data.channel_list_lock); >> + >> + return ret; >> +} >> + >> +static void relinquish_scmi_channel(struct scmi_channel *channel) >> +{ >> + ASSERT(channel !=3D NULL); >> + >> + spin_lock(&scmi_data.channel_list_lock); >> + channel->domain_id =3D DOMID_INVALID; >> + spin_unlock(&scmi_data.channel_list_lock); >> +} >> + >> +static int map_channel_memory(struct scmi_channel *channel) >> +{ >> + ASSERT(channel && channel->paddr); >> + channel->shmem =3D ioremap_nocache(channel->paddr, SCMI_SHMEM_MAPPE= D_SIZE); >=20 > ioremap is for MMIO, if these shared memory channels are on DDR, then it > would not be the right call. Are the "arm,scmi-shmem" address ranges > part of the memory node ranges? Or are they completely separate? >=20 > Also, why nocache? Wouldn't we want ioremap_cache? >=20 >=20 >> + if ( !channel->shmem ) >> + return -ENOMEM; >> + >> + channel->shmem->channel_status =3D SCMI_SHMEM_CHAN_STAT_CHANNEL_FRE= E; >> + printk(XENLOG_DEBUG "scmi: Got shmem %lx after vmap %p\n", channel-= >paddr, >> + channel->shmem); >> + >> + return 0; >> +} >> + >> +static void unmap_channel_memory(struct scmi_channel *channel) >> +{ >> + ASSERT(channel && channel->shmem); >> + iounmap(channel->shmem); >> + channel->shmem =3D NULL; >> +} >> + >> +static struct scmi_channel *smc_create_channel(uint32_t agent_id, >> + uint32_t func_id, uint64= _t addr) >> +{ >> + struct scmi_channel *channel; >> + >> + channel =3D get_channel_by_id(agent_id); >> + if ( channel ) >> + return ERR_PTR(EEXIST); >> + >> + channel =3D xmalloc(struct scmi_channel); >> + if ( !channel ) >> + return ERR_PTR(ENOMEM); >> + >> + spin_lock_init(&channel->lock); >> + channel->agent_id =3D agent_id; >> + channel->func_id =3D func_id; >> + channel->domain_id =3D DOMID_INVALID; >> + channel->shmem =3D NULL; >> + channel->paddr =3D addr; >> + list_add_tail(&channel->list, &scmi_data.channel_list); >> + return channel; >> +} >> + >> +static void free_channel_list(void) >> +{ >> + struct scmi_channel *curr, *_curr; >> + >> + list_for_each_entry_safe(curr, _curr, &scmi_data.channel_list, list= ) >> + { >> + list_del(&curr->list); >> + xfree(curr); >> + } >> +} >> + >> +static int __init >> +scmi_dt_read_hyp_channel_addr(struct dt_device_node *scmi_node, u64 *ad= dr, >> + u64 *size) >> +{ >> + struct dt_device_node *shmem_node; >> + const __be32 *prop; >> + >> + prop =3D dt_get_property(scmi_node, "shmem", NULL); >> + if ( !prop ) >> + return -EINVAL; >> + >> + shmem_node =3D dt_find_node_by_phandle(be32_to_cpup(prop)); >> + if ( IS_ERR_OR_NULL(shmem_node) ) >> + { >> + printk(XENLOG_ERR >> + "scmi: Device tree error, can't parse reserved memory %l= d\n", >> + PTR_ERR(shmem_node)); >> + return PTR_ERR(shmem_node); >> + } >> + >> + return dt_device_get_address(shmem_node, 0, addr, size); >> +} >> + >> +/* >> + * Handle Dom0 SCMI specific DT nodes >> + * >> + * Make a decision on copying SCMI specific nodes into Dom0 device tree= . >> + * For SCMI multi-agent case: >> + * - shmem nodes will not be copied and generated instead if SCMI >> + * is enabled for Dom0 >> + * - scmi node will be copied if SCMI is enabled for Dom0 >> + */ >> +static bool scmi_dt_handle_node(struct domain *d, struct dt_device_node= *node) >> +{ >> + static const struct dt_device_match skip_matches[] __initconst =3D = { >> + DT_MATCH_COMPATIBLE("arm,scmi-shmem"), >> + { /* sentinel */ }, >> + }; >> + static const struct dt_device_match scmi_matches[] __initconst =3D = { >> + DT_MATCH_PATH("/firmware/scmi"), >> + { /* sentinel */ }, >> + }; >> + >> + if ( !scmi_data.initialized ) >> + return false; >> + >> + /* always drop shmem */ >> + if ( dt_match_node(skip_matches, node) ) >> + { >> + dt_dprintk(" Skip scmi shmem\n"); >> + return true; >> + } >> + >> + /* drop scmi if not enabled */ >> + if ( dt_match_node(scmi_matches, node) && !sci_domain_is_enabled(d)= ) >> + { >> + dt_dprintk(" Skip scmi node\n"); >> + return true; >> + } >> + >> + return false; >> +} >> + >> +/* >> + * Finalize Dom0 SCMI specific DT nodes >> + * >> + * if SCMI is enabled for Dom0: >> + * - generate shmem node >> + * - map SCMI shmem MMIO into Dom0 >> + */ >> +static int scmi_dt_finalize(struct domain *d, void *fdt) >> +{ >> + __be32 reg[GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS]; >> + struct scmi_channel *channel; >> + int nodeoffset; >> + __be32 *cells; >> + __be32 val; >> + char buf[64]; >> + int res, rc; >> + >> + if ( !sci_domain_is_enabled(d) ) >> + return 0; >> + >> + channel =3D d->arch.sci_data; >> + >> + /* >> + * Replace "arm,smc-id" with proper value assigned for Dom0 SCMI ch= annel >> + */ >> + nodeoffset =3D fdt_node_offset_by_compatible(fdt, -1, "arm,scmi-smc= "); >> + if ( nodeoffset < 0 ) >> + return -ENODEV; >> + >> + cells =3D (__be32 *)&val; >> + dt_set_cell(&cells, 1, channel->func_id); >> + res =3D fdt_setprop_inplace(fdt, nodeoffset, "arm,smc-id", &val, si= zeof(val)); >> + if ( res ) >> + return -EINVAL; >> + >=20 > Are you sure it is worth to go through all this trouble to modify FDT in > place when we could simply generate the DT node from scratch like we do > for example for the GIC? This seems to be more error prone as well. Is > generating it from scratch is really difficult? If it is difficult then O= K. >=20 >=20 >> + /* >> + * All SCMI shmem nodes should be removed from Dom0 DT at this poin= t, so >> + * the shmem node for Dom0 need to be generated from SCMI channel a= ssigned >> + * to Dom0. >> + * The original SCMI shmem node from platform DT is used by Xen SCM= I driver >> + * itself as privileged channel (agent_id=3D0) to manage other SCMI >> + * agents (domains). >> + */ >> + snprintf(buf, sizeof(buf), "scmi-shmem@%lx", channel->paddr); >> + >> + res =3D fdt_begin_node(fdt, buf); >> + if ( res ) >> + return res; >> + >> + res =3D fdt_property_string(fdt, "compatible", "arm,scmi-shmem"); >> + if ( res ) >> + return res; >> + >> + cells =3D ®[0]; >> + >> + dt_child_set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZ= E_CELLS, >> + channel->paddr, SCMI_SHMEM_MAPPED_SIZE); >> + >> + res =3D fdt_property(fdt, "reg", reg, sizeof(reg)); >> + if ( res ) >> + return res; >> + >> + res =3D fdt_property_cell(fdt, "phandle", scmi_data.shmem_phandle); >> + if ( res ) >> + return res; >> + >> + res =3D fdt_end_node(fdt); >> + if ( res ) >> + return res; >> + >> + /* >> + * Map SCMI shmem into Dom0 here as shmem nodes are excluded from >> + * generic Dom0 DT processing >> + */ >> + res =3D iomem_permit_access(d, paddr_to_pfn(channel->paddr), >> + paddr_to_pfn(channel->paddr + >> + SCMI_SHMEM_MAPPED_SIZE - 1))= ; >> + if ( res ) >> + return res; >> + >> + res =3D map_regions_p2mt(d, gaddr_to_gfn(channel->paddr), >> + PFN_UP(SCMI_SHMEM_MAPPED_SIZE), >> + maddr_to_mfn(channel->paddr), p2m_mmio_direc= t_nc); >> + if ( res ) >> + { >> + rc =3D iomem_deny_access(d, paddr_to_pfn(channel->paddr), >> + paddr_to_pfn(channel->paddr + >> + SCMI_SHMEM_MAPPED_SIZE - 1)= ); >> + if ( rc ) >> + printk(XENLOG_ERR "scmi: Unable to deny iomem access , err = =3D %d\n", >> + rc); >> + } >> + >> + return res; >> +} >> + >> +static int scmi_assign_device(uint32_t agent_id, uint32_t device_id, >> + uint32_t flags) >> +{ >> + struct scmi_msg_base_set_device_permissions_a2p tx; >> + struct scmi_channel *channel; >> + scmi_msg_header_t hdr; >> + int ret; >> + >> + channel =3D get_channel_by_id(HYP_CHANNEL); >> + if ( !channel ) >> + return -EINVAL; >> + >> + hdr.id =3D SCMI_BASE_SET_DEVICE_PERMISSIONS; >> + hdr.type =3D 0; >> + hdr.protocol =3D SCMI_BASE_PROTOCOL; >> + >> + tx.agent_id =3D agent_id; >> + tx.device_id =3D device_id; >> + tx.flags =3D flags; >> + >> + ret =3D do_smc_xfer(channel, &hdr, &tx, sizeof(tx), NULL, 0); >> + if ( ret =3D=3D -EOPNOTSUPP ) >> + return 0; >=20 > Is it actually OK to pretend that everything worked if the return is > -EOPNOTSUPP? I mean that in this case can we assume that the device is > actually assigned anyway? Wouldn't follow up SCMI operations on this > device fail? >=20 >=20 >> + return ret; >> +} >> + >> +static int scmi_dt_assign_device(struct domain *d, >> + struct dt_phandle_args *ac_spec) >> +{ >> + struct scmi_channel *agent_channel; >> + uint32_t scmi_device_id =3D ac_spec->args[0]; >> + int ret; >> + >> + if ( !d->arch.sci_data ) >> + return 0; >> + >> + /* The access-controllers is specified for DT dev, but it's not a S= CMI */ >> + if ( ac_spec->np !=3D scmi_data.dt_dev ) >> + return 0; >=20 > I wonder if this should be an error >=20 >=20 >> + agent_channel =3D d->arch.sci_data; >> + >> + spin_lock(&agent_channel->lock); >> + >> + ret =3D scmi_assign_device(agent_channel->agent_id, scmi_device_id, >> + SCMI_BASE_DEVICE_ACCESS_ALLOW); >> + if ( ret ) >> + { >> + printk(XENLOG_ERR >> + "scmi: could not assign dev for %pd agent:%d dev_id:%u (= %d)", >> + d, agent_channel->agent_id, scmi_device_id, ret); >> + } >> + >> + spin_unlock(&agent_channel->lock); >> + return ret; >> +} >> + >> +static __init int collect_agents(struct dt_device_node *scmi_node) >> +{ >> + const struct dt_device_node *chosen_node; >> + const __be32 *prop; >> + uint32_t len, i; >> + >> + chosen_node =3D dt_find_node_by_path("/chosen"); >> + if ( !chosen_node ) >> + { >> + printk(XENLOG_ERR "scmi: chosen node not found\n"); >> + return -ENOENT; >> + } >> + >> + prop =3D dt_get_property(chosen_node, SCMI_SECONDARY_AGENTS, &len); >> + if ( !prop ) >> + { >> + printk(XENLOG_WARNING "scmi: No %s property found\n", >> + SCMI_SECONDARY_AGENTS); >> + return -ENODEV; >> + } >> + >> + if ( len % (3 * sizeof(uint32_t)) ) >> + { >> + printk(XENLOG_ERR "scmi: Invalid length of %s property: %d\n", >> + SCMI_SECONDARY_AGENTS, len); >> + return -EINVAL; >> + } >> + >> + for ( i =3D 0; i < len / (3 * sizeof(uint32_t)); i++ ) >> + { >> + uint32_t agent_id =3D be32_to_cpu(*prop++); >> + uint32_t smc_id =3D be32_to_cpu(*prop++); >> + uint32_t shmem_phandle =3D be32_to_cpu(*prop++); >> + struct dt_device_node *node =3D dt_find_node_by_phandle(shmem_p= handle); >> + u64 addr, size; >> + int ret; >> + >> + if ( !node ) >> + { >> + printk(XENLOG_ERR "scmi: Could not find shmem node for agen= t %d\n", >> + agent_id); >> + return -EINVAL; >> + } >> + >> + ret =3D dt_device_get_address(node, 0, &addr, &size); >> + if ( ret ) >> + { >> + printk(XENLOG_ERR >> + "scmi: Could not read shmem address for agent %d: %d= ", >> + agent_id, ret); >> + return ret; >> + } >> + >> + if ( !IS_ALIGNED(size, SCMI_SHMEM_MAPPED_SIZE) ) >> + { >> + printk(XENLOG_ERR "scmi: shmem memory is not aligned\n"); >> + return -EINVAL; >> + } >> + >> + ret =3D PTR_RET(smc_create_channel(agent_id, smc_id, addr)); >> + if ( ret ) >> + { >> + printk(XENLOG_ERR "scmi: Could not create channel for agent= %d: %d", >> + agent_id, ret); >> + return ret; >> + } >> + >> + printk(XENLOG_DEBUG "scmi: Agent %d SMC %X addr %lx\n", agent_i= d, >> + smc_id, addr); >> + } >> + >> + return 0; >> +} >> + >> +static int scmi_domain_init(struct domain *d, >> + struct xen_domctl_createdomain *config) >> +{ >> + struct scmi_channel *channel; >> + int ret; >> + >> + if ( !scmi_data.initialized ) >> + return 0; >> + >> + /* >> + * Special case for Dom0 - the SCMI support is enabled basing on >> + * "dom0_sci_agent_id" Xen command line parameter >> + */ >> + if ( is_hardware_domain(d) ) >> + { >> + if ( opt_dom0_scmi_agent_id !=3D SCMI_AGENT_ID_INVALID ) >> + { >> + config->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_SCM= I_SMC_MA; >> + config->arch.arm_sci_agent_id =3D opt_dom0_scmi_agent_id; >> + } >> + else >> + config->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_NON= E; >> + } >> + >> + if ( config->arch.arm_sci_type =3D=3D XEN_DOMCTL_CONFIG_ARM_SCI_NON= E ) >> + return 0; >> + >> + channel =3D acquire_scmi_channel(d, config->arch.arm_sci_agent_id); >> + if ( IS_ERR(channel) ) >> + { >> + printk(XENLOG_ERR >> + "scmi: Failed to acquire SCMI channel for agent_id %u: %= ld\n", >> + config->arch.arm_sci_agent_id, PTR_ERR(channel)); >> + return PTR_ERR(channel); >> + } >> + >> + printk(XENLOG_INFO >> + "scmi: Acquire channel id =3D 0x%x, domain_id =3D %d paddr = =3D 0x%lx\n", >> + channel->agent_id, channel->domain_id, channel->paddr); >> + >> + /* >> + * Dom0 (if present) needs to have an access to the guest memory ra= nge >> + * to satisfy iomem_access_permitted() check in XEN_DOMCTL_iomem_pe= rmission >> + * domctl. >=20 > Ideally this should not be needed but I understand we don't have an > easy solution, I think we can go ahead with this for now. >=20 >=20 >> + */ >> + if ( hardware_domain && !is_hardware_domain(d) ) >> + { >> + ret =3D iomem_permit_access(hardware_domain, paddr_to_pfn(chann= el->paddr), >> + paddr_to_pfn(channel->paddr + PAGE_SI= ZE - 1)); >> + if ( ret ) >> + goto error; >> + } >> + >> + d->arch.sci_data =3D channel; >> + d->arch.sci_enabled =3D true; >> + >> + return 0; >> + >> +error: >> + relinquish_scmi_channel(channel); >> + return ret; >> +} >> + >> +int scmi_domain_sanitise_config(struct xen_domctl_createdomain *config) >> +{ >> + if ( config->arch.arm_sci_type !=3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE = && >> + config->arch.arm_sci_type !=3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_= SMC_MA ) >> + { >> + dprintk(XENLOG_INFO, "scmi: Unsupported ARM_SCI type\n"); >> + return -EINVAL; >> + } >> + else if ( config->arch.arm_sci_type =3D=3D >> + XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA && >> + config->arch.arm_sci_agent_id =3D=3D 0 ) >> + { >> + dprintk(XENLOG_INFO, >> + "scmi: A zero ARM SCMI agent_id is not supported\n"); >> + return -EINVAL; >> + } >> + >> + return 0; >> +} >> + >> +static int scmi_relinquish_resources(struct domain *d) >> +{ >> + int ret; >> + struct scmi_channel *channel, *agent_channel; >> + scmi_msg_header_t hdr; >> + struct scmi_msg_base_reset_agent_cfg_a2p tx; >> + >> + if ( !d->arch.sci_data ) >> + return 0; >> + >> + agent_channel =3D d->arch.sci_data; >> + >> + spin_lock(&agent_channel->lock); >> + tx.agent_id =3D agent_channel->agent_id; >> + spin_unlock(&agent_channel->lock); >> + >> + channel =3D get_channel_by_id(HYP_CHANNEL); >> + if ( !channel ) >> + { >> + printk(XENLOG_ERR >> + "scmi: Unable to get Hypervisor scmi channel for domain = %d\n", >> + d->domain_id); >> + return -EINVAL; >> + } >> + >> + hdr.id =3D SCMI_BASE_RESET_AGENT_CONFIGURATION; >> + hdr.type =3D 0; >> + hdr.protocol =3D SCMI_BASE_PROTOCOL; >> + >> + tx.flags =3D 0; >> + >> + ret =3D do_smc_xfer(channel, &hdr, &tx, sizeof(tx), NULL, 0); >> + if ( ret =3D=3D -EOPNOTSUPP ) >> + return 0; >> + >> + return ret; >> +} >> + >> +static void scmi_domain_destroy(struct domain *d) >> +{ >> + struct scmi_channel *channel; >> + >> + if ( !d->arch.sci_data ) >> + return; >> + >> + channel =3D d->arch.sci_data; >> + spin_lock(&channel->lock); >> + >> + relinquish_scmi_channel(channel); >> + printk(XENLOG_DEBUG "scmi: Free domain %d\n", d->domain_id); >> + >> + d->arch.sci_data =3D NULL; >> + d->arch.sci_enabled =3D true; >> + >> + spin_unlock(&channel->lock); >> +} >> + >> +static bool scmi_handle_call(struct cpu_user_regs *regs) >> +{ >> + uint32_t fid =3D (uint32_t)get_user_reg(regs, 0); >> + struct scmi_channel *agent_channel; >> + struct domain *d =3D current->domain; >> + struct arm_smccc_res resp; >> + bool res =3D false; >> + >> + if ( !sci_domain_is_enabled(d) ) >> + return false; >> + >> + agent_channel =3D d->arch.sci_data; >> + spin_lock(&agent_channel->lock); >> + >> + if ( agent_channel->func_id !=3D fid ) >> + { >> + res =3D false; >> + goto unlock; >> + } >> + >> + 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), >> + &resp); >> + >> + set_user_reg(regs, 0, resp.a0); >> + set_user_reg(regs, 1, resp.a1); >> + set_user_reg(regs, 2, resp.a2); >> + set_user_reg(regs, 3, resp.a3); >> + res =3D true; >> +unlock: >> + spin_unlock(&agent_channel->lock); >> + >> + return res; >> +} >> + >> +static const struct sci_mediator_ops scmi_ops =3D { >> + .domain_init =3D scmi_domain_init, >> + .domain_destroy =3D scmi_domain_destroy, >> + .relinquish_resources =3D scmi_relinquish_resources, >> + .handle_call =3D scmi_handle_call, >> + .dom0_dt_handle_node =3D scmi_dt_handle_node, >> + .dom0_dt_finalize =3D scmi_dt_finalize, >> + .domain_sanitise_config =3D scmi_domain_sanitise_config, >> + .assign_dt_device =3D scmi_dt_assign_device, >> +}; >> + >> +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 disab= led\n"); >> + return -ENOSYS; >> + } >> + >> + return 0; >> +} >> + >> +static __init int scmi_probe(struct dt_device_node *scmi_node, const vo= id *data) >> +{ >> + u64 addr, size; >> + int ret, i; >> + struct scmi_channel *channel, *agent_channel; >> + int n_agents; >> + scmi_msg_header_t hdr; >> + struct scmi_msg_base_attributes_p2a rx; >> + >> + ASSERT(scmi_node !=3D NULL); >> + >> + INIT_LIST_HEAD(&scmi_data.channel_list); >> + spin_lock_init(&scmi_data.channel_list_lock); >> + >> + if ( !acpi_disabled ) >> + { >> + printk(XENLOG_WARNING "scmi: is not supported when using ACPI\n= "); >> + return -EINVAL; >> + } >> + >> + ret =3D scmi_check_smccc_ver(); >> + if ( ret ) >> + return ret; >> + >> + if ( !dt_property_read_u32(scmi_node, "arm,smc-id", &scmi_data.func= _id) ) >> + { >> + printk(XENLOG_ERR "scmi: unable to read smc-id from DT\n"); >> + return -ENOENT; >> + } >> + >> + /* save shmem phandle and re-use it fro Dom0 DT shmem node */ >> + if ( !dt_property_read_u32(scmi_node, "shmem", &scmi_data.shmem_pha= ndle) ) >> + { >> + printk(XENLOG_ERR "scmi: unable to read shmem phandle from DT\n= "); >> + return -ENOENT; >> + } >> + >> + ret =3D scmi_dt_read_hyp_channel_addr(scmi_node, &addr, &size); >> + if ( IS_ERR_VALUE(ret) ) >> + return -ENOENT; >> + >> + if ( !IS_ALIGNED(size, SCMI_SHMEM_MAPPED_SIZE) ) >> + { >> + printk(XENLOG_ERR "scmi: shmem memory is not aligned\n"); >> + return -EINVAL; >> + } >> + >> + scmi_data.dt_dev =3D scmi_node; >> + >> + channel =3D smc_create_channel(HYP_CHANNEL, scmi_data.func_id, addr= ); >> + if ( IS_ERR(channel) ) >> + goto out; >> + >> + ret =3D map_channel_memory(channel); >> + if ( ret ) >> + goto out; >> + >> + channel->domain_id =3D DOMID_XEN; >> + >> + hdr.id =3D SCMI_BASE_PROTOCOL_ATTIBUTES; >> + hdr.type =3D 0; >> + hdr.protocol =3D SCMI_BASE_PROTOCOL; >> + >> + ret =3D do_smc_xfer(channel, &hdr, NULL, 0, &rx, sizeof(rx)); >> + if ( ret ) >> + goto error; >> + >> + n_agents =3D SCMI_FIELD_GET(SCMI_BASE_ATTR_NUM_AGENT, rx.attributes= ); >> + printk(XENLOG_DEBUG "scmi: Got agent count %d\n", n_agents); >> + >> + ret =3D collect_agents(scmi_node); >> + if ( ret ) >> + goto error; >> + >> + i =3D 1; >> + >> + list_for_each_entry(agent_channel, &scmi_data.channel_list, list) >> + { >> + struct scmi_msg_base_discover_agent_p2a da_rx; >> + struct scmi_msg_base_discover_agent_a2p da_tx; >> + >> + ret =3D map_channel_memory(agent_channel); >> + if ( ret ) >> + goto error; >> + >> + hdr.id =3D SCMI_BASE_DISCOVER_AGENT; >> + hdr.type =3D 0; >> + hdr.protocol =3D SCMI_BASE_PROTOCOL; >> + >> + da_tx.agent_id =3D agent_channel->agent_id; >> + >> + ret =3D do_smc_xfer(agent_channel, &hdr, &da_tx, sizeof(da_tx),= &da_rx, >> + sizeof(da_rx)); >> + if ( agent_channel->domain_id !=3D DOMID_XEN ) >> + unmap_channel_memory(agent_channel); >> + if ( ret ) >> + goto error; >> + >> + printk(XENLOG_DEBUG "id=3D0x%x name=3D%s\n", da_rx.agent_id, da= _rx.name); >> + >> + agent_channel->agent_id =3D da_rx.agent_id; >=20 > It is OK to set agent_channel->agent_id to the value provided by the > SCMI server, but if we are also taking the agent_channel->agent_id value > from the user via device tree, shouldn't we throw an error if there is a > mismatch? >=20 > Or even better: can we avoid taking the value via device tree to make it > easier to configure? >=20 >=20 >> + if ( i > n_agents ) >> + break; >> + >> + i++; >> + } >> + >> + ret =3D sci_register(&scmi_ops); >> + if ( ret ) >> + { >> + printk(XENLOG_ERR "SCMI: mediator already registered (ret =3D %= d)\n", >> + ret); >> + return ret; >> + } >> + >> + scmi_data.initialized =3D true; >> + goto out; >> + >> +error: >> + unmap_channel_memory(channel); >> + free_channel_list(); >> +out: >> + return ret; >> +} >> + >> +static const struct dt_device_match scmi_smc_match[] __initconst =3D { >> + DT_MATCH_COMPATIBLE("arm,scmi-smc"), >> + { /* sentinel */ }, >> +}; >> + >> +DT_DEVICE_START(scmi_smc_ma, "SCMI SMC MEDIATOR", DEVICE_FIRMWARE) >> + .dt_match =3D scmi_smc_match, >> + .init =3D scmi_probe, >> +DT_DEVICE_END >> + >> +/* >> + * 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/public/arch-arm.h b/xen/include/public/arch-arm= .h >> index 095b1a23e3..30e46de6d7 100644 >> --- a/xen/include/public/arch-arm.h >> +++ b/xen/include/public/arch-arm.h >> @@ -329,6 +329,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t); >>=20 >> #define XEN_DOMCTL_CONFIG_ARM_SCI_NONE 0 >> #define XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC 1 >> +#define XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA 2 >>=20 >> struct xen_arch_domainconfig { >> /* IN/OUT */ >> @@ -355,6 +356,8 @@ struct xen_arch_domainconfig { >> uint32_t clock_frequency; >> /* IN */ >> uint8_t arm_sci_type; >> + /* IN */ >> + uint8_t arm_sci_agent_id; >> }; >> #endif /* __XEN__ || __XEN_TOOLS__ */ >>=20 >> --=20 >> 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 02 07:29:38 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 07:29:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1002832.1382217 (Exim 4.92) (envelope-from ) id 1uLzbv-0004C9-UD; Mon, 02 Jun 2025 07:29:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1002832.1382217; Mon, 02 Jun 2025 07: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 1uLzbv-0004C2-RC; Mon, 02 Jun 2025 07:29:31 +0000 Received: by outflank-mailman (input) for mailman id 1002832; Mon, 02 Jun 2025 07:29: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 1uLzbu-0004Bu-6q for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 07:29:30 +0000 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2061a.outbound.protection.outlook.com [2a01:111:f403:2415::61a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4fef36d7-3f83-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 09:29:27 +0200 (CEST) Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22) by MW4PR12MB7192.namprd12.prod.outlook.com (2603:10b6:303:22a::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.28; Mon, 2 Jun 2025 07:29:21 +0000 Received: from BN9PR12MB5273.namprd12.prod.outlook.com ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8769.037; Mon, 2 Jun 2025 07:29: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: 4fef36d7-3f83-11f0-b894-0df219b8e170 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=DlhOVJ7dm2BBNPVKKZWxw3QdoPRRpRSOlF9BRqV2KYC87+TODvlFJqscLG+nNLZeCba2u1vL6hFMt7ms2aE3+XRm0QSTe39tKckawJfDBzfd9uTOFhQluOa79H5InO+MdLUWtBZHMObp+R+xTQMOjxChNqzMrWqGqP8rWaIFsFYm+JWHD/Azuz015wGzU8FO4N+C6kFZLmwG39tjcuNXXFK1omjrbLVkeQD3e4gDeEf8zB6gDp+Rbc/mJcBUC4JJXS/zKK6BlHhFdb3JXMtuMzujpuhcDAL3tUxaMXqy1Z9iBsTV1C8ornepMKvRuXn2dTE9bmbqtcCuM3GLIwZsZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=atjzhwzwO4A4IJOfKslccgDJ0UFxqYSHRSFWVkGHQtA=; b=qvHhWRMtFHROxh8GeqcaB0KLvHwIcjL/QQHA1wptSL069lA2efChrcHy5ylw+zuItSinfT1cJXS1sI0XkymThhZks562wWoi9ZqDuwYNk9ZWOiXy1JEJJSGWy31TLuwNsluZMpgv7Tpdk0DbrOxCtOHrdBtCvSDJvCbtU0P/U67yfkz6T1lzKhVZm3zDyQgQhjs97iKrYcSnlk4NVq5/2abGzrzGY96psP0EgH0shwogohGl6bbJXRBz/5S3UlsDt8aaxMjJ9cnMu+AL3GlMXYSEQQhhLsNWuaKWHef61yqQ3YEFmWgmB6Do67J+A7uYUx5hBXffQNmIuJRL8kZbcQ== 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=atjzhwzwO4A4IJOfKslccgDJ0UFxqYSHRSFWVkGHQtA=; b=E6Ko1w1cfoaaB+WVaiOT6ibWThEkEhvsH+lwsdqy6NJ6NXxZ6jCL0vhscxJy2xSjdtKFZiCZyBjNpNqShDgjjK1J19QgGXKfEUnflQSyUwdxnmkULATXlKF/44LCvdW/S602DwpLi5UMrT9xJcX8ygJ7otDIq9VRNE6+DpVTQlM= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Message-ID: <9df7c8b2-0864-4d8e-8969-d876ae77c4cc@amd.com> Date: Mon, 2 Jun 2025 09:29:16 +0200 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 12/19] xen/dt: Move bootfdt functions to xen/bootfdt.h To: dmkhn@proton.me, Alejandro Vallejo Cc: xen-devel@lists.xenproject.org, Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , "Daniel P. Smith" References: <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-13-agarciav@amd.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: VI1PR09CA0157.eurprd09.prod.outlook.com (2603:10a6:800:120::11) To BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|MW4PR12MB7192:EE_ X-MS-Office365-Filtering-Correlation-Id: 8bd7fab8-57ec-4523-f5cf-08dda1a730db X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?R0RVdGwxOURUSStTd0UvUXNGRWNEdmI2aWRKQ1BTUlRTNFk1RWNWL1ZuUnor?= =?utf-8?B?RHk5UXdkaUpXWE45am1peEc4QnVEQllhRWRtTTJvV2dDa25kWUNod2ZpUi9O?= =?utf-8?B?UXp3UDRpYVVGQVBqeHR2VWxvbFREY08yNWI5TGF3U1JVbWRmL2tpVHJJWWsv?= =?utf-8?B?eE5FeHhkM2Z4RUtXMHBIMUhPWkIzVHR4MkoyamJqcjNRa2tjY1VvNDc2UmQ5?= =?utf-8?B?bXNmNzZDaEFIcXFNSGxQVmlkcmdSN011SXZJY1YvelNqZVlIMlR2RVZzMGp5?= =?utf-8?B?RTF4WW5pUXZHWDNHcmE2cjdtMlZlVUY4MVJmUHcvUjhXM0IwVnNkcVF6aEUz?= =?utf-8?B?Q2gwSXM1bDlyNHNLaUNVeUx0dWN0WTdvR1JaMEI2OHU2aVU3SklGdVJWWUkr?= =?utf-8?B?bnZLVno5bG9nN0lpbmdnYnNzY0gzaUxZeUZDZnNvaTMyUGJIQjZCdG8rMGNk?= =?utf-8?B?dEdzenFaaFZtbFNqSUtVSmM1aHpwanB5OXpvUkxjOXJ0VnJmRE90VUwxbDNi?= =?utf-8?B?dWZCdkNiRERTZXltWDUzamE3TlBiK0RlNVl5WjVLTExuajEwem9FdmwwNnRy?= =?utf-8?B?RkE5aVllNjZZTkx0OFRNaWlldjU4dUM1Mlo2dG8zR0lyTDQvd21ITVpuNGh3?= =?utf-8?B?aThvczVlejRoTGFZa2NyamtEVHdqL2FxQjliN3MxOUlmNjkzWnMxcjVYNWdR?= =?utf-8?B?RVFmNldpTGlQNHVUUHVmV2N5bU9peURSMWwyRWJNV2g5RDhSNFB3RFptV2VC?= =?utf-8?B?dnNkUkQ0SHU4R3g5ZmlHL0lYNWN1SUJHTEVYdmZqangyaCtQTEVOWTgzSFpN?= =?utf-8?B?Qjg2bTdHQXdZOTZXZUdzOVd4VHZYS0hKKzZnZTE2V1B3MVJBbVRibllPekdx?= =?utf-8?B?MlQ0b0oxZEhkRWZpRUpUYVhOanJTbm9uVW5PSHg0ODNIT0x3aUV1Tm5YeWgv?= =?utf-8?B?YWMwMU8zbGVXNWNIUUpVYi9GNzdQcko5eWZNYmFyRXN4UW5VdHZ1WkdWQXA3?= =?utf-8?B?MEZlQ0tuM2FQREhUMFl3SEJZK2h2K21hM3VUVmMwdWV0M1V4ajBSdEo2VmVp?= =?utf-8?B?d3lqWXExaGNuK2pzT2ZRdU1PcDFuZ3hSUHhrNUZ5S2ZDaFRrSUpLOFltWFYr?= =?utf-8?B?aXBLSFZtQkRWcGdFYU5VUzFUbmpqNHBIdXVzcmRBVWNHYnU5Vm5iRnNMSEVl?= =?utf-8?B?eUZ1L1UvbEVrZ0pLRFV0N1hGZXJPOTRvRUpySlpvcWVBandlZFRDaEhuVE9q?= =?utf-8?B?NjBsYVYwUnUyYS9UTmtkdE5seVlTRlRQY1UxYnlrSlJYQkRVcnhyZXNzRUFj?= =?utf-8?B?TWpmMFhSMFlsRnBHOHJuQ1hyR0JpUFd4dlZEYTdNZ2tlVjNjVnRSN2VSS1Bx?= =?utf-8?B?R1pWVTlmbEcxc2x3Rzkya3FKVWJzOUZsK2ZPTERCd3p6emVtWVg1OUY3Ym1E?= =?utf-8?B?NHByck9id295MTg3c3M0S3pkckowSTBXMnd1TjVKa0RPNC8xb2NPQ2Nzc0lH?= =?utf-8?B?WVREU1VNVG9nVUppMTJYTm84Qmk2V0JOeEtxaGVxaFIxYWhpNGhnRHNGcUY2?= =?utf-8?B?VlZYSnpxb1puV0FGL1lrQ2dYS1JCbmFZbGpTSThKNnpock52Q2xiZFNWR1Jj?= =?utf-8?B?aXpSVXphNVNXZzA0V2h0NHMwWGdadGVNWXZMVHp4ODFIUlZlRTlPMTAzeWU5?= =?utf-8?B?VkY2WWxNZWxsdEFZb2dQOVVVOGdCVVNuNWMwOE95bDF4cWZsWVpvNFNhY2dZ?= =?utf-8?B?T0UraE5ZaXp2UEpyd3MzSENxNmlYSndNY054R3NXZ0Jjb3lqWWtuYU5abkdZ?= =?utf-8?B?WU56ZVp4SXBlWGg1a21uRmZRck83bEwySG1ZUkxJRU5UeU1vUVRFdTRYQ09t?= =?utf-8?B?dVVYUDkzUDJHYUwzU29YS0NaaDdYV3BabUhlN09UdURQMjJsZTd5dVJlczdP?= =?utf-8?Q?YkP8AUTpnoc=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?c003blE1ZFM5T05rT25vbDV4NUVBQjZwTzRCdDRkclZlWHBFUUZMQy95RS9F?= =?utf-8?B?Qko1YjAyYURqTW5XMHNpd0tPVzMrd3gwbTRtazNRUjU1ZFJZbnNZaGVpMit2?= =?utf-8?B?UDYrVW5KRWpSWEhod01BN0JqZWltNFVRemY0RkZidEVxNE9uRjl4NFJrZ01D?= =?utf-8?B?cStNM3RkQk9hSG9BYmlxcmdZc0pLcFZPTU1oakMwY2pWb0VrbXNLaWF4dGs0?= =?utf-8?B?c2tBbndhMERMYzRscTUrZ3U5bkxEcnZ3WHpNYmxKZXJmcTVoMHFZMVRtUWo5?= =?utf-8?B?ZDVzWno0RGVjZlcwYkxXQkR2NVU5KzdTQVNWT1Ixc2R0S2FGUmRBRXByVC9r?= =?utf-8?B?NkZJMmVwdkRtTDI3Z1dFNlVEc2dJamtGdVlOOGxzWEdNUEN5b3Y4ZWNOK0hW?= =?utf-8?B?UHNtenhZNWNZV3V2UHBmMlJNd28xRUdOK1hrankxQjJ2V0lnYjFsU28vOS9Q?= =?utf-8?B?QjRkdFNpNzk2U2krWlFnSU5SeGtlQlFvU0lXRFZsM1JlU0UybEhjemlpQVNE?= =?utf-8?B?N1o4MXBIZXFTYTIzbG1SWWFqODUvTjMzUEczQ2FmTjFQSElONjQrSU5KZjRu?= =?utf-8?B?cVJiZ3k0N1BGUVFPci9JRWl6aHdHcnRyaVhGeklST2VxVmQ5Rjd3ZG5kSmRK?= =?utf-8?B?UTRYS0dIbFZCS1FUcTRUKzltUS9lMlZKR0dqNlFmcHBkSEtJWXBYckR2WkZr?= =?utf-8?B?dmUrME1lSXR2Z2swUWN5Qnk4ZXNULzhzMXRkOFdYaXM4WGlxYllLL0RlV0hM?= =?utf-8?B?enZtQXNNSTRVQkpldGNCckxGa091ZDlHaWVqZnA3OTdKNEhXWm9EU2NEL0RS?= =?utf-8?B?dHFrVUdBNzByV2sycVJSdzlJbG1nRngrVGtCdWNUT3VKTWUxblJtM3FjYU1W?= =?utf-8?B?VFJKMEV1R0xHZXVnY2VpVmlnVkJremJyem11RWx0Qi9ZMVo1WEtZeXZDZGpi?= =?utf-8?B?NElTQU1lVGJVL3hsM1BRWlFXNlRmaGM1cU44aFU5UUFRSzAyNHlqUG8zWDFr?= =?utf-8?B?QVA4cVRJV0trY1Ztd1FaUkV3ekRRa3ZhZEVMRjdjMzFheXVRa2RLeEFyWmh4?= =?utf-8?B?WEtXMnBwT3U3ak5pNTRhVC9yVG9CaXp5TlNOWVZyMEJucXJnVWN6c0FpK2Jx?= =?utf-8?B?SUUybUNRQjd4Q0hCS1hkcWUwLzRtdVhwek9DckNxTDZOeEx5bFZUQVZhQkZC?= =?utf-8?B?dUg4MG9zNnd3UW1JVXFadlQ4TVVVSkQycXdzZVNsVHdzdzBzUmEvMWY5RWtC?= =?utf-8?B?b25FUzBWREFSUVBPb1d2elFabDdiQkhoZVpDS1B2VEE3NjhuM3Vlb1NmMHo5?= =?utf-8?B?TE53YnEzaEhDS0p5T0pXNjBLYkx6Si9RL21UMCtpcHBsWGtDRjRuOWhPU2Vt?= =?utf-8?B?YWVuUVMwZ0xsWlNpVmhac1FSajZGcWhZamxzcGRYNUl5TjNrYUFKTzJhZzNB?= =?utf-8?B?VlU5WWNBc01KSS9lZlNDQVBzV1F5NW85NkVldDE4KzFDTzZYTC9sOUhsZFBl?= =?utf-8?B?dURKUzdVWU16ZUVXQnhCNXZabTl0L0NJTFQwcE1ZZ0xIbHpOMm9rOTVHNEZU?= =?utf-8?B?ZVM4aVJnSENEZkN3QVRETzRIY0RYSm1iVUJZQWtlaEFzdVN1UTl3aUdVUFQz?= =?utf-8?B?VlVOL3FrU09sMklyQ2tuZTdqL3lSSkY5VmtyYnVjVEZnbFFPS0FXNFRRaE5X?= =?utf-8?B?VGNUWE5SUUlJVlRYK0pLaXVEWjZZK1FGazAxYStXVHZHTExhQ0RabnpCcUdz?= =?utf-8?B?bmVQb05aQkw0Y2EwWXY5TGM4MnBubTZYdzJUV3NTbS9FQVkvTFpYVW9CeENk?= =?utf-8?B?a014ZTZXTWtDSTdQWWJ4M1RSM0x3Y1dqNkFHcmtRUzZhNDgwQTk3elJXUTVK?= =?utf-8?B?VDl4bFE4TkVuUko4UGVER0JxQmx3UGVsL2Nxd3lGQkI1QXdZZ3ZHMjdpME5k?= =?utf-8?B?dXdUQ3RPODlLMmVsaVpXdnlZQUl5Wkl2NzBTZW1tZVU4TmdIN3RBc1ZRU1BF?= =?utf-8?B?bEVXYkJkK1hKQzRVOWtFZkpySlhHL1d2SEV6a3lXa3MxYkRCVk5hN0ZaUEpN?= =?utf-8?B?eEtNNm94SnRJNURPN0g1NW4xQ3MvakdodGI1QlYyQ3IyL2VISzNocXQ5YWU4?= =?utf-8?Q?FXIw=3D?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8bd7fab8-57ec-4523-f5cf-08dda1a730db X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jun 2025 07:29:21.0019 (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: tb1cWfVgPJLKf2HQn+vgEKRiFyz4s+81BEMLCjxkctB42XHukEcAkja7qd7fB0SZ X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB7192 On 31/05/2025 02:35, dmkhn@proton.me wrote: > On Fri, May 30, 2025 at 02:02:20PM +0200, Alejandro Vallejo wrote: >> Part of an unpicking process to extract bootfdt contents independent of bootinfo >> to a separate file for x86 to take. >> >> Move functions required for early FDT parsing from device_tree.h and arm's >> setup.h onto bootfdt.h >> >> Declaration motion only. Not a functional change. >> >> Signed-off-by: Alejandro Vallejo >> --- >> xen/arch/arm/include/asm/setup.h | 6 ---- >> xen/include/xen/bootfdt.h | 62 ++++++++++++++++++++++++++++++++ >> xen/include/xen/device_tree.h | 34 +----------------- >> 3 files changed, 63 insertions(+), 39 deletions(-) >> >> diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h >> index 0f9e531a34..32308837a9 100644 >> --- a/xen/arch/arm/include/asm/setup.h >> +++ b/xen/arch/arm/include/asm/setup.h >> @@ -55,12 +55,6 @@ void setup_mm(void); >> extern uint32_t hyp_traps_vector[]; >> void init_traps(void); >> >> -void device_tree_get_reg(const __be32 **cell, uint32_t address_cells, >> - uint32_t size_cells, paddr_t *start, paddr_t *size); >> - >> -u32 device_tree_get_u32(const void *fdt, int node, >> - const char *prop_name, u32 dflt); >> - >> int handle_device(struct domain *d, struct dt_device_node *dev, p2m_type_t p2mt, >> struct rangeset *iomem_ranges, struct rangeset *irq_ranges); >> >> diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h >> index fa65e8fcf4..079259c719 100644 >> --- a/xen/include/xen/bootfdt.h >> +++ b/xen/include/xen/bootfdt.h >> @@ -2,6 +2,7 @@ >> #ifndef XEN_BOOTFDT_H >> #define XEN_BOOTFDT_H >> >> +#include >> #include >> #include >> #include >> @@ -16,8 +17,53 @@ >> #define NR_MEM_BANKS 256 >> #define NR_SHMEM_BANKS 32 >> >> +/* Default #address and #size cells */ >> +#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2 >> +#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1 >> + >> #define MAX_MODULES 32 /* Current maximum useful modules */ >> >> +#define DEVICE_TREE_MAX_DEPTH 16 >> + >> +/* Helper to read a big number; size is in cells (not bytes) */ >> +static inline u64 dt_read_number(const __be32 *cell, int size) >> +{ >> + u64 r = 0; >> + >> + while ( size-- ) >> + r = (r << 32) | be32_to_cpu(*(cell++)); >> + return r; >> +} >> + >> +static inline u64 dt_next_cell(int s, const __be32 **cellp) >> +{ >> + const __be32 *p = *cellp; >> + >> + *cellp = p + s; >> + return dt_read_number(p, s); >> +} >> + >> +typedef int (*device_tree_node_func)(const void *fdt, >> + int node, const char *name, int depth, >> + u32 address_cells, u32 size_cells, >> + void *data); >> + >> +/** >> + * device_tree_for_each_node - iterate over all device tree sub-nodes >> + * @fdt: flat device tree. >> + * @node: parent node to start the search from >> + * @func: function to call for each sub-node. >> + * @data: data to pass to @func. >> + * >> + * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored. >> + * >> + * Returns 0 if all nodes were iterated over successfully. If @func >> + * returns a value different from 0, that value is returned immediately. >> + */ >> +int device_tree_for_each_node(const void *fdt, int node, >> + device_tree_node_func func, >> + void *data); >> + >> typedef enum { >> BOOTMOD_XEN, >> BOOTMOD_FDT, >> @@ -246,4 +292,20 @@ static inline struct membanks *membanks_xzalloc(unsigned int nr, >> return banks; >> } >> >> +/* >> + * Interpret the property `prop_name` of `node` as a u32. >> + * >> + * Returns the property value on success; otherwise returns `dflt`. >> + */ >> +uint32_t device_tree_get_u32(const void *fdt, int node, >> + const char *prop_name, uint32_t dflt); > > Suggest using `dt_` prefix (or any other good prefix) for all functions > in this header for consistency: e.g. there's dt_read_number() but also > device_tree_get_u32(). Not really. AFAIR device_tree_ prefix is for functions operating on flattened DT (usually calling libfdt functions inside) and dt_ otherwise. Let's not mix them. ~Michal From xen-devel-bounces@lists.xenproject.org Mon Jun 02 07:31:21 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 07:31:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1002839.1382227 (Exim 4.92) (envelope-from ) id 1uLzdg-0005uj-8F; Mon, 02 Jun 2025 07:31:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1002839.1382227; Mon, 02 Jun 2025 07:31: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 1uLzdg-0005uc-4l; Mon, 02 Jun 2025 07:31:20 +0000 Received: by outflank-mailman (input) for mailman id 1002839; Mon, 02 Jun 2025 07:31: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 1uLzde-0005uU-GY for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 07:31:18 +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 8b02b86a-3f83-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 09:31:05 +0200 (CEST) Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-3a503d9ef59so762011f8f.3 for ; Mon, 02 Jun 2025 00:31:05 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-747affafa34sm7220962b3a.103.2025.06.02.00.31.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 00:31:04 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8b02b86a-3f83-11f0-a300-13f23c93f187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1748849465; x=1749454265; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=Gr0W4d9Z7GhDmdsc2sW5D6VLyrwB0V2fU8lbKoKoQUw=; b=ALn+YBUnmGhbfoJLnLAjQZu2s6hB7uNBZMO3iC/7hIDFwFa1PuQdUH0IQEza6w7M1r 2LGsZZQkOqEUfOHbOeZLoTTVAXIFEaJBXsSd1zoWADsURTKbwQu0Gh8IeDSJ9dJ7FOQf KaPxxKoeHoz2D/E+zlZkExROENnvarCn24FU3qrJ4d89xIiDxZ1P1cJZ0iaRKSLNOWhc +LKG8AO/9eCOuKPob3Kjv4plDwjNWY7oorL/yN0O66XFTlwoCfLeNFvjPyOv9m/XaZpC Ijj9/wwMPwqiJ+kry2SM2K1CaACnGUyYWEY+b+LUp9YBvcMeFlNfA/quyg1KDy80gN3w vBQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748849465; x=1749454265; 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=Gr0W4d9Z7GhDmdsc2sW5D6VLyrwB0V2fU8lbKoKoQUw=; b=Mc9Dhl8pf6MeNGgAf6bf8RnQe8znWH8QcEYqiJcomNbpiGrpvuQwehcmqHgb4cuVB3 KEi38OVNpVZx85ylxjTtIooUX3dMhhMV9ZOVIA0s3gw5jbGkNsjVfd+spBXpHEf3yBpv ANLJdOJO0U3TTVi5PpqqcQ+vq91vxsdYl4RGL7hNLiH5p8RINsZv6Dh6d/YR9kFRRmU2 +P2hO1vZvedA4qBH384vFE8pAvSFI5z/Dg0fW4oOupTszN21hVWlqieSK/gaJ0CHe0Nd /h+9wLJlMADR7iMWWruJXLM71WTacRJqanayOUHXnG3k1NoSiMgKN8kPGuKPOZSK8PAw RFhQ== X-Forwarded-Encrypted: i=1; AJvYcCXRQOUzw7ZA0BAug7CZlZfrTWGUugbwJ7127FFUtZd+Movpw2EZqpoa5vJ+rc3I/5VN21ynMQRKhLA=@lists.xenproject.org X-Gm-Message-State: AOJu0YzJkXybXOppu6TykQkq9tNTCJ1popctFxFou4fMQF/KEc4B3Bco GdnbZIlLwoBu0ma9jp+A/QhnORRpx9fN+G7sj9s4nZUCJJlb4pQszhxFYcSujMYt+w== X-Gm-Gg: ASbGnctYCbxOW2wGNOJciCyPeVV9OfobIxNpD4ZdUjCdE9InF3L4aU2XkwPOiJYFvYr MPASll/7sFBjVbU9jWoFyLziVWb+FgHFnbYMEZzkhKJqmYyfn01FEghOKLX9ErBVoDki+X2l/Wn DVvrYBFP4LsnjM7CspTeYGLaKXkzaU15xBN3cpwjptdm67s/eACskgiFdnASFeV0/6V1hgIsaem GvzZRylls7jBohWEgOPowr9vYcBlZ3ucW/olYEleJQart8/u98MZLf8iANJG9BqqNabyTKDG1Uq 4veiU/4QvcLcErseTo4tCdy7Oex57IqM5hw+RauGNtJIeoO0sSKbE1lk3OfvGnqLfrcncZUGEzX 2Oxyu1Ao9eZRs5fhLE7zUxWYPzPnK1j4IfR/n X-Google-Smtp-Source: AGHT+IGqLImJUHq14zafjBMpIwNYTLdYQPzO6D2+lNiq0zbBU72tBlNz8fbGL1lf8k6mI676RmXLiQ== X-Received: by 2002:a05:6000:4013:b0:3a4:edf6:566b with SMTP id ffacd0b85a97d-3a4fe160d10mr4902997f8f.6.1748849464867; Mon, 02 Jun 2025 00:31:04 -0700 (PDT) Message-ID: <8521480a-f14d-4ac4-826e-6ed066619070@suse.com> Date: Mon, 2 Jun 2025 09:31:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 02/22] include/xen/slr-table.h: Secure Launch Resource Table definitions To: Sergii Dmytruk Cc: "Daniel P. Smith" , Ross Philipson , trenchboot-devel@googlegroups.com, xen-devel@lists.xenproject.org References: <4896ab0b-f45e-43e9-bcee-f5496717eb2a@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 24.05.2025 00:19, Sergii Dmytruk wrote: > On Wed, May 21, 2025 at 05:45:04PM +0200, Jan Beulich wrote: >>> +/* >>> + * Copyright (c) 2025 Apertus Solutions, LLC >>> + * Copyright (c) 2025 Oracle and/or its affiliates. >>> + * Copyright (c) 2025 3mdeb Sp. z o.o >> >> I'm curious: Considering the (just) 2 S-o-b, where's the 3rd copyright >> line coming from? > > I'll add "Daniel P. Smith" (already in CC), not sure why his S-o-B > wasn't there. Just to mention it: Be careful there; aiui you can't simply add someone else's S-o-b without their agreement. >>> +#define UEFI_SLR_TABLE_GUID \ >>> + { 0x877a9b2aU, 0x0385, 0x45d1, { 0xa0, 0x34, 0x9d, 0xac, 0x9c, 0x9e, 0x56, 0x5f } } >> >> I'm not sure this is a good place to put UEFI GUIDs. Considering e.g ... > > It's here because the GUID is related more to SLRT than to EFI. I can > move it if there is a more fitting place for table GUIDs. It'll (at least somewhat) depend on where it's going to be used. A common problem when definitions / declarations are introduced without any use. >>> +/* >>> + * Primary SLR Table Header >>> + */ >>> +struct slr_table >>> +{ >>> + uint32_t magic; >>> + uint16_t revision; >>> + uint16_t architecture; >>> + uint32_t size; >>> + uint32_t max_size; >>> + /* entries[] */ >>> +} __packed; >> >> If x86-specific, the question on the need for some of the __packed arises >> again. > > The table is used to communicate data from pre-DRTM world to DRTM-world > and is produced and consumed by unrelated software components that don't > necessarily pad structures the same way by default. How do other environments matter when this header is solely used by Xen? >>> +/* >>> + * Prototype of a function pointed to by slr_entry_dl_info::dl_handler. >>> + */ >>> +typedef void (*dl_handler_func)(struct slr_bl_context *bl_context); >> >> It being an internal header, ... >>> + uint64_t dl_handler; >> >> ... why can't this type be used here then? This would presumably avoid a >> typecast later. > > It's not an internal header in my understanding of the phrase, Xen > parses what a bootloader has passed to it. In principle, pointers could > be 32-bit here. "Internal" as opposed to "public", i.e. what's exposed to guests. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 02 07:48:12 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 07:48:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1002846.1382238 (Exim 4.92) (envelope-from ) id 1uLztv-0007q7-FK; Mon, 02 Jun 2025 07:48:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1002846.1382238; Mon, 02 Jun 2025 07:48:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uLztv-0007q0-CP; Mon, 02 Jun 2025 07:48:07 +0000 Received: by outflank-mailman (input) for mailman id 1002846; Mon, 02 Jun 2025 07: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 1uLztt-0007pu-L4 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 07:48:05 +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 ea3ac6f9-3f85-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 09:48:04 +0200 (CEST) Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-3a4f78ebec8so1584116f8f.0 for ; Mon, 02 Jun 2025 00:48:04 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-b2eceb396f6sm4343096a12.42.2025.06.02.00.47.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 00:48:02 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ea3ac6f9-3f85-11f0-a300-13f23c93f187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1748850484; x=1749455284; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=VuQJh8JOIlFyJ8NwWZN9JrryHkYz8OsrTmzcYDIvA3Q=; b=X/r4lK4lXR7ZtjEYccnVcr3yimo2lYgcrqVpsQ2Edc31d07mAyg65cSCTO9OmF2Ufa KRHiPmwtgPzn9OZNOp5vqlAou2+cuJ6ExTCX9kXm6dbQhDGnjCAKz6NkrKjB4/ARcR6G 9B5EtfUYx+VV3PaUaqUu5gq93uH4tsSZ0eqLKP9tGUI2r+BIo/JD1X0tK6Csh88uDn7+ QYdv50B+X1PYcrBMT18goPw2/7EFjd7/sDw57+59FTRY51H+5zsLALyTM29ogq0LuAtx 9hme3Najcx/+RW6DUYRAR0614zWo8NuCsodhzp2GRB+gO4rHQTLw5x0ZU7fNdTmzYBdV LxrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748850484; x=1749455284; 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=VuQJh8JOIlFyJ8NwWZN9JrryHkYz8OsrTmzcYDIvA3Q=; b=KfwXuvEnAT40uue1ORXV94KJGpLrf1Snhgpjn8Kqh8IE01dh6yQB2QX28oJyZu9Wru 4XLKzDoLoBqsvjEn1VL/6Qfmrrbd5WBmYB0C+mqCo/cXHcmMd1JE7JYjvVUwLlLYzWIB g/wbr7Oqm9AnFviAFW0SNV/dJzm1jEK/iNX6MZS1Z3l1XMXOHU/4613z+9wbxT1uRZ8G 1tk8V1V+xg5Hk41J2XLub5CHDZCE2vsVfHR+ILYovlDXt0Qo+X9IWSO0r8tyKodFIrCe NsVtjB3TWElH9ZeQGfsIyZnzdogxLB+hMzq7ZtzeOX0h4HcbRwHF7/FqWI6iivD2AGjl pd8w== X-Forwarded-Encrypted: i=1; AJvYcCW7x9EMTGrBEzJf18M9BGCDla/Ap/xeN3wk9ftb/Fq0pHk6p7UICzszUpooNcYpHXSIs7MCIczjRps=@lists.xenproject.org X-Gm-Message-State: AOJu0YwFRaYhDVcz0Snvf4hVEU0qw7k1uxjUzxg5IPEV4Kfjx62oZSlJ 7t/i+XC7pKFiIoshy4BDTv6MsOjfg7i6ihQX317d8EIenliI5cGoFvC/OmiPEuJtLA== X-Gm-Gg: ASbGncsgAb5iLKrlWXan/z1CWtBtTqHZvRMS0znY0BmTnsEde/DPR0Xn1enZEpFdkLY UHprFpC5fzHq8wqXhTl0FYrMK0ionVXkkaz3Ytl4VkglA8xPM7/AVDcPL3cVBe97o/eeQSnzUJ0 jvIhDV7A2PiASSP1/xhpcrEW1x3zLkHz8DgvqkqnPy2ghb6ecJZpZqtbLx6+1454p1DaGcpua4V rPwbVPTBDdteOVlDhSmfV19bT9rannQF0ERLfUdSloV5vnjA8Ym/Opxn1bbRfsn+QdQBAGKsaQH rvDahI6myAOAiDsVsOhAl3VIJkdXOzyfG7FyJwo2Nen909QApz6SFjsTG7v01QIiRGNWdb0RvFL KtF28itKeCqoMWZKrBAzICacgWwTZLeAQSGNy X-Google-Smtp-Source: AGHT+IHyW1eNEyTCSasXANQXDAtgz7lLhxfRwi5KfDWrlt58AlPDdJfdZpZXOftJAvwUXnz/CcBtpg== X-Received: by 2002:a05:6000:1445:b0:3a4:ef30:a4c8 with SMTP id ffacd0b85a97d-3a4f89a5d60mr8129392f8f.10.1748850483633; Mon, 02 Jun 2025 00:48:03 -0700 (PDT) Message-ID: <680c7ba4-e4f4-4fb9-969d-ecaa206e37c6@suse.com> Date: Mon, 2 Jun 2025 09:48:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 02/19] x86: Add missing pci_dev forward declaration in asm/pci.h To: Alejandro Vallejo Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "Daniel P. Smith" , xen-devel@lists.xenproject.org References: <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-3-agarciav@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: <20250530120242.39398-3-agarciav@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 30.05.2025 14:02, Alejandro Vallejo wrote: > --- a/xen/arch/x86/include/asm/pci.h > +++ b/xen/arch/x86/include/asm/pci.h > @@ -13,6 +13,8 @@ > || (id) == 0x01128086 || (id) == 0x01228086 \ > || (id) == 0x010A8086 ) > > +struct pci_dev; > + > struct arch_pci_dev { > vmask_t used_vectors; > /* Would it perhaps be better to put this ahead of xen/pci.h's #include, thus helping all architectures? Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 02 07:51:28 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 07:51:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1002856.1382247 (Exim 4.92) (envelope-from ) id 1uLzx2-0001Da-Vm; Mon, 02 Jun 2025 07:51:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1002856.1382247; Mon, 02 Jun 2025 07:51:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uLzx2-0001DT-TB; Mon, 02 Jun 2025 07:51:20 +0000 Received: by outflank-mailman (input) for mailman id 1002856; Mon, 02 Jun 2025 07:51: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 1uLzx0-0001DN-Si for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 07:51:18 +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 5dacc608-3f86-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 09:51:18 +0200 (CEST) Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-3a4fdc27c4aso914663f8f.3 for ; Mon, 02 Jun 2025 00:51:18 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-747afe966f5sm7031824b3a.32.2025.06.02.00.51.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 00:51:16 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5dacc608-3f86-11f0-a300-13f23c93f187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1748850677; x=1749455477; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=3I5ocxBZaCZUzTigw4wiLT3+ZKZMcMmKbkujRIPO+AI=; b=QFxeYQlFEhXB2ssO/Q8VjgA0Pc7tIMTAU89pvtATWFVNi+V/LYii10SU5rzV7W1OBC p3SZHE2TlMy1dfwY3e2Eru+h0fhg8mLLhC4jRx6ipP1SA3c3eJyE7OGWZiA+BKT6vxYA TDKkbRW6/okQWqAhlo+FhVhFIn+D5i6yXC1kJCtwGgm3EJKqRi2r4AXwV3+mHcvG6Gu9 7dSjjg1sYPCgy6NSVmYnGGzciiba7LGZVvm7IlvNUhWonwDEaAJ2P8xR7OEQO6cUX/5t mBa5SYrzBk2esRoiJTburPHVDyE3qG5WCykw8Kwjsc+RKNSEE1ygEOO1COuwszJMkS57 AdoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748850677; x=1749455477; 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=3I5ocxBZaCZUzTigw4wiLT3+ZKZMcMmKbkujRIPO+AI=; b=Jwj9c/I8RevZVvWa0HfjLCIdaG48ucthPXqQvfcBSXjUTV3rMBE0UKyScjGYUdbygo YVcuiq5dWZdVE/NRd9QZkvraZxWj1XQPE5eQvtp7KUV7E/CATyxfPk96aVjtz1p5GWwo lKeQ2AB+Z2f9IHT640WUXE4iWHy6AWi5V2I/obHJhzQuKcoo0L3QOWSPSxCHKMMoDCXu HmE3Hn5gxwExcHakAWjclqkBLvKA9rwCKWVNRCHjhfKVXd/6om4wvnlxd6rk/2cmlIrV VTOCajNJ2pbcOonP2kf9J1yDnlgbUV9eWHeIE7u0ThieuYpubnaq1534QUVQYxcaIfLd nNXA== X-Forwarded-Encrypted: i=1; AJvYcCUV9SwQVRYrEh4OPjoJCb7HgBoe62ziVzGL58jlt5EuA1AQY6w1HZNYkJWJiUOUuJr2tGMd7gBS3cI=@lists.xenproject.org X-Gm-Message-State: AOJu0YxpRVtLt3fBkXakSpdX+c1h/d8mON3PDtQy6/vJE8tDbOO1edYH eAhiljZkGHspYa9BicM2GAT3A7jPGcotcja/7qTCY6qFMeg/t5U9yYwiyOWLqKYJHg== X-Gm-Gg: ASbGncuAsHt1btsVYHMVEVyVAo6pIaUdmfENTxU58Bcgy2VOfdtR1820vZVsgMDQdqE hBx8t5NcCroURmP7LtmzMndOGnNiuNUyIJ5VUc7jWqFFNsEnAe5P41OD8+0ippQlsyrjvdRiJkt iG8Lhcrdt2AAInb0zk1DG9DeL0HWLWNYdiXNrTIwzMHCebeePbD6YWS1t8DbzEAvfHbhlCp2QE0 nyCQ9wNrDneLTBBKZIeTttaJyRChAiJ4DJr26QSonhW0nP2u7+f6cIPzMYxD2kFCY5x1oC3q+Yp sd12XaGr1pcbJ1WylitILZXyadx6ymcfmxbJ58eZskTHQFQF/XRoP8AshbGFSKI/z5yY5PNXMxD 17B2eSQKF+1s4ClaIEzuyZ7eM05aW3y82yFbzLQjOhFbaXsI= X-Google-Smtp-Source: AGHT+IHN+S7cDseoV/xLp721ZC/KU1I8mJFys0x0aP4dEI497NMhuF6YTmg7j/10zhNC+Sgq02qv4w== X-Received: by 2002:adf:a152:0:b0:3a4:f8fa:9116 with SMTP id ffacd0b85a97d-3a4f8fa9122mr6173341f8f.8.1748850677407; Mon, 02 Jun 2025 00:51:17 -0700 (PDT) Message-ID: Date: Mon, 2 Jun 2025 09:51:20 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 06/19] xen: Clean up asm-generic/device.h To: Alejandro Vallejo Cc: Alistair Francis , Bob Eshleman , Connor Davis , Oleksii Kurochko , 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: <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-7-agarciav@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: <20250530120242.39398-7-agarciav@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 30.05.2025 14:02, Alejandro Vallejo wrote: > --- a/xen/include/asm-generic/device.h > +++ b/xen/include/asm-generic/device.h > @@ -6,9 +6,7 @@ > > enum device_type > { > -#ifdef CONFIG_HAS_DEVICE_TREE > DEV_DT, > -#endif Why would this enumerator need exposing on a non-DT arch? In fact I would have hoped for ... > DEV_PCI ... this to be hidden for arch-es not supporting PCI. Similar concerns elsewhere in this change. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 02 07:53:43 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 07:53:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1002862.1382258 (Exim 4.92) (envelope-from ) id 1uLzzH-0001k1-Bt; Mon, 02 Jun 2025 07:53:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1002862.1382258; Mon, 02 Jun 2025 07:53:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uLzzH-0001ju-8f; Mon, 02 Jun 2025 07:53:39 +0000 Received: by outflank-mailman (input) for mailman id 1002862; Mon, 02 Jun 2025 07:53: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 1uLzzG-0001jo-P8 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 07:53:38 +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 b076f8a5-3f86-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 09:53:36 +0200 (CEST) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-450cfb6a794so23244155e9.1 for ; Mon, 02 Jun 2025 00:53:36 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-23506bd8a88sm65111015ad.57.2025.06.02.00.53.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 00:53:35 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b076f8a5-3f86-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1748850816; x=1749455616; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=G5t/BcSsovNKFXGoVpGtnl0Ugn4JwQoFP8yJ/1UIBg8=; b=av3aKA9UkJivY9WZsn0Fdice/nywjvTl0droCfiT/1qaHHBVBzuR3XkzB5C3rkkVXe MtNa7FF2PdXo9tIRjtQM70hTU3bY7Defk3qaxvdzTblQlQTulBOxTATL/gtOLWD6yzd/ wnYOuauVAlEaR+sDUA2ks6N2zDfq5qZhf+rIJws5J5+ijRGS8YdoTgtOXXKAOvce7R/A mbdwnnc1jxjketDG0aMAs80BHjxXMeK+9z5vlMn4Ekug5tt7KzRrd8a0o+CRs+cT7hol CScvb46l/myRlylhsH15CQ4fs1ma49ESpOIgAvygKoPIW4eU6B0DZw7s+TzO7JZABmnZ 6Mew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748850816; x=1749455616; 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=G5t/BcSsovNKFXGoVpGtnl0Ugn4JwQoFP8yJ/1UIBg8=; b=ulP63tzLCPLjyF6+KbSax49DDLbQQFdW7/NfFsBkyrp5weI3cNuWqpsLxvnikhb70R pBdUNzisOwmGkuHVZeYsJdab1J37IVZnrULYHw5VGfhF5vzTg30Ft/Djqk1IL+cPnh0M +BfG6BcgVD440hbx/4Nh8pwD2bPsXz/oijSUX8xyKN3r237IAbb/C+vFXwqjt/Affd4v BVvPmCmmfpACr9qAnfjCQKTDMzzXq2RAlduaMoZP6x+yE4XBPhoU6lIaZq1gsJ6fy0wq oP7yBoA+LS0ZzMIKb2cyat6Z2/jPukoZLn8XFRht1hnEZ1KcL2Z9NFauN6lPx3bbvX5H IS8A== X-Forwarded-Encrypted: i=1; AJvYcCWETrUA+TQOm3oTh8t90u++1EQx5tb6CE1LeHy/qeIoKfmXfaBWx2flB1tqvKnxXzK6u4CnEiQOI1A=@lists.xenproject.org X-Gm-Message-State: AOJu0YyHwWoHcimrVOEASmvcMc5wDyNkxofPzbrNm2upeWeQMJzXeZEB 0byCkskbkOw4cD0xbLZtxcAmQ4LelpL8AmydMDbyn0zCjN7bdx2L8+Cd5xCI/b/82Q== X-Gm-Gg: ASbGncuyoSRIelhgSpiWw0Is2isi4uwXXTIvPWT5hB9oK80KTJonLqi04o2wderX4Tf M02pPip9Y1hFRaEeQZUmFB8R/QQdIVOqVICIcg3L8YeLUmMYrxdJYskaYqQoFJEUBt97boGM0uw JqKwoncWeBuF5lh5PU8/C3/+22KtiSGxK0vjgFHO2O8WkZ9GY+pwSGqxr3whsYr6kwQpFHSP5RB rAt1TxfsuzE1JXSKYxh0J9R+cRP4UA42iGIKR4WjvL425I3ho9zdOiLftSL4N1f8WvEXxPOZDGj E3ZqycLponi4yuH5oMXvy5LzoImI7iy4E+5QbAeQzDodr1DmrwtLudjvNHkowVfRK/TxLeMuu2E Gq27TPwCEGoiLGZrnEotsYi6lj+HyTq3mSsbI X-Google-Smtp-Source: AGHT+IFWpQ6hHHQF5W905oHr74vystJJa0QS0nc+GjF36GSpbFY8vzPNRMZqL1vFTwFZOOAEvH4kOw== X-Received: by 2002:a05:6000:40cf:b0:3a4:e6e4:6ee7 with SMTP id ffacd0b85a97d-3a4f7a9d580mr8482953f8f.45.1748850816223; Mon, 02 Jun 2025 00:53:36 -0700 (PDT) Message-ID: <5f3de127-70cd-422f-a368-6c23d83c6cf9@suse.com> Date: Mon, 2 Jun 2025 09:53:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 07/19] arm/gnttab: Break cycle between asm/grant_table.h and xen/grant_table.h To: Alejandro Vallejo Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "Daniel P. Smith" , xen-devel@lists.xenproject.org References: <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-8-agarciav@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: <20250530120242.39398-8-agarciav@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 30.05.2025 14:02, Alejandro Vallejo wrote:> --- a/xen/include/xen/grant_table.h > +++ b/xen/include/xen/grant_table.h > @@ -27,7 +27,7 @@ > #include > #include > > -#ifdef CONFIG_GRANT_TABLE > +#if __has_include("asm/grant_table.h") > #include > #endif This change looks wrong (or otherwise is lacking justification): With GRANT_TABLE=n the arch header isn't supposed to be included. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 02 07:55:34 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 07:55:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1002869.1382268 (Exim 4.92) (envelope-from ) id 1uM017-0002Hm-Ml; Mon, 02 Jun 2025 07:55:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1002869.1382268; Mon, 02 Jun 2025 07: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 1uM017-0002Hf-JP; Mon, 02 Jun 2025 07:55:33 +0000 Received: by outflank-mailman (input) for mailman id 1002869; Mon, 02 Jun 2025 07: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 1uM016-0002HZ-Li for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 07:55:32 +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 f469ce6f-3f86-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 09:55:30 +0200 (CEST) Received: by mail-wr1-x431.google.com with SMTP id ffacd0b85a97d-3a4f379662cso3070252f8f.0 for ; Mon, 02 Jun 2025 00:55:30 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-23506cf539esm65320235ad.194.2025.06.02.00.55.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 00:55:29 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f469ce6f-3f86-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1748850930; x=1749455730; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=na4hsWIUgzqP17/7nLAHiigP7fiaicCJrWy9v/JjPtQ=; b=E6t+H25fDHPwcnx/YTFZm2YItJuUd146j/3hU5WMlOCn0gVsdWBDU66AzaZhkEnZDN vnnWxIXlhyrw6XmSeJoZOX1O06koKEOEsEy7Upbq4goQvtTsy7laZd5jgJXVdQTdSv4g mKFhNPxJR+MC8fXIiRtJDMEKzdyRn3fjjvtOnWS6BliEm2BkbJnhf3PTcvHMwkI+TkwA vzJ1lAM2gYnUH/2zIo0CsEaOp82J/zxUZaaUWf/EwzRJjOb/rIopic6CimM72D8HwWj+ JDLWQm6/cmbJWTnPqxC7p0YqA+d9Hp/yNnNo68LELRgjmrQctxy2NIEPybpYlHxo2h5s TdrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748850930; x=1749455730; 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=na4hsWIUgzqP17/7nLAHiigP7fiaicCJrWy9v/JjPtQ=; b=Hcv7D8lqyA3RjAj+967hN5WR46UzRYhrTJdh4NMBYJAe9/SpKsjQpecDC6bXjrdGer f4B2GnABRezrjzMcxGZ60mGLbjFEJBe7zfr4chr6egDOdiRdL+XVJIg6RvVGDV6lB1Wy +9z5X0NYDhm4ZKS0sxgFb/pmZXnb0YE69cLMuMkCs9Phjd5F1yBU9ISfFaOGTnWop/Lc ZFQ4w0tsWzet1jGsn8JJOF/MThKoyge0ZPq//0PpzP7HYtClmblBUIIYrb+Q8KJpLa0u a9JNcfwOo0jAHpRPwqE6vmkc1kf1lW8i/rgMiDnhsTnyPeojzoR9ed63VUO/4Y4MQnzK Jy7w== X-Forwarded-Encrypted: i=1; AJvYcCXmpLBagHatqvimgS+ht5sH9GtsCuaYO3MiGaAnDIV92R3IEK2d0zDvF4VGGCUyMky2iF6yzhUfeqE=@lists.xenproject.org X-Gm-Message-State: AOJu0YyhC0sf4rBc2OChwI0Ke2tQCun1dCX0ZbdVics4WpzR1ME7nV7D F49WY7TdqAQJLncX97T9RqIRQkSoruNk57pfJ41S6z8fyR7I2Fp2prCur869I786mg== X-Gm-Gg: ASbGncuYaXKptWagfjDwMchQx6XeJy3pxiZdtHwDPWfJIICFEdL6AzR6a6R1VOg2ckD v9V+lsZgEoS9OqRJvZaP1w7hlOwkPrk0UgRxLkct5u1Q+893fy6GyBzZ7UP8MGC2vMJQavQNWbw qx4If6qige/ylEgPOS7/CT0IoI4tNcsaF4HkPzNt0C/0UKLmDbQlbt31CYPlf9V0T0EbIPvaKLo Yt6920/2Uxdyvo7Jp4bGfb6MMNNMVLuMYMtmp5CYKWru+obv9uKeIqRIgNdgdd7+3MYARii81mQ p7IDgGshj5IfKqb4uY97FBAKp8rqAsrBSk/duSRJbkaJ8X0ji9IFAl+weqiMwUsLumu1LIOhFLZ O8IdKbmSsrxMuqWrukrYznwUacqNh/FNNSV1qCGYfRVcYyDA= X-Google-Smtp-Source: AGHT+IEe0cGAIcjlDFcf0JrEJvDh27LUcDOfQ1IiKMHpgNYaQKw9EmLuF9X54MuS5yYlyA/zH4agxA== X-Received: by 2002:a05:6000:220d:b0:3a3:4baa:3f3d with SMTP id ffacd0b85a97d-3a4fe154f5bmr4535272f8f.6.1748850930195; Mon, 02 Jun 2025 00:55:30 -0700 (PDT) Message-ID: <2548f9a0-76f8-4e6e-8330-759b118b777b@suse.com> Date: Mon, 2 Jun 2025 09:55:36 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 09/19] x86: Preinitialise all modules to be of kind BOOTMOD_UNKNOWN To: Alejandro Vallejo Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "Daniel P. Smith" , xen-devel@lists.xenproject.org References: <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-10-agarciav@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: <20250530120242.39398-10-agarciav@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 30.05.2025 14:02, Alejandro Vallejo wrote: > A later patch removes boot_module and replaces its uses with bootmodule. > The equivalent field for "type" doesn't have BOOTMOD_UNKNOWN as a zero > value, so it must be explicitly set in the static xen_boot_info. > > Not a functional change. > > Signed-off-by: Alejandro Vallejo > --- > xen/arch/x86/setup.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c > index 1f5cb67bd0..5da9df33c9 100644 > --- a/xen/arch/x86/setup.c > +++ b/xen/arch/x86/setup.c > @@ -298,6 +298,7 @@ struct boot_info __initdata xen_boot_info = { > .loader = "unknown", > .cmdline = "", > .domains = { [0 ... MAX_NR_BOOTDOMS - 1] = { .domid = DOMID_INVALID } }, > + .mods = { [0 ... MAX_NR_BOOTMODS] = { .type = BOOTMOD_UNKNOWN } }, > }; A brief comment may be nice, to help readers understand that there is no off- by-1 here. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 02 08:00:28 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 08:00:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1002878.1382277 (Exim 4.92) (envelope-from ) id 1uM05n-0004KO-AU; Mon, 02 Jun 2025 08:00:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1002878.1382277; Mon, 02 Jun 2025 08: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 1uM05n-0004KH-7V; Mon, 02 Jun 2025 08:00:23 +0000 Received: by outflank-mailman (input) for mailman id 1002878; Mon, 02 Jun 2025 08: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 1uM05m-0004KB-8W for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 08: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 a0fbf742-3f87-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 10:00:20 +0200 (CEST) Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-3a36efcadb8so3568375f8f.0 for ; Mon, 02 Jun 2025 01:00:20 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-b2eceb0288fsm5057609a12.9.2025.06.02.01.00.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 01:00:19 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a0fbf742-3f87-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1748851220; x=1749456020; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=GqmeDNkJdMV6tc0fk79c9Oib5+eJkyYKFPZAKEz0tNE=; b=a0niYQ1LoQJQua0fu5KEB/TQUcYmXZs54u8Dny5mMMD0clVy9GHkvLOY12eN1ki2gL IHD/KKNn9Jpb23CBWzAwrfDNQlyDtrcn/t6AOx+5lPhTn0ejrPje+1L0ilb63jCVr9Xy kDmzM9HrfK2DqmSU0tu1/ru3rMhTiehqWNCfktWBYP0aZkq+jLT506K9BhBSgOytfjdw 6taYJqX4rHKBDFCwCvEslcNTggRKFc6l48LPsLHNcFSHAFy+fOW1LeX+JDVpjVuBLnoW OvIJ+tNw7f1p5Z+hVlljDYNkOsT9wfnGZ8N01k0haLB+GisOfiBSM/YYx1PHKZysm4qB uroQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748851220; x=1749456020; 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=GqmeDNkJdMV6tc0fk79c9Oib5+eJkyYKFPZAKEz0tNE=; b=W3uRl7ofidNWPBD+MmD+Zf7016O6ifxXcBNeeWpvKi9m/KR8yNEPi+Vj3wcfe/HXWO edJ7NFsx0qQPScNLkK6HUjWJGf3yxDgRW+BuFWq5weXqIN6Sdw4I5+NGFQymUdKj6Laq W4o5fPJd5HqD/6yK1GO77VauHis8sEnfTNvnh6Qk/4XucEroDwC9jkrO3W9thaiMxyNb A3ZK9eP6ZDImQqJeOOXr6VvHz3eXlsa4oIgNXIOiwFGmujxLH+j2B9xQK3fXYkNu521f I3KvOlU4GzbYSzxngH8HlK+BmyCA+Jcy0sEvfjKtUsxHHtIkIeL3slhfFGd4ZhJm89G7 gLNA== X-Gm-Message-State: AOJu0YyYK6qapJ44Y5Ftu7Sr/ICTx8AG0xi/jwdF6Oyku0cQeVHJHHrh JuLCyUPRAZRQzqObllREY1BY9JQdxE1XyARbI9SSV/qqYiCwiZjIC3hwxnIxdFr9BA== X-Gm-Gg: ASbGnctsCE7RzBdRRAZsVQR2+bPQ6dla8XTb5cTJwr4wug7Nz12f8ZFJFOF7F+KRXPX 8BpohpvaWYshTYXSsE7kI9RPaFYHsTcgmjLxCrb0zy+dXBcqCgu8Oi1qDTN14X5Th5etPj5ZiBZ D2/6n8xwFoFY3eGynQrvcKlpFjMvwQIOCfUgdsBuz2pwudsPp5rxt7jjf2HxX7sB6xaWbzjIX0+ JdzfW3rQopF73GAJV1fcXuIkTgC1H9lHd16ppnBgnIgv6zSp2AIODTcTjwzNriC2lL44/YuPTJc sYZpkHsVc/WP1UOjshXhEDOQ53RwOeP3Smvf025eTT7kJvCnhApKf2z0b/Ywa3rA8SD4Xbjvqqr aJIjF86zSqrlMK3HG1hzl128wzlTWNQ6YhOPB X-Google-Smtp-Source: AGHT+IEw8FU7DPK3ZDbfSq7h4rgIWjRGcdSfart7DivhOsBXCLmiwH+LK2gXPKb7QhC2/NgK9/+E9w== X-Received: by 2002:a05:6000:220b:b0:3a4:ef00:a7bb with SMTP id ffacd0b85a97d-3a4f7a4d637mr9432431f8f.18.1748851219660; Mon, 02 Jun 2025 01:00:19 -0700 (PDT) Message-ID: Date: Mon, 2 Jun 2025 10:00:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 15/19] xen/dt: Move bootinfo-independent helpers out of bootinfo-fdt.c To: Stefano Stabellini , Alejandro Vallejo Cc: xen-devel@lists.xenproject.org, Julien Grall , Bertrand Marquis , Michal Orzel , "Daniel P. Smith" References: <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-16-agarciav@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 31.05.2025 03:47, Stefano Stabellini wrote: > On Fri, 30 May 2025, Alejandro Vallejo wrote: >> --- /dev/null >> +++ b/xen/common/device-tree/bootfdt.c >> @@ -0,0 +1,97 @@ >> +/* SPDX-License-Identifier: GPL-2.0-only */ >> +#include >> +#include >> +#include >> +#include >> + >> +uint32_t __init device_tree_get_u32(const void *fdt, int node, >> + const char *prop_name, uint32_t dflt) >> +{ >> + const struct fdt_property *prop; >> + >> + prop = fdt_get_property(fdt, node, prop_name, NULL); >> + if ( !prop || prop->len < sizeof(u32) ) > > Ah this is where the u32->uint32_t renaming is done! > Since we are at it, we can change the u32 in the sizeof > > >> + return dflt; >> + >> + return fdt32_to_cpu(*(uint32_t*)prop->data); And avoid to cast away const-ness here. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 02 08:09:11 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 08:09:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1002888.1382287 (Exim 4.92) (envelope-from ) id 1uM0EE-0005Pd-3i; Mon, 02 Jun 2025 08:09:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1002888.1382287; Mon, 02 Jun 2025 08:09: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 1uM0EE-0005PW-1D; Mon, 02 Jun 2025 08:09:06 +0000 Received: by outflank-mailman (input) for mailman id 1002888; Mon, 02 Jun 2025 08:09: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 1uM0EC-0005PQ-BW for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 08:09:04 +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 d82cf40c-3f88-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 10:09:02 +0200 (CEST) Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-3a4f71831abso2800738f8f.3 for ; Mon, 02 Jun 2025 01:09:02 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3124e3228f6sm5045193a91.46.2025.06.02.01.08.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 01:09:01 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d82cf40c-3f88-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1748851742; x=1749456542; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=J+X3nOHKqYKn6IBZ9pDsGZ0xvJicwk19L46SIvP3EOM=; b=fysdBtjQ/5L1Zn4up8iM6G8T9eKzy6TZlAbZV/cGzWylZ8BI/IIkNzkezbyMi/eRbX U3JKKqLb0hYvQ9B03uKDi5I4UAqxWVuMOW/IGzFwuREVVRYoeo3b2jNubQihpAnLXKSm cxdDpfTIfhObvuFWdVrucdqmLi3yMYR/URBeqwEJEsKYWvau1CEVt3wtrUiFEaeA7Iw+ 1O1JQ2Qup1OJ6X9ya+BoVolw6FwXdXuVLfjvMb+WbkVK9x3D0L4kLgJSj0tQUDhlC4rY lYqCS0dWhE3D72CZNd/PXgWwqjphZiSDFBP+neYP8FPsKKyMfej/yPgYcs2IKPBFsEiB AuDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748851742; x=1749456542; 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=J+X3nOHKqYKn6IBZ9pDsGZ0xvJicwk19L46SIvP3EOM=; b=BVBeXuTtUnRsu8MRBP7EgnqzRzbQdsxgfBcL0ck/U8VrKkprmwm7AAYGz2L3D/V22F Gd8pAizUDL+y0ypqnqRgcye8kwlk+c1RzTg5hu1wUGYTqOoJzcN2oH/6KB/LhTyhEv0g rTRoWZh/fj7pHdmJARcScJGlpQwAAC7grt9ETAggGc4+7h8Qw1kQT/5zjGpN3mGcvJke jxaCFOBDK5tbqohZMiKy168T44+qnitkeYa10Sn8xD5zv3fCg6qNPZM1fjSxmVjxwvO2 OgvhosDOzKSxSoRPGweCTqYp/VPpOV7nJvszak6UyWqBmWrqMkfLAmoO1uUk4aj6jMKH 4ZGA== X-Forwarded-Encrypted: i=1; AJvYcCVRJbgYlLzGZtIjduvMaWvgtdo8ASFQfew3YIAatkuEve9hwuYD/zwCJ2Tr7Oe4htEBVljI9CgCNUc=@lists.xenproject.org X-Gm-Message-State: AOJu0YyB9usAW63x/juejQGU/zQr0lphM2g0M5ZuQoJSMU6nR1NAgKpD UEqxwvb59dG0gdApplcAjDMv3UMqbrdwdejGKc8AQwspLCA+OVStNqekWFYSVc3qjA== X-Gm-Gg: ASbGncvV8iQl5EV8rgHGOKkZ4/tzS+azuP1m3WQkP3efDayS51BG0K720kxFOQKI67c bqmYYctaTljecRgXLfZHmrx35jsbksgRKARYRcY9DQfMJ+dnv2XR7Smvd2vnUQDRrBn2bWEb6l8 jqeWiwxrkav3n9ghorEZecQy7qhZQ9lIzKHfdn19i3ghpfwAOKMmKJj4N0evxb6mCB8uWGtCWSA Xn1Bwv5sgouaBhhNdsRGTtIBw2hIJe+EbzwOeD5n+T6u7KwEAxraz5XaYj+6qNRkiYIts/0v+tB ztewX45b9JAJPINLTEkDIyUyZfpWIGCLVE0OhI1JxHFdfF2pX2ku7Uai9/jIgZVgkmZxKD0r2jo wVFLrXs6M1/NUIgVF0VcCeb5vB2zH6JRafuN2 X-Google-Smtp-Source: AGHT+IHH57sWuTFbXkuTymxD86Piq2+iWZcP0oxWqJ6rWCif3AwkcHPGBprdKedQ8oL/V07lqzrbuQ== X-Received: by 2002:a05:6000:22c1:b0:3a4:ec2a:158d with SMTP id ffacd0b85a97d-3a4f89df510mr7465719f8f.55.1748851741823; Mon, 02 Jun 2025 01:09:01 -0700 (PDT) Message-ID: <24e2b3c2-6533-4e09-a33c-35dedaa89d66@suse.com> Date: Mon, 2 Jun 2025 10:09:05 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v11 1/7] iommu/arm: Introduce iommu_add_dt_pci_sideband_ids API To: Mykyta Poturai Cc: Oleksandr Tyshchenko , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stewart Hildebrand , "xen-devel@lists.xenproject.org" References: <503fe598dd53b4023bc60e621592f4f0a0e0bf6c.1748422217.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: <503fe598dd53b4023bc60e621592f4f0a0e0bf6c.1748422217.git.mykyta_poturai@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 28.05.2025 11:12, Mykyta Poturai wrote: > From: Oleksandr Tyshchenko > > The main purpose of this patch is to add a way to register PCI device > (which is behind the IOMMU) using the generic PCI-IOMMU DT bindings [1] > before assigning that device to a domain. > > This behaves similarly to the existing iommu_add_dt_device API, except it > handles PCI devices, and it is to be invoked from the add_device hook in the > SMMU driver. > > The function dt_map_id to translate an ID through a downstream mapping > (which is also suitable for mapping Requester ID) was borrowed from Linux > (v5.10-rc6) and updated according to the Xen code base. > > [1] https://www.kernel.org/doc/Documentation/devicetree/bindings/pci/pci-iommu.txt > > Signed-off-by: Oleksandr Tyshchenko > Signed-off-by: Stewart Hildebrand > Signed-off-by: Mykyta Poturai > Reviewed-by: Stefano Stabellini While I'm not happy about all this DT stuff in ... > --- > xen/arch/arm/include/asm/iommu.h | 15 +++++ > xen/common/device-tree/device-tree.c | 91 +++++++++++++++++++++++++++ > xen/drivers/passthrough/arm/iommu.c | 13 ++++ > xen/drivers/passthrough/device_tree.c | 42 +++++++++++++ > xen/include/xen/device_tree.h | 23 +++++++ > xen/include/xen/iommu.h | 21 ++++++- ... this file, it's only adding to what's there already, so Acked-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 02 08:11:14 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 08:11:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1002899.1382297 (Exim 4.92) (envelope-from ) id 1uM0GG-0007AV-IS; Mon, 02 Jun 2025 08:11:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1002899.1382297; Mon, 02 Jun 2025 08:11:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uM0GG-0007AM-Fl; Mon, 02 Jun 2025 08:11:12 +0000 Received: by outflank-mailman (input) for mailman id 1002899; Mon, 02 Jun 2025 08:11: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 1uM0GE-0007AG-Tc for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 08:11:10 +0000 Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [2a00:1450:4864:20::431]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 24097668-3f89-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 10:11:09 +0200 (CEST) Received: by mail-wr1-x431.google.com with SMTP id ffacd0b85a97d-3a4fdc27c4aso928214f8f.3 for ; Mon, 02 Jun 2025 01:11:09 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-23506cf908fsm65391385ad.193.2025.06.02.01.11.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 01:11:08 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 24097668-3f89-11f0-a300-13f23c93f187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1748851869; x=1749456669; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=8h874oZetIgDTxJQnHT4qevISzGI0DoLGKur2SoUoUk=; b=NOkXHm9wKcvkw7d7N39GQykmACW0oegHuCXNrDjVZfMwAt8VDOcXCBq28hdfvUd15o FmGSbO8gQD/eNaE5UGH48CazONuGOkqScxx3Hj6P83/bYSvfATMjouHx5ybfrHC43+Vt WtTQNxB9kwQ8jNcwYgaVKPB+8Ifd438RxsnYPyKCMZZk0tjr8YZGioRugY7ekmuXT01S sZkxcdRRyBYVmkt9KkId90udzB7W08A3o0+KImOXIYYjOFRFvq0OxZGw/LHrA5h/whtO GBVCE0yhfSZ+nlFoaB95iaCZEBbDg5GvPQTtu9CovEZ6k3vWG5XOq5UK7eYGTEkY27Uz RPOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748851869; x=1749456669; 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=8h874oZetIgDTxJQnHT4qevISzGI0DoLGKur2SoUoUk=; b=VtqPo8aK2EKtSetV3UTvm5T1UEH3bEUEuw86erjxUfgOemAEwNQWCu19fhnOViWpSI qf/chk2JR2tdso8qgxTqcpXxnpUzNoSvNFqkp8LwvMVU2FVVk6o7N5fGrDgTkpIT2o3i 7qMFJOYJuDp8u5OUFXBBcC4YB0k2cMygxSeLIsW4q9d0tSghxpSATuJyp29Ukv//3WHN CkROI5RNUDBYHrKGE70cY+izLkm+DH3mMdmHMP9QlXM/vTy4UJcL4P61hXlBAwO26rz8 WaLV+Yk6RkQM3If0LjDv4B9nzsinC6TcVmgHRSdG9/2r6Z3pqGbybpVjOKi8Y3GLWp6e RS4A== X-Forwarded-Encrypted: i=1; AJvYcCXgYwPTmVX8HsuzkpZIQQmXeNT3gja3SWFLMAQIGAYrdHGNobvFBy3s/YH9VAndPCzvbX+0rcg/a8s=@lists.xenproject.org X-Gm-Message-State: AOJu0YywtDSD6vREMSRyFpoz79+jJwrReyeu1WQoEKA0ifYZtsK31yI2 RGP+j4j7HkgeDfoU85TbP3w44f9zsAoPS2VfdZXoi40dhbO2SLl/hErYpwjVpqXwVw== X-Gm-Gg: ASbGncsMDrt16MGJQmVQwKTPh+jFtOkC4MS0z5AnJdHP94qounMa0Pti8/DNCHdGIwe QVbbL3eAEXCozQ7l83P6QEoCMh1O+gdgs+I3GaGhESs6gEAPSOTpfw55hVcZ/QYMHdN2+BncNbg LbST/51L06r/ozXrJ9r3+ib4Mim2PJAGktVlg/F6p2sVzgU3K4lsPlbezs3FyewqIKX8KjctxkZ sCeQJp7cAHNKnhde7yaD0GSwvCUbBiVxc/uYyngssb5ZqbvD9pOhDqWUHYWv2nzlLxjgpZsWgKF t3ZWLg43p+Lt9ojbz5iGWtRxQYMwVhFLCIJGOrlIuvy2lUIRoQCq4H3y0n47qRRUjLeOkFt66Rt zRbxI9zMXuP84A4uIN7bfsYmWTeAlclOnT6EQkTCIS5vlYhQ= X-Google-Smtp-Source: AGHT+IFsrgjZwTZjW/JVCyivWRXNIYB3H84BslfVXB6S6wW8q0qP2SmsMax+HufZXoBPdAoo30V4/g== X-Received: by 2002:a05:6000:2087:b0:3a4:eaab:5111 with SMTP id ffacd0b85a97d-3a4f89ddd94mr7844197f8f.37.1748851869167; Mon, 02 Jun 2025 01:11:09 -0700 (PDT) Message-ID: <66cda989-efe9-4389-ae8d-cb9bc4dc5239@suse.com> Date: Mon, 2 Jun 2025 10:11:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v11 6/7] xen/arm: enable dom0 to use PCI devices with pci-passthrough=no To: Mykyta Poturai Cc: Stewart Hildebrand , 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: 7bit On 28.05.2025 11:12, Mykyta Poturai wrote: > From: Stewart Hildebrand > > Enable the use of IOMMU + PCI in dom0 without having to specify > "pci-passthrough=yes". Due to possible platform specific dependencies > of the PCI host, we rely on dom0 to initialize it and perform > a PHYSDEVOP_pci_device_add/remove call to add each device to SMMU. > PHYSDEVOP_pci_device_reset is left untouched as it does not have the > pci_passthrough_enabled check. Just to re-raise the question here: Is this actually correct? > --- a/xen/drivers/pci/physdev.c > +++ b/xen/drivers/pci/physdev.c > @@ -19,7 +19,7 @@ ret_t pci_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) > struct pci_dev_info pdev_info; > nodeid_t node = NUMA_NO_NODE; > > - if ( !is_pci_passthrough_enabled() ) > + if ( !is_pci_passthrough_enabled() && !arch_pci_device_physdevop()) > return -EOPNOTSUPP; > > ret = -EFAULT; > @@ -57,7 +57,7 @@ ret_t pci_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) > case PHYSDEVOP_pci_device_remove: { > struct physdev_pci_device dev; > > - if ( !is_pci_passthrough_enabled() ) > + if ( !is_pci_passthrough_enabled() && !arch_pci_device_physdevop()) > return -EOPNOTSUPP; Nit (style): You're losing a relevant blank each. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 02 08:37:35 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 08:37:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1002919.1382328 (Exim 4.92) (envelope-from ) id 1uM0fh-0002gH-Oj; Mon, 02 Jun 2025 08:37:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1002919.1382328; Mon, 02 Jun 2025 08:37: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 1uM0fh-0002gA-M6; Mon, 02 Jun 2025 08:37:29 +0000 Received: by outflank-mailman (input) for mailman id 1002919; Mon, 02 Jun 2025 08:37: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 1uM0fg-0002g4-Sl for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 08:37:28 +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 d01f06da-3f8c-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 10:37:27 +0200 (CEST) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-450d668c2a1so18297275e9.0 for ; Mon, 02 Jun 2025 01:37:26 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-23506bd92c7sm65941785ad.62.2025.06.02.01.37.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 01:37:25 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d01f06da-3f8c-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1748853446; x=1749458246; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=s2CizzUvivBsJgNurFjR4ozFanrBFlQK/zlyrNxv9jE=; b=fXKK8JKrv3dHira05MdICWSCYPw2pNNvgEGq7SDpYmvtuG6lducVB3jBSC6BTvdhwO rLyQ+J9/ioAS6kEd+htnsv9KRASjy+HEUPeLVRt/uLQySVDf+zUICUPJs4nXHafJc+DI h6Zl/J5TIfoDgP96U5tiU0pBwd0/1NVFwSqjsR1faPlXGrjedq8uEq44OzmFkvbguiZY PvnkiX+TPWwTwtsfsQovS1xax3EgQdL9WwySI3IqOBnwg2xSONclWelmddLqJA1uM8RB PahC46BcqD8VyZMLDytm1s9701WPv3w2MOno73WVGfYFwkTVXxTQbqwNq+UEL0nvETfS PixA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748853446; x=1749458246; 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=s2CizzUvivBsJgNurFjR4ozFanrBFlQK/zlyrNxv9jE=; b=LVRZUstBm2d++IFHFpPPQTyu5j3B3q1Vd/9Qk3jB/5FbpOW+giEFmLCbZLDBKBPHNa H51DX+MZBkoEPRrIGYwYnxdew88hWz6y1m62KqDC3l7akaKOrpVSrP5S15IRZCcqd3fK cXF146oZUL2zy9bGDz14+KISRXJd4OV/M46lEkxHKg3LavZmKMNhzZ/ocGrulCjeiC4q XeqwCGjO4PWuYNtueT1+9WMjfXoydAqWn2lzOLEr/O2sWLGpTsFtZYpO7KBcd4b4E+vK AHFZ8zCyDBN7VcYq0dLgDCxJKjmfsMmTW+EoZvmea3kOKVmWxggNGmxeuGeM7ryWUsbm g+HQ== X-Forwarded-Encrypted: i=1; AJvYcCXcSeZFpfCE85qB6+HAzkvQuI2MGQxvpvrLPNhYopAcM4XC967ibwL1pW4njjm9yXwImYeVXvWxi24=@lists.xenproject.org X-Gm-Message-State: AOJu0YyStB6kwTwm+zY8qeHo5Rc1YAcN/ghNk5/jNJlUjeAhrpIUE9Pt 6Qw0ckkEIHA35vQ6/GWeqVB7Vl7UTQmw/nhHeBeYm7A2cKv+1RaQpAlkWldxnTm7bw== X-Gm-Gg: ASbGnctVOKvhwr6O6DMAa33ZGGzwoZFQY/C8wsS8KViION1PmVpkcVRjXJPjAac9Jhs r7/qpP5PjTw1L3pSzrBpekWoabdkVSCPBbNBX0DvjQAuyGfkSWk240uirhdEv1UJiJIIV0/3zP2 OFCwXqW26X+5SIb4E1y6FtWWNOjCF3Pk30FKdW0VI2Zygxrep1/6ug4OPcvohY+mXroeCojyaC2 5I99j8/GjkZVZ3Fr3aV+0xv9Td38qXyummCh9V9YQ37ubKTZYpfYkjar0o1ebwMcB6+yTJkQUIL duDQS7RxgIoJcCj07nwJMA4ytWYSs5i5CLrS4mu7wun9i7S/QcGP4onCLMiwG5vugKIP1H2ndK8 iTgmFBjUYlfVt3OPX71C+rrKMNQBpKeqvrvZb X-Google-Smtp-Source: AGHT+IFkApe44EvHCGqUgausq2lD8gYN51hsqftFsSXTAC6z/iteQWmoh0vEF5Nm/Lxz80TkinX9XQ== X-Received: by 2002:a05:6000:22c3:b0:3a4:d9d3:b7cc with SMTP id ffacd0b85a97d-3a4eedceccbmr13240142f8f.28.1748853446269; Mon, 02 Jun 2025 01:37:26 -0700 (PDT) Message-ID: <344823d0-eb05-48e5-80c5-9598104f3a3b@suse.com> Date: Mon, 2 Jun 2025 10:37:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] device-tree: Move Arm's static-evtchn feature to common To: Michal Orzel Cc: 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: <20250527082117.120214-1-michal.orzel@amd.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20250527082117.120214-1-michal.orzel@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 27.05.2025 10:21, Michal Orzel wrote: > There's nothing Arm specific about this feature. Move it to common as > part of a larger activity to commonalize device tree related features. > For now, select it only for ARM until others (e.g. RISC-V) verify it > works for them too. > > Signed-off-by: Michal Orzel I realize this was already committed, but ... > --- a/xen/common/Kconfig > +++ b/xen/common/Kconfig > @@ -162,6 +162,14 @@ config STATIC_MEMORY > > If unsure, say N. > > +config STATIC_EVTCHN > + bool "Static event channel support on a dom0less system" > + depends on DOM0LESS_BOOT && ARM ... I think we should strive to avoid such arch dependencies; they simply don't scale very well. Instead (if needed) HAS_* should be introduced, which each interested arch can select. In the case here, however, perhaps DOM0LESS_BOOT alone would have been sufficient as a dependency? Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 02 08:45:44 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 08:45:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1002925.1382338 (Exim 4.92) (envelope-from ) id 1uM0nZ-0004XH-HK; Mon, 02 Jun 2025 08:45:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1002925.1382338; Mon, 02 Jun 2025 08:45: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 1uM0nZ-0004XA-Di; Mon, 02 Jun 2025 08:45:37 +0000 Received: by outflank-mailman (input) for mailman id 1002925; Mon, 02 Jun 2025 08:45: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 1uM0nX-0004X2-PK for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 08:45:35 +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 f2507cb6-3f8d-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 10:45:33 +0200 (CEST) Received: by mail-wr1-x42c.google.com with SMTP id ffacd0b85a97d-3a366843fa6so2106596f8f.1 for ; Mon, 02 Jun 2025 01:45:33 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3124e2d120esm5173123a91.14.2025.06.02.01.45.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 01:45:32 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f2507cb6-3f8d-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1748853933; x=1749458733; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=kxChy2WxfDmfeUWMBhxsoVuB+hRqdSs3hVOzj1v8TQg=; b=ZgSU5yew1Zu3ZPCW3t8yVTb2qzjWSaELNct82AgQn/uOjLVSAIWm+H949QZInI/gwM DPkuGBxHmaTSi2R6MG318NtiqqQL8A0gOFeVUu1Z5zzHIV4V//COMKhdfTnHrBasEOCS MG0+fwN83i/THSg04wbOl+g+7f9uIE5TVnG/69Xr3B1WLHRYmDu7toKDu7Wac3eAs4hm tq993n4J3XozOvb4aohVdMXmh0O/6iWHfDdKdoLGhp6Lw4I/OmM0zkJzHryleZiqrfzZ BN4rDbWbehFIFVHXpfIl95EFqIzPsscAG86ZWBWZCv8naZmc9wYhS3RK3/SDupSISc0E IJNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748853933; x=1749458733; 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=kxChy2WxfDmfeUWMBhxsoVuB+hRqdSs3hVOzj1v8TQg=; b=I67PgqLDJuCnRuTUZBXNk3zG20KWxBzRmO26T3S+Mv/sRKC9c+BXxVhubqOv2Ebr3l /55h8D7rKa4Z3yBJeGoM4ftDn4/SjjFDD3llHrcNy3cEEmd537A5APgcCQ5+BWUSMckJ HOmRyM/qD5nsZjx5ZMXrRYGK+xYsil6OTgAGPip2OP8Z1sHMiEhoS/+lLpFhWbAZ+m1F s4A+1nzJvB1jhY97ALMalXrg5Yl9J/ntP+7Gp5ob3k8LsC3OE8y/TsGFuF+X5rPJdKyK B7KAMiD7afDRJFLaiPCH84UZhutom8X0vrAKf9J7mK8H2ht0KYGNqoXliwmj0NArxn+6 hKyw== X-Forwarded-Encrypted: i=1; AJvYcCWBN/nPd1aW98qhk/bBWFLO689ykW9kT4P2TAyETLFRkzNofmhWuaBl5ZveCcrJiwThv6M3SOpz2e0=@lists.xenproject.org X-Gm-Message-State: AOJu0Yye8eKOg37bk0MinIiXQWiC10GBARLurXiMBswqbuD8B5Ndbykr oCYA3sn10gHvCGPgBJK6ZiRr6mcziHK1taAoXXtbflpKFEbFJmDgVAojJ/d+Map3DA== X-Gm-Gg: ASbGncsakRjRUQfup7orv+YVFFxYtG0MNqjlGWdGfYa/YcExc199GArgHOonSL9BkPV HFsiWXXKa88SZpF2kxX7dz9X2rOIb38/NcyyBgLoGmTaRAsBmpT2bR/P/LWpxOcNucATtIbzpZz TFbUedMQl7Sfp1hMyLpbl1XzayBkwvI1X366USlMEUZdS9QwH57Z0isKjDtp7zAohTTx65Mgy8S c8QTQ/UXQm/kbjMGzaB3DDXNvFI7D4hhp6ZUNygd6cuxj4NR+8rqppjgorLblcMxf74KYk6eJup dlBOmPCVjNokO5FnrXRcCpCCqk+zyuCOOtWVEdiblOVrP7ZYh9w03X4uXFlfgZk8BXqtDD/Xf9n NYyHiTOU8ePCzQK1WJeAo9MQjwYVntnlL220u X-Google-Smtp-Source: AGHT+IF5VHVCF8ZQU+ZrAV4CMubjEUmm8X2kg4jjAFRd3H6n2PCG2M2oX9kGE/eOci5hfiumtHNyiA== X-Received: by 2002:adf:b301:0:b0:3a4:f8fa:9c94 with SMTP id ffacd0b85a97d-3a4f8fa9ce5mr7317441f8f.13.1748853933193; Mon, 02 Jun 2025 01:45:33 -0700 (PDT) Message-ID: <4cd82cbb-fc01-425d-b036-62f80a027a9b@suse.com> Date: Mon, 2 Jun 2025 10:45:36 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/5] xen/arm: Add way to disable traps on accesses to unmapped addresses To: "Edgar E. Iglesias" Cc: sstabellini@kernel.org, julien@xen.org, bertrand.marquis@arm.com, michal.orzel@amd.com, Volodymyr_Babchuk@epam.com, andrew.cooper3@citrix.com, edgar.iglesias@amd.com, Anthony PERARD , Juergen Gross , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20250530134559.1434255-1-edgar.iglesias@gmail.com> <20250530134559.1434255-2-edgar.iglesias@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: <20250530134559.1434255-2-edgar.iglesias@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 30.05.2025 15:45, Edgar E. Iglesias wrote: > --- a/xen/common/domain.c > +++ b/xen/common/domain.c > @@ -721,7 +721,8 @@ static int sanitise_domain_config(struct xen_domctl_createdomain *config) > ~(XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap | > XEN_DOMCTL_CDF_s3_integrity | XEN_DOMCTL_CDF_oos_off | > XEN_DOMCTL_CDF_xs_domain | XEN_DOMCTL_CDF_iommu | > - XEN_DOMCTL_CDF_nested_virt | XEN_DOMCTL_CDF_vpmu) ) > + XEN_DOMCTL_CDF_nested_virt | XEN_DOMCTL_CDF_vpmu | > + XEN_DOMCTL_CDF_trap_unmapped_accesses) ) > { > dprintk(XENLOG_INFO, "Unknown CDF flags %#x\n", config->flags); > return -EINVAL; > --- a/xen/include/public/domctl.h > +++ b/xen/include/public/domctl.h > @@ -66,9 +66,11 @@ struct xen_domctl_createdomain { > #define XEN_DOMCTL_CDF_nested_virt (1U << _XEN_DOMCTL_CDF_nested_virt) > /* Should we expose the vPMU to the guest? */ > #define XEN_DOMCTL_CDF_vpmu (1U << 7) > +/* Should we trap guest accesses to unmapped addresses? */ > +#define XEN_DOMCTL_CDF_trap_unmapped_accesses (1U << 8) Besides being pretty long an identifier (and that's already with "guest" not even in the name), if this is to be arch-independent, would this perhaps fit x86'es recently introduced "advanced" PVH handling of holes? See [1]. Jan [1] 104591f5dd67 ("x86/dom0: attempt to fixup p2m page-faults for PVH dom0") From xen-devel-bounces@lists.xenproject.org Mon Jun 02 09:05:01 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 09:05:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1002942.1382368 (Exim 4.92) (envelope-from ) id 1uM16F-0008CQ-L4; Mon, 02 Jun 2025 09:04:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1002942.1382368; Mon, 02 Jun 2025 09:04: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 1uM16F-0008CJ-Hi; Mon, 02 Jun 2025 09:04:55 +0000 Received: by outflank-mailman (input) for mailman id 1002942; Mon, 02 Jun 2025 09:04: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 1uM16F-00081k-3x for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 09:04:55 +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 a56f24f8-3f90-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 11:04:53 +0200 (CEST) Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-3a367ec7840so2772397f8f.2 for ; Mon, 02 Jun 2025 02:04:53 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-23506bc8b26sm66014585ad.9.2025.06.02.02.04.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 02:04:52 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a56f24f8-3f90-11f0-a300-13f23c93f187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1748855093; x=1749459893; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=ngZ6Vuh7hQeKo6LT9x+wiicwheB6dNz7u4CSeZREy7I=; b=X92C0ClR1hPXNoLhvTspdhilb+TWmjBSQ8R7x7TUH1QBD2b4mhvi0lhaPwiQD3mhNs veEyVIJz/XPeQD5krwPAMKcWs/d/0YLa2byuUBdHH1N5OlU/Qk+WDH7Up29W34owSQIB Ca5jz5dr4u1MbFRHw8K3tYm2wKVN6pP3w66lZCY3NGzijNgDmwjqJbN2Txt7BWDwLSgZ 6Ct1CQaALQXdQNrP2Y8Be3tV3ffAkW1VZI3b95DgS2PR7yQP/K5gZLddheK9KuRtyaVN uC60pd2sHik50BG5RFXARmp1ODio4W287EnkNxxECmq27WAZI98ZpISSLZyqYCR2vK8S rCNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748855093; x=1749459893; 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=ngZ6Vuh7hQeKo6LT9x+wiicwheB6dNz7u4CSeZREy7I=; b=ArPkS/CzY/JDNcFOR/iolVHu68uLlew0P6TMOUcUxSOuxWZH+M6jmea46eeZU+U0Ud 8hXz4QSmVenb8/+fXHT29HJ4DmGsPuk41w06sKBDMG2nfWGh6KfKlA97FJSqU23omsbJ sUfOfG6ppP/qpZNEaeCtfTQSdU9ePdtUC/SzngZ3sCzq5oCf94Avxz3fDgFMlQLjJ7xQ VUVP/VZ9Kfx/pwHeFrn1LOOtPDrjDOd28WxFTPONUzddvjvCrGN38I57FLUdyjCDhSkg MMgqageascFFcxzw+werl1vduJ8ybvAWfHFpNOC5N2APF4eUQLuomov6gP8z2vY6N5u3 k1KQ== X-Forwarded-Encrypted: i=1; AJvYcCUWeMnxXJck0cC+Z8r2HBdkkc9GtdKnNAeseaEx/yT+ciKG2kiyuxWHZ4LV9tdnOoaAfYGEiunn3HU=@lists.xenproject.org X-Gm-Message-State: AOJu0YwPJSBa7HCLbxyP0pAm+yUskDXfMHhE5nmYrn3DsMwNY0/HNZTv FR1UyqVwqejpj09VGZGmu6g+P10LPsR87hM9KRLkRzpg6mCs0BgnnmcjDr0q04gJzw== X-Gm-Gg: ASbGnctFlA1Uw0qDFkKMd5fIUsJ+dakDFgQpmTEQ2l5n83SL/EpDT7Z7AgNlcxN2Atk vpCjezR9adVLnVmG66vdh3BYQrjK3P3ARlCHuMp991/mqCZJDSUlMK+I2GdRe64YL7jl+9wHfOb zWEKOy+M/5yygbhjlREPIU2gzuTKeiGHF+q8DGrJ1gDGRMNG8Oud+F9/WsuHqU28uMuit9riOuh PFjNYW2ZToiIrHksEmQ1nzRMgJohXdrO3RaI1gljvxZE+VuSeP4fZeZR1H30IPonbuEZ3ALojwe MMst6YA5+WWOWBN04ZZSH3A+v6GGu/JOl+0+YI0AYiztoVgiSRiokmAlLe2sM3ApAqSXG6c7Pyp MgpGmTRV2pOMMliHyIoyBlE5nLwDuq9tNzPuy66oUw6DHPGE= X-Google-Smtp-Source: AGHT+IFx3pepFQ+9Hv0YIA9CI0Hq8K45c/r5jJbK5V+IFastwKJcN18fCSYaUS2VkFAFiXMlAxFAjA== X-Received: by 2002:a05:6000:2302:b0:3a3:6991:dcbb with SMTP id ffacd0b85a97d-3a4f89a7f8dmr7847316f8f.12.1748855092705; Mon, 02 Jun 2025 02:04:52 -0700 (PDT) Message-ID: <2c4f4c2a-b1d7-4cbb-834e-cee0fd3d2433@suse.com> Date: Mon, 2 Jun 2025 11:04:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/x86: Remove is_periodic_irq() prototype To: Andrew Cooper , Jason Andryuk Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org, "consulting@bugseng.com" References: <20250527223753.47055-1-jason.andryuk@amd.com> <1c850e02-0d87-4fd1-8504-0aee53949136@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: <1c850e02-0d87-4fd1-8504-0aee53949136@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 28.05.2025 00:39, Andrew Cooper wrote: > On 27/05/2025 11:37 pm, Jason Andryuk wrote: >> is_periodic_irq() was removed in the Fixes commit, but the prototype >> remained. Drop it now. >> >> Fixes: ddc35d1cc994 ("[HVM] Enable more than one platform timer...") >> Signed-off-by: Jason Andryuk > > Acked-by: Andrew Cooper > >> --- >> The full Fixes line is: >> Fixes: ddc35d1cc994 ("[HVM] Enable more than one platform timer (PIT/RTC/HPET) programmed as periodic timer and adds them to abstract layer, which keeps track of pending_intr_nr to avoid time interrupt lost and sync'ed timer with TSC.") > > Yeah, the older commit messages weren't as well structured as we insist > on them being these days. > > How did you find this?  inspection, or a tool? What I'm curious about: Why didn't Eclair spot this? Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 02 09:05:01 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 09:05:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1002940.1382348 (Exim 4.92) (envelope-from ) id 1uM16E-0007l0-0Q; Mon, 02 Jun 2025 09:04:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1002940.1382348; Mon, 02 Jun 2025 09:04: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 1uM16D-0007kt-Ts; Mon, 02 Jun 2025 09:04:53 +0000 Received: by outflank-mailman (input) for mailman id 1002940; Mon, 02 Jun 2025 09:04: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 1uM16C-0007kh-M3 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 09:04:52 +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 a3ee79bc-3f90-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 11:04:50 +0200 (CEST) Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-55324062ea8so5504480e87.3 for ; Mon, 02 Jun 2025 02:04:50 -0700 (PDT) Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5533791cdc3sm1507541e87.176.2025.06.02.02.04.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 02:04:48 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a3ee79bc-3f90-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748855090; x=1749459890; 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=uXSQSjQZGKU0T7Hq11MWc0zTSBaXNkHaMHY+7QO6x6g=; b=QtpUJEtN4emVwGrcotqX/eDpzHNKuCdww/VErUOkzen2o0qXAbapOfXpYMBkjJg/nI FTrYMNQ5WnlCIJ7quSdesY19ddFzDdFifompD5qhjmL6pvTkL2rKoCtCB5L8swIW49Hz xXrWRzSRcku6mS/N1Lmd29y4y2Mj7pgYTOd+tKHQJpnPe8f4U2NRG5SwMgsCygprP+cP 4pd2m8hR6NdjGLBnY11emv+T9rC0wki0fceLbEeNWH17FobJcXmGOJ9PrJ4/g49eS9v4 qE05RUfj63nJL3kfotPjW2xYOCOVHtB27j0fRbATFiDFthX8YqlY4gP/3zKlUZ5RKR8n 7jYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748855090; x=1749459890; 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=uXSQSjQZGKU0T7Hq11MWc0zTSBaXNkHaMHY+7QO6x6g=; b=Db8UaagHk59Dtu56eQoB/7QCzJ5lyp1Fq2AC0gYjvUwHmdEp8qGGXkwSqJvpcA3uBi D69Z3fSTqYZsOgwqUbC92XUHX3Mq+CIuNMjga1UeLBedrOr3+ly89Y86mdEe6lq+I/XW RTwmmcY4jEkPBKpzoh6CXWyxgBiUoVLUJjXKSmyHFGvdoYY/qV3eX51VPtCHV+OhM95Z PxbrvneVl0kp9fC1dLjKXGp6OJIHk7gLj68iOOcnlhb+GXfHKbUFjMR9X6hGe4eYV9mE F9xCNUbFCZFe6iXKw1K3WAc2sx9RrjYosMhVb19vdQb0HD2nwzzzGBC1qWhF27Ad9GLn TJFw== X-Gm-Message-State: AOJu0YwgiychfKJPh+uipYntNXZHyzTipBAfaEk0ZjcgujfXdd+Wdavk 63CCItkY7M4YMHWFdwkcOQON0geZgrptuLZGiA6kJbNkEEUs4KAGEc/VwCw9OuaYcAg= X-Gm-Gg: ASbGnctD9iAJ8D2pyONdodPZqlZWlp7jTYgKPB8ZVnVDyMbJeO7gxIHW+BoUpyMGyWc NZ0FMm2DA/I1Z9aLfpcnT6ikxxOfp7AQYfDgwx2cWTISe6A6+HpVh86WsPrhU3ikCU4zju/526Q e+VGxPr/CKIXJLBdLSHH41WX6vaBCu1aOkA8B8OXB/hR3/P722AyAJx1ajmaFHhsNOloLYURVWW k6E8XK5uF4+WDMePojAQxUmghvbg6viO/iB5uaQiXtubsYM0N009B67uxYZAKI8iY10be7sYZhd lrdJwHxPghg6QJW5c9utqSab7k59trf3GoDld70iyIek7bXsSLEzGo7M48trMJIUggjAew8Nidr 2J0tPXFndK7/TBROxWUivmieTCw== X-Google-Smtp-Source: AGHT+IFZ3gOyH/son6jCZ1hSmo99fS4cVJYmopNYROqvOmRtmwz8SBOI0kHmuXoyv34FjsA6xOK0bg== X-Received: by 2002:a05:6512:104f:b0:553:2450:5895 with SMTP id 2adb3069b0e04-55342f5212emr2046464e87.4.1748855089525; Mon, 02 Jun 2025 02:04:49 -0700 (PDT) From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: xakep.amatop@gmail.com, Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , Bertrand Marquis , Volodymyr Babchuk , Shawn Anastasio , Alistair Francis , Bob Eshleman , Connor Davis , Oleksii Kurochko Subject: [PATCH v4][PART 2 00/10] Add initial Xen Suspend-to-RAM support on ARM64 Date: Mon, 2 Jun 2025 12:04:11 +0300 Message-ID: X-Mailer: git-send-email 2.48.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Mykola Kvach This is part 2 of version 4 of the ARM Xen system suspend/resume patch series, based on earlier work by Mirela Simonovic and Mykyta Poturai. This version is ported to Xen master (4.21-unstable) and includes extensive improvements based on reviewer feedback. The patch series restructures code to improve robustness, maintainability, and implements system Suspend-to-RAM support on ARM64 hardware domains. Part 1 of the v4 patch series is available here: https://patchew.org/Xen/cover.1748337249.git.mykola._5Fkvach@epam.com/ This part also depends on the patch that introduces CONFIG_SYSTEM_SUSPEND: https://patchew.org/Xen/cover.1748381788.git.mykola._5Fkvach@epam.com/eb586049ef5180bb33e9414c4754ee2621a772bc.1748381788.git.mykola._5Fkvach@epam.com/ Previous versions: V1: https://marc.info/?l=xen-devel&m=154202231501850&w=2 V2: https://marc.info/?l=xen-devel&m=166514782207736&w=2 V3: https://lists.xen.org/archives/html/xen-devel/2025-03/msg00168.html At a high-level, this patch series provides: - Support for Host system suspend/resume via PSCI SYSTEM_SUSPEND (ARM64) - Suspend/resume infrastructure for CPU context, timers, and GICv2 - Proper error propagation and recovery throughout the suspend/resume flow Key updates in this series: - Introduced architecture-specific suspend/resume infrastructure (new `suspend.c`, `suspend.h`, low-level context save/restore in `head.S`) - Integrated GICv2 suspend and resume, including memory-backed context save/restore with error handling - Added time and IRQ suspend/resume hooks, ensuring correct timer/interrupt state across suspend cycles - Refactored domain shutdown flow to consistently propagate errors from arch-specific suspend handlers - Implemented proper PSCI SYSTEM_SUSPEND invocation and version checks - Improved state management and recovery in error cases during suspend/resume --- TODOs: - Test system suspend with LLC_COLORING enabled and verify functionality - Implement IOMMU suspend/resume handlers and integrate them into the suspend/resume path - Add GICv3 suspend/resume support if required - Enable "xl suspend" support on ARM - Properly disable Xen timer watchdog from relevant services - Add suspend/resume CI test for ARM (QEMU if feasible) - Investigate feasibility and need for implementing system suspend on ARM32 --- Changes introduced in V4: - Remove the prior tasklet-based workaround in favor of a more straightforward and safer solution. - Rework the approach by adding explicit system state checks around request_irq and release_irq calls; skip these calls during suspend and resume states to avoid unsafe memory operations when IRQs are disabled. - Prevent reinitialization of local IRQ descriptors on system resume. - Restore the state of local IRQs during system resume for secondary CPUs. - Drop code for saving and restoring VCPU context (see part 1 of the patch series for details). - Remove IOMMU suspend and resume calls until these features are implemented. - Move system suspend logic to arch_domain_shutdown, invoked from domain_shutdown. - Add console_end_sync to the resume path after system suspend. - Drop unnecessary DAIF masking; interrupts are already masked on resume. - Remove leftover TLB flush instructions; flushing is handled in enable_mmu. - Avoid setting x19 in hyp_resume as it is not required. - Replace prepare_secondary_mm with set_init_ttbr, and call it from system_suspend. - Produce a build-time error for ARM32 when CONFIG_SYSTEM_SUSPEND is enabled. - Use register_t instead of uint64_t in the cpu_context structure. - Apply minor fixes such as renaming functions, updating comments, and modifying commit messages to accurately reflect the changes introduced by this patch series. For earlier changelogs, please refer to the previous cover letters. Mirela Simonovic (7): xen/x86: Move freeze/thaw_domains to common code xen/arm: Add suspend and resume timer helpers xen/arm: Implement GIC suspend/resume functions (gicv2 only) xen/arm: Add support for system suspend triggered by hardware domain xen/arm: Implement PSCI SYSTEM_SUSPEND call (host interface) xen/arm: Resume memory management on Xen resume xen/arm: Save/restore context on suspend/resume Mykola Kvach (3): xen/arm: Prevent crash during disable_nonboot_cpus on suspend xen/arm: irq: avoid local IRQ descriptors reinit on system resume xen/arm: irq: Restore state of local IRQs during system resume xen/arch/arm/Kconfig | 1 + xen/arch/arm/Makefile | 1 + xen/arch/arm/arm64/head.S | 110 +++++++++++++++++++ xen/arch/arm/domain.c | 21 +++- xen/arch/arm/gic-v2.c | 154 ++++++++++++++++++++++++++ xen/arch/arm/gic.c | 35 ++++++ xen/arch/arm/include/asm/gic.h | 12 +++ xen/arch/arm/include/asm/mm.h | 2 + xen/arch/arm/include/asm/psci.h | 1 + xen/arch/arm/include/asm/suspend.h | 44 ++++++++ xen/arch/arm/include/asm/time.h | 5 + xen/arch/arm/irq.c | 48 +++++++++ xen/arch/arm/mmu/smpboot.c | 2 +- xen/arch/arm/psci.c | 23 +++- xen/arch/arm/suspend.c | 167 +++++++++++++++++++++++++++++ xen/arch/arm/tee/ffa_notif.c | 2 +- xen/arch/arm/time.c | 56 +++++++--- xen/arch/arm/vpsci.c | 4 - xen/arch/ppc/stubs.c | 2 +- xen/arch/riscv/stubs.c | 2 +- xen/arch/x86/acpi/power.c | 25 ----- xen/arch/x86/domain.c | 4 +- xen/common/domain.c | 34 +++++- xen/include/xen/domain.h | 2 +- xen/include/xen/sched.h | 3 + 25 files changed, 709 insertions(+), 51 deletions(-) create mode 100644 xen/arch/arm/include/asm/suspend.h create mode 100644 xen/arch/arm/suspend.c -- 2.48.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 02 09:05:01 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 09:05:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1002946.1382404 (Exim 4.92) (envelope-from ) id 1uM16K-0000Yr-Tm; Mon, 02 Jun 2025 09:05:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1002946.1382404; Mon, 02 Jun 2025 09:05: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 1uM16K-0000Y6-Li; Mon, 02 Jun 2025 09:05:00 +0000 Received: by outflank-mailman (input) for mailman id 1002946; Mon, 02 Jun 2025 09: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 1uM16J-0007kh-Vr for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 09:04:59 +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 a89ace8b-3f90-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 11:04:58 +0200 (CEST) Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-54e816aeca6so5395978e87.2 for ; Mon, 02 Jun 2025 02:04:58 -0700 (PDT) Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5533791cdc3sm1507541e87.176.2025.06.02.02.04.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 02:04:57 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a89ace8b-3f90-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748855098; x=1749459898; darn=lists.xenproject.org; h=content-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=RiaE/YXxsWcT0rjjz9SjADvJ7JVMLOm41080TZwDgkw=; b=ijoWbsD1V7y9lQ+/gVXTVzayAMW0UlokSVUX5g0WZWbRyn7/IBHqyW24dqdqt1RJ1m 18mt4BEbYEwbSV/EoqG8mls6BinlCTVVsJdaz0dKsRg0ZDfwxxzGe3XgtG7U2lQO1GTH O9kGaIkZ9kpTPw+RbAMDPFzMFQm4hUYQgx2QlMsXwPpkD5RDYmjoIzww8lqFWdoaOUpg kX2TJsP1Tq2sBmU59TqSDmMweb9ZHGub7Ed9irWQKidYHIGS0yFx45FyO45YvHw4V6pR /uTuyuIEPV0G4FFMhbO3gQADVgjCR+f/S+dfYlNHSQs6/8zWknrpoVisqiV34hvoDF/4 PVDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748855098; x=1749459898; 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=RiaE/YXxsWcT0rjjz9SjADvJ7JVMLOm41080TZwDgkw=; b=fTnz3cz+ptbfj0hGuf1sTJdkADw1986Trd3CMPRlNleCXvz+rzG++EbE8eCYwnm0Qj /4/MRN2ITTgRqJuAMjHg704mGzsIJP3SV5A03fZ6Pcfay2gPCPmkrA0bJomF8Bx/BB1d NhgEcE4qglpodO9Eq5TXBGVTzLxALMMg3iXf7uNS4/05+nIvYG/20n4/RiMt2CtSBSRS YIGN6LCW9GwfZ99gMVEpBIVj8D/qj87jSQUYE7uAs+WDbaR4MjKSnbV40mzqw+Js1cho 10QeKG0+VpdzKiTHhvUwI3NEYDsaYuW8U3M9HBBrTf9eFG+WFkA7AWKckTijvRTQ0d85 zGpw== X-Gm-Message-State: AOJu0Yzr8AgXJ6UH9oVRvBhgkaz000wNhD7nWzj2rG6EAhHWIC05fEbb RqCe9duk8Dt/F5lRJBHNv3v+7ntIghi9Zp0PedTAOlqh3g2icCKE6B/V56QNwsui X-Gm-Gg: ASbGncuswR0OiqA+UP2YrCI2ci5hTSzk2gA5/iivrvYZjbK9KIb61o0uEjKJ1cv6SU8 6ixFT4wT0140n+m8M26wcymuSrUFmABA7k3Ni8AkBxg/5rdY0ULXUKg/jJYO/oZXM5YRZTMrgyT /XfWtdto4aE//qHz3/x3mrIdgT2/p1aec4Q/BhDxjlFDq/r2E/yW0k+MnC9YqxOYctQCBSn1jmx 4pdIakiKLDJAUYb/G8/M58da7fccgTCL9cXfXPIkqxYV9BRJcrf3pyNTcGcNUKNchuyzdEqRbdD /et4p2Y9FLaMejqqDx4QsbZV4Gi8bZllBezQDfveJobCeYhBxkiGlvIXornVWok82WFJq94qF7Q zte7FpuO9sUtP8eQ= X-Google-Smtp-Source: AGHT+IHT93ClrOVTknOM+Ss/N0Bog9/86dU4UzyGwalCHDLaSj4MeQjn7jNqW8uBN0iRuRnBK45f8w== X-Received: by 2002:a05:6512:a91:b0:553:3654:3319 with SMTP id 2adb3069b0e04-5533b930abamr4209993e87.43.1748855097582; Mon, 02 Jun 2025 02:04:57 -0700 (PDT) From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: xakep.amatop@gmail.com, Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v4][PART 2 05/10] xen/arm: irq: avoid local IRQ descriptors reinit on system resume Date: Mon, 2 Jun 2025 12:04:16 +0300 Message-ID: <36ef314ff29957fb9fa727319535a0479b80ca28.1748848482.git.mykola_kvach@epam.com> X-Mailer: git-send-email 2.48.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Mykola Kvach On ARM, during system resume, CPUs are brought online again. This normally triggers init_local_irq_data, which reinitializes IRQ descriptors for banked interrupts (SGIs and PPIs). These descriptors are statically allocated per CPU and retain valid state across suspend/resume cycles. Re-initializing them on resume is unnecessary and may result in loss of interrupt configuration or restored state. This patch skips init_local_irq_data when system_state is set to SYS_STATE_resume to preserve banked IRQ descs state during resume. Signed-off-by: Mykola Kvach --- xen/arch/arm/irq.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c index 03fbb90c6c..372716a73b 100644 --- a/xen/arch/arm/irq.c +++ b/xen/arch/arm/irq.c @@ -122,6 +122,10 @@ static int cpu_callback(struct notifier_block *nfb, unsigned long action, switch ( action ) { case CPU_UP_PREPARE: + /* Skip local IRQ cleanup on resume */ + if ( system_state == SYS_STATE_resume ) + break; + rc = init_local_irq_data(cpu); if ( rc ) printk(XENLOG_ERR "Unable to allocate local IRQ for CPU%u\n", -- 2.48.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 02 09:05:01 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 09:05:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1002941.1382354 (Exim 4.92) (envelope-from ) id 1uM16E-0007s0-Dw; Mon, 02 Jun 2025 09:04:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1002941.1382354; Mon, 02 Jun 2025 09:04:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uM16E-0007qN-A1; Mon, 02 Jun 2025 09:04:54 +0000 Received: by outflank-mailman (input) for mailman id 1002941; Mon, 02 Jun 2025 09:04: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 1uM16D-0007kh-Ch for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 09:04:53 +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 a49eed8e-3f90-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 11:04:51 +0200 (CEST) Received: by mail-lf1-x12f.google.com with SMTP id 2adb3069b0e04-5534f3722caso252521e87.0 for ; Mon, 02 Jun 2025 02:04:51 -0700 (PDT) Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5533791cdc3sm1507541e87.176.2025.06.02.02.04.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 02:04:50 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a49eed8e-3f90-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748855091; x=1749459891; darn=lists.xenproject.org; h=content-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=Da/Gwj5SRn8BTf5+gC6RkaoWtjYeeb+pM91gG3eXP48=; b=WR3l8b//HTc/vvydLQNzqKH2jZoqJMoFtrFpzqgrYQPUH6MXU8THOumo8n404ixRI2 RGxFsmuwH1drmlFovrnFeLlMVD9QmHZrTahXTcBz2GCkNowBvyoMj7jbpqM2OQE7GSrR 5e7Vq6k1+T61WtN4QMr2a7V03bO/fOiNge4jWH5bdrAHhTrDpVTCbfJEl6/O8qXdfYM7 kOned9m/DghJ4+GgUfYPUb8So0lS7BphcfRQ6LHJWko98qvx6PGSrzH1PCNpx9ANogjp 1kJUkfEhsw89dQvlrVrG/HkVBQJ+ansNuX4imaCi4dIGXve6mDdUV6D4VT1Dg8p92OMu Sp4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748855091; x=1749459891; 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=Da/Gwj5SRn8BTf5+gC6RkaoWtjYeeb+pM91gG3eXP48=; b=SnFdF6Hxf+muuaNfSSo1bKD6t67vMHAUmp5DMs4wFVQD1Fnn4ZmzjCwk2zdUzIObIC 90jMPSScRlo7n7Mx51j68N6SPkvt2FDzIJdX9xTmdEFoEaITUsC3kNYQIrfnHlYLlcpE UnHfmM12DWCy0O31QgR8gMpJ4HjFKBvKXeA69oOnPKsn5d2f4EoTIPc1UJmmCv8ClY2X LuwD9mO2MBSc+oEeUBsMdAYnJTyaZpEF14ilN8quxfShQFV/vNjLaR2Rg310lvuhGH8h bhWvsvc1XPwr6spj1HLw8hMhmyFRLTX1rrMaeznTNWm8kywJM6gCuTAOZq+yPKSjt16p BqMg== X-Gm-Message-State: AOJu0Yx3wM+sD2QSOmtPfBtvDY2+al5/3jnop+t6tv16o2McSRQ6Yfhm AwvXg2GUVHeGO6xABcqsWhkTEyyjuKHoCeZB2/4PE0TNn5mgAzK7H1jIH34yqdQg X-Gm-Gg: ASbGnctaZ/53f0YRPEPCkBFUhuGY/LMbB9CNOVsWvIyEDN7gdil1RQ7cos1CnxvVATp 8Hxzze1/us7avs4oq0NI+9TmgIx81at9rfNEkIo0R0/q+0Tu1eFSG7IeTT2K/vkV7aGHSpsFAjH D0e8ELsLPFuGqWEHLB6LcwFeB821jratEyDYQXPP3GzbzH6LUgXCto87iuWlgAeDrxtfJWQlg0A eKMfxWc5xzBS8t+0t8NVQzbT16g2H8w/JiEs4ByK15ZrtOYoiB4PkwMD13ru+TGpMi7qQT0k3fV N8H0uQUnUt9AFGHcDWcBx+2DDlxTdvHrnvLOMROT9vN741/xZuvlyqIgCEOXtyhRfzX0bgRKWXH A95bEO59MTam1KZ8= X-Google-Smtp-Source: AGHT+IGSGQlhdjKcLLakl9LRgHis7Wp+dmnc2fkNECPVD/CuspGse8lLtiZIhN0uW5p+NxZ0WdrUqQ== X-Received: by 2002:a05:6512:3b2a:b0:553:3892:5ecc with SMTP id 2adb3069b0e04-55342f928d0mr1769232e87.36.1748855090890; Mon, 02 Jun 2025 02:04:50 -0700 (PDT) From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: xakep.amatop@gmail.com, Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini Subject: [PATCH v4][PART 2 01/10] xen/x86: Move freeze/thaw_domains to common code Date: Mon, 2 Jun 2025 12:04:12 +0300 Message-ID: X-Mailer: git-send-email 2.48.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Mirela Simonovic The freeze_domains and thaw_domains functions are currently defined in x86-specific suspend code. These functions are also useful on other architectures, such as ARM, for implementing system-wide suspend and resume functionality. This patch moves these functions to common code so they can be reused across architectures. Signed-off-by: Mirela Simonovic Signed-off-by: Saeed Nowshadi Signed-off-by: Mykyta Poturai Signed-off-by: Mykola Kvach --- Changes in v4: - Enhanced commit message with a clearer explanation of the rationale for moving freeze/thaw_domains to common code. --- xen/arch/x86/acpi/power.c | 25 ------------------------- xen/common/domain.c | 25 +++++++++++++++++++++++++ xen/include/xen/sched.h | 3 +++ 3 files changed, 28 insertions(+), 25 deletions(-) diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c index 448aa9f3a7..2ac162c997 100644 --- a/xen/arch/x86/acpi/power.c +++ b/xen/arch/x86/acpi/power.c @@ -138,31 +138,6 @@ static void device_power_up(enum dev_power_saved saved) } } -static void freeze_domains(void) -{ - struct domain *d; - - rcu_read_lock(&domlist_read_lock); - /* - * Note that we iterate in order of domain-id. Hence we will pause dom0 - * first which is required for correctness (as only dom0 can add domains to - * the domain list). Otherwise we could miss concurrently-created domains. - */ - for_each_domain ( d ) - domain_pause(d); - rcu_read_unlock(&domlist_read_lock); -} - -static void thaw_domains(void) -{ - struct domain *d; - - rcu_read_lock(&domlist_read_lock); - for_each_domain ( d ) - domain_unpause(d); - rcu_read_unlock(&domlist_read_lock); -} - static void acpi_sleep_prepare(u32 state) { void *wakeup_vector_va; diff --git a/xen/common/domain.c b/xen/common/domain.c index abf1969e60..58c5ffc466 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -2405,6 +2405,31 @@ domid_t get_initial_domain_id(void) return hardware_domid; } +void freeze_domains(void) +{ + struct domain *d; + + rcu_read_lock(&domlist_read_lock); + /* + * Note that we iterate in order of domain-id. Hence we will pause dom0 + * first which is required for correctness (as only dom0 can add domains to + * the domain list). Otherwise we could miss concurrently-created domains. + */ + for_each_domain ( d ) + domain_pause(d); + rcu_read_unlock(&domlist_read_lock); +} + +void thaw_domains(void) +{ + struct domain *d; + + rcu_read_lock(&domlist_read_lock); + for_each_domain ( d ) + domain_unpause(d); + rcu_read_unlock(&domlist_read_lock); +} + /* * Local variables: * mode: C diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h index 559d201e0c..071ee19062 100644 --- a/xen/include/xen/sched.h +++ b/xen/include/xen/sched.h @@ -1070,6 +1070,9 @@ static inline struct vcpu *domain_vcpu(const struct domain *d, return vcpu_id >= d->max_vcpus ? NULL : d->vcpu[idx]; } +void freeze_domains(void); +void thaw_domains(void); + void cpu_init(void); /* -- 2.48.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 02 09:05:01 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 09:05:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1002943.1382378 (Exim 4.92) (envelope-from ) id 1uM16H-0008Rj-Ru; Mon, 02 Jun 2025 09:04:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1002943.1382378; Mon, 02 Jun 2025 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 1uM16H-0008RZ-Oi; Mon, 02 Jun 2025 09:04:57 +0000 Received: by outflank-mailman (input) for mailman id 1002943; Mon, 02 Jun 2025 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 1uM16G-0007kh-Gw for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 09:04:56 +0000 Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [2a00:1450:4864:20::133]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a6756e62-3f90-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 11:04:55 +0200 (CEST) Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-551fe46934eso4789596e87.1 for ; Mon, 02 Jun 2025 02:04:54 -0700 (PDT) Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5533791cdc3sm1507541e87.176.2025.06.02.02.04.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 02:04:53 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a6756e62-3f90-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748855094; x=1749459894; darn=lists.xenproject.org; h=content-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=uqPcozH5cY7WTdc/VNhtz0ZQbmCe6X/v3JhqZHPKizE=; b=ZVxmGu10AD80T/aX8tjvpkfnwdwwNWZ1Q5QtVFlL6jgZf9h6HEaAP7nSLceSVp8sTw e103hUe2USC7pmv4VDkpRZpFFXktKXXa9/tEt7Ba5NuqBCw2I6ZZwONAQ8CAulhsusjf 8KEqhmp+azMXiYIiDtmjI6UiYBZc1Mp3TIH8+yVGc+BbN5gA8yw0kGlqxc8t3QSyIrl0 yoikQn8JbkdOg1smVhMpdz1M1JxDzgtV5Fg2JfGGlc/BkmmRq7aZPtQwlSZfWQRkJJpl d4MXRyGm/lysnhMC90IfhbaAyUQEC78wcP2k6wsPtnmZPTydHPM22TI3jpUaLguvGk8F 87Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748855094; x=1749459894; 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=uqPcozH5cY7WTdc/VNhtz0ZQbmCe6X/v3JhqZHPKizE=; b=RBIdOQIuGB0gx4Ma8CcNhGaI/6c24zsFlH8+yWWzKMM/KegRY3CZ5Nb9VPkZlxM3fF 5u2QuDOqDI8Zm4LFDUcOxrP6EiZYfFjlujYyoEPp/rUFQndtYA7p1ogUwvMHkuD8pWwv CprKs7P2XAjXorkFehmyQAw4ouMdyIGrnUkPLWU7GFF38GeN2Ou+TSv+FSr0MN0r2RJK 66mdyFzCQtRe8nz3CQWJh4SD0zFqOFtKVsyyErnJserqSm654Q6J8Glj973hbp2FFIPd kM7irSGe6an848BML4u9MMKaeLaJiYP46A6SxO4B3vCykB9gtrFqVFUOG0yncWXeJtQs 4WvA== X-Gm-Message-State: AOJu0YyXrwYTaMcazVjQwp4YFb0yfdt8vHOp+4sb5UxHwrhm6a6AXeRL 1KPegG17nCoHzSYCtGVM4a8I9YkDg0HYab2ZzS6QaTOmlYBqgBcG4Tw+NM7MmvCr X-Gm-Gg: ASbGncut6InjXlKY7uekZRyCE5Hd+zwA7HiAV7BQBdKf3lyKnCrz2vfwJqGXSpdF0il 0xkR6lCYWLH/gedE2XKDpsiOleia8zu0UL966hEZspyCgnpsn4Kq1k12XoaBpcvf/1WgAGgcyvt p47y1fDqvRuHQczh40DOyBd3R/KJh2dybNSu51DN4pi+zqCEAf8/gB64hIk6z/3I3PY7Z0HhY+T 7pbOtw7dSyrrj2VW3SsNDg/yI0909egj26v78oB4sOCT9aKW3iyFwMj5w+8w+JSgaIVGXqoUrQS K25eDyLLmHFMuIQaDFtcHp7p5QTWofJYFmpKUjKW1sf+4Imq3ri2cyWwvWkdsYIzJjpK8qMiaPn Z3CyleiTAZ7Wt9gI= X-Google-Smtp-Source: AGHT+IFEWk5B09gxMmpBvB5cg/vxGWxO+XS2KdbPTd/vJrhO5L40I2jeOSWpJi89b7J3UM5ZWg5JqQ== X-Received: by 2002:a05:6512:3b86:b0:54a:c4af:15 with SMTP id 2adb3069b0e04-5533ba8be3emr3554424e87.19.1748855093947; Mon, 02 Jun 2025 02:04:53 -0700 (PDT) From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: xakep.amatop@gmail.com, Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v4][PART 2 02/10] xen/arm: Add suspend and resume timer helpers Date: Mon, 2 Jun 2025 12:04:13 +0300 Message-ID: X-Mailer: git-send-email 2.48.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Mirela Simonovic Timer interrupts must be disabled while the system is suspended to prevent spurious wake-ups. Suspending the timers involves disabling both the EL1 physical timer and the EL2 hypervisor timer. Resuming consists of raising the TIMER_SOFTIRQ, which prompts the generic timer code to reprogram the EL2 timer as needed. Re-enabling of the EL1 timer is left to the entity that uses it. Introduce a new helper, disable_physical_timers, to encapsulate disabling of the physical timers. Signed-off-by: Mirela Simonovic Signed-off-by: Saeed Nowshadi Signed-off-by: Mykola Kvach --- Changes in V4: - Rephrased comment and commit message for better clarity - Created separate function for disabling physical timers Changes in V3: - time_suspend and time_resume are now conditionally compiled under CONFIG_SYSTEM_SUSPEND --- xen/arch/arm/include/asm/time.h | 5 +++++ xen/arch/arm/time.c | 38 +++++++++++++++++++++++++++------ 2 files changed, 37 insertions(+), 6 deletions(-) diff --git a/xen/arch/arm/include/asm/time.h b/xen/arch/arm/include/asm/time.h index 49ad8c1a6d..f4fd0c6af5 100644 --- a/xen/arch/arm/include/asm/time.h +++ b/xen/arch/arm/include/asm/time.h @@ -108,6 +108,11 @@ void preinit_xen_time(void); void force_update_vcpu_system_time(struct vcpu *v); +#ifdef CONFIG_SYSTEM_SUSPEND +void time_suspend(void); +void time_resume(void); +#endif /* CONFIG_SYSTEM_SUSPEND */ + #endif /* __ARM_TIME_H__ */ /* * Local variables: diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c index e74d30d258..ad984fdfdd 100644 --- a/xen/arch/arm/time.c +++ b/xen/arch/arm/time.c @@ -303,6 +303,14 @@ static void check_timer_irq_cfg(unsigned int irq, const char *which) "WARNING: %s-timer IRQ%u is not level triggered.\n", which, irq); } +/* Disable physical timers for EL1 and EL2 on the current CPU */ +static inline void disable_physical_timers(void) +{ + WRITE_SYSREG(0, CNTP_CTL_EL0); /* Physical timer disabled */ + WRITE_SYSREG(0, CNTHP_CTL_EL2); /* Hypervisor's timer disabled */ + isb(); +} + /* Set up the timer interrupt on this CPU */ void init_timer_interrupt(void) { @@ -310,9 +318,7 @@ void init_timer_interrupt(void) WRITE_SYSREG64(0, CNTVOFF_EL2); /* No VM-specific offset */ /* Do not let the VMs program the physical timer, only read the physical counter */ WRITE_SYSREG(CNTHCTL_EL2_EL1PCTEN, CNTHCTL_EL2); - WRITE_SYSREG(0, CNTP_CTL_EL0); /* Physical timer disabled */ - WRITE_SYSREG(0, CNTHP_CTL_EL2); /* Hypervisor's timer disabled */ - isb(); + disable_physical_timers(); request_irq(timer_irq[TIMER_HYP_PPI], 0, htimer_interrupt, "hyptimer", NULL); @@ -330,9 +336,7 @@ void init_timer_interrupt(void) */ static void deinit_timer_interrupt(void) { - WRITE_SYSREG(0, CNTP_CTL_EL0); /* Disable physical timer */ - WRITE_SYSREG(0, CNTHP_CTL_EL2); /* Disable hypervisor's timer */ - isb(); + disable_physical_timers(); release_irq(timer_irq[TIMER_HYP_PPI], NULL); release_irq(timer_irq[TIMER_VIRT_PPI], NULL); @@ -372,6 +376,28 @@ void domain_set_time_offset(struct domain *d, int64_t time_offset_seconds) /* XXX update guest visible wallclock time */ } +#ifdef CONFIG_SYSTEM_SUSPEND + +void time_suspend(void) +{ + disable_physical_timers(); +} + +void time_resume(void) +{ + /* + * Raising the timer softirq triggers generic code to call reprogram_timer + * with the correct timeout (not known here). + * + * No further action is needed to restore timekeeping after power down, + * since the system counter is unaffected. See ARM DDI 0487 L.a, D12.1.2 + * "The system counter must be implemented in an always-on power domain." + */ + raise_softirq(TIMER_SOFTIRQ); +} + +#endif /* CONFIG_SYSTEM_SUSPEND */ + static int cpu_time_callback(struct notifier_block *nfb, unsigned long action, void *hcpu) -- 2.48.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 02 09:05:01 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 09:05:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1002945.1382398 (Exim 4.92) (envelope-from ) id 1uM16K-0000VU-HH; Mon, 02 Jun 2025 09:05:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1002945.1382398; Mon, 02 Jun 2025 09:05: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 1uM16K-0000VJ-DR; Mon, 02 Jun 2025 09:05:00 +0000 Received: by outflank-mailman (input) for mailman id 1002945; Mon, 02 Jun 2025 09:04: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 1uM16I-0007kh-RD for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 09:04:58 +0000 Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [2a00:1450:4864:20::133]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a7e47e97-3f90-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 11:04:57 +0200 (CEST) Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-551ed563740so5335407e87.2 for ; Mon, 02 Jun 2025 02:04:57 -0700 (PDT) Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5533791cdc3sm1507541e87.176.2025.06.02.02.04.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 02:04:55 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a7e47e97-3f90-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748855096; x=1749459896; darn=lists.xenproject.org; h=content-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=t3qd7wn/+BTaUGKnbQ/zLRIfyUfmlIN1J0Bwt1qcE10=; b=WbGXqU9a88+HORAGiOjUP8+B+eIE86O8z3KV/Bcoxoh19SaPQMYog2NRJ07SdHAyl6 4VgxgCjJdZcbaX2pR3LeVCZkfmYNxR+i2w9AoFRFM+Xe6GWSVhycM0y12dbRvCIGhqlz mZ+lTmJE/1t/QQGjmqGL/tnJ6B35Xp6lPtJ1hsXos/prFL5EtYCU1Yc82R3W0rBfqZKB KY0kjDt1EKgXxKuH+G/wQnuuECU6ZXfaLS0ERcDKJVIto2+P0/0zI7cWJmtJQNQHTBYN HWMg11afFY4b7ti7V/1bhZZQSEZTU/7MlOkA2netRfJkMNWA2rKZij1EWkoKgDYhxtgQ +HbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748855096; x=1749459896; 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=t3qd7wn/+BTaUGKnbQ/zLRIfyUfmlIN1J0Bwt1qcE10=; b=j635ycgOAaqvuXveHQ1JJlvnDXaaCoq2njBffEgQO4EezFrbvqW6dXrmP/e/LwpHXU bLIJ10Yv2GS9eZg7sV1qcBECLyu+Bul09DZdS3fOu+qn1GRU9LZn+l1fzhd2mhA8Oihr T3mESP5aFhgdyTyjPrvIML21l29aTxixd7v5u5SK9gbHYGqkDHxA7BscwYvSTjffMb+Y cBhlHuvbh6u14Cv5M09f5tTy2nH2yfwqBBnxAIMsYaSop4jWl8onLommCbZgZVjixzGb E5rkavQfjwiKMKVkLmYgi/WE4yIOuSsVc8KxK50MYSy5N0OXSEmojeXBkcu7/KvCBKcC qHog== X-Gm-Message-State: AOJu0YyWzGAGFHfgJqdn5mDliYi5t/W0+Z9BhDeorBaN7fJXYFT1DyLy DGafaXQClFJO2d/O1TRv1JZ2L3NBTSLXJPPluviPEYb73C0J5wY6He4ZP4uvVa0x X-Gm-Gg: ASbGncs0A7F9NGYYhCx6ntSHZ1pqGvNfHx2llE5WcIUZgNfnaXgAYxV5yaUkQcoPTQE BSeZe9gE0I5pbMT+47uE+XXsghVwAFohyKbO0RYzU+E1fdrwtydTyW2Tp8MLpk14yh1DgrkqUhf I6ph+7MYE0SDN1Gb/lwYJD8RVM2gOyual1SahyZFwiDsN+940L1pGAUq1jJ1KWDdMyUfGUxClwe N+1ezCJG4Yma11TBDR1r5SDt/5AZ47Ij+RtwFi/5tCNqRjt6OS+zDCv25GludHQ/xAiBfrA86po IcrrHBgwE44Dee5+Q0CRgkCmgyFMUUnyzIR00De91Y1Jr7nmwbUzdTT/hT8G69CFk2UTrdU7ET3 9GT9Q4r3OKiw1uk0= X-Google-Smtp-Source: AGHT+IGi3/KfBHShC4Zm7tMGUh4qiGmrbniKVBV5ymlS3Q6WgyqayZLY6h/yrit9MCILP5HY1wYUag== X-Received: by 2002:a05:6512:2215:b0:553:3127:b00 with SMTP id 2adb3069b0e04-5533b90b7d6mr4336691e87.32.1748855096396; Mon, 02 Jun 2025 02:04:56 -0700 (PDT) From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: xakep.amatop@gmail.com, Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v4][PART 2 04/10] xen/arm: Prevent crash during disable_nonboot_cpus on suspend Date: Mon, 2 Jun 2025 12:04:15 +0300 Message-ID: X-Mailer: git-send-email 2.48.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Mykola Kvach If we call disable_nonboot_cpus on ARM64 with system_state set to SYS_STATE_suspend, the following assertion will be triggered: ``` (XEN) [ 25.582712] Disabling non-boot CPUs ... (XEN) [ 25.587032] Assertion '!in_irq() && (local_irq_is_enabled() || num_online_cpus() <= 1)' failed at common/xmalloc_tlsf.c:714 [...] (XEN) [ 25.975069] Xen call trace: (XEN) [ 25.978353] [<00000a000022e098>] xfree+0x130/0x1a4 (PC) (XEN) [ 25.984314] [<00000a000022e08c>] xfree+0x124/0x1a4 (LR) (XEN) [ 25.990276] [<00000a00002747d4>] release_irq+0xe4/0xe8 (XEN) [ 25.996152] [<00000a0000278588>] time.c#cpu_time_callback+0x44/0x60 (XEN) [ 26.003150] [<00000a000021d678>] notifier_call_chain+0x7c/0xa0 (XEN) [ 26.009717] [<00000a00002018e0>] cpu.c#cpu_notifier_call_chain+0x24/0x48 (XEN) [ 26.017148] [<00000a000020192c>] cpu.c#_take_cpu_down+0x28/0x34 (XEN) [ 26.023801] [<00000a0000201944>] cpu.c#take_cpu_down+0xc/0x18 (XEN) [ 26.030281] [<00000a0000225c5c>] stop_machine.c#stopmachine_action+0xbc/0xe4 (XEN) [ 26.038057] [<00000a00002264bc>] tasklet.c#do_tasklet_work+0xb8/0x100 (XEN) [ 26.045229] [<00000a00002268a4>] do_tasklet+0x68/0xb0 (XEN) [ 26.051018] [<00000a000026e120>] domain.c#idle_loop+0x7c/0x194 (XEN) [ 26.057585] [<00000a0000277e30>] start_secondary+0x21c/0x220 (XEN) [ 26.063978] [<00000a0000361258>] 00000a0000361258 ``` This happens because before invoking take_cpu_down via the stop_machine_run function on the target CPU, stop_machine_run requests the STOPMACHINE_DISABLE_IRQ state on that CPU. Releasing memory in the release_irq function then triggers the assertion: /* * Heap allocations may need TLB flushes which may require IRQs to be * enabled (except when only 1 PCPU is online). */ This patch adds system state checks to guard calls to request_irq and release_irq. These calls are now skipped when system_state is SYS_STATE_{resume,suspend}, preventing unsafe operations during suspend/resume handling. Signed-off-by: Mykola Kvach --- Changes in V4: - removed the prior tasklet-based workaround in favor of a more straightforward and safer solution - reworked the approach by adding explicit system state checks around request_irq and release_irq calls, skips these calls during suspend and resume states to avoid unsafe memory operations when IRQs are disabled --- xen/arch/arm/gic.c | 6 ++++++ xen/arch/arm/tee/ffa_notif.c | 2 +- xen/arch/arm/time.c | 18 ++++++++++++------ 3 files changed, 19 insertions(+), 7 deletions(-) diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c index a018bd7715..9856cb1592 100644 --- a/xen/arch/arm/gic.c +++ b/xen/arch/arm/gic.c @@ -388,6 +388,9 @@ void gic_dump_info(struct vcpu *v) void init_maintenance_interrupt(void) { + if ( system_state == SYS_STATE_resume ) + return; + request_irq(gic_hw_ops->info->maintenance_irq, 0, maintenance_interrupt, "irq-maintenance", NULL); } @@ -461,6 +464,9 @@ static int cpu_gic_callback(struct notifier_block *nfb, switch ( action ) { case CPU_DYING: + if ( system_state == SYS_STATE_suspend ) + break; + /* This is reverting the work done in init_maintenance_interrupt */ release_irq(gic_hw_ops->info->maintenance_irq, NULL); break; diff --git a/xen/arch/arm/tee/ffa_notif.c b/xen/arch/arm/tee/ffa_notif.c index 00efaf8f73..06f715a82b 100644 --- a/xen/arch/arm/tee/ffa_notif.c +++ b/xen/arch/arm/tee/ffa_notif.c @@ -347,7 +347,7 @@ void ffa_notif_init_interrupt(void) { int ret; - if ( notif_enabled && notif_sri_irq < NR_GIC_SGI ) + if ( notif_enabled && notif_sri_irq < NR_GIC_SGI && system_state != SYS_STATE_resume ) { /* * An error here is unlikely since the primary CPU has already diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c index ad984fdfdd..b2e07ade43 100644 --- a/xen/arch/arm/time.c +++ b/xen/arch/arm/time.c @@ -320,10 +320,13 @@ void init_timer_interrupt(void) WRITE_SYSREG(CNTHCTL_EL2_EL1PCTEN, CNTHCTL_EL2); disable_physical_timers(); - request_irq(timer_irq[TIMER_HYP_PPI], 0, htimer_interrupt, - "hyptimer", NULL); - request_irq(timer_irq[TIMER_VIRT_PPI], 0, vtimer_interrupt, - "virtimer", NULL); + if ( system_state != SYS_STATE_resume ) + { + request_irq(timer_irq[TIMER_HYP_PPI], 0, htimer_interrupt, + "hyptimer", NULL); + request_irq(timer_irq[TIMER_VIRT_PPI], 0, vtimer_interrupt, + "virtimer", NULL); + } check_timer_irq_cfg(timer_irq[TIMER_HYP_PPI], "hypervisor"); check_timer_irq_cfg(timer_irq[TIMER_VIRT_PPI], "virtual"); @@ -338,8 +341,11 @@ static void deinit_timer_interrupt(void) { disable_physical_timers(); - release_irq(timer_irq[TIMER_HYP_PPI], NULL); - release_irq(timer_irq[TIMER_VIRT_PPI], NULL); + if ( system_state != SYS_STATE_suspend ) + { + release_irq(timer_irq[TIMER_HYP_PPI], NULL); + release_irq(timer_irq[TIMER_VIRT_PPI], NULL); + } } /* Wait a set number of microseconds */ -- 2.48.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 02 09:05:01 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 09:05:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1002944.1382383 (Exim 4.92) (envelope-from ) id 1uM16I-0008V5-6Y; Mon, 02 Jun 2025 09:04:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1002944.1382383; Mon, 02 Jun 2025 09:04:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uM16I-0008Ud-0l; Mon, 02 Jun 2025 09:04:58 +0000 Received: by outflank-mailman (input) for mailman id 1002944; Mon, 02 Jun 2025 09:04: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 1uM16G-00081k-OJ for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 09:04:56 +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 a73e7c91-3f90-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 11:04:56 +0200 (CEST) Received: by mail-lf1-x129.google.com with SMTP id 2adb3069b0e04-55324e35f49so4990016e87.3 for ; Mon, 02 Jun 2025 02:04:56 -0700 (PDT) Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5533791cdc3sm1507541e87.176.2025.06.02.02.04.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 02:04:54 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a73e7c91-3f90-11f0-a300-13f23c93f187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748855095; x=1749459895; darn=lists.xenproject.org; h=content-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=Jf3vC/bMLxsK+qQIEq63MqPOkecni+X3pTICciqQJuw=; b=JsMjDz/WcVkQycjqVs9dX9i37frKDZThoti3L77TXgIhdUhhOv4iFzfeYhO4mghaSi XPdRFh7kEoExwUV8VC3iKOXE1nL6mKDiCOTGaFQJsQmtq/OzxbMVBAyBIncH5vmPttT+ mQsuok/isvvTJohfqoqkZpvliBg/JNKtuMqnFKxPKGEyXRoVCS6y2MhjfMhL2UrfeeeQ aKafARywnwZMch5KPJ1kiI4YAOfWnB0JmDYNx/WooyFhxQ/ZFpEeX4g9JhqPfjCnvJDe umWujBteDkEGTNMt0e4P8pqroBTQ3E6/KW/L8V5sMHgmRX8egHT1mzAmTjHhsDaBol88 gZ3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748855095; x=1749459895; 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=Jf3vC/bMLxsK+qQIEq63MqPOkecni+X3pTICciqQJuw=; b=pJ25wImjuYFzDH97JQDArTAgV/ae83/oEsZYFaLWJaEsjpEwJoky88lFrM4Xnmgv4B x1h3IOEp8TOonvjkcNIxil/TvKmI4u/uTo1UUaPqanKXbtUl20QsmRs9+1+INSzkoaTE Qtco3qzrCtj3vs7j7IkxCRAiojonUA50OJbWlIPmGF6JpAwer95YDguU1m39PTyuLTVP sZJ7225qFUkXjFyjnj1tF9+1m6p0MHxcATlCcqlRoMEo9psMCNa1jAYG05wQsnfpgBki 7cpZTxXWTmgPrvsCXaSm8PLGZRJRt+WWuf8V+4M9gS2x7M4o2GQz0VV29qFLNwHnt7L0 U4Zw== X-Gm-Message-State: AOJu0YzunoFa8HOLmdwiJrHIFQuBitnJzyYnn55cbim8SaZw24dFswRB 499g7T94BT0bth146cAr3JM3nABaUbQd+ByMNmySipJorKsTAD/8L+qqy4zy0PsO X-Gm-Gg: ASbGncsUbqN2oZ0mQfcSzszc2orshWIrxF1sg+rayu4pbmKT5eIvS6Xqdv8VNyS76UX HGl/bgtbC2NWGqDiEiH5mDsbdEUjf0nn8ZMo+Fcr/JUsbF1kE+GIT+3InL2o3viQik05HI9RFdK T5Fspd/GHQFHlF5QlY0wRYFBKPB0fkzWylu2uS1ads4sifZUaclMBB/k7PAar9WojooWH6kgqr4 TbZ2fCrjFacJJ7LTCBLV9AcoKGCZ6xEdAP8FRkOBsKxmaAFkWAAFOEi5bX+sTQSPo09ia0tZbg4 bZ5sPYJF5ULHUFUIg0FF6JFamAdKveu3+TlcxVEYq2gUrYS50A/aojBh8ie0NT8DILWMeeE90HJ rhKIFyy4fqj3ae/025Y2udGPsVw== X-Google-Smtp-Source: AGHT+IHzhIcJPLhYeyY8gRjIbAaAby/DEUcUcJeunz8LbzATZzYj/HE4uNg6xTTusSuHPyQMGBDzRw== X-Received: by 2002:a05:6512:2313:b0:553:202e:a41b with SMTP id 2adb3069b0e04-5533b8f3e6emr3760415e87.15.1748855095180; Mon, 02 Jun 2025 02:04:55 -0700 (PDT) From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: xakep.amatop@gmail.com, Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v4][PART 2 03/10] xen/arm: Implement GIC suspend/resume functions (gicv2 only) Date: Mon, 2 Jun 2025 12:04:14 +0300 Message-ID: X-Mailer: git-send-email 2.48.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Mirela Simonovic System suspend may lead to a state where GIC would be powered down. Therefore, Xen should save/restore the context of GIC on suspend/resume. Note that the context consists of states of registers which are controlled by the hypervisor. Other GIC registers which are accessible by guests are saved/restored on context switch. Tested on Xilinx Ultrascale+ MPSoC with (and without) powering down the GIC. Signed-off-by: Mirela Simonovic Signed-off-by: Saeed Nowshadi Signed-off-by: Mykyta Poturai Signed-off-by: Mykola Kvach --- Changes in v4: - Add error logging for allocation failures Changes in v3: - Drop asserts and return error codes instead. - Wrap code with CONFIG_SYSTEM_SUSPEND. Changes in v2: - Minor fixes after review. --- xen/arch/arm/gic-v2.c | 154 +++++++++++++++++++++++++++++++++ xen/arch/arm/gic.c | 29 +++++++ xen/arch/arm/include/asm/gic.h | 12 +++ 3 files changed, 195 insertions(+) diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c index b23e72a3d0..dce8f5e924 100644 --- a/xen/arch/arm/gic-v2.c +++ b/xen/arch/arm/gic-v2.c @@ -1098,6 +1098,151 @@ static int gicv2_iomem_deny_access(struct domain *d) return iomem_deny_access(d, mfn, mfn + nr); } +#ifdef CONFIG_SYSTEM_SUSPEND + +/* GICv2 registers to be saved/restored on system suspend/resume */ +struct gicv2_context { + /* GICC context */ + uint32_t gicc_ctlr; + uint32_t gicc_pmr; + uint32_t gicc_bpr; + /* GICD context */ + uint32_t gicd_ctlr; + uint32_t *gicd_isenabler; + uint32_t *gicd_isactiver; + uint32_t *gicd_ipriorityr; + uint32_t *gicd_itargetsr; + uint32_t *gicd_icfgr; +}; + +static struct gicv2_context gicv2_context; + +static int gicv2_suspend(void) +{ + unsigned int i; + + if ( !gicv2_context.gicd_isenabler ) + { + dprintk(XENLOG_WARNING, "%s:%d: GICv2 suspend context not allocated!\n", + __func__, __LINE__); + return -ENOMEM; + } + + /* Save GICC configuration */ + gicv2_context.gicc_ctlr = readl_gicc(GICC_CTLR); + gicv2_context.gicc_pmr = readl_gicc(GICC_PMR); + gicv2_context.gicc_bpr = readl_gicc(GICC_BPR); + + /* Save GICD configuration */ + gicv2_context.gicd_ctlr = readl_gicd(GICD_CTLR); + + for ( i = 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 32); i++ ) + gicv2_context.gicd_isenabler[i] = readl_gicd(GICD_ISENABLER + i * 4); + + for ( i = 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 32); i++ ) + gicv2_context.gicd_isactiver[i] = readl_gicd(GICD_ISACTIVER + i * 4); + + for ( i = 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 4); i++ ) + gicv2_context.gicd_ipriorityr[i] = readl_gicd(GICD_IPRIORITYR + i * 4); + + for ( i = 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 4); i++ ) + gicv2_context.gicd_itargetsr[i] = readl_gicd(GICD_ITARGETSR + i * 4); + + for ( i = 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 16); i++ ) + gicv2_context.gicd_icfgr[i] = readl_gicd(GICD_ICFGR + i * 4); + + return 0; +} + +static void gicv2_resume(void) +{ + unsigned int i; + + if ( !gicv2_context.gicd_isenabler ) + { + dprintk(XENLOG_WARNING, "%s:%d: GICv2 suspend context not allocated!\n", + __func__, __LINE__); + return; + } + + gicv2_cpu_disable(); + /* Disable distributor */ + writel_gicd(0, GICD_CTLR); + + /* Restore GICD configuration */ + for ( i = 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 32); i++ ) { + writel_gicd(0xffffffff, GICD_ICENABLER + i * 4); + writel_gicd(gicv2_context.gicd_isenabler[i], GICD_ISENABLER + i * 4); + } + + for ( i = 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 32); i++ ) { + writel_gicd(0xffffffff, GICD_ICACTIVER + i * 4); + writel_gicd(gicv2_context.gicd_isactiver[i], GICD_ISACTIVER + i * 4); + } + + for ( i = 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 4); i++ ) + writel_gicd(gicv2_context.gicd_ipriorityr[i], GICD_IPRIORITYR + i * 4); + + for ( i = 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 4); i++ ) + writel_gicd(gicv2_context.gicd_itargetsr[i], GICD_ITARGETSR + i * 4); + + for ( i = 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 16); i++ ) + writel_gicd(gicv2_context.gicd_icfgr[i], GICD_ICFGR + i * 4); + + /* Make sure all registers are restored and enable distributor */ + writel_gicd(gicv2_context.gicd_ctlr | GICD_CTL_ENABLE, GICD_CTLR); + + /* Restore GIC CPU interface configuration */ + writel_gicc(gicv2_context.gicc_pmr, GICC_PMR); + writel_gicc(gicv2_context.gicc_bpr, GICC_BPR); + + /* Enable GIC CPU interface */ + writel_gicc(gicv2_context.gicc_ctlr | GICC_CTL_ENABLE | GICC_CTL_EOI, + GICC_CTLR); +} + +static void gicv2_alloc_context(struct gicv2_context *gc) +{ + uint32_t n = gicv2_info.nr_lines; + + gc->gicd_isenabler = xzalloc_array(uint32_t, DIV_ROUND_UP(n, 32)); + if ( !gc->gicd_isenabler ) + goto err_free; + + gc->gicd_isactiver = xzalloc_array(uint32_t, DIV_ROUND_UP(n, 32)); + if ( !gc->gicd_isactiver ) + goto err_free; + + gc->gicd_itargetsr = xzalloc_array(uint32_t, DIV_ROUND_UP(n, 4)); + if ( !gc->gicd_itargetsr ) + goto err_free; + + gc->gicd_ipriorityr = xzalloc_array(uint32_t, DIV_ROUND_UP(n, 4)); + if ( !gc->gicd_ipriorityr ) + goto err_free; + + gc->gicd_icfgr = xzalloc_array(uint32_t, DIV_ROUND_UP(n, 16)); + if ( !gc->gicd_icfgr ) + goto err_free; + + return; + + err_free: + dprintk(XENLOG_ERR, + "%s:%d: failed to allocate memory for GICv2 suspend context\n", + __func__, __LINE__); + + xfree(gc->gicd_icfgr); + xfree(gc->gicd_ipriorityr); + xfree(gc->gicd_itargetsr); + xfree(gc->gicd_isactiver); + xfree(gc->gicd_isenabler); + + memset(gc, 0, sizeof(*gc)); +} + +#endif /* CONFIG_SYSTEM_SUSPEND */ + #ifdef CONFIG_ACPI static unsigned long gicv2_get_hwdom_extra_madt_size(const struct domain *d) { @@ -1302,6 +1447,11 @@ static int __init gicv2_init(void) spin_unlock(&gicv2.lock); +#ifdef CONFIG_SYSTEM_SUSPEND + /* Allocate memory to be used for saving GIC context during the suspend */ + gicv2_alloc_context(&gicv2_context); +#endif /* CONFIG_SYSTEM_SUSPEND */ + return 0; } @@ -1345,6 +1495,10 @@ static const struct gic_hw_operations gicv2_ops = { .map_hwdom_extra_mappings = gicv2_map_hwdom_extra_mappings, .iomem_deny_access = gicv2_iomem_deny_access, .do_LPI = gicv2_do_LPI, +#ifdef CONFIG_SYSTEM_SUSPEND + .suspend = gicv2_suspend, + .resume = gicv2_resume, +#endif /* CONFIG_SYSTEM_SUSPEND */ }; /* Set up the GIC */ diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c index e80fe0ca24..a018bd7715 100644 --- a/xen/arch/arm/gic.c +++ b/xen/arch/arm/gic.c @@ -425,6 +425,35 @@ int gic_iomem_deny_access(struct domain *d) return gic_hw_ops->iomem_deny_access(d); } +#ifdef CONFIG_SYSTEM_SUSPEND + +int gic_suspend(void) +{ + /* Must be called by boot CPU#0 with interrupts disabled */ + ASSERT(!local_irq_is_enabled()); + ASSERT(!smp_processor_id()); + + if ( !gic_hw_ops->suspend || !gic_hw_ops->resume ) + return -ENOSYS; + + return gic_hw_ops->suspend(); +} + +void gic_resume(void) +{ + /* + * Must be called by boot CPU#0 with interrupts disabled after gic_suspend + * has returned successfully. + */ + ASSERT(!local_irq_is_enabled()); + ASSERT(!smp_processor_id()); + ASSERT(gic_hw_ops->resume); + + gic_hw_ops->resume(); +} + +#endif /* CONFIG_SYSTEM_SUSPEND */ + static int cpu_gic_callback(struct notifier_block *nfb, unsigned long action, void *hcpu) diff --git a/xen/arch/arm/include/asm/gic.h b/xen/arch/arm/include/asm/gic.h index 541f0eeb80..a706303008 100644 --- a/xen/arch/arm/include/asm/gic.h +++ b/xen/arch/arm/include/asm/gic.h @@ -280,6 +280,12 @@ extern int gicv_setup(struct domain *d); extern void gic_save_state(struct vcpu *v); extern void gic_restore_state(struct vcpu *v); +#ifdef CONFIG_SYSTEM_SUSPEND +/* Suspend/resume */ +extern int gic_suspend(void); +extern void gic_resume(void); +#endif /* CONFIG_SYSTEM_SUSPEND */ + /* SGI (AKA IPIs) */ enum gic_sgi { GIC_SGI_EVENT_CHECK, @@ -395,6 +401,12 @@ struct gic_hw_operations { int (*iomem_deny_access)(struct domain *d); /* Handle LPIs, which require special handling */ void (*do_LPI)(unsigned int lpi); +#ifdef CONFIG_SYSTEM_SUSPEND + /* Save GIC configuration due to the system suspend */ + int (*suspend)(void); + /* Restore GIC configuration due to the system resume */ + void (*resume)(void); +#endif /* CONFIG_SYSTEM_SUSPEND */ }; extern const struct gic_hw_operations *gic_hw_ops; -- 2.48.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 02 09:05:02 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 09:05:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1002947.1382417 (Exim 4.92) (envelope-from ) id 1uM16M-0000yj-4j; Mon, 02 Jun 2025 09:05:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1002947.1382417; Mon, 02 Jun 2025 09:05: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 1uM16L-0000xn-Vx; Mon, 02 Jun 2025 09:05:01 +0000 Received: by outflank-mailman (input) for mailman id 1002947; Mon, 02 Jun 2025 09:05: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 1uM16L-0007kh-6a for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 09:05:01 +0000 Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [2a00:1450:4864:20::135]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a94a2ed8-3f90-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 11:04:59 +0200 (CEST) Received: by mail-lf1-x135.google.com with SMTP id 2adb3069b0e04-55220699ba8so5134319e87.2 for ; Mon, 02 Jun 2025 02:04:59 -0700 (PDT) Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5533791cdc3sm1507541e87.176.2025.06.02.02.04.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 02:04:58 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a94a2ed8-3f90-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748855099; x=1749459899; darn=lists.xenproject.org; h=content-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=gLtZvLmNS5IQ5nQywV+KESH/yusLqzvm5c+C1sq8VQE=; b=ZI6qqWrhzS7h7+3frDr+CYM7CAaAxcp4CfwrFfUakAtDva5BHNjlh50FLoTRLHQzMG wkyTjMl6cGeMxW1njm/PKcDpProuJEa1FcVX4CKQm77WOOQ0zOiKovwzV/Bn3NfSWYuM 6VGwUp54NsmO5F00OPe70O6jaN5A5dc3Kui6DKfPhfEHaUe+/8ZEEJDRXcdfAq69GTDs am2NkT2GHzQ20nKI/Po+4nwKkjct1dsflb6o1WYG4b5haWuNxkGC2gvArCYTIRYQ11Ny ncVhpUFEOabhO5kabtZHggfPR7+CVK/nCk7pI5eIrWe/X73gz8+9Qc0Wnm4DGF2Jb3C4 eI/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748855099; x=1749459899; 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=gLtZvLmNS5IQ5nQywV+KESH/yusLqzvm5c+C1sq8VQE=; b=r8RfCvmE/GB7aO1FXW4s5ErzP5KW47yHxb2kofW8Gy3IHwSv5adWvZRhpXsYT9mRcn 2uPEeyQhki/gb52g8UMTOtY0fq17TGEmI1iN62C0TTc0hEyEs2ZlSELBwQlir8FwPAv2 WservR/cXepMdCYw/6shY6Z3+X+r8mGUY3yyg/XievJAoJAfWRDWEOZv0QfrQ4B2sbzE RrdMxjIcKbLiZ7ysRK6WCIQ3PNUewSio4XFpLL68wr6XCQ2Akm+mg8oBBoPo0t9oKvf3 dcG1+AFDtiNAXBPiYPshbg0Fa2vmbihCccW40RI8i3SfoOtAYR6fqmjrb1EjmDLLAcSV 629Q== X-Gm-Message-State: AOJu0YwUx+DzBVvTQ6SPf1iAMQ9CrKprQZFgbxXut4IYnIxkIeP4q/9i zhuzoY3fzxvn0SS+oKtTW1uYwCzpiHier03NooYrWjj0fhYMMxE6Zye9IZg0ReRw X-Gm-Gg: ASbGnctnsjJp8ZuBCj3jQ7PgBsT2U6izBiVKLl1BfpXomkDGTHYo8LaYDfKtqAwm3vW JY/68jokWsaB2vyiLVVRy0gJEvOAaTHrGk3J3IGyki85N+ftLn5XLrPtnTUF+90jYUotMi5ZWjE /jTCe03JwsriFe+f+dIm3A2b+7pFRWh9Knnue1SP3Uovj7Io9UXwRWCrNrLT+o2Tdz7z3/tsOdX YP9aSJX0PW4z1FE8KppwxX/EO5bXBvipEL6HvSfDsi23XTUaFNsu2tJSAG0NzkVz48iAjrIZhZI uRKjFgffRuqInV7K7FqUJYccdK0829eR2w04PQMI580qyS5nG5rW/6WZOJw/V2I9+DPODgjFFjZ sEJThol4GB/s98KPz4HFK+NvBIw== X-Google-Smtp-Source: AGHT+IEvX585OOmt7ZiEiMyg7i6PA8bef54WnayP0mdDtUFr/dnbjwdOuWJmj0LjXKmXClWMsr03gg== X-Received: by 2002:a05:6512:3d13:b0:550:e5c4:b0a1 with SMTP id 2adb3069b0e04-5533d13e73dmr2804533e87.11.1748855098750; Mon, 02 Jun 2025 02:04:58 -0700 (PDT) From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: xakep.amatop@gmail.com, Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v4][PART 2 06/10] xen/arm: irq: Restore state of local IRQs during system resume Date: Mon, 2 Jun 2025 12:04:17 +0300 Message-ID: <8cbea1b2335ba0f2ea189c653c62bd591882b295.1748848482.git.mykola_kvach@epam.com> X-Mailer: git-send-email 2.48.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Mykola Kvach On ARM, the first 32 interrupts (SGIs and PPIs) are banked per-CPU and not restored by gic_resume (for secondary cpus). This patch introduces restore_local_irqs_on_resume, a function that restores the state of local interrupts on the target CPU during system resume. It iterates over all local IRQs and re-enables those that were not disabled, reprogramming their routing and affinity accordingly. The function is invoked from start_secondary, ensuring that local IRQ state is restored early during CPU bring-up after suspend. Signed-off-by: Mykola Kvach --- xen/arch/arm/irq.c | 44 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c index 372716a73b..f32f8b56ca 100644 --- a/xen/arch/arm/irq.c +++ b/xen/arch/arm/irq.c @@ -113,6 +113,47 @@ static int init_local_irq_data(unsigned int cpu) return 0; } +/* + * The first 32 interrupts (PPIs and SGIs) are per-CPU, + * so call this function on the target CPU to restore them. + * + * SPIs are restored via gic_resume. + */ +static void restore_local_irqs_on_resume(void) +{ + int irq; + + if ( system_state != SYS_STATE_resume ) + return; + + spin_lock(&local_irqs_type_lock); + + for ( irq = 0; irq < NR_LOCAL_IRQS; irq++ ) + { + struct irq_desc *desc = irq_to_desc(irq); + + spin_lock(&desc->lock); + + if ( test_bit(_IRQ_DISABLED, &desc->status) ) + { + spin_unlock(&desc->lock); + continue; + } + + /* it is needed to avoid asserts in below calls */ + set_bit(_IRQ_DISABLED, &desc->status); + + gic_route_irq_to_xen(desc, GIC_PRI_IRQ); + + /* _IRQ_DISABLED is cleared by below call */ + desc->handler->startup(desc); + + spin_unlock(&desc->lock); + } + + spin_unlock(&local_irqs_type_lock); +} + static int cpu_callback(struct notifier_block *nfb, unsigned long action, void *hcpu) { @@ -131,6 +172,9 @@ static int cpu_callback(struct notifier_block *nfb, unsigned long action, printk(XENLOG_ERR "Unable to allocate local IRQ for CPU%u\n", cpu); break; + case CPU_STARTING: + restore_local_irqs_on_resume(); + break; } return notifier_from_errno(rc); -- 2.48.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 02 09:05:05 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 09:05:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1002948.1382428 (Exim 4.92) (envelope-from ) id 1uM16P-0001Q8-Gd; Mon, 02 Jun 2025 09:05:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1002948.1382428; Mon, 02 Jun 2025 09:05:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uM16P-0001Pu-BS; Mon, 02 Jun 2025 09:05:05 +0000 Received: by outflank-mailman (input) for mailman id 1002948; Mon, 02 Jun 2025 09:05: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 1uM16N-0007kh-BE for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 09:05: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 aa775ed5-3f90-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 11:05:01 +0200 (CEST) Received: by mail-lf1-x12c.google.com with SMTP id 2adb3069b0e04-553280c345cso5290525e87.0 for ; Mon, 02 Jun 2025 02:05:01 -0700 (PDT) Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5533791cdc3sm1507541e87.176.2025.06.02.02.04.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 02:04:59 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: aa775ed5-3f90-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748855101; x=1749459901; darn=lists.xenproject.org; h=content-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=NXZs6M8P80Im90jJSBLKCDHJny8JfIVqdVI3nVOxBmE=; b=kUKBdBHmu47ZOW8rZpCaqSNoS2j1Ly1SKnz5MyfJBUgaE+F9ZxGtfjfEoF7nIgcljN Dx+iu2Kk6SRD+WY+uVbdm9cDN6ZwfNSL6Cc4GcmbGcpZDHrvmr2Ffl17fOrUpu1UEQL0 eKiPEN3IlFrnxy5ZtOisjvW/op4oM7T1hPMfr1PMN4Q3V8fawXc7UOBx/VzDWol6MlFH DlC+mwSQOqGdeXwNwpIPAsiBJRV9I9dykcyzCY7vmBp7+CoqEP3WfRzbqDmwr/egXxzn pr8cgup0VWKC3VRWL8Z/Kfu5IhCsImRwEZby0qUU1p4hYtLwB0JLbA3ebMtKhc9d452K mYDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748855101; x=1749459901; 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=NXZs6M8P80Im90jJSBLKCDHJny8JfIVqdVI3nVOxBmE=; b=ANEP71lLSlm8PaObWIVoqytAf9EU0Je2aewD6PixAPQSpiEDysM94S8Ka+o+6nZxCp Y4sW28icVwf82R71h0578bL7B26+5WlMAMBStpc9aurLxAS1eW+SWIbN22EKUpECL1wN +5PA2+dB7DA394OwsqS+rC6wQbsLPJXySu9ebG+PQHZWT7ZFL5XKNfdGkbDY7p7YVwkr b2Mu8FyXslf2vbeIbidcJQPsiZxfEM3USL9f2jEVatXItS9shrtO+0Dm/iIGZbkS8FOA maSavfUYlrxb4RYnJTYIvqR82UUc0IGDGNMxf80dbVV5zV4d9tt49uDYdbFloVX3a8fv ByTQ== X-Gm-Message-State: AOJu0YwvfMErhR1vUTjs1Ei/OoiFv33bSuLQzsnMvJWGI9fj+dDTcogT idn3uHJik4vMeFL4Bkftnvw+cRcS0U1Sl6f21ipQwMCRb3lFfgZZBG6TovHmJagAK9o= X-Gm-Gg: ASbGncsER2rWTvBEY+isQnsuWJ5Yk60pQMkPEmt7WmGKagIZNgR5HIfR3bWoa2fbz7R 2+afRq5K7FadrWfsTA4UAK/tj+WSCbAgxisyyyUUK9BpDYAcxCizEzrYgFN6Y38v7CMsY9d9LyB 8q+iYzcustv/YTIyRO0LRYI8mKNsztPikbS+ixo02SooMJbVwYey2X2onUHF1/tbWCWOL/2y3OZ O/3kmYmN88ukfiPrRfdE1DV6wjb3m7E+FAfoWy6f+8pKVONqYCe6Db/Gi87ehF42kpEQMeZC8ZS QFquvUMItrfxmYXUL1FGQXyaL0wLhuPsSvoYvhx/qFgQl9bBGZNdWVcYRQSPAru9hVJErFZs99s hQJ7Rh2m3XFTzPm9JGpsfhXd9fA== X-Google-Smtp-Source: AGHT+IEuTNPnBUZrCCHATRKgs5I7i+11AlP+JJAf9fOMKvbdRpaN5dntYb1dXqpKLf04epIJMtzGHw== X-Received: by 2002:a05:6512:3352:b0:553:50c6:b86c with SMTP id 2adb3069b0e04-55350c6b915mr46633e87.57.1748855100526; Mon, 02 Jun 2025 02:05:00 -0700 (PDT) From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: xakep.amatop@gmail.com, Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Shawn Anastasio , Alistair Francis , Bob Eshleman , Connor Davis , Oleksii Kurochko Subject: [PATCH v4][PART 2 07/10] xen/arm: Add support for system suspend triggered by hardware domain Date: Mon, 2 Jun 2025 12:04:18 +0300 Message-ID: <7bd75ecfff5b0a75ea5abd7cc4934582d7e1250c.1748848482.git.mykola_kvach@epam.com> X-Mailer: git-send-email 2.48.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Mirela Simonovic Trigger Xen suspend when the hardware domain initiates suspend via SHUTDOWN_suspend. Redirect system suspend to CPU#0 to ensure the suspend logic runs on the boot CPU, as required. Introduce full suspend/resume infrastructure gated by CONFIG_SYSTEM_SUSPEND, including logic to: - disable and enable non-boot physical CPUs - freeze and thaw domains - suspend and resume the GIC, timer and console - maintain system state before and after suspend Extend arch_domain_shutdown to return a status code and integrate system_suspend into the ARM-specific path. Update stub implementations and function signatures across other architectures (x86, riscv, ppc) for consistency. Remove the restriction in the PSCI interface preventing suspend from the hardware domain. Update Kconfig and Makefile to support conditional inclusion of the new suspend.c implementation.Limit SYSTEM_SUSPEND support to ARM64 with UNSUPPORTED enabled and LLC_COLORING disabled. Signed-off-by: Mirela Simonovic Signed-off-by: Saeed Nowshadi Signed-off-by: Mykyta Poturai Signed-off-by: Mykola Kvach --- Changes introduced in V4: - drop code for saving and restoring VCPU context (for more information refer part 1 of patch series) - remove IOMMU suspend and resume calls until they will be implemented - move system suspend logic to arch_domain_shutdown, invoked from domain_shutdown - apply minor fixes such as renaming functions, updating comments, and modifying the commit message to reflect these changes - add console_end_sync to resume path after system suspend Changes introduced in V3: - merge changes from other commits into this patch (previously stashed): 1) disable/enable non-boot physical CPUs and freeze/thaw domains during suspend/resume 2) suspend/resume the timer, GIC, console, IOMMU, and hardware domain --- xen/arch/arm/Kconfig | 1 + xen/arch/arm/Makefile | 1 + xen/arch/arm/domain.c | 21 ++++- xen/arch/arm/include/asm/suspend.h | 22 +++++ xen/arch/arm/suspend.c | 143 +++++++++++++++++++++++++++++ xen/arch/arm/vpsci.c | 4 - xen/arch/ppc/stubs.c | 2 +- xen/arch/riscv/stubs.c | 2 +- xen/arch/x86/domain.c | 4 +- xen/common/domain.c | 9 +- xen/include/xen/domain.h | 2 +- 11 files changed, 200 insertions(+), 11 deletions(-) create mode 100644 xen/arch/arm/include/asm/suspend.h create mode 100644 xen/arch/arm/suspend.c diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index 57919d8b3a..80d0a6bf54 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -19,6 +19,7 @@ config ARM select HAS_DOM0LESS select HAS_GRANT_CACHE_FLUSH if GRANT_TABLE select HAS_STACK_PROTECTOR + select HAS_SYSTEM_SUSPEND if ARM_64 && !LLC_COLORING && UNSUPPORTED select HAS_UBSAN config ARCH_DEFCONFIG diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile index eeeac4e653..381969dd90 100644 --- a/xen/arch/arm/Makefile +++ b/xen/arch/arm/Makefile @@ -53,6 +53,7 @@ obj-y += smp.o obj-y += smpboot.o obj-$(CONFIG_STATIC_MEMORY) += static-memory.init.o obj-$(CONFIG_STATIC_SHM) += static-shmem.init.o +obj-$(CONFIG_SYSTEM_SUSPEND) += suspend.o obj-y += sysctl.o obj-y += time.o obj-y += traps.o diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c index 45aeb8bddc..75092a997f 100644 --- a/xen/arch/arm/domain.c +++ b/xen/arch/arm/domain.c @@ -24,11 +24,14 @@ #include #include #include +#include #include #include #include #include +#include + #include "vpci.h" #include "vuart.h" @@ -857,8 +860,24 @@ void arch_domain_destroy(struct domain *d) domain_io_free(d); } -void arch_domain_shutdown(struct domain *d) +int arch_domain_shutdown(struct domain *d) { + switch ( d->shutdown_code ) + { + case SHUTDOWN_suspend: +#ifdef CONFIG_SYSTEM_SUSPEND + if ( !is_hardware_domain(d) ) + break; + + return host_system_suspend(); +#else + break; +#endif + default: + break; + } + + return 0; } void arch_domain_pause(struct domain *d) diff --git a/xen/arch/arm/include/asm/suspend.h b/xen/arch/arm/include/asm/suspend.h new file mode 100644 index 0000000000..78d0e2383b --- /dev/null +++ b/xen/arch/arm/include/asm/suspend.h @@ -0,0 +1,22 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#ifndef __ASM_ARM_SUSPEND_H__ +#define __ASM_ARM_SUSPEND_H__ + +#ifdef CONFIG_SYSTEM_SUSPEND + +int host_system_suspend(void); + +#endif /* CONFIG_SYSTEM_SUSPEND */ + +#endif /* __ASM_ARM_SUSPEND_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/arch/arm/suspend.c b/xen/arch/arm/suspend.c new file mode 100644 index 0000000000..13e59015c0 --- /dev/null +++ b/xen/arch/arm/suspend.c @@ -0,0 +1,143 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#include +#include +#include + +/* + * TODO list: + * - Test system suspend with LLC_COLORING enabled and verify functionality + * - Implement IOMMU suspend/resume handlers and integrate them + * into the suspend/resume path + * - Add GICv3 suspend/resume support if required + * - Enable "xl suspend" support on ARM architecture + * - Properly disable Xen timer watchdog from relevant services + * - Add suspend/resume CI test for ARM (QEMU if feasible) + * - Investigate feasibility and need for implementing system suspend on ARM32 + */ + +/* Xen suspend. Note: data is not used (suspend is the suspend to RAM) */ +static long system_suspend(void *data) +{ + int status; + unsigned long flags; + + BUG_ON(system_state != SYS_STATE_active); + + system_state = SYS_STATE_suspend; + freeze_domains(); + scheduler_disable(); + + /* + * Non-boot CPUs have to be disabled on suspend and enabled on resume + * (hotplug-based mechanism). Disabling non-boot CPUs will lead to PSCI + * CPU_OFF to be called by each non-boot CPU. Depending on the underlying + * platform capabilities, this may lead to the physical powering down of + * CPUs. Tested on Xilinx Zynq Ultrascale+ MPSoC (including power down of + * each non-boot CPU). + */ + status = disable_nonboot_cpus(); + if ( status ) + { + system_state = SYS_STATE_resume; + goto resume_nonboot_cpus; + } + + time_suspend(); + + local_irq_save(flags); + status = gic_suspend(); + if ( status ) + { + system_state = SYS_STATE_resume; + goto resume_irqs; + } + + printk("Xen suspending...\n"); + + console_start_sync(); + status = console_suspend(); + if ( status ) + { + dprintk(XENLOG_ERR, "Failed to suspend the console, err=%d\n", status); + system_state = SYS_STATE_resume; + goto resume_console; + } + + /* + * Enable identity mapping before entering suspend to simplify + * the resume path + */ + update_boot_mapping(true); + + system_state = SYS_STATE_resume; + update_boot_mapping(false); + + resume_console: + console_resume(); + console_end_sync(); + + gic_resume(); + + resume_irqs: + local_irq_restore(flags); + time_resume(); + + resume_nonboot_cpus: + /* + * The rcu_barrier() has to be added to ensure that the per cpu area is + * freed before a non-boot CPU tries to initialize it (_free_percpu_area() + * has to be called before the init_percpu_area()). This scenario occurs + * when non-boot CPUs are hot-unplugged on suspend and hotplugged on resume. + */ + rcu_barrier(); + enable_nonboot_cpus(); + scheduler_enable(); + thaw_domains(); + + system_state = SYS_STATE_active; + + /* The resume of hardware domain should always follow Xen's resume. */ + domain_resume(hardware_domain); + + printk("Resume (status %d)\n", status); + return status; +} + +int host_system_suspend(void) +{ + int status; + + /* + * system_suspend should be called when Dom0 finalizes the suspend + * procedure from its boot core (VCPU#0). However, Dom0's VCPU#0 could + * be mapped to any PCPU (this function could be executed by any PCPU). + * The suspend procedure has to be finalized by the PCPU#0 (non-boot + * PCPUs will be disabled during the suspend). + */ + status = continue_hypercall_on_cpu(0, system_suspend, NULL); + + /* + * If an error happened, there is nothing that needs to be done here + * because the system_suspend always returns in fully functional state + * no matter what the outcome of suspend procedure is. If the system + * suspended successfully the function will return 0 after the resume. + * Otherwise, if an error is returned it means Xen did not suspended, + * but it is still in the same state as if the system_suspend was never + * called. We dump a debug message in case of an error for debugging/ + * logging purpose. + */ + if ( status ) + dprintk(XENLOG_ERR, "Failed to suspend, errno=%d\n", status); + + return status; +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c index 87a63b0a94..27e413b1fb 100644 --- a/xen/arch/arm/vpsci.c +++ b/xen/arch/arm/vpsci.c @@ -202,10 +202,6 @@ static int32_t do_psci_1_0_system_suspend(register_t epoint, register_t cid) struct vcpu *v; struct domain *d = current->domain; - /* Drop this check once SYSTEM_SUSPEND is supported in hardware domain */ - if ( is_hardware_domain(d) ) - return PSCI_NOT_SUPPORTED; - /* Ensure that all CPUs other than the calling one are offline */ for_each_vcpu ( d, v ) { diff --git a/xen/arch/ppc/stubs.c b/xen/arch/ppc/stubs.c index 671e71aa0a..5bb08dcd95 100644 --- a/xen/arch/ppc/stubs.c +++ b/xen/arch/ppc/stubs.c @@ -219,7 +219,7 @@ void arch_domain_destroy(struct domain *d) BUG_ON("unimplemented"); } -void arch_domain_shutdown(struct domain *d) +int arch_domain_shutdown(struct domain *d) { BUG_ON("unimplemented"); } diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c index 83416d3350..e2cb6c2579 100644 --- a/xen/arch/riscv/stubs.c +++ b/xen/arch/riscv/stubs.c @@ -204,7 +204,7 @@ void arch_domain_destroy(struct domain *d) BUG_ON("unimplemented"); } -void arch_domain_shutdown(struct domain *d) +int arch_domain_shutdown(struct domain *d) { BUG_ON("unimplemented"); } diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index 7536b6c871..ab4b54fc3c 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -951,10 +951,12 @@ void arch_domain_destroy(struct domain *d) psr_domain_free(d); } -void arch_domain_shutdown(struct domain *d) +int arch_domain_shutdown(struct domain *d) { if ( is_viridian_domain(d) ) viridian_time_domain_freeze(d); + + return 0; } void arch_domain_pause(struct domain *d) diff --git a/xen/common/domain.c b/xen/common/domain.c index 58c5ffc466..6a3140561e 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -1276,6 +1276,7 @@ void __domain_crash(struct domain *d) int domain_shutdown(struct domain *d, u8 reason) { struct vcpu *v; + int ret; #ifdef CONFIG_X86 if ( pv_shim ) @@ -1288,7 +1289,11 @@ int domain_shutdown(struct domain *d, u8 reason) d->shutdown_code = reason; reason = d->shutdown_code; +#if defined(CONFIG_SYSTEM_SUSPEND) && defined(CONFIG_ARM) + if ( reason != SHUTDOWN_suspend && is_hardware_domain(d) ) +#else if ( is_hardware_domain(d) ) +#endif hwdom_shutdown(reason); if ( d->is_shutting_down ) @@ -1311,13 +1316,13 @@ int domain_shutdown(struct domain *d, u8 reason) v->paused_for_shutdown = 1; } - arch_domain_shutdown(d); + ret = arch_domain_shutdown(d); __domain_finalise_shutdown(d); spin_unlock(&d->shutdown_lock); - return 0; + return ret; } void domain_resume(struct domain *d) diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h index e10baf2615..c0cbbd808f 100644 --- a/xen/include/xen/domain.h +++ b/xen/include/xen/domain.h @@ -101,7 +101,7 @@ int arch_domain_create(struct domain *d, int arch_domain_teardown(struct domain *d); void arch_domain_destroy(struct domain *d); -void arch_domain_shutdown(struct domain *d); +int arch_domain_shutdown(struct domain *d); void arch_domain_pause(struct domain *d); void arch_domain_unpause(struct domain *d); -- 2.48.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 02 09:05:06 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 09:05:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1002950.1382434 (Exim 4.92) (envelope-from ) id 1uM16Q-0001XK-3V; Mon, 02 Jun 2025 09:05:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1002950.1382434; Mon, 02 Jun 2025 09:05:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uM16P-0001WP-VB; Mon, 02 Jun 2025 09:05:05 +0000 Received: by outflank-mailman (input) for mailman id 1002950; Mon, 02 Jun 2025 09: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 1uM16O-0007kh-GL for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 09:05:04 +0000 Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [2a00:1450:4864:20::136]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ab32a00e-3f90-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 11:05:02 +0200 (CEST) Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-55320ddb9edso4626327e87.1 for ; Mon, 02 Jun 2025 02:05:02 -0700 (PDT) Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5533791cdc3sm1507541e87.176.2025.06.02.02.05.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 02:05:01 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ab32a00e-3f90-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748855102; x=1749459902; darn=lists.xenproject.org; h=content-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=xVrfy+vq7RG5yhPUKzBrjh3pK5+yQTsG+Zt3de4iBS0=; b=YPAX9AgwzlBcLOXw9GYbEM9R9RjEDqkbAGnvs2wEJsBONx8PgDU3ViCPGR8HbkOa2U 3y2FndoZZ1sGJFzVnjSZStGamjjqz27jdjU9KIdPhWHdLRsllnRk0+GPjH3B/JGSDhWR HdIwT4MBiYYQ4/Sz0o4jKZ/fNCxK/+W1dz/p8p8WhI1z5hsKNDo5mwQDRPbjLGu8QMoz tr48Lv+/nqBiEM8MZnmSeYcPYH8qXuk6BUvQCXWM2J0AbRuaYGoTEEOoNR1iqjH8JNGC m4jYqBwObqZskDiLxdpWrMHTF3GxY419s+HMe00H/ab+n7Ut/tL7UQDy7sugt2x+czaS whbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748855102; x=1749459902; 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=xVrfy+vq7RG5yhPUKzBrjh3pK5+yQTsG+Zt3de4iBS0=; b=w3VycqwDzvAvf+iUF0x2yZ6/aqvjen8/5bYpeZyAz3s3eD1CXKvp/YLlXdcc1loAVw qmcUImH67JEZmvpUpeG+SzH8Pt+CZAc/LTxqCl64tCKKnKKRPPs7ehnaMMssnOmdjY42 eCaKIiM34IP3khWjlwUU7NudxD4Vj4xrohpsRr+vBN1Hgte6iAAkneJxWQo55HOqKADG Z0+R00v0ng/mGePlH7DQINB2ZjXKzkVV+FQI13IPzf6IePsWIy3OnwBGR6IQ5NoTWDgl Q1lzJgee25gkNS6XJIv8YANr8aeYhda4Wwe6aKoS/05H4mzgPgXzgx6HvcjszJ29l3lR vjZg== X-Gm-Message-State: AOJu0YxAmmo1mwrk/2D1zt+us3yBiuFzCq5L35kX/NPonMmv8nKAsxqg Qn1jcAJ+mG2qDWAe5fmWqmfEofIKwhc+A5p5BabC0wszyo1hMXBRYy6CNDuUKVgK X-Gm-Gg: ASbGncu1cAs7iHtMGfcCKag1hxdsnwuvvEulGDoqRdrlQTHJug8iV6dnSwo1XowWEuM OKz4i11eLTmTCA9JlaTFouXhSFUIEL2S1gBz7lphWVzu0/BafGXoxcrJ3GuycpeV5YeP3SoeLE3 hyTeV28JYhXRt4deXu1IEyHzcHNSanyUFQy/qxfjYD9pBQ7HI9Tvn53A+kSca3jPhvqrBjIY6nk jVjfD7KgGyt+KEYSeNQpNZ0vJk4ryZYnrppWfmoiqtdzBVr0aiLvMftNSjOTGuLQKThN5/taWVv eLa7s3NaqgpvAGWYL7AyL1KNkU64viXOSJMecWE/41xgIhAGlzWg6HBxfFtFG3zN97fPYfp7ckt fQvDK43vpz7u4Ntg= X-Google-Smtp-Source: AGHT+IEzvXRcRJQ8PQGVzDpd6OcQsKQvl49VrWAqrNtL/IwwXOCr/Woxdx0f+/LYoggsghv0r2tfcg== X-Received: by 2002:a05:6512:1284:b0:553:2f49:ff2a with SMTP id 2adb3069b0e04-5533b92e3c3mr3620581e87.38.1748855101772; Mon, 02 Jun 2025 02:05:01 -0700 (PDT) From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: xakep.amatop@gmail.com, Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v4][PART 2 08/10] xen/arm: Implement PSCI SYSTEM_SUSPEND call (host interface) Date: Mon, 2 Jun 2025 12:04:19 +0300 Message-ID: <482f5988adbfe209ef01ebffd48f37e2b210556e.1748848482.git.mykola_kvach@epam.com> X-Mailer: git-send-email 2.48.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Mirela Simonovic Invoke PSCI SYSTEM_SUSPEND to finalize Xen's suspend sequence on ARM64 platforms. Pass the resume entry point (hyp_resume) as the first argument to EL3. The resume handler is currently a stub and will be implemented later in assembly. Ignore the context ID argument, as is done in Linux. Only enable this path when CONFIG_SYSTEM_SUSPEND is set and PSCI version is >= 1.0. Signed-off-by: Mirela Simonovic Signed-off-by: Saeed Nowshadi Signed-off-by: Mykyta Poturai Signed-off-by: Mykola Kvach --- Changes in v4: - select the appropriate PSCI SYSTEM_SUSPEND function ID based on arch - update comments and commit message to reflect recent changes Changes in v3: - return PSCI_NOT_SUPPORTED instead of a hardcoded 1 on ARM32 - check PSCI version before invoking SYSTEM_SUSPEND in call_psci_system_suspend --- xen/arch/arm/arm64/head.S | 8 ++++++++ xen/arch/arm/include/asm/psci.h | 1 + xen/arch/arm/include/asm/suspend.h | 2 ++ xen/arch/arm/psci.c | 23 ++++++++++++++++++++++- xen/arch/arm/suspend.c | 5 +++++ 5 files changed, 38 insertions(+), 1 deletion(-) diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S index 72c7b24498..3522c497c5 100644 --- a/xen/arch/arm/arm64/head.S +++ b/xen/arch/arm/arm64/head.S @@ -561,6 +561,14 @@ END(efi_xen_start) #endif /* CONFIG_ARM_EFI */ +#ifdef CONFIG_SYSTEM_SUSPEND + +FUNC(hyp_resume) + b . +END(hyp_resume) + +#endif /* CONFIG_SYSTEM_SUSPEND */ + /* * Local variables: * mode: ASM diff --git a/xen/arch/arm/include/asm/psci.h b/xen/arch/arm/include/asm/psci.h index 48a93e6b79..bb3c73496e 100644 --- a/xen/arch/arm/include/asm/psci.h +++ b/xen/arch/arm/include/asm/psci.h @@ -23,6 +23,7 @@ int call_psci_cpu_on(int cpu); void call_psci_cpu_off(void); void call_psci_system_off(void); void call_psci_system_reset(void); +int call_psci_system_suspend(void); /* Range of allocated PSCI function numbers */ #define PSCI_FNUM_MIN_VALUE _AC(0,U) diff --git a/xen/arch/arm/include/asm/suspend.h b/xen/arch/arm/include/asm/suspend.h index 78d0e2383b..55041a5d06 100644 --- a/xen/arch/arm/include/asm/suspend.h +++ b/xen/arch/arm/include/asm/suspend.h @@ -7,6 +7,8 @@ int host_system_suspend(void); +void hyp_resume(void); + #endif /* CONFIG_SYSTEM_SUSPEND */ #endif /* __ASM_ARM_SUSPEND_H__ */ diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c index b6860a7760..c9d126b195 100644 --- a/xen/arch/arm/psci.c +++ b/xen/arch/arm/psci.c @@ -17,17 +17,20 @@ #include #include #include +#include /* * While a 64-bit OS can make calls with SMC32 calling conventions, for * some calls it is necessary to use SMC64 to pass or return 64-bit values. - * For such calls PSCI_0_2_FN_NATIVE(x) will choose the appropriate + * For such calls PSCI_*_FN_NATIVE(x) will choose the appropriate * (native-width) function ID. */ #ifdef CONFIG_ARM_64 #define PSCI_0_2_FN_NATIVE(name) PSCI_0_2_FN64_##name +#define PSCI_1_0_FN_NATIVE(name) PSCI_1_0_FN64_##name #else #define PSCI_0_2_FN_NATIVE(name) PSCI_0_2_FN32_##name +#define PSCI_1_0_FN_NATIVE(name) PSCI_1_0_FN32_##name #endif uint32_t psci_ver; @@ -60,6 +63,24 @@ void call_psci_cpu_off(void) } } +int call_psci_system_suspend(void) +{ +#ifdef CONFIG_SYSTEM_SUSPEND + struct arm_smccc_res res; + + if ( psci_ver < PSCI_VERSION(1, 0) ) + return PSCI_NOT_SUPPORTED; + + /* 2nd argument (context ID) is not used */ + arm_smccc_smc(PSCI_1_0_FN_NATIVE(SYSTEM_SUSPEND), __pa(hyp_resume), &res); + return PSCI_RET(res); +#else + dprintk(XENLOG_WARNING, + "SYSTEM_SUSPEND not supported (CONFIG_SYSTEM_SUSPEND disabled)\n"); + return PSCI_NOT_SUPPORTED; +#endif +} + void call_psci_system_off(void) { if ( psci_ver > PSCI_VERSION(0, 1) ) diff --git a/xen/arch/arm/suspend.c b/xen/arch/arm/suspend.c index 13e59015c0..e3a9b68622 100644 --- a/xen/arch/arm/suspend.c +++ b/xen/arch/arm/suspend.c @@ -1,5 +1,6 @@ /* SPDX-License-Identifier: GPL-2.0-only */ +#include #include #include #include @@ -70,6 +71,10 @@ static long system_suspend(void *data) */ update_boot_mapping(true); + status = call_psci_system_suspend(); + if ( status ) + dprintk(XENLOG_WARNING, "PSCI system suspend failed, err=%d\n", status); + system_state = SYS_STATE_resume; update_boot_mapping(false); -- 2.48.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 02 09:05:06 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 09:05:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1002951.1382437 (Exim 4.92) (envelope-from ) id 1uM16Q-0001by-Gq; Mon, 02 Jun 2025 09:05:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1002951.1382437; Mon, 02 Jun 2025 09:05:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uM16Q-0001aw-87; Mon, 02 Jun 2025 09:05:06 +0000 Received: by outflank-mailman (input) for mailman id 1002951; Mon, 02 Jun 2025 09:05: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 1uM16P-00081k-4S for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 09:05:05 +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 abc4a5a5-3f90-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 11:05:03 +0200 (CEST) Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-55350d0eedeso56746e87.2 for ; Mon, 02 Jun 2025 02:05:03 -0700 (PDT) Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5533791cdc3sm1507541e87.176.2025.06.02.02.05.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 02:05:02 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: abc4a5a5-3f90-11f0-a300-13f23c93f187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748855103; x=1749459903; darn=lists.xenproject.org; h=content-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=teuh5RSMor4Ejk4U6N2jEUsE+RWNO2fK7HvyuJpLGDk=; b=SOvwPxt5zh9+aUvv1EWJwG8xBGuXyAU+k218MbkKmTvz6VwOLoQ1ujp5qKnUOAhwr5 VKDP8vI7gtY1DvGOKt2vLUQE9luC8oCP3itSAk94oF2bVYVK6AbKUT3/J7e+tZ2fjoN6 HcHQPVZyGViXW10NY4sVkxxV8uGhQb6Fny+uWd+Cr4P1TG+BYAWjDrZc4pb7f4dAcWMP 5OhdE0IChlHmsA1tB7W0KB5FWOGquADN3ISFRPgyapdd+OcZ1R7X7YYfupygDfe/a8dx H3AQfuSYjACxJsYsxn0Tp/UAlToE2saSE0Agp4Nk+UM3QX2NpL3Bv0H1698mZe8JAA0v V46w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748855103; x=1749459903; 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=teuh5RSMor4Ejk4U6N2jEUsE+RWNO2fK7HvyuJpLGDk=; b=qXex9VcZkLLH6fBJQNSEBdKcpPwg8xjjrR2jg7JzElH8WEd+AT9Yw7rwd/9pMUkUgR VCW1xbL5vo3GrAk77V/DMdTLbFOQbUlEzUkNvHcIRR9BIBKYIRibePRz1PiRzM5QyW74 1Oyg6h55UV8PaTJh9PJIMkd7xs4rZ1E6XVI0h4O+Y+kWY4cElUcokJAiI/NID8qgQBXj OPdGlFZ8vNLTicAlPTtEjAbguWlr+0Uf66LR9JvMdJAsgM8w7HdGBvo1YdmIEVpVS1F2 QfU8g6NUx8bYrXbUN4nwxPS96JYhcYdeQtfoDK5QYR6qIiTYB6xCtdMPzy8YvPDO4D0o 3nPA== X-Gm-Message-State: AOJu0Yx8btZ1eIblxl9MiM2Zxg3UdjQ+almSeRi91jbLUsTcBggbF2OJ 20oc/1tiy8FUNiusHAHOz8dowS4h8BOzknEOxCsSaJIoC6JvnfF8kOtqjSNMymFe X-Gm-Gg: ASbGnct0/P4nv4VBR1sw31Fdq3XANiW802W0j6UX9WRAAmhFys3IS0Sow71AUq3eMlp zZm55lwXeLjqwHsaqB87MJg1ODfEYDMmPbEJnk1HjLGQT2G836YbYBxqknqycKPmLqKq9NBl8C1 CrgeZVWo2OLa4VPEH+1+lYTuTXT5oo1Y3FMFduZYtUGoLueIeXUKloOqYMdVZ3LJZa4idgHL4ov /do//50j9JuVZLEal3JtqsF61WpZ8cEVjCZiAMKY3jzRBCycznUmvJukeQyGTrkwh9lGrjfSPmv H1RkJ2KQeH7WK0OkfdU2H0vSkHMwFNCUXlSaDhqUad+k7Nzkz7PkV2tYSpAR1rlEywyjafndhUt oP9jFT+4V9X2CHVEtfkduWG80Hw== X-Google-Smtp-Source: AGHT+IEJbNUnDx2JeNnvdW9LV+EzHVXhdrAnE0wIQugHmKVHXrDvwNO2KkiktLN3zfaenjrUIhcqXw== X-Received: by 2002:a05:6512:3b23:b0:553:27cb:b84e with SMTP id 2adb3069b0e04-5533d1bb77amr3481253e87.41.1748855102981; Mon, 02 Jun 2025 02:05:02 -0700 (PDT) From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: xakep.amatop@gmail.com, Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v4][PART 2 09/10] xen/arm: Resume memory management on Xen resume Date: Mon, 2 Jun 2025 12:04:20 +0300 Message-ID: X-Mailer: git-send-email 2.48.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Mirela Simonovic The MMU must be enabled during the resume path before restoring context, as virtual addresses are used to access the saved context data. This patch adds MMU setup during resume by reusing the existing enable_secondary_cpu_mm function, which enables data cache and the MMU. Before the MMU is enabled, the content of TTBR0_EL2 is changed to point to init_ttbr (page tables used at runtime). On boot, init_ttbr is normally initialized during secondary CPU hotplug. On uniprocessor systems, this would leave init_ttbr uninitialized, causing resume to fail. To address this, the boot CPU now sets init_ttbr during suspend. Signed-off-by: Mirela Simonovic Signed-off-by: Saeed Nowshadi Signed-off-by: Mykyta Poturai Signed-off-by: Mykola Kvach --- Changes in v4: - Drop unnecessary DAIF masking; interrupts are already masked on resume - Remove leftover TLB flush instructions; flushing is done in enable_mmu - Avoid setting x19 in hyp_resume; not needed - Replace prepare_secondary_mm with set_init_ttbr; call it from system_suspend Changes in v3: - Update commit message for clarity - Replace create_page_tables, enable_mmu, and mmu_init_secondary_cpu with enable_secondary_cpu_mm - Move prepare_secondary_mm to start_xen to avoid crash - Add early UART init during resume Changes in v2: - Move hyp_resume to head.S to keep resume logic together - Simplify hyp_resume using existing helpers: check_cpu_mode, cpu_init, create_page_tables, enable_mmu --- xen/arch/arm/arm64/head.S | 16 ++++++++++++++++ xen/arch/arm/include/asm/mm.h | 2 ++ xen/arch/arm/mmu/smpboot.c | 2 +- xen/arch/arm/suspend.c | 2 ++ 4 files changed, 21 insertions(+), 1 deletion(-) diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S index 3522c497c5..596e960152 100644 --- a/xen/arch/arm/arm64/head.S +++ b/xen/arch/arm/arm64/head.S @@ -564,6 +564,22 @@ END(efi_xen_start) #ifdef CONFIG_SYSTEM_SUSPEND FUNC(hyp_resume) + /* Initialize the UART if earlyprintk has been enabled. */ +#ifdef CONFIG_EARLY_PRINTK + bl init_uart +#endif + PRINT_ID("- Xen resuming -\r\n") + + bl check_cpu_mode + bl cpu_init + + ldr x0, =start + adr x20, start /* x20 := paddr (start) */ + sub x20, x20, x0 /* x20 := phys-offset */ + ldr lr, =mmu_resumed + b enable_secondary_cpu_mm + +mmu_resumed: b . END(hyp_resume) diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/mm.h index 011bc1fd30..868282ec06 100644 --- a/xen/arch/arm/include/asm/mm.h +++ b/xen/arch/arm/include/asm/mm.h @@ -363,6 +363,8 @@ static inline void page_set_xenheap_gfn(struct page_info *p, gfn_t gfn) } while ( (y = cmpxchg(&p->u.inuse.type_info, x, nx)) != x ); } +void set_init_ttbr(lpae_t *root); + #endif /* __ARCH_ARM_MM__ */ /* * Local variables: diff --git a/xen/arch/arm/mmu/smpboot.c b/xen/arch/arm/mmu/smpboot.c index 37e91d72b7..ff508ecf40 100644 --- a/xen/arch/arm/mmu/smpboot.c +++ b/xen/arch/arm/mmu/smpboot.c @@ -72,7 +72,7 @@ static void clear_boot_pagetables(void) clear_table(boot_third); } -static void set_init_ttbr(lpae_t *root) +void set_init_ttbr(lpae_t *root) { /* * init_ttbr is part of the identity mapping which is read-only. So diff --git a/xen/arch/arm/suspend.c b/xen/arch/arm/suspend.c index e3a9b68622..f3ad8517ac 100644 --- a/xen/arch/arm/suspend.c +++ b/xen/arch/arm/suspend.c @@ -65,6 +65,8 @@ static long system_suspend(void *data) goto resume_console; } + set_init_ttbr(xen_pgtable); + /* * Enable identity mapping before entering suspend to simplify * the resume path -- 2.48.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 02 09:05:08 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 09:05:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1002952.1382451 (Exim 4.92) (envelope-from ) id 1uM16S-00022g-4b; Mon, 02 Jun 2025 09:05:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1002952.1382451; Mon, 02 Jun 2025 09:05: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 1uM16R-00021S-Ve; Mon, 02 Jun 2025 09:05:07 +0000 Received: by outflank-mailman (input) for mailman id 1002952; Mon, 02 Jun 2025 09:05: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 1uM16Q-00081k-4b for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 09:05:06 +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 aca78b68-3f90-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 11:05:05 +0200 (CEST) Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-55329bd977aso5224207e87.1 for ; Mon, 02 Jun 2025 02:05:05 -0700 (PDT) Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5533791cdc3sm1507541e87.176.2025.06.02.02.05.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 02:05:03 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: aca78b68-3f90-11f0-a300-13f23c93f187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748855105; x=1749459905; darn=lists.xenproject.org; h=content-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=bD1e3cReyKifgfKVVK1ivsJtIILbWIwhcDmXv0PowdU=; b=aqU9jxcieiQz9hYAEEwZt2MFz4xNK1EvE5cUp5vCASp1MUDMaJ1AvfUTBjaEb80wyd +r9t4lIld9HOv+3l8UzM/pf6uXIRj62T2pUKyHr+QGl+6snbVs72vTT2JRX662x954kp PwmmzhbCJH7Ks0sRBWuLzicerVKm4oMKi0HzxaQzQBHBtZ+0MbIcEZxHeWc4cQe5xAg2 p6BDfgrvJYa9yBzfynVqJY5lF4Lk2oavIJwFIt/RmZ2JKWfxfJEsGelsq7ALq9BtxAyY cwJRT5bWZnHOaK9LYBpsJyXYFbpY9RnzYESwlfwsUCSZ5RLSn5Wdt69nMEb7ORXIpqt2 LiVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748855105; x=1749459905; 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=bD1e3cReyKifgfKVVK1ivsJtIILbWIwhcDmXv0PowdU=; b=NSL8C/5yCaladbBY6T4zXXPOsIeDrEpw3k/USDYV2b0TAUFndc83F2ql7T9YPV2EBP VoFlwGPujmE+ennOY5yysIoiwcDw0ye86uGwZuILkjg6Y8zvpBVOhGGNnDTpBjLEgLlm 8lbkCQBykkMzhe7FxOHXXI7YGuyzo3ckje9xKsKlNGQLw1C5r+oeLMTKv3/J/eQO0n2m KcCRBO3Z1ZQ7VCSRLnydDlN+3S5DeV1tSIG2AG9hAC1BxGgdyg4SrWvXstMcgJzVhxJT 4ia4tD+3LEbc84twuYmvbNWYbdtL+QKEjd1oA9K5Epa+3ojyduprcwZf9VcgSM1AObeQ Zzlw== X-Gm-Message-State: AOJu0YynydaVDej2eOUO5FL78/RJBnvW8CPL4SKNF2Q7xxoYiMqgKi8/ Kcu+nHTFGBEd7MK9ta/l0bHfUENMprTYKIXKOe5h7Bzwnu3YcE0eQobFN7O++WZ1 X-Gm-Gg: ASbGncuoLwDiNz8VRqy0zgRb1TwMy9TsponFm4voNadTq9RiKnZpMwjieuM5FIhukR4 zalGoBILXi/b3ec6jun66U/fQUSBqvm6h/IpeJ0jpKEnTq4W356mplmfFFXXanB8G/P2yuUbu5h 0X2nuA5/hM/IS9JtkpFnhJ+2dQ2z4r3Fiks84oJ5469EZ8eTxeYXJpmNbkiHM4MHEO99m5cR5Vk g0triTtWOiyjo37cX2Gjzzoiq1RjP3AdsohAV9zd5GydWnVkRvdOu9rMgQX8T4J//CxBYwoNeXD Kp086njUD33n2p6Ugf1NH67QlIVVO3UNra3kFqpgFd/J4TNKc2WZjgNBom3ARHUGDTpw9kMYbjn D71IApzUVBaAOhIzOmLI194Ljmg== X-Google-Smtp-Source: AGHT+IFaBoA7Yo/WUepczn6Qruy6S1UWK4p6ZJeemhxCrjIh1ez95m44qZ2wj4raboedU+yZ8Qfwqw== X-Received: by 2002:a05:6512:1592:b0:553:2159:8716 with SMTP id 2adb3069b0e04-5533ba99850mr3614033e87.26.1748855104208; Mon, 02 Jun 2025 02:05:04 -0700 (PDT) From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: xakep.amatop@gmail.com, Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v4][PART 2 10/10] xen/arm: Save/restore context on suspend/resume Date: Mon, 2 Jun 2025 12:04:21 +0300 Message-ID: <8f5904bc8f4d8ee39e248b3a2213fb3ed6815aff.1748848482.git.mykola_kvach@epam.com> X-Mailer: git-send-email 2.48.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Mirela Simonovic The context of CPU general purpose and system control registers has to be saved on suspend and restored on resume. This is implemented in hyp_suspend and before the return from hyp_resume function. The hyp_suspend is invoked just before the PSCI system suspend call is issued to the ATF. The hyp_suspend has to return a non-zero value so that the calling 'if' statement evaluates to true, causing the system suspend to be invoked. Upon the resume, context saved on suspend will be restored, including the link register. Therefore, after restoring the context the control flow will return to the address pointed by the saved link register, which is the place from which the hyp_suspend was called. To ensure that the calling 'if' statement doesn't again evaluate to true and initiate system suspend, hyp_resume has to return a zero value after restoring the context. Note that the order of saving register context into cpu_context structure has to match the order of restoring. Support for ARM32 is not implemented. Instead, compilation fails with a build-time error if suspend is enabled for ARM32. Signed-off-by: Mirela Simonovic Signed-off-by: Saeed Nowshadi Signed-off-by: Mykyta Poturai Signed-off-by: Mykola Kvach --- Changes in v4: - produce build-time error for ARM32 when CONFIG_SYSTEM_SUSPEND is enabled - use register_t instead of uint64_t in cpu_context structure --- xen/arch/arm/arm64/head.S | 88 +++++++++++++++++++++++++++++- xen/arch/arm/include/asm/suspend.h | 20 +++++++ xen/arch/arm/suspend.c | 23 +++++++- 3 files changed, 127 insertions(+), 4 deletions(-) diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S index 596e960152..70bb305ce3 100644 --- a/xen/arch/arm/arm64/head.S +++ b/xen/arch/arm/arm64/head.S @@ -562,6 +562,52 @@ END(efi_xen_start) #endif /* CONFIG_ARM_EFI */ #ifdef CONFIG_SYSTEM_SUSPEND +/* + * int hyp_suspend(struct cpu_context *ptr) + * + * x0 - pointer to the storage where callee's context will be saved + * + * CPU context saved here will be restored on resume in hyp_resume function. + * hyp_suspend shall return a non-zero value. Upon restoring context + * hyp_resume shall return value zero instead. From C code that invokes + * hyp_suspend, the return value is interpreted to determine whether the context + * is saved (hyp_suspend) or restored (hyp_resume). + */ +FUNC(hyp_suspend) + /* Store callee-saved registers */ + stp x19, x20, [x0], #16 + stp x21, x22, [x0], #16 + stp x23, x24, [x0], #16 + stp x25, x26, [x0], #16 + stp x27, x28, [x0], #16 + stp x29, lr, [x0], #16 + + /* Store stack-pointer */ + mov x2, sp + str x2, [x0], #8 + + /* Store system control registers */ + mrs x2, VBAR_EL2 + str x2, [x0], #8 + mrs x2, VTCR_EL2 + str x2, [x0], #8 + mrs x2, VTTBR_EL2 + str x2, [x0], #8 + mrs x2, TPIDR_EL2 + str x2, [x0], #8 + mrs x2, MDCR_EL2 + str x2, [x0], #8 + mrs x2, HSTR_EL2 + str x2, [x0], #8 + mrs x2, CPTR_EL2 + str x2, [x0], #8 + mrs x2, HCR_EL2 + str x2, [x0], #8 + + /* hyp_suspend must return a non-zero value */ + mov x0, #1 + ret +END(hyp_suspend) FUNC(hyp_resume) /* Initialize the UART if earlyprintk has been enabled. */ @@ -580,7 +626,47 @@ FUNC(hyp_resume) b enable_secondary_cpu_mm mmu_resumed: - b . + /* Now we can access the cpu_context, so restore the context here */ + ldr x0, =cpu_context + + /* Restore callee-saved registers */ + ldp x19, x20, [x0], #16 + ldp x21, x22, [x0], #16 + ldp x23, x24, [x0], #16 + ldp x25, x26, [x0], #16 + ldp x27, x28, [x0], #16 + ldp x29, lr, [x0], #16 + + /* Restore stack pointer */ + ldr x2, [x0], #8 + mov sp, x2 + + /* Restore system control registers */ + ldr x2, [x0], #8 + msr VBAR_EL2, x2 + ldr x2, [x0], #8 + msr VTCR_EL2, x2 + ldr x2, [x0], #8 + msr VTTBR_EL2, x2 + ldr x2, [x0], #8 + msr TPIDR_EL2, x2 + ldr x2, [x0], #8 + msr MDCR_EL2, x2 + ldr x2, [x0], #8 + msr HSTR_EL2, x2 + ldr x2, [x0], #8 + msr CPTR_EL2, x2 + ldr x2, [x0], #8 + msr HCR_EL2, x2 + isb + + /* Since context is restored return from this function will appear as + * return from hyp_suspend. To distinguish a return from hyp_suspend + * which is called upon finalizing the suspend, as opposed to return + * from this function which executes on resume, we need to return zero + * value here. */ + mov x0, #0 + ret END(hyp_resume) #endif /* CONFIG_SYSTEM_SUSPEND */ diff --git a/xen/arch/arm/include/asm/suspend.h b/xen/arch/arm/include/asm/suspend.h index 55041a5d06..ae71ccb87b 100644 --- a/xen/arch/arm/include/asm/suspend.h +++ b/xen/arch/arm/include/asm/suspend.h @@ -5,9 +5,29 @@ #ifdef CONFIG_SYSTEM_SUSPEND +#ifdef CONFIG_ARM_64 +struct cpu_context { + register_t callee_regs[12]; + register_t sp; + register_t vbar_el2; + register_t vtcr_el2; + register_t vttbr_el2; + register_t tpidr_el2; + register_t mdcr_el2; + register_t hstr_el2; + register_t cptr_el2; + register_t hcr_el2; +} __aligned(16); +#else +#error "Define cpu_context structure for arm32" +#endif + +extern struct cpu_context cpu_context; + int host_system_suspend(void); void hyp_resume(void); +int hyp_suspend(struct cpu_context *ptr); #endif /* CONFIG_SYSTEM_SUSPEND */ diff --git a/xen/arch/arm/suspend.c b/xen/arch/arm/suspend.c index f3ad8517ac..b1b8644a75 100644 --- a/xen/arch/arm/suspend.c +++ b/xen/arch/arm/suspend.c @@ -1,6 +1,7 @@ /* SPDX-License-Identifier: GPL-2.0-only */ #include +#include #include #include #include @@ -17,6 +18,8 @@ * - Investigate feasibility and need for implementing system suspend on ARM32 */ +struct cpu_context cpu_context; + /* Xen suspend. Note: data is not used (suspend is the suspend to RAM) */ static long system_suspend(void *data) { @@ -73,9 +76,23 @@ static long system_suspend(void *data) */ update_boot_mapping(true); - status = call_psci_system_suspend(); - if ( status ) - dprintk(XENLOG_WARNING, "PSCI system suspend failed, err=%d\n", status); + if ( hyp_suspend(&cpu_context) ) + { + status = call_psci_system_suspend(); + /* + * If suspend is finalized properly by above system suspend PSCI call, + * the code below in this 'if' branch will never execute. Execution + * will continue from hyp_resume which is the hypervisor's resume point. + * In hyp_resume CPU context will be restored and since link-register is + * restored as well, it will appear to return from hyp_suspend. The + * difference in returning from hyp_suspend on system suspend versus + * resume is in function's return value: on suspend, the return value is + * a non-zero value, on resume it is zero. That is why the control flow + * will not re-enter this 'if' branch on resume. + */ + if ( status ) + dprintk(XENLOG_WARNING, "PSCI system suspend failed, err=%d\n", status); + } system_state = SYS_STATE_resume; update_boot_mapping(false); -- 2.48.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 02 09:15:19 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 09:15:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003035.1382468 (Exim 4.92) (envelope-from ) id 1uM1GF-0007Sx-AJ; Mon, 02 Jun 2025 09:15:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003035.1382468; Mon, 02 Jun 2025 09:15:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uM1GF-0007Sq-7M; Mon, 02 Jun 2025 09:15:15 +0000 Received: by outflank-mailman (input) for mailman id 1003035; Mon, 02 Jun 2025 09:15:14 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uM1GE-0007SZ-AY for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 09:15: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 14907edb-3f92-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 11:15:09 +0200 (CEST) Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-43ea40a6e98so44355865e9.1 for ; Mon, 02 Jun 2025 02:15:09 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-747afe9681asm7396382b3a.12.2025.06.02.02.15.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 02:15:08 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 14907edb-3f92-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1748855708; x=1749460508; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=lPySZfbm9D5ca0VETYqleubXSTJeG2xriOZGDql9+Vo=; b=BEKNLNJi63/ElCUYQr64d5LYemsBIKF4P4zrqssV7Qk4b7ID9dgaTir6XersW/hhJZ 6kv0q1HrAfQEaGxJwOlamDFJHUgNhci8ui6oYvY6odOxjssojolvwoVoZtrp2lA5i8Iw ZL6EYVU64oCQohJd3i8sNz5Rzwo7wiDOc6nVWvv+wqnwRfeVMLFotYjqaie1U0nWb4O8 OiHhsRpDAWII0yYd1ZXCl0pwFOguW0xiyxtrySndha0JrllcJOrVK9jea/iYK4iMSD8T h4qTZCjofr2iT/rqDMDCWHsQG/QxAk6NXDcvmCfeomui+vNd5xCS1uTHLlbGis0WSVXd 09fA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748855708; x=1749460508; 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=lPySZfbm9D5ca0VETYqleubXSTJeG2xriOZGDql9+Vo=; b=MtXn7Qh1KzDLkcXLfTibVc+Ab7y4v2FgkqtuopljzqoRipX4f1kXcuV67J9lxK7GTQ fQYIgAbkUxtzuTG/KcuJx0U0fNXfpcCT9d2vDYwqhEYxPRigSciFLqPeF9WjIplyMjIO 6E67r4eC90qkvoZ9xMwHu9D+4Ye9nDSTKgTTO7njcL5gQMf5g0A7pdwAjNHozvg7ctHE qOpIl9p65jwcLMUbrmZistEfGCNKp5Tu52scuHXzKXokqSFY0ZI2qQFtDd9mV+BCsLMM H43L0IE3kKwMEabcF7rpHhfcQ8OnsBGNSMRAPeGuJZaUAnPZ3+IpJpbKOTB/m9EkN3QH wwpQ== X-Forwarded-Encrypted: i=1; AJvYcCVd5AurHEP7XN2YthIUCz6FjUN4t3hVsNPonv3ruF+n+iWPw40B6AUvX0pyXQWWtxm4C/ITyJxwuag=@lists.xenproject.org X-Gm-Message-State: AOJu0YxvjrF3Gar771kCQJc6z8VDfMy1/MAQONV6YvpYGdbDdEayXBsv x9exKUV+VpaEoDKLFmYhjbH5FSBmjyekygPoM6slUP9GwuUqxsW5/cI1u03HZ3OkZQ== X-Gm-Gg: ASbGncs1596GOUsjHnGW89EL5fiKWKkyR66m6hOkwZRoqP3w73Ckv8b2pk7K5WXiqrS LBVLqSiPmqZqmPV8gldStp/YkWjawqQIisc3lXIci/cJsh8QB6WA+ndEYnpHOXhGy4yeTNFgi8R /W0cRWvGkR2XOBgu0dufs41fXCTPPNtWOhQRc7atJXcJ+tIWY60cinoI4Qf6GcLCOt/3yvVmEZt HyOSZIS26Ecaz1AMZfm5RUfaCqTEQUrd0tFePlEbiBnk/rizRxJ+CvXDjGnxihh2mMGng8uFbxQ vvhPMJ8EAzqDsCcXv0Kiolom3PCtBV7LOmdakiNz30C5obY6cbn3PsymOM6ojDWPYNGDH8fagQ5 B0x61Mz4cqCv8f6ggLnZX7xcd9559wYkfRYmo X-Google-Smtp-Source: AGHT+IGZySKSZr/f1ttYZPglStKrSY8vsfwajd2hmSjJQa2zJ1RpCIsq24MLqKzl/bbV32vC8x2kvw== X-Received: by 2002:a05:6000:2303:b0:3a4:deb9:8964 with SMTP id ffacd0b85a97d-3a4f7a4d340mr9190816f8f.17.1748855708550; Mon, 02 Jun 2025 02:15:08 -0700 (PDT) Message-ID: <66ec1282-808b-49c0-872e-e440a9b9384b@suse.com> Date: Mon, 2 Jun 2025 11:15:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9 3/3] xen/domain: introduce CONFIG_MAX_DOMID To: dmkhn@proton.me Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org, roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com, xen-devel@lists.xenproject.org References: <20250528225030.2652166-1-dmukhin@ford.com> <20250528225030.2652166-4-dmukhin@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: <20250528225030.2652166-4-dmukhin@ford.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 29.05.2025 00:50, dmkhn@proton.me wrote: > From: Denis Mukhin > > From: Denis Mukhin > > Embedded deployments of Xen do not need to have support for more than dozen of > domains. > > Introduce build-time configuration option to limit the number of domains during > run-time. > > Suggested-by: Julien Grall > Signed-off-by: Denis Mukhin > --- > Changes since v8: > - dropped hunk w/ compile-time check for DOMID_FIRST_RESERVED > - updated CONFIG_MAX_DOMID explanation > - dropped public header file changes > --- > xen/arch/x86/cpu/mcheck/mce.c | 2 +- > xen/arch/x86/cpu/vpmu.c | 2 +- > xen/common/Kconfig | 8 ++++++++ > xen/common/domain.c | 20 +++++++++++--------- > xen/common/sched/core.c | 4 ++-- > xen/drivers/passthrough/vtd/iommu.c | 2 +- > 6 files changed, 24 insertions(+), 14 deletions(-) What about checks against DOMID_FIRST_RESERVED in common/domctl.c? Indeed they must not be changed, but when not changing them, how are several of the checks you actually change going to be correct? (I'm sorry for noticing this only now; it should have occurred to me earlier on.) Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 02 09:20:23 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 09:20:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003049.1382478 (Exim 4.92) (envelope-from ) id 1uM1L8-0000as-UJ; Mon, 02 Jun 2025 09:20:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003049.1382478; Mon, 02 Jun 2025 09: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 1uM1L8-0000al-RN; Mon, 02 Jun 2025 09:20:18 +0000 Received: by outflank-mailman (input) for mailman id 1003049; Mon, 02 Jun 2025 09:20: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 1uM1L7-0000af-Eh for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 09:20:17 +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 cbc813e2-3f92-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 11:20:16 +0200 (CEST) Received: by mail-wr1-x42c.google.com with SMTP id ffacd0b85a97d-3a4fea34e07so927828f8f.1 for ; Mon, 02 Jun 2025 02:20:16 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-747affd41c3sm7426903b3a.149.2025.06.02.02.20.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 02:20:15 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cbc813e2-3f92-11f0-a300-13f23c93f187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1748856016; x=1749460816; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=Z0cD2HHhOIx0K6TxQbxJpirEOQrDsyEh1e27Yog7Hec=; b=BbX6+yDKXQhaj3XZ55Ax8ijFIRHQu8+IPSeXSdF5dEmEno+pP+6a1VmUxU+F7kLmDl xe0M6RSdOP+rRuyTP70yPEPA+69Yp4rdHUw+9J6geCdJcQlrAb+GunQFxjYBzRWQbo6k /MkcAfHEdOQO1r2fNvcd1Jl+SB5piMUYsKK19bDNfm5x9nxeYzxInNqsTNH1YPCbrPaB kNYhF2aA2SaZFVFsoCnIL1AwxppM2zqGY1ywABPqBU0g9BHDjBBxM7HFUbogwTbZE95H Q9BPlaWXf6bjHUMGeN7ii8krqfchpl+4eRotNV0cc0w+lJJeXhF8goiMKYOi+KgvnpSs TfoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748856016; x=1749460816; 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=Z0cD2HHhOIx0K6TxQbxJpirEOQrDsyEh1e27Yog7Hec=; b=UmOxkZE4zemzE2CABsglqQkR8LB1+fSX8AyCudKaVgxs0kFgi/KjW6SYls3A4kwGhw i/ktpu3omFQC4dZy+0B1GZ0KMUNJo45UfB9SMnOlGPET9+M8DmRuACz/0D6u1fu93FS+ wPcqUXBO1nx03usbGZDYy+eb6xjcBRKeG4YGYBK1cVvNmS83MrAtSc4l+vOzyACNRDgA iePjtyeBiUAOjJfLvRFgn6teAlciaO/+dprI6VYtd+N/UW1PC11OTpPi2L5pZCNSc3qb mcfyg2dAMDiesIcVYNJYEzBtLpfsXzFSidm4llY3Ioz6m7vMFhVkRyrMARI0gLRPK5q4 ScDA== X-Forwarded-Encrypted: i=1; AJvYcCX5aRtsSRSaBgDiQeVB5S8Fn2xo5jhXTqqDg+pI0AdQsmvEG+4o2YMzqgTi8JoRR0V0i6MdIg94XQk=@lists.xenproject.org X-Gm-Message-State: AOJu0YxiFd8jCQPtcYvSArclJ58ZkPrTz9Bjze1IOPYi4IJiD4GhV/YN JStUiiXNIyODMmsToLsaSS5yGDahzu27P2L81nIzWm//Wb/HB/FD9oDLYknjo5MAyg== X-Gm-Gg: ASbGncsAZnj5O+f/bRlfgQZHTJh9XCPQh/iMBA+/GtuXHm1vcDKyBrXJLczzFRdolSW Y49Bhi9mfW3rpwHaNLiJLxvUHhH/gP8VX75+f+kacxq27uvti7AFtXu+1h+z/fKIc2ISaHETtZW 5mPy0q5g5DdBOJhuE6GOFYDlvB+VIughqfwzBJgR+2PbxV/zA23ra/itUG0I//GXhVnwXKs7eUb duPXXV2oy/8EB2cAI6K8828d1rS7QGJOvJ29f5GbWD88bUm4jUDcUDn6peJsDpJP6AxtIbikojd +vzIh0XDHpYGkD5L1qQjqimIyVD0IBkvzjb1VD+sJY2u9c0L4IP54dCXAuFcmyYDtAxQqq8SI3/ Xnc+nsk5pk+YtyWkdWjktTUora62maPLDTPzgKLi7thiCUGI= X-Google-Smtp-Source: AGHT+IH7gf5s/Ru8n5gf9eYTT0PRUgu02WTxxIBjfJmq8CfUdj1Z2yxsRwUzeA5Zpfkm+xBPG1NLZw== X-Received: by 2002:a05:6000:1889:b0:3a4:dc80:b932 with SMTP id ffacd0b85a97d-3a4f7a0251dmr9015734f8f.8.1748856015989; Mon, 02 Jun 2025 02:20:15 -0700 (PDT) Message-ID: <4bfe5a9a-6128-4760-9121-46b0d9bd6789@suse.com> Date: Mon, 2 Jun 2025 11:20:20 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4][PART 2 01/10] xen/x86: Move freeze/thaw_domains to common code To: Mykola Kvach Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/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.06.2025 11:04, Mykola Kvach wrote: > From: Mirela Simonovic > > The freeze_domains and thaw_domains functions are currently defined > in x86-specific suspend code. These functions are also useful on other > architectures, such as ARM, for implementing system-wide suspend and > resume functionality. > > This patch moves these functions to common code so they can be reused > across architectures. > > Signed-off-by: Mirela Simonovic > Signed-off-by: Saeed Nowshadi > Signed-off-by: Mykyta Poturai > Signed-off-by: Mykola Kvach On the assumption that the transient Misra violation is okay: Acked-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 02 09:24:45 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 09:24:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003055.1382488 (Exim 4.92) (envelope-from ) id 1uM1PQ-00024o-EQ; Mon, 02 Jun 2025 09:24:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003055.1382488; Mon, 02 Jun 2025 09:24:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uM1PQ-00024h-AX; Mon, 02 Jun 2025 09:24:44 +0000 Received: by outflank-mailman (input) for mailman id 1003055; Mon, 02 Jun 2025 09: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 1uM1PP-00024b-Tr for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 09:24:43 +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 6a137796-3f93-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 11:24:42 +0200 (CEST) Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-551fe46934eso4813108e87.1 for ; Mon, 02 Jun 2025 02:24:42 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6a137796-3f93-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748856281; x=1749461081; 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=qzDXYs/TNa8CfSzGEAtyBDVTqaKRNSpTzDTdNGCr4zs=; b=SCsk2C60scW5cO2jsaMgg5l+HybJva6UHh/D5cRy8V4HDxD8u+BYA3Np2W4TVx/PBa RqcC8FUJcNeloEvhn3jRVXDtkiAhIh2eHgtx7lERTszC84NIqGNEBfaWx0mO6kSohQ8d 2YGbrmxqi19FSyohkjSu8pn2cQQsb4S9Ogbh0+UEL33dr9ecWRsyDtSRCTrbKO4CnHFk 0WvYEmNHMxoM0Pe7raYJay33pDrU/+3+g6gdUZf6mNyogvCqkWzlMKCqC3OegmPDmKG5 qIekbjTSXnMkbarfVnuc0R2rmibz5Ac5PNRCPElmXphhzmdYZ7eOT7PfgYT1gCL5IfIo +N9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748856281; x=1749461081; 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=qzDXYs/TNa8CfSzGEAtyBDVTqaKRNSpTzDTdNGCr4zs=; b=vF3igTLyQlg65ArZbA5Sqa35xRnbZUBDZXGYQ/XgXB3egjN8GbT6gBiH1sxTP86JJb zRWE0af5K588AfA5lu/cYFQK0N9awXipFXA3gp1YdXtHH819WFE55ePQL9YhtrT/RGTC YdwY+rKjSJWCraNE9rXYGHltRZ7WaS3XUp69q1CbpRmpq80Hv7c+foV7MCvWlK71mgqz eJlTC3JOKv1cAtVy9Oo+5T82x3qY/LbZUOD4AVfwu3aSYPotkPQ8Fcyox4tB4kePs+rK DQvZjBPXsvciLtyqYvxzAIiobUlPmkjQJrm+/KqI/GqJxNCaBn1YvEATBbipXKTkoATb dcnA== X-Gm-Message-State: AOJu0YwMY5jVP0BdDquraIiv8C8MpBbrjcSRNCVvBh84PDzMnNsm7Sto jC4nxllVUg2tyKXOLK1+uTNySO+MBMwvRUPB9Y44m0UmlLLGTUvw9YsYaKulP5Jl9XXCel/Pbim 9yxxOa5o5nIjzB/T3OwIvsRf783vgqak= X-Gm-Gg: ASbGncvLQaKr5EJI5/WdcEHnETDMMiaQgt3qwpwGxWSy/qiKwITYWMOMEpmxslNt0PK sOmv/FQa31cNCLW72oSlUsO86/4ofVL64DIc2MsKQkmmrix8ni0XshSUdQ3KIra7yoXtZ99VO1C FXwm2OtUwEdtkwfshaTkrvEv6hg7BUyQvxRxLT/4JzGQ== X-Google-Smtp-Source: AGHT+IFGp3hOtFmFrnmNQpGZXL8QndS/jOoMW61IiBKpSMXmCsucKddHh1Y0bHLeiZv2hO/+IJi+qTfya5jTC9MHXyM= X-Received: by 2002:a05:6512:118d:b0:553:2bdf:8b87 with SMTP id 2adb3069b0e04-55335b117ebmr4686574e87.10.1748856281394; Mon, 02 Jun 2025 02:24:41 -0700 (PDT) MIME-Version: 1.0 References: <9b1f50a40e3634f859ad8e7446c24e43caaa38eb.1748637004.git.mykola_kvach@epam.com> <26d614da-3fb4-4209-8123-096512911897@amd.com> In-Reply-To: <26d614da-3fb4-4209-8123-096512911897@amd.com> From: Mykola Kvach Date: Mon, 2 Jun 2025 12:24:29 +0300 X-Gm-Features: AX0GCFtrFid9ZUNyeaH5UxXRhUqIPDgY2dSNowP9IBDHElpmBOujb6W1kMTWIdI Message-ID: Subject: Re: [PATCH] xen/arm64: head: document missing input registers for MMU functions To: "Orzel, Michal" Cc: xen-devel@lists.xenproject.org, Mykola Kvach , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, @Michal Orzel On Mon, Jun 2, 2025 at 10:10=E2=80=AFAM Orzel, Michal wrote: > > > > On 30/05/2025 22:31, Mykola Kvach wrote: > > From: Mykola Kvach > > > > Add missing input register descriptions to enable_secondary_cpu_mm > > and enable_boot_cpu_mm functions. > > > > Specifically: > > - x19 is used in enable_boot_cpu_mm as physical start address. > > - x20 is used in both functions for physical offset passed to load_padd= r. > I'm not sure if we need to document register usage that is part of a comm= ent in > so called "Common register usage". It's repeating information for me. Tha= t said, > I can see that Arm32 does that too so no objection. I'll drop that sentence from the commit message. > > > > > This update improves code clarity and consistency in comments. > > > > No functional changes are introduced by this patch. > > > > Signed-off-by: Mykola Kvach > > --- > > xen/arch/arm/arm64/mmu/head.S | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/xen/arch/arm/arm64/mmu/head.S b/xen/arch/arm/arm64/mmu/hea= d.S > > index 634156f83d..033b3a018a 100644 > > --- a/xen/arch/arm/arm64/mmu/head.S > > +++ b/xen/arch/arm/arm64/mmu/head.S > > @@ -313,6 +313,7 @@ END(enable_mmu) > > * > > * Inputs: > > * lr : Virtual address to return to. > > + * x20: phys offset (used by load_paddr) > > * > > * Clobbers x0 - x6 > > */ > > @@ -337,6 +338,8 @@ END(enable_secondary_cpu_mm) > > * > > * Inputs: > > * lr : Virtual address to return to. > > + * x19: paddr(start) (used by remove_identity_mapping) > AFAICT it's also used by create_page_tables. I don't see it beneficial to > mention the places the register is used. It can easily go stale. I'll remove the mention of usage locations. > > With the remark addressed: > Reviewed-by: Michal Orzel Thank you for reviewing the patch. > > ~Michal > ~Mykola From xen-devel-bounces@lists.xenproject.org Mon Jun 02 09:26:47 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 09:26:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003062.1382498 (Exim 4.92) (envelope-from ) id 1uM1RK-0002bk-OZ; Mon, 02 Jun 2025 09:26:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003062.1382498; Mon, 02 Jun 2025 09: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 1uM1RK-0002bd-Lg; Mon, 02 Jun 2025 09:26:42 +0000 Received: by outflank-mailman (input) for mailman id 1003062; Mon, 02 Jun 2025 09:26: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 1uM1RJ-0002bW-BN for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 09:26:41 +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 b07dbdf3-3f93-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 11:26:40 +0200 (CEST) Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-3a50956e5d3so738715f8f.1 for ; Mon, 02 Jun 2025 02:26:40 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-747afe96474sm7229219b3a.22.2025.06.02.02.26.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 02:26:39 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b07dbdf3-3f93-11f0-a300-13f23c93f187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1748856400; x=1749461200; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=DJXWp3fAzCxU30vF/SD3NX/7M+QmejJN6no0tmul914=; b=W/+cUeA7Lm4qB7OX/zkBVIoUA4KRPtJGDKn5qWg0vL7rideX5jTWYoPN+6vKuhOMx5 5DFx+pFyPUCBmfuA6T2Cc7eyMwCN9s+L+O5L3OicupwYmhJIY4ltExntrbYJDhGX1reP 8GDRdG63fzKHM0TdLm7q3+cbKUItNPOKyE6qUWmsmleeZ2CCJxfF32huXL+lEjDwBj+m E2oY1d9q9Z9zq7X/Hb0huDo8QH9emhBcWylqfVG0ZaELYUgD7otLEXl7A5v6eCXvfsK6 CmUigiYoM8ElO3cDzg9aXK48o3dMbiSKd7+37E9V/j2WOhvQLPI4mpBDN+96yvWyl9Y7 DBEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748856400; x=1749461200; 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=DJXWp3fAzCxU30vF/SD3NX/7M+QmejJN6no0tmul914=; b=DNWZJmsJgI+npqWKO8aZh2FCBLWQdoQQNEgDClo+Lt2KCR7kcRdE9yWTIKe2FKTuZL 559knkItBEqJjKEOaTz3suAto4wiRTjpqNZVMon8nXXDh8awX5+OR6Yz1GOU/2UGWM8u JEAOMcvQxc5IpzQXxD68T2uPuSGJavisG6CmhFCKUzwafxr9NySiAWERXLypfnloeGkp VP41yNrSJfaXTGAwKZYg6V/2h9baMj6ezdFOOZFgBn1kSYEe8E+Hs1c+gOiXbgS2Izv2 VHt+h5ItP1VOwmhdthHYcCGLrqvpaQpjb7ebGM34HFbdriD+SI02WhdPkkPPrOFA7l3J d47Q== X-Forwarded-Encrypted: i=1; AJvYcCVo6PLEC2CsIwcufvZrP9X0F0YYRVeGr4SAdRc64dQuhS46jDAzjr+W1XjC56ZKLPrGbQJyM7ymu4A=@lists.xenproject.org X-Gm-Message-State: AOJu0YwlHgOew3PWCI9628tuWbQdSFX3V+rCRl+WqiTZBaCCf3KbRVSX oCmIvwAb0Oaw7XDAMSwnRn7EIubxaI9Ntp8gMZfYdZX1NisXww/ne5BKUQr9paJ9Uw== X-Gm-Gg: ASbGnculPb4E30cQklVm5SS3yveTcPP4kn6kgtNdC30HDkv1sk0Etn5uScWf/7MBo6P l/bzpZkJRNzDdXFt5mt1lBhkvzh65i4EsYdgPEiRz94A18WSlQ6sqkJZ8exPWPgnRopHPmgFrrM qs4xjK22eNAuT+1K6cAn9zC7DwkNge6otAu5QBvqSH26DpbQCHL34cVElZdBnO2rZmetq9Hbu+F 9/C6BUxkfC685oKBxunyAb6h8KARCMKFK+Z/Tb2ONWjTkOjtH3vf2W0h3I93kC1C+n3YK8LFM9c 9rIzvjupuseBSOMOsNK+kMZIsYaki1ipU7vGT2dy25+6/hcfk2nqFpJq1uxp7tr5QxhDWV9/O6H R+PZ/5l8aAnTezeNCQStQF0yX6DJI0DDsb/PhDHrY9ovh6wxAMpVujUeoHg== X-Google-Smtp-Source: AGHT+IFP/6X/OfzSMdMb497K2+J4DcXrjq/ILa4TRv3Fk17NS0VMNPbxnjN2DFiBMrzWBd2+aha8yQ== X-Received: by 2002:a5d:64e7:0:b0:3a3:7a33:c96a with SMTP id ffacd0b85a97d-3a4f7ab15c3mr9542447f8f.51.1748856399662; Mon, 02 Jun 2025 02:26:39 -0700 (PDT) Message-ID: <90048f71-8313-4110-924c-f956a2bec5a0@suse.com> Date: Mon, 2 Jun 2025 11:26:41 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4][PART 2 07/10] xen/arm: Add support for system suspend triggered by hardware domain To: Mykola Kvach Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Shawn Anastasio , Alistair Francis , Bob Eshleman , Connor Davis , Oleksii Kurochko , xen-devel@lists.xenproject.org References: <7bd75ecfff5b0a75ea5abd7cc4934582d7e1250c.1748848482.git.mykola_kvach@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: <7bd75ecfff5b0a75ea5abd7cc4934582d7e1250c.1748848482.git.mykola_kvach@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 02.06.2025 11:04, Mykola Kvach wrote: > @@ -857,8 +860,24 @@ void arch_domain_destroy(struct domain *d) > domain_io_free(d); > } > > -void arch_domain_shutdown(struct domain *d) > +int arch_domain_shutdown(struct domain *d) > { > + switch ( d->shutdown_code ) > + { > + case SHUTDOWN_suspend: > +#ifdef CONFIG_SYSTEM_SUSPEND > + if ( !is_hardware_domain(d) ) > + break; > + > + return host_system_suspend(); > +#else > + break; > +#endif > + default: > + break; > + } > + > + return 0; > } What's wrong with int arch_domain_shutdown(struct domain *d) { switch ( d->shutdown_code ) { #ifdef CONFIG_SYSTEM_SUSPEND case SHUTDOWN_suspend: if ( !is_hardware_domain(d) ) break; return host_system_suspend(); #endif default: break; } return 0; } ? > @@ -1311,13 +1316,13 @@ int domain_shutdown(struct domain *d, u8 reason) > v->paused_for_shutdown = 1; > } > > - arch_domain_shutdown(d); > + ret = arch_domain_shutdown(d); If non-zero comes back here, is ... > __domain_finalise_shutdown(d); ... this still appropriate to call? > spin_unlock(&d->shutdown_lock); > > - return 0; > + return ret; > } Most callers don't care about the return value of this function. That likely needs to change, even if _for now_ you only alter the SHUTDOWN_suspend case (and hence some of the callers aren't immediately impacted)? Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 02 09:36:00 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 09:36:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003069.1382507 (Exim 4.92) (envelope-from ) id 1uM1a6-0004vu-Hb; Mon, 02 Jun 2025 09:35:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003069.1382507; Mon, 02 Jun 2025 09:35: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 1uM1a6-0004vn-ET; Mon, 02 Jun 2025 09:35:46 +0000 Received: by outflank-mailman (input) for mailman id 1003069; Mon, 02 Jun 2025 09:35: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 1uM1a4-0004vh-Ul for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 09:35:44 +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 f41d928a-3f94-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 11:35:43 +0200 (CEST) Received: by mail-wr1-x435.google.com with SMTP id ffacd0b85a97d-3a50fc819f2so202920f8f.2 for ; Mon, 02 Jun 2025 02:35:43 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-b2eceb396f6sm4491200a12.42.2025.06.02.02.35.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 02:35:42 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f41d928a-3f94-11f0-a300-13f23c93f187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1748856943; x=1749461743; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=2Yu5AAL3zoKPvgz1Wy3fQ+yLKsDz3HqiqShgBRi5YVw=; b=XGIhZJ6G7Imr4D8MiG9MCYy0J0czoI3glhq+WNYFAk4tjDvKOexzEJHQ43YnPB+7SI yjO7e2Mhv4Rx1Xjjb8UWwT+CBxVMYTS18I9hZD53lSSzhhTGzTNhEgxw1nGGKIZftUbS 20hht4RnXsUbLwGKXl/Im/wVSyy250vLWPZQnlhln0NNCoe+apgyo4/9UFtwLQjX01pS lIg5mUJF1JLb1FyNlE8SazUOgPOHzszYlNSoVbFYCsJ0/bK1cuBquNi4rA9urfvxo/1h TxJSHKyUDtXiEI/X6i2yqYvGlY/t+k1R7KNqfVAdAnmE6kY5WCyuvPS480ul4m0ybWA7 QADw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748856943; x=1749461743; 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=2Yu5AAL3zoKPvgz1Wy3fQ+yLKsDz3HqiqShgBRi5YVw=; b=nQpJX4SO5u/jVyumO4HppfsMuVxUghPdsvwn3Vjc5CmZvqzW6gOrxdzRwR/aMRVDBx RKklXwKJ2Ov3YrxgNOV6mElOlhGfEsxK1g+nweCk0mYU57T/y+G3+Ak+8T3ciW9yz+gv oq6gFgQHeZT3HcheDkB/7+uMaUcAdLr8qwMbWohxiMRuS+0ibyDzLHPY4vI2D4+Koi4b SIKjTOPi/V/LdffQsIzvRyCBCn2l7EJ+5N4EcL9j1UV0ACG8Oib8m9gxuEAalMzVhirV cElzLW6K6EHwPw6ksrbmunUBhtTUGwUE/Q2AN5EG8fhGeIqHFgPZujnAmuBvdDaimfQ+ N4ag== X-Forwarded-Encrypted: i=1; AJvYcCWYczmyhIKY4PmFtZwwIrNSvH+tblz0wASBb1BdYG8OI1IGGH4aeRgvKTkNTM3BA/J2rzG6XwtTUSU=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy1qjUY/jbS9nzfqWlyzje1oIp1EGQhjIIMY+ItZOCcfTWjYZnx +OXdgE5XW4bwHDeybcw3APSrU1W7LA9e/KVf0LMpbmfsEMGt+PlhHoeskBldHY7Qqg== X-Gm-Gg: ASbGncu6KVJyJKPpt5x8xlsCvzud7npdusc9die9ed01d3RjUHjERzDfxhrPtu29Dly a8sxSz0blekwktdZJZf9/7IFVIa0HlYldoGh7kFk+kinEEFVB08zb17RNtZaumvE8+BvQAz8+bi DBpSJO+cPgo63jylZ3CoQ9XU2S3s0XAu69ODKtszst4fXbh8AHx70eIIHXsXWgARYXp0v6gvctf yVUXjOWpiDoeQALLHTxwRu8AgCjIarToLPrHRsuQFiD1ivRXSh4BbyeIkGmJCqc08o2eqSP4Yh5 rZaBtsWnfasluBoubqZiRrC8aaD2Yn9FnQCaB7nKyKd9qf7bv1JTi5EsutumDDq7yYa51mHzogI zwQ8MoCSDIh6WBXFXiP5TwWyX/ohfSUfRAY7f5AFwFpPoFmE= X-Google-Smtp-Source: AGHT+IGTp70XTPR7UcAZewF3ACtFqXkDT/PZzqfQPlGgU/iZjWf6BOAc2yXMpR6D3IM6Imgh/AkSvQ== X-Received: by 2002:a05:6000:18ab:b0:3a4:fb33:85ce with SMTP id ffacd0b85a97d-3a4fb3388bbmr8265737f8f.46.1748856942606; Mon, 02 Jun 2025 02:35:42 -0700 (PDT) Message-ID: <9ac69643-6510-4a14-8187-9e2d0c831576@suse.com> Date: Mon, 2 Jun 2025 11:35:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/bitops: Optimise arch_ffs()/etc some more on AMD To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250527222930.1452674-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: <20250527222930.1452674-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 28.05.2025 00:29, Andrew Cooper wrote: > One aspect of the old ffs()/etc infrastructure was the use of TZCNT/LZCNT > without a CPUID check. Given no obvious justification, I dropped it during > the cleanup. > > It turns out there is a good reason, on all but the most recent AMD CPUs. > > Reinstate the use of "blind" TZCNT/LZCNT when safe to do so. This happens to > be preferentially in loops where a repeated saving of 5-6 uops becomes far > more relevant than a one-off scenario. > > Leave an explanation of why. > > No functional change. > > Fixes: 989e5f08d33e ("x86/bitops: Improve arch_ffs() in the general case") > Fixes: 5ed26fc0768d ("xen/bitops: Implement ffsl() in common logic") > Fixes: 54b10ef6c810 ("xen/bitops: Implement fls()/flsl() in common logic") > Signed-off-by: Andrew Cooper In principle Reviewed-by: Jan Beulich but ... > --- a/xen/arch/x86/include/asm/bitops.h > +++ b/xen/arch/x86/include/asm/bitops.h > @@ -399,9 +399,16 @@ static always_inline unsigned int arch_ffs(unsigned int x) > * > * and the optimiser really can work with the knowledge of x being > * non-zero without knowing it's exact value, in which case we don't > - * need to compensate for BSF's corner cases. Otherwise... > + * need to compensate for BSF's corner cases. > + * > + * That said, we intentionally use TZCNT on capable hardware when the > + * behaviour for the 0 case doesn't matter. On AMD CPUs prior to > + * Zen4, TZCNT is 1-2 uops while BSF is 6-8 with a latency to match. > + * Intel CPUs don't suffer this discrepancy. > + * > + * Otherwise... > */ > - asm ( "bsf %[val], %[res]" > + asm ( "rep bsf %[val], %[res]" ... why would we use REP (again) when gas 2.25 supports LZCNT/TZCNT? Jan > : [res] "=r" (r) > : [val] "rm" (x) ); > } > @@ -428,7 +435,7 @@ static always_inline unsigned int arch_ffsl(unsigned long x) > > /* See arch_ffs() for safety discussions. */ > if ( __builtin_constant_p(x > 0) && x > 0 ) > - asm ( "bsf %[val], %q[res]" > + asm ( "rep bsf %[val], %q[res]" > : [res] "=r" (r) > : [val] "rm" (x) ); > else > @@ -446,7 +453,7 @@ static always_inline unsigned int arch_fls(unsigned int x) > > /* See arch_ffs() for safety discussions. */ > if ( __builtin_constant_p(x > 0) && x > 0 ) > - asm ( "bsr %[val], %[res]" > + asm ( "rep bsr %[val], %[res]" > : [res] "=r" (r) > : [val] "rm" (x) ); > else > @@ -464,7 +471,7 @@ static always_inline unsigned int arch_flsl(unsigned long x) > > /* See arch_ffs() for safety discussions. */ > if ( __builtin_constant_p(x > 0) && x > 0 ) > - asm ( "bsr %[val], %q[res]" > + asm ( "rep bsr %[val], %q[res]" > : [res] "=r" (r) > : [val] "rm" (x) ); > else > > base-commit: d965e2ee07c56c341d8896852550914d87ea5374 > prerequisite-patch-id: 8da89000c73c38aab6abfa6622217ea9eff07fbd > prerequisite-patch-id: 74830838bac94ed1e036a8173cf3210a314b35d8 > prerequisite-patch-id: 0654835c28df8d40b6c97006d041c4d31447a9a6 > prerequisite-patch-id: 2d47d646c6a6e0019918c57753d6c01a752c377f > prerequisite-patch-id: d8f8c4221a2d7039bae6f3d38e93fe90b2091d01 > prerequisite-patch-id: e0397c86b545a1d65f2e6b2049c282b926c40c64 > prerequisite-patch-id: ea21abe4540ee229f4f8725ce3f701d9ba4bd4a8 From xen-devel-bounces@lists.xenproject.org Mon Jun 02 09:38:59 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 09:38:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003080.1382518 (Exim 4.92) (envelope-from ) id 1uM1d2-0005Xa-2e; Mon, 02 Jun 2025 09:38:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003080.1382518; Mon, 02 Jun 2025 09:38: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 1uM1d1-0005XT-VF; Mon, 02 Jun 2025 09:38:47 +0000 Received: by outflank-mailman (input) for mailman id 1003080; Mon, 02 Jun 2025 09:38: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 1uM1d0-0005XN-CZ for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 09:38: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 6031f900-3f95-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 11:38:44 +0200 (CEST) Received: by mail-lf1-x129.google.com with SMTP id 2adb3069b0e04-54e7967cf67so4996316e87.0 for ; Mon, 02 Jun 2025 02:38:44 -0700 (PDT) Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-55337910e17sm1522600e87.153.2025.06.02.02.38.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 02:38:43 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6031f900-3f95-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748857124; x=1749461924; 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=Dd3DXS8m7SUMS7UPQ201OWX9Ru8pmaMIQdvRgn70O4A=; b=PWir0UtmYmHE9/O5QnSNzzVvExdQYqezG0h1+xoOzlnNPE/tXyc54qFxs+7dsIaPMg j6fWLcK20XLcIgddUheb2WZwERIOk+ul3NuL/Rt3ig5u+11ix43uoFuAQHhS5nlFxAgj eqpeqhh8zOOkCSedGsFPxVSYiOxhC+sl9dQObKsKncWXiMqjWc1PMxhTb0eR/6fRlrub v6Si/WL7rm7bzJdEtIJwMyM+Z3hPwf0xstXWGhuNd5Qu8bjEGpAcHdw67YnE3G4XwWnr 7mSGCcdfO/0Lpp8MizgVDMgBDk6ftR5CShuiVn0OqK3WWDVjlTO4mayqBj9IpxyWE24p H9kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748857124; x=1749461924; 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=Dd3DXS8m7SUMS7UPQ201OWX9Ru8pmaMIQdvRgn70O4A=; b=NC5qhK75ydyFaKe1jYuqN7OLaqJXtYL41GRXeEh64t2wjn+m6uKtRlxOxUUS3s5xIq jYot8sXvVleQoDRuAZ4ZeEgxZP47oJKkoLfMxVduHVddv9iCKYp9Y0agKV6WAZ6aKU93 LYmIF0gNZ+mgVQRdrhcwfjUC0owaFKLqaLIE2ixHzMstoBprLIREq3IeSu722Gr3OaOz xvYXhPbTZ/y0TvsgKv0pn00xeI5BGnnDgu8wfxKbj8fcPhcl6YoTZPqBM002Qv51gOPo V20E65WPPOMW4s6ToskiaVjkeUkLtZx7mdyrAU4YuZsOeVEuCytejT1TENAp/XWsgcIw yQ1A== X-Gm-Message-State: AOJu0YxFAcA5nfoS7hZzDNZWoUfEt/NYiv/wDWEotXgksMezc1XDE8XK qJC2nxkksHq9HDQDySaHZgG+f86nNSVBAFqUcj1181Pr91HaoiGrJDz5ROT6hrEN X-Gm-Gg: ASbGncsVe6hIISwBMsjUOIRqXYDTqgL+qHKYJLgcvsZh2OTMRoyBuBU02O6affdJcZx fWlxx2k/G69ntjYcmNkh2Q6TMMJlUQbSn7DDyvCOgaOF/rPPjhQsVtWZoE4abl1gne9HxSDh4Se +n5jM5klFDIFK5f64M/4pWjqRhi2FgtLMbLBukYXjHVoGUKPo4j02/l725uYrIavG/Nx5O5GLMC gqI5K9eU5+fJ5FHfAWEElUu82gCoxtX3bXQX3W4CWFtkOMABSOjK3ROA1OSoXIdSOn3fg2qnye4 EYi7wsI2rod6z4KPpN7uutXERCs0lZA+fh1KqA/d8kolo+SsMZGeOTkoPX1B+j7byb+KbrigmSO tn9pbZkXLluFHuFk= X-Google-Smtp-Source: AGHT+IENU9Oaln+oysIjlwHkawxsEnesfWaJ3BobFnuO8c+123kh32pLPuiLP5+mj8xL20HpP3vCcQ== X-Received: by 2002:a05:6512:31d3:b0:553:35e6:393e with SMTP id 2adb3069b0e04-55342f92726mr1852606e87.34.1748857123527; Mon, 02 Jun 2025 02:38:43 -0700 (PDT) From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: Mykola Kvach , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v2] xen/arm64: head: document missing input registers for MMU functions Date: Mon, 2 Jun 2025 12:38:37 +0300 Message-ID: <9e9977e85fca5971e2a3cac9edfd62404cb5643f.1748856752.git.mykola_kvach@epam.com> X-Mailer: git-send-email 2.48.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Mykola Kvach Add missing input register descriptions to enable_secondary_cpu_mm and enable_boot_cpu_mm functions. This update improves code clarity and consistency in comments. No functional changes are introduced by this patch. Signed-off-by: Mykola Kvach Reviewed-by: Michal Orzel --- xen/arch/arm/arm64/mmu/head.S | 3 +++ 1 file changed, 3 insertions(+) diff --git a/xen/arch/arm/arm64/mmu/head.S b/xen/arch/arm/arm64/mmu/head.S index 634156f83d..d14780ad19 100644 --- a/xen/arch/arm/arm64/mmu/head.S +++ b/xen/arch/arm/arm64/mmu/head.S @@ -313,6 +313,7 @@ END(enable_mmu) * * Inputs: * lr : Virtual address to return to. + * x20: phys offset * * Clobbers x0 - x6 */ @@ -337,6 +338,8 @@ END(enable_secondary_cpu_mm) * * Inputs: * lr : Virtual address to return to. + * x19: paddr(start) + * x20: phys offset * * Clobbers x0 - x6 */ -- 2.48.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 02 09:46:53 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 09:46:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003092.1382548 (Exim 4.92) (envelope-from ) id 1uM1kn-0007wH-3i; Mon, 02 Jun 2025 09:46:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003092.1382548; Mon, 02 Jun 2025 09:46: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 1uM1kn-0007wA-0P; Mon, 02 Jun 2025 09:46:49 +0000 Received: by outflank-mailman (input) for mailman id 1003092; Mon, 02 Jun 2025 09:46: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 1uM1km-0007w4-9r for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 09:46:48 +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 7fbf9635-3f96-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 11:46:47 +0200 (CEST) Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-3a36e0d22c1so2377993f8f.2 for ; Mon, 02 Jun 2025 02:46:47 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-23506cd3563sm66885735ad.158.2025.06.02.02.46.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 02:46:45 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7fbf9635-3f96-11f0-a300-13f23c93f187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1748857606; x=1749462406; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=6RjksbLPTo8f+oxer9pDxbI9XQzHTDeaZ6gGyOCdedY=; b=GotDI3eKem9rSNPed7WEZJej0TmVWGhBNHFt68LWG+QeI8KqibC/NqeRABZqsp6f9E knfq22nFQ1UStnBfBuweMB44269Abi9q8DpAhYrUdcK5jL3rd1w/JWKDKRoVZZrdrhvS kvLjRoIf1mqEN4OtK5EOHsQ8U1/yB3U9Zcsip/8nZSNV5IpR4Era2jOnh0L2+p99l+iK UOy5TI3aXgI/0J1otg4yyXaQWqyRqgKcRdFmxrAZlsXsBKZ7YCifFS08VEK5q5yZvMMR la5ZAoxnAOaDHHkO34XoQm61L+9bG8ymrKvQwKgY1s5C1g2faCWfNR5mjv1yI3qMpsEo 21ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748857606; x=1749462406; 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=6RjksbLPTo8f+oxer9pDxbI9XQzHTDeaZ6gGyOCdedY=; b=Es5zaMrT+k5HV3KgpZ/Sp//M3Z4bjiIQ/EgjIdgakvt88YkIWJ8hRg1jB90w9YacHj h7aZ6x7lV6F9zhKoMaj1kiynP4cV7XXiIsmJEh5uzGSmm9pw0w2yBkrw31JuQBgI9tQp Sg/cdFpRq8FWxgPzwCvRzcYN0vN5gfuWvW+MbcnZT9yWbrk8eOmUY2rLQESBq68cSM56 M30kP3RgNreQPCUI37p+v+IZJHWHkuvbRi/i/+slrhgRDETSidPA/pCfiD2kEUbnjkP2 fULEW/74FotfE7iQGl5Pot9OigSTMZwCLRr69QjBMOaWq4rup0IRdsVeXtMQNBFZ6WSY c5ow== X-Forwarded-Encrypted: i=1; AJvYcCXi9tvhhin+49nV1h3s5Gmoakm+Me6HmXtlzdFKHLBRGKqCFJC8zkK0rC6sDtr4o845EAi1q9/fsqA=@lists.xenproject.org X-Gm-Message-State: AOJu0YwPLyt2bFc06JxvKyytSuBTBCmNdGXKc5pDnpaxcI6SDOrWPNQx YNqAQ0NChWVmGCLlevB6XCjQ8Xf0cuOPD3UbS2JyQOF1hN8tE9aMuQvbxNap4szy+WDijqd8P2n AxwQ= X-Gm-Gg: ASbGnct7ty7BAvjFKErQKZ0n6PiRPyEoDikGtZEfsX3gmRkRMsx0EIxdNCj04vki2YC vqnwm9SuLRVinGS14vXWfyTer3rrmGbZdhgoKo4dRBYBzhua3OQfbDZw068Haux2gpt+d0q/PPb 6tLlPi3M170fkaTAm3lLTlIIIQeGhExYwcI20QxnGca570kF6Re/iAATeAhfUyEqYHNmtlaIar+ xO5MGfP68sYzjMBLgDJYebbBqktumbaW3xeDVfUIwvNxSLp0AhT7mpTsNDi4CTCRolC6QqjMOP2 Rfx9XGJvpSTb9BzKzJDAMeb0Qnw3r8x57fDt5WjBc75s3xZeIYqit2oWry6WIsmknkdj2Q1JAuV h9a3+ur7OnoJ299cqXiE3iUZunk85felpjdbQ X-Google-Smtp-Source: AGHT+IGAjNViutzTuoJON9wvQDBcxid9RrXa3/0MsHh9PVWh1RXkDT2e1/vjRCWeS9X8bRyJFBhm2w== X-Received: by 2002:a05:6000:2907:b0:3a4:f6b7:8b07 with SMTP id ffacd0b85a97d-3a4f89dd0e0mr9505658f8f.48.1748857606438; Mon, 02 Jun 2025 02:46:46 -0700 (PDT) Message-ID: <58c0499c-cdde-4cc3-9441-606a0eea4652@suse.com> Date: Mon, 2 Jun 2025 11:46:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/hvmloader: don't set xenpci MMIO BAR as UC in MTRR To: Roger Pau Monne Cc: Andrew Cooper , Anthony PERARD , Anthoine Bourgeois , xen-devel@lists.xenproject.org References: <20250530092314.27306-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: <20250530092314.27306-1-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 30.05.2025 11:23, Roger Pau Monne wrote: > The Xen PCI device (vendor ID 0x5853) exposed to x86 HVM guests doesn't > have the functionality of a traditional PCI device. The exposed MIO BAR is > used by some guests (including Linux) as a safe place to map foreign > memory, including the grant table itself. > > Traditionally BARs from devices have the uncacheable (UC) cache attribute > from the MTRR, to ensure correct functionality of such devices. hvmloader > mimics this behaviour and sets the MTRR attributes of both the low and high > PCI MMIO windows (where BARs of PCI devices reside) as UC in MTRR. > > This however causes performance issues for the users of the Xen PCI device > BAR, as for the purposes of mapping remote memory there's no need to use > the UC attribute. On Intel systems this is worked around by using iPAT, > that allows the hypervisor to force the effective cache attribute of a p2m > entry regardless of the guest PAT value. AMD however doesn't have an > equivalent of iPAT, and guest PAT values are always considered. > > Linux commit: > > 41925b105e34 xen: replace xen_remap() with memremap() > > Attempted to mitigate this by forcing mappings of the grant-table to use > the write-back (WB) cache attribute. However Linux memremap() takes MTRRs > into account to calculate which PAT type to use, and seeing the MTRR cache > attribute for the region being UC the PAT also ends up as UC, regardless of > the caller having requested WB. > > As a workaround to allow current Linux to map the grant-table as WB using > memremap() special case the Xen PCI device BAR in hvmloader and don't set > its cache attribute as UC. Can we (fully compatibly) make such a change? IOW do we know all possible guests would be at least unaffected (ideally affected positively)? Imo ... > Such workaround in hvmloader should also be > paired with a fix for Linux so it attempts to change the MTRR of the Xen > PCI device BAR to WB by itself. > > Overall, the long term solution would be to provide the guest with a safe > range in the guest physical address space where mappings to foreign pages > can be created. ... this is the only viable path. > Some vif throughput performance figures provided by Anthoine from a 8 > vCPUs, 4GB of RAM HVM guest(s) running on AMD hardware: > > Without this patch: > vm -> dom0: 1.1Gb/s > vm -> vm: 5.0Gb/s > > With the patch: > vm -> dom0: 4.5Gb/s > vm -> vm: 7.0Gb/s > > Reported-by: Anthoine Bourgeois > Signed-off-by: Roger Pau Monné > --- > I don't think the ACPI tables builder consume the PCI window size > information, I'm not seeing any consumer of the acpi_info->pci_{min,len} > fields, yet I've keep them covering the xenpci device BAR, hence the > adjustment to hvmloader_acpi_build_tables() part of this patch. acpi_build_tables() copies the field, and the comment ahead of struct acpi_info clarifies where the uses are: It's the PLEN field, which does have a use in dsdt.asl. Aiui the change you make is therefore a necessary one. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 02 09:49:58 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 09:49:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003098.1382558 (Exim 4.92) (envelope-from ) id 1uM1no-0008Uk-HK; Mon, 02 Jun 2025 09:49:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003098.1382558; Mon, 02 Jun 2025 09:49: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 1uM1no-0008Ud-Dp; Mon, 02 Jun 2025 09:49:56 +0000 Received: by outflank-mailman (input) for mailman id 1003098; Mon, 02 Jun 2025 09:49: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 1uM1no-0008UR-0K for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 09:49:56 +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 efd7b18b-3f96-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 11:49:55 +0200 (CEST) Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-3a375888297so2452021f8f.1 for ; Mon, 02 Jun 2025 02:49:55 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3124e3221a4sm5235214a91.42.2025.06.02.02.49.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 02:49:54 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: efd7b18b-3f96-11f0-a300-13f23c93f187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1748857794; x=1749462594; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=6J7jrEHwDaD2opq0DC3D0SbKBfw8bYn4hQxM9MZ7fKI=; b=OBCAUoQkcIxvCCiA4UEV0bt0MXzCBUt7f/E7WYWEuDDiUYW3SXFD06wUrd/cqxxNXD UNYDo/8ScB4pIxEEnyCl62qUIAliCmG0/hZoKCaMMLRmtNMtsNrUaJZWwhC5afBtkoVx 2+65XkiK9I7XYuOLz89qpznH7NLgSjOLKdE5yeQe6i05PMbpj4Gb1Ayey25soPqC/s/e NgdwkyXBOiuO/43851Hnsq5ziW081+A81w9H+NWFnUzjrowHGk5xahTDJrGWQSngPrtv G8uC8rUSRKakWwebn2cUeJfC1otF+BXGCP6ojdYif4nh6GrjOXZ2e/vh68Hslx3fCn9G f/CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748857794; x=1749462594; 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=6J7jrEHwDaD2opq0DC3D0SbKBfw8bYn4hQxM9MZ7fKI=; b=g5BlQhyMmDbDuFpPjY4BXTK2KsXsdQYe7OrHpRqaT5DvaWNZZJzOLXXz8zVEJiKbeB bsSN7bn5GOosQtCKDHORzFtlMB5abnY695gyoFBsWvdI171N9tf6bsebj3F60iUonp73 bDEoQ2WjCicaYK86abJe9t0QMrJznY0UW25EE2yXjvLWgBG42HxEoYaANdEj2AUc5gUl UDlG8SbvO0m62i3d8m6Z4UIiqEv8Yx5sNVpXi0seDx5ioxA4KC0fst7F7Tl/EZ2F38bR R8mzqYeG6y4wvuSMuPE8+r9l1VIYdQ/dQ1k5PADMI8Ad21dJCkoxFVhOzBArSs/iqws5 PCig== X-Forwarded-Encrypted: i=1; AJvYcCV9OAwWnFJ+GV/kvHwkdpnfIcWkzTIhOhyLT9CNGVCsJLUOnIbNfPpXunhFDU3Y+cqvKPwnbaDNk3c=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz1+gdn6nTp8WA3attzr50y1BmX5Q/8wndJ5von2SOUk3Y9l4pX /d8lk2sBs3du/a8K1npsH0l7buNwKIrzLN+PURqZ+ceWkyUQWFCh2meCZTX2UpXU/A== X-Gm-Gg: ASbGncu6vnun5JA8+dgeSaDCOULN1Y661uQN9EilHwn/8K1PHTNyljKfmnjYN4k7BCW OUAS6mQdiFig2S1owBvxQVB4IwVTk764x+yEnYyD8Nc0K9A9zY9szWZi2a/HFz37frXhb2dLFtQ ixsTOWktHrQ3S3FU2UNsZFqLZziZ2T2cWExw2HYsiv/lEff/iWb4w9kVSzRJRbkjLZIXl6dV8Ga 1GMIo3L5VK3KFwq9dFmFllVfFkVwFzRRSgi94MioGQdi4SYj/IcSgfM3E8wi5tQQgQDfbTutPJU /SyB+30UjWMAhrYTwHQhCh7+c6eM8nSUmxSSlCf4Ot3R2eVtUN71vhOnrkE4o5PQl2nBgBpOadG e5NvjQ8JIWpihkHBGCVI6zSWBEeed6zi/5Hmp X-Google-Smtp-Source: AGHT+IF+lK5FcWHjtda8xZeMitGQLit2iTxTgpxZIEuoKqJpoeQNvJfENSXISVNW1FPrPDXIgd/bQA== X-Received: by 2002:a05:6000:2289:b0:3a4:cec5:b59c with SMTP id ffacd0b85a97d-3a4eedcd0a4mr15258280f8f.25.1748857794585; Mon, 02 Jun 2025 02:49:54 -0700 (PDT) Message-ID: <5e69c4cf-dc13-4ff0-ad2a-94807d751ef7@suse.com> Date: Mon, 2 Jun 2025 11:50:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/3] x86/alternatives: Factor out access to ideal_nops[] To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250522150015.555492-1-andrew.cooper3@citrix.com> <20250522150015.555492-2-andrew.cooper3@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20250522150015.555492-2-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 22.05.2025 17:00, Andrew Cooper wrote: > --- a/xen/arch/x86/alternative.c > +++ b/xen/arch/x86/alternative.c > @@ -86,6 +86,11 @@ static bool init_or_livepatch_read_mostly toolchain_nops_are_ideal; > # define toolchain_nops_are_ideal false > #endif > > +static const unsigned char *get_ideal_nops(unsigned int noplen) Right here this wants to be init_or_livepatch. I didn't go check whether subsequent patches add a truly non-init caller. If so - fine as is; otherwise with the attribute added: Acked-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 02 09:57:33 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 09:57:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003105.1382568 (Exim 4.92) (envelope-from ) id 1uM1v6-00029o-80; Mon, 02 Jun 2025 09:57:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003105.1382568; Mon, 02 Jun 2025 09:57: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 1uM1v6-00029h-4K; Mon, 02 Jun 2025 09:57:28 +0000 Received: by outflank-mailman (input) for mailman id 1003105; Mon, 02 Jun 2025 09:57: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 1uM1v5-00029G-Db for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 09:57:27 +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 fcb8795f-3f97-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 11:57:26 +0200 (CEST) Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-450cfb79177so21208775e9.0 for ; Mon, 02 Jun 2025 02:57:26 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3124e30c697sm5299968a91.36.2025.06.02.02.57.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 02:57:24 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fcb8795f-3f97-11f0-a300-13f23c93f187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1748858246; x=1749463046; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=TagJ5NmzFstYvgldSkZEvuo6UCP97Llml2SjE3QBkm0=; b=C7CDxJxueJIkNLl2XHvb/RlP7iMjbGGDHV2wCtp3Zqi2drkLpIhWYsB8jj1TdKGDCV 8GXKE2AYzY1+3C1FvEumaflcVeocC7C2gC5vrxPjbdvqfmcPIjEQHec4J5Nk6rO9ums9 qGs+yGpEvNRCrH2+EBgwLeKJBBf1BrZw7JnZYY+G2sDUvPFMhaxwBOS0nzeAFlJ79ogM Il/WTZTX0+vj3UU04V79eBnYa74ajwdUogaVsrYV5oTmReT/vTK42i2+OBRkHu8jMUPK dvsQ0iSR9SsK4ys3Mv09NKBRkfnXoNhDRePnPx6pjzdDPVKHHksBOIZke4jPADXeY1rk fw8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748858246; x=1749463046; 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=TagJ5NmzFstYvgldSkZEvuo6UCP97Llml2SjE3QBkm0=; b=Io8ILOb+KzBJJE/UTC2zTYTjIjNHOvZ0sxNrcc29pjLzuHjEEj6Y73jceBZvJlghgB AiqorDtHAM7zJCgXHKbuixHjSIMXG0uVEBJSIlgL4b4kqnwCzkt4L9XN7hntYiXauYKL Gsmwt3MWL6aNWANld/OrYLnzdlTp2UC9jcEWuO3wsYF2A3dLjX2U86/jK2lkhzPgxWgx H4RkJvCVoB8tuqbrIymmkYDg/QRxIFLy1jt23LhoyV1HSawADIckjNbMCzcMfF8NW1l8 /UvEK2hVbKC6hcw4Wt1hkulZJs4AYr1Al1vk4cr+LxQ/KPqMOZ5gIu3yBDMQZ+nNaMt0 iMiA== X-Forwarded-Encrypted: i=1; AJvYcCX7oR3WlHEJSfM5SypV71VSlrKQjCRDZadeGqDse7CNA70qvPdUDJd9Cpm9TuPaSoHUrxO07lmLtGE=@lists.xenproject.org X-Gm-Message-State: AOJu0Yw1Qn1ZoJ0sBKU0jGOs6gxIyDPNBoDYgtT7SKdaOQou3T0vcozc TQpQBOPWtEyRdc+NXXdAyDni6kwW+7iKA25ChlBF5132mVRxF+KGRf8KMzgkmODjOw== X-Gm-Gg: ASbGncsC04GVq/7ddiDC8OZ/PNXLn+MOsfwrRf50x6TBlFtu8x0vGIgHQS/RB6LxP2G 5wir1W993pYaUlbXy5S1Gpcby9QT3T/zEei7UkDyyt8wquljEBa1rEJ5/3fPFjXzg01cJptbg40 Igzp6pty7gkLiHeVqxzkDt9z59ulFtGFKmj3StwXOzGXkuSgZ7UlXyP3Ur7frMfvrzJj2EfpCT+ sfjp9vJJhzikOJvKL4pD7Ll3+gt76S0ky7A9Xy8gOuk0614Qak5fflGdp7YzXFMdDXljT0FrkEF rk3CU5m62m1kFdX7/J3RSSRIwOaXnm3fVsC4qnHORjGlvIG8V4/YvGPZKbTtRnX5dFyBztog6kX hP+PTZbvo0gqftpfOA3X7PKfftc8Wy2dBOHt/pICdJFLoH0g= X-Google-Smtp-Source: AGHT+IEGVugMmWOPJ8+NtAUxdKxYxH9fzczCH7ftA7my9C5nS+L9TdK1jfoHxFjn3NvMvLYMVc81Aw== X-Received: by 2002:a05:6000:2510:b0:3a4:fc75:d017 with SMTP id ffacd0b85a97d-3a4fc75de24mr6418448f8f.26.1748858245604; Mon, 02 Jun 2025 02:57:25 -0700 (PDT) Message-ID: <99a39800-dbba-4d37-afcb-ae041af648f4@suse.com> Date: Mon, 2 Jun 2025 11:57:32 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/3] x86/alternatives: Rework get_ideal_nops() To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250522150015.555492-1-andrew.cooper3@citrix.com> <20250522150015.555492-3-andrew.cooper3@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20250522150015.555492-3-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 22.05.2025 17:00, Andrew Cooper wrote: > The {k8,p6}_nops[] arrays are both 80-byte structures indexing 45-byte > structures. Furthermore, perhaps unusually for C, the source layout is an > obvious hint about the trangular nature of the structure. > > Therefore, we can replace the pointer chase with some simple arithmatic. > > No functional change. > > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Roger Pau Monné > > The implemenation of get_ideal_nops() changes from: > > mov 0x19bc41(%rip),%rax # > mov %edi,%edi > mov (%rax,%rdi,8),%rax > jmp <__x86_return_thunk> > > to: > > lea -0x1(%rdi),%eax > imul %edi,%eax > shr %eax > add 0x67fc1(%rip),%rax # > jmp <__x86_return_thunk> > > The imul has a latency of 3 cycles on all CPUs back to the K8 and Nehalem. > It's better than an extra deference on all CPUs, even the older ones. While this is all good, what we're losing is ... > --- a/xen/arch/x86/alternative.c > +++ b/xen/arch/x86/alternative.c > @@ -20,7 +20,7 @@ > #define MAX_PATCH_LEN (255-1) > > #ifdef K8_NOP1 > -static const unsigned char k8nops[] init_or_livepatch_const = { > +static const unsigned char k8_nops[] init_or_livepatch_const = { > K8_NOP1, > K8_NOP2, > K8_NOP3, > @@ -31,22 +31,10 @@ static const unsigned char k8nops[] init_or_livepatch_const = { > K8_NOP8, > K8_NOP9, > }; > -static const unsigned char * const k8_nops[ASM_NOP_MAX+1] init_or_livepatch_constrel = { ... the (at least visual) connection to ASM_NOP_MAX. Could I talk you into adding build time array-size checks for both arrays, to restore the connection? > - NULL, > - k8nops, > - k8nops + 1, > - k8nops + 1 + 2, > - k8nops + 1 + 2 + 3, > - k8nops + 1 + 2 + 3 + 4, > - k8nops + 1 + 2 + 3 + 4 + 5, > - k8nops + 1 + 2 + 3 + 4 + 5 + 6, > - k8nops + 1 + 2 + 3 + 4 + 5 + 6 + 7, > - k8nops + 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8, > -}; > #endif > > #ifdef P6_NOP1 > -static const unsigned char p6nops[] init_or_livepatch_const = { > +static const unsigned char p6_nops[] init_or_livepatch_const = { > P6_NOP1, > P6_NOP2, > P6_NOP3, > @@ -57,21 +45,9 @@ static const unsigned char p6nops[] init_or_livepatch_const = { > P6_NOP8, > P6_NOP9, > }; > -static const unsigned char * const p6_nops[ASM_NOP_MAX+1] init_or_livepatch_constrel = { > - NULL, > - p6nops, > - p6nops + 1, > - p6nops + 1 + 2, > - p6nops + 1 + 2 + 3, > - p6nops + 1 + 2 + 3 + 4, > - p6nops + 1 + 2 + 3 + 4 + 5, > - p6nops + 1 + 2 + 3 + 4 + 5 + 6, > - p6nops + 1 + 2 + 3 + 4 + 5 + 6 + 7, > - p6nops + 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8, > -}; > #endif > > -static const unsigned char * const *ideal_nops init_or_livepatch_data = p6_nops; > +static const unsigned char *ideal_nops init_or_livepatch_data = p6_nops; > > #ifdef HAVE_AS_NOPS_DIRECTIVE > > @@ -86,9 +62,17 @@ static bool init_or_livepatch_read_mostly toolchain_nops_are_ideal; > # define toolchain_nops_are_ideal false > #endif > > +/* > + * Both k8_nops[] and p6_nops[] are flattened triangular data structures, > + * making the offsets easy to calculate. > + * > + * To get the start of NOP $N, we want to calculate T($N - 1) > + */ > static const unsigned char *get_ideal_nops(unsigned int noplen) > { > - return ideal_nops[noplen]; > + unsigned int offset = ((noplen - 1) * noplen) / 2; > + > + return &ideal_nops[offset]; > } > > static void __init arch_init_ideal_nops(void) From xen-devel-bounces@lists.xenproject.org Mon Jun 02 09:59:09 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 09:59:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003116.1382578 (Exim 4.92) (envelope-from ) id 1uM1wi-0002jK-KL; Mon, 02 Jun 2025 09:59:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003116.1382578; Mon, 02 Jun 2025 09:59:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uM1wi-0002jD-HK; Mon, 02 Jun 2025 09:59:08 +0000 Received: by outflank-mailman (input) for mailman id 1003116; Mon, 02 Jun 2025 09:59: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 1uM1wh-0002j5-5q for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 09:59:07 +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 3867ecf4-3f98-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 11:59:06 +0200 (CEST) Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-3a5058d46ceso594209f8f.0 for ; Mon, 02 Jun 2025 02:59:06 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-23506cf53a9sm67146545ad.196.2025.06.02.02.59.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 02:59:05 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3867ecf4-3f98-11f0-a300-13f23c93f187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1748858346; x=1749463146; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=59uJKcR3b8YdfDVosBS568wBuugaBMdtBQd/BTjVOAk=; b=TGv6nnjDHGeQ1HvCWqiyv14KIze0ar9p/QdK8l5FYPfRgLpk0GLioAd6d0fh4WPmVe aEkWAg5HTtLPGEeUFwjMkNgM3ySh3DqnFK85jhJMrVyJoxIs87wsf0kbisT1dIag2lwZ qmjOiXB0I9s2G3t5I/1uxC4mtq+8ULgCwXt0vSHFI0kgyjSz25HMm8TzCmGYM211bZSy z516RNhawjPN4dSI4lGXXh+RhBT54VzP6GavoKYNUuFJUVAJyJr9aOrWu29r2QroAh6d f7dTvIR/R42P2uGHrKLZo3msrzmjDy6F1D7UHEfOKT38YNhbQk563YcZsO4aUvOKGD1+ Y4rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748858346; x=1749463146; 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=59uJKcR3b8YdfDVosBS568wBuugaBMdtBQd/BTjVOAk=; b=CZVMsxolNpk3XZJ7owF0G9KJSwPkpkXYk5MSu8cgbdp/Y5MybNo5icpKjQeowqXlwr CdIG7v/APb82wsibL+Vb/HinLxSKIbJTk2WFKsudFpPXLdegW+YkQ8e/sWjAhcf7xdHQ YTL1jwbP5G47yWlqUjhrpwF4VUxkQGYdMCsgP5MurwYI+KazP9YZM9a2oEgEcxb+L20c F85N4KVo9+O8a1CMWtxze4MX0UbuxaXCdZAfoZ5r3Y+bz6yaimf9x16ylY3udB8e8+8Q o5IaxvmWlPtVWnxo2uDOzt7tQxbkDibF69ucfu+wqHE0DJMiANacwjuCui6Xz21lBBY9 nT9A== X-Forwarded-Encrypted: i=1; AJvYcCUpattCBm1utOKJEaOT5Z51J+UXXxTNFjOe5cWl/MdOdgCukOu4+mE95TTNoP7jl/mF60dgfBB3exQ=@lists.xenproject.org X-Gm-Message-State: AOJu0YzGYVBuqPuHZSNImBn4JbgcgOJm5lU5TlvCCRJ6ho6CDlr4cMqa GTSXHHvhDJNs6vKlSzGZVg9VJarsT8s809+Zo5Xo8Wlf83NKPvs+Ng98N+6Mx/BISA== X-Gm-Gg: ASbGncscvEcqMiU7FmNRL3t1TPKElqLu2nzqqppmIauD1bQpOOhUlgnLhUu0Cuh35qB phWMIr4lHzYpLm3UHTG/luBGakqCVNgO82WgXaHVK0EVwnlEde+szuZgYWdUwv+8IcApMUyM+V2 aTc05fqE3f/W3B8HRujrXc/SzA3Y6YIEYmJBD46Xxu+4tKjN2zPN4n+USXzHptcQLiw+qZm37+R kGB6wEjAx+RRy844MW1yCO/mZHLM1krtBd4EZGHq2nEB1/o/mRaAfsN92W05CZByjdmyq9zaKDr JNz8xdMSg97RvXhxIT1tz3PN0FWh73xR6S3uGdXVrgA7D/sapf9JZ7ushWRK6fk+jXJ2q0wvPNH urz9ekaOhGdd0TBPuFhlgemrzy5ZsCA3ZpxqW X-Google-Smtp-Source: AGHT+IGnsgeMxARjYDP3AiU3CSfmJcV6qrz0VEBbaJTeeZnby3QUM00rbz9Ut6pi2208XKxc9baqCg== X-Received: by 2002:a05:6000:178e:b0:3a1:f564:cd9d with SMTP id ffacd0b85a97d-3a4f89dee77mr9360115f8f.36.1748858345765; Mon, 02 Jun 2025 02:59:05 -0700 (PDT) Message-ID: <0eb77cb2-0208-4fba-8663-6015dee3e015@suse.com> Date: Mon, 2 Jun 2025 11:59:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/3] x86/alternatives: Introduce init_or_livepatch_ro_after_init To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250522150015.555492-1-andrew.cooper3@citrix.com> <20250522150015.555492-4-andrew.cooper3@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20250522150015.555492-4-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 22.05.2025 17:00, Andrew Cooper wrote: > ... and use it for ideal_nops and toolchain_nops_are_ideal; both of which are > invariant after arch_init_ideal_nops() has run. > > No functional change. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich preferably with ... > --- a/xen/arch/x86/alternative.c > +++ b/xen/arch/x86/alternative.c > @@ -47,7 +47,7 @@ static const unsigned char p6_nops[] init_or_livepatch_const = { > }; > #endif > > -static const unsigned char *ideal_nops init_or_livepatch_data = p6_nops; > +static const unsigned char *ideal_nops init_or_livepatch_ro_after_init = p6_nops; ... the attribute moved to between type and identifier, as we generally have it elsewhere. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 02 10:21:56 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 10:21:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003132.1382588 (Exim 4.92) (envelope-from ) id 1uM2Ia-0007fZ-By; Mon, 02 Jun 2025 10:21:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003132.1382588; Mon, 02 Jun 2025 10:21:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uM2Ia-0007fS-8t; Mon, 02 Jun 2025 10:21:44 +0000 Received: by outflank-mailman (input) for mailman id 1003132; Mon, 02 Jun 2025 10:21: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 1uM2IY-0007fM-FG for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 10:21:42 +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 5a8ee439-3f9b-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 12:21:32 +0200 (CEST) Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-3a50fc7ac4dso208194f8f.0 for ; Mon, 02 Jun 2025 03:21:32 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-747affadf7bsm7536163b3a.108.2025.06.02.03.21.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 03:21:31 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5a8ee439-3f9b-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1748859691; x=1749464491; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=8qllOqqaeVhoUab7xw9pn8RJARRqQTvpElQ/c2lFnUI=; b=Sz6c25yPmQ3xrf1WKNeWG8ud+MzR3IlY6ALjCP+stEIlsoFR2FYobjzOU8ZyyQxEDa BcElZesHquw08astGbk0CqKjlRRgl1zrHwyZENjwQ4iTHlunGb7cc8fC35DetwyRcIVk rRWJsiDbTuu0a7uqEK8WeP98sLsm/+DM6Tmj7my3zbENlSGNN8CLfWujIKbt9LQDmoRV opHHFsUoMoSPPeplKZ8qh6znKDLJvj/pdCppDoVUM1D73JLFgs+RGxDq9xg0oMM2wbjm KnR2C/d0nVCfJ6xO1pZvMZYOxZbMcAfdOsmX+GgxXdSf/etX6jgGHiRKPz2OczudtYif JA7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748859691; x=1749464491; 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=8qllOqqaeVhoUab7xw9pn8RJARRqQTvpElQ/c2lFnUI=; b=mRy2NXREzNh+WCbEYaW9jBSSxB6aCDnPjCieLAmc3QvWbBoXPtlr6pDoJ+zMyKoe4G NjeE0lRuZFIHUTAxo6bpKA2vEEi2SjduCZIaw/I0EmS90jgTHjnzpPsSeIhx+e+rPVCh BAeN8t6LHsJLQU2bp7Rgt4lteTceMjlE5fHYcLGzSEs61wLsPTGDloO/LgJCO8rv62Tk BVuTgJDyRUBQExNVdYVp0BmthhwFn/t3acx9MIY5m/yHHor5VlOHPDF77INmk8w0Qt8s ZyCxehoNrM533L0PFU4hV61KJnpcbJ6E/+6q52zUBPDEmIYUZvA0SSgYb067R/386oSh X/qg== X-Forwarded-Encrypted: i=1; AJvYcCU6Gu5LWn2Wu+8CcuLP6Ybdf6xSkCVpKCctE3FG5WSYG6NdCbSj39OeclPRoTAcvUibTeh+QlM1lf4=@lists.xenproject.org X-Gm-Message-State: AOJu0YyGQXkgj7VpKli8H62f6azSxxvlw0ogfYfOCvws3cNEBJTZaBOL gMNCQV6hkmOmYz6WBRibT/6CVBsKKIvHsq9fPSv0ty1GCxKXpjiYB5hqwoB4Mng2Gw== X-Gm-Gg: ASbGnctGayZvi6wdQFa6AIo6DQbpi9dwBuP4pC0lBy/gYNrhqdu0VZxa0o6NklOKFAQ y72exzY/xF5vUheyvaJ0YCsgHu/KI6pqYRqVzfqmnAflxB7tsjs9HnrAIOuWO/xtOuyoWYVkffi 4h8hrk5Ny7TZA+vV886bCz4NDpbxf/4KU1OkH51CCQZ3P8KakQWyLgX3pROttrBmgZwFIYoBsEj NYYng5gE5j2Jh8YB93CJjkTt/tSXTaEeF6d2ColpeMyQjkDYLTO2WdrPYIKwTqiwMHcVA/6Jc2m NBQKYPfgEKqUspTF/6nS6Q55d3I7xP8YS1hafDs6/qOWcFHINujImWTtBiEIeKhST/wR4JhkNC5 6jx822i17v5VPOfkvxYRhMhB5ooZ1Uy0pI8rP X-Google-Smtp-Source: AGHT+IE1iJo0yZ38IM2z/ZK7O5XSdSEcvkAJW9rtUZ0bnNLgdrqcZDBLpsT2iH9Z+V6OE3VIB7986g== X-Received: by 2002:a05:6000:3109:b0:3a4:dcfb:3118 with SMTP id ffacd0b85a97d-3a4f7a3d5eemr10151434f8f.10.1748859691515; Mon, 02 Jun 2025 03:21:31 -0700 (PDT) Message-ID: <8cd6c3e0-0361-4f3f-b3ca-8ffa49b9197d@suse.com> Date: Mon, 2 Jun 2025 12:21:34 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 08/14] xen/riscv: imsic_init() implementation 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 , Romain Caritey , xen-devel@lists.xenproject.org References: <421dad1bbd014a2d7ff588af088eadbd56345dbe.1747843009.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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.05.2025 20:44, Oleksii Kurochko wrote: > On 5/22/25 4:46 PM, Jan Beulich wrote: >> On 21.05.2025 18:03, Oleksii Kurochko wrote: >>> + /* Allocate MMIO resource array */ >>> + imsic_cfg.mmios = xzalloc_array(struct imsic_mmios, nr_mmios); >> How large can this and ... >> >>> + if ( !imsic_cfg.mmios ) >>> + { >>> + rc = -ENOMEM; >>> + goto imsic_init_err; >>> + } >>> + >>> + imsic_cfg.msi = xzalloc_array(struct imsic_msi, nr_parent_irqs); >> ... this array grow (in principle)? > > Roughly speaking, this is the number of processors. The highests amount of processors > on the market I saw it was 32. But it was over a year ago when I last checked this. Unless there's an architectural limit, I don't think it's a good idea to take as reference what's available at present. But yes, ... >> I think you're aware that in principle >> new code is expected to use xvmalloc() and friends unless there are specific >> reasons speaking against that. > > Oh, missed 'v'... ... adding the missing 'v' will take care of my concern. Provided of course this isn't running to early for vmalloc() to be usable just yet. >>> + if ( !imsic_cfg.msi ) >>> + { >>> + rc = -ENOMEM; >>> + goto imsic_init_err; >>> + } >>> + >>> + /* Check MMIO register sets */ >>> + for ( unsigned int i = 0; i < nr_mmios; i++ ) >>> + { >>> + if ( !alloc_cpumask_var(&imsic_cfg.mmios[i].cpus) ) >>> + { >>> + rc = -ENOMEM; >>> + goto imsic_init_err; >>> + } >>> + >>> + rc = dt_device_get_address(node, i, &imsic_cfg.mmios[i].base_addr, >>> + &imsic_cfg.mmios[i].size); >>> + if ( rc ) >>> + { >>> + printk(XENLOG_ERR "%s: unable to parse MMIO regset %u\n", >>> + node->name, i); >>> + goto imsic_init_err; >>> + } >>> + >>> + base_addr = imsic_cfg.mmios[i].base_addr; >>> + base_addr &= ~(BIT(imsic_cfg.guest_index_bits + >>> + imsic_cfg.hart_index_bits + >>> + IMSIC_MMIO_PAGE_SHIFT, UL) - 1); >>> + base_addr &= ~((BIT(imsic_cfg.group_index_bits, UL) - 1) << >>> + imsic_cfg.group_index_shift); >>> + if ( base_addr != imsic_cfg.base_addr ) >>> + { >>> + rc = -EINVAL; >>> + printk(XENLOG_ERR "%s: address mismatch for regset %u\n", >>> + node->name, i); >>> + goto imsic_init_err; >>> + } >> Maybe just for my own understanding: There's no similar check for the >> sizes to match / be consistent wanted / needed? > > If you are speaking about imsic_cfg.mmios[i].size then it depends fully on h/w will > provide, IMO. > So I don't what is possible range for imsic_cfg.mmios[i].size. Well, all I can say is that's it feels odd that you sanity check base_addr but permit effectively any size. >>> @@ -18,6 +19,18 @@ static inline unsigned long cpuid_to_hartid(unsigned long cpuid) >>> return pcpu_info[cpuid].hart_id; >>> } >>> >>> +static inline unsigned long hartid_to_cpuid(unsigned long hartid) >>> +{ >>> + for ( unsigned int cpuid = 0; cpuid < ARRAY_SIZE(pcpu_info); cpuid++ ) >>> + { >>> + if ( hartid == cpuid_to_hartid(cpuid) ) >>> + return cpuid; >>> + } >>> + >>> + /* hartid isn't valid for some reason */ >>> + return NR_CPUS; >>> +} >> Considering the values being returned, why's the function's return type >> "unsigned long"? > > mhartid register has MXLEN length, so theoretically we could have from 0 to MXLEN-1 > Harts and so we could have the same amount of Xen's CPUIDs. and MXLEN is 32 for RV32 > and MXLEN is 64 for RV64. Yet the return value here is always constrained by NR_CPUS, isn't it? Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 02 10:22:54 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 10:22:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003138.1382599 (Exim 4.92) (envelope-from ) id 1uM2Ji-0008CF-L9; Mon, 02 Jun 2025 10:22:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003138.1382599; Mon, 02 Jun 2025 10: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 1uM2Ji-0008C8-H9; Mon, 02 Jun 2025 10:22:54 +0000 Received: by outflank-mailman (input) for mailman id 1003138; Mon, 02 Jun 2025 10:22: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 1uM2Ji-0008C0-2T for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 10:22: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 8a90cd45-3f9b-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 12:22:53 +0200 (CEST) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-4508287895dso29961195e9.1 for ; Mon, 02 Jun 2025 03:22:53 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-23506bd8e39sm67687625ad.58.2025.06.02.03.22.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 03:22:51 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8a90cd45-3f9b-11f0-a300-13f23c93f187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1748859772; x=1749464572; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=uQL4P1bUoJSru1C+GIX/VDusUlL+lX9SnKz25o0UXWw=; b=XxAj6Hr+aPGXtK65H79pzVSq5R1hB1aXT0/vLRHmXH3BqYvTajrYi15Nvos/hSsXlj UJrVe8VKl/kArleoSL6aYJ2eXDohkTdncJVy0iiGjPfS1bGtyuFPZeQrFWlcX9lI1T1Z Oy/9v3wuow3N2Smc4idYn7iWvdxhep51tYwZYtxTj9FgUWtakd5hHd1lPAsxHNja3erp DNnnGsHIIE/n3NJfr2u7O+vf0XAaY2Xn4Z+nMNil4phaaY4vx9t6NCIjRj4wkNabWEzk G8uPgGJbl1QaCwq1O2rEfauk7kDCDK6MT/NtZkN5lzqb4kcBC7JzhAFtX+H1v5GwGKdM 2Ptg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748859772; x=1749464572; 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=uQL4P1bUoJSru1C+GIX/VDusUlL+lX9SnKz25o0UXWw=; b=tMgVGGsFiLjha6/mXI/94DIZhSPiypwj9a4cRlOE1kXk8jxTeNXOhIoUY7LKXZc3oP h9LrXjt6pHRFwKha7GgXIBZaNGA4krHFuhd1N3UyBkSyRz/Xe6h4DogT8vk5oxcLLrFA WGNbPC7tkiIuTGjfQ3d6R3YkrZqGqV0GUnX9GMi4+D4PadjpdSyO1DjVEvzLEE9n1qVf 3lMnszSdetR1L21IBOUey3Asgt8WAmcoIciSMIhGgvHQ5XdFmD0yuAkJWYxGmmI4IxRq /Pzz3YnOHin5m0d6mf2mM9cyn6FUG4pn77iEDeo9mO6pvNOxzdpcV41aeYPioUoYBzX4 JEug== X-Forwarded-Encrypted: i=1; AJvYcCVpoqRlEjTXpOG0llLJWEvp7HhOc2SPDrUtEam4S9AyhwI0+VLaOehnXC+O5gahH7/qiEerOjDCSTs=@lists.xenproject.org X-Gm-Message-State: AOJu0YwQ+T20FqjjfLINJ3VzXwF7B6WFrOxg/OY27aA9LCqrzpuCZyB2 6kLDu7y3fdj7N58Pv2Fh8OD+ck4RsAvjdEfsH6NXabzS+rHHgSI83kerWTckY6WlPA== X-Gm-Gg: ASbGnctjlzvvJ1QHd5xAN423qYK5wMkb2/KP4d5aT2evglHx12LQUeV81FHNwm519PY TDqjwOtNE9JZln6EPziENTWWat/dMWa0IkqR+Q2v0kw12tfI3fiShrXPzm+0yLiqxyVKxF0CvTK cWSF9iC2a/VwsR5wFtXTCWLRk6ZckPxc1C9y7YC0LKHbFFUsAXrv2SZwfLVwmkJW71YZRiqZPRn viFBpaoSuDy49fTrr2n2lfgabFrYV3o5Fce5WOq99YHSt9DbuBRtUUIRTvgxHAEEJMA4bb0B3+r U044rUhS+vKLoNr7YBRY4f3Ek6tgd1WHjaO8SBhOjkFEB2uTI7EX6AgjL82RAsM8+xgOPTF4sP+ nibaxDpUNGF855vBvwJ8pInFJ/GIbshPXHnV5+Dq/iw9kgAA= X-Google-Smtp-Source: AGHT+IEbjXtZctthCHASUU1OZYTXEhFgwIS7nghbPqb0c36sMOlAZCFUpiSi7nmZyfjUujkqoM4iCg== X-Received: by 2002:a05:6000:26c2:b0:3a4:ce5c:5e8d with SMTP id ffacd0b85a97d-3a4eedb8adfmr14468096f8f.20.1748859772039; Mon, 02 Jun 2025 03:22:52 -0700 (PDT) Message-ID: <9ab65452-497c-47b5-af18-92a7b2a86d9e@suse.com> Date: Mon, 2 Jun 2025 12:22:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 08/14] xen/riscv: imsic_init() implementation 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 , Romain Caritey , xen-devel@lists.xenproject.org References: <421dad1bbd014a2d7ff588af088eadbd56345dbe.1747843009.git.oleksii.kurochko@gmail.com> <84c9f65a-b278-4be4-b053-5bfa410f9a97@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: <84c9f65a-b278-4be4-b053-5bfa410f9a97@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 27.05.2025 13:30, Oleksii Kurochko wrote: > > On 5/26/25 8:44 PM, Oleksii Kurochko wrote: >>>> + if ( !dt_property_read_u32(node, "riscv,guest-index-bits", >>>> + &imsic_cfg.guest_index_bits) ) >>>> + imsic_cfg.guest_index_bits = 0; >>>> + tmp = BITS_PER_LONG - IMSIC_MMIO_PAGE_SHIFT; >>>> + if ( tmp < imsic_cfg.guest_index_bits ) >>>> + { >>>> + printk(XENLOG_ERR "%s: guest index bits too big\n", >>>> + dt_node_name(node)); >>>> + rc = -ENOENT; >>>> + goto cleanup; >>>> + } >>>> + >>>> + /* Find number of HART index bits */ >>>> + if ( !dt_property_read_u32(node, "riscv,hart-index-bits", >>>> + &imsic_cfg.hart_index_bits) ) >>>> + { >>>> + /* Assume default value */ >>>> + imsic_cfg.hart_index_bits = fls(*nr_parent_irqs); >>>> + if ( BIT(imsic_cfg.hart_index_bits, UL) < *nr_parent_irqs ) >>>> + imsic_cfg.hart_index_bits++; >>> Since fls() returns a 1-based bit number, isn't it rather that in the >>> exact-power-of-2 case you'd need to subtract 1? >> Agree, in this case, -1 should be taken into account. > > Hmm, it seems like in case of fls() returns a 1-based bit number there > is not need for the check: > (2) if ( BIT(imsic_cfg.hart_index_bits, UL) < *nr_parent_irqs ) > > We could do imsic_cfg.hart_index_bits = fls(*nr_parent_irqs - 1) (1) without > checking *nr_parent_irqs is power-of-two or not, and then just leave the > check (2). > And with (1), the check (2) is only needed for the case *nr_parent_irqs=1, if > I amn't mistaken something. And if I'm not mistaken, then probably it make > sense to change (2) to if ( *nr_parent_irqs == 1 ) + some comment why this > case is so special. > > Does it make sense? Can't easily tell; I'd like to see the resulting code instead of the textual description. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 02 10:30:08 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 10:30:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003146.1382608 (Exim 4.92) (envelope-from ) id 1uM2Qe-000128-At; Mon, 02 Jun 2025 10:30:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003146.1382608; Mon, 02 Jun 2025 10:30: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 1uM2Qe-00011h-72; Mon, 02 Jun 2025 10:30:04 +0000 Received: by outflank-mailman (input) for mailman id 1003146; Mon, 02 Jun 2025 10: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 1uM2Qd-0000gS-0F for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 10:30:03 +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 88119ac6-3f9c-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 12:29:58 +0200 (CEST) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-450ce671a08so26204075e9.3 for ; Mon, 02 Jun 2025 03:29:58 -0700 (PDT) Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-450d7fb00ccsm117601985e9.17.2025.06.02.03.29.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 03:29:56 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 88119ac6-3f9c-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1748860197; x=1749464997; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=/8c2hU5Ue9eYT7KD2Rw85cVz8HZowY2V5aBlyfr3DLI=; b=kgjACyfaUwPkuc52t91ATOVxEZoxn4GtcPwS9U6EM17lAdOm7JeO80bdNF7WD/LMth AcUqi9FV2BK18zZ1yaQLksY0Eb0LjgJuNZfSKeEP69Xr3eqqICsekXBM5TwkaO635m5x Rn+aOJOcsN4ULix1Pa5HdyeftFZqEIt70PQmg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748860197; x=1749464997; 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=/8c2hU5Ue9eYT7KD2Rw85cVz8HZowY2V5aBlyfr3DLI=; b=OxLaeiwt9jRMLtOXFtUStIAnMX6z/O9aVXqcnRZHDvKYlfmzfM/vSehPHEna1hfHwH 18R9UU2/U8eKtsIJAee+M6htB3gIu7QTYB/OCX3wa/tA594q4E+97jW7raNWMx7dvDtZ MvBOCwFcF2w2HQASmtttX/xk8kpXgq9MsxJSmgZJaZjWbL7alrIAgidyX/96MxECuWcu KRBR85xIuKuSCfXfukRxcFlG0E4Gour122FPXipWHMXHZxa9arZ5PFOWvU+d37aC4l3o ZlVOLkqiK2lIOCo0xDtJwz9d3smQa6wLto32IMr/8fm58fHXGZUuXqlCTEZzAWwOC5ra XqzQ== X-Forwarded-Encrypted: i=1; AJvYcCVkGSPqOa+ucYbrfvD+1NdT4/x4y9EisHxXJPvYsfqKNxgIUk42tHMVdpvNerKTF5G0HcnCtSOYw7k=@lists.xenproject.org X-Gm-Message-State: AOJu0YzeFe6LFCyI4w6EmyotgcdSKai4mqA3B3rCJrFpwsYnWGHbAaQq Qa6+LkzskwBybSAh9GLcY6/WBY+D39Uf4aJrrKgBqWhRZxvQcDyhvtt0ENdS/Xgk06U= X-Gm-Gg: ASbGnctZMr6Vf49jgAbWiwJtHdASRXVMQmMJyExOTDM2a+QaWsCBeB34aj2R9ogu9Cb OQxljLl4DCMcV1eyDmPchlUjBpRT4vZCOHRGZHyCTwLRVzvfw1OLwHYzGTDZjVrOAoiSZvRYNgM bNsse4A4GfdX84wsq1uj+f+n8T8M39NFqVaofBI1/GQ9ECBTz3f9mQr6dqL1O1zKzIj1E55k+nc RuEpQeZXYd5yfcpTlSca1KRk4xFoluzLxmecr5dMvApeEJdW0IkKaWAbzJHcF32ZgTnN1hu9VWC GnJ2830L8LO0CmZ/2X2Mbkuth/rbvNj0xixJnRltvPrQIcGYbxtvwvCoYdcyAH/a/NLXT9YSc9Y VKB/1eIIItV1O8Ijg X-Google-Smtp-Source: AGHT+IH0QCKABEKIXAitKe2B9IsXkKrYBeIr/qvBp+oDnZbnWWNDiWx1+EWYP21X3ik8F9WSrvhVrA== X-Received: by 2002:a05:600c:314f:b0:450:d3b9:4ba4 with SMTP id 5b1f17b1804b1-451191fd426mr64754465e9.2.1748860197371; Mon, 02 Jun 2025 03:29:57 -0700 (PDT) Message-ID: Date: Mon, 2 Jun 2025 11:29:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/x86: Remove is_periodic_irq() prototype To: Jan Beulich , Jason Andryuk Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org, "consulting@bugseng.com" References: <20250527223753.47055-1-jason.andryuk@amd.com> <1c850e02-0d87-4fd1-8504-0aee53949136@citrix.com> <2c4f4c2a-b1d7-4cbb-834e-cee0fd3d2433@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: <2c4f4c2a-b1d7-4cbb-834e-cee0fd3d2433@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 02/06/2025 10:04 am, Jan Beulich wrote: > On 28.05.2025 00:39, Andrew Cooper wrote: >> On 27/05/2025 11:37 pm, Jason Andryuk wrote: >>> is_periodic_irq() was removed in the Fixes commit, but the prototype >>> remained. Drop it now. >>> >>> Fixes: ddc35d1cc994 ("[HVM] Enable more than one platform timer...") >>> Signed-off-by: Jason Andryuk >> Acked-by: Andrew Cooper >> >>> --- >>> The full Fixes line is: >>> Fixes: ddc35d1cc994 ("[HVM] Enable more than one platform timer (PIT/RTC/HPET) programmed as periodic timer and adds them to abstract layer, which keeps track of pending_intr_nr to avoid time interrupt lost and sync'ed timer with TSC.") >> Yeah, the older commit messages weren't as well structured as we insist >> on them being these days. >> >> How did you find this?  inspection, or a tool? > What I'm curious about: Why didn't Eclair spot this? I don't see how this case is distinguishable from the DCE case dropping calls to compiled-out functions, which is a deviation because of how Xen wants to work. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Jun 02 10:31:18 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 10:31:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003154.1382617 (Exim 4.92) (envelope-from ) id 1uM2Rp-0002Dw-MV; Mon, 02 Jun 2025 10:31:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003154.1382617; Mon, 02 Jun 2025 10: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 1uM2Rp-0002Do-Je; Mon, 02 Jun 2025 10:31:17 +0000 Received: by outflank-mailman (input) for mailman id 1003154; Mon, 02 Jun 2025 10:31: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 1uM2Ro-0002CR-7w for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 10:31:16 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-sth1.inumbo.com (Halon) with ESMTP id b557793c-3f9c-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 12:31:14 +0200 (CEST) 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 D6EAD12FC; Mon, 2 Jun 2025 03:30:56 -0700 (PDT) Received: from [10.57.95.206] (unknown [10.57.95.206]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7C8B93F673; Mon, 2 Jun 2025 03:31:07 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b557793c-3f9c-11f0-a300-13f23c93f187 Message-ID: <23bd2cdf-768f-4053-9839-a0613a25de51@arm.com> Date: Mon, 2 Jun 2025 11:31:05 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v1 0/6] Lazy mmu mode fixes and improvements Content-Language: en-GB To: Mike Rapoport Cc: Lorenzo Stoakes , Catalin Marinas , Will Deacon , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , "David S. Miller" , Andreas Larsson , Juergen Gross , Ajay Kaher , Alexey Makhalov , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Boris Ostrovsky , "Aneesh Kumar K.V" , Andrew Morton , Peter Zijlstra , Arnd Bergmann , David Hildenbrand , "Liam R. Howlett" , Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , Alexei Starovoitov , Andrey Ryabinin , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org, virtualization@lists.linux.dev, xen-devel@lists.xenproject.org, linux-mm@kvack.org, Jann Horn References: <20250530140446.2387131-1-ryan.roberts@arm.com> <5b5d6352-9018-4658-b8fe-6eadaad46881@lucifer.local> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 31/05/2025 08:46, Mike Rapoport wrote: > Hi Ryan, > > On Fri, May 30, 2025 at 04:55:36PM +0100, Ryan Roberts wrote: >> On 30/05/2025 15:47, Lorenzo Stoakes wrote: >>> +cc Jann who is a specialist in all things page table-y and especially scary >>> edge cases :) >>> >>> On Fri, May 30, 2025 at 03:04:38PM +0100, Ryan Roberts wrote: >>>> Hi All, >>>> >>>> I recently added support for lazy mmu mode on arm64. The series is now in >>>> Linus's tree so should be in v6.16-rc1. But during testing in linux-next we >>>> found some ugly corners (unexpected nesting). I was able to fix those issues by >>>> making the arm64 implementation more permissive (like the other arches). But >>>> this is quite fragile IMHO. So I'd rather fix the root cause and ensure that >>>> lazy mmu mode never nests, and more importantly, that code never makes pgtable >>>> modifications expecting them to be immediate, not knowing that it's actually in >>>> lazy mmu mode so the changes get deferred. >>> >>> When you say fragile, are you confident it _works_ but perhaps not quite as well >>> as you want? Or are you concerned this might be broken upstream in any way? >> >> I'm confident that it _works_ for arm64 as it is, upstream. But if Dev's series >> were to go in _without_ the lazy_mmu bracketting in some manner, then it would >> be broken if the config includes CONFIG_DEBUG_PAGEALLOC. >> >> There's a lot more explanation in the later patches as to how it can be broken, >> but for arm64, the situation is currently like this, because our implementation >> of __change_memory_common() uses apply_to_page_range() which implicitly starts >> an inner lazy_mmu_mode. We enter multiple times, but we exit one the first call >> to exit. Everything works correctly but it's not optimal because C is no longer >> deferred: >> >> arch_enter_lazy_mmu_mode() << outer lazy mmu region >> >> alloc_pages() >> debug_pagealloc_map_pages() >> __kernel_map_pages() >> __change_memory_common() >> arch_enter_lazy_mmu_mode() << inner lazy mmu region >> >> arch_leave_lazy_mmu_mode() << exit; complete A + B >> clear_page() >> << no longer in lazy mode >> arch_leave_lazy_mmu_mode() << nop >> >> An alternative implementation would not add the nested lazy mmu mode, so we end >> up with this: >> >> arch_enter_lazy_mmu_mode() << outer lazy mmu region >> >> alloc_pages() >> debug_pagealloc_map_pages() >> __kernel_map_pages() >> __change_memory_common() >> << deferred due to lazy mmu >> clear_page() << BANG! B has not be actioned >> >> arch_leave_lazy_mmu_mode() >> >> This is clearly a much worse outcome. It's not happening today but it could in >> future. That's why I'm claiming it's fragile. It's much better (IMHO) to >> disallow calling the page allocator when in lazy mmu mode. > > First, I think it should be handled completely inside arch/arm64. Page > allocation worked on lazy mmu mode on other architectures, no reason it > should be changed because of the way arm64 implements lazy mmu. > > Second, DEBUG_PAGEALLOC already implies that performance is bad, for it to > be useful the kernel should be mapped with base pages and there's map/unmap > for every page allocation so optimizing a few pte changes (C in your > example) won't matter much. > > If there's a potential correctness issue with Dev's patches, it should be > dealt with as a part of those patches with the necessary updates of how > lazy mmu is implemented on arm64 and used in pageattr.c. > > And it seems to me that adding something along the lines below to > __kernel_map_pages() would solve DEBUG_PAGEALLOC issue: > > void __kernel_map_pages(struct page *page, int numpages, int enable) > { > unsigned long flags; > bool lazy_mmu = false; > > if (!can_set_direct_map()) > return; > > flags = read_thread_flags(); > if (flags & BIT(TIF_LAZY_MMU)) > lazy_mmu = true; > > set_memory_valid((unsigned long)page_address(page), numpages, enable); > > if (lazy_mmu) > set_thread_flag(TIF_LAZY_MMU); > } Hi Mike, I've thought about this for a bit, and concluded that you are totally right. This is a much smaller, arm64-contained patch. Sorry for the noise here, and thanks for the suggestion. Thanks, Ryan > >> Thanks, >> Ryan > From xen-devel-bounces@lists.xenproject.org Mon Jun 02 11:04:06 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 11:04:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003186.1382676 (Exim 4.92) (envelope-from ) id 1uM2xU-0007Gr-J8; Mon, 02 Jun 2025 11:04:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003186.1382676; Mon, 02 Jun 2025 11:04: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 1uM2xU-0007Gk-GK; Mon, 02 Jun 2025 11:04:00 +0000 Received: by outflank-mailman (input) for mailman id 1003186; Mon, 02 Jun 2025 11:03: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 1uM2xT-0007Ge-Hc for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 11:03:59 +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 47a45dca-3fa1-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 13:03:57 +0200 (CEST) Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-3a367ec7840so2864822f8f.2 for ; Mon, 02 Jun 2025 04:03:57 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-23506bca137sm68383265ad.10.2025.06.02.04.03.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 04:03:56 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 47a45dca-3fa1-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1748862237; x=1749467037; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=HDubWYuEbvHQGmWWRtEXtgiOSnw2p0RAjEzB0Z6Oe+s=; b=QYBoyXPa3v2te2H6VNkly9UIu9MjHmEZDL/uLK7U2XX9cCdEODtWearxiydRmGhQfx 4pigMfDcp0A4hsnsFGMtBE6d1B2rCYqB4o40Cte5bYEVk7cOmrEg18Iepo9IEOKKAZjm umhzV9MYUG1CeMkF2BE1JblAv5LJYEX8NJwYaF9eV9DNlbtmG4afCjFyZL8drSAkoopI ZEFcfJ2ZoDUM72Ukgm/CSkQJW/4DJT1KRY2bc9sIO9d+WecinNGJIraJGLuCuUlj0Gnw BmzGy6L/ULvrB57Wl88Dg5EhmQteeWOlqp1an7YOxcwklO3xqUxBHqTuUZv2u/MgB1M/ gGTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748862237; x=1749467037; 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=HDubWYuEbvHQGmWWRtEXtgiOSnw2p0RAjEzB0Z6Oe+s=; b=Omwbd+fO+tpZ+wq/VxtjM8ZpexFJEWuDyVqeUD9bzsT3lzSoScaIJSaldg33+u6PD9 mYvkzlXlk/z3eYazmglLOc+TLCsdPh7YFxCoMt0A27EgLJpxMaOpAuvHh0VIi+76LsNe c/kRSJtRN4tseaKW/L7auaR+fAoSH24v2bk2vAieMSkjd6diDMcDN2RQv9W+ALEmMAP6 oNGGwh4DALvZozsCAEHiOJXrZ3n3WqU5ENOU71A0XUeSHawGYzAba+Ti7HmNP/NkDncm WYIdjaJcud4n2KynsceXbqB2ExJRYH9v8+WHRi+L6u0Oul3BDNXjTIKJn7WPKgBm4+YI +zoQ== X-Forwarded-Encrypted: i=1; AJvYcCUgE68KFU3elUlm06wLg4yyCDZ6zJANEDR61OFhn+7q0NjXDo0uEywLKLlGqQwhV7tRJFxwwjPQ1DA=@lists.xenproject.org X-Gm-Message-State: AOJu0YxcxtPq4jI4LFFabxQjk52teNj03cPZua2zZVoiUXcmvNisZMmA sldlfd5w/rJXfTFpJb4vMB8SAnTpBuaKm8/yuNvF8B2IEDGc9eADsj1UJI4tY5Lcqw== X-Gm-Gg: ASbGncuSVkvY8WsQd0KGxcuxwZf6U1br3e+Y52RaZy4L6vUdWgMrVAds5nZZIczA0zU HBq/CrsBPCXWRdn8zFuVHYShZREcE3fISpg3RJdoMP/iUGw2c6XEZzJETIA0h+K/diuuH45lzod wdQqi2MxhZgezy0YQLhwgYWhNa/es+JYfLp5xOEVcIli/2U4hlVkeZWfmiqRC+wr1+S1C1m9W3c qgR89g3xla4IssNCAyQ/GQsGO5BOp6RWrsNHkO3sAz7JQ8SyJEN5WmtmifdTopcEHTUy+Q9Xmoc QFvFyL/2OCGdOOzoLRSbQ1kbwpxpHttllKzqpYZFQVLY6d8yaWEL/czvV6+AfiYrLcdEs+J3nIt ZWhMNMq4CUXmZjXF0b39/kwUoQl+nLS8wWQNp X-Google-Smtp-Source: AGHT+IHySj4/9gbl3tz1V30XW8H3qyLttno/0cmcwn26JHWmui6AzsEBIlr5QJv/RpuivyzivOrtrQ== X-Received: by 2002:a05:6000:1a8a:b0:3a4:dfc2:b9e1 with SMTP id ffacd0b85a97d-3a4f89a7e71mr9734639f8f.2.1748862236622; Mon, 02 Jun 2025 04:03:56 -0700 (PDT) Message-ID: <0175c281-b669-4412-971a-545e29077b34@suse.com> Date: Mon, 2 Jun 2025 13:04:00 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 2/6] xen/riscv: introduce things necessary for p2m initialization 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: <0a03d1f38649cfd8656147f209652dff0f9d170c.1746805907.git.oleksii.kurochko@gmail.com> <7ef3ca26-05f5-4e86-b7c7-852b6c74a3d0@suse.com> <1a0d3084-9e77-4df5-936a-c1a1317c0f18@gmail.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 23.05.2025 11:44, Oleksii Kurochko wrote: > On 5/22/25 6:09 PM, Jan Beulich wrote: >> On 22.05.2025 17:53, Oleksii Kurochko wrote: >>> On 5/20/25 3:37 PM, Jan Beulich wrote: >>>> On 09.05.2025 17:57, Oleksii Kurochko wrote: >>>>> +static struct page_info *p2m_get_clean_page(struct domain *d) >>>>> +{ >>>>> + struct page_info *page; >>>>> + >>>>> + /* >>>>> + * As mentioned in the Priviliged Architecture Spec (version 20240411) >>>>> + * As explained in Section 18.5.1, for the paged virtual-memory schemes >>>>> + * (Sv32x4, Sv39x4, Sv48x4, and Sv57x4), the root page table is 16 KiB >>>>> + * and must be aligned to a 16-KiB boundary. >>>>> + */ >>>>> + page = alloc_domheap_pages(NULL, 2, 0); >>>> Shouldn't this allocation come from the domain's P2M pool (which is yet >>>> to be introduced)? >>> First, I will drop p2m_get_clean_page() as it will be used only for p2m root page >>> table allocation. >>> >>> p2m_init() is called by domain_create() [->arch_domain_create()->p2m_init()] from create_domUs(): >>> [https://gitlab.com/xen-project/xen/-/blob/staging/xen/common/device-tree/dom0less-build.c?ref_type=heads#L984]. >>> >>> When p2m_init() is called, p2m pool isn't ready and domain isn't created yet. Last one >>> is also crucial for usage of p2m pool as p2m pool belongs to domain and thereby it is >>> using alloc_domheap_page(d, ...) (Not NULL as for allocation of p2m root table above), >>> so domain should be created first. >> Yet that is part of my point: This allocation should be against the domain, >> so it is properly accounted. What's the problem with allocating the root >> table when the pools is being created / filled? > > I can't use pages from pool for root table as they aren't properly aligned. > > At the moment, creation of p2m pool looks like: > int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted) > { > struct page_info *pg; > > ASSERT(spin_is_locked(&d->arch.paging.lock)); > > for ( ; ; ) > { > if ( d->arch.paging.p2m_total_pages < pages ) > { > /* Need to allocate more memory from domheap */ > pg = alloc_domheap_page(d, MEMF_no_owner); > if ( pg == NULL ) > { > printk(XENLOG_ERR "Failed to allocate P2M pages.\n"); > return -ENOMEM; > } > ACCESS_ONCE(d->arch.paging.p2m_total_pages) = > d->arch.paging.p2m_total_pages + 1; > page_list_add_tail(pg, &d->arch.paging.p2m_freelist); > } > ... > } > > return 0; > } > alloc_domheap_page(d, MEMF_no_owner) allocates page table with order 0, so 4k-aligned page table. > But if I needed 16k for root table and it should be 16k-aligned then I still have to use > alloc_domheap_pages(NULL, 2, 0); > > Or do you mean that I have to something like: > int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted) > { > struct page_info *pg; > > ASSERT(spin_is_locked(&d->arch.paging.lock)); > > + if ( !d->arch.p2m.root ) > + { > + unsigned int order = get_order_from_bytes(KB(16)); > + unsigned int nr_pages = _AC(1,U) << order; > + /* > + * As mentioned in the Priviliged Architecture Spec (version 20240411) > + * As explained in Section 18.5.1, for the paged virtual-memory schemes > + * (Sv32x4, Sv39x4, Sv48x4, and Sv57x4), the root page table is 16 KiB > + * and must be aligned to a 16-KiB boundary. > + */ > + d->arch.p2m.root = alloc_domheap_pages(d, order, MEMF_no_owner); > + if ( d->arch.p2m.root == NULL ) > + panic("root page table hasn't been allocated\n"); > + > + clear_and_clean_page(d->arch.p2m.root); > + > + /* TODO: do I need TLB flush here? */ > + > + ACCESS_ONCE(d->arch.paging.p2m_total_pages) = > + d->arch.paging.p2m_total_pages + nr_pages; > + } > + > ... > } Neither. I was thinking of you taking 4 pages off the pool in exchange for the order-2 allocation. Primarily to get the memory accounting right (or at least closer to reality). >>>>> +{ >>>>> + unsigned long ppn; >>>>> + unsigned long hgatp_mode; >>>>> + >>>>> + ppn = PFN_DOWN(page_to_maddr(page_info)) & HGATP_PPN; >>>>> + >>>>> + /* ASID (VMID) not supported yet */ >>>>> + >>>>> +#if RV_STAGE1_MODE == SATP_MODE_SV39 >>>>> + hgatp_mode = HGATP_MODE_SV39X4; >>>>> +#elif RV_STAGE1_MODE == SATP_MODE_SV48 >>>>> + hgatp_mode = HGATP_MODE_SV48X4; >>>>> +#else >>>>> + #error "add HGATP_MODE" >>>> As before, please have the # of pre-processor directives in the first column. >>>> >>>>> +#endif >>>>> + >>>>> + return ppn | (hgatp_mode << HGATP_MODE_SHIFT); >>>> Use MASK_INSR()? >>> Do you mean MASK_INSR(hgatp_mode, HGATP_MODE_MASK)? >>> If yes, then I didn't get what is the point then? >> The point is that generally ..._SHIFT is redundant when you also have >> ..._MASK; that's what MASK_EXTR() and MASK_INSR() leverage. > > At the moment, there is no mask for HGATP_MODE so if to use *_MASK then I > have to introduce it if it better to have *_MASK instead of *_SHIFT. Perhaps best to do so then. >>>>> +static int p2m_alloc_table(struct domain *d) >>>>> +{ >>>>> + struct p2m_domain *p2m = p2m_get_hostp2m(d); >>>>> + >>>>> + p2m->root = p2m_allocate_root(d); >>>>> + if ( !p2m->root ) >>>>> + return -ENOMEM; >>>>> + >>>>> + p2m->hgatp = hgatp_from_page_info(p2m->root); >>>>> + >>>>> + /* >>>>> + * Make sure that all TLBs corresponding to the new VMID are flushed >>>>> + * before using it. >>>>> + */ >>>>> + p2m_write_lock(p2m); >>>>> + p2m_force_tlb_flush_sync(p2m); >>>>> + p2m_write_unlock(p2m); >>>> While Andrew directed you towards a better model in general, it won't be >>>> usable here then, as the guest didn't run on any pCPU(s) yet. Imo you >>>> want to do a single global flush e.g. when VMIDs wrap around. That'll be >>>> fewer global flushes than one per VM creation. >>> I am not sure that I get a phrase 'VMIDs wrap around'. >> You have to allocate them somehow. Typically you'll use the next one available. >> At some point you will need to start over, searching from the beginning. Prior >> to that now allocation of a new one will require any flush, as none of them >> had be in use before (after boot or the last such flush). > > Thanks. Now I get your point. > > Won't be better to do TLB flushing during destroying of a domain so then we will > be sure that TLBs connected to freed VMID aren't present in TLB anymore? That's an option, but will result in more flushes. Furthermore there may be reasons to change the VMID for a domain while it's running. > IIUC, it will work only if VMID is used, right? Well, anything VMID related is of course only relevant when VMIDs are in use. > In case if VMID isn't used, probably we can drop flushing here and do a flush > during booting, right? That'll be too little flushing? > Won't be enough to flushing of guest TLB only during context switch? "only" is interesting here. Context switches are a relatively frequent operation, which in addition you want to be fast. If a flush is necessary there for correctness (e.g. when VMIDs aren't in use), you have to do it there. But if you can flush less frequently without violating correctness, you'd almost always want to use such an opportunity. >>> I am going to implement, p2m_force_tlb_flush_sync() as: >>> static void p2m_force_tlb_flush_sync(struct p2m_domain *p2m) >>> { >>> ... >>> sbi_remote_hfence_gvma(d->dirty_cpumask, 0, 0); >>> ... >>> } >>> >>> With such implementation if the guest didn't run on any pCPU(s) yet >>> then d->dirty_cpumask is empty, then sbi_remote_hfence_gvma() will do nothing >>> as hmask will be NULL (https://gitlab.com/xen-project/people/olkur/xen/-/blob/staging/xen/arch/riscv/sbi.c?ref_type=heads#L238). >>> I am not sure that it is a good idea as I can't find a guarantee in the spec >>> that TLB will be empty during boot time. >> If in doubt, do one global flush while booting. > > By booting you mean somewhere in continue_new_vcpu()? I don't particularly mean any specific place. However, continue_new_vcpu() (by its name) isn't involved in bringing up Xen, is it? Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 02 11:08:57 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 11:08:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003193.1382686 (Exim 4.92) (envelope-from ) id 1uM32F-0007qH-5M; Mon, 02 Jun 2025 11:08:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003193.1382686; Mon, 02 Jun 2025 11:08:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uM32F-0007qA-2L; Mon, 02 Jun 2025 11:08:55 +0000 Received: by outflank-mailman (input) for mailman id 1003193; Mon, 02 Jun 2025 11: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 1uM32E-0007q4-9r for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 11:08:54 +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 f76d0e65-3fa1-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 13:08:52 +0200 (CEST) Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-3a3771c0f8cso2573775f8f.3 for ; Mon, 02 Jun 2025 04:08:52 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-b2ecebb5cf4sm5319150a12.63.2025.06.02.04.08.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 04:08:51 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f76d0e65-3fa1-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1748862532; x=1749467332; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=96Jm4u7S2nACcTkv3aiaQogQWrM493OmL6c8k6PLNIY=; b=LeN9Pyr2lkXb7L54xlbpzqubjJkYzwd3dvZEMYc2R/jHrJf6jkAQHkVJCmL2iJt8KG 8zV8bdaBxCKNWvYViBE3xDvi7WhfC210PvJrTQA2b+O7itset7FgDca237swiXvQhBJB iGRgp4Kd/imHIrIC3gH1mqyjbUq17vTcSAfVFgrCT6iuTs+/Q6qguwv7Z3OR7+QUUzEn J+qiBLU8C2gqTeEi00dUNZK6s6fM6ehRo0fwwhLfJnjp/ZtMwvbDxGWYZdVDu1E8vcRE buE5QQOgL1L0GFpO5iP1WWXuWbfnMrx6hH6o3i9T7TFM+oy9ZgREK8xyz3ImWt1pOrDZ zc8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748862532; x=1749467332; 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=96Jm4u7S2nACcTkv3aiaQogQWrM493OmL6c8k6PLNIY=; b=G1rdYe0tbXk478E1i3cP3WiNDjjSO3nIrX9scd2Ai0WbdsLIwOWejrAVyTwNTmZyM2 sfdFQye25/5ID4Q3PE40BP5x5u3TC91JNe2lm2arOErU8cCKguMT36Rr7YuhapWuw8lg gwrNmj5e1f01Qp5J32tY9ysE53Y18tXBNx633KlpqpO20QTOBQgHpi7dUIJyduVEA5s8 EjTsDBXer2uXxzqRqqDOsEJInevzDzxDqUN3KGjhrQrkI59wGe8buGVZ6hS7XkWDN6kn lJjChMcSvLIzldsdEKRomh0Hykp3fDkp92iBgIyVdFS1ua5rznLsY0osXk5JM9n8WMab 1Oug== X-Forwarded-Encrypted: i=1; AJvYcCUU/DOVjK2yA+qTjOz0fyC/puLYaePIwPNdahCpt++sFsHWeSgsBapwLHa6amrA+L/ds9lr/VZeW+k=@lists.xenproject.org X-Gm-Message-State: AOJu0YzfhR7SqEygk9FKq1uNOAVwW6giCXdF10EAR0v2/11rlVu/38AQ impGszgJpUMaW8K8AGAYgFIEXhrcSPTmrfTYc3uUOOQBlPrQ4d17ytA/p6Ir32WeVg== X-Gm-Gg: ASbGncu4YgKemcu7R6F0f/yJZFFF2jUPc/Sbvfq3lzuTULnBJK4Ty2qKSDLRINKWni2 +NvmYgOkOxaiPvrF7zbVs4BbPYXr8TcflEMUEhDQnx5gK8c0AARwajzlGXnsDKBxuoXM+baD/kZ uWgxgDoTXIQqTt6QRFRCLjZupkx450EBUH27eH4FwSuQYqhZA3xiStoAupRyZglY1apjhGlZvuD 3nGvk+I7xl4W3Azt5C2neW6LBsXQ3YLhSQoaT86ZFXyGnPK6Ojx2kDXZ78W7tvufyI2YHZO/50y 4s5x/xU8+MZW2UzoJAdaztqevszLwmqZ+SOpd9snsPlpQl6XtYo1P0Z9lq2SOsKaE68Kx/wh2nG Q0TvPuBXa3L+yjpnr+dgyBb9MwWiRCzRKgpJr X-Google-Smtp-Source: AGHT+IE17IcbAk117yb+VazU9R8BhdlB8O38D4gJtLMbLIrTkj3SMvh5OlDER/EzWMVNqE31xHfVcQ== X-Received: by 2002:a5d:5f88:0:b0:3a3:7bbc:d959 with SMTP id ffacd0b85a97d-3a4f89a89f7mr9349113f8f.18.1748862531641; Mon, 02 Jun 2025 04:08:51 -0700 (PDT) Message-ID: <5ce4c4a6-8e2e-4b4e-9cec-03a78d1d0173@suse.com> Date: Mon, 2 Jun 2025 13:08:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 3/6] xen/riscv: construct the P2M pages pool for guests 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: <4a6136c3-4146-48e6-85d5-4a6f30bc9920@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: <4a6136c3-4146-48e6-85d5-4a6f30bc9920@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 23.05.2025 12:27, Oleksii Kurochko wrote: > On 5/20/25 4:38 PM, Jan Beulich wrote: >> On 09.05.2025 17:57, Oleksii Kurochko wrote: >>> --- a/xen/arch/riscv/p2m.c >>> +++ b/xen/arch/riscv/p2m.c >>> @@ -1,4 +1,12 @@ >>> #include >>> +/* >>> + * Because of general_preempt_check() from xen/sched.h which uses >>> + * local_events_need_delivery() but latter is declared in . >>> + * Thereby it is needed to icnlude here before xen/sched.h. >>> + * >>> + * Shouldn't be xen/event.h be included in ? >>> + */ >>> +#include >> The question doesn't belong here; such could be put in the post-commit- >> message area. And the answer depends on what dependency you found missing. > > It is needed for local_events_need_delivery() which is used by general_preempt_check() > in p2m_set_allocation(). Otherwise, the following issue will occur: > > In file included from ././include/xen/config.h:17, > from : > arch/riscv/p2m.c: In function 'p2m_set_allocation': > ./include/xen/sched.h:941:36: error: implicit declaration of function 'local_events_need_delivery' [-Werror=implicit-function-declaration] > 941 | (!is_idle_vcpu(current) && local_events_need_delivery()) \ > | ^~~~~~~~~~~~~~~~~~~~~~~~~~ > ./include/xen/compiler.h:26:43: note: in definition of macro 'unlikely' > 26 | #define unlikely(x) __builtin_expect(!!(x),0) > | ^ > arch/riscv/p2m.c:244:27: note: in expansion of macro 'general_preempt_check' > 244 | if ( preempted && general_preempt_check() ) > | ^~~~~~~~~~~~~~~~~~~~~ > cc1: all warnings being treated as errors In which case my answer to your question is "No". Others may take a different perspective. (xen/sched.h being included virtually everywhere, imo we want to avoid adding dependencies there which aren't strictly necessary to keep things building.) >>> @@ -166,3 +176,60 @@ int p2m_init(struct domain *d) >>> >>> return 0; >>> } >>> + >>> +/* >>> + * Set the pool of pages to the required number of pages. >>> + * Returns 0 for success, non-zero for failure. >>> + * Call with d->arch.paging.lock held. >>> + */ >>> +int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted) >>> +{ >>> + struct page_info *pg; >>> + >>> + ASSERT(spin_is_locked(&d->arch.paging.lock)); >>> + >>> + for ( ; ; ) >>> + { >>> + if ( d->arch.paging.p2m_total_pages < pages ) >>> + { >>> + /* Need to allocate more memory from domheap */ >>> + pg = alloc_domheap_page(d, MEMF_no_owner); >>> + if ( pg == NULL ) >>> + { >>> + printk(XENLOG_ERR "Failed to allocate P2M pages.\n"); >>> + return -ENOMEM; >>> + } >>> + ACCESS_ONCE(d->arch.paging.p2m_total_pages) = >>> + d->arch.paging.p2m_total_pages + 1; >> Looks like you copied this from Arm, but this code is bogus: Using >> ACCESS_ONCE() just on the lhs is pretty pointless. Once also used on the >> rhs the expression can easily become >> >> ACCESS_ONCE(d->arch.paging.p2m_total_pages) += 1; >> >> or even >> >> ACCESS_ONCE(d->arch.paging.p2m_total_pages)++; >> >> . >> >>> + page_list_add_tail(pg, &d->arch.paging.p2m_freelist); >>> + } >>> + else if ( d->arch.paging.p2m_total_pages > pages ) >>> + { >>> + /* Need to return memory to domheap */ >>> + pg = page_list_remove_head(&d->arch.paging.p2m_freelist); >>> + if( pg ) >>> + { >>> + ACCESS_ONCE(d->arch.paging.p2m_total_pages) = >>> + d->arch.paging.p2m_total_pages - 1; >> Same here then, obviously. >> >>> + free_domheap_page(pg); >>> + } >>> + else >>> + { >>> + printk(XENLOG_ERR >>> + "Failed to free P2M pages, P2M freelist is empty.\n"); >>> + return -ENOMEM; >>> + } >>> + } >>> + else >>> + break; >>> + >>> + /* Check to see if we need to yield and try again */ >>> + if ( preempted && general_preempt_check() ) >> While it's this way on both Arm and x86, I wonder how useful it is >> to check on every iteration, especially when freeing pages back to the >> buddy allocator. > > IIUC, but a preemption request could happen for both cases. And destroying of > a domain could also consume long time and so not to block hypervisor if something > more urgent should be handled it could be also have this check for the case of > freeng pages back to the buddy allocator. The question wasn't whether to check, but how frequently. The check itself is consuming processing time, too, so one generally wants to balance the number of checks against the size of the resulting time window without any check. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 02 11:12:20 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 11:12:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003204.1382696 (Exim 4.92) (envelope-from ) id 1uM35U-0001FW-Lw; Mon, 02 Jun 2025 11:12:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003204.1382696; Mon, 02 Jun 2025 11:12: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 1uM35U-0001FP-IR; Mon, 02 Jun 2025 11:12:16 +0000 Received: by outflank-mailman (input) for mailman id 1003204; Mon, 02 Jun 2025 11:12: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 1uM35T-0001FJ-Lv for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 11:12:15 +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 701fd723-3fa2-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 13:12:14 +0200 (CEST) Received: by mail-wr1-x42c.google.com with SMTP id ffacd0b85a97d-3a3798794d3so3641458f8f.1 for ; Mon, 02 Jun 2025 04:12:14 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-23506bd939asm68619435ad.70.2025.06.02.04.12.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 04:12:13 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 701fd723-3fa2-11f0-a300-13f23c93f187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1748862734; x=1749467534; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=/yQFO8/a+nNBYLSdWWFYbYJy0W/6piM1Jp2OWBY3pso=; b=GTWbmaJFiVOvohh8CHyzXwjnALy41kkcj1awlMv99Ilt1eNwKIxND+m/1FYQPwBGEB 6K4+ydPjjWjFWmsyI06UgHRJ0j2+wHWcbD4e0UIpXZQRvGPfiGzKLcI8Z6Xjfyqe6+X+ 2fHkhENvPtzYEEb+xEV+F+3BZ+MZN86Cqk3mIsYLxIvKnkD6pv/zORfGWHak9V6G7VrB COvUzjnrh7z1pro51DjREvsJSWyDMrnk+JzdJoaCXJcKGX7gJ4i93HHV5ziZfjyhnbsZ Xb0pVIsc7QGfuXZyVDBEUAnP6yoFtMKaHwMeid8K6ZIubG2sodF/Gu9stXTIqPUoHGzA LskQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748862734; x=1749467534; 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=/yQFO8/a+nNBYLSdWWFYbYJy0W/6piM1Jp2OWBY3pso=; b=wgzQ3Ej3lpytNiphccpeM2xx/ScQfA2rNmMd01v2uyHBhzCneRXFumqV9OuoxKbeIT AZ19BMx28eJQC043EhEPAJyfIaxj2cFgiL59TyJpjWPSYo0VZyD8WCqO3lr4N4EWY40j fVbhiZ8YqXdwsXl8GCmmST/gvY4UUIyQ+jQqwA/GkRadcqPZ64Q/9OkaTo74FkmLcNJ3 0ScVOsogWD9zkvonm2jvYrEkmqsfHgknHBZc4fTAFsiQLG/3vtDjcKSyCf93XDNOJYtH MEjcib4CYU9HKPyB3vJ6A8Zav/1ZDTmUnsa9+F5Wbh6RbEDN0XvpQetKcJjim+X2BeaI r8bw== X-Forwarded-Encrypted: i=1; AJvYcCUE1hVfvmwYvaSOANsrUbU9ab4yuQLjFiVj6ybbIo5bo3P7MENLmc5nSBZMWDiNUmxR9RTHyG9oGu0=@lists.xenproject.org X-Gm-Message-State: AOJu0YyZXM9ud9NNK0GdvXQH7sIRKiUUTOH1/H6V+V96kGU25T8QEZSz fUmt0GvRvkuseeggtSjZSJgUAUJ26V6QK+Njj3OsMLe9D1RwLfN7H+hoQJ0bwMYGzA== X-Gm-Gg: ASbGncvqJ4eujDWiTiHbsHPWlTEY1nPZiL+w1Oa/5XQ227f0NJfSCp1bbBk0iqmYc0Q jeHHGBL9uOOV2DanzyC8VS4gvHIh3XEOy0mmLF9KQ5yj/7qE8JjrZt57PAm0vUWsGP95pEBzc3f PCc5gceNI0DZGOPvdT4LLcAlMIBmf0caKWOKbre692yknCfeZznoXIo/QiEvnYtyhKA/zoBNL0c hMtEnH0Mj/OqYBQ8NAbIuDDfetaRPnDlnsnFamHKbSE1w38GpqMntAPUXFAc5l/g9KqJ1X9+omN Rk0XHM0vLO2B/spXc3mo66tdwBY+f50SKoKFWibFpdfIASC5Yi6954qNgbRZiI0coUwqBzo9edO MJm3b/gBGi9Eylz5qKUkL9afX6/k49ePcUP5y X-Google-Smtp-Source: AGHT+IEueEzD8Lox+/+pUiF/B7aYQ2RsAZI6wayWANPTAjjeNyr4cuxY+pItUrfJAsoPFgmybFlIBQ== X-Received: by 2002:a05:6000:18ad:b0:3a3:727d:10e8 with SMTP id ffacd0b85a97d-3a4fe3a6ac9mr5078869f8f.50.1748862734175; Mon, 02 Jun 2025 04:12:14 -0700 (PDT) Message-ID: <3b1109b5-7028-4ded-b56b-8df4e80fa62f@suse.com> Date: Mon, 2 Jun 2025 13:12:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 5/6] xen/riscv: add new p2m types and helper macros for type classification 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: <52861198c7c363c4b0caf818345f4ffbec056337.1746805907.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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 23.05.2025 13:34, Oleksii Kurochko wrote: > On 5/20/25 5:11 PM, Jan Beulich wrote: >> On 09.05.2025 17:57, Oleksii Kurochko wrote: >>> --- a/xen/arch/riscv/include/asm/p2m.h >>> +++ b/xen/arch/riscv/include/asm/p2m.h >>> @@ -80,8 +80,36 @@ struct p2m_domain { >>> typedef enum { >>> p2m_invalid = 0, /* Nothing mapped here */ >>> p2m_ram_rw, /* Normal read/write domain RAM */ >>> + p2m_ram_ro, /* Read-only; writes are silently dropped */ >> This is pretty special a type, which imo better wouldn't be introduced >> without there being proper support for it. (I don't suppose RISC-V >> hardware alone can effect this type?) > > It is possible to make ro by using r, w, x bits of page table entry in the > same way Arm does that: > case p2m_ram_ro: > e->p2m.xn = 0; > e->p2m.write = 0; > break; That takes care of the r/o aspect, yes, but not of the "writes are silently dropped" one. >>> + p2m_mmio_direct_dev,/* Read/write mapping of genuine Device MMIO area */ >>> + p2m_map_foreign_rw, /* Read/write RAM pages from foreign domain */ >>> + p2m_map_foreign_ro, /* Read-only RAM pages from foreign domain */ >> Aiui you took these from Arm. Looking at its sole use, I'm not convinced >> it's used correctly. If it is, the same comment as for p2m_ram_ro above >> would apply here, too. > > p2m_mmio_direct_dev - this one is defintely needed as it is used for device > pass through to guest domain to map device's MMIO. It seems to me like it is > correctly used. My earlier comment was mainly about p2m_map_foreign_ro. > Others we don't really use now in private branches but it seems like they could be > useful, so I added them now. > > I can drop them now and return back if such functionality which uses them will be > introduced for RISC-V, and at that moment I think it will be > more clear if it is used correctly or not. Indeed. And maybe it'll just be p2m_map_foreign, as we have it on x86. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 02 11:23:11 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 11:23:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003215.1382706 (Exim 4.92) (envelope-from ) id 1uM3Fs-00035E-Im; Mon, 02 Jun 2025 11:23:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003215.1382706; Mon, 02 Jun 2025 11: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 1uM3Fs-000357-Fs; Mon, 02 Jun 2025 11:23:00 +0000 Received: by outflank-mailman (input) for mailman id 1003215; Mon, 02 Jun 2025 11: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 1uM3Fq-000351-Ou for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 11:22:58 +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 eea5c81a-3fa3-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 13:22:56 +0200 (CEST) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-450df5d7b9fso14049365e9.1 for ; Mon, 02 Jun 2025 04:22:56 -0700 (PDT) Received: from localhost.localdomain (host-92-26-98-202.as13285.net. [92.26.98.202]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a4f009fd9bsm14337323f8f.82.2025.06.02.04.22.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 04:22:55 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: eea5c81a-3fa3-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1748863376; x=1749468176; 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=ZpdHezQyE2ZIbO+VDv3N/uXlwAOtaGdLVWN250tzBuo=; b=cezhu61R8DK4In5e5p35UHdHaED8gFOrphq1XSf8/euYTSPzmqF/ArCMfwls6O8Cw3 8S/Q/ES0OYTuyhTgkWjT1mbDbJparYB1t+CqETJJGHxdJCFy0McNQYPqBAzyWdyHI3A6 asbqKy56aAb4PXCIvrJloQ2fGkKmcOL/exP00= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748863376; x=1749468176; 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=ZpdHezQyE2ZIbO+VDv3N/uXlwAOtaGdLVWN250tzBuo=; b=Xpd3068fSbe0Et/KXSUQ0xxKqxgmLbW+7gUwPcyxlKDgPmfIgiQKPIvLvMxJjnNFTe 7Goi4kKrpm/xBqGj4LKp8vvoiwWsiyzL7WXwTuL/apNRF31FKyHiZVjrJF33pFI1lFvn mhMcUS+3f6uWxK+9I34PZ3sj1bzc3/iqEh3rUeOY/662/AkkvPaYBr5tI0ZIhUBcwNMY IDr7NaAG1+xp7ckmC7m3Ia+ukaj2CsaFXW20NCiGVXKvQABMDk8wNt3tywkCXuj5TXk7 5M7kODw1R+1OE9OFO7kAZEiCinhfApIxKUDVktq8flLCCgyQylEut/xu2MT55q25GZ04 129w== X-Gm-Message-State: AOJu0YzSXjNsofmqWh/IvZm0LwaaatSxaqup9CBMWICWLSYWK5ZkJHp5 J0k15fKWPJsjCiXN4Qki9bOqjqNfcUZcshg6dx8ft6i/NQwe9r/E2hFzSN0PonMUy72VcXGnJpF 8AEGN X-Gm-Gg: ASbGncu7kwB/T9DiItu1yBvUkmkco0DP9H4jS8OFB6rY+PfqKU9PS3HCGndG2rXSTEE qIbgTMmGVT2+OU1fD4qqa/JVi8sP6a9Q2pvv0lKHlVhrPOmxo+dVdZaW7+2jGoMtXiaqNudevwI K2HiUriSjXeZXBk/7J2vCtNs0Tv5t/Ey9/Ouj2TW7dsbhhr9JUtFKHXyuTvhRJkqIO09nX+VMXT i0voyeT5+48jhAL7ylr51troNGXb1Kjy1Zv+MUXTXudL8zGpPcdowl3RDjVpv5RU9gNNm8PSfB0 rqCnKwbpry61pKknfNNiPO78RCrTAo4kqstXN18kHNJrsj7fFgryLqJwlsZhN/iLRyIZX2sNTaw sfkd4HnS+Z2e8m+0OjKB8+8lX X-Google-Smtp-Source: AGHT+IF3dstQd6ejemmU3LxccASUB4+LyXvQHeSiQLueIELdt4Eej5WFOl8EB9cX6Bn4F1GdI6MBwQ== X-Received: by 2002:a05:600c:8b51:b0:43b:c857:e9d7 with SMTP id 5b1f17b1804b1-450d6b3ecf3mr116877425e9.5.1748863375781; Mon, 02 Jun 2025 04:22:55 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Anthony PERARD , Juergen Gross Subject: [PATCH] Revert tools/python part of "tools: remove support for running a guest with qemu-traditional" Date: Mon, 2 Jun 2025 12:22:53 +0100 Message-Id: <20250602112253.2628571-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 The migration stream is a stable ABI. What this does is break the ability to inspection and operate on pre-Xen-4.21 streams. Signed-off-by: Andrew Cooper --- CC: Marek Marczykowski-Górecki CC: Anthony PERARD CC: Juergen Gross --- tools/python/xen/migration/libxl.py | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/python/xen/migration/libxl.py b/tools/python/xen/migration/libxl.py index dc5c7ac3550c..5dcb50fe0207 100644 --- a/tools/python/xen/migration/libxl.py +++ b/tools/python/xen/migration/libxl.py @@ -51,10 +51,12 @@ rec_type_to_str = { EMULATOR_HEADER_FORMAT = "II" EMULATOR_ID_unknown = 0x00000000 +EMULATOR_ID_qemu_trad = 0x00000001 EMULATOR_ID_qemu_upstream = 0x00000002 emulator_id_to_str = { EMULATOR_ID_unknown : "Unknown", + EMULATOR_ID_qemu_trad : "Qemu Traditional", EMULATOR_ID_qemu_upstream : "Qemu Upstream", } base-commit: 286c4cc267005f73aba831d22d65abe6874ceaea -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Mon Jun 02 11:27:44 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 11:27:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003222.1382716 (Exim 4.92) (envelope-from ) id 1uM3KR-0003eM-2w; Mon, 02 Jun 2025 11:27:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003222.1382716; Mon, 02 Jun 2025 11:27:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uM3KQ-0003eF-WF; Mon, 02 Jun 2025 11:27:43 +0000 Received: by outflank-mailman (input) for mailman id 1003222; Mon, 02 Jun 2025 11:27:41 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uM3KP-0003e8-Ew for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 11:27:41 +0000 Received: from fout-a5-smtp.messagingengine.com (fout-a5-smtp.messagingengine.com [103.168.172.148]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9673eeb1-3fa4-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 13:27:38 +0200 (CEST) Received: from phl-compute-06.internal (phl-compute-06.phl.internal [10.202.2.46]) by mailfout.phl.internal (Postfix) with ESMTP id 89ACF1380359; Mon, 2 Jun 2025 07:27:37 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-06.internal (MEProxy); Mon, 02 Jun 2025 07:27:37 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 2 Jun 2025 07:27:35 -0400 (EDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9673eeb1-3fa4-11f0-b894-0df219b8e170 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=1748863657; x=1748950057; bh=mMvL2rtjw+i9KmkxaJdZzgLgxjqBmDMDRwPbP2wBerI=; b= PigVAwpTFCJ0F60l/TurgSQOBxnZDRB5L9ODITkdWMZOCJDv/F+X/4OoJtBmuE7/ /fO5UEag9+UA4Rd8KE69rqP46SqR23szN/E/gEx3f2pYfd6MS7eZfD/uC+OKZ97b vwzRqANMmmagMGUXqbOUuSRz1yY20lAbqFnGCfw3tqj8iFlUam/jZ71QcblAUEMq LxU2wDQSYf+Lv/ffIVB0YfZReqb2N67xejJnI/TS/4UuWffltu2lFVENAllmsNbi Bu0FSQjy9XTIYrKk/QH60cujxOMbOZpjEiol2F7PttKu3k7LzWOhExSQ1uiEj1eq pS76/PsDPstoM+0yHY5kfg== 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= 1748863657; x=1748950057; bh=mMvL2rtjw+i9KmkxaJdZzgLgxjqBmDMDRwP bP2wBerI=; b=OuDdZ3w4+di4UbBv3xbUXGVRno0baVAwpatOkqF7ThcbD7id0Hz QnzH5YL3jlIqFQpWBhfINdjpG8JQ2pEnr6StEsvQx1WMGGNQnMSN4sbaoBR7muN/ A8JyJokOSfW1HjU1yM2Wkg1/J3m7rNIQj+4p6fgVmNnezoqI/vh3MWVwrSprWjHc tW/IlxJMWzzq9CEvG/r2Y0k5Pz1FeppAGmq7hcqN87mV546Z6udR6b4dWZco2DeI FCRt692vjzS05Xlhi+onsrm/g4J8RuLnQlkxaB5P90+9mIp9mcWjQw6mSF/L1cYX tf1RKsD2QGY9IP6gHhwcTLiqeOm8QdwzffQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgdefjeehgeculddtuddrgeefvddrtd dtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggft fghnshhusghstghrihgsvgdpuffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftd dtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfhf gggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghkucforghrtgiihihkohifsh hkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhg shhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefgudelteefvefhfeehieetleeihf ejhfeludevteetkeevtedtvdegueetfeejudenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthh hinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopeegpdhmohguvgepshhmthhpohhu thdprhgtphhtthhopegrnhgurhgvfidrtghoohhpvghrfeestghithhrihigrdgtohhmpd hrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdho rhhgpdhrtghpthhtoheprghnthhhohhnhidrphgvrhgrrhgusehvrghtvghsrdhtvggthh dprhgtphhtthhopehjghhrohhsshesshhushgvrdgtohhm X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Mon, 2 Jun 2025 13:27:32 +0200 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Andrew Cooper Cc: Xen-devel , Anthony PERARD , Juergen Gross Subject: Re: [PATCH] Revert tools/python part of "tools: remove support for running a guest with qemu-traditional" Message-ID: References: <20250602112253.2628571-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="M/HnU77sO5JUw4/c" Content-Disposition: inline In-Reply-To: <20250602112253.2628571-1-andrew.cooper3@citrix.com> --M/HnU77sO5JUw4/c Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Jun 2025 13:27:32 +0200 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Andrew Cooper Cc: Xen-devel , Anthony PERARD , Juergen Gross Subject: Re: [PATCH] Revert tools/python part of "tools: remove support for running a guest with qemu-traditional" On Mon, Jun 02, 2025 at 12:22:53PM +0100, Andrew Cooper wrote: > The migration stream is a stable ABI. What this does is break the abilit= y to > inspection and operate on pre-Xen-4.21 streams. Do you mean Xen 4.21 should be able to accept migration of a domU with qemu trad? I don't think it's a desirable feature... > Signed-off-by: Andrew Cooper > --- > CC: Marek Marczykowski-G=C3=B3recki > CC: Anthony PERARD > CC: Juergen Gross > --- > tools/python/xen/migration/libxl.py | 2 ++ > 1 file changed, 2 insertions(+) >=20 > diff --git a/tools/python/xen/migration/libxl.py b/tools/python/xen/migra= tion/libxl.py > index dc5c7ac3550c..5dcb50fe0207 100644 > --- a/tools/python/xen/migration/libxl.py > +++ b/tools/python/xen/migration/libxl.py > @@ -51,10 +51,12 @@ rec_type_to_str =3D { > EMULATOR_HEADER_FORMAT =3D "II" > =20 > EMULATOR_ID_unknown =3D 0x00000000 > +EMULATOR_ID_qemu_trad =3D 0x00000001 > EMULATOR_ID_qemu_upstream =3D 0x00000002 > =20 > emulator_id_to_str =3D { > EMULATOR_ID_unknown : "Unknown", > + EMULATOR_ID_qemu_trad : "Qemu Traditional", > EMULATOR_ID_qemu_upstream : "Qemu Upstream", > } > =20 >=20 > base-commit: 286c4cc267005f73aba831d22d65abe6874ceaea > --=20 > 2.39.5 >=20 --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --M/HnU77sO5JUw4/c Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmg9iqQACgkQ24/THMrX 1yxQkQgAiFicjWZbKDc1nduGygRW6117SSwtaeksBGvpBETN3lzPJFTnvBdDUB6o aflaVg/frCTB8r8RHU2GZbqUUZ4VvjczssETQaBGejvACD6rU5pEZIqbbJ6q9JMa xBA27D1eX/qLNpO4IYuSWnBzO+K8+p+UHQHxXExFapFzivM/ea4+W2qF/T+3iQHV 4y4GLP4cBpHiX3Nvi38s4lsOlJ/3Ftalqoe3iLZkKBmF1tOBnbNj3NaWrXjU56Un 0uaex9gYWMeFWVXdSyu2KgA/8J0jEdJVK6XCOC4+egE62jMDUmZ8C2DMUpAcvAKQ 4Kz6voN7SVsIt0voSabOqhNAR2L1+w== =sn8e -----END PGP SIGNATURE----- --M/HnU77sO5JUw4/c-- From xen-devel-bounces@lists.xenproject.org Mon Jun 02 11:32:22 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 11:32:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003229.1382726 (Exim 4.92) (envelope-from ) id 1uM3Or-0005QC-Jb; Mon, 02 Jun 2025 11:32:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003229.1382726; Mon, 02 Jun 2025 11:32:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uM3Or-0005Q5-Gk; Mon, 02 Jun 2025 11:32:17 +0000 Received: by outflank-mailman (input) for mailman id 1003229; Mon, 02 Jun 2025 11:32: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 1uM3Or-0005Pz-37 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 11:32:17 +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 39b648af-3fa5-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 13:32:11 +0200 (CEST) Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-5533c562608so3034583e87.3 for ; Mon, 02 Jun 2025 04:32:11 -0700 (PDT) Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-450d7fa25besm117437555e9.14.2025.06.02.04.31.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 04:32:00 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 39b648af-3fa5-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1748863931; x=1749468731; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=rTsOX+udqNxI/5fhKLImuGMnxGdWhWIRzg4v6yd1PN4=; b=EXkVISriaiqQ5G0jKarJJPU8/gjoH/0kBDW3KeBq9wZ3LBSMqXYxwvWWwEKWj8hvqr hcDI9CPz2gUlJYffw6Mdnc9D09QFYy0KGrFykh2G14IKy/jhPCl5jARlRPkr6nV/QJ1G qXlFBCpSKDjCPpYbk/+OGd6nDZUCq+9npW2OM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748863931; x=1749468731; 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=rTsOX+udqNxI/5fhKLImuGMnxGdWhWIRzg4v6yd1PN4=; b=Ea94treCIUrkGaLw9xFppWdM2Rxs0amJRyd7vdRdJJXtGVZVHPft5ji6zFXdMc9CqO 9j7s4bJ0VkAwVnYeO3cDSU410GcOZ9qklZU5AXrKZw5np/5uZVr9oDg6rvPOukRfAPpJ IIA8hZ9FG3a85f/+SOkR7wQMQIb5CKaplKGNK3sVgTXmecN/y+ZP5KxGvH4hcJjjNrdK IYfZk5nTFRfIo7ctfLTQ2seBpWfmuGqr3HGfOd0yx9e8nv8sUUxhL6si2D6k6e0j0utn Sgjs7cau1S2ePtNmsyGJQaMVc8j07oZU/hb69mzZJWenrR8+/yGP56uJN74xD224g0s/ GA9g== X-Gm-Message-State: AOJu0Yy249WFWvGQaiy9L9+FD3xdH1QKs+K8LgHfHFrsww96FKEbmOuJ KtCA8gVXrtU9hITMBXloVawziZR7szMsBBL86CBJeyzCGDXxtBsKieybO6Lbrb7/hnEnwAInZLS NOnlC X-Gm-Gg: ASbGncvGRIl7VCQ26XDg6tJGWTwCNLcctPxXfxQJwreFpWmU1Zpy1G8+dw0CRkO2FdX tr91PNI8OxGc8LcqSXbbJNZiU2saga2idLOruzIvhLsp4YXjIXy33Y6YbWb3c4chZSFRpl7Wd9a SnfmCLXo/1LdVLEgYwYeFAOS0+x2o1C1GqmQ6QUQ5mdT0auedWa047AhwkwiK6Iyy7HbRaZ63AG SI5zIpeN7qZz4LKoTGoHcGkso3dqQBuKjl2/b/GaHgTFiY29vNZBLX460/GiQuN+qB2y4ktFSC9 aNnyGN57v/c8F85eLR6TxdTXo6T0i1GNWOJilX1jRTU44Fpbk5Vh4GUVNIQpyvwsSihHQbH5q73 uw5oFn0eWgCSUuuts X-Google-Smtp-Source: AGHT+IHJ0vrFtipV3bhdiTI54MJYxlgcbCjwWWTW4o78zfgD4ViZkePmHjJ8z9feLzX6f3DvWYDFbQ== X-Received: by 2002:a05:600c:1910:b0:450:d3c6:84d8 with SMTP id 5b1f17b1804b1-450d880ce23mr110309655e9.14.1748863920602; Mon, 02 Jun 2025 04:32:00 -0700 (PDT) Message-ID: Date: Mon, 2 Jun 2025 12:31:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Revert tools/python part of "tools: remove support for running a guest with qemu-traditional" To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= Cc: Xen-devel , Anthony PERARD , Juergen Gross References: <20250602112253.2628571-1-andrew.cooper3@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 02/06/2025 12:27 pm, Marek Marczykowski-Górecki wrote: > On Mon, Jun 02, 2025 at 12:22:53PM +0100, Andrew Cooper wrote: >> The migration stream is a stable ABI. What this does is break the ability to >> inspection and operate on pre-Xen-4.21 streams. > Do you mean Xen 4.21 should be able to accept migration of a domU with > qemu trad? I don't think it's a desirable feature... xl is free to reject a qemu-trad stream if it wants. What's not ok is verify-stream-v2 exploding with "unknown emulator 1" when I ask it to tell me what the bytes in this stream mean. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Jun 02 11:33:15 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 11:33:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003239.1382737 (Exim 4.92) (envelope-from ) id 1uM3Pn-0005yX-1X; Mon, 02 Jun 2025 11:33:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003239.1382737; Mon, 02 Jun 2025 11:33: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 1uM3Pm-0005yQ-TY; Mon, 02 Jun 2025 11:33:14 +0000 Received: by outflank-mailman (input) for mailman id 1003239; Mon, 02 Jun 2025 11:33: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 1uM3Pl-0005Pz-O5 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 11:33:13 +0000 Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 5cd4f7fe-3fa5-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 13:33:11 +0200 (CEST) Received: from pps.filterd (m0246631.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 5525tsf4011357; Mon, 2 Jun 2025 11:33:04 GMT Received: from phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta01.appoci.oracle.com [138.1.114.2]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 46yrj52eem-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 02 Jun 2025 11:33:03 +0000 (GMT) Received: from pps.filterd (phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 552BPgAr038592; Mon, 2 Jun 2025 11:33:03 GMT Received: from pps.reinject (localhost [127.0.0.1]) by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 46yr77vhva-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 02 Jun 2025 11:33:02 +0000 Received: from phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 552BWucc001684; Mon, 2 Jun 2025 11:33:02 GMT Received: from ca-dev112.us.oracle.com (ca-dev112.us.oracle.com [10.129.136.47]) by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTP id 46yr77vhuf-2; Mon, 02 Jun 2025 11:33: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: 5cd4f7fe-3fa5-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc :content-transfer-encoding:date:from:in-reply-to:message-id :mime-version:references:subject:to; s=corp-2025-04-25; bh=kvVbO UjyRbYz/XjRS4cixhkQABnoYIWp9dyNm7rGnTk=; b=Rm2JDwdsSnFQJX6ZezlVG 4ZQW06oLvFhJvT6tf0lDspLnMZbVPCUtTNGJCFAOqwMkA8Lu80FmMxfPWWxhSXuF TEsSu0tFcydziuE4ILO+7YWMOcRtFJ3tTGG/57lIVo25hIAShoQuU6DfNhDHPrEM /qsXpD3EX09PAbYR1AQLNOte+3KSMjGjwbwZEOJ+INPKah5i04OKrMmgXM5fUgdz aeSZZpP0f4IsSCResrPRJQOgKDpy9dmA2EsxgdKDDNSHyVCeGHFqb4YD+avvBkcJ irFsFuRyxao/dXJrMdvQY+eqq/fpCWI5nAXlmmEKjC2MHqHPvkA5UnP47G0Qg5MC w== From: Harshvardhan Jha To: jgross@suse.com, sstabellini@kernel.org, boris.ostrovsky@oracle.com Cc: harshvardhan.j.jha@oracle.com, xen-devel@lists.xenproject.org, iommu@lists.linux.dev, stable@vger.kernel.org Subject: [PATCH 5.10.y 1/1] xen/swiotlb: relax alignment requirements Date: Mon, 2 Jun 2025 04:33:01 -0700 Message-ID: <20250602113301.3475805-2-harshvardhan.j.jha@oracle.com> X-Mailer: git-send-email 2.47.1 In-Reply-To: <20250602113301.3475805-1-harshvardhan.j.jha@oracle.com> References: <20250602113301.3475805-1-harshvardhan.j.jha@oracle.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40 definitions=2025-06-02_05,2025-05-30_01,2025-03-28_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 bulkscore=0 suspectscore=0 phishscore=0 mlxlogscore=999 adultscore=0 malwarescore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2505160000 definitions=main-2506020099 X-Authority-Analysis: v=2.4 cv=fs7cZE4f c=1 sm=1 tr=0 ts=683d8bf0 cx=c_pps a=XiAAW1AwiKB2Y8Wsi+sD2Q==:117 a=XiAAW1AwiKB2Y8Wsi+sD2Q==:17 a=6IFa9wvqVegA:10 a=iox4zFpeAAAA:8 a=yPCof4ZbAAAA:8 a=E5hRKjw2lWykmI9IJP0A:9 a=WzC6qhA0u3u7Ye7llzcV:22 X-Proofpoint-GUID: eIe7wPBNFEkgpFOKJc8CTUn2I2JL3tdR X-Proofpoint-ORIG-GUID: eIe7wPBNFEkgpFOKJc8CTUn2I2JL3tdR X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjAyMDEwMCBTYWx0ZWRfX3JG8hQvTJkFH YhYo0zEP2AnAkx95ZpNuvEzj0d/tTPJQjcoA0El66Z4LXT4MrvGlDtVTWVv5E3ORmp4oCju9NRz v66GdNPW6kvbGisENUDvQKU3Ges47rFFldTB8X6UZZKinRYSgwQc2kQy2QBhWnMSTISXF5qj0XK ayulbdthVGdTqZltq/RSm6MXq79v2flvRjx+t+2m/Hdj0CQd5v/k0flKteFDwkMBHuBThKn7rL3 9y3EkPjJ5WmE//4i0ry/OvAoDG3ywIIOLQcCXDjWkIhqeSj/nwK4INmGFFguqni12bKk2xbYxzW w+aoyWb7sOygXgjIiLSBM31ol80LsEqBVu2gVmAjIZMLXj4CxQB7DsaQUpM15T/vBLPbfLOfVl6 EEUWLXqpHhYz1iiArnpTDz41LUoCn/wOvv9i0uAVHsNgOvGKkbOeB+LZ6B4m+30ttsA55zpp [ Upstream commit 85fcb57c983f423180ba6ec5d0034242da05cc54 ] When mapping a buffer for DMA via .map_page or .map_sg DMA operations, there is no need to check the machine frames to be aligned according to the mapped areas size. All what is needed in these cases is that the buffer is contiguous at machine level. So carve out the alignment check from range_straddles_page_boundary() and move it to a helper called by xen_swiotlb_alloc_coherent() and xen_swiotlb_free_coherent() directly. Fixes: 9f40ec84a797 ("xen/swiotlb: add alignment check for dma buffers") Signed-off-by: Juergen Gross Signed-off-by: Harshvardhan Jha --- drivers/xen/swiotlb-xen.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c index 000d02ea4f7d8..d8efb8ea23a0d 100644 --- a/drivers/xen/swiotlb-xen.c +++ b/drivers/xen/swiotlb-xen.c @@ -87,19 +87,21 @@ static inline dma_addr_t xen_virt_to_bus(struct device *dev, void *address) return xen_phys_to_dma(dev, virt_to_phys(address)); } +static inline bool range_requires_alignment(phys_addr_t p, size_t size) +{ + phys_addr_t algn = 1ULL << (get_order(size) + PAGE_SHIFT); + phys_addr_t bus_addr = pfn_to_bfn(XEN_PFN_DOWN(p)) << XEN_PAGE_SHIFT; + + return IS_ALIGNED(p, algn) && !IS_ALIGNED(bus_addr, algn); +} + static inline int range_straddles_page_boundary(phys_addr_t p, size_t size) { unsigned long next_bfn, xen_pfn = XEN_PFN_DOWN(p); unsigned int i, nr_pages = XEN_PFN_UP(xen_offset_in_page(p) + size); - phys_addr_t algn = 1ULL << (get_order(size) + PAGE_SHIFT); next_bfn = pfn_to_bfn(xen_pfn); - /* If buffer is physically aligned, ensure DMA alignment. */ - if (IS_ALIGNED(p, algn) && - !IS_ALIGNED((phys_addr_t)next_bfn << XEN_PAGE_SHIFT, algn)) - return 1; - for (i = 1; i < nr_pages; i++) if (pfn_to_bfn(++xen_pfn) != ++next_bfn) return 1; @@ -321,7 +323,8 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size, phys = dma_to_phys(hwdev, *dma_handle); dev_addr = xen_phys_to_dma(hwdev, phys); if (((dev_addr + size - 1 <= dma_mask)) && - !range_straddles_page_boundary(phys, size)) + !range_straddles_page_boundary(phys, size) && + !range_requires_alignment(phys, size)) *dma_handle = dev_addr; else { if (xen_create_contiguous_region(phys, order, @@ -362,6 +365,7 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t size, void *vaddr, if (!WARN_ON((dev_addr + size - 1 > dma_mask) || range_straddles_page_boundary(phys, size)) && + !range_requires_alignment(phys, size) && TestClearPageXenRemapped(page)) xen_destroy_contiguous_region(phys, order); -- 2.47.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 02 11:33:19 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 11:33:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003240.1382745 (Exim 4.92) (envelope-from ) id 1uM3Pr-0006DJ-7R; Mon, 02 Jun 2025 11:33:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003240.1382745; Mon, 02 Jun 2025 11:33:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uM3Pr-0006DC-3h; Mon, 02 Jun 2025 11:33:19 +0000 Received: by outflank-mailman (input) for mailman id 1003240; Mon, 02 Jun 2025 11:33: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 1uM3Pp-0006CN-F9 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 11:33:17 +0000 Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 5eda54ee-3fa5-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 13:33:15 +0200 (CEST) Received: from pps.filterd (m0246629.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 5525uF3Y004998; Mon, 2 Jun 2025 11:33:09 GMT Received: from phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta01.appoci.oracle.com [138.1.114.2]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 46ysnctcna-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 02 Jun 2025 11:33:09 +0000 (GMT) Received: from pps.filterd (phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 5529ZsOr039135; Mon, 2 Jun 2025 11:33:02 GMT Received: from pps.reinject (localhost [127.0.0.1]) by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 46yr77vhux-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 02 Jun 2025 11:33:02 +0000 Received: from phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 552BWuca001684; Mon, 2 Jun 2025 11:33:01 GMT Received: from ca-dev112.us.oracle.com (ca-dev112.us.oracle.com [10.129.136.47]) by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTP id 46yr77vhuf-1; Mon, 02 Jun 2025 11:33: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: 5eda54ee-3fa5-11f0-a300-13f23c93f187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc :content-transfer-encoding:date:from:message-id:mime-version :subject:to; s=corp-2025-04-25; bh=CfDjhvQigRmWcz+CuhlX6AvZKsSV2 OiOmpQmK2j9khE=; b=abk8xrq3xSmGyzaxVFHwBna5bmg5JiX6X9pHDoDNY4xwv 5dvXdaucHCmels5qSn3JScEk4Ra5L6aAIuxljx2+hAqm6SVRlbeZhLol3N8+DXBn whuC8TofbjV0U8NUx2capxZuC3xRACg/F8adHKPdsFmm8xrts9mxvg+J66bw+N90 cp2P/f+F2aeFlZ0Jtxi1JwM2GIIbniHzHEQx8C0nk71SElANlpKwIPb2C64Kyxs7 jxT0cfiVIL/O58dHKAH3jRNqECAnHFG8m1uGwNbDBLZpgdmtlVy7L0rB50fNjWES n5SkMEBYS/EMndZ+8U6VjzMjiuIURNkYxpSLmeP3w== From: Harshvardhan Jha To: jgross@suse.com, sstabellini@kernel.org, boris.ostrovsky@oracle.com Cc: harshvardhan.j.jha@oracle.com, xen-devel@lists.xenproject.org, iommu@lists.linux.dev, stable@vger.kernel.org Subject: [PATCH 5.10.y 0/1] Manual Backport of 099606a7b2d5 to 5.10 Date: Mon, 2 Jun 2025 04:33:00 -0700 Message-ID: <20250602113301.3475805-1-harshvardhan.j.jha@oracle.com> X-Mailer: git-send-email 2.47.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40 definitions=2025-06-02_05,2025-05-30_01,2025-03-28_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 bulkscore=0 suspectscore=0 phishscore=0 mlxlogscore=999 adultscore=0 malwarescore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2505160000 definitions=main-2506020099 X-Authority-Analysis: v=2.4 cv=Jdu8rVKV c=1 sm=1 tr=0 ts=683d8bf5 cx=c_pps a=XiAAW1AwiKB2Y8Wsi+sD2Q==:117 a=XiAAW1AwiKB2Y8Wsi+sD2Q==:17 a=6IFa9wvqVegA:10 a=cixntLcyVTLVvfsobb8A:9 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjAyMDEwMCBTYWx0ZWRfXyNIOyIVGfBrV ktK1V6Xu3f79srrd4w0S1bq7yGbLZgDZ3shoFa2l01puyzAxv6ParH9NBJtpHU6X+sTE/pvvDF+ WuUu4PvasOTDK9ZCxWkIbsfetzmDLj7F4jPgp5UdsjAIiaGAqLH5m0+5ViD6XLDcappv2I7292r iEcrsXOGkx9mAyJvB4zK8418JuMVUR6K75n0icDT4u2AAYfthTfYjRHhcCLcr1joYEjz0mK5AuM eb6UB1YRXxUdwxJ+tax/ZqjIUECNJBSX3+NG6X5BPpVBtIzCwf/1G/5cjJREtoG8Pg+CQ88OAwp bIkymP/ni2Yn/Avq9Sb0r/XhB905U4q7WQQkQJIHlbELKqC2S6KRBXZarM/8+XYcsrEUYw1TWa8 gtD+nw4y0WsCSZJZaW5JABeXOJJ78061uHj/owALA5avyUG9p3kjnp9d4BdQuTCzzomDbVtn X-Proofpoint-GUID: LWPjPIADqO7-S79GFkKNeZQ-FKaukyki X-Proofpoint-ORIG-GUID: LWPjPIADqO7-S79GFkKNeZQ-FKaukyki The patch 099606a7b2d5 didn't cleanly apply to 5.10 due to the significant difference in codebases. I've tried to manually bring it back to 5.10 via some minor conflict resolution but also invoking the newly introduced API using inverted logic as the conditionals present in 5.10 are the opposite of those in 6.1 xen/swiotlib. Harshvardhan Jha (1): xen/swiotlb: relax alignment requirements drivers/xen/swiotlb-xen.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) -- 2.47.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 02 11:33:20 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 11:33:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003241.1382756 (Exim 4.92) (envelope-from ) id 1uM3Ps-0006Rq-DX; Mon, 02 Jun 2025 11:33:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003241.1382756; Mon, 02 Jun 2025 11:33:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uM3Ps-0006Rh-AX; Mon, 02 Jun 2025 11:33:20 +0000 Received: by outflank-mailman (input) for mailman id 1003241; Mon, 02 Jun 2025 11: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 1uM3Pr-0005Pz-6k for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 11:33:19 +0000 Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 5ff3f062-3fa5-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 13:33:17 +0200 (CEST) Received: from pps.filterd (m0246629.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 5525umN9005801; Mon, 2 Jun 2025 11:33:12 GMT Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.appoci.oracle.com [147.154.18.20]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 46ysnctcnf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 02 Jun 2025 11:33:11 +0000 (GMT) Received: from pps.filterd (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 5529mSOh030588; Mon, 2 Jun 2025 11:33:10 GMT Received: from pps.reinject (localhost [127.0.0.1]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 46yr77uuja-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 02 Jun 2025 11:33:10 +0000 Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 552BXAUj020033; Mon, 2 Jun 2025 11:33:10 GMT Received: from ca-dev112.us.oracle.com (ca-dev112.us.oracle.com [10.129.136.47]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTP id 46yr77uuhu-1; Mon, 02 Jun 2025 11:33:09 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5ff3f062-3fa5-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc :content-transfer-encoding:date:from:message-id:mime-version :subject:to; s=corp-2025-04-25; bh=/vrCB2lmg2R3iKH+4Uwt19KHyOhC+ iMk6uA4rOe3q4A=; b=Y94lSI5a6a2VspzMaNb0XQi8eXM/gfX6H3pkVDvhPLTzv 5WpMO3BD/BQlibNYyUf3/UhrZ7u6PtmcBtJcnB9iStFve2EV6dn7ONQ/Ujakzt46 ezffkg2ywPFxMl4BiA1zmKxPQ+2kW/AUDs2DnJBjmVzGhoeS8UxztTtKzKwaUcQ5 pSz23lNbH6ZfX2wmbGnP+jfvLBGnqmY7pvADuK990SRXs9wfb3B7vffaOgkGZccy Vv8gQKSZdxyvXIKK2Eux2pCxXLP89TqqZIjoMHcaDDOZUqARqomxC4Td9bh4NAe0 3YxTqQknZ3xB36osaarx2mjUpbifzYH5pcXdaY/Sg== From: Harshvardhan Jha To: jgross@suse.com, sstabellini@kernel.org, boris.ostrovsky@oracle.com Cc: harshvardhan.j.jha@oracle.com, xen-devel@lists.xenproject.org, iommu@lists.linux.dev, stable@vger.kernel.org Subject: [PATCH 5.4.y 0/1] Manual Backport of 099606a7b2d5 to 5.4 Date: Mon, 2 Jun 2025 04:33:07 -0700 Message-ID: <20250602113308.3475836-1-harshvardhan.j.jha@oracle.com> X-Mailer: git-send-email 2.47.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40 definitions=2025-06-02_05,2025-05-30_01,2025-03-28_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 malwarescore=0 suspectscore=0 phishscore=0 adultscore=0 spamscore=0 mlxlogscore=999 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2505160000 definitions=main-2506020099 X-Authority-Analysis: v=2.4 cv=Jdu8rVKV c=1 sm=1 tr=0 ts=683d8bf7 b=1 cx=c_pps a=e1sVV491RgrpLwSTMOnk8w==:117 a=e1sVV491RgrpLwSTMOnk8w==:17 a=6IFa9wvqVegA:10 a=lNF16g9DOHChzQpZLYMA:9 cc=ntf awl=host:14714 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjAyMDEwMCBTYWx0ZWRfXxqXNfMl9KVkx JdK844gffey5z34nf8j/Kxd06rEHB2abD0GC7Npv+TXxrsNGfEke3NrPC3mjMwQiXeCoxl3aPLC TiphMJwSjyER1e2NRsUCi+IncTgsQa+4G/KcQiNeqXlTNe6oJEb76XYZzj8C3UMy7wPeFAEmlL2 Scg5mwi37GfKbYvxOeT3JaxcZLOAiAtdLZ+4iMp00F8DyVywyQAHB0QPvOtIkAcpc76lPGMPkq5 oSxUizTJOscqAWnKgdlaoSrCH9bu9vtS11CfqdC2wKNZv05WcpbzXJGuxLJ9mZmJ7UG9Mwqw7aR F/HsNAVWMYvQHmn5Dsah8hnhuMETtoUAMeqCcSi4QLZExOr+tRMoKis/NLRqx7XacUWI8o2SN64 TwOmMjd66kh5iSVPE5BI9meIMAoKvq3fD8TkEw9Zid69RUOdvaCkd1xYgo2/xMPhK+EcBSiq X-Proofpoint-GUID: W_CYE281bNe4V2F4hhYOrMuU4d0TiXBg X-Proofpoint-ORIG-GUID: W_CYE281bNe4V2F4hhYOrMuU4d0TiXBg The patch 099606a7b2d5 didn't cleanly apply to 5.4 due to the significant difference in codebases. I've tried to manually bring it back to 5.4 via some minor conflict resolution but also invoking the newly introduced API using inverted logic as the conditionals present in 5.4 are the opposite of those in 6.1 xen/swiotlib. Harshvardhan Jha (1): xen/swiotlb: relax alignment requirements drivers/xen/swiotlb-xen.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) -- 2.47.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 02 11:33:24 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 11:33:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003242.1382766 (Exim 4.92) (envelope-from ) id 1uM3Pv-0006jH-LJ; Mon, 02 Jun 2025 11:33:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003242.1382766; Mon, 02 Jun 2025 11:33:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uM3Pv-0006j8-Ho; Mon, 02 Jun 2025 11:33:23 +0000 Received: by outflank-mailman (input) for mailman id 1003242; Mon, 02 Jun 2025 11:33: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 1uM3Pu-0005Pz-92 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 11:33:22 +0000 Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 61ee9dc0-3fa5-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 13:33:20 +0200 (CEST) Received: from pps.filterd (m0246617.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 5525uQTG002330; Mon, 2 Jun 2025 11:33:15 GMT Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.appoci.oracle.com [147.154.18.20]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 46ytawjcbr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 02 Jun 2025 11:33:14 +0000 (GMT) Received: from pps.filterd (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 5529VABB030620; Mon, 2 Jun 2025 11:33:12 GMT Received: from pps.reinject (localhost [127.0.0.1]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 46yr77uujv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 02 Jun 2025 11:33:11 +0000 Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 552BXAUl020033; Mon, 2 Jun 2025 11:33:11 GMT Received: from ca-dev112.us.oracle.com (ca-dev112.us.oracle.com [10.129.136.47]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTP id 46yr77uuhu-2; Mon, 02 Jun 2025 11:33: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: 61ee9dc0-3fa5-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc :content-transfer-encoding:date:from:in-reply-to:message-id :mime-version:references:subject:to; s=corp-2025-04-25; bh=gayvE A2rVtsXvkFiJ3V1oEC2mGeCkmsqwcTLVgBGcnU=; b=cwrSisxuL3SydVLeYypgp R+CWudHLz95hzRmFVNhqRZORVzAGzdcoFAUSYD2gbotJ7Nz8ybo3Yy64bEM5im/T fVBh/lFcU0H+FGeaL7Z44dTSCNg1Y7anLI3RYSZtQnoQFsR8mtUtlIgNF33AEKcV 6r3W1ajAV4ea8LUReU2x9rLIGs5U//5lBiHH0+jo44RL8RrQN7LQtY6q1ke76uyt b2iucf/aana75SBAXL7p2uimHUssAhwxvpCQZHyJ4lDwKkwTKOSMl7YYEXMDvvnG S5kMhu73hsQtvkU2CCCKX3J67GVbWPxoNsLNTGqfHZWYFztedE2b2CwnBYJCkYk/ w== From: Harshvardhan Jha To: jgross@suse.com, sstabellini@kernel.org, boris.ostrovsky@oracle.com Cc: harshvardhan.j.jha@oracle.com, xen-devel@lists.xenproject.org, iommu@lists.linux.dev, stable@vger.kernel.org Subject: [PATCH 5.4.y 1/1] xen/swiotlb: relax alignment requirements Date: Mon, 2 Jun 2025 04:33:08 -0700 Message-ID: <20250602113308.3475836-2-harshvardhan.j.jha@oracle.com> X-Mailer: git-send-email 2.47.1 In-Reply-To: <20250602113308.3475836-1-harshvardhan.j.jha@oracle.com> References: <20250602113308.3475836-1-harshvardhan.j.jha@oracle.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40 definitions=2025-06-02_05,2025-05-30_01,2025-03-28_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 malwarescore=0 suspectscore=0 phishscore=0 adultscore=0 spamscore=0 mlxlogscore=999 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2505160000 definitions=main-2506020099 X-Proofpoint-GUID: TduUfKGbuxsukIBDwRYM4gyTx9y4tmCM X-Proofpoint-ORIG-GUID: TduUfKGbuxsukIBDwRYM4gyTx9y4tmCM X-Authority-Analysis: v=2.4 cv=ctObk04i c=1 sm=1 tr=0 ts=683d8bfb b=1 cx=c_pps a=e1sVV491RgrpLwSTMOnk8w==:117 a=e1sVV491RgrpLwSTMOnk8w==:17 a=6IFa9wvqVegA:10 a=iox4zFpeAAAA:8 a=yPCof4ZbAAAA:8 a=E5hRKjw2lWykmI9IJP0A:9 a=WzC6qhA0u3u7Ye7llzcV:22 cc=ntf awl=host:14714 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjAyMDEwMCBTYWx0ZWRfXwLSOvWaaOpvw /9NGPMepObrOY+QYEypxiCckoPETYx0oNPJkwRzfn/4TqftXcO1+irEyoGFAjnQMAXIB/QpCwHr KLg8cA0yOnt9yYoNXYZjxIjJSKDdIwA0ykcTmivx0sCJsPE6ZxZMAGMMJ26RBhcs4HMDtyx4vHC MsFpj8FWiavKM92wjcSsC0b2+DhhXNJPEjzV/QvwUfVkdWthzgRojsXuTJHhO9r80qZSnsoRZx0 gRNmNaitmu9OMppw1W7ZF0IZ5d/VXYM1SmZ+Wgd5EnLHQ6l7Y3hHdxNnXyunHSvyetGWtkhbxnJ 4fDqsStL2toaf6uzjvS66TrUwj7pk5R/V4KeHrT4hJ+66J6FL1qyknT83gfMi23E79/2yACnYGV gIMVSyyY3Gn7sWPl2LdZ4Wk9ogB6n1zL8GjgtQirONaV1qifV4btqSIJTjERMtGLTrqnE+CC [ Upstream commit 85fcb57c983f423180ba6ec5d0034242da05cc54 ] When mapping a buffer for DMA via .map_page or .map_sg DMA operations, there is no need to check the machine frames to be aligned according to the mapped areas size. All what is needed in these cases is that the buffer is contiguous at machine level. So carve out the alignment check from range_straddles_page_boundary() and move it to a helper called by xen_swiotlb_alloc_coherent() and xen_swiotlb_free_coherent() directly. Fixes: 9f40ec84a797 ("xen/swiotlb: add alignment check for dma buffers") Signed-off-by: Juergen Gross Signed-off-by: Harshvardhan Jha --- drivers/xen/swiotlb-xen.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c index 5bd29d0bffa2e..382ee7dc3d5d9 100644 --- a/drivers/xen/swiotlb-xen.c +++ b/drivers/xen/swiotlb-xen.c @@ -85,19 +85,21 @@ static inline dma_addr_t xen_virt_to_bus(void *address) return xen_phys_to_bus(virt_to_phys(address)); } +static inline bool range_requires_alignment(phys_addr_t p, size_t size) +{ + phys_addr_t algn = 1ULL << (get_order(size) + PAGE_SHIFT); + phys_addr_t bus_addr = pfn_to_bfn(XEN_PFN_DOWN(p)) << XEN_PAGE_SHIFT; + + return IS_ALIGNED(p, algn) && !IS_ALIGNED(bus_addr, algn); +} + static inline int range_straddles_page_boundary(phys_addr_t p, size_t size) { unsigned long next_bfn, xen_pfn = XEN_PFN_DOWN(p); unsigned int i, nr_pages = XEN_PFN_UP(xen_offset_in_page(p) + size); - phys_addr_t algn = 1ULL << (get_order(size) + PAGE_SHIFT); next_bfn = pfn_to_bfn(xen_pfn); - /* If buffer is physically aligned, ensure DMA alignment. */ - if (IS_ALIGNED(p, algn) && - !IS_ALIGNED((phys_addr_t)next_bfn << XEN_PAGE_SHIFT, algn)) - return 1; - for (i = 1; i < nr_pages; i++) if (pfn_to_bfn(++xen_pfn) != ++next_bfn) return 1; @@ -320,7 +322,8 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size, phys = *dma_handle; dev_addr = xen_phys_to_bus(phys); if (((dev_addr + size - 1 <= dma_mask)) && - !range_straddles_page_boundary(phys, size)) + !range_straddles_page_boundary(phys, size) && + !range_requires_alignment(phys, size)) *dma_handle = dev_addr; else { if (xen_create_contiguous_region(phys, order, @@ -360,6 +363,7 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t size, void *vaddr, if (!WARN_ON((dev_addr + size - 1 > dma_mask) || range_straddles_page_boundary(phys, size)) && + !range_requires_alignment(phys, size) && TestClearPageXenRemapped(page)) xen_destroy_contiguous_region(phys, order); -- 2.47.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 02 12:02:58 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 12:02:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003281.1382824 (Exim 4.92) (envelope-from ) id 1uM3sS-0004qJ-Ev; Mon, 02 Jun 2025 12:02:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003281.1382824; Mon, 02 Jun 2025 12: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 1uM3sS-0004qC-Bs; Mon, 02 Jun 2025 12:02:52 +0000 Received: by outflank-mailman (input) for mailman id 1003281; Mon, 02 Jun 2025 12:02: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 1uM3sR-0004q5-EA for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 12:02:51 +0000 Received: from mail137-30.atl71.mandrillapp.com (mail137-30.atl71.mandrillapp.com [198.2.137.30]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8047a3a3-3fa9-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 14:02:49 +0200 (CEST) Received: from pmta07.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail137-30.atl71.mandrillapp.com (Mailchimp) with ESMTP id 4b9ssz1qZpzMQxdLv for ; Mon, 2 Jun 2025 12:02:47 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id c62ac387ba0f4ebba1484d9b7361dd6f; Mon, 02 Jun 2025 12:02:47 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8047a3a3-3fa9-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1748865767; x=1749135767; bh=S7GHa6QN4mpZvACWU57SJNZSis3cue+XvOomwDDlDj8=; 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=biAFs/qbcu28PufYpcg89EnO7qWobw1X0MF2tHWO3FApj2f4ta/l3sZLk6QAnBg7H SW76k6mNXMKJwe+t4I2yl/nQFnDUIl/PVtsRQvzW/XKoSjYIYJSs0kENawoJTNzjRW munIuuioncLmoFtWEdFfHzN7zVmHsskrcZODpKgrmp/E3PGf4OUzTLhyJRYcoioENI CSsrYVu5orl0eXFr69fXffRse4qegIu44rHM6TWlS43SeyjgkPvBnuduBYqxgZY4/s L9hOSc8fcy7dlbcWKvdbwDYJsqXNo/XSBsVTDuY88abW1CG6w6Fzlq+p1A+7hjK/y8 OcbBzEwBX2M4w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1748865767; x=1749126267; i=anthony.perard@vates.tech; bh=S7GHa6QN4mpZvACWU57SJNZSis3cue+XvOomwDDlDj8=; 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=HUd/94DBJKBY2RRldDAYiSDa3K28f+OaSynzBv/D6lWWnDnmHQKoBnKu4JZGujogH 17K7DpwTgiNpxv8h9Qpfb9hVeBkZGzSw2tXOq/DBKJHU55NTEVphubjcbpCq3BMqas iJNBYm7A/iYdrCqxsMdvjtIUoYy/+K7QuW3t6m3OocOLGhfiNga5GqfNqlPOLVI/VL Hbgz4n5bf3jJl6+4fjH2V9E2KEgPoGcvhsorSbcpvDJ9KwhhLBn8Y0OfIUShOWyADw 1QppsqQ3//cfsn0rsr0ei1EkfZfhrgxwqE2SGDE43grARdhIA7+SG5XwP6oIhJNcPX m9npfyFqCwsvg== From: "Anthony PERARD" Subject: =?utf-8?Q?Re:=20[PATCH]=20Revert=20tools/python=20part=20of=20"tools:=20remove=20support=20for=20running=20a=20guest=20with=20qemu-traditional"?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1748865766130 To: "Andrew Cooper" Cc: Xen-devel , "=?utf-8?Q?Marek=20Marczykowski-G=C3=B3recki?=" , "Juergen Gross" Message-Id: References: <20250602112253.2628571-1-andrew.cooper3@citrix.com> In-Reply-To: <20250602112253.2628571-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.c62ac387ba0f4ebba1484d9b7361dd6f?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20250602:md Date: Mon, 02 Jun 2025 12:02:47 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On Mon, Jun 02, 2025 at 12:22:53PM +0100, Andrew Cooper wrote: > The migration stream is a stable ABI. What this does is break the ability to > inspection and operate on pre-Xen-4.21 streams. > > Signed-off-by: Andrew Cooper Acked-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 Jun 02 12:34:14 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 12:34:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003297.1382833 (Exim 4.92) (envelope-from ) id 1uM4Mc-0000w8-PG; Mon, 02 Jun 2025 12:34:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003297.1382833; Mon, 02 Jun 2025 12: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 1uM4Mc-0000w1-M9; Mon, 02 Jun 2025 12:34:02 +0000 Received: by outflank-mailman (input) for mailman id 1003297; Mon, 02 Jun 2025 12: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 1uM4Ma-0000vv-TA for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 12:34:01 +0000 Received: from gw4.antarean.org (gw4.antarean.org [136.144.238.64]) by se1-gles-sth1.inumbo.com (Halon) with ESMTP id da5c0921-3fad-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 14:33:57 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by gw4.antarean.org (Postfix) with ESMTP id 4b9tT62dzmzNkbn for ; Mon, 02 Jun 2025 14:29:46 +0200 (CEST) Received: from gw4.antarean.org ([127.0.0.1]) by localhost (gw4.antarean.org [127.0.0.1]) (amavis, port 10024) with ESMTP id vuC9TymzEBZm for ; Mon, 2 Jun 2025 14:29:44 +0200 (CEST) Received: from mailstore1.adm.antarean.org (localhost [127.0.0.1]) by gw4.antarean.org (Postfix) with ESMTP id 4b9tT46f8yzNkDx for ; Mon, 02 Jun 2025 14:29:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mailstore1.adm.antarean.org (Postfix) with ESMTP id 4b9tYv3y12z17 for ; Mon, 02 Jun 2025 12:33:55 +0000 (UTC) Received: from mailstore1.adm.antarean.org ([127.0.0.1]) by localhost (mailstore1.adm.antarean.org [127.0.0.1]) (amavis, port 10024) with ESMTP id X4pFflhNJVX9 for ; Mon, 2 Jun 2025 12:28:55 +0000 (UTC) Received: from persephone.localnet (persephone.adm.antarean.org [10.55.16.48]) (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 mailstore1.adm.antarean.org (Postfix) with ESMTPS id 4b9tS70LY2z15 for ; Mon, 02 Jun 2025 12:28:55 +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: da5c0921-3fad-11f0-a300-13f23c93f187 X-Virus-Scanned: amavis at antarean.org X-Virus-Scanned: amavis at antarean.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=antarean.org; s=default; t=1748867335; bh=14z1t6M505HYK1WY1Wpn6iJw1GferfRcM4xInosrBWk=; h=From:To:Subject:Date; b=X8ZGj/GAKiMpoFvKC0fmngDkcweAVYLusPlNnfGZS2AeJ9xba5PnNnyrTJEM+q/A3 PZ5XLDBu6i41JvtONS1eLq6MkB5Ba4c3cd5ORKKwbMdi9yjL5+9lEhisY6NbZ8+Dd+ VbKtIV1OgzeYFXt8/gGdoIQm/4R8kseM0kt+ELYM= From: "J. Roeleveld" To: xen-devel@lists.xenproject.org Subject: Kernel panic when passing through 2 identical PCI devices Date: Mon, 02 Jun 2025 14:28:54 +0200 Message-ID: <2226691.irdbgypaU6@persephone> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart13775105.uLZWGnKmhe" Content-Transfer-Encoding: 7Bit This is a multi-part message in MIME format. --nextPart13775105.uLZWGnKmhe Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Hi all, I have a domain to which I pass through 4 PCI devices: 2 NVMe drives 83:00.0 Samsung 980 NVMe 84:00.0 Samsung 980 NVMe 2 HBA Controllers 86:00.0 LSI SAS3008 87:00.0 LSI SAS3008 This works fine with Xen version 4.18.4_pre1. However, when trying to update to 4.19, this fails. Checking the output during boot, I think I found something. But my knowledge is insufficient to figure out what is causing what I am seeing and how to fix this. >From the below (where I only focus on the 2 NVMe drives), it is similar to the succesfull boot up until it tries to "claiming resource 0000:84:00.0/0". At which point sysfs fails because the entry for "84" is already present. The SAS drives appear be dones correctly, but am unable to confirm this as the NVMEs are required for a succesful boot. For completeness, I have attached the output for the failed boot, a normal succesfull boot (using 4.18.4_pre1) and my xl.conf (which might need adjusting) === (output for just the NVME devices) === pci_bus 0000:83: root bus resource [io 0x0000-0xffff] pci_bus 0000:83: root bus resource [mem 0x00000000-0x3fffffffffff] pci_bus 0000:83: root bus resource [bus 00-ff] pci 0000:83:00.0: [144d:a809] type 00 class 0x010802 PCIe Endpoint pci 0000:83:00.0: BAR 0 [mem 0xfbc00000-0xfbc03fff 64bit] pcifront pci-0: claiming resource 0000:83:00.0/0 pcifront pci-0: Creating PCI Frontend Bus 0000:84 pcifront pci-0: PCI host bridge to bus 0000:84 pci_bus 0000:84: root bus resource [io 0x0000-0xffff] pci_bus 0000:84: root bus resource [mem 0x00000000-0x3fffffffffff] pci_bus 0000:84: busn_res: can not insert [bus 84-ff] under domain [bus 00-ff] (conflicts with (null) [bus 83-ff]) pci_bus 0000:84: root bus resource [bus 00-ff] pci 0000:84:00.0: [144d:a809] type 00 class 0x010802 PCIe Endpoint pci 0000:84:00.0: BAR 0 [mem 0xfbb00000-0xfbb03fff 64bit] pcifront pci-0: claiming resource 0000:84:00.0/0 sysfs: cannot create duplicate filename '/devices/pci-0/ pci0000:84/0000:84:00.0/resource0' CPU: 2 UID: 0 PID: 39 Comm: xenwatch Not tainted 6.12.21-gentoo-generic #1 Call Trace: dump_stack_lvl+0x56/0x80 sysfs_warn_dup+0x51/0x60 sysfs_add_bin_file_mode_ns+0x8a/0xa0 sysfs_create_bin_file+0x5e/0x80 pci_create_attr+0xfc/0x140 pci_create_resource_files+0x30/0x90 pci_bus_add_device+0x26/0x80 pci_bus_add_devices+0x27/0x60 pcifront_rescan_root+0x18a/0x220 pcifront_connect+0x117/0x170 ? xenbus_read_driver_state+0x32/0x60 ? xenbus_otherend_changed+0x49/0xa0 ? __pfx_xenwatch_thread+0x10/0x10 xenwatch_thread+0xf6/0x130 ? __pfx_autoremove_wake_function+0x10/0x10 kthread+0xea/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x1f/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 === --nextPart13775105.uLZWGnKmhe Content-Disposition: attachment; filename="xl_config.txt" Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8"; name="xl_config.txt" name = "san1" kernel = "/opt/local/pvgrub2/grub-x86_64-xen.bin" memory = 98304 maxmem = 98304 vcpus = 4 pool = "Pool-storage" cpus = ["20","21","22","23"] vif = [ 'mac=00:16:3e:16:10:3d, bridge=bradm', 'mac=00:16:3e:16:15:3d, bridge=brstr'] disk = [ 'phy:/dev/zvol/zhost/os/services/san1/root,xvda1,rw', 'phy:/dev/zvol/zhost/os/services/san1/home,xvda2,rw', 'phy:/dev/zvol/zhost/os/services/san1/var,xvda3,rw', 'phy:/dev/zvol/zhost/swap/san1,xvda4,rw'] # (83:00:0) = NVMe 3 # (84:00.0) = NVMe 4 # (86:00.0) = HBA 1 # (87:00.0) = HBA 2 pci = [ '83:00.0,permissive=1', '84:00.0,permissive=1', '86:00.0,permissive=1', '87:00.0,permissive=1'] driver_domain=1 --nextPart13775105.uLZWGnKmhe Content-Disposition: attachment; filename="Boot_Succesfull.txt" Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8"; name="Boot_Succesfull.txt" Parsing config from /etc/xen/domains/san1/san1 Welcome to GRUB!  [ grub.cfg 304B 100% 1.95KiB/s ] Booting `Default' Linux version 6.12.21-gentoo-generic (root@san1) (gcc (Gentoo Hardened 14.2.1_p20241221 p7) 14.2.1 20241221, GNU ld (Gentoo 2.44 p1) 2.44.0) #1 SMP PREEMPT_DYNAMIC Tue Apr 29 10:13:56 UTC 2025 Command line: root=/dev/xvda1 nfs.callback_tcpport=32764 lockd.nlm_udpport=32768 lockd.nlm_tcpport=32768 KERNEL supported cpus: Intel GenuineIntel AMD AuthenticAMD Hygon HygonGenuine zhaoxin Shanghai ACPI in unprivileged domain disabled Released 0 page(s) BIOS-provided physical RAM map: Xen: [mem 0x0000000000000000-0x000000000009ffff] usable Xen: [mem 0x00000000000a0000-0x00000000000fffff] reserved Xen: [mem 0x0000000000100000-0x0000000078da2fff] usable Xen: [mem 0x0000000078da3000-0x00000000795bbfff] reserved Xen: [mem 0x00000000795bc000-0x000000007969ffff] unusable Xen: [mem 0x00000000796a0000-0x0000000079c1efff] ACPI NVS Xen: [mem 0x0000000079c1f000-0x000000007bcf6fff] reserved Xen: [mem 0x000000007bcf7000-0x000000007bcf7fff] unusable Xen: [mem 0x000000007bcf8000-0x000000007bd7dfff] reserved Xen: [mem 0x000000007bd7e000-0x000000007bffffff] unusable Xen: [mem 0x000000007c000000-0x000000008fffffff] reserved Xen: [mem 0x00000000c7ffc000-0x00000000c7ffcfff] reserved Xen: [mem 0x00000000fbffc000-0x00000000fbffcfff] reserved Xen: [mem 0x00000000fec00000-0x00000000fec01fff] reserved Xen: [mem 0x00000000fec40000-0x00000000fec40fff] reserved Xen: [mem 0x00000000fed1c000-0x00000000fed44fff] reserved Xen: [mem 0x00000000fee00000-0x00000000feefffff] reserved Xen: [mem 0x00000000ff000000-0x00000000ffffffff] reserved Xen: [mem 0x0000000100000000-0x000000188725cfff] usable NX (Execute Disable) protection: active APIC: Static calls initialized DMI not present or invalid. Hypervisor detected: Xen PV Xen PV: Detected 4 vCPUS tsc: Fast TSC calibration failed tsc: Detected 2399.998 MHz processor last_pfn = 0x188725d max_arch_pfn = 0x400000000 MTRR map: 0 entries (0 fixed + 0 variable; max 0), built from 0 variable MTRRs MTRRs set to read-only x86/PAT: PAT support disabled because CONFIG_X86_PAT is disabled in the kernel. x86/PAT: Configuration [0-7]: WB WT UC- UC WC WP UC UC last_pfn = 0x78da3 max_arch_pfn = 0x400000000 Kernel/User page tables isolation: disabled on XEN PV. Zone ranges: DMA [mem 0x0000000000001000-0x0000000000ffffff] DMA32 [mem 0x0000000001000000-0x00000000ffffffff] Normal [mem 0x0000000100000000-0x000000188725cfff] Movable zone start for each node Early memory node ranges node 0: [mem 0x0000000000001000-0x000000000009ffff] node 0: [mem 0x0000000000100000-0x0000000078da2fff] node 0: [mem 0x0000000100000000-0x000000188725cfff] Initmem setup node 0 [mem 0x0000000000001000-0x000000188725cfff] On node 0, zone DMA: 1 pages in unavailable ranges On node 0, zone DMA: 96 pages in unavailable ranges On node 0, zone Normal: 29277 pages in unavailable ranges On node 0, zone Normal: 3491 pages in unavailable ranges p2m virtual area at (____ptrval____), size is c600000 Remapped 553565 page(s) Remapped 0 non-RAM page(s) CPU topo: Max. logical packages: 1 CPU topo: Max. logical dies: 1 CPU topo: Max. dies per package: 1 CPU topo: Max. threads per core: 2 CPU topo: Num. cores per package: 2 CPU topo: Num. threads per package: 4 CPU topo: Allowing 4 present CPUs plus 0 hotplug CPUs [mem 0x90000000-0xc7ffbfff] available for PCI devices Booting kernel on Xen Xen version: 4.18.4-pre (preserve-AD) clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns setup_percpu: NR_CPUS:64 nr_cpumask_bits:4 nr_cpu_ids:4 nr_node_ids:1 percpu: Embedded 57 pages/cpu s195928 r8192 d29352 u524288 PV qspinlock hash table entries: 256 (order: 0, 4096 bytes, linear) Kernel command line: root=/dev/xvda1 nfs.callback_tcpport=32764 lockd.nlm_udpport=32768 lockd.nlm_tcpport=32768 random: crng init done Dentry cache hash table entries: 8388608 (order: 14, 67108864 bytes, linear) Inode-cache hash table entries: 4194304 (order: 13, 33554432 bytes, linear) Built 1 zonelists, mobility grouping on. Total pages: 25165727 mem auto-init: stack:off, heap alloc:off, heap free:off software IO TLB: area num 4. SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 Dynamic Preempt: voluntary rcu: Preemptible hierarchical RCU implementation. rcu: RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=4. Trampoline variant of Tasks RCU enabled. rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies. rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 RCU Tasks: Setting shift to 2 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=4. Using NULL legacy PIC NR_IRQS: 4352, nr_irqs: 80, preallocated irqs: 0 xen:events: Using FIFO-based ABI rcu: srcu_init: Setting srcu_struct sizes based on contention. Console: colour dummy device 80x25 printk: legacy console [tty0] enabled printk: legacy console [hvc0] enabled clocksource: xen: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns installing Xen timer for CPU 0 APIC: Switched APIC routing to: Xen PV clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x229835b7123, max_idle_ns: 440795242976 ns Calibrating delay loop (skipped), value calculated using timer frequency.. 4799.99 BogoMIPS (lpj=23999980) Last level iTLB entries: 4KB 64, 2MB 8, 4MB 8 Last level dTLB entries: 4KB 64, 2MB 32, 4MB 32, 1GB 4 Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization Spectre V2 : Mitigation: Retpolines Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch Spectre V2 : Spectre v2 / SpectreRSB : Filling RSB on VMEXIT Spectre V2 : Enabling Restricted Speculation for firmware calls Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier Spectre V2 : User space: Mitigation: STIBP via prctl Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl MDS: Mitigation: Clear CPU buffers TAA: Mitigation: Clear CPU buffers MMIO Stale Data: Vulnerable: Clear CPU buffers attempted, no microcode x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. Freeing SMP alternatives memory: 24K pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear) Mountpoint-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear) cpu 0 spinlock event irq 1 VPMU disabled by hypervisor. Performance Events: unsupported p6 CPU model 79 no PMU driver, software events only. signal: max sigframe size: 1776 rcu: Hierarchical SRCU implementation. rcu: Max phase no-delay instances is 1000. Timer migration: 1 hierarchy levels; 8 children per group; 1 crossnode level smp: Bringing up secondary CPUs ... installing Xen timer for CPU 2 cpu 2 spinlock event irq 11 installing Xen timer for CPU 1 installing Xen timer for CPU 3 cpu 1 spinlock event irq 22 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. 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. 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. cpu 3 spinlock event irq 23 smp: Brought up 1 node, 4 CPUs Memory: 98485732K/100662908K available (12288K kernel code, 3568K rwdata, 5024K rodata, 2276K init, 2376K bss, 2168812K reserved, 0K cma-reserved) devtmpfs: initialized clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns futex hash table entries: 1024 (order: 4, 65536 bytes, linear) NET: Registered PF_NETLINK/PF_ROUTE protocol family xen:grant_table: Grant tables using version 1 layout Grant table initialized thermal_sys: Registered thermal governor 'step_wise' thermal_sys: Registered thermal governor 'user_space' dca service started, version 1.12.1 PCI: setting up Xen PCI frontend stub cryptd: max_cpu_qlen set to 1000 ACPI: Interpreter disabled. xen:balloon: Initialising balloon driver iommu: Default domain type: Translated iommu: DMA domain TLB invalidation policy: lazy mode SCSI subsystem initialized pps_core: LinuxPPS API ver. 1 registered pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti PTP clock support registered PCI: System does not support PCI vgaarb: loaded clocksource: Switched to clocksource xen VFS: Disk quotas dquot_6.6.0 VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes) pnp: PnP ACPI: disabled NET: Registered PF_INET protocol family IP idents hash table entries: 262144 (order: 9, 2097152 bytes, linear) tcp_listen_portaddr_hash hash table entries: 65536 (order: 8, 1048576 bytes, linear) Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear) TCP established hash table entries: 524288 (order: 10, 4194304 bytes, linear) TCP bind hash table entries: 65536 (order: 9, 2097152 bytes, linear) TCP: Hash tables configured (established 524288 bind 65536) UDP hash table entries: 65536 (order: 9, 2097152 bytes, linear) UDP-Lite hash table entries: 65536 (order: 9, 2097152 bytes, linear) NET: Registered PF_UNIX/PF_LOCAL protocol family RPC: Registered named UNIX socket transport module. RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp-with-tls transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. PCI: CLS 0 bytes, default 64 PCI-DMA: Using software bounce buffering for IO (SWIOTLB) software IO TLB: mapped [mem 0x000000187d000000-0x0000001881000000] (64MB) clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x229835b7123, max_idle_ns: 440795242976 ns workingset: timestamp_bits=46 max_order=25 bucket_order=0 DLM installed NFS: Registering the id_resolver key type Key type id_resolver registered Key type id_legacy registered fuse: init (API version 7.41) JFS: nTxBlock = 8192, nTxLock = 65536 SGI XFS with ACLs, security attributes, realtime, quota, no debug enabled Key type asymmetric registered Block layer SCSI generic (bsg) driver version 0.4 loaded (major 250) io scheduler mq-deadline registered io scheduler kyber registered uvesafb: failed to execute /sbin/v86d uvesafb: make sure that the v86d helper is installed and executable uvesafb: Getting VBE info block failed (eax=0x4f00, err=-2) uvesafb: vbe_init() failed with -22 uvesafb uvesafb.0: probe with driver uvesafb failed with error -22 ioatdma: Intel(R) QuickData Technology Driver 5.00 xen:xen_evtchn: Event-channel device installed Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled Non-volatile memory driver v1.3 Linux agpgart interface v0.103 pcifront pci-0: Installing PCI frontend pcifront pci-0: Creating PCI Frontend Bus 0000:83 pcifront pci-0: PCI host bridge to bus 0000:83 pci_bus 0000:83: root bus resource [io 0x0000-0xffff] pci_bus 0000:83: root bus resource [mem 0x00000000-0x3fffffffffff] pci_bus 0000:83: root bus resource [bus 00-ff] pci 0000:83:00.0: [144d:a809] type 00 class 0x010802 PCIe Endpoint loop: module loaded pci 0000:83:00.0: BAR 0 [mem 0xfbc00000-0xfbc03fff 64bit] SCSI Media Changer driver v0.25 xen_netfront: Initialising Xen virtual ethernet driver i8042: PNP: No PS/2 controller found. i8042: Probing ports directly. pcifront pci-0: claiming resource 0000:83:00.0/0 i8042: No controller found pcifront pci-0: Creating PCI Frontend Bus 0000:84 pcifront pci-0: PCI host bridge to bus 0000:84 pci_bus 0000:84: root bus resource [io 0x0000-0xffff] pci_bus 0000:84: root bus resource [mem 0x00000000-0x3fffffffffff] pci_bus 0000:84: busn_res: can not insert [bus 84-ff] under domain [bus 00-ff] (conflicts with (null) [bus 83-ff]) pci_bus 0000:84: root bus resource [bus 00-ff] mousedev: PS/2 mouse device common for all mice device-mapper: uevent: version 1.0.3 pci 0000:84:00.0: [144d:a809] type 00 class 0x010802 PCIe Endpoint device-mapper: ioctl: 4.48.0-ioctl (2023-03-01) initialised: dm-devel@lists.linux.dev device-mapper: multipath round-robin: version 1.2.0 loaded intel_pstate: CPU model not supported hid: raw HID events driver (C) Jiri Kosina Initializing XFRM netlink socket NET: Registered PF_PACKET protocol family sctp: Hash tables configured (bind 2048/2048) pci 0000:84:00.0: BAR 0 [mem 0xfbb00000-0xfbb03fff 64bit] Key type dns_resolver registered pcifront pci-0: claiming resource 0000:84:00.0/0 pcifront pci-0: Creating PCI Frontend Bus 0000:86 pcifront pci-0: PCI host bridge to bus 0000:86 pci_bus 0000:86: root bus resource [io 0x0000-0xffff] pci_bus 0000:86: root bus resource [mem 0x00000000-0x3fffffffffff] pci_bus 0000:86: busn_res: can not insert [bus 86-ff] under domain [bus 00-ff] (conflicts with (null) [bus 83-ff]) pci_bus 0000:86: root bus resource [bus 00-ff] pci 0000:86:00.0: [1000:0097] type 00 class 0x010700 PCIe Endpoint IPI shorthand broadcast: enabled pci 0000:86:00.0: BAR 0 [io 0xf000-0xf0ff] pci 0000:86:00.0: BAR 1 [mem 0xfba40000-0xfba4ffff 64bit] pci 0000:86:00.0: BAR 3 [mem 0xfba00000-0xfba3ffff 64bit] pci 0000:86:00.0: ROM [mem 0xfb900000-0xfb9fffff pref] pci 0000:86:00.0: supports D1 D2 pci 0000:86:00.0: 31.504 Gb/s available PCIe bandwidth, limited by 8.0 GT/s PCIe x4 link at 0000:86:00.0 (capable of 63.008 Gb/s with 8.0 GT/s PCIe x8 link) sched_clock: Marking stable (3911602419, 705114)->(3914816421, -2508888) pcifront pci-0: claiming resource 0000:86:00.0/0 pcifront pci-0: claiming resource 0000:86:00.0/1 pcifront pci-0: claiming resource 0000:86:00.0/3 pcifront pci-0: claiming resource 0000:86:00.0/6 registered taskstats version 1 pcifront pci-0: Creating PCI Frontend Bus 0000:87 pcifront pci-0: PCI host bridge to bus 0000:87 pci_bus 0000:87: root bus resource [io 0x0000-0xffff] pci_bus 0000:87: root bus resource [mem 0x00000000-0x3fffffffffff] pci_bus 0000:87: busn_res: can not insert [bus 87-ff] under domain [bus 00-ff] (conflicts with (null) [bus 83-ff]) pci_bus 0000:87: root bus resource [bus 00-ff] pci 0000:87:00.0: [1000:0097] type 00 class 0x010700 PCIe Endpoint pci 0000:87:00.0: BAR 0 [io 0xe000-0xe0ff] pci 0000:87:00.0: BAR 1 [mem 0xfb840000-0xfb84ffff 64bit] pci 0000:87:00.0: BAR 3 [mem 0xfb800000-0xfb83ffff 64bit] pci 0000:87:00.0: ROM [mem 0xfb700000-0xfb7fffff pref] pci 0000:87:00.0: supports D1 D2 pci 0000:87:00.0: 31.504 Gb/s available PCIe bandwidth, limited by 8.0 GT/s PCIe x4 link at 0000:87:00.0 (capable of 63.008 Gb/s with 8.0 GT/s PCIe x8 link) pcifront pci-0: claiming resource 0000:87:00.0/0 pcifront pci-0: claiming resource 0000:87:00.0/1 pcifront pci-0: claiming resource 0000:87:00.0/3 pcifront pci-0: claiming resource 0000:87:00.0/6 xen_netfront: backend supports XDP headroom xen_netfront: backend supports XDP headroom blkfront: xvda1: flush diskcache: enabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled blkfront: xvda2: flush diskcache: enabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled blkfront: xvda3: flush diskcache: enabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled blkfront: xvda4: flush diskcache: enabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled clk: Disabling unused clocks EXT4-fs (xvda1): mounted filesystem f46e14cc-db5e-410f-9c70-9b9eb1498be9 r/w with ordered data mode. Quota mode: none. VFS: Mounted root (ext4 filesystem) on device 202:1. devtmpfs: mounted Freeing unused kernel image (initmem) memory: 2276K Write protecting the kernel read-only data: 18432k Freeing unused kernel image (rodata/data gap) memory: 1120K rodata_test: all tests were successful Run /sbin/init as init process INIT: version 3.09 booting --nextPart13775105.uLZWGnKmhe Content-Disposition: attachment; filename="Boot_Failed.txt" Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8"; name="Boot_Failed.txt" Parsing config from /etc/xen/domains/san1/san1 Welcome to GRUB!  [ grub.cfg 304B 100% 2.01KiB/s ] Booting `Default' Linux version 6.12.21-gentoo-generic (root@san1) (gcc (Gentoo Hardened 14.2.1_p20241221 p7) 14.2.1 20241221, GNU ld (Gentoo 2.44 p1) 2.44.0) #1 SMP PREEMPT_DYNAMIC Tue Apr 29 10:13:56 UTC 2025 Command line: root=/dev/xvda1 nfs.callback_tcpport=32764 lockd.nlm_udpport=32768 lockd.nlm_tcpport=32768 KERNEL supported cpus: Intel GenuineIntel AMD AuthenticAMD Hygon HygonGenuine zhaoxin Shanghai ACPI in unprivileged domain disabled Released 0 page(s) BIOS-provided physical RAM map: Xen: [mem 0x0000000000000000-0x000000000009ffff] usable Xen: [mem 0x00000000000a0000-0x00000000000fffff] reserved Xen: [mem 0x0000000000100000-0x0000000078da2fff] usable Xen: [mem 0x0000000078da3000-0x00000000795bbfff] reserved Xen: [mem 0x00000000795bc000-0x000000007969ffff] unusable Xen: [mem 0x00000000796a0000-0x0000000079c1efff] ACPI NVS Xen: [mem 0x0000000079c1f000-0x000000007bcf6fff] reserved Xen: [mem 0x000000007bcf7000-0x000000007bcf7fff] unusable Xen: [mem 0x000000007bcf8000-0x000000007bd7dfff] reserved Xen: [mem 0x000000007bd7e000-0x000000007bffffff] unusable Xen: [mem 0x000000007c000000-0x000000008fffffff] reserved Xen: [mem 0x00000000c7ffc000-0x00000000c7ffcfff] reserved Xen: [mem 0x00000000fbffc000-0x00000000fbffcfff] reserved Xen: [mem 0x00000000fec00000-0x00000000fec01fff] reserved Xen: [mem 0x00000000fec40000-0x00000000fec40fff] reserved Xen: [mem 0x00000000fed1c000-0x00000000fed44fff] reserved Xen: [mem 0x00000000fee00000-0x00000000feefffff] reserved Xen: [mem 0x00000000ff000000-0x00000000ffffffff] reserved Xen: [mem 0x0000000100000000-0x000000188725cfff] usable NX (Execute Disable) protection: active APIC: Static calls initialized DMI not present or invalid. Hypervisor detected: Xen PV Xen PV: Detected 4 vCPUS tsc: Fast TSC calibration failed tsc: Detected 2399.994 MHz processor last_pfn = 0x188725d max_arch_pfn = 0x400000000 MTRR map: 0 entries (0 fixed + 0 variable; max 0), built from 0 variable MTRRs MTRRs set to read-only x86/PAT: PAT support disabled because CONFIG_X86_PAT is disabled in the kernel. x86/PAT: Configuration [0-7]: WB WT UC- UC WC WP UC UC last_pfn = 0x78da3 max_arch_pfn = 0x400000000 Kernel/User page tables isolation: disabled on XEN PV. Zone ranges: DMA [mem 0x0000000000001000-0x0000000000ffffff] DMA32 [mem 0x0000000001000000-0x00000000ffffffff] Normal [mem 0x0000000100000000-0x000000188725cfff] Movable zone start for each node Early memory node ranges node 0: [mem 0x0000000000001000-0x000000000009ffff] node 0: [mem 0x0000000000100000-0x0000000078da2fff] node 0: [mem 0x0000000100000000-0x000000188725cfff] Initmem setup node 0 [mem 0x0000000000001000-0x000000188725cfff] On node 0, zone DMA: 1 pages in unavailable ranges On node 0, zone DMA: 96 pages in unavailable ranges On node 0, zone Normal: 29277 pages in unavailable ranges On node 0, zone Normal: 3491 pages in unavailable ranges p2m virtual area at (____ptrval____), size is c600000 Remapped 553565 page(s) Remapped 0 non-RAM page(s) CPU topo: Max. logical packages: 1 CPU topo: Max. logical dies: 1 CPU topo: Max. dies per package: 1 CPU topo: Max. threads per core: 2 CPU topo: Num. cores per package: 2 CPU topo: Num. threads per package: 4 CPU topo: Allowing 4 present CPUs plus 0 hotplug CPUs [mem 0x90000000-0xc7ffbfff] available for PCI devices Booting kernel on Xen Xen version: 4.19.1 (preserve-AD) clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns setup_percpu: NR_CPUS:64 nr_cpumask_bits:4 nr_cpu_ids:4 nr_node_ids:1 percpu: Embedded 57 pages/cpu s195928 r8192 d29352 u524288 PV qspinlock hash table entries: 256 (order: 0, 4096 bytes, linear) Kernel command line: root=/dev/xvda1 nfs.callback_tcpport=32764 lockd.nlm_udpport=32768 lockd.nlm_tcpport=32768 random: crng init done Dentry cache hash table entries: 8388608 (order: 14, 67108864 bytes, linear) Inode-cache hash table entries: 4194304 (order: 13, 33554432 bytes, linear) Built 1 zonelists, mobility grouping on. Total pages: 25165727 mem auto-init: stack:off, heap alloc:off, heap free:off software IO TLB: area num 4. SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 Dynamic Preempt: voluntary rcu: Preemptible hierarchical RCU implementation. rcu: RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=4. Trampoline variant of Tasks RCU enabled. rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies. rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 RCU Tasks: Setting shift to 2 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=4. Using NULL legacy PIC NR_IRQS: 4352, nr_irqs: 80, preallocated irqs: 0 xen:events: Using FIFO-based ABI rcu: srcu_init: Setting srcu_struct sizes based on contention. Console: colour dummy device 80x25 printk: legacy console [tty0] enabled printk: legacy console [hvc0] enabled clocksource: xen: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns installing Xen timer for CPU 0 APIC: Switched APIC routing to: Xen PV clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x229831eaaf8, max_idle_ns: 440795283826 ns Calibrating delay loop (skipped), value calculated using timer frequency.. 4799.98 BogoMIPS (lpj=23999940) Last level iTLB entries: 4KB 64, 2MB 8, 4MB 8 Last level dTLB entries: 4KB 64, 2MB 32, 4MB 32, 1GB 4 Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization Spectre V2 : Mitigation: Retpolines Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch Spectre V2 : Spectre v2 / SpectreRSB : Filling RSB on VMEXIT Spectre V2 : Enabling Restricted Speculation for firmware calls Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier Spectre V2 : User space: Mitigation: STIBP via prctl Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl MDS: Mitigation: Clear CPU buffers TAA: Mitigation: Clear CPU buffers MMIO Stale Data: Vulnerable: Clear CPU buffers attempted, no microcode x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. Freeing SMP alternatives memory: 24K pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear) Mountpoint-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear) cpu 0 spinlock event irq 1 VPMU disabled by hypervisor. Performance Events: unsupported p6 CPU model 79 no PMU driver, software events only. signal: max sigframe size: 1776 rcu: Hierarchical SRCU implementation. rcu: Max phase no-delay instances is 1000. Timer migration: 1 hierarchy levels; 8 children per group; 1 crossnode level smp: Bringing up secondary CPUs ... installing Xen timer for CPU 2 cpu 2 spinlock event irq 11 installing Xen timer for CPU 1 installing Xen timer for CPU 3 cpu 1 spinlock event irq 22 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. 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. 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. cpu 3 spinlock event irq 23 smp: Brought up 1 node, 4 CPUs Memory: 98485732K/100662908K available (12288K kernel code, 3568K rwdata, 5024K rodata, 2276K init, 2376K bss, 2168812K reserved, 0K cma-reserved) devtmpfs: initialized clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns futex hash table entries: 1024 (order: 4, 65536 bytes, linear) NET: Registered PF_NETLINK/PF_ROUTE protocol family xen:grant_table: Grant tables using version 1 layout Grant table initialized thermal_sys: Registered thermal governor 'step_wise' thermal_sys: Registered thermal governor 'user_space' dca service started, version 1.12.1 PCI: setting up Xen PCI frontend stub cryptd: max_cpu_qlen set to 1000 ACPI: Interpreter disabled. xen:balloon: Initialising balloon driver iommu: Default domain type: Translated iommu: DMA domain TLB invalidation policy: lazy mode SCSI subsystem initialized pps_core: LinuxPPS API ver. 1 registered pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti PTP clock support registered PCI: System does not support PCI vgaarb: loaded clocksource: Switched to clocksource xen VFS: Disk quotas dquot_6.6.0 VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes) pnp: PnP ACPI: disabled NET: Registered PF_INET protocol family IP idents hash table entries: 262144 (order: 9, 2097152 bytes, linear) tcp_listen_portaddr_hash hash table entries: 65536 (order: 8, 1048576 bytes, linear) Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear) TCP established hash table entries: 524288 (order: 10, 4194304 bytes, linear) TCP bind hash table entries: 65536 (order: 9, 2097152 bytes, linear) TCP: Hash tables configured (established 524288 bind 65536) UDP hash table entries: 65536 (order: 9, 2097152 bytes, linear) UDP-Lite hash table entries: 65536 (order: 9, 2097152 bytes, linear) NET: Registered PF_UNIX/PF_LOCAL protocol family RPC: Registered named UNIX socket transport module. RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp-with-tls transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. PCI: CLS 0 bytes, default 64 PCI-DMA: Using software bounce buffering for IO (SWIOTLB) software IO TLB: mapped [mem 0x000000187d000000-0x0000001881000000] (64MB) clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x229831eaaf8, max_idle_ns: 440795283826 ns workingset: timestamp_bits=46 max_order=25 bucket_order=0 DLM installed NFS: Registering the id_resolver key type Key type id_resolver registered Key type id_legacy registered fuse: init (API version 7.41) JFS: nTxBlock = 8192, nTxLock = 65536 SGI XFS with ACLs, security attributes, realtime, quota, no debug enabled Key type asymmetric registered Block layer SCSI generic (bsg) driver version 0.4 loaded (major 250) io scheduler mq-deadline registered io scheduler kyber registered uvesafb: failed to execute /sbin/v86d uvesafb: make sure that the v86d helper is installed and executable uvesafb: Getting VBE info block failed (eax=0x4f00, err=-2) uvesafb: vbe_init() failed with -22 uvesafb uvesafb.0: probe with driver uvesafb failed with error -22 ioatdma: Intel(R) QuickData Technology Driver 5.00 xen:xen_evtchn: Event-channel device installed Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled pcifront pci-0: Installing PCI frontend Non-volatile memory driver v1.3 Linux agpgart interface v0.103 pcifront pci-0: Creating PCI Frontend Bus 0000:83 pcifront pci-0: PCI host bridge to bus 0000:83 pci_bus 0000:83: root bus resource [io 0x0000-0xffff] pci_bus 0000:83: root bus resource [mem 0x00000000-0x3fffffffffff] pci_bus 0000:83: root bus resource [bus 00-ff] pci 0000:83:00.0: [144d:a809] type 00 class 0x010802 PCIe Endpoint pci 0000:83:00.0: BAR 0 [mem 0xfbc00000-0xfbc03fff 64bit] loop: module loaded SCSI Media Changer driver v0.25 xen_netfront: Initialising Xen virtual ethernet driver i8042: PNP: No PS/2 controller found. i8042: Probing ports directly. i8042: No controller found mousedev: PS/2 mouse device common for all mice device-mapper: uevent: version 1.0.3 device-mapper: ioctl: 4.48.0-ioctl (2023-03-01) initialised: dm-devel@lists.linux.dev device-mapper: multipath round-robin: version 1.2.0 loaded intel_pstate: CPU model not supported hid: raw HID events driver (C) Jiri Kosina Initializing XFRM netlink socket NET: Registered PF_PACKET protocol family sctp: Hash tables configured (bind 2048/2048) Key type dns_resolver registered pcifront pci-0: claiming resource 0000:83:00.0/0 pcifront pci-0: Creating PCI Frontend Bus 0000:84 pcifront pci-0: PCI host bridge to bus 0000:84 pci_bus 0000:84: root bus resource [io 0x0000-0xffff] pci_bus 0000:84: root bus resource [mem 0x00000000-0x3fffffffffff] pci_bus 0000:84: busn_res: can not insert [bus 84-ff] under domain [bus 00-ff] (conflicts with (null) [bus 83-ff]) pci_bus 0000:84: root bus resource [bus 00-ff] pci 0000:84:00.0: [144d:a809] type 00 class 0x010802 PCIe Endpoint pci 0000:84:00.0: BAR 0 [mem 0xfbb00000-0xfbb03fff 64bit] IPI shorthand broadcast: enabled sched_clock: Marking stable (3910019036, 711046)->(3920862979, -10132897) registered taskstats version 1 pcifront pci-0: claiming resource 0000:84:00.0/0 sysfs: cannot create duplicate filename '/devices/pci-0/pci0000:84/0000:84:00.0/resource0' CPU: 2 UID: 0 PID: 39 Comm: xenwatch Not tainted 6.12.21-gentoo-generic #1 Call Trace: dump_stack_lvl+0x56/0x80 sysfs_warn_dup+0x51/0x60 sysfs_add_bin_file_mode_ns+0x8a/0xa0 sysfs_create_bin_file+0x5e/0x80 pci_create_attr+0xfc/0x140 pci_create_resource_files+0x30/0x90 pci_bus_add_device+0x26/0x80 pci_bus_add_devices+0x27/0x60 pcifront_rescan_root+0x18a/0x220 pcifront_connect+0x117/0x170 ? xenbus_read_driver_state+0x32/0x60 ? xenbus_otherend_changed+0x49/0xa0 ? __pfx_xenwatch_thread+0x10/0x10 xenwatch_thread+0xf6/0x130 ? __pfx_autoremove_wake_function+0x10/0x10 kthread+0xea/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x1f/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 pcifront pci-0: Creating PCI Frontend Bus 0000:86 pcifront pci-0: PCI host bridge to bus 0000:86 pci_bus 0000:86: root bus resource [io 0x0000-0xffff] pci_bus 0000:86: root bus resource [mem 0x00000000-0x3fffffffffff] pci_bus 0000:86: busn_res: can not insert [bus 86-ff] under domain [bus 00-ff] (conflicts with (null) [bus 83-ff]) pci_bus 0000:86: root bus resource [bus 00-ff] pci 0000:86:00.0: [1000:0097] type 00 class 0x010700 PCIe Endpoint pci 0000:86:00.0: BAR 0 [io 0xf000-0xf0ff] pci 0000:86:00.0: BAR 1 [mem 0xfba40000-0xfba4ffff 64bit] pci 0000:86:00.0: BAR 3 [mem 0xfba00000-0xfba3ffff 64bit] pci 0000:86:00.0: ROM [mem 0xfb900000-0xfb9fffff pref] pci 0000:86:00.0: supports D1 D2 pci 0000:86:00.0: 31.504 Gb/s available PCIe bandwidth, limited by 8.0 GT/s PCIe x4 link at 0000:86:00.0 (capable of 63.008 Gb/s with 8.0 GT/s PCIe x8 link) pcifront pci-0: claiming resource 0000:86:00.0/0 pcifront pci-0: claiming resource 0000:86:00.0/1 pcifront pci-0: claiming resource 0000:86:00.0/3 pcifront pci-0: claiming resource 0000:86:00.0/6 pcifront pci-0: Creating PCI Frontend Bus 0000:87 pcifront pci-0: PCI host bridge to bus 0000:87 pci_bus 0000:87: root bus resource [io 0x0000-0xffff] pci_bus 0000:87: root bus resource [mem 0x00000000-0x3fffffffffff] pci_bus 0000:87: busn_res: can not insert [bus 87-ff] under domain [bus 00-ff] (conflicts with (null) [bus 83-ff]) pci_bus 0000:87: root bus resource [bus 00-ff] pci 0000:87:00.0: [1000:0097] type 00 class 0x010700 PCIe Endpoint pci 0000:87:00.0: BAR 0 [io 0xe000-0xe0ff] pci 0000:87:00.0: BAR 1 [mem 0xfb840000-0xfb84ffff 64bit] pci 0000:87:00.0: BAR 3 [mem 0xfb800000-0xfb83ffff 64bit] pci 0000:87:00.0: ROM [mem 0xfb700000-0xfb7fffff pref] pci 0000:87:00.0: supports D1 D2 pci 0000:87:00.0: 31.504 Gb/s available PCIe bandwidth, limited by 8.0 GT/s PCIe x4 link at 0000:87:00.0 (capable of 63.008 Gb/s with 8.0 GT/s PCIe x8 link) pcifront pci-0: claiming resource 0000:87:00.0/0 pcifront pci-0: claiming resource 0000:87:00.0/1 pcifront pci-0: claiming resource 0000:87:00.0/3 pcifront pci-0: claiming resource 0000:87:00.0/6 xen_netfront: backend supports XDP headroom xen_netfront: backend supports XDP headroom blkfront: xvda1: flush diskcache: enabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled blkfront: xvda2: flush diskcache: enabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled blkfront: xvda3: flush diskcache: enabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled blkfront: xvda4: flush diskcache: enabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled clk: Disabling unused clocks EXT4-fs (xvda1): 14 orphan inodes deleted EXT4-fs (xvda1): recovery complete EXT4-fs (xvda1): mounted filesystem f46e14cc-db5e-410f-9c70-9b9eb1498be9 r/w with ordered data mode. Quota mode: none. VFS: Mounted root (ext4 filesystem) on device 202:1. devtmpfs: mounted Freeing unused kernel image (initmem) memory: 2276K Write protecting the kernel read-only data: 18432k Freeing unused kernel image (rodata/data gap) memory: 1120K rodata_test: all tests were successful Run /sbin/init as init process INIT: version 3.09 booting --nextPart13775105.uLZWGnKmhe-- From xen-devel-bounces@lists.xenproject.org Mon Jun 02 13:37:02 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 13:37:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003321.1382854 (Exim 4.92) (envelope-from ) id 1uM5LR-0000O3-DF; Mon, 02 Jun 2025 13:36:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003321.1382854; Mon, 02 Jun 2025 13:36:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uM5LR-0000Nw-A3; Mon, 02 Jun 2025 13:36:53 +0000 Received: by outflank-mailman (input) for mailman id 1003321; Mon, 02 Jun 2025 13:36: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 1uM5LQ-0000AN-S9 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 13:36:52 +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 a39e7a3b-3fb6-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 15:36:51 +0200 (CEST) Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-ad51ef2424bso850932766b.0 for ; Mon, 02 Jun 2025 06:36:51 -0700 (PDT) Received: from rossla-pc.eng.citrite.net ([185.25.67.249]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ada5d82becbsm801962166b.39.2025.06.02.06.36.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 06:36:49 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a39e7a3b-3fb6-11f0-a300-13f23c93f187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1748871410; x=1749476210; darn=lists.xenproject.org; h=content-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=eXyFKt8SkeFv2JRAXt3PYp9ZfiPqxDGxVcFws6/GjMQ=; b=C7S7NmLvXn4Aiavsyg3n9EpbG/w5QwFcli1QncfilI8mGHC49wLHJ/t93944dvjf6A kx6bHqBuOzNfPqMHlMcl5CFuB0k+Fuw4GXtDRnt3snAeXmfY8woiswB8vY+Suyejw5at DLIfOmZEeediUplTaR4aiLj5oqOspaj62hF8U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748871410; x=1749476210; 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=eXyFKt8SkeFv2JRAXt3PYp9ZfiPqxDGxVcFws6/GjMQ=; b=GgnKT5rEbA1QCulOqrVkOEshQMr43bFH1royt6Ov66frSPYsQ1MrwYbeks1FeFusug Q8kVXeG7FF85c4OQrZhixbx6MHpM0LZvAxmMey31R5VTq7xdbG0AqecFMpXDJKZB5PYK UUbsyjSw7JQp+s8is/oI4xwXP0PI6g4KHgBazBQEkpvIJz44bIhU+bxLFbM60z/M/F3N pr5i8+Edqe81u7CrChXnJKtf6q8DPCAcWpzymtakeJ9SSJsEB3OZRKqfOuAPKE3D4ZDU QlWTPd6iG7f4mfsj/DUJNTGWE7ALKND1pgNqB8aY0LPMhxloFyuz2AFSfC9hZaYsfj3V pV9w== X-Gm-Message-State: AOJu0YwY+zYtZm1GgdVYn/CGvFr2/kruQINrMI9kOzPBStf6d3yYb/O7 CYk4VOX59kqA7B7L7aWL0TjVyry0NTG5tJDjQgDqQHTM5SISYWnFz0zZkFqPksmGuruLAAard4Y bR7Q= X-Gm-Gg: ASbGncuyyOXAIzHW53MB+r1Tsa5WJckwCNv77Q3uON1nKKT7dRteN/eoV6r1dCbi9Z3 1Fo4he6oy4ywIORY3/AzoPrJLRt7mNNzB5kgBcE1PXjiPJSsCceYEGdfzWOEN8GESBMJVqHlB85 rCGTqgUP3Kn6U8uZrEQWuz74/rQjKv2pv8M//Gr+iJTr0xU3PC0GOOhf/CCTI64cvCBxA2mqjYr MWV31a7NvpfsqEy5tLjXzTL1C7n1u9NqCXWbDIXzG1+dsyWCZtz7sgMlCSKSsFH7N5tIW4S4U2D N3lQfT7zp72lwnSu6hjN5gOjQty5d2i9Cvc6UdIih90OLiiuu8GJDmltVY8UvcvyHm/RUV7xyEo = X-Google-Smtp-Source: AGHT+IFDR2jTnNkplK5MDSg0EiFkL63MSZQoNcI1lDzXXdOHZRHY4hs4m38UOsREknK3kO+gkCgGBA== X-Received: by 2002:a17:907:9488:b0:ad8:99e7:171 with SMTP id a640c23a62f3a-adb493e28f3mr800031766b.21.1748871410169; Mon, 02 Jun 2025 06:36:50 -0700 (PDT) From: Ross Lagerwall To: xen-devel@lists.xenproject.org Cc: Kevin Lampis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Ross Lagerwall Subject: [PATCH v3 2/5] livepatch: Embed public key in Xen Date: Mon, 2 Jun 2025 14:36:34 +0100 Message-ID: <20250602133639.2871212-3-ross.lagerwall@citrix.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250602133639.2871212-1-ross.lagerwall@citrix.com> References: <20250602133639.2871212-1-ross.lagerwall@citrix.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Kevin Lampis Make it possible to embed a public key in Xen to be used when verifying live patch payloads. Inclusion of the public key is optional. To avoid needing to include a DER / X.509 parser in the hypervisor, the public key is unpacked at build time and included in a form that is convenient for the hypervisor to consume. This is different approach from that used by Linux which embeds the entire X.509 certificate and builds in a parser for it. A suitable key can be created using openssl: openssl req -x509 -newkey rsa:2048 -keyout priv.pem -out pub.pem \ -sha256 -days 3650 -nodes \ -subj "/C=XX/ST=StateName/L=CityName/O=CompanyName/OU=CompanySectionName/CN=CommonNameOrHostname" openssl x509 -inform PEM -in pub.pem -outform PEM -pubkey -nocert -out verify_key.pem Signed-off-by: Kevin Lampis Signed-off-by: Ross Lagerwall --- In v3: * Drop unnecessary condition in Makefile * Use dashes instead of underscores * Drop section placement annotation on declaration * Clarify endianness of embedded key xen/common/Kconfig | 18 +++++++++++++++++ xen/crypto/Makefile | 11 ++++++++++ xen/include/xen/livepatch.h | 5 +++++ xen/tools/extract-key.py | 40 +++++++++++++++++++++++++++++++++++++ 4 files changed, 74 insertions(+) create mode 100755 xen/tools/extract-key.py diff --git a/xen/common/Kconfig b/xen/common/Kconfig index 0951d4c2f286..74673078202a 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -472,6 +472,24 @@ config LIVEPATCH If unsure, say Y. +config PAYLOAD_VERIFY + bool "Verify signed LivePatch payloads" + depends on LIVEPATCH + select CRYPTO + help + Verify signed LivePatch payloads using an RSA public key built + into the Xen hypervisor. Selecting this option requires a + public key in PEM format to be available for embedding during + the build. + +config PAYLOAD_VERIFY_KEY + string "File name of public key used to verify payloads" + default "verify_key.pem" + depends on PAYLOAD_VERIFY + help + The file name of an RSA public key in PEM format to be used for + verifying signed LivePatch payloads. + config FAST_SYMBOL_LOOKUP bool "Fast symbol lookup (bigger binary)" default y diff --git a/xen/crypto/Makefile b/xen/crypto/Makefile index db29655333a3..3d17232b78bc 100644 --- a/xen/crypto/Makefile +++ b/xen/crypto/Makefile @@ -1,2 +1,13 @@ obj-y += rijndael.o obj-y += vmac.o + +obj-$(CONFIG_PAYLOAD_VERIFY) += builtin-payload-key.o + +key-path := $(objtree)/$(patsubst "%",%,$(CONFIG_PAYLOAD_VERIFY_KEY)) +$(obj)/builtin-payload-key.bin: $(key-path) $(srctree)/tools/extract-key.py + $(srctree)/tools/extract-key.py < $< > $@.new + $(call move-if-changed,$@.new,$@) + +$(obj)/builtin-payload-key.S: BINFILE_FLAGS := -i +$(obj)/builtin-payload-key.S: $(srctree)/tools/binfile $(obj)/builtin-payload-key.bin FORCE + $(call if_changed,binfile,$(obj)/builtin-payload-key.bin xen_livepatch_key_data) diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h index d074a5bebecc..52f90cbed45b 100644 --- a/xen/include/xen/livepatch.h +++ b/xen/include/xen/livepatch.h @@ -143,6 +143,11 @@ struct payload; int revert_payload(struct payload *data); void revert_payload_tail(struct payload *data); +#ifdef CONFIG_PAYLOAD_VERIFY +/* The public key data contained with Xen used to verify payload signatures. */ +extern const uint8_t xen_livepatch_key_data[]; +#endif + #else /* diff --git a/xen/tools/extract-key.py b/xen/tools/extract-key.py new file mode 100755 index 000000000000..05c6bc261b3f --- /dev/null +++ b/xen/tools/extract-key.py @@ -0,0 +1,40 @@ +#!/usr/bin/env python3 + +# SPDX-License-Identifier: GPL-2.0 + +import binascii +import struct +import sys +import subprocess +import re + +# Decode a certificate into a format suitable for embedding in Xen. + +out = subprocess.check_output(['openssl', 'rsa', '-pubin', '-inform', 'PEM', + '-noout', '-text'], stdin=sys.stdin, + universal_newlines=True) +combined = '' +for line in out.split('\n'): + line = line.rstrip() + if line.startswith(' '): + combined += line.strip().replace(':', '') + match = re.match(r'Exponent: .* \(0x(.*)\)', line) + if match: + e = match.group(1) + +n = combined.lstrip('0') +if len(n) % 2 == 1: + n = '0' + n +n = binascii.unhexlify(n) +e = e.lstrip('0') +if len(e) % 2 == 1: + e = '0' + e +e = binascii.unhexlify(e) + +# Use little-endian for lengths. +# Use big-endian for byte sequences (as openssl does). + +sys.stdout.buffer.write(struct.pack(' Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 13:37:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003320.1382843 (Exim 4.92) (envelope-from ) id 1uM5LQ-0000AH-6c; Mon, 02 Jun 2025 13:36:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003320.1382843; Mon, 02 Jun 2025 13: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 1uM5LQ-0000A4-3w; Mon, 02 Jun 2025 13:36:52 +0000 Received: by outflank-mailman (input) for mailman id 1003320; Mon, 02 Jun 2025 13: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 1uM5LO-00009x-Vx for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 13:36:51 +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 a24a17a9-3fb6-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 15:36:48 +0200 (CEST) Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-604e2a2f200so8506176a12.1 for ; Mon, 02 Jun 2025 06:36:48 -0700 (PDT) Received: from rossla-pc.eng.citrite.net ([185.25.67.249]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ada5d82becbsm801962166b.39.2025.06.02.06.36.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 06:36:47 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a24a17a9-3fb6-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1748871408; x=1749476208; darn=lists.xenproject.org; h=content-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=gCihro/AP9pN/FWCTSPFf8bcTbZs+EZ03FJTcWvuD/4=; b=OtFfnsmcW1m4WDTknDBC0qg/zn5SlpoB0BAxd0RTjF1u/TXyCAZYuUsCVeg3Ufkgry xLJVs+L+2XAwe6Nkp0S+SB4trsxPsNjjd2yfbxA+/XJMJJz8M7WsuhEKqHOI116cLuSs qVJY0czgyhhP2MKaHx+T65v1ugO06LhUwPlFM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748871408; x=1749476208; 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=gCihro/AP9pN/FWCTSPFf8bcTbZs+EZ03FJTcWvuD/4=; b=GLu2BhPA9m9HdytqUKXvdn7vjFm+VOIj1WJ5WsDAA/CB+tafaMQ1taUaaN3VAXXxq1 AdtaYql53bJgEIJFIyJTQNIyIwiasR7viULYKTk8Tcoa1JqYDCF+ObAn8yS4iFNXYPS6 ZXpnbdZMV8ZpGro4Uz5tWDpbOxhST60V16TqGgoNmGrlm7vlOkpAtN1ES7/trruxOgtg EVEfsYjaf7R7BqroquhELy1eqC9miB4E3tZCjjWJ3nVMR23E0gI8KEJlkqynFowYNrk1 zvWGEaa9az2jBDZQnW1HFmSRxuhwX5APH94xqV5iqY8rhMF5ITG+wcJL3Nb9tsILRld0 /Dbw== X-Gm-Message-State: AOJu0YzV3BjRGNSJ62YqtvZHXK/1fMwhaZzz9Gta3YsD5y7RdRROUTrp sFv/CP1LBDFDgHCPfGsnnZJQQAC8JVPc0pYVmzCVY24xtKzsq6X0fyox1WrThTkzDLPfCYVol3F s2LY= X-Gm-Gg: ASbGncu1df5nHXwu0ooCpsERJArbiKjoP1YnXyDo0TNRC5pizBYWmuzgFuztDrWhaYi mrKBVM+PnGdfW8Ygi2CyjNmfyoQSOvGc7eUVmt19zT76ahpwPaf+h/Dza89t5jMk8fbS1oGiQ10 zq51/glCtxfcZHjne2VYe36GrY/hgxyOzCpjoPpmjitjb3FBxcLUoDOroOWbSoEmp4HCvNt9b/a tLFgISPIoKKQtbHJS+q0K9izULvhUBeBPcMXYy4yebaBz6V1Iy/AF/pCArJlH3xJ5DD0m2PtYhb f3zkZmj90E43H4I2UBu1Id/v5rZSm7Ve9SMggEkbl0fKigyhinlDTBjnOae3EfXn2iWKS1vrKz7 G33gxVvnX3Q== X-Google-Smtp-Source: AGHT+IGVgPnsadP3szTnZtAQeJxjgRkT8ybKYWCQN5JNzzSzY2mYQPNgmqzXA9vfQk9H+u9mGRrQVg== X-Received: by 2002:a17:907:9611:b0:ad8:7fd2:7754 with SMTP id a640c23a62f3a-adb49560382mr770807066b.47.1748871407899; Mon, 02 Jun 2025 06:36:47 -0700 (PDT) From: Ross Lagerwall To: xen-devel@lists.xenproject.org Cc: Ross Lagerwall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v3 1/5] docs: Introduce live patch signing Date: Mon, 2 Jun 2025 14:36:33 +0100 Message-ID: <20250602133639.2871212-2-ross.lagerwall@citrix.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250602133639.2871212-1-ross.lagerwall@citrix.com> References: <20250602133639.2871212-1-ross.lagerwall@citrix.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Remove a never-implemented description of live patch signing from the TODO section and document signing as implemented by the following patches. Signed-off-by: Ross Lagerwall --- No change in v3. docs/misc/livepatch.pandoc | 106 +++++++++++++++++++------------------ 1 file changed, 54 insertions(+), 52 deletions(-) diff --git a/docs/misc/livepatch.pandoc b/docs/misc/livepatch.pandoc index 04dd5ed7b271..f36de449e992 100644 --- a/docs/misc/livepatch.pandoc +++ b/docs/misc/livepatch.pandoc @@ -917,6 +917,60 @@ The normal sequence of events is to: 3. *XEN_SYSCTL_LIVEPATCH_ACTION* with *LIVEPATCH_ACTION_APPLY* to apply the patch. 4. *XEN_SYSCTL_LIVEPATCH_GET* to check the `->rc`. If in *-XEN_EAGAIN* spin. If zero exit with success. +## Signature Checking + +While loading live patches would generally be restricted to a privileged +process in dom0, in certain cases signature checking in Xen may be required. +For example, when Secure Boot is enabled live patches need to be verified +before being loaded. + +Xen live patches are ELF binaries but there is no standardized mechanism for +signing ELF binaries. One approach used by Linux is to append a signature to +the end of the binary, outside of the ELF container. While this works, it tends +to be fragile since tools that handle ELF binaries do not correctly handle the +signature. Instead, the approach taken here is to use an ELF note for the +signature. + +The ELF note section name shall be `.note.Xen.signature` with note name `Xen`. +The note type shall encode the signature version, algorithm, and hash: + +* version - uint16_t, bits 0-15 +* algorithm - uint8_t, bits 16-23 +* hash - uint8_t, bits 24-31 + +All other bits of the note type shall be zero. + +The known values for the above fields are: + + #define LIVEPATCH_SIGNATURE_VERSION 1 + #define SIGNATURE_ALGORITHM_RSA 0 + #define SIGNATURE_HASH_SHA256 0 + +The note descriptor length defines the length of the signature. + +To sign a live patch: + +1) Add a new note section with a populated payload signature and zeroed out + signature. +2) Generate a detached signature over the entire binary. +3) Fill in the signature in the note section. + +During live patch load, Xen shall verify the signature using the following +steps: + +1) Copy the signature out of the note section. +2) Zero the signature. +3) Generate a detached signature over the entire binary. +4) Compare against the signature from (1). + +Initially, to avoid including DER / X.509 parsing of certificates, handling +chains, etc. Xen shall verify signatures against a compiled in RSA key in +exponent/modulus form. However, it may be extended in future to support other +types of signatures and key types. + +Support of signatures in Xen and in live patches is optional. However, certain +features such as Secure Boot may require live patches to be signed. + ## Addendum @@ -1178,58 +1232,6 @@ the function itself. Similar considerations are true to a lesser extent for \__FILE__, but it could be argued that file renaming should be done outside of hotpatches. -## Signature checking requirements. - -The signature checking requires that the layout of the data in memory -**MUST** be same for signature to be verified. This means that the payload -data layout in ELF format **MUST** match what the hypervisor would be -expecting such that it can properly do signature verification. - -The signature is based on the all of the payloads continuously laid out -in memory. The signature is to be appended at the end of the ELF payload -prefixed with the string '`~Module signature appended~\n`', followed by -an signature header then followed by the signature, key identifier, and signers -name. - -Specifically the signature header would be: - - #define PKEY_ALGO_DSA 0 - #define PKEY_ALGO_RSA 1 - - #define PKEY_ID_PGP 0 /* OpenPGP generated key ID */ - #define PKEY_ID_X509 1 /* X.509 arbitrary subjectKeyIdentifier */ - - #define HASH_ALGO_MD4 0 - #define HASH_ALGO_MD5 1 - #define HASH_ALGO_SHA1 2 - #define HASH_ALGO_RIPE_MD_160 3 - #define HASH_ALGO_SHA256 4 - #define HASH_ALGO_SHA384 5 - #define HASH_ALGO_SHA512 6 - #define HASH_ALGO_SHA224 7 - #define HASH_ALGO_RIPE_MD_128 8 - #define HASH_ALGO_RIPE_MD_256 9 - #define HASH_ALGO_RIPE_MD_320 10 - #define HASH_ALGO_WP_256 11 - #define HASH_ALGO_WP_384 12 - #define HASH_ALGO_WP_512 13 - #define HASH_ALGO_TGR_128 14 - #define HASH_ALGO_TGR_160 15 - #define HASH_ALGO_TGR_192 16 - - struct elf_payload_signature { - u8 algo; /* Public-key crypto algorithm PKEY_ALGO_*. */ - u8 hash; /* Digest algorithm: HASH_ALGO_*. */ - u8 id_type; /* Key identifier type PKEY_ID*. */ - u8 signer_len; /* Length of signer's name */ - u8 key_id_len; /* Length of key identifier */ - u8 __pad[3]; - __be32 sig_len; /* Length of signature data */ - }; - -(Note that this has been borrowed from Linux module signature code.). - - ### .bss and .data sections. In place patching writable data is not suitable as it is unclear what should be done -- 2.49.0 From xen-devel-bounces@lists.xenproject.org Mon Jun 02 13:37:02 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 13:37:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003322.1382864 (Exim 4.92) (envelope-from ) id 1uM5LV-0000dE-Jk; Mon, 02 Jun 2025 13:36:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003322.1382864; Mon, 02 Jun 2025 13:36: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 1uM5LV-0000d5-Gz; Mon, 02 Jun 2025 13:36:57 +0000 Received: by outflank-mailman (input) for mailman id 1003322; Mon, 02 Jun 2025 13:36: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 1uM5LU-0000AN-6C for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 13:36:56 +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 a664d860-3fb6-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 15:36:55 +0200 (CEST) Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-ad8a6c202ffso855479666b.3 for ; Mon, 02 Jun 2025 06:36:55 -0700 (PDT) Received: from rossla-pc.eng.citrite.net ([185.25.67.249]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ada5d82becbsm801962166b.39.2025.06.02.06.36.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 06:36:54 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a664d860-3fb6-11f0-a300-13f23c93f187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1748871415; x=1749476215; darn=lists.xenproject.org; h=content-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=D4baIbDrOsM/y9vBJw3lc1/l5s3LVRFoojQrWo8j6uc=; b=cLEY13ZWw57uHIDQFppYDQ79QwNpvQZbHtCr9SDi7hTkR/iKKWkzJQlfGQRtNfAhD5 ISvMhjmjz0fl4oNJqjTP85DoFaXH9yn20WkV2soZLh3VBdRDAziL7JjYAEmRjE787hku Qd3PjNakR9T3wzc/yFmEzRRid9cr/o1gF9bL4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748871415; x=1749476215; 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=D4baIbDrOsM/y9vBJw3lc1/l5s3LVRFoojQrWo8j6uc=; b=en8C3jibS4cnCI/bXmqU1oSmCZvfZ5Ayl4Wy6DR+xYlXvErrp14OerG+0qOQH6Xlve eWPiFADutOVSjZPYfjpJCMi8YZBc6cauUZqJMYnXW0NelAlNbIuW7NIyfgJsACtXk+tb cZ7HqqH7eKfM4yrAIk5anmpRj1X+nQCQg6klXjeKpAziIC49QuW71UYWSqCQx71mx4G0 /ho+UpuKihQ9ki9rDpSM7Jns2PIZ+ngZpgXYpXIuQ+8ZdcYcDY7/qOV8XoZvKmJNVxx5 AsS/55tKO9SxyElHI51UbzqjEiflHK4+GI5J0S9M8Kv2kWO6Py0PqAJLOxl8J+60lfcW Cr6A== X-Gm-Message-State: AOJu0Yx1fsMPLu9I/Mxj236owerRfa6zXbgDJqgC14SjZKQ2KjIb1lRm zP2Gob65P4/0dujMpKxsPOoZEcpWHgnkAIsMlLhEt8qkCpQPaubTXKyyChZc87H28DdbyMleM4I 3NUc= X-Gm-Gg: ASbGncv07aszco3ek8cxSLOkOh08TArGnu91Z1w3Dt4W7WKPlNb/kkBggBICDRpNMp8 /WRo79tHf6U7kvZ+T4yoFwvACZNAxEajHtyeLOnxwuN7W05afzopL/Fw8/vyXgy1kTiA8+wui0S nbVt7I7s+OrCkBkNc82reLA+JxsEVXfRDeK+vxio7vUlURoXVYBs+Ex8isQ/ej33DvnUovLz3s/ Fm6zGdo6XaqW6FOjeZgsgLvawrChSjE3ADYg9DBq7SDrhxLeQICJ+a2I81CGqtR+TLL9kwVdh7D 3aBI/jnbZZNGGrB2WEn2CJRpxbekEqqAiwRLv/KnEIb8WwlFbtvug90G9xTPgKb+2biCtKqvkBG j3xTHGwozZA== X-Google-Smtp-Source: AGHT+IGyzrBL1oEx1GJqgPBxBT5OrZ6loM+nv7/VroTRyESh/NW9kHGjgB8y/GwOZNWzbhJ1PHSi4A== X-Received: by 2002:a17:907:9711:b0:ad8:9b16:58cc with SMTP id a640c23a62f3a-adb494e5aa2mr765152666b.39.1748871414513; Mon, 02 Jun 2025 06:36:54 -0700 (PDT) From: Ross Lagerwall To: xen-devel@lists.xenproject.org Cc: Ross Lagerwall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v3 4/5] livepatch: Load built-in key during boot Date: Mon, 2 Jun 2025 14:36:36 +0100 Message-ID: <20250602133639.2871212-5-ross.lagerwall@citrix.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250602133639.2871212-1-ross.lagerwall@citrix.com> References: <20250602133639.2871212-1-ross.lagerwall@citrix.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Parse the raw data of the embedded RSA key into a form that can be later used for verifying live patch signatures. Signed-off-by: Ross Lagerwall --- * Fix endianness of builtin key lengths * Set builtin key to __ro_after_init xen/common/livepatch.c | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c index 9a0df5363b59..92d1d342d872 100644 --- a/xen/common/livepatch.c +++ b/xen/common/livepatch.c @@ -11,6 +11,8 @@ #include #include #include +#include +#include #include #include #include @@ -73,6 +75,10 @@ static struct livepatch_work livepatch_work; static DEFINE_PER_CPU(bool, work_to_do); static DEFINE_PER_CPU(struct tasklet, livepatch_tasklet); +#ifdef CONFIG_PAYLOAD_VERIFY +static struct rsa_public_key __ro_after_init builtin_payload_key; +#endif + static int get_name(const struct xen_livepatch_name *name, char *n) { if ( !name->size || name->size > XEN_LIVEPATCH_NAME_SIZE ) @@ -2300,6 +2306,31 @@ static void cf_check livepatch_printall(unsigned char key) spin_unlock(&payload_lock); } +static int load_builtin_payload_key(void) +{ +#ifdef CONFIG_PAYLOAD_VERIFY + const uint8_t *ptr; + uint32_t len; + + rsa_public_key_init(&builtin_payload_key); + + ptr = xen_livepatch_key_data; + + memcpy(&len, ptr, sizeof(len)); + ptr += sizeof(len); + builtin_payload_key.n = mpi_read_raw_data(ptr, le32_to_cpu(len)); + ptr += len; + + memcpy(&len, ptr, sizeof(len)); + ptr += sizeof(len); + builtin_payload_key.e = mpi_read_raw_data(ptr, le32_to_cpu(len)); + + return rsa_public_key_prepare(&builtin_payload_key); +#else + return 0; +#endif +} + static int cf_check cpu_callback( struct notifier_block *nfb, unsigned long action, void *hcpu) { @@ -2318,6 +2349,11 @@ static struct notifier_block cpu_nfb = { static int __init cf_check livepatch_init(void) { unsigned int cpu; + int err; + + err = load_builtin_payload_key(); + if ( err ) + return err; for_each_online_cpu ( cpu ) { -- 2.49.0 From xen-devel-bounces@lists.xenproject.org Mon Jun 02 13:37:02 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 13:37:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003323.1382870 (Exim 4.92) (envelope-from ) id 1uM5LV-0000fr-Vz; Mon, 02 Jun 2025 13:36:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003323.1382870; Mon, 02 Jun 2025 13:36: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 1uM5LV-0000eh-OX; Mon, 02 Jun 2025 13:36:57 +0000 Received: by outflank-mailman (input) for mailman id 1003323; Mon, 02 Jun 2025 13:36:56 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uM5LU-00009x-Az for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 13:36:56 +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 a557f18b-3fb6-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 15:36:54 +0200 (CEST) Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-ad52dfe06ceso550851666b.3 for ; Mon, 02 Jun 2025 06:36:54 -0700 (PDT) Received: from rossla-pc.eng.citrite.net ([185.25.67.249]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ada5d82becbsm801962166b.39.2025.06.02.06.36.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 06:36:52 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a557f18b-3fb6-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1748871413; x=1749476213; darn=lists.xenproject.org; h=content-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=jZPdtLJc6ueITKp0X/zmlW9IvyS6npVX/EwxkveUrjM=; b=QERCK1rnR5+NnpMy+vH7yHVHj60lMStvloWQx99XAZ9nSV1RI+Sp3as/5EuGBfeuvo m+HAJOYVfVuy8RpaXGGoutHWrZDk6BJystCpXLvffp/tyknhY5cGaxz16VGg5WQtTRL6 kYKoOX+ma27Sp41neGEHs62I2RPSb4xjERyHI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748871413; x=1749476213; 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=jZPdtLJc6ueITKp0X/zmlW9IvyS6npVX/EwxkveUrjM=; b=b8wg5lv9duhZ/kNMjE5h/4bv3MuuxRTOa4q1+in9J3efK0z4+egQ0Cktrb5QAp4IOV mZj+94j4HZr4GvKB6DEtbj2/5X7jdFvfJpE/04X1MxiQvisL/uHm0mBcOrFSZU3FRC/1 HZyi8L7VsMqyH3ZOobPtMB4veEenkwY5/Zsm+sXIv/cV8qyeTDi6i5NzSw+6eGsJRE7j MCT94b+1lc2XJU6439NUYGNIiE6bu09JOTmVYWBQHWasP96UPDntkAuEgTazjbZUcbxa JfeIMnsOpXkx4mUnX3szFQrKCYVplDY3okmJLmDjCTvec0T/xPL8UGBPLg7FvEVh3TJU Pb1Q== X-Gm-Message-State: AOJu0YwJf4DY/atAMqkIHE1qhZT5D7CgwB+yqj3vkmRK0ZPxiC3QVeJh Ikkt4ia8zJdWTmkuD/EchXb5+K1x71ehVpuMDhPc1DIJ9kymOYm1vF08P7Xo+fp/kzXaF4ls5zg 5X0M= X-Gm-Gg: ASbGncvFR3K0ots+kS+WVjH6yp0Np7rJOV5s4MfANigB78mVWoeJm1PIsVGbJhYrX7b iW0XDpDPjrU7E45P9NCYRpC9FGWlcyL+ShfnT7MDvQNZHbKXIxH/yb7JaBzt000EOaVo8k6W8Qc GIg9xiqpu7w4hrknn3K9E3eTNT+HP8TYvUn6S096lLy0DEV7s2KOdZoRZvcC1Kt9bLFi6PwC0ax ickRdc8It0MHNoXsVnjujLU590X3AzCxBKTqT1Jnr/3r4idH7fHJoDze5NVDqSu+BFTx5PHMWp/ FgdZWuLcDJTCedUsJrCJ5R7yrHS0S0sUK0lRZAt6tXHK/rYNkxvbNMpjd/SMQlkHDiGq5VkUOyk = X-Google-Smtp-Source: AGHT+IHX8If27lZf8Ncnm7cXY3VU/q8YWymJgLlu48b5CE6uCMIrbABR2hXvEzw8xHk76saiyMy5Ig== X-Received: by 2002:a17:907:9349:b0:ad8:9257:5741 with SMTP id a640c23a62f3a-adb4936fa69mr634306066b.9.1748871412511; Mon, 02 Jun 2025 06:36:52 -0700 (PDT) From: Ross Lagerwall To: xen-devel@lists.xenproject.org Cc: Ross Lagerwall , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v3 3/5] crypto: Add RSA support Date: Mon, 2 Jun 2025 14:36:35 +0100 Message-ID: <20250602133639.2871212-4-ross.lagerwall@citrix.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250602133639.2871212-1-ross.lagerwall@citrix.com> References: <20250602133639.2871212-1-ross.lagerwall@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit In preparation for adding support for livepatch signing, add support for RSA crypto. The RSA code is extracted from Nettle at tag nettle_3.2_release_20160128 (https://git.lysator.liu.se/nettle/nettle). The MPI code is extracted from Linux at commit eef0df6a5953 (lib/mpi/*). Signed-off-by: Ross Lagerwall --- In v3: * Move mpi.c to lib * Fix header guard name xen/crypto/Makefile | 1 + xen/crypto/rsa.c | 196 +++++ xen/include/xen/mpi.h | 68 ++ xen/include/xen/rsa.h | 74 ++ xen/lib/Makefile | 1 + xen/lib/mpi.c | 1729 +++++++++++++++++++++++++++++++++++++++++ 6 files changed, 2069 insertions(+) create mode 100644 xen/crypto/rsa.c create mode 100644 xen/include/xen/mpi.h create mode 100644 xen/include/xen/rsa.h create mode 100644 xen/lib/mpi.c diff --git a/xen/crypto/Makefile b/xen/crypto/Makefile index 3d17232b78bc..55a045a7f0c0 100644 --- a/xen/crypto/Makefile +++ b/xen/crypto/Makefile @@ -1,4 +1,5 @@ obj-y += rijndael.o +obj-$(CONFIG_PAYLOAD_VERIFY) += rsa.o obj-y += vmac.o obj-$(CONFIG_PAYLOAD_VERIFY) += builtin-payload-key.o diff --git a/xen/crypto/rsa.c b/xen/crypto/rsa.c new file mode 100644 index 000000000000..bd78c65f7393 --- /dev/null +++ b/xen/crypto/rsa.c @@ -0,0 +1,196 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later OR LGPL-3.0-or-later */ +/* rsa.c + + The RSA publickey algorithm. + + Copyright (C) 2001 Niels Möller + + This file is part of GNU Nettle. + + GNU Nettle is free software: you can redistribute it and/or + modify it under the terms of either: + + * the GNU Lesser General Public License as published by the Free + Software Foundation; either version 3 of the License, or (at your + option) any later version. + + or + + * the GNU General Public License as published by the Free + Software Foundation; either version 2 of the License, or (at your + option) any later version. + + or both in parallel, as here. + + GNU Nettle is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + General Public License for more details. + + You should have received copies of the GNU General Public License and + the GNU Lesser General Public License along with this program. If + not, see http://www.gnu.org/licenses/. +*/ + +#include +#include +#include +#include +#include +#include + +void rsa_public_key_init(struct rsa_public_key *key) +{ + key->n = NULL; + key->e = NULL; + key->size = 0; +} + +/* + * Computes the size, in octets, of the modulo. Returns 0 if the + * modulo is too small to be useful, or otherwise appears invalid. + */ +static size_t rsa_check_size(MPI n) +{ + /* Round upwards */ + size_t size; + + /* Even moduli are invalid */ + if ( mpi_test_bit(n, 0) == 0 ) + return 0; + + size = (mpi_get_nbits(n) + 7) / 8; + + if ( size < RSA_MINIMUM_N_OCTETS ) + return 0; + + return size; +} + +int rsa_public_key_prepare(struct rsa_public_key *key) +{ + if ( !key->n || !key->e || key->size ) + return -EINVAL; + + key->size = rsa_check_size(key->n); + + return key->size > 0 ? 0 : -EINVAL; +} + +/* + * Formats the PKCS#1 padding, of the form + * + * 0x00 0x01 0xff ... 0xff 0x00 id ...digest... + * + * where the 0xff ... 0xff part consists of at least 8 octets. The + * total size equals the octet size of n. + */ +static uint8_t *pkcs1_signature_prefix(unsigned int key_size, uint8_t *buffer, + unsigned int id_size, const uint8_t *id, + unsigned int digest_size) +{ + unsigned int j; + + if ( key_size < 11 + id_size + digest_size ) + return NULL; + + j = key_size - digest_size - id_size; + + memcpy(buffer + j, id, id_size); + buffer[0] = 0; + buffer[1] = 1; + buffer[j - 1] = 0; + + ASSERT(j >= 11); + memset(buffer + 2, 0xff, j - 3); + + return buffer + j + id_size; +} + +/* + * From RFC 3447, Public-Key Cryptography Standards (PKCS) #1: RSA + * Cryptography Specifications Version 2.1. + * + * id-sha256 OBJECT IDENTIFIER ::= + * {joint-iso-itu-t(2) country(16) us(840) organization(1) + * gov(101) csor(3) nistalgorithm(4) hashalgs(2) 1} + */ +static const uint8_t +sha256_prefix[] = +{ + /* 19 octets prefix, 32 octets hash, total 51 */ + 0x30, 49, /* SEQUENCE */ + 0x30, 13, /* SEQUENCE */ + 0x06, 9, /* OBJECT IDENTIFIER */ + 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, + 0x05, 0, /* NULL */ + 0x04, 32 /* OCTET STRING */ + /* Here comes the raw hash value */ +}; + +static int pkcs1_rsa_sha256_encode(MPI *m, size_t key_size, + struct sha2_256_state *hash) +{ + uint8_t *ptr; + uint8_t *buf; + + buf = xmalloc_bytes(key_size); + if ( !buf ) + return -ENOMEM; + + ptr = pkcs1_signature_prefix(key_size, buf, + sizeof(sha256_prefix), sha256_prefix, + SHA2_256_DIGEST_SIZE); + if ( !ptr ) + { + xfree(buf); + return -EINVAL; + } + + sha2_256_final(hash, ptr); + *m = mpi_read_raw_data(buf, key_size); + xfree(buf); + return 0; +} + +static int rsa_verify(const struct rsa_public_key *key, MPI m, MPI s) +{ + int ret; + MPI m1; + + /* (1) Validate 0 <= s < n */ + if ( mpi_cmp_ui(s, 0) < 0 || mpi_cmp(s, key->n) >= 0 ) + return -EINVAL; + + m1 = mpi_alloc(key->size / BYTES_PER_MPI_LIMB); + if ( !m1 ) + return -ENOMEM; + + /* (2) m = s^e mod n */ + ret = mpi_powm(m1, s, key->e, key->n); + if ( ret ) + goto out; + + ret = mpi_cmp(m, m1) ? -EINVAL : 0; + + out: + mpi_free(m1); + return ret; +} + +int rsa_sha256_verify(const struct rsa_public_key *key, + struct sha2_256_state *hash, MPI s) +{ + int ret; + MPI m; + + ret = pkcs1_rsa_sha256_encode(&m, key->size, hash); + if ( ret ) + return ret; + + ret = rsa_verify(key, m, s); + + mpi_free(m); + + return ret; +} diff --git a/xen/include/xen/mpi.h b/xen/include/xen/mpi.h new file mode 100644 index 000000000000..2d6adb8d8d0a --- /dev/null +++ b/xen/include/xen/mpi.h @@ -0,0 +1,68 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ +/* mpi.h - Multi Precision Integers + * Copyright (C) 1994, 1996, 1998, 1999, + * 2000, 2001 Free Software Foundation, Inc. + * + * This file is part of GNUPG. + * + * GNUPG is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * GNUPG is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA + * + * Note: This code is heavily based on the GNU MP Library. + * Actually it's the same code with only minor changes in the + * way the data is stored; this is to support the abstraction + * of an optional secure memory allocation which may be used + * to avoid revealing of sensitive data due to paging etc. + * The GNU MP Library itself is published under the LGPL; + * however I decided to publish this code under the plain GPL. + */ + +#ifndef XEN_MPI_H +#define XEN_MPI_H + +#include + +#define BYTES_PER_MPI_LIMB (BITS_PER_LONG / 8) +#define BITS_PER_MPI_LIMB BITS_PER_LONG + +typedef unsigned long int mpi_limb_t; +typedef signed long int mpi_limb_signed_t; + +struct mpi { + int alloced; /* array size (# of allocated limbs) */ + int nlimbs; /* number of valid limbs */ + int nbits; /* the real number of valid bits (info only) */ + int sign; /* indicates a negative number */ +#define MPI_FLAG_SECURE_MEM (1 << 0) +#define MPI_FLAG_UNUSED (1 << 1) +#define MPI_FLAG_PTR_ALLOC (1 << 4) +#define MPI_FLAG_MASK 7 + unsigned int flags; /* bit 0: array must be allocated in secure memory space */ + /* bit 1: not used */ + /* bit 2: the limb is a pointer to some m_alloced data */ + mpi_limb_t *d; /* array with the limbs */ +}; + +typedef struct mpi *MPI; + +MPI mpi_alloc(unsigned nlimbs); +void mpi_free(MPI a); +MPI mpi_read_raw_data(const void *xbuffer, size_t nbytes); +int mpi_powm(MPI res, MPI base, MPI exp, MPI mod); +int mpi_cmp_ui(MPI u, unsigned long v); +int mpi_cmp(MPI u, MPI v); +unsigned mpi_get_nbits(MPI a); +int mpi_test_bit(MPI a, unsigned int n); + +#endif /* XEN_MPI_H */ diff --git a/xen/include/xen/rsa.h b/xen/include/xen/rsa.h new file mode 100644 index 000000000000..be60383b18d5 --- /dev/null +++ b/xen/include/xen/rsa.h @@ -0,0 +1,74 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later OR LGPL-3.0-or-later */ +/* rsa.h + + The RSA publickey algorithm. + + Copyright (C) 2001, 2002 Niels Möller + + This file is part of GNU Nettle. + + GNU Nettle is free software: you can redistribute it and/or + modify it under the terms of either: + + * the GNU Lesser General Public License as published by the Free + Software Foundation; either version 3 of the License, or (at your + option) any later version. + + or + + * the GNU General Public License as published by the Free + Software Foundation; either version 2 of the License, or (at your + option) any later version. + + or both in parallel, as here. + + GNU Nettle is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + General Public License for more details. + + You should have received copies of the GNU General Public License and + the GNU Lesser General Public License along with this program. If + not, see http://www.gnu.org/licenses/. +*/ + +#ifndef XEN_RSA_H +#define XEN_RSA_H + +#include +#include + +struct sha2_256_state; + +/* + * This limit is somewhat arbitrary. Technically, the smallest modulo + * which makes sense at all is 15 = 3*5, phi(15) = 8, size 4 bits. But + * for ridiculously small keys, not all odd e are possible (e.g., for + * 5 bits, the only possible modulo is 3*7 = 21, phi(21) = 12, and e = + * 3 don't work). The smallest size that makes sense with pkcs#1, and + * which allows RSA encryption of one byte messages, is 12 octets, 89 + * bits. + */ +#define RSA_MINIMUM_N_OCTETS 12 +#define RSA_MINIMUM_N_BITS (8 * RSA_MINIMUM_N_OCTETS - 7) + +struct rsa_public_key +{ + /* + * Size of the modulo, in octets. This is also the size of all + * signatures that are created or verified with this key. + */ + size_t size; + MPI n; /* Modulo */ + MPI e; /* Public exponent */ +}; + +void rsa_public_key_init(struct rsa_public_key *key); + +int rsa_public_key_prepare(struct rsa_public_key *key); + +int rsa_sha256_verify(const struct rsa_public_key *key, + struct sha2_256_state *hash, + MPI signature); + +#endif /* XEN_RSA_H */ diff --git a/xen/lib/Makefile b/xen/lib/Makefile index 5ccb1e5241c5..f37367277ede 100644 --- a/xen/lib/Makefile +++ b/xen/lib/Makefile @@ -14,6 +14,7 @@ lib-y += memcmp.o lib-y += memcpy.o lib-y += memmove.o lib-y += memset.o +lib-y += mpi.o lib-y += muldiv64.o lib-y += parse-size.o lib-y += rbtree.o diff --git a/xen/lib/mpi.c b/xen/lib/mpi.c new file mode 100644 index 000000000000..94010d14b3d0 --- /dev/null +++ b/xen/lib/mpi.c @@ -0,0 +1,1729 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ +/* mpi.c - MPI functions + * Copyright (C) 1994, 1996, 1998, 2000 Free Software Foundation, Inc. + * + * This file is part of GnuPG. + * + * GnuPG is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * GnuPG is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA + * + * Note: This code is heavily based on the GNU MP Library. + * Actually it's the same code with only minor changes in the + * way the data is stored; this is to support the abstraction + * of an optional secure memory allocation which may be used + * to avoid revealing of sensitive data due to paging etc. + * The GNU MP Library itself is published under the LGPL; + * however I decided to publish this code under the plain GPL. + */ + +#include +#include +#include +#include +#include +#include +#include + +#define MAX_EXTERN_MPI_BITS 16384 + +/* Define it to a value which is good on most machines. + * tested 4, 16, 32 and 64, where 16 gave the best performance when + * checking a 768 and a 1024 bit ElGamal signature. + * (wk 22.12.97) */ +#define KARATSUBA_THRESHOLD 16 + +typedef mpi_limb_t *mpi_ptr_t; /* pointer to a limb */ +typedef int mpi_size_t; /* (must be a signed type) */ + +/* Copy N limbs from S to D. */ +#define MPN_COPY(d, s, n) \ + do { \ + mpi_size_t _i; \ + for (_i = 0; _i < (n); _i++) \ + (d)[_i] = (s)[_i]; \ + } while (0) + +#define MPN_COPY_DECR(d, s, n) \ + do { \ + mpi_size_t _i; \ + for (_i = (n)-1; _i >= 0; _i--) \ + (d)[_i] = (s)[_i]; \ + } while (0) + +/* Zero N limbs at D */ +#define MPN_ZERO(d, n) \ + do { \ + mpi_size_t _i; \ + for (_i = 0; _i < (n); _i++) \ + (d)[_i] = 0; \ + } while (0) + +#define MPN_NORMALIZE(d, n) \ + do { \ + while ((n) > 0) { \ + if ((d)[(n)-1]) \ + break; \ + (n)--; \ + } \ + } while (0) + +#define MPN_MUL_N_RECURSE(prodp, up, vp, size, tspace) \ + do { \ + if ((size) < KARATSUBA_THRESHOLD) \ + mul_n_basecase(prodp, up, vp, size); \ + else \ + mul_n(prodp, up, vp, size, tspace); \ + } while (0); + +#define MPN_SQR_N_RECURSE(prodp, up, size, tspace) \ + do { \ + if ((size) < KARATSUBA_THRESHOLD) \ + mpih_sqr_n_basecase(prodp, up, size); \ + else \ + mpih_sqr_n(prodp, up, size, tspace); \ + } while (0); + +#define add_ssaaaa(sh, sl, ah, al, bh, bl) \ +do { \ + mpi_limb_t __x; \ + __x = (al) + (bl); \ + (sh) = (ah) + (bh) + (__x < (al)); \ + (sl) = __x; \ +} while (0) + +#define sub_ddmmss(sh, sl, ah, al, bh, bl) \ +do { \ + mpi_limb_t __x; \ + __x = (al) - (bl); \ + (sh) = (ah) - (bh) - (__x > (al)); \ + (sl) = __x; \ +} while (0) + +#define __ll_B ((mpi_limb_t) 1 << (BITS_PER_MPI_LIMB / 2)) +#define __ll_lowpart(t) ((mpi_limb_t) (t) & (__ll_B - 1)) +#define __ll_highpart(t) ((mpi_limb_t) (t) >> (BITS_PER_MPI_LIMB / 2)) + +#define umul_ppmm(w1, w0, u, v) \ +do { \ + mpi_limb_t __x0, __x1, __x2, __x3; \ + unsigned int __ul, __vl, __uh, __vh; \ + mpi_limb_t __u = (u), __v = (v); \ + \ + __ul = __ll_lowpart(__u); \ + __uh = __ll_highpart(__u); \ + __vl = __ll_lowpart(__v); \ + __vh = __ll_highpart(__v); \ + \ + __x0 = (mpi_limb_t) __ul * __vl; \ + __x1 = (mpi_limb_t) __ul * __vh; \ + __x2 = (mpi_limb_t) __uh * __vl; \ + __x3 = (mpi_limb_t) __uh * __vh; \ + \ + __x1 += __ll_highpart(__x0);/* this can't give carry */ \ + __x1 += __x2; /* but this indeed can */ \ + if (__x1 < __x2) /* did we get it? */ \ + __x3 += __ll_B; /* yes, add it in the proper pos. */ \ + \ + (w1) = __x3 + __ll_highpart(__x1); \ + (w0) = (__ll_lowpart(__x1) << BITS_PER_MPI_LIMB/2) + __ll_lowpart(__x0); \ +} while (0) + +#define udiv_qrnnd(q, r, n1, n0, d) \ +do { \ + mpi_limb_t __d1, __d0, __q1, __q0, __r1, __r0, __m; \ + __d1 = __ll_highpart(d); \ + __d0 = __ll_lowpart(d); \ + \ + __r1 = (n1) % __d1; \ + __q1 = (n1) / __d1; \ + __m = (mpi_limb_t) __q1 * __d0; \ + __r1 = __r1 * __ll_B | __ll_highpart(n0); \ + if (__r1 < __m) { \ + __q1--, __r1 += (d); \ + if (__r1 >= (d)) /* i.e. we didn't get carry when adding to __r1 */ \ + if (__r1 < __m) \ + __q1--, __r1 += (d); \ + } \ + __r1 -= __m; \ + \ + __r0 = __r1 % __d1; \ + __q0 = __r1 / __d1; \ + __m = (mpi_limb_t) __q0 * __d0; \ + __r0 = __r0 * __ll_B | __ll_lowpart(n0); \ + if (__r0 < __m) { \ + __q0--, __r0 += (d); \ + if (__r0 >= (d)) \ + if (__r0 < __m) \ + __q0--, __r0 += (d); \ + } \ + __r0 -= __m; \ + \ + (q) = (mpi_limb_t) __q1 * __ll_B | __q0; \ + (r) = __r0; \ +} while (0) + +struct karatsuba_ctx { + struct karatsuba_ctx *next; + mpi_ptr_t tspace; + mpi_size_t tspace_size; + mpi_ptr_t tp; + mpi_size_t tp_size; +}; + +static void mpi_normalize(MPI a); +static mpi_limb_t mpihelp_submul_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, + mpi_size_t s1_size, mpi_limb_t s2_limb); +static mpi_limb_t mpihelp_divrem(mpi_ptr_t qp, mpi_size_t qextra_limbs, + mpi_ptr_t np, mpi_size_t nsize, + mpi_ptr_t dp, mpi_size_t dsize); +static mpi_limb_t mpihelp_rshift(mpi_ptr_t wp, mpi_ptr_t up, mpi_size_t usize, + unsigned cnt); +static void mpi_assign_limb_space(MPI a, mpi_ptr_t ap, unsigned nlimbs); +static mpi_ptr_t mpi_alloc_limb_space(unsigned nlimbs); +static void mpi_free_limb_space(mpi_ptr_t a); +static mpi_limb_t mpihelp_addmul_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, + mpi_size_t s1_size, mpi_limb_t s2_limb); +static int mpihelp_mul(mpi_ptr_t prodp, mpi_ptr_t up, mpi_size_t usize, + mpi_ptr_t vp, mpi_size_t vsize, mpi_limb_t *_result); +static mpi_limb_t mpihelp_lshift(mpi_ptr_t wp, mpi_ptr_t up, mpi_size_t usize, + unsigned cnt); +static int mpihelp_cmp(mpi_ptr_t op1_ptr, mpi_ptr_t op2_ptr, mpi_size_t size); +static void mpih_sqr_n(mpi_ptr_t prodp, mpi_ptr_t up, mpi_size_t size, + mpi_ptr_t tspace); +static mpi_limb_t mpihelp_add_n(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, + mpi_ptr_t s2_ptr, mpi_size_t size); +static mpi_limb_t mpihelp_sub_n(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, + mpi_ptr_t s2_ptr, mpi_size_t size); +static mpi_limb_t mpihelp_mul_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, + mpi_size_t s1_size, mpi_limb_t s2_limb); +static void mpihelp_release_karatsuba_ctx(struct karatsuba_ctx *ctx); +static void mpih_sqr_n_basecase(mpi_ptr_t prodp, mpi_ptr_t up, mpi_size_t size); +static int mpihelp_mul_karatsuba_case(mpi_ptr_t prodp, + mpi_ptr_t up, mpi_size_t usize, + mpi_ptr_t vp, mpi_size_t vsize, + struct karatsuba_ctx *ctx); +static int mpi_resize(MPI a, unsigned nlimbs); + +/** + * count_leading_zeros - Count the number of zeros from the MSB back + * @x: The value + * + * Count the number of leading zeros from the MSB going towards the LSB in @x. + * + * If the MSB of @x is set, the result is 0. + * If only the LSB of @x is set, then the result is BITS_PER_LONG-1. + * If @x is 0 then the result is BITS_PER_LONG. + */ +static inline int count_leading_zeros(unsigned long x) +{ + if (sizeof(x) == 4) + return BITS_PER_LONG - fls(x); + else + return BITS_PER_LONG - fls64(x); +} + +static mpi_limb_t +mpihelp_add_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, + mpi_size_t s1_size, mpi_limb_t s2_limb) +{ + mpi_limb_t x; + + x = *s1_ptr++; + s2_limb += x; + *res_ptr++ = s2_limb; + if (s2_limb < x) { /* sum is less than the left operand: handle carry */ + while (--s1_size) { + x = *s1_ptr++ + 1; /* add carry */ + *res_ptr++ = x; /* and store */ + if (x) /* not 0 (no overflow): we can stop */ + goto leave; + } + return 1; /* return carry (size of s1 to small) */ + } + + leave: + if (res_ptr != s1_ptr) { /* not the same variable */ + mpi_size_t i; /* copy the rest */ + for (i = 0; i < s1_size - 1; i++) + res_ptr[i] = s1_ptr[i]; + } + return 0; /* no carry */ +} + +static mpi_limb_t +mpihelp_sub_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, + mpi_size_t s1_size, mpi_limb_t s2_limb) +{ + mpi_limb_t x; + + x = *s1_ptr++; + s2_limb = x - s2_limb; + *res_ptr++ = s2_limb; + if (s2_limb > x) { + while (--s1_size) { + x = *s1_ptr++; + *res_ptr++ = x - 1; + if (x) + goto leave; + } + return 1; + } + + leave: + if (res_ptr != s1_ptr) { + mpi_size_t i; + for (i = 0; i < s1_size - 1; i++) + res_ptr[i] = s1_ptr[i]; + } + return 0; +} + +static mpi_limb_t +mpihelp_sub(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, mpi_size_t s1_size, + mpi_ptr_t s2_ptr, mpi_size_t s2_size) +{ + mpi_limb_t cy = 0; + + if (s2_size) + cy = mpihelp_sub_n(res_ptr, s1_ptr, s2_ptr, s2_size); + + if (s1_size - s2_size) + cy = mpihelp_sub_1(res_ptr + s2_size, s1_ptr + s2_size, + s1_size - s2_size, cy); + return cy; +} + +static mpi_ptr_t mpi_alloc_limb_space(unsigned nlimbs) +{ + size_t len = nlimbs * sizeof(mpi_limb_t); + + if (!len) + return NULL; + + return xmalloc_bytes(len); +} + +static void mpi_free_limb_space(mpi_ptr_t a) +{ + if (!a) + return; + + xfree(a); +} + +/**************** + * Resize the array of A to NLIMBS. the additional space is cleared + * (set to 0) [done by m_realloc()] + */ +static int mpi_resize(MPI a, unsigned nlimbs) +{ + void *p; + + if (nlimbs <= a->alloced) + return 0; /* no need to do it */ + + if (a->d) { + p = xmalloc_array(mpi_limb_t, nlimbs); + if (!p) + return -ENOMEM; + memcpy(p, a->d, a->alloced * sizeof(mpi_limb_t)); + xfree(a->d); + a->d = p; + } else { + a->d = xzalloc_array(mpi_limb_t, nlimbs); + if (!a->d) + return -ENOMEM; + } + a->alloced = nlimbs; + return 0; +} + +/**************** + * RES = BASE ^ EXP mod MOD + */ +int mpi_powm(MPI res, MPI base, MPI exp, MPI mod) +{ + mpi_ptr_t mp_marker = NULL, bp_marker = NULL, ep_marker = NULL; + mpi_ptr_t xp_marker = NULL; + mpi_ptr_t tspace = NULL; + mpi_ptr_t rp, ep, mp, bp; + mpi_size_t esize, msize, bsize, rsize; + int msign, bsign, rsign; + mpi_size_t size; + int mod_shift_cnt; + int negative_result; + int assign_rp = 0; + mpi_size_t tsize = 0; /* to avoid compiler warning */ + /* fixme: we should check that the warning is void */ + int rc = -ENOMEM; + + esize = exp->nlimbs; + msize = mod->nlimbs; + size = 2 * msize; + msign = mod->sign; + + rp = res->d; + ep = exp->d; + + if (!msize) + return -EINVAL; + + if (!esize) { + /* Exponent is zero, result is 1 mod MOD, i.e., 1 or 0 + * depending on if MOD equals 1. */ + res->nlimbs = (msize == 1 && mod->d[0] == 1) ? 0 : 1; + if (res->nlimbs) { + if (mpi_resize(res, 1) < 0) + goto enomem; + rp = res->d; + rp[0] = 1; + } + res->sign = 0; + goto leave; + } + + /* Normalize MOD (i.e. make its most significant bit set) as required by + * mpn_divrem. This will make the intermediate values in the calculation + * slightly larger, but the correct result is obtained after a final + * reduction using the original MOD value. */ + mp = mp_marker = mpi_alloc_limb_space(msize); + if (!mp) + goto enomem; + mod_shift_cnt = count_leading_zeros(mod->d[msize - 1]); + if (mod_shift_cnt) + mpihelp_lshift(mp, mod->d, msize, mod_shift_cnt); + else + MPN_COPY(mp, mod->d, msize); + + bsize = base->nlimbs; + bsign = base->sign; + if (bsize > msize) { /* The base is larger than the module. Reduce it. */ + /* Allocate (BSIZE + 1) with space for remainder and quotient. + * (The quotient is (bsize - msize + 1) limbs.) */ + bp = bp_marker = mpi_alloc_limb_space(bsize + 1); + if (!bp) + goto enomem; + MPN_COPY(bp, base->d, bsize); + /* We don't care about the quotient, store it above the remainder, + * at BP + MSIZE. */ + mpihelp_divrem(bp + msize, 0, bp, bsize, mp, msize); + bsize = msize; + /* Canonicalize the base, since we are going to multiply with it + * quite a few times. */ + MPN_NORMALIZE(bp, bsize); + } else + bp = base->d; + + if (!bsize) { + res->nlimbs = 0; + res->sign = 0; + goto leave; + } + + if (res->alloced < size) { + /* We have to allocate more space for RES. If any of the input + * parameters are identical to RES, defer deallocation of the old + * space. */ + if (rp == ep || rp == mp || rp == bp) { + rp = mpi_alloc_limb_space(size); + if (!rp) + goto enomem; + assign_rp = 1; + } else { + if (mpi_resize(res, size) < 0) + goto enomem; + rp = res->d; + } + } else { /* Make BASE, EXP and MOD not overlap with RES. */ + if (rp == bp) { + /* RES and BASE are identical. Allocate temp. space for BASE. */ + BUG_ON(bp_marker); + bp = bp_marker = mpi_alloc_limb_space(bsize); + if (!bp) + goto enomem; + MPN_COPY(bp, rp, bsize); + } + if (rp == ep) { + /* RES and EXP are identical. Allocate temp. space for EXP. */ + ep = ep_marker = mpi_alloc_limb_space(esize); + if (!ep) + goto enomem; + MPN_COPY(ep, rp, esize); + } + if (rp == mp) { + /* RES and MOD are identical. Allocate temporary space for MOD. */ + BUG_ON(mp_marker); + mp = mp_marker = mpi_alloc_limb_space(msize); + if (!mp) + goto enomem; + MPN_COPY(mp, rp, msize); + } + } + + MPN_COPY(rp, bp, bsize); + rsize = bsize; + rsign = bsign; + + { + mpi_size_t i; + mpi_ptr_t xp; + int c; + mpi_limb_t e; + mpi_limb_t carry_limb; + struct karatsuba_ctx karactx; + + xp = xp_marker = mpi_alloc_limb_space(2 * (msize + 1)); + if (!xp) + goto enomem; + + memset(&karactx, 0, sizeof karactx); + negative_result = (ep[0] & 1) && base->sign; + + i = esize - 1; + e = ep[i]; + c = count_leading_zeros(e); + e = (e << c) << 1; /* shift the exp bits to the left, lose msb */ + c = BITS_PER_MPI_LIMB - 1 - c; + + /* Main loop. + * + * Make the result be pointed to alternately by XP and RP. This + * helps us avoid block copying, which would otherwise be necessary + * with the overlap restrictions of mpihelp_divmod. With 50% probability + * the result after this loop will be in the area originally pointed + * by RP (==RES->d), and with 50% probability in the area originally + * pointed to by XP. + */ + + for (;;) { + while (c) { + mpi_ptr_t tp; + mpi_size_t xsize; + + /*if (mpihelp_mul_n(xp, rp, rp, rsize) < 0) goto enomem */ + if (rsize < KARATSUBA_THRESHOLD) + mpih_sqr_n_basecase(xp, rp, rsize); + else { + if (!tspace) { + tsize = 2 * rsize; + tspace = + mpi_alloc_limb_space(tsize); + if (!tspace) + goto enomem; + } else if (tsize < (2 * rsize)) { + mpi_free_limb_space(tspace); + tsize = 2 * rsize; + tspace = + mpi_alloc_limb_space(tsize); + if (!tspace) + goto enomem; + } + mpih_sqr_n(xp, rp, rsize, tspace); + } + + xsize = 2 * rsize; + if (xsize > msize) { + mpihelp_divrem(xp + msize, 0, xp, xsize, + mp, msize); + xsize = msize; + } + + tp = rp; + rp = xp; + xp = tp; + rsize = xsize; + + if ((mpi_limb_signed_t) e < 0) { + /*mpihelp_mul( xp, rp, rsize, bp, bsize ); */ + if (bsize < KARATSUBA_THRESHOLD) { + mpi_limb_t tmp; + if (mpihelp_mul + (xp, rp, rsize, bp, bsize, + &tmp) < 0) + goto enomem; + } else { + if (mpihelp_mul_karatsuba_case + (xp, rp, rsize, bp, bsize, + &karactx) < 0) + goto enomem; + } + + xsize = rsize + bsize; + if (xsize > msize) { + mpihelp_divrem(xp + msize, 0, + xp, xsize, mp, + msize); + xsize = msize; + } + + tp = rp; + rp = xp; + xp = tp; + rsize = xsize; + } + e <<= 1; + c--; + } + + i--; + if (i < 0) + break; + e = ep[i]; + c = BITS_PER_MPI_LIMB; + } + + /* We shifted MOD, the modulo reduction argument, left MOD_SHIFT_CNT + * steps. Adjust the result by reducing it with the original MOD. + * + * Also make sure the result is put in RES->d (where it already + * might be, see above). + */ + if (mod_shift_cnt) { + carry_limb = + mpihelp_lshift(res->d, rp, rsize, mod_shift_cnt); + rp = res->d; + if (carry_limb) { + rp[rsize] = carry_limb; + rsize++; + } + } else { + MPN_COPY(res->d, rp, rsize); + rp = res->d; + } + + if (rsize >= msize) { + mpihelp_divrem(rp + msize, 0, rp, rsize, mp, msize); + rsize = msize; + } + + /* Remove any leading zero words from the result. */ + if (mod_shift_cnt) + mpihelp_rshift(rp, rp, rsize, mod_shift_cnt); + MPN_NORMALIZE(rp, rsize); + + mpihelp_release_karatsuba_ctx(&karactx); + } + + if (negative_result && rsize) { + if (mod_shift_cnt) + mpihelp_rshift(mp, mp, msize, mod_shift_cnt); + mpihelp_sub(rp, mp, msize, rp, rsize); + rsize = msize; + rsign = msign; + MPN_NORMALIZE(rp, rsize); + } + res->nlimbs = rsize; + res->sign = rsign; + + leave: + rc = 0; + enomem: + if (assign_rp) + mpi_assign_limb_space(res, rp, size); + if (mp_marker) + mpi_free_limb_space(mp_marker); + if (bp_marker) + mpi_free_limb_space(bp_marker); + if (ep_marker) + mpi_free_limb_space(ep_marker); + if (xp_marker) + mpi_free_limb_space(xp_marker); + if (tspace) + mpi_free_limb_space(tspace); + return rc; +} + +/* Multiply the natural numbers u (pointed to by UP) and v (pointed to by VP), + * both with SIZE limbs, and store the result at PRODP. 2 * SIZE limbs are + * always stored. Return the most significant limb. + * + * Argument constraints: + * 1. PRODP != UP and PRODP != VP, i.e. the destination + * must be distinct from the multiplier and the multiplicand. + * + * + * Handle simple cases with traditional multiplication. + * + * This is the most critical code of multiplication. All multiplies rely + * on this, both small and huge. Small ones arrive here immediately. Huge + * ones arrive here as this is the base case for Karatsuba's recursive + * algorithm below. + */ + +static mpi_limb_t +mul_n_basecase(mpi_ptr_t prodp, mpi_ptr_t up, mpi_ptr_t vp, mpi_size_t size) +{ + mpi_size_t i; + mpi_limb_t cy; + mpi_limb_t v_limb; + + /* Multiply by the first limb in V separately, as the result can be + * stored (not added) to PROD. We also avoid a loop for zeroing. */ + v_limb = vp[0]; + if (v_limb <= 1) { + if (v_limb == 1) + MPN_COPY(prodp, up, size); + else + MPN_ZERO(prodp, size); + cy = 0; + } else + cy = mpihelp_mul_1(prodp, up, size, v_limb); + + prodp[size] = cy; + prodp++; + + /* For each iteration in the outer loop, multiply one limb from + * U with one limb from V, and add it to PROD. */ + for (i = 1; i < size; i++) { + v_limb = vp[i]; + if (v_limb <= 1) { + cy = 0; + if (v_limb == 1) + cy = mpihelp_add_n(prodp, prodp, up, size); + } else + cy = mpihelp_addmul_1(prodp, up, size, v_limb); + + prodp[size] = cy; + prodp++; + } + + return cy; +} + +static void +mul_n(mpi_ptr_t prodp, mpi_ptr_t up, mpi_ptr_t vp, + mpi_size_t size, mpi_ptr_t tspace) +{ + if (size & 1) { + /* The size is odd, and the code below doesn't handle that. + * Multiply the least significant (size - 1) limbs with a recursive + * call, and handle the most significant limb of S1 and S2 + * separately. + * A slightly faster way to do this would be to make the Karatsuba + * code below behave as if the size were even, and let it check for + * odd size in the end. I.e., in essence move this code to the end. + * Doing so would save us a recursive call, and potentially make the + * stack grow a lot less. + */ + mpi_size_t esize = size - 1; /* even size */ + mpi_limb_t cy_limb; + + MPN_MUL_N_RECURSE(prodp, up, vp, esize, tspace); + cy_limb = mpihelp_addmul_1(prodp + esize, up, esize, vp[esize]); + prodp[esize + esize] = cy_limb; + cy_limb = mpihelp_addmul_1(prodp + esize, vp, size, up[esize]); + prodp[esize + size] = cy_limb; + } else { + /* Anatolij Alekseevich Karatsuba's divide-and-conquer algorithm. + * + * Split U in two pieces, U1 and U0, such that + * U = U0 + U1*(B**n), + * and V in V1 and V0, such that + * V = V0 + V1*(B**n). + * + * UV is then computed recursively using the identity + * + * 2n n n n + * UV = (B + B )U V + B (U -U )(V -V ) + (B + 1)U V + * 1 1 1 0 0 1 0 0 + * + * Where B = 2**BITS_PER_MP_LIMB. + */ + mpi_size_t hsize = size >> 1; + mpi_limb_t cy; + int negflg; + + /* Product H. ________________ ________________ + * |_____U1 x V1____||____U0 x V0_____| + * Put result in upper part of PROD and pass low part of TSPACE + * as new TSPACE. + */ + MPN_MUL_N_RECURSE(prodp + size, up + hsize, vp + hsize, hsize, + tspace); + + /* Product M. ________________ + * |_(U1-U0)(V0-V1)_| + */ + if (mpihelp_cmp(up + hsize, up, hsize) >= 0) { + mpihelp_sub_n(prodp, up + hsize, up, hsize); + negflg = 0; + } else { + mpihelp_sub_n(prodp, up, up + hsize, hsize); + negflg = 1; + } + if (mpihelp_cmp(vp + hsize, vp, hsize) >= 0) { + mpihelp_sub_n(prodp + hsize, vp + hsize, vp, hsize); + negflg ^= 1; + } else { + mpihelp_sub_n(prodp + hsize, vp, vp + hsize, hsize); + /* No change of NEGFLG. */ + } + /* Read temporary operands from low part of PROD. + * Put result in low part of TSPACE using upper part of TSPACE + * as new TSPACE. + */ + MPN_MUL_N_RECURSE(tspace, prodp, prodp + hsize, hsize, + tspace + size); + + /* Add/copy product H. */ + MPN_COPY(prodp + hsize, prodp + size, hsize); + cy = mpihelp_add_n(prodp + size, prodp + size, + prodp + size + hsize, hsize); + + /* Add product M (if NEGFLG M is a negative number) */ + if (negflg) + cy -= + mpihelp_sub_n(prodp + hsize, prodp + hsize, tspace, + size); + else + cy += + mpihelp_add_n(prodp + hsize, prodp + hsize, tspace, + size); + + /* Product L. ________________ ________________ + * |________________||____U0 x V0_____| + * Read temporary operands from low part of PROD. + * Put result in low part of TSPACE using upper part of TSPACE + * as new TSPACE. + */ + MPN_MUL_N_RECURSE(tspace, up, vp, hsize, tspace + size); + + /* Add/copy Product L (twice) */ + + cy += mpihelp_add_n(prodp + hsize, prodp + hsize, tspace, size); + if (cy) + mpihelp_add_1(prodp + hsize + size, + prodp + hsize + size, hsize, cy); + + MPN_COPY(prodp, tspace, hsize); + cy = mpihelp_add_n(prodp + hsize, prodp + hsize, tspace + hsize, + hsize); + if (cy) + mpihelp_add_1(prodp + size, prodp + size, size, 1); + } +} + +static void mpih_sqr_n_basecase(mpi_ptr_t prodp, mpi_ptr_t up, mpi_size_t size) +{ + mpi_size_t i; + mpi_limb_t cy_limb; + mpi_limb_t v_limb; + + /* Multiply by the first limb in V separately, as the result can be + * stored (not added) to PROD. We also avoid a loop for zeroing. */ + v_limb = up[0]; + if (v_limb <= 1) { + if (v_limb == 1) + MPN_COPY(prodp, up, size); + else + MPN_ZERO(prodp, size); + cy_limb = 0; + } else + cy_limb = mpihelp_mul_1(prodp, up, size, v_limb); + + prodp[size] = cy_limb; + prodp++; + + /* For each iteration in the outer loop, multiply one limb from + * U with one limb from V, and add it to PROD. */ + for (i = 1; i < size; i++) { + v_limb = up[i]; + if (v_limb <= 1) { + cy_limb = 0; + if (v_limb == 1) + cy_limb = mpihelp_add_n(prodp, prodp, up, size); + } else + cy_limb = mpihelp_addmul_1(prodp, up, size, v_limb); + + prodp[size] = cy_limb; + prodp++; + } +} + +static void +mpih_sqr_n(mpi_ptr_t prodp, mpi_ptr_t up, mpi_size_t size, mpi_ptr_t tspace) +{ + if (size & 1) { + /* The size is odd, and the code below doesn't handle that. + * Multiply the least significant (size - 1) limbs with a recursive + * call, and handle the most significant limb of S1 and S2 + * separately. + * A slightly faster way to do this would be to make the Karatsuba + * code below behave as if the size were even, and let it check for + * odd size in the end. I.e., in essence move this code to the end. + * Doing so would save us a recursive call, and potentially make the + * stack grow a lot less. + */ + mpi_size_t esize = size - 1; /* even size */ + mpi_limb_t cy_limb; + + MPN_SQR_N_RECURSE(prodp, up, esize, tspace); + cy_limb = mpihelp_addmul_1(prodp + esize, up, esize, up[esize]); + prodp[esize + esize] = cy_limb; + cy_limb = mpihelp_addmul_1(prodp + esize, up, size, up[esize]); + + prodp[esize + size] = cy_limb; + } else { + mpi_size_t hsize = size >> 1; + mpi_limb_t cy; + + /* Product H. ________________ ________________ + * |_____U1 x U1____||____U0 x U0_____| + * Put result in upper part of PROD and pass low part of TSPACE + * as new TSPACE. + */ + MPN_SQR_N_RECURSE(prodp + size, up + hsize, hsize, tspace); + + /* Product M. ________________ + * |_(U1-U0)(U0-U1)_| + */ + if (mpihelp_cmp(up + hsize, up, hsize) >= 0) + mpihelp_sub_n(prodp, up + hsize, up, hsize); + else + mpihelp_sub_n(prodp, up, up + hsize, hsize); + + /* Read temporary operands from low part of PROD. + * Put result in low part of TSPACE using upper part of TSPACE + * as new TSPACE. */ + MPN_SQR_N_RECURSE(tspace, prodp, hsize, tspace + size); + + /* Add/copy product H */ + MPN_COPY(prodp + hsize, prodp + size, hsize); + cy = mpihelp_add_n(prodp + size, prodp + size, + prodp + size + hsize, hsize); + + /* Add product M (if NEGFLG M is a negative number). */ + cy -= mpihelp_sub_n(prodp + hsize, prodp + hsize, tspace, size); + + /* Product L. ________________ ________________ + * |________________||____U0 x U0_____| + * Read temporary operands from low part of PROD. + * Put result in low part of TSPACE using upper part of TSPACE + * as new TSPACE. */ + MPN_SQR_N_RECURSE(tspace, up, hsize, tspace + size); + + /* Add/copy Product L (twice). */ + cy += mpihelp_add_n(prodp + hsize, prodp + hsize, tspace, size); + if (cy) + mpihelp_add_1(prodp + hsize + size, + prodp + hsize + size, hsize, cy); + + MPN_COPY(prodp, tspace, hsize); + cy = mpihelp_add_n(prodp + hsize, prodp + hsize, tspace + hsize, + hsize); + if (cy) + mpihelp_add_1(prodp + size, prodp + size, size, 1); + } +} + +static int +mpihelp_mul_karatsuba_case(mpi_ptr_t prodp, + mpi_ptr_t up, mpi_size_t usize, + mpi_ptr_t vp, mpi_size_t vsize, + struct karatsuba_ctx *ctx) +{ + mpi_limb_t cy; + + if (!ctx->tspace || ctx->tspace_size < vsize) { + if (ctx->tspace) + mpi_free_limb_space(ctx->tspace); + ctx->tspace = mpi_alloc_limb_space(2 * vsize); + if (!ctx->tspace) + return -ENOMEM; + ctx->tspace_size = vsize; + } + + MPN_MUL_N_RECURSE(prodp, up, vp, vsize, ctx->tspace); + + prodp += vsize; + up += vsize; + usize -= vsize; + if (usize >= vsize) { + if (!ctx->tp || ctx->tp_size < vsize) { + if (ctx->tp) + mpi_free_limb_space(ctx->tp); + ctx->tp = mpi_alloc_limb_space(2 * vsize); + if (!ctx->tp) { + if (ctx->tspace) + mpi_free_limb_space(ctx->tspace); + ctx->tspace = NULL; + return -ENOMEM; + } + ctx->tp_size = vsize; + } + + do { + MPN_MUL_N_RECURSE(ctx->tp, up, vp, vsize, ctx->tspace); + cy = mpihelp_add_n(prodp, prodp, ctx->tp, vsize); + mpihelp_add_1(prodp + vsize, ctx->tp + vsize, vsize, + cy); + prodp += vsize; + up += vsize; + usize -= vsize; + } while (usize >= vsize); + } + + if (usize) { + if (usize < KARATSUBA_THRESHOLD) { + mpi_limb_t tmp; + if (mpihelp_mul(ctx->tspace, vp, vsize, up, usize, &tmp) + < 0) + return -ENOMEM; + } else { + if (!ctx->next) { + ctx->next = xzalloc(struct karatsuba_ctx); + if (!ctx->next) + return -ENOMEM; + } + if (mpihelp_mul_karatsuba_case(ctx->tspace, + vp, vsize, + up, usize, + ctx->next) < 0) + return -ENOMEM; + } + + cy = mpihelp_add_n(prodp, prodp, ctx->tspace, vsize); + mpihelp_add_1(prodp + vsize, ctx->tspace + vsize, usize, cy); + } + + return 0; +} + +static void mpihelp_release_karatsuba_ctx(struct karatsuba_ctx *ctx) +{ + struct karatsuba_ctx *ctx2; + + if (ctx->tp) + mpi_free_limb_space(ctx->tp); + if (ctx->tspace) + mpi_free_limb_space(ctx->tspace); + for (ctx = ctx->next; ctx; ctx = ctx2) { + ctx2 = ctx->next; + if (ctx->tp) + mpi_free_limb_space(ctx->tp); + if (ctx->tspace) + mpi_free_limb_space(ctx->tspace); + xfree(ctx); + } +} + +/* Multiply the natural numbers u (pointed to by UP, with USIZE limbs) + * and v (pointed to by VP, with VSIZE limbs), and store the result at + * PRODP. USIZE + VSIZE limbs are always stored, but if the input + * operands are normalized. Return the most significant limb of the + * result. + * + * NOTE: The space pointed to by PRODP is overwritten before finished + * with U and V, so overlap is an error. + * + * Argument constraints: + * 1. USIZE >= VSIZE. + * 2. PRODP != UP and PRODP != VP, i.e. the destination + * must be distinct from the multiplier and the multiplicand. + */ + +static int +mpihelp_mul(mpi_ptr_t prodp, mpi_ptr_t up, mpi_size_t usize, + mpi_ptr_t vp, mpi_size_t vsize, mpi_limb_t *_result) +{ + mpi_ptr_t prod_endp = prodp + usize + vsize - 1; + mpi_limb_t cy; + struct karatsuba_ctx ctx; + + if (vsize < KARATSUBA_THRESHOLD) { + mpi_size_t i; + mpi_limb_t v_limb; + + if (!vsize) { + *_result = 0; + return 0; + } + + /* Multiply by the first limb in V separately, as the result can be + * stored (not added) to PROD. We also avoid a loop for zeroing. */ + v_limb = vp[0]; + if (v_limb <= 1) { + if (v_limb == 1) + MPN_COPY(prodp, up, usize); + else + MPN_ZERO(prodp, usize); + cy = 0; + } else + cy = mpihelp_mul_1(prodp, up, usize, v_limb); + + prodp[usize] = cy; + prodp++; + + /* For each iteration in the outer loop, multiply one limb from + * U with one limb from V, and add it to PROD. */ + for (i = 1; i < vsize; i++) { + v_limb = vp[i]; + if (v_limb <= 1) { + cy = 0; + if (v_limb == 1) + cy = mpihelp_add_n(prodp, prodp, up, + usize); + } else + cy = mpihelp_addmul_1(prodp, up, usize, v_limb); + + prodp[usize] = cy; + prodp++; + } + + *_result = cy; + return 0; + } + + memset(&ctx, 0, sizeof ctx); + if (mpihelp_mul_karatsuba_case(prodp, up, usize, vp, vsize, &ctx) < 0) + return -ENOMEM; + mpihelp_release_karatsuba_ctx(&ctx); + *_result = *prod_endp; + return 0; +} + +static mpi_limb_t +mpihelp_mul_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, mpi_size_t s1_size, + mpi_limb_t s2_limb) +{ + mpi_limb_t cy_limb; + mpi_size_t j; + mpi_limb_t prod_high, prod_low; + + /* The loop counter and index J goes from -S1_SIZE to -1. This way + * the loop becomes faster. */ + j = -s1_size; + + /* Offset the base pointers to compensate for the negative indices. */ + s1_ptr -= j; + res_ptr -= j; + + cy_limb = 0; + do { + umul_ppmm(prod_high, prod_low, s1_ptr[j], s2_limb); + prod_low += cy_limb; + cy_limb = (prod_low < cy_limb ? 1 : 0) + prod_high; + res_ptr[j] = prod_low; + } while (++j); + + return cy_limb; +} + +static mpi_limb_t +mpihelp_add_n(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, + mpi_ptr_t s2_ptr, mpi_size_t size) +{ + mpi_limb_t x, y, cy; + mpi_size_t j; + + /* The loop counter and index J goes from -SIZE to -1. This way + the loop becomes faster. */ + j = -size; + + /* Offset the base pointers to compensate for the negative indices. */ + s1_ptr -= j; + s2_ptr -= j; + res_ptr -= j; + + cy = 0; + do { + y = s2_ptr[j]; + x = s1_ptr[j]; + y += cy; /* add previous carry to one addend */ + cy = y < cy; /* get out carry from that addition */ + y += x; /* add other addend */ + cy += y < x; /* get out carry from that add, combine */ + res_ptr[j] = y; + } while (++j); + + return cy; +} + +/* Shift U (pointed to by UP and USIZE digits long) CNT bits to the left + * and store the USIZE least significant digits of the result at WP. + * Return the bits shifted out from the most significant digit. + * + * Argument constraints: + * 1. 0 < CNT < BITS_PER_MP_LIMB + * 2. If the result is to be written over the input, WP must be >= UP. + */ + +static mpi_limb_t +mpihelp_lshift(mpi_ptr_t wp, mpi_ptr_t up, mpi_size_t usize, unsigned int cnt) +{ + mpi_limb_t high_limb, low_limb; + unsigned sh_1, sh_2; + mpi_size_t i; + mpi_limb_t retval; + + sh_1 = cnt; + wp += 1; + sh_2 = BITS_PER_MPI_LIMB - sh_1; + i = usize - 1; + low_limb = up[i]; + retval = low_limb >> sh_2; + high_limb = low_limb; + while (--i >= 0) { + low_limb = up[i]; + wp[i] = (high_limb << sh_1) | (low_limb >> sh_2); + high_limb = low_limb; + } + wp[i] = high_limb << sh_1; + + return retval; +} + +static mpi_limb_t +mpihelp_addmul_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, + mpi_size_t s1_size, mpi_limb_t s2_limb) +{ + mpi_limb_t cy_limb; + mpi_size_t j; + mpi_limb_t prod_high, prod_low; + mpi_limb_t x; + + /* The loop counter and index J goes from -SIZE to -1. This way + * the loop becomes faster. */ + j = -s1_size; + res_ptr -= j; + s1_ptr -= j; + + cy_limb = 0; + do { + umul_ppmm(prod_high, prod_low, s1_ptr[j], s2_limb); + + prod_low += cy_limb; + cy_limb = (prod_low < cy_limb ? 1 : 0) + prod_high; + + x = res_ptr[j]; + prod_low = x + prod_low; + cy_limb += prod_low < x ? 1 : 0; + res_ptr[j] = prod_low; + } while (++j); + return cy_limb; +} + +static mpi_limb_t +mpihelp_sub_n(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, + mpi_ptr_t s2_ptr, mpi_size_t size) +{ + mpi_limb_t x, y, cy; + mpi_size_t j; + + /* The loop counter and index J goes from -SIZE to -1. This way + the loop becomes faster. */ + j = -size; + + /* Offset the base pointers to compensate for the negative indices. */ + s1_ptr -= j; + s2_ptr -= j; + res_ptr -= j; + + cy = 0; + do { + y = s2_ptr[j]; + x = s1_ptr[j]; + y += cy; /* add previous carry to subtrahend */ + cy = y < cy; /* get out carry from that addition */ + y = x - y; /* main subtract */ + cy += y > x; /* get out carry from the subtract, combine */ + res_ptr[j] = y; + } while (++j); + + return cy; +} + +/**************** + * Compare OP1_PTR/OP1_SIZE with OP2_PTR/OP2_SIZE. + * There are no restrictions on the relative sizes of + * the two arguments. + * Return 1 if OP1 > OP2, 0 if they are equal, and -1 if OP1 < OP2. + */ +static int mpihelp_cmp(mpi_ptr_t op1_ptr, mpi_ptr_t op2_ptr, mpi_size_t size) +{ + mpi_size_t i; + mpi_limb_t op1_word, op2_word; + + for (i = size - 1; i >= 0; i--) { + op1_word = op1_ptr[i]; + op2_word = op2_ptr[i]; + if (op1_word != op2_word) + goto diff; + } + return 0; + + diff: + /* This can *not* be simplified to + * op2_word - op2_word + * since that expression might give signed overflow. */ + return (op1_word > op2_word) ? 1 : -1; +} + +static void mpi_assign_limb_space(MPI a, mpi_ptr_t ap, unsigned nlimbs) +{ + mpi_free_limb_space(a->d); + a->d = ap; + a->alloced = nlimbs; +} + +/* Shift U (pointed to by UP and USIZE limbs long) CNT bits to the right + * and store the USIZE least significant limbs of the result at WP. + * The bits shifted out to the right are returned. + * + * Argument constraints: + * 1. 0 < CNT < BITS_PER_MP_LIMB + * 2. If the result is to be written over the input, WP must be <= UP. + */ + +static mpi_limb_t +mpihelp_rshift(mpi_ptr_t wp, mpi_ptr_t up, mpi_size_t usize, unsigned cnt) +{ + mpi_limb_t high_limb, low_limb; + unsigned sh_1, sh_2; + mpi_size_t i; + mpi_limb_t retval; + + sh_1 = cnt; + wp -= 1; + sh_2 = BITS_PER_MPI_LIMB - sh_1; + high_limb = up[0]; + retval = high_limb << sh_2; + low_limb = high_limb; + for (i = 1; i < usize; i++) { + high_limb = up[i]; + wp[i] = (low_limb >> sh_1) | (high_limb << sh_2); + low_limb = high_limb; + } + wp[i] = low_limb >> sh_1; + + return retval; +} + +/* Divide num (NP/NSIZE) by den (DP/DSIZE) and write + * the NSIZE-DSIZE least significant quotient limbs at QP + * and the DSIZE long remainder at NP. If QEXTRA_LIMBS is + * non-zero, generate that many fraction bits and append them after the + * other quotient limbs. + * Return the most significant limb of the quotient, this is always 0 or 1. + * + * Preconditions: + * 0. NSIZE >= DSIZE. + * 1. The most significant bit of the divisor must be set. + * 2. QP must either not overlap with the input operands at all, or + * QP + DSIZE >= NP must hold true. (This means that it's + * possible to put the quotient in the high part of NUM, right after the + * remainder in NUM. + * 3. NSIZE >= DSIZE, even if QEXTRA_LIMBS is non-zero. + */ + +static mpi_limb_t +mpihelp_divrem(mpi_ptr_t qp, mpi_size_t qextra_limbs, + mpi_ptr_t np, mpi_size_t nsize, mpi_ptr_t dp, mpi_size_t dsize) +{ + mpi_limb_t most_significant_q_limb = 0; + + switch (dsize) { + case 0: + /* We are asked to divide by zero, so go ahead and do it! (To make + the compiler not remove this statement, return the value.) */ + /* + * existing clients of this function have been modified + * not to call it with dsize == 0, so this should not happen + */ + return 1 / dsize; + + case 1: + { + mpi_size_t i; + mpi_limb_t n1; + mpi_limb_t d; + + d = dp[0]; + n1 = np[nsize - 1]; + + if (n1 >= d) { + n1 -= d; + most_significant_q_limb = 1; + } + + qp += qextra_limbs; + for (i = nsize - 2; i >= 0; i--) + udiv_qrnnd(qp[i], n1, n1, np[i], d); + qp -= qextra_limbs; + + for (i = qextra_limbs - 1; i >= 0; i--) + udiv_qrnnd(qp[i], n1, n1, 0, d); + + np[0] = n1; + } + break; + + case 2: + { + mpi_size_t i; + mpi_limb_t n1, n0, n2; + mpi_limb_t d1, d0; + + np += nsize - 2; + d1 = dp[1]; + d0 = dp[0]; + n1 = np[1]; + n0 = np[0]; + + if (n1 >= d1 && (n1 > d1 || n0 >= d0)) { + sub_ddmmss(n1, n0, n1, n0, d1, d0); + most_significant_q_limb = 1; + } + + for (i = qextra_limbs + nsize - 2 - 1; i >= 0; i--) { + mpi_limb_t q; + mpi_limb_t r; + + if (i >= qextra_limbs) + np--; + else + np[0] = 0; + + if (n1 == d1) { + /* Q should be either 111..111 or 111..110. Need special + * treatment of this rare case as normal division would + * give overflow. */ + q = ~(mpi_limb_t) 0; + + r = n0 + d1; + if (r < d1) { /* Carry in the addition? */ + add_ssaaaa(n1, n0, r - d0, + np[0], 0, d0); + qp[i] = q; + continue; + } + n1 = d0 - (d0 != 0 ? 1 : 0); + n0 = -d0; + } else { + udiv_qrnnd(q, r, n1, n0, d1); + umul_ppmm(n1, n0, d0, q); + } + + n2 = np[0]; + q_test: + if (n1 > r || (n1 == r && n0 > n2)) { + /* The estimated Q was too large. */ + q--; + sub_ddmmss(n1, n0, n1, n0, 0, d0); + r += d1; + if (r >= d1) /* If not carry, test Q again. */ + goto q_test; + } + + qp[i] = q; + sub_ddmmss(n1, n0, r, n2, n1, n0); + } + np[1] = n1; + np[0] = n0; + } + break; + + default: + { + mpi_size_t i; + mpi_limb_t dX, d1, n0; + + np += nsize - dsize; + dX = dp[dsize - 1]; + d1 = dp[dsize - 2]; + n0 = np[dsize - 1]; + + if (n0 >= dX) { + if (n0 > dX + || mpihelp_cmp(np, dp, dsize - 1) >= 0) { + mpihelp_sub_n(np, np, dp, dsize); + n0 = np[dsize - 1]; + most_significant_q_limb = 1; + } + } + + for (i = qextra_limbs + nsize - dsize - 1; i >= 0; i--) { + mpi_limb_t q; + mpi_limb_t n1, n2; + mpi_limb_t cy_limb; + + if (i >= qextra_limbs) { + np--; + n2 = np[dsize]; + } else { + n2 = np[dsize - 1]; + MPN_COPY_DECR(np + 1, np, dsize - 1); + np[0] = 0; + } + + if (n0 == dX) { + /* This might over-estimate q, but it's probably not worth + * the extra code here to find out. */ + q = ~(mpi_limb_t) 0; + } else { + mpi_limb_t r; + + udiv_qrnnd(q, r, n0, np[dsize - 1], dX); + umul_ppmm(n1, n0, d1, q); + + while (n1 > r + || (n1 == r + && n0 > np[dsize - 2])) { + q--; + r += dX; + if (r < dX) /* I.e. "carry in previous addition?" */ + break; + n1 -= n0 < d1; + n0 -= d1; + } + } + + /* Possible optimization: We already have (q * n0) and (1 * n1) + * after the calculation of q. Taking advantage of that, we + * could make this loop make two iterations less. */ + cy_limb = mpihelp_submul_1(np, dp, dsize, q); + + if (n2 != cy_limb) { + mpihelp_add_n(np, np, dp, dsize); + q--; + } + + qp[i] = q; + n0 = np[dsize - 1]; + } + } + break; + } + + return most_significant_q_limb; +} + +static mpi_limb_t +mpihelp_submul_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, + mpi_size_t s1_size, mpi_limb_t s2_limb) +{ + mpi_limb_t cy_limb; + mpi_size_t j; + mpi_limb_t prod_high, prod_low; + mpi_limb_t x; + + /* The loop counter and index J goes from -SIZE to -1. This way + * the loop becomes faster. */ + j = -s1_size; + res_ptr -= j; + s1_ptr -= j; + + cy_limb = 0; + do { + umul_ppmm(prod_high, prod_low, s1_ptr[j], s2_limb); + + prod_low += cy_limb; + cy_limb = (prod_low < cy_limb ? 1 : 0) + prod_high; + + x = res_ptr[j]; + prod_low = x - prod_low; + cy_limb += prod_low > x ? 1 : 0; + res_ptr[j] = prod_low; + } while (++j); + + return cy_limb; +} + +/** + * mpi_read_raw_data - Read a raw byte stream as a positive integer + * @xbuffer: The data to read + * @nbytes: The amount of data to read + */ +MPI mpi_read_raw_data(const void *xbuffer, size_t nbytes) +{ + const uint8_t *buffer = xbuffer; + int i, j; + unsigned nbits, nlimbs; + mpi_limb_t a; + MPI val = NULL; + + while (nbytes > 0 && buffer[0] == 0) { + buffer++; + nbytes--; + } + + nbits = nbytes * 8; + if (nbits > MAX_EXTERN_MPI_BITS) { + printk("MPI: mpi too large (%u bits)\n", nbits); + return NULL; + } + if (nbytes > 0) + nbits -= count_leading_zeros(buffer[0]) - (BITS_PER_LONG - 8); + + nlimbs = DIV_ROUND_UP(nbytes, BYTES_PER_MPI_LIMB); + val = mpi_alloc(nlimbs); + if (!val) + return NULL; + val->nbits = nbits; + val->sign = 0; + val->nlimbs = nlimbs; + + if (nbytes > 0) { + i = BYTES_PER_MPI_LIMB - nbytes % BYTES_PER_MPI_LIMB; + i %= BYTES_PER_MPI_LIMB; + for (j = nlimbs; j > 0; j--) { + a = 0; + for (; i < BYTES_PER_MPI_LIMB; i++) { + a <<= 8; + a |= *buffer++; + } + i = 0; + val->d[j - 1] = a; + } + } + return val; +} + +/**************** + * Note: It was a bad idea to use the number of limbs to allocate + * because on a alpha the limbs are large but we normally need + * integers of n bits - So we should chnage this to bits (or bytes). + * + * But mpi_alloc is used in a lot of places :-) + */ +MPI mpi_alloc(unsigned nlimbs) +{ + MPI a; + + a = xmalloc(struct mpi); + if (!a) + return a; + + if (nlimbs) { + a->d = mpi_alloc_limb_space(nlimbs); + if (!a->d) { + xfree(a); + return NULL; + } + } else { + a->d = NULL; + } + + a->alloced = nlimbs; + a->nlimbs = 0; + a->sign = 0; + a->flags = 0; + a->nbits = 0; + return a; +} + +void mpi_free(MPI a) +{ + if (!a) + return; + + if (a->flags & MPI_FLAG_PTR_ALLOC) + xfree(a->d); + else + mpi_free_limb_space(a->d); + + if (a->flags & ~MPI_FLAG_MASK) + printk("invalid flag value in mpi\n"); + xfree(a); +} + +int mpi_cmp_ui(MPI u, unsigned long v) +{ + mpi_limb_t limb = v; + + mpi_normalize(u); + if (!u->nlimbs && !limb) + return 0; + if (u->sign) + return -1; + if (u->nlimbs > 1) + return 1; + + if (u->d[0] == limb) + return 0; + else if (u->d[0] > limb) + return 1; + else + return -1; +} + +int mpi_cmp(MPI u, MPI v) +{ + mpi_size_t usize, vsize; + int cmp; + + mpi_normalize(u); + mpi_normalize(v); + usize = u->nlimbs; + vsize = v->nlimbs; + if (!u->sign && v->sign) + return 1; + if (u->sign && !v->sign) + return -1; + if (usize != vsize && !u->sign && !v->sign) + return usize - vsize; + if (usize != vsize && u->sign && v->sign) + return vsize - usize; + if (!usize) + return 0; + cmp = mpihelp_cmp(u->d, v->d, usize); + if (u->sign) + return -cmp; + return cmp; +} + +/**************** + * Sometimes we have MSL (most significant limbs) which are 0; + * this is for some reasons not good, so this function removes them. + */ +static void mpi_normalize(MPI a) +{ + for (; a->nlimbs && !a->d[a->nlimbs - 1]; a->nlimbs--) + ; +} + +/**************** + * Return the number of bits in A. + */ +unsigned mpi_get_nbits(MPI a) +{ + unsigned n; + + mpi_normalize(a); + + if (a->nlimbs) { + mpi_limb_t alimb = a->d[a->nlimbs - 1]; + if (alimb) + n = count_leading_zeros(alimb); + else + n = BITS_PER_MPI_LIMB; + n = BITS_PER_MPI_LIMB - n + (a->nlimbs - 1) * BITS_PER_MPI_LIMB; + } else + n = 0; + return n; +} + +int mpi_test_bit(MPI a, unsigned int n) +{ + unsigned int limbno, bitno; + mpi_limb_t limb; + + limbno = n / BITS_PER_MPI_LIMB; + bitno = n % BITS_PER_MPI_LIMB; + + if (limbno >= a->nlimbs) + return 0; /* too far left: this is a 0 */ + limb = a->d[limbno]; + return (limb & (((mpi_limb_t)1) << bitno))? 1: 0; +} -- 2.49.0 From xen-devel-bounces@lists.xenproject.org Mon Jun 02 13:37:02 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 13:37:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003324.1382884 (Exim 4.92) (envelope-from ) id 1uM5LX-00016N-B0; Mon, 02 Jun 2025 13:36:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003324.1382884; Mon, 02 Jun 2025 13:36:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uM5LX-00016G-7v; Mon, 02 Jun 2025 13:36:59 +0000 Received: by outflank-mailman (input) for mailman id 1003324; Mon, 02 Jun 2025 13:36: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 1uM5LV-00009x-B6 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 13:36:57 +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 a0776e5c-3fb6-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 15:36:45 +0200 (CEST) Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-606741e8e7cso1199296a12.1 for ; Mon, 02 Jun 2025 06:36:45 -0700 (PDT) Received: from rossla-pc.eng.citrite.net ([185.25.67.249]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ada5d82becbsm801962166b.39.2025.06.02.06.36.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 06:36:44 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a0776e5c-3fb6-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1748871405; x=1749476205; 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=yy53j1DOU6WWUw+PBhTlbtLkLrjDWtoXUpgaf2G0MZI=; b=fAvRw2IZl3fv5MEP+1gQDTRCWvotG4ZIh+GBdr7K3c8/EH0DkrF62WGpO/4v2AFt2e 6tDx9DjlIg6i/IdwJ0SuLAclrflYBJLZw2r/KpDGwZ+QwGNOAnnR+GJs/ZQczfzzEx48 QT/Hf9Irxn6t8IZzBZG5PDyVhVsyIkKy9OyaY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748871405; x=1749476205; 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=yy53j1DOU6WWUw+PBhTlbtLkLrjDWtoXUpgaf2G0MZI=; b=Hn4H+G0bEgnouTSPE/EzSex14JlkFs9mUR6aGn6YujW/G6qZi0t06TbsbBRYqTzzug fpAlZJqjL1ENEMEcm5KCdiOAB5fSFznEFscfh2p54tVaDk8blX2EsLYr3g2WsjM0urnb SKdDDAYXwxn2z2dIDydFA2C4p4reYJ4jQ3Ofy2PWt48+BxS/TVHV7keX1rZ6GZzo6aMG GneBkkWwLTJcGMg+0k7ol7sH0j7ehRSUKuPULahMdosbuoaVMwq2CnpCezgdITWz/ghz zicQDWhbFcHnNvYZb7J+0GMyUm/Jucs6JNqvl7b+teeVKSGrGv11qn3r7jrKNgVH75VG UGiQ== X-Gm-Message-State: AOJu0YzZoED1lkIEsNklWbAqcSgxQkMWQPUuicGz/uBZn/xa3GQpozUV MtSlRxvmbTOrhhwTF1PpLebtMoum2juhFbmLCH+xCanGaSj9Ubpc4jB4dvs6o32HMVKVtH7K7un 8f7I= X-Gm-Gg: ASbGncsyWZcqm+/UujpDiFU2/1JkW6usuJ1GbIiLiq9jsKPgDskDgiHF7aL1Dglpt7u Cn4fTfPCVghg7P4f0gAokUfnAUHEIgUDVQnZyekbLpXwBbG1ESWTpGSow0bCfuybtv4XXeDy8cf h5k9MiKQXI1n4M2bYWWvqrem2A3kdZ3fCNjxRcu97o0y+cC+mvOfGhEHHYgxP+tVxZSejipCFL5 qJxepJISq3/aLmXs+ODIwC7Ujp1a1XlCj7c7KY18Rw5apsu+arP/yF/IoGwT3zjcqwY6MfyzrJS 0S+hNBzMYbFyLsRGRiPX+jUaQoZvTTvhb6OS3K2bhmT9OihGTguQrcxKe12BwquzuPI6UCCNcL6 Gvm/bDph15A== X-Google-Smtp-Source: AGHT+IFpP/DPyjJsrVxJduaDWmB2TXpnjhtrBnEJgFtvQkMmvBFskmlVj4MaJ6HCh10KwIxdPLIVMw== X-Received: by 2002:a17:907:3f12:b0:ad8:9d41:371e with SMTP id a640c23a62f3a-adb322fe389mr1448220566b.36.1748871405037; Mon, 02 Jun 2025 06:36:45 -0700 (PDT) From: Ross Lagerwall To: xen-devel@lists.xenproject.org Cc: Ross Lagerwall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: [PATCH v3 0/5] LivePatch signing support Date: Mon, 2 Jun 2025 14:36:32 +0100 Message-ID: <20250602133639.2871212-1-ross.lagerwall@citrix.com> X-Mailer: git-send-email 2.49.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Live patch signing support was mentioned as future work in the design document several years ago. This series finally implements support for it since it is a requirement of Secure Boot to prevent loading unsigned code into Xen. See the individual patches for what has changed in v3. Jennifer Herbert (1): livepatch: Verify livepatch signatures Kevin Lampis (1): livepatch: Embed public key in Xen Ross Lagerwall (3): docs: Introduce live patch signing crypto: Add RSA support livepatch: Load built-in key during boot docs/misc/livepatch.pandoc | 106 +- xen/common/Kconfig | 18 + xen/common/livepatch.c | 139 +++ xen/common/livepatch_elf.c | 55 + xen/crypto/Makefile | 12 + xen/crypto/rsa.c | 196 ++++ xen/include/xen/livepatch.h | 15 + xen/include/xen/livepatch_elf.h | 18 + xen/include/xen/mpi.h | 68 ++ xen/include/xen/rsa.h | 74 ++ xen/lib/Makefile | 1 + xen/lib/mpi.c | 1729 +++++++++++++++++++++++++++++++ xen/tools/extract-key.py | 40 + 13 files changed, 2419 insertions(+), 52 deletions(-) create mode 100644 xen/crypto/rsa.c create mode 100644 xen/include/xen/mpi.h create mode 100644 xen/include/xen/rsa.h create mode 100644 xen/lib/mpi.c create mode 100755 xen/tools/extract-key.py -- 2.49.0 From xen-devel-bounces@lists.xenproject.org Mon Jun 02 13:37:02 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 13:37:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003325.1382889 (Exim 4.92) (envelope-from ) id 1uM5LX-00019O-LM; Mon, 02 Jun 2025 13:36:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003325.1382889; Mon, 02 Jun 2025 13:36:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uM5LX-00018U-Fe; Mon, 02 Jun 2025 13:36:59 +0000 Received: by outflank-mailman (input) for mailman id 1003325; Mon, 02 Jun 2025 13:36: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 1uM5LV-0000AN-Pi for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 13:36: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 a75c4373-3fb6-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 15:36:57 +0200 (CEST) Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-acb39c45b4eso709648366b.1 for ; Mon, 02 Jun 2025 06:36:57 -0700 (PDT) Received: from rossla-pc.eng.citrite.net ([185.25.67.249]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ada5d82becbsm801962166b.39.2025.06.02.06.36.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 06:36:55 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a75c4373-3fb6-11f0-a300-13f23c93f187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1748871416; x=1749476216; darn=lists.xenproject.org; h=content-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=xN7zQNXihUlijbgV6bSCt7tkvkUX3nHa7idYxDq6Di8=; b=iDCMNbN1PXalTU2jWFC5KO/J9e0tBgS/01oVT/VVqXhonbw4T4hz9OuPlfoK7XVR1w G+pSel21H2EbrwweuySyeLbokCL9ZIk9NzzHI41syvlCzBEWEIu1aiUgwJwbkzv++WrF 5vJlXKji7khC5HM0YDfl9X4t9On4HvshWl2+g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748871416; x=1749476216; 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=xN7zQNXihUlijbgV6bSCt7tkvkUX3nHa7idYxDq6Di8=; b=K+a54KKWD8W+tbdZHLPQ9XoXjI4UZTF+M4lDCcPYIqv35EstMmePji1H3ccOa2cD+p vcyqNN+M+8Z5mey/lqLWTNiGCQdClaYD2V5Tfs67GcT/lBZ90/y/kRdrdbc1bHG5UvZq nWwvDFmZpw03aahflis+75HbncF/40bLzsMomr5cSswgNPpO/3HFM1DZ5dB7Jf3esVWC HzpKN2S2hl8NimdR389nXeUTSN5OUhWKTAXVUlyyH+gAyUsx3owLoEqq9c9l2ftn7xoH ME7KnvhEC6ALpDzIW6B+tdR4KSm5VYI0dwpKg13C/Q1LxRgpFOFQkNAbzKcGRC158QS0 SIqw== X-Gm-Message-State: AOJu0YyliFVr2/khMbGQvnCstlCIVNKmbYdAq/UWGfbvNroWolOtxSIA WF+6kpFH4zdTqnoBDCuHY6S6utDrH+E6wqOR+UmdjUh/bfBNF/ghHeHEABoM8LFB6maxrLBCqyt yjMk= X-Gm-Gg: ASbGncskLe+1RwgDmILSwt59Gs4LjsgOyi9TLD6uUYpKUXl2KIty+pANQ0216Jinwzk pGp1zXFT1gQov0auUaenZj7OAofEK5vKN54qVArtMZf8VJ0scFq4xr84XfeqV+sKcmzlOG4SAqp sBOp6TJziS10KGtLy6CzNyvbZVRG0XJmDgBkKzw3DRJii8KSqDglIGGHEtPWtqW72bE8/Avz0fA 0zAyWF0Qtx7NzoHeRhAliGKsSrHICbHAo/BCakCPWeOoIU7S7hFF9WgD9xbfLn7HjS6gU/p3Nbt ZHpFEPwaf//RmPZgJcMY8h7ShUsqPjHVYfClsop+euIF10GKf+KRoqK1XVIidkaN3iFOuZZEip2 X5YIcCWy31w== X-Google-Smtp-Source: AGHT+IGS/er/Ph6frH7OwftA6z4tvqTxkoXIM3ibqtdHZvxd7ceD8DeUWCX9Q4Szhd1tn/kRrTfDlA== X-Received: by 2002:a17:906:3d3:b0:adb:413e:2a2f with SMTP id a640c23a62f3a-adb413e2ae7mr631194466b.9.1748871416434; Mon, 02 Jun 2025 06:36:56 -0700 (PDT) From: Ross Lagerwall To: xen-devel@lists.xenproject.org Cc: Jennifer Herbert , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Ross Lagerwall Subject: [PATCH v3 5/5] livepatch: Verify livepatch signatures Date: Mon, 2 Jun 2025 14:36:37 +0100 Message-ID: <20250602133639.2871212-6-ross.lagerwall@citrix.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250602133639.2871212-1-ross.lagerwall@citrix.com> References: <20250602133639.2871212-1-ross.lagerwall@citrix.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Jennifer Herbert Verify livepatch signatures against the embedded public key in Xen. Failing to verify does not prevent the livepatch from being loaded. In future, this will be changed for certain cases (e.g. when Secure Boot is enabled). Signed-off-by: Jennifer Herbert Signed-off-by: Ross Lagerwall --- In v3: * Minor style fixes xen/common/livepatch.c | 103 ++++++++++++++++++++++++++++++++ xen/common/livepatch_elf.c | 55 +++++++++++++++++ xen/include/xen/livepatch.h | 10 ++++ xen/include/xen/livepatch_elf.h | 18 ++++++ 4 files changed, 186 insertions(+) diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c index 92d1d342d872..56a3d125483f 100644 --- a/xen/common/livepatch.c +++ b/xen/common/livepatch.c @@ -14,6 +14,7 @@ #include #include #include +#include #include #include #include @@ -525,6 +526,106 @@ static int check_xen_buildid(const struct livepatch_elf *elf) return 0; } +#ifdef CONFIG_PAYLOAD_VERIFY +static int check_rsa_sha256_signature(void *data, size_t datalen, + void *sig, uint32_t siglen) +{ + struct sha2_256_state hash; + MPI s; + int rc; + + s = mpi_read_raw_data(sig, siglen); + if ( !s ) + { + printk(XENLOG_ERR LIVEPATCH "Failed to mpi_read_raw_data\n"); + return -ENOMEM; + } + + sha2_256_init(&hash); + sha2_256_update(&hash, data, datalen); + + rc = rsa_sha256_verify(&builtin_payload_key, &hash, s); + if ( rc ) + printk(XENLOG_ERR LIVEPATCH "rsa_sha256_verify failed: %d\n", rc); + + mpi_free(s); + + return rc; +} +#endif + +static int check_signature(const struct livepatch_elf *elf, void *raw, + size_t size) +{ +#ifdef CONFIG_PAYLOAD_VERIFY +#define MAX_SIG_NOTE_SIZE 1024 + static const char notename[] = "Xen"; + void *sig; + livepatch_elf_note note; + int rc; + + rc = livepatch_elf_note_by_names(elf, ELF_XEN_SIGNATURE, notename, -1, + ¬e); + if ( rc ) + { + dprintk(XENLOG_DEBUG, LIVEPATCH "%s: Signature not present\n", + elf->name); + return rc; + } + + /* We expect only one signature, find a second is an error! */ + rc = livepatch_elf_next_note_by_name(notename, -1, ¬e); + if ( rc != -ENOENT ) + { + if ( rc ) + { + printk(XENLOG_ERR LIVEPATCH + "Error while checking for notes! err = %d\n", rc); + return rc; + } + else + { + printk(XENLOG_ERR LIVEPATCH + "Error, found second signature note! There can be only one!\n"); + return -EINVAL; + } + } + + if ( SIGNATURE_VERSION(note.type) != LIVEPATCH_SIGNATURE_VERSION || + SIGNATURE_ALGORITHM(note.type) != SIGNATURE_ALGORITHM_RSA || + SIGNATURE_HASH(note.type) != SIGNATURE_HASH_SHA256 ) + { + printk(XENLOG_ERR LIVEPATCH + "Unsupported signature type: v:%u, a:%u, h:%u\n", + SIGNATURE_VERSION(note.type), SIGNATURE_ALGORITHM(note.type), + SIGNATURE_HASH(note.type)); + return -EINVAL; + } + + if ( note.size == 0 || note.size >= MAX_SIG_NOTE_SIZE ) + { + printk(XENLOG_ERR LIVEPATCH "Invalid signature note size: %u\n", + note.size); + return -EINVAL; + } + + sig = xmalloc_bytes(note.size); + if ( !sig ) + return -ENOMEM; + + memcpy(sig, note.data, note.size); + + /* Remove signature from data, as can't be verified with it. */ + memset((void *)note.data, 0, note.size); + rc = check_rsa_sha256_signature(raw, size, sig, note.size); + + xfree(sig); + return rc; +#else + return -EINVAL; +#endif +} + static int check_special_sections(const struct livepatch_elf *elf) { unsigned int i; @@ -1162,6 +1263,8 @@ static int load_payload_data(struct payload *payload, void *raw, size_t len) if ( rc ) goto out; + check_signature(&elf, raw, len); + rc = move_payload(payload, &elf); if ( rc ) goto out; diff --git a/xen/common/livepatch_elf.c b/xen/common/livepatch_elf.c index 25ce1bd5a0ad..b27c4524611d 100644 --- a/xen/common/livepatch_elf.c +++ b/xen/common/livepatch_elf.c @@ -23,6 +23,61 @@ livepatch_elf_sec_by_name(const struct livepatch_elf *elf, return NULL; } +int livepatch_elf_note_by_names(const struct livepatch_elf *elf, + const char *sec_name, const char *note_name, + const unsigned int type, + livepatch_elf_note *note) +{ + const struct livepatch_elf_sec *sec = livepatch_elf_sec_by_name(elf, + sec_name); + if ( !sec ) + return -ENOENT; + + note->end = sec->addr + sec->sec->sh_size; + note->next = sec->addr; + + return livepatch_elf_next_note_by_name(note_name, type, note); +} + +int livepatch_elf_next_note_by_name(const char *note_name, + const unsigned int type, + livepatch_elf_note *note) +{ + const Elf_Note *pkd_note = note->next; + size_t notenamelen = strlen(note_name) + 1; + size_t note_hd_size; + size_t note_size; + size_t remaining; + + while ( (void *)pkd_note < note->end ) + { + + remaining = note->end - (void *)pkd_note; + if ( remaining < sizeof(livepatch_elf_note) ) + return -EINVAL; + + note_hd_size = sizeof(Elf_Note) + ((pkd_note->namesz + 3) & ~0x3); + note_size = note_hd_size + ((pkd_note->descsz + 3) & ~0x3); + if ( remaining < note_size ) + return -EINVAL; + + if ( notenamelen == pkd_note->namesz && + !memcmp(note_name, (const void *) pkd_note + sizeof(Elf_Note), + notenamelen) && + (type == -1 || pkd_note->type == type) ) + { + note->size = pkd_note->descsz; + note->type = pkd_note->type; + note->data = (void *)pkd_note + note_hd_size; + note->next = (void *)pkd_note + note_size; + return 0; + } + pkd_note = (void *)pkd_note + note_size; + } + + return -ENOENT; +} + static int elf_verify_strtab(const struct livepatch_elf_sec *sec) { const Elf_Shdr *s; diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h index 52f90cbed45b..12206ce3b2b8 100644 --- a/xen/include/xen/livepatch.h +++ b/xen/include/xen/livepatch.h @@ -38,6 +38,7 @@ struct xen_sysctl_livepatch_op; #define ELF_LIVEPATCH_DEPENDS ".livepatch.depends" #define ELF_LIVEPATCH_XEN_DEPENDS ".livepatch.xen_depends" #define ELF_BUILD_ID_NOTE ".note.gnu.build-id" +#define ELF_XEN_SIGNATURE ".note.Xen.signature" #define ELF_LIVEPATCH_LOAD_HOOKS ".livepatch.hooks.load" #define ELF_LIVEPATCH_UNLOAD_HOOKS ".livepatch.hooks.unload" #define ELF_LIVEPATCH_PREAPPLY_HOOK ".livepatch.hooks.preapply" @@ -49,6 +50,15 @@ struct xen_sysctl_livepatch_op; /* Arbitrary limit for payload size and .bss section size. */ #define LIVEPATCH_MAX_SIZE MB(2) +#define SIGNATURE_VERSION(type) ((type) & 0xffff) +#define LIVEPATCH_SIGNATURE_VERSION 1 + +#define SIGNATURE_ALGORITHM(type) (((type) >> 16) & 0xff) +#define SIGNATURE_ALGORITHM_RSA 0 + +#define SIGNATURE_HASH(type) (((type) >> 24) & 0xff) +#define SIGNATURE_HASH_SHA256 0 + struct livepatch_symbol { const char *name; unsigned long value; diff --git a/xen/include/xen/livepatch_elf.h b/xen/include/xen/livepatch_elf.h index 842111e14518..04611bac410e 100644 --- a/xen/include/xen/livepatch_elf.h +++ b/xen/include/xen/livepatch_elf.h @@ -39,6 +39,16 @@ struct livepatch_elf { unsigned int symtab_idx; }; +typedef struct { + uint32_t size; /* Note size */ + uint32_t type; /* Note type */ + const void *data; /* Pointer to note */ + + /* Private */ + const Elf_Note *next; + const void *end; +} livepatch_elf_note; + const struct livepatch_elf_sec * livepatch_elf_sec_by_name(const struct livepatch_elf *elf, const char *name); @@ -48,6 +58,14 @@ void livepatch_elf_free(struct livepatch_elf *elf); int livepatch_elf_resolve_symbols(struct livepatch_elf *elf); int livepatch_elf_perform_relocs(struct livepatch_elf *elf); +int livepatch_elf_note_by_names(const struct livepatch_elf *elf, + const char *sec_name, const char *note_name, + const unsigned int type, + livepatch_elf_note *note); +int livepatch_elf_next_note_by_name(const char *note_name, + const unsigned int type, + livepatch_elf_note *note); + static inline bool livepatch_elf_ignore_section(const Elf_Shdr *sec) { return !(sec->sh_flags & SHF_ALLOC); -- 2.49.0 From xen-devel-bounces@lists.xenproject.org Mon Jun 02 13:39:20 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 13:39:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003346.1382905 (Exim 4.92) (envelope-from ) id 1uM5Nn-00037V-1B; Mon, 02 Jun 2025 13:39:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003346.1382905; Mon, 02 Jun 2025 13:39:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uM5Nm-00037O-T2; Mon, 02 Jun 2025 13:39:18 +0000 Received: by outflank-mailman (input) for mailman id 1003346; Mon, 02 Jun 2025 13:39: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 1uM5Nj-00037I-Nv for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 13:39:18 +0000 Received: from postout1.mail.lrz.de (postout1.mail.lrz.de [129.187.255.137]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f93cb0e5-3fb6-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 15:39:14 +0200 (CEST) Received: from lxmhs51.srv.lrz.de (localhost [127.0.0.1]) by postout1.mail.lrz.de (Postfix) with ESMTP id 4b9w1G468hzySV for ; Mon, 2 Jun 2025 15:39:14 +0200 (CEST) Received: from postout1.mail.lrz.de ([127.0.0.1]) by lxmhs51.srv.lrz.de (lxmhs51.srv.lrz.de [127.0.0.1]) (amavis, port 20024) with LMTP id ZlMNUrqWyXHe for ; Mon, 2 Jun 2025 15:39:13 +0200 (CEST) Received: from [IPV6:2a02:2455:1858:e00:e0bb:e98d:8f46:dc66] (unknown [IPv6:2a02:2455:1858:e00:e0bb:e98d:8f46:dc66]) (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 postout1.mail.lrz.de (Postfix) with ESMTPSA id 4b9w1D6JC4zyVm for ; Mon, 2 Jun 2025 15:39:12 +0200 (CEST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f93cb0e5-3fb6-11f0-a300-13f23c93f187 Authentication-Results: postout.lrz.de (amavis); dkim=pass (2048-bit key) reason="pass (just generated, assumed good)" header.d=tum.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tum.de; h= in-reply-to:references:content-language:subject:subject:from :from:user-agent:mime-version:date:date:message-id:content-type :content-type:received:received; s=tu-postout21; t=1748871553; bh=bfukpYZo80PMkfvoZk9FkrYpOY/fDD2jTTnWUQHlWZw=; b=PFohczUPpyQs 7MhbiivoDShwyQUZZ86x2wIKgdlU6hWrTGtzjNtfb5Kbl3wdQX3HpxRz/caahJd9 E1Sve6lQRsf7V8nDo8gqFqQfIy+ax3Pft09yxNIMfymM+qMLxd4NcEZBOOe6fury 6atZRFmD7/uyfWKFckUhASbzKzMXV77ma1gixl32TVOQhn4keJ5bbLKIcN/zmpkq LMOJxkTsDznWueGn+WTQNDJeIi8EoJJcVUQO/inQeWJXy6bkjtn0A4uwlDHnuJeg jS2Tcp0mKpHVGioZzOcS/mIc4z5m+hEpqwAQoyVz+zprITWHKF6QucdlR++HPMR2 ov5s1iz4nA== X-Virus-Scanned: by amavisd-new at lrz.de in lxmhs51.srv.lrz.de X-Spam-Flag: NO X-Spam-Score: -2.866 X-Spam-Level: X-Spam-Status: No, score=-2.866 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, DMARC_ADKIM_RELAXED=0.001, DMARC_ASPF_RELAXED=0.001, DMARC_POLICY_NONE=0.001, HTML_MESSAGE=0.001, LRZ_BND_ANU8=0.001, LRZ_BND_M12_AN24=0.001, LRZ_DMARC_FAIL=0.001, LRZ_DMARC_FAIL_NONE=0.001, LRZ_DMARC_POLICY=0.001, LRZ_DMARC_TUM_FAIL=0.001, LRZ_DMARC_TUM_REJECT=3.5, LRZ_DMARC_TUM_REJECT_PO=-3.5, LRZ_ENVFROM_FROM_MATCH=0.001, LRZ_ENVFROM_TUM_S=0.001, LRZ_FROM_ENVFROM_ALIGNED_STRICT=0.001, LRZ_FROM_HAS_A=0.001, LRZ_FROM_HAS_AAAA=0.001, LRZ_FROM_HAS_MDOM=0.001, LRZ_FROM_HAS_MX=0.001, LRZ_FROM_HOSTED_DOMAIN=0.001, LRZ_FROM_NAME_IN_ADDR=0.001, LRZ_FROM_PHRASE=0.001, LRZ_FROM_PRE_SUR=0.001, LRZ_FROM_PRE_SUR_PHRASE=0.001, LRZ_FROM_TUM_S=0.001, LRZ_HAS_BND=0.001, LRZ_HAS_CLANG=0.001, LRZ_HAS_CT=0.001, LRZ_HAS_IN_REPLY_TO=0.001, LRZ_HAS_MIME_VERSION=0.001, LRZ_HAS_SPF=0.001, LRZ_MIME_BND_SPAM_184=0.001, LRZ_MSGID_HL8_3HL4_HL12=0.001, LRZ_MSGID_MOZ=0.001, LRZ_TO_SHORT=0.001, LRZ_UA_MOZ=0.001] autolearn=no autolearn_force=no Content-Type: multipart/mixed; boundary="------------7k0v5mQ5ROhNHfbSS6tpHkwi" Message-ID: <6d28eb0c-caed-4c58-a6ac-cbf8da357d22@tum.de> Date: Mon, 2 Jun 2025 15:39:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Manuel Andreas Subject: Nullptr dereference in nested VMX when shadow VMCS support is available Content-Language: en-US References: <5f258e25-a4ed-4f9a-8ca6-9ea3400e2369@tum.de> To: xen-devel@lists.xenproject.org Autocrypt: addr=manuel.andreas@tum.de; keydata= xjMEY9Zx/RYJKwYBBAHaRw8BAQdALWzRzW9a74DX4l6i8VzXGvv72Vz0qfvj9s7bjBD905nN Jk1hbnVlbCBBbmRyZWFzIDxtYW51ZWwuYW5kcmVhc0B0dW0uZGU+wokEExYIADEWIQQuSfNX 11QV6exAUmOqZGwY4LuingUCY9Zx/QIbAwQLCQgHBRUICQoLBRYCAwEAAAoJEKpkbBjgu6Ke McQBAPyP530S365I50I5rM2XjH5Hr9YcUQATD5dusZJMDgejAP9T/wUurwQSuRfm1rK8cNcf w4wP3+PLvL+J+kuVku93CM44BGPWcf0SCisGAQQBl1UBBQEBB0AmCAf31tLBD5tvtdZ0XX1B yGLUAxhgmFskGyPhY8wOKQMBCAfCeAQYFggAIBYhBC5J81fXVBXp7EBSY6pkbBjgu6KeBQJj 1nH9AhsMAAoJEKpkbBjgu6Kej6YA/RvJdXMjsD5csifolLw53KX0/ElM22SvaGym1+KiiVND AQDy+y+bCXI+J713/AwLBsDxTEXmP7Cp49ZqbAu83NnpBQ== In-Reply-To: <5f258e25-a4ed-4f9a-8ca6-9ea3400e2369@tum.de> This is a multi-part message in MIME format. --------------7k0v5mQ5ROhNHfbSS6tpHkwi Content-Type: multipart/alternative; boundary="------------5mUg0o6IZ2M7iPMMkaAxDZ0X" --------------5mUg0o6IZ2M7iPMMkaAxDZ0X Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Dear all, I've discovered an issue in the nested VMX implementation, where an unprivileged domain is able to force Xen to dereference a NULL pointer, resulting in a panic. This is possible when: 1. The malicious domain has nested HVM capabilities. 2. The CPU is running on top of VMX and supports shadow VMCS. To trigger the bug, the domain must first enable VMX operation for itself, execute VMXON and then finally execute VMPTRLD on a guest physical address that is backed by a non-writable p2m mapping. In `nvmx_handle_vmptrld`, after attempting to map the nested VMCS, Xen will check whether or not this mapping is suitable for writing and if not immediately unmap the nested VMCS again and abort the setup of `nvcpu->nv_vvmcx`. However, Xen at this point erroneously continues emulation of the VMPTRLD. In particular, if VMCS shadowing is available, Xen will nonetheless attempt to link up the nested VMCS to its own VMCS in `nvmx_set_vmcs_pointer`. Importantly, Xen here attempts to dereference the presumably mapped nested VMCS (which now is merely a NULL pointer) in order to mark it as a shadow VMCS by applying the `VMCS_RID_TYPE_MASK` to its revision identifier. Following, the page fault handler will panic Xen. I've attached an XTF reproducer that triggers the bug. To setup such a non-writable p2m mapping for the malicious VMCS, I first setup an appropriate grant table entry. I've tested it on Xen version 4.20.0. To fix the issue I believe the following patch should be suitable: --- a/xen/arch/x86/hvm/vmx/vvmx.c +++ b/xen/arch/x86/hvm/vmx/vvmx.c @@ -1817,7 +1817,9 @@ static int nvmx_handle_vmptrld(struct cpu_user_regs *regs)              else              {                  hvm_unmap_guest_frame(vvmcx, 1); -                vvmcx = NULL; +                vmfail(regs, VMX_INSN_VMPTRLD_INVALID_PHYADDR); + +                return X86EMUL_OKAY;              }          }          else The VMX error AFAICT does not strictly adhere to the Intel SDM, but providing the guest some indication on what went wrong is likely more sensible than silently failing. Best, Manuel --------------5mUg0o6IZ2M7iPMMkaAxDZ0X Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Dear all,

I've discovered an issue in the nested VMX implementation, where an unprivileged domain is able to force Xen to dereference a NULL pointer, resulting in a panic.

This is possible when:

  1. The malicious domain has nested HVM capabilities.
  2. The CPU is running on top of VMX and supports shadow VMCS.

To trigger the bug, the domain must first enable VMX operation for itself, execute VMXON and then finally execute VMPTRLD on a guest physical address that is backed by a non-writable p2m mapping.
In `nvmx_handle_vmptrld`, after attempting to map the nested VMCS, Xen will check whether or not this mapping is suitable for writing and if not immediately unmap the nested VMCS again and abort the setup of `nvcpu->nv_vvmcx`. However, Xen at this point erroneously continues emulation of the VMPTRLD. In particular, if VMCS shadowing is available, Xen will nonetheless attempt to link up the nested VMCS to its own VMCS in `nvmx_set_vmcs_pointer`. Importantly, Xen here attempts to dereference the presumably mapped nested VMCS (which now is merely a NULL pointer) in order to mark it as a shadow VMCS by applying the `VMCS_RID_TYPE_MASK` to its revision identifier. Following, the page fault handler will panic Xen.

I've attached an XTF reproducer that triggers the bug. To setup such a non-writable p2m mapping for the malicious VMCS, I first setup an appropriate grant table entry. I've tested it on Xen version 4.20.0.

To fix the issue I believe the following patch should be suitable:

--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -1817,7 +1817,9 @@ static int nvmx_handle_vmptrld(struct cpu_user_regs *regs)
             else
             {
                 hvm_unmap_guest_frame(vvmcx, 1);
-                vvmcx = NULL;
+                vmfail(regs, VMX_INSN_VMPTRLD_INVALID_PHYADDR);
+
+                return X86EMUL_OKAY;
             }
         }
         else

The VMX error AFAICT does not strictly adhere to the Intel SDM, but providing the guest some indication on what went wrong is likely more sensible than silently failing.

Best,
Manuel

--------------5mUg0o6IZ2M7iPMMkaAxDZ0X-- --------------7k0v5mQ5ROhNHfbSS6tpHkwi Content-Type: application/gzip; name="poc-nested-vmx-shadow-vmcs-vmptrld-nullderef.tar.gz" Content-Disposition: attachment; filename="poc-nested-vmx-shadow-vmcs-vmptrld-nullderef.tar.gz" Content-Transfer-Encoding: base64 H4sIAAAAAAAAA+1Y/3PauBLvz/wVe34vHdMCIYSkGfry5ihxcpkJkAk0l/fyGI+xZdDVljyS IeTa/u+3KxtiWq4tfTPtdBrNYGxpv2g/uyutlEi/KphOWVCdx4uqnnqBvMNXX+MjSVUUVMUs igKmWLgbe1zU/Cfbtjq2w2aT/vdeHNSL//TaaDQOn+wdYF/jxUGzgf2NRv1F/QnUt9b0FW2m U08BPNHp/UJ/gu5z4z9o2332rATP4NeQRwxSDAS9m2wfEkYEfhoJ1W0EIKdhTrwJ254bLvud as8ZDJ2T6nX3pjr4rX3S/x1fOwN8XA6vLk6qvdcXFyfOlXOaq2oHc66lum/B7en5TdcZ2eav vJxJKgMJJ9LXEEr19QZp9v/huVv6Bxd+NAsY/GuRhrXpvwsdnvKnuyiMeku+FDoFf+pls3VT nkbsdgTHYG0DD1zKjvWyVJpxkR65KUyUJ1I3VF7Mbi/bZ447OP+vMwLXJVe5XsQnggXuWOsC D05JClexCZdiCyZff5Z416DqLFImUhSuQQpIZQIyBFQ3i9B45+a8d9qv5Q54rVne47av2+cX b+uVvffGpdfdU49Hb8/FHFUElWt6vq8B2N64PEOudMog9PwUX7yURGUMhg5i5qFyIYEtfJbQ VED6/kyxAKcDuJboqRGAcMM5+kXNfEPkKCUVCfMlOpALQxTJOxjzVFdQoIq9KLoHnEBgZjln firVLiM+N2cKiYrE1bIACVjIBelyrq7cwetOxxkMwLT6B4Pnvev2xflJNmjnuDg3l04HYwPe rSFVL3/AbFjtRflLmPfw2ybap1BfhNjK5VIJYUm5j5CRCRRaLHUxVFwutHDRQnsueVAuvS2R gpnQxvGIjpgAjqL3qd/TMdjWPFbMC2DnNuQsCkYVfEM3ztjIKsGyYWZnfWAdq9gCG4WU14Yz ZrAUDlI2uNddhGjQc9FceA71WVQu52oVS2dKrCFB4l6W3lNQQidiGHoekBTYJbf3e5AlQAU8 EYBmKQ7rhPk8RAwUw9WHAoIHNfJhDg0XEeFNOIBPIl3KCoMLPDPvFaB82W8gfChjBday7xnR YMob2nzqMYtRu51x1yuwyjGcPY2bxKvTQoESjUErD+l0Nnbz1ckmJYdN7E28IFBL1StatkAJ 9UzkWMoIk4dHrkkuHAi9SLNK1sfFWm/BsXMZIQ64BdnWXgtyxehbo3H0suDcVWsPuu7pRfvM 7b8e2hWw0FSf4qKgCBnLX8b555LzU3xWo7VpIi7Jc26G7VcXjvtbu3dy4VzZe+MKNPC3c3mr mD/aJK4F1vMTis5FubJh+IN5Wse/+r5vVWDdQpSBIV4Gu9j7xfL+XMnLpcG6vEzaxrnnrgGL EiwLjM1ajf1gJcZS3Bt8qQI39GZR6rKAr/KMh2BTKD1oyzOPLbLQYhgxGdVaLH1Ev7bgbWT9 G8aPVqXyA/dmJfmSuzF1cCP8HomDah/T5jFtfpi0MTucKVup8l0rBBKF6fPGtgZ4QEs51gKz BLI62lRXporNimkaXO4ZVErjG2TnA5L8y/+Elc/JPHDXHvZP+i0smZn/Bm6YgExMton7XuKN ecTTe9qflxyk0VRhXuAlNIVQydiIh4fanhhWTvnFT2bu1NMEzseoYUnv6jc8QfPw2YLrYXWB VSDWCnPE2htHLJt1Qd6ciQBrQa4R6pRFBZkk7M5TAnGwrd+zl1xkKGdYhOCiIKSonhu+REmf aTwCFTSghae4EEwhkDE6ZM49mN4nTJmjEmBBEi5tW1UcaZxUMvIMWzSXB3Z90cyO9c0KPDUk +dNQZl8FpWd0yICU7P07eG8GbWg0mitskV75uBKS0Vzw1M0OKkaGvbcGGdJtBN4U1bZlanIg GRxDW1MUTR7m04KdABGqoJSHCWfSsOyTeW2PHBhmR1T8Y/2OMZQdmEbUMWYQe0mC1ozvQc6U ZtGc6VouIzNnIlLU5s73bo9GtQz8Y7DNi5uWi/iuURotSDnnCk2X7iQUduHAloe7jhP3Lh4v M3JdQuRNqGA8G5666OgYgfR8iovc1qV5GQ/akeNM5uIXcr5dQVubSkxgWsxo8msFPB4ECvN6 WOrQ912U4ukcchJJlX1VCjwFIXip4pMJU3CneBYex/nmt0TOKF5Z0Rt225eumQeJerfsIZkk 8kFzjSw4hqNCD6L8MerZ+PvlMYBCzqSEj34uxpwrExuV4T7Wv1zHCaMdvyvwFUFJcUPxuGMg ShpxLpXkK7kKzTVsC4Eaa2XW5LGnuY+5av7JZaACHLO7AzzLdG/cV+3Beae8MnKV23QycOmo QtFomGvLLpficcNBzVdNc5DwAhdf7UKOO8L4j1ZQ/nAi1uuLpU38T+Hm6NDtXDVpck65gBNF ATOCie7dOl2uqnhuKtxDVArWLEnXS7BCxebO1njLeebQHLHegE1+o70Rz/+2RZcELUSFLfCw R2tYVo3l47BTP1oYp6GgB3CGykR7JL0g237ueDolh2cmQ8C17ylcOBXTuPdTTHABdGmT73A5 ikVDslMbmlJcEZY6zcYzM5luWz3ccOazSDBFLrKWp1q6p7iQGOgw9xSnId2ivhhX6BZ0zDVG lW4Mqzq9p5XSejU4sbJuEy1VGYZYHragSZ2YJtU7HqTT/JuLgIm0it26mokUPDLXOyJomZuN 730r+vO0rS4nu94bRm7fUsen7//r9f3G/ur+/+BFk+7/m82Dx/v/b9GWV8r/tK/6/WF5dzzj UbDryziWoha/KZV67a6TrXmtY9jqIrzTHjpn/av/GM6F9kpDZzCsOr3rAXVM5/Fhs5T33Qyv 2tXO6RkNsEWqvJofTmpclEpy/EcVN10m5vD8GMztuCyVNs96wsyUvzekP1TbKv9p06z9oaXY Tsfn8r+xv2fy/3C/efBi/4Dy/7DxmP/fpGVFvCWwRLBwH98mHKysQrZ8L2UTqe6JH9N82Y0p y5UUMW71GoduV7WTZVI/uxIa5cSmzjBlIZGOsAz53sD8JG2r/C8uzVvo+Fz+Y+Yv87/Z3G9g /u836o3H/P8WLfM9ZiQeH/Yek+6xPbbH9th+mvYXAJbiYwAoAAA= --------------7k0v5mQ5ROhNHfbSS6tpHkwi-- From xen-devel-bounces@lists.xenproject.org Mon Jun 02 13:42:08 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 13:42:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003377.1382914 (Exim 4.92) (envelope-from ) id 1uM5QR-0005Bz-H8; Mon, 02 Jun 2025 13:42:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003377.1382914; Mon, 02 Jun 2025 13:42:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uM5QR-0005Bs-Cw; Mon, 02 Jun 2025 13:42:03 +0000 Received: by outflank-mailman (input) for mailman id 1003377; Mon, 02 Jun 2025 13:42: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 1uM5QQ-0005Bl-AP for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 13:42:02 +0000 Received: from mail-oa1-x2e.google.com (mail-oa1-x2e.google.com [2001:4860:4864:20::2e]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 5c4a6f22-3fb7-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 15:42:01 +0200 (CEST) Received: by mail-oa1-x2e.google.com with SMTP id 586e51a60fabf-2e8ec65078eso3270606fac.0 for ; Mon, 02 Jun 2025 06:42:01 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5c4a6f22-3fb7-11f0-a300-13f23c93f187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1748871720; x=1749476520; 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=C7PQuANJfTujA3g/Om1tWM/nzKErHeArIm4YuhdyCvU=; b=BRetK6GGEcgfVbJG72usV4s5d/mcnGHemv9MzoVTV+Wg1gdNBst/vhtZ/w60VwSPo7 BuPEatAptLL82/tFI02uFn+6bJQMpjGNJ9mUlJzN35LprUVU6QWf9nG1aazGzESuWnfM LiUrFwfe4MluXJ9DH6tfB/Xot5Gw+90VirgNc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748871720; x=1749476520; 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=C7PQuANJfTujA3g/Om1tWM/nzKErHeArIm4YuhdyCvU=; b=YojxveowFFuBdWZ+oTur4eUaC3DsmHSlGy6DZYFlyOVuM3seDCSXGfvW0h7Hbgs8VF dT9/uQ09/pCt0oK/1lp7Sf7bMw581iNa//qu4j8wFXgoY/esmw4C5IiAGz3yHJhFF6z9 TNoUZYue9g/X1jMmxmZ/A3uvzrdekVlre86pQ936PfFs5Rp9OTVnO7IZfJBL6HSRAmLq qRxZTwjNRy02QYEpD/EOAppMWtTJmBIgF4Y32O3nNf3PXHIDXIVWXyhGaByBAyA1WAmC Ned6hSYMLYe4z1MiHVMv/QGVm1LnF1uK9pf7d+5KNJ1+oSza5sN0R/uvXiAhd75R70Mr Dg9A== X-Forwarded-Encrypted: i=1; AJvYcCXv9uC5s4bKmJ78JhyrqVw9k8XEkZSHqBIaXUTZ4gUi1clYz1RjYhzLScOHl3lVjBUmIRlAP0OwQuE=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx18bzRLQsUHkF/62K/TKT6ndK55NkIr9sLbj0+68An2Rehmmeu um3wgdEffrdhRoRpTT3PQdA6H7BmCduikNlunj55ETgUNF09FcWCqstHTmJEF22bzZiv/NRLskY EqVnnnw2DyqAf61ngKf/dReXmHEyLvr6IphgZfjMpA+077a8qXORXuw== X-Gm-Gg: ASbGncsuSodjmKcrqITEDqL228VlKUgRNv4Yr/X8UPS5pcD3OySLj2o/mFsERU7w2TD zNQEy9xLYA4FQT8zCZHwuQpXMvoWqbh9Ug+LODIbo1bw4rypQZArR5HFezVQvizkt8qQPb8SRCO YLbnXctIx5V4T4M/ORlwpsoDge4YJEANI= X-Google-Smtp-Source: AGHT+IHm2T2yKn9FuSpyCg9OjEmGB7rTkfVvdgYGcTDKDAFkt+8YzGPrDCSFwg7ZnIwg+kwDChUmNtGcA8YTkFb9ILI= X-Received: by 2002:a05:6871:713:b0:2c2:260:d77b with SMTP id 586e51a60fabf-2e9486d6508mr5058862fac.5.1748871720291; Mon, 02 Jun 2025 06:42:00 -0700 (PDT) MIME-Version: 1.0 References: <20250515093822.659916-1-ross.lagerwall@citrix.com> <20250515093822.659916-5-ross.lagerwall@citrix.com> <2c5fbc92-c81f-452c-8a5a-3f1eaf53dfdb@suse.com> In-Reply-To: <2c5fbc92-c81f-452c-8a5a-3f1eaf53dfdb@suse.com> From: Ross Lagerwall Date: Mon, 2 Jun 2025 14:41:48 +0100 X-Gm-Features: AX0GCFvTq6Vq5JBgMcyXp2hGPWqqtrX1z7biGpGUMFstGsjRS5tHU9AtW8Fti-8 Message-ID: Subject: Re: [PATCH v2 4/5] livepatch: Load built-in key during boot To: Jan Beulich Cc: =?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 Sun, May 18, 2025 at 1:17=E2=80=AFPM Jan Beulich wro= te: > > On 15.05.2025 11:38, Ross Lagerwall wrote: > > @@ -73,6 +75,10 @@ static struct livepatch_work livepatch_work; > > static DEFINE_PER_CPU(bool, work_to_do); > > static DEFINE_PER_CPU(struct tasklet, livepatch_tasklet); > > > > +#ifdef CONFIG_PAYLOAD_VERIFY > > +static struct rsa_public_key builtin_payload_key; > > __read_mostly or even __ro_after_init? > > > @@ -2287,6 +2293,31 @@ static void cf_check livepatch_printall(unsigned= char key) > > spin_unlock(&payload_lock); > > } > > > > +static int __init load_builtin_payload_key(void) > > +{ > > +#ifdef CONFIG_PAYLOAD_VERIFY > > + const uint8_t *ptr; > > + uint32_t len; > > + > > + rsa_public_key_init(&builtin_payload_key); > > + > > + ptr =3D xen_livepatch_key_data; > > + > > + memcpy(&len, ptr, sizeof(len)); > > Doesn't this (and the similar one further down) need to be an endian- > ness conversion? In fact, seeing how the data is being built, it's > not really clear to me what endian-ness the field would be written > in, when build host and target host endianness differ. Good point. In v3, I've made this and the build-time tool use little endian which in most cases should be a no-op. > > > + ptr +=3D sizeof(len); > > + builtin_payload_key.n =3D mpi_read_raw_data(ptr, len); > > Whether there are endianness concerns here I also don't know. As a byte sequence, this always uses big endian (much like OpenSSL). I've added a comment in v3 to clarify this. Thanks, Ross From xen-devel-bounces@lists.xenproject.org Mon Jun 02 13:43:48 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 13:43:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003384.1382923 (Exim 4.92) (envelope-from ) id 1uM5S7-0005jC-QN; Mon, 02 Jun 2025 13:43:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003384.1382923; Mon, 02 Jun 2025 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 1uM5S7-0005j5-NF; Mon, 02 Jun 2025 13:43:47 +0000 Received: by outflank-mailman (input) for mailman id 1003384; Mon, 02 Jun 2025 13:43: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 1uM5S6-0005iz-HC for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 13:43:46 +0000 Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [2a00:1450:4864:20::32d]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 99fe48e1-3fb7-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 15:43:44 +0200 (CEST) Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-441ab63a415so47903785e9.3 for ; Mon, 02 Jun 2025 06:43:44 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-b2eceb28c20sm5542304a12.21.2025.06.02.06.43.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 06:43:43 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 99fe48e1-3fb7-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1748871824; x=1749476624; 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=p5mRCfrBwdgU9xmW7xvQQcWoE9THaQT42+bThtdVls4=; b=d5Ohb/QrD1T/ckqYdgIkbDaBYKj1TLEWeRKXQJChn2ExVUj/PAa3lCxcXKDc5lXxSN f2QY61WRzAzqRggukE9OF8swI8wZF7Gl+FjwBmzfqRdkeGeJvAeqcX6xyphMzLxsF0z3 gtopiYdpDX8ayKiTRyBCMu3yVf62+A7gpIrcrzzQYKKuCiJYzF0hamiFnZBAFjhndt70 vehsNsLhW7y2INTn6e4JJ9dB8M/3J/MVW4RwKhsDTmZwJCy7HPJWPFLtJJ/e/ozrw1k/ eqLtM5S17moGQhHvo3FehrVvCwsl3U2vRhDb0J0QH37IZMgjwACabA3TNhffQLRVD0Pb Yukg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748871824; x=1749476624; 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=p5mRCfrBwdgU9xmW7xvQQcWoE9THaQT42+bThtdVls4=; b=rGCc5CFHWECQpJ989ltGX2ty6YXEy8GWXcIDMzCRgmPTg6eXSV0xML5LdDFslPuMaT T0/WIqgSaZMUtuWCL2iUubBrx5yXv93OyW2SUmdQ7tFW8nOn2bWXLx65BRkskFbm22W1 BWsRliogTSIZbcR048Da1t0o3X+zhUIDhI9Nw9Fz6U+XryXRMC1/xGYySBzA6Pue9Bbk tyTIFgOFvblTEKmZ0OlxRDie5VTokA4z0az0NT0L35PomH+d+Tp5lKae7BzxUQWJvTMs Fb1RCsMneeFBCL11TbyFpZZKG2mRWusp6jvmZBZCsaiqc1lm/fhv3OFG6/LLWaIOOYZm Vxrg== X-Gm-Message-State: AOJu0YzEyvovVQrFDwUvl6fJi1ZCzMWkoyGhvgTz2sZLD24NljjUzWo5 Zz/monajQPUXCXMRq+4Hetb31Gl0kkPzfizuSDSqjZZUJCBeGbyowYkPss0zpH8fZHq/IruEYvN YDUE= X-Gm-Gg: ASbGnctAmYb1pfqsEOoyLXD3BJmdX7z7Jz1XWYcdbhvlGho7hk1bV0u9Q1xWnVQPHSX SgAMPvkZPl3x/AZTuiaAXMNahqPRD3TuTCvWKHbmcU20kgCAgMErXHzAaV7xxzFK4xQgZ2W7KcO OTe42nhaoFvzFc15i8kY1O52s/r89NzZDABXrZ82SDQV6+CIbu93s8xIJ6YqdWcEkgEadym/bXr EEc385k9V+UW1FF8xrs5koCUvP1COV09/tjdHfdqMx0+2Wc1+hFkMBLtWRixZwGXTpbvjXaDwGB VzdX8VXjEur887qaFXNyAQuizuNwn7pNcspUdko4xUs1dRXpbHomxhzCzB9/7m+XCZExHn5lFtc UPu0wuwyxi3hvNpOzAsEGXf6rUtzzA47D3D1N X-Google-Smtp-Source: AGHT+IFDaALxptVo8kTH2xMW0nL84eAmgsC83l0Yxbtwknuw/gFrDkKi8IW5ialAKK0L64UYPYCcfg== X-Received: by 2002:a05:6000:250d:b0:3a4:c95f:c1d1 with SMTP id ffacd0b85a97d-3a4f7a3e4d6mr10111303f8f.4.1748871823929; Mon, 02 Jun 2025 06:43:43 -0700 (PDT) Message-ID: Date: Mon, 2 Jun 2025 15:43:37 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Kernel panic when passing through 2 identical PCI devices To: "J. Roeleveld" References: <2226691.irdbgypaU6@persephone> 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: <2226691.irdbgypaU6@persephone> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 02.06.2025 14:28, J. Roeleveld wrote: > I have a domain to which I pass through 4 PCI devices: > 2 NVMe drives > 83:00.0 Samsung 980 NVMe > 84:00.0 Samsung 980 NVMe > > 2 HBA Controllers > 86:00.0 LSI SAS3008 > 87:00.0 LSI SAS3008 > > This works fine with Xen version 4.18.4_pre1. > However, when trying to update to 4.19, this fails. To make it explicit: The domain in question is a PV one. > Checking the output during boot, I think I found something. But my knowledge > is insufficient to figure out what is causing what I am seeing and how to fix > this. > > From the below (where I only focus on the 2 NVMe drives), it is similar to the > succesfull boot up until it tries to "claiming resource 0000:84:00.0/0". > At which point sysfs fails because the entry for "84" is already present. What would be interesting is to know why / how this 2nd registration happens. It's the same (guest) kernel version afaics, so something must behave differently on the host. Are you sure the sole (host side) difference is the hypervisor version? I.e. the Dom0 kernel version is the same in the failing and successful cases? I ask because there's very little Xen itself does that would play into pass-through device discovery / resource setup by a (PV) guest (which doesn't mean Xen can't screw things up). The more relevant component is the xen-pciback driver in Dom0. Sadly the log provided does, to me at least, not have enough data to draw conclusions. Some instrumenting of the guest kernel may be necessary ... Jan > The SAS drives appear be dones correctly, but am unable to confirm this as the > NVMEs are required for a succesful boot. > > For completeness, I have attached the output for the failed boot, a normal > succesfull boot (using 4.18.4_pre1) and my xl.conf (which might need > adjusting) > > === (output for just the NVME devices) === > pci_bus 0000:83: root bus resource [io 0x0000-0xffff] > pci_bus 0000:83: root bus resource [mem 0x00000000-0x3fffffffffff] > pci_bus 0000:83: root bus resource [bus 00-ff] > pci 0000:83:00.0: [144d:a809] type 00 class 0x010802 PCIe Endpoint > pci 0000:83:00.0: BAR 0 [mem 0xfbc00000-0xfbc03fff 64bit] > pcifront pci-0: claiming resource 0000:83:00.0/0 > pcifront pci-0: Creating PCI Frontend Bus 0000:84 > pcifront pci-0: PCI host bridge to bus 0000:84 > pci_bus 0000:84: root bus resource [io 0x0000-0xffff] > pci_bus 0000:84: root bus resource [mem 0x00000000-0x3fffffffffff] > pci_bus 0000:84: busn_res: can not insert [bus 84-ff] under domain [bus 00-ff] > (conflicts with (null) [bus 83-ff]) > pci_bus 0000:84: root bus resource [bus 00-ff] > pci 0000:84:00.0: [144d:a809] type 00 class 0x010802 PCIe Endpoint > pci 0000:84:00.0: BAR 0 [mem 0xfbb00000-0xfbb03fff 64bit] > pcifront pci-0: claiming resource 0000:84:00.0/0 > sysfs: cannot create duplicate filename '/devices/pci-0/ > pci0000:84/0000:84:00.0/resource0' > CPU: 2 UID: 0 PID: 39 Comm: xenwatch Not tainted 6.12.21-gentoo-generic #1 > Call Trace: > > dump_stack_lvl+0x56/0x80 > sysfs_warn_dup+0x51/0x60 > sysfs_add_bin_file_mode_ns+0x8a/0xa0 > sysfs_create_bin_file+0x5e/0x80 > pci_create_attr+0xfc/0x140 > pci_create_resource_files+0x30/0x90 > pci_bus_add_device+0x26/0x80 > pci_bus_add_devices+0x27/0x60 > pcifront_rescan_root+0x18a/0x220 > pcifront_connect+0x117/0x170 > ? xenbus_read_driver_state+0x32/0x60 > ? xenbus_otherend_changed+0x49/0xa0 > ? __pfx_xenwatch_thread+0x10/0x10 > xenwatch_thread+0xf6/0x130 > ? __pfx_autoremove_wake_function+0x10/0x10 > kthread+0xea/0x100 > ? __pfx_kthread+0x10/0x10 > ret_from_fork+0x1f/0x40 > ? __pfx_kthread+0x10/0x10 > ret_from_fork_asm+0x1a/0x30 > > === > From xen-devel-bounces@lists.xenproject.org Mon Jun 02 13:45:39 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 13:45:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003391.1382933 (Exim 4.92) (envelope-from ) id 1uM5Tv-0006Gx-3i; Mon, 02 Jun 2025 13:45:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003391.1382933; Mon, 02 Jun 2025 13: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 1uM5Tv-0006Gq-1C; Mon, 02 Jun 2025 13:45:39 +0000 Received: by outflank-mailman (input) for mailman id 1003391; Mon, 02 Jun 2025 13:45: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 1uM5Tt-0006Gj-FC for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 13:45:37 +0000 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2061d.outbound.protection.outlook.com [2a01:111:f403:2416::61d]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id dae1bd6c-3fb7-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 15:45:34 +0200 (CEST) Received: from DM6PR06CA0039.namprd06.prod.outlook.com (2603:10b6:5:54::16) by LV2PR12MB5822.namprd12.prod.outlook.com (2603:10b6:408:179::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Mon, 2 Jun 2025 13:45:29 +0000 Received: from DS1PEPF0001709C.namprd05.prod.outlook.com (2603:10b6:5:54:cafe::f1) by DM6PR06CA0039.outlook.office365.com (2603:10b6:5:54::16) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Mon, 2 Jun 2025 13:45:29 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by DS1PEPF0001709C.mail.protection.outlook.com (10.167.18.106) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8792.29 via Frontend Transport; Mon, 2 Jun 2025 13:45:29 +0000 Received: from localhost (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 Jun 2025 08:45:27 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: dae1bd6c-3fb7-11f0-b894-0df219b8e170 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=sBR0+8L3vqm+K7vs480inmY2pLH2sgGOr2BtB1ZqR18p5KHjmFJv8DjtnxF9yX550orVlN0tnfUoxGb2iAyf46VR4NdHjOrkgZ4PINpWm06fjTVwYYEHEnP0VRHDZUij1QkDhV5tLN8QVU5Qabr+hoG7CCgJNzlDU2Yu4YSZVxnBCnuzkxOsmqpj/ajb2KIJwys6xZm0fOwTOsz7eQjXI2Js+KQnvF9v0GTa49jwew9YWEysCgfE2VnJkbIwRtfTGwPpQQcIhhw3fdqN8tulGAjOT+lMbHp7F0oP5VFu/eC9p6FUdj2m99p0CPFmwlD4duf2go+5H66EPeCPS4iWew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jfnnRzDw+6tDzTcBk1dZpJldnwaZ1kJT2h30g57b2tU=; b=W9gmTRBGS6JIqD15k0o8PAhoIdahWxug+JF9iu8+XEXy3tp9E4fjL/DKNi1ZAgRLddhWNe0pX75O97wgZuaThDZQQPEs4rP3yhefmCmaAZza3yKNiLHylQe1jUVwZTFMXty53J3oCdS0wg1dxc0IIPKNPOP4XcoBF24yFmo9zYZvA8Cx0yhCh3Zq/Oq/xwZ7+e24VSPdv52ZG4Cmhie9fAne57FV2wtJLWZzyDOtKi2oS5l9XsgzDvpOuVz8V+wjAE4Qm0UbGhxyHazFmXJG+zatzpl7XPiGUpBVQ1OkaYEwavwTdIpfYnnMrQwwPtF4mQurue2hmpRaHNn2kKBGrQ== 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=jfnnRzDw+6tDzTcBk1dZpJldnwaZ1kJT2h30g57b2tU=; b=rSChZk62YJctp+zRJE27EI9xk/nDGARSwFG/+C+xpBLP2ZQfv0UzGQ0QHOX2srXnmYXEzVYEd4kvdIhX5VzXTsszm9u/lxqAIbgZP1LxfvFI06Q8KTXzVXxc2t1/GHlvuXPvuv/zXLW8BDmOBiW0LKmxau/crzj0H7kDY/KchpY= 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 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Date: Mon, 2 Jun 2025 15:45:25 +0200 Message-ID: From: Alejandro Vallejo To: Jason Andryuk , CC: Jan Beulich , Andrew Cooper , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , "Daniel P. Smith" Subject: Re: [PATCH 02/19] x86: Add missing pci_dev forward declaration in asm/pci.h X-Mailer: aerc 0.20.1 References: <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-3-agarciav@amd.com> <9b5a1599-d8dc-423d-b144-90bfe33cdae9@amd.com> In-Reply-To: <9b5a1599-d8dc-423d-b144-90bfe33cdae9@amd.com> 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: DS1PEPF0001709C:EE_|LV2PR12MB5822:EE_ X-MS-Office365-Filtering-Correlation-Id: 648d7dfa-7f5d-4d70-a64d-08dda1dbbca5 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?cDJWTlp4eU56K1QvSmMwWUxSYXZqNG5LdXpzR3pnRVJOaW1HbGtNaStHSFg2?= =?utf-8?B?OTZVOEYrMXMzN3BMUWZWY1hJYTRScWcrM0p3MXU5Q1pnd2YwU0JKcEUweDY1?= =?utf-8?B?YVRoTDljNFY4Sm8xQkpCbm8yc2MrdjB0WXd3bXE1V01nNkF6V0wwblE2VlFs?= =?utf-8?B?WXJERldmaEoyMkRxSlo1dVhQVzcvN2pLMHY1bG1SbmdNdnplWHZiVVhMWEgz?= =?utf-8?B?RGloUSswUEk2SUNCMGZkUmJBdVVsWjJlVFdNaEJFM0J0bHU0cmZYSDlpckVQ?= =?utf-8?B?ajdSdWVjY3VTTkQ3VEpLR3hIT1lndDYzWlhMdXcrc2tBTzZuSGg0cndXSG50?= =?utf-8?B?bXpPbjV1NUNPMVJ5alMvMm9HaDN0MlloRnVEaEJJMlpISWNoQm9DUW1jSDNL?= =?utf-8?B?blFvT2RpaThvdVFDTVhCdmw0MXNyS20reENzR1k4dkdVdUowOENZblBCVGVt?= =?utf-8?B?ZEtnblJOelBidUttWDhEZkVGaVhtN05yb0Q0ektmL216dUIvTUg0cjVRSVlF?= =?utf-8?B?RkIrQlo3QkNQZlN3NVNtMVFMdm9icVZOaWkyTUJSTlVkeHFhQ1A5NnY0M05l?= =?utf-8?B?NkJDaWhOcUE3SkNjdVRuRDRMTU4xcVkwaHlDN0tzS1NzOTcxNHJSNjJIZlVR?= =?utf-8?B?ODRrYzZjbTd1T1VBR3VqQkNzd0UyK2FTRXpWZTlqdEZxMDV6K215U2lySTlk?= =?utf-8?B?aDFZZWx1UGlhVHMwSkpvdXloYUtyaWtRQVFWd2JIZE0vaTIweWYxbGJ4cEM5?= =?utf-8?B?NEFUdnd5V05FUmJ0cVI1Tk4yTWd4WGV5NThJRmZFYkk4VVZMOUtvZms0eUpu?= =?utf-8?B?ck9yRFl3WlpwRlVhNWltTE1WMUxpaTRJbkRWOXMwSm1BYkFKSmpXcFJ6b3E2?= =?utf-8?B?YkNCcEdOS0JKMmNvZnlzaVAzNExsVjkzSXk4R2pxY1VZeTJKbkNnRk83WGg3?= =?utf-8?B?ckQxVzNXaXoxL3dnanRMcjcyOU9EL3h0N0ZJSkJid2k0K0lhcmpOZE5sR2RJ?= =?utf-8?B?ZmV6WmtwZTc4N2JTYXljVnlTcnZUdmF0aXBpdlpDQkFLSFhxZmZSbnZqM2k0?= =?utf-8?B?bmprai9veEpYYlJZaVAzMkxZY1RtTTQxd0ZscUVKN3lUb3NzZGJTaVM4aDJ6?= =?utf-8?B?TDZLR0JYL1Zham1FczYrL2JETG94Y3lnTFFTZHFZc3hBekYxOVluL0ZWcVho?= =?utf-8?B?UFZLVWZBSzRkbUhLWFo2cVpjNXQ0ZlFxSXlvSWpMSHNyREYvR3pUMGxxOUtL?= =?utf-8?B?ZEJEQ1RCbHAzUVdQV3N5MGpsaXA2ZDhmdU9rYmVLc3lmTHJZdkpsc2xiU0ZL?= =?utf-8?B?cXB0YVNDY2Q2OHR3eExucGozME15ZFFSZ3V6U3k5UU1yb24wMjV2cXE5UTNk?= =?utf-8?B?WkFlVTdodjJsMWJDMlhZOCtiTjhBeXZOMDg4OFI2cldXK2VaYlpoYWVMSXlu?= =?utf-8?B?SHZLbFZUQWZ5QXhJVHVBS0VhTVFWazEvbHNsdHN4UWpYbThHUjVna3hBeS81?= =?utf-8?B?ZDlmaFdOeWhpTnY1d3ZINTBVVHVOclpqOG8zdmZzWDExZ1U0cG85R0JET1FP?= =?utf-8?B?dWE1dkdHNmxyM3daQXdkblZ6WldBVGJOMXFWODg5ajdCd0cxS3JPbHcvbXVQ?= =?utf-8?B?cUNpenNPbm8wbmt1MkVnd0ZQMWNYL1BZSzcySko5aklxd2xhS3hJd1hXaDkx?= =?utf-8?B?RU5sSmFqRWFXNy9JNmsraEU0MXdNL3ZDVWJXZ1RIdVhMK1JVaEczS1RLU2pF?= =?utf-8?B?ZWkwWEhUaTdmaDlhYWdRZDRRQ1lyWDltQVBvZVF6bWEzZnNQNHlsMWNndzZt?= =?utf-8?B?V1c3czJ0MjMzYlB1WW0ydWk5R3JVcXhlaEhETmZzc2hzZTB2VmtBVGNJQnM3?= =?utf-8?B?d0xDVXJDRzFSMm9LdXJxWVN6VHlSbjkvcmk4NmRjeFFkNVBzOVZ6ME5nY29G?= =?utf-8?B?YnlCSENsQXN1alJreURBTEVkZGd1STlQVW9LVTJBaTRPRzlTdUxNU2s1ajA1?= =?utf-8?B?YkNWcFM5VkJQeUcrMXhYZjFsUkxHUWd0MEVuQWpDbGVnZ2VlbDVHbUhEalJ0?= =?utf-8?Q?T3+mox?= 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: 02 Jun 2025 13:45:29.0551 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 648d7dfa-7f5d-4d70-a64d-08dda1dbbca5 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: DS1PEPF0001709C.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV2PR12MB5822 On Fri May 30, 2025 at 11:04 PM CEST, Jason Andryuk wrote: > On 2025-05-30 08:02, Alejandro Vallejo wrote: >> Not a functional change. >>=20 >> Signed-off-by: Alejandro Vallejo > > Some sort of reason would be good in the commit message. > > "struct pci_dev is used in function prototypes within the header. This= =20 > is in preparation for including (transitively) in device tree"? > > ... I'm guessing that is why. Stating it would be better. Yes, but I'm not sure the second part of that explanation is relevant. Unle= ss specifically noted in the header, they are meant to stand by themselves whe= n possible and not require preinclusion of something else (in this case, xen/= pci.h). This patch would still be relevant (imo) even if I wasn't using the header = for anything. > > With a suitable reason: > > Reviewed-by: Jason Andryuk Thanks, Does this sound reasonable? struct pci_dev is used in function prototypes within the header, so it mu= st be forward declared for asm/pci.h not to depend on xen/pci.h being includ= ed first. > > Regards, > Jason Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Mon Jun 02 13:46:57 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 13:46:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003398.1382944 (Exim 4.92) (envelope-from ) id 1uM5VA-0006lu-Dg; Mon, 02 Jun 2025 13:46:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003398.1382944; Mon, 02 Jun 2025 13:46: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 1uM5VA-0006ln-Ae; Mon, 02 Jun 2025 13:46:56 +0000 Received: by outflank-mailman (input) for mailman id 1003398; Mon, 02 Jun 2025 13:46: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 1uM5V9-0006ld-NQ for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 13:46:55 +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 0ae89121-3fb8-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 15:46:54 +0200 (CEST) Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-ad574992fcaso719113366b.1 for ; Mon, 02 Jun 2025 06:46:54 -0700 (PDT) Received: from fedora.eng.citrite.net ([185.25.67.249]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ada5dd04591sm790372466b.114.2025.06.02.06.46.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 06:46:52 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0ae89121-3fb8-11f0-a300-13f23c93f187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1748872013; x=1749476813; 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=SiLwLWHFfreci1k3/3don9flm/R9wvMppu+kYNStDuY=; b=Q2S7/wrsTIPUnpe7q5hS5t+azV4AUjvckPrH1vepCUYEerNJHDNvO5QC6lgIwr0fgR 7+02JbAQ4p6wefenngf/w49lVLss0z5rN5rct+ktqv3Gku0JZRom1Kw8nPFQNpkMTN70 X2bCogvBkNQo9Esy5087jb222E+XUH8MQ88Qg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748872013; x=1749476813; 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=SiLwLWHFfreci1k3/3don9flm/R9wvMppu+kYNStDuY=; b=thew16DWdR51lgLL7fRxKwuQbPpxKju1weKIpk7t+OtRSSDYr8oYzpabdXdIMTBNjO JCzRsumoHmVytyqz/2eQ2HFp6aUefz58FU7I6U6o+bBELlmVkakD/iOcxT9HH+4Woagx X8/ELewzorLSz3LEgzv/iXEnhLzEdFk+bj0hMVhsoH9Lr2Ow/Vt+PtcGZBx11xFlPkst 8PwGjbNJnUKg+JBG2nZOoE/GrA022hckWkUkHBo3hhbbyoxmQlX35OuSVQNiaBWnhnov C/mcUjnvH2IttPkZaqIPXqyg8RtlJ2cogfWkjGc6+kK03vs+FkodxbBMlDttB8CGtj0r DsJg== X-Gm-Message-State: AOJu0YziAw8Mv69By34CTtOv+s8F/VMuXR/YoO9Mxxv5PhZArabLlAdc x2qKetsxAjk/vEk5sx3/agfu0FcgRlR3QIUlXdZSSoN1RNlyH/ZzJK7KQP2pozPsLqABjtJQ9Cz VkO8K X-Gm-Gg: ASbGnctncxzLRRLjLAHR9/v8IqMZ9twh2rmT9ySbuaZvgdT39KShQ2zZuzyrGkxBP22 5v6YJyI0H6c+RMTcJOVR06rEzUunZdJdDZ2TDwwHZc65+bQvWyTuSncpxCpaCaX+M3i/fiX6Hss vWzAMepLgpSjBrjCAO93/x+5jUCK1UxtFxJpU6X8JEpB+trabjcz3DJPz2oKk/E829L1QgGTF/p nhR+5Tikqf59dHf3vui1tR5o6GRp4BWENEys/x0+akO2AjlSLJXbi0APkcpogj5jh3x3FThqLLa K60XMXN7m3zO0VRhj/ejlNf6Djw1qEIymVXZ/dRbaN3vGbhgruBWv0YOOS1mcSNGwH+E X-Google-Smtp-Source: AGHT+IEekP3SlKgi9Gm7hF2YLLrf+Abm5uS3+eZNmxPiCwBrxgYH2DuEAeJ0J0RkbFA+ZDbKJ6bRTA== X-Received: by 2002:a17:907:980e:b0:ad8:a935:b90b with SMTP id a640c23a62f3a-adb494d689cmr839378666b.28.1748872012869; Mon, 02 Jun 2025 06:46:52 -0700 (PDT) From: Kevin Lampis To: xen-devel@lists.xenproject.org Cc: Kevin Lampis Subject: [PATCH v2 0/3] Add lockdown mode Date: Mon, 2 Jun 2025 14:46:53 +0100 Message-ID: <20250602134656.3836280-1-kevin.lampis@cloud.com> X-Mailer: git-send-email 2.42.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The intention of lockdown mode is to prevent attacks from a rogue dom0 userspace from compromising the system. Lockdown mode can be controlled by a Kconfig option and a command-line parameter. It is also enabled automatically when Secure Boot is enabled and it cannot be disabled in that case. Ross Lagerwall (2): efi: Add a function to check if Secure Boot mode is enabled Add lockdown mode Kevin Lampis (1): Disallow most command-line options when lockdown mode is enabled docs/misc/xen-command-line.pandoc | 16 ++++++++ xen/arch/arm/domain_build.c | 4 +- xen/arch/x86/acpi/cpu_idle.c | 2 +- xen/arch/x86/cpu/amd.c | 2 +- xen/arch/x86/cpu/mcheck/mce.c | 2 +- xen/arch/x86/cpu/microcode/core.c | 2 +- xen/arch/x86/dom0_build.c | 4 +- xen/arch/x86/hvm/hvm.c | 2 +- xen/arch/x86/irq.c | 2 +- xen/arch/x86/nmi.c | 2 +- xen/arch/x86/setup.c | 3 +- xen/arch/x86/traps.c | 2 +- xen/arch/x86/x86_64/mmconfig-shared.c | 2 +- xen/common/Kconfig | 8 ++++ xen/common/Makefile | 1 + xen/common/domain.c | 2 +- xen/common/efi/boot.c | 23 ++++++++++++ xen/common/efi/runtime.c | 3 ++ xen/common/kernel.c | 17 ++++++++- xen/common/kexec.c | 2 +- xen/common/lockdown.c | 54 +++++++++++++++++++++++++++ xen/common/numa.c | 2 +- xen/common/page_alloc.c | 2 +- xen/common/shutdown.c | 2 +- xen/drivers/char/console.c | 2 +- xen/drivers/char/ns16550.c | 4 +- xen/drivers/video/vga.c | 2 +- xen/include/xen/efi.h | 6 +++ xen/include/xen/lockdown.h | 11 ++++++ xen/include/xen/param.h | 49 ++++++++++++++++++------ 30 files changed, 200 insertions(+), 35 deletions(-) create mode 100644 xen/common/lockdown.c create mode 100644 xen/include/xen/lockdown.h -- 2.42.0 From xen-devel-bounces@lists.xenproject.org Mon Jun 02 13:47:08 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 13:47:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003400.1382954 (Exim 4.92) (envelope-from ) id 1uM5VJ-000757-Nx; Mon, 02 Jun 2025 13:47:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003400.1382954; Mon, 02 Jun 2025 13:47:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uM5VJ-00074y-LL; Mon, 02 Jun 2025 13:47:05 +0000 Received: by outflank-mailman (input) for mailman id 1003400; Mon, 02 Jun 2025 13:47: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 1uM5VI-000739-R5 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 13:47:04 +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 106991bf-3fb8-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 15:47:03 +0200 (CEST) Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-ad88105874aso687584266b.1 for ; Mon, 02 Jun 2025 06:47:03 -0700 (PDT) Received: from fedora.eng.citrite.net ([185.25.67.249]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ada5dd04591sm790372466b.114.2025.06.02.06.47.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 06:47:01 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 106991bf-3fb8-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1748872022; x=1749476822; darn=lists.xenproject.org; h=content-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=lUY9aLovER8VbMW5czTU1XwpbiLmoqQ0EIkuCpbO60s=; b=iFyzM7Lznth22fYcf40jChkwAIpHkNO+NHUStVwtk9XRMjyevJYfrcTVtjgAsPneDf TIYAqaM5lQLH+zRSRrZEC9DaMhcf8N03Vbb7Hrp8Ftx5Ctl17pRA3XGkWj1zo3SZiApW hw/2epm9t+7zk/BNQ0QH3fh0b1jcfVNMlFvdQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748872022; x=1749476822; 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=lUY9aLovER8VbMW5czTU1XwpbiLmoqQ0EIkuCpbO60s=; b=sV4SsgxAsu3huvbgWKqWU0xa/XKFAXDoKiRxMLP/Bkx5A+jqheKO+LnraR9jYSMnV0 WWg0RuwJXJEZKzjA/SzhwOILSC4+RwonuLW4fykyq17Sag5ttAMIB0uQpiM8Hh+VN+te uxqC+TaFiuMk+i7TS5P0prE/RWFjQdM5bO786ADW/KKJBoEWkJxcKor9vOzS/5BfgjA3 dujc5W2CT8uHu9KobHQMwW5Lot08wonhOBhRkYo3z+j1nLzO9y/di5kQcpxFPILNP34n YldOLa8Ld7/C0YtxsLJTvgA2fDkgaA9A0L5dz9xlO4QN8/PwDjCo1gD4xBHQaDaV7z/o kKOA== X-Gm-Message-State: AOJu0Yy1YzJc8Jb1Dlwi9LLCmH0Fr65g/SEUiIHWyFBNcFFsFhKUlQRY 5Dema7oB9v1aTav8+I2Tr8lyuE/4p1Jv6Yivc1JbDMr9crhD4eGKiGAF7BHmYtgR4ElunlNldKQ JRsD1 X-Gm-Gg: ASbGncsLhY9+r3qtM7oSvybIK+ENprowwi1S36QziHWotBV0mpzNyzR49tKwD32L6MF oViOZJJYBuJMqTbfgB72ZljLQazq2w/tPQ0koNumS1FfkY++beBIA0R4JBRHcAnfLMB81t9G27b ez+Cr8HD8s1hNF5aIE3vJJ9EgNAqAFFYPXYOuuIsdl8XSsCPv+UmvNxdv0qDO/TNMkTY3Wm8q/V 8PH7D/EFY/lrCiwk8mX4tCvhsQPFWFT9pvZ+cdI7LWtz3QbNzRHPWuVuJIgERpVzUgrqT57wSJh 4SrV5YlF/QG0eCqwSRFKRyWCt6cowryEIt/FqNzf/jItCmbFVT/hps0Gdthtbg7ZbJy2 X-Google-Smtp-Source: AGHT+IE7h0pcwcJQaHNurqLaeDeDGh2s76qegW3LqKsV3t6RmL+M2iTUFPHtBRYNTB/o21N3dUGUNQ== X-Received: by 2002:a17:907:6e86:b0:ad2:2569:696d with SMTP id a640c23a62f3a-adb322d8912mr1203167466b.15.1748872022189; Mon, 02 Jun 2025 06:47:02 -0700 (PDT) From: Kevin Lampis To: xen-devel@lists.xenproject.org Cc: Ross Lagerwall , Kevin Lampis Subject: [PATCH v2 1/3] efi: Add a function to check if Secure Boot mode is enabled Date: Mon, 2 Jun 2025 14:46:54 +0100 Message-ID: <20250602134656.3836280-2-kevin.lampis@cloud.com> X-Mailer: git-send-email 2.42.0 In-Reply-To: <20250602134656.3836280-1-kevin.lampis@cloud.com> References: <20250602134656.3836280-1-kevin.lampis@cloud.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Ross Lagerwall Also cache it to avoid needing to repeatedly ask the firmware. Signed-off-by: Ross Lagerwall Signed-off-by: Kevin Lampis --- Changes in v2: - None --- xen/common/efi/boot.c | 23 +++++++++++++++++++++++ xen/common/efi/runtime.c | 3 +++ xen/include/xen/efi.h | 6 ++++++ 3 files changed, 32 insertions(+) diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c index e39fbc3529..7c528cd5dd 100644 --- a/xen/common/efi/boot.c +++ b/xen/common/efi/boot.c @@ -870,6 +870,27 @@ static void __init pre_parse(const struct file *file) " last line will be ignored.\r\n"); } +static void __init init_secure_boot_mode(void) +{ + EFI_STATUS status; + EFI_GUID gv_uuid = EFI_GLOBAL_VARIABLE; + uint8_t data = 0; + UINTN size = sizeof(data); + UINT32 attr = 0; + status = efi_rs->GetVariable((CHAR16 *)L"SecureBoot", &gv_uuid, &attr, + &size, &data); + + if ( status == EFI_NOT_FOUND || + (status == EFI_SUCCESS && + attr == (EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS) && + size == 1 && data == 0) ) + /* Platform does not support Secure Boot or it's disabled. */ + efi_secure_boot = false; + else + /* Everything else play it safe and assume enabled. */ + efi_secure_boot = true; +} + static void __init efi_init(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable) { efi_ih = ImageHandle; @@ -884,6 +905,8 @@ static void __init efi_init(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTabl StdOut = SystemTable->ConOut; StdErr = SystemTable->StdErr ?: StdOut; + + init_secure_boot_mode(); } static void __init efi_console_set_mode(void) diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c index 7e1fce291d..b63d21f16c 100644 --- a/xen/common/efi/runtime.c +++ b/xen/common/efi/runtime.c @@ -40,6 +40,9 @@ void efi_rs_leave(struct efi_rs_state *state); unsigned int __read_mostly efi_num_ct; const EFI_CONFIGURATION_TABLE *__read_mostly efi_ct; +#if defined(CONFIG_X86) && !defined(CONFIG_PV_SHIM) +bool __ro_after_init efi_secure_boot; +#endif unsigned int __read_mostly efi_version; unsigned int __read_mostly efi_fw_revision; const CHAR16 *__read_mostly efi_fw_vendor; diff --git a/xen/include/xen/efi.h b/xen/include/xen/efi.h index 160804e294..ae10ac62d0 100644 --- a/xen/include/xen/efi.h +++ b/xen/include/xen/efi.h @@ -40,6 +40,12 @@ static inline bool efi_enabled(unsigned int feature) } #endif +#if defined(CONFIG_X86) && !defined(CONFIG_PV_SHIM) +extern bool efi_secure_boot; +#else +#define efi_secure_boot false +#endif + void efi_init_memory(void); bool efi_boot_mem_unused(unsigned long *start, unsigned long *end); bool efi_rs_using_pgtables(void); -- 2.42.0 From xen-devel-bounces@lists.xenproject.org Mon Jun 02 13:47:12 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 13:47:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003402.1382964 (Exim 4.92) (envelope-from ) id 1uM5VQ-0007OS-19; Mon, 02 Jun 2025 13:47:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003402.1382964; Mon, 02 Jun 2025 13:47:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uM5VP-0007OL-T9; Mon, 02 Jun 2025 13:47:11 +0000 Received: by outflank-mailman (input) for mailman id 1003402; Mon, 02 Jun 2025 13:47: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 1uM5VO-0006ld-Dp for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 13:47:10 +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 147dc699-3fb8-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 15:47:10 +0200 (CEST) Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-ad1d1f57a01so822134666b.2 for ; Mon, 02 Jun 2025 06:47:10 -0700 (PDT) Received: from fedora.eng.citrite.net ([185.25.67.249]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ada5dd04591sm790372466b.114.2025.06.02.06.47.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 06:47:08 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 147dc699-3fb8-11f0-a300-13f23c93f187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1748872029; x=1749476829; darn=lists.xenproject.org; h=content-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=cZi9jqmMrV3NUMU+6p8ZI4T+vj2Im9r5MjIQcF216lA=; b=NEG1N6Achj5DnEPm0LIjxoTTJDZoKwY3I68uSKd5m1Egf+zQjiEaAcw5vvruaDKKYa iN10xSieMXZkA97uWhQyH4OeABYYcS1I+svGFAMiYRfdQuSw4meQug0usKRJo4xP5j9L R6NT+L6cXl3DBQkyEM36lWj05gzJ0lqZi8ovA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748872029; x=1749476829; 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=cZi9jqmMrV3NUMU+6p8ZI4T+vj2Im9r5MjIQcF216lA=; b=YlpQDRVcXcmJuWEuNEEqs/SFRL0jq916W8VTXRL6xqW8iN6Rb3ur1grlhjd/lUQ5Uy r7vM4oqnATje/onKE8pU/ModTUF0bwHPQ9ZAhTNyLc0D5o0hn8Kaq/MxCnXW5a3gX/1h S6VPxeamo1fLjw9tMi1nLDI73m5JE3zD/zPtwdwUqDYRDRGg8grCQOiXLCkfduVF3pwt HZUKUnhY9Zc3aRR6E1bSNUVWvqKFzdXPj3/pgfX6E5tIopnmHTVBmdAx3a9ajdLb6u1L WYyQd0GXoWHP1C/9WAuEx8HGAjb+9l+sVYetNklFFvzy7lJAvVs/kRu1CLZdVkR4AJcV 8vHA== X-Gm-Message-State: AOJu0Yx7n2w2WU330G8Gs6pSXH5DBYFrTLX/qgDf7fUYZCNyK5YX1Cno g3BjwDuDxy0ug+qpjXWTaxuXtBrj5YFCfyF9aGfyeTaKLFA5f5UAFKuMx2bF99+1hf7hdfcLCzq 5gjOd X-Gm-Gg: ASbGncsU4DrfZlUOim71lB/cyeNv7WAIjrVhd1m3HjQW168SXUCHF5+mSwFK5+6Uac0 N6V0aVh41X8AL1LGzL0EDzjO/eAHFiMKhL8MAGBjLfkKQUDsDAofJZO69FAh3y/XjNH32La4iDc AX6548zIDpLJNnjKad0A2Y/q21lLbf+8lLT8yRC1cE2wK5zWuMVIV8WYuo4D3m58jixx1In98z6 MrnJ+TmK2zeNsFl/pm2pwqdF1de2uvR30Cwon9j5+rtkEOCG/0AEAfud3IVQJl/0+SA0WFg7M6M Bq/PhzGhccd0SJJ2jHjGFe9eVcF9GLkli+00JaqRUHk0qAKaNRVPJ3lCGG/lkX4BFfrhFVfnuLK lUDw= X-Google-Smtp-Source: AGHT+IFdvk3SBy1J7ejqhoPz10BChSbI+ROrbhjjlADH8cMRQufcnFqODx7E3KZLuRuQkai9PazRmg== X-Received: by 2002:a17:907:9404:b0:ad8:8c09:a51a with SMTP id a640c23a62f3a-adb32264c43mr1362741666b.4.1748872028897; Mon, 02 Jun 2025 06:47:08 -0700 (PDT) From: Kevin Lampis To: xen-devel@lists.xenproject.org Cc: Ross Lagerwall , Kevin Lampis Subject: [PATCH v2 2/3] Add lockdown mode Date: Mon, 2 Jun 2025 14:46:55 +0100 Message-ID: <20250602134656.3836280-3-kevin.lampis@cloud.com> X-Mailer: git-send-email 2.42.0 In-Reply-To: <20250602134656.3836280-1-kevin.lampis@cloud.com> References: <20250602134656.3836280-1-kevin.lampis@cloud.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Ross Lagerwall The intention of lockdown mode is to prevent attacks from a rogue dom0 userspace from compromising the system. Lockdown mode can be controlled by a Kconfig option and a command-line parameter. It is also enabled automatically when Secure Boot is enabled and it cannot be disabled in that case. If enabled from the command-line then it is required to be first in the list otherwise Xen may process some insecure parameters before reaching the lockdown parameter. Signed-off-by: Ross Lagerwall Signed-off-by: Kevin Lampis --- Changes in v2: - Remove custom command line parsing - Print warning if lockdown is not first on command line --- xen/arch/x86/setup.c | 1 + xen/common/Kconfig | 8 ++++++ xen/common/Makefile | 1 + xen/common/kernel.c | 7 +++++ xen/common/lockdown.c | 54 ++++++++++++++++++++++++++++++++++++++ xen/include/xen/lockdown.h | 11 ++++++++ 6 files changed, 82 insertions(+) create mode 100644 xen/common/lockdown.c create mode 100644 xen/include/xen/lockdown.h diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index 1f5cb67bd0..efeed5eafc 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -15,6 +15,7 @@ #include #include #include +#include #include #include #include diff --git a/xen/common/Kconfig b/xen/common/Kconfig index 0951d4c2f2..33cd669110 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -587,4 +587,12 @@ config BUDDY_ALLOCATOR_SIZE Amount of memory reserved for the buddy allocator to serve Xen heap, working alongside the colored one. +config LOCKDOWN_DEFAULT + bool "Enable lockdown mode by default" + default n + help + Lockdown mode prevents attacks from a rogue dom0 userspace from + compromising the system. This is automatically enabled when Secure + Boot is enabled. + endmenu diff --git a/xen/common/Makefile b/xen/common/Makefile index 98f0873056..b00a8a925a 100644 --- a/xen/common/Makefile +++ b/xen/common/Makefile @@ -26,6 +26,7 @@ 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-y += lockdown.o obj-$(CONFIG_VM_EVENT) += mem_access.o obj-y += memory.o obj-y += multicall.o diff --git a/xen/common/kernel.c b/xen/common/kernel.c index 8b63ca55f1..7280da987d 100644 --- a/xen/common/kernel.c +++ b/xen/common/kernel.c @@ -14,6 +14,7 @@ #include #include #include +#include #include #include #include @@ -199,6 +200,8 @@ static int parse_params(const char *cmdline, const struct kernel_param *start, printk("parameter \"%s\" unknown!\n", key); final_rc = -EINVAL; } + + lockdown_clear_first_flag(); } return final_rc; @@ -216,6 +219,9 @@ static void __init _cmdline_parse(const char *cmdline) */ void __init cmdline_parse(const char *cmdline) { + /* Call this early since it affects command-line parsing */ + lockdown_init(cmdline); + if ( opt_builtin_cmdline[0] ) { printk("Built-in command line: %s\n", opt_builtin_cmdline); @@ -227,6 +233,7 @@ void __init cmdline_parse(const char *cmdline) return; safe_strcpy(saved_cmdline, cmdline); + lockdown_set_first_flag(); _cmdline_parse(cmdline); #endif } diff --git a/xen/common/lockdown.c b/xen/common/lockdown.c new file mode 100644 index 0000000000..84eabe9c83 --- /dev/null +++ b/xen/common/lockdown.c @@ -0,0 +1,54 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ + +#include +#include +#include + +#define FIRST_ARG_FLAG 2 + +static int __ro_after_init lockdown = IS_ENABLED(CONFIG_LOCKDOWN_DEFAULT); + +void __init lockdown_set_first_flag(void) +{ + lockdown |= FIRST_ARG_FLAG; +} + +void __init lockdown_clear_first_flag(void) +{ + lockdown &= ~FIRST_ARG_FLAG; +} + +static int __init parse_lockdown_opt(const char *s) +{ + if ( strncmp("no", s, 2) == 0 ) + if ( efi_secure_boot ) + printk("lockdown can't be disabled because Xen booted in Secure Boot mode\n"); + else + lockdown = 0; + else + { + if ( !(lockdown & FIRST_ARG_FLAG) ) + printk("lockdown was not the first argument, unsafe arguments may have been already processed\n"); + + lockdown = 1; + } + + return 0; +} +custom_param("lockdown", parse_lockdown_opt); + +bool is_locked_down(void) +{ + return lockdown & ~FIRST_ARG_FLAG; +} + +void __init lockdown_init(const char *cmdline) +{ + if ( efi_secure_boot ) + { + printk("Enabling lockdown mode because Secure Boot is enabled\n"); + lockdown = 1; + } + + printk("Lockdown mode is %s\n", is_locked_down() ? "enabled" : "disabled"); +} diff --git a/xen/include/xen/lockdown.h b/xen/include/xen/lockdown.h new file mode 100644 index 0000000000..6ae97f9d5f --- /dev/null +++ b/xen/include/xen/lockdown.h @@ -0,0 +1,11 @@ +#ifndef XEN__LOCKDOWN_H +#define XEN__LOCKDOWN_H + +#include + +void lockdown_set_first_flag(void); +void lockdown_clear_first_flag(void); +bool is_locked_down(void); +void lockdown_init(const char *cmdline); + +#endif /* XEN__LOCKDOWN_H */ -- 2.42.0 From xen-devel-bounces@lists.xenproject.org Mon Jun 02 13:47:18 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 13:47:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003405.1382974 (Exim 4.92) (envelope-from ) id 1uM5VW-0007lo-6m; Mon, 02 Jun 2025 13:47:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003405.1382974; Mon, 02 Jun 2025 13: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 1uM5VW-0007lf-3u; Mon, 02 Jun 2025 13:47:18 +0000 Received: by outflank-mailman (input) for mailman id 1003405; Mon, 02 Jun 2025 13:47: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 1uM5VU-0006ld-JL for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 13:47:16 +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 17a390bb-3fb8-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 15:47:15 +0200 (CEST) Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-ad89c32a7b5so711831166b.2 for ; Mon, 02 Jun 2025 06:47:15 -0700 (PDT) Received: from fedora.eng.citrite.net ([185.25.67.249]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ada5dd04591sm790372466b.114.2025.06.02.06.47.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 06:47:13 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 17a390bb-3fb8-11f0-a300-13f23c93f187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1748872034; x=1749476834; darn=lists.xenproject.org; h=content-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=jeLh8Ma6G37ySiE9rnwoSsxN+Os3m5e6sWsq/WSV0LI=; b=czLZFUEHgHIbREwRctJWRuZlmhja25ZzL1dFGRaWsDj1seQXhqUUHoKkKSAUIxUJyd TaJJawV+8r4t7zsEubpJlsM+jPOf7oYuLDYTCSLqJYCnFR7Ugrw+lBNAlVnkEMt6e33V G36ddhv+R6+oPivXdtIrmLHq8gjuIeBlV9Pdo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748872034; x=1749476834; 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=jeLh8Ma6G37ySiE9rnwoSsxN+Os3m5e6sWsq/WSV0LI=; b=GWJsxZrWLzn7atc5Y40Gz5wSBxaK6D7V8KzN5dLmXPM/FFDSbpuwsCI61TQL5MS/Qd kOOfogk9s9DCKrjoibDxKJPEgejXCPfmOPZNqB1mQJe2pVCbXL7HplOccDQqt7E2DQjk UAMDThOq482d60o1SNOjltrYpLsFrgN3+rn71DcF94q9QrkTScVNInzLQOT888qFJ4Q8 +XH+epiQybIWPqxIp8hwZk2VD5JgV/TQQro72IBe5KD+x7L4qfZ68ws/g32Ball4Qt8g AAvVVTBOF5Y7cNFZWLLwIbTmEnxt/qFh33JashfRZIEtC8TSF3FCHGceCkgFSWjbCjx3 kmZw== X-Gm-Message-State: AOJu0YzyUCT4v5uQ/2Xj6aMCuwCJ60BJGmarpMEiKgdvWf75LzhWL7ts mNQTAjUrvHysjNmTkrRtwCtVWZoNBpC6HMKoNb5ozEhPalUxd0qUXN8nVznvNPOwGhjP+LqiXfg Vzk4d X-Gm-Gg: ASbGncsQmjdT68aDl/g4POQtNyBZo/yQxs3tTp5Lo6RcuqrjDcYwh7ZjdZ6GQETkNEa V6CxM2wPPh3tb/Zolb+5LOE36M75CjYXu/N4LjowVCS3k0tgdIkhwtVd38utMUM+tbZtD2HpOAm da8Jlz0nSEtmVlMvnuL9dO6+Ki0zsEOy/Hb1RhSxefss8YHcT9fTCsmwVgCQVsjDIpRxMWbgRSk +0S2Gsa/7E/WIKpUGXtr6cDOZjd9jlUcBafhg6lTGzd1yc4fzfisPmcmWFEpdgk2lLzy9LqrPRT 6gQvNij36CYlWp5rj3Xw3Dh/+hfEkFHYVvgdO4As4cgTgB3CzvcbriXPZjp6bVSeG34e X-Google-Smtp-Source: AGHT+IEYwBX8bu190Ojee9nWXLiHoSLcBexR8JtlLtqIaRnE3WzzQdWdetG4JLk+JnPEyKtmvjLpHQ== X-Received: by 2002:a17:907:971e:b0:ad8:81c2:64e9 with SMTP id a640c23a62f3a-adb322b3326mr1123457566b.8.1748872034117; Mon, 02 Jun 2025 06:47:14 -0700 (PDT) From: Kevin Lampis To: xen-devel@lists.xenproject.org Cc: Kevin Lampis , Ross Lagerwall Subject: [PATCH v2 3/3] Disallow most command-line options when lockdown mode is enabled Date: Mon, 2 Jun 2025 14:46:56 +0100 Message-ID: <20250602134656.3836280-4-kevin.lampis@cloud.com> X-Mailer: git-send-email 2.42.0 In-Reply-To: <20250602134656.3836280-1-kevin.lampis@cloud.com> References: <20250602134656.3836280-1-kevin.lampis@cloud.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit A subset of command-line parameters that are specifically safe to use when lockdown mode is enabled are annotated as such. These are commonly used parameters which have been audited to ensure they cannot be used to undermine the integrity of the system when booted in Secure Boot mode. Signed-off-by: Kevin Lampis Signed-off-by: Ross Lagerwall --- Changes in v2: - Add more information about the safe parameters - Add lockdown section to the command line doc --- docs/misc/xen-command-line.pandoc | 16 +++++++++ xen/arch/arm/domain_build.c | 4 +-- xen/arch/x86/acpi/cpu_idle.c | 2 +- xen/arch/x86/cpu/amd.c | 2 +- xen/arch/x86/cpu/mcheck/mce.c | 2 +- xen/arch/x86/cpu/microcode/core.c | 2 +- xen/arch/x86/dom0_build.c | 4 +-- xen/arch/x86/hvm/hvm.c | 2 +- xen/arch/x86/irq.c | 2 +- xen/arch/x86/nmi.c | 2 +- xen/arch/x86/setup.c | 2 +- xen/arch/x86/traps.c | 2 +- xen/arch/x86/x86_64/mmconfig-shared.c | 2 +- xen/common/domain.c | 2 +- xen/common/kernel.c | 10 +++++- xen/common/kexec.c | 2 +- xen/common/lockdown.c | 2 +- xen/common/numa.c | 2 +- xen/common/page_alloc.c | 2 +- xen/common/shutdown.c | 2 +- xen/drivers/char/console.c | 2 +- xen/drivers/char/ns16550.c | 4 +-- xen/drivers/video/vga.c | 2 +- xen/include/xen/param.h | 49 +++++++++++++++++++++------ 24 files changed, 87 insertions(+), 36 deletions(-) diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index b0eadd2c5d..7916875f22 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -1798,6 +1798,22 @@ immediately. Specifying `0` will disable all testing of illegal lock nesting. This option is available for hypervisors built with CONFIG_DEBUG_LOCKS only. +### lockdown +> `= ` + +> Default: `false` + +The intention of lockdown mode is to prevent attacks from a rogue dom0 +userspace from compromising the system. It is also enabled automatically +when Secure Boot is enabled and it cannot be disabled in that case. + +After lockdown mode is enabled some unsafe command line options will be +ignored by Xen. + +If enabling lockdown mode via the command line then ensure it is positioned as +the first option in the command line string otherwise Xen may process unsafe +options before reaching the lockdown parameter. + ### loglvl > `= [/]` where level is `none | error | warning | info | debug | all` diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index b189a7cfae..ef1cba8f0f 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -41,7 +41,7 @@ #include static unsigned int __initdata opt_dom0_max_vcpus; -integer_param("dom0_max_vcpus", opt_dom0_max_vcpus); +integer_secure_param("dom0_max_vcpus", opt_dom0_max_vcpus); /* * If true, the extended regions support is enabled for dom0 and @@ -61,7 +61,7 @@ static int __init parse_dom0_mem(const char *s) return *s ? -EINVAL : 0; } -custom_param("dom0_mem", parse_dom0_mem); +custom_secure_param("dom0_mem", parse_dom0_mem); int __init parse_arch_dom0_param(const char *s, const char *e) { diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/acpi/cpu_idle.c index 1dbf15b01e..431fd0c997 100644 --- a/xen/arch/x86/acpi/cpu_idle.c +++ b/xen/arch/x86/acpi/cpu_idle.c @@ -113,7 +113,7 @@ static int __init cf_check parse_cstate(const char *s) max_csubstate = simple_strtoul(s + 1, NULL, 0); return 0; } -custom_param("max_cstate", parse_cstate); +custom_secure_param("max_cstate", parse_cstate); static bool __read_mostly local_apic_timer_c2_ok; boolean_param("lapic_timer_c2_ok", local_apic_timer_c2_ok); diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c index 27ae167808..9aab3d05e1 100644 --- a/xen/arch/x86/cpu/amd.c +++ b/xen/arch/x86/cpu/amd.c @@ -47,7 +47,7 @@ integer_param("cpuid_mask_thermal_ecx", opt_cpuid_mask_thermal_ecx); /* 1 = allow, 0 = don't allow guest creation, -1 = don't allow boot */ int8_t __read_mostly opt_allow_unsafe; -boolean_param("allow_unsafe", opt_allow_unsafe); +boolean_secure_param("allow_unsafe", opt_allow_unsafe); /* Signal whether the ACPI C1E quirk is required. */ bool __read_mostly amd_acpi_c1e_quirk; diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c index 1c348e557d..a229af6fd3 100644 --- a/xen/arch/x86/cpu/mcheck/mce.c +++ b/xen/arch/x86/cpu/mcheck/mce.c @@ -31,7 +31,7 @@ #include "vmce.h" bool __read_mostly opt_mce = true; -boolean_param("mce", opt_mce); +boolean_secure_param("mce", opt_mce); bool __read_mostly mce_broadcast; bool is_mc_panic; DEFINE_PER_CPU_READ_MOSTLY(unsigned int, nr_mce_banks); diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c index 34a94cd25b..b5b7304ae7 100644 --- a/xen/arch/x86/cpu/microcode/core.c +++ b/xen/arch/x86/cpu/microcode/core.c @@ -160,7 +160,7 @@ static int __init cf_check parse_ucode(const char *s) return rc; } -custom_param("ucode", parse_ucode); +custom_secure_param("ucode", parse_ucode); static struct microcode_ops __ro_after_init ucode_ops; diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c index 0b467fd4a4..6d42acb661 100644 --- a/xen/arch/x86/dom0_build.c +++ b/xen/arch/x86/dom0_build.c @@ -142,7 +142,7 @@ static int __init cf_check parse_dom0_mem(const char *s) return s[-1] ? -EINVAL : ret; } -custom_param("dom0_mem", parse_dom0_mem); +custom_secure_param("dom0_mem", parse_dom0_mem); static unsigned int __initdata opt_dom0_max_vcpus_min = 1; static unsigned int __initdata opt_dom0_max_vcpus_max = UINT_MAX; @@ -164,7 +164,7 @@ static int __init cf_check parse_dom0_max_vcpus(const char *s) return *s ? -EINVAL : 0; } -custom_param("dom0_max_vcpus", parse_dom0_max_vcpus); +custom_secure_param("dom0_max_vcpus", parse_dom0_max_vcpus); static __initdata unsigned int dom0_nr_pxms; static __initdata unsigned int dom0_pxms[MAX_NUMNODES] = diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index 4cb2e13046..97afb274fe 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -87,7 +87,7 @@ unsigned long __section(".bss.page_aligned") __aligned(PAGE_SIZE) /* Xen command-line option to enable HAP */ static bool __initdata opt_hap_enabled = true; -boolean_param("hap", opt_hap_enabled); +boolean_secure_param("hap", opt_hap_enabled); #ifndef opt_hvm_fep /* Permit use of the Forced Emulation Prefix in HVM guests */ diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c index 556134f85a..44f39f6ece 100644 --- a/xen/arch/x86/irq.c +++ b/xen/arch/x86/irq.c @@ -34,7 +34,7 @@ /* opt_noirqbalance: If true, software IRQ balancing/affinity is disabled. */ bool __read_mostly opt_noirqbalance; -boolean_param("noirqbalance", opt_noirqbalance); +boolean_secure_param("noirqbalance", opt_noirqbalance); unsigned int __read_mostly nr_irqs_gsi = NR_ISA_IRQS; unsigned int __read_mostly nr_irqs; diff --git a/xen/arch/x86/nmi.c b/xen/arch/x86/nmi.c index 9793fa2316..3735f22e88 100644 --- a/xen/arch/x86/nmi.c +++ b/xen/arch/x86/nmi.c @@ -73,7 +73,7 @@ static int __init cf_check parse_watchdog(const char *s) return 0; } -custom_param("watchdog", parse_watchdog); +custom_secure_param("watchdog", parse_watchdog); /* opt_watchdog_timeout: Number of seconds to wait before panic. */ static unsigned int opt_watchdog_timeout = 5; diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index efeed5eafc..adfaf8667b 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -71,7 +71,7 @@ /* opt_nosmp: If true, secondary processors are ignored. */ static bool __initdata opt_nosmp; -boolean_param("nosmp", opt_nosmp); +boolean_secure_param("nosmp", opt_nosmp); /* maxcpus: maximum number of CPUs to activate. */ static unsigned int __initdata max_cpus; diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c index 092c7e4197..1a1ce541c3 100644 --- a/xen/arch/x86/traps.c +++ b/xen/arch/x86/traps.c @@ -61,7 +61,7 @@ static char __read_mostly opt_nmi[10] = "dom0"; #else static char __read_mostly opt_nmi[10] = "fatal"; #endif -string_param("nmi", opt_nmi); +string_secure_param("nmi", opt_nmi); DEFINE_PER_CPU(uint64_t, efer); static DEFINE_PER_CPU(unsigned long, last_extable_addr); diff --git a/xen/arch/x86/x86_64/mmconfig-shared.c b/xen/arch/x86/x86_64/mmconfig-shared.c index f1a3d42c5b..80cdca7d77 100644 --- a/xen/arch/x86/x86_64/mmconfig-shared.c +++ b/xen/arch/x86/x86_64/mmconfig-shared.c @@ -60,7 +60,7 @@ static int __init cf_check parse_mmcfg(const char *s) return rc; } -custom_param("mmcfg", parse_mmcfg); +custom_secure_param("mmcfg", parse_mmcfg); static const char *__init cf_check pci_mmcfg_e7520(void) { diff --git a/xen/common/domain.c b/xen/common/domain.c index abf1969e60..c95988c067 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -55,7 +55,7 @@ unsigned int xen_processor_pmbits = XEN_PROCESSOR_PM_PX; /* opt_dom0_vcpus_pin: If true, dom0 VCPUs are pinned. */ bool opt_dom0_vcpus_pin; -boolean_param("dom0_vcpus_pin", opt_dom0_vcpus_pin); +boolean_secure_param("dom0_vcpus_pin", opt_dom0_vcpus_pin); /* Protect updates/reads (resp.) of domain_list and domain_hash. */ DEFINE_SPINLOCK(domlist_update_lock); diff --git a/xen/common/kernel.c b/xen/common/kernel.c index 7280da987d..923ea43cee 100644 --- a/xen/common/kernel.c +++ b/xen/common/kernel.c @@ -14,6 +14,7 @@ #include #include #include +#include #include #include #include @@ -136,9 +137,16 @@ static int parse_params(const char *cmdline, const struct kernel_param *start, } continue; } + found = true; + + if ( !param->is_lockdown_safe && is_locked_down() ) + { + printk("Ignoring unsafe cmdline option %s in lockdown mode\n", + param->name); + break; + } rctmp = 0; - found = true; switch ( param->type ) { case OPT_STR: diff --git a/xen/common/kexec.c b/xen/common/kexec.c index 84fe8c3597..790839657d 100644 --- a/xen/common/kexec.c +++ b/xen/common/kexec.c @@ -189,7 +189,7 @@ static int __init cf_check parse_crashkernel(const char *str) return rc; } -custom_param("crashkernel", parse_crashkernel); +custom_secure_param("crashkernel", parse_crashkernel); /* Parse command lines in the format: * diff --git a/xen/common/lockdown.c b/xen/common/lockdown.c index 84eabe9c83..cd3deeb63e 100644 --- a/xen/common/lockdown.c +++ b/xen/common/lockdown.c @@ -35,7 +35,7 @@ static int __init parse_lockdown_opt(const char *s) return 0; } -custom_param("lockdown", parse_lockdown_opt); +custom_secure_param("lockdown", parse_lockdown_opt); bool is_locked_down(void) { diff --git a/xen/common/numa.c b/xen/common/numa.c index ad75955a16..c4981f2ff1 100644 --- a/xen/common/numa.c +++ b/xen/common/numa.c @@ -687,7 +687,7 @@ static int __init cf_check numa_setup(const char *opt) return 0; } -custom_param("numa", numa_setup); +custom_secure_param("numa", numa_setup); static void cf_check dump_numa(unsigned char key) { diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index e57a287133..a07690d8fd 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -235,7 +235,7 @@ static int __init cf_check parse_bootscrub_param(const char *s) return 0; } -custom_param("bootscrub", parse_bootscrub_param); +custom_secure_param("bootscrub", parse_bootscrub_param); /* * bootscrub_chunk -> Amount of bytes to scrub lockstep on non-SMT CPUs diff --git a/xen/common/shutdown.c b/xen/common/shutdown.c index c47341b977..231de1454a 100644 --- a/xen/common/shutdown.c +++ b/xen/common/shutdown.c @@ -13,7 +13,7 @@ /* opt_noreboot: If true, machine will need manual reset on error. */ bool __ro_after_init opt_noreboot; -boolean_param("noreboot", opt_noreboot); +boolean_secure_param("noreboot", opt_noreboot); static void noreturn reboot_or_halt(void) { diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index 30701ae0b0..4f4f4aab19 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -65,7 +65,7 @@ static void console_send(const char *str, size_t len, unsigned int flags); /* console: comma-separated list of console outputs. */ static char __initdata opt_console[30] = OPT_CONSOLE_STR; -string_param("console", opt_console); +string_secure_param("console", opt_console); /* conswitch: a character pair controlling console switching. */ /* Char 1: CTRL+ is used to switch console input between Xen and DOM0 */ diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c index eaeb0e09d0..fae509cbd8 100644 --- a/xen/drivers/char/ns16550.c +++ b/xen/drivers/char/ns16550.c @@ -1390,8 +1390,8 @@ static void enable_exar_enhanced_bits(const struct ns16550 *uart) */ static char __initdata opt_com1[128] = ""; static char __initdata opt_com2[128] = ""; -string_param("com1", opt_com1); -string_param("com2", opt_com2); +string_secure_param("com1", opt_com1); +string_secure_param("com2", opt_com2); enum serial_param_type { baud_rate, diff --git a/xen/drivers/video/vga.c b/xen/drivers/video/vga.c index b577b24619..abc6e56aa3 100644 --- a/xen/drivers/video/vga.c +++ b/xen/drivers/video/vga.c @@ -48,7 +48,7 @@ void (*video_puts)(const char *s, size_t nr) = vga_noop_puts; * control of the console to domain 0. */ static char __initdata opt_vga[30] = ""; -string_param("vga", opt_vga); +string_secure_param("vga", opt_vga); /* VGA text-mode definitions. */ static unsigned int columns, lines; diff --git a/xen/include/xen/param.h b/xen/include/xen/param.h index 1bdbab34ab..31e7326d88 100644 --- a/xen/include/xen/param.h +++ b/xen/include/xen/param.h @@ -25,6 +25,7 @@ struct kernel_param { void *var; int (*func)(const char *s); } par; + bool is_lockdown_safe; }; /* Maximum length of a single parameter string. */ @@ -44,46 +45,72 @@ extern const struct kernel_param __setup_start[], __setup_end[]; #define _TEMP_NAME(base, line) __TEMP_NAME(base, line) #define TEMP_NAME(base) _TEMP_NAME(base, __LINE__) -#define custom_param(_name, _var) \ +#define custom_param_(_name, _var, _sec) \ __setup_str __setup_str_##_var[] = (_name); \ __kparam __setup_##_var = \ { .name = __setup_str_##_var, \ .type = OPT_CUSTOM, \ - .par.func = (_var) } -#define boolean_param(_name, _var) \ + .par.func = (_var), \ + .is_lockdown_safe = (_sec) } +#define custom_param(_name, _var) \ + custom_param_(_name, _var, false) +#define custom_secure_param(_name, _var) \ + custom_param_(_name, _var, true) +#define boolean_param_(_name, _var, _sec) \ __setup_str __setup_str_##_var[] = (_name); \ __kparam __setup_##_var = \ { .name = __setup_str_##_var, \ .type = OPT_BOOL, \ .len = sizeof(_var) + \ BUILD_BUG_ON_ZERO(sizeof(_var) != sizeof(bool)), \ - .par.var = &(_var) } -#define integer_param(_name, _var) \ + .par.var = &(_var), \ + .is_lockdown_safe = (_sec) } +#define boolean_param(_name, _var) \ + boolean_param_(_name, _var, false) +#define boolean_secure_param(_name, _var) \ + boolean_param_(_name, _var, true) +#define integer_param_(_name, _var, _sec) \ __setup_str __setup_str_##_var[] = (_name); \ __kparam __setup_##_var = \ { .name = __setup_str_##_var, \ .type = OPT_UINT, \ .len = sizeof(_var), \ - .par.var = &(_var) } -#define size_param(_name, _var) \ + .par.var = &(_var), \ + .is_lockdown_safe = (_sec) } +#define integer_param(_name, _var) \ + integer_param_(_name, _var, false) +#define integer_secure_param(_name, _var) \ + integer_param_(_name, _var, true) +#define size_param_(_name, _var, _sec) \ __setup_str __setup_str_##_var[] = (_name); \ __kparam __setup_##_var = \ { .name = __setup_str_##_var, \ .type = OPT_SIZE, \ .len = sizeof(_var), \ - .par.var = &(_var) } -#define string_param(_name, _var) \ + .par.var = &(_var), \ + .is_lockdown_safe = (_sec) } +#define size_param(_name, _var) \ + size_param_(_name, _var, false) +#define size_secure_param(_name, _var) \ + size_param_(_name, _var, true) +#define string_param_(_name, _var, _sec) \ __setup_str __setup_str_##_var[] = (_name); \ __kparam __setup_##_var = \ { .name = __setup_str_##_var, \ .type = OPT_STR, \ .len = sizeof(_var), \ - .par.var = &(_var) } + .par.var = &(_var), \ + .is_lockdown_safe = (_sec) } +#define string_param(_name, _var) \ + string_param_(_name, _var, false) +#define string_secure_param(_name, _var) \ + string_param_(_name, _var, true) #define ignore_param(_name) \ __setup_str TEMP_NAME(__setup_str_ign)[] = (_name); \ __kparam TEMP_NAME(__setup_ign) = \ { .name = TEMP_NAME(__setup_str_ign), \ - .type = OPT_IGNORE } + .type = OPT_IGNORE, \ + .is_lockdown_safe = true } #ifdef CONFIG_HYPFS -- 2.42.0 From xen-devel-bounces@lists.xenproject.org Mon Jun 02 14:01:48 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 14:01:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003435.1382984 (Exim 4.92) (envelope-from ) id 1uM5jS-0003UV-GN; Mon, 02 Jun 2025 14:01:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003435.1382984; Mon, 02 Jun 2025 14:01:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uM5jS-0003UO-DG; Mon, 02 Jun 2025 14:01:42 +0000 Received: by outflank-mailman (input) for mailman id 1003435; Mon, 02 Jun 2025 14: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 1uM5jR-0003UI-BZ for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 14:01:41 +0000 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on20609.outbound.protection.outlook.com [2a01:111:f403:2415::609]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 1a087b87-3fba-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 16:01:39 +0200 (CEST) Received: from PH8PR02CA0007.namprd02.prod.outlook.com (2603:10b6:510:2d0::18) by SA3PR12MB7999.namprd12.prod.outlook.com (2603:10b6:806:312::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.32; Mon, 2 Jun 2025 14:01:35 +0000 Received: from SJ1PEPF000023D4.namprd21.prod.outlook.com (2603:10b6:510:2d0:cafe::b4) by PH8PR02CA0007.outlook.office365.com (2603:10b6:510:2d0::18) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.19 via Frontend Transport; Mon, 2 Jun 2025 14:01:35 +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.8835.2 via Frontend Transport; Mon, 2 Jun 2025 14:01:34 +0000 Received: from localhost (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 Jun 2025 09:01:32 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1a087b87-3fba-11f0-a300-13f23c93f187 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=chy0kpLjGVdV8WkiiBwAegRUIvwCVNk9pivzdoh/iYVxMgGzqQCjIlCy4jhEXy1q5/y5kMRyjb5xbn4Y/J38gGWAPLWkGiQENJwB7c09SBxP2a5iQpPtrG5N2UoOa0NzSZVjmwA9RbkH5mTCSq/segOZ0ZX+oytA08arlwuvazDTF6BvigsG7gxXOsQpQ5ay/g8lKiWbHPvHM1XnWL2+nV1oV1uZZuGWoqCyHOTI9QC45BZDjFDZLT+IE8j1gHwsCe2R6AtXe34T5IUjUvRXA+y9LNK4xJlY96MjsXE5zOsAGvjOsOlXRpwkqjCAsAWOKT5Q7ZhqseSw69lLfSkWKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ld1S+SP5zIa3cFaYHbDba9acNH4nT5mVLdFuQSLkneE=; b=CXtZzVtwqMg4K06Tnh7PyPReoaF8z55SfFITVuNcabGhhYTjWUO0Rvo3QFQwdAFNmMU19dMCOQAKu0ODzdsZI8BWhqpHMqTlT36ucVxW99ufBjq4SDaoBf4RUVCNtd6BeTiztuehA+xsLQ8exFPJMUtQX7k0At9RCd88IZxpAnSMBdG9a2acHP+V30zDqbPHFd5tFef6Y0wRnj4CB2+NHp54U71hBhnik5FHPgECcu3Qa6ZueLViUjk1oWWCZ29S48OOrrOiv1HAvsn2wei92BQpNxc01gus9hLbc+TT2gi5RTCjBNwjL9h4Bwy1SWLpq44EgfeVC/401NAfnU/b5g== 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=ld1S+SP5zIa3cFaYHbDba9acNH4nT5mVLdFuQSLkneE=; b=wLjLxHZ83JJAYid29JII/O8nIl/fKkkR99SWDdiozPMAR22t6Avb2uc3HwXcpIZxR1l1DlmH7/vw7OgCrWQ0Q13OzPol5xQu0uMevIrbNijCvjmG+sT64nwm4HCPXN/TIeYiTfehGJ7/X3DKOqOPFeFHhE1hXZ3dIxo7pykIhAI= 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 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Date: Mon, 2 Jun 2025 16:01:29 +0200 Message-ID: CC: Andrew Cooper , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , "Daniel P. Smith" , Subject: Re: [PATCH 02/19] x86: Add missing pci_dev forward declaration in asm/pci.h From: Alejandro Vallejo To: Jan Beulich X-Mailer: aerc 0.20.1 References: <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-3-agarciav@amd.com> <680c7ba4-e4f4-4fb9-969d-ecaa206e37c6@suse.com> In-Reply-To: <680c7ba4-e4f4-4fb9-969d-ecaa206e37c6@suse.com> 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: SJ1PEPF000023D4:EE_|SA3PR12MB7999:EE_ X-MS-Office365-Filtering-Correlation-Id: 899cb75f-f14b-4b69-8455-08dda1ddfc3d 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?TnZJZnozb2NucHk4VEtNUlhMb3Q5UjhNck94amJVeUlsV2ZzM3R0Z0FQc3hZ?= =?utf-8?B?L2NydmpxTGxWSUhzdUFGdndJdFNlN3lFeEtMNlVyOFcrS2M1MmhtUEVhcW9X?= =?utf-8?B?TlRRQmdLTE5GTFpHVGF0S29DV1d3eVk4QTV4UzZKWTNyTGtOZUpSQy82RDlS?= =?utf-8?B?bG0xSng2OER1a0hOb2x3T1NiakhxNGc1U2pQM0ZLeTg3SHVwd1d0UGNMcjZP?= =?utf-8?B?Nko1K1VQL3RXdWpSU0lSMGh1cmlGcnBIZmwxK2RUbWpvMHNIYjR5Yk1LK0xo?= =?utf-8?B?N0lLTVRLbkJIbTBEQzhqREFpOXEwRFhlQlJNOHhsYmN0YmxkV2RkZjlTQUNV?= =?utf-8?B?WkdIWDBQeERDa0VIRXpVZ09FeG5keGkyblJ3cWJBenM2eWNYQ3J2TytJaEcz?= =?utf-8?B?VmhXaXkzMERUcTVOaUk3UExzZyt1d05wZzYrSEVZOU1PS0NBT2dvVVlxc0hi?= =?utf-8?B?NVB3cVlTSUR4b04yQjFESFF1N1RLZ1M4WEtxYnlqd2YxTm1ZQnFjUkdCNEZB?= =?utf-8?B?eGpVTWUxVHhLUEltNEFCNXd2TFNVeVRMLzYvT0YvUmJDa3dVQndLUlR1Q1pp?= =?utf-8?B?R3lrdDBBMlhBNHA5U0Fhdk5Ndzl5KzRyOStFdk5DUnh1ejVpUDQ5U2xLTkVx?= =?utf-8?B?cWNzRVlFMHZQcWFhSDdRM3p4ZFNFRldmM2VuUysxUGx6SHNYQWhzTzZZT1Zk?= =?utf-8?B?TTF3UEZhL0dHT3FyTUFtOUI2QUtQaGhUUHVCMEpUSnJlSG51UkprN3B5Nkov?= =?utf-8?B?ZE5LdmVKZno3OTNWU3QxTUpxU0dzb1JZTmxDSzRBaFluSFdZVnhEb1BGb042?= =?utf-8?B?WHFqZlJETWhTTlplZTU2SHJpQ3FCOVF3dmJ4d3FjWFBIRVd1cGtEa1JORDRE?= =?utf-8?B?MmhRcGFITzR6SXlod0NIRGtnNHFJQllsdWp0UmJCZXpKSEc4OHZjbUxkMmVm?= =?utf-8?B?L0pIZ2ZIb0VXSFNwcUl1Vm5Wa3A1WEpkZTFqbUVReU9mSEpHYm1pbVJMZjBw?= =?utf-8?B?ZjJJb2FCWWM3TU9HcTcyZW9tSVhDTE5ma1R0REVQRDc0bHNUUjlUT0RIcytq?= =?utf-8?B?Wld6L0hqQlc1RDFUQzUwbFhZbkx2NkQycWlHTHVmQVNKb3hCUWVYYTlGakxn?= =?utf-8?B?UlU5ejJKL0hWZGgzVWl0TlJHWForT1NVZi81TnZEZUk0YThCaXZ5VWRPejRW?= =?utf-8?B?UUNhQXlKZVNWSlJxTzlZTFRUSDRWS0xGb084eDBlQXRyN09TblpmWXFYTWY5?= =?utf-8?B?dzZZc2ltYkVVWWFaRWsxc1FQL2xvUnVSRmR1M1Brakk4azFMUjVUaVE3dFpC?= =?utf-8?B?U0FEeTZlUjdxUXVqeUYzYkJ1YlJrVS9tVEpVL1c1K2ZrZmRXTFFsSUZXUXI5?= =?utf-8?B?QW5BK3ZxZTduRTl5MVdpeFBERklhL1ZyNXRMMXNrQUkybnlyRnR3dGp3eHV5?= =?utf-8?B?WHBaUmhkMWFZK3FFSHgxb3YvSHpTanhObXQ3TUk0SkFpUUFVcFlGcVFKUEhV?= =?utf-8?B?dHNIakI5b21vaHdTWXFqK3lQQ0ZCMnJqYUswcE85dm5DdUdZdHRqQldJNlJL?= =?utf-8?B?eDRYZ3gvT0tkZzBNZDZ1ODZVRWdwZGVhZHVwcXV2QUpWcU5rTUw0QjhEUDZ3?= =?utf-8?B?ckZmYy83N3Nqa2VjcHZFdTZXY21IVzFVSHdncUdhVkFpK3hDMGw5bkRFaTVE?= =?utf-8?B?bytyVG4vS0FSRXFHYk1DajFDSnZQRHo3czhFYU5JL0dFR2NUdFlMamVYMjg0?= =?utf-8?B?N1BoeGFhaHJVWjhLdFc3STdVNlpzcUNwMk9EYitXOURZVGIvTWh1SDFhR0Ru?= =?utf-8?B?RVQ4a0cxb1JSdjZUVmw5TFYyWlllZmJzUE9YS0E3LytnK0xjUy9tTElMZmVs?= =?utf-8?B?Z3pNKytFTW1jRE5JTC84M2lkRXNrQ1lsNXJIVUlCb3UxWndRRmFZMTArMUNZ?= =?utf-8?B?UzlRUS9ESnozUnpwd3JuUkQwNkhGUWVHM0RIYWxYNE1QRkhBQVFwTHk0c01t?= =?utf-8?B?MGNwUmlWV1FYeUxWajVZWFBPWDE4OTJkMitmRk1xd2hUYXFwUkFnYm1yb2g5?= =?utf-8?Q?3rk5qg?= 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 Jun 2025 14:01:34.6949 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 899cb75f-f14b-4b69-8455-08dda1ddfc3d 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: SA3PR12MB7999 On Mon Jun 2, 2025 at 9:48 AM CEST, Jan Beulich wrote: > On 30.05.2025 14:02, Alejandro Vallejo wrote: >> --- a/xen/arch/x86/include/asm/pci.h >> +++ b/xen/arch/x86/include/asm/pci.h >> @@ -13,6 +13,8 @@ >> || (id) =3D=3D 0x01128086 || (id) =3D=3D 0x0122= 8086 \ >> || (id) =3D=3D 0x010A8086 ) >> =20 >> +struct pci_dev; >> + >> struct arch_pci_dev { >> vmask_t used_vectors; >> /* > > Would it perhaps be better to put this ahead of xen/pci.h's #include, thu= s > helping all architectures? > > Jan You mean include asm/pci.h from xen/pci.h ? Seeing how arch_pci_dev is here= it must already be transitively included. I could replace all asm/pci.h with x= en/ pci.h instead, but this seems strictly better so you can include asm/pci.h = when that's all you need. Or did you mean something else? Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Mon Jun 02 14:06:00 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 14:06:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003441.1382993 (Exim 4.92) (envelope-from ) id 1uM5nb-0004VJ-Vs; Mon, 02 Jun 2025 14:05:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003441.1382993; Mon, 02 Jun 2025 14: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 1uM5nb-0004VC-TH; Mon, 02 Jun 2025 14:05:59 +0000 Received: by outflank-mailman (input) for mailman id 1003441; Mon, 02 Jun 2025 14:05: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 1uM5nb-0004V5-D7 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 14:05:59 +0000 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on20618.outbound.protection.outlook.com [2a01:111:f403:200a::618]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id b35a46ec-3fba-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 16:05:57 +0200 (CEST) Received: from SA1P222CA0085.NAMP222.PROD.OUTLOOK.COM (2603:10b6:806:35e::28) by CH1PR12MB9624.namprd12.prod.outlook.com (2603:10b6:610:2b3::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.27; Mon, 2 Jun 2025 14:05:52 +0000 Received: from SN1PEPF0002BA4D.namprd03.prod.outlook.com (2603:10b6:806:35e:cafe::2b) by SA1P222CA0085.outlook.office365.com (2603:10b6:806:35e::28) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.29 via Frontend Transport; Mon, 2 Jun 2025 14:05:52 +0000 Received: from SATLEXMB04.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.8792.29 via Frontend Transport; Mon, 2 Jun 2025 14:05:52 +0000 Received: from localhost (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 Jun 2025 09:05:50 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b35a46ec-3fba-11f0-b894-0df219b8e170 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=dAv4ndAwkNUQaKHDIf0oFLkoN5KOE+54FDO+JK9Hc/8+sfZd5xMGWDn73nINaeoMzx1cvRbqDlso+ELQ1l9IApvgVg+IfAP2MOeMdQLf3v51K/e5iYVeaG4xlKtsoAUCMEK+FtyVAmiAP79W+k2kXlHJRfP8AielTrRTXTpGmX6czL0xhiCtB/svHXdgTCmQbnWY8rKqzOX0yqHLML6ciTndPhBaZTpan8nwyyEWVBIEqZVwGsMKModUfar0pbPrSXb+cfaFIEGLa3V58hAQPKk2GkuFNwkp3nTribaYP2pFxwM5e2S5m6suMraeFn3KAM6VwZC1ymkEPvzt+m+3kA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=T6My3KMxVFugVEvBPx0UL+Q4+Bwlp665qYLXsuj5ZfM=; b=yUScKXCtfaRq4C9eVgClzv6ldWW7hWLxrBGkV5QJP0Kha8RW+iT0UCfPu15YpFOp0FG4U1A7Ndi4/35CG3Zs/ChBU3B5tMris+m/zAlU4kO8ycuDKHb8rI+6Y6cbU0eWlRdHfv5qXmj/uWQgxG2xEq69xoiXdA0uHjZl4tHY4J60CV1RqnE7VFTIhRe9ffIAMkK+x+XQVM4PjT+iVt6inH0mffHDUx6+5iF88mUTmheuTJBh9wyQm0F5R6nmhvXiEXliGT1rAOWDDFUEFHoXIpW1zrBMYLECxlL6offaPWPfEloKEmt+M29Xb95ahPwlhOUIaVC95wSRXHifVhkqzg== 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=T6My3KMxVFugVEvBPx0UL+Q4+Bwlp665qYLXsuj5ZfM=; b=PE+R0fhZxE83XVG78W6LEub3iKP1sfWJmz/cjZcAui/sbOeYnTZdiXOuBCSwdYnvUX87YNjsfJIGHrRzsOWB62pTEyqgkAOb6zNOUgu4fPprDHZfOvbSB2jMyuRwZwOCyPto0cMWPlYftmUbadBICSVhQPvxFBIhxA3E+egzsJE= 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 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Date: Mon, 2 Jun 2025 16:05:47 +0200 Message-ID: CC: , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , "Julien Grall" , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , "Daniel P. Smith" Subject: Re: [PATCH 04/19] xen: Add missing forward declaration to btcpupools_get_domain_pool_id From: Alejandro Vallejo To: Stefano Stabellini X-Mailer: aerc 0.20.1 References: <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-5-agarciav@amd.com> In-Reply-To: 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: SN1PEPF0002BA4D:EE_|CH1PR12MB9624:EE_ X-MS-Office365-Filtering-Correlation-Id: 7f11e099-663e-4c02-d36d-08dda1de95c0 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?Q283aCs3UmJCK1VlOGgrQzl3M2tvN0ptQVVFWWFMdnpmVFpRK1lzbWZUdi9B?= =?utf-8?B?MHJxQm1ON0RBZE1jeHp3MXNkQXlOWkpET01LbitnVTJuaXZjazRxdVRtRDBp?= =?utf-8?B?ZWc3TDJyQkI5U1RZTWdQczBpeUorVkVHRXhQaHZyYytSN1VYQjEyVWd1QVRZ?= =?utf-8?B?QkZNeG5kdGlSbzZkSURMTGQ4ZkxDRnRELzhabkFiNUUvcTE5K252bHNCeFhn?= =?utf-8?B?ZllSOEpvemRsRXZFbVhhZEJFSVVKa0czYzQ1SmRUNi8wTXRpeW1nQThsa0Rv?= =?utf-8?B?TUxWUGN0L2FuV25OdlF1dXo5bjl0c1JFM1hGU1BlM3dkeXE1eEFLWlpDMnJj?= =?utf-8?B?Wmd6VVNjWTFrZDE4dUo1WmFZRWR5NkQvUnMrc3FzeG8rZHArMDUvdXZFeXhV?= =?utf-8?B?TUVSby9XbmwrNXdkK082V2w5NFU1VHpMWHc3ZnNhaURGb1N1d2JvQjhFRG5y?= =?utf-8?B?OUtJNGtITmQ3U014YXYvcDc5bWxMdTRad2Zha3ZENWFzL1o4S0xON3EwZ2tZ?= =?utf-8?B?dnBUdjFvbXBMV0xPZTJkUUxWSUs5dERsRHdTTG1lWjE0M04vVjE4TFd5Rms4?= =?utf-8?B?b0d4dU9ySFlpaDF1OXgvK3dTWDlKejl5MUFEMlFPL1kyclNqZHpqVDBzR2l0?= =?utf-8?B?aVZoRzhxSEp1VXA0RWZCWndDenlVVjBKRmFxMTVhWXZ1ZjR5aWpZUnZpcFR2?= =?utf-8?B?UVc2bFhuamdlSzdGbHlUVmptMlZyNmFyRUtXQWFkTzNodlJYejcrclhIcHJh?= =?utf-8?B?QTJ0d01jYi9vT2NET25OMUZ4dlM2eTlnZFRDSDhvU1JCck1wT3M2ektYelpN?= =?utf-8?B?TVpnNlNsaFJKa09zT0EvNDBjOEd0U3BxcHd4ak5XV1JhRVVIdUYxamdEVHZM?= =?utf-8?B?WlNPaEN4cUZteEtRcG1UU1BiSnV1YWFnWkZjRmZXRTJCTm1lMmhMRFQxeXds?= =?utf-8?B?NVRmNlVPc3VWL3NSSUgyNjZmT3gvajNkd2tYRHdiaGZlSTlPY3hsazQ2WnNk?= =?utf-8?B?Ky9WNmVTdzFNVGV4S043SXdocWt3c2R1UHljSmpORnZ2aDEwaGRoWTJqeFJN?= =?utf-8?B?U3ZCV3psUDRzUjcrSzFCd1ZiS3h4ZWNrZ0ZmaVFNd0FEWFg0cE12bk5qRlRJ?= =?utf-8?B?UUkvSTZ2em9SdjNNTFVUUEI4R2FWZXdqSGtxTUwrOE9ubnVpcjIvWk5DMUhl?= =?utf-8?B?elpkbi9jTEtFanNUQUFrZ2o5ekVkT21HN3NpQkVJOTZRY3haNkVJT0s1cEFt?= =?utf-8?B?ZEJNTFNna2kvbkxqaGpRSS94anBtQk9hQTQxZWRwRUU3cmdLN1ViZytMRTVy?= =?utf-8?B?eW9MVUl1VlFHVDdhRGRUaFBuRjdPRGdTTzRxa0xQbW42YUxPUkYxVVAvNVkx?= =?utf-8?B?VE9aK1RkNis0VVNZbGZycldZOCtwV2Z6ai9RK2w4dW53ZHBBVmxSMk84Q0ZZ?= =?utf-8?B?a01oSjBZUzN6Z1k2U2xYdldDN2Uydm9HVWEvL3hkc21OVHN2QlRCZnRMa2hC?= =?utf-8?B?bVlxNWwzQ1JqeFZ4R0VPWWF3SEtYUnFmeUhKQTM4Tko3MlV1TUYxMVNzTE9n?= =?utf-8?B?dmJLU2wzR1hzTVlyMm90L1lQcHN3SlJGTFNlZXlXYlF2UVZabTY2L1lQU0lh?= =?utf-8?B?c09nOEwvVGdmZGNPV1I5MENxWWVwQ0E3MzArSkFKeVJiZzNpWllpbXJJazZ1?= =?utf-8?B?Ym1qNjlCL2dUa0FHRFZwYlNrSW03N3ZpU211VUtQaWg2cnhtWXVaM3ZMRURv?= =?utf-8?B?RTUvY1FqdzhSTmo4THFYZyswM2I1ZFRScHBBZm9wOGZnamp5YWM3WTN3VEJy?= =?utf-8?B?aDBYcEJRQXdyT1M3cDBNaFJWVkQ1dVVyZGEzc0ZOVFU1MEoyYW9zdFBoZDFY?= =?utf-8?B?azgwQWREbkJyWFNmTjA4UmJTN0V0MVBLT0J4QXF4d1pGNVRlenR4bjk3eVF1?= =?utf-8?B?N2xPRUN5aXYxMlpCWmtXSEtHNnJQdHVnM1ZXTkROaXQ3Wnpua1Q0TzgwM3N1?= =?utf-8?B?aElzenB2emlIU0NPdWo1aVhkWlo0L0h0Zk9zVkQwRmZzTEYzQnFzN2VWcTBy?= =?utf-8?Q?JKAh5A?= 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: 02 Jun 2025 14:05:52.3080 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7f11e099-663e-4c02-d36d-08dda1de95c0 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: SN1PEPF0002BA4D.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH1PR12MB9624 On Sat May 31, 2025 at 2:46 AM CEST, Stefano Stabellini wrote: > On Fri, 30 May 2025, Alejandro Vallejo wrote: >> And remove the ifdef guard, as it's inconsequential. >>=20 >> Signed-off-by: Alejandro Vallejo >> --- >> xen/include/xen/sched.h | 8 ++++---- >> 1 file changed, 4 insertions(+), 4 deletions(-) >>=20 >> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h >> index 559d201e0c..b5a6a22c7f 100644 >> --- a/xen/include/xen/sched.h >> +++ b/xen/include/xen/sched.h >> @@ -1291,15 +1291,15 @@ static inline unsigned int btcpupools_get_cpupoo= l_id(unsigned int cpu) >> { >> return 0; >> } >> -#ifdef CONFIG_HAS_DEVICE_TREE >> + >> +struct dt_device_node; >> + >> static inline int >> btcpupools_get_domain_pool_id(const struct dt_device_node *node) >> { >> return 0; >> } >> -#endif >> - >> -#endif >> +#endif /* !CONFIG_BOOT_TIME_CPUPOOLS */ > > Usually the commend would just be /* CONFIG_BOOT_TIME_CPUPOOLS */ > without the ! True, my bad. I think I've seen both styles around (e.g: arm/include/asm/pc= i.h), but it's true this one is more prevalent. > > Other than that: > > Reviewed-by: Stefano Stabellini Thanks! Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Mon Jun 02 14:08:27 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 14:08:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003449.1383004 (Exim 4.92) (envelope-from ) id 1uM5pv-00051Y-BQ; Mon, 02 Jun 2025 14:08:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003449.1383004; Mon, 02 Jun 2025 14:08:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uM5pv-00051R-8K; Mon, 02 Jun 2025 14:08:23 +0000 Received: by outflank-mailman (input) for mailman id 1003449; Mon, 02 Jun 2025 14:08: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 1uM5pu-00051L-Cm for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 14:08:22 +0000 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on20622.outbound.protection.outlook.com [2a01:111:f403:2414::622]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 09b77f43-3fbb-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 16:08:21 +0200 (CEST) Received: from PH0PR07CA0104.namprd07.prod.outlook.com (2603:10b6:510:4::19) by SJ1PR12MB6266.namprd12.prod.outlook.com (2603:10b6:a03:457::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.30; Mon, 2 Jun 2025 14:08:16 +0000 Received: from CY4PEPF0000E9D8.namprd05.prod.outlook.com (2603:10b6:510:4:cafe::59) by PH0PR07CA0104.outlook.office365.com (2603:10b6:510:4::19) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.19 via Frontend Transport; Mon, 2 Jun 2025 14:08:15 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by CY4PEPF0000E9D8.mail.protection.outlook.com (10.167.241.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8792.29 via Frontend Transport; Mon, 2 Jun 2025 14:08:03 +0000 Received: from localhost (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 Jun 2025 09:07:46 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 09b77f43-3fbb-11f0-a300-13f23c93f187 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Y7d5grMKwYOQfwC9YS4Wqr+19iwlgYbkjPypw0o6TQFnFWmunL5GHCSqrz2VnJEf9k4fE8exmQGle32Dk52m5K0eO64HXxPMamcRsRPSdUV2cLi5bPivv2X7EDwiA1wn4aZqEM3Pb+430ZLYu/fWnEGOn9ABBIRLy2h2VaPZ8+zHU/OpXFmHsiFNWpCXL3elZ1I7lYAgMWAsp60YJg/KR+Nf4efxZkcBYnFkNkIWOCBml8yQxyOUf4YfjoGpSwOccbv82OY/5ztZ+2P/uhFcRc+drbCmAoJ95msyPojGNLDGdqquaTPnRnKi7c1hctnds2Z2xCV/xRXTpLJ0rVvZ8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=VRduVKyxGWOIw04J5RNaOAAl08qw4iMH6VZDnrnwcVg=; b=d6ODP1Fs1npgbd3yAUFgezsnDD0KrY6aQlbXpH9a40bx110sfSdVtDoOyyHYSAXkN6jXnaQ7L/JfmjCZU+1ClR9WqJMNHVcDWiJ+x6vDy1OTeIC6xnl0/JCrT3fchBdtXLMc9w5rC1CiWBCyH/C/8ICD7uYh+RCxBXEHtDCUAKw9hyu3alj8oyVC2X24zB8XLVtwyrQxPAcWK8pry66vMIf/TjSOaljMz5afHAmFkKtQlxnNhioIkiIag7R0TS8vJCgYggjmElczrR0HvYOhzkVCPfjViooTCsxiyvWsXqs8tkA3a9zKztw+BFFL4GTO1MCL2mI1SkIiWODSRRsBhw== 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=VRduVKyxGWOIw04J5RNaOAAl08qw4iMH6VZDnrnwcVg=; b=gmIdtig5aDMHoDMr3HhxDVbwACWLba+pttKY9zGFOO3OQ40qpv2yuNIdZvGlxtaGi/F03wMDevX7DAvi1RDG0Fhj0et2oVk2jM1tAxhvXk0FZ9ZvR6QM1/GGj+cm+Pgm6u+TBnHGtcDpxHh31hZU//GBMrOdNyWYGg44o+zl9Qs= 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 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Date: Mon, 2 Jun 2025 16:07:45 +0200 Message-ID: CC: , Julien Grall , "Bertrand Marquis" , Michal Orzel , Volodymyr Babchuk , "Daniel P. Smith" Subject: Re: [PATCH 05/19] arm: Remove dependencies with membank(s) definitions from setup.h From: Alejandro Vallejo To: Stefano Stabellini X-Mailer: aerc 0.20.1 References: <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-6-agarciav@amd.com> In-Reply-To: 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: CY4PEPF0000E9D8:EE_|SJ1PR12MB6266:EE_ X-MS-Office365-Filtering-Correlation-Id: 4777a4fe-5bd6-481e-6b37-08dda1deeafa X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|376014|36860700013; X-Microsoft-Antispam-Message-Info: =?utf-8?B?ZXNuWXp5b1pEc1pDMUVPTEVXa3YvY3JzaWpacGM2RHRYTlg5V0VaWE5hSHpB?= =?utf-8?B?QVFYWWZVbUZmeGRucXEwMEJkY2tldDZRb0RHWUZDdC9ld3NBL2g5TktOTU9H?= =?utf-8?B?WDhLZDVGbTFobUE5bWRyVHp1aTVidkRGamYxenlPTU1NV0w2TlQ5L3NTaXI4?= =?utf-8?B?a01KVWhuWDMwZXZGd0lTOTBNbzdUVnBWb0tuWkdJd2RuRm5yMFdjbVFTSVhm?= =?utf-8?B?aEY0R3U3Q01BVnNYc0thM0JwSmhKVFJUZzFxV3lpVTRJRk8rYzZDS2RHdTEr?= =?utf-8?B?WVNzYUZjWXRkZ05RQlI2ZGJleGo2Yk9sdzVoOFNmbHVMQzNjeGNvNUJuVGhV?= =?utf-8?B?cHIxOHJzUFRvLzB1d09ndWlsN1hTSXBpd0tFWWJXUDlGdE5OZFpkOHRZUVp1?= =?utf-8?B?TFJGaTJod2JadldrTDBwV2IyZmVIcHdwQTFpRDQzdVZrbjl2UG90dnpjSmxC?= =?utf-8?B?RkRBOU9NM09od01ESnlxNkJJOTNudzM2T3RnZ2F2aHhTZ0FvUk9LM1dYdUl4?= =?utf-8?B?RHVPYiszWEZrOVVJTlhEdEZrTmI0dXZORi9CSjRrbWdienZJU1BJWWZQL2FW?= =?utf-8?B?bXlHdVNNK21NYkFydTlBdW1PcWFtb0VyTU1OaEY1T2ZDb1ZqYjZaNHBlUU10?= =?utf-8?B?dEJOVG9hc2FEN0R1c3QrVjlrcmZ4cTRIY3duMVBVUVE1L1pocG9WVmZ1cnFR?= =?utf-8?B?Sm5GSVdhVkRBTXh0TGVRa0dvbis3aGVVejZJbXJaM0grY2pEajYrejY5Y2ZB?= =?utf-8?B?QTBsMTFSZy9RQXMzdi9hbkhJTm4wVjZMWTIzc1h4L1ZYNklMcnJyd0F5czlx?= =?utf-8?B?MWlUS1J1ZXlEV1JVTVVwUUlOYUxPRTRHZ0x3OXYrOGpMN0VZdUJxZDhjaFR6?= =?utf-8?B?cGpPSzFaZUdLS0tvNG5uTnNwT3NHUTRxMTVTTEdOSWIyUnRHQ2VoZFBUbk9F?= =?utf-8?B?SlpodE1MNjhBUlVHaDRrYStUN2RveXlyaUllUlpVdmdtU2JRL29kR0ZZcTE1?= =?utf-8?B?V3dhZ2lvKzhZSzJ4cmtDaytZWlVCQ2Z2cVZCV2d3bmhQN0VVdGlvUUsxRlh1?= =?utf-8?B?QUw1Qnp2eGdtNnBlZU5OM2NCUS9YNjBndXppcGZRTUVFTFMrZFd3amdMcmNU?= =?utf-8?B?Wnk3ak9oeHBzYkNRcDU3dFIwc205TFhpUUZNREZHbnBlRTFzUUhFSjhPMTZa?= =?utf-8?B?K0l4K1lZblVha0lqSnRGb3RWcFlSOE1uNWRJTzM3a05QNkVyMXV3Z0xqbDdJ?= =?utf-8?B?UHhEZktndU9Dc1NFc002QVJPNGVLTER2QjRHY1hGQ0IxNXVOdkJLdFBTNFB2?= =?utf-8?B?cW9HUlQ3UlIwQUIvd1BTL2VmSlpqQXcyMUw4U0FsRzVZdE5UcGo1SlUwT01M?= =?utf-8?B?NmtyWDJhMmpmc0hVekpWa1AvUjZPQkRTOHI4alNLWTF6SVJoWHRuVlVvZlZK?= =?utf-8?B?RU9ZOVVjNmhWSlZldTN1T0EwYmpnNkhTTWtmQUJzYkJ5ZzlSaTJDVFo0OFdu?= =?utf-8?B?Vlhjak0yeGkzOUloZE93RzM0ZlFOZ2xkcmpoOHdzajNnNjRaVjFwSXlpQ1A2?= =?utf-8?B?OTcvcnc4K1NtT3Y2dUdnS0JUblkyMHQrY0MvbU9kSUUrWnMzaytoa0phUGYz?= =?utf-8?B?azFFcVVxSSs0QW1aZUViMmxBTk0vWjVJdHNPU0pLS2thRHBjeVIyT1Qyc2FF?= =?utf-8?B?UThFT1BRR3hqWGlxSmVGdFREbkdacHNyc2RZMXJBbVRDMHBIQ0tYVG12WTBv?= =?utf-8?B?RnJxQlhyUUlIcmplbkdmdTRmaUJzVmxNOFN4dGlXOGZibEZXTjFDMHY0blZm?= =?utf-8?B?QXY0UU05OEFtbTByWlpxc3hBelB3aEZ3K1d2WDF2by9NcnZrT1p3V20zUU5P?= =?utf-8?B?bkNUS3ZIVWw0RUxUS09LeXFWU1E4anVWVWd1eThlZ0MvRklWQlVOdFVDcGZ0?= =?utf-8?B?U29jRExnTS9MbWtHbU1XOFZiNG5waEtTdTdiTytxT1JkSEhRVFZiSmkzNldm?= =?utf-8?B?bkpSbEE5aXdDRXJPdkIrcWR0clEzV04xWHEzZW1aR3phTCtYa0kzQmdCNXRC?= =?utf-8?Q?aU3/Kd?= 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);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jun 2025 14:08:03.9011 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4777a4fe-5bd6-481e-6b37-08dda1deeafa 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: CY4PEPF0000E9D8.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ1PR12MB6266 On Sat May 31, 2025 at 2:51 AM CEST, Stefano Stabellini wrote: > On Fri, 30 May 2025, Alejandro Vallejo wrote: >> ... as they can be forward-declared changing arrays for pointers in the = function >> declarations. >>=20 >> No functional change. >>=20 >> Signed-off-by: Alejandro Vallejo >> --- >> xen/arch/arm/include/asm/setup.h | 10 ++++++---- >> 1 file changed, 6 insertions(+), 4 deletions(-) >>=20 >> diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm= /setup.h >> index 6cf272c160..0f9e531a34 100644 >> --- a/xen/arch/arm/include/asm/setup.h >> +++ b/xen/arch/arm/include/asm/setup.h >> @@ -3,7 +3,6 @@ >> =20 >> #include >> #include >> -#include >> #include > > This change breaks the build on ARM: > > CC xsm/xsm_policy.o > xsm/xsm_policy.c: In function =E2=80=98xsm_dt_policy_init=E2=80=99: > xsm/xsm_policy.c:71:30: error: implicit declaration of function =E2=80=98= boot_module_find_by_kind=E2=80=99 [-Werror=3Dimplicit-function-declaration] > 71 | struct bootmodule *mod =3D boot_module_find_by_kind(BOOTMOD_X= SM); > | ^~~~~~~~~~~~~~~~~~~~~~~~ > xsm/xsm_policy.c:71:30: error: nested extern declaration of =E2=80=98boot= _module_find_by_kind=E2=80=99 [-Werror=3Dnested-externs] > xsm/xsm_policy.c:71:55: error: =E2=80=98BOOTMOD_XSM=E2=80=99 undeclared (= first use in this function) > 71 | struct bootmodule *mod =3D boot_module_find_by_kind(BOOTMOD_X= SM); > | ^~~~~~~~~~~ > xsm/xsm_policy.c:71:55: note: each undeclared identifier is reported only= once for each function it appears in > xsm/xsm_policy.c:74:22: error: dereferencing pointer to incomplete type = =E2=80=98struct bootmodule=E2=80=99 > 74 | if ( !mod || !mod->size ) > | ^~ > cc1: all warnings being treated as errors > make[2]: *** [Rules.mk:249: xsm/xsm_policy.o] Error 1 > make[1]: *** [build.mk:72: xsm] Error 2 > make: *** [Makefile:619: xen] Error 2 > > The rest looks OK Ugh. The series passed regular CI, but it must not have had XSM compiled-in= . I'll sort that out and re-send. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Mon Jun 02 14:12:50 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 14:12:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003460.1383014 (Exim 4.92) (envelope-from ) id 1uM5uC-00076y-Vm; Mon, 02 Jun 2025 14:12:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003460.1383014; Mon, 02 Jun 2025 14:12: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 1uM5uC-00076r-S9; Mon, 02 Jun 2025 14:12:48 +0000 Received: by outflank-mailman (input) for mailman id 1003460; Mon, 02 Jun 2025 14:12: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 1uM5uB-00076g-OF for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 14:12:47 +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 a8567cbc-3fbb-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 16:12:46 +0200 (CEST) Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-450caff6336so26079545e9.3 for ; Mon, 02 Jun 2025 07:12:46 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-23506d14ca5sm71123705ad.242.2025.06.02.07.12.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 07:12:45 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a8567cbc-3fbb-11f0-a300-13f23c93f187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1748873566; x=1749478366; 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=4eeQLARWxeYLzy5WyPLj5L3+9dsulMwlYB+Z9BmlGMs=; b=TwqzU+WUKxQ0G6MgIr/2whdjwYxdtRlMXFsBG0yTo7mfcHJ47tWsjTLUaGa1hU1G4l xQ3v9I1JcjAOJ6OfwMZjejiaOZ6hvRYgWwxmxukgP3AU2TxN15+vlgtYlsZoeDK9C6HZ wz2Ydvq9fUCwFzG4RNnhj2VOgmOYFe1uYIZru+9Cp86hqdt2a3nSjWVt5sW+wyvXaWVG qbWpAWV2Q/5EJs21c/jtW57iNOnxcwtjgEFLLHg9++bW0sWHySryta0atXKI3Yhls1q0 IOhVVjPS/w737YQtHdctsM8NROJ/OgeT5x8aUsH3tW3Uk1kzrFairLZBXXY6s/CEv/4t Rfww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748873566; x=1749478366; 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=4eeQLARWxeYLzy5WyPLj5L3+9dsulMwlYB+Z9BmlGMs=; b=e4zPcbTYtFOG7TUkcjYihkUQULW5U6ip/yUK0NW9rReau3X01wB3otmDBOQYTJQ/Iv 9eW9EbYBEMaFCPzkxpyX65h8g459Yi13vlYt6aqekXVBsekrst38vKiCSB8x7qYC4LWp MGpCqdaRRx28fEy6SwILd1kZFLowa3+zcMZkOSLkM7sQDefXjFd4kjbpI5dxRptF2UcM aYXa5j3q3LzLV2pRR7uLvmZ6s7Jk/XJM3CXhtCHhSWOJz33UyUAZpxYhPG6LlX1RQmgC sjeci+kE04Iq+X5yzux4CQ+kLd14Hq2QB9N1325a4+Hw7GYg4oCVzcXuhLkk+yYAP9AO TYUw== X-Gm-Message-State: AOJu0YwENFvFOZZesZpCcYIdancardaC/QyGJN3uftjDQRO/SQzoNIub vTY14B/wMvP/fuqZ47AVgaZSLU4pysMWWLkXO0pl/n2WhsaPpd9entxA2aI/JSv46g== X-Gm-Gg: ASbGncsE0vdg3H5F+eBJerX09lfdoenF0RZNw+MGYEa775BtVepHU1GUnvlO/CUPkSx Z4VQmU7j1LNYYUEpJd4pN0OaimIlctFvWdYKVu2SLhe7WS8G1mj5SCxXpOtXjsvz/LJSbvw7KSz fLQ9yD/WWgsGU1Q0jDaQ3vfN6p3UC/JVLT9RD74ej0SOuiy1JtWzPItq7I89m5T0hnSwFVoxOLI 8xD1RsAr/9TFQZ96PBwg7LTlFHaQI8TSqPxtgMsTtzWVkIz6JFjrDLY97nrJR7vgm8CoiaAKC5h wbUl12EYYHMKjx1OJekoxXvi58ak/+9jvzzgMim3hO+dqnUdQbMgOARU2iXLK3RqehF+pjPt+YM vnRgtuHEn6QsD87CzljYRhe4HE3V0sqpgOfFM X-Google-Smtp-Source: AGHT+IEcxG4to/eMfwQM4ClD9gY+6KCLVgw7JmWvADhDrXWMBFRmX5Y8VhhgPB7SvGvT9m9ftWb5oQ== X-Received: by 2002:a05:6000:288b:b0:3a4:e5bc:9892 with SMTP id ffacd0b85a97d-3a4f89a892bmr9892282f8f.21.1748873565837; Mon, 02 Jun 2025 07:12:45 -0700 (PDT) Message-ID: <21dcca4d-1c51-42f1-b73b-65702451de13@suse.com> Date: Mon, 2 Jun 2025 16:12:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Nullptr dereference in nested VMX when shadow VMCS support is available To: Manuel Andreas References: <5f258e25-a4ed-4f9a-8ca6-9ea3400e2369@tum.de> <6d28eb0c-caed-4c58-a6ac-cbf8da357d22@tum.de> 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: <6d28eb0c-caed-4c58-a6ac-cbf8da357d22@tum.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 02.06.2025 15:39, Manuel Andreas wrote: > I've discovered an issue in the nested VMX implementation, where an > unprivileged domain is able to force Xen to dereference a NULL pointer, > resulting in a panic. Sadly you provide no details on this NULL deref. > This is possible when: > > 1. The malicious domain has nested HVM capabilities. > 2. The CPU is running on top of VMX and supports shadow VMCS. > > To trigger the bug, the domain must first enable VMX operation for > itself, execute VMXON and then finally execute VMPTRLD on a guest > physical address that is backed by a non-writable p2m mapping. > In `nvmx_handle_vmptrld`, after attempting to map the nested VMCS, Xen > will check whether or not this mapping is suitable for writing and if > not immediately unmap the nested VMCS again and abort the setup of > `nvcpu->nv_vvmcx`. However, Xen at this point erroneously continues > emulation of the VMPTRLD. In particular, if VMCS shadowing is available, > Xen will nonetheless attempt to link up the nested VMCS to its own VMCS > in `nvmx_set_vmcs_pointer`. Importantly, Xen here attempts to > dereference the presumably mapped nested VMCS (which now is merely a > NULL pointer) in order to mark it as a shadow VMCS by applying the > `VMCS_RID_TYPE_MASK` to its revision identifier. Following, the page > fault handler will panic Xen. > > I've attached an XTF reproducer that triggers the bug. To setup such a > non-writable p2m mapping for the malicious VMCS, I first setup an > appropriate grant table entry. I've tested it on Xen version 4.20.0. I expect this to not work anymore on current staging or 4.20.1-pre. See a8325f981ce4 ("x86/P2M: synchronize fast and slow paths of p2m_get_page_from_gfn()"). > To fix the issue I believe the following patch should be suitable: > > --- a/xen/arch/x86/hvm/vmx/vvmx.c > +++ b/xen/arch/x86/hvm/vmx/vvmx.c > @@ -1817,7 +1817,9 @@ static int nvmx_handle_vmptrld(struct > cpu_user_regs *regs) >              else >              { >                  hvm_unmap_guest_frame(vvmcx, 1); > -                vvmcx = NULL; > +                vmfail(regs, VMX_INSN_VMPTRLD_INVALID_PHYADDR); > + > +                return X86EMUL_OKAY; >              } >          } >          else > > The VMX error AFAICT does not strictly adhere to the Intel SDM, but > providing the guest some indication on what went wrong is likely more > sensible than silently failing. Giving the guest some indication is certainly right. If we want to follow the above route, I think the change would want doing a little differently, to take the path that presently is the "else" at the bottom of the hunk above. However, I can't presently see how invoking vmfail() would make a difference as to the subsequent NULL deref: The guest could continue the same irrespective of the failure. Hence why I'd like to understand what NULL deref you did observe. (We may hence need two patches - one along the above lines, and another one dealing with the NULL issue.) Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 02 14:16:54 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 14:16:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003468.1383024 (Exim 4.92) (envelope-from ) id 1uM5y6-0007gF-FD; Mon, 02 Jun 2025 14:16:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003468.1383024; Mon, 02 Jun 2025 14:16: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 1uM5y6-0007g8-C2; Mon, 02 Jun 2025 14:16:50 +0000 Received: by outflank-mailman (input) for mailman id 1003468; Mon, 02 Jun 2025 14:16: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 1uM5y4-0007fx-7d for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 14:16:48 +0000 Received: from fout-b4-smtp.messagingengine.com (fout-b4-smtp.messagingengine.com [202.12.124.147]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 36e84047-3fbc-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 16:16:46 +0200 (CEST) Received: from phl-compute-05.internal (phl-compute-05.phl.internal [10.202.2.45]) by mailfout.stl.internal (Postfix) with ESMTP id EB68A1140186; Mon, 2 Jun 2025 10:16:44 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-05.internal (MEProxy); Mon, 02 Jun 2025 10:16:45 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 2 Jun 2025 10:16:43 -0400 (EDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 36e84047-3fbc-11f0-a300-13f23c93f187 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=1748873804; x=1748960204; bh=U5vh15ldnIwmnsvpqOh3R+awUXBVNiNBWbzkpE2jouw=; b= Z3m30inwAaRtiE7NTo8ykJpb9b8CJpsErlPh+Faad0q0sJtkukEShpbfzno4foMG EBi962+JBItjGsVevQS5jHmDeG97QVHn5aFV+CqyY414OoJezFbUbqK1i3sv5r8r CGRFe3nVOOhPDh3jH7csFVSbDsYcxfJEvF/8ui548ok5VHHlhE0+HwnFpo0abFHC suwB6gHeuXnduNkXl/YqBO7yRb03RiDrBA3ufq9IaOwRZsg7Ur56oh+TQE+IJfs1 KpEsitLU6G6e1UBtujJDOCCOaz4SsQV2dMIf+IDVuZs0KKCxMJoTCHehHzobaMuF tLtCFaOOGNryX3nSOLP6cw== 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= 1748873804; x=1748960204; bh=U5vh15ldnIwmnsvpqOh3R+awUXBVNiNBWbz kpE2jouw=; b=aiA+P9SSM+G/8iS0rHdQtMgoaOgWld1+ZfDGJk4M2ulKqqMxiRI msuI0J6zVkwAMOF1LRMulgPIcX+wt8QHgM+Ow4Ht2HHerixwxcVWtrslOf7//T1m clh0JdMFADjkHSKwvPvns9+wKktPeuGWV3lDG2YWediqLiKXqCqVCTdryOvaVGQ0 3m+xng/K5yFyXT+f+fBkXphRPIaFgpqJK0h+bee8ck5wRdBaAhc0t31tyQ33XlCg 5Fs4AEU+ti6jarru5POVZD9hq9ynOF+gp0DG5295MlUt9F0BbEVxGdnSwXgDxish RWwCGuv6wg3prWCP86tTYXJffn4juf+x10A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgdefjeekleculddtuddrgeefvddrtd dtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggft fghnshhusghstghrihgsvgdpuffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftd dtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfhf gggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghkucforghrtgiihihkohifsh hkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhg shhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefgudelteefvefhfeehieetleeihf ejhfeludevteetkeevtedtvdegueetfeejudenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthh hinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopeefpdhmohguvgepshhmthhpohhu thdprhgtphhtthhopehkvghvihhnrdhlrghmphhishestghlohhuugdrtghomhdprhgtph htthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdp rhgtphhtthhopehrohhsshdrlhgrghgvrhifrghllhestghithhrihigrdgtohhm X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Mon, 2 Jun 2025 16:16:41 +0200 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Kevin Lampis Cc: xen-devel@lists.xenproject.org, Ross Lagerwall Subject: Re: [PATCH v2 3/3] Disallow most command-line options when lockdown mode is enabled Message-ID: References: <20250602134656.3836280-1-kevin.lampis@cloud.com> <20250602134656.3836280-4-kevin.lampis@cloud.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jkJSLdWIIrLJxY8S" Content-Disposition: inline In-Reply-To: <20250602134656.3836280-4-kevin.lampis@cloud.com> --jkJSLdWIIrLJxY8S Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Jun 2025 16:16:41 +0200 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Kevin Lampis Cc: xen-devel@lists.xenproject.org, Ross Lagerwall Subject: Re: [PATCH v2 3/3] Disallow most command-line options when lockdown mode is enabled On Mon, Jun 02, 2025 at 02:46:56PM +0100, Kevin Lampis wrote: > A subset of command-line parameters that are specifically safe to use when > lockdown mode is enabled are annotated as such. >=20 > These are commonly used parameters which have been audited to ensure they > cannot be used to undermine the integrity of the system when booted in > Secure Boot mode. >=20 > Signed-off-by: Kevin Lampis > Signed-off-by: Ross Lagerwall > --- > Changes in v2: > - Add more information about the safe parameters > - Add lockdown section to the command line doc > --- > docs/misc/xen-command-line.pandoc | 16 +++++++++ > xen/arch/arm/domain_build.c | 4 +-- > xen/arch/x86/acpi/cpu_idle.c | 2 +- > xen/arch/x86/cpu/amd.c | 2 +- > xen/arch/x86/cpu/mcheck/mce.c | 2 +- > xen/arch/x86/cpu/microcode/core.c | 2 +- > xen/arch/x86/dom0_build.c | 4 +-- > xen/arch/x86/hvm/hvm.c | 2 +- > xen/arch/x86/irq.c | 2 +- > xen/arch/x86/nmi.c | 2 +- > xen/arch/x86/setup.c | 2 +- > xen/arch/x86/traps.c | 2 +- > xen/arch/x86/x86_64/mmconfig-shared.c | 2 +- > xen/common/domain.c | 2 +- > xen/common/kernel.c | 10 +++++- > xen/common/kexec.c | 2 +- > xen/common/lockdown.c | 2 +- > xen/common/numa.c | 2 +- > xen/common/page_alloc.c | 2 +- > xen/common/shutdown.c | 2 +- > xen/drivers/char/console.c | 2 +- > xen/drivers/char/ns16550.c | 4 +-- > xen/drivers/video/vga.c | 2 +- > xen/include/xen/param.h | 49 +++++++++++++++++++++------ > 24 files changed, 87 insertions(+), 36 deletions(-) >=20 > diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-li= ne.pandoc > index b0eadd2c5d..7916875f22 100644 > --- a/docs/misc/xen-command-line.pandoc > +++ b/docs/misc/xen-command-line.pandoc > @@ -1798,6 +1798,22 @@ immediately. Specifying `0` will disable all testi= ng of illegal lock nesting. > =20 > This option is available for hypervisors built with CONFIG_DEBUG_LOCKS o= nly. > =20 > +### lockdown > +> `=3D ` > + > +> Default: `false` This belongs to the 2/3 patch, no? > + > +The intention of lockdown mode is to prevent attacks from a rogue dom0 > +userspace from compromising the system. It is also enabled automatically > +when Secure Boot is enabled and it cannot be disabled in that case. > + > +After lockdown mode is enabled some unsafe command line options will be > +ignored by Xen. > + > +If enabling lockdown mode via the command line then ensure it is positio= ned as > +the first option in the command line string otherwise Xen may process un= safe > +options before reaching the lockdown parameter. > + > ### loglvl > > `=3D [/]` where level is `none | error | wa= rning | info | debug | all` > =20 =2E.. > diff --git a/xen/common/lockdown.c b/xen/common/lockdown.c > index 84eabe9c83..cd3deeb63e 100644 > --- a/xen/common/lockdown.c > +++ b/xen/common/lockdown.c > @@ -35,7 +35,7 @@ static int __init parse_lockdown_opt(const char *s) > =20 > return 0; > } > -custom_param("lockdown", parse_lockdown_opt); > +custom_secure_param("lockdown", parse_lockdown_opt); Is that really a good idea? It means `lockdown=3Dyes lockdown=3Dno` would still disable it in the end. This may matter more if for example the `lockdown=3Dyes` part is in the built-in cmdline (possibly with other integrity protection than UEFI SB). --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --jkJSLdWIIrLJxY8S Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmg9skkACgkQ24/THMrX 1yzj4Af9Fl+Of2IAPvZbhwIDPdPJj2CRxEnnmCCBCIUHyN+BiuOR6U9Xgg4cZL25 BVQdA9QYeJgAx/cXaluTiLca061kc4cu1kaNwvLHF6nKxwevJjLEgGcb2cCkh5H5 kanrhIyIFJoqayc6JlKkrf0IOv2J1YNWhOR72/OrjIfRkw05YEubxJ9HG2L4ZjPt N8vQnoSRr4ICzcWzZXlK/GPoSPAJaMuJWq/814HGZYh8/VmyTSOohAstw+Z33+MO v2vs2NoNeeYR4d1uKaVRiTJOJ2uMYD57htiA2gZ64Jd8PkaZ4cEVYq8G/8FggR1W p7Q5Rbxx9h0Rq5EjRYwmklx2J2XJFA== =OrsQ -----END PGP SIGNATURE----- --jkJSLdWIIrLJxY8S-- From xen-devel-bounces@lists.xenproject.org Mon Jun 02 14:19:20 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 14:19:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003476.1383035 (Exim 4.92) (envelope-from ) id 1uM60U-0008C9-Rr; Mon, 02 Jun 2025 14:19:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003476.1383035; Mon, 02 Jun 2025 14:19:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uM60U-0008C2-NL; Mon, 02 Jun 2025 14:19:18 +0000 Received: by outflank-mailman (input) for mailman id 1003476; Mon, 02 Jun 2025 14:19:17 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uM60T-0008Bu-Sf for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 14:19:17 +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 90f8da46-3fbc-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 16:19:17 +0200 (CEST) Received: by mail-wr1-x435.google.com with SMTP id ffacd0b85a97d-3a36748920cso5134224f8f.2 for ; Mon, 02 Jun 2025 07:19:16 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-747affcf9ddsm7953091b3a.148.2025.06.02.07.19.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 07:19:15 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 90f8da46-3fbc-11f0-a300-13f23c93f187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1748873956; x=1749478756; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=deZYGG2U5VJ5yOWCKkeDQWSOnCfYxX4f89HMPGryjK4=; b=D4XYjuKOHNFdHG+2hLojirZeSG+bhUTJLINHQvEOQwmiKwYTvO0ilHZokX+/n9rWEq 9sR8ZCANsSMKgn0mEvs9arl50Qut7dUXJpJAE3nast+BmTDdmCLDsaALUtFtFVrmoZGP 9bkh/dq0oR0RYeIDz8mSI+XkSJyoFYW9q+xYbzBfyhqwwU+wZk1BjlGPBYvVJDtUa8K6 WDHJVVlgj+zfFF3XBtUL6PlM9R+yRVEKjJYe6XTFEfmFOtN3lCbc5H6ZkcKtIHgLyb92 8OH4g9XJvVG27G6saBhmgR7UQdJ4u7bhFYpCfeh5D41QEdUchz6GHUAZs/8aBo/9nNq9 /CxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748873956; x=1749478756; 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=deZYGG2U5VJ5yOWCKkeDQWSOnCfYxX4f89HMPGryjK4=; b=MCsalpul+AnHwor4Yt7b/gxyYQYAKWVlQwk1iYvsPKcYZv45IDK7iOICG3rM3+9cm0 5pDKqzde8kOMczPOd9XtY6xpFSUtGQwf7Fm7uPrQrEYeaEluRGa/oVzKXQRTuZ2/wLuJ ukYGCq1M+ZNFpQ9gTn3P5hb4+XbuM80E686kX+CUKfrLUmKoVF368vvLqtdqxMY/vU2t UyJ3WV1EYpX6ajUkeGP5vYBSL5w7Vs0MPivFkMHMm+t0qI28LdmQDdVzhOi1gtW2/oeG RIOC9A3OH1APJf/MXYgXbdD/jobZO5odcEq6f5OcJyn/QmKtri2dPujurBJ9u6HGa/Sk oDjQ== X-Forwarded-Encrypted: i=1; AJvYcCXy1Iqg9SZUIV0RwkUHudLnxUPmFpGUaJO/7k5B9o+TytLW2t4PgHxIilyjO58xgCnSDk0+881q/4k=@lists.xenproject.org X-Gm-Message-State: AOJu0YzDdLFz9xOlvBb18DyTMZGqcbue/EabvNbWZf6DgT+hA9ywoOIX fowC63JUQbebFqKYkggS9KaZFE+mR07Ltsg0UlgEaUa9E+tt/ur9yRPvnIXRbQwFuQ== X-Gm-Gg: ASbGncseV6xgVJtSzmmHYNqAPCunRcKFR+o8AiR3XlJhn3VzLRPH6TP6qJpoKUxqLPA byWIFEZj6VN4dCGYi5IzkqIoPkLygg0+Hbpi1Qc36Hqi5XqrZ3N0BoKn1+S4nduEQc35sX2GGMh BowjUXgbXEdNZ+ABcZaD00mhmdUb/B3gnavoTFQaskHNDVJFfFexDdGK47Yun8HSG1G9tV8AfqW COXyy6oxYz1Pg8YSE+RTiG0goVm7lsHerGmHOiSjBmRA/s4IQ+ok9ojBDqCK71nW88P3w9xsmMp 6Qul3Ul4ca42no5wtwSJXfV7kTlIGL+kEUxu0iqXeZKHL4GKhOlnsQjYGQFeEi18IzZua4sVssw mOVFK0R3nxRmX4PftS9hyICUm83h4uNWnaB1v X-Google-Smtp-Source: AGHT+IFzBnPwwWT9+jKTRkwzuZTm7jrUqTbVO6E3msnRKNbqnI3CtXn1jR97ntpjOlEZejmeHbB6gg== X-Received: by 2002:a05:6000:4023:b0:3a4:e7d3:bd9c with SMTP id ffacd0b85a97d-3a4f89a76a3mr10077900f8f.17.1748873956279; Mon, 02 Jun 2025 07:19:16 -0700 (PDT) Message-ID: <7e2f2de4-4a06-4e4a-85e8-e82dcbfa1abf@suse.com> Date: Mon, 2 Jun 2025 16:19:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 02/19] x86: Add missing pci_dev forward declaration in asm/pci.h To: Alejandro Vallejo Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "Daniel P. Smith" , xen-devel@lists.xenproject.org References: <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-3-agarciav@amd.com> <680c7ba4-e4f4-4fb9-969d-ecaa206e37c6@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.06.2025 16:01, Alejandro Vallejo wrote: > On Mon Jun 2, 2025 at 9:48 AM CEST, Jan Beulich wrote: >> On 30.05.2025 14:02, Alejandro Vallejo wrote: >>> --- a/xen/arch/x86/include/asm/pci.h >>> +++ b/xen/arch/x86/include/asm/pci.h >>> @@ -13,6 +13,8 @@ >>> || (id) == 0x01128086 || (id) == 0x01228086 \ >>> || (id) == 0x010A8086 ) >>> >>> +struct pci_dev; >>> + >>> struct arch_pci_dev { >>> vmask_t used_vectors; >>> /* >> >> Would it perhaps be better to put this ahead of xen/pci.h's #include, thus >> helping all architectures? > > You mean include asm/pci.h from xen/pci.h ? Seeing how arch_pci_dev is here it > must already be transitively included. I could replace all asm/pci.h with xen/ > pci.h instead, but this seems strictly better so you can include asm/pci.h when > that's all you need. Hmm, I didn't take into account that asm/pci.h is indeed being included all on its own in a few places. IOW your patch is fine by me as-is. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 02 14:19:43 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 14:19:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003480.1383044 (Exim 4.92) (envelope-from ) id 1uM60t-0000Bl-2I; Mon, 02 Jun 2025 14:19:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003480.1383044; Mon, 02 Jun 2025 14:19: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 1uM60s-0000Be-VW; Mon, 02 Jun 2025 14:19:42 +0000 Received: by outflank-mailman (input) for mailman id 1003480; Mon, 02 Jun 2025 14:19: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 1uM60r-0008Bu-Oo for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 14:19:41 +0000 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on20606.outbound.protection.outlook.com [2a01:111:f403:2009::606]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 9eb79e65-3fbc-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 16:19:40 +0200 (CEST) Received: from MW3PR05CA0013.namprd05.prod.outlook.com (2603:10b6:303:2b::18) by SJ2PR12MB9192.namprd12.prod.outlook.com (2603:10b6:a03:55d::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.27; Mon, 2 Jun 2025 14:19:25 +0000 Received: from SJ1PEPF000023D1.namprd02.prod.outlook.com (2603:10b6:303:2b:cafe::93) by MW3PR05CA0013.outlook.office365.com (2603:10b6:303:2b::18) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.17 via Frontend Transport; Mon, 2 Jun 2025 14:19:25 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by SJ1PEPF000023D1.mail.protection.outlook.com (10.167.244.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8792.29 via Frontend Transport; Mon, 2 Jun 2025 14:19:24 +0000 Received: from localhost (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 Jun 2025 09:19:20 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9eb79e65-3fbc-11f0-a300-13f23c93f187 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=IhYFk8h50o3yIrgIZhSP3W9+G79jEJn8igzKzRs8QvSG63AT0HILbVTvrZnVMxwqk8LhbdhPgl7XdJ1ENCVeRL/HY/41y/FGyKa5alW2NIL6/9elutiaJbJ5o5riZvJDLwRJCrrFwMsXEASDJ7RgExuLwcM+KqC7GdUGvV2F4HiUsVsviB0yV/LXZkwwSLTdsSvE5p7mLbKMltpkJSb1Xbrh9+4IrIAwt0i5K7kZumB8DfjVLqD0GXMLA6RkLfREVnbSKx/BFLGfuPhy+AH7wxThebsIPlhvByI0ISjdZwHS99OFSCQKYllWWyXJghzG3wrzLTbgOwC3lvjW4VBvHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SEfCPmWcu3ajNrJzQLhFprDXyE0OyQKnt3mZTPoj9DQ=; b=ANY4dExC44N2q4LgMa9OA1PyMYIONs+KJMKpZD6dhyTv/RmSXekVeBcG0zi9TM1sxaFrvx0JGLi95vs/btHHIQYZ/+aIDzSPK0qg9uD1qkYz0qUNBHRoGPhGBHhIqXF+F7u1HcUXtDR34EmtrvkgaHHS+mLJhMLbfcQlHlxo0AL6M+vaNDUxTCFyCK/yioHd+I85G7od8zFzrqqUM2RDSP/Oqqh8iE2ICoh5J10wTE8W97u3/3esxTWgJn5PyA9gRnw9/Il45Wyfn84Bb7tIEQfBTUHutL42BrXJW4+GLhDQfjA4DWYps+/rn6amO5drShSNneZm2TfbbsxvXhZofQ== 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=SEfCPmWcu3ajNrJzQLhFprDXyE0OyQKnt3mZTPoj9DQ=; b=I/nB26SzJAeBNKxjq+HrFrwxiXXPcBm+0HmrF865hbZt35qpsKnS+bEpkE4s2VoiH4gDsjDjJuHtX1uz8wNsB0A8Cwq1nZHxcvxtUn6SYjLUI9y8aJi0I7oM7HydwqnluMbBaStdS62iQs+K6QQKWrjDDls/IZSaJxiH5Rf75dM= 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 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Date: Mon, 2 Jun 2025 16:19:18 +0200 Message-ID: Subject: Re: [PATCH 06/19] xen: Clean up asm-generic/device.h From: Alejandro Vallejo To: Jan Beulich CC: Alistair Francis , Bob Eshleman , Connor Davis , "Oleksii Kurochko" , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , "Daniel P. Smith" , X-Mailer: aerc 0.20.1 References: <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-7-agarciav@amd.com> In-Reply-To: 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: SJ1PEPF000023D1:EE_|SJ2PR12MB9192:EE_ X-MS-Office365-Filtering-Correlation-Id: 991a7e7f-5711-4bc9-d13d-08dda1e07a2b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|82310400026|376014|1800799024|36860700013; X-Microsoft-Antispam-Message-Info: =?utf-8?B?SEF5NHNXZXZhVjVpb2x2Q0pEMnNhV1U2UkJJd0FmZGJoRmpRUU0zTUxMb1FY?= =?utf-8?B?TU01aFVkWVoxQ29rWDVORUxzQnUzVy9CUGZ5bnd4MVNrZDdBNGw2c1dHUlhl?= =?utf-8?B?bGthUnBYVklBK29jMEZkMVA4bEFRK3NzMWNlYWRxYysrK1p0VFNvK0lvUnF4?= =?utf-8?B?WXFjZHY5a2dlWkxUYTZsWE1hQXlzQTBPOXVGZFpWWXRob1pWc2pQU1lrN2Vj?= =?utf-8?B?eFIvZlQ1TkZBR09Rd3R5aFpUc0dTMy9YeTZETit3c1NyeXpwRUp3OVdNVllH?= =?utf-8?B?Y1V6eW90VUU1d1F0TkZuSGhjbTlNSlRJdkNOYktiWVExVlFidnVzVktLUUt4?= =?utf-8?B?dVNxQ0FhaXBiQlZDb0Y5SFNTdFdQMUc5K1IyZk1VUm8yQlJ4amFZOU9LYVQx?= =?utf-8?B?VkZWbitSSUNQQ01yVDFUTlVnOWtlb2NsaHN4cElxUE5qa1B2NXhpalNuOVhF?= =?utf-8?B?TkZBN2VLL0M3WWJQM1hvWnlCNktqYWN6K25zVlR0UkovbVRPZmN6U0VHdUxE?= =?utf-8?B?YnV4d3ZtMitoY1lXOFdQZExjNi9BcW1pY0o4akREKzBxY0MzeXJseXhuaFg4?= =?utf-8?B?WmttUjJHQ1phSDU3Rm11VkNrbmQvalkyNTU2bWQ3MGt4c3pzV3BnSVI0ajRF?= =?utf-8?B?dCs3c01Oay9jckRQeHRlMXM1VXViY2ZoQVlMRk51UzFYUXErRVNmSWlyazh6?= =?utf-8?B?NTR6R0hqaHo4NTI2QWwvd0xWQUJxbnJidWpGMXZTVDN1MkljMzRxbkZZN1BQ?= =?utf-8?B?QU44TW5kKzNFVXpMMUZSenB5Rlp3THlxUlUraHRjNXV3M2JKTFZjSU5JOWl3?= =?utf-8?B?V3dIZldkQk5PZWlUenBubmVyODJoR3lmcW4zZ1RYN3hwU3dHZSsvYnM4Vkx1?= =?utf-8?B?RHpkSnNsL2JyYUpWcVIycFY5dzdBaytxU0JiUHJlNkQ4UFZGaEtzT0xMK2hI?= =?utf-8?B?Zlc3MGQwS2N6L0ZHWVJJNU9EaHRBSGR2NjZWZzFzMTU4Rm9wUTl5MFVvaUNB?= =?utf-8?B?TkJLbHFkcU1BcFNLT1V5RVdaYi9HdFpOQmZ3bUtWMC9CRXpBSmRaQXo3dGlv?= =?utf-8?B?T29hUjRvalh5Q3pMc3Zud3ZlUXIrdnlQWXFwUFJhNUlwRzNtQXBpb0V0eUJS?= =?utf-8?B?YTlZTFdQQVkvQzRnNnVSM0tLTjNKYUM3a2I0NW9oMnJycXh4aGhUVUJoY3Rj?= =?utf-8?B?dERlRUNoa0JKTXFUaml6QTJGTENGM3lNMGRGbW9oYjFCbUJGOTJTR3NRQVBH?= =?utf-8?B?RCtMWENwNVlSdmZNMEczRTJORjZDNDBBUTUzUk9Vek1KT3FZVUFNMkxkaS96?= =?utf-8?B?aHF4WXhDYXlpS1p5TUwydDBjL1pIYU9LK2R3SGlvN0tGcnMwcGkyMytiZjR0?= =?utf-8?B?UEh5Ynl3L2Y0NU5Cdmh1Z3UrVWRzbHpsNm1FRlZTOHlEVWVLOUN2dDByNWhq?= =?utf-8?B?VHRHcytLcW10ZlV3Y0x4ZWxHbGRDZEplek04dVZSU29VZVY0TlZTWXdPSHN4?= =?utf-8?B?VVU0eFlwYTdYOWh5T2drL09UUlRZN3orYXBXSlNDY0dWVDQ1RHNQQVNZbVhN?= =?utf-8?B?YUlnQjZLd1BoWklXUklXZXZXMzJqQVZ0STVEQnYrVVlNNlltSjRHaXVTclQv?= =?utf-8?B?cHNtTVRYeEp5bEE5OW9PekhrWk9qOCtJaWRuVUFPL3NBZDVMY2tNNFpnUnNw?= =?utf-8?B?OUs3Y0RqMzdWOHVueENyejRhOGZ1NlNnMmszMWYrQVFyc3NvRXI3eElsRld4?= =?utf-8?B?N3hOWTFrS25mM0RrcVMxZ1lKTGNXL0F2WjBJSVZ0Y0pibUlzQlBRQ280ZjRL?= =?utf-8?B?K084R09UQkkvMzAvWG12b1ZUbXJUMnhXMjFhczU2eTZvUXNZb0J2SHFrWWNJ?= =?utf-8?B?M3k5YlNSemI1QWJCRnFON044WFZrN3UzV2c3OHNFU0ZRTVlnUjBTVlZjc2NE?= =?utf-8?B?U05RMzdHbVpCd1QxVjFYUDNvSXdkQUg4ZHZ1TjV3b2drT21Wblc2NkV3V3pS?= =?utf-8?B?K3RWS05PcWlPWmo5WHpOOG9DZlBzWVpKUWVkY0J2dXdRZFRmVXZmdGY1YUVJ?= =?utf-8?Q?Ksy27i?= 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)(82310400026)(376014)(1800799024)(36860700013);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jun 2025 14:19:24.9493 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 991a7e7f-5711-4bc9-d13d-08dda1e07a2b 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: SJ1PEPF000023D1.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB9192 On Mon Jun 2, 2025 at 9:51 AM CEST, Jan Beulich wrote: > On 30.05.2025 14:02, Alejandro Vallejo wrote: >> --- a/xen/include/asm-generic/device.h >> +++ b/xen/include/asm-generic/device.h >> @@ -6,9 +6,7 @@ >> =20 >> enum device_type >> { >> -#ifdef CONFIG_HAS_DEVICE_TREE >> DEV_DT, >> -#endif > > Why would this enumerator need exposing on a non-DT arch? In fact I would= have > hoped for ... A non-DT arch would not include this. x86 doesn't. > >> DEV_PCI > > ... this to be hidden for arch-es not supporting PCI. > > Similar concerns elsewhere in this change. > > Jan This file is exclusively used by arches supporting DT to abstract away wher= e the device came from. x86 does not use it at all, and while it wouldn't be impossible to compile-out DEV_PCI, it would needlessly pollute the codebase= with no measurable gain, because the abstractions still need to stay. This patch is merely removing ifdefs that don't amount to anything in pract= ice, and I'd rather not go further than that. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Mon Jun 02 14:20:34 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 14:20:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003491.1383054 (Exim 4.92) (envelope-from ) id 1uM61h-0001kS-FM; Mon, 02 Jun 2025 14:20:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003491.1383054; Mon, 02 Jun 2025 14: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 1uM61h-0001kL-CY; Mon, 02 Jun 2025 14:20:33 +0000 Received: by outflank-mailman (input) for mailman id 1003491; Mon, 02 Jun 2025 14:20: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 1uM61g-00008u-KC for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 14:20:32 +0000 Received: from fhigh-b3-smtp.messagingengine.com (fhigh-b3-smtp.messagingengine.com [202.12.124.154]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id bca2daae-3fbc-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 16:20:30 +0200 (CEST) Received: from phl-compute-05.internal (phl-compute-05.phl.internal [10.202.2.45]) by mailfhigh.stl.internal (Postfix) with ESMTP id B126B2540166; Mon, 2 Jun 2025 10:20:29 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-05.internal (MEProxy); Mon, 02 Jun 2025 10:20:29 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 2 Jun 2025 10:20:28 -0400 (EDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: bca2daae-3fbc-11f0-b894-0df219b8e170 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=1748874029; x=1748960429; bh=AV/igsfrrFWvo9IG6lLn9Rt0La8NTlknG/qFtz69sJY=; b= kHyTEFDTlxfk3VRrr14Z3H8wcYR38pAalGbKRI6eSXIOHxuIh1kzNL3YamEHI6al +2tx6U4YZjZyhuy8z0V11GtgusQmh39VKLjlqPZjx+ZCt3ZBLCpM0J4qi2BhfCyU gMjoRhOVNHWJHW72sOahnv8hgYFkUR97z2ZQwPPIaoZaCwtKmj7UxrJl8RK07fv5 hAIwC+yzDb1xnQ1SIYy8KSfeapJyRPLjzCU6sXSZdA239Jypn8v7IYIDBD4t83ga tqMRBwZr5U4ImYA9VmiI0nnok659XYaYGzNhmMmyIdQmVbK/aNKwPuzdfH1s42C7 ht+JhCQR/WJm5DanXgYL/w== 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= 1748874029; x=1748960429; bh=AV/igsfrrFWvo9IG6lLn9Rt0La8NTlknG/q Ftz69sJY=; b=PUvaREDggQpJbbKSgyuOjqdXHPoBzJKW+R8m22hRkGuSD9GtWT9 bXqLYL157WmQEJx+l60VCIXOD/TFXnB95qlOgDyr2CXG0V9w7jJIAdzCwkfpugdG J5kNdHejHwKW4Ul1OXDwm7GptgAiBk+Bu8Jop8jRloUKPVo7+SWK59q4ftO7wZsI MOl8H5SDmU131o9uSOQ07Ojl2S+r5abERX3Rvnl321GS/H1VnIN+8ZU0M+xZOkBu SYiUFkORMC6srkhTPI6YHjoMWNKxe93bUgtpC6FkRajmMI5Z2Lam0H+BWaeJIK6B /m1BDohqj+ILiJcgoLxeQjJawteZSOxUWaA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgdefjeeltdculddtuddrgeefvddrtd dtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggft fghnshhusghstghrihgsvgdpuffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftd dtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfhf gggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghkucforghrtgiihihkohifsh hkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhg shhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefgudelteefvefhfeehieetleeihf ejhfeludevteetkeevtedtvdegueetfeejudenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthh hinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopeefpdhmohguvgepshhmthhpohhu thdprhgtphhtthhopehkvghvihhnrdhlrghmphhishestghlohhuugdrtghomhdprhgtph htthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdp rhgtphhtthhopehrohhsshdrlhgrghgvrhifrghllhestghithhrihigrdgtohhm X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Mon, 2 Jun 2025 16:20:26 +0200 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Kevin Lampis Cc: xen-devel@lists.xenproject.org, Ross Lagerwall Subject: Re: [PATCH v2 2/3] Add lockdown mode Message-ID: References: <20250602134656.3836280-1-kevin.lampis@cloud.com> <20250602134656.3836280-3-kevin.lampis@cloud.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ws1tl/B/3EL9OFd3" Content-Disposition: inline In-Reply-To: <20250602134656.3836280-3-kevin.lampis@cloud.com> --ws1tl/B/3EL9OFd3 Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Jun 2025 16:20:26 +0200 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Kevin Lampis Cc: xen-devel@lists.xenproject.org, Ross Lagerwall Subject: Re: [PATCH v2 2/3] Add lockdown mode On Mon, Jun 02, 2025 at 02:46:55PM +0100, Kevin Lampis wrote: > From: Ross Lagerwall >=20 > The intention of lockdown mode is to prevent attacks from a rogue dom0 > userspace from compromising the system. Lockdown mode can be controlled b= y a > Kconfig option and a command-line parameter. It is also enabled automatic= ally > when Secure Boot is enabled and it cannot be disabled in that case. >=20 > If enabled from the command-line then it is required to be first in the > list otherwise Xen may process some insecure parameters before reaching > the lockdown parameter. >=20 > Signed-off-by: Ross Lagerwall > Signed-off-by: Kevin Lampis > --- > Changes in v2: > - Remove custom command line parsing > - Print warning if lockdown is not first on command line > --- =2E.. > diff --git a/xen/common/lockdown.c b/xen/common/lockdown.c > new file mode 100644 > index 0000000000..84eabe9c83 > --- /dev/null > +++ b/xen/common/lockdown.c > @@ -0,0 +1,54 @@ > +/* SPDX-License-Identifier: GPL-2.0-or-later */ > + > +#include > +#include > +#include > + > +#define FIRST_ARG_FLAG 2 > + > +static int __ro_after_init lockdown =3D IS_ENABLED(CONFIG_LOCKDOWN_DEFAU= LT); > + > +void __init lockdown_set_first_flag(void) > +{ > + lockdown |=3D FIRST_ARG_FLAG; > +} > + > +void __init lockdown_clear_first_flag(void) > +{ > + lockdown &=3D ~FIRST_ARG_FLAG; > +} > + > +static int __init parse_lockdown_opt(const char *s) > +{ > + if ( strncmp("no", s, 2) =3D=3D 0 ) This is rather inconsistent with other bool options. I think you want to use parse_bool() here. > + if ( efi_secure_boot ) > + printk("lockdown can't be disabled because Xen booted in Sec= ure Boot mode\n"); > + else > + lockdown =3D 0; > + else > + { > + if ( !(lockdown & FIRST_ARG_FLAG) ) > + printk("lockdown was not the first argument, unsafe argument= s may have been already processed\n"); > + > + lockdown =3D 1; > + } > + > + return 0; > +} > +custom_param("lockdown", parse_lockdown_opt); --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --ws1tl/B/3EL9OFd3 Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmg9syoACgkQ24/THMrX 1ywGAAgAkkdGb+Ji+h1zoL1o9UKy6Md6/Yf6cqEdulcY7MvpAwQM0tZ9p19Hlx2U w+ZD933uNMhpZYEMj/9+v6dgjnnzDKF3Aqni3j2zAG206LzNWyNj4j6SWGKK5dLD 82iQ8j+AgPQMH+Uhd7fWrn4azDs0Yn7gIoLRFXJ/6XBqEcS3DWMocM25zhkvPq8m mFJ6AfXMHCtTOaE+jbEarrms8IB9/Pd/G9uPr4rj2MPaNC52aBt91xeyIVe/vWLW Q5ln68x4/FSPEDb6ullh0m7j1evSn9ud9X678L/xEs3M0wW9+mKIK68GCOFBzN/C ptxuECA+UgAi+nKICY/Y/7gIepW27A== =DS/K -----END PGP SIGNATURE----- --ws1tl/B/3EL9OFd3-- From xen-devel-bounces@lists.xenproject.org Mon Jun 02 14:20:38 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 14:20:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003493.1383064 (Exim 4.92) (envelope-from ) id 1uM61m-00020R-MX; Mon, 02 Jun 2025 14:20:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003493.1383064; Mon, 02 Jun 2025 14:20: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 1uM61m-00020G-J6; Mon, 02 Jun 2025 14:20:38 +0000 Received: by outflank-mailman (input) for mailman id 1003493; Mon, 02 Jun 2025 14:20: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 1uM61k-00008u-Nc for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 14:20:36 +0000 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on20604.outbound.protection.outlook.com [2a01:111:f403:200a::604]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id beb9ab93-3fbc-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 16:20:34 +0200 (CEST) Received: from SJ0PR05CA0167.namprd05.prod.outlook.com (2603:10b6:a03:339::22) by PH7PR12MB6491.namprd12.prod.outlook.com (2603:10b6:510:1f4::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.37; Mon, 2 Jun 2025 14:20:30 +0000 Received: from SJ1PEPF000023CE.namprd02.prod.outlook.com (2603:10b6:a03:339:cafe::f0) by SJ0PR05CA0167.outlook.office365.com (2603:10b6:a03:339::22) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.15 via Frontend Transport; Mon, 2 Jun 2025 14:20:30 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by SJ1PEPF000023CE.mail.protection.outlook.com (10.167.244.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8792.29 via Frontend Transport; Mon, 2 Jun 2025 14:20:29 +0000 Received: from localhost (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 Jun 2025 09:20:24 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: beb9ab93-3fbc-11f0-b894-0df219b8e170 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=gac/Rm/pAz2FUvK0hP6RcX8fUUFRsd3iQIYsks0MqTJQ3NgG4y6ndpDqIqddSvtTW3Z/gN20hiIPROGFov+NQvGx+f15KWY0yT6kf2ADHrYl6A8SDOeTKJR+m1X+hfxr9zspaeOmra1kCbZRroV7mKaHXtriM+dAagrYUmj+pHznlkPv6QJ3cL+iQsvHpajqwo7nD5GSdGME1CJbi3WvR/PI302WDS3mCVNNJVpaeYxmtPmApDlg89yn7gJgED8WZMkCmhGOKhQOQNBKb07Py4WHEVqAm6YJwhpn05zWHE7SFn4iipM2EyV7RSFxaxBUqUmJPtLlgB2WhKbNtu9Srg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/M/SiW4a1t1yWHQE0fruyR4FKzJ2ExYRcXotkyi8dMc=; b=ZrZFM6yl+6kXAdVOAeJGHkC5nbJ8ElztZ5hI+lKPNybTuOv/MxKDGlAi9Rqh6fCA+6ywHH8prsS8SBDQ+5lsRe2PnWsE2ZkOLvi9Ia5uMbPBOdiQ9UOtTNooNetuIFz8hfeBp1yHaqogZhST5TAkuRtWvNoEwL70CbF29/2tt1zqEFa7k9KeHAoxEZVv00W2185hdUfLSbg5JAEGUb6/5Qw61WlJL5Fgs1FxRLuQTQooAqh1dVHfoVbLrCvRyjfxaXFNZAw06s4/TNhg+RsXnFrY/MFYcvPSYgunTX3M3q64bUJz03z3T14ktejYxUJ1nGve2rNsbdQ1T+zSDrc9mQ== 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=/M/SiW4a1t1yWHQE0fruyR4FKzJ2ExYRcXotkyi8dMc=; b=d6XqwdsnXpASmZ9FIgvZHLR2m2fohgUgfVC3qV4K++prTv2eL9kFAU4QllbSULQyjIDexsphQRxXgfYMjFScag4Zw5UhsNs2AFFyx3zs6xHowDYO15/sld4oWRPQsaPCCNLvdcSiQwkA0UE9LlFtHJS2EDgV+o6gD5Mp5zNvqjU= 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 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Date: Mon, 2 Jun 2025 16:20:17 +0200 Message-ID: To: Jason Andryuk , CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , "Daniel P. Smith" Subject: Re: [PATCH 07/19] arm/gnttab: Break cycle between asm/grant_table.h and xen/grant_table.h From: Alejandro Vallejo X-Mailer: aerc 0.20.1 References: <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-8-agarciav@amd.com> In-Reply-To: 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: SJ1PEPF000023CE:EE_|PH7PR12MB6491:EE_ X-MS-Office365-Filtering-Correlation-Id: f73868c9-3775-4e31-ff7c-08dda1e0a07e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|36860700013|1800799024|376014|7416014; X-Microsoft-Antispam-Message-Info: =?utf-8?B?WHY2Vk1VdmFnNG5jQzVXVGhSRENzcGI3cWUxdTRXVkcxMW05bXhQUmlrRlVP?= =?utf-8?B?MWN0QnhWS0hNbUdzQWpEQlhDVko5dDdNV012cjZ4WUpHUUFjc3FEVmlEV05W?= =?utf-8?B?UlVCNDNPUmIwUTU1TzhRWjR5dlllZXJWOUw4TFpLRjhUSWhmc29nZTd4Y2JH?= =?utf-8?B?cFVpUFRNb0tIY0Q2S0pwRk4xSDI2VUF6MnNNaUZJZE1BRmFJdWdLWnF5WHVP?= =?utf-8?B?M2lpREc5dUVYY25GOWpHVDI0U0g2NFBRVWx1MnNiQ0FQaCtWTHNGYU1zNG55?= =?utf-8?B?SldUVHdQZkpKNjV1Ymh1Q2pzenZjRWhram4yd3BETXFGT1ByNmJENHdsNlRS?= =?utf-8?B?Qm5tOWRtUnVoYXVVcncxamtDOTY1c2R3SHRFQTBkd2xpQUl6OGsra2NvVGUw?= =?utf-8?B?Nm9ON3BZNm84UStuV28rVlY4L3RVR1FTSDNwWnBTU2F0L2NZSkJkMEtEcXNv?= =?utf-8?B?RjZHQTVOT0JKRnoxVzFKWVBPUzM2QkE4U3dNaWNLQWlUcWZLOVpqM1hjT2NE?= =?utf-8?B?Y1d5d0h3S1hBTExHUjhZeEdyNU9UVW1xRW5EOFRLVDdNMmdHQzNHdllaQkZQ?= =?utf-8?B?WCtxNEFXTHZmM1BKT1MyWnhhQjZwY3djMitLcGpHSXk4SHNmUE5RZVIrSlNv?= =?utf-8?B?dy85VWZUeHd6cDJBK3N4SUxmUi9abFR1V3M1Vy95UldraXl6N1dPb0hxVldN?= =?utf-8?B?ekl3bURoTUxrUVgxWm82L3Vtd0lHUjM2TDZJb2ZvMTcybDNkSzFGdFNxOWdl?= =?utf-8?B?T2h5VWtQWHlKM2ZKdlQ4ZkxnVURXTjBMZkx0RW9tMklPSGVrcmdPdUl5bWNt?= =?utf-8?B?WFR6emxwVDc4cHRFcVc3SmJuYm5pSmdmb1QzdG54c2pOM1lCOVg0UEoyMk9y?= =?utf-8?B?QzZjSk92dExTbzdRVE1VY2V3OHpJQ1U5R2NKWitTQ1VqcFpyNU1XUi9YRzZX?= =?utf-8?B?ZW1KQ01YUjBJdDhPVy9NbTZRT1pXaklwcXRnR1BndmN3UHFoTzJTbTh5UitG?= =?utf-8?B?OTlpdWkvL0E2VU9Va2pGUkVCb1o4VHBXMFRianA2eGZYRGw2cU5SVTNuMER0?= =?utf-8?B?eGRqbHp1Z0FUMTliVzBjWWNUWWhmQkVnSmJrYWJyUjREZy94KzFaMmN1V0hR?= =?utf-8?B?Vlo0cDMvVFpWU1NLTjNEVGlMSllyMmtlMnRJVWRVMnZYWUFOYlZ5RnV0NEhB?= =?utf-8?B?VCtDWkFpZm0wcEtiZUlXQlZTWmQ3bzJFb3FtNnNSY0ZtT0pCZ2lHMjB2MWh0?= =?utf-8?B?QnI5dlh3d1k0N2Z4Q2x1RGJ1aHFYVXhFNGROWnhpLzJGN3hmcmJBR0JZb0Fo?= =?utf-8?B?eHA3NVpONTliWHdEOUhZSkxYK1BtOGJSTUJrYWVxcmhyNTVzRUhjYU03bkNB?= =?utf-8?B?aThJSUx2MFJzQ2Vsc2dnQTIxNjlTQTJDTTlmUi92TmFaRVJGbU1WTUtZOW9v?= =?utf-8?B?Vmh0M056aWRadXFYRmFQWkdCREtvamVTMSttS1VOdU10REVERkhXd2twOURo?= =?utf-8?B?RUtQTEl4eFdJY1d4UjhTWmRtckMyZHFiQ3AydllCQnhqaUFUTVIwbkhDaC9y?= =?utf-8?B?WWN4d0NMcGo5NHcxdG9qczFIbGEzR3oyMFlmaFR4bGhiS1JhUG45LzBTRXRq?= =?utf-8?B?azR2V1ZwWUxMa1hGUXdNRjkySEZuQnd2a1FiKzlubFdxS01KVGZLU244VzVR?= =?utf-8?B?eVZYS3Q0QWlINm9pMlplZ0V1dnF0Unk5d3VBV2dmWmJXZkl2QTF4cENmNFA5?= =?utf-8?B?YVA4dVlIQ2lrc0lTYWNOQXpNMUl4NS9FQllNRkVtN21jUzhMMWc0bUNnU0Nr?= =?utf-8?B?SEtoNXA1Ni81WUtzaUFlSEF3MElkV2dVTWtuQWoySHJSTUFNWUJNcFg4V3VC?= =?utf-8?B?NDNGeXFZSnB1UkQ0ODNidUxIMzVoWGVXNEM2Y1FKR1ZPZXBrbG0wRXNMRlBP?= =?utf-8?B?Wk8xaTM3U0ZpekZFb0V5TjMrQ09BNm1PTDJZMy9tVXR5MkltenRyMkZmdkxy?= =?utf-8?B?STM0WTg0QlU1UU11OE9JOWRYb1ViKzNreFhXci9ST0JXSnJtekZtSmFuS3lo?= =?utf-8?Q?dZPkIb?= 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)(7416014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jun 2025 14:20:29.2534 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f73868c9-3775-4e31-ff7c-08dda1e0a07e 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: SJ1PEPF000023CE.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6491 On Fri May 30, 2025 at 11:04 PM CEST, Jason Andryuk wrote: > On 2025-05-30 08:02, Alejandro Vallejo wrote: >> xen/grant_table is meant to pull asm/grant_table, when it exists. >>=20 >> Signed-off-by: Alejandro Vallejo > > I think you can also remove this one: > xen/arch/arm/dom0less-build.c:#include > > With that, > Reviewed-by: Jason Andryuk Oh, yes. I missed that one. Thanks. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Mon Jun 02 14:22:21 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 14:22:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003504.1383075 (Exim 4.92) (envelope-from ) id 1uM63O-0003RK-0c; Mon, 02 Jun 2025 14:22:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003504.1383075; Mon, 02 Jun 2025 14:22:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uM63N-0003RD-Sq; Mon, 02 Jun 2025 14:22:17 +0000 Received: by outflank-mailman (input) for mailman id 1003504; Mon, 02 Jun 2025 14:22: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 1uM63M-0003PY-NK for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 14:22:16 +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 fad5d7e1-3fbc-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 16:22:14 +0200 (CEST) Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-3a5123c1533so82518f8f.2 for ; Mon, 02 Jun 2025 07:22:14 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-23506bc85b8sm71329355ad.52.2025.06.02.07.22.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 07:22:13 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fad5d7e1-3fbc-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1748874134; x=1749478934; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=TTAs0LNSF1EHUIsw/UIDSNXNq8tvvSiD1S1MQhaB5cw=; b=L8Fi6nSzT53141AljdfKckS6qwjVAuJs4+Q/xdYkIFwNRdYooMWNP5hebT7r8GzbKj 1fB+SG9rSLW4TAUN4twcHmqFtCyGZ5WOSvVlRxhiRCAQ+7/KMf81erg6foVZCHqH4m/C 3rnuzLJ6XF4oFcWgkPzOfYB3/xiX2s9X0fydi9pat/W68DRH6j49NsOVMbQVYQ2i+MmN sDtF9+c/dEIrNSI+8YuPAInNpl4MO0/WoJ5vC6+Wzn6uCpQNwq/Rk1XLdQuu7R4sC5Lo J71ArMhR06IrWO+2JddxyosnqZc5BxLwuUNqk66q2id7Tmn3um0E97DE7adT0Wd9kJNT UVhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748874134; x=1749478934; 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=TTAs0LNSF1EHUIsw/UIDSNXNq8tvvSiD1S1MQhaB5cw=; b=FrsrRz43LhZRVJnYHzISk98Hl8jlXQ5AsCz4/8EI2coQUh/FOAGfAv5Ke3GEW12j9x gf6A8thu4qTJhkRWcyoDR3I0nRQLX/wg6ECR+UbKTXqcwpl19jBy6ViZjSAvTzfixFjl F1OPvJKy8EkegA8Qfey6KTQvoI866jnfRrtLFb83KX15QJ2N+HVCGhCrBs9+j0QX8TMi 207HssAVH9cXNOyE+A5NrGY+RsuJ5ogzwScLvyzrX5zY8dg/RylmbBhdLmBR6DoUoSLh hGjIXiJYcSAdKfZiH7O6y2g9x1wKyqysWzuLL8nUuF0B2jVieZZJgE2plPaKWT709wQw yTjQ== X-Gm-Message-State: AOJu0Yxlq59r4xvWrfdyGnRrrgLJEjfJz6oPwX8thdSVXky+al/Kdr/U oqQdJyCXyx29ZdjzOmax2hBxK+VVVGig/q4af/4LeddSttbY8FpA7X85+/i5WLtKnQ== X-Gm-Gg: ASbGnctcJMaar9bxkyYLOfL3woRTVQtilNsQ63LkzoUIKupmEs+fZVBx5RugLLzYyNO BoL51acSffsTqYCSpQ85TbAanRem7ebHIyQky8p1RZ0dONjBsrmQcGrvtRJIV+oC+kmCdHLY57h azhJBlWn2fDIASc0VXA7G5RdHXFmQaW5vwkluWzWgEnRfn9Rd0GbROa8I9wvHtnCT7IFMQ4+1Zp MuNUcz8ZUcUoR0yrT5AyNtovNFjLC0IVWJJgEIKKGlwmjk9XYU3y6fSEfupnqLkghvgwEBJx+ME 1vkJ3gbfUpizaoioecpmtKWyNyGa60Sj8OHl5S2cQSGMGFwXbRxNNoyp/Jp8/qdrAcGNE2skksw G9lWURYrZVzpL3tISQht/syQLmG5P2ga+SwgzxZQVLe3qYu0= X-Google-Smtp-Source: AGHT+IHEXC6Uumottm9oIKFUcssW7+3tDoegr5i/csRPbP4io+NfA0fzHLWQHdGPxs6FmiNXc1FW6w== X-Received: by 2002:a05:6000:250f:b0:3a3:ec58:ebf2 with SMTP id ffacd0b85a97d-3a4f89a5a9cmr10633361f8f.7.1748874133857; Mon, 02 Jun 2025 07:22:13 -0700 (PDT) Message-ID: Date: Mon, 2 Jun 2025 16:22:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/3] Disallow most command-line options when lockdown mode is enabled To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= Cc: xen-devel@lists.xenproject.org, Ross Lagerwall , Kevin Lampis References: <20250602134656.3836280-1-kevin.lampis@cloud.com> <20250602134656.3836280-4-kevin.lampis@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 02.06.2025 16:16, Marek Marczykowski-Górecki wrote: > On Mon, Jun 02, 2025 at 02:46:56PM +0100, Kevin Lampis wrote: >> --- a/xen/common/lockdown.c >> +++ b/xen/common/lockdown.c >> @@ -35,7 +35,7 @@ static int __init parse_lockdown_opt(const char *s) >> >> return 0; >> } >> -custom_param("lockdown", parse_lockdown_opt); >> +custom_secure_param("lockdown", parse_lockdown_opt); > > Is that really a good idea? It means `lockdown=yes lockdown=no` would > still disable it in the end. This may matter more if for example the > `lockdown=yes` part is in the built-in cmdline (possibly with other > integrity protection than UEFI SB). But having a way to override an earlier "lockdown" by "lockdown=no" is intended? E.g. when your xen.cfg has the former, but you don't really want that (for, say, an experiment). Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 02 14:24:53 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 14:24:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003513.1383084 (Exim 4.92) (envelope-from ) id 1uM65s-00049R-Bl; Mon, 02 Jun 2025 14:24:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003513.1383084; Mon, 02 Jun 2025 14:24: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 1uM65s-00049K-8x; Mon, 02 Jun 2025 14:24:52 +0000 Received: by outflank-mailman (input) for mailman id 1003513; Mon, 02 Jun 2025 14:24: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 1uM65q-00049E-5X for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 14:24:50 +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 566e3d95-3fbd-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 16:24:48 +0200 (CEST) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-451d41e1ad1so13177465e9.1 for ; Mon, 02 Jun 2025 07:24:48 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-23506bc8b0fsm71255915ad.7.2025.06.02.07.24.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 07:24:47 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 566e3d95-3fbd-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1748874287; x=1749479087; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=+xSc7AvOYJ5oAG7rtbkBJTkVM+vaBHZuRstLmwn9AGM=; b=cD8goVFI6yk2r0TTvrtd53Pcfha0VJcNiIJAOvhcRRMCN4AYNSARpjxp6ZlffOg6sW fY8na3ZFzdkeDCESiyoKF1Q1PvHktJlliVDsU4kh2cfdpZoH4do7QnimXr5kUYHIhQPc ktSK5VhVIqV8kgHQmmY7RWK3awHer8oDy5+JRsVK6qhw/1fhWTiNyJz82U2yv07JGqie nWth776Se6guIMfSrBV4KHp4LY037208wB1IzDC80rjYwqF8LPvfrt/bKvNQYvSiJRzH Cn7m+nZHknakFkN/4RbrJ+tlBygPaBKhXGbmnDGrOkoQ85d3txWYxyUwvh3hmqdjsmG7 13xA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748874287; x=1749479087; 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=+xSc7AvOYJ5oAG7rtbkBJTkVM+vaBHZuRstLmwn9AGM=; b=T6VPXxdrpON6CwxVxkcFcBkoR1oUXpjYs4fL8oHY/utin3SCz9zK6vSNvQUEx9VqkK 1j1h/JWuez8nCO/uaBgxpxMFvifThSVqpnh4evitWObxauG8SMIsJbb4FExytEh6UIMG 0wEZJOVZJHdugi1BZcqqFZYXwUwbBf2/up+OLQQL2NqTQq0Vpc+adqXmAS0WeFfG5J0q vs67cRf/Jb8td0AmpOSBqSvTBBsUr6zhu/3UQCLHBOcISY4wfJrRfeWwW4/9RBsoDkPv 1ybtiwQt0ksaWhCVt180UNzdsqfIueDNZEmYUg0ap/2F+yEDjZzbOKhC5pI8RUNb+rIU bvDA== X-Forwarded-Encrypted: i=1; AJvYcCXy3hPJXieIYRZgyBZuVSd+4uFabCH/v2igs3/u0bvTbXuhEcusO4pYJAdYuUMwn9mA+exbuE73LFU=@lists.xenproject.org X-Gm-Message-State: AOJu0Yye9N+guMLslXN4TrDoDK7vnMHF8iPNlExLhLQ20ZIweK+MIo3g 1W0AN0+eyHy8ibPqWvMJUrEzGkgaB52Z78XaD7m2NOKs6HKmROHEpLW7IGhv/ER89g== X-Gm-Gg: ASbGncuPVS81Q/vhqmbGd1R9qlDuzL2t8jJW4oRXZHTn7+yKdGQGzjfyWItW8AmrEDJ ihGk1fXpE9psAHrkUCg0ooN62/ylpE7ADUUIYy2d9T/2vyKlQJJCD3a5RSOF5JLlZKjn5dODsu4 RhpN1fHBXxYiWDkQ3PBPmA+5LWLIdyaobevsu9F4hwO4dlclqE7LAwyDFVtPJgcr/SO4lLcovE/ 7R+8NSMEf+ue67ZO5NOyTeOcuXovU+IthTwIhSJzKVN2rM1vGiNHk4+rz/nrnZvDPgxNbc+/x+I +ufxYluMoez84tlg4eu4MlYDZz9NfU/5AE5ANO/Hxvnzxn3j6znea6M7Ni2R1Xxh5N0Jit/BobJ aU8VJF5xALGxD0+x5e79vCiOaGVSSH2+w7Ynczh8tACtnKMI= X-Google-Smtp-Source: AGHT+IHG7eP42v2dgk428z3sGHrVSCKO9+ajlpz8VQ1N2OLEqLJtP5jPewMdY+CQ2Sfo99qOIWVtwQ== X-Received: by 2002:a05:6000:2c12:b0:3a4:d64a:3df0 with SMTP id ffacd0b85a97d-3a4f7a025bdmr10826143f8f.4.1748874287541; Mon, 02 Jun 2025 07:24:47 -0700 (PDT) Message-ID: Date: Mon, 2 Jun 2025 16:24:36 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 06/19] xen: Clean up asm-generic/device.h To: Alejandro Vallejo Cc: Alistair Francis , Bob Eshleman , Connor Davis , Oleksii Kurochko , 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: <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-7-agarciav@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 02.06.2025 16:19, Alejandro Vallejo wrote: > On Mon Jun 2, 2025 at 9:51 AM CEST, Jan Beulich wrote: >> On 30.05.2025 14:02, Alejandro Vallejo wrote: >>> --- a/xen/include/asm-generic/device.h >>> +++ b/xen/include/asm-generic/device.h >>> @@ -6,9 +6,7 @@ >>> >>> enum device_type >>> { >>> -#ifdef CONFIG_HAS_DEVICE_TREE >>> DEV_DT, >>> -#endif >> >> Why would this enumerator need exposing on a non-DT arch? In fact I would have >> hoped for ... > > A non-DT arch would not include this. x86 doesn't. Both here and ... >>> DEV_PCI >> >> ... this to be hidden for arch-es not supporting PCI. >> >> Similar concerns elsewhere in this change. > > This file is exclusively used by arches supporting DT to abstract away where > the device came from. x86 does not use it at all, and while it wouldn't be > impossible to compile-out DEV_PCI, it would needlessly pollute the codebase with > no measurable gain, because the abstractions still need to stay. ... here: In "xen/include/asm-generic/device.h" there's nothing at all saying that this file is a DT-only one. Instead there is something in there saying that it's suitable to use in the entirely "generic" case. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 02 14:27:30 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 14:27:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003523.1383094 (Exim 4.92) (envelope-from ) id 1uM68M-0004i8-TO; Mon, 02 Jun 2025 14:27:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003523.1383094; Mon, 02 Jun 2025 14: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 1uM68M-0004i1-QE; Mon, 02 Jun 2025 14:27:26 +0000 Received: by outflank-mailman (input) for mailman id 1003523; Mon, 02 Jun 2025 14:27: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 1uM68L-0004hv-Di for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 14:27:25 +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 b3a5623a-3fbd-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 16:27:24 +0200 (CEST) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-450cfb79177so23389205e9.0 for ; Mon, 02 Jun 2025 07:27:24 -0700 (PDT) Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112]) by smtp.gmail.com with UTF8SMTPSA id 5b1f17b1804b1-450d7fb7e41sm122725445e9.26.2025.06.02.07.27.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 07:27:23 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b3a5623a-3fbd-11f0-a300-13f23c93f187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1748874444; x=1749479244; 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=FThXX84qzUvkWuvanpUBN/Tye/WVUi7pzOiYGlnoRLY=; b=Lj9wFkLkw7Fwt/8tiWYOwyktWLsKns+3xYnDM9pZMrbFKQnQjZGt09pGGmuB5wMrM0 NxfTbnYVcus2chZWEBCSbul6ZAMKrMqIWt1wUvMqCm6tqt9uUSBBNqY0O0iTiDEnDQsT TrQxrEc3VJRVLDgEdEiJzWQqPhK7hGAawfFcc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748874444; x=1749479244; 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=FThXX84qzUvkWuvanpUBN/Tye/WVUi7pzOiYGlnoRLY=; b=vIDPGI4Q7rpE4lAYxyxGpLkUlrdcfnMeiImk4aLg4bf6FFDzCSva8qwy4No0Pn0LML JDmy7fVdlJOv1LW1lFGur5sPMIqjpxvT7YriznbOpigx3WwZz9HdcD9Dls7v+Sweife+ m0DwWKlS0eynOp1EMxeE9oJilTvIk7LILoil0pRyaCnVLpDxCFDKLL/M5QbmS3sgrDaH nDCmdxONgqTHKaMmXn2fU010Wh0N9J6trDbnGqNf15oEamAZTqs/85OzYQGjBhikuzGR qJpsTACINSuF9RQQEdN4LgWsnYuP4Y8lUrO22GjGKhwi+nhw862xB9w+kEzHularcrCZ d3vg== X-Forwarded-Encrypted: i=1; AJvYcCXT2NWjBnmP/b6BsvaG6QLLlUZLbP+zQ8LyDKWnwJNuEm4aMiNOUJOi+Q6Vt+HG3hRol0WjEOpLFdQ=@lists.xenproject.org X-Gm-Message-State: AOJu0YzjkCMpt3ZbwZt8N9eeeEDd0fmd1knkqlpxUNv01xQrrmO0NDpf UBn04WJZQZGh9hBF9wpN0bTC+tjmpzuUQDpaDJvRx0NNZqfldWyaxpyIsyx3UIgYlUc= X-Gm-Gg: ASbGnctjmmLIo+2DOMJM2o7nWELh7tIzjYDtm+FtJbeIdRScbSrrPKlVYhmtpZIU7lx 5FPqFHsyNV2UmriyjhOIDXeOLpt+lfubfxv4+eIGjSavLY3kNH4fROV/vminzjrxYFjuNGx0Q68 Ot/L6pWGn3PXv4VV79jP1CY+8KQO3kHSi0mrdkwctGTyG/eX8NNCTQ0APixgv+7QCilC5vNiit0 3IFB8aIclcwUDT01cMujnmc5spIDdDMIheHQLJ+ytaVenDH/CeirmjCHLnp2wnEXixOvaj3ET9i E+8g9CldXJgcfemphQRz/dpt0xBjewjVRZaOSTOcA9ss1edUC7lYE61b1uzd8dhKqLNm5ygnbRy aePyiGM55VyUtwK2HfXnVsy/unSTShQ== X-Google-Smtp-Source: AGHT+IEDBm1thALKRLLquPDciEzDf+F/HEJD1o4XUAkGUIn3gKRgVB61smOj3Vo9fIbjE+IWz8/GhA== X-Received: by 2002:a05:600c:314a:b0:442:d9f2:c6ef with SMTP id 5b1f17b1804b1-450d880abb7mr119480495e9.2.1748874443872; Mon, 02 Jun 2025 07:27:23 -0700 (PDT) Date: Mon, 2 Jun 2025 16:27:22 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: Andrew Cooper , Anthony PERARD , Anthoine Bourgeois , xen-devel@lists.xenproject.org Subject: Re: [PATCH] x86/hvmloader: don't set xenpci MMIO BAR as UC in MTRR Message-ID: References: <20250530092314.27306-1-roger.pau@citrix.com> <58c0499c-cdde-4cc3-9441-606a0eea4652@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <58c0499c-cdde-4cc3-9441-606a0eea4652@suse.com> On Mon, Jun 02, 2025 at 11:46:52AM +0200, Jan Beulich wrote: > On 30.05.2025 11:23, Roger Pau Monne wrote: > > The Xen PCI device (vendor ID 0x5853) exposed to x86 HVM guests doesn't > > have the functionality of a traditional PCI device. The exposed MIO BAR is > > used by some guests (including Linux) as a safe place to map foreign > > memory, including the grant table itself. > > > > Traditionally BARs from devices have the uncacheable (UC) cache attribute > > from the MTRR, to ensure correct functionality of such devices. hvmloader > > mimics this behaviour and sets the MTRR attributes of both the low and high > > PCI MMIO windows (where BARs of PCI devices reside) as UC in MTRR. > > > > This however causes performance issues for the users of the Xen PCI device > > BAR, as for the purposes of mapping remote memory there's no need to use > > the UC attribute. On Intel systems this is worked around by using iPAT, > > that allows the hypervisor to force the effective cache attribute of a p2m > > entry regardless of the guest PAT value. AMD however doesn't have an > > equivalent of iPAT, and guest PAT values are always considered. > > > > Linux commit: > > > > 41925b105e34 xen: replace xen_remap() with memremap() > > > > Attempted to mitigate this by forcing mappings of the grant-table to use > > the write-back (WB) cache attribute. However Linux memremap() takes MTRRs > > into account to calculate which PAT type to use, and seeing the MTRR cache > > attribute for the region being UC the PAT also ends up as UC, regardless of > > the caller having requested WB. > > > > As a workaround to allow current Linux to map the grant-table as WB using > > memremap() special case the Xen PCI device BAR in hvmloader and don't set > > its cache attribute as UC. > > Can we (fully compatibly) make such a change? IOW do we know all possible > guests would be at least unaffected (ideally affected positively)? Imo ... Is there any other possible usage for the xenpci MMIO BAR? My understanding is it was introduced for this specific purpose; to signal a safe place to map the grant-table or foreign mappings, which in both cases want to have an effective WB cache attribute. > > Such workaround in hvmloader should also be > > paired with a fix for Linux so it attempts to change the MTRR of the Xen > > PCI device BAR to WB by itself. > > > > Overall, the long term solution would be to provide the guest with a safe > > range in the guest physical address space where mappings to foreign pages > > can be created. > > ... this is the only viable path. I agree, however this will take more time to materialize IMO. Needs a patch to Linux, plus possible backports, and then distros picking the updates. While I agree this needs fixing in Linux, I don't see any downsides of doing the workaround in hvmloader also, as a faster way to get it deployed with just a Xen update. > > Some vif throughput performance figures provided by Anthoine from a 8 > > vCPUs, 4GB of RAM HVM guest(s) running on AMD hardware: > > > > Without this patch: > > vm -> dom0: 1.1Gb/s > > vm -> vm: 5.0Gb/s > > > > With the patch: > > vm -> dom0: 4.5Gb/s > > vm -> vm: 7.0Gb/s > > > > Reported-by: Anthoine Bourgeois > > Signed-off-by: Roger Pau Monné > > --- > > I don't think the ACPI tables builder consume the PCI window size > > information, I'm not seeing any consumer of the acpi_info->pci_{min,len} > > fields, yet I've keep them covering the xenpci device BAR, hence the > > adjustment to hvmloader_acpi_build_tables() part of this patch. > > acpi_build_tables() copies the field, and the comment ahead of struct > acpi_info clarifies where the uses are: It's the PLEN field, which does > have a use in dsdt.asl. Aiui the change you make is therefore a necessary > one. Right, thanks. I was grepping for 'Field("BIOS"', instead of 'Field(BIOS'. Roger. From xen-devel-bounces@lists.xenproject.org Mon Jun 02 14:31:10 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 14:31:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003533.1383103 (Exim 4.92) (envelope-from ) id 1uM6Bx-0006OA-BX; Mon, 02 Jun 2025 14:31:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003533.1383103; Mon, 02 Jun 2025 14: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 1uM6Bx-0006O3-8n; Mon, 02 Jun 2025 14:31:09 +0000 Received: by outflank-mailman (input) for mailman id 1003533; Mon, 02 Jun 2025 14: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 1uM6Bv-0006Nx-R0 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 14:31:07 +0000 Received: from NAM02-BN1-obe.outbound.protection.outlook.com (mail-bn1nam02on2061d.outbound.protection.outlook.com [2a01:111:f403:2407::61d]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 37862069-3fbe-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 16:31:06 +0200 (CEST) Received: from BY5PR04CA0023.namprd04.prod.outlook.com (2603:10b6:a03:1d0::33) by DM4PR12MB6447.namprd12.prod.outlook.com (2603:10b6:8:bf::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.33; Mon, 2 Jun 2025 14:31:00 +0000 Received: from SJ1PEPF00001CEA.namprd03.prod.outlook.com (2603:10b6:a03:1d0:cafe::3b) by BY5PR04CA0023.outlook.office365.com (2603:10b6:a03:1d0::33) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.23 via Frontend Transport; Mon, 2 Jun 2025 14:31:00 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by SJ1PEPF00001CEA.mail.protection.outlook.com (10.167.242.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8792.29 via Frontend Transport; Mon, 2 Jun 2025 14:31:00 +0000 Received: from localhost (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 Jun 2025 09:30:57 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 37862069-3fbe-11f0-a300-13f23c93f187 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=YgylZAB+tO8GOrpFvLqcBMQbf6yKFOf9ktAdf8NCyEukiwe9uFD9lcaM+uXkfSLtbgQCCR0Km7LuUOV2VIWtKhGc1+kximjxoWUD0kdum3Zq/0DG2kufHYTe2nbWkDCvM4OHyy5yzVvfRNC99MEunN/E1a7qzY1i4VPGAibL3U3xCCLDGxlTwkYwzxETFoq+6kQmghngFoMjqQ7NJntStYn/KYZCADRva/47XI4Dxo/+Cvyi0jObmJCggnkRVgeQHIfrbL1QDNOzNhAozJr9xTN/uQpDWheVZwZBZROsDZktn8vJkRtRTfjX1duVPXt2boxBMoSypVsoVz/gJoZRqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=DztQnG2UMubC+EwWW6HqFUliBpkKn8jWegdjsxqAeQo=; b=AwKwfzr6A8ESISWbCt9ivfcUib6cOkfw+2wigtTp2TgOVQ5VqRgcdSteFtsCuCj5AjOPBCBYWoN+Ehzbg0JelexdaMw6fIC1oJLaNt5Isz4TrosTJGMiVPpDs+8tnpJxEweOLvb471h57WOQyc7EpnvBSrZ5zD/HBxTllbUzTC59bzrh0GWqYQIiFNI9SWUK5ARjTfJ8htj9UthFLw3Q4laefXglI8whZdUNzz37AHoM83xdEud1k6qDWNOESYtB+9c5aIWOyoV8wFdsobVDrZIMAj6aRWTnW0gfKuiXnzveGA25dvkV8/QZZkK5iQgooBgI3qEQEDFIJ0ads1qGuQ== 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=DztQnG2UMubC+EwWW6HqFUliBpkKn8jWegdjsxqAeQo=; b=v1YPEjC04Iw9gfXby15HUcCIfXTNrxHOOHsgCsr7Cb3bNj4TJ2Cjtj7EJaQKF1DggH1NTMkaD284gzfjTCITK2InL//B3kiWV5DxgXW9C0MVwdO+We78WdMcZwjkY/cznbEv6bMU/q1uYKsHcTrTNTikrOUiQsRftj/VKwUE948= 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 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Date: Mon, 2 Jun 2025 16:30:56 +0200 Message-ID: CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , "Daniel P. Smith" , Subject: Re: [PATCH 07/19] arm/gnttab: Break cycle between asm/grant_table.h and xen/grant_table.h From: Alejandro Vallejo To: Jan Beulich X-Mailer: aerc 0.20.1 References: <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-8-agarciav@amd.com> <5f3de127-70cd-422f-a368-6c23d83c6cf9@suse.com> In-Reply-To: <5f3de127-70cd-422f-a368-6c23d83c6cf9@suse.com> 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: SJ1PEPF00001CEA:EE_|DM4PR12MB6447:EE_ X-MS-Office365-Filtering-Correlation-Id: fad0d522-ee4f-4847-78a3-08dda1e2188f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|36860700013|7416014|82310400026|376014; X-Microsoft-Antispam-Message-Info: =?utf-8?B?Slgyd1FFOXNyUmdubVEwYU56ditNUG51elZ1bFB2ZE53cWFJUnJ6dUpGVUw3?= =?utf-8?B?bk9OeTFvZUdiL2JVQmpaeHNyUm5LMENSUWpEVTRuUUFlTDRPQldXaUhYQzgw?= =?utf-8?B?UWROZEkxMHhjYTBkWmZWaXpaczQvczBxTlZUM3dDRzFMNzBDNDc1amRLdWE1?= =?utf-8?B?ZVdmZVV3SExvUFJ3YXgyQ3JqaFBndldxbG1vVDN6WDNaV2w0eUxKNE9CL2Yx?= =?utf-8?B?L0MyTGVEWGVTNEhtV005c1JPOGRqaXRPVXJ5Ym5zN1l4bUNzYVNGMzhkSTdx?= =?utf-8?B?RlhjYWRQUWp0Uk92OGxhd0lNWWxJQitUQUVmaDRBNG1taXVUUGRVMHUxWEly?= =?utf-8?B?ZWg1dDJhR25Ua0NaNldITzE0L0Y2TEVuOXZjVHlIMmdHRlJPMXlJZkZhTDlu?= =?utf-8?B?ZGdaR05CdGhRYVE4QmQwSkMyNXVGOUNaQmdseFhOL2hMZFdMeUozWElQUXh2?= =?utf-8?B?SDVpa3VJVEF4RFMyRHdiaWxVSjIzWUh2anVvbjJiZ3VjeCtlcUFEbEUrbU9a?= =?utf-8?B?TWlOb2h6Z3VzVmtDa29ubGthbGJsZjg2MTlYbDdtbkJaWXdGVTFsckkrOTly?= =?utf-8?B?V21TcmpZM3ZidHpiazg2clNuK3lFYzU5ZmUzOHQ5clYxcGNKdEo2ODdyNENR?= =?utf-8?B?RDhrS3YweXQ0TzByb3lyV2V2blo1Yk5reC9CMXRmdzJFWG1yWWgwbGJCdE93?= =?utf-8?B?dmZka3BGVU4yNWZPekNoMlFlYVMrUm4xWnlRVGlPYy9haEhaelF6bjl1MlVC?= =?utf-8?B?ejRKclVNaFpSMHc1WkE3Uy9IUzNQZXFlZ2xhYURQdXRYeWJlbFlIMGdQSFNq?= =?utf-8?B?YWlVVnIrOUMzTmNkMkZqbWw4WU5MakVKZEZJRzVldlNyNTdKRDcvemZ1ZThx?= =?utf-8?B?clVIaVFCL0ZVR1B4RExHTEsvNllrZHdBSFdxZU9DUkJjM1BJOGxvVldOSU9B?= =?utf-8?B?Q2c4dWZQVkJrQ24rRGxjd1N6SFNqL3U1RU5ObEg1MGxTZ3hURHBSVjZWRFI4?= =?utf-8?B?SG9INGpkdHZwTUpKRFJTcVNTeXBrOUszNVRISkl2VjBSSW94SERIT0tJTXlQ?= =?utf-8?B?cmRKcHpvcWE1SzMxbGxZN1hYRWMzWmlQU2hZMWp5QVRndTFHTlJ1eW0zK1hh?= =?utf-8?B?elNPM3VLYjdoelhtYmRWWTlEeGlaU2hEQ1pLRmpqZ3Naa1JkVS9ySFNMTEFL?= =?utf-8?B?SXhBS3pLaEtaSzFXVTJIblpVUnBhSVAxMXFmbTE5aitnT3ZhOFFIM3VaL3Yz?= =?utf-8?B?ZWVoSEZSU0o1RHlJaGl6azZFSGYrdnRNa2FzYTBMNkxFQzdJaU9UTXJ5SGVD?= =?utf-8?B?dW85TE9kMUV5VloyMmhUUCtacldQWHdlTHFOMEhRQnprU0l5bHd3L2hIUkRw?= =?utf-8?B?TURJYzBrZDZ6WTZTYjdRZFV6NjJLSTBaclpwcEpOelRuZTNDQU5ibEVWQUlo?= =?utf-8?B?dGJWR0hNZ2h4Vko4NFhIbHJQZ1p6V1ZKcHJMSUk4TFR4SUcvalR4NnpTZ2Za?= =?utf-8?B?OGJVeFFvdHU2bEk1cmNQUGFjcHI1NmZPd0pWVzVWY2RHM2hxUDFuWDYzUVZW?= =?utf-8?B?VTdLVUVjZkcrVkJzTExpaUpxc0gyWXRLSndKU2hTTFhyTlp4QThwTFRpdFJ2?= =?utf-8?B?ZytSL1RTMVpqRE1VbDlVKzFvMDJMTXQrWDR4VWJkT2VsWkQ4N3NRc21tT04v?= =?utf-8?B?YXhadVFobUJRV2VGRk9aeVhWVmx3dHF6TEREaTJITTJQbkY3KzRWYU5QVGFE?= =?utf-8?B?U3BSeGdzbXp4bzZGUmU5K3NWUm43R1h6ZVFsTC9xdzZlRitOM0Mvdjg5Mk5W?= =?utf-8?B?SXdDU2lJNmp1eXY3M3hBdVJmdXVqbVFsNlNOUFJoWndPZHM2K3Z6N2dQS2RD?= =?utf-8?B?WnZpclYvRytpTFFMUkkvYjdVTCthbGx4OVpCQVlQT1AxRXZ4WlpTM1NRSjM3?= =?utf-8?B?eCtPL2dYRVlCSU0zbTgyNGRnd3F3TGVxTkxrMExkejBGYnBEbGFSYk9aVWVH?= =?utf-8?B?cVB4c29KQ21jNSszQVU5cGRsUjgwS2MzNFVrK3dwQ285aG1XekZaY21jWWJv?= =?utf-8?Q?ikAd7H?= 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)(82310400026)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jun 2025 14:31:00.1749 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: fad0d522-ee4f-4847-78a3-08dda1e2188f 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: SJ1PEPF00001CEA.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6447 On Mon Jun 2, 2025 at 9:53 AM CEST, Jan Beulich wrote: > On 30.05.2025 14:02, Alejandro Vallejo wrote:> --- a/xen/include/xen/gran= t_table.h >> +++ b/xen/include/xen/grant_table.h >> @@ -27,7 +27,7 @@ >> #include >> #include >> =20 >> -#ifdef CONFIG_GRANT_TABLE >> +#if __has_include("asm/grant_table.h") >> #include >> #endif > > This change looks wrong (or otherwise is lacking justification): With GRA= NT_TABLE=3Dn > the arch header isn't supposed to be included. > > Jan It's not equivalent to the previous code; but that's a feature, not a bug. Not including the header with GRANT_TABLE=3Dn was the best we could with the older toolchains in order to not try to include a header that might not exist. The high number of sequential inclusions of xen/grant_table.h and asm/grant_table.h seem to attest to that. I can ammend the commit message to be clearer, but IMO this is what it was = always meant to be. I can replace the current commit message with: "The previous toolchain base version didn't provide __has_include(), whic= h allows conditional inclusion based on a header's existence. Lacking that feature the inclusion was guarded by the GRANT_TABLE option being presen= t but even then sometimes the arch-specific header is required even when the option is not selected. This causes inclusion sites to needlessly include both asm/grant_table.h and xen/grant_table.h. Using __has_include() removes this requirement at inclusion sites." Thoughts? Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Mon Jun 02 14:33:14 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 14:33:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003542.1383114 (Exim 4.92) (envelope-from ) id 1uM6Du-0007TM-Mm; Mon, 02 Jun 2025 14:33:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003542.1383114; Mon, 02 Jun 2025 14:33: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 1uM6Du-0007TF-Jj; Mon, 02 Jun 2025 14:33:10 +0000 Received: by outflank-mailman (input) for mailman id 1003542; Mon, 02 Jun 2025 14:33: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 1uM6Ds-0007T9-VU for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 14:33:08 +0000 Received: from gw3.antarean.org (gw3.antarean.org [84.247.13.64]) by se1-gles-sth1.inumbo.com (Halon) with ESMTP id 8061a084-3fbe-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 16:33:07 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by gw3.antarean.org (Postfix) with ESMTP id 4b9xCy2njzzNsTk for ; Mon, 02 Jun 2025 16:33:34 +0200 (CEST) Received: from gw3.antarean.org ([127.0.0.1]) by localhost (gw3.antarean.org [127.0.0.1]) (amavis, port 10024) with ESMTP id a7JFk9kzoPnz for ; Mon, 2 Jun 2025 16:33:34 +0200 (CEST) Received: from mailstore1.adm.antarean.org (localhost [127.0.0.1]) by gw3.antarean.org (Postfix) with ESMTP id 4b9xCy2CpTzNl38 for ; Mon, 02 Jun 2025 16:33:34 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mailstore1.adm.antarean.org (Postfix) with ESMTP id 4b9xCR2nXTz1G for ; Mon, 02 Jun 2025 14:33:07 +0000 (UTC) Received: from mailstore1.adm.antarean.org ([127.0.0.1]) by localhost (mailstore1.adm.antarean.org [127.0.0.1]) (amavis, port 10024) with ESMTP id I9kZDh_9fklY for ; Mon, 2 Jun 2025 14:33:06 +0000 (UTC) Received: from f2b978515ea2 (web2.adm.antarean.org [10.55.16.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailstore1.adm.antarean.org (Postfix) with ESMTPSA id 4b9xCQ66ttz17 for ; Mon, 02 Jun 2025 14:33: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: 8061a084-3fbe-11f0-a300-13f23c93f187 X-Virus-Scanned: amavis at antarean.org X-Virus-Scanned: amavis at antarean.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=antarean.org; s=default; t=1748874786; bh=z4ZlMf+Lv5xV4mIU7iCEzl70cQ7/c13EtEcrPm5jX9Q=; h=From:In-Reply-To:References:To:Subject:Date; b=IY/kW/xrcRvFGwjReT8yxPy67Qm3qnmBJewN3kBu8oAGbEJ4yli5vdIIoIWuDzUw8 mEXaQo47eDyuG4JapIyqwKIKX0jnkNHhxeO5yOonLpw805XpwAEgnlFMPfEghC5Jct rTA9u73s4zlAmbed/5owaRauiDQpZcSn6TmtPVJY= User-Agent: EGroupware API 23.1.011 From: Joost Roeleveld X-Priority: 3 X-Mailer: EGroupware-Mail In-Reply-To: <2226691.irdbgypaU6@persephone> References: <2226691.irdbgypaU6@persephone> To: xen-devel@lists.xenproject.org Subject: Re: Kernel panic when passing through 2 identical PCI devices Message-ID: <20250602143306.EGroupware.1G0k_iePuNZvNjMVaaT1dBR@egw.antarean.nl> Date: Mon, 02 Jun 2025 14:33:06 +0000 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 On Monday, 2 June 2025 15:43:37 CEST you wrote: > On 02.06.2025 14:28, J. Roeleveld wrote: > > I have a domain to which I pass through 4 PCI devices: > >2 NVMe drives > >83:00.0 Samsung 980 NVMe > >84:00.0 Samsung 980 NVMe > > > >2 HBA Controllers > >86:00.0 LSI SAS3008 > >87:00.0 LSI SAS3008 > > > > This works fine with Xen version 4.18.4_pre1. > > However, when trying to update to 4.19, this fails. > > To make it explicit: The domain in question is a PV one. Yes. I tried to convert it to PVH in the past, but PCI-passthrough wasn't working at all. And nothing I found since shows that it should be working now. > > Checking the output during boot, I think I found something. But my > > knowledge is insufficient to figure out what is causing what I am seeing > > and how to fix this. > > > > From the below (where I only focus on the 2 NVMe drives), it is similar to > > the succesfull boot up until it tries to "claiming resource > >0000:84:00.0/0". At which point sysfs fails because the entry for "84" is > > already present. > What would be interesting is to know why / how this 2nd registration > happens. Only guess I can make: They are both the same brand/model/size. Only serial number differs > It's the same (guest) kernel version afaics, so something must > behave differently on the host. Are you sure the sole (host side) > difference is the hypervisor version? I.e. the Dom0 kernel version is the > same in the failing and successful cases? I ask because there's very little > Xen itself does that would play into pass-through device discovery / > resource setup by a (PV) guest (which doesn't mean Xen can't screw things > up). The more relevant component is the xen-pciback driver in Dom0. I can confirm it's dependent on the Xen version. Kernel version = 6.12.21 I get a succesful boot with Xen version 4.18.4_pre1. When I use Xen version 4.19.1, the boot fails due to this issue. The kernel and initramfs does not differ between the boot. > Sadly the log provided does, to me at least, not have enough data to draw > conclusions. Some instrumenting of the guest kernel may be necessary ... The host boots using UEFI: === (xen.cfg in the EFI partition) === [global] default=xen [xen] options=dom0_mem=24576M,max:24576M dom0_max_vcpus=4 dom0_vcpus_pin gnttab_max_frames=512 sched=credit console=vga extra_guest_irqs=768,1024 kernel=gentoo-6.12.21.efi dozfs root=ZFS=zhost/host/root by=id elevator=noop logo.nologo triggers=zfs quiet refresh softlevel=prexen nomodeset nfs.callback_tcpport=32764 lockd.nlm_udpport=32768 lockd.nlm_tcpport=32768 xen-pciback.hide=(83:00.0)(84:00.0)(86:00.0)(87:00.0) xen- pciback.passthrough=1 ramdisk=initramfs-6.12.21-gentoo-host.img === Please let me know what other information you need and if there is anything I can try/test to get more information. Does the mailing list allow gzipped text files as attachment? Or how would you prefer the kernel-config of the host and guest? If there are tests to do, please give me several to try as I need to schedule downtime for reboots. Many thanks in advance, Joost From xen-devel-bounces@lists.xenproject.org Mon Jun 02 14:37:48 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 14:37:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003549.1383124 (Exim 4.92) (envelope-from ) id 1uM6IH-00088m-5n; Mon, 02 Jun 2025 14:37:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003549.1383124; Mon, 02 Jun 2025 14:37: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 1uM6IH-00088f-2n; Mon, 02 Jun 2025 14:37:41 +0000 Received: by outflank-mailman (input) for mailman id 1003549; Mon, 02 Jun 2025 14: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 1uM6IF-00088Z-B1 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 14:37:39 +0000 Received: from gw4.antarean.org (gw4.antarean.org [136.144.238.64]) by se1-gles-sth1.inumbo.com (Halon) with ESMTP id 21129717-3fbf-11f0-a300-13f23c93f187; Mon, 02 Jun 2025 16:37:37 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by gw4.antarean.org (Postfix) with ESMTP id 4b9xCp4D9xzNkbn; Mon, 02 Jun 2025 16:33:26 +0200 (CEST) Received: from gw4.antarean.org ([127.0.0.1]) by localhost (gw4.antarean.org [127.0.0.1]) (amavis, port 10024) with ESMTP id dlMktHZeBDOp; Mon, 2 Jun 2025 16:33:26 +0200 (CEST) Received: from mailstore1.adm.antarean.org (localhost [127.0.0.1]) by gw4.antarean.org (Postfix) with ESMTP id 4b9xCp1xhrzNkDx; Mon, 02 Jun 2025 16:33:26 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mailstore1.adm.antarean.org (Postfix) with ESMTP id 4b9xJc722Xz1G; Mon, 02 Jun 2025 14:37:36 +0000 (UTC) Received: from mailstore1.adm.antarean.org ([127.0.0.1]) by localhost (mailstore1.adm.antarean.org [127.0.0.1]) (amavis, port 10024) with ESMTP id YM1WjdwNVlcP; Mon, 2 Jun 2025 14:37:36 +0000 (UTC) Received: from persephone.localnet (persephone.adm.antarean.org [10.55.16.48]) (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 mailstore1.adm.antarean.org (Postfix) with ESMTPS id 4b9xJc1bl6z17; Mon, 02 Jun 2025 14:37: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: 21129717-3fbf-11f0-a300-13f23c93f187 X-Virus-Scanned: amavis at antarean.org X-Virus-Scanned: amavis at antarean.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=antarean.org; s=default; t=1748875056; bh=8Q8M9v2Q6jgMC1TqEdmw1BWVc9Dp26exxCehNBE3GHE=; h=From:To:Subject:Date:In-Reply-To:References; b=FOiVXcSjVY+Qdi4JZ1iAl7DLGYqrPa0iKUYDUTT5DVmU5roxjr9P5wEGqxYpWsQGi PCkW+YgF+/Fhf0uPWHSicqgauGDfhZ3rEb2rMy4HK+CgQ1N6W8UIwwOVXZkCAu8835 jBlHbgc2Esp2INDZ5SCJR34SVPp+T/hKecMObOHc= From: "J. Roeleveld" To: xen-devel@lists.xenproject.org, Jan Beulich Subject: Re: Kernel panic when passing through 2 identical PCI devices Date: Mon, 02 Jun 2025 16:37:36 +0200 Message-ID: <13792630.uLZWGnKmhe@persephone> In-Reply-To: References: <2226691.irdbgypaU6@persephone> <5004508.GXAFRqVoOG@persephone> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" On Monday, 2 June 2025 16:31:11 CEST Jan Beulich wrote: > On 02.06.2025 16:19, J. Roeleveld wrote: > > On Monday, 2 June 2025 15:43:37 CEST you wrote: > >> On 02.06.2025 14:28, J. Roeleveld wrote: > >>> I have a domain to which I pass through 4 PCI devices: > >>> 2 NVMe drives > >>> 83:00.0 Samsung 980 NVMe > >>> 84:00.0 Samsung 980 NVMe > >>> > >>> 2 HBA Controllers > >>> 86:00.0 LSI SAS3008 > >>> 87:00.0 LSI SAS3008 > >>> > >>> This works fine with Xen version 4.18.4_pre1. > >>> However, when trying to update to 4.19, this fails. > >> > >> To make it explicit: The domain in question is a PV one. > > > > Yes. I tried to convert it to PVH in the past, but PCI-passthrough wasn't > > working at all. And nothing I found since shows that it should be working > > now.> > >>> Checking the output during boot, I think I found something. But my > >>> knowledge is insufficient to figure out what is causing what I am seeing > >>> and how to fix this. > >>> > >>> From the below (where I only focus on the 2 NVMe drives), it is similar > >>> to > >>> the succesfull boot up until it tries to "claiming resource > >>> 0000:84:00.0/0". At which point sysfs fails because the entry for "84" > >>> is > >>> already present. > >> > >> What would be interesting is to know why / how this 2nd registration > >> happens. > > > > Only guess I can make: They are both the same brand/model/size. Only > > serial number differs > > I don't think this matters here at all. The guest isn't at the point yet > where it would even be able to retrieve these. From the log you provided > it's the PCI subsystem where the issue is triggered. This goes beyond my knowledge. Which means I'd rather provide too much information then too little :) > >> It's the same (guest) kernel version afaics, so something must > >> behave differently on the host. Are you sure the sole (host side) > >> difference is the hypervisor version? I.e. the Dom0 kernel version is the > >> same in the failing and successful cases? I ask because there's very > >> little > >> Xen itself does that would play into pass-through device discovery / > >> resource setup by a (PV) guest (which doesn't mean Xen can't screw things > >> up). The more relevant component is the xen-pciback driver in Dom0. > > > > I can confirm it's dependent on the Xen version. > > Kernel version = 6.12.21 > > I get a succesful boot with Xen version 4.18.4_pre1. > > When I use Xen version 4.19.1, the boot fails due to this issue. > > > > The kernel and initramfs does not differ between the boot. > > And that's the Dom0 kernel, just to clarify? There are two kernels involved > here, after all. Yes. Dom0 and the guest have their own kernel images. However, both run the same version. (I compile kernels from source) > >> Sadly the log provided does, to me at least, not have enough data to draw > >> conclusions. Some instrumenting of the guest kernel may be necessary ... > > > > The host boots using UEFI: > > > > === (xen.cfg in the EFI partition) === > > [global] > > default=xen > > > > [xen] > > options=dom0_mem=24576M,max:24576M dom0_max_vcpus=4 dom0_vcpus_pin > > gnttab_max_frames=512 sched=credit console=vga extra_guest_irqs=768,1024 > > > > kernel=gentoo-6.12.21.efi dozfs root=ZFS=zhost/host/root by=id > > elevator=noop logo.nologo triggers=zfs quiet refresh softlevel=prexen > > nomodeset > > nfs.callback_tcpport=32764 lockd.nlm_udpport=32768 lockd.nlm_tcpport=32768 > > xen-pciback.hide=(83:00.0)(84:00.0)(86:00.0)(87:00.0) xen- > > pciback.passthrough=1 > > > > ramdisk=initramfs-6.12.21-gentoo-host.img > > === > > > > Please let me know what other information you need and if there is > > anything I can try/test to get more information. > > Does the mailing list allow gzipped text files as attachment? Or how would > > you prefer the kernel-config of the host and guest? > > I don't think these are relevant (for the moment). Ok. > > If there are tests to do, please give me several to try as I need to > > schedule downtime for reboots. > > That would be some kernel hacking, as indicated before: Instrument the > (guest) kernel enough to figure out where the 1st and 2nd sysfs > registrations come from. This may then give us a clue what's being driven > the wrong way (by Xen, or maybe by the toolstack). If you could point me to a guide on how to do this? I know enough about C/C++ to write my own tools. But the kernel and Xen is too complex for me to follow and I would not even know where to begin. -- Joost From xen-devel-bounces@lists.xenproject.org Mon Jun 02 14:52:04 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 14:52:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003561.1383135 (Exim 4.92) (envelope-from ) id 1uM6W5-0003Vb-Hl; Mon, 02 Jun 2025 14:51:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003561.1383135; Mon, 02 Jun 2025 14:51: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 1uM6W5-0003VU-DQ; Mon, 02 Jun 2025 14:51:57 +0000 Received: by outflank-mailman (input) for mailman id 1003561; Mon, 02 Jun 2025 14:51: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 1uM6W4-0003VM-NA for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 14:51:56 +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 1d458d00-3fc1-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 16:51:50 +0200 (CEST) Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-3a365a6804eso3410848f8f.3 for ; Mon, 02 Jun 2025 07:51:50 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3124e3c1146sm5729608a91.35.2025.06.02.07.51.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 07:51:49 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1d458d00-3fc1-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1748875909; x=1749480709; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=Gm7cNfOyNkiOgSg9LIC0y0HPLqjG2l+p4TZscsqBbu0=; b=ZGamNin8ikIjtMCQskav9qkV7/Oqj+SqNgY6g/XuJy5aAzs6T57rkOBqiXzKW+adtF fVePecsbdlxZoOFcoNYNKFbZ1FIdic2BncKnE1f2YT7jOf046O+l3ae0+Rmo7dTK30ti mVjhiqN7XGCBUFLp0ctyttb7LJrmswrVkas8+5jPy5ZT71fbc9kbSv3Cw5vCJB0OMaP/ jc/LDFEEWccsnwdelH1xh0NPOCMSGuVxXwGz/+CcX9hJB6V2LBKZd25tNjcyWch83jbk bm72mIrHJYGFlmehmJj5bZSVRKtimCXjd/5X3GpwWlSQHxVTxNs1BkhKwXUifPanQMLO YpPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748875909; x=1749480709; 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=Gm7cNfOyNkiOgSg9LIC0y0HPLqjG2l+p4TZscsqBbu0=; b=C+S6LoY7lfXiLGHDL342/VPDx79NlA7aJycbYr0fvlNfVJTLCkzC6lShFgMvEBJqXq iGLmAZqk1Tpsh5VE67hh6HfTMQ72HtQzErO3H9wcJz+GCUz8SIZ6AHregmNq/GkKywAL Wq8Mv598Zw5uj4mzsKy+naYsG93R3b+ieVss4NAhuqEWd8E1hbWtp6RwJCRZnFnpgop5 Sto98xiRbXlYB6rh8BC0xpGfmNmsnMDSMF99JnX47DUmJVw4LDG+1LVApZL0pupqEzDm 63Ux2bfBXWqhGTdG+88DcruzURkpBnfPU3UuJtt9C6qVto52swZp7F351wCIW0n6zIjW T+Eg== X-Forwarded-Encrypted: i=1; AJvYcCUbAf89Z091kHUNmNqbuUuMe/4ay6OMxc/dMEZXaFwT4C4cFmW7NCfjbeGl5vUBHz5WBnpqmMTYCzs=@lists.xenproject.org X-Gm-Message-State: AOJu0YxWD0Xoz8vK+igROMnDcc6EHhYib/PSyaozO3Jv7hkHNcVL6Qz5 LbVXJIkhwU1sRA7W5DG4le2T8hYySaiyKogFDUR0VgroWvObCLPjSnczR9dzK1zaeA== X-Gm-Gg: ASbGncvCAd9yTKTu0FRrL5cixuaB52ZvJvtbzAm/7+jiNnT5hzPqXd4Hjr7yA6xMZq/ UOjMX9+Lj1tDI5eiSUHe19BN7XKETicd250eDQRfQxK0xjdtrgxnsZinRP884KLYMnTUkbaTDH3 +Zrncpias79o4+rVPs7iDQxA/dEfjf/9hRgazdsnDt3B/8y98GmaRDrM+9KmNYA/xkH2M/kaBO6 fIg8DHZd0Nv6ozYbbk6PXnxyANtF79PaueQ5hRZVuzkjoEVnDaHwxl4FNR8YPcHTuGQKqIGpAqd ruEU5cDgD+ywOsUs84KfUFI0D/B6r7QAc83YtQRVqryDUXXHmccLU6PtTeYJ24VMCyCvd4MB8me MYWJaYnLD5LaPDF5Ov/CWFUSak78/kqYBfwtc X-Google-Smtp-Source: AGHT+IFBFtNbIgjKyFwMZJ4IGUJXh6bywRNgIwFW4Ce3TXeFTrK2FKk+kzOmDl5756gORud0bq/Xmg== X-Received: by 2002:a05:6000:40cf:b0:3a4:e6e4:6ee7 with SMTP id ffacd0b85a97d-3a4f7a9d580mr9730597f8f.45.1748875909584; Mon, 02 Jun 2025 07:51:49 -0700 (PDT) Message-ID: <6cc4d172-793b-4d3e-990e-f8fd0d4bbabc@suse.com> Date: Mon, 2 Jun 2025 16:51:38 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 07/19] arm/gnttab: Break cycle between asm/grant_table.h and xen/grant_table.h To: Alejandro Vallejo Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "Daniel P. Smith" , xen-devel@lists.xenproject.org References: <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-8-agarciav@amd.com> <5f3de127-70cd-422f-a368-6c23d83c6cf9@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.06.2025 16:30, Alejandro Vallejo wrote: > On Mon Jun 2, 2025 at 9:53 AM CEST, Jan Beulich wrote: >> On 30.05.2025 14:02, Alejandro Vallejo wrote:> --- a/xen/include/xen/grant_table.h >>> +++ b/xen/include/xen/grant_table.h >>> @@ -27,7 +27,7 @@ >>> #include >>> #include >>> >>> -#ifdef CONFIG_GRANT_TABLE >>> +#if __has_include("asm/grant_table.h") >>> #include >>> #endif >> >> This change looks wrong (or otherwise is lacking justification): With GRANT_TABLE=n >> the arch header isn't supposed to be included. > > It's not equivalent to the previous code; but that's a feature, not a bug. > > Not including the header with GRANT_TABLE=n was the best we could with > the older toolchains in order to not try to include a header that might not > exist. The high number of sequential inclusions of xen/grant_table.h and > asm/grant_table.h seem to attest to that. > > I can ammend the commit message to be clearer, but IMO this is what it was always > meant to be. I can replace the current commit message with: > > "The previous toolchain base version didn't provide __has_include(), which > allows conditional inclusion based on a header's existence. Lacking that > feature the inclusion was guarded by the GRANT_TABLE option being present > but even then sometimes the arch-specific header is required even when > the option is not selected. This causes inclusion sites to needlessly > include both asm/grant_table.h and xen/grant_table.h. > > Using __has_include() removes this requirement at inclusion sites." > > Thoughts? So why would we include a header we don't need when GRANT_TABLE=n? Overall we're trying to reduce dependency trees rather than growing them further. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 02 14:52:34 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Jun 2025 14:52:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1003566.1383143 (Exim 4.92) (envelope-from ) id 1uM6Wg-00048Q-Nx; Mon, 02 Jun 2025 14:52:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1003566.1383143; Mon, 02 Jun 2025 14: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 1uM6Wg-00048J-LM; Mon, 02 Jun 2025 14:52:34 +0000 Received: by outflank-mailman (input) for mailman id 1003566; Mon, 02 Jun 2025 14: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 1uM6Wf-0003VM-7q for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 14:52:33 +0000 Received: from postout2.mail.lrz.de (postout2.mail.lrz.de [129.187.255.138]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 357f4757-3fc1-11f0-b894-0df219b8e170; Mon, 02 Jun 2025 16:52:31 +0200 (CEST) Received: from lxmhs52.srv.lrz.de (localhost [127.0.0.1]) by postout2.mail.lrz.de (Postfix) with ESMTP id 4b9xdp4v7gzyTy; Mon, 2 Jun 2025 16:52:30 +0200 (CEST) Received: from postout2.mail.lrz.de ([127.0.0.1]) by lxmhs52.srv.lrz.de (lxmhs52.srv.lrz.de [127.0.0.1]) (amavis, port 20024) with LMTP id 6Q7Bwaq5tZfE; Mon, 2 Jun 2025 16:52:29 +0200 (CEST) Received: from [IPV6:2a02:2455:1858:e00:e0bb:e98d:8f46:dc66] (unknown [IPv6:2a02:2455:1858:e00:e0bb:e98d:8f46:dc66]) (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 postout2.mail.lrz.de (Postfix) with ESMTPSA id 4b9xdn1XCQzyT9; Mon, 2 Jun 2025 16:52:29 +0200 (CEST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 357f4757-3fc1-11f0-b894-0df219b8e170 Authentication-Results: postout.lrz.de (amavis); dkim=pass (2048-bit key) reason="pass (just generated, assumed good)" header.d=tum.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tum.de; h= in-reply-to:from:from:content-language:references:subject :subject:user-agent:mime-version:date:date:message-id :content-type:content-type:received:received; s=tu-postout21; t= 1748875949; bh=nMeEhx7L+DCZVZYlqJjaSDQXyy4Ot24sMO8x0OyCLf4=; b=M DYSntO7RZz3SI1zwHIIqt5RP7rrNiLqiql5ykA9rBKmLkJKBaBPO/RmCrxHqubyh DvgniG65t9NOQJy4pufMDccjvC7Erb7xcLcsFa2WLbNTuRYpocpyBdc+vKTPRWw/ HJq4dGCTe4BcCu+j5zevRF5Hu3mjCVI1DQ49+852EChgbRWEq1kaP4LdjrQDgc6P DoXcS5TaoZQtQS3UNMMolp7uRoNWHC6bmp2R3d6nGWlti+++nMZWBXGRDUPUzsDo 4M5KXRrlAqjPO+rbkihMJnYc+8NdbSLLs2zGMKVeYR+RHyiWH4vOt+lohuhoJfwj LsMg0f8L581T6OXXrSARg== X-Virus-Scanned: by amavisd-new at lrz.de in lxmhs52.srv.lrz.de X-Spam-Flag: NO X-Spam-Score: -2.866 X-Spam-Level: X-Spam-Status: No, score=-2.866 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, DMARC_ADKIM_RELAXED=0.001, DMARC_ASPF_RELAXED=0.001, DMARC_POLICY_NONE=0.001, HTML_MESSAGE=0.001, LRZ_BND_ANU8=0.001, LRZ_BND_M12_AN24=0.001, LRZ_DMARC_FAIL=0.001, LRZ_DMARC_FAIL_NONE=0.001, LRZ_DMARC_POLICY=0.001, LRZ_DMARC_TUM_FAIL=0.001, LRZ_DMARC_TUM_REJECT=3.5, LRZ_DMARC_TUM_REJECT_PO=-3.5, LRZ_ENVFROM_FROM_MATCH=0.001, LRZ_ENVFROM_TUM_S=0.001, LRZ_FROM_ENVFROM_ALIGNED_STRICT=0.001, LRZ_FROM_HAS_A=0.001, LRZ_FROM_HAS_AAAA=0.001, LRZ_FROM_HAS_MDOM=0.001, LRZ_FROM_HAS_MX=0.001, LRZ_FROM_HOSTED_DOMAIN=0.001, LRZ_FROM_NAME_IN_ADDR=0.001, LRZ_FROM_PHRASE=0.001, LRZ_FROM_PRE_SUR=0.001, LRZ_FROM_PRE_SUR_PHRASE=0.001, LRZ_FROM_TUM_S=0.001, LRZ_HAS_BND=0.001, LRZ_HAS_CLANG=0.001, LRZ_HAS_CT=0.001, LRZ_HAS_IN_REPLY_TO=0.001, LRZ_HAS_MIME_VERSION=0.001, LRZ_HAS_SPF=0.001, LRZ_MIME_BND_SPAM_184=0.001, LRZ_MSGID_HL8_3HL4_HL12=0.001, LRZ_MSGID_MOZ=0.001, LRZ_SUBJ_FW_RE=0.001, LRZ_UA_MOZ=0.001] autolearn=no autolearn_force=no Content-Type: multipart/alternative; boundary="------------1EvWbjWPzA6lFP0fbfCwHvBg" Message-ID: <26f412e2-ba65-4e3f-8c5f-7e15f5f32491@tum.de> Date: Mon, 2 Jun 2025 16:52:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Nullptr dereference in nested VMX when shadow VMCS support is available To: Jan Beulich Cc: xen-devel@lists.xenproject.org References: <5f258e25-a4ed-4f9a-8ca6-9ea3400e2369@tum.de> <6d28eb0c-caed-4c58-a6ac-cbf8da357d22@tum.de> <21dcca4d-1c51-42f1-b73b-65702451de13@suse.com> Content-Language: en-US From: Manuel Andreas Autocrypt: addr=manuel.andreas@tum.de; keydata= xjMEY9Zx/RYJKwYBBAHaRw8BAQdALWzRzW9a74DX4l6i8VzXGvv72Vz0qfvj9s7bjBD905nN Jk1hbnVlbCBBbmRyZWFzIDxtYW51ZWwuYW5kcmVhc0B0dW0uZGU+wokEExYIADEWIQQuSfNX 11QV6exAUmOqZGwY4LuingUCY9Zx/QIbAwQLCQgHBRUICQoLBRYCAwEAAAoJEKpkbBjgu6Ke McQBAPyP530S365I50I5rM2XjH5Hr9YcUQATD5dusZJMDgejAP9T/wUurwQSuRfm1rK8cNcf w4wP3+PLvL+J+kuVku93CM44BGPWcf0SCisGAQQBl1UBBQEBB0AmCAf31tLBD5tvtdZ0XX1B yGLUAxhgmFskGyPhY8wOKQMBCAfCeAQYFggAIBYhBC5J81fXVBXp7EBSY6pkbBjgu6KeBQJj 1nH9AhsMAAoJEKpkbBjgu6Kej6YA/RvJdXMjsD5csifolLw53KX0/ElM22SvaGym1+KiiVND AQDy+y+bCXI+J713/AwLBsDxTEXmP7Cp49ZqbAu83NnpBQ== In-Reply-To: <21dcca4d-1c51-42f1-b73b-65702451de13@suse.com> This is a multi-part message in MIME format. --------------1EvWbjWPzA6lFP0fbfCwHvBg Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 6/2/25 4:12 PM, Jan Beulich wrote: > On 02.06.2025 15:39, Manuel Andreas wrote: >> I've discovered an issue in the nested VMX implementation, where an >> unprivileged domain is able to force Xen to dereference a NULL pointer, >> resulting in a panic. > Sadly you provide no details on this NULL deref. Here's the respective dump: ----[ Xen-4.20.0  x86_64  debug=y Tainted:     H  ]---- (XEN) CPU:    1 (XEN) RIP:    e008:[] nvmx_handle_vmx_insn+0x7ab/0xccb (XEN) RFLAGS: 0000000000010202   CONTEXT: hypervisor (d1v0) (XEN) rax: 0000000000000000   rbx: 0000000000000000   rcx: 8000000000000002 (XEN) rdx: 0000000000000000   rsi: 01ffffffffffffff   rdi: ffff82e0020155e0 (XEN) rbp: ffff830179407e68   rsp: ffff830179407e00   r8: ffff82c00023b000 (XEN) r9:  ffff830179413c40   r10: 0000000000000000   r11: 0000000000000200 (XEN) r12: ffff83010483d000  r13: ffff830179407ef8   r14: 0000000000000000 (XEN) r15: 0000000000000000   cr0: 0000000080050033   cr4: 00000000003526e0 (XEN) cr3: 000000010498f000   cr2: 0000000000000000 (XEN) fsb: 0000000000000000   gsb: 0000000000000000   gss: 0000000000000000 (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008 (XEN) Xen code around (nvmx_handle_vmx_insn+0x7ab/0xccb): (XEN)  75 b0 0f 86 12 05 00 00 <81> 08 00 00 00 80 41 8b 84 24 f4 05 00 00 80 cc (XEN) Xen stack trace from rsp=ffff830179407e00: (XEN)    ffff83010483d000 000000000011e000 0000000000000000 0000000000000000 (XEN)    ffff82d0402bfc4a 0000000100000000 0000000000119fa8 ffff82d000000008 (XEN)    ffff830100000006 ffff830179407ef8 0000000000000015 ffff83010483d000 (XEN)    0000000000000000 ffff830179407ee8 ffff82d0402a9a19 ffff82d04020361b (XEN)    0000000000000000 0000000000000000 0000000000000000 ffff830100997000 (XEN)    ffff82d040203615 ffff82d04020361b ffff82d040203615 ffff82d04020361b (XEN)    ffff83010483d000 0000000000000000 0000000000000000 0000000000000000 (XEN)    0000000000000000 00007cfe86bf80e7 ffff82d040203673 0000000000000000 (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000001 (XEN)    0000000000000000 0000000000000000 0000000000000043 000000000000007b (XEN)    0000000000000043 0000000000000000 0000000000000000 0000000011e57e00 (XEN)    0000000000000000 0000000000000000 0000beef0000beef 0000000000103fa2 (XEN)    000000bf0000beef 0000000000000046 0000000000119fa0 000000000000beef (XEN)    000000000000beef 000000000000beef 000000000000beef 000000000000beef (XEN)    0000e01000000001 ffff83010483d000 0000003136627000 00000000003526e0 (XEN)    0000000000000000 0000000000000000 0000000300000001 0000004e00000003 (XEN) Xen call trace: (XEN)    [] R nvmx_handle_vmx_insn+0x7ab/0xccb (XEN)    [] F vmx_vmexit_handler+0xd97/0x1e14 (XEN)    [] F vmx_asm_vmexit_handler+0x103/0x220 (XEN) (XEN) Pagetable walk from 0000000000000000: (XEN)  L4[0x000] = 0000000000000000 ffffffffffffffff Where nvmx_handle_vmx_insn+0x7ab/0xccb resolves to xen/arch/x86/hvm/vmx/vvmx.c:1169 Specifically, in nvmx_handle_vmptrld we have: 1830 if ( cpu_has_vmx_vmcs_shadowing ) 1831 nvmx_set_vmcs_pointer(v, nvcpu->nv_vvmcx); Which is reachable with nvcpu->nv_vvmcx untouched in the case of the p2m mapping for gpa not being writable (see lines 1793 - 1827) . Therefore, nvcpu->nv_vvmcx will remain NULL (as initialized in nvmx_vcpu_initialize). Further, inside nvmx_set_vmcs_pointer: 1164    static void nvmx_set_vmcs_pointer(struct vcpu *v, struct vmcs_struct *vvmcs) 1165    { 1166        paddr_t vvmcs_maddr = v->arch.hvm.vmx.vmcs_shadow_maddr; 1167 1168        __vmpclear(vvmcs_maddr); 1169        vvmcs->vmcs_revision_id |= VMCS_RID_TYPE_MASK; 1170        /* ... */ will then dereference vvmcs, which is NULL. >> This is possible when: >> >> 1. The malicious domain has nested HVM capabilities. >> 2. The CPU is running on top of VMX and supports shadow VMCS. >> >> To trigger the bug, the domain must first enable VMX operation for >> itself, execute VMXON and then finally execute VMPTRLD on a guest >> physical address that is backed by a non-writable p2m mapping. >> In `nvmx_handle_vmptrld`, after attempting to map the nested VMCS, Xen >> will check whether or not this mapping is suitable for writing and if >> not immediately unmap the nested VMCS again and abort the setup of >> `nvcpu->nv_vvmcx`. However, Xen at this point erroneously continues >> emulation of the VMPTRLD. In particular, if VMCS shadowing is available, >> Xen will nonetheless attempt to link up the nested VMCS to its own VMCS >> in `nvmx_set_vmcs_pointer`. Importantly, Xen here attempts to >> dereference the presumably mapped nested VMCS (which now is merely a >> NULL pointer) in order to mark it as a shadow VMCS by applying the >> `VMCS_RID_TYPE_MASK` to its revision identifier. Following, the page >> fault handler will panic Xen. >> >> I've attached an XTF reproducer that triggers the bug. To setup such a >> non-writable p2m mapping for the malicious VMCS, I first setup an >> appropriate grant table entry. I've tested it on Xen version 4.20.0. > I expect this to not work anymore on current staging or 4.20.1-pre. > See a8325f981ce4 ("x86/P2M: synchronize fast and slow paths of > p2m_get_page_from_gfn()"). On first glance I don't see how that would impact the type of the established p2m mapping. If you want I can compile staging and test if the PoC does not work there anymore. > >> To fix the issue I believe the following patch should be suitable: >> >> --- a/xen/arch/x86/hvm/vmx/vvmx.c >> +++ b/xen/arch/x86/hvm/vmx/vvmx.c >> @@ -1817,7 +1817,9 @@ static int nvmx_handle_vmptrld(struct >> cpu_user_regs *regs) >>              else >>              { >>                  hvm_unmap_guest_frame(vvmcx, 1); >> -                vvmcx = NULL; >> +                vmfail(regs, VMX_INSN_VMPTRLD_INVALID_PHYADDR); >> + >> +                return X86EMUL_OKAY; >>              } >>          } >>          else >> >> The VMX error AFAICT does not strictly adhere to the Intel SDM, but >> providing the guest some indication on what went wrong is likely more >> sensible than silently failing. > Giving the guest some indication is certainly right. If we want to follow > the above route, I think the change would want doing a little differently, > to take the path that presently is the "else" at the bottom of the hunk > above. However, I can't presently see how invoking vmfail() would make a > difference as to the subsequent NULL deref: The guest could continue the > same irrespective of the failure. Hence why I'd like to understand what > NULL deref you did observe. (We may hence need two patches - one along > the above lines, and another one dealing with the NULL issue.) The issue is really just in the latter part of nvmx_handle_vmptrld, which attempts to initialize its shadow VMCS even though establishing a mapping for the nested VMCS failed. An early exit from that function (as my patch suggests) should be sufficient for that case. Other parts of the nested VMX code already check for a valid nested VMCS via vvmcx_valid. There simply isn't such a check here presumably because the assumption was that any previous errors in mapping the nested VMCS were already handled by returning from the function or jumping to the out label. Best, Manuel --------------1EvWbjWPzA6lFP0fbfCwHvBg Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 6/2/25 4:12 PM, Jan Beulich wrote:

On 02.06.2025 15:39, Manuel Andreas wrote:

I've discovered an issue in the nested VMX implementation, where an 
unprivileged domain is able to force Xen to dereference a NULL pointer, 
resulting in a panic.

Sadly you provide no details on this NULL deref.
Here's the respective dump:

----[ Xen-4.20.0  x86_64  debug=y  Tainted:     H  ]----
(XEN) CPU:    1
(XEN) RIP:    e008:[<ffff82d0402ae2b8>] nvmx_handle_vmx_insn+0x7ab/0xccb
(XEN) RFLAGS: 0000000000010202   CONTEXT: hypervisor (d1v0)
(XEN) rax: 0000000000000000   rbx: 0000000000000000   rcx: 8000000000000002
(XEN) rdx: 0000000000000000   rsi: 01ffffffffffffff   rdi: ffff82e0020155e0
(XEN) rbp: ffff830179407e68   rsp: ffff830179407e00   r8:  ffff82c00023b000
(XEN) r9:  ffff830179413c40   r10: 0000000000000000   r11: 0000000000000200
(XEN) r12: ffff83010483d000  r13: ffff830179407ef8   r14: 0000000000000000
(XEN) r15: 0000000000000000   cr0: 0000000080050033   cr4: 00000000003526e0
(XEN) cr3: 000000010498f000   cr2: 0000000000000000
(XEN) fsb: 0000000000000000   gsb: 0000000000000000   gss: 0000000000000000
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen code around <ffff82d0402ae2b8> (nvmx_handle_vmx_insn+0x7ab/0xccb):
(XEN)  75 b0 0f 86 12 05 00 00 <81> 08 00 00 00 80 41 8b 84 24 f4 05 00 00 80 cc
(XEN) Xen stack trace from rsp=ffff830179407e00:
(XEN)    ffff83010483d000 000000000011e000 0000000000000000 0000000000000000
(XEN)    ffff82d0402bfc4a 0000000100000000 0000000000119fa8 ffff82d000000008
(XEN)    ffff830100000006 ffff830179407ef8 0000000000000015 ffff83010483d000
(XEN)    0000000000000000 ffff830179407ee8 ffff82d0402a9a19 ffff82d04020361b
(XEN)    0000000000000000 0000000000000000 0000000000000000 ffff830100997000
(XEN)    ffff82d040203615 ffff82d04020361b ffff82d040203615 ffff82d04020361b
(XEN)    ffff83010483d000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 00007cfe86bf80e7 ffff82d040203673 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000001
(XEN)    0000000000000000 0000000000000000 0000000000000043 000000000000007b
(XEN)    0000000000000043 0000000000000000 0000000000000000 0000000011e57e00
(XEN)    0000000000000000 0000000000000000 0000beef0000beef 0000000000103fa2
(XEN)    000000bf0000beef 0000000000000046 0000000000119fa0 000000000000beef
(XEN)    000000000000beef 000000000000beef 000000000000beef 000000000000beef
(XEN)    0000e01000000001 ffff83010483d000 0000003136627000 00000000003526e0
(XEN)    0000000000000000 0000000000000000 0000000300000001 0000004e00000003
(XEN) Xen call trace:
(XEN)    [<ffff82d0402ae2b8>] R nvmx_handle_vmx_insn+0x7ab/0xccb
(XEN)    [<ffff82d0402a9a19>] F vmx_vmexit_handler+0xd97/0x1e14
(XEN)    [<ffff82d040203673>] F vmx_asm_vmexit_handler+0x103/0x220
(XEN)
(XEN) Pagetable walk from 0000000000000000:

(XEN)  L4[0x000] = 0000000000000000 ffffffffffffffff

Where nvmx_handle_vmx_insn+0x7ab/0xccb resolves to xen/arch/x86/hvm/vmx/vvmx.c:1169
Specifically, in nvmx_handle_vmptrld we have:

1830    if ( cpu_has_vmx_vmcs_shadowing )
1831        nvmx_set_vmcs_pointer(v, nvcpu->nv_vvmcx);

Which is reachable with nvcpu->nv_vvmcx untouched in the case of the p2m mapping for gpa not being writable (see lines 1793 - 1827) .
Therefore, nvcpu->nv_vvmcx will remain NULL (as initialized in nvmx_vcpu_initialize).
Further, inside nvmx_set_vmcs_pointer:

1164    static void nvmx_set_vmcs_pointer(struct vcpu *v, struct vmcs_struct *vvmcs)
1165    {
1166        paddr_t vvmcs_maddr = v->arch.hvm.vmx.vmcs_shadow_maddr;
1167
1168        __vmpclear(vvmcs_maddr);
1169        vvmcs->vmcs_revision_id |= VMCS_RID_TYPE_MASK;
1170        /* ... */

will then dereference vvmcs, which is NULL.


      

        
This is possible when:

 1. The malicious domain has nested HVM capabilities.
 2. The CPU is running on top of VMX and supports shadow VMCS.

To trigger the bug, the domain must first enable VMX operation for 
itself, execute VMXON and then finally execute VMPTRLD on a guest 
physical address that is backed by a non-writable p2m mapping.
In `nvmx_handle_vmptrld`, after attempting to map the nested VMCS, Xen 
will check whether or not this mapping is suitable for writing and if 
not immediately unmap the nested VMCS again and abort the setup of 
`nvcpu->nv_vvmcx`. However, Xen at this point erroneously continues 
emulation of the VMPTRLD. In particular, if VMCS shadowing is available, 
Xen will nonetheless attempt to link up the nested VMCS to its own VMCS 
in `nvmx_set_vmcs_pointer`. Importantly, Xen here attempts to 
dereference the presumably mapped nested VMCS (which now is merely a 
NULL pointer) in order to mark it as a shadow VMCS by applying the 
`VMCS_RID_TYPE_MASK` to its revision identifier. Following, the page 
fault handler will panic Xen.

I've attached an XTF reproducer that triggers the bug. To setup such a 
non-writable p2m mapping for the malicious VMCS, I first setup an 
appropriate grant table entry. I've tested it on Xen version 4.20.0.


      

      
I expect this to not work anymore on current staging or 4.20.1-pre.
See a8325f981ce4 ("x86/P2M: synchronize fast and slow paths of
p2m_get_page_from_gfn()").

    

    On first glance I don't see how that would impact the type of the
    established p2m mapping.

    If you want I can compile staging and test if the PoC does not work
    there anymore.
    

      



      

        
To fix the issue I believe the following patch should be suitable:

--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -1817,7 +1817,9 @@ static int nvmx_handle_vmptrld(struct 
cpu_user_regs *regs)
              else
              {
                  hvm_unmap_guest_frame(vvmcx, 1);
-                vvmcx = NULL;
+                vmfail(regs, VMX_INSN_VMPTRLD_INVALID_PHYADDR);
+
+                return X86EMUL_OKAY;
              }
          }
          else

The VMX error AFAICT does not strictly adhere to the Intel SDM, but 
providing the guest some indication on what went wrong is likely more 
sensible than silently failing.


      

      
Giving the guest some indication is certainly right. If we want to follow
the above route, I think the change would want doing a little differently,
to take the path that presently is the "else" at the bottom of the hunk
above. However, I can't presently see how invoking vmfail() would make a
difference as to the subsequent NULL deref: The guest could continue the
same irrespective of the failure. Hence why I'd like to understand what
NULL deref you did observe. (We may hence need two patches - one along
the above lines, and another one dealing with the NULL issue.)

    

    

    
The issue is really just in the latter part of nvmx_handle_vmptrld, which attempts to
      initialize its shadow VMCS even though establishing a mapping for
      the nested VMCS failed.

      An early exit from that function (as my patch suggests) should be
      sufficient for that case.

      Other parts of the nested VMX code already check for a valid
      nested VMCS via vvmcx_valid. There
      simply isn't such a check here presumably because the assumption
      was that any previous errors in mapping the nested VMCS were
      already handled by returning from the function or jumping to the out label.

    
Best,

      Manuel

  


--------------1EvWbjWPzA6lFP0fbfCwHvBg--


From xen-devel-bounces@lists.xenproject.org Mon Jun 02 15:09:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 15:09:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003585.1383153 (Exim 4.92)
	(envelope-from )
	id 1uM6nK-0006gd-4O; Mon, 02 Jun 2025 15:09:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003585.1383153; Mon, 02 Jun 2025 15:09: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 1uM6nK-0006gW-1S; Mon, 02 Jun 2025 15:09:46 +0000
Received: by outflank-mailman (input) for mailman id 1003585;
 Mon, 02 Jun 2025 15:09: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 1uM6nI-0006gF-I8
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 15:09:44 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20619.outbound.protection.outlook.com
 [2a01:111:f403:2417::619])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9cc6ca7a-3fc3-11f0-a300-13f23c93f187;
 Mon, 02 Jun 2025 17:09:43 +0200 (CEST)
Received: from MN2PR11CA0018.namprd11.prod.outlook.com (2603:10b6:208:23b::23)
 by CY5PR12MB6227.namprd12.prod.outlook.com (2603:10b6:930:21::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Mon, 2 Jun
 2025 15:09:39 +0000
Received: from BN1PEPF0000468A.namprd05.prod.outlook.com
 (2603:10b6:208:23b:cafe::1f) by MN2PR11CA0018.outlook.office365.com
 (2603:10b6:208:23b::23) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.31 via Frontend Transport; Mon,
 2 Jun 2025 15:09:39 +0000
Received: from SATLEXMB04.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.8792.29 via Frontend Transport; Mon, 2 Jun 2025 15:09:38 +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; Mon, 2 Jun
 2025 10:09:38 -0500
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 Jun
 2025 10:09:38 -0500
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; Mon, 2 Jun 2025 10:09:37 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9cc6ca7a-3fc3-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ZRZRgSAPrbhG0HCC3nAJnpJCtpuwVtdJiGv33WoufjT/q0giE32mddzjUdAUKK0u9yaZ7gbFAu9u/Mwh2ILB0uvQXMLTDJtGvDCdj77wyKB6q/0U0XtUWRy3ZLvLzxSMuussX4Akdwt5d92lfeDY614VeKPxiXmti3TzKhoXT1wvKxHmiq1QDfKkxGNJeNr2Op+DlSO/7aaErLT0aF9k4GphvHD3ergRTP7fPMaAf8zq7N5+vvJh/xWv3Ay+w/ILC0EkJWFDL27L/2/t4dPCr1N7wXbeoVeZCWSbkIZ22x/q/dXmtcNrLlZI2EqHBW7f97Fz92aeka4KZfAGgcAT5w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=twEqUavFV+a5GkK6oudUB5yohK7XtyF83wD0kvr1NWk=;
 b=FkJjLeRGFjxfeYDweEyEad7dJq9IRXrB6WmYVj+Ng8Sfezj6cKlFmFDRjOqcq0LiTr3DX7DIZpyRAkjZADhUe0pvFyfjQmHMqyShfMUWOocb2rdRoJMJjsoro2xCtJDMEoYjbJTItLMmQEqipbdGXNhmAeVsbX1CwdSKrXCPaRModl80ajjqg4O+/rU06uFUWGuj2pPDLrz+HdErumOqzV5wMe3HR8basPpQEZXOc/0/xlO9+eQcVxCbC3OgJ4P4bRxInd0NSRz2EwQkTlSjrZQev/UXwMh59eJERjQ/B5AKKEgbP5/2YmVeGkg5QlZ5u2aL8KGFzeOqP1IAKu1aEw==
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=twEqUavFV+a5GkK6oudUB5yohK7XtyF83wD0kvr1NWk=;
 b=LZ8C1fP1spllQwanyI5wVW/H5Niuogh5HPVW/UKJyJ2Ki1/nm2+unUPK0sV+jotyx5p1tLxMnCDwj+fx3Awmyb4ezkvAbdvpfmNrjzQpmcLOno0c/IuPgLnB3ZCu0iteGtzdYqYzVwMa9uKE+amkR3BFPbXgIDZ25p9eu83Y6g0=
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 , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Anthony PERARD 
Subject: [PATCH] tests/vpci: Use $(CC) instead of $(HOSTCC)
Date: Mon, 2 Jun 2025 17:09:29 +0200
Message-ID: <20250602150929.10679-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: BN1PEPF0000468A:EE_|CY5PR12MB6227:EE_
X-MS-Office365-Filtering-Correlation-Id: 7ed29135-86f6-41f7-8585-08dda1e77e98
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?80IY62AVazCjmmUFIB/sTTVaM7hgyqOrxlrIx0qYwwujnPF2v3eMiWGwWKgr?=
 =?us-ascii?Q?OMnHUOOs/y2/Bnn3nEDcnssGDORIYfgQ5zSvcjuQzD/No2kq6y/p6iJHE8Lp?=
 =?us-ascii?Q?rYe+U57u8J1ygFHAcj6vFhV+937mbKP0M04B9ZsfC8+/fvoxbnDNFX0meGbA?=
 =?us-ascii?Q?eTJGBuOyBeU+S4tW0m6RjzBaR9BOXDmXQ+3QeCB39ru3VmXu67inNcWclxzW?=
 =?us-ascii?Q?NAHBjsUH3IOVz49qVVPTtf4mkKi4fRe/pg4oBqhKRHZre4napUADm2NzZr40?=
 =?us-ascii?Q?7jkC3Q9/4ZgPZbkx4QaOmPjoZ6AYhy2z8HljvQ8p3q/2sLN0JfHtgIRJi+eQ?=
 =?us-ascii?Q?e1D3Y37mAa5P7qJV2Rs214Bd9f3mi8Mm5+TU3eKr21SmDyZoByNRyvIqA42N?=
 =?us-ascii?Q?tVp/OngE4rwe8n8Bwa1dNmkPa3OPZAo7simvnsOAjRUx5JycVchnCA0P81Ja?=
 =?us-ascii?Q?RhJxNzSOIS7Aa4PID+Vm62RuoK6vcZDoQKjHdUWtnJzyC3tm/Q1U15W53ZOb?=
 =?us-ascii?Q?8yQl9c5Fpejb6x2TWyKk9TFs30g5i8nZ1uZOg5tH9G2rFS9nncH8LANzseLO?=
 =?us-ascii?Q?P9r1fEjfgwYSBuDWGr7Oza/QS8te4+lg/MkDRN2vcVVy/9pIqrXgM0O4ZC/Z?=
 =?us-ascii?Q?IgLH86QVrsevnKkqNjEBbgIkX8qDkEaJ1/6B76wNjJG9urn4z74+Ob/aAdMs?=
 =?us-ascii?Q?N/23SDp5miDCbqTxdFrvbPXAr65fTSwejoCqo0NuO5DE17C6skDKJexuvoVM?=
 =?us-ascii?Q?RHoP8gfxJunQ/aPkLxbGJbejtbABR3I4PuZV36yDpKASfpzezwmM46b8LuRg?=
 =?us-ascii?Q?FHnqZR4VeflJ0TwUeZDYG7FvZf57MIzYLTVXasH7egj/i+KZlNbvME5Qwuls?=
 =?us-ascii?Q?15Qcd2Pu8gr3ECKYzJvBUQbqE4n9lzWTqOgVRhu/B21lMPaQj8+pNZlZLEVS?=
 =?us-ascii?Q?BLqoZ+Yih8FvWjjJI9NaN4hjGSK4yLNhTN899LJxXTnGQjoigxdKykAfnrFf?=
 =?us-ascii?Q?1z/erFxwpO1aZzXEzlIePbvD+0XSMTG8COR9BNhhvNt05n74c+ew3z46/e4k?=
 =?us-ascii?Q?WeuokiyeH3smC12LwHo6sH5reTMopAP+Dw+FWVDkexz1UuYD24HMU6xxFrsT?=
 =?us-ascii?Q?qpH056AqqJ1AucDjUxX4u3bTAXBgl/2UiWGtSHTqLJl2cgHTtLODiCUyw1YV?=
 =?us-ascii?Q?a4/id29idgyRYxIa8Bdb46lE+3wX6/GxRnMtok2zpjEFl8wqnczxkQBJHSod?=
 =?us-ascii?Q?foQiMCpFcw4tj/QYYbbHuc94FgT6wcgT49dPyUOS03ON4qmcQ0KrfWuex7IU?=
 =?us-ascii?Q?O0J0JB7sWsKXXF56ouHpWF4sj9ELpKpU9FRwrREy8PzhmVnR7LCXfKXj5tQP?=
 =?us-ascii?Q?mpTzzgtNsbexe0nHaClzLTN06qL7gU8rqs+dmVbXtYlK8lSo7kNQSNRsHxuz?=
 =?us-ascii?Q?FqqcZdclXoVBZYOYgONqh5qWDU/+X6u9E1dSmwScHGcrrWwvQAzdn3FzlApn?=
 =?us-ascii?Q?B2MKGCwQ6D0yMu2+DKaJe66eawhuul7+R1zS?=
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: 02 Jun 2025 15:09:38.9451
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7ed29135-86f6-41f7-8585-08dda1e77e98
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:
	BN1PEPF0000468A.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR12MB6227

These tests are supposed to run on target. HOSTCC can be different than
CC (when cross-compiling). At the moment, tests installation would put
a binary of a wrong format in the destdir.

Fixes: e90580f25bd7 ("vpci: introduce basic handlers to trap accesses to the PCI config space")
Signed-off-by: Michal Orzel 
---
 tools/tests/vpci/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/tests/vpci/Makefile b/tools/tests/vpci/Makefile
index 9450f7593a41..1101a669e118 100644
--- a/tools/tests/vpci/Makefile
+++ b/tools/tests/vpci/Makefile
@@ -11,7 +11,7 @@ run: $(TARGET)
 	./$(TARGET)
 
 $(TARGET): vpci.c vpci.h list.h main.c emul.h
-	$(HOSTCC) $(CFLAGS_xeninclude) -g -o $@ vpci.c main.c
+	$(CC) $(CFLAGS_xeninclude) -g -o $@ vpci.c main.c
 
 .PHONY: clean
 clean:
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Mon Jun 02 15:23:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 15:23:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003592.1383164 (Exim 4.92)
	(envelope-from )
	id 1uM709-0001aU-8S; Mon, 02 Jun 2025 15:23:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003592.1383164; Mon, 02 Jun 2025 15:23: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 1uM709-0001aN-4q; Mon, 02 Jun 2025 15:23:01 +0000
Received: by outflank-mailman (input) for mailman id 1003592;
 Mon, 02 Jun 2025 15:22: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 1uM707-0001aH-7k
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 15:22:59 +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 752085cd-3fc5-11f0-b894-0df219b8e170;
 Mon, 02 Jun 2025 17:22:55 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-442eb5d143eso45465725e9.0
 for ; Mon, 02 Jun 2025 08:22:55 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3124e29f84csm6318452a91.5.2025.06.02.08.22.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 02 Jun 2025 08:22:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 752085cd-3fc5-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1748877775; x=1749482575; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=mIWxW7FaHgRT0LbhrqLQkU7C0b4uzof8dnhIxka71wA=;
        b=GPkIUW93wTTEg3eJ14C1t879oryRCj4iCpLFMsrlFKZvAkp6jrLPkoUo7etrXd4Lmb
         X0QIZoklPVQ92rPnzfoJdkUHRf+W06H5ibMSSzKxe5UdwQxHOunZDlmNzMUaSVXBe1z1
         r0a0utSFOi4OoKQu5BwLr+pwc4I6NxYWx+FZJUUBya6d8cDqZJAmbinV3ykOtKrznOoJ
         p/48562mrzPpuSk/lx+Fvqx4zu5GqPUEZZkLhBNBV3w164DVwVZc8ZYCvj05/s89HsOu
         Y6qD4XKxwGeID+EXRPDGOv8Mh+TWdZl/x6cjd3N/irkmjImwlGUDo1bI1sUTckoXBN6c
         IO1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748877775; x=1749482575;
        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=mIWxW7FaHgRT0LbhrqLQkU7C0b4uzof8dnhIxka71wA=;
        b=itaOkZhzfe6v8/PgsxvztkAMS3FXlgqCnASwxzbWaAR3l72Ch8FiojwIToiSarYw8M
         gEFSVZUbFH6lf3O1o2KM8hllNr74Gb0glmRxpcAoTohR2K3ku7BnwUpUSioZEytmOhIq
         gRT+K666FceSLJ0XupWLvFTqnrtO4fQEF6yFz2SwqLHYX4qnvEZApyy/0br8IXlZnDm4
         eUtNIOBU+Zsh/vI/uF5CkzOMKS3AyoOIoP/lo4I51yMVXDTj33CNzoXR3mR+ITdDFDt+
         tQvCfi5S5XDtsR4KWOF1FYpbZIWZiOqVsJ/lMJ2UiLLiaXSbDTd6RIn1Gk5Bo+OIk4Xv
         qs5g==
X-Forwarded-Encrypted: i=1; AJvYcCX+GKb/Wx+HDVqWDrX/Y/Rlze/7UlCqpMhgYbqfzn6YZXP4/zJiMesqD1vVrXuTPh/wOHuzqu5qmv4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx+yzX37rcRvKdTl9pJmWRkQtEYQRyvcGGGDNk49Zm844aru6KT
	VhXtR28JKJlSy0e1mggwV0hKT03kOSSqw+v5KyxW2/E7pH++JGx26aY1+7w/HghHsA==
X-Gm-Gg: ASbGncuBZZpYEGGzwZpJTU1eNSsknSsNp8jYyndqu9KQd0GoK/leT3+KajJOIyRS93L
	gsNXQH7xMC6AU2BXUKknzMTDOlUEyWNwyMOMlYCoCRMcJCJu4LVEjv2ns/EamjhmNsxqmaTgBjj
	JtYWwTMSlMM5nOOGoTfMtgEi1PIR+oi+P3iGHfKRfGhCECWvDiFTjII5kV+xZzH9zMoEwjVEw13
	00tg8fyhIyUwusqAqig8iTxvENeFE/c6lzCEjnpZ+O+aM1b5XAHxJrDhehGFFF2MYlnbSfJ31oQ
	yzMqt7nbxQkoHtWSZBydh+Elagb0uqt1mL3I17J6Hwmm0UP4zme8Aiplgz6S6+vRwM10EeoIQBO
	Kli5QHs550bqKAwv6An2UWKPyk3aNbTpvlOS+
X-Google-Smtp-Source: AGHT+IE7IMR7mC43NKOjETRkUGKmmXP2RPSgM816IzEY5wbF8fmd7EzzOTi3A0aavKBYuerge6zZ7g==
X-Received: by 2002:a05:6000:4013:b0:3a4:edf6:566b with SMTP id ffacd0b85a97d-3a4fe160d10mr6287268f8f.6.1748877774921;
        Mon, 02 Jun 2025 08:22:54 -0700 (PDT)
Message-ID: <37819f9d-8438-4d41-8df3-62c25eb2a18e@suse.com>
Date: Mon, 2 Jun 2025 17:22:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/hvmloader: don't set xenpci MMIO BAR as UC in MTRR
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Anthoine Bourgeois ,
 xen-devel@lists.xenproject.org
References: <20250530092314.27306-1-roger.pau@citrix.com>
 <58c0499c-cdde-4cc3-9441-606a0eea4652@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 02.06.2025 16:27, Roger Pau Monné wrote:
> On Mon, Jun 02, 2025 at 11:46:52AM +0200, Jan Beulich wrote:
>> On 30.05.2025 11:23, Roger Pau Monne wrote:
>>> The Xen PCI device (vendor ID 0x5853) exposed to x86 HVM guests doesn't
>>> have the functionality of a traditional PCI device.  The exposed MIO BAR is
>>> used by some guests (including Linux) as a safe place to map foreign
>>> memory, including the grant table itself.
>>>
>>> Traditionally BARs from devices have the uncacheable (UC) cache attribute
>>> from the MTRR, to ensure correct functionality of such devices.  hvmloader
>>> mimics this behaviour and sets the MTRR attributes of both the low and high
>>> PCI MMIO windows (where BARs of PCI devices reside) as UC in MTRR.
>>>
>>> This however causes performance issues for the users of the Xen PCI device
>>> BAR, as for the purposes of mapping remote memory there's no need to use
>>> the UC attribute.  On Intel systems this is worked around by using iPAT,
>>> that allows the hypervisor to force the effective cache attribute of a p2m
>>> entry regardless of the guest PAT value.  AMD however doesn't have an
>>> equivalent of iPAT, and guest PAT values are always considered.
>>>
>>> Linux commit:
>>>
>>> 41925b105e34 xen: replace xen_remap() with memremap()
>>>
>>> Attempted to mitigate this by forcing mappings of the grant-table to use
>>> the write-back (WB) cache attribute.  However Linux memremap() takes MTRRs
>>> into account to calculate which PAT type to use, and seeing the MTRR cache
>>> attribute for the region being UC the PAT also ends up as UC, regardless of
>>> the caller having requested WB.
>>>
>>> As a workaround to allow current Linux to map the grant-table as WB using
>>> memremap() special case the Xen PCI device BAR in hvmloader and don't set
>>> its cache attribute as UC.
>>
>> Can we (fully compatibly) make such a change? IOW do we know all possible
>> guests would be at least unaffected (ideally affected positively)? Imo ...
> 
> Is there any other possible usage for the xenpci MMIO BAR?

How do you / we know?

>  My
> understanding is it was introduced for this specific purpose; to
> signal a safe place to map the grant-table or foreign mappings, which
> in both cases want to have an effective WB cache attribute.

It's a hack. It's relatively easy to imagine that someone might have built
a 2nd hack on top of this 1st one.

>>>  Such workaround in hvmloader should also be
>>> paired with a fix for Linux so it attempts to change the MTRR of the Xen
>>> PCI device BAR to WB by itself.
>>>
>>> Overall, the long term solution would be to provide the guest with a safe
>>> range in the guest physical address space where mappings to foreign pages
>>> can be created.
>>
>> ... this is the only viable path.
> 
> I agree, however this will take more time to materialize IMO.  Needs a
> patch to Linux, plus possible backports, and then distros picking the
> updates.
> 
> While I agree this needs fixing in Linux, I don't see any downsides of
> doing the workaround in hvmloader also, as a faster way to get it
> deployed with just a Xen update.

The (maybe merely theoretical) downside is that we may regress something
somewhere. Hence why I think that for starters this new behavior should
be optional, default off. Later, once proven to work in practice for a
fair while, we could then consider changing the default. (Then again I
certainly realize that adding yet another control is quite a bit of extra
effort, too.)

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 02 15:23:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 15:23:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003593.1383175 (Exim 4.92)
	(envelope-from )
	id 1uM70I-0001q4-GO; Mon, 02 Jun 2025 15:23:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003593.1383175; Mon, 02 Jun 2025 15:23:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uM70I-0001px-Bw; Mon, 02 Jun 2025 15:23:10 +0000
Received: by outflank-mailman (input) for mailman id 1003593;
 Mon, 02 Jun 2025 15:23: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 1uM70G-0001p9-9r
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 15:23:08 +0000
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com
 [2a00:1450:4864:20::22f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7bd82d18-3fc5-11f0-a300-13f23c93f187;
 Mon, 02 Jun 2025 17:23:06 +0200 (CEST)
Received: by mail-lj1-x22f.google.com with SMTP id
 38308e7fff4ca-32a6f5cb6f9so22596151fa.2
 for ; Mon, 02 Jun 2025 08:23:06 -0700 (PDT)
Received: from gmail.com (213-67-3-247-no600.tbcn.telia.com. [213.67.3.247])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-32a85b337absm15211891fa.26.2025.06.02.08.23.05
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 02 Jun 2025 08:23:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7bd82d18-3fc5-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748877786; x=1749482586; darn=lists.xenproject.org;
        h=user-agent: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=5F5eVUrYkyhLcTB2TJWM26UTa/yIJkoh7wyIMTrpq3s=;
        b=Sa0NciF33VF5cYIxGYqzpGOnlCGhgrzCPuvI59NQVt8bkDVTiIj7HBGwtc4XLpY1hA
         wDP+b2Gni+u7KE1w/jsq9zFdZVMEqG1YHbSdaqZnyX92Gtb5rCsYmbEuSX96vAU+cGFX
         Q6ahANz0tHpkqeUsi751NHJ8Tlvl2GZp/83dXQ4PdP0PbDKE+zC+GQwuxJwaKcz9SRGf
         BF27eTp7o9QXsDISCJ1/Rq4FWaWatQl3jwti0o6TzGwOKjz2HV+7TXlhLNYyOVsSIqy3
         dDsHHVfM9dkSSvxUh8tX+xWIdiuCn6fQmtcwnUsVyaf9ypQwXPA/BzvjcME97Sg4rXYQ
         bEDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748877786; x=1749482586;
        h=user-agent: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=5F5eVUrYkyhLcTB2TJWM26UTa/yIJkoh7wyIMTrpq3s=;
        b=s+aagkf384I1q3NPBWCHw9BE5ieqzaIOpnL9XAXL0QDVF4Iajqthvg4iJp9X1MzjUj
         a4hE8cBQHSNL6Ky3G2UE4WWFh0m7W0cRKtTjG+nxOMKs26GWkRsej8bo1nbhnl/R5ViM
         VHyuhuClF4tHayzDCvnjBLyyS0yVIiLosu5Bw5UC4G+5yYxmnL3PvAX5/gq351adlW3V
         200q/w99m9ye4J6sqUsCQLfSX+TM8WCFEHKpfdmCL+6fWcIl5ctbXH22LC/Q11HTGERI
         Vdv5N7a3CMvFinylU/P7dEa9lMph0fmABzlWxk+anoervBQryDn/Zg1sOy8DwJ7pRyVf
         yxIg==
X-Forwarded-Encrypted: i=1; AJvYcCXPLM5R24qK0QAENVrNvV47jq3kndroxMrKmrphkARz3SOPcTpp+j1oGc/I6aN8NrvD8hTOUud8p1E=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzW04sdHRRcWyrWNV5d67MYsa4BcNvs21GhnL71/AY9kUsyS2Cj
	n8sDYrfhmI74I/ePJaOZVz/MHXffO6KcKUX4AkzIK9gFv0/8QTgZXtmS
X-Gm-Gg: ASbGnct+Edt5WkHOcPvvsDRZy5n5j7zKWzN4SZ/6+mPb025JyZ1s3uHr97pa1R0OoiI
	CKv5+n3aA3TNEVL5BmYyVEZ4i0JAAGjCtEVrOfCZI2XFZxqRk0ITO3dR4Avazu4xhd/LHHsDJCD
	evOeHxX1J77i2g355Dz56XG9nxFrWpCNj8iCCTKtx6Aroqj/5xO7H27iQYtTfmspRxVKpV83JdG
	+I7FJeUl+HGdKhseH0ttn75yk57KuxMqhaK9SZa3ttseXw0LdIHqedplhi27xgSu3HE/Vlgcus1
	o0/F0/oGezvjaCKk/1GzMvUrI+BJK6jbrShwkSafI3mY4i7K7qk3r+oo/IhKHnLHT9kRH8oBywM
	Xcc5xYgaIwAb/CM7w2oXYD/k=
X-Google-Smtp-Source: AGHT+IFkiAoB2M7nK9lhfiIC9rbpVEThHExxCNd1GPIWrv/AbF1SdDBnKgG+gc9uRNGy9AR2nQoFkw==
X-Received: by 2002:a05:651c:220d:b0:32a:7122:58c9 with SMTP id 38308e7fff4ca-32a9e99b732mr18989151fa.5.1748877786054;
        Mon, 02 Jun 2025 08:23:06 -0700 (PDT)
Date: Mon, 2 Jun 2025 17:23:05 +0200
From: "Edgar E. Iglesias" 
To: Jan Beulich 
Cc: sstabellini@kernel.org, julien@xen.org, bertrand.marquis@arm.com,
	michal.orzel@amd.com, Volodymyr_Babchuk@epam.com,
	andrew.cooper3@citrix.com, edgar.iglesias@amd.com,
	Anthony PERARD ,
	Juergen Gross ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 1/5] xen/arm: Add way to disable traps on accesses to
 unmapped addresses
Message-ID: 
References: <20250530134559.1434255-1-edgar.iglesias@gmail.com>
 <20250530134559.1434255-2-edgar.iglesias@gmail.com>
 <4cd82cbb-fc01-425d-b036-62f80a027a9b@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4cd82cbb-fc01-425d-b036-62f80a027a9b@suse.com>
User-Agent: Mutt/2.2.14+84 (2efcabc4) (2025-03-23)

On Mon, Jun 02, 2025 at 10:45:36AM +0200, Jan Beulich wrote:
> On 30.05.2025 15:45, Edgar E. Iglesias wrote:
> > --- a/xen/common/domain.c
> > +++ b/xen/common/domain.c
> > @@ -721,7 +721,8 @@ static int sanitise_domain_config(struct xen_domctl_createdomain *config)
> >           ~(XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap |
> >             XEN_DOMCTL_CDF_s3_integrity | XEN_DOMCTL_CDF_oos_off |
> >             XEN_DOMCTL_CDF_xs_domain | XEN_DOMCTL_CDF_iommu |
> > -           XEN_DOMCTL_CDF_nested_virt | XEN_DOMCTL_CDF_vpmu) )
> > +           XEN_DOMCTL_CDF_nested_virt | XEN_DOMCTL_CDF_vpmu |
> > +           XEN_DOMCTL_CDF_trap_unmapped_accesses) )
> >      {
> >          dprintk(XENLOG_INFO, "Unknown CDF flags %#x\n", config->flags);
> >          return -EINVAL;
> > --- a/xen/include/public/domctl.h
> > +++ b/xen/include/public/domctl.h
> > @@ -66,9 +66,11 @@ struct xen_domctl_createdomain {
> >  #define XEN_DOMCTL_CDF_nested_virt    (1U << _XEN_DOMCTL_CDF_nested_virt)
> >  /* Should we expose the vPMU to the guest? */
> >  #define XEN_DOMCTL_CDF_vpmu           (1U << 7)
> > +/* Should we trap guest accesses to unmapped addresses? */
> > +#define XEN_DOMCTL_CDF_trap_unmapped_accesses  (1U << 8)
> 
> Besides being pretty long an identifier (and that's already with "guest" not
> even in the name), if this is to be arch-independent, would this perhaps fit
> x86'es recently introduced "advanced" PVH handling of holes? See [1].
> 

Looks like the implementation of the options would be related
but trap_unmapped_accesses is intended for domU's and pf-fixup is for
dom0 IIUC, so in terms of configuration they would be different...

I'm happy to change the name of trap_unmapped_accesses if there
are better (and shorter) ideas.

Thanks,
Edgar



> Jan
> 
> [1] 104591f5dd67 ("x86/dom0: attempt to fixup p2m page-faults for PVH dom0")


From xen-devel-bounces@lists.xenproject.org Mon Jun 02 15:31:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 15:31:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003607.1383184 (Exim 4.92)
	(envelope-from )
	id 1uM78h-0003vo-9u; Mon, 02 Jun 2025 15:31:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003607.1383184; Mon, 02 Jun 2025 15:31: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 1uM78h-0003vh-5k; Mon, 02 Jun 2025 15:31:51 +0000
Received: by outflank-mailman (input) for mailman id 1003607;
 Mon, 02 Jun 2025 15:31: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 1uM78g-0003va-L9
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 15:31:50 +0000
Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com
 [2607:f8b0:4864:20::1032])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b2fbf66c-3fc6-11f0-a300-13f23c93f187;
 Mon, 02 Jun 2025 17:31:49 +0200 (CEST)
Received: by mail-pj1-x1032.google.com with SMTP id
 98e67ed59e1d1-3114c943367so5019886a91.1
 for ; Mon, 02 Jun 2025 08:31:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b2fbf66c-3fc6-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1748878308; x=1749483108; 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=+BR50Vk7OBqfOang4vAqA5ASJPHaW0l0ECfLkMRTLdQ=;
        b=PP814vTzA6oZ462nobd2yK2vaRaOsOzrb1P82ulEHqIBEW/7E8An8fAG+9BeFEchJl
         gKfS7IYQGT1AQ2K8KwQU/tojV+885W/ixIF4JJA/0u1eIYSTVYtT1prQF1Hwvi8iCS3z
         bshwKb2dKPpH7XXhA66+6Hfguv18tF5PLO/lw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748878308; x=1749483108;
        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=+BR50Vk7OBqfOang4vAqA5ASJPHaW0l0ECfLkMRTLdQ=;
        b=gJfJjO0cFNCQsB9PKMowFZFzrX8+UBNMn0LUWh6MNcF58kl5XTBrZ1K3UbNOqGu0Eh
         bQ3TxbXBVVZAMh0jkjcoJ2MN2Oj4esZ+XZ6NA8rswP3aseuicHcAZSKSnx9AsTv06Z4Z
         curPY6Y+exokeRkuzXb5rPVTuS1huD1NQ1xJmHkE42D9J7/9U9FT54xF1BPB/rQf8V+g
         PIJGskz8uj5vpOx7O4nB/k20ihccCqqAuWaLx+f7TE6sUJYtETSAFFpgw+nc+7GvBl7+
         hQf5Q+pOy1PjKFrMjzd44cE//Ulw348+ESofu2qRi/+R1i3IwgAHMepWgpZE+z9DK8mx
         sMTg==
X-Gm-Message-State: AOJu0YwwCHAOVKDfj0eZkkHF5HBU8Box4ZEovKUgTl/uPlJ9PzOrHdgE
	ZaQwDmKaUHFYgpI4JOlC51gb+ZrJhzhzGMIw05OpRF6uiI60eJHApX8fHM8dgL7FmuOUCAqufSm
	Mid79qdG+qjJQm2XUtqXIx+A6ldjl95mME6wWVWgu8Q==
X-Gm-Gg: ASbGnct+f0/RgqyH5uS5kmz2pPjXhqQAoisEtjQsz4Worxcn0TdF8tIT5C1Yi6IyyDV
	WOXHIGmiOGV4c9U5qjYnaqv8O6ypzatyf5k7qYElIuevFvEBw9HdRXFRFdEiIheb8TLvWAQ250Y
	7/0cTtCbrVdpAG7OHe0XC1oJsh7NNqy7rjHxi1MNeKVw==
X-Google-Smtp-Source: AGHT+IHjyZxS49KclLfVu+pnSK4pBZMtAWZh4p2HnOgaZy0loFpLddenjBWZrepvKJ4oUxq6JQH5WUyUP6V189+pqhg=
X-Received: by 2002:a17:90a:da87:b0:311:9e59:7aba with SMTP id
 98e67ed59e1d1-31250344814mr20495985a91.2.1748878307404; Mon, 02 Jun 2025
 08:31:47 -0700 (PDT)
MIME-Version: 1.0
References: <20250602134656.3836280-1-kevin.lampis@cloud.com>
 <20250602134656.3836280-3-kevin.lampis@cloud.com> 
In-Reply-To: 
From: Kevin Lampis 
Date: Mon, 2 Jun 2025 16:31:35 +0100
X-Gm-Features: AX0GCFtTFYl7D4Qu4yVJMghy2z5WJHSdtv7us-Sahj7v6AzEkVnnGPUsWSFXYY8
Message-ID: 
Subject: Re: [PATCH v2 2/3] Add lockdown mode
To: =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= 
Cc: xen-devel@lists.xenproject.org, Ross Lagerwall 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 2, 2025 at 3:20=E2=80=AFPM Marek Marczykowski-G=C3=B3recki
 wrote:
>
> This is rather inconsistent with other bool options. I think you want to
> use parse_bool() here.

Thank you. I will use that instead.


From xen-devel-bounces@lists.xenproject.org Mon Jun 02 15:36:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 15:36:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003616.1383194 (Exim 4.92)
	(envelope-from )
	id 1uM7D0-0004dJ-Sh; Mon, 02 Jun 2025 15:36:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003616.1383194; Mon, 02 Jun 2025 15:36:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uM7D0-0004dC-Or; Mon, 02 Jun 2025 15:36:18 +0000
Received: by outflank-mailman (input) for mailman id 1003616;
 Mon, 02 Jun 2025 15:36:17 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uM7Cz-0004d6-6Z
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 15:36:17 +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 524226e5-3fc7-11f0-a300-13f23c93f187;
 Mon, 02 Jun 2025 17:36:16 +0200 (CEST)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-451d3f72391so22587545e9.3
 for ; Mon, 02 Jun 2025 08:36:16 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-450d7fa21e4sm130240605e9.11.2025.06.02.08.36.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 02 Jun 2025 08:36:15 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 524226e5-3fc7-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748878575; x=1749483375; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=t15U6LjHDsrC5DALlzvuI3GFzEPy6/MnV+dmHacy8Ww=;
        b=kB29ffzDYEQl7qV7Vc+6kyHovtbxeqxntUHNF97aKi0BzYzQuP3QrWwgizaFLtja0C
         PmkH84qIeuzm1ctkLYPycUehY8SwNSVkiM2bdcD/nbSsTue2xJVBgbHYqk3Tq8V58T5R
         Htr30RPcxpfF2aAjeyXgWpEiHQnwKUYNRukzI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748878575; x=1749483375;
        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=t15U6LjHDsrC5DALlzvuI3GFzEPy6/MnV+dmHacy8Ww=;
        b=hbTqkkkTb5pOzNBHOo+aRvdr93qNspxKIIScBGMDo/lzHss2i7p1w4cODTydFzTw8T
         gdmDIUtbopug/ny3oj01W6HqxW5dp+XGAmPliIAw1/yeErgtntH9lEnYjIm1fEWgYMEp
         n1Pbk/EJ/WwAUlfjp0b52B9VMtr+AqZbvnoF1v81msIMBHMXFoNM2ziTcM4e7e5dex+1
         Xl12gPBjndWH08Yu6kq0UoYdGfx/wDPNNLX5xjRKznaiXIABjcFRbYKkjHwwzJAlaVTb
         WXeeJVOYoVfzyxA1tW7+Rh60sTY8PDeI8HdTDwU0FhhOadcTfViYsKZa02ZxMyDFGw/d
         Cqwg==
X-Forwarded-Encrypted: i=1; AJvYcCWB5l9C/AS0xeBbJAQ5r/NAmMudCWcQv96tWF7gDtxgUVRnGYrMEYfSYocDsQ1du8YYELI6ZRGr7QA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyDsp0o+r+9V3CHblyOzfg6p6jT0jSrNxSXFOBTPGXsw2ewg+Ic
	bFUGQFAhmXktAgEOxmA7+PT4zDCsJmkhgX32askBCekBmHy2HUYEB0KN7B04cN91SVY=
X-Gm-Gg: ASbGncs9ksuwEBov0Du3XOImbJIriFMGOEozIeHBXi623L6x+X3HMlTgfuu4LrKEArR
	OjFS8Qq38qJJjJX9GjZ2G+2WUpn3fsLN9MRiwKTHIWGbEU+M7jl4YcoMIqMEfgGMlpHbuFjwNqa
	pj63FRJIKzB2eS5i8PpQT/lyd0O3vUoJbA0X8YYd1EiUJZs3UA2alcBl3IiIdc+tW87ZXPe2Nl8
	fvFFthsyd6uy+TxKYsbTf1N/D81gfetIlJaUwNnP5ijkORK2VWpdeV1WGBUNstMwAra84rfd2P5
	lwOp/PPyBGfUizUPnBw9i1l3TaBHtW/MWc3hHy+LFF4CI0ebmFzRAtkLiY8SkxlsLMCfqGwqYRC
	yj05dquPOHSnkWww9/gB6vkPmSgg=
X-Google-Smtp-Source: AGHT+IExzrvBXDMdr+vNPnjm45bvzoALfRL9vYd6djqClX+bzAnVJc15sQqZHM4DxKDAWhn6i4rCTw==
X-Received: by 2002:a05:600c:34c4:b0:450:d570:e0ee with SMTP id 5b1f17b1804b1-450d880ca1emr142851815e9.10.1748878575488;
        Mon, 02 Jun 2025 08:36:15 -0700 (PDT)
Message-ID: 
Date: Mon, 2 Jun 2025 16:36:13 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] tests/vpci: Use $(CC) instead of $(HOSTCC)
To: Michal Orzel , xen-devel@lists.xenproject.org
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD 
References: <20250602150929.10679-1-michal.orzel@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: <20250602150929.10679-1-michal.orzel@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 02/06/2025 4:09 pm, Michal Orzel wrote:
> These tests are supposed to run on target. HOSTCC can be different than
> CC (when cross-compiling). At the moment, tests installation would put
> a binary of a wrong format in the destdir.
>
> Fixes: e90580f25bd7 ("vpci: introduce basic handlers to trap accesses to the PCI config space")
> Signed-off-by: Michal Orzel 

Oh.  This didn't explode in GitlabCI because there's no ARM version of
*-tools-tests-*.

Can we fix that too please, seeing as there is a real ARM board?

Also, I guess we have to finally sort out the CC vs HOSTCC debate.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Jun 02 15:38:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 15:38:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003623.1383204 (Exim 4.92)
	(envelope-from )
	id 1uM7Ee-000591-6F; Mon, 02 Jun 2025 15:38:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003623.1383204; Mon, 02 Jun 2025 15:38:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uM7Ee-00058u-2f; Mon, 02 Jun 2025 15:38:00 +0000
Received: by outflank-mailman (input) for mailman id 1003623;
 Mon, 02 Jun 2025 15:37: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 1uM7Ec-00058g-M4
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 15:37:58 +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 8e2b451e-3fc7-11f0-a300-13f23c93f187;
 Mon, 02 Jun 2025 17:37:56 +0200 (CEST)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3a3758b122cso3070066f8f.1
 for ; Mon, 02 Jun 2025 08:37:56 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3124e2b51f5sm5750503a91.9.2025.06.02.08.37.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 02 Jun 2025 08:37:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8e2b451e-3fc7-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1748878676; x=1749483476; 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=osS3e7H1/IB8NKkOhZIrQllFgeNTqh100R+aLj5TLDE=;
        b=aAARYXUgTlrhgFw2FoeSuHprKeEX3BYxZ7uwh2eAk5NI9eLJqw9JQl/lD34S5dXjrs
         2M0C7/cM+uwtgJWoPkH1/a5NNoEEoKDj7dbJs+KqfQGCsLaVJYyHxCa1Zo2H9xg3+1h/
         u2dVseQA+At2gQQu9B40MX4jSoAyMvxoDTMMeGoVxgdAeH2MP0G9w9ZDktr1QEJK0+Ku
         b1U7hD1O2vsVohoV+LhMnBVLPH9rABdieaLNJ965S8No1pWZqxvaBwPvYEevXYdQ9cAn
         InmoT2OWc9uaXyr8PH0SuO+jIxJYqL+N0kKxZXh8VJ2VJ5a6adeBgJe5XYfe9hVi2NCQ
         t7uA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748878676; x=1749483476;
        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=osS3e7H1/IB8NKkOhZIrQllFgeNTqh100R+aLj5TLDE=;
        b=nArhGa5JnnP/uyh/Jo+FlVTDSAPvPLyyBXcc2ssubRyv9M2o8++W5iftbqxX1nOEac
         j8ewL+zEaMxseKxp/q/7fj2+X5YS2N+LaW/BjD9m3+k8KVYJ0S9v0Up4SsZ6mz3WymqI
         pP+s3CRR0lrLfBuqm9JIRq1qGdCXpg8aiZiwrLQ56K/ctXtWt29AtVM0s9b9xN+M2+hn
         /uF+kWvIA3wK5BoWZe/YNbBF4pR20pH4lyvBrJbP54sO45OteFzE7/o0C0Fm/s8J5yNF
         LL+0B/t1G9AauRnx8cx4/7SnENlX8TnUDtFWisaz1v4lC/yVtTPWiooC7TNCXW5V27/3
         wPrw==
X-Gm-Message-State: AOJu0Yy0rb9YlRiIhy3pf291sb2OBiCw/DWBsg0ItonYLC9Te3QXqxUl
	WIT5B40S3VUq53traUKpie/+WvsOQ4ejOS/N5IctLvz4hLG/C8MtTpJtnIINmipojTjWBSrrRc1
	oRHk=
X-Gm-Gg: ASbGnctxQ9hZARuVOgRjmLGzhi2vXsZYz5uqSbLmiA1UndQL9wAy8YfHe7MKoXFTJJx
	vQL2ETmuaEuIeIYDR3LXRJa6DOQQs5J3j7Ih7bCAbkID9/WDLtz5VM771qzOzjYHvw9EXyP8XMh
	enuGixVjKovcvdvkPL5LB1NhGrddbabqyQ2Ixd0cez+bIMKfacmr6ZjdOKFZdUhD4x7AhO5LuSF
	y8zeWHe7hXCJ0YCXdKi4QB6yVqx/oUMR6px0/ljr8dkqT5coRAoYxXymTRAZmTRepJIY8Pm4v8a
	5Nu0eEkYfnmaxfFBh56q1cufhOQd3khI0kMYy9NKhdYPC4LwXn/FX7F/AP7BkXgnCZKpZfOqhY1
	1QfkElQIz6Vy0ANM1yvFTlGOH4/i33iKIlMyZg/MWuw9bxmI=
X-Google-Smtp-Source: AGHT+IES5LkjEkvP+9o45D1D3ev0KmTb26x2T3mQor3D+2QQSWOQFv9eq0si0S0zkBY8NL+IYqF+5g==
X-Received: by 2002:a05:6000:18ab:b0:3a4:ea40:4d3f with SMTP id ffacd0b85a97d-3a4f7aafa70mr12745942f8f.53.1748878676067;
        Mon, 02 Jun 2025 08:37:56 -0700 (PDT)
Message-ID: <421e2f85-c1ed-4989-b8db-36e261826fa0@suse.com>
Date: Mon, 2 Jun 2025 17:37:49 +0200
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?= ,
 Manuel Andreas 
From: Jan Beulich 
Subject: [PATCH] vVMX: adjust VMPTRLD error handling
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

There are two issues there: When hvm_map_guest_frame_rw() yields a r/o
page mapping, we fail to indicate the failure to the guest, and we fall
over the NULL pointer in nvcpu->nv_vvmcx when subsequently invoking
nvmx_set_vmcs_pointer() (if no earlier VMPTRLD put in place a valid
value).

Fixes: 5dbbaa0fe121 ("x86/vvmx: fix I/O and MSR bitmaps mapping")
Reported-by: Manuel Andreas 
Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -1820,7 +1820,7 @@ static int nvmx_handle_vmptrld(struct cp
                 vvmcx = NULL;
             }
         }
-        else
+        if ( !vvmcx )
         {
             vmfail(regs, VMX_INSN_VMPTRLD_INVALID_PHYADDR);
             goto out;


From xen-devel-bounces@lists.xenproject.org Mon Jun 02 15:40:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 15:40:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003629.1383213 (Exim 4.92)
	(envelope-from )
	id 1uM7Gs-0006c7-Gx; Mon, 02 Jun 2025 15:40:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003629.1383213; Mon, 02 Jun 2025 15:40: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 1uM7Gs-0006c0-E1; Mon, 02 Jun 2025 15:40:18 +0000
Received: by outflank-mailman (input) for mailman id 1003629;
 Mon, 02 Jun 2025 15:40: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 1uM7Gq-0006br-Po
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 15:40:16 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20610.outbound.protection.outlook.com
 [2a01:111:f403:2416::610])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id df6a64e9-3fc7-11f0-b894-0df219b8e170;
 Mon, 02 Jun 2025 17:40:14 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by CH3PR12MB9078.namprd12.prod.outlook.com (2603:10b6:610:196::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.33; Mon, 2 Jun
 2025 15:40:09 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8792.034; Mon, 2 Jun 2025
 15:40: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: df6a64e9-3fc7-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=C8WkjxORBBlypN3c01ftfrIsYdD7xacScC1q1mtFbcXHGA4KbjAtA7LfYzM0HH8Q6MqzJIqYj82khT+1jmUQh5MFIxCDUPIFFh3YAVG+4MV5dAEKH1b7Eo+cp2rv2ZrWyw+FZOZd5AlC4pg525bMbhaxMEuHrmVa5BK+MwvTw0y3+QfWHwywROADqySBceZRsnXRDvECHVZ3YYherXQZLlvudYnEePgwQieblaIDF1P4TCUu9Sfigs1LeaK3Jk2moP7IthorkpeA2THEWmtn0kk0OVIQ9MxojXruH8bdfR56w3q6IGVC29pRFkO0Ci+T83XYzfi8o5dJl7ys8qYhkA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Gdy7SCFRir2oQeE1e9j4czGYajiy4okOYIPvAppi+58=;
 b=Wzo4YG5TmRE0r6Q0DPJKCa2FLICUSRsve4xkiLPo6K4ZyaudCn4NOykRNk4uB5WKn3XwavzZMMaEt1Rkigh+0YSlvb0H8OhK+oWG9NBJzYgPxIbkIkRNVUigtsSv2hub1EnUZ1VYRzvaOL2zvrWYHwIRNfCHtIFdy3WGp3NOF7Ty6C18fxmLEgd5aG/VinXaP3GwpcVLqYnM1rq5PNPOVJHJIyIJPyIsUXCA+mIBmlSMpqgyUGQVhq2ceTMRrN2h/fjrYiLct0pRgZ2cCRKL7kY32tSn+Z8b2HWckTt7UtQXQNXWd9lQGjw39Y9uFUBLsXph/LevPJqCh8GehRcuiQ==
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=Gdy7SCFRir2oQeE1e9j4czGYajiy4okOYIPvAppi+58=;
 b=dcLwz99n68VQJWRNMEIKg1z7I8XNslhUWRycdIqJplDEJPUJQZeXYFFNYRjon6irIdmqlXHPU8uznTaDmrZer9Af3eOvmFqhw44LP96cyLi9PkN7AqjHKKSyS5FLY8RzmtG6nCfucGvCsJaXIUIfD+fXwJIzfmM9/VR9S6XJiJs=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <5c58a036-2dae-4b12-97a1-e2fbafea4999@amd.com>
Date: Mon, 2 Jun 2025 17:40:01 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] tests/vpci: Use $(CC) instead of $(HOSTCC)
To: Andrew Cooper , xen-devel@lists.xenproject.org
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD 
References: <20250602150929.10679-1-michal.orzel@amd.com>
 
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: DX0P273CA0043.AREP273.PROD.OUTLOOK.COM
 (2603:1086:300:58::11) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|CH3PR12MB9078:EE_
X-MS-Office365-Filtering-Correlation-Id: 34e2741e-99cc-4863-1ccf-08dda1ebc113
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?blk1YWJKT0t1aTBNVEJ2S2orL1JrcXFVRzBjT0kyL2FkUTVzMG5sQi9NcFBr?=
 =?utf-8?B?TmZkd2lsRnhTQWlWNDRFcUxyRTRiTnFsT01lc1F6aXAzWHlBT2dXUWZpc0tK?=
 =?utf-8?B?bnZMNjZXVU5pMzZUV1NmZVJmcmtyd1gvdG5yV1FBeThMaGhRWk9CeGZqaTdC?=
 =?utf-8?B?QmNEUStlZGFybmNIZDI4RE9kbzZuSHRrTXh3U3BadlNpTHFFTFNFQmVreHdm?=
 =?utf-8?B?NEV3N1VJb3B3QUZxTytkb2hFUVlmVDFkWGNoZnlnaGpjN1hxVkt6YXgzT0JH?=
 =?utf-8?B?MitHNWF5dytwZTIwbHVRanE1c2hXVVB6dDZPM3MvQTFkQ3NIVlMybDQyOEFh?=
 =?utf-8?B?NkkvbVZ1SFBoYnpGa29qekNrTmRndmxOUWxieEk5TjgvOGx0VytONEpodk1Q?=
 =?utf-8?B?cDJFTW9vcFZHaUlNbzcxSUxPNzVUNlNjeEpJT1VEK1F0WitYUUViQnhoM1NF?=
 =?utf-8?B?QjVGb3dSYjhrTzYvMUcwMHcyUXVKbWlFWkFtZ1dqUTFGSlcxcEFhdDcvWTNP?=
 =?utf-8?B?NXRYTkJrdlNENlVBZVpqaVI0dlo5dlA3Mm9Fcm9Tc0NLV0phc2JZSlcrV3U3?=
 =?utf-8?B?V096S2FFSEJHRW0rL2ttakIyT2dMKzJVcHNEWXJ5THk5N3R6SjI4dytBYkJw?=
 =?utf-8?B?UEpkSU40dzBYV3pYUVVWS1JDanVqK2xwSE8vVDE3OHJzS0w1Z085T0M1N1hs?=
 =?utf-8?B?TXhTY09LYmpZZStjQVBsRlQwcXcxQkovekRUQlJrV2lxUVZoMWZoU2VtMk9y?=
 =?utf-8?B?aGJrbmVXRU9KT3VEdnlCUVZZUkNNSXpwYTR2Yys4QXQ0cjVpVmhPdnNZQk1P?=
 =?utf-8?B?Z3QyMjhRSmh3UGdBWVVMc09yd1hZZ3NmU1dhcy9jdCs0dEZ5MTdZNGdXdHU1?=
 =?utf-8?B?Y0VqRTdSMXhwNlJPRCtGWWE4OWNNc3lQQTAzcmc4WHVaVklzT2hLY2o1ZlFa?=
 =?utf-8?B?MERQUzkrSllaOExkcGt5WVlYNmJiNVJzRnY3cTdPZ3VMa0R1L3hXdDdyNkxK?=
 =?utf-8?B?MzlpYWtoMVNNSlVMVVpRMlFzOHoxOTBCRXlLRnU3b2VDeFRybndWdUtTQlNa?=
 =?utf-8?B?bnd3bUo3NjU1QTRZYlNjaE5lSE5CN3FaamVtVWZHakRyenlIWGd0SlU4bWIy?=
 =?utf-8?B?a0U3ZXRRbU0zRjdhcEh1T1lZTmNYZTQzbTlzTm1Zd0NOalBMUk9FOW5mRWx6?=
 =?utf-8?B?RkFFSkR1ekdaQlZCQTMxZ3RFMWgvRWdPeTR4OXFjZEJuMld2M0t3U2RrQVdW?=
 =?utf-8?B?ekRpNEwvcTJvRWRNRStaVE9sV1JNejJTc00zMTJxWXBrM2VSTFdwWGtTTkww?=
 =?utf-8?B?ODJaV01ZdUMxRmZqU1ZPekYxc2ZsWi9yQktUR3RBdUJpMXgvdDA3YW9iMHZO?=
 =?utf-8?B?eEJSdDh4c1I1Nm8xR0gwUzVWSlFaZjZHRDdiZ1o0anhMQnRhTjJlU0FjZ3ly?=
 =?utf-8?B?UmJFeTBDbUpWaVlETFBlUXhnUnhIRVdjU1hkSXM4aGk3Uk1ScFZxSVJxa1VH?=
 =?utf-8?B?ZU9yK0U1ZTcyazV5Y21TZktpY3JtWVZTSFNLeFcxQU16dHFUaGp3ZXhpVnV3?=
 =?utf-8?B?QWJWWDlLd3JZRlQ0MU1OK2ErL3hTTkc0NExWeGZ5eURpS0tKVnZGMStlWnNy?=
 =?utf-8?B?UGNOSFV6b2tNcmxCTlI4ODNnSms1c2gzTThHWWdaTDc0aWJGWHpad0NIcjEy?=
 =?utf-8?B?VGhKQ0ZXdTJBbnJodFJONGhERGhQcVNYVFBzeU51RUMxcEpZQ1lvT0x1d1Nh?=
 =?utf-8?B?WU5nSitPWFh1NklBSm5lMEF5aHczdVdZNE85dXZTMlFDUWJ1N0RtbytXTkd5?=
 =?utf-8?B?QUNSdTdESzh0NGxvT1B6SWRYV0duUDhEZVJvTm1yU2Q1WG15d3BtUHNaUEpS?=
 =?utf-8?B?bG1hdHRSNHJVMzVjcXgxWnlRSWxmN1ZwUzh3cG16TTVTQ2RSaEN0ZEtoVmd3?=
 =?utf-8?Q?x9oLruxw/7o=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?dk1UZUlSNHcxcms1dlFhcGRSb3JEa2tvUVAwQVN2cktwamY2SGt5NnRXUEtn?=
 =?utf-8?B?QjZiOVJXeTNQMXNibjV6WER0Nis4dHplN2ZrOUNpZXZvVUdYb1lDZ3g5SnFh?=
 =?utf-8?B?cEM0ZHVQL2J5TGo0RGRKQ3h1YXIzTDRwL05id2FBc3Q5ZGI2bmJ6SzVORDEy?=
 =?utf-8?B?bGRUV2Z2aXF1dkFJVlRsSjZveUtVTUt6VWcxOFJoVTl2OWhTNWZwV0x3Unkz?=
 =?utf-8?B?K2FPbGFtSFNWUys5WGlGcTIrWWVscm01NThXeHZENWRWdlR6b2JEQS85dzBY?=
 =?utf-8?B?ZjdPLzFWS1hVM1JhWjRVWXdnSzQyRlg0MnE5S2ZqQk9HNmtsYnpmQ2RyaFpI?=
 =?utf-8?B?UkZ1b2pNb1h1NDNVYkJpeVVtRFZrUGhTekNjdDYrT1JsUU5oSVhkdmtkSEZZ?=
 =?utf-8?B?anh1QUVYOFovOENJQ3NJS0UvYzBqa0FOSHNqMFRwUS91YXVYMVplQ0FTZHRn?=
 =?utf-8?B?RWhhc29pOXNQK0JkbHMvOUpFMUlBU3BPekt4Z2JDTTRUbnNEZjU4MDM4VEtW?=
 =?utf-8?B?bzFMeDJVY0RMZEV5Y3pReDJ0blN3ZlNCUVh2K2dWK3EvSFdrdm56U1RPejdp?=
 =?utf-8?B?U3A2clhCZlVtcG5sQXByRm52K3Q5UjFwdTJLY2xlTVVpempMZnlFYVJ6UGE3?=
 =?utf-8?B?OGlaVjdDd1NHZnJsZEVweXJjWFdVZlFpZGEwK1VwSnRrbk5hS1lRSm0vS0xF?=
 =?utf-8?B?N21TZjQvOUM2czUyWkNiajRib0RWUDFsdWl5L0EwQnJVQUFMTWQvRjNWd0ln?=
 =?utf-8?B?aDdxS1dYazl2Y3VhL2lkakhzbi9td0VJOVRrV1p6WmFuYStiN3FySlFsb0dm?=
 =?utf-8?B?Yll5ck9uVkROZ0duQ2tidTRtczRNa3NOblJzL20xUHVwcG0xNkNqa29PVDZt?=
 =?utf-8?B?Z1N2aDkxcURVZEdoZm5uL2FiSjlTL0xKeTZhVFh1eHJBaFRIaXBaK0RlK0Rp?=
 =?utf-8?B?Nkk3eURpbzVnbVNZdk0wMC9ZZUVTbzFlMjY0Qzg0aWp3RlQ2bGc0RVV3aUJa?=
 =?utf-8?B?NzhKT0FES2h4ZzYwdjN1RjJuSldaNEhzNzFCK2w4ZjRDSHlScFlBZE04a040?=
 =?utf-8?B?OHcvSis1RlQrS2duV3ovRHVsTmRjMDZPT3JEUjlpVnhtQmdNeEs2N1lvK1Vu?=
 =?utf-8?B?bHg1OExzU0ZLQXBtcWpEZi8xTE1QcFNRZTJZUkQyTnFjNkZGREpGd3dsUDlr?=
 =?utf-8?B?NjA3bEhqVFVQOUVMZ1Z1ejhBam9iZlVOOGdlcEgxVi9RQUM1MnZzUC9DNks3?=
 =?utf-8?B?OVY4aTlxcC9sdFpDMmI1ai95T3hkWVBvazE5TGdhOUxoZVd5WUpvM1BabzZX?=
 =?utf-8?B?bWtpdzk1Mlh0d2p6S05yNmRnYWtmNmFxR3V2UHZkc2I1UklnWEp4UjNtWVUz?=
 =?utf-8?B?UFY3U0UrS1NsTWc1aTRzRG1ucll0SDBSMVhjYmU5Q0g1KzY5TGdGNjhJOWs0?=
 =?utf-8?B?RXdQamwzNi9JQUk1akcvSW1HUUVyaFRrNGwrd3dqUWZ2ZkhjYVpZR3dncWpz?=
 =?utf-8?B?N3ZxYXpUT1lsODVXMFAvdXptR3BwWHFqeTVuUVA2TEhmUzIrQk00NW8yUFAy?=
 =?utf-8?B?Ujh6Q09zTnV0RUgvMElJRndFdHFKdDNqb0pMeWJwQk10UmxVS0ZybkUvWGRt?=
 =?utf-8?B?NDJJalp0QXZFelFJRUZJaExOcVZHbisrbk1xbjVHOGMvTy8yV2paVDFMQTZt?=
 =?utf-8?B?endpZmhYcktBcEkxUEJ3VUtscTBKTlk5bWpQYmU4U3pqeFNsQU0rRTRBbG1Z?=
 =?utf-8?B?V29raGV3aHkvNTlLK3AxUnZpSWhqTVZiQjl2amZoWDJiUmFTSTFPYVVlNWMy?=
 =?utf-8?B?RVA2VHhWVnVJblFVN0NGWVluQnh6b0VoWHlQUHg0bDN6alJtMktMUEN5emtK?=
 =?utf-8?B?cU5yK1NkOFc4L1ZjQ1NXZi9sQzBwdlZrVnpuNVB2blppNCsyOTlidW4vUXBw?=
 =?utf-8?B?eXQ2TFpJelZCVCtva1ZpTmo2MytxSnd1SWtqVEJvMHEzZ0phOHFpdEFMK25R?=
 =?utf-8?B?ZVR3d2JRZEFQbnZLZlJMTXhvRHhUN1BlOUpLTnpWamd5SmYzaXhOamtCaTg1?=
 =?utf-8?B?akMvV0lFaXZQc3AzTHRLZ3pYOVNIVE5MU2Zic0RyUjdDdkxyU0ZCTmxzaVRT?=
 =?utf-8?Q?1p2o=3D?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 34e2741e-99cc-4863-1ccf-08dda1ebc113
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jun 2025 15:40:08.8084
 (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: W9cWjDXg8qgH5BoJHzNN90Mro5L9duNl7pqwOufvVAHn8VOssm9K37BbmxiJHT6V
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB9078



On 02/06/2025 17:36, Andrew Cooper wrote:
> On 02/06/2025 4:09 pm, Michal Orzel wrote:
>> These tests are supposed to run on target. HOSTCC can be different than
>> CC (when cross-compiling). At the moment, tests installation would put
>> a binary of a wrong format in the destdir.
>>
>> Fixes: e90580f25bd7 ("vpci: introduce basic handlers to trap accesses to the PCI config space")
>> Signed-off-by: Michal Orzel 
> 
> Oh.  This didn't explode in GitlabCI because there's no ARM version of
> *-tools-tests-*.
> 
> Can we fix that too please, seeing as there is a real ARM board?
We will add it to our TODO.

> 
> Also, I guess we have to finally sort out the CC vs HOSTCC debate.
> 
> ~Andrew

~Michal



From xen-devel-bounces@lists.xenproject.org Mon Jun 02 15:42:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 15:42:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003634.1383224 (Exim 4.92)
	(envelope-from )
	id 1uM7JI-0007da-TD; Mon, 02 Jun 2025 15:42:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003634.1383224; Mon, 02 Jun 2025 15: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 1uM7JI-0007dT-QK; Mon, 02 Jun 2025 15:42:48 +0000
Received: by outflank-mailman (input) for mailman id 1003634;
 Mon, 02 Jun 2025 15:42: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 1uM7JG-0007dI-Vr
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 15:42:46 +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 3ab7e3bf-3fc8-11f0-a300-13f23c93f187;
 Mon, 02 Jun 2025 17:42:46 +0200 (CEST)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-3a4f89c6e61so1806195f8f.3
 for ; Mon, 02 Jun 2025 08:42:46 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-747affafba1sm7742560b3a.110.2025.06.02.08.42.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 02 Jun 2025 08:42:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3ab7e3bf-3fc8-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1748878965; x=1749483765; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=f9mH8227pMYWB5HdwXe+aKUpdQxLpQw8jSjD6kN34NM=;
        b=NNJVZ3KLpbCj/7U+vS30LIZg8uqwBLbocdfHyTK/0yXwkvuNd8hQ8mRj2HzWu0H1ZY
         DEmVqb2AImwPZxYWvlz048QVXjwXG/8pGL8ePeY+DExix+HWrViMtKb9OgJ/t1ORWI7U
         XW4rgkhIQM1AqVobquGTHPK+w/mlEf4Ijbgcmc/dbpBauFmOmFygLk4SWDfUlB050zx3
         8MRt/RC1gQix6nH51gJc/OqWeu0gLcKX5oZtkxX8/WFUaE2YHqHXgNhvz6g+HEfkN/7w
         w7FrxEuqkECUElvyHbas6gCKqO9s4mCenzTqvO6JT6wUvVXDL3I9WSlnGquhFKY8WYEJ
         gjvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748878965; x=1749483765;
        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=f9mH8227pMYWB5HdwXe+aKUpdQxLpQw8jSjD6kN34NM=;
        b=vRwX9ohogK2DyTFUuv+Yi+dIIs/bFilmBT6PeXKOHVCDaHGBbtTaSMkToKtPyTAENQ
         bhyMTWliNaM8yqoI6qsdt79Ej7GGhxGgk1IdGGTCxprNAwJMYPNyuzSnVMjNfvtYcziT
         0RR/i0K3qoGkYOSunKRk++MmC7nBCKZmG0nHOXWNXNhqHyIsoCpqu/sPmBc3tn2viEAv
         BvZrGOvVI0BhaO6a0qU1hGS2MBCyk/Ze1HbE7bQSYReQ/cIQNBnSret4B2TV/xIk4BuK
         7ksh/mWwXXqllOxrB1KX/BtpReBZVzg3xufGE1vEo/+jzIj5uH6BvQiyCEp+K4QjaeqQ
         CIyA==
X-Gm-Message-State: AOJu0YzGwr4RrlSxWufdhzdEuKGz7yEJt3oyPZf0ed6qe/ok5tRtUAOs
	63ELuf/hnzyuoxzj9mqw3QC7O7EEz2aM/8c2l62+cY/9mrERgwfTg6dnZrCZ9Yv17w==
X-Gm-Gg: ASbGnctCVlPFG/CCMZ99NcZTtV2l9ZQ0vuo2asR4wr7anFDWGD+JxQGr8hCcvNAkFr/
	aH4W1pA91Nj1b82LUSGM7oSn1SMgPEyyk0tNuu6oz5t/t9Swabpe5bQ3ZCpuT6z+jOLTJNkL3Zd
	/lVBgDThLIoFJMKu5khvsduz3ZOqxKxwDDeBpAyuygrwfRECuk+nb0kaM1wdqO/IfBzPG6DOCYN
	rvu/txibkfERCHhWB3svdJC5Oqc695MT0nnYz686Rpw6xG0BFPV7/WVCm/XiDsk5JYeI8sP77tD
	TEXM65liQ5kKwMY1V80MxdG3CZH8fixjOqICL6WBN7PL9KE28ghmo5SFVOdkgnXUibrLnr0IAqo
	uIn5Tq3qMPevz0WXyY7+mounPc8HwQkA9gUdW
X-Google-Smtp-Source: AGHT+IFBsu44e5wPODsgaqdd45Tq3ZfQ4XBfpq/sE6r+b5bkDmgYld8qKzeIoMSmzKbU2Ou3TP1TFg==
X-Received: by 2002:a05:6000:26c3:b0:3a4:ed62:c7e2 with SMTP id ffacd0b85a97d-3a4fe394776mr6719290f8f.28.1748878965458;
        Mon, 02 Jun 2025 08:42:45 -0700 (PDT)
Message-ID: 
Date: Mon, 2 Jun 2025 17:42:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Nullptr dereference in nested VMX when shadow VMCS support is
 available
To: Manuel Andreas 
Cc: xen-devel@lists.xenproject.org
References: <5f258e25-a4ed-4f9a-8ca6-9ea3400e2369@tum.de>
 <6d28eb0c-caed-4c58-a6ac-cbf8da357d22@tum.de>
 <21dcca4d-1c51-42f1-b73b-65702451de13@suse.com>
 <26f412e2-ba65-4e3f-8c5f-7e15f5f32491@tum.de>
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <26f412e2-ba65-4e3f-8c5f-7e15f5f32491@tum.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 02.06.2025 16:52, Manuel Andreas wrote:
> On 6/2/25 4:12 PM, Jan Beulich wrote:
> 
>> On 02.06.2025 15:39, Manuel Andreas wrote:
>>> I've discovered an issue in the nested VMX implementation, where an
>>> unprivileged domain is able to force Xen to dereference a NULL pointer,
>>> resulting in a panic.
>> Sadly you provide no details on this NULL deref.
> Here's the respective dump:
> 
> ----[ Xen-4.20.0  x86_64  debug=y Tainted:     H  ]----
> (XEN) CPU:    1
> (XEN) RIP:    e008:[] nvmx_handle_vmx_insn+0x7ab/0xccb
> (XEN) RFLAGS: 0000000000010202   CONTEXT: hypervisor (d1v0)
> (XEN) rax: 0000000000000000   rbx: 0000000000000000   rcx: 8000000000000002
> (XEN) rdx: 0000000000000000   rsi: 01ffffffffffffff   rdi: ffff82e0020155e0
> (XEN) rbp: ffff830179407e68   rsp: ffff830179407e00   r8: ffff82c00023b000
> (XEN) r9:  ffff830179413c40   r10: 0000000000000000   r11: 0000000000000200
> (XEN) r12: ffff83010483d000  r13: ffff830179407ef8   r14: 0000000000000000
> (XEN) r15: 0000000000000000   cr0: 0000000080050033   cr4: 00000000003526e0
> (XEN) cr3: 000000010498f000   cr2: 0000000000000000
> (XEN) fsb: 0000000000000000   gsb: 0000000000000000   gss: 0000000000000000
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
> (XEN) Xen code around  (nvmx_handle_vmx_insn+0x7ab/0xccb):
> (XEN)  75 b0 0f 86 12 05 00 00 <81> 08 00 00 00 80 41 8b 84 24 f4 05 00 
> 00 80 cc
> (XEN) Xen stack trace from rsp=ffff830179407e00:
> (XEN)    ffff83010483d000 000000000011e000 0000000000000000 0000000000000000
> (XEN)    ffff82d0402bfc4a 0000000100000000 0000000000119fa8 ffff82d000000008
> (XEN)    ffff830100000006 ffff830179407ef8 0000000000000015 ffff83010483d000
> (XEN)    0000000000000000 ffff830179407ee8 ffff82d0402a9a19 ffff82d04020361b
> (XEN)    0000000000000000 0000000000000000 0000000000000000 ffff830100997000
> (XEN)    ffff82d040203615 ffff82d04020361b ffff82d040203615 ffff82d04020361b
> (XEN)    ffff83010483d000 0000000000000000 0000000000000000 0000000000000000
> (XEN)    0000000000000000 00007cfe86bf80e7 ffff82d040203673 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000001
> (XEN)    0000000000000000 0000000000000000 0000000000000043 000000000000007b
> (XEN)    0000000000000043 0000000000000000 0000000000000000 0000000011e57e00
> (XEN)    0000000000000000 0000000000000000 0000beef0000beef 0000000000103fa2
> (XEN)    000000bf0000beef 0000000000000046 0000000000119fa0 000000000000beef
> (XEN)    000000000000beef 000000000000beef 000000000000beef 000000000000beef
> (XEN)    0000e01000000001 ffff83010483d000 0000003136627000 00000000003526e0
> (XEN)    0000000000000000 0000000000000000 0000000300000001 0000004e00000003
> (XEN) Xen call trace:
> (XEN)    [] R nvmx_handle_vmx_insn+0x7ab/0xccb
> (XEN)    [] F vmx_vmexit_handler+0xd97/0x1e14
> (XEN)    [] F vmx_asm_vmexit_handler+0x103/0x220
> (XEN)
> (XEN) Pagetable walk from 0000000000000000:
> 
> (XEN)  L4[0x000] = 0000000000000000 ffffffffffffffff
> 
> Where nvmx_handle_vmx_insn+0x7ab/0xccb resolves to 
> xen/arch/x86/hvm/vmx/vvmx.c:1169
> Specifically, in nvmx_handle_vmptrld we have:
> 
> 1830    if ( cpu_has_vmx_vmcs_shadowing )
> 1831        nvmx_set_vmcs_pointer(v, nvcpu->nv_vvmcx);

Ah yes, this is what I overlooked (as seemingly innocent).

>>> This is possible when:
>>>
>>>   1. The malicious domain has nested HVM capabilities.
>>>   2. The CPU is running on top of VMX and supports shadow VMCS.
>>>
>>> To trigger the bug, the domain must first enable VMX operation for
>>> itself, execute VMXON and then finally execute VMPTRLD on a guest
>>> physical address that is backed by a non-writable p2m mapping.
>>> In `nvmx_handle_vmptrld`, after attempting to map the nested VMCS, Xen
>>> will check whether or not this mapping is suitable for writing and if
>>> not immediately unmap the nested VMCS again and abort the setup of
>>> `nvcpu->nv_vvmcx`. However, Xen at this point erroneously continues
>>> emulation of the VMPTRLD. In particular, if VMCS shadowing is available,
>>> Xen will nonetheless attempt to link up the nested VMCS to its own VMCS
>>> in `nvmx_set_vmcs_pointer`. Importantly, Xen here attempts to
>>> dereference the presumably mapped nested VMCS (which now is merely a
>>> NULL pointer) in order to mark it as a shadow VMCS by applying the
>>> `VMCS_RID_TYPE_MASK` to its revision identifier. Following, the page
>>> fault handler will panic Xen.
>>>
>>> I've attached an XTF reproducer that triggers the bug. To setup such a
>>> non-writable p2m mapping for the malicious VMCS, I first setup an
>>> appropriate grant table entry. I've tested it on Xen version 4.20.0.
>> I expect this to not work anymore on current staging or 4.20.1-pre.
>> See a8325f981ce4 ("x86/P2M: synchronize fast and slow paths of
>> p2m_get_page_from_gfn()").
> On first glance I don't see how that would impact the type of the 
> established p2m mapping.

Thing is that with said change grant mappings will cause
hvm_map_guest_frame_rw() to simply fail, rather than returning a r/o
mapping for r/o grant entries.

>>> To fix the issue I believe the following patch should be suitable:
>>>
>>> --- a/xen/arch/x86/hvm/vmx/vvmx.c
>>> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
>>> @@ -1817,7 +1817,9 @@ static int nvmx_handle_vmptrld(struct
>>> cpu_user_regs *regs)
>>>                else
>>>                {
>>>                    hvm_unmap_guest_frame(vvmcx, 1);
>>> -                vvmcx = NULL;
>>> +                vmfail(regs, VMX_INSN_VMPTRLD_INVALID_PHYADDR);
>>> +
>>> +                return X86EMUL_OKAY;
>>>                }
>>>            }
>>>            else
>>>
>>> The VMX error AFAICT does not strictly adhere to the Intel SDM, but
>>> providing the guest some indication on what went wrong is likely more
>>> sensible than silently failing.
>> Giving the guest some indication is certainly right. If we want to follow
>> the above route, I think the change would want doing a little differently,
>> to take the path that presently is the "else" at the bottom of the hunk
>> above. However, I can't presently see how invoking vmfail() would make a
>> difference as to the subsequent NULL deref: The guest could continue the
>> same irrespective of the failure. Hence why I'd like to understand what
>> NULL deref you did observe. (We may hence need two patches - one along
>> the above lines, and another one dealing with the NULL issue.)
> 
> The issue is really just in the latter part of nvmx_handle_vmptrld, 
> which attempts to initialize its shadow VMCS even though establishing a 
> mapping for the nested VMCS failed.
> An early exit from that function (as my patch suggests) should be 
> sufficient for that case.

In fact there was correct code earlier on, and then the if() there was
converted to "else". Which simply needs converting back; patch sent.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 02 15:50:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 15:50:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003647.1383233 (Exim 4.92)
	(envelope-from )
	id 1uM7R5-0000uC-OI; Mon, 02 Jun 2025 15:50:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003647.1383233; Mon, 02 Jun 2025 15:50:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uM7R5-0000u5-Lj; Mon, 02 Jun 2025 15:50:51 +0000
Received: by outflank-mailman (input) for mailman id 1003647;
 Mon, 02 Jun 2025 15:50: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 1uM7R4-0000sm-RE
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 15:50:50 +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 5a5823ef-3fc9-11f0-b894-0df219b8e170;
 Mon, 02 Jun 2025 17:50:48 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a375888197so2333443f8f.0
 for ; Mon, 02 Jun 2025 08:50:48 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-747afe96781sm7798189b3a.29.2025.06.02.08.50.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 02 Jun 2025 08:50:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5a5823ef-3fc9-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1748879448; x=1749484248; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=JCcK73cs/9H9t85O0GxARqxzcSe8RU3p6Y+o+djw8jE=;
        b=g54ub1LBp2eRMg3bm2/4uQMkquVBq3Zwt5LwYqlVed0AuLvgqeOC2yjlkB4LMtvoPE
         YURY2WutJkhdu/73X7Wqv2spBmcvLPx4c9Z3z/FEQ0jWCmU0gcjUR/8sk+Ft7HCqKyn4
         mXWWfRReYq7Fo98Y7QtWAvv/lx4i1AgwHd6ddSsb34RMaY8WM3V9eXydpP+iSV3dkJN7
         IVsJnJJPVrhIq6dkGNUdtZm9R1z9UXI//JVS+x3Arq2FKt2/HA07pRFb0s6EgkGQ1pXm
         rpjSthLZ0Nxsgtoqb4t1plzx1zP50wfyyVXYyWdvaH7Ve57cTJVpzRjoMq5PUVERakdB
         4OdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748879448; x=1749484248;
        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=JCcK73cs/9H9t85O0GxARqxzcSe8RU3p6Y+o+djw8jE=;
        b=j3HGKr6N+PmestIvDxzz2xOkrHT1xv3fJJwPcLAgnDtDn3PUA5S0ObzyVg3zEwXUwU
         JL6nbAY/aN5Z5r/Mg49ni3DchmFAcElPIrW1T3c9HNJhlt0q6ZiLRbM+fdqC7SJPDXwF
         xbtw5GLBP91KHN8Tr+AMwyNpybuh/WPjcFUgc8oZJg5W3vmo4hgrbm7G1WIkru4GxPVL
         FIXAK+D1B38JLIDOuGVJQ4ozyycI6lvj13JuL6CULKyerF2CGHilYoxUh9lI/nuou5+Q
         mIbfXMHrndYsc+IVoDo9djEcNKL6HVuzrYFwc0CCFwZUCGUoJFQuppSk0DBLAictrihO
         jPTQ==
X-Forwarded-Encrypted: i=1; AJvYcCWlJsIjvvNBzq1AtrOGMGeARBuwtKbYXGfB2gQa/x9XZg2H6nanoqS6PUvhme3JQsQ4NicTm01t3kA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz01/r2xf8/23JU1TWEQz2hDjSW2s3DuC/yOgD/T1Bp8TponYIK
	0cuyQc8DwrcOgKT2VyRgNW1fWswZ2YQqrlVuCTjhukG5DAXD7bhTag/fJAO7FFlrsA==
X-Gm-Gg: ASbGncuX9Ewd6tzLWSRmGWsTSVB3YgLTGbmMb8NTYJB5eheUTg5e4h9/iP/wY2YKELW
	ZA8WMlqCFQZJICuKBdGTorNKF/qVCctGG7tTGHnNDS7smjs4T3a5hsMuYL3qo6UGDHsyJ/xrYF3
	jxtntZXOgtUMk2as/8wtWF0I+S2GIboFFpiiDKnw9cv9WkRT7GJeYs2q5fNU+zfELxdxA/1QiuR
	vRAWNlzLD4FT168WAupZxehs7HOp7t8rBu7vngBhOMXQFn0ZLbTTiOc7YsrzOd52X4wmW1N+ZX9
	/546rjy0s7K5yMyZLMJMflK4WMrUT6688ACHHot0DORSPCJ43hhKES1SUtTt8FlIKWVkFu4xCOf
	4V5m3C5zTp4bnw3ZbNtj9pDm19M07krGhp76vJFPAZWEwWLQ=
X-Google-Smtp-Source: AGHT+IFu2iPd4yaF5j0v15LiN7mjt6B4RyMR9nCD6RCIe+3okpsyhVh6y/FN9tkswPETAwEt3xjhiQ==
X-Received: by 2002:a5d:5f49:0:b0:3a4:f744:e00c with SMTP id ffacd0b85a97d-3a4fe39475bmr6730730f8f.29.1748879448024;
        Mon, 02 Jun 2025 08:50:48 -0700 (PDT)
Message-ID: <811c154c-d7d4-480c-8898-a21f62f2cf6a@suse.com>
Date: Mon, 2 Jun 2025 17:50:40 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] tests/vpci: Use $(CC) instead of $(HOSTCC)
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 Michal Orzel , xen-devel@lists.xenproject.org
References: <20250602150929.10679-1-michal.orzel@amd.com>
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 02.06.2025 17:36, Andrew Cooper wrote:
> On 02/06/2025 4:09 pm, Michal Orzel wrote:
>> These tests are supposed to run on target. HOSTCC can be different than
>> CC (when cross-compiling). At the moment, tests installation would put
>> a binary of a wrong format in the destdir.
>>
>> Fixes: e90580f25bd7 ("vpci: introduce basic handlers to trap accesses to the PCI config space")
>> Signed-off-by: Michal Orzel 
> 
> Oh.  This didn't explode in GitlabCI because there's no ARM version of
> *-tools-tests-*.
> 
> Can we fix that too please, seeing as there is a real ARM board?
> 
> Also, I guess we have to finally sort out the CC vs HOSTCC debate.

I think the situation here makes pretty clear that HOSTCC is almost always
wrong to use for tests/. The emulator test harness is special in that it (in
principle) needs a target compiler (CC) and additionally an x86 one (with no
present representation). The present way of (partly) distinguishing the two
by using CC and HOSTCC was assigning wrong meaning to one (perhaps both) of
them. The (or maybe just my) problem is that in the toolchain world it is
build, host, and target which are distinguished. As per Michal's description
my understanding is that HOSTCC is matching "build" there, not "host".

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 02 16:00:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 16:00:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003653.1383243 (Exim 4.92)
	(envelope-from )
	id 1uM7aU-0003I2-JP; Mon, 02 Jun 2025 16:00:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003653.1383243; Mon, 02 Jun 2025 16:00: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 1uM7aU-0003Hv-Gr; Mon, 02 Jun 2025 16:00:34 +0000
Received: by outflank-mailman (input) for mailman id 1003653;
 Mon, 02 Jun 2025 16:00: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 1uM7aT-0003Hp-LV
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 16:00:33 +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 b5b5a96d-3fca-11f0-b894-0df219b8e170;
 Mon, 02 Jun 2025 18:00:31 +0200 (CEST)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-43ede096d73so33670665e9.2
 for ; Mon, 02 Jun 2025 09:00:31 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a4f009f9d6sm15209795f8f.84.2025.06.02.09.00.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 02 Jun 2025 09:00:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b5b5a96d-3fca-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748880031; x=1749484831; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Shq0jHtUzQDgV0IdKjL8hlrAHgToAhtVE+Rp5+dg7xg=;
        b=olQRuRXLonxB0GWOh/WbXezgidkXmyAMVeNR4uk3MnoN0c/72ORHCrlEC728GpwhSw
         mirdZR7PcfKyEt5XRcOgyVctzxUVCZ4MLpZk302ad3wYjUldWLsQkvjBpXjiQiZHSfQ/
         jPR8Msn8TI4fUp3kwOepdl6Db47B82/ARZ4ZA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748880031; x=1749484831;
        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=Shq0jHtUzQDgV0IdKjL8hlrAHgToAhtVE+Rp5+dg7xg=;
        b=H7+F+P4eIjBCYKMFuZPwBKzmBXKy/BaE2RiEUxcK2SPhWAWqBkSm25zapfTN/LSIdG
         NNE1srV5poOIsvQjJzz+Hhd+84LYbf31r7gZH3XOHiOfN475e0ib3lHdXefqKskw1xeC
         CfbI/cR52SCZRnYXv+DJMhlrY58B2TV+iG2BO+Xx+ZfGZMQIVM0IxPXz9iM+dP9Xnn7j
         rNNBWtUIlD7rKAXlN5KDJKYCKZQzXtr5i4BKE/CulpICGTFA5TmFMDO0yewbfhNB7AOv
         rK06MZHvC5ke6V89DK+lOgy16fu2cvPLFPO3pgj8B/JTjEobhWOmh6Jgl2Vqvu66TteG
         mj2w==
X-Forwarded-Encrypted: i=1; AJvYcCXTwOaGhDmNMZjApc7BE1tDEb2IkLSJX9yvE9MKbOAXugFoU5CgzdwcDJiD9jdn8TvmNDGY6W5VrK8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzjMijk7xnBnInPUwCl5wwA2vVbVK5cTw4GWMpBV9TR6U8m4m+Q
	CS7lqL/cH3vDNVPXWNLrt37bnphT1pjVYP0ON2XlpuFyR6WyrFgL3tAWlG8m/xsZrzg=
X-Gm-Gg: ASbGncswFpz/UDp44GzV0gm7+MakEiRSxEsF6cAJE7AONInTrX+qxwEnkb83XixrslC
	W9xTLHRY7FclENsJtMopBi6gt5vnhBt8N/uyPzfJb4Wm+pS52LVbEsfjE8o5Epzpl91fKKe/5ti
	FfVfcDEHlgzNIp2GEUN5Xjxjt1qISf06hZOC0XIYvlVxHfDpAnOaxopXbOCMEkJQnC73Lpd/9V7
	oQ+a5gy2ipakyUN/zdqTreSVURQkkNT6sHMNVqSvl6q0PFk1U327+04nKYiOogp/3+oPpwBakwT
	yv7ihNAY6U3+M3KOE33ofaYCYVKiegE642YePDSnK9r8K0kylUPufSAXQ5c+dipxshek4dXTNSX
	Dx4HhOSMekCLfPOKs
X-Google-Smtp-Source: AGHT+IHnggI/9DeQr343iS9W2mhXQg200DgsoUxhLTSfNQV/Ub8BR6DZk09UdcweZrCuUrnLyK1+sg==
X-Received: by 2002:a05:600c:1d81:b0:442:e03b:589d with SMTP id 5b1f17b1804b1-4511edf2931mr70847295e9.24.1748880030680;
        Mon, 02 Jun 2025 09:00:30 -0700 (PDT)
Message-ID: 
Date: Mon, 2 Jun 2025 17:00:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] tests/vpci: Use $(CC) instead of $(HOSTCC)
To: Jan Beulich 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 Michal Orzel , xen-devel@lists.xenproject.org
References: <20250602150929.10679-1-michal.orzel@amd.com>
 
 <811c154c-d7d4-480c-8898-a21f62f2cf6a@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: <811c154c-d7d4-480c-8898-a21f62f2cf6a@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 02/06/2025 4:50 pm, Jan Beulich wrote:
> On 02.06.2025 17:36, Andrew Cooper wrote:
>> On 02/06/2025 4:09 pm, Michal Orzel wrote:
>>> These tests are supposed to run on target. HOSTCC can be different than
>>> CC (when cross-compiling). At the moment, tests installation would put
>>> a binary of a wrong format in the destdir.
>>>
>>> Fixes: e90580f25bd7 ("vpci: introduce basic handlers to trap accesses to the PCI config space")
>>> Signed-off-by: Michal Orzel 
>> Oh.  This didn't explode in GitlabCI because there's no ARM version of
>> *-tools-tests-*.
>>
>> Can we fix that too please, seeing as there is a real ARM board?
>>
>> Also, I guess we have to finally sort out the CC vs HOSTCC debate.
> I think the situation here makes pretty clear that HOSTCC is almost always
> wrong to use for tests/. The emulator test harness is special in that it (in
> principle) needs a target compiler (CC) and additionally an x86 one (with no
> present representation). The present way of (partly) distinguishing the two
> by using CC and HOSTCC was assigning wrong meaning to one (perhaps both) of
> them. The (or maybe just my) problem is that in the toolchain world it is
> build, host, and target which are distinguished. As per Michal's description
> my understanding is that HOSTCC is matching "build" there, not "host".

vPCI is a true unit test.  It can be run in the build environment. 
Installing it here was to get it run somewhere.

x86_emulator is weird.  It can be run in the build environment, but it
is also dependent on CPUID so wants running on target environments too.

Everything else (IIRC) needs a real dom0 to run in, because they make
hypercalls.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Jun 02 16:32:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 16:32:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003664.1383254 (Exim 4.92)
	(envelope-from )
	id 1uM84w-00089F-TR; Mon, 02 Jun 2025 16:32:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003664.1383254; Mon, 02 Jun 2025 16:32: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 1uM84w-000898-QW; Mon, 02 Jun 2025 16:32:02 +0000
Received: by outflank-mailman (input) for mailman id 1003664;
 Mon, 02 Jun 2025 16:32: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 1uM84v-000892-7i
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 16:32:01 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20628.outbound.protection.outlook.com
 [2a01:111:f403:2414::628])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1a9a553e-3fcf-11f0-a300-13f23c93f187;
 Mon, 02 Jun 2025 18:31:59 +0200 (CEST)
Received: from MW4PR04CA0153.namprd04.prod.outlook.com (2603:10b6:303:85::8)
 by MW6PR12MB8913.namprd12.prod.outlook.com (2603:10b6:303:247::11) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.21; Mon, 2 Jun
 2025 16:31:56 +0000
Received: from CH2PEPF00000148.namprd02.prod.outlook.com
 (2603:10b6:303:85:cafe::b8) by MW4PR04CA0153.outlook.office365.com
 (2603:10b6:303:85::8) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.19 via Frontend Transport; Mon,
 2 Jun 2025 16:31:56 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH2PEPF00000148.mail.protection.outlook.com (10.167.244.105) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Mon, 2 Jun 2025 16:31:55 +0000
Received: from localhost (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 Jun
 2025 11:31:52 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1a9a553e-3fcf-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=tH+tlCfpCVqB/GoQ0Ts326/R0+b9s881TxocRXkrlwPopKVu2NL1qb/g6LDR3yDG7hiLTueiJKgmiLLKqkYDgG+pFUmP9+hAJHhzZFTF+b9wGor7OdpkyCQaSdQaItpONEZ6cykLnP8i3hnDcQgP5aNkw1xT/Y0NKaU5K2/IE6yQiy/E0eJve1AB8lgEJepw875tiY7nGq1fOBOiv8let9V4vVh4fsBHhXG7jOji+WOi3CljrSVVo1o3bgF2IiL4Z50REqrxreu0iBltGs6mKeFsuhAinZDVM/X11YgnSHmFJ1pQPz7aeVRuL+1Y5XFVhLUg0ioL3SwQ+ffUq+WvDg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=slY+IyKFFQxbitcaY/U014p/ejMGRRzdUKhAgDaPrxM=;
 b=trLr0qodTG4CDMykSD5kbuTy/X/dolx0Nh8fAeGiccpfr2MUH1p5L0N/wXR3Yv0fPjO8ERXNDeCzuyB83XlTGK1KR5wNdLMpLgak3in7oIlKP3NmvdtpHuYAu1TiQROqgrtuFyNASZw40BUnVJvtde111txmnY7oqln5+AYM3trEqWkxwehvrtNJ709XleegpoAlKKsGCg5jUQ+dKduTezJRqMfc1i2TRNQvdmY0ZYUMg+Uz6MneMpCU1WTYOVUvP+W3xbh21QwHOlDftr9Dku8DG2hoIfJgJXutmnEk/nG3uB3UJnFEegFV9abw6e2HfWnPX/m8cepQzO6d7UE/0w==
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=slY+IyKFFQxbitcaY/U014p/ejMGRRzdUKhAgDaPrxM=;
 b=iq4xfN+n1Vb3mynQt4/2rMEr304OY/ROqCTonXy3naH1gAdvrucC1St2gSS7ZkEVvWawLwgLzQ6ZxjbyQEeslfhnbnAd0+rekWR8vV0Y6OwAJo15S8AYx5U/f0CGTLkUmN6RYYfnYKITLJhdwDAr4gWg25BNCfwfoTJxG3W7xc4=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 2 Jun 2025 18:31:49 +0200
Message-ID: 
CC: , Jan Beulich , "Andrew
 Cooper" , =?utf-8?q?Roger_Pau_Monn=C3=A9?=
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Daniel P.
 Smith" 
Subject: Re: [PATCH 10/19] x86: Replace boot_module with bootmodule
From: Alejandro Vallejo 
To: Stefano Stabellini 
X-Mailer: aerc 0.20.1
References: 
 <20250530120242.39398-1-agarciav@amd.com>
 <20250530120242.39398-11-agarciav@amd.com>
 
In-Reply-To: 
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: CH2PEPF00000148:EE_|MW6PR12MB8913:EE_
X-MS-Office365-Filtering-Correlation-Id: e6ff021a-a406-41db-ffb3-08dda1f2fd30
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:
	=?utf-8?B?S1Q4RXRteXZJSldRY3AvaFlNeXNLdVl5UWRQczNhUkt3bjJNVlIzMGErWGVk?=
 =?utf-8?B?ZWJ2cnZJWXF5c2JhakNTSDhRSEN0aVlJU3ptdWdIb1U0NVJaUFJFR2ZtUHhU?=
 =?utf-8?B?VWp5STk2V3BHUDd2TGduTUpOTUlSYmdXSUJ2dElRSGpRYnFSVW1oeWFJOXpF?=
 =?utf-8?B?elJoWm9qRm11anE4U2tYUzZuRE1pOTdnM3ErNWNBaXFPdm9DREowOHl2c1JG?=
 =?utf-8?B?M1kzN3BJZHMwZzNCNkJUejZrd3pXQS9BTW1OQTBJYm11ZTFZWHpaM3B4cjBP?=
 =?utf-8?B?TjlvWEFQaGdodFJNUWdYYkl6NXM5OHpsTWVhdUlPcy9mQ3daOHozSUpsMy9N?=
 =?utf-8?B?NXpNbnNRdXlnVDhyZDZVOWVZWHFTdUlWaHM0WU4rMlJUaFBqcnNDZWlWVC9B?=
 =?utf-8?B?YXlzTXRyT1NkODdYemtDZm5Ga1Juc0ZMbzdwT3p3dVM2eGtTK3RkV1ZmWWJ5?=
 =?utf-8?B?eU5KNGV5ZjREYlAvWlc5ekVyYjgwbUZlakZaUHJEY0RZdSs5NS9EZGhyM3U2?=
 =?utf-8?B?SW9mYW5JTkV1S3pYVU5xRHp6b3ZRZklISmlWejJCMFVlR1Zxbk13SkVCa3ZJ?=
 =?utf-8?B?VGRqV1VHc3R3SWtNMXpwVVZvQk5Hbks5RTBPRGFFa01iZUFZVzhoQ2RyS0xr?=
 =?utf-8?B?bTg1MFlyUkc5b2haVHpPcURLM09MUlJ1bmN6dFpQSlJIZ1hZTW42MmNwOFA0?=
 =?utf-8?B?cXRDUm5iWUxkVko1YVN2aFpNdGx4cGxsb2lkY3JPQmQxMWVDSG1zOG1FdzFO?=
 =?utf-8?B?Y3lDMTdXMXlYTTJydGpCdEhrb09Sd1pWc0JzSmVwQ0R0NUNCWUliZSttdHFM?=
 =?utf-8?B?NkRPMmN1K3o3d3d1TnR0dDY0dEVhVTAxbmV1U1BhMGtaYUFTem00QXUzN1NK?=
 =?utf-8?B?Uno4UzUxc2Nnb1VhVitFRllwSmtEeGt3Q08yT3FWTTE4V1lsSko2RUE2RjVG?=
 =?utf-8?B?YlBVNVk3Y094b2t6Y1I2NWZvTm1yeHpka1lIOTJKUEF1MWt3cEN5TC9DcUM4?=
 =?utf-8?B?bnZwVERjTTUvRkdzamkxYWRUNVkrdDRFVG55MTc2QXV1MFV6Ump2SndUZXpQ?=
 =?utf-8?B?MWhKMWpuVEhBSjBSN2JVUTVnMXd0T1BTd0FWMFFzdUoveHNOWnNuUkhBQnhS?=
 =?utf-8?B?NmJPQTZSMjVXZmlwcWdRanp2NDlmNG4wYldQUjB2Z1NQWDZLcmxEc1Znd2U2?=
 =?utf-8?B?THFUUkpzeWJ0U3NZMkNaaHowMVBjcGhuRmRHejZOWGEzdi9vTkNPZTJPSzZX?=
 =?utf-8?B?RC9qSjZacE1jdzNqelZVcmRpdWNhS0p2NWs0bDc2V1BsdXd6cEdWaGF2TC9q?=
 =?utf-8?B?N1djaVZwVHNJZzQ4UTI5NWxVa1Znc0hUM2I5dmR3dFhYbXMwdW5qb3VQVmhY?=
 =?utf-8?B?TzVwaXlhVDlSR3E4MDdxZ3MxVit2VGdlRmxyZEFkeHdFVThQRmJYQlcwZ1p5?=
 =?utf-8?B?Y0hnVmtmOFRsczVwejJGZmE5TXhURVpDQ3Q5aU85Tlh5RkRIRUliVjdNT2V2?=
 =?utf-8?B?V3NWSGZyc0FCM0o2N1hMMnN6UDJpbGZBSnR5bmJnbkZ0d0lCQW9YNXpVNUg2?=
 =?utf-8?B?MTlKUmVXTVZXemVDSm1NRWV1cm9nTUNXZy8wRGtLOW9NWXRTWGllVUNodmdz?=
 =?utf-8?B?WnpyUHZQMThzNkRDV2lVTnU3Y3RiaVYxSlJFTkpka2JKV25iRVcyT2V5MVJq?=
 =?utf-8?B?eVRPUlljWGxpa01UNmZ5SnZ4N3pMb2RwYm1Wd3MvRFVnYklxakJBVnhVNDFj?=
 =?utf-8?B?MjBhcFpJcHFlMmlucGJiRUVtWkI1ckJZcmlEeUNLVnU1VWJMa3hVRmNUckt0?=
 =?utf-8?B?UU5GNnllU2dDajFuVDJNanhDWU90ayt5TERvaEh1aEdKRlVvSGgrNDF1OE9P?=
 =?utf-8?B?ZzFqa3ZJNU1CNCt0WVhHaFp4TnlENnBjdHI3M05wWkZWaTJ4K0VZOWd3Zm1j?=
 =?utf-8?B?NjU0SmlHK1dSYmVrSFJqamR0TFNmM1ZIL05wcURHS3VsOWlyNnRQWkdRSlZM?=
 =?utf-8?B?SWV2d0NnTzE4SXJLVXU2SWNsd3ZrMzk5MS9ydWE0a1NOWm9NUzNjOVo5d3lF?=
 =?utf-8?Q?hdtcEg?=
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: 02 Jun 2025 16:31:55.7919
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e6ff021a-a406-41db-ffb3-08dda1f2fd30
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:
	CH2PEPF00000148.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW6PR12MB8913

On Sat May 31, 2025 at 3:15 AM CEST, Stefano Stabellini wrote:
> On Fri, 30 May 2025, Alejandro Vallejo wrote:
>> These types resemble each other very closely in layout and intent, and
>> with "struct bootmodule" already in common code it makes perfect sense
>> to merge them. In order to do so, add an arch-specific area for
>> x86-specific tidbits.
>>=20
>> Signed-off-by: Alejandro Vallejo 
>> ---
>>  xen/arch/x86/cpu/microcode/core.c      |  9 ++--
>>  xen/arch/x86/hvm/dom0_build.c          | 10 ++---
>>  xen/arch/x86/include/asm/boot-domain.h |  4 +-
>>  xen/arch/x86/include/asm/bootfdt.h     | 52 +++++++++++++++++++++++
>>  xen/arch/x86/include/asm/bootinfo.h    | 58 +++-----------------------
>>  xen/arch/x86/include/asm/setup.h       |  6 +--
>>  xen/arch/x86/pv/dom0_build.c           |  8 ++--
>>  xen/arch/x86/setup.c                   | 52 ++++++++++++-----------
>>  xen/include/xen/bootfdt.h              |  9 ++++
>>  xen/xsm/xsm_policy.c                   |  4 +-
>>  10 files changed, 113 insertions(+), 99 deletions(-)
>>  create mode 100644 xen/arch/x86/include/asm/bootfdt.h
>>=20
>> diff --git a/xen/arch/x86/include/asm/bootfdt.h b/xen/arch/x86/include/a=
sm/bootfdt.h
>> new file mode 100644
>> index 0000000000..c00de8c09b
>> --- /dev/null
>> +++ b/xen/arch/x86/include/asm/bootfdt.h
>> @@ -0,0 +1,52 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +#ifndef __ARCH_X86_BOOTFDT_H__
>> +#define __ARCH_X86_BOOTFDT_H__
>
> With the new convention this is just X86_BOOTFDT_H

Ah, right. I forgot about that. Sure.

>> +#include 
>> +
>> +struct arch_bootmodule
>> +{
>> +    /*
>> +     * Module State Flags:
>> +     *   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;
>
> This is not actually used or needed in this patch?

Bah. This is a later addition in the dom0 DTB series. I pulled it
here too by mistake. Good catch.

Cheers,
Alejandro=20


From xen-devel-bounces@lists.xenproject.org Mon Jun 02 16:38:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 16:38:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003671.1383263 (Exim 4.92)
	(envelope-from )
	id 1uM8Ac-0000IE-Gp; Mon, 02 Jun 2025 16:37:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003671.1383263; Mon, 02 Jun 2025 16:37:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uM8Ac-0000I6-EB; Mon, 02 Jun 2025 16:37:54 +0000
Received: by outflank-mailman (input) for mailman id 1003671;
 Mon, 02 Jun 2025 16:37: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 1uM8Ab-0000I0-2C
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 16:37:53 +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 ec914fb8-3fcf-11f0-b894-0df219b8e170;
 Mon, 02 Jun 2025 18:37:51 +0200 (CEST)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-addcea380eeso214346066b.0
 for ; Mon, 02 Jun 2025 09:37:50 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ada5d82dd2bsm827017766b.59.2025.06.02.09.37.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 02 Jun 2025 09:37:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ec914fb8-3fcf-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748882270; x=1749487070; 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=tLJO6NhTswMAk3NAD5Hu8kfWCi+LVnX1Hp3DucLbjdc=;
        b=TDLFnk16Z9d45hAMcqvAoUdqT1PttyJIY2ZdwUEvGIdSGu12rRG+SbzUxwFZm7hofc
         LRYLAcIv88AkrruMwJo5xbccLObsESv3uAABH3/82Xj9cUoNDJY3GLncxcm13H5Dzz2P
         1oVWYodRNQNHtChdDwIl2oV78jMZ0o27gDE1C4b8HCrqtiXPypKoWL6YTJ3hbqrHeB6X
         6UBQVmg5hRMpGwehcgheaI8gXyaNztEql74Uh905xpcg07DhLOttticTZjVtOAHNqjaJ
         HkmAKeIaWrPIv2T6cw++DljkkZdbDAQ2mUrhzbHGH6ABOmB3PTuJN4rtrfyBY94DGztH
         7bQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748882270; x=1749487070;
        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=tLJO6NhTswMAk3NAD5Hu8kfWCi+LVnX1Hp3DucLbjdc=;
        b=hqsx6xT2DrZoq7S0Zo9UJ/Zy9sE9UdleO6grOuQ40Vo3GaUdcimAr8Ymv12dcdzG5Y
         sBHpMLFaaOECtaHRW2ubqL75VwI9FO9om4/wJT3SyPRGdQpxK+B3mN0WfKPz0W/zNHXq
         ZF4BGcnQTr+6XifP6t+lDLEkiurCOI3S6jOFfLiT392lHH79tU8oRxQahpnQh17lU0ZI
         ZFL1K8DNpqMvp9uJRrHs32zMV9IFehXkUZTsKz5C3rHcNiwE7UEasnC+qKJaknAIUzSO
         bup2AChGnDToYLg57YjkOLpuOCg7rphd+R6MPyfSa8VkHk1gmUojRzcItGQVcO01YDA7
         d3TA==
X-Gm-Message-State: AOJu0YwTibEzgO6428koGUgJms4mHisGJPa8l5y95Q7Zpv5cPoVOMjH8
	7lkp4RDzA/REeXmVC9BsVwPVZaQoi2chAFZquvehc1E+hHBnlbpl8ZFQHGer+w==
X-Gm-Gg: ASbGncsvU8KwzU+yFLbRes5pvo+889bLicQarzzuaDR3VKJ2G4Q8pZxlFCr0DPI/Fvy
	Jw2FC0vM9wF2VjyKLegEpsEFrtokPtDIgH3dneIy/VfBGbr+nZ2DF0fwgt0AZOHZfzqZD9f69N5
	+UGehpsnc6UH/JkOyyAhiyLAeMX8o45KlN3Bu6dAYidpAK17m4SNNeEDRrlIQldve9p39vMHuUM
	jPIX2ft+RJ6K5TDw5LmwpxO+0yu4odHIrxYlwdrZpv8fC9vkirsmf+0C2yktkmRp9M7rW0bM+MX
	AE4TG/VC0a3gen42/x1fVfdeuv4n6x/UKqETB0l1p/x1bL6yrP3PbQ5NhbA1FrYMQTAldrOL/bZ
	sWBAwm25vVMzrj8pCugTPkv18NUHFYSWCbI0=
X-Google-Smtp-Source: AGHT+IFQQTdSNJoGhW7Tksc8aaVZ9tzd1kpzqCSBzTeDZcazBxLP07P2f2pE3C17I57N2D/hu3cCVw==
X-Received: by 2002:a17:907:1c0b:b0:ad8:a41a:3cc6 with SMTP id a640c23a62f3a-adb4936fd72mr832001366b.11.1748882269826;
        Mon, 02 Jun 2025 09:37:49 -0700 (PDT)
Message-ID: <7364a71d-2604-49ca-bab7-d21544d49b10@gmail.com>
Date: Mon, 2 Jun 2025 18:37:46 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: xen-devel@lists.xenproject.org
Cc: Ayan Kumar Halder ,
 Mykyta Poturai , Juergen Gross ,
 Teddy Astie ,
 Bertrand Marquis ,
 Luca Fancellu , Jason Andryuk
 , Alejandro Vallejo ,
 Sergii Dmytruk , Penny Zheng
 ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , Roger Pau Monne ,
 Luca Fancellu ,
 Andrew Cooper , dmkhn@proton.me,
 Mykola Kvach ,
 "Daniel P. Smith" ,
 Grygorii Strashko ,
 Alejandro Vallejo ,
 "committers@xenproject.org" ,
 Community Manager 
From: Oleksii Kurochko 
Subject: Xen 4.21 Development Update [May]
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello everyone,

This email only tracks big items for xen.git tree. Please reply for 
items you
would like to see in 4.21 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 =

As there hasn't been any feedback on the proposed timeline shared here:
https://lore.kernel.org/xen-devel/666e3f49-2f92-4828-8897-8579832bcaa2@gmail.com/T/#u

We can proceed with the suggested timeline as the release schedule for 
Xen 4.21.
I've updated the Xen 4.21 Release Notes with this schedule, which can now be
accessed via the RN link:
   https://xenbits.xen.org/docs/unstable/support-matrix.html

= Updates =

The following items ( the links for them could be found int the list below )
were moved to completed:
   [since May 6 - Jun2]:
     * Hypervisor:
       - tools: remove qemu-traditional
     * Arm:
       - PCI devices passthrough on Arm, part 3
     * x86:
       - xen: cache control improvements
   [since 4.20 relese - May 6]:
     * Hypervisor:
       - Move parts of Arm's Dom0less to common code
       - remove libxenctrl usage from xenstored
     * Arm:
       - Enable early bootup of Armv8-R AArch32 systems
     * x86:
       - x86/HVM: emulation (MMIO) improvements
     * RISC-V:
       - RISC-V some preinit calls.
       - Fixes for UBSAN & GCOV support for RISC-V.

Some new items added:
  [since May]
     * x86:
      - Allow x86 to unflatten DTs
      - hyperlaunch: move remaining pvh dom0 construction
      - x86/hyperlaunch: introduce concept of core domains
      - Confidential computing and AMD SEV support
     * Arm:
      - SMMU handling for PCIe Passthrough on ARM
      - xen/arm: scmi: introduce SCI SCMI SMC multi-agent support
      - Add initial Xen Suspend-to-RAM support on ARM64
     * RISC-V:
      - introduce p2m functionality
  [since 4.20 release]
     * Hypervisor:
       - tools: remove qemu-traditional
       - Physical address hypercall ABI ("HVMv2")
       - xen: Untangle mm.h
       - xen: introduce CONFIG_SYSCTL
       - Add support for exact-node memory claims
       - Several CI cleanups and improvements, plus yet another new runner
     * x86:
       - x86/EFI: prevent write-execute sections
       - x86: Trenchboot Secure Launch DRTM (Xen)
       - Hyperlaunch device tree for dom0 (v6)
       - amd-cppc CPU Performance Scaling Driver (v4)
       - Hyperlaunch domain builder
       - kexec: add kexec support to Mini-OS
       - xen: cache control improvements (should be moved to "Hypervisor"?)
       - x86: generate xen.efi image with no write-execute sections
       - x86/asm: cleanups after toolchain baseline upgrade
     * Arm:
       - Add support for R-Car Gen4 PCI host controller (v4)
       - FF-A VM to VM support (v5)
       - First chunk for Arm R82 and MPU support (v4)
       - ARM split hardware and control domains (v5)
       - MPU mm subsistem skeleton
     * RISC-V:
       - introduce basic UART support and interrupts for hypervisor mode

* Full list of items : *

= Projects =

== Hypervisor ==

* xen/console: cleanup console input switch logic (v1 -> v5)
   - Denis Mukhin
   - 
https://lore.kernel.org/xen-devel/20250530231841.73386-1-dmukhin@ford.com/
   - https://patchew.org/Xen/20250530231841.73386-1-dmukhin@ford.com/

* xen: introduce CONFIG_SYSCTL (v3 -> v4)
   -  Penny Zheng
   - 
https://lore.kernel.org/xen-devel/20250528091708.390767-1-Penny.Zheng@amd.com/
   - https://patchew.org/Xen/20250528091708.390767-1-Penny.Zheng@amd.com/

* Physical address hypercall ABI ("HVMv2")
   - Teddy Astie
   - 
https://lore.kernel.org/xen-devel/cover.1744981654.git.teddy.astie@vates.tech/

* xen: Untangle mm.h
   -  Andrew Cooper
   - 
https://lore.kernel.org/xen-devel/20250312174513.4075066-1-andrew.cooper3@citrix.com/
   - 
https://patchew.org/Xen/20250312174513.4075066-1-andrew.cooper3@citrix.com/

* Add support for exact-node memory claims
   -  Alejandro Vallejo
   - 
https://lore.kernel.org/xen-devel/20250314172502.53498-1-alejandro.vallejo@cloud.com/
   - 
https://patchew.org/Xen/20250314172502.53498-1-alejandro.vallejo@cloud.com/

* Several CI cleanups and improvements, plus yet another new runner
   - Marek Marczykowski-Górecki
   - 
https://lore.kernel.org/xen-devel/cover.7da1777882774486a13e6f39ff4a2096f6b7901e.1744028549.git-series.marmarek@invisiblethingslab.com/
   - 
https://patchew.org/Xen/cover.7da1777882774486a13e6f39ff4a2096f6b7901e.1744028549.git-series.marmarek@invisiblethingslab.com/

*  Remove the directmap (v5)
   -  Alejandro Vallejo
   - 
https://lore.kernel.org/xen-devel/20250108151822.16030-1-alejandro.vallejo@cloud.com/
   - 
https://patchew.org/Xen/20250108151822.16030-1-alejandro.vallejo@cloud.com/

*  automation: Refresh the remaining Debian containers (v2)
   -  Javi Merino
   - 
https://lore.kernel.org/xen-devel/cover.1730743077.git.javi.merino@cloud.com/T/#m5d9acb7cf5db3c2be3d6527de14b69b07812314e

*  GRUB: Supporting Secure Boot of xen.gz (v1)
   -  Ross Lagerwall
   - 
https://patchew.org/Xen/20240313150748.791236-1-ross.lagerwall@citrix.com/

*  MSI-X support with qemu in stubdomain, and other related changes (v8)
   -  Marek Marczykowski-Górecki
   - 
https://lore.kernel.org/xen-devel/cover.33fb4385b7dd6c53bda4acf0a9e91748b3d7b1f7.1715313192.git-series.marmarek@invisiblethingslab.com/
   -  Only automation patch left to be reviewed/merged.

*  [RFC] Introduce xenbindgen to autogen hypercall structs (v1)
   -  Alejandro Vallejo
   - 
https://patchew.org/Xen/20241115115200.2824-1-alejandro.vallejo@cloud.com/

*  Introduce NS8250 UART emulator (v2)
   -  Denis Mukhin
   - 
https://patchew.org/Xen/20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com/

=== x86 ===

* Allow x86 to unflatten DTs
   - Alejandro Vallejo
   - 
https://lore.kernel.org/xen-devel/20250530120242.39398-1-agarciav@amd.com/
   - https://patchew.org/Xen/20250530120242.39398-1-agarciav@amd.com/

* hyperlaunch: move remaining pvh dom0 construction (v2)
   - Daniel P. Smith
   - 
https://lore.kernel.org/xen-devel/20250515131912.5019-1-dpsmith@apertussolutions.com/

* x86/hyperlaunch: introduce concept of core domains (v2)
   - Daniel P. Smith
   - 
https://lore.kernel.org/xen-devel/20250515131951.5594-1-dpsmith@apertussolutions.com/

* Confidential computing and AMD SEV support
   - Teddy Astie
   - https://patchew.org/Xen/cover.1747312394.git.teddy.astie@vates.tech/
   - 
https://lore.kernel.org/xen-devel/cover.1747312394.git.teddy.astie@vates.tech/

* x86/efi: Fix booting when NX is disabled (v1 -> v2)
   - Andrew Cooper
   - 
https://patchew.org/Xen/20240722101838.3946983-1-andrew.cooper3@citrix.com/
   - 
https://lore.kernel.org/xen-devel/20240722101838.3946983-1-andrew.cooper3@citrix.com/

* x86/asm: cleanups after toolchain baseline upgrade (v1 -> v2)
   - Denis Mukhin
   - 
https://lore.kernel.org/xen-devel/20250403182250.3329498-1-dmukhin@ford.com/
   - https://patchew.org/Xen/20250403182250.3329498-1-dmukhin@ford.com/

* amd-cppc CPU Performance Scaling Driver (v4 -> v5)
   - Penny Zheng
   - 
https://lore.kernel.org/xen-devel/20250527084833.338427-1-Penny.Zheng@amd.com/
   - https://patchew.org/Xen/20250414074056.3696888-1-Penny.Zheng@amd.com/

* x86: Trenchboot Secure Launch DRTM (Xen) (v1 -> v3)
   - Sergii Dmytruk
   - https://patchew.org/Xen/cover.1745172094.git.sergii.dmytruk@3mdeb.com/
   - 
https://lore.kernel.org/xen-devel/cover.1748611041.git.sergii.dmytruk@3mdeb.com/

* x86/EFI: prevent write-execute sections
   - Roger Pau Monne 
   - 
https://lore.kernel.org/xen-devel/20250401130840.72119-1-roger.pau@citrix.com/

* Hyperlaunch device tree for dom0 (v6)
   - Alejandro Vallejo
   - https://patchew.org/Xen/20250429123629.20839-1-agarciav@amd.com/
   - 
https://lore.kernel.org/xen-devel/20250429123629.20839-1-agarciav@amd.com/

* Hyperlaunch domain builder
   - Daniel P. Smith
   - 
https://patchew.org/Xen/20250419220820.4234-1-dpsmith@apertussolutions.com/

* kexec: add kexec support to Mini-OS
   - Juergen Gross 
   - 
https://lore.kernel.org/xen-devel/20250321092451.17309-1-jgross@suse.com/

* x86: generate xen.efi image with no write-execute sections
   - Roger Pau Monne
   - 
https://lore.kernel.org/xen-devel/20250318173547.59475-1-roger.pau@citrix.com/

*  Expose consistent topology to guests (v7)
   -  Alejandro Vallejo
   - 
https://patchew.org/Xen/20241021154600.11745-1-alejandro.vallejo@cloud.com/

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

*  Address Space Isolation FPU preparations (v2->v3)
   -  Alejandro Vallejo
   - 
https://patchew.org/Xen/20250110132823.24348-1-alejandro.vallejo@cloud.com/

*  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

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

*  x86: support AVX10 (v3)
   -  Jan Beulich
   - https://patchew.org/Xen/516b7f9a-048e-409d-8a4e-89aeb8ffacc4@suse.com/

*  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/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/

*  x86: memcpy() / memset() (non-)ERMS flavors plus fallout (v4)
   -  Jan Beulich
   - https://patchew.org/Xen/14b65231-b83b-43fb-bbcf-dec5c07d285b@suse.com/

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

=== ARM ===

* SMMU handling for PCIe Passthrough on ARM (v11)
   - Mykyta Poturai
   - 
https://lore.kernel.org/xen-devel/cover.1741958647.git.mykyta_poturai@epam.com/
   - 
https://patchew.org/Xen/cover.1748422217.git.mykyta._5Fpoturai@epam.com/

* xen/arm: scmi: introduce SCI SCMI SMC multi-agent support
   - Grygorii Strashko
   - 
https://lore.kernel.org/xen-devel/20250311111618.1850927-1-grygorii_strashko@epam.com/

* Add initial Xen Suspend-to-RAM support on ARM64 (v4)
   - Mykola Kvach
   - 
https://lore.kernel.org/xen-devel/cover.1741164138.git.xakep.amatop@gmail.com/
   - https://patchew.org/Xen/cover.1748848482.git.mykola._5Fkvach@epam.com/

* Add support for R-Car Gen4 PCI host controller (v4 -> v5)
   - Mykyta Poturai
   - 
https://lore.kernel.org/xen-devel/cover.1747820844.git.mykyta_poturai@epam.com/
   - 
https://patchew.org/Xen/cover.1747820844.git.mykyta._5Fpoturai@epam.com/

* FF-A VM to VM support (v5 -> v6)
   - Bertrand Marquis 
   - 
https://lore.kernel.org/xen-devel/cover.1747925287.git.bertrand.marquis@arm.com/
   - https://patchew.org/Xen/cover.1747925287.git.bertrand.marquis@arm.com/

* First chunk for Arm R82 and MPU support (v4 -> v6)
   - Luca Fancellu
   - 
https://lore.kernel.org/xen-devel/20250523065406.3795420-1-luca.fancellu@arm.com/
   - https://patchew.org/Xen/20250523065406.3795420-1-luca.fancellu@arm.com/

* ARM split hardware and control domains (v5)
   - Jason Andryuk
   - 
https://lore.kernel.org/xen-devel/20250416212911.410946-1-jason.andryuk@amd.com/
   - https://patchew.org/Xen/20250416212911.410946-1-jason.andryuk@amd.com/

* MPU mm subsistem skeleton
   - Luca Fancellu
   - 
https://lore.kernel.org/xen-devel/20250312135258.1815706-1-luca.fancellu@arm.com/
   - https://patchew.org/Xen/20250312135258.1815706-1-luca.fancellu@arm.com/

*  Add Virtio-PCI for dom0less on ARM (v1)
   -  Edgar E. Iglesias
   - 
https://lore.kernel.org/xen-devel/20240924162359.1390487-1-edgar.iglesias@gmail.com/T/#mfa148991b9408f223a079d4cef610244d5b04c2b
   - 
https://patchew.org/Xen/20240924162359.1390487-1-edgar.iglesias@gmail.com/

*  DOMCTL-based guest magic region allocation for 11 domUs (v4)
   -  Henry Wang
   - https://patchew.org/Xen/20240409045357.236802-1-xin.wang2@amd.com/

=== RISCV ===

* riscv: introduce basic UART support and interrupts for hypervisor mode 
(v2 -> v3)
   -  Oleksii Kurochko
   - 
https://lore.kernel.org/xen-devel/cover.1747843009.git.oleksii.kurochko@gmail.com/
   - 
https://patchew.org/Xen/cover.1747843009.git.oleksii.kurochko@gmail.com/

* xen/riscv: introduce p2m functionality (v1)
   - Oleksii Kurochko
   - 
https://lore.kernel.org/xen-devel/cover.1746805907.git.oleksii.kurochko@gmail.com/
   - 
https://patchew.org/Xen/cover.1746805907.git.oleksii.kurochko@gmail.com/

=== PPC ===

*  Early Boot Allocation on Power (v5)
   -  Shawn Anastasio
   - 
https://lore.kernel.org/xen-devel/cover.1727388925.git.sanastasio@raptorengineering.com/T/#m8cac91a93b56a359fa2d5f08596c4be61dca290d
   - 
https://patchew.org/Xen/cover.1727388925.git.sanastasio@raptorengineering.com/

== Completed ==

=== Hypervisor ===

* tools: remove qemu-traditional
   - Juergen Gross 
   - https://lore.kernel.org/xen-devel/20250527132035.985-1-jgross@suse.com/

*  remove libxenctrl usage from xenstored (v8)
   -  Juergen Gross
   - 
https://lore.kernel.org/xen-devel/20250204113407.16839-1-jgross@suse.com/

* xen/config.h: Move BITS_PER_* definitions from asm/config.h to 
xen/config.h
   - Oleksii Kurochko
   - 
https://lore.kernel.org/xen-devel/6b21fb046cf1c8ca760f5ad72fa3cc13b59c4069.1743092485.git.oleksii.kurochko@gmail.com/

* Move parts of Arm's Dom0less to common code
   -  Oleksii Kurochko
   - 
https://patchew.org/Xen/cover.1746468003.git.oleksii.kurochko@gmail.com/
   - 
https://lore.kernel.org/xen-devel/cover.1746468003.git.oleksii.kurochko@gmail.com/T/#t

=== x86 ===

* xen: cache control improvements
   - Roger Pau Monne
   - 
https://lore.kernel.org/xen-devel/20250506083148.34963-1-roger.pau@citrix.com/

*  x86/HVM: emulation (MMIO) improvements (v3)
   -  Jan Beulich
   - https://patchew.org/Xen/729f7896-55b7-4b5b-a7e9-6eb0420e0b14@suse.com/

=== ARM ===
*  PCI devices passthrough on Arm, part 3 (v16->v20->v21)
   -  Stewart Hildebrand
   - 
https://patchew.org/Xen/20250508104608.531079-1-stewart.hildebrand@amd.com/
   - 
https://lore.kernel.org/xen-devel/20250508104608.531079-1-stewart.hildebrand@amd.com/

* Enable early bootup of Armv8-R AArch32 systems
   - Ayan Kumar Halder
   - 
https://lore.kernel.org/xen-devel/20250414164514.588373-1-ayan.kumar.halder@amd.com/
   - 
https://patchew.org/Xen/20250414164514.588373-1-ayan.kumar.halder@amd.com/

=== RISC-V ===

* RISC-V some preinit calls:
   -  Oleksii Kurochko
   - 
https://lore.kernel.org/xen-devel/4ddde60347edf6740fbc69b5739d099616f5b5ff.1743165791.git.oleksii.kurochko@gmail.com/

* Fixes for UBSAN & GCOV support for RISC-V:
   -  Oleksii Kurochko
   - 
https://lore.kernel.org/xen-devel/9fbb5e1389b84bed2e95f99e4c383d0215c7a524.1744889185.git.oleksii.kurochko@gmail.com/

Have a good week!

Best regards,
  Oleksii



From xen-devel-bounces@lists.xenproject.org Mon Jun 02 16:39:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 16:39:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003682.1383274 (Exim 4.92)
	(envelope-from )
	id 1uM8CS-0000t8-VB; Mon, 02 Jun 2025 16:39:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003682.1383274; Mon, 02 Jun 2025 16:39:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uM8CS-0000t1-SX; Mon, 02 Jun 2025 16:39:48 +0000
Received: by outflank-mailman (input) for mailman id 1003682;
 Mon, 02 Jun 2025 16:39: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 1uM8CQ-0000r5-Rz
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 16:39:46 +0000
Received: from NAM04-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam04on20623.outbound.protection.outlook.com
 [2a01:111:f403:240a::623])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2e12b9a9-3fd0-11f0-b894-0df219b8e170;
 Mon, 02 Jun 2025 18:39:42 +0200 (CEST)
Received: from MW4PR04CA0137.namprd04.prod.outlook.com (2603:10b6:303:84::22)
 by PH7PR12MB6720.namprd12.prod.outlook.com (2603:10b6:510:1b3::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.32; Mon, 2 Jun
 2025 16:39:32 +0000
Received: from CO1PEPF000075F4.namprd03.prod.outlook.com
 (2603:10b6:303:84:cafe::5a) by MW4PR04CA0137.outlook.office365.com
 (2603:10b6:303:84::22) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.30 via Frontend Transport; Mon,
 2 Jun 2025 16:39:32 +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.8792.29 via Frontend Transport; Mon, 2 Jun 2025 16:39:31 +0000
Received: from localhost (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 Jun
 2025 11:39:28 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2e12b9a9-3fd0-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=B206H2hna7RIYZzfDLtOj6pX4nUnwp1gPTQg1FlUbAPG2ccfEjrtg6pQiuIuvlzofXg4FnQdG3dyNGnUDR5aXtYxKd+wrXJcus1OaRy5jRFMRVmBETmGHjuAp5DdXsqp16iPrCzoKFXilQ1kyZkjSyUOXHq8Ci1kR66Ft+RxyENIGoVO+maqasWzfJkYNJZINsTglgpswvTjuG4+6wD7UEIXrXh675Ac9wD1PwEPllCtAt6y5nJwhhIbsrnl9AyJIM+pPgMaoNooMAWy5DhRymy0csdEwKS6I9iqHUPht0kdkfnzbRCc7XCOCe9bFXdls2mTJU8zE/aNiHgRKkT3cQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=MNzsK8CGtOthrl6qNLnupbK7S6LGHzAYmm62zD66UuQ=;
 b=X1cFaEsMTVW3FZuhS4njkGcOUiUib6FLGxMws2H68FdEkVcPMvfsZ0fsdRkHfqiHJ5cYaGEtY5Fv4/pO/Dm2SPZKfA1f2N+xoAbkiGvv7CT1oqKhbhStwoCuMqR9S13X6zftPEjvgZrM2rZ79fI/vcGCfXd833u3gLpya3yhg5I3gP50p1SO5tY6AS2btKLzTqdkLfIyCKBRyfWp2hnaAFOH5kBJV74vPRvm75lojOaihfTECrz95oOFacDb3fpz0QJkx0xIbiB2YzSxvNTR03r/a03Dd5gTyQnBRjicTAKZRpAUBP9YapgmaHmsA34PfF5u/qF8PdDRJ83r0U54Yg==
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=MNzsK8CGtOthrl6qNLnupbK7S6LGHzAYmm62zD66UuQ=;
 b=3YHE46waC8YfrRcIbE5yk7OqjIGiVq2fVYYyX0+jq/XGUUrJQTZrzmIMGcqkyke+3hDOubyHK88KvhyTGoghIYp0EDApaH5Tb1uHR0nnd5fDhF7rLh56JDqpkezPNHACxzjuPXWpzpZd9I7Do4gbN4B3VIku6rwtj1HzUUZ2g/Q=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 2 Jun 2025 18:39:26 +0200
Message-ID: 
Subject: Re: [PATCH 07/19] arm/gnttab: Break cycle between asm/grant_table.h
 and xen/grant_table.h
From: Alejandro Vallejo 
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?=
	, "Daniel P. Smith" ,
	
X-Mailer: aerc 0.20.1
References: 
 <20250530120242.39398-1-agarciav@amd.com>
 <20250530120242.39398-8-agarciav@amd.com>
 <5f3de127-70cd-422f-a368-6c23d83c6cf9@suse.com>
 
 <6cc4d172-793b-4d3e-990e-f8fd0d4bbabc@suse.com>
In-Reply-To: <6cc4d172-793b-4d3e-990e-f8fd0d4bbabc@suse.com>
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: CO1PEPF000075F4:EE_|PH7PR12MB6720:EE_
X-MS-Office365-Filtering-Correlation-Id: d8e31b7f-47db-4f97-8f74-08dda1f40d12
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|7416014|1800799024|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?a05Da3U1QjEyRXNkSi9GdUI0ZEdLYTV4VjlYbnk4L3NjRERPYmRuUTEvcDFv?=
 =?utf-8?B?bDRwWjJDa1NHYVd3Z1FOSGsrS01vdDM5Ymo2UDMybkw5VzhKclN0S2NXaEh0?=
 =?utf-8?B?aFVHTnBROEoxYXdES1B3RHFWRFBGeHNkSXJZS3E4aHRQdTIrZTkyRE8wSzla?=
 =?utf-8?B?ZEJtSEUvZVY5WU15VHlRY25GWHhKR0svU3FsVjUzei9CUEp6dlZzamtjazJS?=
 =?utf-8?B?bjg0WjRWZExibVpDWnNGZkZ5UkxvNUwxZVJxb2FlcVFOSS9VQXNyQ2pvSlJh?=
 =?utf-8?B?OUFTd0l6cWNnR29PVzBId3RkOXpick1TWFJzZWNvbUFqQ040Q1BaOS9wUlNT?=
 =?utf-8?B?a3hvSnh5VW9jV09tRlJtVyt0LzU4MDQ5NHZuQWs1Sk1KdnFUNjE2UlBjY0Fv?=
 =?utf-8?B?Sy9rNTgxMnFrZlB3YTJ4UHROS1RycHBIU0t6ZTZVY0tublpkdlVmRDRJNER0?=
 =?utf-8?B?WGcrSStLaTJ2SW0xYktCdlpDSTlVc1JNelB5bDcvbHFqMDdGeEJYQzdJMFVE?=
 =?utf-8?B?SlVPWWNsWjFkWW8wRmkxRmxocVNISytzTFVtcW9PbHUySUtiVzBvTGtxdTA5?=
 =?utf-8?B?RGFCQi96NW5EWU1jend3NnVubEdNcEkvOHJUaGp0YlFEcEpFV0pwY3lmQ2I3?=
 =?utf-8?B?ZnZPSUJOdmR4OFBJVFg1dXJnL054NkcrTjJBc20rTnJlS0tEOGlRSXkwSEVG?=
 =?utf-8?B?YXNXK1NjQXRrUmg1Z0hDS0NMcWF2Z29GTXNTZDNMS2Z4ZE96dWZxLys5Qkt0?=
 =?utf-8?B?VlBXQ3BheGF6VVkrR1Btd2pBRHYxZDIrczZCRFUrdzNzbE5ZZUhMaXpmZWJu?=
 =?utf-8?B?YjB1U2MrSFBGbStBeWliTHFyby8zSzVFWm53TFdoMG9WZ2p0Vkc1TnZ4OFZD?=
 =?utf-8?B?SEtuR21EcEdJWlI1RUF6czlpVjkwaTREZm14KzZHc1hyVSt6VWFpcTJwa3cx?=
 =?utf-8?B?SWtWeXh1TUJHcFJBR3orSGxBR284SmU3RHZrN1kwbitlYUhpYzcwRElnOS9W?=
 =?utf-8?B?bStzK3hkeWpYejlDdmZVTXB0MmFjSmt4NWNaNXJZcUhGYW9FandSeWhRbEdT?=
 =?utf-8?B?a2s1S3cvOTRXQUNHbnRMczl0WWxtWjBEUkQxQjd2RkcxL1ZSL08rV2Y1Nzh6?=
 =?utf-8?B?aWxyU0RpSzZvS2FmOVVUNkt4Qmh2U0lQMFdPNVZCSGNCRXAzN3gwbEQ5ai8z?=
 =?utf-8?B?TmZMdEpQVDFHZlhJME9wT2VKbU5CTE53RU44eGY5WnRLUXpmKzhnZDZtYkdQ?=
 =?utf-8?B?R2VqRmxCUkpXZDYyUE45U1FYSmp4SWhpdzgwZ1lzcnlKV1RVYUpwTVVUcldZ?=
 =?utf-8?B?SWE5YVZPOGdOQnJkS1UrOE1yK1kxNFVCUTlJYlpqOGk3c04yNFN1cm5Ra3dJ?=
 =?utf-8?B?UjE2Zzdidk1Ud0hZWFplcjFLdWt1azZveWZwcGhtbnJpaG5vM0E2MzFTdHVh?=
 =?utf-8?B?ZzA1ckFnTUVka01JN1ErWklLUUUxajBOT2RybnJlVnIrdWM4WU1NNVJzKzlZ?=
 =?utf-8?B?VjM3cVExdm1FdGI4QVB2cGQyamV3dlZZTG9ic3lmZW8wSDJXcmpJV0NmYXV4?=
 =?utf-8?B?aVo3RVJOVWE5SXpVY2tKVTJaNnJZQktNeEhDMUxmbFhnUmNBQTVHNDN2eGlS?=
 =?utf-8?B?ZlBMQ01ObmozbGNRV2RmOFV4M1pneDZpZllXVUlaUkZYZlBYb1QzakVZRjdk?=
 =?utf-8?B?c0hOdzdLME1nWWVickZDajFZUGdldENHQTFQQ3FjYXZxenRlbUxEK2tENXd6?=
 =?utf-8?B?bUF4elNmS2U1VXZ6Y0NTWEM2WHJHT29BWDh1SWo3OUtCY2xMcnNiZTBPL3Ny?=
 =?utf-8?B?cjdHdDJVOS9ITE9yVXAwWFRDSERyWGpqcW1wLytHQStUQWIrbm8zc3M5ZGVv?=
 =?utf-8?B?RnBmTXFTS01CbnU1T3AzSytBVXVPcm1FQ0lzUjhaQXFVUzFkOTJvOFRZRzl1?=
 =?utf-8?B?MUgzVHNxdzVZc3daY3I2WlhpcGRGdTBTU0dRbHVDTkxyTStDV0MwWk9jS0xk?=
 =?utf-8?B?UDRxckhWejhXUGcvdjYxRnozOGFVYjlKcytSRzZ0NEp0QThhOWI1TDJpUHJU?=
 =?utf-8?Q?o8zsfi?=
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)(1800799024)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jun 2025 16:39:31.8415
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d8e31b7f-47db-4f97-8f74-08dda1f40d12
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: PH7PR12MB6720

On Mon Jun 2, 2025 at 4:51 PM CEST, Jan Beulich wrote:
> On 02.06.2025 16:30, Alejandro Vallejo wrote:
>> On Mon Jun 2, 2025 at 9:53 AM CEST, Jan Beulich wrote:
>>> On 30.05.2025 14:02, Alejandro Vallejo wrote:> --- a/xen/include/xen/gr=
ant_table.h
>>>> +++ b/xen/include/xen/grant_table.h
>>>> @@ -27,7 +27,7 @@
>>>>  #include 
>>>>  #include 
>>>> =20
>>>> -#ifdef CONFIG_GRANT_TABLE
>>>> +#if __has_include("asm/grant_table.h")
>>>>  #include 
>>>>  #endif
>>>
>>> This change looks wrong (or otherwise is lacking justification): With G=
RANT_TABLE=3Dn
>>> the arch header isn't supposed to be included.
>>=20
>> It's not equivalent to the previous code; but that's a feature, not a bu=
g.
>>=20
>> Not including the header with GRANT_TABLE=3Dn  was the best we could wit=
h
>> the older toolchains in order to not try to include a header that might =
not
>> exist. The high number of sequential inclusions of xen/grant_table.h and
>> asm/grant_table.h seem to attest to that.
>>=20
>> I can ammend the commit message to be clearer, but IMO this is what it w=
as always
>> meant to be. I can replace the current commit message with:
>>=20
>>   "The previous toolchain base version didn't provide __has_include(), w=
hich
>>    allows conditional inclusion based on a header's existence. Lacking t=
hat
>>    feature the inclusion was guarded by the GRANT_TABLE option being pre=
sent
>>    but even then sometimes the arch-specific header is required even whe=
n
>>    the option is not selected. This causes inclusion sites to needlessly
>>    include both asm/grant_table.h and xen/grant_table.h.
>>=20
>>    Using __has_include() removes this requirement at inclusion sites."
>>=20
>> Thoughts?
>
> So why would we include a header we don't need when GRANT_TABLE=3Dn? Over=
all
> we're trying to reduce dependency trees rather than growing them further.
>
> Jan

Because we do need it or the code doesn't compile. gnttab_dom0_frames(), fo=
r
instance, exists and is used in unguarded statements. There's more case lik=
e
that. It may be possible to break those dependencies so the inclusion is
not always expected, but the reality is that you tend to need the other hea=
der
for pretty much the same class of reasons you needed xen/grant_table.h to b=
egin
with.

Forcing the code to include both seems counter-productive to me.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Mon Jun 02 16:40:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 16:40:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003686.1383285 (Exim 4.92)
	(envelope-from )
	id 1uM8Cr-0002CU-8K; Mon, 02 Jun 2025 16:40:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003686.1383285; Mon, 02 Jun 2025 16:40:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uM8Cr-0002CN-4K; Mon, 02 Jun 2025 16:40:13 +0000
Received: by outflank-mailman (input) for mailman id 1003686;
 Mon, 02 Jun 2025 16:40: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 1uM8Cq-0002AB-CO
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 16:40:12 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20617.outbound.protection.outlook.com
 [2a01:111:f403:2413::617])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 405fe94b-3fd0-11f0-a300-13f23c93f187;
 Mon, 02 Jun 2025 18:40:11 +0200 (CEST)
Received: from SJ0PR03CA0126.namprd03.prod.outlook.com (2603:10b6:a03:33c::11)
 by SN7PR12MB7854.namprd12.prod.outlook.com (2603:10b6:806:32b::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.20; Mon, 2 Jun
 2025 16:40:08 +0000
Received: from CO1PEPF000044FA.namprd21.prod.outlook.com
 (2603:10b6:a03:33c:cafe::7d) by SJ0PR03CA0126.outlook.office365.com
 (2603:10b6:a03:33c::11) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.19 via Frontend Transport; Mon,
 2 Jun 2025 16:40:07 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CO1PEPF000044FA.mail.protection.outlook.com (10.167.241.200) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.2 via Frontend Transport; Mon, 2 Jun 2025 16:40:06 +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 Jun
 2025 11:40:06 -0500
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 Jun
 2025 11:40:05 -0500
Received: from [172.27.195.250] (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 Jun 2025 11:40:05 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 405fe94b-3fd0-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=wXzH5qATohfJvDhwr1ER5SWkh4U0/FJ9rPGOPPZwNDrhG/6eQeLEElkeX4/Mkyyam/XdGmH8+2iHhVmPHApcMkN8QtOJaAzkjw+W8s5JhU6AnmPSb+S63+cVLei5uBmQEzJTm6ufttyDVmNiIjojqYRVwGiXbsaG9GGkMZ/Vf9spaZmsSzZ3VgDG4f/BApevczkELaRdOsvkqbnWU48KwHNS2rF3inF665WB/wZlSqEUKwSPAJFxWyo3q8Gq0lM7JV9tUnJ3blfTiLy2DDnM1Hg+8a/n5KNTE4Oyrr3QHwebsB7MS9l8XiF0xE+aYNcIkxNJHxH0AfhWv6rBRtd6jg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=vDdKz5+HTZX2WoZC+WW4sTbm2S/2Jml6w9rzHsFx4YU=;
 b=LrNHmkBmITLuI6P/qfxuZ9UFO4bZYZ06xjr9VBRZs32xF4AYF5471QnWT7KqyIRRENiibrI14EGRcRuyVlrR72MkmzKBzSS9yYqUkFC0d8Lq2PVCxDJlNBQCju8qfP0OEX0k/Mo0r44PKEInfjeVYIoZj88xyUTkO5U1a4AFqGkQ7HQh+DcN+2WNFd0igbe/L0EkSwfpLr2NHSU+nAjCq93Zxnm56owWvRj0K0u2v1Q8y9J6F0xHmyd6DENN8IWmRreJ1oxvNe6OSAK98r31PVpZhv3WtJFB/ZCr01yHbA1xstcGGNccRvcWZSGBMxQb5SmRQ1qZEGznQs+uNOr8cw==
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=vDdKz5+HTZX2WoZC+WW4sTbm2S/2Jml6w9rzHsFx4YU=;
 b=ZIzMrAWg3rSGo0hswLJcluv9UhG4eutFqFWym9GRHs2mVKL2Q9vpmc2qUI5JiKM3oT5xuQeSRifVk/IslTePdiT/kItj9Jdkz2sl+jWt+9DrBT0NkuTpn5qxy5wV8ab57B/ucNDyMUdipvumVhQG00sM3uFlJ73zwax8lclvzIo=
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 Jun 2025 12:40:05 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 02/19] x86: Add missing pci_dev forward declaration in
 asm/pci.h
To: Alejandro Vallejo , 
CC: Jan Beulich , Andrew Cooper
	, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	, "Daniel P. Smith" 
References: 
 <20250530120242.39398-1-agarciav@amd.com>
 <20250530120242.39398-3-agarciav@amd.com>
 <9b5a1599-d8dc-423d-b144-90bfe33cdae9@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
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PEPF000044FA:EE_|SN7PR12MB7854:EE_
X-MS-Office365-Filtering-Correlation-Id: e8578d7c-26d3-4947-9240-08dda1f42204
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?bTEvTEd3UG1Vc2NlZ2FycGhLLzBwNHVSckwxalJwTzRuWUlDQmlCRHhYWkk1?=
 =?utf-8?B?RFA1VG1lK3ZSUE5LdkhCaWkxMFBqK3FXa0lCR2tlZTMwcjFIRDh4bW9XN216?=
 =?utf-8?B?QStvVGF5d1VhaFh3YUlOU05tQ0M4c3hEZDRteDUyaXlPeVg1N0UrK0g0S3ZH?=
 =?utf-8?B?VGMvNGFWUHJEQm4yNHhrVXZLaXZ3ZmxmUFplWnB6S3Nwd2xPeHg2bk1DWUpY?=
 =?utf-8?B?TDNqU3FhRGJNYzVqQWgwMFpub2o0SXorb2tvYUhzUk5IdTcrSG95RE1LVm1W?=
 =?utf-8?B?Tml2MXNMVHBQQ2xTKzd1ZHdiQ3dROWU3STFzNGlkaitaN1pucFRiajFCTm9Y?=
 =?utf-8?B?ajdMYTVuOVRzYzgvRGlvbDhBNmtUNnlTcFo4SVh5YVJ4ZlJFVHRJNUxjQ2dD?=
 =?utf-8?B?SC9wTVMvQWlBeURrY3c2ZU9FRXBzSkFuaGgzOG50SlhFaEZadWcrZHBnYjA2?=
 =?utf-8?B?akZDRFhaYm4reEF0VkFENVd1VklnWXZTSGV0Tzh2WjN5UWhETWR3MXQ4NDdI?=
 =?utf-8?B?N1JpRFEyekQ3WE5yUUtxNUhQWEVsejhkL2dMNktsMElkcDJzS2h5Vks3Zkdo?=
 =?utf-8?B?SWlwMzdpeXNZMldjdmdWY0RJOWpaTWYrY01SNTlycFRoUVYwNEdzRHpKc2U0?=
 =?utf-8?B?bG5JM2VhSzVtZU1EK0k5TDhYaC9GWHNXalNNNzZwSjNsOXQ1eTdkdTJuRHZ4?=
 =?utf-8?B?NGxQVU1BeCtpR3hCQVY2cFcvNnBmcXVnTUJneU05Y3BPWTdCOC9OWDdXODZm?=
 =?utf-8?B?UnhUb2FjMVBnNWVwNWt5NTVBSVFYUVN5dkpaa1A3SWk0VTFYendxdURHZFhW?=
 =?utf-8?B?Y2l0VXJ5QnBaOHVPVW5iSGlnWE9YQ0V3dXltN3ZLWUc0QXo2UndqNS9TNzNK?=
 =?utf-8?B?NHFJT1JlVjZFSkFnUDM5Qy9wbnV2bXZmaEZud0hTZGI5YUI0ZzBqczBQaHZv?=
 =?utf-8?B?dlA4SEdLamQ4TXlrY1NkWis3RjYrM2J5azlpdUJyTjAreG85WjcrOXdpSURL?=
 =?utf-8?B?TUxJSnVLcDBxUk1TV2VLaFZuSWczZzNodG4ydDFtZER6emlEaUd0Zk0xSUxk?=
 =?utf-8?B?UUdPUDhVbmhnQ2xUNjdBMUtiUnpIWGdEMnFjWXZCbTlYdnVaRXpIdVh5WnlC?=
 =?utf-8?B?emQ5NUtjNlFSTDhtTWJIL2VvNUhTUHJEazh2TGsxMlBSMm0zSzR4aW1JQnBN?=
 =?utf-8?B?NGpwd0tma29ZTnU1eWJlOG9mZ3VIQ0xKdm1yTHlQK09TRDVmYnVqeEJXYXJw?=
 =?utf-8?B?QXBYbzdEWVZPYmhjbDltbU1naWtiZy9Mb1hSSE1RY0hFR2JTNnhOS3RpeEpM?=
 =?utf-8?B?ZHpwMUdrYzFhQndiWjhuQ1Yxc0ZNdkZHT3hoa2ZsS2lodEYrSHg1Tk1qWjk5?=
 =?utf-8?B?NUIrN3ZHVG1DWmZMK24rMEREYnN6Z3EvM2swTU9pelNSbHNLYzVGMGlDd1dV?=
 =?utf-8?B?NHc4RU92RGVORlZkT2lOcXlBOFdHQ1hjWXNUb0U1NTVPS2ZtcllmN2lNLzl4?=
 =?utf-8?B?Y20vNHZmZDhxQkR0UDJpbXpELzJ3aWRjUnlJWlluTWRJTHgrK2N0N1pFdTBT?=
 =?utf-8?B?bldBV25FV2tyY2dseWFSeVBGb2MxRnY1dkRGa2tuRmFtWHdkZkZ2Lzh1Z3Q3?=
 =?utf-8?B?Y3A4VzBxdFhwS29VbnRHSkRURGdVQkNBL09uL0VBbFdHUGRVanZlNjYrcDRz?=
 =?utf-8?B?U09Nc21pL0E5b3NhbTlCcXkzMlgvOUpMUi9Gd0dXWWlQdEgyQWhLbFY4VjRh?=
 =?utf-8?B?N05zOXpYTVd0dm13R3F0Zmw4Z29pQ1p3dFdES2tUV2dVeGZLQVk0SC8zekJ1?=
 =?utf-8?B?MVd2Y3RzL0V2TWRKeExsbmNIV0ZsckNVMFlRUWhUTEdhQmlrVTU5QVFrRFdu?=
 =?utf-8?B?ajdVQmM0MjlqK1NtOXNtcU9acUdmUER1alVtZ2oyd01jNG5UNDdOYVlHekRV?=
 =?utf-8?B?NktMQzFtOURzVHBHb0ZGaUllREdQQTZQVHZQak02a2NMSHhwWkR6VTlXRU4w?=
 =?utf-8?B?RU85eGZZeXlrMVFFTzhqaTNDaWhNcERoRkJOSkp0bUt5SjJwK2VjeVdtSlVr?=
 =?utf-8?Q?QvK0me?=
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)(82310400026)(36860700013)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jun 2025 16:40:06.9827
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e8578d7c-26d3-4947-9240-08dda1f42204
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:
	CO1PEPF000044FA.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7854

On 2025-06-02 09:45, Alejandro Vallejo wrote:
> On Fri May 30, 2025 at 11:04 PM CEST, Jason Andryuk wrote:
>> On 2025-05-30 08:02, Alejandro Vallejo wrote:
>>> Not a functional change.
>>>
>>> Signed-off-by: Alejandro Vallejo 
>>
>> Some sort of reason would be good in the commit message.
>>
>> "struct pci_dev is used in function prototypes within the header.  This
>> is in preparation for including (transitively) in device tree"?
> 
>>
>> ... I'm guessing that is why.  Stating  it would be better.
> 
> Yes, but I'm not sure the second part of that explanation is relevant. Unless
> specifically noted in the header, they are meant to stand by themselves when
> possible and not require preinclusion of something else (in this case, xen/pci.h).
> 
> This patch would still be relevant (imo) even if I wasn't using the header for
> anything.

Yes, this could be made as a totally independent clean up, and that 
would be fine.  If this is a prerequisite for some later change, I think 
it is useful to highlight it.  It would not otherwise be evident when 
looking at the history.  Because I haven't gotten farther into the 
series, I don't know if this patch is an independent cleanup or a 
prerequisite.

>>
>> With a suitable reason:
>>
>> Reviewed-by: Jason Andryuk 
> 
> Thanks,
> 
> Does this sound reasonable?
> 
>    struct pci_dev is used in function prototypes within the header, so it must
>    be forward declared for asm/pci.h not to depend on xen/pci.h being included
>    first.

Sure.  Or just:
struct pci_dev is used in function prototypes within the header, so this 
forward declaration makes it standalone.

My point is: we should explicitly state what the patch is trying to 
achieve.  It helps reviewers and future git history readers.

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Mon Jun 02 16:40:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 16:40:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003695.1383294 (Exim 4.92)
	(envelope-from )
	id 1uM8DN-0002nX-FG; Mon, 02 Jun 2025 16:40:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003695.1383294; Mon, 02 Jun 2025 16:40: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 1uM8DN-0002nO-CV; Mon, 02 Jun 2025 16:40:45 +0000
Received: by outflank-mailman (input) for mailman id 1003695;
 Mon, 02 Jun 2025 16:40: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 1uM8DL-0000r5-SD
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 16:40:43 +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 52beb384-3fd0-11f0-b894-0df219b8e170;
 Mon, 02 Jun 2025 18:40:42 +0200 (CEST)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-604f5691bceso8331506a12.0
 for ; Mon, 02 Jun 2025 09:40:42 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ada5d7ff25dsm820184266b.23.2025.06.02.09.40.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 02 Jun 2025 09:40:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 52beb384-3fd0-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748882441; x=1749487241; darn=lists.xenproject.org;
        h=subject:from:cc:to:content-language:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=XOkZmKx8zTwCq0REpLaY9J/as7EWIHf65KSPJyIY2l8=;
        b=mIX/B2CldssnnbpIHaWCUkAqfLBhM4yPoAvIVnPvS9eVk5KnRaz2JY53++7K4SefLV
         DEG3APThfkSxzRVJpXjO8uq3gZCIGmTxIff2GxvWtBlHbBybN8N6PhJ4TYL6VYBcyYTi
         r1avMy7QA37aDN3eUWW9ZaK+d9Ho6/lE7evh5/6wuR5IncmxWIsHMjDHgXHu3f07CewP
         FbYCwwu4T50HHwe2gmolX6xKTrlm0A3GyKbv+hbTys0O4kwuXDY6RG38M6d8jZTtYmM7
         4gHxGUarkYj9QP7OBMRQiw6fseCY0ts3NQDFe+Z542Vx3DQfHdXlBGszD3e1Scf3Q7Yk
         z39w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748882441; x=1749487241;
        h=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=XOkZmKx8zTwCq0REpLaY9J/as7EWIHf65KSPJyIY2l8=;
        b=cYF7tKoFwoM9CaX80opSDqS+l8mReZ2wU1XnJ1b8d9SG3t/beeZhYWoiCkvnorkT0j
         3HQJVwKN3GkvQQZ5YBtsB3rvvguFfd/R9jdlzO4UMP5alohKt6CczJsAkeBpAQ9VjMbM
         EL3qUzatc+62PPcyqD8WYXrkeLmmmHYgdKHwC01bwZhGdV1hF8bgIUbwirMhjXltRl87
         jhplZIu9PVJpqmhzk1hH0yNAN3zj3SM6ra8zIHC3Hk8L94Vnf42QmZ0gVFwPs87JGnYP
         Z6HWhZHCfcO2GItwe08Xt9NoqiiWDvx4d6v6+j5atMZuLqhysyXpV6Lq1qcl0TEY6fTZ
         +UHQ==
X-Gm-Message-State: AOJu0Yyv3pSP5a4v2AiGf+NRnNvTAj8DH00Fe8szSfJyKtKMox4pYqo1
	oTcYyRFtEUOlF5X9i0hkS/SkirS4LapX1w2WNPe7cWjWZ2QtrpQZZc82UUxKvg==
X-Gm-Gg: ASbGncvH1KCFX9++Z45sWiG5eQPceVpqJRgUrXElYHMvNkCnZFr4oXIeFVYpcH252Qm
	UT21jslIofkF1eL5IwnhKAVGnQFOWPAh9jbZX+jyRZQn5w1vrhYFZJrY1iBZrRhSk5UShBMH4md
	tjxMA/0ISaqXJOiix5q3Yf7UsnROxMglxr2i89aPBnROd0yt45PI9A1C7WH0gYteAI3NNPztLLe
	0RJZdCYmcWAovkkReMvvFFi0dMIuAbwowkw2gUu+5CPN9B1IzsLXLoCntlZJotRwtInZPv/D7RL
	ZUctrAAkftveaDI9EmgUGhSgmFGmAZ4epOW+ZnEQygbw05io2LG7dF+jCvUve714kfISmYBlS5X
	zg75x1jLOfHsEHh3X0tYC6kjlDZmMM2DfnNs=
X-Google-Smtp-Source: AGHT+IHLBUGYE718BADnLJ9/Ho8abkTMJ7ZogAQnrdOAxssdVBBCfo1ip8zw6lsStAohAqZNcnp8/w==
X-Received: by 2002:a17:907:7e96:b0:ad8:85df:865b with SMTP id a640c23a62f3a-adb322fcebbmr1346065066b.33.1748882441154;
        Mon, 02 Jun 2025 09:40:41 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------TCdXds4BUlSw8kCFfoXdRFBM"
Message-ID: <08d11677-8a2f-4777-b84a-7c909f3a87ce@gmail.com>
Date: Mon, 2 Jun 2025 18:40:40 +0200
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: Xen 4.21 release schedule

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

Hello everyone,

As there hasn't been any feedback on the proposed timeline shared here:
  https://lore.kernel.org/xen-devel/666e3f49-2f92-4828-8897-8579832bcaa2@gmail.com/T/#u

We can proceed with the suggested timeline as the release schedule for
Xen 4.21.

I've updated the Xen 4.21 Release Notes with this schedule, which can now be
accessed via the RN link:
    https://xenbits.xen.org/docs/unstable/support-matrix.html

Best regards,
  Oleksii

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



  

    
  
  
    
Hello everyone,

As there hasn't been any feedback on the proposed timeline shared here:
 https://lore.kernel.org/xen-devel/666e3f49-2f92-4828-8897-8579832bcaa2@gmail.com/T/#u

We can proceed with the suggested timeline as the release schedule for 
Xen 4.21.

I've updated the Xen 4.21 Release Notes with this schedule, which can now be
accessed via the RN link:
   https://xenbits.xen.org/docs/unstable/support-matrix.html

Best regards,
 Oleksii


    

  


--------------TCdXds4BUlSw8kCFfoXdRFBM--


From xen-devel-bounces@lists.xenproject.org Mon Jun 02 16:41:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 16:41:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003700.1383304 (Exim 4.92)
	(envelope-from )
	id 1uM8EQ-0003c6-TT; Mon, 02 Jun 2025 16:41:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003700.1383304; Mon, 02 Jun 2025 16: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 1uM8EQ-0003bz-QC; Mon, 02 Jun 2025 16:41:50 +0000
Received: by outflank-mailman (input) for mailman id 1003700;
 Mon, 02 Jun 2025 16: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 1uM8EP-0003bl-Jl
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 16:41:49 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on2062b.outbound.protection.outlook.com
 [2a01:111:f403:2413::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 77bfa650-3fd0-11f0-a300-13f23c93f187;
 Mon, 02 Jun 2025 18:41:45 +0200 (CEST)
Received: from BY3PR04CA0024.namprd04.prod.outlook.com (2603:10b6:a03:217::29)
 by SA1PR12MB8094.namprd12.prod.outlook.com (2603:10b6:806:336::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.29; Mon, 2 Jun
 2025 16:41:39 +0000
Received: from CO1PEPF000075ED.namprd03.prod.outlook.com
 (2603:10b6:a03:217:cafe::94) by BY3PR04CA0024.outlook.office365.com
 (2603:10b6:a03:217::29) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.31 via Frontend Transport; Mon,
 2 Jun 2025 16:41:38 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CO1PEPF000075ED.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.8792.29 via Frontend Transport; Mon, 2 Jun 2025 16:41:38 +0000
Received: from localhost (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 Jun
 2025 11:41:35 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 77bfa650-3fd0-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=aOKaMqneAjJlxfeTUGBrBPPgfUNEGDBMY6upTgx/J2mNY2UTUYRa6dmHV577CcmpKnCcI6JGCFOlwVoMBV5HZ7TJYhkUShbn2MVBSW9hwRP7P7pW7Ddg+9B/OE2FhWULS041H6byV+7OxdusIu1nF8bvnNxMc7ZA4cuI8sKKwvhCP2fVFdAxm56/5Y7MKkPUguyubOW3jsTLKK54VlCnPGkzwMQRfcJV5VFccQkhgKJl59LCJ5/xGFaw3qaXTHiTGCwqJPHdSdUC32FSy4fXITIb4GFx+sV7Y6F4A3T5YiJZTU7BNyQixdytqanr3SDe4lCo54C92hmEp4wJNa1JKQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=cPzhhFORRxrPRrBINMIKY8HmPHg2kNYgIDwDeoItZP0=;
 b=anUPfcsZeZhGbQH+YT5627gAIlK+7kZ6Y2xsKvNpM2XHYUnLxbzGjednGGCQ+Hswyz7uiUJnx3wN8o5AIj+NW6s2qfABjjYE5ZQ84LwLn9yC/UuOQox8SJkWMg6gf+TLPPp6sznkCgHKBp9eqPCKT5hyAh/7V9GMOELDGswpoIjlyAhk8VDKl4FAonDfgOwS4EHHlvaiT8Ut0vSje+ASye0dSl27mT9b1Rh+cBgJOcmLFxy+BAsf5JwkXIuxQCRILwOxl+8PNBA4R9iP1iwXGlvLt56QpoxrmPe+uigGM+WsnPoY2l1UzFJssSm8taW3YFXfJjDV2db8FCsouPaSKQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=proton.me 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=cPzhhFORRxrPRrBINMIKY8HmPHg2kNYgIDwDeoItZP0=;
 b=UVcuW5pSBPBfDb89xOqBygxSNEZ9UMcWR8SIYORDpvFOEsMFl3H83vN3PLeKJZk9viUTEtuAzflWe1fQDDQmztji9toK3i3EEb/n+J4rcOozfRTK4u6hBGsFKdL23pA+jPbAeRLV1D93inCL5fDRZISyVol+GuWN0iKADG7jU6E=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 2 Jun 2025 18:41:32 +0200
Message-ID: 
From: Alejandro Vallejo 
To: 
CC: , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , "Daniel P. Smith"
	
Subject: Re: [PATCH 12/19] xen/dt: Move bootfdt functions to xen/bootfdt.h
X-Mailer: aerc 0.20.1
References: 
 <20250530120242.39398-1-agarciav@amd.com>
 <20250530120242.39398-13-agarciav@amd.com> 
In-Reply-To: 
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: CO1PEPF000075ED:EE_|SA1PR12MB8094:EE_
X-MS-Office365-Filtering-Correlation-Id: d6bdc5bb-6804-4153-952b-08dda1f45893
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:
	=?utf-8?B?dHE2T2FCL3JXN0p2Y3ZqRmlTTk03R3d1WUZ0YUZBRUdRUS96SXlPM2FudGRv?=
 =?utf-8?B?TmRpQmR6M1ZqOXFncmMxdzIvbkU5c2dTMDVrUmhCS3F2bHJFTVlnMEFLSHEr?=
 =?utf-8?B?RS8reUtqajBBbXYyOEkycVMxcm1xRzFMUTRNbTd2VlEwOFdGcFgycnBnUU81?=
 =?utf-8?B?U1hsM2g2aDhRT3JMQTgwcDg0S3A5a2dhRHZlTlcvMnRMZlRGZ2QvSFR5NDNu?=
 =?utf-8?B?SHRQMXp5ZWsxeGpuT3J3TXRyZEZQQkNvNjExbm1BT3hOc2hLWC9TNU9JSWdP?=
 =?utf-8?B?RFEwMGxyWGpaOEVQQnFTN00yU0hQL2V3QWUwSmNRR05tV0hmcHJNWkd0QXZ0?=
 =?utf-8?B?ZVhvK05ZNUhlMTBBaFNOUDhlQ0J3ZFlVNlRDdld6RU11ZkM1L08vWnlxNVpM?=
 =?utf-8?B?L2dSeTRnNHlrNSttYTE5MlhhdS9oUFVNSnRScHU2eVV0U0lmWGR0eWpHakE5?=
 =?utf-8?B?Ymx2OUJYUkpoN2hhZW9vQWhyemNDUFh5enhkdmtzV1A2WUdNVEZJdnJZNnZI?=
 =?utf-8?B?UTJmNzZKODdJcjVZbDk3ekxWSEM5U2g0Z3h3dWpsR29ObUc3RVMrNGd6VHgx?=
 =?utf-8?B?Qm1ESjhqK2VJWXFDU3dxWkNjQ0Fkc2tDYWVhZDl0K2VnRDBSbUtQWXhPVjRC?=
 =?utf-8?B?VE5PUWVkOUNnamZrOHM2Z3QxTW9HM2toZ1A1VjRpM1ByVVN6RVQvQWtwT1I1?=
 =?utf-8?B?K21mejF1QmZIN1dXYXBKdThSQjdnQ2xscXoxdXBDWnY0TDZGRlljZlRqYk5N?=
 =?utf-8?B?WGl6SXNqRStBL3JCRmRhK2JQMlZWdmNGdjg3cUF4eXpNSkhjc2dVdVR1OGFj?=
 =?utf-8?B?Q1RJU3REVERZSXJkNXFDekpFNUdLSTcvUmE5d05zSUlWeHF4aEFqRXZvMmlL?=
 =?utf-8?B?RmRVQ1YzZGtWaHRTVlM5cTVqOGxGZnR4a0JEZTdHMHl3R29iSHI5WHRTSTRQ?=
 =?utf-8?B?OThxYitYUGtPUlFtc09TRFQ2eGIxcUJFbXZ1VW43SDNnblVMNDE1dTlJWnov?=
 =?utf-8?B?NFRGYm1nOXdmOUxrL0ljL0RON3B2ZTI3end0V2ZSdDVmc1lFSStXMTE2aFFP?=
 =?utf-8?B?aXh2b1U4VnJRd1REVDFJNXc4RlFGU09zRXdmRmNvS0c1L1U5UWQyLzRKNHFQ?=
 =?utf-8?B?MEJQSkgxWUNRNVBhSHNSczFuOGdYaHRJNGFmVzNkaUxXelBkU0UxMEhiTjVF?=
 =?utf-8?B?cWl5Ulppb2hxOFFWMXRJNVJlR3dUeWx5b3pYdFdSb0VuUzVnREpYWkpTdnRn?=
 =?utf-8?B?K095R0p6d0gyN3FHRmVUeDVwb3dZdmlpSWNxTWo0S2s2MlBhZDJvN2NhNjd0?=
 =?utf-8?B?cTBTZDI0dTR0VXdCVzdpSmp6L0lwN0U5YUsvMjJ2YVlRZHBjMmJIN1AvYlZZ?=
 =?utf-8?B?VGZ4TDJFM0dOdHlrblcwTy9kUHdxc1NUc3FGZVNIa0o1QUNZWUduY2dTNVdJ?=
 =?utf-8?B?SWo2Q2U2UWpmRzk0dnJpTlVLbFkxdGRyRUc5SmpjMGNJNkl6SGpLQXNsYlNT?=
 =?utf-8?B?azBtRjJ3RlJqUytKVjhxSXhMVVc1S01sQW1HWGdKR3V3enRDdkJKMm83cEFL?=
 =?utf-8?B?STRRQXhHVGJNbWhjV2RydmhSd1Fxa3JBSjNoZU5ObXl6VnoreC9FRExzNnUw?=
 =?utf-8?B?TjkzU1RNUHBaNGJDMXRuaFZtMHB2YVJjMVlWZEJ1ZytXL1NDNU5pbUVpTWtu?=
 =?utf-8?B?RVBpQjVvV2FkTW96cXlnbDJOUDc5alBvVjV3RlUvMDd1SEhHTmpYTllCOTgw?=
 =?utf-8?B?Yk1SZ25Tc1ZUQlppK2Z5eFJ2VE1PdVY3UjgyeGdOUTNwUnM2Nm5WNDBMY1ox?=
 =?utf-8?B?QzZseW5uSXVVN0JPM2RwNFpxK1A0T1V5TmlSVElzRWpOMmtPbGhoSDhxK0tv?=
 =?utf-8?B?bUcxUTlGanZtSzE5cFlLL1VUSzlqczJXd053NmphNHR1YmtydjZRNDVPM3d5?=
 =?utf-8?B?OU1iTkpMZ3U1bUtyNG5tYlZETnlNQWZmT0VuSGlWNnQxQUhaQjE2b0N3dVN1?=
 =?utf-8?B?emxuZmc3RzBETU8vbkY1YTVZVGQ4c2NkbjZhNGRqaEMyK0FjMjh6U3FtMk01?=
 =?utf-8?Q?uwias9?=
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: 02 Jun 2025 16:41:38.5175
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d6bdc5bb-6804-4153-952b-08dda1f45893
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:
	CO1PEPF000075ED.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB8094

On Sat May 31, 2025 at 2:35 AM CEST, dmkhn wrote:
> On Fri, May 30, 2025 at 02:02:20PM +0200, Alejandro Vallejo wrote:
>> Part of an unpicking process to extract bootfdt contents independent of =
bootinfo
>> to a separate file for x86 to take.
>>=20
>> Move functions required for early FDT parsing from device_tree.h and arm=
's
>> setup.h onto bootfdt.h
>>=20
>> Declaration motion only. Not a functional change.
>>=20
>> Signed-off-by: Alejandro Vallejo 
>> ---
>>  xen/arch/arm/include/asm/setup.h |  6 ----
>>  xen/include/xen/bootfdt.h        | 62 ++++++++++++++++++++++++++++++++
>>  xen/include/xen/device_tree.h    | 34 +-----------------
>>  3 files changed, 63 insertions(+), 39 deletions(-)
>>=20
>> diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm=
/setup.h
>> index 0f9e531a34..32308837a9 100644
>> --- a/xen/arch/arm/include/asm/setup.h
>> +++ b/xen/arch/arm/include/asm/setup.h
>> @@ -55,12 +55,6 @@ void setup_mm(void);
>>  extern uint32_t hyp_traps_vector[];
>>  void init_traps(void);
>>=20
>> -void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
>> -                         uint32_t size_cells, paddr_t *start, paddr_t *=
size);
>> -
>> -u32 device_tree_get_u32(const void *fdt, int node,
>> -                        const char *prop_name, u32 dflt);
>> -
>>  int handle_device(struct domain *d, struct dt_device_node *dev, p2m_typ=
e_t p2mt,
>>                    struct rangeset *iomem_ranges, struct rangeset *irq_r=
anges);
>>=20
>> diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
>> index fa65e8fcf4..079259c719 100644
>> --- a/xen/include/xen/bootfdt.h
>> +++ b/xen/include/xen/bootfdt.h
>> @@ -2,6 +2,7 @@
>>  #ifndef XEN_BOOTFDT_H
>>  #define XEN_BOOTFDT_H
>>=20
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -16,8 +17,53 @@
>>  #define NR_MEM_BANKS 256
>>  #define NR_SHMEM_BANKS 32
>>=20
>> +/* Default #address and #size cells */
>> +#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
>> +#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
>> +
>>  #define MAX_MODULES 32 /* Current maximum useful modules */
>>=20
>> +#define DEVICE_TREE_MAX_DEPTH 16
>> +
>> +/* Helper to read a big number; size is in cells (not bytes) */
>> +static inline u64 dt_read_number(const __be32 *cell, int size)
>> +{
>> +    u64 r =3D 0;
>> +
>> +    while ( size-- )
>> +        r =3D (r << 32) | be32_to_cpu(*(cell++));
>> +    return r;
>> +}
>> +
>> +static inline u64 dt_next_cell(int s, const __be32 **cellp)
>> +{
>> +    const __be32 *p =3D *cellp;
>> +
>> +    *cellp =3D p + s;
>> +    return dt_read_number(p, s);
>> +}
>> +
>> +typedef int (*device_tree_node_func)(const void *fdt,
>> +                                     int node, const char *name, int de=
pth,
>> +                                     u32 address_cells, u32 size_cells,
>> +                                     void *data);
>> +
>> +/**
>> + * device_tree_for_each_node - iterate over all device tree sub-nodes
>> + * @fdt: flat device tree.
>> + * @node: parent node to start the search from
>> + * @func: function to call for each sub-node.
>> + * @data: data to pass to @func.
>> + *
>> + * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
>> + *
>> + * Returns 0 if all nodes were iterated over successfully.  If @func
>> + * returns a value different from 0, that value is returned immediately=
.
>> + */
>> +int device_tree_for_each_node(const void *fdt, int node,
>> +                              device_tree_node_func func,
>> +                              void *data);
>> +
>>  typedef enum {
>>      BOOTMOD_XEN,
>>      BOOTMOD_FDT,
>> @@ -246,4 +292,20 @@ static inline struct membanks *membanks_xzalloc(uns=
igned int nr,
>>      return banks;
>>  }
>>=20
>> +/*
>> + * Interpret the property `prop_name` of `node` as a u32.
>> + *
>> + * Returns the property value on success; otherwise returns `dflt`.
>> + */
>> +uint32_t device_tree_get_u32(const void *fdt, int node,
>> +                             const char *prop_name, uint32_t dflt);
>
> Suggest using `dt_` prefix (or any other good prefix) for all functions
> in this header for consistency: e.g. there's dt_read_number() but also
> device_tree_get_u32().

I'd be quite happy with an fdt_ prefix, to clearly show they relate to FDTs=
.

But I didn't want to do that right away because it would obscure the strict=
 code
motion that's going on.

>
>> +
>> +/*
>> + * Interpret the property `prop_name` of `node` as a "reg".
>> + *
>> + * Returns outputs in `start` and `size`.
>> + */
>> +void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
>> +                         uint32_t size_cells, paddr_t *start, paddr_t *=
size);
>> +
>>  #endif /* XEN_BOOTFDT_H */
>> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree=
.h
>> index 6dc1fb5159..0a22b1ba1d 100644
>> --- a/xen/include/xen/device_tree.h
>> +++ b/xen/include/xen/device_tree.h
>> @@ -10,6 +10,7 @@
>>  #ifndef __XEN_DEVICE_TREE_H__
>>  #define __XEN_DEVICE_TREE_H__
>>=20
>> +#include 
>>  #include 
>>=20
>>  #include 
>> @@ -22,8 +23,6 @@
>>  #include 
>>  #include 
>>=20
>> -#define DEVICE_TREE_MAX_DEPTH 16
>> -
>>  /*
>>   * Struct used for matching a device
>>   */
>> @@ -164,17 +163,8 @@ struct dt_raw_irq {
>>      u32 specifier[DT_MAX_IRQ_SPEC];
>>  };
>>=20
>> -typedef int (*device_tree_node_func)(const void *fdt,
>> -                                     int node, const char *name, int de=
pth,
>> -                                     u32 address_cells, u32 size_cells,
>> -                                     void *data);
>> -
>>  extern const void *device_tree_flattened;
>>=20
>> -int device_tree_for_each_node(const void *fdt, int node,
>> -                              device_tree_node_func func,
>> -                              void *data);
>> -
>>  /**
>>   * dt_unflatten_host_device_tree - Unflatten the host device tree
>>   *
>> @@ -245,10 +235,6 @@ void intc_dt_preinit(void);
>>  #define dt_node_cmp(s1, s2) strcasecmp((s1), (s2))
>>  #define dt_compat_cmp(s1, s2) strcasecmp((s1), (s2))
>>=20
>> -/* Default #address and #size cells */
>> -#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
>> -#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
>> -
>>  #define dt_for_each_property_node(dn, pp)                   \
>>      for ( pp =3D (dn)->properties; (pp) !=3D NULL; pp =3D (pp)->next )
>>=20
>> @@ -258,16 +244,6 @@ void intc_dt_preinit(void);
>>  #define dt_for_each_child_node(dt, dn)                      \
>>      for ( dn =3D (dt)->child; (dn) !=3D NULL; dn =3D (dn)->sibling )
>>=20
>> -/* Helper to read a big number; size is in cells (not bytes) */
>> -static inline u64 dt_read_number(const __be32 *cell, int size)
>> -{
>> -    u64 r =3D 0;
>> -
>> -    while ( size-- )
>> -        r =3D (r << 32) | be32_to_cpu(*(cell++));
>> -    return r;
>> -}
>> -
>>  /* Wrapper for dt_read_number() to return paddr_t (instead of uint64_t)=
 */
>>  static inline paddr_t dt_read_paddr(const __be32 *cell, int size)
>>  {
>> @@ -307,14 +283,6 @@ static inline int dt_size_to_cells(int bytes)
>>      return (bytes / sizeof(u32));
>>  }
>>=20
>> -static inline u64 dt_next_cell(int s, const __be32 **cellp)
>> -{
>> -    const __be32 *p =3D *cellp;
>> -
>> -    *cellp =3D p + s;
>> -    return dt_read_number(p, s);
>> -}
>> -
>>  static inline const char *dt_node_full_name(const struct dt_device_node=
 *np)
>>  {
>>      return (np && np->full_name) ? np->full_name : "";
>> --
>> 2.43.0
>>=20
>>=20



From xen-devel-bounces@lists.xenproject.org Mon Jun 02 17:00:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 17:00:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003718.1383315 (Exim 4.92)
	(envelope-from )
	id 1uM8Wl-0006YH-Dp; Mon, 02 Jun 2025 17:00:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003718.1383315; Mon, 02 Jun 2025 17:00: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 1uM8Wl-0006YA-9n; Mon, 02 Jun 2025 17:00:47 +0000
Received: by outflank-mailman (input) for mailman id 1003718;
 Mon, 02 Jun 2025 17:00: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 1uM8Wj-0006XV-Vo
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 17:00:46 +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 1f2a9802-3fd3-11f0-b894-0df219b8e170;
 Mon, 02 Jun 2025 19:00:44 +0200 (CEST)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-45024721cbdso36872105e9.2
 for ; Mon, 02 Jun 2025 10:00:44 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-450d7fb0654sm129639425e9.21.2025.06.02.10.00.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 02 Jun 2025 10:00:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1f2a9802-3fd3-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748883643; x=1749488443; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=XaF1XeDmFm5BPaAg7i67sCNl7+5PLTKIgay5hbJydTA=;
        b=VBL97N5PDFjtNHHfdCaq7bVRWqGV1H+cHiCIm8dBTMfIp6GF6N3bibuZNHwZkvhc2e
         YLauuoczYdHjvTbhRPxjyQiU/mXMy/aXtJS2ATeBtMk4ZODzmrI1qxmUvjqNihqQ6uCn
         E6LeHEWBEqmX8Xo3b9oa3WvTVJT9yqwTfvbE0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748883643; x=1749488443;
        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=XaF1XeDmFm5BPaAg7i67sCNl7+5PLTKIgay5hbJydTA=;
        b=FWFlb7dMfAS33AYcAc3f09IVOWWyJS+GJakOnSXsbc53rERQAWcn3bm+IomYnOSWe/
         GU8dduFbiiSJ0aiSYq5QwNgtP17/JSAO6HPPFrLKGBAoblbN/pi1RE7yoj7MflsUhv70
         eZ0CFghQRPUpQiVx8cNsFB6c3kopIrAMp+QPkdjWJ6Wfeyjm+9+uGcWtRf6TNgJhJecF
         ZuRZsbPvsO7UEu+TK57crACeOtNYENbynqfklMAVA7oHmFibiC/bPxZZNKQlfg4fpFyh
         KhEmaf1iaRenVbRqwNAb/9a9gCqzwFsTx72H01W56n768odejuqk4MJVYGSL5hjfnaoY
         hq9w==
X-Forwarded-Encrypted: i=1; AJvYcCWR0a1JpPM15xb5dcsdVaZpDZA7txLiOeGL9l6rJvLIoPoISYq32V1I9arotplR1/NADBtlcWnyTKY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywg7VF/pq7XFbSO23Ph2mAGgm0JUxxJlkC3SvdHQrl2Ui1+uaW/
	7Hg0UQZYT41YZIMteUt935hi1Z/Uwdqqyw3r8m6ZEkCI8bPFTe1ofEKQPVLhPYNGEoU=
X-Gm-Gg: ASbGncuFZCpaLzgGpySLPbOyEdhcS3O5mqFetYSEbBIc/hQJY1+kxcbgBQnXI+Bqapl
	RVNKgw0BBBN8lcQ9+aJVuMWcoW6azPwRY50muP87zJos2I1nhbh1MgMNBwGL9xqMBX7cZWJlHw+
	swLCMYoHgYoD3F1nzHHWIAgYKcsz93ZAhkCaNFKlqj9om9hmMSmzNS2dq4gdAxaZGdDEin/6Cwl
	hxgKhLbCnJTk8H31xBWb9ZHW8nqqdnP8LIHMoB9by0F1evW3eqOYhd0PchYTWoWD83niJlzGIeC
	fC6ygECEmeT2DJJRKqN4soxv7B6xnJQP7IYFy2URFdCiU9CU4AVN7mf2CGWVHhhKtZHGyqMmmpD
	N18UZHErKpyLIj6sK
X-Google-Smtp-Source: AGHT+IE0WcvOIbm1gMLspAkTw/IBE4RQPOaCldLN4vUmdCKi5/liFVNT7fVSWGNkvisYsZr4yD5Abw==
X-Received: by 2002:a05:600c:5342:b0:450:ddb7:ee4d with SMTP id 5b1f17b1804b1-450ddb7ee6amr67661105e9.24.1748883643515;
        Mon, 02 Jun 2025 10:00:43 -0700 (PDT)
Message-ID: <214c8863-5cd4-4be9-948e-e44b67f541bd@citrix.com>
Date: Mon, 2 Jun 2025 18:00:42 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 10/19] x86: Replace boot_module with bootmodule
To: Alejandro Vallejo , xen-devel@lists.xenproject.org
Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini ,
 Julien Grall , Bertrand Marquis ,
 Michal Orzel ,
 "Daniel P. Smith" 
References: 
 <20250530120242.39398-1-agarciav@amd.com>
 <20250530120242.39398-11-agarciav@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: <20250530120242.39398-11-agarciav@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 30/05/2025 1:02 pm, Alejandro Vallejo wrote:
> These types resemble each other very closely in layout and intent, and
> with "struct bootmodule" already in common code it makes perfect sense
> to merge them. In order to do so, add an arch-specific area for
> x86-specific tidbits.
>
> Signed-off-by: Alejandro Vallejo 

Yet this is a distinct backwards step in terms of legibility.

How about modifying the common code to be more legible, rather than
regressing the x86 code.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Jun 02 17:29:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 17:29:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003727.1383324 (Exim 4.92)
	(envelope-from )
	id 1uM8yk-0001I7-HZ; Mon, 02 Jun 2025 17:29:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003727.1383324; Mon, 02 Jun 2025 17:29: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 1uM8yk-0001I0-EI; Mon, 02 Jun 2025 17:29:42 +0000
Received: by outflank-mailman (input) for mailman id 1003727;
 Mon, 02 Jun 2025 17:29: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 1uM8yk-0001Hu-2x
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 17:29:42 +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 29dbd978-3fd7-11f0-b894-0df219b8e170;
 Mon, 02 Jun 2025 19:29:40 +0200 (CEST)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-43ea40a6e98so50944225e9.1
 for ; Mon, 02 Jun 2025 10:29:40 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a4f00a017esm15241435f8f.89.2025.06.02.10.29.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 02 Jun 2025 10:29:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 29dbd978-3fd7-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748885380; x=1749490180; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=8EysBdXhVRcuwATGtq5Z+vV7iT4lpqk0/v0j0Cc1ok4=;
        b=s0XNaPXpE+2G1t++chQBIa1livncLr2x9gluBrw9E8Bea6ZmpwmfLthBhgiSLttD/C
         B2gYhbtWPIcISgC5cqSoHbpxS7nv1rlxYGCa2Nd0nQYXIgfpFXYOkEVFywCec8JIGM5g
         4CqEprEezpoujXP0r86i/9YuWjbQObmPTOT9U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748885380; x=1749490180;
        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=8EysBdXhVRcuwATGtq5Z+vV7iT4lpqk0/v0j0Cc1ok4=;
        b=hwN5IqXD6hkkHLW5z+OFfhpC3EJZvg19LX+W+uKaNmZkolkPYBRwKh1G/h8iZlsdIM
         JfWuAy6B/cQ+Q3v9tdrOvP5mvyaW2k1i9H6qz2DFry0uYby/TX66S7GimfF02+38SUPR
         77hblwij0xJlnfJQMaZdSKFKGkGtQskJ4rdefR1q6QJJJloj4rm6/Rlpwfq7H0gHkSI8
         LR0UvfXrtbd/6gIXzeecuYkluVBM4pwamAfHQmq+8Z+z0adDrrO3d0plo/TinKrFZIrp
         TCdoM1tXDXpZq0DHEfIfHdMaoE5LG11x3XUKgsVgxGEepa6L7cQ+RO0JwZ/8/i0Jj4h+
         /Ucg==
X-Forwarded-Encrypted: i=1; AJvYcCXx8VdDzDBlR+oC2Is38auy+R4W+eKVBelIg/dcCvB/BYTDMRFnmmeQjkTyVuS2lB7IcD1BFsvk4io=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxVbYeM7SOtqAW0Y9tGSxdM1O1zO9IrmZYxeilk0BnmPsa2WNeK
	K/gcHD9bjJ5yqzM7M2Uv+fhUvK61yYJULYKKL5w8K6v54F7UCcuOgbjnlhREGS81R2w=
X-Gm-Gg: ASbGncvH1WcU5nQhVVpn0j09KsCQ2mvgP+aAyqEzn4MFRlWfJGiY/XZEc7j3Hgy2gSM
	VwuOkp3yCBnIb6sgBcxJqG+KUx7+gi+6WkBSlFgtzTKrmQ35+ZaRDTx9kijPWjpXQTl5lr1YSCr
	6tzWcB3xj6L410hRhB3QytlSP59YeR1C41dfHpxvN36iF9vFOXABCEH/xd58eumWE+naevTwTZV
	+/mGV47un3FkRrxAdk+XWCYIyeaV/2lE7ORrumEz4G+htQuw/qsIlGLOVBoaDHqfkLjkq+zjCen
	sID7Sat+P32tQ8yzTipwD6x9Ckv83M6mzM9bic0/CjxpDtGUyaYLMTNq/Ebp4Z0OLlYRkWELock
	+JPklw9yoDyWg3OfDjhNqkpKai5FVkP+j4KC+2Q==
X-Google-Smtp-Source: AGHT+IGDctUQKiOKTosx4cih6zUBkhvYMnID3FemRn49+9EeLGa3AFkxRBWp4DJWHtpX+ZS8x5HO2Q==
X-Received: by 2002:a05:6000:3112:b0:3a0:7f9c:189a with SMTP id ffacd0b85a97d-3a4f799acd4mr11101980f8f.0.1748885379610;
        Mon, 02 Jun 2025 10:29:39 -0700 (PDT)
Message-ID: 
Date: Mon, 2 Jun 2025 18:29:38 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] vVMX: adjust VMPTRLD error handling
To: Jan Beulich ,
 "xen-devel@lists.xenproject.org" 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Manuel Andreas 
References: <421e2f85-c1ed-4989-b8db-36e261826fa0@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: <421e2f85-c1ed-4989-b8db-36e261826fa0@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 02/06/2025 4:37 pm, Jan Beulich wrote:
> There are two issues there: When hvm_map_guest_frame_rw() yields a r/o
> page mapping, we fail to indicate the failure to the guest, and we fall
> over the NULL pointer in nvcpu->nv_vvmcx when subsequently invoking
> nvmx_set_vmcs_pointer() (if no earlier VMPTRLD put in place a valid
> value).
>
> Fixes: 5dbbaa0fe121 ("x86/vvmx: fix I/O and MSR bitmaps mapping")
> Reported-by: Manuel Andreas 
> Signed-off-by: Jan Beulich 
>
> --- a/xen/arch/x86/hvm/vmx/vvmx.c
> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> @@ -1820,7 +1820,7 @@ static int nvmx_handle_vmptrld(struct cp
>                  vvmcx = NULL;
>              }
>          }
> -        else
> +        if ( !vvmcx )
>          {
>              vmfail(regs, VMX_INSN_VMPTRLD_INVALID_PHYADDR);
>              goto out;

To go back to one of Manuel's original questions, there is no such thing
as a read-only page in real hardware (write ignore is the closest), but
I'm certain that hardware will give us VMPTRLD_INVALID_PHYADDR for e.g.
trying to overlay the APIC MMIO page, so I think it is a reasonable to
use for this purpose.

But, please insert a blank line.  I've spent 5 minutes thinking this
patch was broken and trying to figure out how you'd covered the r/o case
before realising I was reading it wrong.

With that, Reviewed-By: Andrew Cooper 

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Jun 02 17:46:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 17:46:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003740.1383344 (Exim 4.92)
	(envelope-from )
	id 1uM9Ey-0004Am-Fk; Mon, 02 Jun 2025 17:46:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003740.1383344; Mon, 02 Jun 2025 17:46: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 1uM9Ey-00048k-9o; Mon, 02 Jun 2025 17:46:28 +0000
Received: by outflank-mailman (input) for mailman id 1003740;
 Mon, 02 Jun 2025 17:46: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 1uM9Ex-00044r-BD
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 17:46:27 +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 8146c814-3fd9-11f0-a300-13f23c93f187;
 Mon, 02 Jun 2025 19:46:26 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-450cfb790f7so34929005e9.0
 for ; Mon, 02 Jun 2025 10:46:26 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a4f0097539sm15997416f8f.63.2025.06.02.10.46.24
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 02 Jun 2025 10:46:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8146c814-3fd9-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748886385; x=1749491185; darn=lists.xenproject.org;
        h=content-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=VMfDv5scN89KVrBk/1eG8UFcMNbpeEOdoqqQG+/hRZc=;
        b=ZDeVrbiK7eIH0qjbHwl64nDpHSB3BuS/2lt7hGrk+kQbnkK/xqW1gSmlSNesJozxjW
         fIQx52b9ox1jx6HuHTUdI96fWGk7dhBzhs7keBFjJH5d4v0z8XxBPcdN5IbAM/j966cH
         FMRZUPlodjkqN7rp6r/75epngWnuxhiaIowBQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748886385; x=1749491185;
        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=VMfDv5scN89KVrBk/1eG8UFcMNbpeEOdoqqQG+/hRZc=;
        b=qQcKvgVz3766vovEuNzGWzPhFlg3yPRknZgpRCD550ABdAIlLDUcq3BVrKmcYomUuS
         bzsvGRA4GgCKaR9O1WZbHCOkuV06/r5zeJHEUtfVs//YmsYq5P/xYNsWSf6/Pid0ERe9
         fAbRKfeETOa4Wf3p3K6KtPEqDh5Vj9vLv2PQzOUNppQaLLwsZ6TlZkPAgWg/VVUCE30r
         BUL2FWCs4bpwM6MFkO5v27EyMowEDJbNuHUGQ6e8SQBYc3WT4NJLgzMfENg0RFEBZ9U/
         ABhFGNvCh4WWhumN26MD5Z+bdt3GVL8JU4YfFogmTIFHJoAHWVNBIiBhxJqjfrESfWYp
         55Jg==
X-Gm-Message-State: AOJu0Yw1OJqB7JOKmZ8h/3gQWOXtTTVlRQ/BbJ+zBnoHMTO7VzhSkbhb
	VD6Xbn62wj12GMLEKekXshwI4mQ/6AATaEuLQllNBv2DOEt0vUBkee7bdUq+VTQZqXx2Z+MKYX3
	8G5M8
X-Gm-Gg: ASbGncuEQYCG79ZlLKoogfM8rMzY7L854tdLThM+wPDsxKw4qI+kD85UBB0GIycDWyp
	pXxARmw/NvnZUXDEd9ZzXPSstRfsP3BB/c1Aeu1jan/ClOO4BhogbKRlmjnh8dXrm4zIw8CUO7K
	mB2nGjd33p3HjGsSDv89jLJo7/AP7FdqgdRv7X5Uho8VN9I2hZnI+1KSXQPw8xmsM3ejMbdUXQ7
	D7BRKcYwGETwbdqH6qHmEJRko6b01PMHHmYd7wADSBjeRju3ms5lO8/fcz62n8QOIWcgtjxvuvK
	9MHBQCvsiiRHzI489KjNTMgeH77EGwodyQeQe/+O8w/MZnzyXFwfla63Rt4/wOC3LiuOxllGQ3F
	4M6bgdZRu26VZUEO8LBLuyTKi
X-Google-Smtp-Source: AGHT+IE/EagnuGrr5IlNIkzGdMRgLDqUa6swkTOIix8pZfplcFgLE6SCE79B+HL3TiQXEkWFCYfrxg==
X-Received: by 2002:a05:600c:6a93:b0:451:df07:f437 with SMTP id 5b1f17b1804b1-451df07f5e4mr24603605e9.30.1748886385116;
        Mon, 02 Jun 2025 10:46:25 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Anthony PERARD ,
	Stefano Stabellini ,
	Michal Orzel ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
Subject: [PATCH 2/2] CI: Adjust how domU is packaged in dom0
Date: Mon,  2 Jun 2025 18:46:18 +0100
Message-Id: <20250602174618.2641439-3-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250602174618.2641439-1-andrew.cooper3@citrix.com>
References: <20250602174618.2641439-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Package domU for dom0 and insert into the uncompressed part of dom0's rootfs,
rather than recompressing it as part of the overlay.

For Qubes, this avoids putting the domU kernel in dom0's rootfs for tests
which aren't going to boot a guest.

Signed-off-by: Andrew Cooper 
---
CC: Anthony PERARD 
CC: Stefano Stabellini 
CC: Michal Orzel 
CC: Marek Marczykowski-Górecki 

v2:
 * Rebase over dom0_rootfs_extra_{un,}comp changes
 * Move back into boot.  There seem to be objections to having it in root.
---
 automation/scripts/qubes-x86-64.sh             | 17 ++++++++++++-----
 automation/scripts/xilinx-smoke-dom0-x86_64.sh | 14 +++++++++++---
 2 files changed, 23 insertions(+), 8 deletions(-)

diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qubes-x86-64.sh
index 5ec6eff6c469..d9ecc569c956 100755
--- a/automation/scripts/qubes-x86-64.sh
+++ b/automation/scripts/qubes-x86-64.sh
@@ -156,7 +156,7 @@ esac
 domU_config="
 type = '${domU_type}'
 name = 'domU'
-kernel = '/boot/vmlinuz'
+kernel = '/boot/vmlinuz-domU'
 ramdisk = '/boot/initrd-domU'
 cmdline = 'root=/dev/ram0 console=hvc0'
 memory = 512
@@ -187,6 +187,17 @@ Kernel \r on an \m (\l)
     find . | cpio -H newc -o | gzip >> ../binaries/domU-rootfs.cpio.gz
     cd ..
     rm -rf rootfs
+
+    # Package domU kernel+rootfs in /boot for dom0 (uncompressed)
+    mkdir -p rootfs/boot
+    cd rootfs
+    cp ../binaries/bzImage boot/vmlinuz-domU
+    cp ../binaries/domU-rootfs.cpio.gz boot/initrd-domU
+    find . | cpio -H newc -o > ../binaries/domU-in-dom0.cpio
+    cd ..
+    rm -rf rootfs
+
+    dom0_rootfs_extra_uncomp+=(binaries/domU-in-dom0.cpio)
 fi
 
 # Dom0 rootfs.  The order or concatination is important; ucode wants to come
@@ -241,10 +252,6 @@ mkdir -p etc/default
 echo "XENCONSOLED_TRACE=all" >> etc/default/xencommons
 echo "QEMU_XEN=/bin/false" >> etc/default/xencommons
 mkdir -p var/log/xen/console
-cp ../binaries/bzImage boot/vmlinuz
-if [ -n "$domU_check" ]; then
-    cp ../binaries/domU-rootfs.cpio.gz boot/initrd-domU
-fi
 find . | cpio -H newc -o | gzip >> ../binaries/dom0-rootfs.cpio.gz
 cd ..
 
diff --git a/automation/scripts/xilinx-smoke-dom0-x86_64.sh b/automation/scripts/xilinx-smoke-dom0-x86_64.sh
index 45121f39400a..8981aee5d4f2 100755
--- a/automation/scripts/xilinx-smoke-dom0-x86_64.sh
+++ b/automation/scripts/xilinx-smoke-dom0-x86_64.sh
@@ -22,7 +22,7 @@ DOMU_CMD=""
 DOMU_CFG='
 type = "pvh"
 name = "domU"
-kernel = "/boot/vmlinuz"
+kernel = "/boot/vmlinuz-domU"
 ramdisk = "/boot/initrd-domU"
 extra = "root=/dev/ram0 console=hvc0"
 memory = 512
@@ -106,10 +106,20 @@ find . | cpio -H newc -o | gzip >> ../binaries/domU-rootfs.cpio.gz
 cd ..
 rm -rf rootfs
 
+# Package domU kernel+rootfs in /boot for dom0 (uncompressed)
+mkdir -p rootfs/boot
+cd rootfs
+cp ../binaries/bzImage boot/vmlinuz-domU
+cp ../binaries/domU-rootfs.cpio.gz boot/initrd-domU
+find . | cpio -H newc -o > ../binaries/domU-in-dom0.cpio
+cd ..
+rm -rf rootfs
+
 # Dom0 rootfs.  The order or concatination is important; ucode wants to come
 # first, and all uncompressed must be ahead of compressed.
 dom0_rootfs_parts=(
     binaries/ucode.cpio
+    binaries/domU-in-dom0.cpio
     "${dom0_rootfs_extra_uncomp[@]}"
     binaries/rootfs.cpio.gz
     binaries/xen-tools.cpio.gz
@@ -131,8 +141,6 @@ echo "${DOMU_CFG}${DOMU_CFG_EXTRA}" > etc/xen/domU.cfg
 echo "XENCONSOLED_TRACE=all" >> etc/default/xencommons
 echo "QEMU_XEN=/bin/false" >> etc/default/xencommons
 mkdir -p var/log/xen/console
-cp ../binaries/bzImage boot/vmlinuz
-cp ../binaries/domU-rootfs.cpio.gz boot/initrd-domU
 find . | cpio -H newc -o | gzip >> ../binaries/dom0-rootfs.cpio.gz
 cd ..
 
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Jun 02 17:46:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 17:46:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003738.1383334 (Exim 4.92)
	(envelope-from )
	id 1uM9Ey-00045E-04; Mon, 02 Jun 2025 17:46:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003738.1383334; Mon, 02 Jun 2025 17:46: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 1uM9Ex-000457-SX; Mon, 02 Jun 2025 17:46:27 +0000
Received: by outflank-mailman (input) for mailman id 1003738;
 Mon, 02 Jun 2025 17:46: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 1uM9Ew-00044r-AF
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 17:46:26 +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 803073b1-3fd9-11f0-a300-13f23c93f187;
 Mon, 02 Jun 2025 19:46:24 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3a363d15c64so3307058f8f.3
 for ; Mon, 02 Jun 2025 10:46:24 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a4f0097539sm15997416f8f.63.2025.06.02.10.46.22
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 02 Jun 2025 10:46:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 803073b1-3fd9-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748886383; x=1749491183; 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=n55XkaNDtS0SBcOaVPitenhrD4U358oguWrJtotdbW4=;
        b=BpscjNS8shL1Vt/FSBTn5MZjkfG9h+IXh1DnbArmcfBsDH2CGkjHZm/C1OhHBM9uFG
         kZw8QVU2wuK7HsmP1WYFILrqFbpTDbvs1eHAqAKbRI5S/qQdv+Z/ZwmElVH4qaEZSEv+
         Obqq3mnXSPRMQ9q74AtQXjXL71msej4yRcdxo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748886383; x=1749491183;
        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=n55XkaNDtS0SBcOaVPitenhrD4U358oguWrJtotdbW4=;
        b=E8TmeiyTgRwVc53ddcnjaKAGxaTAcojWGDH3Yo2ikgoWG0aY58fz79uoVTZf5drFKa
         Dv2cpo7SOQJzxmbijOTN6/GaA1iJw3H2Vq29+L9hHtZhFVYSCfnChxUpSD4WwwB0NhUy
         Fi+KTVdH1EkUcP+ycCjNl4uqKUHGfxQAKOtd+lgxA2r4hmeKT2swu8AOdFcbxvE1ecHS
         4fGb+bv+53et3TDBMSRuZWV+V/uWECI3ocmUy/2SztpFpubnEUsCWYj55jioV+0NPKah
         eVSDdKb0oCpOrGx7s27HcpNiOJWogTSBuhiEs/IqtbTWLu7QBi1/AyP4tgzDZ6fU83Kg
         DOOQ==
X-Gm-Message-State: AOJu0YytHjLoujTrbKufK5ed28+9jY79ArfztDzi7airhSUnnADeqKGE
	4QyrEsIi9fbpabpWvkCyj4qYMjK90SDlfSZJZ8fSXYuiDcSTS5lHZyoQTZ3BOw/+/u90dWNLEE3
	+2nY2
X-Gm-Gg: ASbGncutAEoyZ8kc1y3li9fvUbw5K0gDH+WQpR9yJvWcxfNEkT7fErfNretp4A5dZZT
	T/tR1sRNfh1jiAHnjimT9oJuXFmZ9lfdiNBgp3QJ7tO0+UUarTxUDWe8w51eRbSzoSu8jRH5lnA
	wpkAN3JDEADGLOQ4KfloMQpXRB71lypdiavHh3AiPLgBdbH36rEOKTQH+wQyfa3ScHcg3G0y3h2
	U63hkLMR2BAjy2Q31cjVbvP4A3a0sU9jsgRvUqkH/srQ5+MHueV1XPnOQjl/huak6vwPVmw8dRe
	1e47F1+HIYcGwCehURFDypz1OTvvXk98M5O9YE+XMG76ML/Wx0eLIth1KKAFI/NdTLl7hFz67JU
	P2EKbDDWikZ4aatDiDvdaH8AZ
X-Google-Smtp-Source: AGHT+IFw0uNb/P1wamNl/u1GHVGpfzuHmIBf6DKXNXSlPhpxkLbX8yLKNbHiUBNUH4Zoo8Dm+LtXMg==
X-Received: by 2002:a05:6000:2c12:b0:3a4:d64a:3df0 with SMTP id ffacd0b85a97d-3a4f7a025bdmr11418782f8f.4.1748886383330;
        Mon, 02 Jun 2025 10:46:23 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Anthony PERARD ,
	Stefano Stabellini ,
	Michal Orzel ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
Subject: [PATCH 0/2] CI: Improve domU handling
Date: Mon,  2 Jun 2025 18:46:16 +0100
Message-Id: <20250602174618.2641439-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

Improvements to domU kernel+initrd handling.

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

Andrew Cooper (2):
  CI: Use bash arrays to simplfy dom0 rootfs construction
  CI: Adjust how domU is packaged in dom0

 automation/scripts/qubes-x86-64.sh            | 35 +++++++++++++------
 .../scripts/xilinx-smoke-dom0-x86_64.sh       | 34 ++++++++++++------
 2 files changed, 49 insertions(+), 20 deletions(-)

-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Jun 02 17:46:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 17:46:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003739.1383340 (Exim 4.92)
	(envelope-from )
	id 1uM9Ey-00048P-9w; Mon, 02 Jun 2025 17:46:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003739.1383340; Mon, 02 Jun 2025 17:46: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 1uM9Ey-00047w-38; Mon, 02 Jun 2025 17:46:28 +0000
Received: by outflank-mailman (input) for mailman id 1003739;
 Mon, 02 Jun 2025 17:46: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 1uM9Ew-00044r-IV
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 17:46:26 +0000
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com
 [2a00:1450:4864:20::332])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 80b13329-3fd9-11f0-a300-13f23c93f187;
 Mon, 02 Jun 2025 19:46:24 +0200 (CEST)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-442fda876a6so41370835e9.0
 for ; Mon, 02 Jun 2025 10:46:24 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a4f0097539sm15997416f8f.63.2025.06.02.10.46.23
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 02 Jun 2025 10:46:23 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 80b13329-3fd9-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748886384; x=1749491184; darn=lists.xenproject.org;
        h=content-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=B9VfFp7KStC3qDdOP/ZlcW7W//yetvsaldEN92b/Svg=;
        b=WFfNUm9BqVzzA/JjaLHRqcpOQp5St6dgqk4+o5s+325i6jkUJZEWhN4c8ZUv5fd/9b
         Cn7dWDjDakR05yh5KpajzYnLlP/co9FO1/2cScLGzQz4fVoUQb8bicYZFUCjAYCHvLPg
         dQJ3HdAr6ZJwn9OiqIjDlfgFhkVmUkCJ20p4A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748886384; x=1749491184;
        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=B9VfFp7KStC3qDdOP/ZlcW7W//yetvsaldEN92b/Svg=;
        b=HcAcsMXly4AaquLIzBuuAu9dvDOUPOp3Sdl8mU5a9Ftga3KIHEQerG9wZog3QCHtjv
         zmzzvQVhMEXrycE6r8sFtQuGXfhGzl9YZHk+SyyPxIVQrELi/lf3j4UsDRqi1ablyRYW
         jkN7L1MWEnp+W8ceLbeSQbPxp5cdje/bs0WAmOhRqm3AY3VDkFcZrhJqtnoE49S83ZwQ
         0l8tOnHj5jQk1PaDcex+bHtnb+/9LtR+U5HGF/dY3AASN4OOkqiHDq6Z01nsyvPFU9Yg
         YeeNsxBtxQi4MD9k9Z6W4uWu0rAIrVln2gCSal3T6SMJ46wZmHyQGTOHc92Pv1FxgvDW
         FRZw==
X-Gm-Message-State: AOJu0YxFl96xY+J8oPlDcBAMgT6hjAztoxopHSGOWa680hlFTRPe+XR5
	xTY7Dcb9bGFLCtth9Srlxl+jpgswDfWX+YCWWay6x/w+KmwCT5iHGRLtMwMq7pLiN76qkhsyBYN
	vb/gg
X-Gm-Gg: ASbGncsmhx2OTdV1YcHjUomFN4uPEIGt9J2BrFP1ovFoLKK18jMWRf79s82yXWHApxT
	p0zDgZXjcihE3kcgkosf9pod8JqpAJdQblQdldmoWjHHdX3LF0cOXQyBF+aRAJuCHg8JTFyXTuI
	qno36zErUHyJJ9sAJ0zA4dUYIF6Pnr5SUhBJ0ZFoUd9oKCzawp32xtN2w4TpjxzdKY8OVw0q/Je
	r9C/zwWf70P4Ba08GOWBMzsNoY7HGjKT/ZsJyvgbiFyht/zw6o7nqwmrwgSDywH6eWYiANO09qe
	JMh+rLNTeMyO6tsfDsTmn6b2B74wTItTZ7uNGtLCp+/A8LsTznsWN2e+RHjnrQWamE7AcS14I4y
	292iMBUKElhoAizFMXzr5FFubl7sRYeKV9CY=
X-Google-Smtp-Source: AGHT+IGuQ0VThV/yJUVdC3GCVEM3YobvqBbPkEGiEo1ShTS8wNLmy+vLpB1N2s8mmpGR6FXcpOJg8w==
X-Received: by 2002:a05:600c:5494:b0:442:cab1:e092 with SMTP id 5b1f17b1804b1-4511ecc2522mr71040995e9.11.1748886384117;
        Mon, 02 Jun 2025 10:46:24 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Anthony PERARD ,
	Stefano Stabellini ,
	Michal Orzel ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
Subject: [PATCH 1/2] CI: Use bash arrays to simplfy dom0 rootfs construction
Date: Mon,  2 Jun 2025 18:46:17 +0100
Message-Id: <20250602174618.2641439-2-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250602174618.2641439-1-andrew.cooper3@citrix.com>
References: <20250602174618.2641439-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

For Qubes, this requires switching from sh to bash.

This reduces the number of times the target filename needs to be written to 1.

Expand the comment to explain the concatination constraints.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Anthony PERARD 
CC: Stefano Stabellini 
CC: Michal Orzel 
CC: Marek Marczykowski-Górecki 

v2:
 * Use dom0_rootfs_extra_{un,}comp arrays
---
 automation/scripts/qubes-x86-64.sh            | 18 ++++++++++++-----
 .../scripts/xilinx-smoke-dom0-x86_64.sh       | 20 ++++++++++++-------
 2 files changed, 26 insertions(+), 12 deletions(-)

diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qubes-x86-64.sh
index 8e86940c6eff..5ec6eff6c469 100755
--- a/automation/scripts/qubes-x86-64.sh
+++ b/automation/scripts/qubes-x86-64.sh
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
 
 set -ex -o pipefail
 
@@ -22,6 +22,8 @@ domU_type="pvh"
 domU_vif="'bridge=xenbr0',"
 domU_extra_config=
 retrieve_xml=
+dom0_rootfs_extra_comp=()
+dom0_rootfs_extra_uncomp=()
 
 case "${test_variant}" in
     ### test: smoke test & smoke test PVH & smoke test HVM & smoke test PVSHIM
@@ -187,10 +189,16 @@ Kernel \r on an \m (\l)
     rm -rf rootfs
 fi
 
-# Dom0 rootfs
-cp binaries/ucode.cpio binaries/dom0-rootfs.cpio.gz
-cat binaries/rootfs.cpio.gz >> binaries/dom0-rootfs.cpio.gz
-cat binaries/xen-tools.cpio.gz >> binaries/dom0-rootfs.cpio.gz
+# Dom0 rootfs.  The order or concatination is important; ucode wants to come
+# first, and all uncompressed must be ahead of compressed.
+dom0_rootfs_parts=(
+    binaries/ucode.cpio
+    "${dom0_rootfs_extra_uncomp[@]}"
+    binaries/rootfs.cpio.gz
+    binaries/xen-tools.cpio.gz
+    "${dom0_rootfs_extra_comp[@]}"
+)
+cat "${dom0_rootfs_parts[@]}" > binaries/dom0-rootfs.cpio.gz
 
 # test-local configuration
 mkdir -p rootfs
diff --git a/automation/scripts/xilinx-smoke-dom0-x86_64.sh b/automation/scripts/xilinx-smoke-dom0-x86_64.sh
index 8f02fa73bd06..45121f39400a 100755
--- a/automation/scripts/xilinx-smoke-dom0-x86_64.sh
+++ b/automation/scripts/xilinx-smoke-dom0-x86_64.sh
@@ -28,6 +28,8 @@ extra = "root=/dev/ram0 console=hvc0"
 memory = 512
 '
 DOMU_CFG_EXTRA=""
+dom0_rootfs_extra_comp=()
+dom0_rootfs_extra_uncomp=()
 
 # Select test variant.
 if [ "${TEST}" = "ping" ]; then
@@ -71,6 +73,7 @@ do
   sleep 1
 done | argo-exec -p 28333 -d 0 -- /bin/echo
 "
+    dom0_rootfs_extra_comp+=(binaries/argo.cpio.gz)
     DOM0_CMD="
 insmod /lib/modules/\$(uname -r)/updates/xen-argo.ko
 xl -vvv create /etc/xen/domU.cfg
@@ -103,13 +106,16 @@ find . | cpio -H newc -o | gzip >> ../binaries/domU-rootfs.cpio.gz
 cd ..
 rm -rf rootfs
 
-# Dom0 rootfs
-cp binaries/ucode.cpio binaries/dom0-rootfs.cpio.gz
-cat binaries/rootfs.cpio.gz >> binaries/dom0-rootfs.cpio.gz
-cat binaries/xen-tools.cpio.gz >> binaries/dom0-rootfs.cpio.gz
-if [[ "${TEST}" == argo ]]; then
-    cat binaries/argo.cpio.gz >> binaries/dom0-rootfs.cpio.gz
-fi
+# Dom0 rootfs.  The order or concatination is important; ucode wants to come
+# first, and all uncompressed must be ahead of compressed.
+dom0_rootfs_parts=(
+    binaries/ucode.cpio
+    "${dom0_rootfs_extra_uncomp[@]}"
+    binaries/rootfs.cpio.gz
+    binaries/xen-tools.cpio.gz
+    "${dom0_rootfs_extra_comp[@]}"
+)
+cat "${dom0_rootfs_parts[@]}" > binaries/dom0-rootfs.cpio.gz
 
 # test-local configuration
 mkdir -p rootfs
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Jun 02 18:11:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 18:11:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003758.1383363 (Exim 4.92)
	(envelope-from )
	id 1uM9d6-0000ow-AX; Mon, 02 Jun 2025 18:11:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003758.1383363; Mon, 02 Jun 2025 18: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 1uM9d6-0000op-7p; Mon, 02 Jun 2025 18:11:24 +0000
Received: by outflank-mailman (input) for mailman id 1003758;
 Mon, 02 Jun 2025 18: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 1uM9d4-0000oj-LA
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 18:11:22 +0000
Received: from postout2.mail.lrz.de (postout2.mail.lrz.de
 [2001:4ca0:0:103::81bb:ff8a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fb8f8a25-3fdc-11f0-b894-0df219b8e170;
 Mon, 02 Jun 2025 20:11:20 +0200 (CEST)
Received: from lxmhs52.srv.lrz.de (localhost [127.0.0.1])
 by postout2.mail.lrz.de (Postfix) with ESMTP id 4bB23C2KMKzyTF;
 Mon,  2 Jun 2025 20:11:19 +0200 (CEST)
Received: from postout2.mail.lrz.de ([127.0.0.1])
 by lxmhs52.srv.lrz.de (lxmhs52.srv.lrz.de [127.0.0.1]) (amavis, port 20024)
 with LMTP id RyoEwIVJ5yHU; Mon,  2 Jun 2025 20:11:18 +0200 (CEST)
Received: from [IPV6:2a02:2455:1858:e00:c6d3:21dc:a17f:42be] (unknown
 [IPv6:2a02:2455:1858:e00:c6d3:21dc:a17f:42be])
 (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 postout2.mail.lrz.de (Postfix) with ESMTPSA id 4bB23B0B0DzySg;
 Mon,  2 Jun 2025 20:11:17 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fb8f8a25-3fdc-11f0-b894-0df219b8e170
Authentication-Results: postout.lrz.de (amavis); dkim=pass (2048-bit key)
 reason="pass (just generated, assumed good)" header.d=tum.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tum.de; h=
	content-transfer-encoding:content-type:content-type:in-reply-to
	:from:from:content-language:references:subject:subject
	:user-agent:mime-version:date:date:message-id:received:received;
	 s=tu-postout21; t=1748887878; bh=xFEbZ8xtgjmVRJg/XWv4y5j1rCjH9a
	WD7HGyeBIkrR4=; b=DK1lD5ylKJUoqd4/Xgvkddy9JcehvR89/NCV4kcW8cCM6u
	Ud5Wg6m43NNlwxESNpUzkbP/ehO/wozwv+hOf5HPCX1QZsm56Kh7h1a6Pkge6yp7
	RCPbpSRhJQ8Auhvlcti/L03qz2E/WHp4eT5Z2/QSIS2V5IYLvBh/RDQLsEqVUCRK
	pOI2YEYb8Gra02ED28N7UbXRcKXd3jDgsJJWnMv4uzzskQw/D09qhWmnzuH4N6X0
	ZzRepwHkHZlU6Qj2tnSTpz+aWQ54pwx4R6Vllp9/zcaFjikA+7U4XZgGej/PYqKO
	PFbj5I/lzFPqrYUweDu/4lH2pUWo1cavR0A3bBSg==
X-Virus-Scanned: by amavisd-new at lrz.de in lxmhs52.srv.lrz.de
X-Spam-Flag: NO
X-Spam-Score: -2.871
X-Spam-Level:
X-Spam-Status: No, score=-2.871 tagged_above=-999 required=5
 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, DMARC_ADKIM_RELAXED=0.001,
 DMARC_ASPF_RELAXED=0.001, DMARC_POLICY_NONE=0.001, LRZ_DMARC_FAIL=0.001,
 LRZ_DMARC_FAIL_NONE=0.001, LRZ_DMARC_POLICY=0.001, LRZ_DMARC_TUM_FAIL=0.001,
 LRZ_DMARC_TUM_REJECT=3.5, LRZ_DMARC_TUM_REJECT_PO=-3.5,
 LRZ_ENVFROM_FROM_MATCH=0.001, LRZ_ENVFROM_TUM_S=0.001,
 LRZ_FROM_ENVFROM_ALIGNED_STRICT=0.001, LRZ_FROM_HAS_A=0.001,
 LRZ_FROM_HAS_AAAA=0.001, LRZ_FROM_HAS_MDOM=0.001, LRZ_FROM_HAS_MX=0.001,
 LRZ_FROM_HOSTED_DOMAIN=0.001, LRZ_FROM_NAME_IN_ADDR=0.001,
 LRZ_FROM_PHRASE=0.001, LRZ_FROM_PRE_SUR=0.001, LRZ_FROM_PRE_SUR_PHRASE=0.001,
 LRZ_FROM_TUM_S=0.001, LRZ_HAS_CLANG=0.001, LRZ_HAS_CT=0.001,
 LRZ_HAS_IN_REPLY_TO=0.001, LRZ_HAS_MIME_VERSION=0.001, LRZ_HAS_SPF=0.001,
 LRZ_MSGID_HL8_3HL4_HL12=0.001, LRZ_MSGID_MOZ=0.001, LRZ_SUBJ_FW_RE=0.001,
 LRZ_UA_MOZ=0.001] autolearn=no autolearn_force=no
Message-ID: <1cf78023-69cf-405f-9678-a3e60d594650@tum.de>
Date: Mon, 2 Jun 2025 20:11:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Nullptr dereference in nested VMX when shadow VMCS support is
 available
To: Jan Beulich 
Cc: xen-devel@lists.xenproject.org
References: <5f258e25-a4ed-4f9a-8ca6-9ea3400e2369@tum.de>
 <6d28eb0c-caed-4c58-a6ac-cbf8da357d22@tum.de>
 <21dcca4d-1c51-42f1-b73b-65702451de13@suse.com>
 <26f412e2-ba65-4e3f-8c5f-7e15f5f32491@tum.de>
 
Content-Language: en-US
From: Manuel Andreas 
Autocrypt: addr=manuel.andreas@tum.de; keydata=
 xjMEY9Zx/RYJKwYBBAHaRw8BAQdALWzRzW9a74DX4l6i8VzXGvv72Vz0qfvj9s7bjBD905nN
 Jk1hbnVlbCBBbmRyZWFzIDxtYW51ZWwuYW5kcmVhc0B0dW0uZGU+wokEExYIADEWIQQuSfNX
 11QV6exAUmOqZGwY4LuingUCY9Zx/QIbAwQLCQgHBRUICQoLBRYCAwEAAAoJEKpkbBjgu6Ke
 McQBAPyP530S365I50I5rM2XjH5Hr9YcUQATD5dusZJMDgejAP9T/wUurwQSuRfm1rK8cNcf
 w4wP3+PLvL+J+kuVku93CM44BGPWcf0SCisGAQQBl1UBBQEBB0AmCAf31tLBD5tvtdZ0XX1B
 yGLUAxhgmFskGyPhY8wOKQMBCAfCeAQYFggAIBYhBC5J81fXVBXp7EBSY6pkbBjgu6KeBQJj
 1nH9AhsMAAoJEKpkbBjgu6Kej6YA/RvJdXMjsD5csifolLw53KX0/ElM22SvaGym1+KiiVND
 AQDy+y+bCXI+J713/AwLBsDxTEXmP7Cp49ZqbAu83NnpBQ==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 6/2/25 17:42, Jan Beulich wrote:

>>>> This is possible when:
>>>>
>>>>    1. The malicious domain has nested HVM capabilities.
>>>>    2. The CPU is running on top of VMX and supports shadow VMCS.
>>>>
>>>> To trigger the bug, the domain must first enable VMX operation for
>>>> itself, execute VMXON and then finally execute VMPTRLD on a guest
>>>> physical address that is backed by a non-writable p2m mapping.
>>>> In `nvmx_handle_vmptrld`, after attempting to map the nested VMCS, Xen
>>>> will check whether or not this mapping is suitable for writing and if
>>>> not immediately unmap the nested VMCS again and abort the setup of
>>>> `nvcpu->nv_vvmcx`. However, Xen at this point erroneously continues
>>>> emulation of the VMPTRLD. In particular, if VMCS shadowing is available,
>>>> Xen will nonetheless attempt to link up the nested VMCS to its own VMCS
>>>> in `nvmx_set_vmcs_pointer`. Importantly, Xen here attempts to
>>>> dereference the presumably mapped nested VMCS (which now is merely a
>>>> NULL pointer) in order to mark it as a shadow VMCS by applying the
>>>> `VMCS_RID_TYPE_MASK` to its revision identifier. Following, the page
>>>> fault handler will panic Xen.
>>>>
>>>> I've attached an XTF reproducer that triggers the bug. To setup such a
>>>> non-writable p2m mapping for the malicious VMCS, I first setup an
>>>> appropriate grant table entry. I've tested it on Xen version 4.20.0.
>>> I expect this to not work anymore on current staging or 4.20.1-pre.
>>> See a8325f981ce4 ("x86/P2M: synchronize fast and slow paths of
>>> p2m_get_page_from_gfn()").
>> On first glance I don't see how that would impact the type of the
>> established p2m mapping.
> Thing is that with said change grant mappings will cause
> hvm_map_guest_frame_rw() to simply fail, rather than returning a r/o
> mapping for r/o grant entries.
I see, that makes sense. Thanks for the clarification!

Best,
Manuel


From xen-devel-bounces@lists.xenproject.org Mon Jun 02 19:17:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 19:17:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003772.1383374 (Exim 4.92)
	(envelope-from )
	id 1uMAfB-0008G2-19; Mon, 02 Jun 2025 19:17:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003772.1383374; Mon, 02 Jun 2025 19:17: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 1uMAfA-0008Fv-Ua; Mon, 02 Jun 2025 19:17:36 +0000
Received: by outflank-mailman (input) for mailman id 1003772;
 Mon, 02 Jun 2025 19:17: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 1uMAf8-0008Fp-OJ
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 19:17:35 +0000
Received: from mail-24418.protonmail.ch (mail-24418.protonmail.ch
 [109.224.244.18]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 39ff5286-3fe6-11f0-b894-0df219b8e170;
 Mon, 02 Jun 2025 21:17:29 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 39ff5286-3fe6-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=ysr6kma3xzaxpcxtq754jyg2t4.protonmail; t=1748891848; x=1749151048;
	bh=TYIdmTL1y/opNybyESvYe5Fbsw4UmNMLAVDl4CmjMFI=;
	h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
	 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector:
	 List-Unsubscribe:List-Unsubscribe-Post;
	b=GRoz+OSUwfpkjv3uGhrO/5dma8jSGfL0plPq3kSBtWLsrXLVbJbMkY8DliKPHP1YA
	 YDPM5xvzQ3qmrvb9MBf+D6BjfZxd2b8lpU6iWbDUtJ0pRqI4TEorI9V3wB8JkZkM/A
	 nT8kEtIDsfXX0QkbPrw9nvNbsM+e3IA4tNAYkPbck+PQbgNgvVgL/d3Ft3EFWdL+oH
	 JVLoxoIreo3bmdikcuGXxbGv6RCm/LAwTRiai+NCXyrhgg4ookkjmSsElsCLHm0jzw
	 JHxh5DNS6obwlr17wb/iXHHZJLit8SvvakydhmFB1WcIRToHlZdTvFNRMXEOQ6eTzH
	 0F1gmRLflwf6A==
Date: Mon, 02 Jun 2025 19:17:22 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com
Subject: [PATCH v5 0/2] xen/domain: updates to hardware emulation flags
Message-ID: <20250602191717.148361-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: d2232326d5e419126d8b29309ba460596b9e8bf8
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Patch 1 introduces emulation_flags in common domain struct for enabling dom=
ain
emulation features on non-x86 platforms.

Patch 2 rewrites emulation_flags_ok() on x86 with a goal of improving
readability and maintainability of the code.

Originally, the code was part of [1], part of NS16550 emulator v3 series.

[1] https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v1-6-c5d36b3=
1d66c@ford.com/
[2] Link to v4: https://lore.kernel.org/xen-devel/20250530220242.63175-1-dm=
ukhin@ford.com/
[3] Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelin=
es/1849512714

Denis Mukhin (2):
  xen/domain: introduce common hardware emulation flags
  xen/domain: rewrite emulation_flags_ok()

 xen/arch/x86/domain.c             | 93 ++++++++++++++++++++++++-------
 xen/arch/x86/domctl.c             |  2 +-
 xen/arch/x86/include/asm/domain.h | 25 ++++-----
 xen/common/keyhandler.c           |  1 +
 xen/include/xen/sched.h           |  2 +
 5 files changed, 89 insertions(+), 34 deletions(-)

--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Mon Jun 02 19:17:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 19:17:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003773.1383385 (Exim 4.92)
	(envelope-from )
	id 1uMAfE-0008U3-An; Mon, 02 Jun 2025 19:17:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003773.1383385; Mon, 02 Jun 2025 19:17:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMAfE-0008Tw-6c; Mon, 02 Jun 2025 19:17:40 +0000
Received: by outflank-mailman (input) for mailman id 1003773;
 Mon, 02 Jun 2025 19:17: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 1uMAfD-0008Fp-AN
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 19:17:39 +0000
Received: from mail-10628.protonmail.ch (mail-10628.protonmail.ch
 [79.135.106.28]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3eb2f106-3fe6-11f0-b894-0df219b8e170;
 Mon, 02 Jun 2025 21:17:37 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3eb2f106-3fe6-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=jgi3by2g5zbwtl2dhg6cnbz7oi.protonmail; t=1748891855; x=1749151055;
	bh=OFArnTWm3efKFTWaDQu3LAnnzQ21K9gfY4s1Z9E7fps=;
	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=dTwG7dyQ8lFni+GPW4RKWIAEKIPqm1iyRPjJ7c7224iJOzxQwkSfXywH67ZkDCTmk
	 5cEgaHvS1/Xk9yGCpv3vvbu/cGHknXiNcauJvJ9GN2zB0IwFD8R8LjW7nPNgjZD72X
	 JN1qJpaDuoZhbXVnXBJtfFLMjLe9IrnqjnhRWu22rbwt1bg3z501YjvllNRCKS2RK9
	 bQRw2w6u6iXxIKln//eTry6O1xNyCsJim7F14ljmcP1OF1xtL6u31WIjR2GzacPvWc
	 0OxVt0woO74feQFjHM0gjIcE28L4bl6ldsLyJwf9LPslq/3Aid+BbfAvM4AA/mrWY5
	 FnRb7iwW+VqZg==
Date: Mon, 02 Jun 2025 19:17:30 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com
Subject: [PATCH v5 1/2] xen/domain: introduce common hardware emulation flags
Message-ID: <20250602191717.148361-2-dmukhin@ford.com>
In-Reply-To: <20250602191717.148361-1-dmukhin@ford.com>
References: <20250602191717.148361-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 44152c72659e4f4e74e9162f3f36e24325a91f72
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Add common emulation_flags for configuring domain emulation features.

Print d->emulation_flags from 'q' keyhandler for better traceability while
debugging.

Signed-off-by: Denis Mukhin 
Reviewed-by: Stefano Stabellini 
---
Changes since v4:
- kept Stefano's R-b
---
 xen/arch/x86/domain.c             |  2 +-
 xen/arch/x86/domctl.c             |  2 +-
 xen/arch/x86/include/asm/domain.h | 25 +++++++++++--------------
 xen/common/keyhandler.c           |  1 +
 xen/include/xen/sched.h           |  2 ++
 5 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 7536b6c871..0363ccb384 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -831,7 +831,7 @@ int arch_domain_create(struct domain *d,
                emflags);
         return -EOPNOTSUPP;
     }
-    d->arch.emulation_flags =3D emflags;
+    d->emulation_flags =3D emflags;
=20
 #ifdef CONFIG_PV32
     HYPERVISOR_COMPAT_VIRT_START(d) =3D
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 3044f706de..37d848f683 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -144,7 +144,7 @@ void arch_get_domain_info(const struct domain *d,
     if ( paging_mode_hap(d) )
         info->flags |=3D XEN_DOMINF_hap;
=20
-    info->arch_config.emulation_flags =3D d->arch.emulation_flags;
+    info->arch_config.emulation_flags =3D d->emulation_flags;
     info->gpaddr_bits =3D hap_paddr_bits;
 }
=20
diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/d=
omain.h
index 8c0dea12a5..eafd5cfc90 100644
--- a/xen/arch/x86/include/asm/domain.h
+++ b/xen/arch/x86/include/asm/domain.h
@@ -455,9 +455,6 @@ struct arch_domain
=20
     /* Don't unconditionally inject #GP for unhandled MSRs. */
     bool msr_relaxed;
-
-    /* Emulated devices enabled bitmap. */
-    uint32_t emulation_flags;
 } __cacheline_aligned;
=20
 #ifdef CONFIG_HVM
@@ -494,17 +491,17 @@ struct arch_domain
                                  X86_EMU_PIT | X86_EMU_USE_PIRQ |       \
                                  X86_EMU_VPCI)
=20
-#define has_vlapic(d)      (!!((d)->arch.emulation_flags & X86_EMU_LAPIC))
-#define has_vhpet(d)       (!!((d)->arch.emulation_flags & X86_EMU_HPET))
-#define has_vpm(d)         (!!((d)->arch.emulation_flags & X86_EMU_PM))
-#define has_vrtc(d)        (!!((d)->arch.emulation_flags & X86_EMU_RTC))
-#define has_vioapic(d)     (!!((d)->arch.emulation_flags & X86_EMU_IOAPIC)=
)
-#define has_vpic(d)        (!!((d)->arch.emulation_flags & X86_EMU_PIC))
-#define has_vvga(d)        (!!((d)->arch.emulation_flags & X86_EMU_VGA))
-#define has_viommu(d)      (!!((d)->arch.emulation_flags & X86_EMU_IOMMU))
-#define has_vpit(d)        (!!((d)->arch.emulation_flags & X86_EMU_PIT))
-#define has_pirq(d)        (!!((d)->arch.emulation_flags & X86_EMU_USE_PIR=
Q))
-#define has_vpci(d)        (!!((d)->arch.emulation_flags & X86_EMU_VPCI))
+#define has_vlapic(d)      (!!((d)->emulation_flags & X86_EMU_LAPIC))
+#define has_vhpet(d)       (!!((d)->emulation_flags & X86_EMU_HPET))
+#define has_vpm(d)         (!!((d)->emulation_flags & X86_EMU_PM))
+#define has_vrtc(d)        (!!((d)->emulation_flags & X86_EMU_RTC))
+#define has_vioapic(d)     (!!((d)->emulation_flags & X86_EMU_IOAPIC))
+#define has_vpic(d)        (!!((d)->emulation_flags & X86_EMU_PIC))
+#define has_vvga(d)        (!!((d)->emulation_flags & X86_EMU_VGA))
+#define has_viommu(d)      (!!((d)->emulation_flags & X86_EMU_IOMMU))
+#define has_vpit(d)        (!!((d)->emulation_flags & X86_EMU_PIT))
+#define has_pirq(d)        (!!((d)->emulation_flags & X86_EMU_USE_PIRQ))
+#define has_vpci(d)        (!!((d)->emulation_flags & X86_EMU_VPCI))
=20
 #define gdt_ldt_pt_idx(v) \
       ((v)->vcpu_id >> (PAGETABLE_ORDER - GDT_LDT_VCPU_SHIFT))
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index 0bb842ec00..cd731452ba 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -306,6 +306,7 @@ static void cf_check dump_domains(unsigned char key)
             if ( test_bit(i, &d->watchdog_inuse_map) )
                 printk("    watchdog %d expires in %d seconds\n",
                        i, (u32)((d->watchdog_timer[i].expires - NOW()) >> =
30));
+        printk("    emulation_flags %#x\n", d->emulation_flags);
=20
         arch_dump_domain_info(d);
=20
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index b17aada5f5..1393923986 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -651,6 +651,8 @@ struct domain
     unsigned int num_llc_colors;
     const unsigned int *llc_colors;
 #endif
+
+    uint32_t emulation_flags;
 } __aligned(PAGE_SIZE);
=20
 static inline struct page_list_head *page_to_list(
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Mon Jun 02 19:17:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 19:17:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003774.1383394 (Exim 4.92)
	(envelope-from )
	id 1uMAfL-0000Kv-G0; Mon, 02 Jun 2025 19:17:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003774.1383394; Mon, 02 Jun 2025 19: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 1uMAfL-0000Ko-Cl; Mon, 02 Jun 2025 19:17:47 +0000
Received: by outflank-mailman (input) for mailman id 1003774;
 Mon, 02 Jun 2025 19:17:46 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uMAfK-0000JS-I9
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 19:17:46 +0000
Received: from mail-24418.protonmail.ch (mail-24418.protonmail.ch
 [109.224.244.18]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 43147dee-3fe6-11f0-a300-13f23c93f187;
 Mon, 02 Jun 2025 21:17:45 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 43147dee-3fe6-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1748891864; x=1749151064;
	bh=uzDJxgN96Kqct/U5nq9L2/hSZ+SqbrgJbBHgdSzDlw8=;
	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=N0t0Aeyiiu2xj4exQknK6b4bzlblBLK1kUHpxCissNgvb507Z4ngR7isvwZyedmZV
	 jSLno16ODafAY5HmtbWfl/F4ZdZ3g9ryH6gAxzCGEPLvK15EpdpML3iVV6yJurcAJf
	 5qFi/JexUzkjoODs78uVrSOt7GP6NctREv7MkuQCpO9Xy60ROthvRmSOKWhMUIPVzr
	 cLSv/DgjGFw8kt2ApZIguSy+aPHMDHNn8qZuxk6waXSA10Mb8Ih2/CB6S3gfqbGIyh
	 mKOWvoKxELGmVE08DQ1uikGvpNMoQUuRwls2uccnLxDdGRNH8R0Pry+RobYQh/iH46
	 WNXst4DSGsf8g==
Date: Mon, 02 Jun 2025 19:17:38 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com
Subject: [PATCH v5 2/2] xen/domain: rewrite emulation_flags_ok()
Message-ID: <20250602191717.148361-3-dmukhin@ford.com>
In-Reply-To: <20250602191717.148361-1-dmukhin@ford.com>
References: <20250602191717.148361-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 9ead51012b322b3702c37d34c3ae7cb06b5d2c06
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Rewrite emulation_flags_ok() to simplify future modifications.

No functional change intended.

Signed-off-by: Denis Mukhin 
Reviewed-by: Stefano Stabellini 
Reviewed-by: Teddy Astie 
---
Changes since v4:
- updated commentaries
- added Teddy's R-b, kept Stefano's R-b
---
 xen/arch/x86/domain.c | 91 ++++++++++++++++++++++++++++++++++---------
 1 file changed, 73 insertions(+), 18 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 0363ccb384..4f6670ce37 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -743,32 +743,87 @@ int arch_sanitise_domain_config(struct xen_domctl_cre=
atedomain *config)
     return 0;
 }
=20
+/*
+ * Verify that the domain's emulation flags resolve to a supported configu=
ration.
+ *
+ * This ensures we only allow a known, safe subset of emulation combinatio=
ns
+ * (for both functionality and security). Arbitrary mixes are likely to ca=
use
+ * errors (e.g., null pointer dereferences).
+ *
+ * NB: use the internal X86_EMU_XXX symbols, not the public XEN_X86_EMU_XX=
X
+ * symbols.
+ */
 static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
 {
+    enum {
+        CAP_PV          =3D BIT(0, U),
+        CAP_HVM         =3D BIT(1, U),
+        CAP_HWDOM       =3D BIT(2, U),
+        CAP_DOMU        =3D BIT(3, U),
+    };
+    static const struct {
+        unsigned int caps;
+        uint32_t min;
+        uint32_t opt;
+    } configs[] =3D {
+#ifdef CONFIG_PV
+        /* PV */
+        {
+            .caps   =3D CAP_PV | CAP_DOMU,
+            .min    =3D 0,
+            .opt    =3D 0,
+        },
+
+        /* PV dom0 */
+        {
+            .caps   =3D CAP_PV | CAP_HWDOM,
+            .min    =3D X86_EMU_PIT,
+            .opt    =3D 0,
+        },
+#endif /* #ifdef CONFIG_PV */
+
+#ifdef CONFIG_HVM
+        /* PVH dom0 */
+        {
+            .caps   =3D CAP_HVM | CAP_HWDOM,
+            .min    =3D X86_EMU_LAPIC | X86_EMU_IOAPIC | X86_EMU_VPCI,
+            .opt    =3D 0,
+        },
+
+        /* HVM domU */
+        {
+            .caps   =3D CAP_HVM | CAP_DOMU,
+            .min    =3D X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ),
+            /* HVM PIRQ feature is user-selectable. */
+            .opt    =3D X86_EMU_USE_PIRQ,
+        },
+
+        /* PVH domU */
+        {
+            .caps   =3D CAP_HVM | CAP_DOMU,
+            .min    =3D X86_EMU_LAPIC,
+            .opt    =3D 0,
+        },
+#endif /* #ifdef CONFIG_HVM */
+    };
+    unsigned int i, caps =3D is_hardware_domain(d) ? CAP_HWDOM : CAP_DOMU;
+
+    if ( is_pv_domain(d) )
+        caps |=3D CAP_PV;
+    else if ( is_hvm_domain(d) )
+        caps |=3D CAP_HVM;
+
 #ifdef CONFIG_HVM
     /* This doesn't catch !CONFIG_HVM case but it is better than nothing *=
/
     BUILD_BUG_ON(X86_EMU_ALL !=3D XEN_X86_EMU_ALL);
 #endif
=20
-    if ( is_hvm_domain(d) )
-    {
-        if ( is_hardware_domain(d) &&
-             emflags !=3D (X86_EMU_VPCI | X86_EMU_LAPIC | X86_EMU_IOAPIC) =
)
-            return false;
-        if ( !is_hardware_domain(d) &&
-             /* HVM PIRQ feature is user-selectable. */
-             (emflags & ~X86_EMU_USE_PIRQ) !=3D
-             (X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ)) &&
-             emflags !=3D X86_EMU_LAPIC )
-            return false;
-    }
-    else if ( emflags !=3D 0 && emflags !=3D X86_EMU_PIT )
-    {
-        /* PV or classic PVH. */
-        return false;
-    }
+    for ( i =3D 0; i < ARRAY_SIZE(configs); i++ )
+        if ( caps =3D=3D configs[i].caps &&
+             (emflags & ~configs[i].opt) =3D=3D configs[i].min )
+            return true;
=20
-    return true;
+    return false;
 }
=20
 void __init arch_init_idle_domain(struct domain *d)
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Mon Jun 02 20:03:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 20:03:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003796.1383403 (Exim 4.92)
	(envelope-from )
	id 1uMBNW-0006nC-Sc; Mon, 02 Jun 2025 20:03:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003796.1383403; Mon, 02 Jun 2025 20:03:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMBNW-0006n5-PF; Mon, 02 Jun 2025 20:03:26 +0000
Received: by outflank-mailman (input) for mailman id 1003796;
 Mon, 02 Jun 2025 20:03: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 1uMBNV-0006mz-Ba
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 20:03:25 +0000
Received: from gw3.antarean.org (gw3.antarean.org [84.247.13.64])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id a3c037bd-3fec-11f0-a300-13f23c93f187;
 Mon, 02 Jun 2025 22:03:24 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
 by gw3.antarean.org (Postfix) with ESMTP id 4bB4Y24pZZzNsTk;
 Mon, 02 Jun 2025 22:03:50 +0200 (CEST)
Received: from gw3.antarean.org ([127.0.0.1])
 by localhost (gw3.antarean.org [127.0.0.1]) (amavis, port 10024) with ESMTP
 id 8OESF7r7NInZ; Mon,  2 Jun 2025 22:03:50 +0200 (CEST)
Received: from mailstore1.adm.antarean.org (localhost [127.0.0.1])
 by gw3.antarean.org (Postfix) with ESMTP id 4bB4Y244pTzNl38;
 Mon, 02 Jun 2025 22:03:50 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
 by mailstore1.adm.antarean.org (Postfix) with ESMTP id 4bB4XW4Pvqz1G;
 Mon, 02 Jun 2025 20:03:23 +0000 (UTC)
Received: from mailstore1.adm.antarean.org ([127.0.0.1])
 by localhost (mailstore1.adm.antarean.org [127.0.0.1]) (amavis, port 10024)
 with ESMTP id KKwbrsgDTe5q; Mon,  2 Jun 2025 20:03:22 +0000 (UTC)
Received: from persephone.localnet (persephone.adm.antarean.org [10.55.16.48])
 (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 mailstore1.adm.antarean.org (Postfix) with ESMTPS id 4bB4XV5rLtz17;
 Mon, 02 Jun 2025 20:03: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: a3c037bd-3fec-11f0-a300-13f23c93f187
X-Virus-Scanned: amavis at antarean.org
X-Virus-Scanned: amavis at antarean.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=antarean.org;
	s=default; t=1748894602;
	bh=lO4povlG+nifRCUarMVCoMNsX8KccwxbuFAlasir/z4=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References;
	b=OZnYIQFTWZqNRLdo4elycwh1KXyVshkU1sCrwJssRPEDCqXJXrDQChGg59A5Gpvvw
	 fm/IJYjjncs5CgN7krmRb+//wmhP+CQHWOR5NEK22zc13BLm8IM151rJfZWFP1bz5T
	 aSi2BeD8FJnc3oV+i2AOMj1c8RUhrMAgbFxENb7g=
From: "J. Roeleveld" 
To: xen-devel@lists.xenproject.org, Jan Beulich 
Cc: "J. Roeleveld" 
Subject: Re: Kernel panic when passing through 2 identical PCI devices
Date: Mon, 02 Jun 2025 22:03:22 +0200
Message-ID: <7829526.EvYhyI6sBW@persephone>
In-Reply-To: <13792630.uLZWGnKmhe@persephone>
References:
 <2226691.irdbgypaU6@persephone>
 
 <13792630.uLZWGnKmhe@persephone>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="utf-8"

(top-posting as this has extra info and not sure where to put it otherwise)

Jan, (and others),

As the HBA devices seem to work correctly, I've been looking further into 
differences.
One thing that could be a problem is how the PCI-devices are connected.

The HBAs are each in a seperate PCIe slot.
The NVMe drives are in a single slot with bifurcation (4x4x4x4) enabled.
There are a total of 4 drives. 2 are for the host, the other 2 for this guest 
domain.
Specifically, I use one of these:
https://www.asus.com/motherboards-components/motherboards/accessories/hyper-m-2-x16-card-v2/

Am currently trying to figure out which function/procedures in the kernel code 
are being used and which would make sense to add additional output with.
Will standard "printf" commands work? Or should I use something else to get 
the output printed to the same output as the rest the kernel outputs?

I could definitely use some assistance with this part. Ideally, I would like to 
put extra output at all possible causes at once.

Many thanks,

Joost


On Monday, 2 June 2025 16:37:36 CEST J. Roeleveld wrote:
> On Monday, 2 June 2025 16:31:11 CEST Jan Beulich wrote:
> > On 02.06.2025 16:19, J. Roeleveld wrote:
> > > On Monday, 2 June 2025 15:43:37 CEST you wrote:
> > >> On 02.06.2025 14:28, J. Roeleveld wrote:
> > >>> I have a domain to which I pass through 4 PCI devices:
> > >>> 2 NVMe drives
> > >>> 83:00.0   Samsung 980 NVMe
> > >>> 84:00.0   Samsung 980 NVMe
> > >>> 
> > >>> 2 HBA Controllers
> > >>> 86:00.0   LSI SAS3008
> > >>> 87:00.0   LSI SAS3008
> > >>> 
> > >>> This works fine with Xen version 4.18.4_pre1.
> > >>> However, when trying to update to 4.19, this fails.
> > >> 
> > >> To make it explicit: The domain in question is a PV one.
> > > 
> > > Yes. I tried to convert it to PVH in the past, but PCI-passthrough
> > > wasn't
> > > working at all. And nothing I found since shows that it should be
> > > working
> > > now.>
> > > 
> > >>> Checking the output during boot, I think I found something. But my
> > >>> knowledge is insufficient to figure out what is causing what I am
> > >>> seeing
> > >>> and how to fix this.
> > >>> 
> > >>> From the below (where I only focus on the 2 NVMe drives), it is
> > >>> similar
> > >>> to
> > >>> the succesfull boot up until it tries to "claiming resource
> > >>> 0000:84:00.0/0". At which point sysfs fails because the entry for "84"
> > >>> is
> > >>> already present.
> > >> 
> > >> What would be interesting is to know why / how this 2nd registration
> > >> happens.
> > > 
> > > Only guess I can make: They are both the same brand/model/size. Only
> > > serial number differs
> > 
> > I don't think this matters here at all. The guest isn't at the point yet
> > where it would even be able to retrieve these. From the log you provided
> > it's the PCI subsystem where the issue is triggered.
> 
> This goes beyond my knowledge. Which means I'd rather provide too much
> information then too little :)
> 
> > >> It's the same (guest) kernel version afaics, so something must
> > >> behave differently on the host. Are you sure the sole (host side)
> > >> difference is the hypervisor version? I.e. the Dom0 kernel version is
> > >> the
> > >> same in the failing and successful cases? I ask because there's very
> > >> little
> > >> Xen itself does that would play into pass-through device discovery /
> > >> resource setup by a (PV) guest (which doesn't mean Xen can't screw
> > >> things
> > >> up). The more relevant component is the xen-pciback driver in Dom0.
> > > 
> > > I can confirm it's dependent on the Xen version.
> > > Kernel version  = 6.12.21
> > > I get a succesful boot with Xen version 4.18.4_pre1.
> > > When I use Xen version 4.19.1, the boot fails due to this issue.
> > > 
> > > The kernel and initramfs does not differ between the boot.
> > 
> > And that's the Dom0 kernel, just to clarify? There are two kernels
> > involved
> > here, after all.
> 
> Yes. Dom0 and the guest have their own kernel images.
> However, both run the same version. (I compile kernels from source)
> 
> > >> Sadly the log provided does, to me at least, not have enough data to
> > >> draw
> > >> conclusions. Some instrumenting of the guest kernel may be necessary
> > >> ...
> > > 
> > > The host boots using UEFI:
> > > 
> > > === (xen.cfg in the EFI partition) ===
> > > [global]
> > > default=xen
> > > 
> > > [xen]
> > > options=dom0_mem=24576M,max:24576M dom0_max_vcpus=4 dom0_vcpus_pin
> > > gnttab_max_frames=512 sched=credit console=vga extra_guest_irqs=768,1024
> > > 
> > > kernel=gentoo-6.12.21.efi dozfs root=ZFS=zhost/host/root by=id
> > > elevator=noop logo.nologo triggers=zfs quiet refresh softlevel=prexen
> > > nomodeset
> > > nfs.callback_tcpport=32764 lockd.nlm_udpport=32768
> > > lockd.nlm_tcpport=32768
> > > xen-pciback.hide=(83:00.0)(84:00.0)(86:00.0)(87:00.0) xen-
> > > pciback.passthrough=1
> > > 
> > > ramdisk=initramfs-6.12.21-gentoo-host.img
> > > ===
> > > 
> > > Please let me know what other information you need and if there is
> > > anything I can try/test to get more information.
> > > Does the mailing list allow gzipped text files as attachment? Or how
> > > would
> > > you prefer the kernel-config of the host and guest?
> > 
> > I don't think these are relevant (for the moment).
> 
> Ok.
> 
> > > If there are tests to do, please give me several to try as I need to
> > > schedule downtime for reboots.
> > 
> > That would be some kernel hacking, as indicated before: Instrument the
> > (guest) kernel enough to figure out where the 1st and 2nd sysfs
> > registrations come from. This may then give us a clue what's being driven
> > the wrong way (by Xen, or maybe by the toolstack).
> 
> If you could point me to a guide on how to do this?
> I know enough about C/C++ to write my own tools. But the kernel and Xen is
> too complex for me to follow and I would not even know where to begin.
> 
> --
> Joost






From xen-devel-bounces@lists.xenproject.org Mon Jun 02 20:25:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 20:25:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003803.1383415 (Exim 4.92)
	(envelope-from )
	id 1uMBj4-000176-Ko; Mon, 02 Jun 2025 20:25:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003803.1383415; Mon, 02 Jun 2025 20:25: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 1uMBj4-00016z-GQ; Mon, 02 Jun 2025 20:25:42 +0000
Received: by outflank-mailman (input) for mailman id 1003803;
 Mon, 02 Jun 2025 20: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 1uMBj3-00016t-QN
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 20:25:41 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id be4e5753-3fef-11f0-b894-0df219b8e170;
 Mon, 02 Jun 2025 22:25:38 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1748895930344260.98692996946454;
 Mon, 2 Jun 2025 13:25:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: be4e5753-3fef-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; t=1748895932; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=HKzHGpEXYnRqGPCUZkth+IDpmu5A0WYc9TeI7GmpfXAgfIujcJsynV2gunhlCRjB/xAghjroyAs4aJG9dp82gsxHl2EVKobt0fF/DhCmx7ln6W2wujvFRzxc6R0Hktf0vdRVYm//tbZKaGMqmmkAW33Hds773T/T1NzUZkDIXvo=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1748895932; 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=OFbGuhWeDFUWODp5A9qftGfaGuYqssnm/PhkfG9YU5w=; 
	b=KxomQ/5+NJpEQwXuUc+gG28Pji4yjQfmlm0JVwhOpiOmTFnZRpBJzk7jm+NREknj1iFD7HPjfTDva4vHsdfJBr+93qwpbbQio4zLi8DecfYloXc05HSNvGtWomrnMFO6YvfaVPWSTAdPAPtCybJB2t1Nlk0PXrhGslGbcn/PzRI=
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=1748895932;
	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=OFbGuhWeDFUWODp5A9qftGfaGuYqssnm/PhkfG9YU5w=;
	b=mlhx98A3RzWDcWBp1F/+rPLX2TlRSx98QyzoIcTZ9GR9kyv2AF8UGTqVZuTk3tuz
	yeEEjweC2ByB8zZSgjyHxeaH9cXPXt74r82QhPHJ6iKL3G8nMRdg5B8dRkT56hc51Ty
	pxsdbagBqiNwYOHEwfS10dlPZ5UGZY2S6AO5Cqzw=
Message-ID: 
Date: Mon, 2 Jun 2025 16:25:28 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 12/19] xen/dt: Move bootfdt functions to xen/bootfdt.h
Content-Language: en-US
To: Alejandro Vallejo , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: 
 <20250530120242.39398-1-agarciav@amd.com>
 <20250530120242.39398-13-agarciav@amd.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: <20250530120242.39398-13-agarciav@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 5/30/25 08:02, Alejandro Vallejo wrote:
> Part of an unpicking process to extract bootfdt contents independent of bootinfo
> to a separate file for x86 to take.
> 
> Move functions required for early FDT parsing from device_tree.h and arm's
> setup.h onto bootfdt.h
> 
> Declaration motion only. Not a functional change.
> 
> Signed-off-by: Alejandro Vallejo 
> ---
>   xen/arch/arm/include/asm/setup.h |  6 ----
>   xen/include/xen/bootfdt.h        | 62 ++++++++++++++++++++++++++++++++
>   xen/include/xen/device_tree.h    | 34 +-----------------
>   3 files changed, 63 insertions(+), 39 deletions(-)
> 
> diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
> index 0f9e531a34..32308837a9 100644
> --- a/xen/arch/arm/include/asm/setup.h
> +++ b/xen/arch/arm/include/asm/setup.h
> @@ -55,12 +55,6 @@ void setup_mm(void);
>   extern uint32_t hyp_traps_vector[];
>   void init_traps(void);
>   
> -void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
> -                         uint32_t size_cells, paddr_t *start, paddr_t *size);
> -
> -u32 device_tree_get_u32(const void *fdt, int node,
> -                        const char *prop_name, u32 dflt);
> -
>   int handle_device(struct domain *d, struct dt_device_node *dev, p2m_type_t p2mt,
>                     struct rangeset *iomem_ranges, struct rangeset *irq_ranges);
>   
> diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
> index fa65e8fcf4..079259c719 100644
> --- a/xen/include/xen/bootfdt.h
> +++ b/xen/include/xen/bootfdt.h
> @@ -2,6 +2,7 @@
>   #ifndef XEN_BOOTFDT_H
>   #define XEN_BOOTFDT_H
>   
> +#include 
>   #include 
>   #include 
>   #include 
> @@ -16,8 +17,53 @@
>   #define NR_MEM_BANKS 256
>   #define NR_SHMEM_BANKS 32
>   
> +/* Default #address and #size cells */
> +#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
> +#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
> +
>   #define MAX_MODULES 32 /* Current maximum useful modules */
>   
> +#define DEVICE_TREE_MAX_DEPTH 16
> +
> +/* Helper to read a big number; size is in cells (not bytes) */
> +static inline u64 dt_read_number(const __be32 *cell, int size)
> +{
> +    u64 r = 0;
> +
> +    while ( size-- )
> +        r = (r << 32) | be32_to_cpu(*(cell++));
> +    return r;
> +}

I know you are trying to keep code changes to a minimal but let's not 
allow poorly constructed logic like this to continue to persist. This is 
an unbounded, arbitrary read function that is feed parameters via 
externally input. The DT spec declares only two number types for a 
property, u32 and u64, see Table 2.3 in Section 2.2.4. There is no 
reason to have an unbounded, arbitrary read function lying around 
waiting to be leveraged in exploitation.


> +static inline u64 dt_next_cell(int s, const __be32 **cellp)
> +{
> +    const __be32 *p = *cellp;
> +
> +    *cellp = p + s;
> +    return dt_read_number(p, s);
> +}
> +
> +typedef int (*device_tree_node_func)(const void *fdt,
> +                                     int node, const char *name, int depth,
> +                                     u32 address_cells, u32 size_cells,
> +                                     void *data);
> +
> +/**
> + * device_tree_for_each_node - iterate over all device tree sub-nodes
> + * @fdt: flat device tree.
> + * @node: parent node to start the search from
> + * @func: function to call for each sub-node.
> + * @data: data to pass to @func.
> + *
> + * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
> + *
> + * Returns 0 if all nodes were iterated over successfully.  If @func
> + * returns a value different from 0, that value is returned immediately.
> + */
> +int device_tree_for_each_node(const void *fdt, int node,
> +                              device_tree_node_func func,
> +                              void *data);
> +
>   typedef enum {
>       BOOTMOD_XEN,
>       BOOTMOD_FDT,
> @@ -246,4 +292,20 @@ static inline struct membanks *membanks_xzalloc(unsigned int nr,
>       return banks;
>   }
>   
> +/*
> + * Interpret the property `prop_name` of `node` as a u32.
> + *
> + * Returns the property value on success; otherwise returns `dflt`.
> + */
> +uint32_t device_tree_get_u32(const void *fdt, int node,
> +                             const char *prop_name, uint32_t dflt);
> +
> +/*
> + * Interpret the property `prop_name` of `node` as a "reg".
> + *
> + * Returns outputs in `start` and `size`.
> + */
> +void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
> +                         uint32_t size_cells, paddr_t *start, paddr_t *size);
> +
>   #endif /* XEN_BOOTFDT_H */
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> index 6dc1fb5159..0a22b1ba1d 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -10,6 +10,7 @@
>   #ifndef __XEN_DEVICE_TREE_H__
>   #define __XEN_DEVICE_TREE_H__
>   
> +#include 
>   #include 
>   
>   #include 
> @@ -22,8 +23,6 @@
>   #include 
>   #include 
>   
> -#define DEVICE_TREE_MAX_DEPTH 16
> -
>   /*
>    * Struct used for matching a device
>    */
> @@ -164,17 +163,8 @@ struct dt_raw_irq {
>       u32 specifier[DT_MAX_IRQ_SPEC];
>   };
>   
> -typedef int (*device_tree_node_func)(const void *fdt,
> -                                     int node, const char *name, int depth,
> -                                     u32 address_cells, u32 size_cells,
> -                                     void *data);
> -
>   extern const void *device_tree_flattened;
>   
> -int device_tree_for_each_node(const void *fdt, int node,
> -                              device_tree_node_func func,
> -                              void *data);
> -
>   /**
>    * dt_unflatten_host_device_tree - Unflatten the host device tree
>    *
> @@ -245,10 +235,6 @@ void intc_dt_preinit(void);
>   #define dt_node_cmp(s1, s2) strcasecmp((s1), (s2))
>   #define dt_compat_cmp(s1, s2) strcasecmp((s1), (s2))
>   
> -/* Default #address and #size cells */
> -#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
> -#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
> -
>   #define dt_for_each_property_node(dn, pp)                   \
>       for ( pp = (dn)->properties; (pp) != NULL; pp = (pp)->next )
>   
> @@ -258,16 +244,6 @@ void intc_dt_preinit(void);
>   #define dt_for_each_child_node(dt, dn)                      \
>       for ( dn = (dt)->child; (dn) != NULL; dn = (dn)->sibling )
>   
> -/* Helper to read a big number; size is in cells (not bytes) */
> -static inline u64 dt_read_number(const __be32 *cell, int size)
> -{
> -    u64 r = 0;
> -
> -    while ( size-- )
> -        r = (r << 32) | be32_to_cpu(*(cell++));
> -    return r;
> -}
> -
>   /* Wrapper for dt_read_number() to return paddr_t (instead of uint64_t) */
>   static inline paddr_t dt_read_paddr(const __be32 *cell, int size)
>   {
> @@ -307,14 +283,6 @@ static inline int dt_size_to_cells(int bytes)
>       return (bytes / sizeof(u32));
>   }
>   
> -static inline u64 dt_next_cell(int s, const __be32 **cellp)
> -{
> -    const __be32 *p = *cellp;
> -
> -    *cellp = p + s;
> -    return dt_read_number(p, s);
> -}
> -
>   static inline const char *dt_node_full_name(const struct dt_device_node *np)
>   {
>       return (np && np->full_name) ? np->full_name : "";



From xen-devel-bounces@lists.xenproject.org Mon Jun 02 22:01:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 22:01:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003822.1383424 (Exim 4.92)
	(envelope-from )
	id 1uMDDP-0004Ld-Av; Mon, 02 Jun 2025 22:01:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003822.1383424; Mon, 02 Jun 2025 22:01: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 1uMDDP-0004LW-8F; Mon, 02 Jun 2025 22:01:07 +0000
Received: by outflank-mailman (input) for mailman id 1003822;
 Mon, 02 Jun 2025 22:01: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 1uMDDM-0004LQ-Q9
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 22:01:05 +0000
Received: from 8.mo584.mail-out.ovh.net (8.mo584.mail-out.ovh.net
 [188.165.33.112]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 11b8142a-3ffd-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 00:01:00 +0200 (CEST)
Received: from director9.ghost.mail-out.ovh.net (unknown [10.109.139.212])
 by mo584.mail-out.ovh.net (Postfix) with ESMTP id 4bB78D1vX1z1XD6
 for ; Mon,  2 Jun 2025 22:01:00 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-z7k6k (unknown [10.110.178.109])
 by director9.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 80FB68427D;
 Mon,  2 Jun 2025 22:00:58 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.104])
 by ghost-submission-5b5ff79f4f-z7k6k with ESMTPSA
 id Ul6XDRofPmhoPwAAZZ0Mgw
 (envelope-from ); Mon, 02 Jun 2025 22:00: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: 11b8142a-3ffd-11f0-b894-0df219b8e170
Authentication-Results:garm.ovh; auth=pass (GARM-104R005fbf77e3d-68e7-4982-8eec-f06a31c6c116,
                    22913471B39E4060B5DF5B2870BF10C0EF5640C4) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
Date: Tue, 3 Jun 2025 01:00:36 +0300
From: Sergii Dmytruk 
To: Jan Beulich 
Cc: "Daniel P. Smith" ,
	Ross Philipson ,
	Andrew Cooper ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	Lukasz Hawrylko ,
	Mateusz =?iso-8859-1?Q?M=F3wka?= ,
	trenchboot-devel@googlegroups.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 01/22] x86/include/asm/intel-txt.h: constants and
 accessors for TXT registers and heap
Message-ID: 
References: 
 
 
 
 <31c7faf1-d393-40d5-87f9-1a01d1ab39cb@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <31c7faf1-d393-40d5-87f9-1a01d1ab39cb@suse.com>
X-Ovh-Tracer-Id: 2241666716339123289
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgdefkeekvdculddtuddrgeefvddrtddtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhepvdfgveegtdffhfdugeevieehkeetudevfeefgedtleejledvfeeutdetudeiveelnecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukeegrddvvddupdefjedrheelrddugedvrddutdegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheekgegmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=oVm7ZC4ZeWySj8lX3Edhum+W60jZvZ4icN77j/Wnutk=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1748901660; v=1;
 b=WpOdxqDcfo6s+/igEzL74R3V3J86EJPM39DOPikCFAEQe5lXrIXX1NWW92LclhiVqlzlED9S
 IRVlrX7n5CxXQ18jQ+x4hR+K0gbSaXcXnVThhhuDZ/i1fuRJSEib/w1/eYtl0Q4PTvDdYGaVW1R
 EhUB+hqcWWYUUSFcJfHQ73lpMV0Gk66eP+0S3gy6K6WNFPoxhL7YnI+Q3pXywD9LC5skk0U1ZIu
 kM7uBP+Ed7HRFRClScmsiTQkBnKP5C26CdXqeNjkLvb5yzvWmsnyhvpL7wDTW/VNzByqlV3NOf+
 7MRFVt0wdjCbfY2OqhoW4Egoc3OX8Q6g+QUXrwRKq+nYw==

On Mon, Jun 02, 2025 at 09:17:37AM +0200, Jan Beulich wrote:
> On 23.05.2025 21:51, Sergii Dmytruk wrote:
> > On Wed, May 21, 2025 at 05:19:57PM +0200, Jan Beulich wrote:
> >>> +/*
> >>> + * Secure Launch defined OS/MLE TXT Heap table
> >>> + */
> >>> +struct txt_os_mle_data {
> >>> +    uint32_t version;
> >>> +    uint32_t reserved;
> >>> +    uint64_t slrt;
> >>> +    uint64_t txt_info;
> >>> +    uint32_t ap_wake_block;
> >>> +    uint32_t ap_wake_block_size;
> >>> +    uint8_t mle_scratch[64];
> >>> +} __packed;
> >>
> >> This being x86-specific, what's the __packed intended to achieve here?
> >
> > This structure is passed to Xen by a bootloader, __packed makes sure the
> > structure has a compatible layout.
>
> And it won't have a compatible layout without the attribute?

It will, but presence of __packed makes it trivial to see.

> >>> +/*
> >>> + * TXT specification defined BIOS data TXT Heap table
> >>> + */
> >>> +struct txt_bios_data {
> >>> +    uint32_t version; /* Currently 5 for TPM 1.2 and 6 for TPM 2.0 */
> >>> +    uint32_t bios_sinit_size;
> >>> +    uint64_t reserved1;
> >>> +    uint64_t reserved2;
> >>> +    uint32_t num_logical_procs;
> >>> +    /* Versions >= 3 && < 5 */
> >>> +    uint32_t sinit_flags;
> >>> +    /* Versions >= 5 with updates in version 6 */
> >>> +    uint32_t mle_flags;
> >>> +    /* Versions >= 4 */
> >>> +    /* Ext Data Elements */
> >>> +} __packed;
> >>
> >> It does affect sizeof() here, which I'm unsure is going to matter.
> >
> > It doesn't hurt anything and makes sure offsets match those in the
> > specification.
>
> It similarly doesn't appear to hurt anything if the attribute was omitted.
> Imo we ought to use compiler extensions on when there is a need to do so.

I would argue that it hurts maintainability and code readability to some
extent:
 * when the attribute is used, there is no need to verify compatibility
   in any way (manually or using pahole) neither now nor on any future
   modification
 * when I see __packed, I immediately know the structure is defined
   externally and can't be changed at will
 * having the attribute only for some structures seems inconsistent

It would be nice if it was possible to verify the structure is packed
via a static assert using only standard C, but without such means I see
__packed as useful and harmless compiler extension.

I can of course drop unnecessary attributes if that's a standard
practice for Xen's sources, never thought it could be undesirable in
a context like this one.

> >>> +static inline uint64_t txt_bios_data_size(void *heap)
> >>
> >> Here, below, and in general: Please try to have code be const-correct, i.e.
> >> use pointers-to-const wherever applicable.
> >
> > I assume this doesn't apply to functions returning `void *`.  The
> > approach used in libc is to accept pointers-to-const but then cast the
> > constness away for the return value, but this header isn't a widely-used
> > code.
>
> Which is, from all I know, bad practice not only by my own view.
>
> Jan

I actually ended up doing that to have const-correctness in v3.  In the
absence of function overloads the casts have to be somewhere, can put
them in the calling code instead.

Regards


From xen-devel-bounces@lists.xenproject.org Mon Jun 02 22:19:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 22:19:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003829.1383434 (Exim 4.92)
	(envelope-from )
	id 1uMDVH-00065X-Q5; Mon, 02 Jun 2025 22:19:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003829.1383434; Mon, 02 Jun 2025 22:19:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMDVH-00065Q-Ls; Mon, 02 Jun 2025 22:19:35 +0000
Received: by outflank-mailman (input) for mailman id 1003829;
 Mon, 02 Jun 2025 22:19: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 1uMDVG-000651-HK
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 22:19:34 +0000
Received: from 11.mo581.mail-out.ovh.net (11.mo581.mail-out.ovh.net
 [87.98.173.157]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a5f536fd-3fff-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 00:19:28 +0200 (CEST)
Received: from director2.ghost.mail-out.ovh.net (unknown [10.109.148.12])
 by mo581.mail-out.ovh.net (Postfix) with ESMTP id 4bB7YW6vCFz1SPG
 for ; Mon,  2 Jun 2025 22:19:27 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-2249b (unknown [10.110.118.96])
 by director2.ghost.mail-out.ovh.net (Postfix) with ESMTPS id A8CB8C3B95;
 Mon,  2 Jun 2025 22:19:26 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.100])
 by ghost-submission-5b5ff79f4f-2249b with ESMTPSA
 id +vF7GW4jPmjPbgIAM3Irlw
 (envelope-from ); Mon, 02 Jun 2025 22:19: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: a5f536fd-3fff-11f0-b894-0df219b8e170
Authentication-Results:garm.ovh; auth=pass (GARM-100R003952fb7fe-7527-41fd-b0a6-24c88fefecaa,
                    22913471B39E4060B5DF5B2870BF10C0EF5640C4) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
Date: Tue, 3 Jun 2025 01:19:04 +0300
From: Sergii Dmytruk 
To: Jan Beulich 
Cc: "Daniel P. Smith" ,
	Ross Philipson ,
	trenchboot-devel@googlegroups.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 02/22] include/xen/slr-table.h: Secure Launch Resource
 Table definitions
Message-ID: 
References: 
 
 <4896ab0b-f45e-43e9-bcee-f5496717eb2a@suse.com>
 
 <8521480a-f14d-4ac4-826e-6ed066619070@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8521480a-f14d-4ac4-826e-6ed066619070@suse.com>
X-Ovh-Tracer-Id: 2553259515016229977
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgdefkeekheculddtuddrgeefvddrtddtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhepvdfgveegtdffhfdugeevieehkeetudevfeefgedtleejledvfeeutdetudeiveelnecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukeegrddvvddupdefjedrheelrddugedvrddutddtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheekudgmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=8e5dtdmFkMnglKi+LBQl4WKLgk8ttsJC8rX2ANw4oew=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1748902768; v=1;
 b=XKxH5J6e8suG/iFxgf+lmAbEMGzb1BrjPfmUgsiX9oA3cZbWS/qNdAgIEMs2974ro/TQ6NSx
 9qCkrBDhP9055LQSzVO6A7sq+Q444YdNCPmLZJkyxG3u5ZaM8VK76rBI7+SWeVE5YZtOv90Vfsi
 4IGAUPVhefifneiJfO58BpuiJSoW+9I3RGFsIgcf8GQ9QPoihIY5jK6FqMU/cyqphuM/jvQJjZ9
 70D6jbMKxsPWJ5oo+G2w3lOOoSl0uxPi4nTApMDnXT4rHdGvk0aHVzO+QgbdmhFjSWiYLYT6IdF
 yZs/a51GdCYUHnHNiLy+gCjWzABIyzeqTAP0tlLZM7Svg==

On Mon, Jun 02, 2025 at 09:31:11AM +0200, Jan Beulich wrote:
> >>> +#define UEFI_SLR_TABLE_GUID \
> >>> +    { 0x877a9b2aU, 0x0385, 0x45d1, { 0xa0, 0x34, 0x9d, 0xac, 0x9c, 0x9e, 0x56, 0x5f } }
> >>
> >> I'm not sure this is a good place to put UEFI GUIDs. Considering e.g ...
> >
> > It's here because the GUID is related more to SLRT than to EFI.  I can
> > move it if there is a more fitting place for table GUIDs.
>
> It'll (at least somewhat) depend on where it's going to be used. A common problem
> when definitions / declarations are introduced without any use.

It's only used in xen/common/efi/boot.c (patch #20), so looks like it
should actually be defined there like the rest of GUIDs.

> >>> +/*
> >>> + * Primary SLR Table Header
> >>> + */
> >>> +struct slr_table
> >>> +{
> >>> +    uint32_t magic;
> >>> +    uint16_t revision;
> >>> +    uint16_t architecture;
> >>> +    uint32_t size;
> >>> +    uint32_t max_size;
> >>> +    /* entries[] */
> >>> +} __packed;
> >>
> >> If x86-specific, the question on the need for some of the __packed arises
> >> again.
> >
> > The table is used to communicate data from pre-DRTM world to DRTM-world
> > and is produced and consumed by unrelated software components that don't
> > necessarily pad structures the same way by default.
>
> How do other environments matter when this header is solely used by Xen?

Xen uses this header to read data prepared for it.  Packing is an easy
way to ensure the data will be parsed consistently regardless of the
architecture or software component which prepared it (i.e., a way to
enforce proper "API").

Regards


From xen-devel-bounces@lists.xenproject.org Mon Jun 02 22:35:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 22:35:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003838.1383444 (Exim 4.92)
	(envelope-from )
	id 1uMDkZ-0000RC-1u; Mon, 02 Jun 2025 22:35:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003838.1383444; Mon, 02 Jun 2025 22: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 1uMDkY-0000R5-Ux; Mon, 02 Jun 2025 22:35:22 +0000
Received: by outflank-mailman (input) for mailman id 1003838;
 Mon, 02 Jun 2025 22:35: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 1uMDkX-0000Qz-Mc
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 22:35:21 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dceb4e8a-4001-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 00:35:20 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id B38414A543;
 Mon,  2 Jun 2025 22:35:18 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 13BBEC4CEEB;
 Mon,  2 Jun 2025 22:35: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: dceb4e8a-4001-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748903718;
	bh=2E5pzV8xvCugbBU2TwpfB0ndT5dcL5RpcchY2wh3Mls=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=MvPkEnp9tvixn7Go/ANFbRyUriKh8ZjLpEVPQgVXhZQNIT8ASsfaZk9NNtgrwoAts
	 EaYoifYWqnFvmUntulUvZaU2l/V2VUaoCNn82mI839nUix1oIRxpaQCemzm5m9eiX+
	 wszx5ctI4MfJvOFVAga9LWNVpdH2LJNcHdCSVb5YS5/X0pXoCI1yzHNuISBGLXd4VP
	 5CvnsZhI0dAu7MxxZ9JKvxozflBr64QWAWxAeAy7mf6gixD3yMqRzqZPqYpDGxRLck
	 OFtagfmPzuHlBZWyRoj/cKwQvcFl7KPPwKv38bQ1aMIMFnb5wKYlLDNwlRef5TSZ9j
	 yMG7o9eFABjrQ==
Date: Mon, 2 Jun 2025 15:35:16 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: "Edgar E. Iglesias" 
cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org, julien@xen.org, 
    bertrand.marquis@arm.com, michal.orzel@amd.com, Volodymyr_Babchuk@epam.com, 
    andrew.cooper3@citrix.com, edgar.iglesias@amd.com, 
    Anthony PERARD , 
    Juergen Gross , Jan Beulich , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Subject: Re: [PATCH v3 1/5] xen/arm: Add way to disable traps on accesses to
 unmapped addresses
In-Reply-To: <20250530134559.1434255-2-edgar.iglesias@gmail.com>
Message-ID: 
References: <20250530134559.1434255-1-edgar.iglesias@gmail.com> <20250530134559.1434255-2-edgar.iglesias@gmail.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 30 May 2025, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias" 
> 
> Add a per-domain way to optionally disable traps for accesses
> to unmapped addresses.
> 
> The domain flag is general but it's only implemented for ARM for now.
> 
> Signed-off-by: Edgar E. Iglesias 

Reviewed-by: Stefano Stabellini 

I am OK with the name "XEN_DOMCTL_CDF_trap_unmapped_accesses" being long
but I would also be OK with a shorter name if it is still clear enough.




From xen-devel-bounces@lists.xenproject.org Mon Jun 02 22:37:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 22:37:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003844.1383454 (Exim 4.92)
	(envelope-from )
	id 1uMDmF-0000wa-CU; Mon, 02 Jun 2025 22:37:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003844.1383454; Mon, 02 Jun 2025 22:37:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMDmF-0000wT-8I; Mon, 02 Jun 2025 22:37:07 +0000
Received: by outflank-mailman (input) for mailman id 1003844;
 Mon, 02 Jun 2025 22:37: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 1uMDmD-0000wJ-90
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 22:37:05 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org
 [2600:3c0a:e001:78e:0:1991:8:25])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1a026a33-4002-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 00:37:03 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id A70F14A77F;
 Mon,  2 Jun 2025 22:37:01 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5FF63C4CEEB;
 Mon,  2 Jun 2025 22:37:00 +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: 1a026a33-4002-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748903821;
	bh=EeA0Pmye73aHgg3zJyJjPO5SGssOoFQyd/y5MP61psQ=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=HxLvJTTWSz6C0P9gvqQrATCKiczK0YhZtH90rTg5Kb2GpiFc7477ni2GEuKk9qtpj
	 I7xdfU7sFrmeMbevIMAhNKbXYFnNn5YkjRrdw7dvnc2AAZHQ3J3cLTKRYCJRMkJ3jt
	 sho3PtlX5Iv1d7LRmAgMdvZe/tEJqT1VaWOj9cb9i/NWHfTE143EAAKRAY6IeG3AJV
	 S6P3ntCmJGXb+p0eCkHr6+vrtX+uMoBKSTwsK71oPMPwZTVn8l5zcJrUDb6/T8BtCP
	 4gJhckAzBNz51MZevEYzcO5R8FpMxp2RH1h85F7e5sTl4VmfiDGgxuI19E5YtABfsA
	 ++lIFLQUjzt9A==
Date: Mon, 2 Jun 2025 15:36:59 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: "Edgar E. Iglesias" 
cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org, julien@xen.org, 
    bertrand.marquis@arm.com, michal.orzel@amd.com, Volodymyr_Babchuk@epam.com, 
    andrew.cooper3@citrix.com, edgar.iglesias@amd.com
Subject: Re: [PATCH v3 2/5] xen/arm: dom0less: Add trap-unmapped-accesses
In-Reply-To: <20250530134559.1434255-3-edgar.iglesias@gmail.com>
Message-ID: 
References: <20250530134559.1434255-1-edgar.iglesias@gmail.com> <20250530134559.1434255-3-edgar.iglesias@gmail.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 30 May 2025, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias" 
> 
> Add the trap-unmapped-accesses per-domain fdt property.
> 
> Signed-off-by: Edgar E. Iglesias 
> ---
>  docs/misc/arm/device-tree/booting.txt | 10 ++++++++++
>  xen/arch/arm/dom0less-build.c         |  9 ++++++++-
>  2 files changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
> index 59fa96a82e..9add6440de 100644
> --- a/docs/misc/arm/device-tree/booting.txt
> +++ b/docs/misc/arm/device-tree/booting.txt
> @@ -225,6 +225,16 @@ with the following properties:
>      option is provided with a non zero value, but the platform doesn't support
>      SVE.
>  
> +- trap-unmapped-accesses
> +
> +    Optional. An integer that configures handling of accesses to unmapped
> +    address ranges.
> +    If set to 0, guest accesses will read all bits as ones, e.g 0xFFFFFFFF
> +    for a 32bit access and writes will be ignored.
> +    If set to 1, guest accesses will trap.
> +
> +    This option is only implemented for ARM where the default is 1.

Please expand it to: "This option is only implemented for ARM where the
default is 1 when trap-unmapped-accesses is absent."

The change could be done on commit:

Reviewed-by: Stefano Stabellini 


>  - xen,enhanced
>  
>      A string property. Possible property values are:
> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
> index a4e0a33632..69324aa597 100644
> --- a/xen/arch/arm/dom0less-build.c
> +++ b/xen/arch/arm/dom0less-build.c
> @@ -344,8 +344,15 @@ void __init arch_create_domUs(struct dt_device_node *node,
>  #endif
>      }
>  
> -    /* Trap accesses to unmapped areas. */
> +    /* Trap unmapped accesses by default. */
>      d_cfg->flags |= XEN_DOMCTL_CDF_trap_unmapped_accesses;
> +    if ( dt_property_read_u32(node, "trap-unmapped-accesses", &val) )
> +    {
> +        if ( val > 1 )
> +            panic("trap-unmapped-accesses: supported values are 0 or 1");
> +        if ( !val )
> +            d_cfg->flags &= ~XEN_DOMCTL_CDF_trap_unmapped_accesses;
> +    }
>  }
>  
>  int __init init_intc_phandle(struct kernel_info *kinfo, const char *name,
> -- 
> 2.43.0
> 


From xen-devel-bounces@lists.xenproject.org Mon Jun 02 22:42:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 22:42:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003851.1383464 (Exim 4.92)
	(envelope-from )
	id 1uMDrh-0002iF-Tj; Mon, 02 Jun 2025 22:42:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003851.1383464; Mon, 02 Jun 2025 22:42:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMDrh-0002i8-R8; Mon, 02 Jun 2025 22:42:45 +0000
Received: by outflank-mailman (input) for mailman id 1003851;
 Mon, 02 Jun 2025 22:42: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 1uMDrg-0002i2-HH
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 22:42:44 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e44a6792-4002-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 00:42:42 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 8719143849;
 Mon,  2 Jun 2025 22:42:40 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 036B3C4CEEB;
 Mon,  2 Jun 2025 22:42: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: e44a6792-4002-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748904160;
	bh=B4MssjLYag38aM6Ga7iI+dTTlyBcVAhFL/tHSZZHnrE=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=u0U08PcgJODV1ATxoPQ1Wgwx/q8vHKVr1B0pW4scyveF5ZueiiTwm77Q7QiwRP+Mx
	 tEqrCW3BjmwfcqG4ATHgH1BGT7h1awRm/9vbB2mSHijbbRstQ53RQfkQauMZdBl3G5
	 0/2Y4NIYe6yyTMy/tNbNtdTBPd8TGDU16z5KPnvYl2mrQ30JFdqLISQj9U5qVMq0ib
	 N5J5V80N6bNRLKqqKBJgaS4FagIOKKZ0Vnv0/CA2x6/6YDFxvNKNyMVchwIRxizPKa
	 7tTYqSa0JUcW7Libm0Ba4zlYvPsM3LZO1EzP87LyieUYGqgKFXFt5p5qquEt5RgJ1j
	 MQuoNBrcb70/g==
Date: Mon, 2 Jun 2025 15:42:38 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: "Edgar E. Iglesias" 
cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org, julien@xen.org, 
    bertrand.marquis@arm.com, michal.orzel@amd.com, Volodymyr_Babchuk@epam.com, 
    andrew.cooper3@citrix.com, edgar.iglesias@amd.com, 
    Anthony PERARD , 
    Juergen Gross 
Subject: Re: [PATCH v3 3/5] tools/arm: Add the trap_unmapped_accesses xl
 config option
In-Reply-To: <20250530134559.1434255-4-edgar.iglesias@gmail.com>
Message-ID: 
References: <20250530134559.1434255-1-edgar.iglesias@gmail.com> <20250530134559.1434255-4-edgar.iglesias@gmail.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 30 May 2025, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias" 
> 
> Signed-off-by: Edgar E. Iglesias 

Reviewed-by: Stefano Stabellini 


> ---
>  docs/man/xl.cfg.5.pod.in         | 9 +++++++++
>  tools/libs/light/libxl_arm.c     | 6 +++---
>  tools/libs/light/libxl_create.c  | 3 +++
>  tools/libs/light/libxl_types.idl | 1 +
>  tools/libs/light/libxl_x86.c     | 6 ++++++
>  tools/xl/xl_parse.c              | 3 +++
>  6 files changed, 25 insertions(+), 3 deletions(-)
> 
> diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> index 7339c44efd..6c303e8efa 100644
> --- a/docs/man/xl.cfg.5.pod.in
> +++ b/docs/man/xl.cfg.5.pod.in
> @@ -3089,6 +3089,15 @@ will be used for the domain. Otherwise, the value specified by the `nr_spis`
>  parameter will be used. The number of SPIs should match the highest interrupt
>  ID that will be assigned to the domain.
>  
> +=item B
> +
> +An Optional boolean parameter that configures handling of accesses to unmapped
> +address ranges. If enabled, guest accesses will trap. If disabled, guest
> +accesses will read all bits as ones, e.g 0xFFFFFFFF for a 32bit access and
> +writes will be ignored.
> +
> +This option is only implemented for ARM where the default is enabled.
> +
>  =back
>  
>  =head3 x86
> diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
> index 9530996e72..afc62a5299 100644
> --- a/tools/libs/light/libxl_arm.c
> +++ b/tools/libs/light/libxl_arm.c
> @@ -233,9 +233,6 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
>          config->arch.sve_vl = d_config->b_info.arch_arm.sve_vl / 128U;
>      }
>  
> -    /* Trap accesses to unmapped areas. */
> -    config->flags |= XEN_DOMCTL_CDF_trap_unmapped_accesses;
> -
>      return 0;
>  }
>  
> @@ -1714,6 +1711,9 @@ int libxl__arch_domain_build_info_setdefault(libxl__gc *gc,
>      /* ACPI is disabled by default */
>      libxl_defbool_setdefault(&b_info->acpi, false);
>  
> +    /* Trapping of unmapped accesses enabled by default.  */
> +    libxl_defbool_setdefault(&b_info->trap_unmapped_accesses, true);
> +
>      /* Sanitise SVE parameter */
>      if (b_info->arch_arm.sve_vl) {
>          unsigned int max_sve_vl =
> diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_create.c
> index e03599ea99..38770eea5b 100644
> --- a/tools/libs/light/libxl_create.c
> +++ b/tools/libs/light/libxl_create.c
> @@ -667,6 +667,9 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
>          if (libxl_defbool_val(b_info->vpmu))
>              create.flags |= XEN_DOMCTL_CDF_vpmu;
>  
> +        if (libxl_defbool_val(b_info->trap_unmapped_accesses))
> +            create.flags |= XEN_DOMCTL_CDF_trap_unmapped_accesses;
> +
>          assert(info->passthrough != LIBXL_PASSTHROUGH_DEFAULT);
>          LOG(DETAIL, "passthrough: %s",
>              libxl_passthrough_to_string(info->passthrough));
> diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl
> index 9bb2969931..e33785c661 100644
> --- a/tools/libs/light/libxl_types.idl
> +++ b/tools/libs/light/libxl_types.idl
> @@ -736,6 +736,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
>      ("vmtrace_buf_kb", integer),
>  
>      ("vpmu", libxl_defbool),
> +    ("trap_unmapped_accesses", libxl_defbool),
>  
>      ], dir=DIR_IN,
>         copy_deprecated_fn="libxl__domain_build_info_copy_deprecated",
> diff --git a/tools/libs/light/libxl_x86.c b/tools/libs/light/libxl_x86.c
> index 0b1c2d3a96..a9d470c9f6 100644
> --- a/tools/libs/light/libxl_x86.c
> +++ b/tools/libs/light/libxl_x86.c
> @@ -26,6 +26,11 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
>      if (libxl_defbool_val(d_config->b_info.arch_x86.msr_relaxed))
>          config->arch.misc_flags |= XEN_X86_MSR_RELAXED;
>  
> +    if (libxl_defbool_val(d_config->b_info.trap_unmapped_accesses)) {
> +            LOG(ERROR, "trap_unmapped_accesses is not supported on x86\n");
> +            return ERROR_FAIL;
> +    }
> +
>      return 0;
>  }
>  
> @@ -813,6 +818,7 @@ int libxl__arch_domain_build_info_setdefault(libxl__gc *gc,
>  {
>      libxl_defbool_setdefault(&b_info->acpi, true);
>      libxl_defbool_setdefault(&b_info->arch_x86.msr_relaxed, false);
> +    libxl_defbool_setdefault(&b_info->trap_unmapped_accesses, false);
>  
>      /*
>       * The config parameter "altp2m" replaces the parameter "altp2mhvm".
> diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
> index 089a88935a..40da75ef74 100644
> --- a/tools/xl/xl_parse.c
> +++ b/tools/xl/xl_parse.c
> @@ -2975,6 +2975,9 @@ skip_usbdev:
>      if (!xlu_cfg_get_long (config, "nr_spis", &l, 0))
>          b_info->arch_arm.nr_spis = l;
>  
> +    xlu_cfg_get_defbool(config, "trap_unmapped_accesses",
> +                        &b_info->trap_unmapped_accesses, 0);
> +
>      parse_vkb_list(config, d_config);
>  
>      d_config->virtios = NULL;
> -- 
> 2.43.0
> 


From xen-devel-bounces@lists.xenproject.org Mon Jun 02 22:47:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 22:47:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003862.1383474 (Exim 4.92)
	(envelope-from )
	id 1uMDwP-0003LK-H0; Mon, 02 Jun 2025 22:47:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003862.1383474; Mon, 02 Jun 2025 22:47: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 1uMDwP-0003LD-EI; Mon, 02 Jun 2025 22:47:37 +0000
Received: by outflank-mailman (input) for mailman id 1003862;
 Mon, 02 Jun 2025 22:47:36 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uMDwO-0003L7-Dh
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 22:47:36 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uMDwN-00GKke-0O;
 Mon, 02 Jun 2025 22:47:35 +0000
Received: from [2a02:8012:3a1:0:7807:532b:1d1d:b850]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uMDwN-00Dau7-1E;
 Mon, 02 Jun 2025 22:47: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" 
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=WpmjVpFGmSIUU9UyeyfbfMjpD78oyCRvKA8bsOznw80=; b=5xsW7h9yStRnvgrdIgpBohKqZy
	2BweO6OHJf+lFkOUh3qPOQw8nVgQzjkRW272VygWVBzScislqWUWs2jz06yCO28Tc7nvBEic+drvH
	CCufWrR35IC1gaX4RCaTsGO8+SdH22B21PUXG4TzP6TSQUi+aisBfN8hMfVn2H+71Fz0=;
Message-ID: 
Date: Mon, 2 Jun 2025 23:47:32 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/5] xen/arm: dom0less: Add trap-unmapped-accesses
Content-Language: en-GB
To: Stefano Stabellini ,
 "Edgar E. Iglesias" 
Cc: xen-devel@lists.xenproject.org, bertrand.marquis@arm.com,
 michal.orzel@amd.com, Volodymyr_Babchuk@epam.com, andrew.cooper3@citrix.com,
 edgar.iglesias@amd.com
References: <20250530134559.1434255-1-edgar.iglesias@gmail.com>
 <20250530134559.1434255-3-edgar.iglesias@gmail.com>
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

On 02/06/2025 23:36, Stefano Stabellini wrote:
> On Fri, 30 May 2025, Edgar E. Iglesias wrote:
>> From: "Edgar E. Iglesias" 
>>
>> Add the trap-unmapped-accesses per-domain fdt property.
>>
>> Signed-off-by: Edgar E. Iglesias 
>> ---
>>   docs/misc/arm/device-tree/booting.txt | 10 ++++++++++
>>   xen/arch/arm/dom0less-build.c         |  9 ++++++++-
>>   2 files changed, 18 insertions(+), 1 deletion(-)
>>
>> diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
>> index 59fa96a82e..9add6440de 100644
>> --- a/docs/misc/arm/device-tree/booting.txt
>> +++ b/docs/misc/arm/device-tree/booting.txt
>> @@ -225,6 +225,16 @@ with the following properties:
>>       option is provided with a non zero value, but the platform doesn't support
>>       SVE.
>>   
>> +- trap-unmapped-accesses
>> +
>> +    Optional. An integer that configures handling of accesses to unmapped
>> +    address ranges.
>> +    If set to 0, guest accesses will read all bits as ones, e.g 0xFFFFFFFF
>> +    for a 32bit access and writes will be ignored.
>> +    If set to 1, guest accesses will trap.
>> +
>> +    This option is only implemented for ARM where the default is 1.
> 
> Please expand it to: "This option is only implemented for ARM where the
> default is 1 when trap-unmapped-accesses is absent."

I am confused. The document is part of "docs/misc/arm" and some options 
like "sve" are Arm specific. We don't mention this is Arm only because 
the documention is Arm specific.

I know that RISC-V is starting to share the bindings. So really (part 
of) the documentation should be moved to common. Until then, I think it 
is misleading to add "is only implemented for ARM".

BTW, the spelling for should be "Arm" ;).

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Mon Jun 02 22:49:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 22:49:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003868.1383484 (Exim 4.92)
	(envelope-from )
	id 1uMDyF-0003rU-S4; Mon, 02 Jun 2025 22:49:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003868.1383484; Mon, 02 Jun 2025 22:49: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 1uMDyF-0003rN-OR; Mon, 02 Jun 2025 22:49:31 +0000
Received: by outflank-mailman (input) for mailman id 1003868;
 Mon, 02 Jun 2025 22: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 1uMDyE-0003rF-DV
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 22:49:30 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org
 [2600:3c04:e001:324:0:1991:8:25])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d6409f79-4003-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 00:49:28 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 7B13E614BA;
 Mon,  2 Jun 2025 22:49:26 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5156EC4CEEB;
 Mon,  2 Jun 2025 22:49: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: d6409f79-4003-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748904566;
	bh=ansHrRPspkZxJyjqUC6llvz8ffhfoqC8ss5bw8iix8k=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=NO+0vbAUaMO6vKs8AV4BMQcXiHbXXBumgrQIG8dBJnzXklI4qXSBq7m7w8S2YaU0/
	 b5z3vKXozBxq9Y+ITlOd5poWTDUwJVloU+7ODwL9FtAuMI5PnPJWPnNa35e/4JXaeN
	 z1lQshbCtLHnymD8iyCdgPlrdsWcHtGQr/bLb4ngHrYQ8Mobj9K2vDy29XBLkg0hOe
	 gN1qHiS4R5aw0YBsQZ6yOkpKXgLK+8uU8GK/DBOqAuBhJRnXc2yAP6SlTcGxi0Jjv6
	 qZZlidrdljD+kEugjN+uroc8vvrYI2iUPZuu8YL+ZMSBG34WMmznkpsNdrcQFrvCed
	 S7SOITGPIySKA==
Date: Mon, 2 Jun 2025 15:49:24 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Andrew Cooper 
cc: Xen-devel , 
    Anthony PERARD , 
    Stefano Stabellini , 
    Michal Orzel , 
    =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
Subject: Re: [PATCH 1/2] CI: Use bash arrays to simplfy dom0 rootfs
 construction
In-Reply-To: <20250602174618.2641439-2-andrew.cooper3@citrix.com>
Message-ID: 
References: <20250602174618.2641439-1-andrew.cooper3@citrix.com> <20250602174618.2641439-2-andrew.cooper3@citrix.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-2053582876-1748904566=:1147082"

  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-2053582876-1748904566=:1147082
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Mon, 2 Jun 2025, Andrew Cooper wrote:
> For Qubes, this requires switching from sh to bash.
> 
> This reduces the number of times the target filename needs to be written to 1.
> 
> Expand the comment to explain the concatination constraints.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Stefano Stabellini 


> ---
> CC: Anthony PERARD 
> CC: Stefano Stabellini 
> CC: Michal Orzel 
> CC: Marek Marczykowski-Górecki 
> 
> v2:
>  * Use dom0_rootfs_extra_{un,}comp arrays
> ---
>  automation/scripts/qubes-x86-64.sh            | 18 ++++++++++++-----
>  .../scripts/xilinx-smoke-dom0-x86_64.sh       | 20 ++++++++++++-------
>  2 files changed, 26 insertions(+), 12 deletions(-)
> 
> diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qubes-x86-64.sh
> index 8e86940c6eff..5ec6eff6c469 100755
> --- a/automation/scripts/qubes-x86-64.sh
> +++ b/automation/scripts/qubes-x86-64.sh
> @@ -1,4 +1,4 @@
> -#!/bin/sh
> +#!/bin/bash
>  
>  set -ex -o pipefail
>  
> @@ -22,6 +22,8 @@ domU_type="pvh"
>  domU_vif="'bridge=xenbr0',"
>  domU_extra_config=
>  retrieve_xml=
> +dom0_rootfs_extra_comp=()
> +dom0_rootfs_extra_uncomp=()
>  
>  case "${test_variant}" in
>      ### test: smoke test & smoke test PVH & smoke test HVM & smoke test PVSHIM
> @@ -187,10 +189,16 @@ Kernel \r on an \m (\l)
>      rm -rf rootfs
>  fi
>  
> -# Dom0 rootfs
> -cp binaries/ucode.cpio binaries/dom0-rootfs.cpio.gz
> -cat binaries/rootfs.cpio.gz >> binaries/dom0-rootfs.cpio.gz
> -cat binaries/xen-tools.cpio.gz >> binaries/dom0-rootfs.cpio.gz
> +# Dom0 rootfs.  The order or concatination is important; ucode wants to come
> +# first, and all uncompressed must be ahead of compressed.
> +dom0_rootfs_parts=(
> +    binaries/ucode.cpio
> +    "${dom0_rootfs_extra_uncomp[@]}"
> +    binaries/rootfs.cpio.gz
> +    binaries/xen-tools.cpio.gz
> +    "${dom0_rootfs_extra_comp[@]}"
> +)
> +cat "${dom0_rootfs_parts[@]}" > binaries/dom0-rootfs.cpio.gz
>  
>  # test-local configuration
>  mkdir -p rootfs
> diff --git a/automation/scripts/xilinx-smoke-dom0-x86_64.sh b/automation/scripts/xilinx-smoke-dom0-x86_64.sh
> index 8f02fa73bd06..45121f39400a 100755
> --- a/automation/scripts/xilinx-smoke-dom0-x86_64.sh
> +++ b/automation/scripts/xilinx-smoke-dom0-x86_64.sh
> @@ -28,6 +28,8 @@ extra = "root=/dev/ram0 console=hvc0"
>  memory = 512
>  '
>  DOMU_CFG_EXTRA=""
> +dom0_rootfs_extra_comp=()
> +dom0_rootfs_extra_uncomp=()
>  
>  # Select test variant.
>  if [ "${TEST}" = "ping" ]; then
> @@ -71,6 +73,7 @@ do
>    sleep 1
>  done | argo-exec -p 28333 -d 0 -- /bin/echo
>  "
> +    dom0_rootfs_extra_comp+=(binaries/argo.cpio.gz)
>      DOM0_CMD="
>  insmod /lib/modules/\$(uname -r)/updates/xen-argo.ko
>  xl -vvv create /etc/xen/domU.cfg
> @@ -103,13 +106,16 @@ find . | cpio -H newc -o | gzip >> ../binaries/domU-rootfs.cpio.gz
>  cd ..
>  rm -rf rootfs
>  
> -# Dom0 rootfs
> -cp binaries/ucode.cpio binaries/dom0-rootfs.cpio.gz
> -cat binaries/rootfs.cpio.gz >> binaries/dom0-rootfs.cpio.gz
> -cat binaries/xen-tools.cpio.gz >> binaries/dom0-rootfs.cpio.gz
> -if [[ "${TEST}" == argo ]]; then
> -    cat binaries/argo.cpio.gz >> binaries/dom0-rootfs.cpio.gz
> -fi
> +# Dom0 rootfs.  The order or concatination is important; ucode wants to come
> +# first, and all uncompressed must be ahead of compressed.
> +dom0_rootfs_parts=(
> +    binaries/ucode.cpio
> +    "${dom0_rootfs_extra_uncomp[@]}"
> +    binaries/rootfs.cpio.gz
> +    binaries/xen-tools.cpio.gz
> +    "${dom0_rootfs_extra_comp[@]}"
> +)
> +cat "${dom0_rootfs_parts[@]}" > binaries/dom0-rootfs.cpio.gz
>  
>  # test-local configuration
>  mkdir -p rootfs
> -- 
> 2.39.5
> 
--8323329-2053582876-1748904566=:1147082--


From xen-devel-bounces@lists.xenproject.org Mon Jun 02 22:53:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 22:53:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003877.1383493 (Exim 4.92)
	(envelope-from )
	id 1uME27-0005gV-AC; Mon, 02 Jun 2025 22:53:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003877.1383493; Mon, 02 Jun 2025 22: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 1uME27-0005gO-6u; Mon, 02 Jun 2025 22:53:31 +0000
Received: by outflank-mailman (input) for mailman id 1003877;
 Mon, 02 Jun 2025 22: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 1uME25-0005gI-GG
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 22:53:29 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 65359303-4004-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 00:53:28 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 594CA442B1;
 Mon,  2 Jun 2025 22:53:26 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5AA88C4CEEB;
 Mon,  2 Jun 2025 22:53: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: 65359303-4004-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748904806;
	bh=iFvTd3IYXCEQsHqPg5lcyVvNBcFSx2lQ/o1KUjtbwqY=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=IXG3i98AbPxmtH0IiFOMT3KCizLiwMDHZISzcD22J0bYMp2PKc4Br58A9zF5X9FHC
	 tfCcG8CLMlOmC0jiLFeaJbKFkK0gCeiE25BfZ8Lw+NXKiiTseb8pbkswCx3EhpAAhD
	 nqj7UWdJHvEpJ/9drelnbEeTtbstD1K6sQkdH1bwgbHcdjTqWmiEToRICg0eQlO+Cj
	 9QpG24bSvC0BRfGOFK8lpDIPbvgQQlNpd00Qt3J2S8PM4yPEW4NTGM4ic39PN748BY
	 54ML3ZHqG6aKMgZ6h0/mq+Piva6MJpAZnKygvgV/ADX5zafu4CSjIV7IbOfm/E2pI3
	 W1+IZIpB0dd5w==
Date: Mon, 2 Jun 2025 15:53:24 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Andrew Cooper 
cc: Xen-devel , 
    Anthony PERARD , 
    Stefano Stabellini , 
    Michal Orzel , 
    =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
Subject: Re: [PATCH 2/2] CI: Adjust how domU is packaged in dom0
In-Reply-To: <20250602174618.2641439-3-andrew.cooper3@citrix.com>
Message-ID: 
References: <20250602174618.2641439-1-andrew.cooper3@citrix.com> <20250602174618.2641439-3-andrew.cooper3@citrix.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-827388975-1748904806=:1147082"

  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-827388975-1748904806=:1147082
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Mon, 2 Jun 2025, Andrew Cooper wrote:
> Package domU for dom0 and insert into the uncompressed part of dom0's rootfs,
> rather than recompressing it as part of the overlay.
> 
> For Qubes, this avoids putting the domU kernel in dom0's rootfs for tests
> which aren't going to boot a guest.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Stefano Stabellini 


> ---
> CC: Anthony PERARD 
> CC: Stefano Stabellini 
> CC: Michal Orzel 
> CC: Marek Marczykowski-Górecki 
> 
> v2:
>  * Rebase over dom0_rootfs_extra_{un,}comp changes
>  * Move back into boot.  There seem to be objections to having it in root.
> ---
>  automation/scripts/qubes-x86-64.sh             | 17 ++++++++++++-----
>  automation/scripts/xilinx-smoke-dom0-x86_64.sh | 14 +++++++++++---
>  2 files changed, 23 insertions(+), 8 deletions(-)
> 
> diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qubes-x86-64.sh
> index 5ec6eff6c469..d9ecc569c956 100755
> --- a/automation/scripts/qubes-x86-64.sh
> +++ b/automation/scripts/qubes-x86-64.sh
> @@ -156,7 +156,7 @@ esac
>  domU_config="
>  type = '${domU_type}'
>  name = 'domU'
> -kernel = '/boot/vmlinuz'
> +kernel = '/boot/vmlinuz-domU'
>  ramdisk = '/boot/initrd-domU'
>  cmdline = 'root=/dev/ram0 console=hvc0'
>  memory = 512
> @@ -187,6 +187,17 @@ Kernel \r on an \m (\l)
>      find . | cpio -H newc -o | gzip >> ../binaries/domU-rootfs.cpio.gz
>      cd ..
>      rm -rf rootfs
> +
> +    # Package domU kernel+rootfs in /boot for dom0 (uncompressed)
> +    mkdir -p rootfs/boot
> +    cd rootfs
> +    cp ../binaries/bzImage boot/vmlinuz-domU
> +    cp ../binaries/domU-rootfs.cpio.gz boot/initrd-domU
> +    find . | cpio -H newc -o > ../binaries/domU-in-dom0.cpio
> +    cd ..
> +    rm -rf rootfs
> +
> +    dom0_rootfs_extra_uncomp+=(binaries/domU-in-dom0.cpio)
>  fi
>  
>  # Dom0 rootfs.  The order or concatination is important; ucode wants to come
> @@ -241,10 +252,6 @@ mkdir -p etc/default
>  echo "XENCONSOLED_TRACE=all" >> etc/default/xencommons
>  echo "QEMU_XEN=/bin/false" >> etc/default/xencommons
>  mkdir -p var/log/xen/console
> -cp ../binaries/bzImage boot/vmlinuz
> -if [ -n "$domU_check" ]; then
> -    cp ../binaries/domU-rootfs.cpio.gz boot/initrd-domU
> -fi
>  find . | cpio -H newc -o | gzip >> ../binaries/dom0-rootfs.cpio.gz
>  cd ..
>  
> diff --git a/automation/scripts/xilinx-smoke-dom0-x86_64.sh b/automation/scripts/xilinx-smoke-dom0-x86_64.sh
> index 45121f39400a..8981aee5d4f2 100755
> --- a/automation/scripts/xilinx-smoke-dom0-x86_64.sh
> +++ b/automation/scripts/xilinx-smoke-dom0-x86_64.sh
> @@ -22,7 +22,7 @@ DOMU_CMD=""
>  DOMU_CFG='
>  type = "pvh"
>  name = "domU"
> -kernel = "/boot/vmlinuz"
> +kernel = "/boot/vmlinuz-domU"
>  ramdisk = "/boot/initrd-domU"
>  extra = "root=/dev/ram0 console=hvc0"
>  memory = 512
> @@ -106,10 +106,20 @@ find . | cpio -H newc -o | gzip >> ../binaries/domU-rootfs.cpio.gz
>  cd ..
>  rm -rf rootfs
>  
> +# Package domU kernel+rootfs in /boot for dom0 (uncompressed)
> +mkdir -p rootfs/boot
> +cd rootfs
> +cp ../binaries/bzImage boot/vmlinuz-domU
> +cp ../binaries/domU-rootfs.cpio.gz boot/initrd-domU
> +find . | cpio -H newc -o > ../binaries/domU-in-dom0.cpio
> +cd ..
> +rm -rf rootfs
> +
>  # Dom0 rootfs.  The order or concatination is important; ucode wants to come
>  # first, and all uncompressed must be ahead of compressed.
>  dom0_rootfs_parts=(
>      binaries/ucode.cpio
> +    binaries/domU-in-dom0.cpio
>      "${dom0_rootfs_extra_uncomp[@]}"
>      binaries/rootfs.cpio.gz
>      binaries/xen-tools.cpio.gz
> @@ -131,8 +141,6 @@ echo "${DOMU_CFG}${DOMU_CFG_EXTRA}" > etc/xen/domU.cfg
>  echo "XENCONSOLED_TRACE=all" >> etc/default/xencommons
>  echo "QEMU_XEN=/bin/false" >> etc/default/xencommons
>  mkdir -p var/log/xen/console
> -cp ../binaries/bzImage boot/vmlinuz
> -cp ../binaries/domU-rootfs.cpio.gz boot/initrd-domU
>  find . | cpio -H newc -o | gzip >> ../binaries/dom0-rootfs.cpio.gz
>  cd ..
>  
> -- 
> 2.39.5
> 
--8323329-827388975-1748904806=:1147082--


From xen-devel-bounces@lists.xenproject.org Mon Jun 02 22:57:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jun 2025 22:57:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003884.1383504 (Exim 4.92)
	(envelope-from )
	id 1uME62-0006FS-OJ; Mon, 02 Jun 2025 22:57:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003884.1383504; Mon, 02 Jun 2025 22:57:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uME62-0006FL-LY; Mon, 02 Jun 2025 22:57:34 +0000
Received: by outflank-mailman (input) for mailman id 1003884;
 Mon, 02 Jun 2025 22:57: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 1uME60-0006FF-Sg
 for xen-devel@lists.xenproject.org; Mon, 02 Jun 2025 22:57:32 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f67bf1f4-4004-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 00:57:31 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 84EDE4A6E2;
 Mon,  2 Jun 2025 22:57:30 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4CA49C4CEEB;
 Mon,  2 Jun 2025 22:57:29 +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: f67bf1f4-4004-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748905050;
	bh=7pIyvHjDLO6WWHS14Re+izDl0pZBBVpDlviSo3FY9KM=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=mAhbgm33ZNRD99nSAg6WXqawWsQvulQydnqWG3C0cvI7dMgI1f+ETcf3NiD4LVaP5
	 4S8M3kB2Iq0F7r7sO5PBqWXEowIpvgpeBVB52NPZHm6qqb2wKo+8blGbMzO6KwIpcx
	 sjXk1tXR+7O3yy/3U7uiT7gTyxekEPtinPznRWwV35uC9TOChmsfGgHsKpg5X4Lu2v
	 +JKGgCJfyMk9/J5YWlxwRf0ETZzqZGubO41he5NSSpc4LdY5jI1aefxhC6Yusnp3oQ
	 KcYNrQZxlPgax3D9JZtXLYEHF4oOtZ/TeF0855XXclDiqhw8DE6sTpFOWogY+DzstR
	 iYoliSOyPISVg==
Date: Mon, 2 Jun 2025 15:57:28 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Julien Grall 
cc: Stefano Stabellini , 
    "Edgar E. Iglesias" , 
    xen-devel@lists.xenproject.org, bertrand.marquis@arm.com, 
    michal.orzel@amd.com, Volodymyr_Babchuk@epam.com, 
    andrew.cooper3@citrix.com, edgar.iglesias@amd.com
Subject: Re: [PATCH v3 2/5] xen/arm: dom0less: Add trap-unmapped-accesses
In-Reply-To: 
Message-ID: 
References: <20250530134559.1434255-1-edgar.iglesias@gmail.com> <20250530134559.1434255-3-edgar.iglesias@gmail.com>  
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 2 Jun 2025, Julien Grall wrote:
> Hi,
> 
> On 02/06/2025 23:36, Stefano Stabellini wrote:
> > On Fri, 30 May 2025, Edgar E. Iglesias wrote:
> > > From: "Edgar E. Iglesias" 
> > > 
> > > Add the trap-unmapped-accesses per-domain fdt property.
> > > 
> > > Signed-off-by: Edgar E. Iglesias 
> > > ---
> > >   docs/misc/arm/device-tree/booting.txt | 10 ++++++++++
> > >   xen/arch/arm/dom0less-build.c         |  9 ++++++++-
> > >   2 files changed, 18 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/docs/misc/arm/device-tree/booting.txt
> > > b/docs/misc/arm/device-tree/booting.txt
> > > index 59fa96a82e..9add6440de 100644
> > > --- a/docs/misc/arm/device-tree/booting.txt
> > > +++ b/docs/misc/arm/device-tree/booting.txt
> > > @@ -225,6 +225,16 @@ with the following properties:
> > >       option is provided with a non zero value, but the platform doesn't
> > > support
> > >       SVE.
> > >   +- trap-unmapped-accesses
> > > +
> > > +    Optional. An integer that configures handling of accesses to unmapped
> > > +    address ranges.
> > > +    If set to 0, guest accesses will read all bits as ones, e.g
> > > 0xFFFFFFFF
> > > +    for a 32bit access and writes will be ignored.
> > > +    If set to 1, guest accesses will trap.
> > > +
> > > +    This option is only implemented for ARM where the default is 1.
> > 
> > Please expand it to: "This option is only implemented for ARM where the
> > default is 1 when trap-unmapped-accesses is absent."
> 
> I am confused. The document is part of "docs/misc/arm" and some options like
> "sve" are Arm specific. We don't mention this is Arm only because the
> documention is Arm specific.
> 
> I know that RISC-V is starting to share the bindings. So really (part of) the
> documentation should be moved to common. Until then, I think it is misleading
> to add "is only implemented for ARM".

Yes you are right. Maybe Oleksii or Alejandro can fix this, moving this
file to common.

For this smaller patch series, I would remove the "is only implemented
for ARM".


> BTW, the spelling for should be "Arm" ;).

:-)


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 00:36:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 00:36:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003894.1383513 (Exim 4.92)
	(envelope-from )
	id 1uMFdq-0002zR-Bn; Tue, 03 Jun 2025 00:36:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003894.1383513; Tue, 03 Jun 2025 00:36: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 1uMFdq-0002zK-8E; Tue, 03 Jun 2025 00:36:34 +0000
Received: by outflank-mailman (input) for mailman id 1003894;
 Tue, 03 Jun 2025 00:36: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 1uMFdo-0002zE-8h
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 00:36:32 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org
 [2600:3c0a:e001:78e:0:1991:8:25])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c9be94c6-4012-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 02:36:30 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id E7420438E8;
 Tue,  3 Jun 2025 00:36:27 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 398B9C4CEEB;
 Tue,  3 Jun 2025 00:36: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: c9be94c6-4012-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748910987;
	bh=H+2Lbhn7OzmGelL50bcvoKFKdnGScwpv1/mggSj/HT4=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=bvOjIjZ/Mo/irhsORdgRaK+5dAw8odW0izcCetoKnMVL97XF2OdJi8r65JRTTq/u6
	 9p7gMJHOXK5QSVk2jltJa6/K8aH+Y8xQmixSvIZC+vq6bgt4L5aM3iuaNb8MzycIjJ
	 7pazT2xQIz4Y+/91RJD3rAqUpsZnb5N6CDmKHoAVjVyNCBUW01GTaFJFkTxS4Dgwfn
	 w5r3UquHjNCAH7FZNimrGkdWJRGWDol9iCnkXiPp9fhYK8SHRpuiMzUF0WfvPPhvYC
	 Qx5x92k9vyvrAQSYLU9QDgSHjMBrslqH9yPFlMDNnQqpiknl6W6NQrFYP/wgn5YjTC
	 u48y58TQbL3Ow==
Date: Mon, 2 Jun 2025 17:36:25 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: dmkhn@proton.me
cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, 
    anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, 
    michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, 
    dmukhin@ford.com
Subject: Re: [PATCH v5 3/4] xen/console: remove max_init_domid dependency
In-Reply-To: <20250530231841.73386-4-dmukhin@ford.com>
Message-ID: 
References: <20250530231841.73386-1-dmukhin@ford.com> <20250530231841.73386-4-dmukhin@ford.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 30 May 2025, dmkhn@proton.me wrote:
> From: Denis Mukhin 
> 
> The physical console input rotation depends on max_init_domid symbol, which is
> managed differently across architectures.
> 
> Instead of trying to manage max_init_domid in the arch-common code the console
> input rotation code can be reworked by removing dependency on max_init_domid
> entirely.
> 
> To do that, introduce domid_find_with_input_allowed() in arch-independent
> location to find the ID of the next possible console owner domain. The IDs
> are rotated across non-system domain IDs and DOMID_XEN.
> 
> Also, introduce helper console_set_domid() for updating identifier of the
> current console input owner (points to Xen or domain).
> 
> Use domid_find_with_input_allowed() and console_set_domid() in
> console_switch_input().
> 
> Remove uses of max_init_domid in the code.
> 
> Signed-off-by: Denis Mukhin 
> ---
> Changes since v4:
> - fixed domid_find_with_input_allowed()
> - kept switching to get_initial_domain_id() in console_endboot()
> ---
>  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/device-tree/dom0less-build.c |  2 -
>  xen/common/domain.c                     | 33 +++++++++
>  xen/drivers/char/console.c              | 90 +++++++++----------------
>  xen/include/xen/domain.h                |  1 +
>  9 files changed, 65 insertions(+), 71 deletions(-)
> 
> diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
> index 6cf272c160..f107e8eebb 100644
> --- a/xen/arch/arm/include/asm/setup.h
> +++ b/xen/arch/arm/include/asm/setup.h
> @@ -25,8 +25,6 @@ struct map_range_data
>      struct rangeset *irq_ranges;
>  };
>  
> -extern domid_t max_init_domid;
> -
>  void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
>  
>  size_t estimate_efi_size(unsigned int mem_nr_banks);
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 734e23da44..0a18d479f9 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -61,8 +61,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 e4f64879b6..956fa6985a 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 c9d69cdf51..d1fc64b673 100644
> --- a/xen/arch/riscv/include/asm/setup.h
> +++ b/xen/arch/riscv/include/asm/setup.h
> @@ -5,8 +5,6 @@
>  
>  #include 
>  
> -#define max_init_domid (0)
> -
>  void setup_mm(void);
>  
>  void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
> diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/asm/setup.h
> index ac34c69855..b67de8577f 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/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
> index 9a6015f4ce..703f20faed 100644
> --- a/xen/common/device-tree/dom0less-build.c
> +++ b/xen/common/device-tree/dom0less-build.c
> @@ -977,8 +977,6 @@ void __init create_domUs(void)
>          domid = domid_alloc(DOMID_INVALID);
>          if ( domid == DOMID_INVALID )
>              panic("Error allocating ID for domain %s\n", dt_node_name(node));
> -        if ( max_init_domid < domid )
> -            max_init_domid = domid;
>  
>          d = domain_create(domid, &d_cfg, flags);
>          if ( IS_ERR(d) )
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index d75ece1b61..4a54bc27a3 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -2461,6 +2461,39 @@ void domid_free(domid_t domid)
>      spin_unlock(&domid_lock);
>  }
>  
> +/*
> + * Find the ID of the next possible console owner domain.
> + *
> + * @return Domain ID: DOMID_XEN or non-system domain IDs within
> + * the range of [0..DOMID_FIRST_RESERVED-1].
> + */
> +domid_t domid_find_with_input_allowed(domid_t hint)
> +{
> +    domid_t domid = DOMID_XEN;
> +
> +    if ( hint < DOMID_FIRST_RESERVED )
> +    {
> +        struct domain *d;
> +
> +        rcu_read_lock(&domlist_read_lock);
> +
> +        for ( d = domid_to_domain(hint);
> +              d && get_domain(d) && d->domain_id < DOMID_FIRST_RESERVED;

The get_domain(d) worries me because it is increasing the domain's
refcnt but I don't see a corresponding call to put_domain to decrease
it.

If I keep rotating between consoles, I could keep increasing refcnt
indefinitely?

I think we either need a corresponding put_domain(d) call when the domain
loses input focus, or we remove the get_domain(d) based on the fact that
we don't need it. I think before this patch we didn't increment refcnt
when a domain has focus but I am not sure it was correct.


> +              d = rcu_dereference(d->next_in_list) )
> +        {
> +            if ( d->console.input_allowed )
> +            {
> +                domid = d->domain_id;
> +                break;
> +            }
> +        }
> +
> +        rcu_read_unlock(&domlist_read_lock);
> +    }
> +
> +    return domid;
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index 9a9836ba91..37289d5558 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -498,26 +498,17 @@ static void cf_check conring_dump_keyhandler(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_rx=0 => input to xen
> - * console_rx=1 => input to dom0 (or the sole shim domain)
> - * console_rx=N => input to dom(N-1)
> - */
> -static unsigned int __read_mostly console_rx = 0;
>  
> -#define max_console_rx (max_init_domid + 1)
> +/* Console owner domain identifier. */
> +static domid_t __read_mostly console_rx = DOMID_XEN;
>  
>  struct domain *console_get_domain(void)
>  {
> -    struct domain *d;
> +    struct domain *d = rcu_lock_domain_by_id(console_rx);
>  
> -    if ( console_rx == 0 )
> -            return NULL;
> -
> -    d = rcu_lock_domain_by_id(console_rx - 1);
>      if ( !d )
>          return NULL;
>  
> @@ -535,43 +526,14 @@ void console_put_domain(struct domain *d)
>          rcu_unlock_domain(d);
>  }
>  
> -static void console_switch_input(void)
> +static void console_set_domid(domid_t domid)
>  {
> -    unsigned int next_rx = console_rx;
> +    if ( domid == DOMID_XEN )
> +        printk("*** Serial input to Xen");
> +    else
> +        printk("*** Serial input to DOM%u", domid);
>  
> -    /*
> -     * 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_rx = 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 )
> -        {
> -            rcu_unlock_domain(d);
> -
> -            if ( !d->console.input_allowed )
> -                continue;
> -
> -            console_rx = next_rx;
> -            printk("*** Serial input to DOM%u", domid);
> -            break;
> -        }
> -    }
> +    console_rx = domid;
>  
>      if ( switch_code )
>          printk(" (type 'CTRL-%c' three times to switch input)",
> @@ -579,12 +541,30 @@ static void console_switch_input(void)
>      printk("\n");
>  }
>  
> +/*
> + * Switch console focus.
> + * Rotates input focus among Xen and domains with console input permission.
> + */
> +static void console_switch_input(void)
> +{
> +    domid_t hint;
> +
> +    if ( console_rx == DOMID_XEN )
> +        hint = get_initial_domain_id();
> +    else
> +        hint = console_rx + 1;
> +
> +    hint = domid_find_with_input_allowed(hint);
> +
> +    console_set_domid(hint);
> +}
> +
>  static void __serial_rx(char c)
>  {
>      struct domain *d;
>      int rc = 0;
>  
> -    if ( console_rx == 0 )
> +    if ( console_rx == DOMID_XEN )
>          return handle_keypress(c, false);
>  
>      d = console_get_domain();
> @@ -1169,14 +1149,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_rx = max_console_rx;
> -
>      register_keyhandler('w', conring_dump_keyhandler,
>                          "synchronously dump console ring buffer (dmesg)", 0);
>      register_irq_keyhandler('+', &do_inc_thresh,
> @@ -1186,8 +1158,8 @@ 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_switch_input();
> +    if ( opt_conswitch[1] != 'x' )
> +        (void)console_set_domid(get_initial_domain_id());
>  }
>  
>  int __init console_has(const char *device)
> diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
> index 8aab05ae93..a88eb34f3f 100644
> --- a/xen/include/xen/domain.h
> +++ b/xen/include/xen/domain.h
> @@ -36,6 +36,7 @@ void getdomaininfo(struct domain *d, struct xen_domctl_getdomaininfo *info);
>  void arch_get_domain_info(const struct domain *d,
>                            struct xen_domctl_getdomaininfo *info);
>  
> +domid_t domid_find_with_input_allowed(domid_t hint);
>  domid_t get_initial_domain_id(void);
>  
>  domid_t domid_alloc(domid_t domid);
> -- 
> 2.34.1
> 
> 


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 00:37:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 00:37:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003902.1383523 (Exim 4.92)
	(envelope-from )
	id 1uMFeM-0003Tk-N4; Tue, 03 Jun 2025 00:37:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003902.1383523; Tue, 03 Jun 2025 00:37:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMFeM-0003Td-KY; Tue, 03 Jun 2025 00:37:06 +0000
Received: by outflank-mailman (input) for mailman id 1003902;
 Tue, 03 Jun 2025 00:37: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 1uMFeL-0002zE-DC
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 00:37:05 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id deadca1f-4012-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 02:37:04 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 88ECB40C03;
 Tue,  3 Jun 2025 00:37:03 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id E1C1BC4CEEB;
 Tue,  3 Jun 2025 00:37:01 +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: deadca1f-4012-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748911023;
	bh=9nNX2P5wnstgiSFoybutTPcfvKINkRlNhtcOUedxy18=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=ewT88G2rLJVufigC8BWhn6YdoNf04+zIR3W/CpLzbKpkjoATVleJ3GdQ6++61AppA
	 XYLRwXUyGgwtQ2nSYAVS3zzSl9EE36i8DcH9JOFq6Fx7r7SeU0w25zWkNeI17/iubF
	 GgJQH4Z06p6j46e9tVN/dNrzsrSHmY04/znKSo8b3p8IQxBCO0ms3Kby/hn5wha8dd
	 cIpNSFOqk9PG48efDvC8V8rNpFGPUgjsyQkO71S1F0rWbKksuHWZGydZdIg+rElDH/
	 JWE64x7jcqQjiqZxAgkDJCJS3/8/NtptyrXi1aAtbQyD9kc3GBTWVaO2ZxU/sTwI15
	 hl9G5BVjJYJOw==
Date: Mon, 2 Jun 2025 17:37:00 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: dmkhn@proton.me
cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, 
    anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, 
    michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, 
    dmukhin@ford.com
Subject: Re: [PATCH v5 2/4] xen/console: introduce console input permission
In-Reply-To: <20250530231841.73386-3-dmukhin@ford.com>
Message-ID: 
References: <20250530231841.73386-1-dmukhin@ford.com> <20250530231841.73386-3-dmukhin@ford.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 30 May 2025, dmkhn@proton.me wrote:
> From: Denis Mukhin 
> 
> Add new flag to domain structure for marking permission to intercept
> the physical console input by the domain.
> 
> Update console input switch logic accordingly.
> 
> No functional change intended.
> 
> Signed-off-by: Denis Mukhin 

Reviewed-by: Stefano Stabellini 


> ---
> Changes since v4:
> - kept input_allowed as a separate flag
> - updated logic for input_allowed in vpl011
> - fixup for console_switch_input()
> ---
>  xen/arch/arm/vpl011.c      |  1 +
>  xen/arch/x86/pv/shim.c     |  2 ++
>  xen/common/domain.c        |  2 ++
>  xen/drivers/char/console.c | 18 +++++++++++++++++-
>  xen/include/xen/sched.h    |  8 +++++++-
>  5 files changed, 29 insertions(+), 2 deletions(-)
> 



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 00:37:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 00:37:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003910.1383533 (Exim 4.92)
	(envelope-from )
	id 1uMFez-000407-Uy; Tue, 03 Jun 2025 00:37:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003910.1383533; Tue, 03 Jun 2025 00: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 1uMFez-000400-S3; Tue, 03 Jun 2025 00:37:45 +0000
Received: by outflank-mailman (input) for mailman id 1003910;
 Tue, 03 Jun 2025 00:37: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 1uMFey-0003L6-E6
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 00:37:44 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org
 [2600:3c04:e001:324:0:1991:8:25])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f57d2ebd-4012-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 02:37:42 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 73AE361155;
 Tue,  3 Jun 2025 00:37:41 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 96FC4C4CEEB;
 Tue,  3 Jun 2025 00:37: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: f57d2ebd-4012-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748911061;
	bh=mknFyfIBYxVFm9uq84bHCuR2mRdnTQNbtNIAEz1NApI=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=fdXHPecKuCuq37omhJJVP7j7RenblEm+TXZCVfYRoHX/M+2Vom9nX7aw2/uiG5zVD
	 0fKk9Hq751G09CSV11JMxdYH9YdLGQRKfxWc/dYW+7aNVwSGc/k90R8uWecbV9miEg
	 SQb5Wj71/5YEuPVRqAnewHqlGFpXxglLrb7acd2UIpvKLMeMCVhJO2eRgggJyKBByK
	 1qFIjJxMEktTbKcB2UvhHNyEQ8VYeJKJMRtVADWkvVkD9vzLIhU66bQq3WY0fojnY8
	 B+OCw+K9fzUD9RIa4woclyMvlNMz03wTTim+abfqrdS4cHG9Y9toqJtNr/GkXCRq3H
	 SvqAMNf6LaY5Q==
Date: Mon, 2 Jun 2025 17:37:38 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: dmkhn@proton.me
cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, 
    anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, 
    michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, 
    dmukhin@ford.com
Subject: Re: [PATCH v5 4/4] xen/console: rename console_rx to console_domid
In-Reply-To: <20250530231841.73386-5-dmukhin@ford.com>
Message-ID: 
References: <20250530231841.73386-1-dmukhin@ford.com> <20250530231841.73386-5-dmukhin@ford.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 30 May 2025, dmkhn@proton.me wrote:
> From: Denis Mukhin 
> 
> Update the symbol name to match the code better.
> 
> No functional change.
> 
> Signed-off-by: Denis Mukhin 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/drivers/char/console.c | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index 37289d5558..5797f29d31 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -503,11 +503,11 @@ static void cf_check conring_dump_keyhandler(unsigned char key)
>  #define switch_code (opt_conswitch[0]-'a'+1)
>  
>  /* Console owner domain identifier. */
> -static domid_t __read_mostly console_rx = DOMID_XEN;
> +static domid_t __read_mostly console_domid = DOMID_XEN;
>  
>  struct domain *console_get_domain(void)
>  {
> -    struct domain *d = rcu_lock_domain_by_id(console_rx);
> +    struct domain *d = rcu_lock_domain_by_id(console_domid);
>  
>      if ( !d )
>          return NULL;
> @@ -533,7 +533,7 @@ static void console_set_domid(domid_t domid)
>      else
>          printk("*** Serial input to DOM%u", domid);
>  
> -    console_rx = domid;
> +    console_domid = domid;
>  
>      if ( switch_code )
>          printk(" (type 'CTRL-%c' three times to switch input)",
> @@ -549,10 +549,10 @@ static void console_switch_input(void)
>  {
>      domid_t hint;
>  
> -    if ( console_rx == DOMID_XEN )
> +    if ( console_domid == DOMID_XEN )
>          hint = get_initial_domain_id();
>      else
> -        hint = console_rx + 1;
> +        hint = console_domid + 1;
>  
>      hint = domid_find_with_input_allowed(hint);
>  
> @@ -564,7 +564,7 @@ static void __serial_rx(char c)
>      struct domain *d;
>      int rc = 0;
>  
> -    if ( console_rx == DOMID_XEN )
> +    if ( console_domid == DOMID_XEN )
>          return handle_keypress(c, false);
>  
>      d = console_get_domain();
> -- 
> 2.34.1
> 
> 


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 00:38:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 00:38:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003916.1383543 (Exim 4.92)
	(envelope-from )
	id 1uMFfV-0004Uv-5E; Tue, 03 Jun 2025 00:38:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003916.1383543; Tue, 03 Jun 2025 00: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 1uMFfV-0004Uo-2a; Tue, 03 Jun 2025 00:38:17 +0000
Received: by outflank-mailman (input) for mailman id 1003916;
 Tue, 03 Jun 2025 00:38: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 1uMFfT-0004IK-2D
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 00:38:16 +0000
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0824140d-4013-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 02:38:14 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0824140d-4013-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=vnfvoodvuzapxl32lxf6ktocfi.protonmail; t=1748911092; x=1749170292;
	bh=NkqVXTkUraQM1kDo5kywHE98t4vuBH9mpp4lvyunIHA=;
	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=WyXk5IdkzFX8lAw0CZjaYrNsHV2eBYHxWMHY07X11x/xv1RpmmrNmnF2wzgDR3+DT
	 Ng92SHKbwR7hP5hBfmRWrambYIoDi4uG+PCMf6vnP7sSDGRiO/FX+aTUjYeOfaUKHj
	 QYAjsK2OFm8r89guN9qSp1NunYtsBSvaOiJy2jrGFDNIV8EmDk0n95SqK8V2wUmVpI
	 OPDtXKvSQCdtO9IT7HOLReYEG3E8WftTw5J50KT3j2QFlOuQBVuzoAREgCMd4IQIFN
	 kllJkbFqrxCKbq8id3HahJxpJBI4bHjm3kKmd9I3FplmjfJ4djHhUZcjnUwa32wrgx
	 XLG6HGabidXcA==
Date: Tue, 03 Jun 2025 00:38:04 +0000
To: "Orzel, Michal" 
From: dmkhn@proton.me
Cc: Alejandro Vallejo , xen-devel@lists.xenproject.org, Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , "Daniel P. Smith" 
Subject: Re: [PATCH 12/19] xen/dt: Move bootfdt functions to xen/bootfdt.h
Message-ID: 
In-Reply-To: <9df7c8b2-0864-4d8e-8969-d876ae77c4cc@amd.com>
References:  <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-13-agarciav@amd.com>  <9df7c8b2-0864-4d8e-8969-d876ae77c4cc@amd.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 243c7a256fddd7c3254a3848b7c533d23957cce5
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 02, 2025 at 09:29:16AM +0200, Orzel, Michal wrote:
>=20
>=20
> On 31/05/2025 02:35, dmkhn@proton.me wrote:
> > On Fri, May 30, 2025 at 02:02:20PM +0200, Alejandro Vallejo wrote:
> >> Part of an unpicking process to extract bootfdt contents independent o=
f bootinfo
> >> to a separate file for x86 to take.
> >>
> >> Move functions required for early FDT parsing from device_tree.h and a=
rm's
> >> setup.h onto bootfdt.h
> >>
> >> Declaration motion only. Not a functional change.
> >>
> >> Signed-off-by: Alejandro Vallejo 
> >> ---
> >>  xen/arch/arm/include/asm/setup.h |  6 ----
> >>  xen/include/xen/bootfdt.h        | 62 +++++++++++++++++++++++++++++++=
+
> >>  xen/include/xen/device_tree.h    | 34 +-----------------
> >>  3 files changed, 63 insertions(+), 39 deletions(-)
> >>
> >> diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/a=
sm/setup.h
> >> index 0f9e531a34..32308837a9 100644
> >> --- a/xen/arch/arm/include/asm/setup.h
> >> +++ b/xen/arch/arm/include/asm/setup.h
> >> @@ -55,12 +55,6 @@ void setup_mm(void);
> >>  extern uint32_t hyp_traps_vector[];
> >>  void init_traps(void);
> >>
> >> -void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
> >> -                         uint32_t size_cells, paddr_t *start, paddr_t=
 *size);
> >> -
> >> -u32 device_tree_get_u32(const void *fdt, int node,
> >> -                        const char *prop_name, u32 dflt);
> >> -
> >>  int handle_device(struct domain *d, struct dt_device_node *dev, p2m_t=
ype_t p2mt,
> >>                    struct rangeset *iomem_ranges, struct rangeset *irq=
_ranges);
> >>
> >> diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
> >> index fa65e8fcf4..079259c719 100644
> >> --- a/xen/include/xen/bootfdt.h
> >> +++ b/xen/include/xen/bootfdt.h
> >> @@ -2,6 +2,7 @@
> >>  #ifndef XEN_BOOTFDT_H
> >>  #define XEN_BOOTFDT_H
> >>
> >> +#include 
> >>  #include 
> >>  #include 
> >>  #include 
> >> @@ -16,8 +17,53 @@
> >>  #define NR_MEM_BANKS 256
> >>  #define NR_SHMEM_BANKS 32
> >>
> >> +/* Default #address and #size cells */
> >> +#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
> >> +#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
> >> +
> >>  #define MAX_MODULES 32 /* Current maximum useful modules */
> >>
> >> +#define DEVICE_TREE_MAX_DEPTH 16
> >> +
> >> +/* Helper to read a big number; size is in cells (not bytes) */
> >> +static inline u64 dt_read_number(const __be32 *cell, int size)
> >> +{
> >> +    u64 r =3D 0;
> >> +
> >> +    while ( size-- )
> >> +        r =3D (r << 32) | be32_to_cpu(*(cell++));
> >> +    return r;
> >> +}
> >> +
> >> +static inline u64 dt_next_cell(int s, const __be32 **cellp)
> >> +{
> >> +    const __be32 *p =3D *cellp;
> >> +
> >> +    *cellp =3D p + s;
> >> +    return dt_read_number(p, s);
> >> +}
> >> +
> >> +typedef int (*device_tree_node_func)(const void *fdt,
> >> +                                     int node, const char *name, int =
depth,
> >> +                                     u32 address_cells, u32 size_cell=
s,
> >> +                                     void *data);
> >> +
> >> +/**
> >> + * device_tree_for_each_node - iterate over all device tree sub-nodes
> >> + * @fdt: flat device tree.
> >> + * @node: parent node to start the search from
> >> + * @func: function to call for each sub-node.
> >> + * @data: data to pass to @func.
> >> + *
> >> + * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
> >> + *
> >> + * Returns 0 if all nodes were iterated over successfully.  If @func
> >> + * returns a value different from 0, that value is returned immediate=
ly.
> >> + */
> >> +int device_tree_for_each_node(const void *fdt, int node,
> >> +                              device_tree_node_func func,
> >> +                              void *data);
> >> +
> >>  typedef enum {
> >>      BOOTMOD_XEN,
> >>      BOOTMOD_FDT,
> >> @@ -246,4 +292,20 @@ static inline struct membanks *membanks_xzalloc(u=
nsigned int nr,
> >>      return banks;
> >>  }
> >>
> >> +/*
> >> + * Interpret the property `prop_name` of `node` as a u32.
> >> + *
> >> + * Returns the property value on success; otherwise returns `dflt`.
> >> + */
> >> +uint32_t device_tree_get_u32(const void *fdt, int node,
> >> +                             const char *prop_name, uint32_t dflt);
> >
> > Suggest using `dt_` prefix (or any other good prefix) for all functions
> > in this header for consistency: e.g. there's dt_read_number() but also
> > device_tree_get_u32().
> Not really. AFAIR device_tree_ prefix is for functions operating on flatt=
ened DT
> (usually calling libfdt functions inside) and dt_ otherwise. Let's not mi=
x them.

I see, thanks for explanation.
I would add a brief comment in this header to distinguish such difference t=
hen.

>=20
> ~Michal
>=20



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 00:39:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 00:39:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003920.1383554 (Exim 4.92)
	(envelope-from )
	id 1uMFgC-00051a-Dg; Tue, 03 Jun 2025 00:39:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003920.1383554; Tue, 03 Jun 2025 00:39: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 1uMFgC-00051T-AS; Tue, 03 Jun 2025 00:39:00 +0000
Received: by outflank-mailman (input) for mailman id 1003920;
 Tue, 03 Jun 2025 00:38: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 1uMFgA-0004IK-Ig
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 00:38:58 +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 21fc5ef5-4013-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 02:38:57 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id CA07A5C61CE;
 Tue,  3 Jun 2025 00:36:38 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 74315C4CEEB;
 Tue,  3 Jun 2025 00:38:54 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 21fc5ef5-4013-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748911135;
	bh=ZmZLHhvDmwB5ExxcBcrnpPqmHiCrD9gNgYLtmtfnJF4=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=uRTpoUHbpPw28MjkJtdgLQbYOf96HBqbkA2ymC7F2gcb3xYNBMEj9lQej/XSJH5eR
	 qjnEAG1lA98Zf6OS4+Vfo21yy6DN4oRjWa1LPdc54Zp/V053rUxSv9uQyXH2E9aS/e
	 mTrpC/8JNfNxnYJNYTcJ/4wt8LdWbxC0CkAcbpaFK4IU/zyoZ3Z6b+zOJgvQ0DNSub
	 3TmNdLZ/wtkb43oAiR1PckICllKYGFE1+3PV9Qx61W77hz6kG1KFw2W/tTwS/NLS4q
	 sPSyqYgDutUQXluguQuagR+TohxLTSe6Ph/+UOS9xSxdzh0QDbk9QycNmNKvnsy/rm
	 u9my1SYGuQMLg==
Date: Mon, 2 Jun 2025 17:38:53 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Stewart Hildebrand 
cc: xen-devel@lists.xenproject.org, Anthony PERARD , 
    Juergen Gross 
Subject: Re: [PATCH v2 6/6] tools/arm: exclude iomem from domU extended
 regions
In-Reply-To: <20250508132040.532898-7-stewart.hildebrand@amd.com>
Message-ID: 
References: <20250508132040.532898-1-stewart.hildebrand@amd.com> <20250508132040.532898-7-stewart.hildebrand@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

I plan to commit this patch, unless someone objects

On Thu, 8 May 2025, Stewart Hildebrand wrote:
> When a device is passed through to a xl domU, the iomem ranges may
> overlap with the extended regions. Remove iomem from extended regions.
> 
> Signed-off-by: Stewart Hildebrand 
> ---
> Not sure if we need a Fixes: tag, but if we do:
> Fixes: 57f87857dc2d ("libxl/arm: Add handling of extended regions for DomU")
> 
> v1->v2:
> * no change
> ---
>  tools/libs/light/libxl_arm.c | 118 +++++++++++++++++++++++++++++------
>  1 file changed, 99 insertions(+), 19 deletions(-)
> 
> diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
> index 75c811053c7c..8ae16a1726fc 100644
> --- a/tools/libs/light/libxl_arm.c
> +++ b/tools/libs/light/libxl_arm.c
> @@ -798,6 +798,8 @@ static int make_timer_node(libxl__gc *gc, void *fdt,
>      return 0;
>  }
>  
> +#define MAX_NR_EXT_REGIONS   256
> +
>  static int make_hypervisor_node(libxl__gc *gc, void *fdt,
>                                  const libxl_version_info *vers)
>  {
> @@ -821,7 +823,7 @@ static int make_hypervisor_node(libxl__gc *gc, void *fdt,
>       */
>      res = fdt_property_reg_placeholder(gc, fdt, GUEST_ROOT_ADDRESS_CELLS,
>                                         GUEST_ROOT_SIZE_CELLS,
> -                                       GUEST_RAM_BANKS + 1);
> +                                       MAX_NR_EXT_REGIONS + 1);
>      if (res) return res;
>  
>      /*
> @@ -1517,17 +1519,29 @@ static void finalise_one_node(libxl__gc *gc, void *fdt, const char *uname,
>  
>  #define EXT_REGION_MIN_SIZE   xen_mk_ullong(0x0004000000) /* 64MB */
>  
> -static int finalize_hypervisor_node(libxl__gc *gc, struct xc_dom_image *dom)
> +static int compare_iomem(const void *a, const void *b)
> +{
> +    const libxl_iomem_range *x = a, *y = b;
> +
> +    if (x->gfn < y->gfn)
> +        return -1;
> +    if (x->gfn > y->gfn)
> +        return 1;
> +    return 0;
> +}
> +
> +static int finalize_hypervisor_node(libxl__gc *gc,
> +                                    libxl_domain_build_info *b_info,
> +                                    struct xc_dom_image *dom)
>  {
>      void *fdt = dom->devicetree_blob;
> -    uint64_t region_size[GUEST_RAM_BANKS] = {0}, region_base[GUEST_RAM_BANKS],
> -        bankend[GUEST_RAM_BANKS];
> +    uint64_t region_base[MAX_NR_EXT_REGIONS], region_size[MAX_NR_EXT_REGIONS];
>      uint32_t regs[(GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS) *
> -                  (GUEST_RAM_BANKS + 1)];
> +                  (MAX_NR_EXT_REGIONS + 1)];
>      be32 *cells = ®s[0];
>      const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
>      const uint64_t banksize[] = GUEST_RAM_BANK_SIZES;
> -    unsigned int i, len, nr_regions = 0;
> +    unsigned int i, j, len, nr_regions = 0;
>      libxl_dominfo info;
>      int offset, rc;
>  
> @@ -1542,20 +1556,90 @@ static int finalize_hypervisor_node(libxl__gc *gc, struct xc_dom_image *dom)
>      if (info.gpaddr_bits > 64)
>          return ERROR_INVAL;
>  
> +    qsort(b_info->iomem, b_info->num_iomem, sizeof(libxl_iomem_range),
> +          compare_iomem);
> +
>      /*
>       * Try to allocate separate 2MB-aligned extended regions from the first
>       * and second RAM banks taking into the account the maximum supported
>       * guest physical address space size and the amount of memory assigned
>       * to the guest.
>       */
> -    for (i = 0; i < GUEST_RAM_BANKS; i++) {
> -        region_base[i] = bankbase[i] +
> +    for (i = 0; i < GUEST_RAM_BANKS && nr_regions < MAX_NR_EXT_REGIONS; i++) {
> +        struct {
> +            uint64_t start;
> +            uint64_t end; /* inclusive */
> +        } unallocated;
> +        uint64_t size = 0;
> +
> +        unallocated.start = bankbase[i] +
>              ALIGN_UP_TO_2MB((uint64_t)dom->rambank_size[i] << XC_PAGE_SHIFT);
>  
> -        bankend[i] = ~0ULL >> (64 - info.gpaddr_bits);
> -        bankend[i] = min(bankend[i], bankbase[i] + banksize[i] - 1);
> -        if (bankend[i] > region_base[i])
> -            region_size[i] = bankend[i] - region_base[i] + 1;
> +        unallocated.end = ~0ULL >> (64 - info.gpaddr_bits);
> +        unallocated.end = min(unallocated.end, bankbase[i] + banksize[i] - 1);
> +
> +        if (unallocated.end > unallocated.start)
> +            size = unallocated.end - unallocated.start + 1;
> +
> +        if (size < EXT_REGION_MIN_SIZE)
> +            continue;
> +
> +        /* Exclude iomem */
> +        for (j = 0; j < b_info->num_iomem && nr_regions < MAX_NR_EXT_REGIONS;
> +             j++) {
> +            struct {
> +                uint64_t start;
> +                uint64_t end; /* inclusive */
> +            } iomem;
> +
> +            iomem.start = b_info->iomem[j].gfn << XC_PAGE_SHIFT;
> +            iomem.end = ((b_info->iomem[j].gfn + b_info->iomem[j].number)
> +                         << XC_PAGE_SHIFT) - 1;
> +
> +            if (iomem.end >= unallocated.start
> +                && iomem.start <= unallocated.end) {
> +
> +                if (iomem.start <= unallocated.start) {
> +                    unallocated.start = iomem.end + 1;
> +
> +                    if (iomem.end >= unallocated.end)
> +                        /* Complete overlap, discard unallocated region */
> +                        break;
> +
> +                    /* Beginning overlap */
> +                    continue;
> +                }
> +
> +                if (iomem.start > unallocated.start) {
> +                    assert(unallocated.end > unallocated.start);
> +                    size = iomem.start - unallocated.start;
> +
> +                    if (size >= EXT_REGION_MIN_SIZE) {
> +                        region_base[nr_regions] = unallocated.start;
> +                        region_size[nr_regions] = size;
> +                        nr_regions++;
> +                    }
> +
> +                    unallocated.start = iomem.end + 1;
> +
> +                    if (iomem.end >= unallocated.end)
> +                        /* End overlap, discard remaining unallocated region */
> +                        break;
> +                }
> +            }
> +        }
> +
> +        if (unallocated.end > unallocated.start
> +            && nr_regions < MAX_NR_EXT_REGIONS)
> +        {
> +            size = unallocated.end - unallocated.start + 1;
> +
> +            if (size >= EXT_REGION_MIN_SIZE) {
> +                region_base[nr_regions] = unallocated.start;
> +                region_size[nr_regions] = size;
> +                nr_regions++;
> +            }
> +        }
>      }
>  
>      /*
> @@ -1565,16 +1649,12 @@ static int finalize_hypervisor_node(libxl__gc *gc, struct xc_dom_image *dom)
>      set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
>                GUEST_GNTTAB_BASE, GUEST_GNTTAB_SIZE);
>  
> -    for (i = 0; i < GUEST_RAM_BANKS; i++) {
> -        if (region_size[i] < EXT_REGION_MIN_SIZE)
> -            continue;
> -
> +    for (i = 0; i < nr_regions; i++) {
>          LOG(DEBUG, "Extended region %u: %#"PRIx64"->%#"PRIx64"",
> -            nr_regions, region_base[i], region_base[i] + region_size[i]);
> +            i, region_base[i], region_base[i] + region_size[i]);
>  
>          set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
>                    region_base[i], region_size[i]);
> -        nr_regions++;
>      }
>  
>      if (!nr_regions)
> @@ -1626,7 +1706,7 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc *gc,
>  
>      }
>  
> -    res = finalize_hypervisor_node(gc, dom);
> +    res = finalize_hypervisor_node(gc, &d_config->b_info, dom);
>      if (res)
>          return res;
>  
> -- 
> 2.49.0
> 
> 


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 00:42:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 00:42:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003931.1383564 (Exim 4.92)
	(envelope-from )
	id 1uMFjI-0006na-Pq; Tue, 03 Jun 2025 00:42:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003931.1383564; Tue, 03 Jun 2025 00: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 1uMFjI-0006nT-N8; Tue, 03 Jun 2025 00:42:12 +0000
Received: by outflank-mailman (input) for mailman id 1003931;
 Tue, 03 Jun 2025 00:42: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 1uMFjH-0006nN-7W
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 00:42:11 +0000
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 95331cc7-4013-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 02:42:10 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 95331cc7-4013-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1748911329; x=1749170529;
	bh=FgKpQh5AdTMGBDKbYRmo26c2uRVxV1LJ2o+HuXBB+K0=;
	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=UCMShHsiDSU0AHw5AgWLzLCH1qvD7Qe7PVrtRjNBE9K94nlTthOObU83XDcUhE7jS
	 zPOaqo34Q7FiEL9k9I5LXOgI95P65O83E3u4bc13nMdVc+ROCPuCgTzem5aC0yvdEg
	 hVN5OosngNDvBTxmp4os6L6Nl5t8kCtukC3vxsQvN0sVbcIIZCV1r3+G2yCbJIp15V
	 JTOr5BMqwKxRxGslt2AfWfEz0jXzEZcn+vjp1HgrLd/E2GkM1k09tJyID+x9US6k6e
	 H2b/Y2h+EVJOA2sF+GrLwOuYIOTdpsDtYQbRWTjIv4C9waMJMKSuThjhF9OeYPiAD8
	 UENBvDJnG71OQ==
Date: Tue, 03 Jun 2025 00:42:04 +0000
To: Alejandro Vallejo 
From: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , "Daniel P. Smith" 
Subject: Re: [PATCH 12/19] xen/dt: Move bootfdt functions to xen/bootfdt.h
Message-ID: 
In-Reply-To: 
References:  <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-13-agarciav@amd.com>  
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 636e15f7edcbc4454be038178d58dc897d0a91ae
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 02, 2025 at 06:41:32PM +0200, Alejandro Vallejo wrote:
> On Sat May 31, 2025 at 2:35 AM CEST, dmkhn wrote:
> > On Fri, May 30, 2025 at 02:02:20PM +0200, Alejandro Vallejo wrote:
> >> Part of an unpicking process to extract bootfdt contents independent o=
f bootinfo
> >> to a separate file for x86 to take.
> >>
> >> Move functions required for early FDT parsing from device_tree.h and a=
rm's
> >> setup.h onto bootfdt.h
> >>
> >> Declaration motion only. Not a functional change.
> >>
> >> Signed-off-by: Alejandro Vallejo 
> >> ---
> >>  xen/arch/arm/include/asm/setup.h |  6 ----
> >>  xen/include/xen/bootfdt.h        | 62 +++++++++++++++++++++++++++++++=
+
> >>  xen/include/xen/device_tree.h    | 34 +-----------------
> >>  3 files changed, 63 insertions(+), 39 deletions(-)
> >>
> >> diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/a=
sm/setup.h
> >> index 0f9e531a34..32308837a9 100644
> >> --- a/xen/arch/arm/include/asm/setup.h
> >> +++ b/xen/arch/arm/include/asm/setup.h
> >> @@ -55,12 +55,6 @@ void setup_mm(void);
> >>  extern uint32_t hyp_traps_vector[];
> >>  void init_traps(void);
> >>
> >> -void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
> >> -                         uint32_t size_cells, paddr_t *start, paddr_t=
 *size);
> >> -
> >> -u32 device_tree_get_u32(const void *fdt, int node,
> >> -                        const char *prop_name, u32 dflt);
> >> -
> >>  int handle_device(struct domain *d, struct dt_device_node *dev, p2m_t=
ype_t p2mt,
> >>                    struct rangeset *iomem_ranges, struct rangeset *irq=
_ranges);
> >>
> >> diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
> >> index fa65e8fcf4..079259c719 100644
> >> --- a/xen/include/xen/bootfdt.h
> >> +++ b/xen/include/xen/bootfdt.h
> >> @@ -2,6 +2,7 @@
> >>  #ifndef XEN_BOOTFDT_H
> >>  #define XEN_BOOTFDT_H
> >>
> >> +#include 
> >>  #include 
> >>  #include 
> >>  #include 
> >> @@ -16,8 +17,53 @@
> >>  #define NR_MEM_BANKS 256
> >>  #define NR_SHMEM_BANKS 32
> >>
> >> +/* Default #address and #size cells */
> >> +#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
> >> +#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
> >> +
> >>  #define MAX_MODULES 32 /* Current maximum useful modules */
> >>
> >> +#define DEVICE_TREE_MAX_DEPTH 16
> >> +
> >> +/* Helper to read a big number; size is in cells (not bytes) */
> >> +static inline u64 dt_read_number(const __be32 *cell, int size)
> >> +{
> >> +    u64 r =3D 0;
> >> +
> >> +    while ( size-- )
> >> +        r =3D (r << 32) | be32_to_cpu(*(cell++));
> >> +    return r;
> >> +}
> >> +
> >> +static inline u64 dt_next_cell(int s, const __be32 **cellp)
> >> +{
> >> +    const __be32 *p =3D *cellp;
> >> +
> >> +    *cellp =3D p + s;
> >> +    return dt_read_number(p, s);
> >> +}
> >> +
> >> +typedef int (*device_tree_node_func)(const void *fdt,
> >> +                                     int node, const char *name, int =
depth,
> >> +                                     u32 address_cells, u32 size_cell=
s,
> >> +                                     void *data);
> >> +
> >> +/**
> >> + * device_tree_for_each_node - iterate over all device tree sub-nodes
> >> + * @fdt: flat device tree.
> >> + * @node: parent node to start the search from
> >> + * @func: function to call for each sub-node.
> >> + * @data: data to pass to @func.
> >> + *
> >> + * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
> >> + *
> >> + * Returns 0 if all nodes were iterated over successfully.  If @func
> >> + * returns a value different from 0, that value is returned immediate=
ly.
> >> + */
> >> +int device_tree_for_each_node(const void *fdt, int node,
> >> +                              device_tree_node_func func,
> >> +                              void *data);
> >> +
> >>  typedef enum {
> >>      BOOTMOD_XEN,
> >>      BOOTMOD_FDT,
> >> @@ -246,4 +292,20 @@ static inline struct membanks *membanks_xzalloc(u=
nsigned int nr,
> >>      return banks;
> >>  }
> >>
> >> +/*
> >> + * Interpret the property `prop_name` of `node` as a u32.
> >> + *
> >> + * Returns the property value on success; otherwise returns `dflt`.
> >> + */
> >> +uint32_t device_tree_get_u32(const void *fdt, int node,
> >> +                             const char *prop_name, uint32_t dflt);
> >
> > Suggest using `dt_` prefix (or any other good prefix) for all functions
> > in this header for consistency: e.g. there's dt_read_number() but also
> > device_tree_get_u32().
>=20
> I'd be quite happy with an fdt_ prefix, to clearly show they relate to FD=
Ts.

+1

>=20
> But I didn't want to do that right away because it would obscure the stri=
ct code
> motion that's going on.

Got it!

>=20
> >
> >> +
> >> +/*
> >> + * Interpret the property `prop_name` of `node` as a "reg".
> >> + *
> >> + * Returns outputs in `start` and `size`.
> >> + */
> >> +void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
> >> +                         uint32_t size_cells, paddr_t *start, paddr_t=
 *size);
> >> +
> >>  #endif /* XEN_BOOTFDT_H */
> >> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tr=
ee.h
> >> index 6dc1fb5159..0a22b1ba1d 100644
> >> --- a/xen/include/xen/device_tree.h
> >> +++ b/xen/include/xen/device_tree.h
> >> @@ -10,6 +10,7 @@
> >>  #ifndef __XEN_DEVICE_TREE_H__
> >>  #define __XEN_DEVICE_TREE_H__
> >>
> >> +#include 
> >>  #include 
> >>
> >>  #include 
> >> @@ -22,8 +23,6 @@
> >>  #include 
> >>  #include 
> >>
> >> -#define DEVICE_TREE_MAX_DEPTH 16
> >> -
> >>  /*
> >>   * Struct used for matching a device
> >>   */
> >> @@ -164,17 +163,8 @@ struct dt_raw_irq {
> >>      u32 specifier[DT_MAX_IRQ_SPEC];
> >>  };
> >>
> >> -typedef int (*device_tree_node_func)(const void *fdt,
> >> -                                     int node, const char *name, int =
depth,
> >> -                                     u32 address_cells, u32 size_cell=
s,
> >> -                                     void *data);
> >> -
> >>  extern const void *device_tree_flattened;
> >>
> >> -int device_tree_for_each_node(const void *fdt, int node,
> >> -                              device_tree_node_func func,
> >> -                              void *data);
> >> -
> >>  /**
> >>   * dt_unflatten_host_device_tree - Unflatten the host device tree
> >>   *
> >> @@ -245,10 +235,6 @@ void intc_dt_preinit(void);
> >>  #define dt_node_cmp(s1, s2) strcasecmp((s1), (s2))
> >>  #define dt_compat_cmp(s1, s2) strcasecmp((s1), (s2))
> >>
> >> -/* Default #address and #size cells */
> >> -#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
> >> -#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
> >> -
> >>  #define dt_for_each_property_node(dn, pp)                   \
> >>      for ( pp =3D (dn)->properties; (pp) !=3D NULL; pp =3D (pp)->next =
)
> >>
> >> @@ -258,16 +244,6 @@ void intc_dt_preinit(void);
> >>  #define dt_for_each_child_node(dt, dn)                      \
> >>      for ( dn =3D (dt)->child; (dn) !=3D NULL; dn =3D (dn)->sibling )
> >>
> >> -/* Helper to read a big number; size is in cells (not bytes) */
> >> -static inline u64 dt_read_number(const __be32 *cell, int size)
> >> -{
> >> -    u64 r =3D 0;
> >> -
> >> -    while ( size-- )
> >> -        r =3D (r << 32) | be32_to_cpu(*(cell++));
> >> -    return r;
> >> -}
> >> -
> >>  /* Wrapper for dt_read_number() to return paddr_t (instead of uint64_=
t) */
> >>  static inline paddr_t dt_read_paddr(const __be32 *cell, int size)
> >>  {
> >> @@ -307,14 +283,6 @@ static inline int dt_size_to_cells(int bytes)
> >>      return (bytes / sizeof(u32));
> >>  }
> >>
> >> -static inline u64 dt_next_cell(int s, const __be32 **cellp)
> >> -{
> >> -    const __be32 *p =3D *cellp;
> >> -
> >> -    *cellp =3D p + s;
> >> -    return dt_read_number(p, s);
> >> -}
> >> -
> >>  static inline const char *dt_node_full_name(const struct dt_device_no=
de *np)
> >>  {
> >>      return (np && np->full_name) ? np->full_name : "";
> >> --
> >> 2.43.0
> >>
> >>
>=20



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 01:01:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 01:01:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003942.1383574 (Exim 4.92)
	(envelope-from )
	id 1uMG1g-0003US-DP; Tue, 03 Jun 2025 01:01:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003942.1383574; Tue, 03 Jun 2025 01:01: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 1uMG1g-0003TR-9r; Tue, 03 Jun 2025 01:01:12 +0000
Received: by outflank-mailman (input) for mailman id 1003942;
 Tue, 03 Jun 2025 01: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 1uMG1f-0002ih-1A
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 01:01:11 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org
 [2600:3c04:e001:324:0:1991:8:25])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 36d545eb-4016-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 03:01:00 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 859F961155;
 Tue,  3 Jun 2025 01:00:59 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3049AC4CEEB;
 Tue,  3 Jun 2025 01:00: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: 36d545eb-4016-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748912458;
	bh=gUWEOxy+ArxWs2+pcdbzIbJgdOuvw8mAqKKAjxlWx/U=;
	h=Date:From:To:cc:Subject:From;
	b=nAjLZ/1/2kXG1NmErzRnMeIeaWRt0rCj30kDhhJlqoWcfzymBZU25IKfrnOF9SX8j
	 Tx8DLhXczRAxpmnkCfU+cHrlFvd5f5RsYqjHFlQzKgSQ9F2cmRW74FvKbnf01NXIcS
	 TS9G4u0blI/Y7gNjpqcNP4y2W1fuDVYo6Yu70QkDF727yuqKzhk/AzS9vDst04anbb
	 4ctVesektOE18CILlhOOOHaqDw25gCD7DW5LiZP7Mn3SzM1gPvgVSmXg89hM0y0cfS
	 ygpXEqWwBAN6Bj1I3FQ2NeQ+GIHpAF1KAyHL10jVGmfsz91UKuONLv+a6MqejhKKqK
	 l5b2XZSYbd6ow==
Date: Mon, 2 Jun 2025 18:00:55 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: xen-devel@lists.xenproject.org
cc: Andrew Cooper , 
    Stefano Stabellini , michal.orzel@amd.com, 
    jbeulich@suse.com, julien@xen.org, roger.pau@citrix.com, 
    sstabellini@kernel.org, bertrand.marquis@arm.com, 
    federico.serafini@bugseng.com, Nicola Vetrini 
Subject: [PATCH v2] automation/eclair: update configuration of D4.10
Message-ID: 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

MISRA C Directive 4.10 states that "Precautions shall be taken in order
to prevent the contents of a header file being included more than
once".

Add a SAF tag to the existing comment on top of cpufeatures.h.
Add a header inclusion guard to compile.h.

Update ECLAIR configuration to:
- extend existing deviation to other comments explicitly saying a file
  is intended for multiple inclusion;
- extend existing deviation to other autogenerated files;
- tag the guidelines as clean.

Update deviations.rst accordingly.

Signed-off-by: Federico Serafini 
Signed-off-by: Stefano Stabellini 
---
Changes in v2:
- merge the two "Generated file, do not edit!" deviations into one
- change cpufeatures.h deviation to SAF
- remove compile.h deviation and change compile.h.in instead
---

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index 9c67358d46..3490db5a13 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -72,11 +72,16 @@ they are not instances of commented-out code."
 -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."
+-doc_begin="Files that are intended to be included more than once (and have
+a comment that says this explicitly) do not need to conform to the directive."
 -config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* This file is intended to be 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$)))"}
+-config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* Generated file, do not edit! \\*/$, begin-3...begin-2))"}
+-doc_end
+
+-doc_begin="Autogenerated files that do not need to conform to the directive."
+-config=MC3A2.D4.10,reports+={safe, "all_area(all_loc(file(^xen/include/generated/autoconf\\.h$)))"}
+-config=MC3A2.D4.10,reports+={safe, "all_area(all_loc(file(^xen/include/compat/xlat\\.h$)))"}
+-config=MC3A2.D4.10,reports+={safe, "all_area(all_loc(file(^xen/arch/(arm||x86)/include/generated/asm/.*$)))"}
 -doc_end
 
 -doc_begin="Including multiple times a .c file is safe because every function or data item
diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl b/automation/eclair_analysis/ECLAIR/tagging.ecl
index f9da5d5f4d..b95f07feb0 100644
--- a/automation/eclair_analysis/ECLAIR/tagging.ecl
+++ b/automation/eclair_analysis/ECLAIR/tagging.ecl
@@ -23,6 +23,7 @@
 "MC3A2.D1.1||
 MC3A2.D2.1||
 MC3A2.D4.1||
+MC3A2.D4.10||
 MC3A2.D4.11||
 MC3A2.D4.14||
 MC3A2.R1.1||
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index fe0b1e10a2..57580fff5f 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -30,6 +30,20 @@ Deviations related to MISRA C:2012 Directives:
        not to add an additional encapsulation layer.
      - Tagged as `deliberate` for ECLAIR.
 
+   * - D4.10
+     - Files that are intended to be included more than once (and have
+       a comment that says this explicitly) do not need to conform to the
+       directive.
+     - Tagged as `safe` for ECLAIR.
+
+   * - D4.10
+     - There are autogenerated files that do not need to comply to the
+       directive.
+     - Tagged as `safe` for ECLAIR. Such files are:
+        - xen/include/generated/autoconf.h
+        - xen/include/compat/xlat.h
+        - xen/arch/{arm,x86}/include/generated/asm/\*
+
    * - D4.10
      - Including multiple times a .c file is safe because every function or data item
        it defines would in (the common case) be already defined.
diff --git a/xen/arch/x86/include/asm/cpufeatures.h b/xen/arch/x86/include/asm/cpufeatures.h
index 9e3ed21c02..02d5250b08 100644
--- a/xen/arch/x86/include/asm/cpufeatures.h
+++ b/xen/arch/x86/include/asm/cpufeatures.h
@@ -1,5 +1,5 @@
 /*
- * Explicitly intended for multiple inclusion.
+ * SAF-8-safe: Explicitly intended for multiple inclusion.
  */
 
 #include 
diff --git a/xen/include/xen/compile.h.in b/xen/include/xen/compile.h.in
index 3151d1e7d1..9206341ba6 100644
--- a/xen/include/xen/compile.h.in
+++ b/xen/include/xen/compile.h.in
@@ -1,3 +1,6 @@
+#ifndef XEN_COMPILE_H
+#define XEN_COMPILE_H
+
 #define XEN_COMPILE_DATE	"@@date@@"
 #define XEN_COMPILE_TIME	"@@time@@"
 #define XEN_COMPILE_BY		"@@whoami@@"
diff --git a/xen/tools/process-banner.sed b/xen/tools/process-banner.sed
index 56c76558bc..2c56b5939d 100755
--- a/xen/tools/process-banner.sed
+++ b/xen/tools/process-banner.sed
@@ -12,3 +12,8 @@ s_(.*)_"\1\\n"_
 
 # Trailing \ on all but the final line.
 $!s_$_ \\_
++
+# Append closing header guard
+$a\
+\
+#endif /* XEN_COMPILE_H */


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 01:03:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 01:03:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003949.1383585 (Exim 4.92)
	(envelope-from )
	id 1uMG3j-0001Iq-PQ; Tue, 03 Jun 2025 01:03:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003949.1383585; Tue, 03 Jun 2025 01:03: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 1uMG3j-0001Ij-LO; Tue, 03 Jun 2025 01:03:19 +0000
Received: by outflank-mailman (input) for mailman id 1003949;
 Tue, 03 Jun 2025 01:03: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 1uMG3h-0001IU-RZ
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 01:03:18 +0000
Received: from mail-10628.protonmail.ch (mail-10628.protonmail.ch
 [79.135.106.28]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 873f035b-4016-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 03:03:15 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 873f035b-4016-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1748912593; x=1749171793;
	bh=xb16ngmh0Y4gX1KL08ipj9+1nfE4yRAO6vOVfdFkpmA=;
	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=iK3d86RxaQd80PyD56bM/9TabG4rcH75iDx9QTRcCxnVTzCONgV4v5O5ewh8I1d/p
	 4ZG3viDaZkoBH9TEWn8nCKWUx38FUe/lucRD6D4VBmiuvNYyqa+dW3pWWit6XDAcwj
	 OqfeVmuhYbc8DrZHy3cFCXaKML0A8hjMzZtTJlksW2dH55KhG0AZFG8eC1Wler5VaK
	 1hJdOoSlvDN1FEay82lkh4UPFNsEupPtyjxyEPn8ZLYbXdbVz8NoGZz0NqVtlhV+P6
	 YdDLr23bng+hzYUxSatBex1urkfXThTOuS+dS94mnwqU7puTdxYpG715uOa+uZv8Bs
	 esksEc2qxJcag==
Date: Tue, 03 Jun 2025 01:03:08 +0000
To: Stefano Stabellini 
From: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, dmukhin@ford.com
Subject: Re: [PATCH v5 3/4] xen/console: remove max_init_domid dependency
Message-ID: 
In-Reply-To: 
References: <20250530231841.73386-1-dmukhin@ford.com> <20250530231841.73386-4-dmukhin@ford.com> 
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 70ac7c5d8bfbc04b1a8f0c45f2c1aba9e03999db
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 02, 2025 at 05:36:25PM -0700, Stefano Stabellini wrote:
> On Fri, 30 May 2025, dmkhn@proton.me wrote:
> > From: Denis Mukhin 
> >
> > The physical console input rotation depends on max_init_domid symbol, w=
hich is
> > managed differently across architectures.
> >
> > Instead of trying to manage max_init_domid in the arch-common code the =
console
> > input rotation code can be reworked by removing dependency on max_init_=
domid
> > entirely.
> >
> > To do that, introduce domid_find_with_input_allowed() in arch-independe=
nt
> > location to find the ID of the next possible console owner domain. The =
IDs
> > are rotated across non-system domain IDs and DOMID_XEN.
> >
> > Also, introduce helper console_set_domid() for updating identifier of t=
he
> > current console input owner (points to Xen or domain).
> >
> > Use domid_find_with_input_allowed() and console_set_domid() in
> > console_switch_input().
> >
> > Remove uses of max_init_domid in the code.
> >
> > Signed-off-by: Denis Mukhin 
> > ---
> > Changes since v4:
> > - fixed domid_find_with_input_allowed()
> > - kept switching to get_initial_domain_id() in console_endboot()
> > ---
> >  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/device-tree/dom0less-build.c |  2 -
> >  xen/common/domain.c                     | 33 +++++++++
> >  xen/drivers/char/console.c              | 90 +++++++++----------------
> >  xen/include/xen/domain.h                |  1 +
> >  9 files changed, 65 insertions(+), 71 deletions(-)
> >
> > diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/as=
m/setup.h
> > index 6cf272c160..f107e8eebb 100644
> > --- a/xen/arch/arm/include/asm/setup.h
> > +++ b/xen/arch/arm/include/asm/setup.h
> > @@ -25,8 +25,6 @@ struct map_range_data
> >      struct rangeset *irq_ranges;
> >  };
> >
> > -extern domid_t max_init_domid;
> > -
> >  void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
> >
> >  size_t estimate_efi_size(unsigned int mem_nr_banks);
> > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> > index 734e23da44..0a18d479f9 100644
> > --- a/xen/arch/arm/setup.c
> > +++ b/xen/arch/arm/setup.c
> > @@ -61,8 +61,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/as=
m/setup.h
> > index e4f64879b6..956fa6985a 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/includ=
e/asm/setup.h
> > index c9d69cdf51..d1fc64b673 100644
> > --- a/xen/arch/riscv/include/asm/setup.h
> > +++ b/xen/arch/riscv/include/asm/setup.h
> > @@ -5,8 +5,6 @@
> >
> >  #include 
> >
> > -#define max_init_domid (0)
> > -
> >  void setup_mm(void);
> >
> >  void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
> > diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/as=
m/setup.h
> > index ac34c69855..b67de8577f 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/device-tree/dom0less-build.c b/xen/common/devic=
e-tree/dom0less-build.c
> > index 9a6015f4ce..703f20faed 100644
> > --- a/xen/common/device-tree/dom0less-build.c
> > +++ b/xen/common/device-tree/dom0less-build.c
> > @@ -977,8 +977,6 @@ void __init create_domUs(void)
> >          domid =3D domid_alloc(DOMID_INVALID);
> >          if ( domid =3D=3D DOMID_INVALID )
> >              panic("Error allocating ID for domain %s\n", dt_node_name(=
node));
> > -        if ( max_init_domid < domid )
> > -            max_init_domid =3D domid;
> >
> >          d =3D domain_create(domid, &d_cfg, flags);
> >          if ( IS_ERR(d) )
> > diff --git a/xen/common/domain.c b/xen/common/domain.c
> > index d75ece1b61..4a54bc27a3 100644
> > --- a/xen/common/domain.c
> > +++ b/xen/common/domain.c
> > @@ -2461,6 +2461,39 @@ void domid_free(domid_t domid)
> >      spin_unlock(&domid_lock);
> >  }
> >
> > +/*
> > + * Find the ID of the next possible console owner domain.
> > + *
> > + * @return Domain ID: DOMID_XEN or non-system domain IDs within
> > + * the range of [0..DOMID_FIRST_RESERVED-1].
> > + */
> > +domid_t domid_find_with_input_allowed(domid_t hint)
> > +{
> > +    domid_t domid =3D DOMID_XEN;
> > +
> > +    if ( hint < DOMID_FIRST_RESERVED )
> > +    {
> > +        struct domain *d;
> > +
> > +        rcu_read_lock(&domlist_read_lock);
> > +
> > +        for ( d =3D domid_to_domain(hint);
> > +              d && get_domain(d) && d->domain_id < DOMID_FIRST_RESERVE=
D;
>=20
> The get_domain(d) worries me because it is increasing the domain's
> refcnt but I don't see a corresponding call to put_domain to decrease
> it.
>=20
> If I keep rotating between consoles, I could keep increasing refcnt
> indefinitely?
>=20
> I think we either need a corresponding put_domain(d) call when the domain
> loses input focus, or we remove the get_domain(d) based on the fact that
> we don't need it. I think before this patch we didn't increment refcnt
> when a domain has focus but I am not sure it was correct.

Thank you for catching this!

My understanding the code should be doing refcnt-ing properly to
access the domain fields, so there has to be a put_domain() call.

Will update.

>=20
>=20
> > +              d =3D rcu_dereference(d->next_in_list) )
> > +        {
> > +            if ( d->console.input_allowed )
> > +            {
> > +                domid =3D d->domain_id;
> > +                break;
> > +            }
> > +        }
> > +
> > +        rcu_read_unlock(&domlist_read_lock);
> > +    }
> > +
> > +    return domid;
> > +}
> > +
> >  /*
> >   * Local variables:
> >   * mode: C
> > diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> > index 9a9836ba91..37289d5558 100644
> > --- a/xen/drivers/char/console.c
> > +++ b/xen/drivers/char/console.c
> > @@ -498,26 +498,17 @@ static void cf_check conring_dump_keyhandler(unsi=
gned char key)
> >
> >  /*
> >   * CTRL- changes input direction, rotating among Xen, Dom=
0,
> > - * and the DomUs started from Xen at boot.
> > + * and the DomUs.
> >   */
> >  #define switch_code (opt_conswitch[0]-'a'+1)
> > -/*
> > - * console_rx=3D0 =3D> input to xen
> > - * console_rx=3D1 =3D> input to dom0 (or the sole shim domain)
> > - * console_rx=3DN =3D> input to dom(N-1)
> > - */
> > -static unsigned int __read_mostly console_rx =3D 0;
> >
> > -#define max_console_rx (max_init_domid + 1)
> > +/* Console owner domain identifier. */
> > +static domid_t __read_mostly console_rx =3D DOMID_XEN;
> >
> >  struct domain *console_get_domain(void)
> >  {
> > -    struct domain *d;
> > +    struct domain *d =3D rcu_lock_domain_by_id(console_rx);
> >
> > -    if ( console_rx =3D=3D 0 )
> > -            return NULL;
> > -
> > -    d =3D rcu_lock_domain_by_id(console_rx - 1);
> >      if ( !d )
> >          return NULL;
> >
> > @@ -535,43 +526,14 @@ void console_put_domain(struct domain *d)
> >          rcu_unlock_domain(d);
> >  }
> >
> > -static void console_switch_input(void)
> > +static void console_set_domid(domid_t domid)
> >  {
> > -    unsigned int next_rx =3D console_rx;
> > +    if ( domid =3D=3D DOMID_XEN )
> > +        printk("*** Serial input to Xen");
> > +    else
> > +        printk("*** Serial input to DOM%u", domid);
> >
> > -    /*
> > -     * Rotate among Xen, dom0 and boot-time created domUs while skippi=
ng
> > -     * switching serial input to non existing domains.
> > -     */
> > -    for ( ; ; )
> > -    {
> > -        domid_t domid;
> > -        struct domain *d;
> > -
> > -        if ( next_rx++ >=3D max_console_rx )
> > -        {
> > -            console_rx =3D 0;
> > -            printk("*** Serial input to Xen");
> > -            break;
> > -        }
> > -
> > -        if ( consoled_is_enabled() && next_rx =3D=3D 1 )
> > -            domid =3D get_initial_domain_id();
> > -        else
> > -            domid =3D next_rx - 1;
> > -        d =3D rcu_lock_domain_by_id(domid);
> > -        if ( d )
> > -        {
> > -            rcu_unlock_domain(d);
> > -
> > -            if ( !d->console.input_allowed )
> > -                continue;
> > -
> > -            console_rx =3D next_rx;
> > -            printk("*** Serial input to DOM%u", domid);
> > -            break;
> > -        }
> > -    }
> > +    console_rx =3D domid;
> >
> >      if ( switch_code )
> >          printk(" (type 'CTRL-%c' three times to switch input)",
> > @@ -579,12 +541,30 @@ static void console_switch_input(void)
> >      printk("\n");
> >  }
> >
> > +/*
> > + * Switch console focus.
> > + * Rotates input focus among Xen and domains with console input permis=
sion.
> > + */
> > +static void console_switch_input(void)
> > +{
> > +    domid_t hint;
> > +
> > +    if ( console_rx =3D=3D DOMID_XEN )
> > +        hint =3D get_initial_domain_id();
> > +    else
> > +        hint =3D console_rx + 1;
> > +
> > +    hint =3D domid_find_with_input_allowed(hint);
> > +
> > +    console_set_domid(hint);
> > +}
> > +
> >  static void __serial_rx(char c)
> >  {
> >      struct domain *d;
> >      int rc =3D 0;
> >
> > -    if ( console_rx =3D=3D 0 )
> > +    if ( console_rx =3D=3D DOMID_XEN )
> >          return handle_keypress(c, false);
> >
> >      d =3D console_get_domain();
> > @@ -1169,14 +1149,6 @@ void __init console_endboot(void)
> >
> >      video_endboot();
> >
> > -    /*
> > -     * If user specifies so, we fool the switch routine to redirect in=
put
> > -     * straight back to Xen. I use this convoluted method so we still =
print
> > -     * a useful 'how to switch' message.
> > -     */
> > -    if ( opt_conswitch[1] =3D=3D 'x' )
> > -        console_rx =3D max_console_rx;
> > -
> >      register_keyhandler('w', conring_dump_keyhandler,
> >                          "synchronously dump console ring buffer (dmesg=
)", 0);
> >      register_irq_keyhandler('+', &do_inc_thresh,
> > @@ -1186,8 +1158,8 @@ 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_switch_input();
> > +    if ( opt_conswitch[1] !=3D 'x' )
> > +        (void)console_set_domid(get_initial_domain_id());
> >  }
> >
> >  int __init console_has(const char *device)
> > diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
> > index 8aab05ae93..a88eb34f3f 100644
> > --- a/xen/include/xen/domain.h
> > +++ b/xen/include/xen/domain.h
> > @@ -36,6 +36,7 @@ void getdomaininfo(struct domain *d, struct xen_domct=
l_getdomaininfo *info);
> >  void arch_get_domain_info(const struct domain *d,
> >                            struct xen_domctl_getdomaininfo *info);
> >
> > +domid_t domid_find_with_input_allowed(domid_t hint);
> >  domid_t get_initial_domain_id(void);
> >
> >  domid_t domid_alloc(domid_t domid);
> > --
> > 2.34.1
> >
> >



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 06:12:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 06:12:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003960.1383594 (Exim 4.92)
	(envelope-from )
	id 1uMKsf-0003a2-2g; Tue, 03 Jun 2025 06:12:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003960.1383594; Tue, 03 Jun 2025 06:12:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMKse-0003Zv-VX; Tue, 03 Jun 2025 06:12:12 +0000
Received: by outflank-mailman (input) for mailman id 1003960;
 Tue, 03 Jun 2025 06:12: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 1uMKsd-0003Zp-Vp
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 06:12:12 +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 a9df218b-4041-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 08:12:01 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a50fc819f2so939401f8f.2
 for ; Mon, 02 Jun 2025 23:12:01 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23506bdb3f4sm80459875ad.86.2025.06.02.23.11.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 02 Jun 2025 23:12:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a9df218b-4041-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1748931121; x=1749535921; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=gCW1YWXzY7SUtJ7RPccHS3xdLZAmi9LuM82UNhqVUsY=;
        b=Gkv5GMyLof2pG5ef99WS3AeGp4Js1dftdbDInJhMrUMHlUGP6cRyJO44XaTZi9aFpE
         uUv9oRITz32d+bBLQhbubGndN3ICQk33XA/iCebLBJ2avQ9NwyqeZMtdXXoRKYEPuUsl
         BuJnb9oySbFuKgJ9paVqROOHCNBsoHSeIDHkKIn+DW8EsBHlnPSYmqq2vQahIT0RNPtd
         sgdh2bboTHpF9/yZwB4ebpapBrPmPGKWytlkhiveVXx14eU8kI4xMfoID+tuQKVdF+ac
         KnrWa5XJu6R7sgr+/I6UyHVVrWpXB0CM33vQqqBNo3/Qga+WlvxJ+3IWjPZLFLr/NvDu
         Wq4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748931121; x=1749535921;
        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=gCW1YWXzY7SUtJ7RPccHS3xdLZAmi9LuM82UNhqVUsY=;
        b=RxpoNbskK+Ytr8DqfUMqObWVeccry77h1lRvVy/1oz195blpJB6r2u9YL15Xpyqmoj
         3akvfzb62MuQtQQPvSDtiv8ecs5/HC2LmD7mWom7L1VNtoxKwdkzROAY+Fy826kOrqr4
         Y5qBxLdtA8oY/QEjueKqJmDyPFjQbi6tZddUJt0Ant2BVNwf/P5dMO1ZGgBZU02y3O8b
         B8eyGxXJQDt2ejRPvxsDLgyVmg/4yFrMYLjZS7fqEPkHqKREuX/D9F2YbUrydQE+bxCK
         An9URifgqeX3q1YVvHP0QQcD2ny9bgnOvLeBYD9dMq+YN+HjacfefN523Gw7UcEVs6wb
         gyog==
X-Gm-Message-State: AOJu0YwcxgZEE5YCAxq2F3XyiJotUNULa4usMZNpx/Ol5PXii/Z+BXVO
	Mh2GLZhwlLfQnVn51LOY/7lvMT4m+bmxfiV0crE7BENG2FPn8dwS/UznO95N6i+cQQ==
X-Gm-Gg: ASbGnctWwdOCTio/7LRKMu4QxAx6kgwEYjpD/Z6yXSl6xE83OUkdfbwKFUULkyJRkjB
	nEXRc16OFEoW7XtEMtNu7lfGLyudqaEnd11fTTMqwztnQ64hsKnSJ5WPZxbMOMt3lTWXhJIdlNb
	b5ESh7pwH1KrvreYhWW93tPli4E+ebzgsF0aOP6nL4pJMxVTCKIWpKTpsWrryt+UKns0xfqWlxO
	Bci3CNgHDGEviD9pWqMqCbQoL75XHHlE1rJeF69Cjta4n4Y8KhQ+npvl4fFGHo4DQGhE/yFjvd7
	2qQsdjlyw9KkuVZxHVnEr4DuOWlrYjQdTYSttUvfDpwoRi//RO1f+7Enmc6KyUY/lHQ0zySknUs
	E34wNzhX7EkOF3xBO4RXV6jGms79zuM1TKiLG2YCgHi0dmpg=
X-Google-Smtp-Source: AGHT+IHGLmXc0ur50kXNPdlU5gfKgfT19cS/P5/yviC69hxHa8rxLZvwITKqg8YCs/CF2equlVXJFw==
X-Received: by 2002:a5d:64ed:0:b0:3a4:e8c8:fb9e with SMTP id ffacd0b85a97d-3a4f7aaf9d5mr11601961f8f.49.1748931121111;
        Mon, 02 Jun 2025 23:12:01 -0700 (PDT)
Message-ID: 
Date: Tue, 3 Jun 2025 08:11:51 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 3/4] xen/console: remove max_init_domid dependency
To: Stefano Stabellini , dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com,
 anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com,
 roger.pau@citrix.com, dmukhin@ford.com
References: <20250530231841.73386-1-dmukhin@ford.com>
 <20250530231841.73386-4-dmukhin@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: 7bit

On 03.06.2025 02:36, Stefano Stabellini wrote:
> On Fri, 30 May 2025, dmkhn@proton.me wrote:
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -2461,6 +2461,39 @@ void domid_free(domid_t domid)
>>      spin_unlock(&domid_lock);
>>  }
>>  
>> +/*
>> + * Find the ID of the next possible console owner domain.
>> + *
>> + * @return Domain ID: DOMID_XEN or non-system domain IDs within
>> + * the range of [0..DOMID_FIRST_RESERVED-1].
>> + */
>> +domid_t domid_find_with_input_allowed(domid_t hint)
>> +{
>> +    domid_t domid = DOMID_XEN;
>> +
>> +    if ( hint < DOMID_FIRST_RESERVED )
>> +    {
>> +        struct domain *d;
>> +
>> +        rcu_read_lock(&domlist_read_lock);
>> +
>> +        for ( d = domid_to_domain(hint);
>> +              d && get_domain(d) && d->domain_id < DOMID_FIRST_RESERVED;
> 
> The get_domain(d) worries me because it is increasing the domain's
> refcnt but I don't see a corresponding call to put_domain to decrease
> it.
> 
> If I keep rotating between consoles, I could keep increasing refcnt
> indefinitely?
> 
> I think we either need a corresponding put_domain(d) call when the domain
> loses input focus, or we remove the get_domain(d) based on the fact that
> we don't need it. I think before this patch we didn't increment refcnt
> when a domain has focus but I am not sure it was correct.

I think it was. The code was - aiui - specifically prepared to deal with
domains going away behind its back. A domain having input focus should
not prevent it from being (fully) destroyed.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 06:20:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 06:20:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003971.1383604 (Exim 4.92)
	(envelope-from )
	id 1uML0n-0005a4-Tn; Tue, 03 Jun 2025 06:20:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003971.1383604; Tue, 03 Jun 2025 06:20:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uML0n-0005Zx-Qx; Tue, 03 Jun 2025 06:20:37 +0000
Received: by outflank-mailman (input) for mailman id 1003971;
 Tue, 03 Jun 2025 06:20: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 1uML0l-0005VI-Up
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 06:20:35 +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 da5858ae-4042-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 08:20:32 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-43ea40a6e98so56543155e9.1
 for ; Mon, 02 Jun 2025 23:20:32 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23506cd75c7sm80874745ad.113.2025.06.02.23.20.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 02 Jun 2025 23:20:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: da5858ae-4042-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1748931632; x=1749536432; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=EFE0kA07gvknvsWKGuyUxWgAprZxrTL6NRaU0HWBkQA=;
        b=Sj6hXd3ivSmWTvzXg3yam58OdUUOsT3qCwmVbKXEDF6FCEo5ozQZKNKMPwHTdNGb4F
         47O6GT564QBZLNKpkzE/lwqTKCEdPE8BjG902x3gkSI8HaKE1BAB2WfZPCSwSaLhFav8
         amU5ydIP0HCHiOv1ZTeyD0ZBweHYpNf/pl7zjMJqY4hTkv7SoFlT3Kf37AI0Ai507LlJ
         EnqTydJ8TGK5me2xztZXXwvTI4LNujmhQnAlx/0RmQQgHa4Hsiqj0+0fiZrlPUQeoLRk
         WOCNv6hZ5p/TwcX7ew4CafRMA6s161yXPN+rdAH4PX4mWnvofsnpcZ9qNLxUvYInbiSS
         IaKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748931632; x=1749536432;
        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=EFE0kA07gvknvsWKGuyUxWgAprZxrTL6NRaU0HWBkQA=;
        b=gGBklzQ/hWB95aKwivWgWXUgDh2a8hVXB8byu85FqqZARuxxHWjeEH5XtKvv4swMKy
         vcr7y2BM6UPkGuTdW/Qaow/xsuYxrUg1qZUtW8X9DXzNFjGjy+i3SxEQ65GxiHKM4/Gc
         v6Tjjv1LnZLEMLbAzLmQf1j3dCT9K4gLJDTnE5mdSZ5hzwk/Ty/RiFVPA5tDv/xN3lTR
         xHBzxuI9kq1vVJP4JyWQDjgl3qZQyXdj3Q5ylwNzKJkAAtdKBH9f6yOHJPxQFeTYE7CW
         7q4rOwPMvpP+7/HioXI3++uDSmV9O9EEkwGK3qhcrNGYtSGg3SNWRJxpQwG1gFhxmj/1
         0AXQ==
X-Forwarded-Encrypted: i=1; AJvYcCUVzGWs5gMiKT9ayEZj48nHRj23T1DGLb+CEjRsNDPt3Y9JXzc1XOQCRNU+G3SzcaDWlue/95dlv0g=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzc9g7a9V+jrRuEpFG+c7+1ZmdTTjd8Ot3UT0lQsLXr042V6en9
	7AMm3AsnfCizGadGy7jBv2/9lKkh33l4AKq++IG0XYvxGQAZ4E9GmcoIpne0KUWKqA==
X-Gm-Gg: ASbGncuZFO71/EfM8P1AsZtmoO8ZI/CkXm80ATBUPpP8Voxy3e7T7SenEMEj9HjYO2L
	WpAdF2JhCEF4NffjdtE78dOynLCvnQ+5Xu4SJbEYceuVzIZY4J6kYBj9XKmk6AEwAJhv8McCUbp
	sgLc2vg862ePKPUoR77H57K9KII2II4HQr33OvfM2zwudDENCxLD9G+s/mNiS58nZiA66F7NExM
	j8H4C8MkDSE00IelqO/XqRhuUepzZi/rK+dTb8g0mXEMzfvBgkVOV6uVD7YPI1gmiA4YH15rTeG
	KfGthMqWnIpNa/RXbDf67UyslXNGoLetgNOdVEjZDuOMRgZEuu8LCwZIjD1kzzv06In2x2QstuR
	+O1kyUmO5zxGQdYEdSb8lkMBdiJim8zKOfWIpcz3JEElH4qc=
X-Google-Smtp-Source: AGHT+IFWGNjnITCGL9K3WGHZ94acrulLHw99byAKrkWthX/4eBTvyk7pidByofWIBTo30kygEICiRA==
X-Received: by 2002:a5d:584e:0:b0:3a4:d8b6:ca40 with SMTP id ffacd0b85a97d-3a4f7a659e5mr12827273f8f.25.1748931631884;
        Mon, 02 Jun 2025 23:20:31 -0700 (PDT)
Message-ID: 
Date: Tue, 3 Jun 2025 08:20:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] automation/eclair: update configuration of D4.10
To: Stefano Stabellini 
Cc: Andrew Cooper ,
 Stefano Stabellini , michal.orzel@amd.com,
 julien@xen.org, roger.pau@citrix.com, bertrand.marquis@arm.com,
 federico.serafini@bugseng.com, Nicola Vetrini ,
 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 03.06.2025 03:00, Stefano Stabellini wrote:
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -72,11 +72,16 @@ they are not instances of commented-out code."
>  -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."
> +-doc_begin="Files that are intended to be included more than once (and have
> +a comment that says this explicitly) do not need to conform to the directive."
>  -config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* This file is intended to be 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$)))"}
> +-config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* Generated file, do not edit! \\*/$, begin-3...begin-2))"}
> +-doc_end
> +
> +-doc_begin="Autogenerated files that do not need to conform to the directive."
> +-config=MC3A2.D4.10,reports+={safe, "all_area(all_loc(file(^xen/include/generated/autoconf\\.h$)))"}
> +-config=MC3A2.D4.10,reports+={safe, "all_area(all_loc(file(^xen/include/compat/xlat\\.h$)))"}
> +-config=MC3A2.D4.10,reports+={safe, "all_area(all_loc(file(^xen/arch/(arm||x86)/include/generated/asm/.*$)))"}
>  -doc_end

I didn't look at the others, but at least xlat.h should be easy to take off of here
by having it have a guard. I guess I'll make a patch ...

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 06:33:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 06:33:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003978.1383613 (Exim 4.92)
	(envelope-from )
	id 1uMLCz-0007N4-VL; Tue, 03 Jun 2025 06:33:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003978.1383613; Tue, 03 Jun 2025 06: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 1uMLCz-0007Mx-SP; Tue, 03 Jun 2025 06:33:13 +0000
Received: by outflank-mailman (input) for mailman id 1003978;
 Tue, 03 Jun 2025 06: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 1uMLCy-0007Mr-8x
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 06:33:12 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20604.outbound.protection.outlook.com
 [2a01:111:f403:200a::604])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9c811d1a-4044-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 08:33:09 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by SJ2PR12MB8846.namprd12.prod.outlook.com (2603:10b6:a03:549::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Tue, 3 Jun
 2025 06:33:03 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8792.034; Tue, 3 Jun 2025
 06:33: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: 9c811d1a-4044-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=hvkWMpbt00tH3TQ2/WViuCTdR/amRn0Z7PIlb9zZEjaerxQCSCqU17H2nrmKcg4dDt+3nS7LsKBB2/brxIZ3+fUEnkpe7HAryfupeU74XUb9lgUsc8Lj5sONv3qqo8RsCw266TVO/lv47CfPcl8NySUMbjhHZSyGsypQYNJMGKK/Afz4v6nYnECfiD3fJNj94ABZCuw+yycV5Xtb8X3mu9QKxo3beIQ0FMd1+MFLFID/WmXb5yIabyMbiNi3e2K8+Fqalk2NEboyk1LcyTJpz1griRIFzNV48eSISqo23JUO3oYrcaWBfMbAfvG9ZaTbRzup0ULx+M9+JlN1/gfQZg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=FHibUciVhTMqdrtGQoC9wIYjBHXIHzpKrEyjWLC6C+8=;
 b=xHkoMlORXynFnDXcFYxgVxkZlkUX9eVu47DeZ2DyS2BiMg+0yjBGE4eZJd6LSD/Cmo6e7+5tigp3l1JR/351suLNOt37/rJVhyl4Bq0W0QTS2761z302RhQ56dKu1oOykY/ydHYR1n/S0NqaeAscG9o3IBpohoxYot0m9nCRTf+BtCRYpwcEY8mP+vWy33dXhGYYFvL0qK4nkruyH/R+WOa/art6x4CY6hB/gq5HMVrFLu/zya+jOb4fTGi3Cx2JZlc4PChcoj3DqMv95rm8MAcHyeVK3YzzmRK1ktbSoV5t6n0hiRs84QkgmdUnUUlNA6lAjxTLJ2IpyfnU/TPPtg==
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=FHibUciVhTMqdrtGQoC9wIYjBHXIHzpKrEyjWLC6C+8=;
 b=2BzELmmHrgeCf6tibPIDk1YoECAvHxs9yV9LUKMEnigxw3/8Go/n7y+js5r09//y1Et4bIzr1ZXmKBMrWNdB4qVbMaEznjbsNCKtUeGKRIacD7uop4ZxxTw6BMmgvym6tBdGflTmrzWUFFUqSnnFmFdjQKL9yfiRf+NolDAl7YE=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <3e8391b7-3b3e-4092-9689-ad0c94059571@amd.com>
Date: Tue, 3 Jun 2025 08:33:00 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 6/6] tools/arm: exclude iomem from domU extended
 regions
To: Stefano Stabellini ,
 Stewart Hildebrand 
Cc: xen-devel@lists.xenproject.org, Anthony PERARD
 , Juergen Gross 
References: <20250508132040.532898-1-stewart.hildebrand@amd.com>
 <20250508132040.532898-7-stewart.hildebrand@amd.com>
 
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: DB8PR03CA0011.eurprd03.prod.outlook.com
 (2603:10a6:10:be::24) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|SJ2PR12MB8846:EE_
X-MS-Office365-Filtering-Correlation-Id: 4ff1ec9a-6341-4cc5-2dc7-08dda2687e1d
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?UXRoYWlxOC8vVEtaNXRrc2ZiUGJkK25jcGVCRHM4bGFpNjVQYWJvOWExaTRw?=
 =?utf-8?B?WTY5YnpzSXJJbE9zTEFlSkRPNWl3OUZYaVFnZ29HMTFZNFFnS3RQUnlVWk5j?=
 =?utf-8?B?dTczaVhlRlBGakR4dnNBa1Q2aDV6K29VczNqZWUyNUUwMksrV2VlV091TnA1?=
 =?utf-8?B?V2dWNDBFY0JkNE9Ra1p2dmRRRVpYd2VEQ0h0VTZUV2p4MENKS0RVbW5Wamw3?=
 =?utf-8?B?V0J6enlhdVV1TExjV2dFeE5Ub2ZGbXpzYlh3VEc2OUF6Y1ZhSlB6djhWR3Rk?=
 =?utf-8?B?STVzMlFBTFhGdnZoTzcycitEdVpMbDBRdjNQVUlUYWdVZkR0eEJuRlA0QXRI?=
 =?utf-8?B?SkNIUHFLRStjV0c3MWVKYlV1VkVDNXo0VmFibWE2S0xDOXQweUV6RTUrU3lI?=
 =?utf-8?B?K2h6dGUxV2FYc29HVndpUGpjZEFhWktmajVpbFd4QkFNWjh4M2duaW0xUm5h?=
 =?utf-8?B?WngyTExiRCtmZkVZUXZsNEZGNEwwRHNTaVUxM3d6c05TcnV3Q0ZEUlozMmQr?=
 =?utf-8?B?aFZwTS9iSTlmK0RiUDNBMEw2eXhOMjM4MTZpSzRUZnRPUG1zejljbllFRGlo?=
 =?utf-8?B?eEtvazlwa09tRmlOMzBDa3I0VVo4N0dHR3laZGxNVHB5b2NyRGY3RW1UcWY5?=
 =?utf-8?B?YVd6bXFvTUNoemc0T1kvcVd3ZGQ5NU5jSSttWlhsL2VKcnhLeE5jSjJMZStZ?=
 =?utf-8?B?dTZGM2VCdm5yYkVPUFFhS04yNEE1YnZGWVRaWUZrUnpmM0JKOVcvNmRzS0xk?=
 =?utf-8?B?cXlqVmwrR2ZJTEJiREtTNGNQYTVYSnFCS25rYVdkTHJtbGdLQWZrTGtBVDhQ?=
 =?utf-8?B?THB6RjdaeVpiZVN3N3BBZk5EMGFlQncwUkFQM1liLy9SR2RzS3Q5eVg0cUR5?=
 =?utf-8?B?U2FDYXFlclV1QjBJZkowdGk4eXRUclRtYmxMVEg0Y21JWjAwekNacDBTRWNC?=
 =?utf-8?B?R3cyRWQvRnRiY08vYjc3cnhHUHB1L2YwQ3NtZUZBSzE1YjZvNjVSdXllRjUx?=
 =?utf-8?B?Q2o2Z2hJMlo5em9rdFU5NDgyd1lSYnBjT3FvOE9kNzhJd1dwcGJJY1lkMDAw?=
 =?utf-8?B?OStqM2xSZ2RkNDdUSEYwWU5SbkVBcTliUXN2am5nSVRoMlVuVWJHdDByTmY3?=
 =?utf-8?B?WmM1TmVRdUxLV2NzbCtma1RjOTM5OU9UMG5UbVdPOERLcnYzejZPWjZjakRt?=
 =?utf-8?B?cjdhbzBmWXZUN2crRDRNdEczNkM0WkdDbmpwUktwKzBEQ3BMM1luTDF0Nklu?=
 =?utf-8?B?Vm5jVzAxSXBaR1ZIVVpGY0hhUFBoRkhkYmdHNHVmSVlZbTBVRFI5UWNPWHNQ?=
 =?utf-8?B?NWFldWZoOVNPd3lVZWc2ZjF4UXhHdTBhMkJJM0wwYjBhS1oxa3FsTVg2R2h5?=
 =?utf-8?B?Vm5FTjdSMDZSQWRJYTROVDMwZW1kTWF0TDhmNG4xUDFqQzVhT0o1c2VZWXA5?=
 =?utf-8?B?d2J6dkpNTjZhNHZrNVZWV2ZGeGRVUmJPaWNSRnV5MjU5RWgyZ3JubnFqU0lH?=
 =?utf-8?B?Z3BOcFFzMnh5NEZOVW45YTVDa3VJU21yLzNyT2hTT1RtTGRERXp3cWJra1dk?=
 =?utf-8?B?eStTdzJOcXJEbTJ4NlUrSUgwNXJpMmpITDJtWnB0d1dQckcrZnNHVmk4RHlN?=
 =?utf-8?B?Z2R6cnNhbTJ6UjRTZGV4MlY5QVpsWlhmcWRnRlVGcHUwL2k1WnVHSTQyNkp4?=
 =?utf-8?B?elhWeGFYTzFEcmdJUUJDbzg2d09CTUhTMFVmVnNTd1dXd29CUCtUKzgzb0NK?=
 =?utf-8?B?OE42cWVYSjMyL21mSGJ4UmYzSDhMQVdjeElUVUpPZjZoelBDOEVybFB3MU5J?=
 =?utf-8?B?WFJ0Sm01RGhwRkNvNmMvWmRvZXM4MFdxOXNhMHhVdjYxTUVQZW9QcUdjNm1i?=
 =?utf-8?B?Y1QvUVV0Q0RZNlF6THRoQzVPeDNmMGtLbnZxOGNuY291V1JFT1NRdkR0blBY?=
 =?utf-8?Q?HfL4XJCsZgA=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.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?NmV1WVFoSmwrd3lPbE93SFlMK1plY2hCNVBlT1ZoS1Q2Z1pGYXBnNWVaQjRD?=
 =?utf-8?B?NTQyd0kyL1B2bWxuWG1Ra1hSV0RzTzUxbzJ2MTBZT3VrOFEyT0c1eFFaUDFB?=
 =?utf-8?B?SFd4dkQ0QklheE5paGxsSDFCZTgxZFR6ZmRuWS9PNU90bjFmc1F0ck52YjRM?=
 =?utf-8?B?c2ZPZjl1MXp5YVBxWjYvTEJIaXRXaitPdjNCLzFKMHV5eE1yRGx3NEpTSU1M?=
 =?utf-8?B?bkMxTXYwNm5yWm5FQjhKaTdQQWlsTmtnbjhzSVBZZGprQzFrVm1qaSs1SHgx?=
 =?utf-8?B?d0pXVllHeG5UdTRJNWxlR0x3N0QxakVmVWNzdS9HZitadGMyRWx2T0xtdXNF?=
 =?utf-8?B?Y2VOamF5RXlzUzZyLzBKR3hKbjRLbXNobjVWUk42bzNLQXVBOTdseW5icGo3?=
 =?utf-8?B?Y29PTGExTjMxR0tBQzJUdnR3UGJ0QkhjcEpiWlhYd3RxT0c5ZkxWbkRtTTVM?=
 =?utf-8?B?QVVyUDRTSkxLM0M5YlZ4ZWlzMDV6R3lRNTRCQkRheTF0ZFhFdVBVZTFIOFEv?=
 =?utf-8?B?MittYVkrZFo2TmZGUzFmUko1bmN4aElHb0FNYzRxOXhoanh6eEhIZ2swV2Nx?=
 =?utf-8?B?TW5GSFFrdkhCd1N5eXBMclQ5cWtPblBOWVgzOHIyWG1TRkdRNFNHbUxGa1lr?=
 =?utf-8?B?V3ZhYnVFdmFQZG9DcVB2MmJ2dnoxT0U5SHJLMUhiSmhrRm5LbTg0RUlRNS91?=
 =?utf-8?B?Z3Zqb1RuaUdSYzJqYkhFdW5tWkxCR252WDlQa1V6VWZ2bEQwRkRMQVFZSUJt?=
 =?utf-8?B?QzJ2QzBrZ1JRUzU1bzBqY3NKNndQNzlEWUdqZkFWRkJnZWtJSmxYZGllc3Zn?=
 =?utf-8?B?eE50ckJXUkRpYm1hTG05TFFZYUtGR1hEWGxxbVdUYU43Zk9KS2pEMXEwU1NQ?=
 =?utf-8?B?R0JubnRTcEphYXMrOW90L2cvZWlDVEVENlMxdjFqbDlrd0lXNkw4TXdUbXFE?=
 =?utf-8?B?WnVXOVRrd1A3NnFidXlodVRHNDBlVHk0TTRpUXp1bWVKWTBrSXErSW45L0NF?=
 =?utf-8?B?R3lDMVNrL0s5ZnE1L0tOQ3lGcitsVU53aTRWcFJJditrUHN2dytNNmVNRThC?=
 =?utf-8?B?U1FmSFhoOHhPUG5OQ05VOHlNbGVGVGNoZStuNzJ3OTNZZXRsMHRrVStVYU4r?=
 =?utf-8?B?STVMcXJ1cUxGd3p6TnBQWnpsUnd0ZlNhNGczNVpDVURRSXJ0VXpVK0VJOGpz?=
 =?utf-8?B?ZXhUQjZVakN5VVdUMnAyVlNJWi9GRDVraExIcmJLTnVKYlFXamJWOE5tTUEr?=
 =?utf-8?B?d3Z4anVFVUNhS3lwcEtFOStINCtoS281UUtJZE1iS2VqQmNNRS9MRFJ3VWxj?=
 =?utf-8?B?TDdncUpTZWo5YWpYTDJMT3BNaXJlbjNjT05heDgwdnVoVkViR0dvRWwzbXEy?=
 =?utf-8?B?RGlZeVdrb1I3TVZlNzQxNUJqOXNpK0lhK2JzSnFIQXFnRFRscVR6N1dHdDhv?=
 =?utf-8?B?RXFuRjdqdDVOSmtzOGZCUDE1VFVUVzdVZGNEZWQxRzdPa2pRZExoa24rSlBt?=
 =?utf-8?B?Z2o1RU9GblppQXRyaFRNMVUra3VaeWdhU0NpQ0NkMUl5cG9Qb01abXRSNTFB?=
 =?utf-8?B?b1BGUmpZSHJHUVpBS3o2N2R3d0xmNS9Ia0hoR0FkTExVVkQwU3ZtbTAyU2gw?=
 =?utf-8?B?bCtlTEpwWGh3YWp4U1Y4bGtQS0hoSkIrbGRYWWxqd0hQLzZIaDJtTW91ak5C?=
 =?utf-8?B?QWYvbm5MVHNXbTlRbkViUXplR1lCQmpMcnRqbDcwdlo1OWRaT2VJNzZaOGla?=
 =?utf-8?B?TEVYZzdiSnVRbEd6ZFdJTTBlNW9UUHFOV2dwd1laRzlNc3hleEN4SDRaNjBB?=
 =?utf-8?B?Q1VLYU9GYy9nN2xmT3FGdy9weGErT3FFWklRVk5EbkNqM1J2TlpsSXQzMHpM?=
 =?utf-8?B?T0NmM2VjaXFkVWNXeWFYbmRCZG9FZEFnUitncWowMlpTcmMxTlRzZ2hRL2JZ?=
 =?utf-8?B?YklSNE9tcVNrV1pnVWRmR2IyN3VXVmN0U2txQWgwTzRFMUl5RTN6dEZUN0Yy?=
 =?utf-8?B?Y01qMGZ5NWl1aUEyakEya21EYTdidU0rRytRU0tTY1l1MngyOUFnZE5XcldP?=
 =?utf-8?B?UWRsaUFMOEZXc25DYXBhVlFZRzczL0VSMEgza0drcEl5VGxROCtEQmp2WmhQ?=
 =?utf-8?Q?DPBA=3D?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4ff1ec9a-6341-4cc5-2dc7-08dda2687e1d
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jun 2025 06:33:03.5721
 (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: 7EdMzB2/g4PWo8JLh2vzCOwY7DDe54qQ5mADWaVdLHpWCEQzA57YmhODNoj6X0QM
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB8846



On 03/06/2025 02:38, Stefano Stabellini wrote:
> I plan to commit this patch, unless someone objects
AFAICT there is a new revision (v3) that has pending comments:
https://lore.kernel.org/xen-devel/20250513195452.699600-1-stewart.hildebrand@amd.com/

~Michal

> 
> On Thu, 8 May 2025, Stewart Hildebrand wrote:
>> When a device is passed through to a xl domU, the iomem ranges may
>> overlap with the extended regions. Remove iomem from extended regions.
>>
>> Signed-off-by: Stewart Hildebrand 
>> ---
>> Not sure if we need a Fixes: tag, but if we do:
>> Fixes: 57f87857dc2d ("libxl/arm: Add handling of extended regions for DomU")
>>
>> v1->v2:
>> * no change
>> ---
>>  tools/libs/light/libxl_arm.c | 118 +++++++++++++++++++++++++++++------
>>  1 file changed, 99 insertions(+), 19 deletions(-)
>>
>> diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
>> index 75c811053c7c..8ae16a1726fc 100644
>> --- a/tools/libs/light/libxl_arm.c
>> +++ b/tools/libs/light/libxl_arm.c
>> @@ -798,6 +798,8 @@ static int make_timer_node(libxl__gc *gc, void *fdt,
>>      return 0;
>>  }
>>  
>> +#define MAX_NR_EXT_REGIONS   256
>> +
>>  static int make_hypervisor_node(libxl__gc *gc, void *fdt,
>>                                  const libxl_version_info *vers)
>>  {
>> @@ -821,7 +823,7 @@ static int make_hypervisor_node(libxl__gc *gc, void *fdt,
>>       */
>>      res = fdt_property_reg_placeholder(gc, fdt, GUEST_ROOT_ADDRESS_CELLS,
>>                                         GUEST_ROOT_SIZE_CELLS,
>> -                                       GUEST_RAM_BANKS + 1);
>> +                                       MAX_NR_EXT_REGIONS + 1);
>>      if (res) return res;
>>  
>>      /*
>> @@ -1517,17 +1519,29 @@ static void finalise_one_node(libxl__gc *gc, void *fdt, const char *uname,
>>  
>>  #define EXT_REGION_MIN_SIZE   xen_mk_ullong(0x0004000000) /* 64MB */
>>  
>> -static int finalize_hypervisor_node(libxl__gc *gc, struct xc_dom_image *dom)
>> +static int compare_iomem(const void *a, const void *b)
>> +{
>> +    const libxl_iomem_range *x = a, *y = b;
>> +
>> +    if (x->gfn < y->gfn)
>> +        return -1;
>> +    if (x->gfn > y->gfn)
>> +        return 1;
>> +    return 0;
>> +}
>> +
>> +static int finalize_hypervisor_node(libxl__gc *gc,
>> +                                    libxl_domain_build_info *b_info,
>> +                                    struct xc_dom_image *dom)
>>  {
>>      void *fdt = dom->devicetree_blob;
>> -    uint64_t region_size[GUEST_RAM_BANKS] = {0}, region_base[GUEST_RAM_BANKS],
>> -        bankend[GUEST_RAM_BANKS];
>> +    uint64_t region_base[MAX_NR_EXT_REGIONS], region_size[MAX_NR_EXT_REGIONS];
>>      uint32_t regs[(GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS) *
>> -                  (GUEST_RAM_BANKS + 1)];
>> +                  (MAX_NR_EXT_REGIONS + 1)];
>>      be32 *cells = ®s[0];
>>      const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
>>      const uint64_t banksize[] = GUEST_RAM_BANK_SIZES;
>> -    unsigned int i, len, nr_regions = 0;
>> +    unsigned int i, j, len, nr_regions = 0;
>>      libxl_dominfo info;
>>      int offset, rc;
>>  
>> @@ -1542,20 +1556,90 @@ static int finalize_hypervisor_node(libxl__gc *gc, struct xc_dom_image *dom)
>>      if (info.gpaddr_bits > 64)
>>          return ERROR_INVAL;
>>  
>> +    qsort(b_info->iomem, b_info->num_iomem, sizeof(libxl_iomem_range),
>> +          compare_iomem);
>> +
>>      /*
>>       * Try to allocate separate 2MB-aligned extended regions from the first
>>       * and second RAM banks taking into the account the maximum supported
>>       * guest physical address space size and the amount of memory assigned
>>       * to the guest.
>>       */
>> -    for (i = 0; i < GUEST_RAM_BANKS; i++) {
>> -        region_base[i] = bankbase[i] +
>> +    for (i = 0; i < GUEST_RAM_BANKS && nr_regions < MAX_NR_EXT_REGIONS; i++) {
>> +        struct {
>> +            uint64_t start;
>> +            uint64_t end; /* inclusive */
>> +        } unallocated;
>> +        uint64_t size = 0;
>> +
>> +        unallocated.start = bankbase[i] +
>>              ALIGN_UP_TO_2MB((uint64_t)dom->rambank_size[i] << XC_PAGE_SHIFT);
>>  
>> -        bankend[i] = ~0ULL >> (64 - info.gpaddr_bits);
>> -        bankend[i] = min(bankend[i], bankbase[i] + banksize[i] - 1);
>> -        if (bankend[i] > region_base[i])
>> -            region_size[i] = bankend[i] - region_base[i] + 1;
>> +        unallocated.end = ~0ULL >> (64 - info.gpaddr_bits);
>> +        unallocated.end = min(unallocated.end, bankbase[i] + banksize[i] - 1);
>> +
>> +        if (unallocated.end > unallocated.start)
>> +            size = unallocated.end - unallocated.start + 1;
>> +
>> +        if (size < EXT_REGION_MIN_SIZE)
>> +            continue;
>> +
>> +        /* Exclude iomem */
>> +        for (j = 0; j < b_info->num_iomem && nr_regions < MAX_NR_EXT_REGIONS;
>> +             j++) {
>> +            struct {
>> +                uint64_t start;
>> +                uint64_t end; /* inclusive */
>> +            } iomem;
>> +
>> +            iomem.start = b_info->iomem[j].gfn << XC_PAGE_SHIFT;
>> +            iomem.end = ((b_info->iomem[j].gfn + b_info->iomem[j].number)
>> +                         << XC_PAGE_SHIFT) - 1;
>> +
>> +            if (iomem.end >= unallocated.start
>> +                && iomem.start <= unallocated.end) {
>> +
>> +                if (iomem.start <= unallocated.start) {
>> +                    unallocated.start = iomem.end + 1;
>> +
>> +                    if (iomem.end >= unallocated.end)
>> +                        /* Complete overlap, discard unallocated region */
>> +                        break;
>> +
>> +                    /* Beginning overlap */
>> +                    continue;
>> +                }
>> +
>> +                if (iomem.start > unallocated.start) {
>> +                    assert(unallocated.end > unallocated.start);
>> +                    size = iomem.start - unallocated.start;
>> +
>> +                    if (size >= EXT_REGION_MIN_SIZE) {
>> +                        region_base[nr_regions] = unallocated.start;
>> +                        region_size[nr_regions] = size;
>> +                        nr_regions++;
>> +                    }
>> +
>> +                    unallocated.start = iomem.end + 1;
>> +
>> +                    if (iomem.end >= unallocated.end)
>> +                        /* End overlap, discard remaining unallocated region */
>> +                        break;
>> +                }
>> +            }
>> +        }
>> +
>> +        if (unallocated.end > unallocated.start
>> +            && nr_regions < MAX_NR_EXT_REGIONS)
>> +        {
>> +            size = unallocated.end - unallocated.start + 1;
>> +
>> +            if (size >= EXT_REGION_MIN_SIZE) {
>> +                region_base[nr_regions] = unallocated.start;
>> +                region_size[nr_regions] = size;
>> +                nr_regions++;
>> +            }
>> +        }
>>      }
>>  
>>      /*
>> @@ -1565,16 +1649,12 @@ static int finalize_hypervisor_node(libxl__gc *gc, struct xc_dom_image *dom)
>>      set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
>>                GUEST_GNTTAB_BASE, GUEST_GNTTAB_SIZE);
>>  
>> -    for (i = 0; i < GUEST_RAM_BANKS; i++) {
>> -        if (region_size[i] < EXT_REGION_MIN_SIZE)
>> -            continue;
>> -
>> +    for (i = 0; i < nr_regions; i++) {
>>          LOG(DEBUG, "Extended region %u: %#"PRIx64"->%#"PRIx64"",
>> -            nr_regions, region_base[i], region_base[i] + region_size[i]);
>> +            i, region_base[i], region_base[i] + region_size[i]);
>>  
>>          set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
>>                    region_base[i], region_size[i]);
>> -        nr_regions++;
>>      }
>>  
>>      if (!nr_regions)
>> @@ -1626,7 +1706,7 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc *gc,
>>  
>>      }
>>  
>> -    res = finalize_hypervisor_node(gc, dom);
>> +    res = finalize_hypervisor_node(gc, &d_config->b_info, dom);
>>      if (res)
>>          return res;
>>  
>> -- 
>> 2.49.0
>>
>>
> 



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 06:41:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 06:41:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003985.1383624 (Exim 4.92)
	(envelope-from )
	id 1uMLL1-0000cr-Pv; Tue, 03 Jun 2025 06:41:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003985.1383624; Tue, 03 Jun 2025 06:41:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMLL1-0000ck-M6; Tue, 03 Jun 2025 06:41:31 +0000
Received: by outflank-mailman (input) for mailman id 1003985;
 Tue, 03 Jun 2025 06:41: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 1uMLL0-0000cc-Ib
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 06:41:30 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20607.outbound.protection.outlook.com
 [2a01:111:f403:2414::607])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c6de7e71-4045-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 08:41:29 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by DS0PR12MB7678.namprd12.prod.outlook.com (2603:10b6:8:135::22) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Tue, 3 Jun
 2025 06:41:25 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8792.034; Tue, 3 Jun 2025
 06:41: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: c6de7e71-4045-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ERWlHnt4ZDS74VEkHMLqWQSLYcmKAHbuOlGSjPgfr6xetKuvFbpOYTjWbWtD7kIeh7TXDPdBTyxZxGcvENaIzlBl7PhOeS3C2gcRuTTau/NMres71dif65CkzWYQIWWtU0mSpJ4lVdqzAY4hT2srm/2tyvcAyZ8NbuJW+pe50PgTn4aGkqm1YFgDDAi3KWuDAgwDt+DwYGZnhK0yesofYNePoF6DcA0e8tE7yCs9zRTktAbz2ox0el7rU6z/miiF83aBm0KeDYJrDUCs+NVyYSnzhVTb2XrdQ0g8dbot1XN5IeIghYCaPN6O6vWECHs34aoSoiKAKEbrrfJ+Jsbqaw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=TOjuW9QwbIty0CAr6oR6MYezSB5oFWNTZo6fdq2u8t8=;
 b=aR04URdDH3aiyxo/azqeXE1c4vwbYTeZ6vfBtZ+ng6JvIOmP0TqvbRXtbR5dWuKmEjiRz3FnByC4koKR9CWY5+U5OpTVjk9TkyE2wU30QtbDcwPMu/TGT/o5Nq8U3tUK3//BxXIVj6C1L5YRoe+83kBQ+MNk3WgU6P+J3t49ENczIjV16KT7nWxiXP91CMeRBzRR8AjS/Ew048qAwfS2rhAbhXV0sXAM3cHALET7ZIvnODyEBz4hUmkGwzKoc46VgNfanSfGbNPNUDGxio2zUTxUeNGdxf4c1oEJ5eWqc/IxvcIhYwAcZclKc3Q5BAKyhhEYtYr3vQs9RDjUuRH+tQ==
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=TOjuW9QwbIty0CAr6oR6MYezSB5oFWNTZo6fdq2u8t8=;
 b=hGLZedIamzUlB6c7w0k3c2KthIQ79wRAxjv1MqvMSHmf20mpT1otgl7jJUuVZr5PfGU51rqMriRDJKmVrw5b3PcyOdN9hNGx7YEq9SqijLeYVN1i9WpiNmxkeDrAAflLaDoKzd4gOO1HRefPd7dOkBuJ/sWDXVMFeXcXzeNkjWI=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Tue, 3 Jun 2025 08:41:22 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] tests/vpci: Use $(CC) instead of $(HOSTCC)
To: Jan Beulich , Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD , xen-devel@lists.xenproject.org
References: <20250602150929.10679-1-michal.orzel@amd.com>
 
 <811c154c-d7d4-480c-8898-a21f62f2cf6a@suse.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <811c154c-d7d4-480c-8898-a21f62f2cf6a@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: FR3P281CA0004.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:1d::23) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|DS0PR12MB7678:EE_
X-MS-Office365-Filtering-Correlation-Id: 804c88e5-2458-487e-f48d-08dda269a908
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?K1hoQWY5NWZ6Tms4ZThGT0ZCUWZ1eHQzWjlYajZadVIzcGRySUUxUDU2NU9O?=
 =?utf-8?B?YlJ0aXBOODEzRk9kLy91dVJCU2ZxMVBGcUVKeEZaZUIvUXJWcjZRb25Vb2to?=
 =?utf-8?B?NklTNWJsS0w0Z0pIOGJUVEwvL1FNRzJlamhaZ05CUXppR2RnUEI2WnRlRDAz?=
 =?utf-8?B?R0IyT3Y5NmQzMmQzWG54QXVKckxHS0lreis1ZkNyR24vOXlvejR1ZVRvczM2?=
 =?utf-8?B?S0NXYm9GMWdZTEluZURvNWNZVE1GOCs1cWlMSEVRUlovWHpwa0lOQlM4bTJa?=
 =?utf-8?B?Vkllc0hvNm9QOFIvcTdVTmROb1kyYXUvbzljajdPNWZMbGNnSlQ2UE5XbEVp?=
 =?utf-8?B?NkZIS090MnBXOUtpdHNTamdPOERBQkNqS2QwRFVwN05hK3d3aFQvMC9GYUlN?=
 =?utf-8?B?SFEwMGdUZFlWbkRsRkVXU3hqWGFOUDBDOWRHUG9kR0NiRzVjSit3TzVkaHhZ?=
 =?utf-8?B?NlZBaGJSQkh2VldXbFMwYlFMRFp3UXluZFMwcitNRm5CT1FhcVlQemx4M0R0?=
 =?utf-8?B?ZHg0SDFJekFLd1dSa2F3d1BnUEgybkJFbUhkUVM5MTEzcHRsNDg2UVk5bUpR?=
 =?utf-8?B?aUdWNTNTY3FyR0xlMVN2b3JVU2Q0cXVlNmk5UDR5M0pJY2dmYUdSVWZRMlVJ?=
 =?utf-8?B?aHR6UlliRUZYcEtvTTU2RzhBYTNXYktPUVUyOVJreXppdGIvSEN2OCthREZa?=
 =?utf-8?B?SlcyOUM3NkZGUVAwaHE5YU9teTN6aGhFeituMWpRMm1kVi9NZ05SVS9YMUp1?=
 =?utf-8?B?VEZjeVJ1QkdjcjY0NG5sQ1hLUUpYZVlVd1NVUEpKYy9xaUVzSlUyeVRqWDBn?=
 =?utf-8?B?endBaGhMQUxSdGN5eWxnaWx0NmVYTE1jR2hzL1gycCtMUzM2eXlRT3NzS2pT?=
 =?utf-8?B?WHRzZUx4U0dnczVBS0VvNmlwZHNZKzM3S3pTN0xhY2duQ3NiNUZwTkhBRURE?=
 =?utf-8?B?SUVwQmtQb2d6bjU1b2FTbG5Va0tEY1h0L3VsNUxwSlQrc3hhOWRSOTdoRVlF?=
 =?utf-8?B?TXdRbVpVR3pzbTV4VzRnNU44OERKMXlyT0dDQzQwN0Z5TytjazFkRFJ3RGYx?=
 =?utf-8?B?Qmc2RVhuNHVUMXo5ZDRQQ0FoMWxFcFdiazZjTEV1ejNRVUNrQ2RRUU1ZOEkx?=
 =?utf-8?B?T2ZXaVI5ZjkxaDk5SGNPY0tOcXhucUlkSzNXSHBOZkZvaUNWdWc3dDJaWVpo?=
 =?utf-8?B?U1c3ZEp6MlcxeUt5Mi9yckM5d2JzTzVVU1hzZllZN3R2RG5kK01NYmY2UWZv?=
 =?utf-8?B?N0tTY0Z0ZWR5VkpkTnhsS3NGL1ovVlVMWGJmTENwWVE0NXM1S0QyZkZaL0RQ?=
 =?utf-8?B?VEFQbmpyMkU5YXo5Uk5NR3h4L3l5WUtjMWczdUNVemhKSVd3VldmN3VDbGls?=
 =?utf-8?B?QS9WZDZjRzM0bWJSSUlxK1UvTC94Y25EeVI2Y2Jyck9EbnNNL1p3bW5yRmFP?=
 =?utf-8?B?WDkrbisveUxKbTIrUU1nR3d1Vnh3SmQzUHBBNFlXU2loVmxsZlNCR09uQWF6?=
 =?utf-8?B?dFZIYmJDMVpLMFZuOFozQlV2dnE5bmRUL2Z0Z1BLNVlWQUZ1WjJGWUlGSVFt?=
 =?utf-8?B?cVkrWDdIOG9UQTVlMWVpa1dPK3dtbmZFR1pUY2k1Sk9UNUpVUzYxNUZZVGRR?=
 =?utf-8?B?VHR3ZlZxS1V4dVlMZXp4dmxKWHlydUxScWM4RmlIVVY0NHVUM0JuRE5BQmkz?=
 =?utf-8?B?U1RkRGprcDhaWFlrUnloeEU3dkMvaDZ3ZGUvc2grSzB6YWY3a3VZNXlPbkhm?=
 =?utf-8?B?bVFjTnZzK0l4eE5uNllDcDI5Y0pUNC84QkREaGxFOWRsK2szTDZVeDFmSyt4?=
 =?utf-8?B?bnM0eVlncVFLNWVMYmFvS3ZwQ242ajcrd0JZRmlucXNBS0l1b3ZJMXpVRGVq?=
 =?utf-8?B?TWRyMi9BQk0yMkhZdjJpVHlYM1pKQWdRZnB4YmFLNjRaU0RYbVpsdW1DN3do?=
 =?utf-8?Q?1h5IRtxJrhE=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?WDFtRnpUUHVaVTdNK2xPb0dBclJIdTJGZGpKR05mZW82MkF2N3YxZllYUm85?=
 =?utf-8?B?ZFBtZHFsZ0lTeXdaaFp0bU1Celg2bEEyNFhyOVR2bEFJeUNqU29XWVpLQWw5?=
 =?utf-8?B?SWpCbmNwSDM1VzNpSHRYWWo0UDJZcFdNVXJaamFlM3l5cTMxOE9tbVVnZG4w?=
 =?utf-8?B?QXZRVmorWjRUUUFsc1o0T2dyZ2d0WUhSMjFQcGx6R1djelVLNjNVNXZsbmJl?=
 =?utf-8?B?dm14VXBmQ3pJVHZJWnQrZmEyV1FicnA1Mk5SVW9wc2VCSmtGOVh5aGJXOGcz?=
 =?utf-8?B?cUF1NldTRG9TRzdYUk94ZGp6MHljZlA4QUpjM2FrWjhadzJpUmZzMEt0anZ1?=
 =?utf-8?B?MWxMaGtrQkVadUNHZW1GSldCekF1ZFBWeGlIZTVJdk5oemJ5MU41SG9mUERB?=
 =?utf-8?B?WjY3eHNSaFNwajh3TEQ4RlJYS3YzbDIwM2RxZndlQ1Z2bFI4cTJVUGVKMXBn?=
 =?utf-8?B?MlVCcjl1aTgzYVg3K3N2T1llR0FheFdTdUpoM3dSWThqeWJGRkNmMy9VZHI4?=
 =?utf-8?B?QlZBbWZJSTF1OE1rZGsreTduL1VCRkZqQ3RSaWFIS0hHYXQxNGphOTZVdTY2?=
 =?utf-8?B?Nkk1Y2dlYnNETmErcTYxVkN0TlhDbkFpcXNYSkdUNGJZOHZHVlRmK1IvRlVH?=
 =?utf-8?B?Sk9SMGc3dVNqbTdiWnp4cUdjTUpPZnlpQ0E1NFd5ZVY4L1BTaWpwcUZHeWNz?=
 =?utf-8?B?b1dVVGFuSGF5SjFhWkY0blM5ZHhwWk1xMEYyZmwvenN4TmJ1MHowTWxFTnFM?=
 =?utf-8?B?S1kvMFhreVFuUG8yL2xqd2dyd3ozOW9qZUJxU25jS0dFN1kyLzlBeGI4SzUr?=
 =?utf-8?B?M0xGQ0lQTFNMRDBvaWlPTE4yQmFoL0xQZWk4OUNBb2JkbWdYS2tmc1ZWcExn?=
 =?utf-8?B?bXpPTk9sbHJaTnJUU3JtaHVZdi9aUGtDejNkeFBxSnFYUzdERmJxNHlvVXQ2?=
 =?utf-8?B?dVFJdVZKOW9aNkMrZFJJRHF5ZXdIbWE3dVdIbTFReWRnTVhTS3ZteGU2dlNi?=
 =?utf-8?B?THBERC9ROHY2NFc0SEd5bGt3L1JNbTl3cU5iaVFTL0tlTGQ4RVB5VWRpdUFq?=
 =?utf-8?B?V3ExbW9LdjhQbDRyUVo5WGFKbWI4OHBXTktpbmRRYk5NRGJ2UGJ2aUlvNU1S?=
 =?utf-8?B?YldMTDYrVjNMcm55eDAxOUQyS3l1bzI1SEdDVmN6TlJwekFxS0dxVEFIRktk?=
 =?utf-8?B?TWs4SUMwMVR5NWVydlFwUjVzRmZaRCthTUphV3FrYXhodUc2N2dYaEEzNEZm?=
 =?utf-8?B?SWJ0ZUR1bDVaYk1oWGR3VWRUdllTT3BtcXgxN2FneWJkM1NZOUVpUWNKc2FQ?=
 =?utf-8?B?MjFTa0tvanRoZDRlaE1JZUdwajh2TUtra2RPKzZDQURNRjFLQnNtMXpiMFJT?=
 =?utf-8?B?NEV0aG0yTFJKRGltVEtkQlp6Sk44aU1udGtuVkdJaldHVkdhWDk0TjVYYjls?=
 =?utf-8?B?a1FwYi84aFBwK1lxbjY2ZEdiQ1M3WXpoZmhlWlAxUG5DeXNrOWwxU0twTkdn?=
 =?utf-8?B?d2s3R0NmZkVVTkk5L0lJUGh3bGt5cTFLVWFaNU5OM0hrMDY1aGhyTUFWeS9X?=
 =?utf-8?B?RWhMTUhIMS8zT0lubnN2czhEb1VsaXovNmh4Y3Q1ems3RTJaRExCUW5Da0Jz?=
 =?utf-8?B?MnJEMThPRThwRW5tUStWVDltd2MxVHJMVktFRmxMSU1wUENGK3RuN3czWFAw?=
 =?utf-8?B?Mit5bnJVRUpPcVpNNzZLdFBDOThycm1sbE4xS0VCdWlnT3V0NjFrMkVidEFm?=
 =?utf-8?B?djJYNEYxU2g1VU1BZVNOSHRkOUdYVnoxWjNyTlI1U3RzdXdYYTY5cXpaUFBR?=
 =?utf-8?B?WUc5L0Rrd2c1Q2hDcktQZ29pWXJKUk1SdUlYaUFmR2NMYTROSSsyZjZPT2hB?=
 =?utf-8?B?N3FRWHpFdzBMcC90L1hKZnVObnVxRkpLYWFwR3NYS2N5OFBmQ2czZElmRUZS?=
 =?utf-8?B?eDB1Y3dkbkNGZHFKaDQ0YWx6cExuM0VSTlV0QTdFWlFCZkVpN2xlRUZMTFBv?=
 =?utf-8?B?V1ZJQWJrVHB2VkxDSkkwMXNFb2tKd1IzR21HSG9SN0FNWjZYL2lJbzhtT05P?=
 =?utf-8?B?MzAzWnhHTkRZSlUxWFlnb3QvcDNRUzlEZ1h0MHRwUU0yM1d3RzNyZnNtampr?=
 =?utf-8?Q?VGAoywFR6Dth3k2JsZlAnYUgN?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 804c88e5-2458-487e-f48d-08dda269a908
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jun 2025 06:41:25.1016
 (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: IPbdDk8Mga4kedKGD/O4O79fkYZ8Id3N1AN0cHMG0cix1mywSHPggqF815mhQteT
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB7678



On 02/06/2025 17:50, Jan Beulich wrote:
> On 02.06.2025 17:36, Andrew Cooper wrote:
>> On 02/06/2025 4:09 pm, Michal Orzel wrote:
>>> These tests are supposed to run on target. HOSTCC can be different than
>>> CC (when cross-compiling). At the moment, tests installation would put
>>> a binary of a wrong format in the destdir.
>>>
>>> Fixes: e90580f25bd7 ("vpci: introduce basic handlers to trap accesses to the PCI config space")
>>> Signed-off-by: Michal Orzel 
>>
>> Oh.  This didn't explode in GitlabCI because there's no ARM version of
>> *-tools-tests-*.
>>
>> Can we fix that too please, seeing as there is a real ARM board?
>>
>> Also, I guess we have to finally sort out the CC vs HOSTCC debate.
> 
> I think the situation here makes pretty clear that HOSTCC is almost always
> wrong to use for tests/. The emulator test harness is special in that it (in
> principle) needs a target compiler (CC) and additionally an x86 one (with no
> present representation). The present way of (partly) distinguishing the two
> by using CC and HOSTCC was assigning wrong meaning to one (perhaps both) of
> them. The (or maybe just my) problem is that in the toolchain world it is
> build, host, and target which are distinguished. As per Michal's description
> my understanding is that HOSTCC is matching "build" there, not "host".
Yes, I found this issue while building latest Xen with Yocto. Build is x86, host
is Arm. HOSTCC is x86 gcc, CC is Arm gcc.

I take as this patch is waiting for a maintainer tag? Not that it needs to wait
for some generic cleanup?

~Michal



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 06:44:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 06:44:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1003995.1383633 (Exim 4.92)
	(envelope-from )
	id 1uMLNm-0001E8-8w; Tue, 03 Jun 2025 06:44:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1003995.1383633; Tue, 03 Jun 2025 06:44: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 1uMLNm-0001E1-5w; Tue, 03 Jun 2025 06:44:22 +0000
Received: by outflank-mailman (input) for mailman id 1003995;
 Tue, 03 Jun 2025 06:44: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 1uMLNl-0001Dv-7J
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 06:44:21 +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 2c0a6469-4046-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 08:44:18 +0200 (CEST)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-3a51481a598so153402f8f.3
 for ; Mon, 02 Jun 2025 23:44:18 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23506cd38e0sm80475425ad.138.2025.06.02.23.44.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 02 Jun 2025 23:44:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2c0a6469-4046-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1748933057; x=1749537857; 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=iREsn6hQ3afS1my3XeOX0j8869opqd7CwiKVSjMzsGI=;
        b=N7C6JNgMuOygOD/cVwTWiVNHPurji5qDlkaZCsKAP94vqtmYvRQDFPQX9lRlQ4o5Z4
         8hpSRqEGH8qhszi6SxMxwZoR6nw+sYTh1e/99EJiHaHHyITPY+gBJTfr+tBoTbaZzdmA
         +7Za8tfKeNQqFWnV2DoNRWquLIrNSCdSxFF/2athjoUmikf1YJi82EFQXNig/D+4XV7m
         X485xWP9nAATYxUjlJ/XxLH6D3uTSP1/J9RB8BAWyikrPr+l48V+kR1yl3xQfvhwcGwl
         QJeichUInzKRMsNQV/EUT1P9nf+BAPeaigZKw59Y3oPSu88FfnkeL93hb+xA+bGTRd9p
         7xVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748933057; x=1749537857;
        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=iREsn6hQ3afS1my3XeOX0j8869opqd7CwiKVSjMzsGI=;
        b=Oi4FPx+fOsm/tH0SzQ4/efZRrxW3N5gnZMWuFSfIjTZZxVosubFlT6arDPiqXY7iv5
         fM277CIT1MAdN3NGztN5KvS3MhMwQ+z28iz4YUo6qOrc76jTMXZ/L6m1DlCLq3BxaFx5
         mNqbiT/4PqbMqbfNNhOttZ/pkOdX54odCO087sIlwASK+0Sg7IetD1MUMbonP6ldl9bw
         TVfClfSqjemCWPMicBzZiXgalYTuY6NZ9qpRAKHrfiHyxSjzeorTuLgVSfI4NvVWZdBp
         Tc66TFQepCnAnyP5hfarkxFkzjennU6VJ0bT6oOqEyoK43iKh+5hIuvF9MYZrYWAjhtY
         YfGg==
X-Gm-Message-State: AOJu0YwBIJBUXUOcw8vITRlsi+U5HGDsB7eHG3pFCMZbJP04bHaibFKP
	WRP+gY9cWC4NngvEXHfAvn9LnjmpAYgpecCa6c4Jpt1baG8MVgPXQP6gYhO9aKDhAOgQ2lHxMjq
	wTw4=
X-Gm-Gg: ASbGncvkXPyzwh4FN8n0Le9tgeZIuI8Ziipr0/aMGYk87WUmy2AVVusSp+pmOAnplfc
	UhP1DkFp7xgG63GuhfsnUBRIa3Ebpn/HwPg7yLGUvfBEcmONu4Pl9Ru+FaMT88MRpKMqSs1zMSq
	DtiVyamV0OLDbRjoTaVoS/h0kMO/gQUZVvkbEv1gS8435wqQWvImuaE7a97TAR7Fh5z900VK6Fq
	YWRjMI04wvG3bI/3BCDqOf+q2otIFYYf50UaVHsX0nL5tNqD5yFYssQfG3+20upA9KkplK/7L1a
	I5oZ0Z3YlhptB6bWabRiD9pWod5LHDe8GWampFfpk60E1KvICXkkICE6HgMf4bjL+ZEJWQQnQmg
	VNbjHp1Seav1Oj3U14BFzi7CAcn97fvVi+9pKjmyFPN16VxI=
X-Google-Smtp-Source: AGHT+IEyu27B/PMf2uuIFQI/zJClAFz2NkQRnW1PPOCRasV8axwAagt9DtnzVc9kp3j4cgEJYxbZUw==
X-Received: by 2002:a5d:4909:0:b0:3a4:febd:39f2 with SMTP id ffacd0b85a97d-3a4febd3a7bmr6184866f8f.37.1748933057331;
        Mon, 02 Jun 2025 23:44:17 -0700 (PDT)
Message-ID: 
Date: Tue, 3 Jun 2025 08:44:08 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini ,
 Anthony PERARD ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 
From: Jan Beulich 
Subject: [PATCH] compat: add header guard to xlat.h
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

This is to conform with Misra C:2012 Directive 4.10.

Reported-by: Stefano Stabellini 
Signed-off-by: Jan Beulich 

--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -105,9 +105,14 @@ xlat-y := $(shell sed -ne 's,@arch@,$(co
 xlat-y := $(filter $(patsubst compat/%,%,$(headers-y)),$(xlat-y))
 
 quiet_cmd_xlat_h = GEN     $@
-cmd_xlat_h = \
-	cat $(filter %.h,$^) >$@.new; \
-	mv -f $@.new $@
+define cmd_xlat_h
+    echo "#ifndef COMPAT_XLAT_H" >$@.new; \
+    echo "#define COMPAT_XLAT_H" >>$@.new; \
+    cat $(filter %.h,$^) >>$@.new; \
+    echo "" >>$@.new; \
+    echo "#endif /* COMPAT_XLAT_H */" >>$@.new; \
+    mv -f $@.new $@
+endef
 
 $(obj)/compat/xlat.h: $(addprefix $(obj)/compat/.xlat/,$(xlat-y)) FORCE
 	$(call if_changed,xlat_h)


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 06:46:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 06:46:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004003.1383643 (Exim 4.92)
	(envelope-from )
	id 1uMLQC-0001nH-KY; Tue, 03 Jun 2025 06:46:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004003.1383643; Tue, 03 Jun 2025 06:46:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMLQC-0001nA-HF; Tue, 03 Jun 2025 06:46:52 +0000
Received: by outflank-mailman (input) for mailman id 1004003;
 Tue, 03 Jun 2025 06:46: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 1uMLQA-0001n4-P7
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 06:46:50 +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 8651707f-4046-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 08:46:49 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3a36efcadb8so4481466f8f.0
 for ; Mon, 02 Jun 2025 23:46:49 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-450d7f92585sm158838735e9.5.2025.06.02.23.46.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 02 Jun 2025 23:46:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8651707f-4046-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748933209; x=1749538009; 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=+RBrRkUU8rQlsBE1rCiUgyDPYrX2VyvVAIYz0+G1pr8=;
        b=AaiYYydk6mflK0BW4D+GnWya53gZYwznvGRsPDxYEKARIqyCabneLpXh2ZZmkUBLkK
         NFT2oSDJVv7mPRB0hbR2sXOgjNRXcoICgLKfkPNYF5RZ4+xwA7CdgHG6wprgULIkWDFu
         VsjTdo7YEnMTR7HVX1SecYgi+65J3v372RSuM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748933209; x=1749538009;
        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=+RBrRkUU8rQlsBE1rCiUgyDPYrX2VyvVAIYz0+G1pr8=;
        b=T8p5TZIr3AQwc1rjcQKDJpC6cM5duUQufRN4N03NpMtDe9bIPKaQhPipkGoqqXfJZX
         9ICtRL+m3SMwrvQst7qgHcGsPwyq5bBWzQuDt04LFmvYV9aMa3bUlVyobsq6sNd6GPVj
         v+OJnVsWWX9ktZ7Y85Uz+plG8OL5FZAVZ5y6K3lMk+c65sJcqOhKlFDXT/yOA6It7sRJ
         OTULozL5gtfzKCmGofrSmMztLFiKKqFPTgJeGV4MtO/p1a0iI/cHuFyqJTROiKSXx2FB
         amN38H3mkB4ZxK5PCErEdP9029cw6QzMwUMoa/XmEnLP3wSASWkjBQzJJtrnDA0N+BPi
         qKAA==
X-Gm-Message-State: AOJu0Yw0macxtc8pH8cwOanhYmDcLPWLgeoG1HvbgsPZiHS/EWOdPqbi
	M5b9wvhzw4meDir9Y6pCHnSj0YLyfaev/FOSsz2YVCxXpniLuDaL22qGN0NjKREQxiY=
X-Gm-Gg: ASbGncvo1yHWu1YXam236FxAeaoGGeVjxoNxD8NDhz3LqkqJYfvMQBsvhft2m3t3ZZs
	QJ4AEtGwi5cIUyWQ4/88fmnBcfB3QphSwSbYL9ZKeTuQaPfbGrcoK02SHW8XfmrV/cXUAWRHsAt
	pOLBtCTqFftI18/cleGhg3xsdN5Z2GhUnu674d+jz+BTQDBEDJbJehLUYKodqpb3FH2qk5lwhvG
	xnV3zb6vd7AAbkLnT5w6GdJ81n88MATfmX2LZoheCgH13pXpYsJTnHh3JtMlvltuGKnrUnWnpgu
	kVe6nK/g18wmRJCuXT85zXLF/bNUmDdfozyNBAFaRFOP6kHi3fMnwyZ/+gPRSJKoGvxKzeDtDF4
	2cMIX+HN9Td78tnt51Okl4naIQsUMCGHMAKU=
X-Google-Smtp-Source: AGHT+IGQz9PbAmBk8/huL5DcDZy4UmhnB82hREbSXy1HI2Fg5B+CZD/0mtG3zKeTw5mlXrt+hIOkQA==
X-Received: by 2002:a05:6000:240b:b0:3a4:f24c:d719 with SMTP id ffacd0b85a97d-3a4f7a816a9mr11796133f8f.29.1748933208903;
        Mon, 02 Jun 2025 23:46:48 -0700 (PDT)
Date: Tue, 3 Jun 2025 08:46:47 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Michal Orzel 
Cc: xen-devel@lists.xenproject.org,
	Anthony PERARD 
Subject: Re: [PATCH] tests/vpci: Use $(CC) instead of $(HOSTCC)
Message-ID: 
References: <20250602150929.10679-1-michal.orzel@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250602150929.10679-1-michal.orzel@amd.com>

On Mon, Jun 02, 2025 at 05:09:29PM +0200, Michal Orzel wrote:
> These tests are supposed to run on target. HOSTCC can be different than
> CC (when cross-compiling). At the moment, tests installation would put
> a binary of a wrong format in the destdir.
> 
> Fixes: e90580f25bd7 ("vpci: introduce basic handlers to trap accesses to the PCI config space")
> Signed-off-by: Michal Orzel 
> ---
>  tools/tests/vpci/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/tests/vpci/Makefile b/tools/tests/vpci/Makefile
> index 9450f7593a41..1101a669e118 100644
> --- a/tools/tests/vpci/Makefile
> +++ b/tools/tests/vpci/Makefile
> @@ -11,7 +11,7 @@ run: $(TARGET)
>  	./$(TARGET)
>  
>  $(TARGET): vpci.c vpci.h list.h main.c emul.h
> -	$(HOSTCC) $(CFLAGS_xeninclude) -g -o $@ vpci.c main.c
> +	$(CC) $(CFLAGS_xeninclude) -g -o $@ vpci.c main.c

This was already posted in:

https://lore.kernel.org/xen-devel/20230313121226.86557-1-roger.pau@citrix.com/

And got no feedback.

I'm happy for your change to go in, but you might also consider
picking up the run target adjustment part of that previous patch.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 06:52:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 06:52:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004010.1383654 (Exim 4.92)
	(envelope-from )
	id 1uMLVw-0003Yr-7R; Tue, 03 Jun 2025 06:52:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004010.1383654; Tue, 03 Jun 2025 06:52: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 1uMLVw-0003Yk-4E; Tue, 03 Jun 2025 06:52:48 +0000
Received: by outflank-mailman (input) for mailman id 1004010;
 Tue, 03 Jun 2025 06:52: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 1uMLVv-0003Ye-43
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 06:52:47 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20629.outbound.protection.outlook.com
 [2a01:111:f403:2412::629])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 59a1b0d2-4047-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 08:52:45 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by BY5PR12MB4291.namprd12.prod.outlook.com (2603:10b6:a03:20c::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.36; Tue, 3 Jun
 2025 06:52:41 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8792.034; Tue, 3 Jun 2025
 06:52: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: 59a1b0d2-4047-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=jx8QXT/ub6qZy7qkt23+ZopCerFT6NFROephBWicB9YYLPBfSBkyBxU4RqmbcplKLTxwyKM35HcTWCMojUBXzKnGtuQHJr3+hYQ+5bB/Mt0zvc+gwAAVRVI1b9cSBwrDSn2A5hC7LcuVqoiXPRwLZAKX4T75XbixuEAHhm4SzBDgb5NYNvUfii9RnDOzf05s/mFTyZL9kyOXSQpwBpvI8EssyHVNEQX6QXceXkvabAlwJnQ/343LX3pYdY5z5Q38Aab6ilj1cZjOSLzGruHFX058h0jXt6ja0ixPj+zGUHp8uT/cVcp3QFOF4dNcBZUEexGjbZv4/CrkqzoFHcPQkw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Hzp8RN9hwOzJoIap6EqlJQLus6f0OAqb16klUeUD3kk=;
 b=yIRPF7yklAQZskocUUXzJj4Xyjt16L6/H4mFJb4bjpfA7/xCMy/+ShArti+I3MjNka82lcjyHANfCC8ffKmP6SqkMpM3xMzfISrDTv8lbfh79aQ7b6D0QcHOkw+z6nsF0t6wJCuxqlpYy12MYeSQEM9CD1x+QwUcNi4QO6kyGbe43Xg0Vpv8dux2EiG/klSk74f23vx7PHOWMkdkrQ4iwMpSv6/B+5DIn6t4zRBiyTEz+oAMXkGMSvDm6fIxSvaiOSfsImzT75O5cSgltxapfmitUMiku73J/ogysNjcK2Ce6VFVWRdmBbfiBKtTBQLuIlmnc5g72IA+QhyrCJt1Og==
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=Hzp8RN9hwOzJoIap6EqlJQLus6f0OAqb16klUeUD3kk=;
 b=Q9NHFvXRM3y4BDU/QMsEyoZmxqff6HmRd+W6wrQucelCQGbg4I/QinGa0rkSuOr26Q4bqOnES3HFG11fbA2zt79m6DbWA7L8WyUMsAYXNp1rkckjHP3H42Dr5fnB2ClqBaIUHLQ6vxLFe85eK5yIhlzeSNPOZveivahrh3sa/Q4=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <6438a00b-a0fe-419d-b57e-5e1af48d43ce@amd.com>
Date: Tue, 3 Jun 2025 08:52:38 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] tests/vpci: Use $(CC) instead of $(HOSTCC)
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: xen-devel@lists.xenproject.org, Anthony PERARD 
References: <20250602150929.10679-1-michal.orzel@amd.com>
 
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: FR4P281CA0183.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:ca::6) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|BY5PR12MB4291:EE_
X-MS-Office365-Filtering-Correlation-Id: f1ec3087-109f-43f8-46fb-08dda26b3c22
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?a2NHTzR3UjFvU001ODA2Qmh6WUJjajhMM0hucUQxWVJLekFxRDdBc2ZkcnpI?=
 =?utf-8?B?QXY4UGJpc1lTTVR2ZmE3d2FFTFVXanc3UFdiR04ranpoa1BVWmI2NkdIYmhs?=
 =?utf-8?B?YUFZMi94YVUzWGtwSXorekxVRllSMnVIOHV4TUJXVEZMZjNZVjl2ZG16ZDIx?=
 =?utf-8?B?U2NUWVdPMkZPNHErS0s4Yzd0aklVb2I1N0N6dDRPbWRRS3ZlSFIyU01PcE13?=
 =?utf-8?B?c2wrVHNreis4RG1oMjdrNkgwbktYMlZzVFYweXQ2UlVTcTdIejZFYlg1ckdJ?=
 =?utf-8?B?ODM0YTlHekdRejlrdlBlNDBQcXlMSmpSSjRIbVNOZUpyVVBUME0xMWl0SEhF?=
 =?utf-8?B?ZnB3ajFlYmR0UEFKbVEyV08wUzFtQnBIYUcvcHBjbTcvTXozYVRrcVlDMzNF?=
 =?utf-8?B?QjkzZFdFVHQyK282ZUdhdkRYTDRpcXlEY1VGR0RCR2U4bjIrYTVOMUJPRFBW?=
 =?utf-8?B?a0dnVHFIY0xQQnBoM0FEVDV5d2hqOWlsOUtKdU9FSGJIY1UzZDh3ZGR5aFNz?=
 =?utf-8?B?Z0xzcUVXbTVEY1N6a3VKdlJzOTZ6MjlpbW8ydXo1cFdhZVliYnJmSVROMmZr?=
 =?utf-8?B?R1l1VmJXcnVtbUpTc0MzS0xmWjc0a1h2bkpQcys1c0grMENyQ3J6YXRQTDRH?=
 =?utf-8?B?dlltQnU0a0lJLzJSSWN5ZGYrQ2l2WlcxVWo5dklRcjlQQWI0ZVdSVlRuTlZv?=
 =?utf-8?B?MTg0Yks4UXVrTnhFOUtpMnV3L3ZGaGVIVHBVdXNVQThOeEVTQWlncUdzeENQ?=
 =?utf-8?B?TzMxT1lsbmJ5dVE4SjJGZkVWaWpPQWN4Sk8vMDZRMHp6dlVILy9PR3BwNHlS?=
 =?utf-8?B?S3NjWFkwQWtDMnZHbGRUSS9yejJKQnQ1RThia2JIc2F3N3BGR2JFZysvOHV2?=
 =?utf-8?B?c3puWWgvQU9jeDdpNDJ2VExQdWVvKzlJMUdqbEdBMCtocUdBSlpJcU9hMHZG?=
 =?utf-8?B?US9aZDdITFFWZXkxaWU4YlFzM3M1ZExNSU9kWW9QYU5nS0pnTTIxY3hKK3A0?=
 =?utf-8?B?M3Y5dGFNSWMvdmpaQmEvUHRjL3VvcnNkNzVOZDFmMDEzSktXMkUxUUlYd1c3?=
 =?utf-8?B?MTV3VTI0ck00UVkwaE1kWUpSRkc5aE5XWWZMVFB0NDZ4U0NWV3hMaktBY1Ju?=
 =?utf-8?B?MFRJd3NXVXlsVk40MHNXUkY2Qm9ld2pMRWY5dGZVZUNlR0Q4MXBETm9FbGFy?=
 =?utf-8?B?VlhlSFBWTm1MbkgwNE9EcjNDZlVpcEcxaGU0bk5ad3I1aEt0dFM4dG5lcWJ2?=
 =?utf-8?B?NXpWN0FwSnpEdDhBQjdzb09kMldDRDBBUkw2MmRxRjd1MlRaanNmangyMmJF?=
 =?utf-8?B?ZGExTWdCSWFMcGc1cWhhQ29wYy9Xbkk1QXdPWnpKcW1xY0lQbTA1bDlNRi9m?=
 =?utf-8?B?T2ZWTmZ3KzN2aGhEMTB5S0pHMmd0RTRuQUdBVW10YUxPaS8xdit3UDBXSDdV?=
 =?utf-8?B?SHVMN082S29hejUvdkVNSnFBeDVzTTc0ejFhQi9Gb2dzSlE4MjlpcTJDNE1v?=
 =?utf-8?B?MnFpc0VmOWlqQlkwNVY0aEVHa1liR3ZDYWFIT0d3aDdaUGRSQVJxc21NQ20x?=
 =?utf-8?B?WDN6bThQVjUwSUVaaE1ZZkRFZmxnY01WZlRxb00wM1Yzenl6SUozY0FjektD?=
 =?utf-8?B?NEdPZFAzaUt3UFBKbzJRekFNd3NUWFJOQU5ndm5peFdpZ2dsejFjVVh2OS9R?=
 =?utf-8?B?MDJvS0FlaFJTRk12am1zNURkWmFLelIzc0pZbVZDZHFnRk0zUG83b0NpZXpo?=
 =?utf-8?B?SnpvNUlmYjdDcHQzVFF2c0ZiRkdkSkZveUNpK3M4SUJKMEdwNDR3ZG5TM0NI?=
 =?utf-8?B?TWwzdnBrcDFrMldhVkwvb3hIbmpGYVp5eElLa21TVkxlZ0NDOVlSb0JCdk40?=
 =?utf-8?B?QVBWczVVTEI4K3ZDc3pOcGJOVHQ0YUZJTDdiNTFGZDBDS01YNzl3SGZOTXo4?=
 =?utf-8?Q?EVC8xQbPooA=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?eDJKMDl3R2E3amJHL2pkakkxMG1tekI1cnNZUWNtQmREYklvWGpzR0s1bHJw?=
 =?utf-8?B?TmJzUi9PUjdxeFJSMElXeU8xVDg5YjlwMEdXRlA0aGZ2NlJvS1BxMGlKM0lK?=
 =?utf-8?B?dE0yNHh0bFdZcFdma081bEtIUlp6RGlqUEJhWE9ZajkzWVpDKzJMZmhucklD?=
 =?utf-8?B?OVlRSHdEbFFSQ0ZubDlHV3ZwT2Q4SlhMV08yK1hjTk5SVEVoMG80b0t3YS9G?=
 =?utf-8?B?NlM5Y2VqOEtRRk9lVDNIbkd4Wkp4LzlDRnJuNmlLRWU4dXd1Y29EblZ6alVk?=
 =?utf-8?B?UjkvQ1dITTlCT0Z3ZGZlZ2tLT0xCK1Y2V3kvUU5vRGtydkNDRWdDb21ZUndJ?=
 =?utf-8?B?aHFFYkhQUmhIRnJVd0d6d3pxWVFVUnRzbnhtNlBGNVpHSnZ6QW91emVaMEh3?=
 =?utf-8?B?bGF1ZE9oWVVTZUJPYkhRZU1OMFNVQXJMZmJrZjNJaWlpeFE2d0RybXdaZDRN?=
 =?utf-8?B?dU9kK3dUMVpaM2Y4cHF5NWppNnplVzZZbXlmU1RHeVNLYVROQk9mUFBVZ2Zi?=
 =?utf-8?B?K21jR1RubmsxNEphUmVUVmZkbjBtZ3VTbDBlb2ZpVWh5RE5kNml1VWNNRW1E?=
 =?utf-8?B?dlZIY2czRmRtdnpKYTM4NGpaeVpFa0R4eFNUOWtHNUdIdU9xT29wUlE0NTFT?=
 =?utf-8?B?NEE4eGZnTGoybVJjb3liVGhKZXc3ZDhLRnVBSWNBNFpnZWVmZDR3V09GMlAz?=
 =?utf-8?B?NkpVL21lVkkwNThZOWczT3ZCZlJZUUJjaWNuWUE3Yi9rTGRHV3RVaXpldkdE?=
 =?utf-8?B?cm9mWHc5U242VE5uQVdMSXZsN2laNDVoVG1ZaC94aGhocmhtUitpRW55NXJl?=
 =?utf-8?B?TnVlYWNqWEhmV1lWWlNjUFpNdVBtYjBJWTdvdFN1ZW5ncGZrc1hxTW1rN2o0?=
 =?utf-8?B?Rk9hS2VRdm0xNWtZUXFmckV6QUtoZ1c2aVd3Mkk0SW5abDBFOVAvaGVjQ0V0?=
 =?utf-8?B?bjVxTEVxNE14Y3VHd09jSk5NZXpQbTN0SGQ5Q1ZQWHJIQkVUN2ZzL09FaE5V?=
 =?utf-8?B?c1l3WTd4QWoyVXBjczdZNWExS0kranl2bEpEd01lOXd1bkllRXZGQnczWWo3?=
 =?utf-8?B?WXpoUHcrM3hWK21FbHo3WVROYnVWSktsWlNLUmg4OFBvaUJCV3NYbThydnA4?=
 =?utf-8?B?M3R0dE1hWXZ5S25zM0pUa0JncklMdmd2TU41Z2JnS3MxdER2djRDaldJSyt0?=
 =?utf-8?B?dDZrekdLZ3haOWI3OFJMRGZmSXhPRjhybGt0eURsQU9ZRnA2NlN5R1lVL3Vw?=
 =?utf-8?B?L3pTT1hYSGFSVmtwaVpaNjdlbWRjNHJzMXRrOVFyTmdlamQxWDVBUDlLUDdp?=
 =?utf-8?B?MkdJR2VEU2NrMC9QTEJoUldxUGdHeVo3U2MzUjFSZGxjbTdKUFcvM0ZTV1p5?=
 =?utf-8?B?VWhVUTZHOHFQRVVteG1ESnRsdjBNT2FiVnlPSmQzSW1mNFJxSTg0VGxuc3Zi?=
 =?utf-8?B?bDlRa1pqQjF3ZHBGdDVnUGU2TkN0SEtvTTZxREdwSWpqOWp3eUU0V3NLZWZ0?=
 =?utf-8?B?Y0hrS29Pa1dMUmlHVktnQS9vSlY5YkZvaVprcTJJbk0ycnY0emN4Smt0OUt3?=
 =?utf-8?B?d25rZE1tNG5HVHJReE85YVNEWTN5SnA4dGY5U0RCZVM3bnZuc3Z4dDJLeFVy?=
 =?utf-8?B?cFBkYW5DUXUyWWtwdjFlQ0l0MVNxek5yWDRCbnMzZE42R055dDhsYkt1OG92?=
 =?utf-8?B?elJocnd0RXlkR0lDU215eGYvaEhOMzhRZkwzMzhZN2JKOXc1bzQvRmJvWG8x?=
 =?utf-8?B?Z0ZRVVN4RktaWDdrcUsxNFZIaFB0a3ZHUHRTMG1qcmlDTUkrWkp2dXpOVWNh?=
 =?utf-8?B?OHFhVkM3QU9JNTVSUCs5RnRSUWdvaXpBN1VPRE0xWXNXWHNEWnkyRkdDVHFK?=
 =?utf-8?B?U2R1RllUaWpPR3ZRcGV5TGRwSGNPZWdLWGIrdlo1MUpDelp1OTJQM3A1aGd2?=
 =?utf-8?B?RWZEdnFqMkxZckVPZWRFZ3o1U1UwZ0o3WkNvdFRDdEhmOU9FVFYzMlNNSFpz?=
 =?utf-8?B?alhuTnhMQ0VROXdNU2hlVGtQZTZqbkJOM1ZiSnBXaHBmUnNXZVBCaS9EZi9x?=
 =?utf-8?B?eWlWd0JIRWJKVWh4bmd0SWhWOGFNYkhZWUdtR3pPOG1Lcm1jM0Z6UTE5MHpv?=
 =?utf-8?Q?VHDp+TyBhzeDxbZjDPOEiYeIN?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f1ec3087-109f-43f8-46fb-08dda26b3c22
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jun 2025 06:52:41.2328
 (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: v7Xy8BuTI4dmA1OdUFAlfa7CqHzVh4xPIYW+4/tSvmszpZcqGE6AdVYALpM7mc4g
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4291



On 03/06/2025 08:46, Roger Pau Monné wrote:
> On Mon, Jun 02, 2025 at 05:09:29PM +0200, Michal Orzel wrote:
>> These tests are supposed to run on target. HOSTCC can be different than
>> CC (when cross-compiling). At the moment, tests installation would put
>> a binary of a wrong format in the destdir.
>>
>> Fixes: e90580f25bd7 ("vpci: introduce basic handlers to trap accesses to the PCI config space")
>> Signed-off-by: Michal Orzel 
>> ---
>>  tools/tests/vpci/Makefile | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tools/tests/vpci/Makefile b/tools/tests/vpci/Makefile
>> index 9450f7593a41..1101a669e118 100644
>> --- a/tools/tests/vpci/Makefile
>> +++ b/tools/tests/vpci/Makefile
>> @@ -11,7 +11,7 @@ run: $(TARGET)
>>  	./$(TARGET)
>>  
>>  $(TARGET): vpci.c vpci.h list.h main.c emul.h
>> -	$(HOSTCC) $(CFLAGS_xeninclude) -g -o $@ vpci.c main.c
>> +	$(CC) $(CFLAGS_xeninclude) -g -o $@ vpci.c main.c
> 
> This was already posted in:
> 
> https://lore.kernel.org/xen-devel/20230313121226.86557-1-roger.pau@citrix.com/
> 
> And got no feedback.
> 
> I'm happy for your change to go in, but you might also consider
> picking up the run target adjustment part of that previous patch.
You're the maintainer of this file. You should tell me what I need to do
unless you want to wait for Anthony feedback.

~Michal



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 06:54:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 06:54:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004017.1383664 (Exim 4.92)
	(envelope-from )
	id 1uMLXn-00045q-Iu; Tue, 03 Jun 2025 06:54:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004017.1383664; Tue, 03 Jun 2025 06: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 1uMLXn-00045j-FD; Tue, 03 Jun 2025 06:54:43 +0000
Received: by outflank-mailman (input) for mailman id 1004017;
 Tue, 03 Jun 2025 06:54:41 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uMLXl-00045K-Et
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 06:54:41 +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 9dc3e729-4047-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 08:54:39 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by BY5PR12MB4291.namprd12.prod.outlook.com (2603:10b6:a03:20c::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.36; Tue, 3 Jun
 2025 06:54:35 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8792.034; Tue, 3 Jun 2025
 06:54: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: 9dc3e729-4047-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ZDSpmaYI4UZEgvIfpDh89p8AVv+4WMAddlbO6LMq61APfFo6AyE37lF+QNP3R3O8HDa2bXyvxJGZ2G8R0fUkGRltdp1T+vqsM6q3kOF+bluGBf2T4vCkc2OtO4Yw2JbK958ePvO1nJ1Phwn75vmRZ/bwVXOEjna/Bs9DPP4VWtFWog7/tubmp4TqZLKUxsySq+b0C/DuLOUkGtzhrNUcfxhwYOh3eAo430uLWm0mS/NjLJKGdqDYc5t8hcWypsS6e3V6xYMr0jU2wUpfRSYBIfJbeqVGjVM82R/EUIWOPqxwl8Aqy5m6FXTQ4ISR0sDbLDCrx3hbFioprcI94Gw5TA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Rehh2XqJS+vhfNjoqb5PhLq3EgCFsnfzArbiRlkYj2c=;
 b=bOS1FfrOyK8oyeG4t2ADaSsUNdjT6Wiue0WbyT60uh3sNucTuYenLA2XhwLcZJ7CnMNlxenv4w8ypCitooEVjOvNblPVXLDucwZRjfQgh/DoSE23ZQLmAxkV1ouEvN/4AvSOfmuFZ9fqNe5HlYRzPrV4Gft88nGVF6nfb5E38jDuWglke2+08YcAmTae6Shh9vMl9DxyKHwyUoBjEdXx7Suyd4d/kSF4wuOcPWfsz5T92gTlGI/Bl3gQxlkb86wna1AlTPI243dqOa7skvN7nRM8ELSuUnev4h7UQ2inzqc0Q4vbK7cGiZYgxZMbFNX/humdebKXYg1B14yDnU1V0Q==
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=Rehh2XqJS+vhfNjoqb5PhLq3EgCFsnfzArbiRlkYj2c=;
 b=CzhAEj/kbM9/U+7sd08VYcGdYaUzowIxVoX5jUM9K/Lr5/sVecrUwroCeu1rbk6ZgzZoOygt6UUuZ2yRfJWs2DungBsU3LZGjeP3jCFEuQuKESsxTZ9CCXtrcxZWJ0QVFYu8+G/4jRECKCku9dTRkI+uBIq6WqAnM2kkxS2UfcU=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <28a9f398-d206-4e42-b627-bea71f038b4d@amd.com>
Date: Tue, 3 Jun 2025 08:54:31 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] device-tree: Move Arm's static-evtchn feature to common
To: Jan Beulich 
Cc: 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: <20250527082117.120214-1-michal.orzel@amd.com>
 <344823d0-eb05-48e5-80c5-9598104f3a3b@suse.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <344823d0-eb05-48e5-80c5-9598104f3a3b@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: DU2PR04CA0207.eurprd04.prod.outlook.com
 (2603:10a6:10:28d::32) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|BY5PR12MB4291:EE_
X-MS-Office365-Filtering-Correlation-Id: 6b7e70c5-0fd6-4148-9015-08dda26b8030
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?UmszK0RPN3JUb3FpUmlyWjlKT3Vuai9tQkI2MnBHYktaTVRneDVycHg1RTNT?=
 =?utf-8?B?VXQ5NlFjbzFBbk9MWGx5UmtzWTBxQmlGdnhLUWNrQkliZ3BsWHU3dzYxR1Vi?=
 =?utf-8?B?N1RBWW1wREZRSEJmT2M1TjJISnJjdHoxUjJISGhDOHByZDd3ZjFkYk1rSHBB?=
 =?utf-8?B?KzkyU1o2RU1Ja3Y5bjBBdUl3bmluS01ZQlR5dlR5OTZ3UEU3WjY3Z1ZwbG8y?=
 =?utf-8?B?bDNnaTZVUWI2VU9qT1BsVnpMZDN6OFlwRzB5aDdmcWJEMW1TMDUzcFFuTlRC?=
 =?utf-8?B?bVFRTmhnOFlYUldCaGc0eHVPRGhZZFdFZllwK3ZwZk9nRFVsOUNtQzRjTmlk?=
 =?utf-8?B?LzJFYVJmaDNyZk9FTWFkYmtHZFZiKzlZZWRRcnNRditkY0liemxsZ2JKQk9U?=
 =?utf-8?B?VzdvMnk4ZisyRFR2YjVMUjFvczN4WmptSDdEYWZYVE1hRzJBeDM5QVdMVU1m?=
 =?utf-8?B?dlYrb1M0MHZKd2xIdXNaR3g0OU5QNHJQOVVoNXdtL1NpOS90UzJJNnV2ZkVV?=
 =?utf-8?B?NkxjWWpMd3BZRHhmUnNiMUNYamROZ3docEtQWVJSZ2ZNSFBRZmFCbVNLRVov?=
 =?utf-8?B?WURaN2EvbnkxZGRsSzl4Sm9VRmZKbmI5dFlabEloek1hWGRQemxuTGNEd01q?=
 =?utf-8?B?NFdYbk80RTluR1BEbmIwbXVhSDhQY0t0NXZlVGZhY1hwNFVNNWNaL3hqTHBl?=
 =?utf-8?B?VkN3OTg5SEFjaXJWVWo4RlBuNDdZSlZGVktBY09XeTI3eks5ci9YOXZtMlpw?=
 =?utf-8?B?OVJDV2d1RVZlT2dMcXpqa0lVekJuTjRDbDQzSVZXOTlsdGk2NWdhTzFQMG04?=
 =?utf-8?B?V09pOFQwNmRnSmxhVGwwaVZydUpodTMvY2ZOZDgxMjJ5T3pSOXNIUmd2SVlQ?=
 =?utf-8?B?RDRlQ0w3UmJaUWhwV2REZ2lwTmY2dzZ0Z2pDT1RjTUF0WDlTSlZ4VjBYY1Ba?=
 =?utf-8?B?QjhOeURjUnFua3ZTaFJlUzFRTE01QkVCTkh2eUxwVG9uLzEwL1VZTFVxMS9Q?=
 =?utf-8?B?WVREeTgzQk9IY3dLLzIwWElNbGZEVmR4N1RQN3I0dXpjK1ZBTXNLb1FXaktP?=
 =?utf-8?B?TE9rcWlWWENINjJWWFMxNWtuK3BmZlo2ODYrc2Q2c3ZhNmwyc2lhaExmRkZ4?=
 =?utf-8?B?dGprQ2lPZEUvWVVER2p0VGhoRjhTL3czTjg0emRjM09wbldoTUcxNEhTS3RF?=
 =?utf-8?B?YUxKdGlFRmU3MTVhSUJ6TUcvWXJlM0hzRktPdjVWQWFweU9mVEF6OFFrb3Nr?=
 =?utf-8?B?Lzg2Q2VoU0tDT0pWRnU3UXhMTHkrYTU0ZXBsUG53TXExK1M2b2dXOGJzWVNC?=
 =?utf-8?B?aTdLaC82RHY4Y2tIQ3ZjdnpZVFlpdWxzU015YTBKeE9OUnZZTnkvV3JDR1hi?=
 =?utf-8?B?SU1pWnNwdGVGMUMrTkRMWThJVVVsTnpweXI3T0puSU5WY3J0R2xrSGxoZVRU?=
 =?utf-8?B?cEZlZ0hOVVoxQmZ0T0E1dEdyVDdYaTBhajQwbWJCN2U1Uld1YUhzT1dibnpV?=
 =?utf-8?B?RHNmdWpaTXVvSTdabGFjZEVkanJMaTl1b1J4enc4ZE5heXl1OGFWY2VSVVV2?=
 =?utf-8?B?YXFJMFR0V3g2ajVjano3dWMrZ3NXQ3BadDROMnFSV3UvVjlGb0cxVVlaNjVj?=
 =?utf-8?B?andkV0NOUjdPWVczWjNmZnJML3VDc1JZdkFZMFJOZ0xadUFwbUk2Zy9sUlJI?=
 =?utf-8?B?WEYzaGRQcUlUMXJzRnZuc3VDYkN2Q1NiWkRPQklNTXV4cWJQU3F2ZjhwQWtC?=
 =?utf-8?B?b0w0bDVvaGhib0ZwdGNJeDdwVVowWlpFeVl4ajljVWpzcHM4UkNOR3N3bEVw?=
 =?utf-8?B?bHFqZGtOUWo1Ri8ySFNXbEx6dzZLenY5dk56OUhZd1BNVmJkL1NRTnFIb2t2?=
 =?utf-8?B?cDR6emhXak9JaHdsZ3l0ZGRyTndrcGRqdkd6bkI1Y3MwYmVxbDVBc285Znk4?=
 =?utf-8?Q?cjDbQV/EI3k=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.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?RHRxYmV1OGw2dVZybW9CaGMvSTFWVm43c0JoUS9rNDZMTlNFRXZhL3FSeWtx?=
 =?utf-8?B?N3VJNzBaRE1Sc2dzeXo2aFFhaUVBZXY3bkZ4Tm5JYjhYTnVyVDZXMkpSWHZk?=
 =?utf-8?B?SkRoL1BTei9kQno0OWxXejNtZmR3ZnRvZFRta0ZYOHlXVndHMVVhUnF0S2la?=
 =?utf-8?B?OWlYTW91UEdpbG9KSTJTT3c5aysxWGpwTWsvbWNYa2ZpbkJTdllWUUdpNjJ6?=
 =?utf-8?B?MllMUFFKSjd3TWZKWXFEaks1U1B1dDBCZ1hKL3dGbHBhSFkyT2pPcUxBQU5S?=
 =?utf-8?B?elIyMWhBdkJEYzlGbDVVcUFlYVF5MndXQ1hIQU1NUFQzbU83dWhXZ3hCSUgr?=
 =?utf-8?B?djMrSWZsckh2c1JjeUZnS2RlcU5FUXVFK1ZWN3E1azJTRk8rOUZzbDQ2NFhw?=
 =?utf-8?B?OUVRRDVQSkJjU0ltb2h5OVBBVkxFMUJndHRSMUNlcFZqc1V2TUtUKzY2Rlpn?=
 =?utf-8?B?ZnFJTFNvempDZ3Z0R3lENnIvcnZXMlhpMlFrQ3llRlFYbHhxbGRHeG01SEJx?=
 =?utf-8?B?NHFpaDA3a1lpWkI3TUxORlJMVkxOaWgzd2xtOUpkd3RKSDdvaUo5YTkwMWVt?=
 =?utf-8?B?OUdzOFNwR2JudnJvUGgwQ1BjWG5YbG0yeHVVMHZiK2pDZ2twOVNGbUh1WThs?=
 =?utf-8?B?ZytEdGlWck82anF2KzRpTHpZMzJMK28weTlOUmVxYkxsYU5xVW9yUlpGbmRv?=
 =?utf-8?B?eXBmSnp5NzV0YW5TUEhiUG1YRFMzcjUrbGpoQ0I5VlJSQzFYTDhOem4wZXgw?=
 =?utf-8?B?QW15QURObEM1MkhPcXByODFlQzRsQy9uMlRiZjNpblgzajl0MnN1ZytBOGpN?=
 =?utf-8?B?WjRLaVc2ZzVRTFlTTWJBVlVYcVZlMFpwODRvdHhZSUo5YmQ5ZG1JajdTSHBM?=
 =?utf-8?B?bCtJbXFxY2JsMXRwYm1mSkRkWUFPTDdFd2hRRXM2eXdpUTk4Sks0SUloRVN5?=
 =?utf-8?B?alp1MlNYeXVoMVFoVVRLR1RUZ3dibGxDL01GcjJSQ3loT1hSb2RFVlM2SDhy?=
 =?utf-8?B?NUh0cXlqSWRmTUhualRaNmNuaVE3cWpiVEdVc3ZocDFLR09HWjJrSms4OC9l?=
 =?utf-8?B?OWtVQjR2RzVPbUptaGpsNTFoazZuQmtEQXZVV2JnSHJPQklnT1Y1bXJHRDJt?=
 =?utf-8?B?WVFEOGtaRE0raFkrWkI4UnQ1RnhQLzdURGJDSWpMcFA2SEJtNXQwWTBOeHJl?=
 =?utf-8?B?WDJKZDZ0SHNPYjVkcUhIRXdoWHp5UkxLclNtWDRPMEhNTGZINGdQaVd1QVBq?=
 =?utf-8?B?S1J4VEMrM08wSDA5NXo2TDROZ3VUdUdDVHFmdFE5WElvMUhPMVhoeGQrd28w?=
 =?utf-8?B?LzVzR1Z2MzBQRDRXV2lOWGJkUkg2cCs5eVYvYVpSZVI0eUJQWFpkejdWMkZr?=
 =?utf-8?B?c0VmZE1xYkI4UWpicEl5bEJUczlqYTBzYkNlQU9QVVRnS0RyeGprY0J4MXBo?=
 =?utf-8?B?M1ZVTGNhUUpSTFRCdHh5b2JYSDllUXpSeER5L3dhaTJyc1RtUFhVWnpwZWJj?=
 =?utf-8?B?d01pZXlEODErM0dOckRGdDJEZDg5M0paem1JNVB6Vi8wc01vUjhjMDR3RDVj?=
 =?utf-8?B?UFI4Wk03aFJrdWZocFNzckJjWmRrUXZRRXNpKzMyd0w4NWorK042QXcyaXRK?=
 =?utf-8?B?dmtnamxzKzFyZ2ZrMjIvNHV6Yy9wYVZZM2wrU2FxaUs1RG9HYndzc05mVm51?=
 =?utf-8?B?UGxqWDF1djkySE1hcUxDNlNIdlJYWGxOak9VbzQvTUtkODMvVjJMR2NsaDg2?=
 =?utf-8?B?ZFJ1cHZ5Z0p1MXgxczFzcXFYTVN2ZkJESWZMei90UGk1cGwzSTJkbEtFdEZU?=
 =?utf-8?B?NW8rS2JzQk5SSE5BQWR0V2FiK2VEMVArK1I1ekkwQU9MZjhwZ21tZDAzV3A4?=
 =?utf-8?B?eWs1amZIVDVlWFJzazVyUmVJNkdseFR4NUxKZUNDNzNEV0RPUUdkZmVZQWgx?=
 =?utf-8?B?M0hlWTJOU01iOEl6bzJIUlBjcDVyVS9FZjEzR1Frd1JGeEVIKzkxdVFRVVh4?=
 =?utf-8?B?SHRLdHI2YXZZNFJ5SEk5QlRWYnpZMWpheG5pWFV3blNEaFc3VDgycExoWkFU?=
 =?utf-8?B?d3RSa1VXTWN5MURweWhTTUMwRGtFNGJWTm83U1lpRnJQenczdkpHUldyYmNE?=
 =?utf-8?Q?XOaVMHOCWtANy8AQMKRswJnHR?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6b7e70c5-0fd6-4148-9015-08dda26b8030
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jun 2025 06:54:35.3820
 (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: FkNC/dX8YRze6+UdxG0vB0nCAeGm8dvEm0P8YTlbv9LcVQdA69bRCnonvLgXO6m/
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4291



On 02/06/2025 10:37, Jan Beulich wrote:
> On 27.05.2025 10:21, Michal Orzel wrote:
>> There's nothing Arm specific about this feature. Move it to common as
>> part of a larger activity to commonalize device tree related features.
>> For now, select it only for ARM until others (e.g. RISC-V) verify it
>> works for them too.
>>
>> Signed-off-by: Michal Orzel 
> 
> I realize this was already committed, but ...
> 
>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
>> @@ -162,6 +162,14 @@ config STATIC_MEMORY
>>  
>>  	  If unsure, say N.
>>  
>> +config STATIC_EVTCHN
>> +	bool "Static event channel support on a dom0less system"
>> +	depends on DOM0LESS_BOOT && ARM
> 
> ... I think we should strive to avoid such arch dependencies; they simply
> don't scale very well. Instead (if needed) HAS_* should be introduced, which
> each interested arch can select. In the case here, however, perhaps
> DOM0LESS_BOOT alone would have been sufficient as a dependency?
What if e.g. RISC-V wants to enable dom0less but not static evtchn/memory/shmem
because there are some functions to be implemented and they don't want to do it
now? Protecting with just DOM0LESS_BOOT would not be sufficient here. I
understand we could define HAS_*. I did not think about it.

~Michal



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 07:02:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 07:02:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004028.1383674 (Exim 4.92)
	(envelope-from )
	id 1uMLfG-00060z-Cc; Tue, 03 Jun 2025 07:02:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004028.1383674; Tue, 03 Jun 2025 07:02:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMLfG-00060s-8n; Tue, 03 Jun 2025 07:02:26 +0000
Received: by outflank-mailman (input) for mailman id 1004028;
 Tue, 03 Jun 2025 07:02: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 1uMLfF-00060l-Sz
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 07:02:25 +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 b3c0ad27-4048-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 09:02:24 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a361b8a66cso3128411f8f.2
 for ; Tue, 03 Jun 2025 00:02:24 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-747afff723csm8724534b3a.164.2025.06.03.00.02.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 03 Jun 2025 00:02:23 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b3c0ad27-4048-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1748934144; x=1749538944; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ME8QyAXpUdBS49Wdak3bz0E6RrV3wZJk9i9w8pmt4V8=;
        b=HbzgtvW05e6shimV24ce5uZZa4LJMe3mZdT1ObUFPN9EhZVBplJaryb9IReFTQ7QXq
         Pkl+4cmkKhbNnXayJHOAhkkvbIFHp0VK3gyAxQX5yefxOqKVWbob8jkPnkfuxc89UKSx
         Vu2KLviLaPonPMRInewVSSL7wbTWjvPkkRZl6bHiFsIRFHYRl9BU8JPZo42THnyOGvn1
         PQBLEstIp0o3PSnJL56kHX26yFv9l9bNd2PY6t1b/F1fqUVBT8QwY5DprTyHEje+sdc9
         Ik7q9p+91ogRvujljwbvVXmwUvF9nF9WsxYWxbbD66QjlbQ7b8JoPEKkcIBWlZfVDKVo
         Vm1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748934144; x=1749538944;
        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=ME8QyAXpUdBS49Wdak3bz0E6RrV3wZJk9i9w8pmt4V8=;
        b=uzofI+7xydGJhCv4fIeT9z0JO2kHzKpEPk/NpEku1AOGqs5fw0zS9genDEYfOSzAl3
         17l5I0T2tvbalRBtD3WSsFNojSsJoh/bnhOEGS7jKVxDut+2/Y+5hNOb1D3CeAQ+zY7z
         2AtiQZjK94Q2Use+6oL2VFfHf4OVXR4EjBYkSHCTRogMJqhbeQzFNhrFMgQVm3uoijI9
         bzWI7DK+DKNJotvjIFJfR/pVHe9hk5YSK/zy4cxhB7imd2YaNvEQqxWOcf2f0gmeGMeX
         naPAsAsAD4BjhICqXLh5EY4wbKXJTyrZUw3OFNo3fQ/WUMWhtQU2avMKHK89/+V9v+zM
         kWjQ==
X-Forwarded-Encrypted: i=1; AJvYcCUHD2iMhC9EK9XamEXJ/9GhSVB1C8VX5UIMYsiAzjihIQMertYhU3LW93iaYSTDdWGZen8fcoADY0E=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzLQVcx3sJnc6jfCbFj1mmg3qc2MWWn86XHriuEVqkQSDjv6FZG
	TYSVX1eOv6ANIMbsnVxzeE1ne0yPJqGe1xSUdD6KSc+brzw/iRluEpipn09P6YqeAA==
X-Gm-Gg: ASbGncvfOgtFLy81/SUsa3Z9OhMXfc4kYZYb2d3xt5X2xIGSSApkRsfvyHQ3Ze7IIZ4
	H1ZKJ7fo6yH4BMAq2fF/jlQWX2knLJVptIT7mURzXEk113roFdQDGiLCJRUGbUFmtC9Zt8O83Ad
	I16m9aayr3sfMXmBPrf8GBsYlrRSWsku/ZRIwWZ528x6gSwyW9U2q0UOYjQvxINx+8DYvFbyV5z
	OXVsuT77Bre570ATui5uk+kWuRO7CWzEPTEHPnKBW3anX9gYtOmK756SZIw0XDMiGdsqSzGINZd
	wABPsVO3oGaC0wGdCTorQaIA+8nntW0tWIAQzzEOgfBD5vNld0RQzO4XWt3rc24+Z5k0sKcGneO
	mmVy/doYqekUp1myI9YBEhdDiS3zYvlOLYEOR
X-Google-Smtp-Source: AGHT+IGCKs5Cd4TR9HufkPatvl8H5FRyFaKs6ZlLSIgcBZyt5fRU3kEZ+MhiZMikFRNPAyHwyy2jCQ==
X-Received: by 2002:a05:6000:2902:b0:3a4:f6c4:355a with SMTP id ffacd0b85a97d-3a4fe3a80ccmr8910630f8f.57.1748934144133;
        Tue, 03 Jun 2025 00:02:24 -0700 (PDT)
Message-ID: 
Date: Tue, 3 Jun 2025 09:02:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] device-tree: Move Arm's static-evtchn feature to common
To: "Orzel, Michal" 
Cc: 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: <20250527082117.120214-1-michal.orzel@amd.com>
 <344823d0-eb05-48e5-80c5-9598104f3a3b@suse.com>
 <28a9f398-d206-4e42-b627-bea71f038b4d@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: <28a9f398-d206-4e42-b627-bea71f038b4d@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 03.06.2025 08:54, Orzel, Michal wrote:
> 
> 
> On 02/06/2025 10:37, Jan Beulich wrote:
>> On 27.05.2025 10:21, Michal Orzel wrote:
>>> There's nothing Arm specific about this feature. Move it to common as
>>> part of a larger activity to commonalize device tree related features.
>>> For now, select it only for ARM until others (e.g. RISC-V) verify it
>>> works for them too.
>>>
>>> Signed-off-by: Michal Orzel 
>>
>> I realize this was already committed, but ...
>>
>>> --- a/xen/common/Kconfig
>>> +++ b/xen/common/Kconfig
>>> @@ -162,6 +162,14 @@ config STATIC_MEMORY
>>>  
>>>  	  If unsure, say N.
>>>  
>>> +config STATIC_EVTCHN
>>> +	bool "Static event channel support on a dom0less system"
>>> +	depends on DOM0LESS_BOOT && ARM
>>
>> ... I think we should strive to avoid such arch dependencies; they simply
>> don't scale very well. Instead (if needed) HAS_* should be introduced, which
>> each interested arch can select. In the case here, however, perhaps
>> DOM0LESS_BOOT alone would have been sufficient as a dependency?
> What if e.g. RISC-V wants to enable dom0less but not static evtchn/memory/shmem
> because there are some functions to be implemented and they don't want to do it
> now? Protecting with just DOM0LESS_BOOT would not be sufficient here.

Imo a transient(!) "depends on !RISCV" would in principle be fine, if ...

> I understand we could define HAS_*. I did not think about it.

... we don't want to go this route.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 07:04:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 07:04:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004035.1383684 (Exim 4.92)
	(envelope-from )
	id 1uMLh0-0006Xj-M1; Tue, 03 Jun 2025 07:04:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004035.1383684; Tue, 03 Jun 2025 07: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 1uMLh0-0006Xc-Ie; Tue, 03 Jun 2025 07:04:14 +0000
Received: by outflank-mailman (input) for mailman id 1004035;
 Tue, 03 Jun 2025 07: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 1uMLgz-0006XR-3o
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 07:04:13 +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 f2f0a92c-4048-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 09:04:10 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3a50fc7ac4dso838368f8f.0
 for ; Tue, 03 Jun 2025 00:04:11 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23506bdd06fsm81387255ad.101.2025.06.03.00.04.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 03 Jun 2025 00:04:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f2f0a92c-4048-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1748934250; x=1749539050; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ORnZR+XmtviWUd4DceF+imR5GCBsuWqg3AXM9xbvPwk=;
        b=E/z0m/+OYkUDlv6MwahqSnqkCFyawzDbM3aorIYRa7pebgkkoK+b2eYbWi5L+H1ArO
         Exy1iXLbW65omaUZLCLag4kQjAJCUKWVUMUJNWPd6u1ch/j64BrzEZY7sA+b8vTdchpZ
         /crLEPCOd7qdJFOQaya0YsbJ8ruXOlw2AcBXF7qyXfLN6Tj5libiM32xkPPQnr56p0L7
         sLdgg3xGHoWLbDc4+6kq2xDTyoPmiRUodXbYFepTz4awcy4u6K559BpuSR1sDqm9LTk8
         8mGfvAPIGb87WE5Sx8cArROh9d0xq4B7JPZxIRPHMpGsSmggBqbmWZ1w/Hqc3uwh8V/b
         8k3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748934250; x=1749539050;
        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=ORnZR+XmtviWUd4DceF+imR5GCBsuWqg3AXM9xbvPwk=;
        b=pcTOFl/TmlplwDo+qE1LceDibsoY0gmex5kkfpZfEjWT3KnAye0UCWYPx3glUKfJPs
         J6KbDXW+lY725GdCr3rWb7VaD5F3LydPM2s7kv0c3IjU81bqXXCqWBHCPlsGAmel4iOY
         ogbrfB2v8GnrqwbJMK00UNIKsCO7Y1Yif06bm8rwMOpZi0Idk7lazXH1UtUrZPIABOrl
         w4xPRwaiviastj+b8XSKA/Lx8EbzTrQvS99p6BWVhIbIKkfhEV6Z8y3tN7Ui+Etw0NB2
         KV40v/p+o+3c7ApIx/qMK5qiKNZyonCAZx2cPbMEBfYdfhH8YbZjFK//YSN283yq20hR
         MdZg==
X-Forwarded-Encrypted: i=1; AJvYcCXJWjvI4zWXn1sdO1++5kyHoM8mlYpQEUBTEuoaxoNn5IiCjHhGFs0PI7FGcxA1n/dJ/7QJsVqnnYE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxI11fmLzo038f379McD/+NxivKtw+sqiEuwQ4YVvp4kfq3jCN7
	8Uc6WCMkoV7lHAzdRY9N5Rl0k3HlcYUpLBwOUgXFkmyRZ93RZuBrD3U/Xjn7/NYBcw==
X-Gm-Gg: ASbGnctsvqzjDgL8DOcxq2NLRsdOUNeBLPZyQZd4yslH8iobNxpXGgufq8VkSKJiuci
	Tm6HGN9CAqXLnxGng7sWpQn5/fXrAAs9h2oOkqnKzWqbAj0jfOujLRUELAYh6NnGjuDTGIHNQZq
	PhIWyIUm5DPNvyMPFcIDT8YUa3iTZI/eIXgOol/j0E2Gz/Tg2qJAYWMv5p477aDAkcsO4ct1Cpl
	hdE4qW2BDXUwC8Myh05YlvEig4b7jRiXQnjGqVtI6vBh9TKtcpRMuAoNMo+EJPm8of++eVwRZii
	0p1snrgU+MjW2sC6v+FtUuxT3ClWEDeJcr3zcOC6IIYIDNL0j4PLrFwbBF8e/BIeSK8xRaidWjQ
	wOJbK4DFCNGyJ2dsTgkrxxaJgK/LnS9zP9lN7byX4RIIpLEI=
X-Google-Smtp-Source: AGHT+IE8pK7zGtL1AJLsB0tbOLPxh5UomnWluJkrrR1rQ1O1WCjrbkYPSeQoGBW/KDKt4b+NOLg7Qw==
X-Received: by 2002:a05:6000:4025:b0:3a3:63d3:369a with SMTP id ffacd0b85a97d-3a4f7a63dfcmr12894877f8f.25.1748934250542;
        Tue, 03 Jun 2025 00:04:10 -0700 (PDT)
Message-ID: <87224eb9-d4a6-4589-8cc2-e222619f8dde@suse.com>
Date: Tue, 3 Jun 2025 09:04:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 07/19] arm/gnttab: Break cycle between asm/grant_table.h
 and xen/grant_table.h
To: Alejandro Vallejo 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org
References: 
 <20250530120242.39398-1-agarciav@amd.com>
 <20250530120242.39398-8-agarciav@amd.com>
 <5f3de127-70cd-422f-a368-6c23d83c6cf9@suse.com>
 
 <6cc4d172-793b-4d3e-990e-f8fd0d4bbabc@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.06.2025 18:39, Alejandro Vallejo wrote:
> On Mon Jun 2, 2025 at 4:51 PM CEST, Jan Beulich wrote:
>> On 02.06.2025 16:30, Alejandro Vallejo wrote:
>>> On Mon Jun 2, 2025 at 9:53 AM CEST, Jan Beulich wrote:
>>>> On 30.05.2025 14:02, Alejandro Vallejo wrote:> --- a/xen/include/xen/grant_table.h
>>>>> +++ b/xen/include/xen/grant_table.h
>>>>> @@ -27,7 +27,7 @@
>>>>>  #include 
>>>>>  #include 
>>>>>  
>>>>> -#ifdef CONFIG_GRANT_TABLE
>>>>> +#if __has_include("asm/grant_table.h")
>>>>>  #include 
>>>>>  #endif
>>>>
>>>> This change looks wrong (or otherwise is lacking justification): With GRANT_TABLE=n
>>>> the arch header isn't supposed to be included.
>>>
>>> It's not equivalent to the previous code; but that's a feature, not a bug.
>>>
>>> Not including the header with GRANT_TABLE=n  was the best we could with
>>> the older toolchains in order to not try to include a header that might not
>>> exist. The high number of sequential inclusions of xen/grant_table.h and
>>> asm/grant_table.h seem to attest to that.
>>>
>>> I can ammend the commit message to be clearer, but IMO this is what it was always
>>> meant to be. I can replace the current commit message with:
>>>
>>>   "The previous toolchain base version didn't provide __has_include(), which
>>>    allows conditional inclusion based on a header's existence. Lacking that
>>>    feature the inclusion was guarded by the GRANT_TABLE option being present
>>>    but even then sometimes the arch-specific header is required even when
>>>    the option is not selected. This causes inclusion sites to needlessly
>>>    include both asm/grant_table.h and xen/grant_table.h.
>>>
>>>    Using __has_include() removes this requirement at inclusion sites."
>>>
>>> Thoughts?
>>
>> So why would we include a header we don't need when GRANT_TABLE=n? Overall
>> we're trying to reduce dependency trees rather than growing them further.
> 
> Because we do need it or the code doesn't compile. gnttab_dom0_frames(), for
> instance, exists and is used in unguarded statements.

I fear I don't understand this: Things are building fine right now, aren't
they?

> There's more case like
> that. It may be possible to break those dependencies so the inclusion is
> not always expected, but the reality is that you tend to need the other header
> for pretty much the same class of reasons you needed xen/grant_table.h to begin
> with.
> 
> Forcing the code to include both seems counter-productive to me.

Depends on how frequent the double inclusion is, imo.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 07:06:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 07:06:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004042.1383694 (Exim 4.92)
	(envelope-from )
	id 1uMLjH-00076b-15; Tue, 03 Jun 2025 07:06:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004042.1383694; Tue, 03 Jun 2025 07:06: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 1uMLjG-00076U-UV; Tue, 03 Jun 2025 07:06:34 +0000
Received: by outflank-mailman (input) for mailman id 1004042;
 Tue, 03 Jun 2025 07:06: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 1uMLjF-00076O-NK
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 07:06:33 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20616.outbound.protection.outlook.com
 [2a01:111:f403:2414::616])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 46dbc051-4049-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 09:06:32 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by BL4PR12MB9721.namprd12.prod.outlook.com (2603:10b6:208:4ed::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.37; Tue, 3 Jun
 2025 07:06:28 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8792.034; Tue, 3 Jun 2025
 07:06: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: 46dbc051-4049-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Rf4+LKM2BnWbpHaZZaAL5oqreUIz0hHy817vCK3T5TYMP0y6SCJtWqLd6n4dQ3BWclX9hC/Nv9WpdIxBNmYSOzXJ501KXvnE+4EHt/7/pzUAuXrvGwLWpTYFIeFy3EpnwHinnCWwwkTbz3IpQlTvQqoiJQGSf9Hsg9ht5EdpQQ0NNK8wjm1A0aTuKkxwMkwiP4pnXlYN/YOWlkKcUW6h6F02iKqM1TmxdvcAjyOSS1X9yWxuhinKKr3Lo1008+M7fJ7aP2tnspEsn0L6r09WzKhMBM4oL4idVYDjm0lkkDbQNFBivtFszF6WBGP0rozHu+KmUExF/80pMz4rG+dQJA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=KzHA8aNUoQ51r6qgLWtnZ4Rk2D5NHDuVcoTBZjKWNL4=;
 b=lyIutpzVHorVYH3XKKxU8gcSHFy3kGqFOfEjem19Mz5ZQThHt67uYTjUgoOQPEkAXe+8VRBWwxUT2bbS7LBKX2ox+bhMn30MZ1K/88tc1dkGwc0MDykNLq/6o1lFrkpbPUzLahN4bfkFOPmP2xtd7a5JWweqJdcc/3FgAUtJ7IUBE55NNcIU7wQr70BJ9wKYL4sKnAfF9WnHfhteQfpXzaD8boIPp5Jwwd8/Ni3YUhxtXFounFmU0ch17Bb/CRhWR/cH33To4KDxsW25sKwfjRcKgIkQYJtpJsMkxM+EsOZTU7ljjxZqLmw0BnpegqtNJWgsSGBqz1hLZzQmNHDczw==
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=KzHA8aNUoQ51r6qgLWtnZ4Rk2D5NHDuVcoTBZjKWNL4=;
 b=I8viwF++U20hS+DfeMZSS0i8EEr7BETAIXNySBn2HzboNhQ+evtfU8bg7ZiUWquwalVu5TpsqmMCy7+zs4qaxSGDzunWp3KtsXjOrz7ycKy6Q0LXe9IFzC4toe2+wQkgQs/F0OfIsUARuBpsHKIQNtGcyeJntGtX2IS1FTiEotM=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <4a806a75-0a2a-45b9-8811-caa51321a6b8@amd.com>
Date: Tue, 3 Jun 2025 09:06:24 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] device-tree: Move Arm's static-evtchn feature to common
To: Jan Beulich 
Cc: 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: <20250527082117.120214-1-michal.orzel@amd.com>
 <344823d0-eb05-48e5-80c5-9598104f3a3b@suse.com>
 <28a9f398-d206-4e42-b627-bea71f038b4d@amd.com>
 
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: PA7P264CA0245.FRAP264.PROD.OUTLOOK.COM
 (2603:10a6:102:371::6) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|BL4PR12MB9721:EE_
X-MS-Office365-Filtering-Correlation-Id: 514a0087-70c1-4de0-199a-08dda26d28e7
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?V0tsUUlPYksrOVZGS2VpQ0dwMlNVYStJU2U4SlJFbHpuYVlzN2JXRVhFdFVr?=
 =?utf-8?B?NEp4NEVEQWtxRkpOUHVtSjA4SmpxbDh3Tmk0Q1hQTkNmNVhuWkhobnRYL0VW?=
 =?utf-8?B?YmlSOEVyNmxiMUtHUm95VXBCbitCWnFqVlpRcWFSMGwrVHA5a09KdUFoYThK?=
 =?utf-8?B?VXRVa3I0U3NxZEJRdWx0d2dRT3I4Ylo0b3VpR2F4MVZwNGlDN1FuUWdNd1hy?=
 =?utf-8?B?emhYb0IvRGhMYTAzZTJvcmIzNXNkcUpXTTJOMHlUNTlZT3RzZUJYOUM4eS9X?=
 =?utf-8?B?Y1lQNUo5dHdWcEQrQjM3VHdZTEcxVTM4VFJLbmVRa1Q4UFQzZUJ6S1hPNnJU?=
 =?utf-8?B?K0hFWEdkQzlGdy9vMk93ZHdZd0pXbHE3YjB1K0JNZUxNNFJobk1PTk5CdG56?=
 =?utf-8?B?ZXhPRzNjMVJVWnJlOGJuS1M0NXlWV1plVEhWczZpbi9ES096Tmp5MmdaTG53?=
 =?utf-8?B?SnAxazlnSXZYRlNpU1pLQy96WGFPb0FzaG5jSzd6blB0b1l2SXAyRFpuTy81?=
 =?utf-8?B?enI3M05GZWljNFRQTkx3b0JhSlQzR1FOeGxDVEppcmowMzl1emY0Y21qMSta?=
 =?utf-8?B?Q0J2VlRpK09hVGNxWkdGUmpnTEhxKzY3WGNhNHoyTHcrczZ2Sms2dWJadC84?=
 =?utf-8?B?R0FrZWRwMGdLMjhTRGN4YVNZOVBhN3ZIc3QxMHVvL1g2aFV2TDgvSkxCdFRp?=
 =?utf-8?B?cUdLbFRyRHAzM0YvVEZyd0dpeTNXRnM3dVVvM2dEenJ0NGQzdTJyc1UwM3Fo?=
 =?utf-8?B?ZGpJT29GaUxQWVFnRkNDZjREMllQeGdXWnNFWGVmanNIR1g3bnd3ZUlCb2Fj?=
 =?utf-8?B?R3NzR28vcXkxT1VHN2VhTFJVa3cwc1VqV20ySHhROHM4aWZabEJqY2tHQWh1?=
 =?utf-8?B?RDhGT01nZlBBbzhubzlFNEo2S3owSlFsbU85aXc2bHZpQUJxU2NwZzFaL2F2?=
 =?utf-8?B?YjRsWDErWnNrT2ZYbzg4RGdRdkVkZysrZUJ1dmRUWHNVbm1mT2h3YnVPRlZC?=
 =?utf-8?B?SzdiNXFjVXBSU0RlZ0dnVGp6SUhGY2d3SHdqUVRLejVpMjJpOEdDMStLcFRU?=
 =?utf-8?B?MHVIOXBEc2NQbVp1LzJlb0ZHV1ZoWFUrUUJnOFVYd3lyamN3Q3ZXQ3ZDM3Z6?=
 =?utf-8?B?QlMvZURMZERtbzZPc2RsK3BtbXF0MnRBSDAvNldkdzdlOU91U0drZ2I3SGRX?=
 =?utf-8?B?bmx2VzZuOHdjK3J0OGt4Tm5GVDh3ajlLbHpWbkJoelgzOTNZdjlvc3dvWW1U?=
 =?utf-8?B?K3VLNW15R1NvbStjM01nZlRZbGFWdzB4eUdjU2VJckxOQlZFQTNlVmhINTht?=
 =?utf-8?B?V05rKzlZVFRlREh1bnFPWGNGKzJzZUJMdUdubVkwZ3pBNG9vbHVxU2h3UDRt?=
 =?utf-8?B?L1kvb1NVOXRBNyswTTBvTkRiWUVoS3BJT0lJZzJNQ3FZUlZVbXY5UWdtSlVH?=
 =?utf-8?B?Nm1TbFlVemc1Y1ZOU0VBSFUxU0xPMUlNb2pOTGFJMmNKVFdhcXQxckNLMGZN?=
 =?utf-8?B?TjlaaW5LSVkwOGpTSDZpZ01lNUJXcmRZRjcweUJBL2FESnQ4OUpjbkMwM2pS?=
 =?utf-8?B?dGNiL1BmNXEzNitJUHZuN0FCVVBDNVM4UlBtQTlPZkZKcm1wQ3FzZC91RmFQ?=
 =?utf-8?B?M21YZjluK3VoQ2RlVWRoNlJzZmdrQkUwb04rVkE1WWUvVWxCS01CSjBnVjc1?=
 =?utf-8?B?blN3NThDWkN4ZUNlK0dsMVR6Ny9ndHZQek85OHUvdWo0ZTRaZk41bHdNeGlz?=
 =?utf-8?B?MEF4ZWdZVWZueFVXZTJVcjEwV3h6VkhPckVoeUV3LzZDK2FEVjRCeGN4cTZV?=
 =?utf-8?B?QWFiVlBlZ2NPWHN4dzh3WlM3cmJ1Y2t2WW9NeWpaYkF0R05nQ1JEYnNiUUQy?=
 =?utf-8?B?VmxvMk5qKytPdURZZW13d2o5MVVDRzEyRU4rL1c3bHlSSi9ZbDRZYmJwdnUy?=
 =?utf-8?Q?l8EnlOttkLI=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.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?Q0JGYjltUDdHdnIzd0x2RWZWajBxRmtaTGZKMWhGRnNDRlhqREZwcm9WdFdn?=
 =?utf-8?B?UkRVbWZUaVlkZ3Z3OXpncFJvUnNqekF4QUd0UlpYNjRsWldZVUtaV1hpNkdW?=
 =?utf-8?B?eEdCTXljZ0R5d1JLVkFlTWhDdWdjNlVMaTdzYVhneDVySW4xN1ptOUl3M1Jy?=
 =?utf-8?B?Zk9McG81VDU2T2R5Q0x2MlBZaVo2QmsxZm1xTDcrSmFqV1lhSktpbTQ2V0JV?=
 =?utf-8?B?WnlaV3VIYmJWdm5RUWxVZldrcDhLUEdjTHIrdXNNb3ZpWmZUQ1gyZ05JWEJo?=
 =?utf-8?B?LzlEVXc3T0UzNzJHVlVWdi9XaDNCL1RicGVhUjBnRUNUM3VwbDJWcTZoa0Yz?=
 =?utf-8?B?NnNtei8xU0poZmw2YUU1WmdwNHpkVmdyKzRReHNETjVleHNVdWpJaUp3SGE1?=
 =?utf-8?B?aUJXWk5RZGJDQXVRSFhpTDl0NE5NMmNubGM3ZSt1OXBKcGlVblFaaWdnWURP?=
 =?utf-8?B?cGx6UFlKZ21vNXZnUG94bHRuQWZyV1NmUTZMdmZuQ2FOTFRMWnFlV0NnY3E3?=
 =?utf-8?B?Tkg4N3htcFhGT0U5ZHFaUlFjU3NIZEJJYndMZndjY1ZqaHZQbDAzUndyb2NQ?=
 =?utf-8?B?UWcwdVd3c3pkeEgzMUZOazR3V3djNWhxVTBtVmRTWTJ1N0srMm4rK0dUSmRK?=
 =?utf-8?B?c1pUVkIxYUk5aURjMjAwcVhRQzNjQlM1d0JCK2U2TXlSZlVFVjJoU1pzWkps?=
 =?utf-8?B?UXB6SEZJdGlhd3AwaVpzbmx5M0tvMmk5dEExcTg1QmxUOWZCa3JNMlVudnFS?=
 =?utf-8?B?M2lQNjlBQWZqT3RtVkJoRHpkbDdPb2IzOWJDRkVzVjZJV2RqQ1ZoVkRVUkNi?=
 =?utf-8?B?VGNxeTFjT2x4NGpTYUtmU0REdS9PMmY2ZTh1WGZhZVUra3BROURpYzk1K0RJ?=
 =?utf-8?B?cmlmQ1FRdnFLVWpRQkNUYjNPbUsxeVBMMmFpWjFHV1dFNVQyd2J2SVZzTWxL?=
 =?utf-8?B?NEN6ZmE1eTBvVFVTa2U2NWJPVWdTVmVkR3pwUU0zRlJXcnVKUEcwNGEyeWNT?=
 =?utf-8?B?SDloOFJ6WW5SQmxpOGdYYnBPOHArNWRnbkhJL3Y5WHRiZFZsbjc4blFQVUNI?=
 =?utf-8?B?b3hFUVhqSEtUVEk2WVF2NGdRSDVsWld2UUtlbGhaZUFIOWRpMHgvWUs5MW9v?=
 =?utf-8?B?Y3pWZkdOYUdGVjc4RDNFRmJCeFN0WDlFY0c1SVJ1ZkZLMzNtd0dyb1B6dmhm?=
 =?utf-8?B?ekdGRjRjcGVoK3RTY0lmVjVyNVBGdUhQOWxvSkwwNTRPc25Qbk10NnlSUjJ2?=
 =?utf-8?B?QktOUTNPMjBXVERMdFBTTjg1alVpRHRFK3M3OXdPUXJIeVlZUVdEeHBsdFl3?=
 =?utf-8?B?QmF3UUVJdzJvUDBXaHVjdUtyejR2T1BhcFRvVXIzMmFNdFlKSEIwTk5WblRu?=
 =?utf-8?B?OUJudVlTRVN1eUUvVm1PSnlGWnlUNWRqY05wYkVZQVQ1VzhyU3I3T2w2Z0Rk?=
 =?utf-8?B?ZGM2Zll2NTRuZVMxajJPeEVuOG8wTmUxalAzV0oyZkFPYVc0dHphVFExMzdM?=
 =?utf-8?B?MnVzSWx2VURaU3ZEbGZ2OFEzTmhibWJQa1VqR0dUcWVteGZGSDg2QkxuaXNu?=
 =?utf-8?B?SHFQNVNtUnZ2Q291Y000TjlPVkxKTU5rYW9JblFrbGU1ak5UWUh5TElCNzJl?=
 =?utf-8?B?MStMbW0reXFnYVltVlhEMmRVU0hYdVRZQ0VmTndORmpHd2R4c0ZZRVpmTkNG?=
 =?utf-8?B?bWNuQWJ0ZnZXNlQ3cElYUUo2K0xHb08wQWhCZjhTY2p4Vkp4OHNRMWpydzBk?=
 =?utf-8?B?OWhtTGJKQjltcFNVQ3cySEFJRllLTnlFMkhiNklCbmZLOTErSDdlNC8ya1I4?=
 =?utf-8?B?eW94cGtPVi9qbkdjMHhkUUJqYXNrWnFVWG9BRUpITDhPblcybXREcG5GNW9x?=
 =?utf-8?B?UmtKUHRacUJYSGN1TW1qM0loL0V5Rkh2UFB5VjZMU2NZdDRLMllIRk5BWVRZ?=
 =?utf-8?B?RHNIUG9qdTZwZjRpaVhDWnFXaXlQcit3ZHI0TmRpczkydkhaL0pnbWdNbjdi?=
 =?utf-8?B?bnF1MGRkWG9BUHBFcU9YSXFMNm5nbXVkV2pmdFFOQURtSkd6QmY5QnBlWWxF?=
 =?utf-8?B?MnQrWkNadWsxaVAweE9LdGFkK0Y2dzRUN3R1VndRWkMxQ1lndGozblZ4QnVq?=
 =?utf-8?Q?CAmZY9Zz76lBJQUfifMFUzdj3?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 514a0087-70c1-4de0-199a-08dda26d28e7
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jun 2025 07:06:27.9622
 (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: cR/+b2fWcOG0aZWxbwFBJDHl448lK5XXdFYs2IVwFe/KMIMucliyHCLwCVSiPoi7
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL4PR12MB9721



On 03/06/2025 09:02, Jan Beulich wrote:
> On 03.06.2025 08:54, Orzel, Michal wrote:
>>
>>
>> On 02/06/2025 10:37, Jan Beulich wrote:
>>> On 27.05.2025 10:21, Michal Orzel wrote:
>>>> There's nothing Arm specific about this feature. Move it to common as
>>>> part of a larger activity to commonalize device tree related features.
>>>> For now, select it only for ARM until others (e.g. RISC-V) verify it
>>>> works for them too.
>>>>
>>>> Signed-off-by: Michal Orzel 
>>>
>>> I realize this was already committed, but ...
>>>
>>>> --- a/xen/common/Kconfig
>>>> +++ b/xen/common/Kconfig
>>>> @@ -162,6 +162,14 @@ config STATIC_MEMORY
>>>>  
>>>>  	  If unsure, say N.
>>>>  
>>>> +config STATIC_EVTCHN
>>>> +	bool "Static event channel support on a dom0less system"
>>>> +	depends on DOM0LESS_BOOT && ARM
>>>
>>> ... I think we should strive to avoid such arch dependencies; they simply
>>> don't scale very well. Instead (if needed) HAS_* should be introduced, which
>>> each interested arch can select. In the case here, however, perhaps
>>> DOM0LESS_BOOT alone would have been sufficient as a dependency?
>> What if e.g. RISC-V wants to enable dom0less but not static evtchn/memory/shmem
>> because there are some functions to be implemented and they don't want to do it
>> now? Protecting with just DOM0LESS_BOOT would not be sufficient here.
> 
> Imo a transient(!) "depends on !RISCV" would in principle be fine, if ...
In this case, how can I know that upfront? When moving a feature I need to put
some dependencies. At that point I don't know RISCV, PPC plans. The only thing I
know is that I tested this feature on Arm. So the only meaningful dependency is
& ARM.

~Michal



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 07:07:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 07:07:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004051.1383704 (Exim 4.92)
	(envelope-from )
	id 1uMLjm-0007dF-Bh; Tue, 03 Jun 2025 07:07:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004051.1383704; Tue, 03 Jun 2025 07:07: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 1uMLjm-0007d8-8j; Tue, 03 Jun 2025 07:07:06 +0000
Received: by outflank-mailman (input) for mailman id 1004051;
 Tue, 03 Jun 2025 07:07: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 1uMLjk-00076O-Cv
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 07:07: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 5a21fc06-4049-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 09:07:03 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a507e88b0aso1808696f8f.1
 for ; Tue, 03 Jun 2025 00:07:03 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23506cd8d06sm81242915ad.143.2025.06.03.00.06.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 03 Jun 2025 00:07:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5a21fc06-4049-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1748934423; x=1749539223; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Mk3zj09tfKC6WcxhJF3QCL1xgpQdaYGCvL/chwb+SWU=;
        b=HEsbZNGHOIJhWcqpP9EUKQ+d1UwIt1uaqVt6F4zNMkL2N3EoKmhUKmxCF5yZIxiSak
         2XSoPLKoQx0EBnf4opwOQscfUlf14BQ66Nhq4dRE4RE4sKlLfTNmauBkB6XiN8lNKgV+
         b6MDKCY2JR9FijB7vkCuJBAc64PJ6hqU95UNT81JfAXmbOIfmcv55YyKi5DTGwH8Defd
         8EUE9cWaam3vWP2i/SgnmL5JYV6vt4NPor+P5ghZJvK7drKl+yY61nohwdF3xKTw/pt4
         g3CV13A9LjbS8o+KjUkE64TrDOYwPJyKaXV0yMGzHEsVkxlp1hf1ROxI5xeEOf1PAoEX
         a25g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748934423; x=1749539223;
        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=Mk3zj09tfKC6WcxhJF3QCL1xgpQdaYGCvL/chwb+SWU=;
        b=nMzBp7qQPJO0PYH5lFF0l92y91uhyRJirr39dEPQmXuwog79IlL343ALYn3pIEeabH
         7e2jKhSYa4OiIbWcDWHDqTEz4iDDh3f2nZeWuzouOhV+8fRig0IEoleeH0N0JDhLkLHU
         c3ZYa/W8c7uS/kaYVRfWbSq1lo/i48VJNftQJ8i8TE8RfWsbVI350jhcJ/9VQiEtTosh
         D2gnVo3eXVNDmaibMT4SEILT4OYVMxTtjaIZyxwC2PWtYGLbExBgoBjBe7buIbV9Yf1h
         tK5CDWOSyxvDCSYUBO2WTvS5Ctx/yVbtoTNBqzQu5QK1XVML9HNyH1HWfxI9iYQBzUzC
         PBAA==
X-Forwarded-Encrypted: i=1; AJvYcCUc1lLLKGEMxp42fNsHc5zG/nkOITNk+6wN4yk1IDh8DROL7x14zTUBvJh4kHM+ksvZwOn569+n/A8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyYLb9P4zO8AyabpisuGZSkdUiCiOucdV4cKEQPysFmRILjLaHo
	oEOAZNRn+wpLShgde9p8AKWKdulSsNKipeC4vGAo+q/zy6IIkggUHDHxG9PKL/yUzA==
X-Gm-Gg: ASbGncse1mc2S31gdaMoVn1vvfvVyqQwy5V3fQi19mBPsZYnkoqBJ3e5j8RjiMI3iYO
	sKsKq71gafTwTlKrI/PKji5NUkhtSDN2Qmd9W7OGIx1KOC1YrPEmhJbvqbrVLZrV5yB8p80I++p
	PRuxdTA1AVR2B0xt4t3bwSHpDhsjmC/cdrowV4NyiXt20QbBx4VYkWHAFd2toqufZZfjwn4h2eG
	wKPF5QLGxn/rWa3pVT8P35s3+2R9pL4cCUO7uLcinxscKaZ5XbCPGJMliaqcx+qhLT0U3+Zax8y
	P71/gT0+Wf+AXQ25yC6KB+wVR3ifPHoMPiiRgCmXDimZXDBUvtcKtD9Mbs1qleBpHaadfPyjt7h
	vLcFVzCdNRw7dBunp9i/L01TTdkxmQbwz3IegnCUyPDweckU=
X-Google-Smtp-Source: AGHT+IGv6TKooDvpwY1ohwdW8gMyvs1IsDyq7rJb3ZDjUWA5eCxKB4ow6nGWJ5O4GeQaGYClXzcNlQ==
X-Received: by 2002:a05:6000:1a8b:b0:3a4:f519:ed3 with SMTP id ffacd0b85a97d-3a4f89da770mr11074269f8f.44.1748934423338;
        Tue, 03 Jun 2025 00:07:03 -0700 (PDT)
Message-ID: 
Date: Tue, 3 Jun 2025 09:06:53 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 01/22] x86/include/asm/intel-txt.h: constants and
 accessors for TXT registers and heap
To: Sergii Dmytruk 
Cc: "Daniel P. Smith" ,
 Ross Philipson ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Lukasz Hawrylko , =?UTF-8?Q?Mateusz_M=C3=B3wka?=
 , trenchboot-devel@googlegroups.com,
 xen-devel@lists.xenproject.org
References: 
 
  
 <31c7faf1-d393-40d5-87f9-1a01d1ab39cb@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 03.06.2025 00:00, Sergii Dmytruk wrote:
> On Mon, Jun 02, 2025 at 09:17:37AM +0200, Jan Beulich wrote:
>> On 23.05.2025 21:51, Sergii Dmytruk wrote:
>>> On Wed, May 21, 2025 at 05:19:57PM +0200, Jan Beulich wrote:
>>>>> +static inline uint64_t txt_bios_data_size(void *heap)
>>>>
>>>> Here, below, and in general: Please try to have code be const-correct, i.e.
>>>> use pointers-to-const wherever applicable.
>>>
>>> I assume this doesn't apply to functions returning `void *`.  The
>>> approach used in libc is to accept pointers-to-const but then cast the
>>> constness away for the return value, but this header isn't a widely-used
>>> code.
>>
>> Which is, from all I know, bad practice not only by my own view.
> 
> I actually ended up doing that to have const-correctness in v3.  In the
> absence of function overloads the casts have to be somewhere, can put
> them in the calling code instead.

Casts of which kind? For context: There shouldn't be any casting away of
const-ness (or volatile-ness, for the sake of completeness).

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 07:09:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 07:09:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004060.1383714 (Exim 4.92)
	(envelope-from )
	id 1uMLlt-0008DR-Mb; Tue, 03 Jun 2025 07:09:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004060.1383714; Tue, 03 Jun 2025 07:09:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMLlt-0008DK-K2; Tue, 03 Jun 2025 07:09:17 +0000
Received: by outflank-mailman (input) for mailman id 1004060;
 Tue, 03 Jun 2025 07:09: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 1uMLls-0008DE-Dr
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 07:09:16 +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 a8ac187e-4049-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 09:09:15 +0200 (CEST)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-451dbe494d6so19327335e9.1
 for ; Tue, 03 Jun 2025 00:09:15 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23506d2570bsm81127895ad.213.2025.06.03.00.09.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 03 Jun 2025 00:09:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a8ac187e-4049-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1748934555; x=1749539355; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=zmYRQJIV4xD9r78SxM/5uplqf7yexMbfIEJ4yae6NXU=;
        b=GcpQwZNcri5T9/6dd+Ig1UfSlxxBcny7ah9qJ1rgZwdp7rMyRYi8G8P3CPglF6MLmo
         dlEcK0q8bu+9OurRg99Vk5PJRtOJdAPdYnV0Lt89zeYDfgVnfcxqAlRhYm/Bt0elV8cV
         izO4eVYQjlYdlb0wHq6eKbVLTOb72a72TnVL+/aIY02w6lVfnlGUX89h6dfGZL2AeR4N
         zyQYMJdLAsvExEUMJQZf/RD8xsBxZiB6pwof+4L6TYD8WqXBpFjcOWDWTGPbtVF56FVz
         81Dxk57iJ839BUQ5hiHx+Ap+xTMBPSC5eBqaBdbNoMyxo3SXKJv/KXc7PVpyZGvvSxQS
         uw5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748934555; x=1749539355;
        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=zmYRQJIV4xD9r78SxM/5uplqf7yexMbfIEJ4yae6NXU=;
        b=p/KebMo+KAq0nypqeVfw9OQUq+LphrQA7wgFAqhkHZWJzLefq7kD3mlO9lM/89tSic
         TnU0LCIB2AR3ctd+cKQ+MczCuraZqOaIAuwK8h9/u1O7te9hp2+l60ytOgjbNfWRByyl
         P57p+OpSypwMllEwskctClOPc7LdPCyye4moB23NuERNwOJAVYgG58uGz7Vh0paSMy9Z
         kuXUdIWSbBMQkuCUwBGQjN2X7HF24MUMhL3Lf5FdG6AKnIffua2ftaluxGURd5HmF1o7
         ofmkx6tvCgoiOpLXoa/fk+tPhy0VomG6p1LqkNILbhUUVVMzpcusHjLFFLrzNcllb+/z
         +b/w==
X-Forwarded-Encrypted: i=1; AJvYcCVI9w7bMAxR4Vwsuj99zta4qmoOkAD7+i/rnkhI3Ys8rUYCLEQT6dpuV2piKifHZO0d2K2459khodg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz9uWmFXzT+iz8fD9mbW+FPJ+AANsycTkk13xkEmr3xmKQ0vbAU
	oef9kzpx/A5FIjjcIwhjvRl3IyY9BwHGJoiAz4vCupdKAX5mvaiB1TU/YU7O2uToPg==
X-Gm-Gg: ASbGncv4LHs10cte/k80Rm2Aw9eedq6eaDOI0GgSM/2lqkDC13RkOd/MzWXOcmPTh5d
	QyykunmsOihfY1+G/bwFYOyyj7PnVKPRrgeyIlKjZncjbMHkF4AFX9VluIYo+55Lufp0jaoTv2G
	CCmT8vIrKzOn7jdUxx81D9ha+I8TonxsGmywvgzrqwamRD7vsXktqetMC9ssRRnBlKemGu80Ani
	9pmQdGEuRZ+kP0qKwtEWVqPl2QLTaC0WTABQZFB86m502/9MZV1qOYO8yqmu78Qu0DODr33xpU+
	36pwXfVyGvUctQNNPujE+xz399Pcg5vzx3EM/q39zv1CzDFml0bfkpLPYICIaPbTxIy3igcSjYT
	Q9/grIUMNUt48QjEWaO7BzcTERqloum0ntxlO
X-Google-Smtp-Source: AGHT+IF+WSh2UjOODrZtVN0JQVQXfYzLbn/gBQg4cJPaBpuwUSHABhpPm8FsZQ6CEHWo65/MHmD/8g==
X-Received: by 2002:a05:6000:1a8e:b0:3a4:f655:8c4d with SMTP id ffacd0b85a97d-3a4fe393647mr9164266f8f.27.1748934554984;
        Tue, 03 Jun 2025 00:09:14 -0700 (PDT)
Message-ID: <93b76d35-7d08-4fc9-890a-4657004f226a@suse.com>
Date: Tue, 3 Jun 2025 09:09:05 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] device-tree: Move Arm's static-evtchn feature to common
To: "Orzel, Michal" 
Cc: 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: <20250527082117.120214-1-michal.orzel@amd.com>
 <344823d0-eb05-48e5-80c5-9598104f3a3b@suse.com>
 <28a9f398-d206-4e42-b627-bea71f038b4d@amd.com>
 
 <4a806a75-0a2a-45b9-8811-caa51321a6b8@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: <4a806a75-0a2a-45b9-8811-caa51321a6b8@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 03.06.2025 09:06, Orzel, Michal wrote:
> 
> 
> On 03/06/2025 09:02, Jan Beulich wrote:
>> On 03.06.2025 08:54, Orzel, Michal wrote:
>>>
>>>
>>> On 02/06/2025 10:37, Jan Beulich wrote:
>>>> On 27.05.2025 10:21, Michal Orzel wrote:
>>>>> There's nothing Arm specific about this feature. Move it to common as
>>>>> part of a larger activity to commonalize device tree related features.
>>>>> For now, select it only for ARM until others (e.g. RISC-V) verify it
>>>>> works for them too.
>>>>>
>>>>> Signed-off-by: Michal Orzel 
>>>>
>>>> I realize this was already committed, but ...
>>>>
>>>>> --- a/xen/common/Kconfig
>>>>> +++ b/xen/common/Kconfig
>>>>> @@ -162,6 +162,14 @@ config STATIC_MEMORY
>>>>>  
>>>>>  	  If unsure, say N.
>>>>>  
>>>>> +config STATIC_EVTCHN
>>>>> +	bool "Static event channel support on a dom0less system"
>>>>> +	depends on DOM0LESS_BOOT && ARM
>>>>
>>>> ... I think we should strive to avoid such arch dependencies; they simply
>>>> don't scale very well. Instead (if needed) HAS_* should be introduced, which
>>>> each interested arch can select. In the case here, however, perhaps
>>>> DOM0LESS_BOOT alone would have been sufficient as a dependency?
>>> What if e.g. RISC-V wants to enable dom0less but not static evtchn/memory/shmem
>>> because there are some functions to be implemented and they don't want to do it
>>> now? Protecting with just DOM0LESS_BOOT would not be sufficient here.
>>
>> Imo a transient(!) "depends on !RISCV" would in principle be fine, if ...
> In this case, how can I know that upfront? When moving a feature I need to put
> some dependencies. At that point I don't know RISCV, PPC plans.

You don't need to know this up front, do you? Neither of the two presently selects
DOM0LESS_BOOT afaict, and hence such a transient negative dependency would (if
necessary in the first place) be added when adding such a select.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 07:13:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 07:13:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004067.1383724 (Exim 4.92)
	(envelope-from )
	id 1uMLq4-0001nA-6v; Tue, 03 Jun 2025 07:13:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004067.1383724; Tue, 03 Jun 2025 07:13: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 1uMLq4-0001n3-45; Tue, 03 Jun 2025 07:13:36 +0000
Received: by outflank-mailman (input) for mailman id 1004067;
 Tue, 03 Jun 2025 07:13: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 1uMLq2-0001mx-Qx
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 07:13:34 +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 41c976b1-404a-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 09:13:32 +0200 (CEST)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-450ccda1a6eso46830805e9.2
 for ; Tue, 03 Jun 2025 00:13:32 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-450d7f8edc0sm148046555e9.5.2025.06.03.00.13.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 03 Jun 2025 00:13:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 41c976b1-404a-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748934812; x=1749539612; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=rG1iWZMw+2XeySwtTaM02Zv29lkGfyJNeZ+kw5p6z5s=;
        b=k2TbZJAW7ntYwfvJK/mTbMLIsPwsKhMVqIwupccaIniDWkaurPRYaQKvY2XO96QiVf
         GyVVRvYwsk6Do2XVbKoJSju9Th3oIBq1i7Wl8ZdG5QuprMgDXPBwS1F3aItg1P9JvYqj
         SZS5oqJoL7cTkNLIoqbckLpHKCHg2Iy2BmIL0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748934812; x=1749539612;
        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=rG1iWZMw+2XeySwtTaM02Zv29lkGfyJNeZ+kw5p6z5s=;
        b=qePmjI+7SHlCdetg8GGLfxOAPYso8GE8cee8rtnYZ4ROxCm8ggp3JEL9kpLewuw1GE
         Z9TvbcVqmLjA7SSo7iAFmSh9T2u4KHvB1cUXQTtnjNSRYQBPn2APJECokY44AVNoCDPk
         SUY/1dYOCkwpFQ2wiSm2L5j+T9XRpqfoRs3f6KGLy0EA4v2HjeW35FYHZp/RhfscKzDV
         ckBy0L7xo7vfltvh7dPh80K7YMFzVzk+EqgiklcP0azHIR8F6zwtgSFgMhGTeRwu1jJU
         BHXdYl7lV1ZJHW/DoUK5zD/MRppCP0oFBRka0WZKkq0MVldi4hUrrGg55/HnXf96nHAZ
         pllQ==
X-Forwarded-Encrypted: i=1; AJvYcCUFpX7QfLez1DRqB0n69ML8HcMk7JFL4sijZBk0jiNIEG7azNQrSNbLBQLHXoWUjLTjCSEhWbzI5Ds=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy80feeo/SHZXbLCLUOei7xWPunUBFXTRBKTcHdzVTAhqiFtGZS
	3bhbruldwXjLCDRMWpVQqj/MuK+UPfOspehpDmVu52tQtS3NakHDL/VSD2ADAfHrN+o=
X-Gm-Gg: ASbGncv94HvcVZxXwTiPr15li77JSU9WnndBhEZ44kj8OP9T1WvouPepu0STgbz72p5
	powkzeBflg7AmxnniOVbtLOLS8xSUFGmXQ4LPHt2WeTI/i3XQkUBSbhoDyxUJxPu1EOuWw6BWyF
	iPvAQklf1rPVAwEuCz05G96l8CkG/Oy0tjYYghvDJza0LGaNu57ZdnddGOItScW1Ak+od5D1H1l
	VBuxUy1ivLebhCgZS1UmIutRLpHWZRSXBAZ+oVTcoslRK1Aj7gXMZUnVPAUunNojrqzU9Gw8KsJ
	aDZF3ZkwmNpTGYcQ71SJN8JnCchwIyWfkf60ni1d/vXGDiD3BAKrWvLjtcC3XS/subvX5MEl2zL
	svJ3wljHRueukMNNtrKBfisKG1Vs=
X-Google-Smtp-Source: AGHT+IFkoYhDTHulGIcVCXjcMo5Y67B5v5F1Nj3bD4IubfbtuHBi7OKGmqA7qrp0YI8T5/ACFOspQQ==
X-Received: by 2002:a05:600c:45cc:b0:44d:a244:4983 with SMTP id 5b1f17b1804b1-450d87fd9bemr158637505e9.3.1748934812281;
        Tue, 03 Jun 2025 00:13:32 -0700 (PDT)
Message-ID: <4c8b739b-52ee-4af1-8f4e-64230007a3ba@citrix.com>
Date: Tue, 3 Jun 2025 08:13:30 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] compat: add header guard to xlat.h
To: Jan Beulich ,
 "xen-devel@lists.xenproject.org" 
Cc: Julien Grall , Stefano Stabellini
 , Anthony PERARD ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 
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 03/06/2025 7:44 am, Jan Beulich wrote:
> This is to conform with Misra C:2012 Directive 4.10.
>
> Reported-by: Stefano Stabellini 
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 07:14:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 07:14:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004073.1383734 (Exim 4.92)
	(envelope-from )
	id 1uMLqb-0002EZ-EG; Tue, 03 Jun 2025 07:14:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004073.1383734; Tue, 03 Jun 2025 07: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 1uMLqb-0002ES-BZ; Tue, 03 Jun 2025 07:14:09 +0000
Received: by outflank-mailman (input) for mailman id 1004073;
 Tue, 03 Jun 2025 07: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 1uMLqa-0001mx-PT
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 07:14:08 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on2061c.outbound.protection.outlook.com
 [2a01:111:f403:2408::61c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 53baba2e-404a-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 09:14:03 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by SJ1PR12MB6363.namprd12.prod.outlook.com (2603:10b6:a03:453::9)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.36; Tue, 3 Jun
 2025 07:13:58 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8792.034; Tue, 3 Jun 2025
 07:13: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: 53baba2e-404a-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=eDSJjRwsNQ7RcVKpq0dJWxBTqzVNf7YadH+xmy5WdPSDMvy4UqAv62x+11yPMpvf4u/rCD+3Jm8Qk6afX/0+JKl+SKCvVP2sT33HTjf0F2UETSDXBd4yQ8qDWdV2TV4ZSDeC6PBNPBsKz/m23k4rUdDcXxA7HNYoyfYLkAXJokXTNpRxzylsTPg/5EDe/US8c/86a6Zmgfqinf4EeXIOz3ogSFww3YpoUVjx1g/7K8sSAP0Ih8fKKdu9TToUMtaUgvC1leeXFSnLIptqjI+rXLwt1LEMvAeeGNotxnyJ1UzTMtMmF3hg2S2y+B7Nmx8qryZtMYVZVw/HjkeAiyMgYQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=dvMQuWfpbG92+tRN/IWHo3py3BV7yqLkf6Wu/nxGDLQ=;
 b=Y9PEwAI+mQuxOU6MyNeLXfsHU+Jp/SyC2qWHjXSPLyumP4gFO7ltjzNUpioj7IWpV3iwKROJPeI/qjcjjKqildZjiI5ydj7OiExu8KwSJDWns2cWIM995PFyhXQYfMCbQf5ebxVqqbKBgRExCITBxIZtnY5nDB71+kTxl8MFwJOSirBq56EBTk8eKnD9auvXqX1npQ+oxUKR/qvO8BDxpTI/Uyu0RXqC69iL2eH0xEqcs0bimir2IzBndBJV/uciWoXoN6/zddjSAEzWkvgW0ktofnKdC1PwU4jO6Ld2mg7Cu/NG97e74fnVqzai3LAyT9UN/Cqto1VGOWeyIOF3fw==
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=dvMQuWfpbG92+tRN/IWHo3py3BV7yqLkf6Wu/nxGDLQ=;
 b=dS4MjgC1j8MAaKd57cBNJEPIRasAQwd8UCO/jCmsbry8FJk6y6V9Ol0KcbpS8bOEehq+tWs9XBRNhkyTWoNZ+hmN5935zeFEa+qPG1AXes8G8sDTusgtPDU8EKCZ50nkx5jq9EL18na5KSHCVJeso+cxobG/9jDuWyQgn3Pmo7A=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <29e19d28-103d-4e44-bdb7-dd42619625d5@amd.com>
Date: Tue, 3 Jun 2025 09:13:55 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] device-tree: Move Arm's static-evtchn feature to common
To: Jan Beulich 
Cc: 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: <20250527082117.120214-1-michal.orzel@amd.com>
 <344823d0-eb05-48e5-80c5-9598104f3a3b@suse.com>
 <28a9f398-d206-4e42-b627-bea71f038b4d@amd.com>
 
 <4a806a75-0a2a-45b9-8811-caa51321a6b8@amd.com>
 <93b76d35-7d08-4fc9-890a-4657004f226a@suse.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <93b76d35-7d08-4fc9-890a-4657004f226a@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR4P281CA0257.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:e8::11) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|SJ1PR12MB6363:EE_
X-MS-Office365-Filtering-Correlation-Id: 9c2050fc-f155-40f1-aba2-08dda26e358f
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?YUFFNEhIRVdhYkQyZVZlU1JySE5EVis2amN2V25oNWtZUDZqUEllVTBRcGht?=
 =?utf-8?B?eXY1TFl3b0pabGNYbjFyODRsaTVpVlc0QXV6eDFsTkRqVmZid055b0I1Ynh6?=
 =?utf-8?B?T3JDRU9aSHk2V2FLa1ZxMXlXMHF1TXkrUkNIeXhtcVd2L1E5MWJ1cENpbmhH?=
 =?utf-8?B?eDBiOGxEQ1RCWXdWOEZDbFZ4N2NJaENTNW1NLzUyS3M0OW0xMElEU1UyVG5s?=
 =?utf-8?B?RVFwY2V6bllab2xHejc0TTdPUHFGeEVEdkg3NzlqVmdXQnBMQzBROHBXYk95?=
 =?utf-8?B?MjhkczdReGlpTXErMmxyN05jU3czRlI3TTRoc1JhdThaZG1GY21kREdvY1c3?=
 =?utf-8?B?WWN3M0xjMnRycmpreUVJaXM2WU9vcXE2K2lMckcvalVSU1o2UTgrc0YwZkNu?=
 =?utf-8?B?aVYwaE0wRFR2b0c4bkxBVzBlNUZiT0Nva3BjQXFGTkxLaGUyRUk2V3pOZTdR?=
 =?utf-8?B?MW1BeTd1dkIxNWtvcUV4QUUvNEhxWkpFcWt0WmM5V2RiRjNLL0ZBT0RDV211?=
 =?utf-8?B?Zi9sc0llN1NROGdlZmxsdXdGbmZSdDNmRkJjTjBLZnd0cmVOaWNoWUpvbG15?=
 =?utf-8?B?Z3NwYVVQRzNsZ2gwVjl5RVJ0SkVJTXFTQW10Z0V4QW9US2kxM3RONTdZRWJh?=
 =?utf-8?B?S1BWQ1gwelBtVWhBUVhjeG5GYTZabVVEUzhGRis2NlFLWnRLT3dqdFFsTXpN?=
 =?utf-8?B?RXhGRFZHcTN1K3BPWHhIeTFtVTJ5Rm5BTGxCNWt0UWxCN1Zwdkszd2lwR05C?=
 =?utf-8?B?d01keEREeE5kSmU5Z3FLZVV5azliTzBPaEhuZFMxYVY5cWllZHo2bU41VGFj?=
 =?utf-8?B?eHBJeFYwSmtUQi9CTzRqQlRzb2JTc0NTMk5IY1lMNi80NU9jQ0pRSnJVcHZC?=
 =?utf-8?B?VXYvclNYeGhTVFY0eENlL2g1Z0hTUGh3R3FhZjlBc1J4TlpXaFZHVWZJSnEv?=
 =?utf-8?B?cVg1YzdNWHc2MUJVOFJUMThkK1BOaWpZcjkvYVd4VWRmcFVtZVVvVk40YnJr?=
 =?utf-8?B?dzF1cmZKN0hSMk1aTW9wYU52MCsydEZoUG9MS0w5NmdKYWw0MGNLaU9aRnk5?=
 =?utf-8?B?ejRpVW1hMW9kekpWU0R0SWd3YkhYQkZQQno1WmFLbHA4cHpCNVdabjdUUHgy?=
 =?utf-8?B?NFl3b0JSbUxKc2FyclM4V2FJYWNHaGY2anlreHhzSUlWL0l2SGlwN2RqLzBV?=
 =?utf-8?B?bGVtL0xUSEROZWFNVjJIMit1R2VYVFFHaUJqQ0xzeUJ2NEdKb0NTd0NTWVVn?=
 =?utf-8?B?ekYrSFRtMCswd2dmaXUydzRKNmVVa0hzR0tWUWJWYWZsUXlCeEFPYW9WNzZR?=
 =?utf-8?B?Y2pEajZJQ1ppL2t0UmJHNjZiMXlQcGtnTmV1UWs4d25HNWJrVU9hZjRvdml5?=
 =?utf-8?B?ZS9MSCtlRXMwblRidUdXdDRqUDZ0Z3JGUmo2dmdnUUVnaHpYQ2hCL3l3b1Jy?=
 =?utf-8?B?aEVYeXduSjlZMnNBaWlUM2NPbG9Wdmx3VHdwcExSVVJKczN6ZE1zbWhIUTdZ?=
 =?utf-8?B?enl4L1UyRnY0azB1ZEE2YU9rQi9lZzBKUWdBL0lXSUFQYlpXOGZ4dUVHbnBI?=
 =?utf-8?B?a0diZVd5YlVzZERxRGp2RFE1TTVPVkZBMU96T1JYdEZ4em83SldwL2pxQTVv?=
 =?utf-8?B?S3dlbzdPRlA3MHd6Z0pWSXd0QXQ3dkFCQ09uNXF1a0xRTFNzUFJPZXZOU21t?=
 =?utf-8?B?SnJEVTlFVUZwUU1IMkY4b21NRVJqQXNwNmlpZmIvQVRaQTArTjl5Uk1sTVBI?=
 =?utf-8?B?THNjSDZWQVdWWWI4cXlJRUNjSm1iSTJHL1ovVmtJOURjOGZ1cFRXWFR2VjIw?=
 =?utf-8?B?NDRjU296OGdZSkU4Z2MzT1JXd2pQVkFSd2wzV3VZTmtlT3NBMVVDTDB2a3lk?=
 =?utf-8?B?Zks5MDlPcTZ4cTJNT3Jmb1RORTFaT2xwaG9vMGRIekV5U2xhTWNKSkpjTktI?=
 =?utf-8?Q?CR0o5Uw8J/0=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.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?cVJPQXphbnVDcnY4U0FDTHRMQ0Faemx4d3FRcE1HK2x0a2RvdXVNWEZ6eXB0?=
 =?utf-8?B?YUNKOWxLd1lCdUpTSmpoS0haVGdwQkJxbGNoMUdxTVZpSEJESTUvQVpUemhp?=
 =?utf-8?B?dzdqTDdSa0F5Z3dwd2JJb2pyeVpSV2hRNVkzYzgvZjVBY0NTV1VtcW5rVytT?=
 =?utf-8?B?MnY2TWVtUHZ5N2wxRlU5NXNxSGRYR1ZKaldjUCs3TFRnVkZqUGl3TUp2N2JK?=
 =?utf-8?B?SGtpOU4wbUR2ZDU1S2NLNWcrWGM5NlVyQVoyMVdpK0s4ZGswVzRESEdZcHlE?=
 =?utf-8?B?eFg4My9DREY3QjVyazd5aWE5bEVnSnJNam11VkFDcjRUdVZXVUkzY2hTNDBx?=
 =?utf-8?B?YTFpZmw1ckFxcEFvQ0M0QmI5UWZBdFlDbVl5R1Jad1NIRVdQQXZ4VG5aYUdk?=
 =?utf-8?B?N2hORitXREJXbkNXditmWm1tdU5Hc0NwMmxYYlA3ZmYxdWR3T0wvR3R5TTBX?=
 =?utf-8?B?VUdVRnMwWEZTbmkzakZ6TjVGbjBKZWxGc2Iwa3dETmJsQ0hDTkV1NHJSdTdl?=
 =?utf-8?B?Z2F0a1UrbEkwdzIvY21oRmlXMUNRdGVETFgya3E3dkFNalgxNE10MFloWEds?=
 =?utf-8?B?ZGpBdXpEbzVPdHJCelNMRk9VWVlsbEpLRTVOMVBJSWphbXpCdVZqbkprZENI?=
 =?utf-8?B?OXpEeHZZVEkyaCtTZFdXYUlxc29RMWIyckQ1RVlNaU1PWThHRW82a0JGM25y?=
 =?utf-8?B?Y21lckJWZUVpRit6eFVIRnY0NStGc2F0L1NJazg3eEZhbUMwdGlySUhoRzBh?=
 =?utf-8?B?S3M1WWdVT01YdDJWSWQwOFZ4VFNrM3VmN3NmaFN6RUhUNndkYVdCRHAwbFlR?=
 =?utf-8?B?WjNkajVYeUduMDI3aFB6WXJoM0U1TS9OUEN6cUIwaG12ZXh5b1NJS3BuNTZy?=
 =?utf-8?B?VXFzYVBCMlNQS1NCcC8xdUt4MVM1KzRmanBZVnY1TTNKRTA1NlkxUDR1WnU2?=
 =?utf-8?B?YVFka3RGRnArNVJqdS9kdEZsZXBhYlJ4WnVxUElUclJucmxZUndqOENiQ2Zr?=
 =?utf-8?B?anJsMGtNbUNGNW9IM1lacWlqVjFoeXA3b0xTaU11NG5vdGZxTWdEZVVLV1Zt?=
 =?utf-8?B?dXJLWkJLWlpqWmNyajRRQmt5YzNFRThCelFWRGxVRHFEUE1xTHFtejhuOGo3?=
 =?utf-8?B?NWNUbUNtUzM5c2U1VTR0UFlwQlNTclBiSUlVV3MxS1gzMy9DcmhYL2Z0cmYw?=
 =?utf-8?B?UWluS1oyK1orTTJzSnd4U0g0TmxlQU5zZThFNDZqQVN2MnVHV0JjNGtKZkh6?=
 =?utf-8?B?dXlxLzY4TlNxYXhUR29mdzdYdVhnVHRUR1FGU2dGSTFGQ3FqelBkcUcrVDlG?=
 =?utf-8?B?WkxoRndFN2RUYmd1dytKbXBRc2U5d2lxYkMvOGdDeFBzY1BQNjNrS0NTTXVj?=
 =?utf-8?B?TFd3Y1RCOEM3NGFhSXZOOHRtV0tFYXlOdjRwbFYxY2laK3JHZjErOVhIWGh0?=
 =?utf-8?B?N3U3TnRpT1hzNlZ3T0RKTXF0NHRiZnJ4dm1jS3MrR2tOUTNjclAvbXZqK2Jl?=
 =?utf-8?B?TzJDa0M4U1k5b3NtWkM3V2VCdkttWHBuV0FJQXFHV0ZoSTVBL1NibTN0NGZw?=
 =?utf-8?B?K0FZSHJIaUZEdVRwUTZiN1lhelNialVZUGlkVzFNNWZ2ZER4ZjcybWZQWHVv?=
 =?utf-8?B?ekorUDljSHduUjJkK3B1M0lIMmdQV1ROdUhhbWZZdzNIUVRIOTFFZ052am11?=
 =?utf-8?B?WmwyeTJGTkpTcEVZdzRLZE50MFRYMkRGT2RLRFRYR0h3SGF4Q2ZQdlNZZXJy?=
 =?utf-8?B?bDlNL1FCMFd3Mlo0dXZVdGtmS3M0dWZEQ3doOVFUTmtRQkJJSVRBeEl4dUM0?=
 =?utf-8?B?Z3cwWEdEWHA4UUhrT3piQ3hVOTlwUzFVejZEdjRlMmdnVFdXTWJvOFVka2hD?=
 =?utf-8?B?UCt5YjEwcDFMMHJUT0ExaEV2eFMwTWZCc2c3RlFMd0krVHJMQUI5V3YvNEU3?=
 =?utf-8?B?YXkrcVYwanI4TDI1c1UrdDYrbFpYTFE5MmlONkNsLzJHZFovajNlYXU0UDZo?=
 =?utf-8?B?UkNNVTZJbkZ6d29SQVNrQ0lvUURtZUZkN21zK3dCcllLQmxnU2QwU1NoaGd3?=
 =?utf-8?B?eGc2ME5UNVR2aTFSblBQL0JuV0tacHkzTzNUdTNPeSs3NTRVSDNyRlFWTFlC?=
 =?utf-8?Q?s/D4B3EcHHms5gfvz4IuXJL+S?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9c2050fc-f155-40f1-aba2-08dda26e358f
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jun 2025 07:13:58.7582
 (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: eXA7WRw9QAFCfFRTzJ0qZpB9iKv3JygWff+FkhztP+G2aSgUDu58ZXbX7/KsY3zm
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ1PR12MB6363



On 03/06/2025 09:09, Jan Beulich wrote:
> On 03.06.2025 09:06, Orzel, Michal wrote:
>>
>>
>> On 03/06/2025 09:02, Jan Beulich wrote:
>>> On 03.06.2025 08:54, Orzel, Michal wrote:
>>>>
>>>>
>>>> On 02/06/2025 10:37, Jan Beulich wrote:
>>>>> On 27.05.2025 10:21, Michal Orzel wrote:
>>>>>> There's nothing Arm specific about this feature. Move it to common as
>>>>>> part of a larger activity to commonalize device tree related features.
>>>>>> For now, select it only for ARM until others (e.g. RISC-V) verify it
>>>>>> works for them too.
>>>>>>
>>>>>> Signed-off-by: Michal Orzel 
>>>>>
>>>>> I realize this was already committed, but ...
>>>>>
>>>>>> --- a/xen/common/Kconfig
>>>>>> +++ b/xen/common/Kconfig
>>>>>> @@ -162,6 +162,14 @@ config STATIC_MEMORY
>>>>>>  
>>>>>>  	  If unsure, say N.
>>>>>>  
>>>>>> +config STATIC_EVTCHN
>>>>>> +	bool "Static event channel support on a dom0less system"
>>>>>> +	depends on DOM0LESS_BOOT && ARM
>>>>>
>>>>> ... I think we should strive to avoid such arch dependencies; they simply
>>>>> don't scale very well. Instead (if needed) HAS_* should be introduced, which
>>>>> each interested arch can select. In the case here, however, perhaps
>>>>> DOM0LESS_BOOT alone would have been sufficient as a dependency?
>>>> What if e.g. RISC-V wants to enable dom0less but not static evtchn/memory/shmem
>>>> because there are some functions to be implemented and they don't want to do it
>>>> now? Protecting with just DOM0LESS_BOOT would not be sufficient here.
>>>
>>> Imo a transient(!) "depends on !RISCV" would in principle be fine, if ...
>> In this case, how can I know that upfront? When moving a feature I need to put
>> some dependencies. At that point I don't know RISCV, PPC plans.
> 
> You don't need to know this up front, do you? Neither of the two presently selects
> DOM0LESS_BOOT afaict, and hence such a transient negative dependency would (if
> necessary in the first place) be added when adding such a select.
Ok, so basically this should be left to people adding support for DOM0LESS_BOOT
for other arches in the future.

There is static mem and shmem left to be moved. I think we can squeeze in a
patch removing && ARM in this case.

~Michal



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 08:32:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 08:32:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004094.1383743 (Exim 4.92)
	(envelope-from )
	id 1uMN4Y-0005cA-3F; Tue, 03 Jun 2025 08:32:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004094.1383743; Tue, 03 Jun 2025 08:32:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMN4Y-0005c3-0f; Tue, 03 Jun 2025 08:32:38 +0000
Received: by outflank-mailman (input) for mailman id 1004094;
 Tue, 03 Jun 2025 08:32: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 1uMN4W-0005bx-Sn
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 08:32:36 +0000
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com
 [2a00:1450:4864:20::12e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4cdbacc4-4055-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 10:32:35 +0200 (CEST)
Received: by mail-lf1-x12e.google.com with SMTP id
 2adb3069b0e04-5533302b49bso6661691e87.2
 for ; Tue, 03 Jun 2025 01:32:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4cdbacc4-4055-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748939555; x=1749544355; 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=hnXcEifqYLp8SzeSVdXvbuJaHdzVO/1FoQdWjdn6rgE=;
        b=h50ZgwDgqF5YIpxBy9znwC6c8+XCCPxP8ZH+ysrcb8YUlHzkwPYHilLxftJvANQ+C+
         sr1y4mCyYpPaj31DcAvH1j+Gar9K4vTH/Sc0IxqGSLgpnDWsyqkhE0vX5+BEa3W5ighb
         r4fTPSXULSUI2oNaIrsZDkxLIO/mkmlAQb620omSILPwDNx5OE3qIsppspoODFTi4Hyw
         LVNCoWWQ5W1mqEg2ghtM4pn15purjMcSkAnBojWRVo5D7ToK4WRAQteYCVyPCP7ma8T7
         SZFfhEw7KSkiQbFY30rhnIhC4/L7rl0Ri4eHerYx6ZRI+/LJP2GMq4ZoRU7xbWi8Y+Vu
         ZqxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748939555; x=1749544355;
        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=hnXcEifqYLp8SzeSVdXvbuJaHdzVO/1FoQdWjdn6rgE=;
        b=k1KVel7Q081Vk56Oh2gUq9GIvK5MIKR2Lf9VcwoNEXGf48jhnUoTYOJIiy+Gj2bEat
         ntotIjxQ93jo27ms6akNJ/y3ZjF6lY2RLEaHtFZab+fsL8ZuHa1GkEygw7iFpSoOB0Dy
         Wy24dp4vxOy43Ewp3jVSvi1TK9xXWxZ5FDwz/wSQtI6fJq4PxPt9gPgQxhZXXtm06TB+
         ril5JwL51AWN0oPa3tMt6ZFxQQ3wPHCTDCwzNJecLiwQg9yK8VNQTEnq57e7/nP16IgN
         b+nl6lbh+rKMHdylj/NM2PrN8PWWaXrtMZbr4b8PMz8b7I/UruwWoEQOw88oNUZW7nTC
         YIwg==
X-Forwarded-Encrypted: i=1; AJvYcCVhu6r2Bp6NF9BOqcnGos/GsotS/87dHMajz+dt1+Moacnzb4xFQkLddXGX3lQcNU1azRia15SfHe4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxnAl3lbZvanqWYDQdIwJUX0zQcpGdPnqE9lZqgRwIGsmJ5kxnj
	AdE55dBR3PINUMXkIFmdWwRer7hyKesx8EDIoJvil6Xvd+vDKnuBxzcmPUnDaxsCBxnqvA3XhWa
	LLFEeVrIGpbrBYttntmuU8bdksjtc1qA=
X-Gm-Gg: ASbGncuq3qKufMN5crNRdFFmrbd/Oo5LRawqRYYbO9u09FjCCbffKtp8qjdAAyMnvBZ
	4RK/D0SHGGdaO7RdTv7c7dJkjTHmtdNOqEg00k8Ra6lJYvNu37oyMmHkU5VYG+RHfTfo0Kw22Fd
	Dbdg5cKi+r4bm4fS1xzYNVmNBWI/8fku98DdqQY4XI8Q==
X-Google-Smtp-Source: AGHT+IGq4OuBDkzkBUGG3cnE/DRyBz+v3HqNLaONGUENREn5ETw98+pHlc2eDlUL6hg/uwc6TGcAJg38duw8IIN9gxU=
X-Received: by 2002:a05:6512:b1a:b0:553:2812:cefb with SMTP id
 2adb3069b0e04-5533b930b19mr5033143e87.37.1748939554663; Tue, 03 Jun 2025
 01:32:34 -0700 (PDT)
MIME-Version: 1.0
References:  <7bd75ecfff5b0a75ea5abd7cc4934582d7e1250c.1748848482.git.mykola_kvach@epam.com>
 <90048f71-8313-4110-924c-f956a2bec5a0@suse.com>
In-Reply-To: <90048f71-8313-4110-924c-f956a2bec5a0@suse.com>
From: Mykola Kvach 
Date: Tue, 3 Jun 2025 11:32:23 +0300
X-Gm-Features: AX0GCFuVFdVu1xHzYOsnMpohxKgntT5H8FlPFbMOdd-ACYwLPju4vgtAokNlUDg
Message-ID: 
Subject: Re: [PATCH v4][PART 2 07/10] xen/arm: Add support for system suspend
 triggered by hardware domain
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?= , 
	Shawn Anastasio , 
	Alistair Francis , Bob Eshleman , 
	Connor Davis , Oleksii Kurochko , 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi, @Jan Beulich

On Mon, Jun 2, 2025 at 12:26=E2=80=AFPM Jan Beulich  wro=
te:
>
> On 02.06.2025 11:04, Mykola Kvach wrote:
> > @@ -857,8 +860,24 @@ void arch_domain_destroy(struct domain *d)
> >      domain_io_free(d);
> >  }
> >
> > -void arch_domain_shutdown(struct domain *d)
> > +int arch_domain_shutdown(struct domain *d)
> >  {
> > +    switch ( d->shutdown_code )
> > +    {
> > +    case SHUTDOWN_suspend:
> > +#ifdef CONFIG_SYSTEM_SUSPEND
> > +        if ( !is_hardware_domain(d) )
> > +            break;
> > +
> > +        return host_system_suspend();
> > +#else
> > +        break;
> > +#endif
> > +    default:
> > +        break;
> > +    }
> > +
> > +    return 0;
> >  }
>
> What's wrong with
>
> int arch_domain_shutdown(struct domain *d)
> {
>     switch ( d->shutdown_code )
>     {
> #ifdef CONFIG_SYSTEM_SUSPEND
>     case SHUTDOWN_suspend:
>         if ( !is_hardware_domain(d) )
>             break;
>
>         return host_system_suspend();
> #endif
>
>     default:
>         break;
>     }
>
>     return 0;
> }
>
> ?

You're right =E2=80=94 your version is cleaner and avoids unnecessary
preprocessor spaghetti.

My original intention was to keep the SHUTDOWN_suspend case visible
even when CONFIG_SYSTEM_SUSPEND is disabled, so future changes
wouldn't require reintroducing the case label. But thinking about it
again, if future support is needed, the code can be easily adjusted at
that time.

I'll switch to your suggested version =E2=80=94 it's simpler and more reada=
ble.

>
> > @@ -1311,13 +1316,13 @@ int domain_shutdown(struct domain *d, u8 reason=
)
> >          v->paused_for_shutdown =3D 1;
> >      }
> >
> > -    arch_domain_shutdown(d);
> > +    ret =3D arch_domain_shutdown(d);
>
> If non-zero comes back here, is ...
>
> >      __domain_finalise_shutdown(d);
>
> ... this still appropriate to call?

Thank you for catching that =E2=80=94 you=E2=80=99re absolutely right, that=
 was my oversight.

If arch_domain_shutdown returns a non-zero value, we need to undo
any previous actions performed before the call to properly restore the
domain=E2=80=99s state. Calling __domain_finalise_shutdown unconditionally
in that case could lead to an inconsistent state.

I will update the code accordingly to ensure proper cleanup and state
restoration.

>
> >      spin_unlock(&d->shutdown_lock);
> >
> > -    return 0;
> > +    return ret;
> >  }
>
> Most callers don't care about the return value of this function. That lik=
ely
> needs to change, even if _for now_ you only alter the SHUTDOWN_suspend ca=
se
> (and hence some of the callers aren't immediately impacted)?

Thanks for pointing this out. You=E2=80=99re right that most callers curren=
tly
ignore the return value of domain_shutdown(). This will need to be
updated to properly handle non-zero returns, at least for the
SHUTDOWN_suspend case where it matters.

Even if some callers aren=E2=80=99t immediately impacted, I agree it=E2=80=
=99s better
to fix this proactively to avoid silent failures or inconsistent states.

I=E2=80=99ll start reviewing the callers and update them accordingly.

>
> Jan

Thank you for reviewing this patch series.

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 08:50:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 08:50:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004103.1383754 (Exim 4.92)
	(envelope-from )
	id 1uMNLx-0008M4-Df; Tue, 03 Jun 2025 08:50:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004103.1383754; Tue, 03 Jun 2025 08:50:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMNLx-0008Lx-AC; Tue, 03 Jun 2025 08:50:37 +0000
Received: by outflank-mailman (input) for mailman id 1004103;
 Tue, 03 Jun 2025 08:50:36 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uMNLv-0008LS-E8
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 08:50:36 +0000
Received: from 11.mo581.mail-out.ovh.net (11.mo581.mail-out.ovh.net
 [87.98.173.157]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ce230f34-4057-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 10:50:31 +0200 (CEST)
Received: from director3.ghost.mail-out.ovh.net (unknown [10.109.176.32])
 by mo581.mail-out.ovh.net (Postfix) with ESMTP id 4bBPYf6pglz1QvJ
 for ; Tue,  3 Jun 2025 08:50:30 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-b5lhs (unknown [10.110.118.96])
 by director3.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 50725C335E;
 Tue,  3 Jun 2025 08:50:29 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.112])
 by ghost-submission-5b5ff79f4f-b5lhs with ESMTPSA
 id ZmE9CFW3PmgnWQAAZkLW6g
 (envelope-from ); Tue, 03 Jun 2025 08:50: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: ce230f34-4057-11f0-b894-0df219b8e170
Authentication-Results:garm.ovh; auth=pass (GARM-112S006faa6357b-4629-49dd-9956-33b0c4d85953,
                    22913471B39E4060B5DF5B2870BF10C0EF5640C4) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
Date: Tue, 3 Jun 2025 11:50:10 +0300
From: Sergii Dmytruk 
To: Jan Beulich 
Cc: "Daniel P. Smith" ,
	Ross Philipson ,
	Andrew Cooper ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	Lukasz Hawrylko ,
	Mateusz =?iso-8859-1?Q?M=F3wka?= ,
	trenchboot-devel@googlegroups.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 01/22] x86/include/asm/intel-txt.h: constants and
 accessors for TXT registers and heap
Message-ID: 
References: 
 
 
 
 <31c7faf1-d393-40d5-87f9-1a01d1ab39cb@suse.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Ovh-Tracer-Id: 13210746560626406489
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgdegtddutdculddtuddrgeefvddrtddtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhepvdfgveegtdffhfdugeevieehkeetudevfeefgedtleejledvfeeutdetudeiveelnecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukeegrddvvddupdefjedrheelrddugedvrdduuddvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheekudgmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=HoeJbOdgFF8DGKZtGTTXnf1sgdKHTqI+Ki+n84Io8OA=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1748940631; v=1;
 b=EP2herTYghv/L01tKNr6xvuldY3iyPHHLknCyEE3Iv+s1gKZNWeDiaCVcEzRyRUBGkvGujit
 PvptCrqcn/LF5mWTP+O6fLBQ41JN0k77JBUSVsECGnk8oiGJBdRoYEH9I6gG/sLFkHx92u8o+eD
 Umw4RfZhf6JF0EF3xAGc+Ife9a56WtCknbctBCbJ7FjR8OrXXnmgBd0KLIpUtMr5x2/32Fc8aWB
 x6jyDpwyg/FR5hEQoX6CtFBXzjI3JELOBx63HBGdpV6zz2QW7oLxnWHxbS0vSUlGsfabepmWK4b
 22dTsB5jGh6U4GcuHTsV5fAmhIqG90Fpv9lXoAF4+oiqQ==

On Tue, Jun 03, 2025 at 09:06:53AM +0200, Jan Beulich wrote:
> On 03.06.2025 00:00, Sergii Dmytruk wrote:
> > On Mon, Jun 02, 2025 at 09:17:37AM +0200, Jan Beulich wrote:
> >> On 23.05.2025 21:51, Sergii Dmytruk wrote:
> >>> On Wed, May 21, 2025 at 05:19:57PM +0200, Jan Beulich wrote:
> >>>>> +static inline uint64_t txt_bios_data_size(void *heap)
> >>>>
> >>>> Here, below, and in general: Please try to have code be const-correct, i.e.
> >>>> use pointers-to-const wherever applicable.
> >>>
> >>> I assume this doesn't apply to functions returning `void *`.  The
> >>> approach used in libc is to accept pointers-to-const but then cast the
> >>> constness away for the return value, but this header isn't a widely-used
> >>> code.
> >>
> >> Which is, from all I know, bad practice not only by my own view.
> >
> > I actually ended up doing that to have const-correctness in v3.  In the
> > absence of function overloads the casts have to be somewhere, can put
> > them in the calling code instead.
>
> Casts of which kind? For context: There shouldn't be any casting away of
> const-ness (or volatile-ness, for the sake of completeness).
>
> Jan

Casting away const-ness inside of functions like

    static inline void *txt_bios_data_start(const void *heap)

If a function accepts a const pointer and returns it, this turns a
non-const incoming pointer into a const one.  Without duplicating the
code (either having const and non-const versions or repeating code in
other ways), nothing can be made const cleanly in here including
*_size() functions because they call *_start() functions:

    static inline uint64_t txt_os_mle_data_size(const void *heap)
    {
        return *((const uint64_t *)(txt_bios_data_start(heap) +
                                                     // ^^^^ -- const
                                    txt_bios_data_size(heap))) -
               sizeof(uint64_t);
    }

Regards


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 08:52:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 08:52:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004110.1383764 (Exim 4.92)
	(envelope-from )
	id 1uMNNf-0000VX-Oy; Tue, 03 Jun 2025 08:52:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004110.1383764; Tue, 03 Jun 2025 08:52: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 1uMNNf-0000VQ-KQ; Tue, 03 Jun 2025 08:52:23 +0000
Received: by outflank-mailman (input) for mailman id 1004110;
 Tue, 03 Jun 2025 08:52: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 1uMNNd-0000VI-SD
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 08:52:21 +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 0ec28b65-4058-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 10:52:19 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3a361b8a664so5128400f8f.3
 for ; Tue, 03 Jun 2025 01:52:19 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23506cd3407sm83223735ad.141.2025.06.03.01.52.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 03 Jun 2025 01:52:18 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0ec28b65-4058-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1748940739; x=1749545539; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=O5EQsxGiyqX3tV1UKwPBw7x5BbR7tn+clRbPJuEo0xI=;
        b=K8mkQtd8jXDVXBRsSKbyv9Yg7jR3OK9lQj7fWGrRyCYrUrpxNNIdV1CD4o5L9UjIOY
         CUVRFKiz7fQ993fCoSk4IP2oxu7K1FljTEERGG6MolHCY5ViVr9bv6QJ+NWCNyyDsF7S
         h0/mlGppyWpLJnKungXStF9kF+cLq3jA0KoKXK96RNv2tYj4O3fFAgVpWVYElQ8Obe66
         ROacUSrwbf6iT3TpfAqmGVa5iOuF03I1faGT/0rtTd+Nfzch8iQ2855WT8Hu1+Vbxg9b
         HUGmAe2hzGRcXOqm3JOBMRRvcRck46We54WF+tfGxXxhV2JcuecZVP4tupVvAoKAvRYH
         N13A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748940739; x=1749545539;
        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=O5EQsxGiyqX3tV1UKwPBw7x5BbR7tn+clRbPJuEo0xI=;
        b=ZOM4pn6aep/SmmYb9RIrluSqwsDMagKvL937oTlhwEsXNjC5Ndam4w2rGoTJh5ClOw
         7VEpLH0/MN64ibBW1tJwZ3iiVp7OfmG45IFk+iDDsoQDqCJk8PSU2AHqtTTabjtF0JL0
         YJ89zS1ZxqWbDWHbGtgShY6ELaLApU57PfFKuHZTNTuzI4xFYBuD9oPr2XzNREuVz0hu
         6kDjsGHkIOCcIE5GeXad90HanccUufHKS1LX03mFrmkZAVGDbKfgBVO/tOmfW4qYb0Fq
         AxT2CpVhZ1DveY/SEABIb17cX1R2L+D9b/VNjpvQuE5eghjtRQzW34gsGJxa4ZNi3d+8
         xxUw==
X-Forwarded-Encrypted: i=1; AJvYcCXELNl/nfalCddNoRnG5+RF/PYgYO5v67b0FBpkn2THVzNx0ErmFQEHf/Q6AkQiM8DwXwqTZcibxaw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyPlA5VJ0NYGkvuy7iZ2EFtJGpWSx5Wy7C01VGrjnIcWBPMxXOQ
	FADyZgyFtnUQtcuyiF/7Z4oUTGIKFJPG8oDSg9Ygp80VI7pTPkitw6lGTzzMrQUjKg==
X-Gm-Gg: ASbGncsYPzmSe+B/W2eGLukF0pkajQUleWZIZrXyPV6n6T6VF2WeQ4/4hzKOaUL9/0w
	fvixEPCBj2lAp6Y5IwHet7GoKy/JgF+K5HdFYFoTllvpVBgySpFBndgCLOFGiKCB4FYYZOayFIc
	z06eLmSo2aVn8gR60ni9R02EaKXxBuMVggEJQ9yS0b/h/M7GxvZoUf+P2pRJa8gaMGmKs0QrWYt
	FcZiNh5o/GpUAgNJSAiEGS0s+goXrJlNwyhcodCLWbSc6I0p4bcNA0iYYKYdH2ZflqVWpPmuMQh
	5VINTxbPTcPsFo0evydJpV6coZdHMe7yvR/4VrScuLUEWxTj9D79MUeGEDyESjDbFXdAjlxeqa+
	Ip5280PnRHyg2iWxKGjW+McKU3tqSDdCrYPuhhHv2XD5J8sa1Bsl9ecFobA==
X-Google-Smtp-Source: AGHT+IHRxmTk0MWjbPCvgQs3VdH8af08OYcOmyGXf6HHfxKcCWKEsr1XzsL/ycW49zP1m+F7hOzHYQ==
X-Received: by 2002:a05:6000:250d:b0:3a4:c95f:c1d1 with SMTP id ffacd0b85a97d-3a4f7a3e4d6mr12690216f8f.4.1748940739153;
        Tue, 03 Jun 2025 01:52:19 -0700 (PDT)
Message-ID: <70310915-478c-460c-b7be-44002a15922b@suse.com>
Date: Tue, 3 Jun 2025 10:52:09 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 01/22] x86/include/asm/intel-txt.h: constants and
 accessors for TXT registers and heap
To: Sergii Dmytruk 
Cc: "Daniel P. Smith" ,
 Ross Philipson ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Lukasz Hawrylko , =?UTF-8?Q?Mateusz_M=C3=B3wka?=
 , trenchboot-devel@googlegroups.com,
 xen-devel@lists.xenproject.org
References: 
 
  
 <31c7faf1-d393-40d5-87f9-1a01d1ab39cb@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 03.06.2025 10:50, Sergii Dmytruk wrote:
> On Tue, Jun 03, 2025 at 09:06:53AM +0200, Jan Beulich wrote:
>> On 03.06.2025 00:00, Sergii Dmytruk wrote:
>>> On Mon, Jun 02, 2025 at 09:17:37AM +0200, Jan Beulich wrote:
>>>> On 23.05.2025 21:51, Sergii Dmytruk wrote:
>>>>> On Wed, May 21, 2025 at 05:19:57PM +0200, Jan Beulich wrote:
>>>>>>> +static inline uint64_t txt_bios_data_size(void *heap)
>>>>>>
>>>>>> Here, below, and in general: Please try to have code be const-correct, i.e.
>>>>>> use pointers-to-const wherever applicable.
>>>>>
>>>>> I assume this doesn't apply to functions returning `void *`.  The
>>>>> approach used in libc is to accept pointers-to-const but then cast the
>>>>> constness away for the return value, but this header isn't a widely-used
>>>>> code.
>>>>
>>>> Which is, from all I know, bad practice not only by my own view.
>>>
>>> I actually ended up doing that to have const-correctness in v3.  In the
>>> absence of function overloads the casts have to be somewhere, can put
>>> them in the calling code instead.
>>
>> Casts of which kind? For context: There shouldn't be any casting away of
>> const-ness (or volatile-ness, for the sake of completeness).
>>
>> Jan
> 
> Casting away const-ness inside of functions like
> 
>     static inline void *txt_bios_data_start(const void *heap)
> 
> If a function accepts a const pointer and returns it, this turns a
> non-const incoming pointer into a const one.  Without duplicating the
> code (either having const and non-const versions or repeating code in
> other ways), nothing can be made const cleanly in here including
> *_size() functions because they call *_start() functions:
> 
>     static inline uint64_t txt_os_mle_data_size(const void *heap)
>     {
>         return *((const uint64_t *)(txt_bios_data_start(heap) +
>                                                      // ^^^^ -- const
>                                     txt_bios_data_size(heap))) -
>                sizeof(uint64_t);
>     }

Yet just to repeat: Besides myself (and maybe others), Misra objects to
the casting away of const-ness.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 09:35:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 09:35:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004123.1383773 (Exim 4.92)
	(envelope-from )
	id 1uMO2s-0005rm-RE; Tue, 03 Jun 2025 09:34:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004123.1383773; Tue, 03 Jun 2025 09: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 1uMO2s-0005rf-Nu; Tue, 03 Jun 2025 09:34:58 +0000
Received: by outflank-mailman (input) for mailman id 1004123;
 Tue, 03 Jun 2025 09:34:57 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uMO2r-0005rZ-QY
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 09:34:57 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uMO2q-0008dc-2b;
 Tue, 03 Jun 2025 09:34:56 +0000
Received: from [15.248.2.27] (helo=[10.24.67.31])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uMO2q-004G5J-35;
 Tue, 03 Jun 2025 09:34: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" 
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=ChVIruCtaiSIjFbQjuWx2tBxlQQ7RjmKNHtbn5ZIBjY=; b=pFJnnjLOx4p8MY77i4xa4Noay9
	Zy9Nb8LAolTGkbJ6hyGwf2q8wZkEVlYhOOObdmv6ry2Lehbz1zRwx6hEwtGJvXswiGzc1CTGlHgmP
	+rAbXq56Qdc+LqIBP8Yvm/ZFUSW3rOpRytVO6trp0BOGBWYoTGlv59ZdgH0Rf9LXcZNI=;
Message-ID: 
Date: Tue, 3 Jun 2025 10:34:53 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 3/5] tools/arm: Add the trap_unmapped_accesses xl
 config option
To: "Edgar E. Iglesias" ,
 xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org, bertrand.marquis@arm.com, michal.orzel@amd.com,
 Volodymyr_Babchuk@epam.com, andrew.cooper3@citrix.com,
 edgar.iglesias@amd.com, Anthony PERARD ,
 Juergen Gross 
References: <20250530134559.1434255-1-edgar.iglesias@gmail.com>
 <20250530134559.1434255-4-edgar.iglesias@gmail.com>
Content-Language: en-GB
From: Julien Grall 
In-Reply-To: <20250530134559.1434255-4-edgar.iglesias@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Edgar,

On 30/05/2025 14:45, Edgar E. Iglesias wrote:
> @@ -1714,6 +1711,9 @@ int libxl__arch_domain_build_info_setdefault(libxl__gc *gc,
>       /* ACPI is disabled by default */
>       libxl_defbool_setdefault(&b_info->acpi, false);
>   
> +    /* Trapping of unmapped accesses enabled by default.  */
> +    libxl_defbool_setdefault(&b_info->trap_unmapped_accesses, true);
> +
>       /* Sanitise SVE parameter */
>       if (b_info->arch_arm.sve_vl) {
>           unsigned int max_sve_vl =
> diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_create.c
> index e03599ea99..38770eea5b 100644
> --- a/tools/libs/light/libxl_create.c
> +++ b/tools/libs/light/libxl_create.c
> @@ -667,6 +667,9 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
>           if (libxl_defbool_val(b_info->vpmu))
>               create.flags |= XEN_DOMCTL_CDF_vpmu;
>   
> +        if (libxl_defbool_val(b_info->trap_unmapped_accesses))
> +            create.flags |= XEN_DOMCTL_CDF_trap_unmapped_accesses;
> +
>           assert(info->passthrough != LIBXL_PASSTHROUGH_DEFAULT);
>           LOG(DETAIL, "passthrough: %s",
>               libxl_passthrough_to_string(info->passthrough));
> diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl
> index 9bb2969931..e33785c661 100644
> --- a/tools/libs/light/libxl_types.idl
> +++ b/tools/libs/light/libxl_types.idl
> @@ -736,6 +736,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
>       ("vmtrace_buf_kb", integer),
>   
>       ("vpmu", libxl_defbool),
> +    ("trap_unmapped_accesses", libxl_defbool),

I think you want to add a LIBXL_HAVE in tools/include/libxl.h for this 
new field.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 09:36:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 09:36:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004134.1383783 (Exim 4.92)
	(envelope-from )
	id 1uMO4b-0006My-4W; Tue, 03 Jun 2025 09:36:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004134.1383783; Tue, 03 Jun 2025 09:36: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 1uMO4b-0006Mq-21; Tue, 03 Jun 2025 09:36:45 +0000
Received: by outflank-mailman (input) for mailman id 1004134;
 Tue, 03 Jun 2025 09:36:44 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uMO4a-0006Mk-1S
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 09:36:44 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uMO4Z-0008hT-1I;
 Tue, 03 Jun 2025 09:36:43 +0000
Received: from [15.248.2.27] (helo=[10.24.67.31])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uMO4Z-004HHp-28;
 Tue, 03 Jun 2025 09:36: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" 
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=DkijHugA+INbBoxV3J52WjLjHR6B+AnfqsRfYep582w=; b=ifxtjq3tjLra1ow/iREYhJKdnY
	YkKATISr2Tsm75gDM3HN4Mot/La9VCnNvs0kvE283VnNkB3ebjxrsl2ihdRIyIUpMEcenNf5JmI4f
	7VHsdVnLbaymH/ASOoav6/i8IqUNPXMrpyJ9u3emu1Up0cX3zFQo11OfFFMOqYCjXSPM=;
Message-ID: 
Date: Tue, 3 Jun 2025 10:36:40 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/5] xen/arm: Add way to disable traps on accesses to
 unmapped addresses
Content-Language: en-GB
To: "Edgar E. Iglesias" ,
 xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org, bertrand.marquis@arm.com, michal.orzel@amd.com,
 Volodymyr_Babchuk@epam.com, andrew.cooper3@citrix.com,
 edgar.iglesias@amd.com, Anthony PERARD ,
 Juergen Gross , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20250530134559.1434255-1-edgar.iglesias@gmail.com>
 <20250530134559.1434255-2-edgar.iglesias@gmail.com>
From: Julien Grall 
In-Reply-To: <20250530134559.1434255-2-edgar.iglesias@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Edgar,

On 30/05/2025 14:45, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias" 
> 
> Add a per-domain way to optionally disable traps for accesses
> to unmapped addresses.
> 
> The domain flag is general but it's only implemented for ARM for now.
> 
> Signed-off-by: Edgar E. Iglesias 
> ---
>   tools/libs/light/libxl_arm.c  |  3 +++
>   xen/arch/arm/dom0less-build.c |  3 +++
>   xen/arch/arm/domain.c         |  3 ++-
>   xen/arch/arm/domain_build.c   |  3 ++-
>   xen/arch/arm/io.c             | 37 +++++++++++++++++++++++++++++++++--
>   xen/common/domain.c           |  3 ++-
>   xen/include/public/domctl.h   |  4 +++-
>   7 files changed, 50 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
> index 75c811053c..9530996e72 100644
> --- a/tools/libs/light/libxl_arm.c
> +++ b/tools/libs/light/libxl_arm.c
> @@ -233,6 +233,9 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
>           config->arch.sve_vl = d_config->b_info.arch_arm.sve_vl / 128U;
>       }
>   
> +    /* Trap accesses to unmapped areas. */
> +    config->flags |= XEN_DOMCTL_CDF_trap_unmapped_accesses;
> +
>       return 0;
>   }
>   
> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
> index a49764f0ad..a4e0a33632 100644
> --- a/xen/arch/arm/dom0less-build.c
> +++ b/xen/arch/arm/dom0less-build.c
> @@ -343,6 +343,9 @@ void __init arch_create_domUs(struct dt_device_node *node,
>           panic("'sve' property found, but CONFIG_ARM64_SVE not selected\n");
>   #endif
>       }
> +
> +    /* Trap accesses to unmapped areas. */
> +    d_cfg->flags |= XEN_DOMCTL_CDF_trap_unmapped_accesses;
>   }
>   
>   int __init init_intc_phandle(struct kernel_info *kinfo, const char *name,
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 45aeb8bddc..be58a23dd7 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -612,7 +612,8 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
>       unsigned int max_vcpus;
>       unsigned int flags_required = (XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap);
>       unsigned int flags_optional = (XEN_DOMCTL_CDF_iommu | XEN_DOMCTL_CDF_vpmu |
> -                                   XEN_DOMCTL_CDF_xs_domain );
> +                                   XEN_DOMCTL_CDF_xs_domain |
> +                                   XEN_DOMCTL_CDF_trap_unmapped_accesses );

Just to double check, doesn't this mean the flag will be allowed on x86? 
If so, shouldn't we reject it in an arch?

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 10:03:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 10:03:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004148.1383804 (Exim 4.92)
	(envelope-from )
	id 1uMOUl-0002dB-E7; Tue, 03 Jun 2025 10:03:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004148.1383804; Tue, 03 Jun 2025 10:03: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 1uMOUl-0002d2-BM; Tue, 03 Jun 2025 10:03:47 +0000
Received: by outflank-mailman (input) for mailman id 1004148;
 Tue, 03 Jun 2025 10:03: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 1uMOUk-0002Ov-AP
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 10:03:46 +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 09577e34-4062-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 12:03:45 +0200 (CEST)
Received: from MW4PR03CA0197.namprd03.prod.outlook.com (2603:10b6:303:b8::22)
 by MW6PR12MB8916.namprd12.prod.outlook.com (2603:10b6:303:24b::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.32; Tue, 3 Jun
 2025 10:03:41 +0000
Received: from SJ5PEPF000001ED.namprd05.prod.outlook.com
 (2603:10b6:303:b8:cafe::e7) by MW4PR03CA0197.outlook.office365.com
 (2603:10b6:303:b8::22) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.30 via Frontend Transport; Tue,
 3 Jun 2025 10:03:40 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SJ5PEPF000001ED.mail.protection.outlook.com (10.167.242.201) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Tue, 3 Jun 2025 10:03:40 +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 Jun
 2025 05:03:39 -0500
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 Jun 2025 05:03:36 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 09577e34-4062-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Lj7nH4ln/xnasCYmjPA/3/b+buD87kS1kHqC/UyMW887BjKuNA3xEuAHcL8757b0F/3+B0X4BKr+298loywzGDMJMzXChTls+OsUzCAahjiuI9MZSV3RSMOrgf2EePNZUB9qJYVaZSi5m1OwuJrZJxWr7NBknHElsTqhwFZQpij9L1cH1apXIVhMVKzkPDuDlqJWw8LFAWg4KTnvzspt5OJK4I7CdOD6XqTPNgJURzBQRuiRxsXPBksbFKcIJHtoJD5oUxAZ5H1vaL8id5KaJdIthkx65G4hv6nmCLBdkf3POYWXsfE9V/KuVf44Yn2ava8xoyIAugxJAjePBnDTUA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=iiTh8ZbLpUcLRcsbatZFM8R8LIAbDcOLOjknhBVFGw0=;
 b=W8a953zJNFMcwp4CgFIDNK0jUdRBRyTSgo7crIKnTA+4GkjxwU67n44sq/nyEYEExOO2EuDwG++sRG2etA6fYjFJZLg8r1lIcDrsyQixLw8aQJ+BZW5ZckFWgoa4BGxYILkgldBsO6HoqZmnckScCEkJI4bPw7hsLbVsnfH0gOYhdfKcZME0fRwJcgJsP6C86yd9YGtvb39OicVfmq4by+onLzfehJ8t1gtbAJa7FkPcwWCAHZ/wZpWzABkCLY49ZZEbekE70/WLoAsn3AD/GVAqa2E0DD4Fm7n3KxGLfsbl1YCQMTgQhHV802McSSPJtWRGo42XCh4v4MY2KZNkSA==
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=iiTh8ZbLpUcLRcsbatZFM8R8LIAbDcOLOjknhBVFGw0=;
 b=KZc/Xbl+pEl3I9qZZlS/ijsUkfsZ10YAHbKz9lZw5rfM7KeUfyFIjlewCOdNq/WEyVryzPu9mgWize1HV697AU6PefwtaiYMNKtZ00y8bDnriRYVhm0n1PQRnfHKix2zS0oQHLUxzeRsY5/WD4RMUkV91Ow4Akfnm/7N4cRtIms=
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 , Andrew Cooper
	, Anthony PERARD , "Jan
 Beulich" , Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Stefano
 Stabellini" 
Subject: [PATCH 1/4] common: Drop unneeded Arm dependency for static-evtchn
Date: Tue, 3 Jun 2025 12:03:26 +0200
Message-ID: <20250603100329.149851-2-michal.orzel@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20250603100329.149851-1-michal.orzel@amd.com>
References: <20250603100329.149851-1-michal.orzel@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
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: SJ5PEPF000001ED:EE_|MW6PR12MB8916:EE_
X-MS-Office365-Filtering-Correlation-Id: d99e236b-1e6b-4bd8-1022-08dda285ea5f
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?73xOxYN4dK76/9iTgvH4XrgzKSDVRBtDk4MLjQjXZdB/wyT928P6kB6JEWgD?=
 =?us-ascii?Q?T9tIkQWVWqegdZ80EthBmh7huKSBhb5EUQ2+aFuGmZUd4IzrOBqvdehtl+0V?=
 =?us-ascii?Q?BnKF7TnnSAAyi505ZbHH8MQqPzg0Ex7UZxSdisYDHmvmFCpL9oNG5QaCDR0L?=
 =?us-ascii?Q?tt1WTnfnZQsafaKhx0lejizFmCebKli1ibl4tNHdUeO+L0NqqW9wWQJyL+8z?=
 =?us-ascii?Q?sMkrp7WxLWjWemSFvaQAHkTRBhqXb4j+gs1GdugfxCvvAexGuwm/dxmeL4Ah?=
 =?us-ascii?Q?00ozQLqy6HsEO3YSAE6AgzJuHmiQSaljJ6P4BvPjzeQKrQ/jqzNvFDhbIf2w?=
 =?us-ascii?Q?mje+2vWB8uO61CWw6TnFKi9NUEafKHzr/utJUdV5DBYoPrMiSpMIHMgGp2LU?=
 =?us-ascii?Q?Q2P84zzkeDcJeezvj29E0tigl/E2PBV4W6HJHB3X9MQbt2IQ+QFbdqF4b3Xs?=
 =?us-ascii?Q?4AJljU39uaOxwMuwr2eZpG3wm7oLcJkVPfIzD53tc3AHK6gEesVcEt0bVv5W?=
 =?us-ascii?Q?6UHOnxnsYum2k0KTFE7HcS9yBjsVRvqYx8brznT0teptH/Q+6o0j2XH5WEsA?=
 =?us-ascii?Q?DdBTDlWnlNFWGwyB8mZVyQ7zk4h6zlQDx2YHp9E5galxu9s354pFZr0FPHtI?=
 =?us-ascii?Q?E8pbIft8pRyGcrq4ZYeyfpE3LJ8/EK3jUQFFgSo4+YoEnz45asCQt8wv+dn/?=
 =?us-ascii?Q?g91X/CusDXmJeYfUnywDqSySrSff728ndfdU22O8SlPB3cUDJADa1PqC9Vdh?=
 =?us-ascii?Q?A0dqkDdzyJ0Gj7iosJ+5x3rPUQzvmHCpZsz/KbFZTBrraDynYReBSrEZAHpy?=
 =?us-ascii?Q?ImsQUJa+rMj0umaR1SeJuuK7W8T4haRNG8p2qs9n3CCz0AjYO2R/PW7STBb9?=
 =?us-ascii?Q?YmiHeE2P58QCjeLUCNgcTxRKqmOAZ3snPRTQ+E/VdpaH10t8ujzBY2Zq6d58?=
 =?us-ascii?Q?iju76n68qdVpqdujafphFGepxFza4mET3VuQnr3KYZ+HajuJtQhTlr44yNAa?=
 =?us-ascii?Q?4b+q6fhfx3S61qv7wa0Vy4gmiBuqls0twIlKWS2NoR4O36q+6IGo7WDKau3r?=
 =?us-ascii?Q?kgvIoEZtdn4qGe3QpHbPnD/5SxRF+Xbnjb4OX2ZebU2rBQPgwFP6B5LmlX/b?=
 =?us-ascii?Q?v+5txITqVx4L2N5lHSDrz/VcpKn5Vhxjl1dz8Rq+T142Mtc9EkWoZ1OeBte6?=
 =?us-ascii?Q?XEXoABLyx7sC3sE9FiJlGn0/nOnVfDRHBRJDwaT3ckUzSi6Q5VK1FC8p8ZwX?=
 =?us-ascii?Q?P6x34hQqWP3idI3Mp6LyenFDcnjTgt1SSMRk4ODwpkFu82BdPu/hzqO3s36j?=
 =?us-ascii?Q?XMjDX6qoC1UtzjMt3Nsy/Ztv9cQ4VtlM+muVwXTF9K3cYbqD5mGkateCPbKG?=
 =?us-ascii?Q?GCnPvmzrRxqSz+vo6vKiY8BLIti7ycSNXneiifUvz7V4U2nwRKTUuqO+/LFu?=
 =?us-ascii?Q?un0MvO5WyOd45Rl1WMgfyAcbHtA0wN6g+Bvkv+s5CFnwvnM7yUL6ZTf6oM1d?=
 =?us-ascii?Q?NnnTty7AZ9M/SYPgc36t5pJIfESFEqSkawgm?=
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 Jun 2025 10:03:40.1663
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d99e236b-1e6b-4bd8-1022-08dda285ea5f
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:
	SJ5PEPF000001ED.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW6PR12MB8916

DOM0LESS_BOOT is sufficient (only Arm selects it today). If needed,
proper arch dependency can be introduced while adding support for it for
another architecture.

Suggested-by: Jan Beulich 
Signed-off-by: Michal Orzel 
---
 xen/common/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 0951d4c2f286..7ecf5a80315d 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -164,7 +164,7 @@ config STATIC_MEMORY
 
 config STATIC_EVTCHN
 	bool "Static event channel support on a dom0less system"
-	depends on DOM0LESS_BOOT && ARM
+	depends on DOM0LESS_BOOT
 	default y
 	help
 	  This option enables establishing static event channel communication
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 10:03:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 10:03:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004147.1383794 (Exim 4.92)
	(envelope-from )
	id 1uMOUi-0002PR-85; Tue, 03 Jun 2025 10:03:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004147.1383794; Tue, 03 Jun 2025 10: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 1uMOUi-0002PK-4l; Tue, 03 Jun 2025 10:03:44 +0000
Received: by outflank-mailman (input) for mailman id 1004147;
 Tue, 03 Jun 2025 10: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 1uMOUg-0002Ov-Rc
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 10:03:43 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20603.outbound.protection.outlook.com
 [2a01:111:f403:2009::603])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 065ec602-4062-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 12:03:40 +0200 (CEST)
Received: from CH5PR03CA0012.namprd03.prod.outlook.com (2603:10b6:610:1f1::9)
 by DS0PR12MB9424.namprd12.prod.outlook.com (2603:10b6:8:1b4::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.37; Tue, 3 Jun
 2025 10:03:37 +0000
Received: from CH3PEPF00000012.namprd21.prod.outlook.com
 (2603:10b6:610:1f1:cafe::ae) by CH5PR03CA0012.outlook.office365.com
 (2603:10b6:610:1f1::9) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.25 via Frontend Transport; Tue,
 3 Jun 2025 10:03:37 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH3PEPF00000012.mail.protection.outlook.com (10.167.244.117) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.2 via Frontend Transport; Tue, 3 Jun 2025 10:03:37 +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 Jun
 2025 05:03:36 -0500
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 Jun
 2025 05:03:36 -0500
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 Jun 2025 05:03:33 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 065ec602-4062-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=bahHtE0Y8X/mtZdqSztrQ3wvBwlTd+i6HSWW7nfNCV1rN8HTegYCyWtdS/3Kz31Qn6ffQIOL9+hOonq1tAU6G19vq/B7D73CGk+BpdDSo/5p+CblYPisNlmkkS/LZEPGwOWe+7vvxQNlmUDIGy4OWL88+f4rBcltLv/FNjT6toLzuN1hA7r8PBXNxuYWyy8eTVHt0qamV2Mj3holRIqRO+o/fhzbl5UqBYehcokfAOkFqJ3EO7eoDidcCFuVTfHxOQFj0Pb2wafmZ2XKKqntblPZLmWrTQMmVMRv7Kyjr8NUC1/NEl6KBy2Koe3cWQodtKlC411FDEFEyyfRRCWL0w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=V8qdZJEv4A/W7uOFdxgJhQkSnCawOYPpWmKB9kccw0o=;
 b=iAuFCDpMy4zC3e8hnr0XaXAGg8/ZtY/UpFblB6xTzEe0C/TXDVSSPEarVU9anevMbQSYg7SlWHQEmBL2VX+OT9geTi6lbQyUovDXyvyZFgJ5VQwKIaO4ZKPpT7GCg3PDTEdIGGN61Yh4vlVsH6bLSRX1g4URF2pue9DKiN3jTEQI9anoOkkIdskq+7ywuVzMlOV3WeIMGB8SSZTlVHvk0GHebYE/9ugOIytwYHEMfLhEy9qR/tWG3WbNdhn+cxttqzpEnBdX1XAWxJpLid3eE2H1kY8w4GYyjyg84AAx5bg3PTHWjfAG5hkd2AeAmOPjIGprZ8BgzL00GdZaJBel4w==
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=V8qdZJEv4A/W7uOFdxgJhQkSnCawOYPpWmKB9kccw0o=;
 b=a95f0m3n2Gpwx02Oek53eJ/HBG9jN2+FGJ21cpm8QOi2CkYT6VabFNbKE3pFYkyRTjVCRZs+oWiy5YNInm4+FFyeJKK46zqYI8A9Yz+Kao1tLw7yRpuvTnYwCBDhdiqsd7PaFyEMzDI5qE5W3XW1p0Pr5pYn0IzX5G2UsEbKO7Q=
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 , Andrew Cooper
	, Anthony PERARD , "Jan
 Beulich" , Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Stefano
 Stabellini" , Bertrand Marquis
	, Volodymyr Babchuk 
Subject: [PATCH 0/4] device-tree: Move static features to common
Date: Tue, 3 Jun 2025 12:03:25 +0200
Message-ID: <20250603100329.149851-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: CH3PEPF00000012:EE_|DS0PR12MB9424:EE_
X-MS-Office365-Filtering-Correlation-Id: 683f97f2-c00d-4177-dab6-08dda285e88c
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?1E5CI8InPD3rj3xEu71bFu4KfQKPnZQFoXL6EBqWMdVzJMetXr+AjaQcO0qb?=
 =?us-ascii?Q?KO0BY8g5adwQqXCOCUkMhsv5Nz1x7GqCYqqIVNVMAXILiS97Q3sZDCBpG9nh?=
 =?us-ascii?Q?FWCrA5XCxtw30UotTqNjLMDSMzU6T7E+MfEBWJwOEbo494rFF1Ltr7J2JTWM?=
 =?us-ascii?Q?ucMo+T3QNgG3I+I980mifRMEO7vOzThmx0KA6WXgZbH0AuMTUyjPwBNRS4Dy?=
 =?us-ascii?Q?f/fNjbCAOWvAzOfAl3JWdt2AoWbmJnF+3iJ748uoF99Y71aBEYNcFkntgj4C?=
 =?us-ascii?Q?T5fQSMajgocj2gfXMBhi/B09snJcFvS6PN1paryxsw4ZSI/wYKhxACk2DibX?=
 =?us-ascii?Q?Yd8ZHfx1SzNWsoG+jvCaEr9NsCB1ePqTk0rtw715B0V9XhJMrQ1h82uwr4WT?=
 =?us-ascii?Q?l2m7rpmNea4gRyApdZRxgc2Br+WdQ2nSbgfpTotRAuWLW43dnEj2Jpj0HqAp?=
 =?us-ascii?Q?sRxq61oYmwon5dMnMjotUwwkao85pLdBY04hmDnqeuTw3HWwsPMqNvqHCj0i?=
 =?us-ascii?Q?msWAwkOZWy37eX+WhdqJZhaZ2FtHnNKajyJaezjyLGb8LcfnPG74Y2BL7ODW?=
 =?us-ascii?Q?zDDXPrce0ZW1RUsdDuxnERdGXTNlcezB1BBaMcYrMXQu7ejq6OQsVW28+6Nh?=
 =?us-ascii?Q?tMWZZO8HT4jyx0UiJNisijdGCNdWZSIY7ytLfZ4zO7KDpLUMxOpJVy66gWsM?=
 =?us-ascii?Q?bo51Ee7nnYvPNXR2vPTMqv4cE9UNFn4tMfYE4i63t16dvvSXLFtYZpDi3HLl?=
 =?us-ascii?Q?hQ8jp8Ep3XQWZrsKvRCNwnkeJaMSZWHICHgKQMJKqnnsS3bmayuSG0kSRS3P?=
 =?us-ascii?Q?GhuKSnwHvadknF/aYQctJIjkXvUenjg1gn1iT07b3m7YAbBXU5Lf+C4zqbCI?=
 =?us-ascii?Q?k8TWv0zuTDRCEgoAbO9xcZhvZLoYNrZZY5/NT8mBRxj2ATVowTgrXli5XIxZ?=
 =?us-ascii?Q?BiDl0IEZhZ8NhmvXnpSS0f5EJaBglvloMOkw5kNjIHe8eHE4FhmDPQ9zxr37?=
 =?us-ascii?Q?kEYC01pzdqH8u/+kEWZRQvqmQ1fEtL+rgXhs8hCKhBV7vSa7bwkOKo2bDExe?=
 =?us-ascii?Q?AIJO4c7scw6wE98zsOa8Bl3KgKBZeaiOJ24ftTr1ZAsFV737FjVf9b5/uDfl?=
 =?us-ascii?Q?9oR8K1gOdl3RceOpppyTB5jk97DcDzeqo3UCiaE4QchYcvHRtmuE6EmJw1MQ?=
 =?us-ascii?Q?LeaeN4D9TB8nhXX/tUt5bP/oO2l6D5OgDr2QPZyOtDde/VzSMXHVW2x1Znxv?=
 =?us-ascii?Q?4va+OjsWPXEr2PSxbJv2YYblwKQiQXRTrPkBoCK/wZw7ZlQaSrMWHA7cl4LG?=
 =?us-ascii?Q?RD1ug7whz/j4SuzApZB0p3dAPvA8Cbwt3VrbLfZQN7yyrGZvQP7sbppwAEpE?=
 =?us-ascii?Q?v1k8GYcimK4DxTVgR56DbhR1CrkUpKwFkQNVxMO3mOLBLy0QFcBlc2OjdK6t?=
 =?us-ascii?Q?kN8jUMMpnp0KcKc466b682/b+C8BsVqcsdmbZ/KiSGHhO82KY93yrm4nyqM9?=
 =?us-ascii?Q?EKwYgl8Guh+KZH97JaQqdqH0bEdgbpXQxDJ6?=
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 Jun 2025 10:03:37.1840
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 683f97f2-c00d-4177-dab6-08dda285e88c
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:
	CH3PEPF00000012.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB9424

Finish the work to move static features that are arch agnostic to common.

Michal Orzel (4):
  common: Drop unneeded Arm dependency for static-evtchn
  device-tree: Move domain_fdt_begin_node() to common
  device-tree: Move Arm's static-memory feature to common
  device-tree: Move Arm's static-shmem feature to common

 xen/arch/arm/Kconfig                          |  6 ----
 xen/arch/arm/Makefile                         |  2 --
 xen/arch/arm/arm32/mmu/mm.c                   |  4 +--
 xen/arch/arm/arm64/mmu/mm.c                   |  4 +--
 xen/arch/arm/dom0less-build.c                 |  4 +--
 xen/arch/arm/domain_build.c                   | 34 +-----------------
 xen/arch/arm/include/asm/domain_build.h       |  1 -
 xen/common/Kconfig                            |  8 ++++-
 xen/common/device-tree/Makefile               |  2 ++
 xen/common/device-tree/bootfdt.c              | 36 +++++++++++++++++--
 xen/common/device-tree/dom0less-build.c       | 15 ++------
 .../device-tree}/static-memory.c              |  2 +-
 .../arm => common/device-tree}/static-shmem.c |  5 ++-
 xen/include/xen/bootfdt.h                     |  1 +
 .../asm => include/xen}/static-memory.h       |  9 ++---
 .../asm => include/xen}/static-shmem.h        |  6 ++--
 16 files changed, 63 insertions(+), 76 deletions(-)
 rename xen/{arch/arm => common/device-tree}/static-memory.c (99%)
 rename xen/{arch/arm => common/device-tree}/static-shmem.c (99%)
 rename xen/{arch/arm/include/asm => include/xen}/static-memory.h (93%)
 rename xen/{arch/arm/include/asm => include/xen}/static-shmem.h (96%)

-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 10:03:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 10:03:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004149.1383814 (Exim 4.92)
	(envelope-from )
	id 1uMOUq-0002uI-Ly; Tue, 03 Jun 2025 10:03:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004149.1383814; Tue, 03 Jun 2025 10:03: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 1uMOUq-0002uB-IM; Tue, 03 Jun 2025 10:03:52 +0000
Received: by outflank-mailman (input) for mailman id 1004149;
 Tue, 03 Jun 2025 10: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 1uMOUo-0002Ov-EO
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 10:03:50 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20624.outbound.protection.outlook.com
 [2a01:111:f403:2412::624])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0af60d8c-4062-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 12:03:49 +0200 (CEST)
Received: from MW4PR03CA0194.namprd03.prod.outlook.com (2603:10b6:303:b8::19)
 by CYYPR12MB8962.namprd12.prod.outlook.com (2603:10b6:930:c4::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Tue, 3 Jun
 2025 10:03:44 +0000
Received: from SJ5PEPF000001ED.namprd05.prod.outlook.com
 (2603:10b6:303:b8:cafe::5d) by MW4PR03CA0194.outlook.office365.com
 (2603:10b6:303:b8::19) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.31 via Frontend Transport; Tue,
 3 Jun 2025 10:03:43 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SJ5PEPF000001ED.mail.protection.outlook.com (10.167.242.201) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Tue, 3 Jun 2025 10:03:43 +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 Jun
 2025 05:03:41 -0500
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 Jun 2025 05:03:39 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0af60d8c-4062-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=kdYyGzjOpL/GOq+U9oY28gHlzxgvbgbrZOfnjnO034K+enlcBrTXPKPzA+h+MykFJ4SY9oZN+2dE+Mp4sOBPRVN86DnesnLQ7RLDmB8FssHsFlNZZGOVLVSnYgv63G8bGF+VzCFTfGr0jYgbq9ylxre2TSs7GnBb1PC6TEtz9hVTE9K4GhAtwGIuoqjQMcq7rxud1l3AdocxLl/024RqES+LE7gLiwM+nX4LVygw1yLer0KdRP9g7p+olAzPk3DFlirQMbhVLEj+LJmju/xPq0o4bbInw1c/y9gNDQQwRwewTB0m1QtjzhKNrJ+WeoIa8rEehNHpJoXHNgWPqvFqTw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=tV5QO82penY1TDFtT13aO09+0kxr4wh/OT9jYuqWgqY=;
 b=wWF2WBeGkDlNU/uQ8uJoQYA+/W3cSnRmLKaZGvR0/5pYxSF3p6NrabV8sb6LRzsWzsrGNuFUyvrh7NFrzHktYPT2NFOV74yE9zUJqSRUnDQ+zD+puYChxrKUjWJ2Xx04G9TsotgJtFaHitLMSt1VQPulWtE/tEbvhZwwtfE1TKhLMSQkQnTsGeu+QSW3VYR15XEhhYiv/KZKDoSAaG0ZsIK1LP60HWXI/g8vWd+gMf1N5MIheWGECnsOdjKXD2qT3WeTCYR+FcCzBRahp+qLWNZL96IyUaBAOqHEO+mdi3HTkk+YRMnDCcgrkbVDoRle7SHKxmUIH0BWjhp6QZskag==
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=tV5QO82penY1TDFtT13aO09+0kxr4wh/OT9jYuqWgqY=;
 b=FZXclpzkTLH5XVG9qkK1Kuwr9dGQa3oPhgdt06g7kTEUNl+RjojYxPXpmmtILNSxBJ+RbyFtfiEZMf8iUQ3LjW6B+K9Sa65xe64PC7Nbqz3bpIz+EOs0PpifwnHwPbI9HCBH3mr37L1kqpA2F+Wma3+IQhC74/tbuvsJHWs+55Q=
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 , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Volodymyr Babchuk 
Subject: [PATCH 2/4] device-tree: Move domain_fdt_begin_node() to common
Date: Tue, 3 Jun 2025 12:03:27 +0200
Message-ID: <20250603100329.149851-3-michal.orzel@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20250603100329.149851-1-michal.orzel@amd.com>
References: <20250603100329.149851-1-michal.orzel@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
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: SJ5PEPF000001ED:EE_|CYYPR12MB8962:EE_
X-MS-Office365-Filtering-Correlation-Id: 819e561f-e283-46ef-c6cf-08dda285ec5f
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?SqsKbrmhiWWrbsXEo6wEQcPiT0eKs7Kv1IpEHQZrxyChI5U6JtIC8WwxLBqX?=
 =?us-ascii?Q?AXsbUMz9+Tal+0b+P6uFCYS+5i84d7K7q2ceQzw1bZpJ1LceClel0MpnEQia?=
 =?us-ascii?Q?yGdoKvqoEZx7YcLVOY6NHwqg3uM6A1sLtMKub784eH0VgC1E0QB71nsmagIH?=
 =?us-ascii?Q?MBSIFq5OfkU1jbXMgCbSlK6z6R7joPmyNB8gXPR5fVdrOODUItjWQF+uL/TF?=
 =?us-ascii?Q?nIejSywooTyRGqEduadEM3l+U5tv3tHkA5xfzEdBdqCdPA00GfGfcKhoHZpg?=
 =?us-ascii?Q?zI2Bi4IqXWFHc6thxBrYg4iCm+G+1iJ3mZN+JXMKexeG5v6es/thMERRjRml?=
 =?us-ascii?Q?JclCIMeIfRMkduNGOxPKjNoETg0yrvFUUuxMhoUMzUi1KUURJpOrsI7e0yTI?=
 =?us-ascii?Q?qC53kEHxmac8t+jn3MJNQev79Cvf5zQ8RsvWWigk14YAvlPUgVc/ryzs7PvQ?=
 =?us-ascii?Q?EvSMWO45zktLbaAA4nlQro1xz1YAfZwISF4nVgPt7D0rWMgBdID1UqgRKM3l?=
 =?us-ascii?Q?EJck501MndCA/126WaYPaAkBc68rilvvf/bFF8tSnGUrKzZ2UHF3pTaIhJWq?=
 =?us-ascii?Q?5ommJX4RXiPLhM9bNxwKnP0yF7HDuVeLdjwkMkfiGLDQIjwaFxTeN2A50rwP?=
 =?us-ascii?Q?w/ej5VSJa65PCLdxL4YqTOiLGLwFq+jdgbsF0kIxDOdCVFZ4vw+1f+sEX7OZ?=
 =?us-ascii?Q?4O8qluT0jhNRtuGRmb5na1WTJv17QOGYdti8maOBj0fOXE5nh6bBffPJkVXw?=
 =?us-ascii?Q?zx6cIyxMBkp9MtOHdoKLbIfxfP52r7OFC390ceCjlquBFu3uv1lYtN58dWBW?=
 =?us-ascii?Q?Tb89+DTuxqwOIeazt6Vpe1qBRGVkzGMZCBM2JnFUTu0Pp7yDz5Z5gAGvLsZ8?=
 =?us-ascii?Q?Af9JLwjoSl5ix1yE7jIphF+jyWh5pz+Vg6L8NLlAkLup+KuaA/bnDjSQFhgt?=
 =?us-ascii?Q?cgvGOlAlg2tky/o/o+Dwa0Er6hArrj8oO927mZ6/pt7KgM9JW5ydNxv/mAc+?=
 =?us-ascii?Q?3NCFIdnlCtX9eGK/evODILf7wMqjL0h0NZsD59lCP2FszzigOo9L3QroDrdK?=
 =?us-ascii?Q?LpeCTx4BgB1VQxrrbt14O7oiWxh7idsOH3rSyXrWttzTLN02Aq/Oy7Mut0hP?=
 =?us-ascii?Q?bqjG67dNb/5WkgHKOrvDBY55XKPO7AoUkV3CR7Cbj7yRnhZpzQpNWi5FPL1x?=
 =?us-ascii?Q?19eKln2N1paaWfxjR4houa7nRtBsdVJUl8JhPZoc5wVyU0YKBYd6NqHjfG37?=
 =?us-ascii?Q?zO7lj+MCwlMTExYmDDxp2VLsh4Hk/Sgr6ygS3Wg6JO7jUy6EohAAPKbLTRuz?=
 =?us-ascii?Q?7R2uGvChtp9TFiFs162FzTbUAYsYau53DxHtogo0PizPG12/2lrofcb/BnqX?=
 =?us-ascii?Q?0/+CSYaINrFffaS7fVAwNVBIBrWqz9MuWqIgMKU5w2eLuALRhobm5EHDwY7f?=
 =?us-ascii?Q?J0OJJuwlEgAzQVoUSjOHPguz1etzdVIxmolZJL2b15OhFevjPO0X5p5gAQMw?=
 =?us-ascii?Q?mw3ijCe4bdoQ2unn3h+du92mHSh2fzE1o6vm?=
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);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jun 2025 10:03:43.5256
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 819e561f-e283-46ef-c6cf-08dda285ec5f
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:
	SJ5PEPF000001ED.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYYPR12MB8962

This is just a wrapper around fdt_begin_node(). Move it to common and
remove asm/domain_build.h inclusion from static-shmem.c.

Signed-off-by: Michal Orzel 
---
 xen/arch/arm/domain_build.c             | 32 -------------------------
 xen/arch/arm/include/asm/domain_build.h |  1 -
 xen/arch/arm/static-shmem.c             |  1 -
 xen/common/device-tree/bootfdt.c        | 32 +++++++++++++++++++++++++
 xen/include/xen/bootfdt.h               |  1 +
 5 files changed, 33 insertions(+), 34 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index b189a7cfae9f..068af31a62db 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -649,38 +649,6 @@ static int __init fdt_property_interrupts(const struct kernel_info *kinfo,
     return res;
 }
 
-/*
- * Wrapper to convert physical address from paddr_t to uint64_t and
- * invoke fdt_begin_node(). This is required as the physical address
- * provided as part of node name should not contain any leading
- * zeroes. Thus, one should use PRIx64 (instead of PRIpaddr) to append
- * unit (which contains the physical address) with name to generate a
- * node name.
- */
-int __init domain_fdt_begin_node(void *fdt, const char *name, uint64_t unit)
-{
-    /*
-     * The size of the buffer to hold the longest possible string (i.e.
-     * interrupt-controller@ + a 64-bit number + \0).
-     */
-    char buf[38];
-    int ret;
-
-    /* ePAPR 3.4 */
-    ret = snprintf(buf, sizeof(buf), "%s@%"PRIx64, name, unit);
-
-    if ( ret >= sizeof(buf) )
-    {
-        printk(XENLOG_ERR
-               "Insufficient buffer. Minimum size required is %d\n",
-               (ret + 1));
-
-        return -FDT_ERR_TRUNCATED;
-    }
-
-    return fdt_begin_node(fdt, buf);
-}
-
 int __init make_memory_node(const struct kernel_info *kinfo, int addrcells,
                             int sizecells, const struct membanks *mem)
 {
diff --git a/xen/arch/arm/include/asm/domain_build.h b/xen/arch/arm/include/asm/domain_build.h
index 9655e9d453fb..c6fec3168cdb 100644
--- a/xen/arch/arm/include/asm/domain_build.h
+++ b/xen/arch/arm/include/asm/domain_build.h
@@ -5,7 +5,6 @@
 #include 
 
 typedef __be32 gic_interrupt_t[3];
-int domain_fdt_begin_node(void *fdt, const char *name, uint64_t unit);
 int make_psci_node(void *fdt);
 void evtchn_allocate(struct domain *d);
 
diff --git a/xen/arch/arm/static-shmem.c b/xen/arch/arm/static-shmem.c
index 32ec6d4bc69f..21fd2c3cd4fd 100644
--- a/xen/arch/arm/static-shmem.c
+++ b/xen/arch/arm/static-shmem.c
@@ -6,7 +6,6 @@
 #include 
 #include 
 
-#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
index 529c91e603ab..aa44f5a67c34 100644
--- a/xen/common/device-tree/bootfdt.c
+++ b/xen/common/device-tree/bootfdt.c
@@ -659,6 +659,38 @@ const __init char *boot_fdt_cmdline(const void *fdt)
     return prop->data;
 }
 
+/*
+ * Wrapper to convert physical address from paddr_t to uint64_t and
+ * invoke fdt_begin_node(). This is required as the physical address
+ * provided as part of node name should not contain any leading
+ * zeroes. Thus, one should use PRIx64 (instead of PRIpaddr) to append
+ * unit (which contains the physical address) with name to generate a
+ * node name.
+ */
+int __init domain_fdt_begin_node(void *fdt, const char *name, uint64_t unit)
+{
+    /*
+     * The size of the buffer to hold the longest possible string (i.e.
+     * interrupt-controller@ + a 64-bit number + \0).
+     */
+    char buf[38];
+    int ret;
+
+    /* ePAPR 3.4 */
+    ret = snprintf(buf, sizeof(buf), "%s@%"PRIx64, name, unit);
+
+    if ( ret >= sizeof(buf) )
+    {
+        printk(XENLOG_ERR
+               "Insufficient buffer. Minimum size required is %d\n",
+               (ret + 1));
+
+        return -FDT_ERR_TRUNCATED;
+    }
+
+    return fdt_begin_node(fdt, buf);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index 847f01955982..64db48f4fe4e 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -191,6 +191,7 @@ void populate_boot_allocator(void);
 size_t boot_fdt_info(const void *fdt, paddr_t paddr);
 
 const char *boot_fdt_cmdline(const void *fdt);
+int domain_fdt_begin_node(void *fdt, const char *name, uint64_t unit);
 
 static inline struct membanks *bootinfo_get_reserved_mem(void)
 {
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 10:03:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 10:03:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004151.1383824 (Exim 4.92)
	(envelope-from )
	id 1uMOUs-00039e-1Z; Tue, 03 Jun 2025 10:03:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004151.1383824; Tue, 03 Jun 2025 10:03: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 1uMOUr-00039V-Tz; Tue, 03 Jun 2025 10:03:53 +0000
Received: by outflank-mailman (input) for mailman id 1004151;
 Tue, 03 Jun 2025 10:03: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 1uMOUq-0002Ov-Qq
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 10:03:52 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20615.outbound.protection.outlook.com
 [2a01:111:f403:2009::615])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0cb1a64b-4062-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 12:03:52 +0200 (CEST)
Received: from DS7PR03CA0360.namprd03.prod.outlook.com (2603:10b6:8:55::33) by
 DM6PR12MB4139.namprd12.prod.outlook.com (2603:10b6:5:214::18) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8769.30; Tue, 3 Jun 2025 10:03:47 +0000
Received: from CH3PEPF00000013.namprd21.prod.outlook.com
 (2603:10b6:8:55:cafe::cf) by DS7PR03CA0360.outlook.office365.com
 (2603:10b6:8:55::33) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.19 via Frontend Transport; Tue,
 3 Jun 2025 10:03:47 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH3PEPF00000013.mail.protection.outlook.com (10.167.244.118) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.2 via Frontend Transport; Tue, 3 Jun 2025 10:03:46 +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 Jun
 2025 05:03:46 -0500
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 Jun
 2025 05:03:46 -0500
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 Jun 2025 05:03:43 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0cb1a64b-4062-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=bYrr3kgPW7dprhxVGTqfpblP9UV2h2bYFipCFJyrR006MoccKaFjd85zO+5TAf3qMiVaAulUhDVXHanC4HKZC84Bf0HDXCwHwZjThGArXIMDiyfVFXSP0WprtkThdiLeNMulsb8/eXl+Wjm7yihmAhDz7qPJ3jmw4CF9XxnOGgFynvslwFQ4ogHhX3DUHnCkxstJHIPdniCxQpgAjBEBth7ja8noT6d4hj9y0YWd8SNbPIMJ0I12bfioXjUq1VbFkgGBzOFWOeimEh3qIL5WvRZg4qpB/bXKIWRaahD0EC+X4GnKTVjPVQSVK7GKeLDjhfkUJLMc5faoJchqzaCjvw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ZnHGABcGglclp7hMY6MIJY9pwxZ/mgS16QSPWnOTu6U=;
 b=gVzn31GhpImft3ESWQPJXJ2ONYBzmrRAwMHxPHC+2gxH2aornsx/O5B9LrLkI8G2ngtdyxNodXLQ6Lclf5eS4mowyqV6HoaVGlojpsnMn5qYp2v3+J3wIISegoquQbnitVVn34Bw5g2y90FsFhdqS4sKXZHxmUV+uMYA6JhIux0yzUk88BR0qDWonSjTtaekhaYNUflpQUYSc1kyr3+ZN+JezJddH26ffBG6WTvzd2WQROvgTcGq7xnBywkDvoomusGlpCLbm2FPTIjXPH5Wytlz7RFLEE0hiJQmDrlyopkApZXpSIx2wCcGMwLwVW0K5RKjxivxmotjzQioSnQEJw==
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=ZnHGABcGglclp7hMY6MIJY9pwxZ/mgS16QSPWnOTu6U=;
 b=alGj6dlO8jWGv7BUMZ7ql6lTmDPPS4SpTLS30ImzdUqnxtA6hVk5PNlORdk6YnNx4iJze6Sb73hmLWVzk8z6f4X9x1iKGCDlMeGkd11Q9DOMoJc4/21DlL2PqMItf90G9QrTdosJoIt0HRP8ayks9ExitQbpG0T9O39ZhuBZIMo=
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 ,
	Andrew Cooper , Anthony PERARD
	, Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH 4/4] device-tree: Move Arm's static-shmem feature to common
Date: Tue, 3 Jun 2025 12:03:29 +0200
Message-ID: <20250603100329.149851-5-michal.orzel@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20250603100329.149851-1-michal.orzel@amd.com>
References: <20250603100329.149851-1-michal.orzel@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH3PEPF00000013:EE_|DM6PR12MB4139:EE_
X-MS-Office365-Filtering-Correlation-Id: 0565fbb1-c3b4-4913-2335-08dda285ee4d
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?tKS1xyMj8sY//SiJbeo5HHbpYz4pjtDAu5owu5SG+TQLHPFpNVJ5RlcIWs/v?=
 =?us-ascii?Q?JxuAMi8M5wIBMNYV/RcjsgKHg4xI6M10kWlLnPXq6LXj0d06KVatTNkw8QhP?=
 =?us-ascii?Q?qxrWEtetxI8yaeaVJJeoMCxiz7yT5dX6o7ROPPOxjBOD5ThLNHig2CH5+8wj?=
 =?us-ascii?Q?Bx8kYRgFERuUiQfcBslR4cNWVHvoqeFzhnmf4dOLzv/oeh7h2HownneJS9QA?=
 =?us-ascii?Q?fzxV7j1N0ewWPWdkQo9Zzj3AHeH26yi42uNyGqh4uxwt+Gn1d80kv6YA9qjL?=
 =?us-ascii?Q?m87CnhY9sukqb+T0tqMtUtczeyp/+z/DOU0u7ztEplw6rJlGdgGTGn7ZpGVA?=
 =?us-ascii?Q?D96UsGgnG8sEE+F4BDL6BgYcaOsBvXNX26uIdn4XZNZJiF4wpitNFe5GFeMz?=
 =?us-ascii?Q?GEOpanOX1L7/v/0Fmg9c2FwZulxVsPuU2ah0B4vCzyzezs+LzU5hMayPL9Ge?=
 =?us-ascii?Q?aNWIYxoU2BDLPKZwVD3rqIZzjUYIHW1F019pgfMQFwC1HHvLLpNuqCSCV/Dr?=
 =?us-ascii?Q?aCTYGIbbw4OeQluFpH1VQPF6ry13xu3cfPTxppfuiPuxXvpWEXzE7Rexwbro?=
 =?us-ascii?Q?Ca3wB8Bx3Hj/EjXTYkzGstY52dg/Xx2ESzw6t4JPi5jW/T1xuI1kevLISe+A?=
 =?us-ascii?Q?Ih9jE/n5i8Jj7ZlHtngHQ/OUi+E4q+GhqbPmXzb/EzpiAfnZ/Cz7weM9tWB6?=
 =?us-ascii?Q?IphBNnvQ7HVE8TtbVMjp7I/jfb21ynemPn9jyo32Lvnpe23K0KiRzqRqj0CW?=
 =?us-ascii?Q?AF2tNiGrxz3QdlF8tgLOm/wYjDwNSRExky4EAf1JKXPjdNwHIiz3BeN0M62z?=
 =?us-ascii?Q?SGNzekbQ2Sxwi6NuCJ5Q+DbVwSEdyebtZbSu3rYzmj3GNgF/tFtUOJosXswg?=
 =?us-ascii?Q?XEs7w7oBcpTai8z+fC1x5J9W0GTuTQvceQnB+uL1FTZy7NjZutT9u3+j68mZ?=
 =?us-ascii?Q?z4zmU8T41boMlZPJoT3G8n7Orb4I/wHkuWqDEvvPDXg0voIkUcnOb2XpeyoT?=
 =?us-ascii?Q?pcqEscLDtLjJp+6M365u3usu0w/nYJzyr07iWAgPgLb+SrTUHcXzJerOo++t?=
 =?us-ascii?Q?4LqJl/4xZOl/RqULLofoa3hAfLZ+MwTGiAu8c/gEo1zqZab49MumOggvEJXw?=
 =?us-ascii?Q?TRzR97uOxkxi9x5Wc4ec/zO8V60e9klGo74YX8NGIgNF191pmhKod/G4cjG+?=
 =?us-ascii?Q?CPZsmOcY7bS8/eu+pYg4VrlAtCH67E7KapfGuT6ZVraaT7Xd8J31C5Nq7knG?=
 =?us-ascii?Q?2I48jfrowll7KTfdkLqIv2xDL2G9IeIrkWLNzzP4kz6Y6l2WNK1OOqM6+u9y?=
 =?us-ascii?Q?WXtaD/tfhnbQoy74vh72biACyEkVVA76jJufIBvh0G0DA7Cl2vM9AF+7vd/B?=
 =?us-ascii?Q?EFLceDO+S3TKrk752brKNd0U8OQpZeaxLxm5GlkT1h7NuvDz1HbbxQBn/4Qn?=
 =?us-ascii?Q?IoCRa1xEwsVNxs7VXpRDPv60wcpyQJEIh7T1v6y7DfQf0rGLUBX1zfZOqQ+3?=
 =?us-ascii?Q?/gHtYKjvo/UkceKjoo4IYSn96ubI7scHtw7Y?=
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 Jun 2025 10:03:46.8311
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 0565fbb1-c3b4-4913-2335-08dda285ee4d
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:
	CH3PEPF00000013.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4139

This feature is arch agnostic, thus move it to common.

Signed-off-by: Michal Orzel 
---
 xen/arch/arm/Kconfig                                     | 6 ------
 xen/arch/arm/Makefile                                    | 1 -
 xen/arch/arm/arm32/mmu/mm.c                              | 2 +-
 xen/arch/arm/arm64/mmu/mm.c                              | 2 +-
 xen/arch/arm/dom0less-build.c                            | 2 +-
 xen/arch/arm/domain_build.c                              | 2 +-
 xen/common/Kconfig                                       | 6 ++++++
 xen/common/device-tree/Makefile                          | 1 +
 xen/common/device-tree/bootfdt.c                         | 4 +---
 xen/common/device-tree/dom0less-build.c                  | 9 +--------
 xen/{arch/arm => common/device-tree}/static-shmem.c      | 2 +-
 xen/{arch/arm/include/asm => include/xen}/static-shmem.h | 6 +++---
 12 files changed, 17 insertions(+), 26 deletions(-)
 rename xen/{arch/arm => common/device-tree}/static-shmem.c (99%)
 rename xen/{arch/arm/include/asm => include/xen}/static-shmem.h (96%)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 57919d8b3ac8..3f25da3ca5fd 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -247,12 +247,6 @@ config ARM64_BTI
 
 source "arch/arm/tee/Kconfig"
 
-config STATIC_SHM
-	bool "Statically shared memory on a dom0less system" if UNSUPPORTED
-	depends on STATIC_MEMORY
-	help
-	  This option enables statically shared memory on a dom0less system.
-
 config PARTIAL_EMULATION
 	bool "Enable partial emulation of system/coprocessor registers"
 	default y
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 4f080145478d..ab0a0c2be6d8 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -51,7 +51,6 @@ obj-y += setup.o
 obj-y += shutdown.o
 obj-y += smp.o
 obj-y += smpboot.o
-obj-$(CONFIG_STATIC_SHM) += static-shmem.init.o
 obj-y += sysctl.o
 obj-y += time.o
 obj-y += traps.o
diff --git a/xen/arch/arm/arm32/mmu/mm.c b/xen/arch/arm/arm32/mmu/mm.c
index f3305e28e9df..4d22f35618aa 100644
--- a/xen/arch/arm/arm32/mmu/mm.c
+++ b/xen/arch/arm/arm32/mmu/mm.c
@@ -7,9 +7,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
-#include 
 
 static unsigned long opt_xenheap_megabytes __initdata;
 integer_param("xenheap_megabytes", opt_xenheap_megabytes);
diff --git a/xen/arch/arm/arm64/mmu/mm.c b/xen/arch/arm/arm64/mmu/mm.c
index cded8f2787f9..a0a2dd8cc762 100644
--- a/xen/arch/arm/arm64/mmu/mm.c
+++ b/xen/arch/arm/arm64/mmu/mm.c
@@ -5,9 +5,9 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
-#include 
 
 /* Override macros from asm/page.h to make them work with mfn_t */
 #undef virt_to_mfn
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index bcfd686a8b7f..20aabf6be5c7 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -23,7 +24,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #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 068af31a62db..590f38e52053 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -32,7 +33,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 7ecf5a80315d..eece1370a3cc 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -162,6 +162,12 @@ config STATIC_MEMORY
 
 	  If unsure, say N.
 
+config STATIC_SHM
+	bool "Statically shared memory on a dom0less system" if UNSUPPORTED
+	depends on STATIC_MEMORY
+	help
+	  This option enables statically shared memory on a dom0less system.
+
 config STATIC_EVTCHN
 	bool "Static event channel support on a dom0less system"
 	depends on DOM0LESS_BOOT
diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
index ed11f2c3b42c..13127296cb50 100644
--- a/xen/common/device-tree/Makefile
+++ b/xen/common/device-tree/Makefile
@@ -8,3 +8,4 @@ obj-y += intc.o
 obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o
 obj-$(CONFIG_STATIC_EVTCHN) += static-evtchn.init.o
 obj-$(CONFIG_STATIC_MEMORY) += static-memory.init.o
+obj-$(CONFIG_STATIC_SHM) += static-shmem.init.o
diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
index aa44f5a67c34..9df80291b159 100644
--- a/xen/common/device-tree/bootfdt.c
+++ b/xen/common/device-tree/bootfdt.c
@@ -13,11 +13,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
-#ifdef CONFIG_STATIC_SHM
-#include 
-#endif
 
 static void __init __maybe_unused build_assertions(void)
 {
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
index c8c5a04f24cb..3d503c697337 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -29,10 +29,7 @@
 #include 
 
 #include 
-
-#if __has_include()
-#   include 
-#endif
+#include 
 
 #define XENSTORE_PFN_LATE_ALLOC UINT64_MAX
 
@@ -505,11 +502,9 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
     if ( ret )
         goto err;
 
-#ifdef CONFIG_STATIC_SHM
     ret = make_resv_memory_node(kinfo, addrcells, sizecells);
     if ( ret )
         goto err;
-#endif
 
     /*
      * domain_handle_dtb_bootmodule has to be called before the rest of
@@ -802,11 +797,9 @@ static int __init construct_domU(struct domain *d,
         else
             assign_static_memory_11(d, &kinfo, node);
 
-#ifdef CONFIG_STATIC_SHM
         rc = process_shm(d, &kinfo, node);
         if ( rc < 0 )
             return rc;
-#endif
 
         rc = init_vuart(d, &kinfo, node);
         if ( rc < 0 )
diff --git a/xen/arch/arm/static-shmem.c b/xen/common/device-tree/static-shmem.c
similarity index 99%
rename from xen/arch/arm/static-shmem.c
rename to xen/common/device-tree/static-shmem.c
index 2055b7be0f3f..8023c0a484c1 100644
--- a/xen/arch/arm/static-shmem.c
+++ b/xen/common/device-tree/static-shmem.c
@@ -6,9 +6,9 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
-#include 
 
 typedef struct {
     struct domain *d;
diff --git a/xen/arch/arm/include/asm/static-shmem.h b/xen/include/xen/static-shmem.h
similarity index 96%
rename from xen/arch/arm/include/asm/static-shmem.h
rename to xen/include/xen/static-shmem.h
index 6a4c33cca8c2..76a49869126c 100644
--- a/xen/arch/arm/include/asm/static-shmem.h
+++ b/xen/include/xen/static-shmem.h
@@ -1,7 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
-#ifndef __ASM_STATIC_SHMEM_H_
-#define __ASM_STATIC_SHMEM_H_
+#ifndef XEN_STATIC_SHMEM_H
+#define XEN_STATIC_SHMEM_H
 
 #include 
 #include 
@@ -82,7 +82,7 @@ static inline void shm_mem_node_fill_reg_range(const struct kernel_info *kinfo,
 
 #endif /* CONFIG_STATIC_SHM */
 
-#endif /* __ASM_STATIC_SHMEM_H_ */
+#endif /* XEN_STATIC_SHMEM_H */
 
 /*
  * Local variables:
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 10:03:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 10:03:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004152.1383834 (Exim 4.92)
	(envelope-from )
	id 1uMOUt-0003PE-8T; Tue, 03 Jun 2025 10:03:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004152.1383834; Tue, 03 Jun 2025 10: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 1uMOUt-0003P1-4n; Tue, 03 Jun 2025 10:03:55 +0000
Received: by outflank-mailman (input) for mailman id 1004152;
 Tue, 03 Jun 2025 10: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 1uMOUr-00037b-Vm
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 10:03:53 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20605.outbound.protection.outlook.com
 [2a01:111:f403:200a::605])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0a2ed149-4062-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 12:03:48 +0200 (CEST)
Received: from DM6PR11CA0044.namprd11.prod.outlook.com (2603:10b6:5:14c::21)
 by CH3PR12MB8584.namprd12.prod.outlook.com (2603:10b6:610:164::14) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.31; Tue, 3 Jun
 2025 10:03:44 +0000
Received: from CH3PEPF00000014.namprd21.prod.outlook.com
 (2603:10b6:5:14c:cafe::cc) by DM6PR11CA0044.outlook.office365.com
 (2603:10b6:5:14c::21) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.30 via Frontend Transport; Tue,
 3 Jun 2025 10:03:44 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH3PEPF00000014.mail.protection.outlook.com (10.167.244.119) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.2 via Frontend Transport; Tue, 3 Jun 2025 10:03:44 +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 Jun
 2025 05:03:43 -0500
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 Jun 2025 05:03:41 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0a2ed149-4062-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=M1B6PPTuxZx6h1pqtMImihxFsGAAos8WkJX1PXw8rND5XkQTKFsT3VL16kQXBf8Io5uQ3atnztoyk2o51PpXjzWRevirbqUTourMeeY4bkwzQq6ECXbxTWFv5PVjwoivwV0e8A+PQBFIBjhLyaIEtmh3TOvPhDZJ7SqVzpqpoF8JFVwB310S7SA1PNEe2xH7i0w/LITy45UOe824LftQqqtwSuW/YGD/ZvjUaTB3ETplek2rl9kdzgsnWrrUeFxF8RiuP2XvbNANzVNM7in8ROyx3tWwryZhnG2phrrYmNyIsX6qL8smNP/eSFtp3QzwxEAB7Ve1z44oT+MXZnGRcA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Qr9xf2waTk4UgPXWOt3Ocr7pR0T3lTFOlQg+2lK/858=;
 b=LF34vAqrpTyC7UcbamVAVk+S7dM1KazfnNYjpbotztqsTbBTP2195fmP/mSljCcTAk8bqwmdqgZ99SJdPhGPmnKXQmXM0LJ6F/Gu7Ee5gdgAXzQsIktfWYj66iT380E4LU61zZegijonXZ4eR/cvCLac/WEufj224uJq/LfI+FZ6p18LVGtjnpgmxnDNYcDmOX8f3bIyoXeba6OrVtcU9BL1QcQtGWddvtXvl0ZrGU6NsGnSu26G62Uyc5a5Vjy9f7NEdfanY2tV1ZrwKbZohicHtYCyf7vkOX1VYVsZQ2+k3HFndZyAzCiHcomCCpLlwKV41uQEWP6EQPYWz+JvGQ==
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=Qr9xf2waTk4UgPXWOt3Ocr7pR0T3lTFOlQg+2lK/858=;
 b=APm4K0G/JabpAbtn9nWLSIbddAcPWnFGi+uCi0sW62eTZDwYzPl0DojJAAFo+0k2/uK09JxDwRaYQByckOKDjEy6btjvylN0PPPWzj46B0Et8goEnCBOJgYnHOdla5YSkEXVtR6OI8MynEMrlqpLy2cc12TkeNijkp4MbCv6HmY=
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 ,
	Andrew Cooper , Anthony PERARD
	, Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH 3/4] device-tree: Move Arm's static-memory feature to common
Date: Tue, 3 Jun 2025 12:03:28 +0200
Message-ID: <20250603100329.149851-4-michal.orzel@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20250603100329.149851-1-michal.orzel@amd.com>
References: <20250603100329.149851-1-michal.orzel@amd.com>
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: CH3PEPF00000014:EE_|CH3PR12MB8584:EE_
X-MS-Office365-Filtering-Correlation-Id: e5f549d9-e491-4339-647a-08dda285ec9f
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|376014|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?WnL9fqsvmOUmEJc6smW8JvEYGkmu+qOzO8F3pDzxyZYN1j1FywuuKz9HEXG9?=
 =?us-ascii?Q?/nDk7XP//Aof8W85jwKEdUfOe+MEVXN2+mdVUD1yBq1IZgL9Yo9WZscp/cy5?=
 =?us-ascii?Q?Q8moduzL46DOGWf0G2u7luAI9c9DpXW0VKqWi096yJsXvExwEGjfYzBe9/BA?=
 =?us-ascii?Q?y3H1NxetFXc40FjaJWbyR/hTM3layw8JvGIuvvQ67KevnVvpJXkylwhYk+cV?=
 =?us-ascii?Q?EzOIeMVUI58oojV+38en1u05O+HujCBssKxqZUwQx8V3vJHfzDszPPhIe0nN?=
 =?us-ascii?Q?TkzCSBYXHaGmmfol991ihcBz9WyncwWGOvvLibL2i2U31AqQlukK9NZg8if7?=
 =?us-ascii?Q?ByuNjKv2moU6okMvvqYFsOH+WScRwlgfDxvAwD9y+2urkP3rThnnF52Q4Dm2?=
 =?us-ascii?Q?Qx70RxUFm+26M65AfnlWTEUwthBPcRhjQp0tbHLPfJS4PwKuG4WmL+euWTiz?=
 =?us-ascii?Q?/PI1tijH+FqXI1ul6QzIy9dnigwsQDesGAO+MJqmBS1Nj7AOux+5n4SKT3LK?=
 =?us-ascii?Q?LCni2p4tQRm2GzPfS2+2/8W0kwzs6uEfiom7EssfS7C2OWSvHrKKd6Cf4Xpc?=
 =?us-ascii?Q?e+QC3PFoz0X7djt9V7K9f1bXDQq4hww6AcL11LFs6HC/PV0kRwZqfROv1gci?=
 =?us-ascii?Q?HmRRzKO6wFG+lUkmiy1nF9Fv//mb57guXhL9qMPZll5SEHBbtveRiJilVjby?=
 =?us-ascii?Q?HPEsWhGZAp+xkd9nG1XjM5RCgGNxUb5fxNPxWMVT6LGcvP3jhRHbzmK4MHHJ?=
 =?us-ascii?Q?2WvtDRQdWA1xMadI8/N7n0vx82+6bgR2AOznI2WjqaK59EIKX5TxVxTiozKc?=
 =?us-ascii?Q?DkIW+nypnxxgZlX7NaVve4Myr6DcvhX1dfNu6iyjt+65dOPtEm5BpPd8dj8B?=
 =?us-ascii?Q?dNDEuU3RLgI30LUQ1u/PA5PTLqkT8nf4Fl+smmojlgSokKuf4rYYmbnD+BDK?=
 =?us-ascii?Q?0Iz/EAffxwE4e1/tRbgT6kDcEUNOnkBhTA48PSt6KqsUQGBZjyx0OGM/Uylb?=
 =?us-ascii?Q?rRRcM5u4AxU8HaUylCwqGJ28CRD1ypUk1fdSZVZkChW7WjorBLCf9zjE4np9?=
 =?us-ascii?Q?ymCC2SVKS/wGPe8KcJQ/+2TaQ/G7hqkpTHSUAxGosnp5KJDwAaD4u/whCSRA?=
 =?us-ascii?Q?9dl3V5R6WftMhSyMtIhhmeGeBoPAks9NV6Y1+dD69QbJAe9+HFsZOYC5kgtm?=
 =?us-ascii?Q?AhxhwVaTm2KGuZNAXr47zZpY8g912FKgCzDQ91faHe0Xhne5rL66J0SGqQhR?=
 =?us-ascii?Q?vnoJnw0FtTW+ZObmB+bedVWFpfsBS75HYedd4QE1CbGChmkOza7xczLCAMuH?=
 =?us-ascii?Q?7Er3CuBuDGbFhYIgwJ2KvgZIDu6flV7M4yZK3iXtNAjTz0aYJMMahqoE7LT6?=
 =?us-ascii?Q?UQ9DHKq6Sy2dD+faLdheIoD15gfL2XpSIBpraG6HRdExOZxTunsDcXMHlF82?=
 =?us-ascii?Q?V6V3TejFyLz3h6pRqemJ18TUI8/BuocmZYdJPCC/zjfvMwLJdo2PIpLNsD/Z?=
 =?us-ascii?Q?85txE83EicVZ3fUhFKhe3Kpcx+hLbgoX0l5c?=
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);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jun 2025 10:03:44.0149
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e5f549d9-e491-4339-647a-08dda285ec9f
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:
	CH3PEPF00000014.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8584

This feature is arch agnostic, thus move it to common.

Signed-off-by: Michal Orzel 
---
 xen/arch/arm/Makefile                                    | 1 -
 xen/arch/arm/arm32/mmu/mm.c                              | 2 +-
 xen/arch/arm/arm64/mmu/mm.c                              | 2 +-
 xen/arch/arm/dom0less-build.c                            | 2 +-
 xen/arch/arm/static-shmem.c                              | 2 +-
 xen/common/device-tree/Makefile                          | 1 +
 xen/common/device-tree/dom0less-build.c                  | 6 +-----
 xen/{arch/arm => common/device-tree}/static-memory.c     | 2 +-
 .../arm/include/asm => include/xen}/static-memory.h      | 9 +++++----
 9 files changed, 12 insertions(+), 15 deletions(-)
 rename xen/{arch/arm => common/device-tree}/static-memory.c (99%)
 rename xen/{arch/arm/include/asm => include/xen}/static-memory.h (93%)

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index eeeac4e653ec..4f080145478d 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -51,7 +51,6 @@ obj-y += setup.o
 obj-y += shutdown.o
 obj-y += smp.o
 obj-y += smpboot.o
-obj-$(CONFIG_STATIC_MEMORY) += static-memory.init.o
 obj-$(CONFIG_STATIC_SHM) += static-shmem.init.o
 obj-y += sysctl.o
 obj-y += time.o
diff --git a/xen/arch/arm/arm32/mmu/mm.c b/xen/arch/arm/arm32/mmu/mm.c
index 956693232a1b..f3305e28e9df 100644
--- a/xen/arch/arm/arm32/mmu/mm.c
+++ b/xen/arch/arm/arm32/mmu/mm.c
@@ -6,9 +6,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
-#include 
 #include 
 
 static unsigned long opt_xenheap_megabytes __initdata;
diff --git a/xen/arch/arm/arm64/mmu/mm.c b/xen/arch/arm/arm64/mmu/mm.c
index c1efa1348aee..cded8f2787f9 100644
--- a/xen/arch/arm/arm64/mmu/mm.c
+++ b/xen/arch/arm/arm64/mmu/mm.c
@@ -4,9 +4,9 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
-#include 
 #include 
 
 /* Override macros from asm/page.h to make them work with mfn_t */
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index a49764f0add9..bcfd686a8b7f 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -22,7 +23,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #ifdef CONFIG_VGICV2
diff --git a/xen/arch/arm/static-shmem.c b/xen/arch/arm/static-shmem.c
index 21fd2c3cd4fd..2055b7be0f3f 100644
--- a/xen/arch/arm/static-shmem.c
+++ b/xen/arch/arm/static-shmem.c
@@ -5,9 +5,9 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
-#include 
 #include 
 
 typedef struct {
diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
index 57b9e6ca008f..ed11f2c3b42c 100644
--- a/xen/common/device-tree/Makefile
+++ b/xen/common/device-tree/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o
 obj-y += intc.o
 obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o
 obj-$(CONFIG_STATIC_EVTCHN) += static-evtchn.init.o
+obj-$(CONFIG_STATIC_MEMORY) += static-memory.init.o
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
index 39cb2cd5c70e..c8c5a04f24cb 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -28,9 +28,7 @@
 #include 
 #include 
 
-#if __has_include()
-#   include 
-#endif
+#include 
 
 #if __has_include()
 #   include 
@@ -799,12 +797,10 @@ static int __init construct_domU(struct domain *d,
     {
         if ( !dt_find_property(node, "xen,static-mem", NULL) )
             allocate_memory(d, &kinfo);
-#ifdef CONFIG_STATIC_MEMORY
         else if ( !is_domain_direct_mapped(d) )
             allocate_static_memory(d, &kinfo, node);
         else
             assign_static_memory_11(d, &kinfo, node);
-#endif
 
 #ifdef CONFIG_STATIC_SHM
         rc = process_shm(d, &kinfo, node);
diff --git a/xen/arch/arm/static-memory.c b/xen/common/device-tree/static-memory.c
similarity index 99%
rename from xen/arch/arm/static-memory.c
rename to xen/common/device-tree/static-memory.c
index e0f76afcd8eb..0774d0680604 100644
--- a/xen/arch/arm/static-memory.c
+++ b/xen/common/device-tree/static-memory.c
@@ -1,9 +1,9 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
 #include 
+#include 
 
 #include 
-#include 
 
 static bool __init append_static_memory_to_bank(struct domain *d,
                                                 struct membank *bank,
diff --git a/xen/arch/arm/include/asm/static-memory.h b/xen/include/xen/static-memory.h
similarity index 93%
rename from xen/arch/arm/include/asm/static-memory.h
rename to xen/include/xen/static-memory.h
index a32a3c6553bc..e445aa80578c 100644
--- a/xen/arch/arm/include/asm/static-memory.h
+++ b/xen/include/xen/static-memory.h
@@ -1,13 +1,14 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
-#ifndef __ASM_STATIC_MEMORY_H_
-#define __ASM_STATIC_MEMORY_H_
+#ifndef XEN_STATIC_MEMORY_H
+#define XEN_STATIC_MEMORY_H
 
 #include 
-#include 
 
 #ifdef CONFIG_STATIC_MEMORY
 
+#include 
+
 static inline void init_staticmem_bank(const struct membank *bank)
 {
     mfn_t bank_start = _mfn(PFN_UP(bank->start));
@@ -46,7 +47,7 @@ static inline void init_staticmem_pages(void) {};
 
 #endif /* CONFIG_STATIC_MEMORY */
 
-#endif /* __ASM_STATIC_MEMORY_H_ */
+#endif /* XEN_STATIC_MEMORY_H */
 
 /*
  * Local variables:
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 10:15:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 10:15:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004189.1383843 (Exim 4.92)
	(envelope-from )
	id 1uMOgI-0006dr-DK; Tue, 03 Jun 2025 10:15:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004189.1383843; Tue, 03 Jun 2025 10:15: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 1uMOgI-0006dk-Aj; Tue, 03 Jun 2025 10:15:42 +0000
Received: by outflank-mailman (input) for mailman id 1004189;
 Tue, 03 Jun 2025 10:15: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 1uMOgG-0006de-CN
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 10:15:40 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20604.outbound.protection.outlook.com
 [2a01:111:f403:2415::604])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b19490ce-4063-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 12:15:38 +0200 (CEST)
Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
 by PH8PR12MB6675.namprd12.prod.outlook.com (2603:10b6:510:1c2::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.27; Tue, 3 Jun
 2025 10:15:33 +0000
Received: from PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264]) by PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264%2]) with mapi id 15.20.8769.031; Tue, 3 Jun 2025
 10:15: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: b19490ce-4063-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=S0zORsoqMPDO7BG/kJq7g3omvibWtGutbh/iQK3MQX0BB3H7XLxOAg0UUZO7dzsEA0xBEhnt0ebauZ96bmZVA47n1W92D+xLpUCm2drU8tKNGe0qdt+cnZ7PIp2aTQ7//Toj2mAY5FRIMy+ZtLJst1JT4TYaiQ6LHGPee8eeAnJz3fEGXab02V/xSgJjhv5npBtn/EPMvrXQGSQQ9xq1Op+/dSrv0WVOsljONotsnIy22DvAOztRZHU4ztIQ12gNSTk3Z9sVzlZkMZ15bOxAftUP9CuymQYmvv5bZY/JG1qfLQwREHnvNu4KwJFL81gLzPB7bbuKlZSIE/Z3EoD57w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=VYOvf9r1OaYSnQZxFAyl2QboU/Idp5Ostc+Zjev2EhA=;
 b=HMSdBa3Op3untwYspgVWHL1g4NsGYXDfaxxMuzc+ZtXOJEFDEteXuvuifG65lmlADCN8G/NX72MZnTLuRLEzqqXK1N3sVBXiB9ABpbmkrcEQ9S4BqdBTMEUobpXtyKFDBIP6BwCRjpsRbv2pTNTIIShDe0pYH4QHwA1rY/PB7xn96PZaRbe+YwH0og2tmb5y7Q+CSSuGf9FoDLasNOEz5p/DEdTJ7qtowM9AayOWByuhM66veIH71Hb+8JpmTfxPTvwt8RZp2WjnWkv5DovgTA1ed+I4v7Ldwu0HhsE2npvAmrIXyQGWC7zQ6CtDNaXqcrIu/3C6ZIY8hTD8EVJOzA==
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=VYOvf9r1OaYSnQZxFAyl2QboU/Idp5Ostc+Zjev2EhA=;
 b=Pr1eMP10EU4moHdLnUVW2Ov2q9D3vEWnj51qPGulnxOskM4gJ227h0Kp66czT9/MI/mdUJ4qEe3DxRbY8XKIw+MWyv2x9SOVUKCoX2bJm1cbYeBfxGFs7Vo/B/RPL5AJuZVfyAz0rXMKQARaVAcGZv7w2U4GljfRVu8Mfiv7h4E=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <31594e99-d509-4081-852f-67ef2122149b@amd.com>
Date: Tue, 3 Jun 2025 11:15:28 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/2] docs: fusa: Define the requirements for
 XEN_VERSION hypercall.
To: Bertrand Marquis ,
 Ayan Kumar Halder 
Cc: "xen-devel@lists.xenproject.org" ,
 Stefano Stabellini ,
 Michal Orzel , Artem Mygaiev 
References: <20250509112447.2931909-1-ayan.kumar.halder@amd.com>
 <2040B386-299A-4BC5-BC59-7D3F58835A2B@arm.com>
Content-Language: en-GB
From: Ayan Kumar Halder 
In-Reply-To: <2040B386-299A-4BC5-BC59-7D3F58835A2B@arm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: MR2P264CA0075.FRAP264.PROD.OUTLOOK.COM
 (2603:10a6:500:32::15) To PH8PR12MB7326.namprd12.prod.outlook.com
 (2603:10b6:510:216::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|PH8PR12MB6675:EE_
X-MS-Office365-Filtering-Correlation-Id: 2e28583a-f6a9-4b41-fc0c-08dda2879324
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?Y1VGQ3FmbXhVNCtMdi9EaUVKWWl1cnlQTXZjZndHWlF4WHNJMlpGR3UxV0VL?=
 =?utf-8?B?UkpPbXdvS2RQb2YwbGJSTU9YNldkcmNCSlZ5M2JCL0ZKVjhWMDFqbFhPaktT?=
 =?utf-8?B?TlptTXNOekZhWktucjJCdmE4SVhYdnl5MlF5STJaTjcxZkRmajNaSmppcVZS?=
 =?utf-8?B?ckJNSFR2Qm1QTFBxODYwRWd0N1JlL2dPN1gxRUVrOHpmV2kyUXJ6dmpJMGJS?=
 =?utf-8?B?Vzk3S29KTjhwODZ4NzRLWk90YlU3Ri9JSGhwOGFvSjBHN1RZNjBmSmp6M0d1?=
 =?utf-8?B?Tzd5Ty9yQ2NWRlNXajBibFA4bThLMUJxU3VUbXczK1BRV1dWZk1yTGtjMWc5?=
 =?utf-8?B?TlQyUCtjY3prRGZxSGxYcjZYb3Ivem9VVEpXd0Vhb2RjSnRYaUh0Y2F4bUZv?=
 =?utf-8?B?cHg5R0wzdUZQMEFuamtXMGprMEIwWk1zNjdLdHpzYVBZZVhsd09oT2xrelJK?=
 =?utf-8?B?MHpJQUwwOGl3Uzk3QmhMaWE1TXA4UXFEYzFDb2w0dVAyQW9wUVdGRkE1dHNo?=
 =?utf-8?B?TFJ6Zk1rczFzOUdmL1JaNnA0dDVYN01ldzJpOVhBcFRUZFczOUxFcm0wQWFq?=
 =?utf-8?B?OUxVNW1YSnNqQlpDNm9kd1pNS1pDZUg0cHIzYWlDNEJScWxHSWhGWXNEVUxG?=
 =?utf-8?B?Q3dUcmhiSmxqaEJ4SUlVWGNNaDQwS1l4ZmhIdkIrRng5ejdrQmsrek14K1Ir?=
 =?utf-8?B?WWlseFZUOHlzV0xidnp2cGw3dXdnOFNVdkU5MXEyVHdzbGErYTNBN1k5MWRQ?=
 =?utf-8?B?K3E5NmxOQytPUXNPZnhJbVJ4em5Vb1FmbnV5aWNEalhzVWdidnROTFZxN3F0?=
 =?utf-8?B?TEI3cTVTWG9YcEk1KzhSUnVybXAwRU9LNmRyWlpzK242ckpCTW5zRjZwV0lT?=
 =?utf-8?B?cUVVN3NKTnhvNHU2azdWOFRxK29EcXBDUXVQcVdKbk1pbCthdzdOazFJSklB?=
 =?utf-8?B?T25xMHNRbUs1TXk3T0xwWGh1ODJVUHNCWEZ0Zk40SU1YUTNSWlFGbkl2YW82?=
 =?utf-8?B?RUlrUUV0MjBxT0VUaWtKN0xFajJkTTZhVWl3eEY0dEhkY0lia3hZVGI0NVk0?=
 =?utf-8?B?c2lia05xRnpTSnJGQWRtTHVWN2YzaVBDWUR1aktINFNSdE40NzJyYXIvUTl1?=
 =?utf-8?B?U3B3NWIra1hBaHcxZlBjaGNNOTRjdWNleWNzSm55dlI3djNxblAwMTFETkIr?=
 =?utf-8?B?RnhNeE9SUTRybVNqZDNDMk5kNlh0a1JpT0Rab0FEU2s5dXpsOHhkQUdlVjQ0?=
 =?utf-8?B?QU5ia0Nuay9uMTFMNVNlQWdRQWdZWDJSQllSWXRzTWNXNGJYOWczRWJUVUky?=
 =?utf-8?B?K2ZxTEl2M0Z0akg1ZGVXM1B4L1V2aCtaUG8yM1N3QjNIejdpWDlJM0d4MEF6?=
 =?utf-8?B?SDhPYnU3Ry9VK0Y3UWJ3TWJPRWFscFRncWFHWDRUU1JtNFBxeXViYldDbzRU?=
 =?utf-8?B?d005b2xFeU5ZNGRqbXViSWZSVzFpcWZ1MU5oZmphb21LeURER0k3a1BwQkxB?=
 =?utf-8?B?K2lIMlhRVEpaaFh1Zm5Jckp1TEs2YTAwR2VXVE5lR2xYOTl1MVAyY3k1d0Ur?=
 =?utf-8?B?TWNVLys1Wlc5QkhvUXhkQzN6cndvMmxCZkdHV095eFc5a0NWRVprSzd1bFoy?=
 =?utf-8?B?eThUV05vK3RVT3I4cy9SS1ErUGRUWGc4a3ZKWk5zOFV1RlJjYjFSVFlTTDA5?=
 =?utf-8?B?MUYxbmU3eVBxbTRDS3N6Q1Vhc0pHQ05RcVNNVktQdlhGNDNOTlU0dzJLWExZ?=
 =?utf-8?B?WDhiMDh4VmpJTUlBYkxOMkx2ZkR1cEp4MWFIS0I1MzdtNTVRV0xPRXBPaEFQ?=
 =?utf-8?B?bWs0dW9LTmdLT25qZmd1aWNhSjIzN3pKbzhUSHlOa3F6L2Zhc1o5M3NLaXBj?=
 =?utf-8?B?NHFoTERtTlNIbHZnS2E1MGloWXJrdm5lcG9WU0Rzc1JvamVtZ2NyRkFPQjdx?=
 =?utf-8?Q?gW7yAWL64sA=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)(376014)(366016)(1800799024);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?NlVtcU5NL2J3cysyYlRkaTB5YmZJc2dtR1VPQTJSeVg5cndxdk80NjM3ZHNY?=
 =?utf-8?B?V1V3SkFvMmwwOUEzYXk3bmY2TlhjV0NPbG1GWVMvcG9HWCsyU090QmIrRXNH?=
 =?utf-8?B?YnMwMjJzblIxQ1JvWmtGZytTQW52RGZ1R0FNbkFyTVBFQzdhbENkam1rRWVo?=
 =?utf-8?B?azFiZ2x5dnV4UHE4TW5PbkNteGZzdDM3by85WDVYTHQwQWJVakVwM2xzemlk?=
 =?utf-8?B?bDJ4SzFjRloxRlpMVmtMUzN6WXVoUW1SbjBLZXdLSStETjZRazY2YSszM1dp?=
 =?utf-8?B?UEFueWtKWXQrOHYyRDExbFFVZ0Z0K3BCWk9PakFmallpK0JyUUZyS0NrNUtn?=
 =?utf-8?B?RkI4cnR4bUJlejNKSWtTbDJKRm9DYWcrQXA5NSt1ZVZydEplSGxKNHprYVdp?=
 =?utf-8?B?bEdyWmN1NDNFUnNYSlNZM3NMSDlJM3c0R01FM1VYdGtXS001dEFDaWlVaXgw?=
 =?utf-8?B?R2R4bmhFN0NaUXQ1UXBLYlJtanVIaERUSnROREtwSzNQTXl5RkFobVNYdVpm?=
 =?utf-8?B?dDFNUzhFNE45R1cxU3NlK0oyaEFTRHlIa2tOWnpkd0NJa21WSnlEenBvYkRD?=
 =?utf-8?B?SmdLNVVSeUVDTk9lam9zdlhDOXVRL05lNGx0Q1FaS1pXM0Vndkp1K1Yrci8w?=
 =?utf-8?B?RFMvbXY4Ujh0YTZYNFpTK09hcFJLSEhWQUtVOExJNmIyWFZndUZ2ZDQxc1lF?=
 =?utf-8?B?R2FGbmtJeWpvbFkzc0FwcU9DOUQwWHlERERUSHlMaVpaWXBYQzIvM1NFWUtk?=
 =?utf-8?B?eHVZaHRZVmZCZldGZ093d0kvYjNvK0RhcUJndy9CZjhhWENGbnJaclBGQ2tz?=
 =?utf-8?B?RXZ2cUxYN01NVkxTcHRDUFBldVA5S2hOZ2xzTTRzajlEOHhRSHlTRmRyc3l3?=
 =?utf-8?B?WmlMRzU1aTBKN2NnWnVkT01GWkZoTXp0T1pDL2dhdmZFZmhYdzdYSEdWRXIr?=
 =?utf-8?B?SEpzM0pHWEp4TllzTmJ0Zm1sWC9jVEM4U1lrMElKSWEzSnBPbVJWSWpFa1l2?=
 =?utf-8?B?WGpreHBqYkJxTUJWNGJMWnhLK0h0QzFIQW5ybG1lQTFaNC8yeXlPRFc3aGRr?=
 =?utf-8?B?elZsbEc2aFUydUhWMHk5a0V2TTZqUE9ZSWdZVkVrTDEzbEdiSVFNcE5Wcks5?=
 =?utf-8?B?N2RSbWRVKzcxbTNXVnNPWVlyZUJyUXdZdTlGYm9PbWxDYnNlZ210VTFtcTBT?=
 =?utf-8?B?MnZaR3o0S1JEUzQvbFlWNkFtbVNaNmh1T2J3VWFYU01RZG1OZ0pvUU16WExF?=
 =?utf-8?B?SGI5VXZzMEU3TnA2Um1RcElCdEI2WTJpd1didlRkS1pBbU9QTHllcURHYjBO?=
 =?utf-8?B?b2Q4aUwyY04ydGtRbFlLSVErd3VkU0FNZzJXNGt1bDhNbDBYZDJ6NXZqTGJF?=
 =?utf-8?B?VU1MVW4vTFovUXNqWWRuQ3RZTitZK3M0WDBGYUx5K2tRT1NDTUxOejkrQkl1?=
 =?utf-8?B?czZXOXFFZjhIQmxYSXlGUlpkeTN3d3ZrRWRTUmJucmRoUDBraGJJMjJ3VHFC?=
 =?utf-8?B?S3I4aDVEeEVBUlVXYTgzdmVrN09zamhSYTFDZXlUZWZZeEo5cHBWVm50RzVp?=
 =?utf-8?B?T2hOMGRHSWJDOHp0bHYrMjdBV1YxVVQvRVV6bStkY1p5YzVGUlBvMmZ5WDNR?=
 =?utf-8?B?VWd0bWNsNW4wYlV4QzByWUdLVE90cStIYTdOSGFIY3ErTEdiQk9DSmhQMU02?=
 =?utf-8?B?eURWN3RQV2lyOFFRM213TlBYTTZrQWtEU2VOQzVxcmJIV2hBWlhrVmFWRmxy?=
 =?utf-8?B?YkRoYlFxb0VtVlZOS0N5Y09qZVRSQmRGR050TXF4NlQrMjQyL0lRYXRxZkth?=
 =?utf-8?B?NU15a0QrWjNjYTg1dnlMZytiZ2QvQzM5NEtuTEtSaHdxNElkd0ZsbWhmWHZn?=
 =?utf-8?B?MUVLVGNocGlMdDBLMitsTTF2aXFGM3Z2WmFjK2NOWm5ZZ0o2ZFZvcjFHZlpZ?=
 =?utf-8?B?MFNCM284b3d3WDRld05zRWprVGhUMzBPMkVueWZXaVFaaXd3dVFUenRobEtk?=
 =?utf-8?B?UjhIcHhEcWdBL0Q4aG9ueEZYK3dRMFZlUG9taEtFVWpCYUNqTFM5dEY4M24v?=
 =?utf-8?B?T0RWODVEVmk5Lzd1VDRCUDFYUlhyYnlVbDhPQ3lSd1VZR3puZERGcHRhcnZr?=
 =?utf-8?Q?Q+zu6/9337jqxPu244qOCqne9?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2e28583a-f6a9-4b41-fc0c-08dda2879324
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jun 2025 10:15:33.1127
 (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: 0E0OOvPmwhMK+N48zJOgTNOlvSbXD3IAzNkbNBNEhRoWfV2RcuHAiwQoyfLSdSYQxtn2olG6RdjP+oDDqvnu/Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB6675


On 21/05/2025 13:02, Bertrand Marquis wrote:
> Hi Ayan,

Hi Bertrand,

>
>> On 9 May 2025, at 13:24, Ayan Kumar Halder  wrote:
>>
>> Define the requirements which are common for all the commands for XEN_VERSION
>> hypercall.
>>
>> Signed-off-by: Ayan Kumar Halder 
>> ---
>> Changes from -
>>
>> v1 - 1. Fixed `XenProd~version_hyp_ret_val~1` requirement as Xen does not return
>> 0 for success in all the cases.
>> 2. Reworded the requirements so as to write them from Xen's perspective (not
>> domain's perspective).
>>
>> v2 - 1. Specified the register details.
>> 2. Specified the type of buffer.
>>
>> .../fusa/reqs/design-reqs/arm64/hypercall.rst | 58 +++++++++++++++++++
>> docs/fusa/reqs/index.rst                      |  2 +
>> docs/fusa/reqs/market-reqs/reqs.rst           | 16 +++++
>> .../reqs/product-reqs/version_hypercall.rst   | 43 ++++++++++++++
>> 4 files changed, 119 insertions(+)
>> create mode 100644 docs/fusa/reqs/design-reqs/arm64/hypercall.rst
>> create mode 100644 docs/fusa/reqs/product-reqs/version_hypercall.rst
>>
>> diff --git a/docs/fusa/reqs/design-reqs/arm64/hypercall.rst b/docs/fusa/reqs/design-reqs/arm64/hypercall.rst
>> new file mode 100644
>> index 0000000000..f00b0b00f9
>> --- /dev/null
>> +++ b/docs/fusa/reqs/design-reqs/arm64/hypercall.rst
>> @@ -0,0 +1,58 @@
>> +.. SPDX-License-Identifier: CC-BY-4.0
>> +
>> +Hypercall
>> +=========
>> +
>> +Instruction
>> +-----------
>> +
>> +`XenSwdgn~arm64_hyp_instr~1`
>> +
>> +Description:
>> +Xen shall treat domain hypercall exception as hypercall requests.
> This really reads weirdly.
> Maybe: Xen shall treat domain hvc instruction execution as hypercall requests.
>
> Then you can add a comment to explain that this is detected through a specific exception.
>
> Also this is not completely true as hvc is also used in other scenarios:
> - PSCI calls
> - Firmware calls
>
> So i would put the 0xEA1 value as part of the requirement.

Description:

Xen shall treat domain hvc instruction execution (with 0xEA1) as hypercall requests.

Comments:
The exception syndrome register should have the following values :-
ESR_EL2.ISS should be 0xEA1.
ESR_EL2.EC should be 0x16.

>
>> +
>> +Rationale:
>> +
>> +Comments:
>> +Hypercall is one of the communication mechanism between Xen and domains.
>> +Domains use hypercalls for various requests to Xen.
>> +Domains use 'hvc #0xEA1' instruction to invoke hypercalls.
>> +
>> +Covers:
>> + - `XenProd~version_hyp_first_param~1`
>> + - `XenProd~version_hyp_second_param~1`
>> +
>> +Parameters
>> +----------
>> +
>> +`XenSwdgn~arm64_hyp_param~1`
>> +
>> +Description:
>> +Xen shall use the first five cpu core registers to obtain the arguments for
>> +domain hypercall requests.
> Why not say x0 to x4 registers instead ? You use x16 after anyway
Ack
>
>> +
>> +Rationale:
>> +
>> +Comments:
>> +Xen shall read the first register for the first argument, second register for
>> +the second argument and so on.
>> +
>> +Covers:
>> + - `XenProd~version_hyp_first_param~1`
>> + - `XenProd~version_hyp_second_param~1`
>> +
>> +Hypercall number
>> +----------------
>> +
>> +`XenSwdgn~arm64_hyp_num~1`
>> +
>> +Description:
>> +Xen shall read x16 to obtain the hypercall number.
>> +
>> +Rationale:
>> +
>> +Comments:
>> +
>> +Covers:
>> + - `XenProd~version_hyp_first_param~1`
>> + - `XenProd~version_hyp_second_param~1`
>> diff --git a/docs/fusa/reqs/index.rst b/docs/fusa/reqs/index.rst
>> index 1088a51d52..d8683edce7 100644
>> --- a/docs/fusa/reqs/index.rst
>> +++ b/docs/fusa/reqs/index.rst
>> @@ -10,5 +10,7 @@ Requirements documentation
>>     market-reqs/reqs
>>     product-reqs/reqs
>>     product-reqs/arm64/reqs
>> +   product-reqs/version_hypercall
>>     design-reqs/arm64/generic-timer
>>     design-reqs/arm64/sbsa-uart
>> +   design-reqs/arm64/hypercall
>> diff --git a/docs/fusa/reqs/market-reqs/reqs.rst b/docs/fusa/reqs/market-reqs/reqs.rst
>> index 2d297ecc13..0e29fe5362 100644
>> --- a/docs/fusa/reqs/market-reqs/reqs.rst
>> +++ b/docs/fusa/reqs/market-reqs/reqs.rst
>> @@ -79,3 +79,19 @@ Comments:
>>
>> Needs:
>>   - XenProd
>> +
>> +Version hypercall
>> +-----------------
>> +
>> +`XenMkt~version_hypercall~1`
>> +
>> +Description:
>> +Xen shall provide an interface for the domains to retrieve Xen's version, type
>> +and compilation information.
> I would say hypercall instead of interface here
Ack
>
>> +
>> +Rationale:
>> +
>> +Comments:
>> +
>> +Needs:
>> + - XenProd
>> diff --git a/docs/fusa/reqs/product-reqs/version_hypercall.rst b/docs/fusa/reqs/product-reqs/version_hypercall.rst
>> new file mode 100644
>> index 0000000000..400d51bbeb
>> --- /dev/null
>> +++ b/docs/fusa/reqs/product-reqs/version_hypercall.rst
>> @@ -0,0 +1,43 @@
>> +.. SPDX-License-Identifier: CC-BY-4.0
>> +
>> +Version hypercall
>> +=================
>> +
>> +First Parameter
>> +---------------
>> +
>> +`XenProd~version_hyp_first_param~1`
>> +
>> +Description:
>> +Xen shall treat the first argument (as an integer) to denote the command number
>> +for the hypercall.
> I would be more precise and say x0 value.
Ack
>
> Also "integer" is unspecified, use a more specific type definition (32/64 bit signed/unsigned integer).

It is a signed integer. The size is not mentioned.

ret = do_xen_version((int)(a1), (XEN_GUEST_HANDLE_PARAM(void)){ _p(a2) });

>
>> +
>> +Rationale:
>> +
>> +Comments:
>> +
>> +Covers:
>> + - `XenMkt~version_hypercall~1`
>> +
>> +Needs:
>> + - XenSwdgn
>> +
>> +Second Parameter
>> +----------------
>> +
>> +`XenProd~version_hyp_second_param~1`
>> +
>> +Description:
>> +Xen shall treat the second argument as a virtual address (mapped as Normal
>> +Inner Write-Back Outer Write-Back Inner-Shareable) to buffer in domain's
>> +memory.
> You should say "guest virtual address" to be more precise.

Ack

s/guest/domain

- Ayan

>
>> +
>> +Rationale:
>> +
>> +Comments:
>> +
>> +Covers:
>> + - `XenMkt~version_hypercall~1`
>> +
>> +Needs:
>> + - XenSwdgn
>> -- 
>> 2.25.1
>>
> Cheers
> Bertrand
>


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 10:30:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 10:30:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004196.1383854 (Exim 4.92)
	(envelope-from )
	id 1uMOus-0001RU-LU; Tue, 03 Jun 2025 10:30:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004196.1383854; Tue, 03 Jun 2025 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 1uMOus-0001RN-I5; Tue, 03 Jun 2025 10:30:46 +0000
Received: by outflank-mailman (input) for mailman id 1004196;
 Tue, 03 Jun 2025 10:30: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 1uMOur-0001Pz-Hh
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 10:30:45 +0000
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com
 [2a00:1450:4864:20::329])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ce160493-4065-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 12:30:44 +0200 (CEST)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-442eb5d143eso54777115e9.0
 for ; Tue, 03 Jun 2025 03:30:44 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-450d8000f3esm158682575e9.23.2025.06.03.03.30.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 03 Jun 2025 03:30:43 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ce160493-4065-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748946644; x=1749551444; 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=9Qcc1ZQtdUX84i6GJLDoeihRG+X6QiJugMzgDRCUCpA=;
        b=Xhhuo0+E9xO7vpZOSNF/vGnJNHA4r0FSqh4O9vifjmCDDaw2Xb+pgMsffdH2UxXM0m
         lfX5LgMx1lKfKT0uz+7tVYvdkCAxZfYIQSvp5etdcPeseUww+vXnV2o41NzDgUbfHN4E
         dwsoDLE52z5IL2k0fr3dJD8S7m+z2tTxBJVN0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748946644; x=1749551444;
        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=9Qcc1ZQtdUX84i6GJLDoeihRG+X6QiJugMzgDRCUCpA=;
        b=kEAR8Ee2camLmbEFzNe5GEuq0dvO+AqIuFQFdmlbxuKsxI+OMfrnFuwnqYvQXvrfjn
         Tfsjv+WruMQiS5wmynTrXh/inymFk3sX5oyobmP4uSVZSIL5n0yp1NZDjPqVlXL8MsqF
         CmrT35PEOFNEv4vpZ6VCegLGbx/N9otMlCa3CYWEK79IPxXpCy66+QXouwDu49DchBzc
         UftldKQr4n1UkR9HXrVXV65npKEZcdI6XshsyrqBG4Ik9s6l4y4BQ8fm2a+zcX0+nb91
         8i87jGFUymOYkDlrtVba0w0YxBwHSAPxi0uN6MRbnNp/P+jyJTz6gphmDaIsBUeqvGb4
         ZRcQ==
X-Gm-Message-State: AOJu0YwFVUNv/GVVpfSROg8vjSt46BWgbUHbFqy2IUkQLJXurqOhj3Xo
	jrgsJLP2XMsi9SiGUQFc1wu+igm3WQnYxjuP51jYku6Bw023dQuwNbC16UMQgUa+16E=
X-Gm-Gg: ASbGnctLou5jnV37sKzlcZzAvH5Q4lcc5TNQ0i3R6NJlXPj5FdrP+SHJeszypq1BxDB
	Y7FL0S+ysYwgdR1WKwHwogYx23k5x9zn/sWoNKkaaasMRJ59LP3eyqybrKZGdst8WVQTlDBQvn7
	yg2Cw+AKUBeY8EMVyblrE/+DeDsIxlGfrLq1Xuy1yVAbnVPOHQjAv1g4w7Ys2wENr9/FnocYf1P
	ITYoKRGbRfK/3kkdTMd8m2bTGrERKdd+0CDVv5MOdd+W0u+1j57kG7Y/vuBv03S+3BoRKj4yrAp
	600wOMazo1aivN35+KOijPpxwq01nI2LElwrnk/zsgzDE97D/M9eFN9CoLqDrbUtHWuJ08JRiOl
	4i3BsoSoTzH29pkL8dDFo+/Du
X-Google-Smtp-Source: AGHT+IHPToY1EEAsDqnXwPsSiO1r/W26mAt0+pUwtxoUtKs7JfjMV89Hngtgs3qrdlyjjRrWq+2hCA==
X-Received: by 2002:a05:600c:8b0f:b0:43c:f63c:babb with SMTP id 5b1f17b1804b1-4511ecbbdc4mr94366225e9.1.1748946643561;
        Tue, 03 Jun 2025 03:30:43 -0700 (PDT)
Date: Tue, 3 Jun 2025 12:30:42 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: "Orzel, Michal" 
Cc: xen-devel@lists.xenproject.org,
	Anthony PERARD 
Subject: Re: [PATCH] tests/vpci: Use $(CC) instead of $(HOSTCC)
Message-ID: 
References: <20250602150929.10679-1-michal.orzel@amd.com>
 
 <6438a00b-a0fe-419d-b57e-5e1af48d43ce@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <6438a00b-a0fe-419d-b57e-5e1af48d43ce@amd.com>

On Tue, Jun 03, 2025 at 08:52:38AM +0200, Orzel, Michal wrote:
> 
> 
> On 03/06/2025 08:46, Roger Pau Monné wrote:
> > On Mon, Jun 02, 2025 at 05:09:29PM +0200, Michal Orzel wrote:
> >> These tests are supposed to run on target. HOSTCC can be different than
> >> CC (when cross-compiling). At the moment, tests installation would put
> >> a binary of a wrong format in the destdir.
> >>
> >> Fixes: e90580f25bd7 ("vpci: introduce basic handlers to trap accesses to the PCI config space")

Hm, it's unclear to me whether this is the correct fixes tag.
Previous to:

96a587a05736 tools/tests: Add install target for vPCI

The test was not installed on the host, and hence didn't need to use
CC instead of HOSTCC (or at least that's my understating).

> >> Signed-off-by: Michal Orzel 
> >> ---
> >>  tools/tests/vpci/Makefile | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/tools/tests/vpci/Makefile b/tools/tests/vpci/Makefile
> >> index 9450f7593a41..1101a669e118 100644
> >> --- a/tools/tests/vpci/Makefile
> >> +++ b/tools/tests/vpci/Makefile
> >> @@ -11,7 +11,7 @@ run: $(TARGET)
> >>  	./$(TARGET)
> >>  
> >>  $(TARGET): vpci.c vpci.h list.h main.c emul.h
> >> -	$(HOSTCC) $(CFLAGS_xeninclude) -g -o $@ vpci.c main.c
> >> +	$(CC) $(CFLAGS_xeninclude) -g -o $@ vpci.c main.c
> > 
> > This was already posted in:
> > 
> > https://lore.kernel.org/xen-devel/20230313121226.86557-1-roger.pau@citrix.com/
> > 
> > And got no feedback.
> > 
> > I'm happy for your change to go in, but you might also consider
> > picking up the run target adjustment part of that previous patch.
> You're the maintainer of this file. You should tell me what I need to do
> unless you want to wait for Anthony feedback.

I would also add the chunk to adjust the run target if you use CC
instead of HOSTCC.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 10:46:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 10:46:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004207.1383864 (Exim 4.92)
	(envelope-from )
	id 1uMPAL-0003ag-VJ; Tue, 03 Jun 2025 10:46:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004207.1383864; Tue, 03 Jun 2025 10:46: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 1uMPAL-0003aZ-R2; Tue, 03 Jun 2025 10:46:45 +0000
Received: by outflank-mailman (input) for mailman id 1004207;
 Tue, 03 Jun 2025 10:46: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 1uMPAK-0003aT-Nm
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 10:46:44 +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 0855fc02-4068-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 12:46:41 +0200 (CEST)
Received: from phl-compute-01.internal (phl-compute-01.phl.internal
 [10.202.2.41])
 by mailfout.phl.internal (Postfix) with ESMTP id 6A2EE138011B;
 Tue,  3 Jun 2025 06:46:40 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-01.internal (MEProxy); Tue, 03 Jun 2025 06:46:40 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 3 Jun 2025 06:46:39 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0855fc02-4068-11f0-b894-0df219b8e170
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=1748947600;
	 x=1749034000; bh=vzcA9HWTWIUMZB9oPmUpNB6+WB4ekEb8Hk9INiG/UfU=; b=
	N69I8BVxr+V8NS4TAQss4jYyaDDwhC74i93UsKz6r8uaPROUu/R1WW/Er4H+KgFh
	xf6vWETGeUuskcQ24X5HDqq5jBceV8Q7puqNFp2b7fAtMsz/I0cVcd2viCgMkwha
	GD6ZnPkQcsRHpcXTTQAvTCDnEgI6awx159XfqfHPcP3mRKYwsEWp+W+hY9Jo2hnO
	J2HbiMBMOuwjYSN8vFFEDUYFz7m/GkX3vHYWECh8yPLAa45ebouAcv6MQ2xnWN1O
	920H7IuSdn+07V+BA3h8oE90C8zgAIHgv8R+o/1/X7d/t45lK7qj41Pe+zwG1D03
	TzUN6ktnKz3X95ypmfwKfA==
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=
	1748947600; x=1749034000; bh=vzcA9HWTWIUMZB9oPmUpNB6+WB4ekEb8Hk9
	INiG/UfU=; b=ONj4NdSMLbp7TPMdYFAeL4/wNs+YcWPZDNjSLm8PDoPXABEdBbh
	QMc+1zTpv0ZMqcW3Bp/8j35SdiDxLbWcDIgYaHgifwHxSzNA+QzDt1n2BbgzwSpx
	+VKiO9Z26ObsHcuJtuss5mOk98He7syvPvW8AnNTZMlRtxcr2J72QJQInOXt8fzW
	bdOpR+WBT4PW9YbOlnvTYB6/z6rcmkJxp+jMtpFIO0JkWtmS/ejh9xW/XDRQJbZz
	NO5MzxWrFvWHZxKpcKfFi1cST+e9sq1Kkyy2htOM5LO+eCGQ9oEBG+TRzgOzyUGw
	htq9LwrmoH2asbXzQB7oXMQnW2C7osj7zSw==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugddtgecutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr
    tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnth
    hsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecu
    hfhrohhmpeforghrvghkucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrg
    hrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffr
    rghtthgvrhhnpefgudelteefvefhfeehieetleeihfejhfeludevteetkeevtedtvdegue
    etfeejudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm
    pehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsg
    gprhgtphhtthhopeegpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegrnhgurhgv
    fidrtghoohhpvghrfeestghithhrihigrdgtohhmpdhrtghpthhtohepgigvnhdquggvvh
    gvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtoheprghnthhh
    ohhnhidrphgvrhgrrhgusehvrghtvghsrdhtvggthhdprhgtphhtthhopehjghhrohhssh
    esshhushgvrdgtohhm
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Tue, 3 Jun 2025 12:46:36 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Andrew Cooper 
Cc: Xen-devel ,
	Anthony PERARD ,
	Juergen Gross 
Subject: Re: [PATCH] Revert tools/python part of "tools: remove support for
 running a guest with qemu-traditional"
Message-ID: 
References: <20250602112253.2628571-1-andrew.cooper3@citrix.com>
 
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="RPDInwLMpp7r77WP"
Content-Disposition: inline
In-Reply-To: 


--RPDInwLMpp7r77WP
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 3 Jun 2025 12:46:36 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Andrew Cooper 
Cc: Xen-devel ,
	Anthony PERARD ,
	Juergen Gross 
Subject: Re: [PATCH] Revert tools/python part of "tools: remove support for
 running a guest with qemu-traditional"

On Mon, Jun 02, 2025 at 12:31:59PM +0100, Andrew Cooper wrote:
> On 02/06/2025 12:27 pm, Marek Marczykowski-G=C3=B3recki wrote:
> > On Mon, Jun 02, 2025 at 12:22:53PM +0100, Andrew Cooper wrote:
> >> The migration stream is a stable ABI.  What this does is break the abi=
lity to
> >> inspection and operate on pre-Xen-4.21 streams.
> > Do you mean Xen 4.21 should be able to accept migration of a domU with
> > qemu trad? I don't think it's a desirable feature...
>=20
> xl is free to reject a qemu-trad stream if it wants.
>=20
> What's not ok is verify-stream-v2 exploding with "unknown emulator 1"
> when I ask it to tell me what the bytes in this stream mean.

I see, in that case:

Acked-by: Marek Marczykowski-G=C3=B3recki 

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

--RPDInwLMpp7r77WP
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmg+0owACgkQ24/THMrX
1yydpwf+KXqUOqyAfR2SazoUISvmNHq2abr7Fb96AngaDfMSqmXKoBnDVC5nhIPk
z7WJ2ZlwNxub2eYWdkq3u9GICuIuwr1OmBJYfFsbpDlskm/I2/+XM9KHvEZqaa5G
+l1ojkbMFiGQbqJ0jMCfYZ5DMMMOkR1k3StoweluFW696FbyDwlZUapsukwkQEnI
lXpQaj5g8qVszLdHk4mKBgeUZBO2fXRo/VU+bEbLAiOwdXMvvnuTzcPVnv5mYIFe
D5jFYed0Lvdbf+O05XGd4srcDS2puWCxSRePUwSLf2M4um6is7Mud+AOKFOzghpu
1onLoECMElWLBOGvPoyoz4U+Z7m/bA==
=hdj1
-----END PGP SIGNATURE-----

--RPDInwLMpp7r77WP--


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 10:51:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 10:51:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004217.1383873 (Exim 4.92)
	(envelope-from )
	id 1uMPEX-0005MF-HC; Tue, 03 Jun 2025 10:51:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004217.1383873; Tue, 03 Jun 2025 10:51:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMPEX-0005M8-Ei; Tue, 03 Jun 2025 10:51:05 +0000
Received: by outflank-mailman (input) for mailman id 1004217;
 Tue, 03 Jun 2025 10:51: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 1uMPEW-0005M2-DU
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 10:51:04 +0000
Received: from fhigh-a6-smtp.messagingengine.com
 (fhigh-a6-smtp.messagingengine.com [103.168.172.157])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a3cbfa94-4068-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 12:51:02 +0200 (CEST)
Received: from phl-compute-02.internal (phl-compute-02.phl.internal
 [10.202.2.42])
 by mailfhigh.phl.internal (Postfix) with ESMTP id 8FB331140110;
 Tue,  3 Jun 2025 06:51:01 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-02.internal (MEProxy); Tue, 03 Jun 2025 06:51:01 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 3 Jun 2025 06:51:00 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a3cbfa94-4068-11f0-b894-0df219b8e170
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=1748947861;
	 x=1749034261; bh=zUI3kzG1Nt/W2ueMOc7+YFtXPhLR/wqWeu6WRS2IapA=; b=
	ZW91Y2ZkZtlvkgTB02Gt395TjVH5vR8Y3P/JsjK8xArScqRT4rc2aptTuSYtPeRu
	KTzHjIxR6bVZp/YUbcWII+BIK1tz1iTU2P2DMkkFlqAtokBMVHfC7PhDLdEp/7gH
	rkG5Sx9MMN5MjXZQRdCwY0yp0jd1VfJbh6iQW1iPeBLlX8kCGu9YbD4L7qdMtZig
	cUY5XR6t6ghjEaQvBieG2xelVedeSrtrJ5WvawkMmpDxE7P2o5kFhdHIOJHQ75CE
	OItusas3phYiwAequCNEjUlAq/Db1L1vDXGei4bmNR/WpzLz5giFPaPCyKn5tzFj
	ohCsnG8mFscJtEt/CPD+1w==
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=
	1748947861; x=1749034261; bh=zUI3kzG1Nt/W2ueMOc7+YFtXPhLR/wqWeu6
	WRS2IapA=; b=E9bT6qRWB+oWeFH+MMCVupmO6vb5+m63mxb9SUsYOcdzDxACENn
	ReuvXHp/Tioo3ubvDWie7SOTUVrvqv50WKSy3uJrbaooOmJW+cWjcWBThBJ1iVHf
	GzEeVoenJbr3ZWkOV2QY1Xk2+oY6dBljgkH+Qa9+cP8BDW0d6+gmHhlwmcPVTvmg
	OFDtfbHDvyvORcMr4JQlNIzOB3MMK40UtzkjVZBHTEcC6ofq6fhAIUDk33nE8GTD
	6aLrt03nnfwqwZWqN3pVwXgs6QNIQIDwGxE6E9+dwEE09EUNL8A9h8g/8PWp5rTp
	0cUJERQx2BZkSxDH3ZkFA5uPW9m9HeJBlNA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugddtgecutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr
    tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnth
    hsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecu
    hfhrohhmpeforghrvghkucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrg
    hrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffr
    rghtthgvrhhnpefgudelteefvefhfeehieetleeihfejhfeludevteetkeevtedtvdegue
    etfeejudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm
    pehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsg
    gprhgtphhtthhopeehpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegrnhgurhgv
    fidrtghoohhpvghrfeestghithhrihigrdgtohhmpdhrtghpthhtohepgigvnhdquggvvh
    gvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtoheprghnthhh
    ohhnhidrphgvrhgrrhgusehvrghtvghsrdhtvggthhdprhgtphhtthhopehsshhtrggsvg
    hllhhinhhisehkvghrnhgvlhdrohhrghdprhgtphhtthhopehmihgthhgrlhdrohhriigv
    lhesrghmugdrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Tue, 3 Jun 2025 12:50:58 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Andrew Cooper 
Cc: Xen-devel ,
	Anthony PERARD ,
	Stefano Stabellini ,
	Michal Orzel 
Subject: Re: [PATCH 1/2] CI: Use bash arrays to simplfy dom0 rootfs
 construction
Message-ID: 
References: <20250602174618.2641439-1-andrew.cooper3@citrix.com>
 <20250602174618.2641439-2-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="GPtApHH0LFsiAuht"
Content-Disposition: inline
In-Reply-To: <20250602174618.2641439-2-andrew.cooper3@citrix.com>


--GPtApHH0LFsiAuht
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 3 Jun 2025 12:50:58 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Andrew Cooper 
Cc: Xen-devel ,
	Anthony PERARD ,
	Stefano Stabellini ,
	Michal Orzel 
Subject: Re: [PATCH 1/2] CI: Use bash arrays to simplfy dom0 rootfs
 construction

On Mon, Jun 02, 2025 at 06:46:17PM +0100, Andrew Cooper wrote:
> For Qubes, this requires switching from sh to bash.
>=20
> This reduces the number of times the target filename needs to be written =
to 1.
>=20
> Expand the comment to explain the concatination constraints.
>=20
> No functional change.
>=20
> Signed-off-by: Andrew Cooper 

With typo below fixed:

Reviewed-by: Marek Marczykowski-G=C3=B3recki 

> ---
> CC: Anthony PERARD 
> CC: Stefano Stabellini 
> CC: Michal Orzel 
> CC: Marek Marczykowski-G=C3=B3recki 
>=20
> v2:
>  * Use dom0_rootfs_extra_{un,}comp arrays
> ---
>  automation/scripts/qubes-x86-64.sh            | 18 ++++++++++++-----
>  .../scripts/xilinx-smoke-dom0-x86_64.sh       | 20 ++++++++++++-------
>  2 files changed, 26 insertions(+), 12 deletions(-)
>=20
> diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qube=
s-x86-64.sh
> index 8e86940c6eff..5ec6eff6c469 100755
> --- a/automation/scripts/qubes-x86-64.sh
> +++ b/automation/scripts/qubes-x86-64.sh
> @@ -1,4 +1,4 @@
> -#!/bin/sh
> +#!/bin/bash
> =20
>  set -ex -o pipefail
> =20
> @@ -22,6 +22,8 @@ domU_type=3D"pvh"
>  domU_vif=3D"'bridge=3Dxenbr0',"
>  domU_extra_config=3D
>  retrieve_xml=3D
> +dom0_rootfs_extra_comp=3D()
> +dom0_rootfs_extra_uncomp=3D()
> =20
>  case "${test_variant}" in
>      ### test: smoke test & smoke test PVH & smoke test HVM & smoke test =
PVSHIM
> @@ -187,10 +189,16 @@ Kernel \r on an \m (\l)
>      rm -rf rootfs
>  fi
> =20
> -# Dom0 rootfs
> -cp binaries/ucode.cpio binaries/dom0-rootfs.cpio.gz
> -cat binaries/rootfs.cpio.gz >> binaries/dom0-rootfs.cpio.gz
> -cat binaries/xen-tools.cpio.gz >> binaries/dom0-rootfs.cpio.gz
> +# Dom0 rootfs.  The order or concatination is important; ucode wants to =
come

                             of

> +# first, and all uncompressed must be ahead of compressed.
> +dom0_rootfs_parts=3D(
> +    binaries/ucode.cpio
> +    "${dom0_rootfs_extra_uncomp[@]}"
> +    binaries/rootfs.cpio.gz
> +    binaries/xen-tools.cpio.gz
> +    "${dom0_rootfs_extra_comp[@]}"
> +)
> +cat "${dom0_rootfs_parts[@]}" > binaries/dom0-rootfs.cpio.gz
> =20
>  # test-local configuration
>  mkdir -p rootfs
> diff --git a/automation/scripts/xilinx-smoke-dom0-x86_64.sh b/automation/=
scripts/xilinx-smoke-dom0-x86_64.sh
> index 8f02fa73bd06..45121f39400a 100755
> --- a/automation/scripts/xilinx-smoke-dom0-x86_64.sh
> +++ b/automation/scripts/xilinx-smoke-dom0-x86_64.sh
> @@ -28,6 +28,8 @@ extra =3D "root=3D/dev/ram0 console=3Dhvc0"
>  memory =3D 512
>  '
>  DOMU_CFG_EXTRA=3D""
> +dom0_rootfs_extra_comp=3D()
> +dom0_rootfs_extra_uncomp=3D()
> =20
>  # Select test variant.
>  if [ "${TEST}" =3D "ping" ]; then
> @@ -71,6 +73,7 @@ do
>    sleep 1
>  done | argo-exec -p 28333 -d 0 -- /bin/echo
>  "
> +    dom0_rootfs_extra_comp+=3D(binaries/argo.cpio.gz)
>      DOM0_CMD=3D"
>  insmod /lib/modules/\$(uname -r)/updates/xen-argo.ko
>  xl -vvv create /etc/xen/domU.cfg
> @@ -103,13 +106,16 @@ find . | cpio -H newc -o | gzip >> ../binaries/domU=
-rootfs.cpio.gz
>  cd ..
>  rm -rf rootfs
> =20
> -# Dom0 rootfs
> -cp binaries/ucode.cpio binaries/dom0-rootfs.cpio.gz
> -cat binaries/rootfs.cpio.gz >> binaries/dom0-rootfs.cpio.gz
> -cat binaries/xen-tools.cpio.gz >> binaries/dom0-rootfs.cpio.gz
> -if [[ "${TEST}" =3D=3D argo ]]; then
> -    cat binaries/argo.cpio.gz >> binaries/dom0-rootfs.cpio.gz
> -fi
> +# Dom0 rootfs.  The order or concatination is important; ucode wants to =
come
> +# first, and all uncompressed must be ahead of compressed.
> +dom0_rootfs_parts=3D(
> +    binaries/ucode.cpio
> +    "${dom0_rootfs_extra_uncomp[@]}"
> +    binaries/rootfs.cpio.gz
> +    binaries/xen-tools.cpio.gz
> +    "${dom0_rootfs_extra_comp[@]}"
> +)
> +cat "${dom0_rootfs_parts[@]}" > binaries/dom0-rootfs.cpio.gz
> =20
>  # test-local configuration
>  mkdir -p rootfs
> --=20
> 2.39.5
>=20

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

--GPtApHH0LFsiAuht
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmg+05IACgkQ24/THMrX
1ywlhAgAgh84yOeeFL195HFesOGNvc44j44m46bUUh8Q/cclE6dBvMTJTQFTgxMk
Yd9nVfsRwaA7IlZkFkA9b1pAAf0eNE4U6AtQ5Tt8MaLtGkiGe0Bre7JsYt+x4JXM
9AegYM8FMYcVWdvc5udkEfccxA0mz8fVYxE7YbVcRX86uyiHnh0l+wcx1MvIARef
sNuEcwc8BrkmBrriAqouxTjoqyLDUHnlC9bVJ/1nw0ihpuIHAtbuXgaJKxSB3sBP
yWD5oiqH/b3Auk1RHcqdihp6flZPSaaoc0Ns7BVwFjWbQGusUAkhmsR/lLx+C3AT
7LwArpck4pFYrulFPattIB7IkYZSGA==
=R0vr
-----END PGP SIGNATURE-----

--GPtApHH0LFsiAuht--


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 10:51:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 10:51:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004219.1383884 (Exim 4.92)
	(envelope-from )
	id 1uMPEr-0005oH-QW; Tue, 03 Jun 2025 10:51:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004219.1383884; Tue, 03 Jun 2025 10:51:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMPEr-0005o7-Mk; Tue, 03 Jun 2025 10:51:25 +0000
Received: by outflank-mailman (input) for mailman id 1004219;
 Tue, 03 Jun 2025 10:51: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 1uMPEq-0005iK-4s
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 10:51:24 +0000
Received: from fhigh-a6-smtp.messagingengine.com
 (fhigh-a6-smtp.messagingengine.com [103.168.172.157])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b02467ee-4068-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 12:51:23 +0200 (CEST)
Received: from phl-compute-06.internal (phl-compute-06.phl.internal
 [10.202.2.46])
 by mailfhigh.phl.internal (Postfix) with ESMTP id 477F711400D8;
 Tue,  3 Jun 2025 06:51:22 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-06.internal (MEProxy); Tue, 03 Jun 2025 06:51:22 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 3 Jun 2025 06:51:21 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b02467ee-4068-11f0-a300-13f23c93f187
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=1748947882;
	 x=1749034282; bh=A7s43Gt3U95U8A+lN2BlegnNS+gkbNUde2mvHC0ZhpU=; b=
	TT7PUxyh1UV/qcFbQFRugdpcSH3nwz0KOWi9d5qACsBfnKLvYZjCBLkXLgL/u/YR
	+jpiMjZLlmhd4eYop4Z+3Buw3cURfHzpUtq2nPkkLSbctvwXV7An8dkeKJzWSU9A
	XCJmX8mZyUH6dkL5rwUtJjn5ckQiPXNSlb1vxrBM3S6gPaZqyfxQEZvQT0qjkPv6
	gJtrufZNpid9dgpmLw8TGUiwY905rij5QgOP4oT48Z7FJ5ZOsVGzGNfV6JdpBUxA
	mriaCVln3L4JtxLxYS5GISaZVWSVxVyPTzQjqdVP+htiitkThtgQur1qeG5rlY3r
	TrRh88Qv54AityQLTOVYBg==
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=
	1748947882; x=1749034282; bh=A7s43Gt3U95U8A+lN2BlegnNS+gkbNUde2m
	vHC0ZhpU=; b=ovNTfvDg5PL/s7riHwCIKJHjJs+nxF1LSbAjoSp/4jsA3bvqYJV
	k29LuMznmQTU3lrIX7kY95776hdYKps6M38E96eMZGe7UbAvfpdOnCQKWvNDWNsq
	iZwXU3gamvtAVL4N3Yu/qB6glnSLoy7dsYpgCbZmc7y+0nwGOM3pcXSI7iWYsLoQ
	b9Acw4SDQKWv/HGg3qRtqXtqiO+bVeRkuCqLcJ0VbNQuH3tx9rKvqBXGeOy/F2Lo
	3JwygzzozRdKKVMPUf/HSgqMATZoXc5yurTOzpqr5yOz06TGH7sxRMjOc/6EHKef
	+hcjPFihNmigvQrUnHfNU/0DdhxhHxwnbTA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugddtgecutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr
    tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnth
    hsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecu
    hfhrohhmpeforghrvghkucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrg
    hrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffr
    rghtthgvrhhnpefgudelteefvefhfeehieetleeihfejhfeludevteetkeevtedtvdegue
    etfeejudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm
    pehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsg
    gprhgtphhtthhopeehpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegrnhgurhgv
    fidrtghoohhpvghrfeestghithhrihigrdgtohhmpdhrtghpthhtohepgigvnhdquggvvh
    gvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtoheprghnthhh
    ohhnhidrphgvrhgrrhgusehvrghtvghsrdhtvggthhdprhgtphhtthhopehsshhtrggsvg
    hllhhinhhisehkvghrnhgvlhdrohhrghdprhgtphhtthhopehmihgthhgrlhdrohhriigv
    lhesrghmugdrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Tue, 3 Jun 2025 12:51:19 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Andrew Cooper 
Cc: Xen-devel ,
	Anthony PERARD ,
	Stefano Stabellini ,
	Michal Orzel 
Subject: Re: [PATCH 2/2] CI: Adjust how domU is packaged in dom0
Message-ID: 
References: <20250602174618.2641439-1-andrew.cooper3@citrix.com>
 <20250602174618.2641439-3-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="4TOChwVca9ELR8ro"
Content-Disposition: inline
In-Reply-To: <20250602174618.2641439-3-andrew.cooper3@citrix.com>


--4TOChwVca9ELR8ro
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 3 Jun 2025 12:51:19 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Andrew Cooper 
Cc: Xen-devel ,
	Anthony PERARD ,
	Stefano Stabellini ,
	Michal Orzel 
Subject: Re: [PATCH 2/2] CI: Adjust how domU is packaged in dom0

On Mon, Jun 02, 2025 at 06:46:18PM +0100, Andrew Cooper wrote:
> Package domU for dom0 and insert into the uncompressed part of dom0's roo=
tfs,
> rather than recompressing it as part of the overlay.
>=20
> For Qubes, this avoids putting the domU kernel in dom0's rootfs for tests
> which aren't going to boot a guest.
>=20
> Signed-off-by: Andrew Cooper 

Reviewed-by: Marek Marczykowski-G=C3=B3recki 

> ---
> CC: Anthony PERARD 
> CC: Stefano Stabellini 
> CC: Michal Orzel 
> CC: Marek Marczykowski-G=C3=B3recki 
>=20
> v2:
>  * Rebase over dom0_rootfs_extra_{un,}comp changes
>  * Move back into boot.  There seem to be objections to having it in root.
> ---
>  automation/scripts/qubes-x86-64.sh             | 17 ++++++++++++-----
>  automation/scripts/xilinx-smoke-dom0-x86_64.sh | 14 +++++++++++---
>  2 files changed, 23 insertions(+), 8 deletions(-)
>=20
> diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qube=
s-x86-64.sh
> index 5ec6eff6c469..d9ecc569c956 100755
> --- a/automation/scripts/qubes-x86-64.sh
> +++ b/automation/scripts/qubes-x86-64.sh
> @@ -156,7 +156,7 @@ esac
>  domU_config=3D"
>  type =3D '${domU_type}'
>  name =3D 'domU'
> -kernel =3D '/boot/vmlinuz'
> +kernel =3D '/boot/vmlinuz-domU'
>  ramdisk =3D '/boot/initrd-domU'
>  cmdline =3D 'root=3D/dev/ram0 console=3Dhvc0'
>  memory =3D 512
> @@ -187,6 +187,17 @@ Kernel \r on an \m (\l)
>      find . | cpio -H newc -o | gzip >> ../binaries/domU-rootfs.cpio.gz
>      cd ..
>      rm -rf rootfs
> +
> +    # Package domU kernel+rootfs in /boot for dom0 (uncompressed)
> +    mkdir -p rootfs/boot
> +    cd rootfs
> +    cp ../binaries/bzImage boot/vmlinuz-domU
> +    cp ../binaries/domU-rootfs.cpio.gz boot/initrd-domU
> +    find . | cpio -H newc -o > ../binaries/domU-in-dom0.cpio
> +    cd ..
> +    rm -rf rootfs
> +
> +    dom0_rootfs_extra_uncomp+=3D(binaries/domU-in-dom0.cpio)
>  fi
> =20
>  # Dom0 rootfs.  The order or concatination is important; ucode wants to =
come
> @@ -241,10 +252,6 @@ mkdir -p etc/default
>  echo "XENCONSOLED_TRACE=3Dall" >> etc/default/xencommons
>  echo "QEMU_XEN=3D/bin/false" >> etc/default/xencommons
>  mkdir -p var/log/xen/console
> -cp ../binaries/bzImage boot/vmlinuz
> -if [ -n "$domU_check" ]; then
> -    cp ../binaries/domU-rootfs.cpio.gz boot/initrd-domU
> -fi
>  find . | cpio -H newc -o | gzip >> ../binaries/dom0-rootfs.cpio.gz
>  cd ..
> =20
> diff --git a/automation/scripts/xilinx-smoke-dom0-x86_64.sh b/automation/=
scripts/xilinx-smoke-dom0-x86_64.sh
> index 45121f39400a..8981aee5d4f2 100755
> --- a/automation/scripts/xilinx-smoke-dom0-x86_64.sh
> +++ b/automation/scripts/xilinx-smoke-dom0-x86_64.sh
> @@ -22,7 +22,7 @@ DOMU_CMD=3D""
>  DOMU_CFG=3D'
>  type =3D "pvh"
>  name =3D "domU"
> -kernel =3D "/boot/vmlinuz"
> +kernel =3D "/boot/vmlinuz-domU"
>  ramdisk =3D "/boot/initrd-domU"
>  extra =3D "root=3D/dev/ram0 console=3Dhvc0"
>  memory =3D 512
> @@ -106,10 +106,20 @@ find . | cpio -H newc -o | gzip >> ../binaries/domU=
-rootfs.cpio.gz
>  cd ..
>  rm -rf rootfs
> =20
> +# Package domU kernel+rootfs in /boot for dom0 (uncompressed)
> +mkdir -p rootfs/boot
> +cd rootfs
> +cp ../binaries/bzImage boot/vmlinuz-domU
> +cp ../binaries/domU-rootfs.cpio.gz boot/initrd-domU
> +find . | cpio -H newc -o > ../binaries/domU-in-dom0.cpio
> +cd ..
> +rm -rf rootfs
> +
>  # Dom0 rootfs.  The order or concatination is important; ucode wants to =
come
>  # first, and all uncompressed must be ahead of compressed.
>  dom0_rootfs_parts=3D(
>      binaries/ucode.cpio
> +    binaries/domU-in-dom0.cpio
>      "${dom0_rootfs_extra_uncomp[@]}"
>      binaries/rootfs.cpio.gz
>      binaries/xen-tools.cpio.gz
> @@ -131,8 +141,6 @@ echo "${DOMU_CFG}${DOMU_CFG_EXTRA}" > etc/xen/domU.cfg
>  echo "XENCONSOLED_TRACE=3Dall" >> etc/default/xencommons
>  echo "QEMU_XEN=3D/bin/false" >> etc/default/xencommons
>  mkdir -p var/log/xen/console
> -cp ../binaries/bzImage boot/vmlinuz
> -cp ../binaries/domU-rootfs.cpio.gz boot/initrd-domU
>  find . | cpio -H newc -o | gzip >> ../binaries/dom0-rootfs.cpio.gz
>  cd ..
> =20
> --=20
> 2.39.5
>=20

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

--4TOChwVca9ELR8ro
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmg+06cACgkQ24/THMrX
1yzVqgf/QPy6lxz0dQ51KPTS4zJN2eRvoN6eY6Fb0qsWcE+4eC71+CADAoUSVbq+
kOUdq+AzRdMYXXXbkJj/3uHA7QWAvEOLsCBtn8CSoVtpL6K1F9frPBNzQLmyHE4L
j8uUJpWsuqkmwUw6vbfcL5SE8dEBxGyYZzZOMh6ec2ifr6qO3LdAlKDLHt6Z/8lt
HI2wVFu0HusNhIOzIit3FKQ5nQ6ausaEoK1XB4RsTsGi5uHyMIp1m8nKIoz3WKTN
Y1hskMnDOnU6G73sOhXMBMtgoMMMn/ZgPWm43FRT/POxQ9n8S0RxihEz+ndX+OyO
ZmGfZYwRzt6yhx5u2mPeC8QdOKHF0w==
=S/49
-----END PGP SIGNATURE-----

--4TOChwVca9ELR8ro--


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 10:55:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 10:55:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004231.1383893 (Exim 4.92)
	(envelope-from )
	id 1uMPJ9-0006Uk-9j; Tue, 03 Jun 2025 10:55:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004231.1383893; Tue, 03 Jun 2025 10:55:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMPJ9-0006Ud-79; Tue, 03 Jun 2025 10:55:51 +0000
Received: by outflank-mailman (input) for mailman id 1004231;
 Tue, 03 Jun 2025 10:55: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 1uMPJ8-0006UW-0T
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 10:55:50 +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 4748924e-4069-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 12:55:36 +0200 (CEST)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-4508287895dso37381355e9.1
 for ; Tue, 03 Jun 2025 03:55:36 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23506be97e5sm85171895ad.103.2025.06.03.03.55.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 03 Jun 2025 03:55:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4748924e-4069-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1748948135; x=1749552935; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=1tH0v/HEdC9WlxoFyWazLONSPy2Y2UaEV2FxRI6+Bsk=;
        b=A8aSWHa7JckLJD0MQq0+KLNVMxuD5oV65IlabjxZCnJqT003xVcvjk47BalOWzb2v0
         yPbGLC4L2EKxgLEVEmeyxz8vv0YCmy1sXFPuffKB4d/BmF0L9zy5NxqhTd2tTO1Aj9ze
         nut8abmb4axSeoJgqRdha6m9vDnGS4cfkNqEuL1ViqfQ+Uh0UrrlS5FHssnrPmwSUN74
         rJBEcsRHeux5OCsHxetoj1ZjOgtB74/JplQM+/z7ANJdx1qNsVXZnbxx5jnjXuNKKZLk
         K5CcjjdZsDVS0nDa9xXC18ztXw7lnGkcav96/Hxjlf1BDs7GH8CbNBq/cHqBnyZaqfZM
         N+0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748948135; x=1749552935;
        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=1tH0v/HEdC9WlxoFyWazLONSPy2Y2UaEV2FxRI6+Bsk=;
        b=rU2Rib191lng/LWyTrBBCWLG2RQ6p2pXlxfUiTjoGQCpopJdlGMZY95JwwnQdeFfjF
         d71JD/aDtCrt3+aLUOFTYVE4Q9n+5t/a1GmEL+DHBTEbZ0lYj0QT4ECZRohZR9G3j4Gn
         IJYPfeBSbPgQoNSkC4xLkayXhaznbPjRHypDQtSlfIwlpI+ARzqcNfunr6LS7PAQDQCd
         /Kg/4zm9Qdp+EJXgTyKaDh3joPfTzxTIcuqrp6e5Ovs3FnJxHIhEEb/DwNzBiYKxICCe
         //DYDcYNC8TcNgc5fE/cDNKc+fNAv85ENBct9r1ecdBcr8VlI5ILsBM64Sng5Io7oP/z
         3gbg==
X-Forwarded-Encrypted: i=1; AJvYcCVHzL+Kc4XvDybsLINZS/eQ2vpECkxqEMw4JsIDIeFHqS+v5BRB98TO/Rup0E1UZHf+9IYJxmICZwU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzwM+z+xwQG7+TKlgK3i+iWcRPc80pfa9w9IhRf+KqcdaCWQj5y
	jxKUvUghldCNY+GSTCoqYkAMp/AYdNbg4e6IhT3vK7XX1AqtkT2ILEZLww4OSZu7VA==
X-Gm-Gg: ASbGnctsdp3JRV+bqok9vpM4imEu87yC62PDpWS452ihSz9UyBdfirCweDUqPsKNSUn
	Jb8hdMWzjWn2caPGRUK6tkzcybRukG3wSdhY+F0BcE4KIeHUnTMoLoD4YkkpczTrLUyg43fEBGC
	0meSbuVlZ6Plj4sr9/GRyLx2hhBUpl6faAth1HNwvIEVgNecbc8NjBsLjHNmJyCmH1GBIrajaaV
	JEKzsSsHvg0t04J8amdCeH4I6EtikN4bbbSB2tvL/0MHPMPOKbtBPq9ArlA08P81EEQdc7073oc
	Jtunyz/TxdfOEdBAKwWMZjcIoPdznRkp2fzKTcOZqsTTKDOtbYISjpdOUdhMMy+R8bM1VxpVDzl
	BtHulMMP93B2RgHpXQmGeItGtSERGKr/8LujO
X-Google-Smtp-Source: AGHT+IH4cOq0txEFv0mpCPLHW/uCS3ETLMRUw6O230Gg6ZwBtcIghw0IcqdSAyF9hWWM4nmPEyKCAg==
X-Received: by 2002:a05:6000:3108:b0:3a4:d685:3de7 with SMTP id ffacd0b85a97d-3a51417af94mr1649306f8f.8.1748948135568;
        Tue, 03 Jun 2025 03:55:35 -0700 (PDT)
Message-ID: 
Date: Tue, 3 Jun 2025 12:55:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/4] common: Drop unneeded Arm dependency for
 static-evtchn
To: Michal Orzel 
Cc: Andrew Cooper ,
 Anthony PERARD , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250603100329.149851-1-michal.orzel@amd.com>
 <20250603100329.149851-2-michal.orzel@amd.com>
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20250603100329.149851-2-michal.orzel@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 03.06.2025 12:03, Michal Orzel wrote:
> DOM0LESS_BOOT is sufficient (only Arm selects it today). If needed,
> proper arch dependency can be introduced while adding support for it for
> another architecture.
> 
> Suggested-by: Jan Beulich 
> Signed-off-by: Michal Orzel 

Acked-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 11:18:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 11:18:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004240.1383903 (Exim 4.92)
	(envelope-from )
	id 1uMPez-0001WV-0L; Tue, 03 Jun 2025 11:18:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004240.1383903; Tue, 03 Jun 2025 11:18: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 1uMPey-0001WO-Tc; Tue, 03 Jun 2025 11:18:24 +0000
Received: by outflank-mailman (input) for mailman id 1004240;
 Tue, 03 Jun 2025 11:18: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 1uMPex-0001WI-4A
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 11:18:23 +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 6f39818b-406c-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 13:18:11 +0200 (CEST)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-441d437cfaaso37203825e9.1
 for ; Tue, 03 Jun 2025 04:18:11 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-450d80136ffsm166387755e9.40.2025.06.03.04.18.10
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 03 Jun 2025 04:18:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6f39818b-406c-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748949491; x=1749554291; 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=xWq37xjSwePxYoSA81gemrxTTNQmdt2lE+wYljjUo3o=;
        b=WVR86XAhlhOo1huE2W4OLQvdO+4vTXhxXVHktOlgRfbhxdH4Fu6wZWHdhq1Xa2X7UJ
         U/qnMXhe+MkqpN9XbV/JyleZK/TRwsfhwGWztt+WJvFN+FpaYys3+3MwJG7DUDA31nJk
         BtFByYki/A4KVWSsI1d1ykP/nBCkFLNTH9KAw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748949491; x=1749554291;
        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=xWq37xjSwePxYoSA81gemrxTTNQmdt2lE+wYljjUo3o=;
        b=vdyITA6YpMBWmT0ZKyP6OPgX7KKC0ANpdUaCqnoxU245Osojy/KXUt9gqRVllCgVU4
         NZ00DRksEJJGIgZ1aWrfW9zaI8UH8z7liR5LmyoBxvqQkuYAA/AN53nYXe6WnJ+qZAdI
         QZ+1SeWSC4sXlP3nBq0lhWPiy0FCyYb1F5aBzWeCWBzlU4pJ4vnnDymU5s5CfoSxGh6N
         h4CPfVfvfDwRah2m8VWwFfXnIgyH10u03yygB+r9vpb/geYmyfitbv4QBdTjOmqve1yX
         1WJ6CzFltvYG5vYScVUPU09kWIa9y+EBgA/yB64tbY2FbmA3OlXFyevTl1U4Lq9UALxq
         54mA==
X-Gm-Message-State: AOJu0YyYC22IrOHOrB35YFdvgpORQofuVRVTVtipA2mtWH98sI/8mzsf
	ZpuuTHsdrgG/wltqs/Lbxs/ndnyMOBEgokAnbAAgcnhOIhiahNZYYNRMQGpgKOgsCRRji+6LaS2
	zx9v0
X-Gm-Gg: ASbGnctwShDxgp3NEfRWtLKEDpqIYUdaI9fJrh7zLhH1783soKnjBeLvuC5YaKv/tj1
	UlsT6IoW/NlUkA7vc3eSe7SprKM7Dl0kTWKMgLFGO9sT6CM762r03HBFud5NNNYUJUmWCnqQLGX
	RkqWpDY+WPXhgx+10xpPGEdnCd3jF/0qHv72cuN3hLCpih4c2kV8ZdvsN59lwBnh3ZO/7bT6P7Z
	Qve9RG7zybsz7XPWYBxj8GnhYO46fFw/Zyml+1CrUJL0tl9dX5xo3XoFsZwmjUcX1IBYy2OMHF+
	zw/vkkc0Oh6aLooE8VabqeBd/eMg+ouA945dsXZhor5T/mK7MOB9rbywyJHBkYuDzP2Y506uWRS
	nborbSGzWoaKEWXiloMD3KH0m
X-Google-Smtp-Source: AGHT+IEXRvJ6Quw6aNHy9QRBSN/QpwsOr6syul//b1qFPBB1qNnBdZzidAE4nUnbfBW/PK+v0Sah7A==
X-Received: by 2002:a05:600c:3593:b0:43c:f3e4:d6f6 with SMTP id 5b1f17b1804b1-450d887f958mr162799765e9.31.1748949490641;
        Tue, 03 Jun 2025 04:18:10 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Anthony PERARD ,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Juergen Gross ,
	Anthoine Bourgeois 
Subject: [PATCH v2] x86/hvmloader: select xenpci MMIO BAR UC or WB MTRR cache attribute
Date: Tue,  3 Jun 2025 13:18:06 +0200
Message-ID: <20250603111806.86555-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The Xen PCI device (vendor ID 0x5853) exposed to x86 HVM guests doesn't
have the functionality of a traditional PCI device.  The exposed MIO BAR is
used by some guests (including Linux) as a safe place to map foreign
memory, including the grant table itself.

Traditionally BARs from devices have the uncacheable (UC) cache attribute
from the MTRR, to ensure correct functionality of such devices.  hvmloader
mimics this behavior and sets the MTRR attributes of both the low and high
PCI MMIO windows (where BARs of PCI devices reside) as UC in MTRR.

This however causes performance issues for users of the Xen PCI device BAR,
as for the purposes of mapping remote memory there's no need to use the UC
attribute.  On Intel systems this is worked around by using iPAT, that
allows the hypervisor to force the effective cache attribute of a p2m entry
regardless of the guest PAT value.  AMD however doesn't have an equivalent
of iPAT, and guest PAT values are always considered.

Linux commit:

41925b105e34 xen: replace xen_remap() with memremap()

Attempted to mitigate this by forcing mappings of the grant-table to use
the write-back (WB) cache attribute.  However Linux memremap() takes MTRRs
into account to calculate which PAT type to use, and seeing the MTRR cache
attribute for the region being UC the PAT also ends up as UC, regardless of
the caller having requested WB.

As a workaround to allow current Linux to map the grant-table as WB using
memremap() introduce an xl.cfg option (xenpci_bar_uc=0) that can be used to
select whether the Xen PCI device BAR will have the UC attribute in MTRR.
Such workaround in hvmloader should also be paired with a fix for Linux so
it attempts to change the MTRR of the Xen PCI device BAR to WB by itself.

Overall, the long term solution would be to provide the guest with a safe
range in the guest physical address space where mappings to foreign pages
can be created.

Some vif throughput performance figures provided by Anthoine from a 8
vCPUs, 4GB of RAM HVM guest(s) running on AMD hardware:

Without this patch:
vm -> dom0: 1.1Gb/s
vm -> vm:   5.0Gb/s

With the patch:
vm -> dom0: 4.5Gb/s
vm -> vm:   7.0Gb/s

Reported-by: Anthoine Bourgeois 
Signed-off-by: Roger Pau Monné 
---
Changes since v1:
 - Leave the xenpci BAR as UC by default.
 - Introduce an option to not set it as UC.
---
 docs/man/xl.cfg.5.pod.in                |  6 +++
 tools/firmware/hvmloader/config.h       |  2 +-
 tools/firmware/hvmloader/pci.c          | 49 ++++++++++++++++++++++++-
 tools/firmware/hvmloader/util.c         |  2 +-
 tools/include/libxl.h                   |  9 +++++
 tools/libs/light/libxl_create.c         |  1 +
 tools/libs/light/libxl_dom.c            |  9 +++++
 tools/libs/light/libxl_types.idl        |  1 +
 tools/xl/xl_parse.c                     |  2 +
 xen/include/public/hvm/hvm_xs_strings.h |  2 +
 10 files changed, 79 insertions(+), 4 deletions(-)

diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index c388899306c2..e540d8169424 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -2351,6 +2351,12 @@ Windows L.
 Setting B with the default device_model "qemu-xen"
 requires at least QEMU 1.6.
 
+
+=item B
+
+B Select whether the memory BAR of the Xen PCI device should have
+uncacheable (UC) cache attribute set in MTRR.
+
 =item B or B
 
 The groups of Microsoft Hyper-V (AKA viridian) compatible enlightenments
diff --git a/tools/firmware/hvmloader/config.h b/tools/firmware/hvmloader/config.h
index 6e1da137d779..c159db30eea9 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -58,7 +58,7 @@ extern uint32_t *cpu_to_apicid;
 #define ACPI_TIS_HDR_ADDRESS 0xFED40F00UL
 
 extern uint32_t pci_mem_start;
-extern const uint32_t pci_mem_end;
+extern uint32_t pci_mem_end;
 extern uint64_t pci_hi_mem_start, pci_hi_mem_end;
 
 extern bool acpi_enabled;
diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index cc67b18c0361..97933b44a82b 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -30,7 +30,7 @@
 #include 
 
 uint32_t pci_mem_start = HVM_BELOW_4G_MMIO_START;
-const uint32_t pci_mem_end = RESERVED_MEMBASE;
+uint32_t pci_mem_end = RESERVED_MEMBASE;
 uint64_t pci_hi_mem_start = 0, pci_hi_mem_end = 0;
 
 /*
@@ -116,6 +116,8 @@ void pci_setup(void)
      * experience the memory relocation bug described below.
      */
     bool allow_memory_relocate = 1;
+    /* Set the MTRR type of the xenpci device BAR as UC. */
+    bool xenpci_bar_uc = false;
 
     BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_IO !=
                  PCI_COMMAND_IO);
@@ -130,6 +132,12 @@ void pci_setup(void)
     printf("Relocating guest memory for lowmem MMIO space %s\n",
            allow_memory_relocate?"enabled":"disabled");
 
+    s = xenstore_read(HVM_XS_XENPCI_BAR_UC, NULL);
+    if ( s )
+        xenpci_bar_uc = strtoll(s, NULL, 0);
+    printf("XenPCI device BAR MTRR cache attribute set to %s\n",
+           xenpci_bar_uc ? "UC" : "WB");
+
     s = xenstore_read("platform/mmio_hole_size", NULL);
     if ( s )
         mmio_hole_size = strtoll(s, NULL, 0);
@@ -271,6 +279,43 @@ void pci_setup(void)
             if ( bar_sz == 0 )
                 continue;
 
+            if ( !xenpci_bar_uc &&
+                 ((bar_data & PCI_BASE_ADDRESS_SPACE) ==
+                   PCI_BASE_ADDRESS_SPACE_MEMORY) &&
+                 vendor_id == 0x5853 &&
+                 (device_id == 0x0001 || device_id == 0x0002) )
+            {
+                if ( is_64bar )
+                {
+                     printf("xenpci dev %02x:%x unexpected MMIO 64bit BAR%u\n",
+                            devfn >> 3, devfn & 7, bar);
+                     continue;
+                }
+
+                if ( bar_sz > pci_mem_end ||
+                     ((pci_mem_end - bar_sz) & ~(bar_sz - 1)) < pci_mem_start )
+                {
+                     printf("xenpci dev %02x:%x BAR%u size %llx overflows low PCI hole\n",
+                            devfn >> 3, devfn & 7, bar, bar_sz);
+                     continue;
+                }
+
+                /* Put unconditionally at the end of the low PCI MMIO hole. */
+                pci_mem_end -= bar_sz;
+                pci_mem_end &= ~(bar_sz - 1);
+                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
+                bar_data |= pci_mem_end;
+                pci_writel(devfn, bar_reg, bar_data);
+                pci_devfn_decode_type[devfn] |= PCI_COMMAND_MEMORY;
+
+                /* Prefix BAR address with a 0 to match format used below. */
+                printf("pci dev %02x:%x bar %02x size "PRIllx": 0%08x\n",
+                       devfn >> 3, devfn & 7, bar_reg,
+                       PRIllx_arg(bar_sz), bar_data);
+
+                continue;
+            }
+
             for ( i = 0; i < nr_bars; i++ )
                 if ( bars[i].bar_sz < bar_sz )
                     break;
@@ -310,7 +355,7 @@ void pci_setup(void)
         }
 
         /* Enable bus master for this function later */
-        pci_devfn_decode_type[devfn] = PCI_COMMAND_MASTER;
+        pci_devfn_decode_type[devfn] |= PCI_COMMAND_MASTER;
     }
 
     if ( mmio_hole_size )
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 79c0e6bd4ad2..31b4411db7b4 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -867,7 +867,7 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
         config->table_flags |= ACPI_HAS_HPET;
 
     config->pci_start = pci_mem_start;
-    config->pci_len = pci_mem_end - pci_mem_start;
+    config->pci_len = RESERVED_MEMBASE - pci_mem_start;
     if ( pci_hi_mem_end > pci_hi_mem_start )
     {
         config->pci_hi_start = pci_hi_mem_start;
diff --git a/tools/include/libxl.h b/tools/include/libxl.h
index b7ad7735ca4c..7ce7678e6836 100644
--- a/tools/include/libxl.h
+++ b/tools/include/libxl.h
@@ -1503,6 +1503,15 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst, const libxl_mac *src);
  */
 #define LIBXL_HAVE_CREATEINFO_XEND_SUSPEND_EVTCHN_COMPAT
 
+/*
+ * LIBXL_HAVE_XENPCI_BAR_UC
+ *
+ * libxl_domain_build_info contains a boolean 'u.hvm.xenpci_bar_uc' field to
+ * signal whether the XenPCI device BAR should have UC cache attribute set in
+ * MTRR.
+ */
+#define LIBXL_HAVE_XENPCI_BAR_UC
+
 typedef char **libxl_string_list;
 void libxl_string_list_dispose(libxl_string_list *sl);
 int libxl_string_list_length(const libxl_string_list *sl);
diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_create.c
index 8bc768b5156c..962fa820faec 100644
--- a/tools/libs/light/libxl_create.c
+++ b/tools/libs/light/libxl_create.c
@@ -313,6 +313,7 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
         libxl_defbool_setdefault(&b_info->u.hvm.usb,                false);
         libxl_defbool_setdefault(&b_info->u.hvm.vkb_device,         true);
         libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci,   true);
+        libxl_defbool_setdefault(&b_info->u.hvm.xenpci_bar_uc,      true);
         libxl_defbool_setdefault(&b_info->u.hvm.pirq,               false);
 
         libxl_defbool_setdefault(&b_info->u.hvm.spice.enable, false);
diff --git a/tools/libs/light/libxl_dom.c b/tools/libs/light/libxl_dom.c
index 4d67b0d28294..60ec0354d19a 100644
--- a/tools/libs/light/libxl_dom.c
+++ b/tools/libs/light/libxl_dom.c
@@ -819,6 +819,15 @@ static int hvm_build_set_xs_values(libxl__gc *gc,
             goto err;
     }
 
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM &&
+        libxl_defbool_val(info->u.hvm.xenpci_bar_uc)) {
+        path = GCSPRINTF("/local/domain/%d/"HVM_XS_XENPCI_BAR_UC, domid);
+        ret = libxl__xs_printf(gc, XBT_NULL, path, "%d",
+                               libxl_defbool_val(info->u.hvm.xenpci_bar_uc));
+        if (ret)
+            goto err;
+    }
+
     return 0;
 
 err:
diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl
index 198515383012..6054350b83c7 100644
--- a/tools/libs/light/libxl_types.idl
+++ b/tools/libs/light/libxl_types.idl
@@ -691,6 +691,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
                                        ("vkb_device",       libxl_defbool),
                                        ("soundhw",          string),
                                        ("xen_platform_pci", libxl_defbool),
+                                       ("xenpci_bar_uc",    libxl_defbool),
                                        ("usbdevice_list",   libxl_string_list),
                                        ("vendor_device",    libxl_vendor_device),
                                        # See libxl_ms_vm_genid_generate()
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index 219e924779ff..4da3bb9e91ab 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -2917,6 +2917,8 @@ skip_usbdev:
         xlu_cfg_replace_string (config, "soundhw", &b_info->u.hvm.soundhw, 0);
         xlu_cfg_get_defbool(config, "xen_platform_pci",
                             &b_info->u.hvm.xen_platform_pci, 0);
+        xlu_cfg_get_defbool(config, "xenpci_bar_uc",
+                            &b_info->u.hvm.xenpci_bar_uc, 0);
 
         if(b_info->u.hvm.vnc.listen
            && b_info->u.hvm.vnc.display
diff --git a/xen/include/public/hvm/hvm_xs_strings.h b/xen/include/public/hvm/hvm_xs_strings.h
index e1ed078628a0..ebb07b9fba56 100644
--- a/xen/include/public/hvm/hvm_xs_strings.h
+++ b/xen/include/public/hvm/hvm_xs_strings.h
@@ -14,6 +14,8 @@
 #define HVM_XS_BIOS                    "hvmloader/bios"
 #define HVM_XS_GENERATION_ID_ADDRESS   "hvmloader/generation-id-address"
 #define HVM_XS_ALLOW_MEMORY_RELOCATE   "hvmloader/allow-memory-relocate"
+/* Set xenpci device BAR as UC in MTRR */
+#define HVM_XS_XENPCI_BAR_UC           "hvmloader/pci/xenpci-bar-uc"
 
 /* The following values allow additional ACPI tables to be added to the
  * virtual ACPI BIOS that hvmloader constructs. The values specify the guest
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 11:23:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 11:23:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004254.1383926 (Exim 4.92)
	(envelope-from )
	id 1uMPji-0003P0-OO; Tue, 03 Jun 2025 11:23:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004254.1383926; Tue, 03 Jun 2025 11:23: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 1uMPji-0003Ot-Lh; Tue, 03 Jun 2025 11:23:18 +0000
Received: by outflank-mailman (input) for mailman id 1004254;
 Tue, 03 Jun 2025 11:23: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 1uMPjh-0003Ok-O9
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 11:23:17 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20631.outbound.protection.outlook.com
 [2a01:111:f403:200a::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2403c435-406d-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 13:23:15 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by CH0PR12MB8461.namprd12.prod.outlook.com (2603:10b6:610:183::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Tue, 3 Jun
 2025 11:23:11 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8792.034; Tue, 3 Jun 2025
 11:23: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: 2403c435-406d-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=o84j+i3pKNPmrfXT+YALSaqDIWtWCMj6RrQXwuObUBp6+XVbEV2cWeMCsmEcefZFJZvbCQkUr5oECtGh4BuAwB+KSqoT12DC6Rz72p1pi33eajZZ6HBHsCCYGVzLqYiowRJeDb1vIt0JBoeeEVsEm1uRj2CCAHPe6gJPphTI0qzgOFRPXrOkZ5H/4FJdZSDWG0YwKTKbZsdNjQ1TU7TECDSStghzEcSX6dcsOhV3DXGaVsfbD2PhCrZ0MsQknIjXh6OTNC51euim1y6/QP5FKnI3q+T9sTlm5BNVgeWwaqccvmWcOaS0FDh4ZvDQzAtaUKVT5rfSbjbJ/wHSiXo8aw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=FG+Z8Mhu8hlN7FD6BVQCjltYY7rSLo65HFJ9aJ8JZec=;
 b=EHA4mwWf0V4Rg+vrAljR/3aP6NcVXVCoH8wo1A3zW5TDEhauQilZNaOVF6uVxpvi1FjshQX9blDFosuZNdzZeipEpyaRtjcXZJCeZG8hZKrFOcoMdnm7sTBlJKB61Q0PeGYtX/APzDFl67jXb0Agvv8Cu12eAiQ40ko4BPzyYkTTjgZiEqWX6GWptrJx8LCEwoI1TT6LpyNUdRBIXj7NXAxvLoMcXHVlH57j51gOSeHVtcbe1/xm4DnwOTKJz9fShah0sLz5KVcuxcB+JTi5XtdBLg2Ek89fPug4h9ZRPVedrrWtJvpnfU9D2xhz4x1M0pQMPzatPuuknT2bN6I5wQ==
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=FG+Z8Mhu8hlN7FD6BVQCjltYY7rSLo65HFJ9aJ8JZec=;
 b=Wgw58oFkIt7djzsJTb8EZgSM6wBEWRBJfeJyG+G/1Y8VGK8ZEgflGHrZeybYTxFk6VpwC0s1qk0BYmWzYzIU+GUcqbIhS7JWpDuNnrChZLyVLiSDc69Awo0UBqCqNR16Q76gNE/CrwySal9d8+SSsxroiEtX3N5ozQhmb+ywi3s=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <5448a0af-0bff-4bfc-ba76-34beb5546dc7@amd.com>
Date: Tue, 3 Jun 2025 13:23:07 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] tests/vpci: Use $(CC) instead of $(HOSTCC)
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: xen-devel@lists.xenproject.org, Anthony PERARD 
References: <20250602150929.10679-1-michal.orzel@amd.com>
 
 <6438a00b-a0fe-419d-b57e-5e1af48d43ce@amd.com>
 
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: FR4P281CA0078.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:cd::7) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|CH0PR12MB8461:EE_
X-MS-Office365-Filtering-Correlation-Id: 36dda7f8-0df5-41c3-a487-08dda29105ae
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?eTVPQytWYyt0aXI5SE5mM1NycE9TcGhkeDJrYUkyUFZXQkI2d1MzWkZMYkEx?=
 =?utf-8?B?Y2tDc1F6QWs5R0FRZmtjYmduOFpMa2g1NzREODY3ay9WMko0RWZET3NLczZw?=
 =?utf-8?B?T05zNFViNGJqUWR1VVkveXd6elBCeVlLZFc2VGR1cE9WK3F0MFBTUVRLN1Ev?=
 =?utf-8?B?L2NnbWFkYkRvblpGc3lvUFAxZGVyRlpPVjdvbEd3bmxuZ000VzJlelFHSXNX?=
 =?utf-8?B?aFVNVkMwanZOVkMzNVRvSXlKNzFMNjQwQTJudW5YOWRscURkZjR5djdVTGFr?=
 =?utf-8?B?WjFnbmR1Q1FwNGI2Sm9udktkdm5GT2cyNXNsTnZqRzVJRFZZTHZ2dnZSbTFJ?=
 =?utf-8?B?QlZFb0hZN3NsTVplZ1owRjJYckFzRmdNcWp3MHBEU0IveXJJcXBMU1ZObkhP?=
 =?utf-8?B?RVIwNTBpU2U0eWFDME1HV0wxczYrRmF3TkNCYVhLdlZOTzJRcng5dU85U09K?=
 =?utf-8?B?VnBkNnFlQXUrQ2Fua3lSTGtBUjB2YjNVZGJaWnhnbWtZcTRiWXo2eHg0ZjBU?=
 =?utf-8?B?dDQ5bEZFZkZTTGZlWStocmxYdzRLb0dWdHRpUjVZTkRkWXVsN2lPWmdoVjZo?=
 =?utf-8?B?SXhHVnZMYkJGbFFmOTN1cU1pOW1pQk94OWcvOHVtNmhtTlhaclE5ZGhOWmlU?=
 =?utf-8?B?WXZkTTZPTFNPSW16T3NEOEt4OFRPMWJrSkZTWFBMV3I0RUpteGVzSk9uWm5t?=
 =?utf-8?B?WnY5REJPUVJiZWE1V0psYVB0R1JUb215ZXlrdFVmRFJjR0ZUbkFGeXFsWVA2?=
 =?utf-8?B?R3ZuQXpwRnlIbmhjT0dtbmdtZStNYW5nVkVEY3kvcVN1STVkWXZ6VTdwN3Rv?=
 =?utf-8?B?dHV0ZzV2UHhHbklBS1VGNVFaM1lsaUpQa0FJbS9XTERIemg1dVF1MjBjMmk0?=
 =?utf-8?B?eEpZMTNmNExEYnA0dFNZODhrRTlwZlFST0FOZFMzSW9jODlSclZnbWxGOUVz?=
 =?utf-8?B?M2VyTVQyMUh4cUVtSWJmTCtXcG9rMVB4akZTSE0rN1lvZldESXh5djVjSURk?=
 =?utf-8?B?TFdhdHdiWlprQ3dzU1F3bGxXLzdWTXM2SVFadkJVK1pEekVZeUlnaFZkcnpD?=
 =?utf-8?B?bzVLVmNReHcvb01NL2JRVVFTYzVFcnExM0lGVU8rV1FGMXlidlRzRnZUeVNt?=
 =?utf-8?B?MGVxZkFQWWZ5d3RBcmhxbzJGMU0rNnZwZ1RFejVadGdGU0FNMG5vcForTWFS?=
 =?utf-8?B?Z0dOdFF1R09QU2UxK2NNdGhNc1IrS2RYVWFMeUpoQmRSN1lKdVY5QlMzVFhw?=
 =?utf-8?B?SzZNSTR4SXNyajJsM1NJMDNXdVRJTmlFVEVOV3N4bElMdnUwcGIzTmJ3N3hI?=
 =?utf-8?B?YjNna0ZSVmNrMmtSendRMWxxMWF3U0dPVHltTG5nSjVUeXRYMDRlUEtXWVRu?=
 =?utf-8?B?NG41TGtlakwrdjBzcjY3OFhoZTJ6OXpTSGlYdE9CcFJENXkrK25UcitNNDFy?=
 =?utf-8?B?Wjc3YlI1TmhneDBhSUMyU01KNndoUDE0UklsaDZ6WUV5RkkydTdXYkdYMVV1?=
 =?utf-8?B?anFRUi8wamtCeEFITkRuYzR5WVNURUxaZzR6cEZjMjN1TDRUMFdjTEQydWhI?=
 =?utf-8?B?R1hYUzczUnlocXVQTmtQYTRSc0dJdkErUUtSdjNnUGV6TnpsM3dlTVMwWUdI?=
 =?utf-8?B?U0RWaVJUbk82aVgyM1lUaHJwL0RYZzN6bkZEUW4wSmFVSVVXR1JYZnRHRDQx?=
 =?utf-8?B?S3BuWTZQRkQxelhteGtPSjBoa082aFRsd2lmTVh2bXBoeDU5b1FtbjRuWDJy?=
 =?utf-8?B?MjdDbGIzNlhHcFJqYk1rMXNQTGdFWlBnbU1ZcmZqcklCZ3JCc05TTGNEdURK?=
 =?utf-8?B?Y2V1RGd2a3djQVZkQzd3THJNY3k0RmpPbUdRcnFBOStZRkJiL3ZFclJocDVs?=
 =?utf-8?B?ZEJCRnRFeWhFekVHbFdPL29sQ2hzdm0vTkxsK1hEZkdBQUxpYUJ3dFMralNS?=
 =?utf-8?Q?Ho7ri5fevI8=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?M09rRFF6SHplSzJ4UEF1dFFHL205SjMzOWtCTVRST0cvc2FuSlpxbjRtSDVy?=
 =?utf-8?B?bCtDNlJOT0VFZ3VLL3d0bDN6UE10MjBIWmE1MURZSTNtcXdhK3pIbE15L1k5?=
 =?utf-8?B?SmVQMzFqUWkxNjZ3Q0N0bkp1L1hTb1pvWkxhSXRQNEZuTnNwVUQwMnNZY2V3?=
 =?utf-8?B?Sjlhdng0VjFPWUdPdTZLcTliejExTWhZdGxKQnNqWmFpSmhVRHZ6Y1dCMnkx?=
 =?utf-8?B?Ym93M2tEYWFVSVdVK0V6YXJLdmxUcXRrczVRTnJ5WS9OQnZxK0duVGRGUFM5?=
 =?utf-8?B?dmtOMys1QzNTTzFrcXJhaHNEKzFlNXM0bHh4cnJGVDZKVGMvVUFVL0tPTUFW?=
 =?utf-8?B?SitUQnhLWkgwNFhUNitGZUovRmpMQmZlQmlFVzd0a3cvWWRvbWowTEFyaDZS?=
 =?utf-8?B?TC9sL1dobVRuRkR5OG16MGR3MERndEVPbFp6QkVSb3BMREVzaWJodVFQYzh0?=
 =?utf-8?B?ZDk4SVJFd2V6aDNQSkdCbWV3T2hCdzRYRnpncTBFTmFMVms0b09RTmlhWmZi?=
 =?utf-8?B?VjNveEhUbUo2eFpTSDUySVBFK1dmOG9PdCs2Q1RLV0NQeGdmeHFNUnBmemxi?=
 =?utf-8?B?dzVkbXMwUXpwcWlpWG1Nd2M5bmFrd3JQZytJUGZndzlPaENDRUJjcHhGb20y?=
 =?utf-8?B?M0tld0xjTWNyM1V6S1h6Wm5Kc2RoSEMzQnhzcUN5dHUvMmloaXpqS3NkVVdX?=
 =?utf-8?B?aFh3WE1aRGVPSFNWZ290OWszUzVRckt5ZUxiMC84a2dLd0NrZjk3NHB5YWRR?=
 =?utf-8?B?aFRhNlFYSkRuQVdJR1Z4T2cvM3REUGd2N3lxL3RYd1pzdnhmRE1YaTZ2bHBW?=
 =?utf-8?B?M2tNS3IwbE95STM4VlhwSDFpOG53aUtkdFoxbUV6UXNoSEVNbDl3dzBYc2xk?=
 =?utf-8?B?M2VBSFkrTU9sTXppOE1mbDJKOW10OVVjTDY5Q1cwU0ozcUlFM3ZDUG9vMDdt?=
 =?utf-8?B?VG1lRmhFMEN2WC9VZ3V6aHgyNlhNaW52UWR3eXBGaEFiVjdlYXJPdklLOXFn?=
 =?utf-8?B?U1RwSjFNNTU4QXpmTnpzNUQ2ODhYRWYrSC9RZ3BYUTE3N2tCTE1GVTRTbU0y?=
 =?utf-8?B?cnFKbXlpekRJajZhYmJvc3g3YjZ3aG5WZmlTYTJaN0k2aTViZGg1cVRScXE3?=
 =?utf-8?B?QllaV3lDL05ySEs3cVowWXdMWmhIMnFWejNjM3RIVm9XWWRpNkxFa05oRnlZ?=
 =?utf-8?B?ajFDZGRqVnZOTkE4QUw3Tjlya2xmYkkrVkRZYVRWbUw3bk1ONVNWWTVjNVBr?=
 =?utf-8?B?eXFubjdXU3A3dllKT2ZEUW5TN2tnWHlSSFVvY3h2c3hWYmdURHV2aVRDVTVq?=
 =?utf-8?B?T2Z4U2M0d1JWOVViVGFqbGNua2lVUXZleFBZY3NtajFqaVFNV2pwcmg2Sldo?=
 =?utf-8?B?eXFYTjltc0dweVM0djMvWXJvQmh3Zmwzc0U1ZUJYa1hXdXphQkdLOTVPQ2hn?=
 =?utf-8?B?dUtMVVpzbEdzeExJSFcvWE5hb3lKSG1wMi9XYm16aU94NGwxdkZrRkxMODAw?=
 =?utf-8?B?amx0eUt3c005N052SEcvZUl0WWh3UzRsWEtLZC96cjgzYnZlaUFyRVlZZzlH?=
 =?utf-8?B?WmFZYXRYOVJiRFFINThGRzlONnJFZDF1aUt1d1c2cXpzNTdPMlhtRWZGODFV?=
 =?utf-8?B?MzQ4SzJSZkNYNjBzVENHVGNtck9iTTM3c0xjdXV6QVN3bGM5VDQ5ZVhBSTZa?=
 =?utf-8?B?SVYxNzMzWVUyVEgzN0UyQmNmMFRndDFpemw3MVRHMHUrQ0RjVFpXK3NSczRW?=
 =?utf-8?B?Y2NRUk4xdzBqMG93a0tGb2hjamNVRWJNVUhpaVhFck9HQ0ZoRXhQVXpkK2Jz?=
 =?utf-8?B?K3oxeEVHNWIxZDVieFQxQ2NFdzZRSWFFOU96M3JoOTc1ZVhBZ2pnMCsrbHFl?=
 =?utf-8?B?RkdIcHBIMHU0U1lwc04xSloxaWQ4SzRnYW44b0Q3dWc5UWtyU1lnUEtIU3pX?=
 =?utf-8?B?WGE0MC80dVNOR3lrM2hPdHIvVGtyV0N2NDFpRWxIdFBiU0lLUUs3MlpUOWh1?=
 =?utf-8?B?eDRmZVkyZ1NlcnI4MHd2Y0dHRjRYQWpzNjVDd29PYjZ1MXRpZWV0cFdrVGVx?=
 =?utf-8?B?WHdnckhSN1paNUsyVXFIa2FsYXpDbExkQThpMnFlYW1xY3dPMUpnS0ZYa2Rl?=
 =?utf-8?Q?GLx/Uezk2pJohXOQgUS9jCuJJ?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 36dda7f8-0df5-41c3-a487-08dda29105ae
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jun 2025 11:23:10.7702
 (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: udq491cXDLpJ9pivEuKyLlUpQthVMLoq+2kPV76qB1BVHJbLi8tdy1bLXmzxluxQ
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR12MB8461



On 03/06/2025 12:30, Roger Pau Monné wrote:
> On Tue, Jun 03, 2025 at 08:52:38AM +0200, Orzel, Michal wrote:
>>
>>
>> On 03/06/2025 08:46, Roger Pau Monné wrote:
>>> On Mon, Jun 02, 2025 at 05:09:29PM +0200, Michal Orzel wrote:
>>>> These tests are supposed to run on target. HOSTCC can be different than
>>>> CC (when cross-compiling). At the moment, tests installation would put
>>>> a binary of a wrong format in the destdir.
>>>>
>>>> Fixes: e90580f25bd7 ("vpci: introduce basic handlers to trap accesses to the PCI config space")
> 
> Hm, it's unclear to me whether this is the correct fixes tag.
> Previous to:
> 
> 96a587a05736 tools/tests: Add install target for vPCI
> 
> The test was not installed on the host, and hence didn't need to use
> CC instead of HOSTCC (or at least that's my understating).
You're right. Without install target, HOSTCC could make sense there.
I'll change the Fixes commit.

> 
>>>> Signed-off-by: Michal Orzel 
>>>> ---
>>>>  tools/tests/vpci/Makefile | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/tools/tests/vpci/Makefile b/tools/tests/vpci/Makefile
>>>> index 9450f7593a41..1101a669e118 100644
>>>> --- a/tools/tests/vpci/Makefile
>>>> +++ b/tools/tests/vpci/Makefile
>>>> @@ -11,7 +11,7 @@ run: $(TARGET)
>>>>  	./$(TARGET)
>>>>  
>>>>  $(TARGET): vpci.c vpci.h list.h main.c emul.h
>>>> -	$(HOSTCC) $(CFLAGS_xeninclude) -g -o $@ vpci.c main.c
>>>> +	$(CC) $(CFLAGS_xeninclude) -g -o $@ vpci.c main.c
>>>
>>> This was already posted in:
>>>
>>> https://lore.kernel.org/xen-devel/20230313121226.86557-1-roger.pau@citrix.com/
>>>
>>> And got no feedback.
>>>
>>> I'm happy for your change to go in, but you might also consider
>>> picking up the run target adjustment part of that previous patch.
>> You're the maintainer of this file. You should tell me what I need to do
>> unless you want to wait for Anthony feedback.
> 
> I would also add the chunk to adjust the run target if you use CC
> instead of HOSTCC.
Ok, will do.

~Michal



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 12:06:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 12:06:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004276.1383936 (Exim 4.92)
	(envelope-from )
	id 1uMQPM-0000Rg-0I; Tue, 03 Jun 2025 12:06:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004276.1383936; Tue, 03 Jun 2025 12:06: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 1uMQPL-0000RZ-Ta; Tue, 03 Jun 2025 12:06:19 +0000
Received: by outflank-mailman (input) for mailman id 1004276;
 Tue, 03 Jun 2025 12:06: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 1uMQPK-0000RT-BZ
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 12:06:18 +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 26995fb4-4073-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 14:06:16 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-451d6ade159so21561715e9.1
 for ; Tue, 03 Jun 2025 05:06:16 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a5005aa64esm10970384f8f.70.2025.06.03.05.06.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 03 Jun 2025 05:06:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 26995fb4-4073-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748952376; x=1749557176; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ged95j9C45XK7HEYC2aK6rKqhsVUuq6i2LaonLanmME=;
        b=Y/KRf5T5nK1f9WPLlosVd6L9naXXaRueHpRx8cEzbUoiHUqFLm3jYcvwBEaaXQtdZE
         OQ39AnflXDBeZ/Gs/j3QAIA44rf01D3aPavLwA0QPx1V9CNW+XAUSUaiNGHOxCXH/1ge
         Kvl5bpO7XdPLw1qaqEheWWD0npuZtUWlYE4T0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748952376; x=1749557176;
        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=ged95j9C45XK7HEYC2aK6rKqhsVUuq6i2LaonLanmME=;
        b=JnoO89TyaQxKX+jP+GUbqhXfe01PgGGTMH+3JgALgP1ZWLvYfjRP1EmNg3py30SFdg
         aeWrb9drJwpeorUzk3+iqtaxkS4f04ORn0JFKL2T/qKaHU0+BFH21hZVfXri425tKl7I
         Zj1jJG0KnvTofgSFPXtm51VyhPHRTNUTYsF1wgH39vabvqJa3au8YQ2SA/zAI9BUfOQJ
         u2gP+bmLJio20JJeTho+BDPsoBXRwZ1UdgIqeNdDz/zM7oTgNRl6/j4mxtKn5yxIaHGs
         54ucv3jQIAYkVmk4OZDU/kcvDcseZ23yGKkjghNk5FIlFfBJMAPTE51jZP6X5Iz/uEZl
         iBUQ==
X-Forwarded-Encrypted: i=1; AJvYcCW9tNO5g/9/6cgD5So3WmlEemita8vUe/uR7DL6PFL1xf2450QHh+tmxPvFHeHbIDCOES7BX7vd5L4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YysgxXjHijZiDTwitR5WOos9Dw1TcwuASFSFXoPKBc5t4jDAioc
	eV0fbSORwiQyNoUyO8fPTl5wBJ/pGQGsQan0b4xYZbBdUZtPYL5sPj0c4kF6pUebUdU=
X-Gm-Gg: ASbGncsPjdEga22UYMX7SWN6qT293SAKHe5vTPGIUp9dbxMMh+5KC2oU71dUfTFPw0h
	ugrX4fJZhrGFvjsKMMWWO+LAuvUEymw1Q3M+VBptfpmgi3dBmyC9mS2gqYt5VWIPqkFQk6OamYP
	UHYMMSiTygQAH/Ilo8FLorTMDawyX4F7xDLGg6ki7P7Psq9O2OBSa4gjC74qaP2AKFVQCtyjRsy
	xwbpDro46GZt+QaGD+/90vBdLtaDfpmVjESVBB1SPyQdeoQ/IIzyyKb0/iv2dqm4cKRqsVsyod9
	noPbAFdZsHWZeGnMWIX3rEoig8XBDd0mq0+4a2wzlD6TQ5zCAURO+eNKaPhyUure00bvMZeM4ua
	Agj9qDqYA0G4ZW5Hl
X-Google-Smtp-Source: AGHT+IFdlkleCcid0kp5qu918P6/S3TKTIo1gxVMh3q/KJaDRlcLAQxU124rnH63aaJWN+Unfyb5xg==
X-Received: by 2002:a05:6000:2313:b0:3a3:7638:d754 with SMTP id ffacd0b85a97d-3a4fe17ba86mr9629552f8f.21.1748952375569;
        Tue, 03 Jun 2025 05:06:15 -0700 (PDT)
Message-ID: 
Date: Tue, 3 Jun 2025 13:06:14 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/3] efi: Add a function to check if Secure Boot mode
 is enabled
To: Kevin Lampis , xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 Daniel Smith 
References: <20250602134656.3836280-1-kevin.lampis@cloud.com>
 <20250602134656.3836280-2-kevin.lampis@cloud.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: <20250602134656.3836280-2-kevin.lampis@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 02/06/2025 2:46 pm, Kevin Lampis wrote:
> From: Ross Lagerwall 
>
> Also cache it to avoid needing to repeatedly ask the firmware.
>
> Signed-off-by: Ross Lagerwall 
> Signed-off-by: Kevin Lampis 

You must CC the maintainers on patches.  If in doubt, use
./scripts/get_maintainer.pl.

> diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
> index 7e1fce291d..b63d21f16c 100644
> --- a/xen/common/efi/runtime.c
> +++ b/xen/common/efi/runtime.c
> @@ -40,6 +40,9 @@ void efi_rs_leave(struct efi_rs_state *state);
>  unsigned int __read_mostly efi_num_ct;
>  const EFI_CONFIGURATION_TABLE *__read_mostly efi_ct;
>  
> +#if defined(CONFIG_X86) && !defined(CONFIG_PV_SHIM)
> +bool __ro_after_init efi_secure_boot;
> +#endif

This doesn't build on ARM

arch/arm/efi/boot.c: In function ‘init_secure_boot_mode’:
arch/arm/efi/boot.c:888:25: error: lvalue required as left operand of
assignment
  888 |         efi_secure_boot = false;
      |                         ^
arch/arm/efi/boot.c:891:25: error: lvalue required as left operand of
assignment
  891 |         efi_secure_boot = true;
      |                         ^
make[3]: *** [Rules.mk:249: arch/arm/efi/boot.o] Error 1

I also don't see an answer to why there's a CONFIG_PV_SHIM special
case.  Shim has nothing to do with this.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 12:42:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 12:42:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004289.1383973 (Exim 4.92)
	(envelope-from )
	id 1uMQyK-0005qY-35; Tue, 03 Jun 2025 12:42:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004289.1383973; Tue, 03 Jun 2025 12:42: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 1uMQyJ-0005pk-Rj; Tue, 03 Jun 2025 12:42:27 +0000
Received: by outflank-mailman (input) for mailman id 1004289;
 Tue, 03 Jun 2025 12:42:26 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uMQyI-0005a1-Iw
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 12:42:26 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uMQyI-000CGP-14;
 Tue, 03 Jun 2025 12:42:26 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (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 1uMQyI-005di7-1Y;
 Tue, 03 Jun 2025 12:42: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" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:
	References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From;
	bh=L2rim9EpWcyPqx+pQDGmf2dIc++S82aIcPIQL9cYoMU=; b=45OnV/V7RYa2Ka85Y0ga0LXkh7
	XOwtWfBU3Ec/xLRXAqm1WiIByU0XazsvW/SrqZSVnfl22VuBFdBPpj8u8LesRJmecwvc7BRPbpHzk
	o31iiQgshxcB1CiPsKX1jxUiEWhLqjlKbLamBoJncuLZHOpEba4dRO3fbDZYNPJ0iIeY=;
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Andrew Cooper ,
	Anthony PERARD 
Subject: [XEN PATCH 2/9] tools/tests: Fix return value of test-rangeset
Date: Tue,  3 Jun 2025 14:42:15 +0200
Message-Id: <20250603124222.52057-3-anthony@xenproject.org>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250603124222.52057-1-anthony@xenproject.org>
References: <20250603124222.52057-1-anthony@xenproject.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Anthony PERARD 

Otherwise, failed tests are ignored by automated test.

Signed-off-by: Anthony PERARD 
---
 tools/tests/rangeset/test-rangeset.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/tests/rangeset/test-rangeset.c b/tools/tests/rangeset/test-rangeset.c
index 8b580e14eb..c14a908b4f 100644
--- a/tools/tests/rangeset/test-rangeset.c
+++ b/tools/tests/rangeset/test-rangeset.c
@@ -215,7 +215,7 @@ int main(int argc, char **argv)
         }
     }
 
-    return 0;
+    return ret_code;
 }
 
 /*
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 12:42:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 12:42:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004291.1383998 (Exim 4.92)
	(envelope-from )
	id 1uMQyM-0006U6-DT; Tue, 03 Jun 2025 12:42:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004291.1383998; Tue, 03 Jun 2025 12: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 1uMQyM-0006Ty-9c; Tue, 03 Jun 2025 12:42:30 +0000
Received: by outflank-mailman (input) for mailman id 1004291;
 Tue, 03 Jun 2025 12:42:28 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uMQyK-00066r-MJ
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 12:42:28 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uMQyK-000CGl-1W;
 Tue, 03 Jun 2025 12:42:28 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (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 1uMQyK-005di7-2B;
 Tue, 03 Jun 2025 12:42: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=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:
	References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From;
	bh=XI7mlfkKcVIHJ932YmivIqQFqrUIzKTKRZOSU/o2lrQ=; b=poHaAv0IEhUpNUVscRbLzGInV3
	rvUfPkAgf37JW1npPo2FVxSxxZ8HKpm9jI0pQm1x6OkOB8ao2g89VCTza2owTPRVuWenKJxEd1EyA
	59ZCITkcJkqNZitx0OSQ4EjQQLwJKNy+x6iq8IJbHBxAGmyuPZnRqZK04F2GZzRTX8Rg=;
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Andrew Cooper ,
	Anthony PERARD ,
	Doug Goldstein ,
	Stefano Stabellini 
Subject: [XEN PATCH 4/9] CI: Ignore run-tools-test return value
Date: Tue,  3 Jun 2025 14:42:17 +0200
Message-Id: <20250603124222.52057-5-anthony@xenproject.org>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250603124222.52057-1-anthony@xenproject.org>
References: <20250603124222.52057-1-anthony@xenproject.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Anthony PERARD 

The main script expect to find the string "$passed" or it just
timeout. Then, it doesn't try to download the junit file.
So ignore the return value of run-tools-test for now.

This mean the job will not fail, but at least we should have the junit
files with the error messages.

Signed-off-by: Anthony PERARD 
---

Notes:
    On failure from a tests after this patch, the gitlab job succeed. But
    the junit file is collected.

 automation/scripts/qubes-x86-64.sh | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qubes-x86-64.sh
index 2750d24eba..046137a4a6 100755
--- a/automation/scripts/qubes-x86-64.sh
+++ b/automation/scripts/qubes-x86-64.sh
@@ -135,10 +135,11 @@ done
     ### tests: tools-tests-pv, tools-tests-pvh
     "tools-tests-pv"|"tools-tests-pvh")
         retrieve_xml=1
-        passed="test passed"
+        passed="run-tools-test over"
         domU_check=""
         dom0_check="
-/root/run-tools-tests /usr/lib/xen/tests /tmp/tests-junit.xml && echo \"${passed}\"
+/root/run-tools-tests /usr/lib/xen/tests /tmp/tests-junit.xml ||:
+echo \"${passed}\"
 nc -l -p 8080 < /tmp/tests-junit.xml >/dev/null &
 "
         if [ "${test_variant}" = "tools-tests-pvh" ]; then
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 12:42:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 12:42:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004290.1383988 (Exim 4.92)
	(envelope-from )
	id 1uMQyL-0006Em-7B; Tue, 03 Jun 2025 12:42:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004290.1383988; Tue, 03 Jun 2025 12:42: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 1uMQyL-0006EP-3O; Tue, 03 Jun 2025 12:42:29 +0000
Received: by outflank-mailman (input) for mailman id 1004290;
 Tue, 03 Jun 2025 12:42:27 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uMQyJ-0005oa-Q0
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 12:42:27 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uMQyJ-000CGe-1f;
 Tue, 03 Jun 2025 12:42:27 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (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 1uMQyJ-005di7-1r;
 Tue, 03 Jun 2025 12:42: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=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:
	References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From;
	bh=kK1Tx9vm5iULGdSLvjqkBnXbzSdn9xeUjOcjEOgDs9I=; b=RfQjopJDxB0v5oOjsgVzYOnxOa
	qLO9U7tU3YklWnVN9ZpkCB5r7HGur5rNt1MVF+QUZfWVksWUvhFQMm+BEnBF+xCEPL+YYeb1AYH4Q
	gOcVg6hFWgouu82Gz24PF83hKj8Bu62PVwgEYi6z7N3QN37F0PUd7j/yGGyHmM4dYO6s=;
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Andrew Cooper ,
	Anthony PERARD ,
	Doug Goldstein ,
	Stefano Stabellini 
Subject: [XEN PATCH 3/9] CI: Fix status check for tools/tests
Date: Tue,  3 Jun 2025 14:42:16 +0200
Message-Id: <20250603124222.52057-4-anthony@xenproject.org>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250603124222.52057-1-anthony@xenproject.org>
References: <20250603124222.52057-1-anthony@xenproject.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Anthony PERARD 

Without "pipefail", $? have the exit value of `tee`, which should
always be 0. But instead of using "pipefail", do collect the value of
from the test with $PIPESTATUS.

Signed-off-by: Anthony PERARD 
---

Notes:
    Without the next patch "CI: Ignore run-tools-test return value", this
    just mean that if one test fail, the script `qubes-x86-64.sh` will
    detect a ERROR-Timeout because the expected string is never printed.

 automation/scripts/run-tools-tests | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/automation/scripts/run-tools-tests b/automation/scripts/run-tools-tests
index 2bca1589db..695ed77e46 100755
--- a/automation/scripts/run-tools-tests
+++ b/automation/scripts/run-tools-tests
@@ -20,7 +20,7 @@ for f in "$1"/*; do
     echo "Running $f"
     printf '  \n' "$f" >> "$xml_out"
     "$f" 2>&1 | tee /tmp/out
-    ret=$?
+    ret=${PIPESTATUS[0]}
     if [ "$ret" -ne 0 ]; then
         echo "FAILED: $f"
         failed+=" $f"
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 12:42:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 12:42:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004288.1383968 (Exim 4.92)
	(envelope-from )
	id 1uMQyJ-0005nK-NY; Tue, 03 Jun 2025 12:42:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004288.1383968; Tue, 03 Jun 2025 12: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 1uMQyJ-0005nD-Kf; Tue, 03 Jun 2025 12:42:27 +0000
Received: by outflank-mailman (input) for mailman id 1004288;
 Tue, 03 Jun 2025 12:42:25 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uMQyH-0005ZX-Pt
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 12:42:25 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uMQyH-000CGH-1P;
 Tue, 03 Jun 2025 12:42:25 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (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 1uMQyH-005di7-1z;
 Tue, 03 Jun 2025 12:42: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" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:
	References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From;
	bh=E+UTBqVT4ataITEs2z99MCcjBJjVKQSs1JAGcPyP+AE=; b=LRUze+1QWU+0/9XYKBT+2jZ4hF
	dWaHhMw4rqE6hdBqeEuzZ+ZRaRhcud9BaCecK19RlXQE11F8brOyjDitIGsq9oEIPMONvUywKuN1+
	GYkondxAGCndW9YPwnDhrK+z9BmiAP/iyiODtilkuCtAeMQf6vdHaUvWelQW9oi+2pyc=;
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Andrew Cooper ,
	Anthony PERARD ,
	Doug Goldstein ,
	Stefano Stabellini 
Subject: [XEN PATCH 1/9] CI: Add SELECTED_JOBS_ONLY to analyze.yaml
Date: Tue,  3 Jun 2025 14:42:14 +0200
Message-Id: <20250603124222.52057-2-anthony@xenproject.org>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250603124222.52057-1-anthony@xenproject.org>
References: <20250603124222.52057-1-anthony@xenproject.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Anthony PERARD 

Signed-off-by: Anthony PERARD 
---
 automation/gitlab-ci/analyze.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/automation/gitlab-ci/analyze.yaml b/automation/gitlab-ci/analyze.yaml
index 35ff3620cf..5b00b9f25c 100644
--- a/automation/gitlab-ci/analyze.yaml
+++ b/automation/gitlab-ci/analyze.yaml
@@ -29,6 +29,9 @@
   rules:
     - if: $CI_PIPELINE_SOURCE == "schedule"
       when: never
+    - if: $SELECTED_JOBS_ONLY && $CI_JOB_NAME =~ $SELECTED_JOBS_ONLY
+    - if: $SELECTED_JOBS_ONLY
+      when: never
     - if: $WTOKEN && $CI_PROJECT_PATH =~ /^xen-project\/people\/.*$/
       when: manual
       allow_failure: true
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 12:42:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 12:42:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004287.1383959 (Exim 4.92)
	(envelope-from )
	id 1uMQyI-0005Zk-JW; Tue, 03 Jun 2025 12:42:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004287.1383959; Tue, 03 Jun 2025 12:42:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMQyI-0005Zd-Es; Tue, 03 Jun 2025 12:42:26 +0000
Received: by outflank-mailman (input) for mailman id 1004287;
 Tue, 03 Jun 2025 12:42:24 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uMQyG-0005ZR-Ra
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 12:42:24 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uMQyG-000CGB-1M;
 Tue, 03 Jun 2025 12:42:24 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (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 1uMQyG-005di7-1f;
 Tue, 03 Jun 2025 12:42: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" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:
	Message-Id:Date:Subject:Cc:To:From;
	bh=H91GbEN+aoGGPPzwFtL5rgVS6VFOCpx4W1spHRaIpZ4=; b=cN5apCXUU90TZLTZV9/Fvi+BYs
	i5+DQDjsTupfyZmYFL6XUsDPgg15sJjSPTFHJQLqqbMI0MAoQVjAPybcPIgbao3uSGRHCvyZ7VwE/
	EoyM2d2mK+FwdJKi3HX+LSAamWFRxTqXxve5i+mO9BRNWxh1UHV2QvqgndFVrAXh6Rvo=;
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Andrew Cooper ,
	Anthony PERARD ,
	Stefano Stabellini ,
	Doug Goldstein 
Subject: [XEN PATCH 0/9] CI: Fixes for tools/tests and junit and other
Date: Tue,  3 Jun 2025 14:42:13 +0200
Message-Id: <20250603124222.52057-1-anthony@xenproject.org>
X-Mailer: git-send-email 2.39.5
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Anthony PERARD 

Patch series available in this git branch:
https://xenbits.xenproject.org/git-http/people/aperard/xen-unstable.git br.ci-tools-tests-junit-fixes-v1

All the *-tools-tests-* are currently only checking automatically if the
machine as booted. The only way to find out if one of the tools/tests failed is
to read the console output by hand.

Also, tests-rangeset always return success even if there's a failure.

Fix all that, and add some improvement, and add SELECTED_JOBS_ONLY to
analyze.yaml

How it looks:
success:
    https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1850830262/test_report
failure:
    https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1850830637/test_report

Cheers,

Anthony PERARD (9):
  CI: Add SELECTED_JOBS_ONLY to analyze.yaml
  tools/tests: Fix return value of test-rangeset
  CI: Fix status check for tools/tests
  CI: Ignore run-tools-test return value
  CI: Have the gitlab job fail on tools/tests failure
  CI: Upload junit result as artefact
  CI: Use CDATA avoid the need to escape tests outputs
  CI: Workaround extra content in junit
  CI: Add timing to junit

 automation/gitlab-ci/analyze.yaml    |  3 +++
 automation/gitlab-ci/test.yaml       |  1 +
 automation/scripts/qubes-x86-64.sh   | 18 ++++++++++++++++--
 automation/scripts/run-tools-tests   | 11 +++++++----
 tools/tests/rangeset/test-rangeset.c |  2 +-
 5 files changed, 28 insertions(+), 7 deletions(-)

-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 12:42:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 12:42:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004292.1384008 (Exim 4.92)
	(envelope-from )
	id 1uMQyN-0006jg-Ks; Tue, 03 Jun 2025 12:42:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004292.1384008; Tue, 03 Jun 2025 12:42:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMQyN-0006jB-H9; Tue, 03 Jun 2025 12:42:31 +0000
Received: by outflank-mailman (input) for mailman id 1004292;
 Tue, 03 Jun 2025 12:42:29 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uMQyL-0006Pb-PY
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 12:42:29 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uMQyL-000CGt-1p;
 Tue, 03 Jun 2025 12:42:29 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (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 1uMQyL-005di7-2V;
 Tue, 03 Jun 2025 12:42: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=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:
	References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From;
	bh=edUAqQTo7e+ICLWUgXscm8y7F2IcKiWAIoO6Hnv56ew=; b=XPu7i2TPH6u1UNZmhKmFtlG/nO
	cdMXUwAyFv1dKUwVITa12G+T6A/F+Dop/vUkRy1hiygWWqe99Gt6Kqriet8Lci9YyUElatf8qpDpL
	Lz/V53RpurWNXvV4+h/XOHlSEeSQQEhun+/yQgwzPrsVpKU4phE1Mdmmdkrj8fYZael4=;
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Andrew Cooper ,
	Anthony PERARD ,
	Doug Goldstein ,
	Stefano Stabellini 
Subject: [XEN PATCH 5/9] CI: Have the gitlab job fail on tools/tests failure
Date: Tue,  3 Jun 2025 14:42:18 +0200
Message-Id: <20250603124222.52057-6-anthony@xenproject.org>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250603124222.52057-1-anthony@xenproject.org>
References: <20250603124222.52057-1-anthony@xenproject.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Anthony PERARD 

We can't rely on an exit value from `run-tools-tests` since we only
have the console output. `console.exp` only look for success or it
times out. We could parse the console output, but the junit is more
concise. Also check if we have it or fail as well.

Signed-off-by: Anthony PERARD 
---
 automation/scripts/qubes-x86-64.sh | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qubes-x86-64.sh
index 046137a4a6..7a4c5ae489 100755
--- a/automation/scripts/qubes-x86-64.sh
+++ b/automation/scripts/qubes-x86-64.sh
@@ -298,6 +298,13 @@ TEST_RESULT=$?
 
 if [ -n "$retrieve_xml" ]; then
     nc -w 10 "$SUT_ADDR" 8080 > tests-junit.xml ' tests-junit.xml; then
+        echo "ERROR: tests-junit.xml is incomplete or missing."
+        TEST_RESULT=1
+    elif grep -q '' tests-junit.xml; then
+        TEST_RESULT=1
+    fi
 fi
 
 exit "$TEST_RESULT"
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 12:42:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 12:42:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004293.1384018 (Exim 4.92)
	(envelope-from )
	id 1uMQyP-00070l-4j; Tue, 03 Jun 2025 12:42:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004293.1384018; Tue, 03 Jun 2025 12:42:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMQyO-00070a-VP; Tue, 03 Jun 2025 12:42:32 +0000
Received: by outflank-mailman (input) for mailman id 1004293;
 Tue, 03 Jun 2025 12:42:30 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uMQyM-0006cT-Ru
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 12:42:30 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uMQyM-000CH1-2A;
 Tue, 03 Jun 2025 12:42:30 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (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 1uMQyM-005di7-2p;
 Tue, 03 Jun 2025 12:42: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=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:
	References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From;
	bh=zrPvG8IMBYXQG2B7hfodQ0aQa554NWza+LSe4vglB3o=; b=X9oVUvZSmI2c/8sOSwngBg1Y13
	r8Ewzd1fg0rH0R8fGMpg65/nRh3jTpSsTuacyDggXZpeGxCCldf0XWYc7+tWPmtgYXMBRPSCpeuFW
	sIp+ItMj7Ksd7mhbr0ZKSTp5zQINTtj/5/DLh6DchoQeEDGwSda06weKooMX6modGcXg=;
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Andrew Cooper ,
	Anthony PERARD ,
	Doug Goldstein ,
	Stefano Stabellini 
Subject: [XEN PATCH 6/9] CI: Upload junit result as artefact
Date: Tue,  3 Jun 2025 14:42:19 +0200
Message-Id: <20250603124222.52057-7-anthony@xenproject.org>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250603124222.52057-1-anthony@xenproject.org>
References: <20250603124222.52057-1-anthony@xenproject.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Anthony PERARD 

This allow to investigate the file in cases of error. Not all
jobs that extend ".adl-x86-64" are creating a "tests-junit.xml" but
Gitlab only produce a warning when the file isn't found.

Signed-off-by: Anthony PERARD 
---
 automation/gitlab-ci/test.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
index 842cecf713..2b4b8c021b 100644
--- a/automation/gitlab-ci/test.yaml
+++ b/automation/gitlab-ci/test.yaml
@@ -155,6 +155,7 @@
     paths:
       - smoke.serial
       - '*.log'
+      - tests-junit.xml
     when: always
   rules:
     - if: $SELECTED_JOBS_ONLY && $CI_JOB_NAME =~ $SELECTED_JOBS_ONLY
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 12:42:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 12:42:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004294.1384023 (Exim 4.92)
	(envelope-from )
	id 1uMQyP-00073G-Gh; Tue, 03 Jun 2025 12:42:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004294.1384023; Tue, 03 Jun 2025 12:42:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMQyP-00072b-8y; Tue, 03 Jun 2025 12:42:33 +0000
Received: by outflank-mailman (input) for mailman id 1004294;
 Tue, 03 Jun 2025 12:42:32 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uMQyN-0006oL-W7
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 12:42:31 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uMQyN-000CH9-2U;
 Tue, 03 Jun 2025 12:42:31 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (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 1uMQyN-005di7-39;
 Tue, 03 Jun 2025 12:42: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=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:
	References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From;
	bh=gLml0ocUwSJxLHe7Tk7Z9KoA979LIAL3NtErmX5LnSE=; b=2I5Za3CgYoKOYiObuMlgKNmGKS
	krx3VSqpWkfARsq9vWXYLyU0t+Vje1zYt2MiOk/p6yRXDYrWOGAz5zcSQOEcx7DVH4z2s+AatvyYD
	7V4Day8f1sxBsXpQQicL374h92smCKNL/nrNjZUeU7PlhQ9SZ+UIjus8dGQJaQCliDWc=;
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Andrew Cooper ,
	Anthony PERARD ,
	Doug Goldstein ,
	Stefano Stabellini 
Subject: [XEN PATCH 7/9] CI: Use CDATA avoid the need to escape tests outputs
Date: Tue,  3 Jun 2025 14:42:20 +0200
Message-Id: <20250603124222.52057-8-anthony@xenproject.org>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250603124222.52057-1-anthony@xenproject.org>
References: <20250603124222.52057-1-anthony@xenproject.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Anthony PERARD 

This is easier than escaping individual characters, especially '&'
and '<' which are problematic if present.

We might still need to escape ']]>' if this string is present in the
test output, but hopefully not.

Signed-off-by: Anthony PERARD 
---
 automation/scripts/run-tools-tests | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/automation/scripts/run-tools-tests b/automation/scripts/run-tools-tests
index 695ed77e46..852c1cfbcf 100755
--- a/automation/scripts/run-tools-tests
+++ b/automation/scripts/run-tools-tests
@@ -25,9 +25,9 @@ for f in "$1"/*; do
         echo "FAILED: $f"
         failed+=" $f"
         printf '   \n' "$f" "$ret" >> "$xml_out"
-        # TODO: could use xml escaping... but current tests seems to
-        # produce sane output
+        printf '> "$xml_out"
         cat /tmp/out >> "$xml_out"
+        printf ']]>' >> "$xml_out"
         printf '   \n' >> "$xml_out"
     else
         echo "PASSED"
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 12:42:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 12:42:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004295.1384037 (Exim 4.92)
	(envelope-from )
	id 1uMQyQ-0007R2-Qg; Tue, 03 Jun 2025 12:42:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004295.1384037; Tue, 03 Jun 2025 12:42: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 1uMQyQ-0007Qh-IU; Tue, 03 Jun 2025 12:42:34 +0000
Received: by outflank-mailman (input) for mailman id 1004295;
 Tue, 03 Jun 2025 12:42:33 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uMQyO-00070R-Tm
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 12:42:32 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uMQyO-000CHH-2l;
 Tue, 03 Jun 2025 12:42:32 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (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 1uMQyP-005di7-0E;
 Tue, 03 Jun 2025 12:42: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=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:
	References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From;
	bh=Z+KO5MEJLmLiDR6R7GxGmFnSMjUykYCseZZs3veeZOI=; b=iXva1RAcd06eYvvWX3764g/BQT
	CEKH9Rh3GW00tIYmN+WE5+qEnD7HZy0re8WhwjhieMSRVZn+nt+uEY+dBFKg/+yca34D5LiKkZ9ih
	4SQzd++6JC2LBJHlqq9JUBapr9EXeoGBjebLJtuMZ+Mf7c8gwNLtQTDB1K0nWXQibyvU=;
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Andrew Cooper ,
	Anthony PERARD ,
	Doug Goldstein ,
	Stefano Stabellini 
Subject: [XEN PATCH 8/9] CI: Workaround extra content in junit
Date: Tue,  3 Jun 2025 14:42:21 +0200
Message-Id: <20250603124222.52057-9-anthony@xenproject.org>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250603124222.52057-1-anthony@xenproject.org>
References: <20250603124222.52057-1-anthony@xenproject.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Anthony PERARD 

Signed-off-by: Anthony PERARD 
---
 automation/scripts/qubes-x86-64.sh | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qubes-x86-64.sh
index 7a4c5ae489..6ab8412f45 100755
--- a/automation/scripts/qubes-x86-64.sh
+++ b/automation/scripts/qubes-x86-64.sh
@@ -298,6 +298,12 @@ TEST_RESULT=$?
 
 if [ -n "$retrieve_xml" ]; then
     nc -w 10 "$SUT_ADDR" 8080 > tests-junit.xml /q' tests-junit.xml > /dev/null
+    extra_line_in_junit=$(($(wc -l < tests-junit.xml.old) - $(wc -l < tests-junit.xml)))
+    if [ $extra_line_in_junit -gt 0 ]; then
+        echo "WARNING: Found $extra_line_in_junit too many lines in junit."
+    fi
     # Findout if one of the test failed
     if ! grep -q '' tests-junit.xml; then
         echo "ERROR: tests-junit.xml is incomplete or missing."
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 12:42:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 12:42:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004296.1384048 (Exim 4.92)
	(envelope-from )
	id 1uMQyS-0007oO-Dw; Tue, 03 Jun 2025 12:42:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004296.1384048; Tue, 03 Jun 2025 12:42:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMQyS-0007nZ-35; Tue, 03 Jun 2025 12:42:36 +0000
Received: by outflank-mailman (input) for mailman id 1004296;
 Tue, 03 Jun 2025 12:42:34 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uMQyQ-0007Kz-6y
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 12:42:34 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uMQyP-000CHQ-35;
 Tue, 03 Jun 2025 12:42:33 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (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 1uMQyQ-005di7-0X;
 Tue, 03 Jun 2025 12:42: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=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:
	References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From;
	bh=9+GoEHcrcXffSGesQEWI0GuwFDcV6Q4bPLnJ++8/OYE=; b=p+uT9LUN/v9pU5ZWashSBZfh84
	aKhiQCaYRmLhAFhGtkb5tSNtqFAWtzqgm8AMK2L4M7VpjpGXc2TsV3dWW/hV5Ph4IiXp8T1ztGMV2
	OqliyP0BaRKQ/SqMGKNkeBZxQ1cc9C0si3FG5d/pkVMFzcllRusAzGWLZXcGZy91BIZ8=;
From: Anthony PERARD 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Andrew Cooper ,
	Anthony PERARD ,
	Doug Goldstein ,
	Stefano Stabellini 
Subject: [XEN PATCH 9/9] CI: Add timing to junit
Date: Tue,  3 Jun 2025 14:42:22 +0200
Message-Id: <20250603124222.52057-10-anthony@xenproject.org>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250603124222.52057-1-anthony@xenproject.org>
References: <20250603124222.52057-1-anthony@xenproject.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Anthony PERARD 

Signed-off-by: Anthony PERARD 
---
 automation/scripts/run-tools-tests | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/automation/scripts/run-tools-tests b/automation/scripts/run-tools-tests
index 852c1cfbcf..e38cc4068c 100755
--- a/automation/scripts/run-tools-tests
+++ b/automation/scripts/run-tools-tests
@@ -18,9 +18,12 @@ for f in "$1"/*; do
         continue
     fi
     echo "Running $f"
-    printf '  \n' "$f" >> "$xml_out"
+    time_start=$EPOCHREALTIME
     "$f" 2>&1 | tee /tmp/out
     ret=${PIPESTATUS[0]}
+    time_end=$EPOCHREALTIME
+    time_test="$(bc <<<"$time_end - $time_start")"
+    printf '  \n' "$f" "$time_test" >> "$xml_out"
     if [ "$ret" -ne 0 ]; then
         echo "FAILED: $f"
         failed+=" $f"
-- 
Anthony PERARD



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 12:49:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 12:49:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004329.1384058 (Exim 4.92)
	(envelope-from )
	id 1uMR4Z-0002Kx-3Z; Tue, 03 Jun 2025 12:48:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004329.1384058; Tue, 03 Jun 2025 12:48: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 1uMR4Z-0002Kq-0I; Tue, 03 Jun 2025 12:48:55 +0000
Received: by outflank-mailman (input) for mailman id 1004329;
 Tue, 03 Jun 2025 12:48: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 1uMR4X-0002Kk-JO
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 12:48:53 +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 188fc79f-4079-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 14:48:51 +0200 (CEST)
Received: from BY5PR17CA0024.namprd17.prod.outlook.com (2603:10b6:a03:1b8::37)
 by CH3PR12MB7569.namprd12.prod.outlook.com (2603:10b6:610:146::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.32; Tue, 3 Jun
 2025 12:48:44 +0000
Received: from SJ5PEPF000001EF.namprd05.prod.outlook.com
 (2603:10b6:a03:1b8:cafe::81) by BY5PR17CA0024.outlook.office365.com
 (2603:10b6:a03:1b8::37) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.40 via Frontend Transport; Tue,
 3 Jun 2025 12:48:44 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ5PEPF000001EF.mail.protection.outlook.com (10.167.242.203) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Tue, 3 Jun 2025 12:48:43 +0000
Received: from localhost (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 Jun
 2025 07:48:41 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 188fc79f-4079-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=xUxlgGZ9KVd4m575LbPpWbBSucZ5vhPD91Fi3EZf1lI+R8/JF/yyKB2Gd8PseNlofQ87apIbyaM/zcYmXgbPX5aRWBGn1zjlvwHZikYrRUXR6car5Vt6/QZh2awABc7kKIYSuduq9O8kZVGirPbR6Xe4V4jQW3W0mV20Hr4mH/lAfUqwDSW25GSwMJztwWVE1Js7LZLfnUIiuN9zLQ8Y/wGDxwFCGB3M3+w4D+ZdZykk1FKrDSIcONaoRgk7K4f4dFznNjH5WmtB9fsMW+EZHrm+SuLLj7LWoz732fbYi3K59udYJFKkuayGkvcVxibMhuYbrFAyCH/Co//3tCGNMA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=OOcRDHDw2KcZP/jf3nXNcssUgkECRAZ5Ky7uoik/6P8=;
 b=cU+POluV9zhAXH/lD5kYXmxK+/zjLsGZ1N07OlLgC2STCaEnqpdou+HYx7JSVd7VbkX1ufKu2aeufESiUIV0//rps/2INbpBr36desMYbWSlh5dpeSEqMchHgqfh49m2HA21pUFnyHUjowoog/ldEaYYA5vC80n+dbojYbYL88w3JY5PNJupXnf6jTz6R/04r5xfN72YYawcekHQ3RjcArG1sCQKJsH7Wswpi2Nz5hj4LEOBraGFjMR69T1Xu0rZwWPWyFPSA44dkB0YaoXw2z2Soc5o559loSGx5o1DJgz3JdFaBXbSdyjM6FdZuUpzkRZd9+3TFLQYegyMJgqMeg==
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=OOcRDHDw2KcZP/jf3nXNcssUgkECRAZ5Ky7uoik/6P8=;
 b=J8G08EFYGgeFwAvWyxisJKBvwNDIHO5VcX/X6qNHsAzVbhQ3Lz4NudLymKeJrN5+8HifrfMvG87yfk6HFUyE3rbPcZEyCqrSMvRNGkeaq1C8x7ck07deKsGyW1S6nZZUac9U008lX20o6u46oHlMMuq0MGpKgxvUQrIbWr08tk8=
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
Date: Tue, 3 Jun 2025 14:48:39 +0200
From: "Edgar E. Iglesias" 
To: Julien Grall 
CC: "Edgar E. Iglesias" ,
	, ,
	, ,
	, , Anthony PERARD
	, Juergen Gross , Jan Beulich
	, Roger Pau =?iso-8859-1?Q?Monn=E9?=
	
Subject: Re: [PATCH v3 1/5] xen/arm: Add way to disable traps on accesses to
 unmapped addresses
Message-ID: 
References: <20250530134559.1434255-1-edgar.iglesias@gmail.com>
 <20250530134559.1434255-2-edgar.iglesias@gmail.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/2.2.14+84 (2efcabc4) (2025-03-23)
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: SJ5PEPF000001EF:EE_|CH3PR12MB7569:EE_
X-MS-Office365-Filtering-Correlation-Id: dd7f6dd6-3365-4a2f-f698-08dda29cf930
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700013|82310400026|376014|7416014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?XO+ez36sywyv0UsMOOe3SKMk6XzU7si1+UwPJJNPRCb2N5n1w6udaJmpedxp?=
 =?us-ascii?Q?k5ID01ZzbhUaOTDmOWN+5uGXnGN3+unkK3lQFe8NL4RAIXupLJAmMvj1iFKG?=
 =?us-ascii?Q?vRAsIdlRLPG14kapuHjTx48HXPXOEw+4v5Bp/t6KK1kvFHYd6xZgB+jUE5Uh?=
 =?us-ascii?Q?6h4KA06iPkIx1XTTr7ZfOILLquTGWmDTrfluz09lP+gEk7aCoqKNBFAe81yu?=
 =?us-ascii?Q?epSZ28XCFPcJ6HKP9lk+z7EHax+gTjXPPmN4Bdp/ZjNU71tz1FyKiStwtuxg?=
 =?us-ascii?Q?TNfGCIHRkR8yLOR23UfziyIAd/MlsD8X6cTrzJGhwbEiRF+I64JjzO8w1BCm?=
 =?us-ascii?Q?Bjhqtamx0/LukGOV1AcsyzIA1yDCsSgZRUWTU1kygJyG7/NeupYd5AhdgEUl?=
 =?us-ascii?Q?W0YMCbgHdYUOFYj0zOSFvPv06pB2PGzo47Dfwu3CbxN65tJKTnEZ3gnDIVGa?=
 =?us-ascii?Q?/c+XnzbroFE3GIrGoT8igaDPjukxyy9jcMIsROWD7Xqtu0sHtAZ8yOthCX2v?=
 =?us-ascii?Q?EZ5gz0j9dcaKt265ftVIVbk7UIWUL3zZG9FOP/X6BxiByL4SxeGOLJWYj//u?=
 =?us-ascii?Q?hrgeDErqyx9tYIY2QVpZiJRIqnCN6GPUNUrNaKlj8b8u5xO+cYBurIQcuSi6?=
 =?us-ascii?Q?/dg4hUxoylqUmFHHCdTGndEOv2eoXl5nZKP4Fz/xUxMrxrEuZ2URpXEbDNEB?=
 =?us-ascii?Q?LzUX+BJOl/mMZKU3lCXZfaF7+1zNtMmp/6gzEcLbGAr2nomkwUB6bEgQgmI8?=
 =?us-ascii?Q?IkYJNWEVseIBmoitK/Tfp0pK3KaUkHTaQooUsn3KrUnSangsBZllgQ8mUW5u?=
 =?us-ascii?Q?+wI3+orE6YAVyvlUfxluIZivsMXLaU9pCdmDQFmmWDs2cBK1UKrOvL45ww7Y?=
 =?us-ascii?Q?HYZ6SH1BNFjRGcbGphNa4NknrGzzXpkyese9KROT+mIe1jMbm6s1ZtGxunU/?=
 =?us-ascii?Q?l9pipIlDxd4aMbVEBCD+AZF5+1YlQRdtdT2JA0Q9PL3a3THJP2ipTxkA1UOy?=
 =?us-ascii?Q?qoM+fbort1nrBfEJrhfz3/G8mRrAyQ+fQc2/BGXtji1vd8GjJA+ar0LNc8rW?=
 =?us-ascii?Q?5Agf+nfBSYH+O07EpX81cMT/vn1+Oe90OzAI1NMeR1OLju2V/AV5yVbUySGO?=
 =?us-ascii?Q?wX0Kmm+cU80oYXOQBA4ZGmUrvi9nJYOPw+JaGhjO5NbInp9zcPhY13mcLqeP?=
 =?us-ascii?Q?k3mSpTcJZmObAjsTPOo/wvLJXRJLCY/+nI1glAICUx21KPMIKOJ+7GXQeJlr?=
 =?us-ascii?Q?3SF6BUCky0no5rQBCFY6uEO60OObZ9yKOV6qbdJvhvz6YcmLopqFeoKhYMmT?=
 =?us-ascii?Q?yME3TPw6ESK4PPXrYO54WjhS8TFv36gpi92OvXsZ6HP3ury24fCNbpTFga2w?=
 =?us-ascii?Q?c/f0fHs3vQY7UhzCBvVIXaSvM3SwXTSAjRJc0OnGKewrBGgwUpTGvfJPJG0M?=
 =?us-ascii?Q?RqFR8OLUzVwpIEaeBYY9hgqBCtvqHrL9JRk/clFnQF6YoY8gEQlv4ccpJST3?=
 =?us-ascii?Q?f3XiH52ukOYYEB6iPnC8Ue9HaM0kZbcOGGIV?=
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)(7416014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jun 2025 12:48:43.4547
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: dd7f6dd6-3365-4a2f-f698-08dda29cf930
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:
	SJ5PEPF000001EF.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB7569

On Tue, Jun 03, 2025 at 10:36:40AM +0100, Julien Grall wrote:
> Hi Edgar,

Hi Julien,

> 
> On 30/05/2025 14:45, Edgar E. Iglesias wrote:
> > From: "Edgar E. Iglesias" 
> > 
> > Add a per-domain way to optionally disable traps for accesses
> > to unmapped addresses.
> > 
> > The domain flag is general but it's only implemented for ARM for now.
> > 
> > Signed-off-by: Edgar E. Iglesias 
> > ---
> >   tools/libs/light/libxl_arm.c  |  3 +++
> >   xen/arch/arm/dom0less-build.c |  3 +++
> >   xen/arch/arm/domain.c         |  3 ++-
> >   xen/arch/arm/domain_build.c   |  3 ++-
> >   xen/arch/arm/io.c             | 37 +++++++++++++++++++++++++++++++++--
> >   xen/common/domain.c           |  3 ++-
> >   xen/include/public/domctl.h   |  4 +++-
> >   7 files changed, 50 insertions(+), 6 deletions(-)
> > 
> > diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
> > index 75c811053c..9530996e72 100644
> > --- a/tools/libs/light/libxl_arm.c
> > +++ b/tools/libs/light/libxl_arm.c
> > @@ -233,6 +233,9 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
> >           config->arch.sve_vl = d_config->b_info.arch_arm.sve_vl / 128U;
> >       }
> > +    /* Trap accesses to unmapped areas. */
> > +    config->flags |= XEN_DOMCTL_CDF_trap_unmapped_accesses;
> > +
> >       return 0;
> >   }
> > diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
> > index a49764f0ad..a4e0a33632 100644
> > --- a/xen/arch/arm/dom0less-build.c
> > +++ b/xen/arch/arm/dom0less-build.c
> > @@ -343,6 +343,9 @@ void __init arch_create_domUs(struct dt_device_node *node,
> >           panic("'sve' property found, but CONFIG_ARM64_SVE not selected\n");
> >   #endif
> >       }
> > +
> > +    /* Trap accesses to unmapped areas. */
> > +    d_cfg->flags |= XEN_DOMCTL_CDF_trap_unmapped_accesses;
> >   }
> >   int __init init_intc_phandle(struct kernel_info *kinfo, const char *name,
> > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> > index 45aeb8bddc..be58a23dd7 100644
> > --- a/xen/arch/arm/domain.c
> > +++ b/xen/arch/arm/domain.c
> > @@ -612,7 +612,8 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
> >       unsigned int max_vcpus;
> >       unsigned int flags_required = (XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap);
> >       unsigned int flags_optional = (XEN_DOMCTL_CDF_iommu | XEN_DOMCTL_CDF_vpmu |
> > -                                   XEN_DOMCTL_CDF_xs_domain );
> > +                                   XEN_DOMCTL_CDF_xs_domain |
> > +                                   XEN_DOMCTL_CDF_trap_unmapped_accesses );
> 
> Just to double check, doesn't this mean the flag will be allowed on x86? If
> so, shouldn't we reject it in an arch?

Yes, I had initially thought I could block the flag for x86 in xl but I
didn't consider go/ocaml bindings nor Xen internal missconfig. In v4,
I'm adding a check in x86's arch_sanitise_domain_config().

Cheers,
Edgar


> 
> Cheers,
> 
> -- 
> Julien Grall
> 


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 12:50:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 12:50:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004336.1384068 (Exim 4.92)
	(envelope-from )
	id 1uMR5d-0002rS-DR; Tue, 03 Jun 2025 12:50:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004336.1384068; Tue, 03 Jun 2025 12:50: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 1uMR5d-0002rK-8x; Tue, 03 Jun 2025 12:50:01 +0000
Received: by outflank-mailman (input) for mailman id 1004336;
 Tue, 03 Jun 2025 12:49: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 1uMR5b-0002r0-OW
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 12:49:59 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on2061b.outbound.protection.outlook.com
 [2a01:111:f403:2415::61b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3ed1170c-4079-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 14:49:54 +0200 (CEST)
Received: from BY5PR13CA0026.namprd13.prod.outlook.com (2603:10b6:a03:180::39)
 by DS7PR12MB8322.namprd12.prod.outlook.com (2603:10b6:8:ed::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.37; Tue, 3 Jun
 2025 12:49:48 +0000
Received: from SJ5PEPF000001E8.namprd05.prod.outlook.com
 (2603:10b6:a03:180:cafe::31) by BY5PR13CA0026.outlook.office365.com
 (2603:10b6:a03:180::39) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Tue,
 3 Jun 2025 12:49:48 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ5PEPF000001E8.mail.protection.outlook.com (10.167.242.196) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Tue, 3 Jun 2025 12:49:47 +0000
Received: from localhost (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 Jun
 2025 07:49:47 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3ed1170c-4079-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=I6vCE3WSXb4T4etHk1yCwA9Mp2Xyccyhg8mfFIE9qtDymJJmzSHHukfjr+Sl+hsMTVEis+KNyZ/KsYOlK8ACLIqUDWhdGU2m1fiykkf+ksMwE16NpXuQF/gNVCmP72FierHzHLUYFJt8q7IVycpcrMNKp4LQpiEOcJWeeNsF5NS+2eEEXJYLTzoGTo2lzppqsje91SK9qtK3TSaZFrurJe8WSvrwEIEFhWBJgI3x89Ja8ipNOXzwEUgahFibo3pvSfgsb7SaZxiKFdHyS/x/MYdpjJUsYp5NrWqNY4S9B8zrK4APkixeFP30I5LpSu5S4ZoYD2JcbY79jD+q41JqTg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=eeH+6vE3mqu6gFB7KJtAW7zewFOjGEkZ3/AZ4fTWlOc=;
 b=VrwfpoSDzEX2Lq1YaqnCcpusOTEQ2VecO3KZD4ef/X/uff4t8SwNZ4E4FvXOk/OmQVjNlJ23pic6G/4vHA5saGimpN6KAujvZw8LQCBVzr89I1jXyvGoO6erlb8SaDmaA4gJrwtCzzT2eaieoByW2xDUDuUkb/STieNKwWMXWYwLc2JC8teSJkUEEBplyM0yDLBoDnqE9AKdsMuZShou8KI+i4L9uqLRiiVSdZHovttXiVqfDHXIiNUNqOrAqGSC8UgblktyWy/ZGfWicgGz498AKKdOQaxMH23es8P+X0x82FXIe8pb2Np+w9F884LG/zT0URXS5FHE9rJhssT5DQ==
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=eeH+6vE3mqu6gFB7KJtAW7zewFOjGEkZ3/AZ4fTWlOc=;
 b=leCnLys23jykV9xl7Ow/3UjdAMs6K8Hcm2XwZX1fiJHETA91KDo7tGzdMkCDxqEo3WEIl1ftY6j0dT7jXSYAlq2LTKKuJRxhB6qwHC4Fvk1sygfpxzCow9Rs5ggQILw2IKAtbnBP/Y0gS14JTbuHeMsH1RoRfWU2/dhy30xjbN4=
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
Date: Tue, 3 Jun 2025 14:49:45 +0200
From: "Edgar E. Iglesias" 
To: Julien Grall 
CC: "Edgar E. Iglesias" ,
	, ,
	, ,
	, , Anthony PERARD
	, Juergen Gross 
Subject: Re: [PATCH v3 3/5] tools/arm: Add the trap_unmapped_accesses xl
 config option
Message-ID: 
References: <20250530134559.1434255-1-edgar.iglesias@gmail.com>
 <20250530134559.1434255-4-edgar.iglesias@gmail.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/2.2.14+84 (2efcabc4) (2025-03-23)
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: SJ5PEPF000001E8:EE_|DS7PR12MB8322:EE_
X-MS-Office365-Filtering-Correlation-Id: df3ad9f7-a003-4533-ae06-08dda29d1f97
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?YAdSiOHsTkH0G8hVIR3XD/q7oHSAG49jRe2/XRK+PF/a6JEPNiRSygcpTCFc?=
 =?us-ascii?Q?5UOR2Ba628bqeY66JRYvNUXkvf8eXMhhH7kKn3cEme8ZcNcz4+DHdHiUfl6R?=
 =?us-ascii?Q?ZFpRw0s1k3iVmlxT8SAQARa+Fjpe3etIyBasQIhWQAr8PJEQAgrYNbZIUzof?=
 =?us-ascii?Q?A+Rq+mQjCOpCcTLI+dtwqT0Qiqc4PbkCotvXsaAVFrxxT0RCAvHO0HKLuEvL?=
 =?us-ascii?Q?AQLEcqeCzI1w6YWulMydG/PplJ3KmZbgxfy/2mrkIVVFg8jBO4616XlrFiRF?=
 =?us-ascii?Q?fsit83gN1jt5gCcia0ULWR3d6sME+UFiAGdqtj8m/7BuLAjarzIZ8ZRUjYDP?=
 =?us-ascii?Q?j8jXoWhgrfXvSUMTCcXTtE8I6Q10scq/C/RktxgibRibI6jc8VYtTOXzEX5g?=
 =?us-ascii?Q?smB10LGROm5yg/7hfV/fCrgQ3I8cfuR6FZAvuttFau5xMqa2H9E1OwbK/qSt?=
 =?us-ascii?Q?YwSi8l0EBmQr5dTijP+cPsHFMnFXQg3zLi0RhTCdWNbc+YNaNCbadT/XcYiN?=
 =?us-ascii?Q?5YoYmg2RMIdI9qXaHM2eVjLIYjVrTealz7Bce4p6KeSIOYu5A/tKPKcquIGW?=
 =?us-ascii?Q?GmUo1dXcmD7cgI1WK/KObnzDSnjb43JBZjv2jMrOW1WIs0PSDdz3fNUVZq2s?=
 =?us-ascii?Q?vAqL61kyEDatuPfdD3E7EVMUVtM3MGbPsTRyMtO1nec2eIZ2fAOFJogKu95y?=
 =?us-ascii?Q?bwDnBg3e+5qYnXbtTxoD7aHQH7lAHvr/u5c2KteJpfgomArXVZIWxfpA8qsk?=
 =?us-ascii?Q?xie9g+IvehYTWaj28y1rJpyjDqLT+ZXwfDk1VCjYPssaQ+Bmm/uUzu8sND/5?=
 =?us-ascii?Q?CeK8dqV++fLDZRQLEXbamo/SevZ/YCmhTAVtYBN4xwhFB5pU0/NDncmmR87N?=
 =?us-ascii?Q?gmcu7rgpdFK6A43JD8W5F1qyv3ZoggCnRpkM/9j2FzSfuyKuiusK+5t6+hja?=
 =?us-ascii?Q?RbRSTcY0s8d7CSu79O3P9F+1smUCYJH1Tdhr0hQBk3Gi29hEenJwgnbENf22?=
 =?us-ascii?Q?jWvoxC32aPdKc3fGjgaCnU2a4phBZbRL3mXWYSYVCJjoa4ZDBrfM9hZb1U0F?=
 =?us-ascii?Q?Ja3IGnyqiMdNpBZl6wzIzJR2JcRCfnYuQZRU8DSVIlcbBnMOm3QyW9wrFLCI?=
 =?us-ascii?Q?hGBJj7PUjcw1NxAwBkCcEA+bbWHNU3gUWy7GEbESMeX6LTu8+z61bVZQ5ymh?=
 =?us-ascii?Q?i4MMfDjqoCqNNYBEPrbTFeWNFWMsLOvcIARbe6TNH674UA8VOsfxiWoifUrK?=
 =?us-ascii?Q?p6uMu5jz5SOSV16OEYuz5D3yiJvZnHSGadrl5Fi6BVtn2yzgK7DNeHfMunml?=
 =?us-ascii?Q?xS/P6BAtCFO0h6TZkc12Y1ANnRHxM9ePUqjlLBjlGCf3IYkJKhD/qFU8kNpe?=
 =?us-ascii?Q?XYjm4bAis4y9ZZ4zrnv4zogSRUgwY7ADHspPzdRwNaMasijeYgrH5RCyKKDJ?=
 =?us-ascii?Q?T0LLHdZgJto0FPkOnz41PSTVfpFoZmpzjjHluvY0oj95BtgJa8ZKxJ3+UcHj?=
 =?us-ascii?Q?LTXdX9RU8p1ARt5tPdCAoFHakgFA1uKrdsTP?=
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 Jun 2025 12:49:47.8831
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: df3ad9f7-a003-4533-ae06-08dda29d1f97
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:
	SJ5PEPF000001E8.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB8322

On Tue, Jun 03, 2025 at 10:34:53AM +0100, Julien Grall wrote:
> Hi Edgar,
> 
> On 30/05/2025 14:45, Edgar E. Iglesias wrote:
> > @@ -1714,6 +1711,9 @@ int libxl__arch_domain_build_info_setdefault(libxl__gc *gc,
> >       /* ACPI is disabled by default */
> >       libxl_defbool_setdefault(&b_info->acpi, false);
> > +    /* Trapping of unmapped accesses enabled by default.  */
> > +    libxl_defbool_setdefault(&b_info->trap_unmapped_accesses, true);
> > +
> >       /* Sanitise SVE parameter */
> >       if (b_info->arch_arm.sve_vl) {
> >           unsigned int max_sve_vl =
> > diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_create.c
> > index e03599ea99..38770eea5b 100644
> > --- a/tools/libs/light/libxl_create.c
> > +++ b/tools/libs/light/libxl_create.c
> > @@ -667,6 +667,9 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
> >           if (libxl_defbool_val(b_info->vpmu))
> >               create.flags |= XEN_DOMCTL_CDF_vpmu;
> > +        if (libxl_defbool_val(b_info->trap_unmapped_accesses))
> > +            create.flags |= XEN_DOMCTL_CDF_trap_unmapped_accesses;
> > +
> >           assert(info->passthrough != LIBXL_PASSTHROUGH_DEFAULT);
> >           LOG(DETAIL, "passthrough: %s",
> >               libxl_passthrough_to_string(info->passthrough));
> > diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl
> > index 9bb2969931..e33785c661 100644
> > --- a/tools/libs/light/libxl_types.idl
> > +++ b/tools/libs/light/libxl_types.idl
> > @@ -736,6 +736,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
> >       ("vmtrace_buf_kb", integer),
> >       ("vpmu", libxl_defbool),
> > +    ("trap_unmapped_accesses", libxl_defbool),
> 
> I think you want to add a LIBXL_HAVE in tools/include/libxl.h for this new
> field.

Thanks, adding it in v4.


> 
> Cheers,
> 
> -- 
> Julien Grall
> 


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 12:52:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 12:52:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004348.1384077 (Exim 4.92)
	(envelope-from )
	id 1uMR7t-0004NZ-Qh; Tue, 03 Jun 2025 12:52:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004348.1384077; Tue, 03 Jun 2025 12:52:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMR7t-0004NS-OB; Tue, 03 Jun 2025 12:52:21 +0000
Received: by outflank-mailman (input) for mailman id 1004348;
 Tue, 03 Jun 2025 12:52: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 1uMR7r-0004NK-SM
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 12:52:19 +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 9540f2e4-4079-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 14:52:18 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-451d54214adso22204515e9.3
 for ; Tue, 03 Jun 2025 05:52:18 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a4efe6ca46sm18586919f8f.31.2025.06.03.05.52.17
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 03 Jun 2025 05:52:17 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9540f2e4-4079-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748955138; x=1749559938; 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=EjLawBkFdZCmVWxeleotfU9HS3zYkrhDKjmwvUJc1RI=;
        b=Z54Zb7jo+ROHSaK/CPdecyHh9z8OCqh6AF4+uq+aJgdFYCZkjb0+xZJbEveiBz1CMy
         vPW2WudUWVJOYfbgDVUWNJlS538nEAwIoSYw47BUULaZEUKq8Ef6U26SJs/49dgWmOPM
         xINsw6prUNd9k2qUfWHE+SlZAaMu2T41aKv0g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748955138; x=1749559938;
        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=EjLawBkFdZCmVWxeleotfU9HS3zYkrhDKjmwvUJc1RI=;
        b=oYNWI5NrJkv2ueZTyr1HQF/yi1u4aVrholxdq7nhEduO1xz7DkdhLCjVT3wTN1IU3y
         +6z0YGzSX9puw3gReoSOePJB2Mq1BTgnKfCHkYDxuj5z2gl8fW/qky5RG4zW22FR4zkR
         G5c4wsIxPEdCqqIsjUS9rxE0amU1TnsG1FY+AvtYiIy1OBe4XgGZOVZkBsUHCfZmexUQ
         jtBuljaUuobZBHbypjVkIXtzANb5J8Wj8hncE+c2MTWUInh2LCSNC9aHfIMzBxqtZ+Bm
         YqYR5KHPuEdwwJzWPY3BF7iV+p7BqzjbfoewcB+54R2+pM1h/O2YbINJPoIgpxy6TK83
         qz/A==
X-Gm-Message-State: AOJu0Yy+Er898lV7s0M5b9i0TF7qg17CnBz0CyVLdymoEqakNtSjNHWF
	KruKqaBeHJuimyMNNhOhcf4Q6exfiM8mz9Hdv4ATSF/EfFKENgPYBR3cLP9lCgErjFcRkMiIJ1C
	NrV+c
X-Gm-Gg: ASbGncvuFK16HcpFwns/kcy6hhIqdqEqKAieiZ7XiIadc8vU/lm4Ji9z9u4L7NjMcR+
	wijX/DRDLiYlj8IUoQVloX0yrlRqyuBOCytl/hgAc4iQm4p6bFvKiy3Q7/N0ZHWYnAxlmqLzUdZ
	NGZRdwXIgAak3EGHfkF1ivD4oNsbrXdW2kwpDSV+fd0XJ4FbZ51dAR1R12FL2UACmFY1vtskwGP
	X6CuDYQWrv59ovVGD+t18UICa19/lshvIkB1t14i5/gAUB0yu2Nni77YQIz0uBtxQIFClNPt2hy
	e3DwCcCAywX16ffFK3Fili39tOD5tIuCmw+ZmuDQqv18IlUA5BM87tA2RdNIh6DcI9pC2ECpKlg
	CUpUIQfMRqS7VcfxnYggzt0iZ
X-Google-Smtp-Source: AGHT+IFEms/kCWiCF0W/m/TTgfzKxA40SrJRUxWn9pZdxenYIibsBX2Yp5kC1Jib67+egtOccdmxHQ==
X-Received: by 2002:adf:f34a:0:b0:3a4:f8e9:cee0 with SMTP id ffacd0b85a97d-3a4f8e9cf5cmr10768484f8f.40.1748955138087;
        Tue, 03 Jun 2025 05:52:18 -0700 (PDT)
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 
Subject: [PATCH] xen/kernel: Move parse_params() back into __init
Date: Tue,  3 Jun 2025 13:52:15 +0100
Message-Id: <20250603125215.2716132-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

It's non-init caller was dropped in Xen 4.14

No functional change.

Fixes: 02e9a9cf2095 ("xen: remove XEN_SYSCTL_set_parameter support")
Signed-off-by: Andrew Cooper 
---
CC: Anthony PERARD 
CC: Michal Orzel 
CC: Jan Beulich 
CC: Julien Grall 
CC: Roger Pau Monné 
CC: Stefano Stabellini 

Found while reviewing the lockdown series, where an __init callee was added.

It appears that GCC has inlined it into it's single caller (which is __init),
and not emitted a non-__init form.
---
 xen/common/kernel.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 8b63ca55f14f..5be668ba855a 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -67,8 +67,9 @@ static int assign_integer_param(const struct kernel_param *param, uint64_t val)
     return 0;
 }
 
-static int parse_params(const char *cmdline, const struct kernel_param *start,
-                        const struct kernel_param *end)
+static int __init parse_params(
+    const char *cmdline, const struct kernel_param *start,
+    const struct kernel_param *end)
 {
     char opt[MAX_PARAM_SIZE], *optval, *optkey, *q;
     const char *p = cmdline, *key;

base-commit: 2c4a3d688943b2034756859844b8337a5a97ce07
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 13:00:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 13:00:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004390.1384088 (Exim 4.92)
	(envelope-from )
	id 1uMRFI-0005FW-J0; Tue, 03 Jun 2025 13:00:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004390.1384088; Tue, 03 Jun 2025 13:00:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMRFI-0005FP-F7; Tue, 03 Jun 2025 13:00:00 +0000
Received: by outflank-mailman (input) for mailman id 1004390;
 Tue, 03 Jun 2025 12:59: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 1uMRFG-0005EW-U7
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 12:59:58 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20612.outbound.protection.outlook.com
 [2a01:111:f403:2009::612])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a506bb9b-407a-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 14:59:56 +0200 (CEST)
Received: from BN9PR03CA0571.namprd03.prod.outlook.com (2603:10b6:408:10d::6)
 by CH3PR12MB9429.namprd12.prod.outlook.com (2603:10b6:610:1c9::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.33; Tue, 3 Jun
 2025 12:59:51 +0000
Received: from BN1PEPF00006000.namprd05.prod.outlook.com
 (2603:10b6:408:10d:cafe::39) by BN9PR03CA0571.outlook.office365.com
 (2603:10b6:408:10d::6) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Tue,
 3 Jun 2025 12:59:51 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN1PEPF00006000.mail.protection.outlook.com (10.167.243.232) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Tue, 3 Jun 2025 12:59:51 +0000
Received: from localhost (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 Jun
 2025 07:59:50 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a506bb9b-407a-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=YPZwajjFx39L0eaZ0CwdLZ02AV6SjOrarltq7bE7K7VP1dc/ORVPeaYT20ZbnpwFgUaj7agABOsZrJDyPduTLkOspE0Iv4L+/iqP6Vdsqu2X+R/zh2DTfUR6ncjJXJj0odRmJbVe831niInqTh16HgFP7Y+TkiY2y+rSHAW3vQIzJDYrxrueeIa2qcDhMpCb0AWthLAhUXV0Wdfb4yCXns2qjMDvqjLmfS6ZRsKwfTZdUYSjkWkkAJdhbT3LAaGiHaapJ1B+PZehhPYxc4hpKuzOLgsK9GeTU4hZPxyJB6GLNsZhmcMk98D+e8N+QvR4iyrRElayKq1jiOJTdtgW2Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=gDknBqx6r+bD0zEt/g92j+dwpHxuazo88oXLlU1/jfU=;
 b=inEI3BB7Z08HgHWnAeV3UsNZeSRvWfzY+JKlYPwU7pDsv07bxXgWojxNLsGui/FZ6RJZ1TI3/RITNx5FpMj8Xe3mG/4ykfD/RBuZN366IbtYaFWaOUqbaGcatPayQzLRj5dIOess3t/iwxmIwaZJAMSXhCUAXC3GSDP0SZ1cyg/bwLpiE4jwwPfmQxmlXWLxIDMcHsOreMOj+UOFcAUhfA1j3VCSZKdceDYFeN7CM/PqQMgeCDu11F0oBzZ18P9BKyWD5DnjMrefIAnoNW43nEnRANzTdIbPMN7uhsBFlWJ3aa5ueRyBkT8Iu1P8ytK5S0hH5WakCQYKxdUWmjhYDQ==
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=gDknBqx6r+bD0zEt/g92j+dwpHxuazo88oXLlU1/jfU=;
 b=cTlqYStsSvvCs8YuOqgtVxL8Wt14EwPvDtyGL6z7CBVJeq7olsla3tyHcNa7YcyQDGS+xpuBD5u+6UeIQIhNOg2oS2KM1S1PQntd0/my/6HvXXNtqD9KuOY1PD9lXrreuc/FgloabCMNxL4W2fVoZ5YwTCeXiC1qAXZKeG7iTQ0=
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
Date: Tue, 3 Jun 2025 14:59:49 +0200
From: "Edgar E. Iglesias" 
To: Stefano Stabellini 
CC: Julien Grall , "Edgar E. Iglesias"
	, ,
	, ,
	, 
Subject: Re: [PATCH v3 2/5] xen/arm: dom0less: Add trap-unmapped-accesses
Message-ID: 
References: <20250530134559.1434255-1-edgar.iglesias@gmail.com>
 <20250530134559.1434255-3-edgar.iglesias@gmail.com>
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/2.2.14+84 (2efcabc4) (2025-03-23)
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: BN1PEPF00006000:EE_|CH3PR12MB9429:EE_
X-MS-Office365-Filtering-Correlation-Id: 784a01e8-40cb-418e-517a-08dda29e8751
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?vOfr4gXWgi0qjFuaItP7Ywfp4BL1fv1DMGHXITGtWUIeVmZTbybWh9zNnOkf?=
 =?us-ascii?Q?h82L0dgNOODpNNLeRMMG+urTX5E0k3k0FEwRgqA4KxV7J6pzQ26o7Hh+sHrj?=
 =?us-ascii?Q?0XSArb70RjWzKUtrYw4j65O6Byt+VTX14G9AZE3Vzg6b2CK9FpwbO7gIf8kv?=
 =?us-ascii?Q?x/m6D/+/6VNMtxxAjkA8p5iio0Ub6fNM1U//DqkKyY5mWC912F2HhdCYCG5V?=
 =?us-ascii?Q?ql1is5ZgnaTUxfWzfv5EwmXZbZS49B9V49NhZTF17UXwfftM43tVVP0qGyg2?=
 =?us-ascii?Q?ZUX+rkXLGadXnHy8lDIpmIxVR+IyTBRHawG+GX0GqN1HgFpCd+uj/tNGdhgl?=
 =?us-ascii?Q?by7KnWIC94TSQ09nvwyTS59RlbZ70MGmCKtRkHYAsSKhNjmgbO7u/ADER1fj?=
 =?us-ascii?Q?SbFAxWCCe72P8BIdKmsxkq5WYyjU9l0uOke0x2TakjYlyVWsg+Uw46jWz0j6?=
 =?us-ascii?Q?3Hvhho6qP84zG9rdmozPD1Ls85A5DdoTSEXWbeSU69YJPCHfj2+cKaUTasHh?=
 =?us-ascii?Q?axMBo41I592EJYx09+2VYA1mkt6Cg6ii7s+ZW6+dACKEEWgguJpr37e9E2b1?=
 =?us-ascii?Q?ezwSB7SEXl4GP/HMzCJE/FacUVXu5XKAr1qFk2Ectgn9idAZOAD854PUmUIZ?=
 =?us-ascii?Q?bPBiXLPy2pvbI9ezxzTwLrJ25bsVv+I9kkKCne5fIe11wDBF4PxesMcIbJWK?=
 =?us-ascii?Q?vungurhv/BFq1/781GQ3P7vNgKnnrCSlNn41rkcOucNr/0zDps0BGvpgVfow?=
 =?us-ascii?Q?qqHDk1cPjOdNzORXj5RQOP4fUAdi3mikop4hj86rIE0oQRNlgChBIIuGbxDB?=
 =?us-ascii?Q?RPaj4jCctjyHQiZbGz3TTeMD5ScZ4OLNjCv3vQNAibfqogbL8KbzJ0hSBEeb?=
 =?us-ascii?Q?yCqui//IyhKn39huDgfDKYZ9Rs0TOa8FDPDxSgyAX3eUYC0Vg48YFV6HvMH0?=
 =?us-ascii?Q?i97dD82Ozuowl7lCOHJWxTQkdM1bG4COdHn6rElUBiR6iy7O/Nc1t6ueMACd?=
 =?us-ascii?Q?JN+56i2Jz72LWOnDsn/c5EMuz2oDY4D8yulfTlviHZbuZbQfE4/+dzkDwLAt?=
 =?us-ascii?Q?a76oCkjg/TXyF+Au8e0UvXXpo9UIzeDeye1J5n7WZ77jcAdGXMPJ4v0TXL46?=
 =?us-ascii?Q?sTEonQiQlJhGHS44BVR9f0VFWfYh6I/bYxQj7/pUjoLvN8FJomq8oVOmJ6lA?=
 =?us-ascii?Q?5Gzdsfm1GXFb4uFuVqJkxzUPS8GkIF8RvQUmrpVbfpnZlXrS8NjlcLU8He1Z?=
 =?us-ascii?Q?lVqNuQmAfwBmVHe38+Jc8WEmmShEgL881gbVauvM/BWPhFif4fCdW5f0Zett?=
 =?us-ascii?Q?/jl2HITx34ibdzx5R0R4B9czU2qCymmQ6Y+71tNbBNvri2VXwHU39UBQPpOt?=
 =?us-ascii?Q?ly8p0Mnc+htzFLgN+zMo73ZkJnHZmqOTkULQ2tulGcS/DWfwl8fAPl4yYKK/?=
 =?us-ascii?Q?2NW2IEVp4JDku7j8BdeGCUgC5s4MmEv+0POMKzZfaFxoLQzBftzwz1slMDsp?=
 =?us-ascii?Q?2RFPJgqYZckq+cxh3klvMUtRSFyboAn4+jCK?=
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: 03 Jun 2025 12:59:51.4833
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 784a01e8-40cb-418e-517a-08dda29e8751
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:
	BN1PEPF00006000.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB9429

On Mon, Jun 02, 2025 at 03:57:28PM -0700, Stefano Stabellini wrote:
> On Mon, 2 Jun 2025, Julien Grall wrote:
> > Hi,
> > 
> > On 02/06/2025 23:36, Stefano Stabellini wrote:
> > > On Fri, 30 May 2025, Edgar E. Iglesias wrote:
> > > > From: "Edgar E. Iglesias" 
> > > > 
> > > > Add the trap-unmapped-accesses per-domain fdt property.
> > > > 
> > > > Signed-off-by: Edgar E. Iglesias 
> > > > ---
> > > >   docs/misc/arm/device-tree/booting.txt | 10 ++++++++++
> > > >   xen/arch/arm/dom0less-build.c         |  9 ++++++++-
> > > >   2 files changed, 18 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/docs/misc/arm/device-tree/booting.txt
> > > > b/docs/misc/arm/device-tree/booting.txt
> > > > index 59fa96a82e..9add6440de 100644
> > > > --- a/docs/misc/arm/device-tree/booting.txt
> > > > +++ b/docs/misc/arm/device-tree/booting.txt
> > > > @@ -225,6 +225,16 @@ with the following properties:
> > > >       option is provided with a non zero value, but the platform doesn't
> > > > support
> > > >       SVE.
> > > >   +- trap-unmapped-accesses
> > > > +
> > > > +    Optional. An integer that configures handling of accesses to unmapped
> > > > +    address ranges.
> > > > +    If set to 0, guest accesses will read all bits as ones, e.g
> > > > 0xFFFFFFFF
> > > > +    for a 32bit access and writes will be ignored.
> > > > +    If set to 1, guest accesses will trap.
> > > > +
> > > > +    This option is only implemented for ARM where the default is 1.
> > > 
> > > Please expand it to: "This option is only implemented for ARM where the
> > > default is 1 when trap-unmapped-accesses is absent."
> > 
> > I am confused. The document is part of "docs/misc/arm" and some options like
> > "sve" are Arm specific. We don't mention this is Arm only because the
> > documention is Arm specific.
> > 
> > I know that RISC-V is starting to share the bindings. So really (part of) the
> > documentation should be moved to common. Until then, I think it is misleading
> > to add "is only implemented for ARM".
> 
> Yes you are right. Maybe Oleksii or Alejandro can fix this, moving this
> file to common.
> 
> For this smaller patch series, I would remove the "is only implemented
> for ARM".

Thanks, I've changed that line to:
"The default is 1 when trap-unmapped-accesses is absent."

Cheers,
Edgar


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 13:04:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 13:04:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004397.1384098 (Exim 4.92)
	(envelope-from )
	id 1uMRJq-0006ze-0f; Tue, 03 Jun 2025 13:04:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004397.1384098; Tue, 03 Jun 2025 13:04: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 1uMRJp-0006zX-Tr; Tue, 03 Jun 2025 13:04:41 +0000
Received: by outflank-mailman (input) for mailman id 1004397;
 Tue, 03 Jun 2025 13:04: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 1uMRJp-0006zO-Is
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 13:04: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 4f54a3da-407b-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 15:04:40 +0200 (CEST)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-43ea40a6e98so61562025e9.1
 for ; Tue, 03 Jun 2025 06:04:40 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a4efe754acsm18488654f8f.59.2025.06.03.06.04.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 03 Jun 2025 06:04:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4f54a3da-407b-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748955880; x=1749560680; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=He6rdsQGJzXm42/cfMSDjAoJdTiTVdxbtR5Bhkdesuw=;
        b=jyc9GU3pW9ItWF21MmrFmlveeZ2xvNnFlLqXEiYhEbGq6jvAnHi8bPRMV50B+RZPp+
         DLX7vHVwUgI+Y8xDdkjfT3jmAQ3ETAfHM5NnHpSY86x5+JwkIf6Ggx6sV+mRqlHDM/fF
         UkMdLLmqpSG5YPkCpvBmyQR/Bp/Du1mKlp86Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748955880; x=1749560680;
        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=He6rdsQGJzXm42/cfMSDjAoJdTiTVdxbtR5Bhkdesuw=;
        b=VLN17AGJkBBEYqPCDEfzbXCbBufrasI7cAmw+k/q5Dbh3I0IjF2cuK5K7s/fvr9mKa
         MDGYD4idgUoAg3gb6bX8f+X3/UnN0aX16Q2wXH1t3+hklVPD/wvGSJr5DvVSiZCl5nsE
         X3LVl7qYlbZnR1bv88EFEE2fz/gnmZWJZ63dju5yqAzcWmQUaa0ZvvP+eEPcbtQqacu0
         lPm4SPlB9pxHuIKdhiVIzIZCCxh6U3adw18G2QwDIr8+WPNeg2MT2PiXXQrejC/EEcMj
         BNcx0oDKw63YlPbquUvFIaM4BTgcrerw1F++qT0Z1vPZJSmdlI/nvw/YGg777ubYaAcf
         S31w==
X-Forwarded-Encrypted: i=1; AJvYcCUHIP6hOlEkf1PF/Y7WpByPG4JebWLs+eGGlVyt6iJTq3arxquGzRoiwv01AN1JzkpH5YDnDNWGrHA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyL6S4OV06pPonTmPQntyBpUurFk2ZthUGTkhJlIRCZlxEfso0y
	TFX6UKgKw4O0PrLq/d0npbSWisQ2H9a39+PiOtt/WOltXPoFL0OL+BIiWdVJ0zR8oh4=
X-Gm-Gg: ASbGncs7ZNFHLAHnJLGuG9mLU09g6bXuDBiyKraNAtcc1DkTtctMHgq/AR56H+MJepp
	T+9Wt/MgCRQiwI1+D0EDI8pMbZWvfKV4CBmrQqJ6I/rGD6QCGRud4kQrKFw5hhohws+9LQ9pUod
	P2MasHEKodaSfn2vQCPAClubzuAkmrpMdFOPstUzlS088YpCFdWQ7lMwR07KrstamkOGOhrexow
	v1gsiMh9sxhrWNwAMCAohtaxrG78ZnudCy8m3ogvLMuJn3vppgcNrgtT1o6xSFHpM082yRLWDHi
	tqViGceC3tiwz/aag5izDRS2oL8x7kdX5bW5yLL0jY/BdNnAY/iH/p8QQxJUsYGPa2FHdTvAo9P
	CaR8IoPjSCaNJ7zgVvxnOjfVIqto=
X-Google-Smtp-Source: AGHT+IHZ3aXE7UbbQwOONxvPgqMjjzIUBxo14087QCQZk7Dmd9j8UaKPtZPn5I0S4VzeTP2PT002jw==
X-Received: by 2002:a05:600c:871b:b0:43c:efed:733e with SMTP id 5b1f17b1804b1-450d65306dfmr157962995e9.14.1748955879802;
        Tue, 03 Jun 2025 06:04:39 -0700 (PDT)
Message-ID: <1800c6aa-b3de-418b-967f-d7e7de932fe4@citrix.com>
Date: Tue, 3 Jun 2025 14:04:38 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 7/9] CI: Use CDATA avoid the need to escape tests
 outputs
To: Anthony PERARD , xen-devel@lists.xenproject.org
Cc: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , Anthony PERARD
 , Doug Goldstein ,
 Stefano Stabellini 
References: <20250603124222.52057-1-anthony@xenproject.org>
 <20250603124222.52057-8-anthony@xenproject.org>
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: <20250603124222.52057-8-anthony@xenproject.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 03/06/2025 1:42 pm, Anthony PERARD wrote:
> diff --git a/automation/scripts/run-tools-tests b/automation/scripts/run-tools-tests
> index 695ed77e46..852c1cfbcf 100755
> --- a/automation/scripts/run-tools-tests
> +++ b/automation/scripts/run-tools-tests
> @@ -25,9 +25,9 @@ for f in "$1"/*; do
>          echo "FAILED: $f"
>          failed+=" $f"
>          printf '   \n' "$f" "$ret" >> "$xml_out"
> -        # TODO: could use xml escaping... but current tests seems to
> -        # produce sane output
> +        printf '> "$xml_out"
>          cat /tmp/out >> "$xml_out"
> +        printf ']]>' >> "$xml_out"

I think you want a \n on this printf.

I'd also suggest leaving a TODO for "escape ]]> if necessary".

Otherwise, Reviewed-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 13:07:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 13:07:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004403.1384107 (Exim 4.92)
	(envelope-from )
	id 1uMRMD-0007Xy-Br; Tue, 03 Jun 2025 13:07:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004403.1384107; Tue, 03 Jun 2025 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 1uMRMD-0007Xr-95; Tue, 03 Jun 2025 13:07:09 +0000
Received: by outflank-mailman (input) for mailman id 1004403;
 Tue, 03 Jun 2025 13:07: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 1uMRMC-0007Xl-DE
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 13:07:08 +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 a6f6a35a-407b-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 15:07:07 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3a367ec7840so3867237f8f.2
 for ; Tue, 03 Jun 2025 06:07:07 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-450d7f8f1adsm163686335e9.7.2025.06.03.06.07.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 03 Jun 2025 06:07:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a6f6a35a-407b-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748956027; x=1749560827; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=FngO5pKUv6NzNJwHYN5lAHIoRoCkz+A9NGjhJrIfxq8=;
        b=N6otXvrYW/i1BK2PlzaGCo4yB2OJ9hPNJYzdIjsDXCgqeI0N8ToWw/AsDTLRHww9eF
         eGESZQDU4KZMIpKmDrz+dJ/XieFmqNlTXgmZFAsAADM1nvq3l+FNEy2/SR8lnkUV2Ers
         IzDZM5f3bu91tmv9p+/Rj66PFJLSIYqPWzUUo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748956027; x=1749560827;
        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=FngO5pKUv6NzNJwHYN5lAHIoRoCkz+A9NGjhJrIfxq8=;
        b=MSgqRUKavNevhT/s0yabCBhp+iGqs/BIpRbCjRX9qo3aiuVqz4q9U/Ut2gYbmcW3wz
         EGV8HWZx13XuQRD/MetQWOev1N2aZU0yeshmeCLuS0YSQgCbU1wdb97cHlnyt9wrfKvs
         BitcAQfKWYiaQWLbQVeQP6w/6b13Llyupyh678iScXRka/apjnQA/mTf89YlJy9zEMtP
         mulyxSbuoFD9x+IXs38A5zalatepolLuiqjAKyKCrTYZ/fsYjFc3nqAM7CTZpuf8fn5W
         4BFpq36z62MkDtQcgEAOHcCawfL9kvgyQsHT3ENdgdfuLlVlgbT6XzjcE5SPMS/0oj4d
         Re1Q==
X-Forwarded-Encrypted: i=1; AJvYcCXtwAB6rh5lnP0VTFgxbNT3doz3CI0l74NrS6afYsEeeIEpI0D6UseEFrjJjyZHGlJtrQKA9zliv1s=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyrRzaTF4bt6sht+bQ/O5w92emVoX/Y9ObROtTSzx6gZQjou3LV
	cfDru3B3fF6A/jZK11eM/ksz17y6tb3ZKDrr9A75eifu18SL+mGko8lUC0IeKRGaSqw=
X-Gm-Gg: ASbGncu1K7gJqm5ZGBffJB6eykKybSr99jD99Ban2P7L94lPOmh4im7NQNqFmMR22wY
	QQvTUSAuV3VSFJDiDVA975j2BPs6+oz/Q8elnwz9uqMV5gFco2lvZ8VzKlAAiTf4aveQHAUhgQ3
	tz4Nn1dZLfchSksjMcnUF1GLXt0BPxIoVYNgBvaYU0Kd/fdfNm+HmBMG5/3RqEsv4a+hvw4roVR
	4dQLoyT+H7KZodz3U935sGAR44QrMkX/djY1Lb3QnFD+e/nYDEBn5DFKre5C5WtmFM96YbtsFcb
	9QyE1Cy9d5MZKHN71ilYXnlrpYOVLIGO9FljgliKA/lY+lJWODU7brw0+75b0+a7pfNkHPaaTe5
	yBs8yThnibwRHbYbb7ZbBPOV6Lgg=
X-Google-Smtp-Source: AGHT+IFI6JSvm4b5n6po8K43DCmmCp2oC0SuzxYYiG1EGMT0P1mD04Jfv9A2MGtELK+60oLYrUmMrA==
X-Received: by 2002:a05:6000:18af:b0:3a4:efc3:88d3 with SMTP id ffacd0b85a97d-3a4f89ddd87mr12902257f8f.28.1748956026807;
        Tue, 03 Jun 2025 06:07:06 -0700 (PDT)
Message-ID: <7d2a09db-2379-4dab-ae9b-cc4fb0ed11cd@citrix.com>
Date: Tue, 3 Jun 2025 14:07:05 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 2/9] tools/tests: Fix return value of test-rangeset
To: Anthony PERARD , xen-devel@lists.xenproject.org
Cc: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , Anthony PERARD 
References: <20250603124222.52057-1-anthony@xenproject.org>
 <20250603124222.52057-3-anthony@xenproject.org>
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: <20250603124222.52057-3-anthony@xenproject.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 03/06/2025 1:42 pm, Anthony PERARD wrote:
> From: Anthony PERARD 
>
> Otherwise, failed tests are ignored by automated test.

Fixes 7bf777b42cad

> Signed-off-by: Anthony PERARD 

Reviewed-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 13:09:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 13:09:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004413.1384117 (Exim 4.92)
	(envelope-from )
	id 1uMROu-0008Ax-SY; Tue, 03 Jun 2025 13:09:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004413.1384117; Tue, 03 Jun 2025 13:09: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 1uMROu-0008Aq-Pe; Tue, 03 Jun 2025 13:09:56 +0000
Received: by outflank-mailman (input) for mailman id 1004413;
 Tue, 03 Jun 2025 13:09: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 1uMROt-0008Ae-9U
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 13:09:55 +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 098fc0f8-407c-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 15:09:53 +0200 (CEST)
Received: from phl-compute-12.internal (phl-compute-12.phl.internal
 [10.202.2.52])
 by mailfout.stl.internal (Postfix) with ESMTP id 432BA1140181;
 Tue,  3 Jun 2025 09:09:52 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-12.internal (MEProxy); Tue, 03 Jun 2025 09:09:52 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 3 Jun 2025 09:09:51 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 098fc0f8-407c-11f0-a300-13f23c93f187
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=1748956192;
	 x=1749042592; bh=+58UHdLqAT2Wlb0AI7vyz1T675DG2Tu3VLsBD8GaoY8=; b=
	XLaSkVBFvRGLiWVxft9aC944LoRbW45iSxfuaVpBNeTZ/G0xjgnWv6ywRvj2QZTB
	XodZpaSNKjndn/t2Odgx6B28xowh9h3U7PeL6btiZ8LGY85ZoLO1dK0V+bTo7Wgs
	R2pG+3AzeqHKSi/ICmTOk9dLqZxNTrH0R4hArownohxo8dWQpj6D8uJuXZ5xJRuQ
	Xcq6xRd4qX4oxHIWf6KYpmCV2NdTuNe3BCZGKwq5uSvPLVbtpWNsmBB3txpp4IRS
	vMMIhLDLqjdE4fgshwpzRKQpFtz0mGAvtm2FICotWsGFFhF0PchA8Xaz6CoyTIbd
	bT9wZhM7BZarL+fMdrp2EQ==
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=
	1748956192; x=1749042592; bh=+58UHdLqAT2Wlb0AI7vyz1T675DG2Tu3VLs
	BD8GaoY8=; b=hSN8jUgaPzga/rQql9/9EyQ/gy0NDZlb+6jpNN+OjdQElVPO6+t
	PCmA0lGa6Q22X05ghk5nnWVJByO9rZAbemZgGH0+6O+3qyfhB1tDmmBdDwGun4KE
	Tzady2pYOvdBitoetoJrEKL3QgTSPrJ8KyXY6UcRWtGtglriE+MPuMxjloZzE+dE
	r6/Px2sPdMbthbBZ898PAML81ImqjRwrK/GDsLzeTYhySwmAFCr/FZAHwlOX1Iai
	h0OUsbeaScR0h8DJbiuswhPY9QdEgGK36jwFPAKXBord1zGB2WTW4crKrWYoYhOp
	rkJwulnyZuev/fbddYoy6RKtefIJ1fN3oRA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugdeffecutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr
    tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnth
    hsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecu
    hfhrohhmpeforghrvghkucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrg
    hrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffr
    rghtthgvrhhnpefgudelteefvefhfeehieetleeihfejhfeludevteetkeevtedtvdegue
    etfeejudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm
    pehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsg
    gprhgtphhtthhopeegpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehjsggvuhhl
    ihgthhesshhushgvrdgtohhmpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtsh
    drgigvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtoheprhhoshhsrdhlrghgvghrfigr
    lhhlsegtihhtrhhigidrtghomhdprhgtphhtthhopehkvghvihhnrdhlrghmphhishestg
    hlohhuugdrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Tue, 3 Jun 2025 15:09:48 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Jan Beulich 
Cc: xen-devel@lists.xenproject.org,
	Ross Lagerwall ,
	Kevin Lampis 
Subject: Re: [PATCH v2 3/3] Disallow most command-line options when lockdown
 mode is enabled
Message-ID: 
References: <20250602134656.3836280-1-kevin.lampis@cloud.com>
 <20250602134656.3836280-4-kevin.lampis@cloud.com>
 
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="OYPP6qUbWlcHD4Zh"
Content-Disposition: inline
In-Reply-To: 


--OYPP6qUbWlcHD4Zh
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 3 Jun 2025 15:09:48 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Jan Beulich 
Cc: xen-devel@lists.xenproject.org,
	Ross Lagerwall ,
	Kevin Lampis 
Subject: Re: [PATCH v2 3/3] Disallow most command-line options when lockdown
 mode is enabled

On Mon, Jun 02, 2025 at 04:22:06PM +0200, Jan Beulich wrote:
> On 02.06.2025 16:16, Marek Marczykowski-G=C3=B3recki wrote:
> > On Mon, Jun 02, 2025 at 02:46:56PM +0100, Kevin Lampis wrote:
> >> --- a/xen/common/lockdown.c
> >> +++ b/xen/common/lockdown.c
> >> @@ -35,7 +35,7 @@ static int __init parse_lockdown_opt(const char *s)
> >> =20
> >>      return 0;
> >>  }
> >> -custom_param("lockdown", parse_lockdown_opt);
> >> +custom_secure_param("lockdown", parse_lockdown_opt);
> >=20
> > Is that really a good idea? It means `lockdown=3Dyes lockdown=3Dno` wou=
ld
> > still disable it in the end. This may matter more if for example the
> > `lockdown=3Dyes` part is in the built-in cmdline (possibly with other
> > integrity protection than UEFI SB).
>=20
> But having a way to override an earlier "lockdown" by "lockdown=3Dno" is
> intended? E.g. when your xen.cfg has the former, but you don't really
> want that (for, say, an experiment).

Ok, I guess those are conflicting use cases: using "lockdown" option to
restrict what user can set via bootloader menu (even without
secureboot), vs giving the local user full control (developer case). But
in that latter case, maybe you can simply remove the "lockdown" option
instead of adding "lockdown=3Dno" (granted, more work with xen.cfg or
built-in cmdline...) ?=20

Anyway, what really matters here is the behavior for UEFI SecureBoot,
and this one is okay. The behavior outside of SB is secondary, and if
that's the intention, I'm okay with the current version too.

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

--OYPP6qUbWlcHD4Zh
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmg+9B0ACgkQ24/THMrX
1yympQf9FX/FIlmCa1fgmKxqcikietoQqwWCHv45Wm1G4L+B1bY9BpfWHiaGk9ls
cVxIl5z0DBH7PGmY28Z2gSVL2rLZrFpCNcdPYnwiGfOuxb72+Pr2jkh/jPDb68d0
dJlUO9yt95mH+4lXRi9SxDAhMki+XhdQvbMGslKg4JspeF4X82u4xBJKoXJOMqo8
OaRmybqO8ZiDoXMtuY4nCZNg8mOa1Un6gvzjKv7JkFb8Thw0ry7dmBRnOyVhp85x
K0P5TqkgNG1eX+ig1AzC1O08rFj5Hk4EDAWm3XCvpe+LfSsDwg3t42SMtWgRTwZp
wH3o38Fa9Ogs0h1LudpmdOq/40HE8Q==
=KGYd
-----END PGP SIGNATURE-----

--OYPP6qUbWlcHD4Zh--


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 13:13:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 13:13:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004420.1384128 (Exim 4.92)
	(envelope-from )
	id 1uMRRx-0001Ge-A0; Tue, 03 Jun 2025 13:13:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004420.1384128; Tue, 03 Jun 2025 13:13: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 1uMRRx-0001GX-6M; Tue, 03 Jun 2025 13:13:05 +0000
Received: by outflank-mailman (input) for mailman id 1004420;
 Tue, 03 Jun 2025 13: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 1uMRRv-0001FC-HN
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 13:13:03 +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 79f43be7-407c-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 15:13:01 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a4f379662cso4385548f8f.0
 for ; Tue, 03 Jun 2025 06:13:01 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a4efe73f9csm18411167f8f.50.2025.06.03.06.07.53
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 03 Jun 2025 06:07:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 79f43be7-407c-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748956381; x=1749561181; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=cn6ZSsClTrlyOrDaeJmKZBG0SLsvrD0YJd0ic/nsoxQ=;
        b=HaasrrALuU8XzLtIIE50hgWIFK7IApPYhkUP5ShWfvDQwV27mMeGs3XS+kxBq6pggw
         rSJQXK6a4swD3hKC/8Uh9tFU5gZpoCFHJuH20ZWNRRyQqztIzMiQHwHUwl01Vvhgvvjh
         ZJqjIVO4krdF2kVVBUukLYAfnb3ALQ1frIKQk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748956381; x=1749561181;
        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=cn6ZSsClTrlyOrDaeJmKZBG0SLsvrD0YJd0ic/nsoxQ=;
        b=jIPchCnYjIv5YZAsZP5O61EZ2IWsSTenNlZ3XLhR2g9RP+eA9kAfciWNMaHv99Yt1S
         ecOAv66Im12XCTvr7hgw0rPF7OiKyeVVH+3N5d8nMnJtCcH+4iHIkU7x9i3ab/qZKeiK
         4CCESNA3BQnV42uE2AVpj6/k32ofLENq5dfdsf/t+zefLYV6tT9BgbgHiGn3QPA5cFEn
         DwVChcamiK/bdP0LCqisZPVCaVeHT2fcgNhKdb5GBTEVDZDcVAiqHjiL0Rz9YK61xwgu
         Mn6aD/g+AFYFUngExrQFEQnEeBa02cyoMHT1WKPUbC8CYPeAFxTtyh6BI99oxNa5GU9o
         bZSg==
X-Forwarded-Encrypted: i=1; AJvYcCVK3GM/ntX3ZYBsF0CTwjfdscRQtUbWJy6TsfIvtOVQ8nZfF8/D2T29VP5zrDvp6i7l81O1ovlsiX8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxpmbQlFyl1P6crGV0CiRuP+GsKkBKgdXiv5qmT6tHxbMNY8Mau
	06kZ1qjxiOXRmuRCuWeX6trF0xhbSRbs3GPu+KNPg2wtAR6AL/3CssGNDYM4Orx1QqX5Mx7Osfy
	okYXN
X-Gm-Gg: ASbGncu43dK6o1Y6Em6TDYUFHy8jIlPIv8kYp0nlTH5qdL9mL4ui2/1MsHIqH7X8yDT
	cQzNCpLa2vjcoBR6UrAIcRgx/pBJTTO1xfhYD8vLCfC7ADVKKUwIGLRIu0IFVyBeB3CMppTdinf
	b1mhWC6rq/phA3XDq3igpoI9JpOwzavVRfmj4T0aLkhQs8aikMxBjzifcl3PFseV/Q58Khh9KcD
	z0x2chiuYSggDtjY2p7CDqe/HBVpap08puXJy4lWGzr+aeupAkdeBYARa/cwVrCTiVz6yoqjifQ
	Cl2EB4SfnELrcKzVDNzSQoJT+qSkSHnUqvv+EB4MSy+E9h47xDeMP6CAh7WVv/OEswnWKbFs4FS
	RtK3RLn8DNs1vhLjH
X-Google-Smtp-Source: AGHT+IFVj1XR/CCAN0TFYD8YAl0+YQ8eDgtCkqrCdQeWFTSUxEUAI2Tyg6tx8/kwGtY8QMomMe4ysw==
X-Received: by 2002:a05:6000:2907:b0:3a4:fbd9:58e6 with SMTP id ffacd0b85a97d-3a4fe395abfmr8767589f8f.50.1748956074406;
        Tue, 03 Jun 2025 06:07:54 -0700 (PDT)
Message-ID: <9854421d-e6c4-4ac4-ba77-4c038df8731f@citrix.com>
Date: Tue, 3 Jun 2025 14:07:53 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 3/9] CI: Fix status check for tools/tests
To: Anthony PERARD , xen-devel@lists.xenproject.org
Cc: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , Anthony PERARD
 , Doug Goldstein ,
 Stefano Stabellini 
References: <20250603124222.52057-1-anthony@xenproject.org>
 <20250603124222.52057-4-anthony@xenproject.org>
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: <20250603124222.52057-4-anthony@xenproject.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 03/06/2025 1:42 pm, Anthony PERARD wrote:
> From: Anthony PERARD 
>
> Without "pipefail", $? have the exit value of `tee`, which should
> always be 0. But instead of using "pipefail", do collect the value of
> from the test with $PIPESTATUS.
>
> Signed-off-by: Anthony PERARD 

Reviewed-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 13:14:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 13:14:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004425.1384138 (Exim 4.92)
	(envelope-from )
	id 1uMRSt-0001v7-HR; Tue, 03 Jun 2025 13:14:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004425.1384138; Tue, 03 Jun 2025 13:14: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 1uMRSt-0001v0-Eb; Tue, 03 Jun 2025 13:14:03 +0000
Received: by outflank-mailman (input) for mailman id 1004425;
 Tue, 03 Jun 2025 13:14: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 1uMRSs-0001YM-5D
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 13:14:02 +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 9dc71bbc-407c-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 15:14:01 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-450d668c2a1so29625035e9.0
 for ; Tue, 03 Jun 2025 06:14:01 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a4efe6c94dsm18460034f8f.37.2025.06.03.06.14.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 03 Jun 2025 06:14:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9dc71bbc-407c-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748956441; x=1749561241; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=7Ar2Yizbo6vvS5p58yug47JAna3h/wkC62zs6el0WO4=;
        b=iTQDnZjpkiqG8QKT8nqiLJDrHCyp5pWSY4AqBfKeG8dtJVGD5+cEVUrd5EA6cB5y4a
         LQXSe4XyZToGRLV35JHGuQ+IyEeMzZxsSn85fAOxEXJx7eAUC9DGV8oYI9hP/RAWtWoC
         cKDzEkEQxQX4T3psXbD9gIM7iw5Xq3MGNLqeM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748956441; x=1749561241;
        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=7Ar2Yizbo6vvS5p58yug47JAna3h/wkC62zs6el0WO4=;
        b=U4uaYqGPIMU/LpFQHvMTPlz9pxn9g4N5u5FtW+2Z+dg3Mn/qlh0GV1hbI8N1QEGyF8
         rp5ZM15tK0DGzD2KfHKG+CEdgU3UsTilZV2036qD+gILk1h/cXaPAawu93z5cscvOal7
         KuZEKX//0g1I+lteg+Rsl4DgLkMirX0E2MD0FONTTF2URAIRoSb5chK1o+Q+UFGE6JgF
         A1r2kaGmtBugU8eNgeLdKGGMAOK2Cu/2LWcuQrlEkDTH8nuX0JfC+z8Z1aBsJFIjFU7t
         wWaLaPzdkSy3HINyUsLAP+rAYp5XPnzsVqmMR8HqiaB9AHRzCd/l+oDiN9QfjrbrxYWq
         zwYg==
X-Forwarded-Encrypted: i=1; AJvYcCWWhbfdZ2u6zV7GdKdyPhZg89cz3Lyk8DG8nP6LQx5V0Hj4p0Vuek4Y3epW6+pv7S+BDSjN0NO9KCo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxbfzhNKnLYPDqvqAXlpkiRJvTVu1x6a0ZYaRq58+FkH9y0pjrk
	YBSDvhzcRtO9gIOXD7/YQivFXWAnYKw2n3cv731GBwz5ytK+0eWAyygjVlX9onSVQz5iTfC8l/r
	Z8ML2
X-Gm-Gg: ASbGnctNNPR6XiTo5gy/eYM7ShwqVpAJybKvRKxRj50+HWHfuEvrCenWmf8YzehalaD
	LmioAJho9Jc3eG7OJMThETElCba22la2TUj/8GftHyPJ1AbFDNul7Xtw78wu8nkP+iV942qqXsK
	YaxCbD4t7JI7QAIQktEUFJFFermzUbz2Lt5YpDfnVUJnHuV+jmhTb3m37sLGGU1STwN6e/WX+Q1
	gBDlt4weRqV20RiD/sERDfkiPHFRr0MRlAO+5f45cdKJ+swfcmj/sZFQQLrtdjUdo9APkYDPZWZ
	wfr6Vwe53MFxlDhZjJcZ+O8/cBVaFKQD7r8HO1bFH6LxfVM9GzGwuLNBV7lRqSCljRVFmDFxoDz
	cdTi7iWlX64My/fMu
X-Google-Smtp-Source: AGHT+IHNEIOJzC7PQHqjq+Q5/u+C9LKGCEeaTegrDAHzl0Wk2GwOVZtAXoYFtOXfKs/7GFFT/DeDxA==
X-Received: by 2002:a5d:4c49:0:b0:3a3:779d:7421 with SMTP id ffacd0b85a97d-3a514214285mr1737928f8f.0.1748956440963;
        Tue, 03 Jun 2025 06:14:00 -0700 (PDT)
Message-ID: <30007ef7-9576-41fb-8d4d-08ae7cbdacc4@citrix.com>
Date: Tue, 3 Jun 2025 14:13:59 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 6/9] CI: Upload junit result as artefact
To: Anthony PERARD , xen-devel@lists.xenproject.org
Cc: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , Anthony PERARD
 , Doug Goldstein ,
 Stefano Stabellini 
References: <20250603124222.52057-1-anthony@xenproject.org>
 <20250603124222.52057-7-anthony@xenproject.org>
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: <20250603124222.52057-7-anthony@xenproject.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 03/06/2025 1:42 pm, Anthony PERARD wrote:
> From: Anthony PERARD 
>
> This allow to investigate the file in cases of error. Not all
> jobs that extend ".adl-x86-64" are creating a "tests-junit.xml" but
> Gitlab only produce a warning when the file isn't found.

I'm not sure what you're trying to say here.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 13:15:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 13:15:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004431.1384148 (Exim 4.92)
	(envelope-from )
	id 1uMRUi-0002Vj-SC; Tue, 03 Jun 2025 13:15:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004431.1384148; Tue, 03 Jun 2025 13:15: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 1uMRUi-0002Vc-Oz; Tue, 03 Jun 2025 13:15:56 +0000
Received: by outflank-mailman (input) for mailman id 1004431;
 Tue, 03 Jun 2025 13:15: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 1uMRUg-0002VW-RP
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 13:15:54 +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 e0b3fb4d-407c-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 15:15:54 +0200 (CEST)
Received: by mail-lj1-x236.google.com with SMTP id
 38308e7fff4ca-32a9e5b625eso30634031fa.2
 for ; Tue, 03 Jun 2025 06:15:54 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a4f00a0146sm18454351f8f.93.2025.06.03.06.09.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 03 Jun 2025 06:09:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e0b3fb4d-407c-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748956553; x=1749561353; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=10to7aF3fhkNOnipBiy0p/JG11LLChGUHF/lp/2h1v4=;
        b=PRMukr70FdE73w+h+76qPxCAFu19m4QKoMiOf1FMspvaF+lUPcutC+2A/G6bz7+sfh
         imjlCQ/Ajl8BMRDzd2isTbg8UxFvJE3Bq3elKbtbqYEYm8nIYg/Z/DayDkNabAI02n5U
         Cu8Nwg1wH37Tz9dmrLIsUeaGM/SNii6s/MNDQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748956553; x=1749561353;
        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=10to7aF3fhkNOnipBiy0p/JG11LLChGUHF/lp/2h1v4=;
        b=EnxbarHPbGOUGl0kd6Ld9jqG4xYTMotdvC9got0CwYbSZU6EWBKSqC8iGUxiseaWF0
         hm+lnnPwHrP3IzJUCDbHbxJg5EVkvuWpJCtLPXSmaEsSk0o02G4dtMyLdIYePqqK73PK
         0zjgPvjfK1ADdlwcxhOCEe+QmtFdC5ZU22NtQD+Aog9R4Z7EoeedetOO3S1FxggedSjB
         uArKWfxuvwNClw5SzttDdqlwCx6cqkbL6b26/U0WJDxsh+BFEByhJwPud8RdiAwH/1lQ
         VCnr1VWhfmgsC0PH6Mv85GyVyzWg3jSX/hGdk7KiOFn5wQTP+S3HGvoZ5J+++KThPCcN
         A39Q==
X-Forwarded-Encrypted: i=1; AJvYcCWJ6K61+uYQPl40YyC0cLFRRk/kNSrIUUz1zmFDHlnEaNk/2IcgztDFRgTrVc3QgJu2Jkej8O07dUA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzvTOVrC2McMpuIF0U8W9hoawOEgq718SjDADxA1yih1kq4wze9
	LrASTTCJ7iAHKHfnG9/y2q1CDq0plfz5mCao2KZKFwmV+fRQb4xOMy6MxU7WPhLQOH7LaelyMpv
	ud9z0
X-Gm-Gg: ASbGncuaLR+s9Epnd3wtBqsJVNPgGU5QaaxKjqhSpMr/Bbgmvs8MQX8Zsv2jmUbm8Of
	fzvzs5A5/nJdY7ZkeHcBpGUtcFjMN+ybWTCud2xCpC+/jUqGKGPqCwV7PwxzeD0ukqdikDGxAt6
	+6ICAjRyoel/4a9eBBD/Al8d/XLlrd5cBpyySk+Zh27ZhYF+gKdM/yujrIdGw2ohM9VilUWyFZU
	7XC2tfEkAyI1oJhdSjjUgj9/5Ekltq8mTeHh2Tgk1ufDL33sPKHkH90ScVPiS6lX5RU6h2Vr8gC
	FVIyNelP6P7tYfxEk5z7rwJWGIdypCVRaUth9Ss7C0t1v+aDFuxcM/tCKxAPjL7loZC9fuMAra+
	rfsefKvdRzrck69mPiIeWpTvarfM=
X-Google-Smtp-Source: AGHT+IGp/I7mOZHk1Ju2O1hjlffErtRVx2XBJlZBooV2MMraIIkdgRZcfqt5NOcfKa4XCepS8eTMCg==
X-Received: by 2002:a05:6000:2409:b0:3a4:bfda:1e9 with SMTP id ffacd0b85a97d-3a4f89dab8amr12643773f8f.46.1748956168062;
        Tue, 03 Jun 2025 06:09:28 -0700 (PDT)
Message-ID: <66c1a541-c6b2-4bf5-b1a7-9fb9ae19b4a0@citrix.com>
Date: Tue, 3 Jun 2025 14:09:26 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 1/9] CI: Add SELECTED_JOBS_ONLY to analyze.yaml
To: Anthony PERARD , xen-devel@lists.xenproject.org
Cc: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , Anthony PERARD
 , Doug Goldstein ,
 Stefano Stabellini 
References: <20250603124222.52057-1-anthony@xenproject.org>
 <20250603124222.52057-2-anthony@xenproject.org>
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: <20250603124222.52057-2-anthony@xenproject.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 03/06/2025 1:42 pm, Anthony PERARD wrote:
> From: Anthony PERARD 
>
> Signed-off-by: Anthony PERARD 

Acked-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 13:24:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 13:24:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004443.1384158 (Exim 4.92)
	(envelope-from )
	id 1uMRcZ-0004WM-OZ; Tue, 03 Jun 2025 13:24:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004443.1384158; Tue, 03 Jun 2025 13: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 1uMRcZ-0004WF-Lh; Tue, 03 Jun 2025 13:24:03 +0000
Received: by outflank-mailman (input) for mailman id 1004443;
 Tue, 03 Jun 2025 13:24:02 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uMRcY-0004W9-DO
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 13:24:02 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uMRcX-000D7j-2Z;
 Tue, 03 Jun 2025 13:24:01 +0000
Received: from [15.248.2.27] (helo=[10.24.67.31])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uMRcY-005hsN-09;
 Tue, 03 Jun 2025 13: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" 
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=QmqSn5+WAmGAIFaqmuiQXcfbuRfcZR+Kud7b6Lkqq04=; b=VBKDRDJcpYjJn0LLbKydGTWwNm
	IfGpKDdKS2R0KY9wxcs4YkY7ABMIvLoXbG8HWPzKWHdLxTerr3J17zv4fO+gTdbLox5XpVUo+0gub
	NLWU4N4IoviAengtIECGNCiDwR28BwM/sQPpMaICbpzzTziT2Mmu43uZxijHaz5GCSJE=;
Message-ID: 
Date: Tue, 3 Jun 2025 14:23:59 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/4] device-tree: Move domain_fdt_begin_node() to common
Content-Language: en-GB
To: Michal Orzel , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250603100329.149851-1-michal.orzel@amd.com>
 <20250603100329.149851-3-michal.orzel@amd.com>
From: Julien Grall 
In-Reply-To: <20250603100329.149851-3-michal.orzel@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Michal,

On 03/06/2025 11:03, Michal Orzel wrote:
> This is just a wrapper around fdt_begin_node(). Move it to common and
> remove asm/domain_build.h inclusion from static-shmem.c.
> 
> Signed-off-by: Michal Orzel 

Acked-by: Julien Grall 

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 13:26:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 13:26:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004449.1384168 (Exim 4.92)
	(envelope-from )
	id 1uMRf2-00054K-4b; Tue, 03 Jun 2025 13:26:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004449.1384168; Tue, 03 Jun 2025 13:26: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 1uMRf2-00054D-16; Tue, 03 Jun 2025 13:26:36 +0000
Received: by outflank-mailman (input) for mailman id 1004449;
 Tue, 03 Jun 2025 13:26: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 1uMRf0-000547-Nk
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 13:26:34 +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 5e0af112-407e-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 15:26:33 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3a375888197so2886433f8f.0
 for ; Tue, 03 Jun 2025 06:26:33 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-450d7fc1b60sm167304865e9.34.2025.06.03.06.26.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 03 Jun 2025 06:26:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5e0af112-407e-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748957193; x=1749561993; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=KF+yQPTvcTBTRlMsU6t+RNdnyD5G7ZHfRtKfZZnH7ks=;
        b=gKlHA/ekwwqg6qOtjpeFOL/acGv3vh4O5qvERBVg6TMoW76BIAvf01/v9UmrI0dXtJ
         bBMK8+2KIsR8ZCCHz4F9L988fH4J6e6qfG4csy7ieXOEzY2lo3TOhNltzSBV4U7VHcTM
         1HzXhfxdQ/lsd3GoZTKAQIyaI21xxV2y8HzjQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748957193; x=1749561993;
        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=KF+yQPTvcTBTRlMsU6t+RNdnyD5G7ZHfRtKfZZnH7ks=;
        b=eoDpxhilE1f2uuJRFUmU3KbU3FNsEbo0BUvuxwXNIPcI3ypKx7FagNWewooTOLoPuW
         JGl1NyojKyqCCUioqfef9ZLWnjkpkni+uWy/epnRNev3yuCOGsWA4BIcw1ya8zGAy7Eb
         wc88DZPwEfrhSOw7asxHZRvRJiklmc/QWHIFlhxwIBFF/hlcuodviZt93Xlf7/y5ctRz
         KQBA+CxmAr8GUxyOx9J+eRVfflmD2xFv9uRswFc2UpLpaL0J4Y7Vdchw98rFglqbTeSU
         T8q+a262Q9248VoeE6dWCg2SkoxQZ9bztUk8578/+NugC5aQDAIlwXk0GS1ztAn6ueqP
         mZqg==
X-Forwarded-Encrypted: i=1; AJvYcCWpe5BxVKyvMeI5fsLyyyW6hppfl2EJBCM9GVGYQFnGArc/mnFXseGVQnuKt3CeKKsYmCwauwySjik=@lists.xenproject.org
X-Gm-Message-State: AOJu0YztirKWq7GgLW9yJh+IXgke5hJiYL8NZ1qar4MNoC/G1jKRnchi
	JhIJN7qipuH3Gva8TRie3E9R2DeeTVyQUDX9nQ6T5yJ7R3WzsV87uxvJXyYWBysANxg=
X-Gm-Gg: ASbGncsx9Y5AZm5vBjlfuoRUYmkdojv1f1jc+3/2iizgbQ41ZtddlZBouERUxBfCu11
	ULNOm320qbPWxCqRGhhfxvhlugbRpAvdMApVDC4hNGkT1yN6vvEftEKF+IB8dZbuh3o88aEfksv
	YG969Ab+HmXXTa+DFEdTY28yMnOdIvNwj5SJ8hfLO5bzRasB738ES65RVm1Nlk0rWakXwI6Ch9/
	IvMT2EeWckQquVutGetvx3pGywuPdIsFkAJHGOrR9JwAlOwFtG6v/XecjaS15eBxib0OxLidVGL
	MBjEhMhyydWj2JKzd9U/bYMckfWd9SJKC5Az0PGgNORjPFQtBEz3lcX60vi4/vwfMk8N2TqHM2o
	bN4fVzl7fnOQneaCaG1kLxKJEX4M=
X-Google-Smtp-Source: AGHT+IG079AGySF/BWmgTm8Kr/NnK/R3IIpVYFTqeDETSSySJAPEXPDUFbAjLGSERQq4LNZpOLx5NQ==
X-Received: by 2002:a05:6000:2dc5:b0:3a4:d4e5:498a with SMTP id ffacd0b85a97d-3a4fe398f3emr8214427f8f.42.1748957193089;
        Tue, 03 Jun 2025 06:26:33 -0700 (PDT)
Message-ID: 
Date: Tue, 3 Jun 2025 14:26:31 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 4/9] CI: Ignore run-tools-test return value
To: Anthony PERARD , xen-devel@lists.xenproject.org
Cc: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , Anthony PERARD
 , Doug Goldstein ,
 Stefano Stabellini 
References: <20250603124222.52057-1-anthony@xenproject.org>
 <20250603124222.52057-5-anthony@xenproject.org>
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: <20250603124222.52057-5-anthony@xenproject.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 03/06/2025 1:42 pm, Anthony PERARD wrote:
> diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qubes-x86-64.sh
> index 2750d24eba..046137a4a6 100755
> --- a/automation/scripts/qubes-x86-64.sh
> +++ b/automation/scripts/qubes-x86-64.sh
> @@ -135,10 +135,11 @@ done
>      ### tests: tools-tests-pv, tools-tests-pvh
>      "tools-tests-pv"|"tools-tests-pvh")
>          retrieve_xml=1
> -        passed="test passed"
> +        passed="run-tools-test over"
>          domU_check=""
>          dom0_check="
> -/root/run-tools-tests /usr/lib/xen/tests /tmp/tests-junit.xml && echo \"${passed}\"
> +/root/run-tools-tests /usr/lib/xen/tests /tmp/tests-junit.xml ||:
> +echo \"${passed}\"
>  nc -l -p 8080 < /tmp/tests-junit.xml >/dev/null &
>  "
>          if [ "${test_variant}" = "tools-tests-pvh" ]; then

I noticed this too while hacking on XTF support.  Also of note, I'm not
sure we want to be saying done to the expect script before sending the
results.

The underlying problem is that ${passed} isn't really a pass message;
it's a done+pass message, and there is no way to say "failed" to the
expect script, leaving timeout as the only option of signalling a failure.

I don't think we want to be ignoring errors from run-tools-tests
specifically, but arranging this is hard.  You always need something at
an outer level judging whether there was a good test result.

For XTF, the way I did this was to declare that anything didn't match
"^(Success|Error|Crash|Fail).*" on the final line of the console log to
be deemed to be Crash (because it's usually an uncaught exception).

For this, the best I can think of is to have a fixed outer script which
runs "./test/script && echo $success || echo $failure".  The internal
set -e will cause most unexpected conditions to be an error.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 13:28:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 13:28:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004456.1384177 (Exim 4.92)
	(envelope-from )
	id 1uMRgq-0005aI-Dt; Tue, 03 Jun 2025 13:28:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004456.1384177; Tue, 03 Jun 2025 13:28:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMRgq-0005aB-BI; Tue, 03 Jun 2025 13:28:28 +0000
Received: by outflank-mailman (input) for mailman id 1004456;
 Tue, 03 Jun 2025 13:28:26 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uMRgo-0005a3-IX
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 13:28:26 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uMRgo-000DDd-0B;
 Tue, 03 Jun 2025 13:28:26 +0000
Received: from [15.248.2.27] (helo=[10.24.67.31])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uMRgo-005iP7-0l;
 Tue, 03 Jun 2025 13:28: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" 
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=VcHdTJplhFZR3c9y8nV6FDmR2+6su7oR4/sHzBnqvkE=; b=uejBsbj9zqLYEaKSPRqwSkCDsU
	0PYKxyzQR1IYxEImYO8jWxYMu2ubWsnK409+lTWVj8TVL3Aq+nG+BVITj0ze5n05BdB2AWJbSrlmk
	FOMyeu/Dvvxi5YoE8JDd8AUEn7LhdOR3C6sia+3ERoyzvZsj6UDfuXR4xPyGW54/fFAk=;
Message-ID: 
Date: Tue, 3 Jun 2025 14:28:23 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/4] device-tree: Move Arm's static-memory feature to
 common
Content-Language: en-GB
To: Michal Orzel , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20250603100329.149851-1-michal.orzel@amd.com>
 <20250603100329.149851-4-michal.orzel@amd.com>
From: Julien Grall 
In-Reply-To: <20250603100329.149851-4-michal.orzel@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Michal,

On 03/06/2025 11:03, Michal Orzel wrote:
> This feature is arch agnostic, thus move it to common.
> 
> Signed-off-by: Michal Orzel 

With one remark below:

Acked-by: Julien Grall 

[...]

> diff --git a/xen/arch/arm/include/asm/static-memory.h b/xen/include/xen/static-memory.h
> similarity index 93%
> rename from xen/arch/arm/include/asm/static-memory.h
> rename to xen/include/xen/static-memory.h
> index a32a3c6553bc..e445aa80578c 100644
> --- a/xen/arch/arm/include/asm/static-memory.h
> +++ b/xen/include/xen/static-memory.h
> @@ -1,13 +1,14 @@
>   /* SPDX-License-Identifier: GPL-2.0-only */
>   
> -#ifndef __ASM_STATIC_MEMORY_H_
> -#define __ASM_STATIC_MEMORY_H_
> +#ifndef XEN_STATIC_MEMORY_H
> +#define XEN_STATIC_MEMORY_H
>   
>   #include 
> -#include 
>   
>   #ifdef CONFIG_STATIC_MEMORY
>   
> +#include 

This change looks a bit odd in the context of the patch. I guess this is 
moved because the include should not be used if !CONFIG_STATIC_MEMORY? I 
am fine if you want to keep it here. But it would be worth mentioning in 
the commit message.

> +
>   static inline void init_staticmem_bank(const struct membank *bank)
>   {
>       mfn_t bank_start = _mfn(PFN_UP(bank->start));
> @@ -46,7 +47,7 @@ static inline void init_staticmem_pages(void) {};
>   
>   #endif /* CONFIG_STATIC_MEMORY */
>   
> -#endif /* __ASM_STATIC_MEMORY_H_ */
> +#endif /* XEN_STATIC_MEMORY_H */
>   
>   /*
>    * Local variables:

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 13:29:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 13:29:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004463.1384188 (Exim 4.92)
	(envelope-from )
	id 1uMRi1-00067L-MZ; Tue, 03 Jun 2025 13:29:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004463.1384188; Tue, 03 Jun 2025 13: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 1uMRi1-00067E-Jt; Tue, 03 Jun 2025 13:29:41 +0000
Received: by outflank-mailman (input) for mailman id 1004463;
 Tue, 03 Jun 2025 13:29:39 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uMRhz-00066y-T2
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 13:29:39 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uMRhz-000DEh-0k;
 Tue, 03 Jun 2025 13:29:39 +0000
Received: from [15.248.2.27] (helo=[10.24.67.31])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uMRhz-005iUa-1Y;
 Tue, 03 Jun 2025 13:29: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" 
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=fKOBxPwvsV5O3YyvKP9MdoeOn8IMuvFKRGJ4P9M1W9E=; b=yW2mS0eAKb2LTvFfpJ8xXks51A
	tzTOEGkpaPn9syhoutk2qURSUcoMOBR9RXDURsRqiM4C0sOgMuJ608Miqv2KXfxWFikS6x98xSzvx
	cJzh7kxmywYhe4mxhUeZSN44mz39m/y+dj9PVBB12hq/UtGVECrudSf0dOyG3QGNE0HY=;
Message-ID: 
Date: Tue, 3 Jun 2025 14:29:36 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 4/4] device-tree: Move Arm's static-shmem feature to
 common
Content-Language: en-GB
To: Michal Orzel , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20250603100329.149851-1-michal.orzel@amd.com>
 <20250603100329.149851-5-michal.orzel@amd.com>
From: Julien Grall 
In-Reply-To: <20250603100329.149851-5-michal.orzel@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Michal,

On 03/06/2025 11:03, Michal Orzel wrote:
> This feature is arch agnostic, thus move it to common.
> 
> Signed-off-by: Michal Orzel 

Acked-by: Julien Grall 

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 13:31:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 13:31:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004471.1384198 (Exim 4.92)
	(envelope-from )
	id 1uMRjk-0007cN-17; Tue, 03 Jun 2025 13:31:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004471.1384198; Tue, 03 Jun 2025 13:31: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 1uMRjj-0007cG-UV; Tue, 03 Jun 2025 13:31:27 +0000
Received: by outflank-mailman (input) for mailman id 1004471;
 Tue, 03 Jun 2025 13:31: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 1uMRjj-0007bg-AK
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 13:31:27 +0000
Received: from EUR03-DBA-obe.outbound.protection.outlook.com
 (mail-dbaeur03on20607.outbound.protection.outlook.com
 [2a01:111:f403:260d::607])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 09d9c9bd-407f-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 15:31:22 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by AS8PR03MB7480.eurprd03.prod.outlook.com
 (2603:10a6:20b:2e9::6) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Tue, 3 Jun
 2025 13:31:23 +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.8769.037; Tue, 3 Jun 2025
 13:31: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: 09d9c9bd-407f-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=w6Q2rjLTV+WP5iu2QiMXFVihjwzrxeevj10KBh/bo1kY1qinBZRh2gub1jhStmpZYR/q2fYN1vP8VU58HMyTaTuQ3MQx0+yOwJ2q/ufhGRZY79Ghox4/7hIlnMAhgfsP6gFVyv1fpwYuj7CxwYd2IY+iK4azJmkSzbOgyE427xa7YGrlrj46XiOppWr/W1xI+E9Ym+4FxFGhbsoK9fv5a8omD+QeTndoCzXuxrU/juClqQgxIDD8jcRuO8UPrWC0DxjqRbLTYm0y5C7SC6JJbOf2EH1gBnDWEcFFKSnYoUU2AQQPAPIKJR7we/0FOLEBMeF05g+FKZGv06GQb5TUQQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=z5Suj4YHn9CkrIg05xjvAg9i480A2T2xjgAp6xK8iN0=;
 b=rBVzW6NzraKs4QW2YBFu7d9S4x+3naRPjXsaAeA2pTkdUo5oaCWig1StWaaY7Q9CUEYdiW6FjCDpRAKpGAPNFcWztSbQRUQ+azd0QDLwEC222Ky8PNc+wRu2mi+M5kIbQQwTzdaDNupClrBSBEP2oRbqkFRw1lU/yNk3hzGt94cXrxTKxa7wKhsPdGrS/nqpK26Yw9oMq1V8EK8tcTNR8UpxkoovATLyH+kod88uXQ+0z9LZWs0+eVGPwpAjG9Ieeg3DJQHFe9g5NLGLHDse8U6id1wh5ZKxlDhH/svLQ7A+Hcvx680UYlZ3h/sBc7LvKWz2z0WTo29e8Qg2mtjEXg==
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=z5Suj4YHn9CkrIg05xjvAg9i480A2T2xjgAp6xK8iN0=;
 b=VxUAJhu0Ph8RvLn9jsIrou/rIJUoNLdyd7G4wEB2/x7UT+BUaMWhsCFHNsdMi2fqecBpGq3aBK3YJwafFfogFYHpBcfoVWk8r4EPiGTgu6E1xztbvNczoE695PAQ0+N5lk8ZXkpmuDgeYHM6dKTTceQwMpLftk5tW7qBgIHm8bf+e1CBneAbgl5eLx0Cc156ek/Bsh0pt9W4pD+atoUDEnI7Nnh5mnLyfbXCCYhZshy3r++eyv/5J7p951ARkzwVI2AmEMRKG7CJKBOICLoZ96Q/qyc+HTMZYQ8XNG0ZD4U1jSZvFLafOh5FPKBxcVjlUpsIYfkiD26Zw/e+yGbtyw==
From: Mykyta Poturai 
To: Jan Beulich 
CC: Stewart Hildebrand , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk , Andrew Cooper
	, Anthony PERARD ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= ,
	"xen-devel@lists.xenproject.org" 
Subject: Re: [PATCH v11 6/7] xen/arm: enable dom0 to use PCI devices with
 pci-passthrough=no
Thread-Topic: [PATCH v11 6/7] xen/arm: enable dom0 to use PCI devices with
 pci-passthrough=no
Thread-Index: AQHbz7CcYslTkZ61QEOdjKGC2c9BkrPvjG0AgAHrw4A=
Date: Tue, 3 Jun 2025 13:31:22 +0000
Message-ID: 
References: 
 
 <66cda989-efe9-4389-ae8d-cb9bc4dc5239@suse.com>
In-Reply-To: <66cda989-efe9-4389-ae8d-cb9bc4dc5239@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB10102:EE_|AS8PR03MB7480:EE_
x-ms-office365-filtering-correlation-id: 6e860d8f-649d-44a7-9256-08dda2a2eeab
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|1800799024|7416014|376014|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?VTNmMXI1QmhjVi8zL2lYUm9jME1aYU40c2tiWkNyUTdlUkN3bk9EdHlrOUVN?=
 =?utf-8?B?d25VeDh2VmRZU2JMMHdtQ2ZpTXNaeWRNU1A4SHJSSW1pNkg0cDNHMDVmZGRH?=
 =?utf-8?B?R2hDSDZncjhtVFdrZi81OG9jR1dyZGhiR0dhUjNEUXg3dzYwRS8rdU5iUWxt?=
 =?utf-8?B?U1o3aVQzbVhhbFhTWEJkdGVQMXFHc2tvRmdVUktDUE1kU1l3cm41N0xVcjFp?=
 =?utf-8?B?T2VKMlY2amlmVUFLV0pTVkFRSHcwbWRiemkyVDRnUXBHZ0V6OGxzTWpwMEFS?=
 =?utf-8?B?c0dCRmtpTXdVMnhLVGtEV1JIZkJDWEZlUjVzMXZpekdtUEs1VmQrRHQxWkt3?=
 =?utf-8?B?KytFM1E4U1d5Q3o1VGgxS0xCOVBMTktMUzlKZjZwZGtmMmtKN1BnOGcreWI1?=
 =?utf-8?B?MmY2R2tMQ2Zua2R0R29tZHlyTkhoRExqK2pzNU0xTmpSTmcrVXFQK29PZUZT?=
 =?utf-8?B?M0h4NXcxNXNQYmR2NkdPQ2VqZWwyUnBLYVZyYVdHVjhTaFRQSzJJelMrY29w?=
 =?utf-8?B?bldqVmwrbGVNWlpVYTBOYUpyMndFL0s1QktCWndhMmQ2SUFHWnZqUjB0UnBu?=
 =?utf-8?B?UjdqZzJtUmlaWXU4VmFjcVZZYlJvVkpocktxS0JSay8rMkFBaDRra243SUVO?=
 =?utf-8?B?Wm5CT0phRk1WV2ZNaW9zMEdDbENLcjA2Sm1aSHhNT1ZUcTBpUzMyNlVmTlho?=
 =?utf-8?B?STRPTmhnQTQ5QzA5NWljSFlrV2pRS09SSWxSYVA5UHZGR2lIdVN0MWgyQ3Zx?=
 =?utf-8?B?ajFZd2hvQnI3ekxiZldpTTVMdUFpbXNWbWVyeHVkajVnNFBlWkRWOXlOY2FX?=
 =?utf-8?B?SkFCckhNZnVQbFdBQm9QTStLMFplTFM0RS9sekpLRzQyakZsZ3ZCWnZSTzl4?=
 =?utf-8?B?NFlacFFnWURCTE9KZjZMcHlVeVY0bS9jeGFuVkVYZFZZSGc3YkF2b3lER2dn?=
 =?utf-8?B?aDVZc3YvVVpyNDlKTUw4WW1helBNTWtPVkVSdXQ5NktWb3FmS0ZlcDNhQ3hK?=
 =?utf-8?B?Nkh1eW1Hbkx1K2tzLzdYUHZpanZzTklLQ3M2QUFwczZrNGJZQmZrOU5vS1dZ?=
 =?utf-8?B?QlZXTTM3aFo3WWdsbFNRaHlzQVJpNmIzQTNKazN1TnFQaVFiRXBtRzd4RHd2?=
 =?utf-8?B?THJBSWJkdmFKV2ZjSUdRTmVZclJlUjZUZnJLMEp2MHd1VFd3TjZiYTliamZT?=
 =?utf-8?B?dzREWGw3a2lHbUNpcU4xUjllczFwV1JUYnEwd1B2cFBUanJ0VUR6WlgzUEFD?=
 =?utf-8?B?SFU2KzJCMnlCbWxBREtmcVNUeWdWNHJ5TjlPLzFQSVExOFQxSnY1Mk1lL3ZU?=
 =?utf-8?B?RFlUN09NcDZsWlAzLzhGUlZoSndFWUJ6amFvZHRCQkNhYVJ0YXZZT0ZCYXl5?=
 =?utf-8?B?SXhiaW1aWmsrYmw3WXUreGM1d1NVZlpwOHJ6NGVPaFB1MUR0ZUk5YmJweFpp?=
 =?utf-8?B?dmpTQ2R2VFZLdGtTRTJsNEdmejRFZndWM1RBVXgrWjhvd1VJR0ZaNTJXQ2Zt?=
 =?utf-8?B?ZVZFRFRJQnZwTEFCazZIa3NZZWtFaEVLL1crS0IwY3plUjk2dm1sRGlXZ3N2?=
 =?utf-8?B?dFNCaDhMOS9RSzRJTjRDbmFKSXd2cUZpcG5oSnFmVThDNXQ3N2Q2Zkp2ZmVh?=
 =?utf-8?B?aWlrNU9IaHNhb0pQeDRXMDBCa3Y3MDB4TENGNkpEZWFmOHFSdjdEclpiNFEz?=
 =?utf-8?B?SzJtQ3ZGenh1NjlkZWgzWVdhSlB2VkdSc0U5K0xIemFmMHphaEVtamd6ZVl5?=
 =?utf-8?B?N3ZSQ0FMQnVRQnJEQzIvd1R6MDBKR3VTeG04ejRGVHpGUDdLMzczdFp2cTNV?=
 =?utf-8?B?WnVjY2VYYnl4M3g3SXBKUzdxRTFsT2ZzM2hHdHVGVGlTR0lPNnFQVnNmOWlW?=
 =?utf-8?B?TnZkb1ExL00zNzZjSUtzNWJFUUgzeHYrVWUzSHdtSFVUUENHN3ExMk9Pc010?=
 =?utf-8?Q?y+rl1PvKHsQ=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)(7416014)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?VEZ6U1ErQ1IwQTBrZEVHVVdnVlJkb2lQNXFKZGNPazBlaFJRYTIzcGpZdFhu?=
 =?utf-8?B?WWVxSFJQQlYxczVJQlRudmNjSkcxMm9xRnI5bVBEKy9XRHFhUTR5M3M5Tlpr?=
 =?utf-8?B?bktMbkdtSGZZVGl5Qm5oUFRYTjMybUw4S0xub29DYjU3UjJmUVFlOVZiVnpF?=
 =?utf-8?B?NmhtbFNMaDAwZ0xpSUwvREFKbkFIeVpvbmpGRE9DYXg3WFRGck1pWjVBMzdm?=
 =?utf-8?B?SUI1Q0JKUXl5QkVKUStQc2xPelM1WXIrSHdNZDBVanJUcDdKVGpJSFpZSDJq?=
 =?utf-8?B?UGgvWkphc2FLcFU0MDMzS2pkejcyQXdocXZJZ2RTVFFZZ29OMUpnR2w1ZXVt?=
 =?utf-8?B?UE1oWjBLRXdhUER2alptSkllUm5xc3YzaFlIaHQ5OUhCeW0rOU1hWEMyRkZM?=
 =?utf-8?B?VEhKS0RueVFJSVppODdWdkljeE05QUt2QlRGTkNVbnY0RzV4ZjIvMWhzZGtE?=
 =?utf-8?B?ZXlzK255SmZBNWltd0R5Z2p3YUN5SHZHZ25wVEkyWkZvdW02Vkg1M3B6VHVX?=
 =?utf-8?B?VTE1WWhoZ3ByR0h5cDJCck5UYU52b2RRN2VSeE9EejBOd2RsYmVWcUE2ZFYy?=
 =?utf-8?B?ZGJlQWVHd0tJYURIVmpIc29EMTNuTytLMHVNbjZ4aG9kYTdWeXJzOFdJUWpj?=
 =?utf-8?B?RGFSZ2FNTU1YZXpkZ0VkWVFGRDlkSW0wUkY4R0tCSUFEVG1HN29MRkp6RmJL?=
 =?utf-8?B?RGhzYlgyRk51MTdpZ3dkdklkTjNZaTlYNXhXVzdIMytIV2MzTW1mT3pqREZZ?=
 =?utf-8?B?QmI3OW9FdHNRS05CSXh6Z0NMNzROOXRBdXd6V0xPMGRaNmZvRzZybi9VVDl1?=
 =?utf-8?B?QnQ0Wi9kZjRSNm9UQ2NnMXY2dVpuNXU5WGNYME5tSVI5NE5LVUI1S2FWdmxC?=
 =?utf-8?B?T3NMYzdxTDE0dFRIcXRCQTdxSFFlR1RHNmdJYU1UWk9ZZ3VQb0V2UEl1T0J1?=
 =?utf-8?B?Q0lpd20vU21sNjc1U2w3TU9zYW9WTHlpMzB3Z1FtYzEvbXU1Z0NrT0tRS2U1?=
 =?utf-8?B?c0F0NXg2aGM5a2pteTlBdnlIUElidG1BdVBCZkplN1k5RjE2UzFkTXVKZEZs?=
 =?utf-8?B?NWVaa0xiWllLRzBNeWtQendIQ29rd3FrWjVoU2J6Smlmc1d2aHkvbE1jckhm?=
 =?utf-8?B?WXJmODEwT2hoUEVHdTViV3U4NUhtc015RVlqVnBVd0oxdzhYQS9JTThpTllw?=
 =?utf-8?B?VzBFSDBMNzY0c2EyRFI0UHM4Z2RiMXJHT3A1R1NncDlXbG5UVytWbUttelpQ?=
 =?utf-8?B?dzJsenl3Ym9KSGJ4bXhOYitHWkFDSXlRMlFVQjQ2cWl1U2pQTUcvNEJmVTNQ?=
 =?utf-8?B?eUlPUldHdmpRaVlQK1BDL29GWExaVzNzdDdsSTB5N1N6OEY3Y092czB0MEdw?=
 =?utf-8?B?UEtqakh6MVFWRTVQWXdDd2M1TklWSHJGYjFtVFo1YmhHcnkwYkRVaTFneGZ2?=
 =?utf-8?B?NzNQZDQ2dXg0Q3RFRG9XU04vWlBYZElxektBRHRyYUNNSUtPc2padVBCOE5n?=
 =?utf-8?B?L0tjWDZrais2YW42NGI0c3RodVpDVGRrb2prVHNTTHd3Ti9pZUdreEN2VzFU?=
 =?utf-8?B?aGh1U1UrN2hPanpicURYdTRLVXV2Z2lHVWtzdEh4UlI0Nmd5OFlheXNoYXZY?=
 =?utf-8?B?bzVyMTRzZFlINVppZmp5T0dxSzVNYmsxMWVob3owWkxlNi95eXQ4TzFBZ01U?=
 =?utf-8?B?THpGcWFGdnhoWWpxcUxJM3h4SEh6WnpsNHJnQVErVkFONytMMTNhKzJVSzhO?=
 =?utf-8?B?ai9RZGJWbDJibmtuOW9CcmhLaGlXYlJ2cWc1K0V1ZDU4Zy9tNWlZQW9SVUo1?=
 =?utf-8?B?ZjFWSHBMUkp6ZGRaT2JGa3FuVG54ZVZPRFhlR0RFQlIrRGNvRU96WUl3VWt5?=
 =?utf-8?B?eEw4NVpkQWM3Y0NDOWpHazgyczhJaGdXSDM5ajZvS056MktmNkdMSTZTZUNx?=
 =?utf-8?B?NlJ6ZFNETmtpWXQ3bzdYaFFUUlVMTE5nL0lKSk52NDEwN3kwY3VyUlY0U0xJ?=
 =?utf-8?B?WThCUTN2QXhGN1dhRzlubzFtc2FZYzhlVko2MzI2Tkh3K0VEMTI0NGZtQTF4?=
 =?utf-8?B?MzVoOTFoS3FUYXFEKzRtejQzck5KZFk2Ky9oL2lFMDJXZXdYM1A0dUN5Z1lD?=
 =?utf-8?B?dm5jZktzWlVSc1dCZm43NnNBMlJQdVNpdU1FZEpsc29ZOTdqZXc5M3VTLzJp?=
 =?utf-8?B?eHc9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PAVPR03MB10102.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6e860d8f-649d-44a7-9256-08dda2a2eeab
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jun 2025 13:31:22.9055
 (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: Ne7xAsLWF0DEazM90ZtQcM69/L0D4C41zsv74bdCAhHb0UBvFwsy91oEo+D2SU4MVAuqtJWNqvptdCKnCjckWw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7480

T24gMDIuMDYuMjUgMTE6MTEsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAyOC4wNS4yMDI1IDEx
OjEyLCBNeWt5dGEgUG90dXJhaSB3cm90ZToNCj4+IEZyb206IFN0ZXdhcnQgSGlsZGVicmFuZCA8
c3Rld2FydC5oaWxkZWJyYW5kQGFtZC5jb20+DQo+Pg0KPj4gRW5hYmxlIHRoZSB1c2Ugb2YgSU9N
TVUgKyBQQ0kgaW4gZG9tMCB3aXRob3V0IGhhdmluZyB0byBzcGVjaWZ5DQo+PiAicGNpLXBhc3N0
aHJvdWdoPXllcyIuIER1ZSB0byBwb3NzaWJsZSBwbGF0Zm9ybSBzcGVjaWZpYyBkZXBlbmRlbmNp
ZXMNCj4+IG9mIHRoZSBQQ0kgaG9zdCwgd2UgcmVseSBvbiBkb20wIHRvIGluaXRpYWxpemUgaXQg
YW5kIHBlcmZvcm0NCj4+IGEgUEhZU0RFVk9QX3BjaV9kZXZpY2VfYWRkL3JlbW92ZSBjYWxsIHRv
IGFkZCBlYWNoIGRldmljZSB0byBTTU1VLg0KPj4gUEhZU0RFVk9QX3BjaV9kZXZpY2VfcmVzZXQg
aXMgbGVmdCB1bnRvdWNoZWQgYXMgaXQgZG9lcyBub3QgaGF2ZSB0aGUNCj4+IHBjaV9wYXNzdGhy
b3VnaF9lbmFibGVkIGNoZWNrLg0KPiANCj4gSnVzdCB0byByZS1yYWlzZSB0aGUgcXVlc3Rpb24g
aGVyZTogSXMgdGhpcyBhY3R1YWxseSBjb3JyZWN0Pw0KPiANCg0KSSdtIGFmcmFpZCBJIGRvbid0
IHF1aXRlIHVuZGVyc3RhbmQgeW91ciBjb25jZXJucyBoZXJlLg0KDQpUaGUgcHVycG9zZSBvZiB0
aGlzIHBhdGNoIGlzIHRvIHJlbGF4IHRoZSBwY2lfcGFzc3Rocm91Z2hfZW5hYmxlZCBjaGVja3Mg
DQphbmQgbWFrZSBQQ0kgcGh5c2RldiBvcHMgd29yayB3aXRoIHBhc3N0aHJvdWdoIGRpc2FibGVk
Lg0KVGhlIHJlc2V0IG9wIHdvcmtlZCBpbmRlcGVuZGVudGx5IG9mIFBDSSBwYXNzdGhyb3VnaCBi
ZWluZyBvbiBvciBvZmYgYW5kIA0Kd2lsbCBjb250aW51ZSB0byBkbyBzbyBhZnRlciB0aGlzIHBh
dGNoLg0KSWYgeW91ciBjb25jZXJucyBhcmUgYWJvdXQgdGhlIGNvcnJlY3RuZXNzIG9mIGFsbG93
aW5nIHJlc2V0IHRvIGFsd2F5cyANCndvcmssIHlvdSBzcGVjaWZpY2FsbHkgcmVxdWVzdGVkIHRo
aXMgYmVoYXZpb3IgaW4gdGhlIHBhdGNoZXMgDQppbXBsZW1lbnRpbmcgaXQgaGVyZVsxXS4NCg0K
Pj4gLS0tIGEveGVuL2RyaXZlcnMvcGNpL3BoeXNkZXYuYw0KPj4gKysrIGIveGVuL2RyaXZlcnMv
cGNpL3BoeXNkZXYuYw0KPj4gQEAgLTE5LDcgKzE5LDcgQEAgcmV0X3QgcGNpX3BoeXNkZXZfb3Ao
aW50IGNtZCwgWEVOX0dVRVNUX0hBTkRMRV9QQVJBTSh2b2lkKSBhcmcpDQo+PiAgICAgICAgICAg
c3RydWN0IHBjaV9kZXZfaW5mbyBwZGV2X2luZm87DQo+PiAgICAgICAgICAgbm9kZWlkX3Qgbm9k
ZSA9IE5VTUFfTk9fTk9ERTsNCj4+ICAgDQo+PiAtICAgICAgICBpZiAoICFpc19wY2lfcGFzc3Ro
cm91Z2hfZW5hYmxlZCgpICkNCj4+ICsgICAgICAgIGlmICggIWlzX3BjaV9wYXNzdGhyb3VnaF9l
bmFibGVkKCkgJiYgIWFyY2hfcGNpX2RldmljZV9waHlzZGV2b3AoKSkNCj4+ICAgICAgICAgICAg
ICAgcmV0dXJuIC1FT1BOT1RTVVBQOw0KPj4gICANCj4+ICAgICAgICAgICByZXQgPSAtRUZBVUxU
Ow0KPj4gQEAgLTU3LDcgKzU3LDcgQEAgcmV0X3QgcGNpX3BoeXNkZXZfb3AoaW50IGNtZCwgWEVO
X0dVRVNUX0hBTkRMRV9QQVJBTSh2b2lkKSBhcmcpDQo+PiAgICAgICBjYXNlIFBIWVNERVZPUF9w
Y2lfZGV2aWNlX3JlbW92ZTogew0KPj4gICAgICAgICAgIHN0cnVjdCBwaHlzZGV2X3BjaV9kZXZp
Y2UgZGV2Ow0KPj4gICANCj4+IC0gICAgICAgIGlmICggIWlzX3BjaV9wYXNzdGhyb3VnaF9lbmFi
bGVkKCkgKQ0KPj4gKyAgICAgICAgaWYgKCAhaXNfcGNpX3Bhc3N0aHJvdWdoX2VuYWJsZWQoKSAm
JiAhYXJjaF9wY2lfZGV2aWNlX3BoeXNkZXZvcCgpKQ0KPj4gICAgICAgICAgICAgICByZXR1cm4g
LUVPUE5PVFNVUFA7DQo+IA0KPiBOaXQgKHN0eWxlKTogWW91J3JlIGxvc2luZyBhIHJlbGV2YW50
IGJsYW5rIGVhY2guDQoNCkkgd2lsbCB1cGRhdGUgdGhpcywgdGhhbmtzLg0KDQo+IEphbg0KDQpb
MV06IA0KaHR0cHM6Ly9wYXRjaGV3Lm9yZy9YZW4vMjAyNDA4MTYxMTA4MjAuNzU2NzItMS1KaXFp
YW4uQ2hlbkBhbWQuY29tLzIwMjQwODE2MTEwODIwLjc1NjcyLTItSmlxaWFuLkNoZW5AYW1kLmNv
bS8jMWUwZWVlNmMtMGRjZC00ZWQ0LTk3MGYtM2Q3ZTU2OWNlYzA5QHN1c2UuY29tDQoNCi0tIA0K
TXlreXRh


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 13:41:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 13:41:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004483.1384208 (Exim 4.92)
	(envelope-from )
	id 1uMRtr-0001pE-24; Tue, 03 Jun 2025 13:41:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004483.1384208; Tue, 03 Jun 2025 13:41: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 1uMRtq-0001ok-V3; Tue, 03 Jun 2025 13:41:54 +0000
Received: by outflank-mailman (input) for mailman id 1004483;
 Tue, 03 Jun 2025 13:41: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 1uMRtq-0001oe-1U
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 13:41:54 +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 81c99763-4080-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 15:41:52 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-450ccda1a6eso50874445e9.2
 for ; Tue, 03 Jun 2025 06:41:52 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a4efe73eebsm18133379f8f.44.2025.06.03.06.41.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 03 Jun 2025 06:41:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 81c99763-4080-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748958112; x=1749562912; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=F9wKU01RvMGS9wJB52Arrkx70kwBWx1MUCeZEtlJLvE=;
        b=ST6glmcqi9NKDwYt5lh6Jh8pMULZXa7AScQfpalrHIKdmubNofMgB8RzBFHzeWtdFW
         PMM/qkoYA3ZxEmaCkH8RwKitTZQIqm9JI5j196cYPbiT1hzo9icYj+KY0GEyUhcaRfhF
         thrDnwXiAQc6VLfUVZmEEwONNbRnZ+N1IckEY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748958112; x=1749562912;
        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=F9wKU01RvMGS9wJB52Arrkx70kwBWx1MUCeZEtlJLvE=;
        b=Hg+stcXNbdGUElUZkJr+b5PpnUwNs4nvHkKoz7qNERB8yCXwlM9ogoyc730+PK4jRY
         5URfxDaLdu2nmLpci3QKrDblsU0Lj7mrdbjCO1abe5xtKlkZBod+EVXijy67iqngJtna
         YLX5G/xBfhjQu0HJnYMzd8AH6RnUvN7GZ8DwFnwvqvG0DxK9p8WiAfDrno771CCpFb7p
         28W2jLG3ZQs/bBV9CyJnaXZGoLyJPewvbBmDDCVUhVuBqZLkp8Np3GG8KaX2OfAQGB/U
         Pj9+4dMihth1b1pyTakaLU2oy3SSwSPRVMzz+MIX45f6SlzUeFxwHvY/38d3ijBwomGk
         BN9w==
X-Forwarded-Encrypted: i=1; AJvYcCXEDCf426+BfYpj3uodp8ONUxwVv5Oz45MNFMgOmz9pu094xs9mGUIKyUK2jWdAvRcFZcpr+lP6094=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyW+16xvIkYjq2lcUWegaSISPoYAZPqtwCGADpYzPd50Q2JBmdK
	IMDYUf11XQ/XuNKDg0shHuCzlRPAV/2h2ClJ3Gi1yovyUvhqIJ4Yqhaet0bOb7M/Iy0=
X-Gm-Gg: ASbGncsen/4c8kwoXaVblg/Dwd0KdPn6lXOvzXCgEQj4esy15f/WdRVqgcGCnjYdZ8g
	c3M3YNB1gGSYIdoGxGGHSVNOjJFsvHPkSQlckML4hCZ/ncr4VaS68UwRc6o2ynHYfjVSV70Zv+Z
	iBW/tmT7qQX8MJoa29Xi1LiOTz7Ed7GKN1+VamjTSIS+eZOa7LTj/4qI8D6w1cYiiP6WLqzCl/Y
	z6ZVt5HL5QGGHgULZK3a+XerMhlAKN9uuQ9wgfN7AHQbQorJ3RGpuZZiiIdfrcMrsbtHr6RTTLb
	o1VMQhTzyG7J/hxC46L+yugBT9AAWcjUEwyCPGLlzmn6UMJvCAd2aZbNEYXPJFzy3rvOBD4jY3w
	sNoXx4G0n42Fg54r6
X-Google-Smtp-Source: AGHT+IFRTF1e1H/d+mLUT9dzUyJ6hTDNRPvWL9Cm5tXOl5RcvGQ/lLHgxovWgvW3WdKi+7Gzy6d18g==
X-Received: by 2002:a05:600c:6207:b0:43c:ea36:9840 with SMTP id 5b1f17b1804b1-450d885e38amr109908495e9.22.1748958111992;
        Tue, 03 Jun 2025 06:41:51 -0700 (PDT)
Message-ID: 
Date: Tue, 3 Jun 2025 14:41:50 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 5/9] CI: Have the gitlab job fail on tools/tests
 failure
To: Anthony PERARD , xen-devel@lists.xenproject.org
Cc: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , Anthony PERARD
 , Doug Goldstein ,
 Stefano Stabellini 
References: <20250603124222.52057-1-anthony@xenproject.org>
 <20250603124222.52057-6-anthony@xenproject.org>
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: <20250603124222.52057-6-anthony@xenproject.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 03/06/2025 1:42 pm, Anthony PERARD wrote:
> From: Anthony PERARD 
>
> We can't rely on an exit value from `run-tools-tests` since we only
> have the console output. `console.exp` only look for success or it
> times out. We could parse the console output, but the junit is more
> concise. Also check if we have it or fail as well.
>
> Signed-off-by: Anthony PERARD 
> ---
>  automation/scripts/qubes-x86-64.sh | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qubes-x86-64.sh
> index 046137a4a6..7a4c5ae489 100755
> --- a/automation/scripts/qubes-x86-64.sh
> +++ b/automation/scripts/qubes-x86-64.sh
> @@ -298,6 +298,13 @@ TEST_RESULT=$?
>  
>  if [ -n "$retrieve_xml" ]; then
>      nc -w 10 "$SUT_ADDR" 8080 > tests-junit.xml  +    # Findout if one of the test failed
> +    if ! grep -q '' tests-junit.xml; then
> +        echo "ERROR: tests-junit.xml is incomplete or missing."
> +        TEST_RESULT=1
> +    elif grep -q '' tests-junit.xml; then
> +        TEST_RESULT=1
> +    fi
>  fi
>  
>  exit "$TEST_RESULT"

A couple of things.

>From my experimentation with junit,
https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1849342222/test_report?job_name=kbl-xtf-x86-64-gcc-debug
we can also use  for classification.  I'm also very disappointed
in Gitlab classifying  as success.

Not for this patch, but for XTF I need to be able to express "tolerable
failure".  (All branches of Xen will run the same tests, and we don't
have OSSTest to deem "fail never passed" as non-blocking.)

Even if the job passes overall, I want tolerable failures to show up in
the UI, so I have to use  in junit.xml.  But that means needing
to be more selective, and I don't have a good idea of how to do this. 
(I have one terrible idea, which is  which
will escape that grep, but it feels like (ab)buse of XML.)

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 13:41:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 13:41:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004484.1384218 (Exim 4.92)
	(envelope-from )
	id 1uMRts-00023r-7v; Tue, 03 Jun 2025 13:41:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004484.1384218; Tue, 03 Jun 2025 13: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 1uMRts-00023k-58; Tue, 03 Jun 2025 13:41:56 +0000
Received: by outflank-mailman (input) for mailman id 1004484;
 Tue, 03 Jun 2025 13: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 1uMRtr-0001oe-8i
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 13:41:55 +0000
Received: from fout-b3-smtp.messagingengine.com
 (fout-b3-smtp.messagingengine.com [202.12.124.146])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8207508b-4080-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 15:41:54 +0200 (CEST)
Received: from phl-compute-02.internal (phl-compute-02.phl.internal
 [10.202.2.42])
 by mailfout.stl.internal (Postfix) with ESMTP id 63F8A1140115;
 Tue,  3 Jun 2025 09:41:52 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-02.internal (MEProxy); Tue, 03 Jun 2025 09:41:52 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 3 Jun 2025 09:41:50 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8207508b-4080-11f0-a300-13f23c93f187
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=1748958112;
	 x=1749044512; bh=at+V2xcJ97nR3jSRC9+8kvplrdb00UPWvByJSoMoQIY=; b=
	ZSoCRzkENDx5pA0viZnPetUD76+gQuYJAqYQ5J43/VSZ3L6B5USgFsRYnaD17fwm
	+WmAxruJRnFJaOykGirdWaAXUuSDLpoYhKMBAbtb1hdztDByKXzC9GK6MwRb4Uj1
	7ZwaPQKFEtsahf4bVx4q9TnfP75om4hlOFcJQgYPX1OeYkMCgxiCfpgg/rzLGRf/
	CPFHXbKPDEOBbX6KNXcmlUJrT8rbofzSMWLjj6yWgP8B0v7P1l0lwOlXc5UtyYxd
	ZDEy6ex9Pzd7Qok7qYDxedMw1BH4kFgHqhNfoUJoLrmHZ4g3XTjpoQjG/H3vTs/2
	asVmFSaNG/O/kFU5+GIP3g==
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=
	1748958112; x=1749044512; bh=at+V2xcJ97nR3jSRC9+8kvplrdb00UPWvBy
	JSoMoQIY=; b=UWb7kU1EmBnmrRR5vpPj7c3yJv4tKE1uUFFyhzccT2kxd9fATdp
	hiEWFfwcCUTn2kbAvD431cE2aJZqZnsvgbqUGEwkQU/CVnXPFf1trRtkMKgSHSIU
	zDaSK00F+Dr8jkra3zfAF9Gk1TxsN/lQM8KoC3qmlasD5WoMiG4u9LpJV5TTpmCP
	9+aLBTGLz8dcDG8nP2OA7C+011zZ1f4DCr6nZ1oavgXaBMhiOGCFYreVX2PkYAJ0
	dR7rZvJevW5wCq31zaAN7q+bmPjNNzX2dy6rHJfwgxHqTo/u7fnk37KLqysF6V9f
	W08F0AxECd5y4Lg+5d2AZiYtqj7nAmto1BA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugdefkecutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr
    tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnth
    hsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecu
    hfhrohhmpeforghrvghkucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrg
    hrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffr
    rghtthgvrhhnpefgudelteefvefhfeehieetleeihfejhfeludevteetkeevtedtvdegue
    etfeejudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm
    pehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsg
    gprhgtphhtthhopeeipdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegrnhgurhgv
    fidrtghoohhpvghrfeestghithhrihigrdgtohhmpdhrtghpthhtoheprghnthhhohhnhi
    esgigvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhi
    shhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtoheprghnthhhohhnhidrph
    gvrhgrrhgusehvrghtvghsrdhtvggthhdprhgtphhtthhopegtrghrughovgestggrrhgu
    ohgvrdgtohhmpdhrtghpthhtohepshhsthgrsggvlhhlihhniheskhgvrhhnvghlrdhorh
    hg
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Tue, 3 Jun 2025 15:41:48 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Andrew Cooper 
Cc: Anthony PERARD , xen-devel@lists.xenproject.org,
	Anthony PERARD ,
	Doug Goldstein ,
	Stefano Stabellini 
Subject: Re: [XEN PATCH 4/9] CI: Ignore run-tools-test return value
Message-ID: 
References: <20250603124222.52057-1-anthony@xenproject.org>
 <20250603124222.52057-5-anthony@xenproject.org>
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="vBNrMdv9Uf5hM5TU"
Content-Disposition: inline
In-Reply-To: 


--vBNrMdv9Uf5hM5TU
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 3 Jun 2025 15:41:48 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Andrew Cooper 
Cc: Anthony PERARD , xen-devel@lists.xenproject.org,
	Anthony PERARD ,
	Doug Goldstein ,
	Stefano Stabellini 
Subject: Re: [XEN PATCH 4/9] CI: Ignore run-tools-test return value

On Tue, Jun 03, 2025 at 02:26:31PM +0100, Andrew Cooper wrote:
> On 03/06/2025 1:42 pm, Anthony PERARD wrote:
> > diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qu=
bes-x86-64.sh
> > index 2750d24eba..046137a4a6 100755
> > --- a/automation/scripts/qubes-x86-64.sh
> > +++ b/automation/scripts/qubes-x86-64.sh
> > @@ -135,10 +135,11 @@ done
> >      ### tests: tools-tests-pv, tools-tests-pvh
> >      "tools-tests-pv"|"tools-tests-pvh")
> >          retrieve_xml=3D1
> > -        passed=3D"test passed"
> > +        passed=3D"run-tools-test over"
> >          domU_check=3D""
> >          dom0_check=3D"
> > -/root/run-tools-tests /usr/lib/xen/tests /tmp/tests-junit.xml && echo =
\"${passed}\"
> > +/root/run-tools-tests /usr/lib/xen/tests /tmp/tests-junit.xml ||:
> > +echo \"${passed}\"
> >  nc -l -p 8080 < /tmp/tests-junit.xml >/dev/null &
> >  "
> >          if [ "${test_variant}" =3D "tools-tests-pvh" ]; then
>=20
> I noticed this too while hacking on XTF support.=C2=A0 Also of note, I'm =
not
> sure we want to be saying done to the expect script before sending the
> results.

No, expect needs to be notified before, otherwise retrieving the file
won't start.

> The underlying problem is that ${passed} isn't really a pass message;
> it's a done+pass message, and there is no way to say "failed" to the
> expect script, leaving timeout as the only option of signalling a failure.

Well, that can be changed, by adding yet another message that it looks
for, and handling it with exit 1 instead of exit 0.

> I don't think we want to be ignoring errors from run-tools-tests
> specifically, but arranging this is hard.=C2=A0 You always need something=
 at
> an outer level judging whether there was a good test result.

For those tests specifically, if changing to always say success, you
need to ensure that both finding "failure" in xml and not getting the
xml at all (or getting it malformed) is treated as a failure.

> For XTF, the way I did this was to declare that anything didn't match
> "^(Success|Error|Crash|Fail).*" on the final line of the console log to
> be deemed to be Crash (because it's usually an uncaught exception).
>=20
> For this, the best I can think of is to have a fixed outer script which
> runs "./test/script && echo $success || echo $failure".=C2=A0 The internal
> set -e will cause most unexpected conditions to be an error.
>=20
> ~Andrew

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

--vBNrMdv9Uf5hM5TU
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmg++5wACgkQ24/THMrX
1yyqGgf+P0IsdZ6Ukj2JhQv4WKEy26UpszL8IKU2qWTu02tUIz/M7Ygr5zr2yysM
ZaT6gPl+XoZRxDX95h7APxZJc/Ce8ftW7yfuw+EN37XzO24RN9K+IMTt4y5+l2ju
Sfwp4LkR3a2Kp7wlYSKAmWIjxTmslbgVxn98uQJXaUQyEvIv0c/Vw/Z5+8ux79jr
C/llwNvy8yGns7/OrwuBBWUezWdkwDLSonMZOrFoQ1r+gew0AjFnUHbiIkvAUPSc
c9jXkj8OSZc/9faTYUo3fzakGeA6jwfflFYzvDogvX1w4QXmpYfVIT5ONHfXOSkP
aEEVIoDjcLoXIagRso8ukhHS1JNvUA==
=6eKq
-----END PGP SIGNATURE-----

--vBNrMdv9Uf5hM5TU--


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 13:44:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 13:44:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004499.1384228 (Exim 4.92)
	(envelope-from )
	id 1uMRwQ-0002x6-Js; Tue, 03 Jun 2025 13:44:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004499.1384228; Tue, 03 Jun 2025 13: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 1uMRwQ-0002wz-Gp; Tue, 03 Jun 2025 13:44:34 +0000
Received: by outflank-mailman (input) for mailman id 1004499;
 Tue, 03 Jun 2025 13:44: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 1uMRwO-0002wq-PV
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 13:44:32 +0000
Received: from fout-b3-smtp.messagingengine.com
 (fout-b3-smtp.messagingengine.com [202.12.124.146])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id dd1b599d-4080-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 15:44:26 +0200 (CEST)
Received: from phl-compute-01.internal (phl-compute-01.phl.internal
 [10.202.2.41])
 by mailfout.stl.internal (Postfix) with ESMTP id 9936D114011B;
 Tue,  3 Jun 2025 09:44:28 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-01.internal (MEProxy); Tue, 03 Jun 2025 09:44:28 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 3 Jun 2025 09:44:27 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: dd1b599d-4080-11f0-b894-0df219b8e170
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=1748958268;
	 x=1749044668; bh=vnCuflfvJh5fbWIYpTtpEzKQDNyFvkkxEfvULtRVjyw=; b=
	aBBtAUHK4NZ8mIa2GuEQ8NmQZ3yKFATDd1fg8+PcjrJfjaKJvJS9V/aZxfXP78kj
	UM/TzcsmNBidkTmuaRRz5ou3t+Ej34TQkdexY/enWJvBXyAy5lrVkFU0HTAq6ywl
	dVqV4sDEvu/3QvXnVphzsA3Hdexng6lLLxmzqKT1TR1h6OXveh6q9AUC2QQ+OnFT
	YOi2c7Hfr0lP3YiyojjeDmh2rpY6n8x98wDr4MTCklEzVdt6j19FjjNFJsqc3UFk
	cmE+GBSW1sQX1jr6Io4H0XOnbDjE1/qaFVUZrtyjhc1YcpdhBOn40YGBLPCMvkjg
	1UbkZ5lZNeCUdApO98k3Cg==
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=
	1748958268; x=1749044668; bh=vnCuflfvJh5fbWIYpTtpEzKQDNyFvkkxEfv
	ULtRVjyw=; b=PVmAb8umEAe7X6DJ3xUz5y6+ZO1Y3TxG22thNc5ZsSVWm1go4Uw
	9HKlQoPYRjfwecdlhdefaY3iiSV1LAFoPpH3R2J0yNumgWC9kACtp4oEx/0/oKPY
	gvJYPWjCyo/fJukStWibfGADif3tg66WvYS0FA4l5s9zdFPq3GrkggfU3jNgJvtT
	zh6+6gU7urMGIaZq20E/BDfvFmprC69lqiTaV6HSpyL4KgluMsHXUB7UvVFKoF1D
	A6jW7lA3x+UFOHhYanSQsItx1Y28jKOpuxnfLWchpgdMIlXEQcFYQeYZXybkMEG9
	uWhp2RXbB96cCwuO9C0Ue+EwP0hZgN4drdA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugdeflecutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr
    tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnth
    hsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecu
    hfhrohhmpeforghrvghkucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrg
    hrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffr
    rghtthgvrhhnpeevueejteegleelteduueevhfetgfffjeevtddvgfeiveehteehleegue
    elvdejveenucffohhmrghinhepghhithhlrggsrdgtohhmnecuvehluhhsthgvrhfuihii
    vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhvihhsih
    gslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepiedpmhhouggvpehs
    mhhtphhouhhtpdhrtghpthhtoheprghnughrvgifrdgtohhophgvrhefsegtihhtrhhigi
    drtghomhdprhgtphhtthhopegrnhhthhhonhihseigvghnphhrohhjvggtthdrohhrghdp
    rhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdroh
    hrghdprhgtphhtthhopegrnhhthhhonhihrdhpvghrrghrugesvhgrthgvshdrthgvtghh
    pdhrtghpthhtoheptggrrhguohgvsegtrghrughovgdrtghomhdprhgtphhtthhopehssh
    htrggsvghllhhinhhisehkvghrnhgvlhdrohhrgh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Tue, 3 Jun 2025 15:44:24 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Andrew Cooper 
Cc: Anthony PERARD , xen-devel@lists.xenproject.org,
	Anthony PERARD ,
	Doug Goldstein ,
	Stefano Stabellini 
Subject: Re: [XEN PATCH 5/9] CI: Have the gitlab job fail on tools/tests
 failure
Message-ID: 
References: <20250603124222.52057-1-anthony@xenproject.org>
 <20250603124222.52057-6-anthony@xenproject.org>
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="Mr2DUhFd65wkulsj"
Content-Disposition: inline
In-Reply-To: 


--Mr2DUhFd65wkulsj
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 3 Jun 2025 15:44:24 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Andrew Cooper 
Cc: Anthony PERARD , xen-devel@lists.xenproject.org,
	Anthony PERARD ,
	Doug Goldstein ,
	Stefano Stabellini 
Subject: Re: [XEN PATCH 5/9] CI: Have the gitlab job fail on tools/tests
 failure

On Tue, Jun 03, 2025 at 02:41:50PM +0100, Andrew Cooper wrote:
> On 03/06/2025 1:42 pm, Anthony PERARD wrote:
> > From: Anthony PERARD 
> >
> > We can't rely on an exit value from `run-tools-tests` since we only
> > have the console output. `console.exp` only look for success or it
> > times out. We could parse the console output, but the junit is more
> > concise. Also check if we have it or fail as well.
> >
> > Signed-off-by: Anthony PERARD 
> > ---
> >  automation/scripts/qubes-x86-64.sh | 7 +++++++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qu=
bes-x86-64.sh
> > index 046137a4a6..7a4c5ae489 100755
> > --- a/automation/scripts/qubes-x86-64.sh
> > +++ b/automation/scripts/qubes-x86-64.sh
> > @@ -298,6 +298,13 @@ TEST_RESULT=3D$?
> > =20
> >  if [ -n "$retrieve_xml" ]; then
> >      nc -w 10 "$SUT_ADDR" 8080 > tests-junit.xml  > +    # Findout if one of the test failed
> > +    if ! grep -q '' tests-junit.xml; then
> > +        echo "ERROR: tests-junit.xml is incomplete or missing."
> > +        TEST_RESULT=3D1
> > +    elif grep -q '' tests-junit.xml; then
> > +        TEST_RESULT=3D1
> > +    fi
> >  fi
> > =20
> >  exit "$TEST_RESULT"
>=20
> A couple of things.
>=20
> From my experimentation with junit,
> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/184934222=
2/test_report?job_name=3Dkbl-xtf-x86-64-gcc-debug
> we can also use  for classification.=C2=A0 I'm also very disappoi=
nted
> in Gitlab classifying  as success.
>=20
> Not for this patch, but for XTF I need to be able to express "tolerable
> failure".=C2=A0 (All branches of Xen will run the same tests, and we don't
> have OSSTest to deem "fail never passed" as non-blocking.)
>=20
> Even if the job passes overall, I want tolerable failures to show up in
> the UI, so I have to use  in junit.xml.=C2=A0 But that means nee=
ding
> to be more selective, and I don't have a good idea of how to do this.=C2=
=A0
> (I have one terrible idea, which is  which
> will escape that grep, but it feels like (ab)buse of XML.)

But that automation/ dir (including the run-tools-tests script) is
per-branch, so you can specify there which tests should be considered
failure and which just warning, no? It will require few more bits in the
script, but fundamentally shouldn't be a problem?

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

--Mr2DUhFd65wkulsj
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmg+/DkACgkQ24/THMrX
1yzqtwf/dXxEpoK1ZgAqLd2T+rmMmkC1Sgzevk9Gsy0FG3twjrRbYJ6tXhkeGSFD
JjdFHR9+Nkcr32zAlonr/i2E4PLicYURPHsDXHyG7HFc/7vDPg4GPBsrzdDdDAc2
Lc5F2q1RQSSAXmkSAsxqHHFhY+0mrw5JZEA7KTdWCElUpzDPq/f7/iji+0/BLakb
1VCgGVD8a5SCuVxX7VqRNjfrZPH73OyrSAjlIPhwmKgdtWy0OAGgjmyoscNrz8f5
6+mZZ4wQj0nyiQckwD3igckbHVXYaZQpqa2AEqK6JVgobeMEPpFeK8BQCFd6HyAm
egOsOL9oxmEzr9bLvsMUn9UiCI11AA==
=R2pf
-----END PGP SIGNATURE-----

--Mr2DUhFd65wkulsj--


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 14:09:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 14:09:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004513.1384237 (Exim 4.92)
	(envelope-from )
	id 1uMSKe-0006TJ-EW; Tue, 03 Jun 2025 14:09:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004513.1384237; Tue, 03 Jun 2025 14:09: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 1uMSKe-0006TC-Bk; Tue, 03 Jun 2025 14:09:36 +0000
Received: by outflank-mailman (input) for mailman id 1004513;
 Tue, 03 Jun 2025 14:09: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 1uMSKc-0006T5-Sz
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 14:09: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 5fa1c73c-4084-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 16:09:33 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3a50fc7ac4dso1163244f8f.0
 for ; Tue, 03 Jun 2025 07:09:33 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a4efe5b92bsm18151905f8f.9.2025.06.03.07.09.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 03 Jun 2025 07:09:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5fa1c73c-4084-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748959773; x=1749564573; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=28wcA/4J7tuGdXetpGefwBKi0uYNHb5+EE/7GG8Imj0=;
        b=MbqkfODwgUCnFtCkcvS4n5m1wFA8M1vdtA2lJfEvAqeOZOGasvMDzkK/VlhUfCgEiU
         FW0pxdVbSZvK7dNqj5NuY6839m+AO/YSXaIcOM/Xe1jK4A90yZnZNTxT0UKuY1beo8a/
         1XY8XCD84Dddt+2SiYBl1UQdmozFmYCgfmoks=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748959773; x=1749564573;
        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=28wcA/4J7tuGdXetpGefwBKi0uYNHb5+EE/7GG8Imj0=;
        b=oB72jb1kdXUGSQEXEj8nql1j5yNMdLZvxOMH4lNjmG7FWlrHUhE6TukuLUME75sDZh
         ZmfqF/uDwhP2v+f0i9VvnkcXNkZY+2i6h7jYyBNLz3vyLPlAQSBNY0YcLiAWnwiisA0Q
         RT0sVzsHUalgU31CrDhkTSNxzuRTrfc/ALCN26KqdgS0/E7eD6MQZKm76G9nMAdEx75L
         FsN3ksenm8ivOU0P/2wSxbyGK8uYNyfw6sdhzB4xkyJGVntg+6xIJP+ZPQYH7d13H//A
         0Z18wTgsl/sudYbPP2XUG84u2xC27EJvBTnnn2En1auq/3xk31M5/9fEb0t8rfJmFwrx
         nQiw==
X-Forwarded-Encrypted: i=1; AJvYcCUdBZQWHBWzjJIF8+Wh/szjldf12eOonvcm6NsdlLyLdt/LJx9QUHeNR8MBr5dHSZ7s5uetqd2LWMg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzu+FCC8pthwa2wmnwTFbaRxKlCbegP638eI54+wPfLGTYt3dHb
	Xn7lbtr46LHYuUOWtPPUgEom7uEeX+nwM3deU5cTcmInaLyiB+u1YfQsNcB6wMeLtBk=
X-Gm-Gg: ASbGncvbGIZ+m2638lrlLrT0h3Ci5sFB1CAcEHzj+zvnSYAK1N1YQ68ELypcdBFpKCs
	LZacHIip4dDcuWQUZ48cqmAA8zJq+hDvfx9gBqNwP1ZV8X+4BmnHuO2q6tBvM7uK4XC50M1/JHx
	pGqpAU6kfBW10ukKpWgLtGELv3ToX9wAi+n7yev11B5p04pWFt48gIroP1a2mxlT3sQsf4YDsKE
	bmg0YEZKwAnaurhfeQzszK++3zRcyiZn56g7wu42x8Zk+F1DPEb2/cwZYZ4l/tZDX5h7kEi2Ap7
	yTnAyOvtsAXPKxptTMf8Dx6sODuCSQbbqH4khi+6pyEN7yKwNEm9hRjAR/rN0DatqDLyp1eCAIQ
	26xEKp0XGr8p0vRD0
X-Google-Smtp-Source: AGHT+IEXVckzvDFeMXZzOyfMLkFnVv3w3pscZKorSjZrTDx/Sb0dbtMLfPyNqiRj4TFLxJz6rbQbVA==
X-Received: by 2002:a05:6000:288c:b0:3a4:dd02:f724 with SMTP id ffacd0b85a97d-3a4f7a9d48amr14467649f8f.43.1748959772695;
        Tue, 03 Jun 2025 07:09:32 -0700 (PDT)
Message-ID: <7e545be5-bcfa-46f7-b2b6-bee8c258f91c@citrix.com>
Date: Tue, 3 Jun 2025 15:09:31 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 5/9] CI: Have the gitlab job fail on tools/tests
 failure
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 
Cc: Anthony PERARD , xen-devel@lists.xenproject.org,
 Anthony PERARD ,
 Doug Goldstein ,
 Stefano Stabellini 
References: <20250603124222.52057-1-anthony@xenproject.org>
 <20250603124222.52057-6-anthony@xenproject.org>
  
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/06/2025 2:44 pm, Marek Marczykowski-Górecki wrote:
> On Tue, Jun 03, 2025 at 02:41:50PM +0100, Andrew Cooper wrote:
>> On 03/06/2025 1:42 pm, Anthony PERARD wrote:
>>> From: Anthony PERARD 
>>>
>>> We can't rely on an exit value from `run-tools-tests` since we only
>>> have the console output. `console.exp` only look for success or it
>>> times out. We could parse the console output, but the junit is more
>>> concise. Also check if we have it or fail as well.
>>>
>>> Signed-off-by: Anthony PERARD 
>>> ---
>>>  automation/scripts/qubes-x86-64.sh | 7 +++++++
>>>  1 file changed, 7 insertions(+)
>>>
>>> diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qubes-x86-64.sh
>>> index 046137a4a6..7a4c5ae489 100755
>>> --- a/automation/scripts/qubes-x86-64.sh
>>> +++ b/automation/scripts/qubes-x86-64.sh
>>> @@ -298,6 +298,13 @@ TEST_RESULT=$?
>>>  
>>>  if [ -n "$retrieve_xml" ]; then
>>>      nc -w 10 "$SUT_ADDR" 8080 > tests-junit.xml >> +    # Findout if one of the test failed
>>> +    if ! grep -q '' tests-junit.xml; then
>>> +        echo "ERROR: tests-junit.xml is incomplete or missing."
>>> +        TEST_RESULT=1
>>> +    elif grep -q '' tests-junit.xml; then
>>> +        TEST_RESULT=1
>>> +    fi
>>>  fi
>>>  
>>>  exit "$TEST_RESULT"
>> A couple of things.
>>
>> From my experimentation with junit,
>> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1849342222/test_report?job_name=kbl-xtf-x86-64-gcc-debug
>> we can also use  for classification.  I'm also very disappointed
>> in Gitlab classifying  as success.
>>
>> Not for this patch, but for XTF I need to be able to express "tolerable
>> failure".  (All branches of Xen will run the same tests, and we don't
>> have OSSTest to deem "fail never passed" as non-blocking.)
>>
>> Even if the job passes overall, I want tolerable failures to show up in
>> the UI, so I have to use  in junit.xml.  But that means needing
>> to be more selective, and I don't have a good idea of how to do this. 
>> (I have one terrible idea, which is  which
>> will escape that grep, but it feels like (ab)buse of XML.)
> But that automation/ dir (including the run-tools-tests script) is
> per-branch, so you can specify there which tests should be considered
> failure and which just warning, no? It will require few more bits in the
> script, but fundamentally shouldn't be a problem?
>

XTF is in a separate repo and does not have branches.

Now consider
https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=d965e2ee07c56c341d8896852550914d87ea5374,
and testing it.

Anything I put into XTF to test it will pass on staging but fail on the
older stable-* trees.  In due course it will get backported to the
bugfix branches, but it likely won't get fixed on the security-only
branches.

Furthermore, I need to not change xen.git to make this work, and older
branches need to pick up newer XTF automatically.  (XSA tests *are*
expected to pass everywhere once the issue is public.)

My current plan is to have logic of the form:

if ( xenver >= $STAGING )
    xtf_failure(...);
else
    xtf_success("Expected Failure:" ...);

where $STAGING moves when backports get done.  I still want the failures
to show up in the Tests UI.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 14:12:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 14:12:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004525.1384248 (Exim 4.92)
	(envelope-from )
	id 1uMSNY-0008LV-1M; Tue, 03 Jun 2025 14:12:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004525.1384248; Tue, 03 Jun 2025 14: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 1uMSNX-0008LO-Tb; Tue, 03 Jun 2025 14:12:35 +0000
Received: by outflank-mailman (input) for mailman id 1004525;
 Tue, 03 Jun 2025 14:12: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 1uMSNX-0008LI-Ev
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 14:12:35 +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 cbc00204-4084-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 16:12:34 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3a4f379662cso4449377f8f.0
 for ; Tue, 03 Jun 2025 07:12:34 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a4f009ff7asm18684433f8f.90.2025.06.03.07.12.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 03 Jun 2025 07:12:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cbc00204-4084-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748959954; x=1749564754; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=xjmTYl8OxfXtbZBhYtLhFDJDlt08sG7sjuITSZQLHyk=;
        b=czGyjkSZxyeHiAmhCHHDolBAl/itHWGgrUdzAFqcr0VaqTB+YwZu0C83OVOW3Zvykn
         +Inm/60TXYBd/PT7EQO4HhfZDoGzcmm7yv+9193hY8HRIRO9glgwCCQLYOx1uVeQ8ZpS
         JuiWrVItkZYH4Xhxw6wsOHZ0VEQDFeB2HsHXk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748959954; x=1749564754;
        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=xjmTYl8OxfXtbZBhYtLhFDJDlt08sG7sjuITSZQLHyk=;
        b=mZZJNcchvIvcb+/VTq1Oh3NxV6kBXZAXUJIehzMg0gb4GkLY8BWWCRDYewMq8UJDvK
         Dl/C3GhYqOAzLZ10Z/bDyWs7W8eepXuP/8/m2GkEZ5KSzxVNtt6+4osLkD5GCgSc6hn+
         13sipqA80fV8TMQJIlD3ZXm4PFGbS9ozHS2X6lhvAw7Zyx1BsmLibuK8syXYydXlBsbQ
         KAhYzuIQPNoIY0u7I2nLTIxorc2BZkpUNMngunpSmUhfZc3dyosqMzRzXx2jawnocSgL
         71DegwSbGqiPQZx9t449xKHPOFxQURAWxRaBLOI7Geela68mk2Z95p0LTA8AlTeioRJU
         RPMA==
X-Forwarded-Encrypted: i=1; AJvYcCUs49f20B0FlE1MbS1Psz5h0gxKGumQyQtU4aIDdME+hShLHhQGp0Z7IhTebPOj9TqAM1NJ5232QMw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxxe+G3Fp7hMehuh1VUaVBP//YCanbGG0D3GOopAxHMG9CgOeI+
	aCl267pH6BdQEsBqlNriCFpBMjCSY0jmpIjWugDm3Jft3iFynbbkXEHm4E9S91gqa+k=
X-Gm-Gg: ASbGncsy3uwsTsbztXBEUuLpDm8BY3sGNzlx42fha1RjUA3gnUe3ZHDFq/jdrJHCOKL
	uhYWkQnWBX/mPMRJo9ae3ZNXnsBkUJKY9lXPTZEjYapSbNzGDO55fW7PNBEtaXUIC4YVLXMbkW6
	Kii4CXlDDS2qdhExbkTqOv4/bkJt0ENwNoNVURJ4HKiLJJehsaKBzFPC4CD1KcLjVF2IFxlA6Mt
	NyQ6BT6ld35ETOXkVWyahOggZC+gWdNrWI+ohpx8uh5tWp1Q3bZxf3ywsDcV10+w/dPM87GV5ot
	PRnwiNP84GrmBL3PezZuL45DjAddnglkqusfsoiqQ7+bWugtjjXgBJpB9B7EnYGY50iocWsBGp0
	EK2m6ezRlADcKYHjt9StVAbOJtZY=
X-Google-Smtp-Source: AGHT+IGGgX+/jpAfumrhng1e13HR3ua6uvBQrBVvGc2j8KAcBVsvFdkwIqNjNYauOtcKxr5nE7STZw==
X-Received: by 2002:adf:eacb:0:b0:3a4:ef36:1f4d with SMTP id ffacd0b85a97d-3a4fe391bc4mr7803029f8f.38.1748959954137;
        Tue, 03 Jun 2025 07:12:34 -0700 (PDT)
Message-ID: <86d3655f-f541-441e-bb6c-1dda0b03540f@citrix.com>
Date: Tue, 3 Jun 2025 15:12:32 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 8/9] CI: Workaround extra content in junit
To: Anthony PERARD , xen-devel@lists.xenproject.org
Cc: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , Anthony PERARD
 , Doug Goldstein ,
 Stefano Stabellini 
References: <20250603124222.52057-1-anthony@xenproject.org>
 <20250603124222.52057-9-anthony@xenproject.org>
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: <20250603124222.52057-9-anthony@xenproject.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 03/06/2025 1:42 pm, Anthony PERARD wrote:
> From: Anthony PERARD 
>
> Signed-off-by: Anthony PERARD 
> ---
>  automation/scripts/qubes-x86-64.sh | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qubes-x86-64.sh
> index 7a4c5ae489..6ab8412f45 100755
> --- a/automation/scripts/qubes-x86-64.sh
> +++ b/automation/scripts/qubes-x86-64.sh
> @@ -298,6 +298,12 @@ TEST_RESULT=$?
>  
>  if [ -n "$retrieve_xml" ]; then
>      nc -w 10 "$SUT_ADDR" 8080 > tests-junit.xml  +    # Workaround duplicated data been received
> +    sed -i.old '/^<\/testsuites>/q' tests-junit.xml > /dev/null
> +    extra_line_in_junit=$(($(wc -l < tests-junit.xml.old) - $(wc -l < tests-junit.xml)))
> +    if [ $extra_line_in_junit -gt 0 ]; then
> +        echo "WARNING: Found $extra_line_in_junit too many lines in junit."
> +    fi

Is this the cause of
https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1849342222/test_report
getting a row of 0's for ADL ?

Why are we getting duplicate data?  nc is running in TCP mode, not UDP,
so it's not that.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 14:16:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 14:16:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004532.1384258 (Exim 4.92)
	(envelope-from )
	id 1uMSRK-0000Tz-Fg; Tue, 03 Jun 2025 14:16:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004532.1384258; Tue, 03 Jun 2025 14:16: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 1uMSRK-0000Ts-Bt; Tue, 03 Jun 2025 14:16:30 +0000
Received: by outflank-mailman (input) for mailman id 1004532;
 Tue, 03 Jun 2025 14:16: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 1uMSRJ-0000Tl-Lv
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 14:16:29 +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 54b5a63d-4085-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 16:16:24 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-441d437cfaaso39139075e9.1
 for ; Tue, 03 Jun 2025 07:16:27 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a4efe6c842sm18186772f8f.29.2025.06.03.07.16.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 03 Jun 2025 07:16:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 54b5a63d-4085-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748960187; x=1749564987; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=yw0+f7BJLdAUZiURTz5Gc9U5JJQs3FyRngWcjGXPPFc=;
        b=mkFD9tTG6wGgiwqBvh+wgWHcEasCMkORznLkE8xVeuLSiWAdIuuQRWTvJxIoQVZQ7W
         m769U/cboETXRbJ5lNoKE/f4aONc6R22ynGzG80N5yR8yIxTEi/4TxwNnrOSzeeKxzJO
         lZrwXemQ00uoR4WNsaYr04b178/1VMSUwzeCs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748960187; x=1749564987;
        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=yw0+f7BJLdAUZiURTz5Gc9U5JJQs3FyRngWcjGXPPFc=;
        b=AfekpoooQ6NKiPtAP83gzYN1Fx7f9yF70UCzkx++y5XBINyhMqALuZcnHlyQ5/1XX+
         gpNq5bbEF2rijXbWtEyPQ+uGk+WqVnb7baeC/WlptyK/ScuDHC5Bbds1kNmlY1NAmPaW
         +kJX3RM7kR6dWR5r5Uou6yDq7+DLca+ks1hVSkVtyuvJJgnleyCqJaM9fJifLsEQ9D3Y
         S7LEvRQlaA3vhPd9KfIGe5EmHO/2GW3mo9FeXjbiFd9wKBr+K1dTmW9McKPhCDLBVXhc
         pfyo0Ry/eWr7WzmZLgNaVJUaZPr9fJtsDTuuHRWpaa1TRIH83QKNteMrnbLMaDNdRwHB
         QtyQ==
X-Forwarded-Encrypted: i=1; AJvYcCU7qDKnLdesS0fMSTh6rtQiC0L6k7SqCF05hpiMFCA/xg+N7RHKp/SRnKsM4OC9c/wwIquX8GT37+Q=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxv2xXctHDnfbX1EJyVW8BsPhEPETLwnF7e4gVeOB1IAiKoE/V8
	LmSu3w0cDSXtc3SF6in9JaGePGj88ofUFY7rkcEP+TUycpyVbCpd+td6Z2UVdV24WYk=
X-Gm-Gg: ASbGncvrMwZsyXLLkHzm7vYkzaMdwlu4ZxqMgLJz1lhcEHmMXAsUWLTX4zR6pGH242X
	gkODP/R7jDhy6sAMdazuSW/aEiijTEGylHZS2g8DNKaiimRElLjxLIiV27P+nEKhKC1+ewysem4
	wbp/sn4L8B6NwhCTu0hp388HMnulel5i6wMWM4WEldd/g5P5xVpf90N50smE6hnERZlqDbjW3uY
	CvV8KEAiBOm7DpLyFE4/tJC9Y8KLN5EqYD9ltGLzz2Z7VsVOdbISTJN2UVwjzw8kFryZTR3vFJO
	wrjWHtp261hTB/C5UC55iQ72MIxkyawiE1Vul9UFK9wJ8jDjYXwwYoNST+Jo1fENxOqugIfh28P
	w7Gnrp2gdFfzLckDd
X-Google-Smtp-Source: AGHT+IFfJRs/Szwtq4iZ0OHZqQZIThzeum1Qg6P0iWiceJcXG8t9xTQoxuJ1An7ppDKVQ3N06Jd2GQ==
X-Received: by 2002:a5d:5f8b:0:b0:3a4:e841:b236 with SMTP id ffacd0b85a97d-3a4f89ddd6fmr14482333f8f.33.1748960187029;
        Tue, 03 Jun 2025 07:16:27 -0700 (PDT)
Message-ID: 
Date: Tue, 3 Jun 2025 15:16:25 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 9/9] CI: Add timing to junit
To: Anthony PERARD , xen-devel@lists.xenproject.org
Cc: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , Anthony PERARD
 , Doug Goldstein ,
 Stefano Stabellini 
References: <20250603124222.52057-1-anthony@xenproject.org>
 <20250603124222.52057-10-anthony@xenproject.org>
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: <20250603124222.52057-10-anthony@xenproject.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 03/06/2025 1:42 pm, Anthony PERARD wrote:
> From: Anthony PERARD 
>
> Signed-off-by: Anthony PERARD 

Acked-by: Andrew Cooper 

> ---
>  automation/scripts/run-tools-tests | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/automation/scripts/run-tools-tests b/automation/scripts/run-tools-tests
> index 852c1cfbcf..e38cc4068c 100755
> --- a/automation/scripts/run-tools-tests
> +++ b/automation/scripts/run-tools-tests
> @@ -18,9 +18,12 @@ for f in "$1"/*; do
>          continue
>      fi
>      echo "Running $f"
> -    printf '  \n' "$f" >> "$xml_out"
> +    time_start=$EPOCHREALTIME
>      "$f" 2>&1 | tee /tmp/out
>      ret=${PIPESTATUS[0]}
> +    time_end=$EPOCHREALTIME
> +    time_test="$(bc <<<"$time_end - $time_start")"
> +    printf '  \n' "$f" "$time_test" >> "$xml_out"

I'd suggest $time_delta rather than $time_test.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 14:26:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 14:26:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004542.1384267 (Exim 4.92)
	(envelope-from )
	id 1uMSar-0002ZS-A4; Tue, 03 Jun 2025 14:26:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004542.1384267; Tue, 03 Jun 2025 14:26: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 1uMSar-0002ZL-7C; Tue, 03 Jun 2025 14:26:21 +0000
Received: by outflank-mailman (input) for mailman id 1004542;
 Tue, 03 Jun 2025 14:26: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 1uMSap-0002Z9-Te
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 14:26:19 +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 b666289d-4086-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 16:26:18 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-442f9043f56so34808225e9.0
 for ; Tue, 03 Jun 2025 07:26:18 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a4f00971e4sm18765109f8f.65.2025.06.03.07.26.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 03 Jun 2025 07:26:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b666289d-4086-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748960777; x=1749565577; 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=c1d7pHUH7DhuO7y/k5Cv73v2UJqOlyFolZ+8cHMZUDI=;
        b=Xmi5Ela1ezP5sg0vt5IMTwPy7d60lr9f2Qpc5yvk28WfjiBvxOHtFvWVoUumUPKWrK
         lttuL6g9/TDiK7ankl0u6NeuETIucIfEZ96kK4g7r2OtB6bLumTFK0HLUC70IzWRFcpI
         rA24AEkBhzLeIQ9GBd4rgAKM83Xg9S+PVY560=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748960777; x=1749565577;
        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=c1d7pHUH7DhuO7y/k5Cv73v2UJqOlyFolZ+8cHMZUDI=;
        b=W3KAMcl7IxuoPIWyMJeGlJ1CyGwWjv2xgOK4bsS6QjWwAm9HyYWHMUFe61aUhar8Qu
         5rQgTusHGGiNdL9Rsov3jPdt+deiJlkZLMwkZ6yNiTR8cAd1wwrlvYN83OfagMRVHbWt
         trabRUmkJkBvNnB2zGJO23X5dg+jpyZxRndI9HpudRfPnGi4CW9IA7OJAACKV98b4rLp
         8V30yL6n4jBt4nvC0zLFJ6xMOaw2Bp4h92zRzIuZD2kg4TZ69MDPN743Oy1vBMe+T5Ud
         iSKqyHfcGmF5o43xTDWdN7x1DO0m57UTG3TNsRyw3T3RVqRDcgF1HuoIeK9Oy5dnIiyq
         obYQ==
X-Forwarded-Encrypted: i=1; AJvYcCUrS9P1Fl3AFp8NiRA2ULsmFLXiSsxFO92UVAKVtJX0G2mQfDpeZcmkS5ckN20N4vXl3MXl8QqWqXc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyMu0cdfHeBVxmPcleKD+q0HTok3vuD3jpGGefZkD9EpuEIeaQP
	7HIjTKcN+SguFy1ZgAvX17aYbm1grl9dZzBxldxr1TgE2vNZg/qxwLG8gFzx8Tx205Q=
X-Gm-Gg: ASbGncsnnSDkFZZcQXGk2VZRGMxNImaw37SAgPycuNmZlo4Mlwqz8gEUj6/y+zRhJa+
	0YfPg/9mnQLw8lmrU2cmS6YLEIWf7GWSFUkNwG5mC8ozOHXv14wHBEsYtujp4HOSeWovIidm4za
	QCtibH8tv5iQOc0/qiiFw0KdNGe9ffCxhXKJM8nWhlq3EtlE/foZ7AV0kNXHdA/g3qnG+7K2zBi
	vLgzkLAUAPg0BsYJ/nytvuCYwyK8QxGO04klRI3zqDi2tFY1jTsvVf24+RaB/zaziNpK58EgElC
	kYfpOvx3u6sRmKBsgEBs7oA8w3XpZQxS5JKGLmiZi2H3P0weXbsAFZxS3n+eE9kFsuRND/Pj93Q
	NkI1fOochmLmnT6xR
X-Google-Smtp-Source: AGHT+IEp19aI7RJE6Gq625SPmnCewdA0ZEC7ow8HeR+xdftPOToxUin/ix9i4CGY4WPAiMJcJBKXaA==
X-Received: by 2002:a05:6000:178e:b0:3a4:ed1e:405b with SMTP id ffacd0b85a97d-3a4fe39909bmr9843888f8f.46.1748960777242;
        Tue, 03 Jun 2025 07:26:17 -0700 (PDT)
Message-ID: 
Date: Tue, 3 Jun 2025 15:26:15 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 5/9] CI: Have the gitlab job fail on tools/tests
 failure
From: Andrew Cooper 
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 
Cc: Anthony PERARD , xen-devel@lists.xenproject.org,
 Anthony PERARD ,
 Doug Goldstein ,
 Stefano Stabellini 
References: <20250603124222.52057-1-anthony@xenproject.org>
 <20250603124222.52057-6-anthony@xenproject.org>
  
 <7e545be5-bcfa-46f7-b2b6-bee8c258f91c@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: <7e545be5-bcfa-46f7-b2b6-bee8c258f91c@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 03/06/2025 3:09 pm, Andrew Cooper wrote:
> On 03/06/2025 2:44 pm, Marek Marczykowski-Górecki wrote:
>> On Tue, Jun 03, 2025 at 02:41:50PM +0100, Andrew Cooper wrote:
>>> On 03/06/2025 1:42 pm, Anthony PERARD wrote:
>>>> From: Anthony PERARD 
>>>>
>>>> We can't rely on an exit value from `run-tools-tests` since we only
>>>> have the console output. `console.exp` only look for success or it
>>>> times out. We could parse the console output, but the junit is more
>>>> concise. Also check if we have it or fail as well.
>>>>
>>>> Signed-off-by: Anthony PERARD 
>>>> ---
>>>>  automation/scripts/qubes-x86-64.sh | 7 +++++++
>>>>  1 file changed, 7 insertions(+)
>>>>
>>>> diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qubes-x86-64.sh
>>>> index 046137a4a6..7a4c5ae489 100755
>>>> --- a/automation/scripts/qubes-x86-64.sh
>>>> +++ b/automation/scripts/qubes-x86-64.sh
>>>> @@ -298,6 +298,13 @@ TEST_RESULT=$?
>>>>  
>>>>  if [ -n "$retrieve_xml" ]; then
>>>>      nc -w 10 "$SUT_ADDR" 8080 > tests-junit.xml >>> +    # Findout if one of the test failed
>>>> +    if ! grep -q '' tests-junit.xml; then
>>>> +        echo "ERROR: tests-junit.xml is incomplete or missing."
>>>> +        TEST_RESULT=1
>>>> +    elif grep -q '' tests-junit.xml; then
>>>> +        TEST_RESULT=1
>>>> +    fi
>>>>  fi
>>>>  
>>>>  exit "$TEST_RESULT"
>>> A couple of things.
>>>
>>> From my experimentation with junit,
>>> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1849342222/test_report?job_name=kbl-xtf-x86-64-gcc-debug
>>> we can also use  for classification.  I'm also very disappointed
>>> in Gitlab classifying  as success.
>>>
>>> Not for this patch, but for XTF I need to be able to express "tolerable
>>> failure".  (All branches of Xen will run the same tests, and we don't
>>> have OSSTest to deem "fail never passed" as non-blocking.)
>>>
>>> Even if the job passes overall, I want tolerable failures to show up in
>>> the UI, so I have to use  in junit.xml.  But that means needing
>>> to be more selective, and I don't have a good idea of how to do this. 
>>> (I have one terrible idea, which is  which
>>> will escape that grep, but it feels like (ab)buse of XML.)
>> But that automation/ dir (including the run-tools-tests script) is
>> per-branch, so you can specify there which tests should be considered
>> failure and which just warning, no? It will require few more bits in the
>> script, but fundamentally shouldn't be a problem?
>>
> XTF is in a separate repo and does not have branches.
>
> Now consider
> https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=d965e2ee07c56c341d8896852550914d87ea5374,
> and testing it.
>
> Anything I put into XTF to test it will pass on staging but fail on the
> older stable-* trees.  In due course it will get backported to the
> bugfix branches, but it likely won't get fixed on the security-only
> branches.
>
> Furthermore, I need to not change xen.git to make this work, and older
> branches need to pick up newer XTF automatically.  (XSA tests *are*
> expected to pass everywhere once the issue is public.)
>
> My current plan is to have logic of the form:
>
> if ( xenver >= $STAGING )
>     xtf_failure(...);
> else
>     xtf_success("Expected Failure:" ...);
>
> where $STAGING moves when backports get done.  I still want the failures
> to show up in the Tests UI.

P.S. I'm planning to teach ./xtf-runner how to write out a junit.xml
directly.  I'm not interested in interpreting python's stdout and
writing xml in shell...

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 14:49:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 14:49:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004558.1384287 (Exim 4.92)
	(envelope-from )
	id 1uMSxg-0006FB-CH; Tue, 03 Jun 2025 14:49:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004558.1384287; Tue, 03 Jun 2025 14:49: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 1uMSxg-0006F4-9g; Tue, 03 Jun 2025 14:49:56 +0000
Received: by outflank-mailman (input) for mailman id 1004558;
 Tue, 03 Jun 2025 14: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 1uMSxe-00060n-Ew
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 14:49:54 +0000
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com
 [2a00:1450:4864:20::132])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 026192d2-408a-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 16:49:54 +0200 (CEST)
Received: by mail-lf1-x132.google.com with SMTP id
 2adb3069b0e04-5532f9ac219so6451492e87.1
 for ; Tue, 03 Jun 2025 07:49:53 -0700 (PDT)
Received: from gmail.com (213-67-3-247-no600.tbcn.telia.com. [213.67.3.247])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-55350cab690sm450194e87.53.2025.06.03.07.49.51
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 03 Jun 2025 07:49:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 026192d2-408a-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748962192; x=1749566992; darn=lists.xenproject.org;
        h=content-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=Ob3NsRzu/zCymMrGjnHAxZ8pg1NKaHtYVDfNAqbwUHM=;
        b=hTaRQz4yfHvsrf2w+aDot75LJs2aMl93grs+cPErncdF2GeEyF7V87fqtS1Rm2t+BA
         8UhEkdcUzASB5rxzbKxaBUq7bnMpcFtxRRBor3om0cCW/PEu9XaQM9ro5ZRc/sfnMyPC
         /0MgBJjhKf1S4daNNEPTBsCkhzaQFb1sic8R8zZt+B3flDVqtLtUF97ov0R2aa1VQZiN
         zHqkGfgE5lqhOs73vsX68Sr6uEEGFKJECwmJWg/oI+Z/nCP/o2dUwniHKUsAVg96xWtv
         N2eo0scE/LQlvjNVJJoS4mFYLSjvQ2MYMcj+oaG67zYIhSWjZDnXQDeEwD17BcN5vFcc
         mkPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748962192; x=1749566992;
        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=Ob3NsRzu/zCymMrGjnHAxZ8pg1NKaHtYVDfNAqbwUHM=;
        b=PSbrK/rYao85pApEvv8gJ5k5PLqb1btZ0bN4LyJqBvapD8eqCaOvVLfPgmQpatuZiD
         CMrnZ+dL7R3mPFwmpc5IHvDMhjYt8xhwmh2umjJFaDMknNAp2n8qCtIpXNll1SV/jT5S
         8BhYQuKhEf34IfxTcvYnMr7Wsbq04ihS6W/xG2wx6oJL6LhuK8TPv0v45HmO4fgCdox0
         2uNsREYwmCTodYWZTujjYsF5QPBQgMFB52ZuL4qp4ecbyD/8P9tG7kecH0HBOJDWL2xh
         WMXFWeiGhq7zo+X3hAMFX5NP90z27HutmCNRYCA6eLd6/Kdrg4LUQldvzERKlEMP1FaQ
         Tlkw==
X-Gm-Message-State: AOJu0Ywt/3viN6ia6scl3RxnC3bJZXsENHaqUi8qIfmqHXtODYripqj1
	+dJV+QZwBnQV4vclmILDRxs/0mrQl6KydPGNfPVIfWLrovDDpacUcx9lUyJvkssiDb0=
X-Gm-Gg: ASbGncveeiH5xL9l7DRiKa584SUxZpHUaT3DLGydpD6m7UcLL63y5ENeFPKwIMMgOrL
	CN0ai1m/8bKg72qe9bWAP+KHSGyHfrtUz6UGX9q0Ex6QqCZDxxmW66FORi3u2DXBfb+QeIyPWbv
	qdj3lYLMCNA+r+j6fDY6fNod8zPsKmHkj7JfFS/YaYbQeutNIVTJuGzqzf0qXerxHW4ekJzNQRO
	YKJNKu6m6wg0FMJSoo8GbNWT/l9ftyRFWJOCGNSD8i46qAWDaSGpX7BvLVY/kinTbHR/ooFkHm0
	Lnyh7Pji8kzyyYnVfTaUNNJjqhkNsfhrtLQ/MVsfGuJ4NySkSa9T6+y1/otlc6Fyk7+vHjVNYVT
	7XUWpb6TXd/Ij4QXSaAEUr02ZC9ZsS+3WJw==
X-Google-Smtp-Source: AGHT+IHxB3yc+PX4HInj97eKzz3f2laol/ruQa1wNgVYs/4yCuKsO7cr4MEEkK4HJzdxdQQodqiLvw==
X-Received: by 2002:ac2:4c4a:0:b0:553:2418:8c0c with SMTP id 2adb3069b0e04-5533b93b8e2mr5131186e87.57.1748962192301;
        Tue, 03 Jun 2025 07:49:52 -0700 (PDT)
From: "Edgar E. Iglesias" 
To: xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	julien@xen.org,
	bertrand.marquis@arm.com,
	michal.orzel@amd.com,
	Volodymyr_Babchuk@epam.com,
	andrew.cooper3@citrix.com,
	edgar.iglesias@amd.com,
	Anthony PERARD ,
	Juergen Gross ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v4 1/5] xen/arm: Add way to disable traps on accesses to unmapped addresses
Date: Tue,  3 Jun 2025 16:49:44 +0200
Message-ID: <20250603144948.1685047-2-edgar.iglesias@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250603144948.1685047-1-edgar.iglesias@gmail.com>
References: <20250603144948.1685047-1-edgar.iglesias@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: "Edgar E. Iglesias" 

Add a per-domain way to optionally disable traps for accesses
to unmapped addresses.

The domain flag is general but it's only implemented for Arm for now.

Reviewed-by: Stefano Stabellini 
Signed-off-by: Edgar E. Iglesias 
---
 tools/libs/light/libxl_arm.c  |  3 +++
 xen/arch/arm/dom0less-build.c |  3 +++
 xen/arch/arm/domain.c         |  3 ++-
 xen/arch/arm/domain_build.c   |  3 ++-
 xen/arch/arm/io.c             | 37 +++++++++++++++++++++++++++++++++--
 xen/arch/x86/domain.c         |  7 +++++++
 xen/common/domain.c           |  3 ++-
 xen/include/public/domctl.h   |  4 +++-
 8 files changed, 57 insertions(+), 6 deletions(-)

diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 75c811053c..9530996e72 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -233,6 +233,9 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
         config->arch.sve_vl = d_config->b_info.arch_arm.sve_vl / 128U;
     }
 
+    /* Trap accesses to unmapped areas. */
+    config->flags |= XEN_DOMCTL_CDF_trap_unmapped_accesses;
+
     return 0;
 }
 
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index a49764f0ad..a4e0a33632 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -343,6 +343,9 @@ void __init arch_create_domUs(struct dt_device_node *node,
         panic("'sve' property found, but CONFIG_ARM64_SVE not selected\n");
 #endif
     }
+
+    /* Trap accesses to unmapped areas. */
+    d_cfg->flags |= XEN_DOMCTL_CDF_trap_unmapped_accesses;
 }
 
 int __init init_intc_phandle(struct kernel_info *kinfo, const char *name,
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 45aeb8bddc..be58a23dd7 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -612,7 +612,8 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
     unsigned int max_vcpus;
     unsigned int flags_required = (XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap);
     unsigned int flags_optional = (XEN_DOMCTL_CDF_iommu | XEN_DOMCTL_CDF_vpmu |
-                                   XEN_DOMCTL_CDF_xs_domain );
+                                   XEN_DOMCTL_CDF_xs_domain |
+                                   XEN_DOMCTL_CDF_trap_unmapped_accesses );
     unsigned int sve_vl_bits = sve_decode_vl(config->arch.sve_vl);
 
     if ( (config->flags & ~flags_optional) != flags_required )
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index b189a7cfae..7ff9c1b584 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2003,7 +2003,8 @@ void __init create_dom0(void)
 {
     struct domain *dom0;
     struct xen_domctl_createdomain dom0_cfg = {
-        .flags = XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap,
+        .flags = XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap |
+                 XEN_DOMCTL_CDF_trap_unmapped_accesses,
         .max_evtchn_port = -1,
         .max_grant_frames = gnttab_dom0_frames(),
         .max_maptrack_frames = -1,
diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index 5a4b0e8f25..e599bbe043 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -21,6 +21,32 @@
 
 #include "decode.h"
 
+/* Handler for unmapped ranges. Writes ignored, reads return all ones.  */
+static int unmapped_read(struct vcpu *v, mmio_info_t *info, register_t *r,
+                         void *priv)
+{
+    uint64_t mask = GENMASK((1U << info->dabt.size) * 8 - 1, 0);
+
+    /* Mask off upper bits.  */
+    *r = UINT64_MAX & mask;
+    return 1;
+}
+
+static int unmapped_write(struct vcpu *v, mmio_info_t *info, register_t r,
+                          void *priv)
+{
+    return 1;
+}
+
+static const struct mmio_handler_ops unmapped_ops = {
+    .read = unmapped_read,
+    .write = unmapped_write
+};
+
+static const struct mmio_handler unmapped_handler = {
+    .ops = &unmapped_ops
+};
+
 static enum io_state handle_read(const struct mmio_handler *handler,
                                  struct vcpu *v,
                                  mmio_info_t *info)
@@ -175,11 +201,18 @@ enum io_state try_handle_mmio(struct cpu_user_regs *regs,
     handler = find_mmio_handler(v->domain, info->gpa);
     if ( !handler )
     {
+        bool trap_unmapped = v->domain->options &
+                                         XEN_DOMCTL_CDF_trap_unmapped_accesses;
         rc = try_fwd_ioserv(regs, v, info);
         if ( rc == IO_HANDLED )
             return handle_ioserv(regs, v);
-
-        return rc;
+        else if ( rc == IO_UNHANDLED && !trap_unmapped )
+        {
+            /* Fallback to the unmapped handler. */
+            handler = &unmapped_handler;
+        } else {
+            return rc;
+        }
     }
 
     /*
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 7536b6c871..fb7aea9168 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -713,6 +713,13 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
         }
     }
 
+    if ( config->flags & XEN_DOMCTL_CDF_trap_unmapped_accesses )
+    {
+        dprintk(XENLOG_INFO, "Unsupported trap_unmapped_accesses flag %#x\n",
+                config->flags);
+        return -EINVAL;
+    }
+
     if ( config->arch.misc_flags & ~XEN_X86_MSR_RELAXED )
     {
         dprintk(XENLOG_INFO, "Invalid arch misc flags %#x\n",
diff --git a/xen/common/domain.c b/xen/common/domain.c
index abf1969e60..ac4f58f638 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -721,7 +721,8 @@ static int sanitise_domain_config(struct xen_domctl_createdomain *config)
          ~(XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap |
            XEN_DOMCTL_CDF_s3_integrity | XEN_DOMCTL_CDF_oos_off |
            XEN_DOMCTL_CDF_xs_domain | XEN_DOMCTL_CDF_iommu |
-           XEN_DOMCTL_CDF_nested_virt | XEN_DOMCTL_CDF_vpmu) )
+           XEN_DOMCTL_CDF_nested_virt | XEN_DOMCTL_CDF_vpmu |
+           XEN_DOMCTL_CDF_trap_unmapped_accesses) )
     {
         dprintk(XENLOG_INFO, "Unknown CDF flags %#x\n", config->flags);
         return -EINVAL;
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 5b2063eed9..be19ab5e26 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -66,9 +66,11 @@ struct xen_domctl_createdomain {
 #define XEN_DOMCTL_CDF_nested_virt    (1U << _XEN_DOMCTL_CDF_nested_virt)
 /* Should we expose the vPMU to the guest? */
 #define XEN_DOMCTL_CDF_vpmu           (1U << 7)
+/* Should we trap guest accesses to unmapped addresses? */
+#define XEN_DOMCTL_CDF_trap_unmapped_accesses  (1U << 8)
 
 /* Max XEN_DOMCTL_CDF_* constant.  Used for ABI checking. */
-#define XEN_DOMCTL_CDF_MAX XEN_DOMCTL_CDF_vpmu
+#define XEN_DOMCTL_CDF_MAX XEN_DOMCTL_CDF_trap_unmapped_accesses
 
     uint32_t flags;
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 14:49:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 14:49:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004559.1384291 (Exim 4.92)
	(envelope-from )
	id 1uMSxg-0006Hx-KV; Tue, 03 Jun 2025 14:49:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004559.1384291; Tue, 03 Jun 2025 14:49: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 1uMSxg-0006H4-Gp; Tue, 03 Jun 2025 14:49:56 +0000
Received: by outflank-mailman (input) for mailman id 1004559;
 Tue, 03 Jun 2025 14: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 1uMSxe-00060n-SC
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 14:49: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 02b64404-408a-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 16:49:54 +0200 (CEST)
Received: by mail-lf1-x12a.google.com with SMTP id
 2adb3069b0e04-55350d0eedeso1947244e87.2
 for ; Tue, 03 Jun 2025 07:49:54 -0700 (PDT)
Received: from gmail.com (213-67-3-247-no600.tbcn.telia.com. [213.67.3.247])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5533791cdcesm1955678e87.164.2025.06.03.07.49.52
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 03 Jun 2025 07:49:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 02b64404-408a-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748962193; x=1749566993; darn=lists.xenproject.org;
        h=content-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=cxkHOzjLuIxbnoSdUszUdCQGbRM0T87LtQfXfGg3nVA=;
        b=k4D8wJOydaAPhxrctAl973D/05HHpBl/OC+U8O/2fsiafUYtZLC/hTyB8GIImtSHQq
         QXW+7vihgD12Res8y4MOPG4HMjvWxmlsqnH32/riWfko970IZQCEwftIMzlXiU5BvomW
         z4a7gq5BmOQt0OREjJSWbQZ0PTEihJI+26dd+hRjoxywtWUN+MCKV5rG3CFodzGjt3eD
         oNcGekvudHpde4MToFG4s1VLEYr6QnHVl0cO37AQpThaexhkEqnNKNEW+8DfVlBWj492
         J05Zya8Z/Om9mHq+wC7ZJ9efc1aEZgV4ZCXoDXDXkgUeSqboY4PSrUzIH87ZAsPHNYWh
         d8RQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748962193; x=1749566993;
        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=cxkHOzjLuIxbnoSdUszUdCQGbRM0T87LtQfXfGg3nVA=;
        b=hkTkOGGSMO55XrFWXL5Inv6Rq7xbSDC4dbAGxJmfqcPMXrSDu+aDcg3432/CGizIDm
         C/5gJWeoAVZ8Nb4QSHPJuu8l46J6THzQsAvXSIrRmeEnUIN49qCQXtq8uJJ2rNA2suXM
         eSZxYsUT2pv8UFUlUbssbp/I9YPMMD1kjASTPOQWloBFV5bhxMY+80rO083SvKnR9SmX
         FmqhPQgezTR79V9subOh9eF91osIzEvr8TdgRQLoRyw9BOUkPaUA3sYduDRGKBIXfkA5
         hPQ/rtxZ/PzNTFxo0MgAg57HjyhCnOrIvsaJ3Z2/eXzAj/mDVz4cxC9Wwb1PxM1gujOA
         iq8A==
X-Gm-Message-State: AOJu0YziWGgRsKH7OXkCX/pkPOPvPN3+rqKiFotCS3FYsTH7nfg3Zo8A
	asYdH9bFNvDZxj+mOVpfeVJiniPHVlMDPhchFIKPL+WcVZJdFcJG0PJgMcU3qcwP8pc=
X-Gm-Gg: ASbGncsZKEYYovnW2v9KPModUob1klVjAXNJT+seT/lv/SI0zJ5G8F/3PxxWngM2+LY
	OZrBm/8fpVYD4qdwCzdyoDCLp3Vsc6p0d2QQM56twX5+P01iLEfmSF9EvxyH2LtWwz6FkBDQstI
	ry69FwSg35tuqzbFoAXRfaXDZeRbwxIWSwtKrixqsXr+12jFPEAaKv5rGC3WhFoGCiynsMnXUoo
	0MPRTNmAzhomlQmLxCiOd56nrw4FVm7ElSa0YkhLNC7rvTF4pO0fsYTqV4H2sRYxrIiePsDusBz
	SIr4LDmZ08dfbZiOSgHhIpCJRExrYNfOccNdjPw6HOxd/3l6CUbJmDuC3eZDAUgxxKeUkaj9gJG
	rYq7tAJXhUuBPYX6+XztUHOA=
X-Google-Smtp-Source: AGHT+IEDspcf46WZ+GLaDfcXnfwzoPQcZkL/NMs2D0E3d1fP1/tTD2EkdEVG0kCXUGd8ka7U1V4KBA==
X-Received: by 2002:a05:6512:6cc:b0:553:35bd:d2eb with SMTP id 2adb3069b0e04-5533d16d8fbmr4922174e87.13.1748962193286;
        Tue, 03 Jun 2025 07:49:53 -0700 (PDT)
From: "Edgar E. Iglesias" 
To: xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	julien@xen.org,
	bertrand.marquis@arm.com,
	michal.orzel@amd.com,
	Volodymyr_Babchuk@epam.com,
	andrew.cooper3@citrix.com,
	edgar.iglesias@amd.com
Subject: [PATCH v4 2/5] xen/arm: dom0less: Add trap-unmapped-accesses
Date: Tue,  3 Jun 2025 16:49:45 +0200
Message-ID: <20250603144948.1685047-3-edgar.iglesias@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250603144948.1685047-1-edgar.iglesias@gmail.com>
References: <20250603144948.1685047-1-edgar.iglesias@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: "Edgar E. Iglesias" 

Add the trap-unmapped-accesses per-domain fdt property.

Reviewed-by: Stefano Stabellini 
Signed-off-by: Edgar E. Iglesias 
---
 docs/misc/arm/device-tree/booting.txt | 10 ++++++++++
 xen/arch/arm/dom0less-build.c         |  9 ++++++++-
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
index 59fa96a82e..07acc7ba64 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -225,6 +225,16 @@ with the following properties:
     option is provided with a non zero value, but the platform doesn't support
     SVE.
 
+- trap-unmapped-accesses
+
+    Optional. An integer that configures handling of accesses to unmapped
+    address ranges.
+    If set to 0, guest accesses will read all bits as ones, e.g 0xFFFFFFFF
+    for a 32bit access and writes will be ignored.
+    If set to 1, guest accesses will trap.
+
+    The default is 1 when trap-unmapped-accesses is absent.
+
 - xen,enhanced
 
     A string property. Possible property values are:
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index a4e0a33632..69324aa597 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -344,8 +344,15 @@ void __init arch_create_domUs(struct dt_device_node *node,
 #endif
     }
 
-    /* Trap accesses to unmapped areas. */
+    /* Trap unmapped accesses by default. */
     d_cfg->flags |= XEN_DOMCTL_CDF_trap_unmapped_accesses;
+    if ( dt_property_read_u32(node, "trap-unmapped-accesses", &val) )
+    {
+        if ( val > 1 )
+            panic("trap-unmapped-accesses: supported values are 0 or 1");
+        if ( !val )
+            d_cfg->flags &= ~XEN_DOMCTL_CDF_trap_unmapped_accesses;
+    }
 }
 
 int __init init_intc_phandle(struct kernel_info *kinfo, const char *name,
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 14:49:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 14:49:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004557.1384278 (Exim 4.92)
	(envelope-from )
	id 1uMSxe-000612-3U; Tue, 03 Jun 2025 14:49:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004557.1384278; Tue, 03 Jun 2025 14:49: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 1uMSxe-00060v-0N; Tue, 03 Jun 2025 14:49:54 +0000
Received: by outflank-mailman (input) for mailman id 1004557;
 Tue, 03 Jun 2025 14:49: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 1uMSxc-00060n-S0
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 14:49:52 +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 01383e0b-408a-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 16:49:51 +0200 (CEST)
Received: by mail-lf1-x136.google.com with SMTP id
 2adb3069b0e04-54afb5fcebaso7319113e87.3
 for ; Tue, 03 Jun 2025 07:49:51 -0700 (PDT)
Received: from gmail.com (213-67-3-247-no600.tbcn.telia.com. [213.67.3.247])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-553379377e9sm1929345e87.237.2025.06.03.07.49.49
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 03 Jun 2025 07:49:50 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 01383e0b-408a-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748962191; x=1749566991; 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=FpzZLJFihudQ2+Wn0CdDPOwa86hjlKd/fcpwnlnFWEM=;
        b=TXIh1uMLtmcwMuIwFpxu0i1wZI+5qFbKFZLcOxrhAbJ1vZsm0EMEjz1uKGnKIMt9gH
         lwpYVTG0hdBDmnjVviVF5annYpVsDZOC7jx1eXvT9SDp+ezQE5sJHqK93XZrpmSbtLYI
         j0yoPTYpUXjLSihxJhlUEW0gnm5gY5qjGTDTBjlrE/qV/l1tPFRcdcmKGlJVSbnZOaI2
         1trKZnrFRDFgKT+kovJ2vsRrD7sM7NBpRKCkIYX6UDhj2LbA6NGioeIk6DUbunmMeZJ1
         gY2lcPGq7n9gPYgaaBKioxUQAgf0CjGCUllKRkcDd9P9CUKJRvouPX2EObGr9IKxcurL
         A5gA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748962191; x=1749566991;
        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=FpzZLJFihudQ2+Wn0CdDPOwa86hjlKd/fcpwnlnFWEM=;
        b=bc3guTaHSRMvcF4BNk+ThcPErn05Dgp27jabp1a4lget3CSUBXoOq9y8qXlxhGn6tr
         iCDbRVvb+p5sgfs3ibizoUEWenYtRwgtqEZwDZHv9GV+XZdL1AKumT97Ht4PHjd15NU1
         YrgUQa/oLxbGnNEsyJdYf5HtkhK74B9gR/LneTsr/A6qQsww4nwxW5G4ieJJm6mRVBwy
         mrJAaDgpmDpjOJc0e5Y+b8hIH4pcAaRKphrZ9oiAev2P7aec3PouDYOPirQbRfAnM0RL
         vEb3Ne5+s6Aky/uNrbOL7kxqMXTjK22LoMGKK71MisvLVX1wDpC4SPzOuT8pQM38beUl
         edMw==
X-Gm-Message-State: AOJu0YxIsgNNdBRIoFFdCPHnElSPCY/N7NUG499QvigGuJfmI3Knbja0
	HYHYRexCG99fhb2B5uNR7Ow8i8eLEIYRitpHOVo2dTrc21BZyouhj52o3gDg2RWosT8=
X-Gm-Gg: ASbGncv+ZRzESerW3Q3SNE5zLY9U/Sh+WVHfi4YXay/OuEQrjAuR5ryLg0Th2af2zWu
	uTPSx5KMOKLKb+mryrjo90epTuAtmB7DGHfTPOghA1rmYwU/lkUZT12+JUGm81SHFWMzmI9fiNF
	atqgvj8ApzPL2A3c1Jcd1SssxQfN8CQ0IyjSOL1S3pfScn3sQvmwoVrs4f5axsy+yD5Oh9Z+VC8
	gmpYFPz78cTD4lgbzhw+u9dgtrCPc4AL8PvuCGLe6I2VfbVu2d0MmHfjqEsD0t5nRHcGw6cwCz6
	o4xDe/HH9M2b/eppAvLW4TjuGA7x6GUnUZ4sXQ1saeQyYhRh5aXoeChWV87gBImKPncZGmxbDAU
	GXwjLIv0yWw1+FCoq7qsvCcA=
X-Google-Smtp-Source: AGHT+IEXJGpaihCNW2i6cfKQ6awfzdXIAoGFzBTNVZs5piGQCGWS92dGKRESDo9Ku3cRWYNDlf3A2g==
X-Received: by 2002:a05:6512:104a:b0:553:26a7:70e0 with SMTP id 2adb3069b0e04-5533b92e3e4mr6071646e87.43.1748962190753;
        Tue, 03 Jun 2025 07:49:50 -0700 (PDT)
From: "Edgar E. Iglesias" 
To: xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	julien@xen.org,
	bertrand.marquis@arm.com,
	michal.orzel@amd.com,
	Volodymyr_Babchuk@epam.com,
	andrew.cooper3@citrix.com,
	edgar.iglesias@amd.com
Subject: [PATCH v4 0/5] xen/arm: Add option to optionally disable trapping on unmapped acceses
Date: Tue,  3 Jun 2025 16:49:43 +0200
Message-ID: <20250603144948.1685047-1-edgar.iglesias@gmail.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: "Edgar E. Iglesias" 

This follows up on the virtio-pci discussion and adds a per-domain
option to select the behaviour of accesses to unmapped address ranges.
The new option is trap_unmapped_accesses, it's general but for now
only implemented for ARM.

I'm happy with any name, so if you have better ideas please suggest them!

I've included regenerated golang bindings as a separate patch.

Thanks,
Edgar

ChangeLog:

v3 -> v4:
* Reject in x86 arch_sanitise_domain_config
* Add LIBXL_HAVE_TRAP_UNMAPPED_ACCESSES
* Remove "..is only implemented for ARM" from Arm specific documentation
* ARM -> Arm

v2 -> v3:
* Reword descriptions to clarify reads of all bits as ones
* Use GENMASK as GENMASK_ULL not needed
* Style fix in if/else
* Regenerate golang bindings
* Update ocaml bindings

v1 -> v2:
* Rename trap_unmapped_mmio to trap_unmapped_accesses
* Generalize to allow other archs to later support this option
* Change dom0less DT binding from boolean to integer
* Remove changes to autogenerated go bindings


Edgar E. Iglesias (5):
  xen/arm: Add way to disable traps on accesses to unmapped addresses
  xen/arm: dom0less: Add trap-unmapped-accesses
  tools/arm: Add the trap_unmapped_accesses xl config option
  tools/ocaml: Update bindings for CDF_TRAP_UNMAPPED_ACCESSES
  tools/golang: Regenerate bindings for trap_unmapped_accesses

 docs/man/xl.cfg.5.pod.in              |  9 +++++++
 docs/misc/arm/device-tree/booting.txt | 10 ++++++++
 tools/golang/xenlight/helpers.gen.go  |  6 +++++
 tools/golang/xenlight/types.gen.go    |  1 +
 tools/include/libxl.h                 |  7 +++++
 tools/libs/light/libxl_arm.c          |  3 +++
 tools/libs/light/libxl_create.c       |  3 +++
 tools/libs/light/libxl_types.idl      |  1 +
 tools/libs/light/libxl_x86.c          |  6 +++++
 tools/ocaml/libs/xc/xenctrl.ml        |  1 +
 tools/ocaml/libs/xc/xenctrl.mli       |  1 +
 tools/xl/xl_parse.c                   |  3 +++
 xen/arch/arm/dom0less-build.c         | 10 ++++++++
 xen/arch/arm/domain.c                 |  3 ++-
 xen/arch/arm/domain_build.c           |  3 ++-
 xen/arch/arm/io.c                     | 37 +++++++++++++++++++++++++--
 xen/arch/x86/domain.c                 |  7 +++++
 xen/common/domain.c                   |  3 ++-
 xen/include/public/domctl.h           |  4 ++-
 19 files changed, 112 insertions(+), 6 deletions(-)

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 14:49:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 14:49:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004560.1384308 (Exim 4.92)
	(envelope-from )
	id 1uMSxi-0006iJ-SI; Tue, 03 Jun 2025 14:49:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004560.1384308; Tue, 03 Jun 2025 14:49: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 1uMSxi-0006iC-OP; Tue, 03 Jun 2025 14:49:58 +0000
Received: by outflank-mailman (input) for mailman id 1004560;
 Tue, 03 Jun 2025 14:49: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 1uMSxh-00060n-Cb
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 14:49:57 +0000
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com
 [2a00:1450:4864:20::231])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 040d5322-408a-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 16:49:56 +0200 (CEST)
Received: by mail-lj1-x231.google.com with SMTP id
 38308e7fff4ca-32a81344ae9so61753821fa.0
 for ; Tue, 03 Jun 2025 07:49:56 -0700 (PDT)
Received: from gmail.com (213-67-3-247-no600.tbcn.telia.com. [213.67.3.247])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-32a85bd20e2sm19958911fa.88.2025.06.03.07.49.53
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 03 Jun 2025 07:49:53 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 040d5322-408a-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748962196; x=1749566996; darn=lists.xenproject.org;
        h=content-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=8/P4JJfVyXfBWOJOwxQ63tEugbkZDcheuT5ZnHfj61Q=;
        b=GRdlHQp+vD3UkJtI5GxssD1hknwr864YmpWaRw+pVvusbtHctFacK0FyRVt0ipM0ak
         odUfICi2KlbZzNR/2gDxzBY7a3CP60ZcS+zdZBd2j6K8ds11puZ/FrllsAl3c7fe3XQZ
         0gv2zbMO56Jt4ot9wk882PRXLkHX6/ebTqr6QsXUr2o9H18QNok8y3D/7TZuCJfwVBPv
         qCdH+yyjkDK5rWj+z/XbYv5fRyykFSLN3C7Nh6rTuQtsLkZsDIBFctrdUXXw4soXHFii
         O7h7h+iHx1b/3zYwJhE2R7OmUHkEk8Ie5tNi6heydTtOPsdSeJ4AYyXjcfKVZHS7XPFx
         sl6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748962196; x=1749566996;
        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=8/P4JJfVyXfBWOJOwxQ63tEugbkZDcheuT5ZnHfj61Q=;
        b=aw4i0+75jr03zOVuyl6JivOXgG7ZKQR0MNCGkkZNsFgIyRU8lWZGY8S71H9FfHATqb
         x/uvrjix9CXMQFQT+Gzfqqwog4mub6/BnHL9+/SoMd7vZUVIpEG/LhblHq8/XQEaqqHY
         +20nv86I/4yuY9RcrBBywDzE5nFQEL0LUkU6X320znqSRiwoMI6QErwM0C5RNiaTUNqP
         q6QroJtOSJXgOy3WlawNr+3cwCh4snbpi15Md36JtO6bQPiQtoaDd/GruN0Y7DPmpQuz
         /POuFxHMvKa6N2f9tprZVg8sBGtzcU5t+jOhYue7uVpNf3fbW4XWTI9KT1eBXq1i/lKN
         xlOw==
X-Gm-Message-State: AOJu0YxzojiqtcEX4kIgJVr+9LNr3nhnCGnVLziRb25dVdxvez7vHPPM
	vaWZWH5b1L4CbXXfwCCjhfuQO+LV9aqv6xwS19lL6bwzYaDUXwT/6fixasrTrCRTPnI=
X-Gm-Gg: ASbGncvUANldHzSl9njM0J0Rg8MAayRBOZv1aa3j2b8wuK/VL+FrVPW0cAyhaX+T1Uu
	GfTPxoy1TcWtafKGbvuSLRIbVhTpxSdNG2UgF/RGc9OMNOD2FK4hdXhGGta/nLzxcqA/kVpmdfE
	4/8vQn0sfSfh37B3OFEQ0ramI0lmUSZrQMkRG4xd5oQWaCKBrGmnf4M0LwP5w4lV7q6Fb2A86d7
	l1oc6HxICrkXwJj4OfE6RKe2fsH2FnSUZ9KlEh9GoCILlaImczTaysS+FOV2hnScYdxReuT+Z25
	9lLB+25gSfVOzY3PK0wuYhaMi94GHvfbIO/9ZBg15Hsx2B4MQRVr8lJF773tv4QI/Us/sop5KUy
	XgHzhiKXR0+t41vcyc9qJgMA=
X-Google-Smtp-Source: AGHT+IG8r/MCEHNzSQ5BGqRl+m2UokCyQfxstG/mthNpbTEWTCy0p07qQ5CFnX8ov8CFEYVmvgmH/A==
X-Received: by 2002:a05:651c:30c6:b0:32a:681f:696e with SMTP id 38308e7fff4ca-32a8ce5d659mr52521281fa.37.1748962195426;
        Tue, 03 Jun 2025 07:49:55 -0700 (PDT)
From: "Edgar E. Iglesias" 
To: xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	julien@xen.org,
	bertrand.marquis@arm.com,
	michal.orzel@amd.com,
	Volodymyr_Babchuk@epam.com,
	andrew.cooper3@citrix.com,
	edgar.iglesias@amd.com,
	Anthony PERARD ,
	Juergen Gross 
Subject: [PATCH v4 3/5] tools/arm: Add the trap_unmapped_accesses xl config option
Date: Tue,  3 Jun 2025 16:49:46 +0200
Message-ID: <20250603144948.1685047-4-edgar.iglesias@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250603144948.1685047-1-edgar.iglesias@gmail.com>
References: <20250603144948.1685047-1-edgar.iglesias@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: "Edgar E. Iglesias" 

Reviewed-by: Stefano Stabellini 
Signed-off-by: Edgar E. Iglesias 
---
 docs/man/xl.cfg.5.pod.in         | 9 +++++++++
 tools/include/libxl.h            | 7 +++++++
 tools/libs/light/libxl_arm.c     | 6 +++---
 tools/libs/light/libxl_create.c  | 3 +++
 tools/libs/light/libxl_types.idl | 1 +
 tools/libs/light/libxl_x86.c     | 6 ++++++
 tools/xl/xl_parse.c              | 3 +++
 7 files changed, 32 insertions(+), 3 deletions(-)

diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index c388899306..075e89e6d2 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -3056,6 +3056,15 @@ will be used for the domain. Otherwise, the value specified by the `nr_spis`
 parameter will be used. The number of SPIs should match the highest interrupt
 ID that will be assigned to the domain.
 
+=item B
+
+An Optional boolean parameter that configures handling of accesses to unmapped
+address ranges. If enabled, guest accesses will trap. If disabled, guest
+accesses will read all bits as ones, e.g 0xFFFFFFFF for a 32bit access and
+writes will be ignored.
+
+This option is only implemented for Arm where the default is enabled.
+
 =back
 
 =head3 x86
diff --git a/tools/include/libxl.h b/tools/include/libxl.h
index b7ad7735ca..24c81cf145 100644
--- a/tools/include/libxl.h
+++ b/tools/include/libxl.h
@@ -549,6 +549,13 @@
  */
 #define LIBXL_HAVE_VPMU 1
 
+/*
+ * LIBXL_HAVE_TRAP_UNMAPPED_ACCESSES indicates that libxl_domain_build_info
+ * has a trap_unmapped_accesses parameter, which allows the control of how
+ * accesses to unmapped adresses behave.
+ */
+#define LIBXL_HAVE_TRAP_UNMAPPED_ACCESSES 1
+
 /*
  * LIBXL_HAVE_PHYSINFO_CAP_GNTTAB indicates that libxl_physinfo has a
  * cap_gnttab_v1/2 fields, which indicates the available grant table ABIs.
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 9530996e72..afc62a5299 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -233,9 +233,6 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
         config->arch.sve_vl = d_config->b_info.arch_arm.sve_vl / 128U;
     }
 
-    /* Trap accesses to unmapped areas. */
-    config->flags |= XEN_DOMCTL_CDF_trap_unmapped_accesses;
-
     return 0;
 }
 
@@ -1714,6 +1711,9 @@ int libxl__arch_domain_build_info_setdefault(libxl__gc *gc,
     /* ACPI is disabled by default */
     libxl_defbool_setdefault(&b_info->acpi, false);
 
+    /* Trapping of unmapped accesses enabled by default.  */
+    libxl_defbool_setdefault(&b_info->trap_unmapped_accesses, true);
+
     /* Sanitise SVE parameter */
     if (b_info->arch_arm.sve_vl) {
         unsigned int max_sve_vl =
diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_create.c
index 8bc768b515..625ce5b040 100644
--- a/tools/libs/light/libxl_create.c
+++ b/tools/libs/light/libxl_create.c
@@ -605,6 +605,9 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
         if (libxl_defbool_val(b_info->vpmu))
             create.flags |= XEN_DOMCTL_CDF_vpmu;
 
+        if (libxl_defbool_val(b_info->trap_unmapped_accesses))
+            create.flags |= XEN_DOMCTL_CDF_trap_unmapped_accesses;
+
         assert(info->passthrough != LIBXL_PASSTHROUGH_DEFAULT);
         LOG(DETAIL, "passthrough: %s",
             libxl_passthrough_to_string(info->passthrough));
diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl
index 1985153830..57ae16ae78 100644
--- a/tools/libs/light/libxl_types.idl
+++ b/tools/libs/light/libxl_types.idl
@@ -736,6 +736,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
     ("vmtrace_buf_kb", integer),
 
     ("vpmu", libxl_defbool),
+    ("trap_unmapped_accesses", libxl_defbool),
 
     ], dir=DIR_IN,
        copy_deprecated_fn="libxl__domain_build_info_copy_deprecated",
diff --git a/tools/libs/light/libxl_x86.c b/tools/libs/light/libxl_x86.c
index 867addfcab..60d4e8661c 100644
--- a/tools/libs/light/libxl_x86.c
+++ b/tools/libs/light/libxl_x86.c
@@ -26,6 +26,11 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
     if (libxl_defbool_val(d_config->b_info.arch_x86.msr_relaxed))
         config->arch.misc_flags |= XEN_X86_MSR_RELAXED;
 
+    if (libxl_defbool_val(d_config->b_info.trap_unmapped_accesses)) {
+            LOG(ERROR, "trap_unmapped_accesses is not supported on x86\n");
+            return ERROR_FAIL;
+    }
+
     return 0;
 }
 
@@ -813,6 +818,7 @@ int libxl__arch_domain_build_info_setdefault(libxl__gc *gc,
 {
     libxl_defbool_setdefault(&b_info->acpi, true);
     libxl_defbool_setdefault(&b_info->arch_x86.msr_relaxed, false);
+    libxl_defbool_setdefault(&b_info->trap_unmapped_accesses, false);
 
     if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         /*
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index 219e924779..98b3612d0f 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -2972,6 +2972,9 @@ skip_usbdev:
     if (!xlu_cfg_get_long (config, "nr_spis", &l, 0))
         b_info->arch_arm.nr_spis = l;
 
+    xlu_cfg_get_defbool(config, "trap_unmapped_accesses",
+                        &b_info->trap_unmapped_accesses, 0);
+
     parse_vkb_list(config, d_config);
 
     d_config->virtios = NULL;
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 14:50:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 14:50:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004561.1384317 (Exim 4.92)
	(envelope-from )
	id 1uMSxk-0006xt-3u; Tue, 03 Jun 2025 14:50:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004561.1384317; Tue, 03 Jun 2025 14:50: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 1uMSxk-0006xi-0S; Tue, 03 Jun 2025 14:50:00 +0000
Received: by outflank-mailman (input) for mailman id 1004561;
 Tue, 03 Jun 2025 14:49: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 1uMSxi-00060n-G3
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 14:49:58 +0000
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com
 [2a00:1450:4864:20::135])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 04e74a9c-408a-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 16:49:58 +0200 (CEST)
Received: by mail-lf1-x135.google.com with SMTP id
 2adb3069b0e04-5532a30ac41so6587144e87.0
 for ; Tue, 03 Jun 2025 07:49:58 -0700 (PDT)
Received: from gmail.com (213-67-3-247-no600.tbcn.telia.com. [213.67.3.247])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-55337937409sm1926383e87.213.2025.06.03.07.49.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 03 Jun 2025 07:49:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 04e74a9c-408a-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748962197; x=1749566997; darn=lists.xenproject.org;
        h=content-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=8Rv9jkk9a7Mmckdgwtv3pi1GijaKXKBiRxq1uzaztv4=;
        b=FryjlqXvPvaOSRJF9986RbyZ9g9VnxhhzDqBlwGAArYETqcwI+ZPuyZxtX31LYF0qs
         5Tr6tB9QRTxJEQ78B21iuiqMkgfKhXBtu8obA8A4KJsZY8eYxq1THEa/lhNFjVT/NoUF
         h2SSnMHMe/3RzhRyqCSffeMhaU63JlEHQQ/gIe06BK+Efa8LK3Ie3NOyP+rhdccpEGm5
         0o5e31Y8p5MXssdoD8uhvVWq5TE2i/OuWRCQv97awg0683Q/jXck1+k3rlfsnHjIcwEe
         4LuKZ9BEn9x9M2tDZYHDizdpCO+l13QZkKtnfiu7kksOtCOe2o0WbihA9vFGb7Cep7vc
         EfuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748962197; x=1749566997;
        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=8Rv9jkk9a7Mmckdgwtv3pi1GijaKXKBiRxq1uzaztv4=;
        b=DTh+l7074sLXUbO2ob99odm1QkyDf9E8TYBZDTh8M5+il3cqK8xLCB70sJGWYWWG0L
         dKTFaCqfJbDq92k0NLaDvsdr+19iDBkLica1Of+PgO8/2BjLt15ycRzoHkUCXB/c9YT6
         3rq6eyAD9Wr8fXremDfCg6FBFrhZPLW7tLO8oVVwpJ37D5VtAK6V7I/N5Wo5WhmtBmsq
         Mvxx5TafBsRgXBnBufvUzN1nqJTzvmpT4qqjGd4GrREIbsyeav40R4vhCya7o+YUc2t2
         mSccTs7J85gJse1IdOx+o1jr7ZpfueH315sjwKoTDdkDC/qNFAXy6RISXE+YY3/u103j
         Jp1Q==
X-Gm-Message-State: AOJu0YyMjmwOQ82uQrWt31QHjy1QhB31M+gDElFYZvbsjCX5uFt5nIrY
	NrGA1Wus7yEgRhupO2MP4cqbKJ58IvljVvHCYtIbpjqxcdoYt+FBPJMQmiyvspglmlE=
X-Gm-Gg: ASbGncuVSnTEqTS96P2CoA6OWlOfeqStzGyEFGFBq2RvnawOWcjGZzNn1ZE1G4gCW7V
	ubEqoWQTGbLTWGVOLvOCJW1epiAe2gjNuGk2tiO3sGfuWmqIRNOkPqYrVJoHz+0vzVa5rhWi3In
	35jTtb4oQ0sAMm5pGoyvoA822/33LpzDG6CQ28vQlE4mt0VRz6J5s8N4e8M+xmGnavaDHt1ew+y
	HNZWMTZECB+wRM17t2PNlWQDdC1LAaPndcZu67juANc4XKAtBLLc4mLrZdP6Ob7fQ3WIY8W59cV
	o2qWIbavleaTI+GcEgmqgGjTmPMWU3uH7td6IxrPdp/nPWPG4GC9wtwaBY1tlEjjX5875xQvHbF
	bN6B1xaS5WjMc434LK41UCrM=
X-Google-Smtp-Source: AGHT+IH8/jb/PldOgmQh1jF9CunVlSSRPSF7jucpLmiTBONZ2toTWA1eabhva7I9GfIVjFLmvX3g4A==
X-Received: by 2002:a05:6512:3d2a:b0:553:35c4:db08 with SMTP id 2adb3069b0e04-5533b908034mr5543769e87.30.1748962196978;
        Tue, 03 Jun 2025 07:49:56 -0700 (PDT)
From: "Edgar E. Iglesias" 
To: xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	julien@xen.org,
	bertrand.marquis@arm.com,
	michal.orzel@amd.com,
	Volodymyr_Babchuk@epam.com,
	andrew.cooper3@citrix.com,
	edgar.iglesias@amd.com,
	Christian Lindig ,
	Christian Lindig ,
	David Scott ,
	Anthony PERARD 
Subject: [PATCH v4 4/5] tools/ocaml: Update bindings for CDF_TRAP_UNMAPPED_ACCESSES
Date: Tue,  3 Jun 2025 16:49:47 +0200
Message-ID: <20250603144948.1685047-5-edgar.iglesias@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250603144948.1685047-1-edgar.iglesias@gmail.com>
References: <20250603144948.1685047-1-edgar.iglesias@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: "Edgar E. Iglesias" 

Acked-by: Christian Lindig 
Signed-off-by: Edgar E. Iglesias 
---
 tools/ocaml/libs/xc/xenctrl.ml  | 1 +
 tools/ocaml/libs/xc/xenctrl.mli | 1 +
 2 files changed, 2 insertions(+)

diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml
index 2690f9a923..7e1aabad6c 100644
--- a/tools/ocaml/libs/xc/xenctrl.ml
+++ b/tools/ocaml/libs/xc/xenctrl.ml
@@ -70,6 +70,7 @@ type domain_create_flag =
   | CDF_IOMMU
   | CDF_NESTED_VIRT
   | CDF_VPMU
+  | CDF_TRAP_UNMAPPED_ACCESSES
 
 type domain_create_iommu_opts =
   | IOMMU_NO_SHAREPT
diff --git a/tools/ocaml/libs/xc/xenctrl.mli b/tools/ocaml/libs/xc/xenctrl.mli
index febbe1f6ae..f44dba61ae 100644
--- a/tools/ocaml/libs/xc/xenctrl.mli
+++ b/tools/ocaml/libs/xc/xenctrl.mli
@@ -63,6 +63,7 @@ type domain_create_flag =
   | CDF_IOMMU
   | CDF_NESTED_VIRT
   | CDF_VPMU
+  | CDF_TRAP_UNMAPPED_ACCESSES
 
 type domain_create_iommu_opts =
   | IOMMU_NO_SHAREPT
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 14:50:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 14:50:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004562.1384328 (Exim 4.92)
	(envelope-from )
	id 1uMSxm-0007Og-Gv; Tue, 03 Jun 2025 14:50:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004562.1384328; Tue, 03 Jun 2025 14:50: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 1uMSxm-0007OJ-Dn; Tue, 03 Jun 2025 14:50:02 +0000
Received: by outflank-mailman (input) for mailman id 1004562;
 Tue, 03 Jun 2025 14:50: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 1uMSxk-00060n-3P
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 14:50:00 +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 05dc7897-408a-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 16:49:59 +0200 (CEST)
Received: by mail-lf1-x12f.google.com with SMTP id
 2adb3069b0e04-54afb5fcebaso7319233e87.3
 for ; Tue, 03 Jun 2025 07:49:59 -0700 (PDT)
Received: from gmail.com (213-67-3-247-no600.tbcn.telia.com. [213.67.3.247])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-55350cab690sm450214e87.53.2025.06.03.07.49.57
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 03 Jun 2025 07:49:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 05dc7897-408a-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748962199; x=1749566999; darn=lists.xenproject.org;
        h=content-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=vQZpCaGwN67bAjam9mj+oezbvKc88yCztRac3tGbr1g=;
        b=PVpp1t+w6flUgorB/q0H5JkTZRl43mbgRsV3vvqaPpb4mTkXxdMoY2Xc2ORlO9vZmc
         69kvN5NHEV6ocZAs2P4KF0RMPTT3t0LwL1SYSVacUPVuUzKfPxBcl/YsgqUJX3Akq77H
         V5m8g732OPVlPEEOwMXSviGwjrIcTCd77zA3/QXIMOQZhE5NcdDrphhWDhJYISSvzhES
         wpHT2MJlPYASUFWs7wewsyKSyFGgcfJ5CH/rlXGzgTNTfjcOE2MBLAmKBed3AwY15KKe
         bcyDlRANoSvXRAjc3Co+dcLHv2G82koi2daZiIk6JoUcKbZPNJ6tmZrcgG8yYWEWFEWn
         p3VA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748962199; x=1749566999;
        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=vQZpCaGwN67bAjam9mj+oezbvKc88yCztRac3tGbr1g=;
        b=mQykN1m2NY5cgaKpKravjl54bsILQwk5T9K2PUMdNri/vu+VwisTJ0YiGwinOPbuV7
         iZsMevlOVZXZG/JgjXWQg7iI0Stm8UkfcdEvcMNWApQcjtU6HgzOA4kwxNPTUfi/qypY
         1R7rVcF31Z/KzEvW7LlILlC6rq6zCGxN8pK+2dTEYa9aSh3Hob8msgCXdNejazOmRpW6
         rUvxWdyXmtQhd+e6iE+iIViAv/nweNP9MQih7JpzvGFLQn3VIE+rdqgiSszZj2eccthv
         LGWSm1xUQGJo7LQS19YVzQ4XsfVY+uqFwkrY7r1ZLgfHpaiz4WZkC9nGFHpwGSoKDfBH
         ZzHg==
X-Gm-Message-State: AOJu0Yx1hWEfHe+pKA868+ILzDxltM/aLjsCyDqIvlDJwGfvvTrqSOAD
	tVs9kqCxVZrk35hJX44rd3ocfi7G7K6vgnwx6aatZXWlc+XF2dWyBu2+FGvDfSL9r4A=
X-Gm-Gg: ASbGncvn8zQRoe8q+avk/EIsXhxCBANu9O705YFEBGtM6xYGuKdSlnuUUtmw7OU0cc5
	/y3wAXTIZqa1i8po9u6BtqBlGnNF09865+dXtDz7XZj9/Vsxqq4DT4HxH31Hnv628DHJocuN/0A
	2ZsPq4LsqP8YAEEdD3tBEzjftC098miyw3OgMPm0+zb9NTCfUXSm8FMrxkFDbXL7x4X9cRI+yZD
	7f8Q2ox+7CjbX19LDhXHfXuX+l+NO4czDWlQnCeE0T+Qp+1cMMH1ij4ul3fQYUg7ZnX5Lk6UwbE
	j+qFlWU00IEge0AXP3DpRlnLuRUJXy7u0fuBsQM8JDux/u5a774JyAmG723S21Pvpnm8yDSgaus
	Rjhk/4+JJBg1WiU6oeqi7lNBMQiIDaFplkw==
X-Google-Smtp-Source: AGHT+IGGQ7NvgDsfuiAWCA46sv02b09CkDopMWaZ/5Lkp1s7+9CQeYnYoAEWbBDrB5w+u3eS1tdXLQ==
X-Received: by 2002:a05:6512:2203:b0:553:3303:471 with SMTP id 2adb3069b0e04-5533b90af1emr4945561e87.30.1748962198615;
        Tue, 03 Jun 2025 07:49:58 -0700 (PDT)
From: "Edgar E. Iglesias" 
To: xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	julien@xen.org,
	bertrand.marquis@arm.com,
	michal.orzel@amd.com,
	Volodymyr_Babchuk@epam.com,
	andrew.cooper3@citrix.com,
	edgar.iglesias@amd.com,
	Nick Rosbrook ,
	George Dunlap ,
	Anthony PERARD 
Subject: [PATCH v4 5/5] tools/golang: Regenerate bindings for trap_unmapped_accesses
Date: Tue,  3 Jun 2025 16:49:48 +0200
Message-ID: <20250603144948.1685047-6-edgar.iglesias@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250603144948.1685047-1-edgar.iglesias@gmail.com>
References: <20250603144948.1685047-1-edgar.iglesias@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: "Edgar E. Iglesias" 

Signed-off-by: Edgar E. Iglesias 
---
 tools/golang/xenlight/helpers.gen.go | 6 ++++++
 tools/golang/xenlight/types.gen.go   | 1 +
 2 files changed, 7 insertions(+)

diff --git a/tools/golang/xenlight/helpers.gen.go b/tools/golang/xenlight/helpers.gen.go
index 90846ea8e8..191be87297 100644
--- a/tools/golang/xenlight/helpers.gen.go
+++ b/tools/golang/xenlight/helpers.gen.go
@@ -1170,6 +1170,9 @@ x.Altp2M = Altp2MMode(xc.altp2m)
 x.VmtraceBufKb = int(xc.vmtrace_buf_kb)
 if err := x.Vpmu.fromC(&xc.vpmu);err != nil {
 return fmt.Errorf("converting field Vpmu: %v", err)
+}
+if err := x.TrapUnmappedAccesses.fromC(&xc.trap_unmapped_accesses);err != nil {
+return fmt.Errorf("converting field TrapUnmappedAccesses: %v", err)
 }
 
  return nil}
@@ -1695,6 +1698,9 @@ xc.altp2m = C.libxl_altp2m_mode(x.Altp2M)
 xc.vmtrace_buf_kb = C.int(x.VmtraceBufKb)
 if err := x.Vpmu.toC(&xc.vpmu); err != nil {
 return fmt.Errorf("converting field Vpmu: %v", err)
+}
+if err := x.TrapUnmappedAccesses.toC(&xc.trap_unmapped_accesses); err != nil {
+return fmt.Errorf("converting field TrapUnmappedAccesses: %v", err)
 }
 
  return nil
diff --git a/tools/golang/xenlight/types.gen.go b/tools/golang/xenlight/types.gen.go
index e7667f1ce3..656933c6c9 100644
--- a/tools/golang/xenlight/types.gen.go
+++ b/tools/golang/xenlight/types.gen.go
@@ -606,6 +606,7 @@ MsrRelaxed Defbool
 Altp2M Altp2MMode
 VmtraceBufKb int
 Vpmu Defbool
+TrapUnmappedAccesses Defbool
 }
 
 type DomainBuildInfoTypeUnion interface {
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 14:59:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 14:59:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004602.1384339 (Exim 4.92)
	(envelope-from )
	id 1uMT6d-0002Nr-CM; Tue, 03 Jun 2025 14:59:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004602.1384339; Tue, 03 Jun 2025 14: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 1uMT6d-0002Nk-7T; Tue, 03 Jun 2025 14:59:11 +0000
Received: by outflank-mailman (input) for mailman id 1004602;
 Tue, 03 Jun 2025 14:59: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 1uMT6c-0002Ne-18
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 14:59:10 +0000
Received: from NAM02-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam02on2061c.outbound.protection.outlook.com
 [2a01:111:f403:2405::61c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4bd8e97f-408b-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 16:59:08 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by PH7PR12MB7331.namprd12.prod.outlook.com (2603:10b6:510:20e::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.32; Tue, 3 Jun
 2025 14:59:04 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8792.034; Tue, 3 Jun 2025
 14:59: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: 4bd8e97f-408b-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=MZ6AtuHzaMqLbEKSCIjOh7uOXVeSUJhYb7ymOUxDg+LjnHmZhjHG+n0ar4vztMX8Wft9c537Dj8TPKP8XPOffe+bqkIuq/D9LXyLsdqoVX3FJG59EG9Yk7z4ifCBjGpxdaIkNQjWoJV5FVneNVZzu7gwfMaFmiPcQcMZ+MFhvZy2kiV487/ICPt15tnzxUTfJLajE8B4d8iBHPqifkwT9R1B1si4ALeikgKLHSo+AK0PYA/inI6QVfO1TlvNh20egpiAb2IqLZCH5rOPcnmPZ2BmLhS/fE2kgw/+w6JtHU6rBBuRqAroYbR71iry2uidAlfHZ4+25+q7LO2rdiKeOw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ZumHIjBi/UCD0syGquwVwzUx23wes+j9/Sllq/MIZX4=;
 b=W1qi8VE6M5GwhNwXJyfMxwMaCINEBCF1JapwQcJuKgyYR8EAWZ+9OON1JgxMssGtFReRUC4YLLn5PhMHCbmBhmCmfLbG8oCXtQE5QNXY6drw0uGUcYH7JwOl0r4a5qhhPlVF5WzudnslKAkBm3ztSy+DRnj9RL0GJQ61fAnsyPCsJnVWK0ytzWStRYmOdvUIApEqT+UjleSL5QB2DXlQWBJqUaHc2A8WqSB5pkiN1vIC8bObA2Wi1Z3qbdjkSDJDmhzyHeia1wCEdVRWXfCTbQQMdHTD8ZjOeskUdKBDGTBBPk2DjxfobWisvhZsv6ZwBPRkKEJR00SdwACbOi4qhA==
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=ZumHIjBi/UCD0syGquwVwzUx23wes+j9/Sllq/MIZX4=;
 b=HlT9hHrm4S6/nt5IynPZDS23Au7bTL3Vrz1qrBAZxYc0/8rGZqyii2lRSgNWwYvAgqmC+Fn53LwOewTqeamRclsN3DEOiFSak4icUNthQED6gwqHW0khlho2n4xrWzVlkfVVB7NoT/5WPOtfZnccVU/QXUvsnswSNNkRvoUEP78=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Tue, 3 Jun 2025 16:58:59 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/4] device-tree: Move Arm's static-memory feature to
 common
To: Julien Grall , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20250603100329.149851-1-michal.orzel@amd.com>
 <20250603100329.149851-4-michal.orzel@amd.com>
 
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LO4P265CA0192.GBRP265.PROD.OUTLOOK.COM
 (2603:10a6:600:311::20) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|PH7PR12MB7331:EE_
X-MS-Office365-Filtering-Correlation-Id: 254b9726-fcfe-46dd-7fe1-08dda2af2e4b
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?dHAvd0lZZkg0cUNWRHRnSVd4RkNVSk4rc05jNS85bnB5ZXhkMHJVRUJQNXFy?=
 =?utf-8?B?NWN5K2NmbFd3UUR6WCsrZjdsSGkzbWZaaThYbk5oZUhGelJBOWszQjZXNkUv?=
 =?utf-8?B?SnRhNHluK2pzME5NRW85MXJtL1ZWM3RxSUZGRTFlbVZ1WGJxOEN0dVJmQUhM?=
 =?utf-8?B?SG03d3cySjNPMU5OZkphS1VtMnhNQlhqRGRoWVZ5eTdITHlVL2RBVUVmbmhX?=
 =?utf-8?B?dDhKdk5HWWljRGkvWE1lT1dvYUkzdVZKL0hrRWs1V1lGbzkvV0s3d0xMNzlK?=
 =?utf-8?B?OG9Scno4S1ZIWjcvNVFnTDdRbGo1WEsrMFBxbDRRdHBxRkdaYjdUNnB1SlM5?=
 =?utf-8?B?V3dRSENvSWdLenFTS1hMc0htZG4xZXJ1cDFsWVphSyszcTUrRjFiTDBWTk5C?=
 =?utf-8?B?dUxqZHMwZFZ2TVhubWExNE1UU1BEVHpqOEU4NHBHbHlMVXA4RVdacjVIQTg3?=
 =?utf-8?B?T0I2WHRaMU81NHMwenVnVFZ6T3ZYbzA1U0hvRXNZRnp1TTQ0dS9URDdnYTZV?=
 =?utf-8?B?OHc0ZDRUNWt1MnY4azUzQXVxMUlKK2p6SW4yNzBRdXlkaXloRHoxakF3UEsx?=
 =?utf-8?B?TldjNGtQeldVMTdLMlFxVHZaQTRjVytWUnhGSTZjck04Yk43QjNtN1VYWmlT?=
 =?utf-8?B?RDNocFJlUEswMzE3MS9qcy9CN1diQVZLZ2h0cHlVaDZPejFyUkt6R3k1VFEx?=
 =?utf-8?B?aHJHRDBoZTRIcWtKUDJXVW1GL2RNZTR6S3JSMVg0enA4aEJaSHdubWJ6V1Ro?=
 =?utf-8?B?dldTTkxSTXA0YzExWURqbVdSSjBRbHUvZXNwUnU0NWpZS3JnVjQzbEVrMG8v?=
 =?utf-8?B?ek1hdFdSb1hRYWh4RVlhdWtVRmR3WkJKWkwzQ2kzc2RmY1Y5WUZBelROTHp6?=
 =?utf-8?B?TXFiSFBNU2NVLzZNQXpyT00wRlJETU5HWDBGVjJvbVRnYkY4SGIrU3BYYlUv?=
 =?utf-8?B?blZDZDBQR24xNStVTTRxdEdzYjBnQyt4V2ZmMU5zK1pJMUdlTUlmL2c3aC94?=
 =?utf-8?B?NVJxWFBIKysyUDV2M0pVMzdYZWYySVd1bEI3ZFZPTjZDbUNaSjZVZExDZW1B?=
 =?utf-8?B?Tk0ybkdleS9zQVJ1bHRVdkxiMzBVRzV5Rk5ESVlLNmpEWnk3TGlzY2FEZnZp?=
 =?utf-8?B?cGFXMklERzN3SmFwaXpLR0t4REdtbnlRRzUyQTA4OGs3bU52QnByYjh5QVg4?=
 =?utf-8?B?MG5LUjNoNlpiaHQ0UVJzRzBRcVhYbzhYTGJpRDNMbzVUU2ZTNE5QV1VLZkVB?=
 =?utf-8?B?U2tEMzEySkRUYkRWd1ZtWkpYOWZta3F0ai93QmtjeW4yaFBpWFoyWnQ5LzlL?=
 =?utf-8?B?OGFNTE43NnJvaFJ6TWNsQTlYdFAyajFLSUdsUVkvSFVKbmF6T2ZJdEZ4ZUxK?=
 =?utf-8?B?Skc0aFRkRnRkREtJYXo5SCtnNDZDUks1MVJsc0p4cTcycTZGdEkxdW0vYWpm?=
 =?utf-8?B?VXh0cEo3WEdhV0lZak9NWXQxWTRhRHlNZ3g2RDJGMDJGcWgvK0p6S3hpY2d5?=
 =?utf-8?B?Z2FSTFl1dHFEYitHbkZURWhkMmFLQWVPejZiUnZ3bFN4Zm1PT0UyVXhadXEw?=
 =?utf-8?B?VFkrVHRwWTZHZnBBUzV6ZDUyTVAxL2FjdEhLY2ViWlFvWGNLQlJadmhWNUxN?=
 =?utf-8?B?em1HajNmckRMamJkSWVVc3R0bnAzaXIwMVdZZTVKdGNKUmYzMnpsaGVTTk5u?=
 =?utf-8?B?c3M0QmdpUEpXUitVOVhkSDQvcU9Sd3E3Yk5tRVZMWUFBenRkalMzcXZPSS9N?=
 =?utf-8?B?VzJWV0RVaE9pM2F6THJzVk1sZXNMNGRzOHFHbVd5L1BvQTVQdUx6LzlKZ2lP?=
 =?utf-8?B?T0ZSR0h4Z0hsMFVHRGZTM1NENzhmNEVhd2JvYWQxclF2a3BxNWxVck1WR1Uw?=
 =?utf-8?B?Vm5wU3d2VlBiZm5oMVQwQS9rNlVXdWZNeGN4K2JVejVWKzFuZWJ1VGNtSCth?=
 =?utf-8?Q?MnTVXAPZe50=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.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?NjF2Z09kYlcwOUl4YkVPSmpycllCWmtJMWd1V3liUWtDMnAxaGo4bjBQVnhC?=
 =?utf-8?B?cllmS1FHOGExRElCSFY1NUpIT1VXQWp4cUVNalJaZ283RFFWa05rRVNRS1Nl?=
 =?utf-8?B?ZysvY3FXZDRZNW5DRkxyVXBjc3JiajFGcjVnVU04SERSbzhYNFd6c2g3alNo?=
 =?utf-8?B?S0pVZEFMN0pBa2tOSHdTZm4xa3NZOGRuUEZBZ2hsMVBoT0lSV0RTZ1kyTmEr?=
 =?utf-8?B?NWlaeDlJNm1xYUZaZDJKRVBuWjEyWnYzTkZBUGpJeXRSMGhZNERRc0d1VHVh?=
 =?utf-8?B?TWtOYSt2U1N5dlFTMVU3eWpkL3JrZ0NhREpyOWtPWHBqMFN3Yk0xNWdJUWRp?=
 =?utf-8?B?Wk9wMnM2NnM1YTlmN0JJKzhLQWdWa0drdERCT1JJU3BSODZrSyttWFJoaTRL?=
 =?utf-8?B?cTBLS3RFdnBCL1lDODYrVitScWFWNENFZTg5SzMvL3I0T2RzQmtZdkhTSitW?=
 =?utf-8?B?NGczUTVCZzUxYTVscjI1TElsM2VTOW5KeWRFOGtvWUZNcGJSVUhIWEt6TGc4?=
 =?utf-8?B?cVZyd2tBdEdpMTV6UEFHb3N0V0RYcEVXUmoxaEh3MlN4Vk4zNTYvYzRXeEdv?=
 =?utf-8?B?WE5aL3FxTkdjbmdkdHNXVVI5VCt4Z3AxV29sRWxMb2JyMWhNeHMxQlFiaTNE?=
 =?utf-8?B?QkRRL3M4MWJaSFVpTmF0REV2ODM4ekdKQjcrK21vSDAzZkhvbUN6YlZ3QVR3?=
 =?utf-8?B?aldPWTFRS2x6OEM3SEJFRkdoMjlZbnovQXBoTHN0QUFIN3F2VHpYeVE1STNh?=
 =?utf-8?B?azMrYWg1WUdGc1ZKNkFmWjdoU1M3YTl1OFdHZENlV1JEaU9jbDFoSmpVeWRU?=
 =?utf-8?B?Ni9VM0ZxRnc5a3JZSnNMT1VHYnlLVzJscGdIV1pTUm1lSnl5eldBWFljQWFC?=
 =?utf-8?B?MUs3VmJMN1FBT01TRXB3Rk1FZ21Gakp5b0RNclErNkNqTzNGNlVCa3BtSTFT?=
 =?utf-8?B?cmFWWWxub0NNcHdVWGMyMFhuSzRHSjZSOGtOeG5VNUZWNkRTaEV1Q2JkTFVz?=
 =?utf-8?B?SmQ2T1RCUlFiY0U0YlJFVWcxNWpRNXZtS08xcFlOa0RwaHZ5ZGY0UmwyWHhV?=
 =?utf-8?B?WHZhZzJUMnlNNnUxNUpxWGdrdzNobHFneGtzbWlqbWExUC8rekx2VUZQc3hk?=
 =?utf-8?B?bDNHOHc4VGRBUGNyMk1ZT1lGWEpNcGJ1MTNTL3plMnpmdTJrcUFTSjdEeEFM?=
 =?utf-8?B?WmJIbVRBblNmQ0VnZzVsYTJsdkVPMm83cXpHS1lyWTdqUWxvWXVRRFVjM25m?=
 =?utf-8?B?eVkyU3pMZ1NxeGhob09GenJGWmowa1IveDBJYnRic1FZUys3eE8zdnJRaU1Y?=
 =?utf-8?B?UlgrSUVtT3dxV2x2d0tIUlVoRTZBM0IxSUdGa05GWGJEVHJFYnViNXJQdHFB?=
 =?utf-8?B?czd5RTR6TFZ3M2xJLzJaVEpzemQxNXdIbmxhQy9HME81T1FYWkRhOFNoQjBT?=
 =?utf-8?B?eEQ5QjFYd3NwbFZhdTd0VkxMQVZjckh3WnpwcTdCc0ttMWZ2dGNOT2lEbjJM?=
 =?utf-8?B?M0Y1MkZDdDZZZWF5dnY3ZjU1aDZtUEZtR1Y2ZFZBZG5QUS9aWmpZM2QwcFIw?=
 =?utf-8?B?cTZmN2pLU3NZUDZtMFFPRWZMWTBCZGt6ekt1OW5paFg2a2cyeVlHaUVETTcv?=
 =?utf-8?B?cHRLTzl1S21aOGVTL0JrSTQ0MFVHQ0syUDJoUngwckRqTndYTUZxaUZKTUFW?=
 =?utf-8?B?TkpoMlk4UGk5RFNCT1dXSXM4YTRGVEd2ZWZQVEJqYk5oMUIreWtkdWRrN1BX?=
 =?utf-8?B?MGVzQUZoTDQ3U2tBci9qZzZKcEdTK1RRQnBvRyt6R0pUd1lub2JXeTdMMEo0?=
 =?utf-8?B?WTlrSEFtUFUyMlYrUjFUU1dKZUlhT0huMGcyaUwyTitVZWluWktTbzhoNXVK?=
 =?utf-8?B?bERQQ0k4ZXNUQS9VdTVVTE8xaHBOWEdUaHVwS2tZdzZTQUlXTkcwY0tlM2Jl?=
 =?utf-8?B?eE01R29ETEJYeU5haVFOOXhWaUs2RUY3M1NtRkZwdmw4SnVXRVVZbzdGcGRm?=
 =?utf-8?B?S2IyK2xMTkNSdDFTS290bmZyMU12WEQrQnJuZ3hhWXA1WnhZeE8wSW5rbmhl?=
 =?utf-8?B?LzIvVHBUZ05aL3J6MTBpNEJoZ1loaDZ0UnI2TmZidmx2eTVwU1ZYa1A1S3BK?=
 =?utf-8?Q?ilDo7BvUVPgDhj75LN1wpKGZR?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 254b9726-fcfe-46dd-7fe1-08dda2af2e4b
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jun 2025 14:59:03.8399
 (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: QD6wkKZktzj3yHeM8rdmp3fhFLFi9ak8Mz2RE2pcO7ChBWJ78PY3pVHLLt3PO84h
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB7331



On 03/06/2025 15:28, Julien Grall wrote:
> Hi Michal,
> 
> On 03/06/2025 11:03, Michal Orzel wrote:
>> This feature is arch agnostic, thus move it to common.
>>
>> Signed-off-by: Michal Orzel 
> 
> With one remark below:
> 
> Acked-by: Julien Grall 
> 
> [...]
> 
>> diff --git a/xen/arch/arm/include/asm/static-memory.h b/xen/include/xen/static-memory.h
>> similarity index 93%
>> rename from xen/arch/arm/include/asm/static-memory.h
>> rename to xen/include/xen/static-memory.h
>> index a32a3c6553bc..e445aa80578c 100644
>> --- a/xen/arch/arm/include/asm/static-memory.h
>> +++ b/xen/include/xen/static-memory.h
>> @@ -1,13 +1,14 @@
>>   /* SPDX-License-Identifier: GPL-2.0-only */
>>   
>> -#ifndef __ASM_STATIC_MEMORY_H_
>> -#define __ASM_STATIC_MEMORY_H_
>> +#ifndef XEN_STATIC_MEMORY_H
>> +#define XEN_STATIC_MEMORY_H
>>   
>>   #include 
>> -#include 
>>   
>>   #ifdef CONFIG_STATIC_MEMORY
>>   
>> +#include 
> 
> This change looks a bit odd in the context of the patch. I guess this is 
> moved because the include should not be used if !CONFIG_STATIC_MEMORY? I 
> am fine if you want to keep it here. But it would be worth mentioning in 
> the commit message.
Yes, I did want to mention this change but clearly forgot. Will add (on commit).

~Michal



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 15:20:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 15:20:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004616.1384348 (Exim 4.92)
	(envelope-from )
	id 1uMTRU-0007Au-Vc; Tue, 03 Jun 2025 15:20:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004616.1384348; Tue, 03 Jun 2025 15:20: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 1uMTRU-0007An-Si; Tue, 03 Jun 2025 15:20:44 +0000
Received: by outflank-mailman (input) for mailman id 1004616;
 Tue, 03 Jun 2025 15:20: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 1uMTRT-00079Q-7k
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 15:20:44 +0000
Received: from 13.mo561.mail-out.ovh.net (13.mo561.mail-out.ovh.net
 [188.165.33.202]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4faf0af2-408e-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 17:20:41 +0200 (CEST)
Received: from director2.ghost.mail-out.ovh.net (unknown [10.108.25.35])
 by mo561.mail-out.ovh.net (Postfix) with ESMTP id 4bBZCs2Tyzz1TcZ
 for ; Tue,  3 Jun 2025 15:20:41 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-fr2dt (unknown [10.111.182.11])
 by director2.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 79B42C1A5C;
 Tue,  3 Jun 2025 15:20:39 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.112])
 by ghost-submission-5b5ff79f4f-fr2dt with ESMTPSA
 id 3Y3fCscSP2i6zAAA8fgr3w
 (envelope-from ); Tue, 03 Jun 2025 15:20: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: 4faf0af2-408e-11f0-a300-13f23c93f187
Authentication-Results:garm.ovh; auth=pass (GARM-112S00639f4f7c0-0b7e-4de7-8627-021896060042,
                    22913471B39E4060B5DF5B2870BF10C0EF5640C4) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
Date: Tue, 3 Jun 2025 18:20:16 +0300
From: Sergii Dmytruk 
To: Jan Beulich 
Cc: "Daniel P. Smith" ,
	Ross Philipson ,
	Andrew Cooper ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	Lukasz Hawrylko ,
	Mateusz =?iso-8859-1?Q?M=F3wka?= ,
	trenchboot-devel@googlegroups.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 01/22] x86/include/asm/intel-txt.h: constants and
 accessors for TXT registers and heap
Message-ID: 
References: 
 
 
 
 <31c7faf1-d393-40d5-87f9-1a01d1ab39cb@suse.com>
 
 
 
 <70310915-478c-460c-b7be-44002a15922b@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <70310915-478c-460c-b7be-44002a15922b@suse.com>
X-Ovh-Tracer-Id: 1353613165104116825
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugdehkecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhepvdfgveegtdffhfdugeevieehkeetudevfeefgedtleejledvfeeutdetudeiveelnecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukeegrddvvddupdefjedrheelrddugedvrdduuddvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheeiudgmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=/7jwljHWEo6BH4mdXV7mdM8WMyUE0FU/S8nFAxCmD7Q=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1748964041; v=1;
 b=YhswgaQEysClvGIX+DVMKOALkptV7zHLyK9waLu68RP5jh3LIaJxLqnTfd5PXioomqunDzcx
 +7WBlIfYYI4mGoPPKOHGLcEqByaecEfWJ4FbTwP2NpIYtXQSEbs+ZHHUA8MX4WeoUh6CVytLs5E
 77aRrH8H1G/BsXkETScYtWCiNrB0fHGK14c+RtiiK6d7u7R6M/bM63vYi2wSENiDFoMfHiOBuzv
 MfD0bnq8Eo1OuTggF5yvlYrvFRITIUpRST4a68umQoBz4Svj2EMg5j909hSx49uKnEiXpPnpZJu
 NadKpDd3ra5JzIMSYyqCDJ6VOEnPtZm2LIUf0KMNflIXA==

On Tue, Jun 03, 2025 at 10:52:09AM +0200, Jan Beulich wrote:
> On 03.06.2025 10:50, Sergii Dmytruk wrote:
> > On Tue, Jun 03, 2025 at 09:06:53AM +0200, Jan Beulich wrote:
> >> On 03.06.2025 00:00, Sergii Dmytruk wrote:
> >>> On Mon, Jun 02, 2025 at 09:17:37AM +0200, Jan Beulich wrote:
> >>>> On 23.05.2025 21:51, Sergii Dmytruk wrote:
> >>>>> On Wed, May 21, 2025 at 05:19:57PM +0200, Jan Beulich wrote:
> >>>>>>> +static inline uint64_t txt_bios_data_size(void *heap)
> >>>>>>
> >>>>>> Here, below, and in general: Please try to have code be const-correct, i.e.
> >>>>>> use pointers-to-const wherever applicable.
> >>>>>
> >>>>> I assume this doesn't apply to functions returning `void *`.  The
> >>>>> approach used in libc is to accept pointers-to-const but then cast the
> >>>>> constness away for the return value, but this header isn't a widely-used
> >>>>> code.
> >>>>
> >>>> Which is, from all I know, bad practice not only by my own view.
> >>>
> >>> I actually ended up doing that to have const-correctness in v3.  In the
> >>> absence of function overloads the casts have to be somewhere, can put
> >>> them in the calling code instead.
> >>
> >> Casts of which kind? For context: There shouldn't be any casting away of
> >> const-ness (or volatile-ness, for the sake of completeness).
> >>
> >> Jan
> >
> > Casting away const-ness inside of functions like
> >
> >     static inline void *txt_bios_data_start(const void *heap)
> >
> > If a function accepts a const pointer and returns it, this turns a
> > non-const incoming pointer into a const one.  Without duplicating the
> > code (either having const and non-const versions or repeating code in
> > other ways), nothing can be made const cleanly in here including
> > *_size() functions because they call *_start() functions:
> >
> >     static inline uint64_t txt_os_mle_data_size(const void *heap)
> >     {
> >         return *((const uint64_t *)(txt_bios_data_start(heap) +
> >                                                      // ^^^^ -- const
> >                                     txt_bios_data_size(heap))) -
> >                sizeof(uint64_t);
> >     }
>
> Yet just to repeat: Besides myself (and maybe others), Misra objects to
> the casting away of const-ness.
>
> Jan

OK, I'll change it back then unless I'll find a way to preserve some
const-ness without duplication.

Regards


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 15:58:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 15:58:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004642.1384357 (Exim 4.92)
	(envelope-from )
	id 1uMU2K-0003Xj-KT; Tue, 03 Jun 2025 15:58:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004642.1384357; Tue, 03 Jun 2025 15: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 1uMU2K-0003Xc-Hp; Tue, 03 Jun 2025 15:58:48 +0000
Received: by outflank-mailman (input) for mailman id 1004642;
 Tue, 03 Jun 2025 15:58:47 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uMU2J-0003XG-DK
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 15:58:47 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uMU2I-000GMx-2D;
 Tue, 03 Jun 2025 15:58:46 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (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 1uMU2I-006BcW-2J;
 Tue, 03 Jun 2025 15:58: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=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding:
	Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date;
	bh=WgWMHehosbmoZ5s9vhs7cuJMPBtHntjnuJFYBdCbYLU=; b=qTBwXa7aRB5QN44d3OTwvxfYMr
	gz0HUcD1wMoV6IYLijnDi1g7MjoTnrMJtGr8bBGfg/LLUDqPYSfdMIBVnJddHMNd71DXV0KLpVvqH
	ISnhwV/A3oWxO3e4C0kBY49wmpWF4BXDDbVasas81obfxStia0kvA8mgWh+IhRzkScFU=;
Date: Tue, 3 Jun 2025 17:58:44 +0200
From: Anthony PERARD 
To: Andrew Cooper 
Cc: xen-devel@lists.xenproject.org,
	Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= ,
	Anthony PERARD ,
	Doug Goldstein ,
	Stefano Stabellini 
Subject: Re: [XEN PATCH 5/9] CI: Have the gitlab job fail on tools/tests
 failure
Message-ID: 
References: <20250603124222.52057-1-anthony@xenproject.org>
 <20250603124222.52057-6-anthony@xenproject.org>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Tue, Jun 03, 2025 at 02:41:50PM +0100, Andrew Cooper wrote:
> On 03/06/2025 1:42 pm, Anthony PERARD wrote:
> >  if [ -n "$retrieve_xml" ]; then
> >      nc -w 10 "$SUT_ADDR" 8080 > tests-junit.xml  > +    # Findout if one of the test failed
> > +    if ! grep -q '' tests-junit.xml; then
> > +        echo "ERROR: tests-junit.xml is incomplete or missing."
> > +        TEST_RESULT=1
> > +    elif grep -q '' tests-junit.xml; then
> > +        TEST_RESULT=1
> > +    fi
> >  fi
> >  
> >  exit "$TEST_RESULT"
> 
> A couple of things.
> 
> From my experimentation with junit,
> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1849342222/test_report?job_name=kbl-xtf-x86-64-gcc-debug
> we can also use  for classification. I'm also very disappointed
> in Gitlab classifying  as success.

According to the documentation [1] which point to this junit xml format [2]
the only elements (and path) are:
    testsuites.testsuite.testcase.failure
"error" or "warning" don't exist.
There's the attributes `type` in  but this isn't explained how
it's used.

But I guess if we follow the link in [2], go through web.archive.org, we
can find [3] which has "skipped", "error", "failure", but still no
"warning".


[1] https://docs.gitlab.com/ci/testing/unit_test_reports/#unit-test-reporting-workflow
[2] https://www.ibm.com/docs/en/developer-for-zos/16.0?topic=formats-junit-xml-format
[3] https://github.com/windyroad/JUnit-Schema/blob/master/JUnit.xsd


> Not for this patch, but for XTF I need to be able to express "tolerable
> failure". (All branches of Xen will run the same tests, and we don't
> have OSSTest to deem "fail never passed" as non-blocking.)

According to [1], there's a notion of "Existing failures", but that
might show up only on merge request.

> Even if the job passes overall, I want tolerable failures to show up in
> the UI, so I have to use  in junit.xml. But that means needing
> to be more selective, and I don't have a good idea of how to do this.
> (I have one terrible idea, which is  which
> will escape that grep, but it feels like (ab)buse of XML.)

At the moment, `run-tools-tests` write '' at first because that's
much less likely to be written differently, while the attributes in the
tag could be written in a different order.

Then, we can always use `sed` and extract the "type" to check it:
sed -n 's/.*
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 16:03:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004652.1384369 (Exim 4.92)
	(envelope-from )
	id 1uMU6Y-0005lI-AJ; Tue, 03 Jun 2025 16:03:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004652.1384369; Tue, 03 Jun 2025 16:03: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 1uMU6Y-0005lB-5o; Tue, 03 Jun 2025 16:03:10 +0000
Received: by outflank-mailman (input) for mailman id 1004652;
 Tue, 03 Jun 2025 16:03:09 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uMU6X-0005l5-5A
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 16:03:09 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uMU6W-000Gzj-2l;
 Tue, 03 Jun 2025 16:03:08 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (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 1uMU6W-006EQw-2w;
 Tue, 03 Jun 2025 16:03: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=pisaKtL3MIeruJOLIMwS+fjY5pQV6SvYfczT5BZv9i8=; b=qUQwvCiWihEVxjQOYDCpgN3kRI
	zMaBoDVZ59AqRrKRPhwqMTD3gn5FRWQK4oyrxu6WRMy3eea42GN3gbtxXpJl/8tfINq943XOm24VD
	4l/phc+FKJlwM9A9qI5W+5cZlsJb0vgiHDipfYBzfNVSBn+2vljVQhZpskGo68RezwQw=;
Date: Tue, 3 Jun 2025 18:03:06 +0200
From: Anthony PERARD 
To: Andrew Cooper 
Cc: xen-devel@lists.xenproject.org,
	Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= ,
	Anthony PERARD ,
	Doug Goldstein ,
	Stefano Stabellini 
Subject: Re: [XEN PATCH 6/9] CI: Upload junit result as artefact
Message-ID: 
References: <20250603124222.52057-1-anthony@xenproject.org>
 <20250603124222.52057-7-anthony@xenproject.org>
 <30007ef7-9576-41fb-8d4d-08ae7cbdacc4@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <30007ef7-9576-41fb-8d4d-08ae7cbdacc4@citrix.com>

On Tue, Jun 03, 2025 at 02:13:59PM +0100, Andrew Cooper wrote:
> On 03/06/2025 1:42 pm, Anthony PERARD wrote:
> > From: Anthony PERARD 
> >
> > This allow to investigate the file in cases of error. Not all
> > jobs that extend ".adl-x86-64" are creating a "tests-junit.xml" but
> > Gitlab only produce a warning when the file isn't found.
> 
> I'm not sure what you're trying to say here.

I guess I can shorten the message to (with some rewording):
    "This allows to investigate the junit file in cases of parse error."

I guess it doesn't matter if a gitlab job is expected to produce
"tests-junit.xml" or not.

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 16:11:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 16:11:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004665.1384378 (Exim 4.92)
	(envelope-from )
	id 1uMUEl-0007Oe-Vp; Tue, 03 Jun 2025 16:11:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004665.1384378; Tue, 03 Jun 2025 16:11: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 1uMUEl-0007OX-Sm; Tue, 03 Jun 2025 16:11:39 +0000
Received: by outflank-mailman (input) for mailman id 1004665;
 Tue, 03 Jun 2025 16:11: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 1uMUEk-0007OR-DT
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 16:11:38 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20606.outbound.protection.outlook.com
 [2a01:111:f403:2412::606])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6b14c43a-4095-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 18:11:35 +0200 (CEST)
Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
 by PH7PR12MB6836.namprd12.prod.outlook.com (2603:10b6:510:1b6::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.33; Tue, 3 Jun
 2025 16:11:30 +0000
Received: from PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264]) by PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264%2]) with mapi id 15.20.8769.031; Tue, 3 Jun 2025
 16:11: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: 6b14c43a-4095-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=R/EDlJB8P0ShBNtR6yt+ec6W5K4ymOQDfl1t3ROr0t0b2QNG+RUk+AswlRWRSwih8uXMCrdLh8zoP5Qw1Lvjt2wHfJhE0gpmfQqZfgztzu73QnMATeAUxX31Dp07VKlFljKO4PuVDLNzFj384/OnROfb2D6qbkxCYh6WYEHyJCTMD0Aexnyd4jINTrenAtFl3MOm9gEUYbKXNZ9NY8VQHgWbxetbKQEG5h4BkVy7Gpx2jzSkLHmi7RO+MRWddH6x/SlXAMx4j1dHaIbCTE0beQHYPC5oQEOD6PI7/gk5GcRXEWuk9G6IqnL1AHieOYjKSjVNRauLUA1WJgbq7x3BHA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=UjxxjXuEmRkNz6IqfMUzFoKrRWLUe7OdTNH04naV+70=;
 b=ZfTg9LRWp5jV2crwlP+LG3ZAQ35smmstEOuH1+KfylZvYQ84/tLMIV91noF1SQxR/xxBKyL5xwl0yj1OSpw09sVesEFhkzXpcoURUbToKRsIBIJyyLvVFnnwG7FcOvTCvuAM/as7Kgvw6wulm4m0b41i2Fk+/8DdwuT1uxavTRfeiQw7EJi+d1kEJgJLdZ2Y4CwlZeaMSZNQg4fQI695AbCeq15ehatFXCjd46t4d63Kc72cwXJcJOSaqEy57o+X3frUp3tFdSoJkBT3geD354oRt8jNw08O8YO3phgt81ms16DmKYpeDPGjEV3PUeVP2g0DS8RJ+VTXMbgRs6pBng==
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=UjxxjXuEmRkNz6IqfMUzFoKrRWLUe7OdTNH04naV+70=;
 b=rFvtzUik8TnS/5BC2cp5icC3bikyw09jBkLTNqtfPqGaF7MGBkMM1MVaynHcK50BJrHLpBEbNO9mafHs+P/bPiLKi0p6zroKkQod2dd0srnkWutw6DhgyaBA8bINAu7+6xjxQbf5uL1CKxTlrd6UDjiK0w5124ml8LSIDfsUDLQ=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Tue, 3 Jun 2025 17:11:25 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/2] docs: fusa: Add the requirements for few commands
 of XEN_VERSION
Content-Language: en-GB
To: Bertrand Marquis ,
 Ayan Kumar Halder 
Cc: "xen-devel@lists.xenproject.org" ,
 Stefano Stabellini ,
 Michal Orzel , Artem Mygaiev 
References: <20250509112447.2931909-1-ayan.kumar.halder@amd.com>
 <20250509112447.2931909-2-ayan.kumar.halder@amd.com>
 
From: Ayan Kumar Halder 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: GV2PEPF00006634.SWEP280.PROD.OUTLOOK.COM
 (2603:10a6:158:401::3d6) To PH8PR12MB7326.namprd12.prod.outlook.com
 (2603:10b6:510:216::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|PH7PR12MB6836:EE_
X-MS-Office365-Filtering-Correlation-Id: dccdee45-11dc-4584-99eb-08dda2b94cf9
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|13003099007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?eGJJWTBWU0VqdTRHZ3ljRkdja2IyRSsyRUxxRkxvT1VIMkNLN0VqeXdMcVR5?=
 =?utf-8?B?R2hMTjI0NzBMUlhXTW8zd0doMGhLMWFkS3VNaktrMElNa21GejVaVm9jNVFk?=
 =?utf-8?B?cmJBMnBKekFyS0ZpcnRmVlNjbzFXT0xlT3ByQzVwNmRvTmRXaU4xOCt1NXR4?=
 =?utf-8?B?d2taSzJvMzZiWVpVdFN5U0Q5UVR5b1JubFhQbnpMb215Y2xRK0IrRHU4dEJG?=
 =?utf-8?B?UjFYdXJ3MUZwRGU0YUdIRXY3YUhaNVJ1ZitlVmcxRXFWWXpWM1pqTlVaNVdw?=
 =?utf-8?B?MGIrajc5QUJLYWNPNndDL2phRHg1SzhDSk53cEFVYjRjSEd4MC9yR2g4VldI?=
 =?utf-8?B?bCtHRXR6azIxQmU4aFBYQVd0czBYa245NGd3VFZNaWJyZC9RenduOGVNVFNE?=
 =?utf-8?B?WFNwMnR5cW5paVRyb2NpTEVUekdZaHZJUjlINS96SlNxcmVxUGpmZVZoTHFT?=
 =?utf-8?B?QkdTRklxRGNvRWJVeCtYeW0rUk15bEZnd3JublZQajlQb0pINTYvSGtQQ2w3?=
 =?utf-8?B?NiswVGYzdzg1eXo3ckplWC9WNzhUZHR6ZFYzV2xZREthN0RxT0JldEw2VlRO?=
 =?utf-8?B?MWNRYVhXMHRzcXZDQXpOOE1OQVFhMmp0VWp2bzA4N2tmdUt2OGdkdzA2UVlY?=
 =?utf-8?B?ZTYzWmxQeDZnMkoxNXM2V0pQdFlVeGw4czlXbnd2azY1ZEc2K1ptU1FUaThI?=
 =?utf-8?B?QnZJdldva3J0U2FScWMzQlZWWWxjZUwwc2F3M2U4TE9IVE9jWm12WDFCUmhr?=
 =?utf-8?B?NnMyZmJSVzNMdGpCV0dvZkI5Sk9RSUFjbkRJTldVS09YaEZpSDUxMzl4anlS?=
 =?utf-8?B?aXl1SGwxNlZ0UkVXNmJPeWhRWUMvdWVWRERmWnZGWW4yQVFKSzFHZFNHeFhH?=
 =?utf-8?B?R2htOEhSd0NBUGtWVnYzVEVZSURITjF1NzZ3Z2EwdGphdFhKbGhSemxRT2Nq?=
 =?utf-8?B?Y3R2V3gwbWt3Lzg0N1pMWGU0VWpUSDN4S3ZsWTVyNTFJbFlLUnU5amlySkRr?=
 =?utf-8?B?ang1c0VDRVpEb05lcUFrNThvSGVNU1lUQ3RTTCsvTHFTSGtaWUNaWmQycW8z?=
 =?utf-8?B?b1d2ZUZQN3RIZzlVTFhRbk5NZDBaMUNzUG9vMWR1M1ZLKzF6eFZQaFZ0L0lL?=
 =?utf-8?B?cERhRDRIUCtQcDl6dzlWMFNkNXFHL2lyQk44Smx4YVdzUGFyN1VlQStvRDNI?=
 =?utf-8?B?R0VsNWVNOFBETzBuYjQ0eTNSeTlsMXZHTEdja21xdStHbVVKaEo1dU90UlVt?=
 =?utf-8?B?enF1VnFwNDQ1OEFPTHBwWG4xL21La093K1F2ZzRXYjdUVGdPbi9xU0FwQ2xR?=
 =?utf-8?B?NW1uckd0UW1PeCtGb0VDQVBMbkFCbDNNM1ZpdjdwSTZaamsyZThYZUFKcEF2?=
 =?utf-8?B?ckRhNURtZGdOc1FRV3RkbExqamNERnZxMU5LZDA0OUZ0UFIwaUN4M0k3aE90?=
 =?utf-8?B?azFiZ0VocGRJOGZNQVYzSE1RcFBDaXNlZzdyRFJnUkVDQ3JvQU4ya05SN2Fx?=
 =?utf-8?B?WEx0bWt4ZkFXWklXM1hzWFdnRTh2MWM5WVZpNGJKSlZKMFdvbXphSHFxSzVq?=
 =?utf-8?B?OXFma3U3S2NsRGtJSjYyV1ZFSHUyTmd2YVZGNWFlME1hYXF2czZPMjRSdG83?=
 =?utf-8?B?K3FYOGgwVGttcmVIRlNVbDVINUQ3WVNYbmlKejA5VzBiamZnWi8vV25Fa1RR?=
 =?utf-8?B?c05UR2IxZHZNUHlZWEpVZlhKSmJXQ0kwYnovWTU0REY1aDYvT2hqSjhlYXZM?=
 =?utf-8?B?ZEVDUXc1RS9LSEhXVlhxOExKT3ZRVXNmdVRNUDgydWhzTmlaamlxMXpDcm9h?=
 =?utf-8?B?Q0Q0K3ZnZ0ZnUi83ZGh5WHBwL3cwYnZGSzdoOHhQaVY0aWcrRVZwUjA2SFd5?=
 =?utf-8?Q?iwyapETfnriHt?=
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)(1800799024)(376014)(13003099007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?dmdyais0dVRRZEZNV29VdjNZdGpwRmVsbEx4bndLOVpHUjZ5WjhrdDRrZmty?=
 =?utf-8?B?VjNIdXBOZlFveTQvR28zNFVFWU9UQWt6dER6ODVXTE5vMjBoSVZ5Z1NSRnli?=
 =?utf-8?B?TjNRU2g3TW1xNnZQSmRWT1FRTkFpYlV3WGcrcjFoa0M1L1pWN3NBRnNBYVRM?=
 =?utf-8?B?NFBhOVBzZ1J3Q09DVi9sKzhUSSt2anZRRXlHSkFzL3ZqWDN2eGlMQU5Tdkhj?=
 =?utf-8?B?azlWTzFVb0xGOGtpWnlXOGpvN29tTmpHdFp6UU02dWIyVnJrNVdLb04waHNt?=
 =?utf-8?B?NXUzMlV6Tmx0WTdCQ1U2djVCSkxtUEpZZmhDSGQ3dXJjQzdualFGcWkydTk1?=
 =?utf-8?B?Q0VHZ3BCV1F0dVhFaUZqRmFZQjN1VXpQNjc1blhWZHQxUFU1WVphQnlyaUNX?=
 =?utf-8?B?ZXgrdVlscVliRFhISEMzSWJsUzdqbjBaT0pMQzZHZWY3eUpiQzFhLzZteW1O?=
 =?utf-8?B?Zkc1OTc1MTZmeDA0M2d0c3NIZmtMSi9zZTNaaUdreTdrTWp2V096aFYydmhh?=
 =?utf-8?B?YWFSNWRNNGkvUXhWZjZPc1FJelhhbUplaU5aeC83b2Zwc1VHR0YxclRjMDVI?=
 =?utf-8?B?RFNzSXFxL0t3VUR2OHBRd2hOeTFwcmlCUkUyR0xNbkNFeUZZWGR1emYzYjdx?=
 =?utf-8?B?WnVWQmgzdTZBY2tyRGJWeXc1N3VNM3BuV3dHZnpodklpNXpTdHdvbjA5UlhQ?=
 =?utf-8?B?ejdNbG1mdURCYmlSNHlxeGJrcHdWNXMxbUxOaDgyRE4xNmNaYmFoaHdUN1pL?=
 =?utf-8?B?OWpRS25admZZTHh6TzhlY1hFMmRZVy9lTWVsZHBoeDBWeCtXaEVrVzVMRmpU?=
 =?utf-8?B?WGFSTHBCZ3gvUVBIY0pqZHlpeUxZdEprYjJab2ZZdnNxbXdJbE91dUI1YnVM?=
 =?utf-8?B?R1Bwazcwc2VhZ0M3MXdCSEhqNXdoMHZWUFlVTy9XM0NiQWhQbFQydnhVMWhy?=
 =?utf-8?B?eEN6bUVvUmQzZWY5WVI1VXlReTRnZnBTQXMrTEtFaXVya2VGV1lxZWxoZ0N6?=
 =?utf-8?B?OHZ5ejRWTEZLUEM4cENOUWorTDZKR2U3dnJWdUZFYTRDb1J1VjVSaVFzSHox?=
 =?utf-8?B?MkxmbmF3NTUwWk5YRjBvd0xjbmxTOUJjNjQxL0lFaG1Beis1UFdoVS9BYSt0?=
 =?utf-8?B?ZWJkM1NIb0ZaUmhsUWVWUm1ZcjYvQWhsOUZSWGUxQU0zMTNETDBRV0hoM1lZ?=
 =?utf-8?B?QVJDRUQ2WjQ5a2tlMjdsYVc5bVBNdERlbWNTVE9MV0hXREliN2FRU3I2SkIw?=
 =?utf-8?B?K0VOYXA2N0VkZW9zamlwcDNkSUs5NFA5MUQvM2FKbThwdmxRSmJDZW1sekZv?=
 =?utf-8?B?UXRVMForYTZTT2tWWVE5UGZYdktrd0ZDMXR2NnpqQWNMbmpKem5KZXlrQjhQ?=
 =?utf-8?B?RktJK2VNbnFIdmszV1FsL3VRVCs5U051QXliV2JrenFBdys0eE81amtGSktu?=
 =?utf-8?B?WFl0MFErSnJPYzM3dlBrRGs2WkRYWWM5L1NnQysyMmNEYllxYllJWmppNnFj?=
 =?utf-8?B?Rk12ME9NV3hTYnNEUzlBaTVJempBTWRRaUtWN1Fkc2xoZWtReVQ3K0s5eGJo?=
 =?utf-8?B?d3Y1aHJxYVZXVk00MjJ2OUlKdHd0WU5PU1h1dmE0Y01zeFQwTmFxeGUvN2Rw?=
 =?utf-8?B?USsvVmNkRVVLVkdxYmtPWms2UjJnUzlVWnQwa0paWlB2N05FVHRYRUNjeGJX?=
 =?utf-8?B?ZlAvb2theER0WGFMaGZjY0RUSUp4dWhnVVVtNGRSM3Vrb1ZuZkRtQ2ptUW5u?=
 =?utf-8?B?bnhaL2VjRVdmSFAyNTZDblVydmlVeklWOWQ5dVlIL3pBNk9JVU1Tb0pDLzVr?=
 =?utf-8?B?L3V3bHR1dEhCanhOK1FabDVnYkN1ZmFqT3JHVlVKc29HTTAyUU5pQ3d1Tzky?=
 =?utf-8?B?UWRPVUhnS3JzOTNLc1NWRXZtcjd2dnN4cmNQb256WXVqYSs2eEs0dFBhM3dy?=
 =?utf-8?B?cGhxK3M1Y3NjOVFuY2c0NFQ3UmJXTUlZYnlaK3Vua2ZiaW45RXd0bEkxL2Ri?=
 =?utf-8?B?MTdRSi84UmdwS0FzYlZ3NHVYKzluaUsvLzUwaXFHRjIzOFpjc2FQQ1l4dkxs?=
 =?utf-8?B?RkZoZHJWdzM5aHdOSnowcDJkNUdreGc1blBHWXZuc2JuaHJid29Xc29mY3N0?=
 =?utf-8?Q?QGS5jkEza07iUx2cAIr5w1Hcw?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dccdee45-11dc-4584-99eb-08dda2b94cf9
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jun 2025 16:11:30.3339
 (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: 8yNnVVIADP2qrFnoubKM9U9Mr9oaGprPc3ggvrRLv/Tg3MnsKzSgyJkSR3T1UYerwC04A1N2Ku3je+jlFDPNgw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6836


On 21/05/2025 13:10, Bertrand Marquis wrote:
> Hi Ayan,
Hi Bertrand,
>
>> On 9 May 2025, at 13:24, Ayan Kumar Halder  wrote:
>>
>> Define requirements for specific commands.
>>
>> Signed-off-by: Ayan Kumar Halder 
>> ---
>> Changes from -
>>
>> v1 - 1. Reworded the requirement so as to avoid mentioining variable names
>> or hardcoded strings. Otherwise, one would need to change the requirement
>> each time the code changes.
>>
>> v2 - 1. Moved few changes to previous patch.
>>
>> .../fusa/reqs/design-reqs/arm64/hypercall.rst | 15 ++++
>> .../design-reqs/arm64/version_hypercall.rst   | 34 ++++++++
>> .../reqs/design-reqs/version_hypercall.rst    | 82 ++++++++++++++++++
>> docs/fusa/reqs/index.rst                      |  3 +
>> docs/fusa/reqs/product-reqs/hypercall.rst     | 20 +++++
>> .../reqs/product-reqs/version_hypercall.rst   | 83 +++++++++++++++++++
>> 6 files changed, 237 insertions(+)
>> create mode 100644 docs/fusa/reqs/design-reqs/arm64/version_hypercall.rst
>> create mode 100644 docs/fusa/reqs/design-reqs/version_hypercall.rst
>> create mode 100644 docs/fusa/reqs/product-reqs/hypercall.rst
>>
>> diff --git a/docs/fusa/reqs/design-reqs/arm64/hypercall.rst b/docs/fusa/reqs/design-reqs/arm64/hypercall.rst
>> index f00b0b00f9..f58a9d50aa 100644
>> --- a/docs/fusa/reqs/design-reqs/arm64/hypercall.rst
>> +++ b/docs/fusa/reqs/design-reqs/arm64/hypercall.rst
>> @@ -56,3 +56,18 @@ Comments:
>> Covers:
>>   - `XenProd~version_hyp_first_param~1`
>>   - `XenProd~version_hyp_second_param~1`
>> +
>> +Return value
>> +------------
>> +
>> +`XenSwdgn~arm64_ret_val~1`
>> +
>> +Description:
>> +Xen shall store the return value in first cpu core register.
> use x0 instead.
Ack
>
>> +
>> +Rationale:
>> +
>> +Comments:
>> +
>> +Covers:
>> + - `XenProd~hyp_err_ret_val~1`
>> diff --git a/docs/fusa/reqs/design-reqs/arm64/version_hypercall.rst b/docs/fusa/reqs/design-reqs/arm64/version_hypercall.rst
>> new file mode 100644
>> index 0000000000..3aa12ea2c2
>> --- /dev/null
>> +++ b/docs/fusa/reqs/design-reqs/arm64/version_hypercall.rst
>> @@ -0,0 +1,34 @@
>> +.. SPDX-License-Identifier: CC-BY-4.0
>> +
>> +Capabilities
>> +------------
>> +
>> +`XenSwdgn~arm64_capabilities~1`
>> +
>> +Description:
>> +Xen shall have an internal constant string to denote that the cpu is running
>> +in arm64 mode.
> This is untestable if this is purely internal so this cannot be a requirement
> I am not quite sure why you need this, can you explain ?

We had agreed on this wording in "[PATCH v1 2/2] docs: fusa: Add the 
requirements for some of the commands of XEN_VERSION". You had mentioned 
this

```

All in all, the design just need to say that it must be stored somewhere "bounded" to the source code so that a tester can check it.

```

So, I infer that needs to be validated by code inspection. The string is 
set in init_xen_cap_info().

>
>> +
>> +Rationale:
>> +
>> +Comments:
>> +
>> +Covers:
>> + - `XenProd~version_hyp_capabilities_cmd~1`
>> +
>> +Capabilities AArch32
>> +--------------------
>> +
>> +`XenSwdgn~arm64_capabilities_aarch32~1`
>> +
>> +Description:
>> +Xen shall have a internal constant string to denote that the cpu is running in
>> +arm32 mode.
>> +
>> +Rationale:
>> +
>> +Comments:
>> +
>> +Covers:
>> + - `XenProd~version_hyp_capabilities_cmd~1`
>> +
>> diff --git a/docs/fusa/reqs/design-reqs/version_hypercall.rst b/docs/fusa/reqs/design-reqs/version_hypercall.rst
>> new file mode 100644
>> index 0000000000..aac5896965
>> --- /dev/null
>> +++ b/docs/fusa/reqs/design-reqs/version_hypercall.rst
>> @@ -0,0 +1,82 @@
>> +.. SPDX-License-Identifier: CC-BY-4.0
>> +
>> +Version
>> +-------
>> +
>> +`XenSwdgn~version~1`
>> +
>> +Description:
>> +Xen shall have a internal constant (XEN_VERSION) storing the version number
>> +coming from the Makefile.
> I really have doubts about this and the following one.
>
> If this only goal is to say what should be returned in the XEN_VERSION hypcall you might
> just need something saying it and mention this as a comment because you will have a very
> hard time to test such a requirement.

Should I say

Description:

Xen shall return its version when XENVER_version command is invoked.

If so , then ...

>
>> +
>> +Rationale:
>> +
>> +Comments:
>> +
>> +Covers:
>> + - `XenProd~version_hyp_version_cmd~1`
>> +
>> +Subversion
>> +----------
>> +
>> +`XenSwdgn~subversion~1`
>> +
>> +Description:
>> +Xen shall have a internal constant (XEN_SUBVERSION) storing the sub version
>> +number coming from the Makefile.
Xen shall return its extra version when XENVER_extraversion command is 
invoked.
>> +
>> +Rationale:
>> +
>> +Comments:
>> +
>> +Covers:
>> + - `XenProd~version_hyp_version_cmd~1`
>> +
>> +Error copying buffer
>> +--------------------
>> +
>> +`XenSwdgn~error_copy_buffer~1`
>> +
>> +Description:
>> +Xen shall return -EFAULT if it is not able to copy data to domain's buffer.
>> +
>> +Rationale:
>> +-EFAULT is one of the error code defined in
>> +http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/errno.h.
>> +
>> +Comments:
>> +
>> +Covers:
>> + - `XenProd~hyp_err_ret_val~1`
>> +
>> +Extraversion
>> +------------
>> +
>> +`XenSwdgn~extraversion~1`
>> +
>> +Description:
>> +Xen shall have a internal constant (XEN_EXTRAVERSION) storing the extraversion
>> +coming from the build environment.
>> +
>> +Rationale:
>> +
>> +Comments:
>> +
>> +Covers:
>> + - `XenProd~version_hyp_extraversion_cmd~1`
>> +
>> +Changeset
>> +---------
>> +
>> +`XenSwdgn~changeset~1`
>> +
>> +Description:
>> +Xen shall have a internal constant string (XEN_CHANGESET) storing the date,
>> +time and git hash of the last change made to Xen's codebase.
>> +
>> +Rationale:
>> +
>> +Comments:
>> +
>> +Covers:
>> + - `XenProd~version_hyp_changeset_cmd~1`
>> diff --git a/docs/fusa/reqs/index.rst b/docs/fusa/reqs/index.rst
>> index d8683edce7..de19b0cda2 100644
>> --- a/docs/fusa/reqs/index.rst
>> +++ b/docs/fusa/reqs/index.rst
>> @@ -11,6 +11,9 @@ Requirements documentation
>>     product-reqs/reqs
>>     product-reqs/arm64/reqs
>>     product-reqs/version_hypercall
>> +   product-reqs/hypercall
>>     design-reqs/arm64/generic-timer
>>     design-reqs/arm64/sbsa-uart
>>     design-reqs/arm64/hypercall
>> +   design-reqs/arm64/version_hypercall
>> +   design-reqs/version_hypercall
>> diff --git a/docs/fusa/reqs/product-reqs/hypercall.rst b/docs/fusa/reqs/product-reqs/hypercall.rst
>> new file mode 100644
>> index 0000000000..b57b9acde8
>> --- /dev/null
>> +++ b/docs/fusa/reqs/product-reqs/hypercall.rst
>> @@ -0,0 +1,20 @@
>> +.. SPDX-License-Identifier: CC-BY-4.0
>> +
>> +Error Return Value
>> +------------------
>> +
>> +`XenProd~hyp_err_ret_val~1`
>> +
>> +Description:
>> +In case the hypercall fails, Xen shall return one of the error codes defined
>> +in http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/errno.h.
> s/the/an/ hypercall otherwise it is not quite clear which hypercall you mean.
Ack
>
>> +
>> +Rationale:
>> +
>> +Comments:
>> +
>> +Covers:
>> + - `XenMkt~version_hypercall~1`
>> +
>> +Needs:
>> + - XenSwdgn
>> diff --git a/docs/fusa/reqs/product-reqs/version_hypercall.rst b/docs/fusa/reqs/product-reqs/version_hypercall.rst
>> index 400d51bbeb..2ef1c4f9ca 100644
>> --- a/docs/fusa/reqs/product-reqs/version_hypercall.rst
>> +++ b/docs/fusa/reqs/product-reqs/version_hypercall.rst
>> @@ -41,3 +41,86 @@ Covers:
>>
>> Needs:
>>   - XenSwdgn
>> +
>> +Version command
>> +---------------
>> +
>> +`XenProd~version_hyp_version_cmd~1`
>> +
>> +Description:
>> +Xen shall provide a command (num 0) for  hypercall (num 17) to retrieve Xen's
>> +version in the domain's register 0.
>> +
>> +Rationale:
>> +
>> +Comments:
>> +Xen version is composed of major and minor number.
> How Xen version is encoded should be a requirement, you can add this directly into
> the definition of this one in fact i think.

Do you mean the description should be :-

Description:

Xen shall provide a command (num 0) for  hypercall (num 17) to retrieve Xen's
version (composed of major and minor number) in the domain's register 0.

>
>> +
>> +Covers:
>> + - `XenMkt~version_hypercall~1`
>> +
>> +Needs:
>> + - XenSwdgn
>> +
>> +Extraversion command
>> +--------------------
>> +
>> +`XenProd~version_hyp_extraversion_cmd~1`
>> +
>> +Description:
>> +Xen shall provide a command (num 1) for hypercall (num 17) to copy its
>> +extraversion in the domain's buffer.
>> +
>> +Rationale:
>> +
>> +Comments:
>> +Xen's extra version consists of a string passed with 'XEN_VENDORVERSION' command
>> +line parameter while building Xen.
>> +
>> +Covers:
>> + - `XenMkt~version_hypercall~1`
>> +
>> +Needs:
>> + - XenSwdgn
>> +
>> +Capabilities command
>> +--------------------
>> +
>> +`XenProd~version_hyp_capabilities_cmd~1`
>> +
>> +Description:
>> +Xen shall provide a command (num 3) for hypercall (num 17) to copy its
>> +capabilities to the domain's buffer.
>> +
>> +Rationale:
>> +
>> +Comments:
>> +Capabilities related information is represented by char[1024].
>> +For Arm64, the capabilities should contain "xen-3.0-aarch64" string.
> Isn't it mandatory for xen to return aarch64 for arm64 ?
> This could be turned into a requirement (easily testable).

So should I change the following design requirement

"Xen shall have an internal constant string to denote that the cpu is 
running in arm64 mode."

to

"Xen shall return xen-3.0-aarch64 to denote that the cpu is running in 
arm64 mode."

>
>> +
>> +Covers:
>> + - `XenMkt~version_hypercall~1`
>> +
>> +Needs:
>> + - XenSwdgn
>> +
>> +Changeset command
>> +-----------------
>> +
>> +`XenProd~version_hyp_changeset_cmd~1`
>> +
>> +Description:
>> +Xen shall provide a command (num 4) for hypercall (num 17) to copy changeset
>> +to the domain's buffer.
>> +
>> +Rationale:
>> +
>> +Comments:
>> +Changeset is string denoting the date, time and git hash of the last change
>> +made to Xen's codebase.
> Does this has a standard format ? if so it should be explained.

This is a implementation level detail. The format is autogenerated in 
compile.h

"Mon Dec 30 22:00:31 2024 +0100 git:0d729221ab"

How do you want me explain this ?

- Ayan

>
>> +
>> +Covers:
>> + - `XenMkt~version_hypercall~1`
>> +
>> +Needs:
>> + - XenSwdgn
>> -- 
>> 2.25.1
>>
> Cheers
> Bertrand
>
>


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 16:17:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 16:17:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004672.1384388 (Exim 4.92)
	(envelope-from )
	id 1uMUKh-000815-JZ; Tue, 03 Jun 2025 16:17:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004672.1384388; Tue, 03 Jun 2025 16: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 1uMUKh-00080y-Go; Tue, 03 Jun 2025 16:17:47 +0000
Received: by outflank-mailman (input) for mailman id 1004672;
 Tue, 03 Jun 2025 16:17: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 1uMUKf-00080Z-GI
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 16:17:45 +0000
Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com
 [205.220.177.32]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 46f8d9d8-4096-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 18:17:43 +0200 (CEST)
Received: from pps.filterd (m0246630.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 553AElML028843;
 Tue, 3 Jun 2025 16:17:38 GMT
Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta02.appoci.oracle.com [147.154.18.20])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 471g8ga7g5-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Tue, 03 Jun 2025 16:17:38 +0000 (GMT)
Received: from pps.filterd
 (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2)
 with ESMTP id 553FIu3E030602; Tue, 3 Jun 2025 16:17:37 GMT
Received: from nam12-dm6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on2070.outbound.protection.outlook.com [40.107.243.70])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id
 46yr79m17v-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Tue, 03 Jun 2025 16:17:37 +0000
Received: from DS0PR10MB7224.namprd10.prod.outlook.com (2603:10b6:8:f5::14) by
 PH7PR10MB7695.namprd10.prod.outlook.com (2603:10b6:510:2e5::8) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8746.41; Tue, 3 Jun 2025 16:17:34 +0000
Received: from DS0PR10MB7224.namprd10.prod.outlook.com
 ([fe80::c57:383f:cfb2:47f8]) by DS0PR10MB7224.namprd10.prod.outlook.com
 ([fe80::c57:383f:cfb2:47f8%4]) with mapi id 15.20.8813.018; Tue, 3 Jun 2025
 16:17: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: 46f8d9d8-4096-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=
	corp-2025-04-25; bh=Bvz81MBFxNDPQYEaUfkbYf5tO+1avxRcX3L+dkWTGJw=; b=
	PgNdm6V6I8DOYRXfHwYirxLZA8sMxxQ8mNWuMyXqWkkvnltMliylsBe+zA0miaDm
	rhYybDM4dzJXNm6DwAre1cL+ZCp9vWo1lUuqAxcmY27KCoDHr8slUdNGQUZOM97U
	u6vTRn+eZFVAHUpmQ1tooxWB+5a0rnYs4UP/n/EwSOb2aE6DiQteMQh8Lt4NGoHI
	wO7YeZe3nc/y9ovH6peAEtvHM+t0X2LUIDZYFMUyfURrCcnrfcUCpkbCy9zVwWZu
	2q8Fe2ombqyRUmOyDKdtFFDKEtxsNamN0gJ93sBXfdhqWHa8nSsbO+QrbeL+QBbE
	9JmTW4p2EdpW8trfXDBdxg==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=qKQz2sNV1QvTJwsj7lUNz7dt+beIJ0TMjaDZa5Hx9cgqvdZuucO5yem8LjqnamD595bqRdHPZqbNNoe0DplIVsyE196gApp9H4NK5ieywUZnE2JcvXwm8nJDxka2JEscE7YNPYt28suJPs2hapjvgXFRRKohqIGxvVQ3Xcw9V1k4ixEgdZOru/hbeZIrtRTwVhuL0PxmS3h+6bhHIOzpIzmYQKnx93EaFwjIhyMDse0M9uFB39JIeaqXP7ByGm/GEX2oamBcR0lAbrvAihXVviDG6O+rfkdlik8Yvpmo5ghFE4iEYcRRjW5j7IyPXIulpkPv3N+6NWE7OezuVHA5Wg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Bvz81MBFxNDPQYEaUfkbYf5tO+1avxRcX3L+dkWTGJw=;
 b=qre0/3e84ghZpeGjNnAb6DuCR1yRsM2wOO/1qKRLprLNrHSyQPvgHmilmDGcVyGhcsK/IhJm/GDTp1aesdEGIQ4VwPw4k3NvijU1KWM+jJWRHByvamBXs5LVjUq1gPPMVTlTf1y3AWGRVfBVlW//6TPgd9lyaYygwBBdMI3YCqGoWLaN5+1ywbOPvbk7tqHsrcfbGA4IM0NUWNY3iNehKv6P3yaHXEl+p4KaktHPzHvXoKdsArCjmVUOTqubMKmKoRIhCTvANiQKKgUarKmwGQfuR/QhWs11v3QUkYndqu2ohrWVnRduBxdDkziIdoKC0wJkqGyzixHhZWxv+yt+hQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Bvz81MBFxNDPQYEaUfkbYf5tO+1avxRcX3L+dkWTGJw=;
 b=hP/yJcaLFPjOdDbZHj7gVOYOIQdsNnckJ+0QOx0AisI0Wtub6e8AY1eivAaZFkvJeqDx2b2Wx01iHo1D6+dIpsW46TeWlaimvEuWi0sWyMW4kI5N+inDEuHJiUhFIXZLzG9Xj7pjObOAi3iup3z1s8cB+39tq7DSVTuSKBbrmng=
Message-ID: <5792bec7-cd2f-4d27-aa3b-f417b07c8ea8@oracle.com>
Date: Tue, 3 Jun 2025 09:17:29 -0700
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 04/22] x86/boot/slaunch-early: implement early
 initialization
To: Sergii Dmytruk , xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
        Andrew Cooper
 ,
        =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 ,
        "Daniel P. Smith" ,
        trenchboot-devel@googlegroups.com
References: 
 <16a544876163afece619d50f80869aaacc9c797c.1748611041.git.sergii.dmytruk@3mdeb.com>
Content-Language: en-US
From: ross.philipson@oracle.com
In-Reply-To: <16a544876163afece619d50f80869aaacc9c797c.1748611041.git.sergii.dmytruk@3mdeb.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: BN9PR03CA0596.namprd03.prod.outlook.com
 (2603:10b6:408:10d::31) To DS0PR10MB7224.namprd10.prod.outlook.com
 (2603:10b6:8:f5::14)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS0PR10MB7224:EE_|PH7PR10MB7695:EE_
X-MS-Office365-Filtering-Correlation-Id: 85627626-9bb0-435f-fa71-08dda2ba2554
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?eG1MS2wwb3h3bnljaVVSZUhnTlVTU20wencxcFhpcnZsUHZvTmEwWUVWOWt3?=
 =?utf-8?B?bHlocUh1Vlh0aXBiS2VPWjYxWWRFemYxdzlCWTdGdGR1dC9tUFFITis3UElR?=
 =?utf-8?B?b0pYV2oxVHg5eXJtS2hVU1R1eVM3bG5nVFJwSlN2MTh5TUNwM0gwQXZ6YWd0?=
 =?utf-8?B?VlZ5Rno2YXRWYkRjdnBrSlpEMVJSazU2OEVyc2Y3anpDQXA5U0E3bi9wZCtS?=
 =?utf-8?B?WVVaWjVheUdISEFNTjVEeklyTSt5WEtaNmFYTEpySkpHdEFDckZZVE9ZVzQ0?=
 =?utf-8?B?YWMyVElCYUhZNTN5a1YvS0xiZHV5K25mOEVNa1pTM1NUaW8zbHRvQWxWdUI2?=
 =?utf-8?B?OTNWZ0F6bDBXeEwvMEFBMmNHbWp0VmIydXhBUzVtN1dxdWMzQ3BxUlA4UXFj?=
 =?utf-8?B?OTdhV3NUYkJyaWp1Q0dKUEhEaVNITTV4SmVYT1FBbEFLY3hWK3Ewd2U4VGVX?=
 =?utf-8?B?NUJPRTRkb29zQi8zSU1KMUJIQmhJNTNUQkJMd0lnRk5IdW5rV3QwaVlrVUcw?=
 =?utf-8?B?Yy9YYnRoOFpmTWpSTUVXM3A3NWlCbStwYUttM3VibkRsL1FyRzE2enlHeStX?=
 =?utf-8?B?REFEYnFsN0pYcHJFYzgwSnFWaElabkV2emdKaGVMemRjRUtWaDhxN0dsT0JZ?=
 =?utf-8?B?NlRQUFlOVllNaW9jU01iTmxWWStrazRERk5yY1A0MW1FTXFnWmpKbEtHQ0tY?=
 =?utf-8?B?aW9hSk1aY05DeXpFMGpRV1o2TDVHK1JWSTR3ckQ1NWpFYjF1aktZUUN3b2E4?=
 =?utf-8?B?VWp3bFN1WVg1YmwvUWxiVnZrWForMHRBZ2VtYmdqMDFWbmIwR2FjN2Uyb3M3?=
 =?utf-8?B?eW5mUmdBdzh3L1BlUmlmRnRScktJVFB6WjdPc3diNWpRci9TbXR3WXh5MlpH?=
 =?utf-8?B?VkZGeUJreGo4Wnp5RTBLblJPdzlZVHE5cXBNOHdIczJRYUFMMnR1Y09ILzJj?=
 =?utf-8?B?WlZCUHhWTEo0MWNzb1JFY3hEZ0l5eEVDM2U1OUVMNHRqUC9qN0t1WDkxUzVH?=
 =?utf-8?B?eTNYSDh6dDNDVE5RZ1F2d0pYSUkzUDZUNFozeUhmLyt4a2kzQjRibzFvNDJW?=
 =?utf-8?B?NG1qRUZIbS9pR1I1UUlUdkRNeVZ6TXVnd2FobmFwNUZheU9RTmVSU3ZNZFgz?=
 =?utf-8?B?L0JtN3lkVkdjL2NWQVVXR3NVc0hlRnNQS0FqZ1EvYWRNODBab3dQMFhNcCtk?=
 =?utf-8?B?SXlFak1LSUMvNVlLeDZxaFhEaUpSQ3p1dFFJV0l6YjFEWUFYTC9hNlNzS0xF?=
 =?utf-8?B?TzFnOW11MjJGM3Z0Tm0reEJNQ1lsSkRFVTJpeThLc2NLMXltL3ZQYWZrZFhY?=
 =?utf-8?B?NC8vMTZXWmdtZVRPYitqRWs4WFdFbXllQXcxWG9EMTNVUzVYaDhvcEx2MCtR?=
 =?utf-8?B?S2VjeDA0UjRUbk5kb2RvY3ZqcDVhdlZ2VzJzRTFZdnpzMWJEaTRPRHJKRTE3?=
 =?utf-8?B?N1o4YWdRQmRISGhqVWhrMEZqc0ovUXFkUTFFUVJlL1BTdS9xdmJqT2JTaVRu?=
 =?utf-8?B?Ly9FMkY0VjlJNWJyUUZmK2NRTTdOVG5rdlltNU1ST282SmdqZDJnL1d4ZUMw?=
 =?utf-8?B?MFhWU0U2UjY0M0tkOFA0WS9FajQ0bGVHNG9tVmg2QjR6R2NTQmNPUTF6Nksy?=
 =?utf-8?B?elBtT29wRDZ0eHhkcUpCdWd1cjNRemQ3dXljdTFZSG0ybmZOaTBaMW5kRlF0?=
 =?utf-8?B?M1lvVEo5cDkrZ25SNjFrUXhvUjNkQ2tVV2lnQkNOTWlaYjJNSU95b0dWRlhN?=
 =?utf-8?B?ZE5IamJyS1NvS1NXREp5dkpYckZ3VzF6TTJlNk85U0xhOGJRblpPWjRmUDIw?=
 =?utf-8?B?WVB6SUovWjFHNDBMaXRqM1BGa1ZLNDNyVDFBZEpFQTI3YllsekV6cnNIZkpT?=
 =?utf-8?B?bVRMSXcrYmNOVjVkMDdHd3I0UEJDU2YwRGVGSmh5b2FYNW5SRmxxdmpYL3FT?=
 =?utf-8?Q?CDKUH/lAQ2Y=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS0PR10MB7224.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?TmJ5YjkrMWJmWlVCaU03TUdtR0pFRFFjMnhOTGxGWm9LMTVBN3BDWFFmQnpV?=
 =?utf-8?B?V3lWV044MzZXdmpSUWY3K2ZvWVJNWi8zNU93dzlsa3Job0RZaTZMSnhpeEQ0?=
 =?utf-8?B?N1RPMEdyRVlNQjRkam5QQXF6dVduNFF6WTl0ZSszSzhTSzhJcWlHaElPQ2RL?=
 =?utf-8?B?SkNJaHpXT1ZXRkRzU3RrQ2pUWXVxaDdKQnV4MGJ0ZlJUdW5YcDYxTW14R2tB?=
 =?utf-8?B?Ni9xT1JKNXZ4NXFKdUpPZndNdnJqeUEvNDBjQS8zQ2xsRDh2bGJ4TCswYzQ2?=
 =?utf-8?B?ejEvRGpBdlhBWEkvZk0xZ2tRTVFwbzRWNVc2eFVLdDI2eDFxU0ZXM2FxajRu?=
 =?utf-8?B?bjBjUE04dUE3SHBRV0xGM1RQNTl4Qk1SZm1PWnIwZ3FPNkNnM3FRTHdiNHpL?=
 =?utf-8?B?cGZMWnFLSGNUbjliN01NTDdzalNaVmxvS0VTQS9hWVlRVXpUUXlYMTNObnRx?=
 =?utf-8?B?R3RKcE1oY21OZVVMemdzODBTVTM3dks1UjEvSVA2VmMxTkFMQW5QdSttV1di?=
 =?utf-8?B?V0lzalhLZHIvbU5FU0xoNEFRQmU0U2VrYWd3VEdQTDEyUWJ4T2NxTFhGSHkw?=
 =?utf-8?B?OGl5bUtGUWF5aDM4dkk2ZFVjOFc0WEt4Z0NPNHlxMlNmbnQycGRwWUJxR2U1?=
 =?utf-8?B?SXhHQ3A0dU9aWkFOR2d3UFZxRmRTSXE3VnE3eFB1T0IvUUdPcnJ0Kzl5QTlq?=
 =?utf-8?B?UWs1ME9SZW05UGRzdHZjdlVabk9aeTFXNlE0U3FDUGJyeHRjUjJGMHFUejky?=
 =?utf-8?B?L0xONHVSQUpsV29aOHJoNkVuejNDK0ROd2x4SGlrTEM4VnZHd2JvMEpqWlNq?=
 =?utf-8?B?TUVUeE8yQXlySjFmdTN0MTdmSzhiSTAvTEZGWVZKWDFhdGdoNHF6cXZlbUh5?=
 =?utf-8?B?Y0xCWm1GNTZGSW5IWnJPQ0FEMUVRN01xYnpnS3RrdzZVOU11K2VCZndtRVMv?=
 =?utf-8?B?ZWI2dStvcWI0bENPNWZVMWRGVkZJK21wOHRuOG9DZjI3end3aVQ5TmxVS25Q?=
 =?utf-8?B?S1RCc0JFcXNxSjB0dFloN1ZQWmVkVmtRRkRNY296TzV6OVRKbHUzNFc4TDNw?=
 =?utf-8?B?QjRaVHF6MFczMG1IRHkxQ2pUNk03aTFtcUV5Y2daVTlGVGo1SExxQkxZQ0JZ?=
 =?utf-8?B?S056NUErc0pkMlJLY0dldGl2RTdPV1VQV2o5emFkanNPVzE1TkNkdkw4dDlk?=
 =?utf-8?B?UHhVK01qY1JCL25DdUNXRWovL1NvaTRna29vMVloOFNJZTUrd29TUzFpN0lz?=
 =?utf-8?B?eW1Xc2ZvNVVqdkpPZjM2MHQ0WjF3Y3E0RnVpMzhmbUh4cXpVVXg4R2xCSVhB?=
 =?utf-8?B?aTlDdmtpY2VNS1RyL0RGd0Z5bllHYnBtSktFS1BFYmJrVjkxdG16MFVnR2dJ?=
 =?utf-8?B?cGhtWW9tNzl3YVJOUkFPS0RCM3ZSZHcvS1VFTUhZSWhwSi9sdC9IYnYvWGJ6?=
 =?utf-8?B?TTRLZWRtdmdyRHA0V0NYdzhJTThxV2M4UCszakJ5MWhSMVdrOVVWTGJkVzZm?=
 =?utf-8?B?SnR0SDJOTTF1b3I3V3QxdjRraUVqYlo3aU5aVjNRaXc5c1J5VTIvdnhnNS9a?=
 =?utf-8?B?ajVtc1NMa0diY2MySDNaRUVLRU1NQ3BFL3ZMQUtQTThGVUE4dUtLNmcvUHc0?=
 =?utf-8?B?WFdIZ0lGUFJvY0xtNkMyMzF2S1Bmb0w2Y3d6WlFyTE0zSzdKcFhkcWxjUTZF?=
 =?utf-8?B?NmFJV3JWSlNUVExoalFkRk5wSCt5Y0l3TVc3WldicmgwZEsvdlFpTUJoenlG?=
 =?utf-8?B?dWlYdFdXNEZKZTBGcVA4RmFQY05ySkpMcU9DUEcxU2htZDEzaFBSS0tzYmIw?=
 =?utf-8?B?U20rUkJPcitsWm9mRmZwaG94Z2dPR0h1MWxnL3pWN1V5UVNBUVNzQmkvb1py?=
 =?utf-8?B?L0pDNjNCUzBKRURKZ0tXMGRoT3BNWTV5MzdnaDV0NmgvUkw4Ym5HSUd1RnZX?=
 =?utf-8?B?dW9WMTgxazFoQWFyOHhIcVVTYi8vclFJdkgyVnR3Nm4rMkIzbXE2UnMwb1hm?=
 =?utf-8?B?OHpiREZ5Mk94Y20xdFlDQ2FXbzBoS09kaEpGR09PUHNOQkMxaTRwVVg5UFNV?=
 =?utf-8?B?V0FoT2pNVjdKK3NzelpGY2RZcnRUV2U3Yk5DVWNpYTNnTHpOUjZob253TkRO?=
 =?utf-8?B?L0xLaDBIdllGRUh5QlZXd1Vsd1IvdXFQRFdqd1JsYzhQR1QrOHRGRzlWdnha?=
 =?utf-8?B?TGc9PQ==?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	OleufUSMA1XO/3rtuhFyUPkjqMUt/7BwtpmaG1x0yuxq51J8N+A4+tkyVDzorqepmHYmSV7kcqVJNPE//TLDdlr48LPHtX58Q/Nk1k4YvjmQgqmUQRU307EReCmLcqxGfiaUUZbriIBf+jS4Aja/edDlGy6o9lby0u2abYMB9sbk0qEb8zWuxPsThL9asWo11Z5VzDFKVC1N4I1frGfAlIb7mK5261nm0G6jFmmQ9LPxBPmr7/Mvf9B1EQ0op5UZKQqRQ4WY/zkDnt1J80r4ffuVzTYCqXk7c7myy6JR9NKb4MRP3+f0iLjHXEWRBsdt164KamihJOk4iiy7OoRb4fMdExGRTaYxiVvRNP0C/+Kp2gOFBu1u3jk9X0qIuk55pFFjuqKruIJfM0/wrZfCS/FmgjuTQm5nvBL9M4NVjaLu01KHt4omh9B4vDG7HT/3wRJtK78v6febJPxxgfeCZ7Pbg9S1Szcp/NXH00nX0eUG3tPAtT4hmCDhkvFW3kQPUGd0lSgMaNZEQcaB9pvPhDU/s9cY8Xuw3kspL1q+hKm0E4P1lO5Zz/IHuuHeT7gCZljdJ7kvMjZcKsLcw9Fv6nWIAbq623+Iw5dpJjnlB40=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 85627626-9bb0-435f-fa71-08dda2ba2554
X-MS-Exchange-CrossTenant-AuthSource: DS0PR10MB7224.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jun 2025 16:17:33.3495
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: vp+WVr7sfHdChu8ZVs3qTywqCKEGXWNI5u8Dz6XrxN/tDn4a3y5nNYYBDwW651Gd86BKYSOuns35ngCyl2nCX1kev9PqISvm8qfu+g6wT7U=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR10MB7695
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40
 definitions=2025-06-03_01,2025-06-02_01,2025-03-28_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 malwarescore=0
 suspectscore=0 phishscore=0 adultscore=0 spamscore=0 mlxlogscore=999
 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2505160000 definitions=main-2506030141
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjAzMDE0MSBTYWx0ZWRfXwaYWXIqAmzMg LCI9fTeMfSY9KXCmCnl8cCf9mKZ8Gew9LQkQ7QmaOBa5EPwP38eEap0VOMQs2stvYcYumySc2cx 3/qkxe5Bi16rBRJlnmh/IjIyMXc44mDBC/lPiJ+5cOzIweGmC3xjDGACSl0AGiRaSErugXMJ0++
 gUHa2nPr9m5+lMhnGSjkxnbyDRfDZ2PhVU+SfYe0mIFTANiqWxEpq36/NuI2I8XoKcTxx2aIauM h9cByH+Rq41s3atQt4kr2zm6ULzennZD/tAayCtS4TE6sOppxhyJnrPqmsjlLgQsMXO81IgkwP0 6N6uRRYqR/8bLo2ZQ2qYJY7ZpiMk2qtJRTY0nNsrep3UT5/DheZEE0WQs8Q+Gs/MZw1WKpdifSZ
 jqTCZVlrN24bzcrb4Icz/FdANxxrj3rNQ3kWiR4sPcy8pmVSDmgV50u49Q+KUohve6yb99r3
X-Proofpoint-GUID: RoH5XLgP5PLOMhwntx6OBEZEyHaEUd07
X-Proofpoint-ORIG-GUID: RoH5XLgP5PLOMhwntx6OBEZEyHaEUd07
X-Authority-Analysis: v=2.4 cv=H5Tbw/Yi c=1 sm=1 tr=0 ts=683f2022 b=1 cx=c_pps a=e1sVV491RgrpLwSTMOnk8w==:117 a=e1sVV491RgrpLwSTMOnk8w==:17 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19
 a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=6IFa9wvqVegA:10 a=GoEa3M9JfhUA:10 a=C_d68mY_AAAA:8 a=ybf3h8MS243WDXt1rIEA:9 a=QEXdDO2ut3YA:10 a=wASdygnoxNaGnvDdgHrj:22 cc=ntf awl=host:14714

On 5/30/25 6:17 AM, Sergii Dmytruk wrote:
> Make head.S invoke a C function to retrieve MBI and SLRT addresses in a
> platform-specific way.  This is also the place to perform sanity checks
> of DRTM.
> 
> Signed-off-by: Krystian Hebel 
> Signed-off-by: Sergii Dmytruk 
> ---
>   xen/arch/x86/Makefile                |  1 +
>   xen/arch/x86/boot/Makefile           |  5 +++-
>   xen/arch/x86/boot/head.S             | 43 ++++++++++++++++++++++++++++
>   xen/arch/x86/boot/slaunch-early.c    | 41 ++++++++++++++++++++++++++
>   xen/arch/x86/include/asm/intel-txt.h | 16 +++++++++++
>   xen/arch/x86/include/asm/slaunch.h   | 26 +++++++++++++++++
>   xen/arch/x86/slaunch.c               | 27 +++++++++++++++++
>   7 files changed, 158 insertions(+), 1 deletion(-)
>   create mode 100644 xen/arch/x86/boot/slaunch-early.c
>   create mode 100644 xen/arch/x86/include/asm/slaunch.h
>   create mode 100644 xen/arch/x86/slaunch.c
> 
> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> index ce724a9daa..aa20eb42b5 100644
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -58,6 +58,7 @@ obj-$(CONFIG_COMPAT) += x86_64/physdev.o
>   obj-$(CONFIG_X86_PSR) += psr.o
>   obj-y += setup.o
>   obj-y += shutdown.o
> +obj-y += slaunch.o
>   obj-y += smp.o
>   obj-y += smpboot.o
>   obj-y += spec_ctrl.o
> diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
> index ff0d61d7ac..5471b966dd 100644
> --- a/xen/arch/x86/boot/Makefile
> +++ b/xen/arch/x86/boot/Makefile
> @@ -5,6 +5,7 @@ obj-bin-y += $(obj64)
>   obj32 := cmdline.32.o
>   obj32 += reloc.32.o
>   obj32 += reloc-trampoline.32.o
> +obj32 += slaunch-early.32.o
>   
>   obj64 := reloc-trampoline.o
>   
> @@ -28,6 +29,8 @@ $(obj32): XEN_CFLAGS := $(CFLAGS_x86_32) -fpic
>   $(obj)/%.32.o: $(src)/%.c FORCE
>   	$(call if_changed_rule,cc_o_c)
>   
> +$(obj)/slaunch-early.32.o: XEN_CFLAGS += -D__EARLY_SLAUNCH__
> +
>   orphan-handling-$(call ld-option,--orphan-handling=error) := --orphan-handling=error
>   LDFLAGS_DIRECT-$(call ld-option,--warn-rwx-segments) := --no-warn-rwx-segments
>   LDFLAGS_DIRECT += $(LDFLAGS_DIRECT-y)
> @@ -81,7 +84,7 @@ cmd_combine = \
>                 --bin1      $(obj)/built-in-32.base.bin \
>                 --bin2      $(obj)/built-in-32.offset.bin \
>                 --map       $(obj)/built-in-32.base.map \
> -              --exports   cmdline_parse_early,reloc,reloc_trampoline32 \
> +              --exports   cmdline_parse_early,reloc,reloc_trampoline32,slaunch_early_init \
>                 --output    $@
>   
>   targets += built-in-32.S
> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
> index a69107bd81..b4cf423c80 100644
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -472,6 +472,10 @@ __start:
>           /* Bootloaders may set multiboot{1,2}.mem_lower to a nonzero value. */
>           xor     %edx,%edx
>   
> +        /* Check for TrenchBoot slaunch bootloader. */
> +        cmp     $SLAUNCH_BOOTLOADER_MAGIC, %eax
> +        je      .Lslaunch_proto
> +
>           /* Check for Multiboot2 bootloader. */
>           cmp     $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
>           je      .Lmultiboot2_proto
> @@ -487,6 +491,45 @@ __start:
>           cmovnz  MB_mem_lower(%ebx),%edx
>           jmp     trampoline_bios_setup
>   
> +.Lslaunch_proto:
> +        /*
> +         * Upon reaching here, CPU state mostly matches the one setup by the
> +         * bootloader with ESP, ESI and EDX being clobbered above.
> +         */
> +
> +        /* Save information that TrenchBoot slaunch was used. */
> +        movb    $1, sym_esi(slaunch_active)
> +
> +        /*
> +         * Prepare space for output parameter of slaunch_early_init(), which is
> +         * a structure of two uint32_t fields.
> +         */
> +        sub     $8, %esp
> +
> +        push    %esp                             /* pointer to output structure */
> +        lea     sym_offs(__2M_rwdata_end), %ecx  /* end of target image */
> +        lea     sym_offs(_start), %edx           /* target base address */
> +        mov     %esi, %eax                       /* load base address */
> +        /*
> +         * slaunch_early_init(load/eax, tgt/edx, tgt_end/ecx, ret/stk) using
> +         * fastcall calling convention.
> +         */
> +        call    slaunch_early_init
> +        add     $4, %esp                         /* pop the fourth parameter */
> +
> +        /* Move outputs of slaunch_early_init() from stack into registers. */
> +        pop     %eax  /* physical MBI address */
> +        pop     %edx  /* physical SLRT address */
> +
> +        /* Save physical address of SLRT for C code. */
> +        mov     %edx, sym_esi(slaunch_slrt)
> +
> +        /* Store MBI address in EBX where MB2 code expects it. */
> +        mov     %eax, %ebx
> +
> +        /* Move magic number expected by Multiboot 2 to EAX and fall through. */
> +        movl    $MULTIBOOT2_BOOTLOADER_MAGIC, %eax
> +
>   .Lmultiboot2_proto:
>           /* Skip Multiboot2 information fixed part. */
>           lea     (MB2_fixed_sizeof+MULTIBOOT2_TAG_ALIGN-1)(%ebx),%ecx
> diff --git a/xen/arch/x86/boot/slaunch-early.c b/xen/arch/x86/boot/slaunch-early.c
> new file mode 100644
> index 0000000000..c9d364bcd5
> --- /dev/null
> +++ b/xen/arch/x86/boot/slaunch-early.c
> @@ -0,0 +1,41 @@
> +/*
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + *
> + * Copyright (c) 2022-2025 3mdeb Sp. z o.o. All rights reserved.
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +struct early_init_results
> +{
> +    uint32_t mbi_pa;
> +    uint32_t slrt_pa;
> +} __packed;
> +
> +void asmlinkage slaunch_early_init(uint32_t load_base_addr,
> +                                   uint32_t tgt_base_addr,
> +                                   uint32_t tgt_end_addr,
> +                                   struct early_init_results *result)
> +{
> +    void *txt_heap;
> +    const struct txt_os_mle_data *os_mle;
> +    const struct slr_table *slrt;
> +    const struct slr_entry_intel_info *intel_info;
> +
> +    txt_heap = txt_init();
> +    os_mle = txt_os_mle_data_start(txt_heap);
> +
> +    result->slrt_pa = os_mle->slrt;
> +    result->mbi_pa = 0;
> +
> +    slrt = (const struct slr_table *)(uintptr_t)os_mle->slrt;
> +
> +    intel_info = (const struct slr_entry_intel_info *)
> +        slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_INTEL_INFO);
> +    if ( intel_info == NULL || intel_info->hdr.size != sizeof(*intel_info) )
> +        return;

Since these are the x86/TXT bits, it seems at this point, not finding 
the TXT info structure would be fatal, no?

> +
> +    result->mbi_pa = intel_info->boot_params_base;
> +}
> diff --git a/xen/arch/x86/include/asm/intel-txt.h b/xen/arch/x86/include/asm/intel-txt.h
> index cc2d312f4d..7658457e9d 100644
> --- a/xen/arch/x86/include/asm/intel-txt.h
> +++ b/xen/arch/x86/include/asm/intel-txt.h
> @@ -292,6 +292,22 @@ static inline void *txt_sinit_mle_data_start(const void *heap)
>              sizeof(uint64_t);
>   }
>   
> +static inline void *txt_init(void)
> +{
> +    void *txt_heap;
> +
> +    /* Clear the TXT error register for a clean start of the day. */
> +    txt_write(TXTCR_ERRORCODE, 0);
> +
> +    txt_heap = _p(txt_read(TXTCR_HEAP_BASE));
> +
> +    if ( txt_os_mle_data_size(txt_heap) < sizeof(struct txt_os_mle_data) ||
> +         txt_os_sinit_data_size(txt_heap) < sizeof(struct txt_os_sinit_data) )
> +        txt_reset(SLAUNCH_ERROR_GENERIC);

I know the list of error codes pulled in are from the patches for Linux 
Secure Launch which seems right. The Xen work is free to add more 
specific error codes e.g. somewhere like here. We could even consider 
using regions in the vendor error code space for different things like 
generic errors vs architecture specific ones vs etc.

Thanks
Ross

> +
> +    return txt_heap;
> +}
> +
>   #endif /* __ASSEMBLY__ */
>   
>   #endif /* X86_INTEL_TXT_H */
> diff --git a/xen/arch/x86/include/asm/slaunch.h b/xen/arch/x86/include/asm/slaunch.h
> new file mode 100644
> index 0000000000..df42defd92
> --- /dev/null
> +++ b/xen/arch/x86/include/asm/slaunch.h
> @@ -0,0 +1,26 @@
> +/*
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + *
> + * Copyright (c) 2022-2025 3mdeb Sp. z o.o. All rights reserved.
> + */
> +
> +#ifndef X86_SLAUNCH_H
> +#define X86_SLAUNCH_H
> +
> +#include 
> +
> +/* Indicates an active Secure Launch boot. */
> +extern bool slaunch_active;
> +
> +/*
> + * Holds physical address of SLRT.  Use slaunch_get_slrt() to access SLRT
> + * instead of mapping where this points to.
> + */
> +extern uint32_t slaunch_slrt;
> +
> +/*
> + * Retrieves pointer to SLRT.  Checks table's validity and maps it as necessary.
> + */
> +struct slr_table *slaunch_get_slrt(void);
> +
> +#endif /* X86_SLAUNCH_H */
> diff --git a/xen/arch/x86/slaunch.c b/xen/arch/x86/slaunch.c
> new file mode 100644
> index 0000000000..a3e6ab8d71
> --- /dev/null
> +++ b/xen/arch/x86/slaunch.c
> @@ -0,0 +1,27 @@
> +/*
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + *
> + * Copyright (c) 2022-2025 3mdeb Sp. z o.o. All rights reserved.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * These variables are assigned to by the code near Xen's entry point.
> + *
> + * slaunch_active is not __initdata to allow checking for an active Secure
> + * Launch boot.
> + */
> +bool slaunch_active;
> +uint32_t __initdata slaunch_slrt; /* physical address */
> +
> +/* Using slaunch_active in head.S assumes it's a single byte in size, so enforce
> + * this assumption. */
> +static void __maybe_unused compile_time_checks(void)
> +{
> +    BUILD_BUG_ON(sizeof(slaunch_active) != 1);
> +}



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 16:23:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 16:23:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004683.1384397 (Exim 4.92)
	(envelope-from )
	id 1uMUQT-0001HP-9l; Tue, 03 Jun 2025 16:23:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004683.1384397; Tue, 03 Jun 2025 16: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 1uMUQT-0001HI-7J; Tue, 03 Jun 2025 16:23:45 +0000
Received: by outflank-mailman (input) for mailman id 1004683;
 Tue, 03 Jun 2025 16:23:43 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uMUQR-0001HC-TS
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 16:23:43 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uMUQR-000HNY-1l;
 Tue, 03 Jun 2025 16:23:43 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (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 1uMUQR-006SJG-26;
 Tue, 03 Jun 2025 16:23: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" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding:
	Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date;
	bh=Cwx6Rqps1LuDQSxWQKEUHa/luYpJWhqKmQTcwM4fePU=; b=qxiyRAFnCnLISIOVpNR+4sznVX
	CFQbc2rNEtndFhLdMN9E8HSdMpHU50+Tz58bDxN+LMd8qbb+kuB2jnF+JxOdZHEm6oN/sk3j982v7
	Gu/v9AUjEEFJZqdP/PBfr5LjhHmxSmk/lOJFkAOK9VJLaQlZKtjBbo/t6QzrD1IMw8N4=;
Date: Tue, 3 Jun 2025 18:23:41 +0200
From: Anthony PERARD 
To: Andrew Cooper 
Cc: xen-devel@lists.xenproject.org,
	Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= ,
	Anthony PERARD ,
	Doug Goldstein ,
	Stefano Stabellini 
Subject: Re: [XEN PATCH 8/9] CI: Workaround extra content in junit
Message-ID: 
References: <20250603124222.52057-1-anthony@xenproject.org>
 <20250603124222.52057-9-anthony@xenproject.org>
 <86d3655f-f541-441e-bb6c-1dda0b03540f@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <86d3655f-f541-441e-bb6c-1dda0b03540f@citrix.com>

On Tue, Jun 03, 2025 at 03:12:32PM +0100, Andrew Cooper wrote:
> On 03/06/2025 1:42 pm, Anthony PERARD wrote:
> >  if [ -n "$retrieve_xml" ]; then
> >      nc -w 10 "$SUT_ADDR" 8080 > tests-junit.xml  > +    # Workaround duplicated data been received
> > +    sed -i.old '/^<\/testsuites>/q' tests-junit.xml > /dev/null
> > +    extra_line_in_junit=$(($(wc -l < tests-junit.xml.old) - $(wc -l < tests-junit.xml)))
> > +    if [ $extra_line_in_junit -gt 0 ]; then
> > +        echo "WARNING: Found $extra_line_in_junit too many lines in junit."
> > +    fi
> 
> Is this the cause of
> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1849342222/test_report
> getting a row of 0's for ADL ?

Well, the error I had was this one:
"FATAL: Extra content at the end of the document"
https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1848598740/test_report

And indeed, when I managed to dl the junit.xml, there were the end of
the document duplicated many times.

> Why are we getting duplicate data? nc is running in TCP mode, not UDP,
> so it's not that.

I think Marek talked about some notwork equiment in the middle?
I managed to find in matrix where they were talk about this duplication
of data, well, with `nc` dl for ever, with lots of duplicated data:

https://matrix.to/#/!XcEgmbCouiNWHlGdHk:matrix.org/$OkZmPOandaPy_OVAU8hpoAs14JWHtI6rXYrIZawUqDE?via=matrix.org&via=nitro.chat&via=aperard.fr

from marmarek
> So, it appears to be a bug in pasta - the thing that podman uses to
> proxy traffic out of the container's network namespace. You know, an
> additional network stack in userspace.

I have no idea if it is the same issue, but I had extra content in the
junit file with nearly all my jobs.

Cheers,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 16:29:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 16:29:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004690.1384407 (Exim 4.92)
	(envelope-from )
	id 1uMUVy-0001uu-Sx; Tue, 03 Jun 2025 16:29:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004690.1384407; Tue, 03 Jun 2025 16:29: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 1uMUVy-0001un-Q8; Tue, 03 Jun 2025 16:29:26 +0000
Received: by outflank-mailman (input) for mailman id 1004690;
 Tue, 03 Jun 2025 16: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 1uMUVx-0001ug-GJ
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 16:29:25 +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 e859b0ba-4097-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 18:29:23 +0200 (CEST)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-451e24dfe1aso14803405e9.3
 for ; Tue, 03 Jun 2025 09:29:23 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a4f009ff7asm19032368f8f.90.2025.06.03.09.29.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 03 Jun 2025 09:29:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e859b0ba-4097-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748968162; x=1749572962; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=eOAGv+DXtkAwgB8ZfO5WdaLO/ElcOtPmyp2YWSWX+go=;
        b=JALqNNf2IpPu75lOdL4dkhXf5QRQ6ETURw72z3O20VBSPkUj3j0WYzgdw84uoMvmyE
         a/s8x9xQTmiLQGYKW0tgftM3qTqTfGsHHjoef19U08KJSETbFPFSKDwPPXSfvFSYVHKu
         XdiBo8FjQF5bXnOElkwG7G7FdGF3Rsxgfs3wE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748968162; x=1749572962;
        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=eOAGv+DXtkAwgB8ZfO5WdaLO/ElcOtPmyp2YWSWX+go=;
        b=SUOLxhj5/+3UrFmhUTStUtwGJS1TuVECyXq+tjsf8AGhN0PxIrsGe78GnRhcM+xvMF
         kUme0PtYnI4sgGzINhBnPxLEInACMXEQAbhDDkq4deSWvKl6FGwvyod3og+wL/i0QPs0
         +TBttpGNbaVjBz6+Yo6eZl5Svm5GulTytD7T+mQ1BE2l8GKD7E88X5xOGgSFOUehPJCL
         J1p5WI30PAOMTzLzzEpAieC46EJfreDAp9pFcLHjAmlrHd1PPQm0NntmtFPXGCyfdtcu
         ilgBj5irPF/pPtIYKshavCvp+K9yYJDOJa7rAaY0KhVj9A/cqDclsnCJUOG+9xuRW8JS
         thnw==
X-Forwarded-Encrypted: i=1; AJvYcCWhxX59DU1kiC1GAHavF3BSgOHw3tvohMvmzxATDkmpJs4LUYy5fKXA73eBVZVTCGvQf4QlytKweg4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YybKscjiXHltkUzivvXHcIR4US9fo/6KyXClsuy25cOogClWSl0
	MfgRZTpjbPyvrEgYgNY3o8GI40iDVPcK+HaxG9B13MnkGSQy0N9Tlz63dVaT9PMNRVc=
X-Gm-Gg: ASbGnctawVYsI+F/XD/iZMYNNI+E8dIIx8slGoX0pwn30+LAe+TmsMTPKuB0GnDYjVC
	PXvqEpqxqcHdwVoALjo6AE+y92AvrQq02wq5ADkOVCtKWKoYYBAN3Wr4fdWAiOlVZfDGD2qqr24
	IwvgF3IeyYJtWPJVWZLnmhKIZ2PF+cwME+YDoO5jIHdaXgXx/nMuRoBZj7pYASDZm8wHd/bankc
	xJwEX3UP5d27wQAMK2ov4JBRC3qACH5vxOdR+hOVl6yRdqotVX0cVwNALlrUHwhkug03vpP8U5x
	LuQ3AEL6kpcSdVYHMT+xBVJvDi9PNKZS50FPwFgbq7xt6q4dAkpBq8jWjhS+TLxuQPxwg1/gwvW
	VFbL1d2aaoRABgy9PjjhwGmoSvpw=
X-Google-Smtp-Source: AGHT+IFxCwsclOtFy9LTloapBe9cTt9eVIrLThmbZt9gil8qhmsEDj1UsVEMtN5xk9CU03voA40k3Q==
X-Received: by 2002:a05:600c:620f:b0:445:1984:2479 with SMTP id 5b1f17b1804b1-450d64bdccemr166185545e9.5.1748968162523;
        Tue, 03 Jun 2025 09:29:22 -0700 (PDT)
Message-ID: <32e3df0b-9ce2-4de7-9f48-d68aab8f2177@citrix.com>
Date: Tue, 3 Jun 2025 17:29:21 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/3] Add lockdown mode
To: Kevin Lampis , xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 Daniel Smith ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Jan Beulich 
References: <20250602134656.3836280-1-kevin.lampis@cloud.com>
 <20250602134656.3836280-3-kevin.lampis@cloud.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: <20250602134656.3836280-3-kevin.lampis@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 02/06/2025 2:46 pm, Kevin Lampis wrote:
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index 1f5cb67bd0..efeed5eafc 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 

As the only modification to setup.c, this hunk surely isn't in the right
patch.

> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index 0951d4c2f2..33cd669110 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -587,4 +587,12 @@ config BUDDY_ALLOCATOR_SIZE
>  	  Amount of memory reserved for the buddy allocator to serve Xen heap,
>  	  working alongside the colored one.
>  
> +config LOCKDOWN_DEFAULT
> +       bool "Enable lockdown mode by default"
> +       default n

default n is redundant.  Please drop it.

> +       help
> +         Lockdown mode prevents attacks from a rogue dom0 userspace from
> +         compromising the system. This is automatically enabled when Secure
> +         Boot is enabled.

It's more than just rogue dom0 userspace.  But, are we using lockdown
mode for anything more than just cmdline filtering?

> diff --git a/xen/common/kernel.c b/xen/common/kernel.c
> index 8b63ca55f1..7280da987d 100644
> --- a/xen/common/kernel.c
> +++ b/xen/common/kernel.c
> @@ -199,6 +200,8 @@ static int parse_params(const char *cmdline, const struct kernel_param *start,
>              printk("parameter \"%s\" unknown!\n", key);
>              final_rc = -EINVAL;
>          }
> +
> +        lockdown_clear_first_flag();

You're calling an __init function from a non-__init one.

I've submitted
https://lore.kernel.org/xen-devel/20250603125215.2716132-1-andrew.cooper3@citrix.com/T/#u
to fix it.

But honestly, given 3 function calls for trivial operations but with
complicated semantics, I'm not sure splitting out lockdown.c out of
kernel.c is a good move.

>      }
>  
>      return final_rc;
> @@ -216,6 +219,9 @@ static void __init _cmdline_parse(const char *cmdline)
>   */
>  void __init cmdline_parse(const char *cmdline)
>  {
> +    /* Call this early since it affects command-line parsing */
> +    lockdown_init(cmdline);
> +
>      if ( opt_builtin_cmdline[0] )
>      {
>          printk("Built-in command line: %s\n", opt_builtin_cmdline);

Even from just this hunk, the positioning looks suspicious.  Existing
UEFI-SB support in Xen relies on the builtin cmdline to provide
configuration, seeing as it ends up part of the signed whole.

Beyond that, I don't see what the fuss is over argument order.  The only
case where it matters is if Xen defaults to 0 and a user explicitly
wants to activate lockdown mode on the cmdline, at which point warning
them that their order of arguments was problematic is a) a problem in an
of itself, and b) unworkable when e.g. placeholder is in use.

> @@ -227,6 +233,7 @@ void __init cmdline_parse(const char *cmdline)
>          return;
>  
>      safe_strcpy(saved_cmdline, cmdline);
> +    lockdown_set_first_flag();
>      _cmdline_parse(cmdline);
>  #endif
>  }
> diff --git a/xen/common/lockdown.c b/xen/common/lockdown.c
> new file mode 100644
> index 0000000000..84eabe9c83
> --- /dev/null
> +++ b/xen/common/lockdown.c
> @@ -0,0 +1,54 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +
> +#include 
> +#include 
> +#include 
> +
> +#define FIRST_ARG_FLAG 2
> +
> +static int __ro_after_init lockdown = IS_ENABLED(CONFIG_LOCKDOWN_DEFAULT);
> +
> +void __init lockdown_set_first_flag(void)
> +{
> +    lockdown |= FIRST_ARG_FLAG;
> +}
> +
> +void __init lockdown_clear_first_flag(void)
> +{
> +    lockdown &= ~FIRST_ARG_FLAG;
> +}
> +
> +static int __init parse_lockdown_opt(const char *s)

You need a cf_check attribute too.  This only doesn't explode in XenRT
because it runs before activating CET, but it will fail in CI.

> +{
> +    if ( strncmp("no", s, 2) == 0 )
> +        if ( efi_secure_boot )
> +            printk("lockdown can't be disabled because Xen booted in Secure Boot mode\n");
> +        else
> +            lockdown = 0;

Braces please.  This is dangerously close to being a buggy expression.

> +    else
> +    {
> +        if ( !(lockdown & FIRST_ARG_FLAG) )
> +            printk("lockdown was not the first argument, unsafe arguments may have been already processed\n");
> +
> +        lockdown = 1;
> +    }
> +
> +    return 0;
> +}
> +custom_param("lockdown", parse_lockdown_opt);
> +
> +bool is_locked_down(void)
> +{
> +    return lockdown & ~FIRST_ARG_FLAG;
> +}
> +
> +void __init lockdown_init(const char *cmdline)
> +{
> +    if ( efi_secure_boot )
> +    {
> +        printk("Enabling lockdown mode because Secure Boot is enabled\n");
> +        lockdown = 1;
> +    }

This wants setting by init_secure_boot_mode().  Nothing good can come of
there being a window where efi_secure_boot is set but lockdown is not.

Why is there a cmdline parameter?  It doesn't appear to be used.

> +
> +    printk("Lockdown mode is %s\n", is_locked_down() ? "enabled" : "disabled");
> +}

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 16:39:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 16:39:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004697.1384418 (Exim 4.92)
	(envelope-from )
	id 1uMUfT-0003cW-OX; Tue, 03 Jun 2025 16:39:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004697.1384418; Tue, 03 Jun 2025 16:39: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 1uMUfT-0003cP-Ko; Tue, 03 Jun 2025 16:39:15 +0000
Received: by outflank-mailman (input) for mailman id 1004697;
 Tue, 03 Jun 2025 16:39:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uMUfS-0003cJ-33
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 16:39:14 +0000
Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com
 [2607:f8b0:4864:20::22e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 46dd8c80-4099-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 18:39:11 +0200 (CEST)
Received: by mail-oi1-x22e.google.com with SMTP id
 5614622812f47-4066a0d0256so3700926b6e.3
 for ; Tue, 03 Jun 2025 09:39:11 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 46dd8c80-4099-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748968750; x=1749573550; 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=Mz2eFOP4xXzeoBysviyy+w23/MgnulMoveTa63frXq8=;
        b=cZtT4y3pmssONVJNEd7tYXczK2GWN0bv5THMMXQoefG2Ts2niWY8Uzp21gV4f1Qji4
         /FlCkXZDpCZ5BQKKL+X2InvC7UTGIq0aQBvSpOWaVPLCbx1JghlXz7XWkk+3P/Ontsti
         PYRXZJZcl4U/zECv9V4wwCYGDlBmcFeWr6Lkw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748968750; x=1749573550;
        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=Mz2eFOP4xXzeoBysviyy+w23/MgnulMoveTa63frXq8=;
        b=YBjnXHC8tdeLdSNu6jxg8GcpxsgR/YiJVFmXR0HQl2nCQv0uUYQDZgl//G+vCx14F7
         uNOC3IKRA3n+w45B8Q94eetiecUxxbrH8FyLsqb7pR+5W1cL7/ISH3pAhto9cf0Y8Kob
         arQ36+0MEjVIHnMTleJikqDc5JMtzWVRTsOdjyEFbq53sDZK0BfU84tatnikFrviAiSB
         MCulKsvNSIFhBIPlkj26yU72veJZDiSJ8gn0VS53V7PHscdnFroszKhCrjDn4IBYx2LW
         FDAcIYMGy/HXrEycGbNOiQzQhKZlQa15qFpAq98oa2P67AQ1z0D29RFMee68QKUgkRru
         RPJQ==
X-Forwarded-Encrypted: i=1; AJvYcCUznIIlVE3gSQLw2hdgQH6D32StVw32MeWgbInFuctvzzb0hl43n2CwzqbisiFZRlypaAKdi24tejs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwPbLicCswiqf4NjYGwzovgM3+0cBNp12iz+E0vsw4xth2YE8iy
	VawkDIYINZkZNYOofYRtqQoLGJB7thC87ZDmMmZiMws+LP2CheboQfoOUYQoj5L8dkHL//koSmg
	Oo7OZthHwNQkBMFhwLZuTNYpNeHATWuGmtWQigLve
X-Gm-Gg: ASbGncuPIyWCfV/UE4QLA1+ahEv0fx5pBGLGfOxAvV1SY+17rFTvVAewHPC9bpXCREP
	pi61ZH4LgGDk4/AV4kg8VctNYMJfmI8McSfG3jm0dPOUN2s0LkS9Uk6dOs9URp/nzxw7EDv436d
	fYzAYvnXdVmgmIst9cmhjymWNUf5au5qc=
X-Google-Smtp-Source: AGHT+IEPsAUGln4BnpMpjKtCG5527JWb/M4eTwWfCaK+ZFEQVYQx88QlHY6wjQsxB4ZH1h/3Bx9/XO8mQ/En8HVU7Ms=
X-Received: by 2002:a05:6808:4484:b0:406:6bf5:cb61 with SMTP id
 5614622812f47-406796b4916mr12813186b6e.13.1748968750574; Tue, 03 Jun 2025
 09:39:10 -0700 (PDT)
MIME-Version: 1.0
References: <20250602134656.3836280-1-kevin.lampis@cloud.com>
 <20250602134656.3836280-3-kevin.lampis@cloud.com> <32e3df0b-9ce2-4de7-9f48-d68aab8f2177@citrix.com>
In-Reply-To: <32e3df0b-9ce2-4de7-9f48-d68aab8f2177@citrix.com>
From: Ross Lagerwall 
Date: Tue, 3 Jun 2025 17:38:58 +0100
X-Gm-Features: AX0GCFs9ZIcyBTnmGq-HGMuj8CnPPmUafTETz0F8bOYk0KMprCXBp2TtQx877Xc
Message-ID: 
Subject: Re: [PATCH v2 2/3] Add lockdown mode
To: Andrew Cooper 
Cc: Kevin Lampis , xen-devel@lists.xenproject.org, 
	=?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= , 
	Daniel Smith , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Jan Beulich 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 3, 2025 at 5:29=E2=80=AFPM Andrew Cooper  wrote:
>
> On 02/06/2025 2:46 pm, Kevin Lampis wrote:
> > diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> > index 1f5cb67bd0..efeed5eafc 100644
> > --- a/xen/arch/x86/setup.c
> > +++ b/xen/arch/x86/setup.c
> > @@ -15,6 +15,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
>
> As the only modification to setup.c, this hunk surely isn't in the right
> patch.
>
> > diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> > index 0951d4c2f2..33cd669110 100644
> > --- a/xen/common/Kconfig
> > +++ b/xen/common/Kconfig
> > @@ -587,4 +587,12 @@ config BUDDY_ALLOCATOR_SIZE
> >         Amount of memory reserved for the buddy allocator to serve Xen =
heap,
> >         working alongside the colored one.
> >
> > +config LOCKDOWN_DEFAULT
> > +       bool "Enable lockdown mode by default"
> > +       default n
>
> default n is redundant.  Please drop it.
>
> > +       help
> > +         Lockdown mode prevents attacks from a rogue dom0 userspace fr=
om
> > +         compromising the system. This is automatically enabled when S=
ecure
> > +         Boot is enabled.
>
> It's more than just rogue dom0 userspace.  But, are we using lockdown
> mode for anything more than just cmdline filtering?

Not as part of this series, but it is expected that lockdown mode will
eventually be tied into certain other functionality. E.g. requiring live
patches to be signed when it is enabled.

Ross


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 16:57:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 16:57:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004711.1384427 (Exim 4.92)
	(envelope-from )
	id 1uMUww-0006fa-5F; Tue, 03 Jun 2025 16:57:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004711.1384427; Tue, 03 Jun 2025 16:57: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 1uMUww-0006fT-2F; Tue, 03 Jun 2025 16:57:18 +0000
Received: by outflank-mailman (input) for mailman id 1004711;
 Tue, 03 Jun 2025 16:57:16 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uMUwu-0006fN-T3
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 16:57:16 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uMUwu-000IA1-2I
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 16:57:16 +0000
Received: from mail-qv1-f47.google.com ([209.85.219.47])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uMUwv-006uhk-0P
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 16:57:16 +0000
Received: by mail-qv1-f47.google.com with SMTP id
 6a1803df08f44-6fac7147cb8so114856576d6.1
 for ; Tue, 03 Jun 2025 09:57:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Type:Cc:To:Subject:Message-ID:
	Date:From:MIME-Version; bh=CEUWcAPHJA+IQYGOvV9m8IfwmlUWjF70Ql7nnAbQf0w=; b=v/
	+saA6HeXyHvfVJmQteLxtwmOpbHnBYpnQKm77q198hI5b8cxxFvRG07zmMFfYOiYnN2KUNKpxnhk0
	69ZqaWCrpTO6gCdO69dXHiszErIear0eJ1dtobjRQpOFzFQHJi+A40N1Lyug5kQ+bF119MB4wdb9X
	os/EUcLhb+0lNEQ=;
X-Gm-Message-State: AOJu0YwcBFLUxxSKl2xxfQRcGoHxxb9MiVR03I6RyJqB4Dls7/Jp5HpH
	XYod+XC7cztmxQbYnWKYyG49W8nUVcySwU50yjpjwROgPJVwFhwtoyjCZXwyueMLrSZdG3zBek4
	/IPDlMmJASNbDg/rfttOKx6N4uDRq8AE=
X-Google-Smtp-Source: AGHT+IGSX6uDlTtgDrRafX/bWlwCVPuNp6YD+HwCBaQRnJC3GuBB7jRR43xlUPaGjiEuPWADtrgY8EWvbJMBDiHTZJg=
X-Received: by 2002:a05:6122:3d0e:b0:52b:789:2d0 with SMTP id
 71dfb90a1353d-53084bdfd0cmr13570949e0c.5.1748969392025; Tue, 03 Jun 2025
 09:49:52 -0700 (PDT)
MIME-Version: 1.0
From: Cody Zuschlag 
Date: Tue, 3 Jun 2025 18:49:41 +0200
X-Gmail-Original-Message-ID: 
X-Gm-Features: AX0GCFsiuy6-heKlYCkOYatbbEjzocmXTcQYvkmlrVRkMpMec5fGUh0dg05g4RM
Message-ID: 
Subject: [ANNOUNCE] Call for agenda items for June 5, 2025 Xen Community Call
 @ 15:00 UTC
To: xen-devel@lists.xenproject.org
Cc: Tamas K Lengyel , "intel-xen@intel.com" , 
	"daniel.kiper@oracle.com" , Roger Pau Monne , 
	Christopher Clark , Rich Persaud , 
	Kevin Pearson , Juergen Gross , 
	Paul Durrant , Ji John , 
	"robin.randhawa@arm.com" , Artem Mygaiev , 
	Matt Spencer , Stewart Hildebrand , 
	Volodymyr Babchuk , Jeff Kubascik , 
	Stefano Stabellini , Julien Grall , 
	Rian Quinn , "Daniel P. Smith" , 
	=?UTF-8?B?4oCL4oCL4oCL4oCL4oCL4oCL4oCLRG91ZyBHb2xkc3RlaW4=?= , 
	George Dunlap , David Woodhouse , 
	=?UTF-8?B?4oCL4oCL4oCL4oCL4oCL4oCL4oCLQW1pdCBTaGFo?= , 
	=?UTF-8?B?4oCL4oCL4oCL4oCL4oCL4oCL4oCLVmFyYWQgR2F1dGFt?= , 
	Brian Woods , Robert Townley , 
	Bobby Eshleman , 
	=?UTF-8?B?4oCL4oCL4oCL4oCL4oCL4oCL4oCLQ29yZXkgTWlueWFyZA==?= , 
	Olivier Lambert , Andrew Cooper , 
	Ash Wilding , Rahul Singh , 
	=?UTF-8?Q?Piotr_Kr=C3=B3l?= , 
	Brendan Kerrigan , Thierry Laurion , 
	Oleksandr Andrushchenko , 
	Oleksandr Tyshchenko , Scott Davis , 
	Anthony PERARD , Michal Orzel , 
	Marc Ungeschikts , Zhiming Shen , 
	Xenia Ragiadakou , 
	=?UTF-8?B?4oCL4oCL4oCL4oCL4oCL4oCL4oCLSGVucnkgV2FuZw==?= , 
	Samuel Verschelde , Andrei Semenov , 
	Yann Dirson , Bernhard Kaindl , 
	=?UTF-8?B?4oCL4oCL4oCL4oCL4oCL4oCL4oCLTHVjYSBGYW5jZWxsdQ==?= , 
	=?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= , 
	Vikram Garhwal , Ayan Kumar Halder , 
	Kelly Choi , Thierry Escande , 
	Guillaume Thouvenin , 
	Andrei Cherechesu , =?UTF-8?B?UmFmYcOrbCBLb29p?= , 
	Mathieu Labourier , 
	Demi Marie Obenour , Cody Zuschlag , 
	Alejandro Vallejo 
Content-Type: multipart/alternative; boundary="00000000000055b8530636adabaf"

--00000000000055b8530636adabaf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi everyone,

We=E2=80=99re getting ready for June's Xen Project Community Call on *Thurs=
day, 5
June 2025* at *15:00 UTC* (4 pm UK time). We=E2=80=99d love for you to join=
. Feel
free to just observe or jump in! This call is a great opportunity to see
what the community is working on, align our various efforts, and share
updates. Everyone is welcome!

*Preparation:*

   - Add any proposed agenda items or missing action items:
   https://cryptpad.fr/pad/#/2/pad/edit/-I2PgZ1dBxBj1JlK07sQ77VM/
   - If any action items have been resolved or are no longer relevant, feel
   free to remove them from the doc.

*Call Details:*

   - *Date:* Thursday, 5 June 2025
   - *Time:* 15:00 UTC (agenda begins at 15:05 UTC)
      - Find your local timezone here
      
   - *Link to Join the Call:* https://meet.jit.si/XenProjectCommunityCall

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

*Want to be CC=E2=80=99d on future calls?*

Add or remove yourself from our Sign-up Sheet
.


See you next week!


Cody Zuschlag
Xen Project - Community Manager

--00000000000055b8530636adabaf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi everyone,
We=E2=80=99re get=
ting ready for June's Xen Project Community Call on=C2=A0Thursday, 5=
 June 2025=C2=A0at=C2=A015:00 UTC=C2=A0(4 pm UK time). We=E2=80=
=99d love for you to join. Feel free to just observe or jump in! This call =
is a great opportunity to see what the community is working on, align our v=
arious efforts, and share updates. Everyone is welcome!
Prep=
aration:
Call Details:=

=

We plan to open the meeting room at 15:00 UTC, but to allow time fo=
r switching between meetings and handling any technical issues, we=E2=80=99=
ll officially start discussing the agenda at 15:05 UTC.
Want to be=
 CC=E2=80=99d on future calls?
Add or remove yourself from=
 our=C2=A0Sign-up Sheet.
    See you nex=
t week!


    Cody Zus=
chlag
    Xen Project - Community Manager
    

--00000000000055b8530636adabaf--


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 17:04:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 17:04:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004722.1384438 (Exim 4.92)
	(envelope-from )
	id 1uMV3p-0008PB-VZ; Tue, 03 Jun 2025 17:04:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004722.1384438; Tue, 03 Jun 2025 17:04:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMV3p-0008P4-Sh; Tue, 03 Jun 2025 17:04:25 +0000
Received: by outflank-mailman (input) for mailman id 1004722;
 Tue, 03 Jun 2025 17:04: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 1uMV3o-0008Oy-Ss
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 17:04:25 +0000
Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com
 [205.220.177.32]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cbae3515-409c-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 19:04:23 +0200 (CEST)
Received: from pps.filterd (m0333520.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 553AEpSu009184;
 Tue, 3 Jun 2025 17:04:18 GMT
Received: from phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com
 (phxpaimrmta03.appoci.oracle.com [138.1.37.129])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 471gahac5a-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Tue, 03 Jun 2025 17:04:18 +0000 (GMT)
Received: from pps.filterd
 (phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1])
 by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (8.18.1.2/8.18.1.2)
 with ESMTP id 553Fc9xB034872; Tue, 3 Jun 2025 17:04:17 GMT
Received: from nam12-dm6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on2059.outbound.protection.outlook.com [40.107.243.59])
 by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id
 46yr79whu6-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Tue, 03 Jun 2025 17:04:16 +0000
Received: from DS0PR10MB7224.namprd10.prod.outlook.com (2603:10b6:8:f5::14) by
 SJ0PR10MB4461.namprd10.prod.outlook.com (2603:10b6:a03:2d8::15) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.41; Tue, 3 Jun
 2025 17:03:34 +0000
Received: from DS0PR10MB7224.namprd10.prod.outlook.com
 ([fe80::c57:383f:cfb2:47f8]) by DS0PR10MB7224.namprd10.prod.outlook.com
 ([fe80::c57:383f:cfb2:47f8%4]) with mapi id 15.20.8813.018; Tue, 3 Jun 2025
 17:03: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: cbae3515-409c-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=
	corp-2025-04-25; bh=iEr+24aXgFdbbB10KT8hbM5HxMuXX2wJFJsvwsazeyA=; b=
	PklZb3ID+X3ZTlAfTNbKvOmD+Us8fVtkLtKfOSCTs66ElBCvUoVwrE4KSme/C8Di
	XFZ0EtnDeHZKxbOurcOvcxC7pCdglXo39rRaUGgKc9yZD7bcBVpYk22o8lXWy5v6
	TuWmhWMcA1XydGuQJhK1R1Q48s1PC8S4Zvt+YBD1vf5WcJr09kAJPtej/acLtnHe
	N4W1Qo4NpAtAbct7y9EP5kL4uPnGnI1rmm37aMNGrXw4OnFlMdiTb6R7h6nq+Ube
	RhShyCgguIQQegOzp/JuTaedchkL0fM/Y36z6TqIjQdWqK8PqIDgAxwE0rlVCTdM
	dNgzRcxocWOpRN1q7Hg7mg==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=fvxVDTSMa04bB6h3ghl2lzV5RZVmIIVn+3NyV58Z8NEPjyZRaKvE07QjrlrTNqlA68CRCWsuk6jU+VPG22jd73ehW5okUWccEjBjibfyVhc/SDPCz8YJBTv/EYoz1duoMDQDKD+MmIY3y9Rs5Q+HTQ5f33+QviKavWx3ZTNQkM/hdC/LFIdilbI/u2prndHuOPL2ntiVc0Nly+aeUb9ZpGjsk4WfvHAjLo5yKS+qkzTfB05lOdLjqWfU8ov3WzSIH4VCJhqoirchhNn5VfMhJXqcfsZvtRlu3tW37aq3nKT/yfs6jUICWNOohB53A62pbtZTnjaNjzenrwdH3Z56eA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=iEr+24aXgFdbbB10KT8hbM5HxMuXX2wJFJsvwsazeyA=;
 b=PscygufRVCWVFROiSHAPFTpiUVqZMD9x2Rsg7KC74Kaj977T8ZvaSjDeOyF5496OHIDty6eD2/gJtobS2kwKTvVAempsBYtDp//SLyAbnkuni3BPa1wkPEAXNwXPGIc7E9y/H09yu9YipxhJzt0wOrO+Rf31ProX5HBwGx/boh1bsoJAnJjKAOYNnp3crijMGNWC68QjH6Sqt7SVlC+UXSnNtwAqluogULc4pJlgwDcj3ihMzZ/vz5mgf1FSu7oBtXL+WCddoaq+m0tF0X+H1shNvhhqf1N7TBDSjV2T18u0Bo0ixOA2VzBUeHVHlxALqH4Jejt/OYTgunQ2apVJbg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=iEr+24aXgFdbbB10KT8hbM5HxMuXX2wJFJsvwsazeyA=;
 b=QTdiLF85kVmJaqnp+49uvfhI4BhrShI8NKrLOV4eOZz+T/P959QXqP2eMEYqZS/bU3C7vBO7ZV9ieI/deZNI9s1aTYYUHmBe89KRg38KfgQ6WxaOZP/2xCgYVki97AMK1PzOjaLj8mfsQ9NQ9eaZC3L0ehN3CVdrb9H5QGq+EPs=
Message-ID: <4ff41a13-1af9-4c87-ad6b-cd616b4d1840@oracle.com>
Date: Tue, 3 Jun 2025 10:03:31 -0700
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 05/22] x86/boot/slaunch-early: early TXT checks and
 boot data retrieval
To: Sergii Dmytruk , xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
        Jan Beulich ,
        Andrew Cooper ,
        =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
        trenchboot-devel@googlegroups.com
References: 
 
Content-Language: en-US
From: ross.philipson@oracle.com
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: BN0PR04CA0052.namprd04.prod.outlook.com
 (2603:10b6:408:e8::27) To DS0PR10MB7224.namprd10.prod.outlook.com
 (2603:10b6:8:f5::14)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS0PR10MB7224:EE_|SJ0PR10MB4461:EE_
X-MS-Office365-Filtering-Correlation-Id: 362effc4-fb26-4423-0039-08dda2c09322
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?YTZ3TkpKUDVkTEphaldXMmFZbmllOFE4QmI5dEFwYzc5ZStGYWRDY0JvRHh3?=
 =?utf-8?B?cjhjUzB5NmxjY25xbmQ2ZGdwTExLRWlwemZNdlVoZWg5dCtnUHM5K3pETVhF?=
 =?utf-8?B?YjRtSkNRcGNETVVpR0VTaVBGZXArWTFZdXByVDl6ZEQxS0IzbXExRG40YU0w?=
 =?utf-8?B?RUkzY00wVXE2eTRwVTlud3dFRmh1NFp6MEhxN3U0Ly9pWHU3TGd4YVVMUVRa?=
 =?utf-8?B?VkpwTFR3T1FYb0FOVC9iV3VRc043KzdZcThnbXJ5b2twUEdMV3JSVDF2dFh0?=
 =?utf-8?B?R21FQ05ITGNQMCtET1V3UnJyNWpzY2lpN3M4NE5IYnVLMDlwRktlSVh3V0ow?=
 =?utf-8?B?Q1dudDRVZVdKckY1d3kzejBac3VMMVFJcWlES0IwZWRyZkFJam5KRnM4dmpJ?=
 =?utf-8?B?QnJlRjZ0TFVKbkJ2K2FGZ2hBZDhXSnhIWTFGTFBaU2ZXTmdZQXE1ODg2d1cv?=
 =?utf-8?B?TkhSeWw1STU5MWJYc1RabDNDUWYvMTNlWkMyY3RENHBGZkhXWDg5NWpVc3gz?=
 =?utf-8?B?K1M2M0dXMkFibVNvbURnYUR4NzZRbWJGSE5SWVdjL2l3MlNDYTd6V1F3WXFi?=
 =?utf-8?B?ZUxMSTFDTnVGZWh5OG9QODZISUw1M1c3TmlOTHNNRVNFaUIxdWRxY01sY0tH?=
 =?utf-8?B?T3BTQmpvVHJNRU5wd01JZ0VKWnJqSkVQUE9USVBxeE9JdWRzSU1BN3JvQVAy?=
 =?utf-8?B?NnNsT2lBMW1pQXNBUlo1SFcxRnBzM2xtbmZ1Q3NDVXZ4TytXNUhUODBXdkZH?=
 =?utf-8?B?dlIxc29hMlJNK2hvNnNZb0ZQYkFSdERMc2VJbDI3NVVWSkJxN1h3WVliRjBQ?=
 =?utf-8?B?Vk5hc1VGWTVNY1JIWFRJUkRvbDYya2xaQ1RYLzVWTjUxOWtoV3BuZkNPaGFV?=
 =?utf-8?B?dDJIdSs3d0crakhXakRtOERpRnFaRDVBZHhZazM4ZHBybU96YlVYS01LdGlp?=
 =?utf-8?B?TlozYWozTlNYc3gwSmMwemk0eE00TFFvMnFlbVNPRlpUMG1CbjRYUUd2anJ1?=
 =?utf-8?B?eW8zV0ZXMEpTZWYxR29RS1ovU09kNEdsNU5nMEdJQ1YyRkg4dlR3ZFI3SkFw?=
 =?utf-8?B?MzlvdDkyem1NYS9kWFlrS2duNE1IWTl4THh0ZFFRNUY4Y3J6YlcwbmYvQmhE?=
 =?utf-8?B?RS9KcFZDM3RwMXoxY0NxV3crelh3NVc3b0ZIRk5zVWxtM2I2WFV1Rm52UzBB?=
 =?utf-8?B?OUJhM3N5VG1zSjk1OGcxNG1QZERpNWtQNVFpK0dXWXMvRUVnTDdLYi9vMG14?=
 =?utf-8?B?bEF4V011dWRCMnNiNCs4eDZDUmJ3eHJPckljZGd4TitWS2svN2FHZzd6RFVM?=
 =?utf-8?B?UVZSOE8yQmE4bmhLdFRYdXk3cWhuMGpjS2lsTC94NXQya3pvWEt3ekp1Wktj?=
 =?utf-8?B?VEQ1anVtSUFPR2x3N3JvNDExdGkvd0pxQXRrN0RSWWlIcUxadlVRcmJ5Y1lG?=
 =?utf-8?B?TVdTWmtuZmZTZHh6eHFkWUJSTGx1SEt2V1QvZCs4enVkbW9MOUNneXNvNUYy?=
 =?utf-8?B?M1NCOWdMSnUvMkR2V3A0ckZialFaS0NmeEJKSTRrQzlqT0Qvbm13N1BIRGxy?=
 =?utf-8?B?cnRiVVo2bCtjL1lRb1ZEdGhCWWxIbGJyRWFQQ0hQUWhTOWJwWmV6bHJMOHdT?=
 =?utf-8?B?cENXRHFyYzZKR2hiNHBicHMweVd4bmVSeGlWWm40L0pXVzFzMlA1alJTQlhT?=
 =?utf-8?B?UVA1WTA0V1VreklaOEE3dVZKZy8yZXBCNGpsV0JRYlphWkphZ2Rsb25XNGs1?=
 =?utf-8?B?eExxUTZTV0sxUmQ5dlJYV0ZqNG4ySklRd0ZKOGo0Tm5rT1B0WThwcEZJbjZq?=
 =?utf-8?B?WFVLanpYQ2NHcTYxN3BvOG93WVhrOTdyK0xubTdGTDQ0dUgyUlZjdHlOKzZU?=
 =?utf-8?B?Zk0zWnZwQmhxTHNRdHZqbWxWUFA0dWI4Y2tURldqUjAxWmZIdTRJNkF2eXg2?=
 =?utf-8?Q?T+kjp6dvXNE=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS0PR10MB7224.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?dlJsVTU0dkxTZzVkUEQzT1NhMkljRVBqb3c4OCtoOTFBaVFuQmVNMzJWTXUz?=
 =?utf-8?B?S25kNjNQdUtRTTF0ZklTRkVSVWwrL2NDc2RHNzlQMkVrNU8vOFptYjJTZXk5?=
 =?utf-8?B?YXcrSC9qa2pzV3RjWGhDSFZhV01xNllFaXlFSTBESFlyV0xIaFI4bGI4Q0gy?=
 =?utf-8?B?MkhYK0ZhYWZXUW1pa1NOeUhaZVRzSVlpTVB5R3hnSXlPcm9NaVpqckZPN2NL?=
 =?utf-8?B?elJsK3d1eWlpTXdvdi9wek5QZ1p3a0ZjWUlabTRzQy9tcXQwRzJ0SHd4bGJJ?=
 =?utf-8?B?R3dGZlZkaDEyaVJQOGUvNmxubld1UGp4SkVWUjdaZDRlMzg5VmZhU2pKL01V?=
 =?utf-8?B?aW9CUW5PL3Bkcmk2Z1UzUi80eDlUWHEyWjlLT284NDl3anM1RWlzcldmdEJL?=
 =?utf-8?B?VGhDMFArZWEzQ0VWeUEzZGFOTUZzcWhXL0xScGFKRGhHUVd0VU1GdENmQk1F?=
 =?utf-8?B?dXpuTEVHRTEweHlGM016OUR1bEFEcmZJL3BxY1VBWWkzeDhWcWxrVFQxTmNI?=
 =?utf-8?B?TVZrRGJDejlsR2ZIZEtUamVFN3Q5dWFGUXRDclIvMXRFZzE1UHZSYnZMSS9V?=
 =?utf-8?B?N1liZElZNDVMVVo3WWl6K3VyV1dPL2JsSjRuN21rNGJxWkh6UzZQbVhpUlpU?=
 =?utf-8?B?WGlvcjVEaFBEQmpGemFLT2VvRWdHK0JITkFMNTFOODMxWHlUUmxtbEVsMlVU?=
 =?utf-8?B?Z3pTU3hKQTJPYUtIMjg3bm9xNSs5ZXdrTlJvLzJpWFZreVhKR0Y3YnRpVGtW?=
 =?utf-8?B?K2VCaEI1NFYwWFdYN3hCUzhVQ3NtQkNFbDN0ckFOcmQrampPWFNrWU1RV2pz?=
 =?utf-8?B?WVJvRE01V25YRnlWMnVFdzFzZ2xDbklYQTR5OXJzbjEvakRGbXk3cTUvaGV2?=
 =?utf-8?B?aVlDalZadUhDRVl3aDBEayt1c0dzQVlhMjVhRVlJZWcyQ0FRbnFXUlRwaHF5?=
 =?utf-8?B?NFpTTW0zMnZrTy9KVnVyN3hrczI1djMxZzRZRVpmRkg2YmJTUDhJd0pZOVhG?=
 =?utf-8?B?cWNhSCsrT2QwR2Rra1hWUXl3dHk4eFh4cG1CWFpyekI0THNaK1NZNm5udmZ4?=
 =?utf-8?B?VkVsVkRkUTkvYUJNU01hRWlXYTgxSE5DVkREUEJOOStlemFIRmk1bnhTV09I?=
 =?utf-8?B?SkoranAxeWo5Y3ZkM05qV2xuWG1zSVgvSmVLQ1BONXFwcyt2MHJ5ZHRNdzVF?=
 =?utf-8?B?YlAxdnNyY3RjbW11cVUzVEFOTkV1ZTBkNmlJMXZiYTFISFY1dkpVM2V1Mmx0?=
 =?utf-8?B?aTM2emRJNEVRVTNRNTk0V2R2eXFoZlFORmt1ck90N1h3b0c4TXpMTWQ0elht?=
 =?utf-8?B?VUFMRXZEcWFVUENvazlId2hvbFNTSFNUVXhnOVZ4ODZJcEF0MmJ3cjJmODJw?=
 =?utf-8?B?NGl0QUlWRlJmZi9nSERLTFZtSWdrRG5kdkFNK0NETGRCdnIza01ZQjlvaHVR?=
 =?utf-8?B?cndrQ2N3VTdPZ0RldnVtMDNSY0I1cGZuNU5PRTdGSHI5RDdXemtLMUdLemZx?=
 =?utf-8?B?WlFHdGpzNlBLYTlzcmZhUzI4ZjczczYrSXY5WXdzQ1ZiOEhMTGhTSHdNUTdP?=
 =?utf-8?B?YUdJektKS2xvM3ZzU0ZKZkY3Zy9kdzZzRWh2L3pUYm02ejlwOS9aYU5mWnJ0?=
 =?utf-8?B?MldLMG03ZnJYb3BXcHN1Y09UQjJ2SXI0d2Y3Lzc5dU81elk3TndXems1Mmdy?=
 =?utf-8?B?MnVOMlBmbEhCcFlHckVkRXdqYlFOKy85dHpGZk1PWGhtU28yakJ0U05PZVFn?=
 =?utf-8?B?Ry9CSHZ6RUVBcVRmL2UyYjZ4eFZrUWNpVnQ4L3FaQWJKQ2Y2ajVyUXV1Q0Nr?=
 =?utf-8?B?OW5iVnNDaGcvYVpDaWhya05yVDc0WVd6RUdWUlRNREY1eWMwWHVWcVdSN3Za?=
 =?utf-8?B?N3NFeG1nZ0hHQU1mV2x2bzVySnlIdmNQN050d0k0aytZVm1xNFlDcW00TkNo?=
 =?utf-8?B?cG5TbjlFTHUzQXVVUWdnS1BiYW1ybzZ2dDB4bURod0lQc3NHVi9DZnAwL2t5?=
 =?utf-8?B?ajloYmJPa2N0NHdoL2pqb0NiT0JNbGdScFVuYWVZKzlHdDZ5dXYrTU8zd3Bm?=
 =?utf-8?B?QXJVVk9VUkZ3K1R3U2NtK1ViWGRhbHB4djQwTjQrU2t1T0lscDN2QTFCOUpB?=
 =?utf-8?B?MDVkdDJBMlhZTlZJeEU4dFlDSEVjdDN2b2xpMkNmNVJ5N201MWdFekNPdmtK?=
 =?utf-8?B?M2c9PQ==?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	0C1VkevhZVH6/Xks/QXz8bYKyaYRHXP9IqvBnKs86uXpNXdEyQ6692O/qEATUqVFxcIMNGHSefBDQdReOpd3u4NaEtqj8fEibDk9cLp9/K6jXi2Zp6WmnGA962ND3s21pzwmHPUjU1Fw1EOe3I5QWoMAf6SPiuNod7n1pAG1QBez2NYBEPyKvTrkERLukxNSsXyNmy/F2vjczwsm9gNcN8hj/BJdtdNbiyKEh2dLjQuRhakIYOHwwny+0bsJ/y10Zc1lKptJnQp6lNomO2to8ZyYCdfMYZGYdf3shW0mSj2G3S5KFQ8dgO7r8vXg7T7iyThfxbRgKYReFCVlOUtTP198UW6GM4IuEAtom92r3Sst+C/27AdmHF0sSRfgyJx/5iPMVSJG8BULXHQ3UeP98y/lJIk3eumsGVjZwtKU1GtZk3w5bYnveE1NzhJKVN+ako+OJDflTvwNDWJZVLLYD+8noFgIPijm4WIofsiUq5gNetxJ4FTQV0SnJpqlJhZRqfUfcthLfBpfsTp2aA3SxZCRhBZ2G9pQpGvLYPeoamZ0pYiVXQbzN3adqDhrmKhtWwX+OvPDecSazlftKduCo5Xsvf34uBjuLbHDz64fZ3A=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 362effc4-fb26-4423-0039-08dda2c09322
X-MS-Exchange-CrossTenant-AuthSource: DS0PR10MB7224.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jun 2025 17:03:34.4212
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Cvbhl1iRz51kwMQoEZezJXiCschc7Rh0cHGnGzxnIhMK03SRHRxqerx/z5hL1OjJVJDkN73QD3ULyBM0BM7yAneZ16Uz3IJchrMOM8XwHtk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR10MB4461
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40
 definitions=2025-06-03_02,2025-06-02_01,2025-03-28_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxlogscore=999
 bulkscore=0 spamscore=0 suspectscore=0 malwarescore=0 mlxscore=0
 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2505160000 definitions=main-2506030149
X-Authority-Analysis: v=2.4 cv=aqqyCTZV c=1 sm=1 tr=0 ts=683f2b12 b=1 cx=c_pps a=WeWmnZmh0fydH62SvGsd2A==:117 a=WeWmnZmh0fydH62SvGsd2A==:17 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19
 a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=6IFa9wvqVegA:10 a=GoEa3M9JfhUA:10 a=C_d68mY_AAAA:8 a=1LLuQrjauJPoW5hFOboA:9 a=QEXdDO2ut3YA:10 a=wASdygnoxNaGnvDdgHrj:22
X-Proofpoint-GUID: QzQpXWojv_vT1-lncHvqD9Tj5t-9cENs
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjAzMDE0OSBTYWx0ZWRfXwKX0pfKcXx7K X7pQOKt8lWVyous+52XV9T43tRyc+lVkj7ZNwMMv2ndc4cw140jIHNWeoiPrgqbNerayUk0RPw7 nRuhztQbVuE2n2Rz/02IYLHYAdNfFyi7yLH1nd02AyZNTtxzhKQ5UeSl9A0n2ACyW1Q526bs8na
 rSqdWEdmTihDnvV+GMhYnp0cdDTH24xVzYR6/SRAUPJSdxlAOfDIyIAbU8eRqybGYcCKM2UMI5Q 0QIC5OuptYLHrdtQz67+CYN45BF5UPL1Wc3hWGM64Qdu79VLGPXel68phKW3wzhd4s8AwlWvCpv 1fkhQOF3B6wG3KIjcXe+7oibBc9932ov6RUtbbZe/y81eAhXYZL+aAjlbeHPFCijyh2PjEpZk8P
 IBZ5SDpupxwgxfYA3ADp1f0QIof2MMeWYMeKNvPhqw1i3lE3VKSbL/CjUfCUgykiKGile6Js
X-Proofpoint-ORIG-GUID: QzQpXWojv_vT1-lncHvqD9Tj5t-9cENs

On 5/30/25 6:17 AM, Sergii Dmytruk wrote:
> From: Krystian Hebel 
> 
> The tests validate that important parts of memory are protected against
> DMA attacks, including Xen and MBI. Modules can be tested later, when it
> is possible to report issues to a user before invoking TXT reset.
> 
> TPM event log validation is temporarily disabled due to an issue with
> its allocation by bootloader (GRUB) which will need to be modified to
> address this. Ultimately event log will also have to be validated early
> as it is used immediately after these tests to hold MBI measurements.
> See larger comment in txt_verify_pmr_ranges().
> 
> Signed-off-by: Krystian Hebel 
> Signed-off-by: Sergii Dmytruk 
> ---
>   xen/arch/x86/boot/slaunch-early.c    |   6 ++
>   xen/arch/x86/include/asm/intel-txt.h | 112 +++++++++++++++++++++++++++
>   2 files changed, 118 insertions(+)
> 
> diff --git a/xen/arch/x86/boot/slaunch-early.c b/xen/arch/x86/boot/slaunch-early.c
> index c9d364bcd5..662144e42f 100644
> --- a/xen/arch/x86/boot/slaunch-early.c
> +++ b/xen/arch/x86/boot/slaunch-early.c
> @@ -22,10 +22,13 @@ void asmlinkage slaunch_early_init(uint32_t load_base_addr,
>       void *txt_heap;
>       const struct txt_os_mle_data *os_mle;
>       const struct slr_table *slrt;
> +    const struct txt_os_sinit_data *os_sinit;
>       const struct slr_entry_intel_info *intel_info;
> +    uint32_t size = tgt_end_addr - tgt_base_addr;
>   
>       txt_heap = txt_init();
>       os_mle = txt_os_mle_data_start(txt_heap);
> +    os_sinit = txt_os_sinit_data_start(txt_heap);
>   
>       result->slrt_pa = os_mle->slrt;
>       result->mbi_pa = 0;
> @@ -38,4 +41,7 @@ void asmlinkage slaunch_early_init(uint32_t load_base_addr,
>           return;
>   
>       result->mbi_pa = intel_info->boot_params_base;
> +
> +    txt_verify_pmr_ranges(os_mle, os_sinit, intel_info,
> +                          load_base_addr, tgt_base_addr, size);
>   }
> diff --git a/xen/arch/x86/include/asm/intel-txt.h b/xen/arch/x86/include/asm/intel-txt.h
> index 7658457e9d..122b4293ea 100644
> --- a/xen/arch/x86/include/asm/intel-txt.h
> +++ b/xen/arch/x86/include/asm/intel-txt.h
> @@ -93,6 +93,8 @@
>   
>   #ifndef __ASSEMBLY__
>   
> +#include 
> +
>   /* Need to differentiate between pre- and post paging enabled. */
>   #ifdef __EARLY_SLAUNCH__
>   #include 
> @@ -308,6 +310,116 @@ static inline void *txt_init(void)
>       return txt_heap;
>   }
>   
> +static inline int is_in_pmr(const struct txt_os_sinit_data *os_sinit,
> +                            uint64_t base, uint32_t size, int check_high)

bool return val?

> +{
> +    /* Check for size overflow. */
> +    if ( base + size < base )
> +        txt_reset(SLAUNCH_ERROR_INTEGER_OVERFLOW);
> +
> +    /* Low range always starts at 0, so its size is also end address. */
> +    if ( base >= os_sinit->vtd_pmr_lo_base &&
> +         base + size <= os_sinit->vtd_pmr_lo_size )
> +        return 1;
> +
> +    if ( check_high && os_sinit->vtd_pmr_hi_size != 0 )
> +    {
> +        if ( os_sinit->vtd_pmr_hi_base + os_sinit->vtd_pmr_hi_size <
> +             os_sinit->vtd_pmr_hi_size )
> +            txt_reset(SLAUNCH_ERROR_INTEGER_OVERFLOW);
> +        if ( base >= os_sinit->vtd_pmr_hi_base &&
> +             base + size <= os_sinit->vtd_pmr_hi_base +
> +                            os_sinit->vtd_pmr_hi_size )
> +            return 1;
> +    }
> +
> +    return 0;
> +}
> +
> +static inline void txt_verify_pmr_ranges(
> +    const struct txt_os_mle_data *os_mle,
> +    const struct txt_os_sinit_data *os_sinit,
> +    const struct slr_entry_intel_info *info,
> +    uint32_t load_base_addr,
> +    uint32_t tgt_base_addr,
> +    uint32_t xen_size)
> +{
> +    int check_high_pmr = 0;
> +
> +    /* Verify the value of the low PMR base. It should always be 0. */
> +    if ( os_sinit->vtd_pmr_lo_base != 0 )
> +        txt_reset(SLAUNCH_ERROR_LO_PMR_BASE);
> +
> +    /*
> +     * Low PMR size should not be 0 on current platforms. There is an ongoing
> +     * transition to TPR-based DMA protection instead of PMR-based; this is not
> +     * yet supported by the code.
> +     */
> +    if ( os_sinit->vtd_pmr_lo_size == 0 )
> +        txt_reset(SLAUNCH_ERROR_LO_PMR_SIZE);
> +
> +    /* Check if regions overlap. Treat regions with no hole between as error. */
> +    if ( os_sinit->vtd_pmr_hi_size != 0 &&
> +         os_sinit->vtd_pmr_hi_base <= os_sinit->vtd_pmr_lo_size )
> +        txt_reset(SLAUNCH_ERROR_HI_PMR_BASE);
> +
> +    /* All regions accessed by 32b code must be below 4G. */
> +    if ( os_sinit->vtd_pmr_hi_base + os_sinit->vtd_pmr_hi_size <=
> +         0x100000000ULL )
> +        check_high_pmr = 1;
> +
> +    /*
> +     * ACM checks that TXT heap and MLE memory is protected against DMA. We have
> +     * to check if MBI and whole Xen memory is protected. The latter is done in
> +     * case bootloader failed to set whole image as MLE and to make sure that
> +     * both pre- and post-relocation code is protected.
> +     */
> +

Is this the full list of entities that should be covered by PMRs? I am 
thinking of entries in the SLR policy that should be covered. E.g. with 
Linux we ensure setup_data entry blobs are covered before measuring.

> +    /* Check if all of Xen before relocation is covered by PMR. */
> +    if ( !is_in_pmr(os_sinit, load_base_addr, xen_size, check_high_pmr) )
> +        txt_reset(SLAUNCH_ERROR_LO_PMR_MLE);
> +
> +    /* Check if all of Xen after relocation is covered by PMR. */
> +    if ( load_base_addr != tgt_base_addr &&
> +         !is_in_pmr(os_sinit, tgt_base_addr, xen_size, check_high_pmr) )
> +        txt_reset(SLAUNCH_ERROR_LO_PMR_MLE);
> +
> +    /*
> +     * If present, check that MBI is covered by PMR. MBI starts with 'uint32_t
> +     * total_size'.
> +     */
> +    if ( info->boot_params_base != 0 &&
> +         !is_in_pmr(os_sinit, info->boot_params_base,
> +                    *(uint32_t *)(uintptr_t)info->boot_params_base,
> +                    check_high_pmr) )
> +        txt_reset(SLAUNCH_ERROR_BUFFER_BEYOND_PMR);
> +
> +    /* Check if TPM event log (if present) is covered by PMR. */
> +    /*
> +     * FIXME: currently commented out as GRUB allocates it in a hole between
> +     * PMR and reserved RAM, due to 2MB resolution of PMR. There are no other
> +     * easy-to-use DMA protection mechanisms that would allow to protect that
> +     * part of memory. TPR (TXT DMA Protection Range) gives 1MB resolution, but
> +     * it still wouldn't be enough.
> +     *
> +     * One possible solution would be for GRUB to allocate log at lower address,
> +     * but this would further increase memory space fragmentation. Another
> +     * option is to align PMR up instead of down, making PMR cover part of
> +     * reserved region, but it is unclear what the consequences may be.

The consequences depend on the firmware. The failure mode we used to see 
was on some systems if the PMR covered certain areas marked as reserved, 
the system will hang at boot. In this particular case, firmware was 
trying to use an xHCI controller to get to the kb attached to use it at 
boot time. When DMA to the host controller was blocked, the firmware was 
unhappy. We have not seen this issue in a while and the current logic in 
the prologue code just sets the upper bound to the highest RAM area 
below 4Gb which is optimal.

The most correct solution for PMRs is to read the VTd RMRR structures. 
These can tell you what reserved regions should not be blocked like this 
(if any). This will give more control over the best configuration for 
the PMRs and what to avoid. This needs to be done in the prologue code 
and validated in the DLME.

And yea, TPR support too where available.

Thanks
Ross

> +     *
> +     * In tboot this issue was resolved by reserving leftover chunks of memory
> +     * in e820 and/or UEFI memory map. This is also a valid solution, but would
> +     * require more changes to GRUB than the ones listed above, as event log is
> +     * allocated much earlier than PMRs.
> +     */
> +    /*
> +    if ( os_mle->evtlog_addr != 0 && os_mle->evtlog_size != 0 &&
> +         !is_in_pmr(os_sinit, os_mle->evtlog_addr, os_mle->evtlog_size,
> +                    check_high_pmr) )
> +        txt_reset(SLAUNCH_ERROR_BUFFER_BEYOND_PMR);
> +    */
> +}
> +
>   #endif /* __ASSEMBLY__ */
>   
>   #endif /* X86_INTEL_TXT_H */



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 17:13:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 17:13:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004729.1384449 (Exim 4.92)
	(envelope-from )
	id 1uMVCm-0001gZ-RK; Tue, 03 Jun 2025 17:13:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004729.1384449; Tue, 03 Jun 2025 17: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 1uMVCm-0001gS-NM; Tue, 03 Jun 2025 17:13:40 +0000
Received: by outflank-mailman (input) for mailman id 1004729;
 Tue, 03 Jun 2025 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 1uMVCm-0001gM-1d
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 17:13:40 +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 157342de-409e-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 19:13:35 +0200 (CEST)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-ad89f9bb725so1174831866b.2
 for ; Tue, 03 Jun 2025 10:13:35 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ada5e2befaesm995164666b.104.2025.06.03.10.13.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 03 Jun 2025 10:13:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 157342de-409e-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748970815; x=1749575615; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=fgAdH6z/B6I/QpF7fBowdts0/hFtO2fb+8/ioZpDhJo=;
        b=ArJ/z4V4dDVMtCPxQyHdh4hI5wqO9CJrGuQ2tCd6SpZue+HtZLabkABukCesfXG3EE
         uKzD8SaOvUtTL8h1w6pAgAKflDq1kLm0beLGctpr492mJ3Fe0UN6ALDSUlGX/tQiSZAM
         L+mzOFy4heAjh1M+osmqc7RrVk0zLqHnsvUcA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748970815; x=1749575615;
        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=fgAdH6z/B6I/QpF7fBowdts0/hFtO2fb+8/ioZpDhJo=;
        b=CeHhaK5/oHZjI1Y2iVdGkaUyn2wrBU6TxPJyRZmCF6MH9N33slSJGWJvZUPXuiAYKc
         5FjExdcwfFZZjcSkRXNtM3LKUb5iqiaE7MdwxxgH1vnrrHnxSV8fmnWWCPBHjVtzw71J
         gGtd8l7dIuoHc4jyWlCmBtPSh2iE2rr80+r5c4kdv/wWAs6E4hVg3RMooEEGHKk+Hky0
         i1nZV/XXgMtCacRBxRoGKLv/Y6jDPuahjRKDo9Wq7wwHi3BagRKVtUYfJmb/OmRGfidP
         PsgPbx5p/ZD7065ITcmk5Svlqv1F7IyUBkYaOi+L48k12PZXBMcVjA4TQkwFvTb5fiTP
         +3yw==
X-Gm-Message-State: AOJu0YzvZ4zfWkzfGQZk/R7o9/0nM8ZtLfTGEgwrQBXSHvG1i4EHITfg
	siOY0KDjj5AMVLpdd9StHyvGr+W0Hyy/hPgt9zAQBvS8M/DVJcj5svyMjNq5422n544=
X-Gm-Gg: ASbGncuPum9VQ6MARTm1YzND7qOHWfKp/MPG1kGNq+PuPGgYNH455/lphATdVioCRsN
	m2urZ/FGOsXJ2cA2gv9TrlwOFAKsTbXjGjpOfasbsWnHIihGmGJfcNPxFueuX552WTfUKyNnNIQ
	K1eHqM5B6CSK8mDxdt1TQ7q6EU9rl+dpHP4GMu3nFDFLtiljNOlkyFIZFZYuryC1f9/rYHNA2pi
	ygxFhQQ2Oo+2DyFR+3YicnTdAQmuZjkaYA0f93hJ7H+eZxpo0AnZO0V3eVuosS/MCs6HY2u4pQH
	5DcDD0W4Kt3YS2lIeUsG77qe26sqjna9XwQBgZ9t7eZJKDtzbJenxrZHNZ+Vvm9F4XVKxVnXuUQ
	2/B2PWFCmcsria7+O
X-Google-Smtp-Source: AGHT+IFwYO0C5AbbIbylKNhqlfdmNNZCInj6oz7DJIvhVa++O9eKAUIitnEMwGTtHockAgP5Hj2IJg==
X-Received: by 2002:a17:907:971c:b0:adb:2ef9:db38 with SMTP id a640c23a62f3a-adb36be2060mr1697004966b.36.1748970815044;
        Tue, 03 Jun 2025 10:13:35 -0700 (PDT)
Message-ID: <70df2eac-0b82-4f9f-9235-95d42e412e82@citrix.com>
Date: Tue, 3 Jun 2025 18:13:32 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 5/9] CI: Have the gitlab job fail on tools/tests
 failure
To: Anthony PERARD 
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , Anthony PERARD
 , Doug Goldstein ,
 Stefano Stabellini 
References: <20250603124222.52057-1-anthony@xenproject.org>
 <20250603124222.52057-6-anthony@xenproject.org>
  
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/06/2025 4:58 pm, Anthony PERARD wrote:
> On Tue, Jun 03, 2025 at 02:41:50PM +0100, Andrew Cooper wrote:
>> On 03/06/2025 1:42 pm, Anthony PERARD wrote:
>>>  if [ -n "$retrieve_xml" ]; then
>>>      nc -w 10 "$SUT_ADDR" 8080 > tests-junit.xml >> +    # Findout if one of the test failed
>>> +    if ! grep -q '' tests-junit.xml; then
>>> +        echo "ERROR: tests-junit.xml is incomplete or missing."
>>> +        TEST_RESULT=1
>>> +    elif grep -q '' tests-junit.xml; then
>>> +        TEST_RESULT=1
>>> +    fi
>>>  fi
>>>  
>>>  exit "$TEST_RESULT"
>> A couple of things.
>>
>> From my experimentation with junit,
>> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1849342222/test_report?job_name=kbl-xtf-x86-64-gcc-debug
>> we can also use  for classification.  I'm also very disappointed
>> in Gitlab classifying  as success.
> According to the documentation [1] which point to this junit xml format [2]
> the only elements (and path) are:
>     testsuites.testsuite.testcase.failure
> "error" or "warning" don't exist.
> There's the attributes `type` in  but this isn't explained how
> it's used.
>
> But I guess if we follow the link in [2], go through web.archive.org, we
> can find [3] which has "skipped", "error", "failure", but still no
> "warning".
>
>
> [1] https://docs.gitlab.com/ci/testing/unit_test_reports/#unit-test-reporting-workflow
> [2] https://www.ibm.com/docs/en/developer-for-zos/16.0?topic=formats-junit-xml-format
> [3] https://github.com/windyroad/JUnit-Schema/blob/master/JUnit.xsd

I was also very disappointed with the documentation, which seems to be
almost non-existent.

But after some source diving:
https://gitlab.com/gitlab-org/gitlab-foss/-/blob/master/lib/gitlab/ci/parsers/test/junit.rb#L69-83

So anything which isn't recognised is deemed to be success.  Lovely :(

I'm also still none the wiser as to why Skip's system_out is a formatted
json blob, unlike the others.


>
>
>> Not for this patch, but for XTF I need to be able to express "tolerable
>> failure".  (All branches of Xen will run the same tests, and we don't
>> have OSSTest to deem "fail never passed" as non-blocking.)
> According to [1], there's a notion of "Existing failures", but that
> might show up only on merge request.
>
>> Even if the job passes overall, I want tolerable failures to show up in
>> the UI, so I have to use  in junit.xml.  But that means needing
>> to be more selective, and I don't have a good idea of how to do this. 
>> (I have one terrible idea, which is  which
>> will escape that grep, but it feels like (ab)buse of XML.)
> At the moment, `run-tools-tests` write ' failure, so we could grep on that instead event if it is sligtly more
> fragile. I've choosen to grep on '' at first because that's
> much less likely to be written differently, while the attributes in the
> tag could be written in a different order.
>
> Then, we can always use `sed` and extract the "type" to check it:
> sed -n 's/.*   case $type in
>     failure) echo fail;;
>     tolerable) echo ok;;
>     *) echo error unknwon type $type;;
>   esac
> done
> But that maybe going a bit too far :-)

There's xq which might be able to do this more nicely, and is packaged
in alpine.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 18:13:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 18:13:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004763.1384457 (Exim 4.92)
	(envelope-from )
	id 1uMW8J-0000q4-4O; Tue, 03 Jun 2025 18:13:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004763.1384457; Tue, 03 Jun 2025 18:13:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMW8J-0000px-1k; Tue, 03 Jun 2025 18:13:07 +0000
Received: by outflank-mailman (input) for mailman id 1004763;
 Tue, 03 Jun 2025 18:13: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 1uMW8H-0000pr-Ps
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 18:13:05 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6372a87c-40a6-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 20:13:03 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id C828761129;
 Tue,  3 Jun 2025 18:13:01 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id B2BFAC4CEED;
 Tue,  3 Jun 2025 18:13:00 +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: 6372a87c-40a6-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748974381;
	bh=DXC2BSuZDs+yoKc1QDayEXdrA2LCvsuZkC40+vec9no=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=VuQJ5qVVvpS1+hFl07Bpy6IOtuwexmWfGH0Jpq/vx+EoNfHkmpXDg9VT1q2uyAKKn
	 Hoxq5GlY/izqvoqr9vRFOHqivoKE3AYJrqXh9MStjku3TGeL0lXreFvTRCm+SB/7qS
	 1nEL3gIFyunmVDBSG3xqdG415aNM4QWkjurFzODF7L1vXqYs2pSWVvmTPjfY5kehwP
	 jxo7PspwnIsfUBFEUwS4rxbd4hJpfP3op69moaPhsYU4gtNeuEgnyS17W7iXfcl4HF
	 GWuSAYB4Z9bYPARbTmDiUe0Atm6XccEtCAy3Ofpnb/Tb+ceknaxZ7DRd+bHaQqlhjy
	 dYvbraoADKYlA==
Date: Tue, 3 Jun 2025 11:12:59 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: "Orzel, Michal" 
cc: Stefano Stabellini , 
    Stewart Hildebrand , 
    xen-devel@lists.xenproject.org, Anthony PERARD , 
    Juergen Gross 
Subject: Re: [PATCH v2 6/6] tools/arm: exclude iomem from domU extended
 regions
In-Reply-To: <3e8391b7-3b3e-4092-9689-ad0c94059571@amd.com>
Message-ID: 
References: <20250508132040.532898-1-stewart.hildebrand@amd.com> <20250508132040.532898-7-stewart.hildebrand@amd.com>  <3e8391b7-3b3e-4092-9689-ad0c94059571@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Tue, 3 Jun 2025, Orzel, Michal wrote:
> On 03/06/2025 02:38, Stefano Stabellini wrote:
> > I plan to commit this patch, unless someone objects
> AFAICT there is a new revision (v3) that has pending comments:
> https://lore.kernel.org/xen-devel/20250513195452.699600-1-stewart.hildebrand@amd.com/

Thanks Michal! Due to the change in CC and 0 email subject I didn't
notice the newer version


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 18:21:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 18:21:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004769.1384467 (Exim 4.92)
	(envelope-from )
	id 1uMWGN-0002TK-Tt; Tue, 03 Jun 2025 18:21:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004769.1384467; Tue, 03 Jun 2025 18: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 1uMWGN-0002TD-RD; Tue, 03 Jun 2025 18:21:27 +0000
Received: by outflank-mailman (input) for mailman id 1004769;
 Tue, 03 Jun 2025 18:21: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 1uMWGM-0002T7-K9
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 18:21:26 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org
 [2600:3c04:e001:324:0:1991:8:25])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8e33b9dc-40a7-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 20:21:24 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 4731161129;
 Tue,  3 Jun 2025 18:21:23 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0BF20C4CEF2;
 Tue,  3 Jun 2025 18:21: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: 8e33b9dc-40a7-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748974883;
	bh=a2w6lkekBlhpt9rgrFUNnuxqvuKrr/zY0TaVVm9GB8g=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=NkEq6okHcd3Owb+/GYt6ghnt3eMZewbW0HR6UZfp5vKQ3mW5b2zwKsrHB9x/ccZzP
	 9fRDQs0mnS7zB0c+IpQn+VzU/Va6VS3PqrMHrD07ZkcvSo6NGkmITbBYr4+csYH+Jy
	 zjK4JXa8DGm9AFvXOyaKz2/BBMz661oEu2W3KSm6A+U8XKDQEqazGJcqJjvpJpSBMG
	 H40zakLMsd7otalZGwnA61Sr8o3Q431GNY6Ib78GwGmyvb0UEUUg08VL2MXl37MpeP
	 7H04VPzVqPphEQNe15r51Uez9edFbnqRgHZYWwKQ9KVtUootMnK/mEB9r/mAqCpbB1
	 +syZgFqfkVRDg==
Date: Tue, 3 Jun 2025 11:21:21 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Andrew Cooper 
cc: Anthony PERARD , xen-devel@lists.xenproject.org, 
    =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , 
    Anthony PERARD , 
    Doug Goldstein , 
    Stefano Stabellini 
Subject: Re: [XEN PATCH 1/9] CI: Add SELECTED_JOBS_ONLY to analyze.yaml
In-Reply-To: <66c1a541-c6b2-4bf5-b1a7-9fb9ae19b4a0@citrix.com>
Message-ID: 
References: <20250603124222.52057-1-anthony@xenproject.org> <20250603124222.52057-2-anthony@xenproject.org> <66c1a541-c6b2-4bf5-b1a7-9fb9ae19b4a0@citrix.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Tue, 3 Jun 2025, Andrew Cooper wrote:
> On 03/06/2025 1:42 pm, Anthony PERARD wrote:
> > From: Anthony PERARD 
> >
> > Signed-off-by: Anthony PERARD 
> 
> Acked-by: Andrew Cooper 

Acked-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 18:22:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 18:22:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004775.1384478 (Exim 4.92)
	(envelope-from )
	id 1uMWHh-0002yb-7u; Tue, 03 Jun 2025 18:22:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004775.1384478; Tue, 03 Jun 2025 18:22:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMWHh-0002yU-55; Tue, 03 Jun 2025 18:22:49 +0000
Received: by outflank-mailman (input) for mailman id 1004775;
 Tue, 03 Jun 2025 18:22: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 1uMWHf-0002xx-EU
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 18:22:47 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id be6132cd-40a7-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 20:22:45 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 0BDE260008;
 Tue,  3 Jun 2025 18:22:44 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id C3E77C4CEED;
 Tue,  3 Jun 2025 18:22:42 +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: be6132cd-40a7-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748974963;
	bh=blaKPU6vquJLkgFFDNmpUlKYLKgCMRzOduRTL6lNUtc=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=aLt1oJct/22Wc+1Tzu6HClhuK7GYvh+sTLgYKr4vie1Jzch9twW/D7D6s+URHJfQv
	 PBiyPy3VvUy2jRTJuI5PRk8GtxhwjMLmJghpMnmbn0mmPQmB/KbFumfIkVqGnp+EY7
	 34m+3Vxia2Tzh3CFleYWti0jekxoAOhHk3/BEgz0gZnFnxzFyYVpoYDyVpvsqrlpR3
	 fFAxd7PnkPTQuNROdtXrn7oEyIw9HTLaX/D9dHEu1WKXUKwTJfVe/3sHqA9JmWNt0G
	 6ucLUsOfTIGc/lhbLEkOuAnBuYceVWrmp5leVP2/3xRii3h31K5lkgvHE1rO08MSeq
	 P6xJNZhDJLYyQ==
Date: Tue, 3 Jun 2025 11:22:42 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Andrew Cooper 
cc: Anthony PERARD , xen-devel@lists.xenproject.org, 
    =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , 
    Anthony PERARD , 
    Doug Goldstein , 
    Stefano Stabellini 
Subject: Re: [XEN PATCH 3/9] CI: Fix status check for tools/tests
In-Reply-To: <9854421d-e6c4-4ac4-ba77-4c038df8731f@citrix.com>
Message-ID: 
References: <20250603124222.52057-1-anthony@xenproject.org> <20250603124222.52057-4-anthony@xenproject.org> <9854421d-e6c4-4ac4-ba77-4c038df8731f@citrix.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Tue, 3 Jun 2025, Andrew Cooper wrote:
> On 03/06/2025 1:42 pm, Anthony PERARD wrote:
> > From: Anthony PERARD 
> >
> > Without "pipefail", $? have the exit value of `tee`, which should
> > always be 0. But instead of using "pipefail", do collect the value of
> > from the test with $PIPESTATUS.
> >
> > Signed-off-by: Anthony PERARD 
> 
> Reviewed-by: Andrew Cooper 

Acked-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 18:27:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 18:27:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004781.1384488 (Exim 4.92)
	(envelope-from )
	id 1uMWM7-0003Xm-Of; Tue, 03 Jun 2025 18:27:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004781.1384488; Tue, 03 Jun 2025 18:27: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 1uMWM7-0003Xf-L7; Tue, 03 Jun 2025 18:27:23 +0000
Received: by outflank-mailman (input) for mailman id 1004781;
 Tue, 03 Jun 2025 18:27: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 1uMWM6-0003XZ-NU
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 18:27:22 +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 62e13eab-40a8-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 20:27:21 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id D20F55C5A02;
 Tue,  3 Jun 2025 18:25:02 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 78D16C4CEED;
 Tue,  3 Jun 2025 18:27: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: 62e13eab-40a8-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748975239;
	bh=J/f+C6keB5M9wVg8IlVxoP0FHVf4r7gWEDaECsO3aLc=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=uZWhyuF3yxWyvDFJukMX8xkPK99nx5Ueb9jQyj26eSpmohQNYR5Y9AU7Nm9Ha1L42
	 B03Jh2Dv4T4WPk9sYrVNin6jgQw6HKVhKHCudXfdP+RxYDRSl0JidNdI4dxYyySIOI
	 AzSv4UQqrmA44KZqiggpTjC9JtffryInSR/JOmwH3Xjx5unAzZ8vtVbQ6TQMZy0Zl3
	 5cfiSLnzjSzXInhMQGbruK2eETtVTCVsXXb9eGT3+dPHsqwpsLMAjKBZ3kRAR4rYcS
	 CrqTQh/TCxm9qFP5759efP2X1f6SJZidUggJ5fMvyicWymt44jyEZBoYMFeCN330nY
	 9MsRRj2YjfLXQ==
Date: Tue, 3 Jun 2025 11:27:18 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Andrew Cooper 
cc: Anthony PERARD , xen-devel@lists.xenproject.org, 
    =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , 
    Anthony PERARD , 
    Doug Goldstein , 
    Stefano Stabellini 
Subject: Re: [XEN PATCH 7/9] CI: Use CDATA avoid the need to escape tests
 outputs
In-Reply-To: <1800c6aa-b3de-418b-967f-d7e7de932fe4@citrix.com>
Message-ID: 
References: <20250603124222.52057-1-anthony@xenproject.org> <20250603124222.52057-8-anthony@xenproject.org> <1800c6aa-b3de-418b-967f-d7e7de932fe4@citrix.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Tue, 3 Jun 2025, Andrew Cooper wrote:
> On 03/06/2025 1:42 pm, Anthony PERARD wrote:
> > diff --git a/automation/scripts/run-tools-tests b/automation/scripts/run-tools-tests
> > index 695ed77e46..852c1cfbcf 100755
> > --- a/automation/scripts/run-tools-tests
> > +++ b/automation/scripts/run-tools-tests
> > @@ -25,9 +25,9 @@ for f in "$1"/*; do
> >          echo "FAILED: $f"
> >          failed+=" $f"
> >          printf '   \n' "$f" "$ret" >> "$xml_out"
> > -        # TODO: could use xml escaping... but current tests seems to
> > -        # produce sane output
> > +        printf '> "$xml_out"
> >          cat /tmp/out >> "$xml_out"
> > +        printf ']]>' >> "$xml_out"
> 
> I think you want a \n on this printf.
> 
> I'd also suggest leaving a TODO for "escape ]]> if necessary".
> 
> Otherwise, Reviewed-by: Andrew Cooper 

Acked-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 18:29:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 18:29:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004788.1384499 (Exim 4.92)
	(envelope-from )
	id 1uMWNx-00042r-3f; Tue, 03 Jun 2025 18:29:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004788.1384499; Tue, 03 Jun 2025 18:29: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 1uMWNw-00042k-Vn; Tue, 03 Jun 2025 18:29:16 +0000
Received: by outflank-mailman (input) for mailman id 1004788;
 Tue, 03 Jun 2025 18:29: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 1uMWNv-00042e-NO
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 18:29:15 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a65b886c-40a8-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 20:29:14 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 3F31A60008;
 Tue,  3 Jun 2025 18:29:13 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0178BC4CEED;
 Tue,  3 Jun 2025 18:29: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: a65b886c-40a8-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748975352;
	bh=GbUJ+/YExugj8Q/Ik9MvCEXTOICGfE8TT7m1yoRV1ng=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=Xqfk7XJIkBlL4TuYa33pBmhaRXXv7x4VAGWPjeEKydW0sTHkWTm6EEjIfnBSihKZw
	 ybLpputMigPHPY/nGE5EfT70Nrh8ScxXrZDbuCOIChltbl8klhAE2jRe1g904rikGY
	 H2A8NRzyk2/c4Rq9FTpUE0cdzmQtTavn88DmGKTiML4hzHZ0hmYyHN3g8YklD6nxih
	 Pbeu0nEo0cIQBtSDkOG+nysheBgHc4FzVCLmFXS/QFHPdirm0ZqIJ3R8dIbi3J4vz8
	 3JuwtYXVHi3BXhryYa0y1y8HLH1sxaD0OZHi41FjEvy3Zmbg53qXC/+uqGokmdHlIr
	 r/2GIofdBR7bw==
Date: Tue, 3 Jun 2025 11:29:11 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Anthony PERARD 
cc: Andrew Cooper , xen-devel@lists.xenproject.org, 
    =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , 
    Anthony PERARD , 
    Doug Goldstein , 
    Stefano Stabellini 
Subject: Re: [XEN PATCH 8/9] CI: Workaround extra content in junit
In-Reply-To: 
Message-ID: 
References: <20250603124222.52057-1-anthony@xenproject.org> <20250603124222.52057-9-anthony@xenproject.org> <86d3655f-f541-441e-bb6c-1dda0b03540f@citrix.com> 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Tue, 3 Jun 2025, Anthony PERARD wrote:
> On Tue, Jun 03, 2025 at 03:12:32PM +0100, Andrew Cooper wrote:
> > On 03/06/2025 1:42 pm, Anthony PERARD wrote:
> > >  if [ -n "$retrieve_xml" ]; then
> > >      nc -w 10 "$SUT_ADDR" 8080 > tests-junit.xml  > > +    # Workaround duplicated data been received
> > > +    sed -i.old '/^<\/testsuites>/q' tests-junit.xml > /dev/null
> > > +    extra_line_in_junit=$(($(wc -l < tests-junit.xml.old) - $(wc -l < tests-junit.xml)))
> > > +    if [ $extra_line_in_junit -gt 0 ]; then
> > > +        echo "WARNING: Found $extra_line_in_junit too many lines in junit."
> > > +    fi
> > 
> > Is this the cause of
> > https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1849342222/test_report
> > getting a row of 0's for ADL ?
> 
> Well, the error I had was this one:
> "FATAL: Extra content at the end of the document"
> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1848598740/test_report
> 
> And indeed, when I managed to dl the junit.xml, there were the end of
> the document duplicated many times.

Wouldn't it better to do |sort|uniq to dedup the file?


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 18:35:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 18:35:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004794.1384508 (Exim 4.92)
	(envelope-from )
	id 1uMWTw-0005q9-MB; Tue, 03 Jun 2025 18:35:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004794.1384508; Tue, 03 Jun 2025 18: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 1uMWTw-0005q2-JZ; Tue, 03 Jun 2025 18:35:28 +0000
Received: by outflank-mailman (input) for mailman id 1004794;
 Tue, 03 Jun 2025 18: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 1uMWTv-0005pw-JD
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 18:35:27 +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 8354da70-40a9-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 20:35:25 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 2696D5C5819;
 Tue,  3 Jun 2025 18:33:07 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id B9947C4CEED;
 Tue,  3 Jun 2025 18:35: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: 8354da70-40a9-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748975723;
	bh=fcup2wT9zyRm8eeL+Go1fTAE14x50tKplGDeaJ8a5fQ=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=iycfMqgjQDXoVXHEWmjbaCnBWTESAF7gYmSiwEq513FC2cWt3MSzkAqgg6CW9O1v6
	 sIlBoReB3XFYw4mVq6pTrdWzfzy0ZJjRLam18Q3PNP91EYwgqFHyOlwiT6hPNEUDt3
	 Xuzh0dbBhOFH0Aztpu99BIBJqhe7Up8CFHJhOh+O1xUWUSWVS/exG6qEEIuS0tSXJT
	 syaHRHWWtkWtke0iKVj0gSL7SZeFLIlkO+gcF0e/0Vua5Eg039tJq/g1Vs3pDnz44h
	 zXQL0oAUAQIUS8LtKZzsUna7QSlB3C6PXnnzOxjQ/qkcMVUCSnSe8fr7SVNFGk5AbJ
	 jkg97otgybANg==
Date: Tue, 3 Jun 2025 11:35:22 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Anthony PERARD 
cc: xen-devel@lists.xenproject.org, 
    =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , 
    Andrew Cooper , 
    Anthony PERARD , 
    Doug Goldstein , 
    Stefano Stabellini 
Subject: Re: [XEN PATCH 9/9] CI: Add timing to junit
In-Reply-To: <20250603124222.52057-10-anthony@xenproject.org>
Message-ID: 
References: <20250603124222.52057-1-anthony@xenproject.org> <20250603124222.52057-10-anthony@xenproject.org>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Tue, 3 Jun 2025, Anthony PERARD wrote:
> From: Anthony PERARD 
> 
> Signed-off-by: Anthony PERARD 
> ---
>  automation/scripts/run-tools-tests | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/automation/scripts/run-tools-tests b/automation/scripts/run-tools-tests
> index 852c1cfbcf..e38cc4068c 100755
> --- a/automation/scripts/run-tools-tests
> +++ b/automation/scripts/run-tools-tests
> @@ -18,9 +18,12 @@ for f in "$1"/*; do
>          continue
>      fi
>      echo "Running $f"
> -    printf '  \n' "$f" >> "$xml_out"
> +    time_start=$EPOCHREALTIME
>      "$f" 2>&1 | tee /tmp/out
>      ret=${PIPESTATUS[0]}
> +    time_end=$EPOCHREALTIME
> +    time_test="$(bc <<<"$time_end - $time_start")"

As it looks like no other scripts need bc at the moment but we already
rely on awk (automation/scripts/xilinx-smoke-dom0less-arm64.sh) I'd
prefer this version:

time_test="$(awk "BEGIN {print $time_end - $time_start}")"


> +    printf '  \n' "$f" "$time_test" >> "$xml_out"
>      if [ "$ret" -ne 0 ]; then
>          echo "FAILED: $f"
>          failed+=" $f"
> -- 
> Anthony PERARD
> 


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 18:37:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 18:37:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004801.1384518 (Exim 4.92)
	(envelope-from )
	id 1uMWVj-0006M0-0i; Tue, 03 Jun 2025 18:37:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004801.1384518; Tue, 03 Jun 2025 18:37:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMWVi-0006Lt-Tf; Tue, 03 Jun 2025 18:37:18 +0000
Received: by outflank-mailman (input) for mailman id 1004801;
 Tue, 03 Jun 2025 18:37: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 1uMWVh-0006Ll-Ja
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 18:37:17 +0000
Received: from fhigh-b5-smtp.messagingengine.com
 (fhigh-b5-smtp.messagingengine.com [202.12.124.156])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c4a9dd31-40a9-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 20:37:15 +0200 (CEST)
Received: from phl-compute-06.internal (phl-compute-06.phl.internal
 [10.202.2.46])
 by mailfhigh.stl.internal (Postfix) with ESMTP id 963F22540109;
 Tue,  3 Jun 2025 14:37:13 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-06.internal (MEProxy); Tue, 03 Jun 2025 14:37:13 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 3 Jun 2025 14:37:11 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c4a9dd31-40a9-11f0-b894-0df219b8e170
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=1748975833;
	 x=1749062233; bh=nEuiz3ufLBAGsi6VBBkny6n5Ky9dEu0DhzDGeZ8X354=; b=
	JZZSZwEEUAgbAMkubWCPRyuEStKzdvfNIY/Ic7E+i/7pFsiB5ZsPDUToO4rSPBiK
	+M6JuI2N2GXSnRdEklmRUwkwGrGlrPpNzjD8nX6SFaU5Rq5OcOk53jrH0e4aXI6i
	UkLTjRddyen7fAwZWxyQYZrAnpmK9Xf3feGHtvDo5qvhpKxWQvmWMFUPMSjSlp5x
	XAL8q/jb/SPJ9KLE2U0APfqOJSk91hCpwljumtTJlcc6Bm48ZLv+4Qnjum7nG9lA
	G7dYBqSMMg7PpqdFjGvznTARv9Wf491CrMr4lvBgXqbHMaBsuANqvK+WLWoegfPl
	KlLlBt86sb7apsx11dtVVA==
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=
	1748975833; x=1749062233; bh=nEuiz3ufLBAGsi6VBBkny6n5Ky9dEu0DhzD
	GeZ8X354=; b=bh6pOf+LulZkdPbvmT0ypIhqTQ+aDr07DJg7YS+j8Ij0DfkASPC
	QmUHo76XhnpbpMFrh9V2o/z6cQqbZu+43PiPjtz/t3/MDDCYNLl/yngKqATYZBjW
	zuBJ58vdDln13MiGqL5IvF60hUyTmnPhKL+8lxfl4JJUOBP2FnxCUCcmvnJOti1x
	HBRuY68LZnQEkxyyfttES7eawKa4ruTLPNhxmlysRyLIQub+iW5+zu/5g/2D28sT
	e87T0NW6BIWCumVjFiCyimrB8Fl1V0eD14Qzbwh2grjccX1aqAW+coADH1VQQvte
	7fj0Xf/Gjh+9C77bKomMOzRtpwEzK/iTAFg==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugdeliecutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr
    tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnth
    hsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecu
    hfhrohhmpeforghrvghkucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrg
    hrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffr
    rghtthgvrhhnpeevueejteegleelteduueevhfetgfffjeevtddvgfeiveehteehleegue
    elvdejveenucffohhmrghinhepghhithhlrggsrdgtohhmnecuvehluhhsthgvrhfuihii
    vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhvihhsih
    gslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepiedpmhhouggvpehs
    mhhtphhouhhtpdhrtghpthhtohepshhsthgrsggvlhhlihhniheskhgvrhhnvghlrdhorh
    hgpdhrtghpthhtoheprghnthhhohhnhiesgigvnhhprhhojhgvtghtrdhorhhgpdhrtghp
    thhtoheprghnughrvgifrdgtohhophgvrhefsegtihhtrhhigidrtghomhdprhgtphhtth
    hopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdprhgt
    phhtthhopegrnhhthhhonhihrdhpvghrrghrugesvhgrthgvshdrthgvtghhpdhrtghpth
    htoheptggrrhguohgvsegtrghrughovgdrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Tue, 3 Jun 2025 20:37:09 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Stefano Stabellini 
Cc: Anthony PERARD ,
	Andrew Cooper ,
	xen-devel@lists.xenproject.org,
	Anthony PERARD ,
	Doug Goldstein 
Subject: Re: [XEN PATCH 8/9] CI: Workaround extra content in junit
Message-ID: 
References: <20250603124222.52057-1-anthony@xenproject.org>
 <20250603124222.52057-9-anthony@xenproject.org>
 <86d3655f-f541-441e-bb6c-1dda0b03540f@citrix.com>
 
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="J8Or3Pad7ufB5OFK"
Content-Disposition: inline
In-Reply-To: 


--J8Or3Pad7ufB5OFK
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 3 Jun 2025 20:37:09 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Stefano Stabellini 
Cc: Anthony PERARD ,
	Andrew Cooper ,
	xen-devel@lists.xenproject.org,
	Anthony PERARD ,
	Doug Goldstein 
Subject: Re: [XEN PATCH 8/9] CI: Workaround extra content in junit

On Tue, Jun 03, 2025 at 11:29:11AM -0700, Stefano Stabellini wrote:
> On Tue, 3 Jun 2025, Anthony PERARD wrote:
> > On Tue, Jun 03, 2025 at 03:12:32PM +0100, Andrew Cooper wrote:
> > > On 03/06/2025 1:42 pm, Anthony PERARD wrote:
> > > >  if [ -n "$retrieve_xml" ]; then
> > > >      nc -w 10 "$SUT_ADDR" 8080 > tests-junit.xml  > > > +    # Workaround duplicated data been received
> > > > +    sed -i.old '/^<\/testsuites>/q' tests-junit.xml > /dev/null
> > > > +    extra_line_in_junit=3D$(($(wc -l < tests-junit.xml.old) - $(wc=
 -l < tests-junit.xml)))
> > > > +    if [ $extra_line_in_junit -gt 0 ]; then
> > > > +        echo "WARNING: Found $extra_line_in_junit too many lines i=
n junit."
> > > > +    fi
> > >=20
> > > Is this the cause of
> > > https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/18493=
42222/test_report
> > > getting a row of 0's for ADL ?
> >=20
> > Well, the error I had was this one:
> > "FATAL: Extra content at the end of the document"
> > https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1848598=
740/test_report
> >=20
> > And indeed, when I managed to dl the junit.xml, there were the end of
> > the document duplicated many times.
>=20
> Wouldn't it better to do |sort|uniq to dedup the file?

I don't think XML structure will survive it...

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

--J8Or3Pad7ufB5OFK
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmg/QNUACgkQ24/THMrX
1yx2oAf/dBzm8uVNHbYdwmGDmrNF2f1svf1qAAErBd9u1+OKXzzxs3GmrlwaqLDf
ImChEhME6A4bgPpMgyaA7aBob7z7ChGJU8g16mSmkjIklytx0ecXrDxT3tYDi5oS
bBPc0lXz5ns58WEcdAw/BHMy1DJmCfPKIUBB0mChSwneENdR7AzIT1j7mXBDracU
PAuoLIZgZEhRR1Yso8y1iZrkchFSZPEyFi0fzqptYY1FG2v3UusLz9PffhAvH0Ng
/Ky043iauM8jvzln2CgILeONILvu++9ANG4mVGftT2qSbleZ4ua5EAQ3Uk6eO71J
Wi3D/UvdHkPWk0rIX+ceChsWkDDpEA==
=h837
-----END PGP SIGNATURE-----

--J8Or3Pad7ufB5OFK--


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 19:44:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 19:44:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004833.1384528 (Exim 4.92)
	(envelope-from )
	id 1uMXYB-0007Tn-O7; Tue, 03 Jun 2025 19:43:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004833.1384528; Tue, 03 Jun 2025 19:43:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMXYB-0007Tg-KE; Tue, 03 Jun 2025 19:43:55 +0000
Received: by outflank-mailman (input) for mailman id 1004833;
 Tue, 03 Jun 2025 19:43: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 1uMXY9-0007Ta-A2
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 19:43:53 +0000
Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com
 [205.220.165.32]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1189a2f7-40b3-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 21:43:50 +0200 (CEST)
Received: from pps.filterd (m0246617.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 553HY1bQ020072;
 Tue, 3 Jun 2025 19:43:36 GMT
Received: from phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com
 (phxpaimrmta03.appoci.oracle.com [138.1.37.129])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 471g8kanj9-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Tue, 03 Jun 2025 19:43:36 +0000 (GMT)
Received: from pps.filterd
 (phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1])
 by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (8.18.1.2/8.18.1.2)
 with ESMTP id 553IqTx0035024; Tue, 3 Jun 2025 19:43:35 GMT
Received: from cy4pr05cu001.outbound.protection.outlook.com
 (mail-westcentralusazon11010046.outbound.protection.outlook.com
 [40.93.198.46])
 by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id
 46yr7a3nxq-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Tue, 03 Jun 2025 19:43:35 +0000
Received: from DS0PR10MB7224.namprd10.prod.outlook.com (2603:10b6:8:f5::14) by
 SA1PR10MB6541.namprd10.prod.outlook.com (2603:10b6:806:2bd::20) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.30; Tue, 3 Jun
 2025 19:43:33 +0000
Received: from DS0PR10MB7224.namprd10.prod.outlook.com
 ([fe80::c57:383f:cfb2:47f8]) by DS0PR10MB7224.namprd10.prod.outlook.com
 ([fe80::c57:383f:cfb2:47f8%4]) with mapi id 15.20.8813.018; Tue, 3 Jun 2025
 19:43: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: 1189a2f7-40b3-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=
	corp-2025-04-25; bh=sEXC6T0MJe2O10glzMtv7+EQ4/Y0XN4bug/GWxox0gY=; b=
	CC3nc6zFb3Fq3kGNhGUNRKPpSFzV/tsijo/90/P2vSb7yF/iY9/LlUz+nq+gNkYT
	EAil1PE6WFDgP5AKqPOfaQDbNs8m/Cn1rFHR0T3Ui+hG8u29YzqneZZa0p2WA8yO
	JQ3eW3KQ36dxTkGHr1kLDc3EGNjTqk76deO9mu2Tegzfonp3bTsAK/aGzYLVrJUb
	zpZJUgI4z1DLiMINSjk+KI342nZj9vmzaaNxPfOX9jKHJODPEBQCkz69pmWr5IYV
	0JCoNZYMXBm9al4TFFC7/oyKG7I2FSasDeCjLeLYxZldolWIOxRpn2NMpRrhTstN
	1EHsncOJOsqWz1pZ2G9N2g==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=QLo6BE1NFR701FHn0cw5w58f1ukKFLBIkZfnvQ4uuah1fwXKiucybklXCSIkenLhpBxQ+hthl4WPc4Ccfo4uWr9dDixqUYiXXsiXtyuqxOlqENd7khqzB28pT2CCoVIEzOAJrwTpzz6unrS5Oi3Wd27hW4BfJLJwobt70aSi44vHQ5U49/V+0fmT8McDowcKIJ/K0tTc9BwiDF0IdgAaKbLFa2UYpVtdpkcUgx/Fa2nL33K6zuZO1CQ1TPYKP6Jb8Kq7JWOFFGCGlnvfylJvZ6et6vo65tv8AbS4DYaT6OvgAjXtyRzxpuXi/7t53G90LH1CZuqqiI0pTFa5F+kccA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=sEXC6T0MJe2O10glzMtv7+EQ4/Y0XN4bug/GWxox0gY=;
 b=PrzrbvOQ2gOiRi30ciH/9n7a3hlOZ6zcG7TKgvWAs5alz5//wyweyEwylwp7UuxPE8tvjO3jdhMp3NFNp+qQ04z+/I2Y8yOIuaeZOmBZFzX0gj3UAliRppfj1nCTmFJ1KN9vnUblM6QWkUA9B0gmASRMee3PZ0nNItgZ036xfHHySgD02gDk8Cq6UlBgGinZvaIXJf5ncv863gmOX2g8PuXcg/bHTSsWMtlo/P0xJphVbuvSmme+b9yw6NVWPejlGQwAEwnCNtjGTUZMfrcBTE0hdh8w3QlskchVYtHpLnN2qJSvXG3H5eO3cR0G8tyfMUv/tHBtjn2QAaB9SDpJZA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=sEXC6T0MJe2O10glzMtv7+EQ4/Y0XN4bug/GWxox0gY=;
 b=NUwEDkhg2/fZCbLBlpl20chPXcTi8pJzZ+b9XpNHyyI4fHU3X474p1kHPcsybrGnJtyBetTNLjyGBJ3J0O9QjoThdpmsNHLKvI7/OaLhz4f7pXFqPDBMLwmOk0oXBrUEdQNa0wDY+pkXAkLdwZcQdMqT30OLnztiy8acorY47vA=
Message-ID: 
Date: Tue, 3 Jun 2025 12:43:30 -0700
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 08/22] x86/slaunch: restore boot MTRRs after Intel TXT
 DRTM
To: Sergii Dmytruk , xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
        Andrew Cooper
 ,
        =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 ,
        "Daniel P. Smith" ,
        trenchboot-devel@googlegroups.com
References: 
 <5b6b9bf165a4fd9444dc53848fb8faa2cea30781.1748611041.git.sergii.dmytruk@3mdeb.com>
Content-Language: en-US
From: ross.philipson@oracle.com
In-Reply-To: <5b6b9bf165a4fd9444dc53848fb8faa2cea30781.1748611041.git.sergii.dmytruk@3mdeb.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: SJ0PR05CA0021.namprd05.prod.outlook.com
 (2603:10b6:a03:33b::26) To DS0PR10MB7224.namprd10.prod.outlook.com
 (2603:10b6:8:f5::14)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS0PR10MB7224:EE_|SA1PR10MB6541:EE_
X-MS-Office365-Filtering-Correlation-Id: a965491f-4d2c-46b6-3ed4-08dda2d6ec42
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?SnpEak85RTVudHFrWlpQbEVXMXpBNjFJK1NiZmhSRmFUcDVLOUlCc3lmQnJW?=
 =?utf-8?B?c2xQMHJUS3Ird05UTXh0eUwrejJjb0lRRlp2aTZWRmRzWDNQQ2d3MGZ4UzQw?=
 =?utf-8?B?bjJrbVU0MzlFL0JTQUZPKy9uK2p6YmtlYzYwZDBHeWovUXJTOUl5WlQ3MTRO?=
 =?utf-8?B?OVJLWnFHQ3d1QWljWEExanBzaHE3RW1VR0crK2kxa0ZvOG5QcVRSV2FybWR3?=
 =?utf-8?B?THR6VUIwL2psbURnNlB2V1dFQ3BndjBieHppYTVhMzB0MWpOK2VVOStJZHdK?=
 =?utf-8?B?RjZOd3ovcWcxelBHZmNwME54SUJKaHdoUnYvdzh2VlVxQThXWGh6eEpaRHNt?=
 =?utf-8?B?NkRXRU5WcEJIQ282RTZMeVdoNHUzZEpBR2JUdnRUUW5STlN1Nys4d0RaYy9r?=
 =?utf-8?B?Z2lEUzE2NWtoeWxGa21mTERvYUJxczF4ZnpIbktvV01CV2ViYXJXRjIyTWZC?=
 =?utf-8?B?QnlMbm9MakVCbmZiU0JPWUROYXNsNTVoR0RXTkg2Q3NlOURxSGkyUnBOdmhw?=
 =?utf-8?B?ZXVBYldZSmhudkJsSVFoU2FYdlVnaWZFU0FzMGVBTUl6MEo4NzJZKzJtN3Jn?=
 =?utf-8?B?TU41ZTMzZjlKUEU2dklUYW9DNXd1SGxZVStrVWFpRUs0MjcxcXA1aEJXTDRJ?=
 =?utf-8?B?elJrL25LNGpDL09pRHNFeHg3ZHFubzBkY2I3a0ZxVTkzMm9aazRwNXBYVlFr?=
 =?utf-8?B?aG9uM3RURVR6UkttdU1HZ0ZDb0E2SENaa1hwY1RaaWpwOGEranl5cW1vQ29z?=
 =?utf-8?B?TWtGK2VxbEZDelo5ZE9CZGlvRzRxWmZmOHdCYW5NbDVWVDF0N2FmNUZtaTVG?=
 =?utf-8?B?bVMvMHd4OWRNRW43amRHdmo4ZzVQWUErWmpVa0xaT0xQY00weHBQeHlXMDEr?=
 =?utf-8?B?THYzUWM0dlRBQWVXdFVBMC9UM2ExUzI2dzhGU3d5YzZYM3N3R0dSUWxYYU9j?=
 =?utf-8?B?NDZiVCtMOHo0b3dNZWRBRGpnMm5CSjZZOUhva0JNNDZJMWhDeTRIVlA5Q3FK?=
 =?utf-8?B?SkRvTmtZOG5hMUFSWFRHTkZkdDg0U2t0dm5RNlFBZUNJQVNLeExGUTQwRW54?=
 =?utf-8?B?enIzbXM3OEFkOXVaR2tyUWZlT1B6Zmd2MHlEbUZ0VWcxUm5DY0RhY0U1MHl3?=
 =?utf-8?B?Y3VIc2U2cHdGWWEzYTl3NGtmOVg2ZjZLTmY4VVVsNEg3cklhM0pMaWFKbUor?=
 =?utf-8?B?WThGQWx1N0NFMWVHK01sZ3YwUUwxS3VmSXYveUF4TSt3VUl4MlhZc2E4c2p6?=
 =?utf-8?B?cldqZ2xsd2gwK0lKVVJGMk0xNXdVVmtNY2c3b1E5MXVqa1BZc3AwRnlpR0VD?=
 =?utf-8?B?dDU1UHIxeFBucFJaN2hNc05KWE1qRmdYOUlMS2ZNbURodVVmeDN1bGVkTDVU?=
 =?utf-8?B?V1FHUWxldVpra3E4RnNxOFhtNWpzVDBiWUFFVWpGK0VnQklUQnUyTCtOYzVw?=
 =?utf-8?B?S3dUL2pSVXBqclhOTzZra0dDa2JUbHR5NnhSc0JOSDVoaURwQVVJMWJ6WktR?=
 =?utf-8?B?ckttK2psT1FNbW90QUxMZCtXMndMb3hqWDBNQVk5M3YzbC9XeXBSSUZ3b2g4?=
 =?utf-8?B?TDd4Z1hjUWFoLzRyL1lKVTQ3WGkydFk3QUJpQk0yUVlEUmJhaFVUb2pmcWNL?=
 =?utf-8?B?bUpGYSs3QUhYZnA3MFR2MWJ4MUo0dnhIYjIvMUxRdFJlbDJ0c2lmU1NlUitO?=
 =?utf-8?B?NHVQVENYcUpFcGJaZWlMNjlEcW9GU3JQSS8wNXlmZlU4cEdMNmRCaTJtZnhO?=
 =?utf-8?B?K2lmU1d5Nlh1ZFlXV1pZcWhPT3dTbGhCWWJraHUwVnpPSUhwazVzUzVMSkpr?=
 =?utf-8?B?VCtQUGc2ZFRwVTVSN0tQMytEOHRyVnp1M3FCcjJXYUpXU3R0bUxQeUttTHZR?=
 =?utf-8?B?RG1WcnRDR0ZEbUhLeEE2ZDZYOTFONGNXcWovQ2QxUUN2b3NQMkN6WnhkNm1H?=
 =?utf-8?Q?Sk/kZps/KNU=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS0PR10MB7224.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?ZVI2RVdzUGg2MDF6Q2VyaUtQb2VYQkFKRWViTDhkZk9NeUtZZHZ4NktzbEly?=
 =?utf-8?B?elplSnRsSEJ0Nk5FZURHZ0NGWEc0czdud2dmV2ZIaDE3bG5GN2N3bGJhbFRE?=
 =?utf-8?B?cktrTWprM1UrK25TcGpsZFNvZGkwVFljWDJkVlVubC9hUTNYMlVSWFN0THgw?=
 =?utf-8?B?UmF0Nyt5QWNBSVBVR21YbEQ4T2FGM0tUSytVZWRIQW9nRXVGRmpNaHdFK3pH?=
 =?utf-8?B?MG9GbVFPcVdUT0doc0tUdmwwZGpxcW1CelA1NEN2RVJRRXkrUzhvYUlRZmQ1?=
 =?utf-8?B?OFhodWJKM0hScGZWZmlOMlhMS1Q1ZlprVGJMNlZZN3RqVjJoaUIvU1pITVBW?=
 =?utf-8?B?RW9JY1lFZlJZUGhpMUFpR3pnbGpDNXI4OXpqbXBRSExhdFNjR0FGa3JYbnlJ?=
 =?utf-8?B?SFVyRUpyNDRNR3BtTXU5YjRQdkt1VlZwK3NRWkg5U0hQT3dHcnZ6c0hUeUZV?=
 =?utf-8?B?MFlPamJSMEJKUm5WWmFtditWNzQ3a1FGY0ZTM0swY1BTdFBtS1NhVklidzRO?=
 =?utf-8?B?T0pUTHNBakpuOTNVMHRKTE5lNW00KzhubStEWnpEeTZzaUV5YU1LSGpsaEd5?=
 =?utf-8?B?ZUtSZWFzSklUTGlpMUhXenhIekFvVXBLeFpoRzBJL1kwVlo5aFV5ZzByUDkx?=
 =?utf-8?B?a2M4ZmxSYWJhNVNHNG52SXQ3TnlSRHdTOHR0VldrNmdEQWtTVDRmZXdZSFdo?=
 =?utf-8?B?ZVhTRlhBNU5CZjFsRHd3elIzZm5tN0ZwZVVZV0tyYkpKVDJMWW5wVllWY1ZJ?=
 =?utf-8?B?MUIvUmRXZFNaZjA0NlZyVG94RENETjFISmM0dmgxQlE1eXBicGlObER3L002?=
 =?utf-8?B?dnNlTkIyZHJsazl3bUVqYWhuencwK3d4ZzAvbFlPdVZNSk1Sd2xMQlVRb2NG?=
 =?utf-8?B?L2JSM1dQemw2MkVZcVVvUWYyU0NCbnFxUVNaSFdPTUUxa1psMHlBazRXNitl?=
 =?utf-8?B?STE1NVg2SUx5UDRSTGU1Y0huaEk0TDZ4SnNpdHMyNStVMUw1YW1kOGRhdmxm?=
 =?utf-8?B?aWdKMFl6cUhkVFcrZmQrVk5qd1hqbG9taEE4NFp4RU9PRW1idU4zY2ZFRkEw?=
 =?utf-8?B?NVhuVDgvVmlDTnJSSy85RFUxNStISFcxcGF3KzRVbFBpQ2VBTjdVOW5ieFNY?=
 =?utf-8?B?dlBuOFQ5QnIwQ2diemwrSk04YmVGdnY5QmZRREN5MmFPTTRKZ1N5TytlRXN1?=
 =?utf-8?B?dlNGaXBPVm1VYUF4L1RvUkhrd3JBQlVQS2J0YnIwV2xNajNOcG14UG1jeHdF?=
 =?utf-8?B?RXBuODhRZ1Z1MW1lcFhpWlFJN01iVG9tUE5kTDVyYndZTmtWajhBZGJqZEhw?=
 =?utf-8?B?ODRRK3ByaUxDcEE0bVBVLzJheFBvOWFlZ0MyZlF4ajBZaVBBNjQ0aitlQU1S?=
 =?utf-8?B?M3NIMFVHbTRkUm4rRzQ4czNnNlJrNEI4dFNaTXZtMWZzZWd1NzMzRkVXUVNZ?=
 =?utf-8?B?dUZuSzBQaHQ2eUpiVnE3YVFvRlJFWTdVNTg2RVJEYUE2V2xGN3g3OUY1Rmlh?=
 =?utf-8?B?Mjh0a2QzcjdSTVlLUmUyY3BZU2dFNXRkR2VKNC90UmJlOENoZCt2S0R5ZDhk?=
 =?utf-8?B?d3YvWkFoNEN5cGRUeFRzUDR0bkFZRkJ0WHlvSnVJdUZrR3NoRG10R25JWDRE?=
 =?utf-8?B?bkVQWGxudHhRT2NHZFVRaWxHM1hFNkNjdEdTb1RkUUpSYllCYzZoTFFtNFZT?=
 =?utf-8?B?SCtvOXEvUmlrTVRFVmR6d0kwYUJYRnZ6bzRyekFhcTdCQUU2ck1YOFBCRmg0?=
 =?utf-8?B?eUxEV0QxSVRNNnRLa2dUNFpoVjEzb3pHaVpIVjZNS0IwMzlqdkZzUHlMS0Fr?=
 =?utf-8?B?b2Y4b2ZFVDdEb0ZHLzcydHlHelFBdmx4dzBYblhvdXFJWnVKY1J0QVZGK3ZP?=
 =?utf-8?B?aTZiWTJjQ0F4QWxKejhEdkRNM2FlMWthcnlXTGNWbmdka1lUNVZwSlFtT2JN?=
 =?utf-8?B?V0xlM1NNcU91aEZzZXl1Q2ZPbzFPbGY1VTZvc04wRXRHelJLRGk3OWozNUF5?=
 =?utf-8?B?bEp3SERGR21PNU1CM0E3dUhSbmpaazBYRnhWa3IvYmltYlBhT0FjNlgxcWl4?=
 =?utf-8?B?VGVMSHZVeGVGVUpFMHRIYmN4cVQ4Tk5OM1pETWRWekgwd29VaHpLM21pZzhi?=
 =?utf-8?B?UlN6bHk2M1ZxMGFPSFJoeGI2b2FrS1A4S2Jtcjc4ZS9HTVpoc3RNcEFrQ2hY?=
 =?utf-8?B?RWc9PQ==?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	KFeP+m+X3jyb4bO7qOh/LSWFw7dBMvUTZdenf1fRfWE0S87OIkJWMdFIDr1pOvdwvU1WkJdLO+yUSgA+kqm5zlQNm/hV5Wa2WzBIsGZgqs1ObVB2rlAvZPgrDjaI1sveMfzVa5sWOKWWiYpvEG4akBx5fU5+b2MqoE0SoeBtyo6MDkLyly6Er9Ie2PdQEE4NQVNwk4EZQKsa/kVysKHhR35xw/BFv8tSud/MbCUYLLjPE+lDJtCXXU60oEovpCfNVRCMFMY2LIWAAGaBSntvQMIV6BdFLAl5jRMu9AYcCi1BiRyLH92mFULk1/g9sQ7bsbt4EfdDJW+UdBrsHPlnoGv2kVLcFYW/U61Uu6aQOGLi13lVKiZ4eWgMpkyZpXidlzjeNPSu8EwyQ3jX+i9xai64tb2mjYlZfmEe0V5NSxLCyWFQIHPTytiC3HYV6ZEkpQNmNnsho20NuS5/HfvMGxOLlhxbIXPsl0izSyxxVkwXloPEUYvnoCX2AAghAy+Sp2nAAjs72yLSMMc3NF6i5Ed4mQJYXnZDGItG58EtrN2umgyq5QOsa0pbKJHci8+1LLGZklk1i0XVs6lrl0/5AOLNmsfWzpZ2QuLzo3idnsM=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a965491f-4d2c-46b6-3ed4-08dda2d6ec42
X-MS-Exchange-CrossTenant-AuthSource: DS0PR10MB7224.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jun 2025 19:43:32.8379
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Wu9B+VH+c1zCjRGRqDNw/jU2IM2J7LtjgKFNO/95kTUusI6ppQM2ZL39lwlqKneWRa7NniST4hsOWb5pwdmdMHvH6hMhvJ2faMCIma6eiQQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR10MB6541
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40
 definitions=2025-06-03_02,2025-06-02_01,2025-03-28_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxlogscore=999
 bulkscore=0 spamscore=0 suspectscore=0 malwarescore=0 mlxscore=0
 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2505160000 definitions=main-2506030172
X-Proofpoint-GUID: m6o4JVHiNyJWHCOTe64BCyxvvr6F6kZo
X-Proofpoint-ORIG-GUID: m6o4JVHiNyJWHCOTe64BCyxvvr6F6kZo
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjAzMDE3MiBTYWx0ZWRfXwKlDzEbC7y8s zX1gCj1BuJHNsK1upbrx3D7L/VlLE0H+k5LcF7eNRe8D7j6hcj5jctmYUmVGqxAfHD2msEwJu6S OBvAfHY7x67cvftKiQoerDbV6JL4ii4RpaWHY7uIi+NRP5n+DgRi8mTiEQvVnL353kbBrYZ1lf5
 Me9EKHUX24FBr4n935pC+TxVFQFGhU532Jhfh1FMNQxzmbILXYBWQGvAJoJbLOPzG+8zcWG/c/o nKQEuhan31Ya9L7jJIfsZSfn3eKliiaftfhc89YdmBCpW+fYOyroYbA2zfzjFGvYOE0j+pyRxWj +P/qleufu5JxZcE8fadISO4c/cXEpDRTh8udJGJXHreF07yUY+GI53Yk+6jjkTMQ/+jWyySPA+n
 hOaoAZHLn+zjyPtzOpPt6OvOzmXFUT/WCXgEwyMUcnVuknOYZbTLsx7lB0FlL7QPlUjz2HZo
X-Authority-Analysis: v=2.4 cv=FM4bx/os c=1 sm=1 tr=0 ts=683f5068 b=1 cx=c_pps a=WeWmnZmh0fydH62SvGsd2A==:117 a=WeWmnZmh0fydH62SvGsd2A==:17 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19
 a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=6IFa9wvqVegA:10 a=GoEa3M9JfhUA:10 a=C_d68mY_AAAA:8 a=b_4gr1VNPdOSmOihzdAA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=wASdygnoxNaGnvDdgHrj:22

On 5/30/25 6:17 AM, Sergii Dmytruk wrote:
> From: Krystian Hebel 
> 
> In preparation for TXT SENTER call, GRUB had to modify MTRR settings
> to be UC for everything except SINIT ACM. Old values are restored
> from SLRT where they were saved by the bootloader.
> 
> Signed-off-by: Krystian Hebel 
> Signed-off-by: Michał Żygowski 
> Signed-off-by: Sergii Dmytruk 
> ---
>   xen/arch/x86/e820.c                  |  5 ++
>   xen/arch/x86/include/asm/intel-txt.h |  3 ++
>   xen/arch/x86/intel-txt.c             | 75 ++++++++++++++++++++++++++++
>   3 files changed, 83 insertions(+)
> 
> diff --git a/xen/arch/x86/e820.c b/xen/arch/x86/e820.c
> index ca577c0bde..60f00e5259 100644
> --- a/xen/arch/x86/e820.c
> +++ b/xen/arch/x86/e820.c
> @@ -11,6 +11,8 @@
>   #include 
>   #include 
>   #include 
> +#include 
> +#include 
>   
>   /*
>    * opt_mem: Limit maximum address of physical RAM.
> @@ -442,6 +444,9 @@ static uint64_t __init mtrr_top_of_ram(void)
>       ASSERT(paddr_bits);
>       addr_mask = ((1ULL << paddr_bits) - 1) & PAGE_MASK;
>   
> +    if ( slaunch_active )
> +        txt_restore_mtrrs(e820_verbose);
> +

I was just curious why they are being restored here in the e820 code? It 
seems that could be restored earlier. Until they are restored, most of 
RAM is set UC as you know. I also don't have an exact idea how early in 
Xen boot cycle this is occurring so maybe this is fine but obviously for 
performance reasons it should be done as early as possible.

Thanks,
Ross

>       rdmsrl(MSR_MTRRcap, mtrr_cap);
>       rdmsrl(MSR_MTRRdefType, mtrr_def);
>   
> diff --git a/xen/arch/x86/include/asm/intel-txt.h b/xen/arch/x86/include/asm/intel-txt.h
> index ad3c41d86c..0b0bdc1bb2 100644
> --- a/xen/arch/x86/include/asm/intel-txt.h
> +++ b/xen/arch/x86/include/asm/intel-txt.h
> @@ -426,6 +426,9 @@ void txt_map_mem_regions(void);
>   /* Marks TXT-specific memory as used to avoid its corruption. */
>   void txt_reserve_mem_regions(void);
>   
> +/* Restores original MTRR values saved by a bootloader before starting DRTM. */
> +void txt_restore_mtrrs(bool e820_verbose);
> +
>   #endif /* __ASSEMBLY__ */
>   
>   #endif /* X86_INTEL_TXT_H */
> diff --git a/xen/arch/x86/intel-txt.c b/xen/arch/x86/intel-txt.c
> index 163383b262..0c14d84486 100644
> --- a/xen/arch/x86/intel-txt.c
> +++ b/xen/arch/x86/intel-txt.c
> @@ -10,6 +10,8 @@
>   #include 
>   #include 
>   #include 
> +#include 
> +#include 
>   #include 
>   
>   static uint64_t __initdata txt_heap_base, txt_heap_size;
> @@ -111,3 +113,76 @@ void __init txt_reserve_mem_regions(void)
>                        E820_UNUSABLE);
>       BUG_ON(rc == 0);
>   }
> +
> +void __init txt_restore_mtrrs(bool e820_verbose)
> +{
> +    struct slr_entry_intel_info *intel_info;
> +    uint64_t mtrr_cap, mtrr_def, base, mask;
> +    unsigned int i;
> +    uint64_t def_type;
> +    struct mtrr_pausing_state pausing_state;
> +
> +    rdmsrl(MSR_MTRRcap, mtrr_cap);
> +    rdmsrl(MSR_MTRRdefType, mtrr_def);
> +
> +    if ( e820_verbose )
> +    {
> +        printk("MTRRs set previously for SINIT ACM:\n");
> +        printk(" MTRR cap: %"PRIx64" type: %"PRIx64"\n", mtrr_cap, mtrr_def);
> +
> +        for ( i = 0; i < (uint8_t)mtrr_cap; i++ )
> +        {
> +            rdmsrl(MSR_IA32_MTRR_PHYSBASE(i), base);
> +            rdmsrl(MSR_IA32_MTRR_PHYSMASK(i), mask);
> +
> +            printk(" MTRR[%d]: base %"PRIx64" mask %"PRIx64"\n",
> +                   i, base, mask);
> +        }
> +    }
> +
> +    intel_info = (struct slr_entry_intel_info *)
> +        slr_next_entry_by_tag(slaunch_get_slrt(), NULL, SLR_ENTRY_INTEL_INFO);
> +
> +    if ( (mtrr_cap & 0xFF) != intel_info->saved_bsp_mtrrs.mtrr_vcnt )
> +    {
> +        printk("Bootloader saved %ld MTRR values, but there should be %ld\n",
> +               intel_info->saved_bsp_mtrrs.mtrr_vcnt, mtrr_cap & 0xFF);
> +        /* Choose the smaller one to be on the safe side. */
> +        mtrr_cap = (mtrr_cap & 0xFF) > intel_info->saved_bsp_mtrrs.mtrr_vcnt ?
> +                   intel_info->saved_bsp_mtrrs.mtrr_vcnt : mtrr_cap;
> +    }
> +
> +    def_type = intel_info->saved_bsp_mtrrs.default_mem_type;
> +    pausing_state = mtrr_pause_caching();
> +
> +    for ( i = 0; i < (uint8_t)mtrr_cap; i++ )
> +    {
> +        base = intel_info->saved_bsp_mtrrs.mtrr_pair[i].mtrr_physbase;
> +        mask = intel_info->saved_bsp_mtrrs.mtrr_pair[i].mtrr_physmask;
> +        wrmsrl(MSR_IA32_MTRR_PHYSBASE(i), base);
> +        wrmsrl(MSR_IA32_MTRR_PHYSMASK(i), mask);
> +    }
> +
> +    pausing_state.def_type = def_type;
> +    mtrr_resume_caching(pausing_state);
> +
> +    if ( e820_verbose )
> +    {
> +        printk("Restored MTRRs:\n"); /* Printed by caller, mtrr_top_of_ram(). */
> +
> +        /* If MTRRs are not enabled or WB is not a default type, MTRRs won't be printed */
> +        if ( !test_bit(11, &def_type) || ((uint8_t)def_type == X86_MT_WB) )
> +        {
> +            for ( i = 0; i < (uint8_t)mtrr_cap; i++ )
> +            {
> +                rdmsrl(MSR_IA32_MTRR_PHYSBASE(i), base);
> +                rdmsrl(MSR_IA32_MTRR_PHYSMASK(i), mask);
> +                printk(" MTRR[%d]: base %"PRIx64" mask %"PRIx64"\n",
> +                       i, base, mask);
> +            }
> +        }
> +    }
> +
> +    /* Restore IA32_MISC_ENABLES */
> +    wrmsrl(MSR_IA32_MISC_ENABLE, intel_info->saved_misc_enable_msr);
> +}



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 20:48:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 20:48:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004854.1384538 (Exim 4.92)
	(envelope-from )
	id 1uMYYJ-0006IW-51; Tue, 03 Jun 2025 20:48:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004854.1384538; Tue, 03 Jun 2025 20:48:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMYYJ-0006IP-27; Tue, 03 Jun 2025 20:48:07 +0000
Received: by outflank-mailman (input) for mailman id 1004854;
 Tue, 03 Jun 2025 20:48: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 1uMYYH-0006IJ-Ks
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 20:48:05 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20618.outbound.protection.outlook.com
 [2a01:111:f403:2418::618])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0ab50794-40bc-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 22:48:02 +0200 (CEST)
Received: from SN7PR04CA0236.namprd04.prod.outlook.com (2603:10b6:806:127::31)
 by SN7PR12MB7227.namprd12.prod.outlook.com (2603:10b6:806:2aa::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.33; Tue, 3 Jun
 2025 20:47:58 +0000
Received: from SA2PEPF00003AE5.namprd02.prod.outlook.com
 (2603:10b6:806:127:cafe::9b) by SN7PR04CA0236.outlook.office365.com
 (2603:10b6:806:127::31) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.34 via Frontend Transport; Tue,
 3 Jun 2025 20:47:57 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SA2PEPF00003AE5.mail.protection.outlook.com (10.167.248.5) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Tue, 3 Jun 2025 20:47:56 +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 Jun
 2025 15:47:54 -0500
Received: from [172.31.138.29] (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 Jun 2025 15:47:53 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0ab50794-40bc-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=kqTjlKgLNsk8zRZTddCHhOpDpQ3zu6DTaFIsl3DcgdT+SLHvIE0M5nBplS8xMhEQGVfrfhGRcOg4Z5EW6311XYRHjZ1OdJ2ei1kBsG7fEFArOZPJSfYi5CSBUCrOALk6LOIO9Ks2D77jERHRQik5rx1PhBNlDnMleH73y9orMzGO90sGeQlmVt9mb7lS25CMMqFKTM10uBoLvbOJC5GWmoK2EmV99RyTE7gi3+dQxq45k02LPg9cYcrfUyF0/Q1PDFgXCfisQ5vKSDGGECQ4U9dxWE4myyC5jQeHP76kd0YNOtxNbSipQPiYSyY0D2iKO67A2dXY6kbaw7MWHKcLnw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=auvcygLBSRlC2nO2N4ZqD++PYsSu95L6zPf6TAUUoJE=;
 b=DaYKGW3Vc4syTLlA49P0iG/2BD5/TB7k/gZB3j1RjFW1Sc0BIYMxiSZxAyPTiRBHsKdFdGYvhPgQRTOtX/OWMx/FDvk/SzgRU0yPt8xwzxCdajQ9HeMMt9ZIG8AkEfCAFhm8tNJH4wR5sb7za2eKNS1BHRtZjRvHqwOmhq+h3KotyD3//t4f+AcQfBMFd54AZoF77rSAppYDgeUazgj2IoUO79DieREYs4+ae9qWLfZZ8O8BLL/amvgxFlHdYTO3CrNbDhAJpkN+FI3GhJwcUAIAZzDBM03k86JCq2Ywv/sGv5FZWsRp/F9ogl1mF0Db6QGCnBYqAbILpx4bECBRmQ==
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=auvcygLBSRlC2nO2N4ZqD++PYsSu95L6zPf6TAUUoJE=;
 b=j+I7+RJvk2nkUWrx21Hl/XADZJtdgQMadMYXlDwWQNFGsBQUryp9NUAvft2JYn4z5v9abDquw+3KRwIRYPH4LFr/AIq5J2Zl81fDe4zDt0an6F1xpIbjcfclHh+0mIr6OCliUqBHldqzNQ/Y8lY3D5hVAm0rTnZylI7e5SI/W24=
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: <198b21fd-ec37-4edd-9419-37bde034149f@amd.com>
Date: Tue, 3 Jun 2025 16:47:55 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] x86/vpci: refuse to map BARs at position 0
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
CC: Jan Beulich , Andrew Cooper
	, 
References: <20250522140356.5653-1-roger.pau@citrix.com>
 <20250522140356.5653-3-roger.pau@citrix.com>
 <3f274948-92bb-40c4-bcaf-7b538300140a@suse.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 (SATLEXMB04.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SA2PEPF00003AE5:EE_|SN7PR12MB7227:EE_
X-MS-Office365-Filtering-Correlation-Id: fb5b020f-b077-4cf0-e0c9-08dda2dfeb6d
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?VkpmMGlJamhQS3k1ZjR6SXFWSXRjWkpyc1M3YS9ueWFFQmZFT2VTMG5kcm9Z?=
 =?utf-8?B?YU0vR3dNYkdwblpscjZWV0FvOTNTVGhVcWFReHlFK2ExZUd3bHlSUmRKMCtR?=
 =?utf-8?B?WUliaGlLUEc5c3lyZFZlaDBEWHJHc3RlRk0wUVJnTk9Gd1R1eWVCTFdFL2V3?=
 =?utf-8?B?ZEp2cXpTUmQ4Z3Zuek40ekxYamJOenMxZzFOMGRtR0xaWUpwdjYrQ0d4SERV?=
 =?utf-8?B?QStvV3FNMko5OWZxNVpIMlI4YUllc09lNlNEbitQa2ZtZHNhZE96eEFjQlVE?=
 =?utf-8?B?b3p5dXFMMkpTZ1VYWnhuWmVVblkzeEF3NzRLbGIvR3ozM3kvSTc2NFRrd1BP?=
 =?utf-8?B?ZEw2OHA4U1E3S3VEK083VFRYdC91NGtqaXp4S1Bsa2lHMnZ4NGxyRjA2TlZZ?=
 =?utf-8?B?dWU5cnRjQkRTUnVLQU5yNlJyamZ6Mk91THBwVmx4dk5IaFdkMmJDaVNnZzFj?=
 =?utf-8?B?SW5RZUJldDJrb3huTC9STE5mMU1SSGJ5UndnUWxUMkk5d3FoaXl3cGdWdmp2?=
 =?utf-8?B?RXdBMnBFcXNwYlh6L0FnV25vdHA4MklKNHFNdFFRaVRycUZvb09GV2UxWG9r?=
 =?utf-8?B?TFNzT092MUtJQTE5UEV3Q21RdG4zSEg2T2NIMlM1VmQ2ZTEzVjQySXNtNWsx?=
 =?utf-8?B?UEhtTVpTS1k3ZFQweVQyaTZiRGF0REtBMjh5dlB6dHUvUU5Jc1d4UzZIYWVV?=
 =?utf-8?B?TENXbTk4aGRFd0ZzWkY1eFlmaEtFOHJYdXlCUDJjSG5BUmVHR1paZGtaUlR1?=
 =?utf-8?B?K05hWjQ2dTM4T0hLNDNISXlDaVFsd1FQMzlwZ21WbE9SbkFybWRNWFMxcUx1?=
 =?utf-8?B?NVlnNG9yKzJ0b3BpOWw0QmlKMzdKRkZ3NG9LVkZSVDRlR3VZdWI1eE1mc3Qx?=
 =?utf-8?B?QTVPOUM4N1lrdHNUL2o1dmpDSDRzbThUZ3c4RmRLcjh0dVlUOWVaaTJUWS9v?=
 =?utf-8?B?NDYvVXZFbkZ6KzZZVVRhd2NrSlBwbWxwdlpnY2EvMitCa0xYdHJLZ0JmbGJJ?=
 =?utf-8?B?UFo1KzkyZDVqZmVNY250V0hlSTE1cUxKNGM0Ry91UGgwOHltQlpBNzdBSTRF?=
 =?utf-8?B?dzZhaWs2U1RrRkRSdjNHZVJWblErTCtTdExMMXVMWlQxL1QrdmkrejNWUnIr?=
 =?utf-8?B?Qmh0UUdjVDY2WUlidFFZK2MwV3F3SnZzSWVjdEJNcGZvTU0yTWdNR3BxSUc2?=
 =?utf-8?B?d05KOCtsTmt0L2ZqaWNSa0NaUjZGaGkyMjNZbWd2VGs1Qm51dnBwZk1sUzFY?=
 =?utf-8?B?UWNNR2pubThCQ1Y5cU12T1RMbG9PYnNPKytMeW5ZZWJScU1VTjljYjk5aW8v?=
 =?utf-8?B?Uzd2aXBkN283SklRdmhQVEFwZE0xNFVFd1h2YnQ5RlBBR0FiTlMzd1lJTmJM?=
 =?utf-8?B?Zm9rcGhQSXMwTjcrME43N01WSmtzNk44QnFORjBrMXBnYVJUUG90VFdkNzJv?=
 =?utf-8?B?OGh0bWZkb1krR1l6Y3BSN2JONHhEWXlpK0VQTUV3MHdMdmZRNXNoZEZnZTB0?=
 =?utf-8?B?UURtUWpHWExYVXZUMUEyRmFFTnFGV1hRMWlWUE1MM0ZWMk9UMlVqUGs2YXdq?=
 =?utf-8?B?UnpOb0VhdkJTeHpnOUVRNlBGV2MrakFZRGEyRnJsMkhlU3hVb1FSaE5yVnlt?=
 =?utf-8?B?U3VKMDZSYmQ0dnNKbEx2YXQya3cyTThrUzhPNERGcXgyTEl3RnZVWTZjbVgz?=
 =?utf-8?B?eGVRMEt5R3NOWVZmRy95d1l2NVE2ZTNReHo2cXE2dzMzaUVuNlJWRWxydHE5?=
 =?utf-8?B?YlQzR0NVRFRjVzNUN0UzYlNuSithT2Y5SmFVNUt6M0V5d1U0MTFaZHBsOVhn?=
 =?utf-8?B?SWV5eDd6WkI3QnVPeEpLaUJJV1VKS3ZZVjRNT2NjQXFycFFnMHA1eWlMQm1R?=
 =?utf-8?B?dXFoZVZuYnlzQ3pXd0VGWmhXb2w2OFd6anBuZ3hsK3RhM1VkclhCTmVuVzNm?=
 =?utf-8?B?M29aSk1zL2N2QnhiWjNLa1YxR01MLzNHTzBRMzJPVFJhWTJPMWZjUnJ2VThP?=
 =?utf-8?B?cTBnMnZmVWsvaEdTTU80MTZkVU5wYldpUUhQcXFVcjAvKzBtVXF3TWUxSWMv?=
 =?utf-8?Q?pkSioj?=
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: 03 Jun 2025 20:47:56.7078
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: fb5b020f-b077-4cf0-e0c9-08dda2dfeb6d
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:
	SA2PEPF00003AE5.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7227

On 5/22/25 12:24, Roger Pau Monné wrote:
> On Thu, May 22, 2025 at 11:44:24AM -0400, Stewart Hildebrand wrote:
>> On 5/22/25 10:59, Jan Beulich wrote:
>>> On 22.05.2025 16:03, Roger Pau Monne wrote:
>>>> diff --git a/xen/arch/x86/pci.c b/xen/arch/x86/pci.c
>>>> index 26bb7f6a3c3a..39fd5a16a4aa 100644
>>>> --- a/xen/arch/x86/pci.c
>>>> +++ b/xen/arch/x86/pci.c
>>>> @@ -101,6 +101,15 @@ int pci_conf_write_intercept(unsigned int seg, unsigned int bdf,
>>>>  
>>>>  bool pci_check_bar(const struct pci_dev *pdev, mfn_t start, mfn_t end)
>>>>  {
>>>> +    /*
>>>> +     * Refuse to map BARs at position 0, those are not initialized.  This might
>>>> +     * be required by Linux, that can reposition BARs with memory decoding
>>>> +     * enabled.  By returning false here bar->enabled will be set to false, and
>>>> +     * bar_write() will work as expected.
>>>> +     */
>>>> +    if ( mfn_eq(start, _mfn(0)) )
>>>> +        return false;
>>>
>>> Is this really x86-specific?
>>
>> No, I think Arm would benefit from this check too. I'm in favor of
>> moving the check to common.
> 
> I think on ARM pci_check_bar() is more strict, and doesn't really need
> this check since it explicitly checks whether the BAR falls inside of
> a bridge window.
> 
> So unless you have a bridge window at mfn 0 this won't make a
> difference.  And if you have a bridge window at mfn 0 you really want
> to be able to position BARs at address 0.
> 
> Thanks, Roger.

True, but I was thinking more generally: if a BAR is not initialized,
don't map it. On Arm, it seems to be hit or miss whether BARs have been
initialized or not. I guess the difficulty lies in whether comparing to
zero is a reliable test to determine if the BAR is uninitialized.


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 21:15:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 21:15:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004876.1384548 (Exim 4.92)
	(envelope-from )
	id 1uMYzB-0001o6-DY; Tue, 03 Jun 2025 21:15:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004876.1384548; Tue, 03 Jun 2025 21:15: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 1uMYzB-0001nz-A6; Tue, 03 Jun 2025 21:15:53 +0000
Received: by outflank-mailman (input) for mailman id 1004876;
 Tue, 03 Jun 2025 21:15: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 1uMYzA-0001nt-Gg
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 21:15:52 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20610.outbound.protection.outlook.com
 [2a01:111:f403:2415::610])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ec25ab8b-40bf-11f0-b894-0df219b8e170;
 Tue, 03 Jun 2025 23:15:50 +0200 (CEST)
Received: from MN2PR05CA0060.namprd05.prod.outlook.com (2603:10b6:208:236::29)
 by CYXPR12MB9319.namprd12.prod.outlook.com (2603:10b6:930:e8::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Tue, 3 Jun
 2025 21:15:46 +0000
Received: from BN3PEPF0000B070.namprd21.prod.outlook.com
 (2603:10b6:208:236:cafe::5d) by MN2PR05CA0060.outlook.office365.com
 (2603:10b6:208:236::29) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Tue,
 3 Jun 2025 21:15:46 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BN3PEPF0000B070.mail.protection.outlook.com (10.167.243.75) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.2 via Frontend Transport; Tue, 3 Jun 2025 21:15:45 +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, 3 Jun
 2025 16:15:45 -0500
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 Jun
 2025 16:15:44 -0500
Received: from [172.31.138.29] (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 Jun 2025 16:15:43 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ec25ab8b-40bf-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=muK2pcBZq09aYFDifC8PheJY3nhaaIrneE6lcdJxts251i2Xt8iU5hWl9J9arghHdgvr+u7qF/xWR7ey8f+MDsf8HGO3Co8rAPw/dbuI0OuVMM0Pp+QR/rtwSxif3daHoMW4snbDYU4PciZwWr8g7qgZLh392/WjdqhTwt6Saqvpxf8wi4AvpD7htU0eamRskXhKD2twH9G+gvF1iBGxdIx77G4MAE5d8v54lilvJ2tblU8ddTxNWR/Q1xRnnaXUMtSdXGt633/6lnv4wvnKFLSMal8IZScFjq+/LwphC8nX5MlR5kRI6J1NHITPVfKxGIk0HzWAlcLQQsVssgk4PA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=4o2Osna6pU0Zg0E8eP+DfN2HnDAwcfSnKy8HLh5fBaE=;
 b=R7iArKJpHP3FuphU3AS3OHUfDsGGl2IIRZGNDSxv5CRfO9a1oYpzni3PaMmEIY0vZ0o2qGq7BdjfMccoQNcl56aWJi+077+1a2m/I3p4eZFL30V6hf5wTwx8ofqFIc7nvLnV4CfMN2kpQLIWcfQoBYXDkYcX49hB2p6jGxguO3r6X1sIHKy+paXEHVn4yQQDN0xyJXz5E16KMF8q9M5g7MA9F/DHw2SnIZNrvX6H7VXp09Qo9QlFOm/POYW4EqWq+q6W+SFpL3DKk1/exD58yq8N5jg7dxGd9pyoZbY8lEOWrNQhJ2vu2QDauaVb7inArwfuHRDXblEoIJ3SKuVVmg==
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=4o2Osna6pU0Zg0E8eP+DfN2HnDAwcfSnKy8HLh5fBaE=;
 b=ZTk+Mn2jrygl78OpRchmO5yWglDrwRe5GEUHI75xdcbWi7yoHiBSxZsPqxuEvvG6F5G+T/ZAUZq9VBJ44FCCvzI9wzHPRMPqgDU3N/svU+NLKDRmglhB2xEEzjjRinGgJrl+OTemgB3xsSbQmYL4wCe/CMekqmnT0WfxvJ1ZHv0=
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: <4bd41362-6ee4-44d7-9f9b-0ffd78f1e6f8@amd.com>
Date: Tue, 3 Jun 2025 17:15:45 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/2] xen/arm: exclude xen,reg from direct-map domU
 extended regions
To: "Orzel, Michal" , 
CC: Stefano Stabellini , Julien Grall
	, Bertrand Marquis , "Volodymyr
 Babchuk" , Andrew Cooper
	, Anthony PERARD , "Jan
 Beulich" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	
References: <20250513195452.699600-1-stewart.hildebrand@amd.com>
 <20250513195452.699600-2-stewart.hildebrand@amd.com>
 <54c3d341-1d7f-428d-89a7-ce4fcae8a5db@amd.com>
Content-Language: en-US
From: Stewart Hildebrand 
In-Reply-To: <54c3d341-1d7f-428d-89a7-ce4fcae8a5db@amd.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN3PEPF0000B070:EE_|CYXPR12MB9319:EE_
X-MS-Office365-Filtering-Correlation-Id: d554ecf8-2784-4c0a-48e1-08dda2e3ce03
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?MDRPdlVHcDRxZkg2WXpkNjFwcDBTd0dQN2lFRmlpdlpWSzJtbUZQVU1xd093?=
 =?utf-8?B?T2E1RHZaT0p0QnRlcndoVW1CUko3b2RweGtaM1hZYXhUcHp5NnRGZlFUelJF?=
 =?utf-8?B?d1NBcVFuMWY5U2U0ZERMa211bTFvWS9uM2Y5RzJGVnVvdkMxT3hVWThBRXNx?=
 =?utf-8?B?VjJZaDM4NG05UklaTW1pc1IvaGdUUmlsL0hrSFQvaDUwTGNad3Fzck94dkFX?=
 =?utf-8?B?Zkc2ZGRUMmlQa2RmNjdyWnpiTDlvaW9CUjMvZ0szZUFndE1PNndCT25JR0po?=
 =?utf-8?B?LzZ3d1dZUlhXN0pFU3NBZTdhcjBJWXhlK1VoZHZaUEQzL1V0N3lsbGxjRTl6?=
 =?utf-8?B?aWgxSzVsdUpLRnJRbEFjZkN2aGFyVlYvWDZDNS9wUHdIL0h6YnN0V041anAw?=
 =?utf-8?B?MXdvK1B5b2Jra3RweHh2S3F4NEE4NmhNR1lZTFBMSlk0bTNqUG4zR3dPVFd1?=
 =?utf-8?B?a2JlRmxUK01BNi9KbmxvazB2Ly9tcTR3d3FFa29RcHIvZEFKYmNrUmlIeGpW?=
 =?utf-8?B?TWk3RTE0SG52WVM1dDFyUzBvSFlaZWVpNFhZM3FmaVBGU1pwYkNzUGwwOVJI?=
 =?utf-8?B?MmFBVmtidTcvRXM1aGhLS0czT3haN0lZaDZ5dHBpYTNQR1M2eHJVdGRrS2h3?=
 =?utf-8?B?OUo4ZmRwLy9FekVQaXhpT3ByTTgxZ1BVTEo3ays0MTk4RGYzZGM1SytYZWxs?=
 =?utf-8?B?YVMyQndGemxOaFFVRDh1emd6L1lmbm9rTE5SK1lCQkhuK1ZhVjIzNFJxa3pW?=
 =?utf-8?B?N1F2Y2g1aDZFTENnV1lOSnduYVRSNk1hV0xUdm9kNkhqU3p5d3RFeXRzVUVi?=
 =?utf-8?B?RDF6MkpBR0dqcU1sZzdjc1dIQmRCMmFNYTRuUDhodVpUWWcxWWhxV0NaMkJx?=
 =?utf-8?B?TWFkN1BQNWM4YndXWWVFdHM5WkdSZE5oQ09aVEI2LzNrQ0hTYzc5RWFyRm1t?=
 =?utf-8?B?NEg2ajZlTXMzb2h2ZVhub2h3N1V4eFg1YkZPTExydXdqS1FwMnBEWDhvMUhm?=
 =?utf-8?B?NXRNVGlPTG9GTWZQMEt3eUdSWUdYRkt5ZE1RWHJiUmUvdzBwdW41SzRieWVE?=
 =?utf-8?B?bnppVERJWEY4VkZUWUF4REk1dWRsbW1DT1k1SkV3aFE1QzBJRUhGVEpZdWdI?=
 =?utf-8?B?TGMrWGJIZy9oYWt3M2Z4QzBnTFJBTTl5eEl5Vmx6QmpJVTNvMHNCZkgrQ2Vx?=
 =?utf-8?B?L2ZFMEJDVWNCVzRkOWNEd1IvVTAza0Q3dEgrME8zVTVIandWR0VQVnBWcVdH?=
 =?utf-8?B?MllUQnhsSjhUMzlKL0VMUWM5cHRmUWI2R2R4d1RNN3dobVVtYVcySXcwRWJG?=
 =?utf-8?B?Znd3Ni8zMndaZEF0SmppeXlBSVZPWExOWXd6d0tFTkNlV09KaEJISklRR20v?=
 =?utf-8?B?MEtxWkVhVFVCUFM2ZzZwN004aFdrYnlSVHZ0ZXNzbm9LU0tzbXMwZ2o4SEYr?=
 =?utf-8?B?cUdQZ3hEdXpvMWtpVDk2WTRLTW9rWUN0M085TGI2RlBDWitubkJxSjBRRzJ2?=
 =?utf-8?B?ZlBnYVVnSEFHNUZSdVJyUFJ2ZGJ2ZEFtYVVGeUdFV1MzdzU4NElzNCtTQTVh?=
 =?utf-8?B?Wm9aY0RpZnlQRnBCcUNrVXhXUStxa2xrV1dYaFFjVXprbzdlalZ3eDRtQzZR?=
 =?utf-8?B?akE5eUZhb3NmdmY3Y2FkaEZXYjZGWHQvckFBOXpDQzIyRW81aVlZWlZIVldC?=
 =?utf-8?B?ZkFGNXFaakNBK2dNaFlaSlJLWkUvRVkwU244eU83bzA5bDFQNHFnTDA1bUk5?=
 =?utf-8?B?TFVlYTZvd3h3S0Ztc1JvQTQ5NmlIN3g5YUhpSCtHUThNNzZwblBlYTRaQXNr?=
 =?utf-8?B?OGJxZ3BHc0oxU3BoR0IwcVdWWWUvVTFDZTVTWUdIMWpibDR2SzdlQ1F2ZGdS?=
 =?utf-8?B?ZThRQjE1VGlrT0cwNXg3TTlEQm0wcndXdEZCM3BKMStRRmtoRXM0WE9ITjZF?=
 =?utf-8?B?TnNEK0s2dGxYSE5vQTRBK0lXbTlLa1lnUzF6YWdHUXlYd1RCd1lueDBYSFZD?=
 =?utf-8?B?VXJCMlp0Uzl3TS9YRllSUmNGOVhsSVZpSmdpcCtSeXhOYWpMcngyZCtWR0VI?=
 =?utf-8?Q?kQUsxI?=
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: 03 Jun 2025 21:15:45.3641
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d554ecf8-2784-4c0a-48e1-08dda2e3ce03
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:
	BN3PEPF0000B070.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYXPR12MB9319

On 5/14/25 03:31, Orzel, Michal wrote:
> On 13/05/2025 21:54, Stewart Hildebrand wrote:
>> Similarly to fba1b0974dd8, when a device is passed through to a
>> direct-map dom0less domU, the xen,reg ranges may overlap with the
>> extended regions. Remove xen,reg from direct-map domU extended regions.
>>
>> Introduce rangeset_count_ranges().
>>
>> Take the opportunity to update the comment ahead of find_memory_holes().
>>
>> Signed-off-by: Stewart Hildebrand 
>> ---
>> v2->v3:
>> * new patch
>> ---
>>  xen/arch/arm/domain_build.c | 57 +++++++++++++++++++++++++++++++++----
>>  xen/common/rangeset.c       | 14 +++++++++
>>  xen/include/xen/rangeset.h  |  2 ++
>>  3 files changed, 68 insertions(+), 5 deletions(-)
>>
>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> index b189a7cfae9f..3cdf5839bc98 100644
>> --- a/xen/arch/arm/domain_build.c
>> +++ b/xen/arch/arm/domain_build.c
>> @@ -824,15 +824,17 @@ static int __init handle_pci_range(const struct dt_device_node *dev,
>>  }
>>  
>>  /*
>> - * Find the holes in the Host DT which can be exposed to Dom0 as extended
>> - * regions for the special memory mappings. In order to calculate regions
>> - * we exclude every addressable memory region described by "reg" and "ranges"
>> - * properties from the maximum possible addressable physical memory range:
>> + * Find the holes in the Host DT which can be exposed to Dom0 or a direct-map
>> + * domU as extended regions for the special memory mappings. In order to
>> + * calculate regions we exclude every addressable memory region described by
>> + * "reg" and "ranges" properties from the maximum possible addressable physical
>> + * memory range:
>>   * - MMIO
>>   * - Host RAM
>>   * - PCI aperture
>>   * - Static shared memory regions, which are described by special property
>>   *   "xen,shared-mem"
>> + * - xen,reg mappings
>>   */
>>  static int __init find_memory_holes(const struct kernel_info *kinfo,
>>                                      struct membanks *ext_regions)
>> @@ -914,6 +916,13 @@ static int __init find_memory_holes(const struct kernel_info *kinfo,
>>          }
>>      }
>>  
>> +    if ( kinfo->xen_reg_assigned )
>> +    {
>> +        res = rangeset_subtract(mem_holes, kinfo->xen_reg_assigned);
>> +        if ( res )
>> +            goto out;
>> +    }
>> +
>>      start = 0;
>>      end = (1ULL << p2m_ipa_bits) - 1;
>>      res = rangeset_report_ranges(mem_holes, PFN_DOWN(start), PFN_DOWN(end),
>> @@ -994,11 +1003,30 @@ static int __init find_domU_holes(const struct kernel_info *kinfo,
>>      return res;
>>  }
>>  
>> +static int __init rangeset_to_membank(unsigned long s_gfn, unsigned long e_gfn,
>> +                                      void *data)
>> +{
>> +    struct membanks *membank = data;
>> +    paddr_t s = pfn_to_paddr(s_gfn);
>> +    paddr_t e = pfn_to_paddr(e_gfn + 1) - 1;
>> +
>> +    if ( membank->nr_banks >= membank->max_banks )
>> +        return 0;
>> +
>> +    membank->bank[membank->nr_banks].start = s;
>> +    membank->bank[membank->nr_banks].size = e - s + 1;
>> +    membank->nr_banks++;
>> +
>> +    return 0;
>> +}
>> +
>>  static int __init find_host_extended_regions(const struct kernel_info *kinfo,
>>                                               struct membanks *ext_regions)
>>  {
>>      int res;
>>      struct membanks *gnttab = membanks_xzalloc(1, MEMORY);
>> +    struct membanks *xen_reg = membanks_xzalloc(
>> +        max(1, rangeset_count_ranges(kinfo->xen_reg_assigned)), MEMORY);
> You allocate at least 1 membank even though xen_reg_assigned may be empty because:
>  - this function is called for hwdom - no xen,reg
>  - there may be no xen,reg i.e. no passthrough

Ah, sorry, there's no need to allocate at least 1. This can just be:

    struct membanks *xen_reg = membanks_xzalloc(
        rangeset_count_ranges(kinfo->arch.xen_reg_assigned), MEMORY);



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 21:49:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 21:49:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004893.1384558 (Exim 4.92)
	(envelope-from )
	id 1uMZVP-0005pF-RB; Tue, 03 Jun 2025 21:49:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004893.1384558; Tue, 03 Jun 2025 21:49: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 1uMZVP-0005p8-NT; Tue, 03 Jun 2025 21:49:11 +0000
Received: by outflank-mailman (input) for mailman id 1004893;
 Tue, 03 Jun 2025 21:49: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 1uMZVO-0005p2-PD
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 21:49:10 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 93545a34-40c4-11f0-a300-13f23c93f187;
 Tue, 03 Jun 2025 23:49:08 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 4CA4760010;
 Tue,  3 Jun 2025 21:49:07 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1A762C4CEFF;
 Tue,  3 Jun 2025 21:49: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: 93545a34-40c4-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748987347;
	bh=1higfkYZ5kOwALN6KpDH6l2jnbygdxuOYha2B+9PiAM=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=cxfo/vhWpdfrvTxzbZIgHhgFCwdwu1c/CdE/rk2dEgKhJkhCGHpa9mB7tLJwyG5MU
	 Tk9phaNFvHjE1ZRaRkLwBrGmfXlRLmThbk9FnZjyPDTljrDF7nrJF7ihF0ddV/8Idx
	 yDK3JLK8spULJUK3qr03FysSilrcNF0UT0NQIrGpHubdRgT3gSmQ5m3CcXlW5oLnGx
	 8/2luDs5QWtSv+pCZ3NlZX6el2ZBMP/YCZ8BSdcb0aX3hAEKLazigsSFDvaWvVvOFo
	 wZgto+gwn/YFe/Okj6vzOy+JGwodjPHsnSKszAfE8VCymiu6NaJQ+5t+KmzEeZWIkN
	 PhAuxAVb6Q8uA==
Date: Tue, 3 Jun 2025 14:49:05 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
cc: Stefano Stabellini , 
    Anthony PERARD , 
    Andrew Cooper , xen-devel@lists.xenproject.org, 
    Anthony PERARD , 
    Doug Goldstein 
Subject: Re: [XEN PATCH 8/9] CI: Workaround extra content in junit
In-Reply-To: 
Message-ID: 
References: <20250603124222.52057-1-anthony@xenproject.org> <20250603124222.52057-9-anthony@xenproject.org> <86d3655f-f541-441e-bb6c-1dda0b03540f@citrix.com>  
 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1740808301-1748987347=:2495561"

  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-1740808301-1748987347=:2495561
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Tue, 3 Jun 2025, Marek Marczykowski-Górecki wrote:
> On Tue, Jun 03, 2025 at 11:29:11AM -0700, Stefano Stabellini wrote:
> > On Tue, 3 Jun 2025, Anthony PERARD wrote:
> > > On Tue, Jun 03, 2025 at 03:12:32PM +0100, Andrew Cooper wrote:
> > > > On 03/06/2025 1:42 pm, Anthony PERARD wrote:
> > > > >  if [ -n "$retrieve_xml" ]; then
> > > > >      nc -w 10 "$SUT_ADDR" 8080 > tests-junit.xml  > > > > +    # Workaround duplicated data been received
> > > > > +    sed -i.old '/^<\/testsuites>/q' tests-junit.xml > /dev/null
> > > > > +    extra_line_in_junit=$(($(wc -l < tests-junit.xml.old) - $(wc -l < tests-junit.xml)))
> > > > > +    if [ $extra_line_in_junit -gt 0 ]; then
> > > > > +        echo "WARNING: Found $extra_line_in_junit too many lines in junit."
> > > > > +    fi
> > > > 
> > > > Is this the cause of
> > > > https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1849342222/test_report
> > > > getting a row of 0's for ADL ?
> > > 
> > > Well, the error I had was this one:
> > > "FATAL: Extra content at the end of the document"
> > > https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1848598740/test_report
> > > 
> > > And indeed, when I managed to dl the junit.xml, there were the end of
> > > the document duplicated many times.
> > 
> > Wouldn't it better to do |sort|uniq to dedup the file?
> 
> I don't think XML structure will survive it...

Ops, good point.
--8323329-1740808301-1748987347=:2495561--


From xen-devel-bounces@lists.xenproject.org Tue Jun 03 21:51:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 21:51:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004901.1384568 (Exim 4.92)
	(envelope-from )
	id 1uMZY0-0007Pk-7R; Tue, 03 Jun 2025 21:51:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004901.1384568; Tue, 03 Jun 2025 21:51: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 1uMZY0-0007Pd-3C; Tue, 03 Jun 2025 21:51:52 +0000
Received: by outflank-mailman (input) for mailman id 1004901;
 Tue, 03 Jun 2025 21:51:50 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uMZXy-0007PB-Cc
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 21:51:50 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uMZXx-000PVm-21;
 Tue, 03 Jun 2025 21:51:49 +0000
Received: from [2a02:8012:3a1:0:7807:532b:1d1d:b850]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uMZXx-009HNV-2n;
 Tue, 03 Jun 2025 21:51: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=/zCMXzXitlxIkhkPk26k31uDHOdETnhHZJief7dFn4s=; b=rszt4uV/QZ9bAnPlMUOD72IwHU
	UmYZ5zg5k7JTok6aZNknbJ0QMGaq90aV0uEbEG44KYLNViIrAlTce19uhXYjpFZ5Ht/EyB+/McMDa
	MKgv8R+Qm06O5GZFyztLscQHaxthd1K1EPQ+M5kyAP99LqW0/pgRPKSi4pkIt8CVJCb4=;
Message-ID: <33786bb2-9c4f-47f3-8962-83662f658392@xen.org>
Date: Tue, 3 Jun 2025 22:51:45 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 1/5] xen/arm: Add way to disable traps on accesses to
 unmapped addresses
Content-Language: en-GB
To: "Edgar E. Iglesias" ,
 xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org, bertrand.marquis@arm.com, michal.orzel@amd.com,
 Volodymyr_Babchuk@epam.com, andrew.cooper3@citrix.com,
 edgar.iglesias@amd.com, Anthony PERARD ,
 Juergen Gross , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20250603144948.1685047-1-edgar.iglesias@gmail.com>
 <20250603144948.1685047-2-edgar.iglesias@gmail.com>
From: Julien Grall 
In-Reply-To: <20250603144948.1685047-2-edgar.iglesias@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Edgar,

On 03/06/2025 15:49, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias" 
> 
> Add a per-domain way to optionally disable traps for accesses
> to unmapped addresses.
> 
> The domain flag is general but it's only implemented for Arm for now.
> 
> Reviewed-by: Stefano Stabellini 
> Signed-off-by: Edgar E. Iglesias 

For the future, tags should be ordered chronogically. So the 
Signed-off-by should be first, then reviewed-by...

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 21:53:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 21:53:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004912.1384578 (Exim 4.92)
	(envelope-from )
	id 1uMZZH-0007vi-Fc; Tue, 03 Jun 2025 21:53:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004912.1384578; Tue, 03 Jun 2025 21:53:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMZZH-0007vb-DB; Tue, 03 Jun 2025 21:53:11 +0000
Received: by outflank-mailman (input) for mailman id 1004912;
 Tue, 03 Jun 2025 21:53:09 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uMZZF-0007vR-Cl
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 21:53:09 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uMZZF-000PXk-02;
 Tue, 03 Jun 2025 21:53:09 +0000
Received: from [2a02:8012:3a1:0:7807:532b:1d1d:b850]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uMZZF-009HTy-0y;
 Tue, 03 Jun 2025 21:53:08 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
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=ZbAGSy41kFbcj3x6f03D0CDbPKm+J0fC6Gg03ennvME=; b=KzpG1WiGrx/L7gJC7zdMMeirbq
	s9XnV5ULGnRi2NKEHTji6ZFesrzye/Ub07brgR3eDyeSzhMGa5P6G+V5a4qE82RMP2HnP93uBXBUv
	P0cKOe8ICO9Exy+QObWjqVhhRNmHMUBFMpBLmmI9KNkL/UqHYKZwsq7XZm6i920a2BLs=;
Message-ID: <44fd7458-bd29-44a4-b3c7-71f15732e004@xen.org>
Date: Tue, 3 Jun 2025 22:53:04 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/kernel: Move parse_params() back into __init
Content-Language: en-GB
To: Andrew Cooper ,
 Xen-devel 
Cc: Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini 
References: <20250603125215.2716132-1-andrew.cooper3@citrix.com>
From: Julien Grall 
In-Reply-To: <20250603125215.2716132-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Andrew,

On 03/06/2025 13:52, Andrew Cooper wrote:
> It's non-init caller was dropped in Xen 4.14
> 
> No functional change.
> 
> Fixes: 02e9a9cf2095 ("xen: remove XEN_SYSCTL_set_parameter support")
> Signed-off-by: Andrew Cooper 

Acked-by: Julien Grall 

Cheers,

> ---
> CC: Anthony PERARD 
> CC: Michal Orzel 
> CC: Jan Beulich 
> CC: Julien Grall 
> CC: Roger Pau Monné 
> CC: Stefano Stabellini 
> 
> Found while reviewing the lockdown series, where an __init callee was added.
> 
> It appears that GCC has inlined it into it's single caller (which is __init),
> and not emitted a non-__init form.
> ---
>   xen/common/kernel.c | 5 +++--
>   1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/common/kernel.c b/xen/common/kernel.c
> index 8b63ca55f14f..5be668ba855a 100644
> --- a/xen/common/kernel.c
> +++ b/xen/common/kernel.c
> @@ -67,8 +67,9 @@ static int assign_integer_param(const struct kernel_param *param, uint64_t val)
>       return 0;
>   }
>   
> -static int parse_params(const char *cmdline, const struct kernel_param *start,
> -                        const struct kernel_param *end)
> +static int __init parse_params(
> +    const char *cmdline, const struct kernel_param *start,
> +    const struct kernel_param *end)
>   {
>       char opt[MAX_PARAM_SIZE], *optval, *optkey, *q;
>       const char *p = cmdline, *key;
> 
> base-commit: 2c4a3d688943b2034756859844b8337a5a97ce07

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 23:00:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 23:00:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004935.1384588 (Exim 4.92)
	(envelope-from )
	id 1uMacP-0008Bf-A6; Tue, 03 Jun 2025 23:00:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004935.1384588; Tue, 03 Jun 2025 23:00:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMacP-0008BY-6a; Tue, 03 Jun 2025 23:00:29 +0000
Received: by outflank-mailman (input) for mailman id 1004935;
 Tue, 03 Jun 2025 23:00:28 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uMacO-0008BS-IG
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 23:00:28 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uMacO-000R5i-0M;
 Tue, 03 Jun 2025 23:00:28 +0000
Received: from [2a02:8012:3a1:0:7807:532b:1d1d:b850]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uMacO-009wnI-0c;
 Tue, 03 Jun 2025 23:00: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=5DfUmcGB0M7LIleky9dThIr14kX51+jSAz9lKoqmbx0=; b=WtR4nFoUJOdRgq7jxPtmD/R2Br
	fVir5qRqdQMfg6Xnll4oL+pbSfhXgHhvFOeG64OIerzNWqIozIOGVcVyGZfau9Hf2ocCyMz2T2ar7
	5RNENTVJYgqM7FRdhgntJF1BERb73uFd4X8SADKlAVL5LupibmVLopKYi3PCiVixmTX4=;
Message-ID: 
Date: Wed, 4 Jun 2025 00:00:25 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4][PART 1 2/4] xen/arm: Implement PSCI SYSTEM_SUSPEND
 call for guests
Content-Language: en-GB
To: Mykola Kvach , xen-devel@lists.xenproject.org
Cc: Mykola Kvach ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: 
 <1a8313537603bee36636b0fcd2fdc2f76a2374fb.1748337249.git.mykola_kvach@epam.com>
From: Julien Grall 
In-Reply-To: <1a8313537603bee36636b0fcd2fdc2f76a2374fb.1748337249.git.mykola_kvach@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Mykola,

On 27/05/2025 10:18, Mykola Kvach wrote:
> From: Mykola Kvach 
> 
> This patch adds support for the PSCI SYSTEM_SUSPEND function in the vPSCI
> (virtual PSCI) interface, allowing guests to request suspend via the PSCI
> v1.0 SYSTEM_SUSPEND call (both 32-bit and 64-bit variants).
> 
> The implementation:
> - Adds SYSTEM_SUSPEND function IDs to PSCI definitions
> - Implements trapping and handling of SYSTEM_SUSPEND in vPSCI
> - Allows only non-hardware domains to invoke SYSTEM_SUSPEND; for the
>    hardware domain, PSCI_NOT_SUPPORTED is returned to avoid halting the
>    system in hwdom_shutdown() called from domain_shutdown
> - Ensures all secondary VCPUs of the calling domain are offline before
>    allowing suspend due to PSCI spec
> - Treats suspend as a "standby" operation: the domain is shut down with
>    SHUTDOWN_suspend, and resumes execution at the instruction following
>    the call

Looking at the specification, I am still not convinced you can implement 
PSCI SUSPEND as a NOP. For instance, in the section "5.1.19 
SYSTEM_SUSPEND", the wording implies the call cannot return when it is 
successul.

I understand that 5.20.2 ("Caller reponsabilities" for SYSTEM_SUSPEND) 
suggests the caller should apply all the rules from 5.4 ("Caller 
responsabilties" for CPU_SUSPEND), but it is also mentioned that 
SYSTEM_SUSPEND behave as the deepest power down state.

So I don't think standby is an option. I would like an opinion from the 
other maintainers.

> +static int32_t do_psci_1_0_system_suspend(register_t epoint, register_t cid)
 > +{> +    struct vcpu *v;
> +    struct domain *d = current->domain;
> +
> +    /* Drop this check once SYSTEM_SUSPEND is supported in hardware domain */
> +    if ( is_hardware_domain(d) )
> +        return PSCI_NOT_SUPPORTED;
> +
> +    /* Ensure that all CPUs other than the calling one are offline */
> +    for_each_vcpu ( d, v )
> +    {
> +        if ( v != current && is_vcpu_online(v) )

I think this is racy because you can still turn on a vCPU afterwards 
from a vCPU you haven't checked.

Did you add this check just to follow the specification, or is there any 
other problem in Xen?

> +            return PSCI_DENIED;
 > +    }> +
> +    /*
> +     * System suspend requests are treated as performing standby
> +     * as this simplifies Xen implementation.
> +     *
> +     * Arm Power State Coordination Interface (DEN0022F.b)

This comment is a bit too verbose. There is no need to copy/paste the 
specification. You can just write a couple of sentence with link to the 
specification.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Tue Jun 03 23:56:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jun 2025 23:56:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004961.1384597 (Exim 4.92)
	(envelope-from )
	id 1uMbUh-00064d-A2; Tue, 03 Jun 2025 23:56:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004961.1384597; Tue, 03 Jun 2025 23:56: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 1uMbUh-00064W-7V; Tue, 03 Jun 2025 23:56:35 +0000
Received: by outflank-mailman (input) for mailman id 1004961;
 Tue, 03 Jun 2025 23:56: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 1uMbUf-00064Q-QO
 for xen-devel@lists.xenproject.org; Tue, 03 Jun 2025 23:56:33 +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 5f6467b3-40d6-11f0-a300-13f23c93f187;
 Wed, 04 Jun 2025 01:56:31 +0200 (CEST)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-451ebd3d149so8877445e9.2
 for ; Tue, 03 Jun 2025 16:56:31 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-450d7fb0467sm178723325e9.19.2025.06.03.16.56.29
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 03 Jun 2025 16:56:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5f6467b3-40d6-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748994991; x=1749599791; 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=pODLuhqUvl+9jztQ6zVDSplRxKL2WIWuXC+a3efJm9g=;
        b=nmewkGQahYU1B26of2Ie3D++1082Nung5k077P4PjAtbmb+ImqQjOGEdqHJNvJmcms
         DzusykjH+eB3m2h378QeO69WiZeBVKFIfdrJAGcrb5EPp7VZCTWSdEeDwW+/nhdglIE2
         gjVBB4X0vkApVmPThL4ZQkcPQbLTZazLNNKl4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748994991; x=1749599791;
        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=pODLuhqUvl+9jztQ6zVDSplRxKL2WIWuXC+a3efJm9g=;
        b=rDrtnshpJukTp8gNPtmjcQIwl9wjtcSZoANCdIfYG/8+QJbkeyrHrCixGFHwdZltTh
         jR/y45k4k9b16864gmoBqAqC35aqy05++ssFGI50xa8bMi1K+JoGYxfhoXRYQ3qPHtJP
         FdvJvRSWdy3Q5YvMu7+MH5r4ARam7lgXF6BHVTpmi5coaUftpe9dnEUgEDaHVT3x7yIW
         0o/zIYxVUO2h5dG01xVXWij99M7u11fmzKGCvO+F7gRTpiZxUp2JkBDGeI2eZzoJVNsR
         63Q927cjB519IkvGS3ZpjI1SGmJpL0tyieTgRbnAmo4CadE8UZ0IkQAwph69mFzydnWX
         tTsg==
X-Gm-Message-State: AOJu0YwuUUoCzQpU9XV3L3m4gHSrRjAohtAxes6ZMzlmfxCslal6IYhv
	P+OZuQPm74AQOHY5zIuRq0BCcAnuGXHeOv1P3XeMcJmnzgmKo2GNix3Ev4PVm3gMbDghalb068o
	kSw+M
X-Gm-Gg: ASbGncuCgXCERIk7Gw3fUIbiU4g2boZZhcH+gZHOu5Ortje2Ahn0eeiPifH1MHv4sD+
	gJ9TxID32ecEiCX6HIF3XkEdbuiG33uJizRehKs7kNH5ColP2p1WY/U+DDJPROzw7tCeQxkxijs
	0kgd0D66A2LzcIwErOe0/FVTy3/4ZHf0ziBRqQDOPQ/G9CQGMDJO3fkqoNGVOYvNQyJ3tN9cR4u
	raPrDsVVpRnfi8ThEfVY3eX7ZX+V0NKTP2CdtSsTwPc9KEh2MoxvplYk3xY6PAoszA+BY02wxBn
	8s2Q8DMhTZFJqwXCC4djMWjZluhW2IYxH/fKLd2/CkfLLllYRDpHSjogHIRVBhprLJQ02Y0yWcd
	uzUq3Ix4ptr+9MrKvz5sahmlwodeL/ulJsUQ=
X-Google-Smtp-Source: AGHT+IEYkIt5cApoydTDEeGe6Eamjf/vu4yo0zzuizQAvi7VqToTNX+2Q+5yW+W6wrr76H7m/o3QRQ==
X-Received: by 2002:a5d:584a:0:b0:3a4:eecf:99af with SMTP id ffacd0b85a97d-3a51d9748c4mr416413f8f.44.1748994990974;
        Tue, 03 Jun 2025 16:56:30 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH] x86/boot: Fix domain_cmdline_size()
Date: Wed,  4 Jun 2025 00:56:28 +0100
Message-Id: <20250603235628.2750156-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

The early exit from domain_cmdline_size() is buggy.  Even if there's no
bootloader cmdline and no kextra, there still might be Xen parameters to
forward, and therefore a nonzero cmdline.

Explain what the function is doing, and rewrite it to be both more legible and
more extendible.

Fixes: 142f0a43a15a ("x86/boot: add cmdline to struct boot_domain")
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 

And just to demonstrate how bad ternary operators are when they're not used
over trivial scalars, this "no effective change in logic" still saves most of
a cacheline of logic:

  add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-56 (-56)
  Function                                     old     new   delta
  __start_xen                                 8946    8890     -56

The "if ( cmdline_size )" in create_dom0() could be dropped.  It's impossible
to be 0 now, which is correct behaviour.  But, that should be deferred to a
later change.
---
 xen/arch/x86/setup.c | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 1f5cb67bd0ee..d47b99f1b2c9 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -980,15 +980,22 @@ static unsigned int __init copy_bios_e820(struct e820entry *map, unsigned int li
     return n;
 }
 
+/*
+ * Calculate the maximum possible size of the dom0 cmdline.  Pieces of the
+ * dom0 cmdline optionally come from the bootloader directly, from Xen's
+ * cmdline (following " -- "), and individual Xen parameters are forwarded
+ * too.
+ */
 static size_t __init domain_cmdline_size(const struct boot_info *bi,
                                          const struct boot_domain *bd)
 {
-    size_t s = bi->kextra ? strlen(bi->kextra) : 0;
+    size_t s = 0;
 
-    s += bd->kernel->cmdline_pa ? strlen(__va(bd->kernel->cmdline_pa)) : 0;
+    if ( bd->kernel->cmdline_pa )
+        s += strlen(__va(bd->kernel->cmdline_pa));
 
-    if ( s == 0 )
-        return s;
+    if ( bi->kextra )
+        s += strlen(bi->kextra);
 
     /*
      * Certain parameters from the Xen command line may be added to the dom0

base-commit: 2c4a3d688943b2034756859844b8337a5a97ce07
prerequisite-patch-id: 32a8746877e6b92075be2f022dca25c6bfa6f31e
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Wed Jun 04 01:11:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 01:11:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1004994.1384608 (Exim 4.92)
	(envelope-from )
	id 1uMcfG-0006oR-Ns; Wed, 04 Jun 2025 01:11:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1004994.1384608; Wed, 04 Jun 2025 01:11: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 1uMcfG-0006oK-Kf; Wed, 04 Jun 2025 01:11:34 +0000
Received: by outflank-mailman (input) for mailman id 1004994;
 Wed, 04 Jun 2025 01:11: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 1uMcfE-0006oE-SK
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 01:11:32 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org
 [2600:3c0a:e001:78e:0:1991:8:25])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d855a85d-40e0-11f0-a300-13f23c93f187;
 Wed, 04 Jun 2025 03:11:30 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id DAA204419F;
 Wed,  4 Jun 2025 01:11:28 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 66208C4CEED;
 Wed,  4 Jun 2025 01:11:27 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d855a85d-40e0-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748999488;
	bh=0LANvjNKYi3ekDv4nxB1reNihHSyLjryMxfmaUPKeao=;
	h=Date:From:To:cc:Subject:From;
	b=r3fJ/KCC0B2aghuY9oBFg6p0thtORSSDXHz2JcSZE1K9emzej6T9CiSO/JJ1DmQ8v
	 DHO1c5MWdMKBm5pBB37mLlxAZxroKL/MQTPgueKxTGRwQJOPPCz6HMb4g16KkhAqy/
	 eY0PahzCVPs4k043NVa2myXpzO302QDefMmE2DXjHrIW79UxXBl5cpmbrPhOKSU6Nc
	 k8IOCpsy8E+XMoqjArddIkjTTlftmm6NKHfiPc5vfrO1BDDBCNeDWOo8t49dMtAi3j
	 UC2SGUKQwggzqF2bsP/XhvydMDUyrOhy4xxPJHqgVs5l/6n0ufeMZAw7UK62S+Zryd
	 ARQITw6jTYDUw==
Date: Tue, 3 Jun 2025 18:11:26 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: xen-devel@lists.xenproject.org
cc: Andrew Cooper , 
    Stefano Stabellini , michal.orzel@amd.com, 
    jbeulich@suse.com, julien@xen.org, roger.pau@citrix.com, 
    sstabellini@kernel.org, bertrand.marquis@arm.com, 
    federico.serafini@bugseng.com, Nicola Vetrini 
Subject: [PATCH v3] automation/eclair: update configuration of D4.10
Message-ID: 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

MISRA C Directive 4.10 states that "Precautions shall be taken in order
to prevent the contents of a header file being included more than
once".

Add a SAF tag to the existing comment on top of cpufeatures.h.
Add a header inclusion guard to compile.h.

Update ECLAIR configuration to:
- extend existing deviation to other comments explicitly saying a file
  is intended for multiple inclusion;
- extend existing deviation to other autogenerated files;
- tag the guidelines as clean.

Update deviations.rst accordingly.

Signed-off-by: Federico Serafini 
Signed-off-by: Stefano Stabellini 
---
Changes in v3:
- fix copy/paste error in process-banner.sed
- fix comment in cpufeatures.h so that ECLAIR picks it up properly
- remove xlat.h deviation thanks to Jan's patch

Now it is fully tested and working as the ECLAIR runner is back online.

Changes in v2:
- merge the two "Generated file, do not edit!" deviations into one
- change cpufeatures.h deviation to SAF
- remove compile.h deviation and change compile.h.in instead
---

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index 9c67358d46..8ec1b85350 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -72,11 +72,15 @@ they are not instances of commented-out code."
 -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."
+-doc_begin="Files that are intended to be included more than once (and have
+a comment that says this explicitly) do not need to conform to the directive."
 -config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* This file is intended to be 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$)))"}
+-config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* Generated file, do not edit! \\*/$, begin-3...begin-2))"}
+-doc_end
+
+-doc_begin="Autogenerated files that do not need to conform to the directive."
+-config=MC3A2.D4.10,reports+={safe, "all_area(all_loc(file(^xen/include/generated/autoconf\\.h$)))"}
+-config=MC3A2.D4.10,reports+={safe, "all_area(all_loc(file(^xen/arch/(arm||x86)/include/generated/asm/.*$)))"}
 -doc_end
 
 -doc_begin="Including multiple times a .c file is safe because every function or data item
diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl b/automation/eclair_analysis/ECLAIR/tagging.ecl
index f9da5d5f4d..b95f07feb0 100644
--- a/automation/eclair_analysis/ECLAIR/tagging.ecl
+++ b/automation/eclair_analysis/ECLAIR/tagging.ecl
@@ -23,6 +23,7 @@
 "MC3A2.D1.1||
 MC3A2.D2.1||
 MC3A2.D4.1||
+MC3A2.D4.10||
 MC3A2.D4.11||
 MC3A2.D4.14||
 MC3A2.R1.1||
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index fe0b1e10a2..fd7a18983d 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -30,6 +30,19 @@ Deviations related to MISRA C:2012 Directives:
        not to add an additional encapsulation layer.
      - Tagged as `deliberate` for ECLAIR.
 
+   * - D4.10
+     - Files that are intended to be included more than once (and have
+       a comment that says this explicitly) do not need to conform to the
+       directive.
+     - Tagged as `safe` for ECLAIR.
+
+   * - D4.10
+     - There are autogenerated files that do not need to comply to the
+       directive.
+     - Tagged as `safe` for ECLAIR. Such files are:
+        - xen/include/generated/autoconf.h
+        - xen/arch/{arm,x86}/include/generated/asm/\*
+
    * - D4.10
      - Including multiple times a .c file is safe because every function or data item
        it defines would in (the common case) be already defined.
diff --git a/xen/arch/x86/include/asm/cpufeatures.h b/xen/arch/x86/include/asm/cpufeatures.h
index 9e3ed21c02..bd1f00f5d2 100644
--- a/xen/arch/x86/include/asm/cpufeatures.h
+++ b/xen/arch/x86/include/asm/cpufeatures.h
@@ -1,6 +1,6 @@
-/*
- * Explicitly intended for multiple inclusion.
- */
+/* This file is intended to be included multiple times. */
+/*#ifndef X86_CPUFEATURES_H */
+/*#define X86_CPUFEATURES_H */
 
 #include 
 
@@ -63,3 +63,5 @@ XEN_CPUFEATURE(USE_VMCALL,        X86_SYNTH(30)) /* Use VMCALL instead of VMMCAL
 
 /* Total number of capability words, inc synth and bug words. */
 #define NCAPINTS (FSCAPINTS + X86_NR_SYNTH + X86_NR_BUG) /* N 32-bit words worth of info */
+
+/*#endif X86_CPUFEATURES_H */
diff --git a/xen/include/xen/compile.h.in b/xen/include/xen/compile.h.in
index 3151d1e7d1..9206341ba6 100644
--- a/xen/include/xen/compile.h.in
+++ b/xen/include/xen/compile.h.in
@@ -1,3 +1,6 @@
+#ifndef XEN_COMPILE_H
+#define XEN_COMPILE_H
+
 #define XEN_COMPILE_DATE	"@@date@@"
 #define XEN_COMPILE_TIME	"@@time@@"
 #define XEN_COMPILE_BY		"@@whoami@@"
diff --git a/xen/tools/process-banner.sed b/xen/tools/process-banner.sed
index 56c76558bc..4cf3f9a116 100755
--- a/xen/tools/process-banner.sed
+++ b/xen/tools/process-banner.sed
@@ -12,3 +12,8 @@ s_(.*)_"\1\\n"_
 
 # Trailing \ on all but the final line.
 $!s_$_ \\_
+
+# Append closing header guard
+$a\
+\
+#endif /* XEN_COMPILE_H */


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 05:53:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 05:53:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005080.1384618 (Exim 4.92)
	(envelope-from )
	id 1uMh3W-00050C-Lz; Wed, 04 Jun 2025 05:52:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005080.1384618; Wed, 04 Jun 2025 05: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 1uMh3W-000503-H8; Wed, 04 Jun 2025 05:52:54 +0000
Received: by outflank-mailman (input) for mailman id 1005080;
 Wed, 04 Jun 2025 05: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 1uMh3V-0004zx-Ij
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 05:52:53 +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 26bd9628-4108-11f0-b894-0df219b8e170;
 Wed, 04 Jun 2025 07:52:51 +0200 (CEST)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-442f9043f56so39181155e9.0
 for ; Tue, 03 Jun 2025 22:52:51 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b2ecebb5f40sm6914100a12.67.2025.06.03.22.52.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 03 Jun 2025 22:52:50 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 26bd9628-4108-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749016371; x=1749621171; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=6xysgJtuGxvMMNRBUfK61fJbx9rk+uZUzkoc8rRqP6Q=;
        b=gPBlp8ldDpIrKvqmYjWf4c96i9O+zTUO+tfKZxq4zlbo16YHUsUo9yvsTT1I2BV7wK
         jEnxGmdWKoc2xe1GIZ5Fz1fNECE4IMTeKBTmdJwvWgtZZmuL40ADxSphhAzbW0XqP7l3
         n9aQiCufi6QiVhR8r6AII1m1O0ogbOlccvrWuk/xFPWkFd7qCT0kJNXwpQBD6X7XPAKK
         5sNm4Ibbf9R1BHAeUfQaE1hYi/ycVTO2M9qRStUEB5qe6hUHTZYFVT+HbM6I6h8lXSX/
         ESRxRPhKI8juA0uBFwGJJDMCQCB60OnYhMIVFlNJw/0HgebHSpRQJaNvebw6BoBDfeuI
         G+nA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749016371; x=1749621171;
        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=6xysgJtuGxvMMNRBUfK61fJbx9rk+uZUzkoc8rRqP6Q=;
        b=iKrdB7S8Sx7NzKQYLRBsOsw3Mt1LopTZHX50cJ7ibutCbfrRyv/yOAQcb5LM4zMxtb
         Aa8OzbwaSrOm+ojS38/XLr159p3zR4QmZwiPlbYzNlm1B9C4VVC6wxmS8K3KA+fQ1p05
         HXH2gz18BaKPQx3RTaHmlyjvYY3c9ppfsZmUwxAbbNjNXD4PwISI3ylbBJ3t0NFD/w3D
         w1Hxwv7HXSjAlg7ModIDJuVne0Yb6M7XP7smnJOhqkfmBoh5ZYfWK/gJx71T9QMxwJm9
         Hkw8eibkGEkrmZQFXVHfTyThELjYLaGP2AMgik4j/yPE8klq8CpDZ3svIQNdeiZbo1Ze
         ECcQ==
X-Forwarded-Encrypted: i=1; AJvYcCVvTfQFIPTpv37rWoT3Uip/sDE+gtl1iQApO3ge7UMU1sLfRztGDFPs6LaA74AtTOFiIKYjMp123jY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyqva4Hyv2AatFEkR12js0zOHIls99+I9RK8BZpAt04GiZXRTYy
	rTbAEXEud3wgDnzTqVmqS5F3PPj8S9PkJhqJfebSDT1VyvROcg9trMrHF7thEBzjVw==
X-Gm-Gg: ASbGnctytwNZuyuHJsuBKGyvRvi4yuoEvdtKV+FPggOLDAkihATKFZSZxXV7flk36WR
	OemGIKRkspqUx8JmUdPV6Giio610QamFyLTIe3t6i3+u7cqxy7um1K5hwV9R6B5RuXNkFokSHm6
	42MHeTt+xJfg7rc+DyjUki2kZ8Zg4VO0KJbJBwgw1ZvnFe6Tn5235O5SMt8riguvW23snZ1rJzb
	oBU0VWu/bXghdpLjhD0v3Td9xFeSh2SdoJCBoGMHMV3d4Qo50idUAxMnQZDmRXiyHotq0OBoBXI
	5kS2cMfShdW6oLU1n+qkjMdtuNTD4WDtt0MSsw3NFNctp6m5MWc7h56rKTCL/Dz+tlr3BaHjGu4
	2cLgoCnWM3g3zbBXH5Pc5S+DWL1v97HcVDrO8
X-Google-Smtp-Source: AGHT+IH1QA9XaM7sNNEGRlTenWmHQ/dXp2xH90NrOuAIW4vSDmwDtCc3bfIt2F/VpyJQBHE1JIJ1ww==
X-Received: by 2002:a05:6000:2913:b0:3a3:6415:96c8 with SMTP id ffacd0b85a97d-3a51d973ce1mr935968f8f.41.1749016370895;
        Tue, 03 Jun 2025 22:52:50 -0700 (PDT)
Message-ID: 
Date: Wed, 4 Jun 2025 07:52:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v11 6/7] xen/arm: enable dom0 to use PCI devices with
 pci-passthrough=no
To: Mykyta Poturai 
Cc: Stewart Hildebrand ,
 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: 
 
 <66cda989-efe9-4389-ae8d-cb9bc4dc5239@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 03.06.2025 15:31, Mykyta Poturai wrote:
> On 02.06.25 11:11, Jan Beulich wrote:
>> On 28.05.2025 11:12, Mykyta Poturai wrote:
>>> From: Stewart Hildebrand 
>>>
>>> Enable the use of IOMMU + PCI in dom0 without having to specify
>>> "pci-passthrough=yes". Due to possible platform specific dependencies
>>> of the PCI host, we rely on dom0 to initialize it and perform
>>> a PHYSDEVOP_pci_device_add/remove call to add each device to SMMU.
>>> PHYSDEVOP_pci_device_reset is left untouched as it does not have the
>>> pci_passthrough_enabled check.
>>
>> Just to re-raise the question here: Is this actually correct?
> 
> I'm afraid I don't quite understand your concerns here.
> 
> The purpose of this patch is to relax the pci_passthrough_enabled checks 
> and make PCI physdev ops work with passthrough disabled.
> The reset op worked independently of PCI passthrough being on or off and 
> will continue to do so after this patch.
> If your concerns are about the correctness of allowing reset to always 
> work, you specifically requested this behavior in the patches 
> implementing it here[1].

Right, yet even there I had already asked for possible differing opinions.
Plus the case I had mentioned was specifically Dom0, which fits here.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 07:01:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 07:01:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005126.1384633 (Exim 4.92)
	(envelope-from )
	id 1uMi7f-00054G-HX; Wed, 04 Jun 2025 07:01:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005126.1384633; Wed, 04 Jun 2025 07: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 1uMi7f-000549-Ei; Wed, 04 Jun 2025 07:01:15 +0000
Received: by outflank-mailman (input) for mailman id 1005126;
 Wed, 04 Jun 2025 07: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 1uMi7d-000542-QG
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 07:01:14 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on2061e.outbound.protection.outlook.com
 [2a01:111:f403:2407::61e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id aee08c71-4111-11f0-b894-0df219b8e170;
 Wed, 04 Jun 2025 09:01:05 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by BL1PR12MB5899.namprd12.prod.outlook.com (2603:10b6:208:397::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Wed, 4 Jun
 2025 07:01:01 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8792.034; Wed, 4 Jun 2025
 07:01: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: aee08c71-4111-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=KbZLmrMvWXDka6uT9OhlWbyWvlTPCQAYEoRQ8J3ctt6rskasqz8x0xIZfnpvnBF0WajI2XUPy0aTwUiPLyayHdWmLlnlVC4RJ2AP9u66rjFjYBtOjOuRPY7VJRRSdyh5CgfszvhRR3+iFGdtTSxT8pUnv9+H97QS/UhELMjoTKsxRfnDZLGMJM4AgR0E5Rh8MEKn4WJzgtvd9O4Rd5nWinbKSU2fd9v33tM3QiKno2oDdZxdYkEeEkcZcrFpZz/qTjKYuCnnmA8GFKBin6oBGtiLwFk98LfWOAkoq9+MalrpBcjr+UyaC9X93m1N0Bb5uDzBz1JXKo9Dha3LQJnrUA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=RPgnn9uUfAEefzWq1OSr6YrAA1PzqHiV8NmfF8vMYGI=;
 b=aPTgAZY4iiZ3wjdb4OGgXSDmpVw4tIpYnpM5QJogsaPpV98P2wTwxzSXF0Nn3kcqjET7ul4Mpnzydtk44/lb2a/tdBEocaRZRPkzPU3EqlAjFKZ5Z14+uLyIIio+lz1ZYtQde2KUna/0Gj6ucrkN+NaEaJ4CDZQ7ilH26vFP6NzLoaevF5A4MSvxEhlYWyZwBg5pqHSCPmL1yI7w5zvVDNqYQmKujjf8gWyJJzl2LhTQinfbpPpwrXUfOsuWHXLa7wyu+IWALC4H17jPQaJdJZqyw+4gnFBfRTK2CaUt+gLBiDhTQC1yIMK4B4Fktz35FdaTUyooyzkBYktL/UTeFg==
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=RPgnn9uUfAEefzWq1OSr6YrAA1PzqHiV8NmfF8vMYGI=;
 b=ldrG1qGAldHu7mNA7FCadScR5UseiKpDHd/F05amXHvyaVSxIpPo5jfSKqhYNunNJPA9yWJlt7eEzHiCudbK1jyvuLyhhL0q8rO5iXUkwgO9Q8IkuYKAaSv0UssP9ysIb7lusPrF++jpll2t2IooqWTjO3bGyM7NOeiRoI8od3c=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <28b22fa6-c6f9-463e-8e7e-0a00eae88737@amd.com>
Date: Wed, 4 Jun 2025 09:00:55 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/2] xen/arm: exclude xen,reg from direct-map domU
 extended regions
To: Stewart Hildebrand ,
 xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20250513195452.699600-1-stewart.hildebrand@amd.com>
 <20250513195452.699600-2-stewart.hildebrand@amd.com>
 <54c3d341-1d7f-428d-89a7-ce4fcae8a5db@amd.com>
 <4bd41362-6ee4-44d7-9f9b-0ffd78f1e6f8@amd.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <4bd41362-6ee4-44d7-9f9b-0ffd78f1e6f8@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LO4P123CA0177.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:18a::20) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|BL1PR12MB5899:EE_
X-MS-Office365-Filtering-Correlation-Id: b5c4ba71-21ad-4612-ae58-08dda33590e4
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?Z1dYSW8vYUJ2bHNibFRxMmZZMmlLaWNlTHJCMFRqQTlIY0cwNUYySlhmUmt6?=
 =?utf-8?B?MmhMY2dOS2xzZGxXNjc4L3lBMmVDS3UrN2N0ejlJaTJvTG1NYlQ4TWJmbFB0?=
 =?utf-8?B?WGhxWGFhRXZ5NThxbnp1bi9KZ2FMSmRqb3BMSWRpcHZWQ3FzWEtUclRRbGxE?=
 =?utf-8?B?Q1ZrOVJ0aVJ4cTQ1Z09sa0hPTEwzMTUxQUoxbFVycEVSNmphVThYbHYrZzdo?=
 =?utf-8?B?MU9wNytQa0tMdVpGQnozcFM4d0ZqNW1NSEdNcVpyT3BXSm5UR09TL0hOTWY2?=
 =?utf-8?B?elFGQ3hmSDN3S2p6bDdWZ1c5b3o5RTFONG1aNFlaRU5Qdkk4V09SRXE5TmZX?=
 =?utf-8?B?WWNuYkFMRXZFem81Q3AvUk9KcGZGYVhWSFU5aVgzN043a2dLS2hiNU1ZU0Ez?=
 =?utf-8?B?ZmhmVzNuWll6QWpiRVZXaVUzLzBmVlA0ekJGNGllQ1RnamlOajBoUHZMNzZD?=
 =?utf-8?B?QnA4VkxqTXJtTmpDKzRTVHBhY1VZS3RVZlI3ampkL1hPMU43ZjZnN2FDd1FK?=
 =?utf-8?B?RXA2dU1FM2dDRTVpZ01kMWdmRnhEVXAxRE1vMTA3TXV5NXN5b3YvNkpqQzJS?=
 =?utf-8?B?VFFSTWhlMGtMYjFoeVhPTkpodlE0cnhnVmF6SExSY2NyVkF4c1ZIaGRWY21V?=
 =?utf-8?B?YXpYQVRVTWM0RmVpYm5jRktVSnY1RWpWRzlHYXZ4K0RZd2JQUVBjZ2U4bWlx?=
 =?utf-8?B?MUJ1Q3lsemNiN290OUhrRzdsajRsVEdMV21adGRnRUpQc0lla2o3RVhtVkxT?=
 =?utf-8?B?UFA4ZzAvY3RZZE9jY3pMNmZzWCtvY2hibit4OVpjOUZUQW96b3ZzUGhSNTU0?=
 =?utf-8?B?S1Z2NjJzVk03U3BQMkJYTU5nTko4cGdFcTRKREF2NzhZVEhCRXF5UE1wSVY1?=
 =?utf-8?B?RWxoWi9HS1IyLzh5Y0R1dnZtM1NxU2RCaWRUZkNYRTdaTU9UNmxEMUlEUmlv?=
 =?utf-8?B?VzBCLzV4S1JkWVNpMUlVMnR1NWx1UGFMT0gvK2lndTZNRE9yK3k0anZZeUpt?=
 =?utf-8?B?Sk00bVBYTXBrZlg4TUFoalJHY1lYWkdTdzlYK2hVVWhkTXFtNTgzQ3lCL2k5?=
 =?utf-8?B?TGNpR2d2SkFFUTNXRTNmeVFpb0oyaHBXeWxXVlloMzhySVZ5bUJ1VThXRHlo?=
 =?utf-8?B?Ni9qYkIxWVlyUDBrbmhHL1RhOFhHcXgzKzIzdWNpRWxNbVl0QkpBYUdtQ1J0?=
 =?utf-8?B?NVdjL0JpbnRwTkdVS1dmZFBoZEk4RDJTT3J1a3pxN1Y1aG80dTgray9Nd1gx?=
 =?utf-8?B?SXZmcGppQURNRXVJeEx4aUw3RjVlVnZZZStTVTVDbmtYL0UvWlQ5c0xhY3hN?=
 =?utf-8?B?WTJzSC9yMlBNbjFMWTBGVkx6cHBZTHlQWGFRMDd4ZE5BN1ZNc2t2OURIa29q?=
 =?utf-8?B?bjZJOFlsOGJhcC9TUU11UTVCdDljeUJnK2hFZ1dFQ2JhS21nbERsb1VkeVg2?=
 =?utf-8?B?ak1kbFk4bHBXYUNpZHZTdVdtWk1TeDdiY3VRZ1pmZS8zcG9CUFI5MnY2bUxr?=
 =?utf-8?B?enhObmtRcEErNnk4czVwQllKWHE4Nkt5WW00REM1dEpjMWRTWkE5cm1veEoy?=
 =?utf-8?B?MHd1Z1orUVVMc2pvdGxXZnQ1ZDE2V3lGTVJvTDRReVAzKzFvMFJwbkx3Y21a?=
 =?utf-8?B?aUd2K2xiMzNLSmhJRTVRNFVhK3dSU3JGNWdFYVNJVWJDZU5BQVJ4T2ZzS21O?=
 =?utf-8?B?aHRCK2pzYzJDTExwUmNmTFFDVDA3c3ZTNnVqMXdyd3o2RmlCbW8yZ2wxQlNW?=
 =?utf-8?B?VGVHRVZtRFdpbkNIbkdSZ29wUklGRUpJOS9BcFpsY3AvSFkxYVlmN25qYmd4?=
 =?utf-8?B?WU45MXJYOHNEclBJbkRaeDdqV2ZsRXU0bGNvYjV3S1dmRzRhcEE5N1Vnb1Zs?=
 =?utf-8?B?Q0NvMlZ4bkhIK3huTC84NVF3NTFZRzVROCtpOGJsM3hUazJoNDl5SlM3WGF6?=
 =?utf-8?Q?h9ogQotW4Js=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?eVdma1U2NzFtR3MzSkxkVEtkNzY4elFyWkMrV3FKaFBvekorbEFURzFySHE2?=
 =?utf-8?B?U091bWM0NDlLb2JDY2JTSXJVbCtSbnhJY0dtOGtpYWhrbEhCS3Rzck1YVWlV?=
 =?utf-8?B?eklNK0ZiekM1aUxPSS9lTlZWZ1JxOG5KRkF3eGZjL1Bnb21Na2RKbyt6Uk1U?=
 =?utf-8?B?bElXcXZDNzFyUEZObHdXOWVwRjhzMWUwSDltalVEcjJBdG9ieEtwT0g4cmZz?=
 =?utf-8?B?WWw3UjV6aTR5UE9rektPb09qV3V1eDh3VExpa1lEYk5SRm1GVnJlb0Rkdjha?=
 =?utf-8?B?dEU4Zm94MTUvMGhmMkN4c3RXS1VPdnhSUk14VXRmcUJEdFFNanR0N3FmN3dp?=
 =?utf-8?B?WWQvSVVudHVGQVFGVmsrZ2wrZExUK1BYNEJpclhRcDJEYjlKU3o3OE1XaHox?=
 =?utf-8?B?R1k2M090TUFybmtyVnF3UmVHTU1oZDN5L21vOWZqMnc3K2ljbUthc1JDYUJJ?=
 =?utf-8?B?TFRXSUpnN1hCaStvZDU5SlVTVGZsVXRxNk5zQ0V5cUN3R2cycDhNNThWS0RI?=
 =?utf-8?B?YUZLYmRLYXdFZzZGZnU4a2t0WlZwbExZRmVjTi9hVXV5WDd3WVVGYUZEeTlO?=
 =?utf-8?B?Z1djTUo1a2taT0tkaEdCSCsrWjd5ZHFhYVdDb3d0M29UTGIxL2tXNE40b1N3?=
 =?utf-8?B?WDczR1FnQXUvTXJWS2Jsd3ViT1R2VjUzSWxkQ2szVFg3Sng5eURGUzF1aUhJ?=
 =?utf-8?B?d2h4KzY2MGsvYnpnREw4MXBIYUxmMnRDVHd4ekZrNEVscWxtNlQ1eE1mZnZu?=
 =?utf-8?B?R2Q5REw5L1FlamZLa1JxL2VOc3VRdmdpSkZYQ2ZKMkhjWTg5ZXR3VFhNVTc5?=
 =?utf-8?B?NWRDSUVpdnIxVktxWThiemhSV0JyNEJUZEIxY3BydDBsOVR1ZXNINXZNcTR2?=
 =?utf-8?B?cnBZS2lBenpJQ2RidS9UWFBkTm9kdzVXMjhMcThDbVVvWnBvUkx3L3I2THlG?=
 =?utf-8?B?eUVZTTZxZjZXTEVNSnJCWXo3Ym9rQkJMTHI5bGs1YWhWOEdhSU5aOGtPbC9v?=
 =?utf-8?B?Y2t0Q3dPZzltdDdvOEVlSUh0dld0NTlrdUNRQnhvbVlGeTNHNjVHR3lraFpD?=
 =?utf-8?B?ejdaV3hxd2RvK0FzUEdIYk9jR1pLSFh2VDBWNk9VQWlNalpGZ3FPczJ3RmEz?=
 =?utf-8?B?RGpKRUM1NlN3TlRvek9WcjdiUXNHM2UzMHphNDdaQThOK0YyNGNnWGw3dWNi?=
 =?utf-8?B?VlFvbkZ1U1NDL083WTdFY1YxaExLR29vR0g5T1MzSkdMNlhpK1pVNXExYVFU?=
 =?utf-8?B?LzRzbWx6RWV1cW1xbDNLWVloZktHNHZGblNxMXlScmlZVEJ1M3VZWjNvMDJY?=
 =?utf-8?B?SFFjZk9jOU0zQ1RLa3dWVkRZS1JkT3FOWWU0ajZJeUxUUjRLTnI5MVJXQlFr?=
 =?utf-8?B?NjBWdGtpb212RXQ3Sy80bmF5OG4rTzJod1c3eHBNWm9qd1NNZFZIRWEyQmpG?=
 =?utf-8?B?UzF2aFRKaitxajdiK012L1pHNlVzVXRUbStja2VhcWpZWmI0WEtENEJnaFFp?=
 =?utf-8?B?cy9jcjZtdzFMTUo5c2NzdC9uZW5zeFVVb3llWWlyVjZITmFHeFpFY3lNS01C?=
 =?utf-8?B?UmVZN1Y5UUpmbXJYZXlsNGM1TlBucHhYd2drZndWV1lKWXBCVEwrbXJKb0Zs?=
 =?utf-8?B?UWFqcGFTZkd2c1NGOXdTbkZDR2NkL1JvdVpxWlc2amN1a2h0Ymc0WTFhVG1N?=
 =?utf-8?B?aG9GV3V3NDFwemtTb1BJck1haWtGNnpUTk5VYWxNc1NqTVExVkpmUi9CSWtj?=
 =?utf-8?B?WWhIdEdHQUxTUVN6WlhpMmRPK3ZmL2VXUGRIck1wTlNqZTI2dHVDTjU1OXQ0?=
 =?utf-8?B?cENzTGNyc3FoZHR4ZHlhbjMwZGQzUnY4WEZ3RXA2RUZINjUrSDArS3ptNkxh?=
 =?utf-8?B?WlNRbWJma0l5QjJMYzR1ZzdoS1ZqaDByQXYxaTRLTVVWK2NIZG5INlB6bExu?=
 =?utf-8?B?eUJwWVRqTVltbUVzZlgydUpqNHRKRFcwVlpWNVczS2ttWmg5OVA5Nnl5UFJa?=
 =?utf-8?B?RlVIcXprL0FPMkM2SERoS1NZNWlSRm5CUkl0THBmeGxqK3JlMEwyQVg2TXJx?=
 =?utf-8?B?alI0MW8wZFhnSTF3R1BmSHdxQlpYS3FKRTlvd2J0Uk9UbnVQQlN5Z2VJRi85?=
 =?utf-8?Q?BQjs=3D?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b5c4ba71-21ad-4612-ae58-08dda33590e4
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jun 2025 07:01:01.7721
 (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: I6vCHtts7I4JFU1vWo9PUKpKWp1ZfyVuvqlh0egawLE6LYNnudaKCooJioblzUL0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR12MB5899



On 03/06/2025 23:15, Stewart Hildebrand wrote:
> On 5/14/25 03:31, Orzel, Michal wrote:
>> On 13/05/2025 21:54, Stewart Hildebrand wrote:
>>> Similarly to fba1b0974dd8, when a device is passed through to a
>>> direct-map dom0less domU, the xen,reg ranges may overlap with the
>>> extended regions. Remove xen,reg from direct-map domU extended regions.
>>>
>>> Introduce rangeset_count_ranges().
>>>
>>> Take the opportunity to update the comment ahead of find_memory_holes().
>>>
>>> Signed-off-by: Stewart Hildebrand 
>>> ---
>>> v2->v3:
>>> * new patch
>>> ---
>>>  xen/arch/arm/domain_build.c | 57 +++++++++++++++++++++++++++++++++----
>>>  xen/common/rangeset.c       | 14 +++++++++
>>>  xen/include/xen/rangeset.h  |  2 ++
>>>  3 files changed, 68 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>>> index b189a7cfae9f..3cdf5839bc98 100644
>>> --- a/xen/arch/arm/domain_build.c
>>> +++ b/xen/arch/arm/domain_build.c
>>> @@ -824,15 +824,17 @@ static int __init handle_pci_range(const struct dt_device_node *dev,
>>>  }
>>>  
>>>  /*
>>> - * Find the holes in the Host DT which can be exposed to Dom0 as extended
>>> - * regions for the special memory mappings. In order to calculate regions
>>> - * we exclude every addressable memory region described by "reg" and "ranges"
>>> - * properties from the maximum possible addressable physical memory range:
>>> + * Find the holes in the Host DT which can be exposed to Dom0 or a direct-map
>>> + * domU as extended regions for the special memory mappings. In order to
>>> + * calculate regions we exclude every addressable memory region described by
>>> + * "reg" and "ranges" properties from the maximum possible addressable physical
>>> + * memory range:
>>>   * - MMIO
>>>   * - Host RAM
>>>   * - PCI aperture
>>>   * - Static shared memory regions, which are described by special property
>>>   *   "xen,shared-mem"
>>> + * - xen,reg mappings
>>>   */
>>>  static int __init find_memory_holes(const struct kernel_info *kinfo,
>>>                                      struct membanks *ext_regions)
>>> @@ -914,6 +916,13 @@ static int __init find_memory_holes(const struct kernel_info *kinfo,
>>>          }
>>>      }
>>>  
>>> +    if ( kinfo->xen_reg_assigned )
>>> +    {
>>> +        res = rangeset_subtract(mem_holes, kinfo->xen_reg_assigned);
>>> +        if ( res )
>>> +            goto out;
>>> +    }
>>> +
>>>      start = 0;
>>>      end = (1ULL << p2m_ipa_bits) - 1;
>>>      res = rangeset_report_ranges(mem_holes, PFN_DOWN(start), PFN_DOWN(end),
>>> @@ -994,11 +1003,30 @@ static int __init find_domU_holes(const struct kernel_info *kinfo,
>>>      return res;
>>>  }
>>>  
>>> +static int __init rangeset_to_membank(unsigned long s_gfn, unsigned long e_gfn,
>>> +                                      void *data)
>>> +{
>>> +    struct membanks *membank = data;
>>> +    paddr_t s = pfn_to_paddr(s_gfn);
>>> +    paddr_t e = pfn_to_paddr(e_gfn + 1) - 1;
>>> +
>>> +    if ( membank->nr_banks >= membank->max_banks )
>>> +        return 0;
>>> +
>>> +    membank->bank[membank->nr_banks].start = s;
>>> +    membank->bank[membank->nr_banks].size = e - s + 1;
>>> +    membank->nr_banks++;
>>> +
>>> +    return 0;
>>> +}
>>> +
>>>  static int __init find_host_extended_regions(const struct kernel_info *kinfo,
>>>                                               struct membanks *ext_regions)
>>>  {
>>>      int res;
>>>      struct membanks *gnttab = membanks_xzalloc(1, MEMORY);
>>> +    struct membanks *xen_reg = membanks_xzalloc(
>>> +        max(1, rangeset_count_ranges(kinfo->xen_reg_assigned)), MEMORY);
>> You allocate at least 1 membank even though xen_reg_assigned may be empty because:
>>  - this function is called for hwdom - no xen,reg
>>  - there may be no xen,reg i.e. no passthrough
> 
> Ah, sorry, there's no need to allocate at least 1. This can just be:
> 
>     struct membanks *xen_reg = membanks_xzalloc(
>         rangeset_count_ranges(kinfo->arch.xen_reg_assigned), MEMORY);
No, it cannot. membanks_xzalloc() calls xzalloc_flex_struct(). If you pass 0
as size, the latter will calculate offset to FAM[0]. In other words, the
allocation will succeed but only for members up to FAM[0] (i.e. only for struct
membanks_hdr).

Also, even if you conditionally allocate for xen_reg_assigned or set NULL, in
latter case you will end up with mem_banks containing NULL member. AFAICT that's
not something expected by the users of mem_banks (+ it gives unneeded iteration).

~Michal



From xen-devel-bounces@lists.xenproject.org Wed Jun 04 07:21:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 07:21:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005148.1384658 (Exim 4.92)
	(envelope-from )
	id 1uMiRV-00087O-Ip; Wed, 04 Jun 2025 07:21:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005148.1384658; Wed, 04 Jun 2025 07:21:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMiRV-00087H-G8; Wed, 04 Jun 2025 07:21:45 +0000
Received: by outflank-mailman (input) for mailman id 1005148;
 Wed, 04 Jun 2025 07:21: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 1uMiRU-00087B-KE
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 07:21:44 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20611.outbound.protection.outlook.com
 [2a01:111:f403:2417::611])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8e891875-4114-11f0-b894-0df219b8e170;
 Wed, 04 Jun 2025 09:21:40 +0200 (CEST)
Received: from DS7PR05CA0052.namprd05.prod.outlook.com (2603:10b6:8:2f::30) by
 CH3PR12MB9028.namprd12.prod.outlook.com (2603:10b6:610:123::20) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.37; Wed, 4 Jun
 2025 07:21:36 +0000
Received: from DS2PEPF00003445.namprd04.prod.outlook.com
 (2603:10b6:8:2f:cafe::57) by DS7PR05CA0052.outlook.office365.com
 (2603:10b6:8:2f::30) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Wed,
 4 Jun 2025 07:21:36 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 DS2PEPF00003445.mail.protection.outlook.com (10.167.17.72) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Wed, 4 Jun 2025 07:21:35 +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, 4 Jun
 2025 02:21:35 -0500
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; Wed, 4 Jun 2025 02:21:34 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8e891875-4114-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Lc0xrM6hvltbN3g003K9d5BD0/dr1w2+JzmkWwfo+Y1bexmespxz3Mvt5vIFIyYseXxWRcgf3kmWDyb/V9FXCfU1RohgxxGsWQ89DeoCKrg+uA7Oi30oPPNA3mE3JkNFkM8aTBvKisO0yOdD4dbBuki2fEbRl3znRazxBegtTkbMYYvc3cO8mFRyOb4cIKDNIUp7EGcR7aRmpo3GsDDPhmwHaIE5jv+nHVtMYK2e8bgkMKpYqTTGBrsGJt9amw+EmZsOJ89rEoV1PfTnm+rQ94riA0RlZ03z4SQsPVG7F0l7Nnn/nY0nNLmzTffRmMnGgMrnEKGE2J79ngb5HjJ3yQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=gxaFUMpZS8ns2MzsrcIMUMcaQb3KLMXDA3h61XvrduM=;
 b=RN2hjhJwNIHeGsbqbzAj03dUlB/5EnqsL7P8Vaqm8XA9Aln5DfRMM3ccJ/D9leAC+7xCZ3bSFaLNGdtM66jJ1/wnTGSc8eNzhs1YJsb3wcm5FbA5YGDISX9Trqu3F0VKLYjEwIuoDl9jW5tzdkVP/ubEKz3BhsI80042apfTUectEpxyb6sGSztHVMqvoqBpf7pp6XFxBEzJB0Y3gwpzczJE2SaQyt9Bpzk6ZUbiSXHMnFHYAGfY8YRaAubWwEwQEHnimebrACAcQWtuemPKHK26nDdtDYWGuhN3zB6QsitYGD3WBU0j9gOaVfa4QR/j8uyY6SmybY9d1b3rE/8GSw==
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=gxaFUMpZS8ns2MzsrcIMUMcaQb3KLMXDA3h61XvrduM=;
 b=4mYxNGiEz2lshKMMKs3Ow08ZaCQM80bDGJBi6UkVbtf2TnJQ/VIHJBXNUKKz0OL38SaxIHbI07ZkQuxrR6rpQ6z854phXDGPThTsGJFQxvLGrIrTR3e+9TojgRVhY+glfvlBYBqHtM09+phEfigWtd0nGz8V9rVilG6wgxmquwI=
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 , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Anthony PERARD 
Subject: [PATCH v2] tests/vpci: Use $(CC) instead of $(HOSTCC)
Date: Wed, 4 Jun 2025 09:21:28 +0200
Message-ID: <20250604072128.16628-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: DS2PEPF00003445:EE_|CH3PR12MB9028:EE_
X-MS-Office365-Filtering-Correlation-Id: 96e83053-09eb-47b9-e33b-08dda338707f
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?uOj6CTvmG6tS0koW3fv9dD2/M2Ui23lA83m1R3fE9D2wXgRyUq5ghZsUhgp5?=
 =?us-ascii?Q?bh6rfLTQecIx1Kt1eYhLEmw3dnrN4eF2/rMBQNRi8gQ93qifrWHUyq8ISt57?=
 =?us-ascii?Q?//GOsQOmMKf6fMWbFTHN52JIzWnB6fq4ywBA9cgncvtvDyvp7OwI2BPLjlmp?=
 =?us-ascii?Q?Qr3eMK781J2h6i7rtePNsobpvKOiaxHZNWuK5DXoYHm1eJ0wY2YMu4Pbykwm?=
 =?us-ascii?Q?FB2fyzNrSXbdN6tkJfbhU3fxXQ09/RhChsB8I0eKJK4QQkZT4NqF8K8WG4N4?=
 =?us-ascii?Q?v7KBvWpt8KWeWcKz5CSjT3TjRCTf9BMYoWZSiozzB68ja3GxlJDK93ekZXes?=
 =?us-ascii?Q?G/4jjm5Uylbstr3P73VgaReNm1FEe1brN2u55HPlun5NUG6bJnmT111q4Fgo?=
 =?us-ascii?Q?ySM8vVPIde+ICzyzCsc/Mm+9a25N7Fm9XrN5wOJp4GRV5YpWKaq7ULqehq9c?=
 =?us-ascii?Q?KUMjF3QPtxPs4jQNcWfPdyGeYs6Q277BJ7tWIRXtmfWeMriqRk1oAsp+TKym?=
 =?us-ascii?Q?UumffLRdvlIjt9FaQg8oclDtMxMNplkj7QGWhaIUINi0xakopfb8NYemA8jE?=
 =?us-ascii?Q?Ib1tRSGuVk6ZydY4e3jPRM6FGUsDXM1oc2i0UBqnaaIW0eIElLan+4UB7ii3?=
 =?us-ascii?Q?OhRdEbT29uNjI0eHznlAIk+CucKhBc2mkPvRKpYifpj1VLYi2dnca2aCVIr3?=
 =?us-ascii?Q?nxGCu3zPPyiu+ZyFCcRi6RoDeH5+7zElIpKXOSuzqvtRBal7wdmQj9+6oyuc?=
 =?us-ascii?Q?j6cLQ5Rqz09sMUdRuVDhE/3mSJXuRMVoIk89N71uc/23XH9mJ67sIr4aN7y4?=
 =?us-ascii?Q?zLeOxQg6HL0FzPEYy/nvS379NGNDaYJ9PBxxBfyaBjkhO6jOA/lgrqyQjUJk?=
 =?us-ascii?Q?5KJSJjt9SMFLYJme6KXOagU/2j7TL5z9KQzKR3Fyf5IjraZ+PcsQmutYoy+t?=
 =?us-ascii?Q?nT5Mtui8ezDIln9MBtqL9aiCD39jqWk+VKkfzdUVn+k/mZ71oyf1lSt/YZkQ?=
 =?us-ascii?Q?S2+LwsKgK3eINHzNfhRHzeVnQ4mf8+sVbpwj0HL6av0JzRl+owfGIMkb9ZdM?=
 =?us-ascii?Q?LoPnziEXdSLcB+4lDCuJK+narApvKMq7TeeDVhRS1a3cTArk6v7FcFQkJNwW?=
 =?us-ascii?Q?cTTDzHLfvEl7S0pe53sqXX5WJCyZcPggYl6Bar6zJxEl2/1NcpG/e9c6p7OW?=
 =?us-ascii?Q?Cz2Ict3uweBdyVDmiGYFJgMXETWl88c9QtrJiYSITdjvkK9Y2YMSsuL3xX38?=
 =?us-ascii?Q?EHtAWWo3P63IZxc5t2yD6TTRR7ZqwdECvo7ga7oCCPm8bq8/8C+D4oLOE3Bk?=
 =?us-ascii?Q?1TK6Kt0tW3T5d75DtwuLmIsxexVCHiZ0rium+t48zObIe8OvRAGmdcheaTHS?=
 =?us-ascii?Q?btNtKunEnYquWBOBumDm7sONEKscwfQKu3fo/RAFcXl5hn4Lsu2a0hnMEAc3?=
 =?us-ascii?Q?rXrgMmAFJULeuqP6OjB9UPXX3OwKxU9Ow/xTbOGG63Fpp9jYnpHJCzRM9Dra?=
 =?us-ascii?Q?MGGQyR8m3xFhUcPcbkvAE3us30qU5F5JswnR?=
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: 04 Jun 2025 07:21:35.6559
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 96e83053-09eb-47b9-e33b-08dda338707f
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:
	DS2PEPF00003445.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB9028

When cross-compiling, HOSTCC can be different than CC. With the recent
`install` rule addition, this would put a binary of a wrong format in
the destdir (e.g. building tests on x86 host for Arm target).

Take the opportunity to adjust the `run` rule to only run the test if
HOSTCC is CC, else print a warning message.

Fixes: 96a587a05736 ("tools/tests: Add install target for vPCI")
Signed-off-by: Michal Orzel 
---
Changes in v2:
 - change Fixes tag
 - add `run` rule adjustment from Roger
---
 tools/tests/vpci/Makefile | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tools/tests/vpci/Makefile b/tools/tests/vpci/Makefile
index 9450f7593a41..f2226a5543bc 100644
--- a/tools/tests/vpci/Makefile
+++ b/tools/tests/vpci/Makefile
@@ -8,10 +8,14 @@ all: $(TARGET)
 
 .PHONY: run
 run: $(TARGET)
+ifeq ($(CC),$(HOSTCC))
 	./$(TARGET)
+else
+	$(warning HOSTCC != CC, cannot run test)
+endif
 
 $(TARGET): vpci.c vpci.h list.h main.c emul.h
-	$(HOSTCC) $(CFLAGS_xeninclude) -g -o $@ vpci.c main.c
+	$(CC) $(CFLAGS_xeninclude) -g -o $@ vpci.c main.c
 
 .PHONY: clean
 clean:
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Wed Jun 04 07:43:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 07:43:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005155.1384669 (Exim 4.92)
	(envelope-from )
	id 1uMim4-0002Z4-9h; Wed, 04 Jun 2025 07:43:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005155.1384669; Wed, 04 Jun 2025 07:43:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMim4-0002Yx-5m; Wed, 04 Jun 2025 07:43:00 +0000
Received: by outflank-mailman (input) for mailman id 1005155;
 Wed, 04 Jun 2025 07:42: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 1uMim2-0002Yr-QC
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 07:42:58 +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 87b26c52-4117-11f0-a300-13f23c93f187;
 Wed, 04 Jun 2025 09:42:56 +0200 (CEST)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-3a3798794d3so5403158f8f.1
 for ; Wed, 04 Jun 2025 00:42:56 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-450d7fb09a3sm187134615e9.24.2025.06.04.00.42.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 04 Jun 2025 00:42:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 87b26c52-4117-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749022976; x=1749627776; 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=NqGl+7cdkaDAGvPWjnVxDSCo1PzGXC4U6uc/+bIOygA=;
        b=SjuWPe8uz3vX72OffrYcnKD8GZ6I29aQFkGb0Q5/6PFpiN+b7eosUhEVEYPy/iMxqO
         yIqPmC6lRhRxhmqhenvTKZolt2L8Pwe/EChsI8DW7vm1F4Z7RxemJbYndo2TtHXUoKxS
         Gupgf1vvC1aT7FLcpVLZ2qRHhUyByjXr2irBs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749022976; x=1749627776;
        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=NqGl+7cdkaDAGvPWjnVxDSCo1PzGXC4U6uc/+bIOygA=;
        b=X4P9Q79gPphJp2GoXsWNp1HQKHPdWYDfDnFra0XJjtbTN7cbbYhPmmBH3WUxdOl/bS
         ol/NUcLIwLBwY9QuAvbl6EUjtdvIC8pzE5uome13bLQLuj/H7StfkXd+DwDG04XOPYXk
         b7TkPFBFMtAzQyguVR+Z5nv8ECYOJ7C1i6iwkmT9N3ABdC6r904HbP1NRX+SPQLhIG0P
         gZ6hAjRSiNoIipMRH4C+b1Nu3y7DN4KA49j4Q37YLjs8qtNbxA6nQTJ/p8ywAwmtt/0b
         yA0rJXm7w7MN9XuD1xvVZpJ8tM6JPg1N9KeZUZOlA8JeNifJ3EcdIgiD+M1sytydn4aF
         gIeQ==
X-Forwarded-Encrypted: i=1; AJvYcCUJRX54VLalcP71cPEZ9+wHMZx3Gl/3p6+L6V6K5tbvH5TxQpQidQYhSE7vIHQym73FLcbijzsbvEk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxpChoXnvurGwADQiwkZxYoHhIkAY0MsraquP8nQVlkIs+vkRV5
	7b+IWBh1Y/wb0bxCoh26JpmEnxOeKs2CakZnVos2J5dV8TLDRlK5ep5cWPyMezhCEIk=
X-Gm-Gg: ASbGnct0TFdgIdX8R+z6qXktVNVhOtL0c94AvioM4D+9r3oF//54TRBaad1kK+/+eN+
	+mQux3Ck9X32ytPTG1fEl/QsBrlgvYG2MLVaBSTHUrKA6pKIgrwtXCaBsGNgEEv2z340wnmVjuO
	RBqneqVENIJZLj+np4M52CR0TXg6byKpGS8eLAov2Ppnwe1frVHJ0IPtfE0MkXNrh/RaGloll6d
	5YmTQ+dFTB4Hq7LrasMNWq1zTSKglFsNK/fwr61FWVvJMHnuluqKDSueIluspV7JpjB/2pVEo2v
	sQGVJGcSBNezUPV9MATJoWWB+5JbZHbrHG9UNQCUuTPfjGmPlnBj2qvaBmF40DUkA1Oye1wZf2M
	ysOb/ihXGtKm4QggvEj8=
X-Google-Smtp-Source: AGHT+IE3Dm4ReIuQ+TmscDOwKNZm6QncTxYw+InMS4zDFhruvWCbbdwz5sL6LSWk9esh79Dt54Idbw==
X-Received: by 2002:a05:6000:26c1:b0:3a3:727d:10e8 with SMTP id ffacd0b85a97d-3a51d968010mr1153991f8f.50.1749022976031;
        Wed, 04 Jun 2025 00:42:56 -0700 (PDT)
Date: Wed, 4 Jun 2025 09:42:54 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Stewart Hildebrand 
Cc: Jan Beulich ,
	Andrew Cooper ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 2/2] x86/vpci: refuse to map BARs at position 0
Message-ID: 
References: <20250522140356.5653-1-roger.pau@citrix.com>
 <20250522140356.5653-3-roger.pau@citrix.com>
 <3f274948-92bb-40c4-bcaf-7b538300140a@suse.com>
 
 
 <198b21fd-ec37-4edd-9419-37bde034149f@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <198b21fd-ec37-4edd-9419-37bde034149f@amd.com>

On Tue, Jun 03, 2025 at 04:47:55PM -0400, Stewart Hildebrand wrote:
> On 5/22/25 12:24, Roger Pau Monné wrote:
> > On Thu, May 22, 2025 at 11:44:24AM -0400, Stewart Hildebrand wrote:
> >> On 5/22/25 10:59, Jan Beulich wrote:
> >>> On 22.05.2025 16:03, Roger Pau Monne wrote:
> >>>> diff --git a/xen/arch/x86/pci.c b/xen/arch/x86/pci.c
> >>>> index 26bb7f6a3c3a..39fd5a16a4aa 100644
> >>>> --- a/xen/arch/x86/pci.c
> >>>> +++ b/xen/arch/x86/pci.c
> >>>> @@ -101,6 +101,15 @@ int pci_conf_write_intercept(unsigned int seg, unsigned int bdf,
> >>>>  
> >>>>  bool pci_check_bar(const struct pci_dev *pdev, mfn_t start, mfn_t end)
> >>>>  {
> >>>> +    /*
> >>>> +     * Refuse to map BARs at position 0, those are not initialized.  This might
> >>>> +     * be required by Linux, that can reposition BARs with memory decoding
> >>>> +     * enabled.  By returning false here bar->enabled will be set to false, and
> >>>> +     * bar_write() will work as expected.
> >>>> +     */
> >>>> +    if ( mfn_eq(start, _mfn(0)) )
> >>>> +        return false;
> >>>
> >>> Is this really x86-specific?
> >>
> >> No, I think Arm would benefit from this check too. I'm in favor of
> >> moving the check to common.
> > 
> > I think on ARM pci_check_bar() is more strict, and doesn't really need
> > this check since it explicitly checks whether the BAR falls inside of
> > a bridge window.
> > 
> > So unless you have a bridge window at mfn 0 this won't make a
> > difference.  And if you have a bridge window at mfn 0 you really want
> > to be able to position BARs at address 0.
> > 
> > Thanks, Roger.
> 
> True, but I was thinking more generally: if a BAR is not initialized,
> don't map it. On Arm, it seems to be hit or miss whether BARs have been
> initialized or not. I guess the difficulty lies in whether comparing to
> zero is a reliable test to determine if the BAR is uninitialized.

Indeed.  I think on ARM it is better to check whether the BAR position
matches the bridge window, if it does not match then the BAR is not
initialized, which is what the current check already does?

On x86 this is more complex, since Xen doesn't track bridge windows,
hence the sub-optimal solution of checking against 0.  Also on x86
while not impossible I think it's extremely unlikely to have a bridge
window starting at 0, given all the legacy stuff that resides in the
low 1MB, and the fact that the AP trampoline must be in the low 1MB.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 07:59:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 07:59:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005166.1384695 (Exim 4.92)
	(envelope-from )
	id 1uMj2E-0004cT-Ty; Wed, 04 Jun 2025 07:59:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005166.1384695; Wed, 04 Jun 2025 07: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 1uMj2E-0004cM-Qc; Wed, 04 Jun 2025 07:59:42 +0000
Received: by outflank-mailman (input) for mailman id 1005166;
 Wed, 04 Jun 2025 07: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 1uMj2D-0004cB-2b
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 07:59:41 +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 dd2375fb-4119-11f0-b894-0df219b8e170;
 Wed, 04 Jun 2025 09:59:39 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3a4fb9c2436so2390016f8f.1
 for ; Wed, 04 Jun 2025 00:59:39 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23506d20bfasm98947275ad.235.2025.06.04.00.59.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 04 Jun 2025 00:59:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: dd2375fb-4119-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749023978; x=1749628778; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=irP3jzCjhLiox3DaGK3fe8uEpmp2A76YqA4wKhD5kSI=;
        b=bW2TA6EY7RH6BpSEcSznazrRKiO1omnH5rMdqm8An/flUhyqhufMh5HCoZ45gtfhAz
         MnQsoepQfacpOG6lbzg5x+D+XjiWammTw+HT9V+BgSR5GyqUE8AmYA5Y6FAXqkoVx9Rz
         vTCNXZFOReqIdL7Z6+SChG+bMGrKfJ2WFeEtfSR13WqYqX2Ko4VeuaonKCjXRO0X/aET
         XAVgszMFSHmnfF15DtvtTEtVNjCeJcZ8vtbQzgXJQftKvcsd7gqCM6Obc9OWDU9Iw4pg
         v0vVpYctC8PqIx++hx2KmEQDtPawIF2Y6okhxUTXCmPegR8NOPa/BWao8xNwfy1Hczrd
         9a3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749023978; x=1749628778;
        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=irP3jzCjhLiox3DaGK3fe8uEpmp2A76YqA4wKhD5kSI=;
        b=Z68wRCG/1Fq80iMkf2kIcp3owCmxY71xPrcTKcdrZjSe2b8eI4///41Z+zROMoGZGi
         rbs5uxJQRuO96VJb9U4FlmZQs/h3Z2TKU7P8dn+fLiP3Ny+9+r7gwzJBfE9PEcnV7SYs
         ebgFtmW6C7k6DRhUS1qwq64UM1CPvkGSDk5auxK9/qlBCVw8TDU431mi2+HH0jrJ4aXu
         M49OxcVwjzye3yPT3kYy87+rTzZ6qVRo13wSEF31UeFtx4bZh7Lz8rfTQIgeBUm6YcXB
         9CDH3tLsJNdlwvosH1lpMSKe2Wow/+vDJzHwTEdhDcOrQKjF1RAI5LJoTL78cJi7nXd1
         63VA==
X-Forwarded-Encrypted: i=1; AJvYcCXTnKTDd5Ve/y4Ku8o7kTnWgOPHP4p7IgNfV5GyIMokv/xdrbggYIPWQdogfFp1wYY3pEQ3GIwckCk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyzZMEDfJ5AyGkDyyTyH/yzQuTgkt5BV6lDeJWCvXdUczWjXSEm
	5204ay7AtJwunz8z2qvepIAHDEKz33ueahiJJd2SakQxqrcBVERJqJg6r8G42tv2Xw==
X-Gm-Gg: ASbGnctzyngsGHcQb+1Jk3AlSdocIzCPCiR8f9WX+Lc4nB3ZHc0LKLqJk8QxnwSaA+p
	QBsFEKdNGMIrn1kAV7eMVRzVEJxa3Vgh7eBaIV42rHubGXRsliadpPRWx8R9EY7y0qP0vnsxEEO
	5VVT6m2kfKlVzuUA2PHBOv4PVJveErAb9oLlAjDIi4esUzZNUMapvb2gyFmJWrJ0AFBK2/Oazj2
	wAIQxXTBc2wppB0kAT4rDqq1xqbi0u9kC/PkXhHk0cJ6RecUAYNoz5KTYVJRs/iLyiDUrROBD2p
	dU1JCazUp73OvNzMqClrQeCwvF9j9daHrTbz16FlqrRAjYgB7MfTisO07Eb5THXtvkJODCpvpQ9
	6xBJ6euwlrxe+cPO7nwzJSgZkbuDzWCdxe+b8
X-Google-Smtp-Source: AGHT+IGrY50CqtMCczgXM+SVHPrh6Ru9ASkXq+24Hf4GO9BQFJDIqoF7Kh2tx4MLNpDCFJOaTWg8XQ==
X-Received: by 2002:a5d:5f42:0:b0:3a4:e6b4:9c4b with SMTP id ffacd0b85a97d-3a51d8f6bbfmr1206717f8f.1.1749023978350;
        Wed, 04 Jun 2025 00:59:38 -0700 (PDT)
Message-ID: <20a7bc79-2359-4ee1-9d42-fe8524a2d3e1@suse.com>
Date: Wed, 4 Jun 2025 09:59:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/boot: Fix domain_cmdline_size()
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20250603235628.2750156-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: <20250603235628.2750156-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.06.2025 01:56, Andrew Cooper wrote:
> The early exit from domain_cmdline_size() is buggy.  Even if there's no
> bootloader cmdline and no kextra, there still might be Xen parameters to
> forward, and therefore a nonzero cmdline.
> 
> Explain what the function is doing, and rewrite it to be both more legible and
> more extendible.
> 
> Fixes: 142f0a43a15a ("x86/boot: add cmdline to struct boot_domain")

I don't think this is correct. Iirc I even commented on this apparent anomaly,
being (validly) told that it preserved original behavior, where all the code
was inside "if ( bd->kernel->cmdline_pa || bi->kextra )". Since I had asked to
fix this already back then, ...

> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 
with the Fixes: tag corrected (or dropped, for simplicity).

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 08:08:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 08:08:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005192.1384704 (Exim 4.92)
	(envelope-from )
	id 1uMjAD-00072S-OO; Wed, 04 Jun 2025 08:07:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005192.1384704; Wed, 04 Jun 2025 08:07: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 1uMjAD-00072L-LY; Wed, 04 Jun 2025 08:07:57 +0000
Received: by outflank-mailman (input) for mailman id 1005192;
 Wed, 04 Jun 2025 08:07: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 1uMjAD-00072F-1V
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 08:07:57 +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 04c79826-411b-11f0-b894-0df219b8e170;
 Wed, 04 Jun 2025 10:07:55 +0200 (CEST)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-442ea341570so45351415e9.1
 for ; Wed, 04 Jun 2025 01:07:55 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-747afed4566sm10661082b3a.80.2025.06.04.01.07.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 04 Jun 2025 01:07:53 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 04c79826-411b-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749024474; x=1749629274; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=LieOTA9FfiY7vHi/zrl88X3f6M26S9qGc7eS+VMX0lg=;
        b=OJMJwQS6DTb9KFutsXHpwLP+jNa7nPuewKN/Jc+yBXGZY7+/4/W2YEkxXgpHYMGD0f
         mawpMDriuoihgC2iiuZMcc6qii0akt7MComjxRQ6+Dy3q9Gl1nM9FVKR91k4J6SvRRAD
         G56c3wvmsXD1Kf+yjfQxXyTxPTl+fxUZ6tN3u7kKSpb2mqO53TtUrtLXyumeoj6jGiq8
         2kLeHGfYh3I7n0pTeQmzKB2fdMPNpGaVhnoW4Dho1/rKUKsWgUpEwDSznUxMG2JQXxWb
         lw4vOGaGN3xjD05T7gA2IgP+1zICzv1pIoxeeSoWuDNZG9YyE0Q3ZXIF9nJRxXXMAlEd
         kwSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749024474; x=1749629274;
        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=LieOTA9FfiY7vHi/zrl88X3f6M26S9qGc7eS+VMX0lg=;
        b=BjctsfoHkGkzJ7HJr8BQd3rwWzfRi8ADsYmRSoAGR91AyYUap3BkPv8C5wk6JO6QIX
         fu4S2DY+jCrYp9FJ75XpxTYsu6fLEOgpnQ62eLsuFMdMG6LOA2ddkxQmm/wrzkxOqqRc
         a64yTSV+Nzc44V4qRak2/vE2OWMj0U/qUnOl6vipsp3upeoxjnvbOfbslSnsj3CLLNrQ
         OsmVxIhgDpX1NRo/y1E2qNhmjfJ3tFIvTAWGnKi26tNOfr7J/ovAi6C6OQSsYEdhPGZp
         IoJsrqkMxx8wklg5NSgn4hrjSYjpYBk/YXYfKA0NfGc/HH0cs2qcxt93mvZrUvC+DGJh
         LYng==
X-Forwarded-Encrypted: i=1; AJvYcCVtnJpOoC6J78drm1msqUDpp7CIpEADULtC381vaX+WxLrkGyqAy61k8xgnA7GjLHFvRczOupD9f9U=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy0beCDURKzH3lFwLav2MK+eq6CMHehlFmd7uDhCfu7136ELW3W
	ApGso87AGZ7wJKbPtG6ZvrWTzFTTanIBp8POvREhYcT+H3Kz7HNrmf43SyMBZvWuNg==
X-Gm-Gg: ASbGncuyS6LS4DkgTUfA31IhokFafbEUeN8gVjhv0U+mQ2W1lKOXKCha/DsmFdnNvMN
	JGz6g4PEkwZr5cCAya/ukUUQfkA6ZzgTwr2dNyreJH0Ck2esInVvquXqbrWHOdJfnAItGeOCCiu
	fpCAahv45H0Lbp91AuA01RyvDy+Q64RIzUymc1TSpu2m+2em69kuYY4s219sliAPmW2tCSLVlMD
	achZbAB8fFndFPiQrzB6aiMT8t5zmgr71dMTHNKxqdzTHgvu5AwlRDNkDlD7wz8ohNCoShYHqDF
	crJYkAwgwLvi+X/EI2claciFS/ajnwv3ZyX+6dLzGX6ZmiX9QRGP+9xbi6enjdWRpSviWVIU5+U
	34A+TmIZHaxO8XlrBEGYcGBTYJE0NJRIQi78yX3aAzzNicR4=
X-Google-Smtp-Source: AGHT+IFPlLzhL7zpk4RRgRhoF5OJP5moBTZIMCiHuVjSUvw5+V62ROjnmRfT11TxDGnOld77BAQKdw==
X-Received: by 2002:a5d:5f48:0:b0:3a4:ead4:5ea4 with SMTP id ffacd0b85a97d-3a51d930f6cmr1452485f8f.24.1749024474348;
        Wed, 04 Jun 2025 01:07:54 -0700 (PDT)
Message-ID: 
Date: Wed, 4 Jun 2025 10:07:46 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tests/vpci: Use $(CC) instead of $(HOSTCC)
To: Michal Orzel 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD , xen-devel@lists.xenproject.org
References: <20250604072128.16628-1-michal.orzel@amd.com>
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20250604072128.16628-1-michal.orzel@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.06.2025 09:21, Michal Orzel wrote:
> When cross-compiling, HOSTCC can be different than CC.

I'm sorry for being pedantic, but the two can also be different for other
reasons (and I'd like to avoid this becoming a bad precedent, then getting
copied elsewhere). Both may target the same architecture. Hence I'd like
to suggest ...

> With the recent
> `install` rule addition, this would put a binary of a wrong format in
> the destdir (e.g. building tests on x86 host for Arm target).
> 
> Take the opportunity to adjust the `run` rule to only run the test if
> HOSTCC is CC, else print a warning message.
> 
> Fixes: 96a587a05736 ("tools/tests: Add install target for vPCI")
> Signed-off-by: Michal Orzel 
> ---
> Changes in v2:
>  - change Fixes tag
>  - add `run` rule adjustment from Roger
> ---
>  tools/tests/vpci/Makefile | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/tests/vpci/Makefile b/tools/tests/vpci/Makefile
> index 9450f7593a41..f2226a5543bc 100644
> --- a/tools/tests/vpci/Makefile
> +++ b/tools/tests/vpci/Makefile
> @@ -8,10 +8,14 @@ all: $(TARGET)
>  
>  .PHONY: run
>  run: $(TARGET)
> +ifeq ($(CC),$(HOSTCC))
>  	./$(TARGET)
> +else
> +	$(warning HOSTCC != CC, cannot run test)

... s/cannot/will not/ here. Alternatively, -dumpmachine output of both
could be compared, yet even that would leave us with false negatives
(e.g. x86_64-suse-linux vs x86_64-pc-linux-gnu as I can see for my
system compiler vs the ones I built myself).

Jan

> +endif
>  
>  $(TARGET): vpci.c vpci.h list.h main.c emul.h
> -	$(HOSTCC) $(CFLAGS_xeninclude) -g -o $@ vpci.c main.c
> +	$(CC) $(CFLAGS_xeninclude) -g -o $@ vpci.c main.c
>  
>  .PHONY: clean
>  clean:



From xen-devel-bounces@lists.xenproject.org Wed Jun 04 08:11:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 08:11:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005202.1384715 (Exim 4.92)
	(envelope-from )
	id 1uMjDL-0000S0-AE; Wed, 04 Jun 2025 08:11:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005202.1384715; Wed, 04 Jun 2025 08:11:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMjDL-0000Rt-70; Wed, 04 Jun 2025 08:11:11 +0000
Received: by outflank-mailman (input) for mailman id 1005202;
 Wed, 04 Jun 2025 08:11: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 1uMjDK-0000Rn-DH
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 08:11:10 +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 7890c3b5-411b-11f0-a300-13f23c93f187;
 Wed, 04 Jun 2025 10:11:09 +0200 (CEST)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-ad8a8da2376so1072471666b.3
 for ; Wed, 04 Jun 2025 01:11:09 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3130b823094sm899271a91.1.2025.06.04.01.10.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 04 Jun 2025 01:10:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7890c3b5-411b-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749024669; x=1749629469; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=W6s1y9MSe1f3GMnf2G7luNsLZfAczGqpzbbZXynEbAo=;
        b=Jj1MXCwoFms0HyrDNybInLrrEbzVt+xhv6tIv93HUUE9KLsVWaPF4gEDVHXR64+p/J
         Rl5zTj/RpXcEl3bjDL8OahkeTw568OfDnMmk81HQzyKHXbddxplbIO00W61QVHNSA3kZ
         rSRrpOffutS0PEP9QzK6NCSpBmtEe6FrEyzSCn2uqxHRHDH6q7Xy8txj4XkjDCAYsVky
         Dk7QPGNI4Vp0xf4EzQaLnD+b2l2ISV+zGIaLgrByZlUZ37j7720ARIQ3M3zMVMzi7k/B
         7AfNq4cYz0GSswA1NMdcLcgEqwPp2GE64m4KaKsqkYdFuxY6HTMZqhsOegHX0tesGlXw
         XvIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749024669; x=1749629469;
        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=W6s1y9MSe1f3GMnf2G7luNsLZfAczGqpzbbZXynEbAo=;
        b=g17WdYSYhUSTKgimJj1SC17x8/VlEUmJ9WSiHPIMShj7zewaeKAjltnwv5TzmzZKYA
         m1PqzZRP7x539gD8RB5qKlVYScsVTuxPQjbTVJIloMpUSnGMBPX6C8AZ6rqotETXkikm
         s+e3BFZQ57kAakQHCuFYFkkuPY6jFA+PZ5/lkWvgeKwGHeHvPIcoPAQMk3VOoKGiYOue
         BUWww3k4EyTxY8U2mbaVSYVFhyaRVel4nmSxL6yJESK7lqhNl6x9JIIyyaUuoq/ab52Q
         F5LOPt3hWmCR4n73vhUQfJOJRNXVNgfHjH8KrO6wo2Fa3/BuzinrKO4RygBdew9taN2e
         4tKQ==
X-Forwarded-Encrypted: i=1; AJvYcCURTdGyh41yH8fewfMsygRv0+7n/Vx8tIXtKiL0fAoWHynWYBznHzwxsS5fjJVH8UO8FNfjArceHCk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyH3ZvPwlnGCdHagK68r+r//lDwj4wRYM7f6QATDvv/SxLZLzvJ
	yTdZQSppJsR9+MhfVr1zhoGG8rugrGVyzuPpTWqwtUj0gUQWAVwG6JxC+Lr6JKfR7LrBrKEeQQT
	21DY=
X-Gm-Gg: ASbGncsYveRrgmxwEqvTKLjofmaexqEvwZ9HQy6+VgxDd8kqAExrpitSXKr5GIdICi/
	L38aJ9MjhPVX4w1zTzf23efeWdetbN4v+TL2qaofG6DaHB8ylFOQUnAShnCumyc5bX90IuEnLk4
	LBb5vF3cI3AIQ6NJ2b/pi0YRiwVvcJlxsHyNjVAo12yYnj5kri97Km8S768J63kd80F9W+UwcJ+
	MZar6pges3w1SFi0ltufl03TjOrf1zKgUHvOEU3tyhfi4R/xSMdR76TKxqDxW7vLBNr7zXSGCby
	0Hc+4BU9AccrHIj4LP6BF6TXR2bzTCvDc/zNY3SPkmS+LanyM6N19wit7L5zIM6tbJiemzC38eo
	fOQpC6ZXnUlb8DzV44RaTpJcqtOKrOvSimsd9
X-Google-Smtp-Source: AGHT+IFrJ/orOagyAJymgJPSg/DJVqruqyKhIrkVeGYAF60SbrJ+3Q3sY0rzE/YfsLCXA6Yoo+krKw==
X-Received: by 2002:a05:6000:2892:b0:3a4:f661:c3e0 with SMTP id ffacd0b85a97d-3a51d9807eamr1500605f8f.45.1749024656883;
        Wed, 04 Jun 2025 01:10:56 -0700 (PDT)
Message-ID: <84a62d70-a60b-475c-b0d8-275528dd4f33@suse.com>
Date: Wed, 4 Jun 2025 10:10:46 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] automation/eclair: update configuration of D4.10
To: Stefano Stabellini 
Cc: Andrew Cooper ,
 Stefano Stabellini , michal.orzel@amd.com,
 julien@xen.org, roger.pau@citrix.com, bertrand.marquis@arm.com,
 federico.serafini@bugseng.com, Nicola Vetrini ,
 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.06.2025 03:11, Stefano Stabellini wrote:
> MISRA C Directive 4.10 states that "Precautions shall be taken in order
> to prevent the contents of a header file being included more than
> once".
> 
> Add a SAF tag to the existing comment on top of cpufeatures.h.
> Add a header inclusion guard to compile.h.
> 
> Update ECLAIR configuration to:
> - extend existing deviation to other comments explicitly saying a file
>   is intended for multiple inclusion;
> - extend existing deviation to other autogenerated files;
> - tag the guidelines as clean.
> 
> Update deviations.rst accordingly.
> 
> Signed-off-by: Federico Serafini 
> Signed-off-by: Stefano Stabellini 
> ---
> Changes in v3:
> - fix copy/paste error in process-banner.sed
> - fix comment in cpufeatures.h so that ECLAIR picks it up properly
> - remove xlat.h deviation thanks to Jan's patch

With this in mind, ...

> --- a/docs/misra/deviations.rst
> +++ b/docs/misra/deviations.rst
> @@ -30,6 +30,19 @@ Deviations related to MISRA C:2012 Directives:
>         not to add an additional encapsulation layer.
>       - Tagged as `deliberate` for ECLAIR.
>  
> +   * - D4.10
> +     - Files that are intended to be included more than once (and have
> +       a comment that says this explicitly) do not need to conform to the
> +       directive.
> +     - Tagged as `safe` for ECLAIR.
> +
> +   * - D4.10
> +     - There are autogenerated files that do not need to comply to the
> +       directive.
> +     - Tagged as `safe` for ECLAIR. Such files are:
> +        - xen/include/generated/autoconf.h
> +        - xen/arch/{arm,x86}/include/generated/asm/\*

... why not deal with at least the latter (we may not want to fiddle with kconfig
sources) as well?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 08:25:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 08:25:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005216.1384725 (Exim 4.92)
	(envelope-from )
	id 1uMjR3-0002Ob-Ea; Wed, 04 Jun 2025 08:25:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005216.1384725; Wed, 04 Jun 2025 08:25: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 1uMjR3-0002OU-Ak; Wed, 04 Jun 2025 08:25:21 +0000
Received: by outflank-mailman (input) for mailman id 1005216;
 Wed, 04 Jun 2025 08:25: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 1uMjR1-0002OO-Lu
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 08:25:19 +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 71fa569c-411d-11f0-a300-13f23c93f187;
 Wed, 04 Jun 2025 10:25:18 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by CH3PR12MB7763.namprd12.prod.outlook.com (2603:10b6:610:145::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Wed, 4 Jun
 2025 08:25:14 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8792.034; Wed, 4 Jun 2025
 08:25: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: 71fa569c-411d-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=j9uweb1VZ87CrPOXpUV0JQ9Ta6Ur/9Uf57rXK8/6swxvEgI24oTUumcmh+vWZy3S6tuG5SVuwuee7P5JpAZ54BZpU2enj1jAv4g97rU4RJZOuJp0vR7A/NRXou06/tkIw1/NnrtLpy9vV3Mtf22Ht1HXIiGFlSLpssz+OhV9I81Vu4Pgw1GpHOjc8NIsL8UzxEZvMaIZQy6DOIGTU4mvIYMfmYKLs6IUEUW9f2P2ltUPifWUIxPLq1/smq+R61b76bFNxenhmVEDNtSUtwQW0Wc4egl5F+N1ymyOdLPDLLgERKj4eAXY/3H89+VozK2O7otiY6Y6G98VSk/1+4a54w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=bjpbt+0/ueKdclJinFewhBc63ULLjOAw6TcJiBj7BW0=;
 b=xlSNwKpPzbBZKMXOeZ//mN8gAreroNofy6M47tAMT0l60krd6+NUYcqA8X/vj8el6x4zo95AE1/AJSKLem2hqixG5kapEJQE5MFgs8ZaAdHEWSEdip1PYlBoP/0+tMesvY1EDHzNKyXZu5e9CUg936ZpT91+a189TXAatJALE5brUpBkY6xRwYr4ubSwSxKeb/SD+OfZqUMKjO8n1Ih1D7gGytvv4LP7/dMh1RkPsl/hodifnmjFSIow8P1UkIScswZC4OZw8SfnRPAoELh2PdSrKtqzsDDTRG/pAQHwMrc8M1/R3be1H5KoWHjqdZGzCpxWiO6leS+3crZZFfZW4g==
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=bjpbt+0/ueKdclJinFewhBc63ULLjOAw6TcJiBj7BW0=;
 b=GJRFKvw3eMWoNQSEc5stjGiee8moOdUeIR3AxgAUkmQv44yGnB7OfPiuPwwF/pGm/JpI4Xf3lk1K6uGW0tzy1VRP4kYpnbu4HrPGsX4EP8pllw60VNQelqmtHKPArf0nwpNu52PvQ7k5FOBEgcekrrfwcmk3WXzv2QQQhpkLtAU=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Wed, 4 Jun 2025 10:25:07 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tests/vpci: Use $(CC) instead of $(HOSTCC)
To: Jan Beulich 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD , xen-devel@lists.xenproject.org
References: <20250604072128.16628-1-michal.orzel@amd.com>
 
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: DX0P273CA0014.AREP273.PROD.OUTLOOK.COM
 (2603:1086:300:26::19) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|CH3PR12MB7763:EE_
X-MS-Office365-Filtering-Correlation-Id: 73900408-ea8d-4ee9-99ac-08dda3415490
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?b1RXZlpORGQvWmh2azhPcDJ3VEIrb0VwVVFWYmQrSm41SEMvYjJZR1ltY2p1?=
 =?utf-8?B?RjZMeGdxbDJmQmdDOElYTXlPN2tuWmpydGplZ2k4RzRQMFdwTlhNOG04dmpC?=
 =?utf-8?B?NEhMK05oWkxjMzNFUWlkUTRRRmlzNFAvWE9UNnIwOC9ONjV3RjlTbUlZL2J4?=
 =?utf-8?B?KzdHWVAycEpwNjBPbE9mY29pZU9xK3FObmZSUWJzUmJORXA0MDhtcjBUMlpm?=
 =?utf-8?B?YnFyOEg2d2pMY1pPV1UvVmxhRXhROE9aaXowT3Y2Qjd3M1pKODhIVU56cTNo?=
 =?utf-8?B?Q01PaXc0cWQ3ZWIvb1hLVklHbHhRcUtRY2FwN3hPY2JuYzRDMDJSekdRTzhJ?=
 =?utf-8?B?d1ZXTWZEMTMzamVIYVo1WnJUbkFkdHZiL0xZSndoOGdQVFU1YURud0o1c0tE?=
 =?utf-8?B?d1dCYzFwTk1QcEdUSGU2eUxlR2cxVzZWMDUzTlhVZk5HeCtIamZ3d0VoNWo2?=
 =?utf-8?B?dHhTYmJwQWh3QXM1WURxR0dDVS9FcTJrWjAyVUhlbzNIc0ovR2IzL3NwYTJT?=
 =?utf-8?B?cm5pTjA4Mm9QcFA1RkN0QjFhQ1hHVHhSU1RuL09uWlRtWDVPM2tYNmJKV1N5?=
 =?utf-8?B?aVBlckgrN1Zjb3JJYzQxNmJEMjBMZWx5MllIUnp0ZllVWVpnd09hUldjaFdN?=
 =?utf-8?B?RFlFbW9weUMxQmI1a0xLcXJ4K3RSTllzcFdqR2ZqSmhHektVY0JpN2FzV3cx?=
 =?utf-8?B?S0NvUFJUT3hIdUtrNGZicldwd0h4cHdLb0lVbDRWc294SmdrUWJQdkZMNnBu?=
 =?utf-8?B?U2hsdW5UQVhYaHFPbXBnTmwrSnp2Y0g0dGdndW1obTlHN2JyMzFjeFhYV1cr?=
 =?utf-8?B?Z1hSUnZuVlFmaUp0UkVDSTVqWUNMZjVvdVU2OEt1dGUrRGVoL1ExaWd4QlJQ?=
 =?utf-8?B?NXBqSXVkcUNPdVRRMExaQy9hdXJlSS9Zb2M4cEtZSndTMTVabHZoMFRyQldW?=
 =?utf-8?B?Q29VWHc2VFZWWXFScjlGc1hybXZsU3MrYllnQnNWbjV1TjdGQmU3ajlMMG1a?=
 =?utf-8?B?Q2dMSTkyQ2p2MEtLU0dnbWs5YlpCTU9SdXorZm1KZlVnYjB4TCtlUmROelhl?=
 =?utf-8?B?elpxYnRnN3lLTVZDckp4SjFDVFJPZ1ZObERVV0NqMjd1QXJ2VDI3NllKdUls?=
 =?utf-8?B?VC9LT3hYTjc3MTNwaTBCL1NCd0tDNVMvVEE1eENYY3RvZ2p1eGpUUUY3cnVG?=
 =?utf-8?B?UXhMK2pLdFpzVlh5SldBMUs0WGgxTTlRSE0yeGlHckJCSk9hZThjcHVCVVI4?=
 =?utf-8?B?MG81aDRLeTNsMGVJd1EzU01KSit0ajhyWitocHcrSUVLc2dtbWZwM2F5ckl6?=
 =?utf-8?B?aVFmL2FOSms5UVkrd05TaW45NmMvUnVuWmp6d2R6OUZ4ajVHb0NPWHVRZTFP?=
 =?utf-8?B?NXV1NEVkUnAwbTBmTVdhQ2czS01mYVNsU0o0NG1jakN3YkFLUHhDeFZIa1pn?=
 =?utf-8?B?dDlteTkvdWpSOEFnUlBOaFEycXRMZUJSNUcwUVJQZjhqMHdsTFFTam51OHFl?=
 =?utf-8?B?TVZQZHVQVUhUSW1hWGgzOU5HLzREbHhBbCtFbFlvbUhaZjdxdFM5M0JGTUJx?=
 =?utf-8?B?Rllra3BVeWlnRU9QSXhtZmluSkNVL09tMGt3WUNqYkxkZUd6MHVML2wvNHk2?=
 =?utf-8?B?Mm0zN3ZoZy8rTk5JcGdZa1BQT2FxMzF4cVFxUFNmVm5WM09oRmFFMW4zbHpG?=
 =?utf-8?B?dEs4Zy84RENnUjBaYWFYU3ZTbCtSZTVPUHdxZDlJemVkR0ZjOGlhQVRJVUQy?=
 =?utf-8?B?RXVNTFdKYVBWVTJWc3pHTU52WldXdW4xVWR3K3FDRGdkYldoMkhDenNWUUVw?=
 =?utf-8?B?U0wvTm1MMG50ZEpVbTlNWk94cFlJNHk1YmdldmZrRDJ2RTRyZlVjeHk3Q2Ir?=
 =?utf-8?B?bHFEUjFnZldGR09xWTlXVFlocmd3WmFDbXplb3UwODRXZFVQbmtPNjF3Smhk?=
 =?utf-8?Q?d89TXeUrVyg=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.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?REdCS0dLZ2pWUmxuVUVtU3ppb09sOXZvbU9iK1AxbzFXV1J1TjVTYU92T3Fr?=
 =?utf-8?B?allqYTVGVFl6UThOdnNIaTJ4d212NEw4SE5PaU5OdEQ2Vzd4ZFFCcGVHQzBZ?=
 =?utf-8?B?Q28vNGpUcG1OTC9wZE8xVUxHOTl3aTNKcmZPUnlRVHN5Y2VVRUQxbXUreWF2?=
 =?utf-8?B?WE13VjllcmJZVTFhRHZ3TlNIRStkaklMUUNSK25qVjVNbUpWZWFaM2ZaZ2pO?=
 =?utf-8?B?Q2FZVjFHQUJGblZtdTcyYmZ3ZWsyeDlsdFo5RHJBSXJDSGFTeFBlc3IyK2xv?=
 =?utf-8?B?QkpuUW5RTUNzbDYwNFlTRWpEaXpyUUVIWWZ2OEJGUStwRTdOOGF5citoVmxS?=
 =?utf-8?B?eENhZXM3U2J0SzF0VkhlUFFlMTJiams1RE1SZ0dtaHZiYVdDQi9Fb3NwSm94?=
 =?utf-8?B?NE5pdzNxa2p1bmRpMFpwNExtT1ROYm1STUxQL2ZJU3VoVS9iSHFBTVF3alFa?=
 =?utf-8?B?dUdMcSt2dlY2N1VGQWI5N1hPeUtxak9xYnZiaUs2bmtmSktPdE5FT3EwdEFN?=
 =?utf-8?B?NmJpTmJpc2pON0hIN0RpSENXUkZRMkplUkZ5RmZjS05UVXBBS1JvK2oyYzlJ?=
 =?utf-8?B?a1BPcEJRSEFzUXZxRUJqNjlpUnMwRTRiVUNxYnVtVTdZb08vdmFsYXBVbzN3?=
 =?utf-8?B?VDRaOTF0R1oxMTBCMklBMCtQeS82andHdkl4bm1zUWJnZjZic3dlZTF1MGFR?=
 =?utf-8?B?Q1MvT0hScEhiaEFuVCtTUWIvMTNNM0g0NTVzaEF5R1p4ZGRLWFFMMzRvQU1J?=
 =?utf-8?B?Z1lFajhVVEJ5TUpWNU1JNnNxU3hySDR3WkRTU0ZieUFybnhHTXh4My9FekRU?=
 =?utf-8?B?dmhTNVV0b0xHeWR3TWxzRS9WcnFaVzdZWG95Y1pJYkNhbkZsQWdFcXMvZmEy?=
 =?utf-8?B?dWZvVmdwL3hDazJOOGV6d3pTakFLZnl1M2E2YWV4UGs3MDdSeEFUdFJSL1FT?=
 =?utf-8?B?SjdaZDFJQzhJTW5OdjFtWlIxT0d2WXRGbGsrYndHbGU5YlpWMHpTME9XNEFm?=
 =?utf-8?B?TTYxZDJ6dU9jYTJESldvVWJQVEM1OEdwYk9oOUZjZ1VSSDIvZlB3YSszME5M?=
 =?utf-8?B?ckVnWHNtTzg2VzlWbTRsdjBNYm1BVGVaZkp2Smk5RkVCYUtsMlFyclVaTVVZ?=
 =?utf-8?B?dEUyOHFxc0hQKzI4Lytic1dOVVg1d3ZwVWNienJrQ1NGYlJRR3dTcWJBQXc1?=
 =?utf-8?B?OUxjSnlDSWxvMlJ3WVc0aldybFpFV2VoOGM0VXkrQzJUZjJhc08weUZNVThB?=
 =?utf-8?B?QmpieHZjb3A3aDdwaEZyUGdhZ1NheE9ndkhZZnpYNEYzVUtzeVdDV0FOYzdw?=
 =?utf-8?B?NDFFc0xSSUd2Q2UwNEV2QmUvQXNMZVJKZ3hDYkp0c3JaRzlVVktJMnhQdys3?=
 =?utf-8?B?ZGV2S2Y1dXliYVhKc0cyMk5Lc2NCYUhMRjRWcDlpWEdQazBva3ArNkI3YUNP?=
 =?utf-8?B?R0hkWWhwQU5vSmYrNHdNSlorcnpsY291aFQ1UTF2YmRJdllzaGFOVTZsLzFw?=
 =?utf-8?B?dVA2ODFLbWVKZ2kxYWFYNUd3ZEtvbGZVZTV0NGRMK21Vc1Z3cU1XSEZZYThm?=
 =?utf-8?B?V0NxMy9JZUlFK1ViVXdpRkt0UklCR3d5Zld1YUdlM083VkRTbVpwR25JdEhX?=
 =?utf-8?B?Ymp5cTJqeEhXS3NVbEJ0SU9mUXo3MEhFV0o2eWFKNmpycjQxaXhrZ0RpVlll?=
 =?utf-8?B?bmdvSCtsc3pJSlI3cGd3Q3AwWWtvd0U3ZW5HODZodS85VDZPeDBhQjVFV3Bm?=
 =?utf-8?B?WkpWWGNiSkswVVRIeGp6YjEwbnNWazFqTGNUajZTWkJyemhUTDNjY2VoaDFy?=
 =?utf-8?B?SXFIb3BVNFdYV3A4QllRTEowdEFuM091RTZtdGV5ekp0d0VPSStrVWEvZXkz?=
 =?utf-8?B?OXFGU2VNaGR1Z2hzSUsvRkZKQ2lQMCtpdDc5dDJqMUZGT3JsVnZBdEMyMThO?=
 =?utf-8?B?cmd0VXJvanVzNlU5Wlllc3ZXWTJkUTZma0p6bzNSNHdDSGhkYm9SNHI1T0g3?=
 =?utf-8?B?NXFHZkNybkhJcmsyWWNOb0cveU1WUjF1djNxc2dCUmV2UjNadkcrZWl2Z2ZX?=
 =?utf-8?B?a1RVWjY0a1R1OHk2dW9Pb3NrNklacGFWcWsreGtzVlc1Mjd1ZUhPRVp2b1Fl?=
 =?utf-8?Q?MnZw=3D?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 73900408-ea8d-4ee9-99ac-08dda3415490
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jun 2025 08:25:14.6086
 (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: MhxSkkC94aAh86Md0WMFLeAPxYNZu/XuIdIFDdjuYJizece0HPLUsrRs06DuTx8V
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB7763



On 04/06/2025 10:07, Jan Beulich wrote:
> On 04.06.2025 09:21, Michal Orzel wrote:
>> When cross-compiling, HOSTCC can be different than CC.
> 
> I'm sorry for being pedantic, but the two can also be different for other
> reasons (and I'd like to avoid this becoming a bad precedent, then getting
> copied elsewhere). Both may target the same architecture. Hence I'd like
> to suggest ...
> 
>> With the recent
>> `install` rule addition, this would put a binary of a wrong format in
>> the destdir (e.g. building tests on x86 host for Arm target).
>>
>> Take the opportunity to adjust the `run` rule to only run the test if
>> HOSTCC is CC, else print a warning message.
>>
>> Fixes: 96a587a05736 ("tools/tests: Add install target for vPCI")
>> Signed-off-by: Michal Orzel 
>> ---
>> Changes in v2:
>>  - change Fixes tag
>>  - add `run` rule adjustment from Roger
>> ---
>>  tools/tests/vpci/Makefile | 6 +++++-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/tests/vpci/Makefile b/tools/tests/vpci/Makefile
>> index 9450f7593a41..f2226a5543bc 100644
>> --- a/tools/tests/vpci/Makefile
>> +++ b/tools/tests/vpci/Makefile
>> @@ -8,10 +8,14 @@ all: $(TARGET)
>>  
>>  .PHONY: run
>>  run: $(TARGET)
>> +ifeq ($(CC),$(HOSTCC))
>>  	./$(TARGET)
>> +else
>> +	$(warning HOSTCC != CC, cannot run test)
> 
> ... s/cannot/will not/ here. Alternatively, -dumpmachine output of both
If this is just s/cannot/will not/ I hope this can be done on commit.

~Michal

> could be compared, yet even that would leave us with false negatives
> (e.g. x86_64-suse-linux vs x86_64-pc-linux-gnu as I can see for my
> system compiler vs the ones I built myself).
> 
> Jan
> 
>> +endif
>>  
>>  $(TARGET): vpci.c vpci.h list.h main.c emul.h
>> -	$(HOSTCC) $(CFLAGS_xeninclude) -g -o $@ vpci.c main.c
>> +	$(CC) $(CFLAGS_xeninclude) -g -o $@ vpci.c main.c
>>  
>>  .PHONY: clean
>>  clean:
> 



From xen-devel-bounces@lists.xenproject.org Wed Jun 04 08:48:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 08:48:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005272.1384751 (Exim 4.92)
	(envelope-from )
	id 1uMjnX-0005lW-D5; Wed, 04 Jun 2025 08:48:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005272.1384751; Wed, 04 Jun 2025 08:48:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMjnX-0005lP-A7; Wed, 04 Jun 2025 08:48:35 +0000
Received: by outflank-mailman (input) for mailman id 1005272;
 Wed, 04 Jun 2025 08:48:33 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uMjnV-0005lJ-Ix
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 08:48:33 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uMjnV-001pP7-0P;
 Wed, 04 Jun 2025 08:48:33 +0000
Received: from lfbn-gre-1-199-136.w90-112.abo.wanadoo.fr ([90.112.161.136]
 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 1uMjnV-00G5Ij-0v;
 Wed, 04 Jun 2025 08:48: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=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date;
	bh=FJf7+sWC+t6EWeV6vCfTbl0TfGzNfB1Wkn38FwFxXcQ=; b=yoOeojKb55O1bqC21myeD5ieFt
	NwwsayHMaCpv/zCv0yX7KO0gFvE1HMrEMrEkOqHVtv+zAMVKe5jht921ZreT93g5/cWMv8MHcUJfs
	egbiKqdhgsdmoy5PNvKKJu4r/c4XefZ/RshRZUKvwCacZed8hbVoWSxKqAyQopQoM8Lk=;
Date: Wed, 4 Jun 2025 10:48:30 +0200
From: Anthony PERARD 
To: Stefano Stabellini 
Cc: xen-devel@lists.xenproject.org,
	Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= ,
	Andrew Cooper ,
	Anthony PERARD ,
	Doug Goldstein 
Subject: Re: [XEN PATCH 9/9] CI: Add timing to junit
Message-ID: 
References: <20250603124222.52057-1-anthony@xenproject.org>
 <20250603124222.52057-10-anthony@xenproject.org>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 

On Tue, Jun 03, 2025 at 11:35:22AM -0700, Stefano Stabellini wrote:
> On Tue, 3 Jun 2025, Anthony PERARD wrote:
> > From: Anthony PERARD 
> > 
> > Signed-off-by: Anthony PERARD 
> > ---
> >  automation/scripts/run-tools-tests | 5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/automation/scripts/run-tools-tests b/automation/scripts/run-tools-tests
> > index 852c1cfbcf..e38cc4068c 100755
> > --- a/automation/scripts/run-tools-tests
> > +++ b/automation/scripts/run-tools-tests
> > @@ -18,9 +18,12 @@ for f in "$1"/*; do
> >          continue
> >      fi
> >      echo "Running $f"
> > -    printf '  \n' "$f" >> "$xml_out"
> > +    time_start=$EPOCHREALTIME
> >      "$f" 2>&1 | tee /tmp/out
> >      ret=${PIPESTATUS[0]}
> > +    time_end=$EPOCHREALTIME
> > +    time_test="$(bc <<<"$time_end - $time_start")"
> 
> As it looks like no other scripts need bc at the moment but we already
> rely on awk (automation/scripts/xilinx-smoke-dom0less-arm64.sh) I'd
> prefer this version:
> 
> time_test="$(awk "BEGIN {print $time_end - $time_start}")"

You mean I have to choose between busybox and busybox?

$ ls -l $(which bc awk)
lrwxrwxrwx    1 root     root            12 Feb 13 23:19 /usr/bin/awk -> /bin/busybox
lrwxrwxrwx    1 root     root            12 Feb 13 23:19 /usr/bin/bc -> /bin/busybox

:-)

I guess it doesn't really matter.

One difference though:
$ awk "BEGIN {print $time_end - $time_start}"
3.28798
$ bc <<<"$time_end - $time_start"
3.287982

awk is less precise, but I guess that doesn't matter as well, gitlab UI
isn't going to show the extra digits.

So I guess I can change to use `awk` instead, just in case for some
reason `bc` isn't present, since `awk` seems mandatory for many of our
scripts.

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 09:05:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 09:05:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005279.1384762 (Exim 4.92)
	(envelope-from )
	id 1uMk46-00006D-Qe; Wed, 04 Jun 2025 09:05:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005279.1384762; Wed, 04 Jun 2025 09: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 1uMk46-000066-LQ; Wed, 04 Jun 2025 09:05:42 +0000
Received: by outflank-mailman (input) for mailman id 1005279;
 Wed, 04 Jun 2025 09:05: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 1uMk45-000060-G5
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 09:05:41 +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 15777d14-4123-11f0-b894-0df219b8e170;
 Wed, 04 Jun 2025 11:05:39 +0200 (CEST)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-451d6ade159so31418645e9.1
 for ; Wed, 04 Jun 2025 02:05:38 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-450d7fa23f4sm199000615e9.14.2025.06.04.02.05.37
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 04 Jun 2025 02:05:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 15777d14-4123-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749027938; x=1749632738; 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=TVb5eqYruBVqHy+zG7LsLfZyeooeoPVXNOTackwmwOg=;
        b=FC0ewMQIUwvw7yeGI8yTfzo9MohSoQRFP+YjJNHshwoyf7xSf63iuoiHdNlMm96BLJ
         iTzku2WCwQjOCV06Ht77ilCaevuTDif7V0AnWBZEmvqG6oCf5CYZZlbZRl5LjoFFd6rw
         8W731yy3VTmkXmRyCJVFx6CpZYarhA+arCueo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749027938; x=1749632738;
        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=TVb5eqYruBVqHy+zG7LsLfZyeooeoPVXNOTackwmwOg=;
        b=NwV3muhVKF64n32Z7kMxHNKQXuUE5V8EAslm6FsfO/ju1pug/ZoNzY592RRDeUsAhi
         AWThbRSXtOdYVjRm1tP6DmIzB0kuTs/QpEm47im+WEE2Ohx9hp8FQmY4IuzKAyebB4JN
         3Lq2mQxH/RTPaeDUYuLU2eBk1eQxO+NcS6E1L3ZfkIzA7KdgcMyraI1XDekecoTxQj0d
         D0VAhtZL3VfVi79neAIFIk3WTDeEHJe3AADoql4WKjalXXm8O470fBCpMvYxaQ3pEEBv
         TdycdyJkJ5O5HpsF4foLMkNgbMkH889vceeXHuBc6Jd1MQSfK9WPu/dc5B+tCqBxZwto
         TxzQ==
X-Forwarded-Encrypted: i=1; AJvYcCVzOtDVEdA3WDrzgOXznWYy0kaZ0FWvqzZ5JZzaXGlUVzFK5EwecE2hQohrhJJ9JX/8iGJnojeThpo=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxw/k19jhAQ6uHk0y+Xo3bvUQI+NOWR+DeFZNph+T5wOoqu+jzY
	RnEA65Duv0xk/aJO1tw8HTAtQtbXny5BAO7FcgGwGLLS8yx3DSOgc/AKBx3kntQXr3Y=
X-Gm-Gg: ASbGncsou+PQnR0RdFz5hzCHLmo5lxrj9QF1gSrzSjlW58ZLDv7P7tPZKwQ2DKX+upQ
	w/ckUpNm+JcfqnuGGOMDYbXt2NrTFuxk8BlmjKHnhiR7gzrTr856zIBsiiPDHLn5lH1+lNm/Hfn
	jaRT5RK1+7oPyHtgrKoIyJD8T9ZXdE7RfokaZ4KjZ0kc3q8KIJBdW2tclVfRQX93ok8EwZbTI3e
	MwwqRK3zcaIkGClV/fMaBoCxzn55NExW1CWot2RJJCJzkfmyIEv6bnZMo4pDPPmusTCh5c6fOUW
	ICaJu+AvH8jCfdHiOu2UUZUDu5MmxWTZty24Jr0fAUPGlhb//hQ2YiPE6nyxq72KSUWJOd6WEog
	S33c+3DyEqaN5ssLgSfk=
X-Google-Smtp-Source: AGHT+IEcUyT09/XfaNmWdciSWhU27h3VqV3bQOUkQsrKqpG8i5mraxw+h0c+zWsMBUgUfCIQ2wYWsg==
X-Received: by 2002:a05:600c:4590:b0:43d:82c:2b11 with SMTP id 5b1f17b1804b1-451f0b1e4e7mr13579255e9.23.1749027938211;
        Wed, 04 Jun 2025 02:05:38 -0700 (PDT)
Date: Wed, 4 Jun 2025 11:05:37 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Michal Orzel ,
	Anthony PERARD ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2] tests/vpci: Use $(CC) instead of $(HOSTCC)
Message-ID: 
References: <20250604072128.16628-1-michal.orzel@amd.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Wed, Jun 04, 2025 at 10:07:46AM +0200, Jan Beulich wrote:
> On 04.06.2025 09:21, Michal Orzel wrote:
> > When cross-compiling, HOSTCC can be different than CC.
> 
> I'm sorry for being pedantic, but the two can also be different for other
> reasons (and I'd like to avoid this becoming a bad precedent, then getting
> copied elsewhere). Both may target the same architecture. Hence I'd like
> to suggest ...

Would you be fine with:

"Depending on the build environment, HOSTCC can be different than CC.
With ..."

And the s/cannot/will not/ adjustment below?

If so, I don't have any further objections:

Reviewed-by: Roger Pau Monné 

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 09:22:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 09:22:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005289.1384770 (Exim 4.92)
	(envelope-from )
	id 1uMkJz-0002uW-5T; Wed, 04 Jun 2025 09:22:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005289.1384770; Wed, 04 Jun 2025 09: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 1uMkJz-0002uP-2Q; Wed, 04 Jun 2025 09:22:07 +0000
Received: by outflank-mailman (input) for mailman id 1005289;
 Wed, 04 Jun 2025 09:22: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 1uMkJx-0002uI-Kx
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 09:22:05 +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 5f8353e5-4125-11f0-b894-0df219b8e170;
 Wed, 04 Jun 2025 11:22:02 +0200 (CEST)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-604b9c53f6fso2573848a12.2
 for ; Wed, 04 Jun 2025 02:22:02 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ada5d7fed60sm1059114866b.24.2025.06.04.02.22.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 04 Jun 2025 02:22:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5f8353e5-4125-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749028921; x=1749633721; 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=iyJju7FtrJuI+Yce7p+wMhH4nnhxOspZPYR9aN/hzpM=;
        b=eofn/ggx83+bkyTBZ6kTp/vXLzkd0muV5A/tdMRMw/0mTRzTUMLNcF7HaOclZQKKZx
         JibE4mZ9VMQdKzRgrwJL6D3Zc3OhW/a1WhA4j1KKNaLqCSjasMJ8SKZpo/VoknOIr0BS
         G/GdrXyy8h+tQzyyLd2tkWPgUBrNK0OrAV9/vfj7wZ2d6GEQnSNel/FWw9uENZre7CO/
         NGZcGmHZ0W+4V4WMCJ63R5UToxZ7Hg+s7asFb1UR/w+p3AduZNduss8FL0pTewYaImgA
         QgkuQyp3kkohqGqhMBRgiDoUVdfIemoepqUDZF4igkcFu7m3/alh48uCa+aSBPm7iYky
         WkgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749028921; x=1749633721;
        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=iyJju7FtrJuI+Yce7p+wMhH4nnhxOspZPYR9aN/hzpM=;
        b=m6sC2WJvTZGMgMosQ1dlbcu49EfHqMekqJMuHg6tBQX+Cf5RWjgMYMnsVOdpozso/O
         bR2kKkTkTEEE9Yd8xVMFAAI78gJA9zbJ83WkAxk0P5n/k/WS8SPS3BhxSDhK8nAEFwHt
         M77CuPYhBLBFXTkm9gEbYPMR3Ay/w+tyJj7snME+DfiXxR9IJuhgfngps0PcL/faL3ZG
         bMtPYDGXiaAV2MSlO5vNuKjEZQKlQ6OTMIUv+g2qkMToDON+ORWDFw3JBp1D7dLFpnKJ
         C54DMeSwfnEo6zxQczK9YBqUgydqe77ZWE3dAak5cz40ENeaIZ4Hn3YejMrGudScvza2
         Xeeg==
X-Gm-Message-State: AOJu0Yxg663jXJV/y3A8yqNQxbyZGIgHOJQCLwg0xlzPD9CHsv3tvCHU
	iwhzc2GQ3jg4NH5eoGsDcEkG8xl3xaS34xtGlEEnK5dJJGX0edbwfxbLQoipSuoTv1Rz+eOk6Yw
	FBI0=
X-Gm-Gg: ASbGncuDWfgYO0CKJR7Z1XB6Zw6qXexDKwxofLGkUtkRG6GVGgqZiP7MM3a8UqYHC9N
	S6RDLXAxyGMkS4DFHZhqCcg7MKShJ/mGklE6xA3eHUsVdMoEQc5Hisc+g1gSIrbHac8FLP1hPvY
	6IpgUrseq+QzGmUPiocLX6FG8S4yBSb7JwbYcpK/vemgalijkZv2PkGHGu+B/kxhvaubba0XeQ4
	WmWVyxMkxjlNKMbFV2moQ+JBvSsR452ZFJaNeBetFVtRvAeRqQIXlo3uqJgaL0nMki+kuAv3MEm
	caPzojACj0DsgV4Asqrb2J2VlT1VwY0KPlnBkXjrmVRPPmhChEfdeKsN82zyK7R+HJ+JujCKsZ+
	SttUe6FVYj8/iclPAYtcF/Uw3zTgWuabh36Mp
X-Google-Smtp-Source: AGHT+IHBvWeQZWoOHAEtcxhVvqXA+G9HI/tcnryBcpwHkW5Ivj2urUODZ+G9/bVqQ2A05vEWN9OGtg==
X-Received: by 2002:a17:907:3da3:b0:ad8:9e80:6bac with SMTP id a640c23a62f3a-addf8c996f9mr201719966b.10.1749028921461;
        Wed, 04 Jun 2025 02:22:01 -0700 (PDT)
Message-ID: <5dadf381-0f97-4362-93ed-aa5b01d73d88@suse.com>
Date: Wed, 4 Jun 2025 11:22:00 +0200
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?= 
From: Jan Beulich 
Subject: [PATCH] x86/PV: make mmio_ro_emulated_write() static
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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

It being non-static and it not having a declaration (anymore) violates
one or more Misra rules, iirc.

Fixes: ff3e5dfa7c2d ("x86/mm: move mmio_ro_emulated_write() to PV only file")
Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/pv/ro-page-fault.c
+++ b/xen/arch/x86/pv/ro-page-fault.c
@@ -337,7 +337,7 @@ static int cf_check mmcfg_intercept_writ
     return X86EMUL_OKAY;
 }
 
-int cf_check mmio_ro_emulated_write(
+static int cf_check mmio_ro_emulated_write(
     enum x86_segment seg,
     unsigned long offset,
     void *p_data,


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 09:23:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 09:23:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005295.1384780 (Exim 4.92)
	(envelope-from )
	id 1uMkLB-0003Ou-EP; Wed, 04 Jun 2025 09:23:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005295.1384780; Wed, 04 Jun 2025 09: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 1uMkLB-0003On-Ba; Wed, 04 Jun 2025 09:23:21 +0000
Received: by outflank-mailman (input) for mailman id 1005295;
 Wed, 04 Jun 2025 09:23: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 1uMkLA-0003Od-7p
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 09:23:20 +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 8cea549a-4125-11f0-b894-0df219b8e170;
 Wed, 04 Jun 2025 11:23:18 +0200 (CEST)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-ad8826c05f2so1165049666b.3
 for ; Wed, 04 Jun 2025 02:23:18 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ada6ad6a76csm1058215966b.165.2025.06.04.02.23.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 04 Jun 2025 02:23:17 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8cea549a-4125-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749028998; x=1749633798; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=EgfiYkJxwVWx4NLZmNd8AFdJxqOQUYFs+rGR5lOtfT4=;
        b=Lrz9rR/Vqc80MiyEMVEGEwWYHaxY56PVqeXquHOvfHFhtzJzIpvMTnfYbNIVbW0/aL
         5c593oqSbUk6yEy5SncFMCBRywE1t3zYvrCAMbMVkZAAtT3CEzlzJMH55QkUAtvg7/iH
         41qEmWTbsdnxy33gmf5idGJgvjnrsj8z1wSxPDjo2wZJoBDOt1kxhKMeT3qmk+MYBHSg
         pmpDLl05Fhr/cgfon0VYeRystZe2NHqE3QKpziqxpPygrJHz8iKgGsM2++UPvL/7IR55
         XbxpvX/+mW2ePWwYeZUVyihZzfAaWJtAEtjrKgs/9ATito8YKw6w6XnQLYB4wXO032av
         HZZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749028998; x=1749633798;
        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=EgfiYkJxwVWx4NLZmNd8AFdJxqOQUYFs+rGR5lOtfT4=;
        b=ANqrc7HyT5MX58myvo+gA6Wxrlb7REDBZLfFCXBRVJ8/rt7DYHUQ+zqql61JdkDESG
         Nq/SigP7fLJ8HHTVZ75GrjxT56OusGW+1NxBaTmU6uK+8n7v/sXqjnwKHtn2GqQx6cDD
         xVdt9YRkV5VJX1m2oFNlB9Z4QmrCaT58CY+lj4qqGWQsiQVAqU6XH3GUXL4Q/BjDyQ3c
         hXTyZdWssFF8W9MqByV8ypHnZ72VVxStBwt6pxMv9Gh/nWQFSsQ9UFCEQwJjdUi/2xmK
         qfPxyj3+6/q+yxhfh9nUZPKuLcGxrphstLUhE+rrClMhxTslfs9IKE/V6b4QwnyjKsrM
         sbnA==
X-Forwarded-Encrypted: i=1; AJvYcCV5ZM9QJ3YfwcYWJ867VSO8i7ama4oNXwAIQjSyF6tHic5KGbwkt6dpywev304DuvHcWdIfEi1KKIY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YysW8DMnUxUpWwKBt9VaPKf3M9hH4wEx2DJjoqmi5iOdILGWqiV
	3xpXYsT1sQaoLz2sOvKxgHLMPHNSYqOygwy788dLpAseOsH6qVuZSmNHB4+vtrEYRg==
X-Gm-Gg: ASbGncsGJkIhbeJZB1NjpPs2JS4WLmBg/fNfYiXz40SWbuyuiL9FP0NvCUA86ZHkUBq
	bFYSYbtNCPgamXa1APzBdAlxNSHeqP1YADQg8+quFMnNBEHVbtohYGSZI/bCXA8GZz8IMbzO+/P
	fZqOZjHSj9DDA4vk9gf1MEQfqq+PTQhtjEc86oBgrm2GKEP/iMPyhFHE+z+o77eV2jVlqTq5gMC
	+PKPTgeErLg0UwSAcAhs9lAIAcRQEYmOCAHO+6XpLTr8Lx/vKOG/tRXIz+3gcse8LlpSzQgwE+M
	P2BL5KBDw6g+vt+hJf54pVdnYcvUOxguclylgPVL/z4YSeIuW4YmGfBRsET/oMOQ4UiVh1LJ03x
	KM/H7nvlJ8lsnJGi3MpWsEZ7DE+59LdcqmHW0EpkdxfTK/DI=
X-Google-Smtp-Source: AGHT+IGgpWIoPNCUsFR/msoovt5w3sOf6uBMWPPPOVA5E4ZqrSYfRtQgo0KU4rEOaHeww8YweebFfA==
X-Received: by 2002:a17:907:608e:b0:ad5:bbcb:e3f2 with SMTP id a640c23a62f3a-addf8f770f3mr173429166b.39.1749028997693;
        Wed, 04 Jun 2025 02:23:17 -0700 (PDT)
Message-ID: <874fe8cd-2fc3-4007-9616-4709b2f080a0@suse.com>
Date: Wed, 4 Jun 2025 11:23:16 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tests/vpci: Use $(CC) instead of $(HOSTCC)
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Michal Orzel 
Cc: Anthony PERARD , xen-devel@lists.xenproject.org
References: <20250604072128.16628-1-michal.orzel@amd.com>
 
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 04.06.2025 11:05, Roger Pau Monné wrote:
> On Wed, Jun 04, 2025 at 10:07:46AM +0200, Jan Beulich wrote:
>> On 04.06.2025 09:21, Michal Orzel wrote:
>>> When cross-compiling, HOSTCC can be different than CC.
>>
>> I'm sorry for being pedantic, but the two can also be different for other
>> reasons (and I'd like to avoid this becoming a bad precedent, then getting
>> copied elsewhere). Both may target the same architecture. Hence I'd like
>> to suggest ...
> 
> Would you be fine with:
> 
> "Depending on the build environment, HOSTCC can be different than CC.
> With ..."
> 
> And the s/cannot/will not/ adjustment below?

Yeah, that would be good enough for now.

Jan

> If so, I don't have any further objections:
> 
> Reviewed-by: Roger Pau Monné 
> 
> Thanks, Roger.



From xen-devel-bounces@lists.xenproject.org Wed Jun 04 09:27:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 09:27:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005301.1384791 (Exim 4.92)
	(envelope-from )
	id 1uMkPT-0003z2-UY; Wed, 04 Jun 2025 09:27:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005301.1384791; Wed, 04 Jun 2025 09:27: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 1uMkPT-0003yv-Rr; Wed, 04 Jun 2025 09:27:47 +0000
Received: by outflank-mailman (input) for mailman id 1005301;
 Wed, 04 Jun 2025 09:27: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 1uMkPS-0003yp-0T
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 09:27:46 +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 2bdeddce-4126-11f0-a300-13f23c93f187;
 Wed, 04 Jun 2025 11:27:45 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3a36efcadb8so5545853f8f.0
 for ; Wed, 04 Jun 2025 02:27:45 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a4efe6c79dsm20670261f8f.25.2025.06.04.02.27.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 04 Jun 2025 02:27:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2bdeddce-4126-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749029264; x=1749634064; 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=q192x4MOg/z3zZ4sKfz0zZhIzh5Xs90+eUmw0paUWRk=;
        b=KMs42SGsherJSS5klg9V5C47vGCY9lGk5O+sCUpzr4B7o0dA3AzuVCljg6QYveOX0p
         CNNPftpz9WLoB8+vncNHoVSrRwQV/LMOhklaXAPcW4wom8NPZJs2/p9dceKHlVPm6fSn
         1/vZZO/02qbMXU+YmKSFl4QCgiY8ez2NxOS8g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749029264; x=1749634064;
        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=q192x4MOg/z3zZ4sKfz0zZhIzh5Xs90+eUmw0paUWRk=;
        b=CZ3pSUi5VTonjJsFU7BELTpfFyS4GYC7Yd0973BCq6ikBxtjDKBF3goaoijpibzA1E
         4apf0PwhPaEnSKjQJGfgPugnkDQSXzHobU5nafF+NePlyKiV8IJ2RgdlQhIEjRd2kgdJ
         ldsHdlAzusB/Q2Ntxvd033WJ1jubF045nDeUtyKy6225XKsikur/afeLy+Pdy6kw1rY+
         u/Ac3VaVcHNmKnpYbRxOf685Ewv3J61GO1xl0SUdXfY7Iyr5zIOaiTYLRHZa1uUeVibt
         O/ozWaXte6BpwpXtElxR0neR04XBppTM+9C4qgUZQsRUzbLshoOqjEtR0wD2as3szz6N
         CZ/w==
X-Gm-Message-State: AOJu0YwdT1zMwdJE4vaH5x43AsHcoYJsBGkUyyu+1UWl2a6GrfjoG2b3
	gzeDmqVUCWJMYBQf4yd+X5yMkbKEjd6Rh5aDHl4B80gvUjJmwIhJVZwLNT5UCUYIkRJR1pI21y0
	NNuLu
X-Gm-Gg: ASbGncsxj1JgVfvCy/SGehvCYRYxvzcu6LeZGqQPMWKdVC/k5vLC4DUSrvac/yV8z3U
	EYJrymOTj0ovBQrhkeTGbJKgRLSbADP1stUREsn8tL1QJdbHBdbGcYXbOZAXOt6WMGnVkteNEgI
	5gDDS2n16ht7pQzKAIwCtVqo0syTh1luDO3YZu8llVfZ9iu+EDCabL5J0g9wqa5eUy9+mgKeKQy
	I+MF1EoUkngBbJzxJZZapzywFXKCaP4u7fFt64LKyciVwVKjWzo106y3CSAwyEcLKUCIo/WeVPZ
	yrAzkXwfZ0KatLrEeUFyB3ucXkvgavF2sZ3lbon8HAE1HJpTJgI5jnamBOX5IjMWQpJjyl8kTeI
	yTQo4Gfv+UocB9H7iWHU=
X-Google-Smtp-Source: AGHT+IE+9MWe8ld9GybbG4gdAvfjXnv96Pu7aarncQaTas/hyQUYjrcCzrfdfi/1hVZvrLPe2deO5Q==
X-Received: by 2002:a05:6000:25c2:b0:3a3:65b5:51d7 with SMTP id ffacd0b85a97d-3a51d9311bfmr1690350f8f.26.1749029264423;
        Wed, 04 Jun 2025 02:27:44 -0700 (PDT)
Date: Wed, 4 Jun 2025 11:27:43 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" ,
	Andrew Cooper 
Subject: Re: [PATCH] x86/PV: make mmio_ro_emulated_write() static
Message-ID: 
References: <5dadf381-0f97-4362-93ed-aa5b01d73d88@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <5dadf381-0f97-4362-93ed-aa5b01d73d88@suse.com>

On Wed, Jun 04, 2025 at 11:22:00AM +0200, Jan Beulich wrote:
> It being non-static and it not having a declaration (anymore) violates
> one or more Misra rules, iirc.
> 
> Fixes: ff3e5dfa7c2d ("x86/mm: move mmio_ro_emulated_write() to PV only file")
> Signed-off-by: Jan Beulich 

Acked-by: Roger Pau Monné 

We are not checking for those rules in Eclair I think?  Otherwise this
won't have passed the CI testing.  Or maybe we are just checking
builds with !CONFIG_PV?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 09:48:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 09:48:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005307.1384801 (Exim 4.92)
	(envelope-from )
	id 1uMkj8-0006jf-Eu; Wed, 04 Jun 2025 09:48:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005307.1384801; Wed, 04 Jun 2025 09: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 1uMkj8-0006jY-CN; Wed, 04 Jun 2025 09:48:06 +0000
Received: by outflank-mailman (input) for mailman id 1005307;
 Wed, 04 Jun 2025 09: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 1uMkj6-0006jQ-VD
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 09:48:04 +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 0192efde-4129-11f0-a300-13f23c93f187;
 Wed, 04 Jun 2025 11:48:02 +0200 (CEST)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-607013a3dc8so358692a12.1
 for ; Wed, 04 Jun 2025 02:48:02 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-60566c74cd4sm8757998a12.44.2025.06.04.02.48.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 04 Jun 2025 02:48:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0192efde-4129-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749030482; x=1749635282; 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=odruecDOvo+t9KpaVjj9qI+wVwOtPBef4MrD5a+o5Aw=;
        b=gCMbmqbiepOcNpeQDn/t6Vj99NCIG1+dZoB2fN8mQvFcAhourUznbGa+SazCkTrs2K
         sPzXTH5Jb7Ifz8PVtgngJ5zXs6NMbDqvAc9nHrv/Gcc3BToOQCJYtrRfg0FEV5rYk82y
         +wS+C9As1NjjhUJLgx0aawQQBbYW0/brBZlTMmvKBhLpxpN5MMBohuFeGr3GpY1kAzil
         /FgeDTG/p5BriORgoDruRbo4aI8om3QQZRcGp+00J41mv6JwziQ9FBxjGkZy5Y2ZyROm
         aN2fW9hIkjmJhNy08E93tCE3wqrwx51oYSzQZXrrRvhvYtz77FwD8ONPBz3ps2D3t7qU
         vloQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749030482; x=1749635282;
        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=odruecDOvo+t9KpaVjj9qI+wVwOtPBef4MrD5a+o5Aw=;
        b=b4vZsxS4cNWDU/af+2YL+WPTIt/62BLg9SUv2RK4uxCkhIloERzuAUi6ga0wXMJEvv
         tvYYbfBmUxKQRc4C1KjRV4wnJWsYokDSmUbM0JrmbwRb02ZF3yw4RygjTRMkT2ZW1vMU
         VCTiqyjXZngq0FvLIk+Cf9Erl6bZtD0YU+59DClIek78TYIfooMU+JWoVbfQYY/JJMRR
         gYJQ/PCNsHvAaEKN3WYTl6zmdhsPiX5D69AE9skl0ie5BZavVXMQ4AcRIN2lF8x1Oc28
         +i5xe2X21eCRaM/SAR9a1iScTZ0mOHUhhzhTbrmCBxHd2AFhvhmbqRw2OpmrXOhhsa9o
         W2mw==
X-Gm-Message-State: AOJu0YxexWW0c98ERGFKUsRjFlIo0eD3sheaXmeQPccelJwcN1oMXaG9
	Ag2i++Rae1gajbn0maIHlMEzfr7V57bYt6riuIqcUaKJO/4VhLCU0A1YtobIAMh30rynNphiwmf
	E/Qw=
X-Gm-Gg: ASbGncu8d2COqlcI/lvDoayzwtpYyHLRE4YDZ3aqK2RC0aZ/9x1/xurQnRdqzz3Wo8k
	0r1lXptxQR84prQs4F3GRiCQB2D9+vyD5bTmkmnSK+pTNXbvFULFQgxXzA8EDAB9Sctr5blXEgQ
	EPSbgUYygBJtqsDMpoUF8PBQxRgvmJ4O6n8OhSlq/7SGNyHRTWzCSrlQ/SX/g9ZugLHlzTzj3Dj
	2NtFyzoo/7D77Emj3qg01Q2nhMw4Rnh2S392dHC+bQtGluHPgtz5HQ1Qm77EI3c7JkXvurG5jpl
	llOFd1YxeJA00a7o07VbZAnAwaFo3JwkTzHs8ZZbvp3doOd3j4M+fJS/cHg9Qb1n888KNaq8wDU
	ZIGKFG8L/1eU7PYT9ss+shp6Ag3a2ceowH2fW
X-Google-Smtp-Source: AGHT+IEjDMzhYz9lHMci6k4SS1rSCc/HwUT10egeql4xTuFK+EMbl7YgYm43CVVP9xGWoNqYfH3vCw==
X-Received: by 2002:a05:6402:2789:b0:600:2af6:d91b with SMTP id 4fb4d7f45d1cf-606e9415f3cmr2074917a12.1.1749030481934;
        Wed, 04 Jun 2025 02:48:01 -0700 (PDT)
Message-ID: <78b3ddeb-4317-4d54-ad52-9eb03bdf7942@suse.com>
Date: Wed, 4 Jun 2025 11:48:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Jan Beulich 
Subject: [PATCH v2] x86/HVM: restrict use of pinned cache attributes as well
 as associated flushing
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper , Wei Liu ,
 =?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

We don't permit use of uncachable memory types elsewhere unless a domain
meets certain criteria. Enforce this also during registration of pinned
cache attribute ranges.

Furthermore restrict cache flushing to just uncachable range registration.
While there, also (mainly be calling memory_type_changed())
- take CPU self-snoop as well as IOMMU snoop into account (albeit the
  latter still is a global property rather than a per-domain one),
- avoid flushes when the domain isn't running yet (which ought to be the
  common case).

Reported-by: Andrew Cooper 
Signed-off-by: Jan Beulich 
---
At the expense of yet larger a diff it would be possible to get away
without any "goto", by moving the whole "new entry" handling into the
switch(). Personally I'd prefer that, but the larger diff may be
unwelcome.

I have to admit that I can't spot what part of epte_get_entry_emt() the
comment refers to that is being deleted. The function does use
hvm_get_mem_pinned_cacheattr(), yes, but there's nothing there that talks
about cache flushes (and their avoiding) in any way.

Is it really sensible to add/remove ranges once the guest is already
running? (If it is, limiting the scope of the flush would be nice, but
would require knowing dirtyness for the domain wrt the caches, which
currently we don't track.)

This is kind of amending XSA-428.
---
v2: Use memory_type_changed() and conditionalize call to
    p2m_memory_type_changed().

--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -582,6 +582,7 @@ int hvm_set_mem_pinned_cacheattr(struct
 {
     struct hvm_mem_pinned_cacheattr_range *range, *newr;
     unsigned int nr = 0;
+    bool flush = false;
     int rc = 1;
 
     if ( !is_hvm_domain(d) )
@@ -605,31 +606,35 @@ int hvm_set_mem_pinned_cacheattr(struct
 
                 type = range->type;
                 call_rcu(&range->rcu, free_pinned_cacheattr_entry);
-                p2m_memory_type_changed(d);
                 switch ( type )
                 {
-                case X86_MT_UCM:
+                case X86_MT_WB:
+                case X86_MT_WP:
+                case X86_MT_WT:
                     /*
-                     * For EPT we can also avoid the flush in this case;
-                     * see epte_get_entry_emt().
+                     * Flush since we don't know what the cachability is going
+                     * to be.
                      */
-                    if ( hap_enabled(d) && cpu_has_vmx )
-                case X86_MT_UC:
-                        break;
-                    /* fall through */
-                default:
-                    flush_all(FLUSH_CACHE);
+                    if ( is_iommu_enabled(d) || cache_flush_permitted(d) )
+                        flush = true;
                     break;
                 }
-                return 0;
+                rc = 0;
+                goto finish;
             }
         domain_unlock(d);
         return -ENOENT;
 
     case X86_MT_UCM:
     case X86_MT_UC:
-    case X86_MT_WB:
     case X86_MT_WC:
+        /* Flush since we don't know what the cachability was. */
+        if ( !is_iommu_enabled(d) && !cache_flush_permitted(d) )
+            return -EPERM;
+        flush = true;
+        break;
+
+    case X86_MT_WB:
     case X86_MT_WP:
     case X86_MT_WT:
         break;
@@ -682,9 +687,11 @@ int hvm_set_mem_pinned_cacheattr(struct
 
     xfree(newr);
 
-    p2m_memory_type_changed(d);
-    if ( type != X86_MT_WB )
-        flush_all(FLUSH_CACHE);
+ finish:
+    if ( flush )
+        memory_type_changed(d);
+    else if ( d->vcpu && d->vcpu[0] )
+        p2m_memory_type_changed(d);
 
     return rc;
 }


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 09:58:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 09:58:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005315.1384810 (Exim 4.92)
	(envelope-from )
	id 1uMkt6-0008OB-CB; Wed, 04 Jun 2025 09:58:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005315.1384810; Wed, 04 Jun 2025 09:58: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 1uMkt6-0008O4-9Z; Wed, 04 Jun 2025 09:58:24 +0000
Received: by outflank-mailman (input) for mailman id 1005315;
 Wed, 04 Jun 2025 09:58: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 1uMkt5-0008Ny-2X
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 09:58:23 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 722e3f82-412a-11f0-a300-13f23c93f187;
 Wed, 04 Jun 2025 11:58:21 +0200 (CEST)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 (Authenticated sender: nicola)
 by support.bugseng.com (Postfix) with ESMTPA id 3C1C24EE7C3E;
 Wed,  4 Jun 2025 11:58:20 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 722e3f82-412a-11f0-a300-13f23c93f187
Authentication-Results: bugseng.com; arc=none smtp.remote-ip=162.55.131.47
ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1749031100;
	b=0h5m+whCgad6zUSdf+EGt3dF1C3l0YfGYLA2b2q6s9kAJtcPmp6Myfk56rHO3yeP4pVa
	 n4XG+1hv5Uuk4cNCZJwocvplIARjZuQV8rR9zual4koYT1OkFRTYeAYpSIwXz34FThnel
	 FBpKxf5qiZ23+t4a7Jy5bARKpRbLr+yXIzs9dYYdPzUMEJIYmq1FvkwosQUbJ/I1180ZT
	 JensKnroUXmP3AW6Tp3FbD7vz6mYDgiPCQvcwK6Zrs/AA8mZ8oQCC2yUCU3h/YSfffw5+
	 PTEnFYRc640OwSjYTBCotv2KsGT8A33FMvayW9Pu+0NQDBuKY0WiomK5vpj9SXL8OXDLx
	 8vFLIe+hGUzRCKpxdkjlPauIJFgsfyyLCPYnPeGi8ZN8DaVHyROygduVAdmJn0Mt3kGFJ
	 ebZPhEWBuJMCuQsO6VAMf16L1xjuyU0vm+Zcc+Z2Fs3ehQ3U10RjR039JJkvVUl/tYIn1
	 aKrSfCMBIGq1cABrN4ihiALgoxMgQ3NXPzBLe4vnKHGsx63eAUYh5P4yMhAXJKcnNAEfS
	 YWVhc8Z0XWeHdphavFLoSfjwkmdEDyHwj8DCiGtekd5vCYbvp483paNUEqCe7cLrz7/66
	 MD2FpOn6qkyt8TgvoxMCuBudDzSFI8m3SHpCdpi0SmWSJPtRu+7nt5RvGNpgOSM=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1749031100;
	h=DKIM-Signature:MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:
	 References:Message-ID:X-Sender:Organization:Content-Type:
	 Content-Transfer-Encoding;
	bh=vG5hMSRJvNT1puUMge3SKwnwpuribeb27xPAyDjR0Zk=;
	b=hMPOr+6lneJou6xhLDOD/9iBlBs2shFO6wUjSg9fB8v51VGb9TeP2YPsnFsxPagAP1xm
	 wyI5efABjdLfORwrtNq3wRCya4wHa3FLYrA0RVqVai/5gN7BCs72iWLaRYWb8kBLApOrQ
	 vX4K0wX8/5zmRuIXCwtdlSlVhz/HioKcW/wBXc2ai7LAMi7B5V+DpeE1EeKh9mzLdqQh1
	 5qkG2qj5jAEWNGfFLTfCIWFAIyuJm34CN0jXcmXVk5h3mbtGoM9HqcHxncsoH6gj+dJXX
	 nglVG57asbZ3JcCO2Tgb5yjQNf6COmnYiQ3wK93JADAcdaCoPyNhWy2s1v1Jdb1Ie6bMR
	 SBYdpecebIwjV5MIHsc9uFSmcokh8iXCwcoiGR0JUk9P+mtqsD6Eb4C0Vqnu9eE27Ag87
	 tKUmiXJLcHsTXTlQtih9U8NKBOc59ZawwAOJuO8kkgodjmZCM9/unJY18kRr13z3euXRl
	 AMXZ4UtqkNEH6U1PjkDJuzYY4ocvOwghBt6SIV82dOZIiICMs4GwOjHpJAT3fFAbBDUGY
	 wVCtDazFlyPzrHc0Mpqqnn72AkZl3DQZwiV6N4FEP4fluDTM+A3vjE2gu+FBjCAPmiws6
	 LCCbfcH2yB6rEwHaNrq8rKBiUg9WdGBV2UBWm91DFiNj4JrH2EgdV3nONzn/5kk=
ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1749031100; bh=lC7U2eX4blnbA7jZiKjj2/myvrfqSXkLqBhAk6Vethw=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=pT3VXb6ifH2JkQsZdXtnKaCzL6XF+tTkx0hAb6fVP1j4xeqGetWULLQmXYmbnTJpd
	 8zvsB5kbbMcSp8u6krOgihiCXhPE7ios5xnM8cLBJf9ao1kAU4N1NnFP0qgLXvf/sy
	 m1DZxbSt8HAI/kQFdiR9ojqvLAz5RZBpV/Ylf1pJkX96xuKIF9iZ1snBYOpTVz/Xpt
	 nLwChtPfkEiOjAU3imW4mVfCbZomulJ8b0/uNjfvdx5PfxA3udTVB2aSTDfXN3uWjU
	 RK236IqzHmRqrvDgh76682IBPQXoGIGt3+3x1Y6aLGu4Bx0+8fYuwTUzstJ0YgyNKw
	 qSjma78NRlW2w==
MIME-Version: 1.0
Date: Wed, 04 Jun 2025 11:58:20 +0200
From: Nicola Vetrini 
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Jan Beulich , xen-devel@lists.xenproject.org, Andrew
 Cooper 
Subject: Re: [PATCH] x86/PV: make mmio_ro_emulated_write() static
In-Reply-To: 
References: <5dadf381-0f97-4362-93ed-aa5b01d73d88@suse.com>
 
Message-ID: 
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 2025-06-04 11:27, Roger Pau Monné wrote:
> On Wed, Jun 04, 2025 at 11:22:00AM +0200, Jan Beulich wrote:
>> It being non-static and it not having a declaration (anymore) violates
>> one or more Misra rules, iirc.
>> 
>> Fixes: ff3e5dfa7c2d ("x86/mm: move mmio_ro_emulated_write() to PV only 
>> file")
>> Signed-off-by: Jan Beulich 
> 
> Acked-by: Roger Pau Monné 
> 
> We are not checking for those rules in Eclair I think?  Otherwise this
> won't have passed the CI testing.  Or maybe we are just checking
> builds with !CONFIG_PV?
> 
> Thanks, Roger.

That seems to be the case on x86. On Arm64 there is no override for 
CONFIG_PV [1], but perhaps that is unset by default? I'm not opposed to 
having more variants under analysis, but that is not something I can 
decide on individually.

Thanks,
  Nicola

[1] 
https://gitlab.com/xen-project/hardware/xen/-/blob/staging/automation/gitlab-ci/analyze.yaml?ref_type=heads

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 10:33:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 10:33:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005360.1384841 (Exim 4.92)
	(envelope-from )
	id 1uMlQt-0005S1-6m; Wed, 04 Jun 2025 10:33:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005360.1384841; Wed, 04 Jun 2025 10: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 1uMlQt-0005Ru-40; Wed, 04 Jun 2025 10:33:19 +0000
Received: by outflank-mailman (input) for mailman id 1005360;
 Wed, 04 Jun 2025 10:33: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 1uMlQr-0005Rl-FY
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 10:33:17 +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 5322c15a-412f-11f0-a300-13f23c93f187;
 Wed, 04 Jun 2025 12:33:16 +0200 (CEST)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-acb39c45b4eso1061912766b.1
 for ; Wed, 04 Jun 2025 03:33:16 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ada6ad39420sm1079928166b.136.2025.06.04.03.33.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 04 Jun 2025 03:33:15 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5322c15a-412f-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749033196; x=1749637996; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=97SXe+q169l9mnHBS3nIc28wgOZ/0HzJFNuHFvC0sLk=;
        b=DnCFNIvcOkekx7Fq7P75KoSrOJ3QvuYwEOjgrEcEW96aSUW1xeOchkaNmXkAK64AaA
         ZJbEU8IyyBtMS6WzsukMXUVTnbhfpuvGCgXZ/I8tyfINZmJG3ZQV1iyAIdobInD5OPxx
         BjKEF+TVZA0PZ/I1KvZZ8TtCNNLk+50bG1jB0Lb04njfViRFvMdnK7Pz8INSscgQ2eYh
         jUgAbd6x8UBj8BhX5aSoQMqwjxY7/fvy1ZgiAs5yROTFnZ37Rn1SMopsSUxP6zc8WtyH
         DZHtrzkXljPCW4U+5NWOVpPm+/knaeZ/aV+hOPOixx+o96cgIvsEy+s6F7QaH8ZvCjSS
         Ju5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749033196; x=1749637996;
        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=97SXe+q169l9mnHBS3nIc28wgOZ/0HzJFNuHFvC0sLk=;
        b=AIVGnaCnqVX5rWCVHyJMDsvzCzl8Gf9VQtbOCDZpnM7xL6IsGZX2t8xMY4YtiW6EpA
         xUlkQPJP4zCZ1jsNC9jNScq221aUuNXisx0iky99bQeiybc9OTrhOgbWrcaYyqrVn4c3
         zJ2UbUCwB1uWA9rln78ZeuKlASsC4spoD4dgSAgHtNqQAOKxhFENLrDOLGfqI7uoKS1k
         K/jXQrW45NKUJ2SrteW27mJFvXyW08oqX03UeUhjkW/Nf57q1K25TUtztog4mxRcbkJ+
         H+L8gTWn3stPVd73Ju2cRtnSs5uWDT1mooktoouql1g9tvUS3z5+HTwVIsjGdevnQqxs
         OyJw==
X-Forwarded-Encrypted: i=1; AJvYcCVqUaDzGnoz8VsNnXlsQ+xl/Ymag1cH8dUd6K9auo8TBoEYyulAjNCTED1pWY1ikk5RAd7wbdARzxA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzaHRIFqHijBEa+NSknEPwxS9w6Lp/+IPWhQWnGp6MAUXStKZpi
	lrQgmRZLj07X1hd1MLvF5TmGsQzBMAWq1qg66YGjaMh3C/BsmbNffq4kfYtOg7gPvg==
X-Gm-Gg: ASbGnctwIu620VIqYRKxFB5qIWkVdsjbeqQ7o1C1VBggKxCMvJgXzMSs5phZ3/I9PkQ
	kPBsu5Dw7B9qzwQ2ouhwMeqQJTiv/FglBSIAWSBF3MeL2LSFNbxqzmqNEx0UyHrqYe2e80KvqD8
	WysJ4Qi1IDUgBLMYMOxYWRlwkzHgVzuwatzcHs3mnUoGAHey35S81xAg611yZWhSekW3kW7ZTcJ
	uKmrVtkpeG/RpUGhDoSrDlMh2MComgqUujv3xB/nN4sD0zeialWuBkSRplub9Jth+jPQJldDoff
	J4eyC6ixJheSS3eFhhT09+8Bu3f+QTXM8SLoG0w/tZ0VboH9vds02EpBjy7tyaNM5YjPWIbB5/0
	iNYYY6jycIXXtmJwDDJ0wW3aq/5gyRdlPtbNyB4MNDfl08AE=
X-Google-Smtp-Source: AGHT+IFjcxel4oqWYrNtvT20WhfO6k7FvpyLRmCoztVdVWZTnBBprC5ONlSystpY0dwbdqJP3rnA1A==
X-Received: by 2002:a17:907:86a7:b0:add:ede0:b9d4 with SMTP id a640c23a62f3a-addf89e8fe6mr195165266b.0.1749033195781;
        Wed, 04 Jun 2025 03:33:15 -0700 (PDT)
Message-ID: <49f31b2a-d171-4ab1-8002-67453804fa60@suse.com>
Date: Wed, 4 Jun 2025 12:33:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/2] xen: Introduce system suspend config option
To: Mykola Kvach 
Cc: Mykola Kvach ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini ,
 Mykyta Poturai , 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 28.05.2025 10:05, Mykola Kvach wrote:
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -33,6 +33,8 @@ config X86
>  	select HAS_VMAP
>  	select HAS_VPCI if HVM
>  	select NEEDS_LIBELF
> +	select HAS_SYSTEM_SUSPEND
> +	select SYSTEM_SUSPEND_ALWAYS_ON

To avoid other architectures potentially also needing to select both, how about
moving the former one ...

> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -579,4 +579,21 @@ config BUDDY_ALLOCATOR_SIZE
>  	  Amount of memory reserved for the buddy allocator to serve Xen heap,
>  	  working alongside the colored one.
>  
> +config HAS_SYSTEM_SUSPEND
> +	bool
> +
> +config SYSTEM_SUSPEND_ALWAYS_ON
> +	bool

... here?

> +config SYSTEM_SUSPEND
> +	bool "System suspend support"
> +	depends on HAS_SYSTEM_SUSPEND
> +	default y if SYSTEM_SUSPEND_ALWAYS_ON

Hmm, this way "always on" isn't achieved. Someone can still turn it off, likely
causing the build to fail (until it is properly made an optional feature). You
also need to make the prompt invisible (by attaching "if SYSTEM_SUSPEND_ALWAYS_ON").

Also the default line could be shorter as "default SYSTEM_SUSPEND_ALWAYS_ON";
aiui with modern kconfig there's no difference anymore between the two.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 10:34:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 10:34:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005366.1384851 (Exim 4.92)
	(envelope-from )
	id 1uMlRb-0005sx-Ev; Wed, 04 Jun 2025 10:34:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005366.1384851; Wed, 04 Jun 2025 10:34: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 1uMlRb-0005sq-Bj; Wed, 04 Jun 2025 10:34:03 +0000
Received: by outflank-mailman (input) for mailman id 1005366;
 Wed, 04 Jun 2025 10:34: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 1uMlRZ-0005p5-AP
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 10:34:01 +0000
Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com
 [2a00:1450:4864:20::342])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6b9e9ce9-412f-11f0-b894-0df219b8e170;
 Wed, 04 Jun 2025 12:33:57 +0200 (CEST)
Received: by mail-wm1-x342.google.com with SMTP id
 5b1f17b1804b1-450cfb6a794so42194435e9.1
 for ; Wed, 04 Jun 2025 03:33:57 -0700 (PDT)
Received: from ?IPV6:2003:e5:872a:8800:5c7b:1ac1:4fa0:423b?
 (p200300e5872a88005c7b1ac14fa0423b.dip0.t-ipconnect.de.
 [2003:e5:872a:8800:5c7b:1ac1:4fa0:423b])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-450d8000d5dsm196141005e9.26.2025.06.04.03.33.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 04 Jun 2025 03:33:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6b9e9ce9-412f-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749033237; x=1749638037; 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=LKOy79S/KiSiz1vBJTOioaJxS3yGLOA+8frmhyQLdhU=;
        b=S74YLaWep/2Z2GRpTTzHwsNbvWpBiOyAkNvuBg24Iq3TCdmHaqrPBlCQ9R1kajmqaN
         uofhPJa8AFOeiAU8z8Jvb2Sd4U76BHIl1dZbRp3CBkC6AlSBYE8JTlTTI51rCG4XRWHz
         OxLaXkdq9aFgci9RWYcmWTrjM+KKzDYKtts0pi4ur0Zoy4HLLQvd3VFpFHY+WpIczbss
         LZQ089mhPoCiq+juMCRTinXSSPA/ZyJmMghjXynNKpcO01CxwXPqjRVFXxtTLlcaBUVd
         BEchWQIWybZeAfzXtqeamOAKVghFD+m+uVp16E5onnys8Mvbg9uK8mGLCtiYwoaljtUT
         nAYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749033237; x=1749638037;
        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=LKOy79S/KiSiz1vBJTOioaJxS3yGLOA+8frmhyQLdhU=;
        b=AovSU/1ty9M1Slm3J3Zqis+KU5hGPL+8bqIG/ZClW7voE9UN2mnAgGwppSqvDMo5IT
         xMWg9rFKpmFO87J/r1k1JJwWSIdxfMhSLfcPeM1kH/exnV8m0SMq30IXrIxZTOtKMCob
         oRZEQDsuHtnfoXGkDxuH2skugj9Scbb0ZtO+78P8/P33MHo/m+HR7ZST+Bw692CN/MTY
         LS9M9V0XZUis/CEU4vxpvroQ/LTa3biXJWe4Vfg0hC0aRNF+1MXC7BKumz0gPJNfs+Lv
         vNZxuigoh8hr/auyegzqh8Fgz7crsecj+ggDwjZRqhdKur5e1/hAXhSWF3vYvqgPZkd9
         9jZg==
X-Forwarded-Encrypted: i=1; AJvYcCVTGdhnAkV+oylcNmyZNxQhcYisaoEl9zLISOzgMune6lRfKffwa9OtrVp7pMloyyyx22rtXKroWqs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwvGDmrQazdysFQrz8jBjJ0Ds8tKC2ih+P/n1BGgYgR8ui4r4+q
	onC3pyWJOcvt1JaiK6Ll8L/PCZGZdscDs7jtF1Oilyy254c2aRVfh9M39Ird2+VlsOs=
X-Gm-Gg: ASbGnct2BGSaN4wuTUUUhYoPcO4LNUaHSutn6u8lEqZzrt+S3+cpdbDjHtL0b5DYJP3
	cMTXKoNZGMz2ukkZgjiQ02uLabM7rr38PrgWUMKDgJQE5LSQ614oyOiAYzqf6FFmhmLZRA+cDUq
	wJUAn/N5rILKP6/BD71hAvqRSl0z2d8r9IKaFWz0TCi3lHf/b4IDAdIYymu33ROiXSmy6bjudqS
	Z19TWmoCKthua7TrfC9dv37st6SHhP3un/U2X/1SNlpt8jpi8/0vQtDFu8EWg4w+7hPgSC44fAq
	cIty4Z/xVnrr4Y0jhZ+Blj3UlMtvFzu4Uc/dijMcjNlXOYoOY4C6isMzfE/gZECEfPrFHnVSr3Q
	hsxrmG7yB+cb74gKkl/XIrqMCnFUREIe/Lj7WQIiayoF/WxwZyflwbdqUDp2ARqRKRryIsOUjjU
	Z6ZCyU53sOafY=
X-Google-Smtp-Source: AGHT+IECX69oOdRq9Byhpk8nysFp8ycL/uH1HFCEGon5Z0PlL9vRg89OnvO6gsiCz+Y7+0olAb6aXQ==
X-Received: by 2002:a05:600c:32a7:b0:442:f4d4:53a with SMTP id 5b1f17b1804b1-451f6755c8dmr561335e9.2.1749033236666;
        Wed, 04 Jun 2025 03:33:56 -0700 (PDT)
Message-ID: <2c26fe05-ef42-48a0-9d9d-ad86100eaf01@suse.com>
Date: Wed, 4 Jun 2025 12:33:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] x86/hvmloader: select xenpci MMIO BAR UC or WB MTRR
 cache attribute
To: Roger Pau Monne , xen-devel@lists.xenproject.org
Cc: Anthony PERARD ,
 Andrew Cooper ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , Stefano Stabellini ,
 Anthoine Bourgeois 
References: <20250603111806.86555-1-roger.pau@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: <20250603111806.86555-1-roger.pau@citrix.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------rQSDNLCVVyhoKdrmo1a0z0Pi"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------rQSDNLCVVyhoKdrmo1a0z0Pi
Content-Type: multipart/mixed; boundary="------------SMBDPK2PAW6iBtfNuxFAcg4X";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Roger Pau Monne , xen-devel@lists.xenproject.org
Cc: Anthony PERARD ,
 Andrew Cooper ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , Stefano Stabellini ,
 Anthoine Bourgeois 
Message-ID: <2c26fe05-ef42-48a0-9d9d-ad86100eaf01@suse.com>
Subject: Re: [PATCH v2] x86/hvmloader: select xenpci MMIO BAR UC or WB MTRR
 cache attribute
References: <20250603111806.86555-1-roger.pau@citrix.com>
In-Reply-To: <20250603111806.86555-1-roger.pau@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=

--------------SMBDPK2PAW6iBtfNuxFAcg4X
Content-Type: multipart/mixed; boundary="------------0cdjGz3Jk78FPlxxZqbddiIb"

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

T24gMDMuMDYuMjUgMTM6MTgsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToNCj4gVGhlIFhlbiBQ
Q0kgZGV2aWNlICh2ZW5kb3IgSUQgMHg1ODUzKSBleHBvc2VkIHRvIHg4NiBIVk0gZ3Vlc3Rz
IGRvZXNuJ3QNCj4gaGF2ZSB0aGUgZnVuY3Rpb25hbGl0eSBvZiBhIHRyYWRpdGlvbmFsIFBD
SSBkZXZpY2UuICBUaGUgZXhwb3NlZCBNSU8gQkFSIGlzDQoNCnMvTUlPL01NSU8vID8NCg0K
PiB1c2VkIGJ5IHNvbWUgZ3Vlc3RzIChpbmNsdWRpbmcgTGludXgpIGFzIGEgc2FmZSBwbGFj
ZSB0byBtYXAgZm9yZWlnbg0KPiBtZW1vcnksIGluY2x1ZGluZyB0aGUgZ3JhbnQgdGFibGUg
aXRzZWxmLg0KPiANCj4gVHJhZGl0aW9uYWxseSBCQVJzIGZyb20gZGV2aWNlcyBoYXZlIHRo
ZSB1bmNhY2hlYWJsZSAoVUMpIGNhY2hlIGF0dHJpYnV0ZQ0KPiBmcm9tIHRoZSBNVFJSLCB0
byBlbnN1cmUgY29ycmVjdCBmdW5jdGlvbmFsaXR5IG9mIHN1Y2ggZGV2aWNlcy4gIGh2bWxv
YWRlcg0KPiBtaW1pY3MgdGhpcyBiZWhhdmlvciBhbmQgc2V0cyB0aGUgTVRSUiBhdHRyaWJ1
dGVzIG9mIGJvdGggdGhlIGxvdyBhbmQgaGlnaA0KPiBQQ0kgTU1JTyB3aW5kb3dzICh3aGVy
ZSBCQVJzIG9mIFBDSSBkZXZpY2VzIHJlc2lkZSkgYXMgVUMgaW4gTVRSUi4NCj4gDQo+IFRo
aXMgaG93ZXZlciBjYXVzZXMgcGVyZm9ybWFuY2UgaXNzdWVzIGZvciB1c2VycyBvZiB0aGUg
WGVuIFBDSSBkZXZpY2UgQkFSLA0KPiBhcyBmb3IgdGhlIHB1cnBvc2VzIG9mIG1hcHBpbmcg
cmVtb3RlIG1lbW9yeSB0aGVyZSdzIG5vIG5lZWQgdG8gdXNlIHRoZSBVQw0KPiBhdHRyaWJ1
dGUuICBPbiBJbnRlbCBzeXN0ZW1zIHRoaXMgaXMgd29ya2VkIGFyb3VuZCBieSB1c2luZyBp
UEFULCB0aGF0DQo+IGFsbG93cyB0aGUgaHlwZXJ2aXNvciB0byBmb3JjZSB0aGUgZWZmZWN0
aXZlIGNhY2hlIGF0dHJpYnV0ZSBvZiBhIHAybSBlbnRyeQ0KPiByZWdhcmRsZXNzIG9mIHRo
ZSBndWVzdCBQQVQgdmFsdWUuICBBTUQgaG93ZXZlciBkb2Vzbid0IGhhdmUgYW4gZXF1aXZh
bGVudA0KPiBvZiBpUEFULCBhbmQgZ3Vlc3QgUEFUIHZhbHVlcyBhcmUgYWx3YXlzIGNvbnNp
ZGVyZWQuDQo+IA0KPiBMaW51eCBjb21taXQ6DQo+IA0KPiA0MTkyNWIxMDVlMzQgeGVuOiBy
ZXBsYWNlIHhlbl9yZW1hcCgpIHdpdGggbWVtcmVtYXAoKQ0KPiANCj4gQXR0ZW1wdGVkIHRv
IG1pdGlnYXRlIHRoaXMgYnkgZm9yY2luZyBtYXBwaW5ncyBvZiB0aGUgZ3JhbnQtdGFibGUg
dG8gdXNlDQo+IHRoZSB3cml0ZS1iYWNrIChXQikgY2FjaGUgYXR0cmlidXRlLiAgSG93ZXZl
ciBMaW51eCBtZW1yZW1hcCgpIHRha2VzIE1UUlJzDQo+IGludG8gYWNjb3VudCB0byBjYWxj
dWxhdGUgd2hpY2ggUEFUIHR5cGUgdG8gdXNlLCBhbmQgc2VlaW5nIHRoZSBNVFJSIGNhY2hl
DQo+IGF0dHJpYnV0ZSBmb3IgdGhlIHJlZ2lvbiBiZWluZyBVQyB0aGUgUEFUIGFsc28gZW5k
cyB1cCBhcyBVQywgcmVnYXJkbGVzcyBvZg0KPiB0aGUgY2FsbGVyIGhhdmluZyByZXF1ZXN0
ZWQgV0IuDQo+IA0KPiBBcyBhIHdvcmthcm91bmQgdG8gYWxsb3cgY3VycmVudCBMaW51eCB0
byBtYXAgdGhlIGdyYW50LXRhYmxlIGFzIFdCIHVzaW5nDQo+IG1lbXJlbWFwKCkgaW50cm9k
dWNlIGFuIHhsLmNmZyBvcHRpb24gKHhlbnBjaV9iYXJfdWM9MCkgdGhhdCBjYW4gYmUgdXNl
ZCB0bw0KPiBzZWxlY3Qgd2hldGhlciB0aGUgWGVuIFBDSSBkZXZpY2UgQkFSIHdpbGwgaGF2
ZSB0aGUgVUMgYXR0cmlidXRlIGluIE1UUlIuDQo+IFN1Y2ggd29ya2Fyb3VuZCBpbiBodm1s
b2FkZXIgc2hvdWxkIGFsc28gYmUgcGFpcmVkIHdpdGggYSBmaXggZm9yIExpbnV4IHNvDQo+
IGl0IGF0dGVtcHRzIHRvIGNoYW5nZSB0aGUgTVRSUiBvZiB0aGUgWGVuIFBDSSBkZXZpY2Ug
QkFSIHRvIFdCIGJ5IGl0c2VsZi4NCj4gDQo+IE92ZXJhbGwsIHRoZSBsb25nIHRlcm0gc29s
dXRpb24gd291bGQgYmUgdG8gcHJvdmlkZSB0aGUgZ3Vlc3Qgd2l0aCBhIHNhZmUNCj4gcmFu
Z2UgaW4gdGhlIGd1ZXN0IHBoeXNpY2FsIGFkZHJlc3Mgc3BhY2Ugd2hlcmUgbWFwcGluZ3Mg
dG8gZm9yZWlnbiBwYWdlcw0KPiBjYW4gYmUgY3JlYXRlZC4NCj4gDQo+IFNvbWUgdmlmIHRo
cm91Z2hwdXQgcGVyZm9ybWFuY2UgZmlndXJlcyBwcm92aWRlZCBieSBBbnRob2luZSBmcm9t
IGEgOA0KPiB2Q1BVcywgNEdCIG9mIFJBTSBIVk0gZ3Vlc3QocykgcnVubmluZyBvbiBBTUQg
aGFyZHdhcmU6DQo+IA0KPiBXaXRob3V0IHRoaXMgcGF0Y2g6DQo+IHZtIC0+IGRvbTA6IDEu
MUdiL3MNCj4gdm0gLT4gdm06ICAgNS4wR2Ivcw0KPiANCj4gV2l0aCB0aGUgcGF0Y2g6DQo+
IHZtIC0+IGRvbTA6IDQuNUdiL3MNCj4gdm0gLT4gdm06ICAgNy4wR2Ivcw0KPiANCj4gUmVw
b3J0ZWQtYnk6IEFudGhvaW5lIEJvdXJnZW9pcyA8YW50aG9pbmUuYm91cmdlb2lzQHZhdGVz
LnRlY2g+DQo+IFNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBj
aXRyaXguY29tPg0KPiAtLS0NCj4gQ2hhbmdlcyBzaW5jZSB2MToNCj4gICAtIExlYXZlIHRo
ZSB4ZW5wY2kgQkFSIGFzIFVDIGJ5IGRlZmF1bHQuDQo+ICAgLSBJbnRyb2R1Y2UgYW4gb3B0
aW9uIHRvIG5vdCBzZXQgaXQgYXMgVUMuDQo+IC0tLQ0KPiAgIGRvY3MvbWFuL3hsLmNmZy41
LnBvZC5pbiAgICAgICAgICAgICAgICB8ICA2ICsrKw0KPiAgIHRvb2xzL2Zpcm13YXJlL2h2
bWxvYWRlci9jb25maWcuaCAgICAgICB8ICAyICstDQo+ICAgdG9vbHMvZmlybXdhcmUvaHZt
bG9hZGVyL3BjaS5jICAgICAgICAgIHwgNDkgKysrKysrKysrKysrKysrKysrKysrKysrLQ0K
PiAgIHRvb2xzL2Zpcm13YXJlL2h2bWxvYWRlci91dGlsLmMgICAgICAgICB8ICAyICstDQo+
ICAgdG9vbHMvaW5jbHVkZS9saWJ4bC5oICAgICAgICAgICAgICAgICAgIHwgIDkgKysrKysN
Cj4gICB0b29scy9saWJzL2xpZ2h0L2xpYnhsX2NyZWF0ZS5jICAgICAgICAgfCAgMSArDQo+
ICAgdG9vbHMvbGlicy9saWdodC9saWJ4bF9kb20uYyAgICAgICAgICAgIHwgIDkgKysrKysN
Cj4gICB0b29scy9saWJzL2xpZ2h0L2xpYnhsX3R5cGVzLmlkbCAgICAgICAgfCAgMSArDQo+
ICAgdG9vbHMveGwveGxfcGFyc2UuYyAgICAgICAgICAgICAgICAgICAgIHwgIDIgKw0KPiAg
IHhlbi9pbmNsdWRlL3B1YmxpYy9odm0vaHZtX3hzX3N0cmluZ3MuaCB8ICAyICsNCj4gICAx
MCBmaWxlcyBjaGFuZ2VkLCA3OSBpbnNlcnRpb25zKCspLCA0IGRlbGV0aW9ucygtKQ0KPiAN
Cj4gZGlmZiAtLWdpdCBhL2RvY3MvbWFuL3hsLmNmZy41LnBvZC5pbiBiL2RvY3MvbWFuL3hs
LmNmZy41LnBvZC5pbg0KPiBpbmRleCBjMzg4ODk5MzA2YzIuLmU1NDBkODE2OTQyNCAxMDA2
NDQNCj4gLS0tIGEvZG9jcy9tYW4veGwuY2ZnLjUucG9kLmluDQo+ICsrKyBiL2RvY3MvbWFu
L3hsLmNmZy41LnBvZC5pbg0KPiBAQCAtMjM1MSw2ICsyMzUxLDEyIEBAIFdpbmRvd3MgTDxo
dHRwczovL3hlbnByb2plY3Qub3JnL3dpbmRvd3MtcHYtZHJpdmVycy8+Lg0KPiAgIFNldHRp
bmcgQjx4ZW5fcGxhdGZvcm1fcGNpPTA+IHdpdGggdGhlIGRlZmF1bHQgZGV2aWNlX21vZGVs
ICJxZW11LXhlbiINCj4gICByZXF1aXJlcyBhdCBsZWFzdCBRRU1VIDEuNi4NCj4gICANCj4g
Kw0KPiArPWl0ZW0gQjx4ZW5wY2lfYmFyX3VjPUJPT0xFQU4+DQo+ICsNCj4gK0I8eDg2IG9u
bHk6PiBTZWxlY3Qgd2hldGhlciB0aGUgbWVtb3J5IEJBUiBvZiB0aGUgWGVuIFBDSSBkZXZp
Y2Ugc2hvdWxkIGhhdmUNCj4gK3VuY2FjaGVhYmxlIChVQykgY2FjaGUgYXR0cmlidXRlIHNl
dCBpbiBNVFJSLg0KPiArDQoNClNob3VsZG4ndCB5b3Ugc3RhdGUgd2hhdCB0aGUgZGVmYXVs
dCBpcz8NCg0KPiAgID1pdGVtIEI8dmlyaWRpYW49WyAiR1JPVVAiLCAiR1JPVVAiLCAuLi5d
PiBvciBCPHZpcmlkaWFuPUJPT0xFQU4+DQo+ICAgDQo+ICAgVGhlIGdyb3VwcyBvZiBNaWNy
b3NvZnQgSHlwZXItViAoQUtBIHZpcmlkaWFuKSBjb21wYXRpYmxlIGVubGlnaHRlbm1lbnRz
DQo+IGRpZmYgLS1naXQgYS90b29scy9maXJtd2FyZS9odm1sb2FkZXIvY29uZmlnLmggYi90
b29scy9maXJtd2FyZS9odm1sb2FkZXIvY29uZmlnLmgNCj4gaW5kZXggNmUxZGExMzdkNzc5
Li5jMTU5ZGIzMGVlYTkgMTAwNjQ0DQo+IC0tLSBhL3Rvb2xzL2Zpcm13YXJlL2h2bWxvYWRl
ci9jb25maWcuaA0KPiArKysgYi90b29scy9maXJtd2FyZS9odm1sb2FkZXIvY29uZmlnLmgN
Cj4gQEAgLTU4LDcgKzU4LDcgQEAgZXh0ZXJuIHVpbnQzMl90ICpjcHVfdG9fYXBpY2lkOw0K
PiAgICNkZWZpbmUgQUNQSV9USVNfSERSX0FERFJFU1MgMHhGRUQ0MEYwMFVMDQo+ICAgDQo+
ICAgZXh0ZXJuIHVpbnQzMl90IHBjaV9tZW1fc3RhcnQ7DQo+IC1leHRlcm4gY29uc3QgdWlu
dDMyX3QgcGNpX21lbV9lbmQ7DQo+ICtleHRlcm4gdWludDMyX3QgcGNpX21lbV9lbmQ7DQo+
ICAgZXh0ZXJuIHVpbnQ2NF90IHBjaV9oaV9tZW1fc3RhcnQsIHBjaV9oaV9tZW1fZW5kOw0K
PiAgIA0KPiAgIGV4dGVybiBib29sIGFjcGlfZW5hYmxlZDsNCj4gZGlmZiAtLWdpdCBhL3Rv
b2xzL2Zpcm13YXJlL2h2bWxvYWRlci9wY2kuYyBiL3Rvb2xzL2Zpcm13YXJlL2h2bWxvYWRl
ci9wY2kuYw0KPiBpbmRleCBjYzY3YjE4YzAzNjEuLjk3OTMzYjQ0YTgyYiAxMDA2NDQNCj4g
LS0tIGEvdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVyL3BjaS5jDQo+ICsrKyBiL3Rvb2xzL2Zp
cm13YXJlL2h2bWxvYWRlci9wY2kuYw0KPiBAQCAtMzAsNyArMzAsNyBAQA0KPiAgICNpbmNs
dWRlIDx4ZW4vaHZtL2U4MjAuaD4NCj4gICANCj4gICB1aW50MzJfdCBwY2lfbWVtX3N0YXJ0
ID0gSFZNX0JFTE9XXzRHX01NSU9fU1RBUlQ7DQo+IC1jb25zdCB1aW50MzJfdCBwY2lfbWVt
X2VuZCA9IFJFU0VSVkVEX01FTUJBU0U7DQo+ICt1aW50MzJfdCBwY2lfbWVtX2VuZCA9IFJF
U0VSVkVEX01FTUJBU0U7DQo+ICAgdWludDY0X3QgcGNpX2hpX21lbV9zdGFydCA9IDAsIHBj
aV9oaV9tZW1fZW5kID0gMDsNCj4gICANCj4gICAvKg0KPiBAQCAtMTE2LDYgKzExNiw4IEBA
IHZvaWQgcGNpX3NldHVwKHZvaWQpDQo+ICAgICAgICAqIGV4cGVyaWVuY2UgdGhlIG1lbW9y
eSByZWxvY2F0aW9uIGJ1ZyBkZXNjcmliZWQgYmVsb3cuDQo+ICAgICAgICAqLw0KPiAgICAg
ICBib29sIGFsbG93X21lbW9yeV9yZWxvY2F0ZSA9IDE7DQo+ICsgICAgLyogU2V0IHRoZSBN
VFJSIHR5cGUgb2YgdGhlIHhlbnBjaSBkZXZpY2UgQkFSIGFzIFVDLiAqLw0KPiArICAgIGJv
b2wgeGVucGNpX2Jhcl91YyA9IGZhbHNlOw0KDQpIbW0sIHNob3VsZG4ndCB0aGlzIGJlICJ0
cnVlIj8gT3Igc2hvdWxkIHRoZSBjb21tZW50IGJlIGNoYW5nZWQ/DQoNCj4gICANCj4gICAg
ICAgQlVJTERfQlVHX09OKCh0eXBlb2YoKnBjaV9kZXZmbl9kZWNvZGVfdHlwZSkpUENJX0NP
TU1BTkRfSU8gIT0NCj4gICAgICAgICAgICAgICAgICAgIFBDSV9DT01NQU5EX0lPKTsNCj4g
QEAgLTEzMCw2ICsxMzIsMTIgQEAgdm9pZCBwY2lfc2V0dXAodm9pZCkNCj4gICAgICAgcHJp
bnRmKCJSZWxvY2F0aW5nIGd1ZXN0IG1lbW9yeSBmb3IgbG93bWVtIE1NSU8gc3BhY2UgJXNc
biIsDQo+ICAgICAgICAgICAgICBhbGxvd19tZW1vcnlfcmVsb2NhdGU/ImVuYWJsZWQiOiJk
aXNhYmxlZCIpOw0KPiAgIA0KPiArICAgIHMgPSB4ZW5zdG9yZV9yZWFkKEhWTV9YU19YRU5Q
Q0lfQkFSX1VDLCBOVUxMKTsNCj4gKyAgICBpZiAoIHMgKQ0KPiArICAgICAgICB4ZW5wY2lf
YmFyX3VjID0gc3RydG9sbChzLCBOVUxMLCAwKTsNCj4gKyAgICBwcmludGYoIlhlblBDSSBk
ZXZpY2UgQkFSIE1UUlIgY2FjaGUgYXR0cmlidXRlIHNldCB0byAlc1xuIiwNCj4gKyAgICAg
ICAgICAgeGVucGNpX2Jhcl91YyA/ICJVQyIgOiAiV0IiKTsNCj4gKw0KPiAgICAgICBzID0g
eGVuc3RvcmVfcmVhZCgicGxhdGZvcm0vbW1pb19ob2xlX3NpemUiLCBOVUxMKTsNCj4gICAg
ICAgaWYgKCBzICkNCj4gICAgICAgICAgIG1taW9faG9sZV9zaXplID0gc3RydG9sbChzLCBO
VUxMLCAwKTsNCj4gQEAgLTI3MSw2ICsyNzksNDMgQEAgdm9pZCBwY2lfc2V0dXAodm9pZCkN
Cj4gICAgICAgICAgICAgICBpZiAoIGJhcl9zeiA9PSAwICkNCj4gICAgICAgICAgICAgICAg
ICAgY29udGludWU7DQo+ICAgDQo+ICsgICAgICAgICAgICBpZiAoICF4ZW5wY2lfYmFyX3Vj
ICYmDQo+ICsgICAgICAgICAgICAgICAgICgoYmFyX2RhdGEgJiBQQ0lfQkFTRV9BRERSRVNT
X1NQQUNFKSA9PQ0KPiArICAgICAgICAgICAgICAgICAgIFBDSV9CQVNFX0FERFJFU1NfU1BB
Q0VfTUVNT1JZKSAmJg0KPiArICAgICAgICAgICAgICAgICB2ZW5kb3JfaWQgPT0gMHg1ODUz
ICYmDQo+ICsgICAgICAgICAgICAgICAgIChkZXZpY2VfaWQgPT0gMHgwMDAxIHx8IGRldmlj
ZV9pZCA9PSAweDAwMDIpICkNCj4gKyAgICAgICAgICAgIHsNCj4gKyAgICAgICAgICAgICAg
ICBpZiAoIGlzXzY0YmFyICkNCj4gKyAgICAgICAgICAgICAgICB7DQo+ICsgICAgICAgICAg
ICAgICAgICAgICBwcmludGYoInhlbnBjaSBkZXYgJTAyeDoleCB1bmV4cGVjdGVkIE1NSU8g
NjRiaXQgQkFSJXVcbiIsDQo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgZGV2Zm4g
Pj4gMywgZGV2Zm4gJiA3LCBiYXIpOw0KPiArICAgICAgICAgICAgICAgICAgICAgY29udGlu
dWU7DQo+ICsgICAgICAgICAgICAgICAgfQ0KPiArDQo+ICsgICAgICAgICAgICAgICAgaWYg
KCBiYXJfc3ogPiBwY2lfbWVtX2VuZCB8fA0KPiArICAgICAgICAgICAgICAgICAgICAgKChw
Y2lfbWVtX2VuZCAtIGJhcl9zeikgJiB+KGJhcl9zeiAtIDEpKSA8IHBjaV9tZW1fc3RhcnQg
KQ0KPiArICAgICAgICAgICAgICAgIHsNCj4gKyAgICAgICAgICAgICAgICAgICAgIHByaW50
ZigieGVucGNpIGRldiAlMDJ4OiV4IEJBUiV1IHNpemUgJWxseCBvdmVyZmxvd3MgbG93IFBD
SSBob2xlXG4iLA0KPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRldmZuID4+IDMs
IGRldmZuICYgNywgYmFyLCBiYXJfc3opOw0KPiArICAgICAgICAgICAgICAgICAgICAgY29u
dGludWU7DQo+ICsgICAgICAgICAgICAgICAgfQ0KPiArDQo+ICsgICAgICAgICAgICAgICAg
LyogUHV0IHVuY29uZGl0aW9uYWxseSBhdCB0aGUgZW5kIG9mIHRoZSBsb3cgUENJIE1NSU8g
aG9sZS4gKi8NCj4gKyAgICAgICAgICAgICAgICBwY2lfbWVtX2VuZCAtPSBiYXJfc3o7DQo+
ICsgICAgICAgICAgICAgICAgcGNpX21lbV9lbmQgJj0gfihiYXJfc3ogLSAxKTsNCj4gKyAg
ICAgICAgICAgICAgICBiYXJfZGF0YSAmPSB+UENJX0JBU0VfQUREUkVTU19NRU1fTUFTSzsN
Cj4gKyAgICAgICAgICAgICAgICBiYXJfZGF0YSB8PSBwY2lfbWVtX2VuZDsNCj4gKyAgICAg
ICAgICAgICAgICBwY2lfd3JpdGVsKGRldmZuLCBiYXJfcmVnLCBiYXJfZGF0YSk7DQo+ICsg
ICAgICAgICAgICAgICAgcGNpX2RldmZuX2RlY29kZV90eXBlW2RldmZuXSB8PSBQQ0lfQ09N
TUFORF9NRU1PUlk7DQo+ICsNCj4gKyAgICAgICAgICAgICAgICAvKiBQcmVmaXggQkFSIGFk
ZHJlc3Mgd2l0aCBhIDAgdG8gbWF0Y2ggZm9ybWF0IHVzZWQgYmVsb3cuICovDQo+ICsgICAg
ICAgICAgICAgICAgcHJpbnRmKCJwY2kgZGV2ICUwMng6JXggYmFyICUwMnggc2l6ZSAiUFJJ
bGx4IjogMCUwOHhcbiIsDQo+ICsgICAgICAgICAgICAgICAgICAgICAgIGRldmZuID4+IDMs
IGRldmZuICYgNywgYmFyX3JlZywNCj4gKyAgICAgICAgICAgICAgICAgICAgICAgUFJJbGx4
X2FyZyhiYXJfc3opLCBiYXJfZGF0YSk7DQo+ICsNCj4gKyAgICAgICAgICAgICAgICBjb250
aW51ZTsNCj4gKyAgICAgICAgICAgIH0NCj4gKw0KPiAgICAgICAgICAgICAgIGZvciAoIGkg
PSAwOyBpIDwgbnJfYmFyczsgaSsrICkNCj4gICAgICAgICAgICAgICAgICAgaWYgKCBiYXJz
W2ldLmJhcl9zeiA8IGJhcl9zeiApDQo+ICAgICAgICAgICAgICAgICAgICAgICBicmVhazsN
Cj4gQEAgLTMxMCw3ICszNTUsNyBAQCB2b2lkIHBjaV9zZXR1cCh2b2lkKQ0KPiAgICAgICAg
ICAgfQ0KPiAgIA0KPiAgICAgICAgICAgLyogRW5hYmxlIGJ1cyBtYXN0ZXIgZm9yIHRoaXMg
ZnVuY3Rpb24gbGF0ZXIgKi8NCj4gLSAgICAgICAgcGNpX2RldmZuX2RlY29kZV90eXBlW2Rl
dmZuXSA9IFBDSV9DT01NQU5EX01BU1RFUjsNCj4gKyAgICAgICAgcGNpX2RldmZuX2RlY29k
ZV90eXBlW2RldmZuXSB8PSBQQ0lfQ09NTUFORF9NQVNURVI7DQo+ICAgICAgIH0NCj4gICAN
Cj4gICAgICAgaWYgKCBtbWlvX2hvbGVfc2l6ZSApDQo+IGRpZmYgLS1naXQgYS90b29scy9m
aXJtd2FyZS9odm1sb2FkZXIvdXRpbC5jIGIvdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVyL3V0
aWwuYw0KPiBpbmRleCA3OWMwZTZiZDRhZDIuLjMxYjQ0MTFkYjdiNCAxMDA2NDQNCj4gLS0t
IGEvdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVyL3V0aWwuYw0KPiArKysgYi90b29scy9maXJt
d2FyZS9odm1sb2FkZXIvdXRpbC5jDQo+IEBAIC04NjcsNyArODY3LDcgQEAgdm9pZCBodm1s
b2FkZXJfYWNwaV9idWlsZF90YWJsZXMoc3RydWN0IGFjcGlfY29uZmlnICpjb25maWcsDQo+
ICAgICAgICAgICBjb25maWctPnRhYmxlX2ZsYWdzIHw9IEFDUElfSEFTX0hQRVQ7DQo+ICAg
DQo+ICAgICAgIGNvbmZpZy0+cGNpX3N0YXJ0ID0gcGNpX21lbV9zdGFydDsNCj4gLSAgICBj
b25maWctPnBjaV9sZW4gPSBwY2lfbWVtX2VuZCAtIHBjaV9tZW1fc3RhcnQ7DQo+ICsgICAg
Y29uZmlnLT5wY2lfbGVuID0gUkVTRVJWRURfTUVNQkFTRSAtIHBjaV9tZW1fc3RhcnQ7DQo+
ICAgICAgIGlmICggcGNpX2hpX21lbV9lbmQgPiBwY2lfaGlfbWVtX3N0YXJ0ICkNCj4gICAg
ICAgew0KPiAgICAgICAgICAgY29uZmlnLT5wY2lfaGlfc3RhcnQgPSBwY2lfaGlfbWVtX3N0
YXJ0Ow0KPiBkaWZmIC0tZ2l0IGEvdG9vbHMvaW5jbHVkZS9saWJ4bC5oIGIvdG9vbHMvaW5j
bHVkZS9saWJ4bC5oDQo+IGluZGV4IGI3YWQ3NzM1Y2E0Yy4uN2NlNzY3OGU2ODM2IDEwMDY0
NA0KPiAtLS0gYS90b29scy9pbmNsdWRlL2xpYnhsLmgNCj4gKysrIGIvdG9vbHMvaW5jbHVk
ZS9saWJ4bC5oDQo+IEBAIC0xNTAzLDYgKzE1MDMsMTUgQEAgdm9pZCBsaWJ4bF9tYWNfY29w
eShsaWJ4bF9jdHggKmN0eCwgbGlieGxfbWFjICpkc3QsIGNvbnN0IGxpYnhsX21hYyAqc3Jj
KTsNCj4gICAgKi8NCj4gICAjZGVmaW5lIExJQlhMX0hBVkVfQ1JFQVRFSU5GT19YRU5EX1NV
U1BFTkRfRVZUQ0hOX0NPTVBBVA0KPiAgIA0KPiArLyoNCj4gKyAqIExJQlhMX0hBVkVfWEVO
UENJX0JBUl9VQw0KPiArICoNCj4gKyAqIGxpYnhsX2RvbWFpbl9idWlsZF9pbmZvIGNvbnRh
aW5zIGEgYm9vbGVhbiAndS5odm0ueGVucGNpX2Jhcl91YycgZmllbGQgdG8NCj4gKyAqIHNp
Z25hbCB3aGV0aGVyIHRoZSBYZW5QQ0kgZGV2aWNlIEJBUiBzaG91bGQgaGF2ZSBVQyBjYWNo
ZSBhdHRyaWJ1dGUgc2V0IGluDQo+ICsgKiBNVFJSLg0KPiArICovDQo+ICsjZGVmaW5lIExJ
QlhMX0hBVkVfWEVOUENJX0JBUl9VQw0KPiArDQo+ICAgdHlwZWRlZiBjaGFyICoqbGlieGxf
c3RyaW5nX2xpc3Q7DQo+ICAgdm9pZCBsaWJ4bF9zdHJpbmdfbGlzdF9kaXNwb3NlKGxpYnhs
X3N0cmluZ19saXN0ICpzbCk7DQo+ICAgaW50IGxpYnhsX3N0cmluZ19saXN0X2xlbmd0aChj
b25zdCBsaWJ4bF9zdHJpbmdfbGlzdCAqc2wpOw0KPiBkaWZmIC0tZ2l0IGEvdG9vbHMvbGli
cy9saWdodC9saWJ4bF9jcmVhdGUuYyBiL3Rvb2xzL2xpYnMvbGlnaHQvbGlieGxfY3JlYXRl
LmMNCj4gaW5kZXggOGJjNzY4YjUxNTZjLi45NjJmYTgyMGZhZWMgMTAwNjQ0DQo+IC0tLSBh
L3Rvb2xzL2xpYnMvbGlnaHQvbGlieGxfY3JlYXRlLmMNCj4gKysrIGIvdG9vbHMvbGlicy9s
aWdodC9saWJ4bF9jcmVhdGUuYw0KPiBAQCAtMzEzLDYgKzMxMyw3IEBAIGludCBsaWJ4bF9f
ZG9tYWluX2J1aWxkX2luZm9fc2V0ZGVmYXVsdChsaWJ4bF9fZ2MgKmdjLA0KPiAgICAgICAg
ICAgbGlieGxfZGVmYm9vbF9zZXRkZWZhdWx0KCZiX2luZm8tPnUuaHZtLnVzYiwgICAgICAg
ICAgICAgICAgZmFsc2UpOw0KPiAgICAgICAgICAgbGlieGxfZGVmYm9vbF9zZXRkZWZhdWx0
KCZiX2luZm8tPnUuaHZtLnZrYl9kZXZpY2UsICAgICAgICAgdHJ1ZSk7DQo+ICAgICAgICAg
ICBsaWJ4bF9kZWZib29sX3NldGRlZmF1bHQoJmJfaW5mby0+dS5odm0ueGVuX3BsYXRmb3Jt
X3BjaSwgICB0cnVlKTsNCj4gKyAgICAgICAgbGlieGxfZGVmYm9vbF9zZXRkZWZhdWx0KCZi
X2luZm8tPnUuaHZtLnhlbnBjaV9iYXJfdWMsICAgICAgdHJ1ZSk7DQo+ICAgICAgICAgICBs
aWJ4bF9kZWZib29sX3NldGRlZmF1bHQoJmJfaW5mby0+dS5odm0ucGlycSwgICAgICAgICAg
ICAgICBmYWxzZSk7DQo+ICAgDQo+ICAgICAgICAgICBsaWJ4bF9kZWZib29sX3NldGRlZmF1
bHQoJmJfaW5mby0+dS5odm0uc3BpY2UuZW5hYmxlLCBmYWxzZSk7DQo+IGRpZmYgLS1naXQg
YS90b29scy9saWJzL2xpZ2h0L2xpYnhsX2RvbS5jIGIvdG9vbHMvbGlicy9saWdodC9saWJ4
bF9kb20uYw0KPiBpbmRleCA0ZDY3YjBkMjgyOTQuLjYwZWMwMzU0ZDE5YSAxMDA2NDQNCj4g
LS0tIGEvdG9vbHMvbGlicy9saWdodC9saWJ4bF9kb20uYw0KPiArKysgYi90b29scy9saWJz
L2xpZ2h0L2xpYnhsX2RvbS5jDQo+IEBAIC04MTksNiArODE5LDE1IEBAIHN0YXRpYyBpbnQg
aHZtX2J1aWxkX3NldF94c192YWx1ZXMobGlieGxfX2djICpnYywNCj4gICAgICAgICAgICAg
ICBnb3RvIGVycjsNCj4gICAgICAgfQ0KPiAgIA0KPiArICAgIGlmIChpbmZvLT50eXBlID09
IExJQlhMX0RPTUFJTl9UWVBFX0hWTSAmJg0KPiArICAgICAgICBsaWJ4bF9kZWZib29sX3Zh
bChpbmZvLT51Lmh2bS54ZW5wY2lfYmFyX3VjKSkgew0KPiArICAgICAgICBwYXRoID0gR0NT
UFJJTlRGKCIvbG9jYWwvZG9tYWluLyVkLyJIVk1fWFNfWEVOUENJX0JBUl9VQywgZG9taWQp
Ow0KPiArICAgICAgICByZXQgPSBsaWJ4bF9feHNfcHJpbnRmKGdjLCBYQlRfTlVMTCwgcGF0
aCwgIiVkIiwNCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsaWJ4bF9kZWZi
b29sX3ZhbChpbmZvLT51Lmh2bS54ZW5wY2lfYmFyX3VjKSk7DQo+ICsgICAgICAgIGlmIChy
ZXQpDQo+ICsgICAgICAgICAgICBnb3RvIGVycjsNCj4gKyAgICB9DQo+ICsNCj4gICAgICAg
cmV0dXJuIDA7DQo+ICAgDQo+ICAgZXJyOg0KPiBkaWZmIC0tZ2l0IGEvdG9vbHMvbGlicy9s
aWdodC9saWJ4bF90eXBlcy5pZGwgYi90b29scy9saWJzL2xpZ2h0L2xpYnhsX3R5cGVzLmlk
bA0KPiBpbmRleCAxOTg1MTUzODMwMTIuLjYwNTQzNTBiODNjNyAxMDA2NDQNCj4gLS0tIGEv
dG9vbHMvbGlicy9saWdodC9saWJ4bF90eXBlcy5pZGwNCj4gKysrIGIvdG9vbHMvbGlicy9s
aWdodC9saWJ4bF90eXBlcy5pZGwNCj4gQEAgLTY5MSw2ICs2OTEsNyBAQCBsaWJ4bF9kb21h
aW5fYnVpbGRfaW5mbyA9IFN0cnVjdCgiZG9tYWluX2J1aWxkX2luZm8iLFsNCj4gICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoInZrYl9kZXZpY2UiLCAgICAg
ICBsaWJ4bF9kZWZib29sKSwNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAoInNvdW5kaHciLCAgICAgICAgICBzdHJpbmcpLA0KPiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICgieGVuX3BsYXRmb3JtX3BjaSIsIGxpYnhs
X2RlZmJvb2wpLA0KPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
KCJ4ZW5wY2lfYmFyX3VjIiwgICAgbGlieGxfZGVmYm9vbCksDQo+ICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgKCJ1c2JkZXZpY2VfbGlzdCIsICAgbGlieGxf
c3RyaW5nX2xpc3QpLA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICgidmVuZG9yX2RldmljZSIsICAgIGxpYnhsX3ZlbmRvcl9kZXZpY2UpLA0KPiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICMgU2VlIGxpYnhsX21zX3Zt
X2dlbmlkX2dlbmVyYXRlKCkNCj4gZGlmZiAtLWdpdCBhL3Rvb2xzL3hsL3hsX3BhcnNlLmMg
Yi90b29scy94bC94bF9wYXJzZS5jDQo+IGluZGV4IDIxOWU5MjQ3NzlmZi4uNGRhM2JiOWU5
MWFiIDEwMDY0NA0KPiAtLS0gYS90b29scy94bC94bF9wYXJzZS5jDQo+ICsrKyBiL3Rvb2xz
L3hsL3hsX3BhcnNlLmMNCj4gQEAgLTI5MTcsNiArMjkxNyw4IEBAIHNraXBfdXNiZGV2Og0K
PiAgICAgICAgICAgeGx1X2NmZ19yZXBsYWNlX3N0cmluZyAoY29uZmlnLCAic291bmRodyIs
ICZiX2luZm8tPnUuaHZtLnNvdW5kaHcsIDApOw0KPiAgICAgICAgICAgeGx1X2NmZ19nZXRf
ZGVmYm9vbChjb25maWcsICJ4ZW5fcGxhdGZvcm1fcGNpIiwNCj4gICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgJmJfaW5mby0+dS5odm0ueGVuX3BsYXRmb3JtX3BjaSwgMCk7DQo+
ICsgICAgICAgIHhsdV9jZmdfZ2V0X2RlZmJvb2woY29uZmlnLCAieGVucGNpX2Jhcl91YyIs
DQo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmJfaW5mby0+dS5odm0ueGVucGNp
X2Jhcl91YywgMCk7DQo+ICAgDQo+ICAgICAgICAgICBpZihiX2luZm8tPnUuaHZtLnZuYy5s
aXN0ZW4NCj4gICAgICAgICAgICAgICYmIGJfaW5mby0+dS5odm0udm5jLmRpc3BsYXkNCj4g
ZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3B1YmxpYy9odm0vaHZtX3hzX3N0cmluZ3MuaCBi
L3hlbi9pbmNsdWRlL3B1YmxpYy9odm0vaHZtX3hzX3N0cmluZ3MuaA0KPiBpbmRleCBlMWVk
MDc4NjI4YTAuLmViYjA3YjlmYmE1NiAxMDA2NDQNCj4gLS0tIGEveGVuL2luY2x1ZGUvcHVi
bGljL2h2bS9odm1feHNfc3RyaW5ncy5oDQo+ICsrKyBiL3hlbi9pbmNsdWRlL3B1YmxpYy9o
dm0vaHZtX3hzX3N0cmluZ3MuaA0KPiBAQCAtMTQsNiArMTQsOCBAQA0KPiAgICNkZWZpbmUg
SFZNX1hTX0JJT1MgICAgICAgICAgICAgICAgICAgICJodm1sb2FkZXIvYmlvcyINCj4gICAj
ZGVmaW5lIEhWTV9YU19HRU5FUkFUSU9OX0lEX0FERFJFU1MgICAiaHZtbG9hZGVyL2dlbmVy
YXRpb24taWQtYWRkcmVzcyINCj4gICAjZGVmaW5lIEhWTV9YU19BTExPV19NRU1PUllfUkVM
T0NBVEUgICAiaHZtbG9hZGVyL2FsbG93LW1lbW9yeS1yZWxvY2F0ZSINCj4gKy8qIFNldCB4
ZW5wY2kgZGV2aWNlIEJBUiBhcyBVQyBpbiBNVFJSICovDQo+ICsjZGVmaW5lIEhWTV9YU19Y
RU5QQ0lfQkFSX1VDICAgICAgICAgICAiaHZtbG9hZGVyL3BjaS94ZW5wY2ktYmFyLXVjIg0K
DQpDb3VsZCB5b3UgcGxlYXNlIGFkZCB0aGlzIHBhdGggdG8gZG9jcy9taXNjL3hlbnN0b3Jl
LXBhdGhzLnBhbmRvYyA/DQoNCg0KSnVlcmdlbg0K
--------------0cdjGz3Jk78FPlxxZqbddiIb
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-----

--------------0cdjGz3Jk78FPlxxZqbddiIb--

--------------SMBDPK2PAW6iBtfNuxFAcg4X--

--------------rQSDNLCVVyhoKdrmo1a0z0Pi
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/Ey8FAmhAIRMFAwAAAAAACgkQsN6d1ii/Ey8/
WQgAji2CLKpYD/ejPcdoLH6RBbdhigCS3HgfwId0dP0EE4tkvZNQuXeeMkK5VNwVEWV9bCyQBk7g
/jhbV+z315fWFIb7+GFS0JVaIv6kdMlEmAG3zCW37nEvJ4Q3oMmXU/EAJUcPcqyXtSLQb1Ui5P5q
rZcm/6Y52hfL8jJfDBIedvgXS9MMBdVwLkh5obo2pTeP9+7Zdcssu3rxvFGPS94VHpsyZOydN8U0
ozc3xdEoFgg/qBsE+n9aO/oJNZI7hUolVmFMla4Jad4yqBFXFqNLs3BZe1iin0UGFLMnT3Nqw+6b
jQjH9RMJRQ+OHg1uddFZ5jy17Qrwru6rXIivzUVhFA==
=oM7M
-----END PGP SIGNATURE-----

--------------rQSDNLCVVyhoKdrmo1a0z0Pi--


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 10:36:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 10:36:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005377.1384861 (Exim 4.92)
	(envelope-from )
	id 1uMlTq-0006Xl-0X; Wed, 04 Jun 2025 10:36:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005377.1384861; Wed, 04 Jun 2025 10: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 1uMlTp-0006Xe-Sl; Wed, 04 Jun 2025 10:36:21 +0000
Received: by outflank-mailman (input) for mailman id 1005377;
 Wed, 04 Jun 2025 10:36: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 1uMlTo-0006XW-K7
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 10:36: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 c05f19be-412f-11f0-a300-13f23c93f187;
 Wed, 04 Jun 2025 12:36:19 +0200 (CEST)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-ad1d1f57a01so394621066b.2
 for ; Wed, 04 Jun 2025 03:36:19 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ada6ad3952esm1080521966b.126.2025.06.04.03.36.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 04 Jun 2025 03:36:18 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c05f19be-412f-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749033379; x=1749638179; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=heSEnKLJCzFjiVAdepYWI524DyGDrhfym4Hsd4gNN3M=;
        b=TuDgqWZmZKaxrOwa/E21Zr0pfSeCNfLvyaYqtz2PNd+J7JzwAhoAxj6NTn/o3PLLX0
         6QqHYJ0J1a43A4Qdj0lyLHHkuN6LsSpEJx1zPAAC6cVn2L4v4rHsYbWCbCdRlHS09YrC
         tAgaY49eOQ9CIWKJ5XIptRyfDmW78Nz7xqB2RbB3pyRqgq1IIPbdQXD+mjj68SRVjC/y
         D0qEkBatfjFVSTeDs6yCbMOMJBKSXt4zP/K3KYzuTYIRZpE4L7L7XKq0AD0Ra2xhP5u4
         UOjgoVQjbkxZbEQt3dhYZaPVPHWnNvDGUSf1VaLk3DSYdinsPkH6HiJPv53mHAi9pdxw
         wqpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749033379; x=1749638179;
        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=heSEnKLJCzFjiVAdepYWI524DyGDrhfym4Hsd4gNN3M=;
        b=E2LnPL4WH5O5w1c/5lsRvA53WRNFnDFDG70C88laGPSyuY+UCHWkkkeKYo+Omk+8FG
         H6bWU6YG+iNux13Lhg6LHFaUaI8GGpz3+BVVWvSVMxwzjZjAvPlkVR7m25105vrVklh0
         q0tGG9886t+pJAySp0s1nsPxGhckUDmlCvo9YBr+/lrZfsP4iDnqOqSZSWYJU9I5OrWc
         XEGXmNsUmFj+tNVRsMRTApaYr/wl20oW3voeDKQEaUif9WbMNAI0dq94e6ww7oy0WxMS
         jh9+NKlwGjz6VLXBihLUN/z9gEiZzHpjos/1/dcSYs5BxSkIiajywCdsR9FN3d3W5Dau
         BFLg==
X-Forwarded-Encrypted: i=1; AJvYcCUQm5nNEr7C/j1QTcnGc0xX0XU4wOBodujxd+og7Tq2/BycIBRMwcyLFJ6ixn2Q4ZqOEZq4x9JCeUo=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx8EtjRBF5RZsazbDoZHjzy7X1grnShlzbwQBEXxK/ec8W/jkJR
	FbJELqiMYU9IsNS+NADgwImYb1QI8CP4OLVTIjPNs+LgoYqsXQRgswiEQd3xJiUp9Q==
X-Gm-Gg: ASbGncuPyf6B7lSB7UlMer2nLNKq/P8xj7TBMCW3A38WdJnos/cpBUz0U2sVc43YyGQ
	0TsSSUn4bBpsG4Dg+xcFlFqpOoIAJjgTmuqs3pM/eAFD1bBuyR0i3KBvLkt0zl2NnG38D8tGaGz
	sTcYoL/kVz3Z/UyIRZhg30WtDGLBpcxA1xStQ/uSZx/3iRjCw9vOmpppC0RpfZngMtxYyN5/sk4
	/lU1gQEbLDNmA7iiKd47Sr9aKBhlM6tOZjjriii+8ZJ39cVAaB7BqClKgdJVn6TYNflU0BAcgMF
	hJ2z42McTvhJDd8wVHPYkQiIg0+Jcuki1MwQIadQATPdoCMcD4HWWkU2VZ+cHxwGtKYNeJ5jPvb
	rUThybZOycsXPNr/xsX5Cv4wiqLtrkmDokdJU
X-Google-Smtp-Source: AGHT+IGItkZqx4ToV+tzXoSCdFvrqO8lXw1rhyRVCweZUWDQViKEovq/3BwNY0Rjt/siKBoubjWIFg==
X-Received: by 2002:a17:907:1c0d:b0:adb:413e:2a2f with SMTP id a640c23a62f3a-addf8c2fe70mr179729066b.9.1749033379029;
        Wed, 04 Jun 2025 03:36:19 -0700 (PDT)
Message-ID: <093dc85d-ebf3-4982-8888-db4e7cfd0e45@suse.com>
Date: Wed, 4 Jun 2025 12:36:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 1/2] xen/domain: introduce common hardware emulation
 flags
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org,
 teddy.astie@vates.tech, dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250602191717.148361-1-dmukhin@ford.com>
 <20250602191717.148361-2-dmukhin@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: <20250602191717.148361-2-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 02.06.2025 21:17, dmkhn@proton.me wrote:
> From: Denis Mukhin 
> 
> Add common emulation_flags for configuring domain emulation features.
> 
> Print d->emulation_flags from 'q' keyhandler for better traceability while
> debugging.
> 
> Signed-off-by: Denis Mukhin 
> Reviewed-by: Stefano Stabellini 

It's not becoming clear why this would want doing, nor in how far some of
the bits there may gain "common" meaning, too. Imo this kind of change is
meaningful only in a series where later the common-ness is also used.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 10:43:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 10:43:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005396.1384870 (Exim 4.92)
	(envelope-from )
	id 1uMlak-0008DH-LQ; Wed, 04 Jun 2025 10:43:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005396.1384870; Wed, 04 Jun 2025 10: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 1uMlak-0008DA-Ik; Wed, 04 Jun 2025 10:43:30 +0000
Received: by outflank-mailman (input) for mailman id 1005396;
 Wed, 04 Jun 2025 10: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 1uMlaj-0008D4-Rr
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 10:43:29 +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 bdca830d-4130-11f0-b894-0df219b8e170;
 Wed, 04 Jun 2025 12:43:24 +0200 (CEST)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-602346b1997so11477760a12.3
 for ; Wed, 04 Jun 2025 03:43:24 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-605fab0272csm4751346a12.17.2025.06.04.03.43.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 04 Jun 2025 03:43:23 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bdca830d-4130-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749033804; x=1749638604; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=sCgXzljo2K/JIVDYKaT2wzXng1unvS3CANAtMI00h2w=;
        b=df43tUAnUzhZ5i/hmzPDRhsiSm/u0lrbLXkhbbDVw69CNVwTcqyIcz96YIgwsv2v06
         +VmeJeGKdW6LYQPiq3mkPOlsqhp4yt8dmW2vYqcqb8hww9mWrpVi8e0VGSIvjjedd0jl
         ZAUUe6ug0nuPM9g1j5VYLeJXxJkz4Rp8KxS8K71rMLV6k9/HhrbfKpDZ1xkMUBkoWjSp
         cL34tst8u1xhjgbw2mF1oZDHakhoLQoraaq8PUHqnUnKWin+PW5VR38ayavOxdAbFn+v
         NASye/l2bvgfo6Ttrm6VhWQG+pNX+WDhsLhG0aaerqCn5hUGNYkoL2lvhoVb/i7fg730
         Z9lw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749033804; x=1749638604;
        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=sCgXzljo2K/JIVDYKaT2wzXng1unvS3CANAtMI00h2w=;
        b=Lg/z2X3cBLK1/kdEIZl90xSS47o2jzIBdPOC3w/OurQghJpY2H4+/DT8F2VxoNIF8h
         rpWHNVvQAR+XwdJ+3ljBYg6ExQb0Y74WeEYp74JVE/s2jCaMOKFw7lCm+1UzcMI49XEX
         oGH7J+s7zl3k6B66AxeE9wmF7VVgzz+lKK0D3i8xQTVJO5aJZ8yLyFFhMerwHfXoth0P
         1TF7p/yMX+BXLTNkaQjY3qSYHCA1OdPOAAsxH/GNltz1lm7KstLfdopCyP8hp6qLeSXj
         JqqGqT60a9dQeisCCyKRBdpTZ9M3TNIeh3DDz5lUsyJWytg+cPLJ170SpqZgxaWF6NpO
         pOjw==
X-Forwarded-Encrypted: i=1; AJvYcCVH7kc2nMVUymovkCv/FRBGgcocPkrudIJ6ZmUSwel9e5nnccYGigZA8MVTAsY3XC3RsLFGF7uPNO0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwgQjOK59EYuNatfJxp+90DO/w5C46Kar6lJrd7Y7uwKRtIgl4N
	C8okHGCDDC+ciz/MAIcyli3P/xNMyc6Hu9ExzrXUZHRLR2NzXqn4DWMrPszE6g36mA==
X-Gm-Gg: ASbGnctn6jBsU/LvGyXdm57G/XmzMX3XGOuisK4yPo9WNci56EuGGygxLlVIDkfRPQe
	G0rNDyioEzwFdG8poBJ3+soHTQSxruUCIM698BMfBI1Y+7yoMBkt1mWUntqBC3mJnqONPGS5x08
	eAlNwmfiKIA4J7SjYRSlxx0j889zcglJSXdIM4mbEhaGg5qQ+Xu/aENg9FgcSIs8/JAT6ZTCAX6
	W6JzWZf10fBIx6rljAzIX9bRNT4GsnAABc95QecJg5D30xt8Wci7lJAjR8D9qwrbYmVj8No656m
	5+gavSXjQJQQTv/u0T9L9b5TVwGXESWbSnw7SkTVVukzoip5YFxzSUzyuCFJsLb0ExG/mHyWHPx
	UHrPixEmwqjiNK2sUT8l4e/+Ns6U0gNsw+YmS
X-Google-Smtp-Source: AGHT+IFo3zceErhBG/yUTlPOz1TJtpZoZAvwh+Bi7j1y6aK/nAE3eubsf+hTI4biordwJhr/o86PGg==
X-Received: by 2002:a05:6402:27d0:b0:606:a99d:91d4 with SMTP id 4fb4d7f45d1cf-606ea16f586mr2465169a12.27.1749033804199;
        Wed, 04 Jun 2025 03:43:24 -0700 (PDT)
Message-ID: 
Date: Wed, 4 Jun 2025 12:43:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 2/2] xen/domain: rewrite emulation_flags_ok()
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org,
 teddy.astie@vates.tech, dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250602191717.148361-1-dmukhin@ford.com>
 <20250602191717.148361-3-dmukhin@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: <20250602191717.148361-3-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 02.06.2025 21:17, dmkhn@proton.me wrote:
> From: Denis Mukhin 
> 
> Rewrite emulation_flags_ok() to simplify future modifications.
> 
> No functional change intended.
> 
> Signed-off-by: Denis Mukhin 
> Reviewed-by: Stefano Stabellini 
> Reviewed-by: Teddy Astie 
> ---
> Changes since v4:
> - updated commentaries
> - added Teddy's R-b, kept Stefano's R-b
> ---
>  xen/arch/x86/domain.c | 91 ++++++++++++++++++++++++++++++++++---------
>  1 file changed, 73 insertions(+), 18 deletions(-)

Given this diffstat, I wonder what the other x86 maintainers think about
this.

> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -743,32 +743,87 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
>      return 0;
>  }
>  
> +/*
> + * Verify that the domain's emulation flags resolve to a supported configuration.
> + *
> + * This ensures we only allow a known, safe subset of emulation combinations
> + * (for both functionality and security). Arbitrary mixes are likely to cause
> + * errors (e.g., null pointer dereferences).
> + *
> + * NB: use the internal X86_EMU_XXX symbols, not the public XEN_X86_EMU_XXX
> + * symbols.
> + */
>  static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
>  {
> +    enum {
> +        CAP_PV          = BIT(0, U),
> +        CAP_HVM         = BIT(1, U),
> +        CAP_HWDOM       = BIT(2, U),
> +        CAP_DOMU        = BIT(3, U),
> +    };
> +    static const struct {
> +        unsigned int caps;
> +        uint32_t min;
> +        uint32_t opt;
> +    } configs[] = {
> +#ifdef CONFIG_PV
> +        /* PV */
> +        {
> +            .caps   = CAP_PV | CAP_DOMU,
> +            .min    = 0,
> +            .opt    = 0,

Why the latter two initializers? Imo adding ones which say nothing else than
what's the default is only enlarging code without much real benefit.

> +        },
> +
> +        /* PV dom0 */
> +        {
> +            .caps   = CAP_PV | CAP_HWDOM,
> +            .min    = X86_EMU_PIT,
> +            .opt    = 0,
> +        },
> +#endif /* #ifdef CONFIG_PV */
> +
> +#ifdef CONFIG_HVM
> +        /* PVH dom0 */
> +        {
> +            .caps   = CAP_HVM | CAP_HWDOM,
> +            .min    = X86_EMU_LAPIC | X86_EMU_IOAPIC | X86_EMU_VPCI,
> +            .opt    = 0,
> +        },
> +
> +        /* HVM domU */
> +        {
> +            .caps   = CAP_HVM | CAP_DOMU,
> +            .min    = X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ),
> +            /* HVM PIRQ feature is user-selectable. */
> +            .opt    = X86_EMU_USE_PIRQ,
> +        },
> +
> +        /* PVH domU */
> +        {
> +            .caps   = CAP_HVM | CAP_DOMU,
> +            .min    = X86_EMU_LAPIC,
> +            .opt    = 0,
> +        },
> +#endif /* #ifdef CONFIG_HVM */
> +    };
> +    unsigned int i, caps = is_hardware_domain(d) ? CAP_HWDOM : CAP_DOMU;
> +
> +    if ( is_pv_domain(d) )
> +        caps |= CAP_PV;
> +    else if ( is_hvm_domain(d) )
> +        caps |= CAP_HVM;

There's no 3rd case, so this could be expressed with plain "else", and hence
also with a conditional operator, and hence could also be right in the
initializer. How far to go with those transformations I'm not sure; personally
I'd go all the way, but I'd be okay-ish with just the first of the steps.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 10:48:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 10:48:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005403.1384882 (Exim 4.92)
	(envelope-from )
	id 1uMlfJ-0000LG-6Q; Wed, 04 Jun 2025 10:48:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005403.1384882; Wed, 04 Jun 2025 10:48: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 1uMlfJ-0000L9-2P; Wed, 04 Jun 2025 10:48:13 +0000
Received: by outflank-mailman (input) for mailman id 1005403;
 Wed, 04 Jun 2025 10:48: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 1uMlfI-0000L3-82
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 10:48:12 +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 662343f4-4131-11f0-b894-0df219b8e170;
 Wed, 04 Jun 2025 12:48:07 +0200 (CEST)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-acb5ec407b1so1044976366b.1
 for ; Wed, 04 Jun 2025 03:48:07 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ada5d82ccedsm1075589066b.48.2025.06.04.03.48.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 04 Jun 2025 03:48:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 662343f4-4131-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749034087; x=1749638887; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=fG3HJmUeDmAud3SYdcrzvH6XfWyeWXYbj4gkMX0vrTU=;
        b=ZQ9mXe7mMGbePcsNGB98A8slRVRv78o888UT7SpKBl8zh1VQrBMovPcNwsr4pm2Cx1
         fsX5cDNt+ZN5BEuCMipWeLFwIh5rmYdJp6gJ3Ow554ZnGHO+B573pzzgNwC+e/R7+pa1
         HP5kkn7wF+nosJiIw3RooNtAIykRpFdB8BWxNllO5aj+wTKm9DRvpdXPXumzowsjxUKL
         pz7lGKeaTnqMYuJxrDeUbygg3fg8vVCVJk4JHtPAuNAn5DOLeE1aPVvzUorLH9YSZ/6Y
         zT2TWCCZD/BNdfm1CZy69bdvEDWwtZbppawdrFJd46MLyvfX0Fs2wyC36y1pY0VX4bjW
         O8GQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749034087; x=1749638887;
        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=fG3HJmUeDmAud3SYdcrzvH6XfWyeWXYbj4gkMX0vrTU=;
        b=la11ZhOJa9WTmR4x0jHcJ08lQOnOOimQeH9RozfH1LGQXTQ9H6v6/1g+HSjLjtlzlE
         qgHt9AmLPBFY5nl1ApQGUZqg8FuNIqx6sHRgKksrhqQQr7EjhGZN3RhwqZ1osPqDJNF0
         C9WAMTFs/GjI4SyJN/zxlr4eZ7XdiiSNwyabh7R7EchnZPAQ5j8bLgwUnsckqFKNHOF8
         xoBVFuqoEBl1qj5/fBQZ46QIx870tXPAm1ya/u6rW75qZwxMsrNXEnuo8c8yy6QSLHfr
         pDyGPRPmKjqeH5j0DHTzyqZChr2bqghhQnKtv/xxbkGQD++L2rhvOH/gK4u42f/1Ux/U
         0ojQ==
X-Forwarded-Encrypted: i=1; AJvYcCWK624ZBI9JKawy8VodCIoJ67Ppei3x6XkZrybDM+hjTKkBz+DOX8hTu4tifyp4nuUna4fdUQBe9cU=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywf9ciNEUJ5nbOtQmvIqLKL3iS5ubfgqN8tpSPEN96oSiGUd1qJ
	R3Y1pu7HQrkGzzxIKav28yE0jhlI2EbfqfKtyuS2OIe9GpnQ6BOJ/HoKU1IQGHs/1A==
X-Gm-Gg: ASbGncv5AtTCpvYTvFMcoeH+cnSfmwk44w2VQ1nOpPGn3RH/p82JkyVE7qX9HAv6VxP
	wo/kSAyb5QYE1Mk0PsTU8C4ojNq8mHwDPNlWBEiqqVmntYbjRGAHQI1UUYXnvyGRrs7BrQwMgb+
	38XQzitcOa76va5TzXbQzPNYRTFP47zyWbbkWnMV0eUr/eXdmLNX5VDKEvu6Nt2pFfkEs4SZfN+
	FMNn0iyXBZX1CcJatQeJrhY+jSPRCiaSCshURG4ByBjMljXODlsBDmwLoJ9b/6yTP86HC1W7Liy
	u+gHfTR4YGt9veDQk/NW7kGYvdJU6HX2PyHbPoucHEXEjExy9Zy1mUAMMJJU4j4aG/EId0lum/p
	YxHmGb3vXP3cyRJ42+coPIuu9aXv91f3er0n9tZ1qTFBN+cQ=
X-Google-Smtp-Source: AGHT+IFS6T++DZRcSRhV0nuL1AbAiV1mp0qSqBJmvvJsmTAN+nLpoYRCvT0Di+ZuryvlzPphIYpwrw==
X-Received: by 2002:a17:907:7e8d:b0:ad4:cfbd:efd0 with SMTP id a640c23a62f3a-addf8f256admr197566666b.36.1749034086681;
        Wed, 04 Jun 2025 03:48:06 -0700 (PDT)
Message-ID: <71318dd2-0724-4c2a-9786-40b676411e56@suse.com>
Date: Wed, 4 Jun 2025 12:48:05 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/2] xen/console: unify printout behavior for UART
 emulators
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org,
 dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250531000417.81750-1-dmukhin@ford.com>
 <20250531000417.81750-3-dmukhin@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: <20250531000417.81750-3-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 31.05.2025 02:04, dmkhn@proton.me wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -577,7 +577,7 @@ static int cf_check hvm_print_line(
>      if ( (cd->pbuf_idx == (DOMAIN_PBUF_SIZE - 1)) || (c == '\n') )
>      {
>          cd->pbuf[cd->pbuf_idx] = '\0';
> -        guest_printk(cd, XENLOG_G_DEBUG "%s\n", cd->pbuf);
> +        guest_printk(cd, "%s\n", cd->pbuf);
>          cd->pbuf_idx = 0;
>      }

Why this and ...

> @@ -755,7 +765,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer,
>              else
>              {
>                  cd->pbuf[cd->pbuf_idx] = '\0';
> -                guest_printk(cd, XENLOG_G_DEBUG "%s%s\n", cd->pbuf, kbuf);
> +                guest_printk(cd, "%s%s\n", cd->pbuf, kbuf);
>                  cd->pbuf_idx = 0;
>              }

... this change? There's no compensation for it ...

> @@ -1013,12 +1023,21 @@ void printk(const char *fmt, ...)
>      va_end(args);
>  }
>  
> +/*
> + * Print message from the guest on the diagnostic console.
> + * Prefixes all messages w/ "(dX)" if domain X does not own physical console
> + * focus.
> + */
>  void guest_printk(const struct domain *d, const char *fmt, ...)
>  {
>      va_list args;
> -    char prefix[16];
> +    char prefix[16] = "";
> +    struct domain *consd;
>  
> -    snprintf(prefix, sizeof(prefix), "(d%d) ", d->domain_id);
> +    consd = console_get_domain();
> +    if ( consd != d )
> +        snprintf(prefix, sizeof(prefix), "(d%d) ", d->domain_id);
> +    console_put_domain(consd);
>  
>      va_start(args, fmt);
>      vprintk_common(fmt, args, prefix);

... here afaics, so it looks like you're undermining rate-limiting of
those messages.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 10:57:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 10:57:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005415.1384911 (Exim 4.92)
	(envelope-from )
	id 1uMlo6-0002Ev-6z; Wed, 04 Jun 2025 10:57:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005415.1384911; Wed, 04 Jun 2025 10:57: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 1uMlo6-0002Eo-3N; Wed, 04 Jun 2025 10:57:18 +0000
Received: by outflank-mailman (input) for mailman id 1005415;
 Wed, 04 Jun 2025 10:57: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 1uMlo4-0002Eh-6A
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 10:57: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 abe9e837-4132-11f0-b894-0df219b8e170;
 Wed, 04 Jun 2025 12:57:13 +0200 (CEST)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-451d41e1ad1so31535335e9.1
 for ; Wed, 04 Jun 2025 03:57:13 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-450d7fb80f6sm192840155e9.28.2025.06.04.03.57.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 04 Jun 2025 03:57:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: abe9e837-4132-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749034633; x=1749639433; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=kIdDRLdK9ahe0t0qTzt/qdF8nLEjAB0AXrpApyXgJyk=;
        b=FHrIJYEdDngEtg/mKKKkKQKJq28vnf26ojUFfY5/AMJAjWHn4woXiUlJE8J+wjQ0+m
         YZPAzp1OqQ5qDX3nk0gcsbjRBz89Ris2WX1k32S982sPgxYi+Jotvb79hyjQLP9LszQk
         xgO/2DF84XfTFYCIc/fU/Q6ygioCP+u1Y2KWg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749034633; x=1749639433;
        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=kIdDRLdK9ahe0t0qTzt/qdF8nLEjAB0AXrpApyXgJyk=;
        b=icU+07785FiFg/wh6CXvn+WSfewmxjVr9tnnFtxwUMNNedF66kjd5W9As7tx0KDrkv
         FWbvsGFAHgvIYGguWwWKFR1Ttdbxw4vqQiAyPH+/oe/2OxwYDoxVztJTVHjNQ8sNBUnh
         DtGgnNpsxpF5jDcKQJ07ywSMRdMek3QG9/N7vx8uXzmp1McearipvUrcaITtEjDR9tI8
         92YwOGeqDYWDYx1Qy3fOLPkoWhNxo+9yrUbpQB9PP4br8KSsnBmlx4H8TDUy7qHYpdbv
         OCzsfwtBSrWe2Ve/YPTfd/k2V+KSPZDQOpQpah90AK8e9ZHfXVO1+UQyTx/fe72HCGM4
         fWAw==
X-Gm-Message-State: AOJu0YwbfMiXa+Zqe3zBxL7GwBRTOS9Rs06wjwJu77JTxsBUP3Qa09er
	j+EHupt2b7P4R8/uel+WK9g7kDhZ7ynxFUnXYJzF+XDwnrbqg1NgxgxlK6js/LVLAM0=
X-Gm-Gg: ASbGncvWQJg/fDVZLs5J5W69SOsStRbqm8pCgNx/cV4/Fu+ezuSRPHAGI1I/3xDfq5A
	EPeMtwJWgAFsvorgb5tvVDDWTijkkwkIHkz7kWuQiTTQDlP1kPeDjVmeM66H3G9sXQqx2eC6pNy
	KewyHAbRmLA+bg8qAR2EMttMmh6TZF45q3XoYoYg+hhI+wb3Bw03kFdQ32DnXrAqo6LB3XiZKBv
	eXc7+e4oQMavvOEX4Jhcp79qufKQ6WN4yZLT/QQ1WrkIfoPvw6C3jPP6CurSYL27QgGI3WUtxpY
	fHg6TKEOis8GezLmu44Op8i5suH5CwwlelaMabvtjkswosyHsG42ecx/sX8i4FDz4Q/J4Gv9Z7e
	1o2RMri+cU4hqLLNT
X-Google-Smtp-Source: AGHT+IGI2SBhRZBFTbtMTow/6jyX/VdSaAAq/Qv8jYwoAGWQYL4x1hTt1GZbsgK25ZCGsZEX/23i7w==
X-Received: by 2002:a05:6000:1a8d:b0:3a4:cbc6:9db0 with SMTP id ffacd0b85a97d-3a51dc49afcmr1776994f8f.51.1749034633199;
        Wed, 04 Jun 2025 03:57:13 -0700 (PDT)
Message-ID: <384fd17a-9236-4727-b564-543edff65e9e@citrix.com>
Date: Wed, 4 Jun 2025 11:57:11 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 9/9] CI: Add timing to junit
To: Anthony PERARD ,
 Stefano Stabellini 
Cc: xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , Anthony PERARD
 , Doug Goldstein 
References: <20250603124222.52057-1-anthony@xenproject.org>
 <20250603124222.52057-10-anthony@xenproject.org>
 
 
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 04/06/2025 9:48 am, Anthony PERARD wrote:
> On Tue, Jun 03, 2025 at 11:35:22AM -0700, Stefano Stabellini wrote:
>> On Tue, 3 Jun 2025, Anthony PERARD wrote:
>>> From: Anthony PERARD 
>>>
>>> Signed-off-by: Anthony PERARD 
>>> ---
>>>  automation/scripts/run-tools-tests | 5 ++++-
>>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/automation/scripts/run-tools-tests b/automation/scripts/run-tools-tests
>>> index 852c1cfbcf..e38cc4068c 100755
>>> --- a/automation/scripts/run-tools-tests
>>> +++ b/automation/scripts/run-tools-tests
>>> @@ -18,9 +18,12 @@ for f in "$1"/*; do
>>>          continue
>>>      fi
>>>      echo "Running $f"
>>> -    printf '  \n' "$f" >> "$xml_out"
>>> +    time_start=$EPOCHREALTIME
>>>      "$f" 2>&1 | tee /tmp/out
>>>      ret=${PIPESTATUS[0]}
>>> +    time_end=$EPOCHREALTIME
>>> +    time_test="$(bc <<<"$time_end - $time_start")"
>> As it looks like no other scripts need bc at the moment but we already
>> rely on awk (automation/scripts/xilinx-smoke-dom0less-arm64.sh) I'd
>> prefer this version:
>>
>> time_test="$(awk "BEGIN {print $time_end - $time_start}")"
> You mean I have to choose between busybox and busybox?
>
> $ ls -l $(which bc awk)
> lrwxrwxrwx    1 root     root            12 Feb 13 23:19 /usr/bin/awk -> /bin/busybox
> lrwxrwxrwx    1 root     root            12 Feb 13 23:19 /usr/bin/bc -> /bin/busybox
>
> :-)
>
> I guess it doesn't really matter.
>
> One difference though:
> $ awk "BEGIN {print $time_end - $time_start}"
> 3.28798
> $ bc <<<"$time_end - $time_start"
> 3.287982
>
> awk is less precise, but I guess that doesn't matter as well, gitlab UI
> isn't going to show the extra digits.
>
> So I guess I can change to use `awk` instead, just in case for some
> reason `bc` isn't present, since `awk` seems mandatory for many of our
> scripts.
>
> Thanks,

bc is a normal posix utility just like awk is, so there's no change in
dependencies caused by this.

Furthermore, it is the right tool for this job in a way that awk isn't. 
Besides the reduction in precision, see xen/tools/check-endbr.sh for the
number of ways we found that awk malfunctions with large numbers.

I firmly suggest continuing to use bc here.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 11:20:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 11:20:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005428.1384921 (Exim 4.92)
	(envelope-from )
	id 1uMmAH-0006Dt-1y; Wed, 04 Jun 2025 11:20:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005428.1384921; Wed, 04 Jun 2025 11:20:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMmAG-0006Dm-VC; Wed, 04 Jun 2025 11:20:12 +0000
Received: by outflank-mailman (input) for mailman id 1005428;
 Wed, 04 Jun 2025 11:20: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 1uMmAF-0006Dg-Le
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 11:20:12 +0000
Received: from OS0P286CU011.outbound.protection.outlook.com
 (mail-japanwestazlp170100001.outbound.protection.outlook.com
 [2a01:111:f403:c406::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id dc77232b-4135-11f0-b894-0df219b8e170;
 Wed, 04 Jun 2025 13:20:05 +0200 (CEST)
Received: from OSOPR01MB12408.jpnprd01.prod.outlook.com (2603:1096:604:2d7::7)
 by TYYPR01MB6697.jpnprd01.prod.outlook.com (2603:1096:400:c8::5) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8813.21; Wed, 4 Jun
 2025 11:19:55 +0000
Received: from OSOPR01MB12408.jpnprd01.prod.outlook.com
 ([fe80::7ff4:8a98:ccd4:daa1]) by OSOPR01MB12408.jpnprd01.prod.outlook.com
 ([fe80::7ff4:8a98:ccd4:daa1%4]) with mapi id 15.20.8813.018; Wed, 4 Jun 2025
 11:19: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: dc77232b-4135-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=l8EnLnXOKzlsHWTcdWwNA5oOO7w8KZ+R3/8J1Fa3j3+h9DkKSfm6/tlTaXZh+pXtBthiRkO3ufxg29nXPQjFudYngyM5XMofidqP9GsZeURnyIYMA1dtlV4mPQcnDB82+/s1U0OiYTEiDx2YkkinExuYqhNJmrRdboTdsC0pYCBjFsdgf99nk3tj/BeOwj82YyAT0uj02rr8nVQLFa7LYjdd91TkXgv4rFCoa0zBHb8LwOvJzFIV2bQHgqoq4canDs2DS7jR+qNG6DRDzR99TzrckGwrvr0+rugTQgq6Lr5w43YxAd/OmH9lbP21S23keZ0PmKlmmBxFlJ9j/+zVsg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=KNrgudgmzOX5uFrNQV2dwcE6ST9TJL2pYV4m02zJjrQ=;
 b=a/SuS4LkPLJsiisagZHSK4yPobzezsNVu2mjSWcgU47yYzVAqkoOOWZXG+ZJN9Xwj9grma7nH0wD+8rKHBsdc6LSOg4dWoHV5jg9CafTk5d2OfpjkxwfIpjWYtIjgFeY9ZbR1+QmOKRUU0mVwra1R2xnCbwQspE32Q+XrY2Ya+ThWuwUVvtWK8SA798yw6o1nR8WnOh/IOLloQKqCdFSyp9/D3reP9QTLARo7HVeF24735alZyQbJ6KfuoERtljeUlQqLisyLTTEDXdedrEmxMHJv1ZnN4vTqXQ5Xppbnd68grFurcYgH4gkD++VyCroaGX8FLjhGm/EhAfqMFa1CA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=renesas.com; dmarc=pass action=none header.from=renesas.com;
 dkim=pass header.d=renesas.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=renesas.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=KNrgudgmzOX5uFrNQV2dwcE6ST9TJL2pYV4m02zJjrQ=;
 b=g6cGJcW7DMi4F+ZhkzIZSf7d8qlnqQmuNZgAEykI+lQ5UYjsu5wQ+tL1DFzazfjDiJguzW/TQJ5kToeLcIWPW04HSAmx7koJC4Fb6Q1rH3bwPdBF6DbF63XF5zhrhICrMENaS6FiWMkCUzVae8G2tIjUfzKXfb+p3YRj8WhOQjA=
From: Jahan Murudi 
To: "Orzel, Michal" , Stefano Stabellini
	, Julien Grall 
CC: Bertrand Marquis , Volodymyr Babchuk
	, "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v2] arm/vgic-v2: Fix undefined behavior in
 vgic_fetch_itargetsr()
Thread-Topic: [PATCH v2] arm/vgic-v2: Fix undefined behavior in
 vgic_fetch_itargetsr()
Thread-Index: AQHb0xLawsf35GKOO0Slf/uLdloOKrPvcB4AgANsdTA=
Date: Wed, 4 Jun 2025 11:19:55 +0000
Message-ID:
 
References: <20250601163212.2988162-1-jahan.murudi.zg@renesas.com>
 <01c5ad19-2add-4270-948d-ecdf3d5e8bd6@amd.com>
In-Reply-To: <01c5ad19-2add-4270-948d-ecdf3d5e8bd6@amd.com>
Accept-Language: en-IN, kn-IN, 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=renesas.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: OSOPR01MB12408:EE_|TYYPR01MB6697:EE_
x-ms-office365-filtering-correlation-id: df9abec2-1510-413c-a071-08dda359bbdc
x-ld-processed: 53d82571-da19-47e4-9cb4-625a166a4a2a,ExtAddr
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?WEtEMVdyRVQzcFpxd2pTZVNBSVh6R3U4ay9LWjl1dVFPY0E1ZFc1NVhENVJU?=
 =?utf-8?B?YXEzSENJQUY4dnRxRGhVY29BaEpJTld5RVhqM01nZEM4ODFQczdKb0p2eGJk?=
 =?utf-8?B?RkNSTjIzcWRtNVVwV3Q3d0FQM1VydksvUzJYbHR4SnBwY2ZQb3d2Yy8raXN5?=
 =?utf-8?B?eitackFoOTRuNXhWZFdDQTNyRnpkTTdEUE9WNlNudjJRNVNhWFJubFl6enV4?=
 =?utf-8?B?RmdMM2JDL2VzeWJYOXpnMEpUa1BIcHpocHNyQmgvT1hFYTMvSzJPVWdnd2pP?=
 =?utf-8?B?Q3lSc0FyNnFhdlF6M1RSOStnK3RFNlhlQlQ1Ny9iaUJQc0tCOVZ4UG5VMzVy?=
 =?utf-8?B?eWpJM3A1empLZVdMbjdMYnNEYkFIczAzbThEOU5UdnFKRUVuMlpXZDJQNnlE?=
 =?utf-8?B?Z2drZytNb3M3Vk4wS0NWd2IwRXRNTGp3alc0ZW9MdTdvalIyTVJsQ1cvakdI?=
 =?utf-8?B?TVlYVmtUR0JvaHFyTnRRYjgzR3Jmd3hvanpLbmg2MVBmc2ppZDZTejZ4UzBs?=
 =?utf-8?B?bkNUaStrWFQzTFd2TTJSdjZQTTJSUk5rVXhCOC9wamVsNU10RzVFR09ZTE45?=
 =?utf-8?B?RGVqNTBFV2JJbFFlQUd3M3l4eE5ZZkNTaXQ3T0tjbVBDWk1WUUNMWTBBU1RI?=
 =?utf-8?B?cEhPZ1U1WWU5YWJSamtaaHUwTUNKTTYySGJPTUZYVkF1SWFWWHdnU3p4YnF3?=
 =?utf-8?B?UWI1Vm5Bc1hYbEphV21reWlPS3JHSmlEOFljdDVyN1VEMnhEVVBKTUt3c2dQ?=
 =?utf-8?B?a2U5NjNoTWVqMkh0dnRFbFJHclQ3em9yY2N4b2RGR09PZzl2WC92NXZBM0Z6?=
 =?utf-8?B?WTNSUEt4V0VsVG1nczBXZEFpSlNJZGZ5UUhvSGhDeUpFZDB0Y0NaZkRLYUtH?=
 =?utf-8?B?TzNERVZJRUE5aWpPQjhqNHdTZisvT1NUSlhwVEp3N2VITjVSZlpLeTFlbEN6?=
 =?utf-8?B?eTl1MkZheWVmYnJJYUxBN0Y1b1pYNnF0ZXk2c3Z4SzlkK1RoS0tpNlFMN1Jy?=
 =?utf-8?B?aklnZ3lEUXl0UnlQU2tyTG4yNGVyZE0zaG82TG5yYUtSZW1adHQyMXFlamMx?=
 =?utf-8?B?cDdJME1FdHZJeTRiMmpwUFErK2ZpMmQzdEpwQW9ISzN5cTVhVHhGYytScHNU?=
 =?utf-8?B?YTJTKzlNNDhjNHJ1MjJmM3RtSHN4VitkeVVXaE9VRVovaXVQUXorNldXSzZB?=
 =?utf-8?B?TjBkWlliSlE2RXY4TGxPaG5rNldYdytHMTZaOWVkUWsyUGMwU2YzZEJvNHps?=
 =?utf-8?B?QXlaRGpwR3grOEYvZDdLTHJPcG50ZmR5b0J6V1FxaFJ3czNEdU9TTG9GQVVV?=
 =?utf-8?B?TXdzc3hseTlpanlqZVpJVEI4M09Kdi9xNDUzRDlhQTR3Y3JTY25NOThORWxv?=
 =?utf-8?B?RDREWjB5TUM5RURReHdxakFKZXpJbndhd2tnT3lmdzAyQTdoNjROUVcrMEdJ?=
 =?utf-8?B?MThYbUJMWFdEM2I4STF1VDVOeFUvVHBTVTVRaVFHVlFxZEwxVitoallsV043?=
 =?utf-8?B?cFFWOStoZHFWVThtZC9QVVRaZ1VEL2dGQnRleEZhWmJtaUNHTTF2VnE0WVlj?=
 =?utf-8?B?Qi8yQklSeThDRGZjbWVXUm96VGNIdi9MY0pvclN6cE5rMktYZXZDSy82L21I?=
 =?utf-8?B?cmpiSHVFMnVvYlY4c3dnQ0xSRUwyNVdDYnlneDZPYW9DWklQemdBSWtGQ3JR?=
 =?utf-8?B?eVBtZWpKMmRjRGZSRlZPYy9WYlEvd1pIN2FzT1U1VmVoUGJVWmx1ZUVHQlcy?=
 =?utf-8?B?NGp3MWdsaG40emJjY2hVbVNUSnhqMnFMa0ZVMU5lSk42SzZpRU90WDJ2ckk4?=
 =?utf-8?B?RW1lMUVES1g2YUxBZTEzQ0RrY3NKQnZSUm5sTGxMK1Y3dE5OWjlkWGYwL3Zk?=
 =?utf-8?B?SGtGK1FPaFd5QlFqVjROSkpydThNc1ByRENGd2J0Vk51d090WERtbFR3NVVa?=
 =?utf-8?B?M3NyNTdHM1RWRDZtVHQ0M2N1ZU1EMjVuZkI3NEtwdHlCbVIyV2RNV2h5RW1r?=
 =?utf-8?Q?L2fgPki68NHeUYwKuZtazhk2+KbNdk=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:OSOPR01MB12408.jpnprd01.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?RmhBU3gvZU5PcmtmeUZxbTdnMUVZUkRvNnM3bXoxYnhSWVFIKzZRVmdvWjht?=
 =?utf-8?B?K2ZnYUNubE5QNGU0Kzk0VzZKdWNjY25qSmVvdHpWNTRwdktyRk9IeEkycmdC?=
 =?utf-8?B?WXFCK2ZFcDNOc2hQeEUyLzQrUUFkdU8vNExqN3ZtenRMVkdZdHhoNDE1QldI?=
 =?utf-8?B?K0NNNjFOZmxqRG9haEJUYURpVnZUeVNtQlJFTklSLzZNY2xCN0hPTWpJaTMx?=
 =?utf-8?B?OU1iZ3V6bEdWaTJrVmd6UnhoeHpKQWtpYnBHbFVnbXg0OHJoU3VWRVc5RSt6?=
 =?utf-8?B?aTRsZzRsMzNQT0FjSlJpdjkzdzNFZHhHS2h2Vm5vTlBBNHpzUVlvTmdaN056?=
 =?utf-8?B?VlMyZnNxRnJOQWdDN2VKNXJ5UTRjd0o4eEJLZEovcUJlaXVabkdtS2xkRWVs?=
 =?utf-8?B?RHMvZjhRbjZmVFAzU2s4NGVDUE54cGV2elJkZE1RQ3RncTh0WUVTdWxmdlBH?=
 =?utf-8?B?Y3ZtWWZXTndLQ2RseFlkMTJBTmVuemo4bEZzL0RkZnozQ1VubkdIZDhQeHNP?=
 =?utf-8?B?Q3huVGR3SHNWWVZON3dQdmprTjJzNWd0QkU5Qlo4WG5lNWMwbGIrYnlzT0o0?=
 =?utf-8?B?SFk0K000cGdMVnJEM0NPQTlJUFRWcWthbU96bDFtaG9SbVdyb3dVRkJMTXVF?=
 =?utf-8?B?cW1BVW9wY0RVZmpzdEdtbVIyTUo3c2p1L1VXdXI0ZzNJZ3lLdWU4cElJa25V?=
 =?utf-8?B?TXNFZCtab0cyeENtTjFlekNIVWFLS0dYQVcxcHU3NFoyOVVhQk1uMTRHUXRh?=
 =?utf-8?B?MGsxQUZvUzB5cktOaXhycWpHUUJsT25od20yQ0lWcmpmd0JsaUIrNCtxWGtB?=
 =?utf-8?B?SEQrRUVkSUlzUTJzTjBoUnFld1BBSkx5UGxkZGp0Wmt5OGJTUVg4Mm15Wng4?=
 =?utf-8?B?Y2JVSTV3V1lWWTBqYnJ3K3FDNzRud1NmMFN6T2dSUTlJOVRCZGJ5d1p6ei9P?=
 =?utf-8?B?K2FrZFRBK2ZZR0JIejE5alh6K3RWaHdMdzd1b0ZPQ2QwS1l5NDFBUXNzY2ox?=
 =?utf-8?B?WmpWMjNtV3VlcTZ0TzNwWlZiVmQ4bTZrNnR2Q2N3NFRLOUxCcU5lb0pGWGR2?=
 =?utf-8?B?REdyWURkOGRjeXQvVUVIbzlqK0NXSG1iNll6TW5INDJjb1oyOEFyTDRDZGth?=
 =?utf-8?B?WTd2UE5ENHRNYnZlcmUrOHArMDlBZWc3MjFRYTNFaG9nL2pkYlFhQ1RnWHE2?=
 =?utf-8?B?OGorMUY2TXlmcytaVHUrcDlRV2FLQkNudkhwa3NxMlhOelZqamNtQzMyVW5v?=
 =?utf-8?B?ek9CZWxmc3pLMUVDV0dPdDBvMlBtNFo3dks3Wng4VFRLNDF5aGJvWTJIVVFM?=
 =?utf-8?B?NUNqR3NMZHlKZytHNjhzVG5nMUxYRkhhNWY3eUVYRFQwY2x5VXhhSUVWOHdm?=
 =?utf-8?B?R0dja1VkcHNUQmlzMjA0RzlWSTlFZ0t2VURVMmFraDU5TGNoaGJlYUJLZy96?=
 =?utf-8?B?Uzg1RU1qMHkxbHowcXZNbHliMU0vVkpXeGR6VWZKK1JIeS9IUUxTaEV4Wkla?=
 =?utf-8?B?Q3FFM2dVWmdld21tUjhFL3Nnd0RkSjRjOGplSXFxSDVmc1RaazJwMXlTaTcz?=
 =?utf-8?B?eDlaMEtYTVZJM1BHNUgyMTZNZ2NQZFh0S3I2ZU5aNGt0bGFETDVHV1RkQVcw?=
 =?utf-8?B?bmhSYmpCQ2U4ejlhS0JVcEp2M2kxZ2tja0JBeTd5YTNMUnp5MUZKSmk3U1VN?=
 =?utf-8?B?bHdIMldXcHFXbGYwZHRYdmc3cjRFbFFHejNFOTJ4Ung3aXoyKzRMbXFPQUta?=
 =?utf-8?B?UksxNitsRGZhSnRGV1dMKzcrMDMvSk0rRjczTVVOMDVNa1VZK2JadXhxTTRU?=
 =?utf-8?B?UnBTVjBLeTNNZmhGRFlwcEltTTdlTDZiTURkWXVZQ3FYa2FsR1BHdVA3S25K?=
 =?utf-8?B?cUhGV2JGUStJZkF5SllBTEc1Zk5iTHVWeVFZTjI1aUk2VE9CUTduTS96bWJL?=
 =?utf-8?B?cVpqWWxNREVLY3pwYlBBZU90UW5HV3RnbnQwWkZ2dk5hMThPSUZxNWlvdXk3?=
 =?utf-8?B?M1pVRU10TjRteEk1clB0NjVPYnFadURVMzFDOC9oTGhiTzJ2dUZRTnNZRkc3?=
 =?utf-8?B?dFRRZnhEYUJRNVdCdVBXQ01SSVdMeFFFSk56M0Q2TWJEcW0veDM2VzVwSUdQ?=
 =?utf-8?B?UXBRbHZHVUVuTmhqbHlZVUhWSUhVQXQxbDJaVWRNaEd6VEN6L0dtQnJzakJF?=
 =?utf-8?B?R2c9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: renesas.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: OSOPR01MB12408.jpnprd01.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: df9abec2-1510-413c-a071-08dda359bbdc
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2025 11:19:55.5073
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 53d82571-da19-47e4-9cb4-625a166a4a2a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 1tKuJCJZiJt8wZGK9PyC3ZPjUp2GSnlycYshKHSNcKGA/wc29kOZuCxWePcF/fU75JVViSN3fzQ6IMrpMMjWf2863qoTfuJI/0Ou4QDuP/U=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYYPR01MB6697

IEhpIFN0ZWZhbm8vSnVsaWVuLA0KDQpUaGlzIHYyIHBhdGNoIHdhcyByZXZpZXdlZC1ieSBNaWNo
YWwgT3J6ZWwgb24gMm5kIEp1bmUuIENvdWxkIGl0IGJlIG1lcmdlZD8NCg0KTGluayA6IGh0dHBz
Oi8vcGF0Y2h3b3JrLmtlcm5lbC5vcmcvcHJvamVjdC94ZW4tZGV2ZWwvcGF0Y2gvMjAyNTA2MDEx
NjMyMTIuMjk4ODE2Mi0xLWphaGFuLm11cnVkaS56Z0ByZW5lc2FzLmNvbS8NCg0KVGhhbmtzLCAN
CkphaGFuIE11cnVkaQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPcnpl
bCwgTWljaGFsIDxtaWNoYWwub3J6ZWxAYW1kLmNvbT4gDQpTZW50OiAwMiBKdW5lIDIwMjUgMTI6
MjQNClRvOiBKYWhhbiBNdXJ1ZGkgPGphaGFuLm11cnVkaS56Z0ByZW5lc2FzLmNvbT47IHhlbi1k
ZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZw0KQ2M6IFN0ZWZhbm8gU3RhYmVsbGluaSA8c3N0YWJl
bGxpbmlAa2VybmVsLm9yZz47IEp1bGllbiBHcmFsbCA8anVsaWVuQHhlbi5vcmc+OyBCZXJ0cmFu
ZCBNYXJxdWlzIDxiZXJ0cmFuZC5tYXJxdWlzQGFybS5jb20+OyBWb2xvZHlteXIgQmFiY2h1ayA8
dm9sb2R5bXlyX2JhYmNodWtAZXBhbS5jb20+DQpTdWJqZWN0OiBSZTogW1BBVENIIHYyXSBhcm0v
dmdpYy12MjogRml4IHVuZGVmaW5lZCBiZWhhdmlvciBpbiB2Z2ljX2ZldGNoX2l0YXJnZXRzcigp
DQoNCg0KDQpPbiAwMS8wNi8yMDI1IDE4OjMyLCBKYWhhbiBNdXJ1ZGkgd3JvdGU6DQo+IFRoZSBj
dXJyZW50IGltcGxlbWVudGF0aW9uIHBlcmZvcm1zIGxlZnQgc2hpZnQgb3BlcmF0aW9ucyB0aGF0
IG1heSANCj4gdHJpZ2dlciB1bmRlZmluZWQgYmVoYXZpb3Igd2hlbiB0aGUgdGFyZ2V0IHZhbHVl
IGlzIHRvbyBsYXJnZS4gVGhpcyBwYXRjaDoNCj4gDQo+IDEuIENoYW5nZXMgdGhlIHNoaWZ0IGZy
b20gc2lnbmVkICgxKSB0byB1bnNpZ25lZCAoMVUpIHRvIGVuc3VyZSANCj4gd2VsbC1kZWZpbmVk
DQpOSVQgZm9yIHRoZSBmdXR1cmU6IFVzZSBpbXBlcmF0aXZlIG1vb2QNCg0KPiAgICBiZWhhdmlv
ciBmb3IgYWxsIHZhbGlkIHRhcmdldCB2YWx1ZXMgMi4gTWFpbnRhaW5zIGlkZW50aWNhbCANCj4g
ZnVuY3Rpb25hbGl0eSB3aGlsZSBmaXhpbmcgdGhlIFVCU0FOIHdhcm5pbmcNCj4gDQo+IFRoZSBp
c3N1ZSB3YXMgZGV0ZWN0ZWQgYnkgVUJTQU46DQo+IChYRU4pIFVCU0FOOiBVbmRlZmluZWQgYmVo
YXZpb3VyIGluIGFyY2gvYXJtL3ZnaWMtdjIuYzo3Mzo1Ng0KPiAoWEVOKSBsZWZ0IHNoaWZ0IG9m
IDEyOCBieSAyNCBwbGFjZXMgY2Fubm90IGJlIHJlcHJlc2VudGVkIGluIHR5cGUgJ2ludCcNCj4g
KFhFTikgWGVuIFdBUk4gYXQgY29tbW9uL3Vic2FuL3Vic2FuLmM6MTc0DQo+IA0KPiBTaWduZWQt
b2ZmLWJ5OiBKYWhhbiBNdXJ1ZGkgPGphaGFuLm11cnVkaS56Z0ByZW5lc2FzLmNvbT4NClJldmll
d2VkLWJ5OiBNaWNoYWwgT3J6ZWwgPG1pY2hhbC5vcnplbEBhbWQuY29tPg0KDQp+TWljaGFsDQoN
Cj4gDQo+IC0tLQ0KPiBDaGFuZ2VkIHNpbmNlIHYxOg0KPiAgKiBBZGRlZCBzcGFjZSBhZnRlciBz
dWJqZWN0IGxpbmUNCj4gLS0tDQo+ICB4ZW4vYXJjaC9hcm0vdmdpYy12Mi5jIHwgMiArLQ0KPiAg
MSBmaWxlIGNoYW5nZWQsIDEgaW5zZXJ0aW9uKCspLCAxIGRlbGV0aW9uKC0pDQo+IA0KPiBkaWZm
IC0tZ2l0IGEveGVuL2FyY2gvYXJtL3ZnaWMtdjIuYyBiL3hlbi9hcmNoL2FybS92Z2ljLXYyLmMg
aW5kZXggDQo+IGExOWQ2MTAxNzguLjY0MjQwN2ZkNWIgMTAwNjQ0DQo+IC0tLSBhL3hlbi9hcmNo
L2FybS92Z2ljLXYyLmMNCj4gKysrIGIveGVuL2FyY2gvYXJtL3ZnaWMtdjIuYw0KPiBAQCAtNzAs
NyArNzAsNyBAQCBzdGF0aWMgdWludDMyX3QgdmdpY19mZXRjaF9pdGFyZ2V0c3Ioc3RydWN0IHZn
aWNfaXJxX3JhbmsgKnJhbmssDQo+ICAgICAgb2Zmc2V0ICY9IH4oTlJfVEFSR0VUU19QRVJfSVRB
UkdFVFNSIC0gMSk7DQo+ICANCj4gICAgICBmb3IgKCBpID0gMDsgaSA8IE5SX1RBUkdFVFNfUEVS
X0lUQVJHRVRTUjsgaSsrLCBvZmZzZXQrKyApDQo+IC0gICAgICAgIHJlZyB8PSAoMSA8PCByZWFk
X2F0b21pYygmcmFuay0+dmNwdVtvZmZzZXRdKSkgPDwgKGkgKiBOUl9CSVRTX1BFUl9UQVJHRVQp
Ow0KPiArICAgICAgICByZWcgfD0gKDFVIDw8IHJlYWRfYXRvbWljKCZyYW5rLT52Y3B1W29mZnNl
dF0pKSA8PCAoaSAqIA0KPiArIE5SX0JJVFNfUEVSX1RBUkdFVCk7DQo+ICANCj4gICAgICByZXR1
cm4gcmVnOw0KPiAgfQ0KDQo=


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 11:33:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 11:33:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005443.1384931 (Exim 4.92)
	(envelope-from )
	id 1uMmMw-00083M-2q; Wed, 04 Jun 2025 11:33:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005443.1384931; Wed, 04 Jun 2025 11:33:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMmMv-00083F-Vt; Wed, 04 Jun 2025 11:33:17 +0000
Received: by outflank-mailman (input) for mailman id 1005443;
 Wed, 04 Jun 2025 11:33: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 1uMmMu-000839-Ph
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 11:33:16 +0000
Received: from fout-b8-smtp.messagingengine.com
 (fout-b8-smtp.messagingengine.com [202.12.124.151])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b0eb7c76-4137-11f0-a300-13f23c93f187;
 Wed, 04 Jun 2025 13:33:11 +0200 (CEST)
Received: from phl-compute-11.internal (phl-compute-11.phl.internal
 [10.202.2.51])
 by mailfout.stl.internal (Postfix) with ESMTP id 9C5F3114015A;
 Wed,  4 Jun 2025 07:33:07 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-11.internal (MEProxy); Wed, 04 Jun 2025 07:33:07 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 4 Jun 2025 07:33:05 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b0eb7c76-4137-11f0-a300-13f23c93f187
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=1749036787;
	 x=1749123187; bh=HVHucHtMlP6nGhlONqDyv1khxvbB4JaPQQFnu+jh2fY=; b=
	RmSB/mR78IyOYI7VGWCuHUzJmpeHR6n+kI6jtSRL9fnzQCgddzkpw79ewuAkFRKh
	3X3q/O3IGnPv4SXsMtT9wIGuwCuZtb35XNh4eG7Cz1rkmN86G4USj3u6RTg309Vn
	3OP/akIO0AR7ws1BKChEJWSr2jV5POmkP5RaAltK9SdrPPoWifrHptXRetCl6BfM
	oTgCNKKDWMu4Bhx6DCuF3jjMpODgjsoF5yEFZljoD8QV8N9PCFPuLRGVT+yAadQ2
	GxqOqfX5LfKEgMhvpbxfDZ4zNb1ZnQbCD29eWYIMwMnNzd0vJPLA0d8xCh5enyjw
	bgozlkyvMkrgcIHJiTBJKg==
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=
	1749036787; x=1749123187; bh=HVHucHtMlP6nGhlONqDyv1khxvbB4JaPQQF
	nu+jh2fY=; b=afSyQJyyGUeb3/MLgZqcLh3W7eLl3lXm1ryldIqogBZ3HuoDXKs
	wYv6SZYhyDjJdlnpx/794mXfC//Iq9atNZPG8PiScfjsCHJsS11eee7Rra5MwNNu
	2Qh/I5kb2apC/ki9+YtPTWt5ceNCNP+LnSS7Np9wfvMwyvR54waw1p0Tjtp2RBm5
	91+FY63BILG53Af+AA6V0rBw6WruIoMVV8z3I9bh4oRoYhPvtt+Usf3E9bx2aUmV
	VT0GvqMSFpSceE7RUjw7sGsOJ88k+JBDgspduOnJgRh7DOmvr4nTcnNJl+Q/E+A1
	X1YC2D2IwNw03E+c/fuKRN93X0J4IvhZd8w==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugddvtdeiucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtjeen
    ucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomh
    grrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggft
    rfgrthhtvghrnhepgfduleetfeevhfefheeiteeliefhjefhleduveetteekveettddvge
    euteefjedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho
    mhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnh
    gspghrtghpthhtohepiedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtoheprghnughr
    vgifrdgtohhophgvrhefsegtihhtrhhigidrtghomhdprhgtphhtthhopegrnhhthhhonh
    ihseigvghnphhrohhjvggtthdrohhrghdprhgtphhtthhopehsshhtrggsvghllhhinhhi
    sehkvghrnhgvlhdrohhrghdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrd
    igvghnphhrohhjvggtthdrohhrghdprhgtphhtthhopegrnhhthhhonhihrdhpvghrrghr
    ugesvhgrthgvshdrthgvtghhpdhrtghpthhtoheptggrrhguohgvsegtrghrughovgdrtg
    homh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Wed, 4 Jun 2025 13:33:03 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Andrew Cooper 
Cc: Anthony PERARD ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org,
	Anthony PERARD ,
	Doug Goldstein 
Subject: Re: [XEN PATCH 9/9] CI: Add timing to junit
Message-ID: 
References: <20250603124222.52057-1-anthony@xenproject.org>
 <20250603124222.52057-10-anthony@xenproject.org>
 
 
 <384fd17a-9236-4727-b564-543edff65e9e@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="gLpLWhxf59BS+ZUw"
Content-Disposition: inline
In-Reply-To: <384fd17a-9236-4727-b564-543edff65e9e@citrix.com>


--gLpLWhxf59BS+ZUw
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Wed, 4 Jun 2025 13:33:03 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Andrew Cooper 
Cc: Anthony PERARD ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org,
	Anthony PERARD ,
	Doug Goldstein 
Subject: Re: [XEN PATCH 9/9] CI: Add timing to junit

On Wed, Jun 04, 2025 at 11:57:11AM +0100, Andrew Cooper wrote:
> On 04/06/2025 9:48 am, Anthony PERARD wrote:
> > On Tue, Jun 03, 2025 at 11:35:22AM -0700, Stefano Stabellini wrote:
> >> On Tue, 3 Jun 2025, Anthony PERARD wrote:
> >>> From: Anthony PERARD 
> >>>
> >>> Signed-off-by: Anthony PERARD 
> >>> ---
> >>>  automation/scripts/run-tools-tests | 5 ++++-
> >>>  1 file changed, 4 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/automation/scripts/run-tools-tests b/automation/scripts/=
run-tools-tests
> >>> index 852c1cfbcf..e38cc4068c 100755
> >>> --- a/automation/scripts/run-tools-tests
> >>> +++ b/automation/scripts/run-tools-tests
> >>> @@ -18,9 +18,12 @@ for f in "$1"/*; do
> >>>          continue
> >>>      fi
> >>>      echo "Running $f"
> >>> -    printf '  \n' "$f" >> "$xml_out"
> >>> +    time_start=3D$EPOCHREALTIME
> >>>      "$f" 2>&1 | tee /tmp/out
> >>>      ret=3D${PIPESTATUS[0]}
> >>> +    time_end=3D$EPOCHREALTIME
> >>> +    time_test=3D"$(bc <<<"$time_end - $time_start")"
> >> As it looks like no other scripts need bc at the moment but we already
> >> rely on awk (automation/scripts/xilinx-smoke-dom0less-arm64.sh) I'd
> >> prefer this version:
> >>
> >> time_test=3D"$(awk "BEGIN {print $time_end - $time_start}")"
> > You mean I have to choose between busybox and busybox?
> >
> > $ ls -l $(which bc awk)
> > lrwxrwxrwx    1 root     root            12 Feb 13 23:19 /usr/bin/awk -=
> /bin/busybox
> > lrwxrwxrwx    1 root     root            12 Feb 13 23:19 /usr/bin/bc ->=
 /bin/busybox
> >
> > :-)
> >
> > I guess it doesn't really matter.
> >
> > One difference though:
> > $ awk "BEGIN {print $time_end - $time_start}"
> > 3.28798
> > $ bc <<<"$time_end - $time_start"
> > 3.287982
> >
> > awk is less precise, but I guess that doesn't matter as well, gitlab UI
> > isn't going to show the extra digits.
> >
> > So I guess I can change to use `awk` instead, just in case for some
> > reason `bc` isn't present, since `awk` seems mandatory for many of our
> > scripts.
> >
> > Thanks,
>=20
> bc is a normal posix utility just like awk is, so there's no change in
> dependencies caused by this.

Linux requires bc for building, and I _very_ often find systems where it
isn't installed by default (by awk is)...
Anyway, that's probably irrelevant in the CI container that has busybox
for both.

> Furthermore, it is the right tool for this job in a way that awk isn't.=
=C2=A0
> Besides the reduction in precision, see xen/tools/check-endbr.sh for the
> number of ways we found that awk malfunctions with large numbers.
>=20
> I firmly suggest continuing to use bc here.
>=20
> ~Andrew

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

--gLpLWhxf59BS+ZUw
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmhALu8ACgkQ24/THMrX
1ywPrAf/WXoFOT1N4ZV7X58Tedefv5mCJsCSPQPPZUZGy+uhm22fwPH6ER5MFJl8
K3jcH/gsao2efdSOAmGzdVFT3AEj+ICoxVsYo/T+IaMZ+8Y9xtWIZ4xLHrYDf41/
+JOvXkdTbTRu5QK67h4xGUlsst3WsZfyBj0pZF9nHF66zwJLc6DLWRv0bGk2+z3Q
+hSa0ROB2kfupptaFoMb0Z/0dPvpLbTFKqGVDWO/u4X5yoz7RHyGE5Aw0PAMrHRG
HndYo6mYnZRA+SB+zGSF8Y+oVp+Vx2T1s5yk5wZg2Yz9vbuNyMQvZpYSfTKXPPbF
yfm9M01Sy86nC9xQ015X212Ux63O9A==
=f70P
-----END PGP SIGNATURE-----

--gLpLWhxf59BS+ZUw--


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 12:35:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 12:35:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005486.1384941 (Exim 4.92)
	(envelope-from )
	id 1uMnKs-0007IX-Kr; Wed, 04 Jun 2025 12:35:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005486.1384941; Wed, 04 Jun 2025 12:35: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 1uMnKs-0007IQ-Hy; Wed, 04 Jun 2025 12:35:14 +0000
Received: by outflank-mailman (input) for mailman id 1005486;
 Wed, 04 Jun 2025 12:35: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 1uMnKr-0007IK-58
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 12:35:13 +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 5af4853f-4140-11f0-b894-0df219b8e170;
 Wed, 04 Jun 2025 14:35:11 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a375888197so3521965f8f.0
 for ; Wed, 04 Jun 2025 05:35:11 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-747afeab82csm11380773b3a.55.2025.06.04.05.35.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 04 Jun 2025 05:35:09 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5af4853f-4140-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749040510; x=1749645310; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=1tAd5m2TcM3QJHb3JDxfCf5+jsBmE8HBnvy/3Jh1sts=;
        b=bR0lK1m3U7oUxzKvuRf5GcVl5LHbrq1wxDKN1NQETMFtZGY06RRuLAPLZuwUxyK45t
         sCnS6C65fKB4QrDcq57rNs7zCzXKi1GNZnmFbDLuRpkVv7q7AOgC/L/vzTX3eGfQImy5
         xla8adJv2qcegOfhC4I9EsKj8aUX7y5d02SpKpITMaSnxrymAqsO8AHicptk+PFcIqOA
         eQbo6j6//0xyggLB0Qjw1UffFyckUDt6hu623m82joUrHPPFWEbUMrJ71DroaXcoETPt
         X4Wd/E/hrdNLidvKZsfT0yd2iISjhBOXnBZ8PqfrkqfnZ4l6Qxz4Fxw6eDrLf6SHlCVD
         VczA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749040510; x=1749645310;
        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=1tAd5m2TcM3QJHb3JDxfCf5+jsBmE8HBnvy/3Jh1sts=;
        b=g2McoOcO21fJQfH4saOyeUegBXO8NY7VtdR1MLt4woD4wxUqjdjgnYNbHaSJ5zgN18
         e5JeAUCvRelUKOPo70j5i1dftTRflCOPKRwdT/Uh5VMcRGEgNv/ijXCYKzOc9JLckY5p
         LMYaRwKdt5sn963FrWL7RxXgdlaqvl63jpuPNiJuFkPFw8I2jVijqNM/JDO3xn03dx7c
         Z7oV+9f577D+uQ+S+rVjmzWbcUU6Mcva84Dd1rY4aLiPmugGVJbEg5ubdTMdmYTQVPqz
         kmVHenM6AFlZze6x7LbhCWt/f+ew1vNQ1DlfgmMzJeUBx0IghGyDnPMg61Db7TYfY2r1
         aseQ==
X-Forwarded-Encrypted: i=1; AJvYcCVOQCYfQ1XrF8EeEs50Laqc7ZnuvslMvmPU9Ba8cN2yIkwkro07Lp/dXmgXUiZ9V0m2SBxfjv5GCUM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxbQQWemedaXx4GzyNxkkFnyjjp7FoyF8cR+b3anwFCxALBb+Yd
	UfhOLP2oC0e+tQB4pdFBXiYt2EbWkRpbkWqsEzBg0lKVbQFH+JFte6sM6c7JLrB+zA==
X-Gm-Gg: ASbGncuNUI9Uy3YOGy1lNbsp5FueIV8hVtP4sGox+sMQdeaMYPuR/JigW+X6d+GX997
	fUz6u92EstCtW8bnfMwhEf5uqBZRRWcYBr2ed+IbKqsXNxt7GFGPWEFoddNyY8RFNlbanRlzLr8
	+TV0mWl8dLpitnmsNhXi2SwsgS3XQ5n+II/x/PyjTn+pHOmLXtI3Bff9dcFojgXF+hcayWW7rhT
	HD7INiitOGBOYOOaiuUyuytkDO6MyiSWFqHdy1q7aU8eRmyckkc5pvhkpCXElpbrI+YT40cWXFH
	p09qbwuStU0JYvIuRs/PiXvmTfo+En041rqbHgqbL97wE60zI2/yBaSmaTAaYHCb5A8yE+FxyMo
	icpLTY6hwisdLy3cdUlrfyXUk2UxLMG9+IOJO
X-Google-Smtp-Source: AGHT+IFe5xYdohDuhW9RkI44ugFsu2qAySQWdut7u0gzj5yoBiqyHmWVaMgK37lDMAUnIdj8tIqIwg==
X-Received: by 2002:a05:6000:430c:b0:3a4:f435:5801 with SMTP id ffacd0b85a97d-3a51d923793mr2129251f8f.17.1749040510348;
        Wed, 04 Jun 2025 05:35:10 -0700 (PDT)
Message-ID: 
Date: Wed, 4 Jun 2025 14:35:01 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] x86/numa: introduce per-NUMA node flush locks
To: Roger Pau Monne 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250522084815.825-1-roger.pau@citrix.com>
 <20250522084815.825-3-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: <20250522084815.825-3-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 22.05.2025 10:48, Roger Pau Monne wrote:
> Contention around the global flush_lock increases as the amount of physical
> CPUs on the host also increases.  Sadly this doesn't scale on big boxes.
> However most of the time Xen doesn't require broadcasting flushes to all
> CPUs on the system, and hence more fine grained (ie: covering less CPUs)
> locks could be used.
> 
> A natural boundary to use when splitting the locks are NUMA nodes.  Most
> domains will be limited to running on a single node, specifically the one
> where the domain memory has been allocated from.  Flushes related to
> domains are most likely to be limited to a single NUMA node, and hence
> being able to execute per-node flushes allows to reduce the contention
> around the global flush_lock, while also allowing to perform concurrent
> flushes on different nodes.
> 
> This however doesn't come for free.  A new vector must be allocated to be
> used for the per-NUMA flushes, and more logic is required in the flush
> dispatcher to figure out whether a flush is limited to a single node.
> 
> The figures on a 2-node NUMA system are as follows, after having been
> running the same XenRT boot storm workload for 90 minutes.
> 
> Without the per-NUMA node flush:
> 
> Global flush_lock: addr=ffff82d040837340, lockval=d8ded8de, not locked
>   lock:21878876(98178042228), block:1603338(6043805110)
> 
> So a total block time of ~6s, and average block time of 3.7us.
> 
> With the per-node locks:
> 
> Global flush_lock: addr=ffff82d040837360, lockval=78e678e6, not locked
>   lock:6781028(41032945811), block:583712(2025657239)
> NUMA node 1 flush_lock: addr=ffff832fd085b110, lockval=5cd65cd6, not locked
>   lock:220374(766500536), block:4091(9933129)
> NUMA node 0 flush_lock: addr=ffff8310336a7110, lockval=5c715c71, not locked
>   lock:547953(1658170241), block:23856(51266297)
> 
> The total block time goes down to ~2s, and the average block time is 3.4us.
> The total block time of the per-node locks is much lower compared to the
> global flush_lock, 9ms and 51ms respectively.
> 
> Note the example here is possibly the system where such split locks don't
> make a lot of difference, being a 2 node system, but still there's a
> non-trivial difference between the block times.  On a 4 or 9 node system
> the figures should likely be even better.
> 
> Signed-off-by: Roger Pau Monné 

The savings must be from TLB flushes only? Cache flushes, as we have discussed
recently, need to be global anyway, and hence there are no savings to be had.
This may want reflecting the subject and/or description.

> @@ -126,3 +129,95 @@ int __init arch_get_ram_range(unsigned int idx, paddr_t *start, paddr_t *end)
>  
>      return 0;
>  }
> +
> +static struct arch_numa_node {
> +    const void *flush_va;
> +    unsigned int flush_flags;
> +    cpumask_t flush_mask;
> +    spinlock_t flush_lock;
> +    struct lock_profile_qhead profile_head;
> +} *node_info[MAX_NUMNODES];

__ro_after_init or at least __read_mostly?

> +static int __init cf_check arch_numa_init(void)
> +{
> +    unsigned int i;
> +
> +    if ( num_online_nodes() == 1 )
> +        return 0;
> +
> +    for_each_online_node ( i )
> +    {
> +        struct arch_numa_node *node =
> +            alloc_xenheap_pages(get_order_from_bytes(sizeof(*node)),
> +                                                     MEMF_node(i));

A full page for what may cover just a cacheline or two? I realize ...

> +        if ( node )
> +            clear_page(node);
> +        else
> +            node = xvzalloc(typeof(*node));

... this (sadly) still has no NUMA-capable counterpart, but I'd have expected
at least a brief comment to justify.

> +void cf_check invalidate_tbl_numa(void)

Nit: s/tbl/tlb/ ?

> +bool flush_numa_node(const cpumask_t *mask, const void *va, unsigned int flags)
> +{
> +    nodeid_t node = num_online_nodes() > 1 ? cpumask_to_node(mask)
> +                                           : NUMA_NO_NODE;
> +    struct arch_numa_node *info;
> +
> +    if ( node == NUMA_NO_NODE )
> +        return false;
> +
> +    info = node_info[node];
> +
> +    if ( !info )
> +        return false;
> +
> +    spin_lock(&info->flush_lock);
> +    cpumask_and(&info->flush_mask, mask, &cpu_online_map);
> +    cpumask_clear_cpu(smp_processor_id(), &info->flush_mask);

IOW this function is strictly a helper of flush_area_mask(), relying on
the local CPU to have had its flushing done already. Might it not be
better if this was put as a static in smp.c then? Or, to keep struct
arch_numa_node local to this file, split it into two parts?

> +    info->flush_va = va;
> +    info->flush_flags = flags;
> +    send_IPI_mask(&info->flush_mask, INVALIDATE_NUMA_VECTOR);

This one similarly depends on flush_area_mask() behavior, not calling here
when mask has solely the local CPU set.

> --- a/xen/common/numa.c
> +++ b/xen/common/numa.c
> @@ -689,6 +689,29 @@ static int __init cf_check numa_setup(const char *opt)
>  }
>  custom_param("numa", numa_setup);
>  
> +/*
> + * Return the NUMA node index if all CPUs in the mask belong to the same node,
> + * otherwise return NUMA_NO_NODE.
> + */
> +nodeid_t cpumask_to_node(const cpumask_t *mask)
> +{
> +    unsigned int cpu;
> +    nodeid_t node = NUMA_NO_NODE;
> +
> +    if ( num_online_nodes() == 1 )
> +        return cpu_to_node[0];

The sole caller checks this already, so strictly speaking Misra would consider
this dead / unreachable code.

Similarly Misra may not like this on Arm, where it's unused right now. Then
again looks like NUMA work there was abandoned, so for now all ought to be
fine here.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 12:43:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 12:43:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005500.1384950 (Exim 4.92)
	(envelope-from )
	id 1uMnSM-0000WK-AD; Wed, 04 Jun 2025 12:42:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005500.1384950; Wed, 04 Jun 2025 12:42:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMnSM-0000WD-7i; Wed, 04 Jun 2025 12:42:58 +0000
Received: by outflank-mailman (input) for mailman id 1005500;
 Wed, 04 Jun 2025 12:42: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 1uMnSK-0000Vd-Fh
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 12:42:56 +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 6f205ea7-4141-11f0-b894-0df219b8e170;
 Wed, 04 Jun 2025 14:42:54 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3a36e090102so3940694f8f.2
 for ; Wed, 04 Jun 2025 05:42:54 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3124e2c284dsm8835785a91.11.2025.06.04.05.42.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 04 Jun 2025 05:42:53 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6f205ea7-4141-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749040974; x=1749645774; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=mA4TmxYayexRiMjd9XMf0pd9INNo8GBli4r/JCX2tuA=;
        b=R0IcJGo9+B2BPKa+wSXRHTwX60hpU91IMVz3GEEdeNU/zOmMX4T7nLkrsUJBjhN23B
         uUhhPcKt12UlS3uO7Yhl02hEUuIm4BK3nXzy918T6fjllC9ALpfxRhVeKj1x1xFI9qrx
         ZAPzJkhGFevmrK5iR6ttFu/Vz0IL5Hl8oBRaHIIoXH+Uet5K6Np1rCRjyUKLVlYbAB/U
         5pb23VYICExPuicIOv9Cbqx1jqouLCW6bGeVDFLVsqtXeyw3vsEgWQOGQ8phZzenz8pP
         t2ryOZ4MWuPwYjJ8Uw2oqKe1r/E4ERZgInN+1tEkseD68mfjtZK8RnH9zLDcXgU5ztxz
         vWMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749040974; x=1749645774;
        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=mA4TmxYayexRiMjd9XMf0pd9INNo8GBli4r/JCX2tuA=;
        b=oY9YJoDgd8OcM88M2INhhS1JHjT1zf53BRfloDSoLaZRNeXQuBwd+KVwqWPctb8Unk
         o+oUTHFKV5hJN+xHgBzCs+vqzviBQ/VIz1X0vXnqT30iyEc6JJeRD4BXCSmydeYMYnks
         smI4Zw9gfgpmcGIal9wDaD47rlyd3hqeOq26SC+8EOuwDpHgpHybJDXfqNI5ka+BFeWU
         tknR33cEWx24dzctODdm0sOz06GWJLUdFP4uih1wZJ8qF2DWQzwFtV1+8v3KWbWfPKyA
         ZH5TV7KBjUeWEF5ZpOFpjOnzYmPYoHSLLtQ+9EfkO+U1zGJwtyTyEV2uZjbaSiRCmF/O
         1pxg==
X-Forwarded-Encrypted: i=1; AJvYcCW6MLQArZqyPvlQZo5Hff6JfRO8s/N1dJZS7axv2uFp44U7aOv2BR8nnO3uKx6Z8DI5no/6ChQ+qVs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YysLpb3UUPBwY8IAzLOh01unZ1suK+RJw50VO5q9ZzGnwoMLJmR
	hahm1RYK14A20vD8O3/aFuSqSah/ZMt0me/JNGMlfzat7EQgNHgTE1Al6+Ol0d4rKg==
X-Gm-Gg: ASbGncvBOcDAytc42ZAwhBwZDRTDOh1Nc0zeboowG9Zf8Bh1nbuBeRNWjMirosfsENS
	Xv48TIJRtJcHTK9BjQhXHzAkXQVlhUfjk86ZJlIlDINm7+e8nWClxc7ZiqFhVnxQx5axMNWkWld
	rNm8m/IQrlRRtonsSSO2XnyPXga4fViH6KN+4dMmjF6312Csx+U7iHXgwgAP7Q8sHb8tauAtEqI
	WGlJKlqa6+wdmOKP3sDIVsyEIF3lQIs1U5cWLXfOT3VkL4tx8ekVTvm/b62PJz+vw8qL5RLy/XQ
	Q9VQcg8eI/zC02Aqy2H/ZvPXVsXBRQt43WUe5f/ZBEeUIIGDAXWJntdKMIP1pQ2hBTUM/zupOMP
	i+Yn1SQXFgd8pJnDdYa6zW3ZxFCYKy5HQ1fyBEYUTEORbXJ0=
X-Google-Smtp-Source: AGHT+IH2DIwyN/2U28Q8nyTv+/5DQc1G3N6C56uxMa4glVhhGGnNtYx2FzenrLx2u33Dl8/tnARTBg==
X-Received: by 2002:a5d:4805:0:b0:3a5:2182:bd17 with SMTP id ffacd0b85a97d-3a52182c0eamr1350639f8f.19.1749040973761;
        Wed, 04 Jun 2025 05:42:53 -0700 (PDT)
Message-ID: <2c120e48-edaa-4518-a92e-38872bfc6eac@suse.com>
Date: Wed, 4 Jun 2025 14:42:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] x86/numa: introduce per-NUMA node flush locks
To: Roger Pau Monne 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250522084815.825-1-roger.pau@citrix.com>
 <20250522084815.825-3-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: <20250522084815.825-3-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 22.05.2025 10:48, Roger Pau Monne wrote:
> +bool flush_numa_node(const cpumask_t *mask, const void *va, unsigned int flags)
> +{
> +    nodeid_t node = num_online_nodes() > 1 ? cpumask_to_node(mask)
> +                                           : NUMA_NO_NODE;
> +    struct arch_numa_node *info;
> +
> +    if ( node == NUMA_NO_NODE )
> +        return false;

One further question: Here you limit NUMA flushing to a single node, using
global flushes in all other cases. Did you consider extending this? Savings
ought to be had also when you want to e.g. flush on 2 out of 8 nodes. That
is, would it perhaps make sense to break up the file-scope flush_* variables
in smp.c altogether, using the NUMA approach uniformly?

> +    info = node_info[node];

node_info[0] would then need populating from a static struct instance, of
course, and ...

> +    if ( !info )
> +        return false;

... such conditionals of course would need to go away. Then we'd also get
away without requiring yet another direct-APIC-vector, as ...

> +    spin_lock(&info->flush_lock);
> +    cpumask_and(&info->flush_mask, mask, &cpu_online_map);
> +    cpumask_clear_cpu(smp_processor_id(), &info->flush_mask);
> +    info->flush_va = va;
> +    info->flush_flags = flags;
> +    send_IPI_mask(&info->flush_mask, INVALIDATE_NUMA_VECTOR);

... INVALIDATE_TLB_VECTOR could then be used here.

Jan

> +    while ( !cpumask_empty(&info->flush_mask) )
> +        cpu_relax();
> +    spin_unlock(&info->flush_lock);
> +
> +    return true;
> +}


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 12:43:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 12:43:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005506.1384961 (Exim 4.92)
	(envelope-from )
	id 1uMnTC-00011G-KN; Wed, 04 Jun 2025 12:43:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005506.1384961; Wed, 04 Jun 2025 12: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 1uMnTC-000119-Gt; Wed, 04 Jun 2025 12:43:50 +0000
Received: by outflank-mailman (input) for mailman id 1005506;
 Wed, 04 Jun 2025 12:43: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 1uMnTC-00010z-3M
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 12:43:50 +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 8fd26a96-4141-11f0-a300-13f23c93f187;
 Wed, 04 Jun 2025 14:43:49 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3a51481a598so1127258f8f.3
 for ; Wed, 04 Jun 2025 05:43:49 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3124e3d4b6dsm8847157a91.45.2025.06.04.05.43.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 04 Jun 2025 05:43:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8fd26a96-4141-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749041028; x=1749645828; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=555Hmb33Ir+0XtpJymECE0VBTEfBzKFFNJkE+4GGjdE=;
        b=gpm1NpnVZruP/OF6x5C/Sg/9P1yQ2NgUVfQxLnIZp11F+MxO0ozgU37c7zh97z0bJ6
         sXMXD/63hrRzVyfmRy0TskGE8RM2iDR8aTK9a1q2JFe9RGxzQ5tPye87ywRDIPFgmBQB
         KSwYpST5Q34y3DC/f+J2hgvwKkacgzBK/BS2wD8Y/dgt7fzT9nN+gl+9YCtXTTpRuMrQ
         wWocOdIBX1KP8Ku6c1BnmmSiDnwY1F7UgvKI7tDO34lMGZjRlZ8J/HwjLIojFzvNAGhb
         Fs46VYtCplEot1Kx/9sVIaLUZxIuokJ0FcKmt09bR2HICTISghkuoEI+KNExjvX/lWKD
         HF9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749041028; x=1749645828;
        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=555Hmb33Ir+0XtpJymECE0VBTEfBzKFFNJkE+4GGjdE=;
        b=j4ZHY735M75jro2t+zxx3J+5jqFWsfhvZGVf5rmeFEw5H5F2hHurolAGOm20RS4EHg
         65SoBJl3qqQIvsgqnD/3iW2WiR921mSIvH/pNO3av3iRQ4bNaR46AFG1ivALm6GgmR6u
         yKX0nmknYwW1AmrWAUD9QB0nJKx2ofUw2gyU7Kihign3DS59nwxY1hs9ouTK8kCI8hf4
         5SrfF+tZUvFTwR4mopAG7Aegag2tChqJ7FwZtMw4/JxGd7KhYLzGx6L2rL1c0wrT56SH
         Xsqi0+aYGeC/0f4SiatWhfPbNGoCYVqkw5ZFeI9grpNNTaeYqA72zs7iukCvpYtaNa71
         cU1g==
X-Forwarded-Encrypted: i=1; AJvYcCW9/vOsv8AQFJg8mo61qol6QrioiCsjMZt3DyIrlA3w8UPTYo5FadP/5YBcoRUDDVx3NsZw3HHTltM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxbZ7SycX8w5L10Pg3qfbb1g337uPk2o+x1fPGK2ljgFQhNlepG
	lv1UWdw7BUZ9J6RILNKP8Upgt3ShzaQUsUvCL4osfg76F9jIAm7MrDJM9qivTJYYQg==
X-Gm-Gg: ASbGncsLc65ptIoerBULVe4SVwJbkATfOg5e+oNquoeVH59Thn5a4CiBhDT1PU8GJTS
	iOEkNcGbUTRSX5Cc9uo/D3BpnA7OGs+hytPrLfSSqw2zQd0UAA6l6RYIP32IWK79x+rgqoOBe00
	VGAyjUJjYKZ1EnOHOrLchBxwTesINwHO6IWSx0TWCoxD4TYzqNVb8mXpirl/e3ChImirLEyeFvz
	optxym1Jnc7d7fvW9gmVMWHYtZWqIEIAyPmByXBItiYDlE/m8gKA5bvAYpxd5uwyBm8I5B4rsfy
	Ve7oiHwK2B0mST8RJy1ThuXGqWAyGpTJVvV1tYgtVmXY869exmVY/XoXhaM7BjgxbbfOwRnTF0i
	LdFsrQtZX2A/HZX0zI90QehLxQvxbzTcYn6qo
X-Google-Smtp-Source: AGHT+IGp7fmNwXlvYYX4jYZ5yBaRWzspEd1rgOH0yHzz1CcrYZ7UrfSBS2qlWErTB/4FG6O4rUDKoQ==
X-Received: by 2002:a05:6000:3105:b0:3a4:ef00:a7ac with SMTP id ffacd0b85a97d-3a51d974cd2mr2454074f8f.45.1749041028577;
        Wed, 04 Jun 2025 05:43:48 -0700 (PDT)
Message-ID: <8ffbb281-6297-4f78-981b-1f4c6fc1ff29@suse.com>
Date: Wed, 4 Jun 2025 14:43:40 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] x86/numa: add per-node lock profile objects
To: Roger Pau Monne 
Cc: Anthony PERARD ,
 Andrew Cooper ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250522084815.825-1-roger.pau@citrix.com>
 <20250522084815.825-2-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: <20250522084815.825-2-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 22.05.2025 10:48, Roger Pau Monne wrote:
> Add some basic infrastructure to be able to use lockprofile with per NUMA
> node locks.  This patch just introduces the required types, plus the
> printing of the data for the newly introduced type.  There's no user of
> per NUMA node locks introduced here.
> 
> Signed-off-by: Roger Pau Monné 
> ---
>  tools/misc/xenlockprof.c    | 5 +++++
>  xen/common/spinlock.c       | 1 +
>  xen/include/public/sysctl.h | 3 ++-
>  3 files changed, 8 insertions(+), 1 deletion(-)

Just one nit: Nothing here is x86-specific, so the subject prefix may want
adjusting.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 12:48:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 12:48:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005513.1384971 (Exim 4.92)
	(envelope-from )
	id 1uMnXk-0001f7-48; Wed, 04 Jun 2025 12:48:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005513.1384971; Wed, 04 Jun 2025 12:48:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMnXk-0001f0-19; Wed, 04 Jun 2025 12:48:32 +0000
Received: by outflank-mailman (input) for mailman id 1005513;
 Wed, 04 Jun 2025 12:48:30 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uMnXi-0001eu-Pe
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 12:48:30 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uMnXi-001uWN-0w;
 Wed, 04 Jun 2025 12:48:30 +0000
Received: from [15.248.3.91] (helo=[10.24.67.75])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uMnXi-000gpF-1i;
 Wed, 04 Jun 2025 12:48: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:Cc:
	References:To:Subject:MIME-Version:Date:Message-ID;
	bh=UcRq1X/Jk/hGFNv8Vnqvksc8YIMxv4iDO52XpfmJ4Oo=; b=dqn4bMeaztrA62b5yP9b61DUjj
	OhjTbw2K7pO6NGif+C4eUd9VxiVJkvDVhq62IvcHQLBZJqBoqI4TUL+RRk9L2WiGJ2UeO1eyHfhEE
	kjp4B/Sj9VlQcBhzqjCnR33ds1qL5JarFv7fIveCKcw9ZYn/KmfTpPO0mvMF9FFJJ2BY=;
Message-ID: <56e44ec8-c9c0-4d58-98f3-730cc1c1bb86@xen.org>
Date: Wed, 4 Jun 2025 13:48:27 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v11 4/7] xen/arm: smmuv3: Add PCI devices support for
 SMMUv3
Content-Language: en-GB
To: Demi Marie Obenour , xen-devel@lists.xenproject.org
References: 
 <71741747bdc0cfcacbe86e66ddd6239ea2f5a3af.1748422217.git.mykyta_poturai@epam.com>
 <9bfc305b-602e-4c96-bd7a-763075e506d7@gmail.com>
Cc: Bertrand Marquis ,
 Stefano Stabellini ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Stewart Hildebrand ,
 Mykyta Poturai 
From: Julien Grall 
In-Reply-To: <9bfc305b-602e-4c96-bd7a-763075e506d7@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Demi,

When replying to a thread, please keep the folks in CC unless there is a 
reason to drop them. Sending to just xen-devel is likely going to be 
lost. I personally don't always keep an eyes on discussion where I am 
not CCed, there are too many!

So adding re-adding the CC for you and keeping your reply as-is.

On 29/05/2025 03:10, Demi Marie Obenour wrote:
> On 5/28/25 05:12, Mykyta Poturai wrote:
>> From: Rahul Singh 
>>
>> Implement support for PCI devices in the SMMU driver. Trigger iommu-map
>> parsing when new PCI device is added. Add checks to assign/deassign
>> functions to ensure PCI devices are handled correctly. Implement basic
>> quarantining.
>>
>> All pci devices are automatically assigned to hardware domain if it exists
>> to ensure it can probe them.
> This is only safe for devices present at boot time.  It’s not safe for
> hotplugged devices, which should be quarantined.

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Wed Jun 04 12:55:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 12:55:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005532.1384981 (Exim 4.92)
	(envelope-from )
	id 1uMneq-0003af-TG; Wed, 04 Jun 2025 12:55:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005532.1384981; Wed, 04 Jun 2025 12:55:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMneq-0003aY-Q5; Wed, 04 Jun 2025 12:55:52 +0000
Received: by outflank-mailman (input) for mailman id 1005532;
 Wed, 04 Jun 2025 12:55: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 1uMnep-0003aQ-DL
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 12:55:51 +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 3dbb0ee3-4143-11f0-a300-13f23c93f187;
 Wed, 04 Jun 2025 14:55:50 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a375888297so631167f8f.1
 for ; Wed, 04 Jun 2025 05:55:50 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-747affd437asm11070294b3a.150.2025.06.04.05.55.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 04 Jun 2025 05:55:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3dbb0ee3-4143-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749041750; x=1749646550; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=SwEsN8riVOQhHVvIwBUlpvCCfcOS2+JYdhTkiCBfZiA=;
        b=ZYkb+Fw4zh5Xk1miz5RoWJo0pQPWvnIApYInbbhMOtOnsDcgslS8oPvlqZbSp+PHB0
         f3iW80QJg3ddfDEdnBKcJN208D6PR6LI4FjD+4MdzFdPx/03VVk8zX1lH2ba8PeMdkQx
         hcTSuQodi9b2rGzSolIMsvmy1XhqPBrn+HBH0mFq1rngo4A2ie4NzqN5L3nCpO1ZfxyV
         o0fTgqW+lpZnrhhDyo9hes6Ap5AtuwEDzoOzuRAirg2Ctw73hL1sKCrYuyOI1Ksm5lSA
         /Auv5XbtPSTXCUVNREldRiEfDHHyJMGfzDX583vZxgKVJweOlIdZ/LWlbcuh+P/yXQAq
         24Bg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749041750; x=1749646550;
        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=SwEsN8riVOQhHVvIwBUlpvCCfcOS2+JYdhTkiCBfZiA=;
        b=YRxuQZaJ3jhlDETovTEv2uXzXKV+yp0UOKPX1toWAIRCAaeqwGpPTJTDaf07BrriRb
         DNNicS1z02fqReaZjRnYgxt6Mk0yF7U2Gpfk513KZE5bfNIVixVCQIyObEOwa9OFG4V1
         nY0Ez4iktK8DXZ+nYBG+J12tEBez45+rw2nNSR/yK06WfYSfpEVuYmtIaCEsJf9OlMT+
         NUxCO3aSpOlmXSssczOi11znUcr1GofpICQwU7udg2zPLDCDtqzc53goiRyl3AyJsh5r
         3NOLALTbIkX1Hb5vffCD656xu3WNa/ik1oo884WVoBu3YNITKTan2mq86bXnRnhtq7mf
         vjOQ==
X-Forwarded-Encrypted: i=1; AJvYcCUjq9XunYo9P7J5Sdeq9SvxWO3ydwswWhK9gMviUsl82rffS59sxGs5VFfn+HKTlXeCofkDCybKS4c=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyK+t5G0R2TmmS2Wm7gnaDEcM7GuK0OhdkKr+JJWfNVOS+e5F6N
	ircFSNhx64IkfRym0bpLHjFQ1jltlC2xf/yo/hA80+bTVE2m+sZO9anSwanpW+n7rw==
X-Gm-Gg: ASbGncvrAG579JBEcwjp7b7SAW6PnVV4lY73V8DEfO7n+mh6FOPgHDE7wJB8fk2Jfn7
	NAjuCRLJMpcMDKIgNKadosSFWbO2xr9DtDatn2mOFjFqV0zkPeeiw8cFAbrxRf0cb4nwgzicpHm
	cZBHiKztQrosjSzu/ZIwA09uMXXGgYQ1DnCjY8Y030G9vyNPebfilombGTPl7+jdbvXCAOlShXL
	+F58WdBqFaoGbrXNSEQjFlBVloLBiazrk9r5Vu9RuGC1rWyPOYAU3oJHS/LwWvnfKh3LeoTITg2
	cMryxs9eE2pqiwpImXaopDe5TQryY+zl4KtV6Y05xwdxDhyYv4v57O/76rRcFToxJ3fzkmyQj8k
	U+sCmYAYmFx7gQDEsjbM4B4XEj1lRbNsmo/Xr06aw+bW0uew=
X-Google-Smtp-Source: AGHT+IEmSbwcKsgPKaH72eDwzO6/RXZClFff1QaiWghVzUznvO2srghKd3ULdRoN/TxlwKNXH2m6dg==
X-Received: by 2002:a5d:5847:0:b0:3a4:ed9a:7016 with SMTP id ffacd0b85a97d-3a5141cfce3mr5426662f8f.26.1749041749761;
        Wed, 04 Jun 2025 05:55:49 -0700 (PDT)
Message-ID: 
Date: Wed, 4 Jun 2025 14:55:40 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 3/4] xen/console: remove max_init_domid dependency
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org,
 dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250530231841.73386-1-dmukhin@ford.com>
 <20250530231841.73386-4-dmukhin@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: <20250530231841.73386-4-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 31.05.2025 01:19, dmkhn@proton.me wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -2461,6 +2461,39 @@ void domid_free(domid_t domid)
>      spin_unlock(&domid_lock);
>  }
>  
> +/*
> + * Find the ID of the next possible console owner domain.
> + *
> + * @return Domain ID: DOMID_XEN or non-system domain IDs within
> + * the range of [0..DOMID_FIRST_RESERVED-1].
> + */
> +domid_t domid_find_with_input_allowed(domid_t hint)
> +{
> +    domid_t domid = DOMID_XEN;
> +
> +    if ( hint < DOMID_FIRST_RESERVED )
> +    {
> +        struct domain *d;
> +
> +        rcu_read_lock(&domlist_read_lock);
> +
> +        for ( d = domid_to_domain(hint);

If the domain with ID "hint" went away, what is being switched to changes
compared to behavior prior to this patch, if I'm not mistaken. While this
_may_ be acceptable, not saying so in the description is imo a no-go.

> +              d && get_domain(d) && d->domain_id < DOMID_FIRST_RESERVED;

What's the DOMID_FIRST_RESERVED check for? And where's the put_domain()
for the get_domain() here?

> +              d = rcu_dereference(d->next_in_list) )
> +        {
> +            if ( d->console.input_allowed )
> +            {
> +                domid = d->domain_id;
> +                break;
> +            }
> +        }
> +
> +        rcu_read_unlock(&domlist_read_lock);
> +    }
> +
> +    return domid;
> +}

My concern remains: With many domains, the loop here may take quite a few
iterations. That's even more concerning because it regresses right away in
environments where along with boot-time created domains (eligible for
console focus) later further domains are created (non of which are eligible
for console focus). That is, the step from last boot-time created back to
DOMID_XEN may now take excessively long.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 13:03:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 13:03:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005539.1384991 (Exim 4.92)
	(envelope-from )
	id 1uMnlj-0005Uv-JN; Wed, 04 Jun 2025 13:02:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005539.1384991; Wed, 04 Jun 2025 13:02: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 1uMnlj-0005Uo-Fc; Wed, 04 Jun 2025 13:02:59 +0000
Received: by outflank-mailman (input) for mailman id 1005539;
 Wed, 04 Jun 2025 13:02: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 1uMnli-0005Ui-0f
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 13:02:58 +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 3bf3507d-4144-11f0-a300-13f23c93f187;
 Wed, 04 Jun 2025 15:02:56 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-450ce671a08so43956845e9.3
 for ; Wed, 04 Jun 2025 06:02:56 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a4f00a02cdsm21890755f8f.94.2025.06.04.06.02.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 04 Jun 2025 06:02:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3bf3507d-4144-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749042176; x=1749646976; 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=W+k2cOatHut62eiVD86m0J41TDAOoAGZL4LtoHPLDVI=;
        b=Th2z/cC+344Bfgo/HWcL7PaB8cNNzDS9PO9Qj1PYih18meuX2Oulfdo7F7ZGo+hnSW
         091qelnZsUXsbQDVmQC9kq8HCtNkFBKSQj/vQf0Y0v4LsftckUDhZfw2OYM0ldGP1aEw
         mEOL8u9MQLWdG6nZFfDtv9zZXbJZidMX2kVqA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749042176; x=1749646976;
        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=W+k2cOatHut62eiVD86m0J41TDAOoAGZL4LtoHPLDVI=;
        b=FWSRqyF/qeuSGcu4h/J0psEoTMgmLu6oAEKr2ZFklTJ1CP5gRVKMUy/0xvKpFeMGUR
         aq0JBZ+4SailAoepy39hbN9T2sent8noeRKzoDjHRtLDUKB7CxVG72FezVq6ZLmWmJ9e
         jbjjWbL+/jzdBAFE8x1myIyBYl6OMpqMB+PVxw55Cn46Eu0V3PI4NKPBI7xwCkz8Y3rX
         DYF8FgDUcE2aoTNOxzlpCeqGy9dwDWsXj8v4PxOqe6/ifhlc5I5e38CNc/UXyJ9xrfMU
         /4826MLrdH3wYj6YbjZDR9n1evpiDb5JdqyO2rfkGV/sHjIFZ3K4brY7i/mLdVwwUDF3
         yv3w==
X-Gm-Message-State: AOJu0YylqJrfslILYme2N3wZPtZ/+sxdyliHP05lWKwar66QeMaLTUHU
	IzXSe0YRZ1CactQW5KNRccMpXVJdKb6XPoir87dE5EmUdhl7otWPPW40cMZtXeFgFv1DSFALvi6
	vEXB1
X-Gm-Gg: ASbGncuX3obt7c6tIVBUMDzabOLAwKz0xtVMp8F4pFux4G+F5cS+bDVzDuCd0OgClJq
	uQWpf5un8EqXowD7rnyk+ztgrMWlcJzGvYVFhWDbfxVpbqYwsWfxxAJezV+e7c5gHTHDV84gxn8
	Hs/1qQPOPHzpqSjA9nw51C8cAEZtNIhAzui9o1034unhKXLPBeR85m39uEqh6qViSQHDE3G/p44
	Ydfbm99eS4kdidn68e//knBAIiuX8ukMELVCyVx7pKB0eHsygMWtVLTZrDlJNr3YvYngC+7Stoh
	zYBummn2QQarAKZCFvwFm1LrD83xODc9Uhg6xCLieBcIKZ3j6aq66zRS7wqYmTeTlh2xamU48F9
	tQzfddWRBpaldkHX+5orv4h93
X-Google-Smtp-Source: AGHT+IGxqKWgRu7Fty1BsVpcQl50CvKjUPbJmvS6U8jQOQI5ofW1ncRC47tjBdkrHdEe8gbrIVD7OA==
X-Received: by 2002:a05:600c:3151:b0:450:d586:25ad with SMTP id 5b1f17b1804b1-451f0a9a4b2mr23571995e9.15.1749042175862;
        Wed, 04 Jun 2025 06:02:55 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Aidan Allen ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH] x86/hvm: Process pending softirqs while dumping VMC[SB]s
Date: Wed,  4 Jun 2025 14:02:53 +0100
Message-Id: <20250604130253.2805053-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

24 guests with 8 vcpus each is sufficient to hit a 5 second watchdog.

Drop a piece of trailing whitespace while here.

Reported-by: Aidan Allen 
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Aidan Allen 
---
 xen/arch/x86/hvm/svm/vmcb.c | 4 ++++
 xen/arch/x86/hvm/vmx/vmcs.c | 4 +++-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c
index 4e1f61dbe038..839d3ff91b5a 100644
--- a/xen/arch/x86/hvm/svm/vmcb.c
+++ b/xen/arch/x86/hvm/svm/vmcb.c
@@ -12,6 +12,8 @@
 #include 
 #include 
 #include 
+#include 
+
 #include 
 #include 
 #include 
@@ -246,6 +248,8 @@ static void cf_check vmcb_dump(unsigned char ch)
             }
             printk("\tVCPU %d\n", v->vcpu_id);
             svm_vmcb_dump("key_handler", v->arch.hvm.svm.vmcb);
+
+            process_pending_softirqs();
         }
     }
 
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 57d49364db56..57bae6679dd5 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -2165,7 +2165,7 @@ static void cf_check vmcs_dump(unsigned char ch)
 {
     struct domain *d;
     struct vcpu *v;
-    
+
     printk("*********** VMCS Areas **************\n");
 
     rcu_read_lock(&domlist_read_lock);
@@ -2184,6 +2184,8 @@ static void cf_check vmcs_dump(unsigned char ch)
             }
             printk("\tVCPU %d\n", v->vcpu_id);
             vmcs_dump_vcpu(v);
+
+            process_pending_softirqs();
         }
     }
 

base-commit: eb57fe072232c9836d085020450ce1434b21a819
prerequisite-patch-id: 32a8746877e6b92075be2f022dca25c6bfa6f31e
prerequisite-patch-id: a048b84683314d3a731d79fb3cb11406afa29d7b
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Wed Jun 04 13:15:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 13:15:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005547.1385001 (Exim 4.92)
	(envelope-from )
	id 1uMny4-0007Nz-K7; Wed, 04 Jun 2025 13:15:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005547.1385001; Wed, 04 Jun 2025 13:15:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMny4-0007Ns-Gk; Wed, 04 Jun 2025 13:15:44 +0000
Received: by outflank-mailman (input) for mailman id 1005547;
 Wed, 04 Jun 2025 13:15: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 1uMny2-0007Nm-Hd
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 13:15:42 +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 03188d55-4146-11f0-b894-0df219b8e170;
 Wed, 04 Jun 2025 15:15:40 +0200 (CEST)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3a5123c1533so1407946f8f.2
 for ; Wed, 04 Jun 2025 06:15:40 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a4efe5b8f0sm21462296f8f.6.2025.06.04.06.15.39
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 04 Jun 2025 06:15:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 03188d55-4146-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749042940; x=1749647740; 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=dE60K0Jg5UXM6f6JnTQ2Tr/PstGbb+8CXQfQV1ZFOHo=;
        b=ONYirIvmqUZrzq7ra7e2CiA28yf4dWXF5F8sbWsdYNJycHuxunsRTUDZZRyq7lM+Df
         7d40Iga+GpE5PK7l7SKatYMbi/ub4f1vJ2P1JJ51VB17Jx1cFDFBug9g0qfOlw5z2oYN
         nl1SjMk9sgS1TlUr0wbUTm0sEyUInBBWi4JzY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749042940; x=1749647740;
        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=dE60K0Jg5UXM6f6JnTQ2Tr/PstGbb+8CXQfQV1ZFOHo=;
        b=RIv9FC9MyG7bKAUd1hJGBfZPZk9yui//qW98B39SnCyqdG2y0aFN+BQbPiQqI4CJXc
         +3yXivbmMSAOZcGKIATGa0+Hi2bgOo3zkfMwUII89yAtSuLYlWQTxA1/Ujaijk7aGqNK
         D0wUBw5uARDy6ukFXE8pGPw4oMuD1ycsOppgeiM74gqaNIExs1NAnzpMpl0dHlYusi8O
         MNrIZLSauBBLZuuqai2UNJz61ezoL5FaZEwpbptlwEgYNbIQ1U6+iIHJ246dvE592I4b
         td9+Wy33iKv/XFRIikN+QEmr5j/oVDAnH0qSDY64FAuaCYOvc4XOhxeM8Pcep6wzIIRH
         iVDw==
X-Gm-Message-State: AOJu0YzoQ2jegUMts+690YYmZrC9EE0c1oTSO0FDleWwjohgNgqod9Gs
	O1uY8hvaf/veRnIVXQAjp9HWmvUZOX43y47ch1O4zntzdcWJj7zxf2I9dVt98hB5eT4=
X-Gm-Gg: ASbGncskkBuupcFadzy1+4Qg2EmlV2c2VdhxnZ8bfUt5hxDGeW1x9sDLUcBPdOQBzaf
	TCNffPy3aI+s+uPKkDKueWYZqCP3S10yEc1mtuf4bkvnGlmEgIiKh+ToO3SOjKyGHS++FOGwq17
	sTn70ouftSG2jh2QtFtidkLYGOnWrzQgmaDkRzxub2bZgg1XTvUcthF/W90xu5GkATaVSPjs7jU
	sSujdV/7t28nVOcw0jpPeJInQX501nC95dOrwjdMaJgRF3tuDgTujjH6mkeUJ343hIGtSrTB6dx
	IwB1YOYxxXAIfvTXwSJJ6Ay/BrYOS1oIxIMkkAqpUYflDurJOFbZc/Oh/pMNIwM0Hj9+DwDCpgO
	at3BsefU2/F3EQ1z/s8pwvx5a
X-Google-Smtp-Source: AGHT+IEznKm/nzynKwvMDtBIyUza3TBGYRFkzHVycvjYrPqiRsH9MEfpwQaNcoSdl15hQ+8jtIr7OA==
X-Received: by 2002:a05:6000:2388:b0:3a4:f7af:b41 with SMTP id ffacd0b85a97d-3a51d91d9abmr2553077f8f.15.1749042939930;
        Wed, 04 Jun 2025 06:15:39 -0700 (PDT)
Date: Wed, 4 Jun 2025 15:15:38 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Andrew Cooper 
Cc: Xen-devel ,
	Aidan Allen ,
	Jan Beulich 
Subject: Re: [PATCH] x86/hvm: Process pending softirqs while dumping VMC[SB]s
Message-ID: 
References: <20250604130253.2805053-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: <20250604130253.2805053-1-andrew.cooper3@citrix.com>

On Wed, Jun 04, 2025 at 02:02:53PM +0100, Andrew Cooper wrote:
> 24 guests with 8 vcpus each is sufficient to hit a 5 second watchdog.
> 
> Drop a piece of trailing whitespace while here.
> 
> Reported-by: Aidan Allen 
> Signed-off-by: Andrew Cooper 

Acked-by: Roger Pau Monné 

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 13:42:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 13:42:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005562.1385010 (Exim 4.92)
	(envelope-from )
	id 1uMoNu-00036l-JF; Wed, 04 Jun 2025 13:42:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005562.1385010; Wed, 04 Jun 2025 13:42:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMoNu-00036e-Gf; Wed, 04 Jun 2025 13:42:26 +0000
Received: by outflank-mailman (input) for mailman id 1005562;
 Wed, 04 Jun 2025 13: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 1uMoNt-00036Y-Fl
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 13:42:25 +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 bf0ee6cf-4149-11f0-a300-13f23c93f187;
 Wed, 04 Jun 2025 15:42:24 +0200 (CEST)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-451dbe494d6so36365775e9.1
 for ; Wed, 04 Jun 2025 06:42:24 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-451e505d40csm48115035e9.0.2025.06.04.06.42.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 04 Jun 2025 06:42:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bf0ee6cf-4149-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749044544; x=1749649344; 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=PF00C3kY/+mRujOxew52RXLgbaZA6/tfQkWDEf1jLfk=;
        b=G/eCLH/WPynDT7vyJpCvycIkP9rz4zpb4MpmEwpmdxvzSogFnfcRJwLy+9/+Yt3FQW
         pI/GXz1ENci9yDG/kdoTDWny6zevAHd5hQpF0/TkjXnfvoLwHMnXWzOX05uNxh/VFDi3
         1yLsna2m8IO0hbgrKZ1SYuy8dN55laVqNtdfzEGtjYNcGHBS/nzaPq814f+xdFT5rx1y
         16g2rwFRd7dBYwvGbt/NtA0G0cN27CvFZxWWm12QJ9nY7HguzhGyo24lrgXe4MmvHFEi
         rgw+IEUctCiQ7fsGUfnVlwiHkPAH1x3WK0NYp62bFALrH3yDoZgNpUrICT1MpdpwhVtf
         XVMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749044544; x=1749649344;
        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=PF00C3kY/+mRujOxew52RXLgbaZA6/tfQkWDEf1jLfk=;
        b=INaIbp09NcSVZ/MqOF/rskI/QtwfkHOsKyxQz6Q9PdhYd964vdxyDjcuzonOpt9Z1E
         H+Rv4nVri96+RQ0X0mlTpowKIMbaYxnsTb8XU8guYuxlfFJNMNRzGKtpQkEHL9BHe7Jp
         L0DRHSZRwL+i8K3ERTkRrNkxan6IY3EXCxdp4wCKjWFhEKaW6osGlQerkr4khcnLCzlX
         7oPqqXaL7R2k+hyI5DIQ5DwKQIdNckvwW7cOlyo9VtzHs6ck/Fi1fEa8RnENvOnM5V+P
         7O8TjRaYUmFx9LIN3Yd5z2Mg3NAw7WC4BFW2FQMO0d2s6a2zhelFeZE0JTwD1/ifc43m
         uC/Q==
X-Forwarded-Encrypted: i=1; AJvYcCUIdl/2nOrIZwzdTpKpngjO5PPJYrPuGmLAjLBnO4a2fDiBRgW1ecsZuev85+w6tPmRY/PxBMLdhLk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxmZrVX7vlbeHcNDiF9jsMBnQzKw5fXz+ju2rua/nvjupyFz1yt
	K0zXq7G9pqC1mc0/XEKzoI6qOmwuwQa0QVdx4dUYCLsN9KJZsJSWwf4n
X-Gm-Gg: ASbGncudgOmowemzDnX+yi9XwwM7aXiEu7Q/eqV5Dfa5TYQA3DNtWgVs0L9WI7Rmar5
	Dnu+oq4kdN8VWLwHizBzOkwAbMf4G7+idXWaGR4ZFaldxoyOU3TwFlD5PYdC8HKk/Ni7Yw/5s1Y
	u+bgxq58hV86yu/9wX1oxJmYddNSyiKbr02COyxJPMvLzSu1uOD8VrJU3DjfpNQ3/J7EMtV2dvi
	mXtYNr7t3Ge1IVIOjIYVmWZgF0wZRjd0cqyMflXt8pFAdOpApDit4XgGqoA7SmXdncg2AOwSNfJ
	6AQG2K81ZhAmJzvnBOhtjoJb4uZcwwGWQ1xbbeSzczWw4C3ZNPxdJFyscAa6Yy28W8wUMMiCAY+
	nZhXC/uc5HuCfZ233vqd1jGkn
X-Google-Smtp-Source: AGHT+IEN9mJdEqFGYwbNLgvBdx6zyqxxwExmwYHzZgQy9vDh1al1HP4mXTi03WpEPZpCjJJT3vPzAw==
X-Received: by 2002:a05:600c:a015:b0:450:d37c:9fc8 with SMTP id 5b1f17b1804b1-451f0a74191mr27040095e9.13.1749044543371;
        Wed, 04 Jun 2025 06:42:23 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------jLUq03l8pT5mI1PrASgE0rXy"
Message-ID: 
Date: Wed, 4 Jun 2025 15:42:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 08/14] xen/riscv: imsic_init() implementation
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 ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <421dad1bbd014a2d7ff588af088eadbd56345dbe.1747843009.git.oleksii.kurochko@gmail.com>
 
 
 <84c9f65a-b278-4be4-b053-5bfa410f9a97@gmail.com>
 <9ab65452-497c-47b5-af18-92a7b2a86d9e@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <9ab65452-497c-47b5-af18-92a7b2a86d9e@suse.com>

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


On 6/2/25 12:22 PM, Jan Beulich wrote:
> On 27.05.2025 13:30, Oleksii Kurochko wrote:
>> On 5/26/25 8:44 PM, Oleksii Kurochko wrote:
>>>>> +    if ( !dt_property_read_u32(node, "riscv,guest-index-bits",
>>>>> +                               &imsic_cfg.guest_index_bits) )
>>>>> +        imsic_cfg.guest_index_bits = 0;
>>>>> +    tmp = BITS_PER_LONG - IMSIC_MMIO_PAGE_SHIFT;
>>>>> +    if ( tmp < imsic_cfg.guest_index_bits )
>>>>> +    {
>>>>> +        printk(XENLOG_ERR "%s: guest index bits too big\n",
>>>>> +               dt_node_name(node));
>>>>> +        rc = -ENOENT;
>>>>> +        goto cleanup;
>>>>> +    }
>>>>> +
>>>>> +    /* Find number of HART index bits */
>>>>> +    if ( !dt_property_read_u32(node, "riscv,hart-index-bits",
>>>>> +                               &imsic_cfg.hart_index_bits) )
>>>>> +    {
>>>>> +        /* Assume default value */
>>>>> +        imsic_cfg.hart_index_bits = fls(*nr_parent_irqs);
>>>>> +        if ( BIT(imsic_cfg.hart_index_bits, UL) < *nr_parent_irqs )
>>>>> +            imsic_cfg.hart_index_bits++;
>>>> Since fls() returns a 1-based bit number, isn't it rather that in the
>>>> exact-power-of-2 case you'd need to subtract 1?
>>> Agree, in this case, -1 should be taken into account.
>> Hmm, it seems like in case of fls() returns a 1-based bit number there
>> is not need for the check:
>>    (2) if ( BIT(imsic_cfg.hart_index_bits, UL) < *nr_parent_irqs )
>>
>> We could do imsic_cfg.hart_index_bits = fls(*nr_parent_irqs - 1) (1) without
>> checking *nr_parent_irqs is power-of-two or not, and then just leave the
>> check (2).
>> And with (1), the check (2) is only needed for the case *nr_parent_irqs=1, if
>> I amn't mistaken something. And if I'm not mistaken, then probably it make
>> sense to change (2) to if ( *nr_parent_irqs == 1 ) + some comment why this
>> case is so special.
>>
>> Does it make sense?
> Can't easily tell; I'd like to see the resulting code instead of the textual
> description.

Here is the code:
     /* Find number of HART index bits */
     if ( !dt_property_read_u32(node, "riscv,hart-index-bits",
                                &imsic_cfg.hart_index_bits) )
     {
         /* Assume default value */
         imsic_cfg.hart_index_bits = fls(*nr_parent_irqs - 1) +
                                     (*nr_parent_irqs == 1);
     }

It seems like it covers all the cases.

~ Oleksii

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



  
    
  
  
    

    
    
    
    
    On 6/2/25 12:22 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 27.05.2025 13:30, Oleksii Kurochko wrote:

    
      
    
        
    On 5/26/25 8:44 PM, Oleksii Kurochko wrote:

    
        
    
          
    
            
    
              
    +    if ( !dt_property_read_u32(node, "riscv,guest-index-bits",
+                               &imsic_cfg.guest_index_bits) )
+        imsic_cfg.guest_index_bits = 0;
+    tmp = BITS_PER_LONG - IMSIC_MMIO_PAGE_SHIFT;
+    if ( tmp < imsic_cfg.guest_index_bits )
+    {
+        printk(XENLOG_ERR "%s: guest index bits too big\n",
+               dt_node_name(node));
+        rc = -ENOENT;
+        goto cleanup;
+    }
+
+    /* Find number of HART index bits */
+    if ( !dt_property_read_u32(node, "riscv,hart-index-bits",
+                               &imsic_cfg.hart_index_bits) )
+    {
+        /* Assume default value */
+        imsic_cfg.hart_index_bits = fls(*nr_parent_irqs);
+        if ( BIT(imsic_cfg.hart_index_bits, UL) < *nr_parent_irqs )
+            imsic_cfg.hart_index_bits++;

    
            
    
            
    Since fls() returns a 1-based bit number, isn't it rather that in the
exact-power-of-2 case you'd need to subtract 1?

    
          
    
          
    Agree, in this case, -1 should be taken into account.

    
        
    
        
    Hmm, it seems like in case of fls() returns a 1-based bit number there
is not need for the check:
  (2) if ( BIT(imsic_cfg.hart_index_bits, UL) < *nr_parent_irqs )

We could do imsic_cfg.hart_index_bits = fls(*nr_parent_irqs - 1) (1) without
checking *nr_parent_irqs is power-of-two or not, and then just leave the
check (2).
And with (1), the check (2) is only needed for the case *nr_parent_irqs=1, if
I amn't mistaken something. And if I'm not mistaken, then probably it make
sense to change (2) to if ( *nr_parent_irqs == 1 ) + some comment why this
case is so special.

Does it make sense?

    
      
    
      
    Can't easily tell; I'd like to see the resulting code instead of the textual
description.
    
    
    
    
    Here is the code:
    /* Find number of HART index bits */
    if ( !dt_property_read_u32(node, "riscv,hart-index-bits",
                               &imsic_cfg.hart_index_bits) )
    {
        /* Assume default value */
        imsic_cfg.hart_index_bits = fls(*nr_parent_irqs - 1) +
                                    (*nr_parent_irqs == 1);
    }

It seems like it covers all the cases.

~ Oleksii
    
  


--------------jLUq03l8pT5mI1PrASgE0rXy--


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 14:22:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 14:22:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005599.1385021 (Exim 4.92)
	(envelope-from )
	id 1uMp0b-0008K5-Jo; Wed, 04 Jun 2025 14:22:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005599.1385021; Wed, 04 Jun 2025 14: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 1uMp0b-0008Jy-H5; Wed, 04 Jun 2025 14:22:25 +0000
Received: by outflank-mailman (input) for mailman id 1005599;
 Wed, 04 Jun 2025 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 1uMp0a-0008Jr-Ah
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 14:22:24 +0000
Received: from fhigh-a7-smtp.messagingengine.com
 (fhigh-a7-smtp.messagingengine.com [103.168.172.158])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 539447fa-414f-11f0-b894-0df219b8e170;
 Wed, 04 Jun 2025 16:22:21 +0200 (CEST)
Received: from phl-compute-06.internal (phl-compute-06.phl.internal
 [10.202.2.46])
 by mailfhigh.phl.internal (Postfix) with ESMTP id 417A21140237;
 Wed,  4 Jun 2025 10:22:20 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-06.internal (MEProxy); Wed, 04 Jun 2025 10:22:20 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 4 Jun 2025 10:22:18 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 539447fa-414f-11f0-b894-0df219b8e170
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=1749046940;
	 x=1749133340; bh=l9qTL6VyDfkoyc94nfz6CdcDFNs7QiHmBUzDCEMHvgE=; b=
	Q4ErSjeW4VOznKj0N+l3iczNlcBj+NXKv2ttSNWavCZIq8sDZ9aSXq6qnKzCuMsG
	K5In3r//KTUnq7X3M4aNES5WcC+p1RdR16RNz8VHhbvFYGcxnnODJGsc6p/D7OCs
	cky8j3l8OKDIkYrT4eiKkaYXYRWgm5/wOCGEYGA93nmrED45BFUKl+TeZIvmUHDx
	4r22XvBct4APiCGsoXjbFtSN+xZfCOz5tnKcN0m6gR1NvPlilC1MqyXdYE9Uqp+4
	ZfWkw0JiMdovs2aE4Mn3pQ3xKcQR8J63AhorWedPjEsZ/ZnX9qQMCOemxn1VyoUZ
	UrOQ9TirfiFKwq0Z/x/elg==
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=
	1749046940; x=1749133340; bh=l9qTL6VyDfkoyc94nfz6CdcDFNs7QiHmBUz
	DCEMHvgE=; b=D0j+LQ7cOJA1nQG4pbbCqsU+8T60bcyhWBSItXL5xkQ2AScoRup
	D6g4gDmau1B431JqpfNxV3xt57U4JDhFpjfZ+nhowCNxV4g4f/rJ+htSU9nXGg3o
	74J+lhyCe1zhavHk5HjkbV2NtYsXrLddg1LY6oYfM0d5FzrpEgbNxLawWBpNF7B9
	J2asq5O3u4rMDl4ayVWbUvR1Or1mSbYOuDfy403SsoLyDEwcaPtx3oUM/bWPZdeF
	u+Glkou7WcVwQHq6SKjdRXVkE7ZXYEkq8mBzvqvbs6VEMAd94p393OhV+ckBkhne
	fVinQQncbTo5iuwokYLteKc5APqImwNbZzg==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugddvvdeiucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtroertddtjeen
    ucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomh
    grrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggft
    rfgrthhtvghrnheptdetvdfhkedutedvleffgeeutdektefhtefhfffhfeetgefhieegle
    dvtddtkedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho
    mhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnh
    gspghrtghpthhtohepledpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtoheprhhoghgv
    rhdrphgruhestghithhrihigrdgtohhmpdhrtghpthhtohepjhhgrhhoshhssehsuhhsvg
    drtghomhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhj
    vggtthdrohhrghdprhgtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvg
    hrnhgvlhdrohhrghdprhgtphhtthhopehjrghsohhnrdgrnhgurhihuhhksegrmhgurdgt
    ohhmpdhrtghpthhtohepjhifsehnuhgtlhgvrghrfhgrlhhlohhuthdrnhgvthdprhgtph
    htthhopehsshhtrggsvghllhhinhhisehkvghrnhgvlhdrohhrghdprhgtphhtthhopeho
    lhgvkhhsrghnughrpghthihshhgthhgvnhhkohesvghprghmrdgtohhmpdhrtghpthhtoh
    epshhtrggslhgvsehvghgvrhdrkhgvrhhnvghlrdhorhhg
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Wed, 4 Jun 2025 16:22:16 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Roger Pau Monne 
Cc: Juergen Gross , xen-devel@lists.xenproject.org,
	linux-kernel@vger.kernel.org, jason.andryuk@amd.com,
	John ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	stable@vger.kernel.org
Subject: Re: [PATCH] xen/x86: fix initial memory balloon target
Message-ID: 
References: <20250514080427.28129-1-roger.pau@citrix.com>
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="rjdcZPeLS3c+Qw6Y"
Content-Disposition: inline
In-Reply-To: 


--rjdcZPeLS3c+Qw6Y
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Wed, 4 Jun 2025 16:22:16 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Roger Pau Monne 
Cc: Juergen Gross , xen-devel@lists.xenproject.org,
	linux-kernel@vger.kernel.org, jason.andryuk@amd.com,
	John ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	stable@vger.kernel.org
Subject: Re: [PATCH] xen/x86: fix initial memory balloon target

On Thu, May 15, 2025 at 11:01:24AM +0200, Marek Marczykowski-G=C3=B3recki w=
rote:
> On Wed, May 14, 2025 at 10:04:26AM +0200, Roger Pau Monne wrote:
> > When adding extra memory regions as ballooned pages also adjust the bal=
loon
> > target, otherwise when the balloon driver is started it will populate
> > memory to match the target value and consume all the extra memory regio=
ns
> > added.
> >=20
> > This made the usage of the Xen `dom0_mem=3D,max:` command line paramete=
r for
> > dom0 not work as expected, as the target won't be adjusted and when the
> > balloon is started it will populate memory straight to the 'max:' value.
> > It would equally affect domUs that have memory !=3D maxmem.
> >=20
> > Kernels built with CONFIG_XEN_UNPOPULATED_ALLOC are not affected, becau=
se
> > the extra memory regions are consumed by the unpopulated allocation dri=
ver,
> > and then balloon_add_regions() becomes a no-op.
> >=20
> > Reported-by: John 
> > Fixes: 87af633689ce ('x86/xen: fix balloon target initialization for PV=
H dom0')
> > Signed-off-by: Roger Pau Monn=C3=A9 
>=20
> Tested-by: Marek Marczykowski-G=C3=B3recki 

I think this wants Cc: stable, since the commit named in Fixes: got
backported too. Or is the Fixes tag enough?

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

--rjdcZPeLS3c+Qw6Y
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmhAVpgACgkQ24/THMrX
1yxTXAf/f2m+HJfB41dbfKE54f3JNUqW0V87ci8kZTbhmd1/JxZFU+o1phpKn9Dd
PW4Dd2qzBqcu7h+rlG6C3q9Y6ugtR17qU3eTWA3OCNmBgwK34ga3oJ6bJ5Fbvkyv
//B71ZXIXTv3KxjQgRUH6v3n1WNNqLjkFQBtHqjlC/1K8NCierXgiQK25ysueo/K
yybT8woevQgoZm1E6VINtDYo6c8sbtGE+RorVX8Q4DeSn3AutWRG/AFL/yw1RF7U
QAgZq297ZSLAyHFVtNiGoWY5zELHTVb9EW/ajvPE0jPnuOjEgGw+Mwg2SnAmHejb
rgokQ7UTD84BW7b58MHEMK0W190lRA==
=Birs
-----END PGP SIGNATURE-----

--rjdcZPeLS3c+Qw6Y--


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 15:03:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 15:03:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005626.1385030 (Exim 4.92)
	(envelope-from )
	id 1uMpdx-0004nh-JX; Wed, 04 Jun 2025 15:03:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005626.1385030; Wed, 04 Jun 2025 15: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 1uMpdx-0004na-Gj; Wed, 04 Jun 2025 15:03:05 +0000
Received: by outflank-mailman (input) for mailman id 1005626;
 Wed, 04 Jun 2025 15:03: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 1uMpdw-0004nU-6L
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 15:03:04 +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 034eb98e-4155-11f0-a300-13f23c93f187;
 Wed, 04 Jun 2025 17:03:03 +0200 (CEST)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3a375888297so751084f8f.1
 for ; Wed, 04 Jun 2025 08:03:03 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-450d7f8f1e7sm203568925e9.1.2025.06.04.08.03.01
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 04 Jun 2025 08:03:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 034eb98e-4155-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749049383; x=1749654183; 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=0mgaArX06BoKL6s7D0jsLiXeLtQCXCOHLwG4c5t2ENg=;
        b=RnwkeUu96J8ZcNoB6HdZVuljB94mCN85b3C4KnxAzVslOxTauqTBHwZtbpwz/q2+zt
         zKDd4XPPNOOTkJw+MBEUbLHMf1gukcLL84xAvQEjIpDGeWt5JCU+ivYu3vDlZSHYXM99
         aHdupp7dzbQYwMgz+VtgFvtTRxZAX/r8cFCcs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749049383; x=1749654183;
        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=0mgaArX06BoKL6s7D0jsLiXeLtQCXCOHLwG4c5t2ENg=;
        b=Zfr24dSR+KTWtkoyn9IsE01Ye8Y4kPhUIR3hqoJLWJ0ZU0nMHZRENKajo98aBZIxAG
         hxdXqgw7Y7t9li2ndccih3rUA1Vvmrci8mAxoggT8iDITNSj5Jwk85WG5mYFHbyEMsHF
         GGMmPkf93FG/Z81YQYf0s8pf8pZj9F/MItKXJVeen+jUJf5Q+y9Z7csozHiO0LsXSIYf
         KMR+4QUuC97ByTO0DmzEWzeKPkKvRS2p4lzhhglXIkO5F3WKdJ/w/2MHlPUA8vJD4xG4
         AIesIayAJ+gjC2tzr5TjCftWjiowdZ7mdbE7pA6EJN2k5YrxMLbgrdsiPnw+zf3vwmOz
         ofGA==
X-Forwarded-Encrypted: i=1; AJvYcCXAjbwsGPKyKRr9TciR4NeMiR0lHTwTTpzX2hnDhIcfOTinTT7dUOkOzgbBWw2SYUBn7O8ou5q324o=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywodec6RWOE6dwu4TUpWfZ4wg8QFsMH1OXu/sQGdVIWM/MmoZcx
	RmimKAgfedalNFHsbwjr1HJHccEaKD2lH3efe+YuyYaUFMc5HxA9oxuOZSGaqfK0g4M=
X-Gm-Gg: ASbGnct9mupz5JnA3DkizfqfOtNcS9cHghMxcuDOFAPQcz4gE9fNQv+QWSx07FdDiEk
	8HpMT+kEnhoB534fRTEsTFykep0L2lEyFcDXxdtcs+gv+qfQjjjEDZEtpTU6wCIhpaRHeFUvl2R
	ZYj7C/vSPcqF/mJHeu5Lk8N8zkCO8+pykNLL69oepNZ+8uZDeMEaShH6+c5macNEQBfjL/AkIp3
	+q2JYzsbhLd3IfPy/2/z1DmPpbn6vtTiGmShU45i0urhhIKNZY0ObWnlA9Bm+3usJWbqtQL/ktX
	p39vDzlqHvugH7Yv0+4fobI8VG3ONsQzYMN+ZcA79cbLjszCDlPqpOZhN6CwRzsaMEDjW2N+MFC
	coawPcKUBou2kImuxP2Q=
X-Google-Smtp-Source: AGHT+IHiJjB0kJuY7q6ie9oSM6rLZ2lrNKWeiotz3Y1wEEbeSFBBk0RSbNnmot7MSXg/0azUFaxnVg==
X-Received: by 2002:a05:6000:250d:b0:3a4:da0e:517a with SMTP id ffacd0b85a97d-3a5141a819amr6829958f8f.23.1749049382197;
        Wed, 04 Jun 2025 08:03:02 -0700 (PDT)
Date: Wed, 4 Jun 2025 17:03:00 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 2/2] x86/numa: introduce per-NUMA node flush locks
Message-ID: 
References: <20250522084815.825-1-roger.pau@citrix.com>
 <20250522084815.825-3-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 Wed, Jun 04, 2025 at 02:35:01PM +0200, Jan Beulich wrote:
> On 22.05.2025 10:48, Roger Pau Monne wrote:
> > Contention around the global flush_lock increases as the amount of physical
> > CPUs on the host also increases.  Sadly this doesn't scale on big boxes.
> > However most of the time Xen doesn't require broadcasting flushes to all
> > CPUs on the system, and hence more fine grained (ie: covering less CPUs)
> > locks could be used.
> > 
> > A natural boundary to use when splitting the locks are NUMA nodes.  Most
> > domains will be limited to running on a single node, specifically the one
> > where the domain memory has been allocated from.  Flushes related to
> > domains are most likely to be limited to a single NUMA node, and hence
> > being able to execute per-node flushes allows to reduce the contention
> > around the global flush_lock, while also allowing to perform concurrent
> > flushes on different nodes.
> > 
> > This however doesn't come for free.  A new vector must be allocated to be
> > used for the per-NUMA flushes, and more logic is required in the flush
> > dispatcher to figure out whether a flush is limited to a single node.
> > 
> > The figures on a 2-node NUMA system are as follows, after having been
> > running the same XenRT boot storm workload for 90 minutes.
> > 
> > Without the per-NUMA node flush:
> > 
> > Global flush_lock: addr=ffff82d040837340, lockval=d8ded8de, not locked
> >   lock:21878876(98178042228), block:1603338(6043805110)
> > 
> > So a total block time of ~6s, and average block time of 3.7us.
> > 
> > With the per-node locks:
> > 
> > Global flush_lock: addr=ffff82d040837360, lockval=78e678e6, not locked
> >   lock:6781028(41032945811), block:583712(2025657239)
> > NUMA node 1 flush_lock: addr=ffff832fd085b110, lockval=5cd65cd6, not locked
> >   lock:220374(766500536), block:4091(9933129)
> > NUMA node 0 flush_lock: addr=ffff8310336a7110, lockval=5c715c71, not locked
> >   lock:547953(1658170241), block:23856(51266297)
> > 
> > The total block time goes down to ~2s, and the average block time is 3.4us.
> > The total block time of the per-node locks is much lower compared to the
> > global flush_lock, 9ms and 51ms respectively.
> > 
> > Note the example here is possibly the system where such split locks don't
> > make a lot of difference, being a 2 node system, but still there's a
> > non-trivial difference between the block times.  On a 4 or 9 node system
> > the figures should likely be even better.
> > 
> > Signed-off-by: Roger Pau Monné 
> 
> The savings must be from TLB flushes only? Cache flushes, as we have discussed
> recently, need to be global anyway, and hence there are no savings to be had.
> This may want reflecting the subject and/or description.

Yeah, it's only TLB flushes.

> > @@ -126,3 +129,95 @@ int __init arch_get_ram_range(unsigned int idx, paddr_t *start, paddr_t *end)
> >  
> >      return 0;
> >  }
> > +
> > +static struct arch_numa_node {
> > +    const void *flush_va;
> > +    unsigned int flush_flags;
> > +    cpumask_t flush_mask;
> > +    spinlock_t flush_lock;
> > +    struct lock_profile_qhead profile_head;
> > +} *node_info[MAX_NUMNODES];
> 
> __ro_after_init or at least __read_mostly?

__ro_after_init would be OK I think.

> > +static int __init cf_check arch_numa_init(void)
> > +{
> > +    unsigned int i;
> > +
> > +    if ( num_online_nodes() == 1 )
> > +        return 0;
> > +
> > +    for_each_online_node ( i )
> > +    {
> > +        struct arch_numa_node *node =
> > +            alloc_xenheap_pages(get_order_from_bytes(sizeof(*node)),
> > +                                                     MEMF_node(i));
> 
> A full page for what may cover just a cacheline or two? I realize ...
> 
> > +        if ( node )
> > +            clear_page(node);
> > +        else
> > +            node = xvzalloc(typeof(*node));
> 
> ... this (sadly) still has no NUMA-capable counterpart, but I'd have expected
> at least a brief comment to justify.

Oh, yes, it should better have a comment.

> > +void cf_check invalidate_tbl_numa(void)
> 
> Nit: s/tbl/tlb/ ?
> 
> > +bool flush_numa_node(const cpumask_t *mask, const void *va, unsigned int flags)
> > +{
> > +    nodeid_t node = num_online_nodes() > 1 ? cpumask_to_node(mask)
> > +                                           : NUMA_NO_NODE;
> > +    struct arch_numa_node *info;
> > +
> > +    if ( node == NUMA_NO_NODE )
> > +        return false;
> > +
> > +    info = node_info[node];
> > +
> > +    if ( !info )
> > +        return false;
> > +
> > +    spin_lock(&info->flush_lock);
> > +    cpumask_and(&info->flush_mask, mask, &cpu_online_map);
> > +    cpumask_clear_cpu(smp_processor_id(), &info->flush_mask);
> 
> IOW this function is strictly a helper of flush_area_mask(), relying on
> the local CPU to have had its flushing done already. Might it not be
> better if this was put as a static in smp.c then? Or, to keep struct
> arch_numa_node local to this file, split it into two parts?
> 
> > +    info->flush_va = va;
> > +    info->flush_flags = flags;
> > +    send_IPI_mask(&info->flush_mask, INVALIDATE_NUMA_VECTOR);
> 
> This one similarly depends on flush_area_mask() behavior, not calling here
> when mask has solely the local CPU set.
> 
> > --- a/xen/common/numa.c
> > +++ b/xen/common/numa.c
> > @@ -689,6 +689,29 @@ static int __init cf_check numa_setup(const char *opt)
> >  }
> >  custom_param("numa", numa_setup);
> >  
> > +/*
> > + * Return the NUMA node index if all CPUs in the mask belong to the same node,
> > + * otherwise return NUMA_NO_NODE.
> > + */
> > +nodeid_t cpumask_to_node(const cpumask_t *mask)
> > +{
> > +    unsigned int cpu;
> > +    nodeid_t node = NUMA_NO_NODE;
> > +
> > +    if ( num_online_nodes() == 1 )
> > +        return cpu_to_node[0];
> 
> The sole caller checks this already, so strictly speaking Misra would consider
> this dead / unreachable code.
> 
> Similarly Misra may not like this on Arm, where it's unused right now. Then
> again looks like NUMA work there was abandoned, so for now all ought to be
> fine here.

Thanks, given the feedback I think you consider this an improvement
worth pursuing then?

Regards, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 15:03:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 15:03:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005631.1385041 (Exim 4.92)
	(envelope-from )
	id 1uMpef-0005Cb-SY; Wed, 04 Jun 2025 15:03:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005631.1385041; Wed, 04 Jun 2025 15:03: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 1uMpef-0005CU-Pw; Wed, 04 Jun 2025 15:03:49 +0000
Received: by outflank-mailman (input) for mailman id 1005631;
 Wed, 04 Jun 2025 15:03: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 1uMpee-0005CJ-Iw
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 15:03:48 +0000
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com
 [2a00:1450:4864:20::136])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1d10ab10-4155-11f0-b894-0df219b8e170;
 Wed, 04 Jun 2025 17:03:46 +0200 (CEST)
Received: by mail-lf1-x136.google.com with SMTP id
 2adb3069b0e04-5533a86a134so6169391e87.3
 for ; Wed, 04 Jun 2025 08:03:46 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3124e1f3f22sm8986345a91.0.2025.06.04.08.03.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 04 Jun 2025 08:03:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1d10ab10-4155-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749049426; x=1749654226; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=gVaQ2qL6GfyW7UZdFSX7v/cET0aens2AC39Mv1Xz7m0=;
        b=Rv0I8eBJcgR9c0qcq5LFp1/pJQPvxKLhw1H+BcDTV/ZqHJPubH2cYCn85rE9mmZS4n
         6WB6vvntixsx/niJaWCrzdwjKGnkfDdlRWy6mHYVboqD2J+4PsFA4B6Owh4GdvEVKgr/
         Fdu+uyZkb4VN4vWHEXCORhD38c+TmVxAWUXNkGrgeV0uxrVUCXbkK4J7WBlM7jgA9m67
         DrTxY4qoJ+PtRZ47El0eyEJcWbMvxfk/b0+FbFmmjky8SNJf/UgqPSnkeGi44Vijvhat
         3utpo707Q/kdYr7+9GSgZemxsL01Oj+njijKHJnXYCrnURQqEb1SGcRpBajcleMPg6gk
         X60A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749049426; x=1749654226;
        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=gVaQ2qL6GfyW7UZdFSX7v/cET0aens2AC39Mv1Xz7m0=;
        b=Gf5/FABn/uJ2pnJGn/MQ+CxVNptY/eARPOBMcvmE2uov0ES8OyeEP5s48kGhwL4Za6
         aG/VH83LM/ChImApO2g0+/Vlw4DYCxfaUcNONLRuXw7MYy4sbZNJCOmh8MOY+8RqyM8J
         m7epZo0AAzGwRxRDA0rWA9xZHem+yfNGn3M84lKq/wfE+3XGe56cIybB6P6CqG+c4R68
         KorJAJYK/XL0flccdwU0IwPleUFwCBQmbjCISiUwvnpYosC/5kmBvsJp7742uYXWO232
         HuhtzhhQFv8TY8DFBRHkpNXsp0BGV7qVn47E2bYbvRof9O3QWMhk5vfpcgdbIuxkaV5p
         9BNw==
X-Forwarded-Encrypted: i=1; AJvYcCU2XN/z9rJKDETntFdt1FTC5aYQr4tXxjk2+V4zfv1cnKSzQeA8nI1gbf1IucGINZ0LhFs8J7Uar0M=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwhcO+3kPx5d0pT8voX2jb3YJJZQxIDOwiQtD5mQ0qRW4ihSNmH
	KXUCmOuMoa1u8ARofDlmpR9Lo+Y05I94oVBwD15BI3/DgdWuI+mUgNWCRRvM71hMTQ==
X-Gm-Gg: ASbGncu0LyYVL32ykmla0WFMhYIjSu8CJzDsEmf3EtZA5Xartc57JV+e1chUcLKBXx2
	QBhkVYmlkKJuwLznSMaBtFp225XT3nrayJvBjX6hABUZ5N+PIICRySyFf7oFBFIGrJVWjHzmGkb
	uO4ZavU23xA+74z2hAf+EfMRKoYY67Py9d0FqsLyZ3OPoNLCIECVxI6OCRIIkXUBGgGjDwHmtca
	t4/WBz7qdBXiGUjS1L9AqTUeG8JOfLmH+V83G4KX6YCzbPC1vohTeEgiw78IP/z5dx4bOe6DVwC
	79ARy4nnSBH5oCuumfvyqG9fmctzzO7BFhxNi72u8+6BWN1JP6GL4a2BW5ndOyMqXEkpYabDUiV
	Bj7CcJ17vGv4xfihku2xJ6gBekN10VFwHYZ1j
X-Google-Smtp-Source: AGHT+IF0V5fsNqD0VcvFHei3Zn1VYKKInYlV8WQRHPG09f7jxeWIQ1ykZtk6lV1h7ZLzVGd/UbQykw==
X-Received: by 2002:a05:6512:4013:b0:553:399d:58eb with SMTP id 2adb3069b0e04-55356af0680mr1217073e87.24.1749049424887;
        Wed, 04 Jun 2025 08:03:44 -0700 (PDT)
Message-ID: 
Date: Wed, 4 Jun 2025 17:03:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 08/14] xen/riscv: imsic_init() implementation
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 ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <421dad1bbd014a2d7ff588af088eadbd56345dbe.1747843009.git.oleksii.kurochko@gmail.com>
 
 
 <84c9f65a-b278-4be4-b053-5bfa410f9a97@gmail.com>
 <9ab65452-497c-47b5-af18-92a7b2a86d9e@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.06.2025 15:42, Oleksii Kurochko wrote:
> 
> On 6/2/25 12:22 PM, Jan Beulich wrote:
>> On 27.05.2025 13:30, Oleksii Kurochko wrote:
>>> On 5/26/25 8:44 PM, Oleksii Kurochko wrote:
>>>>>> +    if ( !dt_property_read_u32(node, "riscv,guest-index-bits",
>>>>>> +                               &imsic_cfg.guest_index_bits) )
>>>>>> +        imsic_cfg.guest_index_bits = 0;
>>>>>> +    tmp = BITS_PER_LONG - IMSIC_MMIO_PAGE_SHIFT;
>>>>>> +    if ( tmp < imsic_cfg.guest_index_bits )
>>>>>> +    {
>>>>>> +        printk(XENLOG_ERR "%s: guest index bits too big\n",
>>>>>> +               dt_node_name(node));
>>>>>> +        rc = -ENOENT;
>>>>>> +        goto cleanup;
>>>>>> +    }
>>>>>> +
>>>>>> +    /* Find number of HART index bits */
>>>>>> +    if ( !dt_property_read_u32(node, "riscv,hart-index-bits",
>>>>>> +                               &imsic_cfg.hart_index_bits) )
>>>>>> +    {
>>>>>> +        /* Assume default value */
>>>>>> +        imsic_cfg.hart_index_bits = fls(*nr_parent_irqs);
>>>>>> +        if ( BIT(imsic_cfg.hart_index_bits, UL) < *nr_parent_irqs )
>>>>>> +            imsic_cfg.hart_index_bits++;
>>>>> Since fls() returns a 1-based bit number, isn't it rather that in the
>>>>> exact-power-of-2 case you'd need to subtract 1?
>>>> Agree, in this case, -1 should be taken into account.
>>> Hmm, it seems like in case of fls() returns a 1-based bit number there
>>> is not need for the check:
>>>    (2) if ( BIT(imsic_cfg.hart_index_bits, UL) < *nr_parent_irqs )
>>>
>>> We could do imsic_cfg.hart_index_bits = fls(*nr_parent_irqs - 1) (1) without
>>> checking *nr_parent_irqs is power-of-two or not, and then just leave the
>>> check (2).
>>> And with (1), the check (2) is only needed for the case *nr_parent_irqs=1, if
>>> I amn't mistaken something. And if I'm not mistaken, then probably it make
>>> sense to change (2) to if ( *nr_parent_irqs == 1 ) + some comment why this
>>> case is so special.
>>>
>>> Does it make sense?
>> Can't easily tell; I'd like to see the resulting code instead of the textual
>> description.
> 
> Here is the code:
>      /* Find number of HART index bits */
>      if ( !dt_property_read_u32(node, "riscv,hart-index-bits",
>                                 &imsic_cfg.hart_index_bits) )
>      {
>          /* Assume default value */
>          imsic_cfg.hart_index_bits = fls(*nr_parent_irqs - 1) +
>                                      (*nr_parent_irqs == 1);
>      }
> 
> It seems like it covers all the cases.

*nr_parent_irqs		imsic_cfg.hart_index_bits
	 1			0
	 2			2 (1 + 1)
	 3			2
	 4			2
	 5			3
	 6			3

IOW why the special casing of *nr_parent_irqs == 1?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 15:05:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 15:05:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005640.1385051 (Exim 4.92)
	(envelope-from )
	id 1uMpgg-0005qf-7s; Wed, 04 Jun 2025 15:05:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005640.1385051; Wed, 04 Jun 2025 15:05: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 1uMpgg-0005qY-4X; Wed, 04 Jun 2025 15:05:54 +0000
Received: by outflank-mailman (input) for mailman id 1005640;
 Wed, 04 Jun 2025 15:05: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 1uMpgf-0005pm-BJ
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 15:05:53 +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 683ed0ec-4155-11f0-a300-13f23c93f187;
 Wed, 04 Jun 2025 17:05:52 +0200 (CEST)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-4508287895dso7429955e9.1
 for ; Wed, 04 Jun 2025 08:05:52 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-747afe963b3sm11268821b3a.34.2025.06.04.08.05.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 04 Jun 2025 08:05:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 683ed0ec-4155-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749049552; x=1749654352; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=sqA7dL44psqc11Le0tudCJdv3a89frzD8q/8A8clZrU=;
        b=CzFDtsSjlsL3XoJnO0lVZR+BGwIcr4x2NLUohIpzdkoB3o8EazQUQkwpbOtMJ0c5vm
         2QGL6CI2tuayBpbcSf2DZJbwsX1+GvzC904mp+134TjWFw5YCCdORbkB6DAbZJNIVb+V
         NKsyYVhuMxPIfTIKKwhnwrtmUg3WxVccIPuSvGWYyh0Klo/Zw8A9n60bl3k9A17Ph4Od
         uNA7G0f5dab9KeY/mlUA8tWwQUfyUxxshZL9/rmAv7O1r2Ae7/iVe7A4a3rcmPHsDFOl
         owl5OKcrbPzfb6NTTKdNvDeqOltLOzOdvjQ7U5cGmah9X18q3jWFhku+Uw0YCPnP+qfH
         YGBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749049552; x=1749654352;
        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=sqA7dL44psqc11Le0tudCJdv3a89frzD8q/8A8clZrU=;
        b=nWs/8AaMC0WT7Gpocj8xby4c136xm3vddbb0cVV4m5AwZJk8oojMVzShEgmzUXzljw
         UPrHaJuHxQfYmDIeN9+ahHDGqPbywgnH2odlt0zYpWGRLrhLXTFii2D8QP9L620QPoTk
         Z6/SEFKCn96EuEFq6BYaMQ19LhHN16xvYMcLGfmH3+69/MS+8SihT2TD6srJHsqMfLHS
         uQl3CSQ8IqVnJBvO5uk54YjoS2aLKLx0nK8scdUmXEkNuyl+4bsz3jQfOAtF8GGNFsdb
         aQ2hrxA/zuW6Ceo+6Q+KPYBPgwqGcGCiN2mwhbQqsgUKRMRCV4gFgE7VygEedXpb1L7q
         2M+g==
X-Forwarded-Encrypted: i=1; AJvYcCW2gc52DElizr5IToJXn2okOcVVXCr9CTfr7V8bq7Z806ljDKBQ7Y7bGruxyD0sgMcndhsJM4O1LSs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxhXlACycw6OUHCsF+fNqHvbQvcYSlq/RBKhusNba/VbQaw8yNQ
	C8cPATjHx8fNqEZXZTk3p991SD4aL0fuPi6H+ebXaAgG5LJXU9DAEvfZ/gW5FUL1rw==
X-Gm-Gg: ASbGncv1b0s7CCSvYdG9vpPCn7fC8FKE3Ca6lkIbxlbNCtfizBo5Xpehf9ofwzjhOJ3
	0c5MWiR0KM5/sg8+1MWnc1aM64IyndY6OStgBhr8kNhTHipSREc9c0mP7ZQWJzotLedVFMhgnhy
	wKIpqNZvqRhcOR9ywqvSbivPJxTfbtgK9eKvT45dN4OEvZCsyOVBpp5GLgyT+2XvBngmRuqFA1a
	mhNHTelLO4grFqgxxHILC3qlMRS/AlRrjt6DDYi/zSDe5p6aVQs0drudB1Uc6EDsT6Z045jET+E
	CrZQP/+a4stes9wiT5t/KGUf/UrOn/KTS2zNgci4ny+H+SpcBxtkDKuD4vOhEExR3vnbqHBlAMx
	81SXhDeYiJbRn8o7nTP8V8Zhk2+giwUz5bVNaL+8zh1VPnZ8=
X-Google-Smtp-Source: AGHT+IEKRVUNPcdIjsD4lH54+md1/CJofdOdf9qOxBOrrx+usMrEpQYwlhyErmeZT2mR011yVXZGzg==
X-Received: by 2002:a05:6000:2903:b0:3a4:dc3b:5a3b with SMTP id ffacd0b85a97d-3a51417b09bmr5913737f8f.10.1749049551914;
        Wed, 04 Jun 2025 08:05:51 -0700 (PDT)
Message-ID: <85d6f812-784a-4959-a1e6-589ebac8887c@suse.com>
Date: Wed, 4 Jun 2025 17:05:40 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 08/14] xen/riscv: imsic_init() implementation
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 ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <421dad1bbd014a2d7ff588af088eadbd56345dbe.1747843009.git.oleksii.kurochko@gmail.com>
 
 
 <84c9f65a-b278-4be4-b053-5bfa410f9a97@gmail.com>
 <9ab65452-497c-47b5-af18-92a7b2a86d9e@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.06.2025 15:42, Oleksii Kurochko wrote:
> 
> On 6/2/25 12:22 PM, Jan Beulich wrote:
>> On 27.05.2025 13:30, Oleksii Kurochko wrote:
>>> On 5/26/25 8:44 PM, Oleksii Kurochko wrote:
>>>>>> +    if ( !dt_property_read_u32(node, "riscv,guest-index-bits",
>>>>>> +                               &imsic_cfg.guest_index_bits) )
>>>>>> +        imsic_cfg.guest_index_bits = 0;
>>>>>> +    tmp = BITS_PER_LONG - IMSIC_MMIO_PAGE_SHIFT;
>>>>>> +    if ( tmp < imsic_cfg.guest_index_bits )
>>>>>> +    {
>>>>>> +        printk(XENLOG_ERR "%s: guest index bits too big\n",
>>>>>> +               dt_node_name(node));
>>>>>> +        rc = -ENOENT;
>>>>>> +        goto cleanup;
>>>>>> +    }
>>>>>> +
>>>>>> +    /* Find number of HART index bits */
>>>>>> +    if ( !dt_property_read_u32(node, "riscv,hart-index-bits",
>>>>>> +                               &imsic_cfg.hart_index_bits) )
>>>>>> +    {
>>>>>> +        /* Assume default value */
>>>>>> +        imsic_cfg.hart_index_bits = fls(*nr_parent_irqs);
>>>>>> +        if ( BIT(imsic_cfg.hart_index_bits, UL) < *nr_parent_irqs )
>>>>>> +            imsic_cfg.hart_index_bits++;
>>>>> Since fls() returns a 1-based bit number, isn't it rather that in the
>>>>> exact-power-of-2 case you'd need to subtract 1?
>>>> Agree, in this case, -1 should be taken into account.
>>> Hmm, it seems like in case of fls() returns a 1-based bit number there
>>> is not need for the check:
>>>    (2) if ( BIT(imsic_cfg.hart_index_bits, UL) < *nr_parent_irqs )
>>>
>>> We could do imsic_cfg.hart_index_bits = fls(*nr_parent_irqs - 1) (1) without
>>> checking *nr_parent_irqs is power-of-two or not, and then just leave the
>>> check (2).
>>> And with (1), the check (2) is only needed for the case *nr_parent_irqs=1, if
>>> I amn't mistaken something. And if I'm not mistaken, then probably it make
>>> sense to change (2) to if ( *nr_parent_irqs == 1 ) + some comment why this
>>> case is so special.
>>>
>>> Does it make sense?
>> Can't easily tell; I'd like to see the resulting code instead of the textual
>> description.
> 
> Here is the code:
>      /* Find number of HART index bits */
>      if ( !dt_property_read_u32(node, "riscv,hart-index-bits",
>                                 &imsic_cfg.hart_index_bits) )
>      {
>          /* Assume default value */
>          imsic_cfg.hart_index_bits = fls(*nr_parent_irqs - 1) +
>                                      (*nr_parent_irqs == 1);
>      }
> 
> It seems like it covers all the cases.

*nr_parent_irqs		imsic_cfg.hart_index_bits
	 1			1 (0 + 1)
	 2			1
	 3			2
	 4			2
	 5			3
	 6			3

IOW why the special casing of *nr_parent_irqs == 1?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 15:07:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 15:07:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005628.1385061 (Exim 4.92)
	(envelope-from )
	id 1uMpiC-0006Rz-KM; Wed, 04 Jun 2025 15:07:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005628.1385061; Wed, 04 Jun 2025 15:07: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 1uMpiC-0006Rs-HB; Wed, 04 Jun 2025 15:07:28 +0000
Received: by outflank-mailman (input) for mailman id 1005628;
 Wed, 04 Jun 2025 15:03: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 1uMpeB-0004nU-Sg
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 15:03:19 +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 0c8fa1a7-4155-11f0-a300-13f23c93f187;
 Wed, 04 Jun 2025 17:03:19 +0200 (CEST)
Received: by mail-yw1-x1134.google.com with SMTP id
 00721157ae682-70e3980757bso9631367b3.1
 for ; Wed, 04 Jun 2025 08:03:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0c8fa1a7-4155-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1749049398; x=1749654198; 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=agykzeI/CP2rf2KGCNS4gg7WiuRx4xrKGi9P0NkfQ28=;
        b=WwZ6Ww0xdzUQgTMLg/DWP5gTQIopM/OFHpv2ZZQOphefRwC3Qld603HLHyZno7ZgHW
         WyhA7Zh8Ie8iIvDh8YZVj2syLmMcujZ5qZrjFfqc6HE6tG/od9xJo4KRF5noOJbtkhau
         6Rc7GmAGO/EryD9fnqwI717v2qCLQykPaWFo0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749049398; x=1749654198;
        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=agykzeI/CP2rf2KGCNS4gg7WiuRx4xrKGi9P0NkfQ28=;
        b=WvCrr0HrMGDzmY1FaR1vCOe+JPn5us0J1vZMO7YbIKhMse1vmEr7hQQzqsd9C3espH
         yf6uZyG8voBwGIvzkGzfNu9TXXaAESOGDyfCpmQmD3RL/b5zF2SPEhFH3fdcl0jJySlP
         HJ8X3ktpdGTq2wn2Q6xok87M1SsPp49l+ldUjQ/aYHfB7pI6BaBncxctu9WG7ZCvLbSp
         qqUCp9cadM/DxfAy4nS2hGnnce/s0OgoHB642qAgCb11/vX8quu/xhhbMrU3XyMCrWTE
         NysvcNcVa/jALo+06P9YpTo1pWWFTKCeVb/q6Q7DATUXK9z6PBNdjIMw/KN+PQbAtEOB
         YGGQ==
X-Gm-Message-State: AOJu0YxKLxNBA8ue2bBaDDXtd64pbs213nqfjwgufCP+8uFcju1xhg7/
	77kNDjNljygBvjBGvsMqG1LiqUrADwOQWIGFn8wGii45II1cLUth0iEetip7S+znu5DeMAXOAcU
	N9CHJ2f3IASjrTYfaWztyT+ZzSjDVwSlgIeYE6hNaGQ==
X-Gm-Gg: ASbGnctui8VT+/QVV0J7ztMTrwPtvojlVd73SLEAksqRbw8Y5gMvJ/KROmeDiffcK4y
	dMaDZAR/hcgIguC/oZ0J1JcDfErqUA876w+92msXMA98oNP1Dba8/oZvtOQ9Lm6+9DVgLAaYW9O
	+DQ8g0kNnab1YaqZn2a2AY3/o41Y4FzHkx
X-Google-Smtp-Source: AGHT+IEqF0SLV+GCQF+QfBOUfR0r1MwfptPqkOmqScPWq5rYbqvxsSsyjfCvAdo6PzTYZqr7FafcwV8ng+tTOMpJTT8=
X-Received: by 2002:a05:690c:dc7:b0:70d:8e1f:ec2b with SMTP id
 00721157ae682-710c98673femr98902357b3.6.1749049397837; Wed, 04 Jun 2025
 08:03:17 -0700 (PDT)
MIME-Version: 1.0
References: <20250604130253.2805053-1-andrew.cooper3@citrix.com>
In-Reply-To: <20250604130253.2805053-1-andrew.cooper3@citrix.com>
From: Aidan Allen 
Date: Wed, 4 Jun 2025 16:03:08 +0100
X-Gm-Features: AX0GCFupS9JuYktCUlMyyxJwXzkMWCCCe0oCAdMP4ZIfnfB-OZ-HeQ1YRKDo6kc
Message-ID: 
Subject: Re: [PATCH] x86/hvm: Process pending softirqs while dumping VMC[SB]s
To: Andrew Cooper 
Cc: Xen-devel , Jan Beulich , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 4, 2025 at 2:02=E2=80=AFPM Andrew Cooper  wrote:
>
> 24 guests with 8 vcpus each is sufficient to hit a 5 second watchdog.
>
> Drop a piece of trailing whitespace while here.
>
> Reported-by: Aidan Allen 
> Signed-off-by: Andrew Cooper 

LGTM. Boots fine and cannot reproduce the crash with this patch.

Tested-by: Aidan Allen 

Thanks, Aidan.


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 15:12:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 15:12:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005658.1385070 (Exim 4.92)
	(envelope-from )
	id 1uMpnD-0007yS-4P; Wed, 04 Jun 2025 15:12:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005658.1385070; Wed, 04 Jun 2025 15: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 1uMpnD-0007yL-1p; Wed, 04 Jun 2025 15:12:39 +0000
Received: by outflank-mailman (input) for mailman id 1005658;
 Wed, 04 Jun 2025 15:12: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 1uMpnC-0007yF-30
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 15:12:38 +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 596f3ba9-4156-11f0-a300-13f23c93f187;
 Wed, 04 Jun 2025 17:12:37 +0200 (CEST)
Received: by mail-lj1-x230.google.com with SMTP id
 38308e7fff4ca-32a63ff3bdfso57358121fa.3
 for ; Wed, 04 Jun 2025 08:12:37 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23506cd8cfbsm105170005ad.118.2025.06.04.08.07.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 04 Jun 2025 08:07:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 596f3ba9-4156-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749049957; x=1749654757; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ppKDDd1KM/CBZpIQdCr6Cpu3wQ0r5qJV36tW1pEJnz0=;
        b=UUWZrx+bRmsoEaJ82S+gFWGYVenh6VZdZQpK6dzpWtbPVxhn5KkXgeiqQRHwzqInlj
         iAjrs+J33CzM3vE+M6zfy+YymEJxKVpkllmOpUcxHPyEaYDG3bxxZj0UEabhKFzlKm7O
         07tq7P2SJpz+PCAWHJlfTofJzW4a4EX3Ptn0tJG1eWuz5gV8ny/F01ycbloYib/LVy33
         9icJiKb29OdVtCfuWaWRiyXKrJGBLuyt3Rll0HIlPa3wEie0nezemsT4692eV55iyhif
         SevVCy83bftb4yXnE5Exe4sS9CTN5O0zWzb7G5EiYepfD+uEelFMIx3CbVqINs0lu0mW
         RJug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749049957; x=1749654757;
        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=ppKDDd1KM/CBZpIQdCr6Cpu3wQ0r5qJV36tW1pEJnz0=;
        b=VnoOuDaX4zd+BJOBgiZ28ZHLRL/OZWk/v5DpU34/yg4Uh6rOiiParu2RD4soE1aLLP
         H4oqo/wdOns4yrw9uG0r1+FBzaOb5USFm6j+M0gocJJLc87eQK3Yu0Vm351RVTI0vg1G
         +Xgv8RBu9Cgu1KgCnh3e/m4sUxBF0oVObB4HNNpdNXI2ayjTWcbmYDowqlPFFWT1RYou
         g8Hc2z5Vhgx4OeT7JcSMwH+Uj8swWxX3RKEpUTZ48tUZRpfGn/08UcB9GY+nYplwjZAo
         AE8LmPnaA+ngCRAqqNotk8U+4SxTs5wnMvkHI05Re6/TCwbSI0A0DANErMP6hqhHkxmu
         fkzw==
X-Forwarded-Encrypted: i=1; AJvYcCVT5Kqs4ZGDwmroWm6obOhRqhoW523gs4joxCsXeFCJzELBNTpCgyLGohps/GTq3Hw6cNy9Ya6BIuE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyhsRrKKjkKRRB0eeoLnocA0U3gnFn7zcWLjUT+7i8Lk6PQ4u6/
	poF2WXw0Ln47q5N9ZAWmaJAMikquFteiEXaFa0PAE+Jy31YQMBxFZc0Rj8REZ9TQp35Fw2S6czt
	eUTg=
X-Gm-Gg: ASbGncsFETGnRtOliDpy4w6ws1DIYJGDEvSO+uvhcQVlUznsPPud1hSIgkIeT0wvQoH
	iMMkkwQgW3v3WaXp+VMidgGxlh696M/4crNwLJ4aQ0MWM7I29nzG20LuZxmzWZOrKvvXRfkO/sh
	9UaPN2DpdcFdcse5xEfxR+v8KiiBuUvZFskJiELiefjfH1n8I9dgGCSzw1AFkml3W8tqhJ0waQQ
	MzB2NLpVZnDVQ1PodYW8H0J//I8/LW9fuDu+dbXhDBoUUxq8mweadpwnhw8RijMMEg7lh66Nraj
	UBmLlqMKDK5VVSA3oLThOQ9/h0pRBJrXNPm03SvV5c0e2wpPxsrJXZwlX5/4PSIWyi7BDivZISH
	vnOLC9rUUSt8HqMhqec/G7TEA4bZ1QoVgvygIepnQQuTcOPU=
X-Google-Smtp-Source: AGHT+IF/LtX1ICFsoFXnH9qbJjrhUWgHzmL7wfiW5XIrMaAA7X1uTuUx6gkqxzvECP4BgyJzdjEGQw==
X-Received: by 2002:a05:6000:420a:b0:3a4:f893:3f03 with SMTP id ffacd0b85a97d-3a51d967c96mr2506343f8f.45.1749049650919;
        Wed, 04 Jun 2025 08:07:30 -0700 (PDT)
Message-ID: <8bd7442c-cd63-4933-b05d-f939462614ba@suse.com>
Date: Wed, 4 Jun 2025 17:07:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] x86/numa: introduce per-NUMA node flush locks
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250522084815.825-1-roger.pau@citrix.com>
 <20250522084815.825-3-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: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 04.06.2025 17:03, Roger Pau Monné wrote:
> Thanks, given the feedback I think you consider this an improvement
> worth pursuing then?

Given the numbers you provided - yes.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 15:13:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 15:13:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005662.1385082 (Exim 4.92)
	(envelope-from )
	id 1uMpne-00004t-Dd; Wed, 04 Jun 2025 15:13:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005662.1385082; Wed, 04 Jun 2025 15:13: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 1uMpne-0008WS-9i; Wed, 04 Jun 2025 15:13:06 +0000
Received: by outflank-mailman (input) for mailman id 1005662;
 Wed, 04 Jun 2025 15:13: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 1uMpnd-0007yF-Ej
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 15:13:05 +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 69ea6eb1-4156-11f0-a300-13f23c93f187;
 Wed, 04 Jun 2025 17:13:05 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3a374f727dbso6116263f8f.0
 for ; Wed, 04 Jun 2025 08:13:05 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a5253a7aeesm600914f8f.1.2025.06.04.08.13.03
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 04 Jun 2025 08:13:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 69ea6eb1-4156-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749049984; x=1749654784; 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=xitLzBlMV1JQpJ/aBXMyhSPmWh6MH4hoLGJtOXCcl1U=;
        b=vic22R41tWWHrnwgAzGDinPClkyYi/yrgPBJfACgDlAVQwE3S7oJV860NxdYva4q8p
         UhNYBJiKeB/QfZoLdjXQ/MqhqJdNglTYH+NlBI3/jzYpoCmnPPhYUKb3GHm246NLyDSA
         E0cXQ/ZtjOM11LHiFSjkOS4dK2Wi9L/i1R3s0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749049984; x=1749654784;
        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=xitLzBlMV1JQpJ/aBXMyhSPmWh6MH4hoLGJtOXCcl1U=;
        b=dN5jKkckztQMgd4+SRHnGJspTziM6qQTvDHf1NPG4zpVDPqtXYqdu9W2m0R818m/a+
         zkSZp6bhX9MfWsosOwHGX/9gJfWIMToz8yaISwCbxMpGOBqxpbeO/K+o6sKKF+NhGPDp
         d6i2afGLsaqxHA3LssdEOUNO32ubKPdfxGaQltkiUQj4upX1E/DBS5f7ZiAjFJku4J8X
         EfcyyP2wszt1relRYTa8zRTZNQ3RIU0DVq0sCMkJfdlsZlIVdkHOLtBzzmAZTWN9dt+B
         WGDpP7PynzIbKSMHEq0c64i3Kg0lR88L3U3wP4gn0cEknZr7WRKJl9MUbhaCO8qyoL88
         7kOA==
X-Forwarded-Encrypted: i=1; AJvYcCXc0XlDNo8+MZN7zyKtVvZOOSXEPxHs0/GlrbrKmoYN3L0W9WrNLQBfCjOY0X3HOzwsyVsDg+hm4no=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyBi3vEn54VephwceyZMNu9bbgXwogHClXOMg6hWbraX9PuYTcP
	QPUCFlT3NL/swR1b4YW0j8BNr3JBhf9sCMB30B17QghCpl1emr4YOjdruvSmejyo910=
X-Gm-Gg: ASbGnctyUb8oL1724E0n0t2KgENrEIsIIwmGK0E2VrCNVgqKST4/xNDm72W2xTVUSNQ
	qUo8MaPgN4ni4wdCnI83VNuWla1ugr9fQjHbdcpvBvYVKn4dhBxaFO33/HNiSIjwAnFHMTQ5naf
	uNgqfTrpgNtKtP8QaLzuel53UXD2+WXatiL2fajpTSHU6U2ioRHCT6vZLjDREpfRSjmFbXFQRCy
	felTz4d2YKpyp4dBUUXiqwnGP6qQ4Ao3EPw1b2/Aziv6fxTji76K3wDdF74A5UwrrnnEsAYqU9d
	km0jZFkdOUfoXp/g4pGlSQxLP8bM3VFUTHzFYGT1V8uAruI2pVjyUddbtBDB3uMv2ze07yN8EcN
	8fKA0+MAGJJEjBh7vEY7cAlbM
X-Google-Smtp-Source: AGHT+IFI5748rw0qTSZpO584EyoNsU5hs9vzricJt0LgJ6hI/FSjq2DObGwkyPbA/tYUgpiwbvwIEA==
X-Received: by 2002:a05:6000:dc6:b0:3a5:25d0:cf3e with SMTP id ffacd0b85a97d-3a525d0d330mr486273f8f.21.1749049984314;
        Wed, 04 Jun 2025 08:13:04 -0700 (PDT)
Date: Wed, 4 Jun 2025 17:13:03 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 2/2] x86/numa: introduce per-NUMA node flush locks
Message-ID: 
References: <20250522084815.825-1-roger.pau@citrix.com>
 <20250522084815.825-3-roger.pau@citrix.com>
 <2c120e48-edaa-4518-a92e-38872bfc6eac@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <2c120e48-edaa-4518-a92e-38872bfc6eac@suse.com>

On Wed, Jun 04, 2025 at 02:42:45PM +0200, Jan Beulich wrote:
> On 22.05.2025 10:48, Roger Pau Monne wrote:
> > +bool flush_numa_node(const cpumask_t *mask, const void *va, unsigned int flags)
> > +{
> > +    nodeid_t node = num_online_nodes() > 1 ? cpumask_to_node(mask)
> > +                                           : NUMA_NO_NODE;
> > +    struct arch_numa_node *info;
> > +
> > +    if ( node == NUMA_NO_NODE )
> > +        return false;
> 
> One further question: Here you limit NUMA flushing to a single node, using
> global flushes in all other cases. Did you consider extending this?

I did consider it, my first through was that such approach would
require taking multiple per-node locks at the same time, and so was
not worth pursuing.

I now realize however that we can decompose multi-node flushes into
per-node actions, and execute them sequentially, taking just one
per-node lock for each action.  I can see into doing this.  I'm unsure
whether such decomposing into sequential per-node flushes won't add
more latency (even if reducing contention).

As you say below, that way we would avoid having to allocate an extra
vector.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 15:16:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 15:16:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005670.1385091 (Exim 4.92)
	(envelope-from )
	id 1uMpqX-0000ne-Pt; Wed, 04 Jun 2025 15:16:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005670.1385091; Wed, 04 Jun 2025 15:16: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 1uMpqX-0000nX-MK; Wed, 04 Jun 2025 15:16:05 +0000
Received: by outflank-mailman (input) for mailman id 1005670;
 Wed, 04 Jun 2025 15:16: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 1uMpqW-0000nR-M7
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 15:16:04 +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 d3db2ac7-4156-11f0-b894-0df219b8e170;
 Wed, 04 Jun 2025 17:16:02 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3a3673e12c4so4598230f8f.2
 for ; Wed, 04 Jun 2025 08:16:02 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b2eceb35702sm7690356a12.33.2025.06.04.08.15.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 04 Jun 2025 08:16:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d3db2ac7-4156-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749050162; x=1749654962; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=VrYmFIQbGOCJvVH7bubKFU+nq46q1ZjZsLP8JCXNox8=;
        b=L2AX7q4vIfj8rHzfG2rQ4mIkyZU/CE2eGpht1/rudhHD2YgJobPlpUKvfSEC5eMjB3
         TWkbyxQf+IlU/N1QRVdWdguzWfvMRVinHWGzWjILU6ANlJgPzWDd0Bn+MVRbipvUQD6Q
         1XoTCkevKvGM4GL+SUekqbcvwHzx77OcxWsiDZc6/Gd7fkS9FSvVZmZUtJMir4NOQVDJ
         sfGdarUiF81hPnTOA6+xiKHL8A6T/dhYgVTjUywhWU3QY/WXaOFRUnUtwqxJcg80FQB5
         +FkSEFN6V5slYdohKtgBRMKkManxkVME/Xr28WWyEnxKWyeCWS19EDaxqGgQKolV5n+K
         DjXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749050162; x=1749654962;
        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=VrYmFIQbGOCJvVH7bubKFU+nq46q1ZjZsLP8JCXNox8=;
        b=kRnoBNJ+94vhDtmolLewisM/T82f03qcB/bBhyT5O74j72Wr1sn0g3xW1nlcj4+/XO
         wJwsEb45j6ajFUCf46baxT+h28bTRuGnqe8YQs3ANDQKr/sRr3diYM/9hlSa8xEITPFi
         Kn4/flxwpzPP/XhuMhwxOcpoEDyLcTftmH3LqJfdASFhtP2PTAb2eF4NBllinCkZ8hZY
         nqmDI5AMtvUzA8aB5izXkOQEpFTGYD4KVN7oH4HTRGbNWDFSN1J5F6MIpSuirkLPWxzj
         /f7eHPgNBrI2w7sXoSt+H07QKhMt+EDuq8xiZaeabSHdR4rReprW/OFT+jmgBjyQAc8Y
         3WyQ==
X-Forwarded-Encrypted: i=1; AJvYcCUCpfdslRUptsUI9gETWxXL74DbZrFgPgBErUF20QfPGrD57sQTNPexUu82rRpCoHgQH0duQ5k4z1w=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzgsIFbotKBByRbT+G5nvUqtjY2nRGl17gAe7Qk/1RuX+46R1Yt
	+ZMZbSwXS/S+ZG4oeWXm48gUyQ4yb0ewr7E9qypW10EH8tnNaR5DkoDLda6VnlFugw==
X-Gm-Gg: ASbGnctFjRZa4e7r1fsVHldLY2+5g3LNR3qQzB0g+zWVKIlc4IhKIfBut7XQtykgOij
	u2F+FUT7hsCNz/qhetkBIeJdvxL3zZ4g1eIsWhTVVZVOOVzX6Fei6QAN0k9Kz3DBtDW/R4lLQn5
	6MUi5zh2ttMZtsyA/dQAo1PGAMJwJRE4YI7hIkpCVRoRzoIq0oRESx+ybR9LMTRIZCSjb0rRPq0
	I56CsXdXDwj0gpKPLvdzoGW67xcSUMSOGKgS2LukOKwFsoQR4sh/hgFErU81fOFazjx8iwV3dJg
	a4pYjh/r+7DBrrVHGNBmO3Tr66fCvDZS+qpdTjeoCLCQKLZihC0Mlu1bUK1tZhJqd0BNjPH9bzu
	xM40eTnmw6E9eMelMUTp1StaKCZ/LQLEBAlvIIkWu8XwyPO8=
X-Google-Smtp-Source: AGHT+IEedwOOlksAyr7VLCJx98WGfZ4X+I+UB4nt7jJSsMnNRdyZLCwkwsium2ep4id77ZyPGqHNhg==
X-Received: by 2002:a05:6000:250c:b0:3a0:b84c:7c64 with SMTP id ffacd0b85a97d-3a51d8ff9e2mr2515175f8f.13.1749050162040;
        Wed, 04 Jun 2025 08:16:02 -0700 (PDT)
Message-ID: 
Date: Wed, 4 Jun 2025 17:15:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/hvm: Process pending softirqs while dumping VMC[SB]s
To: Andrew Cooper 
Cc: Aidan Allen ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20250604130253.2805053-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: <20250604130253.2805053-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.06.2025 15:02, Andrew Cooper wrote:
> @@ -246,6 +248,8 @@ static void cf_check vmcb_dump(unsigned char ch)
>              }
>              printk("\tVCPU %d\n", v->vcpu_id);
>              svm_vmcb_dump("key_handler", v->arch.hvm.svm.vmcb);
> +
> +            process_pending_softirqs();

It's only an RCU read lock we're holding here, but it still feels somewhat
odd to do this with any kind of lock held. Then again (I didn't even
consider this upon earlier insertions of such into keyhandler functions)
we may even be holding a real lock (the sysctl one) when getting here, yet
apparently that was deemed fine in the past. Plus dump_domains() does the
same as what we end up with here ...

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 15:20:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 15:20:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005676.1385101 (Exim 4.92)
	(envelope-from )
	id 1uMpv3-0002K4-Aj; Wed, 04 Jun 2025 15:20:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005676.1385101; Wed, 04 Jun 2025 15: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 1uMpv3-0002Jx-7L; Wed, 04 Jun 2025 15:20:45 +0000
Received: by outflank-mailman (input) for mailman id 1005676;
 Wed, 04 Jun 2025 15:20:43 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uMpv1-0002Jr-KR
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 15:20:43 +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 7add5135-4157-11f0-a300-13f23c93f187;
 Wed, 04 Jun 2025 17:20:42 +0200 (CEST)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-441ab63a415so76323795e9.3
 for ; Wed, 04 Jun 2025 08:20:42 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-450d7f9efa3sm199613815e9.9.2025.06.04.08.20.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 04 Jun 2025 08:20:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7add5135-4157-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749050442; x=1749655242; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=OM10Z5QIzo2xd5+skjriv/42PaEeMYCQ1FffggO6aJA=;
        b=awt4e/3k7bYfZkPF52w7peW28tb5AQBXIv9bVePcJG27lmrke+Dbm4P3b2PV0L4Ga+
         B3fLBdR5aFihEWqRorH573/gKXk3OBSftevYGGFszIkrVcoxkHQSu8FdsEuyOr5E90+E
         b0yn6LvgsmfkB4oK+JsLZRdtzydg3E7RLxo9w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749050442; x=1749655242;
        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=OM10Z5QIzo2xd5+skjriv/42PaEeMYCQ1FffggO6aJA=;
        b=P90WQHwsodCuyUtdbbyLr031C1os+NYag8PpZt3PIqUfZvR6xEuBBT3Tv8aw1YBgYq
         hEuP5cd/2jGXMNRzwYXBv8iJqpgxLUjeHQTzPWwTdEL/NM6JYwr/eUZ9d5zRqaSwu5GV
         QTPTNViYEJVsGbcnsdGZPEJS6hffUiVz16CokTxJY/B5E/VyesJ36DtcrdfHpD2SXES7
         TJ710kVEYad3NAPh/ktfOAsBb4/e2Y3mAeJ6yRBSBcokBC5E6E9UzjQaUkP4+ScrWWTT
         N7jgypReRn09XlRbCPpAuibIPJUkn0KzUbIlVScKMiegKIE2o9T0HnXhyARPEzLJ5K2c
         Br5g==
X-Forwarded-Encrypted: i=1; AJvYcCXygMBFDtsOZiUWY/FQL1sx9x+RqVfMm2/ntyg6trDe1OQob59TmEJjnzFTua/wYviVlgHUFCCb8/g=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzbydnXo//sKwjRTTtxrn8rgEXAc3WUkJdikwb3Ni6x17k70Ulv
	wkFilrhYnG+Aws0UxUmsiU6RsuU8rOWaPIBsiMhpTytz33c/mIMvR4udxcgPUiH/3l0=
X-Gm-Gg: ASbGncvxEX95H10TNq7pEh6B2ehy7YZlu1SXm7QO2cpNGhc/kMzq0l0YAOuvQqXAFsQ
	WEqq4X0PicaM3/1B04F3Uk0ARSE03evEORYHaM1QISfhZdRTnMfraXjJvztrfRTB2JQrAlUVYFh
	5btYWktNg/oUh7j3e0GwEveRRbPD5H6HZ1QY2BoQvpSyhiQITt+xurdsf2HaKrdZEsrocFHkK+p
	UBS+x/1o9KNdMcX8C3bgLJUW5R8VRab2LpiLo9onc5XXgOeuZGbIReX8OzXUGGQwwQsnmsSyNTq
	gr0Qm7v50FOhCOV+qPHrzfZQXtiXrHfqCYK7+Ip+8OadRFlk5J/NxLNxJgyEhjOtMeskY+3/pHw
	vMhGQXeqG0ZqV7MOu
X-Google-Smtp-Source: AGHT+IFOiDqhkF/LuZL8w0Rtb4OkwCmEdbAvTq104oKUlTYWpVJV4+Naoh6nWzC9kYpYwot3hMrpug==
X-Received: by 2002:a05:600c:4f47:b0:43c:efed:733e with SMTP id 5b1f17b1804b1-451f0a7c52emr32839385e9.14.1749050442235;
        Wed, 04 Jun 2025 08:20:42 -0700 (PDT)
Message-ID: <7c3f7bb0-b7b9-4909-8d8b-d412498aea59@citrix.com>
Date: Wed, 4 Jun 2025 16:20:40 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/hvm: Process pending softirqs while dumping VMC[SB]s
To: Jan Beulich 
Cc: Aidan Allen ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20250604130253.2805053-1-andrew.cooper3@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 04/06/2025 4:15 pm, Jan Beulich wrote:
> On 04.06.2025 15:02, Andrew Cooper wrote:
>> @@ -246,6 +248,8 @@ static void cf_check vmcb_dump(unsigned char ch)
>>              }
>>              printk("\tVCPU %d\n", v->vcpu_id);
>>              svm_vmcb_dump("key_handler", v->arch.hvm.svm.vmcb);
>> +
>> +            process_pending_softirqs();
> It's only an RCU read lock we're holding here, but it still feels somewhat
> odd to do this with any kind of lock held. Then again (I didn't even
> consider this upon earlier insertions of such into keyhandler functions)
> we may even be holding a real lock (the sysctl one) when getting here, yet
> apparently that was deemed fine in the past. Plus dump_domains() does the
> same as what we end up with here ...

The debug keys are debug functionality, and do play rather fast and loose.

While the Xen watchdog does hit first (5s), spending too long does cause
problems for the vCPU that's interrupted (usually soft lockup).

I was wondering if we should force schedule to idle before running most
keyhandlers.  That prevents holding a vCPU hostage (and if it's hard
pinned, then tough luck).

We would want a way of blocking further sysctl-debug-key's while one is
pending.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 15:30:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 15:30:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005694.1385111 (Exim 4.92)
	(envelope-from )
	id 1uMq4k-0004G2-7x; Wed, 04 Jun 2025 15:30:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005694.1385111; Wed, 04 Jun 2025 15: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 1uMq4k-0004Fv-4x; Wed, 04 Jun 2025 15:30:46 +0000
Received: by outflank-mailman (input) for mailman id 1005694;
 Wed, 04 Jun 2025 15:30:45 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uMq4j-0004Fp-Bz
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 15:30:45 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uMq4i-001xey-2y;
 Wed, 04 Jun 2025 15:30:44 +0000
Received: from lfbn-gre-1-199-136.w90-112.abo.wanadoo.fr ([90.112.161.136]
 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 1uMq4j-002VFC-0F;
 Wed, 04 Jun 2025 15:30: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" 
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=DRLG+PyVcgEL1nJqbsbEqw1b4C7pXgsy8kpVYFM30VM=; b=KNOrvLUS6IVNltpBYGObCszLkk
	Mim9aD4rUyBSTbYnAqAVi58ImaS9W+dg4CB0igHPtH2YEz7rTn9ptelQLG3Xyoei6Blf+JBXQUpva
	bW4KG/4hOhb8TzfoLEj47hhGhQ0rzPqbHN0eWDdMHrqBZqVRot+MOF+BG3JXW6xD5fMc=;
Date: Wed, 4 Jun 2025 17:30:42 +0200
From: Anthony PERARD 
To: Ross Lagerwall 
Cc: xen-devel@lists.xenproject.org,
	Anthony PERARD ,
	Juergen Gross , Jan Beulich 
Subject: Re: [PATCH v3 4/5] libxc/PM: Ensure pxstat buffers are correctly
 sized
Message-ID: 
References: <20250527152635.2451449-1-ross.lagerwall@citrix.com>
 <20250527152635.2451449-5-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250527152635.2451449-5-ross.lagerwall@citrix.com>

On Tue, May 27, 2025 at 04:26:34PM +0100, Ross Lagerwall wrote:
> diff --git a/tools/libs/ctrl/xc_pm.c b/tools/libs/ctrl/xc_pm.c
> index ff7b5ada053f..0bd79031044f 100644
> --- a/tools/libs/ctrl/xc_pm.c
> +++ b/tools/libs/ctrl/xc_pm.c
> @@ -46,35 +46,34 @@ int xc_pm_get_pxstat(xc_interface *xch, int cpuid, struct xc_px_stat *pxpt)
>  {
>      struct xen_sysctl sysctl = {};
>      /* Sizes unknown until xc_pm_get_max_px */

This comment is wrong now and can be removed.

> -    DECLARE_NAMED_HYPERCALL_BOUNCE(trans, pxpt->trans_pt, 0, XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
> -    DECLARE_NAMED_HYPERCALL_BOUNCE(pt, pxpt->pt, 0, XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
> +    DECLARE_NAMED_HYPERCALL_BOUNCE(trans, pxpt->trans_pt,
> +                                   pxpt->total * pxpt->total * sizeof(uint64_t),
> +                                   XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
> +    DECLARE_NAMED_HYPERCALL_BOUNCE(pt, pxpt->pt,
> +                                   pxpt->total * sizeof(struct xc_px_val),
> +                                   XC_HYPERCALL_BUFFER_BOUNCE_BOTH);

The rest of the patch looks fine:
Reviewed-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 15:36:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 15:36:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005699.1385120 (Exim 4.92)
	(envelope-from )
	id 1uMqA7-0005CA-Pl; Wed, 04 Jun 2025 15:36:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005699.1385120; Wed, 04 Jun 2025 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 1uMqA7-0005C3-N7; Wed, 04 Jun 2025 15:36:19 +0000
Received: by outflank-mailman (input) for mailman id 1005699;
 Wed, 04 Jun 2025 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 1uMqA6-0005Bx-Bl
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 15:36:18 +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 a72e16c6-4159-11f0-b894-0df219b8e170;
 Wed, 04 Jun 2025 17:36:16 +0200 (CEST)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-606741e8e7cso5928685a12.1
 for ; Wed, 04 Jun 2025 08:36:16 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ada5dd04579sm1097050366b.87.2025.06.04.08.36.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 04 Jun 2025 08:36:04 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a72e16c6-4159-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749051376; x=1749656176; 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=k19Y/CfWCFtHB6ri66KNehYH7QxHeq9EzOhhmIGU8J8=;
        b=ikIpHYdGYzbTFqHfVWSjBXTDrUEuRUD9K8uMSiMtbqf31AKQO/pj5b/55GWeIH2NMb
         g82TaVG92V61Xx6ShVBEi+Vl18GJpP9mxN8/mK7mvAMxvAu0BSDsrJtHV9ycYHhaamEc
         Ym3vcXg4qgNhWW29Zpx+ZFfkEfXJG+hiNzAUFAY9WpWszStplRfXjuJsOcbuHqxBgmoZ
         aYOwxb1H50Lv5o9FX99epjOdnnB7uEkIV1EnVj6c9t6OzSyj1aCGDyaKmeu1j9v6IgbU
         bnRrycSl8dO2MMKIkM3hbsfD2YhZ4Mltx/NvIJ0ygv/tJfP73PbL609U0nBP/+Cw+LkC
         h86g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749051376; x=1749656176;
        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=k19Y/CfWCFtHB6ri66KNehYH7QxHeq9EzOhhmIGU8J8=;
        b=CSgTDzmcaRniRxueHEmcmUaTeOOaeKeL9b7krXtD/eUwdUS14FET/CAKSNQ28uMpJu
         ezN2RqdYfe6SOKkSoD5s1C+WOqvoLgyFpJNPQ23MFW8N3Kj9Zxv7Ov6IHluoMe6rHAul
         zkvanK7GMInwweXJomaF29eST7pinK+D0S3hgxYV1iaEhaR7YOH95VyqeV8+gKEsDkyk
         tOMR/Koyr/E/AuuRqpMoDmS7esn34bEwPoGXmuK6EPRaUGlmHGIuhRYQIjAriI1ZiFK/
         NjlvCxYcbYOuugwd4/54nJsoSRYLsEDTyhWKvdZUVAdWxkXpS87SLTh6ruYFti4pH3ZT
         DarA==
X-Forwarded-Encrypted: i=1; AJvYcCWxI1q6pFwPr4Yl1SE0cMk9rKdhnLPybs67voQDkZrfzukO1nF1cgckRq0rvms+dIuIqXGrrL4eBSo=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy920UXrmmBD/yjvBhWTHme4QUjrWdsQPplRC37DxSoOEzvIvwH
	8aQsn1EOgnRn8k996J8pTMvWOgCxFfnLFujwHmoAUsSgZzfNdBojlVYNuI5J6A==
X-Gm-Gg: ASbGncunvetIhivHc1XQ7j4wSG4EZY7hPdzYRjMCyfjDOQ2sv602CUiJhxYgK/DklDp
	6bLp4yUaimL/U8AXTI4I+qblS7r3fju2CVhMY+gLCqHXBMskUcAsyjqtIu4j3wjK7wjyIbFNSyS
	NHcYp0vgAcevQOguUOv96iGF5/EPtkXa+JqXIPdWelkTpHLiyPsCpDZfSUPBzuFYtAt7ZmlucjB
	p3qhS4k+bet1mN0DsOBEGsmoD4UTAuAmoY9Ol1pjhVn+nFX4mAtG5PAM+zRwJ1trwYMqR9NvcSq
	Z7iJhNL+vNJ4kMVe81/EenUyhdzEnm0G46Q7xdYwjy8+WuICl32qQvc4n9HZd1qmiQvz7uj0Zce
	4nOL4TbirhPogz1O1ezt8/9rV
X-Google-Smtp-Source: AGHT+IHT+D34Kom9Xk1HHs2qP5yXo6QNtD6elrXwyz5TliNEH01zs/VXJAnVNxc5KbhuEfijLTGaPA==
X-Received: by 2002:a17:907:7fa2:b0:ad8:a50c:f6cb with SMTP id a640c23a62f3a-addf8d5ec0amr292575666b.26.1749051365045;
        Wed, 04 Jun 2025 08:36:05 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------nj0fHv050wP7zpSJaqbI1jbx"
Message-ID: 
Date: Wed, 4 Jun 2025 17:36:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 08/14] xen/riscv: imsic_init() implementation
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 ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <421dad1bbd014a2d7ff588af088eadbd56345dbe.1747843009.git.oleksii.kurochko@gmail.com>
 
 
 <8cd6c3e0-0361-4f3f-b3ca-8ffa49b9197d@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <8cd6c3e0-0361-4f3f-b3ca-8ffa49b9197d@suse.com>

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


On 6/2/25 12:21 PM, Jan Beulich wrote:
> On 26.05.2025 20:44, Oleksii Kurochko wrote:
>> On 5/22/25 4:46 PM, Jan Beulich wrote:
>>> On 21.05.2025 18:03, Oleksii Kurochko wrote:
>>>> +    /* Allocate MMIO resource array */
>>>> +    imsic_cfg.mmios = xzalloc_array(struct imsic_mmios, nr_mmios);
>>> How large can this and ...
>>>
>>>> +    if ( !imsic_cfg.mmios )
>>>> +    {
>>>> +        rc = -ENOMEM;
>>>> +        goto imsic_init_err;
>>>> +    }
>>>> +
>>>> +    imsic_cfg.msi = xzalloc_array(struct imsic_msi, nr_parent_irqs);
>>> ... this array grow (in principle)?
>> Roughly speaking, this is the number of processors. The highests amount of processors
>> on the market I saw it was 32. But it was over a year ago when I last checked this.
> Unless there's an architectural limit, I don't think it's a good idea to
> take as reference what's available at present. But yes, ...

This (32) is not an architectural limit.
I assume that if mhartd id accepts a range from 0 to  2^64-1 for RV64 then I assume
that the *theoretical* limit for amount of cpus is  2^64-1. And in RISC-V spec. I can't
find if it is theoretical limit or not.
But if look into AIA (interrupt controller) specification then it tells explicitly that limit
is 16,384:
   1.2 Limits
   In its current version, the RISC-V Advanced Interrupt Architecture can support RISC-V symmet-ric
   multiprocessing (SMP) systems with up to 16,384 harts. If the harts are 64-bit (RV64) and implement
   the hypervisor extension, and if all features of the Advanced Interrupt Architecture are fully
   implemented as well, then for each physical hart there may be up to 63 active virtual harts and
   potentially thousands of additional idle (swapped-out) virtual harts, where each virtual hart has
   direct control of one or more physical devices.
Also 16,384 is used as a maximum for nr_parent_irqs from DTS point of view.

>
>>>    I think you're aware that in principle
>>> new code is expected to use xvmalloc() and friends unless there are specific
>>> reasons speaking against that.
>> Oh, missed 'v'...
> ... adding the missing 'v' will take care of my concern. Provided of
> course this isn't running to early for vmalloc() to be usable just yet.
>
>>>> +    if ( !imsic_cfg.msi )
>>>> +    {
>>>> +        rc = -ENOMEM;
>>>> +        goto imsic_init_err;
>>>> +    }
>>>> +
>>>> +    /* Check MMIO register sets */
>>>> +    for ( unsigned int i = 0; i < nr_mmios; i++ )
>>>> +    {
>>>> +        if ( !alloc_cpumask_var(&imsic_cfg.mmios[i].cpus) )
>>>> +        {
>>>> +            rc = -ENOMEM;
>>>> +            goto imsic_init_err;
>>>> +        }
>>>> +
>>>> +        rc = dt_device_get_address(node, i, &imsic_cfg.mmios[i].base_addr,
>>>> +                                   &imsic_cfg.mmios[i].size);
>>>> +        if ( rc )
>>>> +        {
>>>> +            printk(XENLOG_ERR "%s: unable to parse MMIO regset %u\n",
>>>> +                   node->name, i);
>>>> +            goto imsic_init_err;
>>>> +        }
>>>> +
>>>> +        base_addr = imsic_cfg.mmios[i].base_addr;
>>>> +        base_addr &= ~(BIT(imsic_cfg.guest_index_bits +
>>>> +                           imsic_cfg.hart_index_bits +
>>>> +                           IMSIC_MMIO_PAGE_SHIFT, UL) - 1);
>>>> +        base_addr &= ~((BIT(imsic_cfg.group_index_bits, UL) - 1) <<
>>>> +                       imsic_cfg.group_index_shift);
>>>> +        if ( base_addr != imsic_cfg.base_addr )
>>>> +        {
>>>> +            rc = -EINVAL;
>>>> +            printk(XENLOG_ERR "%s: address mismatch for regset %u\n",
>>>> +                   node->name, i);
>>>> +            goto imsic_init_err;
>>>> +        }
>>> Maybe just for my own understanding: There's no similar check for the
>>> sizes to match / be consistent wanted / needed?
>> If you are speaking about imsic_cfg.mmios[i].size then it depends fully on h/w will
>> provide, IMO.
>> So I don't what is possible range for imsic_cfg.mmios[i].size.
> Well, all I can say is that's it feels odd that you sanity check base_addr
> but permit effectively any size.

Okay, I think I have two ideas how to check the size:
1. Based on guest bits from IMSIC's DT node. QEMU calculates a size as:
     for (socket = 0; socket < socket_count; socket++) {
         imsic_addr = base_addr + socket * VIRT_IMSIC_GROUP_MAX_SIZE;
         imsic_size = IMSIC_HART_SIZE(imsic_guest_bits) *
                      s->soc[socket].num_harts;
     ...
    where:
      #define IMSIC_MMIO_PAGE_SHIFT          12
      #define IMSIC_MMIO_PAGE_SZ             (1UL << IMSIC_MMIO_PAGE_SHIFT)
      
      #define IMSIC_HART_NUM_GUESTS(__guest_bits)           \
              (1U << (__guest_bits))
      #define IMSIC_HART_SIZE(__guest_bits)                 \
              (IMSIC_HART_NUM_GUESTS(__guest_bits) * IMSIC_MMIO_PAGE_SZ)

2. Just take a theoretical maximum for S-mode IMSIC's node:
     16,384 * 64 1(S-mode interrupt file) + 63(max guest interrupt files)) * 4 KiB
    Where,
      16,384 - maximum possible amount of harts according to AIA spec
      64 - a maximum amount of possible interrupt file for S-mode IMSIC node:
           1 - S interupt file + 63 guest interrupt files.
      4 Kib - a maximum size of one interrupt file.

Which option is preferred?

The specification doesn’t seem to mention (or I couldn’t find) that all platforms
must calculate the MMIO size in the same way QEMU does. Therefore, it’s probably
better to use the approach described in option 2.

On the other hand, I don't think a platform should be considered correct if it
provides slightly more than needed but still less than the theoretical maximum.

>
>>>> @@ -18,6 +19,18 @@ static inline unsigned long cpuid_to_hartid(unsigned long cpuid)
>>>>        return pcpu_info[cpuid].hart_id;
>>>>    }
>>>>    
>>>> +static inline unsigned long hartid_to_cpuid(unsigned long hartid)
>>>> +{
>>>> +    for ( unsigned int cpuid = 0; cpuid < ARRAY_SIZE(pcpu_info); cpuid++ )
>>>> +    {
>>>> +        if ( hartid == cpuid_to_hartid(cpuid) )
>>>> +            return cpuid;
>>>> +    }
>>>> +
>>>> +    /* hartid isn't valid for some reason */
>>>> +    return NR_CPUS;
>>>> +}
>>> Considering the values being returned, why's the function's return type
>>> "unsigned long"?
>> mhartid register has MXLEN length, so theoretically we could have from 0 to MXLEN-1
>> Harts and so we could have the same amount of Xen's CPUIDs. and MXLEN is 32 for RV32
>> and MXLEN is 64 for RV64.
> Yet the return value here is always constrained by NR_CPUS, isn't it?

I am not 100% sure that I get your point, but I put NR_CPUS here because of:
   /*
    * tp points to one of these per cpu.
    *
    * hart_id would be valid (no matter which value) if its
    * processor_id field is valid (less than NR_CPUS).
    */
   struct pcpu_info pcpu_info[NR_CPUS] = { [0 ... NR_CPUS - 1] = {
       .processor_id = NR_CPUS,
   }};

As an option we could use ULONG_MAX. Would it be better?

~ Oleksii

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



  
    
  
  
    

    
    
    
    
    On 6/2/25 12:21 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 26.05.2025 20:44, Oleksii Kurochko wrote:

    
      
    
        
    On 5/22/25 4:46 PM, Jan Beulich wrote:

    
        
    
          
    On 21.05.2025 18:03, Oleksii Kurochko wrote:

    
          
    
            
    +    /* Allocate MMIO resource array */
+    imsic_cfg.mmios = xzalloc_array(struct imsic_mmios, nr_mmios);

    
          
    
          
    How large can this and ...


    
          
    
            
    +    if ( !imsic_cfg.mmios )
+    {
+        rc = -ENOMEM;
+        goto imsic_init_err;
+    }
+
+    imsic_cfg.msi = xzalloc_array(struct imsic_msi, nr_parent_irqs);

    
          
    
          
    ... this array grow (in principle)?

    
        
    
        
    Roughly speaking, this is the number of processors. The highests amount of processors
on the market I saw it was 32. But it was over a year ago when I last checked this.

    
      
    
      
    Unless there's an architectural limit, I don't think it's a good idea to
take as reference what's available at present. But yes, ...
    
    
    
    
    This (32) is not an architectural limit.
I assume that if mhartd id accepts a range from 0 to  2^64-1 for RV64 then I assume
that the *theoretical* limit for amount of cpus is  2^64-1. And in RISC-V spec. I can't
find if it is theoretical limit or not.
But if look into AIA (interrupt controller) specification then it tells explicitly that limit
is 16,384:
  1.2 Limits
  In its current version, the RISC-V Advanced Interrupt Architecture can support RISC-V symmet-ric
  multiprocessing (SMP) systems with up to 16,384 harts. If the harts are 64-bit (RV64) and implement
  the hypervisor extension, and if all features of the Advanced Interrupt Architecture are fully
  implemented as well, then for each physical hart there may be up to 63 active virtual harts and
  potentially thousands of additional idle (swapped-out) virtual harts, where each virtual hart has
  direct control of one or more physical devices.
Also 16,384 is used as a maximum for nr_parent_irqs from DTS point of view.


    
    
    
      
    

    
      
    
        
    
          
      I think you're aware that in principle
new code is expected to use xvmalloc() and friends unless there are specific
reasons speaking against that.

    
        
    
        
    Oh, missed 'v'...

    
      
    
      
    ... adding the missing 'v' will take care of my concern. Provided of
course this isn't running to early for vmalloc() to be usable just yet.


    
      
    
        
    
          
    
            
    +    if ( !imsic_cfg.msi )
+    {
+        rc = -ENOMEM;
+        goto imsic_init_err;
+    }
+
+    /* Check MMIO register sets */
+    for ( unsigned int i = 0; i < nr_mmios; i++ )
+    {
+        if ( !alloc_cpumask_var(&imsic_cfg.mmios[i].cpus) )
+        {
+            rc = -ENOMEM;
+            goto imsic_init_err;
+        }
+
+        rc = dt_device_get_address(node, i, &imsic_cfg.mmios[i].base_addr,
+                                   &imsic_cfg.mmios[i].size);
+        if ( rc )
+        {
+            printk(XENLOG_ERR "%s: unable to parse MMIO regset %u\n",
+                   node->name, i);
+            goto imsic_init_err;
+        }
+
+        base_addr = imsic_cfg.mmios[i].base_addr;
+        base_addr &= ~(BIT(imsic_cfg.guest_index_bits +
+                           imsic_cfg.hart_index_bits +
+                           IMSIC_MMIO_PAGE_SHIFT, UL) - 1);
+        base_addr &= ~((BIT(imsic_cfg.group_index_bits, UL) - 1) <<
+                       imsic_cfg.group_index_shift);
+        if ( base_addr != imsic_cfg.base_addr )
+        {
+            rc = -EINVAL;
+            printk(XENLOG_ERR "%s: address mismatch for regset %u\n",
+                   node->name, i);
+            goto imsic_init_err;
+        }

    
          
    
          
    Maybe just for my own understanding: There's no similar check for the
sizes to match / be consistent wanted / needed?

    
        
    
        
    If you are speaking about imsic_cfg.mmios[i].size then it depends fully on h/w will
provide, IMO.
So I don't what is possible range for imsic_cfg.mmios[i].size.

    
      
    
      
    Well, all I can say is that's it feels odd that you sanity check base_addr
but permit effectively any size.
    
    
    
    
    Okay, I think I have two ideas how to check the size:
1. Based on guest bits from IMSIC's DT node. QEMU calculates a size as:
    for (socket = 0; socket < socket_count; socket++) {
        imsic_addr = base_addr + socket * VIRT_IMSIC_GROUP_MAX_SIZE;
        imsic_size = IMSIC_HART_SIZE(imsic_guest_bits) *
                     s->soc[socket].num_harts;
    ...
   where:
     #define IMSIC_MMIO_PAGE_SHIFT          12
     #define IMSIC_MMIO_PAGE_SZ             (1UL << IMSIC_MMIO_PAGE_SHIFT)
     
     #define IMSIC_HART_NUM_GUESTS(__guest_bits)           \
             (1U << (__guest_bits))
     #define IMSIC_HART_SIZE(__guest_bits)                 \
             (IMSIC_HART_NUM_GUESTS(__guest_bits) * IMSIC_MMIO_PAGE_SZ)

2. Just take a theoretical maximum for S-mode IMSIC's node:
    16,384 * 64 1(S-mode interrupt file) + 63(max guest interrupt files)) * 4 KiB
   Where,
     16,384 - maximum possible amount of harts according to AIA spec
     64 - a maximum amount of possible interrupt file for S-mode IMSIC node:
          1 - S interupt file + 63 guest interrupt files.
     4 Kib - a maximum size of one interrupt file.


    
    
    Which option is preferred?
    
    
    The specification doesn’t seem to mention (or I couldn’t find) that all platforms
must calculate the MMIO size in the same way QEMU does. Therefore, it’s probably
better to use the approach described in option 2.
    
    
    On the other hand, I don't think a platform should be considered correct if it
provides slightly more than needed but still less than the theoretical maximum.


    
    
    
      
    

    
      
    
        
    
          
    
            
    @@ -18,6 +19,18 @@ static inline unsigned long cpuid_to_hartid(unsigned long cpuid)
      return pcpu_info[cpuid].hart_id;
  }
  
+static inline unsigned long hartid_to_cpuid(unsigned long hartid)
+{
+    for ( unsigned int cpuid = 0; cpuid < ARRAY_SIZE(pcpu_info); cpuid++ )
+    {
+        if ( hartid == cpuid_to_hartid(cpuid) )
+            return cpuid;
+    }
+
+    /* hartid isn't valid for some reason */
+    return NR_CPUS;
+}

    
          
    
          
    Considering the values being returned, why's the function's return type
"unsigned long"?

    
        
    
        
    mhartid register has MXLEN length, so theoretically we could have from 0 to MXLEN-1
Harts and so we could have the same amount of Xen's CPUIDs. and MXLEN is 32 for RV32
and MXLEN is 64 for RV64.

    
      
    
      
    Yet the return value here is always constrained by NR_CPUS, isn't it?
    
    
    
    
    I am not 100% sure that I get your point, but I put NR_CPUS here because of:
  /*
   * tp points to one of these per cpu.
   *
   * hart_id would be valid (no matter which value) if its
   * processor_id field is valid (less than NR_CPUS).
   */
  struct pcpu_info pcpu_info[NR_CPUS] = { [0 ... NR_CPUS - 1] = {
      .processor_id = NR_CPUS,
  }};

    
    
    As an option we could use ULONG_MAX. Would it be better?

~ Oleksii

    
  


--------------nj0fHv050wP7zpSJaqbI1jbx--


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 15:41:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 15:41:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005707.1385131 (Exim 4.92)
	(envelope-from )
	id 1uMqFV-0006xb-CD; Wed, 04 Jun 2025 15:41:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005707.1385131; Wed, 04 Jun 2025 15: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 1uMqFV-0006xU-8u; Wed, 04 Jun 2025 15:41:53 +0000
Received: by outflank-mailman (input) for mailman id 1005707;
 Wed, 04 Jun 2025 15:41: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 1uMqFT-0006xO-S7
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 15:41:51 +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 6deb51c1-415a-11f0-b894-0df219b8e170;
 Wed, 04 Jun 2025 17:41:49 +0200 (CEST)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-ad89f9bb725so1383988266b.2
 for ; Wed, 04 Jun 2025 08:41:49 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ada6ad39e15sm1120304566b.149.2025.06.04.08.41.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 04 Jun 2025 08:41:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6deb51c1-415a-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749051709; x=1749656509; 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=1PAiwpQjSuqDljXiId6xFvX/8pkDamWfADCpZlqFGx4=;
        b=Q8q0VZHq2RMVlpIXH0i8U5Z9yBsn1x8eOAs4Y0abMalm+oH+HIVFf1DLCZxZqAGyi9
         QUQ0iPmkRpfTKRvOEsTYUGvg/Ochv223y800bbdZoEmUU0LsaGKostshWCuc/rRA2/jL
         sbJMo23n/ILo9a4amWbDFUypPuya/FqA0TqdwA6Ia3Ooms4Rkd1RbRPPzB0OKxN1354z
         8ocLZyT2vwxzpGsZw/1dKgguuS4SEwjmYio/1Ss3YqKjwDbQiqVqFj6ajkUOjn25Zent
         oEyu2yczULGIxjVUztvKKIIoALU+zmGpdM5TzzbInjGHIGBzc8ELDJlX3YERQCPvfkQv
         BNBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749051709; x=1749656509;
        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=1PAiwpQjSuqDljXiId6xFvX/8pkDamWfADCpZlqFGx4=;
        b=EeSaviH70I1IceTe7137zkNQjqZM4HvPmFly9HCFBqZJ3+UMX7W9+o9wm6z0AIWte6
         xEzD+yogpjcva/RIfLN9L63ghIkU10MCqbmY8t2FWOjpNohzZ3eAV1M9jhS0xkSSiWfz
         faNDnROmOy1VyIq2HFKAyiP5DuiIXePF0c/5HI/btZ7EuuZRZAaWak6orgOMrfjqj7Be
         S/HPsBMZ8hGLTh+/vQde6Ad7RRvv+rKssdTb8KcAXYCmynQlKkXvkm9xlviIbo0d3EqO
         NfGVcOZHHiyujffujbvGKuyM2SOCnDHJkBGsBIDxv2B1rgeugFw7QCcKBAneJfX8EV9n
         hDfQ==
X-Forwarded-Encrypted: i=1; AJvYcCXfzuKGHMqQ3o6qP87gDshoI/+FQnPdA1id4iEMPB4rt6QckHsPgobW8Ksh08+IwicNZi/mMjejMeg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzA0lK8TewuBAG1gmxbqbWs+pJgpHJG/Sylg8L0lE0qh4PIEc8m
	ddGp5K37MUaKpmYZ6ot3oxpR6pzmWC76MqIkFF7kuxPr1LsFncswpITY
X-Gm-Gg: ASbGncuLsBtwI21zHuZyjMjZeBinGXhEPyTYO/oIywLHm4uTZUgDRI8VDGNDwlolH+F
	sf692Iiax2DRMvJ3nVmXBALXkqcpIUoKzs/YAPTB8oT8HaN2L+78RVtYeSdt9JzHsrnFns3tkyB
	vnsANeU6Y4e3SEAUXwYJQpjB5L8yAd1T3u2IF/Jm73cOC8py/6Xw6h/AOUnKvkwKciDiCXQxgQS
	1nZS5YzvZNKEgAT6FRnaO50AwYJIGHB2q4bO/g40JRgdH+UPOZtFvCbo/WCkEuW86v+mvK/TiDJ
	4h92/2M8XX7tmWw7wticXmhTuT9Rq6db4rDRqkNnOE+zw6DdzWtXFLGE93/2XkUxt0MQW+Q8hp4
	uy+zveeGyt9vVcVp/yVXIUOsv
X-Google-Smtp-Source: AGHT+IGisFwpTKMJPaS2OeNRrVuPDIiYNgYjOPh70rEPDpw7ZhHD43alxzsQigNYuDmDexMXAhdd6g==
X-Received: by 2002:a17:907:3f1a:b0:ada:4b3c:ea74 with SMTP id a640c23a62f3a-addf904cb61mr321971566b.59.1749051708911;
        Wed, 04 Jun 2025 08:41:48 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------Zf7zaXotRFKOUI97rdkYMQrA"
Message-ID: <63d8882d-bd54-4cbd-8c48-24b296ce4a50@gmail.com>
Date: Wed, 4 Jun 2025 17:41:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 08/14] xen/riscv: imsic_init() implementation
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 ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <421dad1bbd014a2d7ff588af088eadbd56345dbe.1747843009.git.oleksii.kurochko@gmail.com>
 
 
 <84c9f65a-b278-4be4-b053-5bfa410f9a97@gmail.com>
 <9ab65452-497c-47b5-af18-92a7b2a86d9e@suse.com>
 
 <85d6f812-784a-4959-a1e6-589ebac8887c@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <85d6f812-784a-4959-a1e6-589ebac8887c@suse.com>

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


On 6/4/25 5:05 PM, Jan Beulich wrote:
> On 04.06.2025 15:42, Oleksii Kurochko wrote:
>> On 6/2/25 12:22 PM, Jan Beulich wrote:
>>> On 27.05.2025 13:30, Oleksii Kurochko wrote:
>>>> On 5/26/25 8:44 PM, Oleksii Kurochko wrote:
>>>>>>> +    if ( !dt_property_read_u32(node, "riscv,guest-index-bits",
>>>>>>> +                               &imsic_cfg.guest_index_bits) )
>>>>>>> +        imsic_cfg.guest_index_bits = 0;
>>>>>>> +    tmp = BITS_PER_LONG - IMSIC_MMIO_PAGE_SHIFT;
>>>>>>> +    if ( tmp < imsic_cfg.guest_index_bits )
>>>>>>> +    {
>>>>>>> +        printk(XENLOG_ERR "%s: guest index bits too big\n",
>>>>>>> +               dt_node_name(node));
>>>>>>> +        rc = -ENOENT;
>>>>>>> +        goto cleanup;
>>>>>>> +    }
>>>>>>> +
>>>>>>> +    /* Find number of HART index bits */
>>>>>>> +    if ( !dt_property_read_u32(node, "riscv,hart-index-bits",
>>>>>>> +                               &imsic_cfg.hart_index_bits) )
>>>>>>> +    {
>>>>>>> +        /* Assume default value */
>>>>>>> +        imsic_cfg.hart_index_bits = fls(*nr_parent_irqs);
>>>>>>> +        if ( BIT(imsic_cfg.hart_index_bits, UL) < *nr_parent_irqs )
>>>>>>> +            imsic_cfg.hart_index_bits++;
>>>>>> Since fls() returns a 1-based bit number, isn't it rather that in the
>>>>>> exact-power-of-2 case you'd need to subtract 1?
>>>>> Agree, in this case, -1 should be taken into account.
>>>> Hmm, it seems like in case of fls() returns a 1-based bit number there
>>>> is not need for the check:
>>>>     (2) if ( BIT(imsic_cfg.hart_index_bits, UL) < *nr_parent_irqs )
>>>>
>>>> We could do imsic_cfg.hart_index_bits = fls(*nr_parent_irqs - 1) (1) without
>>>> checking *nr_parent_irqs is power-of-two or not, and then just leave the
>>>> check (2).
>>>> And with (1), the check (2) is only needed for the case *nr_parent_irqs=1, if
>>>> I amn't mistaken something. And if I'm not mistaken, then probably it make
>>>> sense to change (2) to if ( *nr_parent_irqs == 1 ) + some comment why this
>>>> case is so special.
>>>>
>>>> Does it make sense?
>>> Can't easily tell; I'd like to see the resulting code instead of the textual
>>> description.
>> Here is the code:
>>       /* Find number of HART index bits */
>>       if ( !dt_property_read_u32(node, "riscv,hart-index-bits",
>>                                  &imsic_cfg.hart_index_bits) )
>>       {
>>           /* Assume default value */
>>           imsic_cfg.hart_index_bits = fls(*nr_parent_irqs - 1) +
>>                                       (*nr_parent_irqs == 1);
>>       }
>>
>> It seems like it covers all the cases.
> *nr_parent_irqs		imsic_cfg.hart_index_bits
> 	 1			1 (0 + 1)
> 	 2			1
> 	 3			2
> 	 4			2
> 	 5			3
> 	 6			3
>
> IOW why the special casing of *nr_parent_irqs == 1?

If we don't have "... + (*nr_parent_irqs == 1)" then for the case when *nr_parent_irqs == 1,
we will have imsic_cfg.hart_index_bits = fls(1-1) = fls(0) = 0 because:
   #define arch_fls(x)     ((x) ? BITS_PER_INT - __builtin_clz(x) : 0)
and imsic_cfg.hart_index_bits = 0 doesn't seem correct because I expect that if I have only
1 hart then at least 1 bit will be needed to point to it.

~ Oleksii




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



  
    
  
  
    

    
    
    
    
    On 6/4/25 5:05 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 04.06.2025 15:42, Oleksii Kurochko wrote:

    
      
    
        
    On 6/2/25 12:22 PM, Jan Beulich wrote:

    
        
    
          
    On 27.05.2025 13:30, Oleksii Kurochko wrote:

    
          
    
            
    On 5/26/25 8:44 PM, Oleksii Kurochko wrote:

    
            
    
              
    
                
    
                  
    +    if ( !dt_property_read_u32(node, "riscv,guest-index-bits",
+                               &imsic_cfg.guest_index_bits) )
+        imsic_cfg.guest_index_bits = 0;
+    tmp = BITS_PER_LONG - IMSIC_MMIO_PAGE_SHIFT;
+    if ( tmp < imsic_cfg.guest_index_bits )
+    {
+        printk(XENLOG_ERR "%s: guest index bits too big\n",
+               dt_node_name(node));
+        rc = -ENOENT;
+        goto cleanup;
+    }
+
+    /* Find number of HART index bits */
+    if ( !dt_property_read_u32(node, "riscv,hart-index-bits",
+                               &imsic_cfg.hart_index_bits) )
+    {
+        /* Assume default value */
+        imsic_cfg.hart_index_bits = fls(*nr_parent_irqs);
+        if ( BIT(imsic_cfg.hart_index_bits, UL) < *nr_parent_irqs )
+            imsic_cfg.hart_index_bits++;

    
                
    
                
    Since fls() returns a 1-based bit number, isn't it rather that in the
exact-power-of-2 case you'd need to subtract 1?

    
              
    
              
    Agree, in this case, -1 should be taken into account.

    
            
    
            
    Hmm, it seems like in case of fls() returns a 1-based bit number there
is not need for the check:
   (2) if ( BIT(imsic_cfg.hart_index_bits, UL) < *nr_parent_irqs )

We could do imsic_cfg.hart_index_bits = fls(*nr_parent_irqs - 1) (1) without
checking *nr_parent_irqs is power-of-two or not, and then just leave the
check (2).
And with (1), the check (2) is only needed for the case *nr_parent_irqs=1, if
I amn't mistaken something. And if I'm not mistaken, then probably it make
sense to change (2) to if ( *nr_parent_irqs == 1 ) + some comment why this
case is so special.

Does it make sense?

    
          
    
          
    Can't easily tell; I'd like to see the resulting code instead of the textual
description.

    
        
    
        
    Here is the code:
     /* Find number of HART index bits */
     if ( !dt_property_read_u32(node, "riscv,hart-index-bits",
                                &imsic_cfg.hart_index_bits) )
     {
         /* Assume default value */
         imsic_cfg.hart_index_bits = fls(*nr_parent_irqs - 1) +
                                     (*nr_parent_irqs == 1);
     }

It seems like it covers all the cases.

    
      
    
      
    *nr_parent_irqs		imsic_cfg.hart_index_bits
	 1			1 (0 + 1)
	 2			1
	 3			2
	 4			2
	 5			3
	 6			3

IOW why the special casing of *nr_parent_irqs == 1?

    
    
    
    
    If we don't have "... + (*nr_parent_irqs == 1)" then for the case when *nr_parent_irqs == 1,
we will have imsic_cfg.hart_index_bits = fls(1-1) = fls(0) = 0 because:
  #define arch_fls(x)     ((x) ? BITS_PER_INT - __builtin_clz(x) : 0)
and imsic_cfg.hart_index_bits = 0 doesn't seem correct because I expect that if I have only
1 hart then at least 1 bit will be needed to point to it.

~ Oleksii




    
    

    
    
    
  


--------------Zf7zaXotRFKOUI97rdkYMQrA--


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 16:14:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 16:14:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005731.1385141 (Exim 4.92)
	(envelope-from )
	id 1uMqlH-0003O2-UJ; Wed, 04 Jun 2025 16:14:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005731.1385141; Wed, 04 Jun 2025 16:14:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMqlH-0003Nv-RF; Wed, 04 Jun 2025 16:14:43 +0000
Received: by outflank-mailman (input) for mailman id 1005731;
 Wed, 04 Jun 2025 16:14: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 1uMqlF-0003Np-Ug
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 16:14:42 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20620.outbound.protection.outlook.com
 [2a01:111:f403:2416::620])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 038db770-415f-11f0-a300-13f23c93f187;
 Wed, 04 Jun 2025 18:14:40 +0200 (CEST)
Received: from DS7P220CA0058.NAMP220.PROD.OUTLOOK.COM (2603:10b6:8:224::22) by
 DM4PR12MB6133.namprd12.prod.outlook.com (2603:10b6:8:ae::7) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8792.33; Wed, 4 Jun 2025 16:14:36 +0000
Received: from DS1PEPF0001708F.namprd03.prod.outlook.com
 (2603:10b6:8:224:cafe::50) 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.8792.32 via Frontend Transport; Wed,
 4 Jun 2025 16:14:36 +0000
Received: from SATLEXMB03.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.8792.29 via Frontend Transport; Wed, 4 Jun 2025 16:14: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; Wed, 4 Jun
 2025 11:14:35 -0500
Received: from [172.27.195.250] (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 Jun 2025 11:14:33 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 038db770-415f-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=nOxm7/JMk7hRVq01wVdPUm+RhxTw7uD+Wnu/nHXFKL9PVPinddFR1Zz7tx98lXtkektc84dx9y5KhdWpSpc+MN4aRngHzZYSWoo23z/rUyWMYEflt6o3b7cdrmOz3GfxIgwm02YfvKNuZ9IzuBxrHs19+wXYAFkj7FN1D0mt/aJMc2TUDUfKbyyAD8vb/gJ91gPty8Qgyv+rSavAK8Q5rIxs4NqnG/cY70QeTMaa9lmTKJjrVl12h5Y+iDnl6eE7yfpKxcog3IYfRvMfhNU83q+nE/OooaXaOYYK6ihAzv1CV19h4Gzf2RPkqxxICYun2AfS2i7WmtmGG/XBkGGxFg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=eSOJ6meNppqIJCtLKD1Winmsj/qxt0d4kcfO69cMtAo=;
 b=IYajzAh0DhBxwgTtDiho7j/3035nlyJvymyClvv7b0SVaK96+pEr3NQbwd7XcMqFiXhqGdbPGyz/XLcVFBmopQAWqOVU/CvdJvQ1s7Y57N9QKDLEVSzerzmxiQVWfwONZT1VjnqypEuKlRexPrPeyOQG3foZ3d4K3c9tDgm+PM9L+g4eUCn3NiYugz28P+JAhSf1Ev6D6M+htpB9PZVyaTufD7BsDv5CuB1TWBHN3SqOSA7rUa/1ncYLlzRtjbrd1pWha/Zm2RHnNZ0nETVvice5sRG6xngTyparLUTqAqmeNp4hE91JjQDtTBhzVCh7sW4KvXo+hL/Twlzf1AwNmQ==
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=eSOJ6meNppqIJCtLKD1Winmsj/qxt0d4kcfO69cMtAo=;
 b=goB+FOLTZV3FEBJ2w2Uxq+xanal4eebS6Ju+NhGy6vSMVdiew7iQM9DznWTUG/+5ydNfaVAN9jsdAcLr9Pd7FJKIn/fptNgOrrnD2l68iugmYZYI71yx7LRRjEGg+KcgaKF8fmj7yzrAdMDMiLzxgFoej5XQ74ygnB7IygbZCXU=
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, 4 Jun 2025 11:42:33 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/3] docs: add documentation for Argo as a feature
To: Teddy Astie , Christopher Clark
	, 
CC: Daniel Smith , Rich Persaud
	, Andrew Cooper , "Anthony
 PERARD" , Michal Orzel ,
	"Jan Beulich" , Julien Grall ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini
	
References: <20250528211040.10562-1-christopher.w.clark@gmail.com>
 
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: 
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: DS1PEPF0001708F:EE_|DM4PR12MB6133:EE_
X-MS-Office365-Filtering-Correlation-Id: a8d242c3-8b10-49ae-b954-08dda382e645
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|7416014|376014|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?b1FTbURjR1FFMVlqWnJqa3hXVUsvRlJselZtRGJiWE9tQytac0daWW9RUkZr?=
 =?utf-8?B?TmFQSGpRRThVcGd4YUE5L29HWFlrUUh6Vm5ndmcxNkdFOEFRSTBSNEMrOHJh?=
 =?utf-8?B?LzZJbGplVkVaaG5rdEpLRTBnVzlXQW9jckRxYUFMVHFPYTdMOWVRN0FncmZD?=
 =?utf-8?B?ZG1PSnU3VVhjVnlsWHRmWSt2d3pORUZONXVFZmUrSW5PRjlKNm1jeWFVM3hk?=
 =?utf-8?B?eWdHSjM0V1FUbGFpOHNHeTRoWlM2NkJnYXFyQnQ0YlF0bytlZVZ1dDNFS2cw?=
 =?utf-8?B?LzM3d1lGNGQ3UGxseC9FSXdqdWFLZExIRnVKOHhBdmxRTCtxUzFXRDhjeWIr?=
 =?utf-8?B?R0xjNnRRZjI2Y05LWk5NbEV5ZUZycklMQWVva2NtczBCR2x0eTFjbm05MUNl?=
 =?utf-8?B?N0hnK3JOK0EwL0ZFTDVlMzdQMUlzK201T3hJb0tUQUM2UDN0Q1B4RVUzY1F5?=
 =?utf-8?B?czIrYm1PWEpYbThIVTgzWTRBczlYS25vMTk0VlVXdlpvczJxay9MMW5jR0RU?=
 =?utf-8?B?VHJsbm9UMVpYVEpLVWFoWWpkNU5VK3Q5ZVdsS1dXYWMrMFZMMDJRSGZCenBm?=
 =?utf-8?B?cDFWeEJBY2ZFUWg4cEpETGRCQ3J2ZnFkYy9RMkg2MFVsclFTdFNaaVRQR2xR?=
 =?utf-8?B?ODFRWEZmM1pac215ZjBwNEttY0RKREladURpM3BCb1B3SHJhNUdNY2l3UFZQ?=
 =?utf-8?B?T0RhbVVlT2F1MXp3Z2xheTZXS2tpT3FBS2tyeUZFdDYwVFJTRytzQTh2SFZW?=
 =?utf-8?B?L0FkSVVlQy9UYjVHdEp2d0JYRWViY2lLLy8vOEFGV2cwcFF6bUcxc21EdSt4?=
 =?utf-8?B?NEV4Q3cwYTJ1UlQzaWo2ZEt5dVg5YnNqVXc2cWlUNWZxSmZPa2dMaWZJUDdC?=
 =?utf-8?B?YXlWNUJqWW5WaGRXM1pUZDlaU0JPODU2M3hCOENGZkMzUzlQNW1kZnFaaHJ0?=
 =?utf-8?B?N1I0V3NhRGdRdGxMZDltNnk0N1duQnBiL1E3NUJYeUNpRUdncFVBK0gyUXRK?=
 =?utf-8?B?VW5BNTRsNFhFOCtwSzRwR0IwbUlnNEhzTSs4TUx1NlJRNVh2TFZzajdZVUd4?=
 =?utf-8?B?RzIrS0pZbVBLVHpHQmZEbFBudEdMM3pvK1o2alc1bVJUTkdxOFV2alpKeUl5?=
 =?utf-8?B?dXB0Y1ZISWphOEx4QmlHb21mejRLVWxYcFdmVnlteHFaa0FETm4yZFpFQVIr?=
 =?utf-8?B?TDkrU2JlNmFtUEI4VU8vbjhzQ0lGN0xNaHFTZXA1RGZEdUpkTmhnTjkxV3Fy?=
 =?utf-8?B?ZS9XTzhVeUxNYjE3YnY0ZGxhSGVqeW1qdlYzYUl3cnpTTTQwdFY1Y0VCeGlY?=
 =?utf-8?B?aVVnUlUrKzA0c2JDYVo3bDZqYU1ZOXdhYzlJTUlXbld3aVM5d0ZuN0NzYmFu?=
 =?utf-8?B?bXVaTVgxVlRKTTF2UlJzVE8xS1Y4dTVHVzFmVUt5VGllR09ib3BqV3dWZFlH?=
 =?utf-8?B?SnVHZS9LeWZRTUJpL1QrZThwb3JJMmovWUFYOHp0SnZHVE9GQUVhT2FYV2Ir?=
 =?utf-8?B?aS96YW5IUWppUWVMZ3R3Nm1Hb1Vwc3lJejBYendaVXdMY04zVXRjT2htdHVL?=
 =?utf-8?B?SXRCUERqRUh3RGphcDJLNFJSVjFOL1R5dk16cGkyR3FLajg1anY3ODVkcE9v?=
 =?utf-8?B?NHhPS0kwZ2FRVEt1OUtzM1ZjRlF3Lzd6OGM3aWtpSGFiM0V4QUtacGJsNXl2?=
 =?utf-8?B?OWJoTEc0alp4SDg2U1Y2YUx6dXJTUTdRQm9UN09BOXlZNW1DUG9sNlRoMm9o?=
 =?utf-8?B?b21hY0VDdzQ1WmZiUkh4ckxnZXorNDJRRFhNK1dvZGdpeHhxazlrSVBTWTJ0?=
 =?utf-8?B?K1FBcXhOZDV3RjFOUWdjY3BmU2NXd2liaWJ4ak5Oek9WQjc0eU1FeWFRM2Jy?=
 =?utf-8?B?Tk1ZRVdWMmZiNEdoOG5XS3NCbmYzTlJnN2hDRHRIam15SkdsRitjUmdWNUVO?=
 =?utf-8?B?U1pYQUdnTGdiWG9wMFhIeE5WMCtmVnNFaDhjcEJSb2l0QTVYRXlvN0hDM2VT?=
 =?utf-8?B?bk55allTS09BPT0=?=
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)(82310400026)(7416014)(376014)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jun 2025 16:14:36.0080
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: a8d242c3-8b10-49ae-b954-08dda382e645
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:
	DS1PEPF0001708F.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6133

On 2025-05-29 18:40, Teddy Astie wrote:
> Hello Christopher,
> 
> Le 28/05/2025 à 23:13, Christopher Clark a écrit :

>> +## Argo and VirtIO
>> +
>> +References to design documentation for the development of an Argo
>> +transport for VirtIO are available via:
>> +https://wiki.xenproject.org/wiki/Virtio_On_Xen
>> +
> 
> Are there news regarding this ?
> 
> There is work done on virtio-msg [1], which looks fairly similar to
> virtio-argo (or at least, virtio-msg could work with Argo in a similar
> fashion to what's described on the virtio-argo design).
> 
> [1] https://linaro.atlassian.net/wiki/spaces/HVAC/overview

I think this should be dropped.  We don't need a link to a design 
document without an implementation.  You can add it once you've 
upstreamed the implementation.

>> +# Known issues
>> +
>> +* For development: sysctl/domctls for toolstack to control per-VM access
>> +  to Argo
>> +
> 
> Is it regarding disabling the argo on a per-guest basis, or regarding if
> a specific VM can communicate with another VM ? i.e can the toolstack
> decide to prevent 2 guest from communicating ?
> 
> IIRC, in Argo, a guest on his own can decide who can communicate with
> him using separate registered rings. But I am not sure if there is more
> on that regard.

Yes, I think the existing text needs to be rephrased to be more explicit 
on the issue.  I can guess what it is, but I shouldn't have to.  I'd 
recommend stating the issue as it exists, and then optionally clearly 
state a proposed solution.

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 17:41:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 17:41:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005785.1385150 (Exim 4.92)
	(envelope-from )
	id 1uMs6b-0005Mn-UI; Wed, 04 Jun 2025 17:40:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005785.1385150; Wed, 04 Jun 2025 17:40:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMs6b-0005Mg-RS; Wed, 04 Jun 2025 17:40:49 +0000
Received: by outflank-mailman (input) for mailman id 1005785;
 Wed, 04 Jun 2025 17:40: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 1uMs6Z-0005Ma-Vh
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 17:40:47 +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 0b929c18-416b-11f0-a300-13f23c93f187;
 Wed, 04 Jun 2025 19:40:46 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3a4e742dc97so821001f8f.0
 for ; Wed, 04 Jun 2025 10:40:46 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a4f00a0146sm22614053f8f.93.2025.06.04.10.40.44
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 04 Jun 2025 10:40:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0b929c18-416b-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749058845; x=1749663645; 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=V+jg+denqzEfVkfGkQz8sgF5eavw0as2hMWRK9MVLj4=;
        b=qwF+Bu0GoP4M+dq4NN/4/IGSHQrv48JpwdxfHD/XHsXVjDU8JyGhNGc8GMErn31gpN
         IBnbrhayhNpd89GMtZ1iCsygtg8CpX1b/ssd2vMHCmtzs4pUuWsfEntBKdJl7dBc84aH
         +zcEth80Q3a32GrDj8nSaXwcja0zbMX2/Od4I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749058845; x=1749663645;
        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=V+jg+denqzEfVkfGkQz8sgF5eavw0as2hMWRK9MVLj4=;
        b=ToJqxMHXBkzX2M33oplW2fZP+ws+FSSTUW9CiiVsN2IDqeg8LRcKvCN0vFJ9oIbK03
         l8RuxYXxtowTBLxORNeDfRSU7pKnyms1ksGrHaD+0lQuGwNPq2NDdsvidzrcjadTD66W
         GceMgwOfw3HEwA68Zcxnthtks/0kStYgvTB4pvV9tLRc5zSsYuepDCM5ftJnqjYYW5WJ
         Q5nWeqx48E/IVoMzeJUjY6Fbn6HAQwehAJsHdOmnzOf5vNGJ+gXbq82J/ndoQ6g4rdv1
         to+dUgRRJ4LIf9NwmyaNUwuX+upQbTO+ab+sA3or/gq+BWo/PNmsXgsFYPiOETZ1stQf
         FktQ==
X-Gm-Message-State: AOJu0Yw7HgSH/9EvVXP9yfk0EyW+dvBz5WKsmdDEJu1pVJCDA3VuAslf
	kUh0O6tMlqeTQK/WJNUi+CYszvvOobnTTqt6BI/qPWLNZU9Z/G35upmYLUm5Kvm4EUY=
X-Gm-Gg: ASbGnctELqUhpBMtOTmtOoGwvhpB8wqeXLFUvOrjqbwdUzaeRf0uklBun8zFaK+6NFF
	kdAmrD3VWPXc/d7iub35LvJRxuupRhQFlCyrGap07sRyrRn4JpEppcAxg63PSmx3YBTgkVA5LKK
	u1Ay3oZFB2W6gqwNTv9gsE5HzaT47dmoI2pNPsgbx50/JLYsQIBbPa3UYP6t44RgdFF2g0KPJCM
	j4VxzYSwIgb3O7f9EhycC9CLK3eIXTTlsp8vKHHBaoUMNUm8h3WU68Q5A4sUSYCiNmdFWIzd+D2
	4CB1eLxdTC7MteDEl4rJUBXnlxIGqS5rzSb1iZi1N5oWy/NCwzgYCggfaB0zd8VGpZd0WuwAsmF
	1OkrmDt1udPW5jL1n94qTfBthjxZnhx5u494=
X-Google-Smtp-Source: AGHT+IHIC34fFJ86M0nj6jj9jGVFs4Fc3FMQJG0lWKy1SYo19b/7TEGpJRNNgSFqpIxZagpErZA6JA==
X-Received: by 2002:a05:6000:240a:b0:3a5:1360:6b34 with SMTP id ffacd0b85a97d-3a526dc524cmr395659f8f.2.1749058845530;
        Wed, 04 Jun 2025 10:40:45 -0700 (PDT)
Date: Wed, 4 Jun 2025 19:40:44 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Christopher Clark 
Cc: xen-devel@lists.xenproject.org,
	Daniel Smith ,
	Rich Persaud ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v3 2/3] MAINTAINERS: add link and keyword statements for
 Argo section
Message-ID: 
References: <20250528211040.10562-1-christopher.w.clark@gmail.com>
 <20250528211040.10562-2-christopher.w.clark@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250528211040.10562-2-christopher.w.clark@gmail.com>

On Wed, May 28, 2025 at 10:10:39PM +0100, Christopher Clark wrote:
> Add link to Argo documentation and to ensure that Argo maintainers and
> reviewers are included in developments involving Argo, add keyword
> expressions for Argo.
> 
> Signed-off-by: Christopher Clark 
> ---
>  MAINTAINERS | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c11b82eca9..697f383505 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -223,9 +223,12 @@ F:	tools/libacpi/
>  ARGO
>  M:	Christopher Clark 
>  S:	Maintained
> +W:	https://wiki.xenproject.org/wiki/Argo:_Hypervisor-Mediated_Exchange_(HMX)_for_Xen

Could this be moved somewhere else?

The wiki is in a very bad state, with an increasing amount of stale
content.  It would be better if documentation linked here is in a more
controlled (ie: reviewed) place rather than a wiki that can be
modified by an unknown number of users.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 17:43:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 17:43:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005790.1385160 (Exim 4.92)
	(envelope-from )
	id 1uMs9D-0005sS-Aa; Wed, 04 Jun 2025 17:43:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005790.1385160; Wed, 04 Jun 2025 17: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 1uMs9D-0005sL-7w; Wed, 04 Jun 2025 17:43:31 +0000
Received: by outflank-mailman (input) for mailman id 1005790;
 Wed, 04 Jun 2025 17: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 1uMs9C-0005sE-OT
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 17:43:30 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20629.outbound.protection.outlook.com
 [2a01:111:f403:2413::629])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6c25ba31-416b-11f0-a300-13f23c93f187;
 Wed, 04 Jun 2025 19:43:29 +0200 (CEST)
Received: from MN0P220CA0014.NAMP220.PROD.OUTLOOK.COM (2603:10b6:208:52e::6)
 by SA3PR12MB9090.namprd12.prod.outlook.com (2603:10b6:806:397::11) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Wed, 4 Jun
 2025 17:43:25 +0000
Received: from MN1PEPF0000ECD4.namprd02.prod.outlook.com
 (2603:10b6:208:52e:cafe::49) by MN0P220CA0014.outlook.office365.com
 (2603:10b6:208:52e::6) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.29 via Frontend Transport; Wed,
 4 Jun 2025 17:43:25 +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.8792.29 via Frontend Transport; Wed, 4 Jun 2025 17:43:25 +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 Jun
 2025 12:43:24 -0500
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, 4 Jun
 2025 12:43:24 -0500
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; Wed, 4 Jun 2025 12:43:23 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6c25ba31-416b-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=EAurE/NfrFDnUoj9yQt7MLEN0l7XDyAqIcjxt6WLVuOmvuQCOAYrbVU53NzC/bEsNpmRDHECBMhS+X0UzxNuUXVLDeM5v2gc5vUbOglE8uyJgF0DT3jS/CuZQeSjmHbp8yw0MGu84Vpkn5l7Fbdo1TzvnY5WoXRcYsI0En1ETj2Gmk/8UIB+N4nlh6iL1kgJswAhbmYJu2QmLa2IuBEse8OleunlhCLWvZfY1CE3+l2TxhVxQZv5y9gDH00Rw998oMQ+zmJeXVqV6OzgNFgJ4hDpKvjgPLmfrofZTd6e1SB+hxJHOCi7LjF5JNIE/krofeih46Vgdmt80VS81IIdNw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=A8XJKa5ucdD1VpelyUTvJ+5t2YHb/OgWCnHOLZ/1bxc=;
 b=f2414hx5RDKOSj49qJHOfwj1l2WRegu9KsyV2L2HXwRq81KNaNE8/Gl99jkbPrmb3TGE1SmiW8CXyN/T0GUZ1cQHYqMoz+cqBC6Dmpwt01IXuTusHHqcfaL6Dvh77LQOlzWwslsSq1iWhKuA9/+qvFL4YO0HL+KXeOa6XEZvOGpeRnqxU+DLRH9UOAhG0OjVr2O44dh5WWzqr+eeHD7ehhJlQ0UMKAN+6qij8jAyWHQGA1CO8mCsaXra49cD1AMjvxoINWBhyh3C5dACR8cuPQCpW8xZ2VtVmK/f5QxPq7kUDo6htfXxgO0tfGWE5s20/5zI+acWH++s3jZ2FEfTvA==
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=A8XJKa5ucdD1VpelyUTvJ+5t2YHb/OgWCnHOLZ/1bxc=;
 b=y8NNwkFr+PDpZqzRbVdoTEZW7o85eRUiGn/WeWHEWcQxdOCpDwE63jZV4AlubICAXTTebtJPxkDaOoaxs6kOYAFfttD7yONnuG2jACGUlHuGBM4XNKaGm292IAI8raVyQR3wLGiU1tlP82bKArE4CJBgPs+/HATRlHSUocW5z58=
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 v1 1/3] arm/mpu: Introduce MPU memory region map structure
Date: Wed, 4 Jun 2025 18:43:09 +0100
Message-ID: <20250604174311.754899-2-ayan.kumar.halder@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20250604174311.754899-1-ayan.kumar.halder@amd.com>
References: <20250604174311.754899-1-ayan.kumar.halder@amd.com>
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: MN1PEPF0000ECD4:EE_|SA3PR12MB9090:EE_
X-MS-Office365-Filtering-Correlation-Id: 7a750a83-388f-4582-ca85-08dda38f4eb4
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?NWZyFpugRLQ/eSaJH9AIsvwQ3Eap2W2+4fYU1MW/cRqPMwpaXSRZAwCFWHHu?=
 =?us-ascii?Q?1Aj+4FUfMGNBFGzCfpiSg541XkIXFYD7DwevGvjC98mNRGyiuq3OSLn+TfwD?=
 =?us-ascii?Q?X0xGKgaGHHN0U7DIxUXUlFn2FN4hxMbZjHqetJBLcurjCWnviAPN0vxLDl0G?=
 =?us-ascii?Q?Hjq4/ubInz3MaA9L0TN+MPWngIWglw7ADWyvA7oH/mrXcVt41tajbiAD0nPI?=
 =?us-ascii?Q?gRf+Kjih4ANFdQvLSCYtdPzno8oD432IX7hCeF3wrPMqiSb673In1ZDb237o?=
 =?us-ascii?Q?s3YA3sseNJaRMeuWKavpFywvyGVOPxb5pxo/pg1teDEWp7wtxuvQB0AHfXPO?=
 =?us-ascii?Q?OWrb0d80npxIf9AZPUdjMGVUchqajkJMC7dNR3YFZkOz5YNPMXQthpfIkLu3?=
 =?us-ascii?Q?10Wxta+tIlpI3/3Fu44VUK4CV5p7j9zuHhXJ7/twQ+oobolxUzP2v3RZt24X?=
 =?us-ascii?Q?kCMtKcbC/w3QXaRCL2OJFzHKxGB70Qe75swp1CPHIoc4+hcNb7m+Fp+L6vsC?=
 =?us-ascii?Q?XkeTftEHNxl4xeGvUQ8iAdk+1zdxdfk40GssWU+XWwmUQbcaY2GYmbPURQaA?=
 =?us-ascii?Q?FhIqmTgIxBJeKUtJ28TfMe12ekyl32CxqdPU6cMytPxKLhc2rDa8Tniwduix?=
 =?us-ascii?Q?huZ+oHwPLi0nf7iJCZN5KxU8NNqiTtjHFYRrNmmlS8evhzbOEJ5r5qLNSRDU?=
 =?us-ascii?Q?BFb0s2MTHAaL8hkpOvCHAXwBEeEafg4mSCtm5P8hE5J7hWg2BHk0rwkrRQi6?=
 =?us-ascii?Q?Xw1NDBiXsbawdLa58/vlHRnlgcSwctXbylCYfTplHFj9Tz5p6WowANIr4cp8?=
 =?us-ascii?Q?0ozFDslF7N+kI8UaftV5ldHQerSf1dVmTD7zSOhbftwQfVSF/+x1q6UL6ehX?=
 =?us-ascii?Q?n8FhGMfZEAjNQQx/g2yDf5mGDbNPa5gnvyzZj/Taydpmoik8Er8yP3pYdtWD?=
 =?us-ascii?Q?zJS4ii6wd1BweymlFtKlS38msK521dbaRIqQha87X6+s8xge/yMbXDLQv+XS?=
 =?us-ascii?Q?KV2tMHMitkify2xkCzJfMv6ig892kbrGpPG4DR1eCVd08kqAzAcswQ6Rzosh?=
 =?us-ascii?Q?+zVx54Te35L57pTTbkI8Gwi5Sm1jYDJIvNWxUjBgwdwZ8ejazK48IomljNlf?=
 =?us-ascii?Q?SR3LhuCYXIpgFGaNjpZpCie+ZOkRbfkXxPEhLyGDdsWwN1ZjrcAH7FPLiJ43?=
 =?us-ascii?Q?Ov1mHFy3sl+sAsT33UNlrzJ+7R1o4559fXqvrMqrE2UTaOfw4iV4nzUhyDUn?=
 =?us-ascii?Q?QFgErqb8RurOKDrqK1OC9ZveNBns7afFwNvK62VyPU61nDEgUzQXU6vMZ5W4?=
 =?us-ascii?Q?UCqb8cFmoieKAtldL6noftA0vYhmQjo1YVLj+z2ZMYpekhkiZUHgsIXUdUec?=
 =?us-ascii?Q?f+u84jLQ/jH6PuCpOQXoWn74ZLCEC9WKueuF9XSwQkwoisWxHZeBLjxpY1Z/?=
 =?us-ascii?Q?uavaJgD5MO+JycnWyaDp6ncE6WVC6ufs5BP7W+6wHyDNHQ1qGJ3DpCojiQBx?=
 =?us-ascii?Q?2nrnzDafEumhg+v2Qj/LnL+WvO46BPU46zn2?=
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: 04 Jun 2025 17:43:25.2104
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7a750a83-388f-4582-ca85-08dda38f4eb4
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: SA3PR12MB9090

Introduce pr_t typedef which is a structure having the prbar and prlar members,
each being structured as the registers of the AArch32 Armv8-R architecture.

Also, define MPU_REGION_RES0 to 0 as there are no reserved 0 bits beyond the
BASE or LIMIT bitfields in prbar or prlar respectively.

Move pr_t definition to common code.
Also, enclose xn_0 within ARM64 as it is not present for ARM32.

Signed-off-by: Ayan Kumar Halder 
---
 xen/arch/arm/include/asm/arm32/mpu.h | 30 +++++++++++++++++++++++-----
 xen/arch/arm/include/asm/arm64/mpu.h |  6 ------
 xen/arch/arm/include/asm/mpu.h       |  6 ++++++
 xen/arch/arm/mpu/mm.c                |  2 ++
 4 files changed, 33 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/include/asm/arm32/mpu.h b/xen/arch/arm/include/asm/arm32/mpu.h
index f0d4d4055c..ae3b661fde 100644
--- a/xen/arch/arm/include/asm/arm32/mpu.h
+++ b/xen/arch/arm/include/asm/arm32/mpu.h
@@ -5,11 +5,31 @@
 
 #ifndef __ASSEMBLY__
 
-/* MPU Protection Region */
-typedef struct {
-    uint32_t prbar;
-    uint32_t prlar;
-} pr_t;
+#define MPU_REGION_RES0       0x0
+
+/* Hypervisor Protection Region Base Address Register */
+typedef union {
+    struct {
+        unsigned int xn:1;       /* Execute-Never */
+        unsigned int ap_0:1;     /* Acess Permission */
+        unsigned long ro:1;      /* Access Permission AP[1] */
+        unsigned int sh:2;       /* Sharebility */
+        unsigned int res0:1;     /* Reserved as 0 */
+        unsigned int base:26;    /* Base Address */
+    } reg;
+    uint32_t bits;
+} prbar_t;
+
+/* Hypervisor Protection Region Limit Address Register */
+typedef union {
+    struct {
+        unsigned int en:1;     /* Region enable */
+        unsigned int ai:3;     /* Memory Attribute Index */
+        unsigned int res0:2;   /* Reserved 0 by hardware */
+        unsigned int limit:26; /* Limit Address */
+    } reg;
+    uint32_t bits;
+} prlar_t;
 
 #endif /* __ASSEMBLY__ */
 
diff --git a/xen/arch/arm/include/asm/arm64/mpu.h b/xen/arch/arm/include/asm/arm64/mpu.h
index f0ce344e78..df46774dcb 100644
--- a/xen/arch/arm/include/asm/arm64/mpu.h
+++ b/xen/arch/arm/include/asm/arm64/mpu.h
@@ -34,12 +34,6 @@ typedef union {
     uint64_t bits;
 } prlar_t;
 
-/* MPU Protection Region */
-typedef struct {
-    prbar_t prbar;
-    prlar_t prlar;
-} pr_t;
-
 #endif /* __ASSEMBLY__ */
 
 #endif /* ARM_ARM64_MPU_H */
diff --git a/xen/arch/arm/include/asm/mpu.h b/xen/arch/arm/include/asm/mpu.h
index 8f06ddac0f..c8573a5980 100644
--- a/xen/arch/arm/include/asm/mpu.h
+++ b/xen/arch/arm/include/asm/mpu.h
@@ -25,6 +25,12 @@
 
 #ifndef __ASSEMBLY__
 
+/* MPU Protection Region */
+typedef struct {
+    prbar_t prbar;
+    prlar_t prlar;
+} pr_t;
+
 #ifdef CONFIG_ARM_64
 /*
  * Set base address of MPU protection region.
diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
index 86fbe105af..2fb6b822c6 100644
--- a/xen/arch/arm/mpu/mm.c
+++ b/xen/arch/arm/mpu/mm.c
@@ -167,7 +167,9 @@ pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags)
     /* Build up value for PRBAR_EL2. */
     prbar = (prbar_t) {
         .reg = {
+#ifdef CONFIG_ARM64
             .xn_0 = 0,
+#endif
             .xn = PAGE_XN_MASK(flags),
             .ap_0 = 0,
             .ro = PAGE_RO_MASK(flags)
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Wed Jun 04 17:43:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 17:43:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005791.1385171 (Exim 4.92)
	(envelope-from )
	id 1uMs9H-00067m-J8; Wed, 04 Jun 2025 17:43:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005791.1385171; Wed, 04 Jun 2025 17: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 1uMs9H-00067E-FN; Wed, 04 Jun 2025 17:43:35 +0000
Received: by outflank-mailman (input) for mailman id 1005791;
 Wed, 04 Jun 2025 17: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 1uMs9F-0005sE-UU
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 17:43:33 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20611.outbound.protection.outlook.com
 [2a01:111:f403:2412::611])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6e694e76-416b-11f0-a300-13f23c93f187;
 Wed, 04 Jun 2025 19:43:33 +0200 (CEST)
Received: from SJ0PR03CA0036.namprd03.prod.outlook.com (2603:10b6:a03:33e::11)
 by CY3PR12MB9654.namprd12.prod.outlook.com (2603:10b6:930:ff::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Wed, 4 Jun
 2025 17:43:29 +0000
Received: from MWH0EPF000A6733.namprd04.prod.outlook.com
 (2603:10b6:a03:33e:cafe::e4) by SJ0PR03CA0036.outlook.office365.com
 (2603:10b6:a03:33e::11) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.19 via Frontend Transport; Wed,
 4 Jun 2025 17:43:29 +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.8792.29 via Frontend Transport; Wed, 4 Jun 2025 17:43:28 +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; Wed, 4 Jun
 2025 12:43:27 -0500
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, 4 Jun
 2025 12:43:27 -0500
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; Wed, 4 Jun 2025 12:43:26 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6e694e76-416b-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=aSvUND22+qfx6ALYMGRDOttp8LIF4MLG2jr0A0BDJH5OU/5dj/0zg8o78FhGSSvIrMyoWI1eq7RTo9DxZwsKooJEjExk8NU6QMowZh4U1sgnxLTVngbtWUui1/v4J5P8S+H52Yfdhj1BZaAS3OsJ68b58aULoEedqGzUSWRrAeL+dTnIZaRNQpBYc3x2gHDoXgmgl5/py2zWXYG6TGz9VoREV0k2chmi2nf1EjfV6/VBCFWcs2KK3aiIa3ZqhfNGFE/AuBfv4/lJ6d8I1lwaP1uNOzK6x0KL8qaNJ+K4ph9i+VVTgPa+mhYT8PEJqNI6yU021BhYuhX8eNzkDhwOyg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=YWnqUpJPAtydCWvyxSfMnnr9qFnPiUp527yPVVPPBQ0=;
 b=IR5mlJDtXIpv8Q7VqUH4DmAzaoML38rXK6U+u4PftMVgnfOa9eTyNZ6Kh72trcHTqROmjYphTL5X1W1yMMzmskH3UCnM11IjRAp/vb62/Q3Ty15HKsw6/IzDbOuODZUD8yvWNce5h1l2tH5xrU+vimFX1PkjatXqah2OELyapLIx1wZyblSWIbb5mPsY+m3Gc+zcJLLX0OLoa/1tONOYwcw3mokfWt6aoWhyw2CE37lGuLpSqEukp0S7Pe3ZPfOclHVyrcMNquUa+rxBm2QBCEEB+mtgvGlAFSLvwHZueL04aMrooAA2nfX2GvPeQ2Krc1NevHqCtmKMnmZnUtxkhQ==
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=YWnqUpJPAtydCWvyxSfMnnr9qFnPiUp527yPVVPPBQ0=;
 b=XD+tYhaSQuvL64GMDBzS3ncc0S+pQvwFCkFli1+rgqiz+mu+SM8kbvdnseLOJMsFEOIcXf6lHzDoGfy0AaOZ9l/KKDI2CQfLolimVljjwLBqVXvXzzXLWX75jpDfLaVm8iM3SNIQzVFDpp6SC7WQMGsViFLi0yu/9nHeLc5HPWQ=
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: Ayan Kumar Halder , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" 
Subject: [PATCH v1 2/3] arm/mpu: Provide and populate MPU C data structures
Date: Wed, 4 Jun 2025 18:43:10 +0100
Message-ID: <20250604174311.754899-3-ayan.kumar.halder@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20250604174311.754899-1-ayan.kumar.halder@amd.com>
References: <20250604174311.754899-1-ayan.kumar.halder@amd.com>
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: MWH0EPF000A6733:EE_|CY3PR12MB9654:EE_
X-MS-Office365-Filtering-Correlation-Id: 2dcee06d-0e5c-4b2f-8496-08dda38f50ab
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?OzNTRaEhXNZKAefPWDRhRLLDkl+pLNLzM9E8vvZSIjlFW4D3VBqr4+P7aK9y?=
 =?us-ascii?Q?bzVJxA8whYyMBFfJTwMdUB33HvofiAZ88OVZKXmZJSXTU+qutyDQCwcdnh7f?=
 =?us-ascii?Q?1zKvkTe65cQPkauiB5ek6jg0NIQ3KvRJo2Hhs/B57b1jXZVNg/g6n+RpRZbY?=
 =?us-ascii?Q?0hIBhwxjN0S8YmQ0YO1Wkd9OX5/DDmIIA2N854eKFzOp8hEfXzZAzpr9Z/Ke?=
 =?us-ascii?Q?4ieE2UMKVwVhKyyVpQoDcEWJh3DnYkqZy55siA/m1FQxMSWyUN2uOS+uJXLG?=
 =?us-ascii?Q?TXcd2Zwn76VGU67ncdPs4SnTEGRuTcukVKSWUwrozFXm0+RS0wpuzLGzS7Hz?=
 =?us-ascii?Q?Fkz0Yvo5jA31ABY/7RR9Oy4vZkW2wR/za2uikOlh28tP3MdK29RbtFIy76zy?=
 =?us-ascii?Q?oBbpX+oA0bS1qo5YVk3Xb2apUITFO7vsDWt/gUCcxI4zJuiF4Z31VfSY1dUf?=
 =?us-ascii?Q?RZMFcscc0ZvqCsommsvLZAi07kGqNNyiI3kQKxcckjl+bhfs2N0l8ozbqKAl?=
 =?us-ascii?Q?9N9mUXQmuHbke/ls2X6sxEIkQfqGwGjQDTJ/e0SIo5Sz2NjfQoV6qG8fstQi?=
 =?us-ascii?Q?3iDCTZUm1St7mqTZYYqQqe9yqR798vmnpgMTfleQpIWb314m7rE+ryTwdZkA?=
 =?us-ascii?Q?CwNVN8S+mGTK9DKBz5PUO77KJUU8rud5aMLbyJeysB6D72SqdJmqtiHaiZin?=
 =?us-ascii?Q?vU6RtkYqgpg89p9rsV6w1M69PMt3i+Pek2yqIHqUl2G6tFNI4/CPwUeJlVqA?=
 =?us-ascii?Q?nJtu40qB5Wx2ZFIq/oeRlI1gT7FHu/a9O8KHt28RKbXlBxGqKQWoHroN3dJv?=
 =?us-ascii?Q?qfVdzs6lMw5j8VhAI0mQgMxbvacH55GX0qC0I5khJODZkYASyBK/RHgwvNo6?=
 =?us-ascii?Q?u9FweFzfDSdi+YR8TFyXxYldoJmRo6Kn1Wsh59dLgVt+hEr5y5LLtRxukF3R?=
 =?us-ascii?Q?2iDNklrn5TRe22zltP6qMEeXSCzxhvr+UtZsPn5QgWxrZIHc8JgPRXO+hXOj?=
 =?us-ascii?Q?rYlwZVkysmvtcF6CD8fd8T6P4eG1TlP+VcH8yhgE8LlL/W6I/7AGsa8xDxnx?=
 =?us-ascii?Q?IS1XoiVZQAkSvl0lJc8lDgderIU/wS7VFUqZtQ4Bj1SQJNHYKGKayEutHPs8?=
 =?us-ascii?Q?XKGDZfj+DlOuP0tO3vd2CeaD0wWU7IkydZ+7eyAafqeNlHZlV7EsihgzULDP?=
 =?us-ascii?Q?5ij3Q7uoSRLDFQ6gNmV0LktHAYj4ZbEDvpBSxQdhtHTfuziVx2k/V2Flr5lw?=
 =?us-ascii?Q?MQ869j78x0UlKsVnLhHZlDI7Xb9RGtOtZwfBc0HqhrUU9ymYxt/VRP7NiiyT?=
 =?us-ascii?Q?ZwOVeMQBidheUcaDbFCHADB02SSAKtb0hf5oB4vhj0hQ5XIUJm2dYOQQeokn?=
 =?us-ascii?Q?oCcK+9u4nvydyJmnWndtKFTrFVVzZCA87+7FKiK6y6dJuJW3/iRStg4pCH3j?=
 =?us-ascii?Q?J+/uYDzLZXTcvgR3/zWaHO0cENyL9EAPPKCggRAOF0W4JXWeI0rjkl4r4Wjl?=
 =?us-ascii?Q?XoYINkZltqYBDMb6mWfGBL8LZTPJQnkbWjNS?=
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)(82310400026)(36860700013)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jun 2025 17:43:28.4076
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 2dcee06d-0e5c-4b2f-8496-08dda38f50ab
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: CY3PR12MB9654

Do the arm32 equivalent initialization for commit id ca5df936c4.

Signed-off-by: Ayan Kumar Halder 
---
 xen/arch/arm/arm32/asm-offsets.c         |  6 +++
 xen/arch/arm/arm32/mpu/head.S            | 57 ++++++++++++++++++++++++
 xen/arch/arm/include/asm/mpu/regions.inc |  8 +++-
 3 files changed, 70 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/arm32/asm-offsets.c b/xen/arch/arm/arm32/asm-offsets.c
index 8bbb0f938e..c203ce269d 100644
--- a/xen/arch/arm/arm32/asm-offsets.c
+++ b/xen/arch/arm/arm32/asm-offsets.c
@@ -75,6 +75,12 @@ void __dummy__(void)
 
    OFFSET(INITINFO_stack, struct init_info, stack);
    BLANK();
+
+#ifdef CONFIG_MPU
+   DEFINE(XEN_MPUMAP_MASK_sizeof, sizeof(xen_mpumap_mask));
+   DEFINE(XEN_MPUMAP_sizeof, sizeof(xen_mpumap));
+   BLANK();
+#endif
 }
 
 /*
diff --git a/xen/arch/arm/arm32/mpu/head.S b/xen/arch/arm/arm32/mpu/head.S
index b2c5245e51..1f9eec6e68 100644
--- a/xen/arch/arm/arm32/mpu/head.S
+++ b/xen/arch/arm/arm32/mpu/head.S
@@ -10,6 +10,38 @@
 #include 
 #include 
 
+/*
+ * dcache_line_size - get the minimum D-cache line size from the CTR register.
+ */
+    .macro  dcache_line_size, reg, tmp1, tmp2
+    mrc CP32(\reg, CTR)           // read CTR
+    ubfx   \tmp1, \reg, #16, #4   // Extract DminLine (bits 19:16) into tmp1
+    mov    \tmp2, #1
+    lsl    \tmp2, \tmp2, \tmp1    // tmp2 = 2^DminLine
+    lsl    \tmp2, \tmp2, #2       // tmp2 = 4 * 2^DminLine = cache line size in bytes
+    .endm
+
+/*
+ * __invalidate_dcache_area(addr, size)
+ *
+ * Ensure that the data held in the cache for the buffer is invalidated.
+ *
+ * - addr - start address of the buffer
+ * - size - size of the buffer
+ */
+FUNC(__invalidate_dcache_area)
+    dcache_line_size r2, r3, r4
+    add   r1, r0, r1
+    sub   r4, r2, #1
+    bic   r0, r0, r4
+1:  mcr   CP32(r0, DCIMVAC)     /* invalidate D line / unified line */
+    add   r0, r0, r2
+    cmp   r0, r1
+    blo   1b
+    dsb   sy
+    ret
+END(__invalidate_dcache_area)
+
 /*
  * Set up the memory attribute type tables and enable EL2 MPU and data cache.
  * If the Background region is enabled, then the MPU uses the default memory
@@ -49,6 +81,10 @@ FUNC(enable_boot_cpu_mm)
     mrc   CP32(r5, MPUIR_EL2)
     and   r5, r5, #NUM_MPU_REGIONS_MASK
 
+    ldr   r0, =max_mpu_regions
+    str   r5, [r0]
+    mcr   CP32(r0, DCIMVAC) /* Invalidate cache for max_mpu_regions addr */
+
     /* x0: region sel */
     mov   r0, #0
     /* Xen text section. */
@@ -83,6 +119,27 @@ FUNC(enable_boot_cpu_mm)
     prepare_xen_region r0, r1, r2, r3, r4, r5, attr_prbar=REGION_DEVICE_PRBAR, attr_prlar=REGION_DEVICE_PRLAR
 #endif
 
+zero_mpu:
+    /* Reset remaining MPU regions */
+    cmp   r0, r5
+    beq   out_zero_mpu
+    mov   r1, #0
+    mov   r2, #1
+    prepare_xen_region r0, r1, r2, r3, r4, r5, attr_prlar=REGION_DISABLED_PRLAR
+    b     zero_mpu
+
+out_zero_mpu:
+    /* Invalidate data cache for MPU data structures */
+    mov r5, lr
+    ldr r0, =xen_mpumap_mask
+    mov r1, #XEN_MPUMAP_MASK_sizeof
+    bl __invalidate_dcache_area
+
+    ldr r0, =xen_mpumap
+    mov r1, #XEN_MPUMAP_sizeof
+    bl __invalidate_dcache_area
+    mov lr, r5
+
     b    enable_mpu
 END(enable_boot_cpu_mm)
 
diff --git a/xen/arch/arm/include/asm/mpu/regions.inc b/xen/arch/arm/include/asm/mpu/regions.inc
index 6b8c233e6c..943bcda346 100644
--- a/xen/arch/arm/include/asm/mpu/regions.inc
+++ b/xen/arch/arm/include/asm/mpu/regions.inc
@@ -24,7 +24,13 @@
 #define XEN_MPUMAP_ENTRY_SHIFT  0x3     /* 8 byte structure */
 
 .macro store_pair reg1, reg2, dst
-    .word 0xe7f000f0                    /* unimplemented */
+    str \reg1, [\dst]
+    add \dst, \dst, #4
+    str \reg2, [\dst]
+.endm
+
+.macro invalidate_dcache_one reg
+    mcr CP32(\reg, DCIMVAC)
 .endm
 
 #endif
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Wed Jun 04 17:43:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 17:43:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005792.1385180 (Exim 4.92)
	(envelope-from )
	id 1uMs9M-0006Oq-00; Wed, 04 Jun 2025 17:43:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005792.1385180; Wed, 04 Jun 2025 17:43: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 1uMs9L-0006Oj-Sk; Wed, 04 Jun 2025 17:43:39 +0000
Received: by outflank-mailman (input) for mailman id 1005792;
 Wed, 04 Jun 2025 17:43: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 1uMs9K-0005sE-LF
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 17:43:38 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on2060a.outbound.protection.outlook.com
 [2a01:111:f403:2414::60a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 71669a7a-416b-11f0-a300-13f23c93f187;
 Wed, 04 Jun 2025 19:43:37 +0200 (CEST)
Received: from BLAPR05CA0010.namprd05.prod.outlook.com (2603:10b6:208:36e::19)
 by DM4PR12MB5964.namprd12.prod.outlook.com (2603:10b6:8:6b::6) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8792.34; Wed, 4 Jun 2025 17:43:32 +0000
Received: from MN1PEPF0000ECD6.namprd02.prod.outlook.com
 (2603:10b6:208:36e:cafe::f8) by BLAPR05CA0010.outlook.office365.com
 (2603:10b6:208:36e::19) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.22 via Frontend Transport; Wed,
 4 Jun 2025 17:43: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.8792.29 via Frontend Transport; Wed, 4 Jun 2025 17:43:31 +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 Jun
 2025 12:43:30 -0500
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, 4 Jun
 2025 12:43:30 -0500
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; Wed, 4 Jun 2025 12:43:29 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 71669a7a-416b-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=aR+nXiwif367zRAg0TWdwfLBmb+T+51XrgREj9L+rNpmwB6FOcvfLj9rEqp5Yn4/6UYkMjtoMgJsxujMHxQDRpFG1eBJu0JoJMegTUDvB9aCxfYKW5y43QbO1wZLmgY7Pph9O+FOg2sfUU9UWkQQyTmIfWuHEhUZSqt2XwvKKxtVvVtnBKCSmICIRnfBdgnLiUvo8yUgNIF2OTed3sQIad0B/TaVyotpcARZy10feHmYkXfzyPZm630FmZQr+F210oru5Xhba5N9lCcC4JtxRhcavZwAxmSoLopJg03JimFmSTFCGc0RFV7PkCJiiiZSWmu/xsQ/zJAVhRrE9V9Myg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=8KI8E/qyLOB0LA8peY0GYGndGcJOK3jDcX0S5pyP3xs=;
 b=LPgaS5yxTyjDPPIAs+x3u4z07BxcgR86LCKgZtMXyvDufyKFruLSsC3hUxRLR24XD9ph73Pub9FQ3llAodmayXevWvSZU7XrdR6quj4w3pDYOkehLiRkbo+xEOf/s3Y3TD5+B980y+zlPhrtfjhO1MUmOWNtPbaY1XzDuxep/E5GzLSF5z7Z5DpJyKrpF5/bRgkJ/Fe76AAFQwiNo6vqfDfLkGGrVm0SUMEmetaQMT45PKdTmG/u6L+tAAmenpBn8kxRSZZ9Rh3xWwu6L0DlL360k5Z3D+u+I/fejx3U/YbTRy4fhCzJWWw9m4kWZ94/Ilx1SWy5N/aOZYN9H04kUg==
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=8KI8E/qyLOB0LA8peY0GYGndGcJOK3jDcX0S5pyP3xs=;
 b=5czGjaZGMquxt9rluCJrBcn7p7XNr8WghASnBjlGFrRrLN2caZv/WmvTClvcXNl+KrUPsB2RFwX+O5smeYXWqm7EHNIUn8T9IHTy3mjqw1rQBoEL/AQRPnP6hKOCF4DrrqYWJCZgdGLRQ1a0PHpM2IsoNtnJZwMCrQxNaBpT6iU=
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 v1 3/3] arm/mpu: Provide access to the MPU region from the C code
Date: Wed, 4 Jun 2025 18:43:11 +0100
Message-ID: <20250604174311.754899-4-ayan.kumar.halder@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20250604174311.754899-1-ayan.kumar.halder@amd.com>
References: <20250604174311.754899-1-ayan.kumar.halder@amd.com>
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: MN1PEPF0000ECD6:EE_|DM4PR12MB5964:EE_
X-MS-Office365-Filtering-Correlation-Id: b378e537-3325-477b-ee5e-08dda38f5250
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?HWZyI3vynkps4EEWpIagT4erp7YW9/BBaPbX8YTtYyq2DHG7T91ZR8tojCNZ?=
 =?us-ascii?Q?zAT03D0G4aoRtrlW+CYL3d9w4rgMYUc0ajPjRTTaI4Li799/1SzRiS6khVPg?=
 =?us-ascii?Q?tkGG6YtFq6jCKUHMmTohAdaNt1VUmvfUL1qeUeT7LEjQxaEpFziiiONUx/UY?=
 =?us-ascii?Q?oVXRISkW9u9m5V9IXUG6nquh5khXWjaWEFvFTWz2TAk4nC5QO2rS5B6NoIMF?=
 =?us-ascii?Q?zOd+r9HXPx4ey4NMt1iGlhEhNH/C6JwzqQ3Q4Dmaa/A6nTXM4or4Iaq3koDb?=
 =?us-ascii?Q?msVq8ueMy6li7eLbNyb/gIf06j0TsjKYQoL/Do7M9WQFMCPFkCJJw1TFG/fi?=
 =?us-ascii?Q?hb/iEEG5SjAwgQ0qdm2S+d33WFEp8dU5JaeOJOYDkMYQDIEUiivCk2iYfPz1?=
 =?us-ascii?Q?Mq+g9qYgr4OtlEbpxux6AmUjDMr7qTltrJ3biO9m2EHcnhgtJNmbuNy8rg5G?=
 =?us-ascii?Q?iozW/cHyqz6qIDqeF9fQUIdxMg6g06aCckmtgq1gAqXa+Ax4g5cqpua5jCxf?=
 =?us-ascii?Q?+gw9V6XnLbkE/SyxvzKF1SnhiOLFBjg7h4hrzY0q1ksZkOo+uHG2Gs78lHDK?=
 =?us-ascii?Q?qM+YHpnQt9dFy1ffKWCRAsw8VuKlzQdWl5oSObKfth8UZuuj8ikvB7hbW5HR?=
 =?us-ascii?Q?acnOVlt57oiAKWFzGc5wJ3sRpKt5aOrT9I083gwCKzOemm3U82nn1LtThH/7?=
 =?us-ascii?Q?/G4VBjOHcNWlo7HUn6nd56XkukY/FO5EG7yQ82fpCU4UsezgLXrK1yVzBQjF?=
 =?us-ascii?Q?ZwcM0zxlLfwfNhQM2BcR3CSf419Dtc8bBO+RVxmDz9LqpbHML/kefX0rzJHI?=
 =?us-ascii?Q?fEG5o6kkokzHBN1N1rNMgmdHA2mG6hgagvJgSALoVctV4/e6ZJBWgXPYF8QX?=
 =?us-ascii?Q?8qQgh2pmpawoETSXHQwevTcuVryaixhWT/96R49Op7zvw51/LOKVx8mYDP/e?=
 =?us-ascii?Q?xubsAsINBiNk+ilpaegItpb9jGhmeuQTu+QUa9K7nT/2bh2A7T8XgftF2fvT?=
 =?us-ascii?Q?BW374Ai0AQsLZMMj0S5FD2nj+8mRnH+/E5T59vDc/Mypui2kAbDdGmhF/aBL?=
 =?us-ascii?Q?ZQRy6N92hBzByRHpXc/pB71weDqocsJx8gnJPaEhESnO+CA7Cd3yhGzUjjgb?=
 =?us-ascii?Q?AmqolqK40gnX6LQENRD49LxEMwGG6vgRkC9ERfeAlhmARtXefLZrxLJp+/4X?=
 =?us-ascii?Q?B6NEs0u5VBniibmrAZNw4JAANIYFNVxnvn5hHPCOTmFFj3XfIInPTvZELkJL?=
 =?us-ascii?Q?sGEXcCsLfu3NcWLlVxk0ip26/s5fY2uCnkcgVop0UTfoGrWNEQDgxFB+B0gg?=
 =?us-ascii?Q?Iwgga+Q6W5aaIyepqlhQafJ8hRziOZEJ6NwIAUyDPfi9bq0uq1hfGhY8KM0x?=
 =?us-ascii?Q?0GxH8Zb+EPVMgpxOxaMPVFZ2eC1gr3dlU+xSVnDuPV3j3YF0ce2E/3xHtHJQ?=
 =?us-ascii?Q?KB1Fpm5NIrpi49DeRffQ8G++VWw7nO8Wi3OCvuLPz6onOHBzvvfDekXZhE6Y?=
 =?us-ascii?Q?OAmHfI44OP1CqDVW+NWA3aeZ4Ir0327vA7be?=
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 Jun 2025 17:43:31.2734
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b378e537-3325-477b-ee5e-08dda38f5250
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: DM4PR12MB5964

Enable the helper functions defined in mpu/mm.c and asm/mpu.h for ARM32.
Define the register definitions for HPRBAR{0..31} and HPRLAR{0..31}.
One can directly access the first 32 MPU regions using the above registers
without the use of PRSELR.

Also fix the register definition for HPRLAR.

Signed-off-by: Ayan Kumar Halder 
---
 xen/arch/arm/include/asm/mpu.h        |  2 -
 xen/arch/arm/include/asm/mpu/cpregs.h | 72 ++++++++++++++++++++++++++-
 xen/arch/arm/mpu/mm.c                 | 31 ++++++++++--
 3 files changed, 98 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/include/asm/mpu.h b/xen/arch/arm/include/asm/mpu.h
index c8573a5980..29f507ce3c 100644
--- a/xen/arch/arm/include/asm/mpu.h
+++ b/xen/arch/arm/include/asm/mpu.h
@@ -31,7 +31,6 @@ typedef struct {
     prlar_t prlar;
 } pr_t;
 
-#ifdef CONFIG_ARM_64
 /*
  * Set base address of MPU protection region.
  *
@@ -91,7 +90,6 @@ static inline bool region_is_valid(const pr_t *pr)
 {
     return pr->prlar.reg.en;
 }
-#endif /* CONFIG_ARM_64 */
 
 #endif /* __ASSEMBLY__ */
 
diff --git a/xen/arch/arm/include/asm/mpu/cpregs.h b/xen/arch/arm/include/asm/mpu/cpregs.h
index d5cd0e04d5..9f3b32acd7 100644
--- a/xen/arch/arm/include/asm/mpu/cpregs.h
+++ b/xen/arch/arm/include/asm/mpu/cpregs.h
@@ -6,16 +6,86 @@
 /* CP15 CR0: MPU Type Register */
 #define HMPUIR          p15,4,c0,c0,4
 
+/* CP15 CR6: Protection Region Enable Register */
+#define HPRENR          p15,4,c6,c1,1
+
 /* CP15 CR6: MPU Protection Region Base/Limit/Select Address Register */
 #define HPRSELR         p15,4,c6,c2,1
 #define HPRBAR          p15,4,c6,c3,0
-#define HPRLAR          p15,4,c6,c8,1
+#define HPRLAR          p15,4,c6,c3,1
+
+/* CP15 CR6: MPU Protection Region Base/Limit Address Register */
+#define HPRBAR0         p15,4,c6,c8,0
+#define HPRLAR0         p15,4,c6,c8,1
+#define HPRBAR1         p15,4,c6,c8,4
+#define HPRLAR1         p15,4,c6,c8,5
+#define HPRBAR2         p15,4,c6,c9,0
+#define HPRLAR2         p15,4,c6,c9,1
+#define HPRBAR3         p15,4,c6,c9,4
+#define HPRLAR3         p15,4,c6,c9,5
+#define HPRBAR4         p15,4,c6,c10,0
+#define HPRLAR4         p15,4,c6,c10,1
+#define HPRBAR5         p15,4,c6,c10,4
+#define HPRLAR5         p15,4,c6,c10,5
+#define HPRBAR6         p15,4,c6,c11,0
+#define HPRLAR6         p15,4,c6,c11,1
+#define HPRBAR7         p15,4,c6,c11,4
+#define HPRLAR7         p15,4,c6,c11,5
+#define HPRBAR8         p15,4,c6,c12,0
+#define HPRLAR8         p15,4,c6,c12,1
+#define HPRBAR9         p15,4,c6,c12,4
+#define HPRLAR9         p15,4,c6,c12,5
+#define HPRBAR10        p15,4,c6,c13,0
+#define HPRLAR10        p15,4,c6,c13,1
+#define HPRBAR11        p15,4,c6,c13,4
+#define HPRLAR11        p15,4,c6,c13,5
+#define HPRBAR12        p15,4,c6,c14,0
+#define HPRLAR12        p15,4,c6,c14,1
+#define HPRBAR13        p15,4,c6,c14,4
+#define HPRLAR13        p15,4,c6,c14,5
+#define HPRBAR14        p15,4,c6,c15,0
+#define HPRLAR14        p15,4,c6,c15,1
+#define HPRBAR15        p15,4,c6,c15,4
+#define HPRLAR15        p15,4,c6,c15,5
+#define HPRBAR16        p15,5,c6,c8,0
+#define HPRLAR16        p15,5,c6,c8,1
+#define HPRBAR17        p15,5,c6,c8,4
+#define HPRLAR17        p15,5,c6,c8,5
+#define HPRBAR18        p15,5,c6,c9,0
+#define HPRLAR18        p15,5,c6,c9,1
+#define HPRBAR19        p15,5,c6,c9,4
+#define HPRLAR19        p15,5,c6,c9,5
+#define HPRBAR20        p15,5,c6,c10,0
+#define HPRLAR20        p15,5,c6,c10,1
+#define HPRBAR21        p15,5,c6,c10,4
+#define HPRLAR21        p15,5,c6,c10,5
+#define HPRBAR22        p15,5,c6,c11,0
+#define HPRLAR22        p15,5,c6,c11,1
+#define HPRBAR23        p15,5,c6,c11,4
+#define HPRLAR23        p15,5,c6,c11,5
+#define HPRBAR24        p15,5,c6,c12,0
+#define HPRLAR24        p15,5,c6,c12,1
+#define HPRBAR25        p15,5,c6,c12,4
+#define HPRLAR25        p15,5,c6,c12,5
+#define HPRBAR26        p15,5,c6,c13,0
+#define HPRLAR26        p15,5,c6,c13,1
+#define HPRBAR27        p15,5,c6,c13,4
+#define HPRLAR27        p15,5,c6,c13,5
+#define HPRBAR28        p15,5,c6,c14,0
+#define HPRLAR28        p15,5,c6,c14,1
+#define HPRBAR29        p15,5,c6,c14,4
+#define HPRLAR29        p15,5,c6,c14,5
+#define HPRBAR30        p15,5,c6,c15,0
+#define HPRLAR30        p15,5,c6,c15,1
+#define HPRBAR31        p15,5,c6,c15,4
+#define HPRLAR31        p15,5,c6,c15,5
 
 /* Aliases of AArch64 names for use in common code */
 #ifdef CONFIG_ARM_32
 /* Alphabetically... */
 #define MPUIR_EL2       HMPUIR
 #define PRBAR_EL2       HPRBAR
+#define PRENR_EL2       HPRENR
 #define PRLAR_EL2       HPRLAR
 #define PRSELR_EL2      HPRSELR
 #endif /* CONFIG_ARM_32 */
diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
index 2fb6b822c6..9aea9fbacb 100644
--- a/xen/arch/arm/mpu/mm.c
+++ b/xen/arch/arm/mpu/mm.c
@@ -40,7 +40,10 @@ pr_t __cacheline_aligned __section(".data") xen_mpumap[MAX_MPU_REGION_NR];
 #define PRBAR_EL2_(n)   PRBAR##n##_EL2
 #define PRLAR_EL2_(n)   PRLAR##n##_EL2
 
-#endif /* CONFIG_ARM_64 */
+#else  /* CONFIG_ARM_64 */
+#define PRBAR_EL2_(n)   HPRBAR##n
+#define PRLAR_EL2_(n)   HPRLAR##n
+#endif /* !CONFIG_ARM_64 */
 
 #define GENERATE_WRITE_PR_REG_CASE(num, pr)                                 \
     case num:                                                               \
@@ -68,7 +71,6 @@ static void __init __maybe_unused build_assertions(void)
     BUILD_BUG_ON(PAGE_SIZE != SZ_4K);
 }
 
-#ifdef CONFIG_ARM_64
 /*
  * Armv8-R supports direct access and indirect access to the MPU regions through
  * registers:
@@ -85,6 +87,7 @@ static void __init __maybe_unused build_assertions(void)
  */
 static void prepare_selector(uint8_t *sel)
 {
+#ifdef CONFIG_ARM_64
     uint8_t cur_sel = *sel;
 
     /*
@@ -98,7 +101,8 @@ static void prepare_selector(uint8_t *sel)
         WRITE_SYSREG(cur_sel, PRSELR_EL2);
         isb();
     }
-    *sel &= 0xFU;
+    *sel = *sel & 0xFU;
+#endif
 }
 
 void read_protection_region(pr_t *pr_read, uint8_t sel)
@@ -123,6 +127,24 @@ void read_protection_region(pr_t *pr_read, uint8_t sel)
         GENERATE_READ_PR_REG_CASE(13, pr_read);
         GENERATE_READ_PR_REG_CASE(14, pr_read);
         GENERATE_READ_PR_REG_CASE(15, pr_read);
+#ifdef CONFIG_ARM_32
+        GENERATE_READ_PR_REG_CASE(16, pr_read);
+        GENERATE_READ_PR_REG_CASE(17, pr_read);
+        GENERATE_READ_PR_REG_CASE(18, pr_read);
+        GENERATE_READ_PR_REG_CASE(19, pr_read);
+        GENERATE_READ_PR_REG_CASE(20, pr_read);
+        GENERATE_READ_PR_REG_CASE(21, pr_read);
+        GENERATE_READ_PR_REG_CASE(22, pr_read);
+        GENERATE_READ_PR_REG_CASE(23, pr_read);
+        GENERATE_READ_PR_REG_CASE(24, pr_read);
+        GENERATE_READ_PR_REG_CASE(25, pr_read);
+        GENERATE_READ_PR_REG_CASE(26, pr_read);
+        GENERATE_READ_PR_REG_CASE(27, pr_read);
+        GENERATE_READ_PR_REG_CASE(28, pr_read);
+        GENERATE_READ_PR_REG_CASE(29, pr_read);
+        GENERATE_READ_PR_REG_CASE(30, pr_read);
+        GENERATE_READ_PR_REG_CASE(31, pr_read);
+#endif
     default:
         BUG(); /* Can't happen */
         break;
@@ -208,7 +230,9 @@ pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags)
     /* Build up value for PRLAR_EL2. */
     prlar = (prlar_t) {
         .reg = {
+#ifdef CONFIG_ARM_64
             .ns = 0,        /* Hyp mode is in secure world */
+#endif
             .ai = attr_idx,
             .en = 1,        /* Region enabled */
         }};
@@ -225,7 +249,6 @@ pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags)
 
     return region;
 }
-#endif /* CONFIG_ARM_64 */
 
 void __init setup_mm(void)
 {
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Wed Jun 04 17:43:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 17:43:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005793.1385191 (Exim 4.92)
	(envelope-from )
	id 1uMs9N-0006de-6h; Wed, 04 Jun 2025 17:43:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005793.1385191; Wed, 04 Jun 2025 17: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 1uMs9N-0006dS-34; Wed, 04 Jun 2025 17:43:41 +0000
Received: by outflank-mailman (input) for mailman id 1005793;
 Wed, 04 Jun 2025 17:43: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 1uMs9L-0006Ny-7b
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 17:43:39 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20615.outbound.protection.outlook.com
 [2a01:111:f403:2414::615])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6be5fd18-416b-11f0-b894-0df219b8e170;
 Wed, 04 Jun 2025 19:43:27 +0200 (CEST)
Received: from SJ0PR13CA0209.namprd13.prod.outlook.com (2603:10b6:a03:2c3::34)
 by MW6PR12MB8708.namprd12.prod.outlook.com (2603:10b6:303:242::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.37; Wed, 4 Jun
 2025 17:43:23 +0000
Received: from MWH0EPF000A6734.namprd04.prod.outlook.com
 (2603:10b6:a03:2c3:cafe::65) by SJ0PR13CA0209.outlook.office365.com
 (2603:10b6:a03:2c3::34) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.16 via Frontend Transport; Wed,
 4 Jun 2025 17:43:23 +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.8792.29 via Frontend Transport; Wed, 4 Jun 2025 17:43:23 +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 Jun
 2025 12:43:22 -0500
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 Jun
 2025 12:43:22 -0500
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; Wed, 4 Jun 2025 12:43:21 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6be5fd18-416b-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=H68oeu/z6rAq4buWBsxOwqDPA98ZZwlpC8qxn2u4X7DfEBgJ8nAuaaJ1F3CsneUikm3GvzdnExGhTz9aDLinUO4eE09HutvPVWmgJRdsfTLVljrd5Raj9hvuTvR8phqK5Yb8hSm9RhodV78FeSA2EAUT66EbDPmWMuZNPMTK8edXEqw8sZgBVA1r0TXs8XUXClJiGRMsInK6qYaNtR4jJ0gOWgLFCK6WdjfXiANi/BSujWb/GNOFcpMi4pcr3lE5HRuMqwGktupAtX13bLFeJAoZ6HQUuUABHi/Sf1Qq3BXAOD2PZxpu/M8Ml70XIiUhJkz3u3rJl/fSc5Wiz7/DDw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=P1sfToAZNlyRaxZJqcw3TzKgYq0CR67tXwv+x0v9c2w=;
 b=Og8QU7WNSsFtrBs+deiKcT4tjn1cE4HaU5q2drE935al9dh2+p/0PGohvULpeedLWGt6LyBef8C6Ff256iKqCGQXc49JOhEp19yb+V3ZT0e1BA09ZzDSanVZXrU3WI9Kg496h3vAJA5UXWrZXQotjGfEfsmuVO2HqVwIMo2xq+jBmL8WJne+NKKLHJQsin6F+h66bhdZ6+D2Bci3BUtYsEuTXhlDBKEPIuowwOHuU4sssujfL9jHUbRHK08XO1cFbiwGJGTEPiuN8WO6/WFaosHKqPQQxwVynXKlCaA/5Z5PBLXxKNA5h7arS7XvgjY/6JeK6kmUjq4If5fixS1vJA==
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=P1sfToAZNlyRaxZJqcw3TzKgYq0CR67tXwv+x0v9c2w=;
 b=0wrG6Xy3AxfWsiuEnf80Jck58ao9NH3TJBXd4q+hRf8DeqbGokNa8XVkMwIfFJcICrxJQuuwcy2Ce3kk8WhJ1NctD1h0YXE+JGwGqCRU9ubBb4zanGGcYvZlZoA5cJbUMVGUWoati/Tm80EpZXk7nJ5kkV31ZsI/kLATLB7JTZw=
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: Ayan Kumar Halder , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" 
Subject: [PATCH v1 0/3] Enable R52 support for the first chunk of MPU support
Date: Wed, 4 Jun 2025 18:43:08 +0100
Message-ID: <20250604174311.754899-1-ayan.kumar.halder@amd.com>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MWH0EPF000A6734:EE_|MW6PR12MB8708:EE_
X-MS-Office365-Filtering-Correlation-Id: cd44d750-94c4-4c39-ac69-08dda38f4d84
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?BD/FhesnOJoL8sE0rBOTtfBrt1Y5TPpxq9KEZwNlQgghtF5gNsHh+Jr6xTgi?=
 =?us-ascii?Q?HlxmVKvHMoiOYzVfxhEvL9G9nV0U5sMZrPeywE3DKiN5uVp2vkq4pRhq9gzD?=
 =?us-ascii?Q?P3vh5OI7UPHfpj4UntuoZhImAmPlpPalPHIsMTVKF3LeAkEmeLwjbK8U5cL+?=
 =?us-ascii?Q?4/Y0fc/XxFdFGgdwBoFp6gpGcPdzXxH3RMFsH0N9t82DLns2ppcFw/Bscq6A?=
 =?us-ascii?Q?eO+bjrRIzuMVJo1jat/X0uavUjuT4Ju8cyrXPKcNX2C3TABDxEHkK9qJU35H?=
 =?us-ascii?Q?n6HfteZc2PYwPKh5YXmxPlqROGKxn/GP48CUTDQlkCyywvC6D2DTb15bpoSl?=
 =?us-ascii?Q?lknoKf8Kcu09nv7Bfmn4a8FhViOZ/idJiouHjnQ4dsJBjZeNF/kXvxOnfzfe?=
 =?us-ascii?Q?HLtlj6Y81TBZLJuRne728xDOmEa0grOfVka6u8agBI2Ez6anfA1+apRR/FxF?=
 =?us-ascii?Q?eL99XQPgJ7KyKVCnzmhy+Kyq0uMy0PcsnepP9HZLv0BO+yZZt/hSfz3RyiWu?=
 =?us-ascii?Q?k3XR22ySnAx5MAp2ad2E3b0ypBtA3DYbw4GOk7Zmx+Lvj3ikBQSKHsDnE4sQ?=
 =?us-ascii?Q?GwL/zee+4Onfuwh5m39n6YdyfpXFWfZujCjtUAc6dT3jMwVrSWyijLZfkp3b?=
 =?us-ascii?Q?c5IvOy6FzHKdw/1f4HS5usvIrSN9n+UR4y7e4dVeBzeMTWUEAEs3yAg29F3z?=
 =?us-ascii?Q?6txkeIoXqARf2DLn2PDb7f/WdLVWh42Up0k9aLPnfsbdAM9516L+X+BQbjFi?=
 =?us-ascii?Q?ym1LFlSF+hMrdOZoEVQUM7SyajMAAgXT5l4i8MrlHlArFsopzULn7UU/BvVA?=
 =?us-ascii?Q?94sNsIYwBGew2S69bAeAcplH6tD8/PypIVl3ioWL4G44sxP/5NiM+yx9YeHX?=
 =?us-ascii?Q?ThHOLjyijgEMzhID72KvQjk8lChoC43jTpiaFUUixGMHcupSRJr5nWHZSrof?=
 =?us-ascii?Q?co4osN+xGM7iR+oo8vgWesaFSL/g/F/i6tvfrwZ0QbuGtrEm5lf0Ynxfzb96?=
 =?us-ascii?Q?xUsK0B6pYPgHzA73GBA9hhYdhuidZYTNjUGdUaCiuKdNAsNBAZHaSZHwg+1L?=
 =?us-ascii?Q?0LQyDySp4MrtrmdxQEPAp+JrjPnqTXavoJu8pxGXQwEXCuCEW28DsxOKmQZF?=
 =?us-ascii?Q?UnuZx2WvCT6iH8sFdWNS8tLjCJp64nVP7c8DTwPAvZdwuix3tWaibzfXRlR5?=
 =?us-ascii?Q?elZyLEPpttDXghurS0UmTEIStkssnyq5plsQ4GyrdeBc/CkEgyb5gAZy601q?=
 =?us-ascii?Q?CdqmUW4pLBIi26U7gHW1n7gi4cvA9wMjQZ1STrNfp73/fvNgsOqbGx4E53sJ?=
 =?us-ascii?Q?eUVqSxw1QSh+LuBzb9SF3USToQ40NO05c3PISRTl2RjCgNRbsFGwXta3ntG7?=
 =?us-ascii?Q?I/TxplIh0YMnBLdnZiI4MAmdM21x8Y636KqPc8I/LjCP9rtLycwQ542KZ5/C?=
 =?us-ascii?Q?BaeBkuOOvO9UwCG2MFfNLyPO2qqbFCSWB8PZgyPFcqL0yeBy5uxxJBTVn2UO?=
 =?us-ascii?Q?pheOvXdlCsX8svhq7hQoniY7M7qFtRPLeami?=
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: 04 Jun 2025 17:43:23.1203
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: cd44d750-94c4-4c39-ac69-08dda38f4d84
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: MW6PR12MB8708

Hi all,

This patch serie enables R52 support based on Luca's series.
"[PATCH v6 0/6] First chunk for Arm R82 and MPU support".

Ayan Kumar Halder (3):
  arm/mpu: Introduce MPU memory region map structure
  arm/mpu: Provide and populate MPU C data structures
  arm/mpu: Provide access to the MPU region from the C code

 xen/arch/arm/arm32/asm-offsets.c         |  6 ++
 xen/arch/arm/arm32/mpu/head.S            | 57 +++++++++++++++++++
 xen/arch/arm/include/asm/arm32/mpu.h     | 30 ++++++++--
 xen/arch/arm/include/asm/arm64/mpu.h     |  6 --
 xen/arch/arm/include/asm/mpu.h           |  8 ++-
 xen/arch/arm/include/asm/mpu/cpregs.h    | 72 +++++++++++++++++++++++-
 xen/arch/arm/include/asm/mpu/regions.inc |  8 ++-
 xen/arch/arm/mpu/mm.c                    | 33 +++++++++--
 8 files changed, 201 insertions(+), 19 deletions(-)

-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Wed Jun 04 18:57:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 18:57:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005842.1385201 (Exim 4.92)
	(envelope-from )
	id 1uMtIg-0007jb-D5; Wed, 04 Jun 2025 18:57:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005842.1385201; Wed, 04 Jun 2025 18: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 1uMtIg-0007jU-AE; Wed, 04 Jun 2025 18:57:22 +0000
Received: by outflank-mailman (input) for mailman id 1005842;
 Wed, 04 Jun 2025 18:57: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 1uMtIf-0007jO-AK
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 18:57:21 +0000
Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com
 [2607:f8b0:4864:20::f2a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bd40c80b-4175-11f0-a300-13f23c93f187;
 Wed, 04 Jun 2025 20:57:19 +0200 (CEST)
Received: by mail-qv1-xf2a.google.com with SMTP id
 6a1803df08f44-6fafb6899c2so3410126d6.0
 for ; Wed, 04 Jun 2025 11:57:19 -0700 (PDT)
Received: from [10.138.10.6] ([89.187.178.201])
 by smtp.gmail.com with ESMTPSA id
 af79cd13be357-7d09a0e9383sm1084023185a.20.2025.06.04.11.57.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 04 Jun 2025 11:57:17 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bd40c80b-4175-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749063438; x=1749668238; 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=ZGhC2rXS5lSykmspzD2pmrb8c20kCRcKSB074ZH4zZk=;
        b=eaco1+m+Fu9NtFyUN2+b+Q21Kwn6QthvSNSEtwK1qgvbn4faas674peCZEQQ7obmfk
         UodNuHr0ee46JVrTBxVLXkNkPoP099460u/8gUTJV+XTdX7hEIayxqZxTBVQbfxoPGlr
         +U7M2722uOvOmPfO335Yc5FT6iEu/6u9aZc0WwVM9JOkTMpnpbrKAQVYCmR95foCmgmw
         NQdFoqAXsdWgzfzLF8Xlxflw2IPvXH9luSgeffZLUepSXmmUFGXgzaMwAUf+uKLa3FaF
         VUgeghNjzelljXDiowiSTIDogZbvTWfpisfHOFsm43Pdsg5U6bsJi16LtuiFEnLEGUNw
         O/xw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749063438; x=1749668238;
        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=ZGhC2rXS5lSykmspzD2pmrb8c20kCRcKSB074ZH4zZk=;
        b=SQtLS8NDiE2z4wVDdYkYaPDJLt3iVwjwGIzVu7ooEVK1cIOz+XyyBZT+vi8npiOBhB
         DExJSvpWG0ABYr67u6lK9GEMLDy/JioXS7ZcSQB0qIyT2E/yfWSp954bMav3DP2C63gG
         B8KF4BacdtxH5vIlp/kJvwqfW+dih2HZCvmuUXqqxvs4U1UTcbi3D/LCaZaK+bdAInA8
         QeTQpEK4FSjv+vd8W5jN47z7fYu+oexRuq8BvxU7m8g4ZpddSD5LlUcAnkbifjrbynnH
         kj8Zz6UOXukYbOXMX1sMqLniWCbUkNb3Lcs7eZMoJwfY4S1kfJk7y5X29kXH9zogTyS5
         XMzQ==
X-Forwarded-Encrypted: i=1; AJvYcCUBRsPbrsqHRPMyFNVCB9ocNOnHgXueOUZMTddxJn3cJTuvmk403vgukg0OrCKVVvOXYq+PIjEYwlY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzPVXY3HE/QvZw8wU/VOw8/CavV8aenTWeRKlKADeajMfsGNhk/
	L+bFb6tx3Y0HqnXpP1vQac8vKzu/bnSBQ98b4y9dhCWhNIxaO2hIj+Ln
X-Gm-Gg: ASbGncsex1AS4TmhHkZA1vAuy5f9zn6MQNc0mZysNbLn7bbJmyTJg/VXaba4yrjgHn0
	n/2JpV9VXhVYNBTQmHY+KuiYPfv77EA8igxiwDTiZrn+V3MaUhZjp/nySnIFfU9Pm/OzuqYQcEh
	2BkH/UMSk/S4muOeRyLg2pZfjkPFPPJxOeGgRUH2EhQjkm+K7goBcL6lU7lkZeSvY3ZvchreM3L
	wR5uLbK7D7XpNFtz0BUksCaxkSfbK2Etcxp8hSrxDi77YHzhVsZS0SF/KJRZAWXOMVGC6BJ+Ni6
	jlYnRIDBCSikkza9ObBIPeRLAVkjZUWbZG6G54zMgdgZFDXA+DnpVtRCk3P8WFWfSSY=
X-Google-Smtp-Source: AGHT+IEMLpOMnL0T/qASyxXwy9fg20borwJufJ0r9FCkjmHy+IEWhqROlP4Qri0FLb6u70BCVaKv2g==
X-Received: by 2002:a05:6214:248d:b0:6fa:9a9d:fe93 with SMTP id 6a1803df08f44-6faffeb2decmr10298086d6.21.1749063438457;
        Wed, 04 Jun 2025 11:57:18 -0700 (PDT)
Message-ID: <62b32285-8ce5-4bee-b3b7-66e3a91a0a26@gmail.com>
Date: Wed, 4 Jun 2025 14:57:02 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v11 4/7] xen/arm: smmuv3: Add PCI devices support for
 SMMUv3
To: Julien Grall , xen-devel@lists.xenproject.org
Cc: Bertrand Marquis ,
 Stefano Stabellini ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Stewart Hildebrand ,
 Mykyta Poturai 
References: 
 <71741747bdc0cfcacbe86e66ddd6239ea2f5a3af.1748422217.git.mykyta_poturai@epam.com>
 <9bfc305b-602e-4c96-bd7a-763075e506d7@gmail.com>
 <56e44ec8-c9c0-4d58-98f3-730cc1c1bb86@xen.org>
Content-Language: en-US
From: Demi Marie Obenour 
Autocrypt: addr=demiobenour@gmail.com; keydata=
 xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49yB+l2nipd
 aq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYfbWpr/si88QKgyGSV
 Z7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/UorR+FaSuVwT7rqzGrTlscnT
 DlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7MMPCJwI8JpPlBedRpe9tfVyfu3euTPLPx
 wcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9Hzx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR
 6h3nBc3eyuZ+q62HS1pJ5EvUT1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl
 5FMWo8TCniHynNXsBtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2
 Bkg1b//r6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nSm9BBff0N
 m0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQABzTxEZW1pIE1hcmll
 IE9iZW5vdXIgKGxvdmVyIG9mIGNvZGluZykgPGRlbWlvYmVub3VyQGdtYWlsLmNvbT7CwXgE
 EwECACIFAlp+A0oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELKItV//nCLBhr8Q
 AK/xrb4wyi71xII2hkFBpT59ObLN+32FQT7R3lbZRjVFjc6yMUjOb1H/hJVxx+yo5gsSj5LS
 9AwggioUSrcUKldfA/PKKai2mzTlUDxTcF3vKx6iMXKA6AqwAw4B57ZEJoMM6egm57TV19kz
 PMc879NV2nc6+elaKl+/kbVeD3qvBuEwsTe2Do3HAAdrfUG/j9erwIk6gha/Hp9yZlCnPTX+
 VK+xifQqt8RtMqS5R/S8z0msJMI/ajNU03kFjOpqrYziv6OZLJ5cuKb3bZU5aoaRQRDzkFIR
 6aqtFLTohTo20QywXwRa39uFaOT/0YMpNyel0kdOszFOykTEGI2u+kja35g9TkH90kkBTG+a
 EWttIht0Hy6YFmwjcAxisSakBuHnHuMSOiyRQLu43ej2+mDWgItLZ48Mu0C3IG1seeQDjEYP
 tqvyZ6bGkf2Vj+L6wLoLLIhRZxQOedqArIk/Sb2SzQYuxN44IDRt+3ZcDqsPppoKcxSyd1Ny
 2tpvjYJXlfKmOYLhTWs8nwlAlSHX/c/jz/ywwf7eSvGknToo1Y0VpRtoxMaKW1nvH0OeCSVJ
 itfRP7YbiRVc2aNqWPCSgtqHAuVraBRbAFLKh9d2rKFB3BmynTUpc1BQLJP8+D5oNyb8Ts4x
 Xd3iV/uD8JLGJfYZIR7oGWFLP4uZ3tkneDfYzsFNBFp+A0oBEAC9ynZI9LU+uJkMeEJeJyQ/
 8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd8xD57ue0eB47bcJv
 VqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPpI4gfUbVEIEQuqdqQyO4GAe+M
 kD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalql1/iSyv1WYeC1OAs+2BLOAT2NEggSiVO
 txEfgewsQtCWi8H1SoirakIfo45Hz0tk/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJ
 riwoaRIS8N2C8/nEM53jb1sH0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcN
 fRAIUrNlatj9TxwivQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6
 dCxN0GNAORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
 rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog2LNtcyCj
 kTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZAgrrnNz0iZG2DVx46
 x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJELKItV//nCLBwNIP/AiIHE8b
 oIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwjjVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGj
 gn0TPtsGzelyQHipaUzEyrsceUGWYoKXYyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8fr
 RHnJdBcjf112PzQSdKC6kqU0Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2
 E0rW4tBtDAn2HkT9uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHM
 OBvy3EhzfAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
 Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVssZ/rYZ9+5
 1yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aWemLLszcYz/u3XnbO
 vUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPthZlDnTnOT+C+OTsh8+m5tos8
 HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E
 +MYSfkEjBz0E8CLOcAw7JIwAaeBT
In-Reply-To: <56e44ec8-c9c0-4d58-98f3-730cc1c1bb86@xen.org>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------gZ1UpVam19FfOqUlsth20aeL"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------gZ1UpVam19FfOqUlsth20aeL
Content-Type: multipart/mixed; boundary="------------MuW510iI600yHT6DWNk5Cg9R";
 protected-headers="v1"
From: Demi Marie Obenour 
To: Julien Grall , xen-devel@lists.xenproject.org
Cc: Bertrand Marquis ,
 Stefano Stabellini ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Stewart Hildebrand ,
 Mykyta Poturai 
Message-ID: <62b32285-8ce5-4bee-b3b7-66e3a91a0a26@gmail.com>
Subject: Re: [PATCH v11 4/7] xen/arm: smmuv3: Add PCI devices support for
 SMMUv3
References: 
 <71741747bdc0cfcacbe86e66ddd6239ea2f5a3af.1748422217.git.mykyta_poturai@epam.com>
 <9bfc305b-602e-4c96-bd7a-763075e506d7@gmail.com>
 <56e44ec8-c9c0-4d58-98f3-730cc1c1bb86@xen.org>
In-Reply-To: <56e44ec8-c9c0-4d58-98f3-730cc1c1bb86@xen.org>

--------------MuW510iI600yHT6DWNk5Cg9R
Content-Type: multipart/mixed; boundary="------------UvkIgYfv3GO51dQuK5p9CjhF"

--------------UvkIgYfv3GO51dQuK5p9CjhF
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 6/4/25 08:48, Julien Grall wrote:
> Hi Demi,
>=20
> When replying to a thread, please keep the folks in CC unless there is =
a=20
> reason to drop them. Sending to just xen-devel is likely going to be=20
> lost. I personally don't always keep an eyes on discussion where I am=20
> not CCed, there are too many!
>=20
> So adding re-adding the CC for you and keeping your reply as-is.
>=20
> On 29/05/2025 03:10, Demi Marie Obenour wrote:
>> On 5/28/25 05:12, Mykyta Poturai wrote:
>>> From: Rahul Singh 
>>>
>>> Implement support for PCI devices in the SMMU driver. Trigger iommu-m=
ap
>>> parsing when new PCI device is added. Add checks to assign/deassign
>>> functions to ensure PCI devices are handled correctly. Implement basi=
c
>>> quarantining.
>>>
>>> All pci devices are automatically assigned to hardware domain if it e=
xists
>>> to ensure it can probe them.
>> This is only safe for devices present at boot time.  It=E2=80=99s not =
safe for
>> hotplugged devices, which should be quarantined.

Thank you!  This makes me wonder if Thunderbird is a good choice for an
email client, or if I should use something like Mutt or Aerc.
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
--------------UvkIgYfv3GO51dQuK5p9CjhF
Content-Type: application/pgp-keys; name="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

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

xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49y
B+l2nipdaq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYf
bWpr/si88QKgyGSVZ7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/
UorR+FaSuVwT7rqzGrTlscnTDlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7M
MPCJwI8JpPlBedRpe9tfVyfu3euTPLPxwcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9H
zx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR6h3nBc3eyuZ+q62HS1pJ5EvU
T1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl5FMWo8TCniHynNXs
BtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2Bkg1b//r
6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nS
m9BBff0Nm0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQAB
zTxEZW1pIE9iZW5vdXIgKElUTCBFbWFpbCBLZXkpIDxhdGhlbmFAaW52aXNpYmxl
dGhpbmdzbGFiLmNvbT7CwY4EEwEIADgWIQR2h02fEza6IlkHHHGyiLVf/5wiwQUC
X6YJvQIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRCyiLVf/5wiwWRhD/0Y
R+YYC5Kduv/2LBgQJIygMsFiRHbR4+tWXuTFqgrxxFSlMktZ6gQrQCWe38WnOXkB
oY6n/5lSJdfnuGd2UagZ/9dkaGMUkqt+5WshLFly4BnP7pSsWReKgMP7etRTwn3S
zk1OwFx2lzY1EnnconPLfPBc6rWG2moA6l0WX+3WNR1B1ndqpl2hPSjT2jUCBWDV
rGOUSX7r5f1WgtBeNYnEXPBCUUM51pFGESmfHIXQrqFDA7nBNiIVFDJTmQzuEqIy
Jl67pKNgooij5mKzRhFKHfjLRAH4mmWZlB9UjDStAfFBAoDFHwd1HL5VQCNQdqEc
/9lZDApqWuCPadZN+pGouqLysesIYsNxUhJ7dtWOWHl0vs7/3qkWmWun/2uOJMQh
ra2u8nA9g91FbOobWqjrDd6x3ZJoGQf4zLqjmn/P514gb697788e573WN/MpQ5XI
Fl7aM2d6/GJiq6LC9T2gSUW4rbPBiqOCeiUx7Kd/sVm41p9TOA7fEG4bYddCfDsN
xaQJH6VRK3NOuBUGeL+iQEVF5Xs6Yp+U+jwvv2M5Lel3EqAYo5xXTx4ls0xaxDCu
fudcAh8CMMqx3fguSb7Mi31WlnZpk0fDuWQVNKyDP7lYpwc4nCCGNKCj622ZSocH
AcQmX28L8pJdLYacv9pU3jPy4fHcQYvmTavTqowGnM08RGVtaSBNYXJpZSBPYmVu
b3VyIChsb3ZlciBvZiBjb2RpbmcpIDxkZW1pb2Jlbm91ckBnbWFpbC5jb20+wsF4
BBMBAgAiBQJafgNKAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCyiLVf
/5wiwYa/EACv8a2+MMou9cSCNoZBQaU+fTmyzft9hUE+0d5W2UY1RY3OsjFIzm9R
/4SVccfsqOYLEo+S0vQMIIIqFEq3FCpXXwPzyimotps05VA8U3Bd7yseojFygOgK
sAMOAee2RCaDDOnoJue01dfZMzzHPO/TVdp3OvnpWipfv5G1Xg96rwbhMLE3tg6N
xwAHa31Bv4/Xq8CJOoIWvx6fcmZQpz01/lSvsYn0KrfEbTKkuUf0vM9JrCTCP2oz
VNN5BYzqaq2M4r+jmSyeXLim922VOWqGkUEQ85BSEemqrRS06IU6NtEMsF8EWt/b
hWjk/9GDKTcnpdJHTrMxTspExBiNrvpI2t+YPU5B/dJJAUxvmhFrbSIbdB8umBZs
I3AMYrEmpAbh5x7jEjoskUC7uN3o9vpg1oCLS2ePDLtAtyBtbHnkA4xGD7ar8mem
xpH9lY/i+sC6CyyIUWcUDnnagKyJP0m9ks0GLsTeOCA0bft2XA6rD6aaCnMUsndT
ctrab42CV5XypjmC4U1rPJ8JQJUh1/3P48/8sMH+3krxpJ06KNWNFaUbaMTGiltZ
7x9DngklSYrX0T+2G4kVXNmjaljwkoLahwLla2gUWwBSyofXdqyhQdwZsp01KXNQ
UCyT/Pg+aDcm/E7OMV3d4lf7g/CSxiX2GSEe6BlhSz+Lmd7ZJ3g32M1ARGVtaSBN
YXJpZSBPYmVub3VyIChJVEwgRW1haWwgS2V5KSA8ZGVtaUBpbnZpc2libGV0aGlu
Z3NsYWIuY29tPsLBjgQTAQgAOBYhBHaHTZ8TNroiWQcccbKItV//nCLBBQJgOEV+
AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJELKItV//nCLBKwoP/1WSnFdv
SAD0g7fD0WlF+oi7ISFT7oqJnchFLOwVHK4Jg0e4hGn1ekWsF3Ha5tFLh4V/7UUu
obYJpTfBAA2CckspYBqLtKGjFxcaqjjpO1I2W/jeNELVtSYuCOZICjdNGw2Hl9yH
KRZiBkqc9u8lQcHDZKq4LIpVJj6ZQV/nxttDX90ax2No1nLLQXFbr5wb465LAPpU
lXwunYDij7xJGye+VUASQh9datye6orZYuJvNo8Tr3mAQxxkfR46LzWgxFCPEAZJ
5P56Nc0IMHdJZj0Uc9+1jxERhOGppp5jlLgYGK7faGB/jTV6LaRQ4Ad+xiqokDWp
mUOZsmA+bMbtPfYjDZBz5mlyHcIRKIFpE1l3Y8F7PhJuzzMUKkJi90CYakCV4x/a
Zs4pzk5E96c2VQx01RIEJ7fzHF7lwFdtfTS4YsLtAbQFsKayqwkGcVv2B1AHeqdo
TMX+cgDvjd1ZganGlWA8Sv9RkNSMchn1hMuTwERTyFTr2dKPnQdA1F480+jUap41
ClXgn227WkCIMrNhQGNyJsnwyzi5wS8rBVRQ3BOTMyvGM07j3axUOYaejEpg7wKi
wTPZGLGH1sz5GljD/916v5+v2xLbOo5606j9dWf5/tAhbPuqrQgWv41wuKDi+dDD
EKkODF7DHes8No+QcHTDyETMn1RYm7t0RKR4zsFNBFp+A0oBEAC9ynZI9LU+uJkM
eEJeJyQ/8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd
8xD57ue0eB47bcJvVqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPp
I4gfUbVEIEQuqdqQyO4GAe+MkD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalq
l1/iSyv1WYeC1OAs+2BLOAT2NEggSiVOtxEfgewsQtCWi8H1SoirakIfo45Hz0tk
/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJriwoaRIS8N2C8/nEM53jb1sH
0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcNfRAIUrNlatj9Txwi
vQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6dCxN0GNA
ORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog
2LNtcyCjkTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZA
grrnNz0iZG2DVx46x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJ
ELKItV//nCLBwNIP/AiIHE8boIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwj
jVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGjgn0TPtsGzelyQHipaUzEyrsceUGWYoKX
YyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8frRHnJdBcjf112PzQSdKC6kqU0
Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2E0rW4tBtDAn2HkT9
uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHMOBvy3Ehz
fAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVss
Z/rYZ9+51yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aW
emLLszcYz/u3XnbOvUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPt
hZlDnTnOT+C+OTsh8+m5tos8HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj
6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E+MYSfkEjBz0E8CLOcAw7JIwAaeBTzsFN
BGbyLVgBEACqClxh50hmBepTSVlan6EBq3OAoxhrAhWZYEwN78k+ENhK68KhqC5R
IsHzlL7QHW1gmfVBQZ63GnWiraM6wOJqFTL4ZWvRslga9u28FJ5XyK860mZLgYhK
9BzoUk4s+dat9jVUbq6LpQ1Ot5I9vrdzo2p1jtQ8h9WCIiFxSYy8s8pZ3hHh5T64
GIj1m/kY7lG3VIdUgoNiREGf/iOMjUFjwwE9ZoJ26j9p7p1U+TkKeF6wgswEB1T3
J8KCAtvmRtqJDq558IU5jhg5fgN+xHB8cgvUWulgK9FIF9oFxcuxtaf/juhHWKMO
RtL0bHfNdXoBdpUDZE+mLBUAxF6KSsRrvx6AQyJs7VjgXJDtQVWvH0PUmTrEswgb
49nNU+dLLZQAZagxqnZ9Dp5l6GqaGZCHERJcLmdY/EmMzSf5YazJ6c0vO8rdW27M
kn73qcWAplQn5mOXaqbfzWkAUPyUXppuRHfrjxTDz3GyJJVOeMmMrTxH4uCaGpOX
Z8tN6829J1roGw4oKDRUQsaBAeEDqizXMPRc+6U9vI5FXzbAsb+8lKW65G7JWHym
YPOGUt2hK4DdTA1PmVo0DxH00eWWeKxqvmGyX+Dhcg+5e191rPsMRGsDlH6KihI6
+3JIuc0y6ngdjcp6aalbuvPIGFrCRx3tnRtNc7He6cBWQoH9RPwluwARAQABwsOs
BBgBCgAgFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmbyLVgCGwICQAkQsoi1X/+c
IsHBdCAEGQEKAB0WIQSilC2pUlbVp66j3+yzNoc6synyUwUCZvItWAAKCRCzNoc6
synyU85gD/0T1QDtPhovkGwoqv4jUbEMMvpeYQf+oWgm/TjWPeLwdjl7AtY0G9Ml
ZoyGniYkoHi37Gnn/ShLT3B5vtyI58ap2+SSa8SnGftdAKRLiWFWCiAEklm9FRk8
N3hwxhmSFF1KR/AIDS4g+HIsZn7YEMubBSgLlZZ9zHl4O4vwuXlREBEW97iL/FSt
VownU2V39t7PtFvGZNk+DJH7eLO3jmNRYB0PL4JOyyda3NH/J92iwrFmjFWWmmWb
/Xz8l9DIs+Z59pRCVTTwbBEZhcUc7rVMCcIYL+q1WxBG2e6lMn15OQJ5WfiE6E0I
sGirAEDnXWx92JNGx5l+mMpdpsWhBZ5iGTtttZesibNkQfd48/eCgFi4cxJUC4PT
UQwfD9AMgzwSTGJrkI5XGy+XqxwOjL8UA0iIrtTpMh49zw46uV6kwFQCgkf32jZM
OLwLTNSzclbnA7GRd8tKwezQ/XqeK3dal2n+cOr+o+Eka7yGmGWNUqFbIe8cjj9T
JeF3mgOCmZOwMI+wIcQYRSf+e5VTMO6TNWH5BI3vqeHSt7HkYuPlHT0pGum88d4a
pWqhulH4rUhEMtirX1hYx8Q4HlUOQqLtxzmwOYWkhl1C+yPObAvUDNiHCLf9w28n
uihgEkzHt9J4VKYulyJM9fe3ENcyU6rpXD7iANQqcr87ogKXFxknZ97uEACvSucc
RbnnAgRqZ7GDzgoBerJ2zrmhLkeREZ08iz1zze1JgyW3HEwdr2UbyAuqvSADCSUU
GN0vtQHsPzWl8onRc7lOPqPDF8OO+UfN9NAfA4wl3QyChD1GXl9rwKQOkbvdlYFV
UFx9u86LNi4ssTmU8p9NtHIGpz1SYMVYNoYy9NU7EVqypGMguDCL7gJt6GUmA0sw
p+YCroXiwL2BJ7RwRqTpgQuFL1gShkA17D5jK4mDPEetq1d8kz9rQYvAR/sTKBsR
ImC3xSfn8zpWoNTTB6lnwyP5Ng1bu6esS7+SpYprFTe7ZqGZF6xhvBPf1Ldi9UAm
U2xPN1/eeWxEa2kusidmFKPmN8lcT4miiAvwGxEnY7Oww9CgZlUB+LP4dl5VPjEt
sFeAhrgxLdpVTjPRRwTd9VQF3/XYl83j5wySIQKIPXgT3sG3ngAhDhC8I8GpM36r
8WJJ3x2yVzyJUbBPO0GBhWE2xPNIfhxVoU4cGGhpFqz7dPKSTRDGq++MrFgKKGpI
ZwT3CPTSSKc7ySndEXWkOYArDIdtyxdE1p5/c3aoz4utzUU7NDHQ+vVIwlnZSMiZ
jek2IJP3SZ+COOIHCVxpUaZ4lnzWT4eDqABhMLpIzw6NmGfg+kLBJhouqz81WITr
EtJuZYM5blWncBOJCoWMnBEcTEo/viU3GgcVRw=3D=3D
=3Dx94R
-----END PGP PUBLIC KEY BLOCK-----

--------------UvkIgYfv3GO51dQuK5p9CjhF--

--------------MuW510iI600yHT6DWNk5Cg9R--

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

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

iQIzBAEBCAAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmhAlwcACgkQszaHOrMp
8lOAZxAAjxTIhyxgUxM2nrpBpo54YN6v5qlmo83SLpK/O0OZXIkV+mwlVo2yOYQH
l8Z33Q6eBgf3RNyJANdMGzJ9ZW53BiBhJIeBlfmymRtknRvAoD6PdT/TL1Dp/+OO
3T0e27fHUafUuRxDviNZ1ODq9WsIt+ZepmTeexloZAKbuP4URIX+97tm8DT2gpEV
UTboTFC47ecbuSRIcf+rLsd/lRAr90VTBYWlEHpDXubIlMgg1qpvFHbwwqenvkhY
fub24cIUI45g1jDZkykGPy8vlvoQTqqgVX6DBPSVRalcEHPANRUh1qheWfr1VesB
frxBGECur3McGAxIaLdrgwqnXLeJQ8jqf3fAQiMqdS193EKiQEPdmW5kyYlyfjN0
zrC1bcTG7PAVd7FgmR7Kf6pJrjzovLxb7tSk8GGGRVX5NPhmsXjMm3BAggsvlQRy
8AbL+gyAVDNUl0v2jEkYghTxSEMmO3EVnSFfYPqtOwrOWp5GDWlcRZ11W2CuwPpu
2l2fJBhdajvSgzfm3E9kCs0/xQZQS7jVRLHeIrYucU8V/Kw6vw9OWHurvaybWG62
vPGgarx+1XOximbDl+4rWfJWVZJeleo9JdlyNC4P4j4Efpbb3MhKnNSy9hM18yGM
LShq4PHf06bdP8EJ2GSsVcN27ZOAlef3o4iE6/aG92gjHWEjVgQ=
=/x8V
-----END PGP SIGNATURE-----

--------------gZ1UpVam19FfOqUlsth20aeL--


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 19:20:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 19:20:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005876.1385211 (Exim 4.92)
	(envelope-from )
	id 1uMtfE-0003BP-7d; Wed, 04 Jun 2025 19:20:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005876.1385211; Wed, 04 Jun 2025 19:20:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMtfE-0003BI-42; Wed, 04 Jun 2025 19:20:40 +0000
Received: by outflank-mailman (input) for mailman id 1005876;
 Wed, 04 Jun 2025 19:20: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 1uMtfC-0003B9-Bd
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 19:20:38 +0000
Received: from EUR03-AM7-obe.outbound.protection.outlook.com
 (mail-am7eur03on2060d.outbound.protection.outlook.com
 [2a01:111:f403:260e::60d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fd0aa8f3-4178-11f0-b894-0df219b8e170;
 Wed, 04 Jun 2025 21:20:35 +0200 (CEST)
Received: from DUZPR01CA0320.eurprd01.prod.exchangelabs.com
 (2603:10a6:10:4ba::16) by DBBPR08MB10795.eurprd08.prod.outlook.com
 (2603:10a6:10:530::16) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Wed, 4 Jun
 2025 19:20:31 +0000
Received: from DU6PEPF00009526.eurprd02.prod.outlook.com
 (2603:10a6:10:4ba:cafe::51) by DUZPR01CA0320.outlook.office365.com
 (2603:10a6:10:4ba::16) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.24 via Frontend Transport; Wed,
 4 Jun 2025 19:20:24 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 DU6PEPF00009526.mail.protection.outlook.com (10.167.8.7) with Microsoft SMTP
 Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.29 via
 Frontend Transport; Wed, 4 Jun 2025 19:20:31 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com (2603:10a6:5:1c::25) by
 AS4PR08MB8093.eurprd08.prod.outlook.com (2603:10a6:20b:588::18) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.37; Wed, 4 Jun
 2025 19:19:58 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668]) by DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668%2]) with mapi id 15.20.8813.018; Wed, 4 Jun 2025
 19:19: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: fd0aa8f3-4178-11f0-b894-0df219b8e170
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=WG1B6sKKOr4nEaaTjTkD3pvXcNh6GNDHE9Ojsf6PMM5uImZmO+kguAxbV2i0+OFvRCWqHEMCKa3WmXVYQfkFFuAtzykVqlTVV+xdRHyvjryPZKN5UxULXC7192C8s+H2wvQZL2LXZphQCK9XaYw5RFrVO+WYE3865WPOMgml2FqHm2TJXSPZ5Tjje08qG64Ngi22XRzEbFDnhikOnYVLYFe8fSui/fZBISV9DCV5/T4fF//zZ4YAvUeW0FkAzEWOsrVPqgOr8n/pqi/qszuquy1hI9dmBnJS7nIha2JbI+M0zmJeHT5bwC14ZRbWH4CYH/WJEc5PP+IAc6enXWp9pg==
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=jtDwB5a4jaBk8/cJ+Rk3+5Pv6Jo34HQdVBLkmcHrKuQ=;
 b=dcJAF8mJxTHR6vOHxc4WiJ2NWJ9+A/Kqc8j1ikswRvPi6Lu3rWq0c4vNP1gy7uFpZPI3PJcaEpQ6f8apCw16+iW2pVcKmiL4AhVDS/s9udQJx2K9vAlf0yxpnZLvayb9Cn5A6PZIsbkKinXe+4CuLCcWkbQoVoQ2RP+sJPoYdkuV6W+RtawRWJc5LVsbfjfOB3BhS6ATz7C15ALQn+wHTIDUUrvqPXIYxH+/ydsWpaR+c65lVFbyOZ4XByMGGehatWB+FJ1myZ10/yVHJF+K9L2R0xfrkzj9GQwLfCpzV3pHrS2i68JW6fsM3LTbcC7Z7ChBMkU1/x3tfWTf/YFd/g==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=amd.com smtp.mailfrom=arm.com; dmarc=pass
 (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
 (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=jtDwB5a4jaBk8/cJ+Rk3+5Pv6Jo34HQdVBLkmcHrKuQ=;
 b=GFwGKYhMSnIddUf/Zkh64MxQPagZnIbUnKEWiIuMiTIOGapO9mt20tn0CqHKl8Ld8xSbSSR10NKi9bZJLsrElcmSoxGggfcJvgTQbzaqqoSkgHjE4Z83I36AbbMrwK7MtmWOtnEb7GczFo79HnBO0r7q3SkGP7LvxYk5+wf2RNc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=t9hXFK9dAqq2sA4EPlB5XxtX0OQRQGJnhiI1CtX+QVb5sZANOqWhDd/5HwyNCYry/9EQ6ylZgzLGeAoBScmhje30zy1GOTEGW/dfpqKBNZGRKoCH4/V5WDePn+PXUxSK7wYO4MfPV1xxjcYYu45Eyht8nYZ0fK04NIl5W5rA+P97Qxrv0d2suDAy2dlLR4hJ2tnX38ArnHHNTj/O4hmcRyvH+qG9W/Q4jdj2KTglPPaCz/in0loZFBGsZXshWbZmoZ12+Y6wOtdzaKjVTI3MffhCH48UtvQ33/Fn6u9nVyzeSzh/3HIaY/s8VhFXQZBDa+K4wY+yGtTb/dBEgOjPcw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=jtDwB5a4jaBk8/cJ+Rk3+5Pv6Jo34HQdVBLkmcHrKuQ=;
 b=NZcNUPedAlCkpfAqk4Q91Cc7U6rabhU8NCJOKeTqsoE7AH4kN+j5Uc6+dZWyt9XiIqAWLfeSEk7wiEgIT8GyV4aZhFGc7ZXEvEVygz145d/IjnZKkRkHoBxC7bfMO54dlh43BBjSvC2wJ4MRcnz9wQdg2YTdxciwEZaz63z1eqqK3iEOro9pGdZMHHPUOqCuIMNpgkpRtdQH5bT8SFXsvKy9CEnkZy8FO1yKnpZeGpnddzpwadIwOcXeqR+aa2nqgU7ZNMmE+xhTKpMi5sZQGb7q85Ug1D1TeBV3AIlul/nAUZ639FJIE6CiJfup5KZA68ke3RX6shYp9EtjjusLXg==
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=jtDwB5a4jaBk8/cJ+Rk3+5Pv6Jo34HQdVBLkmcHrKuQ=;
 b=GFwGKYhMSnIddUf/Zkh64MxQPagZnIbUnKEWiIuMiTIOGapO9mt20tn0CqHKl8Ld8xSbSSR10NKi9bZJLsrElcmSoxGggfcJvgTQbzaqqoSkgHjE4Z83I36AbbMrwK7MtmWOtnEb7GczFo79HnBO0r7q3SkGP7LvxYk5+wf2RNc=
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 v1 1/3] arm/mpu: Introduce MPU memory region map structure
Thread-Topic: [PATCH v1 1/3] arm/mpu: Introduce MPU memory region map
 structure
Thread-Index: AQHb1XhE+9uzMCRJ9UO6OgGmjkgLx7PzYDyA
Date: Wed, 4 Jun 2025 19:19:57 +0000
Message-ID: <154A0263-6E4D-4855-9408-ED31F45B293F@arm.com>
References: <20250604174311.754899-1-ayan.kumar.halder@amd.com>
 <20250604174311.754899-2-ayan.kumar.halder@amd.com>
In-Reply-To: <20250604174311.754899-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.600.51.1.1)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB7PR08MB2987:EE_|AS4PR08MB8093:EE_|DU6PEPF00009526:EE_|DBBPR08MB10795:EE_
X-MS-Office365-Filtering-Correlation-Id: 62c83304-c3e6-4df2-b285-08dda39cdf35
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?Y0FUWVZKNHhBVTdNQTcrRFJVc3BZNzk0dlJtblQzODNsTEM4Yy9qOGpkd3cw?=
 =?utf-8?B?OVZEVFV0WHBaNVJlMTJ5N2xEQUord3hzQ0pTNUJDKzJ5cUdiUVVYdzhYMHc5?=
 =?utf-8?B?dDV4TkFBUzgrbks1WjluT2lZK2V4RzhCLzh1dGdFRlRoTWRkelcxRUVoeU5G?=
 =?utf-8?B?WlJuNG9OR3VoUzdkVStFakRZT0NzdGUyQjhnNVpseE1TeXArUkhwamU3WXRB?=
 =?utf-8?B?Vk1SMW5mZEE4c0ZzZ0ZRSjF2YWN6djhOTTVpRERsWnpRbnlmSjNLNVN6NGNp?=
 =?utf-8?B?OW53QVh3Qi8wQ1doMHo0eU1CLzJrMlY1amJxWW5QNEVQRGFkaVpqeWFmUVVC?=
 =?utf-8?B?UWZYblhaWkNOSVI1TkJ5R3JEN2cxQzBwZ0xFejM0bWFKTndVMGZwbU45Ujkx?=
 =?utf-8?B?R1NjOUFNdGY4VWUwRU43MXNrN1p0NWg0UWNsUDVnVzd6eUN6V0krZE14VDd6?=
 =?utf-8?B?c1N4M2tFc1U2SWNyL2Y4RFUrWUdrMnhES1ZPVDRMcWhhRUV0YnlwWVhnb2NT?=
 =?utf-8?B?cGVLVXVRTVdNMDhqWThCb3BmQ0tVSndRZG9PN2FjSFlXeFR4dVdhdTl1eGJi?=
 =?utf-8?B?VDRYbExQQnJhRTVjR0NuQXcrZVAxNUVuYVI3RmdrQ0g0cnlyc2VOejVKbnh1?=
 =?utf-8?B?T1VrMk45c2pCU1ovZFFFLzFoOUNHVnlLNExudDY4M1V2Ty9LMk5iMjBPaU9E?=
 =?utf-8?B?aGdrTnhoYWx4WVZLN2J2dCsxYU56TUVSazlsWGF0K01NSWNsSmhxU0hxTHpP?=
 =?utf-8?B?QS85djZDMjlwbDB6MVJmNGtIeHZ6SThFeUtkMGk1cTFnVjExeDgrTVFQOEd6?=
 =?utf-8?B?azZTT3hRZkgrKzdLOHJDa3ZlRHlnS2NZNDdReXJ4QjRuZkxCcThhNDBFSy8x?=
 =?utf-8?B?T21QZ2duZ2d6cnBjRU5HNVhjMlNuSnR3aWVDZHB1T1o0SDR5Y1RPT3RBbVJW?=
 =?utf-8?B?RWFmeDlmbWpEMTJmb1VVL0tOQ1c4dVdsdDIvQmhpZ25URVVMV1oxTERCaDk0?=
 =?utf-8?B?VUJibXQ3SWpkUzhqRTRGdVRiOG0vM1llRkFFS21pMG1ndzMvRDBoWkhPNlFK?=
 =?utf-8?B?clEvaVk3YkVIT3VPV1I0RnVMUGt6RW1SREtQK29QWDVTYitTZmZjMHRrRGRQ?=
 =?utf-8?B?OHl5VmtzdjBEeHkvbEZjc2RjOS93NHF4Ny9pZ3kwS01GT25VWHIvMDJXMDN1?=
 =?utf-8?B?emNCK0JXeWFVdkpDUDFRT2lkb0ZJSkI1M2kyM2l0YWhKZjBFdkRXeWtyVTN1?=
 =?utf-8?B?NWJoSGgzampWTFBoVmYvTldEaWZVVFR2TGVBMGVRcmNGbUJXd3JmWnh4WFNT?=
 =?utf-8?B?N0pwNG1QaDlSREl5ZmxITEZTbmdWVmRBalJ5NGxGYTJtalF3ZlN5dCtQc2VS?=
 =?utf-8?B?cW93MGZ0M0txbktqMHVhQmZGUCtLYXhxUFhUblllQ0lFRmN3dUN0SllBVVE4?=
 =?utf-8?B?dFUvYTBNOGJrL3BQS3F6YU5uYVZGeldXaGNnNndFYWJCRnZWOTFIZTV0NE91?=
 =?utf-8?B?dXpkeW9aNGlrUjcrL1J1UkwrTi9VZ20rclpKOG42V3Y2Y29yUDM2Q3dtdHVZ?=
 =?utf-8?B?QlJLMlJ0ZTFqQnVhMDJiYkh1Rlg1UkdXSWZGMkZMTjBHc0l6VDcxSWJPUC9Q?=
 =?utf-8?B?NGhwQUZvcWZvZWFMa0ZpcFpkNEhhT1JtNWYyenpTdTJpM0E4ZmtYSGl6cE5x?=
 =?utf-8?B?MURUYm12WHhOL3ZGQ1B0Q0JLQys2emtoUDZLcWw3UDgzbGRCQzFqdDNTcXFt?=
 =?utf-8?B?bTJ6ZWg4UTczdDRVTFZVMXFhNHRaNFdtODRKVndudDBTMWdWMU1CN0o2UUV0?=
 =?utf-8?B?djVCZzBkSHBhSDBZdG9nMEkrYklHNVV1TFAweDNpNFFtbTRYekFCOC9SeFRT?=
 =?utf-8?B?UEFNNUVTb05mOFQva1JZSVRtZTdkQ1o4aGRwSElhYlV2M3liemp1TzkvQ2tu?=
 =?utf-8?B?Wk1kOEVnbUkzK0M1c0lpMFNKMEJiSXZjalUxN0lsQ0Fsa2NUMTJrMEZnUlRp?=
 =?utf-8?Q?pPfrS/18Dv2CUVm2T8aN7jy5/KJZD0=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB7PR08MB2987.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: <6794D7E81FB5964F8D79B03F3E58D751@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR08MB8093
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DU6PEPF00009526.eurprd02.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	c9f22ae0-f5ec-475b-fc02-08dda39ccb54
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|14060799003|36860700013|82310400026|35042699022|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?SE9pL2Y2T2kyc0FZSE9UOUx5ZzNCUnRkdk5zMXV6VWY3T2pPbGhqclEvV1VX?=
 =?utf-8?B?dTI0T1ppTlFVeFpnR2xGQlNSTW1oOEpKQ2xXU2x4ZGdNWmU3WjRudnZQQXdO?=
 =?utf-8?B?SXAyNTMxVlkvWkI4Q1p3ZnpMcUkvUEFFNm13cGdhbWxkNlRJVDIxZ3pHMWhj?=
 =?utf-8?B?T2hjUHdRdnltZ3JYckNYOEtMUXJqbjB4NDlXVDNMdDc4eGRFTUR2U1BHS0Jo?=
 =?utf-8?B?Q3MzRjhzMnVkUHY4R1ZVbFlmMXpxcWJhTkZZcXhuaTlzM2d0TUVoMG1ORFFI?=
 =?utf-8?B?M3JXKytLUzRVMFZhdjJYQktTMEpPeHVSUGsvZXZRUGFOVm1FSHE1Uk50NFJj?=
 =?utf-8?B?TFE0aUE0S0p5WjhzUldwelhhZE01a2VwVUNMT2xrdHpPVU1ObklrY1habFFl?=
 =?utf-8?B?SVB4eTZ0bDNneDNEZktpNEczMkowaWY0QTV6Y3p2bHEzVTkzcFlRVHRMamUr?=
 =?utf-8?B?cmpTUG1obUFuN1NrWE0wMnJFQWU0Vk1NUTRMSFJlMWVraGZqRUx0Mk5peGJr?=
 =?utf-8?B?dWVJcmdQUCtFcjBhTVRRWTIxbUNjYVZnY0RyQ1FQa2dnVGtSZiswTGxaQXpY?=
 =?utf-8?B?U2ZZTncrbUI3eEVPbGtNNEg2ZDJ1UnRra3Q5QXlMdElJcmlrQ1NlcE1aUkNR?=
 =?utf-8?B?Q2kyd1ptZUFtaGVnbytsWVRyckJlWjBkMzY2NExjNWk2emlIbUZ4U1IxS2Mz?=
 =?utf-8?B?M3cwYmJ0SEpray96aERIc0NUajVobmFqL2pUZ09SSzhnZ29aTVF6SFJkWEpk?=
 =?utf-8?B?ZUNNaXZzVmpMaEZZQ0M5WnVqRktDendrSHJueVlIdkhEeWJIMHdwUUFOOUs1?=
 =?utf-8?B?M05xNVNXUXQxNUhhWFlsMlhFVk02eHIxazB6M2hNUlo2Q0lkSFJMN3R1SXVh?=
 =?utf-8?B?dlpSNzJKbFlwd0xlMHpQWTdNL1lONTc4cmZVbldNeGF2cUhKR285ZzJ1Wkwz?=
 =?utf-8?B?R1lneEZWNFl4bjZtYjlqUE9ZQ3U3cVE3S0FvMDRLMWF0MFpCZkdxKytucGYw?=
 =?utf-8?B?c0xnSmZSdGJTKyttOHNoU0xPcDlRclh3ZzI1TTBGY3ZMdVhjeVJReDUva3Ur?=
 =?utf-8?B?dXNaRkZuOVJPQUJLU2xFTlVEdmpYdGJJcGwrT1I0dVNIV0dBc2Vja0JvcGZF?=
 =?utf-8?B?K1RGVHNWUDB2NHdBRUhjZVZSc2lUTE56cXgwK1pHdmVSdWlFdXlWT1I3aDlp?=
 =?utf-8?B?WTdIcHhyLzlHblVPS3BSMEQyVGhrOE4ySm1KVG80T01XdTg1Qm93TTZCR29p?=
 =?utf-8?B?RjFLN2dJK1RRTkFaQ1RncDJaZXVVZEtLOVMwQzB4ZkhOblU1K3UyMjRibnBU?=
 =?utf-8?B?QU5PQ21YemhMUUg1Uy8vN3J6azJBVlhReFZqREM2cTFrWFdCWGVOSWdJb1NR?=
 =?utf-8?B?cy9NRkxaRXZZQTJWcEw2TERPd0lKczl3bjB3VzdETU5acUxXOUlPUTVRRkwr?=
 =?utf-8?B?SVEyaU95WDJVUDVOZGhiT2RKMUkwVSt1SndDd3N2Q2JVOWU3YUhEZU9SUVlR?=
 =?utf-8?B?N0o4MzlHU0NKaStCbEpvT3NWQjFlVjlScXdlS0Irdklaamd0eFpYZGVDVUN0?=
 =?utf-8?B?dlF2QTNPdjNOOXFyZjRHSVRXTk9NcFlGemVmclZnczdGaHVsd3I1b2JxMzRl?=
 =?utf-8?B?dEJxaFZ2TjZyUjNwWXBWUHI4VXh2SEJocFY4ajgvRlBnVnk0cWUzaklBQkNH?=
 =?utf-8?B?TFRaWG5meWs0R3RiVHpCdXhqNkJtNnEyZmR4bzVqVlBwQW56RHlVYTVsRzcw?=
 =?utf-8?B?UVZIcUdtYUFLYTVTNVpqbGpQRW5EK0xmNTlRWmc5bng4KzhJUGhGb0dGSVJs?=
 =?utf-8?B?ZUlkOXdSMnc3WGRTdUZTclhDa1A1RUpLN2NLbEZsaU1WT3kwdTlXY1FZSmdL?=
 =?utf-8?B?MEF0SVBvUGFHVWVLUVBPb2JBYnBZQlQzRU4yUTFTWEFwOTN6dlJZYWZiTDE5?=
 =?utf-8?B?cytyVXhZVExZZVlNaUJoV2k2Q0xkay9MWGVRUVhxRDBLUFZmWEdvcGpzMEZl?=
 =?utf-8?B?ZWRLRWwxMEw4UmJDQWlXelVOWHRZK0ErYnJ2VW1IR25EQjkxK3lobFRISnRR?=
 =?utf-8?Q?R1AcFJ?=
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(376014)(14060799003)(36860700013)(82310400026)(35042699022)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jun 2025 19:20:31.0466
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 62c83304-c3e6-4df2-b285-08dda39cdf35
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DU6PEPF00009526.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB10795

SGkgQXlhbiwNCg0KPiBPbiA0IEp1biAyMDI1LCBhdCAxODo0MywgQXlhbiBLdW1hciBIYWxkZXIg
PGF5YW4ua3VtYXIuaGFsZGVyQGFtZC5jb20+IHdyb3RlOg0KPiANCj4gSW50cm9kdWNlIHByX3Qg
dHlwZWRlZiB3aGljaCBpcyBhIHN0cnVjdHVyZSBoYXZpbmcgdGhlIHByYmFyIGFuZCBwcmxhciBt
ZW1iZXJzLA0KPiBlYWNoIGJlaW5nIHN0cnVjdHVyZWQgYXMgdGhlIHJlZ2lzdGVycyBvZiB0aGUg
QUFyY2gzMiBBcm12OC1SIGFyY2hpdGVjdHVyZS4NCj4gDQo+IEFsc28sIGRlZmluZSBNUFVfUkVH
SU9OX1JFUzAgdG8gMCBhcyB0aGVyZSBhcmUgbm8gcmVzZXJ2ZWQgMCBiaXRzIGJleW9uZCB0aGUN
Cj4gQkFTRSBvciBMSU1JVCBiaXRmaWVsZHMgaW4gcHJiYXIgb3IgcHJsYXIgcmVzcGVjdGl2ZWx5
Lg0KPiANCj4gTW92ZSBwcl90IGRlZmluaXRpb24gdG8gY29tbW9uIGNvZGUuDQo+IEFsc28sIGVu
Y2xvc2UgeG5fMCB3aXRoaW4gQVJNNjQgYXMgaXQgaXMgbm90IHByZXNlbnQgZm9yIEFSTTMyLg0K
PiANCj4gU2lnbmVkLW9mZi1ieTogQXlhbiBLdW1hciBIYWxkZXIgPGF5YW4ua3VtYXIuaGFsZGVy
QGFtZC5jb20+DQo+IC0tLQ0KPiB4ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vYXJtMzIvbXB1Lmgg
fCAzMCArKysrKysrKysrKysrKysrKysrKysrKy0tLS0tDQo+IHhlbi9hcmNoL2FybS9pbmNsdWRl
L2FzbS9hcm02NC9tcHUuaCB8ICA2IC0tLS0tLQ0KPiB4ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20v
bXB1LmggICAgICAgfCAgNiArKysrKysNCj4geGVuL2FyY2gvYXJtL21wdS9tbS5jICAgICAgICAg
ICAgICAgIHwgIDIgKysNCj4gNCBmaWxlcyBjaGFuZ2VkLCAzMyBpbnNlcnRpb25zKCspLCAxMSBk
ZWxldGlvbnMoLSkNCj4gDQo+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20v
YXJtMzIvbXB1LmggYi94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vYXJtMzIvbXB1LmgNCj4gaW5k
ZXggZjBkNGQ0MDU1Yy4uYWUzYjY2MWZkZSAxMDA2NDQNCj4gLS0tIGEveGVuL2FyY2gvYXJtL2lu
Y2x1ZGUvYXNtL2FybTMyL21wdS5oDQo+ICsrKyBiL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9h
cm0zMi9tcHUuaA0KPiBAQCAtNSwxMSArNSwzMSBAQA0KPiANCj4gI2lmbmRlZiBfX0FTU0VNQkxZ
X18NCj4gDQo+IC0vKiBNUFUgUHJvdGVjdGlvbiBSZWdpb24gKi8NCj4gLXR5cGVkZWYgc3RydWN0
IHsNCj4gLSAgICB1aW50MzJfdCBwcmJhcjsNCj4gLSAgICB1aW50MzJfdCBwcmxhcjsNCj4gLX0g
cHJfdDsNCj4gKyNkZWZpbmUgTVBVX1JFR0lPTl9SRVMwICAgICAgIDB4MA0KPiArDQo+ICsvKiBI
eXBlcnZpc29yIFByb3RlY3Rpb24gUmVnaW9uIEJhc2UgQWRkcmVzcyBSZWdpc3RlciAqLw0KPiAr
dHlwZWRlZiB1bmlvbiB7DQo+ICsgICAgc3RydWN0IHsNCj4gKyAgICAgICAgdW5zaWduZWQgaW50
IHhuOjE7ICAgICAgIC8qIEV4ZWN1dGUtTmV2ZXIgKi8NCj4gKyAgICAgICAgdW5zaWduZWQgaW50
IGFwXzA6MTsgICAgIC8qIEFjZXNzIFBlcm1pc3Npb24gKi8NCj4gKyAgICAgICAgdW5zaWduZWQg
bG9uZyBybzoxOyAgICAgIC8qIEFjY2VzcyBQZXJtaXNzaW9uIEFQWzFdICovDQo+ICsgICAgICAg
IHVuc2lnbmVkIGludCBzaDoyOyAgICAgICAvKiBTaGFyZWJpbGl0eSAqLw0KDQpUeXBvOiBTaGFy
ZWJpbGl0eSAtPiBTaGFyZWFiaWxpdHkuDQoNCkFsc28sIGZyb20gdGhlIHBhdGNoIHRoZSBjb21t
ZW50cyBmZWVscyBub3QgYWxpZ25lZCwgaXMgdGhhdCB0aGUgY2FzZT8NCg0KPiArICAgICAgICB1
bnNpZ25lZCBpbnQgcmVzMDoxOyAgICAgLyogUmVzZXJ2ZWQgYXMgMCAqLw0KPiArICAgICAgICB1
bnNpZ25lZCBpbnQgYmFzZToyNjsgICAgLyogQmFzZSBBZGRyZXNzICovDQo+ICsgICAgfSByZWc7
DQo+ICsgICAgdWludDMyX3QgYml0czsNCj4gK30gcHJiYXJfdDsNCj4gKw0KPiArLyogSHlwZXJ2
aXNvciBQcm90ZWN0aW9uIFJlZ2lvbiBMaW1pdCBBZGRyZXNzIFJlZ2lzdGVyICovDQo+ICt0eXBl
ZGVmIHVuaW9uIHsNCj4gKyAgICBzdHJ1Y3Qgew0KPiArICAgICAgICB1bnNpZ25lZCBpbnQgZW46
MTsgICAgIC8qIFJlZ2lvbiBlbmFibGUgKi8NCj4gKyAgICAgICAgdW5zaWduZWQgaW50IGFpOjM7
ICAgICAvKiBNZW1vcnkgQXR0cmlidXRlIEluZGV4ICovDQo+ICsgICAgICAgIHVuc2lnbmVkIGlu
dCByZXMwOjI7ICAgLyogUmVzZXJ2ZWQgMCBieSBoYXJkd2FyZSAqLw0KPiArICAgICAgICB1bnNp
Z25lZCBpbnQgbGltaXQ6MjY7IC8qIExpbWl0IEFkZHJlc3MgKi8NCj4gKyAgICB9IHJlZzsNCj4g
KyAgICB1aW50MzJfdCBiaXRzOw0KPiArfSBwcmxhcl90Ow0KPiANCj4gI2VuZGlmIC8qIF9fQVNT
RU1CTFlfXyAqLw0KPiANCj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9h
cm02NC9tcHUuaCBiL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9hcm02NC9tcHUuaA0KPiBpbmRl
eCBmMGNlMzQ0ZTc4Li5kZjQ2Nzc0ZGNiIDEwMDY0NA0KPiAtLS0gYS94ZW4vYXJjaC9hcm0vaW5j
bHVkZS9hc20vYXJtNjQvbXB1LmgNCj4gKysrIGIveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2Fy
bTY0L21wdS5oDQo+IEBAIC0zNCwxMiArMzQsNiBAQCB0eXBlZGVmIHVuaW9uIHsNCj4gICAgIHVp
bnQ2NF90IGJpdHM7DQo+IH0gcHJsYXJfdDsNCj4gDQo+IC0vKiBNUFUgUHJvdGVjdGlvbiBSZWdp
b24gKi8NCj4gLXR5cGVkZWYgc3RydWN0IHsNCj4gLSAgICBwcmJhcl90IHByYmFyOw0KPiAtICAg
IHBybGFyX3QgcHJsYXI7DQo+IC19IHByX3Q7DQoNCknigJltIG5vdCBzdXJlIEkgd291bGQgZG8g
dGhpcywgYXQgc29tZSBwb2ludCB0aGVyZSB3aWxsIGJlIHRoZSB0cmFuc2llbnQgZmxhZ3MgYW5k
IHAybSB0eXBlDQphbmQgd2Uga25vdyBhcm0zMiB3aWxsIG5lZWQgdG8gc3RvcmUgdGhlbSBpbiBw
cl90IGFzIGFkZGl0aW9uYWwgbWVtYmVycywgaW5zdGVhZCANCmFybTY0IHdpbGwgc3RvcmUgdGhl
bSBhcyBwYXJ0IG9mIHByYmFyL3BybGFyIHVzaW5nIHRoZSBub3QgdXNlZCBzcGFjZSAod2l0aG91
dCB3cml0aW5nIHRoZW0NCmluIHRoZSBIVyByZWdpc3RlcnMpDQoNCj4gLQ0KPiAjZW5kaWYgLyog
X19BU1NFTUJMWV9fICovDQo+IA0KPiAjZW5kaWYgLyogQVJNX0FSTTY0X01QVV9IICovDQo+IGRp
ZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vbXB1LmggYi94ZW4vYXJjaC9hcm0v
aW5jbHVkZS9hc20vbXB1LmgNCj4gaW5kZXggOGYwNmRkYWMwZi4uYzg1NzNhNTk4MCAxMDA2NDQN
Cj4gLS0tIGEveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL21wdS5oDQo+ICsrKyBiL3hlbi9hcmNo
L2FybS9pbmNsdWRlL2FzbS9tcHUuaA0KPiBAQCAtMjUsNiArMjUsMTIgQEANCj4gDQo+ICNpZm5k
ZWYgX19BU1NFTUJMWV9fDQo+IA0KPiArLyogTVBVIFByb3RlY3Rpb24gUmVnaW9uICovDQo+ICt0
eXBlZGVmIHN0cnVjdCB7DQo+ICsgICAgcHJiYXJfdCBwcmJhcjsNCj4gKyAgICBwcmxhcl90IHBy
bGFyOw0KPiArfSBwcl90Ow0KPiArDQo+ICNpZmRlZiBDT05GSUdfQVJNXzY0DQo+IC8qDQo+ICAq
IFNldCBiYXNlIGFkZHJlc3Mgb2YgTVBVIHByb3RlY3Rpb24gcmVnaW9uLg0KPiBkaWZmIC0tZ2l0
IGEveGVuL2FyY2gvYXJtL21wdS9tbS5jIGIveGVuL2FyY2gvYXJtL21wdS9tbS5jDQo+IGluZGV4
IDg2ZmJlMTA1YWYuLjJmYjZiODIyYzYgMTAwNjQ0DQo+IC0tLSBhL3hlbi9hcmNoL2FybS9tcHUv
bW0uYw0KPiArKysgYi94ZW4vYXJjaC9hcm0vbXB1L21tLmMNCj4gQEAgLTE2Nyw3ICsxNjcsOSBA
QCBwcl90IHByX29mX2FkZHIocGFkZHJfdCBiYXNlLCBwYWRkcl90IGxpbWl0LCB1bnNpZ25lZCBp
bnQgZmxhZ3MpDQo+ICAgICAvKiBCdWlsZCB1cCB2YWx1ZSBmb3IgUFJCQVJfRUwyLiAqLw0KPiAg
ICAgcHJiYXIgPSAocHJiYXJfdCkgew0KPiAgICAgICAgIC5yZWcgPSB7DQo+ICsjaWZkZWYgQ09O
RklHX0FSTTY0DQo+ICAgICAgICAgICAgIC54bl8wID0gMCwNCj4gKyNlbmRpZg0KPiAgICAgICAg
ICAgICAueG4gPSBQQUdFX1hOX01BU0soZmxhZ3MpLA0KPiAgICAgICAgICAgICAuYXBfMCA9IDAs
DQo+ICAgICAgICAgICAgIC5ybyA9IFBBR0VfUk9fTUFTSyhmbGFncykNCj4gLS0gDQo+IDIuMjUu
MQ0KPiANCg0KQ2hlZXJzLA0KTHVjYQ0KDQoNCg==


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 19:52:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 19:52:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005890.1385221 (Exim 4.92)
	(envelope-from )
	id 1uMu9Y-00075p-Bc; Wed, 04 Jun 2025 19:52:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005890.1385221; Wed, 04 Jun 2025 19:52: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 1uMu9Y-00075i-8S; Wed, 04 Jun 2025 19:52:00 +0000
Received: by outflank-mailman (input) for mailman id 1005890;
 Wed, 04 Jun 2025 19:51: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 1uMu9W-00075c-Ca
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 19:51:58 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on2061e.outbound.protection.outlook.com
 [2a01:111:f403:2413::61e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5d790e38-417d-11f0-b894-0df219b8e170;
 Wed, 04 Jun 2025 21:51:55 +0200 (CEST)
Received: from CH0PR04CA0117.namprd04.prod.outlook.com (2603:10b6:610:75::32)
 by IA1PR12MB8336.namprd12.prod.outlook.com (2603:10b6:208:3fc::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.37; Wed, 4 Jun
 2025 19:51:52 +0000
Received: from CH1PEPF0000AD75.namprd04.prod.outlook.com
 (2603:10b6:610:75:cafe::37) by CH0PR04CA0117.outlook.office365.com
 (2603:10b6:610:75::32) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.23 via Frontend Transport; Wed,
 4 Jun 2025 19:51:52 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CH1PEPF0000AD75.mail.protection.outlook.com (10.167.244.54) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Wed, 4 Jun 2025 19:51:51 +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, 4 Jun
 2025 14:51:51 -0500
Received: from [172.31.138.29] (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 Jun 2025 14:51:50 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5d790e38-417d-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=UnW8Fah93vzAsppY2h7t2dA0mgPIoWT8IuBQeCWXo+qCNB7WoF1KS3jSqeUJ9Y3nW7BJFmk3tXGQWD1KknQyQaGUHVwQKQMsx9V9vvV+bYB/XcnHO6fmrdxpggkdavL9CGd2BGSkKDw/lItp4aZ5PnZsV3F9+4CeWJ2qAlF72GL/hs9IQfl+lLniiVOYaf9Q8vn0sTGVEw9nsZd7xSvtsQWH4M5bvsHHvXpd3KemGj6ed1R5OuuyA7m/HPvFyQMX/qVGAQENvu3UB4SDKkg9IlxVSSM787Zr8FjGKbMhHrMtgIJnT7vmOJAJionwWTRBzPMtiAFBdom0xhAoE130wA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=JWLtwx3KVfo9VJoKchdXuplTFM20rdP1HjCFSwF2KoI=;
 b=lnTQB+vmkRezvleSZliVXxgAzTDmyyHZJ7Lvo1u/nFqg+wUYNFrYeWHf+Ec50cC5KecGa+TT5SDQfPZp91ba9ZmhtsS9hoI1AGqkr/0p3DD2lbMgxk1ZvRBumP2A4Z68csRJ0ejNAX2vUJHbqLOD69AohfID7OAG4jg5RHEX8mqZOAkD/FUHmt66bCNQil7H77lMJzxgAeNcP6vKcY/GRFgzGjkv2VtgIy3IUnxox/r8bNNBRv+pmdlVpOzctNY74cig5dQfcJj4OnoDeVdeCIO5oAMru/PiPB3TwsNLQv+tWwNIEas++kPs47NXSo8IgHWvjN2nfnERIQUu4qU7Bg==
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=JWLtwx3KVfo9VJoKchdXuplTFM20rdP1HjCFSwF2KoI=;
 b=2rA5SsCVYRCBQDCURsKlPDXbgNA3HJ1Dt9zo2ZmsMdV7lcU4/Qwv/6k0XrvX4uE9+5xI3iuUWnftgdKehf4ipZOyhD02TE37idVxdfn43FXl6bejFpP3hFE7ANOcME8P6QlJK9X0EDQuO1oB1fJs11X8JdjUfXFCnuuzybMBBcY=
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, 4 Jun 2025 15:51:53 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/2] xen/arm: exclude xen,reg from direct-map domU
 extended regions
To: "Orzel, Michal" , 
CC: Stefano Stabellini , Julien Grall
	, Bertrand Marquis , "Volodymyr
 Babchuk" , Andrew Cooper
	, Anthony PERARD , "Jan
 Beulich" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	
References: <20250513195452.699600-1-stewart.hildebrand@amd.com>
 <20250513195452.699600-2-stewart.hildebrand@amd.com>
 <54c3d341-1d7f-428d-89a7-ce4fcae8a5db@amd.com>
 <4bd41362-6ee4-44d7-9f9b-0ffd78f1e6f8@amd.com>
 <28b22fa6-c6f9-463e-8e7e-0a00eae88737@amd.com>
Content-Language: en-US
From: Stewart Hildebrand 
In-Reply-To: <28b22fa6-c6f9-463e-8e7e-0a00eae88737@amd.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
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: CH1PEPF0000AD75:EE_|IA1PR12MB8336:EE_
X-MS-Office365-Filtering-Correlation-Id: 61f7ac66-a926-42eb-7023-08dda3a14024
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?UWRGd2FkVytUYUcvOHdFa1ROQVUwWll0aHFtMVp0Ry9uVVkvTHpVQkJDVnZH?=
 =?utf-8?B?QmtRd0dQVzY0MDRCZnVBeWhpeWJDN1NvYmQ4c1dSRVpjZ3NCYWFDei91SVla?=
 =?utf-8?B?cjhrTVo5Vnk4OHEwdTBWRGJNUGlxVkdNaHdGdHNtTloxYVhuZDlaSy82ZHlX?=
 =?utf-8?B?QTB2V1RPZGNLbExoaU00a1hnUmw3YUw4R0xuVHdZYnV6NmJDSWVidjFPaU95?=
 =?utf-8?B?cHFyQ2MwWXE5RkpTNXpkTUtmR05yWWhvVEVjdkcvdUFpbEw5SU9zaXErZ0ls?=
 =?utf-8?B?MjA2MjNwQVp6YjJ1dUtRZmJMSVRYaDhKWDBGTE1GblN1WlVxWXZVS1BGbTFZ?=
 =?utf-8?B?L3ZORDFVOXdTZEFxZjZ3MExNSzRnWGl4bEVqcCswaW1NeG5janN5bjhRRDNV?=
 =?utf-8?B?Y1NnZ1VDU2tEeElscnBVdXN5R0pBTnZWNEpOUFJWT3FPQS9RN1BseEx6Vm9t?=
 =?utf-8?B?MVUxUTNFd1JQTTI1NkpOS3RpZHE5djFUSE5Da2tDK2Ercnowa0lYUTZBdkFD?=
 =?utf-8?B?cDQ0aHkrSkhHbGpxWUpGaFN3bGRNLytGYWFEYjJyTDJSNTFDU1hXN0tVVXBY?=
 =?utf-8?B?Q1NVQTVkZnhsRmxtUVcrMDFydThROUdOb2JSenV5bnRra1JQbUp0d2ZEVVVk?=
 =?utf-8?B?RWlJemlxVUlhMkNBaWNtanpHRGFLRnJUcWsrZ2N5VFdCMXJLMStDdVJaOWow?=
 =?utf-8?B?TmpkakJudGxzY1JnUng4S0NzaTlaSGtYUjFVclBRRGVhcEppWk1peVpmVHpv?=
 =?utf-8?B?T3ljODk2S2JZMTVCYzF1eDB2ZnU1WHYvNm9ETHdPbW9ZUGlwTHU4VG9KNjZt?=
 =?utf-8?B?c0UxdXlhRldGRjFReFdOdEhJSytLd1U0NDJVa0RaaGI3aS80UzBLaXpIeEw5?=
 =?utf-8?B?bFIrWmxZbWJkdVBlTzhya05oMEx6M1VSSmR1UDlCVTVQalUyTDBSNkJDcGdl?=
 =?utf-8?B?U0swVldpU3FaNXhZM0hwQ3hiMzBKVjkycFU1SlFHY2g2R1crMUEwRzJqUWV1?=
 =?utf-8?B?TW50YnQvRElHK1RjVjJnR2ZKdkhDalZPZzYvMmRUNWovZHh1TGR6U3M0dER3?=
 =?utf-8?B?R2ZwWGc0QjFnU2xlQU12TVlxTjMyU2pIQS93MDhRdTNBNGJpaGRyTEhMSkhD?=
 =?utf-8?B?Rk9qZmtLSEJHWVM1ZUk2WXBpNWlXTG1xdHFPdXJsLzR4K2htMzdiR3dBaitM?=
 =?utf-8?B?MGZLVmx4a2tyZ1lveWlvbkxGTy9uNXE5V0NYOGFlV0xXY29TbW16U0lZeXU2?=
 =?utf-8?B?ajVNU1pzK0djWERCK3dCamxCRnp1WURDMWRTRy9qTnp6akdIVGlqbzZTN3VQ?=
 =?utf-8?B?aktEU3ZmRWcvMjI2YzJ4UVFlclRxS1RSWHVVNkIxcUNjanpqR3hoTDNuY283?=
 =?utf-8?B?L0VyVm1sSXpDNjdmRThNd0laNHY1RFREdjZIaVVYUkVnV0o1Kzg3RnJCbU9q?=
 =?utf-8?B?MHZ2OW5wT3hWM1dvRWkyZ1BobzV5MiswNCswRzlicEI0VHlwdWJzYkZRUXox?=
 =?utf-8?B?eTd6K1RuVjdwR08vZERRTjhRREZXWGFRczJmUnVMRW1YUlRjdWtUZTVad1BE?=
 =?utf-8?B?dEtuZ1ZWTlhiSzFFdzRQWVBaWk96Z09YNmEzNVJGOThhWGJKN0VzR0Z3WUw3?=
 =?utf-8?B?QjNKeVJyMzBZeDFzOFZ0dkFnL05nSldRZ2xUc28wRkRwTVYwazJJR1hxWXB0?=
 =?utf-8?B?Tlh5endaTTVrVERVbktIL3czcXgzUlFmdTZ4VnRna240YzRPdythekcvZE1O?=
 =?utf-8?B?eXZuMkNmWlNUdWs4K1pKMXd5Ujh5YWFwNlVyTFJMWG0zMjlzOFNZUkM5MXFY?=
 =?utf-8?B?VWJrOE1FeWdpb20xUHBFa0dhQm9xK1ZwS2RKcmhwL2F1bWRVUWxycjhWU1Fh?=
 =?utf-8?B?T3RVcS9xTzE5R0JvdFc0ZTF5TUl4dklIVnRYS004VE5kejBKZm1WdHBEQ3pJ?=
 =?utf-8?B?MGd4dzNIT2RKTkpLc2E1R215NmZXWWt4MEVWcDc3d1ZUZS9NakFwZEU3OHI3?=
 =?utf-8?B?VmJ5QThmaDM2eUl4VWNEVHNQakI3eThuL3hRa2E0dURaWU9NSjdKQlFkaHU2?=
 =?utf-8?Q?jywh2U?=
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: 04 Jun 2025 19:51:51.7126
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 61f7ac66-a926-42eb-7023-08dda3a14024
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:
	CH1PEPF0000AD75.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB8336

On 6/4/25 03:00, Orzel, Michal wrote:
> On 03/06/2025 23:15, Stewart Hildebrand wrote:
>> On 5/14/25 03:31, Orzel, Michal wrote:
>>> On 13/05/2025 21:54, Stewart Hildebrand wrote:
>>>> Similarly to fba1b0974dd8, when a device is passed through to a
>>>> direct-map dom0less domU, the xen,reg ranges may overlap with the
>>>> extended regions. Remove xen,reg from direct-map domU extended regions.
>>>>
>>>> Introduce rangeset_count_ranges().
>>>>
>>>> Take the opportunity to update the comment ahead of find_memory_holes().
>>>>
>>>> Signed-off-by: Stewart Hildebrand 
>>>> ---
>>>> v2->v3:
>>>> * new patch
>>>> ---
>>>>  xen/arch/arm/domain_build.c | 57 +++++++++++++++++++++++++++++++++----
>>>>  xen/common/rangeset.c       | 14 +++++++++
>>>>  xen/include/xen/rangeset.h  |  2 ++
>>>>  3 files changed, 68 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>>>> index b189a7cfae9f..3cdf5839bc98 100644
>>>> --- a/xen/arch/arm/domain_build.c
>>>> +++ b/xen/arch/arm/domain_build.c
>>>> @@ -824,15 +824,17 @@ static int __init handle_pci_range(const struct dt_device_node *dev,
>>>>  }
>>>>  
>>>>  /*
>>>> - * Find the holes in the Host DT which can be exposed to Dom0 as extended
>>>> - * regions for the special memory mappings. In order to calculate regions
>>>> - * we exclude every addressable memory region described by "reg" and "ranges"
>>>> - * properties from the maximum possible addressable physical memory range:
>>>> + * Find the holes in the Host DT which can be exposed to Dom0 or a direct-map
>>>> + * domU as extended regions for the special memory mappings. In order to
>>>> + * calculate regions we exclude every addressable memory region described by
>>>> + * "reg" and "ranges" properties from the maximum possible addressable physical
>>>> + * memory range:
>>>>   * - MMIO
>>>>   * - Host RAM
>>>>   * - PCI aperture
>>>>   * - Static shared memory regions, which are described by special property
>>>>   *   "xen,shared-mem"
>>>> + * - xen,reg mappings
>>>>   */
>>>>  static int __init find_memory_holes(const struct kernel_info *kinfo,
>>>>                                      struct membanks *ext_regions)
>>>> @@ -914,6 +916,13 @@ static int __init find_memory_holes(const struct kernel_info *kinfo,
>>>>          }
>>>>      }
>>>>  
>>>> +    if ( kinfo->xen_reg_assigned )
>>>> +    {
>>>> +        res = rangeset_subtract(mem_holes, kinfo->xen_reg_assigned);
>>>> +        if ( res )
>>>> +            goto out;
>>>> +    }
>>>> +
>>>>      start = 0;
>>>>      end = (1ULL << p2m_ipa_bits) - 1;
>>>>      res = rangeset_report_ranges(mem_holes, PFN_DOWN(start), PFN_DOWN(end),
>>>> @@ -994,11 +1003,30 @@ static int __init find_domU_holes(const struct kernel_info *kinfo,
>>>>      return res;
>>>>  }
>>>>  
>>>> +static int __init rangeset_to_membank(unsigned long s_gfn, unsigned long e_gfn,
>>>> +                                      void *data)
>>>> +{
>>>> +    struct membanks *membank = data;
>>>> +    paddr_t s = pfn_to_paddr(s_gfn);
>>>> +    paddr_t e = pfn_to_paddr(e_gfn + 1) - 1;
>>>> +
>>>> +    if ( membank->nr_banks >= membank->max_banks )
>>>> +        return 0;
>>>> +
>>>> +    membank->bank[membank->nr_banks].start = s;
>>>> +    membank->bank[membank->nr_banks].size = e - s + 1;
>>>> +    membank->nr_banks++;
>>>> +
>>>> +    return 0;
>>>> +}
>>>> +
>>>>  static int __init find_host_extended_regions(const struct kernel_info *kinfo,
>>>>                                               struct membanks *ext_regions)
>>>>  {
>>>>      int res;
>>>>      struct membanks *gnttab = membanks_xzalloc(1, MEMORY);
>>>> +    struct membanks *xen_reg = membanks_xzalloc(
>>>> +        max(1, rangeset_count_ranges(kinfo->xen_reg_assigned)), MEMORY);
>>> You allocate at least 1 membank even though xen_reg_assigned may be empty because:
>>>  - this function is called for hwdom - no xen,reg
>>>  - there may be no xen,reg i.e. no passthrough
>>
>> Ah, sorry, there's no need to allocate at least 1. This can just be:
>>
>>     struct membanks *xen_reg = membanks_xzalloc(
>>         rangeset_count_ranges(kinfo->arch.xen_reg_assigned), MEMORY);
> No, it cannot. membanks_xzalloc() calls xzalloc_flex_struct(). If you pass 0
> as size, the latter will calculate offset to FAM[0]. In other words, the
> allocation will succeed but only for members up to FAM[0] (i.e. only for struct
> membanks_hdr).

If we pass 0 as the size, these members (and their ->common.*
counterparts) will be allocated:
xen_reg->nr_banks
xen_reg->max_banks
xen_reg->type

but there will not be allocated any space for the flexible array member:
xen_reg->bank[]

Since ->max_banks will be set to 0, and ->nr_banks shouldn't exceed
->max_banks, it should work. At least for the (inner) loop in
find_unallocated_memory(), when ->nr_banks is 0, it won't dereference
->bank[]. FWIW, I also tested this with UBSAN enabled.

I admit it does give me a weird feeling not allocating any space for a
member in a struct, but it's a C standard flexible array member, and the
array's size would be 0. We deviated relevant MISRA rule 18.7 in
b87697fc1a6f ("automation/eclair: fully deviate MISRA C:2012 Rules 5.7
and 18.7").

With that said, I'd be happy either way (i.e. either allocating exactly
what's returned by rangeset_count_ranges() or max(1,
rangeset_count_ranges()), but I just want to ensure we have the same
understanding on the technicalities.

> Also, even if you conditionally allocate for xen_reg_assigned or set NULL, in
> latter case you will end up with mem_banks containing NULL member. AFAICT that's
> not something expected by the users of mem_banks (+ it gives unneeded iteration).

Agreed, it would be a bad idea to set xen_reg = NULL (leading to a NULL
member in mem_banks), because then find_unallocated_memory() would not
be happy.


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 19:53:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 19:53:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005913.1385231 (Exim 4.92)
	(envelope-from )
	id 1uMuAX-0007iZ-NB; Wed, 04 Jun 2025 19:53:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005913.1385231; Wed, 04 Jun 2025 19: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 1uMuAX-0007iS-KO; Wed, 04 Jun 2025 19:53:01 +0000
Received: by outflank-mailman (input) for mailman id 1005913;
 Wed, 04 Jun 2025 19:52:59 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uMuAV-0007iF-OL
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 19:52:59 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uMuAV-0023Fw-0Y;
 Wed, 04 Jun 2025 19:52:59 +0000
Received: from [2a02:8012:3a1:0:dd42:978c:f857:f7b]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uMuAV-005RgB-0Y;
 Wed, 04 Jun 2025 19:52: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=OACipzjAlCNCN9PanSeoIOjwbI77IZdSjM7We3jlyxg=; b=JISu1V6zL5D4k+WRME/zVHYwrj
	T9ieoxjfU6Z98EtWceXDDOvIg08/WrBTYOSjY8bCxa2uVKSWiByQZ9ghCiGDlFDpsbCuC7787nnqq
	aHCAI7lqV8CcvLFBn9P1hyIjSsVh/BKNs/jMBtg3nnPAe7fC2fhWyXQTPn17p21Zny+E=;
Message-ID: 
Date: Wed, 4 Jun 2025 20:52:56 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v11 4/7] xen/arm: smmuv3: Add PCI devices support for
 SMMUv3
Content-Language: en-GB
To: Demi Marie Obenour , xen-devel@lists.xenproject.org
Cc: Bertrand Marquis ,
 Stefano Stabellini ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Stewart Hildebrand ,
 Mykyta Poturai 
References: 
 <71741747bdc0cfcacbe86e66ddd6239ea2f5a3af.1748422217.git.mykyta_poturai@epam.com>
 <9bfc305b-602e-4c96-bd7a-763075e506d7@gmail.com>
 <56e44ec8-c9c0-4d58-98f3-730cc1c1bb86@xen.org>
 <62b32285-8ce5-4bee-b3b7-66e3a91a0a26@gmail.com>
From: Julien Grall 
In-Reply-To: <62b32285-8ce5-4bee-b3b7-66e3a91a0a26@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Demi,

On 04/06/2025 19:57, Demi Marie Obenour wrote:
> On 6/4/25 08:48, Julien Grall wrote:
>> Hi Demi,
>>
>> When replying to a thread, please keep the folks in CC unless there is a
>> reason to drop them. Sending to just xen-devel is likely going to be
>> lost. I personally don't always keep an eyes on discussion where I am
>> not CCed, there are too many!
>>
>> So adding re-adding the CC for you and keeping your reply as-is.
>>
>> On 29/05/2025 03:10, Demi Marie Obenour wrote:
>>> On 5/28/25 05:12, Mykyta Poturai wrote:
>>>> From: Rahul Singh 
>>>>
>>>> Implement support for PCI devices in the SMMU driver. Trigger iommu-map
>>>> parsing when new PCI device is added. Add checks to assign/deassign
>>>> functions to ensure PCI devices are handled correctly. Implement basic
>>>> quarantining.
>>>>
>>>> All pci devices are automatically assigned to hardware domain if it exists
>>>> to ensure it can probe them.
>>> This is only safe for devices present at boot time.  It’s not safe for
>>> hotplugged devices, which should be quarantined.
> 
> Thank you!  This makes me wonder if Thunderbird is a good choice for an
> email client, or if I should use something like Mutt or Aerc.

I have been using Thunderbird for the past 10 years without any issue.

The UI tends to offer me two options "reply" and "reply all". I need to 
click on the latter to CC everyone.

I am not sure whether you can hide the "reply" (so drop all the CC) only.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Wed Jun 04 20:18:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 20:18:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005921.1385240 (Exim 4.92)
	(envelope-from )
	id 1uMuYe-0002Gu-Jg; Wed, 04 Jun 2025 20:17:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005921.1385240; Wed, 04 Jun 2025 20:17:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMuYe-0002Gn-H7; Wed, 04 Jun 2025 20:17:56 +0000
Received: by outflank-mailman (input) for mailman id 1005921;
 Wed, 04 Jun 2025 20:17: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 1uMuYe-0002Gg-3A
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 20:17: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 fdc4ca27-4180-11f0-a300-13f23c93f187;
 Wed, 04 Jun 2025 22:17:53 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 485EAA50754;
 Wed,  4 Jun 2025 20:17:51 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 10B3FC4CEE4;
 Wed,  4 Jun 2025 20:17: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: fdc4ca27-4180-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749068270;
	bh=fi3QD+f9jeY7VeRt7KTdukORp7vu2ILca9M6e90IBbI=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=TfozS2gOGTXafifdhwUw/RZEpp9IwgBn5AqjECPscNI59xZTZTF4tH/XL/FfRfl+G
	 wumyhEA6l/WJc7FBlLQOR/HZGsfGJBnKnvjQA/pT0RUkgWmZ3ZScsQElvwBrgrBltu
	 mwqvbJPvy9L1q7r5DdSKvy59N05IfRtypuePcYz0Mlb595pLFX4qEIjDTkBBUZUQmT
	 BL3QLIzdlPYcjxy+5VCkOZxV5w+iR8jGwmOS7cuhxJvLVRARsvRPEwFCNIntDk52c+
	 H9TWicNwuquGMP9UbBZSgVsWYy71lVHH/3krKaCHt6eBHHKTlpFcdDV0fSvRLFlvdw
	 VyCiuaKLgpP7g==
Date: Wed, 4 Jun 2025 13:17:49 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
cc: Andrew Cooper , 
    Anthony PERARD , 
    Stefano Stabellini , 
    xen-devel@lists.xenproject.org, Anthony PERARD , 
    Doug Goldstein 
Subject: Re: [XEN PATCH 9/9] CI: Add timing to junit
In-Reply-To: 
Message-ID: 
References: <20250603124222.52057-1-anthony@xenproject.org> <20250603124222.52057-10-anthony@xenproject.org>   <384fd17a-9236-4727-b564-543edff65e9e@citrix.com>
 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1641201751-1749068271=:2495561"

  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-1641201751-1749068271=:2495561
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Wed, 4 Jun 2025, Marek Marczykowski-Górecki wrote:
> On Wed, Jun 04, 2025 at 11:57:11AM +0100, Andrew Cooper wrote:
> > On 04/06/2025 9:48 am, Anthony PERARD wrote:
> > > On Tue, Jun 03, 2025 at 11:35:22AM -0700, Stefano Stabellini wrote:
> > >> On Tue, 3 Jun 2025, Anthony PERARD wrote:
> > >>> From: Anthony PERARD 
> > >>>
> > >>> Signed-off-by: Anthony PERARD 
> > >>> ---
> > >>>  automation/scripts/run-tools-tests | 5 ++++-
> > >>>  1 file changed, 4 insertions(+), 1 deletion(-)
> > >>>
> > >>> diff --git a/automation/scripts/run-tools-tests b/automation/scripts/run-tools-tests
> > >>> index 852c1cfbcf..e38cc4068c 100755
> > >>> --- a/automation/scripts/run-tools-tests
> > >>> +++ b/automation/scripts/run-tools-tests
> > >>> @@ -18,9 +18,12 @@ for f in "$1"/*; do
> > >>>          continue
> > >>>      fi
> > >>>      echo "Running $f"
> > >>> -    printf '  \n' "$f" >> "$xml_out"
> > >>> +    time_start=$EPOCHREALTIME
> > >>>      "$f" 2>&1 | tee /tmp/out
> > >>>      ret=${PIPESTATUS[0]}
> > >>> +    time_end=$EPOCHREALTIME
> > >>> +    time_test="$(bc <<<"$time_end - $time_start")"
> > >> As it looks like no other scripts need bc at the moment but we already
> > >> rely on awk (automation/scripts/xilinx-smoke-dom0less-arm64.sh) I'd
> > >> prefer this version:
> > >>
> > >> time_test="$(awk "BEGIN {print $time_end - $time_start}")"
> > > You mean I have to choose between busybox and busybox?
> > >
> > > $ ls -l $(which bc awk)
> > > lrwxrwxrwx    1 root     root            12 Feb 13 23:19 /usr/bin/awk -> /bin/busybox
> > > lrwxrwxrwx    1 root     root            12 Feb 13 23:19 /usr/bin/bc -> /bin/busybox
> > >
> > > :-)
> > >
> > > I guess it doesn't really matter.
> > >
> > > One difference though:
> > > $ awk "BEGIN {print $time_end - $time_start}"
> > > 3.28798
> > > $ bc <<<"$time_end - $time_start"
> > > 3.287982
> > >
> > > awk is less precise, but I guess that doesn't matter as well, gitlab UI
> > > isn't going to show the extra digits.
> > >
> > > So I guess I can change to use `awk` instead, just in case for some
> > > reason `bc` isn't present, since `awk` seems mandatory for many of our
> > > scripts.
> > >
> > > Thanks,
> > 
> > bc is a normal posix utility just like awk is, so there's no change in
> > dependencies caused by this.
> 
> Linux requires bc for building, and I _very_ often find systems where it
> isn't installed by default (by awk is)...
> Anyway, that's probably irrelevant in the CI container that has busybox
> for both.

Yes, I see the same. Honestly, I wouldn't mind having a dependecy on bc,
it is common enough and available enough, it is just that we are not
doing a great job at tracking this type of dependencies in test scripts,
so I just thought the less we have the better and in this case there is
an easy solution. Anyway, this is not the hill I am hill I am going to
die on.
--8323329-1641201751-1749068271=:2495561--


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 21:35:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 21:35:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1005970.1385251 (Exim 4.92)
	(envelope-from )
	id 1uMvlp-0003Ft-1s; Wed, 04 Jun 2025 21:35:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1005970.1385251; Wed, 04 Jun 2025 21:35:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMvlo-0003Fm-VM; Wed, 04 Jun 2025 21:35:36 +0000
Received: by outflank-mailman (input) for mailman id 1005970;
 Wed, 04 Jun 2025 21:35:35 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uMvln-0003Fg-Sk
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 21:35:35 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d83ca4cf-418b-11f0-a300-13f23c93f187;
 Wed, 04 Jun 2025 23:35:34 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 772DD6115E;
 Wed,  4 Jun 2025 21:35:32 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 40313C4CEE4;
 Wed,  4 Jun 2025 21:35: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: d83ca4cf-418b-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749072932;
	bh=TqRbb2Q1Gkn8kaZ/od4bxmZLkh5e3Ze666f1MwY/wjI=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=c64vpUJDSIdCwFnb9wtJFt5zwRDk1BdWBJdys2FayArSgBBeN532xhK0fMk13YCt2
	 efz4wvq0REk63sO3o871xDlh6W9dX+JlCvyryzI10whxD2AJoUeXURXkjtAJ1gU8ao
	 bX6qOIaLgabWXXL2RwdrcKA+GWPCpkEr5aMQmT/USuFkzzWBGbbsdprTawV4+rPMp2
	 51aT6VldPLsgjhH1QlybNadiIhBzMMFT79U/mCfRCHVFpxGpcr4DE8wWg9BdYfdl3K
	 K91TJldwR80ZCQNutED+7uiTZAasi+y5fEUT2cIvThK0i99Pbr3x57FU/xfja8uuuo
	 QqjAv9mRLde+w==
Date: Wed, 4 Jun 2025 14:35:30 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jahan Murudi 
cc: "Orzel, Michal" , 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Volodymyr Babchuk , 
    "xen-devel@lists.xenproject.org" 
Subject: RE: [PATCH v2] arm/vgic-v2: Fix undefined behavior in
 vgic_fetch_itargetsr()
In-Reply-To: 
Message-ID: 
References: <20250601163212.2988162-1-jahan.murudi.zg@renesas.com> <01c5ad19-2add-4270-948d-ecdf3d5e8bd6@amd.com> 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

Yes, I committed it. Thank you for the ping.

Cheers,

Stefano

On Wed, 4 Jun 2025, Jahan Murudi wrote:
>  Hi Stefano/Julien,
> 
> This v2 patch was reviewed-by Michal Orzel on 2nd June. Could it be merged?
> 
> Link : https://patchwork.kernel.org/project/xen-devel/patch/20250601163212.2988162-1-jahan.murudi.zg@renesas.com/
> 
> Thanks, 
> Jahan Murudi
> 
> 
> -----Original Message-----
> From: Orzel, Michal  
> Sent: 02 June 2025 12:24
> To: Jahan Murudi ; xen-devel@lists.xenproject.org
> Cc: Stefano Stabellini ; Julien Grall ; Bertrand Marquis ; Volodymyr Babchuk 
> Subject: Re: [PATCH v2] arm/vgic-v2: Fix undefined behavior in vgic_fetch_itargetsr()
> 
> 
> 
> On 01/06/2025 18:32, Jahan Murudi wrote:
> > The current implementation performs left shift operations that may 
> > trigger undefined behavior when the target value is too large. This patch:
> > 
> > 1. Changes the shift from signed (1) to unsigned (1U) to ensure 
> > well-defined
> NIT for the future: Use imperative mood
> 
> >    behavior for all valid target values 2. Maintains identical 
> > functionality while fixing the UBSAN warning
> > 
> > The issue was detected by UBSAN:
> > (XEN) UBSAN: Undefined behaviour in arch/arm/vgic-v2.c:73:56
> > (XEN) left shift of 128 by 24 places cannot be represented in type 'int'
> > (XEN) Xen WARN at common/ubsan/ubsan.c:174
> > 
> > Signed-off-by: Jahan Murudi 
> Reviewed-by: Michal Orzel 
> 
> ~Michal
> 
> > 
> > ---
> > Changed since v1:
> >  * Added space after subject line
> > ---
> >  xen/arch/arm/vgic-v2.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c index 
> > a19d610178..642407fd5b 100644
> > --- a/xen/arch/arm/vgic-v2.c
> > +++ b/xen/arch/arm/vgic-v2.c
> > @@ -70,7 +70,7 @@ static uint32_t vgic_fetch_itargetsr(struct vgic_irq_rank *rank,
> >      offset &= ~(NR_TARGETS_PER_ITARGETSR - 1);
> >  
> >      for ( i = 0; i < NR_TARGETS_PER_ITARGETSR; i++, offset++ )
> > -        reg |= (1 << read_atomic(&rank->vcpu[offset])) << (i * NR_BITS_PER_TARGET);
> > +        reg |= (1U << read_atomic(&rank->vcpu[offset])) << (i * 
> > + NR_BITS_PER_TARGET);
> >  
> >      return reg;
> >  }
> 
> 


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 23:10:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 23:10:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006005.1385276 (Exim 4.92)
	(envelope-from )
	id 1uMxFF-00068x-Od; Wed, 04 Jun 2025 23:10:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006005.1385276; Wed, 04 Jun 2025 23:10:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMxFF-00068M-MA; Wed, 04 Jun 2025 23:10:05 +0000
Received: by outflank-mailman (input) for mailman id 1006005;
 Wed, 04 Jun 2025 23:10: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 1uMxFE-0005oG-12
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 23:10:04 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0a761421-4199-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 01:10:01 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 4D4B761139;
 Wed,  4 Jun 2025 23:10:00 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 008B8C4CEE4;
 Wed,  4 Jun 2025 23:09:58 +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: 0a761421-4199-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749078600;
	bh=9hPBLa6j3nmZiASL002dh5+4P4fO7fZUVLERjQNoOek=;
	h=Date:From:To:cc:Subject:From;
	b=RW9Lrgm9o3ErOnQzUfWj1aEmj547mXpmBm4/gXmZi3ny9trmzaWvBDvHet4aLC5is
	 3n5iw8VE2lEA9V6OBWwi1AwVOgZuz0MJWPBhzEH8ejFt+t19Zf7B7BCNrO1PaBxFQO
	 2jGuWB1tsTZp1fBf2qFOuZfVZDNt3m2hb779Yb2HrWA2BNPHBnVIIurxF0JybRWQZ9
	 6OJIMxnolgYX/Nx2K6nTGD0WEbzUEiH5HJ2MSqCLC7UCeCLXnUN9gO3zdzB3s1T1zF
	 jYib+gYSTDYoXYWnEOlPEVv2eV4jjlsS1mXyh4scBciP9kPa3jkWE7kCxn63aqlimF
	 2Foy237COEfGg==
Date: Wed, 4 Jun 2025 16:09:57 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: xen-devel@lists.xenproject.org
cc: sstabellini@kernel.org, andrew.cooper3@citrix.com, 
    anthony.perard@vates.tech, michal.orzel@amd.com, jbeulich@suse.com, 
    julien@xen.org, roger.pau@citrix.com
Subject: [PATCH] xen: add header guards to generated asm generic headers 
Message-ID: 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

MISRA D4.10 requires to have proper header guards in place in all header
files. Add header guards for generated asm generic headers as well.

Suggested-by: Jan Beulich 
Signed-off-by: Stefano Stabellini 

diff --git a/xen/scripts/Makefile.asm-generic b/xen/scripts/Makefile.asm-generic
index b0d356bfa3..a44844bed0 100644
--- a/xen/scripts/Makefile.asm-generic
+++ b/xen/scripts/Makefile.asm-generic
@@ -32,7 +32,12 @@ old-headers := $(wildcard $(obj)/*.h)
 unwanted    := $(filter-out $(generic-y) $(generated-y),$(old-headers))
 
 quiet_cmd_wrap = WRAP    $@
-      cmd_wrap = echo "\#include " > $@
+      cmd_wrap = \
+	upper=$$(echo $*.h | tr a-z A-Z | tr '/.' '__'); \
+	printf "\#ifndef ASM_GENERIC_$${upper}\n" > $@; \
+	printf "\#define ASM_GENERIC_$${upper}\n" >> $@; \
+	printf "\#include \n" >> $@; \
+	printf "\#endif /* ASM_GENERIC_$${upper} */\n" >> $@
 
 quiet_cmd_remove = REMOVE  $(unwanted)
       cmd_remove = rm -f $(unwanted)


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 23:11:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 23:11:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006011.1385286 (Exim 4.92)
	(envelope-from )
	id 1uMxGx-0006k8-3U; Wed, 04 Jun 2025 23:11:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006011.1385286; Wed, 04 Jun 2025 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 1uMxGx-0006k1-0v; Wed, 04 Jun 2025 23:11:51 +0000
Received: by outflank-mailman (input) for mailman id 1006011;
 Wed, 04 Jun 2025 23:11: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 1uMxGv-0006j8-BQ
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 23:11: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 4a16514b-4199-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 01:11:48 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id DC3D65C10FB;
 Wed,  4 Jun 2025 23:09:29 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0E2A0C4CEE4;
 Wed,  4 Jun 2025 23:11: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: 4a16514b-4199-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749078706;
	bh=7YWJ98uD5sIubwpYJqzx1jwQR7qtLfxm8I2SmWy3q2c=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=e/Cdj74by1roua4GiZmNVdWbSgWmjLfLKJWNIu4xPAhzmLqLl9clN8f9A0itc8lYP
	 Bvo98NXQ1ah+xagEO/ymfPT1y3evvxABmn4qrnLz9976y/vfX7p4jxJtJprsgkFnX9
	 4Wdc/pSRS8R+1NgkDGqAKsv3HbvNC8b++NCxpR4aA7M5Fa3PBWGvoAB+J6tfD1yQv5
	 LnYHB5yVa6Xbc1Co8Iuq0sf863pF2xney3NU7p1Wk5dR1XF5579E28Lb5v6edE1wht
	 +hh29GfLN/e3z1FX+uqyMeklr4XyUmNYMfl61xY81mWKg10BPlFY/iUhsujKoiS3tj
	 jbzupYfiYmWOQ==
Date: Wed, 4 Jun 2025 16:11:43 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Stefano Stabellini , 
    Andrew Cooper , 
    Stefano Stabellini , michal.orzel@amd.com, 
    julien@xen.org, roger.pau@citrix.com, bertrand.marquis@arm.com, 
    federico.serafini@bugseng.com, Nicola Vetrini , 
    xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3] automation/eclair: update configuration of D4.10
In-Reply-To: <84a62d70-a60b-475c-b0d8-275528dd4f33@suse.com>
Message-ID: 
References:  <84a62d70-a60b-475c-b0d8-275528dd4f33@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 4 Jun 2025, Jan Beulich wrote:
> On 04.06.2025 03:11, Stefano Stabellini wrote:
> > MISRA C Directive 4.10 states that "Precautions shall be taken in order
> > to prevent the contents of a header file being included more than
> > once".
> > 
> > Add a SAF tag to the existing comment on top of cpufeatures.h.
> > Add a header inclusion guard to compile.h.
> > 
> > Update ECLAIR configuration to:
> > - extend existing deviation to other comments explicitly saying a file
> >   is intended for multiple inclusion;
> > - extend existing deviation to other autogenerated files;
> > - tag the guidelines as clean.
> > 
> > Update deviations.rst accordingly.
> > 
> > Signed-off-by: Federico Serafini 
> > Signed-off-by: Stefano Stabellini 
> > ---
> > Changes in v3:
> > - fix copy/paste error in process-banner.sed
> > - fix comment in cpufeatures.h so that ECLAIR picks it up properly
> > - remove xlat.h deviation thanks to Jan's patch
> 
> With this in mind, ...
> 
> > --- a/docs/misra/deviations.rst
> > +++ b/docs/misra/deviations.rst
> > @@ -30,6 +30,19 @@ Deviations related to MISRA C:2012 Directives:
> >         not to add an additional encapsulation layer.
> >       - Tagged as `deliberate` for ECLAIR.
> >  
> > +   * - D4.10
> > +     - Files that are intended to be included more than once (and have
> > +       a comment that says this explicitly) do not need to conform to the
> > +       directive.
> > +     - Tagged as `safe` for ECLAIR.
> > +
> > +   * - D4.10
> > +     - There are autogenerated files that do not need to comply to the
> > +       directive.
> > +     - Tagged as `safe` for ECLAIR. Such files are:
> > +        - xen/include/generated/autoconf.h
> > +        - xen/arch/{arm,x86}/include/generated/asm/\*
> 
> ... why not deal with at least the latter (we may not want to fiddle with kconfig
> sources) as well?

Is this what you had in mind?
https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2506041605090.2495561@ubuntu-linux-20-04-desktop/


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 23:36:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 23:36:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006038.1385296 (Exim 4.92)
	(envelope-from )
	id 1uMxeE-00017V-U9; Wed, 04 Jun 2025 23:35:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006038.1385296; Wed, 04 Jun 2025 23:35: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 1uMxeE-00017O-RJ; Wed, 04 Jun 2025 23:35:54 +0000
Received: by outflank-mailman (input) for mailman id 1006038;
 Wed, 04 Jun 2025 23:35: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 1uMxeD-00017I-Dt
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 23:35:53 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20619.outbound.protection.outlook.com
 [2a01:111:f403:2418::619])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a5251c0e-419c-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 01:35:50 +0200 (CEST)
Received: from SJ0PR03CA0008.namprd03.prod.outlook.com (2603:10b6:a03:33a::13)
 by DS7PR12MB5838.namprd12.prod.outlook.com (2603:10b6:8:79::17) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Wed, 4 Jun
 2025 23:35:40 +0000
Received: from MWH0EPF000989E7.namprd02.prod.outlook.com
 (2603:10b6:a03:33a:cafe::93) by SJ0PR03CA0008.outlook.office365.com
 (2603:10b6:a03:33a::13) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Wed,
 4 Jun 2025 23:35:39 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 MWH0EPF000989E7.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.8792.29 via Frontend Transport; Wed, 4 Jun 2025 23:35:39 +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 Jun
 2025 18:35:38 -0500
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 Jun
 2025 18:35:38 -0500
Received: from ubuntu-linux-20-04-desktop.tail503a2a.ts.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; Wed, 4 Jun 2025 18:35:37 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a5251c0e-419c-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=bIZnqQcQdjBWrygGQrlBxO6Au3F0so/8uIA3aSH+9hWaa5JRwPM6y6T9LtTNp/qNMfn1AZvmfELfKEyZnjaHElboIT5V9eSwxJGKu5CoxKx2kx087zmdiRmKVeaw8nDfpAK9+zFMPzKuH/INxbgPO0AZvaWrQpRxxw0kaC0wR6sYZM7rF3TzyZVz8NGXZqj0X/0gK/2OfSmCOgUkZlqDUg5EpsIdCxBpAuAds62ZNHb5wy8Kre6OuZylBkH1wFAZ1jIMxIHFHZflXNk5UXb6EU3/v8ln2wj/TMl4I67kmxpX9vrfxuvB2xrybfJIBwgPBWxmqiIxku3lcPJqiCz9yw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=uleT6ILVG7kx3wLTyOv2IoCuR7/et9OzSZjso4aXr6I=;
 b=STQSxsj+aZTLBASuRlTwZDNoXHb8iP/SqSFffsQyAQxT7+9Fg3GHdT1W7+9QZOD2hhuxUXbygAhzzb9f9wpRsC4c6Yaju2+HOPEKDoPkeg4JEiySBsUYy455rZVXkydICRkxYxdjeioFXgIQTleIeV8antg4I0t1iG1SRe8JcmW5sDBFaykYp2Ugj9tzbvvqi9sNNY/NY3IUmr2DhpvurGzlo5H3fCRB8CCDBgUH7DK9BVT9QEcUn4o8RXu0joo2+mtueish2j/e0X3OQdWjlNqhf86H5oKLJmgv11Gcd1WKbaRiUHyP1pIUmdhotD896QaNrBD60pvX4sjPDNb6lg==
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=uleT6ILVG7kx3wLTyOv2IoCuR7/et9OzSZjso4aXr6I=;
 b=CxT5bU4sevjz8DIbYgd3zXCUu+i9paFn6ld73isDB4WqgSUUhGU9RL9E/myoB2R4FeiFITtz34t5cbCZSq2osvLbtc1KyAvSgajibsb+YSDfuvJ8AebiWV/DJQHcI2MsL8UnlQCWgritaxG0MxMGKhDS6AxIrket35mZHXS4ZR4=
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: Stefano Stabellini 
To: 
CC: Jan Beulich , Andrew Cooper
	, =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Alessandro Zucchelli
	
Subject: [PATCH] x86: remove memcmp calls non-compliant with Rule 21.16.
Date: Wed, 4 Jun 2025 16:35:37 -0700
Message-ID: <20250604233537.2892206-1-stefano.stabellini@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: MWH0EPF000989E7:EE_|DS7PR12MB5838:EE_
X-MS-Office365-Filtering-Correlation-Id: b8e5b231-f937-4755-acde-08dda3c083a3
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:
	=?us-ascii?Q?nzrhkUGhs1n5yosw8wwGYWTrRbp6g8xsSjkhw8jcOvrO4jqeYh6Q52DlZ4dL?=
 =?us-ascii?Q?CIffi6oWdY/M9RovNKXdzCtcDWz2q88sAetEdIheGUsPsQwOtFgqXHQoTmpi?=
 =?us-ascii?Q?xk1BttcwkGx0LhKIOOhHT7o2ZJCACA7p1P44TRHD9ymBUaTM/Hfj3uBnWBv9?=
 =?us-ascii?Q?r4SwmdtDkDIsAopKmU5t4uLYpDiKqSqvZbJRw+Tbcd6dSeq2+NcTrCU+BJDi?=
 =?us-ascii?Q?BoB/1/xt0aJTq0Z7oPDKePz32E+ykPrATbk/MhEVqu8S0yK1Ht/XmP69iLtH?=
 =?us-ascii?Q?xuMvJSY+7O4+wYMhGgxiJJMTW1/RVORkEd2pIehdlF43x57RzfiorFCoHCeK?=
 =?us-ascii?Q?b19JhK6iTnbIy/6QlUpvHwl4w/dw1NrxaCcC21xynMEcC0IkOARg1Ra/NOzY?=
 =?us-ascii?Q?+/aTu9TVeqxbjvgE2RViRPxumLezTe50d1ezOIog26Yw4yfKiW8DZuNoFZr6?=
 =?us-ascii?Q?Cuszu+zm0Z8uFscD7Gz74EoIT1aLArzwQ2Cxf7q6OID08wZTdp1GojO6n4uf?=
 =?us-ascii?Q?DbveQFY+pDylyoFItu10UvLcJPVe/5wZbs7LN4UXD9FKKMIUmyiVSVwtJEOn?=
 =?us-ascii?Q?ureQ5EU2X9Z/R1yAWcr46+AK3HkH5f3JS/ji7cXbNakQOEbAwJfITmBJC4gP?=
 =?us-ascii?Q?VJDF7MoXQnr4s7gY/+hHdaqFwEEYaXF/V0MlLzWMS9qkRDKwa6XEcLOsVBX0?=
 =?us-ascii?Q?sxmPFJVacnkfBSbraJpLs940Zxojditeobw8KG/X2Lj0PflPOTQhQiLcCkgP?=
 =?us-ascii?Q?Z/b72XW9OjacJB68qkFUanH3+GzIcsZL8wZzR38Nm8tyGmn2n7clL6og7ZhU?=
 =?us-ascii?Q?jCwkYI0DOOej/JA+MzwhpHqp03QNYM5AuXIxqccU8SO0E4E0gGgC6rSQdjQ/?=
 =?us-ascii?Q?s8ae0MIM5JrgL7rO7cQJNCK7ebJFsUw4lfhswDN+3HIEoj7Qd4VQ3kLvtBGj?=
 =?us-ascii?Q?A65aVglkBM18TSEKFaY75TYzbXk1HSUoriJ0nTBmCZ9NZM/V4Uog3gDptgOh?=
 =?us-ascii?Q?RCjqrHYiasiSYdPDmW3Us1anfvlp5GeaLbw3NiNCWxSgVm/V21M3KyR3TVGC?=
 =?us-ascii?Q?BVh5yExGivc8xYmlYjzTH1xfiPUuVVKUm6W9RhANWh4Cs6Xx3CvsMWe82+dj?=
 =?us-ascii?Q?XeNYUvOPBzcS1CHp3dkwMy8bFm5Tk4MIYMoy3CBwyis2YTFf8Lg0yAnYJFhX?=
 =?us-ascii?Q?2Y5vljyeLEheb1CuzTYuzjz/A/ybbr/7ff70wItZiV5nipgyeIMbyyihR+TR?=
 =?us-ascii?Q?TQhKwUPISA3OUvjB3LZnK9K7aJnf5NVW2W1lNrxDtbMgMBbJkjxyhUFVBC8/?=
 =?us-ascii?Q?g0AlI2z+1g7aC3EDKhtYnTsTIe9j4iAM4ceqyQCEtWzMWcRRHCzrTV/Hc8Rq?=
 =?us-ascii?Q?Dod11DVhPIL0F/Yky9VHCnArV7tFL7GGJf4nhlN6WnkafCjg2nV3dRwyEcsa?=
 =?us-ascii?Q?FsQ/FFQSgjfRukZBYJ/3cHumUsrz3uAip47IgVlsGYGugXKC6SNnjzowkyOr?=
 =?us-ascii?Q?EMTX7/jycIWGMQjU+gqvWOQa3/PjMrjAN/Im?=
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: 04 Jun 2025 23:35:39.2559
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b8e5b231-f937-4755-acde-08dda3c083a3
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:
	MWH0EPF000989E7.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB5838

From: Alessandro Zucchelli 

MISRA C Rule 21.16 states the following: "The pointer arguments to
the Standard Library function `memcmp' shall point to either a pointer
type, an essentially signed type, an essentially unsigned type, an
essentially Boolean type or an essentially enum type".

Comparing string literals with char arrays is more appropriately
done via strncmp.

No functional change.

Signed-off-by: Alessandro Zucchelli 
---
 xen/arch/x86/dmi_scan.c | 20 ++++++++++----------
 xen/arch/x86/mpparse.c  | 10 +++++-----
 2 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/xen/arch/x86/dmi_scan.c b/xen/arch/x86/dmi_scan.c
index eb65bc86bb..b6edd7a965 100644
--- a/xen/arch/x86/dmi_scan.c
+++ b/xen/arch/x86/dmi_scan.c
@@ -233,7 +233,7 @@ void __init dmi_efi_get_table(const void *smbios, const void *smbios3)
 	const struct smbios_eps *eps = smbios;
 	const struct smbios3_eps *eps3 = smbios3;
 
-	if (eps3 && memcmp(eps3->anchor, "_SM3_", 5) == 0 &&
+	if (eps3 && strncmp(eps3->anchor, "_SM3_", 5) == 0 &&
 	    eps3->length >= sizeof(*eps3) &&
 	    dmi_checksum(eps3, eps3->length)) {
 		efi_smbios3_address = eps3->address;
@@ -241,13 +241,13 @@ void __init dmi_efi_get_table(const void *smbios, const void *smbios3)
 		return;
 	}
 
-	if (eps && memcmp(eps->anchor, "_SM_", 4) == 0 &&
+	if (eps && strncmp(eps->anchor, "_SM_", 4) == 0 &&
 	    eps->length >= sizeof(*eps) &&
 	    dmi_checksum(eps, eps->length)) {
 		efi_smbios_address = (u32)(long)eps;
 		efi_smbios_size = eps->length;
 
-		if (memcmp(eps->dmi.anchor, "_DMI_", 5) == 0 &&
+		if (strncmp(eps->dmi.anchor, "_DMI_", 5) == 0 &&
 		    dmi_checksum(&eps->dmi, sizeof(eps->dmi))) {
 			efi_dmi_address = eps->dmi.address;
 			efi_dmi_size = eps->dmi.size;
@@ -288,7 +288,7 @@ const char *__init dmi_get_table(paddr_t *base, u32 *len)
 		for (q = p; q <= p + 0x10000 - sizeof(eps.dmi); q += 16) {
 			memcpy_fromio(&eps, q, sizeof(eps.dmi));
 			if (!(instance & 1) &&
-			    memcmp(eps.dmi.anchor, "_DMI_", 5) == 0 &&
+			    strncmp(eps.dmi.anchor, "_DMI_", 5) == 0 &&
 			    dmi_checksum(&eps.dmi, sizeof(eps.dmi))) {
 				*base = eps.dmi.address;
 				*len = eps.dmi.size;
@@ -302,7 +302,7 @@ const char *__init dmi_get_table(paddr_t *base, u32 *len)
 				continue;
 			memcpy_fromio(&eps.dmi + 1, q + sizeof(eps.dmi),
 			              sizeof(eps.smbios3) - sizeof(eps.dmi));
-			if (!memcmp(eps.smbios3.anchor, "_SM3_", 5) &&
+			if (strncmp(eps.smbios3.anchor, "_SM3_", 5) == 0 &&
 			    eps.smbios3.length >= sizeof(eps.smbios3) &&
 			    q <= p + 0x10000 - eps.smbios3.length &&
 			    dmi_checksum(q, eps.smbios3.length)) {
@@ -370,14 +370,14 @@ static int __init dmi_iterate(void (*decode)(const struct dmi_header *))
 	for (q = p; q < p + 0x10000; q += 16) {
 		if (!dmi.size) {
 			memcpy_fromio(&dmi, q, sizeof(dmi));
-			if (memcmp(dmi.anchor, "_DMI_", 5) ||
+			if (strncmp(dmi.anchor, "_DMI_", 5) != 0 ||
 			    !dmi_checksum(&dmi, sizeof(dmi)))
 				dmi.size = 0;
 		}
 		if (!smbios3.length &&
 		    q <= p + 0x10000 - sizeof(smbios3)) {
 			memcpy_fromio(&smbios3, q, sizeof(smbios3));
-			if (memcmp(smbios3.anchor, "_SM3_", 5) ||
+			if (strncmp(smbios3.anchor, "_SM3_", 5) != 0 ||
 			    smbios3.length < sizeof(smbios3) ||
 			    q > p + 0x10000 - smbios3.length ||
 			    !dmi_checksum(q, smbios3.length))
@@ -406,7 +406,7 @@ static int __init dmi_efi_iterate(void (*decode)(const struct dmi_header *))
 		memcpy_fromio(&eps, p, sizeof(eps));
 		bt_iounmap(p, sizeof(eps));
 
-		if (memcmp(eps.anchor, "_SM3_", 5) ||
+		if (strncmp(eps.anchor, "_SM3_", 5) != 0 ||
 		    eps.length < sizeof(eps))
 			break;
 
@@ -429,7 +429,7 @@ static int __init dmi_efi_iterate(void (*decode)(const struct dmi_header *))
 		memcpy_fromio(&eps, p, sizeof(eps));
 		bt_iounmap(p, sizeof(eps));
 
-		if (memcmp(eps.anchor, "_SM_", 4) ||
+		if (strncmp(eps.anchor, "_SM_", 4) != 0 ||
 		    eps.length < sizeof(eps))
 			return -1;
 
@@ -437,7 +437,7 @@ static int __init dmi_efi_iterate(void (*decode)(const struct dmi_header *))
 		if (!p)
 			return -1;
 		if (dmi_checksum(p, eps.length) &&
-		    memcmp(eps.dmi.anchor, "_DMI_", 5) == 0 &&
+		    strncmp(eps.dmi.anchor, "_DMI_", 5) == 0 &&
 		    dmi_checksum(&eps.dmi, sizeof(eps.dmi))) {
 			printk(KERN_INFO "SMBIOS %d.%d present.\n",
 			       eps.major, eps.minor);
diff --git a/xen/arch/x86/mpparse.c b/xen/arch/x86/mpparse.c
index e74a714f50..c86c38f191 100644
--- a/xen/arch/x86/mpparse.c
+++ b/xen/arch/x86/mpparse.c
@@ -303,7 +303,7 @@ static int __init smp_read_mpc(struct mp_config_table *mpc)
 	int count=sizeof(*mpc);
 	unsigned char *mpt=((unsigned char *)mpc)+count;
 
-	if (memcmp(mpc->mpc_signature,MPC_SIGNATURE,4)) {
+	if (strncmp(mpc->mpc_signature,MPC_SIGNATURE,4)) {
 		printk(KERN_ERR "SMP mptable: bad signature [%#x]!\n",
 			*(u32 *)mpc->mpc_signature);
 		return 0;
@@ -720,10 +720,10 @@ static void __init efi_check_config(void)
 	__set_fixmap(FIX_EFI_MPF, PFN_DOWN(efi.mps), __PAGE_HYPERVISOR);
 	mpf = fix_to_virt(FIX_EFI_MPF) + ((long)efi.mps & (PAGE_SIZE-1));
 
-	if (memcmp(mpf->mpf_signature, "_MP_", 4) == 0 &&
-	    mpf->mpf_length == 1 &&
-	    mpf_checksum((void *)mpf, 16) &&
-	    (mpf->mpf_specification == 1 || mpf->mpf_specification == 4)) {
+	if (strncmp(mpf->mpf_signature, "_MP_", 4) == 0 &&
+            mpf->mpf_length == 1 &&
+            mpf_checksum((void *)mpf, 16) &&
+            (mpf->mpf_specification == 1 || mpf->mpf_specification == 4)) {
 		smp_found_config = true;
 		printk(KERN_INFO "SMP MP-table at %08lx\n", efi.mps);
 		mpf_found = mpf;
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Wed Jun 04 23:51:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 23:51:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006050.1385313 (Exim 4.92)
	(envelope-from )
	id 1uMxsq-0003wd-FE; Wed, 04 Jun 2025 23:51:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006050.1385313; Wed, 04 Jun 2025 23:51:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMxsq-0003vd-Aw; Wed, 04 Jun 2025 23:51:00 +0000
Received: by outflank-mailman (input) for mailman id 1006050;
 Wed, 04 Jun 2025 23:50: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 1uMxsp-0003tB-Gc
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 23:50:59 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20626.outbound.protection.outlook.com
 [2a01:111:f403:2009::626])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c1524d89-419e-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 01:50:56 +0200 (CEST)
Received: from MW4PR03CA0245.namprd03.prod.outlook.com (2603:10b6:303:b4::10)
 by CY5PR12MB6576.namprd12.prod.outlook.com (2603:10b6:930:40::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.33; Wed, 4 Jun
 2025 23:50:50 +0000
Received: from SJ5PEPF000001D0.namprd05.prod.outlook.com
 (2603:10b6:303:b4:cafe::d7) by MW4PR03CA0245.outlook.office365.com
 (2603:10b6:303:b4::10) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.24 via Frontend Transport; Wed,
 4 Jun 2025 23:50:50 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SJ5PEPF000001D0.mail.protection.outlook.com (10.167.242.52) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Wed, 4 Jun 2025 23:50:49 +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 Jun
 2025 18:50:48 -0500
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 Jun
 2025 18:50:48 -0500
Received: from xsjvictlira50.xilinx.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 via Frontend
 Transport; Wed, 4 Jun 2025 18:50:47 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c1524d89-419e-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=SAoCnEJZUM9e2xf7zrJw/q1MdAfz6kDBgqTcWODvMdUd8nBjqKXGWS4NytbP79Bl6TkGmv24G4TJC1Lu37TS4NsaPf/We4Z2O3jo+mfyk6GpPdBPBjV0KCKJoYUL4FuES8W8Bo1ZTJLfxaHUzuX9TKC27cogsQDiDIzY1WIszIem2m4KT3zfl+6SmwBJ/yjKTbM52uIyYSAgoAPivDmpqKt7pUYzFpuvKZ76MUrBCJF26wF8QNT04rTH5FSa/duBBzvu4hO0ayfhFAmcYe57GGhp6hg0UQgssUQiL/tzgX/V6VRnC7SI3jXdN10UN7HMRj/rX71o5F7+sYHE9/jooA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=uElrQ4phKJmjjzZ+5AvSPmniHWoCmEZRcshcnxDA9VY=;
 b=kthV4ENMzMTTs6LLooQAS3t9d7eAw2CX8IkuzkcvYA5OUlT896reW2Fxb5XrDdhxfC6NCkKwts3Wt0XZF5ETzvAM1LJyWTwQC7gRBn/1s/5pDte48bTqXwzso2PTjJMNFpWHxjSRklZFFSkfM+DoQx2cflBxivUKxx60eWmugGbEfaFG1/6VdQD//86uihr6nJIQUE4RFCmf33Y1t1HQlNodKBtb8rjp49nvaqF5QrfPCckS85w9fmptJfhwSJSx5/DvDLuxsDxih0uj5OPIYwyTEM069RyZWNHDAbKVgmx/0XwuuPswZGwJTd8yqghT9GEsjLYKLcD92LSY2zvk/w==
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=uElrQ4phKJmjjzZ+5AvSPmniHWoCmEZRcshcnxDA9VY=;
 b=VNvxQB5KHYFesiCRHKTrQJvct1MKBnJehzqhitbgO1N1Mag059d0HDPFuy+XPRBwNaUTOI+I6zf8qikURkuSXcq5pqG2CSe6nvLhX1xUn0RXmpCTsHBKfieAsNp83tmNHIljcCqekluqiipwRbIFty+7RSkJ0JKBPquQyZ/IZTs=
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: 
To: 
CC: Nicola Vetrini , Victor Lira
	, Andrew Cooper , "Anthony
 PERARD" , Michal Orzel , Jan
 Beulich , Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=83=C2=A9?= , "Stefano
 Stabellini" , Federico Serafini
	, Bertrand Marquis 
Subject: [PATCH 2/3] xen/arm: add missing noreturn attributes
Date: Wed, 4 Jun 2025 16:49:56 -0700
Message-ID: <20250604235034.1595881-2-victorm.lira@amd.com>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250604235034.1595881-1-victorm.lira@amd.com>
References: <20250604235034.1595881-1-victorm.lira@amd.com>
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: SJ5PEPF000001D0:EE_|CY5PR12MB6576:EE_
X-MS-Office365-Filtering-Correlation-Id: ff942b29-2088-4568-71af-08dda3c2a22d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|82310400026|7416014|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?WThFaE0vT29tcjNpLy81dThxbFAxQU5saTZoVVZOUE53blF4VDN6all5ZEds?=
 =?utf-8?B?Rmd2cjRycit6ZE5tU0JQNzdWWjFPVDRyYit5UmMxOEpsdTMyTkQ3TEU5cGlB?=
 =?utf-8?B?VXBvdS9WUysrQXAyalduQnV3NzU5UTJxNHp3QWV5Mys0UkFVU1BDSVAzTjlq?=
 =?utf-8?B?WnZmVHZ2RGxjdUxkYXMzTHF4MFB4RmdQbXZTOUhQT2U4T1JGMjIvYXN4K1Rk?=
 =?utf-8?B?SFFhYVlqRS9tK2xDcEVrNnEweDdUZ0tpWDNmOVBzK0hJT09YT1YwaHNTZmFG?=
 =?utf-8?B?L1lrdHMrL2kvam95Ynh5eXBjS01OZ3FhV1ExSU1DUDFiV2ltbk5md1k4WVZz?=
 =?utf-8?B?UE5XVVphVlNla0dlNFk4QldJZEdnMGJDVFd3VzFiQkErL3hvL2drc2pXQnBW?=
 =?utf-8?B?WDNGQXNDUCtLZWRxY3k4RHV2Kzh6SWpwZTlMTTFhMmV4NzJIWEJXRTluN29Q?=
 =?utf-8?B?bkpYQ3VyWm9GNjZHNk9IRUZ3SmJYb0s2cXlhWWprYk40eTNoSmsySDh5UW10?=
 =?utf-8?B?a1lvVTdkcEtPUkZ5WTJmaVQ0dmdhSkRMQ2U1cUxvaGJBUzVFbHk3NHE2bWhL?=
 =?utf-8?B?SzkvT2JmaVBMVkNlR3JqSWhrRkllMi9ublExYnpLYjNuZ1dxT0tkR01hUG03?=
 =?utf-8?B?azVJUTVQN0lac3ZNK3VveXhKdGVDbWVPMlN0U2NuSHlQY1IvOElwOU1BdFJO?=
 =?utf-8?B?d3F1TGpCM1RsclF6TGgybzQrdHBNRnBkM0wrZlFmSW5yTG5kSGdRMGM2c1l6?=
 =?utf-8?B?QXFoQW1wVUk3a2k1SngrclZYc0d5QWtGUU5mM2h6Njg1eGZqQm43Rjg1ZVhW?=
 =?utf-8?B?MGJPZ1FJWFNMK3cyZ0p4KzFBMSs2cEIvdWpKc0FUZjNmTWNSaVYvT25xZWh1?=
 =?utf-8?B?ODF5OUsrTUJ2SlExSllDWDZ0S0cwTExNMk9ta09SbUJrYVdkSU5IMEU1S2xa?=
 =?utf-8?B?YUdFOHQ4WHoxU0d2K2VXZmtvZExTdGN1Q3h3NlR4endLNUFNVWRuelZsWENI?=
 =?utf-8?B?bzJ5U3BjU0pYSTNycksza05BWjE3UEg1R0dGRE0yTUtHTXpFaERYczZ2SFJp?=
 =?utf-8?B?NFFuWXdiRHlrM2RPTW1CRzlGaHlrVkJFNVJGSForbnpSNFA5QzNlQUNXMXNs?=
 =?utf-8?B?V0U4bk01Q2YxOGdtaW0vMzBTTXRJYWdKenNRQUEzUHU4cnNmVlAzRnJOd0Vj?=
 =?utf-8?B?OGZoOGkzekJmaWV6d0E3S2w1azBZSUpwR0hxTE9GS0N5cU52ZXVjeSt4MzZj?=
 =?utf-8?B?RHJ4a1RobVZuZ2dlTERERHBreTlzOC9jcVd6T1BlTVVhM2taelVFa0hmL0hv?=
 =?utf-8?B?M05SV0laeHU5R2I5dWZNb2dGaFIrU244bm5sM0JxckNqaFdic3kwUWdtNjhJ?=
 =?utf-8?B?WENBMUEveDRBRytSTWlUWldaM3dEVWRVTlVOYXl3UGcwcXVmOUY1YXova2VM?=
 =?utf-8?B?YVI3ZnVkK3NkR2tqMUdzaVcyclhuNVVNUERrYU1wV0ljRFMrbXpSL3hqd013?=
 =?utf-8?B?cUtTSGRBaHpMRlNyejY3cG9PdGFaTDhtODdBdzBTQjNPNkNhTm9ybHZVWUc5?=
 =?utf-8?B?bTNydCtGWVNLOG5oQjRFUHJMVS9lLys4L0VWaVhObEpHclZVamN0R1hTdE95?=
 =?utf-8?B?MG5wTi9QRXhYS0dWT1pUNUJhNCtXcXEyRDVmSUY3VURyMzVILytxWTZkQjdD?=
 =?utf-8?B?a2wzOWdwSDRxTnVwVWFzTUxRZzhMSlB5R0toMnR1QndVTXNmWkVKYUpNM1dW?=
 =?utf-8?B?TjMrQXpZWjdwMjl1TnBNNzRjY0t3dnhCSEFSVmhoTnViMi96Sjd2QklRZ09p?=
 =?utf-8?B?cFNUdWFQTUFMNUdSUXFOdUd4ZkMvSnBpZVpKb2pWVm83ckFsa1phUXlkc2dv?=
 =?utf-8?B?STVqS1ZGS3laQkpKeDRhcmcxem5kbXJxVitBWUFkT2d0OVhBaGtIeEZMVHZH?=
 =?utf-8?B?TVNtZXpDL25RUjBWV2NrVjVWL2lFeG5YRUJ1Tk9rVWhFMzB4dXdPdXhiZGYw?=
 =?utf-8?B?VnNaUks4QzRKNVNKTk4rdlRBYlNCWE5vRkFtWTZuNmlXbnExbytRWWx1ak1s?=
 =?utf-8?Q?2mi10j?=
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)(7416014)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jun 2025 23:50:49.4922
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ff942b29-2088-4568-71af-08dda3c2a22d
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:
	SJ5PEPF000001D0.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR12MB6576

From: Nicola Vetrini 

The marked functions never return to their caller, but
lack the `noreturn' attribute, therefore causing a violation
of MISRA C Rule 2.1: "A project shall not contain unreachable code".

No functional change.

Signed-off-by: Nicola Vetrini 
Signed-off-by: Victor Lira 
---
Cc: Andrew Cooper 
Cc: Anthony PERARD 
Cc: Michal Orzel 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Roger Pau Monné 
Cc: Stefano Stabellini 
Cc: Nicola Vetrini 
Cc: Federico Serafini 
Cc: Bertrand Marquis 
---

 xen/arch/arm/efi/efi-boot.h            | 2 +-
 xen/arch/arm/include/asm/arm64/traps.h | 2 +-
 xen/arch/arm/include/asm/processor.h   | 2 +-
 xen/arch/arm/setup.c                   | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
index d2a09ad3a1..ee80560e13 100644
--- a/xen/arch/arm/efi/efi-boot.h
+++ b/xen/arch/arm/efi/efi-boot.h
@@ -934,7 +934,7 @@ static void __init efi_arch_blexit(void)
         efi_bs->FreePool(memmap);
 }

-static void __init efi_arch_halt(void)
+static void noreturn __init efi_arch_halt(void)
 {
     stop_cpu();
 }
diff --git a/xen/arch/arm/include/asm/arm64/traps.h b/xen/arch/arm/include/asm/arm64/traps.h
index 3be2fa69ee..b7435c6e73 100644
--- a/xen/arch/arm/include/asm/arm64/traps.h
+++ b/xen/arch/arm/include/asm/arm64/traps.h
@@ -6,7 +6,7 @@ void inject_undef64_exception(struct cpu_user_regs *regs);
 void do_sysreg(struct cpu_user_regs *regs,
                const union hsr hsr);

-void do_bad_mode(struct cpu_user_regs *regs, int reason);
+void noreturn do_bad_mode(struct cpu_user_regs *regs, int reason);

 #endif /* __ASM_ARM64_TRAPS__ */
 /*
diff --git a/xen/arch/arm/include/asm/processor.h b/xen/arch/arm/include/asm/processor.h
index 9cbc4f9110..92c8bc1a31 100644
--- a/xen/arch/arm/include/asm/processor.h
+++ b/xen/arch/arm/include/asm/processor.h
@@ -571,7 +571,7 @@ extern register_t __cpu_logical_map[];
 #endif

 #ifndef __ASSEMBLY__
-void panic_PAR(uint64_t par);
+void noreturn panic_PAR(uint64_t par);

 /* Debugging functions are declared with external linkage to aid development. */
 void show_registers(const struct cpu_user_regs *regs);
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 734e23da44..ed72317af3 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -63,7 +63,7 @@ bool __read_mostly acpi_disabled;

 domid_t __read_mostly max_init_domid;

-static __used void init_done(void)
+static __used void noreturn init_done(void)
 {
     int rc;

--
2.25.1


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 23:51:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 23:51:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006051.1385327 (Exim 4.92)
	(envelope-from )
	id 1uMxsr-0004Ka-Ll; Wed, 04 Jun 2025 23:51:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006051.1385327; Wed, 04 Jun 2025 23: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 1uMxsr-0004KT-Ic; Wed, 04 Jun 2025 23:51:01 +0000
Received: by outflank-mailman (input) for mailman id 1006051;
 Wed, 04 Jun 2025 23:51:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uMxsq-0003tB-Gi
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 23:51:00 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on2062b.outbound.protection.outlook.com
 [2a01:111:f403:2009::62b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c17ac33b-419e-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 01:50:55 +0200 (CEST)
Received: from BN9PR03CA0945.namprd03.prod.outlook.com (2603:10b6:408:108::20)
 by PH7PR12MB9104.namprd12.prod.outlook.com (2603:10b6:510:2f3::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Wed, 4 Jun
 2025 23:50:50 +0000
Received: from BN1PEPF00005FFF.namprd05.prod.outlook.com
 (2603:10b6:408:108:cafe::98) by BN9PR03CA0945.outlook.office365.com
 (2603:10b6:408:108::20) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Wed,
 4 Jun 2025 23:50:50 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN1PEPF00005FFF.mail.protection.outlook.com (10.167.243.231) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Wed, 4 Jun 2025 23:50:49 +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 Jun
 2025 18:50:49 -0500
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 Jun
 2025 18:50:49 -0500
Received: from xsjvictlira50.xilinx.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 via Frontend
 Transport; Wed, 4 Jun 2025 18:50:48 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c17ac33b-419e-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=P9cS8h8KjuGtpmkFqoLkJUTCZR6LKXO8MASbiiXVvPZfzlEnn1zEYjXOQoJsVegDj8kZbmL7/RsmM88nt/7LiPfTnCx++sjGH8mn3WWPCFqpEmIvt/AHszGPSOR/DFoC1+ihLPcVeTcFSXa6Vz3uojuoGl4SXnSnWl83OCrqUDaKPyOQSpjFku1KKEo5rVU6mfkYLKQc8f8icYfOcsvOEXwy+PPfijXNr7SZSiCHR47Zf3Ah8uf0bezfDaAYd5TNaXpxw1fzDVQjjl+TnLYJRA+GJR+glH0coFWpBA6Fyeu7hlk/9VtNBvIl9tItd9ytH/NVsgZy3S6txWb/SVMqgQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=WsU8ZFwE0tMqVtPeYMWkPu3IcPpAH6M2QRMph/pkbco=;
 b=yA+W5N0qEi3HBq0LBcZVh3iz7ITdKuqwx1bHKgHyDgsLEtAvF+k3NHz93leSBKQU/DcGK76aG9LDWsquRs5AW5j8egvKprlwJqgS89Wma52XkXkaBke5QK5P50mhh8XPKZwqamGutx3m6X1p29enLxJQYbxS66lu9PDLpE9Tar2ZUP7t/apzwRXj7vvC1l74bbCOeWXt5coMO6A7n0RNxgBO01qfG9l3aHOnJNAytKF043l0zwv2NtINrCtWscjhN/fv6kPAN44gmP1SYZQ1hDFHMQxEg1dh7lLlv3HXQUF8ph52ZWlosd6J/kOg0RvC16T+U1T2NNKzAe4nMOkTrQ==
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=WsU8ZFwE0tMqVtPeYMWkPu3IcPpAH6M2QRMph/pkbco=;
 b=Rolboj8QEeqrHR2qsJlX/PHPtBzNP/X+i+Q9jXNACAGetOdG8xhyKGlo4zyNFnQ+jK3q4mXhQkImduDZn30ZCLUXe3xe1/8b76j/daBWhmlZDJvKg2WmsJ+p5konOyWX4XBojIXisaSRx4ix0mG3cJK8BZz8zKn1/Syo+P1xJzw=
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: 
To: 
CC: Nicola Vetrini , Victor Lira
	, Andrew Cooper , "Anthony
 PERARD" , Michal Orzel , Jan
 Beulich , Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=83=C2=A9?= , "Stefano
 Stabellini" , Federico Serafini
	, Bertrand Marquis 
Subject: [PATCH 3/3] xen/x86: add missing noreturn attributes
Date: Wed, 4 Jun 2025 16:49:57 -0700
Message-ID: <20250604235034.1595881-3-victorm.lira@amd.com>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250604235034.1595881-2-victorm.lira@amd.com>
References: <20250604235034.1595881-1-victorm.lira@amd.com>
 <20250604235034.1595881-2-victorm.lira@amd.com>
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: BN1PEPF00005FFF:EE_|PH7PR12MB9104:EE_
X-MS-Office365-Filtering-Correlation-Id: dcca156b-42a0-4a37-e362-08dda3c2a252
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|82310400026|1800799024|376014|7416014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?K2piM2VpaHpTZG11d3M0MmJka3lqbmdVOWllZkd0T1oremJaaEo3YmErN3RN?=
 =?utf-8?B?dEFIWXhDZjJnQjA0cENKd3hYWXFFNHYzdzFnYnZGTlZzRzk4dHlzNGdGMzdC?=
 =?utf-8?B?RDROMk4rZFFnODFzaThERWkrdHRpZ2I1NmVjRnhJRnZjTU9wUGp3aDNLODlq?=
 =?utf-8?B?cEo5UVdzbnJHVFd3SllDQUlyQkZRYXJ5NlUyK21HYS8rTHhDeTFHdEViSm5E?=
 =?utf-8?B?aXZJbmk5cEh0cno5ZzdQeFgvenVyN0ZOZW55eUt2bDZVTnVUdldhWXFMdTRt?=
 =?utf-8?B?am9tSVdHeEFrNWNrbmpZQzdpakFOVTFkTmEwZ0pEcWsvcitOOFE2cC82MnZR?=
 =?utf-8?B?T29kcm5Vci9xalhjVlhMVTdCZnpVZDY1cFhQTTRSNjVnTGFlS3NRQzEyQmEz?=
 =?utf-8?B?ajlQOXhobGllNEI2ZzVLZ3FPTDR2bG9lWGROamRLWldweUg2VmRyMzMyMlow?=
 =?utf-8?B?bzg5SFFDS2lhcGdHNWhpL1M2ZVZJb0xJZVhnUlNLZTc2dGdyQ0w1V29iTWU2?=
 =?utf-8?B?UHlTQm50ZkRRV05rV2Z3a0JDK1RTdlgydWt3UlhQTExyZmRIMnhUZGRrdk1l?=
 =?utf-8?B?NUNMVENLSzcrclpIV2NIK2wrVzVWRExRM2t3QjBUTzRJa0VIYUNESW1xTjF1?=
 =?utf-8?B?Q2ZKelJ6UnFaOFRIYk5QU0Q1RFZqR2p1QlRLTVVPdXhMclpGNlk1MUQ4NXd4?=
 =?utf-8?B?QWtzYlpxZDVmUWNOQmpsOGFpOSsrV0ZjYWZVb2Q3SjJPdzJYOWloc3VKN25z?=
 =?utf-8?B?L3k2NGYvcFU3TkhWSTlheDMvMkN0MDVCNi9VT2tGaHFOYXRUcU0wL0p6S1JX?=
 =?utf-8?B?d3ppdVpQV2MyakdmaVJQdEExVjFPOXMyRGV2Q1BkTDhEeVBObjljN0hleDYz?=
 =?utf-8?B?YkFjWlBsdUZkTTR3T1Q4bHR0UjJRWlRYL09WTlBQcDljWFRWdXowbkZ4YzlO?=
 =?utf-8?B?RDFFbGlQMHZmRmpxcW1DdGNka292c0o0S2pqVEUybU5pUGZabjNiZmN4YnRo?=
 =?utf-8?B?TDdsWnBKN1dlY2llMFpiRG96YVl6Zk5mRXlKN2tGK0pWbDQ4ajI0THpYZVBh?=
 =?utf-8?B?VlR5bHhxVEtKSWZleEF6ZEFkak9INUZsNXdndCsyY1hCemZoemVOK1NJYlRJ?=
 =?utf-8?B?djJMOUE0SGdGaTNGVW95TThYU0FoQmNsMFFpcHNSTkEzcGg0QUNLVU4yN21u?=
 =?utf-8?B?NXlRSFpXTXFRTFFKdjVJc2M1Wmk4Uzh4QmZrUkF5bXgzbHBaVTc1NUVIMExO?=
 =?utf-8?B?QjZHTzl6bTFWeHc0KzNzT3lVbVRPWVZFYjRUMGZqVjU0a3dmaXJ2dGIzaFhE?=
 =?utf-8?B?NzVxdWpLZ1VYZ3loajNwRGUxNWZjdk5QZUd0MStDVEJTSWpRamduWnNmNzIz?=
 =?utf-8?B?MW9ZZ3czajMyM3gyS01Td2w2a1FMVjkyaXpNQTRkTmFHN1FCelppVjdOY28x?=
 =?utf-8?B?Y0grSGY2UTRVY3BEY2JBM1BwQndOR1RXVXdKaEErd1huUi9KVkpEOUxMMExH?=
 =?utf-8?B?eWNXdzJPaklRSFFjdEl6MDl4cXVpb3laVENvYTJHMkF2bHJIY1VBQ2trSWNH?=
 =?utf-8?B?cURTVklxcWpiT0YvaWh0M2k5dFJ3YXBWR3VRUlJ5QTVuN3MzdTA5TklpekdZ?=
 =?utf-8?B?c21hSEZ6QjgyWDBGMkdDOXRLeTJtQXBiSG4zVWxLK1hyVjAvcmgzdDNlMm41?=
 =?utf-8?B?L0pBVlBicjR0VTJ0aW9GWDIyNXhzRnhsZ2xaSjl6bWNnUDc0ZzdwR0pINTlY?=
 =?utf-8?B?eXpaU2Q1NnBBZ1IreGlsMVRySzgvcGVPOGhacUtZWFV0T1Yrd0hpNjBud0Vl?=
 =?utf-8?B?aFNvR3RQeXZmc3crR0tQdUhwYTdnUU9PdmozUkhVSGxBelhtdUxZb2lhMzVw?=
 =?utf-8?B?Mmpoeldsb093a3FDU3JPNkxlZUxnSlFJQURaNVJiWHVhOXVaT0RvYndzbEcr?=
 =?utf-8?B?YWdSb2F1YjRyVDY4K0lKQm5LZElycHplZmFIZFNtVUNCS1BQd1k5M3RUVXpU?=
 =?utf-8?B?ZUlFWEJZWmZNY1BSbVM3b1Y3MVUrTUhTaE9CVWIvTS8rMmd6RnExN2lXSmhU?=
 =?utf-8?Q?FbqREU?=
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)(7416014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jun 2025 23:50:49.8377
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: dcca156b-42a0-4a37-e362-08dda3c2a252
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:
	BN1PEPF00005FFF.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB9104

From: Nicola Vetrini 

The marked functions never return to their caller, but
lack the `noreturn' attribute, therefore causing a violation
of MISRA C Rule 2.1: "A project shall not contain unreachable code".

No functional change.

Signed-off-by: Nicola Vetrini 
Signed-off-by: Victor Lira 
---
Cc: Andrew Cooper 
Cc: Anthony PERARD 
Cc: Michal Orzel 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Roger Pau Monné 
Cc: Stefano Stabellini 
Cc: Nicola Vetrini 
Cc: Federico Serafini 
Cc: Bertrand Marquis 
---

 xen/arch/x86/cpu/mcheck/mce.c | 3 ++-
 xen/arch/x86/efi/efi-boot.h   | 2 +-
 xen/arch/x86/smp.c            | 2 +-
 xen/arch/x86/traps.c          | 2 +-
 xen/arch/x86/x86_64/traps.c   | 2 +-
 5 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 1c348e557d..79214ce56b 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -79,7 +79,8 @@ static int __init cf_check mce_set_verbosity(const char *str)
 custom_param("mce_verbosity", mce_set_verbosity);

 /* Handle unconfigured int18 (should never happen) */
-static void cf_check unexpected_machine_check(const struct cpu_user_regs *regs)
+static void noreturn cf_check
+unexpected_machine_check(const struct cpu_user_regs *regs)
 {
     console_force_unlock();
     printk("Unexpected Machine Check Exception\n");
diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
index 0ecf4ca53f..0194720003 100644
--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -769,7 +769,7 @@ static void __init efi_arch_blexit(void)
         efi_bs->FreePages(ucode.addr, PFN_UP(ucode.size));
 }

-static void __init efi_arch_halt(void)
+static void noreturn __init efi_arch_halt(void)
 {
     local_irq_disable();
     for ( ; ; )
diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c
index 516dab5528..7936294f5f 100644
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -343,7 +343,7 @@ void __stop_this_cpu(void)
     cpumask_clear_cpu(smp_processor_id(), &cpu_online_map);
 }

-static void cf_check stop_this_cpu(void *dummy)
+static void noreturn cf_check stop_this_cpu(void *dummy)
 {
     const bool *stop_aps = dummy;

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 092c7e4197..34dc077cad 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -805,7 +805,7 @@ void fatal_trap(const struct cpu_user_regs *regs, bool show_remote)
           (regs->eflags & X86_EFLAGS_IF) ? "" : " IN INTERRUPT CONTEXT");
 }

-void asmlinkage do_unhandled_trap(struct cpu_user_regs *regs)
+void asmlinkage noreturn do_unhandled_trap(struct cpu_user_regs *regs)
 {
     fatal_trap(regs, false);
 }
diff --git a/xen/arch/x86/x86_64/traps.c b/xen/arch/x86/x86_64/traps.c
index c77f304bb0..8460a4a1ae 100644
--- a/xen/arch/x86/x86_64/traps.c
+++ b/xen/arch/x86/x86_64/traps.c
@@ -293,7 +293,7 @@ void show_page_walk(unsigned long addr)
            l1_table_offset(addr), l1e_get_intpte(l1e), pfn);
 }

-void asmlinkage do_double_fault(struct cpu_user_regs *regs)
+void asmlinkage noreturn do_double_fault(struct cpu_user_regs *regs)
 {
     unsigned int cpu;
     struct extra_state state;
--
2.25.1


From xen-devel-bounces@lists.xenproject.org Wed Jun 04 23:51:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jun 2025 23:51:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006049.1385306 (Exim 4.92)
	(envelope-from )
	id 1uMxsq-0003tT-7P; Wed, 04 Jun 2025 23:51:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006049.1385306; Wed, 04 Jun 2025 23:51:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMxsq-0003tM-4g; Wed, 04 Jun 2025 23:51:00 +0000
Received: by outflank-mailman (input) for mailman id 1006049;
 Wed, 04 Jun 2025 23:50: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 1uMxso-0003tB-SM
 for xen-devel@lists.xenproject.org; Wed, 04 Jun 2025 23:50:58 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on2062c.outbound.protection.outlook.com
 [2a01:111:f403:2418::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c045309f-419e-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 01:50:53 +0200 (CEST)
Received: from MW4PR03CA0247.namprd03.prod.outlook.com (2603:10b6:303:b4::12)
 by SJ2PR12MB9087.namprd12.prod.outlook.com (2603:10b6:a03:562::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.32; Wed, 4 Jun
 2025 23:50:48 +0000
Received: from SJ5PEPF000001D0.namprd05.prod.outlook.com
 (2603:10b6:303:b4:cafe::2d) by MW4PR03CA0247.outlook.office365.com
 (2603:10b6:303:b4::12) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.34 via Frontend Transport; Wed,
 4 Jun 2025 23:50:48 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SJ5PEPF000001D0.mail.protection.outlook.com (10.167.242.52) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Wed, 4 Jun 2025 23:50: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; Wed, 4 Jun
 2025 18:50:46 -0500
Received: from xsjvictlira50.xilinx.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 via Frontend
 Transport; Wed, 4 Jun 2025 18:50:46 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c045309f-419e-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=y+Z56QVzWzuyWC2fIa3gYpM6veo0IEYsHLqTvrkhHP5VIjNLyL/SV7ycBzEPseHdX5iRHJm44bD+V7hx+Ko7uuwEfm2AttpE11JM+F9IkgbJ57nc/42po95UzKfpkGJ3bKxRUaYxmKl+dn1MmD6G/v3spjBsqd/zctB5ZR6kDi9xlZgiBocPuQ+tThQRhsKnny3eXpTQHTvVj4AmLwz/N7oMYbFlf2JCGVJuRUpKHwn9shpNY3a2pN+ycgQhOULvLIl5stYlz5j8eEZb6Hh2K63xgBbuz7g40PB0IEUhAL8Yep0+UF2E2b9eAfM7CnvckDVRvILxu8E0GX+cP2QJeA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=48VLOy0/b6rx5ed5zZ7/OJCVbc1U+JkkkK8ji4aPVCA=;
 b=ZSK8gWcZXdPFSeXSIwo+jN87bOaYygS80xw2Hnqi6k+JE7pz9VMH+ABUrkhWAOdik8zf/pUebVdjRk0p+OxYLnmi6cp1AkTBnYlY1PzC+BGpXZ5EUp6IDMDOIjlrZihL3/LVWA4MaasYX+HFrcDnbT3oWpQAPOAizt61+ewxEC0mMrS2oDDZjwxFoSqi3ASTyw/7hCx2lten4MnT/hmBPoUh1Dhpt5Xboo+mWGinn4+lP6dg85aDe+lSnvFtHILPXxM2UZ2UvwbbyvkVZxG+8IL9wu8G5FLXYvYHB2Q+EUSOAOXuZaLS+gjiIvelDNr6hXURuHD9Zz9mjIzPhXLWvQ==
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=48VLOy0/b6rx5ed5zZ7/OJCVbc1U+JkkkK8ji4aPVCA=;
 b=3O9SkpQ58QtYP44+uVcbDXhFDMC0Pt9d13km+yZb24DGlsqVwFNW3HKojNJJm2qP7EdTX/sQJL40f3mQx6CJvUzLCVTkQpIKgN7CH5/xJV12CwYg9QZuDA0/fxrStLp6lBWoWjSR5bo9lwQq29HxYy+rEPCknVcV8VkfQ4aQiB8=
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: 
To: 
CC: Nicola Vetrini , Victor Lira
	, Andrew Cooper , "Anthony
 PERARD" , Michal Orzel ,
	"Jan Beulich" , Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=83=C2=A9?= , "Stefano
 Stabellini" , Federico Serafini
	, Bertrand Marquis 
Subject: [PATCH 1/3] xen/keyhandler: add missing noreturn attribute
Date: Wed, 4 Jun 2025 16:49:55 -0700
Message-ID: <20250604235034.1595881-1-victorm.lira@amd.com>
X-Mailer: git-send-email 2.47.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB03.amd.com: victorm.lira@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001D0:EE_|SJ2PR12MB9087:EE_
X-MS-Office365-Filtering-Correlation-Id: 357c3a48-1fca-4808-0e06-08dda3c2a125
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|82310400026|1800799024|36860700013|7416014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?MkdrcSt6OUtQRCtBVzNWenRzQ2V6Vy9jQjlJZmUyb1VTTmtYcE5FYjlUVzNS?=
 =?utf-8?B?NDlmOFR4RmNNRGI3M0tjaVhvRDJ1eW9MVTd5YXR1S0FzNXlXWTl3NWRRczUx?=
 =?utf-8?B?T0pXRnBIbkVoK1QvTjg5c0NIWkpvZFhVL09PaDVpbmJiRVV1cG51L0UxOHJM?=
 =?utf-8?B?ZjJrOE9oZjNPTlBWSXdxUjlsL2VXbmszZE8wRlZJZ2YwOWlyYmYzTXlmQmUr?=
 =?utf-8?B?QW9zd1NZRUZhZDUzTlRvQTd1ZE4zUUdPV25zMG1tMWg4dU5uWjdlSllEaWp5?=
 =?utf-8?B?eFJFVHYvaFA0NVlEL1F6NVZud1RRUHlEMkRJSXRxRk5rZXhrdy9HOEJDMGxh?=
 =?utf-8?B?bTViVW1iNmRIYW43eVBFek5aYUhKRFJEejJBUExQZ1ZRbTYrQkxVZWc3Wmw4?=
 =?utf-8?B?bW5aV09JdkVhb2J5d0dEUVd5eWgzVUJoQkNqZ3h2VmhHR3hQSGdnT1doTkpT?=
 =?utf-8?B?NzI0blduUzh5ZVl0SVFvd0liSTZiOEpBMzRHOU9BaEN3RDVuUWVHbG1sNWlL?=
 =?utf-8?B?UG1UTSt3bXl5NVhKYmdmRnZ3Sk1FMFBiRW55ZWZIRGdmVHJuOTY0TWhzeUhn?=
 =?utf-8?B?YktGSzBWdWxnSS9SOUtEU3M5aTFFdlhsMUxqdlBSRWRPT1QvOHFFTGtvaEE2?=
 =?utf-8?B?WnlscjI0S3VxWU1vNTVqUjEwL2FZa2YrTDhXdVk3OGlveUdGUE1UemFEcHVy?=
 =?utf-8?B?ZndiSDEvWjYzVHE0T1N4KzYyaVlGRVdwRHZCb1o2dDZMZ3djTk1CZ0R2MzZl?=
 =?utf-8?B?TEFXT3N1SG9mUERTOEpkRE90UERkOFB6bVllSVNLREtrVGN6aU4zcnM1YjJw?=
 =?utf-8?B?cHptNlJQR2R3OVNUMjBVRXMvNHV4UzhhN2tBcXV0S2toR1NEL1YrbXpPSnFy?=
 =?utf-8?B?NTkvSFdUendoOHExQVRFMlJIUE1IRkxUVUU1SmFVRlM2VjFMZGRIOW81ZENK?=
 =?utf-8?B?Q1lQKzlpSk5EZGVYK2FmalB0NGdNU3R2UTRhUGx0NHlURlgwNFRKcytST2VU?=
 =?utf-8?B?SVB2UklkTDQxRjBwZmIwOFpNdDg3NWlpRW9kVFhOSmFOTmdRWXdZa05NZThq?=
 =?utf-8?B?OS9XM09lY09oU3krU1FKZy9NSVdhN3p0OERpcUcwMzU0RWJuOXZqMWNqdXFp?=
 =?utf-8?B?MmF0NVJIcHEyQ2EvMGd0Y2Z3NXA0aHpIMWQwbGpsa1VidjJ0VXkya1BZT1JE?=
 =?utf-8?B?S3M4YmIrT1R5WlJoS1BuT0xZZXk3NUJQTEl1QlJLelVxUDJjL1daRGd1ajA5?=
 =?utf-8?B?bGc2M215V21La2FpaDljMnVKTEZrOW1DVzFrcFBFRmFaY1JGL1lsU0wyQ0xa?=
 =?utf-8?B?MnI1c1lSUWFpaDdQVTk5MVFyeTlJZVdScVUzZU5SNUlUMFlVUXk3WExueTBJ?=
 =?utf-8?B?MG90aHdXcXc2ZGVlVjNobGNPSERYMER4WkhqVVVPUGJSSVo4dEVnM3VqNmxo?=
 =?utf-8?B?cW9nS0U3TG5Pa3hGckZVNms3ZDR6TWtTVkEzcHpEUk81T1NnaGIzUXpOZjRG?=
 =?utf-8?B?dnBmV0k1dWpFT2dUNUR4TCtaVFdOZTVub0dDSFNIcFRqUnkrV2xJUkdHRnMr?=
 =?utf-8?B?UUFOWHVpdVdLVGIyTHRWd0t3TmJkaVRtQUNHN3VhTXcxTzBrVnFPcmQvcWQ5?=
 =?utf-8?B?bkUzQnlpZXJQd1MyWisycytkend2QmIva245VkptWUhDUGdLZUd3UGxPMitR?=
 =?utf-8?B?V2lacWJsOXpPbHRNcTYwOGNmZDBMTHFYNzF1UkROSFFjemsweU9iVzV2U2Jr?=
 =?utf-8?B?KzRic3N3Q0FRUFdodVZWWVBvejFYS2RDOFpxRHdtaXBMUisySVEreDF5VDRx?=
 =?utf-8?B?UmREUWNyTExjazBQcVdCd1MyRWxPMlQzVk03UnVYbjUrdExwM1lSRHNBdFVB?=
 =?utf-8?B?YVFUS2dzUTZIYVJCTENVa2dCaHNYdkRBOHN4OVplbkIyVnNuUEwrd1h6UUFa?=
 =?utf-8?B?N3pCOEp0M0ZrL25BM29jUC9jV0RTUDRaR253QjdpNEFnVE9pcFBmSEl6ZGxV?=
 =?utf-8?B?bGkyMUhCaW43bmVhZjZMOVFiUWxlOG5GNWREaGRvMEVjZUNPNE1YbDQ1ZTRq?=
 =?utf-8?Q?ZLBlE4?=
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)(7416014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jun 2025 23:50:47.7589
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 357c3a48-1fca-4808-0e06-08dda3c2a125
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:
	SJ5PEPF000001D0.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB9087

From: Nicola Vetrini 

Function `reboot_machine' does not return, but lacks the `noreturn' attribute,
therefore causing a violation of MISRA C Rule 2.1: "A project shall not contain
unreachable code".

No functional change.

Signed-off-by: Nicola Vetrini 
Signed-off-by: Victor Lira 
---
Cc: Andrew Cooper 
Cc: Anthony PERARD 
Cc: Michal Orzel 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Roger Pau Monné 
Cc: Stefano Stabellini 
Cc: Nicola Vetrini 
Cc: Federico Serafini 
Cc: Bertrand Marquis 
---

 xen/common/keyhandler.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index 0bb842ec00..b0a2051408 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -251,7 +251,7 @@ static void cf_check dump_hwdom_registers(unsigned char key)
     }
 }

-static void cf_check reboot_machine(unsigned char key, bool unused)
+static void noreturn cf_check reboot_machine(unsigned char key, bool unused)
 {
     printk("'%c' pressed -> rebooting machine\n", key);
     machine_restart(0);
--
2.25.1


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 00:46:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 00:46:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006090.1385356 (Exim 4.92)
	(envelope-from )
	id 1uMykb-0003xh-1y; Thu, 05 Jun 2025 00:46:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006090.1385356; Thu, 05 Jun 2025 00:46: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 1uMyka-0003xa-Uv; Thu, 05 Jun 2025 00:46:32 +0000
Received: by outflank-mailman (input) for mailman id 1006090;
 Thu, 05 Jun 2025 00:46: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 1uMykZ-0003dI-Ox
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 00:46:31 +0000
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 85806f2c-41a6-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 02:46:31 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 85806f2c-41a6-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1749084390; x=1749343590;
	bh=9smI6UqtAGVdne0R3e2rtMBynR9rK4/XlXYqfjo4GgM=;
	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=EOHAc1s/hRHY6RAFcNVziAL7IfSuCMtYXXQmUVtwAsFXeG6D7Wl2oyvTzUbP9UZWr
	 pdyRYReQGJ4cSLyW7r7flv7CVLqKomL24gfj13n5vM6YtuqPmCgz2fMcXkZrZQgy0z
	 50cafQQGoQVOuelkAEZl8wSdzRQTuJ6/vN4d5SAAqF0BIeDFvxsqhJPkZU/ucbuGlw
	 grp7QP2Ues7r7ZLAh157S3jl1OMzUyMmRWw0od/mWp1z4yiPKZNeKJIPJfKAHhETwn
	 jV4YZjnYEK+WDj+ao6ZPK/NG5UgFrKGfChipWsPlQGzafelKMPmP8Hoebx5BDD2aQA
	 VcUoZw9hHBuyA==
Date: Thu, 05 Jun 2025 00:46:25 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v2 2/2] xen/console: unify printout behavior for UART emulators
Message-ID: <20250605004601.1142090-3-dmukhin@ford.com>
In-Reply-To: <20250605004601.1142090-1-dmukhin@ford.com>
References: <20250605004601.1142090-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 0def410e3d0ccdb8d9d0833aa67447765c7cbd6a
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

If virtual UART from domain X prints on the physical console, the behavior =
is
updated to (see [1]):
- console focus in domain X: do not prefix messages;
- no console focus in domain X: prefix all messages with "(dX)".

Use guest_printk() without rate-limiting in all current in-hypervisor UART
emulators. That aligns the behavior with debug I/O port 0xe9 handler on x86=
 and
slightly improves the logging since guest_printk() already prints the domai=
n
ID. guest_printk() was modified to account for console focus ownership.

Modify guest_console_write() for hardware domain case by adding domain ID t=
o
the message when hwdom does not have console focus.

[1] https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2412121655360.463=
523@ubuntu-linux-20-04-desktop/
Signed-off-by: Denis Mukhin 
---
Changes since v1:
- dropped change for debug port and for HYPERVISOR_console_io hypercall
---
 xen/arch/arm/vpl011.c      |  6 +++---
 xen/arch/arm/vuart.c       |  2 +-
 xen/drivers/char/console.c | 23 +++++++++++++++++++++--
 3 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 480fc664fc..2b6f2a09bc 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -87,7 +87,7 @@ static void vpl011_write_data_xen(struct domain *d, uint8=
_t data)
     {
         if ( intf->out_prod =3D=3D 1 )
         {
-            printk("%c", data);
+            guest_printk(d, "%c", data);
             intf->out_prod =3D 0;
         }
         else
@@ -95,7 +95,7 @@ static void vpl011_write_data_xen(struct domain *d, uint8=
_t data)
             if ( data !=3D '\n' )
                 intf->out[intf->out_prod++] =3D '\n';
             intf->out[intf->out_prod++] =3D '\0';
-            printk("%s", intf->out);
+            guest_printk(d, "%s", intf->out);
             intf->out_prod =3D 0;
         }
     }
@@ -107,7 +107,7 @@ static void vpl011_write_data_xen(struct domain *d, uin=
t8_t data)
             if ( data !=3D '\n' )
                 intf->out[intf->out_prod++] =3D '\n';
             intf->out[intf->out_prod++] =3D '\0';
-            printk("DOM%u: %s", d->domain_id, intf->out);
+            guest_printk(d, "%s", intf->out);
             intf->out_prod =3D 0;
         }
     }
diff --git a/xen/arch/arm/vuart.c b/xen/arch/arm/vuart.c
index bd2f425214..8c9f9e2182 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 !=3D '\n' )
             uart->buf[uart->idx++] =3D '\n';
         uart->buf[uart->idx] =3D '\0';
-        printk(XENLOG_G_DEBUG "DOM%u: %s", d->domain_id, uart->buf);
+        guest_printk(d, "%s", uart->buf);
         uart->idx =3D 0;
     }
     spin_unlock(&uart->lock);
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index a8cb6363ea..616f4968b0 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -740,7 +740,17 @@ 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 */
+            char prefix[16] =3D "";
+            struct domain *consd;
+
+            consd =3D console_get_domain();
+            if ( consd !=3D cd )
+                snprintf(prefix, sizeof(prefix), "(d%d) ", cd->domain_id);
+            console_put_domain(consd);
+
             nrspin_lock_irq(&console_lock);
+            if ( prefix[0] !=3D '\0' )
+                console_send(prefix, strlen(prefix), flags);
             console_send(kbuf, kcount, flags);
             nrspin_unlock_irq(&console_lock);
         }
@@ -1029,12 +1039,21 @@ void printk(const char *fmt, ...)
     va_end(args);
 }
=20
+/*
+ * Print message from the guest on the diagnostic console.
+ * Prefixes all messages w/ "(dX)" if domain X does not own physical conso=
le
+ * focus.
+ */
 void guest_printk(const struct domain *d, const char *fmt, ...)
 {
     va_list args;
-    char prefix[16];
+    char prefix[16] =3D "";
+    struct domain *consd;
=20
-    snprintf(prefix, sizeof(prefix), "(d%d) ", d->domain_id);
+    consd =3D console_get_domain();
+    if ( consd !=3D d )
+        snprintf(prefix, sizeof(prefix), "(d%d) ", d->domain_id);
+    console_put_domain(consd);
=20
     va_start(args, fmt);
     vprintk_common(fmt, args, prefix);
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Thu Jun 05 00:46:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 00:46:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006089.1385347 (Exim 4.92)
	(envelope-from )
	id 1uMykW-0003ic-R8; Thu, 05 Jun 2025 00:46:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006089.1385347; Thu, 05 Jun 2025 00:46: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 1uMykW-0003iT-Oa; Thu, 05 Jun 2025 00:46:28 +0000
Received: by outflank-mailman (input) for mailman id 1006089;
 Thu, 05 Jun 2025 00:46: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 1uMykV-0003dI-U2
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 00:46:27 +0000
Received: from mail-10628.protonmail.ch (mail-10628.protonmail.ch
 [79.135.106.28]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8219daa8-41a6-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 02:46:25 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8219daa8-41a6-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1749084383; x=1749343583;
	bh=ytJlHdADwkkLmr+mgrJUrJhb0F+8LfeAiZe0wZX+P8A=;
	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=EP6C7l8fDk2SwJtGOgSdTXBfj0wrG/AVrppMfyQE44MTZmrM3JLHDgfhQPk8HnxUq
	 scVEGoWLjHzM4dAbro+EvoEj6hfF2EpwiESi/o7htny+2KBdoIGgY8VqsDbgLJHRLf
	 QfQL36Yc38v+1a+9/qeNS6hqWpT+uAwiVlbqRoezFQX5NYPXbct1mcNuLaJ2zDO5s5
	 QQ0gF8BMgiKrYO8yn1rc4PyP43mQY71Fv4+Egumd3mGw8QiEgAYW5XELmxNihQWKjl
	 Qi+PwUqZOCw1KwpyOkDxDhgzJTSpGfaXMKZQCHRjU0LdNKkA5R5yvCvjz3bCK7QCk1
	 aU64wecrYevPg==
Date: Thu, 05 Jun 2025 00:46:17 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v2 1/2] xen/console: introduce CONSOLE_PREFIX
Message-ID: <20250605004601.1142090-2-dmukhin@ford.com>
In-Reply-To: <20250605004601.1142090-1-dmukhin@ford.com>
References: <20250605004601.1142090-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: fe120c6f48d95d38ba42437ca80885342328b0b0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Add CONSOLE_PREFIX symbol to keep the prefix of the hypervisor's diagnostic
messages.

No functional change.

Signed-off-by: Denis Mukhin 
---
Changes since v1:
- n/a
---
 xen/drivers/char/console.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 9a9836ba91..a8cb6363ea 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -61,6 +61,9 @@ enum {
     CONSOLE_ALL             =3D CONSOLE_DEFAULT | CONSOLE_RING,
 };
=20
+/* Prefix for hypervisor's diagnostic console messages. */
+#define CONSOLE_PREFIX      "(XEN) "
+
 static void console_send(const char *str, size_t len, unsigned int flags);
=20
 /* console: comma-separated list of console outputs. */
@@ -1014,7 +1017,7 @@ static void vprintk_common(const char *fmt, va_list a=
rgs, const char *prefix)
=20
 void vprintk(const char *fmt, va_list args)
 {
-    vprintk_common(fmt, args, "(XEN) ");
+    vprintk_common(fmt, args, CONSOLE_PREFIX);
 }
=20
 void printk(const char *fmt, ...)
@@ -1285,7 +1288,7 @@ int __printk_ratelimit(int ratelimit_ms, int ratelimi=
t_burst)
             snprintf(lost_str, sizeof(lost_str), "%d", lost);
             /* console_lock may already be acquired by printk(). */
             rspin_lock(&console_lock);
-            printk_start_of_line("(XEN) ");
+            printk_start_of_line(CONSOLE_PREFIX);
             __putstr("printk: ");
             __putstr(lost_str);
             __putstr(" messages suppressed.\n");
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Thu Jun 05 00:46:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 00:46:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006088.1385337 (Exim 4.92)
	(envelope-from )
	id 1uMykU-0003Ut-Kx; Thu, 05 Jun 2025 00:46:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006088.1385337; Thu, 05 Jun 2025 00: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 1uMykU-0003Um-Hp; Thu, 05 Jun 2025 00:46:26 +0000
Received: by outflank-mailman (input) for mailman id 1006088;
 Thu, 05 Jun 2025 00: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 1uMykR-0003Uc-BS
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 00:46:24 +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 7db9419a-41a6-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 02:46:18 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7db9419a-41a6-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1749084377; x=1749343577;
	bh=yrHPGYbphu2Gt/MWqUwv4rxzUWxk5rYWOxUjjk+StiI=;
	h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
	 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector:
	 List-Unsubscribe:List-Unsubscribe-Post;
	b=XOnSHChjc3rjbnxCyzFn5uiyVWRhKK9nRR0LiFO9H4ixSDkynmzakXCi+Q3fPskrB
	 KOXkHZJnyb2hiH7Q8gEyBitWvCgO4VsLsNx7M/MSPyh//n92HdJLMlYu6laDFvMy3c
	 2XTri4Ovw64lLw6Iac9bcEmYEQ2sU/ZZ5B9V0J6mG4uotrwYjdBYAR0/l+0sT5IVft
	 Eq8gk4j9nt3SeX3kPYoz/atqakXMtC5f+MosR5WYgGqBJkGOeIVtUhw4JFAcv4JWMP
	 d/Us3Y03IlxQuteOfA/E1ZipaJnHEkOSYJVGqcaHThfTDoFIkuomRd0d97YDrH3YzM
	 SxsnZIt8VGSKg==
Date: Thu, 05 Jun 2025 00:46:08 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v2 0/2] xen/console: updates to diagnostic messages prefixes
Message-ID: <20250605004601.1142090-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: a2a99761fe885937cf59d8c8f5e33a91c8916145
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Patch 1 is purely cosmetic change, adds a symbol for hypervisor's messages.

Patch 2 updates the logic how the domain prefix is formed for guest message=
s
sent over emulated UART.

[1] Link to v1: https://lore.kernel.org/xen-devel/20250531000417.81750-1-dm=
ukhin@ford.com/
[2] Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelin=
es/1854205416

Denis Mukhin (2):
  xen/console: introduce CONSOLE_PREFIX
  xen/console: unify printout behavior for UART emulators

 xen/arch/arm/vpl011.c      |  6 +++---
 xen/arch/arm/vuart.c       |  2 +-
 xen/drivers/char/console.c | 30 ++++++++++++++++++++++++++----
 3 files changed, 30 insertions(+), 8 deletions(-)

--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Thu Jun 05 00:57:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 00:57:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006112.1385366 (Exim 4.92)
	(envelope-from )
	id 1uMyvK-0006Dj-03; Thu, 05 Jun 2025 00:57:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006112.1385366; Thu, 05 Jun 2025 00:57: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 1uMyvJ-0006Dc-Tn; Thu, 05 Jun 2025 00:57:37 +0000
Received: by outflank-mailman (input) for mailman id 1006112;
 Thu, 05 Jun 2025 00:57:36 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uMyvI-0006DW-Jx
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 00:57:36 +0000
Received: from mail-24417.protonmail.ch (mail-24417.protonmail.ch
 [109.224.244.17]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 102d6672-41a8-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 02:57:33 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 102d6672-41a8-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1749085052; x=1749344252;
	bh=awmIl9NoMME1vVxstyWfTyCNGNxKPbkGb9bMS0sKVPI=;
	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=VMYq233qiBuLWLJ//yhRonJn/FRiysDOqu4OwGznTX0K5mWR7ynMr5/dkpeS+qU88
	 PxbpOqDCdiJT6o56XQprKFJaJxcaZZvULcUJT7PDzaUssYiBDUxs8bJZuwg4aWQEhq
	 f7nUcSIx0N+9NJFlrPH634IiNOxUkjfXepDG4CXXkBYp5x1z2ROuRORqwmK5rtXbZK
	 I7QrMyK6DHaGC7/Z/LmlNDOrUVsvDxHldTzs1o+L2SYKcqpKI810Dcg3VejA10VCSD
	 V0KNIdnJaI7Cd2aeF88HWhl3eA75ul2c7UIjBr0rXFd22qO/DhvFkBM9wCsRQFty0I
	 XOozwTkg64rvw==
Date: Thu, 05 Jun 2025 00:57:26 +0000
To: Jan Beulich 
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v1 2/2] xen/console: unify printout behavior for UART emulators
Message-ID: 
In-Reply-To: <71318dd2-0724-4c2a-9786-40b676411e56@suse.com>
References: <20250531000417.81750-1-dmukhin@ford.com> <20250531000417.81750-3-dmukhin@ford.com> <71318dd2-0724-4c2a-9786-40b676411e56@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: cc8100ddd9f7c3cf39d7caf070ecff2f87063e48
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 04, 2025 at 12:48:05PM +0200, Jan Beulich wrote:
> On 31.05.2025 02:04, dmkhn@proton.me wrote:
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -577,7 +577,7 @@ static int cf_check hvm_print_line(
> >      if ( (cd->pbuf_idx =3D=3D (DOMAIN_PBUF_SIZE - 1)) || (c =3D=3D '\n=
') )
> >      {
> >          cd->pbuf[cd->pbuf_idx] =3D '\0';
> > -        guest_printk(cd, XENLOG_G_DEBUG "%s\n", cd->pbuf);
> > +        guest_printk(cd, "%s\n", cd->pbuf);
> >          cd->pbuf_idx =3D 0;
> >      }
>=20
> Why this and ...
>=20
> > @@ -755,7 +765,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PA=
RAM(char) buffer,
> >              else
> >              {
> >                  cd->pbuf[cd->pbuf_idx] =3D '\0';
> > -                guest_printk(cd, XENLOG_G_DEBUG "%s%s\n", cd->pbuf, kb=
uf);
> > +                guest_printk(cd, "%s%s\n", cd->pbuf, kbuf);
> >                  cd->pbuf_idx =3D 0;
> >              }
>=20
> ... this change? There's no compensation for it ...
>=20
> > @@ -1013,12 +1023,21 @@ void printk(const char *fmt, ...)
> >      va_end(args);
> >  }
> >
> > +/*
> > + * Print message from the guest on the diagnostic console.
> > + * Prefixes all messages w/ "(dX)" if domain X does not own physical c=
onsole
> > + * focus.
> > + */
> >  void guest_printk(const struct domain *d, const char *fmt, ...)
> >  {
> >      va_list args;
> > -    char prefix[16];
> > +    char prefix[16] =3D "";
> > +    struct domain *consd;
> >
> > -    snprintf(prefix, sizeof(prefix), "(d%d) ", d->domain_id);
> > +    consd =3D console_get_domain();
> > +    if ( consd !=3D d )
> > +        snprintf(prefix, sizeof(prefix), "(d%d) ", d->domain_id);
> > +    console_put_domain(consd);
> >
> >      va_start(args, fmt);
> >      vprintk_common(fmt, args, prefix);
>=20
> ... here afaics, so it looks like you're undermining rate-limiting of
> those messages.

I droppped behavior change for I/O debug port on x86 and HYPERVISOR_console=
_io
hypercall.

But my understanding is that all guest debugging facilities, if enabled, sh=
ould
not be rate-limited.

>=20
> Jan



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 01:17:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 01:17:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006129.1385377 (Exim 4.92)
	(envelope-from )
	id 1uMzEv-0008HI-JL; Thu, 05 Jun 2025 01:17:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006129.1385377; Thu, 05 Jun 2025 01:17:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uMzEv-0008HB-Fz; Thu, 05 Jun 2025 01:17:53 +0000
Received: by outflank-mailman (input) for mailman id 1006129;
 Thu, 05 Jun 2025 01:17: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 1uMzEt-0008H4-JJ
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 01:17:52 +0000
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e553ee60-41aa-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 03:17:49 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e553ee60-41aa-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1749086268; x=1749345468;
	bh=ZYlzHNGcktA7wOygRVP7CHnmUsOYcMDd1aY869XyxRA=;
	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=OhgRVC18gxnpGXhvNVj016Cbsv5VFhc4U7/pW//qg3+MAXMAou2zmC1N3oeAvgsi2
	 I9InYjTYolTAAr2UsLgF4k8skyuIgR6sWa5l9AMwTxBkssHernwcCXxOTlHCmKADP/
	 Zm+37zkBj1tp7nrWaSiANN8VttScZ/wBkgN0TwZLpILUMX4W3zAwNhvL0h5CRXNU2X
	 ZuKy5izx5ppVtchKISrGL0wqsXFz05tDq3iuZrZPeUm49uFMw0N4XgK4SDTJR0GTxf
	 c0gPJVlERmvzbxKI/ObciheMxNlKY2+ZfvQTjADynisaNySQs1mhf73I5IQ7O2quuM
	 NWvEd8aAlsuEQ==
Date: Thu, 05 Jun 2025 01:17:43 +0000
To: Jan Beulich 
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v5 1/2] xen/domain: introduce common hardware emulation flags
Message-ID: 
In-Reply-To: <093dc85d-ebf3-4982-8888-db4e7cfd0e45@suse.com>
References: <20250602191717.148361-1-dmukhin@ford.com> <20250602191717.148361-2-dmukhin@ford.com> <093dc85d-ebf3-4982-8888-db4e7cfd0e45@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 5062ddf93c492581c5ee289e0055ecfb1c123e7b
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 04, 2025 at 12:36:17PM +0200, Jan Beulich wrote:
> On 02.06.2025 21:17, dmkhn@proton.me wrote:
> > From: Denis Mukhin 
> >
> > Add common emulation_flags for configuring domain emulation features.
> >
> > Print d->emulation_flags from 'q' keyhandler for better traceability wh=
ile
> > debugging.
> >
> > Signed-off-by: Denis Mukhin 
> > Reviewed-by: Stefano Stabellini 
>=20
> It's not becoming clear why this would want doing, nor in how far some of
> the bits there may gain "common" meaning, too. Imo this kind of change is
> meaningful only in a series where later the common-ness is also used.

I have a set of upcoming changes here:
  https://gitlab.com/xen-project/people/dmukhin/xen/-/tree/vuart-framework?=
ref_type=3Dheads

Specifically,
 https://gitlab.com/xen-project/people/dmukhin/xen/-/commit/17f44d23c190437=
4963c4ec839bc8219041b5d26

enables the use of emulation_flags on Arm.

I can move this patch to the upcoming series, if needed, but looks like it =
is
OK to have it for Arm even now.

>=20
> Jan



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 02:01:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 02:01:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006139.1385386 (Exim 4.92)
	(envelope-from )
	id 1uMzuX-0007Dn-Jv; Thu, 05 Jun 2025 02:00:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006139.1385386; Thu, 05 Jun 2025 02: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 1uMzuX-0007Dg-H9; Thu, 05 Jun 2025 02:00:53 +0000
Received: by outflank-mailman (input) for mailman id 1006139;
 Thu, 05 Jun 2025 02:00: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 1uMzuV-0007DV-Dp
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 02:00:52 +0000
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e7108670-41b0-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 04:00:49 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e7108670-41b0-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1749088846; x=1749348046;
	bh=faC1QDkVXavzq1jMkkEEKtrZ8+5HWOz5ffowOpSVkWE=;
	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=KeaMpnvzntYbZa4wT/x7Nz1X4X+VfgIx9FhNCg5d9KKMkliT9kQ1wedNgVIS1Ia93
	 AAkAMQsZV9aHjka6acotAaDuiXOoD/sU5ipgecRsye4SHicj3QfoJtDUSf7AQ0qaUM
	 V6iieT6tmfCsGrH8dWM8+NwnyBF62l8PHcxjufP5cl1e/qLne35oGap2m01RQgr9Jo
	 9lepPu9O8a+5IYy5Xl7Lp641Ajhwhg5RmFZvY1Z5i99TJNOsZgtQtc9mrB4l9K0qkE
	 k78ftDMW3+KApCnQHvCV++D41F5SNl7Z17DRwNYsaPRv3oBkNjp74OLKU+TpTdKAfe
	 hiTd+tZBypubg==
Date: Thu, 05 Jun 2025 02:00:41 +0000
To: Jan Beulich 
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v5 2/2] xen/domain: rewrite emulation_flags_ok()
Message-ID: 
In-Reply-To: 
References: <20250602191717.148361-1-dmukhin@ford.com> <20250602191717.148361-3-dmukhin@ford.com> 
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 11b5ddd624975d30e4186a776adfb07b6bbd7971
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 04, 2025 at 12:43:22PM +0200, Jan Beulich wrote:
> On 02.06.2025 21:17, dmkhn@proton.me wrote:
> > From: Denis Mukhin 
> >
> > Rewrite emulation_flags_ok() to simplify future modifications.
> >
> > No functional change intended.
> >
> > Signed-off-by: Denis Mukhin 
> > Reviewed-by: Stefano Stabellini 
> > Reviewed-by: Teddy Astie 
> > ---
> > Changes since v4:
> > - updated commentaries
> > - added Teddy's R-b, kept Stefano's R-b
> > ---
> >  xen/arch/x86/domain.c | 91 ++++++++++++++++++++++++++++++++++---------
> >  1 file changed, 73 insertions(+), 18 deletions(-)
>=20
> Given this diffstat, I wonder what the other x86 maintainers think about
> this.
>=20
> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -743,32 +743,87 @@ int arch_sanitise_domain_config(struct xen_domctl=
_createdomain *config)
> >      return 0;
> >  }
> >
> > +/*
> > + * Verify that the domain's emulation flags resolve to a supported con=
figuration.
> > + *
> > + * This ensures we only allow a known, safe subset of emulation combin=
ations
> > + * (for both functionality and security). Arbitrary mixes are likely t=
o cause
> > + * errors (e.g., null pointer dereferences).
> > + *
> > + * NB: use the internal X86_EMU_XXX symbols, not the public XEN_X86_EM=
U_XXX
> > + * symbols.
> > + */
> >  static bool emulation_flags_ok(const struct domain *d, uint32_t emflag=
s)
> >  {
> > +    enum {
> > +        CAP_PV          =3D BIT(0, U),
> > +        CAP_HVM         =3D BIT(1, U),
> > +        CAP_HWDOM       =3D BIT(2, U),
> > +        CAP_DOMU        =3D BIT(3, U),
> > +    };
> > +    static const struct {
> > +        unsigned int caps;
> > +        uint32_t min;
> > +        uint32_t opt;
> > +    } configs[] =3D {
> > +#ifdef CONFIG_PV
> > +        /* PV */
> > +        {
> > +            .caps   =3D CAP_PV | CAP_DOMU,
> > +            .min    =3D 0,
> > +            .opt    =3D 0,
>=20
> Why the latter two initializers? Imo adding ones which say nothing else t=
han
> what's the default is only enlarging code without much real benefit.

Sure, no problem, I can address that.
Thanks!

>=20
> > +        },
> > +
> > +        /* PV dom0 */
> > +        {
> > +            .caps   =3D CAP_PV | CAP_HWDOM,
> > +            .min    =3D X86_EMU_PIT,
> > +            .opt    =3D 0,
> > +        },
> > +#endif /* #ifdef CONFIG_PV */
> > +
> > +#ifdef CONFIG_HVM
> > +        /* PVH dom0 */
> > +        {
> > +            .caps   =3D CAP_HVM | CAP_HWDOM,
> > +            .min    =3D X86_EMU_LAPIC | X86_EMU_IOAPIC | X86_EMU_VPCI,
> > +            .opt    =3D 0,
> > +        },
> > +
> > +        /* HVM domU */
> > +        {
> > +            .caps   =3D CAP_HVM | CAP_DOMU,
> > +            .min    =3D X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIR=
Q),
> > +            /* HVM PIRQ feature is user-selectable. */
> > +            .opt    =3D X86_EMU_USE_PIRQ,
> > +        },
> > +
> > +        /* PVH domU */
> > +        {
> > +            .caps   =3D CAP_HVM | CAP_DOMU,
> > +            .min    =3D X86_EMU_LAPIC,
> > +            .opt    =3D 0,
> > +        },
> > +#endif /* #ifdef CONFIG_HVM */
> > +    };
> > +    unsigned int i, caps =3D is_hardware_domain(d) ? CAP_HWDOM : CAP_D=
OMU;
> > +
> > +    if ( is_pv_domain(d) )
> > +        caps |=3D CAP_PV;
> > +    else if ( is_hvm_domain(d) )
> > +        caps |=3D CAP_HVM;
>=20
> There's no 3rd case, so this could be expressed with plain "else", and he=
nce
> also with a conditional operator, and hence could also be right in the
> initializer. How far to go with those transformations I'm not sure; perso=
nally
> I'd go all the way, but I'd be okay-ish with just the first of the steps.

Ack.

>=20
> Jan



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 05:26:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 05:26:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006207.1385396 (Exim 4.92)
	(envelope-from )
	id 1uN37G-0006BJ-Kn; Thu, 05 Jun 2025 05:26:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006207.1385396; Thu, 05 Jun 2025 05:26: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 1uN37G-0006BC-He; Thu, 05 Jun 2025 05:26:14 +0000
Received: by outflank-mailman (input) for mailman id 1006207;
 Thu, 05 Jun 2025 05:26: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 1uN37F-0006B6-MH
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 05:26:13 +0000
Received: from mail-il1-x131.google.com (mail-il1-x131.google.com
 [2607:f8b0:4864:20::131])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 97dc7793-41cd-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 07:26:12 +0200 (CEST)
Received: by mail-il1-x131.google.com with SMTP id
 e9e14a558f8ab-3ddc3c70e20so386465ab.2
 for ; Wed, 04 Jun 2025 22:26:12 -0700 (PDT)
Received: from kf-m2g5 ([2607:fb91:729:c9c7:c3e2:180e:e54f:7b49])
 by smtp.gmail.com with ESMTPSA id
 8926c6da1cb9f-4ff1e5aee18sm2684590173.101.2025.06.04.22.26.10
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 04 Jun 2025 22:26:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 97dc7793-41cd-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749101171; x=1749705971; darn=lists.xenproject.org;
        h=mime-version:message-id:subject:cc:to:from:date:from:to:cc:subject
         :date:message-id:reply-to;
        bh=T53+ijlXu/Jb/YRepw4rfUkWAWCFRGwzmhGhfqmrkf0=;
        b=np8bzwblFQovFxUw6WhqD82dMPJFKaNnYBz+3nCViyD1+2USIZnbkhPerV3bUzqocW
         mAKgpUW9Gk069+s4TJQsJw2rmHxg3o4IBWGYPgxRnjBEyA8/3OxLq37f4wII17qLzyne
         loZLNz1psQgHlqJxRuSI61xVL15spVE2FcoEQqOVuJCgZ1iGwPzUJSSauJLp1MVz797w
         xZ0wrySSp9v95dND/9hkCSYoL4d4V6giEr2lu0Qzw8LBMVMG8Ve3eswB0SVHb5y9tU/G
         KMxM0oOLqXg9b84qeKDpx3c/xjxvbgCPojBb6FUPm707gKSd0u+/fPE6DkY34mFm0cxI
         o/uw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749101171; x=1749705971;
        h=mime-version:message-id:subject:cc:to:from:date:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=T53+ijlXu/Jb/YRepw4rfUkWAWCFRGwzmhGhfqmrkf0=;
        b=ejxbKC/Su0i/6AvTGSBZ0RxABNeAlwJtV1X3gq15Qw/2hrzZ4EtW935vhZMrOEy3EU
         d3SKTiARSHQoK9mGzQFVzseDu5j+rbe0ceZKxzioC/N18H237d9VE1zb+dTGXpNa2MRj
         vPsXzhfZBFxeH+bYWCiX97xSAH+v5JIdH3SRv2AQ8wxoQrAVB8/abv2IpcuotW0kcgYr
         JLNUs8hgpUgooefQ349Qa9ptT5TXwOREZX2wbIu3aFvCm60pK4Y1Dw2gU2NP8CgCeNNn
         LtG0GEMpU7OMQixjmH0Qq6nYoaaV5BW5jVG68Go3cVdTeciEbPWkKsZN3rqOT0jUht8G
         FAfg==
X-Gm-Message-State: AOJu0YwNN0vKDC2NGrUefe7I+mRJecum12lByrbjx5n7VHhzHIcaLKZK
	SBdmVHt82YmY1+7SUzEEyP0WdYgJbiMRxknP0tSIawrRjTlQ70jQmJBl
X-Gm-Gg: ASbGncvMI2/BZV4Kvr8JWqM+8WtdcdeCCCkgETzwoR5/2OctM/0dApdrhgZkLkCy/pr
	h9IJLZXNFdYaNlnLHWk0w+gDwPLoL4YG65PifiKo50NJySbPf2fOR3lJyn+RsCTL+npe2y4fxXK
	z0Oo9GVneiCeknKCi2Ru6K3MNsQfu4OMR8t6XC/KckozycxvNUs9HK/UczKOm02wWj6bIbP5seu
	FP7KxRar9A0Ykw/3OWb4pHZLNeKKQZl2gwNrp/AEux0R/BOnx9ff0FmqNMsC2Tn6EDbOoFSonoW
	7SqyUukwgrVMV6C6YRdf2KDM7XrPZtn0ySfpL0hqlvt43Pm1YBcGwpRRyhA=
X-Google-Smtp-Source: AGHT+IEIEssQyYpJAI3uaYnFE/r+RIy7mtvyJO2hCXZ7dYai+czsg/AJDEmrM6oh2w1ZHJoQU/jxZQ==
X-Received: by 2002:a05:6e02:12cc:b0:3dd:b7da:5254 with SMTP id e9e14a558f8ab-3ddbedae965mr16824255ab.7.1749101171227;
        Wed, 04 Jun 2025 22:26:11 -0700 (PDT)
Date: Thu, 5 Jun 2025 00:26:01 -0500
From: Aaron Rainbolt 
To: grub-devel@gnu.org
Cc: xen-devel@lists.xenproject.org, daniel.kiper@oracle.com,
 phcoder@gmail.com, marmarek@invisiblethingslab.com
Subject: [PATCH v3 0/1] kern/xen: Add Xen command line parsing
Message-ID: <20250605002601.73a34f9b@kf-m2g5>
X-Mailer: Claws Mail 4.3.1 (GTK 3.24.41; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="Sig_/ZF=r=FsOwGehNJsxTrAMV2o";
 protocol="application/pgp-signature"; micalg=pgp-sha512

--Sig_/ZF=r=FsOwGehNJsxTrAMV2o
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

The purpose of this patch is to allow the Xen hypervisor to pass extra
data to GRUB in the form of a kernel command line, allowing the host to
customize the boot process of the guest. The command line from Xen is
parsed, and any variables within that start with the string
`xen_grub_env_` are exposed as environment variables. The grub.cfg
script can then use those environment variables as it sees fit.

The main reason for doing this is to allow implementing boot modes in
Qubes OS while also using in-VM kernels. For more context on Qubes boot
modes, see [1]. In order for this to work with in-VM kernels, it is
necessary for dom0 to pass kernel parameters to the guest without
modifying the guest's grub.cfg manually. This patch allows this to be
done, by allowing dom0 to pass kernel parameters to GRUB, which then
provides them to grub.cfg as an environment variable. The grub.cfg
script within the VM can then append those variables to the kernel
command line.

The patch has been tested with both PV and PVH virtual machines, using
an otherwise unpatched GRUB source tree, building the patch on top of
the tip of git master at the time of this writing (commit 438f055). My
testing environment is a fully updated Arch Linux system with Xen built
from the stable-4.20 branch.

Changes from the previous version of the patch:

* Implemented changes suggested by Marek from Invisible Things Lab, who
  reviewed an earlier version of the patch. Specifically:
  * Added minor optimizations (avoided needlessly calling grub_strlen
    in a loop, got rid of an unneeded variable, removed a redundant
    string length check)
  * Made a couple of bit setting and unsetting operations in the parser
    more readable
  * Removed a superfluous extra NUL terminator from a string literal

The patch has been thoroughly tested by booting a patched GRUB with
various different parameters passed to it via the Xen-provided kernel
command line. The effects of these parameters on the bootloader's
environment were then tested, and then an Arch Linux image was booted
to ensure that boot still worked. The full list of test cases and their
results can be seen at [2] (pastebinned so as to not overload people's
email clients with 185-character-long lines). This is the same test
suite used for version 2 of the patch.

[1] https://github.com/QubesOS/qubes-linux-pvgrub2/pull/16
[2] https://bpa.st/5C7A

Aaron Rainbolt (1):
  kern/xen: Add Xen command line parsing

 docs/grub.texi                |  50 +++++
 grub-core/Makefile.core.def   |   2 +
 grub-core/kern/i386/xen/pvh.c |  14 ++
 grub-core/kern/main.c         |  12 ++
 grub-core/kern/xen/cmdline.c  | 343 ++++++++++++++++++++++++++++++++++
 include/grub/xen.h            |   2 +
 6 files changed, 423 insertions(+)
 create mode 100644 grub-core/kern/xen/cmdline.c

--=20
2.49.0


--Sig_/ZF=r=FsOwGehNJsxTrAMV2o
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

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

iQIzBAEBCgAdFiEEudh48PFXwyPDa0wGpwkWDXPHkQkFAmhBKmkACgkQpwkWDXPH
kQnGvQ//SdvF1dnEEjK7Y9/lSyC91a1q7JWPyHSodauHeEmHBz8X5JcvAhJB3eRz
7QVGnAa4cLeXAZtumPcxlFbHyBFVgRvSdoOMYNu02GB7kTWg/71tHVGZKgDDgjSi
t7CNevsaKDy6BymJlMq8bLjbodxgE5qZ14kQ3SwPdQcSVRIpzSggTOOe1sIvYoWr
B0/8mc67e3Lk4U7MtvcuG0PeBVRR64hxzjY/rxvqfyUUs9sYIVVNHiab2FWmvsmP
sF3uTyYW4kuQjK3rpgmuQf2n8jGB8rD4TMoa6TkW5j+zw6a87ZeoeoxNcKW1HYzY
QNEuQglgIK2lVX0ozWEqpUKK4EliSP1sylZFxfZETvvZZf3FkRddgpQ+O07l9V/j
piMH5qjIslEK99uOQ3ZrqFfqhG7zLPekO1H8B5YhOcyjIw2p50HNMzaP5UkUyQJ1
Fx1p1n3JxRP/000gUfizisWZSxLNlYYuKok/dLgpWqudp3BqLjkixhFpDioADVgR
KAqzo9Iync/AzIgP/A+Wy8Y+3vx2mDEMGgvTJsS8Q1+XP6FMQVACuF8lx/8TBBAb
QyIep0+a3YkNbhfTMsKvnNY9gHFh+JOuMO+88z1VRlUkZAA9sSsj+qq60Eno6Zlo
t5LVgs06I7VHhTdmhXdz1mhBgaOSSEt4QT3+VAuCVSecBhB3q0g=
=lgoW
-----END PGP SIGNATURE-----

--Sig_/ZF=r=FsOwGehNJsxTrAMV2o--


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 05:28:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 05:28:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006218.1385407 (Exim 4.92)
	(envelope-from )
	id 1uN39N-0006kt-3W; Thu, 05 Jun 2025 05:28:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006218.1385407; Thu, 05 Jun 2025 05:28: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 1uN39N-0006km-0H; Thu, 05 Jun 2025 05:28:25 +0000
Received: by outflank-mailman (input) for mailman id 1006218;
 Thu, 05 Jun 2025 05:28: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 1uN39L-0006ke-6e
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 05:28:23 +0000
Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com
 [2607:f8b0:4864:20::d2e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e20dfee3-41cd-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 07:28:18 +0200 (CEST)
Received: by mail-io1-xd2e.google.com with SMTP id
 ca18e2360f4ac-864a29cf2daso1731739f.1
 for ; Wed, 04 Jun 2025 22:28:17 -0700 (PDT)
Received: from kf-m2g5 ([2607:fb91:729:c9c7:c3e2:180e:e54f:7b49])
 by smtp.gmail.com with ESMTPSA id
 8926c6da1cb9f-4fdd7ed81b1sm3137778173.86.2025.06.04.22.28.14
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 04 Jun 2025 22:28:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e20dfee3-41cd-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749101296; x=1749706096; darn=lists.xenproject.org;
        h=mime-version:references:in-reply-to:message-id:subject:cc:to:from
         :date:from:to:cc:subject:date:message-id:reply-to;
        bh=WwCurTopJGv31bpHBjbnnne+gMhFb6BxAc9wg8PtYiw=;
        b=jk5CUwra5LbQld0rGbA/56ZhLAkh8aF5arj/i60R5CroI+Pb8dYaeypolbkCwZqV08
         W5Xkhe6KF5atoAqcbs1TkVNSpRFHEyS+a/8XXvFhmj2rpokIbYTAyD9U/kmCj2edlBEw
         LMNte2YOyshYwJHUzLLCmV8FKUDIIFMX2EH0wF1IkedRDRHMCuDticQ9DtpXFEW1SfGX
         U+CXvzVq4iccpRrNAf9uGN2AYPgTI+ppzff2uk+v7ZS3c0cV0v3f8sWjTGt5wDdVLuzS
         yjXXxGbeWoQ6EXgKQPHIbkmVZr3qbyW4ZriFOZ4JDlKuiFtSKJK+3wud4It6QpfCm31D
         S0Bg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749101296; x=1749706096;
        h=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=WwCurTopJGv31bpHBjbnnne+gMhFb6BxAc9wg8PtYiw=;
        b=ms1NWNuys0Zxg8dEctpsTlbg0Vwrss7ivYnAqMstj9DLnr5ORlHSsigPMb3RU4dyrM
         Tr278oGg/WdycsfivQbaKjYWKwlvZx7pVWcsxFg4LHC5ZdWir/fiYjKxDvoaw505vyj0
         8GtRj7y36mbgzl42PZtEPH4rAdjjt7vwe2LVWrCZ5fqwZTeRCwIxZBvLVZumFZ26qbCP
         fe60EQFAqSx9rYY0Gw+nNK9n7Lg68H5hajldcSta4IVlTuWMgH042mlrq1qa1tPH74+M
         WeiyqIipM5fcIBCgDOZjd89NDofEL3MaRbQz24dimewSOM6/weazrnUqh3juh5DTMF7V
         O4oA==
X-Gm-Message-State: AOJu0YwPu8bGSL248FdR2awzYAjMmWlYof8MfZ6/ljcvtwR2USFzwq7k
	bPpkz3x2x2lcylzygKzrWTg59ieoxMXLuSI0mDeCpN/gxhS1mBUrUsp/
X-Gm-Gg: ASbGncu3vOk4UEzQdCDHxLZzWaaeZbQahQe7MCmVYWmrrREj+jq0Cxy5Pw+2G8DqpMA
	x7kCWQ2JnxeUULvPN9wmPA7KUEVOa9T1DDY+ClEAgh4wzfqsK9xcyeNoi761ECQ8+3tfkJOW8yg
	zUfDE+WqA8ibyRsCX78DVIsrR2HfwKvv0mjWbLD7Fok04SAOos5H+swIqCimQOOpXv7pd0WwdCM
	d+g5XCVPHWcLpq/6mVKRdujaOCBKnRPHj+OPk+mnlKfFU/ZaeriwIobIdeMm52cg04VXQ4qkE+P
	e8Y1fz6JU7Te8O7SGJvEeV6X3NJDDz21vHcwqPIB2uXenfwY
X-Google-Smtp-Source: AGHT+IFz5oVr9m8av9462qSk2DpWiOxZTJo++F8KwhpejFtLNXjmbMNdwcfbvP03/XM4OwjUzLJFqw==
X-Received: by 2002:a05:6e02:1526:b0:3d4:6d6f:6e1f with SMTP id e9e14a558f8ab-3ddbedfcfdemr15746365ab.6.1749101295449;
        Wed, 04 Jun 2025 22:28:15 -0700 (PDT)
Date: Thu, 5 Jun 2025 00:28:11 -0500
From: Aaron Rainbolt 
To: grub-devel@gnu.org
Cc: xen-devel@lists.xenproject.org, daniel.kiper@oracle.com,
 phcoder@gmail.com, marmarek@invisiblethingslab.com
Subject: [PATCH v3 1/1] kern/xen: Add Xen command line parsing
Message-ID: <20250605002811.216f2ef9@kf-m2g5>
In-Reply-To: <20250605002601.73a34f9b@kf-m2g5>
References: <20250605002601.73a34f9b@kf-m2g5>
X-Mailer: Claws Mail 4.3.1 (GTK 3.24.41; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="Sig_/CBBYWyRHjyZxGj6=6xzWhkB";
 protocol="application/pgp-signature"; micalg=pgp-sha512

--Sig_/CBBYWyRHjyZxGj6=6xzWhkB
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Xen traditionally allows customizing guest behavior by passing arguments
to the VM kernel via the kernel command line. This is no longer possible
when using GRUB with Xen, as the kernel command line is decided by the
GRUB configuration file within the guest, not data passed to the guest
by Xen.

To work around this limitation, enable GRUB to parse a command line
passed to it by Xen, and expose data from the command line to the GRUB
configuration as environment variables. These variables can be used in
the GRUB configuration for any desired purpose, such as extending the
kernel command line passed to the guest. The command line format is
inspired by the Linux kernel's command line format.

To reduce the risk of misuse, abuse, or accidents in production, the
command line will only be parsed if it consists entirely of 7-bit ASCII
characters, only alphabetical characters and underscores are permitted
in variable names, and all variable names must start with the string
"xen_grub_env_". This also allows room for expanding the command line
arguments accepted by GRUB in the future, should other arguments end up
becoming desirable in the future.

Signed-off-by: Aaron Rainbolt 
---
 docs/grub.texi                |  50 +++++
 grub-core/Makefile.core.def   |   2 +
 grub-core/kern/i386/xen/pvh.c |  14 ++
 grub-core/kern/main.c         |  12 ++
 grub-core/kern/xen/cmdline.c  | 343 ++++++++++++++++++++++++++++++++++
 include/grub/xen.h            |   2 +
 6 files changed, 423 insertions(+)
 create mode 100644 grub-core/kern/xen/cmdline.c

diff --git a/docs/grub.texi b/docs/grub.texi
index 34b3484..ce82483 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -3271,6 +3271,7 @@ GRUB.  Others may be used freely in GRUB configuratio=
n files.
 @menu
 * Special environment variables::
 * Environment block::
+* Passing environment variables through Xen::
 @end menu
=20
=20
@@ -3871,6 +3872,55 @@ using BIOS or EFI functions (no ATA, USB or IEEE1275=
).
 @command{grub-mkconfig} uses this facility to implement
 @samp{GRUB_SAVEDEFAULT} (@pxref{Simple configuration}).
=20
+@node Passing environment variables through Xen
+@section Passing environment variables through Xen
+
+If you are using a GRUB image as the kernel for a PV or PVH Xen virtual
+machine, you can pass environment variables from Xen's dom0 to the VM thro=
ugh
+the Xen-provided kernel command line. When combined with a properly config=
ured
+guest, this can be used to customize the guest's behavior on bootup via the
+VM's Xen configuration file.
+
+GRUB will parse the kernel command line passed to it by Xen during bootup.
+The command line will be split into space-delimited words. Single and
+double quotes may be used to quote words or portions of words that contain
+spaces. Arbitrary characters may be backslash-escaped to make them a liter=
al
+component of a word rather than being parsed as quotes or word separators.=
 The
+command line must consist entirely of printable 7-bit ASCII characters and
+spaces. If a non-printing ASCII character is found anywhere in the command
+line, the entire command line will be ignored by GRUB.
+
+Each word should be a variable assignment in the format ``variable'' or
+``variable=3Dvalue''. Variable names must contain only the characters A-Z,=
 a-z,
+and underscore (``_''). Variable names must begin with the string
+``xen_grub_env_''. Variable values can contain arbitrary printable 7-bit
+ASCII characters and space. If any variable contains an illegal name, that
+variable will be ignored.
+
+If a variable name and value are both specified, the variable will be set =
to
+the specified value. If only a variable name is specified, the variable's
+value will be set to ``1''.
+
+The following is a simple example of how to use this functionality to appe=
nd
+arbitrary variables to a guest's kernel command line:
+
+@example
+# In the Xen configuration file for the guest
+name =3D "linux_vm"
+type =3D "pvh"
+kernel =3D "/path/to/grub-i386-xen_pvh.bin"
+extra =3D "xen_grub_env_kernelappend=3D'loglevel=3D3'"
+memory =3D 1024
+disk =3D [ "file:/srv/vms/linux_vm.img,sda,w" ]
+
+# In the guest's GRUB configuration file
+menuentry "Linux VM with dom0-specified kernel parameters" @{
+    search --set=3Droot --label linux_vm --hint hd0,msdos1
+    linux /boot/vmlinuz root=3DLABEL=3Dlinux_vm $@{xen_grub_env_kernelappe=
nd@}
+    initrd /boot/initrd.img
+@}
+@end example
+
 @node Modules
 @chapter Modules
=20
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 24e8c84..d2208ea 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -248,6 +248,7 @@ kernel =3D {
   xen =3D term/xen/console.c;
   xen =3D disk/xen/xendisk.c;
   xen =3D commands/boot.c;
+  xen =3D kern/xen/cmdline.c;
=20
   i386_xen_pvh =3D commands/boot.c;
   i386_xen_pvh =3D disk/xen/xendisk.c;
@@ -255,6 +256,7 @@ kernel =3D {
   i386_xen_pvh =3D kern/i386/xen/tsc.c;
   i386_xen_pvh =3D kern/i386/xen/pvh.c;
   i386_xen_pvh =3D kern/xen/init.c;
+  i386_xen_pvh =3D kern/xen/cmdline.c;
   i386_xen_pvh =3D term/xen/console.c;
=20
   ia64_efi =3D kern/ia64/efi/startup.S;
diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
index 91fbca8..12df2d8 100644
--- a/grub-core/kern/i386/xen/pvh.c
+++ b/grub-core/kern/i386/xen/pvh.c
@@ -321,6 +321,8 @@ void
 grub_xen_setup_pvh (void)
 {
   grub_addr_t par;
+  const char *xen_cmdline;
+  int i;
=20
   grub_xen_cpuid_base ();
   grub_xen_setup_hypercall_page ();
@@ -352,6 +354,18 @@ grub_xen_setup_pvh (void)
   grub_xen_mm_init_regions ();
=20
   grub_rsdp_addr =3D pvh_start_info->rsdp_paddr;
+
+  xen_cmdline =3D (const char *) pvh_start_info->cmdline_paddr;
+  for (i =3D 0; i < MAX_GUEST_CMDLINE; i++)
+    {
+      if (xen_cmdline[i] =3D=3D '\0')
+        {
+          grub_strncpy ((char *) grub_xen_start_page_addr->cmd_line,
+			(char *) pvh_start_info->cmdline_paddr,
+			MAX_GUEST_CMDLINE);
+          break;
+        }
+    }
 }
=20
 grub_err_t
diff --git a/grub-core/kern/main.c b/grub-core/kern/main.c
index 143a232..b4377d3 100644
--- a/grub-core/kern/main.c
+++ b/grub-core/kern/main.c
@@ -37,6 +37,10 @@
 #include 
 #endif
=20
+#if defined (GRUB_MACHINE_XEN) || defined (GRUB_MACHINE_XEN_PVH)
+#include 
+#endif
+
 static bool cli_disabled =3D false;
 static bool cli_need_auth =3D false;
=20
@@ -351,6 +355,14 @@ grub_main (void)
   grub_env_export ("root");
   grub_env_export ("prefix");
=20
+  /*
+   * Parse command line parameters from Xen and export them as environment
+   * variables
+   */
+#if defined (GRUB_MACHINE_XEN) || defined (GRUB_MACHINE_XEN_PVH)
+  grub_parse_xen_cmdline ();
+#endif
+
   /* Reclaim space used for modules.  */
   reclaim_module_space ();
=20
diff --git a/grub-core/kern/xen/cmdline.c b/grub-core/kern/xen/cmdline.c
new file mode 100644
index 0000000..03dd88f
--- /dev/null
+++ b/grub-core/kern/xen/cmdline.c
@@ -0,0 +1,343 @@
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2025  Free Software Foundation, Inc.
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or
+ *  (at your option) any later version.
+ *
+ *  GRUB is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with GRUB.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+enum parse_flags
+{
+  PARSER_HIT_BACKSLASH =3D 0x1,
+  PARSER_IN_SINGLE_QUOTES =3D 0x2,
+  PARSER_IN_DOUBLE_QUOTES =3D 0x4,
+};
+
+#define PARSER_BASE_WORD_LEN 16
+
+static grub_size_t word_list_len;
+static char **word_list;
+static grub_size_t current_word_len;
+static grub_size_t current_word_pos;
+static char *current_word;
+static char current_char;
+
+static bool
+append_char_to_word (bool allow_null)
+{
+  /*
+   * Fail if the current char is outside of the range 0x20 to 0x7E. If
+   * allow_null is true, make an exception for 0x00. This is a safeguard
+   * against likely-invalid data.
+   */
+  if ( (!(current_char >=3D 0x20) || !(current_char <=3D 0x7E) )
+      && (current_char !=3D '\0' || allow_null =3D=3D false))
+    return false;
+
+  if (current_word_pos =3D=3D current_word_len)
+    {
+      current_word_len *=3D 2;
+      current_word =3D grub_realloc (current_word, current_word_len);
+      if (current_word =3D=3D NULL)
+        {
+          current_word_len /=3D 2;
+          return false;
+        }
+    }
+
+  current_word[current_word_pos] =3D current_char;
+  current_word_pos++;
+  return true;
+}
+
+static bool
+append_word_to_list (void)
+{
+  /* No-op on empty words. */
+  if (current_word_pos =3D=3D 0)
+    return true;
+
+  current_char =3D '\0';
+  if (append_char_to_word (true) =3D=3D false)
+    {
+      grub_error (GRUB_ERR_BUG,
+		  "couldn't append null terminator to word during Xen cmdline parsing");
+      grub_print_error ();
+      grub_exit ();
+    }
+
+  current_word_len =3D grub_strlen (current_word) + 1;
+  current_word =3D grub_realloc (current_word, current_word_len);
+  if (current_word =3D=3D NULL)
+    return false;
+  word_list_len++;
+  word_list =3D grub_realloc (word_list, word_list_len * sizeof (char *));
+  if (word_list =3D=3D NULL)
+    return false;
+  word_list[word_list_len - 1] =3D current_word;
+
+  current_word_len =3D PARSER_BASE_WORD_LEN;
+  current_word_pos =3D 0;
+  current_word =3D grub_malloc (current_word_len);
+  if (current_word =3D=3D NULL)
+    return false;
+
+  return true;
+}
+
+static bool
+check_key_is_safe (char *key, grub_size_t len)
+{
+  grub_size_t i;
+
+  for (i =3D 0; i < len; i++)
+  {
+    /*
+     * Ensure only a-z, A-Z, and _ are allowed.
+     */
+    if (! ( (key[i] >=3D 'A' && key[i] <=3D 'Z')
+          || (key[i] >=3D 'a' && key[i] <=3D 'z')
+          || (key[i] =3D=3D '_') ) )
+      return false;
+  }
+  return true;
+}
+
+void
+grub_parse_xen_cmdline (void)
+{
+  const char *cmdline =3D (const char *) grub_xen_start_page_addr->cmd_lin=
e;
+  grub_size_t cmdline_len;
+  bool cmdline_valid =3D false;
+  char **param_keys =3D NULL;
+  char **param_vals =3D NULL;
+  grub_size_t param_dict_len =3D 0;
+  grub_size_t param_dict_pos =3D 0;
+  enum parse_flags parse_flags =3D 0;
+  grub_size_t i =3D 0;
+
+  /*
+   * The following algorithm is used to parse the Xen command line:
+   *
+   * - The command line is split into space-separated words.
+   *   - Single and double quotes may be used to suppress the splitting
+   *     behavior of spaces.
+   *   - Double quotes are appended to the current word verbatim if they
+   *     appear within a single-quoted string portion, and vice versa.
+   *   - Backslashes may be used to cause the next character to be
+   *     appended to the current word verbatim. This is only useful when
+   *     used to escape quotes, spaces, and backslashes, but for simplicity
+   *     we allow backslash-escaping anything.
+   * - After splitting the command line into words, each word is checked to
+   *   see if it contains an equals sign.
+   *   - If it does, it is split on the equals sign into a key-value pair.=
 The
+   *     key is then treated as an variable name, and the value is treated=
 as
+   *     the variable's value.
+   *   - If it does not, the entire word is treated as a variable name. The
+   *     variable's value is implicitly considered to be `1`.
+   * - All variables detected on the command line are checked to see if th=
eir
+   *   names begin with the string `xen_grub_env_`. Variables that do not =
pass
+   *   this check are discarded, variables that do pass this check are
+   *   exported so they are available to the GRUB configuration.
+   */
+
+  current_word_len =3D PARSER_BASE_WORD_LEN;
+  current_word =3D grub_malloc (current_word_len);
+  if (current_word =3D=3D NULL)
+    goto cleanup;
+
+  for (i =3D 0; i < MAX_GUEST_CMDLINE; i++)
+    {
+      if (cmdline[i] =3D=3D '\0')
+        {
+          cmdline_valid =3D true;
+          break;
+        }
+    }
+
+  if (cmdline_valid =3D=3D false)
+    {
+      grub_error (GRUB_ERR_BAD_ARGUMENT,
+		  "Command line from Xen is not NUL-terminated");
+      grub_print_error ();
+      goto cleanup;
+    }
+
+  cmdline_len =3D grub_strlen (cmdline);
+  for (i =3D 0; i < cmdline_len; i++)
+    {
+      current_char =3D cmdline[i];
+
+      /*
+       * If the previous character was a backslash, append the current
+       * character to the word verbatim
+       */
+      if (parse_flags & PARSER_HIT_BACKSLASH)
+        {
+          parse_flags &=3D ~PARSER_HIT_BACKSLASH;
+          if (append_char_to_word (false) =3D=3D false)
+            goto cleanup;
+          continue;
+        }
+
+      switch (current_char)
+        {
+        case '\\':
+          /* Backslashes escape arbitrary characters. */
+          parse_flags |=3D PARSER_HIT_BACKSLASH;
+          continue;
+
+        case '\'':
+          /*
+           * Single quotes suppress word splitting and double quoting until
+           * the next single quote is encountered.
+           */
+          if (parse_flags & PARSER_IN_DOUBLE_QUOTES)
+            {
+              if (append_char_to_word (false) =3D=3D false)
+                goto cleanup;
+              continue;
+            }
+
+          parse_flags ^=3D PARSER_IN_SINGLE_QUOTES;
+          continue;
+
+        case '"':
+          /*
+           * Double quotes suppress word splitting and single quoting until
+           * the next double quote is encountered.
+           */
+          if (parse_flags & PARSER_IN_SINGLE_QUOTES)
+            {
+              if (append_char_to_word (false) =3D=3D false)
+                goto cleanup;
+              continue;
+            }
+
+          parse_flags ^=3D PARSER_IN_DOUBLE_QUOTES;
+          continue;
+
+        case ' ':
+          /* Spaces separate words in the command line from each other. */
+          if (parse_flags & PARSER_IN_SINGLE_QUOTES
+              || parse_flags & PARSER_IN_DOUBLE_QUOTES)
+            {
+              if (append_char_to_word (false) =3D=3D false)
+                goto cleanup;
+              continue;
+            }
+
+          if (append_word_to_list () =3D=3D false)
+            goto cleanup;
+          continue;
+        }
+
+      if (append_char_to_word (false) =3D=3D false)
+        goto cleanup;
+    }
+
+  if (append_word_to_list () =3D=3D false)
+    goto cleanup;
+
+  param_keys =3D grub_malloc (word_list_len * sizeof (char *));
+  if (param_keys =3D=3D NULL)
+    goto cleanup;
+  param_vals =3D grub_malloc (word_list_len * sizeof (char *));
+  if (param_vals =3D=3D NULL)
+    goto cleanup;
+
+  for (i =3D 0; i < word_list_len; i++)
+    {
+      char *current_word_eq_ptr;
+
+      current_word =3D word_list[i];
+      current_word_len =3D grub_strlen (current_word) + 1;
+      current_word_eq_ptr =3D grub_strchr (current_word, '=3D');
+
+      if (current_word_eq_ptr)
+        {
+          grub_size_t eq_idx =3D (grub_size_t)(current_word_eq_ptr - curre=
nt_word);
+          grub_size_t post_eq_len =3D current_word_len - (eq_idx);
+
+          if (check_key_is_safe (current_word, eq_idx))
+            {
+              param_dict_pos =3D param_dict_len;
+              param_dict_len++;
+              param_keys[param_dict_pos] =3D grub_malloc (eq_idx + 1);
+              if (param_keys =3D=3D NULL)
+                goto cleanup;
+              param_vals[param_dict_pos] =3D grub_malloc (post_eq_len + 1);
+              if (param_vals =3D=3D NULL)
+                goto cleanup;
+
+              grub_strncpy (param_keys[param_dict_pos], current_word,
+			    eq_idx);
+              grub_strncpy (param_vals[param_dict_pos],
+			    current_word + eq_idx + 1, post_eq_len);
+              param_keys[param_dict_pos][eq_idx] =3D '\0';
+              param_vals[param_dict_pos][post_eq_len] =3D '\0';
+            }
+        }
+      else
+        {
+          if (check_key_is_safe (current_word, current_word_len - 1))
+            {
+              param_dict_pos =3D param_dict_len;
+              param_dict_len++;
+              param_keys[param_dict_pos] =3D grub_malloc (current_word_len=
);
+              if (param_keys =3D=3D NULL)
+                goto cleanup;
+              param_vals[param_dict_pos] =3D grub_malloc (2);
+              if (param_vals =3D=3D NULL)
+                goto cleanup;
+
+              grub_strncpy (param_keys[param_dict_pos], current_word,
+			    current_word_len);
+              grub_strcpy (param_vals[param_dict_pos], "1");
+            }
+        }
+    }
+
+  for (i =3D 0; i < param_dict_len; i++)
+    {
+      /*
+       * Find keys that start with "xen_grub_env_" and export them
+       * as environment variables.
+       */
+      if (grub_strncmp (param_keys[i],
+			"xen_grub_env_",
+			sizeof ("xen_grub_env_") - 1) !=3D 0)
+        continue;
+      grub_env_set (param_keys[i], param_vals[i]);
+      grub_env_export (param_keys[i]);
+    }
+
+ cleanup:
+  for (i =3D 0; i < word_list_len; i++)
+    grub_free (word_list[i]);
+
+  for (i =3D 0; i < param_dict_len; i++)
+    {
+      grub_free (param_keys[i]);
+      grub_free (param_vals[i]);
+    }
+
+  grub_free (param_keys);
+  grub_free (param_vals);
+  grub_free (word_list);
+}
diff --git a/include/grub/xen.h b/include/grub/xen.h
index 91cb7cf..7f9efee 100644
--- a/include/grub/xen.h
+++ b/include/grub/xen.h
@@ -89,6 +89,8 @@ void grub_console_init (void);
 void grub_xendisk_fini (void);
 void grub_xendisk_init (void);
=20
+void grub_parse_xen_cmdline (void);
+
 #ifdef __x86_64__
 typedef grub_uint64_t grub_xen_mfn_t;
 #else
--=20
2.49.0


--Sig_/CBBYWyRHjyZxGj6=6xzWhkB
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

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

iQIzBAEBCgAdFiEEudh48PFXwyPDa0wGpwkWDXPHkQkFAmhBKusACgkQpwkWDXPH
kQkREg//RdVFETnbmQLIFMHi63AuLSvq4NDr9Ivc47QpwmDa4poyYEomVtVZ3FtV
AKsKUwXfO5KPMTSouE7u/txnLwOxA0Y1JbfpQ6FJyRjykpUvDcQrMr48ABxpJBqm
pAuVmh+eTdMrBSqzTcCf/J7giPDEYIeArpYgBuSaCVOXk/ZGM8XsUQ09RyUD5Qta
onOJPoollrNg7j2mLb8QrbWx6v7eFdvOOThDZZaajmX32tirXlbih3P0hOCDh21n
UN3sxOqOeQQqojhao80/XHOtOWJ+qB+bI2cUz9+t0nSnS8wkyVlt5zVlly/BPU9e
jgIx+Yf4HFpHyen/GOwGzk0rvO2Jo9U/AmeaZpjzbukm3/bBaILy5c1yBgHbuMgT
/Mguk5Lq6W6FTwnF2ytwyFM7I1GK/VbuwfR4JlqIheMmNTK5dduEHXQRw5Yr9wEU
8cSbXNYVhqDc1yhrNsvHpsPQzbCluHzeW6ffOXoqD1j24VgKvdKnbhBrFsPw13Lj
tyjyvzjA/18tqIlLGSByuO5C9qPXn+YsIXSYA7NyBkw7SoPGOM+AcRHxMXBjVsX+
cE+RLo9yCRUjHJKHcQccjarcLlLeHbbVasGj0C1df/VqeOVmdgeWwawU5rHo4YTi
rj0TM0H/bDg/a4E8fV65HnSy46/uWN8O8RSA0YNfZFIPbSCoTBE=
=n3i2
-----END PGP SIGNATURE-----

--Sig_/CBBYWyRHjyZxGj6=6xzWhkB--


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 05:55:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 05:55:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006231.1385417 (Exim 4.92)
	(envelope-from )
	id 1uN3Za-0002VN-6t; Thu, 05 Jun 2025 05:55:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006231.1385417; Thu, 05 Jun 2025 05:55: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 1uN3Za-0002VG-4C; Thu, 05 Jun 2025 05:55:30 +0000
Received: by outflank-mailman (input) for mailman id 1006231;
 Thu, 05 Jun 2025 05:55: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 1uN3ZY-0002VA-SZ
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 05:55:29 +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 abcbfced-41d1-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 07:55:23 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a366843fa6so292201f8f.1
 for ; Wed, 04 Jun 2025 22:55:23 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-747afe9639csm12504925b3a.17.2025.06.04.22.55.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 04 Jun 2025 22:55:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: abcbfced-41d1-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749102923; x=1749707723; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=4v2PFWgrpkN9/X6bYuWG9tQ8K+a6jECdX4qVTa/Ndjk=;
        b=G8f4QtYZvDZbjkKzF0on4HE77vA5GEAD48+y7ZL7ZeHaN7jLMbzTG7wAtFS4It1XXP
         09sJTnN+wfm1vmeN33WqnzgbBocg8puFdNdgtw3RAQl8I553eb2LC8wyB1oDWxyAuk2h
         icylwT7IFa2TFdCIDg/Cz5Sd1K/Bkq35UPVav1IookuUZ/gRuJ/GqJnZMyl1orUGaLLl
         5rOf89TYd5CLJhULCBsjycNeToCf51ro5d0IgnrcPMwHh6CHwdVwoNragbAVYf/CYuTl
         VwZjyqvcJeVT54vYuADccgJaWOS/xFnyvCaE+IlTmCLVJVyeAwJugByiBHGGlqQQh1hA
         V9hQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749102923; x=1749707723;
        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=4v2PFWgrpkN9/X6bYuWG9tQ8K+a6jECdX4qVTa/Ndjk=;
        b=Zr5pBZiE/PZAm1keE7uZjahBkTFOM8vV+EfTxu/C3Qv08C0pCpbLcXF/Pm/3+nBvyL
         nWl5ZSZbzsIg2TbDFgcOGax6u7lAB9nAmi5YQGuf9tZp/XanBdk9lP6+OSVUks/iNbzQ
         aQ9P/RMf5oJpgudFHK8VASQWmZdcPiftRIReZfAC96bxAYfmXJF/f4rHJ9fMfhRPRxPl
         sV1hatXqgdYdwtLes0D0VdGk++ZBAjOjSwZwW/GhRD/sh8+enFouYEspNSruvPOJX34C
         M4D1JUQttbq9GE0QSqOZq/RcEkXMTFwcyevFhdP+ZmbXKW+Esr1rgkEgbSVXHU3yg8DU
         z2/g==
X-Forwarded-Encrypted: i=1; AJvYcCWkmBXdQuHzH/eEaHi2JGLcH+pN8uALTtLEWNKhqCLAbyt/bdkV5l+wjVQhm/Z2P3tFOOfkgitJWQo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwmmRSYJOzj103adoXAhPz2J68ffsGJLZwGQs+GRDioWIs3iDNm
	4EJUTKNrgnU8efYtMDMq4X8JyGbrLsk0y+Fh/V/crjfcaVn0uim4Q7hJV2D6aAL/KA==
X-Gm-Gg: ASbGncsVii7BC76mAMuJ/CNXceMbeWgCNzu/g+/BQzJJYDZU8/k6YcFplx7gIvjVuOl
	qYHs3KZncezoTBEnhXuPKklXVhcWklQ8fGmDW/kA8m+PmoXmDpPmYk4vj9zpxnDW2tcYUSeEmtN
	sZpagJCLJPONpRz06/1lbKpGOB6bU5QBLhIUyFXDDtTf5dt8Zig18Yrw+xd02sCOJqZuXMK7X9e
	Z51L/myvfbIdG2MddHALCR/5Z2OWSE+HCGk993CRslvbIyUQ6k8D5K0yK9WRzjl15mMQCyR/xeD
	qNN7II8zbk2/AwVzIiazwGa/VikJdpgQmiZC0FeqQoRWpqlw14mj2JMJEhjGEZ1L/KZCJkJVLfN
	unvLt7/9dykWGgpAhso6dpMuPidLw+BHG4lDb
X-Google-Smtp-Source: AGHT+IExBX3PDnWv73qdy8MeSxoX+0zw92+HcCpsQKWY/+MQfdqKpSQ4ejrjy18MeEriilHeO/mtew==
X-Received: by 2002:a05:6000:1a87:b0:3a4:ed2f:e82d with SMTP id ffacd0b85a97d-3a51d9306d8mr3935384f8f.22.1749102922788;
        Wed, 04 Jun 2025 22:55:22 -0700 (PDT)
Message-ID: <8cb2ec09-d806-4ee8-8e49-188f278ff2a4@suse.com>
Date: Thu, 5 Jun 2025 07:55:15 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/hvm: Process pending softirqs while dumping VMC[SB]s
To: Andrew Cooper 
Cc: Aidan Allen ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20250604130253.2805053-1-andrew.cooper3@citrix.com>
 
 <7c3f7bb0-b7b9-4909-8d8b-d412498aea59@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: <7c3f7bb0-b7b9-4909-8d8b-d412498aea59@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 04.06.2025 17:20, Andrew Cooper wrote:
> On 04/06/2025 4:15 pm, Jan Beulich wrote:
>> On 04.06.2025 15:02, Andrew Cooper wrote:
>>> @@ -246,6 +248,8 @@ static void cf_check vmcb_dump(unsigned char ch)
>>>              }
>>>              printk("\tVCPU %d\n", v->vcpu_id);
>>>              svm_vmcb_dump("key_handler", v->arch.hvm.svm.vmcb);
>>> +
>>> +            process_pending_softirqs();
>> It's only an RCU read lock we're holding here, but it still feels somewhat
>> odd to do this with any kind of lock held. Then again (I didn't even
>> consider this upon earlier insertions of such into keyhandler functions)
>> we may even be holding a real lock (the sysctl one) when getting here, yet
>> apparently that was deemed fine in the past. Plus dump_domains() does the
>> same as what we end up with here ...
> 
> The debug keys are debug functionality, and do play rather fast and loose.
> 
> While the Xen watchdog does hit first (5s), spending too long does cause
> problems for the vCPU that's interrupted (usually soft lockup).
> 
> I was wondering if we should force schedule to idle before running most
> keyhandlers.  That prevents holding a vCPU hostage (and if it's hard
> pinned, then tough luck).

We already invoke a tasklet in most situations, the main exception being
invocation via sysctl afaict.

> We would want a way of blocking further sysctl-debug-key's while one is
> pending.

That's guaranteed already by the sysctl lock, isn't it? Or did you mean
blocking sysctl ones while a non-sysctl one is in progress? (Along the
lines of what you say in the first sentence of your reply, right now we
simply assume responsible use by the host admin here.)

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 06:15:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 06:15:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006245.1385427 (Exim 4.92)
	(envelope-from )
	id 1uN3su-0005QV-Se; Thu, 05 Jun 2025 06:15:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006245.1385427; Thu, 05 Jun 2025 06:15:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uN3su-0005QO-Pm; Thu, 05 Jun 2025 06:15:28 +0000
Received: by outflank-mailman (input) for mailman id 1006245;
 Thu, 05 Jun 2025 06:15: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 1uN3st-0005QI-OI
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 06:15:27 +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 7882195b-41d4-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 08:15:26 +0200 (CEST)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-451d6ade159so4380305e9.1
 for ; Wed, 04 Jun 2025 23:15:26 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-235e7322a81sm17043625ad.66.2025.06.04.23.15.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 04 Jun 2025 23:15:25 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7882195b-41d4-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749104125; x=1749708925; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=AhHIwwgaIgRJqqWACaKi7GDCYSOcejbHNvKR1zKjwK8=;
        b=F1xmzeNfmsJo+idmjv96NrxqbQEsXRdi1bI5HeBN4Y5DI9WeoxJC/1PV9zV3FMKhfO
         d9VcplYrEKjp5M3uh5pQR1IKDTyEifY62e6z8vhGb/WdUOUpGvjgEJMuXiptFYLJ5Pi4
         XstiGsX19jxhlfxqYqS+/0JR/QZ/TL/PsiKdNGIW5jvrz/LOq0xz6vQoqCHhOikf9Qxp
         b5Mpb8TeyPNEU0aY16HQpWK4NQJ6kzlaUzRSDt3TQLztAtOVyYuAkw8R2PzAyxszhisK
         y0fafI0VoX+cJc7iCPLFDL2Td9oPVEqSxdZvXAvbqSmf1Aq6SZG03ACOiEAdl0ljIQeK
         t34A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749104125; x=1749708925;
        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=AhHIwwgaIgRJqqWACaKi7GDCYSOcejbHNvKR1zKjwK8=;
        b=R2Z/JnsPtF6PPzQpcIx/nMPFcvl8+Iyvh2+guBZ6BWrsyTCI5P/VMtGgSeyqr8uETN
         FAeTcFDTHJSQexu8qL2PbaFZ9LvcJV6Yq4JAOD1ESLcLFoJxbNcVzvxKsjQ3RrUvv7H6
         cXOfoXo5yaIrHBEj8vvmZOtMBGftCrCkqazek2CcQkdWQYAQ/UdZrPSL/pRlWlx38wxz
         QzOMQXBXpt4tr2noJXCZshv1h1bn+2LX3v0SxGSgg6GeQsFDxFnXT2jnSNM8DPBAapa/
         alOiM1gorCRe7+NOeqCrOrpZ8UFJT+Iyau1zqhln+4syFeuj2CEsN0jw/CSPT7YI/WXx
         FAdQ==
X-Forwarded-Encrypted: i=1; AJvYcCU3kB//ADjEsjt9qF8UeoJMq6NWSQsPfIzX/NDn5PcZrjcXf4F9H5EiVofabfI+6+R7oBtCG/cbQwg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxb/Iu/2+457LQe/eo33kYsXrxJMEXWvbnPjxlzmSPvq0ZBvgEV
	QLqMBonuL33gk9Gj7OywYJEEhQhHqAx5zu1TzIr987UkpfDaL6ifUQePjpDthPCQWQ==
X-Gm-Gg: ASbGncv40jyhFxM2aEpFnu4jqMT9Qjl23Z6Y+lEwk8JYtNpSc7M1cIUmQtC1yMz0gqV
	U308y/1HBuaaS9ru0PxOTqnRk+ROwvpiugeEzfsH8+S7/ReWEOHErPLEFGJgVjeHpI2sdYcf5W2
	LextFonGkgKKs1bpeiC+ifAt0+egynIdsc87DpG4w8CdhidLdWxUO/aP+jDjQ8GYltLRD31bCI9
	wFhWObAp7jBS2QfBt7PYuDTr1rAWEJTZ1o0abeks5/JzLiD88DI3d04fRLlXqGjpe0kcs+SqCwa
	oXK0qUqlt1WauJz59ghqHoAdw3sbBElIsMTEk2hl0opn1IahhcN4PYSiAImUviJPzDtjgBT/V6c
	YzRboh40SARbXLR56nZiL3Og7a14dmuAfPI6K
X-Google-Smtp-Source: AGHT+IHTpQz2jONjMnc2ZNbXX0DTzZ44iXVyzIgq7XEY/yF0j6iuEupiYkSykAlztXbBaZbTeyIZTw==
X-Received: by 2002:a05:6000:2489:b0:3a4:ed1e:405b with SMTP id ffacd0b85a97d-3a51d974bddmr4548277f8f.46.1749104125466;
        Wed, 04 Jun 2025 23:15:25 -0700 (PDT)
Message-ID: <8585aaa1-65fc-44cf-822b-d69429d81020@suse.com>
Date: Thu, 5 Jun 2025 08:15:15 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/2] xen/console: unify printout behavior for UART
 emulators
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org,
 dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250531000417.81750-1-dmukhin@ford.com>
 <20250531000417.81750-3-dmukhin@ford.com>
 <71318dd2-0724-4c2a-9786-40b676411e56@suse.com> 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 05.06.2025 02:57, dmkhn@proton.me wrote:
> On Wed, Jun 04, 2025 at 12:48:05PM +0200, Jan Beulich wrote:
>> On 31.05.2025 02:04, dmkhn@proton.me wrote:
>>> --- a/xen/arch/x86/hvm/hvm.c
>>> +++ b/xen/arch/x86/hvm/hvm.c
>>> @@ -577,7 +577,7 @@ static int cf_check hvm_print_line(
>>>      if ( (cd->pbuf_idx == (DOMAIN_PBUF_SIZE - 1)) || (c == '\n') )
>>>      {
>>>          cd->pbuf[cd->pbuf_idx] = '\0';
>>> -        guest_printk(cd, XENLOG_G_DEBUG "%s\n", cd->pbuf);
>>> +        guest_printk(cd, "%s\n", cd->pbuf);
>>>          cd->pbuf_idx = 0;
>>>      }
>>
>> Why this and ...
>>
>>> @@ -755,7 +765,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer,
>>>              else
>>>              {
>>>                  cd->pbuf[cd->pbuf_idx] = '\0';
>>> -                guest_printk(cd, XENLOG_G_DEBUG "%s%s\n", cd->pbuf, kbuf);
>>> +                guest_printk(cd, "%s%s\n", cd->pbuf, kbuf);
>>>                  cd->pbuf_idx = 0;
>>>              }
>>
>> ... this change? There's no compensation for it ...
>>
>>> @@ -1013,12 +1023,21 @@ void printk(const char *fmt, ...)
>>>      va_end(args);
>>>  }
>>>
>>> +/*
>>> + * Print message from the guest on the diagnostic console.
>>> + * Prefixes all messages w/ "(dX)" if domain X does not own physical console
>>> + * focus.
>>> + */
>>>  void guest_printk(const struct domain *d, const char *fmt, ...)
>>>  {
>>>      va_list args;
>>> -    char prefix[16];
>>> +    char prefix[16] = "";
>>> +    struct domain *consd;
>>>
>>> -    snprintf(prefix, sizeof(prefix), "(d%d) ", d->domain_id);
>>> +    consd = console_get_domain();
>>> +    if ( consd != d )
>>> +        snprintf(prefix, sizeof(prefix), "(d%d) ", d->domain_id);
>>> +    console_put_domain(consd);
>>>
>>>      va_start(args, fmt);
>>>      vprintk_common(fmt, args, prefix);
>>
>> ... here afaics, so it looks like you're undermining rate-limiting of
>> those messages.
> 
> I droppped behavior change for I/O debug port on x86 and HYPERVISOR_console_io
> hypercall.
> 
> But my understanding is that all guest debugging facilities, if enabled, should
> not be rate-limited.

I certainly disagree there. How much rate limiting to apply to guest output is a
matter of the guest_loglvl= command line option. Its default settings are the way
they are for a reason.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 06:18:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 06:18:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006251.1385436 (Exim 4.92)
	(envelope-from )
	id 1uN3w7-0005wz-B2; Thu, 05 Jun 2025 06:18:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006251.1385436; Thu, 05 Jun 2025 06: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 1uN3w7-0005ws-7r; Thu, 05 Jun 2025 06:18:47 +0000
Received: by outflank-mailman (input) for mailman id 1006251;
 Thu, 05 Jun 2025 06: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 1uN3w5-0005wm-OD
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 06:18:45 +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 ef099f64-41d4-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 08:18:44 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3a36e090102so291569f8f.2
 for ; Wed, 04 Jun 2025 23:18:44 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b2eceb96f74sm9592303a12.62.2025.06.04.23.18.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 04 Jun 2025 23:18:43 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ef099f64-41d4-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749104324; x=1749709124; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=jC4eir56QUeDqUtrV3PuuzEGAU9maPN452N8Yr+PYs0=;
        b=Y5M4oERtV7xJKfH9I2SN8pn4svHpYdkF+6+5EoYvXOOQdaIDw/Jfy4FluwKc7d4X9o
         FNEzvh16F9pkxK/uEU6OFOdto4Qp4pSq/lDDie3KZzx6C12m6vWUD5wRFRe4dyhbhNxR
         /TIndb5dRcsKtD5dCLKgMvH+C9FJ7wsUV2eQlZn40aaPHJJoeAZ7npvMCF2m5uaiEKc/
         kZ894I7d4cmNzTGJwNSCuKtpo+Emd7T2BtRIO4uEtdK4vC0/iGHFhHwwAAm7mwi6BgpF
         OaP+whPH1I2y/IeDui8yedcFXpA7o0ieZJaiq1V2U36KZU4zIMLUIwm+N1KJzx9Q3cgc
         ro6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749104324; x=1749709124;
        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=jC4eir56QUeDqUtrV3PuuzEGAU9maPN452N8Yr+PYs0=;
        b=pN29U5RqgYa8eFiuuOmIekvKyysrXhA3RfTQVphGJQh1tQbLM+nqJF59VEFAMABxgK
         v/i2gz6anMuPw9p7Gk8nrnWvSZfmTRajGqUc81EkJdtqETVXyy/4Zv0meUKnmGYe4oWU
         Et9QW4dmSVJ39KOg3aLSXp+k2noftCiKP4VTQlWEmvf5P8rpZIhjVHm6LST4CTX35tNs
         BQabNn2BmnBUeMafq98BEQAQ0XQKo/2RRgAH9aFqA8MEotMu6OlGLJIwZgsqJEFRLCFV
         QCCc3ropP3f73evGHESpntnXZ6CfetmN1RAO/uH7n4+wWP3te79DmHV1n7z+k52MNDTg
         FsqA==
X-Forwarded-Encrypted: i=1; AJvYcCUiEdci6cQ6vUwyYOufoqBwKYHjQBTOoaA4aASlPBj630HzUkkTrG2fIwOo7FunlRSsBVLp7FpyI04=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyz/rffRBJKumvpS05JQm9XXe5CzNjqNov6e2RdetX9FjHacSUT
	SZD0HzGUP+o2xgdEj9Yn5yCT2kftn6k2C+iytXYwKrcmv9T3UX9xLiqul03PjeUanA==
X-Gm-Gg: ASbGncvHS+D5ikDDlq0V+5GcQdDKc0IRonveknDIcQi/Y6jv7bXuy0AlcBRB68tHXXf
	LWhrjdCYhYXz8jTq2FtGKYfDe+S6O8ELWUzCMd4XdYO83164CiMebUwNNmj8pIMRT9jpXSdXwm3
	8HOm0nuo5P94seR6uj4yCDPY3gxjB1iFxnqwrAUYcHaIZzBe4/IxmbnR3EGwcOMHDzsb/nqrQNG
	qBwOWJ40trCc9TFkq+RKPDDA031DN67N3VEaEWUlr83I9P8yB9RTHHY+djrGfK/8Pz1VRUDDNK4
	xp1b78YRvUuIj9J12xwmZcxUkkJvTouHWWoQrM10TeTFO6Q1GAxp/A59J7raxLLcaBGpidQlfPQ
	+P7sJ0W+ZAhcl1qhQV2ltiL2GyV1X6ROJJVw2
X-Google-Smtp-Source: AGHT+IHadoUCl0ZXvlEzsufjYXp42virJcyCAo1Zop8+VZRJYrXMrTD7eD3GVj+WdeXFegM/HBJA9g==
X-Received: by 2002:a5d:64c6:0:b0:3a4:dc80:b932 with SMTP id ffacd0b85a97d-3a51dbb5fbfmr4402134f8f.8.1749104324264;
        Wed, 04 Jun 2025 23:18:44 -0700 (PDT)
Message-ID: <842528df-d0ba-4ab2-b182-b6f824c82dc1@suse.com>
Date: Thu, 5 Jun 2025 08:18:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/2] xen/console: unify printout behavior for UART
 emulators
To: dmkhn@proton.me, xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org,
 dmukhin@ford.com
References: <20250605004601.1142090-1-dmukhin@ford.com>
 <20250605004601.1142090-3-dmukhin@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: <20250605004601.1142090-3-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 05.06.2025 02:46, dmkhn@proton.me wrote:
> From: Denis Mukhin 
> 
> If virtual UART from domain X prints on the physical console, the behavior is
> updated to (see [1]):
> - console focus in domain X: do not prefix messages;
> - no console focus in domain X: prefix all messages with "(dX)".
> 
> Use guest_printk() without rate-limiting in all current in-hypervisor UART
> emulators. That aligns the behavior with debug I/O port 0xe9 handler on x86 and
> slightly improves the logging since guest_printk() already prints the domain
> ID. guest_printk() was modified to account for console focus ownership.
> 
> Modify guest_console_write() for hardware domain case by adding domain ID to
> the message when hwdom does not have console focus.
> 
> [1] https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2412121655360.463523@ubuntu-linux-20-04-desktop/
> Signed-off-by: Denis Mukhin 
> ---
> Changes since v1:
> - dropped change for debug port and for HYPERVISOR_console_io hypercall

Yet then what about ...

> --- 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);

... this dropping of XENLOG_G_DEBUG? In fact I'd have expected such to
be _added_ where presently missing.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 06:31:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 06:31:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006257.1385447 (Exim 4.92)
	(envelope-from )
	id 1uN48E-0000Px-CF; Thu, 05 Jun 2025 06:31:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006257.1385447; Thu, 05 Jun 2025 06:31: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 1uN48E-0000Pq-9D; Thu, 05 Jun 2025 06:31:18 +0000
Received: by outflank-mailman (input) for mailman id 1006257;
 Thu, 05 Jun 2025 06:31: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 1uN48C-0000Pk-Hm
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 06:31:16 +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 ad7b1d3a-41d6-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 08:31:14 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3a5123c1533so284893f8f.2
 for ; Wed, 04 Jun 2025 23:31:13 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-747affafa34sm12555519b3a.103.2025.06.04.23.31.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 04 Jun 2025 23:31:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ad7b1d3a-41d6-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749105073; x=1749709873; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=LD1YIKKhP4Y4E1+J+F+lZ84K9Y0IuCjjqTjOSBewbQM=;
        b=XJ1XRCscL6eoGrHJvnEt6dYZvQxyyZ8dnXycR2dv+vGRi1ghO2NeDz/Yza2pMrUfyb
         JACZ9S99/DriXMWvK4q4Mu2l85mptG7k7bcISAgHuK7KtqSubcnpw712b9QH47vN14Ij
         sBuct6/aN8CCVHWh9Bm09ohOTcjnTsn9oibEug1GZX8TVljjmnlK/h4RkyrL7RvQ31XI
         V8dwuZVjk3WbJv1S6p6zHN9jwtC9/IbHthSr3CNgV4FkTXxWufSN2l3O9sYqnKuQz+ez
         czC2aga2jusiUylh+pUUkiW05KdooyjcozlIb9MhDOdpLrP3k6fm0QF1EPxXdJalnz9A
         85iA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749105073; x=1749709873;
        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=LD1YIKKhP4Y4E1+J+F+lZ84K9Y0IuCjjqTjOSBewbQM=;
        b=l/UfEEY//1FBSuD3z/kTBjWjI3d1ivjYJd1yHjSpnYoZams+eai7XmjpOw5FQoc8DV
         sYbV2on27vWilqavnVH+/hx0qEw8/3a2S2iASskHxvliardZA5a2kfBI41udmvgjUMEn
         /JEjVHUkQHDIjFExHtg9D8mWnzFqMaUNRDS6zLfKwgRBQjGRigcvIlIxWAjrwJAzMUDT
         6t8PBWN5oI2FqSH664lAZlOHsv7TbRYq4NA2uEv90qw1pxqZZKJQOiW0NrltBhR9OFSs
         JVQJIgR+b8o7V+QQm3uPWRb9Ce0mFxroRm+qDhV8zvJiU+0nMxjiHQhjFJYCMrt9uPc9
         nRZw==
X-Forwarded-Encrypted: i=1; AJvYcCVrwUsXNoxSf2TkAvQSfuaiujfLD35KcALaZxeiihoUJWsFtta6idjeQweQ32sDuKxpb64kJkSbaa8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy5TK1Cr6cyZBz/8tHCNeIu3qRpADZlyHuD48/pcycrji86Exv4
	YA8R7BpDMXEOQS/mO38P3BqddZmZ82tw+emGykSWMlaoPgst9w5CiMSTPVEQJGm+3w==
X-Gm-Gg: ASbGncsepQme/wjEhnBVXmN5uG4b6LmG3GNQ69Q3grLRlT07hH1nd1zCuUohh4LWONJ
	XPlrFfXxWuleVf9M80b73R6vkIpSp8lWgBPpEtz+iNHGT17h750l8GSwbTfKzBhnXXhayR3RED0
	tKEl9v71HKVrcQI1gwM4Ko5Jg6OV/dsat2D6FDVPK8wA87VlVauG+mlkVY6cGbh4et2TcLA4QSi
	J3lCd9RqyK61MmNrZHVGqnHEerYLFidmoDyrhwIO/xzoGPtC5TaSFqMLVZbDK5xwQ8aHLucxXP8
	aMbPyBOcNkompAtPU3ZoOKPDZDYFzFcSCh08MZjDQJV7MkzVDv1YX3oDPFygBDHSFDqFIgVqXoS
	kLTVKWXED1Al3fg++R8yjK0wi7KtYrICwI7LvKyWLeUD+x+U=
X-Google-Smtp-Source: AGHT+IEaWQ+kW/CdH9J4SmVMQMUWyP38GtH3Z1cvnjfiTCKnPKNcEWsZjPALlBNx2TK8ZZx0xd9zVA==
X-Received: by 2002:adf:cf0b:0:b0:3a5:2208:41e3 with SMTP id ffacd0b85a97d-3a5220844f3mr2539475f8f.4.1749105073274;
        Wed, 04 Jun 2025 23:31:13 -0700 (PDT)
Message-ID: 
Date: Thu, 5 Jun 2025 08:31:05 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86: remove memcmp calls non-compliant with Rule 21.16.
To: Stefano Stabellini 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Alessandro Zucchelli ,
 xen-devel@lists.xenproject.org
References: <20250604233537.2892206-1-stefano.stabellini@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: <20250604233537.2892206-1-stefano.stabellini@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 05.06.2025 01:35, Stefano Stabellini wrote:
> From: Alessandro Zucchelli 
> 
> MISRA C Rule 21.16 states the following: "The pointer arguments to
> the Standard Library function `memcmp' shall point to either a pointer
> type, an essentially signed type, an essentially unsigned type, an
> essentially Boolean type or an essentially enum type".
> 
> Comparing string literals with char arrays is more appropriately
> done via strncmp.

More appropriately - maybe. Yet less efficiently. IOW I view ...

> No functional change.

... this as at the edge of not being true.

> Signed-off-by: Alessandro Zucchelli 

Missing your own S-o-b.

Also (nit) may I ask that you drop the full stop from the patch subject?

> --- a/xen/arch/x86/dmi_scan.c
> +++ b/xen/arch/x86/dmi_scan.c
> @@ -233,7 +233,7 @@ void __init dmi_efi_get_table(const void *smbios, const void *smbios3)
>  	const struct smbios_eps *eps = smbios;
>  	const struct smbios3_eps *eps3 = smbios3;
>  
> -	if (eps3 && memcmp(eps3->anchor, "_SM3_", 5) == 0 &&
> +	if (eps3 && strncmp(eps3->anchor, "_SM3_", 5) == 0 &&

Unlike the last example given in the doc, this does not pose the risk of
false "not equal" returns. Considering there's no example there exactly
matching this situation, I'm not convinced a change is actually needed.
(Applies to all other changes here, too.)

> @@ -302,7 +302,7 @@ const char *__init dmi_get_table(paddr_t *base, u32 *len)
>  				continue;
>  			memcpy_fromio(&eps.dmi + 1, q + sizeof(eps.dmi),
>  			              sizeof(eps.smbios3) - sizeof(eps.dmi));
> -			if (!memcmp(eps.smbios3.anchor, "_SM3_", 5) &&
> +			if (strncmp(eps.smbios3.anchor, "_SM3_", 5) == 0 &&

Here and below there's a further (style) change, moving from ! to "== 0"
(or from implicit boolean to "!= 0"). As we use the original style in many
other places, some justification for this extra change would be needed in
the description (or these extra adjustments be dropped).

> @@ -720,10 +720,10 @@ static void __init efi_check_config(void)
>  	__set_fixmap(FIX_EFI_MPF, PFN_DOWN(efi.mps), __PAGE_HYPERVISOR);
>  	mpf = fix_to_virt(FIX_EFI_MPF) + ((long)efi.mps & (PAGE_SIZE-1));
>  
> -	if (memcmp(mpf->mpf_signature, "_MP_", 4) == 0 &&
> -	    mpf->mpf_length == 1 &&
> -	    mpf_checksum((void *)mpf, 16) &&
> -	    (mpf->mpf_specification == 1 || mpf->mpf_specification == 4)) {
> +	if (strncmp(mpf->mpf_signature, "_MP_", 4) == 0 &&
> +            mpf->mpf_length == 1 &&
> +            mpf_checksum((void *)mpf, 16) &&
> +            (mpf->mpf_specification == 1 || mpf->mpf_specification == 4)) {
>  		smp_found_config = true;
>  		printk(KERN_INFO "SMP MP-table at %08lx\n", efi.mps);
>  		mpf_found = mpf;

There are extra (indentation) changes here which ought to be dropped.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 06:39:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 06:39:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006263.1385457 (Exim 4.92)
	(envelope-from )
	id 1uN4GL-00012a-6E; Thu, 05 Jun 2025 06:39:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006263.1385457; Thu, 05 Jun 2025 06:39:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uN4GL-00012T-2Q; Thu, 05 Jun 2025 06:39:41 +0000
Received: by outflank-mailman (input) for mailman id 1006263;
 Thu, 05 Jun 2025 06:39: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 1uN4GJ-00012L-Cu
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 06:39:39 +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 d9b3373c-41d7-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 08:39:37 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-451d41e1ad1so4345385e9.1
 for ; Wed, 04 Jun 2025 23:39:37 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23506bc8b04sm113474505ad.45.2025.06.04.23.39.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 04 Jun 2025 23:39:36 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d9b3373c-41d7-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749105577; x=1749710377; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=fwd3yPHT98LmiMqwu3HWqnIgMVBoMIjtt5dXJw+Tc+g=;
        b=DUeJSXJ6/CIEDSIe+3QjLGbFksK9H5q/lyytfLD7E2yUe8Lfe6k3vI/tXJ5dLbxGoI
         7cgPCqz1yeAba3vevhD8qKM8yGTGTA/jh0doaAQrK6UhsCXNn7J6CIkfVPlKOu3T2Y49
         xmXOplTWmZZbPOF9uCGsQfZLES5irxHPSAppw3uMAiVlFFYfsqCfuGKm/zG29tq6yXi+
         Kha0XSGAsifSNcmgE9fZJeqyWOZge6ueYcWt+2o7V/Lx0b6Vd8Vw5GiX9Sza0/Docukl
         NmQY7Hur4gcKpcaE6EXEnO1xqWoTCGzqfY/iC+0F9I1xnCRVBUjJ+C9dlb89Q2l+bDYe
         cJ8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749105577; x=1749710377;
        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=fwd3yPHT98LmiMqwu3HWqnIgMVBoMIjtt5dXJw+Tc+g=;
        b=vJA7YAbw9UjjxQIbn4TxBHFRR4UQdFO1vMZ1WiUNB9YxsbhOI477Tn2SNtf1+SRdzx
         icxsdVvxd17PYRnxXwA5XLnt2eNcdcJ2BvTjqr8ZqqAVfsxNoAtQhkZ3tuq2Nt92jyaB
         rnjrGzA/wwFvS2UDqDi+Pf6yzcdt4k1J5KTxZbRqEJEA+NRCjaL0QqWAnOMXxgJhPePH
         4tBKj9hsaCcMj4gc/p2nxwkxHUeC75v0fyKIhcVuOyYVQwZL0MysoXDdS3OC2IHRBHNd
         39x+nErBCkFIa4BQ5JtVbpqbl0BhTY+ojwciK5VZ9VSoFB90trgOL4VsP3Zk3DQOPuMs
         eBDA==
X-Forwarded-Encrypted: i=1; AJvYcCUnqvcDaN0loQqoiGa4albaBycKVZrUGtWRfOSwZPdpey9O53EKcEYJQsjv2RGu2+yWvGg3pDZg0lA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwNGBf3McXDbh36emgbGXLJNAFOZdYlLEhsjb9ADeoXOQvG4Sx3
	6leRav5eZUW+H0g6SHMqEB1QXP2OVKc4QxBXdvJCCvH8VtFvp6zhB1YvCJJYmhQxBw==
X-Gm-Gg: ASbGncsSyu4usu+RwXMJ60Ek4O0g9UBXbcf99ALhUZ6pHzqcqlFkU+Jj+PHQdLETogT
	f72AbHiPM/x3QruLJKg1OcspGhUvTS4kx+i641q+P7wBHG5SXpdWMgRPMJm2zHEZg3N20JIXt6P
	9NyEtN9BwS1psr9JQql8aiVoK80uN9APRrbAs8YK8KOBEGReEju3OK2vpI78lUeWBLXcjdkHS72
	s96Umr1ZedOT47Em0z6/pVrm3iW6t0jIFFCieXSn8NkoGVaQ506EU+3W8W15Cn3lshHvqLzvZQh
	eAgsuSvQaUBkR+gzzRtQ8uV4sY8hxTkd0pBNYsQM0ViJMfJtqAOEBO891QjwF/07DlOzKuy5j9w
	b5KmpTffCHMlpGfpboJ2PfHs5hB+Bavffbt90gCY/GLKA8gw=
X-Google-Smtp-Source: AGHT+IFFYPO9uFt0RzK5cboGIq4WkTNLr37wMXWxt18xqBZHV/CEIsr6uH/HgxzF+9IeeQv4833e8Q==
X-Received: by 2002:a05:6000:2dca:b0:3a4:e672:deef with SMTP id ffacd0b85a97d-3a51dc316bamr4424285f8f.36.1749105576900;
        Wed, 04 Jun 2025 23:39:36 -0700 (PDT)
Message-ID: 
Date: Thu, 5 Jun 2025 08:39:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen: add header guards to generated asm generic headers
To: Stefano Stabellini 
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech,
 michal.orzel@amd.com, julien@xen.org, roger.pau@citrix.com,
 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 05.06.2025 01:09, Stefano Stabellini wrote:
> --- a/xen/scripts/Makefile.asm-generic
> +++ b/xen/scripts/Makefile.asm-generic
> @@ -32,7 +32,12 @@ old-headers := $(wildcard $(obj)/*.h)
>  unwanted    := $(filter-out $(generic-y) $(generated-y),$(old-headers))
>  
>  quiet_cmd_wrap = WRAP    $@
> -      cmd_wrap = echo "\#include " > $@
> +      cmd_wrap = \
> +	upper=$$(echo $*.h | tr a-z A-Z | tr '/.' '__'); \
> +	printf "\#ifndef ASM_GENERIC_$${upper}\n" > $@; \
> +	printf "\#define ASM_GENERIC_$${upper}\n" >> $@; \
> +	printf "\#include \n" >> $@; \
> +	printf "\#endif /* ASM_GENERIC_$${upper} */\n" >> $@

I'm curious: In what is now a0f56da94c3e I had to resort to "define" to
get the rule to work (including a correct .*.cmd being generated). I
can't claim I actually understood why things didn't work the "simple
macro" way, and hence it's unclear to me whether the way it's done here
will work with all make versions.

One further difference to that other commit: If make is interrupted in
the middle of any of these printf-s, an incomplete file may remain. The
cmd_xlat_h rule specifically uses "mv -f $@.new $@" to cover that corner
case.

Finally - is ASM_GENERIC_$${upper} actually correct? Isn't that the
guard that ought to be used _in_ asm-generic/$*.h?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 06:44:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 06:44:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006273.1385466 (Exim 4.92)
	(envelope-from )
	id 1uN4LL-0002oq-Pl; Thu, 05 Jun 2025 06:44:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006273.1385466; Thu, 05 Jun 2025 06:44:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uN4LL-0002oj-Mr; Thu, 05 Jun 2025 06:44:51 +0000
Received: by outflank-mailman (input) for mailman id 1006273;
 Thu, 05 Jun 2025 06:44:50 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uN4LK-0002od-Qe
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 06:44:50 +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 8edb1c6d-41d8-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 08:44:41 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-450ce671a08so3288565e9.3
 for ; Wed, 04 Jun 2025 23:44:41 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23506cf53b5sm113541535ad.176.2025.06.04.23.44.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 04 Jun 2025 23:44:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8edb1c6d-41d8-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749105881; x=1749710681; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=GgyywJP5ynHnrlaMEb819bvlv5C2nMuRfpi1tLHSqTk=;
        b=cocRUGr3FR88RRNegtMTsNWVO8o/fwjodgGCiP5luub9U3j0wQHNP45JJG1RPs68Uq
         WCbNZn90kTZjEnLnleqnIC7GloSnhtd0GGoO/U4xPC2ITER3oGG+SLOS3o6blI5ZIiVd
         AnmH0clf/o0TdgRZgCwLoXC3eZ2B9vtG/pp3sxuaOwq+OIK9C9sEVzMqxft6dgk2hzmA
         5f9HoMHwd12Cot5XLfII1YE101hkYcBWDnNaOUESzOzQ3KHLYy4nnFdOD4qPa3KT0Q4b
         ZarrUPnVQeRrz22AW4faQODRYXmrIz3DVplg9JV4Qz5nQdeBPmh1NA8015AxDx6vHEyK
         54Qg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749105881; x=1749710681;
        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=GgyywJP5ynHnrlaMEb819bvlv5C2nMuRfpi1tLHSqTk=;
        b=YGGuXgO3Tk7dais62b+Ot7dG8OcvcdtZrpxyhuGhhdFsOMsahOginHiOVyjxxmzklb
         UDrWRc/BDIbR/tNDJsFD0P3l6oJ2nrI87UNSLI50CvQoNQs+maBmoXRGYsNr92COa60a
         hHbhJXQC54KaKG6qa3042RoBxZtkM6Vj9/xEqOesgWr8VEMf/YhzZSyu28n5RRFaLaNQ
         r87PoKGH4gFgM6TvlJyq158/NX44i8opfo4yJ6CAFvXuKAH38GqrjXZGPfuCF+V4Rv4F
         qPgez0Wr6f0xOhsAevneZVgXItILCL2Ez3YPfrMwr2je7p/RYDAfPAcjUGLMpSRZuG8Q
         AVAw==
X-Forwarded-Encrypted: i=1; AJvYcCV8J8sImKFbtjFvw0x3Qp1NVWOjJ8VA6gA68Uln29SXpK29N733s/ItgSQnLZKLjvkQLGGQfJdh+lE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzvcf8KYxhUqRnMO0dLb3oHR8LTQAvpOvi+ovOp7AbaLQ7VWBUl
	jfSSJyP95apaNsltg3ZjQHQuvwv1b0sEBZd9bpkUfduAWd1LH1ghzGSXukVfqmzJ8A==
X-Gm-Gg: ASbGncvooyPN+grbrua8vUOGVU81+Px8kxPn0MU7GQiWSXHvA/S8zw2SAq3kurWZorA
	BtLLrTn4yAdmZ+9sCvIx8YtRoyQsLbRz5pMe1LL29t33bPr37esbqNCm44ZLw6wdTWrarmP2pMI
	hW7jaWPqVDpk8fHEDxDhToxvdtFttHBw7BMjOSCreJ9hRqnjkh+2hvUOmG8RWlhLIir7ymZlTtv
	mcJsl8m0Rslm4bXt0kvgXD0Zm7ql+huNzn3BVYk6fFmQrOvwpjCl8w35GrYVTmpde5t+qqr4d4a
	btyZ1Saaw1wEnWFY0kP3VFTLJI3GEkDq1N/csgnhmzlqmGcpm4M1wbXc7375umFtOMOAjE+jdOW
	4d61gxsadfIF6MXbw+JSpfksX6hyt/fI9VhT5d1FONiETSHE=
X-Google-Smtp-Source: AGHT+IFNlMLietISVppGKM7b/wqlSV9AFZvPb98DDuP/ACCpLp+OxMIHriLeZPSQtiK9MCXljGMSXA==
X-Received: by 2002:a5d:5885:0:b0:3a4:c8c1:aed8 with SMTP id ffacd0b85a97d-3a51d973a3fmr4391344f8f.39.1749105880932;
        Wed, 04 Jun 2025 23:44:40 -0700 (PDT)
Message-ID: <8412c795-610b-416e-8d22-4149d2492517@suse.com>
Date: Thu, 5 Jun 2025 08:44:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 1/2] xen/domain: introduce common hardware emulation
 flags
To: dmkhn@proton.me, sstabellini@kernel.org
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, teddy.astie@vates.tech,
 dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250602191717.148361-1-dmukhin@ford.com>
 <20250602191717.148361-2-dmukhin@ford.com>
 <093dc85d-ebf3-4982-8888-db4e7cfd0e45@suse.com> 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 05.06.2025 03:17, dmkhn@proton.me wrote:
> On Wed, Jun 04, 2025 at 12:36:17PM +0200, Jan Beulich wrote:
>> On 02.06.2025 21:17, dmkhn@proton.me wrote:
>>> From: Denis Mukhin 
>>>
>>> Add common emulation_flags for configuring domain emulation features.
>>>
>>> Print d->emulation_flags from 'q' keyhandler for better traceability while
>>> debugging.
>>>
>>> Signed-off-by: Denis Mukhin 
>>> Reviewed-by: Stefano Stabellini 
>>
>> It's not becoming clear why this would want doing, nor in how far some of
>> the bits there may gain "common" meaning, too. Imo this kind of change is
>> meaningful only in a series where later the common-ness is also used.
> 
> I have a set of upcoming changes here:
>   https://gitlab.com/xen-project/people/dmukhin/xen/-/tree/vuart-framework?ref_type=heads
> 
> Specifically,
>  https://gitlab.com/xen-project/people/dmukhin/xen/-/commit/17f44d23c1904374963c4ec839bc8219041b5d26
> 
> enables the use of emulation_flags on Arm.
> 
> I can move this patch to the upcoming series, if needed, but looks like it is
> OK to have it for Arm even now.

Prior to that series making it to a ready-to-be-committed state, it'll be
(effectively) dead code on Arm. Which strictly speaking Misra objects to.
I wonder if you, Stefano, considered that when giving your R-b.

Further - what about PPC and RISC-V?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 06:45:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 06:45:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006283.1385477 (Exim 4.92)
	(envelope-from )
	id 1uN4MK-0003K2-4A; Thu, 05 Jun 2025 06:45:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006283.1385477; Thu, 05 Jun 2025 06:45: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 1uN4MK-0003Jv-0R; Thu, 05 Jun 2025 06:45:52 +0000
Received: by outflank-mailman (input) for mailman id 1006283;
 Thu, 05 Jun 2025 06: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 1uN4MI-0002od-GO
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 06:45:50 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on2060b.outbound.protection.outlook.com
 [2a01:111:f403:2412::60b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b734c31e-41d8-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 08:45:49 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by IA0PR12MB8350.namprd12.prod.outlook.com (2603:10b6:208:40d::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.35; Thu, 5 Jun
 2025 06:45:44 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8792.034; Thu, 5 Jun 2025
 06: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: b734c31e-41d8-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=LBygWqfiULxUVkKoYC6sOKPxajfdRl5x3dNOJwvnSk+uatielJe1GMmm93gQJg5Meqxibmv4WMByJuvBloD67QWP29Uc37wHNGZAyQKbM0MFuw1QcySo8G2DvPWYZUmmGHJU7g4f7EiCNdyv9xV7NgCoOG9A/pjXHZTr7ex0mUzpnzc1TOOwyVbUXfmiAsRZGwX7MSOk/T2Hf+xSggbVB/w/i4AR8Rsjltad8dSr08Ekp1s/WwDfZ2HTyC+0GYfClA8oqzC4blN40G/RmObntNkA0f4hg2949PWezqYXD2/z3CUIxcHz4A7ww0K2xO+szlOIDRrwlXptDgvmuT/i+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=DwMKXWFlV1yC73Rj+zORFY+lz6V4Qnpj1arWCCT33jI=;
 b=QAoYS8cXsignGd9K7UgDlND7xKlURnU6S+a4ZzlorOIxQc7ZTTf2myMq0dEmvwMDZI4SjINo5aq0w0TPmx1B0DsqTLGqBX1+CTsz3OVi+FhRsWbj6zcmUWH17oV/rGEJ6fJfjVEjZYsiUPJv8GGxf+uaoU8APwfL8E5CtYAiCi1oBFqR2OgjRVH8w5WVe/vEwiXw3rDdVkvemobVmlkqYjzN4HYBgXbonkJfWMOeFy009qyEXsWoYVtf2ss0ZQBzWRiYmzvWVl0CjWs34YESzR8zg/z9Fl8UkXBwDtTVRVXCFEQHyl8Cn6xrFDyh+9k9Qkxguc5Hzo3xZObUOqxkOg==
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=DwMKXWFlV1yC73Rj+zORFY+lz6V4Qnpj1arWCCT33jI=;
 b=uX89VS50WYSC8fOlHL8nz9iKRYtDdBHwkU4lXUo/SKV+JIzSSEAJc9AcXHTXjbH2cojzTSx2Gw2FWotcJPiBZpL1jDk+PSu06M7AWKjoIdyxPqt04vTHKC/j2GXXBikjpZq5rOFdpMdZofsvYr7caAcQ3FuaYmAA9nwYzkWdSuY=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <861e66c8-c225-4913-b00e-4dfb2c1e0e39@amd.com>
Date: Thu, 5 Jun 2025 08:45:40 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/2] xen/arm: exclude xen,reg from direct-map domU
 extended regions
To: Stewart Hildebrand ,
 xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20250513195452.699600-1-stewart.hildebrand@amd.com>
 <20250513195452.699600-2-stewart.hildebrand@amd.com>
 <54c3d341-1d7f-428d-89a7-ce4fcae8a5db@amd.com>
 <4bd41362-6ee4-44d7-9f9b-0ffd78f1e6f8@amd.com>
 <28b22fa6-c6f9-463e-8e7e-0a00eae88737@amd.com>
 
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR2P281CA0003.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:a::13) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|IA0PR12MB8350:EE_
X-MS-Office365-Filtering-Correlation-Id: 67ef4bd2-a933-46e0-c62d-08dda3fc9889
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?YS9zWmxjUkd6K1Fadm8veXFXb2dRTHhKQXd4eFdldDlLNmZwMytRNEJSdnhK?=
 =?utf-8?B?MHRkZUtXRDNsaUJDQThEUTJNVHladzdRcVFBb3kxcWcyU1BLcjBtSG1QdFVa?=
 =?utf-8?B?R2xhdTNqQmpRYTRhbDNOUk5aczFHeU9zaTh0QTNZUjdTZ0p2WUxFZmxLV3Ew?=
 =?utf-8?B?TWVDc1VwbXJ2dkYrdTRJSGxVMnk3SS9jTkNOeDQ2ODNKemcxcTdlQVkyYmth?=
 =?utf-8?B?dnJCWHZRMERnVnhJUWU0bnIzbDVxd3lGQnY1U3pOZ294V0piL0ZpTFRkb3Q3?=
 =?utf-8?B?Vk1NMHA0ZHBzbStVZS9sNGVMb1M1bmdsL1FiMmt1eHEwTlV3R21kVWw4Tjk1?=
 =?utf-8?B?djBEMEhGNHpROHQ0TW9HZ3Jkd1ZWNHJTSzJkZm9hV2pqWWtGTGl6WnBjSnAv?=
 =?utf-8?B?WWh6SDJGdjB2ZDNCcTFpeDQ1U1ljSlltSWtWQ1RhSUVCQ05HR2xXYk5VSFds?=
 =?utf-8?B?OURJbTA1UzZJalFodGZkVTcrUUFDdlZub21CcTh2YTdPd0hQajZCWmpKZmh2?=
 =?utf-8?B?L0RWb1ZWRFY1Y1lTQXVkYUxhRzRmb0gyZitJOHNubjdFWWNGUlNwVUFWRzVj?=
 =?utf-8?B?ekV6ZFZMVitmV3dZSUtUU2J5bkJtWjIvemwwbnd4VkRGZmRYdFpaOWEzSE9E?=
 =?utf-8?B?ZTBRRmhnRm95NFU1M2ZXQWpIY2cycEYzbzJaUVZEVnBxOGlLdXJPSEsrLys3?=
 =?utf-8?B?UGZzdHdtR0hKU0pWbGFXaWRuU0FRNXZWenV4NGpTU0w5YUhBRndFeXdzYWNo?=
 =?utf-8?B?czRpWlJJQzhJWW50eWdNNjlqeWlKME0xYWMvTmtkVGRVNVAxSTZtcWpTbmph?=
 =?utf-8?B?MWpMUUxNUGJQSlZxMXhMa21HTExEcGMyMko3Q2tsaWNHTjhaMTVFRXMzeFp5?=
 =?utf-8?B?bE9uVUFRL0tLSExwdWhzZEJqa0hLdjlrUGFYczNoaDNPampHL05hT0hWRUo3?=
 =?utf-8?B?NEc1TW0yeDhGT0R2bHM0RjlseWNwYUV1M2w1YkJ1UjZhVkJ3RXJzanprK1hL?=
 =?utf-8?B?dWUxQUxMSnA2cWVRdHA0M082V0lva2NDa1ZTMHpjMGlHWElFMmJoeUoyQnRE?=
 =?utf-8?B?WmZCQmMreDVhU1pUQkF0UjAybUFvQUtra2lFMDZvN3dyUE5Pa0V0N3JLM2Qv?=
 =?utf-8?B?YlpTWnNJWTh0WEhCNElnem9EYjd4bFFqZ0VacGoxRjFlbDBqcFpOSlV1b0RS?=
 =?utf-8?B?d3NKWFh5S1R5WVVNL3BLS25PWk05SExiVEhxQ1A5OHB5cE9KeVlYTXFIM2Ux?=
 =?utf-8?B?VlpuNktnY2tBakEzdUl4RGE4UW5wZWN0WVg3dDF2dVJJNFByMmdFUHVlY3d3?=
 =?utf-8?B?bDVkSTNCSHV0blZlZGJpemdRV1QzMnU1MFV4VVVBU3NYaGZaZ05aeHUzSEtp?=
 =?utf-8?B?dGtWcTN2MUFMN3ZZWGFua1RlU1BlMGZUTUFxMlJXUnA5Vk56SExhZ09WWHY1?=
 =?utf-8?B?Y28xZG5OcHFJb2I4Vmo5TWlOWVhUd2tMZXZWQ2FUaitRNnJwdWVYKzduZG5r?=
 =?utf-8?B?TU5JaDRLcVpRMkNsL1VTTVFiQlk5cU9CaTlyWkxyQytreUd5VENXekUwamxv?=
 =?utf-8?B?TEZ4bnVmL1h3OWJQNE1UV0ljd3RRdFpGTWpHWXI2N2F2dVhRS2VEcC95YVVv?=
 =?utf-8?B?ZGxaQi9yamJPUWV5eFRsaGZqR2hlbXpNNDZTMVRMcTJRSHd1ZFJ1c1YzTDZB?=
 =?utf-8?B?cjZqbWRQQU0yMkdsYTI4dHdGL09FVnR1RW1jYUFlczlsdEhqbFdtdGlxczN3?=
 =?utf-8?B?RysrZVgwdlZSRE5rYk8wdWhFZ1kvaHVnK012Uk9zMk1pSFF3R3psWlZWQWRR?=
 =?utf-8?B?ei9heFBzRzlLSGY5RGpqMTJ5Q0YzeHY2QW8vQ0J5RFFkK2IvRjZjem82azVo?=
 =?utf-8?B?T1NDN1Awem4vK0h3UGU5UUJqYkc3YXVjUDRlZGp4cEhzQi9VOEVVL1RQRldP?=
 =?utf-8?Q?NOk5JvYb11U=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.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?RndCMzhQM2RrOFlvZWhiM25vcFg0NGN5RmR2cytrTWhaKzdKMzdmN2hKVkww?=
 =?utf-8?B?by9jci9KOUN6NUFrRy83cXVpNURvVXIzUWgwdTh1dlFUMnZnMTJJbjBnVDB1?=
 =?utf-8?B?S0cvemM0MDdCZzFqbFZqS1ROYlZ1Q3Y1QzBnaDVYcXpqcWg2d0hMNTRka3JS?=
 =?utf-8?B?OVBTMUJnbTdicXlPM3o2SFlLVmNjZUhUOVhOUG1pWUFPYmtSdzIxOENwOGRl?=
 =?utf-8?B?S1EvZ3BQL3ptWEU5VWw3dXFzRDNFQW9WV2FkQXBVdUkzV2V6R3hmWG1oam93?=
 =?utf-8?B?OVE3YnNFVlRYTHBxYmxzZnhDQWZPT2ZIK3J0ZEhiVWlVQTNaeDdCRG13Z3VS?=
 =?utf-8?B?akVPQlJmQURPWkt2ZVVraUQ2UW9VNXQwTFFrZlpvLzdaK3EvSGUyTEVXTXZ1?=
 =?utf-8?B?RDlsNHdPaTZnMjNTVnNvK3NIU2hOb3NUWjd5UzZ0OG16c1UyRXhmMnZNS3ZJ?=
 =?utf-8?B?WUEvNEtTbE1vQ01QMVlyUnF3OWk0VCszWFdYVHhNUHliNGJuUW1xekZvaG1X?=
 =?utf-8?B?R0lFWnlmZjlMd3B2T1ZtQU85UDcvNElYZzdDQnVMdlZlL1NER1hvRGNCYVpV?=
 =?utf-8?B?VWdLcFhVdnRnVFUrK3lCUER3bnllNVo3Wi92SEJXaGRJNlZVZXg0NUJ4S202?=
 =?utf-8?B?aDIvcGhJRVRyRGowVVVhSzd0Vm5HMW1CZU1Jb2Z0T1ZpZGYwdEpqdU9aUC9n?=
 =?utf-8?B?eDQ1Z1cwcG5WVE1zRDdJNVZPbEF1MjJ3ZlZjNFZydmJVZWRjeHVwRENuZC9B?=
 =?utf-8?B?b0loSEh5U1JZa3A5Z0JBelJNdy94THV6MTFiVXptOFI0TG9BR0g5Z3dyQXlZ?=
 =?utf-8?B?TjJ1dDN0cTB3VlFkeUZtc1gwWWExOWl0U2Z1M2puY0tMV243OENEcXhETW5q?=
 =?utf-8?B?S3lveEQwZUR1Qk1iOWVNUDBXd093Q0xUNUNIa1AzcU9yaFRCM05xamFFOHpw?=
 =?utf-8?B?Qk1hNzJEL3hvdndEVFdHdHBHT21HS3EzK3BydTRMM2FVVFVSdnh0RG5uNVo1?=
 =?utf-8?B?a0Irek9QcU9FeExwMGhCN3FCWjR3a1dOS3BwLzFZOE5WNDBCSS9nTDdoWVlu?=
 =?utf-8?B?WWJJeEdEbUpNakNDWHBPcS9HUnBSMHcwTmI3dnJ0T1JDbDBXbTViNEcvQk5N?=
 =?utf-8?B?WEhIbXZMWW5vRDc4QW8wcGNTOHMwblRnV0dZZXlaZ0NUOEQrSFFxWEpWN01j?=
 =?utf-8?B?L3F0ZVNjdER2ellHT1hPU1ZvL0dnNDVaQkxlWEpnaDVONU93Q0FQVXhQUkZ2?=
 =?utf-8?B?YmF1b2hsNTAvbHNQdW51UldxSy9VOVJkUElEekdQdGlsTWxqOTFPZzc3dk5R?=
 =?utf-8?B?MCtrMEdEcExncTlvcGt0Z2Z2bFJ1YU9LcFJITGlBb2NBSng4SzRHU1VDbEY1?=
 =?utf-8?B?MnRmL284UTZ6cVM5cGxwSXhIK0d3R1ZUZFhqU3lwMUplaHZ6UTR3QTN5L1Fl?=
 =?utf-8?B?bmZ6a1ZPMmVVc0d1cTQwRTdUTnVFRWNFMUtRWmszanhTUS9aSEY0ZXRTZ29w?=
 =?utf-8?B?Wm1VclR3bStDSW1kTUl1ZktYd3d5a2p2eStMclNiRkV0a05YNHpYaE1DZTE4?=
 =?utf-8?B?dS9IVEhha0FBYXZXaUFGSVRXMUxpV3ljalJJQ0lNL09kbFg3bzRYR2pmNWkv?=
 =?utf-8?B?cm1DUmFuVzRGd0t1WVZHaklneHpxb093bW1LVzhWZW5MRlN4Mzk4SFdtaFhR?=
 =?utf-8?B?U1dheHN3NkhqUWRnZ2lmME1HNXRMYjZ2NHdzOXg2UDY4VjhoeGIzUWY3UVR0?=
 =?utf-8?B?MnlOUFA3ZC90Vzh2UUpLRkNKYUYvcXQvMVpOR0Z5OXg1c0F4RHd2R2lKRVh6?=
 =?utf-8?B?ZzhXNFhCSUxBK2JRRm9uYytGUTduSlpLMDFqeS9Jc2RsdkZpOEd6NEtaQ01u?=
 =?utf-8?B?bDFCVWxyeVBqK25pcm42SU5iaUdpVlNtRHFLVTd1bGlSVG8yTEtka2FCekh0?=
 =?utf-8?B?UTRKWDBTTGJ6MndUbDFCRVE4K1dkR1JYQWNvWHRma241Uk04cnloT1dNQ3gx?=
 =?utf-8?B?R1pnY20vR29GWFJRL2RBZG5hZnczVHhxWEpJc21zZ3Y5ejhHU0tudHIxQmhX?=
 =?utf-8?B?VW5SWWpud0lpTUVHaU9WaTBpREY0ZmNQV0tqYlN3eWtXYWNZeDRaMlMwTTNo?=
 =?utf-8?Q?0YdXP46cMaxIYao1ygfxBjtZC?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 67ef4bd2-a933-46e0-c62d-08dda3fc9889
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jun 2025 06:45:44.5733
 (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: wjUo6gXYvz+QO3zvFxZ1fDn3uaVpH30omJvbMeIugyviXAbsyu4uN7SUJoY6nE3v
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB8350



On 04/06/2025 21:51, Stewart Hildebrand wrote:
> On 6/4/25 03:00, Orzel, Michal wrote:
>> On 03/06/2025 23:15, Stewart Hildebrand wrote:
>>> On 5/14/25 03:31, Orzel, Michal wrote:
>>>> On 13/05/2025 21:54, Stewart Hildebrand wrote:
>>>>> Similarly to fba1b0974dd8, when a device is passed through to a
>>>>> direct-map dom0less domU, the xen,reg ranges may overlap with the
>>>>> extended regions. Remove xen,reg from direct-map domU extended regions.
>>>>>
>>>>> Introduce rangeset_count_ranges().
>>>>>
>>>>> Take the opportunity to update the comment ahead of find_memory_holes().
>>>>>
>>>>> Signed-off-by: Stewart Hildebrand 
>>>>> ---
>>>>> v2->v3:
>>>>> * new patch
>>>>> ---
>>>>>  xen/arch/arm/domain_build.c | 57 +++++++++++++++++++++++++++++++++----
>>>>>  xen/common/rangeset.c       | 14 +++++++++
>>>>>  xen/include/xen/rangeset.h  |  2 ++
>>>>>  3 files changed, 68 insertions(+), 5 deletions(-)
>>>>>
>>>>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>>>>> index b189a7cfae9f..3cdf5839bc98 100644
>>>>> --- a/xen/arch/arm/domain_build.c
>>>>> +++ b/xen/arch/arm/domain_build.c
>>>>> @@ -824,15 +824,17 @@ static int __init handle_pci_range(const struct dt_device_node *dev,
>>>>>  }
>>>>>  
>>>>>  /*
>>>>> - * Find the holes in the Host DT which can be exposed to Dom0 as extended
>>>>> - * regions for the special memory mappings. In order to calculate regions
>>>>> - * we exclude every addressable memory region described by "reg" and "ranges"
>>>>> - * properties from the maximum possible addressable physical memory range:
>>>>> + * Find the holes in the Host DT which can be exposed to Dom0 or a direct-map
>>>>> + * domU as extended regions for the special memory mappings. In order to
>>>>> + * calculate regions we exclude every addressable memory region described by
>>>>> + * "reg" and "ranges" properties from the maximum possible addressable physical
>>>>> + * memory range:
>>>>>   * - MMIO
>>>>>   * - Host RAM
>>>>>   * - PCI aperture
>>>>>   * - Static shared memory regions, which are described by special property
>>>>>   *   "xen,shared-mem"
>>>>> + * - xen,reg mappings
>>>>>   */
>>>>>  static int __init find_memory_holes(const struct kernel_info *kinfo,
>>>>>                                      struct membanks *ext_regions)
>>>>> @@ -914,6 +916,13 @@ static int __init find_memory_holes(const struct kernel_info *kinfo,
>>>>>          }
>>>>>      }
>>>>>  
>>>>> +    if ( kinfo->xen_reg_assigned )
>>>>> +    {
>>>>> +        res = rangeset_subtract(mem_holes, kinfo->xen_reg_assigned);
>>>>> +        if ( res )
>>>>> +            goto out;
>>>>> +    }
>>>>> +
>>>>>      start = 0;
>>>>>      end = (1ULL << p2m_ipa_bits) - 1;
>>>>>      res = rangeset_report_ranges(mem_holes, PFN_DOWN(start), PFN_DOWN(end),
>>>>> @@ -994,11 +1003,30 @@ static int __init find_domU_holes(const struct kernel_info *kinfo,
>>>>>      return res;
>>>>>  }
>>>>>  
>>>>> +static int __init rangeset_to_membank(unsigned long s_gfn, unsigned long e_gfn,
>>>>> +                                      void *data)
>>>>> +{
>>>>> +    struct membanks *membank = data;
>>>>> +    paddr_t s = pfn_to_paddr(s_gfn);
>>>>> +    paddr_t e = pfn_to_paddr(e_gfn + 1) - 1;
>>>>> +
>>>>> +    if ( membank->nr_banks >= membank->max_banks )
>>>>> +        return 0;
>>>>> +
>>>>> +    membank->bank[membank->nr_banks].start = s;
>>>>> +    membank->bank[membank->nr_banks].size = e - s + 1;
>>>>> +    membank->nr_banks++;
>>>>> +
>>>>> +    return 0;
>>>>> +}
>>>>> +
>>>>>  static int __init find_host_extended_regions(const struct kernel_info *kinfo,
>>>>>                                               struct membanks *ext_regions)
>>>>>  {
>>>>>      int res;
>>>>>      struct membanks *gnttab = membanks_xzalloc(1, MEMORY);
>>>>> +    struct membanks *xen_reg = membanks_xzalloc(
>>>>> +        max(1, rangeset_count_ranges(kinfo->xen_reg_assigned)), MEMORY);
>>>> You allocate at least 1 membank even though xen_reg_assigned may be empty because:
>>>>  - this function is called for hwdom - no xen,reg
>>>>  - there may be no xen,reg i.e. no passthrough
>>>
>>> Ah, sorry, there's no need to allocate at least 1. This can just be:
>>>
>>>     struct membanks *xen_reg = membanks_xzalloc(
>>>         rangeset_count_ranges(kinfo->arch.xen_reg_assigned), MEMORY);
>> No, it cannot. membanks_xzalloc() calls xzalloc_flex_struct(). If you pass 0
>> as size, the latter will calculate offset to FAM[0]. In other words, the
>> allocation will succeed but only for members up to FAM[0] (i.e. only for struct
>> membanks_hdr).
> 
> If we pass 0 as the size, these members (and their ->common.*
> counterparts) will be allocated:
> xen_reg->nr_banks
> xen_reg->max_banks
> xen_reg->type
> 
> but there will not be allocated any space for the flexible array member:
> xen_reg->bank[]
> 
> Since ->max_banks will be set to 0, and ->nr_banks shouldn't exceed
> ->max_banks, it should work. At least for the (inner) loop in
> find_unallocated_memory(), when ->nr_banks is 0, it won't dereference
> ->bank[]. FWIW, I also tested this with UBSAN enabled.
> 
> I admit it does give me a weird feeling not allocating any space for a
> member in a struct, but it's a C standard flexible array member, and the
> array's size would be 0. We deviated relevant MISRA rule 18.7 in
> b87697fc1a6f ("automation/eclair: fully deviate MISRA C:2012 Rules 5.7
> and 18.7").
> 
> With that said, I'd be happy either way (i.e. either allocating exactly
> what's returned by rangeset_count_ranges() or max(1,
> rangeset_count_ranges()), but I just want to ensure we have the same
> understanding on the technicalities.
Hmm, why do you want to allocate memory in the first place? If xen_reg_assigned
is NULL, we should not allocate anything. Instead you suggest to allocate either
full structure or part of it. That's where I disagree.

> 
>> Also, even if you conditionally allocate for xen_reg_assigned or set NULL, in
>> latter case you will end up with mem_banks containing NULL member. AFAICT that's
>> not something expected by the users of mem_banks (+ it gives unneeded iteration).
> 
> Agreed, it would be a bad idea to set xen_reg = NULL (leading to a NULL
> member in mem_banks), because then find_unallocated_memory() would not
> be happy.

~Michal




From xen-devel-bounces@lists.xenproject.org Thu Jun 05 06:50:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 06:50:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006292.1385487 (Exim 4.92)
	(envelope-from )
	id 1uN4Qa-0004pF-KN; Thu, 05 Jun 2025 06:50:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006292.1385487; Thu, 05 Jun 2025 06:50: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 1uN4Qa-0004p8-Hc; Thu, 05 Jun 2025 06:50:16 +0000
Received: by outflank-mailman (input) for mailman id 1006292;
 Thu, 05 Jun 2025 06:50: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 1uN4QZ-0004oz-N5
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 06:50:15 +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 5568dbd6-41d9-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 08:50:14 +0200 (CEST)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-451e24dfe1aso4568195e9.3
 for ; Wed, 04 Jun 2025 23:50:14 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-747affd41edsm12583028b3a.146.2025.06.04.23.50.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 04 Jun 2025 23:50:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5568dbd6-41d9-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749106214; x=1749711014; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=mZlcEnevP85+N4jveoMj+WxfN38GGi7vHzAT4VJJ5g8=;
        b=CdngmDyv0pPk6OZBu0VpbNyxKceqjSYN45M2jFo2gwRsYRGRMNAXLMeMCtfHbzUi8L
         /LUWsFlog+Y3pOnh7vBFgWbxOdnB7rgEMAfjVELu+6osTiFDk+gTsKCQNpGYv01wSOBO
         Owj0oAtVIjHM+7BdmqrMhiwA2LJJeMkGn4RctNQRpx3TmmyhOz4sdrqAuVH9DrLWqJ7f
         dbir7X859TB8+1d1OMbBBu/awdhcZ6ubqVDYy5/dC2Ym2rB9dMdIuJPjHFYTiZ3h2PjQ
         Wvfxm/C1SLgYs4YuUYcPeervZlWbogbJcCSg7Tn4vNCpwiQFDRmO5tr/jlZQUUQwUtNO
         GFmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749106214; x=1749711014;
        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=mZlcEnevP85+N4jveoMj+WxfN38GGi7vHzAT4VJJ5g8=;
        b=DLi+cSKh1fieBG5yQPtv89CFcPqtFtW7VwjYQz+XvcCVqRGbCDyof5lJH3vuZGplF7
         qNWc97FShT3zfsYBVsmHwaxY9Rrh6JGjZDlFAF1wqljPV7XYZgMRAEcEDGXE9Aqzt8YV
         D90x4pEDeO9rWq7m3Y2H2/N/ib/grwc05Vw4KoxHQNeCcHVBZQAOhyzFLM2/hR332Hmf
         StUGXKQeHbTAHQA/vFNH5RPUtkfw2xCgyHE199vvnBaFbHwc2XysVOY5ENyXXxivhlRH
         rQO53wshNK4YnUWSe2BwUXztAbyq3ymcAG6IBwzkntivLSpVriaG1/7ORjjg+Tdxd9tE
         02Wg==
X-Forwarded-Encrypted: i=1; AJvYcCUJeLyZBY8J/Gi8j8qL3Imf3lg4SxOoOGz0C2QtNibMqdBQj3lUi80TpYFpWUL2pfFdSL8qITiNjpw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyoIqZK9jaT5+/MHjUtgtbFkYsXMC2tuyJIxijsEBNzLpmkaa6w
	kjtv1fxLSXJzTXUgpvgpZAPJ2nBvqwNpjf53fN/SPltowzCRg9Yw6U6xabaaQ3VzRQ==
X-Gm-Gg: ASbGncukAjb1ol8KhiZ+ceT8YfDXq/pCZhZh6jrxnGJqEsQC9Vmg/BypT7PqcGXknRO
	r8tI5IYo48xL5UDwSqyGW5CVQqJJ92hYdv+gVip/UF+zVVmG0zG/Pf/gJ0ICsjifo7ZJKv6lLhj
	ujbpNe979OKqsq9vctYOkERpNSvDbdDUwo1S03QJR+VWPVetpwxY7fneOL9e+wfhGOK6ZKOnh8a
	6btmGF+2vTWH7zIUa2R/hkZ6hUsk7NKCBSYK20mzEhMBMf75IKK9xhecboSqzcW7tHLYNj7b4zL
	ZEzQ9KD9PWhiuooImnkNStVeZ3p0yHh0VA989x2omWh2EiiN93Y178mE+BpV9vYsuiKQ+uZGCd+
	rCeTx6Xl5VNRFlqcgqpX+HTwNl+DPHOAth8ZO
X-Google-Smtp-Source: AGHT+IGk7krn6O+QUL452+xgEbntSP7jZQonfSyg67U5irJluwlk5hor3sskPweURQGJf8fQQHMyag==
X-Received: by 2002:a05:6000:288f:b0:3a4:d9fa:f1ed with SMTP id ffacd0b85a97d-3a51dbcc79fmr4730499f8f.13.1749106213999;
        Wed, 04 Jun 2025 23:50:13 -0700 (PDT)
Message-ID: 
Date: Thu, 5 Jun 2025 08:50:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 08/14] xen/riscv: imsic_init() implementation
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 ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <421dad1bbd014a2d7ff588af088eadbd56345dbe.1747843009.git.oleksii.kurochko@gmail.com>
 
 
 <8cd6c3e0-0361-4f3f-b3ca-8ffa49b9197d@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 04.06.2025 17:36, Oleksii Kurochko wrote:
> On 6/2/25 12:21 PM, Jan Beulich wrote:
>> On 26.05.2025 20:44, Oleksii Kurochko wrote:
>>> On 5/22/25 4:46 PM, Jan Beulich wrote:
>>>> On 21.05.2025 18:03, Oleksii Kurochko wrote:
>>>>> +    /* Check MMIO register sets */
>>>>> +    for ( unsigned int i = 0; i < nr_mmios; i++ )
>>>>> +    {
>>>>> +        if ( !alloc_cpumask_var(&imsic_cfg.mmios[i].cpus) )
>>>>> +        {
>>>>> +            rc = -ENOMEM;
>>>>> +            goto imsic_init_err;
>>>>> +        }
>>>>> +
>>>>> +        rc = dt_device_get_address(node, i, &imsic_cfg.mmios[i].base_addr,
>>>>> +                                   &imsic_cfg.mmios[i].size);
>>>>> +        if ( rc )
>>>>> +        {
>>>>> +            printk(XENLOG_ERR "%s: unable to parse MMIO regset %u\n",
>>>>> +                   node->name, i);
>>>>> +            goto imsic_init_err;
>>>>> +        }
>>>>> +
>>>>> +        base_addr = imsic_cfg.mmios[i].base_addr;
>>>>> +        base_addr &= ~(BIT(imsic_cfg.guest_index_bits +
>>>>> +                           imsic_cfg.hart_index_bits +
>>>>> +                           IMSIC_MMIO_PAGE_SHIFT, UL) - 1);
>>>>> +        base_addr &= ~((BIT(imsic_cfg.group_index_bits, UL) - 1) <<
>>>>> +                       imsic_cfg.group_index_shift);
>>>>> +        if ( base_addr != imsic_cfg.base_addr )
>>>>> +        {
>>>>> +            rc = -EINVAL;
>>>>> +            printk(XENLOG_ERR "%s: address mismatch for regset %u\n",
>>>>> +                   node->name, i);
>>>>> +            goto imsic_init_err;
>>>>> +        }
>>>> Maybe just for my own understanding: There's no similar check for the
>>>> sizes to match / be consistent wanted / needed?
>>> If you are speaking about imsic_cfg.mmios[i].size then it depends fully on h/w will
>>> provide, IMO.
>>> So I don't what is possible range for imsic_cfg.mmios[i].size.
>> Well, all I can say is that's it feels odd that you sanity check base_addr
>> but permit effectively any size.
> 
> Okay, I think I have two ideas how to check the size:
> 1. Based on guest bits from IMSIC's DT node. QEMU calculates a size as:
>      for (socket = 0; socket < socket_count; socket++) {
>          imsic_addr = base_addr + socket * VIRT_IMSIC_GROUP_MAX_SIZE;
>          imsic_size = IMSIC_HART_SIZE(imsic_guest_bits) *
>                       s->soc[socket].num_harts;
>      ...
>     where:
>       #define IMSIC_MMIO_PAGE_SHIFT          12
>       #define IMSIC_MMIO_PAGE_SZ             (1UL << IMSIC_MMIO_PAGE_SHIFT)
>       
>       #define IMSIC_HART_NUM_GUESTS(__guest_bits)           \
>               (1U << (__guest_bits))
>       #define IMSIC_HART_SIZE(__guest_bits)                 \
>               (IMSIC_HART_NUM_GUESTS(__guest_bits) * IMSIC_MMIO_PAGE_SZ)
> 
> 2. Just take a theoretical maximum for S-mode IMSIC's node:
>      16,384 * 64 1(S-mode interrupt file) + 63(max guest interrupt files)) * 4 KiB
>     Where,
>       16,384 - maximum possible amount of harts according to AIA spec
>       64 - a maximum amount of possible interrupt file for S-mode IMSIC node:
>            1 - S interupt file + 63 guest interrupt files.
>       4 Kib - a maximum size of one interrupt file.
> 
> Which option is preferred?

I would have said 2, if your outline used "actual" rather than "maximum" values.

> The specification doesn’t seem to mention (or I couldn’t find) that all platforms
> must calculate the MMIO size in the same way QEMU does. Therefore, it’s probably
> better to use the approach described in option 2.
> 
> On the other hand, I don't think a platform should be considered correct if it
> provides slightly more than needed but still less than the theoretical maximum.
> 
>>
>>>>> @@ -18,6 +19,18 @@ static inline unsigned long cpuid_to_hartid(unsigned long cpuid)
>>>>>        return pcpu_info[cpuid].hart_id;
>>>>>    }
>>>>>    
>>>>> +static inline unsigned long hartid_to_cpuid(unsigned long hartid)
>>>>> +{
>>>>> +    for ( unsigned int cpuid = 0; cpuid < ARRAY_SIZE(pcpu_info); cpuid++ )
>>>>> +    {
>>>>> +        if ( hartid == cpuid_to_hartid(cpuid) )
>>>>> +            return cpuid;
>>>>> +    }
>>>>> +
>>>>> +    /* hartid isn't valid for some reason */
>>>>> +    return NR_CPUS;
>>>>> +}
>>>> Considering the values being returned, why's the function's return type
>>>> "unsigned long"?
>>> mhartid register has MXLEN length, so theoretically we could have from 0 to MXLEN-1
>>> Harts and so we could have the same amount of Xen's CPUIDs. and MXLEN is 32 for RV32
>>> and MXLEN is 64 for RV64.
>> Yet the return value here is always constrained by NR_CPUS, isn't it?
> 
> I am not 100% sure that I get your point,

NR_CPUS is guaranteed to fit in a unsigned int. Furthermore variables / parameters
holding Xen-internal CPU numbers also are unsigned int everywhere else.

> but I put NR_CPUS here because of:
>    /*
>     * tp points to one of these per cpu.
>     *
>     * hart_id would be valid (no matter which value) if its
>     * processor_id field is valid (less than NR_CPUS).
>     */
>    struct pcpu_info pcpu_info[NR_CPUS] = { [0 ... NR_CPUS - 1] = {
>        .processor_id = NR_CPUS,
>    }};
> 
> As an option we could use ULONG_MAX. Would it be better?

No. NR_CPUS is the appropriate value to use here, imo.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 06:52:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 06:52:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006303.1385498 (Exim 4.92)
	(envelope-from )
	id 1uN4Sa-0005kQ-5D; Thu, 05 Jun 2025 06:52:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006303.1385498; Thu, 05 Jun 2025 06:52: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 1uN4Sa-0005kJ-19; Thu, 05 Jun 2025 06:52:20 +0000
Received: by outflank-mailman (input) for mailman id 1006303;
 Thu, 05 Jun 2025 06:52: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 1uN4SY-0005k7-IS
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 06:52:18 +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 9eb0b5f2-41d9-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 08:52:17 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a3673e12c4so336004f8f.2
 for ; Wed, 04 Jun 2025 23:52:17 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-747afff7e3bsm12542036b3a.175.2025.06.04.23.52.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 04 Jun 2025 23:52:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9eb0b5f2-41d9-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749106337; x=1749711137; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=gPaSM6tyqkg4/i4DkBb0q2jQhcQsWsXzAM1RSQKJND8=;
        b=NYKKOmBdpOAA5qlIEkgdDg5RnTn7/vQCJTe5bakQ98OY4Zz0F1lgI4UqJdHRCyMPmD
         mq1imcvJB+/phRf+CrtmQZgNaQ48e/I1sx8xsq4sR9vSxJFGJzun0gm5i9pXQMHymfyK
         0RzuUDRdiNbjwd2bTyxj8G1qQV7y2kG5JB/7Cyc58+bWn0+srhHqXMmZpxulq6WyG18N
         we6VYirkL1XIQFhlhwTES+to6NJN8eQcFQWcnfRxdSURK/OudIoYIuSC/3Vqi8+W46KM
         BA7N9A1HLllGsI8WPwfZ+WbyDqcYYRLb/7SZ88WoiIRT4IPfY93A+VlM3SCArXJJ5ctA
         cHsw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749106337; x=1749711137;
        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=gPaSM6tyqkg4/i4DkBb0q2jQhcQsWsXzAM1RSQKJND8=;
        b=CRazJa4v0v3RqRbgRODHDfPS5/yFg4K8qFeXCFQAL+9IGQHtfKduBes13OoThqjp7J
         Z6X9m6T3WeeWxEEKjNp2FQNHHoQMUh1REpwEqGUgDLXdGg4r7QZy5iqsBZW5tdFoNjBS
         4PgUkL+OY6ehAUqT5n1ZXDVAqo+L9HTuDPttgWLATf4zf4jnba4II5JCbVGEx104AaBK
         AVXbXrzTlBM3GzbB2czVC8GbrhLeoUQ1UxYqURDVKeWxHHgvaZNQrDOoShvka662hJGm
         SogAOAN3eUMJoOTy/FKCWrhpEHuDzRYMZxD9ooCNyAlgl+vrqzH4zNVTa91zw/sNGplo
         YBRQ==
X-Forwarded-Encrypted: i=1; AJvYcCX+suGRnqgTK6tVr74mkjeqkBPfHH/QLoQI55SxNmxrbsfvYq9iDAvKk79mjb2E49vJqCxa+OMPLEc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzjTB4xFBVGI7Ob6gPLt1H2f7njjc/gQ9Lv8MXzAeMJpTIoV0/z
	5xUXamQmF1CNXR0FrGKV2tmSUqF0xeYYgo9Z/hnOocOpLtowudq9Sfoe3uFuc201kA==
X-Gm-Gg: ASbGnctN7Ld+2ytuu6haPO4f+vVnh8nhZzhFrmmx5NrExFQdcLAtnLQT4d1T+sdQ1ir
	ijwsN2l0NBAt0UiWn6kGbjkMETQOqDNVozK+6RYGnk8D7SDd7DM80oBqEDm1vmfAfpL3RaguG4l
	km4U48AFJ066NveIeZ1aQeWB/nX2FCO5/jfBbKr4JAtEQsbp4Jh9awafzv/4xsnuq5eWmT5rg+a
	HLP+N6ZaN6DdqJx9G25snC5Cx1c7i+waQBTeh4YTTG0pqLPpW3c8p93F50tzk3LrfzzdVW8uQLF
	jKbLbDBPExENvRJ9+tJZiiaaAfMclycoaE+W0dH8gg9yV4m8+/E5426PsZ3OVIVHPzb3+hb2PS2
	Zq6SxMeTAEc+PpWddyO1Pf5WDsUm1RVrbHcST
X-Google-Smtp-Source: AGHT+IGN5A5YUUeiJjdZVFaaIdt1SS0nIhg8EonmQGtPkUca8kcDxFQ5BY7JWvLfrq9/4L6xgBTXHw==
X-Received: by 2002:a5d:64cd:0:b0:3a5:2dae:9718 with SMTP id ffacd0b85a97d-3a52dae9eadmr80749f8f.41.1749106336966;
        Wed, 04 Jun 2025 23:52:16 -0700 (PDT)
Message-ID: <7c487a6e-474b-417e-a120-2d097eb3d178@suse.com>
Date: Thu, 5 Jun 2025 08:52:05 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 08/14] xen/riscv: imsic_init() implementation
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 ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <421dad1bbd014a2d7ff588af088eadbd56345dbe.1747843009.git.oleksii.kurochko@gmail.com>
 
 
 <84c9f65a-b278-4be4-b053-5bfa410f9a97@gmail.com>
 <9ab65452-497c-47b5-af18-92a7b2a86d9e@suse.com>
 
 <85d6f812-784a-4959-a1e6-589ebac8887c@suse.com>
 <63d8882d-bd54-4cbd-8c48-24b296ce4a50@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: <63d8882d-bd54-4cbd-8c48-24b296ce4a50@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.06.2025 17:41, Oleksii Kurochko wrote:
> 
> On 6/4/25 5:05 PM, Jan Beulich wrote:
>> On 04.06.2025 15:42, Oleksii Kurochko wrote:
>>> On 6/2/25 12:22 PM, Jan Beulich wrote:
>>>> On 27.05.2025 13:30, Oleksii Kurochko wrote:
>>>>> On 5/26/25 8:44 PM, Oleksii Kurochko wrote:
>>>>>>>> +    if ( !dt_property_read_u32(node, "riscv,guest-index-bits",
>>>>>>>> +                               &imsic_cfg.guest_index_bits) )
>>>>>>>> +        imsic_cfg.guest_index_bits = 0;
>>>>>>>> +    tmp = BITS_PER_LONG - IMSIC_MMIO_PAGE_SHIFT;
>>>>>>>> +    if ( tmp < imsic_cfg.guest_index_bits )
>>>>>>>> +    {
>>>>>>>> +        printk(XENLOG_ERR "%s: guest index bits too big\n",
>>>>>>>> +               dt_node_name(node));
>>>>>>>> +        rc = -ENOENT;
>>>>>>>> +        goto cleanup;
>>>>>>>> +    }
>>>>>>>> +
>>>>>>>> +    /* Find number of HART index bits */
>>>>>>>> +    if ( !dt_property_read_u32(node, "riscv,hart-index-bits",
>>>>>>>> +                               &imsic_cfg.hart_index_bits) )
>>>>>>>> +    {
>>>>>>>> +        /* Assume default value */
>>>>>>>> +        imsic_cfg.hart_index_bits = fls(*nr_parent_irqs);
>>>>>>>> +        if ( BIT(imsic_cfg.hart_index_bits, UL) < *nr_parent_irqs )
>>>>>>>> +            imsic_cfg.hart_index_bits++;
>>>>>>> Since fls() returns a 1-based bit number, isn't it rather that in the
>>>>>>> exact-power-of-2 case you'd need to subtract 1?
>>>>>> Agree, in this case, -1 should be taken into account.
>>>>> Hmm, it seems like in case of fls() returns a 1-based bit number there
>>>>> is not need for the check:
>>>>>     (2) if ( BIT(imsic_cfg.hart_index_bits, UL) < *nr_parent_irqs )
>>>>>
>>>>> We could do imsic_cfg.hart_index_bits = fls(*nr_parent_irqs - 1) (1) without
>>>>> checking *nr_parent_irqs is power-of-two or not, and then just leave the
>>>>> check (2).
>>>>> And with (1), the check (2) is only needed for the case *nr_parent_irqs=1, if
>>>>> I amn't mistaken something. And if I'm not mistaken, then probably it make
>>>>> sense to change (2) to if ( *nr_parent_irqs == 1 ) + some comment why this
>>>>> case is so special.
>>>>>
>>>>> Does it make sense?
>>>> Can't easily tell; I'd like to see the resulting code instead of the textual
>>>> description.
>>> Here is the code:
>>>       /* Find number of HART index bits */
>>>       if ( !dt_property_read_u32(node, "riscv,hart-index-bits",
>>>                                  &imsic_cfg.hart_index_bits) )
>>>       {
>>>           /* Assume default value */
>>>           imsic_cfg.hart_index_bits = fls(*nr_parent_irqs - 1) +
>>>                                       (*nr_parent_irqs == 1);
>>>       }
>>>
>>> It seems like it covers all the cases.
>> *nr_parent_irqs		imsic_cfg.hart_index_bits
>> 	 1			1 (0 + 1)
>> 	 2			1
>> 	 3			2
>> 	 4			2
>> 	 5			3
>> 	 6			3
>>
>> IOW why the special casing of *nr_parent_irqs == 1?
> 
> If we don't have "... + (*nr_parent_irqs == 1)" then for the case when *nr_parent_irqs == 1,
> we will have imsic_cfg.hart_index_bits = fls(1-1) = fls(0) = 0 because:
>    #define arch_fls(x)     ((x) ? BITS_PER_INT - __builtin_clz(x) : 0)
> and imsic_cfg.hart_index_bits = 0 doesn't seem correct because I expect that if I have only
> 1 hart then at least 1 bit will be needed to point to it.

No, why? To pick 1 out of 1 you need no bits at all to represent.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 07:07:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 07:07:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006318.1385508 (Exim 4.92)
	(envelope-from )
	id 1uN4gr-0007pE-FV; Thu, 05 Jun 2025 07:07:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006318.1385508; Thu, 05 Jun 2025 07: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 1uN4gr-0007p7-Am; Thu, 05 Jun 2025 07:07:05 +0000
Received: by outflank-mailman (input) for mailman id 1006318;
 Thu, 05 Jun 2025 07:07: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 1uN4gq-0007p1-MM
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 07:07:04 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20627.outbound.protection.outlook.com
 [2a01:111:f403:2413::627])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a92c5011-41db-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 09:06:55 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by DS0PR12MB7725.namprd12.prod.outlook.com (2603:10b6:8:136::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.32; Thu, 5 Jun
 2025 07:06:51 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8792.034; Thu, 5 Jun 2025
 07:06: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: a92c5011-41db-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=cOJBAn7/H15Pa8rQ7Xs16Uytuv8wwPvO3Xv4N2FW59iJpvq46cXsncQ9V4FOjb7PSlIPVEpwuRfKnh2R8hJurTj9hbfSkq/dGhO4TauxpUERN5gBne3A2jv532b5UIJZbzH24MetksgPswEtt09GVMS+UQG9WxklJ9Zz6BWTapHLJuoLBKhXMPINj2bf6F4bFrKsDdH6XhZERJzuouADkHxuibsV8jRb/tXQlpGyEQ/b4+k01XmdFRis53WlKVKAmqYDZ1N/lO4zr0jRasAoogD2owUIlzGexi/AIhPDGNEcU7jcBe6LgUZMvt4viNMYmKQbIjYUTXWUHe8f2APJOA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=sarXzygds8mxl0ouTU6R4fDfRq9JNcq2nePTgyCoXNI=;
 b=QyqeGAyFvCQ6AGTj+uguf8pULIR/iwJPn/DXeZrP/A67wwpbBHovpvxZOOg8GRrj9aiSDe4G+iY9WyDwS8OpFKKr5g8T1IAvfSGfFB2i1c9gkEaLY3zlyqSBLhZXdFgQ5FW/o9UWe/tKrG1wjJjTN8s57XPuVAZ4PAYkwvnviIT2v4WUGOKQDUqLDXWrhlhfjCiEVCLib3ZmD6Fhd7YkkwT9e0Rc453PnH/ZuknyWTGwuhzGAsqlyHiPT//o3ZjfSFUms5f90DqIu/1InHLqxBeGV6Swz0/H7uiXWb9YLL4sO9LgEdVTIzjv+FVq56ZhQwaMTKkdWjKdHq1FEw/0Lg==
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=sarXzygds8mxl0ouTU6R4fDfRq9JNcq2nePTgyCoXNI=;
 b=c56A99YN7mF8KLgYx/KMAQeV+kB7k6CT2qmPzYp+GU2fj9+kO5zni84UM1z7cqhcZDV+nemj0v39QVq1DL8Ni/db4tfCKuiZQ2DxnClnNwzfNcgHidk/kO3sYaIU8i20qBCCT1n7qg3FFaYVgODffu7LEmrnLFw8mIyQsrKVaBo=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Thu, 5 Jun 2025 09:06:47 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/3] arm/mpu: Introduce MPU memory region map structure
To: Ayan Kumar Halder ,
 xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250604174311.754899-1-ayan.kumar.halder@amd.com>
 <20250604174311.754899-2-ayan.kumar.halder@amd.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250604174311.754899-2-ayan.kumar.halder@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR5P281CA0010.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:f2::11) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|DS0PR12MB7725:EE_
X-MS-Office365-Filtering-Correlation-Id: d1ebf4f7-8508-4044-d9e3-08dda3ff8bcd
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?aEdGQm1aOXc0engvQ1RyRDZTMWZUWlJLQzRvOUtLT3dNaW5IQU1WUDVOaFNz?=
 =?utf-8?B?end3b2dJLzNPOWYyZkhJeW9WS3VZUTZkdUJuZDB1dEpGcEtxeGNNWFIyMk4y?=
 =?utf-8?B?bGFVL0RUcittZUpEUVJjSVZiWlJSSlFWdkNJb1JLS2swdVBETmQ2ZzVUWXdy?=
 =?utf-8?B?RzdFY0pCUktacXpaY0s2RzhTZThuZlRZWVhBS2diYUswYjM3dVk1STlLaDRw?=
 =?utf-8?B?K3JzWXRGaUJpTmlyQ1Vqa3NScHhRUTZPOENuSDNjdXo2TThBM29xQ1VPSGFL?=
 =?utf-8?B?OGxvMGM4NGlhb0l3ZU9WcU5mQnhaQnpzTXlJK2t3eER1d0t6YlJYdGVkREZI?=
 =?utf-8?B?T2RkczJDY01tUm1WQlRsTkY3RTU4c0RPdXdFK0Y2K2cxWStjVnFJOWhoYjZ0?=
 =?utf-8?B?U2F5ZGZWdDViMlMxT1lhamRNVVJhb1JnSkhhUkgwK1poUnJYNjdPaGJic3Fu?=
 =?utf-8?B?V2ZjaENSdjc0R0lMbS9GR0syMnQydzRoNFFPSHg1VUVXNlZ0NU1EYmt2Mzlq?=
 =?utf-8?B?eVlhNnBnVGhxeTNpMDRuMldKVzZhSUlqdDAwbDhMeGNreHZBZUtFdHN0dnlD?=
 =?utf-8?B?RkJnQ3liR3ZTWWNjVGVZQjlJTFJVOFg3aGtwYmEwcnhXQjFYc1IzY0NsRkMr?=
 =?utf-8?B?anRtZDZ1bVFnOW1KYlpyN1VCYjRhUTBTNGZOR2FCeEFOYU1BUEs0ald1N1JN?=
 =?utf-8?B?bmNpdExodVBZNDRoWmpPeTFMWXZoWjZBb3N5cUVvU0UxVFBvdTRGaFJLT0h3?=
 =?utf-8?B?aGN5dkdzNWFRalczbXA5UmJsM1I1NllxMkdRTnp0MTJOc3YvRUhjNU02VWhU?=
 =?utf-8?B?UEJPM0l1RDFRa0tiS0c2b0grdExkMUR3RE0xdVoyWTNsOGJTRUN1dWcyWDJW?=
 =?utf-8?B?QjJKMXVjLzFqbExZTVJtVWQ3MDhNdHJuSDBET0lTSFJpOTZFYWpRNlJIUjZ1?=
 =?utf-8?B?OThYSlBacmVCcmdtSGVsWFJwaEYzaEhrbTg4WGZwSUtCZXpIZTJqdkltQmEy?=
 =?utf-8?B?MFV4SFZSWkQxZDhXeExrUThoYmdER1pMWFFmTzNmOVR4MXFRSHVZbEhHQ2NY?=
 =?utf-8?B?YTQ0ZWFYS242NHJVNEtEdWhWTHJoTFRMQlNibTR4YU80UHBFMlpqMk5MNlBy?=
 =?utf-8?B?UVlnZTl4M0VLWkQvRlNWVUIrb0dLcTU4aG91aTQvZFo3eE9qdVBwWk1RcDVy?=
 =?utf-8?B?bFk1WSs1dEU5SE9wMGViYmdSV2RmNTI0d3hYeVRHdWFGRk5TeitlLzJGMnQy?=
 =?utf-8?B?UnJHTi8zOUppVnI2Nmsrbm1NenNmSHU0VitORUFua1UzTWxuSnB3UUxkNDNB?=
 =?utf-8?B?Rmxldi9yMTlRWWRJL1h5cVQ2NVVuVFRZZldqcjdxS1AycElxR21GY2xNamIx?=
 =?utf-8?B?SEx2NTRKdnNLTXg0VWlyOEhCMTdXNmNTbEgrY01uc0lpNXZNMGl6V2sxZ013?=
 =?utf-8?B?RXpsUXhJY0xUN3hFV01WMXhVc0h6Q3N1K2F3TE9wNitId2t6YlhSWG5xV2Vw?=
 =?utf-8?B?QTRKbVFVWjlyNTJJT3Q3VEU0a0c2ZzFnZDFwaVdKYnh2NVNJdGNRSU5pamlj?=
 =?utf-8?B?eGZnazFZczZteDE4SWZyU0kwTEMxYzNyUXVWWjFsblJ1QVFabkhpb0hNOGRa?=
 =?utf-8?B?YXlnTXIxMWxrVVk0MjE2ZHd4Y21BVytabVVpa2F6bGEvTDdrMmVOdVpYUWZt?=
 =?utf-8?B?MXpiZW1iSk5xd0R1WmYwcjNHTXA2SVBlTjIwb2RZTnVRYzhob2pNZmJQczRo?=
 =?utf-8?B?RWZmT1F1aXpiVzVGekN6TnBHZEMwdnRCZllKeUFNMG1nMzB4dm5xK3VVeDRO?=
 =?utf-8?B?UHZUNWlKa0RlTUM4UFpQZGE3UTk4bWNyUktYZGd3bTBPTEpnaTVxbjR1UUJS?=
 =?utf-8?B?Z2w4QmRIMmo2UThpeDhKVnNvdEtUT2ExeWpXVWxJdG1UWVJqajU4QzNjMStI?=
 =?utf-8?Q?0YpvyinA8/c=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.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?SG9aemJiSnRKbFNWUjNleHVJZkZOZGUzY2JRdmVleWlpcmdKTFNyQXRjL2lu?=
 =?utf-8?B?VHpvbVI2YUdHeVB1RDhaMmVRa2xQeXJyOStMdEcrN2x2RkpSQ3pEY0J0RWZL?=
 =?utf-8?B?cTdUZmZ2ZGFTU1d1YXkvUCtONEd6R0RNVnlzUGRjV3Y0UVNNUDIxaWRqN2wx?=
 =?utf-8?B?Kzc0bXgvbE9QTnhRVzFhNjRsN2NnUnBZL3JrQUdWZlBDRWd2RGltbGZSdXFn?=
 =?utf-8?B?aHN4NWQzZTVzQWVibG40QXhWcHJZbXRTNk13TWUxMFZNTGZHZTlMaXpWSFR1?=
 =?utf-8?B?Nm5XcmM2alh5MGJYa2Q5TTJHbWFHYmE1YjhJeXI5c09YME5IZW1WM0RSdVQ5?=
 =?utf-8?B?S01jNnR6eWF0Yk9LYTloWFZXM21qTlI4d29UajJaRWg0Q3dxZDRrcFRkVDNi?=
 =?utf-8?B?R3VuUW5udGJkNmxrcWFzbTB1ZXJ4K211L2JmMEkybWtIazhWQzZETkRQcjQ3?=
 =?utf-8?B?QzAyTXJzY3k2aVVrbU9LbXBwaXpoZ0pGNUNBSDE4VUsySTFOZmFKaEVZenBD?=
 =?utf-8?B?MzEzN0ZUVm9rcTNpREI4ZmJyOXluN2RWWjZDbTVWZ0xyV2lOdmxMUFMzMi85?=
 =?utf-8?B?K3ZaUTVMSjNwYmFiRHpObFhVTkhUaDNNaW1pS1dzbGc0NldTSHRnYzBlTVAw?=
 =?utf-8?B?ajJZcHVoa2xEZDFiOWV5U1U4L0p6U1JaM21kbVlES0NDRDVsVy9BLzZ5VnY4?=
 =?utf-8?B?NStaUzRraVM0dDgzTnh1dkxRcStTUE9nbWwxa1NEQitTaEZhMEZtcTVvY2Fw?=
 =?utf-8?B?aE1meUpvaVZidlpRS2FSbmVzcGpORzg1STBySHd0UUdtbDdJbnZrS1FsZFNz?=
 =?utf-8?B?SkF6TmJ1b3FDUW42YnRIa0tucWJhckU0TTRyYll0QUpCL3BPVkNvUCswcjdv?=
 =?utf-8?B?Vm5JaUdQdG9sKzAvK2lSZEJjbGlZMFlza0hDVVVVbm5WRTh1blRQSjV3Qjh4?=
 =?utf-8?B?K2FNOWxpM3cwUGJtY0ZFUG8wQ0ZPMTdnRTB2S0VVNFRraGNhNEtwRTBIeUZ4?=
 =?utf-8?B?Zmk4Y1JianFWZ1Z2QTBOcFdEK0VTZnJmVldiL09ZY3h5NUpHY0hnMEZwN0Mw?=
 =?utf-8?B?OUNla05KcnRWSGhuMll0UVpaaFlmZGsrclBOcXBGUFYvSGdtczhtZFZENCtv?=
 =?utf-8?B?Q2s2S0MvRmRNNmhuNWh0REFHRmhZY0N2MkNhb3RPR0FwZGNLVEI4bzR4ZzZR?=
 =?utf-8?B?d3RtVE41TWZPS2hqcWpRbkJlL1EyNEM2bk1LNlNXZjBYNmlTbmJ6VmN0YndN?=
 =?utf-8?B?dytCVFZMeGNkLy93L2d2RnlwSUo5MzNRUEZPWUI4N2tiN29pTU5qb1dVbXh6?=
 =?utf-8?B?MG11UzB2SjQzZnY2SUFQc3p6V25hRFBaZWJXZkUwRmxKMGY5UEQ5TUEvT1pG?=
 =?utf-8?B?bkU2MitGcWJ2NU1HL2FyajVNamd0U0lBMkFmTi84dW1JdmhWbWxid3NGRUsv?=
 =?utf-8?B?NUFBVE9xcW9NYTFpTHEzVDU2cDBPTjk1K0UxR3R5SjFxRy93dTJjK1c3cG9u?=
 =?utf-8?B?ZUFHZllVdUplNy85UW5pNVJNRG9Wcnlmd0VhdlNlWFB6dHFNUWk5QjBzU0lS?=
 =?utf-8?B?SHVNT3pJNGFTV2ZPUGNMUkpKbkUwRXp3NllXMUtQZGVZMkp4YjNGVFRUclZW?=
 =?utf-8?B?ODB1aTFwVEF0TC8zWC95Yk5XWHNEYzE0MWdmRGVzV05ibUwyWExTbU1pM3hW?=
 =?utf-8?B?Ry8zcHZmZ2NGemREVTltLzVzMW5jWlpCcWZWVFRLa1BFKzV4UkV2ZGpXWDJj?=
 =?utf-8?B?aW9SUHcxQUprdUJYdW9VVk94WEdFcHAzV3ZpZkpLZkhEdVl0UHN1OGJWdGMy?=
 =?utf-8?B?L1ZSRWcyN0xJTzMzN3dlL2NvYnlEZHZKa2VRamRYaEh2QkRRQWZIbE8zOGZt?=
 =?utf-8?B?Qk5rM2ZKcnBoN3VpKzN4YW1VSno2bGVYRnF1YjRjMkZwcnR0WTk3R0s2MUYz?=
 =?utf-8?B?RWVaWGVBSzRxWjFiWW1LY2dmY0lLbU1rcGZKUEl5SUQrem42VCtudlYvSjZB?=
 =?utf-8?B?NEgxVUtrUnUramcwdlh1Vmp3dkdmSTFSdXAwWVppWDU4NmlmMFJDc0JpbW1p?=
 =?utf-8?B?YllTclJQRzllQzdrWENlLzM2VllVTGJLZTFTM21qU0NtQnpwSUhtelNTZzE4?=
 =?utf-8?Q?t9G0=3D?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d1ebf4f7-8508-4044-d9e3-08dda3ff8bcd
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jun 2025 07:06:51.5814
 (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: ZyagwOyAFiV/xPOPLxq5xdq7TK8qfXOg8eIkRnoy2W4TnJ0q6JejD6XB9JioQCIm
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB7725



On 04/06/2025 19:43, Ayan Kumar Halder wrote:
> Introduce pr_t typedef which is a structure having the prbar and prlar members,
> each being structured as the registers of the AArch32 Armv8-R architecture.
> 
> Also, define MPU_REGION_RES0 to 0 as there are no reserved 0 bits beyond the
> BASE or LIMIT bitfields in prbar or prlar respectively.
> 
> Move pr_t definition to common code.
> Also, enclose xn_0 within ARM64 as it is not present for ARM32.
> 
> Signed-off-by: Ayan Kumar Halder 
> ---
>  xen/arch/arm/include/asm/arm32/mpu.h | 30 +++++++++++++++++++++++-----
>  xen/arch/arm/include/asm/arm64/mpu.h |  6 ------
>  xen/arch/arm/include/asm/mpu.h       |  6 ++++++
>  xen/arch/arm/mpu/mm.c                |  2 ++
>  4 files changed, 33 insertions(+), 11 deletions(-)
> 
> diff --git a/xen/arch/arm/include/asm/arm32/mpu.h b/xen/arch/arm/include/asm/arm32/mpu.h
> index f0d4d4055c..ae3b661fde 100644
> --- a/xen/arch/arm/include/asm/arm32/mpu.h
> +++ b/xen/arch/arm/include/asm/arm32/mpu.h
> @@ -5,11 +5,31 @@
>  
>  #ifndef __ASSEMBLY__
>  
> -/* MPU Protection Region */
> -typedef struct {
> -    uint32_t prbar;
> -    uint32_t prlar;
> -} pr_t;
> +#define MPU_REGION_RES0       0x0
The name of the macro does not make a lot of sense in AArch32 context
and can create a confusion for the reader.

> +
> +/* Hypervisor Protection Region Base Address Register */
> +typedef union {
> +    struct {
> +        unsigned int xn:1;       /* Execute-Never */
> +        unsigned int ap_0:1;     /* Acess Permission */
If you write AP[1] below, I would expect here AP[0]
Also s/acess/access/

> +        unsigned long ro:1;      /* Access Permission AP[1] */
> +        unsigned int sh:2;       /* Sharebility */
> +        unsigned int res0:1;     /* Reserved as 0 */
Here your comment for RES0 (which IMO could be just RES0) does not match...

> +        unsigned int base:26;    /* Base Address */
> +    } reg;
> +    uint32_t bits;
> +} prbar_t;
> +
> +/* Hypervisor Protection Region Limit Address Register */
> +typedef union {
> +    struct {
> +        unsigned int en:1;     /* Region enable */
> +        unsigned int ai:3;     /* Memory Attribute Index */
> +        unsigned int res0:2;   /* Reserved 0 by hardware */
this one. I don't think you need to explain what RES0 means.

~Michal



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 07:18:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 07:18:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006328.1385517 (Exim 4.92)
	(envelope-from )
	id 1uN4ra-0001Gf-B2; Thu, 05 Jun 2025 07:18:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006328.1385517; Thu, 05 Jun 2025 07:18:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uN4ra-0001GY-8L; Thu, 05 Jun 2025 07:18:10 +0000
Received: by outflank-mailman (input) for mailman id 1006328;
 Thu, 05 Jun 2025 07:18: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 1uN4rZ-0001GS-Na
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 07:18:09 +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 36443da3-41dd-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 09:18:00 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-450ce3a2dd5so5323905e9.3
 for ; Thu, 05 Jun 2025 00:18:00 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23506bc8537sm114103595ad.26.2025.06.05.00.17.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 00:17:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 36443da3-41dd-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749107880; x=1749712680; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=t3rkpb+NSz/2FWkgizVVfnTh5Y+dQnHK84NxNFRckzY=;
        b=NpkZGVXlYObb7K2QMqkWaRev/17RSHY1JxXtEzOkeJMWpo5M+yHHXA1Hmb5ckJt7QT
         iP8lztyLomnVQjm3qDL+w+carek7pzFY66+fdc5BZhC26Kf3AJAB73bvuFydKbCuG9qZ
         URchJiKs2Fpmt1sa9pNiUq/rf0TO7I2aVnv1aWcIXJYoVWMcGn1gtL0GUz+EUgoBFSMA
         k2WddICD2Kyl2X61RtgUv14wNFZ1Rn0r9CTF/y2LISQkRotCOUBr085aFPaO/seqbN5r
         cQZuu6j8ye4P4+Uz4P7FoFFvsu6O6q0I5r4URtmuu0BtFQjfO9V/j35t5fKBPJG1uI3o
         n2OA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749107880; x=1749712680;
        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=t3rkpb+NSz/2FWkgizVVfnTh5Y+dQnHK84NxNFRckzY=;
        b=kKAltYwYo/9bCPt8VwoNTpdZQuWjuYIzsJMfuKlJ596oQvemtcE+kpyypQuyC5+x4h
         3qByLUkPgBSxejNem3xusKF2V7JvRM3qACS03wnyM7h4heFtgqlplnMZSsba9LhLxXFV
         l+tSOz/R8k95bYGv6bscJ0Q+j78BFep6TPLSM1xRZFfTBEhrZR1X+VeD6M0ZcBz8OKMx
         QR3sbC5KiOAwUUWTbo0NJs1UGwELqGlByP8bg7nQGs5tvFUAQdKdzCUAa/aUDVp0OGwH
         gXP50nrdXamaTMZs5l1W3RUE9x1cPtdFUS+fNyxQqGpZ80tZAx9pJkdyLZkUkOmtDMbq
         UVjg==
X-Forwarded-Encrypted: i=1; AJvYcCUmC1qLJ1Hl/jhcQgC3QMsFntU+3XyE0BOGUODi/G5qqa6ZfALC4/jJf8pSzjWx4JIq1XezRRxG26U=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzobJWN7Z+CEtNZ/bXyp0nKsnGRws0OFwmO9qdF3zCkujZR4q/9
	4nedsXK0rqqeWIxIDJtFZ0soYx7cdkGudp84H2Y5H73Zgb3Aqu8vuESkfVXZ2AJwRg==
X-Gm-Gg: ASbGncsWRy1LGkCB1lZImoZ+3qmfxyvhehS/Kl+KKY1VkJ0mdL+hUxfcDKNlcDBSAHs
	kJj3lkW5Rzo6N3shKBg5RisCRv0yJ/t7lGuHSI/khmOxLmalKivlaZ34+asA8oNZzp2r90bMRX1
	ZH+V/KTcDmU73RAP9QutdLwwKFZZA4xbSvpaNaQTllv8gLj+mj+oyO1cmtYBecYhUpg6pGHkdGY
	g1b02RpqPwBWGjH/3LE/eyaV6Za04pam46Enl5oz5JKO2j7rreFsxs9FJ4Q9PX4JT+go0EWn/q8
	IAfwdkphEYiwIHNrq0m7cu700rB+GKEkAxlNrcoGD3Jhl+GSvtiECZ3ZLXKFe0EiEd2MonoBUKD
	rRYYa3MzcEhKYuJpETrmbtlJbKwh/7Y+1QYRy
X-Google-Smtp-Source: AGHT+IFQ30LGdW7a8Eg2tDU1UjLXNj7pFE3NuxLSuwGwVoN3UgXjOsMqhh4ITqNrNEdUnYz7pgpWnA==
X-Received: by 2002:a5d:64ee:0:b0:3a4:f41d:696e with SMTP id ffacd0b85a97d-3a51d9708b0mr4781030f8f.27.1749107879776;
        Thu, 05 Jun 2025 00:17:59 -0700 (PDT)
Message-ID: <9e3a7b1b-7fbe-428b-888a-c18c95d8ee37@suse.com>
Date: Thu, 5 Jun 2025 09:17:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/3] xen/keyhandler: add missing noreturn attribute
To: victorm.lira@amd.com
Cc: Nicola Vetrini ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?B?Um9nZXIgUGF1IE1vbm7Dg8Kp?= ,
 Stefano Stabellini ,
 Federico Serafini ,
 Bertrand Marquis , xen-devel@lists.xenproject.org
References: <20250604235034.1595881-1-victorm.lira@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: <20250604235034.1595881-1-victorm.lira@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 05.06.2025 01:49, victorm.lira@amd.com wrote:
> From: Nicola Vetrini 
> 
> Function `reboot_machine' does not return, but lacks the `noreturn' attribute,
> therefore causing a violation of MISRA C Rule 2.1: "A project shall not contain
> unreachable code".

Is this (uniformly) true? Looking at ...

> --- a/xen/common/keyhandler.c
> +++ b/xen/common/keyhandler.c
> @@ -251,7 +251,7 @@ static void cf_check dump_hwdom_registers(unsigned char key)
>      }
>  }
> 
> -static void cf_check reboot_machine(unsigned char key, bool unused)
> +static void noreturn cf_check reboot_machine(unsigned char key, bool unused)
>  {
>      printk("'%c' pressed -> rebooting machine\n", key);
>      machine_restart(0);

... generated code here, I can see that the compiler is perfectly able to
leverage the noreturn that machine_restart() has, resulting in no
unreachable code to be generated. That is - neither in source nor in
binary there is any unreachable code. Therefore I'm having a hard time
seeing what the violation is here.

That said, I certainly don't mind the addition of the (seemingly) missing
attribute. Otoh I wonder whether an attribute the removal of which has no
effect wouldn't count as "dead code" or alike, violating some other rule.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 07:24:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 07:24:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006338.1385526 (Exim 4.92)
	(envelope-from )
	id 1uN4xT-00037H-1X; Thu, 05 Jun 2025 07:24:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006338.1385526; Thu, 05 Jun 2025 07:24:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uN4xS-00037A-VB; Thu, 05 Jun 2025 07:24:14 +0000
Received: by outflank-mailman (input) for mailman id 1006338;
 Thu, 05 Jun 2025 07:24: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 1uN4xR-000374-Og
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 07:24: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 144bc67f-41de-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 09:24:12 +0200 (CEST)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3a361b8a664so598702f8f.3
 for ; Thu, 05 Jun 2025 00:24:12 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23506bd931bsm114360555ad.90.2025.06.05.00.24.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 00:24:11 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 144bc67f-41de-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749108252; x=1749713052; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=XvRCYzjYvWqqwHfKJcG6SenOHCxqn+OwugGlJt4Vnwg=;
        b=JYL84nh6g9MOfSgGzYTNxZnXInWmt25ICoU2T6x24y5Pe0UywdYiZWYxDB02XguQcz
         RFVNDh02iTd3G1mKm+39R/5KKHG78rzoJBgaMIbR+XwgYYQJipPpZv/AEqZ4rn6GhfUp
         +T6PNkUF3TAiRJciMC/lSPt857gHnlufmtgIuK+HB7JaBOmVC7yiKl1XzbdWptJ3L1yR
         eRcnQAwfwtlWaFwVhXeTioEaRbyqYdyY5OdNTu1k1gPAov8ehu2YKXQV/seOn4Y2TgZf
         d7m+a4IM9O+LGfaSDJ3FrXWl9M7Rd/XAn3HuYuAhE24FVPCDkg9Ai7ORUxRsqYkSwlcX
         ivwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749108252; x=1749713052;
        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=XvRCYzjYvWqqwHfKJcG6SenOHCxqn+OwugGlJt4Vnwg=;
        b=hmVBoEq4FcuT0UK4Uxpw5CApfMr7pf92NAc0qZI4mQ1T/BS59D3wkyfdUX20PqYysi
         yo7S37njRMyW+7mdRYGXR4ZGzHItHbidWesHTecSwObih4knXOLuV3DSQP7bEqkDE0fJ
         q4vh9MCy/qSA0lyfVPDzO1JfUebpqaGSePJ4QbQOUMxF/JO71GjCMM7wdN7ACyF7ux9m
         IzxZ+wk63vnRsk+eYt0EqluPdYepX9bFndfFWcvT5ztKcNU8R+3P/K52UaogLfih9yMU
         ojCuaP4QS63bXuqtC/AvO3to4gZbnWYV8vtutQZ0sPPdheQWgnN+IF2d9iqOsr7T+30v
         Sp4w==
X-Forwarded-Encrypted: i=1; AJvYcCXXf53EK4Z6xU3Vpude8C+tmCqDinfhXbywI68q7Gzs40YiWShY9zzear8Vvx6B7nNe8cMuUPbIIAM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy9hYbGaU1G+nLd1PjnvHkdL/q2qeatSNr2ZlGzzXF3+/imJ+iu
	mXUr7oZwdPxUr+t06+h4BPHniRSk1v6EcoIUtupAek5vWCsFHx2yWC5ozblP0vDqzQ==
X-Gm-Gg: ASbGncu5VDzcm005HmSw4U7qfCCpjOWfLohZMkkWQ2+uvGB2y07nU0rWuPd+OKzutv4
	GkD6glZFhM01D+e1BTPAvRhkrvDV/xRGopR2FkgGUUyq7EaQ7lR8XSUxHYLopBWCVHgMbAzeI4E
	2pElp9uXAZ/H3pECUN8uSlwk4Tjw+9WkokZdplNgF47nHS9qxrj75Wpl/V0bdF09gC4LJZPjz7H
	rh1EoPKNWCZA+dnBbkNw87jfWH/kuOfhPmVTUPPSzbCq0KWuzCwn3i4ltYlhYjS+y9xH+lEsPSz
	boBkwhPSbCVVTIm5UAMzrdmopY/1bpyLd+rjCJ04Mr4oUwb9dVk9PlR2EvaoeXPp5cD1ZOlxDYX
	XPargHoqxfPldDlG/tWGZkQbuBhJPgKymmeRqSjpCjHoJSjwdu7KzyI0ZfA==
X-Google-Smtp-Source: AGHT+IF2cJ2PnImVsJX5pubmpSxSUJb9SkCT5OnxRxLNUr9Ghv7gmKaX9fEAg60oqLsHU3zROGayjA==
X-Received: by 2002:a05:6000:2004:b0:3a4:e841:ee76 with SMTP id ffacd0b85a97d-3a51d968a7emr4272078f8f.37.1749108252133;
        Thu, 05 Jun 2025 00:24:12 -0700 (PDT)
Message-ID: <0575e9d0-ff37-4f66-8ee3-e8c3675f9cc4@suse.com>
Date: Thu, 5 Jun 2025 09:24:01 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/3] xen/x86: add missing noreturn attributes
To: victorm.lira@amd.com
Cc: Nicola Vetrini ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?B?Um9nZXIgUGF1IE1vbm7Dg8Kp?= ,
 Stefano Stabellini ,
 Federico Serafini ,
 Bertrand Marquis , xen-devel@lists.xenproject.org
References: <20250604235034.1595881-1-victorm.lira@amd.com>
 <20250604235034.1595881-2-victorm.lira@amd.com>
 <20250604235034.1595881-3-victorm.lira@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: <20250604235034.1595881-3-victorm.lira@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 05.06.2025 01:49, victorm.lira@amd.com wrote:
> From: Nicola Vetrini 
> 
> The marked functions never return to their caller, but
> lack the `noreturn' attribute, therefore causing a violation
> of MISRA C Rule 2.1: "A project shall not contain unreachable code".
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini 
> Signed-off-by: Victor Lira 

I expect the comment on patch 1 applies to some or all of the cases here,
too. For example, I expect that even if efi_arch_halt() wasn't inlined into
its sole caller, the compiler would also be able to infer noreturn from the
infinite loop there.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 07:44:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 07:44:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006360.1385537 (Exim 4.92)
	(envelope-from )
	id 1uN5HC-0006Ar-Ko; Thu, 05 Jun 2025 07:44:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006360.1385537; Thu, 05 Jun 2025 07: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 1uN5HC-0006Ak-Hn; Thu, 05 Jun 2025 07:44:38 +0000
Received: by outflank-mailman (input) for mailman id 1006360;
 Thu, 05 Jun 2025 07:44: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 1uN5HA-000686-Ds
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 07:44:36 +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 ea57e49e-41e0-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 09:44:32 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by DM4PR12MB6063.namprd12.prod.outlook.com (2603:10b6:8:b1::19) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.37; Thu, 5 Jun
 2025 07:44:28 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8792.034; Thu, 5 Jun 2025
 07:44: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: ea57e49e-41e0-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Zaj10gY9FbMEaT2kI3TgD3zqvdtuzWnrZxq+2+D7aWbxZ2o+fGMZecPUvqunOwOXayfnsdwqjIcPgjN+NKESpXSRyLSbOU5gilHRWI80GZ8S9UbBwI5Wsqi6RLERuZLo3gFuExPsgxRbg2FjCPm5aIrNy2hZqSUVtVLMYk5c+tI6VgyBiczF9GrLlBP5R9hmQJKp0fcF483i8cDfQdKo3Ws1hr+A3wrr4C1fgCbKjoiwhxtkpKYgnB2LFtX3VRp2bd/yEpK5vG+S5OBanENp9i8mM1+Hzhe6i8i7QEVV+JIxO1Q1p9mFTddGZGdy24NnnkBaAZ5l2Q/sd0v1cu3rLQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=b5hwflqy78G9+DmEoprHffsh3VGaV4cnyWxL4C/931E=;
 b=Psaap+sr2sOngXyY4Yc5jpWwC5lzW3Jhp21Ku0XtoEiyYWcplQ1RpbM5vAlXNE2lEr8lqYKjbhf1aYwtfkXzizgQJRktjvTOftdwYucjHa8WcfIbD+kcnZL6dpYiIr+QvYndFrL7I7rtcd0CUPI0HUmxd5GmJD99WT70fu20lhs+5sUKNZqVK6Ae1N8iOo3l8F/cfe/MaR/TnOVr6Tpd+jT9dTC1CWGrOXxq6XiUL3eqWaje9ibHg+oBnES8kdjW+EuH83ekPJBzD9jgF9WVCrB0ClN/yKEH9GYrEdF720TsUcc+sI20HmL8gVnVD+7bbJe3XQ7PuFczE3cFc+zorg==
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=b5hwflqy78G9+DmEoprHffsh3VGaV4cnyWxL4C/931E=;
 b=xRFg9x2wGGvvIItKWxcpSe/yL2nXvuId6wfYNaXhBIA25bAaxpiQp0i8B4log/3x8T+vwCHpOfLGTGSNkWzUHatIpVr3ID8maB7RSDg2KjK5JlpXY8U7C8eZzNEbYtNRYKJYxS4gK8zjvnYP1Vec5EUHRSHHqxmTjstmH18idVg=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <50c8e74e-95f6-4cea-b979-8b81d7575a21@amd.com>
Date: Thu, 5 Jun 2025 09:44:24 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/3] arm/mpu: Provide and populate MPU C data
 structures
To: Ayan Kumar Halder ,
 xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250604174311.754899-1-ayan.kumar.halder@amd.com>
 <20250604174311.754899-3-ayan.kumar.halder@amd.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250604174311.754899-3-ayan.kumar.halder@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR2P281CA0102.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:9c::16) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|DM4PR12MB6063:EE_
X-MS-Office365-Filtering-Correlation-Id: 21e0c967-900b-416a-e734-08dda404cca3
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?NlVrVXpPd0U2WW11aFY4RW1WU0lKT0RQVlhyZDRpRjU3VmRSakZSZ0xRaDBK?=
 =?utf-8?B?SEVRN1ZuWnZ5S043Nll2d0FQd3BoMkVtekhWTHVaZDFjQ1d1RHhVemdTRUF2?=
 =?utf-8?B?QlFBbFZIT1ZVZUhsTFNpZXArRC82dUYwUVhrKzhjWStqaGhubUNKYXgyMndu?=
 =?utf-8?B?R3VHME9pMXNQLytjSEl1UHpPbWh6UkVTMVdVV01QenNFcHg4NHFuUGtTVGQz?=
 =?utf-8?B?TnlsWlQ5bGhKYUV6eTdmN1QrYTVvWEhoYVllM3pLNk1WVFNTT01iTmRXaTJw?=
 =?utf-8?B?TysyMGwyYmRRVFd4Y0dnSTJRNGpSVE94YVlab3NEdnhPaFZ2dzNvejIvNWpG?=
 =?utf-8?B?Z0xRNXlORmRDTmhjWFVGZDdJbFptTy95VDFOOW5zRjhCbFZ0OTc4cUhRRkNq?=
 =?utf-8?B?eFF5UWdhNm1qZk5oRXlIajUrWG56dkdKUDdDVFVYcnc0U0VNZFRoUjlvVEsv?=
 =?utf-8?B?bzh1ZUxNVEJsdUd2MjZ2M293THhKeHZESHlISjBXZEErZkFxalExazFoZ21z?=
 =?utf-8?B?UXB0QnpOVEhVZ2NBTkltbXE5c3lHZTVqL0Y1M25rTEJ3UG5abUJqWkVUb1hB?=
 =?utf-8?B?UlV2SjlQSGNSZWNJWGJlb0FzT3d1VzZueTl0cEU2SEU4eituVzVZaTl1cnRG?=
 =?utf-8?B?cGlieGZRZWR1R0I4WHpaVnlpZmYwU2lxWndJOFpvNFRuVFFtWGdsZzlJaVVZ?=
 =?utf-8?B?ZlI5VHpBRDEwN2UxMlp0TVJTQTVFaTluaXRhQ2FHUUVPbGtBYWk0blcydDR4?=
 =?utf-8?B?ZVBMN2paZk1CUHZ0aWdjSmpqcWtLa0FkcVN0d3pMdVRWWE1XZTZodEowN3Fq?=
 =?utf-8?B?bTZuNXBVZW1pU1pWL2p3dnFHT3JDcUZYdDk3Qm14Zm1iYVlEbUdUb2hTM1Vk?=
 =?utf-8?B?dEc2UzlvOEZqS1UrRnJmakxER29pSFdaUlBoUGdjL0lnOFhzSDFleWlHR3R4?=
 =?utf-8?B?SHlhdTJkWXE1aUVuUDRBbGJqK29ablRFZk03R0pwYnptTHlLUkljeVN0dXoz?=
 =?utf-8?B?OENXSzljdy9jNW9DYWZpZmEzV0JlWGkwdkNoQUxBeFMyMUlIbjd3VzB1dVRS?=
 =?utf-8?B?ZW1HdU9jZlNxeUpoTXI1YXB1cEtORktWZVNCOEhnWWF3MkxFRkd5SG45TFc3?=
 =?utf-8?B?RnczNTNPOTh0YXBIOE5rVVFaZ2I3SUZ0YXhIMXZPWlhuQnpFV1M0eHE0WnJx?=
 =?utf-8?B?N3BQZGRtMGZ4dyszeE8zalp4TFZYVTdzVWxXeGhjSWt4TEcyZG01a3FEVWs4?=
 =?utf-8?B?VE5FTDVJRURKRVZkODNvb0VKT0RmNGNNYUZtYWNoTFRyREpHS0R5UTNIMm9S?=
 =?utf-8?B?WUVsc3hFQ0swaVJHNTNXTkZSSEttazI3R2RVUm9zZUh2Ui9jdTBxU2hiZXcw?=
 =?utf-8?B?cURvL1lpbFp1MmhuS0ZiQzRIVHV5NEVkWDJSZ2VQU2ZydzdwMDJZRU45RVZD?=
 =?utf-8?B?R1BZNjFZeFpGSFpuVEhBK0lNR2l0NVd0Y1YvTlVjTFh3NUZqc0I0dXhnNFdC?=
 =?utf-8?B?a28yTjhOWjRqV0VEL3ZDa3h2eXlFWXdWUFdMRHJNSm9qbUhHNkF6UGZyUGp1?=
 =?utf-8?B?d3MwczJmMjhQQnUwbE1OZnIrSEdTWnBQaE1pUFZ1UWVjeVVCdUxlQnRPN3Rl?=
 =?utf-8?B?b2dqQWhqSjNXVUR5T1p5emVUZThLdSs2aytFbXNoWCszbWx5eTBDSEVGZlkx?=
 =?utf-8?B?SW9sZ1JNdXhUeTBzbEJWcUs1UUFSZUxtTTUzcG4rU0gwMXgwemVPNk9Jc2tl?=
 =?utf-8?B?Sm1oQWtBaThXRTMrOTlBaGd6NU5JakRYK3NIZVd0ZEh0czhpdWJ6UFZCcjVH?=
 =?utf-8?B?R24wdFNqbkJNUmpsU0VzVFd5UENJVmJkVnIwUXl6TGRnSTFJNXpheUhqRSsy?=
 =?utf-8?B?NlhjbkRWZEJEMXgrb3ErdDRrUUppaTBnWmJ4Mm5QbnIrRXM0cTlEaENic2tF?=
 =?utf-8?Q?7j2DrbkS0uY=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?RHFJT3hMYkpvWGsrdVRBN2dydnZWZTlLN09LenRLMjlqMnRITm10eit6emRN?=
 =?utf-8?B?VnlkSkd3ZVhwL3doZHhNcWRjTXh5RDJBNGF5RzdYVEk5c0c1Mzh3QnRCaWtH?=
 =?utf-8?B?RTZyUE1Ka25QK1VJTzZoQWtPRDlRRWZpdmV6SnNQN0xlM1Z3eGRyRXdybC83?=
 =?utf-8?B?NWZ6MnZMbU9iMTIwL3lMNFEwbVBrOU9GZU5NbGpkZVZldE1obytiMXcrd3gx?=
 =?utf-8?B?WDVReGlsdWt4enlMTm5aUElrN3dPa1k2bDQzcUl6L2s1Qm1xcjRmTzU0OTRU?=
 =?utf-8?B?dlJmSldCbEhPczZQZDY4VXkzak5Mc1EvZ1hjYzRSeUpmazhIM3N0WXBreVhN?=
 =?utf-8?B?SlpKMnk3RFcyNm1ReWRGaTc3bVBaaWY3amhJZ1lhQTlIQ2REMmsrL3pHdnFP?=
 =?utf-8?B?SDJDQm8wbWtQb3JjOHU1djVLYVozYVN6ZVVWWG1XMVM4dHlJTDhGTGJjVXdr?=
 =?utf-8?B?enNMZWV0bE9INFBmeGxxK0oxV3creG5aTlg4VnRqMS9QVzlOVVpjRXBjdVJj?=
 =?utf-8?B?UGZzT3k1VmUrUGNLRmJIRm04M0o0M1FYUHFHQ1pET0FDOHR0TGE0VEpNNHVB?=
 =?utf-8?B?ME1SeEJ1cHFVb0RBZnJGK2ltM1orVHo4YmF2elIrTTFDVDJ6YUhXbFVqSjAz?=
 =?utf-8?B?ZDM4akhXNnlRR2U3Tk9OR1VBWGlocHYwSnBwM0gwZ3UxWXZxRTNFOEdWZVF0?=
 =?utf-8?B?bjQrV3c2YXh5M3Nod01jdWYwTmtjdmI2MzU4RTNwbklmSnJNTHhIWmlGdGtK?=
 =?utf-8?B?dUpxU3NLejh1TnN3TzV2Zy9BZjg1bXNxQVpiVld4M2Z4RkxQbjN4dXBKVE0r?=
 =?utf-8?B?eldBZVNMUENvSWRiSy9FSTFSZmdSV09OWkFuM1FjakhIQnlrTklhZFg4YWZp?=
 =?utf-8?B?SXpJMDNaYzE0VEJTWDN1T2FSSmpuT0pyTnhvcTdpa2NmOUFkSSthdFo0SUdq?=
 =?utf-8?B?TWtacUNEWGdhb2lYeWx5K0FYdWxFREp6OHhZYStML2s1LzZVQlFFMmVieUF3?=
 =?utf-8?B?bWZ2bGNlMy9jWjZiejhoclE4ZnIrMStUMlBYaWVZemZnTjc0ZWpDS3kzMXBr?=
 =?utf-8?B?L2hIbkRxeUdUQWE2REI5T2MvUU5MZHdkV3pZdW9RKzdwZmhSaWVobGJrZFZq?=
 =?utf-8?B?aWtqRS91eDRySHlkMHY3K3ExSElpSFg5ckR0cnRFcmMvQlR5Z0RKd1ZycEJE?=
 =?utf-8?B?Vyt3bzZtdkJlMnNHaEYxMGI0Y1JsSmJDVkEyemJCYVdTREQ0Qll3cnE0QzFu?=
 =?utf-8?B?ODdKSnBRSll1ZFZLcWg4eW1BcERWZEJjcWZaZVh5dTBoN0doMGFTa0dEb2Zy?=
 =?utf-8?B?Qzk2dEo0ZHNTZkE5c2tTV1U2SGxmZHF3dTN3Q25hdm5VOUVUaTJuVm9IVlpT?=
 =?utf-8?B?dUNzaFhoZ21obUpBVWtvUmpjN1dYdnRwUmYyZnNWTnZZaEIvYVl6VHhtK1NQ?=
 =?utf-8?B?MWs1ZTVZVHVlcXJqMlpjWlJDTEszU2huR1FjOVhyTEpoeCtHL2pYYWVqZCtQ?=
 =?utf-8?B?c0lFWjdmM3NXbFM2bVZINlFlUlZ1U0sxR1JtQk9RY3ptb0ZZSmVOL3RQTXdP?=
 =?utf-8?B?cFhaNTQ5QVZMWlM4N0g4Q3k1dVV2dnVPbmNiSWI5eE9xbHcxLzlZay9WVTlW?=
 =?utf-8?B?c3QxRkM2ZFRSdzBCRnFzRFJ2K054TWg4M2dGN3NBdlh5eEtVNnZNU2k4d3Fq?=
 =?utf-8?B?OVJkOWlTamdBQzZOU1I3NVo4WlA1YVJoOVlpZUNRSmt4NUtxa3A3bWdmSkM1?=
 =?utf-8?B?aW5zRW1UeDZHMUlGSjZVMmhtRzJSV3lBeGJ2cFZOdmJoL3o4UnY5eXcxV3or?=
 =?utf-8?B?OEpNQzEvMVhZK2t6S2dLeUVyeWhkc3NJOXRMSDFrL2FYNkQ1OFlaWFljVktS?=
 =?utf-8?B?UjlWRmxDRUpUZi9PeWNqL3BWWWE3YzNhN016SGxtUmQrazJqbFFCMkVwRTky?=
 =?utf-8?B?RmtnK0FTL0dlV3BaYS9OU1Vad0krRHgzdFpaTS9oV01HbkhNcFlrM2QwK09X?=
 =?utf-8?B?RFpnUk5COTVuek03cC9McWgya3F5Y3pCRXVrdEQzR1JSSDJmOENtUDlNUUF6?=
 =?utf-8?B?dklId1VUeThac28rZVRiUUE4V2VzT3N0Uzd3L3J3OHBVbkpIY29HWVI5Z3hL?=
 =?utf-8?Q?ftrIGOPRAbqroq+ZYpJhKmyMA?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 21e0c967-900b-416a-e734-08dda404cca3
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jun 2025 07:44:28.2101
 (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: 1Zt2845p/QwZ5hfAwKRgVwMik+TPQ8ory/fd2tPsTaPo9ypVeJW9gPA+wQrYKp9T
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6063



On 04/06/2025 19:43, Ayan Kumar Halder wrote:
> Do the arm32 equivalent initialization for commit id ca5df936c4.
This is not a good commit msg.
Also, we somewhat require passing 12 char long IDs.

> 
> Signed-off-by: Ayan Kumar Halder 
> ---
>  xen/arch/arm/arm32/asm-offsets.c         |  6 +++
>  xen/arch/arm/arm32/mpu/head.S            | 57 ++++++++++++++++++++++++
>  xen/arch/arm/include/asm/mpu/regions.inc |  8 +++-
>  3 files changed, 70 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/arm32/asm-offsets.c b/xen/arch/arm/arm32/asm-offsets.c
> index 8bbb0f938e..c203ce269d 100644
> --- a/xen/arch/arm/arm32/asm-offsets.c
> +++ b/xen/arch/arm/arm32/asm-offsets.c
> @@ -75,6 +75,12 @@ void __dummy__(void)
>  
>     OFFSET(INITINFO_stack, struct init_info, stack);
>     BLANK();
> +
> +#ifdef CONFIG_MPU
> +   DEFINE(XEN_MPUMAP_MASK_sizeof, sizeof(xen_mpumap_mask));
> +   DEFINE(XEN_MPUMAP_sizeof, sizeof(xen_mpumap));
> +   BLANK();
> +#endif
>  }
>  
>  /*
> diff --git a/xen/arch/arm/arm32/mpu/head.S b/xen/arch/arm/arm32/mpu/head.S
> index b2c5245e51..1f9eec6e68 100644
> --- a/xen/arch/arm/arm32/mpu/head.S
> +++ b/xen/arch/arm/arm32/mpu/head.S
> @@ -10,6 +10,38 @@
>  #include 
>  #include 
>  
> +/*
> + * dcache_line_size - get the minimum D-cache line size from the CTR register.
> + */
I do think we should have a cache.S file to store cache related ops just like
for Arm64.
Also, no need for multiline comment.

> +    .macro  dcache_line_size, reg, tmp1, tmp2
I would prefer to use the macro from Linux that uses one temporary register

> +    mrc CP32(\reg, CTR)           // read CTR
NIT: wrong comment style + wrong alignment

> +    ubfx   \tmp1, \reg, #16, #4   // Extract DminLine (bits 19:16) into tmp1
> +    mov    \tmp2, #1
> +    lsl    \tmp2, \tmp2, \tmp1    // tmp2 = 2^DminLine
> +    lsl    \tmp2, \tmp2, #2       // tmp2 = 4 * 2^DminLine = cache line size in bytes
> +    .endm
> +
> +/*
> + * __invalidate_dcache_area(addr, size)
> + *
> + * Ensure that the data held in the cache for the buffer is invalidated.
> + *
> + * - addr - start address of the buffer
> + * - size - size of the buffer
> + */
> +FUNC(__invalidate_dcache_area)
> +    dcache_line_size r2, r3, r4
> +    add   r1, r0, r1
> +    sub   r4, r2, #1
> +    bic   r0, r0, r4
> +1:  mcr   CP32(r0, DCIMVAC)     /* invalidate D line / unified line */
> +    add   r0, r0, r2
> +    cmp   r0, r1
> +    blo   1b
> +    dsb   sy
> +    ret
> +END(__invalidate_dcache_area)
> +
>  /*
>   * Set up the memory attribute type tables and enable EL2 MPU and data cache.
>   * If the Background region is enabled, then the MPU uses the default memory
> @@ -49,6 +81,10 @@ FUNC(enable_boot_cpu_mm)
>      mrc   CP32(r5, MPUIR_EL2)
>      and   r5, r5, #NUM_MPU_REGIONS_MASK
>  
> +    ldr   r0, =max_mpu_regions
Why ldr and not mov_w?

> +    str   r5, [r0]
> +    mcr   CP32(r0, DCIMVAC) /* Invalidate cache for max_mpu_regions addr */
> +
>      /* x0: region sel */
>      mov   r0, #0
>      /* Xen text section. */
> @@ -83,6 +119,27 @@ FUNC(enable_boot_cpu_mm)
>      prepare_xen_region r0, r1, r2, r3, r4, r5, attr_prbar=REGION_DEVICE_PRBAR, attr_prlar=REGION_DEVICE_PRLAR
>  #endif
>  
> +zero_mpu:
> +    /* Reset remaining MPU regions */
> +    cmp   r0, r5
> +    beq   out_zero_mpu
> +    mov   r1, #0
> +    mov   r2, #1
> +    prepare_xen_region r0, r1, r2, r3, r4, r5, attr_prlar=REGION_DISABLED_PRLAR
> +    b     zero_mpu
> +
> +out_zero_mpu:
> +    /* Invalidate data cache for MPU data structures */
> +    mov r5, lr
> +    ldr r0, =xen_mpumap_mask
Why not mov_w?

> +    mov r1, #XEN_MPUMAP_MASK_sizeof
> +    bl __invalidate_dcache_area
> +
> +    ldr r0, =xen_mpumap
> +    mov r1, #XEN_MPUMAP_sizeof
> +    bl __invalidate_dcache_area
> +    mov lr, r5
> +
>      b    enable_mpu
>  END(enable_boot_cpu_mm)
>  
> diff --git a/xen/arch/arm/include/asm/mpu/regions.inc b/xen/arch/arm/include/asm/mpu/regions.inc
> index 6b8c233e6c..943bcda346 100644
> --- a/xen/arch/arm/include/asm/mpu/regions.inc
> +++ b/xen/arch/arm/include/asm/mpu/regions.inc
> @@ -24,7 +24,13 @@
>  #define XEN_MPUMAP_ENTRY_SHIFT  0x3     /* 8 byte structure */
>  
>  .macro store_pair reg1, reg2, dst
> -    .word 0xe7f000f0                    /* unimplemented */
> +    str \reg1, [\dst]
> +    add \dst, \dst, #4
> +    str \reg2, [\dst]
AFAIR there is STM instruction to do the same

> +.endm
> +
> +.macro invalidate_dcache_one reg
> +    mcr CP32(\reg, DCIMVAC)
Why? You don't seem to use this macro

>  .endm
>  
>  #endif

~Michal



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 07:57:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 07:57:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006366.1385547 (Exim 4.92)
	(envelope-from )
	id 1uN5TE-0007wd-LY; Thu, 05 Jun 2025 07:57:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006366.1385547; Thu, 05 Jun 2025 07: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 1uN5TE-0007wW-IA; Thu, 05 Jun 2025 07:57:04 +0000
Received: by outflank-mailman (input) for mailman id 1006366;
 Thu, 05 Jun 2025 07:57: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 1uN5TD-0007wQ-Bs
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 07:57:03 +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 a2dfd5a2-41e2-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 09:56:50 +0200 (CEST)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-450cf214200so5449975e9.1
 for ; Thu, 05 Jun 2025 00:56:50 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-451f991967csm15336285e9.32.2025.06.05.00.56.48
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 00:56:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a2dfd5a2-41e2-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749110209; x=1749715009; 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=QLxzcz9unMcmiV01ec0f5lpEN+wRH56fPF4Yt2WK1x0=;
        b=F4EAP2Kzcvhf+MGY6ZjHSMI3q88slKmhlfukv7rcNwcc22pHHjFbvDW+Vl/EbKvrQD
         F9DGwdn0h3KblBq5nYIKZGtxMwA3AuUQgZQcDpu4p1BxVh6o8kmTPw0skC0dFXq4bOvj
         8yUG+D2bRsAz3OoOmr0mRH5Roedj41OS2sctc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749110209; x=1749715009;
        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=QLxzcz9unMcmiV01ec0f5lpEN+wRH56fPF4Yt2WK1x0=;
        b=XkHUCYq/GrpHkcvWYL9PL6Axom4Z0FhdzBc3rOczZTEgC1mjRg2h0du4ho9gTFDP+S
         umFYDo0Z6oLw3gNPh1wMowjSUa+Er18M4IEqNu/z4jAeL2YxPKGFKxOBRm+6VwODyhyY
         JU/Dd3T3evf63zShjOPaUs4+NZlRdnkMadxZSbPhfWkm0rzfUZPlxYijh2a6GyRyjmXE
         PeKKY5gOFFUIB8r0BLwApJXRbO7LSigNN9xGN873kqZNSY5H1OMroDRl+EfqZ8/ke5Rq
         pQo44jIZlxuCMiP4tEpi7ve7TLEv4HYyN88xggTERCUDSgXBB5iunczexzJb1D8Bluzz
         4efw==
X-Gm-Message-State: AOJu0YwotlyM0yR71/fXlbSUp9Kzyjs1Sg3LLQuto5bu3fZ0eQQtWaXC
	SXwaeTln4YSmHKM8hv2LfEFPuIkbmWobFWBqCw9n44wV3ChLDeuYmd5yAp2PleD7HU0=
X-Gm-Gg: ASbGncsidE3zXfu5kWJbKdfwEgmteuLlgMvAqQTvolxAobNMCeO00FZ4boHfoLJCB5k
	WwZnme2UDO4VOoWaiMu96ZtgvWeOEifu3LSxarbTDLQE7IzIGRo/Zcct2nw8qvJm9I0pyofIMJS
	l6WQmxYNUYizrrdpiftb9yF6UHNJldd5qDpayBkG2j7Xfai85+X9Xbi8qdt1jIAJ57XzT5HWmYb
	wG2RNzdjd2wIxWUgMBZn9hz7KUVRDqggoeq7YYYOBogZboU2l1tq13EPHJ46iZHSLGdS0lhY+mB
	ibrPzsDYwgv5wLSS9wIaN+hmOSjB9QSVshLz7dMODaQZbSspKU+99CHaqAEw3KNowJw43aMyhrX
	AlgkyhI+wQyMshSzhdk3kMI/I
X-Google-Smtp-Source: AGHT+IHPb3M7IYxYN2oTaUlXE+ZzgdOxbnam66IPKbm1sUmSzWMKu/4dicCefCemPwIznQPcgct79Q==
X-Received: by 2002:a05:600c:8312:b0:450:d01f:de6f with SMTP id 5b1f17b1804b1-451f0aa72fdmr53382165e9.15.1749110209455;
        Thu, 05 Jun 2025 00:56:49 -0700 (PDT)
Date: Thu, 5 Jun 2025 09:56:47 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= 
Cc: xen-devel@lists.xenproject.org,
	Anthony PERARD ,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini ,
	Anthoine Bourgeois 
Subject: Re: [PATCH v2] x86/hvmloader: select xenpci MMIO BAR UC or WB MTRR
 cache attribute
Message-ID: 
References: <20250603111806.86555-1-roger.pau@citrix.com>
 <2c26fe05-ef42-48a0-9d9d-ad86100eaf01@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2c26fe05-ef42-48a0-9d9d-ad86100eaf01@suse.com>

On Wed, Jun 04, 2025 at 12:33:55PM +0200, Jürgen Groß wrote:
> On 03.06.25 13:18, Roger Pau Monne wrote:
> > The Xen PCI device (vendor ID 0x5853) exposed to x86 HVM guests doesn't
> > diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
> > index cc67b18c0361..97933b44a82b 100644
> > --- a/tools/firmware/hvmloader/pci.c
> > +++ b/tools/firmware/hvmloader/pci.c
> > @@ -30,7 +30,7 @@
> >   #include 
> >   uint32_t pci_mem_start = HVM_BELOW_4G_MMIO_START;
> > -const uint32_t pci_mem_end = RESERVED_MEMBASE;
> > +uint32_t pci_mem_end = RESERVED_MEMBASE;
> >   uint64_t pci_hi_mem_start = 0, pci_hi_mem_end = 0;
> >   /*
> > @@ -116,6 +116,8 @@ void pci_setup(void)
> >        * experience the memory relocation bug described below.
> >        */
> >       bool allow_memory_relocate = 1;
> > +    /* Set the MTRR type of the xenpci device BAR as UC. */
> > +    bool xenpci_bar_uc = false;
> 
> Hmm, shouldn't this be "true"? Or should the comment be changed?

The intention of the comment was to signal that this variable is used
to set the BAR cache attributes to UC possibly, but I can see how
that's confusing.  What about using:

    /* Select the MTRR cache attributes of the xenpci device BAR. */
    bool xenpci_bar_uc = false;

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 08:35:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 08:35:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006382.1385556 (Exim 4.92)
	(envelope-from )
	id 1uN64T-0005KB-GJ; Thu, 05 Jun 2025 08:35:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006382.1385556; Thu, 05 Jun 2025 08:35: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 1uN64T-0005K4-Dn; Thu, 05 Jun 2025 08:35:33 +0000
Received: by outflank-mailman (input) for mailman id 1006382;
 Thu, 05 Jun 2025 08:35: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 1uN64S-0005Jx-8F
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 08:35:32 +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 0a32057d-41e8-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 10:35:30 +0200 (CEST)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-addfe17ec0bso278720966b.1
 for ; Thu, 05 Jun 2025 01:35:30 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ada5e8780besm1239295266b.94.2025.06.05.01.35.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 01:35:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0a32057d-41e8-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749112530; x=1749717330; 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=fKCS6idbb1RjJfLA+bREsLVqXVOzL5UH+BkPlFq3J88=;
        b=AtceF6imiLH40onegaXkwQKZWdlCRYDXb5fIwtHtFC6NCrsbn9Diw/MdkemzeKXHa3
         oRMZ3+gFQlNhGN4u4TKvorDFMUJEg2pFA1T4lahGqpC9EEZzubpjCZmmZeMuukVv/Ncr
         OGQym5wSY+TUmRgigttZjtNzLUsWPQJLlt4vmRuykqM84a1cC+N4VUslqoJ80Pav0yEv
         mkfpZfrBp0VAV7LyVsKo6JvTIoJi5fXF8zW1ny9aGqJmJcAVj1TnZ2jMYEx/a1jsxs5P
         nNMkk87y7/XuTKh6a7m93XDWTaQhE1LNGIWTanuPEE3CsaN0W9vdvPajNXQ6oSRd/UbI
         yjcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749112530; x=1749717330;
        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=fKCS6idbb1RjJfLA+bREsLVqXVOzL5UH+BkPlFq3J88=;
        b=wVqRcX6zlUfB87pAWSAAd5Oq9gDYZ3jErjrVGh2/j0O49Hqh7DIxbod4/DB8O9S6+b
         HL1WHVgqr163Na37C8BZ6YLbKlynT/BlVVQWP+cz7WatLxzPwzRxRCMs+Q/WfAYb+W6K
         0AFhdy9vUBaRydQaUyF3pc605mbqo3ReaBabbUUGCpLixr+5voCb99BAMQ12SmOSX0X4
         5XM3bWUyQliwBI6a/FHal6YCh5AmBa2RzpKj5jCfnHwsdFSb/RwyWwnl9kqjmgFR3j6K
         X1RjG0Mrq2diFA3XdsrVyZvf7/GxqcL4mLrtwslR8jqW4dz3eea8CMFCTRCM6+8+dimh
         gfKQ==
X-Forwarded-Encrypted: i=1; AJvYcCUSzK5O/3J9py+2mqZBZCEizlhfePKDy44MycMAuH3QeMP1QfYPkUhcJb7ZmaoTQ7y2K1Fczv8gREw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyec5tx2d4PxFDjY8lK+vfoNft8qrnS/jxGbup/kEtEoJO85Lgc
	H8k2bBr3E13WjapiT8/IgGxp0Snvdc9idf6/9Y6MaWlyJpYikWwhqnVv
X-Gm-Gg: ASbGnctMr4w2VsGQ9dauEXW0bzxj8FoyBAxfQGl+fpB6MTsfWP4f5Si/1vGpnIc+AcW
	uyHih63PSLp7r7+G575wiy6lsCD6/UxsCgxF0EjYcLlzuMOK9ZfCIcdo4puu6roAKDa7DcgxQGd
	92drQUi5Bd5BY9kZ4nQTsBo8qq/tS/3QpKnhUyGO48X4QbG/dkFzDKIc8n6rqqLScXoOlqUm9Vv
	lRrFt2u2C+LtkOgMvdYUxAwQ8DqFvWs2V/Cf1qEOpyQ2WysHjIMPBXQQdLU9ZZgAf2uboOpRyTS
	JuEQeRq+4RLyHlxAFM+w+LVFoBr4D1RR8F2lYxG9z3+dthCTEXlEBIZdjtd13sdtjwiOzit83r8
	B1I+4lAF323+LiHHHGDsJQ387
X-Google-Smtp-Source: AGHT+IF8ufuiMBNJcfMFmLqTxeZwgaBPme29wY0NHCBcsjGNRPUqjgiTKkHPUdxo+Ka+c4vYzKdYhg==
X-Received: by 2002:a17:907:2d9f:b0:ad5:6258:996f with SMTP id a640c23a62f3a-ade07828858mr246206866b.19.1749112530017;
        Thu, 05 Jun 2025 01:35:30 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------UAtzJz0SzDZu9np20vv0ePEj"
Message-ID: 
Date: Thu, 5 Jun 2025 10:35:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 08/14] xen/riscv: imsic_init() implementation
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 ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <421dad1bbd014a2d7ff588af088eadbd56345dbe.1747843009.git.oleksii.kurochko@gmail.com>
 
 
 <84c9f65a-b278-4be4-b053-5bfa410f9a97@gmail.com>
 <9ab65452-497c-47b5-af18-92a7b2a86d9e@suse.com>
 
 <85d6f812-784a-4959-a1e6-589ebac8887c@suse.com>
 <63d8882d-bd54-4cbd-8c48-24b296ce4a50@gmail.com>
 <7c487a6e-474b-417e-a120-2d097eb3d178@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <7c487a6e-474b-417e-a120-2d097eb3d178@suse.com>

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


On 6/5/25 8:52 AM, Jan Beulich wrote:
> On 04.06.2025 17:41, Oleksii Kurochko wrote:
>> On 6/4/25 5:05 PM, Jan Beulich wrote:
>>> On 04.06.2025 15:42, Oleksii Kurochko wrote:
>>>> On 6/2/25 12:22 PM, Jan Beulich wrote:
>>>>> On 27.05.2025 13:30, Oleksii Kurochko wrote:
>>>>>> On 5/26/25 8:44 PM, Oleksii Kurochko wrote:
>>>>>>>>> +    if ( !dt_property_read_u32(node, "riscv,guest-index-bits",
>>>>>>>>> +                               &imsic_cfg.guest_index_bits) )
>>>>>>>>> +        imsic_cfg.guest_index_bits = 0;
>>>>>>>>> +    tmp = BITS_PER_LONG - IMSIC_MMIO_PAGE_SHIFT;
>>>>>>>>> +    if ( tmp < imsic_cfg.guest_index_bits )
>>>>>>>>> +    {
>>>>>>>>> +        printk(XENLOG_ERR "%s: guest index bits too big\n",
>>>>>>>>> +               dt_node_name(node));
>>>>>>>>> +        rc = -ENOENT;
>>>>>>>>> +        goto cleanup;
>>>>>>>>> +    }
>>>>>>>>> +
>>>>>>>>> +    /* Find number of HART index bits */
>>>>>>>>> +    if ( !dt_property_read_u32(node, "riscv,hart-index-bits",
>>>>>>>>> +                               &imsic_cfg.hart_index_bits) )
>>>>>>>>> +    {
>>>>>>>>> +        /* Assume default value */
>>>>>>>>> +        imsic_cfg.hart_index_bits = fls(*nr_parent_irqs);
>>>>>>>>> +        if ( BIT(imsic_cfg.hart_index_bits, UL) < *nr_parent_irqs )
>>>>>>>>> +            imsic_cfg.hart_index_bits++;
>>>>>>>> Since fls() returns a 1-based bit number, isn't it rather that in the
>>>>>>>> exact-power-of-2 case you'd need to subtract 1?
>>>>>>> Agree, in this case, -1 should be taken into account.
>>>>>> Hmm, it seems like in case of fls() returns a 1-based bit number there
>>>>>> is not need for the check:
>>>>>>      (2) if ( BIT(imsic_cfg.hart_index_bits, UL) < *nr_parent_irqs )
>>>>>>
>>>>>> We could do imsic_cfg.hart_index_bits = fls(*nr_parent_irqs - 1) (1) without
>>>>>> checking *nr_parent_irqs is power-of-two or not, and then just leave the
>>>>>> check (2).
>>>>>> And with (1), the check (2) is only needed for the case *nr_parent_irqs=1, if
>>>>>> I amn't mistaken something. And if I'm not mistaken, then probably it make
>>>>>> sense to change (2) to if ( *nr_parent_irqs == 1 ) + some comment why this
>>>>>> case is so special.
>>>>>>
>>>>>> Does it make sense?
>>>>> Can't easily tell; I'd like to see the resulting code instead of the textual
>>>>> description.
>>>> Here is the code:
>>>>        /* Find number of HART index bits */
>>>>        if ( !dt_property_read_u32(node, "riscv,hart-index-bits",
>>>>                                   &imsic_cfg.hart_index_bits) )
>>>>        {
>>>>            /* Assume default value */
>>>>            imsic_cfg.hart_index_bits = fls(*nr_parent_irqs - 1) +
>>>>                                        (*nr_parent_irqs == 1);
>>>>        }
>>>>
>>>> It seems like it covers all the cases.
>>> *nr_parent_irqs		imsic_cfg.hart_index_bits
>>> 	 1			1 (0 + 1)
>>> 	 2			1
>>> 	 3			2
>>> 	 4			2
>>> 	 5			3
>>> 	 6			3
>>>
>>> IOW why the special casing of *nr_parent_irqs == 1?
>> If we don't have "... + (*nr_parent_irqs == 1)" then for the case when *nr_parent_irqs == 1,
>> we will have imsic_cfg.hart_index_bits = fls(1-1) = fls(0) = 0 because:
>>     #define arch_fls(x)     ((x) ? BITS_PER_INT - __builtin_clz(x) : 0)
>> and imsic_cfg.hart_index_bits = 0 doesn't seem correct because I expect that if I have only
>> 1 hart then at least 1 bit will be needed to point to it.
> No, why? To pick 1 out of 1 you need no bits at all to represent.

It seems you are right, I thought that DT's binding requires it to be minimum 1, but it could
be zero.
Then it is okay just to initialize hart_index_bits without extra " + (*nr_parent_irqs == 1)":
   imsic_cfg.hart_index_bits = fls(*nr_parent_irqs - 1);

~ Oleksii

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



  
    
  
  
    

    
    
    
    
    On 6/5/25 8:52 AM, Jan Beulich wrote:
    
    
    
    
    
      
    On 04.06.2025 17:41, Oleksii Kurochko wrote:

    
      
    
        
    On 6/4/25 5:05 PM, Jan Beulich wrote:

    
        
    
          
    On 04.06.2025 15:42, Oleksii Kurochko wrote:

    
          
    
            
    On 6/2/25 12:22 PM, Jan Beulich wrote:

    
            
    
              
    On 27.05.2025 13:30, Oleksii Kurochko wrote:

    
              
    
                
    On 5/26/25 8:44 PM, Oleksii Kurochko wrote:

    
                
    
                  
    
                    
    
                      
    +    if ( !dt_property_read_u32(node, "riscv,guest-index-bits",
+                               &imsic_cfg.guest_index_bits) )
+        imsic_cfg.guest_index_bits = 0;
+    tmp = BITS_PER_LONG - IMSIC_MMIO_PAGE_SHIFT;
+    if ( tmp < imsic_cfg.guest_index_bits )
+    {
+        printk(XENLOG_ERR "%s: guest index bits too big\n",
+               dt_node_name(node));
+        rc = -ENOENT;
+        goto cleanup;
+    }
+
+    /* Find number of HART index bits */
+    if ( !dt_property_read_u32(node, "riscv,hart-index-bits",
+                               &imsic_cfg.hart_index_bits) )
+    {
+        /* Assume default value */
+        imsic_cfg.hart_index_bits = fls(*nr_parent_irqs);
+        if ( BIT(imsic_cfg.hart_index_bits, UL) < *nr_parent_irqs )
+            imsic_cfg.hart_index_bits++;

    
                    
    
                    
    Since fls() returns a 1-based bit number, isn't it rather that in the
exact-power-of-2 case you'd need to subtract 1?

    
                  
    
                  
    Agree, in this case, -1 should be taken into account.

    
                
    
                
    Hmm, it seems like in case of fls() returns a 1-based bit number there
is not need for the check:
    (2) if ( BIT(imsic_cfg.hart_index_bits, UL) < *nr_parent_irqs )

We could do imsic_cfg.hart_index_bits = fls(*nr_parent_irqs - 1) (1) without
checking *nr_parent_irqs is power-of-two or not, and then just leave the
check (2).
And with (1), the check (2) is only needed for the case *nr_parent_irqs=1, if
I amn't mistaken something. And if I'm not mistaken, then probably it make
sense to change (2) to if ( *nr_parent_irqs == 1 ) + some comment why this
case is so special.

Does it make sense?

    
              
    
              
    Can't easily tell; I'd like to see the resulting code instead of the textual
description.

    
            
    
            
    Here is the code:
      /* Find number of HART index bits */
      if ( !dt_property_read_u32(node, "riscv,hart-index-bits",
                                 &imsic_cfg.hart_index_bits) )
      {
          /* Assume default value */
          imsic_cfg.hart_index_bits = fls(*nr_parent_irqs - 1) +
                                      (*nr_parent_irqs == 1);
      }

It seems like it covers all the cases.

    
          
    
          
    *nr_parent_irqs		imsic_cfg.hart_index_bits
	 1			1 (0 + 1)
	 2			1
	 3			2
	 4			2
	 5			3
	 6			3

IOW why the special casing of *nr_parent_irqs == 1?

    
        
    
        
    If we don't have "... + (*nr_parent_irqs == 1)" then for the case when *nr_parent_irqs == 1,
we will have imsic_cfg.hart_index_bits = fls(1-1) = fls(0) = 0 because:
   #define arch_fls(x)     ((x) ? BITS_PER_INT - __builtin_clz(x) : 0)
and imsic_cfg.hart_index_bits = 0 doesn't seem correct because I expect that if I have only
1 hart then at least 1 bit will be needed to point to it.

    
      
    
      
    No, why? To pick 1 out of 1 you need no bits at all to represent.
    
    
    
    
    It seems you are right, I thought that DT's binding requires it to be minimum 1, but it could
be zero.
Then it is okay just to initialize hart_index_bits without extra " + (*nr_parent_irqs == 1)":
  imsic_cfg.hart_index_bits = fls(*nr_parent_irqs - 1);

    
    
    ~ Oleksii

    
  


--------------UAtzJz0SzDZu9np20vv0ePEj--


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 08:51:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 08:51:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006401.1385567 (Exim 4.92)
	(envelope-from )
	id 1uN6Ji-00088R-UG; Thu, 05 Jun 2025 08:51:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006401.1385567; Thu, 05 Jun 2025 08: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 1uN6Ji-00088K-QH; Thu, 05 Jun 2025 08:51:18 +0000
Received: by outflank-mailman (input) for mailman id 1006401;
 Thu, 05 Jun 2025 08: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 1uN6Jh-00088E-1t
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 08:51:17 +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 3cc061fe-41ea-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 10:51:14 +0200 (CEST)
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 425E5347E9;
 Thu,  5 Jun 2025 08:51:13 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id E68AE137FE;
 Thu,  5 Jun 2025 08:51: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 k0RzNoBaQWiuTAAAD6G6ig
 (envelope-from ); Thu, 05 Jun 2025 08:51: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: 3cc061fe-41ea-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1749113473; 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=LqRq5aYdQZ1Ws51ElL6WJmXEY1smQJet/1RX0rx0O44=;
	b=ON52WA9Zmo4WHNqmbFzfLfi17zyzTwZbFxfyQHDj74c3mqRzZl9w5t+SaJTxTdWJsa4N9W
	L5k/ynt0IzILJj+4ERfqbwFwYmwCQ5+Apf/nBeiBVTzCBPBKP19XnA9cQeD0tEKuLYt5CH
	8alM8SjP9iRylLGnb/W8uf0QC8Uigus=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1749113473; 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=LqRq5aYdQZ1Ws51ElL6WJmXEY1smQJet/1RX0rx0O44=;
	b=ON52WA9Zmo4WHNqmbFzfLfi17zyzTwZbFxfyQHDj74c3mqRzZl9w5t+SaJTxTdWJsa4N9W
	L5k/ynt0IzILJj+4ERfqbwFwYmwCQ5+Apf/nBeiBVTzCBPBKP19XnA9cQeD0tEKuLYt5CH
	8alM8SjP9iRylLGnb/W8uf0QC8Uigus=
Message-ID: <6e7906b6-9056-45c3-b713-aa9357f582ee@suse.com>
Date: Thu, 5 Jun 2025 10:51:12 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] x86/hvmloader: select xenpci MMIO BAR UC or WB MTRR
 cache attribute
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: xen-devel@lists.xenproject.org, Anthony PERARD
 , Andrew Cooper ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , Stefano Stabellini ,
 Anthoine Bourgeois 
References: <20250603111806.86555-1-roger.pau@citrix.com>
 <2c26fe05-ef42-48a0-9d9d-ad86100eaf01@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="------------MPTUoqGdOkPD9tBToW6z814M"
X-Spamd-Result: default: False [-4.28 / 50.00];
	BAYES_HAM(-3.00)[99.99%];
	SIGNED_PGP(-2.00)[];
	NEURAL_SPAM_SHORT(1.72)[0.575];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];
	MIME_BASE64_TEXT(0.10)[];
	MIME_UNKNOWN(0.10)[application/pgp-keys];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~];
	RCPT_COUNT_SEVEN(0.00)[9];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	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,imap1.dmz-prg2.suse.org:helo];
	HAS_ATTACHMENT(0.00)[]
X-Spam-Level: 
X-Spam-Flag: NO
X-Spam-Score: -4.28

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------MPTUoqGdOkPD9tBToW6z814M
Content-Type: multipart/mixed; boundary="------------2hoOUZy0L9t4VUxpyzvNnNvy";
 protected-headers="v1"
From: Juergen Gross 
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: xen-devel@lists.xenproject.org, Anthony PERARD
 , Andrew Cooper ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , Stefano Stabellini ,
 Anthoine Bourgeois 
Message-ID: <6e7906b6-9056-45c3-b713-aa9357f582ee@suse.com>
Subject: Re: [PATCH v2] x86/hvmloader: select xenpci MMIO BAR UC or WB MTRR
 cache attribute
References: <20250603111806.86555-1-roger.pau@citrix.com>
 <2c26fe05-ef42-48a0-9d9d-ad86100eaf01@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=

--------------2hoOUZy0L9t4VUxpyzvNnNvy
Content-Type: multipart/mixed; boundary="------------Z06gGr1EKKSjusfw4MzO0Rik"

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

T24gMDUuMDYuMjUgMDk6NTYsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+IE9uIFdlZCwg
SnVuIDA0LCAyMDI1IGF0IDEyOjMzOjU1UE0gKzAyMDAsIErDvHJnZW4gR3Jvw58gd3JvdGU6
DQo+PiBPbiAwMy4wNi4yNSAxMzoxOCwgUm9nZXIgUGF1IE1vbm5lIHdyb3RlOg0KPj4+IFRo
ZSBYZW4gUENJIGRldmljZSAodmVuZG9yIElEIDB4NTg1MykgZXhwb3NlZCB0byB4ODYgSFZN
IGd1ZXN0cyBkb2Vzbid0DQo+Pj4gZGlmZiAtLWdpdCBhL3Rvb2xzL2Zpcm13YXJlL2h2bWxv
YWRlci9wY2kuYyBiL3Rvb2xzL2Zpcm13YXJlL2h2bWxvYWRlci9wY2kuYw0KPj4+IGluZGV4
IGNjNjdiMThjMDM2MS4uOTc5MzNiNDRhODJiIDEwMDY0NA0KPj4+IC0tLSBhL3Rvb2xzL2Zp
cm13YXJlL2h2bWxvYWRlci9wY2kuYw0KPj4+ICsrKyBiL3Rvb2xzL2Zpcm13YXJlL2h2bWxv
YWRlci9wY2kuYw0KPj4+IEBAIC0zMCw3ICszMCw3IEBADQo+Pj4gICAgI2luY2x1ZGUgPHhl
bi9odm0vZTgyMC5oPg0KPj4+ICAgIHVpbnQzMl90IHBjaV9tZW1fc3RhcnQgPSBIVk1fQkVM
T1dfNEdfTU1JT19TVEFSVDsNCj4+PiAtY29uc3QgdWludDMyX3QgcGNpX21lbV9lbmQgPSBS
RVNFUlZFRF9NRU1CQVNFOw0KPj4+ICt1aW50MzJfdCBwY2lfbWVtX2VuZCA9IFJFU0VSVkVE
X01FTUJBU0U7DQo+Pj4gICAgdWludDY0X3QgcGNpX2hpX21lbV9zdGFydCA9IDAsIHBjaV9o
aV9tZW1fZW5kID0gMDsNCj4+PiAgICAvKg0KPj4+IEBAIC0xMTYsNiArMTE2LDggQEAgdm9p
ZCBwY2lfc2V0dXAodm9pZCkNCj4+PiAgICAgICAgICogZXhwZXJpZW5jZSB0aGUgbWVtb3J5
IHJlbG9jYXRpb24gYnVnIGRlc2NyaWJlZCBiZWxvdy4NCj4+PiAgICAgICAgICovDQo+Pj4g
ICAgICAgIGJvb2wgYWxsb3dfbWVtb3J5X3JlbG9jYXRlID0gMTsNCj4+PiArICAgIC8qIFNl
dCB0aGUgTVRSUiB0eXBlIG9mIHRoZSB4ZW5wY2kgZGV2aWNlIEJBUiBhcyBVQy4gKi8NCj4+
PiArICAgIGJvb2wgeGVucGNpX2Jhcl91YyA9IGZhbHNlOw0KPj4NCj4+IEhtbSwgc2hvdWxk
bid0IHRoaXMgYmUgInRydWUiPyBPciBzaG91bGQgdGhlIGNvbW1lbnQgYmUgY2hhbmdlZD8N
Cj4gDQo+IFRoZSBpbnRlbnRpb24gb2YgdGhlIGNvbW1lbnQgd2FzIHRvIHNpZ25hbCB0aGF0
IHRoaXMgdmFyaWFibGUgaXMgdXNlZA0KPiB0byBzZXQgdGhlIEJBUiBjYWNoZSBhdHRyaWJ1
dGVzIHRvIFVDIHBvc3NpYmx5LCBidXQgSSBjYW4gc2VlIGhvdw0KPiB0aGF0J3MgY29uZnVz
aW5nLiAgV2hhdCBhYm91dCB1c2luZzoNCj4gDQo+ICAgICAgLyogU2VsZWN0IHRoZSBNVFJS
IGNhY2hlIGF0dHJpYnV0ZXMgb2YgdGhlIHhlbnBjaSBkZXZpY2UgQkFSLiAqLw0KPiAgICAg
IGJvb2wgeGVucGNpX2Jhcl91YyA9IGZhbHNlOw0KDQpZZXMsIHRoaXMgaXMgYmV0dGVyLg0K
DQoNCkp1ZXJnZW4NCg==
--------------Z06gGr1EKKSjusfw4MzO0Rik
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-----

--------------Z06gGr1EKKSjusfw4MzO0Rik--

--------------2hoOUZy0L9t4VUxpyzvNnNvy--

--------------MPTUoqGdOkPD9tBToW6z814M
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/Ey8FAmhBWoAFAwAAAAAACgkQsN6d1ii/Ey89
Zgf/X3QP/5lY3zgl2iwpC53Fz1WASf8z8mlBPaHMpknw2ltx38rCIsfzeiLFrANFo9XtO8gzFNvm
7CNZ86PNEl1g1zuCTf1j00l6uMMV7whqjG64eV9sGlbI+0kp01lb+G/+1lXOMI7J8m0OBzJR3d4O
f54uRlDMrv54l0tycvlNiLwrQYuIHK4iQ1gaglyJNFWnbMgQqzBLn92kw0BeIIPW3j+asuPc+xV4
wT5fnOjWp/nGQWT+csXg6co/Q0K+8mNx4Yb/MRY/EA+lm4KWKyons9PYQXaCna5k2n1EWpBrrEBj
tgVSC8d8M02G2+eOzFeVLaHZTIXDohvMvKm9rrIJiw==
=58pF
-----END PGP SIGNATURE-----

--------------MPTUoqGdOkPD9tBToW6z814M--


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 08:58:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 08:58:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006407.1385578 (Exim 4.92)
	(envelope-from )
	id 1uN6Qe-0000IO-M3; Thu, 05 Jun 2025 08:58:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006407.1385578; Thu, 05 Jun 2025 08:58: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 1uN6Qe-0000IH-Gh; Thu, 05 Jun 2025 08:58:28 +0000
Received: by outflank-mailman (input) for mailman id 1006407;
 Thu, 05 Jun 2025 08:58: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 1uN6Qd-0000I9-C6
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 08:58:27 +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 3dd270a6-41eb-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 10:58:26 +0200 (CEST)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-442eb5d143eso6526435e9.0
 for ; Thu, 05 Jun 2025 01:58:26 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-451fb169336sm11528295e9.1.2025.06.05.01.58.24
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 01:58:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3dd270a6-41eb-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749113905; x=1749718705; 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=Nt4eBACnwJZkVG5t0seTp+2K1gNg3NAL9+SCn2oVifs=;
        b=tZ2kzTxM98S6o0VzpNuQq70te+qYD8NhcKn4O0tiNl/Rw1Gv0L9RUAQUY9Dj21pOW+
         hPYJDo4Hv4Y7jWzXLE/+juACivGZPCnODnUFXBhJUDJrfmnKw13xn9qFKX5WV4qNcWXL
         lwnl21gnOkc99rA80/NmKiEf+usC7bEJ+AU0s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749113905; x=1749718705;
        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=Nt4eBACnwJZkVG5t0seTp+2K1gNg3NAL9+SCn2oVifs=;
        b=MF26NO6ycWExwcuIE+lRVkiESYAM8PFZv7abIyUbcxYoI4lUU348AUwcwtN4IIwdvG
         Ydq1rPXzkYBMna4MK7qNzgrTRzV0ctROjSodUOLiJK48pTMSSB5kA+pZypwyG1mrzE5P
         /p+ykcxhzaQazckVR7MILQ/38Enab8yhftq65nfi5H/zhtAeqPoWtl/pVTaN978AG1Vr
         5Pb6Id3Lj54lYfqsePyURZkMPKiqdjXlulybqOvs1mgUYyUljxWBgL+h6/xITlUxd5Ks
         I1DI/HN/uUmho4ln6BQHPxsLm33yPNU6hbvjKqNPB31dQ3EdUBdqaAhjncXpxAsFPCVD
         SS6g==
X-Forwarded-Encrypted: i=1; AJvYcCW047d+hEA/6y9HL28QTCroek+wXe1YgdIWn/wwrjxRLANM4FxqSOXadm9Y6xlbuAK6B7tI5qRbWuo=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxt+GZTTMywu7jG4EbPU8No4GJYe2a8F4Ut6kYQyIlvERJqMWm/
	xeIXfFlwavJ4z9SjD0AEsN3kmUS41CghyTBMvCNtciPlj8a+NbC2a24t1pYKS0eWq5M=
X-Gm-Gg: ASbGncuTX4PlNv+62nqHuwoYa44gQOm2mHXCegQt9yFEa5rVZkB91I8110HlfGKh5iM
	vK+N+vuphdRKOGiIAfd1F9ObNtlOTy2C89Yw1Amywt5JdZAt1aCvRIrFGIs83qX/Fr2wT9qnDU/
	dB5UzJyHEN+ODQLWQyQCZD09k9J2rMu9/3rXGn8ACPVxQI3bWjdv/jvf65GRukBvbCbWaR12lDJ
	4Ecdu+Xoxeks3vJkcvIi3Y/aDaEiUDvhajJXNyR0kFpid0lb6UQ/sG5aToqIeBC5P+zklKWg8OQ
	RPZx9BX2GbyMRDsbvnTYeapLq3BnBdZPoqnTpCquBnyW2NTqF/Z6w1y/XlU8WiyhfQgLOi7WOsy
	org1MknbDG7IrmvfkjUJ1X9LJ5/GPZg==
X-Google-Smtp-Source: AGHT+IFIgcYr+bsCEjJXL9s/tipEDt9f/uTIzV6udUsheXKTyJkmBPLIfJl811SRU583+UXo3NWC/A==
X-Received: by 2002:a05:600c:34c2:b0:43c:f895:cb4e with SMTP id 5b1f17b1804b1-451f0b0c75emr63448235e9.17.1749113905357;
        Thu, 05 Jun 2025 01:58:25 -0700 (PDT)
Date: Thu, 5 Jun 2025 10:58:24 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: dmkhn@proton.me, andrew.cooper3@citrix.com, anthony.perard@vates.tech,
	julien@xen.org, michal.orzel@amd.com, sstabellini@kernel.org,
	teddy.astie@vates.tech, dmukhin@ford.com,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v5 2/2] xen/domain: rewrite emulation_flags_ok()
Message-ID: 
References: <20250602191717.148361-1-dmukhin@ford.com>
 <20250602191717.148361-3-dmukhin@ford.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 

On Wed, Jun 04, 2025 at 12:43:22PM +0200, Jan Beulich wrote:
> On 02.06.2025 21:17, dmkhn@proton.me wrote:
> > From: Denis Mukhin 
> > 
> > Rewrite emulation_flags_ok() to simplify future modifications.
> > 
> > No functional change intended.
> > 
> > Signed-off-by: Denis Mukhin 
> > Reviewed-by: Stefano Stabellini 
> > Reviewed-by: Teddy Astie 
> > ---
> > Changes since v4:
> > - updated commentaries
> > - added Teddy's R-b, kept Stefano's R-b
> > ---
> >  xen/arch/x86/domain.c | 91 ++++++++++++++++++++++++++++++++++---------
> >  1 file changed, 73 insertions(+), 18 deletions(-)
> 
> Given this diffstat, I wonder what the other x86 maintainers think about
> this.

I think the array is a cleaner way of expressing the possible domain
configurations.

See below, I got some suggestions that would likely make the diffstat
better.

> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -743,32 +743,87 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
> >      return 0;
> >  }
> >  
> > +/*
> > + * Verify that the domain's emulation flags resolve to a supported configuration.
> > + *
> > + * This ensures we only allow a known, safe subset of emulation combinations
> > + * (for both functionality and security). Arbitrary mixes are likely to cause
> > + * errors (e.g., null pointer dereferences).
> > + *
> > + * NB: use the internal X86_EMU_XXX symbols, not the public XEN_X86_EMU_XXX
> > + * symbols.
> > + */
> >  static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
> >  {
> > +    enum {
> > +        CAP_PV          = BIT(0, U),
> > +        CAP_HVM         = BIT(1, U),
> > +        CAP_HWDOM       = BIT(2, U),
> > +        CAP_DOMU        = BIT(3, U),
> > +    };
> > +    static const struct {
> > +        unsigned int caps;
> > +        uint32_t min;
> > +        uint32_t opt;
> > +    } configs[] = {
> > +#ifdef CONFIG_PV
> > +        /* PV */
> > +        {
> > +            .caps   = CAP_PV | CAP_DOMU,
> > +            .min    = 0,
> > +            .opt    = 0,
> 
> Why the latter two initializers? Imo adding ones which say nothing else than
> what's the default is only enlarging code without much real benefit.

I'm fine with skipping explicit initialization of 0 fields, I don't
think there's much benefit here.

> > +        },
> > +
> > +        /* PV dom0 */
> > +        {
> > +            .caps   = CAP_PV | CAP_HWDOM,
> > +            .min    = X86_EMU_PIT,
> > +            .opt    = 0,
> > +        },
> > +#endif /* #ifdef CONFIG_PV */

I think the above two elements could be folded into a single one,
iow:

	/* PV domU and dom0 */
        {
            .caps   = CAP_PV
            .min    = X86_EMU_PIT,
        },

As given the current code we do allow PV domUs with X86_EMU_PIT, so
otherwise the change here is not non-functional.

> > +
> > +#ifdef CONFIG_HVM
> > +        /* PVH dom0 */
> > +        {
> > +            .caps   = CAP_HVM | CAP_HWDOM,
> > +            .min    = X86_EMU_LAPIC | X86_EMU_IOAPIC | X86_EMU_VPCI,
> > +            .opt    = 0,
> > +        },
> > +
> > +        /* HVM domU */
> > +        {
> > +            .caps   = CAP_HVM | CAP_DOMU,
> > +            .min    = X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ),
> > +            /* HVM PIRQ feature is user-selectable. */
> > +            .opt    = X86_EMU_USE_PIRQ,
> > +        },
> > +
> > +        /* PVH domU */
> > +        {
> > +            .caps   = CAP_HVM | CAP_DOMU,
> > +            .min    = X86_EMU_LAPIC,
> > +            .opt    = 0,
> > +        },
> > +#endif /* #ifdef CONFIG_HVM */
> > +    };
> > +    unsigned int i, caps = is_hardware_domain(d) ? CAP_HWDOM : CAP_DOMU;
> > +
> > +    if ( is_pv_domain(d) )
> > +        caps |= CAP_PV;
> > +    else if ( is_hvm_domain(d) )
> > +        caps |= CAP_HVM;
> 
> There's no 3rd case, so this could be expressed with plain "else", and hence
> also with a conditional operator, and hence could also be right in the
> initializer. How far to go with those transformations I'm not sure; personally
> I'd go all the way, but I'd be okay-ish with just the first of the steps.

I agree, I would place them all in the definition:

    unsigned int caps = (is_hardware_domain(d) ? CAP_HWDOM : CAP_DOMU) |
                        (is_pv_domain(d) ? CAP_PV : CAP_HVM);

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 08:58:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 08:58:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006409.1385587 (Exim 4.92)
	(envelope-from )
	id 1uN6Qs-0000cO-Qy; Thu, 05 Jun 2025 08:58:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006409.1385587; Thu, 05 Jun 2025 08:58:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uN6Qs-0000cH-Nk; Thu, 05 Jun 2025 08:58:42 +0000
Received: by outflank-mailman (input) for mailman id 1006409;
 Thu, 05 Jun 2025 08:58:40 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uN6Qq-0000aF-Kh
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 08:58:40 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uN6Qq-003VTO-05;
 Thu, 05 Jun 2025 08:58:40 +0000
Received: from [217.65.134.11] (helo=[192.168.101.22])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uN6Qq-00DZdR-03;
 Thu, 05 Jun 2025 08:58: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" 
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=FJQ5NkyhdWLa/O5URtZuwxoIIJqC7lGerPvtwz/vxz4=; b=0jdT8PljFvm4uc4xiLYFj2Mh9j
	m57vAi0YlNetSyLyzNtNwwOKG3SDtabtboywTTWEv4IeLEZASZ7Jv6Ev4JI9n4ANNNnx5fNF9wo12
	ClOVSzH3lLcummMMOM64h4YsrmWVF80GKrzMJawlrByRxs7BNj+U0DJmCYSzYLv3rcSY=;
Message-ID: <0f5a4c32-3631-4a4c-9dd5-ae5385fc984a@xen.org>
Date: Thu, 5 Jun 2025 09:58:36 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/3] arm/mpu: Provide and populate MPU C data
 structures
Content-Language: en-GB
To: "Orzel, Michal" ,
 Ayan Kumar Halder , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250604174311.754899-1-ayan.kumar.halder@amd.com>
 <20250604174311.754899-3-ayan.kumar.halder@amd.com>
 <50c8e74e-95f6-4cea-b979-8b81d7575a21@amd.com>
From: Julien Grall 
In-Reply-To: <50c8e74e-95f6-4cea-b979-8b81d7575a21@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Michal,

On 05/06/2025 08:44, Orzel, Michal wrote:
> 
> 
> On 04/06/2025 19:43, Ayan Kumar Halder wrote:
>> Do the arm32 equivalent initialization for commit id ca5df936c4.
> This is not a good commit msg.
> Also, we somewhat require passing 12 char long IDs.

We are following the same convention as Linux. IIRC this was updated 
because there was some collision with 10 characters in Linux (not sure 
if we have seen it in Xen yet).

[...]

>> diff --git a/xen/arch/arm/include/asm/mpu/regions.inc b/xen/arch/arm/include/asm/mpu/regions.inc
>> index 6b8c233e6c..943bcda346 100644
>> --- a/xen/arch/arm/include/asm/mpu/regions.inc
>> +++ b/xen/arch/arm/include/asm/mpu/regions.inc
>> @@ -24,7 +24,13 @@
>>   #define XEN_MPUMAP_ENTRY_SHIFT  0x3     /* 8 byte structure */
>>   
>>   .macro store_pair reg1, reg2, dst
>> -    .word 0xe7f000f0                    /* unimplemented */
>> +    str \reg1, [\dst]
>> +    add \dst, \dst, #4
>> +    str \reg2, [\dst]
> AFAIR there is STM instruction to do the same

AFAICT, one issue with stm is the ordering is forced by the instruction 
rather than the user. So \reg1 could be stored first.

I think it would be better to use "strd". It still has restriction
(the two registers need to have contiguous index). But I think that 
would be better if we want to reduce the number of instructions.

Cheers,

> 
>> +.endm
>> +
>> +.macro invalidate_dcache_one reg
>> +    mcr CP32(\reg, DCIMVAC)
> Why? You don't seem to use this macro
> 
>>   .endm
>>   
>>   #endif
> 
> ~Michal
> 

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 09:08:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 09:08:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006427.1385598 (Exim 4.92)
	(envelope-from )
	id 1uN6aA-0002aY-MT; Thu, 05 Jun 2025 09:08:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006427.1385598; Thu, 05 Jun 2025 09: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 1uN6aA-0002aR-Ii; Thu, 05 Jun 2025 09:08:18 +0000
Received: by outflank-mailman (input) for mailman id 1006427;
 Thu, 05 Jun 2025 09: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 1uN6aA-0002aJ-4o
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 09:08:18 +0000
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com
 [2a00:1450:4864:20::336])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9bbd48fc-41ec-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 11:08:13 +0200 (CEST)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-450cfb6a794so4434015e9.1
 for ; Thu, 05 Jun 2025 02:08:13 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-451f9924a6esm17429905e9.38.2025.06.05.02.08.11
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 02:08:11 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9bbd48fc-41ec-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749114492; x=1749719292; 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=AoJYmVxtW7cGEG7rMfpyZImktfoY0IXrysF4/eA/RGM=;
        b=PNRrOgfN1sJmFFu6PxyjqrWq5sYN/eg396gOmcYaLiMfk4bNvEaLF4kHk75Q7AybK3
         YpXxwixJgXVDz6Ki8VcqhSoIuDTNoSt/4xviMkIQJqLF4kPyL0Q01ouksZm9ZppH2vE5
         O93HupH1Xig39HHFdHZDYQVtcp6gLNpUlXPa0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749114492; x=1749719292;
        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=AoJYmVxtW7cGEG7rMfpyZImktfoY0IXrysF4/eA/RGM=;
        b=idSXzX4BKPzBrtFWvTf8XTZ3Y8Y2+oI3UGxH6H8g4wPVy6SHDJpHjyMR7ytHd7ZoGg
         HryZHcQalm9jkwkHQvScm2mb4oz9FBv73KyDNs930N1vCWQspyiVkYiCVq7uEaCKXTPt
         DhiGON8AMH+bHMWjioE6WYx3lh916Y0lnEW8KmSjRILuKYRQuNk1bEeVsr+0kOPY6oLa
         oh7hG257bQWfDkcQgpdPOifsBbzqrLhL/pohtlwt1ecXVuE2xCsMYbqJ4rLBlQlaz0u3
         QFMLz8rNo0rCNMMGlL8RrZABLNCicFjoJdRODA9rkbsuXopad/4QvIFCwsU6CYh1eMxH
         tTQQ==
X-Gm-Message-State: AOJu0YyyVKvNEACFJnmDUKPPKM1KUvysLQR9DEaLtUEd0dLyCvDly8rh
	YlDVY3aXkx/0v4sUf01qIvxCJlnYdvXmYsMlBB1pKCSTHM+47jLLJ2u6tVaccSyrxr4=
X-Gm-Gg: ASbGncssS9w3SHfmPCSod/nLe7Qo9QOgc9o5KqNY+olcLK6S8XRXYzgnllaObcgzxNS
	1MhZ87VzwzJnJBfGS2K8CStVfpKKUY1/m2na9eJf4+W+lxSSuupZynyZCjK8DMII3c9lfY7/UHW
	u7c82ARXoN4Dza0qBjbUZ1P8ZSOwsZyT4ebvLvcoX/HAIgDTKQczLaRqEfa+78SlpiNlANnwtO1
	bq5xNds1WP5tCiz9JTLa6J9WdxPoipGUmKEEoAXmrqUDIElyVvk/xdMdwAUK3AmTdc1RiYEygTs
	H7LXUAHcIjhdQnuKMaulO3keaB/CyzcuXR40oHTf8dLoQVlxDUeiQTf/EK+rGzMMkq2Ew0NkEeB
	EoD3Fh1PHDIsvNYVW6RfYVQY1GzifMg==
X-Google-Smtp-Source: AGHT+IEg0DIfzLxM5cKvMgFPiSd02lGWi6OuYsDwuyWUt1JcmS6+6Ik6cigTW4NGlPiwd/a2S1DDpw==
X-Received: by 2002:a05:600c:4446:b0:441:ac58:ead5 with SMTP id 5b1f17b1804b1-451f0b3e164mr63095975e9.31.1749114492322;
        Thu, 05 Jun 2025 02:08:12 -0700 (PDT)
Date: Thu, 5 Jun 2025 11:08:07 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com,
	anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org,
	michal.orzel@amd.com, sstabellini@kernel.org,
	teddy.astie@vates.tech, dmukhin@ford.com
Subject: Re: [PATCH v5 1/2] xen/domain: introduce common hardware emulation
 flags
Message-ID: 
References: <20250602191717.148361-1-dmukhin@ford.com>
 <20250602191717.148361-2-dmukhin@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250602191717.148361-2-dmukhin@ford.com>

On Mon, Jun 02, 2025 at 07:17:30PM +0000, dmkhn@proton.me wrote:
> From: Denis Mukhin 
> 
> Add common emulation_flags for configuring domain emulation features.
> 
> Print d->emulation_flags from 'q' keyhandler for better traceability while
> debugging.
> 
> Signed-off-by: Denis Mukhin 
> Reviewed-by: Stefano Stabellini 
> ---
> Changes since v4:
> - kept Stefano's R-b
> ---
>  xen/arch/x86/domain.c             |  2 +-
>  xen/arch/x86/domctl.c             |  2 +-
>  xen/arch/x86/include/asm/domain.h | 25 +++++++++++--------------
>  xen/common/keyhandler.c           |  1 +
>  xen/include/xen/sched.h           |  2 ++
>  5 files changed, 16 insertions(+), 16 deletions(-)
> 
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index 7536b6c871..0363ccb384 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -831,7 +831,7 @@ int arch_domain_create(struct domain *d,
>                 emflags);
>          return -EOPNOTSUPP;
>      }
> -    d->arch.emulation_flags = emflags;
> +    d->emulation_flags = emflags;
>  
>  #ifdef CONFIG_PV32
>      HYPERVISOR_COMPAT_VIRT_START(d) =
> diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
> index 3044f706de..37d848f683 100644
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -144,7 +144,7 @@ void arch_get_domain_info(const struct domain *d,
>      if ( paging_mode_hap(d) )
>          info->flags |= XEN_DOMINF_hap;
>  
> -    info->arch_config.emulation_flags = d->arch.emulation_flags;
> +    info->arch_config.emulation_flags = d->emulation_flags;
>      info->gpaddr_bits = hap_paddr_bits;
>  }
>  
> diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h
> index 8c0dea12a5..eafd5cfc90 100644
> --- a/xen/arch/x86/include/asm/domain.h
> +++ b/xen/arch/x86/include/asm/domain.h
> @@ -455,9 +455,6 @@ struct arch_domain
>  
>      /* Don't unconditionally inject #GP for unhandled MSRs. */
>      bool msr_relaxed;
> -
> -    /* Emulated devices enabled bitmap. */
> -    uint32_t emulation_flags;
>  } __cacheline_aligned;
>  
>  #ifdef CONFIG_HVM
> @@ -494,17 +491,17 @@ struct arch_domain
>                                   X86_EMU_PIT | X86_EMU_USE_PIRQ |       \
>                                   X86_EMU_VPCI)
>  
> -#define has_vlapic(d)      (!!((d)->arch.emulation_flags & X86_EMU_LAPIC))
> -#define has_vhpet(d)       (!!((d)->arch.emulation_flags & X86_EMU_HPET))
> -#define has_vpm(d)         (!!((d)->arch.emulation_flags & X86_EMU_PM))
> -#define has_vrtc(d)        (!!((d)->arch.emulation_flags & X86_EMU_RTC))
> -#define has_vioapic(d)     (!!((d)->arch.emulation_flags & X86_EMU_IOAPIC))
> -#define has_vpic(d)        (!!((d)->arch.emulation_flags & X86_EMU_PIC))
> -#define has_vvga(d)        (!!((d)->arch.emulation_flags & X86_EMU_VGA))
> -#define has_viommu(d)      (!!((d)->arch.emulation_flags & X86_EMU_IOMMU))
> -#define has_vpit(d)        (!!((d)->arch.emulation_flags & X86_EMU_PIT))
> -#define has_pirq(d)        (!!((d)->arch.emulation_flags & X86_EMU_USE_PIRQ))
> -#define has_vpci(d)        (!!((d)->arch.emulation_flags & X86_EMU_VPCI))
> +#define has_vlapic(d)      (!!((d)->emulation_flags & X86_EMU_LAPIC))
> +#define has_vhpet(d)       (!!((d)->emulation_flags & X86_EMU_HPET))
> +#define has_vpm(d)         (!!((d)->emulation_flags & X86_EMU_PM))
> +#define has_vrtc(d)        (!!((d)->emulation_flags & X86_EMU_RTC))
> +#define has_vioapic(d)     (!!((d)->emulation_flags & X86_EMU_IOAPIC))
> +#define has_vpic(d)        (!!((d)->emulation_flags & X86_EMU_PIC))
> +#define has_vvga(d)        (!!((d)->emulation_flags & X86_EMU_VGA))
> +#define has_viommu(d)      (!!((d)->emulation_flags & X86_EMU_IOMMU))
> +#define has_vpit(d)        (!!((d)->emulation_flags & X86_EMU_PIT))
> +#define has_pirq(d)        (!!((d)->emulation_flags & X86_EMU_USE_PIRQ))
> +#define has_vpci(d)        (!!((d)->emulation_flags & X86_EMU_VPCI))
>  
>  #define gdt_ldt_pt_idx(v) \
>        ((v)->vcpu_id >> (PAGETABLE_ORDER - GDT_LDT_VCPU_SHIFT))
> diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
> index 0bb842ec00..cd731452ba 100644
> --- a/xen/common/keyhandler.c
> +++ b/xen/common/keyhandler.c
> @@ -306,6 +306,7 @@ static void cf_check dump_domains(unsigned char key)
>              if ( test_bit(i, &d->watchdog_inuse_map) )
>                  printk("    watchdog %d expires in %d seconds\n",
>                         i, (u32)((d->watchdog_timer[i].expires - NOW()) >> 30));
> +        printk("    emulation_flags %#x\n", d->emulation_flags);

No strong opinion, but my preference would be to print those as
strings if possible, ie:

printk("    emulation_flags: %s%s%s...(%#x)\n",
       !d->emulation_flags ? "none " : "",
       has_vlapic(d) ? "vlapic " : "",
       has_vhpet(d) ? "hpet " : "",
       ...,
       d->emulation_flags);

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 09:13:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 09:13:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006438.1385607 (Exim 4.92)
	(envelope-from )
	id 1uN6f4-0004Nl-A1; Thu, 05 Jun 2025 09:13:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006438.1385607; Thu, 05 Jun 2025 09: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 1uN6f4-0004Ne-64; Thu, 05 Jun 2025 09:13:22 +0000
Received: by outflank-mailman (input) for mailman id 1006438;
 Thu, 05 Jun 2025 09:13: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 1uN6f3-0004NY-3S
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 09:13:21 +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 520e0146-41ed-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 11:13:19 +0200 (CEST)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-60702d77c60so1314469a12.3
 for ; Thu, 05 Jun 2025 02:13:18 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-60566c5c8easm10102651a12.28.2025.06.05.02.13.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 02:13:17 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 520e0146-41ed-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749114798; x=1749719598; 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=Q0JsC959qErSI4wDcs8b8YtgEgnmGFYLnc2hyiCZdsA=;
        b=IhNMD32qAdH4KRFgCzNRbo4OI46f8YDTcuHSeR7syLWFBW3RB1Wi3pssaZ0V0WNUzx
         s4M++g47pc96TJcCDFY3myX9cEaKjDo71MEFrcaT969u/A/kKR4JvJqpH/vo/gjepSyd
         esy57AquEbD/t6eqibK24fDxETIhw0hTGw61Ge6BIi7ZykPdhgp3aE5Rbr2Ekxfky6He
         9+cwKJac/VWCIg4DvmvwYAdx5HNdYSEPVKHS3+XZoqdXC/oSzvNZBRw03361M6Tn7KB6
         aL3sw6bmrMA64W6lnFO/GGC7T4XogtTueCs6tMkYMHNziRW7MglEqUVMKyphNaYnAIYK
         pKCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749114798; x=1749719598;
        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=Q0JsC959qErSI4wDcs8b8YtgEgnmGFYLnc2hyiCZdsA=;
        b=Fe2TNFkBlLeE0QWH0ksz1+a7/6aiLUTLt+GJ21ELn7BB7GL4NOckdneey4gLhI5dwh
         M73JXFf16Z0AQj9+nmgm/D9fnTzDazunF2e4SPBr6PGTbJQR3Hi8h9NT4SMQLvEiMTUw
         JL8MmWKVikQw0mVujVBRSP11vTgMnq9ZTbXTUWLuFbnCe4t+YNy1TfWcvKftLcUu7YJS
         +GbR37XSYE8R2+akqTpzhoyHooSrqtTV4GQ9UJXVaXqxkqBILyIATESjlZl44p9n+OlT
         7V5P61dix9fEFm2fDLA905DV4bX5DPGtcSAsk6xvBwwHn8CndGkDWvOr9tQwBL4imCKw
         UxcQ==
X-Forwarded-Encrypted: i=1; AJvYcCUpAiFZz9gTmlw+r+9bDOj0UalRg+Ib6H7WlRX7HGIsOBC+y9phjGvhDtV8RyC2aabs+n0S4EnwmzA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyVWp0UbZ8l+et8KI+1tc6jOwfy0RNVWgLi9Y/do++hss8lsZwA
	c7vUK7kgTBs83FBkUEFSaa07cU1qdGH9fVPzHEofPIXrqAw5A/4eDb8/
X-Gm-Gg: ASbGnctYIfsH78h2EWi9ZjHnD5nFpSAxm7fr4hZ2W6xFXL87W7ds8YIOr77XZtObIJb
	ter1pzNOTJsdvrN12WuOloU6rX8WH9y6FKpIR8BSf4JA7K0g5kb8jXSTqtoK9z0Ph1FcEEc8ODE
	hP3hxL5Yy+Z9YtuNkAUUBrkhxvQwEVF2WX7Wg6nrYP+kJ8j6B+8MC2WcJpxF1nRDE79Nj/EXFqH
	coRUZpmUxN2aQrkpE4RBHQGGYF+yHqIyQ6eAor0sPR3HTv2/TjEalMaId8U1VBQGYCxrChxUy9s
	zGSySaJJcoDDS8dMgirUR+C61qI+VcbwB10LKq+sYfRaWx6F9BzLsGJYmBnviFuNkrbTX7iHHbb
	bODbbn/ozxMUhN4Flp2UwUEZ5
X-Google-Smtp-Source: AGHT+IE/JFllc5i0iaaMnM1o1AmiGbqBYC6ZsnAY93zRY19Ooz90SQVRVgT0y7RsAhfk5XXqnBV07g==
X-Received: by 2002:a05:6402:3514:b0:601:f4ff:c637 with SMTP id 4fb4d7f45d1cf-606f0b895famr5756336a12.16.1749114798101;
        Thu, 05 Jun 2025 02:13:18 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------Z6QGQIlZd28t5WlLlbobd876"
Message-ID: 
Date: Thu, 5 Jun 2025 11:13:16 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 08/14] xen/riscv: imsic_init() implementation
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 ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <421dad1bbd014a2d7ff588af088eadbd56345dbe.1747843009.git.oleksii.kurochko@gmail.com>
 
 
 <8cd6c3e0-0361-4f3f-b3ca-8ffa49b9197d@suse.com>
 
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

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


On 6/5/25 8:50 AM, Jan Beulich wrote:
> On 04.06.2025 17:36, Oleksii Kurochko wrote:
>> On 6/2/25 12:21 PM, Jan Beulich wrote:
>>> On 26.05.2025 20:44, Oleksii Kurochko wrote:
>>>> On 5/22/25 4:46 PM, Jan Beulich wrote:
>>>>> On 21.05.2025 18:03, Oleksii Kurochko wrote:
>>>>>> +    /* Check MMIO register sets */
>>>>>> +    for ( unsigned int i = 0; i < nr_mmios; i++ )
>>>>>> +    {
>>>>>> +        if ( !alloc_cpumask_var(&imsic_cfg.mmios[i].cpus) )
>>>>>> +        {
>>>>>> +            rc = -ENOMEM;
>>>>>> +            goto imsic_init_err;
>>>>>> +        }
>>>>>> +
>>>>>> +        rc = dt_device_get_address(node, i, &imsic_cfg.mmios[i].base_addr,
>>>>>> +                                   &imsic_cfg.mmios[i].size);
>>>>>> +        if ( rc )
>>>>>> +        {
>>>>>> +            printk(XENLOG_ERR "%s: unable to parse MMIO regset %u\n",
>>>>>> +                   node->name, i);
>>>>>> +            goto imsic_init_err;
>>>>>> +        }
>>>>>> +
>>>>>> +        base_addr = imsic_cfg.mmios[i].base_addr;
>>>>>> +        base_addr &= ~(BIT(imsic_cfg.guest_index_bits +
>>>>>> +                           imsic_cfg.hart_index_bits +
>>>>>> +                           IMSIC_MMIO_PAGE_SHIFT, UL) - 1);
>>>>>> +        base_addr &= ~((BIT(imsic_cfg.group_index_bits, UL) - 1) <<
>>>>>> +                       imsic_cfg.group_index_shift);
>>>>>> +        if ( base_addr != imsic_cfg.base_addr )
>>>>>> +        {
>>>>>> +            rc = -EINVAL;
>>>>>> +            printk(XENLOG_ERR "%s: address mismatch for regset %u\n",
>>>>>> +                   node->name, i);
>>>>>> +            goto imsic_init_err;
>>>>>> +        }
>>>>> Maybe just for my own understanding: There's no similar check for the
>>>>> sizes to match / be consistent wanted / needed?
>>>> If you are speaking about imsic_cfg.mmios[i].size then it depends fully on h/w will
>>>> provide, IMO.
>>>> So I don't what is possible range for imsic_cfg.mmios[i].size.
>>> Well, all I can say is that's it feels odd that you sanity check base_addr
>>> but permit effectively any size.
>> Okay, I think I have two ideas how to check the size:
>> 1. Based on guest bits from IMSIC's DT node. QEMU calculates a size as:
>>       for (socket = 0; socket < socket_count; socket++) {
>>           imsic_addr = base_addr + socket * VIRT_IMSIC_GROUP_MAX_SIZE;
>>           imsic_size = IMSIC_HART_SIZE(imsic_guest_bits) *
>>                        s->soc[socket].num_harts;
>>       ...
>>      where:
>>        #define IMSIC_MMIO_PAGE_SHIFT          12
>>        #define IMSIC_MMIO_PAGE_SZ             (1UL << IMSIC_MMIO_PAGE_SHIFT)
>>        
>>        #define IMSIC_HART_NUM_GUESTS(__guest_bits)           \
>>                (1U << (__guest_bits))
>>        #define IMSIC_HART_SIZE(__guest_bits)                 \
>>                (IMSIC_HART_NUM_GUESTS(__guest_bits) * IMSIC_MMIO_PAGE_SZ)
>>
>> 2. Just take a theoretical maximum for S-mode IMSIC's node:
>>       16,384 * 64 1(S-mode interrupt file) + 63(max guest interrupt files)) * 4 KiB
>>      Where,
>>        16,384 - maximum possible amount of harts according to AIA spec
>>        64 - a maximum amount of possible interrupt file for S-mode IMSIC node:
>>             1 - S interupt file + 63 guest interrupt files.
>>        4 Kib - a maximum size of one interrupt file.
>>
>> Which option is preferred?
> I would have said 2, if your outline used "actual" rather than "maximum" values.

In option 2 maximum possible values are used. If we want to use "actual" values then
the option 1 should be used. At the moment, I did in the following way that S-mode
IMSIC node, at least, should contain 1 S-mode interrupt file + an amount of guest
interrupts files (based on imsic_cfg.guest_index_bits):

+#define IMSIC_HART_SIZE(guest_bits_) (BIT(guest_bits_, U) * IMSIC_MMIO_PAGE_SZ)
+
  #define IMSIC_DISABLE_EIDELIVERY    0
  #define IMSIC_ENABLE_EIDELIVERY     1
  #define IMSIC_DISABLE_EITHRESHOLD   1
@@ -359,6 +356,10 @@ int __init imsic_init(const struct dt_device_node *node)
      /* Check MMIO register sets */
      for ( unsigned int i = 0; i < nr_mmios; i++ )
      {
+        unsigned int guest_bits = imsic_cfg.guest_index_bits;
+        unsigned long expected_size =
+            IMSIC_HART_SIZE(guest_bits) * nr_parent_irqs;
+
          rc = dt_device_get_address(node, i, &mmios[i].base_addr,
                                     &mmios[i].size);
          if ( rc )
@@ -369,7 +370,7 @@ int __init imsic_init(const struct dt_device_node *node)
          }
  
          base_addr = mmios[i].base_addr;
-        base_addr &= ~(BIT(imsic_cfg.guest_index_bits +
+        base_addr &= ~(BIT(guest_bits +
                             imsic_cfg.hart_index_bits +
                             IMSIC_MMIO_PAGE_SHIFT, UL) - 1);
          base_addr &= ~((BIT(imsic_cfg.group_index_bits, UL) - 1) <<
@@ -381,6 +382,14 @@ int __init imsic_init(const struct dt_device_node *node)
                     node->name, i);
              goto imsic_init_err;
          }
+
+        if ( mmios[i].size != expected_size )
+        {
+            rc = -EINVAL;
+            printk(XENLOG_ERR "%s: IMSIC MMIO size is incorrect %ld, "
+                   "max:%ld\n", node->name, mmios[i].size, max_size);
+            goto imsic_init_err;
+        }
      }

>
>> The specification doesn’t seem to mention (or I couldn’t find) that all platforms
>> must calculate the MMIO size in the same way QEMU does. Therefore, it’s probably
>> better to use the approach described in option 2.
>>
>> On the other hand, I don't think a platform should be considered correct if it
>> provides slightly more than needed but still less than the theoretical maximum.
>>
>>>>>> @@ -18,6 +19,18 @@ static inline unsigned long cpuid_to_hartid(unsigned long cpuid)
>>>>>>         return pcpu_info[cpuid].hart_id;
>>>>>>     }
>>>>>>     
>>>>>> +static inline unsigned long hartid_to_cpuid(unsigned long hartid)
>>>>>> +{
>>>>>> +    for ( unsigned int cpuid = 0; cpuid < ARRAY_SIZE(pcpu_info); cpuid++ )
>>>>>> +    {
>>>>>> +        if ( hartid == cpuid_to_hartid(cpuid) )
>>>>>> +            return cpuid;
>>>>>> +    }
>>>>>> +
>>>>>> +    /* hartid isn't valid for some reason */
>>>>>> +    return NR_CPUS;
>>>>>> +}
>>>>> Considering the values being returned, why's the function's return type
>>>>> "unsigned long"?
>>>> mhartid register has MXLEN length, so theoretically we could have from 0 to MXLEN-1
>>>> Harts and so we could have the same amount of Xen's CPUIDs. and MXLEN is 32 for RV32
>>>> and MXLEN is 64 for RV64.
>>> Yet the return value here is always constrained by NR_CPUS, isn't it?
>> I am not 100% sure that I get your point,
> NR_CPUS is guaranteed to fit in a unsigned int. Furthermore variables / parameters
> holding Xen-internal CPU numbers also are unsigned int everywhere else.

Okay, then agree, hartid_to_cpuid() should return unsigned int. I'll update correspondingly.

Thanks.

~ Oleksii

>
>> but I put NR_CPUS here because of:
>>     /*
>>      * tp points to one of these per cpu.
>>      *
>>      * hart_id would be valid (no matter which value) if its
>>      * processor_id field is valid (less than NR_CPUS).
>>      */
>>     struct pcpu_info pcpu_info[NR_CPUS] = { [0 ... NR_CPUS - 1] = {
>>         .processor_id = NR_CPUS,
>>     }};
>>
>> As an option we could use ULONG_MAX. Would it be better?
> No. NR_CPUS is the appropriate value to use here, imo.
>
> Jan
--------------Z6QGQIlZd28t5WlLlbobd876
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
    
  
  
    

    
    
    
    
    On 6/5/25 8:50 AM, Jan Beulich wrote:
    
    
    
    
    
      
    On 04.06.2025 17:36, Oleksii Kurochko wrote:

    
      
    
        
    On 6/2/25 12:21 PM, Jan Beulich wrote:

    
        
    
          
    On 26.05.2025 20:44, Oleksii Kurochko wrote:

    
          
    
            
    On 5/22/25 4:46 PM, Jan Beulich wrote:

    
            
    
              
    On 21.05.2025 18:03, Oleksii Kurochko wrote:

    
              
    
                
    +    /* Check MMIO register sets */
+    for ( unsigned int i = 0; i < nr_mmios; i++ )
+    {
+        if ( !alloc_cpumask_var(&imsic_cfg.mmios[i].cpus) )
+        {
+            rc = -ENOMEM;
+            goto imsic_init_err;
+        }
+
+        rc = dt_device_get_address(node, i, &imsic_cfg.mmios[i].base_addr,
+                                   &imsic_cfg.mmios[i].size);
+        if ( rc )
+        {
+            printk(XENLOG_ERR "%s: unable to parse MMIO regset %u\n",
+                   node->name, i);
+            goto imsic_init_err;
+        }
+
+        base_addr = imsic_cfg.mmios[i].base_addr;
+        base_addr &= ~(BIT(imsic_cfg.guest_index_bits +
+                           imsic_cfg.hart_index_bits +
+                           IMSIC_MMIO_PAGE_SHIFT, UL) - 1);
+        base_addr &= ~((BIT(imsic_cfg.group_index_bits, UL) - 1) <<
+                       imsic_cfg.group_index_shift);
+        if ( base_addr != imsic_cfg.base_addr )
+        {
+            rc = -EINVAL;
+            printk(XENLOG_ERR "%s: address mismatch for regset %u\n",
+                   node->name, i);
+            goto imsic_init_err;
+        }

    
              
    
              
    Maybe just for my own understanding: There's no similar check for the
sizes to match / be consistent wanted / needed?

    
            
    
            
    If you are speaking about imsic_cfg.mmios[i].size then it depends fully on h/w will
provide, IMO.
So I don't what is possible range for imsic_cfg.mmios[i].size.

    
          
    
          
    Well, all I can say is that's it feels odd that you sanity check base_addr
but permit effectively any size.

    
        
    
        
    Okay, I think I have two ideas how to check the size:
1. Based on guest bits from IMSIC's DT node. QEMU calculates a size as:
     for (socket = 0; socket < socket_count; socket++) {
         imsic_addr = base_addr + socket * VIRT_IMSIC_GROUP_MAX_SIZE;
         imsic_size = IMSIC_HART_SIZE(imsic_guest_bits) *
                      s->soc[socket].num_harts;
     ...
    where:
      #define IMSIC_MMIO_PAGE_SHIFT          12
      #define IMSIC_MMIO_PAGE_SZ             (1UL << IMSIC_MMIO_PAGE_SHIFT)
      
      #define IMSIC_HART_NUM_GUESTS(__guest_bits)           \
              (1U << (__guest_bits))
      #define IMSIC_HART_SIZE(__guest_bits)                 \
              (IMSIC_HART_NUM_GUESTS(__guest_bits) * IMSIC_MMIO_PAGE_SZ)

2. Just take a theoretical maximum for S-mode IMSIC's node:
     16,384 * 64 1(S-mode interrupt file) + 63(max guest interrupt files)) * 4 KiB
    Where,
      16,384 - maximum possible amount of harts according to AIA spec
      64 - a maximum amount of possible interrupt file for S-mode IMSIC node:
           1 - S interupt file + 63 guest interrupt files.
      4 Kib - a maximum size of one interrupt file.

Which option is preferred?

    
      
    
      
    I would have said 2, if your outline used "actual" rather than "maximum" values.
    
    
    
    
    In option 2 maximum possible values are used. If we want to use "actual" values then
the option 1 should be used. At the moment, I did in the following way that S-mode
IMSIC node, at least, should contain 1 S-mode interrupt file + an amount of guest
interrupts files (based on imsic_cfg.guest_index_bits):

+#define IMSIC_HART_SIZE(guest_bits_) (BIT(guest_bits_, U) * IMSIC_MMIO_PAGE_SZ)
+
 #define IMSIC_DISABLE_EIDELIVERY    0
 #define IMSIC_ENABLE_EIDELIVERY     1
 #define IMSIC_DISABLE_EITHRESHOLD   1
@@ -359,6 +356,10 @@ int __init imsic_init(const struct dt_device_node *node)
     /* Check MMIO register sets */
     for ( unsigned int i = 0; i < nr_mmios; i++ )
     {
+        unsigned int guest_bits = imsic_cfg.guest_index_bits;
+        unsigned long expected_size =
+            IMSIC_HART_SIZE(guest_bits) * nr_parent_irqs;
+
         rc = dt_device_get_address(node, i, &mmios[i].base_addr,
                                    &mmios[i].size);
         if ( rc )
@@ -369,7 +370,7 @@ int __init imsic_init(const struct dt_device_node *node)
         }
 
         base_addr = mmios[i].base_addr;
-        base_addr &= ~(BIT(imsic_cfg.guest_index_bits +
+        base_addr &= ~(BIT(guest_bits +
                            imsic_cfg.hart_index_bits +
                            IMSIC_MMIO_PAGE_SHIFT, UL) - 1);
         base_addr &= ~((BIT(imsic_cfg.group_index_bits, UL) - 1) <<
@@ -381,6 +382,14 @@ int __init imsic_init(const struct dt_device_node *node)
                    node->name, i);
             goto imsic_init_err;
         }
+
+        if ( mmios[i].size != expected_size )
+        {
+            rc = -EINVAL;
+            printk(XENLOG_ERR "%s: IMSIC MMIO size is incorrect %ld, "
+                   "max:%ld\n", node->name, mmios[i].size, max_size);
+            goto imsic_init_err;
+        }
     }


    
    
    
      
    

    
      
    
        
    The specification doesn’t seem to mention (or I couldn’t find) that all platforms
must calculate the MMIO size in the same way QEMU does. Therefore, it’s probably
better to use the approach described in option 2.

On the other hand, I don't think a platform should be considered correct if it
provides slightly more than needed but still less than the theoretical maximum.


    
        
    
          
    
          
    
            
    
              
    
                
    @@ -18,6 +19,18 @@ static inline unsigned long cpuid_to_hartid(unsigned long cpuid)
       return pcpu_info[cpuid].hart_id;
   }
   
+static inline unsigned long hartid_to_cpuid(unsigned long hartid)
+{
+    for ( unsigned int cpuid = 0; cpuid < ARRAY_SIZE(pcpu_info); cpuid++ )
+    {
+        if ( hartid == cpuid_to_hartid(cpuid) )
+            return cpuid;
+    }
+
+    /* hartid isn't valid for some reason */
+    return NR_CPUS;
+}

    
              
    
              
    Considering the values being returned, why's the function's return type
"unsigned long"?

    
            
    
            
    mhartid register has MXLEN length, so theoretically we could have from 0 to MXLEN-1
Harts and so we could have the same amount of Xen's CPUIDs. and MXLEN is 32 for RV32
and MXLEN is 64 for RV64.

    
          
    
          
    Yet the return value here is always constrained by NR_CPUS, isn't it?

    
        
    
        
    I am not 100% sure that I get your point,

    
      
    
      
    NR_CPUS is guaranteed to fit in a unsigned int. Furthermore variables / parameters
holding Xen-internal CPU numbers also are unsigned int everywhere else.
    
    
    
    
    Okay, then agree, hartid_to_cpuid() should return unsigned int. I'll update correspondingly.

Thanks.

~ Oleksii

    
    
    
      
    

    
      
    
        
    but I put NR_CPUS here because of:
   /*
    * tp points to one of these per cpu.
    *
    * hart_id would be valid (no matter which value) if its
    * processor_id field is valid (less than NR_CPUS).
    */
   struct pcpu_info pcpu_info[NR_CPUS] = { [0 ... NR_CPUS - 1] = {
       .processor_id = NR_CPUS,
   }};

As an option we could use ULONG_MAX. Would it be better?

    
      
    
      
    No. NR_CPUS is the appropriate value to use here, imo.

Jan

    
    
    
  


--------------Z6QGQIlZd28t5WlLlbobd876--


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 09:14:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 09:14:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006444.1385616 (Exim 4.92)
	(envelope-from )
	id 1uN6gC-0004tv-Jc; Thu, 05 Jun 2025 09:14:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006444.1385616; Thu, 05 Jun 2025 09: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 1uN6gC-0004to-Gb; Thu, 05 Jun 2025 09:14:32 +0000
Received: by outflank-mailman (input) for mailman id 1006444;
 Thu, 05 Jun 2025 09:14:31 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uN6gB-0004te-JQ
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 09:14:31 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uN6gB-003VnE-0L;
 Thu, 05 Jun 2025 09:14:31 +0000
Received: from [15.248.2.232] (helo=[10.24.66.12])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uN6gB-00DoUf-0x;
 Thu, 05 Jun 2025 09:14: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:
	References:Cc:To:From:Subject:MIME-Version:Date:Message-ID;
	bh=yHs7yvUsp9mrQZcPjJeOCF+MWRKJaWK3z/GtDJM7evM=; b=1yRCucmc87sAlu50a6pylh+MCl
	OinXV+S0zdwGvLwUAyLTtSejTKWFhXe2hYSdaU95Qks+r9O9opvlJFn3zmPI4gMX60VD2R/Zg++s8
	NBfFxd4uky4TztjYI/McDW1HXjhKXaa1uMAZudG/qeTFVu/BGE5orRf4R3ENL76X+68k=;
Message-ID: <6307eb1f-1759-4e45-be14-d7d0090b051b@xen.org>
Date: Thu, 5 Jun 2025 10:14:28 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/3] arm/mpu: Provide and populate MPU C data
 structures
Content-Language: en-GB
From: Julien Grall 
To: "Orzel, Michal" ,
 Ayan Kumar Halder , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250604174311.754899-1-ayan.kumar.halder@amd.com>
 <20250604174311.754899-3-ayan.kumar.halder@amd.com>
 <50c8e74e-95f6-4cea-b979-8b81d7575a21@amd.com>
 <0f5a4c32-3631-4a4c-9dd5-ae5385fc984a@xen.org>
In-Reply-To: <0f5a4c32-3631-4a4c-9dd5-ae5385fc984a@xen.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit



On 05/06/2025 09:58, Julien Grall wrote:
> Hi Michal,
> 
> On 05/06/2025 08:44, Orzel, Michal wrote:
>>
>>
>> On 04/06/2025 19:43, Ayan Kumar Halder wrote:
>>> Do the arm32 equivalent initialization for commit id ca5df936c4.
>> This is not a good commit msg.
>> Also, we somewhat require passing 12 char long IDs.
> 
> We are following the same convention as Linux. IIRC this was updated 
> because there was some collision with 10 characters in Linux (not sure 
> if we have seen it in Xen yet).
> 
> [...]
> 
>>> diff --git a/xen/arch/arm/include/asm/mpu/regions.inc b/xen/arch/arm/ 
>>> include/asm/mpu/regions.inc
>>> index 6b8c233e6c..943bcda346 100644
>>> --- a/xen/arch/arm/include/asm/mpu/regions.inc
>>> +++ b/xen/arch/arm/include/asm/mpu/regions.inc
>>> @@ -24,7 +24,13 @@
>>>   #define XEN_MPUMAP_ENTRY_SHIFT  0x3     /* 8 byte structure */
>>>   .macro store_pair reg1, reg2, dst
>>> -    .word 0xe7f000f0                    /* unimplemented */
>>> +    str \reg1, [\dst]
>>> +    add \dst, \dst, #4
>>> +    str \reg2, [\dst]
>> AFAIR there is STM instruction to do the same
> 
> AFAICT, one issue with stm is the ordering is forced by the instruction 
> rather than the user. So \reg1 could be stored first.

Sorry I meant \reg2.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 09:15:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 09:15:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006450.1385627 (Exim 4.92)
	(envelope-from )
	id 1uN6hW-0005QQ-SW; Thu, 05 Jun 2025 09:15:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006450.1385627; Thu, 05 Jun 2025 09:15: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 1uN6hW-0005QJ-Pw; Thu, 05 Jun 2025 09:15:54 +0000
Received: by outflank-mailman (input) for mailman id 1006450;
 Thu, 05 Jun 2025 09:15: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 1uN6hV-0005QB-2h
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 09:15:53 +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 acd820a2-41ed-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 11:15:51 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-450caff6336so4184055e9.3
 for ; Thu, 05 Jun 2025 02:15:51 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-451fb169336sm12113595e9.1.2025.06.05.02.15.49
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 02:15:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: acd820a2-41ed-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749114950; x=1749719750; 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=/qWXu8KxmH1W/UcnnhGyan8SaigjVhFkCwT1GCDGwy4=;
        b=hDP1+RlNToMgcHwwdKpLmKmhArlUQ58bhRG2vo4DrNYxDRIr8aCxCIGYFp9rGyEUQQ
         YStmBV1O9cq8Rzz2R1LD7KvCSkE+oDq3KopYNkbLLeJ7hdyi1zxodihMj0WZyoZ5gQhw
         PXQmyar6a7VLn94kxFwcIQb0uWeLkMGCsilQk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749114950; x=1749719750;
        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=/qWXu8KxmH1W/UcnnhGyan8SaigjVhFkCwT1GCDGwy4=;
        b=Ch2HAkz9fMS5O8oIKirZo2c6JDSRPoWkcfKDXNKyjhGH1m10YmhlfqObYyJbfVPvfb
         aldJoay/PkEksZ35owWRsPzs6mpCDrPHML9D2WTcFmZiJkekWxAaZxNsaRWnIdHs89zu
         +2b4HMzaOS2tGJ7JscQqYdZ/3M+5yo71pCBwWd7l+zzgjr7oLY+eBIhRwXPgtnB83EPd
         aG75PmNy45N02LyEmrNM7Ik1tVL8VEj4DmqXTndEMZw8WEq4y2yQ4/ET4mf3bfWnAzcB
         g/pkme+hC8ZKT1f11PyiuNnkIK6f4pFcnx/DklBHLHstcDEEbUE0OUHBWpEjDK3NRa4y
         zn1w==
X-Gm-Message-State: AOJu0YwJSpQ+gHj5kkxMD/8xO4te5sw9RZK3WclMw3fI0lFPqtWi71cg
	BfOyaNt5dCDBqCGyFvI0oKYmcDSbQQ0msTA36gc7+1tv6RCp1Fo9Dey+1SDkcPb6bKM=
X-Gm-Gg: ASbGncvOOI8KhvPb3zNkhagwZ40iT5gJeuVA7KsTmd0mrjDpFxK9+v1AdAC0rHQgyRg
	vj2USAr9QoVLY8o1cB9QXIQktNE7fbT7AMxhR760g3r3yCrV78oPjxPItATNVMXh6RA65NjWYWj
	fZgPyS7CX3Rt31Y0QUFeZViLhh9UhczwURqfrNkN2CFeeCZ+Gs04oReJeLejF4eM9BfaSH2LzcA
	Fv8a28Qi4+F774ChIoMWho0cy0POoyhlKK1la59k3uK8wGpSlCRaMBKC2lHGL5PKK1Wcui4XpOi
	ivrWrfNzi6ZkV13l6rLaz6rSA1Uerv3LQ8O09fOozhyfG2i0Gv8fG9+NH34uJ7RgPUpULIXszN8
	xx2LQlN2ylTckXuiW89omD+m9vLrYVw==
X-Google-Smtp-Source: AGHT+IEGAAnvRQlGloFHoSSWFR//wPA+q4YDLzSCnzlwrKlI9bjWDKuMIW21rjbMNez/Je79+LBRjA==
X-Received: by 2002:a05:600c:46d1:b0:450:d5f6:55f5 with SMTP id 5b1f17b1804b1-451f0a6a475mr56255465e9.6.1749114950428;
        Thu, 05 Jun 2025 02:15:50 -0700 (PDT)
Date: Thu, 5 Jun 2025 11:15:49 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Oleksii Kurochko 
Cc: xen-devel@lists.xenproject.org,
	Ayan Kumar Halder ,
	Mykyta Poturai ,
	Juergen Gross ,
	Teddy Astie ,
	Bertrand Marquis ,
	Luca Fancellu ,
	Jason Andryuk ,
	Alejandro Vallejo ,
	Sergii Dmytruk ,
	Penny Zheng ,
	Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= ,
	Andrew Cooper , dmkhn@proton.me,
	Mykola Kvach ,
	"Daniel P. Smith" ,
	Grygorii Strashko ,
	Alejandro Vallejo ,
	"committers@xenproject.org" ,
	Community Manager 
Subject: Re: Xen 4.21 Development Update [May]
Message-ID: 
References: <7364a71d-2604-49ca-bab7-d21544d49b10@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <7364a71d-2604-49ca-bab7-d21544d49b10@gmail.com>

On Mon, Jun 02, 2025 at 06:37:46PM +0200, Oleksii Kurochko wrote:
> Hello everyone,
> 
> This email only tracks big items for xen.git tree. Please reply for items
> you
> would like to see in 4.21 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 =
> 
> As there hasn't been any feedback on the proposed timeline shared here:
> https://lore.kernel.org/xen-devel/666e3f49-2f92-4828-8897-8579832bcaa2@gmail.com/T/#u
> 
> We can proceed with the suggested timeline as the release schedule for Xen
> 4.21.
> I've updated the Xen 4.21 Release Notes with this schedule, which can now be
> accessed via the RN link:
>   https://xenbits.xen.org/docs/unstable/support-matrix.html
> 
> = Updates =
> 
> The following items ( the links for them could be found int the list below )
> were moved to completed:
>   [since May 6 - Jun2]:
>     * Hypervisor:
>       - tools: remove qemu-traditional
>     * Arm:
>       - PCI devices passthrough on Arm, part 3
>     * x86:
>       - xen: cache control improvements
>   [since 4.20 relese - May 6]:
>     * Hypervisor:
>       - Move parts of Arm's Dom0less to common code
>       - remove libxenctrl usage from xenstored
>     * Arm:
>       - Enable early bootup of Armv8-R AArch32 systems
>     * x86:
>       - x86/HVM: emulation (MMIO) improvements
>     * RISC-V:
>       - RISC-V some preinit calls.
>       - Fixes for UBSAN & GCOV support for RISC-V.
> 
> Some new items added:
>  [since May]
>     * x86:
>      - Allow x86 to unflatten DTs
>      - hyperlaunch: move remaining pvh dom0 construction
>      - x86/hyperlaunch: introduce concept of core domains
>      - Confidential computing and AMD SEV support
>     * Arm:
>      - SMMU handling for PCIe Passthrough on ARM
>      - xen/arm: scmi: introduce SCI SCMI SMC multi-agent support
>      - Add initial Xen Suspend-to-RAM support on ARM64
>     * RISC-V:
>      - introduce p2m functionality
>  [since 4.20 release]
>     * Hypervisor:
>       - tools: remove qemu-traditional
>       - Physical address hypercall ABI ("HVMv2")
>       - xen: Untangle mm.h
>       - xen: introduce CONFIG_SYSCTL
>       - Add support for exact-node memory claims
>       - Several CI cleanups and improvements, plus yet another new runner
>     * x86:
>       - x86/EFI: prevent write-execute sections
>       - x86: Trenchboot Secure Launch DRTM (Xen)
>       - Hyperlaunch device tree for dom0 (v6)
>       - amd-cppc CPU Performance Scaling Driver (v4)
>       - Hyperlaunch domain builder
>       - kexec: add kexec support to Mini-OS
>       - xen: cache control improvements (should be moved to "Hypervisor"?)
>       - x86: generate xen.efi image with no write-execute sections
>       - x86/asm: cleanups after toolchain baseline upgrade
>     * Arm:
>       - Add support for R-Car Gen4 PCI host controller (v4)
>       - FF-A VM to VM support (v5)
>       - First chunk for Arm R82 and MPU support (v4)
>       - ARM split hardware and control domains (v5)
>       - MPU mm subsistem skeleton
>     * RISC-V:
>       - introduce basic UART support and interrupts for hypervisor mode
> 
> * Full list of items : *
> 
> = Projects =
> 
> == Hypervisor ==
> 
> * xen/console: cleanup console input switch logic (v1 -> v5)
>   - Denis Mukhin
>   -
> https://lore.kernel.org/xen-devel/20250530231841.73386-1-dmukhin@ford.com/
>   - https://patchew.org/Xen/20250530231841.73386-1-dmukhin@ford.com/
> 
> * xen: introduce CONFIG_SYSCTL (v3 -> v4)
>   -  Penny Zheng
>   - https://lore.kernel.org/xen-devel/20250528091708.390767-1-Penny.Zheng@amd.com/
>   - https://patchew.org/Xen/20250528091708.390767-1-Penny.Zheng@amd.com/
> 
> * Physical address hypercall ABI ("HVMv2")
>   - Teddy Astie
>   - https://lore.kernel.org/xen-devel/cover.1744981654.git.teddy.astie@vates.tech/
> 
> * xen: Untangle mm.h
>   -  Andrew Cooper
>   - https://lore.kernel.org/xen-devel/20250312174513.4075066-1-andrew.cooper3@citrix.com/
>   -
> https://patchew.org/Xen/20250312174513.4075066-1-andrew.cooper3@citrix.com/
> 
> * Add support for exact-node memory claims
>   -  Alejandro Vallejo
>   - https://lore.kernel.org/xen-devel/20250314172502.53498-1-alejandro.vallejo@cloud.com/
>   -
> https://patchew.org/Xen/20250314172502.53498-1-alejandro.vallejo@cloud.com/
> 
> * Several CI cleanups and improvements, plus yet another new runner
>   - Marek Marczykowski-Górecki
>   - https://lore.kernel.org/xen-devel/cover.7da1777882774486a13e6f39ff4a2096f6b7901e.1744028549.git-series.marmarek@invisiblethingslab.com/
>   - https://patchew.org/Xen/cover.7da1777882774486a13e6f39ff4a2096f6b7901e.1744028549.git-series.marmarek@invisiblethingslab.com/
> 
> *  Remove the directmap (v5)
>   -  Alejandro Vallejo
>   - https://lore.kernel.org/xen-devel/20250108151822.16030-1-alejandro.vallejo@cloud.com/
>   -
> https://patchew.org/Xen/20250108151822.16030-1-alejandro.vallejo@cloud.com/

Since you keep track of the directmap removal, you might also add the
other ASI related series:

https://lore.kernel.org/xen-devel/20250108142659.99490-1-roger.pau@citrix.com/

I very much doubt I will have time to work on this before the next
release.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 09:42:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 09:42:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006467.1385636 (Exim 4.92)
	(envelope-from )
	id 1uN772-0001HT-0M; Thu, 05 Jun 2025 09:42:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006467.1385636; Thu, 05 Jun 2025 09:42:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uN771-0001HM-U6; Thu, 05 Jun 2025 09:42:15 +0000
Received: by outflank-mailman (input) for mailman id 1006467;
 Thu, 05 Jun 2025 09:42: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 1uN771-0001HG-85
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 09:42:15 +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 5c208084-41f1-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 11:42:13 +0200 (CEST)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-43cfe63c592so8440815e9.2
 for ; Thu, 05 Jun 2025 02:42:13 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-235eaa077f6sm17109175ad.5.2025.06.05.02.42.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 02:42:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5c208084-41f1-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749116533; x=1749721333; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ntSLMx1nUW8tpL1OqL7zyGH1j/TNe629bJ4/b5U60So=;
        b=F72rdsA2kl6zh3x5MaN7Nk7g0Ad0k0OLcIO1k0GIgO8JpEjp3EDek2rJBdRmu0pw0e
         x1cNK1XfgkrSeyV0mDv67Nt9PqCI8En1+e5YJhPOjLbSU4UaJORmrNdJnGXRYNI3GD7V
         EU1wTyYg3t7dqoyxKZ+2XhgI6pX8bo5CjyeEENuIU5VksqILjReQFlkYcoH7QBkY10yU
         T0lJE6gpexH+DkGip8THVBRaY1cwPP+jABdZEPtSE5v9zDLAR3VjVnxXYw+ZRDQIrDU1
         Qp3SJ33SS1c1xrwD5LJm5DDUKh1W6IFJ7URKjF1U54FsunJiIe8DVCf4h04lIzAlwt+v
         fLaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749116533; x=1749721333;
        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=ntSLMx1nUW8tpL1OqL7zyGH1j/TNe629bJ4/b5U60So=;
        b=nfascjF14ttvm795Sl+laG0itW4oQ5MU+RkT7J4I/2oTQoVbVbU8irqFc9YD0JOVRu
         7u2J0kquY6nVqYfU4H9gJgODno7hEcYaG8e7QxEW+yWQfwmEJoP6UPARsv0GHd9r4rFf
         fplB60YMxryc6EeOFV4RsUZRVTW+D6ikN3xE3RSjqfcahaY1i3vLfJfxzE5u27JiAd21
         tlrAOQR6ANP882Lm8MsWt0YHT4HVMGo+Zn4foQ/ZhmZoY2kORG7aDUk2Oah9aSUZys4a
         1RYiMsqRAY0Ihd+xvfK93ijEKIjkB2KOYv9rXhBAQAMSMjCnx2ZF1+TIk8kI0jbw+cKy
         3ANg==
X-Forwarded-Encrypted: i=1; AJvYcCWIkkn0ZjjSwvN5oA5rE0R1DzyfxN28jSqjWWzdZrzQuRYWtO6nMgEhEU2XdBFBgbpqX3yeIIMN/0k=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzsKNP5ye04/cqu3AVbM51xGznEW985SGrSsTJHi44zNnwzFKzE
	LBItrvXz+VstPR1k1XHlLMmWIcPHp+/lTrGJvGVkLKij+qLbft5nBKJlkbgTIHcGvw==
X-Gm-Gg: ASbGnctdP4jhkB9AwFk8IhnNAbO/jileaZbLlhjYWLQBBaIjABE2Ho1RJzm4QerLUM9
	N+9sneerkA6JdE2utVUC8x5idxECJm91Ks4Up9g08E80Fi99P4hxg74BfJ+/oQ+VzBpRFz8HfHY
	aJNC3Os3zBcB+GalL/eKOLfrpO7AtVYGpecjrZqZD8aN20EzNnIaJnCDRCyynulta9THwmUngGK
	zj53MGbYJz/0n6Z7mgFr41RVpC+OEKs6ii1ND/fi/mQQF7YTdXLDcBFWYcYAbB4+P7bVir51GUt
	RtlgD91bVtCleKgNU4nJOe/xu7bcAKLsqjTu7VZ8oxgG0Nkbk/QuFHQfdraulcaNp8Bm6EmS0ow
	XnOGAyTqOa6djnRAdvfT9NV18eWD4W31ARM6t
X-Google-Smtp-Source: AGHT+IHht2zlEwR0EvyXqPNpZXtPJCLw1XL5ERnbZ2v2wxMXB3Pqo/kFWcG0GtFQJII5ofUVb+HpuQ==
X-Received: by 2002:a05:6000:2888:b0:3a4:efc0:c90b with SMTP id ffacd0b85a97d-3a51d90470emr5526554f8f.15.1749116533143;
        Thu, 05 Jun 2025 02:42:13 -0700 (PDT)
Message-ID: <2de0a33e-75ff-449c-a0db-6a2279b9e484@suse.com>
Date: Thu, 5 Jun 2025 11:42:01 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 08/14] xen/riscv: imsic_init() implementation
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 ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <421dad1bbd014a2d7ff588af088eadbd56345dbe.1747843009.git.oleksii.kurochko@gmail.com>
 
 
 <8cd6c3e0-0361-4f3f-b3ca-8ffa49b9197d@suse.com>
 
 
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 05.06.2025 11:13, Oleksii Kurochko wrote:
> 
> On 6/5/25 8:50 AM, Jan Beulich wrote:
>> On 04.06.2025 17:36, Oleksii Kurochko wrote:
>>> On 6/2/25 12:21 PM, Jan Beulich wrote:
>>>> On 26.05.2025 20:44, Oleksii Kurochko wrote:
>>>>> On 5/22/25 4:46 PM, Jan Beulich wrote:
>>>>>> On 21.05.2025 18:03, Oleksii Kurochko wrote:
>>>>>>> +    /* Check MMIO register sets */
>>>>>>> +    for ( unsigned int i = 0; i < nr_mmios; i++ )
>>>>>>> +    {
>>>>>>> +        if ( !alloc_cpumask_var(&imsic_cfg.mmios[i].cpus) )
>>>>>>> +        {
>>>>>>> +            rc = -ENOMEM;
>>>>>>> +            goto imsic_init_err;
>>>>>>> +        }
>>>>>>> +
>>>>>>> +        rc = dt_device_get_address(node, i, &imsic_cfg.mmios[i].base_addr,
>>>>>>> +                                   &imsic_cfg.mmios[i].size);
>>>>>>> +        if ( rc )
>>>>>>> +        {
>>>>>>> +            printk(XENLOG_ERR "%s: unable to parse MMIO regset %u\n",
>>>>>>> +                   node->name, i);
>>>>>>> +            goto imsic_init_err;
>>>>>>> +        }
>>>>>>> +
>>>>>>> +        base_addr = imsic_cfg.mmios[i].base_addr;
>>>>>>> +        base_addr &= ~(BIT(imsic_cfg.guest_index_bits +
>>>>>>> +                           imsic_cfg.hart_index_bits +
>>>>>>> +                           IMSIC_MMIO_PAGE_SHIFT, UL) - 1);
>>>>>>> +        base_addr &= ~((BIT(imsic_cfg.group_index_bits, UL) - 1) <<
>>>>>>> +                       imsic_cfg.group_index_shift);
>>>>>>> +        if ( base_addr != imsic_cfg.base_addr )
>>>>>>> +        {
>>>>>>> +            rc = -EINVAL;
>>>>>>> +            printk(XENLOG_ERR "%s: address mismatch for regset %u\n",
>>>>>>> +                   node->name, i);
>>>>>>> +            goto imsic_init_err;
>>>>>>> +        }
>>>>>> Maybe just for my own understanding: There's no similar check for the
>>>>>> sizes to match / be consistent wanted / needed?
>>>>> If you are speaking about imsic_cfg.mmios[i].size then it depends fully on h/w will
>>>>> provide, IMO.
>>>>> So I don't what is possible range for imsic_cfg.mmios[i].size.
>>>> Well, all I can say is that's it feels odd that you sanity check base_addr
>>>> but permit effectively any size.
>>> Okay, I think I have two ideas how to check the size:
>>> 1. Based on guest bits from IMSIC's DT node. QEMU calculates a size as:
>>>       for (socket = 0; socket < socket_count; socket++) {
>>>           imsic_addr = base_addr + socket * VIRT_IMSIC_GROUP_MAX_SIZE;
>>>           imsic_size = IMSIC_HART_SIZE(imsic_guest_bits) *
>>>                        s->soc[socket].num_harts;
>>>       ...
>>>      where:
>>>        #define IMSIC_MMIO_PAGE_SHIFT          12
>>>        #define IMSIC_MMIO_PAGE_SZ             (1UL << IMSIC_MMIO_PAGE_SHIFT)
>>>        
>>>        #define IMSIC_HART_NUM_GUESTS(__guest_bits)           \
>>>                (1U << (__guest_bits))
>>>        #define IMSIC_HART_SIZE(__guest_bits)                 \
>>>                (IMSIC_HART_NUM_GUESTS(__guest_bits) * IMSIC_MMIO_PAGE_SZ)
>>>
>>> 2. Just take a theoretical maximum for S-mode IMSIC's node:
>>>       16,384 * 64 1(S-mode interrupt file) + 63(max guest interrupt files)) * 4 KiB
>>>      Where,
>>>        16,384 - maximum possible amount of harts according to AIA spec
>>>        64 - a maximum amount of possible interrupt file for S-mode IMSIC node:
>>>             1 - S interupt file + 63 guest interrupt files.
>>>        4 Kib - a maximum size of one interrupt file.
>>>
>>> Which option is preferred?
>> I would have said 2, if your outline used "actual" rather than "maximum" values.
> 
> In option 2 maximum possible values are used. If we want to use "actual" values then
> the option 1 should be used.

Actually I was wrong with request "actual" uniformly. It's only the hart count where
I meant to ask for that. For interrupts we should allow the maximum possible unless
we already know their count.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 09:47:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 09:47:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006476.1385646 (Exim 4.92)
	(envelope-from )
	id 1uN7Bm-0001w0-Hy; Thu, 05 Jun 2025 09:47:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006476.1385646; Thu, 05 Jun 2025 09:47:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uN7Bm-0001vt-F7; Thu, 05 Jun 2025 09:47:10 +0000
Received: by outflank-mailman (input) for mailman id 1006476;
 Thu, 05 Jun 2025 09:47:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uN7Bk-0001vW-QH
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 09:47:08 +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 0afef5e2-41f2-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 11:47:07 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-450ce3a2dd5so6609585e9.3
 for ; Thu, 05 Jun 2025 02:47:07 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a5298a2c1esm1213479f8f.5.2025.06.05.02.47.05
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 02:47:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0afef5e2-41f2-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749116826; x=1749721626; 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=vfvPJ9Bsvm5B2vE0nOnqbArtmZ4FsoRPawu6lXG5IDk=;
        b=WyXrrNIGvkVtulGwytif/hrZ7u+P3sWueO3ia9v6/txSYPvPE9brpFzy9E0DFWV6kX
         bNvP2315HM6jl8QFMI97qCLYwgA5vqbYEl36SGeTQZaZRRxfHlSi7U/3ug01gshTgMSx
         /cNMkV5BGqGVjfkJOjXTeFc47W/P61ynHnMJc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749116826; x=1749721626;
        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=vfvPJ9Bsvm5B2vE0nOnqbArtmZ4FsoRPawu6lXG5IDk=;
        b=wUS+9QufXE779odC/wjPoc6KtNRHk/ZXUiBDUQnQi75jOIHUluUGbDn9V6v29Z6lyr
         eDx/prS36iioXW/mKr/ARB3oLO5Wd29cArAx9QpaHEzo3SNPD/a8CLXDXY5lp5Y6CLJ0
         kDrWa9CvLrnPYvZ0znhHDQvKUBoHA64uHjlMES0dQ/PSkywSJCVNbdtmm99YZKWVOiGU
         aBY2SwZys/+jXRYsqzJD5wuvmyUdjn+pMZbdpec8j7VlcrXBiXhCO8HkaQXEhmxJH4Zt
         TECtsoKmGVaQb7S3MGSo7fL93mURu/qy42KvfECK2mB9UDmpYinbDbQsQ4znjTMmiM6/
         ob7A==
X-Gm-Message-State: AOJu0YygZpmHuZKqfud2ueBZtuccPn853nEtkRvwuC3JdMbXhtCs2wtb
	A3sEFhQFAU3qdKHHOInOLHFPtisKYgPwic5Jc5H4Cg+pY1g4Dw0poKAtvU38GmGj1tc=
X-Gm-Gg: ASbGncuFzqvVvQj5I35J109VrtQXNauS430gPsWzyFU4ati1x46dcJfVq2KcscheuF7
	q2XWxZzllpiEi9DllDc3FgnoecGMcoTDxMyBMw2OW0t3DQYdC+8eW+9n8iYKHxd240dAkYvnoZm
	IJ1bHuRVqE88x8XxTFaPRKJP1o5D/6VgAuttLzX9berfqoyaMCjJ5wVVoRddZe0mThlLnrYpT0I
	UQSmL263rg0pTbZjYT7HWDPLbA9rTLI8gawjj6qnTsspHCamoqRPXsVmbcqG804e+r3EbpiDGsA
	PAFNyjCZJ3fd+LrmjzmhbYeWzdG7ln5dhxHoRejsCkrMb3SZtrArEAptwA6QGaBXEO1ZjwhpVjl
	pCTcBrhqtqP7CyEgw7ZIsiIyM
X-Google-Smtp-Source: AGHT+IGAz5kwk+3PxUqTKML4pa957O7B6QvAB/51wR6XQCw64cvT940XOxaiaFZLo4xT4TttjXniLw==
X-Received: by 2002:a05:6000:2207:b0:3a4:eb92:39b6 with SMTP id ffacd0b85a97d-3a51d98e836mr5244419f8f.54.1749116826480;
        Thu, 05 Jun 2025 02:47:06 -0700 (PDT)
Date: Thu, 5 Jun 2025 11:47:05 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Stewart Hildebrand 
Cc: xen-devel@lists.xenproject.org
Subject: Re: [PATCH v1 1/5] vpci: const-ify some pdev instances
Message-ID: 
References: <20250531125405.268984-1-stewart.hildebrand@amd.com>
 <20250531125405.268984-2-stewart.hildebrand@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250531125405.268984-2-stewart.hildebrand@amd.com>

On Sat, May 31, 2025 at 08:53:59AM -0400, Stewart Hildebrand wrote:
> Since 622bdd962822 ("vpci/header: handle p2m range sets per BAR"), a
> non-const pdev is no longer needed for error handling in
> vpci_process_pending(). Const-ify pdev in vpci_process_pending(),
> defer_map(), and struct vpci_vcpu.
> 
> Get rid of const-removal workaround in modify_bars().
> 
> Take the opportunity to remove an unused parameter in defer_map().
> 
> Signed-off-by: Stewart Hildebrand 

Reviewed-by: Roger Pau Monné 

One further simplification below.

> ---
> This is prerequisite for ("vpci: use separate rangeset for BAR
> unmapping") in order to call defer_map() with a const pdev.
> ---
>  xen/drivers/vpci/header.c | 16 ++++------------
>  xen/include/xen/vpci.h    |  2 +-
>  2 files changed, 5 insertions(+), 13 deletions(-)
> 
> diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
> index 1f48f2aac64e..e42c8efa2302 100644
> --- a/xen/drivers/vpci/header.c
> +++ b/xen/drivers/vpci/header.c
> @@ -175,7 +175,7 @@ static void modify_decoding(const struct pci_dev *pdev, uint16_t cmd,
>  
>  bool vpci_process_pending(struct vcpu *v)
>  {
> -    struct pci_dev *pdev = v->vpci.pdev;
> +    const struct pci_dev *pdev = v->vpci.pdev;
>      struct vpci_header *header = NULL;
>      unsigned int i;
>  
> @@ -283,8 +283,7 @@ static int __init apply_map(struct domain *d, const struct pci_dev *pdev,
>      return rc;
>  }
>  
> -static void defer_map(struct domain *d, struct pci_dev *pdev,
> -                      uint16_t cmd, bool rom_only)
> +static void defer_map(const struct pci_dev *pdev, uint16_t cmd, bool rom_only)
>  {
>      struct vcpu *curr = current;
>  
> @@ -308,7 +307,7 @@ static void defer_map(struct domain *d, struct pci_dev *pdev,
>  static int modify_bars(const struct pci_dev *pdev, uint16_t cmd, bool rom_only)
>  {
>      struct vpci_header *header = &pdev->vpci->header;
> -    struct pci_dev *tmp, *dev = NULL;
> +    struct pci_dev *tmp;
>      const struct domain *d;
>      const struct vpci_msix *msix = pdev->vpci->msix;
>      unsigned int i, j;
> @@ -450,11 +449,6 @@ static int modify_bars(const struct pci_dev *pdev, uint16_t cmd, bool rom_only)
>  
>              if ( tmp == pdev )
>              {
> -                /*
> -                 * Need to store the device so it's not constified and defer_map
> -                 * can modify it in case of error.
> -                 */
> -                dev = tmp;
>                  if ( !rom_only )

You can now join this with the previous if, and reduce one level of
indentation:

if ( tmp == pdev && !rom_only )
    /* comment text */
    continue;

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 09:53:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 09:53:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006482.1385656 (Exim 4.92)
	(envelope-from )
	id 1uN7Ha-0003aR-4s; Thu, 05 Jun 2025 09:53:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006482.1385656; Thu, 05 Jun 2025 09:53:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uN7Ha-0003aK-2F; Thu, 05 Jun 2025 09:53:10 +0000
Received: by outflank-mailman (input) for mailman id 1006482;
 Thu, 05 Jun 2025 09:53: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 1uN7HY-0003aE-Jb
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 09:53:08 +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 e1d0aa6d-41f2-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 11:53:07 +0200 (CEST)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-450d37d4699so4457635e9.0
 for ; Thu, 05 Jun 2025 02:53:07 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-451f990cf14sm19261945e9.25.2025.06.05.02.53.06
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 02:53:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e1d0aa6d-41f2-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749117187; x=1749721987; 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=/mCIEOe+99EBm3J56KANgiQehCzEa9feY9OP5XC5xeE=;
        b=URsbV5Jy3ALQ2GsZfgLI9RzrtQ7nVI1z2NPngwg3AWAd4qbMKfiPyeDRklCCimEolB
         SlDf1u9tsL0xvy7leHTON8kf/ePhhMBxjPWoRY+GqJjhmd8JCSHRm1ooYLaYgfxFqkj3
         cZfSUzNo+BclD/uWuxzvKng59aVfdevRYhL6k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749117187; x=1749721987;
        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=/mCIEOe+99EBm3J56KANgiQehCzEa9feY9OP5XC5xeE=;
        b=bYha/0hST9cvfKiagZuGyvymjcKHYR3ex6/CAXussV4IWr1d/GkzzDBr6+NhFwF1kl
         iySn+/+jvd2vEFFu+0TYQe7iOAGgt9VBmjaFlcGNh+D2Q9Fiug3yUdMB093+8StQCtm2
         /GOIQFUHw771aP8TI+h/ln7ZgC0yuGbESFA9EV2tM3ItNWGWx2B4w6WnirEpm6QHhXNm
         S3T/A8Ujx8TSLmW4P0ZbdBTEoMWhSOhOoVr6mgzMd66zJx8WBTOhh95LMbgfVunFr5Qx
         N8SjrxDHR5WJGzfOeLmcpsrAG9+EllpqxJha6x8My+20/r3Kp+CbRn3tTTbktGCLaR3g
         Znhg==
X-Gm-Message-State: AOJu0YwYzv+I7lS2d1WdV00JTG7IP8YG6kBH4Nc340ukErdKLi4ZEa8p
	ykBEwGYONZRNnpMhl6OBvkFjNfA/Ijqe+zGuJCg2wfL+7/9kEDlYjZSMyUC2A+HaTdA=
X-Gm-Gg: ASbGncuwS/p92+ngyePFKYeBY+JXaq0uil35Dx4FeMPqlKIt5JzLsuEHyofv1+hMRqN
	OnLsH5HXkZnpxzwNaTmK3GjKtdw9yXIujcQdpstzX1SVn6j/RBaAdLRWvPM7tolpyJgjiiIUr3u
	pOKgGwTRBOLbuNdu3Do5jX+FjIGCFyHKAHVZSy+xt5gC/yoVCQQSqErTLhDw8UMlO4JrVoZmcdc
	X4SIwKSNAUsJsEBFLXJXxbPUTgPDUOmgfsf/CIhoPJj4zhI62lubEMj/hTLhvl4W3Tde3IExToj
	Y+ZebxQYb0dO3hBW0tQG2KQFWUi4VmkSICslDXSF/X+J+mmglUebypvf28sRP4KI1dfdD+Jgrg0
	niYeRs+rVWj023nzcT9Vu+0Ig
X-Google-Smtp-Source: AGHT+IEyfelTcYbH/SsNwWATuIN0KgUNEr/rax+fv89GQzNHgpgRc/4oKuAdqEil1SE1CxyA8CRIbw==
X-Received: by 2002:a05:600c:c4aa:b0:44b:eb56:1d48 with SMTP id 5b1f17b1804b1-451f2d05ce2mr56012105e9.4.1749117187003;
        Thu, 05 Jun 2025 02:53:07 -0700 (PDT)
Date: Thu, 5 Jun 2025 11:53:05 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Stewart Hildebrand 
Cc: xen-devel@lists.xenproject.org
Subject: Re: [PATCH v1 2/5] vpci: rework error path in vpci_process_pending()
Message-ID: 
References: <20250531125405.268984-1-stewart.hildebrand@amd.com>
 <20250531125405.268984-3-stewart.hildebrand@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250531125405.268984-3-stewart.hildebrand@amd.com>

On Sat, May 31, 2025 at 08:54:00AM -0400, Stewart Hildebrand wrote:
> This will make further refactoring simpler.

I think you want to add:

No functional change intended.

To the commit message.

> Signed-off-by: Stewart Hildebrand 

Acked-by: Roger Pau Monné 

The success and error paths have some shared code, that might be good
to unify, but that requires further rework.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 10:10:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 10:10:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006494.1385668 (Exim 4.92)
	(envelope-from )
	id 1uN7YA-0006jO-Gi; Thu, 05 Jun 2025 10:10:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006494.1385668; Thu, 05 Jun 2025 10:10:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uN7YA-0006jH-Cl; Thu, 05 Jun 2025 10:10:18 +0000
Received: by outflank-mailman (input) for mailman id 1006494;
 Thu, 05 Jun 2025 10:10: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 1uN7Y9-0006jB-73
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 10:10:17 +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 43e3cc47-41f5-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 12:10:11 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3a4f78ebec8so448798f8f.0
 for ; Thu, 05 Jun 2025 03:10:11 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b2eceb029fbsm10019616a12.13.2025.06.05.03.10.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 03:10:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 43e3cc47-41f5-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749118210; x=1749723010; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Hyb8pyb5E0pGicxrf2oKxF8Vsob7n2tNZHEM8CYsMIo=;
        b=YC8BPOMJP1jxrFxCw0yr3J3ELGzmEkLglYfRH2RZgkuZg3RD1BIXRKmJ2Fuiq99k/0
         NosKZv2PwGRqhSXF/UzHd9Vhhlz/qwanI9MAoNjPFCKhtY72uxT5858YRW30UZ7vFHWh
         Ji/QU2qxhQvl6Oj3ava8aeN6OwllJ94dhqLQazj9lahX4nYfgx+gloZFfaTPORKACFC+
         6UHnALqZTU9cWimc0Eb3kDWl6USe8/eaM+VtbUyM6MsJyfSPMIKlR1EHoPuGPp4jxWNB
         BlXrHgUg6AV6StLcTWxpxN4IFxQjjYwJSxEYaItUHdwXlhhTCZOCXef4UnLTin4s4IAw
         zK1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749118210; x=1749723010;
        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=Hyb8pyb5E0pGicxrf2oKxF8Vsob7n2tNZHEM8CYsMIo=;
        b=af+5gugM8pS4crHfwVuqAZvO6o1sGiSxIxZnlrZuNwL8RcMs+hOFk7t+OY3v0OW4ku
         o2yok98G7AX+67EFCmcY5oHnzLsDHPXqiLtzF1EBz2WLhWsK1qgmJCURSBV+cV5yAevf
         jeMnLzlnIaLElAJFDKbjm9CGX+Iy6KLtS8d2AYkoKRoYiM2zSMBrhQ9+4QfLLl2o2RST
         tQJX7dRpTmeF5t7UAicJtqnQ4G8+5OuaBrEwNHxF+0SPxuvDwTOthTFFamjARxTblUy0
         xTxdQRcq0W917AZfaGAb52zNPCs+jPDKC1idRRJC9xFvRodBb3YEHvaIXHN4vp4McIyq
         pR/A==
X-Forwarded-Encrypted: i=1; AJvYcCWu2pnEGQrp84qtqmmDc6MlgV2iNcc2M5cpNPc+fgGQqqN4XqWwVd80VWDfwcEih66b1TsHaD3fTAk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyikffQMqZEJd7fK5aZjVgorTw64+dHItGGkpwXpmYGVeDhwCg+
	OubhTkjI+j7uU+n3sAiWxclUthW8Mmq9fx8oOUUszOa773kYRh3ICjpe1X68omBicw==
X-Gm-Gg: ASbGnctn3Gz0pouOhkJNl+xDvECWR+nw4G7dYRcHk6q9bncMnQnBdzl699o66+cPSIy
	ZpmF7QmIaUw8g6B3slkZjRSke86UredAw2KKEvfeL9xkdNDlACz13Xi3tCnhZ7whpTlWhFyx4D3
	bl+eOkjxScNzvzmjfSimDBOxC1RnfXEU73FAP3mO0tKmzCTiol6175qijxT+FeDOmoI3xPw1K9F
	DoBE/EGI4LlpcZyWIGZLxWcqYWGyID9876UAmLpMADMPU0Eq+H1gbDyjk/KeWD1wofILsbj3qnO
	328TWa5uOml+pSItgV7HOlU5MCjbnIDk4J5M6oNVtgX2VjER117MP9CKB+KXcHj2iclCSTI2ruc
	RKffEm2HjH1OVT9koFa3zZjvntbcLjiZcXf1z
X-Google-Smtp-Source: AGHT+IHRVNj6tJIbyrXX9xmMq8Uq+owAhF3uE47tuWhTg8lakzvIaKUixg4LS3yh27G1Q7cnwPPeUw==
X-Received: by 2002:a05:6000:24c8:b0:3a3:7987:945f with SMTP id ffacd0b85a97d-3a51d98c2b3mr5111189f8f.57.1749118210605;
        Thu, 05 Jun 2025 03:10:10 -0700 (PDT)
Message-ID: <202b9b4f-edd1-4bb4-a61a-a1fcf8333108@suse.com>
Date: Thu, 5 Jun 2025 12:10:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/5] x86/pmstat: Check size of PMSTAT_get_pxstat
 buffers
To: Ross Lagerwall 
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: <20250527152635.2451449-1-ross.lagerwall@citrix.com>
 <20250527152635.2451449-2-ross.lagerwall@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: <20250527152635.2451449-2-ross.lagerwall@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.05.2025 17:26, Ross Lagerwall wrote:
> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -215,11 +215,22 @@ typedef struct pm_px_val pm_px_val_t;
>  DEFINE_XEN_GUEST_HANDLE(pm_px_val_t);
>  
>  struct pm_px_stat {
> -    uint8_t total;        /* total Px states */
> +    /*
> +     * IN: Number of elements in pt, number of rows/columns in trans_pt
> +     *     (PMSTAT_get_pxstat)
> +     * OUT: total Px states (PMSTAT_get_max_px, PMSTAT_get_pxstat)
> +     */
> +    uint8_t total;
>      uint8_t usable;       /* usable Px states */
>      uint8_t last;         /* last Px state */
>      uint8_t cur;          /* current Px state */
> -    XEN_GUEST_HANDLE_64(uint64) trans_pt;   /* Px transition table */
> +    /*
> +     * OUT: Px transition table. This should have total * total elements.
> +     *      As it is a 2-D array, this will not be copied if it is smaller than
> +     *      the hypervisor's Px transition table. (PMSTAT_get_pxstat)
> +     */
> +    XEN_GUEST_HANDLE_64(uint64) trans_pt;
> +    /* OUT: This should have total elements (PMSTAT_get_pxstat) */
>      XEN_GUEST_HANDLE_64(pm_px_val_t) pt;
>  };

Commentary here is still confusing imo: Since "total" now has two meanings,
saying "This should have .." in OUT: descriptions is ambiguous. Imo for
trans_pt you want to say something like "will not be copied if input total is
less than output total", and for pt "the number of elements copied is the
smaller of input and output total".

If that's okay with you, I can edit things along these lines while committing,
at which point
Reviewed-by: Jan Beulich 

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 10:12:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 10:12:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006504.1385677 (Exim 4.92)
	(envelope-from )
	id 1uN7a2-0007XJ-Uf; Thu, 05 Jun 2025 10:12:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006504.1385677; Thu, 05 Jun 2025 10: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 1uN7a2-0007XC-Rh; Thu, 05 Jun 2025 10:12:14 +0000
Received: by outflank-mailman (input) for mailman id 1006504;
 Thu, 05 Jun 2025 10:12: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 1uN7a1-0007X3-Nf
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 10:12:13 +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 8bcfb912-41f5-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 12:12:11 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3a525eee2e3so514888f8f.2
 for ; Thu, 05 Jun 2025 03:12:11 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-313318e68b3sm938496a91.9.2025.06.05.03.12.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 03:12:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8bcfb912-41f5-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749118331; x=1749723131; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=SlmIeEJT5BWcNEpDiD24E5X6BVHCrZzAXxRIO4kfmrM=;
        b=Dpi6tS8JzAPOSkrCmnmQkOyae830YkJLQkB/v3bb4x+z3IoSu5O52O0J9+ZgLvLMXz
         vkJvN76ESslNSgGlXLoNQfvjc2DOwob8Si1VucgY1mrADALKmmTRN8vDIyVW1o5NHGtw
         R86mTTM3l1U8qKwtkhynurFUDLPbZivdPZ09ITBEPAah5YIEJfHd0ggBEDNC2H7DQNsO
         Yq1Ks2oBxfr42VJb7WXu4/0jmWluITJzLti04Mg0bVSpXRj5yRchw+l/OrksQAH/Nxsc
         T5uAUU7+voJ1CjpCNfGK3TVraD4BGeLP+wko8WoB77ur0KcGNC/COPDbL8um/3IixQYa
         mPrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749118331; x=1749723131;
        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=SlmIeEJT5BWcNEpDiD24E5X6BVHCrZzAXxRIO4kfmrM=;
        b=c5BHCOC70P9mylyDCrTsuMvgr4Lf+4V16iaTp6qHbXgxjnjGpanvwJYd/sGCVvu0Oj
         ZFyG3FRysKF5EKZvQ2keHAMHHldLgPzL0+LYaxjzsFSU+oScmUO3pvPpgmCCi7XSoJXb
         anFYZubXvZwF3vqfBivXD9tOov0qq3prA2QnE35WLwrlRuo2Ca5pOK/qSxrv77Y1+Pg0
         co5g+BtIzKyUunp4UU7ZnXpG68HWqIun7oUuv9K59EsZXbWxCbTsIsOSDfcnKrJod1R8
         e6AHAoSHEFnyZ/rRq8oANcEe4rtCOZ6V1Yvky3JUANbHxNV7Y337DuwaKbAqQX/4cnmK
         d3nQ==
X-Forwarded-Encrypted: i=1; AJvYcCVrwhnBXlWgzu2/Hw0Fbp5PSGSdU2HWUgk+9ysrPT5aqw6OiOh3AGGmDJqC1+CQxZhQ+2XwyKUQ7o8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzwGBV7JlWmCLXvl/UYNZGQ2keqdvNHG+GMT23Wpg4btdc/wcRR
	fqj7hmu2l70MOgothB3NgxkOFpe/QNcoV+3BskNHwvh9dA2RsHOFbYtyLiBkmVkZKg==
X-Gm-Gg: ASbGncsSGo0F+KFGziPkFPENmPMifWfu+EEh5Pqf9CAGap96rkI/m2YbIjw/AbbpIWd
	PH5ouudR6qLGAJm2GjR/6dKMQTgmiPapAyz4NRpX1J/FE03u/X6VsODGcLug2SEPMuPVLBM/BZO
	DXsEpQGaXCgcVgqPBM5z+5EqXB0zXK6duPvRq30TxKzR8xYx3S41kVrZVqj5L+b4fTYFuq6ZHqo
	EtlZCoAOAlgnB4Fza+cVSh3KaZqnkJ+j57o7xUCwy6zyiq/0IM2qDUquT4dMRpiqgm1oVXYe/nS
	KCfxn+yZsVPwc9xB0ifZPyMsfrudII/iVudSN6hO7N/h91xvCPGr510OLlyDlQ2nVlgh7JKS4Sq
	NmhM83ICRxPyfhNSYvu6uAKprgN/M97WUtW78tpdfVN9a+gE=
X-Google-Smtp-Source: AGHT+IFLbvL1j895C6+YcbIBEQIxK3IbI+Y0CKmk8pjhqLpyGfXp8RYUCkMStHo4eFmN9K4WknVerQ==
X-Received: by 2002:a5d:64e7:0:b0:3a5:1cc5:4a17 with SMTP id ffacd0b85a97d-3a51d96decdmr5160751f8f.42.1749118331195;
        Thu, 05 Jun 2025 03:12:11 -0700 (PDT)
Message-ID: 
Date: Thu, 5 Jun 2025 12:12:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/5] public/sysctl: Clarify usage of pm_{px,cx}_stat
To: Ross Lagerwall 
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: <20250527152635.2451449-1-ross.lagerwall@citrix.com>
 <20250527152635.2451449-3-ross.lagerwall@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: <20250527152635.2451449-3-ross.lagerwall@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.05.2025 17:26, Ross Lagerwall wrote:
> Suggested-by: Jan Beulich 
> Signed-off-by: Ross Lagerwall 

Acked-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 10:13:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 10:13:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006509.1385686 (Exim 4.92)
	(envelope-from )
	id 1uN7bc-00083l-9B; Thu, 05 Jun 2025 10:13:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006509.1385686; Thu, 05 Jun 2025 10:13:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uN7bc-00083e-6O; Thu, 05 Jun 2025 10:13:52 +0000
Received: by outflank-mailman (input) for mailman id 1006509;
 Thu, 05 Jun 2025 10:13: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 1uN7bb-00083W-1k
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 10:13:51 +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 c5daf720-41f5-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 12:13:49 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3a4f71831abso749628f8f.3
 for ; Thu, 05 Jun 2025 03:13:49 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23506cd8cf0sm116968805ad.155.2025.06.05.03.13.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 03:13:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c5daf720-41f5-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749118428; x=1749723228; 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=r6FItqV2VLLQg98mbOvhkJS/qFja9peEVQmD1TDjje0=;
        b=MVqonyKpp5mFOVupRYfI+lqttmig/yBAv5P4PcTS4bwsk3ztM/sm6e2OczAqh5sYGe
         ZjNy8xjt76CHXx8c8kOfBrgSCKu6/gjwyImMqqnnm3kzrqaaDayOMNlqaIG9QTLMrxmt
         oUXv9ZKLdS6gImbbyMPswWEujM2XoTX1E6o4P7xy7mEq00p3Pw6DOsBoliOFMGJWtWtM
         4R67Q2Vi+TXgGcT3J5aaPMf+WrmsV84JwMB+Xeswj4gGRvYZQZAgdP4RIUDjPx8RXkr/
         8cbUY5d46k8lFfLCSaobTn1BLWMOmsvweW+86T4vA6N/sixNVNUYDRY+bTFAZafiYdNN
         ifRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749118428; x=1749723228;
        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=r6FItqV2VLLQg98mbOvhkJS/qFja9peEVQmD1TDjje0=;
        b=YoG1QguVbzPpVY7l0cazW94lbsc3TT52PmUBDjROOkM0PAcLB3TGfMyqPM7UcBUAQ6
         ELfDEcTkBCqec6EDEojK6UY8vauXxP5H/KIpAy7kWqGjt1qpUW37sQ7w5Vm71hhFK10h
         vPjVIZ6ZwYadRr+kLUPpP3E9QuKkS+l05gT9iV6POdwvv2Wo5UeQ4cLkC1x7S9kG/RJ+
         L7zJqjKf1WqDsrYgCFbnbqid5VUzl70/wGioPe8Jy7wNnJyQBLcC1yMQgbJYc8bMeG48
         R9T0qHjh0PgwtysTTAf0aLooaMfZJnbkdeChEOLU6t9Th3mJYMWYzThi/hCWkp79U+U3
         YYFQ==
X-Gm-Message-State: AOJu0YwRisOkFNtFFpsq57tQUE4UckhZXx+uTXeg+zQW7OeSSYpolJkF
	U1fA2hheXkKy0MxTW/kucW+q2WvFHQV6iuccPO9hyFPpR6o/QCmvKv7vtoyNh4kO2Z/WnIJE9zh
	TivM=
X-Gm-Gg: ASbGncsy9Ybbky14Q1Yos94gs03sLHIa6RJ19zmVx+b9oD2NaY3AobkBbdp2Y5GzcKS
	yCT7rC/jc+zHZjCyM03Kb9BuMM5oXCzbDDSo9tNYXTBURgHTWxBIMTGOG8VTF33b+kuA3eSd7Wn
	Vtt4JE34NOMzbfUZxQ3AJzRNLVfTXzpLbock1T3u/inFmz0YJ5n19a361gcJ30GYz2gYfiNK9PR
	L2/Tsm2bH9odFBjezbXcTyfuSiNFsu6r0uLOZmZH431DNs0fn2UwtBosOAymIEsamvyeeweYb6s
	BimNGuufSRwmCQ7TwiP+hqgyi/JFrw0Ge5gD4x4Ad3wDsdQ1K15j9iu7gLH9zRUFMIQ6GKMo/RN
	UaVC0cSkLunXJeAo2u6fh0WKJDcqWyl2N8U7B
X-Google-Smtp-Source: AGHT+IF+ulNfOCkuPckiIpgQpyc1AXn0B1teqBc7PGk+77nw0y6bAY9ViXdk58mfa0sGVRBwBa+n6g==
X-Received: by 2002:a05:6000:381:b0:3a4:f912:862b with SMTP id ffacd0b85a97d-3a51d95e1a1mr5807981f8f.33.1749118428561;
        Thu, 05 Jun 2025 03:13:48 -0700 (PDT)
Message-ID: <88478f8a-dae0-4371-929a-67e7db95e99b@suse.com>
Date: Thu, 5 Jun 2025 12:13:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 3/5] cpufreq: Avoid potential buffer overrun and leak
To: Ross Lagerwall 
References: <20250527152635.2451449-1-ross.lagerwall@citrix.com>
 <20250527152635.2451449-4-ross.lagerwall@citrix.com>
Content-Language: en-US
Cc: xen-devel@lists.xenproject.org
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20250527152635.2451449-4-ross.lagerwall@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.05.2025 17:26, Ross Lagerwall wrote:
> If set_px_pminfo is called a second time with a larger state_count than
> the first call, calls to PMSTAT_get_pxstat will read beyond the end of
> the pt and trans_pt buffers allocated in cpufreq_statistic_init() since
> they would have been allocated with the original state_count.
> 
> Secondly, the states array leaks on each subsequent call of
> set_px_pminfo.
> 
> Fix both these issues by ignoring subsequent calls to set_px_pminfo if
> it completed successfully previously. Return success rather than an
> error to avoid errors in the dom0 kernel log when reloading the
> xen_acpi_processor module.
> 
> At the same time, fix a leak of the states array on error.
> 
> Signed-off-by: Ross Lagerwall 

Reviewed-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 10:16:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 10:16:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006514.1385697 (Exim 4.92)
	(envelope-from )
	id 1uN7dc-0000CS-Jr; Thu, 05 Jun 2025 10:15:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006514.1385697; Thu, 05 Jun 2025 10:15: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 1uN7dc-0000CL-H9; Thu, 05 Jun 2025 10:15:56 +0000
Received: by outflank-mailman (input) for mailman id 1006514;
 Thu, 05 Jun 2025 10:15: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 1uN7da-0000CF-Sd
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 10:15:55 +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 102b7fcb-41f6-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 12:15:53 +0200 (CEST)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-60462e180e2so1488109a12.2
 for ; Thu, 05 Jun 2025 03:15:53 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6070e505199sm1463883a12.64.2025.06.05.03.15.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 03:15:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 102b7fcb-41f6-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749118553; x=1749723353; 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=O5EgnmYs7+hDLNHmIjVv1NhRqfs+w9AEvSvwUuMUpGI=;
        b=Y71RYJ+59py41O+NaO5/cPsZXI77EWDfyKb5CY4pERgBWz1q7Ave9tRcaLmGBJEEvC
         y/AhLJ4JsnkdNu88HSsiqmZFZLrm/xr/I14nWMyZ5ctWQijXjU8sfZSXQ0frnZs7dEZ2
         w0/KOQH2bkj4iYf3Bp8/hgShJhSednu9ubJ7CGqkvEQ/ShRoHSa71c2WhSa8sunFNV5A
         zxCvbzADr9qncDtoBldqFp5leJVTQrK/X+7+PPjKNTSzDBMZemF01PzhBkDuzaWoN7j9
         e0wRTX6npIhwnL+xOGm1hpgLARk+svALSqUCyaKXiptZyhaDxP1AC1TgteA70H4oWQUF
         0lGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749118553; x=1749723353;
        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=O5EgnmYs7+hDLNHmIjVv1NhRqfs+w9AEvSvwUuMUpGI=;
        b=EPxW2WvNgxhnnOXvNb2UQE1Wy1quGCSwaHj8ebOK8KXZDW3W3K3909YWTxCdBd/Zzm
         FG01N4ZzajE7oEmN0xW6rx5W3IgLbz3ThtqUbgw61jZlKh8UHsNTBwuJxDMCeMU6Kl5i
         Xr6cYg5w/wADhbWLFzwn0CAgyTL397plEGVbnnpffbj8CZlObC3QCJGXSVBvO99iPlWR
         re3OwjNcafeKyPFPJNlmpi5rHFvg16MMgtetoXXSme8pniMSvYUBrlO8U/Oar02d7apS
         eaoHTg06ObBJeB2FwCZX2yDQRoqZTiLd7SUpeZ4Zpf8wtcok0Sy4TiTtIeJ7buZrWP9q
         XADA==
X-Forwarded-Encrypted: i=1; AJvYcCWTrjLrP+UUBRQJxhfUvSb5A7+Hff/gpHCzmU9cRBZii+/v11XnLPeRjTBCaXYl78zDCYXnM0hrSHc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwBQF/wv+YTw2E9+wVIOVRoRXehprz5gzXKwURXp4EhnVdT4+tE
	DGcnQjqVD2qwtkcaVFlDY+mY2YVUx4d9glvn3CAPPqMzjceVfUEQPwKF
X-Gm-Gg: ASbGnctdIZjBhy0S2tYgdUxFiB8HAPUdSyHKnmzUKZa1uk9/5FB3l7+jk7UIYiLGYd2
	COKAthQTSxew0BgdZX1UWThSLt1n4mMFD6zxDaj4p011jCvCxhqVxbYeeX8ss7Vtf0W0cs73nqA
	vMghf35+UiAtx5IBkD/Aeidaj3/xEbetemCisqjjpXz0yOYMHHXhRBWv1/hRUfQsJH9WG3Mw4LW
	Fkr8OpDCyy7EOKZBGvdnOxuMvFVqEVpVDXAwg3V+0iWz0NKpSqXAtlrrQJpR5oOpIsCkPKj3NNj
	A3ZtdxMvhlEmOCpUjDaZJxR6P6daNMe1F7c8wYXETRv7v40d0TeAH4Zl5iI1d4NWsx0EvZwHw01
	sXKEtc4pvoDv3OAFfsk/Nf0p6G2EQTEbXv10=
X-Google-Smtp-Source: AGHT+IGQWwLRVyLMO/INhpCtFu7WNpD3X+7WQxptfd+l12vJ6lYHckJNwRhgRdS+TXUQI7WB/38RFg==
X-Received: by 2002:a05:6402:1d53:b0:602:1d01:2883 with SMTP id 4fb4d7f45d1cf-606e98b0c65mr5905664a12.1.1749118553049;
        Thu, 05 Jun 2025 03:15:53 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------0VKZK6KrDGQgAgTG8WIl40B8"
Message-ID: 
Date: Thu, 5 Jun 2025 12:15:51 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 08/14] xen/riscv: imsic_init() implementation
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 ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <421dad1bbd014a2d7ff588af088eadbd56345dbe.1747843009.git.oleksii.kurochko@gmail.com>
 
 
 <8cd6c3e0-0361-4f3f-b3ca-8ffa49b9197d@suse.com>
 
 
 
 <2de0a33e-75ff-449c-a0db-6a2279b9e484@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <2de0a33e-75ff-449c-a0db-6a2279b9e484@suse.com>

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


On 6/5/25 11:42 AM, Jan Beulich wrote:
> On 05.06.2025 11:13, Oleksii Kurochko wrote:
>> On 6/5/25 8:50 AM, Jan Beulich wrote:
>>> On 04.06.2025 17:36, Oleksii Kurochko wrote:
>>>> On 6/2/25 12:21 PM, Jan Beulich wrote:
>>>>> On 26.05.2025 20:44, Oleksii Kurochko wrote:
>>>>>> On 5/22/25 4:46 PM, Jan Beulich wrote:
>>>>>>> On 21.05.2025 18:03, Oleksii Kurochko wrote:
>>>>>>>> +    /* Check MMIO register sets */
>>>>>>>> +    for ( unsigned int i = 0; i < nr_mmios; i++ )
>>>>>>>> +    {
>>>>>>>> +        if ( !alloc_cpumask_var(&imsic_cfg.mmios[i].cpus) )
>>>>>>>> +        {
>>>>>>>> +            rc = -ENOMEM;
>>>>>>>> +            goto imsic_init_err;
>>>>>>>> +        }
>>>>>>>> +
>>>>>>>> +        rc = dt_device_get_address(node, i, &imsic_cfg.mmios[i].base_addr,
>>>>>>>> +                                   &imsic_cfg.mmios[i].size);
>>>>>>>> +        if ( rc )
>>>>>>>> +        {
>>>>>>>> +            printk(XENLOG_ERR "%s: unable to parse MMIO regset %u\n",
>>>>>>>> +                   node->name, i);
>>>>>>>> +            goto imsic_init_err;
>>>>>>>> +        }
>>>>>>>> +
>>>>>>>> +        base_addr = imsic_cfg.mmios[i].base_addr;
>>>>>>>> +        base_addr &= ~(BIT(imsic_cfg.guest_index_bits +
>>>>>>>> +                           imsic_cfg.hart_index_bits +
>>>>>>>> +                           IMSIC_MMIO_PAGE_SHIFT, UL) - 1);
>>>>>>>> +        base_addr &= ~((BIT(imsic_cfg.group_index_bits, UL) - 1) <<
>>>>>>>> +                       imsic_cfg.group_index_shift);
>>>>>>>> +        if ( base_addr != imsic_cfg.base_addr )
>>>>>>>> +        {
>>>>>>>> +            rc = -EINVAL;
>>>>>>>> +            printk(XENLOG_ERR "%s: address mismatch for regset %u\n",
>>>>>>>> +                   node->name, i);
>>>>>>>> +            goto imsic_init_err;
>>>>>>>> +        }
>>>>>>> Maybe just for my own understanding: There's no similar check for the
>>>>>>> sizes to match / be consistent wanted / needed?
>>>>>> If you are speaking about imsic_cfg.mmios[i].size then it depends fully on h/w will
>>>>>> provide, IMO.
>>>>>> So I don't what is possible range for imsic_cfg.mmios[i].size.
>>>>> Well, all I can say is that's it feels odd that you sanity check base_addr
>>>>> but permit effectively any size.
>>>> Okay, I think I have two ideas how to check the size:
>>>> 1. Based on guest bits from IMSIC's DT node. QEMU calculates a size as:
>>>>        for (socket = 0; socket < socket_count; socket++) {
>>>>            imsic_addr = base_addr + socket * VIRT_IMSIC_GROUP_MAX_SIZE;
>>>>            imsic_size = IMSIC_HART_SIZE(imsic_guest_bits) *
>>>>                         s->soc[socket].num_harts;
>>>>        ...
>>>>       where:
>>>>         #define IMSIC_MMIO_PAGE_SHIFT          12
>>>>         #define IMSIC_MMIO_PAGE_SZ             (1UL << IMSIC_MMIO_PAGE_SHIFT)
>>>>         
>>>>         #define IMSIC_HART_NUM_GUESTS(__guest_bits)           \
>>>>                 (1U << (__guest_bits))
>>>>         #define IMSIC_HART_SIZE(__guest_bits)                 \
>>>>                 (IMSIC_HART_NUM_GUESTS(__guest_bits) * IMSIC_MMIO_PAGE_SZ)
>>>>
>>>> 2. Just take a theoretical maximum for S-mode IMSIC's node:
>>>>        16,384 * 64 1(S-mode interrupt file) + 63(max guest interrupt files)) * 4 KiB
>>>>       Where,
>>>>         16,384 - maximum possible amount of harts according to AIA spec
>>>>         64 - a maximum amount of possible interrupt file for S-mode IMSIC node:
>>>>              1 - S interupt file + 63 guest interrupt files.
>>>>         4 Kib - a maximum size of one interrupt file.
>>>>
>>>> Which option is preferred?
>>> I would have said 2, if your outline used "actual" rather than "maximum" values.
>> In option 2 maximum possible values are used. If we want to use "actual" values then
>> the option 1 should be used.
> Actually I was wrong with request "actual" uniformly. It's only the hart count where
> I meant to ask for that. For interrupts we should allow the maximum possible unless
> we already know their count.

Do you mean 'interrupt file' here? If yes, then an amount of them shouldn't be bigger
then 1 + BIT(guest_bits).

~ Oleksii

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



  
    
  
  
    

    
    
    
    
    On 6/5/25 11:42 AM, Jan Beulich wrote:
    
    
    
    
    
      
    On 05.06.2025 11:13, Oleksii Kurochko wrote:

    
      
    
        
    On 6/5/25 8:50 AM, Jan Beulich wrote:

    
        
    
          
    On 04.06.2025 17:36, Oleksii Kurochko wrote:

    
          
    
            
    On 6/2/25 12:21 PM, Jan Beulich wrote:

    
            
    
              
    On 26.05.2025 20:44, Oleksii Kurochko wrote:

    
              
    
                
    On 5/22/25 4:46 PM, Jan Beulich wrote:

    
                
    
                  
    On 21.05.2025 18:03, Oleksii Kurochko wrote:

    
                  
    
                    
    +    /* Check MMIO register sets */
+    for ( unsigned int i = 0; i < nr_mmios; i++ )
+    {
+        if ( !alloc_cpumask_var(&imsic_cfg.mmios[i].cpus) )
+        {
+            rc = -ENOMEM;
+            goto imsic_init_err;
+        }
+
+        rc = dt_device_get_address(node, i, &imsic_cfg.mmios[i].base_addr,
+                                   &imsic_cfg.mmios[i].size);
+        if ( rc )
+        {
+            printk(XENLOG_ERR "%s: unable to parse MMIO regset %u\n",
+                   node->name, i);
+            goto imsic_init_err;
+        }
+
+        base_addr = imsic_cfg.mmios[i].base_addr;
+        base_addr &= ~(BIT(imsic_cfg.guest_index_bits +
+                           imsic_cfg.hart_index_bits +
+                           IMSIC_MMIO_PAGE_SHIFT, UL) - 1);
+        base_addr &= ~((BIT(imsic_cfg.group_index_bits, UL) - 1) <<
+                       imsic_cfg.group_index_shift);
+        if ( base_addr != imsic_cfg.base_addr )
+        {
+            rc = -EINVAL;
+            printk(XENLOG_ERR "%s: address mismatch for regset %u\n",
+                   node->name, i);
+            goto imsic_init_err;
+        }

    
                  
    
                  
    Maybe just for my own understanding: There's no similar check for the
sizes to match / be consistent wanted / needed?

    
                
    
                
    If you are speaking about imsic_cfg.mmios[i].size then it depends fully on h/w will
provide, IMO.
So I don't what is possible range for imsic_cfg.mmios[i].size.

    
              
    
              
    Well, all I can say is that's it feels odd that you sanity check base_addr
but permit effectively any size.

    
            
    
            
    Okay, I think I have two ideas how to check the size:
1. Based on guest bits from IMSIC's DT node. QEMU calculates a size as:
      for (socket = 0; socket < socket_count; socket++) {
          imsic_addr = base_addr + socket * VIRT_IMSIC_GROUP_MAX_SIZE;
          imsic_size = IMSIC_HART_SIZE(imsic_guest_bits) *
                       s->soc[socket].num_harts;
      ...
     where:
       #define IMSIC_MMIO_PAGE_SHIFT          12
       #define IMSIC_MMIO_PAGE_SZ             (1UL << IMSIC_MMIO_PAGE_SHIFT)
       
       #define IMSIC_HART_NUM_GUESTS(__guest_bits)           \
               (1U << (__guest_bits))
       #define IMSIC_HART_SIZE(__guest_bits)                 \
               (IMSIC_HART_NUM_GUESTS(__guest_bits) * IMSIC_MMIO_PAGE_SZ)

2. Just take a theoretical maximum for S-mode IMSIC's node:
      16,384 * 64 1(S-mode interrupt file) + 63(max guest interrupt files)) * 4 KiB
     Where,
       16,384 - maximum possible amount of harts according to AIA spec
       64 - a maximum amount of possible interrupt file for S-mode IMSIC node:
            1 - S interupt file + 63 guest interrupt files.
       4 Kib - a maximum size of one interrupt file.

Which option is preferred?

    
          
    
          
    I would have said 2, if your outline used "actual" rather than "maximum" values.

    
        
    
        
    In option 2 maximum possible values are used. If we want to use "actual" values then
the option 1 should be used.

    
      
    
      
    Actually I was wrong with request "actual" uniformly. It's only the hart count where
I meant to ask for that. For interrupts we should allow the maximum possible unless
we already know their count.
    
    
    
    
    Do you mean 'interrupt file' here? If yes, then an amount of them shouldn't be bigger
then 1 + BIT(guest_bits).
    
    
    ~ Oleksii
    
  


--------------0VKZK6KrDGQgAgTG8WIl40B8--


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 10:16:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 10:16:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006520.1385707 (Exim 4.92)
	(envelope-from )
	id 1uN7eS-0000hq-SP; Thu, 05 Jun 2025 10:16:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006520.1385707; Thu, 05 Jun 2025 10:16: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 1uN7eS-0000hj-Pc; Thu, 05 Jun 2025 10:16:48 +0000
Received: by outflank-mailman (input) for mailman id 1006520;
 Thu, 05 Jun 2025 10:16: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 1uN7eR-0000bz-6a
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 10:16:47 +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 2d2a90b5-41f6-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 12:16:42 +0200 (CEST)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-451e24dfe1aso6520445e9.3
 for ; Thu, 05 Jun 2025 03:16:42 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-451fb1698acsm14044195e9.3.2025.06.05.03.16.41
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 03:16:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2d2a90b5-41f6-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749118602; x=1749723402; 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=A3GxvxBRsmWqiepq7gu93Re1Z2R4+OHqreQ8ElaKrJ0=;
        b=jLSmrfrQyIvvTC3zkpw/YZIALWPTAr8Hm4w4B/nhVguqsH1NzIrge0f4VFBeFfix1J
         MBj189Koa5LOqnnDIZSODuuNlTczCF5Spdyk/6aM0yC9hRr5fYBjkwn+B8NVa4uU/Q3A
         /jxnucueS6tPeAtREhIct0nNN+9c815SQ7zD0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749118602; x=1749723402;
        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=A3GxvxBRsmWqiepq7gu93Re1Z2R4+OHqreQ8ElaKrJ0=;
        b=ZMsJJQUWGXme7tlvuWK6aXYzkRzqFycyPV4MJ17Jo/aGAxqcRaHjtrrAamIUckAFUq
         jfm+NmXKMiRl6uPd/WJ/1SJJHI8V3JN9t9lk9efxMGocaCk2DlBqLiSkvsgFXHE9C2rD
         c0qd09PfZDKga6bhqGLDTPwth3XHBKF3NwA8oSOgAZKkfPkzWs7Tsb1Cec+fMGjsPh0k
         4ENfjFHzIR3ugwR9f+UmrbSvfULvAmJSqGRQcu54+X52a+zAvoJlgujRI0OfyNARF1Tt
         cEyOrdsnSDNgWiqXaTxzUABUahecbCKjx5dy7Jv2XjrM5LvSM3aIEVD372sTHGXcj3ji
         uexA==
X-Gm-Message-State: AOJu0Ywxe1fjX+k4BfZXbi+JD9gIJw+pfo2WSI+SkLCVgs/d5H0JsS0V
	3TZHW7jaU0y8T5AcZCNl6+MI0t0/NvR09DROCKEzwAB+p4al17Q2N0JafWDFA/Lqz1uAzliYRFL
	vcvvz
X-Gm-Gg: ASbGncufPgF21/QP661wb3HsVp1/lCoHGGl9MEEJUM6ZCSOj+AcP40Pp+6/lLPlzpgp
	PKxTycNjXiCnzvAmuym3v+GTn1wJLJaD05pZE0HO0Ulhb8RUdrjb7dPLLqrnJ7AMwaTSabeakM6
	xxASOouByJ/JiKFT1EL21bF3qYEKYry26H7hENJAELcf2sZDc7IIZRtnYJFXLDFWfaN+9OUdIJX
	23QaYyPGL8c0I8wpNAyySN65ZFX1Dr1RPidFSdZ7lnlOfBhA2ezzv9ZvAXg4OgrNR8o86yJzwK3
	UH8EN/0beG/E3aDZlpDla4c0YttYgKNoSiccwUEmyHA8LCd4VKhncpg/s/DBu3T6qQ+/vBaW+MW
	Dy/FrcEiUjMEg5cf40WE=
X-Google-Smtp-Source: AGHT+IHIG9aDx0qOxX+5jggInU+cm2rquprNr0DSjTshmXcWCr/HMJsQ3Iht78hST2uHWFwY7o/DnQ==
X-Received: by 2002:a05:600c:c4a8:b0:442:f482:c432 with SMTP id 5b1f17b1804b1-451f3be8839mr55289855e9.18.1749118601831;
        Thu, 05 Jun 2025 03:16:41 -0700 (PDT)
Date: Thu, 5 Jun 2025 12:16:40 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Stewart Hildebrand 
Cc: xen-devel@lists.xenproject.org
Subject: Re: [PATCH v1 3/5] vpci: introduce map_bars()
Message-ID: 
References: <20250531125405.268984-1-stewart.hildebrand@amd.com>
 <20250531125405.268984-4-stewart.hildebrand@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250531125405.268984-4-stewart.hildebrand@amd.com>

On Sat, May 31, 2025 at 08:54:01AM -0400, Stewart Hildebrand wrote:
> Move some logic to a new function to enable code reuse.

Like with the previous changes, it's helpful if you explicitly note
that no functional change is intended in the commit message (which I
think it's the case here).

> 
> Signed-off-by: Stewart Hildebrand 
> ---
>  xen/drivers/vpci/header.c | 56 ++++++++++++++++++++++++---------------
>  1 file changed, 35 insertions(+), 21 deletions(-)
> 
> diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
> index c1463d2ce076..b09ccc5e6be6 100644
> --- a/xen/drivers/vpci/header.c
> +++ b/xen/drivers/vpci/header.c
> @@ -173,11 +173,38 @@ static void modify_decoding(const struct pci_dev *pdev, uint16_t cmd,
>          ASSERT_UNREACHABLE();
>  }
>  
> +static int map_bars(struct vpci_header *header, struct domain *d, bool map)
> +{
> +    unsigned int i;
> +
> +    for ( i = 0; i < ARRAY_SIZE(header->bars); i++ )
> +    {
> +        struct vpci_bar *bar = &header->bars[i];
> +        struct map_data data = {
> +            .d = d,
> +            .map = map,
> +            .bar = bar,
> +        };
> +        int rc;
> +
> +        if ( rangeset_is_empty(bar->mem) )
> +            continue;
> +
> +        rc = rangeset_consume_ranges(bar->mem, map_range, &data);
> +
> +        if ( rc )
> +            return rc;
> +    }
> +
> +    return 0;
> +}
> +
>  bool vpci_process_pending(struct vcpu *v)
>  {
>      const struct pci_dev *pdev = v->vpci.pdev;
>      struct vpci_header *header = NULL;
>      unsigned int i;

Maybe I'm missing something, but don't you get complains from the
compiler here about i being unused after this change?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 10:17:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 10:17:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006528.1385717 (Exim 4.92)
	(envelope-from )
	id 1uN7fE-0001I6-9h; Thu, 05 Jun 2025 10:17:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006528.1385717; Thu, 05 Jun 2025 10:17: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 1uN7fE-0001Hz-5V; Thu, 05 Jun 2025 10:17:36 +0000
Received: by outflank-mailman (input) for mailman id 1006528;
 Thu, 05 Jun 2025 10: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 1uN7fC-00011l-9H
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 10:17:34 +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 4b8a59c3-41f6-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 12:17:33 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3a50fc819f2so620387f8f.2
 for ; Thu, 05 Jun 2025 03:17:33 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23506cd352asm117287835ad.131.2025.06.05.03.17.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 03:17:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4b8a59c3-41f6-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749118653; x=1749723453; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=AM6bHoTc63qxevfgt0gNrUbSiwkKLkcYxU1ccmCxQeI=;
        b=XRnjHq+EOMuWVka9LdpBG4KUqoQC0tchV+uVYN3jqe7AIaKFWmdVgYF2rBGJhpxrRG
         ss4n1NbAtK7bAyQ8IZnlRpSTeWLhXSq5VXYMhA0+GTzHfKZ/c7+NdBzZeIL0519DV/xW
         6jj7qptqp881aPaEJ2uFdVMqPYMCzLhkHKoPW6kFzmK0i3t6vo++rdF9S3ktxuAvA7UW
         NKK+Cbuaqb6gj3Sdt/id5lafmi6N93deV6Gmxl1CDqFUrufvkWUCpDvyrRtbCv762yl+
         rXEokHAYlRvkCcgPn0CVRTQ7ROVEKXqmqwg5Q3TxY2mH1ceZh8E/2keNZKw8Gv9QAkte
         7fGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749118653; x=1749723453;
        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=AM6bHoTc63qxevfgt0gNrUbSiwkKLkcYxU1ccmCxQeI=;
        b=FgfTMLumyEK+5hOHj0OQOTnaZe8NKKWpKMIuhQhJBv9w1kJLixBWkxXUeT5j4rWsrW
         c5feAePU3w4aZPvcIDK9+Erx4UsMworvppEKCTr6jIaJUr5aX68jMvng93Q7MjbSPIDk
         iztF7lv/7oVQtSDzJNwi6wSjFxhoinYSJDyf1KJNyprHAy2cyrON/TNzDwx7fJcDvIe7
         I1xZRanJR2VNLPU8TvuCI1JdlFehgJJnWTkfWCJr5GzR17S8gSG5EvS8j9P8W9sTKadz
         ryVg5b3+XZ5RUB5v7DyjmA7x8laX0sca9mcAUoIt7L5/VvGfxBa2+urQCDITH/xLcobL
         wC8w==
X-Forwarded-Encrypted: i=1; AJvYcCX9wZ5Q76jhxFDPs+3wcRhh2mDQI6IzU3KoOzlDLmQItG+m4zkHyTWYOwMGkKuDJ23hV5d2E4yDjDs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwnhZ5fuvW70cdi9g6cEyU1K4ct3XAkfMaXrnyqMvdgl8LP7q2x
	IcYnaRWfRwjjwuYu8j1tpvkv1tFIKE5VtfOaYcO5KvP2C3TdD7PbjvwZZIjREdBc+A==
X-Gm-Gg: ASbGncvHKmVUfmbN8juRRQbc2AF8IK77q0gnZTd/bDvupF+ob3lnSI5s0X+Lm7md72c
	n3ct+Arbc/XshpTfiJcfJqikC8eq7iUsUVqoN1hA2fIcT1A8seYiURQVBskhY9+fwWauefv9WJF
	ihsfFG52YZrVwsSdzfJ118K1lE/mDC1SYQUwR2Ljo3o2p4w01WdXUN2OuRVlfPhJRupLjJsYSLd
	KYxYf0uVrHYzfPSerkOd7gEVSC14hTvu10yon+s3UQZ75XMFwzfezmaYPclCtI82z4AI/xy6EUz
	Fg5DF9wxi4arD/TJnPaVcbsM5/NsqxOIYzb0bc6XFhHBirTMv3GyhiSs63Zyf69W5m7x9UZiMCY
	0yb5JfCz12H63pbZvlgmNAmr4GKpCI7M36xZSweDOLWlM5NQ=
X-Google-Smtp-Source: AGHT+IE73DOQVI66DwN9CvqAMZalhYZh3dUxeF7t/7GjRNd/J8gkAZMXK6sCqrQUWyBa4aApEeCX1g==
X-Received: by 2002:a05:6000:26d0:b0:3a4:f787:9b58 with SMTP id ffacd0b85a97d-3a51d986a6emr5083670f8f.58.1749118652906;
        Thu, 05 Jun 2025 03:17:32 -0700 (PDT)
Message-ID: <1d3165c8-7b45-47a9-999c-a1ed893ef173@suse.com>
Date: Thu, 5 Jun 2025 12:17:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 08/14] xen/riscv: imsic_init() implementation
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 ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <421dad1bbd014a2d7ff588af088eadbd56345dbe.1747843009.git.oleksii.kurochko@gmail.com>
 
 
 <8cd6c3e0-0361-4f3f-b3ca-8ffa49b9197d@suse.com>
 
 
 
 <2de0a33e-75ff-449c-a0db-6a2279b9e484@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 05.06.2025 12:15, Oleksii Kurochko wrote:
> 
> On 6/5/25 11:42 AM, Jan Beulich wrote:
>> On 05.06.2025 11:13, Oleksii Kurochko wrote:
>>> On 6/5/25 8:50 AM, Jan Beulich wrote:
>>>> On 04.06.2025 17:36, Oleksii Kurochko wrote:
>>>>> On 6/2/25 12:21 PM, Jan Beulich wrote:
>>>>>> On 26.05.2025 20:44, Oleksii Kurochko wrote:
>>>>>>> On 5/22/25 4:46 PM, Jan Beulich wrote:
>>>>>>>> On 21.05.2025 18:03, Oleksii Kurochko wrote:
>>>>>>>>> +    /* Check MMIO register sets */
>>>>>>>>> +    for ( unsigned int i = 0; i < nr_mmios; i++ )
>>>>>>>>> +    {
>>>>>>>>> +        if ( !alloc_cpumask_var(&imsic_cfg.mmios[i].cpus) )
>>>>>>>>> +        {
>>>>>>>>> +            rc = -ENOMEM;
>>>>>>>>> +            goto imsic_init_err;
>>>>>>>>> +        }
>>>>>>>>> +
>>>>>>>>> +        rc = dt_device_get_address(node, i, &imsic_cfg.mmios[i].base_addr,
>>>>>>>>> +                                   &imsic_cfg.mmios[i].size);
>>>>>>>>> +        if ( rc )
>>>>>>>>> +        {
>>>>>>>>> +            printk(XENLOG_ERR "%s: unable to parse MMIO regset %u\n",
>>>>>>>>> +                   node->name, i);
>>>>>>>>> +            goto imsic_init_err;
>>>>>>>>> +        }
>>>>>>>>> +
>>>>>>>>> +        base_addr = imsic_cfg.mmios[i].base_addr;
>>>>>>>>> +        base_addr &= ~(BIT(imsic_cfg.guest_index_bits +
>>>>>>>>> +                           imsic_cfg.hart_index_bits +
>>>>>>>>> +                           IMSIC_MMIO_PAGE_SHIFT, UL) - 1);
>>>>>>>>> +        base_addr &= ~((BIT(imsic_cfg.group_index_bits, UL) - 1) <<
>>>>>>>>> +                       imsic_cfg.group_index_shift);
>>>>>>>>> +        if ( base_addr != imsic_cfg.base_addr )
>>>>>>>>> +        {
>>>>>>>>> +            rc = -EINVAL;
>>>>>>>>> +            printk(XENLOG_ERR "%s: address mismatch for regset %u\n",
>>>>>>>>> +                   node->name, i);
>>>>>>>>> +            goto imsic_init_err;
>>>>>>>>> +        }
>>>>>>>> Maybe just for my own understanding: There's no similar check for the
>>>>>>>> sizes to match / be consistent wanted / needed?
>>>>>>> If you are speaking about imsic_cfg.mmios[i].size then it depends fully on h/w will
>>>>>>> provide, IMO.
>>>>>>> So I don't what is possible range for imsic_cfg.mmios[i].size.
>>>>>> Well, all I can say is that's it feels odd that you sanity check base_addr
>>>>>> but permit effectively any size.
>>>>> Okay, I think I have two ideas how to check the size:
>>>>> 1. Based on guest bits from IMSIC's DT node. QEMU calculates a size as:
>>>>>        for (socket = 0; socket < socket_count; socket++) {
>>>>>            imsic_addr = base_addr + socket * VIRT_IMSIC_GROUP_MAX_SIZE;
>>>>>            imsic_size = IMSIC_HART_SIZE(imsic_guest_bits) *
>>>>>                         s->soc[socket].num_harts;
>>>>>        ...
>>>>>       where:
>>>>>         #define IMSIC_MMIO_PAGE_SHIFT          12
>>>>>         #define IMSIC_MMIO_PAGE_SZ             (1UL << IMSIC_MMIO_PAGE_SHIFT)
>>>>>         
>>>>>         #define IMSIC_HART_NUM_GUESTS(__guest_bits)           \
>>>>>                 (1U << (__guest_bits))
>>>>>         #define IMSIC_HART_SIZE(__guest_bits)                 \
>>>>>                 (IMSIC_HART_NUM_GUESTS(__guest_bits) * IMSIC_MMIO_PAGE_SZ)
>>>>>
>>>>> 2. Just take a theoretical maximum for S-mode IMSIC's node:
>>>>>        16,384 * 64 1(S-mode interrupt file) + 63(max guest interrupt files)) * 4 KiB
>>>>>       Where,
>>>>>         16,384 - maximum possible amount of harts according to AIA spec
>>>>>         64 - a maximum amount of possible interrupt file for S-mode IMSIC node:
>>>>>              1 - S interupt file + 63 guest interrupt files.
>>>>>         4 Kib - a maximum size of one interrupt file.
>>>>>
>>>>> Which option is preferred?
>>>> I would have said 2, if your outline used "actual" rather than "maximum" values.
>>> In option 2 maximum possible values are used. If we want to use "actual" values then
>>> the option 1 should be used.
>> Actually I was wrong with request "actual" uniformly. It's only the hart count where
>> I meant to ask for that. For interrupts we should allow the maximum possible unless
>> we already know their count.
> 
> Do you mean 'interrupt file' here?

Yes, I do. Sorry for getting the terminology wrong.

Jan

> If yes, then an amount of them shouldn't be bigger
> then 1 + BIT(guest_bits).
> 
> ~ Oleksii
> 



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 10:23:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 10:23:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006537.1385727 (Exim 4.92)
	(envelope-from )
	id 1uN7l3-0003FJ-SS; Thu, 05 Jun 2025 10:23:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006537.1385727; Thu, 05 Jun 2025 10:23:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uN7l3-0003FC-Ph; Thu, 05 Jun 2025 10:23:37 +0000
Received: by outflank-mailman (input) for mailman id 1006537;
 Thu, 05 Jun 2025 10:23: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 1uN7l3-0003F6-1j
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 10:23:37 +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 238e15c4-41f7-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 12:23:35 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3a5257748e1so587129f8f.2
 for ; Thu, 05 Jun 2025 03:23:35 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-31331a0d21dsm952252a91.47.2025.06.05.03.23.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 03:23:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 238e15c4-41f7-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749119015; x=1749723815; 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=jvFthMSL8+Z8GEs8FOFne7Ns+18c478NJDhlKFOmtKU=;
        b=aKFd/yb2vfvySiKvWvlS90AlwPZbOm1Q44nvFoVdlVEdAjqH/XURIb4m4R2NAHQpAS
         NAQsuXTcVfImmh1grD4RrZWYcTWfr843DEN1eGZks5xB3/ul7LumS2zh15A7BcmxcOZp
         ku2VBPEk+LKnDkFW46IQRtpXKmQQGEZg7l/yZMHxFgkliWXGk+B8JLZBTOsuWyayD2po
         3n9kaWPv4hvQOYDSe43Lv/dKrS/BjtsMTQB0vZfEjRSnq9RcJIODWjf6Hy8/w7DOQHjp
         umItMQwGKP1jzZA6DDokbhDYEd3nRqyrHMGxt1JopoqeEgVrayCN/t+SRZ25he56cl+4
         XChA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749119015; x=1749723815;
        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=jvFthMSL8+Z8GEs8FOFne7Ns+18c478NJDhlKFOmtKU=;
        b=b5NUY+SHkSW2gseplY9n1dXd45yEpKFSKo0vhOqoE/3mh69klARbBQe4eH69BI/w9x
         bQ+jDgg1gGS5FNSx2Z0Q9yymsqdM/YxL7slGexeo62l4u0Zz6HKBO3CZrMGW8aO/n0cD
         4m0bokESj1REZOzCZM2JmrgUIFCswS++R2KB0FfXYKu/nxYXre6dE26x6kZr1A0XWXxU
         2Ijs1CT/MFCRcdUYwq6PYTmYqGTASj5lcZJQqeB5+5K+CzVKXruiQSmBLrPASoYHXqEu
         2/VNZrxL8Alpi0YHmSM5t/3envOD099OH9w+xcBtAtc05dOmb6S4x+8lj5exSiN9bVov
         p3sw==
X-Gm-Message-State: AOJu0YwnoiEciQ2jI73vvso/SjWEio9oTjT1PA02mJvuIvghUCsC4Tsx
	fc4gILyTwTPEwsSVTdCUZt+6BPtLPeMHK1uJ8FJEccrC6tkL7uKFxGtToxjQe2USESQ788/Eh3P
	p0+g=
X-Gm-Gg: ASbGncsHHNAIud+Y/Z4lRuz5hZ/yGvbfb2a9wE+3HWCTAD95nARbnSrSVgxDGz7a2ER
	swg9yct7s3d4+QkL7zhKIZQQSCVaOzuPj6UlyXq2+JOmDtWNsNpV7jS8izkHLV/eXwsBEYN83I3
	WccqOOOgl4nIK4L6E6KcDVfKO87/B3vMgrwV6nH5zsYwI3tBvOZefd9wPwSA98O/TC4aJUvIqzN
	yCPZydK3bKC6bWmvxXA2sGCtUXup8LbBTE3gNLuBCNFBSviaNP4yjEXu8lWtmek3V8JLCxjWOpO
	OxcY9aNPoIINZZW8/Vs6/Bk5r4Pq72gISAt9ulynxZqHaGFQXZkfrwtGNgx8GF81ketGtbi1T4V
	rz9dCZbu89WoH7z+cyqWtsD7xuV8SB5YP9ln7
X-Google-Smtp-Source: AGHT+IFRZeGhZtz6XcZ0X62AWvysjnmmBzClvDGk1IyxS7k24rmsQhPGx4Bmw6TEPXwji9Mg81Ot2g==
X-Received: by 2002:a05:6000:430c:b0:3a4:f435:5801 with SMTP id ffacd0b85a97d-3a51d923793mr5352539f8f.17.1749119015372;
        Thu, 05 Jun 2025 03:23:35 -0700 (PDT)
Message-ID: <73481cbf-337f-4e85-81d2-3487366cd822@suse.com>
Date: Thu, 5 Jun 2025 12:23:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Jan Beulich 
Subject: [PATCH v5 0/6] x86: memcpy() / memset() (non-)ERMS flavors plus
 fallout
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

While the performance varies quite a bit on older (pre-ERMS) and newer
(ERMS) hardware, so far we've been going with just a single flavor of
these two functions, and oddly enough with ones not consistent with one
another. Using plain memcpy() / memset() on MMIO (video frame buffer)
is generally okay, but the ERMS variant of memcpy() turned out to
regress (boot) performance in a way easily visible to the human eye
(meanwhile addressed by using ioremap_wc() there).

01: x86: suppress ERMS for internal use when MISC_ENABLE.FAST_STRING is clear
02: x86: re-work memset()
03: x86: re-work memcpy()
04: x86: control memset() and memcpy() inlining
05: x86: introduce "hot" and "cold" page clearing functions
06: mm: allow page scrubbing routine(s) to be arch controlled

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 10:24:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 10:24:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006542.1385737 (Exim 4.92)
	(envelope-from )
	id 1uN7m8-0003lQ-53; Thu, 05 Jun 2025 10:24:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006542.1385737; Thu, 05 Jun 2025 10:24:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uN7m8-0003lJ-1l; Thu, 05 Jun 2025 10:24:44 +0000
Received: by outflank-mailman (input) for mailman id 1006542;
 Thu, 05 Jun 2025 10:24: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 1uN7m7-0003lD-FF
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 10:24:43 +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 4b46800b-41f7-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 12:24:42 +0200 (CEST)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-442ea341570so4983345e9.1
 for ; Thu, 05 Jun 2025 03:24:42 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-747afff70b5sm12562346b3a.160.2025.06.05.03.24.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 03:24:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4b46800b-41f7-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749119082; x=1749723882; 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=CCGJJ+18Hx71qZ1BImD3aJBlrhNSiedNN3y6oo5smPU=;
        b=GF7X7+tlnFvyN8NA1zazfNKkCmtE8tJXNwAtEl/ikNEwstsyrDmJyO2gkW/mfHaZ07
         uvaznPONxsOeoasAiT0Rg0Gc01edBALulSUGNmokdMiHnsPVusu53HQ3LAjuj8vCksko
         w/oFolNP6wwlXQIKz46qo5/HQcMd5Evu3aJ0/PbabpsW+nGRQuRb8g90EEQ1BFhnRLUP
         nMRZgpGAPqkUVAekfIJJ7xUCxH8sxnlIs7FRNiFQFHcLrCgOTGDENt4lfmYdNjXa0jss
         fYKkSi852ee0UrmSenUERpG5mQQsrspSKSPmWXtaDmxQiy0tHfG/2x5Hrdic7fBUz/Os
         bVZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749119082; x=1749723882;
        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=CCGJJ+18Hx71qZ1BImD3aJBlrhNSiedNN3y6oo5smPU=;
        b=q8dOjvKBBfB6q7g+diJ3CdleyFGv8+S4gAOoriK1LwhNdxrM+scXkozW2jKbTWVT//
         b7nKmlrOfevl+GFAJDQN/UQ7DgXCySl2gRhYKQBLzo0mGswjxVDJlAUZ3FWq+UaY9h3P
         ocjZMtRtQt0Oi4357gX0o4ujQ84QrdIhBSM9teGhvZb6A9IA8U+zrAo9QcQ/HnrU0Pvy
         FlGoFvsWb5bYUtY8JHHgfDbREX59YwuB2nnNdIwR/LqiI0JGf45E5SE/3wLxbLznVmSh
         HXKbiR3FkcKmKw5kdv5Ndr4KxP4CnI4E1UN+CbpG4tR8rl8F1g0r+ua+X857dNLIDFul
         GUig==
X-Gm-Message-State: AOJu0YzXTVmAgOBTmQkYcbvmlpPK/Jz8dQihSkne5akcOuNg9T86AKBS
	2tRhMJF38E9uTZ92tP+3wc2Rqqvc6v3GI+h4YvLYCANcdoEpXWnoFkaak1O54RCtVoqDhnXYENv
	h5bw=
X-Gm-Gg: ASbGnctjKS1XuUg9/E/4T1jLEG+XTuoPPVYpl0dVAjKsTttkQdQIx/tsgz96vwZPn85
	VtG52AF6QWBPzz0i0G4CUL+m6ExYve2e7pZ7LdLLpiMvrk+q9HVPwuv72TAqXo9PXQWE9xIogQu
	KV8YOUKhNAXmDL8qFWROnU61ggbqhvvmqJsBjZa77c8SEHP6+2YnK4AwqRBrshtxZBRXhBnndH1
	Cttlc5RzZTj3jiiqSjPuZIwntAKId2HRrR88KeYkut2tAoZtz//Mmeu8k/OzSVU6mCq4lG72tn1
	G0xIa6cGoUoYGOq/pAKSD6CtyXlXykAjyzMncELJtHCDVCaGl9SxUW3T3nKfXaxBnrObbQlE6PV
	2pknlUH3mq7snQFF2QgKCk/9l8BZd8J1ySraEWXTX+aIOX18=
X-Google-Smtp-Source: AGHT+IHCcgv3vgC11pIaE8euNozBhtxqfc142zYW33hG7ykrV9v+UuFD9NqILRK4vpfVAlbQsyjLkA==
X-Received: by 2002:a05:6000:250f:b0:3a4:edad:2a59 with SMTP id ffacd0b85a97d-3a51d8f6a3bmr5700565f8f.1.1749119081922;
        Thu, 05 Jun 2025 03:24:41 -0700 (PDT)
Message-ID: 
Date: Thu, 5 Jun 2025 12:24:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v5 1/6] x86: suppress ERMS for internal use when
 MISC_ENABLE.FAST_STRING is clear
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <73481cbf-337f-4e85-81d2-3487366cd822@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: <73481cbf-337f-4e85-81d2-3487366cd822@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Before we start actually adjusting behavior when ERMS is available,
follow Linux commit 161ec53c702c ("x86, mem, intel: Initialize Enhanced
REP MOVSB/STOSB") and zap the CPUID-derived feature flag when the MSR
bit is clear. Don't extend the artificial clearing to guest view,
though: Guests can take their own decision in this regard, as they can
read (most of) MISC_ENABLE.

Signed-off-by: Jan Beulich 
---
TBD: Would be nice if "cpuid=no-erms" propagated to guest view (for
     "cpuid=" generally meaning to affect guests as well as Xen), but
     since both disabling paths use setup_clear_cpu_cap() they're
     indistinguishable in guest_common_feature_adjustments(). A separate
     boolean could take care of this, but would look clumsy to me.
---
v5: Correct guest_common_max_feature_adjustments() addition.
v4: Also adjust guest_common_max_feature_adjustments().
v3: New.

--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -366,8 +366,18 @@ static void cf_check early_init_intel(st
 		paddr_bits = 36;
 
 	if (c == &boot_cpu_data) {
+		uint64_t misc_enable;
+
 		check_memory_type_self_snoop_errata();
 
+		/*
+		 * If fast string is not enabled in IA32_MISC_ENABLE for any reason,
+		 * clear the enhanced fast string CPU capability.
+		 */
+		rdmsrl(MSR_IA32_MISC_ENABLE, misc_enable);
+		if (!(misc_enable & MSR_IA32_MISC_ENABLE_FAST_STRING))
+			setup_clear_cpu_cap(X86_FEATURE_ERMS);
+
 		intel_init_levelling();
 	}
 
--- a/xen/arch/x86/cpu-policy.c
+++ b/xen/arch/x86/cpu-policy.c
@@ -487,6 +487,12 @@ static void __init guest_common_max_feat
      */
     if ( test_bit(X86_FEATURE_RTM, fs) )
         __set_bit(X86_FEATURE_RTM_ALWAYS_ABORT, fs);
+
+    /*
+     * We expose MISC_ENABLE to guests, so our internal clearing of ERMS when
+     * FAST_STRING is not set should not affect the view of migrating-in guests.
+     */
+    __set_bit(X86_FEATURE_ERMS, fs);
 }
 
 static void __init guest_common_default_feature_adjustments(uint32_t *fs)
@@ -567,6 +573,16 @@ static void __init guest_common_default_
         __clear_bit(X86_FEATURE_RTM, fs);
         __set_bit(X86_FEATURE_RTM_ALWAYS_ABORT, fs);
     }
+
+    /*
+     * We expose MISC_ENABLE to guests, so our internal clearing of ERMS when
+     * FAST_STRING is not set should not propagate to guest view.  Guests can
+     * judge on their own whether to ignore the CPUID bit when the MSR bit is
+     * clear.  The bit being uniformly set in the max policies, we only need
+     * to clear it here (if hardware doesn't have it).
+     */
+    if ( !raw_cpu_policy.feat.erms )
+        __clear_bit(X86_FEATURE_ERMS, fs);
 }
 
 static void __init guest_common_feature_adjustments(uint32_t *fs)
--- a/xen/arch/x86/include/asm/msr-index.h
+++ b/xen/arch/x86/include/asm/msr-index.h
@@ -493,6 +493,7 @@
 #define MSR_IA32_THERM_INTERRUPT	0x0000019b
 #define MSR_IA32_THERM_STATUS		0x0000019c
 #define MSR_IA32_MISC_ENABLE		0x000001a0
+#define MSR_IA32_MISC_ENABLE_FAST_STRING  (1<<0)
 #define MSR_IA32_MISC_ENABLE_PERF_AVAIL   (1<<7)
 #define MSR_IA32_MISC_ENABLE_BTS_UNAVAIL  (1<<11)
 #define MSR_IA32_MISC_ENABLE_PEBS_UNAVAIL (1<<12)



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 10:25:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 10:25:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006548.1385747 (Exim 4.92)
	(envelope-from )
	id 1uN7mq-0004Gg-DQ; Thu, 05 Jun 2025 10:25:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006548.1385747; Thu, 05 Jun 2025 10:25: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 1uN7mq-0004GZ-A7; Thu, 05 Jun 2025 10:25:28 +0000
Received: by outflank-mailman (input) for mailman id 1006548;
 Thu, 05 Jun 2025 10:25: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 1uN7mo-00043g-N2
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 10:25: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 64a44cf5-41f7-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 12:25:25 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a375888297so533036f8f.1
 for ; Thu, 05 Jun 2025 03:25:25 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23506bc8b26sm116434025ad.9.2025.06.05.03.25.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 03:25:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 64a44cf5-41f7-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749119124; x=1749723924; 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=ODTNNGIVtgxD+7IVtLkWN/Ewp9sfVPUojE1+ozek4qQ=;
        b=a5qugSiNPUXk/XrjAYZnN+37X449OrmlTgSSnntCsc0hWPVL4eTTvvl3xnH/29yLAc
         HMoHOx+acffFA+P545esOq8Gy8X2SLsfa1AGXkzZDhmqS7G3QfS3bEjUnI0nhVrUGGpv
         NGupieYowRJmWWbjVk4zfyfh14GVxA2Y13qiOHMSUgYENQViwsShNw6PXnAZoZEo+PbL
         cWQ2nQeBg7NBfrKhrNGLgC+/Jezm0pVEKxKGNr/lhrbM0Isdth900g0ClH+W1CN0Ixmh
         t0okw58DHZo2ckYYI/og63dq8ORv1d9xFa2/VUm7iqMU1Xq1J9aO3+rloKdCIsEJsiSI
         jOkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749119124; x=1749723924;
        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=ODTNNGIVtgxD+7IVtLkWN/Ewp9sfVPUojE1+ozek4qQ=;
        b=TMl0X8MkEvm3TxvU9r3eEkB900mLow2gXVvVFS86Q21vOmCNAmivB8DVdSqqIuECfb
         76TYzwPHj/co4/xt9NBzhAcujSHlALkqLEqikDQHDPO4iQiST+KUK/2BZ1fiTynC289z
         zDJfLOIZbNqoTgJnlLA6T8cJ/1mG6mll7X9A81fUG8xIW2/SxHWEqcPoEQvgRhSi6Ttl
         vjL5r+eSEKoDYEoF/5yEG31SHb6dGhjHP761kHjmK2zervkoRqy5dw7DwXXNzZJYedQG
         8YjLRLsRyeH3DThFzE+eoPzKYBQUgZHKtmSYSy2MZ5NClZSTnS9wE9ywdoQS8U2+sUKB
         wOMQ==
X-Gm-Message-State: AOJu0YxCF2ydK8wDHgTocJxmti4alz1yNr63eSYYUNv+dXLVYth5SnRw
	FOSbckKsHLfKGr8AojCFpH6vgbl3rVu11B1nJ5qdZNyIVSM7n6W5rHYSF7TOe5ZOwo9qCuoSwgz
	GQyA=
X-Gm-Gg: ASbGnctF92kNcLhjJ4EcNNh68T5YJjKwaL5aFxS2EwYyAjtmH0d4TwrLAFNE6S+i/pz
	KliLU2fandFyM9J9PyCxNKabg8nLP71zVgtI3K8EhWCalSG17wFrPSQ5pmegKL7Z/BTmIuIcZ0h
	oyEYfZy0vgzoW0cmRvSnIqUOGsJrBbjsl/4uDqEgyXUiRweCkLo0FbDLNz9x/xQa6R2AM4DPULd
	weju4KJZrcZ/yl7e0e7+/aYqHhy4DaF0FF51XcknyBBS50shIdaWk+ZOt02CzQRzytUUBsX0R+7
	Z7DYGsK+EW2JEXYYVWQ7fjkagFib5IsW27mhoTdeYzvUOWnq2tZpvp+7bsFFbt/cM+6yk0fAAXf
	4/7sUYPKzvXwl8WugnxNPG7UkyoTRJOrgQqCl
X-Google-Smtp-Source: AGHT+IH/iUBcOUGxo/kZ1XOmLorzJ659k/mRMtiOrAHY23tAraBTACOClPoWtUOpiNH7ekY6pa8chQ==
X-Received: by 2002:a05:6000:2890:b0:3a4:e603:3d2 with SMTP id ffacd0b85a97d-3a526a84717mr2559856f8f.0.1749119124473;
        Thu, 05 Jun 2025 03:25:24 -0700 (PDT)
Message-ID: <4592a702-acf3-4229-9069-d5b639151657@suse.com>
Date: Thu, 5 Jun 2025 12:25:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v5 2/6] x86: re-work memset()
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <73481cbf-337f-4e85-81d2-3487366cd822@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: <73481cbf-337f-4e85-81d2-3487366cd822@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Move the function to its own assembly file. Having it in C just for the
entire body to be an asm() isn't really helpful. Then have two flavors:
A "basic" version using qword steps for the bulk of the operation, and an
ERMS version for modern hardware, to be substituted in via alternatives
patching.

For RET to be usable in an alternative's replacement code, extend the
CALL/JMP patching to cover the case of "JMP __x86_return_thunk" coming
last in replacement code.

Signed-off-by: Jan Beulich 
---
We may want to consider branching over the REP STOSQ as well, if the
number of qwords turns out to be zero.
We may also want to consider using non-REP STOS{L,W,B} for the tail.
---
v5: Re-base.
v4: Use %r8 instead of %rsi in a few places.
v3: Re-base.

--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_RETURN_THUNK) += indirect-t
 obj-$(CONFIG_PV) += ioport_emulate.o
 obj-y += irq.o
 obj-$(CONFIG_KEXEC) += machine_kexec.o
+obj-y += memset.o
 obj-y += mm.o x86_64/mm.o
 obj-$(CONFIG_VM_EVENT) += monitor.o
 obj-y += mpparse.o
--- a/xen/arch/x86/alternative.c
+++ b/xen/arch/x86/alternative.c
@@ -346,6 +346,12 @@ static int init_or_livepatch _apply_alte
         /* 0xe8/0xe9 are relative branches; fix the offset. */
         if ( a->repl_len >= 5 && (*buf & 0xfe) == 0xe8 )
             *(int32_t *)(buf + 1) += repl - orig;
+        else if ( IS_ENABLED(CONFIG_RETURN_THUNK) &&
+                  a->repl_len > 5 && buf[a->repl_len - 5] == 0xe9 &&
+                  ((long)repl + a->repl_len +
+                   *(int32_t *)(buf + a->repl_len - 4) ==
+                   (long)__x86_return_thunk) )
+            *(int32_t *)(buf + a->repl_len - 4) += repl - orig;
 
         a->priv = 1;
 
--- /dev/null
+++ b/xen/arch/x86/memset.S
@@ -0,0 +1,30 @@
+#include 
+
+.macro memset
+        and     $7, %edx
+        shr     $3, %rcx
+        movzbl  %sil, %esi
+        mov     $0x0101010101010101, %rax
+        imul    %rsi, %rax
+        mov     %rdi, %r8
+        rep stosq
+        or      %edx, %ecx
+        jz      0f
+        rep stosb
+0:
+        mov     %r8, %rax
+        RET
+.endm
+
+.macro memset_erms
+        mov     %esi, %eax
+        mov     %rdi, %r8
+        rep stosb
+        mov     %r8, %rax
+        RET
+.endm
+
+FUNC(memset)
+        mov     %rdx, %rcx
+        ALTERNATIVE memset, memset_erms, X86_FEATURE_ERMS
+END(memset)
--- a/xen/arch/x86/string.c
+++ b/xen/arch/x86/string.c
@@ -22,19 +22,6 @@ void *(memcpy)(void *dest, const void *s
     return dest;
 }
 
-void *(memset)(void *s, int c, size_t n)
-{
-    long d0, d1;
-
-    asm volatile (
-        "rep stosb"
-        : "=&c" (d0), "=&D" (d1)
-        : "a" (c), "1" (s), "0" (n)
-        : "memory");
-
-    return s;
-}
-
 void *(memmove)(void *dest, const void *src, size_t n)
 {
     long d0, d1, d2;



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 10:25:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 10:25:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006554.1385756 (Exim 4.92)
	(envelope-from )
	id 1uN7nI-0004o3-PL; Thu, 05 Jun 2025 10:25:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006554.1385756; Thu, 05 Jun 2025 10: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 1uN7nI-0004nw-Mp; Thu, 05 Jun 2025 10:25:56 +0000
Received: by outflank-mailman (input) for mailman id 1006554;
 Thu, 05 Jun 2025 10: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 1uN7nH-00043g-5j
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 10:25: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 75ab4638-41f7-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 12:25:53 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-451dbe494d6so8992725e9.1
 for ; Thu, 05 Jun 2025 03:25:53 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-747afeabc2dsm12994333b3a.65.2025.06.05.03.25.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 03:25:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 75ab4638-41f7-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749119153; x=1749723953; 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=Kzfk8kOPjucUBtuwDsuMCecezBv2uHiBq7/jphCJyvE=;
        b=BT9XNNNh3KTFaXwaAfAArbWCTKHWj3wOoT9qXhcfedbcLmkvq8ZKmRnt2HeQzNHdBo
         lyP7xMOZhEK5vPzj0HBH726Oo/jA32U/yLRag5A2O5Tc8LdWZp6sEc3DLGnvc8mo0R5t
         cgaU158UxQ2+br+T69Ud3Up6wD3lDXZGk6QICszGqqlowa43XVbCPjBn3nnbzQ28C4k8
         fid5n3/8lXSFT1IZCOYAtWCyCOJbwztQUtpC2hkghWAuVzV3P7CcHWfDuPvx2jwc6gXA
         vpqrVXBj5sCyyA/Q/JxJ3B0qPsfRYovichzZ4cMRL3AJDjgcbln2y8Yb7aCclUWVsgLx
         F7WA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749119153; x=1749723953;
        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=Kzfk8kOPjucUBtuwDsuMCecezBv2uHiBq7/jphCJyvE=;
        b=MTfQiFYNXGUrkSfexAWTSaEQNf5lezHIkzSXFnuWwJHGwqd3625k0MUvK1YuG9sqiv
         V9XZX4badaA3tmpkHsL6gDiXqWYQ0z6dM3C8Qoqm6vaid3DN1xScC4DDAzokV6vuwh0e
         8ehDoEtbuo0qbYfS/u9SeHDlCW2uM8YvtNpOyF5PSHVfHtkS9Emj20N5oiNr9MAcocWk
         bGEDJpsquamOtx1xDgneJEIt/MI8wNv8NSb0LK0H3dKpj5a6Zm9P9RfjFWsrNcrz6A8Q
         3F7duoyXhDgvUhdB1Q3kuz4Nppa9WfSZVytrSlb0cOw7NkVa5wKnmpDv3qCGo8ZAZMnS
         m5vg==
X-Gm-Message-State: AOJu0Yx8YWsdYpkf7C5IkO5vnLENvSMU/bUCzwxee4b7/qJTerTndb0O
	JJN3xAWc0RDgsksNjllUoOzQyQGTi411ABCgSFIt952PRHz6gFP3K1S8ZkgPCVL1FNPwduX3ro/
	5vK8=
X-Gm-Gg: ASbGncusAN3NPng1/5BoUQ8GQ277hKgeDCA0X83XzZl00qLtJhdhYy20DQj/5HkGCQh
	YToORmTG1e3VbzQcYf6X3D1x8lZhWvI27nrZSVpBrddfsoily/2LILa6mHPhOemc661YxqrQS0+
	NxMQ1qvrYaH8HUk9MC2wUcRNIEeAZinTz1HoSZQzMUeDtcXiaqsSm5C60rDVlxw/KeRna5YoPW2
	duJ6dHAffQ7ZEK8d6oaR4gS5XUvYAU+9RFxA53w5GFz53xVOgdPlrR4U4cNB0K4ni6JlyBR+kGo
	yOazApC+Z91q5s2apMmC4zHgpv3JKEluXF/e1T1jz0/GuLXaDQSfd8C7hvMQNcLd7CoMcOnQulg
	jEh9iuRoWa0mCw9UPYJy1iZncve1i/9V8NWkq1/hNWmuL1Uc=
X-Google-Smtp-Source: AGHT+IE6OiHLhwrRi590UFvEmq1U+3Yvi/OE0meUH/K8SbPo9CJPv30sHVwgWqAXwtobtk/mFAF5gg==
X-Received: by 2002:a05:6000:4387:b0:3a5:276b:1ec7 with SMTP id ffacd0b85a97d-3a5276b2066mr2200737f8f.7.1749119152974;
        Thu, 05 Jun 2025 03:25:52 -0700 (PDT)
Message-ID: <017e689a-41a2-4722-a5e7-19ffef27500f@suse.com>
Date: Thu, 5 Jun 2025 12:25:46 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v5 3/6] x86: re-work memcpy()
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <73481cbf-337f-4e85-81d2-3487366cd822@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: <73481cbf-337f-4e85-81d2-3487366cd822@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Move the function to its own assembly file. Having it in C just for the
entire body to be an asm() isn't really helpful. Then have two flavors:
A "basic" version using qword steps for the bulk of the operation, and an
ERMS version for modern hardware, to be substituted in via alternatives
patching.

Alternatives patching, however, requires an extra precaution: It uses
memcpy() itself, and hence the function may patch itself. Luckily the
patched-in code only replaces the prolog of the original function. Make
sure this remains this way.

Additionally alternatives patching, while supposedly safe via enforcing
a control flow change when modifying already prefetched code, may not
really be. Afaict a request is pending to drop the first of the two
options in the SDM's "Handling Self- and Cross-Modifying Code" section.
Insert a serializing instruction there.

Signed-off-by: Jan Beulich 
---
We may want to consider branching over the REP MOVSQ as well, if the
number of qwords turns out to be zero.
We may also want to consider using non-REP MOVS{L,W,B} for the tail.

TBD: We may further need a workaround similar to Linux'es 8ca97812c3c8
     ("x86/mce: Work around an erratum on fast string copy
     instructions").

TBD: Some older AMD CPUs have an issue with REP MOVS when source and
     destination are misaligned with one another (modulo 32?), which may
     require a separate memcpy() flavor.
---
v5: Re-base.
v4: Use CR2 write as serializing insn, and limit its use to boot time.
v3: Re-base.

--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_RETURN_THUNK) += indirect-t
 obj-$(CONFIG_PV) += ioport_emulate.o
 obj-y += irq.o
 obj-$(CONFIG_KEXEC) += machine_kexec.o
+obj-y += memcpy.o
 obj-y += memset.o
 obj-y += mm.o x86_64/mm.o
 obj-$(CONFIG_VM_EVENT) += monitor.o
--- a/xen/arch/x86/alternative.c
+++ b/xen/arch/x86/alternative.c
@@ -195,12 +195,16 @@ void *place_ret(void *ptr)
  * executing.
  *
  * "noinline" to cause control flow change and thus invalidate I$ and
- * cause refetch after modification.
+ * cause refetch after modification.  While the SDM continues to suggest this
+ * is sufficient, it may not be - issue a serializing insn afterwards as well,
+ * unless this is for live-patching.
  */
 static void init_or_livepatch noinline
 text_poke(void *addr, const void *opcode, size_t len)
 {
     memcpy(addr, opcode, len);
+    if ( system_state < SYS_STATE_active )
+        asm volatile ( "mov %%rax, %%cr2" ::: "memory" );
 }
 
 extern void *const __initdata_cf_clobber_start[];
--- /dev/null
+++ b/xen/arch/x86/memcpy.S
@@ -0,0 +1,20 @@
+#include 
+
+FUNC(memcpy)
+        mov     %rdx, %rcx
+        mov     %rdi, %rax
+        /*
+         * We need to be careful here: memcpy() is involved in alternatives
+         * patching, so the code doing the actual copying (i.e. past setting
+         * up registers) may not be subject to patching (unless further
+         * precautions were taken).
+         */
+        ALTERNATIVE "and $7, %edx; shr $3, %rcx", \
+                    STR(rep movsb; RET), X86_FEATURE_ERMS
+        rep movsq
+        or      %edx, %ecx
+        jz      1f
+        rep movsb
+1:
+        RET
+END(memcpy)
--- a/xen/arch/x86/string.c
+++ b/xen/arch/x86/string.c
@@ -7,21 +7,6 @@
 
 #include 
 
-void *(memcpy)(void *dest, const void *src, size_t n)
-{
-    long d0, d1, d2;
-
-    asm volatile (
-        "   rep ; movs"__OS" ; "
-        "   mov %k4,%k3      ; "
-        "   rep ; movsb        "
-        : "=&c" (d0), "=&D" (d1), "=&S" (d2)
-        : "0" (n/BYTES_PER_LONG), "r" (n%BYTES_PER_LONG), "1" (dest), "2" (src)
-        : "memory" );
-
-    return dest;
-}
-
 void *(memmove)(void *dest, const void *src, size_t n)
 {
     long d0, d1, d2;



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 10:26:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 10:26:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006561.1385767 (Exim 4.92)
	(envelope-from )
	id 1uN7oI-0005Mz-23; Thu, 05 Jun 2025 10:26:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006561.1385767; Thu, 05 Jun 2025 10: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 1uN7oH-0005Ms-VV; Thu, 05 Jun 2025 10:26:57 +0000
Received: by outflank-mailman (input) for mailman id 1006561;
 Thu, 05 Jun 2025 10:26: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 1uN7oG-0005Mk-O4
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 10:26:56 +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 9a962fb2-41f7-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 12:26:55 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3a525eee2e3so526060f8f.2
 for ; Thu, 05 Jun 2025 03:26:55 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3132bff6688sm1224745a91.5.2025.06.05.03.26.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 03:26:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9a962fb2-41f7-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749119215; x=1749724015; 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=1v47NjpfklYXAFnt1Xg3d5eW/3aEbLVULucn4vLD+N4=;
        b=DosBO0Gz/81wa4HianKDWqliA/kzP8Hmlif+/6lWy/w6zVMaKGmDeJHQl5AnhKQjGF
         qVv9Grygcoane414JhCa+lfH3qCgfEOcO90jbpu4cK4Y4H3JxYqw7MdVuASevyCM7Zgv
         11vDG89LTR79B1DBdi44R1rqvFSdIVibBTqugwNn29NOGgZd2iPALQGgpbyesBisIuwN
         WQk/i0hmj+2DQ26XGsQo1O/jghH3vHDYc9TGjtbdftMoQGNP1bMIA5xoIJ7yHm5hsElJ
         +nDfAYtPtX1amfXwsto4y3OmPduxhV8gzThsQyxClUdbcnsasJ1NVzd996krZ2KxkMIW
         nX6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749119215; x=1749724015;
        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=1v47NjpfklYXAFnt1Xg3d5eW/3aEbLVULucn4vLD+N4=;
        b=htM6StGGG68s9btcBf3hwCdfTyzKKry/k2KiuiiZdhFJPaoodkLcfN1iAgZn6UEz+K
         MiaLadxTZ6yDIH0NeYfZewpNLz3J+H9fmXJP8EW3rKqbOJigVwhb0ue7iov9WVpWtZyq
         2QjvKY6XqzRko5/Z0ZwlV1cqYehmF6C49D33p+KfJ31k0BskjMGs0ZYMtSVPl1fcCz5X
         HI5ZrdazXcd7GwiRqTiwfMqULUgMUs5nDwWjAcgzGVdMt2lKvx5fAsYrRkvDq27B5RIM
         U4drxF6UM3pTRSPFAM+Msf2tF+TilAMRE37AgNK0D7DCvINhCGAUrWk8moExNxoBtTVK
         2VAg==
X-Gm-Message-State: AOJu0YyJML73KVBbnqdJS9qAkugCsyXstQPd2JhGaLRkJrGJEWGtRkPl
	rVI0ymUf+UQtzz85aMjyvOfBHK5Q1Jtj3j0RgstWMDNPlVMCAceug9zdmXwctxRVVeqRfhQRHXt
	05Kw=
X-Gm-Gg: ASbGncuGJJ5xKEpH0MvqxKw7movLJhYY/4wUQj0VDN8/B7c/V6ArA31mrfBljLVPhvS
	eiMvgt0DHimaz453vLWNcYnUuMFrZOFAMbCWoinjY9MhPTcWSjP2/aO3aezzdveOg4GRyNSVXVZ
	2HGOviOIpLWhbqr4YXDPU9OQO37UMleRbcHxJKyzjEzFObi0GEoIpa9NU/b/sB1cdYoanrUKDxy
	ctMM56wBfak89XuJaF80PUpcRlHNdDoQ6C/xLxiYUjb4ndH0hbyFW6iq9YodvTPXysbkJM2f8g6
	v4I9FS0U1JMIl21zyAiSc4Gr8wSRuys01JhJx4O4lL6kbmRcj4DbHjKshea2HcZXo40xFvoCGkr
	vFU6vgFdbS6CzK3+JB4so7YR5nl0J/e3CNoyWHc87pMVNYc0=
X-Google-Smtp-Source: AGHT+IHeyyS21Ai+7nJZfxT9YbsjuA/gqHmUIi2J+XzzBjGSD6NPvK+8TuhRB9TSp5IKQQ1CoUx/KA==
X-Received: by 2002:a05:6000:2c11:b0:3a4:f63b:4bfc with SMTP id ffacd0b85a97d-3a51d961af6mr5282398f8f.34.1749119215013;
        Thu, 05 Jun 2025 03:26:55 -0700 (PDT)
Message-ID: 
Date: Thu, 5 Jun 2025 12:26:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v5 4/6] x86: control memset() and memcpy() inlining
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <73481cbf-337f-4e85-81d2-3487366cd822@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: <73481cbf-337f-4e85-81d2-3487366cd822@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Stop the compiler from inlining non-trivial memset() and memcpy() (for
memset() see e.g. map_vcpu_info() or kimage_load_segments() for
examples). This way we even keep the compiler from using REP STOSQ /
REP MOVSQ when we'd prefer REP STOSB / REP MOVSB (when ERMS is
available).

With gcc10 this yields a modest .text size reduction (release build) of
around 2k.

Unfortunately these options aren't understood by the clang versions I
have readily available for testing with; I'm unaware of equivalents.

Note also that using cc-option-add is not an option here, or at least I
couldn't make things work with it (in case the option was not supported
by the compiler): The embedded comma in the option looks to be getting
in the way.

Requested-by: Andrew Cooper 
Signed-off-by: Jan Beulich 
---
v3: Re-base.
v2: New.
---
The boundary values are of course up for discussion - I wasn't really
certain whether to use 16 or 32; I'd be less certain about using yet
larger values.

Similarly whether to permit the compiler to emit REP STOSQ / REP MOVSQ
for known size, properly aligned blocks is up for discussion.

--- a/xen/arch/x86/arch.mk
+++ b/xen/arch/x86/arch.mk
@@ -58,6 +58,9 @@ endif
 $(call cc-option-add,CFLAGS_stack_boundary,CC,-mpreferred-stack-boundary=3)
 export CFLAGS_stack_boundary
 
+CFLAGS += $(call cc-option,$(CC),-mmemcpy-strategy=unrolled_loop:16:noalign$(comma)libcall:-1:noalign)
+CFLAGS += $(call cc-option,$(CC),-mmemset-strategy=unrolled_loop:16:noalign$(comma)libcall:-1:noalign)
+
 ifeq ($(CONFIG_UBSAN),y)
 # Don't enable alignment sanitisation.  x86 has efficient unaligned accesses,
 # and various things (ACPI tables, hypercall pages, stubs, etc) are wont-fix.



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 10:27:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 10:27:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006567.1385776 (Exim 4.92)
	(envelope-from )
	id 1uN7p6-0005tS-A4; Thu, 05 Jun 2025 10:27:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006567.1385776; Thu, 05 Jun 2025 10:27: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 1uN7p6-0005tJ-7J; Thu, 05 Jun 2025 10:27:48 +0000
Received: by outflank-mailman (input) for mailman id 1006567;
 Thu, 05 Jun 2025 10:27: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 1uN7p5-0005gE-RD
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 10:27:47 +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 b8c026f8-41f7-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 12:27:46 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-43edecbfb46so5597785e9.0
 for ; Thu, 05 Jun 2025 03:27:46 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-747afff7459sm12501568b3a.169.2025.06.05.03.27.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 03:27:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b8c026f8-41f7-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749119265; x=1749724065; 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=uAx+h4vdQMnFmuPeDTCptQ0FqB53/bxqCnS75yppj5g=;
        b=D1ramRQt7YUhBQsQAK5+2I3EbpoHJsHf5j2KPwuOB/HJTk2cw2MZy/rbUoAr8iFkwJ
         rDkJeqyuEa/eEtB6Q2yeiRNYIY0VK9o7d2QeP8cm/qcyEJz3Faz3gZJS5vMsvtuE5X6V
         kKVry0Zg+BTdLEf5G5vb9ds4YTEIwvH9WAnB4Mcvj1IVCV2TTVIuFLrc1tnqWFD93Dbg
         WNoESLP+KBRn9OBb+XoIVDmsxI82/nOaSuN9QONFiW5fZf3TCBHOYQAbOQyuJS+9AbsF
         2VKetl4j2xy4RG1mLWxwv/SWoVHYZ7XJHZVBz63avH2f6Z6jQOzIUU3SUNkD0qkvyK12
         DZmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749119265; x=1749724065;
        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=uAx+h4vdQMnFmuPeDTCptQ0FqB53/bxqCnS75yppj5g=;
        b=vVrncCVx5uWms6yv2fyE3XDy9scPq+RZsSyFFpe3el1hpLbTgnh3f+OvZgLJxELGMm
         aS45Ao1sPHHhkG3nkv/KWs0971eeuALGbJY4Kxw2wwEOCkJwxaAR4z/I3VrQYAsRYGtl
         OpN5O/Ci3VLN9a95IOQUohJeXWsbVCEQ2Nw65hR4oS0/gpdEuErjR84zUhS5kR/Qc5+F
         4nlVWvILArZZVNxrHvTUvLuUcAqRwkZ79LJJUhinc8+9/vqCa+KLcnCTKCYIihTEbmzl
         vR3SBjWyu8y1bVbN5Ln4SbZYvMmWic6oiQXV1w3XAr3NKIqKsfR7F9DG8vKe+LQky+sR
         wkLQ==
X-Gm-Message-State: AOJu0YzmTsWXZXlWIK2KNJ+52Wu7wVygzT0LuO147opMkjKuCl0979Kr
	jMDAn2xnaP45DmrfQMLtyqjRkgfCyX/oEKMSIAUUOfKgrL5uUHYXV2/oP3CDfEw2NuMm4JWDMtE
	86js=
X-Gm-Gg: ASbGncv6yU/HJkA7iPgSnj1lYBSRmMEeYSb8RKi3tpzqsQp9usZHkesPQYmLPhFvKyH
	4Eci13wSAltny2O5wqnOHv+4b6fJCswDp5bke5GBzX7ymE86xXJ/XnjbPGONv9xDVg7xXVuWOIf
	S8UzAZKzvcGG8P7MH+jwg4Lilg7H4BxWXv6t57IDPvtyAuc/XdqHtApCTsXddBjMX/cuKP8a1NF
	B0/5G7PoQ2KF/L2Zay5Qq/Sz4APuDHLPOGLu9JnqrpvgFM1i1YDGDnpq7yktbjNaCjWQcDfIkFh
	njSvXDNjv4eHQT7p9vqGjtpBPTox0l3EYThP0ezsbtIAbxKoHhuxaNZlmoWo6HAWWra5nkUfAAM
	BCzZ0L1Ad2lX4uamjct/dGWpEGN/OVA+8MFnnXYugYxnlN6U=
X-Google-Smtp-Source: AGHT+IETgYM/WluMPaHlS/7Qy8wCK4I2i4OlczpWppxKMCL04DAhHEP67cEjUObBzP6EtYif7E9F+Q==
X-Received: by 2002:a05:6000:2c10:b0:3a4:f8fa:9c94 with SMTP id ffacd0b85a97d-3a51d91ff46mr5283128f8f.13.1749119265441;
        Thu, 05 Jun 2025 03:27:45 -0700 (PDT)
Message-ID: <5fd7631c-a7aa-438b-ae7e-7f35af65cef2@suse.com>
Date: Thu, 5 Jun 2025 12:27:38 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v5 5/6] x86: introduce "hot" and "cold" page clearing
 functions
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <73481cbf-337f-4e85-81d2-3487366cd822@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: <73481cbf-337f-4e85-81d2-3487366cd822@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

The present clear_page_sse2() is useful in case a page isn't going to
get touched again soon, or if we want to limit churn on the caches.
Amend it by alternatively using CLZERO, which has been found to be quite
a bit faster on Zen2 hardware at least. Note that to use CLZERO, we need
to know the cache line size, and hence a feature dependency on CLFLUSH
gets introduced.

For cases where latency is the most important aspect, or when it is
expected that sufficiently large parts of a page will get accessed again
soon after the clearing, introduce a "hot" alternative. Again use
alternatives patching to select between a "legacy" and an ERMS variant.

Don't switch any callers just yet - this will be the subject of
subsequent changes.

Signed-off-by: Jan Beulich 
---
v5: Re-base.
v3: Re-base.
v2: New.
---
Note: Ankur indicates that for ~L3-size or larger regions MOVNT/CLZERO
      is better even latency-wise.

--- a/xen/arch/x86/clear_page.S
+++ b/xen/arch/x86/clear_page.S
@@ -5,7 +5,7 @@
 #include 
 #include 
 
-FUNC(clear_page_sse2)
+        .macro clear_page_sse2
         mov     $PAGE_SIZE/32, %ecx
         xor     %eax,%eax
 
@@ -19,4 +19,42 @@ FUNC(clear_page_sse2)
 
         sfence
         RET
-END(clear_page_sse2)
+        .endm
+
+        .macro clear_page_clzero
+        mov     %rdi, %rax
+        mov     $PAGE_SIZE/64, %ecx
+        .globl clear_page_clzero_post_count
+clear_page_clzero_post_count:
+
+0:      clzero
+        sub     $-64, %rax
+        .globl clear_page_clzero_post_neg_size
+clear_page_clzero_post_neg_size:
+        sub     $1, %ecx
+        jnz     0b
+
+        sfence
+        RET
+        .endm
+
+FUNC(clear_page_cold)
+        ALTERNATIVE clear_page_sse2, clear_page_clzero, X86_FEATURE_CLZERO
+END(clear_page_cold)
+
+        .macro clear_page_stosb
+        mov     $PAGE_SIZE, %ecx
+        xor     %eax,%eax
+        rep stosb
+        .endm
+
+        .macro clear_page_stosq
+        mov     $PAGE_SIZE/8, %ecx
+        xor     %eax, %eax
+        rep stosq
+        .endm
+
+FUNC(clear_page_hot)
+        ALTERNATIVE clear_page_stosq, clear_page_stosb, X86_FEATURE_ERMS
+        RET
+END(clear_page_hot)
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -60,6 +60,9 @@ DEFINE_PER_CPU(bool, full_gdt_loaded);
 
 DEFINE_PER_CPU(uint32_t, pkrs);
 
+extern uint32_t clear_page_clzero_post_count[];
+extern int8_t clear_page_clzero_post_neg_size[];
+
 void __init setup_clear_cpu_cap(unsigned int cap)
 {
 	const uint32_t *dfs;
@@ -357,8 +360,38 @@ void __init early_cpu_init(bool verbose)
 
 	edx &= ~cleared_caps[FEATURESET_1d];
 	ecx &= ~cleared_caps[FEATURESET_1c];
-	if (edx & cpufeat_mask(X86_FEATURE_CLFLUSH))
-		c->x86_cache_alignment = ((ebx >> 8) & 0xff) * 8;
+	if (edx & cpufeat_mask(X86_FEATURE_CLFLUSH)) {
+		unsigned int size = ((ebx >> 8) & 0xff) * 8;
+
+		c->x86_cache_alignment = size;
+
+		/*
+		 * Patch in parameters of clear_page_cold()'s CLZERO
+		 * alternative. Note that for now we cap this at 128 bytes.
+		 * Larger cache line sizes would still be dealt with
+		 * correctly, but would cause redundant work done.
+		 */
+		if (size > 128)
+			size = 128;
+		if (size && !(size & (size - 1))) {
+			/*
+			 * Need to play some games to keep the compiler from
+			 * recognizing the negative array index as being out
+			 * of bounds. The labels in assembler code really are
+			 * _after_ the locations to be patched, so the
+			 * negative index is intentional.
+			 */
+			uint32_t *pcount = clear_page_clzero_post_count;
+			int8_t *neg_size = clear_page_clzero_post_neg_size;
+
+			OPTIMIZER_HIDE_VAR(pcount);
+			OPTIMIZER_HIDE_VAR(neg_size);
+			pcount[-1] = PAGE_SIZE / size;
+			neg_size[-1] = -size;
+		}
+		else
+			setup_clear_cpu_cap(X86_FEATURE_CLZERO);
+	}
 	/* Leaf 0x1 capabilities filled in early for Xen. */
 	c->x86_capability[FEATURESET_1d] = edx;
 	c->x86_capability[FEATURESET_1c] = ecx;
--- a/xen/arch/x86/include/asm/asm-defns.h
+++ b/xen/arch/x86/include/asm/asm-defns.h
@@ -1,5 +1,9 @@
 #include 
 
+.macro clzero
+    .byte 0x0f, 0x01, 0xfc
+.endm
+
 /*
  * Call a noreturn function.  This could be JMP, but CALL results in a more
  * helpful backtrace.  BUG is to catch functions which do decide to return...
--- a/xen/arch/x86/include/asm/page.h
+++ b/xen/arch/x86/include/asm/page.h
@@ -219,10 +219,11 @@ typedef struct { u64 pfn; } pagetable_t;
 #define pagetable_from_paddr(p) pagetable_from_pfn((p)>>PAGE_SHIFT)
 #define pagetable_null()        pagetable_from_pfn(0)
 
-void clear_page_sse2(void *pg);
+void clear_page_hot(void *pg);
+void clear_page_cold(void *pg);
 void copy_page_sse2(void *to, const void *from);
 
-#define clear_page(_p)      clear_page_sse2(_p)
+#define clear_page(_p)      clear_page_cold(_p)
 #define copy_page(_t, _f)   copy_page_sse2(_t, _f)
 
 /* Convert between Xen-heap virtual addresses and machine addresses. */
--- a/xen/tools/gen-cpuid.py
+++ b/xen/tools/gen-cpuid.py
@@ -212,6 +212,10 @@ def crunch_numbers(state):
         # the first place.
         APIC: [X2APIC, TSC_DEADLINE, EXTAPIC],
 
+        # The CLZERO insn requires a means to determine the cache line size,
+        # which is tied to the CLFLUSH insn.
+        CLFLUSH: [CLZERO],
+
         # AMD built MMXExtentions and 3DNow as extentions to MMX.
         MMX: [MMXEXT, _3DNOW],
 



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 10:28:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 10:28:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006571.1385786 (Exim 4.92)
	(envelope-from )
	id 1uN7pS-0006KS-J9; Thu, 05 Jun 2025 10:28:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006571.1385786; Thu, 05 Jun 2025 10:28: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 1uN7pS-0006KL-GO; Thu, 05 Jun 2025 10:28:10 +0000
Received: by outflank-mailman (input) for mailman id 1006571;
 Thu, 05 Jun 2025 10:28: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 1uN7pR-0006Ay-La
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 10:28:09 +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 c6467d7b-41f7-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 12:28:08 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-442ea341570so5007775e9.1
 for ; Thu, 05 Jun 2025 03:28:08 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-451fb208274sm13761535e9.22.2025.06.05.03.28.07
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 03:28:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c6467d7b-41f7-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749119288; x=1749724088; 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=H+DbnJ8CZ9+daFhn/guZIDqh4rHu3fH48iQ0nlx2hmo=;
        b=MrNVpftT7jIXDXRO5KSN9bmm6fKWJEjHlC4dXficEv3P4sDNXfAgtr+HeKyi+vUJda
         Ocj30tsHzos0zQLD+YS+CfrPevYsd/I5RPp/078nwcnD3COatc1B36FT9aPBEaaT1PYG
         EHfDHrrFoxwjh0WkpwnKndr/Ho6dGyE47TI/g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749119288; x=1749724088;
        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=H+DbnJ8CZ9+daFhn/guZIDqh4rHu3fH48iQ0nlx2hmo=;
        b=pTaSFNRKiDSWXht/RyTeXcgncPgXdRDxhDvaR2jWKUrQY7O90mPkdZxCXOnZljL4uW
         9VE8aMgns5qWCViOn6IxMQOw39wtATLStjrepUgJ921F66QGEJaMlCs/fz5VDg8/XIGL
         SmLAv8hlXgGb+K4KUlVh+VADnKWUy6ABQRC/1CwyuvebTlColxj1zcEkFguHsrTsyPIm
         urSGOkOEANgMvRGrNjBZElQtlOEekBUczCbh25yci3WVhJE0yU6/OtsqcxX+UE3bXNK2
         kXDmcEV9JJLDFYVTk8XiVJhCMQFyXtZ/SJHnCZWkcpOPpUfxiXpwQVC9SI3nFcSQ+oBS
         TZkQ==
X-Gm-Message-State: AOJu0YyEb+d2BpnNKhFH7WiJSPfiE5q87nmaHRvg0s6MhdlIUOkVLvBi
	MMbVS/UoPhUxdBVK4NtMu3IhSQy734HXH0IBoiDIqGo5whz6nIKmOEAi6k7wLywKg6LZ3+LIJrk
	oQqHJ
X-Gm-Gg: ASbGncsgMKwKVpm3qaV3W5G9tkuaog1KQoWTlQD2us1304FBVzKpSmTb3Q48+kbo8i2
	yhEaEJfS+W234dKlrx6JkfQSTa7qhRxOQLgI9OdAMxa0dKw71EfxR85mvwejKKAGTWlz96dpfKw
	H7ssmULIZoAhvfGlyfSXAvRzE++xR43Pbg8w2XY4K3jZbdWSQNGc5MNSuzdQXemmYOo9tGAK/j3
	z1s8Z3V+j5lgpeZRD3Pn/uq0gdnmlawQGXr0U7MvHHcfxDWmvl7P7vAzMBQrbAu1ziLXQubOHsh
	DR9As3LskpdlO9LxbvaiDsgPAjkyTfwAPCZiOh9V5OTCPJSJw76VhRcJqZ8ktKq+YWcDtXj+AkZ
	UFaQAJxnEOqKxQyShAgw=
X-Google-Smtp-Source: AGHT+IE5GScrLKlUIrCVt3HKL/M8lp3gSQ/9SCOSf1mFMOgYwdmLXkH7cUn5xGXxaoJto726Ihty1g==
X-Received: by 2002:a05:600c:46d1:b0:450:d5f6:55f5 with SMTP id 5b1f17b1804b1-451f0a6a475mr58883185e9.6.1749119288328;
        Thu, 05 Jun 2025 03:28:08 -0700 (PDT)
Date: Thu, 5 Jun 2025 12:28:07 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Stewart Hildebrand 
Cc: xen-devel@lists.xenproject.org
Subject: Re: [PATCH v1 4/5] vpci: use separate rangeset for BAR unmapping
Message-ID: 
References: <20250531125405.268984-1-stewart.hildebrand@amd.com>
 <20250531125405.268984-5-stewart.hildebrand@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250531125405.268984-5-stewart.hildebrand@amd.com>

On Sat, May 31, 2025 at 08:54:02AM -0400, Stewart Hildebrand wrote:
> Introduce a new per-BAR rangeset, unmap_mem, for p2m unmapping. Rename
> existing mem rangeset to map_mem, which is now only used for mapping.
> Populate unmap_mem by moving just-mapped ranges from map_mem to
> unmap_mem. In modify_bars(), skip recalculating the ranges when
> unmapping as they are already stored in unmap_mem.

I'm afraid the copying of ranges from map_mem to unmap_mem is not fully
correct.

The calculations in modify_bars() take into account overlaps between
BARs.  Given the following set of actions:

1. Map dev#0 BAR0.
2. Cache mapped regions for dev#0 BAR0.
3. Map dev#1 BAR0 that overlaps with dev#0 BAR0.
4. Unmap dev#0 BAR0 using the cached regions.

The unmap of dev#0 BAR0 will also have the side-effect of unmapping
dev#1 BAR0, which is wrong.  That's why modify_bars() must be called
for every map and unmap operation.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 10:28:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 10:28:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006582.1385798 (Exim 4.92)
	(envelope-from )
	id 1uN7q6-0006wM-07; Thu, 05 Jun 2025 10:28:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006582.1385798; Thu, 05 Jun 2025 10:28: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 1uN7q5-0006wF-SR; Thu, 05 Jun 2025 10:28:49 +0000
Received: by outflank-mailman (input) for mailman id 1006582;
 Thu, 05 Jun 2025 10:28: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 1uN7q4-0006Ay-TC
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 10:28:49 +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 dd8a412d-41f7-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 12:28:48 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3a35c894313so678430f8f.2
 for ; Thu, 05 Jun 2025 03:28:47 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-313319d45dfsm971765a91.32.2025.06.05.03.28.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 03:28:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: dd8a412d-41f7-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749119327; x=1749724127; 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=4eEicFsdYkA5hJ8hFbKaqmBk1yERZphW9t6IYOWNxpY=;
        b=V9qzNbxkTnTPZSrk2mJzfGUX6VUlXCvExlosxw6e8L1oPsI5RijIhA2PxM3j9thEIT
         r4Lsnsbe7YcekE3zOfwbGzWDDU9sZ7i0UHhNya39+CDBdzqMcFlsRHb2oGw7JrE964nr
         sToHE7h4w1wPnWCG+ISKaYOmezmkjVKJTPF4A2PP6AMVwR6njY8Gb5XLtFcC9mOe4CXd
         xdcYJOSumhkChMeXTd+JgEZeFx2iqVew5Ldv4dp5dOzYb9Q2rhIEyyT4C6g1jNxqjRk/
         G7b+PCrV2sxTKMo9u43vcyxVU02Rck4q72gYOyrD6dHogzbtnu/dyUiWF6s/b5O0Jkdr
         UoIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749119327; x=1749724127;
        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=4eEicFsdYkA5hJ8hFbKaqmBk1yERZphW9t6IYOWNxpY=;
        b=MKS+nvJoARKN6P8+kL/iNtxs5hdG5d1uT27QV2PyTjioWzoG8vMQaVqBayOx9jgOcL
         DjLfm+EtSfqvUxIjm2zcFTZM+0+E9EnxgS8sr6xZlafH0NETrr/scufLGE1Jr3RxVrhY
         QAAP/6CTLb8srBMjC9rJn1FOWk2PP9CKi/CMPRRYbGBJ/K80AqNnIUdsn2JuED5XPOWl
         R0JBGuP2B/gGGCW3AQVvtD2vUvc8aII3Uv2p60vVwQpDgSgGLu4F90Ue/t+Yfp5Zous2
         LIEpsXd5ZRpPt/QuV1R4A8nCeWuetAjLmsE8sOgF8s5vebocZGFdrePEXJOt1jJgJXdp
         JqOg==
X-Gm-Message-State: AOJu0Yw3x5KvlsBLY/wrH/I7QhoY4z0OohuYgdd9Gb9L1norqhRi3jlI
	/XWOaEAyscViaJLTQznYlyLE7Dcpd8JnK4Ea7NeR91DgBuoWVQKbBbsSNE3kW4zD0lDiA+0ZuA0
	1NuA=
X-Gm-Gg: ASbGnct2Da4fxVxVBShgXcCzIdwFP5zX+2Va+PA2u0yaE6bSuTNu1/goakqkuHuEhwS
	c5lj2ClxfwQQqkdboG8ZPI7QoOIzBjn17gNhR6uyJ0z4w2V+lfrIR6S0gvhFNTAW+DC6sFc+aBc
	boS2tWt/4o6a0utQwVfYqmQNu7ArJby340EFaw4efZfYxabefuAqQ92HfkHYXyElGmhhFOwkHuZ
	Gl0R8eHwgR8cRQgGxEVJdtv9s3epXqZ5p4jkJW76n8sj6Hx2vzReRtP4418EGHrK5hoUnhi/xLF
	YgMvdOCd2efgBWz/EprynzwfcTI9TzhdfkZou2toWjRzUJBVMhImGzfXioGYYME83vYlfwt5BI+
	m8wRgvr19bzxw9/+DxWmoBMvaBYNJ3/K/O47F9L10HmrRlkVYtdfHmODixQ==
X-Google-Smtp-Source: AGHT+IFF2cBgmthnjaPY0d7ZcKwjaIvijwnZ6Vo0g+oi5WwQuWMEzpGV2GKkvMxJO2iG7gtswr52zg==
X-Received: by 2002:a05:6000:3106:b0:3a4:f70d:a65e with SMTP id ffacd0b85a97d-3a51d95a4f1mr4785868f8f.37.1749119327240;
        Thu, 05 Jun 2025 03:28:47 -0700 (PDT)
Message-ID: 
Date: Thu, 5 Jun 2025 12:28:36 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v5 6/6] mm: allow page scrubbing routine(s) to be arch
 controlled
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini ,
 Anthony PERARD ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Bertrand Marquis ,
 Volodymyr Babchuk ,
 Oleksii Kurochko ,
 Shawn Anastasio 
References: <73481cbf-337f-4e85-81d2-3487366cd822@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: <73481cbf-337f-4e85-81d2-3487366cd822@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Especially when dealing with large amounts of memory, memset() may not
be very efficient; this can be bad enough that even for debug builds a
custom function is warranted. We additionally want to distinguish "hot"
and "cold" cases (with, as initial heuristic, "hot" being for any
allocations a domain does for itself, assuming that in all other cases
the page wouldn't be accessed [again] soon). The goal is for accesses
of "cold" pages to not disturb caches (albeit finding a good balance
between this and the higher latency looks to be difficult).

Keep the default fallback to clear_page_*() in common code; this may
want to be revisited down the road.

Signed-off-by: Jan Beulich 
Acked-by: Julien Grall 
---
v4: Re-base.
v3: Re-base.
v2: New.
---
The choice between hot and cold in scrub_one_page()'s callers is
certainly up for discussion / improvement.

--- a/xen/arch/arm/include/asm/page.h
+++ b/xen/arch/arm/include/asm/page.h
@@ -144,6 +144,12 @@ extern size_t dcache_line_bytes;
 
 #define copy_page(dp, sp) memcpy(dp, sp, PAGE_SIZE)
 
+#define clear_page_hot  clear_page
+#define clear_page_cold clear_page
+
+#define scrub_page_hot(page) memset(page, SCRUB_BYTE_PATTERN, PAGE_SIZE)
+#define scrub_page_cold      scrub_page_hot
+
 static inline size_t read_dcache_line_bytes(void)
 {
     register_t ctr;
--- a/xen/arch/ppc/include/asm/page.h
+++ b/xen/arch/ppc/include/asm/page.h
@@ -188,6 +188,12 @@ static inline void invalidate_icache(voi
 #define clear_page(page) memset(page, 0, PAGE_SIZE)
 #define copy_page(dp, sp) memcpy(dp, sp, PAGE_SIZE)
 
+#define clear_page_hot  clear_page
+#define clear_page_cold clear_page
+
+#define scrub_page_hot(page) memset(page, SCRUB_BYTE_PATTERN, PAGE_SIZE)
+#define scrub_page_cold      scrub_page_hot
+
 /* TODO: Flush the dcache for an entire page. */
 static inline void flush_page_to_ram(unsigned long mfn, bool sync_icache)
 {
--- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -198,6 +198,12 @@ static inline void invalidate_icache(voi
 #define clear_page(page) memset((void *)(page), 0, PAGE_SIZE)
 #define copy_page(dp, sp) memcpy(dp, sp, PAGE_SIZE)
 
+#define clear_page_hot  clear_page
+#define clear_page_cold clear_page
+
+#define scrub_page_hot(page) memset(page, SCRUB_BYTE_PATTERN, PAGE_SIZE)
+#define scrub_page_cold      scrub_page_hot
+
 static inline void flush_page_to_ram(unsigned long mfn, bool sync_icache)
 {
     const void *v = map_domain_page(_mfn(mfn));
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -58,6 +58,7 @@ obj-y += pci.o
 obj-y += physdev.o
 obj-$(CONFIG_COMPAT) += x86_64/physdev.o
 obj-$(CONFIG_X86_PSR) += psr.o
+obj-bin-$(CONFIG_DEBUG) += scrub_page.o
 obj-y += setup.o
 obj-y += shutdown.o
 obj-y += smp.o
--- a/xen/arch/x86/include/asm/page.h
+++ b/xen/arch/x86/include/asm/page.h
@@ -226,6 +226,11 @@ void copy_page_sse2(void *to, const void
 #define clear_page(_p)      clear_page_cold(_p)
 #define copy_page(_t, _f)   copy_page_sse2(_t, _f)
 
+#ifdef CONFIG_DEBUG
+void scrub_page_hot(void *);
+void scrub_page_cold(void *);
+#endif
+
 /* Convert between Xen-heap virtual addresses and machine addresses. */
 #define __pa(x)             (virt_to_maddr(x))
 #define __va(x)             (maddr_to_virt(x))
--- /dev/null
+++ b/xen/arch/x86/scrub_page.S
@@ -0,0 +1,39 @@
+        .file __FILE__
+
+#include 
+#include 
+#include 
+
+FUNC(scrub_page_cold)
+        mov     $PAGE_SIZE/32, %ecx
+        mov     $SCRUB_PATTERN, %rax
+
+0:      movnti  %rax,   (%rdi)
+        movnti  %rax,  8(%rdi)
+        movnti  %rax, 16(%rdi)
+        movnti  %rax, 24(%rdi)
+        add     $32, %rdi
+        sub     $1, %ecx
+        jnz     0b
+
+        sfence
+        ret
+END(scrub_page_cold)
+
+        .macro scrub_page_stosb
+        mov     $PAGE_SIZE, %ecx
+        mov     $SCRUB_BYTE_PATTERN, %eax
+        rep stosb
+        ret
+        .endm
+
+        .macro scrub_page_stosq
+        mov     $PAGE_SIZE/8, %ecx
+        mov     $SCRUB_PATTERN, %rax
+        rep stosq
+        ret
+        .endm
+
+FUNC(scrub_page_hot)
+        ALTERNATIVE scrub_page_stosq, scrub_page_stosb, X86_FEATURE_ERMS
+END(scrub_page_hot)
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -135,6 +135,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -779,27 +780,31 @@ static void page_list_add_scrub(struct p
         page_list_add(pg, &heap(node, zone, order));
 }
 
-/* SCRUB_PATTERN needs to be a repeating series of bytes. */
-#ifndef NDEBUG
-#define SCRUB_PATTERN        0xc2c2c2c2c2c2c2c2ULL
-#else
-#define SCRUB_PATTERN        0ULL
+/*
+ * While in debug builds we want callers to avoid relying on allocations
+ * returning zeroed pages, for a production build, clear_page_*() is the
+ * fastest way to scrub.
+ */
+#ifndef CONFIG_DEBUG
+# undef  scrub_page_hot
+# define scrub_page_hot clear_page_hot
+# undef  scrub_page_cold
+# define scrub_page_cold clear_page_cold
 #endif
-#define SCRUB_BYTE_PATTERN   (SCRUB_PATTERN & 0xff)
 
-static void scrub_one_page(const struct page_info *pg)
+static void scrub_one_page(const struct page_info *pg, bool cold)
 {
+    void *ptr;
+
     if ( unlikely(pg->count_info & PGC_broken) )
         return;
 
-#ifndef NDEBUG
-    /* Avoid callers relying on allocations returning zeroed pages. */
-    unmap_domain_page(memset(__map_domain_page(pg),
-                             SCRUB_BYTE_PATTERN, PAGE_SIZE));
-#else
-    /* For a production build, clear_page() is the fastest way to scrub. */
-    clear_domain_page(_mfn(page_to_mfn(pg)));
-#endif
+    ptr = __map_domain_page(pg);
+    if ( cold )
+        scrub_page_cold(ptr);
+    else
+        scrub_page_hot(ptr);
+    unmap_domain_page(ptr);
 }
 
 static void poison_one_page(struct page_info *pg)
@@ -1079,12 +1084,14 @@ static struct page_info *alloc_heap_page
     if ( first_dirty != INVALID_DIRTY_IDX ||
          (scrub_debug && !(memflags & MEMF_no_scrub)) )
     {
+        bool cold = d && d != current->domain;
+
         for ( i = 0; i < (1U << order); i++ )
         {
             if ( test_and_clear_bit(_PGC_need_scrub, &pg[i].count_info) )
             {
                 if ( !(memflags & MEMF_no_scrub) )
-                    scrub_one_page(&pg[i]);
+                    scrub_one_page(&pg[i], cold);
 
                 dirty_cnt++;
             }
@@ -1349,7 +1356,7 @@ bool scrub_free_pages(void)
                 {
                     if ( test_bit(_PGC_need_scrub, &pg[i].count_info) )
                     {
-                        scrub_one_page(&pg[i]);
+                        scrub_one_page(&pg[i], true);
                         /*
                          * We can modify count_info without holding heap
                          * lock since we effectively locked this buddy by
@@ -2074,7 +2081,7 @@ static struct page_info *alloc_color_hea
     if ( !(memflags & MEMF_no_scrub) )
     {
         if ( need_scrub )
-            scrub_one_page(pg);
+            scrub_one_page(pg, d != current->domain);
         else
             check_one_page(pg);
     }
@@ -2225,7 +2232,7 @@ static void __init cf_check smp_scrub_he
         if ( !mfn_valid(_mfn(mfn)) || !page_state_is(pg, free) )
             continue;
 
-        scrub_one_page(pg);
+        scrub_one_page(pg, true);
     }
 }
 
@@ -2930,7 +2937,7 @@ void unprepare_staticmem_pages(struct pa
         if ( need_scrub )
         {
             /* TODO: asynchronous scrubbing for pages of static memory. */
-            scrub_one_page(pg);
+            scrub_one_page(pg, true);
         }
 
         pg[i].count_info |= PGC_static;
--- /dev/null
+++ b/xen/include/xen/scrub.h
@@ -0,0 +1,24 @@
+#ifndef __XEN_SCRUB_H__
+#define __XEN_SCRUB_H__
+
+#include 
+
+/* SCRUB_PATTERN needs to be a repeating series of bytes. */
+#ifdef CONFIG_DEBUG
+# define SCRUB_PATTERN       _AC(0xc2c2c2c2c2c2c2c2,ULL)
+#else
+# define SCRUB_PATTERN       _AC(0,ULL)
+#endif
+#define SCRUB_BYTE_PATTERN   (SCRUB_PATTERN & 0xff)
+
+#endif /* __XEN_SCRUB_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 10:38:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 10:38:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006592.1385807 (Exim 4.92)
	(envelope-from )
	id 1uN7zX-0000py-PP; Thu, 05 Jun 2025 10:38:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006592.1385807; Thu, 05 Jun 2025 10:38: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 1uN7zX-0000pr-Mq; Thu, 05 Jun 2025 10:38:35 +0000
Received: by outflank-mailman (input) for mailman id 1006592;
 Thu, 05 Jun 2025 10:38: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 1uN7zW-0000pl-2I
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 10:38:34 +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 39b35611-41f9-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 12:38:32 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3a50fc819f2so636506f8f.2
 for ; Thu, 05 Jun 2025 03:38:32 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3132bff67ddsm1243128a91.2.2025.06.05.03.38.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 03:38:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 39b35611-41f9-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749119911; x=1749724711; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=eTrMlXczbRTbKd5+LNoMLF92jZcYMThqFApi1ccyYoY=;
        b=WjmLc0W4a3rVtYquPitUving88Mz9XL26LC2FFCiQJh6kEqBER0kh7DTXsMN1TkNis
         icPTYupkSufYXNcbS/SxGlnBHFhtZB8iw3c0sNnpTsXnCyWEu6S440aV5It2lFUBVqA5
         Q/zUdoxBgcwQ4blAbWgYsDxIe6zHws4sEv/bEURDiGTOsDcDzN56MffzbIScdxluE4f7
         neDFNwD5wSvL6j2RqXh9S9y2owOge5fSnd4BPe22wY/1kRoTnOfJoeT9BL/ga6MQMiI0
         kw/J85S62gYUSimVjFLhYyoJHnLYihvZAdcrKHdhrx6s385bw5dlUzuiYIT2ewhu+HqL
         JCDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749119911; x=1749724711;
        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=eTrMlXczbRTbKd5+LNoMLF92jZcYMThqFApi1ccyYoY=;
        b=w+FDTxPO9Gm9jll4Cdf37vPXGusoB7co5+H8MKBzXtlsRDkyhRjZNty+NJhA7z+TWc
         O2KhRmEk73iOSZAEZnigp1XVguFilC1BniDLNBTzlwJ2ZkFOstMFchldcpsgQRYi7APZ
         /e9cubCqdILUSBtdOEvnRVNeH4z4g9ZhJodKSnJTezZ68I4SDRNy8D+VCLaTp75q57bW
         sYlyQ2hy0MOWeKYq7RdS/dyT1s1o48SRRmktiMYXMPBDAVraUAz8F2Klczp6j6fq1sOo
         0VvJ1He0EeKDq6bqwmaJUlj9lU5AioYAbWV8J3oY2cI2Xk+aTMJfBxcLKtxSxHx3JDrK
         PnQA==
X-Forwarded-Encrypted: i=1; AJvYcCVgX0db8gaOc8sF/ISgkBrF0QEI6hAHJrrf2BiFBdx8oyz6W32d/sWyZ1dkTFF16JjFEWDNwbI7Nhk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyAWW6+Zw1Gfs41VBPTxyMdrnkn7e4Z33fiWmCOpKEvBTZm8J4W
	340XJia4G/4/MFfO8Mv2g2l/z8QlFBCrleKpM+tluvuUuZuRcDbTfTFRZda9vzeHXA==
X-Gm-Gg: ASbGnctTCjfMVPax5oTHC94DSq4VaLgcp2o8/RXdXOFgmwNxoefKOLlvQEcltN4CjU3
	S3NdaA8sfkkZuTCIIIA4fkxQbnH5Qdx6TrkIfW01KSwePsjDIiwpptbSzoAplqpPn4zt1iKaHQ8
	pc+O4g4djBrqT/M7PHOzhvDEtRMV4/YOAGp3YzvMoYJU+3gYXAJrd5OjZeGMaw+lKdQL9URQfWJ
	b3My5fDj5qfAW3tNj0C9eouxZJV1ApvjEwg8292zXh70Rk+nD59LSMW3ZxKFzncOXrU6m77JCz4
	OqotmSgGzSehmW6LQZfMbAEGQ014TbTF6UiWtYlN2UUFy1Nr3eUWDxb/Gw3mtSmsNY3Nxmr5MzK
	zivYFfD+IzlqoOjMl4yf9OhaGCmjkbv80lMAp
X-Google-Smtp-Source: AGHT+IHQNNF19xtS4AyWOZL+m96C5xwyE0xK4mmj/hDjdmXjt8SJsXbqgV4LSfCV78eQwZHDWL9rrA==
X-Received: by 2002:a5d:5f85:0:b0:3a4:ee51:8144 with SMTP id ffacd0b85a97d-3a51d91e0f3mr4670163f8f.13.1749119911433;
        Thu, 05 Jun 2025 03:38:31 -0700 (PDT)
Message-ID: 
Date: Thu, 5 Jun 2025 12:38:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 4/5] vpci: use separate rangeset for BAR unmapping
To: Stewart Hildebrand 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20250531125405.268984-1-stewart.hildebrand@amd.com>
 <20250531125405.268984-5-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: <20250531125405.268984-5-stewart.hildebrand@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 31.05.2025 14:54, Stewart Hildebrand wrote:
> Introduce a new per-BAR rangeset, unmap_mem, for p2m unmapping. Rename
> existing mem rangeset to map_mem, which is now only used for mapping.
> Populate unmap_mem by moving just-mapped ranges from map_mem to
> unmap_mem. In modify_bars(), skip recalculating the ranges when
> unmapping as they are already stored in unmap_mem.
> 
> Signed-off-by: Stewart Hildebrand 

Already when per-BAR rangsets were introduced I questioned that, resource
efficiency wise: A BAR fundamentally is a single range. For e.g. the MSI-X
table we punch a hole, but it then is still questionable if representing
the result as a rangeset is appropriate. Now you further extend the waste.
Since unmapping something that was never mapped should not be a problem,
does what needs unmapping really need representing as a rangeset, rather
than as a plain range?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 10:41:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 10:41:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006597.1385816 (Exim 4.92)
	(envelope-from )
	id 1uN829-0002mH-6k; Thu, 05 Jun 2025 10:41:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006597.1385816; Thu, 05 Jun 2025 10: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 1uN829-0002mA-40; Thu, 05 Jun 2025 10:41:17 +0000
Received: by outflank-mailman (input) for mailman id 1006597;
 Thu, 05 Jun 2025 10: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 1uN827-0002kg-FK
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 10:41:15 +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 9a3e3848-41f9-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 12:41:14 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3a4fb9c2436so408453f8f.1
 for ; Thu, 05 Jun 2025 03:41:14 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23506bc85a0sm116829995ad.46.2025.06.05.03.41.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 03:41:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9a3e3848-41f9-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749120073; x=1749724873; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=5D6Cv0KNFWbLjXHjhf1vgO+AnuhxWstKmfRJQupoU/g=;
        b=BOIDkMN6I9B0dx4uDvv7b/jmFXkx7JWVZ7AMv9i2oIEn0xjatdgGWaSHDoxd/ir9+F
         c1DfkuAUp+n4I9txV2g3rzmJt5I4isVCumSkFCTPzZGJotyv/nxdvgAoCqKb1r5vTmqn
         UtCLY43xaCkjnUTFmoyQRJJYWrAiUkgYZGLK0SeJm+rVIX/b/ubzOpvvoW99DMWUJqvr
         9/mi2A3Fd19fkMsHF0EKaIGW0j9z7c5Z0G6XRTDBhgTBnHUPWBWUd6dTUF6Wa4Lpif6M
         WfbHuDXkOlcDopETZVoJATApSM0EYahSiKgSYqqlqc27D37oF0WT+XZSydHeMYXa/E6n
         DMRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749120073; x=1749724873;
        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=5D6Cv0KNFWbLjXHjhf1vgO+AnuhxWstKmfRJQupoU/g=;
        b=po7+rEv5mJfmVjCT/9EES8dwSm2AK7BeHJqHCCPsQSadtwPYNbjK+JHDbUOm8qK8W0
         BcLIh0MKjj5Hr+FJLxMLlJfj5NFM05HRqBof/T4F4I0LcPgwHu3qvC3InJripu/7WEPZ
         83PRcrf+UYeTVkIcyd1w6Zc06oMyXToBFq40wy+SevWI1q9OoXhb6clo1IIah5dbf2uX
         w6mkl03fU7ZpZ8fmkBjkA2LI92NboIJ+Tgyzd9fU331p9wX2qlr4sZ9wwiaRCW+uDHDo
         XubzX0cbGq576YXr8L+/kWiLBnpdJeqsg16C048Kgt4McvPjOrK58Lkj2o0Yvo1A+San
         7ydg==
X-Forwarded-Encrypted: i=1; AJvYcCUJ7tDcodrg+Mm9+ba500MrFQOK+TFiPDpN45mNJrHT424SnXagFsJ7cQyLiSazgrIQM4zPR7DcNUg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwzgOIUXA+f4wVwDvLGn5ERkIjmOC1X0TilW6Wlgwg16wfQ/HHs
	CHdpSSc0xrDqIdxKUuMzIUVHNVQ0as7S+1q1SDtl2xhVxxzaQKA3Sh09LrCN9x5LyA==
X-Gm-Gg: ASbGnctzwOM4M9RoIv5oOU1zI5T87WRlZLnoKuR73EKNAAAlZX9nvi9+GTiIc9s8VO/
	/76h1u/kB9zZB8KSzn25yFIqSvZ4fcKxye6jeugdnyPLrU7/6Mea/F2AnvIv/agIeZCCuJG2BL4
	yoGd5oRPrzlGt6pKPm1Axutiww8oldlBuKEiLzmAgPEVvM8e2iHibJWvsfa0cjRH1lvcS0EHl9H
	vd4L7kpufwEH35+k0ochthxZAJriTQomT4P9VdjRSPqJDcBTY/tz9iw6C4TEHQSRSC9bcprRGha
	dmP+Gup2grLWarbEL2ipN8cM1afSx+AR5ZhmF4bqOCMkrw13NFYdKpUsFJxm1MN1dYr4pH6KFIh
	X0uKTXSmFZgjZQUVfnvokMA9xke6RBtYtunQu
X-Google-Smtp-Source: AGHT+IH/vjJlysWM/1C8EaKWZM2AXOlkgQZzB177cBdI3PPaWqYvsDaH6dyy5C6C0lzVtlQDHtNbpA==
X-Received: by 2002:a5d:4085:0:b0:3a5:2848:2e78 with SMTP id ffacd0b85a97d-3a528482f65mr1663136f8f.28.1749120073366;
        Thu, 05 Jun 2025 03:41:13 -0700 (PDT)
Message-ID: <9ec5079f-9bc1-4843-a266-d74bf0556619@suse.com>
Date: Thu, 5 Jun 2025 12:41:06 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 5/5] vpci: allow 32-bit BAR writes with memory decoding
 enabled
To: Stewart Hildebrand 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20250531125405.268984-1-stewart.hildebrand@amd.com>
 <20250531125405.268984-6-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: <20250531125405.268984-6-stewart.hildebrand@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 31.05.2025 14:54, Stewart Hildebrand wrote:
> Currently, Xen vPCI refuses BAR writes if the BAR is mapped in p2m. If
> firmware initializes a 32-bit BAR to a bad address, Linux may try to
> write a new address to the BAR without disabling memory decoding. Since
> Xen refuses such writes, the BAR (and thus PCI device) will be
> non-functional.

Doing this for 32-bit BARs only, with not even an outline what to do about
the same issue with 64-bit ones, seems like it won't buy us very much.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 10:55:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 10:55:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006613.1385828 (Exim 4.92)
	(envelope-from )
	id 1uN8FI-0004y0-Bv; Thu, 05 Jun 2025 10:54:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006613.1385828; Thu, 05 Jun 2025 10:54: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 1uN8FI-0004xt-7F; Thu, 05 Jun 2025 10:54:52 +0000
Received: by outflank-mailman (input) for mailman id 1006613;
 Thu, 05 Jun 2025 10:54: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 1uN8FH-0004xn-Am
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 10:54:51 +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 801e66ae-41fb-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 12:54:49 +0200 (CEST)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-451e2f0d9c2so6875035e9.1
 for ; Thu, 05 Jun 2025 03:54:49 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-451f99198e1sm20292825e9.33.2025.06.05.03.54.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 03:54:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 801e66ae-41fb-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749120888; x=1749725688; 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=Hf/pKBiCp9I8X2bZ9V5ACkgefi7T4fobe5MhHs7oYmU=;
        b=rGRLF9shWCQneTMsjdRdtzhfuwrnipitY6jaUiBXtxD08+6diLemk09S6vC+WjRsvY
         GL7m4/anIalX5VzPjVSTpqhO9mqH8wVmwJaL+GLkoNNAove6tC7jg73172e3oryIdhNd
         pu6xq+E/uskzNEN+CbYZ2WA/6AZBHREolRWNg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749120888; x=1749725688;
        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=Hf/pKBiCp9I8X2bZ9V5ACkgefi7T4fobe5MhHs7oYmU=;
        b=tgvmn/Y7I2bO3Hcr0fcB4b00jpZqs7UM8JTIo4Ts46hJVaZGAbvMiy6t5v//HRUQ67
         5QvcebTXjo4bKz6xhIanrd09uNp+l0rNsorUlQObppLze/wTVtqY8qSJVyV/0/viYQdF
         7JqxVoZ7a5aw44Djmo3CwrUxxaWW2TCa6+jLybpyuXezpd9/IrAnpyA72+1tGGll3W5A
         jTLMMRqYkqw3dnqIf8rzL+fjv7VvrF7uIHDYTf3APrbjcCP5Ui360mbLXAMtl8tUB8/4
         sgYQ5iE0mqx2mkcvuQHlNDb7hNQOVeh/ZUeJ14ndXFibEz9feJBNYiK4JklPvm0o4BTh
         53cg==
X-Gm-Message-State: AOJu0Yw1iYhOdx42qjwoXw6N0a7zJ6rxDhhSG/teONORnZM1iIfvLpyC
	ONObkTk7ssWHKVEm3tKEeu9pnxJKfSq6ELSzvz9cXtR3Gid1araUl7z85gXav/+/QMThAdhTFhw
	YEYWn
X-Gm-Gg: ASbGncsI8P50GgSmqaX7gzLIQ6ZV8eZzfetsZqS6GMW4giBKS2DFXYlgFHW4wmokw7w
	F+1s8YhLDY2wEwnxTCqYY+vPViE4xzrPT+fZ39Ueu9yGcRi+PSFNgieiDB68E+TMcW5klKaskhx
	5NYd6e3sAojC6q1sp9OzeBuo0VtpXT5Nuih7ta5oR7l8NdkPwCgFpIA+uVGMJSONCt4v34Lp7cF
	68RVCLCT+XYUSYJ/SclDNPv0NLNEPwIkh48n5DwlgqbLMTTm8ulOqnmv5cQdUiMKm9lUzhOti4Q
	oiWzE5EoSQIJLxBQit6s4RNuAF8KQhKN3pexUMc+PlpcYk8Zkn3ozl8qSu3A54CTE6KtLcv/MPx
	fyI+OsvjbyAxeLaRQ8WgjeJKpHysBKw==
X-Google-Smtp-Source: AGHT+IE5p/JiO4iad9KTLzmgKrt5y15ouaGkSM+9v2bNVpW3SyvhRxap0wrEU/GgZh2aWRliOViIIQ==
X-Received: by 2002:a05:600c:444d:b0:441:bbe5:f562 with SMTP id 5b1f17b1804b1-451f88d8050mr27117755e9.16.1749120888464;
        Thu, 05 Jun 2025 03:54:48 -0700 (PDT)
Date: Thu, 5 Jun 2025 12:54:47 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jiqian Chen 
Cc: xen-devel@lists.xenproject.org, Huang Rui 
Subject: Re: [PATCH v5 02/10] vpci/header: Emulate legacy capability list for
 dom0
Message-ID: 
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
 <20250526094559.140423-3-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250526094559.140423-3-Jiqian.Chen@amd.com>

On Mon, May 26, 2025 at 05:45:51PM +0800, Jiqian Chen wrote:
> Current logic of emulating legacy capability list is only for domU.
> So, expand it to emulate for dom0 too. Then it will be easy to hide
> a capability whose initialization fails in a function.
> 
> And restrict adding PCI_STATUS register only for domU since dom0
> has no limitation to access that register.
> 
> Signed-off-by: Jiqian Chen 

Reviewed-by: Roger Pau Monné 

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 10:55:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 10:55:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006620.1385837 (Exim 4.92)
	(envelope-from )
	id 1uN8Fo-0005Tb-N5; Thu, 05 Jun 2025 10:55:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006620.1385837; Thu, 05 Jun 2025 10:55: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 1uN8Fo-0005TU-KG; Thu, 05 Jun 2025 10:55:24 +0000
Received: by outflank-mailman (input) for mailman id 1006620;
 Thu, 05 Jun 2025 10:55: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 1uN8Fm-0005DA-T7
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 10:55:23 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on2062e.outbound.protection.outlook.com
 [2a01:111:f403:2417::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 92a8fa4f-41fb-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 12:55:21 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by CY5PR12MB6300.namprd12.prod.outlook.com (2603:10b6:930:f::8) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Thu, 5 Jun
 2025 10:55:16 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8792.034; Thu, 5 Jun 2025
 10: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: 92a8fa4f-41fb-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=WM24YmbHCrCWxHjRnxdqd6OcXGz6T1pEQYccEd1w7iUf2I/Zb0iuVIh2+f8NT72xrEbxMoofZbB2ZM8+ehB4VfQ45iq+EAEqR4/oln9el+xhjtug9WbXZoDLoT7OdMOOPYcsmXCDKrrGMQDsRbKxLK+dZyMd7aVmm9zfHXzy+d+H9vis58WGJBZdour2TiltDIpDRDwvGby9pQUuKcqVdlHsvBmLLjvRdjOh0ZyiJFVrjWJLGiQgFSEYI/6CrWhtog29vxPZdTwGz14AlCKC7rK0oaTKaFlFndz5nFt+KX8RhlWjbmjGl17Jw8h0W3tvGHHdrfZMUOweN4tKe9bMgQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=mR+gbydvo4UmGyC7Ee6+sqhj2cAhLvN0uoaPYZy6+j8=;
 b=UATO9tBoZlsY+NcMPG0CzvNC21a6IktXQmNkIpUM76iGAdDaIOOasyYabvQ+MshvKULciXQFYoFGM1bc5GOCBGCTGf9I7NvQoUIBY4LxMvuBY513DJpZ4GCjw5KVMJP3UQ6yX+324BKbwGmPP+AJfv3xj0FdMSScGOYa5oZ3epmBtjmbgp0E34RV+xqbHAb50QrttpYGX1obqY4VmMWHjWysFP8r+6kTSqyVFusvGXNPZKmBGmx0GGk41w8/wvvoXwn8aVv2rhAmwNS+dTJRPO+AJs10DNLLHb4E4PycN8W13pm0D2FgCzFwxM7W5GeZAGeLht0zooC42fOLHq5s6Q==
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=mR+gbydvo4UmGyC7Ee6+sqhj2cAhLvN0uoaPYZy6+j8=;
 b=N0fVYqt4Opc5Zw9FTVfep9KghszKPla98lqLPr6tK941Dxb2FhQcWcUMbxd+OwzPEkZWxShd65Hw5sckHpAk5gTupgeAom/9xkWOXP9h/V1CXYTaOCwzWK74uYrgNp+miUgkKnu0i6oCejB1fScVGrEagpRTTmx7Q3lKSVj+UwU=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Thu, 5 Jun 2025 12:55:11 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/3] arm/mpu: Provide and populate MPU C data
 structures
To: Julien Grall ,
 Ayan Kumar Halder , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250604174311.754899-1-ayan.kumar.halder@amd.com>
 <20250604174311.754899-3-ayan.kumar.halder@amd.com>
 <50c8e74e-95f6-4cea-b979-8b81d7575a21@amd.com>
 <0f5a4c32-3631-4a4c-9dd5-ae5385fc984a@xen.org>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <0f5a4c32-3631-4a4c-9dd5-ae5385fc984a@xen.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR4P281CA0158.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:ba::15) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|CY5PR12MB6300:EE_
X-MS-Office365-Filtering-Correlation-Id: 1f46265c-e220-4bb8-9074-08dda41f742f
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?SjY0Unp0a21iY1l6NFBkc1R2SHFwazcxMmUrQzdrbDdPUEhQMkFJVkovaWZO?=
 =?utf-8?B?YnNjMDFqcXZLZWhoVFJiVkhpT29mVHB1QkxPY1AxaVVtSHpzOEJtVk1EWElI?=
 =?utf-8?B?Sm5wQVVGemViakFDOFFFbUF0UWtlSDVwQk1DZWdjSDJBUTE5TnVlMVVRakJP?=
 =?utf-8?B?QTRNVnZnVm13SkFiWks5bHAvcVFvS1lYSGovSmJ6cFp1UXVPWFMxYjVUL3Bw?=
 =?utf-8?B?cFIwWGJXZnA0S0FhSmlGejFrOTg2a2ZEMmF0bmEzUTFSZzVKK1NIbktYZmgr?=
 =?utf-8?B?b0g5UTlLY0xMTHNrcWNRYjJ1L1JmenlxNVhhcWRJQzQra3pmSEhhbFhCR3VP?=
 =?utf-8?B?R3R5SWZiQVNDNlFhK2dTazQvem5FZFVOd0JnUDFwbVdhYURjbUl5bGF4SzFK?=
 =?utf-8?B?TjgyWWtQQmZPZGM4dTBLMVBnWjJSK2lLa2l1UTlmc3NmU3BtR2ZyT21mQlQ3?=
 =?utf-8?B?VU5ETDdrcFNnNzF0MDh0VGlDdDZMdnk2RU8zM25lY0xUR1hldm8zWGZTV2w0?=
 =?utf-8?B?SHdZZTNic01qU1M3bGdnU1k5WFdxRWY5UE9oa3dGQnlBbjhWTFN3aWozYzYw?=
 =?utf-8?B?OFlpNklUSksrQmlTSnBkRG1KRzNYcG9aOFR4andlNU4rek5LazBqcUNRZUp2?=
 =?utf-8?B?RGptZ0svWDdUWjdyOFZNUVdUTEx4YU5CN2xUMTNHK25VZnI1bGdmYjFLdkN4?=
 =?utf-8?B?L05XdXkrZ29MYUcrTzZFeFVscFArM1ZUdENZM3FtS2pLOCttZDhtSWxHM09R?=
 =?utf-8?B?Y0FRUkt3NnZDN3NBbkhKMUdXNHk2eFBkM2ZoUk9vdXBPSUhEd3Rsd1NpTit5?=
 =?utf-8?B?ZmJucDJxck90dmdhY2RuRlFpYVBNQVdQRzJUY3cvM1c0NlVVL3d3TWNtbkJr?=
 =?utf-8?B?Zjd0bitXWXRIVlFhRHBYNVpKcVV1Y3RJcU45N01JVzh4SWxyTjdJVVJIY29V?=
 =?utf-8?B?NXFvRzduNGExSlNWSUtEN3lZNko2cXh3TlMvaVNXWEd6OXlyRlFnVG0yYmU5?=
 =?utf-8?B?UEx0MXBUVksxL3ZIUVZGVDR3bTBXOVpKRzdUTXpZQWlPZ0hYOHFKSHdPNnVG?=
 =?utf-8?B?aDZKdnprY2dFUnRCVXFaOGhtLzJjSHlYemczZjMreFpJcnI0S3lKVGhGbytK?=
 =?utf-8?B?MHJITDZJejVNdTdOYURzaEpTZStBaTFMeVVDSVR5V2Y2dWNRV2lmT3JLbFZC?=
 =?utf-8?B?Z0VMWWRPZzd6UDl0YTdDVHFsMUpHSUczaVdaN3p3VTBna2YyU0pydHpkb3c4?=
 =?utf-8?B?VFNiWUswSXJqNWh2M0RWR3ZGcFRpMWtOV05yaE8xZk5rVXluMlV0eDRFcGNF?=
 =?utf-8?B?Z3pVS1E0azYyZllXWXlnQy9oUXFmbmdpdm8xbGx3NWRFS3psRHJXU0crYU5V?=
 =?utf-8?B?YU44dDRGMEJUMGpZbVF3akl0bndRK0pTV2E3MXhXYVFYZ2RwbE1FMWNwSnlk?=
 =?utf-8?B?bnBSSXBGYm1tLy9KWmlKMmZZZzBBYTRkblNnTzQ4UU4wRm5DUjNVMEN2QXlV?=
 =?utf-8?B?cit2MURybFpwWGJCMEN1NGRTaWxiVUpjbHBwdGVuOFd6ZE5jRkVqTE4wcXZn?=
 =?utf-8?B?UEJxMS9wWFlESFhSbWZuaE5BTHJsM0k5UmpHaWdRYU54NFd3THVUL0ROU1FG?=
 =?utf-8?B?TUFDN3lpcHAyaW03WDdiNHg2dXNMclF0U0paWDFkNEZhd2Z4TC9LZkVBM2FW?=
 =?utf-8?B?ME1vb0NDTkdwbFRTS3NDL3MzYlo2MUNtQS9GVzVpV2EyWitOQkpVWFI1eGdt?=
 =?utf-8?B?MWZ6dEVzWnlNVHRmVmk0T0VSaGdETUExbC8zM0tTc2o4UmZHYmI2K01VWjhS?=
 =?utf-8?B?REk5QUFuSXhydHNkTW1RaGJNR2tsY1BLWlN3bzdiT3RNSm1EaUhPSmNTVXg4?=
 =?utf-8?B?Ym1lMmZqYzl5amdWNWZSR3l3T1BJVitaT3lFRGJHTXhubHdGZUtxMTQ3OUpw?=
 =?utf-8?Q?T13PRLCXRCA=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.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?blczK2krTjI1Ymx2NzNZUWQ0ZkYwMzN0UUNvb3JxY1JoVUdyS2Q3NXFpeFph?=
 =?utf-8?B?bkYzbHRHRHVTREozTURpUnRJUTU4QzVIYzc3ZDBOdGd4ZnFobWxLL05QVmpr?=
 =?utf-8?B?ZVVtTE9ZNTd5SWxwblZIZG1hUDVTR1BSVjlJUm9ONWdFdmpyTG91OWRYakFV?=
 =?utf-8?B?NFF6L0dONkdSMU05RVpwZFdQbTJqTXRkNkozYWdhSlVpSzV4eVhPMnhvblpE?=
 =?utf-8?B?MDRvS2lxM3FueVN3SGVWYTNGQXpkRVBGZnoySG9nck41bkZNUWc5QTRQV2d3?=
 =?utf-8?B?eXNxTmt6VjhjOGhXSXZHcHZPSThMLytuSFNISXJwSmJIL09xdkdHS3NrWncr?=
 =?utf-8?B?RGxjeDJkOEd5WlpQd0NiNW1BaEdVanNVbDBnc3NxbDMxYjg3RGxhTkNMeEIv?=
 =?utf-8?B?bGo3V3ZXSm1KZHZ4amw4bEI5Ly9QSEl6bDVmR0RIWXVCT1lCeGhoWlZyMncz?=
 =?utf-8?B?ay92Z1AydnlLS0RWOXJlWXgyMldQVldZOHBUUmNiZG4vSjZPdzBjYzVrVFpG?=
 =?utf-8?B?YXlPaUNJV1piVU9ITTFNbTQrb2M4NXFDSVhBYXJpczB3TzA4NDVPdU5jckV2?=
 =?utf-8?B?RFFhQmNVbE1kTm9WV1NHdDEyd05hRUdDNUpucHJ1T3p4VXB2YUhBVEdtWFNz?=
 =?utf-8?B?OFJwRm00bllNTzJNVWNjYzdhMTg0ZnBwcmhxQ3J0ZVlYbnU3eXJra0VKRHVH?=
 =?utf-8?B?NUkrSVM0NnRNZ2N6UCswTHNmU3VHTnV6YXFBZEZvcWZINWJBZEpMUXo3cUVO?=
 =?utf-8?B?U1p4YytwclU4S3d4T0grb3FjSGFPSDc3ZTRROFVCT2VRUXppeldsK2pwSzVt?=
 =?utf-8?B?VjAvOW04dmFRTUk4cnlmSFdyeHpVVlNGSHkvdDV4NWxMeUkrem1pNDRHczdJ?=
 =?utf-8?B?MEl6L3FRdGRPRXlNa1hPZDFWYmJadkM5Q0lRR1hoK0pSaGpERnZxUnVjbHJt?=
 =?utf-8?B?Z0JuWURWNXNZNEhiMEphakNKOHJENG15cE55VzFQb3V2bmRnbmw1ODF4QVlN?=
 =?utf-8?B?eEFadHY1Qnp3OHRyWjNnZGptd3BLR0pvOE5sVzl2QXRDd28xYWpadzQ2b0ti?=
 =?utf-8?B?VVlDei9CMW9DT3ZZeERtZHlqSlpDV0U5OXE2KzNpeTJZQ0grR2E3cjZBVUNI?=
 =?utf-8?B?UWVHejVBNlArVVBPMXh5T2hmdWJTZSs2cUo2YzdMQ1RnWFpibnBZVXhPcXpP?=
 =?utf-8?B?RUh3UTlzMzVpOU0wTisyU044T0tFTGtoN3RlRDA3ZzljK0M5TWhrcDk0b0Fo?=
 =?utf-8?B?UGdiRGI4QmpIN0lOUDNNamZ2cE95MkRNYTlsZ00yWUIvTDZYanVBL0RucnhI?=
 =?utf-8?B?bzlzN2kxSE1nL2NhWW1NRlhaN3pvR3BSVDI1cTAzQlZiREowSm9ycTBDL1d0?=
 =?utf-8?B?K3VldU5zYWdHaFo2WVVYMFRNZGc1SE10Nkh1SWw1OEwvL2N3azBSZkxmQzdh?=
 =?utf-8?B?dEN0c1RrcTdhcGxrNHZiMXQyeWVnRU5VSFVrOEw1d200V1BkczdNTnZqZ0Rp?=
 =?utf-8?B?Nyt2YjcxWTcrbE9aZndMR01GQURqaWptb1QwVkMrMURmeUhMaUdSVGJ2ZE8w?=
 =?utf-8?B?VTdVNEQxeWluakFKd2RmMDdDWE4rYWdzY0REcW9Kbk9OcFpHeHc3K1JGb2hU?=
 =?utf-8?B?UUVCNHBONVFaVExiSUJRTWVIRnNOcG1ZUkR6Nm4vcEhja1h6dnEwd1ZDYTcz?=
 =?utf-8?B?ektoazhkblFySzlTUjNhck5TYWZtekgyOWF4eXJWSWozTXNmZ1JyT0tBcFY2?=
 =?utf-8?B?QVpiTVh0ZkpPQ2J1b0x4LzhMYk4wbkUzUTk5UVcxakVQVWRWSmZtakdqZEdF?=
 =?utf-8?B?WFcrdXFXeVVabDlhTWp6Q3Vmem1CdEJFLzQwTDJiZGpuNHNybFVheWNKZ1NC?=
 =?utf-8?B?Q1RlSXlJdHNldi9qcTZaejBiRzE3K0VCbmtpNEg5YTBoeHlGK1I0U3RSL0h2?=
 =?utf-8?B?OGdmSi9Bb2RFYzBEajB1VzBIaEFBNklNb0ZhR0VOK3pjVi85eWYvV0FsYXBw?=
 =?utf-8?B?d2twVkRrTVp1NVpybDVVU0w4aEdHc05QaTh6Vzh5MEM5SEF5aGxGVG95dXQy?=
 =?utf-8?B?bk5DeWVoemJKK3VDQWdzVGNHeTRBL1RkVTNDZFR5TG5NSHVEL3hjVWpaRHo5?=
 =?utf-8?Q?KYDY=3D?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1f46265c-e220-4bb8-9074-08dda41f742f
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jun 2025 10:55:15.9374
 (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: ENlgr+YbZjHc+vgOeP+GxNeAg5YTCKDj6gnSQQ0aNxkjy8JcHZSkN+KFp3PkSagY
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR12MB6300



On 05/06/2025 10:58, Julien Grall wrote:
> Hi Michal,
> 
> On 05/06/2025 08:44, Orzel, Michal wrote:
>>
>>
>> On 04/06/2025 19:43, Ayan Kumar Halder wrote:
>>> Do the arm32 equivalent initialization for commit id ca5df936c4.
>> This is not a good commit msg.
>> Also, we somewhat require passing 12 char long IDs.
> 
> We are following the same convention as Linux. IIRC this was updated 
> because there was some collision with 10 characters in Linux (not sure 
> if we have seen it in Xen yet).
> 
> [...]
> 
>>> diff --git a/xen/arch/arm/include/asm/mpu/regions.inc b/xen/arch/arm/include/asm/mpu/regions.inc
>>> index 6b8c233e6c..943bcda346 100644
>>> --- a/xen/arch/arm/include/asm/mpu/regions.inc
>>> +++ b/xen/arch/arm/include/asm/mpu/regions.inc
>>> @@ -24,7 +24,13 @@
>>>   #define XEN_MPUMAP_ENTRY_SHIFT  0x3     /* 8 byte structure */
>>>   
>>>   .macro store_pair reg1, reg2, dst
>>> -    .word 0xe7f000f0                    /* unimplemented */
>>> +    str \reg1, [\dst]
>>> +    add \dst, \dst, #4
>>> +    str \reg2, [\dst]
>> AFAIR there is STM instruction to do the same
> 
> AFAICT, one issue with stm is the ordering is forced by the instruction 
> rather than the user. So \reg1 could be stored first.
Yes, I think it stores based on register number. So if you do {r2, r1} it will
still store r1 first.

> 
> I think it would be better to use "strd". It still has restriction
> (the two registers need to have contiguous index). But I think that 
> would be better if we want to reduce the number of instructions.
Ok

~Michal



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 11:02:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 11:02:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006629.1385846 (Exim 4.92)
	(envelope-from )
	id 1uN8Mv-0007TF-C4; Thu, 05 Jun 2025 11:02:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006629.1385846; Thu, 05 Jun 2025 11: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 1uN8Mv-0007T8-9Y; Thu, 05 Jun 2025 11:02:45 +0000
Received: by outflank-mailman (input) for mailman id 1006629;
 Thu, 05 Jun 2025 11: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 1uN8Mt-0007T2-QB
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 11:02:43 +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 99b85cbc-41fc-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 13:02:41 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-450cfb79177so4295775e9.0
 for ; Thu, 05 Jun 2025 04:02:41 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23506cf53cfsm117677315ad.181.2025.06.05.04.02.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 04:02:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 99b85cbc-41fc-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749121361; x=1749726161; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=KM0hNDDwYcpOQ+LgXpTyZQeGCMkGJkrCSAa5u4E8qfU=;
        b=bdgexLA49WOz/1C7aCu/FSFR0HD7jyYz/pfFHVHb41k8Y4o4hrnJ5t7kZXMluX3Jaw
         u+iI63vmwhNoesjQTMqt9vZzTMGXvs9GKxaFDq9UdTeouZu9erNN6E/DvMglkWCZkvsZ
         vThGLkwjHA8oetk+t6+zopIXuxG1M5by+cPvwpBMpV9V6k+WSMcFocTU07/wVFBHAVxI
         vo0izKm1aK9oy28CXBZBrvdLe/0LL33ntUU+YV65bjnkMV38LtXk6qGzkQZl4/yfH4MC
         EQXzXSVJMfAndpFww7a/iN/0OmH5OUJkiLwRlxsCX6a6sBMOzl6lQfzYS/MgyuiYGOsX
         SsaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749121361; x=1749726161;
        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=KM0hNDDwYcpOQ+LgXpTyZQeGCMkGJkrCSAa5u4E8qfU=;
        b=HTXPzZj3H9S9kyHyfo52RbSWxMTUlqCQFvtJA2K16dOTZ3t91SMZS8sCsctCw09JwQ
         pa7GeEH7Z7fpmr07iuS1Pz581nI//ZRDhhAFjQ7rfdjRs28lFiRbF1lv6VY92CEjAfM4
         SYGKEL3WxBWJ8RTnLnU5V3VFMn/KSSDRthoQQtziXTbK3btHIC0FGHklSf31lq9KOfwg
         G2sNoCnksGs7MrrGUfCWzCzhdz9DiIWKuppaWK82RMn2KQ4n63vHXT8cJDvZII6tmajG
         uND6oUQYJoqhz3cpDC4B0/jP/fBTa6aMV3oH5pEo1pbbHhojV4pnqv/9xMr9vYtg9vDQ
         /fdg==
X-Forwarded-Encrypted: i=1; AJvYcCWNAYS47EtaZZ3jBCZqtBtx/lhAG9+5nPjJ25dNpKpAnZ1d0l1RH5C0Qzl9Yn8X/M/jPFSgDNKILhQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwzpU+eOioXPs30b9RkhhNoiy8Q1DnqPFF2U8TC2Mf63EpHlpp7
	0supTc5B3DBM8q6vbGcVXy1inqkQHkOgdyWSGBY4kAzKcWQc/+7ECU+gXIZrrZWJbw==
X-Gm-Gg: ASbGncvmKULA4u+X0hbeKu6dPog1Of/50CK3NAxcTht1sbp9KbWFCQQkwuDzzJ3Yjpf
	lGKre8ceNUavxt4hKwXwV7JfAcbLwakr5WP0B1382h4XFS2nEGosEcYZiPHbah5IgQgTy5dYOKC
	4NkueM2nwk2IfJgOj883ij8A+nz0K1N6U0CzP9BYzDUSIxz9cL2ohW9o3q2UO1SEzSdCxgecTSY
	6sxeJJTJkIlu96DgJQbt/r0fpi6RHfxL74/ipqOd7xQYJ55lNGJTBvtxwbZtmcE9B1/cXXCcE9s
	EDdYUne9jkc2NSpH290TjIRntrd7JejgxSwhnPHBNRcT2f6WC0Nsxgsml63XK11KF3/nXVg9txu
	uBibGtx0dvuLu5ETL5jdmb1KFZ700hgIHoIPW2EmB9hw1OF0=
X-Google-Smtp-Source: AGHT+IHrNL6knImrc8DQjJW43EBtjWy1BTQpYfttegHb8Fq5fcEUM3auMMVuuCPZ+Q0S9prXpN14xQ==
X-Received: by 2002:a05:6000:2204:b0:3a4:d3ff:cef2 with SMTP id ffacd0b85a97d-3a51d961912mr5487660f8f.27.1749121360338;
        Thu, 05 Jun 2025 04:02:40 -0700 (PDT)
Message-ID: <7cf79ee4-5176-4a4f-97bd-c7594e1c8c9b@suse.com>
Date: Thu, 5 Jun 2025 13:02:29 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/5] livepatch: Embed public key in Xen
To: Ross Lagerwall ,
 Stefano Stabellini ,
 "consulting@bugseng.com" 
Cc: Kevin Lampis ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20250602133639.2871212-1-ross.lagerwall@citrix.com>
 <20250602133639.2871212-3-ross.lagerwall@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: <20250602133639.2871212-3-ross.lagerwall@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 02.06.2025 15:36, Ross Lagerwall wrote:
> From: Kevin Lampis 
> 
> Make it possible to embed a public key in Xen to be used when verifying
> live patch payloads. Inclusion of the public key is optional.
> 
> To avoid needing to include a DER / X.509 parser in the hypervisor, the
> public key is unpacked at build time and included in a form that is
> convenient for the hypervisor to consume. This is different approach
> from that used by Linux which embeds the entire X.509 certificate and
> builds in a parser for it.
> 
> A suitable key can be created using openssl:
> 
> openssl req -x509 -newkey rsa:2048 -keyout priv.pem -out pub.pem \
>     -sha256 -days 3650 -nodes \
>     -subj "/C=XX/ST=StateName/L=CityName/O=CompanyName/OU=CompanySectionName/CN=CommonNameOrHostname"
> openssl x509 -inform PEM -in pub.pem -outform PEM -pubkey -nocert -out verify_key.pem
> 
> Signed-off-by: Kevin Lampis 
> Signed-off-by: Ross Lagerwall 
> ---
> 
> In v3:
> 
> * Drop unnecessary condition in Makefile
> * Use dashes instead of underscores
> * Drop section placement annotation on declaration
> * Clarify endianness of embedded key
> 
>  xen/common/Kconfig          | 18 +++++++++++++++++
>  xen/crypto/Makefile         | 11 ++++++++++
>  xen/include/xen/livepatch.h |  5 +++++
>  xen/tools/extract-key.py    | 40 +++++++++++++++++++++++++++++++++++++
>  4 files changed, 74 insertions(+)
>  create mode 100755 xen/tools/extract-key.py
> 
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index 0951d4c2f286..74673078202a 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -472,6 +472,24 @@ config LIVEPATCH
>  
>  	  If unsure, say Y.
>  
> +config PAYLOAD_VERIFY
> +	bool "Verify signed LivePatch payloads"
> +	depends on LIVEPATCH
> +	select CRYPTO
> +	help
> +	  Verify signed LivePatch payloads using an RSA public key built
> +	  into the Xen hypervisor. Selecting this option requires a
> +	  public key in PEM format to be available for embedding during
> +	  the build.
> +
> +config PAYLOAD_VERIFY_KEY

This identifier to me mean "verify the key of payloads", when really ...

> +	string "File name of public key used to verify payloads"

... you mean the key used for verification. To express this in the name,
how about PAYLOAD_VERIFICATION_KEY?

> +	default "verify_key.pem"

The revlog says you replaced underscores by dashes.

> +	depends on PAYLOAD_VERIFY
> +	help
> +	  The file name of an RSA public key in PEM format to be used for
> +	  verifying signed LivePatch payloads.

Perhaps the fact that it needs to be an RSA key may also want expressing
in the Kconfig identifier?

Should the help text perhaps further clarify where the file is going to be
looked for in case it's a relative path (as in particular the default is)?
Seeing that ...

> --- a/xen/crypto/Makefile
> +++ b/xen/crypto/Makefile
> @@ -1,2 +1,13 @@
>  obj-y += rijndael.o
>  obj-y += vmac.o
> +
> +obj-$(CONFIG_PAYLOAD_VERIFY) += builtin-payload-key.o
> +
> +key-path := $(objtree)/$(patsubst "%",%,$(CONFIG_PAYLOAD_VERIFY_KEY))

... it's in the object tree now (which will break if an absolute path was
specified), how do you intend the key to make it there? In the default
case, for an out-of-tree build the build tree doesn't exist ahead of the
build being invoked.

> +$(obj)/builtin-payload-key.bin: $(key-path) $(srctree)/tools/extract-key.py
> +	$(srctree)/tools/extract-key.py < $< > $@.new
> +	$(call move-if-changed,$@.new,$@)
> +
> +$(obj)/builtin-payload-key.S: BINFILE_FLAGS := -i
> +$(obj)/builtin-payload-key.S: $(srctree)/tools/binfile $(obj)/builtin-payload-key.bin FORCE
> +	$(call if_changed,binfile,$(obj)/builtin-payload-key.bin xen_livepatch_key_data)

Does the builtin- prefix have any real significance here? Anything that's
part of the hypervisor build is "built in", after all.

> --- a/xen/include/xen/livepatch.h
> +++ b/xen/include/xen/livepatch.h
> @@ -143,6 +143,11 @@ struct payload;
>  int revert_payload(struct payload *data);
>  void revert_payload_tail(struct payload *data);
>  
> +#ifdef CONFIG_PAYLOAD_VERIFY
> +/* The public key data contained with Xen used to verify payload signatures. */
> +extern const uint8_t xen_livepatch_key_data[];
> +#endif

What's our position towards such declarations without (C) definition? The
8.6 deviation talks about cases "when the definition is compiled-out or
optimized-out by the compiler". Shouldn't we follow the 8.4 model here and
annotate them asmlinkage as well?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 11:06:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 11:06:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006635.1385857 (Exim 4.92)
	(envelope-from )
	id 1uN8Ql-00081v-SG; Thu, 05 Jun 2025 11:06:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006635.1385857; Thu, 05 Jun 2025 11:06: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 1uN8Ql-00081o-PG; Thu, 05 Jun 2025 11:06:43 +0000
Received: by outflank-mailman (input) for mailman id 1006635;
 Thu, 05 Jun 2025 11:06: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 1uN8Qk-00081i-JE
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 11:06:42 +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 28bb2e49-41fd-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 13:06:41 +0200 (CEST)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-3a51d552de4so476915f8f.0
 for ; Thu, 05 Jun 2025 04:06:41 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-235eaa07e4esm18339225ad.54.2025.06.05.04.06.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 04:06:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 28bb2e49-41fd-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749121601; x=1749726401; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=5TL2OKvnFRZvlLf1NeBvt0g3XWO8GC90uoai/s0OHfE=;
        b=AoIIRt9PFw7enhE2SEfE/s0u7MnFdHhqrDHTralm3SsTUn6geRApjqY/iUNL9G/WtB
         1Ijk4sEBgemGLQSRrYJ47T6U52DOepdeS0aXtgPzNRLDXvUibrw6tFkoibtmvB7arY3c
         SRNIeKQFVBBjig7miat8zKuCr3aBF3il2Jzokvgx204xQYA3chxveHZeGAAaosUtBkT+
         0OjDSfX6da3k9z5h2s+9w6WSUcNulbqAcyFNATbh7iQ21LEvOV/hIZRAuZjGb1ErrIi+
         oOTJOHRRbBE2W7GsnyrNWNY4jqi/+1n4t6FvV0c9vF4czGALJfyb53nordY3ERQBn5Jf
         UIBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749121601; x=1749726401;
        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=5TL2OKvnFRZvlLf1NeBvt0g3XWO8GC90uoai/s0OHfE=;
        b=wLtkuEuXcDc8bGuSAG0Sf6PzTEShyKpa69O2ahSbucSbato2c/oYpuBXe+9oGBBFBM
         MFJVYP9RIrIZsrvMccWzJL1C2b0f1HXW+it3n+6SxhG1xU/aoDIo0uaWjCfKzSab9pJA
         fS2wenlaqVhTSz0TrYGOu+OYPSr/Fh9PfNo4ROWlv5MhkxgTAeOpsL7BomD9Q66b0ecc
         y/kSrTv2UOFFOnhA60y1JXOSIyJFPocnznZx57JE29+/tdk1e80AKsE9RDSSyf41k/wT
         ammA7kENw+3gybUWyfGLqDRmFy4X/TM55flo+H57+S69boxZTjxUQS0W8SQxritB+UNY
         2nQA==
X-Forwarded-Encrypted: i=1; AJvYcCUNeNbfcA4di0OB1OizaRm6hKBurQ/8e+5uPzNkOvEoC9tJS670jkXItaFXEXySeObES6XGsSWPupQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw32LBhwnU7/R7xowjj++EbuvpIJx1+sphAaJPS2e8A7uXDedjC
	LkjelVpystdNuEO1ITkxiUUEIVtjKz0sDAChQ3xd5/jRcTuAg+S30KOUTd2uKYyOkg==
X-Gm-Gg: ASbGncuDtqVZ1YJgFH3MmdbVufa7QwJoDwk4h6xM75Jabacx4x2x8bhCem9E1xcAAKD
	+uv2GzQjn+qhh3UtUIsdX4ffRosYFMgn3b6FzajbNBe+OR4x6rh+7Phm4fzmQI6P+wW/K1XBjCG
	+mxEDONTpJIRxX4m4hjHpk5x2lP12hO6yRONK0rUPsYni1wnKS9B0loGBrNOkn6L6h19kJmXnco
	IJv14ECfD/BjGnWBjtHYKAXWkpU50rv9X4Yt8cJeq8OCjS8yJuoZarcm7vjzT8TU6J/Q8kKyPne
	F0qp9SMsVHFkGrruMS+SYnfPNgNthhCOz8jz7s0DTQJz0EGHCtVx8MsOl00y3T255IYmCxmpW1w
	SFOQ+1cDtRtg/pDzcEUxPaDgxAT7BOKZI5PiI
X-Google-Smtp-Source: AGHT+IGz0R9HriHQZSH4zKGGAi9IPK4HigC20jCS63PZqUJLXSskun3P4fssi5FN9L+mjAAqakzU3Q==
X-Received: by 2002:a05:6000:178e:b0:3a4:fbd9:b93c with SMTP id ffacd0b85a97d-3a51d961b26mr5392800f8f.30.1749121600927;
        Thu, 05 Jun 2025 04:06:40 -0700 (PDT)
Message-ID: 
Date: Thu, 5 Jun 2025 13:06:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 3/5] crypto: Add RSA support
To: Ross Lagerwall 
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: <20250602133639.2871212-1-ross.lagerwall@citrix.com>
 <20250602133639.2871212-4-ross.lagerwall@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: <20250602133639.2871212-4-ross.lagerwall@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 02.06.2025 15:36, Ross Lagerwall wrote:
> In preparation for adding support for livepatch signing, add support for
> RSA crypto.
> 
> The RSA code is extracted from Nettle at tag nettle_3.2_release_20160128
> (https://git.lysator.liu.se/nettle/nettle).
> 
> The MPI code is extracted from Linux at commit eef0df6a5953 (lib/mpi/*).
> 
> Signed-off-by: Ross Lagerwall 

Acked-by: Jan Beulich 

This looks like it's independent of the earlier patches, and hence could go
in right away. Then again maybe doing so wouldn't make much sense prior to ...

> --- a/xen/crypto/Makefile
> +++ b/xen/crypto/Makefile
> @@ -1,4 +1,5 @@
>  obj-y += rijndael.o
> +obj-$(CONFIG_PAYLOAD_VERIFY) += rsa.o

... this new Kconfig setting appearing (eve though the lack thereof wouldn't
break anything, afaict).

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 11:16:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 11:16:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006652.1385868 (Exim 4.92)
	(envelope-from )
	id 1uN8aT-0001eJ-Ul; Thu, 05 Jun 2025 11:16:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006652.1385868; Thu, 05 Jun 2025 11:16:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uN8aT-0001eC-Qj; Thu, 05 Jun 2025 11:16:45 +0000
Received: by outflank-mailman (input) for mailman id 1006652;
 Thu, 05 Jun 2025 11:16: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 1uN8aS-0001e1-RC
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 11:16:44 +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 8ec92b90-41fe-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 13:16:42 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a5096158dcso708315f8f.1
 for ; Thu, 05 Jun 2025 04:16:42 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a526f4c808sm2043887f8f.28.2025.06.05.04.16.40
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 04:16:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8ec92b90-41fe-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749122201; x=1749727001; 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=+yTB1/fvMVCTDxVNoJBahxAhkJNiv9OGan5nCvCNr0Q=;
        b=H38wIFI7ivo4vYUeLUnnp2kizRHhvAaIlngd8rZs0s+5j+ycjau5lVybsyaxDmL6LL
         SPnoLUprROO/QudUbyABr3IlZ68/gkFiiZM6gvKVIUnivSyVyuTbtBElr3n1May8kD09
         n+q+A7gCcMQAM5I+25/W+26RRUTf/I+OGC38g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749122201; x=1749727001;
        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=+yTB1/fvMVCTDxVNoJBahxAhkJNiv9OGan5nCvCNr0Q=;
        b=cY/cJZy/uz8fvoUUNR4nyQR8RVTfE+aDD/x/7uW2Y8A6qvbfHFY1Zbr0wUNFAuWekA
         63IkTghvPkY8qsUfkxe3Z7zMl5WUIgVZ1divbg/DGkaloPHqHoUNHQgY8lBGhW7DYCXB
         RDn4YNI57WFUwmNpll/nYCTcoBUz53Wu1SUi2EjGGtOieYaoutFkKiAwKmY59ozRMiEd
         fFhQNqV3smW7ttg4US8G6Wz6cUxPD7GTQW4EMww0Da+9BkvflNHMQz0LMhqLjkNGsYse
         2qw6SAGAfhKFdSnZNR+h0pV44XesXvvR8XwnDLRw0IAshOcRSQB8HH1UkVbSSpDmUfS/
         yu9g==
X-Gm-Message-State: AOJu0Yz/gAtpSmepV49vsSM9ZMhyjQLMdshWuPaFI9ToUG21pVYNbIUy
	rOLnsjfXcOwxp+rhi9SZ6pmWTCI4iep1g7i8F06kNlODtTzbQ/ygcI7R0AfqajQcdo2UHoP1Dit
	+bUPr
X-Gm-Gg: ASbGncsPzqKSheifkpGJxodUyxgxUtN4P2RR0rzZWz0OPLVPSMqAC+mwedGqeW6acAM
	U0TBZIoRs1NSrjhSrMmDbVWiBf37WawizE22S6R+yVlFkwtsJJxVa27fs2OdrKnEBadcAiqmw16
	nHPMyKJl+Ro6HzZCM/JrYKf/aUA5lUO1X9vScpwDKSNyCy4YW8BNSfLdO9iANmFoa7rao+EykoO
	UGyJC4SVu9V5WojfdSd8WKv7Nfb5Pf4yzs/h2i9Z7szpPGB4cLa0ghbtu9w495a/wJb9N61k5qr
	QgEvN7CBmBrFSm8Ricd9+ON8FNRcGMJdZ02edM5XDIuoUQXFKA/uufDkYWA2TFlU+ZeHwkPck7Z
	bP3CO3QHacJbmAn44j0xBv3FM5Ox5Pm4sibw=
X-Google-Smtp-Source: AGHT+IExmauxR8dRM92tLzKx7a+12D9g9GI/WV13HI+84A8h/PRzpeMh/5wMZUrSZtyTYrM7KKXynQ==
X-Received: by 2002:adf:f68c:0:b0:3a5:24a9:a5d3 with SMTP id ffacd0b85a97d-3a524a9a7c5mr3309459f8f.17.1749122201460;
        Thu, 05 Jun 2025 04:16:41 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Ross Lagerwall ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	"Daniel P . Smith" 
Subject: [PATCH 0/3] x86/EFI: Fix detection of buildid
Date: Thu,  5 Jun 2025 12:16:35 +0100
Message-Id: <20250605111638.2869914-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

Bugfix in patch 1.  Minor cleanup in the rest.

Andrew Cooper (3):
  x86/EFI: Fix detection of buildid
  x86/EFI: Explain buildid.ihex
  xen/EFI: Drop __ASSEMBLY__ ifdefary in efi.h

 xen/arch/x86/efi/Makefile | 2 ++
 xen/common/version.c      | 7 +++++--
 xen/include/xen/efi.h     | 6 ------
 3 files changed, 7 insertions(+), 8 deletions(-)


base-commit: eb57fe072232c9836d085020450ce1434b21a819
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 11:16:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 11:16:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006653.1385873 (Exim 4.92)
	(envelope-from )
	id 1uN8aU-0001hU-6Q; Thu, 05 Jun 2025 11:16:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006653.1385873; Thu, 05 Jun 2025 11:16: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 1uN8aU-0001gp-11; Thu, 05 Jun 2025 11:16:46 +0000
Received: by outflank-mailman (input) for mailman id 1006653;
 Thu, 05 Jun 2025 11:16: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 1uN8aT-0001e1-2R
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 11:16:45 +0000
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com
 [2a00:1450:4864:20::329])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8fc205c0-41fe-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 13:16:43 +0200 (CEST)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-43ea40a6e98so10156165e9.1
 for ; Thu, 05 Jun 2025 04:16:43 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a526f4c808sm2043887f8f.28.2025.06.05.04.16.42
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 04:16:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8fc205c0-41fe-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749122203; x=1749727003; darn=lists.xenproject.org;
        h=content-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=moO8xlFiAerCznDfAfTky8HoC4xQsYEV2DeeU3FdPhg=;
        b=onuiSKS/0D09FV8xaJ8IZzr4/Wt+HEwXxA38psVQlx9Q8318qdQFOo6AQ9otNHNpna
         n7Uq4XuBN2luhG0dobe/mVVblLVBGOvE7JwkSKTtSG4qr9xA06XLWAqIwYShvdvWw83U
         LtE54n4a+6DWUgA7jXsXpm+Dbq/kUdGRHA1x4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749122203; x=1749727003;
        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=moO8xlFiAerCznDfAfTky8HoC4xQsYEV2DeeU3FdPhg=;
        b=lFdDTZktUAKLoboaVoisQ5Bz1lWl+W+yLm4SeuHAoj17EPiRHw/wboS3s8Abw/YsKG
         O4ZFJrweT2WWTRcejlz7USzPejMRCdC7PzRQG7EEbVb6agD7aUSwhZ1HUzdEYQMyjbxI
         SuIBc14KvEdjcFauUs9Es3z1SFupggiCjC8l9fCVeh48dENG9wlZiOOake8WgPjcahyy
         ptacXuPgIVOGY6Ja/4kB/NQdOzCLZ212V2B1+WsaPCPMNUsctReH4lIe1bXuIrI0ImhC
         akAzwGqZoV4cU0aflcyqXnWUkfSSGp1MLIOu7/zichnkBY9qfDFt3AMQWdo3qW+zOxBj
         65Jw==
X-Gm-Message-State: AOJu0Yy1c25T3eMiJKqNM/EJr8uNu3KIS/xedD871Hji9HFlLYkdX2V3
	AmRBNzWggk88NKaoXUoszwmhbmF4PtarCf4cUAj6gzQ714yLUpEWnVI80a5a6KeoTCeL7Yr5e1+
	Id5b/
X-Gm-Gg: ASbGncuovaNHsbmqo8QGH08vFTuELt+wnIhBobiIlfRzlGcWisUi3KO6sNst4GG1bY5
	TGTXM2oZeidA7gZk9zl025iPaxrn+NzZw7FHBKqVPwWFMQeZ9kv5FmjWVsowLRNtKOv2IltvW9i
	IvuooF+VE8dfMUDVdp5PiRUmz8ML+R5x+0wGnGkwYwJorgNdngVHB7+uXrGxmV2IRk2UxpVHzZ4
	y86HZ0GvbzqZfUYZXC8aCfEjNIGD5pkrkbQucBqbi/KNKRnsJbp62J3aq3wR2Squ6pEHxOhsQ1K
	rQiWldNXBwsvymDcaHWBEbKWHogVElijVxhK05NzRJXMFcms9ggAAnq3WDkQTvb330kuXL180Hf
	S4bxEfKV06P+6MxWhNE++CDWkYJT9mLAesmI5MSaJdV7fzw==
X-Google-Smtp-Source: AGHT+IH8mOB4XgF/U6YfkV/aYOXYekYBKPq8fbc96Y8Ht/wd2TKdqPhACM6OFgroSNmkOMZhrwxP3Q==
X-Received: by 2002:a05:6000:1ac9:b0:3a4:f439:e715 with SMTP id ffacd0b85a97d-3a51d8f6356mr5352020f8f.9.1749122203120;
        Thu, 05 Jun 2025 04:16:43 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Ross Lagerwall ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	"Daniel P . Smith" 
Subject: [PATCH 2/3] x86/EFI: Explain buildid.ihex
Date: Thu,  5 Jun 2025 12:16:37 +0100
Message-Id: <20250605111638.2869914-3-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250605111638.2869914-1-andrew.cooper3@citrix.com>
References: <20250605111638.2869914-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This is an awful lot of magic to only be explained in a commit message.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Ross Lagerwall 
CC: Marek Marczykowski-Górecki 
CC: Daniel P. Smith 
---
 xen/arch/x86/efi/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
index c6678652fc98..3e88f552d20b 100644
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -6,6 +6,8 @@ cmd_objcopy_o_ihex = $(OBJCOPY) -I ihex -O binary $< $@
 $(obj)/%.o: $(src)/%.ihex FORCE
 	$(call if_changed,objcopy_o_ihex)
 
+# buildid.ihex is an empty COFF object.  It exists for the side effect it has
+# when linking into xen.efi, causing --build-id to attach a .buildid section.
 $(obj)/boot.init.o: $(obj)/buildid.o
 
 $(call cc-option-add,cflags-stack-boundary,CC,-mpreferred-stack-boundary=4)
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 11:16:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 11:16:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006654.1385886 (Exim 4.92)
	(envelope-from )
	id 1uN8aY-00027h-Aa; Thu, 05 Jun 2025 11:16:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006654.1385886; Thu, 05 Jun 2025 11:16: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 1uN8aY-00027W-7S; Thu, 05 Jun 2025 11:16:50 +0000
Received: by outflank-mailman (input) for mailman id 1006654;
 Thu, 05 Jun 2025 11:16: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 1uN8aW-0001od-UT
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 11:16:48 +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 904183ee-41fe-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 13:16:44 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3a365a6804eso613747f8f.3
 for ; Thu, 05 Jun 2025 04:16:44 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a526f4c808sm2043887f8f.28.2025.06.05.04.16.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 04:16:43 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 904183ee-41fe-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749122204; x=1749727004; darn=lists.xenproject.org;
        h=content-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=Um/nkv4z1T0RX+MCLdrgS/PNaKhUEklnqmf1PU4WKtE=;
        b=Bdumjplz8pwYL8jhZNoztKAqyYB5f1NNP+g4QfB1uhf0jXjCoblXOUGlq7ruVAzFrX
         wFsFYbVauzBBGhLRPPlFprob2FMvDP6VQAuXkvopZeDAsBLnxfDyM21PVjFz4iGInBnP
         5fXpubdlmSwM/0YUWiIWI6AzlMwS1JlN9MVUI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749122204; x=1749727004;
        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=Um/nkv4z1T0RX+MCLdrgS/PNaKhUEklnqmf1PU4WKtE=;
        b=JP1Pq6977CGNNukhdTQYFUaDnV/v7znayybVT+DkauvRBtTg3z3beybHl5kjoz4/X9
         LXY4E+drxClbjRkYWUTt+WKawF5mlaO7LA5wFfWVt7xTdBxZaSiKaxFu2Ah8nlYNcM0u
         GguICxTA9lUsa07vD9eu9swPNLnSWFSDcqNfMi1A3A/naXKA1RAVeTyEhN1e7qk7S6oI
         28wfO84X4W4DCpqfrmXDsjcx80B322msB+btaH2ERrjyj2RmBSuMEp0vyWa/xHZLHJED
         1C+J4e5gsw7jwX0gSQcknY3grBE+BsQUpo4619mdYAdJcTZBrF2IcruB2/cdHKQ+P9Tg
         Kl5g==
X-Gm-Message-State: AOJu0YzLgkSytrVTnHP3XZPwiNHBHQbVrl8U+3D4jUwJoLWlHZrYkMrc
	FW1HvI1VneP3yPaGK8ugttqOefW5nAHgb1iGMWo6YusPSR2RY4c5agBcJe0faT5pKFuDuf4HX67
	+mRQ8
X-Gm-Gg: ASbGncvtwu2ezyXPW1dgbQ+QBWh1dsnfh9qpdFBEjjV/GIs10LNnrR08fonVUe5Z3gn
	Yhqj9DLgcXHSbmZli2gC8/HH1ja9t+oa9tfCwX11y9ejKwN6fSActALk3rpOUVX5HJL15T6izkR
	0V2sCdMOxP/y3AwwzhGmyQ2N3EAHv9ur6DhH04oZlDusKji/LT5vryFVIlSJP7Fg6cNKZ+ZG3YJ
	IL55BQktxe5YUWMf9TK7UkahDlxfbf2UffuGjqi9f/S8pOVoyvHEGU5tTdhgTBIzKQmqyZwuuE1
	A2MTrg4dA/dFwplRcD1Z0TiRax9DgSbqrKwsaptyxr4VAljjxDC6dAPvf/2SBWLMLHI2sXxEBlS
	sBXRKdmcaDPxgGtPWH6q6RPI3yB5ZNc2J5Vc=
X-Google-Smtp-Source: AGHT+IHXbx1ROPnuIC7JMFjjz7VrKMTObMdKBp/S6c+zhNrVde8FiJm0pu5OtqfXMn/ts1xC8RB3lA==
X-Received: by 2002:a05:6000:2384:b0:3a4:eef5:dece with SMTP id ffacd0b85a97d-3a51d958744mr4428248f8f.35.1749122203934;
        Thu, 05 Jun 2025 04:16:43 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Ross Lagerwall ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	"Daniel P . Smith" 
Subject: [PATCH 3/3] xen/EFI: Drop __ASSEMBLY__ ifdefary in efi.h
Date: Thu,  5 Jun 2025 12:16:38 +0100
Message-Id: <20250605111638.2869914-4-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250605111638.2869914-1-andrew.cooper3@citrix.com>
References: <20250605111638.2869914-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

There's already C outside of the ifdefary, proving that it's not included in
any assembly files.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Ross Lagerwall 
CC: Marek Marczykowski-Górecki 
CC: Daniel P. Smith 
---
 xen/include/xen/efi.h | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/xen/include/xen/efi.h b/xen/include/xen/efi.h
index 160804e29444..623ed2ccdf31 100644
--- a/xen/include/xen/efi.h
+++ b/xen/include/xen/efi.h
@@ -1,9 +1,7 @@
 #ifndef __XEN_EFI_H__
 #define __XEN_EFI_H__
 
-#ifndef __ASSEMBLY__
 #include 
-#endif
 
 #define EFI_INVALID_TABLE_ADDR (~0UL)
 
@@ -23,8 +21,6 @@ struct efi {
 
 extern struct efi efi;
 
-#ifndef __ASSEMBLY__
-
 union xenpf_efi_info;
 union compat_pf_efi_info;
 
@@ -53,6 +49,4 @@ int efi_runtime_call(struct xenpf_efi_runtime_call *op);
 int efi_compat_get_info(uint32_t idx, union compat_pf_efi_info *info);
 int efi_compat_runtime_call(struct compat_pf_efi_runtime_call *op);
 
-#endif /* !__ASSEMBLY__ */
-
 #endif /* __XEN_EFI_H__ */
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 11:16:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 11:16:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006655.1385892 (Exim 4.92)
	(envelope-from )
	id 1uN8aY-0002AA-Ji; Thu, 05 Jun 2025 11:16:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006655.1385892; Thu, 05 Jun 2025 11:16: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 1uN8aY-00029H-EY; Thu, 05 Jun 2025 11:16:50 +0000
Received: by outflank-mailman (input) for mailman id 1006655;
 Thu, 05 Jun 2025 11:16: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 1uN8aX-0001od-54
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 11:16:49 +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 8f4bc1f5-41fe-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 13:16:43 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a522224582so484847f8f.3
 for ; Thu, 05 Jun 2025 04:16:43 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a526f4c808sm2043887f8f.28.2025.06.05.04.16.41
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 04:16:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8f4bc1f5-41fe-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749122202; x=1749727002; darn=lists.xenproject.org;
        h=content-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=3LwfB2gF9isEgIiM5Co6kyT/fwMQ7m7hvxAgSTzQdrA=;
        b=K+v9MopssMNGw8HdOn+44h2jX56dz8SEVoNkGzOXsEG4kVoud/oRwZv7aM1ZNxnKMr
         +tdEdh1ltQwa0wAd2aEH4EWq1zczsj06k96uA1QUmdrX5XGTA42c5Ob8g4m5Nmd06482
         nSra8EImvrPwU9jRNT9Bi6YgEYKFSySeuSV1I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749122202; x=1749727002;
        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=3LwfB2gF9isEgIiM5Co6kyT/fwMQ7m7hvxAgSTzQdrA=;
        b=G0hfG8ij//bJs7FEU8u2lvySdXrr01B62/4Qh/gSyCMNzzTx0cVB9sv6+0WxdHXvKD
         EhgBzvpWgaO1vERWg2DpFQ8qaxBT/OUpgUGADVQClQNiEXjf+1h+Azyv26fycvxAuKdI
         r90bF7zYQAXziFaGjtoxQsK+Q6VpBdCrcoa2atIuHTZpnC0Q65UURzPUkd33pCS9fZCT
         fpzu3xdkDLWROpc7gWbWheDLuKLS1jYNSaGH93MHOoVBXnGAeb60hx7HfPA+yjYx6ilf
         EYMB/0ufgeI1Kjh8OGf4Py0kr1ZLV897JCMg7MIqh+GEBslGhZFqDurCJDG8fXvVEit3
         eoug==
X-Gm-Message-State: AOJu0Yw/XfiLQCTENEPBo/Dx0opkewQH4nlNyhIYR7QlOeRrDL/7In+Q
	OwNDgAXNLiddP3AU7jS5AXUAaUlS4QOP72gxQ+B6kF+aUBgmXcfl2DZZwiTFUMb+dDAHQhMgdAL
	y0xK4
X-Gm-Gg: ASbGncvflaE856IJXhJbOPAb6+mzQRC9Oj37KFas1DfxfBBTWKl+FV9cAgCp+tpj7Kg
	ztXOPtGi+7VsKlErKtxzEXAHC3bf1YPZ9y2CKRHn8mVVssORQf5sxUiiDE0oNfA/Ppibh+HFZIx
	3gJknJ7d3BpaSyi82wvG12VnXuQW6BquvMRjnvv9Qu+bJFrLJUQaxRc28gGztFolo372I4EnDYr
	IalWfDkPk6kYFGUMU5LE+AJMvtR6Pe9zM09yM2IZZQg3aduMpl6rffTDVmH+Obzmndto4HIQzw+
	MCQRvhJsldLeV98WLeSlcDhcKS8AFaa3gwvZ8uL0Y576+Yq6BM0TmKIVw38A0/mM7wge/KCbfn/
	xhQo6no/dDEAYo6Ie5CWcvlGw
X-Google-Smtp-Source: AGHT+IFVlMhltrqqcKZXTRbuUVmCW3hd9rmmakfK2vK2/mAGdohruOl3xoKC6/s8KgnJs25bYvBvig==
X-Received: by 2002:a05:6000:2c0f:b0:3a4:eecf:b8cb with SMTP id ffacd0b85a97d-3a51dbe3d35mr5517306f8f.28.1749122202237;
        Thu, 05 Jun 2025 04:16:42 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Ross Lagerwall ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	"Daniel P . Smith" 
Subject: [PATCH 1/3] x86/EFI: Fix detection of buildid
Date: Thu,  5 Jun 2025 12:16:36 +0100
Message-Id: <20250605111638.2869914-2-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250605111638.2869914-1-andrew.cooper3@citrix.com>
References: <20250605111638.2869914-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The format of the buildid is a property of the binary, not a property of how
it was loaded.  This fixes buildid recognition when starting xen.efi from it's
MB2 entrypoint.

Suggested-by: Ross Lagerwall 
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Ross Lagerwall 
CC: Marek Marczykowski-Górecki 
CC: Daniel P. Smith 

I don't like this patch and tried hard to do it in a better way, but the EFI
aspects of the build system are too intractable.

While on x86 I can in principle pull the same common-stubs.o trick, split on
XEN_BUILD_PE rather than XEN_BUILD_EFI, that doesn't work on ARM which
hand-codes it's PE-ness.  Also, it's really not EFI related, other than as a
consequence of that being the only reason we use PE32+ binaries.

Binutils 2.25 is now the minimum, and the makefiles can be cleaned up
somewhat, but I need to backport this patch, internally at least.
---
 xen/common/version.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/xen/common/version.c b/xen/common/version.c
index 5474b8e385be..56b51c81d2fc 100644
--- a/xen/common/version.c
+++ b/xen/common/version.c
@@ -203,8 +203,11 @@ void __init xen_build_init(void)
     rc = xen_build_id_check(n, sz, &build_id_p, &build_id_len);
 
 #ifdef CONFIG_X86
-    /* Alternatively we may have a CodeView record from an EFI build. */
-    if ( rc && efi_enabled(EFI_LOADER) )
+    /*
+     * xen.efi built with a new enough toolchain will have a CodeView record,
+     * not an ELF note.
+     */
+    if ( rc )
     {
         const struct pe_external_debug_directory *dir = (const void *)n;
 
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 11:17:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 11:17:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006666.1385906 (Exim 4.92)
	(envelope-from )
	id 1uN8ar-0003Fl-PD; Thu, 05 Jun 2025 11:17:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006666.1385906; Thu, 05 Jun 2025 11:17:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uN8ar-0003FV-Li; Thu, 05 Jun 2025 11:17:09 +0000
Received: by outflank-mailman (input) for mailman id 1006666;
 Thu, 05 Jun 2025 11: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 1uN8aq-0001e1-IK
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 11:17:08 +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 9e0e11c5-41fe-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 13:17:07 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a5257748e1so631841f8f.2
 for ; Thu, 05 Jun 2025 04:17:07 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23506bc85b8sm117866975ad.52.2025.06.05.04.17.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 04:17:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9e0e11c5-41fe-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749122227; x=1749727027; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=P74eEXvJTUvSHXcD9lJwchHDajfQ9apm7tVl2xTy/kI=;
        b=GtfcMCn93bT6gOZhh0F0zc0l44cIO8D+2Q0zc1I4pFzm3zui4H6cmxMPWI/9+Qyf8T
         INeEkp/OMC9/GinrIm+u7KbbaY9nlWJannh/a29qYLuRapA46MoL10NDpBw39TNPi99F
         zNGu8Ws/FqM0DZnt36RpjgVWzrBo+3p2vMARdoc+/2fI9R59J6/AFFKN3Rer//zQxCca
         pJIZzD6dDH2+BMBbgV1lMztxo2xw+tUq7J5esODa975PBPyomYuU3JiEE8kGMMI3Q59Z
         hI7+HkbSWZ3ThYAByhozHed5V3c2AL4lil/UmKuIPBAfXhfGADZUGdyKOwvS1wZtTNcM
         rUMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749122227; x=1749727027;
        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=P74eEXvJTUvSHXcD9lJwchHDajfQ9apm7tVl2xTy/kI=;
        b=g/Q4qqdyxw/FaXr678Ut8Sw5QcTS2wwUigpGq84H9alXlHXilk6OuLJg8XMxlWQrW8
         kW249+GKsMw9xgICNJMJdngvv+9nXzXIgKrgToenvvaxUlPTiFAXsv7U9t73xj8usFNV
         9co1l2hqHVfT+fTfkiKAsrA/hOIvzKuSagFnCP4JbPGJakNqcOfZv9xE4F21qkH7AMq8
         QI30go6pX3apvR/b/tXC53dN+P3H0ICkYgu4I6oOQYsHQd8xwPKGxv/s/ODjo6QYodL0
         ZOXAn9mQV8F/uJojr+O5N8BqfB0rfNoD8G37WMpqvhB5UHHelI2D7FZhpYIkEejw/zUj
         EX2Q==
X-Forwarded-Encrypted: i=1; AJvYcCXFuyI//XEef5ryC5RxvVWpZqwOkhM/27r5gqgOJPnpQcKJIui7GNQC7KcZsxNVG70ikHJ9s2Tj1VY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwBkZQ+MEmeV2bRgOWn8QuMa4PXWJ6qlBsqwA/RZCBKWscVpobE
	ouI8Zq8i4ISVrhSO8Hj/SEn4j76Qnb2U+q9TRc2et8j5Erb5YZfYLFcQif08ky782Q==
X-Gm-Gg: ASbGncsfrqaiIB5IjmI3hlDvEcGJXawLQhHoUtDfStNLjOqgEwnRXDodumsqxcuNXDF
	aRt7iEo0mn16DxnL8USVyJ+k2HvZp/TpjvQUGKgVezIjlSGyXh81f9pPrD6o6rLQxmkjxEEkBsu
	Dq/CiZDZ+3BssaUs+k9pgQK3ftXMdiHNW8x4B8YsK0cLpWYdl6YQqQkFR1W/iRQ1bsQRCrbTcLz
	oJ/7mcjoiYVGXULRwTJ4iDNyK6KphAF/k2xZ343NfERT7Hh0cv1ITTWBKbTX7cjvUf6u471NvI5
	nUw82Fj71zXGmNOr3kLPN6DFDPvGR7EFwhuiUX7lRBxWDUzH9LvvyOByjpuqMBKa5FIAtxaZ6Wv
	NG7awWrwCCtw28OwZK1XGbu76URoVWXSgQ5qVZjuIyr8ZfeA=
X-Google-Smtp-Source: AGHT+IG+UDivQEqMWKfN2mqZSkF+NW93yKD1+5CIqdEEP9gTl9IEuLRWTD9u/7kvit0MT28mfX/uIw==
X-Received: by 2002:a05:6000:1a85:b0:3a4:d0ed:257b with SMTP id ffacd0b85a97d-3a51d923b56mr5606104f8f.22.1749122227354;
        Thu, 05 Jun 2025 04:17:07 -0700 (PDT)
Message-ID: <4deb4b15-71ce-40d4-8d6c-3ed04beb172e@suse.com>
Date: Thu, 5 Jun 2025 13:17:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 4/5] livepatch: Load built-in key during boot
To: Ross Lagerwall 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20250602133639.2871212-1-ross.lagerwall@citrix.com>
 <20250602133639.2871212-5-ross.lagerwall@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: <20250602133639.2871212-5-ross.lagerwall@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 02.06.2025 15:36, Ross Lagerwall wrote:
> Parse the raw data of the embedded RSA key into a form that can be later
> used for verifying live patch signatures.
> 
> Signed-off-by: Ross Lagerwall 
> ---
> 
> * Fix endianness of builtin key lengths
> * Set builtin key to __ro_after_init
> 
>  xen/common/livepatch.c | 36 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 36 insertions(+)
> 
> diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
> index 9a0df5363b59..92d1d342d872 100644
> --- a/xen/common/livepatch.c
> +++ b/xen/common/livepatch.c
> @@ -11,6 +11,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -73,6 +75,10 @@ static struct livepatch_work livepatch_work;
>  static DEFINE_PER_CPU(bool, work_to_do);
>  static DEFINE_PER_CPU(struct tasklet, livepatch_tasklet);
>  
> +#ifdef CONFIG_PAYLOAD_VERIFY
> +static struct rsa_public_key __ro_after_init builtin_payload_key;
> +#endif
> +
>  static int get_name(const struct xen_livepatch_name *name, char *n)
>  {
>      if ( !name->size || name->size > XEN_LIVEPATCH_NAME_SIZE )
> @@ -2300,6 +2306,31 @@ static void cf_check livepatch_printall(unsigned char key)
>      spin_unlock(&payload_lock);
>  }
>  
> +static int load_builtin_payload_key(void)

__init

> +{
> +#ifdef CONFIG_PAYLOAD_VERIFY
> +    const uint8_t *ptr;
> +    uint32_t len;
> +
> +    rsa_public_key_init(&builtin_payload_key);
> +
> +    ptr = xen_livepatch_key_data;
> +
> +    memcpy(&len, ptr, sizeof(len));

How do you know enough data is available?

> +    ptr += sizeof(len);
> +    builtin_payload_key.n = mpi_read_raw_data(ptr, le32_to_cpu(len));

Even more so here. And then again below.

> +    ptr += len;
> +
> +    memcpy(&len, ptr, sizeof(len));
> +    ptr += sizeof(len);
> +    builtin_payload_key.e = mpi_read_raw_data(ptr, le32_to_cpu(len));
> +
> +    return rsa_public_key_prepare(&builtin_payload_key);
> +#else
> +    return 0;
> +#endif
> +}
> +
>  static int cf_check cpu_callback(
>      struct notifier_block *nfb, unsigned long action, void *hcpu)
>  {
> @@ -2318,6 +2349,11 @@ static struct notifier_block cpu_nfb = {
>  static int __init cf_check livepatch_init(void)
>  {
>      unsigned int cpu;
> +    int err;
> +
> +    err = load_builtin_payload_key();
> +    if ( err )
> +        return err;
>  
>      for_each_online_cpu ( cpu )
>      {

So far this function can't fail. Therefore it makes sense that I can't find any
provisions for this case elsewhere in the file. Such provisions will need
adding as a prereq, I expect. Or alternatively it would want clarifying
explicitly that (why) none are required.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 11:19:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 11:19:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006678.1385917 (Exim 4.92)
	(envelope-from )
	id 1uN8cr-0004Dc-AF; Thu, 05 Jun 2025 11:19:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006678.1385917; Thu, 05 Jun 2025 11:19: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 1uN8cr-0004DV-63; Thu, 05 Jun 2025 11:19:13 +0000
Received: by outflank-mailman (input) for mailman id 1006678;
 Thu, 05 Jun 2025 11:19:12 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uN8cq-0004DN-6F
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 11:19:12 +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 e789dc49-41fe-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 13:19:11 +0200 (CEST)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-4508287895dso13180835e9.1
 for ; Thu, 05 Jun 2025 04:19:11 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-747afeabb13sm13031470b3a.62.2025.06.05.04.19.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 04:19:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e789dc49-41fe-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749122350; x=1749727150; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=dl0CV9uVnjD+WjAYgU5pp64MtCDepIU/VlSVf5u9atw=;
        b=WjvVZwUgtAMsegGyebEdi3Slr5bqtG6YHvsiBF+FSFBZUXmUtj4h6V0replOhDEhRd
         38D+0Q+84TK3e1c7800g9AvldRTJ/FlMkRBdTfQnCqwLQE6vII5BdP2H27182H3dMxYR
         UcUuCFJYBZTsi9+6IfOftmClnbBw073E9ZzsTQeYSgH4Lu5Ee8Q6H/YgQvB0snkPWbAv
         T41vNX/Aw98r7v/IDVAt0/3E72EVhk55xQ1QoI3JVUZ+7J+foXHHKBaRh5jPjsVvrqcR
         3yD5AE4stJquLXhJ6cLNBt4s+cAi2RvrOeNvnQ0LF0wxi072JQqCu0GyxDpCfYPl/Wja
         ptjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749122350; x=1749727150;
        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=dl0CV9uVnjD+WjAYgU5pp64MtCDepIU/VlSVf5u9atw=;
        b=WKUcM27G3VxrMBqAb0ShkZHO+WBJ6cue+Xy1pFanUFtVEuQHRmmzmy24NyP6EWr5V+
         KOMufjiadWomFk4+itAcvuXnTyOeb8wP3ShNAqVf87NygJCloyoiQNOwPeXf8DedbpHv
         p+BHKv/cgOkJjVr5T03lCpe4i72nVjtEMSl1AvisWyXUycJ/SJIsqHV2EgE2kq6rWeeY
         w9vR6afAjyIZYxmKUPTDvzy3FDOSBrRcudQkMDewjNUB/M7eDUKLSUknhErI7g/Wxe9P
         5e6tvOg4zjQLvFnvGemQ1Vz0oATPzhTOdefZKLoKi0JJDbA/J9enHk9AIdaKQaPVFi7n
         LOzA==
X-Forwarded-Encrypted: i=1; AJvYcCUGiIrkzz/baydG8cA7pxBlPfb2hy2FcwFfzs9IGLzrOl5VmLV7tdzzD4siN/oW/PLDMM4xNT4qWBY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxcbziKXcB1d82WvARVMPFzQlQdZejiLVp78+qmLA0enr5foYs2
	cyoFIwU504PCsl6uViBz0IMyYyph6QhAd1iJYOCPnhy+jRNRrzF3ybP7qPu6CMqUZA==
X-Gm-Gg: ASbGncs9uncwS45EjTwiy97awgxCoM96WCpjuo8qMsywzU4eZVg1b6dHtscQt8X0Qmx
	l2qiEIyn0DhsmHRpYpiJ6xnYdsEpW30zPOFNJtJEMLgmYXhxa5F4is2B5KNR5oRGSgX0qo+fgSd
	NY09ksX3fVyGV+nhWK2ZGuTsu8oRJCsZ2YH58mPGkTl0FIrlOIBoiL7gRjMDR88/IKYquFujJX/
	0WWdWyEyxUNl/fbMfscTumbtgBxR+BsrYFt5E/Zpabpphn5CMyVlUAYq4+tvrrKfHGBx2bVOt8s
	bHC6oFLOL4Nbux9oq4+6YUTan0c9If040xdURt8oaZjMv6WBxaqp4V7/Wy17nP8JdLlnJ9mbCjI
	sLEwH5TwoHW23II8dkvD5wbuRHb5cR7c92J0n7nz3/omqgeU=
X-Google-Smtp-Source: AGHT+IGSfQ32eB+E/W2CLMNdaybiMyJljp4CoCqw94Dkq+xbbV2uS2R8OtHeOuYOb59vCRhnoHnlIw==
X-Received: by 2002:a05:6000:2485:b0:3a4:f70d:aff0 with SMTP id ffacd0b85a97d-3a526ddadedmr2747628f8f.14.1749122350641;
        Thu, 05 Jun 2025 04:19:10 -0700 (PDT)
Message-ID: 
Date: Thu, 5 Jun 2025 13:19:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/5] livepatch: Embed public key in Xen
To: Ross Lagerwall 
Cc: Kevin Lampis ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250602133639.2871212-1-ross.lagerwall@citrix.com>
 <20250602133639.2871212-3-ross.lagerwall@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: <20250602133639.2871212-3-ross.lagerwall@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 02.06.2025 15:36, Ross Lagerwall wrote:
> From: Kevin Lampis 
> 
> Make it possible to embed a public key in Xen to be used when verifying
> live patch payloads. Inclusion of the public key is optional.
> 
> To avoid needing to include a DER / X.509 parser in the hypervisor, the
> public key is unpacked at build time and included in a form that is
> convenient for the hypervisor to consume. This is different approach
> from that used by Linux which embeds the entire X.509 certificate and
> builds in a parser for it.
> 
> A suitable key can be created using openssl:
> 
> openssl req -x509 -newkey rsa:2048 -keyout priv.pem -out pub.pem \
>     -sha256 -days 3650 -nodes \
>     -subj "/C=XX/ST=StateName/L=CityName/O=CompanyName/OU=CompanySectionName/CN=CommonNameOrHostname"
> openssl x509 -inform PEM -in pub.pem -outform PEM -pubkey -nocert -out verify_key.pem
> 
> Signed-off-by: Kevin Lampis 
> Signed-off-by: Ross Lagerwall 

While reviewing patch 4 it occurred to me: Why embed the key? Can't this
be specified as (another) boot module?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 11:24:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 11:24:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006691.1385927 (Exim 4.92)
	(envelope-from )
	id 1uN8hz-0006E7-Oz; Thu, 05 Jun 2025 11:24:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006691.1385927; Thu, 05 Jun 2025 11:24: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 1uN8hz-0006E0-MB; Thu, 05 Jun 2025 11:24:31 +0000
Received: by outflank-mailman (input) for mailman id 1006691;
 Thu, 05 Jun 2025 11:24: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 1uN8hy-0006Ds-B1
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 11:24:30 +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 a4ab62eb-41ff-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 13:24:28 +0200 (CEST)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-442eb5d143eso8072195e9.0
 for ; Thu, 05 Jun 2025 04:24:28 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-451fb1698acsm15887015e9.3.2025.06.05.04.24.26
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 04:24:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a4ab62eb-41ff-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749122668; x=1749727468; 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=iM1SRI6nLs3g6caslCWs1Vs8xHBwtCJcHog+t4a6Dn8=;
        b=hSBORaL4F4tw8B52pyK4sFs8Bb+hUmxFgu2S8+p20fSLKgrcZr8hR0iYdblvCxkQsu
         RB2n6msekzW8oDqVoYtEcbff1CazaH4jFp5is+/TPB58zFYohLiNF8MBZboi1JWusLXk
         uZdmXubn0tC/znCkUdDuv+PQHP/eUxKNwuP6c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749122668; x=1749727468;
        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=iM1SRI6nLs3g6caslCWs1Vs8xHBwtCJcHog+t4a6Dn8=;
        b=psompk8BBGv1viT3lgZtFuChoU977Y7UnElmgoBEpdwJMZRXBv19+tNRvm2ulP/pCC
         5mLre0hoZKYj19ZWttrS0dmHmB1nW6K52Fzmc1fXpTp81LwlUpdzh5XvvzLyAVBcl73L
         sVDJw1YLc2x4Cs5Y1gu/CwZIOML47Zn50OdBFkvbZuWrdQFTfjkT/tAbdu3KmpYRtT90
         QqE69iTLnhhIJzfQMApO+WMsVEIV0RZhHgpPGkWUUQ7//LDGuBXbYvaAYtz80XwxLdcG
         Qkxv7cF/+6z+6x1O5LLFYBuXCfhm45/4QrOVteB7iU7HoYolwLxXQkJwR1s4OMYN23yi
         RcoQ==
X-Gm-Message-State: AOJu0YyfWiQT6ZhjYExOFIgo0feBeNYq6lDoTgmhZCRZ3O+qVbnwbAgT
	fKhHd1VNIP5AflDrZWAQfzFZ9U/ztMjWXICq+vbV6M33ezfRaf2r05+nmrRH+TGraJA=
X-Gm-Gg: ASbGncuJSNos52yM4IeedS9wPR1WZt6VOFDL5bbnxub4mciOdMQ206Luadlv4Fp3+lZ
	+LeE6VgcOHxgpEXYDAvZ31Ktxe4cENYXXoXWWlLr7Fd5OXzGeLtF10+SXV5t+Jy484CNZX9Qk1U
	PJr7xNYI5LgQKlBrhRAgMdjr76USRwExBqhNcPRFcuwT2T4mb85RDfEiyzLa53AlIpelWUgQov4
	O8vjEWmzxF4Hk+tEblqRI0jgxKAV4VDwaxNui37EZilGjW4C5TLSqJTzIBisWVcA42y9MO9ScGh
	bwgE5FoxImI8stLm/W9ljUW33oZqENL7t5o5nxK33X+UZoAjSLkkcB+8fD1OGMXy/aFUkZDyarX
	t04ISOsWn7GAkybmWEfg=
X-Google-Smtp-Source: AGHT+IG4ASCKtKOCAF5n3VRq+SPfwvoyise3yaT3MRsbxiLQScv8j3+yrkgM+hrrdmZpPPUqUlpeHg==
X-Received: by 2002:a05:600c:6219:b0:441:b076:fce8 with SMTP id 5b1f17b1804b1-451f0a757c8mr62820235e9.14.1749122667806;
        Thu, 05 Jun 2025 04:24:27 -0700 (PDT)
Date: Thu, 5 Jun 2025 13:24:25 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jiqian Chen 
Cc: xen-devel@lists.xenproject.org, Huang Rui 
Subject: Re: [PATCH v5 03/10] vpci/header: Emulate extended capability list
 for dom0
Message-ID: 
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
 <20250526094559.140423-4-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250526094559.140423-4-Jiqian.Chen@amd.com>

On Mon, May 26, 2025 at 05:45:52PM +0800, Jiqian Chen wrote:
> Add a new function to emulate extended capability list for dom0,
> and call it in init_header(). So that it will be easy to hide a
> extended capability whose initialization fails.
> 
> As for the extended capability list of domU, just move the logic
> into above function and keep hiding it for domU.
> 
> Signed-off-by: Jiqian Chen 
> ---
> cc: "Roger Pau Monné" 
> ---
> v4->v5 changes:
> * Add check: if capability list of hardware has a overlap, print warning and return 0.
> 
> v3->v4 changes:
> * Add check "if ( !header )   return 0;" to avoid adding handler for
>   device that has no extended capabilities.
> 
> v2->v3 changes:
> * In vpci_init_ext_capability_list(), when domain is domU, directly return after adding a handler(hiding all extended capability for domU).
> * In vpci_init_ext_capability_list(), change condition to be "while ( pos >= 0x100U && ttl-- )" instead of "while ( pos && ttl-- )".
> * Add new function vpci_hw_write32, and pass it to extended capability handler for dom0.
> 
> v1->v2 changes:
> new patch
> 
> Best regards,
> Jiqian Chen.
> ---
>  xen/drivers/vpci/header.c | 47 ++++++++++++++++++++++++++++++++-------
>  xen/drivers/vpci/vpci.c   |  6 +++++
>  xen/include/xen/vpci.h    |  2 ++
>  3 files changed, 47 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
> index d26cbba08ee1..4b2f761c9c24 100644
> --- a/xen/drivers/vpci/header.c
> +++ b/xen/drivers/vpci/header.c
> @@ -836,6 +836,42 @@ static int vpci_init_capability_list(struct pci_dev *pdev)
>                                    PCI_STATUS_RSVDZ_MASK);
>  }
>  
> +static int vpci_init_ext_capability_list(struct pci_dev *pdev)
> +{
> +    unsigned int pos = PCI_CFG_SPACE_SIZE, ttl = 480;

I think you can drop the ttl variable, as said by Jan in a previous
review, the purpose of that counter is to detect overlaps in the PCIe
config space, but for the context here the call to vpci_add_register()
already serves that purpose by returning -EEXIST.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 11:52:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 11:52:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006717.1385940 (Exim 4.92)
	(envelope-from )
	id 1uN98m-0002WW-Rf; Thu, 05 Jun 2025 11:52:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006717.1385940; Thu, 05 Jun 2025 11:52:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uN98m-0002WP-OP; Thu, 05 Jun 2025 11:52:12 +0000
Received: by outflank-mailman (input) for mailman id 1006717;
 Thu, 05 Jun 2025 11: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 1uN98l-0002WJ-K7
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 11:52:11 +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 82b531b0-4203-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 13:52:09 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3a365a6804eso637888f8f.3
 for ; Thu, 05 Jun 2025 04:52:09 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3132c0bee0csm1361977a91.47.2025.06.05.04.52.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 04:52:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 82b531b0-4203-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749124329; x=1749729129; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=EReIriDEQXp6cLyaYJEvTn78WU91hQ9ZJ8NIrV1XUGc=;
        b=NYnaH8JusKzVaaOwIcmQ8f8Z11wMvTCimsHL9HPTy9w6M6GPxyGd5bcZn31yQwStud
         fPX76OUkZe5w+4ELY10jqUS+ndr0+/oAxo+Y/5E3BDVdSaFCT9FPNSFLzHR7WYtX4+5D
         YAXpRl24+WNUKsgyN2MwcOPIfqDOuIt5vt+udNJ+jiflku6LLmYnnMoZktXxOfJThecH
         kdzqLW8S5FWrzAYeSh1ur62u/xnbNcuPL/Uv5TLD5dwxD37UEcICG5BAL1idPj55cXJt
         K+BDJ78sROSbc9ZlL2/z7BNGwpkPzc7dh/9Y/qxYvLOV+5aro1m+lXr5Qf1n7rvXTbre
         MiiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749124329; x=1749729129;
        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=EReIriDEQXp6cLyaYJEvTn78WU91hQ9ZJ8NIrV1XUGc=;
        b=CYq9n4IYkcTW7/YsWT0S87NN7oKBQcuCPA1l4Y/VLbaDJxf9dkPY2+eJLdHcM1odZ7
         OjUI119o7tb0mnLJ6HTq7FB5r8GQbZo7VVf2OZeoD8QkqPesW9j4Spj3PPE/Uxzvc2Wq
         C1tHF82+2chFln93UDXjR2Lwk9+sqEuuoEZXlXGvX1Qa53j/zf3FLNNCxtzbvgALquXc
         xnTl0dusHQsw3IOWPpYXFY+A4wVPodxvQwjy6K/n7k8yPM/2EcWFxx3I8DUTPgU3/lP2
         t3sT+/oHCHVDm6DG34KQ4uPKt7AoxXQIanQv9DkKkR1MsYlPW3iLPriV9zpocRdL9AXP
         FyFg==
X-Forwarded-Encrypted: i=1; AJvYcCU+Zzf9DNvhuXyCr7Eq/O5/Ajg7Mt7owtxvvhThlUIb6iCJeJNmR4EXBnjtCwbw+5ALTPqMbb4E8rI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwwrJlON8Z6mwGmwUkNr9baWKw5GEUrcVM829npvVshSDp4CELb
	mumaR519vsX31fy5ft0Y3F+aHCooU16I+o3YWgsL2d4LG5vMUjnXaR19a4EhfeCeBQ==
X-Gm-Gg: ASbGncvE/kS10b4foIYo6kKYWFUUwMGNB39MrXRzg34SUU3uf/EwK3z+2T9OrQpCGf9
	0vq0gNV6SyXdtauPCASzXQcVwnHUauU6hyJa7tkRFNR1mcLG4viP16RbXHxuWLF4WEYfWuF7D9j
	ULKFIP5PJyreU13lvI2wbNJsUBnQR6aKm0O4OiDrmiyc/vzuoZxQBjGkM6CPcTw7HFGfwa4aUqW
	RKR145mbroZh6C7S1JNrIihds9PR4WV7FIhnF1HrX9AaGtFQsox5a85RevpLaKrzck9Dqn0Vilw
	ci4O2UPi4oslw6M4uMLtxKj2gZX7g93sdZyo49afhEU9GRXTUxvsu89Romo88+48yPOtPXwmNzs
	oDRSf9YGIJ8VNxcsHqmHvHQV0Tu34ghpxDopE
X-Google-Smtp-Source: AGHT+IHjXgUzV5D6bLMcskK4eG/BYyk3buMkeoqG7VwR7efRcL9C6K/iklOKRQfNn8T5jxXTr1IkLQ==
X-Received: by 2002:a5d:5850:0:b0:3a4:f50b:ca2 with SMTP id ffacd0b85a97d-3a51d8ef67cmr5374927f8f.8.1749124328809;
        Thu, 05 Jun 2025 04:52:08 -0700 (PDT)
Message-ID: <8e27de1a-0534-4c22-9c62-fe292779e2a3@suse.com>
Date: Thu, 5 Jun 2025 13:52:01 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 5/5] livepatch: Verify livepatch signatures
To: Ross Lagerwall 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20250602133639.2871212-1-ross.lagerwall@citrix.com>
 <20250602133639.2871212-6-ross.lagerwall@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: <20250602133639.2871212-6-ross.lagerwall@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 02.06.2025 15:36, Ross Lagerwall wrote:
> @@ -525,6 +526,106 @@ static int check_xen_buildid(const struct livepatch_elf *elf)
>      return 0;
>  }
>  
> +#ifdef CONFIG_PAYLOAD_VERIFY
> +static int check_rsa_sha256_signature(void *data, size_t datalen,
> +                                      void *sig, uint32_t siglen)
> +{
> +    struct sha2_256_state hash;
> +    MPI s;
> +    int rc;
> +
> +    s = mpi_read_raw_data(sig, siglen);

sig apparently being an input, can't the function parameter be pointer-to-const?

> +    if ( !s )
> +    {
> +        printk(XENLOG_ERR LIVEPATCH "Failed to mpi_read_raw_data\n");

Both there and ...

> +        return -ENOMEM;
> +    }
> +
> +    sha2_256_init(&hash);
> +    sha2_256_update(&hash, data, datalen);
> +
> +    rc = rsa_sha256_verify(&builtin_payload_key, &hash, s);
> +    if ( rc )
> +        printk(XENLOG_ERR LIVEPATCH "rsa_sha256_verify failed: %d\n", rc);

... here: Instead of mentioning function names, perhaps better to say in normal
word what failed. E.g. here "RSA/SHA256 verification failed".

> +    mpi_free(s);
> +
> +    return rc;
> +}
> +#endif
> +
> +static int check_signature(const struct livepatch_elf *elf, void *raw,

"raw" is an input only, too, isn't it? As such it ought to be const void *.

> +                           size_t size)
> +{
> +#ifdef CONFIG_PAYLOAD_VERIFY
> +#define MAX_SIG_NOTE_SIZE 1024
> +    static const char notename[] = "Xen";
> +    void *sig;
> +    livepatch_elf_note note;
> +    int rc;
> +
> +    rc = livepatch_elf_note_by_names(elf, ELF_XEN_SIGNATURE, notename, -1,
> +                                     ¬e);
> +    if ( rc )
> +    {
> +        dprintk(XENLOG_DEBUG, LIVEPATCH "%s: Signature not present\n",
> +                elf->name);
> +        return rc;
> +    }
> +
> +    /* We expect only one signature, find a second is an error! */
> +    rc = livepatch_elf_next_note_by_name(notename, -1, ¬e);

I can see why finding another signature of the same type might be a problem,
but one of a different type should be fine (i.e. unambiguous), I suppose.
Irrespective I find it slightly odd that you pass in a pointer to the same
local variable. The function, after all, is free to alter that variable
ahead of encountering the next matching note.

> +    if ( rc != -ENOENT )
> +    {
> +        if ( rc )
> +        {
> +            printk(XENLOG_ERR LIVEPATCH
> +                   "Error while checking for notes! err = %d\n", rc);
> +            return rc;
> +        }
> +        else
> +        {
> +            printk(XENLOG_ERR LIVEPATCH
> +                   "Error, found second signature note! There can be only one!\n");
> +            return -EINVAL;
> +        }
> +    }
> +
> +    if ( SIGNATURE_VERSION(note.type) != LIVEPATCH_SIGNATURE_VERSION ||
> +         SIGNATURE_ALGORITHM(note.type) != SIGNATURE_ALGORITHM_RSA ||
> +         SIGNATURE_HASH(note.type) != SIGNATURE_HASH_SHA256 )
> +    {
> +        printk(XENLOG_ERR LIVEPATCH
> +               "Unsupported signature type: v:%u, a:%u, h:%u\n",
> +               SIGNATURE_VERSION(note.type), SIGNATURE_ALGORITHM(note.type),
> +               SIGNATURE_HASH(note.type));
> +        return -EINVAL;
> +    }
> +
> +    if ( note.size == 0 || note.size >= MAX_SIG_NOTE_SIZE )
> +    {
> +        printk(XENLOG_ERR LIVEPATCH "Invalid signature note size: %u\n",
> +               note.size);
> +        return -EINVAL;
> +    }
> +
> +    sig = xmalloc_bytes(note.size);

In principle new code is supposed to be using functions from the xvmalloc()
family. (That family deliberately does not include xvmalloc_bytes(). I think
you mean xmalloc_array() here anyway.)

> @@ -1162,6 +1263,8 @@ static int load_payload_data(struct payload *payload, void *raw, size_t len)
>      if ( rc )
>         goto out;
>  
> +    check_signature(&elf, raw, len);

You entirely ignore the return value? (I was first wondering why the stub variant
of the function would return -EINVAL rather than 0.)

> --- a/xen/common/livepatch_elf.c
> +++ b/xen/common/livepatch_elf.c
> @@ -23,6 +23,61 @@ livepatch_elf_sec_by_name(const struct livepatch_elf *elf,
>      return NULL;
>  }
>  
> +int livepatch_elf_note_by_names(const struct livepatch_elf *elf,
> +                                const char *sec_name, const char *note_name,

So the plural in the function name is because it's both a section and a note
name, whereas ...

> +                                const unsigned int type,
> +                                livepatch_elf_note *note)
> +{
> +     const struct livepatch_elf_sec *sec = livepatch_elf_sec_by_name(elf,
> +                                                                     sec_name);
> +     if ( !sec )
> +           return -ENOENT;

(Nit: Too deep indentation.)

> +     note->end = sec->addr + sec->sec->sh_size;
> +     note->next = sec->addr;
> +
> +     return livepatch_elf_next_note_by_name(note_name, type, note);
> +}
> +
> +int livepatch_elf_next_note_by_name(const char *note_name,
> +                                    const unsigned int type,
> +                                    livepatch_elf_note *note)

... here you only look for further instances in the previously found section.
What if there's a 2nd section of the given name?

livepatch_elf_sec_by_name() also doesn't look to be making sure the section is
of the correct type.

Why is it necessary o pass in the note name again? A typical "find next" would
find the same kind as the "find first" did. Whereas here by passing in a
different name one can achieve "interesting" results. (Getting this correct
may not be necessary, but a comment would then want putting ahead of the
function.)

> +{
> +     const Elf_Note *pkd_note = note->next;
> +     size_t notenamelen = strlen(note_name) + 1;
> +     size_t note_hd_size;
> +     size_t note_size;
> +     size_t remaining;
> +
> +     while ( (void *)pkd_note < note->end )

Misra objects to the casting away of type qualifiers (and I do, too). More such
further down (and at least one instance also further up).

> +     {
> +

Nit: Stray blank line. Perhaps you really meant to move some of the variable
declarations here?

> +         remaining = note->end - (void *)pkd_note;
> +         if ( remaining < sizeof(livepatch_elf_note) )
> +             return -EINVAL;
> +
> +         note_hd_size = sizeof(Elf_Note) + ((pkd_note->namesz + 3) & ~0x3);
> +         note_size = note_hd_size + ((pkd_note->descsz + 3) & ~0x3);

What use are the 0x prefixes here (and then only on 2 of the three instances)?

> +         if ( remaining < note_size )
> +             return -EINVAL;
> +
> +         if ( notenamelen == pkd_note->namesz &&
> +              !memcmp(note_name, (const void *) pkd_note + sizeof(Elf_Note),

Nit: Stray blank between cast and cast value.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 12:02:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 12:02:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006729.1385951 (Exim 4.92)
	(envelope-from )
	id 1uN9Ig-0004MH-TW; Thu, 05 Jun 2025 12:02:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006729.1385951; Thu, 05 Jun 2025 12:02:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uN9Ig-0004MA-PZ; Thu, 05 Jun 2025 12:02:26 +0000
Received: by outflank-mailman (input) for mailman id 1006729;
 Thu, 05 Jun 2025 12:02: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 1uN9If-0004M3-BK
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 12:02:25 +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 f08ee2cb-4204-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 14:02:23 +0200 (CEST)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-ad56829fabdso139936266b.1
 for ; Thu, 05 Jun 2025 05:02:23 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ada5d82becbsm1257481566b.39.2025.06.05.05.02.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 05:02:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f08ee2cb-4204-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749124943; x=1749729743; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=SQV8GbkNSTmuawmHHmwq6Mz/OtVanuxGcNVmOTgjei8=;
        b=SVgoQGAAR42jK8xhjkqz2LgNvrFmO5lOOqj8Pri4X1y9bheTrhEf3Uutz11obui+x4
         9bA5bTsN2RDoGyla1et0iAgg+JbCu1Mf7YG33RiPKR3n8/EolUQiYabCrGLkrYuy0Uz2
         us6RX9Kl6bCWEjTDkPx+4Wu7KRp219Ag2UP+KaF9RljSZ8xARf01J4r3iH+PkduoXzwr
         2+Ca1DWQA+RVpSDjrPERDstQlB23gyfS3q2yGop20TTjjm6LTsf4LLYfUyWUY5vTmSWJ
         JM5IQKgVUumljk554i4a5kEOYoE0dEelWjGktGxCwTQ5JlScBmQRs5eGp8ede36JTWU8
         ahxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749124943; x=1749729743;
        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=SQV8GbkNSTmuawmHHmwq6Mz/OtVanuxGcNVmOTgjei8=;
        b=fEAvJvJXouxVieFmfZDYHUv/CdkmgSDuZsE8K+PTJ2sCCTSiVWkhWu6qIf3bQp1ja+
         hWW5r8zWuTKntVkUl7s/OeCAJ77aDyV6tl6sYd8Nly3Ms+RmQKiDkWxnTL9cOX+BzZKC
         8a9cRX6lqjNtvlXwobysJHXcE9aQ3A1tbW0lLa4g1/WhyCNLgD5NCWf9uEaQb3mFsXbg
         4fVC6FgG6wm/Y5yzGpwE8s+YY/BR+L2GKZw1JGMwM1/wv4T8jUJPmtPs2caM3DlReLVU
         +ulHKerWpw96tabqd4uAkiXXW8RXYbvaoVxcokHdivCbldNtPddmamQhqyuT2+d00Su9
         BSug==
X-Forwarded-Encrypted: i=1; AJvYcCUngLMXXPD7Ffes/uyBeEm/k+FeBAgS7YQv+R3iIFP9BXU6uqPknlea96SNLJ476VYbD6rwhahZl8Y=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy4opGdG8JQgBSckxfOSUwdKKKYCUemhJhIHsZ0Ha1lyZK+Ug1m
	rQwmyU5fRY6hrFSYBzv93bHtATEm2rN0giw6ZMN5/i0sl4RKxuxU5U5f5XFdtZ4Vcg==
X-Gm-Gg: ASbGncsFs5Cdkfd9cu3nrhoENW1BoENSujILl11ukBUxZSl7x6rqVR953kNoV0iszOH
	l0Oo5ic/1PkQHmyrVNg8X/uh4ANKhlfHj1zmBww7jlcphejvlCByXuOvHhjfwW8Jg30Ew31XKUM
	x2GNAAcMHW+WtEj0iQ2fvlK1mAnEfbyjYfEFuZKPxdR8rqtsR1slijwv3UfEY8evkaUwdl2M1Kf
	PGQ9Cczq3BH7Addspvy5m8Gz53KhWiBHXX2xQLZ54aTyCGw+8XkogMI8aytRASbBlL4cm0zq768
	VPcxNzPoULoumqq8YAhvZbaabijdEGiYp4lDi53rESff7n7c/rHa2lJVejp/IWH0dul+3WlP1rX
	4F6xMRx5JepVRP+ZGbBn1EItYDGsQgvxva+34GEZ5TF1f5AY=
X-Google-Smtp-Source: AGHT+IESPNP0Bz4oFj6jHnrxYw+Ps3evLuAI/M+SsVvhZp0u8niGoorfsIJv8WvyQ5mi1qI4y1n/Xw==
X-Received: by 2002:a17:907:7b8e:b0:ad8:93a3:29b0 with SMTP id a640c23a62f3a-addf8f79a1dmr589093466b.45.1749124942549;
        Thu, 05 Jun 2025 05:02:22 -0700 (PDT)
Message-ID: <0a314400-126a-4c2a-b36c-dda61bb0b751@suse.com>
Date: Thu, 5 Jun 2025 14:02:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/3] x86/EFI: Fix detection of buildid
To: Andrew Cooper 
Cc: Ross Lagerwall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 "Daniel P . Smith" ,
 Xen-devel 
References: <20250605111638.2869914-1-andrew.cooper3@citrix.com>
 <20250605111638.2869914-2-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20250605111638.2869914-2-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 05.06.2025 13:16, Andrew Cooper wrote:
> The format of the buildid is a property of the binary, not a property of how
> it was loaded.  This fixes buildid recognition when starting xen.efi from it's
> MB2 entrypoint.
> 
> Suggested-by: Ross Lagerwall 
> Signed-off-by: Andrew Cooper 

I'll pick this up without a Fixes: tag, but I think it ought to have one. (I
didn't check whether MB2 or build-id support came later, hence introducing the
issue.)

> --- a/xen/common/version.c
> +++ b/xen/common/version.c
> @@ -203,8 +203,11 @@ void __init xen_build_init(void)
>      rc = xen_build_id_check(n, sz, &build_id_p, &build_id_len);
>  
>  #ifdef CONFIG_X86
> -    /* Alternatively we may have a CodeView record from an EFI build. */
> -    if ( rc && efi_enabled(EFI_LOADER) )
> +    /*
> +     * xen.efi built with a new enough toolchain will have a CodeView record,
> +     * not an ELF note.
> +     */
> +    if ( rc )

Instead of dropping the efi_enabled(), I think you want to replace EFI_LOADER
by EFI_BOOT.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 12:03:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 12:03:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006735.1385960 (Exim 4.92)
	(envelope-from )
	id 1uN9JR-0004oe-3s; Thu, 05 Jun 2025 12:03:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006735.1385960; Thu, 05 Jun 2025 12:03: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 1uN9JR-0004oX-1H; Thu, 05 Jun 2025 12:03:13 +0000
Received: by outflank-mailman (input) for mailman id 1006735;
 Thu, 05 Jun 2025 12:03: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 1uN9JP-0004M3-On
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 12:03:11 +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 0c8dae29-4205-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 14:03:10 +0200 (CEST)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-604bff84741so1681952a12.2
 for ; Thu, 05 Jun 2025 05:03:10 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-606e6b4d365sm2450752a12.68.2025.06.05.05.03.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 05:03:09 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0c8dae29-4205-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749124990; x=1749729790; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=yuyWPFhR9vouuWTwJYDVNkhB2rheA0q3TFazmwdccBw=;
        b=fwdQayDWr/ahi6T2hyXaWyo9T3Vb0rfwyzVmE/zcSwe47tFCgOfCrgG0i1EajRwBJf
         3jbfpzd8BX6cuGgtUybXKTtPUN0aHViGGZQ0t54qm7A32jyoesj1UgWqHcOOnpb/pMmX
         AOcoLcGnYhUUsiuLbdDCseb+SSSYYQxdL0vXWpYAxNhK6iZMDVFQ+WRDJgd6TL3Mh7kZ
         3Q6OqGgdmxeLJHs60tSDM1NNs6CHPCjZlhGY+bfWKYuFAEQUiIO5WK4H2ZkAFa/ZdhKj
         cAb77q8j3oShr2HwwXLSfga8tD9gky9//h/p3dhsAnAkDLLFQEWNE96PP4bu7q1ZJKAU
         RsiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749124990; x=1749729790;
        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=yuyWPFhR9vouuWTwJYDVNkhB2rheA0q3TFazmwdccBw=;
        b=BCM6/vR4MVD2tjuMydQniQdljK0a+tF5mQTip2b1rpS29U9QpfEOBoXqjYVUdG0Ua+
         2tFFlMdwcGP/anHe4gfn1x8XcybARXrT4mwMPbKwbklnGRmhwY/OwmN1Cot6kKD+8CCj
         pYzOPJJ/T3RYyuaoLqKjHfTamzE3J0FHvQZUulMv46c61eB2pKww6p53hKzykbxBPilw
         52QNUG5UX+smqwXFRzCFlYb0LsnOBIgGbzOPe+DNRRKPFfqF5jZtnqF3Wy1eYS4qu/p8
         GWFDNE4bzvAr2xvv9FJMCy+voICBamdjh613FUuvQJyMM/MFk2K7t1VMPF4oAZOPZZ8O
         tbMQ==
X-Forwarded-Encrypted: i=1; AJvYcCWamAkkV7zNreRZgRrLHIJQ2k3r/2JvALtvzX/XGMdZ/gmUrPMb++1dIDIZwiIGG1K+59eiNXeEU0U=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw0Qc9RwZDrDIBvHquyUqDW40QMvfX3wAfYmiVKpJ9W75Yct/eZ
	Y+4RxaE4EFbxT1E3Nw00Wp7Z5GOP1LIGucOKSjUzOFrzHHiQ1FaY/86d3ro5q/a0Lw==
X-Gm-Gg: ASbGncskoMjFAckVXltUzcE1tjwZ7upQXLUkiEXeEm67shElRBum5WXE+HmvjabFnJ6
	CWSo7fsBGTxGQGH+bWVM0PX6HQsIvBtoIWaC7lmgn0g03mwTup345a0GgH29M0YnHhp3FgcAuVb
	5H1OqkgQn+p37+pcBTSIkfWdC3yzy6gBAaKzX4CGHStF0UrdiS7MYWEWryPo+NpZW/qK/xZVrHe
	w1J9U/m/HNEBaNMm9I6wcT8eUMd/FzlsGEa+jrjFFfHtDG1p1YwIk3VBMQgmibdQNxD63WOqJp9
	2h2UDznNU2yOl/aH94f+eGe9H9a4Nth8VklVnU31x5SC2Aw1kTIGVOFisvhEuaTHg31wGKym0oX
	lzioehkBIdD5jfwNWpSIRqj8VXsQ6Vb2B5PeW
X-Google-Smtp-Source: AGHT+IHyzuqboyAyutxQog/QcHVAEq0fcm+SpE7hGTvDmL5lURpDEQZtRj4p2srROhEZ+ZLxiKrwFw==
X-Received: by 2002:a05:6402:510a:b0:602:120c:f8d8 with SMTP id 4fb4d7f45d1cf-606ea179fb9mr6389650a12.18.1749124989574;
        Thu, 05 Jun 2025 05:03:09 -0700 (PDT)
Message-ID: 
Date: Thu, 5 Jun 2025 14:03:08 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/3] x86/EFI: Explain buildid.ihex
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Ross Lagerwall ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 "Daniel P . Smith" ,
 Xen-devel 
References: <20250605111638.2869914-1-andrew.cooper3@citrix.com>
 <20250605111638.2869914-3-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20250605111638.2869914-3-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 05.06.2025 13:16, Andrew Cooper wrote:
> This is an awful lot of magic to only be explained in a commit message.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 12:05:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 12:05:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006741.1385970 (Exim 4.92)
	(envelope-from )
	id 1uN9Ld-0005PW-FK; Thu, 05 Jun 2025 12:05:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006741.1385970; Thu, 05 Jun 2025 12: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 1uN9Ld-0005PP-Cf; Thu, 05 Jun 2025 12:05:29 +0000
Received: by outflank-mailman (input) for mailman id 1006741;
 Thu, 05 Jun 2025 12: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 1uN9Lc-0005PJ-Up
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 12:05:28 +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 5e1453f9-4205-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 14:05:27 +0200 (CEST)
Received: by mail-ed1-x52d.google.com with SMTP id
 4fb4d7f45d1cf-6020ff8d54bso1587266a12.2
 for ; Thu, 05 Jun 2025 05:05:27 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-60613d1d2bbsm6095670a12.29.2025.06.05.05.05.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 05:05:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5e1453f9-4205-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749125126; x=1749729926; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Bul8HJ0oDED2VX4ejxYmDzsT6CruB+NmT5eUiFzIuAs=;
        b=dacVdM8l/qMJFn55NHGY28IpjexZIBePL0iCBLoJg8M9GaoaklUVeylNV2gTdjY3Fe
         6r9BBLjiB0vOuswQBVEKZlapkjvYG2KYdcB/Pn2ZRNsdJu+52Bkd/xz7D8JuW04Qbp9L
         FHRdGKfNa1oGxHE89a2QrGqKw3fRLeTC2P/TGBxI9nCh3bMJ2UIXPusENEYC8AyF7RaZ
         /3bEa9mhted9n7lsxoRRHJlUOJ9F2RhKHn+mXNeYDWl9epdKJ9ZRSEy33DHAIEMV9bHJ
         N+n+GiGtgaNFAvd4j6VoUWx08XYqDKGk9VINJxPq+gYyXwregRrMSvybjECmiu7VeRLt
         oEHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749125126; x=1749729926;
        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=Bul8HJ0oDED2VX4ejxYmDzsT6CruB+NmT5eUiFzIuAs=;
        b=Jjj0NxLpHA686PMIDD9ZojrU28LTtHlLeaElSySBhKkB9DUhFiMi61nkTN8sC6cjAx
         YE6CQ8ux5PWflI2va+WC8av8uRf3TpTQcuD4B3IAsqEnffRH2WAXtqFB9Fv1kiANN8Fq
         GG94FbUYT7UBMfJGP/rhO/EKHpuoPms34QjuCGc/1xAHA8MSvniWYTpZIuj/oR3ydi0q
         nW6McxNygSI1GzmLZ5YcdnhrsnrxP1/0gPQsnCYpE6zUo9tGB9C1jzSup2kc8FM5Lkd5
         Iaxn13zLExgulqag/JL9vzB8zvAF5K09t9YgWL8Z77xwizRo3pB4S0yJOdAVTpZ2PhX5
         EOWg==
X-Forwarded-Encrypted: i=1; AJvYcCX2LzYJIhx2z4fuQQDE59RjZn2OJoO3NqrUWGSZylhrRb3GcTKr4XyZTi5p3W7OZ+8oQWLMV3rQVNo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwQ4pj7HTTsuSpa+dMLNiEdW4wqchpMjHCFE1geSOIRNBs+t4On
	7FPDbWDd9WqP6lfZiK8FL0IvRKWVdVZQkThgCAvxiRcg6onIZ7RRB1qw23UC2WhtaQ==
X-Gm-Gg: ASbGncsCl5NPT81hZa0QqvQSUIx4aB4y5+ly5oHsVsszuaUORyFeLEXu1lNUBvlA38L
	vkKHsDfeoUMneLIE32rWvmHylHOxRBLvrF5oUTfND/2jyj/FFwBxsmJp0lpL6L0K+p5yVVMJhV5
	PdFB+SEuMw7++DnAvRZ/awKPKIRvJboztg/Ed3bQQj3hgNBRIdtoHSupSFv/kHwGpEaw1GZLqC5
	mxqkiS65Nd//pQe8HWTv80Ep7Z4gzVSUIfbH/T8ALHFk/kC/7u3VrRdsNOaj6F6lQG6l3WKjztJ
	LFkfss5R2iQCCcd4ej20OVyMHygL6jaBE6kR4Ea3/BUgY7q8bWv5/RHIxK6kb66FaiVMpXHNUxZ
	VeeuH74pbH+8h3vwwq5SwelXE6Jeq5JptW98F
X-Google-Smtp-Source: AGHT+IFQlRW2lPERjsboE5pfQyLD0sXGO34bs74s8CYSRWk5NziSFFPBH03+43clS6mUX7c7nLxSpg==
X-Received: by 2002:aa7:c70f:0:b0:604:e6fb:e2e1 with SMTP id 4fb4d7f45d1cf-606ea39c57bmr5129222a12.33.1749125126487;
        Thu, 05 Jun 2025 05:05:26 -0700 (PDT)
Message-ID: <4819eff1-2e5b-40d4-825b-025f92d73d1f@suse.com>
Date: Thu, 5 Jun 2025 14:05:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/3] xen/EFI: Drop __ASSEMBLY__ ifdefary in efi.h
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Ross Lagerwall ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 "Daniel P . Smith" ,
 Xen-devel 
References: <20250605111638.2869914-1-andrew.cooper3@citrix.com>
 <20250605111638.2869914-4-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20250605111638.2869914-4-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 05.06.2025 13:16, Andrew Cooper wrote:
> There's already C outside of the ifdefary, proving that it's not included in
> any assembly files.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 12:15:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 12:15:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006754.1385979 (Exim 4.92)
	(envelope-from )
	id 1uN9Up-0007ME-AS; Thu, 05 Jun 2025 12:14:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006754.1385979; Thu, 05 Jun 2025 12:14: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 1uN9Up-0007M7-7n; Thu, 05 Jun 2025 12:14:59 +0000
Received: by outflank-mailman (input) for mailman id 1006754;
 Thu, 05 Jun 2025 12:14: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 1uN9Uo-0007M1-BZ
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 12:14:58 +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 b1570003-4206-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 14:14:56 +0200 (CEST)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-450cf2291bbso3225885e9.0
 for ; Thu, 05 Jun 2025 05:14:56 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-451fe39fc52sm5662715e9.27.2025.06.05.05.14.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 05:14:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b1570003-4206-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749125696; x=1749730496; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=om3EMqMlcpJqkWx5xkzXfnc6u0tMJraGCNmSjh6lhSg=;
        b=XbIBL90PSyQvt7n6LernzMtRqSCfHOGGvtGf67ioa7FpKb2NEuRcELuSeDCR37yoMc
         L9KLJ2uUqnL9UuXKHjgt62Us9NACB6Twxk6Kksv1+jIRcxUDUjgDi3uCETLlRaeFFozs
         3sXWbSAuwS+v41GM1OgCI5BdlVAnVMd8SREMI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749125696; x=1749730496;
        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=om3EMqMlcpJqkWx5xkzXfnc6u0tMJraGCNmSjh6lhSg=;
        b=fAT6jwCL2TpPuJXcqfoOCjqe1cjWgVYovlGHxwY1k178mLJPA1vKTEzRUp01bRfOz7
         k63UBIaxZWaLRJScKNkCMdP9LHGybL0ZD23WFqpJOSO4/jNRJU4qJbNQW5d0Vgtc3kDO
         9imBeuwrkIyuoLdewVyr5baAgUP+0tRoj75xMZsPRsYox2IboMS5XBKKTxz4ZVh4c5w9
         EJJr9wwS2hTussHOwkqNR/BBZ0VXmiVJNL8lqYc4sxPdh/Xx6vA/0+AEN17JsG9ZkF5u
         /kRXfArRcMJ3S55yoLDd6VwI+uigt0zNUy3B9AXK4NjW7Kpv1ZwMumCEp28LpLsNNmPT
         T/Cg==
X-Forwarded-Encrypted: i=1; AJvYcCVoXwyCYVYdN1uACGAg/zMdt10xJyD6VGa6001DF6t+i/efLy44uQuxGk0+ZXJM8+IP4bibhf+JEv8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyNjxC3OFNlYjzsJ99BkhgzQx3Pt9yWXq7mtAXrpKCwnYv2rJxR
	o6/zailOUbk1YoofLziBLCAceS7/9uHd+xp7OsB/MKqfDXlOU3DgWvvFzD8y12Gj+EM=
X-Gm-Gg: ASbGncsoCEozbgdLyN+KTvT6MutjZb5ZTtoJtu1sm8wlp4LSnBDZCwZfcIdySJaxGzX
	mVBb6vR2/G6HVuCDlBhdM++ie/hr1XU4J1ePU7huT/2Ah/DbO2n5X0woaqCXO8sXN2ADBrRwJoT
	4h+8EbLdmBte2pEn+HyWMN4Pn5lH6R2HiqdN6krpYc4inPVy3BPR2JHVpR2BOnWzY/d/89JypAS
	DVGRdnI1PRycruFYVPXhJ8JIgscdRk0BnXXGRhTDviTktROXKEWrd6lvx+kCsGyIbw8lN4WbxAB
	B8gu1jTZSaxLJWSRwvArCTk/P9dCu+qPogYGvi81Z6ii/0dE5o7qw4dhccxBGyxrvqFESU8qWOP
	YrYi9a3WSLImxzv2d
X-Google-Smtp-Source: AGHT+IHhImI84D3hQFxLRKzGorOj/xFqIcFe4DC1dvK0wnoFzzd/BIrXc+zm+2qau+zo+gV1Lun0oQ==
X-Received: by 2002:a05:600c:a08d:b0:450:6b55:cf91 with SMTP id 5b1f17b1804b1-451f0a64f69mr57888095e9.6.1749125695642;
        Thu, 05 Jun 2025 05:14:55 -0700 (PDT)
Message-ID: 
Date: Thu, 5 Jun 2025 13:14:54 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/3] x86/EFI: Fix detection of buildid
To: Jan Beulich 
Cc: Ross Lagerwall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 "Daniel P . Smith" ,
 Xen-devel 
References: <20250605111638.2869914-1-andrew.cooper3@citrix.com>
 <20250605111638.2869914-2-andrew.cooper3@citrix.com>
 <0a314400-126a-4c2a-b36c-dda61bb0b751@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: <0a314400-126a-4c2a-b36c-dda61bb0b751@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 05/06/2025 1:02 pm, Jan Beulich wrote:
> On 05.06.2025 13:16, Andrew Cooper wrote:
>> The format of the buildid is a property of the binary, not a property of how
>> it was loaded.  This fixes buildid recognition when starting xen.efi from it's
>> MB2 entrypoint.
>>
>> Suggested-by: Ross Lagerwall 
>> Signed-off-by: Andrew Cooper 
> I'll pick this up without a Fixes: tag, but I think it ought to have one. (I
> didn't check whether MB2 or build-id support came later, hence introducing the
> issue.)

MB2+EFI came long before any buildid support.  If you want a fixes tag,
it's eee5909e9d1

>
>> --- a/xen/common/version.c
>> +++ b/xen/common/version.c
>> @@ -203,8 +203,11 @@ void __init xen_build_init(void)
>>      rc = xen_build_id_check(n, sz, &build_id_p, &build_id_len);
>>  
>>  #ifdef CONFIG_X86
>> -    /* Alternatively we may have a CodeView record from an EFI build. */
>> -    if ( rc && efi_enabled(EFI_LOADER) )
>> +    /*
>> +     * xen.efi built with a new enough toolchain will have a CodeView record,
>> +     * not an ELF note.
>> +     */
>> +    if ( rc )
> Instead of dropping the efi_enabled(), I think you want to replace EFI_LOADER
> by EFI_BOOT.

No - that's differently buggy.  I suppose the commit message wasn't
clear enough?

We'd still have a CodeView record if we booted xen.efi using it's MB2
entrypoint without the EFI extensions.

This really is a property of being a PE32+ binary, and nothing to do
with EFI.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 12:20:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 12:20:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006763.1385989 (Exim 4.92)
	(envelope-from )
	id 1uN9aL-0000VZ-0E; Thu, 05 Jun 2025 12:20:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006763.1385989; Thu, 05 Jun 2025 12:20:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uN9aK-0000VS-Tu; Thu, 05 Jun 2025 12:20:40 +0000
Received: by outflank-mailman (input) for mailman id 1006763;
 Thu, 05 Jun 2025 12: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 1uN9aJ-0000U9-GC
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 12:20:39 +0000
Received: from fout-a2-smtp.messagingengine.com
 (fout-a2-smtp.messagingengine.com [103.168.172.145])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7b3bdadf-4207-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 14:20:35 +0200 (CEST)
Received: from phl-compute-06.internal (phl-compute-06.phl.internal
 [10.202.2.46])
 by mailfout.phl.internal (Postfix) with ESMTP id 478B413803A5;
 Thu,  5 Jun 2025 08:20:34 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-06.internal (MEProxy); Thu, 05 Jun 2025 08:20:34 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 5 Jun 2025 08:20:32 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7b3bdadf-4207-11f0-a300-13f23c93f187
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=1749126034;
	 x=1749212434; bh=6eWybKvdJd3EZ3bLh3sBKWehT7wSYUGIiOahcpXYyTM=; b=
	lOieqIxvazyxFpU+IHPvABAhEYkffuY4U7I7IM0rZnIw5sKj9mBLgZaxaSxVgGJB
	5OPBwvx6YIFpN36zq7ayTybj6vVWK6Nm9OXs57HgGWsWxMI+92zIr4Eunzn4sL8F
	0P0OgaN58DQpEwx5fqkdReZ1YFAkUwPCJtht8X1PJjQ8im86kipimweXtMWe49bq
	xYDe2thiwJnuVqvN6tjf8I7V6E79wsacTKOThBjgdJXMyJknwzXe0xaM1fuJ75uT
	fB985aIReY4SgYqJoAT1qiOMSAYZm1CbKu22Iw83WP253huXTP/v+u8uwBsSv66w
	bavuw7v9AS5JaM2YkWnaHg==
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=
	1749126034; x=1749212434; bh=6eWybKvdJd3EZ3bLh3sBKWehT7wSYUGIiOa
	hcpXYyTM=; b=KhNyc23yIBmVb3B7aT4g3o79FbE20YJ3XwBLLVZGMmBvLpTTXx2
	5Z1ZIGj+6DpQP3c2KO1IxPjAZwPIEO2i/k4Z8vmhAAr/SPKA/TFfhlrWfGnueCog
	AX2JB6npUxa1Grz2JR7sj6/0yqWKv+WH7htaNxttUA4c/AVyGcMOuk/1fZ4k/Zkq
	ktI1VNcGJQzqxSir/4tn1asla+DNxg/DgoZPF3U8TGQMX8fpiWvKdgi5bvXzVTw7
	5dDffuEZh4rj9Byl14xJTp3ta1Pu4MejOQdHhPGwqo/i2bTQg0iyPqUk084Nat0M
	ln8h0OcADfCxXxU2+BJSHDsB4hsqP2CaqpQ==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugdefiedvucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtjeen
    ucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomh
    grrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggft
    rfgrthhtvghrnhepgfduleetfeevhfefheeiteeliefhjefhleduveetteekveettddvge
    euteefjedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho
    mhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnh
    gspghrtghpthhtohepiedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepjhgsvghu
    lhhitghhsehsuhhsvgdrtghomhdprhgtphhtthhopegrnhgurhgvfidrtghoohhpvghrfe
    estghithhrihigrdgtohhmpdhrtghpthhtoheprhhoshhsrdhlrghgvghrfigrlhhlsegt
    ihhtrhhigidrtghomhdprhgtphhtthhopehrohhgvghrrdhprghusegtihhtrhhigidrtg
    homhdprhgtphhtthhopeguphhsmhhithhhsegrphgvrhhtuhhsshholhhuthhiohhnshdr
    tghomhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvg
    gtthdrohhrgh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Thu, 5 Jun 2025 14:20:30 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Jan Beulich 
Cc: Andrew Cooper ,
	Ross Lagerwall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	"Daniel P . Smith" ,
	Xen-devel 
Subject: Re: [PATCH 1/3] x86/EFI: Fix detection of buildid
Message-ID: 
References: <20250605111638.2869914-1-andrew.cooper3@citrix.com>
 <20250605111638.2869914-2-andrew.cooper3@citrix.com>
 <0a314400-126a-4c2a-b36c-dda61bb0b751@suse.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="EahQsmcuVhjgAOZm"
Content-Disposition: inline
In-Reply-To: <0a314400-126a-4c2a-b36c-dda61bb0b751@suse.com>


--EahQsmcuVhjgAOZm
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 5 Jun 2025 14:20:30 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Jan Beulich 
Cc: Andrew Cooper ,
	Ross Lagerwall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	"Daniel P . Smith" ,
	Xen-devel 
Subject: Re: [PATCH 1/3] x86/EFI: Fix detection of buildid

On Thu, Jun 05, 2025 at 02:02:21PM +0200, Jan Beulich wrote:
> On 05.06.2025 13:16, Andrew Cooper wrote:
> > The format of the buildid is a property of the binary, not a property o=
f how
> > it was loaded.  This fixes buildid recognition when starting xen.efi fr=
om it's
> > MB2 entrypoint.
> >=20
> > Suggested-by: Ross Lagerwall 
> > Signed-off-by: Andrew Cooper 
>=20
> I'll pick this up without a Fixes: tag, but I think it ought to have one.=
 (I
> didn't check whether MB2 or build-id support came later, hence introducin=
g the
> issue.)
>=20
> > --- a/xen/common/version.c
> > +++ b/xen/common/version.c
> > @@ -203,8 +203,11 @@ void __init xen_build_init(void)
> >      rc =3D xen_build_id_check(n, sz, &build_id_p, &build_id_len);
> > =20
> >  #ifdef CONFIG_X86
> > -    /* Alternatively we may have a CodeView record from an EFI build. =
*/
> > -    if ( rc && efi_enabled(EFI_LOADER) )
> > +    /*
> > +     * xen.efi built with a new enough toolchain will have a CodeView =
record,
> > +     * not an ELF note.
> > +     */
> > +    if ( rc )
>=20
> Instead of dropping the efi_enabled(), I think you want to replace EFI_LO=
ADER
> by EFI_BOOT.

Part of the motivation for MB2 entry point in xen.efi is using the
same binary in all boot modes, including legacy boot - in which case
none of EFI_* checks would be appropriate here. The grub series adds
support for loading PE binaries, and IIUC it isn't tied to booting via
EFI.

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

--EahQsmcuVhjgAOZm
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmhBi44ACgkQ24/THMrX
1yxgQAf/ccoj8J82ogFnLnZYjU5sH/KgGoBPZalxGcPvjUBZR6PL9FyhELXsQRKX
pOJ9B0IRQtmxAf8OTs0qlgvstzPd0ZGzG1+0CRIfUHBs4Tkn9gm966M05LVAdfEH
j8k/MBvC2QvjySMMTpaRWGa06R55J5HPiVIwrFL81gWIEQA3wsd5KGXQLrKMEW/N
5N87uyFLzhbY0358N/Aoqv9BKMBJfF//UBe9QfoIq3HfCzYdxybytuzne1VRELLV
irhnVEqFOElnelOnWsEF34vJhY6i9vBPHjtv/ji4Igv97N3nMAPZKnJ3vUKdN82A
gbNooecZ+zi1K6KNbK7zGCs4OZeOIQ==
=m/31
-----END PGP SIGNATURE-----

--EahQsmcuVhjgAOZm--


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 12:22:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 12:22:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006768.1386001 (Exim 4.92)
	(envelope-from )
	id 1uN9bm-0001Gh-Ar; Thu, 05 Jun 2025 12:22:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006768.1386001; Thu, 05 Jun 2025 12: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 1uN9bm-0001Ga-74; Thu, 05 Jun 2025 12:22:10 +0000
Received: by outflank-mailman (input) for mailman id 1006768;
 Thu, 05 Jun 2025 12:22: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 1uN9bk-0001GS-Ke
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 12:22:08 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id afddcf45-4207-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 14:22:03 +0200 (CEST)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 (Authenticated sender: nicola)
 by support.bugseng.com (Postfix) with ESMTPA id 6C4CD4EE7C3E;
 Thu,  5 Jun 2025 14:22:02 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: afddcf45-4207-11f0-b894-0df219b8e170
Authentication-Results: bugseng.com; arc=none smtp.remote-ip=162.55.131.47
ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1749126122;
	b=oDKKHZNs4FijA0w/G4dB7gG5TSQdDLheCysK8IauhThrNrbJcMO0z9/VHqxt5Jsk1jDb
	 cq9o5dUbSrinJi7RriNIIESQHWY9VyOTPRtSWk1i+xDBiXALwVqTdMVLoZsDePTtSb1Ym
	 7BTPbGH7fpXUglOUpdd7uUOx4XfdL8o/C2g8DEwR43GY9l9AJtZhuCAw4+VhqKc7NMKXw
	 cyQwPqILNsv+NZOKJc7Hm3qp4kzj5hphgJhRlngP866ZWwrW9qwEAI3LNVqaCLmBeYaD5
	 1/YAvJOe1Pvj9Qki0FUjkZQULcXr5rOtP464WrfI54IIfWz74cMfmoVUlfEy5f8mBNHku
	 U9s3glglAKyaQ/yp2fZ8QRQ3cHnwVH5JzhmRDsfDLMT7Dk4SVKC5MHZ8vimQV4719GuZR
	 Raa9UmaLvMBjKSkBzR1I2QV8aaXCupUlSFZU/mw6PcK4EDs+3cDL9FPbchKHmHsAWXZSw
	 PwhJQZru4yNqN2yviZpAwqinT0Mji9e4YGBy2iZTrtbhw6jnxjVsNe6R2PDHpLUr+GlbH
	 JDreaYesG+Het98ekI/heCDWNSul65Rq3DnpxtK+53FlEKDPuWFHhDbqz/vi9jkA2UMTo
	 wUrRJVP7sswz6UGJx7sb3zE5+JdaGKMADrnPV6fLah79RNoBzeZKXChgRih2ibU=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1749126122;
	h=DKIM-Signature:MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:
	 References:Message-ID:X-Sender:Organization:Content-Type:
	 Content-Transfer-Encoding;
	bh=arKwn2jSHhIDgNuO6bTEQtIBxWHLavABUBKp05SAwhk=;
	b=NbvXZYXMmN8cArXeO0HKK//wKkltklyRLq+xcW0Rmgp4/UxuHYTiSP4eQcSnw5O01p9Q
	 4X6WQmRnBIVy9jBkQ6jG1vzg1eM6pmCJMka6gRzJqo6rtpOwWjlxFQ6Pdo4wSbT97xUA0
	 AgSuvIfj1dKWSk8kMkBZzYoCrtj7IDsXpReLlWEO9oKchQCafbvr7cI4jfHRBf5Wwc9ww
	 jfOnmoGAYt2+8L/ELJxRtqXD60IEQ9CihNDBw1Mk6suNz7A9w3HLqT/8+9eRJOS3wummy
	 /fRhohEvxsvs3BNkY3rTtNRHQ5MaS0rOCWW7pv+N2V6i8mhMHG8v4if90H0U+qnmQfABt
	 WevhbN6s78ffdYsA8pAgq5eucAfRQ7iECHidiIsyptTJRar9UoZ6dGSgb0wh+0UHQJ+kv
	 0dg1DH76eMLxdwkGvtvBhQSes245NPUgNsH1CB+K+DauldpHgtc8W2FgKUkWelgqPZWby
	 Z6kOhSI0/gahT5RBveois9vXJ6h7CFlYR1zzmZ1MjGvhbQkWVtDu34/3gdaZgFX5soQWy
	 8g9HSJ5dQ3TLY3A3cCOZBDQgeahZTsa+FGSaEG+VmcaXkPDVzJ6NXOuLr9BhfiEJtK0yU
	 kiXoxoDAAF24Ru51QDs4pMSc+VaYeN4BCvlCO3ckAjhXP2pwYKEE8keAIjVW3gE=
ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1749126122; bh=fR7HLwODY4rYRCY1LX1io5tG6HZXy8KY/aHAsXAOPWw=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=w3DCAEKmTpJuDIDe+ipuvidZANa/DI16Spfo7AnYCvMUrbVLkq6w2QbJRKZlWCtss
	 uZfO3ThtUkmw07Mo23OWmaQjobxedrOU6r1JWjm8qOJEos6B2QZNmUWuowUxeoQKC+
	 sfgXa1Yl8eeL3UJ236V99Gk8281/3Xun9VRD66PZgQm5g1L+NyQTpY0N2roLaPsAzf
	 TbPOHSYagkafOkEvlThBTRfJEMsOJWhMNwpCYQdZMZOVzzSD0duTVi5lItHpxUhhcv
	 7cshZRtBGGKAXh67DML/u1eDS4dG6bDKAE/pII14eWs13bCZpK63ikmGlNF1C3kkyT
	 CW0ZJRq4fNwyA==
MIME-Version: 1.0
Date: Thu, 05 Jun 2025 14:22:02 +0200
From: Nicola Vetrini 
To: Jan Beulich 
Cc: victorm.lira@amd.com, Andrew Cooper , Anthony
 PERARD , Michal Orzel ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=83=C2=A9?=
 , Stefano Stabellini ,
 Federico Serafini , Bertrand Marquis
 , xen-devel@lists.xenproject.org
Subject: Re: [PATCH 1/3] xen/keyhandler: add missing noreturn attribute
In-Reply-To: <9e3a7b1b-7fbe-428b-888a-c18c95d8ee37@suse.com>
References: <20250604235034.1595881-1-victorm.lira@amd.com>
 <9e3a7b1b-7fbe-428b-888a-c18c95d8ee37@suse.com>
Message-ID: 
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 2025-06-05 09:17, Jan Beulich wrote:
> On 05.06.2025 01:49, victorm.lira@amd.com wrote:
>> From: Nicola Vetrini 
>> 
>> Function `reboot_machine' does not return, but lacks the `noreturn' 
>> attribute,
>> therefore causing a violation of MISRA C Rule 2.1: "A project shall 
>> not contain
>> unreachable code".
> 
> Is this (uniformly) true? Looking at ...
> 
>> --- a/xen/common/keyhandler.c
>> +++ b/xen/common/keyhandler.c
>> @@ -251,7 +251,7 @@ static void cf_check dump_hwdom_registers(unsigned 
>> char key)
>>      }
>>  }
>> 
>> -static void cf_check reboot_machine(unsigned char key, bool unused)
>> +static void noreturn cf_check reboot_machine(unsigned char key, bool 
>> unused)
>>  {
>>      printk("'%c' pressed -> rebooting machine\n", key);
>>      machine_restart(0);
> 
> ... generated code here, I can see that the compiler is perfectly able 
> to
> leverage the noreturn that machine_restart() has, resulting in no
> unreachable code to be generated. That is - neither in source nor in
> binary there is any unreachable code. Therefore I'm having a hard time
> seeing what the violation is here.
> 
> That said, I certainly don't mind the addition of the (seemingly) 
> missing
> attribute. Otoh I wonder whether an attribute the removal of which has 
> no
> effect wouldn't count as "dead code" or alike, violating some other 
> rule.
> 

Inlining does not play a role in this case. Here reboot_machine() is 
marked as a violation because machine_restart() is noreturn and there is 
no other path upon which reboot_machine() may return, hence any function 
calling reboot_machine() could have portions that are inadvertently 
unreachable (as in never executed due to divergence) by not having the 
annotation. That said, in such trivial cases compilers are typically 
able to derive the property automatically, but they are not obliged to 
and, more importantly, the behavior may even differ with the same 
compiler using different optimization levels.

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 12:26:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 12:26:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006774.1386009 (Exim 4.92)
	(envelope-from )
	id 1uN9g5-0001qZ-QP; Thu, 05 Jun 2025 12:26:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006774.1386009; Thu, 05 Jun 2025 12:26: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 1uN9g5-0001qS-Nd; Thu, 05 Jun 2025 12:26:37 +0000
Received: by outflank-mailman (input) for mailman id 1006774;
 Thu, 05 Jun 2025 12:26: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 1uN9g4-0001qM-30
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 12:26:36 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 515876db-4208-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 14:26:34 +0200 (CEST)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 (Authenticated sender: nicola)
 by support.bugseng.com (Postfix) with ESMTPA id 545594EE7C3E;
 Thu,  5 Jun 2025 14:26:33 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 515876db-4208-11f0-b894-0df219b8e170
Authentication-Results: bugseng.com; arc=none smtp.remote-ip=162.55.131.47
ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1749126393;
	b=FrhzzpKN32qEut3nuWE7oxDBe8gLbAeKtAq85VTDAZKA5Qk9FeuYUh5av/j0SkIT8c3p
	 zshRYP3Wr81z0LcUtwj5QuFkLk4OLfviGPUAglNg8bWzNMLl7vZfaWWz9e7XqlxZgJTld
	 5dnwiSTOldxZbewyroakzTjs/H+NPyYTUcg4OY0JRdwsIiBi9X6RW53L8X38zTZtRh8Bb
	 n0siBqYfrL2vNqVtfWHWYVUapktSzbi6Buw7z425yCdqatD+V23e9U9+oI7RJ/l4HeWXf
	 D+xPFL9KT6fKQQAJ5pckIZFbygRXiSD4QPET0Ea+tPBezCsfjo+3921o1+NU6ilVLJ5Tx
	 zksR+ot4AkWY1UgFgAGNJ0RFUJm3JAxMpWecna6D/qLJ83+FVufdBGaHsBMX6GRdoY3RG
	 9atdHEUpYLQrCTagCCrvVUTfSHNKCQtJxOMQ/cd03sE/Iw0LXW9m/3K2Ljh2+i9Bzx5GH
	 F0ewYJ6EWuN9D32J1OTUhf7YtXsVJ9vZd07QyJWZpKx4KORwota11cbbgTHuqXlcpZQHj
	 ImKGCwOhmieRDxrio77a7xBOAUHorfJfznG7lcmPQyu2C7LCMgA87AYti/XN3Gy6Ag85K
	 hhabuqteNIWBPbuVICIg/Ofy0zRDEhkbGBQRdUHXvvVIq8Ynrxc0AsRbwDJmFFc=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1749126393;
	h=DKIM-Signature:MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:
	 References:Message-ID:X-Sender:Organization:Content-Type:
	 Content-Transfer-Encoding;
	bh=w/F7qlGB2xLSbeYS44ytj6NIbBauJeItuiKWuUtsa20=;
	b=I9lJhWJpeBEXjOjeX1QJltfQgf1gde3AkUMjAnyxjdTVH5kCZftkYfXQ4BCFMk8LGik2
	 PlAVCtcGdPqicAJAAiJ5+ZKjHxv/4hSBwytsyOHMS//fudj3k3U59qdt6fYeVDkI6G0VY
	 y/OLNVx410sYsB0IbK8+f5g707DyGmPNx6wN7nTzpbMJXUVYVs7iytUvuDjAeEa6YUZzi
	 x1NevW6Q4WsuSlEwPq5EZlAry9ao6Q57fOcVTW6WJ4a7nMT8aMs1Hd2Ncb2QlfeBOAaFp
	 ywIc+dl0cj5bEvd5qOW7wIrmYIC5XBr/qb8Et37QbSYSmy01hiMsHwoV8a7aRMQO9boO+
	 2xBWxduayDFop9DmPGCToJsJK2jCUah2u+XFrK9Z4c9o8hGA0kAtQfUwo9ZFlEZjARzIl
	 W/AobolllF2gfuREAPOdToHXPhKXBJY3C3FPFA4Wr96xl19NfNzhjRYxTG546BqkglIHT
	 YNcRaHP1gzAAJAzRaBmtFkBOanKGsKxvW/XqLNc7OQSWR8CeJ9HS1IdU4FUTJs6nT/S+r
	 0DLPZfQr33HP4rS/W5N1BmBJSRAXGMOVU3cfem2tS/3soB22Mx+zouMYTxeuVbQ+GjJPE
	 YfPhhgF/z42ZLyuf1Iw+SYnh/yS/Qx6Iesg8/Z8MmcQ/wdsdN46fZX5FpRTQCY8=
ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1749126393; bh=4sWXTE8WUaRIv2oOiRoRZzruEp4Ivc/sm0LmysmmMaA=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=bOHL3V3BAY++9+B0bLtu0cpUGHuGjXw+cCPJbywgPkTgv88BRNN7segXZaNsDlmLm
	 6XMxKDeT+WO0nhpBMvowBd2n2w4shQPkp0QccqYOLhp5zHlJ0NOrKA7+IXWBW0WO1Q
	 GBK5N2HOkG4z1Bp51Qrcpkp5OHI2M8iiRyRH8qguK9hRj4l+V/+mN+kwbvc3v0BoZo
	 CKEPS82N3KDizYbxq594jQ3+tB8hlJZCbCNeC3zpx62rB1guVUeVmnLGCFC3HeKS6+
	 mBoXuhM+lrUvtcpFw2T2XTiP/ELxF0HjtegaNFHcianYd5SzDQXuMVl02DVvNLV+UH
	 F/kTxEz3onqYA==
MIME-Version: 1.0
Date: Thu, 05 Jun 2025 14:26:33 +0200
From: Nicola Vetrini 
To: Jan Beulich 
Cc: victorm.lira@amd.com, Andrew Cooper , Anthony
 PERARD , Michal Orzel ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=83=C2=A9?=
 , Stefano Stabellini ,
 Federico Serafini , Bertrand Marquis
 , xen-devel@lists.xenproject.org
Subject: Re: [PATCH 1/3] xen/keyhandler: add missing noreturn attribute
In-Reply-To: 
References: <20250604235034.1595881-1-victorm.lira@amd.com>
 <9e3a7b1b-7fbe-428b-888a-c18c95d8ee37@suse.com>
 
Message-ID: <3b24b1df1a0ce4a62b53067b09fe9a02@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 2025-06-05 14:22, Nicola Vetrini wrote:
> On 2025-06-05 09:17, Jan Beulich wrote:
>> On 05.06.2025 01:49, victorm.lira@amd.com wrote:
>>> From: Nicola Vetrini 
>>> 
>>> Function `reboot_machine' does not return, but lacks the `noreturn' 
>>> attribute,
>>> therefore causing a violation of MISRA C Rule 2.1: "A project shall 
>>> not contain
>>> unreachable code".
>> 
>> Is this (uniformly) true? Looking at ...
>> 
>>> --- a/xen/common/keyhandler.c
>>> +++ b/xen/common/keyhandler.c
>>> @@ -251,7 +251,7 @@ static void cf_check 
>>> dump_hwdom_registers(unsigned char key)
>>>      }
>>>  }
>>> 
>>> -static void cf_check reboot_machine(unsigned char key, bool unused)
>>> +static void noreturn cf_check reboot_machine(unsigned char key, bool 
>>> unused)
>>>  {
>>>      printk("'%c' pressed -> rebooting machine\n", key);
>>>      machine_restart(0);
>> 
>> ... generated code here, I can see that the compiler is perfectly able 
>> to
>> leverage the noreturn that machine_restart() has, resulting in no
>> unreachable code to be generated. That is - neither in source nor in
>> binary there is any unreachable code. Therefore I'm having a hard time
>> seeing what the violation is here.
>> 
>> That said, I certainly don't mind the addition of the (seemingly) 
>> missing
>> attribute. Otoh I wonder whether an attribute the removal of which has 
>> no
>> effect wouldn't count as "dead code" or alike, violating some other 
>> rule.
>> 
> 
> Inlining does not play a role in this case. Here reboot_machine() is 
> marked as a violation because machine_restart() is noreturn and there 
> is no other path upon which reboot_machine() may return, hence any 
> function calling reboot_machine() could have portions that are 
> inadvertently unreachable (as in never executed due to divergence) by 
> not having the annotation. That said, in such trivial cases compilers 
> are typically able to derive the property automatically, but they are 
> not obliged to and, more importantly, the behavior may even differ with 
> the same compiler using different optimization levels.

Just a note: in later revisions of MISRA C this has become a rule of its 
own [1], which helps reduce confusion, but up to MISRA C:2012 Amendment 
2 (currently used by Xen), this is part of Rule 2.1.

[1] Rule 17.11: "A function that never returns should be declared with a 
_Noreturn function specifier"

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 12:41:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 12:41:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006780.1386020 (Exim 4.92)
	(envelope-from )
	id 1uN9um-0004zT-42; Thu, 05 Jun 2025 12:41:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006780.1386020; Thu, 05 Jun 2025 12: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 1uN9um-0004zM-0u; Thu, 05 Jun 2025 12:41:48 +0000
Received: by outflank-mailman (input) for mailman id 1006780;
 Thu, 05 Jun 2025 12:40: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 1uN9th-0004jZ-7k
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 12:40: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 47152bbf-420a-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 14:40:35 +0200 (CEST)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-60179d8e65fso1687261a12.0
 for ; Thu, 05 Jun 2025 05:40:36 -0700 (PDT)
Received: from localhost.localdomain ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-606fe850afasm1998360a12.78.2025.06.05.05.40.34
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 05:40:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 47152bbf-420a-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1749127235; x=1749732035; 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=FfwRnI7lZEthL0WX9nNZFK4rYZZj7EvtDJVub3fMfCY=;
        b=lHC1IGxiv9tntU5H961oDa2pTkzZLMvAKP91MICLOSt3+hcYx5Rs2k/e881BlddVCs
         FODOYDhp9KgNF5yrNrfHgVZ12M4uPVwG074j6DhzbZafIxgbUPBixLvXqU6XGG+iDDk1
         81dUHm+nKmIJcvJIaQYzJ0eixgO50fu2nZi2Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749127235; x=1749732035;
        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=FfwRnI7lZEthL0WX9nNZFK4rYZZj7EvtDJVub3fMfCY=;
        b=q+CLxJ+GkVzoR+ii4OfDJcmcBV1hn8vj3nTzTRSFaPyOLPusieMdLNUgBUhV+whCnR
         5lzo0k/U7UPUxr5KUaKrYBoFZ6w0z0FmWHKDwmpLxNXQlZfr9erbEO1VNtDK7I4cD1py
         v0dfI4XzWyYA8sl2ITsOFkrP2Py6PKsrd0F/cSZ+NoUtuco6pspyLEkqzUAOKBgtXUEQ
         KV81xueAacs0gxkAyVaCSExFhf9rpAouCpwZu7G1auObjJThIT3Oh77T51d6EnNy5j/K
         uSqzuRRxUrseR60aI1QR5svOalshyRYgTMdYpzSur1Q/kJDPV0biL6RyOQ6V94aeZBW7
         TWTA==
X-Gm-Message-State: AOJu0Yw2+eWgK4wmYEVZBp2PPe4uBMLgy6Uf/TYiYSGldEqv0DNmWW0J
	plkW9dqKBXpJuuFGm5CEkOYz8zUV/v1wBFVg7+15OjH8FTCsosaPPq05ci37huCfnw5pfqxLpw7
	CSneCYdDy4Q==
X-Gm-Gg: ASbGncsUEV4p0Hy4eb8QUzT4gKFXdgt8OP0b5RO5vGlxJRQznsAuEjE0MPO9Ruypowf
	0BSUhVacph1FRnZwpP9199+TfcXa7e86Z7oURzkICGw8EACkK6o08PJgs3/aaFgJzxFzprpgDLP
	dhmoVdl/3nnCRDMjYuiMntG7VdAGxUVLqWyUD0r5OTq/8fwHtgA6/2J7dzBib+H9fKl+SCwZQkG
	/vxDkFJCRFYLg3gGBfvuycsFcosYanNJ7gURZllfDcyJ7tgemlF64SAS15PSmjWCpvZUCjc2HK3
	ZN1DQIFJh3pFOYsxUmztAci8sIkCeZXMost3vHZPqqfSW33W1FjiBthN9YGJ
X-Google-Smtp-Source: AGHT+IH5CPvL6XymXfSKxxMOlb1tRSk0In07BRDe0tAIPRV931bMPxrBz4N3x24xg0pobFR92HyMoQ==
X-Received: by 2002:a05:6402:33d0:b0:602:201:b46e with SMTP id 4fb4d7f45d1cf-606ea195f5dmr5012852a12.31.1749127235167;
        Thu, 05 Jun 2025 05:40:35 -0700 (PDT)
From: Gang Ji 
To: xen-devel@lists.xenproject.org
Cc: Gang Ji ,
	Anthony PERARD 
Subject: [PATCH] xenalyze: Add 2 missed VCPUOPs in vcpu_op_str
Date: Thu,  5 Jun 2025 20:36:36 +0800
Message-ID: <20250605123636.1444304-1-gang.ji@cloud.com>
X-Mailer: git-send-email 2.47.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The 2 missed ones are: register_runstate_phys_area and
register_vcpu_time_phys_area.

Signed-off-by: Gang Ji 
---
 tools/xentrace/xenalyze.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
index adc96dd7e4..1c13682aaa 100644
--- a/tools/xentrace/xenalyze.c
+++ b/tools/xentrace/xenalyze.c
@@ -6513,7 +6513,8 @@ static const char *vcpu_op_str[] = {
     "register_runstate_memory_area", "set_periodic_timer",
     "stop_periodic_timer", "set_singleshot_timer", "stop_singleshot_timer",
     "register_vcpu_info", "send_nmi", "get_physid",
-    "register_vcpu_time_memory_area",
+    "register_vcpu_time_memory_area", "register_runstate_phys_area",
+    "register_vcpu_time_phys_area",
 };
 
 static const char *sched_op_str[] = {
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 12:46:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 12:46:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006786.1386030 (Exim 4.92)
	(envelope-from )
	id 1uN9zC-0005Zs-K0; Thu, 05 Jun 2025 12:46:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006786.1386030; Thu, 05 Jun 2025 12:46:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uN9zC-0005Zl-HJ; Thu, 05 Jun 2025 12:46:22 +0000
Received: by outflank-mailman (input) for mailman id 1006786;
 Thu, 05 Jun 2025 12:46: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 1uN9zB-0005Zf-Ec
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 12:46:21 +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 14664d77-420b-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 14:46:20 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a528243636so520063f8f.3
 for ; Thu, 05 Jun 2025 05:46:20 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-451f9924a41sm23785105e9.40.2025.06.05.05.46.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 05:46:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 14664d77-420b-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749127580; x=1749732380; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=/8E13FMRdY/mBMDbjzwsHdMcmOj2DIxgi8uOFTnlUd4=;
        b=fqQgrSg+it5SR5/7jrgO6vjLrfD3J2kjN99oMya3u+ZZMWhHOJPMww397cI5KRkpOI
         9eVXNu+NOhhRrHEjJU5tOF1ALLG7lkncKEbWZJGGb7+Y5k5rIvJG0dAizPlWB3NqHDWD
         RmiDnYw7c/X4HCjcKIc+dOuecGwpx20jkVXlU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749127580; x=1749732380;
        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=/8E13FMRdY/mBMDbjzwsHdMcmOj2DIxgi8uOFTnlUd4=;
        b=p8AGQeZHNEmR1gYg8MmatH9vjWkfOpuaBwwW9+x6Tbz1fr3d0DvUI1ol5p9WklmC45
         696fqKNcvnwft8Qxr9WTDsBE63IL8GoKFy4qFdYtGA+EaWSvlsvkeDVuq8PVG6vVJ9KS
         CJvBAwwLYlddbwKVbO3JJ/QEZesOeSlRcY07Eh5PLTFZY+0VH3ZXpXUjq/L88B98fZmJ
         w1SA9r7+xy4vmewPgQkwZKHWhatjyJeT7Bs+J+/9c91vxoAfhkTzfJHW9u+Yb555y09p
         nU59cCakng7ShedzOkeXTcvvg5KZYZPphKHogKQbs1pneauRNDagmCMhsx9n9L78Sfaf
         r/6w==
X-Forwarded-Encrypted: i=1; AJvYcCUNdFdpW+NRUMJKQzBArM4RuBv2eEmiRzU7O2/LQLu2AdLa0ohWNwbfIxzGWbczsOi2rNyLKQHWHtg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzO1D6H032jnE+Sq4iYiSPo5AwM8kC+Oo79JFrp6ZszIiWtiZpy
	bwERw9UNXq9YbqywKo11WHuW7CQVTRhNqwYqARLD/aNRJhZZZv1iS5beMBWsDrWIPGI=
X-Gm-Gg: ASbGncv0w4jxXTv+tj0lLTm+BHTMhMV7SkQNC8t62NnXpFUtkSc81+CHMVjRexQ+oS2
	bNdb8PNFvTPLGD7iMpIsi8VDpq9pY5ARRBrDpY27z64rbSiLOyaOPmLsQd8HwdAkwJBI7pPlwX+
	I2YxWrDERs0UUqkqE5+ZPAJNlHYA24uvmlWbf8Sv2KpOb/ZbWvPy/d/EXl+KYihLlwHcyfP9jm8
	OsgalYq8oFr75BfzL3y8FhGvBB97xxMxMt4li3FM9KLIP/R9uFMM+dzkWLo0YJT+HdkrVg5Z38W
	5qXsc9vH8QU1XUmpyiY2aTt6tJ+KcbgFMFZc3IQAdfO11CGH+wfVQYF+I1ROA0CVhFrN0n1qnIK
	HTOoU4fg/rt5AfHF+5X+9euRXGOM=
X-Google-Smtp-Source: AGHT+IHnOgKC+CAkJmHmQ2Z8OCICro5ATzijs6v+pWi4OOZhHngK8VBa+oz1rWPoffGTtJpxrmoXKA==
X-Received: by 2002:adf:a348:0:b0:3a4:e318:1aa9 with SMTP id ffacd0b85a97d-3a51d98bf28mr4441746f8f.59.1749127579781;
        Thu, 05 Jun 2025 05:46:19 -0700 (PDT)
Message-ID: 
Date: Thu, 5 Jun 2025 13:46:18 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xenalyze: Add 2 missed VCPUOPs in vcpu_op_str
To: Gang Ji , xen-devel@lists.xenproject.org
Cc: Anthony PERARD 
References: <20250605123636.1444304-1-gang.ji@cloud.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: <20250605123636.1444304-1-gang.ji@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 05/06/2025 1:36 pm, Gang Ji wrote:
> The 2 missed ones are: register_runstate_phys_area and
> register_vcpu_time_phys_area.

Fixes: d5df44275e7a ("domain: introduce GADDR based runstate area registration alternative")
Fixes: 60e544a8c58f ("x86: introduce GADDR based secondary time area registration alternative")


> Signed-off-by: Gang Ji 

Reviewed-by: Andrew Cooper 

Sorry, I forgot to mention the Fixes tags.  We put them on bugfixes to
help figure out if/how far to backport the fix.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 12:50:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 12:50:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006795.1386039 (Exim 4.92)
	(envelope-from )
	id 1uNA3X-0007EN-8A; Thu, 05 Jun 2025 12:50:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006795.1386039; Thu, 05 Jun 2025 12:50:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNA3X-0007E5-5T; Thu, 05 Jun 2025 12:50:51 +0000
Received: by outflank-mailman (input) for mailman id 1006795;
 Thu, 05 Jun 2025 12:50: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 1uNA3W-0007Bf-3x
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 12:50:50 +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 b493d9cc-420b-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 14:50:49 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-451e2f0d9c2so7916255e9.1
 for ; Thu, 05 Jun 2025 05:50:49 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a4efe6cd15sm24849976f8f.39.2025.06.05.05.50.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 05:50:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b493d9cc-420b-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749127848; x=1749732648; 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=7oTjjGy5q2ugLjjyV9NtIRXcE4JeMaUhyWLYzqAiDRg=;
        b=DbrcPMebzyNWXJlcElhwgp4yoqyeJz13EsIiRSeZgB1JLHNNsY1uyoiHwvvHVh8qM/
         rJVIK7m9dmJV2N5/BWvvDt9aBBRPmogDleMFh92ZogVHYIhktyE45473QMWwlauyV/a9
         IdUJGUHqtwOdMHK8yU7Br5O8C9X9s6/73PqXQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749127848; x=1749732648;
        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=7oTjjGy5q2ugLjjyV9NtIRXcE4JeMaUhyWLYzqAiDRg=;
        b=EcDo4hUrLcivjvw7ydssGNGwoAf4gEGs7efpjd5vLndV9gQMqmX6w6qQc4GRn4GXVL
         LfcpFe0mgeguoBIZIsaQ/vda5SbmWuoWOlY1NAvxUhwQ4IemyPnTIhC9QW9lwq9r9mH2
         5n9IKT0bomKISlBDgh2OcfTM0UvM+Klz2TYlnz25rqUxtr3gidfDtGMOaow24lxvrcGW
         MROFBO8D4gB4heDdjg+/HCvzzGzxAAHGoziyiyE1CMByenfj3XD8wSS59JKgJ1Bj6nUI
         u1opOQ59Q4lJuNkT7SW3jXxp9VIc8TYhqfvkx4NFQN37qnY9oVfLheq7/hMBIPjUWnOy
         wjdA==
X-Gm-Message-State: AOJu0YxNCELOH3ItIFGkf2f0yMYV+LRqUaTfeHnzj/+oVBYw/Y1SHqgF
	hwGgUKqVX7bsOwnnXH/pgKP+0g6IXonprDlYL+J78hART4cknHukaAKEg5h9Ny4LG5g=
X-Gm-Gg: ASbGncsNjyIyORmpujEN0J1jT2wo19FoII9ypR5XLiYdgC29GeVdMqPwM/tVE/Ml2RU
	Jzbfl0SEfxvF6qhjYzyOiC3OZhWko0Hr1RW8oy6ewvvWV64pEECHJF8ahT6mNChiifV3XzpjDAm
	BDVo4QtfZoThmFckdcoSh04pAmioEMxHiWZp3hzP9Anl+98pQdjtiubwCxPZ0BV6QYXa/f8zOZl
	oANCv7oNMfFBMk/7Ew7x3PCZILQ+9eTFoPeQG5CdqCwrRG5SBCHwmhkfqrAVH9AeINPrgO98EeH
	HziVkNsCGCuwBjtFjd5sNY4ddMJUpEzyvwPl6bphxfG1IFyI8hVtV8+Da9a+/TrzJWjGeB7gFqy
	n0JvyksnEJ1o9uP9LzqYrj+RDGwAAQw==
X-Google-Smtp-Source: AGHT+IEgK1DMh4qVPESCe7WjipD04ghbwg2FsxBzuOS1nDy64DFs3qBQrkR8jDBCn6ANk+iL3NDd0A==
X-Received: by 2002:a05:600c:458a:b0:450:d3a1:95e2 with SMTP id 5b1f17b1804b1-451f8855f11mr29321965e9.9.1749127848405;
        Thu, 05 Jun 2025 05:50:48 -0700 (PDT)
Date: Thu, 5 Jun 2025 14:50:47 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jiqian Chen 
Cc: xen-devel@lists.xenproject.org, Huang Rui ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v5 04/10] vpci: Refactor REGISTER_VPCI_INIT
Message-ID: 
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
 <20250526094559.140423-5-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250526094559.140423-5-Jiqian.Chen@amd.com>

On Mon, May 26, 2025 at 05:45:53PM +0800, Jiqian Chen wrote:
> Refactor REGISTER_VPCI_INIT to contain more capability specific
> information, this is benefit for follow-on changes to hide capability

"this will benefit further follow-on..."

I think it's clearer.

> when initialization fails.
> 
> What's more, change the definition of init_header() since it is
> not a capability and it is needed for all devices' PCI config space.
> 
> After refactor, the "priority" of initializing capabilities isn't
> needed anymore, so delete its related codes.
> 
> Note:
> Call vpci_make_msix_hole() in the end of init_msix() since the change
> of sequence of init_header() and init_msix().
> 
> The cleanup hook is also added in this change, even if it's still
> unused. Further changes will make use of it.
> 
> Signed-off-by: Jiqian Chen 
> ---
> cc: "Roger Pau Monné" 
> cc: Andrew Cooper 
> cc: Anthony PERARD 
> cc: Michal Orzel 
> cc: Jan Beulich 
> cc: Julien Grall 
> cc: Stefano Stabellini 
> ---
> v4->v5 changes:
> * Rename REGISTER_VPCI_CAP to REGISTER_PCI_CAPABILITY, rename REGISTER_VPCI_LEGACY_CAP to REGISTER_VPCI_CAP, rename REGISTER_VPCI_EXTENDED_CAP to REGISTER_VPCI_EXTCAP.
> * Change cleanup hook of vpci_capability_t from void to int.
> 
> v3->v4 changes
> * Delete the useless trailing dot of section ".data.vpci".
> * Add description about priority since this patch removes the initializing priority of capabilities and priority is not needed anymore.
> * Change the hook name from fini to cleanup.
> * Change the name x and y to be finit and fclean.
> * Remove the unnecessary check "!capability->init"
> 
> v2->v3 changes:
> * This is separated from patch "vpci: Hide capability when it fails to initialize" of v2.
> * Delete __maybe_unused attribute of "out" in function vpci_assign_devic().
> * Rename REGISTER_VPCI_EXTEND_CAP to REGISTER_VPCI_EXTENDED_CAP.
> 
> v1->v2 changes:
> * Removed the "priorities" of initializing capabilities since it isn't used anymore.
> * Added new function vpci_capability_mask() and vpci_ext_capability_mask() to remove failed capability from list.
> * Called vpci_make_msix_hole() in the end of init_msix().
> 
> Best regards,
> Jiqian Chen.
> ---
>  xen/drivers/vpci/header.c |  3 +--
>  xen/drivers/vpci/msi.c    |  2 +-
>  xen/drivers/vpci/msix.c   |  8 +++++--
>  xen/drivers/vpci/rebar.c  |  2 +-
>  xen/drivers/vpci/vpci.c   | 46 ++++++++++++++++++++++++++++++---------
>  xen/include/xen/vpci.h    | 30 ++++++++++++++++++-------
>  xen/include/xen/xen.lds.h |  2 +-
>  7 files changed, 68 insertions(+), 25 deletions(-)
> 
> diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
> index 4b2f761c9c24..9fa1cda23151 100644
> --- a/xen/drivers/vpci/header.c
> +++ b/xen/drivers/vpci/header.c
> @@ -872,7 +872,7 @@ static int vpci_init_ext_capability_list(struct pci_dev *pdev)
>      return 0;
>  }
>  
> -static int cf_check init_header(struct pci_dev *pdev)
> +int vpci_init_header(struct pci_dev *pdev)
>  {
>      uint16_t cmd;
>      uint64_t addr, size;
> @@ -1068,7 +1068,6 @@ static int cf_check init_header(struct pci_dev *pdev)
>      pci_conf_write16(pdev->sbdf, PCI_COMMAND, cmd);
>      return rc;
>  }
> -REGISTER_VPCI_INIT(init_header, VPCI_PRIORITY_MIDDLE);
>  
>  /*
>   * Local variables:
> diff --git a/xen/drivers/vpci/msi.c b/xen/drivers/vpci/msi.c
> index 66e5a8a116be..2d45c7867de7 100644
> --- a/xen/drivers/vpci/msi.c
> +++ b/xen/drivers/vpci/msi.c
> @@ -270,7 +270,7 @@ static int cf_check init_msi(struct pci_dev *pdev)
>  
>      return 0;
>  }
> -REGISTER_VPCI_INIT(init_msi, VPCI_PRIORITY_LOW);
> +REGISTER_VPCI_CAP(PCI_CAP_ID_MSI, init_msi, NULL);
>  
>  void vpci_dump_msi(void)
>  {
> diff --git a/xen/drivers/vpci/msix.c b/xen/drivers/vpci/msix.c
> index 74211301ba10..674815ead025 100644
> --- a/xen/drivers/vpci/msix.c
> +++ b/xen/drivers/vpci/msix.c
> @@ -703,9 +703,13 @@ static int cf_check init_msix(struct pci_dev *pdev)
>      pdev->vpci->msix = msix;
>      list_add(&msix->next, &d->arch.hvm.msix_tables);
>  
> -    return 0;
> +    spin_lock(&pdev->vpci->lock);
> +    rc = vpci_make_msix_hole(pdev);
> +    spin_unlock(&pdev->vpci->lock);
> +
> +    return rc;
>  }
> -REGISTER_VPCI_INIT(init_msix, VPCI_PRIORITY_HIGH);
> +REGISTER_VPCI_CAP(PCI_CAP_ID_MSIX, init_msix, NULL);
>  
>  /*
>   * Local variables:
> diff --git a/xen/drivers/vpci/rebar.c b/xen/drivers/vpci/rebar.c
> index 793937449af7..9cafd80ca2c9 100644
> --- a/xen/drivers/vpci/rebar.c
> +++ b/xen/drivers/vpci/rebar.c
> @@ -118,7 +118,7 @@ static int cf_check init_rebar(struct pci_dev *pdev)
>  
>      return 0;
>  }
> -REGISTER_VPCI_INIT(init_rebar, VPCI_PRIORITY_LOW);
> +REGISTER_VPCI_EXTCAP(PCI_EXT_CAP_ID_REBAR, init_rebar, NULL);
>  
>  /*
>   * Local variables:
> diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
> index 8474c0e3b995..2861557e06d2 100644
> --- a/xen/drivers/vpci/vpci.c
> +++ b/xen/drivers/vpci/vpci.c
> @@ -36,8 +36,8 @@ struct vpci_register {
>  };
>  
>  #ifdef __XEN__
> -extern vpci_register_init_t *const __start_vpci_array[];
> -extern vpci_register_init_t *const __end_vpci_array[];
> +extern vpci_capability_t *const __start_vpci_array[];
> +extern vpci_capability_t *const __end_vpci_array[];
>  #define NUM_VPCI_INIT (__end_vpci_array - __start_vpci_array)
>  
>  #ifdef CONFIG_HAS_VPCI_GUEST_SUPPORT
> @@ -83,6 +83,34 @@ static int assign_virtual_sbdf(struct pci_dev *pdev)
>  
>  #endif /* CONFIG_HAS_VPCI_GUEST_SUPPORT */
>  
> +static int vpci_init_capabilities(struct pci_dev *pdev)
> +{
> +    for ( unsigned int i = 0; i < NUM_VPCI_INIT; i++ )
> +    {
> +        const vpci_capability_t *capability = __start_vpci_array[i];
> +        const unsigned int cap = capability->id;
> +        const bool is_ext = capability->is_ext;
> +        unsigned int pos;
> +        int rc;
> +
> +        if ( !is_ext )
> +            pos = pci_find_cap_offset(pdev->sbdf, cap);
> +        else if ( !is_hardware_domain(pdev->domain) )
> +            continue;
> +        else
> +            pos = pci_find_ext_capability(pdev->sbdf, cap);

Nit: it's more compact if you do something like:

        unsigned int pos = 0;

        if ( !is_ext )
            pos = pci_find_cap_offset(pdev->sbdf, cap);
        else if ( is_hardware_domain(pdev->domain) )
            pos = pci_find_ext_capability(pdev->sbdf, cap);

        if ( !pos )
            continue;

> +
> +        if ( !pos )
> +            continue;
> +
> +        rc = capability->init(pdev);
> +        if ( rc )
> +            return rc;
> +    }
> +
> +    return 0;
> +}
> +
>  void vpci_deassign_device(struct pci_dev *pdev)
>  {
>      unsigned int i;
> @@ -128,7 +156,6 @@ void vpci_deassign_device(struct pci_dev *pdev)
>  
>  int vpci_assign_device(struct pci_dev *pdev)
>  {
> -    unsigned int i;
>      const unsigned long *ro_map;
>      int rc = 0;
>  
> @@ -159,14 +186,13 @@ int vpci_assign_device(struct pci_dev *pdev)
>          goto out;
>  #endif
>  
> -    for ( i = 0; i < NUM_VPCI_INIT; i++ )
> -    {
> -        rc = __start_vpci_array[i](pdev);
> -        if ( rc )
> -            break;
> -    }
> +    rc = vpci_init_header(pdev);
> +    if ( rc )
> +        goto out;
> +
> +    rc = vpci_init_capabilities(pdev);
>  
> - out: __maybe_unused;
> + out:
>      if ( rc )
>          vpci_deassign_device(pdev);
>  
> diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
> index 61d16cc8b897..e5e3f23ca39c 100644
> --- a/xen/include/xen/vpci.h
> +++ b/xen/include/xen/vpci.h
> @@ -13,11 +13,12 @@ typedef uint32_t vpci_read_t(const struct pci_dev *pdev, unsigned int reg,
>  typedef void vpci_write_t(const struct pci_dev *pdev, unsigned int reg,
>                            uint32_t val, void *data);
>  
> -typedef int vpci_register_init_t(struct pci_dev *dev);
> -
> -#define VPCI_PRIORITY_HIGH      "1"
> -#define VPCI_PRIORITY_MIDDLE    "5"
> -#define VPCI_PRIORITY_LOW       "9"
> +typedef struct {
> +    unsigned int id;
> +    bool is_ext;
> +    int (*init)(struct pci_dev *pdev);
> +    int (*cleanup)(struct pci_dev *pdev);
> +} vpci_capability_t;
>  
>  #define VPCI_ECAM_BDF(addr)     (((addr) & 0x0ffff000) >> 12)
>  
> @@ -29,9 +30,22 @@ typedef int vpci_register_init_t(struct pci_dev *dev);
>   */
>  #define VPCI_MAX_VIRT_DEV       (PCI_SLOT(~0) + 1)
>  
> -#define REGISTER_VPCI_INIT(x, p)                \
> -  static vpci_register_init_t *const x##_entry  \
> -               __used_section(".data.vpci." p) = (x)
> +#define REGISTER_PCI_CAPABILITY(cap, finit, fclean, ext) \

REGISTER_VPCI_CAPABILITY() if possible (note the added V).

> +  static vpci_capability_t finit##_t = { \

static const?

> +        .id = (cap), \
> +        .init = (finit), \
> +        .cleanup = (fclean), \
> +        .is_ext = (ext), \

Indent should be 4 spaces here I think.

> +  }; \
> +  static vpci_capability_t *const finit##_entry  \
> +               __used_section(".data.vpci") = &finit##_t

IMO this should better use .rodata instead of .data.  Not that it
matters much in practice, as we place it in .rodata anyway.  Note
however you will have to move the placement of the VPCI_ARRAY in the
linker script ahead of *(.rodata.*), otherwise that section match will
consume the vPCI data.

> +
> +#define REGISTER_VPCI_CAP(cap, finit, fclean) \
> +                REGISTER_PCI_CAPABILITY(cap, finit, fclean, false)
> +#define REGISTER_VPCI_EXTCAP(cap, finit, fclean) \
> +                REGISTER_PCI_CAPABILITY(cap, finit, fclean, true)

Since you are modifying those, can use 4 spaces as indentation?
There's no need to have such padding.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 12:52:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 12:52:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006801.1386049 (Exim 4.92)
	(envelope-from )
	id 1uNA4u-0007u9-H2; Thu, 05 Jun 2025 12:52:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006801.1386049; Thu, 05 Jun 2025 12: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 1uNA4u-0007u2-EK; Thu, 05 Jun 2025 12:52:16 +0000
Received: by outflank-mailman (input) for mailman id 1006801;
 Thu, 05 Jun 2025 12:52:14 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uNA4s-0007tu-TC
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 12:52:14 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uNA4s-003aGI-0w;
 Thu, 05 Jun 2025 12:52:14 +0000
Received: from [15.248.2.232] (helo=[10.24.66.12])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uNA4s-00GLF2-1Z;
 Thu, 05 Jun 2025 12:52: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=L14gISyimxxY29rmC/iLjrj/MwivXj6jzL1ZFHd9EgY=; b=v32Xd1GpLMkN9enwAb075xsbRq
	ZBwtw8yswb/Mfp5PVyputVHEHSMIUKMDDw/0Keym3CKZ4ddEOHFB1R3muH6sey8MuCOv1IAJ9DK6a
	HsW627ebMyUIJwDJI76mpJxqFefW8ctHKqNSn70yOloDp5WnIb0VaZhSUbr8RuuMTLws=;
Message-ID: <9de5c7a2-0679-4f32-9dfb-102261124f5e@xen.org>
Date: Thu, 5 Jun 2025 13:52:11 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] SUPPORT.md: mark xenstore live update as supported
To: Juergen Gross , 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: <20250521044634.11361-1-jgross@suse.com>
 <20250521044634.11361-3-jgross@suse.com>
Content-Language: en-GB
From: Julien Grall 
In-Reply-To: <20250521044634.11361-3-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Juergen,

On 21/05/2025 05:46, Juergen Gross wrote:
> Live update of xenstored is available since Xen 4.15 and it is tested
> on a regular basis since then.
> 
> Switch the live update support from "Tech Preview" to "Supported".

I think it is well overdue :). The feature has been used at large scale 
a couple of years ago.

> 
> Signed-off-by: Juergen Gross 

Acked-by: Julien Grall 

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 12:58:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 12:58:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006806.1386059 (Exim 4.92)
	(envelope-from )
	id 1uNAAc-0008Uw-4U; Thu, 05 Jun 2025 12:58:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006806.1386059; Thu, 05 Jun 2025 12:58: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 1uNAAc-0008Up-1l; Thu, 05 Jun 2025 12:58:10 +0000
Received: by outflank-mailman (input) for mailman id 1006806;
 Thu, 05 Jun 2025 12:58: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 1uNAAa-0008Uj-7F
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 12:58:08 +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 b904a713-420c-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 14:58:06 +0200 (CEST)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-60707b740a6so1254483a12.0
 for ; Thu, 05 Jun 2025 05:58:06 -0700 (PDT)
Received: from localhost.localdomain ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-60566c5a8f1sm10400585a12.20.2025.06.05.05.58.04
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 05:58:04 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b904a713-420c-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1749128285; x=1749733085; 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=9KihiqfAuRceeX2KLBAt2SOwHJgjXU1PeauPiesRfeA=;
        b=FUXFOQwwWa/fFEhlhacpks1HqP6NS0Iif7Ij+xj9PjtFOodlf7iePfTCvZlqjkLHNU
         VzdYJRqexbFajWKLe5uEWVsoJX5J9zD/1IcXISnQY3ez0a3ONnmVJudybcGQFFysCe6D
         8xf14oR4APRUWDmn7suoKbe0V8H50JpsK+xK4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749128285; x=1749733085;
        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=9KihiqfAuRceeX2KLBAt2SOwHJgjXU1PeauPiesRfeA=;
        b=VH98SM9URZJXIgWNQeOeMzaWKt3BKVOc1lF5reQzpsOzWVhcDOaK2HdA7D6UwSqv3R
         TmVPm1i1SxQNQ3MSJYVeLKzGqffJvcYM4Rih5Pp1UW4XRd/8nd+UWnR3RSRHOhfNQJKk
         hK1tUHeItj9I7kcmeSI+4Dc9nuDnI42uYktpv3I8BZc1yCPwA71LdxMOvbYzO8rOuBsU
         UYjezzF1fW8CgHLyKJvEg/GU3OzmB4M56SoXktBl+1Y7MEPhv5W8VBNkTpwi4RnO3JAZ
         6ushrBvaV/Dc4eyBB55gMQqWItwCyA7XddZ4QJ6VubI/rYQcbQkS309puGFeBFcjeTou
         hwqA==
X-Gm-Message-State: AOJu0Yy9036rhuJX9M4uGTKKnuYTcBT9mmNiT0zBvYJ/zYgXsSQ8m42x
	8nvD6zd4SEQotaTbLZJfNOXZA1A/5C8a09rgxdx0YyRwiH4t4kQnip3ibSLPnQ/0YNEF+MtTEAD
	k+1AVVfmEsA==
X-Gm-Gg: ASbGnct6DKAU/gq2ZToieiLCpR9fmRvam8UAtQ3yTMZWWjxcoc12TDXzEM3v7LHQ0Bx
	TAMZHLLNVniiwHmA9reEEGEwgGA79oHEYqrReY7AqIQx5HpRJpvDoM6OIuCvps5HWAWGLqHaSEH
	5+q+ZboRTikdDUqjzJx0ibjZC1iX4LiPXXYI4TOb7SiFnZ/SE3Q3WCpJVQjm9gpza7Xa37L1hUI
	r85SrHWSse5Fd1nMNDKhGCbha8LGZr9QOhV5VylQRqb5khFf4Ucak/7hnPHxbx1dcE/T13R21+L
	Zi5LzrF/QZmJrJdxacl74Yjx/2y1RWrp9ax5H2+8fDJaMWPgetAqV0gOt/eZ
X-Google-Smtp-Source: AGHT+IG2znhCuAhjzRNb/TUUxIHZq6pRY/eArB8U/WfEODScDRAZCmSoVfJLyoc7ECYtC+DWWsrh0w==
X-Received: by 2002:a05:6402:1ed0:b0:606:b997:ae3d with SMTP id 4fb4d7f45d1cf-606e944ee65mr6021473a12.1.1749128284738;
        Thu, 05 Jun 2025 05:58:04 -0700 (PDT)
From: Gang Ji 
To: xen-devel@lists.xenproject.org
Cc: Gang Ji ,
	Andrew Cooper ,
	Anthony PERARD 
Subject: [PATCH v2] xenalyze: Add 2 missed VCPUOPs in vcpu_op_str
Date: Thu,  5 Jun 2025 20:57:38 +0800
Message-ID: <20250605125738.1444521-1-gang.ji@cloud.com>
X-Mailer: git-send-email 2.47.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The 2 missed ones are: register_runstate_phys_area and
register_vcpu_time_phys_area.

Fixes: d5df44275e7a ("domain: introduce GADDR based runstate area registration alternative")
Fixes: 60e544a8c58f ("x86: introduce GADDR based secondary time area registration alternative")
Signed-off-by: Gang Ji 
Reviewed-by: Andrew Cooper 
---
 tools/xentrace/xenalyze.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
index adc96dd7e4..1c13682aaa 100644
--- a/tools/xentrace/xenalyze.c
+++ b/tools/xentrace/xenalyze.c
@@ -6513,7 +6513,8 @@ static const char *vcpu_op_str[] = {
     "register_runstate_memory_area", "set_periodic_timer",
     "stop_periodic_timer", "set_singleshot_timer", "stop_singleshot_timer",
     "register_vcpu_info", "send_nmi", "get_physid",
-    "register_vcpu_time_memory_area",
+    "register_vcpu_time_memory_area", "register_runstate_phys_area",
+    "register_vcpu_time_phys_area",
 };
 
 static const char *sched_op_str[] = {
-- 
2.47.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 12:59:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 12:59:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006821.1386069 (Exim 4.92)
	(envelope-from )
	id 1uNACC-0000c1-EL; Thu, 05 Jun 2025 12:59:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006821.1386069; Thu, 05 Jun 2025 12:59: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 1uNACC-0000bu-BN; Thu, 05 Jun 2025 12:59:48 +0000
Received: by outflank-mailman (input) for mailman id 1006821;
 Thu, 05 Jun 2025 12:59: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 1uNACB-0000bf-NR
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 12:59:47 +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 f45f7dea-420c-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 14:59:45 +0200 (CEST)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-450dd065828so6920205e9.2
 for ; Thu, 05 Jun 2025 05:59:45 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23506cf468esm119156305ad.165.2025.06.05.05.59.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 05:59:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f45f7dea-420c-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749128385; x=1749733185; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Yj4NPeTAaASdQyIvyzzXr2FuA+MvXm7IOjjmkv/2ItM=;
        b=gfJUntxzyXfrFKv/w2elupzSngJqt7XmdzaVFZHNk0Nt5iREtgsfKY4YWNPK1Gt9/L
         79FIcnMobaWdBm7iwdFa5voYhAV11yrD7oy5mq8hOy5B34HX2EcUiOltOBxMyI5C/MoK
         BvFwGdtU1W6pW1q1NHTsV2DrUo3Oj1NhAJXvyQkT8gMtuBlEstLqGgrZh0jL8Mgxe3Zx
         CxI2S/aJk7TOZG4GClnLwhJTjPZxKEqQzy73ykU+RhPVIaRxSRp2r1n2Dxo1H8Jl/4he
         D3SSxUXF0TsDP+A4TJDdKysGhzJt09nY/vPSfxvyejM+Dc1PFRFh1XlPCQ8S87rOqJpB
         D+2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749128385; x=1749733185;
        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=Yj4NPeTAaASdQyIvyzzXr2FuA+MvXm7IOjjmkv/2ItM=;
        b=l/+LPutw4zIiQq8y0YDCZGhp4OMnJjZbQmiWRYqizUhxLSadKJi/spR8FG4KyioXXS
         rNi8MQAhJg3HC9+68nQNDhZ5j4YU1AF3rC7YNGHqRrPbbzTgSyMHNbDgRanQ1PRWxnOY
         6grKBRcS7wHqEGo9n5yikzjp8hu9Bfcd+MVuj7wPNQ3uAjgKffdQ+uxrPpIHlnKlJ+SK
         nXbXEmGeOyMIsiSN+5HjuyX3mQg22Ccn4LwnSPyAOFGGML4MiOwk/Y0CcNBOGqkyGXB9
         EZLB0C+h3qHdNsbBGmZk44bzw0UUsAOm65Zmx+RHP+vCRPaZJQ+RDm0txdzSfNhChuK2
         pT5Q==
X-Gm-Message-State: AOJu0YwDFbhVIJl61r2hrdx/SaFsRYLcT5UOfd7bWNnI8rtrGsHTeHhM
	jbTB2U9h/cXKDprIeX6z2qLSVROdok5r3DOceYfAIhyYMpAezxKs9X3juu92qWG8sA==
X-Gm-Gg: ASbGncsuWksjDV1Kzzjs8ElTxTfOj2h8fsf61jqt8UYE8urd2G0sd1ABV//tHhh1xlk
	kzcn63otD877+ZZ7OBbIH5/ikHxAxjZSb8M6/e+fyAkZIzvl/+fD8kCHeT1/7kWB9wpuQryi4+w
	u+fW01ER1xKrOb6ahYilmsJIBuJzWNPbOHmgo/U0RbUQJddzFQLQ/2hx9BXp79CcniFrLWEMr3V
	85i8EcTtxL+SHY+atc8e5DaC+tgoxuSSDWw+ywX2IttAzW07MprMzcGct9og7HeWYv66+IjBIkY
	SGiNGyIBxp2SQ5ljB6aQNJ0gHQ/y1hb3y3m7tkCUWewGEq1cuabuNos6FRy/C297HvWL8oxpe5Q
	agrzyu2f19RDQb1QUmwrX8gFK7MtPRFImsJ7S
X-Google-Smtp-Source: AGHT+IEzeyHNuznvjgctLNohS/lDQw9Txuo1Bymnq5V3BprBvJai9znuzIDLH8/uyFUhOfXC3nHW+g==
X-Received: by 2002:a05:6000:4202:b0:3a5:1241:ce99 with SMTP id ffacd0b85a97d-3a51d92f980mr6138706f8f.24.1749128385097;
        Thu, 05 Jun 2025 05:59:45 -0700 (PDT)
Message-ID: 
Date: Thu, 5 Jun 2025 14:59:35 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 04/10] vpci: Refactor REGISTER_VPCI_INIT
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Jiqian Chen 
Cc: xen-devel@lists.xenproject.org, Huang Rui ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini 
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
 <20250526094559.140423-5-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 05.06.2025 14:50, Roger Pau Monné wrote:
> On Mon, May 26, 2025 at 05:45:53PM +0800, Jiqian Chen wrote:
>> --- a/xen/drivers/vpci/vpci.c
>> +++ b/xen/drivers/vpci/vpci.c
>> @@ -36,8 +36,8 @@ struct vpci_register {
>>  };
>>  
>>  #ifdef __XEN__
>> -extern vpci_register_init_t *const __start_vpci_array[];
>> -extern vpci_register_init_t *const __end_vpci_array[];
>> +extern vpci_capability_t *const __start_vpci_array[];
>> +extern vpci_capability_t *const __end_vpci_array[];

These also want to gain another const, to match ...

>> @@ -29,9 +30,22 @@ typedef int vpci_register_init_t(struct pci_dev *dev);
>>   */
>>  #define VPCI_MAX_VIRT_DEV       (PCI_SLOT(~0) + 1)
>>  
>> -#define REGISTER_VPCI_INIT(x, p)                \
>> -  static vpci_register_init_t *const x##_entry  \
>> -               __used_section(".data.vpci." p) = (x)
>> +#define REGISTER_PCI_CAPABILITY(cap, finit, fclean, ext) \
> 
> REGISTER_VPCI_CAPABILITY() if possible (note the added V).
> 
>> +  static vpci_capability_t finit##_t = { \
> 
> static const?

... this.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 13:08:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 13:08:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006828.1386080 (Exim 4.92)
	(envelope-from )
	id 1uNAKS-0002Yp-7U; Thu, 05 Jun 2025 13:08:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006828.1386080; Thu, 05 Jun 2025 13:08: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 1uNAKS-0002Yi-3a; Thu, 05 Jun 2025 13:08:20 +0000
Received: by outflank-mailman (input) for mailman id 1006828;
 Thu, 05 Jun 2025 13:08: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 1uNAKR-0002Yc-9r
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 13:08:19 +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 25359a84-420e-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 15:08:17 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3a36efcadb8so821143f8f.0
 for ; Thu, 05 Jun 2025 06:08:17 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-747affcf84asm13224472b3a.130.2025.06.05.06.08.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 06:08:15 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 25359a84-420e-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749128896; x=1749733696; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=wFmhZ5gAy3m/BfHmDeD8ut2hZVZXROiOoMPg6M67dR8=;
        b=PIxxGVNyZ/4DlkrgI2YsR4kp/4ls93bXlr1t9GJFlPJAqGUXV3fRu0aR6ThLfCkx6/
         cLCMHRr81mv9vpbcJHKBhfrR8C7khF7mvjd5tBGXDFNwLATY6IdLReSM5jGP/aYdTUFi
         SZ7CBsO+9l9nU8sJhypSeZxhKYZS0ofMzMAdCJZuw65qtnHuHLCNUkePZfMqvJW/L0BN
         PrxVOkdLgoE31Lu8KThMe48SjZONgbK9WCTwqFWFwf4tW0DQwmgiB2fziPeb28IMs3Ra
         cXzvdLYTtDP35TIi9+tV4JCfrpXc5xN73BKpa0gb9bWVe+tXc3/jyv2+gc+7tDnmdndv
         uvJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749128896; x=1749733696;
        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=wFmhZ5gAy3m/BfHmDeD8ut2hZVZXROiOoMPg6M67dR8=;
        b=oIPPDsUptF7o0TgakG1aUGTZX0TiwbZUPoLDcGtSHXUi/tK4KHc4rmWmXK0+h98Vb9
         7MGf9OhYUhnZPVFMlI11bFvcGqLTOtzqyEdaQEIwJ2UBWyYojohj6Zp2ZAJ5jPQMjNlx
         1qTHtjVjVp5zQ+oczu6IN1snd6VL38QzhXT5FwEeQiWpaYU5TIdmdNc9FSFtkLcghHaJ
         Cu1gVA+2mtKMuVtwE7wUQru34HMPD33vZKze+ww4gvS3p76vVqzpNVsb4nZgOTJdkBvf
         7TuX/G19pD2UPFCBXZTjXSep2QaeJ/rJ810fqvrLET0LrgmFj1extvuDEdc7Rh99XbaS
         27Aw==
X-Forwarded-Encrypted: i=1; AJvYcCVdn5i2dKvtAHYAq/Pr0Vlov8+yJ+Y9E1JbsSm8B1GEXKxP/vzxIiGfD1gr3dne3q16r5du5Pu8xhc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzoBGkrXUF0cYxlqgsYDb3DSNj487uytO4IXvjGfvBK4wpTiVgk
	X4igHZNDO0vIxpUQJO0fCu3XWz4KWG0SxxL/D2xLTwyJ5cz6CzpMRRj4owHuG28Uig==
X-Gm-Gg: ASbGncvK0REzQ0ApAtJBd76bKIr7Zs5wedNwKJSGBgXwhSYeVHu8kjffb95iaYQY1OL
	vOjBDtAyN3rF1QE/lHftOeeOjZu3XC7d7EK/nmKWwO7sHcZNMw54u/5xiaos8bogyMoJozn7HL9
	6O9YZr7aP98QEgzR7/hZ5MfuxK7WASbdFYmlgcVCsELLTNPFXMBDBurmHeLl5feUtfQkTW7vc8W
	1lqTdhHfrHRkFozM9sM8kPpLgNxxUGoUjiprcvI7/KoVNMlbIShst3ldWQfiucuw3pXqVDbOfdb
	4axRI77P9VHHeC0M1DKgAGrEeyC6R7Rbjnkfp+kupS2n6d2pplasIR2mBlkh5PFVOFxjg9HjG7q
	dA/xtNjnaAvq6IzFKIq5V/Kw64dOnpPlSfraYcpJBC6mITVg=
X-Google-Smtp-Source: AGHT+IFOF4KmSNbYzhqpXnOOtBxXVvrGQHwcPOIv2mywKj+gjBNydfJ0xQOlcMtrTheFVJYyD4SwzA==
X-Received: by 2002:a05:6000:26d3:b0:39f:175b:a68d with SMTP id ffacd0b85a97d-3a51d8f6075mr6515539f8f.11.1749128896130;
        Thu, 05 Jun 2025 06:08:16 -0700 (PDT)
Message-ID: 
Date: Thu, 5 Jun 2025 15:08:07 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/3] x86/EFI: Fix detection of buildid
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 
Cc: Andrew Cooper ,
 Ross Lagerwall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "Daniel P . Smith" ,
 Xen-devel 
References: <20250605111638.2869914-1-andrew.cooper3@citrix.com>
 <20250605111638.2869914-2-andrew.cooper3@citrix.com>
 <0a314400-126a-4c2a-b36c-dda61bb0b751@suse.com> 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 05.06.2025 14:20, Marek Marczykowski-Górecki wrote:
> On Thu, Jun 05, 2025 at 02:02:21PM +0200, Jan Beulich wrote:
>> On 05.06.2025 13:16, Andrew Cooper wrote:
>>> The format of the buildid is a property of the binary, not a property of how
>>> it was loaded.  This fixes buildid recognition when starting xen.efi from it's
>>> MB2 entrypoint.
>>>
>>> Suggested-by: Ross Lagerwall 
>>> Signed-off-by: Andrew Cooper 
>>
>> I'll pick this up without a Fixes: tag, but I think it ought to have one. (I
>> didn't check whether MB2 or build-id support came later, hence introducing the
>> issue.)
>>
>>> --- a/xen/common/version.c
>>> +++ b/xen/common/version.c
>>> @@ -203,8 +203,11 @@ void __init xen_build_init(void)
>>>      rc = xen_build_id_check(n, sz, &build_id_p, &build_id_len);
>>>  
>>>  #ifdef CONFIG_X86
>>> -    /* Alternatively we may have a CodeView record from an EFI build. */
>>> -    if ( rc && efi_enabled(EFI_LOADER) )
>>> +    /*
>>> +     * xen.efi built with a new enough toolchain will have a CodeView record,
>>> +     * not an ELF note.
>>> +     */
>>> +    if ( rc )
>>
>> Instead of dropping the efi_enabled(), I think you want to replace EFI_LOADER
>> by EFI_BOOT.
> 
> Part of the motivation for MB2 entry point in xen.efi is using the
> same binary in all boot modes, including legacy boot - in which case
> none of EFI_* checks would be appropriate here. The grub series adds
> support for loading PE binaries, and IIUC it isn't tied to booting via
> EFI.

"The grub series" being which one? I didn't know xen.efi's non-EFI MB2 entry
point could be used; instead I was under the impression that someone was
having (half?) a patch eliminating the MB data from xen.efi, as being dead
code.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 13:24:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 13:24:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006847.1386091 (Exim 4.92)
	(envelope-from )
	id 1uNAaD-0005oP-LC; Thu, 05 Jun 2025 13:24:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006847.1386091; Thu, 05 Jun 2025 13: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 1uNAaD-0005oI-G9; Thu, 05 Jun 2025 13:24:37 +0000
Received: by outflank-mailman (input) for mailman id 1006847;
 Thu, 05 Jun 2025 13: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 1uNAaC-0005oC-EG
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 13:24:36 +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 6bb719db-4210-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 15:24:34 +0200 (CEST)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-43ea40a6e98so12021835e9.1
 for ; Thu, 05 Jun 2025 06:24:34 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-747afe967easm12789921b3a.21.2025.06.05.06.24.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 06:24:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6bb719db-4210-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749129874; x=1749734674; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=u8+sxsowr6AU5P36Xo1cUQ+rCEgTxvqKRs52I670ZnA=;
        b=Piw8DG1GHrhtpnAO9SvXVQMaGEBGiWUiopOmRgJNbSiHzEnapnwuKuR5Qko4+gbzMB
         4B4i778VQzzRjOWoVcI7s3oreDCpp4Hi0Sc/U1H4fhwyM+PH5duz/cK/yfMogwT/Kk1h
         NY6zFdmYAY/3SGlDVerpDZsaZyVWURXuoDeKr+rKO8nm9i01b5HPRNb7osze19YaIhF5
         lm1cems3NaKAzEx6j1YA3ZhrrpUOBjsge4he3AHpMZ3utbN58FL7MT75Ta78jQxRZk/2
         kql5Z7383ytLJ0PRCis7t3iO4suoq9eTCcL7NIAAsFBZ71HSnbAp/8ctNMeSNrM4G9wn
         jNqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749129874; x=1749734674;
        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=u8+sxsowr6AU5P36Xo1cUQ+rCEgTxvqKRs52I670ZnA=;
        b=XnL1sFNqwYV0jLV9mnfhuVkdd8pqXSkvyYI+GTyz9t76ok5nGzHOklSNUyHu6vW/7a
         xmNo2F4fLuN1O3ss3kTlfgnySbXL5m08ZQ+VUosi2+g7I7y+QJ4OXQW1oUa2etNAUXuY
         +LXpKlpopiFY32MZXoZ3ceT0GI5XhjKLBcyI3HCjJoLIVp/FoQiUCz38YDcF80cinKIw
         0AK3wP3PNC9G3Dge8TgclT9HZcN3RrmDvuKF97UztOpJpwf0Zoq9zRAqLSQ1TrWRRIti
         x3lWDeUcLUBKGY5CQrI4nAkYnRg+Ldr6PDwmYEADwPn1MQ4FcuOG7lvCXbtAyu7ArLkX
         Q23g==
X-Forwarded-Encrypted: i=1; AJvYcCXQXsrRuvE9r3RQ/lsif9w6cG+1OLyDQavfpRrNHCSrXmmsIhelvl6t43XXEirGWSBL7A8i55jAtnM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxYfA7D1fLoUU7i8WqqOE/EAD8xhPDY7esq9Em8RKpmRUAELB8D
	11j/efZuVpM2BmpkAJZWIs/RTfoaLyzLzcC98sUflvyy52HMQ8/Pg8DNLttL65btcA==
X-Gm-Gg: ASbGncsxgOFWj63SUtflDe9AxzxAWhl9Yttb7ofWyFyAsUOpUNk97tvf5HMFkYADWCJ
	t1cc6yMevqqIHg/XARqHAEy/4whRDFBwPJt/g277YxnzPZRuc4VuBqRkKat2r7jgWFwMKVXIIua
	M1+S+pteog1qiyGlG6mkt0W72N7olRMPPXPMLLdrSq6tPxwz/ys7MjrDwb2Q5/cdCWisHc7l8Hp
	dZH6hpj0TAFR5kKeqQEJmObm8huI/2p9Axp9Z8X6oypP3W7GvEJ4OYiwOgdTw5NloLgmbZv5S8H
	Urk5Qzpdyz6moRi0WtbkzobXhB81iq5/Uiwiao5Bxi3ajv1ovPdinoBBpgO4317EAMSvmfPRBmv
	Zj8lMlaug6pyu+KRtmVtUbcPfNSr2hMRIysUQ
X-Google-Smtp-Source: AGHT+IFL8X4WjAs9RHgsM+f9mOC15fIN0FKD7wUFR7IdyO4+Vr1DYsdhd3IHsTS+NiImdstm9/nZRw==
X-Received: by 2002:a05:6000:381:b0:3a4:d722:5278 with SMTP id ffacd0b85a97d-3a51d9769c2mr6155181f8f.39.1749129873757;
        Thu, 05 Jun 2025 06:24:33 -0700 (PDT)
Message-ID: <4d1f1b70-e309-453b-bae6-e066d49a417a@suse.com>
Date: Thu, 5 Jun 2025 15:24:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/3] x86/EFI: Fix detection of buildid
To: Andrew Cooper 
Cc: Ross Lagerwall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 "Daniel P . Smith" ,
 Xen-devel 
References: <20250605111638.2869914-1-andrew.cooper3@citrix.com>
 <20250605111638.2869914-2-andrew.cooper3@citrix.com>
 <0a314400-126a-4c2a-b36c-dda61bb0b751@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 05.06.2025 14:14, Andrew Cooper wrote:
> On 05/06/2025 1:02 pm, Jan Beulich wrote:
>> On 05.06.2025 13:16, Andrew Cooper wrote:
>>> The format of the buildid is a property of the binary, not a property of how
>>> it was loaded.  This fixes buildid recognition when starting xen.efi from it's
>>> MB2 entrypoint.
>>>
>>> Suggested-by: Ross Lagerwall 
>>> Signed-off-by: Andrew Cooper 
>> I'll pick this up without a Fixes: tag, but I think it ought to have one. (I
>> didn't check whether MB2 or build-id support came later, hence introducing the
>> issue.)
> 
> MB2+EFI came long before any buildid support.  If you want a fixes tag,
> it's eee5909e9d1

That commit talks of an earlier hack, though. And no, MB2 work came later,
albeit still in the 4.9 dev window (commit 9180f53655245).

>>> --- a/xen/common/version.c
>>> +++ b/xen/common/version.c
>>> @@ -203,8 +203,11 @@ void __init xen_build_init(void)
>>>      rc = xen_build_id_check(n, sz, &build_id_p, &build_id_len);
>>>  
>>>  #ifdef CONFIG_X86
>>> -    /* Alternatively we may have a CodeView record from an EFI build. */
>>> -    if ( rc && efi_enabled(EFI_LOADER) )
>>> +    /*
>>> +     * xen.efi built with a new enough toolchain will have a CodeView record,
>>> +     * not an ELF note.
>>> +     */
>>> +    if ( rc )
>> Instead of dropping the efi_enabled(), I think you want to replace EFI_LOADER
>> by EFI_BOOT.
> 
> No - that's differently buggy.  I suppose the commit message wasn't
> clear enough?
> 
> We'd still have a CodeView record if we booted xen.efi using it's MB2
> entrypoint without the EFI extensions.

Hmm, if that's a possible mode of operation (as said in reply to Marek, I
wasn't aware of that) - yes.

> This really is a property of being a PE32+ binary, and nothing to do
> with EFI.

Which still can be checked for without having this code path being taken
for xen.gz, too: You could e.g. check for &efi > &_end. That's firmly an
image property (yet I expect you're going to sigh about yet another hack).

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 13:27:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 13:27:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006853.1386099 (Exim 4.92)
	(envelope-from )
	id 1uNAdR-0006LE-0h; Thu, 05 Jun 2025 13:27:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006853.1386099; Thu, 05 Jun 2025 13:27: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 1uNAdQ-0006L7-UK; Thu, 05 Jun 2025 13:27:56 +0000
Received: by outflank-mailman (input) for mailman id 1006853;
 Thu, 05 Jun 2025 13:27: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 1uNAdP-0006L1-Ix
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 13:27:55 +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 e274ff53-4210-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 15:27:53 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3a4e742dc97so1365885f8f.0
 for ; Thu, 05 Jun 2025 06:27:53 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23506d21802sm119390475ad.215.2025.06.05.06.27.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 06:27:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e274ff53-4210-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749130073; x=1749734873; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=s8BoNeAxz/18ooR6Va4Bog9IVU7MoN5pP9IrNWTfYXQ=;
        b=B15AZAzIHbPA94tlEqf8CviAssQYk41PtpuFBiaRNGLLygYyPnvInM5U4othuh676h
         jDHhYKER1Y9VjZaMZMrGD6z/eFv7z8ld/8JlzpxyF4BnLz5nAOIzXzVlHYSLMpXExzdy
         bCF04akIueCAexWTVhq+TU5wlZm8RBWbnf2BvoRudVvrxxDey6Md6E2IjJwQ2wkQO+2e
         S+lQ5usKKd6zQB6UvbNDL8isZJdeFRyQhUcCpbIKG2hSHnyR3+voqg5wKGPe+Jwc6/QV
         C2P3NwC9lEcENHHbOQ8P0/5aFyuhWlt7RwnRgxZ0agc/pL3Tjiuo0lYpFBhc4BCy2HAt
         zYKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749130073; x=1749734873;
        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=s8BoNeAxz/18ooR6Va4Bog9IVU7MoN5pP9IrNWTfYXQ=;
        b=m2h5wonm9hQ1ukw2R1FZ/Az+aETdxWwV6VYdRf//oJgua+b7lwxMxZFgh5B7+PMSk9
         MMDuYo7CerQHPzqUiPfBsrZT9WVHufuGqdDu5AAfpV/SZVmqlzLs4jd8N59SQxww9rfC
         PRotLG63DqjdudmVjnUbPOPT4/YyhKCOysIzTfxtYKiZNNxcN0Zp9DAl3cKy+sUSar6Q
         8z8tItVE7i0TM1zCaJ/8KYSfFcMkQZyOsA9gVA85rTIZA5+8Dq5XkrGG/GHMFezQXc18
         0VoHkGJcviFE4uDpKxNfwdzxtGEiBbvVuocgc1oKrtEEnQ0X28nTF1fTkcZF0cpMJOde
         a+YA==
X-Forwarded-Encrypted: i=1; AJvYcCVnUVaCZ9BlJKzOY1yktTrBBxJrrFdy4YjxyLWkn2Q9C3Y+5d/q7CShOYIElUr6rr2qN7ioOv/f8Rc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzOWSDvWvN9lM/diw8gRXhql4Xhi4jjlABnhrCnIY/ZPEFxSo+U
	aeW090Ib7rioVu15oqAVUD/f/rbKipbn9+Ovd+tsiUL4zqc3ZNanSvt+RmmBV5OTDT/TMpuye46
	f9DA=
X-Gm-Gg: ASbGnctgmcGb8NBavu5cvnpgNj2XiMKai6+f0tB9GmDnnsKB+z66asMUCR+OQ/7hnh+
	YKA/dpjPV4azoADxevqFmgzcQI5072N1Fjshw8J8F+F1nXi461PzjcMhvgXMqbb+TthRSrvtc2U
	TC7I8WDwFk+DKi9p5T9JGsBYkyc6QcGXRk05eysmr5kwVR68vEnJrKePx/G8EOZnpaZEG+4hS0h
	GMVRGonFfaHnORsIHYMHA/m53vUPQSq/gh05zCa5BbIPXIuKxwvvVYsngwKmCB8QSEARhWaTcGG
	HLh+rxiPH+D/Yjyp+G8uyxi91T6mmXjdqMF4oL+BIh43NdjDs0lVs9zhcmryKD0hDDfJQ436QjN
	4uE62W/KjACQdblJs6vV6WnP3jCxrmgP9nJLn
X-Google-Smtp-Source: AGHT+IH9IzJwKclOgpgw0Izj0bXnkFsbx6HjRdazthC4nY2QgKGK5QzB649hLQbhZ1Lfvwp+T+yNng==
X-Received: by 2002:a05:6000:2310:b0:3a4:cec5:b59c with SMTP id ffacd0b85a97d-3a526e1cf0fmr3252435f8f.25.1749130073015;
        Thu, 05 Jun 2025 06:27:53 -0700 (PDT)
Message-ID: 
Date: Thu, 5 Jun 2025 15:27:42 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/3] xen/keyhandler: add missing noreturn attribute
To: Nicola Vetrini 
Cc: victorm.lira@amd.com, Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?B?Um9nZXIgUGF1IE1vbm7Dg8Kp?= ,
 Stefano Stabellini ,
 Federico Serafini ,
 Bertrand Marquis , xen-devel@lists.xenproject.org
References: <20250604235034.1595881-1-victorm.lira@amd.com>
 <9e3a7b1b-7fbe-428b-888a-c18c95d8ee37@suse.com>
 
 <3b24b1df1a0ce4a62b53067b09fe9a02@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: <3b24b1df1a0ce4a62b53067b09fe9a02@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 05.06.2025 14:26, Nicola Vetrini wrote:
> On 2025-06-05 14:22, Nicola Vetrini wrote:
>> On 2025-06-05 09:17, Jan Beulich wrote:
>>> On 05.06.2025 01:49, victorm.lira@amd.com wrote:
>>>> From: Nicola Vetrini 
>>>>
>>>> Function `reboot_machine' does not return, but lacks the `noreturn' 
>>>> attribute,
>>>> therefore causing a violation of MISRA C Rule 2.1: "A project shall 
>>>> not contain
>>>> unreachable code".
>>>
>>> Is this (uniformly) true? Looking at ...
>>>
>>>> --- a/xen/common/keyhandler.c
>>>> +++ b/xen/common/keyhandler.c
>>>> @@ -251,7 +251,7 @@ static void cf_check 
>>>> dump_hwdom_registers(unsigned char key)
>>>>      }
>>>>  }
>>>>
>>>> -static void cf_check reboot_machine(unsigned char key, bool unused)
>>>> +static void noreturn cf_check reboot_machine(unsigned char key, bool 
>>>> unused)
>>>>  {
>>>>      printk("'%c' pressed -> rebooting machine\n", key);
>>>>      machine_restart(0);
>>>
>>> ... generated code here, I can see that the compiler is perfectly able 
>>> to
>>> leverage the noreturn that machine_restart() has, resulting in no
>>> unreachable code to be generated. That is - neither in source nor in
>>> binary there is any unreachable code. Therefore I'm having a hard time
>>> seeing what the violation is here.
>>>
>>> That said, I certainly don't mind the addition of the (seemingly) 
>>> missing
>>> attribute. Otoh I wonder whether an attribute the removal of which has 
>>> no
>>> effect wouldn't count as "dead code" or alike, violating some other 
>>> rule.
>>>
>>
>> Inlining does not play a role in this case. Here reboot_machine() is 
>> marked as a violation because machine_restart() is noreturn and there 
>> is no other path upon which reboot_machine() may return, hence any 
>> function calling reboot_machine() could have portions that are 
>> inadvertently unreachable (as in never executed due to divergence) by 
>> not having the annotation.

Just that there's not going to be a 2nd caller, considering the purpose
of the function.

>> That said, in such trivial cases compilers 
>> are typically able to derive the property automatically, but they are 
>> not obliged to and, more importantly, the behavior may even differ with 
>> the same compiler using different optimization levels.
> 
> Just a note: in later revisions of MISRA C this has become a rule of its 
> own [1], which helps reduce confusion, but up to MISRA C:2012 Amendment 
> 2 (currently used by Xen), this is part of Rule 2.1.
> 
> [1] Rule 17.11: "A function that never returns should be declared with a 
> _Noreturn function specifier"

Oh, that's indeed quite a bit more explicit.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 13:28:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 13:28:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006858.1386110 (Exim 4.92)
	(envelope-from )
	id 1uNAeF-0006oy-AZ; Thu, 05 Jun 2025 13:28:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006858.1386110; Thu, 05 Jun 2025 13:28: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 1uNAeF-0006or-7Q; Thu, 05 Jun 2025 13:28:47 +0000
Received: by outflank-mailman (input) for mailman id 1006858;
 Thu, 05 Jun 2025 13:28: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 1uNAeE-0006ol-HO
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 13:28:46 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on2060a.outbound.protection.outlook.com
 [2a01:111:f403:200a::60a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 005a1ea9-4211-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 15:28:43 +0200 (CEST)
Received: from BYAPR08CA0044.namprd08.prod.outlook.com (2603:10b6:a03:117::21)
 by CH1PR12MB9575.namprd12.prod.outlook.com (2603:10b6:610:2ad::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Thu, 5 Jun
 2025 13:28:40 +0000
Received: from SJ1PEPF000023CE.namprd02.prod.outlook.com
 (2603:10b6:a03:117:cafe::6a) by BYAPR08CA0044.outlook.office365.com
 (2603:10b6:a03:117::21) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.19 via Frontend Transport; Thu,
 5 Jun 2025 13:28:39 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ1PEPF000023CE.mail.protection.outlook.com (10.167.244.10) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Thu, 5 Jun 2025 13:28:39 +0000
Received: from localhost (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, 5 Jun
 2025 08:28:37 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 005a1ea9-4211-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=QNwJlTdZhHkTo3UpTxYLZcMzrg8ohqmLO4A+x77NTmVpwSSILXA+Vwk2ecFiZMyqIsXGZ/1qxiion4yMRHfS6yDEEsNX9XvelwM2y3Rqy+rz2Zn8DLi79FdiXFVnVMb4OSwE75OER4n2r/pa7olCGOsLuj80Y0LWQ4QZ2QrYwzkS/hooVSDzGYATwAa2XqWxQwSchPk+c+a2VpQPL+PRGwAKsP+EpB3Hh+SerbmO9oiHYy3TW0oxCq8ETkb9zwMvYZQhNlfEspAEx55PJL4x9R9w+nDYwvWtXXJwlj2ZKntl5awxx9Wk/LyP+QQXhuDfZ8sMU5rSHUWZhouZhbK3fA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=/VFP+JQWBL2kdZ1IWem3gLR3G5H2pW8T/1NTwF2lUS0=;
 b=uoKisIqG0epDBdhUYkmeCsh++FbHo+Qy2BsOCnIJN3tZTWuBoprF5WkNMjJ18N+YWePO8MEBHukGnvbwBXkB6XExBDZm2DncEJkTBrN8NosQNHfD/NblGoCRcwxJgwb80frd27tJjNp+41yJoqnDlClCrHFmi447iDnElNZlsyKnM1Q7L5cYH7tQu+pZMV4JckZii3zQHmafrbmlEy4estKNdK0NDtITnoOaJWOZauuXNUG8Lt2iemd4lJzX4AVa7E6DLuZstMRRIYUZ4qHtb8SR2p/YNF8Hzax+kNzWuwGq3rzHSKe9po8keHFAs0HHWDvbGJ1wscYBj0c9WNK/qw==
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=/VFP+JQWBL2kdZ1IWem3gLR3G5H2pW8T/1NTwF2lUS0=;
 b=1RXpQGViKBx/BJzSgm0ymrCN5i8UNYwmvc1luq+cMqIZXZC8PeFTNo4vAMI2ZaJarZdHnvXn0a/QVl3gBe/pI+dneG8JoStYkMg0IrifoVArC00tOnMek8zZnlZAqfveR67Hjf7r4zj0TCL7s8RKWFFj2lor+5QgWIIS548Kp3o=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 5 Jun 2025 15:28:36 +0200
Message-ID: 
To: Stefano Stabellini 
CC: , Julien Grall , "Bertrand
 Marquis" , Michal Orzel ,
	Volodymyr Babchuk , "Daniel P. Smith"
	
Subject: Re: [PATCH 05/19] arm: Remove dependencies with membank(s)
 definitions from setup.h
From: Alejandro Vallejo 
X-Mailer: aerc 0.20.1
References: 
 <20250530120242.39398-1-agarciav@amd.com>
 <20250530120242.39398-6-agarciav@amd.com>
 
In-Reply-To: 
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: SJ1PEPF000023CE:EE_|CH1PR12MB9575:EE_
X-MS-Office365-Filtering-Correlation-Id: f6f54999-ac11-4c5e-5238-08dda434e261
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?UGJzNkhrYmcvMG8zY2hnVExFVHh0bEZzTUpYbEd5Z2VkT3dON0doNGVIN2Za?=
 =?utf-8?B?d09uSFBtNTdLTGFVK1FYZGt6VXZSbFlkMGFRM2xRY2FocFBidzI4eHM3Ri83?=
 =?utf-8?B?Y05pbzFmZVFXZWFBVTJwN2dMQXlrcTRUZFgycU45OUowTncrb25qTW9sNjdn?=
 =?utf-8?B?ZkhsZmxEelJiRExycVF2Sy8yZ1FOZ0JpRlhiMVBLQUNQNzVOTys3aldtWDR0?=
 =?utf-8?B?d054QnFEUmlLL1NWT0J4Nk9GRnNiNllNcFZpM2hEalJYc0RVbGd4RzYzQjRR?=
 =?utf-8?B?ajNRTWRDMHNCNnVsSU1WQkMvalpxbDUxVFpVbUVvck1RQWhoQnVReFdiSkFC?=
 =?utf-8?B?RmtkNWVWeWQwaTBDWVBxL1RqTVRzZnhCTk94cDJQaUQwVTNlRVk0OTdLUkVS?=
 =?utf-8?B?c09TTnlFV0VLb1hsR3d0RUVtNmpTdmpxNVhKWDNiQytNMWFVYmM5eXBTNFlr?=
 =?utf-8?B?Z2hyNDV2Q1JUbjUwRHpZb2p4SkxtVy95TVJ6ZXlDclhUTWdmckV2SytlNjRV?=
 =?utf-8?B?MkRVNURsUzY4bXVaUmswNUZwRTNGeDBwczBHN3VwdEZZNFFNOHFTMmtkTjlL?=
 =?utf-8?B?aVlLU2ZnSHdSd0QxbTJJSWhBOFNVN1VsNUNxY3NwOWhaU05HYWc5dDNGTUZD?=
 =?utf-8?B?NFdFUTdZdVBXcExkWFlDcVZSeDF2MHE0dHlEOGVINDV3ZlphZDh5STl6c0d1?=
 =?utf-8?B?QlpvNHptTWhIb01TbE5wNHhUcmt0di9aSmFRTVNOMUFBS0ZCWjJRNmdDRlFI?=
 =?utf-8?B?UDJ1YmwxY1lSZDU2K2tjaHZxWE1GUGc4R2VOQXNheE1aWVpzblUwOUhxNFFH?=
 =?utf-8?B?Z0lldmRFc2pHUDI2ZGtMT3A1d2g2Z0g2QlFEckhUQWdxWWZTQ1hmZWVDa0NU?=
 =?utf-8?B?MzRyRTVlVWdoVTV4cy85eDhJUDNLWHE5RjBQL0tUUFVjQ0ZGZFNyalpGT2JI?=
 =?utf-8?B?WWkyaFN6N2hlNXZGV0YvN2Z1OFZGWXVsZ04wU3llOUp3Q25sSlQzS1BjTS9U?=
 =?utf-8?B?UGJuZ2x3RXVwNG15VnRXMU41Qm9MbXFUV0xybzhBVGF6ZXRxazBpR0JSQTV5?=
 =?utf-8?B?a08yVnA5d1hlbVRHM1NRWUpiajM0R0F5bkUxWTB4MXRrRVNhQU9jUDF6c3pX?=
 =?utf-8?B?STBYNGF4bkJXR1loTUo4K0YrbmoyeUNhSWMvd1FkNHlXK3paZlM5dFdQc2F0?=
 =?utf-8?B?UTR4bFlxS3kzN2RxTWN6bjMrUENmcGY0ODNCVWlMbUxTVnBEcWdjNUtOeHJV?=
 =?utf-8?B?VWNNZkdpcXB0MXIrQnJWV1FEM0VmMVJQS0JYQ2VraGFBd2d5ZCsxUUx4VFBo?=
 =?utf-8?B?dUxtVzIzM1JLQTgvNHB0eXA0VVdpOXJSU3E0LzlDWjl0K2lQeDljaGdmcWJY?=
 =?utf-8?B?VjUyVXVsbHpVU1NYKzdNelRYTFFLVy93UzdJVlk3Q01RMVVLOWNTaVl0aHBt?=
 =?utf-8?B?MENQZmtIQmJyc2hYeE9XL1BqNW1RaDZHUG9qSFF3VmwrT0JHQWN5Tk1UdWVG?=
 =?utf-8?B?bUZKM3JlTXNFMkNSK1hFZUt5ZFVKbkdVaHo5UC9YZnJhK1BtTHlQclZWc0FL?=
 =?utf-8?B?TmlwY0hCYm5salBmWmRtR1BtUlZXTVFtd2Jsdy85YWlDczdGU0pENVROZjNj?=
 =?utf-8?B?bVc1QWlwL01oSWQySVd2SW1GVnFSZWoyUGZFU1YyTGpmNXpSMnVtelFjZ1FO?=
 =?utf-8?B?bmx6bHcyMHgyeDFQZm5VV0pJVUVkT1YrQW81c1NtVlRLMjZscWRGbHBnenZs?=
 =?utf-8?B?dGxmZVNUR3VjQ2tWc043blErOVNjSm1TR0QrbFpZSEJXZUNBbjY2M2pZTlk4?=
 =?utf-8?B?T3dONzgwVVdLN3Y1VGxzTUtqb1VJMW9zU3llZVNmeFc0WUd1OXR6UWZmMnhG?=
 =?utf-8?B?OU5ERm9pREYyT3BKTDE3ME1veWRVcGZVOHVnZU9EcW9IbEV5VzBjSnNqdkl0?=
 =?utf-8?B?RTl5VURDRmZ2Tll0SjNRS0ZJN0dPVGtOY25wdGxGWDVYVVlmNExjbnV0YW9x?=
 =?utf-8?B?d0llZEVNaDYxaWlzRy9RK09qRGV0QzFKdnB0Q3kvSGx6NnpucFRLRHFiT3pC?=
 =?utf-8?Q?8U+l8x?=
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: 05 Jun 2025 13:28:39.8488
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f6f54999-ac11-4c5e-5238-08dda434e261
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:
	SJ1PEPF000023CE.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH1PR12MB9575

On Sat May 31, 2025 at 2:51 AM CEST, Stefano Stabellini wrote:
> On Fri, 30 May 2025, Alejandro Vallejo wrote:
>> ... as they can be forward-declared changing arrays for pointers in the =
function
>> declarations.
>>=20
>> No functional change.
>>=20
>> Signed-off-by: Alejandro Vallejo 
>> ---
>>  xen/arch/arm/include/asm/setup.h | 10 ++++++----
>>  1 file changed, 6 insertions(+), 4 deletions(-)
>>=20
>> diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm=
/setup.h
>> index 6cf272c160..0f9e531a34 100644
>> --- a/xen/arch/arm/include/asm/setup.h
>> +++ b/xen/arch/arm/include/asm/setup.h
>> @@ -3,7 +3,6 @@
>> =20
>>  #include 
>>  #include 
>> -#include 
>>  #include 
>
> This change breaks the build on ARM:
>
>   CC      xsm/xsm_policy.o
> xsm/xsm_policy.c: In function =E2=80=98xsm_dt_policy_init=E2=80=99:
> xsm/xsm_policy.c:71:30: error: implicit declaration of function =E2=80=98=
boot_module_find_by_kind=E2=80=99 [-Werror=3Dimplicit-function-declaration]
>    71 |     struct bootmodule *mod =3D boot_module_find_by_kind(BOOTMOD_X=
SM);
>       |                              ^~~~~~~~~~~~~~~~~~~~~~~~
> xsm/xsm_policy.c:71:30: error: nested extern declaration of =E2=80=98boot=
_module_find_by_kind=E2=80=99 [-Werror=3Dnested-externs]
> xsm/xsm_policy.c:71:55: error: =E2=80=98BOOTMOD_XSM=E2=80=99 undeclared (=
first use in this function)
>    71 |     struct bootmodule *mod =3D boot_module_find_by_kind(BOOTMOD_X=
SM);
>       |                                                       ^~~~~~~~~~~
> xsm/xsm_policy.c:71:55: note: each undeclared identifier is reported only=
 once for each function it appears in
> xsm/xsm_policy.c:74:22: error: dereferencing pointer to incomplete type =
=E2=80=98struct bootmodule=E2=80=99
>    74 |     if ( !mod || !mod->size )
>       |                      ^~
> cc1: all warnings being treated as errors
> make[2]: *** [Rules.mk:249: xsm/xsm_policy.o] Error 1
> make[1]: *** [build.mk:72: xsm] Error 2
> make: *** [Makefile:619: xen] Error 2
>
> The rest looks OK

I see what goes on now. Later on the header shuffling fixes this breakage (=
somehow).

This is very much non-essential. I'll drop it for now and have another crac=
k
later on after the patches I do care most about get through.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 13:31:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 13:31:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006871.1386120 (Exim 4.92)
	(envelope-from )
	id 1uNAgx-0000Eu-NO; Thu, 05 Jun 2025 13:31:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006871.1386120; Thu, 05 Jun 2025 13: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 1uNAgx-0000En-KJ; Thu, 05 Jun 2025 13:31:35 +0000
Received: by outflank-mailman (input) for mailman id 1006871;
 Thu, 05 Jun 2025 13:31: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 1uNAgw-00005M-TX
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 13:31:35 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20605.outbound.protection.outlook.com
 [2a01:111:f403:2009::605])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 641b5431-4211-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 15:31:32 +0200 (CEST)
Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
 by PH7PR12MB6563.namprd12.prod.outlook.com (2603:10b6:510:211::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Thu, 5 Jun
 2025 13:31:28 +0000
Received: from PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264]) by PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264%2]) with mapi id 15.20.8792.035; Thu, 5 Jun 2025
 13:31: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: 641b5431-4211-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=hfby94nD+xuzNuZsYKFmeJ+SYplMO31SpfDn36ERJx3Qqos9Qpox1p1B7h/7uQ+5tWKrwsL8SQV6gtvM1rUmtl/eJs0sptdSLzvKMThKToquYfg8Z62YiRAR9PfOwIfO2RsUrUnlRl4IHVs0uojgwGezFTTCKi40OqL62iMgP1/WVss0MrXp3Y4jpgvr0qZ8bse72reIiaks0xHcmg/TakBYtZeibOBN0yvZINaOi+dBvUuhQ7NiF3O8Q80dxS+xQUJXYcK4x16qfj/mBw8qMGGUzmR+PXQhKakrUrVMUL5OtqlljLs80LMt4n2nT7clXsfoMf7luFLBec7a0Iew5Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ZL4seLeWizooK8DSDORy29joCdvoLteFXGH7nIHNwD0=;
 b=DOMVBNtDBINYbjm89RJvWxMd4lYmbPeT3Rg85tUrj7480W2HdrblEER6187rb05nnesI3StiDwUHBrNt0ZfqVW9rEwUUT8b2mpbneZHb0B42pHq6y7j3v7L+mQddPA2v57BtleCVIaye3itspbjLnaSBBwetqMeiViRNGJVIdnAztwYQcYOCegiZl8EIovNDZA2VOJNZq3ylAArbvmmsScLmsTUQfSwP259hPsW6c3kZlDnBAS59Vgi4DvzqeKQQk/SotFupeM9yVEXAUD0n86IEP0f1CePkr+3wHjD46OATqX3Y1spSPs+sRm6ds8e4pD7rW3dJpFdWwIBcR666EQ==
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=ZL4seLeWizooK8DSDORy29joCdvoLteFXGH7nIHNwD0=;
 b=fikVJoGYY5C3eI+CpCvEG15+int9RPfZSv/JUuMQm3G7o/2fcYOPm4j0E1nytrWIjJTIuOPDACDkW4WzqEZnoRQVxZISaxDFF85KzuowLR7EC1jSgVVgykpFxeaadMij5s8mnWJLjpFkh1mkKwfXkktJ/WxnV9txCKQgspioqIA=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <3857c1c8-0abd-4058-a355-9c12ab08ad3c@amd.com>
Date: Thu, 5 Jun 2025 14:31:22 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/3] arm/mpu: Introduce MPU memory region map structure
To: Luca Fancellu ,
 Ayan Kumar Halder 
Cc: "xen-devel@lists.xenproject.org" ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: <20250604174311.754899-1-ayan.kumar.halder@amd.com>
 <20250604174311.754899-2-ayan.kumar.halder@amd.com>
 <154A0263-6E4D-4855-9408-ED31F45B293F@arm.com>
Content-Language: en-GB
From: Ayan Kumar Halder 
In-Reply-To: <154A0263-6E4D-4855-9408-ED31F45B293F@arm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: FR0P281CA0234.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:b2::18) To PH8PR12MB7326.namprd12.prod.outlook.com
 (2603:10b6:510:216::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|PH7PR12MB6563:EE_
X-MS-Office365-Filtering-Correlation-Id: 29252b29-5ef2-4452-c548-08dda4354602
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?cTNkYWZaOElvb2xrdWFRWHVyS09kajY5K2lBYzVZU0NJRzJzMVlnQ3M5ZW1M?=
 =?utf-8?B?TkNwakNtVTJPSFR6RG1DTlJWZHd5TThkdmdFY2dPSVYvTUh0VVRJREZtMUl5?=
 =?utf-8?B?M2k5Q2NIbXRhZ0RlREdKbUdsYWV0WnQ1VXFVR3BSN3poV1lxakhKeWh3R0JQ?=
 =?utf-8?B?a2F5cGRnRGN1Yk9zWmF6cHVkVG9UZWkxM0IxRlF2SXJhRlJVakZPdWtxbXBL?=
 =?utf-8?B?WGlJQWVaRFhZMitHNisyUnUrT2Nkc1llRjYveXhnRVVDRUxkVHJod2pWVTNT?=
 =?utf-8?B?Qi9nR1Q3eGpROGoyaU1kOHhUb0F1cVpYejJYd0ZLTmU4UmxLZXdGWGMzOTNt?=
 =?utf-8?B?MEFvWUNOQUcwbm40N005L3NtR1hFb0ljYnc3Y0JnT0t2SkNhMUN2T3dQM0Uz?=
 =?utf-8?B?SmdPYnBvSW8wTnAxeFFuOFFaNytFY0Jzd29kMlplUDRTRng2a21KMnF5RTdY?=
 =?utf-8?B?eGJPVi9RV25GTnpJUTZDWkl2dm1ySCtoM3JNeDZkS3VyWHUvdnVGb2hXejh2?=
 =?utf-8?B?TGJRZmRKNkptWTZyNTZUczlVVGdJOGtZMDFaZjkxY3hPN2hhZjNHZFBqOURE?=
 =?utf-8?B?SEk0NWg2aU56MjVnT09SUUpBVzEwaldWVzc2Wkk2SVlmRk5adW5JbldqNHpO?=
 =?utf-8?B?OHA5amNDKzVIRE1zR21HMmt2eUI5MFFmaktlVW1YeGIxV0U5c3BSWGR3Skp3?=
 =?utf-8?B?d01SSDZIbVVYRmNqMGNJeHNjd2xsZDdUQ0Urb3lXQlhxSzJPOENXOTJJNHVD?=
 =?utf-8?B?VDdxNTVVTzF4QnZia3dUMmZLN3VSQTU0OVJoZDR0OW52KzhFQUMvSjFPRGdt?=
 =?utf-8?B?bUgxdGVTU2U5aUVrMFo5Ujg5TlNZdUU4MjZ6N0xIRm5OM29oRWE5OE82dStH?=
 =?utf-8?B?WkxhZlBLdkpZeEpDRTY4cm9tVHZZWTAxZzhMUFE5VFFKMFVlRzdkQUdEenls?=
 =?utf-8?B?OC83VjZ6UGZWa2NEMVdLS29ZZzJ3VXZoR0x5VFBoVmg2TmxKQkV2TjZwUHkz?=
 =?utf-8?B?T0dpR205MWcyRGdWRE9YZDBKUjN4N1FSOXc2Q2FleEl6L244QkpVSGxFR0lP?=
 =?utf-8?B?d2oyYzJNc1lwenEvSVdiWmFwUWplY2ZmdzJ4bjVwcUdyQnBvQWpnTkRBS0Rn?=
 =?utf-8?B?OHVNVEcrbEpEYVJyWExpUnkxaEl4SEtuR3h6Q05ZQWxkc1ZhSkR3bE5mVk5H?=
 =?utf-8?B?QlBmbWNzeWZsQmN0TmFhMDlmVSs0a082Y0ZJSHVUU1FJclBGUWlBRWpTUER4?=
 =?utf-8?B?ZWd0RFJhVURxd0FuSStBU2xMc3IvMG5wU3RTM0FLQlRjM3kvR2ZVWmc4T3JG?=
 =?utf-8?B?eVlHVVBJQlFtMHBRUkphUWlUZElNaGtaUDltMldqS1B3cTA3R3pQVVNWUUdk?=
 =?utf-8?B?WDBLcXh1dTRMaitjdG0rMkhpeUlicG5DdHU0TWFFK2UyOEc3eWY0OCthR2tv?=
 =?utf-8?B?WmtwN3dIa2NjbmZoWE0zN3FBYnNkQmg2RXBLYkh3OW9SbGRPdTg0Y1h2dTJE?=
 =?utf-8?B?UVZuMUtsblRtcmkwaTUwdzlrOTczY3l3VXpFRFcrelpJY2wwVDlTcEJjd1p0?=
 =?utf-8?B?anRQanJRbTFBTE9zQkJEMEpMOFdtT2JtOU4wKzJmdlBsbnBaOWpFcDdvSVRJ?=
 =?utf-8?B?cUZQekM5TDdWRm9tWHppZHUzdjFVWk5HS05VUFFpanl5bFV2QTUvRTlWaEVz?=
 =?utf-8?B?L1MwUjV2ZlRLUm1uczQ1WGo3a0VmSUZIc0F3VXFCeUZuTVduRlBHRHFtWDBI?=
 =?utf-8?B?SnVnSzdZcXpNeTJScFFFUnVzOHZpeERDSWN4Y0pvaWt3NDZCNTYxYlFXbUpi?=
 =?utf-8?B?aFBxclB3ZlV5aSszdHVBQmQvOWJ4cSs4Wjk4blFQQmV0a01aYXI5VnJwSzRY?=
 =?utf-8?B?NWFWZXEzK2Zmd1VnVHB5d24rZUhMckQ3QUtnZUpFVFFaVXZTSldDUnhobXVl?=
 =?utf-8?Q?SUebr6fLjIY=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)(1800799024)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?SzJRTkg2QmJhblE0MnFIaEVqVHM3L3BTQlVZd3gxcVovUTRYcVU4eDl2Mk5y?=
 =?utf-8?B?WlM2d3BjUzZua2hnSlFvaGVEL1c2aUtaN001c1FlZ2lrdDdrNDI1WGVxQUcy?=
 =?utf-8?B?UkIrdWJScURoQjhmZ1dWNlZBUEROK3VsT0o3MGJTQkF4OSsrYVRRU0xFblRL?=
 =?utf-8?B?RXNESU0zc1doWHRKUjFIclRydWthWHlRNWZOU1MrWHErcTdGZ3VSbjdUTUJN?=
 =?utf-8?B?VElWNVJvM1hwVmN5ZEhwWXNJdkNoeXBPT0poU3BmVWg2TEd3dVFxb05wa0xj?=
 =?utf-8?B?SldOcTY0RVFFUzBOeTdUdW1Kcmw0UjNiNzgxZ09xcjgxNlpCN0UvQURoVzJz?=
 =?utf-8?B?d2NXMjk0cFNqTjAweWpldlVPVkh4Z0wyTDk3WW9SNHNEWUhLUk1uTGhLVnd2?=
 =?utf-8?B?SzFiZkNPU1FIZEVuZS9FTGN5dlI5UUxySGNGUTJFS2tvZGRnQzVOQUUyK2VT?=
 =?utf-8?B?S2I2dkczN2NIcUhqRVJuUC8zclRaZklQNzFLZUJCb3dPRUROd3MzYks0clB2?=
 =?utf-8?B?Y1ZVWFRieEFWYWdKUjN1NXNhc0RoS0x3K0hQUUVjTkpONGxxY3VMcE85b1lW?=
 =?utf-8?B?TXFFY0NVUVhxMFlkcTJQNWdNQ3lob2paUUM5Sm14QjZudVlCWXZCaHI0YmhD?=
 =?utf-8?B?MCs3c0I2QXd4dlVTN0VlV3ZBRzkzc25sdWd5anArMzU1UngvS3VhOERKSkQ1?=
 =?utf-8?B?QitvT3IvYjB5ZUwvcHcxRTc0OFVyc0d3dldSRFYwYkZhMCtvbjhmVDB5T0x6?=
 =?utf-8?B?YXI0U28vRmFweXRqSHViWW12dFFuMnZvNHV5Qjl4UkNiMXVIOEI5ckJjRll0?=
 =?utf-8?B?UkRLOVRiNTE0aVlXelE0TTIzV3o5aE0wbzlJSlRST0Nyb2NOM2w0Z3dSV1J4?=
 =?utf-8?B?TnN1ZU5IRllJN2dVaE5tN0xXSW8zZGdBWlc0KzdqYldqMTByazBPMVdaa25a?=
 =?utf-8?B?aERIYWN3Uk9CclI3dDFyS2JwdXo4RVUzRVJNQysxZWhpWUtQaHRIMDR4ajJp?=
 =?utf-8?B?TkM2aEsxSWpnNzltSnJkU1pIaXhpM2dVMjM4ZHZMRytwNnZOYlphaUNLbVl6?=
 =?utf-8?B?VmZCS2F4V2ZZbC96MEp6N1JRcXgwVHY4R2F1eHk0ZFZJY2hURnM1TnRaZlFC?=
 =?utf-8?B?c0c0L005amJhUEhWUUowM24xT1V1b28rVXplSStVT1dDUGRUQW5CN3VSQnp1?=
 =?utf-8?B?a1NNTmJZWklKdnFISnl4WW9QWFU5eXY0Qm5GSUNlS0NkRXQ3NEo3T00rVURM?=
 =?utf-8?B?aS9lUXVWR2srbHZ4cmxmbEdBa2dZcThYOWhBc3BHb1R4ald1N0RLaU9iRnIr?=
 =?utf-8?B?RTA2aWEzYXNKekh3aUhqYU1YVndIZ2FESzg1L2pIeXIxeXMyVzRQN1cyLzZB?=
 =?utf-8?B?LzRFMlJmaUVtYnJ5OU5samVYV0ZSdmRrYVNjMCtYaW5qYXFXSGtPRnVzdm8r?=
 =?utf-8?B?MXNHSm9LYzhET1Vod3VPVlh2WHBsbWdqS3FFWStlRFVZNzl3SE9nWEp1WW1q?=
 =?utf-8?B?RlpZZHlTSWROMU1ZOWkzOE84Qkp5Yi92Tk5DOThwZkVqL09rRGgvdW5QZm9u?=
 =?utf-8?B?d2JkaFB5M3gyM3ZrbnNjelJpN0I3Z2QvVFNsNEhwNE10bElhbllLYzNaQmY3?=
 =?utf-8?B?N21GaUdWOGY5dVhaSEl6T01KZXhHK1VRQldtOEF4c2E3NXBlT1RLUXJXb0pH?=
 =?utf-8?B?VWJoYi9tT2swamtaeVBYdnp4d21vK1MzL3hZR1Q4UW5GRVNOWDNuZlVFNHI0?=
 =?utf-8?B?bTFUUWFlNDM3UHRWQ216K2x6ckdFUURLeDE5ei8vNHYxOExQZWg4eEVMUmVs?=
 =?utf-8?B?NXV6Skd1L0tLdWJ2dE5OUGMrdExEb2NtS2s5aWJtRFJQMTc5dUxJN0FneXRx?=
 =?utf-8?B?c0hzQWdyY2tqQnNWRHFHU2Zrd2EzVkVaV29jSGY5QVpaS3gzaGRqNHBVVzNy?=
 =?utf-8?B?S1h6aC9mOUczSENHQUx4OEpnaTYvUTZDWSs0TkMzWVlNdTNXclh4MnRXN2VB?=
 =?utf-8?B?aUpKV0dITWJRT0lsRHFDbHFYQ1ZEbkFzOUlSODJmQ1dNWmRzUnJZWlFwei8y?=
 =?utf-8?B?TTl5SElVbkNDT1I5RnRITmFNSzBDOUdOZW5PYW9KZ2tMbktzLzhtYmFpNEYy?=
 =?utf-8?Q?bqZJc0JwXTyq3NgRFKRnp7q9E?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 29252b29-5ef2-4452-c548-08dda4354602
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jun 2025 13:31:27.5389
 (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: z3GLBuIxjTUtYNj5D2Htq524iS+o7FsUHd11T7rgdVOr8wE/I/NQj7PLxZMRfgSLPg3fd0Z5/QFQgF6jvkTeHg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6563


On 04/06/2025 20:19, Luca Fancellu wrote:
> Hi Ayan,
Hi Luca,
>
>> On 4 Jun 2025, at 18:43, Ayan Kumar Halder  wrote:
>>
>> Introduce pr_t typedef which is a structure having the prbar and prlar members,
>> each being structured as the registers of the AArch32 Armv8-R architecture.
>>
>> Also, define MPU_REGION_RES0 to 0 as there are no reserved 0 bits beyond the
>> BASE or LIMIT bitfields in prbar or prlar respectively.
>>
>> Move pr_t definition to common code.
>> Also, enclose xn_0 within ARM64 as it is not present for ARM32.
>>
>> Signed-off-by: Ayan Kumar Halder 
>> ---
>> xen/arch/arm/include/asm/arm32/mpu.h | 30 +++++++++++++++++++++++-----
>> xen/arch/arm/include/asm/arm64/mpu.h |  6 ------
>> xen/arch/arm/include/asm/mpu.h       |  6 ++++++
>> xen/arch/arm/mpu/mm.c                |  2 ++
>> 4 files changed, 33 insertions(+), 11 deletions(-)
>>
>> diff --git a/xen/arch/arm/include/asm/arm32/mpu.h b/xen/arch/arm/include/asm/arm32/mpu.h
>> index f0d4d4055c..ae3b661fde 100644
>> --- a/xen/arch/arm/include/asm/arm32/mpu.h
>> +++ b/xen/arch/arm/include/asm/arm32/mpu.h
>> @@ -5,11 +5,31 @@
>>
>> #ifndef __ASSEMBLY__
>>
>> -/* MPU Protection Region */
>> -typedef struct {
>> -    uint32_t prbar;
>> -    uint32_t prlar;
>> -} pr_t;
>> +#define MPU_REGION_RES0       0x0
>> +
>> +/* Hypervisor Protection Region Base Address Register */
>> +typedef union {
>> +    struct {
>> +        unsigned int xn:1;       /* Execute-Never */
>> +        unsigned int ap_0:1;     /* Acess Permission */
>> +        unsigned long ro:1;      /* Access Permission AP[1] */
>> +        unsigned int sh:2;       /* Sharebility */
> Typo: Sharebility -> Shareability.
Ack
>
> Also, from the patch the comments feels not aligned, is that the case?
When you apply the patch, the comments look aligned (in the codebase). 
Does it look the same for you ?
>
>> +        unsigned int res0:1;     /* Reserved as 0 */
>> +        unsigned int base:26;    /* Base Address */
>> +    } reg;
>> +    uint32_t bits;
>> +} prbar_t;
>> +
>> +/* Hypervisor Protection Region Limit Address Register */
>> +typedef union {
>> +    struct {
>> +        unsigned int en:1;     /* Region enable */
>> +        unsigned int ai:3;     /* Memory Attribute Index */
>> +        unsigned int res0:2;   /* Reserved 0 by hardware */
>> +        unsigned int limit:26; /* Limit Address */
>> +    } reg;
>> +    uint32_t bits;
>> +} prlar_t;
>>
>> #endif /* __ASSEMBLY__ */
>>
>> diff --git a/xen/arch/arm/include/asm/arm64/mpu.h b/xen/arch/arm/include/asm/arm64/mpu.h
>> index f0ce344e78..df46774dcb 100644
>> --- a/xen/arch/arm/include/asm/arm64/mpu.h
>> +++ b/xen/arch/arm/include/asm/arm64/mpu.h
>> @@ -34,12 +34,6 @@ typedef union {
>>      uint64_t bits;
>> } prlar_t;
>>
>> -/* MPU Protection Region */
>> -typedef struct {
>> -    prbar_t prbar;
>> -    prlar_t prlar;
>> -} pr_t;
> I’m not sure I would do this, at some point there will be the transient flags and p2m type
> and we know arm32 will need to store them in pr_t as additional members, instead
> arm64 will store them as part of prbar/prlar using the not used space (without writing them
> in the HW registers)

Ah I see. Ok, I will keep them separate as it is.

- Ayan

>
>> -
>> #endif /* __ASSEMBLY__ */
>>
>> #endif /* ARM_ARM64_MPU_H */
>> diff --git a/xen/arch/arm/include/asm/mpu.h b/xen/arch/arm/include/asm/mpu.h
>> index 8f06ddac0f..c8573a5980 100644
>> --- a/xen/arch/arm/include/asm/mpu.h
>> +++ b/xen/arch/arm/include/asm/mpu.h
>> @@ -25,6 +25,12 @@
>>
>> #ifndef __ASSEMBLY__
>>
>> +/* MPU Protection Region */
>> +typedef struct {
>> +    prbar_t prbar;
>> +    prlar_t prlar;
>> +} pr_t;
>> +
>> #ifdef CONFIG_ARM_64
>> /*
>>   * Set base address of MPU protection region.
>> diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
>> index 86fbe105af..2fb6b822c6 100644
>> --- a/xen/arch/arm/mpu/mm.c
>> +++ b/xen/arch/arm/mpu/mm.c
>> @@ -167,7 +167,9 @@ pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags)
>>      /* Build up value for PRBAR_EL2. */
>>      prbar = (prbar_t) {
>>          .reg = {
>> +#ifdef CONFIG_ARM64
>>              .xn_0 = 0,
>> +#endif
>>              .xn = PAGE_XN_MASK(flags),
>>              .ap_0 = 0,
>>              .ro = PAGE_RO_MASK(flags)
>> -- 
>> 2.25.1
>>
> Cheers,
> Luca
>
>


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 13:34:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 13:34:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006882.1386131 (Exim 4.92)
	(envelope-from )
	id 1uNAjl-0000s8-7T; Thu, 05 Jun 2025 13:34:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006882.1386131; Thu, 05 Jun 2025 13:34: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 1uNAjl-0000s1-3U; Thu, 05 Jun 2025 13:34:29 +0000
Received: by outflank-mailman (input) for mailman id 1006882;
 Thu, 05 Jun 2025 13:34: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 1uNAjj-0000rv-G4
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 13:34:27 +0000
Received: from AS8PR03CU001.outbound.protection.outlook.com
 (mail-westeuropeazlp170120005.outbound.protection.outlook.com
 [2a01:111:f403:c201::5])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ca2ff987-4211-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 15:34:22 +0200 (CEST)
Received: from AS8PR07CA0059.eurprd07.prod.outlook.com (2603:10a6:20b:459::28)
 by VI0PR08MB10539.eurprd08.prod.outlook.com (2603:10a6:800:208::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Thu, 5 Jun
 2025 13:34:18 +0000
Received: from AM2PEPF0001C70E.eurprd05.prod.outlook.com
 (2603:10a6:20b:459:cafe::18) by AS8PR07CA0059.outlook.office365.com
 (2603:10a6:20b:459::28) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.8 via Frontend Transport; Thu, 5
 Jun 2025 13:34:18 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 AM2PEPF0001C70E.mail.protection.outlook.com (10.167.16.202) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.29
 via Frontend Transport; Thu, 5 Jun 2025 13:34:17 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com (2603:10a6:5:1c::25) by
 PAWPR08MB11086.eurprd08.prod.outlook.com (2603:10a6:102:46e::20) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Thu, 5 Jun
 2025 13:33:46 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668]) by DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668%2]) with mapi id 15.20.8813.018; Thu, 5 Jun 2025
 13:33: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: ca2ff987-4211-11f0-b894-0df219b8e170
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=PPb7bnSttIdbohfTvbfdFpEOvrBIKorZ+JutjycGyHauBdQTTuL3dulnit5k2+i5tv03QYDmwXdD1x1B8T6X0yPTSBiUxWf/cRGvWBWejzO7dhqjDTfjnq+6uW3rXvQ1yV4rQCA8KLqWcdF3WN4PhPRTglTMj81UUweHmm2yg8urNkjpn4X0old7VYYLJfe0QgN//yPhe3etsEO9PTEDbbf9+RyKlwJ/hngwH6AamaW36o1+JvfIGGT+0RDWlZxxTIwiIbODLnfaKTUwpKM14LC19GlMN3VVJASN3MqvUx3QiaEpTBeeQdqhfy2JhBCzy5+SxJZlUWz1ohAaBuPa3A==
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=pmKQvjwyH95o+2UdOedf5lPpQ0hP/Us2XZHP0WIppeA=;
 b=lSJbiyAfAkqY9OF09sbVRXeNDpdywgzKT8VUt9296xExw1ysJsNxQA1hz2jpfjImVfuV5zRn96c+zMvgmtYXmteJAgd8mAWyy4nLrTanYdDYB24PAZ0C16mdDoK82Et73NAkIJqQ8dpX0/9nA3pji40UXSDCSzpJsSwSfYKQAHqjACMn0qPIIZOLby6wr7Pcfcxzc3SrKJHfjKinvvoDeqPHPqI8PcMNj9PnR5/XDDCF7fbxYZ2W7T20HJbpcPIkRoxkVHvnKmpfR9xdjqwQ2GLviHX0cs6bulxrJD5v+FSgnUsPZgTbVVdXJVGKHJmxffv2UGWEIwSW1scmKyqb+Q==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=amd.com smtp.mailfrom=arm.com; dmarc=pass
 (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
 (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=pmKQvjwyH95o+2UdOedf5lPpQ0hP/Us2XZHP0WIppeA=;
 b=h9QeRv/38bIa7vTt/JwqCXwp7q8q94fSDmOnKV2ECule6xxDCgAnW7924SD3Tb1Xl1LVtUXQHhn5Jqlgxe9Z49GLafvsuZ/xE6hBjGzzItWjVisRocRKCDffzdjJ2QoAY5ebj3YdHxoDCgcRHDiIuLjsggHUGSGdqy4GR5FFCLs=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=O4HFecs9ktR/tsMNJcdK8GH7BdZDLCBVVw1E+X/5SDl6o5NbBY+wa8lKRyBPSHv0W9w+OcDuWrop+hgm44f5gpRClni2pD1OEBsDbcCz0+D4+7zjg8mFoux2y/xG3LvQSWxXDJOl2UYnSLh8esEsL2THgpl4fy98TYB2MEGGmgyC7HKdLAIaOZ8XqCjoCsw3dpte/T9fg8pLG4bFD3vlEY0sTLoISvqJRZ3el+0HQcMne6rbL9QQERwCbNRRVPn0eJ5sSZJ1H6k9R47cJzZw/pJm0x7kvO/lKL2AKRWgvOTMszNW5U9PelvY+kEvfX29shf15WFhEp5jLC/9Tz588A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=pmKQvjwyH95o+2UdOedf5lPpQ0hP/Us2XZHP0WIppeA=;
 b=vgyyFGnvzarOJUwyoIVPyDOWXZMRbPYd1JQxWFwbNTsuK6kP5WzXEztNWcVqZxEjQBus/GBtdZBm0oT0tRt1Up6Z9joYsFB088WKNhO0cqKgndDOdjRkKRiJtd8/1X2aIrZnfEE38uDVKStr3By2wzk7eNq4KrNV2aV9BzgYTYLaNUxJWwKfwfWfTKSRZHFFZ/EM7drwg2Wxn0RYai+Oi/JDChAst1KU9rNSI603ifiyFAWhkQHeUTmfDkJKsMpC4QZjzdeMvLsFmvUksQc7yZ/QpKK026GVkbO2+d8qRefakw8j6KX3ddemuAX9HZ6jxTwzKBmbLTX4dPavLl96+g==
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=pmKQvjwyH95o+2UdOedf5lPpQ0hP/Us2XZHP0WIppeA=;
 b=h9QeRv/38bIa7vTt/JwqCXwp7q8q94fSDmOnKV2ECule6xxDCgAnW7924SD3Tb1Xl1LVtUXQHhn5Jqlgxe9Z49GLafvsuZ/xE6hBjGzzItWjVisRocRKCDffzdjJ2QoAY5ebj3YdHxoDCgcRHDiIuLjsggHUGSGdqy4GR5FFCLs=
From: Luca Fancellu 
To: Ayan Kumar Halder 
CC: Ayan Kumar Halder ,
	"xen-devel@lists.xenproject.org" , Stefano
 Stabellini , Julien Grall , Bertrand
 Marquis , Michal Orzel ,
	Volodymyr Babchuk 
Subject: Re: [PATCH v1 1/3] arm/mpu: Introduce MPU memory region map structure
Thread-Topic: [PATCH v1 1/3] arm/mpu: Introduce MPU memory region map
 structure
Thread-Index: AQHb1XhE+9uzMCRJ9UO6OgGmjkgLx7PzYDyAgAExFACAAACHgA==
Date: Thu, 5 Jun 2025 13:33:45 +0000
Message-ID: 
References: <20250604174311.754899-1-ayan.kumar.halder@amd.com>
 <20250604174311.754899-2-ayan.kumar.halder@amd.com>
 <154A0263-6E4D-4855-9408-ED31F45B293F@arm.com>
 <3857c1c8-0abd-4058-a355-9c12ab08ad3c@amd.com>
In-Reply-To: <3857c1c8-0abd-4058-a355-9c12ab08ad3c@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.600.51.1.1)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB7PR08MB2987:EE_|PAWPR08MB11086:EE_|AM2PEPF0001C70E:EE_|VI0PR08MB10539:EE_
X-MS-Office365-Filtering-Correlation-Id: c82cc432-91fd-40a6-aaa7-08dda435abc8
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:
 =?utf-8?B?ZlBpN0V1a0E2RzdpRnBROE1RQ0Rjb1oyZi90RExyVXBrWS9RM0JzSUhmdHI0?=
 =?utf-8?B?c3RETGdCZVhBZ016RVpPSjgvSWlzeENuZ0NJdE5nQUNwaGJiZVdUL3pwNHNn?=
 =?utf-8?B?bFRCby9meW5hQ1UrWHdYbWRVK042Qmt2K0dpd0tEcVJGY2JkNDczYjJGUGx2?=
 =?utf-8?B?ZEN3Z0gwTEpZY01NMjdMdGF5eThFMEJlaTR2ajNHaEN6QWRxd21HVmpjUmFa?=
 =?utf-8?B?YzR6UFpXYXo2KzRKN0l2Q3lwT3VUVFBDUG9Sb1ZvNDVrK09vejhOTXEvV2tw?=
 =?utf-8?B?NDFnbERBQ1lwQzBDYzFQRGxoOVdpYXJRa2tVRk82andaUXVIMVFzTW4wcmdy?=
 =?utf-8?B?VDNGM01aZHZNOHpTcWcyU1ExSnVWSjFEdXViRXZhd0RVQXBOMkltS3BRaGdV?=
 =?utf-8?B?eTR1Zi9qK0xwTXZBMk1GTFVUSkdMRWxZaWJVa0ZLWTNrV0NnY0pSbUlQZmUz?=
 =?utf-8?B?MzdBOFJxWk45STNKR0N4QUR6NWIwUHNFTGtWK0pHMGJKZm9VaFRHSG5NTWwv?=
 =?utf-8?B?cDladUxnOFBTWEYzcDlnaytQWWJBeDVUbEZyT3Y1MWUyci9KZ3ZXWTlRZG91?=
 =?utf-8?B?WkZPS1RPdnE2cU5pSUNDSFR4ZE5oOE1HdjczRGhPb3ladEZLU09iRmlISUp4?=
 =?utf-8?B?TkE0S0JFemRJQ1VPWjc0UGszck1yMkI1Q014K292dDhzWVVNTThLVytqcTVK?=
 =?utf-8?B?cjJmY0hJeWMvM0xrRVlacWpSUS9kcHVaUHhmaFFuTW9TYnJmV2d3b0NabG5V?=
 =?utf-8?B?SnFYUEJFck5oZ01hZDJUS0lJeTVUZnRoZndIcWQvblM3RENibEQ4UTN4UGpw?=
 =?utf-8?B?Vm0yVHAvWTNsc2FpcTE4WmdmWnFHSmNBaVFZWGlFTEdPWU91ZmlJbGdydVBL?=
 =?utf-8?B?cS9xcVB1cGh4dXI0cVdSck4rOFhmY0NLdmF3MC9jY3Z3N2plNC9jU3poaUIv?=
 =?utf-8?B?OGtrRkVSWC9BYnlsaHFEOFNYbmd6RmNNUGk0Q1dwMnNsSHA5czQrSG1YaFUr?=
 =?utf-8?B?TUlDOXcxakY3d2JPa3AzLzRJakhSamczekZ2S0xXL2NnMEY1Q1VsQ0hKNFBQ?=
 =?utf-8?B?L3EyQ3N4VGd2UXVsZHhiV3cvUGJjYytKK3ZyRXJlOGpCcXNUb0xKMllFUTA0?=
 =?utf-8?B?UzJSOVd4K09McDNNSjdwSXVSQ1FNNVR3bFU4SDl0TEJ2RUIwVDVBSUpTV1Vu?=
 =?utf-8?B?eEVPanhkVlQ5UThpY3BxdlBZZmFEaFIwOWxGN091NzBLMC9ueXI3OXlrZFAz?=
 =?utf-8?B?eTBNaktqK2NoOGh6bU1PaklxR1hPUWdKRkR1YktxZ0RYdXFJMW4yM0ZFbVdv?=
 =?utf-8?B?RlY4YW8zOUkyOVBibFBGZCt5NW02KzdXZ3VwMTA2WnpQVitqWEQvb2hDbUNz?=
 =?utf-8?B?bXFWNDVuMFg0a2tWZzlRcktKK3lxTUg0S1A4YzFXazBlMkE2L2o4ZG9EUHhM?=
 =?utf-8?B?L1Y1emtRVWRTaUxkWDI2N3ZwcW93MkRHVzYxWlpwNG9tclNDUXJHV2lqSWN2?=
 =?utf-8?B?dE5lYXA5KzgrS2NQaTRSUStscXlpUkhKYk5samFxTFJvRmtnWWlkYUpnYmVO?=
 =?utf-8?B?b2E1Nlh3M3g0YmlZazFwbTMzMmFpZ3pFOUVhLzh0N291WnNHWCtMOXJvT2Rr?=
 =?utf-8?B?THhmZ1NLdU5rL2ZiR0RXYlYrMmx1SnY2bTRBMTl5QXZvSHBaTU5EbSthcWo4?=
 =?utf-8?B?LzNEZ2J0U1dDZXkzcUdPbzRWYXI3OENFTUdERm92czBpWWxvUklNRWpiTlAw?=
 =?utf-8?B?Sk1rWEFzMURPOEFuV1M1RFZ2aExIWUhCcjM3RjUxWjU4UmtFUFpEL0labTlN?=
 =?utf-8?B?NTRzUUkrTE5ZNjRFWE45SERUbTJWd2YvVjZHWm9UcXYrNXlCV2ZWb2drSVVX?=
 =?utf-8?B?eGpvT2ZsQ09OeUExVXNTZkJhRG14ZGJ1L2dCVzJaNXF5RDduM3BxUjQyZlVO?=
 =?utf-8?B?VS8rckRnY1RVUlRpZUpUeUFrc1JGYldRcUpXVHVOVnozdWt1SUZpSXdmc1FK?=
 =?utf-8?B?dmhjcm5WS3hBPT0=?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB7PR08MB2987.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="utf-8"
Content-ID: <095F735C73948140B88BAEA25F52F80F@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR08MB11086
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AM2PEPF0001C70E.eurprd05.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	94715248-048e-49f2-5df1-08dda43598a1
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|14060799003|82310400026|1800799024|35042699022;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?SmpDNHpVRzdtb1J4MHA5YUtBU2dXdENXaW9YK0lmY1JFVjNYbjYwaG82ckRH?=
 =?utf-8?B?MTExazhCR0hpUnQ5c1gvUkRaSi9nK1VFZWNsWEdLcGdZN29Kay9tQ1dhWE1o?=
 =?utf-8?B?My9lZlRsbVZmQkQ3UHYvYTRKa3I5THExUzhkd09KZVFxQmNEWVNWRGVrb3FM?=
 =?utf-8?B?b1pTOERyVmR0TkJMQzJFYXdhL3BEZ3dLUTRMK3pWVFlpWjZDdEV3eEFwTEVN?=
 =?utf-8?B?Vy9uVUlrOExpRGRDV3Y4R1J6T2pPM05PQUd3UnpiRUROeDNRM2dDVjlwejlK?=
 =?utf-8?B?NXMrWEU3cEwzZHo5bllyakt4anNqWEFoUFo4b1lkaHE2dHBYQVAyRTlmWFg2?=
 =?utf-8?B?aDgyNVI4M3BUSXZJZEpzbzNEcXNGbjJRSzdFbExJdlpQZDdYYTVuNXlWcDZU?=
 =?utf-8?B?UURDem8wSVhUVEtxemloblVLYkMremxaemlObk9obWpwLzRVUjJCckFZbUZ4?=
 =?utf-8?B?citSTzVic1BpSHAvNURFVFNYTGlHNk85M2ZTck9RVW1Uc2txOW9pNzR3RTVB?=
 =?utf-8?B?WVJCemYvdlFiVkd3WHF6bXFPWkJUSkFvU3dxbllvUGZvSmZMdVdBU3FPOXkz?=
 =?utf-8?B?MnFXb1ovNFNKaXNXUGNsL1N1ek01Y0RqRUJSejRaalYzMzZJazMwVncvSGZu?=
 =?utf-8?B?UXBmTklpQmdWTzRMWkNaZ016UDE3UFk3eWxHL1dJSnQ0dytwQzI4U2QrczJ5?=
 =?utf-8?B?YzdQdHRya01NL3dPNDgvQkxnWUQ4Wk82QkF6a0Y1UHU5RWtidm4xMVpXbVJz?=
 =?utf-8?B?azZMdHJQMklkbzlkRkQ5K1BoLzByd3VFR3o5a29LS3BVZUE5RWdWRWxFOERC?=
 =?utf-8?B?SGx1amplaUN5UU9PQ2pyS2UrQkkwd01nMzRGcnBjTDgwOUNRTytxQisxd2I0?=
 =?utf-8?B?Skx5VVFvQmNWMjdtWnRnRkVZUUlhY1A1dXcvc0RvWXVYb3pYWnAxUDZmS1kr?=
 =?utf-8?B?dERhUWJsNjBUcFpHUnMrUFFyOXdLUWh5SHNHODRRRUw0NmVPSTZCWWdudERs?=
 =?utf-8?B?TjliVkpDNEhSUzdRTEt4UGl2YVc1TFBNMFdjYVZUSWZRQ2NNN2haQzY3Sm9w?=
 =?utf-8?B?cjVXUFM5MnV0UzRkYklwcXR3WkRLVDl2ZFZOdy9YaVhUVjk3UC9QVUdDbFV6?=
 =?utf-8?B?V0xQTTl2eWFEUXhCaVB3WThHR1ZUZlNxZG56WFZQbk9QRFFYcE56eitjM1gr?=
 =?utf-8?B?SWxLbE95b3IybG5VR29maVFka3lyTXA4cmIyZGZlUnB5NE9tOUJiZDM2Zjdw?=
 =?utf-8?B?a0hDVTlSRG9ab05nRmgya3BHcFpkNzZmWEdiQ1ZIVFNPK1p1VGtheHpyWExq?=
 =?utf-8?B?NytFcjRtU1YwY2VmRUFDakNkNWFCRFhUdzNjcmxMWE9jN2tKMVIraUtOVVJk?=
 =?utf-8?B?Z3JqdWJUVGZYWmlVN29ueWtQbmFJclJ1ck1tdVZSQWJndU56ejc2M3FrNWpw?=
 =?utf-8?B?LzB5M0FDTG1yQktPV1pSUGFycGJSQ3U0NXV0VmtSY3Z6TWFpam9nTUxtTG5i?=
 =?utf-8?B?b0pqMDdEZHN4ckVIcjZSNHBuT0ZMTnpUTEJqbEhkK1JHb1RqSXYra0UvSERE?=
 =?utf-8?B?MHdPaWFBTHY2R1RrWm1PZCtvR1h2amFoUFRwa1ZTcVFZR2Rwc2JZVFRKU09Q?=
 =?utf-8?B?aDBVQytIeU9RWmtVVExkYiszckhFMW42bVFYOTJJZ2RWTkJrNlFma21FTzRv?=
 =?utf-8?B?cnYrTThhbUZjdFl0M3N4OHRWV3NmOURyTEJTbU1Gb2U2cDJ0d3BLSzlKZEtM?=
 =?utf-8?B?UElrRVVkN1RsK1ZEQWIvaWxUTjRzNUxGK1FVenB0OWN6MTFJbkZmWUVWVHVo?=
 =?utf-8?B?K3pacVFIMm9IaGFMMmJzLzhBQ0JUZ2JDUFdmWUFmTit5ZnJ0amxwQW5jQW1m?=
 =?utf-8?B?M2Z2cHRlcUVES2NGaFluREV2UFVnSnRyOVdEL2xyYlh5Q1dSVnV0VHJGMGV3?=
 =?utf-8?B?b1VKdHR2WFFMT0MyL3hCdTlMcjNmdTlFTGxLaXlxNytTZklpaDMzSG1kWGN3?=
 =?utf-8?B?M2RNdHM2OHlNazVsakRMb09yRzB2NVhxazNpUnBSK2Nnc05oRjVSNER2Y2dx?=
 =?utf-8?Q?kJy4sh?=
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(14060799003)(82310400026)(1800799024)(35042699022);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jun 2025 13:34:17.7892
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c82cc432-91fd-40a6-aaa7-08dda435abc8
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com]
X-MS-Exchange-CrossTenant-AuthSource:
	AM2PEPF0001C70E.eurprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR08MB10539

SGkgQXlhbiwNCg0KPj4+ICsvKiBIeXBlcnZpc29yIFByb3RlY3Rpb24gUmVnaW9uIEJhc2UgQWRk
cmVzcyBSZWdpc3RlciAqLw0KPj4+ICt0eXBlZGVmIHVuaW9uIHsNCj4+PiArICAgIHN0cnVjdCB7
DQo+Pj4gKyAgICAgICAgdW5zaWduZWQgaW50IHhuOjE7ICAgICAgIC8qIEV4ZWN1dGUtTmV2ZXIg
Ki8NCj4+PiArICAgICAgICB1bnNpZ25lZCBpbnQgYXBfMDoxOyAgICAgLyogQWNlc3MgUGVybWlz
c2lvbiAqLw0KPj4+ICsgICAgICAgIHVuc2lnbmVkIGxvbmcgcm86MTsgICAgICAvKiBBY2Nlc3Mg
UGVybWlzc2lvbiBBUFsxXSAqLw0KPj4+ICsgICAgICAgIHVuc2lnbmVkIGludCBzaDoyOyAgICAg
ICAvKiBTaGFyZWJpbGl0eSAqLw0KPj4gVHlwbzogU2hhcmViaWxpdHkgLT4gU2hhcmVhYmlsaXR5
Lg0KPiBBY2sNCj4+IA0KPj4gQWxzbywgZnJvbSB0aGUgcGF0Y2ggdGhlIGNvbW1lbnRzIGZlZWxz
IG5vdCBhbGlnbmVkLCBpcyB0aGF0IHRoZSBjYXNlPw0KPiBXaGVuIHlvdSBhcHBseSB0aGUgcGF0
Y2gsIHRoZSBjb21tZW50cyBsb29rIGFsaWduZWQgKGluIHRoZSBjb2RlYmFzZSkuIERvZXMgaXQg
bG9vayB0aGUgc2FtZSBmb3IgeW91ID8NCg0KSSBkaWRu4oCZdCBhcHBseSB0aGUgcGF0Y2gsIG9r
IHRoZW4gaXTigJlzIGp1c3QgaW4gbXkgY2xpZW50IEkgc2VlIGl0IG5vdCBhbGlnbmVkLCBzb3Jy
eSBmb3IgdGhlIG5vaXNlIQ0KDQpDaGVlcnMsDQpMdWNhDQoNCg==


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 13:35:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 13:35:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006887.1386140 (Exim 4.92)
	(envelope-from )
	id 1uNAkS-0001LY-FE; Thu, 05 Jun 2025 13:35:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006887.1386140; Thu, 05 Jun 2025 13:35: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 1uNAkS-0001LR-C7; Thu, 05 Jun 2025 13:35:12 +0000
Received: by outflank-mailman (input) for mailman id 1006887;
 Thu, 05 Jun 2025 13:35: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 1uNAkQ-0001LF-Fg
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 13:35:10 +0000
Received: from fout-a3-smtp.messagingengine.com
 (fout-a3-smtp.messagingengine.com [103.168.172.146])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e2f9033e-4211-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 15:35:04 +0200 (CEST)
Received: from phl-compute-02.internal (phl-compute-02.phl.internal
 [10.202.2.42])
 by mailfout.phl.internal (Postfix) with ESMTP id 4B60D13802B5;
 Thu,  5 Jun 2025 09:35:03 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-02.internal (MEProxy); Thu, 05 Jun 2025 09:35:03 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 5 Jun 2025 09:35:01 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e2f9033e-4211-11f0-b894-0df219b8e170
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=1749130503;
	 x=1749216903; bh=Ig8lrPs2/XgtloRy6DLLL604F/dk4LIwQ/GemHxYXTk=; b=
	knnfLj+4zJxc8X+JwQnTdQpzKQkjhbMcLuxcUBus+H9/XQ+V41gg2TKOB97+Teux
	q2OQeSSiWZMyuvZHuqNBkOu0xZjiSxsC+BBcuF/9q2Ll0tFAJC6c4j/JQ7TBd1Nr
	qkQ2lS4vVn18xR3HtdSxoIxhIgpL5lHjV6iwJBN6m6Qqcd0nqkEqN+7GluEl/agd
	qbsMVhC9Y5nvMQPvNl1oOCLf8sLI7W/k2Q36NzzfaAquCFHKq8HoZVOrsCrSnBm9
	DNNBt0Fq4d8tZZJ5O+SpN1+XC+NkuMWf/XefwkAq1uI7PTFZN/YazS9X+gGSt+cW
	KEIn/qE1GKorEfUndEAC3Q==
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=
	1749130503; x=1749216903; bh=Ig8lrPs2/XgtloRy6DLLL604F/dk4LIwQ/G
	emHxYXTk=; b=YWWFWwhgB5MoaEGt40DnEX6VGmYsMQsKI4ZSSZY6puQPK0t6mxI
	3torkpX7PS5PtMoSIYC/Uh2HuJZkU+KaBlkCj7HEo9RdPRIli5ne5zJ2CAv+LqsS
	nsaecIRAilLo9Xin3Sx/tm7ZsvIE3fYqPyzqmpdIc2Tc0KChfCDhfznr6/pfc4U/
	W8H608Yp1kLoSAaqpWXE0M0ARAdJZVpgs7xQyelzkga+aRd9MjKsrrReiLtIgQ0Q
	85bcIiGY3gz6iGeaFozD31Xi41LX+zFmCUorr81l8Em+ldKShE1N7MS07KyeNvjZ
	LLWd8mO86CmIIM8lC5bwmHaLQPsxzIUO2Og==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugdefjedtucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtjeen
    ucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomh
    grrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggft
    rfgrthhtvghrnhepheegtdfgvedvueetheelgeetgefffeefvdehueelvdeiudefffelhf
    evveejveeinecuffhomhgrihhnpehgnhhurdhorhhgpdhkvghrnhgvlhdrohhrghenucev
    lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrh
    gvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthho
    peeipdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehjsggvuhhlihgthhesshhush
    gvrdgtohhmpdhrtghpthhtoheprghnughrvgifrdgtohhophgvrhefsegtihhtrhhigidr
    tghomhdprhgtphhtthhopehrohhsshdrlhgrghgvrhifrghllhestghithhrihigrdgtoh
    hmpdhrtghpthhtoheprhhoghgvrhdrphgruhestghithhrihigrdgtohhmpdhrtghpthht
    ohepughpshhmihhthhesrghpvghrthhushhsohhluhhtihhonhhsrdgtohhmpdhrtghpth
    htohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhg
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Thu, 5 Jun 2025 15:34:59 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Jan Beulich 
Cc: Andrew Cooper ,
	Ross Lagerwall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	"Daniel P . Smith" ,
	Xen-devel 
Subject: Re: [PATCH 1/3] x86/EFI: Fix detection of buildid
Message-ID: 
References: <20250605111638.2869914-1-andrew.cooper3@citrix.com>
 <20250605111638.2869914-2-andrew.cooper3@citrix.com>
 <0a314400-126a-4c2a-b36c-dda61bb0b751@suse.com>
 
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="P0ORzQzBCX5mHtyo"
Content-Disposition: inline
In-Reply-To: 


--P0ORzQzBCX5mHtyo
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 5 Jun 2025 15:34:59 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Jan Beulich 
Cc: Andrew Cooper ,
	Ross Lagerwall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	"Daniel P . Smith" ,
	Xen-devel 
Subject: Re: [PATCH 1/3] x86/EFI: Fix detection of buildid

On Thu, Jun 05, 2025 at 03:08:07PM +0200, Jan Beulich wrote:
> On 05.06.2025 14:20, Marek Marczykowski-G=C3=B3recki wrote:
> > On Thu, Jun 05, 2025 at 02:02:21PM +0200, Jan Beulich wrote:
> >> On 05.06.2025 13:16, Andrew Cooper wrote:
> >>> The format of the buildid is a property of the binary, not a property=
 of how
> >>> it was loaded.  This fixes buildid recognition when starting xen.efi =
=66rom it's
> >>> MB2 entrypoint.
> >>>
> >>> Suggested-by: Ross Lagerwall 
> >>> Signed-off-by: Andrew Cooper 
> >>
> >> I'll pick this up without a Fixes: tag, but I think it ought to have o=
ne. (I
> >> didn't check whether MB2 or build-id support came later, hence introdu=
cing the
> >> issue.)
> >>
> >>> --- a/xen/common/version.c
> >>> +++ b/xen/common/version.c
> >>> @@ -203,8 +203,11 @@ void __init xen_build_init(void)
> >>>      rc =3D xen_build_id_check(n, sz, &build_id_p, &build_id_len);
> >>> =20
> >>>  #ifdef CONFIG_X86
> >>> -    /* Alternatively we may have a CodeView record from an EFI build=
=2E */
> >>> -    if ( rc && efi_enabled(EFI_LOADER) )
> >>> +    /*
> >>> +     * xen.efi built with a new enough toolchain will have a CodeVie=
w record,
> >>> +     * not an ELF note.
> >>> +     */
> >>> +    if ( rc )
> >>
> >> Instead of dropping the efi_enabled(), I think you want to replace EFI=
_LOADER
> >> by EFI_BOOT.
> >=20
> > Part of the motivation for MB2 entry point in xen.efi is using the
> > same binary in all boot modes, including legacy boot - in which case
> > none of EFI_* checks would be appropriate here. The grub series adds
> > support for loading PE binaries, and IIUC it isn't tied to booting via
> > EFI.
>=20
> "The grub series" being which one?=20

https://lists.gnu.org/archive/html/grub-devel/2024-03/msg00080.html
| This patch series implements support for loading and verifying a signed
| xen binary. This would allow the same xen binary to be used for BIOS
| boot, UEFI boot, and UEFI boot with Secure Boot verification.
| There is an accompanying Xen patch series.

> I didn't know xen.efi's non-EFI MB2 entry
> point could be used; instead I was under the impression that someone was
> having (half?) a patch eliminating the MB data from xen.efi, as being dead
> code.

See also
https://lore.kernel.org/xen-devel/CAG7k0EroeA=3DcRRDWnJqzH8esoaSmtg8-xjTwc-=
01og5R9JwPzg@mail.gmail.com/
for some extra context.

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

--P0ORzQzBCX5mHtyo
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmhBnQMACgkQ24/THMrX
1ywnhwf/bAZrULA8myvNFHOWMClznpeJ3V+/Ex76QCVuzPtWzx4xdfpLGIukQWqL
erl6hYDbaM8YyzUgGPcMfqIDKSh/hL3nuET/ZACWklqTA5XVGhTbTOZb/Hs7u+TR
PgCzAhc3GLGx46/RggZrUDrbBh77jmD/rEC25n7wd9SzeKkpEZWChMoXShjAIsq8
6I2uG4+pAwY2LqD/javYkdoz1TNkwflBMts0SfyGXWO2cfrmqJ23YWM4WE0Q4UmF
6hBZjVTebIe+/rT28y67NnR//GNHo7HAJNPeXFM9LrPYfKDyb+uZ7Xrh9uvMeri4
SvkmAuTDOh/xQj/V58kkBowiih1/9g==
=/rtk
-----END PGP SIGNATURE-----

--P0ORzQzBCX5mHtyo--


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 13:35:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 13:35:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006893.1386149 (Exim 4.92)
	(envelope-from )
	id 1uNAl3-0001or-Lx; Thu, 05 Jun 2025 13:35:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006893.1386149; Thu, 05 Jun 2025 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 1uNAl3-0001ok-JJ; Thu, 05 Jun 2025 13:35:49 +0000
Received: by outflank-mailman (input) for mailman id 1006893;
 Thu, 05 Jun 2025 13:35: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 1uNAl2-0001LF-3E
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 13:35:48 +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 fc2480bd-4211-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 15:35:46 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-450cfb79177so5203395e9.0
 for ; Thu, 05 Jun 2025 06:35:46 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a5236d4466sm3830417f8f.100.2025.06.05.06.35.45
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 06:35:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fc2480bd-4211-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749130546; x=1749735346; 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=oQ/jRID1McYK5kSvWo683gzCCMc2GCjXLg/u+H+QyLA=;
        b=QbuB2DskTkH4xby0VvSC2C1eqDm1u6Aog0pTGrZZdYSaOlJTvoB7bKRDJhKFbEdIkd
         WEJEg1ZZK2ML9KaBymL0mIyfVUbI1CLQqc0S+QrQNdI5eAxeWM9G9cXd8GbXON0bOc1D
         W8dZJanK+Z6SOsISH5JkH9t/S2jbQBljzf68E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749130546; x=1749735346;
        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=oQ/jRID1McYK5kSvWo683gzCCMc2GCjXLg/u+H+QyLA=;
        b=dI2CWKvRbmdAN+hmtQMRbpLRK9Wzj2yT33Bc4dhNjtooCo+nPmf0lpRWd444nN8o2O
         WFK/kd3/l/dW9b8onezSddYiPUXQoFGgJlfzRkZEtXmxMufXQUOiRvrndsfvJJoRB+lF
         MLjnYt1asIyyrS3pDW2zbacpNY6CNL3qpddvFet9SwT8UF9IJvlZv9k9g5ly6JN1ivYM
         Odd8TW6mbjnWWxtS6l8nq9kW+lfnDfqPhZcxBCIJ9sbD6lYNnhuMGx93hHkTW9WqslH8
         BW7IfIzQQNMdRYiKT3Vz0QEdTKQ/wL+i96ga/yc7LXPqa1L8qXv7QoHqAMgAMd6/HVxH
         mklA==
X-Gm-Message-State: AOJu0YwkvGbNUn+zMvr1VHZSzbbKcYqQHdTenDs4cSo0UDAzPOTHDuEo
	IutkoKLJjNVaPz6W39nK9fHtGQMQKp50Fy+eE6Pa+Fo0pHREsfBq40MN1UKMGMwFLFE=
X-Gm-Gg: ASbGncu/URV9j+WdnPVLdPxjd86hnIF/M03vLFcBUkmRPOrXUoIybU1Nk6+a1c0o76U
	DIl3/bTOlAtkHU3V3pRJeufwgrzG10aNpmZrxhRhjQiRPixKw/QT5bvtx8KQfUi6GfoVDe77ncv
	EoQwKmnuTBweOe3KVRNBdIAfzwApA9W+mDiEFnRB2c4hqpLTKmr2Hr5o9Ni7eM60odzJt0Lk2h0
	8dy/ArK405jlL0tLdkv2LJgeUgDlIkHxqtjwokSeGV2XIf42N9hYMGu6scnwGNNIRVvzr6mS+Ss
	o05VTsjmenq+1N0fFxxj7Kt7Zgj8jXzEHAEI35To1QT540ZaFWGrEW4eKvio7sWEif4mV+ing+5
	OC23xa/Z0pFqt8JdR55A=
X-Google-Smtp-Source: AGHT+IFKvGAsjt58i8TD5iBhNxJeDuesXrMdBfrrvsKe2th459ziI4h37GCaLcWy+DHu1gAjpDp9GQ==
X-Received: by 2002:a05:600c:190c:b0:43c:fffc:7886 with SMTP id 5b1f17b1804b1-451f0a75a7emr65555145e9.8.1749130545554;
        Thu, 05 Jun 2025 06:35:45 -0700 (PDT)
Date: Thu, 5 Jun 2025 15:35:44 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jiqian Chen 
Cc: xen-devel@lists.xenproject.org, Huang Rui 
Subject: Re: [PATCH v5 05/10] vpci: Hide legacy capability when it fails to
 initialize
Message-ID: 
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
 <20250526094559.140423-6-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250526094559.140423-6-Jiqian.Chen@amd.com>

On Mon, May 26, 2025 at 05:45:54PM +0800, Jiqian Chen wrote:
> When vpci fails to initialize a legacy capability of device, it just
> returns an error and vPCI gets disabled for the whole device.  That
> most likely renders the device unusable, plus possibly causing issues
> to Xen itself if guest attempts to program the native MSI or MSI-X
> capabilities if present.
> 
> So, add new function to hide legacy capability when initialization
> fails. And remove the failed legacy capability from the vpci emulated
> legacy capability list.
> 
> Signed-off-by: Jiqian Chen 
> ---
> cc: "Roger Pau Monné" 
> ---
> v4->v5 changes:
> * Modify vpci_get_register() to delete some unnecessary check, so that I don't need to move function vpci_register_cmp().
> * Rename vpci_capability_mask() to vpci_capability_hide().
> 
> v3->v4 changes:
> * Modify the commit message.
> * In function vpci_get_previous_cap_register(), add an ASSERT_UNREACHABLE() if offset below 0x40.
> * Modify vpci_capability_mask() to return error instead of using ASSERT.
> * Use vpci_remove_register to remove PCI_CAP_LIST_ID register instead of open code.
> * Add check "if ( !offset )" in vpci_capability_mask().
> 
> v2->v3 changes:
> * Separated from the last version patch "vpci: Hide capability when it fails to initialize"
> * Whole implementation changed because last version is wrong.
>   This version adds a new helper function vpci_get_register() and uses it to get
>   target handler and previous handler from vpci->handlers, then remove the target.
> 
> v1->v2 changes:
> * Removed the "priorities" of initializing capabilities since it isn't used anymore.
> * Added new function vpci_capability_mask() and vpci_ext_capability_mask() to
>   remove failed capability from list.
> * Called vpci_make_msix_hole() in the end of init_msix().
> 
> Best regards,
> Jiqian Chen.
> ---
>  xen/drivers/vpci/vpci.c | 117 ++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 113 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
> index 2861557e06d2..60e7654ec377 100644
> --- a/xen/drivers/vpci/vpci.c
> +++ b/xen/drivers/vpci/vpci.c
> @@ -83,6 +83,99 @@ static int assign_virtual_sbdf(struct pci_dev *pdev)
>  
>  #endif /* CONFIG_HAS_VPCI_GUEST_SUPPORT */
>  
> +static struct vpci_register *vpci_get_register(struct vpci *vpci,
> +                                               unsigned int offset,
> +                                               unsigned int size)
> +{
> +    struct vpci_register *rm;

Nit: I think you re-used part of the code from vpci_remove_register()
that names the local variable rm (because it's for removal).  Here it
would better to just name it 'r' (for register).

> +
> +    ASSERT(spin_is_locked(&vpci->lock));
> +
> +    list_for_each_entry ( rm, &vpci->handlers, node )
> +    {
> +        if ( rm->offset == offset && rm->size == size )
> +            return rm;
> +
> +        if ( offset <= rm->offset )
> +            break;
> +    }
> +
> +    return NULL;
> +}
> +
> +static struct vpci_register *vpci_get_previous_cap_register(
> +    struct vpci *vpci, unsigned int offset)
> +{
> +    uint32_t next;
> +    struct vpci_register *r;
> +
> +    if ( offset < 0x40 )
> +    {
> +        ASSERT_UNREACHABLE();
> +        return NULL;
> +    }
> +
> +    r = vpci_get_register(vpci, PCI_CAPABILITY_LIST, 1);
> +    if ( !r )
> +        return NULL;
> +
> +    next = (uint32_t)(uintptr_t)r->private;
> +    while ( next >= 0x40 && next != offset )
> +    {
> +        r = vpci_get_register(vpci, next + PCI_CAP_LIST_NEXT, 1);
> +        if ( !r )
> +            return NULL;
> +        next = (uint32_t)(uintptr_t)r->private;
> +    }
> +
> +    if ( next < 0x40 )
> +        return NULL;

The code below I think it's a bit simpler (and compact) by having a
single return instead of multiple ones:

for ( r = vpci_get_register(vpci, PCI_CAPABILITY_LIST, 1); r;
      r = next >= 0x40 ? vpci_get_register(vpci,
                                           next + PCI_CAP_LIST_NEXT, 1)
                       : NULL )
{
    next = (uint32_t)(uintptr_t)r->private;
    ASSERT(next == (uintptr_t)r->private);
    if ( next == offset )
        break;
}

return r;

I haven't tested it however.

> +
> +    return r;
> +}
> +
> +static int vpci_capability_hide(struct pci_dev *pdev, unsigned int cap)
> +{
> +    const unsigned int offset = pci_find_cap_offset(pdev->sbdf, cap);
> +    struct vpci_register *prev_next_r, *next_r;

I think it might be clear to just name this prev_r, next_r,
prev_next_r is IMO a bit confusing.  I understand it refers to the next
capability register in the previous capability, and I think prev_r
might be enough.

> +    struct vpci *vpci = pdev->vpci;
> +
> +    if ( !offset )
> +    {
> +        ASSERT_UNREACHABLE();
> +        return 0;
> +    }
> +
> +    spin_lock(&vpci->lock);
> +    next_r = vpci_get_register(vpci, offset + PCI_CAP_LIST_NEXT, 1);
> +    if ( !next_r )
> +    {
> +        spin_unlock(&vpci->lock);
> +        return -ENODEV;
> +    }
> +
> +    prev_next_r = vpci_get_previous_cap_register(vpci, offset);
> +    if ( !prev_next_r )
> +    {
> +        spin_unlock(&vpci->lock);
> +        return -ENODEV;
> +    }

You can join both the above into a single check IMO:

next_r = vpci_get_register(vpci, offset + PCI_CAP_LIST_NEXT, 1);
prev_r = vpci_get_previous_cap_register(vpci, offset);
if ( !next_r || !prev_r )
{
    spin_unlock(&vpci->lock);
    return -ENODEV;
}

There's no benefit in using two equal error condition checks (just
makes the code longer)

> +
> +    prev_next_r->private = next_r->private;
> +    /*
> +     * Not calling vpci_remove_register() here is to avoid redoing
> +     * the register search
> +     */
> +    list_del(&next_r->node);
> +    spin_unlock(&vpci->lock);
> +    xfree(next_r);
> +
> +    if ( !is_hardware_domain(pdev->domain) )
> +        return vpci_remove_register(vpci, offset + PCI_CAP_LIST_ID, 1);
> +
> +    return 0;
> +}
> +
>  static int vpci_init_capabilities(struct pci_dev *pdev)
>  {
>      for ( unsigned int i = 0; i < NUM_VPCI_INIT; i++ )
> @@ -91,7 +184,6 @@ static int vpci_init_capabilities(struct pci_dev *pdev)
>          const unsigned int cap = capability->id;
>          const bool is_ext = capability->is_ext;
>          unsigned int pos;
> -        int rc;
>  
>          if ( !is_ext )
>              pos = pci_find_cap_offset(pdev->sbdf, cap);
> @@ -103,9 +195,26 @@ static int vpci_init_capabilities(struct pci_dev *pdev)
>          if ( !pos )
>              continue;
>  
> -        rc = capability->init(pdev);
> -        if ( rc )
> -            return rc;
> +        if ( capability->init(pdev) )

I think you want to store rc here to print it in the warning message
below.

> +        {
> +            int rc;
> +
> +            if ( capability->cleanup ) {
> +                rc = capability->cleanup(pdev);
> +                if ( rc )
> +                    return rc;

Here where both init and cleanup failed, you simply don't print any
message.

> +            }
> +
> +            printk(XENLOG_WARNING "%pd %pp: %s cap %u init fail, mask it\n",
> +                   pdev->domain, &pdev->sbdf,
> +                   is_ext ? "extended" : "legacy", cap);

I think this needs to be done ahead of the cleanup(), and print the
returned error code.  Overall we need messages printed when any of
those fails, as that makes it easier to debug when things go wrong.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 13:40:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 13:40:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006903.1386160 (Exim 4.92)
	(envelope-from )
	id 1uNAp0-0002Vy-Ay; Thu, 05 Jun 2025 13:39:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006903.1386160; Thu, 05 Jun 2025 13:39: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 1uNAp0-0002Vr-7c; Thu, 05 Jun 2025 13:39:54 +0000
Received: by outflank-mailman (input) for mailman id 1006903;
 Thu, 05 Jun 2025 13:39: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 1uNAoz-0002Vk-Om
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 13:39:53 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on2061e.outbound.protection.outlook.com
 [2a01:111:f403:2415::61e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8d63a341-4212-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 15:39:51 +0200 (CEST)
Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
 by PH0PR12MB7863.namprd12.prod.outlook.com (2603:10b6:510:28b::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.29; Thu, 5 Jun
 2025 13:39:45 +0000
Received: from PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264]) by PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264%2]) with mapi id 15.20.8792.035; Thu, 5 Jun 2025
 13:39: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: 8d63a341-4212-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=joiX8cbpeZtGFbfbBqnTLKCHWDxUoHZ53IAmXuvLIFwHJxArL7vQT22YHzonzWDoZ/LBuviICGy1bRTYL8kxJjFGZY6HELDudw50MbmZ3ffPW6ORpnjovh1BxOoo69q1nlnWvKeP6udLrWQ/VB2C/UeL54ChN3mJysByWF/0S98qByXxvhZL/uHgRnE+w00NYmXLm/pKVXeQ1BKnRTXpltjqLkX74B1HnQ9rW1dK7u2O+PDIjk+lF14oGLDxD6Acs2D02U1U6vPbHd5yU6JQ4ixrmQqlsqI4bS3ECYgrS5u93rD2MQHddkGDzIQ531iqT5l9jhoYJ0q3+rstx49eaQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=l3GLrIAh+ueQVINWLFF4tU/zqXrndxrvyjSzTP+6QRA=;
 b=qfX3NKoN4RESow6ELwriqSTbjAfpX1Gz0X3Jt4ZRnOdNI+yaeNYGcdKC8Eu0Qudpz2GjALcS3griPxP5QnPPKot4hUx6PXBMMqxwbenKpRi+o5O4Ji0hZ4HcuU+z7EfGy4DExlL/weMIjDtidZPBIjBK1vtRTsdQb3c6l9Y+3KSGyFfnltGGscHMClEHpY9hJoLbbBxHh7kbE/v0oRvW0GgOAYg3V0jrDy6fJsQe/Le2fXr9w7L8Nhfqd1WpT57YtBz4HwJlLXbx5MIIP5YI8L1Tc3K7ukMmOcPPAGFbKPW7HkmsM3E81sEfFnNpWNo/kDPtLqpZ1x+NhEbVeiJFjg==
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=l3GLrIAh+ueQVINWLFF4tU/zqXrndxrvyjSzTP+6QRA=;
 b=gtMC5NwN0pZB6OrnCow5zu2/N67dTNmzKxYHFy4WjMoANrbvu6nAjpvQrSa2eXuq/exMzz0W0djrIfncheG2osetjg6xAutc2/nrgb3jxfRb7ZIsIgMYUrouhpgliLT/HyDSR+XabUMsqyypG0xNVV+YIYoXwut05sUqxdZQcmA=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Thu, 5 Jun 2025 14:39:41 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/3] arm/mpu: Introduce MPU memory region map structure
Content-Language: en-GB
To: "Orzel, Michal" ,
 Ayan Kumar Halder , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250604174311.754899-1-ayan.kumar.halder@amd.com>
 <20250604174311.754899-2-ayan.kumar.halder@amd.com>
 
From: Ayan Kumar Halder 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: AM0PR03CA0013.eurprd03.prod.outlook.com
 (2603:10a6:208:14::26) To PH8PR12MB7326.namprd12.prod.outlook.com
 (2603:10b6:510:216::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|PH0PR12MB7863:EE_
X-MS-Office365-Filtering-Correlation-Id: 5c0f4fa3-5835-484a-fe19-08dda4366ee2
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?Yi9DcFFRZjNxQnU3V3Z6QWNYRGF0cjcvbmZxQjZtWjNzMG1BcENjdTBrQTl5?=
 =?utf-8?B?N2c2aFQzazRrNlZmTXJSUzIrN1E2Rzh2dzNZRnlzSTR2SVdWYUZjNnAvWVMr?=
 =?utf-8?B?RENrUUxxeVZWbi9KbWgyMlE1bW9FRjZwQ1k5eGJSY1ZQZTB1eVovNStxOURG?=
 =?utf-8?B?TlZkdnZvYURENlFHOTVYVmtVbUk3bUYyMzBQN3ZKREMrUlUzYlMyV3N3Z015?=
 =?utf-8?B?L01ERlRRSTA2eUdweEsyZFJkNDFYQW1OWEhaaXZoaXlqVjFLc2tkVDlJWDhw?=
 =?utf-8?B?a3kxTUpuMFNlVFphcFVIN1E0dWpqcFQ3RzlBUW10ZjZ6dG4rS1ZhZEZLV295?=
 =?utf-8?B?OXVPMzFKWU5QZXA3bndDWXBTRWo2OUhLOXE2Mlg1b0RQdXRFc1JGby9HRVd2?=
 =?utf-8?B?cTg5ak5hSlJkYlBlYXRJNk5SSS9tNUZLcmgxMWZMcWR0YmwrSGNVK3lzcE1B?=
 =?utf-8?B?aFBmbjFlSkw1dTEvVWRUTm5sOVJWU3Nsa1BySEFkanJNRDhna1RwWGwyRUNJ?=
 =?utf-8?B?OHA2R01YdjFhb1dUWFk1RG1xelNEL1V4MTlmMjB0RDJkNHZIdG5QZHdlbjBL?=
 =?utf-8?B?QTB3WjZDRVViLysxYkY5VWpDUkFCNFlJNlY4ckVMamt5OHc3d3Jqc0gzcGQw?=
 =?utf-8?B?Ym5xWVZCT3c0VnVOSHVEQ0ZKdXBPZWVoclkvaDVpZG8rVTMrSlAxL1gvODIv?=
 =?utf-8?B?NUpoeEJqOERpSFJQMnF1bzJ0RldMdVhvNy9ZQlBKbm9NVnRCSC9yL2U4Nkd3?=
 =?utf-8?B?ME03V0kzeU81S3I0dHg0OXRzZDJqZ2haYWJ0SVJmUzA0TTNVVTBjSllULzBY?=
 =?utf-8?B?U1EzUHRJVVRyWjFva3ZaY0c2dW5rWmM1akp0N3VtTkJvSTNVOWFQSWJkZEVG?=
 =?utf-8?B?bHo0UmpSbWVPSmxPa1VlZVV3KzZMNE1hS0pIWEsvZ1c4ZVZBbjdWdG0zM0xi?=
 =?utf-8?B?OFFJU2VQWEg4bzBCL25EVSszTUdnbVdzRDFIekxLZ1pnT3NiYkFuZTRSNzZj?=
 =?utf-8?B?VkJQOFZBRUFwQ2xURFVPYnUyUWdnbjlKKzhpaUN5VWd6VUpPNnVQQWNEbkU1?=
 =?utf-8?B?dVpTS1UxdUR0OGIyQjBoK3lhRnlvY29lTXZ6ZlZpV0ZyM2hIT0FYVGZKclhI?=
 =?utf-8?B?RGJ6amovMlJoaWcyaEI5ajZEeG1MMVZSYWVCUU1XNmNVNnEyQSs2eGVJb0xM?=
 =?utf-8?B?UGwzWWFRV2s4QWFJdnJ3TW9IWTRTY2s5ekhXVkxSa0FCQXVCRzhqcWtUQ1RD?=
 =?utf-8?B?N0FJWXFTcFFqV1pOT0hKMTZXNGlxeGFuZ1N1c0tFc0Y0REhLNDB1OEUrUTRC?=
 =?utf-8?B?SXl3MlBGOW9FNTVkUVJsc2RiTEhaYjhGVk9LeXNHVjF5bVF4VHgxcThUNlFZ?=
 =?utf-8?B?azMwRHNwVGZUOTVlNGlUMTl3WTVVNksvK3gwWnA4R1M4VTBPRHFrYVFsbG9q?=
 =?utf-8?B?VFg3TVUySEkyNFVFbDdsR3RJOVE4dk9JR3VkZkRrVVBYMGdZVTg4dFZpbEJI?=
 =?utf-8?B?bnQ2TndPVjhtQnNLeVBSQXUzbUdDV2x3aXN6d3dxb1BkQkdUM0pXK3ArNGN6?=
 =?utf-8?B?VjZzbzBMOXpwcFlpaHhXemtKQjhWbTFOTnhqYWd6dHVuQm5Nb3RSRTcxU0Er?=
 =?utf-8?B?ZGh5dVRpSFdSRkxhVStERUI5YzRNU0xaajcrV2VIeWxxSkNwZllsZjROMS9j?=
 =?utf-8?B?ZzFGTU4yQW5nc2xKQlNQcTZXWVpLSnBWM2c0WnBHZXBvd1hsang5bytjZTJo?=
 =?utf-8?B?NkIrNDV4RFNCckJJVW9QMGphbUJDRmdKR2JsMWZXR0FjUFZGcjd4UjFhTWJw?=
 =?utf-8?B?SDdIVmR1cTRXSXdRb1lES3l1YmhwdzB2Y2Nwdzg1QkU3NUcrb214Vmd1VEhv?=
 =?utf-8?B?Z3VqL0Z2eDY5VHhOYTErc2QzSXVSYkc1WTNhWFFONEFqZWxpSlFzelFBK3dQ?=
 =?utf-8?Q?pte5PWEdE4U=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)(376014)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?dmtIejU2MzJLam96RkVKQ1p1TWhVeU5KSmo2VW81UVUrNmdpY2tOSFhNOEIr?=
 =?utf-8?B?VG5qVWJyL25nRnZCWm83M05yY1RNWUJlVjhUMDVZKzdDMysvSW1tOGNHTWEw?=
 =?utf-8?B?UTVFb1BHOUl5cmZmaVdSemNqZFdoMkNRZnNBZWJCRVk2V1lEZ2owQ093WWIr?=
 =?utf-8?B?UytZalQ1UThHYzlKZFJTeHhJb2MyNitEL3JtVXEyVnY5YjduVFVLMUdCSUlu?=
 =?utf-8?B?RHJyYVU5TDJSdFpuMzg3Slh5TGMrZmg5N1VtdXM1QklrSmtDS0N3eERnUVVh?=
 =?utf-8?B?T2pSUUd6RXJDZjh2Lzk3MlpicGk3dVA1d1VSeEhFdDZaWjV3ZGgyNjl4emQr?=
 =?utf-8?B?QTVzd2xCRHVjTEJqVkkvYWhvR0FiVUtUeU1INkVZc29JazJaa2IxY1JVRVps?=
 =?utf-8?B?VWt2NVY4WWRyVnpITEIzcHgrR0ZOaEpLYlk1blNUQThMVXE5LzUrSkcvdlpF?=
 =?utf-8?B?UmtWZENrL0lMVndLemxJeE0vdFVZMnhCZnFoSUwrbVdrVlpISFh5cmNkeDFy?=
 =?utf-8?B?ZlAzeUNkTmYrN0Y3MklsSFBucXNoQTNnZkx0UWcxUklHZ3IwNUpvaXN0ekxX?=
 =?utf-8?B?S2lMclgxOXdDdDNxRkEybWhncmsvWFZSV2xHNVEzRjJ2ZjZwdHl0QmhhNDJY?=
 =?utf-8?B?MCt2L3p0UjloK3dXT2JRb3MrMDFsMUVGTlBrbEVic0FiYk5qbE5TRXh4RFVn?=
 =?utf-8?B?bnFNOGd1eTkrdUxyMThNYWpkMUJjTVBrcktRQXVqbkhCa0JSMmdCNXF2Tmw3?=
 =?utf-8?B?QmQrN0Y2ZXJ5K1lBMnRTdWU0ejhNdnJhRjZCRG51S0QwcmY0TUd2RlpLbzBD?=
 =?utf-8?B?cVJyYjA0VDlRNkxsOHpTWThubjN1blo4dDh3WlNQVzEza1R0cmk3dE5sc3dL?=
 =?utf-8?B?RmRSU1FGNk9vZU1Dd3ZuS09Kay8xSTE4UFJCZDF6V1dpTkZpZklKWFFkSWxS?=
 =?utf-8?B?Vk91ak1NbktRUFhBNGwvRXh1TGlJMXlabGR6T3FuaGdNRFRZcHh2V3BtNCtx?=
 =?utf-8?B?Q2NORXZJQzcwM0RiYzNaL1dITzV0UWhrYzAyWXZYaVpjcEFRREtwZlNsbWxz?=
 =?utf-8?B?U1pGcVlyT1JaQ1FUbEIyeGFIYXE4R0YyNTdNMGdvRm9HSEMzTTNLZExhalBK?=
 =?utf-8?B?RlI5Yitjc1pmVHFVRnJ4VmU2cHFuOGFnSFErS1EwR2pSWkN6U1BLd29RbHUr?=
 =?utf-8?B?VGc5Z1IzblF2dHRmVlRGeHQzaWEvNldKQ1NyUEs5bys2TlBINnZPNWhXNFF4?=
 =?utf-8?B?YmRGTUZkOTRQUitRWGpEWXFvbVZva3RZQ2pweTkyWE1mSFV6SHhuQ2NGS2Vj?=
 =?utf-8?B?R0JKVFlKcG5CbFlEVDFYQmFZbU9rWmc0Nk1EMGF3NDRVOEMzZ0tGbFpacTRq?=
 =?utf-8?B?OGdTTEFZdmdjNWsyMUJmcms2cHY2K1NxTXpYMGFWc1dqeFRtSmg1b2JQZEZK?=
 =?utf-8?B?bFJMem9kZklsSXFRL00zcVpYMFhJSkNBejlPTk5ZOVBoOEFWUHNtMC9KTWI4?=
 =?utf-8?B?MWlHRUtER2RObzNUSjArWTFPSThRbTVUdDFDTDFGVzcxUGxrbzFMeVlvdWM0?=
 =?utf-8?B?ZEZaUkoxWTArNjA5S2NEVDhUSVVKVFpXbnQ5S2M2NXBTaVl2N2E3bkxXVkZx?=
 =?utf-8?B?RkRTYVJYNC9mQSt3c3Z5MUxTR0hocWowTkF2cE9kRlUxcDYyMWN5RXlPUm15?=
 =?utf-8?B?Ni91NDRHNDMzT0tnMk45WTNqT0dUZWZGWVN4dFl2ZzZ6R1VBdkEzMit4eWFz?=
 =?utf-8?B?dks5ZzlPRnJ3eitUZzlTMjFpNFhobE5HRHpENktXMXltUVhCbU1XZDc4L0Jh?=
 =?utf-8?B?dk42TnFOZG5kWTV6RWtzZG1uSFY2SW1aWThjdmNGNHhOTG9Bd0t4MmhGZG05?=
 =?utf-8?B?bHZQUHl6V0N6TzRRQkZPSW9CTjlvSHZubmx2OU5LS2Jady9YbkVoQmlnOE9B?=
 =?utf-8?B?ZVcrTWgzSHZBcXZFdEJkU09PeWJ4MXdmT0JFMk9JRVFWMHpHS0dsUmNMWlEz?=
 =?utf-8?B?N0pwYzFmR3dDdEE2Q3FoMXN2Z2dXVHE5TlVsdTJhdHhyVmpRcVVERmdnTGhS?=
 =?utf-8?B?dnJrZWNHS3pMOC94QzBhaG1hYmhEY09XVGJLbWRTaUdwaTBsZXc5bm92VGNq?=
 =?utf-8?Q?IG3bMCHDBa5xHy8m1qIyTZ3wB?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5c0f4fa3-5835-484a-fe19-08dda4366ee2
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jun 2025 13:39:45.5190
 (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: 4RhbYHd63zU7pELQCRF17fglTFltIXYtJgp6Xv7KghEEekkrKg0zpgalHaBfLVYfZORrM1kngjP+xjWGu9f7UA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB7863

Hi Michal,

On 05/06/2025 08:06, Orzel, Michal wrote:
>
> On 04/06/2025 19:43, Ayan Kumar Halder wrote:
>> Introduce pr_t typedef which is a structure having the prbar and prlar members,
>> each being structured as the registers of the AArch32 Armv8-R architecture.
>>
>> Also, define MPU_REGION_RES0 to 0 as there are no reserved 0 bits beyond the
>> BASE or LIMIT bitfields in prbar or prlar respectively.
>>
>> Move pr_t definition to common code.
>> Also, enclose xn_0 within ARM64 as it is not present for ARM32.
>>
>> Signed-off-by: Ayan Kumar Halder 
>> ---
>>   xen/arch/arm/include/asm/arm32/mpu.h | 30 +++++++++++++++++++++++-----
>>   xen/arch/arm/include/asm/arm64/mpu.h |  6 ------
>>   xen/arch/arm/include/asm/mpu.h       |  6 ++++++
>>   xen/arch/arm/mpu/mm.c                |  2 ++
>>   4 files changed, 33 insertions(+), 11 deletions(-)
>>
>> diff --git a/xen/arch/arm/include/asm/arm32/mpu.h b/xen/arch/arm/include/asm/arm32/mpu.h
>> index f0d4d4055c..ae3b661fde 100644
>> --- a/xen/arch/arm/include/asm/arm32/mpu.h
>> +++ b/xen/arch/arm/include/asm/arm32/mpu.h
>> @@ -5,11 +5,31 @@
>>   
>>   #ifndef __ASSEMBLY__
>>   
>> -/* MPU Protection Region */
>> -typedef struct {
>> -    uint32_t prbar;
>> -    uint32_t prlar;
>> -} pr_t;
>> +#define MPU_REGION_RES0       0x0
> The name of the macro does not make a lot of sense in AArch32 context
> and can create a confusion for the reader.

I know, but I want to avoid introducing ifdef or have separate 
implementation (for arm32 and arm64) for the following

Refer xen/arch/arm/include/asm/mpu.h

static inline void pr_set_base(pr_t *pr, paddr_t base)
{
     pr->prbar.reg.base = ((base & ~MPU_REGION_RES0) >> MPU_REGION_SHIFT);
}

Let me know your preference.

>
>> +
>> +/* Hypervisor Protection Region Base Address Register */
>> +typedef union {
>> +    struct {
>> +        unsigned int xn:1;       /* Execute-Never */
>> +        unsigned int ap_0:1;     /* Acess Permission */
> If you write AP[1] below, I would expect here AP[0]

Again same reason as before, let me know if you want to have additional 
ifdef in pr_of_addr() or separate functions for arm32 and arm64

pr_t pr_of_addr(...)

{...

     prbar = (prbar_t) {
         .reg = {
#ifdef CONFIG_ARM64
             .xn_0 = 0,
#endif
             .xn = PAGE_XN_MASK(flags),
             .ap_0 = 0,
             .ro = PAGE_RO_MASK(flags)
         }};

...

}

> Also s/acess/access/
Ack.
>
>> +        unsigned long ro:1;      /* Access Permission AP[1] */
>> +        unsigned int sh:2;       /* Sharebility */
>> +        unsigned int res0:1;     /* Reserved as 0 */
> Here your comment for RES0 (which IMO could be just RES0) does not match...
I will remove the comment here and ..
>
>> +        unsigned int base:26;    /* Base Address */
>> +    } reg;
>> +    uint32_t bits;
>> +} prbar_t;
>> +
>> +/* Hypervisor Protection Region Limit Address Register */
>> +typedef union {
>> +    struct {
>> +        unsigned int en:1;     /* Region enable */
>> +        unsigned int ai:3;     /* Memory Attribute Index */
>> +        unsigned int res0:2;   /* Reserved 0 by hardware */
> this one. I don't think you need to explain what RES0 means.

here.

- Ayan

>
> ~Michal
>


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 14:10:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 14:10:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006915.1386170 (Exim 4.92)
	(envelope-from )
	id 1uNBIX-00005L-Od; Thu, 05 Jun 2025 14:10:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006915.1386170; Thu, 05 Jun 2025 14: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 1uNBIX-00005E-LG; Thu, 05 Jun 2025 14:10:25 +0000
Received: by outflank-mailman (input) for mailman id 1006915;
 Thu, 05 Jun 2025 14:10: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 1uNBIW-000058-6V
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 14:10:24 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d1ad19e8-4216-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 16:10:22 +0200 (CEST)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-ad883afdf0cso197013466b.0
 for ; Thu, 05 Jun 2025 07:10:22 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ada5e2bf051sm1256969566b.122.2025.06.05.07.10.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 07:10:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d1ad19e8-4216-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749132622; x=1749737422; 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=7MPcf/gXrO/twwLlDjHtT51ZHXLOI2tdCuqem5hsrwY=;
        b=Fy8vh2RZb8n5d/F+KinoFI2MeOJ9rDj3XhzS2zqw3PKoFbcCPTSYfG+8bvPtwHlZWu
         Ne0/lKd5ZXnO1iN7DVP+nU4xiMTlOeb4nnfQv0HyYcCV4ocdW9mxLTPPAFBD0duQ6E2s
         BV4K/8SDQHoZxYOYGTYF5aHklVfY3W5QrnDEKG6UkMVryN+e3l2x1z0ilWEunx0AcQMc
         2NjnQLeK05Qm1regYmEyRiS/O3vploE9hBESjw6PWvslhWVMvuM9itGUXFkxA3WqjEtC
         z17hm0NMz6zEWQ8ymoF9Phx7MJH6QyBJCx2Sn20mHVkeZOdL60U2tKs9ejxvQMVM25N6
         jAmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749132622; x=1749737422;
        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=7MPcf/gXrO/twwLlDjHtT51ZHXLOI2tdCuqem5hsrwY=;
        b=w2a6ozypDsd8BvJeGkye/C6oCDu2HbnlBN46/jLBNRo0K0gL4+uhe/Jd6mF+Dt1XZq
         kgT048iE1kqSzHD4LF2ZGfiv7Idq6Rn0CfPjtl8JdnDYFHh748NfFou5ilfJZcj88hgB
         3wWW4BR7feo3A+mG1iBD4fV6S/OAzXI+DSdllEfjXWZxixycakzZPhj1aOa2dMEsNjII
         JpUbIeoc4CEXnQ92n0NIcZvYYk3OXfhhTSRag2lfp7MRrwHS2DbJ2ZUbdWg2Rq+zio2O
         YjmjCn0FQtZzZeHWmHziWSjy+r+1fu6J2+f52LIaGrBejt7aRmYyXmW1Vmu8cYYh5eh3
         WRAg==
X-Forwarded-Encrypted: i=1; AJvYcCWQSYRR0cZagRK3wN+O6Jmqz5bxTiyexkNHVkX1L6LPHpMtyGAWRDL6TI7NwUs+4t4szWJ3Ti90E1M=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxpPgaBoDu/W8bwOyeqRzo9vOSdrdDnk8/PzgJJxZX97EHLwiO1
	wOetMgakMGKhZbY84lmPInGFQKLo6CWFxVATTZ6A4tu8aFaR/vjmgWEb
X-Gm-Gg: ASbGncuYf9TpI0QTn14HtSD/W7f8zqr4gPWbgGPXOCpoJ9b8qCBeQ51X3zhbHtO36bv
	FKZS24PoKIM2//NJHIA46GwYoCHN9cZo2YI3kQ7iOHVjcG/4WHXts7pA4nx9sbIvbHhvXXP5rkQ
	3h/p/xHhSCKj7+/EwoetSwNvW4AaFfO/iDHofWMFNn3YdxqcNJXp4SNNIhUeDbP09x9vM3EKUAa
	xDmHsHhpd1DYKwHEMQV5eQBc8xX+gUtkzqoRap+6J5Q/hxQFgBwwsCpahdgVV/6Diwmc2hiHaqG
	s7X50frGCvrvT+/J6JPDXbgNX+s1qVzz5L9SmMEVmOalj4cuk/+et0FyeZ5C8/6qTVLISGSmGGR
	0poMp+Aetv3drK+atSrFUcCol
X-Google-Smtp-Source: AGHT+IGo6LVkTkiyO++lkjpqFUXwv8r2+vctKJJ8ggd9kdBI1TjGhZS5Do8GPvVTnNdnp9TDFwPOsA==
X-Received: by 2002:a17:907:94d0:b0:ad9:f54f:70a2 with SMTP id a640c23a62f3a-addf8d5c680mr573239266b.22.1749132621309;
        Thu, 05 Jun 2025 07:10:21 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------mlVo7cmWF8Yv0Ul1J0VE0lb0"
Message-ID: 
Date: Thu, 5 Jun 2025 16:10:19 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/6] xen/riscv: introduce things necessary for p2m
 initialization
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: 
 <0a03d1f38649cfd8656147f209652dff0f9d170c.1746805907.git.oleksii.kurochko@gmail.com>
 <7ef3ca26-05f5-4e86-b7c7-852b6c74a3d0@suse.com>
 <1a0d3084-9e77-4df5-936a-c1a1317c0f18@gmail.com>
 
 
 <0175c281-b669-4412-971a-545e29077b34@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <0175c281-b669-4412-971a-545e29077b34@suse.com>

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


On 6/2/25 1:04 PM, Jan Beulich wrote:
> On 23.05.2025 11:44, Oleksii Kurochko wrote:
>> On 5/22/25 6:09 PM, Jan Beulich wrote:
>>> On 22.05.2025 17:53, Oleksii Kurochko wrote:
>>>> On 5/20/25 3:37 PM, Jan Beulich wrote:
>>>>> On 09.05.2025 17:57, Oleksii Kurochko wrote:
>>>>>> +static struct page_info *p2m_get_clean_page(struct domain *d)
>>>>>> +{
>>>>>> +    struct page_info *page;
>>>>>> +
>>>>>> +    /*
>>>>>> +     * As mentioned in the Priviliged Architecture Spec (version 20240411)
>>>>>> +     * As explained in Section 18.5.1, for the paged virtual-memory schemes
>>>>>> +     * (Sv32x4, Sv39x4, Sv48x4, and Sv57x4), the root page table is 16 KiB
>>>>>> +     * and must be aligned to a 16-KiB boundary.
>>>>>> +     */
>>>>>> +    page = alloc_domheap_pages(NULL, 2, 0);
>>>>> Shouldn't this allocation come from the domain's P2M pool (which is yet
>>>>> to be introduced)?
>>>> First, I will drop p2m_get_clean_page() as it will be used only for p2m root page
>>>> table allocation.
>>>>
>>>> p2m_init() is called by domain_create() [->arch_domain_create()->p2m_init()] from create_domUs():
>>>> [https://gitlab.com/xen-project/xen/-/blob/staging/xen/common/device-tree/dom0less-build.c?ref_type=heads#L984].
>>>>
>>>> When p2m_init() is called, p2m pool isn't ready and domain isn't created yet. Last one
>>>> is also crucial for usage of p2m pool as p2m pool belongs to domain and thereby it is
>>>> using alloc_domheap_page(d, ...) (Not NULL as for allocation of p2m root table above),
>>>> so domain should be created first.
>>> Yet that is part of my point: This allocation should be against the domain,
>>> so it is properly accounted. What's the problem with allocating the root
>>> table when the pools is being created / filled?
>> I can't use pages from pool for root table as they aren't properly aligned.
>>
>> At the moment, creation of p2m pool looks like:
>>    int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
>>    {
>>        struct page_info *pg;
>>
>>        ASSERT(spin_is_locked(&d->arch.paging.lock));
>>
>>        for ( ; ; )
>>        {
>>            if ( d->arch.paging.p2m_total_pages < pages )
>>            {
>>                /* Need to allocate more memory from domheap */
>>                pg = alloc_domheap_page(d, MEMF_no_owner);
>>                if ( pg == NULL )
>>                {
>>                    printk(XENLOG_ERR "Failed to allocate P2M pages.\n");
>>                    return -ENOMEM;
>>                }
>>                ACCESS_ONCE(d->arch.paging.p2m_total_pages) =
>>                    d->arch.paging.p2m_total_pages + 1;
>>                page_list_add_tail(pg, &d->arch.paging.p2m_freelist);
>>            }
>>            ...
>>        }
>>
>>        return 0;
>>    }
>> alloc_domheap_page(d, MEMF_no_owner) allocates page table with order 0, so 4k-aligned page table.
>> But if I needed 16k for root table and it should be 16k-aligned then I still have to use
>> alloc_domheap_pages(NULL, 2, 0);
>>
>> Or do you mean that I have to something like:
>>    int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
>>    {
>>        struct page_info *pg;
>>    
>>        ASSERT(spin_is_locked(&d->arch.paging.lock));
>>    
>> +    if ( !d->arch.p2m.root )
>> +    {
>> +        unsigned int order = get_order_from_bytes(KB(16));
>> +        unsigned int nr_pages = _AC(1,U) << order;
>> +        /*
>> +        * As mentioned in the Priviliged Architecture Spec (version 20240411)
>> +        * As explained in Section 18.5.1, for the paged virtual-memory schemes
>> +        * (Sv32x4, Sv39x4, Sv48x4, and Sv57x4), the root page table is 16 KiB
>> +        * and must be aligned to a 16-KiB boundary.
>> +        */
>> +        d->arch.p2m.root = alloc_domheap_pages(d, order, MEMF_no_owner);
>> +        if ( d->arch.p2m.root == NULL )
>> +            panic("root page table hasn't been allocated\n");
>> +
>> +        clear_and_clean_page(d->arch.p2m.root);
>> +
>> +        /* TODO: do I need TLB flush here? */
>> +
>> +        ACCESS_ONCE(d->arch.paging.p2m_total_pages) =
>> +            d->arch.paging.p2m_total_pages + nr_pages;
>> +    }
>> +
>> ...
>> }
> Neither. I was thinking of you taking 4 pages off the pool in exchange for the
> order-2 allocation. Primarily to get the memory accounting right (or at least
> closer to reality).

Do you mean that I have to call 4 times page_list_remove_head(), something like
that:
--- a/xen/arch/riscv/p2m.c
+++ b/xen/arch/riscv/p2m.c
@@ -215,6 +215,44 @@ int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
          }
      }
  
+    if ( !d->arch.p2m.root )
+    {
+        unsigned int order = get_order_from_bytes(KB(16));
+        unsigned int nr_pages = _AC(1,U) << order;
+
+        if ( ACCESS_ONCE(d->arch.paging.p2m_total_pages) < nr_pages )
+            panic("Specify more xen,domain-p2m-mem-mb\n");
+
+        /*
+         * As mentioned in the Priviliged Architecture Spec (version 20240411)
+         * As explained in Section 18.5.1, for the paged virtual-memory schemes
+         * (Sv32x4, Sv39x4, Sv48x4, and Sv57x4), the root page table is 16 KiB
+         * and must be aligned to a 16-KiB boundary.
+         */
+        d->arch.p2m.root = alloc_domheap_pages(NULL, order, 0);
+        if (  d->arch.p2m.root == NULL )
+            panic("failed to allocate p2m root page table\n");
+
+        for ( unsigned int i = 0; i < nr_pages; i++ )
+        {
+            clear_and_clean_page(d->arch.p2m.root + i);
+
+            /* Return memory to domheap */
+            pg = page_list_remove_head(&d->arch.paging.p2m_freelist);
+            if( pg )
+            {
+                ACCESS_ONCE(d->arch.paging.p2m_total_pages)--;
+                free_domheap_page(pg);
+            }
+            else
+            {
+                printk(XENLOG_ERR
+                       "Failed to free P2M pages, P2M freelist is empty.\n");
+                return -ENOMEM;
+            }
+        }
+    }
+
      return 0;
  }

>>>>>> +static int p2m_alloc_table(struct domain *d)
>>>>>> +{
>>>>>> +    struct p2m_domain *p2m = p2m_get_hostp2m(d);
>>>>>> +
>>>>>> +    p2m->root = p2m_allocate_root(d);
>>>>>> +    if ( !p2m->root )
>>>>>> +        return -ENOMEM;
>>>>>> +
>>>>>> +    p2m->hgatp = hgatp_from_page_info(p2m->root);
>>>>>> +
>>>>>> +    /*
>>>>>> +     * Make sure that all TLBs corresponding to the new VMID are flushed
>>>>>> +     * before using it.
>>>>>> +     */
>>>>>> +    p2m_write_lock(p2m);
>>>>>> +    p2m_force_tlb_flush_sync(p2m);
>>>>>> +    p2m_write_unlock(p2m);
>>>>> While Andrew directed you towards a better model in general, it won't be
>>>>> usable here then, as the guest didn't run on any pCPU(s) yet. Imo you
>>>>> want to do a single global flush e.g. when VMIDs wrap around. That'll be
>>>>> fewer global flushes than one per VM creation.
>>>> I am not sure that I get a phrase 'VMIDs wrap around'.
>>> You have to allocate them somehow. Typically you'll use the next one available.
>>> At some point you will need to start over, searching from the beginning. Prior
>>> to that now allocation of a new one will require any flush, as none of them
>>> had be in use before (after boot or the last such flush).
>> Thanks. Now I get your point.
>>
>> Won't be better to do TLB flushing during destroying of a domain so then we will
>> be sure that TLBs connected to freed VMID aren't present in TLB anymore?
> That's an option, but will result in more flushes. Furthermore there may be
> reasons to change the VMID for a domain while it's running.
>
>> IIUC, it will work only if VMID is used, right?
> Well, anything VMID related is of course only relevant when VMIDs are in use.
>
>> In case if VMID isn't used, probably we can drop flushing here and do a flush
>> during booting, right?
> That'll be too little flushing?

I meant that instead of having TLB flush in p2m_alloc_table() we could have a one flush
during booting. And of course, we still should have flush on each context switch.

>
>> Won't be enough to flushing of guest TLB only during context switch?
> "only" is interesting here. Context switches are a relatively frequent
> operation, which in addition you want to be fast. If a flush is necessary
> there for correctness (e.g. when VMIDs aren't in use), you have to do it
> there. But if you can flush less frequently without violating correctness,
> you'd almost always want to use such an opportunity.

Then it is better to introduce VMID now, it seems it's only one place where
it should be set, when hgatp is initialized.

Does Xen have some framework to work with VMID?

>
>>>> I am going to implement, p2m_force_tlb_flush_sync() as:
>>>>     static void p2m_force_tlb_flush_sync(struct p2m_domain *p2m)
>>>>     {
>>>>       ...
>>>>         sbi_remote_hfence_gvma(d->dirty_cpumask, 0, 0);
>>>>       ...
>>>>     }
>>>>
>>>> With such implementation if the guest didn't run on any pCPU(s) yet
>>>> then d->dirty_cpumask is empty, then sbi_remote_hfence_gvma() will do nothing
>>>> as hmask will be NULL (https://gitlab.com/xen-project/people/olkur/xen/-/blob/staging/xen/arch/riscv/sbi.c?ref_type=heads#L238).
>>>> I am not sure that it is a good idea as I can't find a guarantee in the spec
>>>> that TLB will be empty during boot time.
>>> If in doubt, do one global flush while booting.
>> By booting you mean somewhere in continue_new_vcpu()?
> I don't particularly mean any specific place. However, continue_new_vcpu()
> (by its name) isn't involved in bringing up Xen, is it?
>
No, it isn't. By booting here I meant a boot of a guest domain, not Xen itself.

~ Oleksii

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



  
    
  
  
    

    
    
    
    
    On 6/2/25 1:04 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 23.05.2025 11:44, Oleksii Kurochko wrote:

    
      
    
        
    On 5/22/25 6:09 PM, Jan Beulich wrote:

    
        
    
          
    On 22.05.2025 17:53, Oleksii Kurochko wrote:

    
          
    
            
    On 5/20/25 3:37 PM, Jan Beulich wrote:

    
            
    
              
    On 09.05.2025 17:57, Oleksii Kurochko wrote:

    
              
    
                
    +static struct page_info *p2m_get_clean_page(struct domain *d)
+{
+    struct page_info *page;
+
+    /*
+     * As mentioned in the Priviliged Architecture Spec (version 20240411)
+     * As explained in Section 18.5.1, for the paged virtual-memory schemes
+     * (Sv32x4, Sv39x4, Sv48x4, and Sv57x4), the root page table is 16 KiB
+     * and must be aligned to a 16-KiB boundary.
+     */
+    page = alloc_domheap_pages(NULL, 2, 0);

    
              
    
              
    Shouldn't this allocation come from the domain's P2M pool (which is yet
to be introduced)?

    
            
    
            
    First, I will drop p2m_get_clean_page() as it will be used only for p2m root page
table allocation.

p2m_init() is called by domain_create() [->arch_domain_create()->p2m_init()] from create_domUs():
[https://gitlab.com/xen-project/xen/-/blob/staging/xen/common/device-tree/dom0less-build.c?ref_type=heads#L984].

When p2m_init() is called, p2m pool isn't ready and domain isn't created yet. Last one
is also crucial for usage of p2m pool as p2m pool belongs to domain and thereby it is
using alloc_domheap_page(d, ...) (Not NULL as for allocation of p2m root table above),
so domain should be created first.

    
          
    
          
    Yet that is part of my point: This allocation should be against the domain,
so it is properly accounted. What's the problem with allocating the root
table when the pools is being created / filled?

    
        
    
        
    I can't use pages from pool for root table as they aren't properly aligned.

At the moment, creation of p2m pool looks like:
  int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
  {
      struct page_info *pg;

      ASSERT(spin_is_locked(&d->arch.paging.lock));

      for ( ; ; )
      {
          if ( d->arch.paging.p2m_total_pages < pages )
          {
              /* Need to allocate more memory from domheap */
              pg = alloc_domheap_page(d, MEMF_no_owner);
              if ( pg == NULL )
              {
                  printk(XENLOG_ERR "Failed to allocate P2M pages.\n");
                  return -ENOMEM;
              }
              ACCESS_ONCE(d->arch.paging.p2m_total_pages) =
                  d->arch.paging.p2m_total_pages + 1;
              page_list_add_tail(pg, &d->arch.paging.p2m_freelist);
          }
          ...
      }

      return 0;
  }
alloc_domheap_page(d, MEMF_no_owner) allocates page table with order 0, so 4k-aligned page table.
But if I needed 16k for root table and it should be 16k-aligned then I still have to use
alloc_domheap_pages(NULL, 2, 0);

Or do you mean that I have to something like:
  int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
  {
      struct page_info *pg;
  
      ASSERT(spin_is_locked(&d->arch.paging.lock));
  
+    if ( !d->arch.p2m.root )
+    {
+        unsigned int order = get_order_from_bytes(KB(16));
+        unsigned int nr_pages = _AC(1,U) << order;
+        /*
+        * As mentioned in the Priviliged Architecture Spec (version 20240411)
+        * As explained in Section 18.5.1, for the paged virtual-memory schemes
+        * (Sv32x4, Sv39x4, Sv48x4, and Sv57x4), the root page table is 16 KiB
+        * and must be aligned to a 16-KiB boundary.
+        */
+        d->arch.p2m.root = alloc_domheap_pages(d, order, MEMF_no_owner);
+        if ( d->arch.p2m.root == NULL )
+            panic("root page table hasn't been allocated\n");
+
+        clear_and_clean_page(d->arch.p2m.root);
+
+        /* TODO: do I need TLB flush here? */
+
+        ACCESS_ONCE(d->arch.paging.p2m_total_pages) =
+            d->arch.paging.p2m_total_pages + nr_pages;
+    }
+
...
}

    
      
    
      
    Neither. I was thinking of you taking 4 pages off the pool in exchange for the
order-2 allocation. Primarily to get the memory accounting right (or at least
closer to reality).
    
    
    
    
    Do you mean that I have to call 4 times page_list_remove_head(), something like
that:
--- a/xen/arch/riscv/p2m.c
+++ b/xen/arch/riscv/p2m.c
@@ -215,6 +215,44 @@ int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
         }
     }
 
+    if ( !d->arch.p2m.root )
+    {
+        unsigned int order = get_order_from_bytes(KB(16));
+        unsigned int nr_pages = _AC(1,U) << order;
+
+        if ( ACCESS_ONCE(d->arch.paging.p2m_total_pages) < nr_pages )
+            panic("Specify more xen,domain-p2m-mem-mb\n");
+
+        /*
+         * As mentioned in the Priviliged Architecture Spec (version 20240411)
+         * As explained in Section 18.5.1, for the paged virtual-memory schemes
+         * (Sv32x4, Sv39x4, Sv48x4, and Sv57x4), the root page table is 16 KiB
+         * and must be aligned to a 16-KiB boundary.
+         */
+        d->arch.p2m.root = alloc_domheap_pages(NULL, order, 0);
+        if (  d->arch.p2m.root == NULL )
+            panic("failed to allocate p2m root page table\n");
+
+        for ( unsigned int i = 0; i < nr_pages; i++ )
+        {
+            clear_and_clean_page(d->arch.p2m.root + i);
+
+            /* Return memory to domheap */
+            pg = page_list_remove_head(&d->arch.paging.p2m_freelist);
+            if( pg )
+            {
+                ACCESS_ONCE(d->arch.paging.p2m_total_pages)--;
+                free_domheap_page(pg);
+            }
+            else
+            {
+                printk(XENLOG_ERR
+                       "Failed to free P2M pages, P2M freelist is empty.\n");
+                return -ENOMEM;
+            }
+        }
+    }
+
     return 0;
 }


    
    
    
      
    
        
    
          
    
            
    
              
    
                
    +static int p2m_alloc_table(struct domain *d)
+{
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+    p2m->root = p2m_allocate_root(d);
+    if ( !p2m->root )
+        return -ENOMEM;
+
+    p2m->hgatp = hgatp_from_page_info(p2m->root);
+
+    /*
+     * Make sure that all TLBs corresponding to the new VMID are flushed
+     * before using it.
+     */
+    p2m_write_lock(p2m);
+    p2m_force_tlb_flush_sync(p2m);
+    p2m_write_unlock(p2m);

    
              
    
              
    While Andrew directed you towards a better model in general, it won't be
usable here then, as the guest didn't run on any pCPU(s) yet. Imo you
want to do a single global flush e.g. when VMIDs wrap around. That'll be
fewer global flushes than one per VM creation.

    
            
    
            
    I am not sure that I get a phrase 'VMIDs wrap around'.

    
          
    
          
    You have to allocate them somehow. Typically you'll use the next one available.
At some point you will need to start over, searching from the beginning. Prior
to that now allocation of a new one will require any flush, as none of them
had be in use before (after boot or the last such flush).

    
        
    
        
    Thanks. Now I get your point.

Won't be better to do TLB flushing during destroying of a domain so then we will
be sure that TLBs connected to freed VMID aren't present in TLB anymore?

    
      
    
      
    That's an option, but will result in more flushes. Furthermore there may be
reasons to change the VMID for a domain while it's running.


    
      
    
        
    IIUC, it will work only if VMID is used, right?

    
      
    
      
    Well, anything VMID related is of course only relevant when VMIDs are in use.


    
      
    
        
    In case if VMID isn't used, probably we can drop flushing here and do a flush
during booting, right?

    
      
    
      
    That'll be too little flushing?
    
    
    
    
    I meant that instead of having TLB flush in p2m_alloc_table() we could have a one flush
during booting. And of course, we still should have flush on each context switch.


    
    
    
      
    

    
      
    
        
    Won't be enough to flushing of guest TLB only during context switch?

    
      
    
      
    "only" is interesting here. Context switches are a relatively frequent
operation, which in addition you want to be fast. If a flush is necessary
there for correctness (e.g. when VMIDs aren't in use), you have to do it
there. But if you can flush less frequently without violating correctness,
you'd almost always want to use such an opportunity.
    
    
    
    
    Then it is better to introduce VMID now, it seems it's only one place where
it should be set, when hgatp is initialized.

Does Xen have some framework to work with VMID?

    
    
    
      
    

    
      
    
        
    
          
    
            
    I am going to implement, p2m_force_tlb_flush_sync() as:
   static void p2m_force_tlb_flush_sync(struct p2m_domain *p2m)
   {
     ...
       sbi_remote_hfence_gvma(d->dirty_cpumask, 0, 0);
     ...
   }

With such implementation if the guest didn't run on any pCPU(s) yet
then d->dirty_cpumask is empty, then sbi_remote_hfence_gvma() will do nothing
as hmask will be NULL (https://gitlab.com/xen-project/people/olkur/xen/-/blob/staging/xen/arch/riscv/sbi.c?ref_type=heads#L238).
I am not sure that it is a good idea as I can't find a guarantee in the spec
that TLB will be empty during boot time.

    
          
    
          
    If in doubt, do one global flush while booting.

    
        
    
        
    By booting you mean somewhere in continue_new_vcpu()?

    
      
    
      
    I don't particularly mean any specific place. However, continue_new_vcpu()
(by its name) isn't involved in bringing up Xen, is it?


    
    
    
    
    No, it isn't. By booting here I meant a boot of a guest domain, not Xen itself.

~ Oleksii

    
  


--------------mlVo7cmWF8Yv0Ul1J0VE0lb0--


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 14:15:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 14:15:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006925.1386179 (Exim 4.92)
	(envelope-from )
	id 1uNBNZ-00010Z-Cu; Thu, 05 Jun 2025 14:15:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006925.1386179; Thu, 05 Jun 2025 14:15: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 1uNBNZ-00010S-AA; Thu, 05 Jun 2025 14:15:37 +0000
Received: by outflank-mailman (input) for mailman id 1006925;
 Thu, 05 Jun 2025 14: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 1uNBNX-00010M-TD
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 14:15:36 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20626.outbound.protection.outlook.com
 [2a01:111:f403:2414::626])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 89710c9b-4217-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 16:15:33 +0200 (CEST)
Received: from BLAPR05CA0006.namprd05.prod.outlook.com (2603:10b6:208:36e::9)
 by IA1PR12MB8191.namprd12.prod.outlook.com (2603:10b6:208:3f3::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Thu, 5 Jun
 2025 14:15:26 +0000
Received: from BL6PEPF0001AB57.namprd02.prod.outlook.com
 (2603:10b6:208:36e:cafe::b4) by BLAPR05CA0006.outlook.office365.com
 (2603:10b6:208:36e::9) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.9 via Frontend Transport; Thu, 5
 Jun 2025 14:15:26 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL6PEPF0001AB57.mail.protection.outlook.com (10.167.241.9) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Thu, 5 Jun 2025 14:15:26 +0000
Received: from localhost (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, 5 Jun
 2025 09:15:24 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 89710c9b-4217-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=SnKILXxAUXUvly7zGQaxGKzEA6plHLslSkK+fAsSDLZ+zBbP0hVGnfchowUpQQDuqRMrOm024OsRpKtOqLeDO710+rAvPBRN0+yY6Dkh+XkBfbtScROEQs/wQi2B/uH5FiRI+zA3vfT/MsaWTOMX2UdyGHC3bQbqF2q1JkoGx6zHtxXz4utsbt2KfgR+kpTA6XcvMAhk3ZRNupXmZHfl2gkK8T22AJsmFa5r9cBW0MB2AIEJI7be4NUUdQ6wtx2a0ksurHYbCApsS7f/qWk0SfldcgEKAWRsVNGLyNGbAimtZp9potf2M7i35t9IgHAtCUkW79qUu833faqkjubZsA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=WHKjQfU4bxhYT26M6l0FU4nyZquQYBgbcOeFFL9KKsQ=;
 b=aAh5DlftbfHFxJQYz8U5+sKD8HURh6i+kRDfZDQCfV1dW72eyzZdk0xpVd4pT5iO8vBLXU0ZaRvi2nDkawi9YW1Xqix7qNt2mOsBGYVtKJXo2J/3Pnc2rNh3ZxB0jXQ3bBB8mtdeN/SSslFBQVSgLvabdndj5eE052CYie6WeV73wmBrYr6bpFaMQBsUZJZt15TO+u0Wp4oNCKd7q9qnnf+RgUhqRmHjy6q49eMnRSVP5fYLzGRzI+4mzlog5jRoPKISErDMQGp2x9JSE/G6tfRKDrcxo/CQ1QeZCNgGnvzYkmIdl9r06hBdXaAx1YFGavfiKR+AZXnMGOH1Va67Bg==
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=WHKjQfU4bxhYT26M6l0FU4nyZquQYBgbcOeFFL9KKsQ=;
 b=U6isFvUSMriRi7J7vhBJ9fI4O4d06no4PypNaWRMdsXC4KDRYKP9tUfeNLKsk7FZ6zI7aZNCAZmUOpDjx4NY/mDuKZYJjsU1ql8itkrI+yzeb+q8q/mH7vTWBAs3YxPB8wivSndVJw2GPerpf723jSHs3oRbsqPP2cYYNxnYVDg=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 5 Jun 2025 16:15:23 +0200
Message-ID: 
To: Jan Beulich 
CC: Alistair Francis , Bob Eshleman
	, Connor Davis , "Oleksii
 Kurochko" , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	=?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini
	, "Daniel P. Smith" ,
	
Subject: Re: [PATCH 06/19] xen: Clean up asm-generic/device.h
From: Alejandro Vallejo 
X-Mailer: aerc 0.20.1
References: 
 <20250530120242.39398-1-agarciav@amd.com>
 <20250530120242.39398-7-agarciav@amd.com>
 
 
 
In-Reply-To: 
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: BL6PEPF0001AB57:EE_|IA1PR12MB8191:EE_
X-MS-Office365-Filtering-Correlation-Id: 29f00e70-14a7-4d2f-7451-08dda43b6b70
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|1800799024|7416014|376014|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?b0Z0QVVlZExoUVJ1cG1LN3NKRXk2Q1BZQXNsazZuNWk4bDFudnVJTWx3Wlhv?=
 =?utf-8?B?UUUyZDd0MXZRY29rZld2OWFDaFFleGo4eFNmTFVqQXdyQ0pNTlFKNjlNVkVJ?=
 =?utf-8?B?cU91OHBidGE5WHBmbWtQZjdoRURDbTN2UGdnV3NCRGhhbEJ4NTRINXJteCth?=
 =?utf-8?B?VFBSdDVoazhtWUlzV3p1VzUzdHdCQisvaERTS0V5WGYwMFpSRnRTc0Zxa01F?=
 =?utf-8?B?MVVIYTRBNDFvRk1tREtPODBhMXVtZ3VKZlg2ZzRBcGoxWW1iWjFtTVU3UHV0?=
 =?utf-8?B?eGIxVFRBcHF0V082azh3KzZnd3ZRV1poaFl1Qk53UzN1TFdsSWhhUzRTVnR1?=
 =?utf-8?B?d0FUTTRiVGdVR1crZ3ZqMnpqTnE5N0k4NEVkYzFDRGF6S1FWamkwRHRQYzQ5?=
 =?utf-8?B?U25SWE1RN2czdCs3RVlacE1MLzc0QnA5bkNUS1g5VTJvYkNFRFdKR2Vtejg0?=
 =?utf-8?B?aXFXUHhORmUvcUF4bU9uY1lQU1dYa21iMFNGOXdTbW9sY1p1bDVtUk9EK3Nx?=
 =?utf-8?B?eHNQd0lNcitOVnFHOFpzSjJoOFVsSlZyTjM5QUloK29xb3BseGhyMllncU5i?=
 =?utf-8?B?STJVMlN5Sk1ybVdKc3RDYW9SWXJyTFVxSmdJeVYvVkhwK0xVTTNBQWxBOUMx?=
 =?utf-8?B?SWFndXhJRVlNTWVDZjNJcGhqRUhIRmtkdXhZOGtXSkQ4UjY2T0NHeTNubU9W?=
 =?utf-8?B?N1V3N2h2M1RwRURYenBCWGxoa2tPV01OSW5oc0J1VkZkT3RoOEZXbktnczBF?=
 =?utf-8?B?dnhnZVZlYUFZU09ZR2twczdTNk12NmNMdnY4R0NiM3JiM0wwNVZUdW94Wkc3?=
 =?utf-8?B?TlpaMXlEQjBCWEFtZUcrN2VoWWVERnlEMmROS1dyaUFJdStUMkprMXk0ZVJS?=
 =?utf-8?B?RTdMam5IUmJpeWEwRlBscmlXbDNYdTVqanBBdkdBL04yc1dlYmFCb043VnNB?=
 =?utf-8?B?VFJFbnFaTWpDditTWTR6ZWwyV0pudVF0dW1WNkFQOWRoZ2RzTDV4R1pucWpx?=
 =?utf-8?B?aWhINHYrcHFkM3FsV2Jick5oeFFsZGdRVktKZEhmMlJ4bEZUdlZhMlFCUWhi?=
 =?utf-8?B?RXhJc25UTjFoRWVubkN0RFJweUpJZ2h6MlYwMzRCbWNQd2VMQ1BaNDlJRytx?=
 =?utf-8?B?NEU2QlF5aVNsUmcvTEhhMUxlMkl0YmJqKzFTZWd0ZGxmcDEzTUtIdUV1NGR6?=
 =?utf-8?B?NGo5akM2YWxjNmVSUjczWEtZdVpwcjd6YnZXaFJDZ085SzVvSmcrT0FTOFA4?=
 =?utf-8?B?Mmt3OWNrN0dVWWJjZXVOWTVSZUF4NllXYnV1eFQvVnIzSkpGVlFBNHdoa3Zh?=
 =?utf-8?B?NnY1VTUzZUFzSVhRRnVIOTJySDJUak1CSFVqZmRCTE5pQjU4cjNIUWRBMTlD?=
 =?utf-8?B?UVY3MXpuNjJXSlNhSDM0N1NCVnY4VU9hNlh3dmgwalRMZkVINUJtZU5QZHNT?=
 =?utf-8?B?UWpFOFBQSnVORlZVdEtFOVBYdE9jUENhekJ3SUVnZlBjZ2NlSjJhU082aHJR?=
 =?utf-8?B?RCt1N0cvTFRxc0FocjdGWDBFUzhDQ2dGekFLbjBlTmozc0JTVXJUYlZPVlhu?=
 =?utf-8?B?d0xoZUpVZGxyWTVpc2VVYjdQMUxTQlpjNVBZSDdyMWt6OXIyQXQ5OUVGSll6?=
 =?utf-8?B?RldNckRMNW92dWxOSEtBUEUrYit1N1MzUGZSd1ZyQkE0U0hNT0gxUjRYOS8r?=
 =?utf-8?B?YWh5TDFhNEJjYnJ1MkxwS2s2bllCSzJIZDlzOSsvK0hZM2NhZjJIaUhab2pL?=
 =?utf-8?B?SlJqaXlRT3Rqb0xmbk9FUDVTaG9JR2s5aW1hNHZ1L3dZWmFEaVI2UWtyU2VL?=
 =?utf-8?B?MjJWTVJTeGRsQklQTnJTc0VQQVFwSm84OHg4aERJNzZ0U1A1U25nMW5vQW50?=
 =?utf-8?B?SEV5clJtcGkrZmI0Uy90aWp2US9SRXowd3FPdExaWXlnYnB2QytKaFB4VmtV?=
 =?utf-8?B?WDhGV1RnRW45VnFiNWV2SjlkaDlFUjdGNVZmU1RTOXRwZC9aU3c0NENtQy81?=
 =?utf-8?B?ajZVSWxBSGx0WGsrZm8zV3BSZjFWdHNOblRiN05UYTJLMHluazZZb1hjZHlh?=
 =?utf-8?Q?o6/hEz?=
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)(7416014)(376014)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jun 2025 14:15:26.8600
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 29f00e70-14a7-4d2f-7451-08dda43b6b70
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:
	BL6PEPF0001AB57.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB8191

On Mon Jun 2, 2025 at 4:24 PM CEST, Jan Beulich wrote:
> On 02.06.2025 16:19, Alejandro Vallejo wrote:
>> On Mon Jun 2, 2025 at 9:51 AM CEST, Jan Beulich wrote:
>>> On 30.05.2025 14:02, Alejandro Vallejo wrote:
>>>> --- a/xen/include/asm-generic/device.h
>>>> +++ b/xen/include/asm-generic/device.h
>>>> @@ -6,9 +6,7 @@
>>>> =20
>>>>  enum device_type
>>>>  {
>>>> -#ifdef CONFIG_HAS_DEVICE_TREE
>>>>      DEV_DT,
>>>> -#endif
>>>
>>> Why would this enumerator need exposing on a non-DT arch? In fact I wou=
ld have
>>> hoped for ...
>>=20
>> A non-DT arch would not include this. x86 doesn't.
>
> Both here and ...
>
>>>>      DEV_PCI
>>>
>>> ... this to be hidden for arch-es not supporting PCI.
>>>
>>> Similar concerns elsewhere in this change.
>>=20
>> This file is exclusively used by arches supporting DT to abstract away w=
here
>> the device came from. x86 does not use it at all, and while it wouldn't =
be
>> impossible to compile-out DEV_PCI, it would needlessly pollute the codeb=
ase with
>> no measurable gain, because the abstractions still need to stay.
>
> ... here: In "xen/include/asm-generic/device.h" there's nothing at all sa=
ying
> that this file is a DT-only one. Instead there is something in there sayi=
ng
> that it's suitable to use in the entirely "generic" case.
>
> Jan

Try to use it from x86 and observe the build system catch fire. It could be=
 made
to not go on fire, but it implies heavy refactoring in x86 (particularly IO=
MMU
code) for no good reason because there's no devices in a DTB to disambiguat=
e.

How about adding this to the top of the header?

```
 /*
  * This header helps DTB-based architectures abstract away where a particu=
lar
  * device comes from; be it the DTB itself or enumerated on a PCI bus.=20
  */

  [snip]

 #ifndef CONFIG_HAS_DEVICE_TREE
 #error "Header meant to be used exclusively by DTB-base architectures."
 #endif
```

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 14:19:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 14:19:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006931.1386189 (Exim 4.92)
	(envelope-from )
	id 1uNBR9-0001XQ-RJ; Thu, 05 Jun 2025 14:19:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006931.1386189; Thu, 05 Jun 2025 14: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 1uNBR9-0001XJ-OJ; Thu, 05 Jun 2025 14:19:19 +0000
Received: by outflank-mailman (input) for mailman id 1006931;
 Thu, 05 Jun 2025 14:19:17 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uNBR7-0001Wx-Og
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 14:19:17 +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 0ffdc22c-4218-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 16:19:16 +0200 (CEST)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-60461fc88d7so2011159a12.0
 for ; Thu, 05 Jun 2025 07:19:16 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ada5d82d75bsm1270928466b.56.2025.06.05.07.19.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 07:19:15 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0ffdc22c-4218-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749133156; x=1749737956; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=rBsXLH+5x3o6U0TQhEf+zYxaUMXg/2xL2PPFdOR1Y9U=;
        b=dR15qdgIX7onL9rnT4WbvBhjaQncbDV43u3W4TqRA1PO960ID2pDgC+geexhWvbVNa
         DFaySsZ/F9M9Jr81MOypMgaj6brEaCRJnKpWWPVhk3Zhnql944RSmpAyONrZjudEy2gM
         aic56wT9+3xp+96mWAOBmF5J1gksWVnnQjPCYfB0I9UsKUGl2Q5GHvUTdmcqesfnuzjx
         5+cEbMOa95zjbrIpp4ISPrAkxVLJhGsuZRv8wp7HHiGS71fCNXxwIdoYnjcdQwSMV+MS
         EX093KDGOK8MKFL9GF/+uGn/mxkoajrsdbUNQUSoS11pjgIjr+6zVMCd0fMWH3pHHMyA
         RjRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749133156; x=1749737956;
        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=rBsXLH+5x3o6U0TQhEf+zYxaUMXg/2xL2PPFdOR1Y9U=;
        b=aVBHQA/4zF5/d4xEabo62LB83sc8cdCLMTprztTFDut5znl+BZNgncn9wk8I6iAvLe
         rtDzwI0vW70Z01V8ULF6FRfkaemH/c38bLCXxCqH6s/d25VAICXPvdIm4X8aSIS68xjI
         3mbiBKoA8vjW2pEF3MkIVgnxx+ZV5SSK86EDhFoDxsY6+WOSivfQs7imQ1jPBhHiKKWv
         Abnx9Tfhxb/qCeHpHD3MNl+bjhAqsJ1284evz1Kv1K5vt3AtoD2sjCEXihemyBwi4id3
         vx9Rr6BEDPSUxEIZBui1qX+yOT1mk5+Lct89gNPav5sAb4+TCEu8LC62ihOfxOQlUTkV
         OirA==
X-Forwarded-Encrypted: i=1; AJvYcCVlDPOy4ZNs7eU4MBgT1XhvhxBDoH02OCVP96/bfZT1tiXKH8AkYftwtcOnw7eFC2UlziHwjZuHyZ0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxtYCbFmLN+DhV28U3L7HPt++LN8rCGE6M4+Tljjmrsmx8R1QrJ
	HQ71xsUDT1rVdcVWwlMFCgtYz4MO39Web5ZbyWWeIMm+64g1i+mtpZ58NYMxEImOoQ==
X-Gm-Gg: ASbGncvSAc/9OAwwClWhyfhBbaMLI8E04RNMUAuBA6QWwNMvOIlrq1WMssFgvvJXtLl
	OI6xBWvNNplwDOt5Kt8QwOyqDYo0srMAF2sBaiRFTPL2n1Ant428CnRDOgzsobanWcit2yd7lPk
	KJX3s3wpj6+1PWU3OEh5kZz4JlWdKOOt4mAJoJ7AT+LHtQsu6ELhtOYtsTVo4RjMI9fx8ieIGA4
	BJPaWz6gAUFnE1IyccYWzNZYEbXOMb08x/ziIvB+CN4SH8svI9OaAIsPj11fqMsMSuI/q2EJTCo
	hD8JM/EWWcjnKTZ3ZhZF/Atxvc//UwkKbrKFG+nIqmWnLCd7ptDx1DFCX1YiGdkWybrj2vwavV0
	jE84gMVFapUFa1uHR2/0v1IRUqOtv/8qAPLu9nn2aYpbLAf4=
X-Google-Smtp-Source: AGHT+IEB3xsj7VvRIyLNXs3qZ2sTZSe7gjgv3W7r/WH5Wt68voCsNpsc0FYQLL6DfaR5/7imeQfung==
X-Received: by 2002:a17:906:6a16:b0:ad5:72d4:85ee with SMTP id a640c23a62f3a-addf8fb22e8mr681591766b.53.1749133155699;
        Thu, 05 Jun 2025 07:19:15 -0700 (PDT)
Message-ID: 
Date: Thu, 5 Jun 2025 16:19:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/6] xen/riscv: introduce things necessary for p2m
 initialization
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: 
 <0a03d1f38649cfd8656147f209652dff0f9d170c.1746805907.git.oleksii.kurochko@gmail.com>
 <7ef3ca26-05f5-4e86-b7c7-852b6c74a3d0@suse.com>
 <1a0d3084-9e77-4df5-936a-c1a1317c0f18@gmail.com>
 
 
 <0175c281-b669-4412-971a-545e29077b34@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 05.06.2025 16:10, Oleksii Kurochko wrote:
> 
> On 6/2/25 1:04 PM, Jan Beulich wrote:
>> On 23.05.2025 11:44, Oleksii Kurochko wrote:
>>> On 5/22/25 6:09 PM, Jan Beulich wrote:
>>>> On 22.05.2025 17:53, Oleksii Kurochko wrote:
>>>>> On 5/20/25 3:37 PM, Jan Beulich wrote:
>>>>>> On 09.05.2025 17:57, Oleksii Kurochko wrote:
>>>>>>> +static struct page_info *p2m_get_clean_page(struct domain *d)
>>>>>>> +{
>>>>>>> +    struct page_info *page;
>>>>>>> +
>>>>>>> +    /*
>>>>>>> +     * As mentioned in the Priviliged Architecture Spec (version 20240411)
>>>>>>> +     * As explained in Section 18.5.1, for the paged virtual-memory schemes
>>>>>>> +     * (Sv32x4, Sv39x4, Sv48x4, and Sv57x4), the root page table is 16 KiB
>>>>>>> +     * and must be aligned to a 16-KiB boundary.
>>>>>>> +     */
>>>>>>> +    page = alloc_domheap_pages(NULL, 2, 0);
>>>>>> Shouldn't this allocation come from the domain's P2M pool (which is yet
>>>>>> to be introduced)?
>>>>> First, I will drop p2m_get_clean_page() as it will be used only for p2m root page
>>>>> table allocation.
>>>>>
>>>>> p2m_init() is called by domain_create() [->arch_domain_create()->p2m_init()] from create_domUs():
>>>>> [https://gitlab.com/xen-project/xen/-/blob/staging/xen/common/device-tree/dom0less-build.c?ref_type=heads#L984].
>>>>>
>>>>> When p2m_init() is called, p2m pool isn't ready and domain isn't created yet. Last one
>>>>> is also crucial for usage of p2m pool as p2m pool belongs to domain and thereby it is
>>>>> using alloc_domheap_page(d, ...) (Not NULL as for allocation of p2m root table above),
>>>>> so domain should be created first.
>>>> Yet that is part of my point: This allocation should be against the domain,
>>>> so it is properly accounted. What's the problem with allocating the root
>>>> table when the pools is being created / filled?
>>> I can't use pages from pool for root table as they aren't properly aligned.
>>>
>>> At the moment, creation of p2m pool looks like:
>>>    int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
>>>    {
>>>        struct page_info *pg;
>>>
>>>        ASSERT(spin_is_locked(&d->arch.paging.lock));
>>>
>>>        for ( ; ; )
>>>        {
>>>            if ( d->arch.paging.p2m_total_pages < pages )
>>>            {
>>>                /* Need to allocate more memory from domheap */
>>>                pg = alloc_domheap_page(d, MEMF_no_owner);
>>>                if ( pg == NULL )
>>>                {
>>>                    printk(XENLOG_ERR "Failed to allocate P2M pages.\n");
>>>                    return -ENOMEM;
>>>                }
>>>                ACCESS_ONCE(d->arch.paging.p2m_total_pages) =
>>>                    d->arch.paging.p2m_total_pages + 1;
>>>                page_list_add_tail(pg, &d->arch.paging.p2m_freelist);
>>>            }
>>>            ...
>>>        }
>>>
>>>        return 0;
>>>    }
>>> alloc_domheap_page(d, MEMF_no_owner) allocates page table with order 0, so 4k-aligned page table.
>>> But if I needed 16k for root table and it should be 16k-aligned then I still have to use
>>> alloc_domheap_pages(NULL, 2, 0);
>>>
>>> Or do you mean that I have to something like:
>>>    int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
>>>    {
>>>        struct page_info *pg;
>>>    
>>>        ASSERT(spin_is_locked(&d->arch.paging.lock));
>>>    
>>> +    if ( !d->arch.p2m.root )
>>> +    {
>>> +        unsigned int order = get_order_from_bytes(KB(16));
>>> +        unsigned int nr_pages = _AC(1,U) << order;
>>> +        /*
>>> +        * As mentioned in the Priviliged Architecture Spec (version 20240411)
>>> +        * As explained in Section 18.5.1, for the paged virtual-memory schemes
>>> +        * (Sv32x4, Sv39x4, Sv48x4, and Sv57x4), the root page table is 16 KiB
>>> +        * and must be aligned to a 16-KiB boundary.
>>> +        */
>>> +        d->arch.p2m.root = alloc_domheap_pages(d, order, MEMF_no_owner);
>>> +        if ( d->arch.p2m.root == NULL )
>>> +            panic("root page table hasn't been allocated\n");
>>> +
>>> +        clear_and_clean_page(d->arch.p2m.root);
>>> +
>>> +        /* TODO: do I need TLB flush here? */
>>> +
>>> +        ACCESS_ONCE(d->arch.paging.p2m_total_pages) =
>>> +            d->arch.paging.p2m_total_pages + nr_pages;
>>> +    }
>>> +
>>> ...
>>> }
>> Neither. I was thinking of you taking 4 pages off the pool in exchange for the
>> order-2 allocation. Primarily to get the memory accounting right (or at least
>> closer to reality).
> 
> Do you mean that I have to call 4 times page_list_remove_head(), something like
> that:
> --- a/xen/arch/riscv/p2m.c
> +++ b/xen/arch/riscv/p2m.c
> @@ -215,6 +215,44 @@ int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
>           }
>       }
>   
> +    if ( !d->arch.p2m.root )
> +    {
> +        unsigned int order = get_order_from_bytes(KB(16));
> +        unsigned int nr_pages = _AC(1,U) << order;
> +
> +        if ( ACCESS_ONCE(d->arch.paging.p2m_total_pages) < nr_pages )
> +            panic("Specify more xen,domain-p2m-mem-mb\n");
> +
> +        /*
> +         * As mentioned in the Priviliged Architecture Spec (version 20240411)
> +         * As explained in Section 18.5.1, for the paged virtual-memory schemes
> +         * (Sv32x4, Sv39x4, Sv48x4, and Sv57x4), the root page table is 16 KiB
> +         * and must be aligned to a 16-KiB boundary.
> +         */
> +        d->arch.p2m.root = alloc_domheap_pages(NULL, order, 0);

Imo you'd better not use NULL here, but instead pass MEMF_no_owner. See
respective x86 code. I also think you want to do the freeing first, and
only then do this allocation, such that ...

> +        if (  d->arch.p2m.root == NULL )
> +            panic("failed to allocate p2m root page table\n");
> +
> +        for ( unsigned int i = 0; i < nr_pages; i++ )
> +        {
> +            clear_and_clean_page(d->arch.p2m.root + i);
> +
> +            /* Return memory to domheap */
> +            pg = page_list_remove_head(&d->arch.paging.p2m_freelist);
> +            if( pg )
> +            {
> +                ACCESS_ONCE(d->arch.paging.p2m_total_pages)--;
> +                free_domheap_page(pg);
> +            }
> +            else
> +            {
> +                printk(XENLOG_ERR
> +                       "Failed to free P2M pages, P2M freelist is empty.\n");
> +                return -ENOMEM;

... this path will not have eaten more memory than was given back.

>>>>>>> +static int p2m_alloc_table(struct domain *d)
>>>>>>> +{
>>>>>>> +    struct p2m_domain *p2m = p2m_get_hostp2m(d);
>>>>>>> +
>>>>>>> +    p2m->root = p2m_allocate_root(d);
>>>>>>> +    if ( !p2m->root )
>>>>>>> +        return -ENOMEM;
>>>>>>> +
>>>>>>> +    p2m->hgatp = hgatp_from_page_info(p2m->root);
>>>>>>> +
>>>>>>> +    /*
>>>>>>> +     * Make sure that all TLBs corresponding to the new VMID are flushed
>>>>>>> +     * before using it.
>>>>>>> +     */
>>>>>>> +    p2m_write_lock(p2m);
>>>>>>> +    p2m_force_tlb_flush_sync(p2m);
>>>>>>> +    p2m_write_unlock(p2m);
>>>>>> While Andrew directed you towards a better model in general, it won't be
>>>>>> usable here then, as the guest didn't run on any pCPU(s) yet. Imo you
>>>>>> want to do a single global flush e.g. when VMIDs wrap around. That'll be
>>>>>> fewer global flushes than one per VM creation.
>>>>> I am not sure that I get a phrase 'VMIDs wrap around'.
>>>> You have to allocate them somehow. Typically you'll use the next one available.
>>>> At some point you will need to start over, searching from the beginning. Prior
>>>> to that now allocation of a new one will require any flush, as none of them
>>>> had be in use before (after boot or the last such flush).
>>> Thanks. Now I get your point.
>>>
>>> Won't be better to do TLB flushing during destroying of a domain so then we will
>>> be sure that TLBs connected to freed VMID aren't present in TLB anymore?
>> That's an option, but will result in more flushes. Furthermore there may be
>> reasons to change the VMID for a domain while it's running.
>>
>>> IIUC, it will work only if VMID is used, right?
>> Well, anything VMID related is of course only relevant when VMIDs are in use.
>>
>>> In case if VMID isn't used, probably we can drop flushing here and do a flush
>>> during booting, right?
>> That'll be too little flushing?
> 
> I meant that instead of having TLB flush in p2m_alloc_table() we could have a one flush
> during booting. And of course, we still should have flush on each context switch.

Yet as said - context switches are likely too frequent for having an
unconditional flush there (if it can be avoided).

>>> Won't be enough to flushing of guest TLB only during context switch?
>> "only" is interesting here. Context switches are a relatively frequent
>> operation, which in addition you want to be fast. If a flush is necessary
>> there for correctness (e.g. when VMIDs aren't in use), you have to do it
>> there. But if you can flush less frequently without violating correctness,
>> you'd almost always want to use such an opportunity.
> 
> Then it is better to introduce VMID now, it seems it's only one place where
> it should be set, when hgatp is initialized.
> 
> Does Xen have some framework to work with VMID?

That's all arch-specific, I think.

>>>>> I am going to implement, p2m_force_tlb_flush_sync() as:
>>>>>     static void p2m_force_tlb_flush_sync(struct p2m_domain *p2m)
>>>>>     {
>>>>>       ...
>>>>>         sbi_remote_hfence_gvma(d->dirty_cpumask, 0, 0);
>>>>>       ...
>>>>>     }
>>>>>
>>>>> With such implementation if the guest didn't run on any pCPU(s) yet
>>>>> then d->dirty_cpumask is empty, then sbi_remote_hfence_gvma() will do nothing
>>>>> as hmask will be NULL (https://gitlab.com/xen-project/people/olkur/xen/-/blob/staging/xen/arch/riscv/sbi.c?ref_type=heads#L238).
>>>>> I am not sure that it is a good idea as I can't find a guarantee in the spec
>>>>> that TLB will be empty during boot time.
>>>> If in doubt, do one global flush while booting.
>>> By booting you mean somewhere in continue_new_vcpu()?
>> I don't particularly mean any specific place. However, continue_new_vcpu()
>> (by its name) isn't involved in bringing up Xen, is it?
>>
> No, it isn't. By booting here I meant a boot of a guest domain, not Xen itself.

Please don't call this "booting", but "starting of a guest" (or "launching" or
some such). When you originally said "booting" I thought RISC-V wouldn't
guarantee clean TLBs when being booted, and hence suggested to cover for this
by doing a single flush during (Xen) boot. Looks like this may not be needed
then, simply because of the misunderstanding.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 14:20:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 14:20:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006942.1386199 (Exim 4.92)
	(envelope-from )
	id 1uNBSZ-00033l-4U; Thu, 05 Jun 2025 14:20:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006942.1386199; Thu, 05 Jun 2025 14: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 1uNBSZ-00033e-1r; Thu, 05 Jun 2025 14:20:47 +0000
Received: by outflank-mailman (input) for mailman id 1006942;
 Thu, 05 Jun 2025 14: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 1uNBSX-00032D-Jn
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 14:20:45 +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 44693dd8-4218-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 16:20:44 +0200 (CEST)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-605b9488c28so1737299a12.2
 for ; Thu, 05 Jun 2025 07:20:44 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-60566c5c5casm10476813a12.25.2025.06.05.07.20.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 07:20:43 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 44693dd8-4218-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749133244; x=1749738044; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=kXvhzliBSn0/66s1rDoEisb24kfD7RiSMh+LlMkgfdE=;
        b=V9AW+oS0/glAMgEpos93JJNGwY4xft9jSweyG3CME+bt/8lBlsUk8amfoTGSaEC/Am
         XJETEsfGrjz1f9X+wM4F5uNZfJ/dX5gHb1EyQZeefDLXRi80HicOievXawRLaQkK2lTG
         5gm2g5u7B9/0wVBO+RqshIdxGFGQejAONhXFVas1B1zbPDuPxe0RGs/vQkfP5E5DxbAL
         q0BBBcPgmHER9mBTTGGJSvqhcqK9JthRFcIjrriV4kKvhEPXf58vSHMglyW7bIQLQ8Js
         r4vWqhUGzE7bAjCEvhyMdozenT/aGPwVFnpVLQCpjz+0mKd2xqmrNkN7e4JujUfVAM/0
         kUpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749133244; x=1749738044;
        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=kXvhzliBSn0/66s1rDoEisb24kfD7RiSMh+LlMkgfdE=;
        b=X60rbe+ezLEA4ux7DQHzyPI3puP1Y6cOmgQzc0MfVZqSfhvvTKDeC3UIsl6lCALBiT
         zCSlLmIxGwCQKEUWQN7bNHPqvASbq70AalCtr5LuG9rK49+c7LFaUF3ooG1MiRHqfTQv
         gHjEDy/atHh4FXUkRJkquV+r1LVuja1pwxM2TQ+Dc04noAlUZdO0yov/iYFEpBmdIOgR
         dnKFF4eyK0lyT6iz0nmBk4TAwy5Juq7Yuc7oW2U+LRD7hlj0zccO8pU55p+LduCwPczj
         SwMu/Sw/zKh/sHR5WWg+wnxxKeKV26wj6yEaO+VxJZ+i/oG8zTACGaIg20WFJNCN/snr
         L+SA==
X-Forwarded-Encrypted: i=1; AJvYcCWYikS/jSBtqK2rM9QVdiTcOZgW71pGeb2ApID8jPlXSp776mBDVV1HR49Hrgr7YWcvYresOOVJai8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxE9SM8C5yEeqqVaWLjEYa+IUFeBkeS66aGY8rnH0/MHK+hWUDV
	z/ApvnFFTGNyF9VqJL/uCZRfYFqiOn6inz3MIGIYFwDXpZnKVKectPlUAgW2XKHYAA==
X-Gm-Gg: ASbGncu52oRep54sTStuYivIPfFrlLDxBBgMYtl5JDkoXrN/KMqHzYoq8OkMQe6BQ94
	6skdsNKkMacoDBCcTJuTpzz2W/QHdChRQyV0Cxpo8XDedLWPYisvFgz7f+D+fX2L7IA5Meji1jE
	gr27i7vJ3iU6h8eH6fXkOA/BUlJAtw+40AyB9y41ZVNG8sQ3NG40xRLdKWtiVGWSl2A9QyGukMr
	CANtWzkaKp/veFl6lIxvj4qLnr920U6iHBIxPQziJ5duNjiZFnGj0L/roU5taZgZVcHiAP4brWi
	5sabXpeDEKk1ATc+P9nGJEwG2+9mMQW8cM+2VUGiZNQkzz5zyOj1q7Dpda+QsrL5GySYWUoRjo5
	jQJSg4PyTxlopgXx4YBOTwMqlgNPOUN2LZ7IL
X-Google-Smtp-Source: AGHT+IHasvsxzOMZ7SBhAmuLBoNTQYAbWqktdrp2r7ZdmEHeMxBQxM8Rn62aacGLZaEMdz0a9SE+Zw==
X-Received: by 2002:a05:6402:2351:b0:607:16b1:7489 with SMTP id 4fb4d7f45d1cf-60716b177dcmr4334550a12.20.1749133243785;
        Thu, 05 Jun 2025 07:20:43 -0700 (PDT)
Message-ID: <8768b970-6c62-4fc4-8ef5-b74f1aa650e6@suse.com>
Date: Thu, 5 Jun 2025 16:20:42 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 06/19] xen: Clean up asm-generic/device.h
To: Alejandro Vallejo 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Oleksii Kurochko ,
 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: 
 <20250530120242.39398-1-agarciav@amd.com>
 <20250530120242.39398-7-agarciav@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 05.06.2025 16:15, Alejandro Vallejo wrote:
> On Mon Jun 2, 2025 at 4:24 PM CEST, Jan Beulich wrote:
>> On 02.06.2025 16:19, Alejandro Vallejo wrote:
>>> On Mon Jun 2, 2025 at 9:51 AM CEST, Jan Beulich wrote:
>>>> On 30.05.2025 14:02, Alejandro Vallejo wrote:
>>>>> --- a/xen/include/asm-generic/device.h
>>>>> +++ b/xen/include/asm-generic/device.h
>>>>> @@ -6,9 +6,7 @@
>>>>>  
>>>>>  enum device_type
>>>>>  {
>>>>> -#ifdef CONFIG_HAS_DEVICE_TREE
>>>>>      DEV_DT,
>>>>> -#endif
>>>>
>>>> Why would this enumerator need exposing on a non-DT arch? In fact I would have
>>>> hoped for ...
>>>
>>> A non-DT arch would not include this. x86 doesn't.
>>
>> Both here and ...
>>
>>>>>      DEV_PCI
>>>>
>>>> ... this to be hidden for arch-es not supporting PCI.
>>>>
>>>> Similar concerns elsewhere in this change.
>>>
>>> This file is exclusively used by arches supporting DT to abstract away where
>>> the device came from. x86 does not use it at all, and while it wouldn't be
>>> impossible to compile-out DEV_PCI, it would needlessly pollute the codebase with
>>> no measurable gain, because the abstractions still need to stay.
>>
>> ... here: In "xen/include/asm-generic/device.h" there's nothing at all saying
>> that this file is a DT-only one. Instead there is something in there saying
>> that it's suitable to use in the entirely "generic" case.
>>
>> Jan
> 
> Try to use it from x86 and observe the build system catch fire. It could be made
> to not go on fire, but it implies heavy refactoring in x86 (particularly IOMMU
> code) for no good reason because there's no devices in a DTB to disambiguate.
> 
> How about adding this to the top of the header?
> 
> ```
>  /*
>   * This header helps DTB-based architectures abstract away where a particular
>   * device comes from; be it the DTB itself or enumerated on a PCI bus. 
>   */
> 
>   [snip]
> 
>  #ifndef CONFIG_HAS_DEVICE_TREE
>  #error "Header meant to be used exclusively by DTB-base architectures."
>  #endif
> ```

Might be fine, together with giving the file a name somewhat referring to DT.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 14:22:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 14:22:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006953.1386210 (Exim 4.92)
	(envelope-from )
	id 1uNBUb-0003tk-JL; Thu, 05 Jun 2025 14:22:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006953.1386210; Thu, 05 Jun 2025 14:22:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNBUb-0003td-GB; Thu, 05 Jun 2025 14:22:53 +0000
Received: by outflank-mailman (input) for mailman id 1006953;
 Thu, 05 Jun 2025 14: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 1uNBUa-0003tX-U4
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 14:22:53 +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 8fb3b2d4-4218-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 16:22:50 +0200 (CEST)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-acb39c45b4eso165969866b.1
 for ; Thu, 05 Jun 2025 07:22:50 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ada5e878152sm1273046866b.107.2025.06.05.07.22.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 07:22:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8fb3b2d4-4218-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749133370; x=1749738170; 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=Vh8RoyS43ThBKLQ/gHpTQbTpGCpGou6sj6M4xPMbD98=;
        b=F2bMDftxMwFgMNLWMBKjC+WyJ9ow7Ah22I6xDof/fFTevcmoZmnNvbWNKXZNiEOntN
         7w/l7Dw4z6v1qwdtngcrKzEfCr5ZltWCs1q4bYsgqjDq4rDlaxrneLPWRpP1yyiwZoDP
         Bupz4lsrcOKVrcqArFxoWZ82pDT5TUduBsrT+ij4dP1ONuTXKVHzm/IpaFNbYrdVF1tM
         IrzY9XVjXqISZGsD4OWYodyFBXPmTw422TTZ4yG5nh/B6kydbhoOz0u7CPQ5skyNF9kt
         D1q6veH8eGuT6RFSW8WROaR49EPvxr3VLscNRjjzHPZOIzGMeLS9wwubU/ahdAr5AyI+
         7SIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749133370; x=1749738170;
        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=Vh8RoyS43ThBKLQ/gHpTQbTpGCpGou6sj6M4xPMbD98=;
        b=eG3a8pMuGYBwccOaxqLy4kLMJJkfOv+r/v2yfN3RmPAEm3n4sZ/K7XzFHn8ghUmSN4
         1eeqDGYEerA1hIeOM4qHQz7YGnUp/KGtiDTis8C7Bfac88PaK5Nn7vRqLFM1+ZOZh85i
         wGTbsvnuM5mOYo4YiOmDzJXT31tl2Z5aM4M3M3J4we852anH2BRoYpUwAYvuQ+ew0cic
         Cc1+d/w9Ilogj2IhaTb2/i3IW/1+V2w3xnMHR+NlVSbMOO7BsVk4/tFbfOqOwUDpdi1I
         3+eOEhqOXBXVO8a8uqNXBHAmlx7w3TjWxlttEYvCqjY1JVHZop1ylCf9PRDWAsfolwJX
         vYVg==
X-Forwarded-Encrypted: i=1; AJvYcCWBFC7VA8w/tMS6SnEzbGgSIP31grlqadiGj61L0sbnxE5maGJIDwj2VIsldt/rP7sPMbJJQgPPXJA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz0S/MAIu+ejOQc5TyjmmcLslAsc9HgvFHY7Wc5sCueQweIIiHs
	lkfw50VFHIq+IKYQ4erCyb7duLsYAHzV4QnY2s7GEgaiYAmYXBD57fgf
X-Gm-Gg: ASbGncvtZjMZpxzJb6eWtdCrqvUc3YNn9Ypew+h9B2MVh05eUTzETwni15O0xsSu96x
	19abI6l58bjvTKevSJSEmiQ2+iXn7BtmROSDeK2ykaYaeo3nQC1TYZYjW/7c7KTxazJ72vpUu4P
	ttNWUJK3uXdpuY5hLwyUQ247TawMSLqwpybXyTZMtIQQ6+RugFjorz8Yl6PWZhCQU1l/SsdfnPT
	VfZCO333Ry8DgkBc69tF2vRjXFYJl5H0fcUvzAlArDBpHyyxg0eXbZpLhxY1db5NSUG+ZlzFiHo
	ojy5K40MO6ZpmrBXPjECw19zNTnkg/KuPHskdX835986CEBx4eY2+aTrC1FawHYvdBCbX+FdoPJ
	8iHG7ib0N/1e8d6z1Q15iHN2N
X-Google-Smtp-Source: AGHT+IEZaZe772STO1YoaJy3ybnIxxMxK8wqVE75Kf+2Dj9nd4QYZVxmheF2bkreCx/uVO3qs5F+9Q==
X-Received: by 2002:a17:907:86a7:b0:add:ede0:b9d4 with SMTP id a640c23a62f3a-addf89e8fe6mr631997866b.0.1749133369779;
        Thu, 05 Jun 2025 07:22:49 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------FcvKDYp52KLyHVM0U0MgvD0D"
Message-ID: <59b5d40e-8db8-4380-9cb9-b7fae8bac05d@gmail.com>
Date: Thu, 5 Jun 2025 16:22:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 3/6] xen/riscv: construct the P2M pages pool for guests
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: 
 
 
 <4a6136c3-4146-48e6-85d5-4a6f30bc9920@gmail.com>
 <5ce4c4a6-8e2e-4b4e-9cec-03a78d1d0173@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <5ce4c4a6-8e2e-4b4e-9cec-03a78d1d0173@suse.com>

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


On 6/2/25 1:08 PM, Jan Beulich wrote:
> On 23.05.2025 12:27, Oleksii Kurochko wrote:
>> On 5/20/25 4:38 PM, Jan Beulich wrote:
>>> On 09.05.2025 17:57, Oleksii Kurochko wrote:
>>>> --- a/xen/arch/riscv/p2m.c
>>>> +++ b/xen/arch/riscv/p2m.c
>>>> @@ -1,4 +1,12 @@
>>>>    #include 
>>>> +/*
>>>> + * Because of general_preempt_check() from xen/sched.h which uses
>>>> + * local_events_need_delivery() but latter is declared in .
>>>> + * Thereby it is needed to icnlude  here before xen/sched.h.
>>>> + *
>>>> + * Shouldn't be xen/event.h be included in ?
>>>> + */
>>>> +#include 
>>> The question doesn't belong here; such could be put in the post-commit-
>>> message area. And the answer depends on what dependency you found missing.
>> It is needed for local_events_need_delivery() which is used by general_preempt_check()
>> in p2m_set_allocation(). Otherwise, the following issue will occur:
>>
>> In file included from ././include/xen/config.h:17,
>>                    from :
>> arch/riscv/p2m.c: In function 'p2m_set_allocation':
>> ./include/xen/sched.h:941:36: error: implicit declaration of function 'local_events_need_delivery' [-Werror=implicit-function-declaration]
>>     941 |         (!is_idle_vcpu(current) && local_events_need_delivery())    \
>>         |                                    ^~~~~~~~~~~~~~~~~~~~~~~~~~
>> ./include/xen/compiler.h:26:43: note: in definition of macro 'unlikely'
>>      26 | #define unlikely(x)   __builtin_expect(!!(x),0)
>>         |                                           ^
>> arch/riscv/p2m.c:244:27: note: in expansion of macro 'general_preempt_check'
>>     244 |         if ( preempted && general_preempt_check() )
>>         |                           ^~~~~~~~~~~~~~~~~~~~~
>> cc1: all warnings being treated as errors
> In which case my answer to your question is "No". Others may take a different
> perspective. (xen/sched.h being included virtually everywhere, imo we want to
> avoid adding dependencies there which aren't strictly necessary to keep things
> building.)

Okay, then I will just update the comment and leave inclusion of xen/event.h in riscv/p2mc.

>
>>>> @@ -166,3 +176,60 @@ int p2m_init(struct domain *d)
>>>>    
>>>>        return 0;
>>>>    }
>>>> +
>>>> +/*
>>>> + * Set the pool of pages to the required number of pages.
>>>> + * Returns 0 for success, non-zero for failure.
>>>> + * Call with d->arch.paging.lock held.
>>>> + */
>>>> +int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
>>>> +{
>>>> +    struct page_info *pg;
>>>> +
>>>> +    ASSERT(spin_is_locked(&d->arch.paging.lock));
>>>> +
>>>> +    for ( ; ; )
>>>> +    {
>>>> +        if ( d->arch.paging.p2m_total_pages < pages )
>>>> +        {
>>>> +            /* Need to allocate more memory from domheap */
>>>> +            pg = alloc_domheap_page(d, MEMF_no_owner);
>>>> +            if ( pg == NULL )
>>>> +            {
>>>> +                printk(XENLOG_ERR "Failed to allocate P2M pages.\n");
>>>> +                return -ENOMEM;
>>>> +            }
>>>> +            ACCESS_ONCE(d->arch.paging.p2m_total_pages) =
>>>> +                d->arch.paging.p2m_total_pages + 1;
>>> Looks like you copied this from Arm, but this code is bogus: Using
>>> ACCESS_ONCE() just on the lhs is pretty pointless. Once also used on the
>>> rhs the expression can easily become
>>>
>>>                   ACCESS_ONCE(d->arch.paging.p2m_total_pages) += 1;
>>>
>>> or even
>>>
>>>                   ACCESS_ONCE(d->arch.paging.p2m_total_pages)++;
>>>
>>> .
>>>
>>>> +            page_list_add_tail(pg, &d->arch.paging.p2m_freelist);
>>>> +        }
>>>> +        else if ( d->arch.paging.p2m_total_pages > pages )
>>>> +        {
>>>> +            /* Need to return memory to domheap */
>>>> +            pg = page_list_remove_head(&d->arch.paging.p2m_freelist);
>>>> +            if( pg )
>>>> +            {
>>>> +                ACCESS_ONCE(d->arch.paging.p2m_total_pages) =
>>>> +                    d->arch.paging.p2m_total_pages - 1;
>>> Same here then, obviously.
>>>
>>>> +                free_domheap_page(pg);
>>>> +            }
>>>> +            else
>>>> +            {
>>>> +                printk(XENLOG_ERR
>>>> +                       "Failed to free P2M pages, P2M freelist is empty.\n");
>>>> +                return -ENOMEM;
>>>> +            }
>>>> +        }
>>>> +        else
>>>> +            break;
>>>> +
>>>> +        /* Check to see if we need to yield and try again */
>>>> +        if ( preempted && general_preempt_check() )
>>> While it's this way on both Arm and x86, I wonder how useful it is
>>> to check on every iteration, especially when freeing pages back to the
>>> buddy allocator.
>> IIUC, but a preemption request could happen for both cases. And destroying of
>> a domain could also consume long time and so not to block hypervisor if something
>> more urgent should be handled it could be also have this check for the case of
>> freeng pages back to the buddy allocator.
> The question wasn't whether to check, but how frequently. The check itself is
> consuming processing time, too, so one generally wants to balance the number
> of checks against the size of the resulting time window without any check.

So you are expecting something like this:
         /* Check to see if we need to yield and try again */
         if ( !(d->arch.paging.p2m_total_pages % 30) && preempted &&
              general_preempt_check() )
         {
             *preempted = true;
             return -ERESTART;
         }
It still requires, at least, one check, but this check isn't so long as
general_preempt_check() could be.

~ Oleksii

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



  
    
  
  
    

    
    
    
    
    On 6/2/25 1:08 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 23.05.2025 12:27, Oleksii Kurochko wrote:

    
      
    
        
    On 5/20/25 4:38 PM, Jan Beulich wrote:

    
        
    
          
    On 09.05.2025 17:57, Oleksii Kurochko wrote:

    
          
    
            
    --- a/xen/arch/riscv/p2m.c
+++ b/xen/arch/riscv/p2m.c
@@ -1,4 +1,12 @@
  #include <xen/domain_page.h>
+/*
+ * Because of general_preempt_check() from xen/sched.h which uses
+ * local_events_need_delivery() but latter is declared in <asm/event.h>.
+ * Thereby it is needed to icnlude <xen/event.h> here before xen/sched.h.
+ *
+ * Shouldn't be xen/event.h be included in <xen/sched.h>?
+ */
+#include <xen/event.h>

    
          
    
          
    The question doesn't belong here; such could be put in the post-commit-
message area. And the answer depends on what dependency you found missing.

    
        
    
        
    It is needed for local_events_need_delivery() which is used by general_preempt_check()
in p2m_set_allocation(). Otherwise, the following issue will occur:

In file included from ././include/xen/config.h:17,
                  from <command-line>:
arch/riscv/p2m.c: In function 'p2m_set_allocation':
./include/xen/sched.h:941:36: error: implicit declaration of function 'local_events_need_delivery' [-Werror=implicit-function-declaration]
   941 |         (!is_idle_vcpu(current) && local_events_need_delivery())    \
       |                                    ^~~~~~~~~~~~~~~~~~~~~~~~~~
./include/xen/compiler.h:26:43: note: in definition of macro 'unlikely'
    26 | #define unlikely(x)   __builtin_expect(!!(x),0)
       |                                           ^
arch/riscv/p2m.c:244:27: note: in expansion of macro 'general_preempt_check'
   244 |         if ( preempted && general_preempt_check() )
       |                           ^~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors

    
      
    
      
    In which case my answer to your question is "No". Others may take a different
perspective. (xen/sched.h being included virtually everywhere, imo we want to
avoid adding dependencies there which aren't strictly necessary to keep things
building.)
    
    
    
    
    Okay, then I will just update the comment and leave inclusion of xen/event.h in riscv/p2mc.


    
    
    
      
    

    
      
    
        
    
          
    
            
    @@ -166,3 +176,60 @@ int p2m_init(struct domain *d)
  
      return 0;
  }
+
+/*
+ * Set the pool of pages to the required number of pages.
+ * Returns 0 for success, non-zero for failure.
+ * Call with d->arch.paging.lock held.
+ */
+int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
+{
+    struct page_info *pg;
+
+    ASSERT(spin_is_locked(&d->arch.paging.lock));
+
+    for ( ; ; )
+    {
+        if ( d->arch.paging.p2m_total_pages < pages )
+        {
+            /* Need to allocate more memory from domheap */
+            pg = alloc_domheap_page(d, MEMF_no_owner);
+            if ( pg == NULL )
+            {
+                printk(XENLOG_ERR "Failed to allocate P2M pages.\n");
+                return -ENOMEM;
+            }
+            ACCESS_ONCE(d->arch.paging.p2m_total_pages) =
+                d->arch.paging.p2m_total_pages + 1;

    
          
    
          
    Looks like you copied this from Arm, but this code is bogus: Using
ACCESS_ONCE() just on the lhs is pretty pointless. Once also used on the
rhs the expression can easily become

                 ACCESS_ONCE(d->arch.paging.p2m_total_pages) += 1;

or even

                 ACCESS_ONCE(d->arch.paging.p2m_total_pages)++;

.


    
          
    
            
    +            page_list_add_tail(pg, &d->arch.paging.p2m_freelist);
+        }
+        else if ( d->arch.paging.p2m_total_pages > pages )
+        {
+            /* Need to return memory to domheap */
+            pg = page_list_remove_head(&d->arch.paging.p2m_freelist);
+            if( pg )
+            {
+                ACCESS_ONCE(d->arch.paging.p2m_total_pages) =
+                    d->arch.paging.p2m_total_pages - 1;

    
          
    
          
    Same here then, obviously.


    
          
    
            
    +                free_domheap_page(pg);
+            }
+            else
+            {
+                printk(XENLOG_ERR
+                       "Failed to free P2M pages, P2M freelist is empty.\n");
+                return -ENOMEM;
+            }
+        }
+        else
+            break;
+
+        /* Check to see if we need to yield and try again */
+        if ( preempted && general_preempt_check() )

    
          
    
          
    While it's this way on both Arm and x86, I wonder how useful it is
to check on every iteration, especially when freeing pages back to the
buddy allocator.

    
        
    
        
    IIUC, but a preemption request could happen for both cases. And destroying of
a domain could also consume long time and so not to block hypervisor if something
more urgent should be handled it could be also have this check for the case of
freeng pages back to the buddy allocator.

    
      
    
      
    The question wasn't whether to check, but how frequently. The check itself is
consuming processing time, too, so one generally wants to balance the number
of checks against the size of the resulting time window without any check.
    
    
    
    
    So you are expecting something like this:
        /* Check to see if we need to yield and try again */
        if ( !(d->arch.paging.p2m_total_pages % 30) && preempted &&
             general_preempt_check() )
        {
            *preempted = true;
            return -ERESTART;
        }
It still requires, at least, one check, but this check isn't so long as 
general_preempt_check() could be.
    
    
    ~ Oleksii

    
  


--------------FcvKDYp52KLyHVM0U0MgvD0D--


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 14:27:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 14:27:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006960.1386220 (Exim 4.92)
	(envelope-from )
	id 1uNBZR-0004VK-5T; Thu, 05 Jun 2025 14:27:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006960.1386220; Thu, 05 Jun 2025 14:27: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 1uNBZR-0004VD-1U; Thu, 05 Jun 2025 14:27:53 +0000
Received: by outflank-mailman (input) for mailman id 1006960;
 Thu, 05 Jun 2025 14:27: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 1uNBZP-0004V7-C0
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 14:27:51 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on2062c.outbound.protection.outlook.com
 [2a01:111:f403:2414::62c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4087ad56-4219-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 16:27:48 +0200 (CEST)
Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
 by IA0PR12MB7577.namprd12.prod.outlook.com (2603:10b6:208:43e::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.37; Thu, 5 Jun
 2025 14:27:44 +0000
Received: from PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264]) by PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264%2]) with mapi id 15.20.8792.035; Thu, 5 Jun 2025
 14:27: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: 4087ad56-4219-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=cm7+fef0sNWc/TWNS5XfXRNQ/eLZ5I/qCYAWvX9aNGELRF3TZTI615IF6aFhMzG7p66laEnHNUwNyYJivI/RVBt4pJbRTaPYzE5eTSnd7UXwq37aRGzdy6Qp6JyBPknoJiicn09B1UUlNdT/f7/PT8PPzyFx33omO8VMA8f1pkVIGJyBmTFPS8ADfR3rDonjunwebbEfsiFhNsGp0hLpWGDy9spkHuhDimGfcEl5ZSkt5jq0JHEp23k+6ZHjt82rGTgxP2okZ+YLfjQ8pdNfywgphjccrayYoXE4xjabSG5IUHYQ0brSy/eUxj5HY+vyNFlPBwJrxF1F/4Pacf1IVg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=DHooqomRs93lb8qYsexZdpkQ3AHpuxhKmbs61F9u2CM=;
 b=vOJmodazRg545qyeI0ED3WlwmecgFoZe5d/df5CBEu9vTAAOGgebdAmejFtv3ck7sU/zI+/guF/nBDsff1LapjNf58i7i1XS2IyudPAtz+9au8P9n+x9mPy6ajrIWrkXusbOiuZnn7mL21rdr6nYOtu6rZUo6ZqR/zbN3lHpK+B7XRx6fj4O6EEBkb/B6ei4Jlahur2wBEwVgwgZdKMZpxklK+ZhBTDfaPTNSdld2sDKXW9KdV8ImV6sDYTgKfHibfTG7rZZjywZ89hBWDVT1YLVcB4BYs5vnZ7c++iNSBWUCrAQoSi/ml0ioAYlnFOqaP7AU78wFGSgelSDDTLzjQ==
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=DHooqomRs93lb8qYsexZdpkQ3AHpuxhKmbs61F9u2CM=;
 b=dMm4qPUXMvYW7EHJlnRH+jxNzVc5539PcCfesEKe8KJIYLOcVP7Ev80DaiLoo448vvMwzdB02eJ3wcJW4rU8/biPvSua9Ds3GmCnE5dOcFsIfLO/uZ72Pp5GgIHDvkPqYVawlLvpu347LUauAS2ze/xdQF1W2GdaX4cZhRLmRzc=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Thu, 5 Jun 2025 15:27:39 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/3] arm/mpu: Provide and populate MPU C data
 structures
Content-Language: en-GB
To: "Orzel, Michal" ,
 Ayan Kumar Halder , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250604174311.754899-1-ayan.kumar.halder@amd.com>
 <20250604174311.754899-3-ayan.kumar.halder@amd.com>
 <50c8e74e-95f6-4cea-b979-8b81d7575a21@amd.com>
From: Ayan Kumar Halder 
In-Reply-To: <50c8e74e-95f6-4cea-b979-8b81d7575a21@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: AM6P193CA0082.EURP193.PROD.OUTLOOK.COM
 (2603:10a6:209:88::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_|IA0PR12MB7577:EE_
X-MS-Office365-Filtering-Correlation-Id: 99a1595d-a577-471e-6fe1-08dda43d228d
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?dExLb3orWEtneit5T0pET2ZzUzFsbkxWQ1hGYklkdGc3WlZtYjM5eHpPVVdB?=
 =?utf-8?B?MXhuSzNqZWk4M0JycENCT2ZDVkEyalE2bXJaSU1heGJnWHRyQXZIUWtDYkZH?=
 =?utf-8?B?TFdEcUdjRENkNkxIRmN6UHRxVXpFWXR1NG93Wmt2TFFyUFo0NzRXakVOd2tz?=
 =?utf-8?B?N1JIOVYrckRWSUFDeE1zaUpJTjI0SXc0alkrQUxodW9BNTI2ZjJIOCt4K2dT?=
 =?utf-8?B?RnVOSVZKWUd3MFZNQVVxRVR2ZENHMUNsU3VxMk11VVhFOXhSaFFIWkNsbVR0?=
 =?utf-8?B?QW80VHFJRFgvSEMyamxwdE1SdzFSRFRtSm5oSlM0aDZJSlF1SG9zU0YvYUNG?=
 =?utf-8?B?STcwQVNyM2dzSE5QK0VqYUswcmJ0TGZPNCtWL0MzaUlrMGp2ZzhpdnpNd2pN?=
 =?utf-8?B?S1V2eWxxeE9WNWN3MmxFVkRXclYybmVTUXhYbHM1a01mWGUwQjdyTG1RK1JL?=
 =?utf-8?B?djF5eDlpOURjMytMM2ZnS1BGdjg3UXpzZVd0cVJkaWxVYmhkYTR4aGRIRzJT?=
 =?utf-8?B?OXBBSHMrSDRpNmUyTUNXQnhQUEhtSCtkNFFaL21LNVFMNG1uaWI4RU9yR3Zx?=
 =?utf-8?B?RE1WazJmYnQzYjNKZmoxVXhUWXNzbnMxanVFeWZrbnZ2cUNGeXZsM1hQVktv?=
 =?utf-8?B?ZzVXVFM4S2NJY1pwNWFtRjA2RnNOcGF3bndIY3JMWXBYYitDa0ZSWkFuZlNj?=
 =?utf-8?B?U0FwM0Z3ejZMRDVJWFdtNlp6M1V4VXlzMW51MXRuWlM2S1hlVEJodmd5VFQ1?=
 =?utf-8?B?bjhuZ2tRQlJyOG91SnVYVDhNQitHR3dKdGJXVmlSYW52Q3JHYkxlMW50aVlL?=
 =?utf-8?B?Zy8wM0JNOHpXbnFsZm1PQjNzOXFQekVGMjVma0ZoVlN6UlRDTi84YVFPaUR5?=
 =?utf-8?B?OUEwd3lpSmdMU2pseGNkVHNSTngyYmNMOWV0VUtBR00vSFdWTElqa050TmFS?=
 =?utf-8?B?R2l4a29kNlhNMFZqMkpqWmp2cHdkRGJiK0xkUDhUQUlVV3MybndrN3VlNko0?=
 =?utf-8?B?Sk56cUlrUUdwL3VEUkJGWVU0dDBQMThJQlIzNUthRnJLNFZuRVVjdFBwZEJC?=
 =?utf-8?B?citrSldLK3BNRms3Q0lDNXdaTml1M1FWeEVGY0ZJWXQ5MzJmUCs1c2Fybllo?=
 =?utf-8?B?emp4a2ZsK3dJUFc4amJvdnlCdVk1UmMveHYwYU9JOEMzMjUzcFAxbEd5d1VI?=
 =?utf-8?B?RlU0OTRRYmJjbzJtbi9QV2Q2UThWSmxrK2I5RW5rMDJtVXVyWU9PMmxpOEdM?=
 =?utf-8?B?Mzg4MXIzNXJRMExqdldmR2JWTTlsVnR5MFJXdWNnWGNmTmZBSDE3c3BCZGdC?=
 =?utf-8?B?VThlbFNIQzZIZlBXelpQbUZwL25tSE5OZ2MwSU0xNVdjL1RlYnlBc2tDdjVP?=
 =?utf-8?B?N0VoTTExWnJXWXlaM2szME5sMWZkQ1RBTldVd25Ia2ZDOUNuVnR2T3VKVjdj?=
 =?utf-8?B?d1BzL3F2YUY0MDladm9MdkxsUFlENko0OGk5SkNuZUc5MjNMeUFTZTBSWlRv?=
 =?utf-8?B?a2JOTVNZa2wwRzM3b1l1dzlrc3dXQ2dwVkxwcWx0Q3V6aUhDa1Z5elg0TDZy?=
 =?utf-8?B?citSbU5sVWI0OFRPUEpvRG12QnV3VTRXT1g0UVE4L3Yzd1RYZDAyYmtsRkNO?=
 =?utf-8?B?aWJ5T3l4bDVvSk4wN2liR1dtRzU5NXZKRW45NGs1WEN3a3JPa01GbTd1Umdv?=
 =?utf-8?B?Z0pvTllzM05HTFFVZlBCT1A5Q3lBQUFDS3oyU0pRNFNmYjRKV2dnSG9BSDJw?=
 =?utf-8?B?WnRMclJBYStyYzNod3lMUDJGdzBtWHNpMDJJN3J3ZDArckFoODkxT0ZIL3Bi?=
 =?utf-8?B?WENaUFJFczBTQzZoNzV4QkxvVWNlRWVtOHA1S1ZWVlBSQnBhY2NUZVcxOGRj?=
 =?utf-8?B?YThCc1VYSldFVzBBMHdBT1RSTGt1ekhPdGJVZnJ6MmgxTjRZTjNNUlB1SEVq?=
 =?utf-8?Q?1N72yB7xJXg=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?U3BZdGFZZkZyZVVJeGpPOXRVNHNIdXVINEMxRVI3REJyUlUxRmVtY2dYdTd5?=
 =?utf-8?B?U21WakpJL1RHWFNwUTVBN3E1Uk1ITDhWYkFZN3l5RWttQ29JVUFTRDVLQXJn?=
 =?utf-8?B?ckVTWHNvbG1rM3dQZ0NuV1FXalU4OXBWMjJxZDlFbDBKMTh4K3hhMUExYTlL?=
 =?utf-8?B?aGtUVW45Mis3RXJqalc4Yk4xYVR2L3p2MXlpOU91NXFJaGlHUWY0bmJNemJz?=
 =?utf-8?B?aXNyVkYwdE9xTmZaak8zZ3RrQ1FqeFEwN2FyZGlJTzRQQUlRQ2YyZlZrdW11?=
 =?utf-8?B?R2h4K2tGZ05LWUxUQVpyTDJYNGhrendFblBQYThYYi9PUmRZOTNMSFErL3pJ?=
 =?utf-8?B?bFlQR1ZFSXdvRVdIZmpYK0hyb01EQkJ3M1RQUmpDaURtekRlRFovU1FYZ2lB?=
 =?utf-8?B?OGpuVlF6cGhBUTlYSFFhVytGRnFrMjBrRy9mdVFaOVV4ZWwwenN0OHlwOGQy?=
 =?utf-8?B?UDFWN1UxZHBYZDlNZFFuS3BodFNtYncrcjU4aU9YVEw3QkNKb2xDVmpzUWxL?=
 =?utf-8?B?VWExbFF5RUxMZ2d5OUptNVpQYW9wemxUbk10ODgyRTVsKzBmVTlvSFhjQ2c5?=
 =?utf-8?B?YTRpVkg0WEJOd1RiM2c1Znl3NG1QYjQ1aENlMmRzQW9laHhWOXNxODBBTWV6?=
 =?utf-8?B?em9GYk9HVUlLc0x5bnJtRXFadDJhcjVPYTkzM1ZDcXBJcElDYjhJUVUrYjdD?=
 =?utf-8?B?YU5wRS8yaVBNRlNIWnY4aU1zTzZsWTIra250SHBPblNOMTZGUmxYTmFQbTZI?=
 =?utf-8?B?WXE5UjJKTFllMlUyK00zOHBPaVFzcW16ZS9NVVRWMkdwODJzWm05WmUzTXpk?=
 =?utf-8?B?ekwzQ2pWUDJHcGI4L1U0WEp4ZTlRVkxOVWdTSzRhdGtFcmFqVnZWd2RqNXdX?=
 =?utf-8?B?Uk53VFRud3d1M2Q1VFdGRnhUeXdJU0xVbVFuNkIvKzdhTEY5QmlsL2x2byt5?=
 =?utf-8?B?blBWTEt0dVBiY3hpYU9obEhOWmhWV0plcGRSdHozZjF6cUx2Y3FXeUtZaFg4?=
 =?utf-8?B?YnlzSVgwcTl6a281VVdXNTc1MDIyN01kVm9nVjZYeGI3NmRLUkEraHRNZWN0?=
 =?utf-8?B?bktwZHJDMStLeU8zWTFhd2dWbENLdzM4MDk1bElPZXZpRnRJRUJQNXBtNGl0?=
 =?utf-8?B?eXcxSmluTUQwTDBsWmR1NGFmZ204SmNicGZHdVJGYWt2OUVJb0hlVGFqbytr?=
 =?utf-8?B?UGU5a0cvV2FiVXlLYWFUWW9wRHgvblU5Ukl0aXdkSHJpK0JtS1dWUlV3STFJ?=
 =?utf-8?B?WjVqdHJpbzAzTWN3SFJKWEF2cXcrcEEzOE5IcFp3QkFSSXJiOG5NaEsxZmJP?=
 =?utf-8?B?cXE3WjZVQmQ5V2VEek9VOUdMK1YxT2hNZ3hNVkNmVnFVVzM0Y25KWlBTajdE?=
 =?utf-8?B?RzY4V1g3TjNaelRlUldEditrZ0dKL2ZlN2F3VmFtdWQ2dDA2YVV5aksrTlhP?=
 =?utf-8?B?Ni9Qa25odmVGbVVGVlJMSVRqaGtqVyttSVFTM0tLYk4yU2h1RDI0VkhXT2dh?=
 =?utf-8?B?QnJNdFJLdERUaXdodzRLaDZBMGhmT2xvalpZWU1nUk1OaE1HM2ZFQUY0VGpT?=
 =?utf-8?B?ZWt0VTJrNmw4ZDROYlhvTVdleHVTM1FIODNWUWFHWDFCbkJ1ZS9Lc3VFcTBy?=
 =?utf-8?B?blBHK0dtRDJ5S3VKZGplQ0ZObUZCQkhZWkoxRmxSOGRkQzJWcVg4d3BZZTNp?=
 =?utf-8?B?ck1NUEdLYUF0WkxiRUp6ZDNkNTR6d1R1U0NGU0FCWnAxK0hvSTl3aTRsYks4?=
 =?utf-8?B?TkM2T1BqUDhIY0c5bUR4VzZNME5memYzRzlhSC9WVW5XYVFCVWl0S2puZ1lw?=
 =?utf-8?B?RG5lS2pmbzNsZFpMWjNHQ3JpVEVGeVd5OVc5NFVyb3F5MFRSZVV5aVA4S0lM?=
 =?utf-8?B?NXVzUjBValMyM29wa214RTdJWTNQNVpvb2d1MFpxdFRHa0ZGVXZhU1VLOXpG?=
 =?utf-8?B?d29zWHJMU0dvejRPRkRCYXFTR2djLzFLMko4TTZjNm15amFac2I3MzVjNFNz?=
 =?utf-8?B?QTBNNWtpSFVFTm5Fa254MWtaVlQwaXVjRitTZFM0dXV5d1hVcnEyNnN1Ujcy?=
 =?utf-8?B?SFVRcWpzQVJxRDQvRlRiTWZIb29haExBSVJwKy9wRXU3cVNLcHEwTlNaM0tF?=
 =?utf-8?Q?TT0wOzs0eNZmsMhDhddzurv9/?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 99a1595d-a577-471e-6fe1-08dda43d228d
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jun 2025 14:27:43.9212
 (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: +1BlExiwtuah+HOJNSp9P4dBdMaOJN/cuutHyJ767X+W4BLz33a3Rb+OE2JSgCVQ03vKVl/Ub/M8jRQmEQ5POw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB7577

Hi Michal/Julien,

On 05/06/2025 08:44, Orzel, Michal wrote:
>
> On 04/06/2025 19:43, Ayan Kumar Halder wrote:
>> Do the arm32 equivalent initialization for commit id ca5df936c4.
> This is not a good commit msg.
> Also, we somewhat require passing 12 char long IDs.

Modify Arm32 assembly boot code to reset any unused MPU region, 
initialise 'max_mpu_regions' with the number of supported MPU regions 
and set/clear the bitmap 'xen_mpumap_mask' used to track the enabled 
regions.

Use the macro definition for "dcache_line_size" from linux.

Does ^^^ read fine ?

>
>> Signed-off-by: Ayan Kumar Halder 
>> ---
>>   xen/arch/arm/arm32/asm-offsets.c         |  6 +++
>>   xen/arch/arm/arm32/mpu/head.S            | 57 ++++++++++++++++++++++++
>>   xen/arch/arm/include/asm/mpu/regions.inc |  8 +++-
>>   3 files changed, 70 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/arm/arm32/asm-offsets.c b/xen/arch/arm/arm32/asm-offsets.c
>> index 8bbb0f938e..c203ce269d 100644
>> --- a/xen/arch/arm/arm32/asm-offsets.c
>> +++ b/xen/arch/arm/arm32/asm-offsets.c
>> @@ -75,6 +75,12 @@ void __dummy__(void)
>>   
>>      OFFSET(INITINFO_stack, struct init_info, stack);
>>      BLANK();
>> +
>> +#ifdef CONFIG_MPU
>> +   DEFINE(XEN_MPUMAP_MASK_sizeof, sizeof(xen_mpumap_mask));
>> +   DEFINE(XEN_MPUMAP_sizeof, sizeof(xen_mpumap));
>> +   BLANK();
>> +#endif
>>   }
>>   
>>   /*
>> diff --git a/xen/arch/arm/arm32/mpu/head.S b/xen/arch/arm/arm32/mpu/head.S
>> index b2c5245e51..1f9eec6e68 100644
>> --- a/xen/arch/arm/arm32/mpu/head.S
>> +++ b/xen/arch/arm/arm32/mpu/head.S
>> @@ -10,6 +10,38 @@
>>   #include 
>>   #include 
>>   
>> +/*
>> + * dcache_line_size - get the minimum D-cache line size from the CTR register.
>> + */
> I do think we should have a cache.S file to store cache related ops just like
> for Arm64.
ok, I will introduce a new file.
> Also, no need for multiline comment.
ack.
>
>> +    .macro  dcache_line_size, reg, tmp1, tmp2
> I would prefer to use the macro from Linux that uses one temporary register
/*
  * dcache_line_size - get the minimum D-cache line size from the CTR 
register
  * on ARMv7.
  */
     .macro  dcache_line_size, reg, tmp
     mrc p15, 0, \tmp, c0, c0, 1     /* read ctr */
     lsr \tmp, \tmp, #16
     and \tmp, \tmp, #0xf             /* cache line size encoding */
     mov \reg, #4                          /* bytes per word */
     mov \reg, \reg, lsl \tmp         /* actual cache line size */
     .endm

>
>> +    mrc CP32(\reg, CTR)           // read CTR
> NIT: wrong comment style + wrong alignment
yes, I should use /* ... */
>
>> +    ubfx   \tmp1, \reg, #16, #4   // Extract DminLine (bits 19:16) into tmp1
>> +    mov    \tmp2, #1
>> +    lsl    \tmp2, \tmp2, \tmp1    // tmp2 = 2^DminLine
>> +    lsl    \tmp2, \tmp2, #2       // tmp2 = 4 * 2^DminLine = cache line size in bytes
>> +    .endm
>> +
>> +/*
>> + * __invalidate_dcache_area(addr, size)
>> + *
>> + * Ensure that the data held in the cache for the buffer is invalidated.
>> + *
>> + * - addr - start address of the buffer
>> + * - size - size of the buffer
>> + */
>> +FUNC(__invalidate_dcache_area)
>> +    dcache_line_size r2, r3, r4
>> +    add   r1, r0, r1
>> +    sub   r4, r2, #1
>> +    bic   r0, r0, r4
>> +1:  mcr   CP32(r0, DCIMVAC)     /* invalidate D line / unified line */
>> +    add   r0, r0, r2
>> +    cmp   r0, r1
>> +    blo   1b
>> +    dsb   sy
>> +    ret
>> +END(__invalidate_dcache_area)
>> +
>>   /*
>>    * Set up the memory attribute type tables and enable EL2 MPU and data cache.
>>    * If the Background region is enabled, then the MPU uses the default memory
>> @@ -49,6 +81,10 @@ FUNC(enable_boot_cpu_mm)
>>       mrc   CP32(r5, MPUIR_EL2)
>>       and   r5, r5, #NUM_MPU_REGIONS_MASK
>>   
>> +    ldr   r0, =max_mpu_regions
> Why ldr and not mov_w?
mov_w   r0, max_mpu_regions
>
>> +    str   r5, [r0]
>> +    mcr   CP32(r0, DCIMVAC) /* Invalidate cache for max_mpu_regions addr */
>> +
>>       /* x0: region sel */
>>       mov   r0, #0
>>       /* Xen text section. */
>> @@ -83,6 +119,27 @@ FUNC(enable_boot_cpu_mm)
>>       prepare_xen_region r0, r1, r2, r3, r4, r5, attr_prbar=REGION_DEVICE_PRBAR, attr_prlar=REGION_DEVICE_PRLAR
>>   #endif
>>   
>> +zero_mpu:
>> +    /* Reset remaining MPU regions */
>> +    cmp   r0, r5
>> +    beq   out_zero_mpu
>> +    mov   r1, #0
>> +    mov   r2, #1
>> +    prepare_xen_region r0, r1, r2, r3, r4, r5, attr_prlar=REGION_DISABLED_PRLAR
>> +    b     zero_mpu
>> +
>> +out_zero_mpu:
>> +    /* Invalidate data cache for MPU data structures */
>> +    mov r5, lr
>> +    ldr r0, =xen_mpumap_mask
> Why not mov_w?
mov_w r0, xen_mpumap_mask
>
>> +    mov r1, #XEN_MPUMAP_MASK_sizeof
>> +    bl __invalidate_dcache_area
>> +
>> +    ldr r0, =xen_mpumap
>> +    mov r1, #XEN_MPUMAP_sizeof
>> +    bl __invalidate_dcache_area
>> +    mov lr, r5
>> +
>>       b    enable_mpu
>>   END(enable_boot_cpu_mm)
>>   
>> diff --git a/xen/arch/arm/include/asm/mpu/regions.inc b/xen/arch/arm/include/asm/mpu/regions.inc
>> index 6b8c233e6c..943bcda346 100644
>> --- a/xen/arch/arm/include/asm/mpu/regions.inc
>> +++ b/xen/arch/arm/include/asm/mpu/regions.inc
>> @@ -24,7 +24,13 @@
>>   #define XEN_MPUMAP_ENTRY_SHIFT  0x3     /* 8 byte structure */
>>   
>>   .macro store_pair reg1, reg2, dst
>> -    .word 0xe7f000f0                    /* unimplemented */
>> +    str \reg1, [\dst]
>> +    add \dst, \dst, #4
>> +    str \reg2, [\dst]
> AFAIR there is STM instruction to do the same
strd \reg1, \reg2, [\dst]
>
>> +.endm
>> +
>> +.macro invalidate_dcache_one reg
>> +    mcr CP32(\reg, DCIMVAC)
> Why? You don't seem to use this macro

oh, this can be removed.

- Ayan

>
>>   .endm
>>   
>>   #endif
> ~Michal
>


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 14:43:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 14:43:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006978.1386233 (Exim 4.92)
	(envelope-from )
	id 1uNBoA-0007zi-Gy; Thu, 05 Jun 2025 14:43:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006978.1386233; Thu, 05 Jun 2025 14:43:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNBoA-0007zb-Dr; Thu, 05 Jun 2025 14:43:06 +0000
Received: by outflank-mailman (input) for mailman id 1006978;
 Thu, 05 Jun 2025 14: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 1uNBo9-0007zV-4F
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 14:43:05 +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 62e9bdf7-421b-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 16:43:04 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a5096158dcso904768f8f.1
 for ; Thu, 05 Jun 2025 07:43:04 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-747afe96776sm12928282b3a.24.2025.06.05.07.42.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 07:43:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 62e9bdf7-421b-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749134583; x=1749739383; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ibQZ3gmRDP/C5LX0XwMwRHmURZDY2RPqf/5UEeuDWF4=;
        b=g1nloAfumUkxkzUg+AlVuQjyWzrMkaxCqebkmQZGiaAD2xPqc2MroG+MVVaEv6VMn+
         1HF+kcQauWZgYDKIeKXo8cCiQqBMnSEcpTB9D4UK1jnF+4Q7PIR557LGsals27Uear04
         7/oCeztcK3bDFWqbN1sy1ErsiM90WRmB6Jj4BE6SWpZ3ZdP9mY0EYp2E0m+mpHhdkunA
         76pJZJkNdAHtX7mN8opISCe2+wnlkAxP05MMa8K6mOjKAI6kvK5UH+VAjj4SrUsVIpNb
         XtTqvNo9TyMofVdqGCkqdndq6Djc13Ms7bh3zkiZkE8pArg9eVM48NqmJDP679VHT7SQ
         n48g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749134583; x=1749739383;
        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=ibQZ3gmRDP/C5LX0XwMwRHmURZDY2RPqf/5UEeuDWF4=;
        b=ctIllGxFB8W18v4T+IQhzDZ7Dh/aY8UQJHvSA55LavY3sRUXyd1uOw9ChSFpYR8+Uh
         wq6RsJN6HIbmNfj9IWubjvMoygePxb/RDW5cF1EtiiuG7jzXI4JkMm4BLkMR/fpYcska
         ZDkEWxmLw+sY/bVSLJgEMfoM58ox83G8U7aLQovq4FfIcj8dPyf9b32CSWDxn/avvyU2
         IgiZBqNAN2uaPeyBpLNt2xMCN4E71ICd91yY2+9Sg5/jvQp7opzDtgC5wPXIDufSb0X9
         uviGPoavUqEIp3f73AQNNUnVXcCnuRn/mVdYBheSYGS5IXnXHHzxDZ2H9ATr3eqQ2u2L
         OO0w==
X-Gm-Message-State: AOJu0YyxCKhZs5Z+Sy3QHOR9gC9FZj/EPvg+YV0q34tDN8hDgSn57lxp
	/Fc0IjBjU4b+ks8BD0qiu0wqsdjcOZE8MF7zF/sLiYs3v1tVGrmFL1VrDHo2lqe/xg==
X-Gm-Gg: ASbGncsRohQz4w9BmuoSx8D+hiKsuAx0/FZT5FzHteBojG9yX9UjRnRprgcMe6Mrr2R
	ZHYFNgYCCEIA7pVbMpa1fCeK4Q0x6O9ACX4bv8G18+Uz2VXZSzEGUd+RmF+OyjBkKS6kFqdtWWP
	PG+FCOUEOBbRWa4eOAzJvTOBn3o/zMPhjIPEeaPON9//Lhs+3J423VqvLSnAc6m4UhG/7Bysl1s
	ZFn7dMERLBSODc41fBkQjwVo6iK4Wi60EZ6JHsPBcHBpUIUhkt/8Z+21FcvO7l43P2OUQz3lebd
	ZpmOiHuI2uH1zKyWTE6yfNXyXZLpbhgWRbb/arQjApUa6lT4F21R4FaCGhbIbI7NL4h4EaCQkgN
	inBjCWMBCLzHLDXIXs0TceGfD4eVOD0fCikuq
X-Google-Smtp-Source: AGHT+IGFy0saGtFzDkmF5bygd+mwqObeMCE3jXb4prcd07GReP708S1nJyCWwNZN4S07Uruyzu8A2w==
X-Received: by 2002:a05:6000:40c7:b0:3a4:e6e7:3acd with SMTP id ffacd0b85a97d-3a51d934705mr6058527f8f.18.1749134583435;
        Thu, 05 Jun 2025 07:43:03 -0700 (PDT)
Message-ID: <66cfdee6-5dc2-4139-8550-ef441fa7a7a0@suse.com>
Date: Thu, 5 Jun 2025 16:42:53 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/5] console: add relocation hook
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 
Cc: xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini ,
 Andrew Cooper 
References: 
 <4f1889dc03ec4aa2cc0cd2bd14523a2c6f670bdb.1748182535.git-series.marmarek@invisiblethingslab.com>
 <0b17da9c-57db-4a8b-90af-e53e45cb1243@citrix.com> 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 26.05.2025 17:39, Marek Marczykowski-Górecki wrote:
> On Mon, May 26, 2025 at 04:08:17PM +0100, Andrew Cooper wrote:
>> On 25/05/2025 3:15 pm, Marek Marczykowski-Górecki wrote:
>>> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
>>> index 25189541244d..3ef819a252e4 100644
>>> --- a/xen/arch/x86/setup.c
>>> +++ b/xen/arch/x86/setup.c
>>> @@ -1481,6 +1481,8 @@ void asmlinkage __init noreturn __start_xen(void)
>>>          highmem_start &= ~((1UL << L3_PAGETABLE_SHIFT) - 1);
>>>  #endif
>>>  
>>> +    console_init_pre_relocate();
>>> +
>>>      /*
>>>       * Iterate backwards over all superpage-aligned RAM regions.
>>>       *
>>> @@ -1606,6 +1608,12 @@ void asmlinkage __init noreturn __start_xen(void)
>>>      if ( !xen_phys_start )
>>>          panic("Not enough memory to relocate Xen\n");
>>>  
>>> +    /*
>>> +     * Notify console drivers about relocation, before reusing old Xen's
>>> +     * memory.
>>> +     */
>>> +    console_init_post_relocate();
>>> +
>>
>> With reference to the next patch, there are printk()'s in this region
>> which want to work (in case something goes very wrong), so I don't think
>> setting dbc->suspended is the best approach.
> 
> I guess the post_relocate hook might be moved a bit earlier, but still,
> once relocation happens, the xhci console is not functional until it
> gets relocated too (for example - it would post new TRBs into a ring
> that isn't actually monitored by the controller).

Why is it that this ring is dependent upon Xen's position? If the ring was
dynamically allocated, it wouldn't change position when Xen is moved.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 14:44:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 14:44:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006984.1386244 (Exim 4.92)
	(envelope-from )
	id 1uNBpA-0008VI-S2; Thu, 05 Jun 2025 14:44:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006984.1386244; Thu, 05 Jun 2025 14: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 1uNBpA-0008VB-Nu; Thu, 05 Jun 2025 14:44:08 +0000
Received: by outflank-mailman (input) for mailman id 1006984;
 Thu, 05 Jun 2025 14:44: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 1uNBp9-0008V1-7o
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 14:44:07 +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 87f3b107-421b-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 16:44:06 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3a503d9ef59so854373f8f.3
 for ; Thu, 05 Jun 2025 07:44:06 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23506bdd06fsm120655405ad.101.2025.06.05.07.44.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 07:44:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 87f3b107-421b-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749134646; x=1749739446; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=9NanXTpNjjgTPjZfmAZcsWJv6jBI3rzDlUYGZAfdXqA=;
        b=LMT0uRuObfW0lUMSnCUDcmXATBpFsoMiusa2MuaUXcxoZQR+yXE27X6XwHJQAJKyyN
         FyvCyEArUiFRRK48TR8Z7AWv4dCAYMwjdWwGRJM5yfs2m4DARoWLiEeA0xcU0to2US4u
         JIigDL16JJqwTeVAHDpASLbRw3UFzyBOseFc+hAc38KCpcH7eojF837Ml8PIkSOlc+FW
         4Sf7v6fzbRMOHuKgnUnfv8zBtDYXHt46IMARoe+aMXwMbOsDLq5K6u4oeswnhBlherFS
         5jDVFPgr2Dmzn9xwBzt6DfSSbVcUayJk7Uabt9r+Cmh06y4j5aPpuErxwXBOUj1HRSyG
         x/7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749134646; x=1749739446;
        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=9NanXTpNjjgTPjZfmAZcsWJv6jBI3rzDlUYGZAfdXqA=;
        b=eCp8/VfTJoAunX3FwRPLpHk7v0DXradm1m7P/Bu5QbDtOXCbs7T4KcQsTZvW82G8rh
         d9cOaoLfmU9nTxO1G/XNuLIZuH/VUgXc3h2vcWavWSPAd4Rk5g6dGMiHJlPgp0CTiRna
         IOMzlBY1VuuoqB20U51xzHGLPsjoCYlByzb8EhlkySJcdROK/bIjWaiiQFTuxFhKKi6P
         Ia9wwvTcwua26lmBdx7svKxRaYBk6th/ybDpcMNMBiP85418ZO37RICbCFTxLTEFMs0m
         IdK7+VdCMncth3/ezb7fKlUEX2i/fJEzFGVKLr3d/Nom08C1BEytpgpFw7c7/FVByCkc
         Ksew==
X-Forwarded-Encrypted: i=1; AJvYcCVZtEOeoIACLKKdJdIUW5Td4HgX9RxY2toBeNvJHs1X2CZyX2JfEfxhtCR5TnDHQDwg6XnaVoOSNhg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyIQdkffJ8KBgxLndflRRoiERR64g+J5dRj2qIKCSLrN2Or+yig
	FE7ZEdZ6KuUIduIplXLo06D3kLGp85NaTW7xg9APNNBFHbyC1lhnueflIoKCvdt8tA==
X-Gm-Gg: ASbGncv8ThulNUQPCBgNTia+3mJoo+2ZGv4CkSwodIp7KyyAWmvZ3TSzO/m+UCSO6gB
	7WNR5bYylc5qxXsuXDTRB7bha6ubjtvp7gBvy1/CISNVpXwyMxtuJ8pY6Sn/aE6kJqOAifBF7dr
	bncMnbEOb3MNfS4g5OK7/n9wcr1tG0vfmUS5K/ptIo8/OdymdC8KoRLaUcc3RVTiiwQOquM0Sks
	Y15HjXfEcKzBrD3FFd8HHZSbdz8ALubRwFhvac6Jpj6yIO+ZzN3p93gMy6TGz5mUXrSBgMg+aH4
	5Ct3YNjioux1GRpWrsMOcNk9IJolay0vNd0+UjAWM1bidktLdIm8P7NCL3abn4PbqQE3Pqdv4FO
	g/aR6V0yAd+vm+55Oi5FWXEE12vA3HRuXkc/9im34ywfNQJo=
X-Google-Smtp-Source: AGHT+IGbBtShWuBwRWtj2mXCX+/UefX5xtamWy3jwxnBNYRMZ38o+3ELbjYC0o+PFaBVESr6NI6G2A==
X-Received: by 2002:a05:6000:3105:b0:3a1:fcd6:1e6b with SMTP id ffacd0b85a97d-3a51d975e3amr6691725f8f.57.1749134645618;
        Thu, 05 Jun 2025 07:44:05 -0700 (PDT)
Message-ID: <80d75ea7-35b6-406a-aae3-6a0fc3374682@suse.com>
Date: Thu, 5 Jun 2025 16:43:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 4/5] drivers/char: remove outdated comment in xhci
 driver
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 
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: 
 <6abaf3a05c8ea7204bea2046a799bc577e0b77e8.1748182535.git-series.marmarek@invisiblethingslab.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: <6abaf3a05c8ea7204bea2046a799bc577e0b77e8.1748182535.git-series.marmarek@invisiblethingslab.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 25.05.2025 16:15, Marek Marczykowski-Górecki wrote:
> The input handling is already implemented, and that limitation is not
> there anymore.
> 
> Signed-off-by: Marek Marczykowski-Górecki 

Acked-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 14:47:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 14:47:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006989.1386253 (Exim 4.92)
	(envelope-from )
	id 1uNBs1-0000dj-72; Thu, 05 Jun 2025 14:47:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006989.1386253; Thu, 05 Jun 2025 14:47:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNBs1-0000dc-46; Thu, 05 Jun 2025 14:47:05 +0000
Received: by outflank-mailman (input) for mailman id 1006989;
 Thu, 05 Jun 2025 14:47: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 1uNBs0-0000dW-98
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 14:47:04 +0000
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com
 [2a00:1450:4864:20::336])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f150ac9b-421b-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 16:47:03 +0200 (CEST)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-451d7b50815so9143025e9.2
 for ; Thu, 05 Jun 2025 07:47:03 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-451fb22b09dsm20438105e9.39.2025.06.05.07.47.01
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 07:47:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f150ac9b-421b-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749134822; x=1749739622; 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=di+wlchiJc2wLdNgQd/YIgUSr6Cs8eMtFIzEN8dijqA=;
        b=Tb/pNMdKzDbkDm44RbmKhlN7/U7MpO8mglV6KPwyFRgLjMfxU0zSLvbENHJY96x2OS
         bWvYNXknXKVYdxVDLyBjO/X8K8Z25pCjBMA5WOdPnpGKO52qLEZpb7z/Q47lCeUh49sS
         ImjWWvdCG5WH+FUOrxPqu0HgvASnGiKozbPho=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749134822; x=1749739622;
        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=di+wlchiJc2wLdNgQd/YIgUSr6Cs8eMtFIzEN8dijqA=;
        b=ptWbcke8pEERZXmyiBLpr/gG1X0XyRFGHV1fVmUtJ0XMhfqFPHjISpTHuYIRzSgOsq
         +QSdxp94HgZ15/sPgtWOQMbaEDmwS+aQvdSsrHPHxiVwMLEYL4YERAQXi5tawwV/lPJ+
         24Oc0iF72JsPKMesES9GQtM71T2/GHDAiD5fLAfoLOYKqwM0EPR/ZDlbcllYUE2sLTUV
         mu5d1KUdmNQMxu5+6rlLqRZWwasxcF8VrIo2U/Z4wGPo1DnXkulCewSH5sXb3BqJQm7n
         kR9pjVBzXF+k2BU2m/F6yX4ddCqauqRnNorL9Pi7j1Z0KkjRhEOBWuYMPdvuwaEm3egD
         BKlQ==
X-Gm-Message-State: AOJu0Yx5Q18XsIeNKtjw2lFibCttX5/2MOVIqUbo71eEPQR86q+C3EpJ
	QT6WFuUrchA+CCBz6pPot2Emg1j5E6EHSxOu9ntsCAMsbSx8d4TCeP6cP1TThiTfoG0=
X-Gm-Gg: ASbGnctaX5cBewkb285P1F5nKq8bP+rjf/UYexaLkdbchymwu7wLTOpUNk2zqBaIx/+
	GOx4Cbr/RUhkVMsiBDf2RvXKQoiWOtL1b41juLlfSAoUj26QIKS1pCAFwxE9a3OBt4eVo5+iqxJ
	qOjO+7p0UkDSZkfoMNn7Vl3oojS8pOAW6DotLFft79P5pfNRDJ/AA7cabVwPs4CXnhrqzqxTmAm
	nxDxorNTlg4CE86WZLCm+YGAjjLGEXW3tNpyhU8bgWeJ6zz1o9IGO0o8YMvO5TV0rDML7aKAxci
	QNQsyJqX8b1g90k+37xM4y07zSqMDPU+myPgVq1cWDAYQ7Xy22aLnWYwNxxW45vGy0YaN+Vf8iC
	ydHCDK9InhmGDfV1YCUQ=
X-Google-Smtp-Source: AGHT+IER/bpJNHlYfJHc+zoLblH6SNgUzD2o/kVjRW5JAXYVwPuEeCQnKZQltTkyTzqR8d7koVs3Ww==
X-Received: by 2002:a05:600c:8cd:b0:442:f4a3:9388 with SMTP id 5b1f17b1804b1-451f270de8cmr45936035e9.19.1749134822318;
        Thu, 05 Jun 2025 07:47:02 -0700 (PDT)
Date: Thu, 5 Jun 2025 16:47:01 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jiqian Chen 
Cc: xen-devel@lists.xenproject.org, Huang Rui ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v5 06/10] vpci: Hide extended capability when it fails to
 initialize
Message-ID: 
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
 <20250526094559.140423-7-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250526094559.140423-7-Jiqian.Chen@amd.com>

On Mon, May 26, 2025 at 05:45:55PM +0800, Jiqian Chen wrote:
> When vpci fails to initialize a extended capability of device, it
> just returns an error and vPCI gets disabled for the whole device.
> 
> So, add function to hide extended capability when initialization
> fails. And remove the failed extended capability handler from vpci
> extended capability list.
> 
> Signed-off-by: Jiqian Chen 
> ---
> cc: "Roger Pau Monné" 
> cc: Andrew Cooper 
> cc: Anthony PERARD 
> cc: Michal Orzel 
> cc: Jan Beulich 
> cc: Julien Grall 
> cc: Stefano Stabellini 
> ---
> v4->v5 changes:
> * Modify the hex digits of PCI_EXT_CAP_NEXT_MASK and PCI_EXT_CAP_NEXT to be low case.
> * Rename vpci_ext_capability_mask to vpci_ext_capability_hide.
> 
> v3->v4 changes:
> * Change definition of PCI_EXT_CAP_NEXT to be "#define PCI_EXT_CAP_NEXT(header) (MASK_EXTR(header, PCI_EXT_CAP_NEXT_MASK) & 0xFFCU)" to avoid redundancy.
> * Modify the commit message.
> * Change vpci_ext_capability_mask() to return error instead of using ASSERT.
> * Set the capability ID part to be zero when we need to hide the capability of position 0x100U.
> * Add check "if ( !offset )" in vpci_ext_capability_mask().
> 
> v2->v3 changes:
> * Separated from the last version patch "vpci: Hide capability when it fails to initialize".
> * Whole implementation changed because last version is wrong.
>   This version gets target handler and previous handler from vpci->handlers, then remove the target.
> * Note: a case in function vpci_ext_capability_mask() needs to be discussed,
>   because it may change the offset of next capability when the offset of target
>   capability is 0x100U(the first extended capability), my implementation is just to
>   ignore and let hardware to handle the target capability.
> 
> v1->v2 changes:
> * Removed the "priorities" of initializing capabilities since it isn't used anymore.
> * Added new function vpci_capability_mask() and vpci_ext_capability_mask() to
>   remove failed capability from list.
> * Called vpci_make_msix_hole() in the end of init_msix().
> 
> Best regards,
> Jiqian Chen.
> ---
>  xen/drivers/vpci/vpci.c    | 100 +++++++++++++++++++++++++++++++++++--
>  xen/include/xen/pci_regs.h |   5 +-
>  2 files changed, 100 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
> index 60e7654ec377..2d4794ff3dea 100644
> --- a/xen/drivers/vpci/vpci.c
> +++ b/xen/drivers/vpci/vpci.c
> @@ -176,6 +176,98 @@ static int vpci_capability_hide(struct pci_dev *pdev, unsigned int cap)
>      return 0;
>  }
>  
> +static struct vpci_register *vpci_get_previous_ext_cap_register(
> +    struct vpci *vpci, unsigned int offset)
> +{
> +    uint32_t header;
> +    unsigned int pos = PCI_CFG_SPACE_SIZE;
> +    struct vpci_register *r;
> +
> +    if ( offset <= PCI_CFG_SPACE_SIZE )
> +    {
> +        ASSERT_UNREACHABLE();
> +        return NULL;
> +    }
> +
> +    r = vpci_get_register(vpci, pos, 4);
> +    if ( !r )
> +        return NULL;
> +
> +    header = (uint32_t)(uintptr_t)r->private;
> +    pos = PCI_EXT_CAP_NEXT(header);
> +    while ( pos > PCI_CFG_SPACE_SIZE && pos != offset )
> +    {
> +        r = vpci_get_register(vpci, pos, 4);
> +        if ( !r )
> +            return NULL;
> +        header = (uint32_t)(uintptr_t)r->private;
> +        pos = PCI_EXT_CAP_NEXT(header);
> +    }
> +
> +    if ( pos <= PCI_CFG_SPACE_SIZE )
> +        return NULL;

Same comment as in the previous patch, I think the proposed for loop
there can also be used here to reduce a bit the code size (and unify
the return paths).

> +
> +    return r;
> +}
> +
> +static int vpci_ext_capability_hide(struct pci_dev *pdev, unsigned int cap)
> +{
> +    const unsigned int offset = pci_find_ext_capability(pdev->sbdf, cap);
> +    struct vpci_register *rm, *prev_r;

s/rm/r/

> +    struct vpci *vpci = pdev->vpci;
> +    uint32_t header, pre_header;
> +
> +    if ( !offset )

I think you want offset < PCI_CFG_SPACE_SIZE here?

> +    {
> +        ASSERT_UNREACHABLE();
> +        return 0;
> +    }
> +
> +    spin_lock(&vpci->lock);
> +    rm = vpci_get_register(vpci, offset, 4);
> +    if ( !rm )
> +    {
> +        spin_unlock(&vpci->lock);
> +        return -ENODEV;
> +    }
> +
> +    header = (uint32_t)(uintptr_t)rm->private;
> +    if ( offset == PCI_CFG_SPACE_SIZE )
> +    {
> +        if ( PCI_EXT_CAP_NEXT(header) <= PCI_CFG_SPACE_SIZE )
> +            rm->private = (void *)(uintptr_t)0;
> +        else
> +            /*
> +             * If this case removes target capability of position 0x100U, then
> +             * it needs to move the next capability to be in position 0x100U,
> +             * that would cause the offset of next capability in vpci different
> +             * from the hardware, then cause error accesses, so here chooses to
> +             * set the capability ID part to be zero.

/*
 * The first extended capability (0x100) cannot be removed from the linked
 * list, so instead mask its capability ID to return 0 and force OSes
 * to skip it.
 */

Is simpler IMO and conveys the same message.

> +             */
> +            rm->private = (void *)(uintptr_t)(header &
> +                                              ~PCI_EXT_CAP_ID(header));
> +
> +        spin_unlock(&vpci->lock);
> +        return 0;
> +    }
> +
> +    prev_r = vpci_get_previous_ext_cap_register(vpci, offset);
> +    if ( !prev_r )
> +    {
> +        spin_unlock(&vpci->lock);
> +        return -ENODEV;
> +    }
> +
> +    pre_header = (uint32_t)(uintptr_t)prev_r->private;
> +    prev_r->private = (void *)(uintptr_t)((pre_header &
> +                                           ~PCI_EXT_CAP_NEXT_MASK) |
> +                                          (header & PCI_EXT_CAP_NEXT_MASK));

No strong opinion (and your code is correct), but it might be easier
to read as:

pre_header &= ~PCI_EXT_CAP_NEXT_MASK;
pre_header |= header & PCI_EXT_CAP_NEXT_MASK;
prev_r->private = (void *)(uintptr_t)pre_header;

It's still tree lines of code at the end.  I would also add a newline
to separate from the removal of rm.

> +    list_del(&rm->node);
> +    spin_unlock(&vpci->lock);
> +    xfree(rm);

Newline before the return preferably.

> +    return 0;
> +}
> +
>  static int vpci_init_capabilities(struct pci_dev *pdev)
>  {
>      for ( unsigned int i = 0; i < NUM_VPCI_INIT; i++ )
> @@ -209,11 +301,11 @@ static int vpci_init_capabilities(struct pci_dev *pdev)
>                     pdev->domain, &pdev->sbdf,
>                     is_ext ? "extended" : "legacy", cap);
>              if ( !is_ext )
> -            {
>                  rc = vpci_capability_hide(pdev, cap);
> -                if ( rc )
> -                    return rc;
> -            }
> +            else
> +                rc = vpci_ext_capability_hide(pdev, cap);
> +            if ( rc )
> +                return rc;

Could the code in the previous patch be:

if ( !is_ext )
    rc = vpci_capability_hide(pdev, cap);

if ( rc )
    return rc;

So that your introduction here is simpler?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 14:50:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 14:50:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1006995.1386264 (Exim 4.92)
	(envelope-from )
	id 1uNBuy-000279-LF; Thu, 05 Jun 2025 14:50:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1006995.1386264; Thu, 05 Jun 2025 14:50: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 1uNBuy-000272-HF; Thu, 05 Jun 2025 14:50:08 +0000
Received: by outflank-mailman (input) for mailman id 1006995;
 Thu, 05 Jun 2025 14:50: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 1uNBux-00026v-LN
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 14:50:07 +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 5e29203c-421c-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 16:50:05 +0200 (CEST)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-604f26055c6so4431923a12.1
 for ; Thu, 05 Jun 2025 07:50:05 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ada5d7ff08bsm1282987266b.17.2025.06.05.07.50.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 07:50:04 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5e29203c-421c-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749135005; x=1749739805; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=UPn8W6WrtLPVEY1yzLklS5GkBy2VKRHwBirs54XXYso=;
        b=W85AYLiPaasz8Pyv3LRcFwTDltR3I1OBujL4BAUZUlkemlHP8f83/ITrFwMRV8+Fj+
         DNvKfhA+xoE9edVsKkc5HZNdKtAjjSqOLVFsXiWr7ZgIEulwawFvRKCpVOuTYjbPI/K6
         J6Y7bsFzgqgrk6KulSpBsdqkFfwBiqcVGmIzj6zK7y7GJmwhhcvuzWfb8ILP7vogoso2
         x4EBGtzsogTHeFSztQ2OWJpHiPNSkKSH4Tu8+hpMAsreUsLaV93DF21p50I93prwh4OT
         AyLAPfl86u7ul2boDIc9Pfx50ROaRbLluwKids/whN6Z1o9TUD4qcj/n/9t6sjMJRByx
         bZ5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749135005; x=1749739805;
        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=UPn8W6WrtLPVEY1yzLklS5GkBy2VKRHwBirs54XXYso=;
        b=fRjdrKpAKMZJJr2Tu6AFfq1CEEoDCzmbHM2tRdqCaZXm+ktkVXtTWEG2VDI9OsTqn4
         2XvblzbOFiiGmdTSmrSxJ2uHf5z23Myj5JHVTzALJ5VBny91Po2KS4JnPrwWbtZSn73i
         7htWC/JkJEsmrlCdFQgZ2s0Nx+7P33wxsMH1kBSnE4OaQDWCZxY8NuIVXISAjt6cw/wa
         RG8UenqrCXFLMAPDUfPSK6/WuilC5YiW3z9o0+bhPEsKEX0+xGBL6MerIajJiMjaRNMs
         SlY7E0Ie+6q4ivIghuk5Xt8wWLfa+6vA7KjdavxilUFoNZ0810nctb3zg9C71tEv0Mwm
         R92A==
X-Forwarded-Encrypted: i=1; AJvYcCWJnR+mWnRJcd+5ppksqhNUKY4Vk+pQeLg5S0nXfqXslOYp8TV7LCY+XXJ5QsXZxI0MlvUZjF4Gois=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwtEz1EpDpCPz7Ovlj9jtF5Zw11g+bHuJPgJyoosb7egcgIXINC
	NEcIok4vz5nGyyQUr08gL/Tvl3DGOmjSF4DOgnMj8Wr7IcEWM2zs/gI0CzFnTORf3OIDRZR6vzi
	b3XA=
X-Gm-Gg: ASbGncsM0o/eHy/gmMaoLgzL63PhkVbA8U5OWbGXDKb0/m28lcy/+puVh4w+R39mkBn
	HJnogPW5gafs2jXZwZlGW4tEzWvQSoSzBWNaM4KAFibPfpBvhRxPhKlvx7H2si7CNfF9WEH04oL
	gznF3Y/qY6svdyRZm2W8/YxxoPsZWqqxIn3hC6e6j4t8yKnSn07CB9qfg0Mzn0ijvrJKQPnkoHO
	RJONYQcuWqGhkEVbtygLN5hDxyzZ79clqQ6Uyp5r1Uw0CG96zJN1HquOxSexlD50eKe0x0PeGO8
	TB7VU15uc05OilDmLE4pYLRktZAOTMN6kmVIDxuanwGp4TzgCildLlP+QZCF2HXPHF7ToxoXB9J
	WYKn2dG1N7tHhzZtuTOzYoa5bP6i6ZpHU7ZaI
X-Google-Smtp-Source: AGHT+IFvdt07i7uoSVz4j/cerryx8WdmIT9dO8j0lAJ58MYL8dlhUyydVFbTzvLJByaHi5VlKBUV+w==
X-Received: by 2002:a17:907:3dac:b0:ad2:2fdb:b0ab with SMTP id a640c23a62f3a-ade07901184mr407296066b.29.1749135005014;
        Thu, 05 Jun 2025 07:50:05 -0700 (PDT)
Message-ID: <4ed9d6ce-5634-4dd9-86e9-5d1f84a43e10@suse.com>
Date: Thu, 5 Jun 2025 16:50:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] vmx: Introduce vcpu single context VPID invalidation
To: Teddy Astie 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <83d0e7dfc076e9453fb6537e5948c03d90e947da.1748594036.git.teddy.astie@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: <83d0e7dfc076e9453fb6537e5948c03d90e947da.1748594036.git.teddy.astie@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 30.05.2025 10:48, Teddy Astie wrote:
> Introduce vpid_sync_vcpu_context to do a single-context invalidation
> on the vpid attached to the vcpu as a alternative to per-gva and all-contexts
> invlidations.
> 
> Signed-off-by: Teddy Astie 
> ---
> Extracted from SEV series.
> This will be used for instance in fixed-ASID patches (in SEV series).

I think it should be in that series, which may still be some long way out.
Until then we'd carry dead/unreachable code (disliked by Misra), and we'd
risk that this bit-rots because of being unused.

> --- a/xen/arch/x86/include/asm/hvm/vmx/vmx.h
> +++ b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
> @@ -451,6 +451,23 @@ static inline void ept_sync_all(void)
>  
>  void ept_sync_domain(struct p2m_domain *p2m);
>  
> +static inline void vpid_sync_vcpu_context(struct vcpu *v)

pointer-to-const?

> +{
> +    int type = INVVPID_SINGLE_CONTEXT;

Please don't use plain int when all values possibly held in a variable are
non-negative.

> +    /*
> +     * If single context invalidation is not supported, we escalate to
> +     * use all context invalidation.
> +     */
> +    if ( likely(cpu_has_vmx_vpid_invvpid_single_context) )
> +        goto execute_invvpid;
> +
> +    type = INVVPID_ALL_CONTEXT;
> +
> +execute_invvpid:

There no reason at all to use "goto" here (and with that replaced there's
then also no style issue with the label placement).

Jan

> +    __invvpid(type, v->arch.hvm.n1asid.asid, 0);
> +}
> +
>  static inline void vpid_sync_vcpu_gva(struct vcpu *v, unsigned long gva)
>  {
>      int type = INVVPID_INDIVIDUAL_ADDR;



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 14:51:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 14:51:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007005.1386273 (Exim 4.92)
	(envelope-from )
	id 1uNBwJ-0002hX-0o; Thu, 05 Jun 2025 14:51:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007005.1386273; Thu, 05 Jun 2025 14:51:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNBwI-0002hQ-Ti; Thu, 05 Jun 2025 14:51:30 +0000
Received: by outflank-mailman (input) for mailman id 1007005;
 Thu, 05 Jun 2025 14:51: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 1uNBwH-0002ge-UB
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 14:51:30 +0000
Received: from fout-a4-smtp.messagingengine.com
 (fout-a4-smtp.messagingengine.com [103.168.172.147])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8f160b73-421c-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 16:51:28 +0200 (CEST)
Received: from phl-compute-06.internal (phl-compute-06.phl.internal
 [10.202.2.46])
 by mailfout.phl.internal (Postfix) with ESMTP id 23A8713802AB;
 Thu,  5 Jun 2025 10:51:27 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-06.internal (MEProxy); Thu, 05 Jun 2025 10:51:27 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 5 Jun 2025 10:51:25 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8f160b73-421c-11f0-a300-13f23c93f187
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=1749135087;
	 x=1749221487; bh=gfg+NcyQfuLhm0vT8GeOOJR34EtiYSk1+xB/aBcVMmw=; b=
	XeLv3gNulUCMrxNTOXfq8CddMxvkJ1XbUkh7IIb2l0uRPEYCZBq9OOKv03eyHtAl
	p4nG5aW/yY9IabnFWOlwt5ywdlxrk07sAaF/7kW131unZYcMyj+BWLY0umNATf5T
	sFVCGlXeKSa8A5foPqi8WmzrMgPkHY/tULF5cnJpXa7TvCTn6vOT0ElZlBTjXiWu
	xEpykHNs0IM+EefiUaBmVg5LD+ST5v9M0fPBAdT7wNweJZnrPOpSuKRY7ScrGjCs
	0HA7ssXl6ev4WqsnTu3D7FnncNTOa3OJjCZV/h5LnfA9u+up49p1cNISfww7jXKS
	NCVxuMv1yb8TvYSuf/peTQ==
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=
	1749135087; x=1749221487; bh=gfg+NcyQfuLhm0vT8GeOOJR34EtiYSk1+xB
	/aBcVMmw=; b=bcf9QxT6zPX0BwHKLuQp62TO3NqpB+ieDHWXx4/XCp8sDC3df36
	OWQJwTluwKg9YADA5tFuv7JcHxgkiX7mgn8Cxoa8+qztdyUojg6fBG/Uo0Zr/p81
	C8+f1W9C5Ff9+k4HFndYx1CMLe73LARpaApz8+R6TXNCtBg6ZtsSFSmd9pGjoPlw
	V2YcxZ+RsbpWot18SHknfbigcPfEchSvRI8dfdEwtSK9sJ1pXFwi6+2+rsnzq75W
	eS9k2XqXSscs1blOBwAcVXekplUV9WzJHqnlfVJM47TjdmOu09xKf5ui+Yj3SQKq
	miP8nWpKpfQWWS3GxNwCN32V958pphyZsPw==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugdefjeejucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtjeen
    ucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomh
    grrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggft
    rfgrthhtvghrnhepgfduleetfeevhfefheeiteeliefhjefhleduveetteekveettddvge
    euteefjedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho
    mhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnh
    gspghrtghpthhtohepkedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepjhgsvghu
    lhhitghhsehsuhhsvgdrtghomhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsth
    hsrdigvghnphhrohhjvggtthdrohhrghdprhgtphhtthhopehrohhgvghrrdhprghusegt
    ihhtrhhigidrtghomhdprhgtphhtthhopegrnhhthhhonhihrdhpvghrrghrugesvhgrth
    gvshdrthgvtghhpdhrtghpthhtohepmhhitghhrghlrdhorhiivghlsegrmhgurdgtohhm
    pdhrtghpthhtohepjhhulhhivghnseigvghnrdhorhhgpdhrtghpthhtohepshhsthgrsg
    gvlhhlihhniheskhgvrhhnvghlrdhorhhgpdhrtghpthhtoheprghnughrvgifrdgtohho
    phgvrhefsegtihhtrhhigidrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Thu, 5 Jun 2025 16:51:23 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Jan Beulich 
Cc: xen-devel@lists.xenproject.org,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Stefano Stabellini ,
	Andrew Cooper 
Subject: Re: [PATCH v1 1/5] console: add relocation hook
Message-ID: 
References: 
 <4f1889dc03ec4aa2cc0cd2bd14523a2c6f670bdb.1748182535.git-series.marmarek@invisiblethingslab.com>
 <0b17da9c-57db-4a8b-90af-e53e45cb1243@citrix.com>
 
 <66cfdee6-5dc2-4139-8550-ef441fa7a7a0@suse.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="hAch/rFUOg5PeioD"
Content-Disposition: inline
In-Reply-To: <66cfdee6-5dc2-4139-8550-ef441fa7a7a0@suse.com>


--hAch/rFUOg5PeioD
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 5 Jun 2025 16:51:23 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Jan Beulich 
Cc: xen-devel@lists.xenproject.org,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Stefano Stabellini ,
	Andrew Cooper 
Subject: Re: [PATCH v1 1/5] console: add relocation hook

On Thu, Jun 05, 2025 at 04:42:53PM +0200, Jan Beulich wrote:
> On 26.05.2025 17:39, Marek Marczykowski-G=C3=B3recki wrote:
> > On Mon, May 26, 2025 at 04:08:17PM +0100, Andrew Cooper wrote:
> >> On 25/05/2025 3:15 pm, Marek Marczykowski-G=C3=B3recki wrote:
> >>> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> >>> index 25189541244d..3ef819a252e4 100644
> >>> --- a/xen/arch/x86/setup.c
> >>> +++ b/xen/arch/x86/setup.c
> >>> @@ -1481,6 +1481,8 @@ void asmlinkage __init noreturn __start_xen(voi=
d)
> >>>          highmem_start &=3D ~((1UL << L3_PAGETABLE_SHIFT) - 1);
> >>>  #endif
> >>> =20
> >>> +    console_init_pre_relocate();
> >>> +
> >>>      /*
> >>>       * Iterate backwards over all superpage-aligned RAM regions.
> >>>       *
> >>> @@ -1606,6 +1608,12 @@ void asmlinkage __init noreturn __start_xen(vo=
id)
> >>>      if ( !xen_phys_start )
> >>>          panic("Not enough memory to relocate Xen\n");
> >>> =20
> >>> +    /*
> >>> +     * Notify console drivers about relocation, before reusing old X=
en's
> >>> +     * memory.
> >>> +     */
> >>> +    console_init_post_relocate();
> >>> +
> >>
> >> With reference to the next patch, there are printk()'s in this region
> >> which want to work (in case something goes very wrong), so I don't thi=
nk
> >> setting dbc->suspended is the best approach.
> >=20
> > I guess the post_relocate hook might be moved a bit earlier, but still,
> > once relocation happens, the xhci console is not functional until it
> > gets relocated too (for example - it would post new TRBs into a ring
> > that isn't actually monitored by the controller).
>=20
> Why is it that this ring is dependent upon Xen's position? If the ring was
> dynamically allocated, it wouldn't change position when Xen is moved.

The console is setup quite early, I don't think I can allocate memory at
this stage, no?

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

--hAch/rFUOg5PeioD
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmhBrusACgkQ24/THMrX
1yy1XAf+I/S6cMtPZeGZosKFALu2NRpDqrK1ddIApICIzIjEbdjTISDHE/z+B7R0
uN3qQrfVGq5RneXgUHmfrdFm1tLcktzoNrPR5Z2ExX/jdL+53sHVSdaKuZR4NhIr
wI1nna0WGpBqFucBYDqWiDYh04GoFr+CoKEW8UmvAtEk0x74R0zRMKv0DpJ0LEva
vrUo5beAZhaC6ujMqxyyQUqVQFDnFHJPBIXMN5X98/y7OvnF3skSwsp6BoPL5a6u
ag4axr/+NzgjNRAmsa+RF3rVg/BFc5lBCvb019n3prV9humDEe5g4wwnnoNeLRQ2
8giSyRIccC4ocusnktxwZqj9yDoYEA==
=+AUt
-----END PGP SIGNATURE-----

--hAch/rFUOg5PeioD--


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 15:01:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 15:01:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007015.1386283 (Exim 4.92)
	(envelope-from )
	id 1uNC5P-0004k0-NR; Thu, 05 Jun 2025 15:00:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007015.1386283; Thu, 05 Jun 2025 15:00: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 1uNC5P-0004jt-KY; Thu, 05 Jun 2025 15:00:55 +0000
Received: by outflank-mailman (input) for mailman id 1007015;
 Thu, 05 Jun 2025 15:00: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 1uNC5O-0004iI-Ik
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 15:00:54 +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 e004e94e-421d-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 17:00:53 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-451d6ade159so9237915e9.1
 for ; Thu, 05 Jun 2025 08:00:53 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a4efe5b8besm25068733f8f.16.2025.06.05.08.00.51
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 08:00:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e004e94e-421d-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749135652; x=1749740452; 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=fvNIJJcSe7ZYoHm2rfWZcNYQeLM/PrCPi0zA+WJTgBA=;
        b=oOpTPbHRHnmUIs3ht1SuJR1/H7NGshR6f2mnlXRQEK+nec/Emzga+D0rIVy8IBlJZe
         dK9wZM/QYICjH7WypsRXUXX2aJMdAidR6t5co3EwF0cfxMXpdZT8B2zVar+o77mpkc2B
         CSnLLQIWGE4Eb3ZwEaqL3J55TcwFCPLUJgu2E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749135652; x=1749740452;
        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=fvNIJJcSe7ZYoHm2rfWZcNYQeLM/PrCPi0zA+WJTgBA=;
        b=T3xDXoi4YG5BF1bFZ7fID8q1Ke5vgqdgIIULbmj5Wgt+TdfO6z/6n77sLJrYbj0hFa
         8QPwg0fdNcql/hYrHJ5pPxvgpwIy/cvselsqE8trCHexXhwoKqRh3LfagoEr/4br348Q
         2U6XUTOpj8j396w42Tz8BKoLyM8mUjzc3O3Bs68oacCI3eL+EL6NYqzqTE7s4i7S8r/w
         H3e2VrWbL/gdsRt1NnZVgaY9yTb0MvUAnitWP4nzOQjxa8HhzV0LF27lidHk6y1ObR0g
         hFz54h7I9Rpf4EKNlZYTP6HUV+ZCdFz2+HTJhgLqGJiTsv4UsrHxHTkEzSfGCCNekYIo
         LeMQ==
X-Gm-Message-State: AOJu0YxBew5jXAuIw5PucKVy/S6PyPSyPi8ErTlDj0hLAOA9CIJIer+p
	Psw1qjFNQJ2F2Jw73b1q/++7JL8ot9AzMPbyHHXXjp5BEj65oF/4QzbEcWfbQ2rheqs=
X-Gm-Gg: ASbGncsSP64R5UXQiy6GNMEajH0x3iuO0yzys0o7CnXoQOOsDOIVdqHS3zl5FYaEqe0
	mOWwCaCY3ekaIyQ3yY3/F4hMaIYbOcBLUegkthPi/Ei85hCmwPD3dIUbw4XnI1eoiRdbNOCKbjQ
	Je8+UGg6OxG04RDhIw6AxD2zBaZOEP/e6fn3QxZoFB6wpDZBHDWtt1y55h42OODdIkrH3P4LL4Q
	Q/GOCrPI3pEFYl6wxgS1s+np2IpVc++c+K0UQvnUY1niE+bEs+J6NZq7NBjp8qbUUfkWsiZxz1M
	czr4dV1cBlyOI9MWye+FXldfA9Dr/FZMErKZSYNK5RygHcr66t/j+ooS4LEFPBejGT/EiXy7wSd
	tpSLlUiy2Tv/1leivf1s=
X-Google-Smtp-Source: AGHT+IG6A9WewjTN0p3wEnbBWSrHzRKowDOgkCfzLW0DgD481xJJYEEVUw/ZRVIA6EbqRuDzFcTs9Q==
X-Received: by 2002:a05:600c:1d98:b0:43e:bdf7:7975 with SMTP id 5b1f17b1804b1-451f0b3988cmr63911675e9.32.1749135652064;
        Thu, 05 Jun 2025 08:00:52 -0700 (PDT)
Date: Thu, 5 Jun 2025 17:00:50 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jiqian Chen 
Cc: xen-devel@lists.xenproject.org, Huang Rui ,
	Anthony PERARD 
Subject: Re: [PATCH v5 07/10] vpci: Refactor vpci_remove_register to remove
 matched registers
Message-ID: 
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
 <20250526094559.140423-8-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250526094559.140423-8-Jiqian.Chen@amd.com>

On Mon, May 26, 2025 at 05:45:56PM +0800, Jiqian Chen wrote:
> vpci_remove_register() only supports removing a register in a time,
> but the follow-on changes need to remove all registers within a range.
> So, refactor it to support removing all matched registers in a calling

"So, refactor it to support removing all registers in a given region."

> time.
> 
> And it is no matter to remove a non exist register, so remove the

s/no matter/no issue/

> __must_check prefix.
> 
> Signed-off-by: Jiqian Chen 

Reviewed-by: Roger Pau Monné 

Thanks.


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 15:15:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 15:15:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007025.1386292 (Exim 4.92)
	(envelope-from )
	id 1uNCJ6-0006oS-SH; Thu, 05 Jun 2025 15:15:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007025.1386292; Thu, 05 Jun 2025 15:15: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 1uNCJ6-0006oL-Pf; Thu, 05 Jun 2025 15:15:04 +0000
Received: by outflank-mailman (input) for mailman id 1007025;
 Thu, 05 Jun 2025 15:15: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 1uNCJ5-0006oF-Hn
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 15:15:03 +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 d9b0cd6f-421f-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 17:15:01 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a4f78ebec8so661143f8f.0
 for ; Thu, 05 Jun 2025 08:15:01 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-451fb220385sm21590475e9.28.2025.06.05.08.15.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 08:15:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d9b0cd6f-421f-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749136501; x=1749741301; 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=BzShc25RIK93H1a1luCRVsTdWpcCisBN+loG66/M3m4=;
        b=IMFy7hPtsRpSNVZlvsG1c/oDpDaOuKJTTDX48RmzxFDUbp3fw/sidCmvtrDJN6Ru++
         9RjaZ+9nWHus/0K8FFaG4cEnsYD3C+pEgr+14Qzc2GrKnJdy5r+H12hb1bFcxtFcSpFu
         VIkFyX67uaCx5wsq0NHqfVWeeBkyEFfskp/a4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749136501; x=1749741301;
        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=BzShc25RIK93H1a1luCRVsTdWpcCisBN+loG66/M3m4=;
        b=ZRUTt08bGuOqaASQzTBqvPD4XDj4lSWBMeNjBhQ+DS+vY8CLl/MQaeWsvyHIWm7jLB
         4IC1ilFurw4ePlFXwqgyAVSXecxXJYX++TA6FvEMysOljWPbh3x7bPwig0UVmv/A5Zll
         SJ1JDp4WfdTo/wnIsgf+BO0EUlu4E3UYA0BkYi1k8mikDxMmC4QyVD9UZwED4Rqfe/Zj
         Stzfbb5XtT/5F0J1crK/UGGaJuxI6wfAecNotnENJ5Qx6FYng7OhO7DFfhHIM18IzkUK
         K/rGiVGCZ51gmQvNgXNJjUF3VF5kZdLcbdVBalyZPrDxyJZ0tE3GpjQ3epS1xLONG4Je
         8+zw==
X-Gm-Message-State: AOJu0YyBe4bwFgLKCcLKjJ6L0dmk6Ey7iB0UfppUa87tPeNk6eg5SGe0
	uaI3jVklU39NK1f+SDdRZuwKP/DYAaIUbmca+u3BnpVl3T27XLNop0mfNAD9x0WKOxw=
X-Gm-Gg: ASbGncuqvsklZ1MlDhVBufEvqDYksTqpvxPbp8fIBBb1UdfgljpfEruvurIq4O4UaDT
	0LABbCEn5NtkoGoQLknpspWPQHm+WgR/RbNAouNApxG5y0hRGUnrts9lVC77UIIUMqn5MSNQbRq
	PaIF//zBaIDk62wYSsWpfdjqEzKmSUCdRSPEegjqwqSLm63XLFYE4LDbEnCxueRJZx4tiA+76A7
	hS3TsAtWyeGpPpgm6DPSAYT6V16rBc/MScWR+uH8+hdu9FvVKCEADci/IWa7VsBxE7jwDb6iPLk
	UcjCH3EZrUOU87C3wnH5xtO8nV+Mce5Liajel1iMHkdkDwbfum9EIdZr3uk9Bl5Z3Kp9f5/mmaY
	kdsujj5MSMr99vcx2SOT9Hg1L9kaf8A==
X-Google-Smtp-Source: AGHT+IErPVrCdYMpgqeNmLE4IGMHQfw+R9SN/p6x04xatxuA8rwvp4FP6wNiHEAWK+HW62TI4TvIaA==
X-Received: by 2002:a05:6000:250f:b0:3a4:edad:2a59 with SMTP id ffacd0b85a97d-3a51d8f6a3bmr6905314f8f.1.1749136500728;
        Thu, 05 Jun 2025 08:15:00 -0700 (PDT)
Date: Thu, 5 Jun 2025 17:14:59 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jiqian Chen 
Cc: xen-devel@lists.xenproject.org, Huang Rui 
Subject: Re: [PATCH v5 08/10] vpci/rebar: Free Rebar resources when
 init_rebar() fails
Message-ID: 
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
 <20250526094559.140423-9-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250526094559.140423-9-Jiqian.Chen@amd.com>

On Mon, May 26, 2025 at 05:45:57PM +0800, Jiqian Chen wrote:
> When init_rebar() fails, current logic return fail and free Rebar-related
> resources in vpci_deassign_device(). But the previous new changes will
> hide Rebar capability and return success, it can't reach
> vpci_deassign_device() to remove resources if hiding success, so those
> resources must be removed in cleanup function of Rebar.
> 
> To do that, implement cleanup function for Rebar.
> 
> Signed-off-by: Jiqian Chen 

LGTM, just one nit about a bounds check.

> ---
> cc: "Roger Pau Monné" 
> ---
> v4->v5 changes:
> * Change definition "static void cleanup_rebar" to "static int cf_check cleanup_rebar" since cleanup hook is changed to be int.
> 
> v3->v4 changes:
> * Change function name from fini_rebar() to cleanup_rebar().
> * Change the error number to be E2BIG and ENXIO in init_rebar().
> 
> v2->v3 changes:
> * Use fini_rebar() to remove all register instead of in the failure path of init_rebar();
> 
> v1->v2 changes:
> * Called vpci_remove_registers() to remove all possible registered registers instead of using a array to record all registered register.
> 
> Best regards,
> Jiqian Chen.
> ---
>  xen/drivers/vpci/rebar.c | 35 ++++++++++++++++++++++++-----------
>  1 file changed, 24 insertions(+), 11 deletions(-)
> 
> diff --git a/xen/drivers/vpci/rebar.c b/xen/drivers/vpci/rebar.c
> index 9cafd80ca2c9..4b1892fab3d6 100644
> --- a/xen/drivers/vpci/rebar.c
> +++ b/xen/drivers/vpci/rebar.c
> @@ -49,6 +49,26 @@ static void cf_check rebar_ctrl_write(const struct pci_dev *pdev,
>      bar->guest_addr = bar->addr;
>  }
>  
> +static int cf_check cleanup_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 || !is_hardware_domain(pdev->domain) )

I think you could check rebar_offset < PCI_CFG_SPACE_SIZE to be more
accurate?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 15:17:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 15:17:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007031.1386302 (Exim 4.92)
	(envelope-from )
	id 1uNCLO-0007KD-6y; Thu, 05 Jun 2025 15:17:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007031.1386302; Thu, 05 Jun 2025 15:17: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 1uNCLO-0007K6-4S; Thu, 05 Jun 2025 15:17:26 +0000
Received: by outflank-mailman (input) for mailman id 1007031;
 Thu, 05 Jun 2025 15:17: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 1uNCLN-0007K0-8x
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 15:17:25 +0000
Received: from mail132-4.atl131.mandrillapp.com
 (mail132-4.atl131.mandrillapp.com [198.2.132.4])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2b7ac91d-4220-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 17:17:19 +0200 (CEST)
Received: from pmta09.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail132-4.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4bCp312jpbzlfcQV
 for ; Thu,  5 Jun 2025 15:17:17 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 4d8bcefe7eba4258a34eb4bab83edbfc; Thu, 05 Jun 2025 15:17: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: 2b7ac91d-4220-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1749136637; x=1749406637;
	bh=Y0zoEZ+oUKLBb3F2PrV9vMIfEPCCp4im/a1FbEJ+45U=;
	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=y9NLakJAOUC9A4xC1JcHfDsWNdYkcqSzpD7MnPGSINveQhxUm3FLuS5OE4nbAnRQV
	 LY7z6U0TXbX2SgDU7fQ31AMnDPCWQPUFNFagaaxzh0WnzuyQXCBb1UKjDuPr2TgMYN
	 IhyzeyphXveLLGj0gWbIZOIovPf65HoCTRaQUDmnyu5WrqzGUYoZno5IWR9zSC+eoL
	 QREGhbfLBI/Y9HSH34MhrgEbW39tmydCFMTk1iLXO9G0qUwmajvsl7+aerz6EdlSQ6
	 qW5TfPYl+E6ZWTqQcfbv/sMWI7iR4k/n8G8/2revoUH0yu5VcPHJ0sq7w5q666YbXG
	 TsezpaV8bViTA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1749136637; x=1749397137; i=teddy.astie@vates.tech;
	bh=Y0zoEZ+oUKLBb3F2PrV9vMIfEPCCp4im/a1FbEJ+45U=;
	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=wAuftiU3qQN3z1kpjAe3VYIWc91O+Ykm7CNvT66NDR+Zv6x1UaE8ue25BCgn1vIgy
	 vRVIHhRK4Ks2+Fs9gewQxrIG2sROGGlk9Z1SSXARU5xYPvmb9JpjKZAyyuOKPYs/lQ
	 avQjf0hb9aEhB2Q0N/BlaiRZAMzRyjNtZgwnU2Z0oM1siOhwwObEz0Vcvf8D5izy+e
	 1Lpsf28s2EoJ/ytKRbTeGYrAtgpxCWUn0IQFH2K2ftx3rA3L5DYiBx/GL7qBjwAPzr
	 MAOMyiHdOG+4Gu7c8gcgH/Cc1iv8wFkIA3ayu9H9IUOh6AJMvXkaQJerfzn9zkqpYo
	 ZvaWeag9HfBNw==
From: "Teddy Astie" 
Subject: =?utf-8?Q?Re:=20[PATCH]=20vmx:=20Introduce=20vcpu=20single=20context=20VPID=20invalidation?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1749136636299
Message-Id: <76bf2d72-3834-4455-8023-a20c84db58d0@vates.tech>
To: "Jan Beulich" 
Cc: "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , xen-devel@lists.xenproject.org
References: <83d0e7dfc076e9453fb6537e5948c03d90e947da.1748594036.git.teddy.astie@vates.tech> <4ed9d6ce-5634-4dd9-86e9-5d1f84a43e10@suse.com>
In-Reply-To: <4ed9d6ce-5634-4dd9-86e9-5d1f84a43e10@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.4d8bcefe7eba4258a34eb4bab83edbfc?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250605:md
Date: Thu, 05 Jun 2025 15:17:17 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Le 05/06/2025 =C3=A0 16:51, Jan Beulich a =C3=A9crit=C2=A0:
> On 30.05.2025 10:48, Teddy Astie wrote:
>> Introduce vpid_sync_vcpu_context to do a single-context invalidation
>> on the vpid attached to the vcpu as a alternative to per-gva and all-con=
texts
>> invlidations.
>>
>> Signed-off-by: Teddy Astie 
>> ---
>> Extracted from SEV series.
>> This will be used for instance in fixed-ASID patches (in SEV series).
> 
> I think it should be in that series, which may still be some long way out=
.
> Until then we'd carry dead/unreachable code (disliked by Misra), and we'd
> risk that this bit-rots because of being unused.
> 

Yes, that make sense, it should exist along with patches that make use 
of it.

>> --- a/xen/arch/x86/include/asm/
hvm/vmx/vmx.h
>> +++ b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
>> @@ -451,6 +451,23 @@ static inline void ept_sync_all(void)
>>   
>>   void ept_sync_domain(struct p2m_domain *p2m);
>>   
>> +static inline void vpid_sync_vcpu_context(struct vcpu *v)
> 
> pointer-to-const?
> 
>> +{
>> +    int type =3D INVVPID_SINGLE_CONTEXT;
> 
> Please don't use plain int when all values possibly held in a variable ar=
e
> non-negative.
> 

I mostly took the code from other vcpu_sync_* functions. I will take a 
look as a separate patch on reworking the existing vpid_sync_vcpu_gva 
with these proposed changes, as it has the same problem.

>> +    /*
>> +     * If single context invalidation is not supported, we escalate to
>> +     * use all context invalidation.
>> +     */
>> +    if ( likely(cpu_has_vmx_vpid_invvpid_single_context) )
>> +        goto execute_invvpid;
>> +
>> +    type =3D INVVPID_ALL_CONTEXT;
>> +
>> +execute_invvpid:
> 
> There no reason at all to use "goto" here (and with that replaced there's
> then also no style issue with the label placement).
> 

Should a similar treatment be made for vpid_sync_vcpu_gva ?

> Jan
> 
>> +    __invvpid(type, v->arch.hvm.n1asid.asid, 0);
>> +}
>> +
>>   static inline void vpid_sync_vcpu_gva(struct vcpu *v, unsigned long gv=
a)
>>   {
>>       int type =3D INVVPID_INDIVIDUAL_ADDR;
> 
> 

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 Jun 05 15:19:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 15:19:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007037.1386312 (Exim 4.92)
	(envelope-from )
	id 1uNCNe-0007tF-I7; Thu, 05 Jun 2025 15:19:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007037.1386312; Thu, 05 Jun 2025 15:19:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNCNe-0007t8-Fc; Thu, 05 Jun 2025 15:19:46 +0000
Received: by outflank-mailman (input) for mailman id 1007037;
 Thu, 05 Jun 2025 15:19: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 1uNCNd-0007t2-GB
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 15:19:45 +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 8298e3eb-4220-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 17:19:44 +0200 (CEST)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-43cfe63c592so12809055e9.2
 for ; Thu, 05 Jun 2025 08:19:44 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-451f97f797bsm29144615e9.1.2025.06.05.08.19.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 08:19:43 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8298e3eb-4220-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749136784; x=1749741584; 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=ZsVi9mFdE9OELkvO8XwzTUIVclaZPprJgsLHYTAHtCo=;
        b=NIcYfn0Cjqu6hyeitzs1pWasbtB+wYF7NO27CCZLl0M2Qrzk6PfeVksrUQx4i1+P7j
         xcUEStZWIW70ClPFl5KbQp/YZ7r9dCCzp1WptGdWR4sOO/UtnNbWHgllhb0dbeM93RTF
         sJk61XOgfb3NC9vFsOnf1lIyR7bcPs5rirMik=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749136784; x=1749741584;
        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=ZsVi9mFdE9OELkvO8XwzTUIVclaZPprJgsLHYTAHtCo=;
        b=cat0p7d7XviWX1LpdbBSZg30DdGzee3Rj6kfJvxP2x7TU7F/o6Mqj9uL4w0BLZz8AA
         /KyWxcimhyJiF9BZiuIOOiL6D1sINl3YO4G/5furxzR1n4V0h/HylHMxS//lw7tS/khh
         Mte9AS/FwGV5td7DR9DA/XdJKdxXwTCbWsIq1l/vjamlChHP732ejkFNdJpzTE9tvRHh
         ocyTXhwQqEDkBuIBRDL9ZK5CMuyS3PJrVunnL8rJYLqoLU4LMDTRkfELLvPZ3RtIIbkl
         tz8Teu+cIjpfBl1tOwE8k+2pkQK9cB//CuxZiysW0UilWm0n50cRxEkoKb805vdca8kU
         W0Sg==
X-Gm-Message-State: AOJu0Yw5cTAu6tZHpOXQJu/CN+3yRDEz6NuSNF+qToito+nQXJeqaoe5
	UxF5CyrzcEra3IGq8DC/8FHJfXslH651WASoicA5EN++8f7cJf+AFOwqjrPH0P8j7Kg=
X-Gm-Gg: ASbGnctT2/X1ae0AtO29P0/CF2O1Mj2NwqQ59h0p+y3cW4RgJcs6ybfpnXSdgdMD07s
	bhxfUwgmObjv6SmvjGm6ZzU3OW4xK2h55q8F1WZzfsA3W5NBiTngjbJOaEmFN61mHa3s6rpbNDT
	Im4/T3ZhJDHrUGJBGpiUUtG2zkAsOWNOu3GTFSpkhDxVJkaPuLRCZ3plJh3WvnjH1OYyyZf1Au1
	vPKwd+yeHM1YYWMVnl/5V+lgBcwv+dXyWzf8xcXKGsc6oimk4QT4szzYURcvp7Qfried6uCLvif
	d6lSTRd9gPlbFKdnmmAjU43SwRxEk2CkjoCRdbdub0ZGluniZmC5Lm2qXGPZXi7puQoivZa6KH6
	vp1NZWYx2/Q9rCgI1diNC9Abhaqi0BA==
X-Google-Smtp-Source: AGHT+IEkbeKljRtN+ExWUey35MAcaufZT76wMhPkdP1lxGimX8xCjmOBuX+YWDBe+mhWjN7cXhhKaw==
X-Received: by 2002:a05:600c:1c94:b0:450:30e4:bdf6 with SMTP id 5b1f17b1804b1-451f0b0cfc6mr65476455e9.19.1749136783911;
        Thu, 05 Jun 2025 08:19:43 -0700 (PDT)
Date: Thu, 5 Jun 2025 17:19:42 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jiqian Chen 
Cc: xen-devel@lists.xenproject.org, Huang Rui 
Subject: Re: [PATCH v5 09/10] vpci/msi: Free MSI resources when init_msi()
 fails
Message-ID: 
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
 <20250526094559.140423-10-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250526094559.140423-10-Jiqian.Chen@amd.com>

On Mon, May 26, 2025 at 05:45:58PM +0800, Jiqian Chen wrote:
> When init_msi() fails, current logic return fail and free MSI-related
> resources in vpci_deassign_device(). But the previous new changes will
> hide MSI capability and return success, it can't reach
> vpci_deassign_device() to remove resources if hiding success, so those
> resources must be removed in cleanup function of MSI.
> 
> To do that, implement cleanup function for MSI.
> 
> Signed-off-by: Jiqian Chen 
> ---
> cc: "Roger Pau Monné" 
> ---
> v4->v5 changes:
> * Change definition "static void cleanup_msi" to "static int cf_check cleanup_msi" since cleanup hook is changed to be int.
> * Add a read-only register for MSI Control Register in the end of cleanup_msi.
> 
> v3->v4 changes:
> * Change function name from fini_msi() to cleanup_msi().
> * Remove unnecessary comment.
> * Change to use XFREE to free vpci->msi.
> 
> v2->v3 changes:
> * Remove all fail path, and use fini_msi() hook instead.
> * Change the method to calculating the size of msi registers.
> 
> v1->v2 changes:
> * Added a new function fini_msi to free all MSI resources instead of using an array to record registered registers.
> 
> Best regards,
> Jiqian Chen.
> ---
>  xen/drivers/vpci/msi.c | 29 ++++++++++++++++++++++++++++-
>  1 file changed, 28 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/drivers/vpci/msi.c b/xen/drivers/vpci/msi.c
> index 2d45c7867de7..4e106c39efae 100644
> --- a/xen/drivers/vpci/msi.c
> +++ b/xen/drivers/vpci/msi.c
> @@ -193,6 +193,33 @@ static void cf_check mask_write(
>      msi->mask = val;
>  }
>  
> +static int cf_check cleanup_msi(struct pci_dev *pdev)
> +{
> +    int rc;
> +    unsigned int end, size;
> +    struct vpci *vpci = pdev->vpci;
> +    const unsigned int msi_pos = pdev->msi_pos;
> +    const unsigned int ctrl = msi_control_reg(msi_pos);
> +
> +    if ( !msi_pos || !vpci->msi )

Possibly same request as the previous patch, msi_pos should be after
the PCI standard header.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 15:25:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 15:25:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007048.1386323 (Exim 4.92)
	(envelope-from )
	id 1uNCT7-0001Rd-92; Thu, 05 Jun 2025 15:25:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007048.1386323; Thu, 05 Jun 2025 15:25:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNCT7-0001RW-5r; Thu, 05 Jun 2025 15:25:25 +0000
Received: by outflank-mailman (input) for mailman id 1007048;
 Thu, 05 Jun 2025 15:25: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 1uNCT5-0001RO-D5
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 15:25:23 +0000
Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com
 [2607:f8b0:4864:20::f32])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 490402dd-4221-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 17:25:18 +0200 (CEST)
Received: by mail-qv1-xf32.google.com with SMTP id
 6a1803df08f44-6f8a87f0c0fso12331916d6.0
 for ; Thu, 05 Jun 2025 08:25:18 -0700 (PDT)
Received: from [10.138.10.6] ([89.187.178.201])
 by smtp.gmail.com with ESMTPSA id
 6a1803df08f44-6fac6d33ab1sm122539926d6.2.2025.06.05.08.25.15
 for 
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 08:25:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 490402dd-4221-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749137117; x=1749741917; 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=ui/+B3zpx9mOf+OpZOvIJ2WoH0H2F3e7Z1ZOs4wbbPU=;
        b=XaGOBXGhYkV+OT0XjqDwHOocjfm42wP08c8rGp+iLdfEB4t/I1+WJzffX/624sElPk
         tXH6Idn/zSX3Rrif1/oNLXzM839cjG6kMhntW9DZmpZ2wA1dWpOmRAXcwtzCz/niEfw1
         jUo80m6b97ZsKJJrqt/KE6h4I6K0k+gv9jXE6xaQr4o1m9u2595X/rAVXf/9EJiCudNz
         qjuZUILKki0xhpB6qUYa3n0ncdhwMteaERx/TzNU3pdMab9fbErtA5QDanqlyRVKeSEd
         0+eclcCQAgMvnZLmDrRyBglDzh9I3sk4UfqxUEs0pKYfGB560/tzt6vsIqZ73vrkeNYG
         iT7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749137117; x=1749741917;
        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=ui/+B3zpx9mOf+OpZOvIJ2WoH0H2F3e7Z1ZOs4wbbPU=;
        b=YR1u2/1utY0U5AymPoGWrV2cqN9Dv1Kqu4OOCZsI0T+Ut1eceHqJpvXpV1iy6+kcyi
         fgueV0HxsIcOWWWH9t2UVEBxpU5XMx7fC42mklifbzv5wpvV5EXBaClnyEO2yIjdWXtb
         gn5Uhou36QWHgInUolT06FVtxAwJUbwX+g5eXyyhhZGyRc7X9TF+5Loeu6juLjNrL3lQ
         4rdKdK/EF6bmzSodWJUaf9vDLfL5IWIfcj1NBNl671b8RAvKg+9HvNu8l/ptF9y/N+mF
         gQ9jArBh1rtxIaNYBkxXzIdIvlIj5qMTIrhqygSHb3w59CD3sJkVEhv9FJYphfhJwaFS
         RilA==
X-Gm-Message-State: AOJu0YykJQV7sqxl4yFq2GXnHjvMKCpWZ2uYvXZOfhIdKzJMzi/CcXrY
	c6zqKCItB9Nk6CB2Kf2HR7Yu2u2ACta49Ocba2Gxi35K2SSMEdfqr1QF0GI9fA==
X-Gm-Gg: ASbGnctR/50UjthCgZe+uvA6CIFx0rbAv2CaLlRBD97/GXDj6j/1LT8E7BkpufW1q2u
	u303nEWBWlF3reZzorv2EYsU5uRLZXwk0AUJJe/YmULcIaL6/tAEiBVB7+9SdQJFWzhlAq78aLj
	YSnuEo58dDWsz5pnHCjybM4nHDpQrCN9AloNNFz8VI1Jbj48kzU4QOdjjAyR8Ruev4uduczVIyP
	rsj4Q2dPl5tTw1ZigzZfV+CCjwU3zqjRuASP7A0tXRB+Y8EbnQoKUgwCFuvij2dRbARMB5u6yvi
	c+u60IO7vMB7q6Rhvw4zgAoYi3ce0jcdhrNnpiQ3jIJMjOdBgAhxqSw8
X-Google-Smtp-Source: AGHT+IE+RMdvpzJa/vQdwBcen/U0VVh4n3BmzcRo6R5cjEyVPb6jj65Bs8yWOrrfAPnKSv9iooMDcA==
X-Received: by 2002:a05:620a:28d0:b0:7c5:ee84:a575 with SMTP id af79cd13be357-7d2198d22damr1028273885a.46.1749137116733;
        Thu, 05 Jun 2025 08:25:16 -0700 (PDT)
Message-ID: <8881e471-23be-43d6-aa83-c465a4d02778@gmail.com>
Date: Thu, 5 Jun 2025 11:25:01 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86: remove memcmp calls non-compliant with Rule 21.16.
To: xen-devel@lists.xenproject.org
References: <20250604233537.2892206-1-stefano.stabellini@amd.com>
 
Content-Language: en-US
From: Demi Marie Obenour 
Autocrypt: addr=demiobenour@gmail.com; keydata=
 xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49yB+l2nipd
 aq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYfbWpr/si88QKgyGSV
 Z7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/UorR+FaSuVwT7rqzGrTlscnT
 DlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7MMPCJwI8JpPlBedRpe9tfVyfu3euTPLPx
 wcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9Hzx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR
 6h3nBc3eyuZ+q62HS1pJ5EvUT1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl
 5FMWo8TCniHynNXsBtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2
 Bkg1b//r6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nSm9BBff0N
 m0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQABzTxEZW1pIE1hcmll
 IE9iZW5vdXIgKGxvdmVyIG9mIGNvZGluZykgPGRlbWlvYmVub3VyQGdtYWlsLmNvbT7CwXgE
 EwECACIFAlp+A0oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELKItV//nCLBhr8Q
 AK/xrb4wyi71xII2hkFBpT59ObLN+32FQT7R3lbZRjVFjc6yMUjOb1H/hJVxx+yo5gsSj5LS
 9AwggioUSrcUKldfA/PKKai2mzTlUDxTcF3vKx6iMXKA6AqwAw4B57ZEJoMM6egm57TV19kz
 PMc879NV2nc6+elaKl+/kbVeD3qvBuEwsTe2Do3HAAdrfUG/j9erwIk6gha/Hp9yZlCnPTX+
 VK+xifQqt8RtMqS5R/S8z0msJMI/ajNU03kFjOpqrYziv6OZLJ5cuKb3bZU5aoaRQRDzkFIR
 6aqtFLTohTo20QywXwRa39uFaOT/0YMpNyel0kdOszFOykTEGI2u+kja35g9TkH90kkBTG+a
 EWttIht0Hy6YFmwjcAxisSakBuHnHuMSOiyRQLu43ej2+mDWgItLZ48Mu0C3IG1seeQDjEYP
 tqvyZ6bGkf2Vj+L6wLoLLIhRZxQOedqArIk/Sb2SzQYuxN44IDRt+3ZcDqsPppoKcxSyd1Ny
 2tpvjYJXlfKmOYLhTWs8nwlAlSHX/c/jz/ywwf7eSvGknToo1Y0VpRtoxMaKW1nvH0OeCSVJ
 itfRP7YbiRVc2aNqWPCSgtqHAuVraBRbAFLKh9d2rKFB3BmynTUpc1BQLJP8+D5oNyb8Ts4x
 Xd3iV/uD8JLGJfYZIR7oGWFLP4uZ3tkneDfYzsFNBFp+A0oBEAC9ynZI9LU+uJkMeEJeJyQ/
 8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd8xD57ue0eB47bcJv
 VqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPpI4gfUbVEIEQuqdqQyO4GAe+M
 kD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalql1/iSyv1WYeC1OAs+2BLOAT2NEggSiVO
 txEfgewsQtCWi8H1SoirakIfo45Hz0tk/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJ
 riwoaRIS8N2C8/nEM53jb1sH0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcN
 fRAIUrNlatj9TxwivQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6
 dCxN0GNAORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
 rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog2LNtcyCj
 kTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZAgrrnNz0iZG2DVx46
 x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJELKItV//nCLBwNIP/AiIHE8b
 oIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwjjVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGj
 gn0TPtsGzelyQHipaUzEyrsceUGWYoKXYyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8fr
 RHnJdBcjf112PzQSdKC6kqU0Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2
 E0rW4tBtDAn2HkT9uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHM
 OBvy3EhzfAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
 Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVssZ/rYZ9+5
 1yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aWemLLszcYz/u3XnbO
 vUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPthZlDnTnOT+C+OTsh8+m5tos8
 HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E
 +MYSfkEjBz0E8CLOcAw7JIwAaeBT
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------0YzQPgdSiWkWZBEOaJX9WjRI"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------0YzQPgdSiWkWZBEOaJX9WjRI
Content-Type: multipart/mixed; boundary="------------qFTKXwNIVhZ0TNJIYhq4x8st";
 protected-headers="v1"
From: Demi Marie Obenour 
To: xen-devel@lists.xenproject.org
Message-ID: <8881e471-23be-43d6-aa83-c465a4d02778@gmail.com>
Subject: Re: [PATCH] x86: remove memcmp calls non-compliant with Rule 21.16.
References: <20250604233537.2892206-1-stefano.stabellini@amd.com>
 
In-Reply-To: 

--------------qFTKXwNIVhZ0TNJIYhq4x8st
Content-Type: multipart/mixed; boundary="------------jGFdWrHJgoQhHAGGvY48i6Ss"

--------------jGFdWrHJgoQhHAGGvY48i6Ss
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 6/5/25 02:31, Jan Beulich wrote:
> On 05.06.2025 01:35, Stefano Stabellini wrote:
>> From: Alessandro Zucchelli 
>>
>> MISRA C Rule 21.16 states the following: "The pointer arguments to
>> the Standard Library function `memcmp' shall point to either a pointer=

>> type, an essentially signed type, an essentially unsigned type, an
>> essentially Boolean type or an essentially enum type".
>>
>> Comparing string literals with char arrays is more appropriately
>> done via strncmp.
>=20
> More appropriately - maybe. Yet less efficiently. IOW I view ...
>=20
>> No functional change.
>=20
> ... this as at the edge of not being true.
>=20
>> Signed-off-by: Alessandro Zucchelli =

>=20
> Missing your own S-o-b.
>=20
> Also (nit) may I ask that you drop the full stop from the patch subject=
?
>=20
>> --- a/xen/arch/x86/dmi_scan.c
>> +++ b/xen/arch/x86/dmi_scan.c
>> @@ -233,7 +233,7 @@ void __init dmi_efi_get_table(const void *smbios, =
const void *smbios3)
>>  	const struct smbios_eps *eps =3D smbios;
>>  	const struct smbios3_eps *eps3 =3D smbios3;
>> =20
>> -	if (eps3 && memcmp(eps3->anchor, "_SM3_", 5) =3D=3D 0 &&
>> +	if (eps3 && strncmp(eps3->anchor, "_SM3_", 5) =3D=3D 0 &&
>=20
> Unlike the last example given in the doc, this does not pose the risk o=
f
> false "not equal" returns. Considering there's no example there exactly=

> matching this situation, I'm not convinced a change is actually needed.=

> (Applies to all other changes here, too.)
>=20
>> @@ -302,7 +302,7 @@ const char *__init dmi_get_table(paddr_t *base, u3=
2 *len)
>>  				continue;
>>  			memcpy_fromio(&eps.dmi + 1, q + sizeof(eps.dmi),
>>  			              sizeof(eps.smbios3) - sizeof(eps.dmi));
>> -			if (!memcmp(eps.smbios3.anchor, "_SM3_", 5) &&
>> +			if (strncmp(eps.smbios3.anchor, "_SM3_", 5) =3D=3D 0 &&
>=20
> Here and below there's a further (style) change, moving from ! to "=3D=3D=
 0"
> (or from implicit boolean to "!=3D 0"). As we use the original style in=
 many
> other places, some justification for this extra change would be needed =
in
> the description (or these extra adjustments be dropped).
>=20
>> @@ -720,10 +720,10 @@ static void __init efi_check_config(void)
>>  	__set_fixmap(FIX_EFI_MPF, PFN_DOWN(efi.mps), __PAGE_HYPERVISOR);
>>  	mpf =3D fix_to_virt(FIX_EFI_MPF) + ((long)efi.mps & (PAGE_SIZE-1));
>> =20
>> -	if (memcmp(mpf->mpf_signature, "_MP_", 4) =3D=3D 0 &&
>> -	    mpf->mpf_length =3D=3D 1 &&
>> -	    mpf_checksum((void *)mpf, 16) &&
>> -	    (mpf->mpf_specification =3D=3D 1 || mpf->mpf_specification =3D=3D=
 4)) {
>> +	if (strncmp(mpf->mpf_signature, "_MP_", 4) =3D=3D 0 &&
>> +            mpf->mpf_length =3D=3D 1 &&
>> +            mpf_checksum((void *)mpf, 16) &&
>> +            (mpf->mpf_specification =3D=3D 1 || mpf->mpf_specificatio=
n =3D=3D 4)) {
>>  		smp_found_config =3D true;
>>  		printk(KERN_INFO "SMP MP-table at %08lx\n", efi.mps);
>>  		mpf_found =3D mpf;
>=20
> There are extra (indentation) changes here which ought to be dropped.

What about using an array of const uint8_t[] instead of a string literal?=

--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
--------------jGFdWrHJgoQhHAGGvY48i6Ss
Content-Type: application/pgp-keys; name="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

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

xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49y
B+l2nipdaq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYf
bWpr/si88QKgyGSVZ7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/
UorR+FaSuVwT7rqzGrTlscnTDlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7M
MPCJwI8JpPlBedRpe9tfVyfu3euTPLPxwcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9H
zx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR6h3nBc3eyuZ+q62HS1pJ5EvU
T1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl5FMWo8TCniHynNXs
BtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2Bkg1b//r
6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nS
m9BBff0Nm0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQAB
zTxEZW1pIE9iZW5vdXIgKElUTCBFbWFpbCBLZXkpIDxhdGhlbmFAaW52aXNpYmxl
dGhpbmdzbGFiLmNvbT7CwY4EEwEIADgWIQR2h02fEza6IlkHHHGyiLVf/5wiwQUC
X6YJvQIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRCyiLVf/5wiwWRhD/0Y
R+YYC5Kduv/2LBgQJIygMsFiRHbR4+tWXuTFqgrxxFSlMktZ6gQrQCWe38WnOXkB
oY6n/5lSJdfnuGd2UagZ/9dkaGMUkqt+5WshLFly4BnP7pSsWReKgMP7etRTwn3S
zk1OwFx2lzY1EnnconPLfPBc6rWG2moA6l0WX+3WNR1B1ndqpl2hPSjT2jUCBWDV
rGOUSX7r5f1WgtBeNYnEXPBCUUM51pFGESmfHIXQrqFDA7nBNiIVFDJTmQzuEqIy
Jl67pKNgooij5mKzRhFKHfjLRAH4mmWZlB9UjDStAfFBAoDFHwd1HL5VQCNQdqEc
/9lZDApqWuCPadZN+pGouqLysesIYsNxUhJ7dtWOWHl0vs7/3qkWmWun/2uOJMQh
ra2u8nA9g91FbOobWqjrDd6x3ZJoGQf4zLqjmn/P514gb697788e573WN/MpQ5XI
Fl7aM2d6/GJiq6LC9T2gSUW4rbPBiqOCeiUx7Kd/sVm41p9TOA7fEG4bYddCfDsN
xaQJH6VRK3NOuBUGeL+iQEVF5Xs6Yp+U+jwvv2M5Lel3EqAYo5xXTx4ls0xaxDCu
fudcAh8CMMqx3fguSb7Mi31WlnZpk0fDuWQVNKyDP7lYpwc4nCCGNKCj622ZSocH
AcQmX28L8pJdLYacv9pU3jPy4fHcQYvmTavTqowGnM08RGVtaSBNYXJpZSBPYmVu
b3VyIChsb3ZlciBvZiBjb2RpbmcpIDxkZW1pb2Jlbm91ckBnbWFpbC5jb20+wsF4
BBMBAgAiBQJafgNKAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCyiLVf
/5wiwYa/EACv8a2+MMou9cSCNoZBQaU+fTmyzft9hUE+0d5W2UY1RY3OsjFIzm9R
/4SVccfsqOYLEo+S0vQMIIIqFEq3FCpXXwPzyimotps05VA8U3Bd7yseojFygOgK
sAMOAee2RCaDDOnoJue01dfZMzzHPO/TVdp3OvnpWipfv5G1Xg96rwbhMLE3tg6N
xwAHa31Bv4/Xq8CJOoIWvx6fcmZQpz01/lSvsYn0KrfEbTKkuUf0vM9JrCTCP2oz
VNN5BYzqaq2M4r+jmSyeXLim922VOWqGkUEQ85BSEemqrRS06IU6NtEMsF8EWt/b
hWjk/9GDKTcnpdJHTrMxTspExBiNrvpI2t+YPU5B/dJJAUxvmhFrbSIbdB8umBZs
I3AMYrEmpAbh5x7jEjoskUC7uN3o9vpg1oCLS2ePDLtAtyBtbHnkA4xGD7ar8mem
xpH9lY/i+sC6CyyIUWcUDnnagKyJP0m9ks0GLsTeOCA0bft2XA6rD6aaCnMUsndT
ctrab42CV5XypjmC4U1rPJ8JQJUh1/3P48/8sMH+3krxpJ06KNWNFaUbaMTGiltZ
7x9DngklSYrX0T+2G4kVXNmjaljwkoLahwLla2gUWwBSyofXdqyhQdwZsp01KXNQ
UCyT/Pg+aDcm/E7OMV3d4lf7g/CSxiX2GSEe6BlhSz+Lmd7ZJ3g32M1ARGVtaSBN
YXJpZSBPYmVub3VyIChJVEwgRW1haWwgS2V5KSA8ZGVtaUBpbnZpc2libGV0aGlu
Z3NsYWIuY29tPsLBjgQTAQgAOBYhBHaHTZ8TNroiWQcccbKItV//nCLBBQJgOEV+
AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJELKItV//nCLBKwoP/1WSnFdv
SAD0g7fD0WlF+oi7ISFT7oqJnchFLOwVHK4Jg0e4hGn1ekWsF3Ha5tFLh4V/7UUu
obYJpTfBAA2CckspYBqLtKGjFxcaqjjpO1I2W/jeNELVtSYuCOZICjdNGw2Hl9yH
KRZiBkqc9u8lQcHDZKq4LIpVJj6ZQV/nxttDX90ax2No1nLLQXFbr5wb465LAPpU
lXwunYDij7xJGye+VUASQh9datye6orZYuJvNo8Tr3mAQxxkfR46LzWgxFCPEAZJ
5P56Nc0IMHdJZj0Uc9+1jxERhOGppp5jlLgYGK7faGB/jTV6LaRQ4Ad+xiqokDWp
mUOZsmA+bMbtPfYjDZBz5mlyHcIRKIFpE1l3Y8F7PhJuzzMUKkJi90CYakCV4x/a
Zs4pzk5E96c2VQx01RIEJ7fzHF7lwFdtfTS4YsLtAbQFsKayqwkGcVv2B1AHeqdo
TMX+cgDvjd1ZganGlWA8Sv9RkNSMchn1hMuTwERTyFTr2dKPnQdA1F480+jUap41
ClXgn227WkCIMrNhQGNyJsnwyzi5wS8rBVRQ3BOTMyvGM07j3axUOYaejEpg7wKi
wTPZGLGH1sz5GljD/916v5+v2xLbOo5606j9dWf5/tAhbPuqrQgWv41wuKDi+dDD
EKkODF7DHes8No+QcHTDyETMn1RYm7t0RKR4zsFNBFp+A0oBEAC9ynZI9LU+uJkM
eEJeJyQ/8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd
8xD57ue0eB47bcJvVqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPp
I4gfUbVEIEQuqdqQyO4GAe+MkD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalq
l1/iSyv1WYeC1OAs+2BLOAT2NEggSiVOtxEfgewsQtCWi8H1SoirakIfo45Hz0tk
/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJriwoaRIS8N2C8/nEM53jb1sH
0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcNfRAIUrNlatj9Txwi
vQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6dCxN0GNA
ORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog
2LNtcyCjkTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZA
grrnNz0iZG2DVx46x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJ
ELKItV//nCLBwNIP/AiIHE8boIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwj
jVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGjgn0TPtsGzelyQHipaUzEyrsceUGWYoKX
YyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8frRHnJdBcjf112PzQSdKC6kqU0
Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2E0rW4tBtDAn2HkT9
uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHMOBvy3Ehz
fAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVss
Z/rYZ9+51yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aW
emLLszcYz/u3XnbOvUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPt
hZlDnTnOT+C+OTsh8+m5tos8HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj
6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E+MYSfkEjBz0E8CLOcAw7JIwAaeBTzsFN
BGbyLVgBEACqClxh50hmBepTSVlan6EBq3OAoxhrAhWZYEwN78k+ENhK68KhqC5R
IsHzlL7QHW1gmfVBQZ63GnWiraM6wOJqFTL4ZWvRslga9u28FJ5XyK860mZLgYhK
9BzoUk4s+dat9jVUbq6LpQ1Ot5I9vrdzo2p1jtQ8h9WCIiFxSYy8s8pZ3hHh5T64
GIj1m/kY7lG3VIdUgoNiREGf/iOMjUFjwwE9ZoJ26j9p7p1U+TkKeF6wgswEB1T3
J8KCAtvmRtqJDq558IU5jhg5fgN+xHB8cgvUWulgK9FIF9oFxcuxtaf/juhHWKMO
RtL0bHfNdXoBdpUDZE+mLBUAxF6KSsRrvx6AQyJs7VjgXJDtQVWvH0PUmTrEswgb
49nNU+dLLZQAZagxqnZ9Dp5l6GqaGZCHERJcLmdY/EmMzSf5YazJ6c0vO8rdW27M
kn73qcWAplQn5mOXaqbfzWkAUPyUXppuRHfrjxTDz3GyJJVOeMmMrTxH4uCaGpOX
Z8tN6829J1roGw4oKDRUQsaBAeEDqizXMPRc+6U9vI5FXzbAsb+8lKW65G7JWHym
YPOGUt2hK4DdTA1PmVo0DxH00eWWeKxqvmGyX+Dhcg+5e191rPsMRGsDlH6KihI6
+3JIuc0y6ngdjcp6aalbuvPIGFrCRx3tnRtNc7He6cBWQoH9RPwluwARAQABwsOs
BBgBCgAgFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmbyLVgCGwICQAkQsoi1X/+c
IsHBdCAEGQEKAB0WIQSilC2pUlbVp66j3+yzNoc6synyUwUCZvItWAAKCRCzNoc6
synyU85gD/0T1QDtPhovkGwoqv4jUbEMMvpeYQf+oWgm/TjWPeLwdjl7AtY0G9Ml
ZoyGniYkoHi37Gnn/ShLT3B5vtyI58ap2+SSa8SnGftdAKRLiWFWCiAEklm9FRk8
N3hwxhmSFF1KR/AIDS4g+HIsZn7YEMubBSgLlZZ9zHl4O4vwuXlREBEW97iL/FSt
VownU2V39t7PtFvGZNk+DJH7eLO3jmNRYB0PL4JOyyda3NH/J92iwrFmjFWWmmWb
/Xz8l9DIs+Z59pRCVTTwbBEZhcUc7rVMCcIYL+q1WxBG2e6lMn15OQJ5WfiE6E0I
sGirAEDnXWx92JNGx5l+mMpdpsWhBZ5iGTtttZesibNkQfd48/eCgFi4cxJUC4PT
UQwfD9AMgzwSTGJrkI5XGy+XqxwOjL8UA0iIrtTpMh49zw46uV6kwFQCgkf32jZM
OLwLTNSzclbnA7GRd8tKwezQ/XqeK3dal2n+cOr+o+Eka7yGmGWNUqFbIe8cjj9T
JeF3mgOCmZOwMI+wIcQYRSf+e5VTMO6TNWH5BI3vqeHSt7HkYuPlHT0pGum88d4a
pWqhulH4rUhEMtirX1hYx8Q4HlUOQqLtxzmwOYWkhl1C+yPObAvUDNiHCLf9w28n
uihgEkzHt9J4VKYulyJM9fe3ENcyU6rpXD7iANQqcr87ogKXFxknZ97uEACvSucc
RbnnAgRqZ7GDzgoBerJ2zrmhLkeREZ08iz1zze1JgyW3HEwdr2UbyAuqvSADCSUU
GN0vtQHsPzWl8onRc7lOPqPDF8OO+UfN9NAfA4wl3QyChD1GXl9rwKQOkbvdlYFV
UFx9u86LNi4ssTmU8p9NtHIGpz1SYMVYNoYy9NU7EVqypGMguDCL7gJt6GUmA0sw
p+YCroXiwL2BJ7RwRqTpgQuFL1gShkA17D5jK4mDPEetq1d8kz9rQYvAR/sTKBsR
ImC3xSfn8zpWoNTTB6lnwyP5Ng1bu6esS7+SpYprFTe7ZqGZF6xhvBPf1Ldi9UAm
U2xPN1/eeWxEa2kusidmFKPmN8lcT4miiAvwGxEnY7Oww9CgZlUB+LP4dl5VPjEt
sFeAhrgxLdpVTjPRRwTd9VQF3/XYl83j5wySIQKIPXgT3sG3ngAhDhC8I8GpM36r
8WJJ3x2yVzyJUbBPO0GBhWE2xPNIfhxVoU4cGGhpFqz7dPKSTRDGq++MrFgKKGpI
ZwT3CPTSSKc7ySndEXWkOYArDIdtyxdE1p5/c3aoz4utzUU7NDHQ+vVIwlnZSMiZ
jek2IJP3SZ+COOIHCVxpUaZ4lnzWT4eDqABhMLpIzw6NmGfg+kLBJhouqz81WITr
EtJuZYM5blWncBOJCoWMnBEcTEo/viU3GgcVRw=3D=3D
=3Dx94R
-----END PGP PUBLIC KEY BLOCK-----

--------------jGFdWrHJgoQhHAGGvY48i6Ss--

--------------qFTKXwNIVhZ0TNJIYhq4x8st--

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

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

iQIzBAEBCAAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmhBttcACgkQszaHOrMp
8lOh+Q/+IG5hypnz+5na7GVJrHjT/SIXlm+T0QAaNWlaFfp5DuKnZLMPC7/yr7Zt
MFz9n83AnkYS+W2ByijQE/PF1mutdf20PetcR50sG7biwZQbWi+EWtNSSK5YnUn3
0LkALPN174ow1blKTQAAoNkuWJXZtK6MyaXy9yCKvIVDT4mxvDx0wexHFWavs3k7
5EXlIod0LAPlGHf7pxEGKd/dPMkCRfPJPp37g4jRZbUbtP5jOF2Nvl5zVw8WXXL2
EPD7L/EXN1Lw8DmmpK0AybtYXiNQEk+7eDWu/MGhfe1ckcrYqi1doCw6CQuMAz1E
+8Yfu/LNku8eY8uoyeHUgwYMagv4Jegyo9c6fIRrPlA6h5vxQVWh62P9B1tfrRkE
C56zLcGIOPylL0WHEYR8LyqNwhbl9cvFFgq5ylKNN4olhCHBOzdxYNwwUhLCFCix
T9Qj1mXjRg/6LmExMxNDJTSGgeZFLPL+BVSKqNxwHPWN4T/krl3qqU+/PtB73qim
XhAraWaAoEZs7PzRS4XMoOW1QT2FLHzzNpHRJY7ncDrjRV2gvlOtbxib84pDNInk
mSkb8ovFKR6tuoC+TmAw1qJFTpHVW9g0jj3sLmHNYZ+b1maP5e2rsVqbLGh7DpZA
gnmdDe1hFMujv6s0B+4AEj4lhVy9Bl25jkg+5vBYuqV3CF2ITB4=
=j0IQ
-----END PGP SIGNATURE-----

--------------0YzQPgdSiWkWZBEOaJX9WjRI--


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 15:28:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 15:28:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007054.1386332 (Exim 4.92)
	(envelope-from )
	id 1uNCWK-0001xz-MI; Thu, 05 Jun 2025 15:28:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007054.1386332; Thu, 05 Jun 2025 15:28: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 1uNCWK-0001xs-Jl; Thu, 05 Jun 2025 15:28:44 +0000
Received: by outflank-mailman (input) for mailman id 1007054;
 Thu, 05 Jun 2025 15:28: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 1uNCWI-0001xm-Td
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 15:28:42 +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 c28a11df-4221-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 17:28:41 +0200 (CEST)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-ad55d6aeb07so218276266b.0
 for ; Thu, 05 Jun 2025 08:28:41 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ada5d82e80csm1268335166b.71.2025.06.05.08.28.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 08:28:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c28a11df-4221-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749137321; x=1749742121; 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=naWYKSBtQ22zr2K7a/qTHaVSdY1rJpbHlyY2oi2V+A8=;
        b=MyYI8h6kYE+L0ifPJ3HUvMXsXE9Not03mG2LT6vrTIg9nTsaWE2CXdsfEGjwjPn8M9
         Y8Bx0oBcDTrzR3frn3hL4GPuVyMSuUU/akpGd8OxaHdpehpibuYNETk9DW7/TpZtYL0v
         AnQVuTkKOfUOyYaDlpKxelXWSaVVQESIcSoOtPPF6uObeceTOXYB1mfbnP21s/55G9z0
         nwHCaLhvxctlzevSy+c6FOxXQQWeX5zyHWcv46SjPkTx6SRj0rcM4Kwf2kRKk5S54A6e
         fuO/aC7kPWLPXpq/QyDqAG1pUyPpQ6mQ00PAYm0aUenfzNfvS8yVh9tcYDggoJ5G1Ofz
         E6Hg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749137321; x=1749742121;
        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=naWYKSBtQ22zr2K7a/qTHaVSdY1rJpbHlyY2oi2V+A8=;
        b=WYolicQGSkgz9pNUT3fXxxkCP1HEmUj1b7VxhXPI7qAHazVeCU09J9MBmYGmXBzRUB
         5GeI9DGYkfZNiYOZNuX6/XxO3KUyPtB0qUbKAeesg+6i83MhAEPqHjvs55uZtefzwvRq
         v0n3/S8kRE9x4r6xs/VviUsyRzBU+kykBHL10JPkv44eX+PozjT1g8R2zviQ3Zc3HWIX
         e+/VGybgaaLon969ezr8pj5rcBo+lKWo25hhrwsMPxGNjSxgSTUHywEVvp4DhYgnNr6K
         7Dzar4jDW/Cj9JolNibG+/JOJ/PJ+5+JJP6S4S8rF1Jhv5R+QNNe6K8M5Pv5NpJwaP1r
         WJPA==
X-Forwarded-Encrypted: i=1; AJvYcCXmT0excWGyLgelh4tptbibOtTjb9klbFhs/udce3VF3wCtgGc2BITdlh6IvP2kmnPH/qf1Iz401gA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwSKEn7rmglSCYQCsSuBLiQkctcaX9IzxTpeJoIh37eG9GAUjge
	XZhePcHcEt5E4R3mxV0mdnPq7i1dZedpn9iDQ1I4SuhePxJAVnD+D9vL
X-Gm-Gg: ASbGnctmh/dYvhSRb3cESECpdIyUQ3X5HJUpeycsEBgnYnVueLC169/6Nfof3gBst4Q
	W18cHf2hDb47QXls+iAhL4SKhC7n/LtwIf124wA6I/R73D9pDpUn9Sap2EywLhuBxYulH+cqHzD
	xkH/PHshYo9DsyEwyQAiy64I2yUookx4OVXVfJYxvUeFGHbaOIvm74BH+18iX6T7HuSrqxwZA3C
	4QSqX6YItnUwt9i6t+aYL0gJwbDs9eSTH+RfAjmkXzUPFjWiITDh7F1SCEmYrzM+BWPRoihAzlz
	uRZ8l+G3pHhlJZa3VMwjginx8qnATCreUL8ZhW76Y+gFrFDcQnrzdy/MkEYRN+/1BDGBfvgsWQK
	q1np5pkkdb48Y5qnX+RZkuLei
X-Google-Smtp-Source: AGHT+IHt0r1gaqCjFbx7fM7HXI6oTurJr7q0SsI/jolLLMyzWCdITG9hHkt7FdyGVFG1oODgk2W14A==
X-Received: by 2002:a17:907:971d:b0:ad2:2d75:d7fb with SMTP id a640c23a62f3a-addf8fe231amr728388666b.55.1749137320666;
        Thu, 05 Jun 2025 08:28:40 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------SZafocSQkPor6gFtp0QTPQEF"
Message-ID: <3b9cc332-5b39-40dc-afc4-40f790abd0ed@gmail.com>
Date: Thu, 5 Jun 2025 17:28:37 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/6] xen/riscv: introduce things necessary for p2m
 initialization
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: 
 <0a03d1f38649cfd8656147f209652dff0f9d170c.1746805907.git.oleksii.kurochko@gmail.com>
 <7ef3ca26-05f5-4e86-b7c7-852b6c74a3d0@suse.com>
 <1a0d3084-9e77-4df5-936a-c1a1317c0f18@gmail.com>
 
 
 <0175c281-b669-4412-971a-545e29077b34@suse.com>
 
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

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


On 6/5/25 4:19 PM, Jan Beulich wrote:
>>>> Won't be enough to flushing of guest TLB only during context switch?
>>> "only" is interesting here. Context switches are a relatively frequent
>>> operation, which in addition you want to be fast. If a flush is necessary
>>> there for correctness (e.g. when VMIDs aren't in use), you have to do it
>>> there. But if you can flush less frequently without violating correctness,
>>> you'd almost always want to use such an opportunity.
>> Then it is better to introduce VMID now, it seems it's only one place where
>> it should be set, when hgatp is initialized.
>>
>> Does Xen have some framework to work with VMID?
> That's all arch-specific, I think.

Probably, I used incorrect words to express what I want. I wrote about allocation/freeing
of VMIDs. Basically something similar to what Arm has (|p2m_vmid_allocator_init(), ||p2m_alloc_vmid(), ||p2m_free_vmid|):
   https://gitlab.com/xen-project/xen/-/blob/staging/xen/arch/arm/p2m.c?ref_type=heads#L271

It seems like it is not very arch-specific, at the moment.

But, likely, RISC-V will need to do an update|p2m_alloc_vmid(), which will do p2m's TLB flush when overflow of VMIDs 
happen. ~ Oleksii |

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



  
    
  
  
    

    
    
    
    
    On 6/5/25 4:19 PM, Jan Beulich wrote:
    
    
    
    
    
      
    Won't be enough to flushing of guest TLB only during context switch?

    "only" is interesting here. Context switches are a relatively frequent
operation, which in addition you want to be fast. If a flush is necessary
there for correctness (e.g. when VMIDs aren't in use), you have to do it
there. But if you can flush less frequently without violating correctness,
you'd almost always want to use such an opportunity.

    Then it is better to introduce VMID now, it seems it's only one place where
it should be set, when hgatp is initialized.

Does Xen have some framework to work with VMID?

    That's all arch-specific, I think.
    
    
    
    
    Probably, I used incorrect words to express what I want. I wrote about allocation/freeing
of VMIDs. Basically something similar to what Arm has (p2m_vmid_allocator_init(), p2m_alloc_vmid(), p2m_free_vmid):
  https://gitlab.com/xen-project/xen/-/blob/staging/xen/arch/arm/p2m.c?ref_type=heads#L271

It seems like it is not very arch-specific, at the moment.

But, likely, RISC-V will need to do an update p2m_alloc_vmid(), which will do p2m's TLB flush when overflow of
VMIDs happen.

~ Oleksii

    
  


--------------SZafocSQkPor6gFtp0QTPQEF--


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 15:34:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 15:34:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007064.1386342 (Exim 4.92)
	(envelope-from )
	id 1uNCbh-0003lq-9F; Thu, 05 Jun 2025 15:34:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007064.1386342; Thu, 05 Jun 2025 15:34:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNCbh-0003lj-6l; Thu, 05 Jun 2025 15:34:17 +0000
Received: by outflank-mailman (input) for mailman id 1007064;
 Thu, 05 Jun 2025 15:34: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 1uNCbf-0003l7-6l
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 15:34:15 +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 88939383-4222-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 17:34:13 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a4f78ebec8so680608f8f.0
 for ; Thu, 05 Jun 2025 08:34:13 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-451fb18a855sm22796605e9.18.2025.06.05.08.34.12
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 08:34:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 88939383-4222-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749137653; x=1749742453; 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=SsXot+elbz3CRhKpGH4GF+wH47QOk45FPC17mvak5Mo=;
        b=p4wpgcwdQpD1NXt7jdFMK4eyaY4jLbWHqTjFDWN6zJ64MnmJg/K4Vp1SDW9t07etwC
         bplrgw5/bWhUqqqGQSqkX0bmCI01jSM3lG6xMGZky1AXBLn4yCqAjE7MQXStIs8z2hlL
         8WiMUuRDv98Yd6TkAklWAzwGlYHEad5yeoTCg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749137653; x=1749742453;
        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=SsXot+elbz3CRhKpGH4GF+wH47QOk45FPC17mvak5Mo=;
        b=HcTGAHPt9f+pbcpUALnew6J72u9FufqX57gFZOlaNAWBN/YfHjvO5/OrKLsk5fzWVa
         Nwob146J029iS2yAts+xeRuvX1WJ0ZB79OJN9C/lTCfUkEpwgbIJCEzP6igXpWF0Pd/L
         TIcOOACm1SvWRApFhKzYlcvs7cpvxZdvTVfsDBNFlBGOCzTSoOKuoA6EfiSsLfjPcMWh
         OXNKY5DSkq2BegE9B8Mchq1l64q+INIytT7t2xKjIkXksBf5ojVNVGJq3yWxYZccDyqx
         n41Z92wzMiq7nYZVc5ZejVP+7CPF54l2EduhZPHwTWIFjgcHsz1LHnwFOL6QkcbkScT/
         A1UQ==
X-Gm-Message-State: AOJu0YwqA+XEVQGcBgf3Pk4mCUoD0UmyR51i/OD8b4gfEhL7TQUeIZf3
	PVUnFFJnrpq7gzhVVUSgCsk4ez8O8kuvMMmk1D1wBTCUZu3M3wKKQdUKsabq0BxQ3Nc=
X-Gm-Gg: ASbGncsywFJlA3jptLwR/5QL9syisdkTumTG8cUUZLt35O9isK7Lu3tD+C8OY57qPS0
	ZPHHn+vpwETNY6XUQoOiwbvCkuGqc7Mv9dbilH9VP/hEcjJ9UyWDN4gPucWCxOxIE5IsY2Ro0kE
	PRIJzBTJANruZT66duukzs4cAQ5vhjNEGz8dYIkHcBj9Y0NBR7x+m5baJLt9J3LNldaYWS27AIL
	QsTTNfRBIOGjVwhwQnS8NCBwh8E3X85gjSLmcJ33dk6hvXgEWju6QKsRNzmWFA/lkN7iW41x1o5
	D2A7B3H3ebuCkxzXEvbLp7P0MKClO6M5tYgepR2idOesYM3gq5bcavYMMmJ4vJ7MF2XSsVD0hN1
	dEaIYnwEbkIgyOxUXN2btAYAnB3xjqw==
X-Google-Smtp-Source: AGHT+IFbZFdT3E0iSjhbuaJj6tq2MkrhlE3Knr/sDMnCH9CVThq5jQvtCdTJHZ42GJnnG2Y6BDb/eg==
X-Received: by 2002:a05:6000:4313:b0:3a4:ddde:13e4 with SMTP id ffacd0b85a97d-3a51d98c667mr5863094f8f.58.1749137653081;
        Thu, 05 Jun 2025 08:34:13 -0700 (PDT)
Date: Thu, 5 Jun 2025 17:34:11 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jiqian Chen 
Cc: xen-devel@lists.xenproject.org, Huang Rui 
Subject: Re: [PATCH v5 10/10] vpci/msix: Free MSIX resources when init_msix()
 fails
Message-ID: 
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
 <20250526094559.140423-11-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250526094559.140423-11-Jiqian.Chen@amd.com>

On Mon, May 26, 2025 at 05:45:59PM +0800, Jiqian Chen wrote:
> When init_msix() fails, current logic return fail and free MSIX-related
> resources in vpci_deassign_device(). But the previous new changes will
> hide MSIX capability and return success, it can't reach
> vpci_deassign_device() to remove resources if hiding success, so those
> resources must be removed in cleanup function of MSIX.
> 
> To do that, implement cleanup function for MSIX.
> 
> Signed-off-by: Jiqian Chen 



> ---
> cc: "Roger Pau Monné" 
> ---
> v4->v5 changes:
> * Change definition "static void cleanup_msix" to "static int cf_check cleanup_msix" since cleanup hook is changed to be int.
> * Add a read-only register for MSIX Control Register in the end of cleanup_msix().
> 
> v3->v4 changes:
> * Change function name from fini_msix() to cleanup_msix().
> * Change to use XFREE to free vpci->msix.
> * In cleanup function, change the sequence of check and remove action according to init_msix().
> 
> v2->v3 changes:
> * Remove unnecessary clean operations in fini_msix().
> 
> v1->v2 changes:
> new patch.
> 
> Best regards,
> Jiqian Chen.
> ---
>  xen/drivers/vpci/msix.c | 29 ++++++++++++++++++++++++++++-
>  1 file changed, 28 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/drivers/vpci/msix.c b/xen/drivers/vpci/msix.c
> index 674815ead025..cf79320d3b6f 100644
> --- a/xen/drivers/vpci/msix.c
> +++ b/xen/drivers/vpci/msix.c
> @@ -655,6 +655,33 @@ int vpci_make_msix_hole(const struct pci_dev *pdev)
>      return 0;
>  }
>  
> +static int cf_check cleanup_msix(struct pci_dev *pdev)
> +{
> +    int rc;
> +    struct vpci *vpci = pdev->vpci;
> +    const unsigned int msix_pos = pdev->msix_pos;
> +
> +    if ( !msix_pos )
> +        return 0;
> +
> +    rc = vpci_remove_registers(vpci, msix_control_reg(msix_pos), 2);
> +    if ( rc )
> +        return rc;
> +
> +    if ( !vpci->msix )
> +        return 0;

You cannot short-circuit here, as it then prevents adding the dummy
handlers done in the last return.

> +
> +    for ( unsigned int i = 0; i < ARRAY_SIZE(vpci->msix->table); i++ )
> +        if ( vpci->msix->table[i] )
> +            iounmap(vpci->msix->table[i]);
> +
> +    list_del(&vpci->msix->next);
> +    XFREE(vpci->msix);
> +
> +    return vpci_add_register(pdev->vpci, vpci_hw_read16, NULL,
> +                             msix_control_reg(msix_pos), 2, NULL);

The above needs to be added even if !vpci->msix.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 15:59:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 15:59:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007082.1386353 (Exim 4.92)
	(envelope-from )
	id 1uNCzt-00071s-8i; Thu, 05 Jun 2025 15:59:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007082.1386353; Thu, 05 Jun 2025 15:59: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 1uNCzt-00071l-5v; Thu, 05 Jun 2025 15:59:17 +0000
Received: by outflank-mailman (input) for mailman id 1007082;
 Thu, 05 Jun 2025 15:59: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 1uNCzs-00071f-8A
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 15:59:16 +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 06dda368-4226-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 17:59:14 +0200 (CEST)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-5fff52493e0so1418216a12.3
 for ; Thu, 05 Jun 2025 08:59:14 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-60566c2aba9sm10443034a12.2.2025.06.05.08.59.12
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 08:59:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 06dda368-4226-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749139153; x=1749743953; darn=lists.xenproject.org;
        h=content-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=GaIQRtc9d3iSedrxQcJBg3temD5lEMJYTzMYZJj6Vlw=;
        b=QwV/na8SYaZzCLPwdlGYAhC5LxLVV5x50//XKIrK3kLnwHwckxu0G0zD/IxVpc6vOw
         3KkH0UTVhUHkS8i6JjCJ1KKK3A7Yw6T5LdZ3wytJdgrP0eb/8QmEavVtPDrCY9JOCcwH
         ir6xvMHkOz9Xn/i85CUwqkJJN0aFpsOc23oLWI34rOuDJHpyqORBYY0jzWIw0GErTqZB
         IP3kRgPigxWrY5UYkaCUNPbc3pjutUYZYnW6BCawVBEz6Fcw/mF8os+Caf8mEoz7EhRp
         WpPXzRUmdNkgE9p/lgtXQI0dP+8jAPZKHZ2/1QsMjQaSml6buTvPdKTdkTYBX0HSP3yx
         wmCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749139153; x=1749743953;
        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=GaIQRtc9d3iSedrxQcJBg3temD5lEMJYTzMYZJj6Vlw=;
        b=H8tWz4UdxfbT8OnN2r/A5jbV9MxSZCX6I8/0No8tn7XOLUDmOA+bs3xXawt1eblgIO
         NFmd7PNT+xoV9x/s1SQYbZVCRqtF+K+CSIkS716TFH/GKZBt4+GW0XQfyWGkJ2eHitEL
         o4TI68CxU+nRwk1lO2yNwLaw/4lVAIsPZ7AJ+Om88eTeWKpNyw4nGyGLkkmIk/DyoW+l
         u8CUowGuX2816vFzNN5Q9L7xjBLAaaFu/Q+78Cqcfg6j/M60LXUQGm86z75aNqJ6mULf
         60N0l41+w+8oPN7azW1vLd+WgtRwCI3r2n91F7Y14QCaywANOhUfqpGJFT3eji8aNB2d
         foVA==
X-Gm-Message-State: AOJu0YyTbc/JimhhEVaVpJqLILpGYz9yBhVsxLuQvYqrRRWGZcxjodP5
	KNhKYGS365Hni6B5yxszusAfMsV77USjBqbjF+4rUFg0NOQNFIMkXygsszi9RQ==
X-Gm-Gg: ASbGncsblRNkMnnMLGzYQW456oaxZW+ZSqJVdle+D5Bddbo9zD4v6xAAEP3SDlHPFCH
	gkjXH0NbqlwmRWIsGF2ESaw34FCOurjxzoTBd/oVA0+FLUvZZdN2IpGlJ7GV8M/GsXjqJQ+BbMb
	N5/30y65OwouDnUM3I8uwPv3QvTu3ZMPY3ujnLzn1iJ5yTyK2Fs76Qk+7QWmp4hxGoY2CxdNBy0
	vX/TIB9XWCa7DaYDEwtuLH96Qfc+DQJzcaaeduyBL7AA0pRMSjM+DHYpE9sstI6BD+Ola/Dpo3R
	bEPPd/FTuq2LVmD1gbi2sYI3GqaH/flRtvOT7kirCCj2AMyxI7rpt7BGlbrftI0rLkuXw9I+iuN
	WfbUF9HGkGQW09ervMcCe5EMIrtjg
X-Google-Smtp-Source: AGHT+IEWPlkK/iMLYQiBhbCLgaRh59G0rEJ5K074BH6um0qrYe3P2tGlwobmKcfS7rA2jE8i4RCk1A==
X-Received: by 2002:a05:6402:350b:b0:607:32e8:652 with SMTP id 4fb4d7f45d1cf-60732e806ccmr1706776a12.19.1749139153169;
        Thu, 05 Jun 2025 08:59:13 -0700 (PDT)
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 v4 1/9] xen/riscv: dt_processor_hartid() implementation
Date: Thu,  5 Jun 2025 17:58:57 +0200
Message-ID: <751343d295c0fa6a9a7d8f2265ece3faecd44b64.1749121437.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Implements dt_processor_hartid() to get the hart ID of the given
device tree node and do some checks if CPU is available and given device
tree node has proper riscv,isa property.

As a helper function dt_get_hartid() is introduced to deal specifically
with reg propery of a CPU device node.

Signed-off-by: Oleksii Kurochko 
---
Changes in V4:
 - Sort properly inculsion of xen/types.h in riscv/smpboot.c.
 - Add overflow check of got address cell value in dt_get_hartid().
 - Use "%#lx" for loging recieved hartid from DTB.
 - s/-EINVAL/-ENODEV for recieved isa string from DTB.
---
Changes in V3:
 - s/dt_processor_cpuid/dt_processor_hartid.
 - s/dt_get_cpuid/dt_get_hartid.
 - use ~0UL in dt_get_cpuid() and in the comment above it.
 - change type for local variable ac in dt_get_cpuid() to unsigned int.
 - Update the return errors for dt_processor_cpuid().
 - Update the commit message + subject: s/cpuid/hartid.
---
Changes in V2:
 - s/of_get_cpu_hwid()/dt_get_cpu_id().
 - Update prototype of dt_get_cpu_hwid(), use pointer-to-const for cpun arg.
 - Add empty line before last return in dt_get_cpu_hwid().
 - s/riscv_of_processor_hartid/dt_processor_cpuid().
 - Use pointer-to_const for node argument of dt_processor_cpuid().
 - Use for hart_id unsigned long type as according to the spec for RV128
   mhartid register will be 128 bit long.
 - Update commit message and subject.
 - use 'CPU' instead of 'HART'.
 - Drop thread argument of dt_get_cpu_id() (of_get_cpu_hwid) as it is
   expected to be always 0 according to RISC-V's DTS binding.
---
 xen/arch/riscv/include/asm/smp.h |  4 ++
 xen/arch/riscv/smpboot.c         | 77 ++++++++++++++++++++++++++++++++
 2 files changed, 81 insertions(+)

diff --git a/xen/arch/riscv/include/asm/smp.h b/xen/arch/riscv/include/asm/smp.h
index 5e170b57b3..eb58b6576b 100644
--- a/xen/arch/riscv/include/asm/smp.h
+++ b/xen/arch/riscv/include/asm/smp.h
@@ -26,6 +26,10 @@ static inline void set_cpuid_to_hartid(unsigned long cpuid,
 
 void setup_tp(unsigned int cpuid);
 
+struct dt_device_node;
+int dt_processor_hartid(const struct dt_device_node *node,
+                        unsigned long *hartid);
+
 #endif
 
 /*
diff --git a/xen/arch/riscv/smpboot.c b/xen/arch/riscv/smpboot.c
index 0f9c2cc54a..8011876372 100644
--- a/xen/arch/riscv/smpboot.c
+++ b/xen/arch/riscv/smpboot.c
@@ -1,6 +1,9 @@
 #include 
+#include 
+#include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -14,3 +17,77 @@ void __init smp_prepare_boot_cpu(void)
     cpumask_set_cpu(0, &cpu_possible_map);
     cpumask_set_cpu(0, &cpu_online_map);
 }
+
+/**
+ * dt_get_hartid - Get the hartid from a CPU device node
+ *
+ * @cpun: CPU number(logical index) for which device node is required
+ *
+ * Return: The hartid for the CPU node or ~0UL if not found.
+ */
+static unsigned long dt_get_hartid(const struct dt_device_node *cpun)
+{
+    const __be32 *cell;
+    unsigned int ac;
+    uint32_t len;
+    unsigned int max_cells = UINT32_MAX / sizeof(*cell);
+
+    ac = dt_n_addr_cells(cpun);
+    cell = dt_get_property(cpun, "reg", &len);
+
+    if (ac > max_cells) {
+        printk("%s: cell count overflow (ac=%u, max=%u)\n", __func__, ac,
+               max_cells);
+        return ~0UL;
+    }
+
+    if ( !cell || !ac || ((sizeof(*cell) * ac) > len) )
+        return ~0UL;
+
+    return dt_read_number(cell, ac);
+}
+
+/*
+ * Returns the hartid of the given device tree node, or -ENODEV if the node
+ * isn't an enabled and valid RISC-V hart node.
+ */
+int dt_processor_hartid(const struct dt_device_node *node,
+                        unsigned long *hartid)
+{
+    const char *isa;
+    int ret;
+
+    if ( !dt_device_is_compatible(node, "riscv") )
+    {
+        printk("Found incompatible CPU\n");
+        return -ENODEV;
+    }
+
+    *hartid = dt_get_hartid(node);
+    if ( *hartid == ~0UL )
+    {
+        printk("Found CPU without CPU ID\n");
+        return -ENODATA;
+    }
+
+    if ( !dt_device_is_available(node))
+    {
+        printk("CPU with hartid=%#lx is not available\n", *hartid);
+        return -ENODEV;
+    }
+
+    if ( (ret = dt_property_read_string(node, "riscv,isa", &isa)) )
+    {
+        printk("CPU with hartid=%#lx has no \"riscv,isa\" property\n", *hartid);
+        return ret;
+    }
+
+    if ( isa[0] != 'r' || isa[1] != 'v' )
+    {
+        printk("CPU with hartid=%#lx has an invalid ISA of \"%s\"\n", *hartid,
+               isa);
+        return -ENODEV;
+    }
+
+    return 0;
+}
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 15:59:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 15:59:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007086.1386386 (Exim 4.92)
	(envelope-from )
	id 1uNCzx-0007ge-IR; Thu, 05 Jun 2025 15:59:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007086.1386386; Thu, 05 Jun 2025 15:59:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNCzx-0007fr-CI; Thu, 05 Jun 2025 15:59:21 +0000
Received: by outflank-mailman (input) for mailman id 1007086;
 Thu, 05 Jun 2025 15:59: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 1uNCzw-0007U9-M1
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 15:59:20 +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 0a179f57-4226-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 17:59:19 +0200 (CEST)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-606741e8e7cso2019511a12.1
 for ; Thu, 05 Jun 2025 08:59:19 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-60566c2aba9sm10443034a12.2.2025.06.05.08.59.16
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 08:59:18 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0a179f57-4226-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749139159; x=1749743959; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to;
        bh=J+NDKY61Cx6ldBPjIJ5Kx3dRaGdPkQgKXL4UjKAuxu0=;
        b=cr0mJdRqHpmassbITEm8jhiCPBEvyHw4ovZl/YDJsOCDnOUKxH27UpO3c7OoLqXg1h
         x1MGd715svVpn6lJB0OAj8wfOQGoDl8qht2R4tgsJk5IPZJmbRBnTEpJpg/8JSLEb/cm
         hjSLETXkjkfLsIFyLCHchfhc7xVYJvmXnE7bj5TAlL/AYi5wjBdJRV0Uyvpse9PwpZnH
         SBzsQOORHYBgvAjFxC+Bi0rznZ9GR7JLKIL84lWCDoi+Oue3/w+74Uyu8XCyUS4Ype7u
         XwHgMe+naJfPGg//q7I2uZ78ybA9PzDZceeUVC1gMTLqLLWDre0HxdwhnzGUHYKtEb7P
         7HhQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749139159; x=1749743959;
        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=J+NDKY61Cx6ldBPjIJ5Kx3dRaGdPkQgKXL4UjKAuxu0=;
        b=qri6j9kpO2sUqX25t3eHnxbJ5DbxQtpPh3c7fV3Lkh9OG3N2zP0IY4bvIWFX6Yjj3v
         C1Ce9xKRNTs176GIICZDwcJ8NkXP8s7/7zKXEu3Z8RT/YX1DJSj6yPDapPxp0Le8JSTG
         dq0F+jo0LFxnYbDG7FLZ+jLP8w/VkbVXMJJuhA/bvg/jrGjGynQlB1OjZz4pzfOdeIIO
         GA07niUofmRF+DwaIftHgcobiur8xDDcyuwKTIp+Ustowb1cNv/qSVxExMcMkMShJikf
         wceTMGinQyhtWL3iETHMQN1xmi3zc6OIvTZygbnpGcqO/aCCWXZWf+IQ+CFmAVWsyQe4
         KgkQ==
X-Gm-Message-State: AOJu0YydROQ6n7VErQCbbY8C0tXLdDmIHDHz80JLLHfVZ1y8v/YqCbwy
	aAiBL1Csd1+6aPcM8RIBPvA8UI2CtNZ9VjTxUM4GJ60H+3EtI6gHK8+Q4YXqdw==
X-Gm-Gg: ASbGnctPgkyyGgKrTOOlSq+hxUcgexUfDNbcL1K6Brp6D/QhOTGzny1XPCJXlV1RaSa
	PVbrkG/d1xrmC4IeUWuAjDGKrNKRUeHlfbba5rotK8vakoJsm/5Et8JnYCD6pRQXaYA6PRbJEwH
	T0zKIyOkelt2GucfbfwEcAplop2W+d9YkarkJ4nJCATp4Xy16AmF25ZD+tkiW2V6cUmzqMNxMrF
	n3KdZESVO6HGh5d/9W0K2vAGiDSVidFCBR8IZt1B69US5JDJLDbm94wAsHCgRcF2/m8LU4W6RFa
	QjjpKh2qb1OpD2r87pIHq99o+1X5yOfuahBoRkpYaboNLo0nXkSOUuhIIPzMJfFD/Xor6iAWHyd
	c/Cp7r9JkNNoAHgJjJA==
X-Google-Smtp-Source: AGHT+IFdBRqxzcs9BcNRaTjie4zaFJ0i9l3AgwmNLIf6sMWzwEUJQ2+TZPnc+YtLV0ejVORY1IiycA==
X-Received: by 2002:a05:6402:524d:b0:607:206f:a2e with SMTP id 4fb4d7f45d1cf-607206f0fd4mr3803925a12.32.1749139158540;
        Thu, 05 Jun 2025 08:59:18 -0700 (PDT)
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 ,
	Romain Caritey 
Subject: [PATCH v4 4/9] xen/riscv: aplic_init() implementation
Date: Thu,  5 Jun 2025 17:59:00 +0200
Message-ID: <1913a653568d51ed630dbbda1e1364b41aa5db89.1749121437.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

aplic_init() function does the following few things:
 - checks that IMSIC in device tree node  ( by checking msi-parent property
   in APLIC node ) is present as current one implmenetaion of AIA is
   supported only MSI method.
 - initialize IMSIC based on IMSIC device tree node
 - Read value of APLIC's paddr start/end and size.
 - Map aplic.regs
 - Setup APLIC initial state interrupts (disable all interrupts, set
   interrupt type and default priority, confgifure APLIC domaincfg) by
   calling aplic_init_hw_interrutps().

aplic_init() is based on the code from [1] and [2].

Since Microchip originally developed aplic.c, an internal discussion with
them led to the decision to use the MIT license.

[1] https://gitlab.com/xen-project/people/olkur/xen/-/commit/7cfb4bd4748ca268142497ac5c327d2766fb342d
[2] https://gitlab.com/xen-project/people/olkur/xen/-/commit/392a531bfad39bf4656ce8128e004b241b8b3f3e

Co-developed-by: Romain Caritey 
Signed-off-by: Oleksii Kurochko 
---
Changes in V4:
 - s/ASM__RISCV_PRIV_APLIC_H/ASM_RISCV_PRIV_APLIC_H
 - Drop APLIC_MAX_NUM_WIRED_IRQ_SOURCES and use ARRAY_SIZE(aplic.regs->sourcecfg).
 - Don't use 'else if' for the case when the earlier if() ends in an
   unconditional control flow change.
 - Use const for aplic_ops and drop __ro_after_init.
 - Add checks of APLIC's memory-mapped control region physical address and
   size.
 - s/ASM__RISCV__APLIC_H/ASM_RISCV_APLIC_H.
 - Use unsigned int in defintion of APLIC_DOMAINCFG_IE and APLIC_DOMAINCFG_DM.
 - set aplic_info.num_irqs to ARRAY_SIZE(aplic.regs->sourcecfg) if DT node
   provides too much.
 - Add some constraints for aplic.paddr_start and aplic.size.
---
Changes in V3:
 - Correct the comment on top of aplic-priv.h:
     xen/arch/riscv/aplic.h -> .../aplic-priv.h
 - Add __iomem for regs member of aplic_priv structure.
 - [aplic_init_hw_interrupts] Use ~0U instead of -1U in aplic_init_hw_interrupts()
   to disable all interrupts.
 - [aplic_init_hw_interrupts] Start 'i' (for-cycle variable) from 0, not from 1.
 - [aplic_init()] Declare imsic_node as pointer-to-const.
 - Use decimal for arrays in struct aplic_regs.
 - [aplic_init()] Check that aplic_info.num_irqs are less then 1023.
 - [aplic_init()] Drop out check of IMSIC's node interrupt-extended property
   from aplic_init().
---
Changes in V2:
 - use __ro_after_init for aplic_ops.
 - s/nr_irqs/num_irqs.
 - s/dt_processor_hartid/dt_processor_cpuid.
 - Drop confusing comment in aplic_init_hw_interrupts().
 - Code style fixes.
 - Drop years for Copyright.
 - Revert changes which drop nr_irq define from asm/irq.h,
   it shouldn't be, at least, part of this patch.
 - Drop paddr_enf from struct aplic_regs. It is enough to have pair
   (paddr_start, size).
 - Make  struct aplic_priv of asm/aplic.h private by moving it to
   riscv/aplic-priv.h.
 - Add the comment above the initialization of APLIC's target register.
 - use writel() to access APLIC's registers.
 - use 'unsinged int' for local variable i in aplic_init_hw_interrupts.
 - Add the check that all modes in interrupts-extended property of
   imsic node are equal. And drop rc != EOVERFLOW when interrupts-extended
   property is read.
 - Add cf_check to aplic_init().
 - Fix a cycle of clrie register initialization in aplic_init_hw_interrupts().
   Previous implementation leads to out-of-boundary.
 - Declare member num_irqs in struct intc_info as it is used by APLIC code.
---
 xen/arch/riscv/aplic-priv.h        |  34 ++++++++++
 xen/arch/riscv/aplic.c             | 104 +++++++++++++++++++++++++++++
 xen/arch/riscv/include/asm/aplic.h |  64 ++++++++++++++++++
 xen/arch/riscv/include/asm/intc.h  |   3 +
 4 files changed, 205 insertions(+)
 create mode 100644 xen/arch/riscv/aplic-priv.h
 create mode 100644 xen/arch/riscv/include/asm/aplic.h

diff --git a/xen/arch/riscv/aplic-priv.h b/xen/arch/riscv/aplic-priv.h
new file mode 100644
index 0000000000..7ed1ab8f4b
--- /dev/null
+++ b/xen/arch/riscv/aplic-priv.h
@@ -0,0 +1,34 @@
+/* SPDX-License-Identifier: MIT */
+
+/*
+ * xen/arch/riscv/aplic-priv.h
+ *
+ * Private part of aplic.h header.
+ *
+ * RISC-V Advanced Platform-Level Interrupt Controller support
+ *
+ * Copyright (c) Microchip.
+ * Copyright (c) Vates.
+ */
+
+#ifndef ASM_RISCV_PRIV_APLIC_H
+#define ASM_RISCV_PRIV_APLIC_H
+
+#include 
+
+#include 
+#include 
+
+struct aplic_priv {
+    /* base physical address and size */
+    paddr_t paddr_start;
+    size_t  size;
+
+    /* registers */
+    volatile struct aplic_regs __iomem *regs;
+
+    /* imsic configuration */
+    const struct imsic_config *imsic_cfg;
+};
+
+#endif /* ASM_RISCV_PRIV_APLIC_H */
diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c
index 10ae81f7ac..04964dc998 100644
--- a/xen/arch/riscv/aplic.c
+++ b/xen/arch/riscv/aplic.c
@@ -9,19 +9,119 @@
  * Copyright (c) 2024-2025 Vates
  */
 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
+
+#include "aplic-priv.h"
 
 #include 
+#include 
 #include 
+#include 
+
+#define APLIC_DEFAULT_PRIORITY  1
+
+static struct aplic_priv aplic;
 
 static struct intc_info __ro_after_init aplic_info = {
     .hw_version = INTC_APLIC,
 };
 
+static void __init aplic_init_hw_interrupts(void)
+{
+    unsigned int i;
+
+    /* Disable all interrupts */
+    for ( i = 0; i < ARRAY_SIZE(aplic.regs->clrie); i++)
+        writel(~0U, &aplic.regs->clrie[i]);
+
+    /* Set interrupt type and default priority for all interrupts */
+    for ( i = 0; i < aplic_info.num_irqs; i++ )
+    {
+        writel(0, &aplic.regs->sourcecfg[i]);
+        /*
+         * Low bits of target register contains Interrupt Priority bits which
+         * can't be zero according to AIA spec.
+         * Thereby they are initialized to APLIC_DEFAULT_PRIORITY.
+         */
+        writel(APLIC_DEFAULT_PRIORITY, &aplic.regs->target[i]);
+    }
+
+    writel(APLIC_DOMAINCFG_IE | APLIC_DOMAINCFG_DM, &aplic.regs->domaincfg);
+}
+
+static int __init cf_check aplic_init(void)
+{
+    dt_phandle imsic_phandle;
+    const __be32 *prop;
+    uint64_t size, paddr;
+    const struct dt_device_node *imsic_node;
+    const struct dt_device_node *node = aplic_info.node;
+    int rc;
+
+    /* Check for associated imsic node */
+    if ( !dt_property_read_u32(node, "msi-parent", &imsic_phandle) )
+        panic("%s: IDC mode not supported\n", node->full_name);
+
+    imsic_node = dt_find_node_by_phandle(imsic_phandle);
+    if ( !imsic_node )
+        panic("%s: unable to find IMSIC node\n", node->full_name);
+
+    rc = imsic_init(imsic_node);
+    if ( rc == IRQ_M_EXT )
+        /* Machine mode imsic node, ignore this aplic node */
+        return 0;
+
+    if ( rc )
+        panic("%s: Failded to initialize IMSIC\n", node->full_name);
+
+    /* Find out number of interrupt sources */
+    if ( !dt_property_read_u32(node, "riscv,num-sources",
+                               &aplic_info.num_irqs) )
+        panic("%s: failed to get number of interrupt sources\n",
+              node->full_name);
+
+    if ( aplic_info.num_irqs > ARRAY_SIZE(aplic.regs->sourcecfg) )
+        aplic_info.num_irqs = ARRAY_SIZE(aplic.regs->sourcecfg);
+
+    prop = dt_get_property(node, "reg", NULL);
+    dt_get_range(&prop, node, &paddr, &size);
+    if ( !paddr )
+        panic("%s: first MMIO resource not found\n", node->full_name);
+
+    if ( !IS_ALIGNED(paddr, KB(4)) )
+        panic("%s: paddr of memory-mapped control region should be 4Kb "
+              "aligned:%#lx\n", __func__, paddr);
+
+    if ( !IS_ALIGNED(size, KB(4)) && (size < KB(16)) )
+        panic("%s: memory-mapped control region should be a multiple of 4 KiB "
+              "in size and the smallest valid control is 16Kb: %#lx\n",
+              __func__, size);
+
+    aplic.paddr_start = paddr;
+    aplic.size = size;
+
+    aplic.regs = ioremap(paddr, size);
+    if ( !aplic.regs )
+        panic("%s: unable to map\n", node->full_name);
+
+    /* Setup initial state APLIC interrupts */
+    aplic_init_hw_interrupts();
+
+    return 0;
+}
+
+static const struct intc_hw_operations aplic_ops = {
+    .info                = &aplic_info,
+    .init                = aplic_init,
+};
+
 static int cf_check aplic_irq_xlate(const uint32_t *intspec,
                                     unsigned int intsize,
                                     unsigned int *out_hwirq,
@@ -53,8 +153,12 @@ static int __init aplic_preinit(struct dt_device_node *node, const void *dat)
 
     aplic_info.node = node;
 
+    aplic.imsic_cfg = imsic_get_config();
+
     dt_irq_xlate = aplic_irq_xlate;
 
+    register_intc_ops(&aplic_ops);
+
     return 0;
 }
 
diff --git a/xen/arch/riscv/include/asm/aplic.h b/xen/arch/riscv/include/asm/aplic.h
new file mode 100644
index 0000000000..fea95d4369
--- /dev/null
+++ b/xen/arch/riscv/include/asm/aplic.h
@@ -0,0 +1,64 @@
+/* SPDX-License-Identifier: MIT */
+
+/*
+ * xen/arch/riscv/asm/include/aplic.h
+ *
+ * RISC-V Advanced Platform-Level Interrupt Controller support
+ *
+ * Copyright (c) Microchip.
+ */
+
+#ifndef ASM_RISCV_APLIC_H
+#define ASM_RISCV_APLIC_H
+
+#include 
+
+#include 
+
+#define APLIC_DOMAINCFG_IE      BIT(8, U)
+#define APLIC_DOMAINCFG_DM      BIT(2, U)
+
+struct aplic_regs {
+    uint32_t domaincfg;
+    uint32_t sourcecfg[1023];
+    uint8_t _reserved1[3008];
+
+    uint32_t mmsiaddrcfg;
+    uint32_t mmsiaddrcfgh;
+    uint32_t smsiaddrcfg;
+    uint32_t smsiaddrcfgh;
+    uint8_t _reserved2[48];
+
+    uint32_t setip[32];
+    uint8_t _reserved3[92];
+
+    uint32_t setipnum;
+    uint8_t _reserved4[32];
+
+    uint32_t in_clrip[32];
+    uint8_t _reserved5[92];
+
+    uint32_t clripnum;
+    uint8_t _reserved6[32];
+
+    uint32_t setie[32];
+    uint8_t _reserved7[92];
+
+    uint32_t setienum;
+    uint8_t _reserved8[32];
+
+    uint32_t clrie[32];
+    uint8_t _reserved9[92];
+
+    uint32_t clrienum;
+    uint8_t _reserved10[32];
+
+    uint32_t setipnum_le;
+    uint32_t setipnum_be;
+    uint8_t _reserved11[4088];
+
+    uint32_t genmsi;
+    uint32_t target[1023];
+};
+
+#endif /* ASM_RISCV_APLIC_H */
diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h
index 434c9d0781..3c4b211f58 100644
--- a/xen/arch/riscv/include/asm/intc.h
+++ b/xen/arch/riscv/include/asm/intc.h
@@ -19,6 +19,9 @@ struct irq_desc;
 struct intc_info {
     enum intc_version hw_version;
     const struct dt_device_node *node;
+
+    /* number of irqs */
+    unsigned int num_irqs;
 };
 
 struct intc_hw_operations {
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 15:59:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 15:59:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007083.1386362 (Exim 4.92)
	(envelope-from )
	id 1uNCzu-0007FS-EX; Thu, 05 Jun 2025 15:59:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007083.1386362; Thu, 05 Jun 2025 15:59: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 1uNCzu-0007FL-C0; Thu, 05 Jun 2025 15:59:18 +0000
Received: by outflank-mailman (input) for mailman id 1007083;
 Thu, 05 Jun 2025 15:59: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 1uNCzt-00071f-QN
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 15:59:17 +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 064b0998-4226-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 17:59:13 +0200 (CEST)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-604f5691bceso2104100a12.0
 for ; Thu, 05 Jun 2025 08:59:13 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-60566c2aba9sm10443034a12.2.2025.06.05.08.59.11
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 08:59:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 064b0998-4226-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749139152; x=1749743952; 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=mZv5gn3dUevmvppm18T2Hm/N5xKI+DzKUnOvVeHLeFg=;
        b=WLI331aS1OoPjUpE+e0bpsmR8NtOJvjOYxG0c4p8iSih/HGDbiVcAndNgBrcO4T3cK
         1s3W4TNCUTL8+eroWcrjsQw+Gr1NIjUcQUukMu91BPzKa62U4KMdo9M0m+0qMxHAVocd
         pxOBJC64QZt9I5x2BuIYEK9ARhFBqZBX84UN8yFDC+C14r23kF16pjePNIf4G4UJiG6t
         5ro0ZCJctwtnrEBCK5BA0Y4HP0Kqm2+UbjC6i96wIvWOqXilNX8lkdkeWlvjeBYOKAm+
         WtmQ6hMzFbzQcbiF10IbClp9SOotG1OJSJrnFhDOpKs85LUGcCp2pssluitUy8YAuNCD
         SCVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749139152; x=1749743952;
        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=mZv5gn3dUevmvppm18T2Hm/N5xKI+DzKUnOvVeHLeFg=;
        b=f0S/1Vqja/QLrY3Q9ZkS1VA6NH6PpCNm+JHTgEYUTRkDHRDtwiMcVNRV54w4v/MaNY
         spEcUbUCuTzPRmupTNwLjqjZ8xjyVllC2jVQYqExTTxq6Qbj1hxVJLfBIjtnvUfY7ZBd
         MIZr4ugqDQWF1OOMfTxA5zJ1M4q/jpvIg0lUZqpB2ezhN0eAsR+hN7qb3bVHY4C4c8Lj
         2eIVmO7oaAwOMNUpTcfr00EEWYve4Bu+bRNLU0owb73/wWYkEQiX5BCOiTiCK1yVUMZK
         UwXdnjNWD/JCL5YyjrVi04BZRrTQF0DOPjEZPVXAQaR00qYkNJv53h7vRTWoOk7tkxKA
         Wo2Q==
X-Gm-Message-State: AOJu0YwaR9YBkOpagTMQt43f6yMgbtHW91KdCk5vxpyLuw8B/JioppM/
	34DWS+z2Y0pxgcMGxe2FOjIkQ/RLOTDw3rSp5sSeTebBex8tDOt/jSTw+CSXfg==
X-Gm-Gg: ASbGncvyFlGblLdro8tRp9nUjvpUeBfXzssA/X5dhnifXsz2od9Nn4CfbuhIkkYECW7
	wddly5AtzC35XLguKYg/ufEW6KvagBS1JjOIU/gMYOEPRrN3Rra/m1iwP/AXhjJwOjdT9cs9t3Y
	0dwuuKRxT6fOAbtEd73ZoM/lpQUO40Kf6qJN9yFJr1SKixW4i/iP2DUURqgRZCIDaoOkDZZOCxB
	c6JEnKUm1TxLi8S5XlXcuqf8Ua2d4klaWDq2+cK9eHM6v9YZ0GVw5+TpMoAAbnVOuqiVLhli1Iw
	LpMdWDpZcRPiu26LBi7yxSGEISsEX0UdRZdCdT13GfbnB3uHpms+LbXnU4VD4zTa5zaVGoFes29
	bwwQbaFaKSbPrULqrFYooR2ynjOMn
X-Google-Smtp-Source: AGHT+IEiKCplfGqYkEV0G+mogv/9gCwlyW6tEVebX1rMvvknqDQj3/5aKDPhaEVraorB47xe5kLO5g==
X-Received: by 2002:a05:6402:5241:b0:607:4c8e:514d with SMTP id 4fb4d7f45d1cf-6074c8e5257mr973870a12.6.1749139152290;
        Thu, 05 Jun 2025 08:59:12 -0700 (PDT)
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 v4 0/9] riscv: introduce basic UART support and interrupts for hypervisor mode
Date: Thu,  5 Jun 2025 17:58:56 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The patch series introduces basic UART support (in interrupt mode) and support of
interrupts for hypervisor mode.

To implement this the following has been added:
- APLIC and IMISC initialization.
- Introduce of intc_hw_operations abstraction.
- Introduce some APLIC and IMSIC operations.
- Introduce init_IRQ(), platform_get_irq() and setup_irq() functions.
- Update do_trap() handler to handle IRQ_S_EXT.
- Introduce some other functions such as: get_s_time(), smp_clear_cpu_maps(),
  ioremap().
- Enable UART. 

CI tests: https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/1829069921
---
Changes in V4:
 - Merged to staging:
    - xen/riscv: initialize bitmap to zero in riscv_fill_hwcap_from_isa_string()
    - xen/asm-generic: introduce asm-generic/irq-dt.h
    - xen/riscv: introduce smp_prepare_boot_cpu()
    - xen/riscv: introduce support of Svpbmt extension
    - add ioremap_*() variants using ioremap_attr()
    - xen/riscv: introduce init_IRQ()
    - xen/riscv: introduce platform_get_irq()
 - All other changes are patch-specific. Please check each patch separately.
---
Changes in V2:
 - Merged to staging:
    xen/riscv: initialize bitmap to zero in riscv_fill_hwcap_from_isa_string()
    xen/asm-generic: introduce asm-generic/irq-dt.h
 - All other changes are patch-specific. Please check each patch separately.
---

Oleksii Kurochko (9):
  xen/riscv: dt_processor_hartid() implementation
  xen/riscv: introduce register_intc_ops() and intc_hw_ops.
  xen/riscv: imsic_init() implementation
  xen/riscv: aplic_init() implementation
  xen/riscv: introduce intc_init() and helpers
  xen/riscv: implementation of aplic and imsic operations
  xen/riscv: add external interrupt handling for hypervisor mode
  xen/riscv: implement setup_irq()
  xen/riscv: add basic UART support

 xen/arch/riscv/Kconfig             |   1 +
 xen/arch/riscv/Makefile            |   1 +
 xen/arch/riscv/aplic-priv.h        |  38 +++
 xen/arch/riscv/aplic.c             | 296 ++++++++++++++++++
 xen/arch/riscv/imsic.c             | 478 +++++++++++++++++++++++++++++
 xen/arch/riscv/include/asm/aplic.h |  73 +++++
 xen/arch/riscv/include/asm/imsic.h |  74 +++++
 xen/arch/riscv/include/asm/intc.h  |  32 ++
 xen/arch/riscv/include/asm/irq.h   |   8 +-
 xen/arch/riscv/include/asm/smp.h   |  17 +
 xen/arch/riscv/intc.c              |  55 ++++
 xen/arch/riscv/irq.c               | 131 ++++++++
 xen/arch/riscv/setup.c             |  14 +
 xen/arch/riscv/smpboot.c           |  77 +++++
 xen/arch/riscv/traps.c             |  19 ++
 xen/drivers/char/Kconfig           |   3 +-
 16 files changed, 1314 insertions(+), 3 deletions(-)
 create mode 100644 xen/arch/riscv/aplic-priv.h
 create mode 100644 xen/arch/riscv/imsic.c
 create mode 100644 xen/arch/riscv/include/asm/aplic.h
 create mode 100644 xen/arch/riscv/include/asm/imsic.h

-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 15:59:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 15:59:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007084.1386372 (Exim 4.92)
	(envelope-from )
	id 1uNCzw-0007UL-MC; Thu, 05 Jun 2025 15:59:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007084.1386372; Thu, 05 Jun 2025 15: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 1uNCzw-0007UC-JL; Thu, 05 Jun 2025 15:59:20 +0000
Received: by outflank-mailman (input) for mailman id 1007084;
 Thu, 05 Jun 2025 15: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 1uNCzv-00071f-8U
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 15:59:19 +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 08e2e749-4226-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 17:59:17 +0200 (CEST)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-601f278369bso2304251a12.1
 for ; Thu, 05 Jun 2025 08:59:17 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-60566c2aba9sm10443034a12.2.2025.06.05.08.59.13
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 08:59:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 08e2e749-4226-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749139157; x=1749743957; darn=lists.xenproject.org;
        h=content-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=8rMgsLeE3IPvDrOvyCQ5hw/i+mcvXBtOgOiBpyo7Ow8=;
        b=nlwo5ZQMM98ycaJvDWaUGm8O+EeByck7QUksUcCme9qAkd7sMpWnS5M+ZXLUuUFn5p
         DUKXV+87z53gfIFq8yE/erXsSZBNAS7mQfnBSuSwP4b2RzQ7qKm1e6zQD5oXqQ6kZtIP
         Zog2W0FMGL77GtmhPEI7f2zqAunFmfOh3X7q6jnb7NeQTbUUo67U2fLjtCA+/BEisiNH
         46+KpZtWAIZpMKepOFslvVeFktw5skcqj/4qmb1pVS1opSSiweEgPcysBTN4n4Qw4I+o
         iXOlHMwpB5sPKZ2sxyg5DTeWwScOZZbYlo14WvTV+S1mhCZulNaTxDjnkSJAV5QMq0ON
         xz3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749139157; x=1749743957;
        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=8rMgsLeE3IPvDrOvyCQ5hw/i+mcvXBtOgOiBpyo7Ow8=;
        b=qNM7khYiLHf5ePyRL27oCeBpsXzmaYse4woOcbZ5a5u5HeTKCHQjUu3anXu4Bd5IEL
         WA+MNztoyXnNEd1U9YoaHCnIdRb5F+Q8dneFhWzgltmYpmFdFt6Km7BDZmsOmj18d6+g
         VM52hk0t8ISS1JskkrfBE/RiKx3KPTKXPi9U8/rt44aniNfBR5hMSm5CvuLZnQIwZISS
         rXxyMsV7WyRSwg5iCtujeesCWn9bCsAo9fQ5Mr0eXVVqzGZWNq8mlNd1QNTdBF2OwFS0
         sdlQ02ImgVdknl43XJqMG7QUYq3nWV2KQojFHBmy94KOaTvigMpNaP6/JiWnGPUHJ1Bn
         MITQ==
X-Gm-Message-State: AOJu0YwIn8NPuS4vVjQQY1VtBq/JT0CGf07HlIEyKElmUzrLfd0JAVs3
	AU0GPhceYcrn7HrNNidP0JzUv1nnzDrG6dpV2+5IOFSTq/VXXmwyksVLZDtpxQ==
X-Gm-Gg: ASbGncs2cC5FtrIxdvEmI65HdjisXQG9WtjEa6JFNpj3R82ndTRv6Avs7tdo62tBDND
	rGkoRzgv/Dq8M0qjiCGbOYvfYotGMWPuXLsdiZtiXqpPIpQXLxd76fF2yb7Pb8WgXHLoIff5Rh/
	yyJxhPRtYnLCIIHqtiom3bO+8nJP5FIkzSxhwMwUK63JcQb1lvgl5mHdF9T54MxzaXOB86vFzS+
	xJU1TsSpxE2ocPUHevpIJb0uOkEsbsiSaSfHC2wAUD1PcD/VawPnFgubuX/2a+O4Cf+KDDTejta
	4crVoHk8vpnLJ04R6Sn2QfeDRZ2ZWSD0L300/v+7254CsXZFlDEAZnSHf9E41rO9dRT+YyUPJsU
	rgPZK5oN2g75A825WXw==
X-Google-Smtp-Source: AGHT+IH7rXiZOc4pWZsuxKU/tb4/N3pcyfMMbckG8T5MjO0JeKXo7aXBlXFcqF9yolConDtACq6QAA==
X-Received: by 2002:a05:6402:3591:b0:607:27bb:7bf with SMTP id 4fb4d7f45d1cf-60727bb09f7mr3105825a12.32.1749139154603;
        Thu, 05 Jun 2025 08:59:14 -0700 (PDT)
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 ,
	Romain Caritey 
Subject: [PATCH v4 2/9] xen/riscv: introduce register_intc_ops() and intc_hw_ops.
Date: Thu,  5 Jun 2025 17:58:58 +0200
Message-ID: <100c1377b3ac06a2603d5740ad4606cb84bff168.1749121437.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Introduce the intc_hw_operations structure to encapsulate interrupt
controller-specific data and operations. This structure includes:
- A pointer to interrupt controller information (`intc_info`)
- Callbacks to initialize the controller and set IRQ type/priority
- A reference to an interupt controller descriptor (`host_irq_type`)
- number of interrupt controller irqs.

Add function register_intc_ops() to mentioned above structure.

Co-developed-by: Romain Caritey 
Signed-off-by: Oleksii Kurochko 
Acked-by: Jan Beulich 
---
Changes in V4:
 - Add Acked-by: Jan Beulich .
---
Changes in V3:
 - Drop inclusion of xen/irq.h in asm/intc.h as forward declaration is enogh
   for types used in asm/intc.h.
 - Drop forward declaration for dt_device_node  and hw_irq_controller.
 - Declare intc_hw_ops as:
     const struct intc_hw_operations * __ro_after_init intc_hw_ops;
---
Changes in V2:
 - Declare host_irq_type member of intc_hw_operations as pointer-to-const.
 - Moved up forward declaration of irq_desc.
 - Use attribute __init for register_intc_ops().
 - Use attribute __ro_after_init for intc_hw_ops variable.
 - Update prototype of register_intc_ops() because of what mention in the
   previous point.
---
 xen/arch/riscv/include/asm/intc.h | 19 +++++++++++++++++++
 xen/arch/riscv/intc.c             |  9 +++++++++
 2 files changed, 28 insertions(+)

diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h
index 81f74736ba..434c9d0781 100644
--- a/xen/arch/riscv/include/asm/intc.h
+++ b/xen/arch/riscv/include/asm/intc.h
@@ -14,11 +14,30 @@ enum intc_version {
     INTC_APLIC,
 };
 
+struct irq_desc;
+
 struct intc_info {
     enum intc_version hw_version;
     const struct dt_device_node *node;
 };
 
+struct intc_hw_operations {
+    /* Hold intc hw information */
+    const struct intc_info *info;
+    /* Initialize the intc and the boot CPU */
+    int (*init)(void);
+
+    /* hw_irq_controller to enable/disable/eoi host irq */
+    const struct hw_interrupt_type *host_irq_type;
+
+    /* Set IRQ type */
+    void (*set_irq_type)(struct irq_desc *desc, unsigned int type);
+    /* Set IRQ priority */
+    void (*set_irq_priority)(struct irq_desc *desc, unsigned int priority);
+};
+
 void intc_preinit(void);
 
+void register_intc_ops(const struct intc_hw_operations *ops);
+
 #endif /* ASM__RISCV__INTERRUPT_CONTOLLER_H */
diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c
index 4061a3c457..1ecd651bf3 100644
--- a/xen/arch/riscv/intc.c
+++ b/xen/arch/riscv/intc.c
@@ -5,6 +5,15 @@
 #include 
 #include 
 
+#include 
+
+static const struct intc_hw_operations *__ro_after_init intc_hw_ops;
+
+void __init register_intc_ops(const struct intc_hw_operations *ops)
+{
+    intc_hw_ops = ops;
+}
+
 void __init intc_preinit(void)
 {
     if ( acpi_disabled )
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 15:59:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 15:59:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007085.1386378 (Exim 4.92)
	(envelope-from )
	id 1uNCzx-0007XN-2I; Thu, 05 Jun 2025 15:59:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007085.1386378; Thu, 05 Jun 2025 15: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 1uNCzw-0007WZ-S5; Thu, 05 Jun 2025 15:59:20 +0000
Received: by outflank-mailman (input) for mailman id 1007085;
 Thu, 05 Jun 2025 15: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 1uNCzv-00071f-LR
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 15:59:19 +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 091863aa-4226-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 17:59:17 +0200 (CEST)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-6049431b409so1844490a12.3
 for ; Thu, 05 Jun 2025 08:59:17 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-60566c2aba9sm10443034a12.2.2025.06.05.08.59.15
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 08:59:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 091863aa-4226-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749139157; x=1749743957; darn=lists.xenproject.org;
        h=content-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=Dpzts88BV16XRk69iw2WTJIV9eUg+bb35qrt86wG5/Q=;
        b=OVJGzquzOdaSBa4YC1GThkMkzervCpFOr36unpf8sSrmrZBOOF9OZUWTZLS2Kri3gF
         Gbraxo0m5+Jin3nOW4D4WHv3oiCzZPq0eII2xdUQaBkLOFBvzIj1J4/I+++v4pDZNzvw
         ehqy57aY0b9QTZYH9l2sAqG+pB6TtcvFzm2xsull08RBKjSJSjSGc3IhcTslgdOP/2Q6
         DvVijEpKxaqkB0NzohmgkAE0xbhuRYN2nyWNALL8TiNV6mVVUZMUIMiF26A+DHqxoxSP
         W+YGLx6900JOW2yslJs0TA7dUuVTZ2Ga2oUV4mtan2dWqvcHnuXbeLBKV7ElptvH1Tjm
         jXIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749139157; x=1749743957;
        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=Dpzts88BV16XRk69iw2WTJIV9eUg+bb35qrt86wG5/Q=;
        b=IqYZaHy9UIP/pPfsM83RFnyuNmAYNX00xzRR7QleKCiIebBmesUzElWsX40oHf2cQo
         xVYEXA+dxQY5C2FEl46UsC8PePywMPgqNdRdsNY/v6D7XVfrdN/B9zZ8a8D64JxbErHw
         B2e98K09NbK6xFRvgevrDi+Qg2xLDy7SFyysABjfeIJqwDyw6eZAjNgIojzsEGTcwVxm
         LZOf7BcncYFzdmxF1QEfkN45nCxkusoSFISZsdl74SvO7IYbCvDk29WjjxM8TpCud7Jk
         +MV9C626o3zDn50VBiIGEFzoSK8wG/Rsi/zk9ZTDjYJowZgf91q4vqXP1ZcfE4xEABMm
         i2hQ==
X-Gm-Message-State: AOJu0Yz6p62t+4dWeeNBnnmyB1DD2h88dOeG0g1RtWy1SwuXRxPYp0Em
	kwJLDYQiCNvIGawF0Il2B5X0nuQSKi6MzptzFzq5/vKuYPYE4BfUVgUh30KVow==
X-Gm-Gg: ASbGncuwcRwEY1p2/62DviG0aB3B215VUDj79odwB8uZJhCoLGHkDPyYMEiH1YJxYLa
	jQbMm1VSaJdWAFUlo8PEfU2Uq3QEPMjc7ZLNY9Ggfd2Y4ODNUFrOXMuDWfbeZhnvS6kUtC3zWM8
	0LajwO1ln3QQBiwtM81BR4jFiQO17z9w7ObkDAzOdbnaAbEe1dvESwSGV8aRHj1F6MF2WT+NgNB
	RV1FvVEf9R9BbkKx3Xl4AotnRT4ki+FfQT5J4Ph2gg2zb8DrcxN7bGM8PpI8gh6/V7RM/wpIjzp
	km5f6aZWE4zfHDqYbk1z1jhzyUcbXt7+A7Dn0As9b+R2ngrCV0BqBeX5mg/xuWDCElY/fTJyq+a
	xmV44Hfa4GToXKy+DpQ==
X-Google-Smtp-Source: AGHT+IGpbl/ztVvGMxcokcetYdxeU83f36HyNSxugyMKvR6KwiJ5/5Dr7lvZ0nXzY9/x2awNk7XwJg==
X-Received: by 2002:a05:6402:524f:b0:602:3e3:dada with SMTP id 4fb4d7f45d1cf-606ea191585mr7843529a12.25.1749139156687;
        Thu, 05 Jun 2025 08:59:16 -0700 (PDT)
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 ,
	Romain Caritey 
Subject: [PATCH v4 3/9] xen/riscv: imsic_init() implementation
Date: Thu,  5 Jun 2025 17:58:59 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

imsic_init() is introduced to parse device tree node, which has the following
bindings [2], and based on the parsed information update IMSIC configuration
which is stored in imsic_cfg.

The following helpers are introduces for imsic_init() usage:
  - imsic_parse_node() parses IMSIC node from DTS
  - imsic_get_parent_hartid() returns the hart ( CPU ) ID of the given device
    tree node.

This patch is based on the code from [1].

Since Microchip originally developed imsic.{c,h}, an internal discussion with
them led to the decision to use the MIT license.

[1] https://gitlab.com/xen-project/people/olkur/xen/-/commit/0b1a94f2bc3bb1a81cd26bb75f0bf578f84cb4d4
[2] https://elixir.bootlin.com/linux/v6.12/source/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml

Co-developed-by: Romain Caritey 
Signed-off-by: Oleksii Kurochko 
---
Changes in V4:
 - s/expected/intended in the comment above imsic_get_config().
 - [imsic_parse_node()] s/irq_num can be 0/irq_num can't be 0 in panic()
   message.
 - [imsic_parse_node()] Move "if ( irq_range[1] == IRQ_M_EXT )" after 'for loop'
   which checks interrupts-extended property.
 - [imsic_parse_node()] s/%d/%u for logging unsigned values.
 - [imsic_parse_node()] drop redundant check "(imsic_cfg.nr_ids & IMSIC_MIN_ID) != IMSIC_MIN_ID)".
 - [imsic_parse_node()] free irq_range much earlier and simlify error paths.
 - [imsic_parse_node()] s/-EINVAL/-ENOENT in the case of incorrect value for
   riscv,group-index-shift and id number.
 - [[imsic_parse_node()] s/xzalloc_array/xvzalloc_array.
 - s/xen_cpuid/cpu.
 - Identation fix.
 - use IMSIC_MMIO_PAGE_SZ instead of PAGE_SZ to check if interrupt file base
   addr is properly aligned.
 - s/ASM__RISCV__IMSIC_H/ASM_RISCV_IMSIC_H.
 - Drop *mmios from struct imsic_cfg as it is used only by imsic_init().
 - Drop cpus[] form struct imsic_mmios as it isn't really used.
 - Update declaration of hartid_to_cpuid() to return unsigned int instead of
   NR_CPUs as processor_id is in range [0, NR_CPUS) and NR_CPUs is less then
   unsigned int.
 - Calculate hart_index_bits as fls(*nr_parent_irqs - 1) to cover the case if
   nr_parent_irqs is a power of two.
 - Check an MMIO's size for IMSIC node.
---
Changes in V3:
 - Drop year in imsic.h in copyrights.
 - Correct identation in imsic_parse_node() and imsic_init()
   where for imsic_cfg.base_addr a mask is applied.
 - Use unsigned int istead of uint32_t for local variable nr_parent_irqs,
   index, nr_handlers in imsic_init().
 - Fix a leakage of ealiers successfull allocations in case if imsic_init()
   returns with an error.
 - Excess blank in printk() message: "%s: unable to parse MMIO regset %d\n".
 - Introduce hartid_to_cpuid() and use it in the check:
     if ( hardid_to_cpuid(cpuid) >= num_possible_cpus() )
   in imsic_init().
 - Use "%u" for unsigned int in printk(...).
 - Fix for loop condition: nr_mmios -> "j < nr_mmios".
 - [imsic_init()] Drop usage of j in nested loop. It is enough to have only
   index.
 - Change 0x%lx to %#lx for formatting of an address in printk().
 - [imsic_init()] Rename local variable cpuid to hartid.
 - s/imsic_get_parent_cpuid/imsic_get_parent_hartid, s/cpuid/hartid for an
   imsic_get_parent_hartid()'s argument.
 - Declare cpus member of struct imsic_mmios as cpumask_t.
 - [imsic_init()] Allocate imsic_mmios.cpus by using of alloc_cpumask_var().
 - [imsic_init()] Use cpumask_set_cpu() instead of bitmap_set().
 - [imsic_parse_node()] add check for correctness of "interrupt-extended" property.
 - [imsic_parse_node()] Use dt_node_name() or dt_full_node_name() instead of
   derefence of struct dt_node.
 - [imsic_parse_node()] Add cleanup label and update 'rc = XXX; goto cleanup'
   instead of 'return rc' as now we have to cleanup dynamically allocated irq_range
   array.
 - Add comments above imsic_init() and imsic_parse_node().
 - s/xen/arch/riscv/imsic.h/xen/arch/riscv/include/asm/imsic.h in the comment of
   imsic.h.
---
Changes in V2:
 - Drop years in copyrights.
 - s/riscv_of_processor_hartid/dt_processor_cpuid.
 - s/imsic_get_parent_hartid/imsic_get_parent_hartid.
   Rename argument hartid to cpuid.
   Make node argument const.
   Return res instead of -EINVAL for the failure case of dt_processor_cpuid().
   Drop local variable hart and use cpuid argument instead.
   Drop useless return res;
 - imsic_parse_node() changes:
   - Make node argument const.
   - Check the return value of dt_property_read_u32() directly instead of
     saving it to rc variable.
   - Update tmp usage, use short form "-=".
   - Update a check (imsic_cfg.nr_ids >= IMSIC_MAX_ID) to (imsic_cfg.nr_ids > IMSIC_MAX_ID)
     as IMSIC_MAX_ID is changed to maximum valid value, not just the firsr out-of-range.
   - Use `rc` to return value instead of explicitly use -EINVAL.
   - Use do {} while() to find number of MMIO register sets.
 - Set IMSIC_MAX_ID to 2047 (maximum possible IRQ number).
 - imsic_init() changes:
   - Use unsigned int in for's expression1.
   - s/xfree/XFEE.
   - Allocate msi and cpus array dynamically.
 - Drop forward declaration before declaration of imsic_get_config() in asm/imsic.h
   as it is not used as parameter type.
 - Align declaration of imisic_init with defintion.
 - s/harts/cpus in imisic_mmios.
   Also, change type from bool harts[NR_CPUS] to unsigned long *cpus.
 - Allocate msi member of imsic_config dynamically to save some memory.
 - Code style fixes.
 - Update the commit message.
---
 xen/arch/riscv/Makefile            |   1 +
 xen/arch/riscv/imsic.c             | 358 +++++++++++++++++++++++++++++
 xen/arch/riscv/include/asm/imsic.h |  55 +++++
 xen/arch/riscv/include/asm/smp.h   |  13 ++
 4 files changed, 427 insertions(+)
 create mode 100644 xen/arch/riscv/imsic.c
 create mode 100644 xen/arch/riscv/include/asm/imsic.h

diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index a1c145c506..e2b8aa42c8 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -2,6 +2,7 @@ obj-y += aplic.o
 obj-y += cpufeature.o
 obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
 obj-y += entry.o
+obj-y += imsic.o
 obj-y += intc.o
 obj-y += irq.o
 obj-y += mm.o
diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c
new file mode 100644
index 0000000000..5006146cb8
--- /dev/null
+++ b/xen/arch/riscv/imsic.c
@@ -0,0 +1,358 @@
+/* SPDX-License-Identifier: MIT */
+
+/*
+ * xen/arch/riscv/imsic.c
+ *
+ * RISC-V Incoming MSI Controller support
+ *
+ * (c) Microchip Technology Inc.
+ * (c) Vates
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define IMSIC_HART_SIZE(guest_bits_) (BIT(guest_bits_, U) * IMSIC_MMIO_PAGE_SZ)
+
+struct imsic_mmios {
+    paddr_t base_addr;
+    unsigned long size;
+};
+
+static struct imsic_config imsic_cfg;
+
+/* Callers aren't intended to changed imsic_cfg so return const. */
+const struct imsic_config *imsic_get_config(void)
+{
+    return &imsic_cfg;
+}
+
+static int __init imsic_get_parent_hartid(const struct dt_device_node *node,
+                                          unsigned int index,
+                                          unsigned long *hartid)
+{
+    int res;
+    struct dt_phandle_args args;
+
+    res = dt_parse_phandle_with_args(node, "interrupts-extended",
+                                     "#interrupt-cells", index, &args);
+    if ( !res )
+        res = dt_processor_hartid(args.np->parent, hartid);
+
+    return res;
+}
+
+/*
+ * Parses IMSIC DT node.
+ *
+ * Returns 0 if initialization is successful, a negative value on failure,
+ * or IRQ_M_EXT if the IMSIC node corresponds to a machine-mode IMSIC,
+ * which should be ignored by the hypervisor.
+ */
+static int imsic_parse_node(const struct dt_device_node *node,
+                            unsigned int *nr_parent_irqs,
+                            unsigned int *nr_mmios)
+{
+    int rc;
+    unsigned int tmp;
+    paddr_t base_addr;
+    uint32_t *irq_range;
+
+    *nr_parent_irqs = dt_number_of_irq(node);
+    if ( !*nr_parent_irqs )
+        panic("%s: irq_num can't be 0. Check %s node\n", __func__,
+              dt_node_full_name(node));
+
+    irq_range = xvzalloc_array(uint32_t, *nr_parent_irqs * 2);
+    if ( !irq_range )
+        panic("%s: irq_range[] allocation failed\n", __func__);
+
+    if ( (rc = dt_property_read_u32_array(node, "interrupts-extended",
+                                    irq_range, *nr_parent_irqs * 2)) )
+        panic("%s: unable to find interrupt-extended in %s node: %d\n",
+              __func__, dt_node_full_name(node), rc);
+
+    /* Check that interrupts-extended property is well-formed. */
+    for ( unsigned int i = 2; i < (*nr_parent_irqs * 2); i += 2 )
+    {
+        if ( irq_range[i + 1] != irq_range[1] )
+            panic("%s: mode[%u] != %u\n", __func__, i + 1, irq_range[1]);
+    }
+
+    if ( irq_range[1] == IRQ_M_EXT )
+    {
+        /* Machine mode imsic node, ignore it. */
+        xfree(irq_range);
+
+        return IRQ_M_EXT;
+    }
+
+    xfree(irq_range);
+
+    if ( !dt_property_read_u32(node, "riscv,guest-index-bits",
+                               &imsic_cfg.guest_index_bits) )
+        imsic_cfg.guest_index_bits = 0;
+    tmp = BITS_PER_LONG - IMSIC_MMIO_PAGE_SHIFT;
+    if ( tmp < imsic_cfg.guest_index_bits )
+    {
+        printk(XENLOG_ERR "%s: guest index bits too big\n",
+               dt_node_name(node));
+        return -ENOENT;
+    }
+
+    /* Find number of HART index bits */
+    if ( !dt_property_read_u32(node, "riscv,hart-index-bits",
+                               &imsic_cfg.hart_index_bits) )
+        /* Assume default value */
+        imsic_cfg.hart_index_bits = fls(*nr_parent_irqs - 1);
+    tmp -= imsic_cfg.guest_index_bits;
+    if ( tmp < imsic_cfg.hart_index_bits )
+    {
+        printk(XENLOG_ERR "%s: HART index bits too big\n",
+               dt_node_name(node));
+        return -ENOENT;
+    }
+
+    /* Find number of group index bits */
+    if ( !dt_property_read_u32(node, "riscv,group-index-bits",
+                               &imsic_cfg.group_index_bits) )
+        imsic_cfg.group_index_bits = 0;
+    tmp -= imsic_cfg.hart_index_bits;
+    if ( tmp < imsic_cfg.group_index_bits )
+    {
+        printk(XENLOG_ERR "%s: group index bits too big\n",
+               dt_node_name(node));
+        return -ENOENT;
+    }
+
+    /* Find first bit position of group index */
+    tmp = IMSIC_MMIO_PAGE_SHIFT * 2;
+    if ( !dt_property_read_u32(node, "riscv,group-index-shift",
+                               &imsic_cfg.group_index_shift) )
+        imsic_cfg.group_index_shift = tmp;
+    if ( imsic_cfg.group_index_shift < tmp )
+    {
+        printk(XENLOG_ERR "%s: group index shift too small\n",
+               dt_node_name(node));
+        return -ENOENT;
+    }
+    tmp = imsic_cfg.group_index_bits + imsic_cfg.group_index_shift - 1;
+    if ( tmp >= BITS_PER_LONG )
+    {
+        printk(XENLOG_ERR "%s: group index shift too big\n",
+               dt_node_name(node));
+        return -ENOENT;
+    }
+
+    /* Find number of interrupt identities */
+    if ( !dt_property_read_u32(node, "riscv,num-ids", &imsic_cfg.nr_ids) )
+    {
+        printk(XENLOG_ERR "%s: number of interrupt identities not found\n",
+               node->name);
+        return -ENOENT;
+    }
+
+    if ( (imsic_cfg.nr_ids < IMSIC_MIN_ID) ||
+         (imsic_cfg.nr_ids > IMSIC_MAX_ID) )
+    {
+        printk(XENLOG_ERR "%s: invalid number of interrupt identities\n",
+               node->name);
+        return -ENOENT;
+    }
+
+    /* Compute base address */
+    *nr_mmios = 0;
+    rc = dt_device_get_address(node, *nr_mmios, &base_addr, NULL);
+    if ( rc )
+    {
+        printk(XENLOG_ERR "%s: first MMIO resource not found: %d\n",
+               dt_node_name(node), rc);
+        return rc;
+    }
+
+    imsic_cfg.base_addr = base_addr;
+    imsic_cfg.base_addr &= ~(BIT(imsic_cfg.guest_index_bits +
+                                 imsic_cfg.hart_index_bits +
+                                 IMSIC_MMIO_PAGE_SHIFT, UL) - 1);
+    imsic_cfg.base_addr &= ~((BIT(imsic_cfg.group_index_bits, UL) - 1) <<
+                             imsic_cfg.group_index_shift);
+
+    /* Find number of MMIO register sets */
+    do {
+        (*nr_mmios)++;
+    } while ( !dt_device_get_address(node, *nr_mmios, &base_addr, NULL) );
+
+    return 0;
+}
+
+/*
+ * Initialize the imsic_cfg structure based on the IMSIC DT node.
+ *
+ * Returns 0 if initialization is successful, a negative value on failure,
+ * or IRQ_M_EXT if the IMSIC node corresponds to a machine-mode IMSIC,
+ * which should be ignored by the hypervisor.
+ */
+int __init imsic_init(const struct dt_device_node *node)
+{
+    int rc;
+    unsigned long reloff, hartid;
+    unsigned int nr_parent_irqs, index, nr_handlers = 0;
+    paddr_t base_addr;
+    unsigned int nr_mmios;
+    struct imsic_mmios *mmios;
+    struct imsic_msi *msi = NULL;
+
+    /* Parse IMSIC node */
+    rc = imsic_parse_node(node, &nr_parent_irqs, &nr_mmios);
+    /*
+     * If machine mode imsic node => ignore it.
+     * If rc < 0 => parsing of IMSIC DT node failed.
+     */
+    if ( (rc == IRQ_M_EXT) || (rc < 0) )
+        return rc;
+
+    /* Allocate MMIO resource array */
+    mmios = xvzalloc_array(struct imsic_mmios, nr_mmios);
+    if ( !mmios )
+    {
+        rc = -ENOMEM;
+        goto imsic_init_err;
+    }
+
+    msi = xvzalloc_array(struct imsic_msi, nr_parent_irqs);
+    if ( !msi )
+    {
+        rc = -ENOMEM;
+        goto imsic_init_err;
+    }
+
+    /* Check MMIO register sets */
+    for ( unsigned int i = 0; i < nr_mmios; i++ )
+    {
+        unsigned int guest_bits = imsic_cfg.guest_index_bits;
+        unsigned long expected_mmio_size =
+            IMSIC_HART_SIZE(guest_bits) * nr_parent_irqs;
+
+        rc = dt_device_get_address(node, i, &mmios[i].base_addr,
+                                   &mmios[i].size);
+        if ( rc )
+        {
+            printk(XENLOG_ERR "%s: unable to parse MMIO regset %u\n",
+                   node->name, i);
+            goto imsic_init_err;
+        }
+
+        base_addr = mmios[i].base_addr;
+        base_addr &= ~(BIT(guest_bits +
+                           imsic_cfg.hart_index_bits +
+                           IMSIC_MMIO_PAGE_SHIFT, UL) - 1);
+        base_addr &= ~((BIT(imsic_cfg.group_index_bits, UL) - 1) <<
+                       imsic_cfg.group_index_shift);
+        if ( base_addr != imsic_cfg.base_addr )
+        {
+            rc = -EINVAL;
+            printk(XENLOG_ERR "%s: address mismatch for regset %u\n",
+                   node->name, i);
+            goto imsic_init_err;
+        }
+
+        if ( mmios[i].size != expected_mmio_size )
+        {
+            rc = -EINVAL;
+            printk(XENLOG_ERR "%s: IMSIC MMIO size is incorrect %ld, "
+                   "expeced MMIO size: %ld\n", node->name, mmios[i].size,
+                   expected_mmio_size);
+            goto imsic_init_err;
+        }
+    }
+
+    /* Configure handlers for target CPUs */
+    for ( unsigned int i = 0; i < nr_parent_irqs; i++ )
+    {
+        unsigned long cpu;
+
+        rc = imsic_get_parent_hartid(node, i, &hartid);
+        if ( rc )
+        {
+            printk(XENLOG_WARNING "%s: cpu ID for parent irq%u not found\n",
+                   node->name, i);
+            continue;
+        }
+
+        cpu = hartid_to_cpuid(hartid);
+
+        if ( cpu >= num_possible_cpus() )
+        {
+            printk(XENLOG_WARNING "%s: unsupported hart ID=%#lx for parent "
+                   "irq%u\n", node->name, hartid, i);
+            continue;
+        }
+
+        /* Find MMIO location of MSI page */
+        reloff = i * BIT(imsic_cfg.guest_index_bits, UL) * IMSIC_MMIO_PAGE_SZ;
+        for ( index = 0; index < nr_mmios; index++ )
+        {
+            if ( reloff < mmios[index].size )
+                break;
+
+            /*
+             * MMIO region size may not be aligned to
+             * BIT(global->guest_index_bits) * IMSIC_MMIO_PAGE_SZ
+             * if holes are present.
+             */
+            reloff -= ROUNDUP(mmios[index].size,
+                      BIT(imsic_cfg.guest_index_bits, UL) * IMSIC_MMIO_PAGE_SZ);
+        }
+
+        if ( index == nr_mmios )
+        {
+            printk(XENLOG_WARNING "%s: MMIO not found for parent irq%u\n",
+                   node->name, i);
+            continue;
+        }
+
+        if ( !IS_ALIGNED(msi[cpu].base_addr + reloff,
+                         IMSIC_MMIO_PAGE_SZ) )
+        {
+            printk(XENLOG_WARNING "%s: MMIO address %#lx is not aligned on "
+                   "a page\n", node->name, msi[cpu].base_addr + reloff);
+            msi[cpu].offset = 0;
+            msi[cpu].base_addr = 0;
+            continue;
+        }
+
+        msi[cpu].base_addr = mmios[index].base_addr;
+        msi[cpu].offset = reloff;
+
+        nr_handlers++;
+    }
+
+    if ( !nr_handlers )
+    {
+        printk(XENLOG_ERR "%s: No CPU handlers found\n", node->name);
+        rc = -ENODEV;
+        goto imsic_init_err;
+    }
+
+    imsic_cfg.msi = msi;
+
+    XFREE(mmios);
+
+    return 0;
+
+ imsic_init_err:
+    XFREE(mmios);
+    XFREE(msi);
+
+    return rc;
+}
diff --git a/xen/arch/riscv/include/asm/imsic.h b/xen/arch/riscv/include/asm/imsic.h
new file mode 100644
index 0000000000..9cd12365b1
--- /dev/null
+++ b/xen/arch/riscv/include/asm/imsic.h
@@ -0,0 +1,55 @@
+/* SPDX-License-Identifier: MIT */
+
+/*
+ * xen/arch/riscv/include/asm/imsic.h
+ *
+ * RISC-V Incoming MSI Controller support
+ *
+ * (c) Microchip Technology Inc.
+ */
+
+#ifndef ASM_RISCV_IMSIC_H
+#define ASM_RISCV_IMSIC_H
+
+#include 
+
+#define IMSIC_MMIO_PAGE_SHIFT   12
+#define IMSIC_MMIO_PAGE_SZ      (1UL << IMSIC_MMIO_PAGE_SHIFT)
+
+#define IMSIC_MIN_ID            63
+#define IMSIC_MAX_ID            2047
+
+struct imsic_msi {
+    paddr_t base_addr;
+    unsigned long offset;
+};
+
+struct imsic_config {
+    /* Base address */
+    paddr_t base_addr;
+
+    /* Bits representing Guest index, HART index, and Group index */
+    unsigned int guest_index_bits;
+    unsigned int hart_index_bits;
+    unsigned int group_index_bits;
+    unsigned int group_index_shift;
+
+    /* IMSIC phandle */
+    unsigned int phandle;
+
+    /* Number of parent irq */
+    unsigned int nr_parent_irqs;
+
+    /* Number off interrupt identities */
+    unsigned int nr_ids;
+
+    /* MSI */
+    const struct imsic_msi *msi;
+};
+
+struct dt_device_node;
+int imsic_init(const struct dt_device_node *node);
+
+const struct imsic_config *imsic_get_config(void);
+
+#endif /* ASM_RISCV_IMSIC_H */
diff --git a/xen/arch/riscv/include/asm/smp.h b/xen/arch/riscv/include/asm/smp.h
index eb58b6576b..57c8baa06c 100644
--- a/xen/arch/riscv/include/asm/smp.h
+++ b/xen/arch/riscv/include/asm/smp.h
@@ -3,6 +3,7 @@
 #define ASM__RISCV__SMP_H
 
 #include 
+#include 
 #include 
 
 #include 
@@ -18,6 +19,18 @@ static inline unsigned long cpuid_to_hartid(unsigned long cpuid)
     return pcpu_info[cpuid].hart_id;
 }
 
+static inline unsigned int hartid_to_cpuid(unsigned long hartid)
+{
+    for ( unsigned int cpuid = 0; cpuid < ARRAY_SIZE(pcpu_info); cpuid++ )
+    {
+        if ( hartid == cpuid_to_hartid(cpuid) )
+            return cpuid;
+    }
+
+    /* hartid isn't valid for some reason */
+    return NR_CPUS;
+}
+
 static inline void set_cpuid_to_hartid(unsigned long cpuid,
                                        unsigned long hartid)
 {
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 15:59:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 15:59:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007087.1386403 (Exim 4.92)
	(envelope-from )
	id 1uNCzz-0008Ft-TA; Thu, 05 Jun 2025 15:59:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007087.1386403; Thu, 05 Jun 2025 15:59: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 1uNCzz-0008Fh-Pg; Thu, 05 Jun 2025 15:59:23 +0000
Received: by outflank-mailman (input) for mailman id 1007087;
 Thu, 05 Jun 2025 15:59: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 1uNCzy-00071f-GP
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 15:59:22 +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 0aeaae45-4226-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 17:59:20 +0200 (CEST)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-606fdbd20afso2217330a12.1
 for ; Thu, 05 Jun 2025 08:59:20 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-60566c2aba9sm10443034a12.2.2025.06.05.08.59.18
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 08:59:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0aeaae45-4226-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749139160; x=1749743960; darn=lists.xenproject.org;
        h=content-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=sllje9we4dPE74YkPYuoGlvOyvramKxYrsh4yQeHi50=;
        b=DIujADFsC81OAWpHPdmzBoCiGOTk/db1tpd2hRbcsxNovXZx86xidFJwaXyC2abkzQ
         ka+mSWKvR9vUyynpZm4Priwmoy/HiIsGtFoo1ucw7u0nQT19yiIXTFDCnDcrz2+H4wPg
         dUqCgu+6A9IYtiY8c0Z8UkWQlfRTivsU/bYgrVNbzQ6kwDyXT2SMqIdgGgRPg7E22GKB
         7nUZ1hOLJj5Pr0LMdNoYNf0pYHSXoge/Z1CaiEhfnRkK3WrrSXsw1lMW7GsYDVlwUkMA
         eXZo1gZtZK0Yqj+kUAaVcAf1IaOK+WN8+DOUNqfl21Vz0oOHBZ1dZQV7bELCViOheAqM
         lBfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749139160; x=1749743960;
        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=sllje9we4dPE74YkPYuoGlvOyvramKxYrsh4yQeHi50=;
        b=vTbTK7CgFqEeXOTn8f6oot8LIo4QAiq7b8tBNKUQkAWVHdJezN4qycn4ub3zhPAaiv
         8XNSH+NhkbDHGanLwmjXzuPsBu7LJzyTSX+tNClUBSvLS01eyCdGv8bhvpl7G1GSfpfK
         6WDjhTF6Uhncn9LFJ2rpTtlX0uJyzJMbRJCn+yQR1FAZ42OvEE/AupU1Vc8OLQUsq1xx
         3p89rwbUjd91TN7HkWq3An9fa8CWKSwjg+wIQ3uEs5poilyOw4Qt2YE2vKIYGUAUkKaj
         zTm4j9zxY7ip9h6NEhn/MhTSznjxwe0aDpW4tcZpwbCsrkfmfzJmm+AcZ5EaVDpbNsTg
         eTWQ==
X-Gm-Message-State: AOJu0YxWd+CQTcDyR1tm3cvhzApyXu0Hrbt1huvIRX7ulqeMILemHBRB
	b5eIQHW1ijmWoelNtxCFt2CFLzIvzn5PDbBNowMG5ZYD2H8T2FfawlwZxXoW7A==
X-Gm-Gg: ASbGncuAHZDwV1JXVwBZZYI0P0BuHYLypH7bwXjQLMLhBfrGDUtWIuTAyJhpyV8hFhP
	x9LY4/ayYbTNrnAFP+F4LEHTBXVKD1bFcqPfLsJWfUSkvw88wRB0S+f1u/YT6xe5Rx4+kZ1sYty
	RCB5LuXJQHGHsz2UROouXBeDFovg86oe5rcmrzs15b+/N/HfbKto/YsGYb2snLmvezlMGixfpOu
	NYIwv/u1KSxtGfUy0uNylHvJ+HJYLyb52QEaxsNZfq2ttU+B3o+60QgMgRR7PbJwHcmTLb6of9w
	dxXMcxKOGKjOn6nfzOHb4llMVBOPy3iZNcFFhsx3d+G6H94gjPrUDCBWNtbCNaA4h4dbqxyYZi/
	3NyxESzIByiM2LMyKOw==
X-Google-Smtp-Source: AGHT+IEDl11Un6GzmqN7TowFArQN2doR3NmYj94vI9Uu0yfDeMYFn2yguIWN6w3JKktwr32STLofhw==
X-Received: by 2002:a05:6402:35d6:b0:607:6097:2f9c with SMTP id 4fb4d7f45d1cf-607609731a4mr421983a12.21.1749139160070;
        Thu, 05 Jun 2025 08:59:20 -0700 (PDT)
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 ,
	Romain Caritey 
Subject: [PATCH v4 5/9] xen/riscv: introduce intc_init() and helpers
Date: Thu,  5 Jun 2025 17:59:01 +0200
Message-ID: <5b18180f1cae0bd29aac6e024d53a180362384c2.1749121437.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Introduce intc_init() to initialize the interrupt controller using the
registered hardware ops.
Also add intc_route_irq_to_xen() to route IRQs to Xen, with support for
setting IRQ type and priority via new internal helpers intc_set_irq_type()
and intc_set_irq_priority().

Call intc_init() to do basic initialization steps for APLIC and IMSIC.

Co-developed-by: Romain Caritey 
Signed-off-by: Oleksii Kurochko 
Acked-by: Jan Beulich 
---
Changes in V4:
 - Add Acked-by: Jan Beulich .
---
Changes in V3:
 - Drop ASSERIT(intc_hw_ops) in intc_init().
 - Drop ASSERT(intc_hw_ops) in intc_set_irq_type() and
   intc_set_irq_priority() as intc_init() will be called first and so if it
   won't crash, then intc_hw_ops is registered.
---
Changes in V2:
 - This patch was part of "xen/riscv: Introduce intc_hw_operations abstraction"
   and splitted to have ability to merge patch "xen/riscv: initialize interrupt controller"
   to the current patch (where intc_init() call is actually introduced).
 - Add checks of that callbacks aren't set to NULL in intc_set_irq_priority()
   and intc_set_irq_type().
 - add num_irqs member to struct intc_info as it is used now in
   intc_route_irq_to_xen().
 - Add ASSERT(spin_is_locked(&desc->lock)) to intc_set_irq_priority() in
   the case this function will be called outside intc_route_irq_to_xen().
---
 xen/arch/riscv/include/asm/intc.h |  4 +++
 xen/arch/riscv/intc.c             | 41 +++++++++++++++++++++++++++++++
 xen/arch/riscv/setup.c            |  2 ++
 3 files changed, 47 insertions(+)

diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h
index 3c4b211f58..a11b7aa55e 100644
--- a/xen/arch/riscv/include/asm/intc.h
+++ b/xen/arch/riscv/include/asm/intc.h
@@ -43,4 +43,8 @@ void intc_preinit(void);
 
 void register_intc_ops(const struct intc_hw_operations *ops);
 
+void intc_init(void);
+
+void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority);
+
 #endif /* ASM__RISCV__INTERRUPT_CONTOLLER_H */
diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c
index 1ecd651bf3..f2823267a9 100644
--- a/xen/arch/riscv/intc.c
+++ b/xen/arch/riscv/intc.c
@@ -1,9 +1,12 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
+#include 
 
 #include 
 
@@ -21,3 +24,41 @@ void __init intc_preinit(void)
     else
         panic("ACPI interrupt controller preinit() isn't implemented\n");
 }
+
+void __init intc_init(void)
+{
+    if ( intc_hw_ops->init() )
+        panic("Failed to initialize the interrupt controller drivers\n");
+}
+
+/* desc->irq needs to be disabled before calling this function */
+static void intc_set_irq_type(struct irq_desc *desc, unsigned int type)
+{
+    ASSERT(desc->status & IRQ_DISABLED);
+    ASSERT(spin_is_locked(&desc->lock));
+    ASSERT(type != IRQ_TYPE_INVALID);
+
+    if ( intc_hw_ops->set_irq_type )
+        intc_hw_ops->set_irq_type(desc, type);
+}
+
+static void intc_set_irq_priority(struct irq_desc *desc, unsigned int priority)
+{
+    ASSERT(spin_is_locked(&desc->lock));
+
+    if ( intc_hw_ops->set_irq_priority )
+        intc_hw_ops->set_irq_priority(desc, priority);
+}
+
+void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority)
+{
+    ASSERT(desc->status & IRQ_DISABLED);
+    ASSERT(spin_is_locked(&desc->lock));
+    /* Can't route interrupts that don't exist */
+    ASSERT(intc_hw_ops && desc->irq < intc_hw_ops->info->num_irqs);
+
+    desc->handler = intc_hw_ops->host_irq_type;
+
+    intc_set_irq_type(desc, desc->arch.type);
+    intc_set_irq_priority(desc, priority);
+}
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 8bcd19218d..0e7398159c 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -134,6 +134,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
 
     intc_preinit();
 
+    intc_init();
+
     printk("All set up\n");
 
     machine_halt();
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 15:59:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 15:59:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007088.1386411 (Exim 4.92)
	(envelope-from )
	id 1uND01-0008V1-8K; Thu, 05 Jun 2025 15:59:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007088.1386411; Thu, 05 Jun 2025 15:59: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 1uND01-0008UN-2R; Thu, 05 Jun 2025 15:59:25 +0000
Received: by outflank-mailman (input) for mailman id 1007088;
 Thu, 05 Jun 2025 15:59: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 1uND00-00071f-0C
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 15:59:24 +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 0babb500-4226-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 17:59:22 +0200 (CEST)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-6049431b409so1844609a12.3
 for ; Thu, 05 Jun 2025 08:59:22 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-60566c2aba9sm10443034a12.2.2025.06.05.08.59.20
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 08:59:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0babb500-4226-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749139161; x=1749743961; darn=lists.xenproject.org;
        h=content-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=zyGDNJ//E8KSJT7z191vBjEkNxWBQsjmNlsiyAJcTsg=;
        b=lEvxqea2bOQRjcbokOdqZ/A/O2QGPszshX8fMc/DYDZVM7DKUq5YXPPjBorYP4T/6Q
         OwCPPLeU2X6REIVyQ1fcZyWnGd2lD+5/EdIqYjV+6eawJZqz0m59/nefir+ijQ6jdnDg
         Wz8CBQ8yuZY3LvL0ZOpGbZeAVk3Sy8wjfvPG/bS5hnEmx40Nzd3XAPTY8a1z4qG9AnmD
         RdV0b4C6p5ezFda4FQOZTMvSRGkuRs/LHKfEpkZVo2jyO/a+5dJONSWRfWB2DqxMrnhJ
         W2OMh+I5kH+LD6MhV9ybtB0DjcywKY9k0JdZXFxLCSf1/VVU+5KIiP8mJhep3wv+dHvt
         mLjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749139161; x=1749743961;
        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=zyGDNJ//E8KSJT7z191vBjEkNxWBQsjmNlsiyAJcTsg=;
        b=h58UoK8h7Iv1CQH/7zXIBIwBS7qJR17q5Dx1r2EVgJfhEISStj3f1+AfO5k/izf5V/
         UdP6fTjlmaedmBmAh3LXkVrcVwH8Va3T28J4nloIjFnXuw5TCYbLd0/IUDk7RPV3TOh9
         0QQ6Wty5J2KkbGFHtgOC0VGNzkACjwxkw+m4grgwia30qL18/jPxHddKxNMaIR6S+mbE
         nK6q3cUzEo9i5xWN9GH8YwQZw/KtGR4077VF/ShmwrASExeO0noRPZjRo/3zdL4ObHHO
         /hDPo5VQAZhSskW2hpMbYPrhpkc7jTyQVDAOX6ng2khT/DofYQ0v2cm/5gBqgGfJZ4nf
         BSzg==
X-Gm-Message-State: AOJu0YyvlK6GRaPU3uayyCOZ6cFyUpNyAIiag476L75IfmJADtidpfim
	NrZVNDKZlyAbT2lA/5cCny3lMP9MiebBdbbs6lf0OeqZAZnxI22LgST9oAxHew==
X-Gm-Gg: ASbGnctTE8ZS1AXd2bxEnndy6/keiDMsWOxZC+ndYaGlaCnGeN38/ntQ5sNYwQUutwq
	FVWxIPAfl20qfhFDQ9vWEPNx3VV1n35Vi9EgcqJKgoOa+V7rRHfZ81ZuriP1j5gXd6oj/Td3xJM
	bXOM9L9MrBQLpNoFELV/KbXEQleiQl615EDlv0ijAvpg5cIc2dAbZTP1b16RUYQzLws1eQVljxN
	kzb0imqFNAhsgjCbLSc4Wgzp+9xkPiik7PiwKBzdkkRblb4hHhsHQTsVSJTL4rKfrP+PlLou2ht
	fhpFBhw32iwK3DiKZhyTf99cLzzhLcqLLmW01DOeeTNPxjGXf3ZxLEGW8GCE4i8V6rrhGuJTwgq
	ZKZD+NqEKhEDI2gvDWpXW3ld+YXcl
X-Google-Smtp-Source: AGHT+IFZRrfstBxC/0pL5sboDJ/l0yCvSfoObRdybF3IAtqmlRx7URjZ717qan4mxMo0pkN79QWl+g==
X-Received: by 2002:a05:6402:4303:b0:607:f1c:bfed with SMTP id 4fb4d7f45d1cf-6070f1cc298mr4502670a12.12.1749139161204;
        Thu, 05 Jun 2025 08:59:21 -0700 (PDT)
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 ,
	Romain Caritey 
Subject: [PATCH v4 6/9] xen/riscv: implementation of aplic and imsic operations
Date: Thu,  5 Jun 2025 17:59:02 +0200
Message-ID: <2135173f5ca0e43b54e97052c221ba04c25f830c.1749121437.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=all
Content-Transfer-Encoding: 8bit

Introduce interrupt controller descriptor for host APLIC to describe
the low-lovel hardare. It includes implementation of the following functions:
 - aplic_irq_startup()
 - aplic_irq_enable()
 - aplic_irq_disable()
 - aplic_set_irq_affinity()

As APLIC is used in MSI mode it requires to enable/disable interrupts not
only for APLIC but also for IMSIC. Thereby for the purpose of
aplic_irq_{enable,disable}() it is introduced imsic_irq_{enable,disable)().

For the purpose of aplic_set_irq_affinity() aplic_get_cpu_from_mask() is
introduced to get hart id.

Also, introduce additional interrupt controller h/w operations and
host_irq_type for APLIC:
 - aplic_host_irq_type

Patch is based on the code from [1].

[1] https://gitlab.com/xen-project/people/olkur/xen/-/commit/7390e2365828b83e27ead56b03114a56e3699dd5

Co-developed-by: Romain Caritey 
Signed-off-by: Oleksii Kurochko 
---
Changes in V4:
 - Code style fixes.
 - Add cf_check for hook functions.
 - Use min() macros instead of open-coding it in imsic_local_eix_update().
 - Update the comment above ASSERT() in imsic_irq_disable():
   s/aplic_irq_enable/aplic_irq_disable.
 - Add an explanatory comment above initializing of hhxs in
   aplic_set_irq_affinity().
---
Changes in V3:
 - Update the lock above lock member of struct aplic_priv and imsic_config struct.
 - Use spin_{un}lock() in aplic_irq_{enable,disable}() as it is IRQ-safe.
   Also drop local variable 'flags'.
 - Add ASSERT(spin_is_locked(&desc->lock)) to aplic_set_irq_affinity() and
   aplic_set_irq_type().
 - Use an initializer instead of spin_lock_init() for aplic.lock.
 - Drop "(l)" in the comment in imsic_irq_enable() as it doesn't point to
   anything.
 - Use ASSERT(!local_irq_is_enabled()) + spin_lock() in imsic_irq_{enable,disable}().
 - Use an initializer instead of spin_lock_init() for imsic_config.lock.
---
Changes in V2:
 - Move imsic_ids_local_delivery() and connected to it parts to the current
   patch to fix compilation issue. Also, add __init for
   imsic_ids_local_delivery().
 - Move introduction of aplic_set_irq_type() and aplic_set_irq_priority()
   to patch [PATCH v1 12/14] xen/riscv: implement setup_irq() where they
   really started to be used.
 - Update the commit message.
 - Drop is_used variable for imsic_cfg and use (aplic.regs->domaincfg & APLIC_DOMAINCFG_DM) instead.
 - Use writel() to write to APLIC regs.
 - Drop aplic_irq_shutdown() and use aplic_irq_disable explicitly.
 - Drop local variable cpu in aplic_get_cpu_from_mask():
   Use cpu_online_map instead of cpu_possible_map.
   Remame possible_mask to mask.
 - Code style fixes.
 - Move spin_lock(&aplic.lock) down before write to the register in aplic_set_irq_affinity.
 - Make aplic_host_irq_type const.
 - imsic_local_eix_update() updates:
   - move unsigned long isel, ireg; to inner loop.
   - Drop unnecessary parentheses.
   - Optimize inner loop of ireg's setting.
 - Drop aplic_irq_ack() and aplic_host_irq_end() as they do nothing.
 - Rename s/hwirq/irq.
 - Add explanatory comment to imsic_irq_enable() about why there is not -1 for IRQ in
   comparison with APLIC's sourcecfg.
 - Use IMSIC_MMIO_PAGE_SHIFT instead of constant 12 in aplic_set_irq_affinity().
 - s/aplic_host_irq_type/aplic_xen_irq_type
 - Drop set/clear of IRQ_DISABLED bit in aplic_{enable,disable}() as guest will always
   first request an interrupt and then only an interrupt will be enabled.
   (for example, in Arm, the physical interrupts would be enabled when the
   interrupt is initially routed. This could lead to problem because the guest
   will usually boot with interrupt disabled.)
---
 xen/arch/riscv/aplic-priv.h        |   4 +
 xen/arch/riscv/aplic.c             | 123 ++++++++++++++++++++++++++++-
 xen/arch/riscv/imsic.c             | 122 +++++++++++++++++++++++++++-
 xen/arch/riscv/include/asm/aplic.h |   2 +
 xen/arch/riscv/include/asm/imsic.h |  18 +++++
 5 files changed, 267 insertions(+), 2 deletions(-)

diff --git a/xen/arch/riscv/aplic-priv.h b/xen/arch/riscv/aplic-priv.h
index 7ed1ab8f4b..d377a7ac67 100644
--- a/xen/arch/riscv/aplic-priv.h
+++ b/xen/arch/riscv/aplic-priv.h
@@ -14,6 +14,7 @@
 #ifndef ASM_RISCV_PRIV_APLIC_H
 #define ASM_RISCV_PRIV_APLIC_H
 
+#include 
 #include 
 
 #include 
@@ -27,6 +28,9 @@ struct aplic_priv {
     /* registers */
     volatile struct aplic_regs __iomem *regs;
 
+    /* lock to protect access to APLIC's registers */
+    spinlock_t lock;
+
     /* imsic configuration */
     const struct imsic_config *imsic_cfg;
 };
diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c
index 04964dc998..7d2a1ea7aa 100644
--- a/xen/arch/riscv/aplic.c
+++ b/xen/arch/riscv/aplic.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -23,11 +24,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define APLIC_DEFAULT_PRIORITY  1
 
-static struct aplic_priv aplic;
+static struct aplic_priv aplic = {
+    .lock = SPIN_LOCK_UNLOCKED,
+};
 
 static struct intc_info __ro_after_init aplic_info = {
     .hw_version = INTC_APLIC,
@@ -117,9 +121,126 @@ static int __init cf_check aplic_init(void)
     return 0;
 }
 
+static void cf_check aplic_irq_enable(struct irq_desc *desc)
+{
+    /*
+     * TODO: Currently, APLIC is supported only with MSI interrupts.
+     *       If APLIC without MSI interrupts is required in the future,
+     *       this function will need to be updated accordingly.
+     */
+    ASSERT(readl(&aplic.regs->domaincfg) & APLIC_DOMAINCFG_DM);
+
+    ASSERT(spin_is_locked(&desc->lock));
+
+    spin_lock(&aplic.lock);
+
+    /* Enable interrupt in IMSIC */
+    imsic_irq_enable(desc->irq);
+
+    /* Enable interrupt in APLIC */
+    writel(desc->irq, &aplic.regs->setienum);
+
+    spin_unlock(&aplic.lock);
+}
+
+static void cf_check aplic_irq_disable(struct irq_desc *desc)
+{
+    /*
+     * TODO: Currently, APLIC is supported only with MSI interrupts.
+     *       If APLIC without MSI interrupts is required in the future,
+     *       this function will need to be updated accordingly.
+     */
+    ASSERT(readl(&aplic.regs->domaincfg) & APLIC_DOMAINCFG_DM);
+
+    ASSERT(spin_is_locked(&desc->lock));
+
+    spin_lock(&aplic.lock);
+
+    /* disable interrupt in APLIC */
+    writel(desc->irq, &aplic.regs->clrienum);
+
+    /* disable interrupt in IMSIC */
+    imsic_irq_disable(desc->irq);
+
+    spin_unlock(&aplic.lock);
+}
+
+static unsigned int cf_check aplic_irq_startup(struct irq_desc *desc)
+{
+    aplic_irq_enable(desc);
+
+    return 0;
+}
+
+static unsigned int aplic_get_cpu_from_mask(const cpumask_t *cpumask)
+{
+    cpumask_t mask;
+
+    cpumask_and(&mask, cpumask, &cpu_online_map);
+
+    return cpumask_any(&mask);
+}
+
+static void cf_check aplic_set_irq_affinity(struct irq_desc *desc, const cpumask_t *mask)
+{
+    unsigned int cpu;
+    uint64_t group_index, base_ppn;
+    uint32_t hhxw, lhxw, hhxs, value;
+    const struct imsic_config *imsic = aplic.imsic_cfg;
+
+    /*
+     * TODO: Currently, APLIC is supported only with MSI interrupts.
+     *       If APLIC without MSI interrupts is required in the future,
+     *       this function will need to be updated accordingly.
+     */
+    ASSERT(readl(&aplic.regs->domaincfg) & APLIC_DOMAINCFG_DM);
+
+    ASSERT(!cpumask_empty(mask));
+
+    ASSERT(spin_is_locked(&desc->lock));
+
+    cpu = cpuid_to_hartid(aplic_get_cpu_from_mask(mask));
+    hhxw = imsic->group_index_bits;
+    lhxw = imsic->hart_index_bits;
+    /*
+     * Although this variable is used only once in the calculation of
+     * group_index, and it might seem that hhxs could be defined as:
+     *   hhxs = imsic->group_index_shift - IMSIC_MMIO_PAGE_SHIFT;
+     * and then the addition of IMSIC_MMIO_PAGE_SHIFT could be omitted
+     * when calculating the group index.
+     * It was done intentionally this way to follow the formula from
+     * the AIA specification for calculating the MSI address.
+     */
+    hhxs = imsic->group_index_shift - IMSIC_MMIO_PAGE_SHIFT * 2;
+    base_ppn = imsic->msi[cpu].base_addr >> IMSIC_MMIO_PAGE_SHIFT;
+
+    /* Update hart and EEID in the target register */
+    group_index = (base_ppn >> (hhxs + IMSIC_MMIO_PAGE_SHIFT)) &
+                  (BIT(hhxw, UL) - 1);
+    value = desc->irq;
+    value |= cpu << APLIC_TARGET_HART_IDX_SHIFT;
+    value |= group_index << (lhxw + APLIC_TARGET_HART_IDX_SHIFT);
+
+    spin_lock(&aplic.lock);
+
+    writel(value, &aplic.regs->target[desc->irq - 1]);
+
+    spin_unlock(&aplic.lock);
+}
+
+static const hw_irq_controller aplic_xen_irq_type = {
+    .typename     = "aplic",
+    .startup      = aplic_irq_startup,
+    .shutdown     = aplic_irq_disable,
+    .enable       = aplic_irq_enable,
+    .disable      = aplic_irq_disable,
+    .set_affinity = aplic_set_irq_affinity,
+};
+
 static const struct intc_hw_operations aplic_ops = {
     .info                = &aplic_info,
     .init                = aplic_init,
+    .host_irq_type       = &aplic_xen_irq_type,
 };
 
 static int cf_check aplic_irq_xlate(const uint32_t *intspec,
diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c
index 5006146cb8..3fbc8243b1 100644
--- a/xen/arch/riscv/imsic.c
+++ b/xen/arch/riscv/imsic.c
@@ -29,7 +29,124 @@ struct imsic_mmios {
     unsigned long size;
 };
 
-static struct imsic_config imsic_cfg;
+static struct imsic_config imsic_cfg = {
+    .lock = SPIN_LOCK_UNLOCKED,
+};
+
+#define IMSIC_DISABLE_EIDELIVERY    0
+#define IMSIC_ENABLE_EIDELIVERY     1
+#define IMSIC_DISABLE_EITHRESHOLD   1
+#define IMSIC_ENABLE_EITHRESHOLD    0
+
+#define imsic_csr_write(c, v)   \
+do {                            \
+    csr_write(CSR_SISELECT, c); \
+    csr_write(CSR_SIREG, v);    \
+} while (0)
+
+#define imsic_csr_set(c, v)     \
+do {                            \
+    csr_write(CSR_SISELECT, c); \
+    csr_set(CSR_SIREG, v);      \
+} while (0)
+
+#define imsic_csr_clear(c, v)   \
+do {                            \
+    csr_write(CSR_SISELECT, c); \
+    csr_clear(CSR_SIREG, v);    \
+} while (0)
+
+void __init imsic_ids_local_delivery(bool enable)
+{
+    if ( enable )
+    {
+        imsic_csr_write(IMSIC_EITHRESHOLD, IMSIC_ENABLE_EITHRESHOLD);
+        imsic_csr_write(IMSIC_EIDELIVERY, IMSIC_ENABLE_EIDELIVERY);
+    }
+    else
+    {
+        imsic_csr_write(IMSIC_EITHRESHOLD, IMSIC_DISABLE_EITHRESHOLD);
+        imsic_csr_write(IMSIC_EIDELIVERY, IMSIC_DISABLE_EIDELIVERY);
+    }
+}
+
+static void imsic_local_eix_update(unsigned long base_id, unsigned long num_id,
+                                   bool pend, bool val)
+{
+    unsigned long id = base_id, last_id = base_id + num_id;
+
+    while ( id < last_id )
+    {
+        unsigned long isel, ireg;
+        unsigned long start_id = id & (__riscv_xlen - 1);
+        unsigned long chunk = __riscv_xlen - start_id;
+        unsigned long count = min(last_id - id, chunk);
+
+        isel = id / __riscv_xlen;
+        isel *= __riscv_xlen / IMSIC_EIPx_BITS;
+        isel += pend ? IMSIC_EIP0 : IMSIC_EIE0;
+
+        ireg = GENMASK(start_id + count - 1, start_id);
+
+        id += count;
+
+        if ( val )
+            imsic_csr_set(isel, ireg);
+        else
+            imsic_csr_clear(isel, ireg);
+    }
+}
+
+void imsic_irq_enable(unsigned int irq)
+{
+    /*
+    * The only caller of imsic_irq_enable() is aplic_irq_enable(), which
+    * already runs with IRQs disabled. Therefore, there's no need to use
+    * spin_lock_irqsave() in this function.
+    *
+    * This ASSERT is added as a safeguard: if imsic_irq_enable() is ever
+    * called from a context where IRQs are not disabled,
+    * spin_lock_irqsave() should be used instead of spin_lock().
+    */
+    ASSERT(!local_irq_is_enabled());
+
+    spin_lock(&imsic_cfg.lock);
+    /*
+     * There is no irq - 1 here (look at aplic_set_irq_type()) because:
+     * From the spec:
+     *   When an interrupt file supports distinct interrupt identities,
+     *   valid identity numbers are between 1 and inclusive. The identity
+     *   numbers within this range are said to be implemented by the interrupt
+     *   file; numbers outside this range are not implemented. The number zero
+     *   is never a valid interrupt identity.
+     *   ...
+     *   Bit positions in a valid eiek register that don’t correspond to a
+     *   supported interrupt identity (such as bit 0 of eie0) are read-only zeros.
+     *
+     * So in EIx registers interrupt i corresponds to bit i in comparison wiht
+     * APLIC's sourcecfg which starts from 0.
+     */
+    imsic_local_eix_update(irq, 1, false, true);
+    spin_unlock(&imsic_cfg.lock);
+}
+
+void imsic_irq_disable(unsigned int irq)
+{
+   /*
+    * The only caller of imsic_irq_disable() is aplic_irq_disable(), which
+    * already runs with IRQs disabled. Therefore, there's no need to use
+    * spin_lock_irqsave() in this function.
+    *
+    * This ASSERT is added as a safeguard: if imsic_irq_disable() is ever
+    * called from a context where IRQs are not disabled,
+    * spin_lock_irqsave() should be used instead of spin_lock().
+    */
+    ASSERT(!local_irq_is_enabled());
+
+    spin_lock(&imsic_cfg.lock);
+    imsic_local_eix_update(irq, 1, false, false);
+    spin_unlock(&imsic_cfg.lock);
+}
 
 /* Callers aren't intended to changed imsic_cfg so return const. */
 const struct imsic_config *imsic_get_config(void)
@@ -344,6 +461,9 @@ int __init imsic_init(const struct dt_device_node *node)
         goto imsic_init_err;
     }
 
+    /* Enable local interrupt delivery */
+    imsic_ids_local_delivery(true);
+
     imsic_cfg.msi = msi;
 
     XFREE(mmios);
diff --git a/xen/arch/riscv/include/asm/aplic.h b/xen/arch/riscv/include/asm/aplic.h
index fea95d4369..c3f00238f2 100644
--- a/xen/arch/riscv/include/asm/aplic.h
+++ b/xen/arch/riscv/include/asm/aplic.h
@@ -18,6 +18,8 @@
 #define APLIC_DOMAINCFG_IE      BIT(8, U)
 #define APLIC_DOMAINCFG_DM      BIT(2, U)
 
+#define APLIC_TARGET_HART_IDX_SHIFT 18
+
 struct aplic_regs {
     uint32_t domaincfg;
     uint32_t sourcecfg[1023];
diff --git a/xen/arch/riscv/include/asm/imsic.h b/xen/arch/riscv/include/asm/imsic.h
index 9cd12365b1..378e49d933 100644
--- a/xen/arch/riscv/include/asm/imsic.h
+++ b/xen/arch/riscv/include/asm/imsic.h
@@ -11,6 +11,7 @@
 #ifndef ASM_RISCV_IMSIC_H
 #define ASM_RISCV_IMSIC_H
 
+#include 
 #include 
 
 #define IMSIC_MMIO_PAGE_SHIFT   12
@@ -19,6 +20,15 @@
 #define IMSIC_MIN_ID            63
 #define IMSIC_MAX_ID            2047
 
+#define IMSIC_EIDELIVERY        0x70
+
+#define IMSIC_EITHRESHOLD       0x72
+
+#define IMSIC_EIP0              0x80
+#define IMSIC_EIPx_BITS         32
+
+#define IMSIC_EIE0              0xC0
+
 struct imsic_msi {
     paddr_t base_addr;
     unsigned long offset;
@@ -45,6 +55,9 @@ struct imsic_config {
 
     /* MSI */
     const struct imsic_msi *msi;
+
+    /* Lock to protect access to IMSIC's stuff */
+    spinlock_t lock;
 };
 
 struct dt_device_node;
@@ -52,4 +65,9 @@ int imsic_init(const struct dt_device_node *node);
 
 const struct imsic_config *imsic_get_config(void);
 
+void imsic_irq_enable(unsigned int hwirq);
+void imsic_irq_disable(unsigned int hwirq);
+
+void imsic_ids_local_delivery(bool enable);
+
 #endif /* ASM_RISCV_IMSIC_H */
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 15:59:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 15:59:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007090.1386423 (Exim 4.92)
	(envelope-from )
	id 1uND02-0000NO-Ls; Thu, 05 Jun 2025 15:59:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007090.1386423; Thu, 05 Jun 2025 15:59:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uND02-0000Mw-Gn; Thu, 05 Jun 2025 15:59:26 +0000
Received: by outflank-mailman (input) for mailman id 1007090;
 Thu, 05 Jun 2025 15:59: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 1uND00-00071f-Qe
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 15:59:24 +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 0c3ffca9-4226-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 17:59:23 +0200 (CEST)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-602c3f113bbso2161628a12.0
 for ; Thu, 05 Jun 2025 08:59:23 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-60566c2aba9sm10443034a12.2.2025.06.05.08.59.21
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 08:59:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0c3ffca9-4226-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749139162; x=1749743962; darn=lists.xenproject.org;
        h=content-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=kv20kch9bDGD4TNotY+8eQw9KowyHoxlqMsSxAa/+hA=;
        b=WAVxSHJw+ht2HSYL5jXSZ0FAHG26FbX7Koi1MdjeDHQo1xhPAAsGJSgKhyqhN8l4Wc
         dJiuw8uDlJBaJbIEHjtZyWyGegHo9xMWeGGcjzOcukjbJQ2DSeDh/46KbFCQyHGhqYCY
         EC2SYQzHIksRWyB4WtDbVR0LwnipmAu34E1eEXiOA1deVGuYRWsujSobxcf+MdAJ7G8/
         gHbIybaVcKkO1IZJyFHg/IIcDyhs5iHjUg5a94pJWgTGM7bFqU45pFq8TIb2l8xSEcs0
         jOqlWqaOD2QbdszOzL4YsZmGfXWvHXt0wviFrsSMsdiDENYj4r88FKMTtO2b9CxeU3NG
         T79A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749139162; x=1749743962;
        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=kv20kch9bDGD4TNotY+8eQw9KowyHoxlqMsSxAa/+hA=;
        b=sKRd1nc3EbjNx9Ise3tFL1S7aqUvfOSA881mPKkDuG9UXYHdkRzM9a54zI0HJhgI9o
         GfX85f9V9jM0aPtBbfoR63v4AF1mxCmDfavYWQTf8QpxPlcxjguGrz5W3A8ZFDWm8+5K
         XhQFAd+nWkI93l0WodLs67L29c3At82T4Fb47tVgwpkLl6rwmnOrOcRoTNyZMPwFj98s
         T3ljeTbUgxPBunYjVPpysreZ/kmI9umAytTO5L6COObPkHGDfdMTAJVDa16bdUiVS5eF
         LJwYWsmwDasUuUDwHtYUsWTBeLIYBfeXC7CHCcpBS/nQ9Pfxqp5fb80sar7FMUxEjt6P
         JfGw==
X-Gm-Message-State: AOJu0Yy6PLPGJo1e08jhb5GmZPLJpzh2QLkXTFBhi3D0AZ9Tnpo4yfeT
	qka3X5Sc9e0QYA9+jPlbYxA/bMospEOIiFf6qrbH2Ad5US2o8ZxCCAsYVL/rMA==
X-Gm-Gg: ASbGncuTEd904Ed4rpAnrG10e/vb0TU7qc6oO9pkVpNgg9KEiOcqFNn7Zyqqhe7S8o4
	pkDcU8038g/GDDKWVxXt3Xf760xLK1tjx4HEQNtFvn1fjJ52IvTZBKraq/N9h1xQGCfrDKNPl0t
	o5n1o8VwN4PCJ8kC/5h1LWXqOFAefLmEGe5cKXMCUDW7ocfcIv9lVKBhlaVGIWLCUySOjnnZ2pC
	kQAO/6rsO3XdBVXW/UMRg4TzC8cHkCUusgzIh6skKO9uhj901lxZV5fnYl1CKc4v4l96cFVvsgR
	j/MVz5sHQILUZY06fMgXmkhhdwVhWhCBgBJxvpxwwaj1ANiElEQ/zocEeQdrrIphoi6jtzI2dAC
	0l2ZKHG1eF4MLZovFpFCp2N5NbW64
X-Google-Smtp-Source: AGHT+IFRa/H01EBeyohHhNxBqX5VxipZYGxyxs5l0TWWU+GFwSXjhsFtNbIO+zOEIcjCIhesJBtVsQ==
X-Received: by 2002:a05:6402:2707:b0:606:b997:ae58 with SMTP id 4fb4d7f45d1cf-606e967a348mr6854304a12.8.1749139162237;
        Thu, 05 Jun 2025 08:59:22 -0700 (PDT)
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 ,
	Romain Caritey 
Subject: [PATCH v4 7/9] xen/riscv: add external interrupt handling for hypervisor mode
Date: Thu,  5 Jun 2025 17:59:03 +0200
Message-ID: <583dd5d3e87230961f7f895f1abf5702cda677bb.1749121437.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=all
Content-Transfer-Encoding: 8bit

Implement functions necessarry to have working external interrupts in
hypervisor mode. The following changes are done:
  - Add a common function intc_handle_external_irq() to call APLIC specific
    function to handle an interrupt.
  - Update do_trap() function to handle IRQ_S_EXT case; add the check to catch
    case when cause of trap is an interrupt.
  - Add handle_interrrupt() member to intc_hw_operations structure.
  - Enable local interrupt delivery for IMSIC by calling of
    imsic_ids_local_delivery() in imsic_init(); additionally introduce helper
    imsic_csr_write() to update IMSIC_EITHRESHOLD and IMSIC_EITHRESHOLD.
  - Enable hypervisor external interrupts.
  - Implement aplic_handler_interrupt() and use it to init ->handle_interrupt
    member of intc_hw_operations for APLIC.
  - Add implementation of do_IRQ() to dispatch the interrupt.

The current patch is based on the code from [1].

[1] https://gitlab.com/xen-project/people/olkur/xen/-/commit/7390e2365828b83e27ead56b03114a56e3699dd5

Co-developed-by: Romain Caritey 
Signed-off-by: Oleksii Kurochko 
Acked-by: Jan Beulich 
---
Changes in V4:
 - Nothing changed. Only rebase.
---
Changes in V3:
 - Add ASSERT(spin_is_locked(&desc->lock)) to aplic_set_irq_type().
 - Fix code style for switch () in aplic_set_irq_type().
 - Drop fallthrough between "case IRQ_TYPE_NONE: case IRQ_TYPE_INVALID:" as there
   is no other statements in "case IRQ_TYPE_NONE".
 - Add Acked-by: Jan Beulich .
---
Changes in V2:
 - use BIT() macros instead of 1UL << bit_num in aplic.c.
 - Drop passing of a cause to aplic_handle_interrupt() function. And update
   prototype of handle_interrupt() callback.
 - Drop ASSERT() in intc_handle_external_irqs() as it is useless.
 - Code style fixes.
 - Drop cause argument for intc_handle_external_irqs().
 - Update the commit message: drop words that imsic_ids_local_delivery() is
   implemented in this patch, it is only called.
 - Add cf_check for aplic_handle_interrupt(), aplic_set_irq_type().
 - Move forward declarations in asm/intc.h up.
 - Use plain C operator instead if {clear,set}_bit() for desc->status as it
   is always used under spinlock().
 - use writel() for writing to APLIC's sourcecfg in aplic_set_irq_type().
---
 xen/arch/riscv/aplic.c             | 71 ++++++++++++++++++++++++++++++
 xen/arch/riscv/include/asm/aplic.h |  7 +++
 xen/arch/riscv/include/asm/imsic.h |  1 +
 xen/arch/riscv/include/asm/intc.h  |  6 +++
 xen/arch/riscv/include/asm/irq.h   |  6 ++-
 xen/arch/riscv/intc.c              |  5 +++
 xen/arch/riscv/irq.c               | 47 ++++++++++++++++++++
 xen/arch/riscv/traps.c             | 19 ++++++++
 8 files changed, 161 insertions(+), 1 deletion(-)

diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c
index 7d2a1ea7aa..763c78617b 100644
--- a/xen/arch/riscv/aplic.c
+++ b/xen/arch/riscv/aplic.c
@@ -9,6 +9,7 @@
  * Copyright (c) 2024-2025 Vates
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -228,6 +229,71 @@ static void cf_check aplic_set_irq_affinity(struct irq_desc *desc, const cpumask
     spin_unlock(&aplic.lock);
 }
 
+static void cf_check aplic_handle_interrupt(struct cpu_user_regs *regs)
+{
+    /* disable to avoid more external interrupts */
+    csr_clear(CSR_SIE, BIT(IRQ_S_EXT, UL));
+
+    /* clear the pending bit */
+    csr_clear(CSR_SIP, BIT(IRQ_S_EXT, UL));
+
+    /* dispatch the interrupt */
+    do_IRQ(regs, csr_swap(CSR_STOPEI, 0) >> TOPI_IID_SHIFT);
+
+    /* enable external interrupts */
+    csr_set(CSR_SIE, BIT(IRQ_S_EXT, UL));
+}
+
+static void cf_check aplic_set_irq_type(struct irq_desc *desc, unsigned int type)
+{
+    /*
+    * Interrupt 0 isn't possible based on the spec:
+    *   Each of an APLIC’s interrupt sources has a fixed unique identity number in the range 1 to N,
+    *   where N is the total number of sources at the APLIC. The number zero is not a valid interrupt
+    *   identity number at an APLIC. The maximum number of interrupt sources an APLIC may support
+    *   is 1023.
+    *
+    * Thereby interrupt 1 will correspond to bit 0 in sourcecfg[] register,
+    * interrupt 2 ->sourcecfg[1] and so on.
+    *
+    * And that is the reason why we need -1.
+    */
+    unsigned int irq_bit = desc->irq - 1;
+
+    ASSERT(spin_is_locked(&desc->lock));
+
+    spin_lock(&aplic.lock);
+
+    switch ( type )
+    {
+    case IRQ_TYPE_EDGE_RISING:
+        writel(APLIC_SOURCECFG_SM_EDGE_RISE, &aplic.regs->sourcecfg[irq_bit]);
+        break;
+
+    case IRQ_TYPE_EDGE_FALLING:
+        writel(APLIC_SOURCECFG_SM_EDGE_FALL, &aplic.regs->sourcecfg[irq_bit]);
+        break;
+
+    case IRQ_TYPE_LEVEL_HIGH:
+        writel(APLIC_SOURCECFG_SM_LEVEL_HIGH, &aplic.regs->sourcecfg[irq_bit]);
+        break;
+
+    case IRQ_TYPE_LEVEL_LOW:
+        writel(APLIC_SOURCECFG_SM_LEVEL_LOW, &aplic.regs->sourcecfg[irq_bit]);
+        break;
+
+    case IRQ_TYPE_NONE:
+    case IRQ_TYPE_INVALID:
+        writel(APLIC_SOURCECFG_SM_INACTIVE, &aplic.regs->sourcecfg[irq_bit]);
+        break;
+
+    default:
+        panic("%s: APLIC doesnt support IRQ type: 0x%x?\n", __func__, type);
+    }
+
+    spin_unlock(&aplic.lock);
+}
+
 static const hw_irq_controller aplic_xen_irq_type = {
     .typename     = "aplic",
     .startup      = aplic_irq_startup,
@@ -241,6 +307,8 @@ static const struct intc_hw_operations aplic_ops = {
     .info                = &aplic_info,
     .init                = aplic_init,
     .host_irq_type       = &aplic_xen_irq_type,
+    .handle_interrupt    = aplic_handle_interrupt,
+    .set_irq_type        = aplic_set_irq_type,
 };
 
 static int cf_check aplic_irq_xlate(const uint32_t *intspec,
@@ -280,6 +348,9 @@ static int __init aplic_preinit(struct dt_device_node *node, const void *dat)
 
     register_intc_ops(&aplic_ops);
 
+    /* Enable supervisor external interrupt */
+    csr_set(CSR_SIE, BIT(IRQ_S_EXT, UL));
+
     return 0;
 }
 
diff --git a/xen/arch/riscv/include/asm/aplic.h b/xen/arch/riscv/include/asm/aplic.h
index c3f00238f2..b335b29d34 100644
--- a/xen/arch/riscv/include/asm/aplic.h
+++ b/xen/arch/riscv/include/asm/aplic.h
@@ -18,6 +18,13 @@
 #define APLIC_DOMAINCFG_IE      BIT(8, U)
 #define APLIC_DOMAINCFG_DM      BIT(2, U)
 
+#define APLIC_SOURCECFG_SM_INACTIVE     0x0
+#define APLIC_SOURCECFG_SM_DETACH       0x1
+#define APLIC_SOURCECFG_SM_EDGE_RISE    0x4
+#define APLIC_SOURCECFG_SM_EDGE_FALL    0x5
+#define APLIC_SOURCECFG_SM_LEVEL_HIGH   0x6
+#define APLIC_SOURCECFG_SM_LEVEL_LOW    0x7
+
 #define APLIC_TARGET_HART_IDX_SHIFT 18
 
 struct aplic_regs {
diff --git a/xen/arch/riscv/include/asm/imsic.h b/xen/arch/riscv/include/asm/imsic.h
index 378e49d933..c6c59215df 100644
--- a/xen/arch/riscv/include/asm/imsic.h
+++ b/xen/arch/riscv/include/asm/imsic.h
@@ -12,6 +12,7 @@
 #define ASM_RISCV_IMSIC_H
 
 #include 
+#include 
 #include 
 
 #define IMSIC_MMIO_PAGE_SHIFT   12
diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h
index a11b7aa55e..ecdc8a5e65 100644
--- a/xen/arch/riscv/include/asm/intc.h
+++ b/xen/arch/riscv/include/asm/intc.h
@@ -14,6 +14,7 @@ enum intc_version {
     INTC_APLIC,
 };
 
+struct cpu_user_regs;
 struct irq_desc;
 
 struct intc_info {
@@ -37,6 +38,9 @@ struct intc_hw_operations {
     void (*set_irq_type)(struct irq_desc *desc, unsigned int type);
     /* Set IRQ priority */
     void (*set_irq_priority)(struct irq_desc *desc, unsigned int priority);
+
+    /* handle external interrupt */
+    void (*handle_interrupt)(struct cpu_user_regs *regs);
 };
 
 void intc_preinit(void);
@@ -47,4 +51,6 @@ void intc_init(void);
 
 void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority);
 
+void intc_handle_external_irqs(struct cpu_user_regs *regs);
+
 #endif /* ASM__RISCV__INTERRUPT_CONTOLLER_H */
diff --git a/xen/arch/riscv/include/asm/irq.h b/xen/arch/riscv/include/asm/irq.h
index 84c3c2904d..94151eb083 100644
--- a/xen/arch/riscv/include/asm/irq.h
+++ b/xen/arch/riscv/include/asm/irq.h
@@ -33,16 +33,20 @@ struct arch_irq_desc {
     unsigned int type;
 };
 
+struct cpu_user_regs;
+struct dt_device_node;
+
 static inline void arch_move_irqs(struct vcpu *v)
 {
     BUG_ON("unimplemented");
 }
 
-struct dt_device_node;
 int platform_get_irq(const struct dt_device_node *device, int index);
 
 void init_IRQ(void);
 
+void do_IRQ(struct cpu_user_regs *regs, unsigned int irq);
+
 #endif /* ASM__RISCV__IRQ_H */
 
 /*
diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c
index f2823267a9..ea317aea5a 100644
--- a/xen/arch/riscv/intc.c
+++ b/xen/arch/riscv/intc.c
@@ -50,6 +50,11 @@ static void intc_set_irq_priority(struct irq_desc *desc, unsigned int priority)
         intc_hw_ops->set_irq_priority(desc, priority);
 }
 
+void intc_handle_external_irqs(struct cpu_user_regs *regs)
+{
+    intc_hw_ops->handle_interrupt(regs);
+}
+
 void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority)
 {
     ASSERT(desc->status & IRQ_DISABLED);
diff --git a/xen/arch/riscv/irq.c b/xen/arch/riscv/irq.c
index 669ef3ae9e..466f1b4ba9 100644
--- a/xen/arch/riscv/irq.c
+++ b/xen/arch/riscv/irq.c
@@ -11,6 +11,10 @@
 #include 
 #include 
 #include 
+#include 
+
+#include 
+#include 
 
 static irq_desc_t irq_desc[NR_IRQS];
 
@@ -90,3 +94,46 @@ void __init init_IRQ(void)
     if ( init_irq_data() < 0 )
         panic("initialization of IRQ data failed\n");
 }
+
+/* Dispatch an interrupt */
+void do_IRQ(struct cpu_user_regs *regs, unsigned int irq)
+{
+    struct irq_desc *desc = irq_to_desc(irq);
+    struct irqaction *action;
+
+    irq_enter();
+
+    spin_lock(&desc->lock);
+
+    if ( desc->handler->ack )
+        desc->handler->ack(desc);
+
+    if ( desc->status & IRQ_DISABLED )
+        goto out;
+
+    desc->status |= IRQ_INPROGRESS;
+
+    action = desc->action;
+
+    spin_unlock_irq(&desc->lock);
+
+#ifndef CONFIG_IRQ_HAS_MULTIPLE_ACTION
+    action->handler(irq, action->dev_id);
+#else
+    do {
+        action->handler(irq, action->dev_id);
+        action = action->next;
+    } while ( action );
+#endif /* CONFIG_IRQ_HAS_MULTIPLE_ACTION */
+
+    spin_lock_irq(&desc->lock);
+
+    desc->status &= ~IRQ_INPROGRESS;
+
+ out:
+    if ( desc->handler->end )
+        desc->handler->end(desc);
+
+    spin_unlock(&desc->lock);
+    irq_exit();
+}
diff --git a/xen/arch/riscv/traps.c b/xen/arch/riscv/traps.c
index ea3638a54f..f061004d83 100644
--- a/xen/arch/riscv/traps.c
+++ b/xen/arch/riscv/traps.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -128,6 +129,24 @@ void do_trap(struct cpu_user_regs *cpu_regs)
         }
         fallthrough;
     default:
+        if ( cause & CAUSE_IRQ_FLAG )
+        {
+            /* Handle interrupt */
+            unsigned long icause = cause & ~CAUSE_IRQ_FLAG;
+
+            switch ( icause )
+            {
+            case IRQ_S_EXT:
+                intc_handle_external_irqs(cpu_regs);
+                break;
+
+            default:
+                break;
+            }
+
+            break;
+        }
+
         do_unexpected_trap(cpu_regs);
         break;
     }
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 15:59:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 15:59:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007091.1386433 (Exim 4.92)
	(envelope-from )
	id 1uND04-0000dQ-4I; Thu, 05 Jun 2025 15:59:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007091.1386433; Thu, 05 Jun 2025 15:59: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 1uND03-0000cv-TY; Thu, 05 Jun 2025 15:59:27 +0000
Received: by outflank-mailman (input) for mailman id 1007091;
 Thu, 05 Jun 2025 15:59: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 1uND02-00071f-KL
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 15:59:26 +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 0d686ab8-4226-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 17:59:25 +0200 (CEST)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-60179d8e65fso2083841a12.0
 for ; Thu, 05 Jun 2025 08:59:25 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-60566c2aba9sm10443034a12.2.2025.06.05.08.59.23
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 08:59:23 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0d686ab8-4226-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749139164; x=1749743964; darn=lists.xenproject.org;
        h=content-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=wo4QtKZfWoJ+7BBnjSqXsA3jxl9wi6iGfitcuuiEYpg=;
        b=H1nSa0P1o93KiPRp8C0eES6wRkabdquqAs00cVOrP3OM0CZIHtSRkUNLJ5v9eEp1Gy
         NXImbg66ufEAdweSAzsEb3d83JrLDPFMP9iEyvWeu+YBU8rwX0yJySHsp3esYp9ZHQS/
         4kvlcsrzIzgu4f7uJ5OO2fB2HVJ87gpj43Qs7yJJgW6mUawndnox2AV4m/0GdJUVuZNf
         8+cS3fnGsyPdFa0yWoCEH1O1ZwL78fQWexhBtBKWdkJ8ifo32AZZXzyOpq6jwE9oN77P
         uCNhhA/VOugf6lNcIj7/r4abW8KD7V2IjoFIe2Qy+NvBvYo9z4EL8Bt8HgyHag+BJq8c
         lHpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749139164; x=1749743964;
        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=wo4QtKZfWoJ+7BBnjSqXsA3jxl9wi6iGfitcuuiEYpg=;
        b=gIAIQTJrb95wh6C94aLb6MI5JxfQl9xvy+44xZXMwHGoMz7671kG8TvUa/074jIQEe
         +zKKlxjbNFzJsvj4qAEBfT3wKrNKCBRCQCns/n1iozv2CTDJrW0pUyV4vfhcNx45m9G8
         jKGw0vCnjtU6L8oq7mgzxdq+8IWIg9qozE8CAxKLkrjqu9iNz5GCRTqms81T0kZCQAeX
         ED2WFgvEj9mMKzWMh/EvzvOtNmK5HjJSE3EPfuorRiaHtnfT39HPgYdwQIhYFX7hV+KG
         m/EjM4/poW55GLxBWpr9H55Z7kF9UMSmvPdbVT6c17XLYMw9elz4XTc3eYKBjo5v1nfv
         OVKQ==
X-Gm-Message-State: AOJu0Yw2e0aaZ4RZzo/GWWp8Cv5NN6v15+vTMCGEudCqKEeXNrpDskvp
	5BsAEq32KsvyilXFsk8eDV7t7VtyCIFajZYlUBdn7DxAmwQGtOdgaB8/Nc/o+A==
X-Gm-Gg: ASbGnct/PGOigiB6KaS7JfX+QbMfQGWGQbUB1OVp0W6RLMALD+uo5GfqxD4rENivCMT
	hJCDfL/caIxIAvGvuZOvnhZGUU3OTUwYN+UT3GGy272ECLyrPlfpEFLRZF+aqbNcgOsNQSgsr2p
	uQ+fRodBtzJKEplklsgp9Xgv+h3+l0ctDlEjM3++tAP460vbIMWoUJetF9l/l9QH4qk6rpG30M/
	B2dXZcXRPLCn/Z2BnNE2NsdXLcKMfB3d+w7wy+l4/+ZSLaymwFfLNqG787e4MWD12ahe8TvuCi/
	2OC9OdSB0Y9UbdSK+Qp6crzx4pZQVNvnW2g2mtU1M3X6G724G+uREMtySkp2VHaaVvFm9ZTM1it
	BtuHD/b0+gyLSYisdsQ==
X-Google-Smtp-Source: AGHT+IHbvQkyjn3zbunZCFPyGEGBZEEKvOH0onRaiUVW35EdMdhPS1zgTJRFvAsmyfKFaILhQlB1mg==
X-Received: by 2002:a05:6402:d08:b0:605:a076:b3bc with SMTP id 4fb4d7f45d1cf-606ea182266mr7661429a12.28.1749139164248;
        Thu, 05 Jun 2025 08:59:24 -0700 (PDT)
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 v4 9/9] xen/riscv: add basic UART support
Date: Thu,  5 Jun 2025 17:59:05 +0200
Message-ID: <0b12815140e424fd019d57955073df3e11c5ea92.1749121437.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Update Kconfig to select GENERIC_UART_INIT for basic UART init ( find a dt node
and call device specific device_init() ).

Drop `default n if RISCV` statement for config HAS_NS16550 as now ns16550 is
ready to be compiled and used by RISC-V. Also, make the config user selectable
for everyone except X86.

Initialize a minimal amount of stuff to have UART and Xen console:
 - Initialize uart by calling uart_init().
 - Initialize Xen console by calling console_init_{pre,post}irq().
 - Initialize timer and its internal lists which are used by
   init_timer() which is called by ns16550_init_postirq(); otherwise
   "Unhandled exception: Store/AMO Page Fault" occurs.
 - Enable local interrupt to recieve an input from UART

Signed-off-by: Oleksii Kurochko 
Acked-by: Jan Beulich 
---
Changes in V4:
 - Nothing changed. Only rebase.
---
Changes in v3:
 - Drop inclusion of  as nothing in setup.c requires it.
 - Add Acked-by: Jan Beulich .
---
Changes in v2:
 - Drop #include  in setup.c, isn't needed anymore.
 - Drop call of percpu_init_areas() as it was needed when I used polling
   mode for UART,  for this case percpu is used to receive serial port info:
     struct serial_port *port = this_cpu(poll_port);
   So percpu isn't really needed at the current development state.
 - Make HAS_NS16550 user selectable for everyone, except X86.
 - Update the commit message.
---
 xen/arch/riscv/Kconfig   |  1 +
 xen/arch/riscv/setup.c   | 12 ++++++++++++
 xen/drivers/char/Kconfig |  3 +--
 3 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/xen/arch/riscv/Kconfig b/xen/arch/riscv/Kconfig
index 62c5b7ba34..96bef90751 100644
--- a/xen/arch/riscv/Kconfig
+++ b/xen/arch/riscv/Kconfig
@@ -2,6 +2,7 @@ config RISCV
 	def_bool y
 	select FUNCTION_ALIGNMENT_16B
 	select GENERIC_BUG_FRAME
+	select GENERIC_UART_INIT
 	select HAS_DEVICE_TREE
 	select HAS_PMAP
 	select HAS_UBSAN
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 0e7398159c..a17096bf02 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -4,12 +4,15 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -134,8 +137,17 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
 
     intc_preinit();
 
+    uart_init();
+    console_init_preirq();
+
     intc_init();
 
+    timer_init();
+
+    local_irq_enable();
+
+    console_init_postirq();
+
     printk("All set up\n");
 
     machine_halt();
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index e6e12bb413..8e49a52c73 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -2,8 +2,7 @@ config GENERIC_UART_INIT
 	bool
 
 config HAS_NS16550
-	bool "NS16550 UART driver" if ARM
-	default n if RISCV
+	bool "NS16550 UART driver" if !X86
 	default y
 	help
 	  This selects the 16550-series UART support. For most systems, say Y.
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 15:59:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 15:59:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007096.1386442 (Exim 4.92)
	(envelope-from )
	id 1uND07-00014M-F5; Thu, 05 Jun 2025 15:59:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007096.1386442; Thu, 05 Jun 2025 15:59: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 1uND07-00014C-9v; Thu, 05 Jun 2025 15:59:31 +0000
Received: by outflank-mailman (input) for mailman id 1007096;
 Thu, 05 Jun 2025 15: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 1uND05-0007U9-Hf
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 15:59:29 +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 0fc10a4e-4226-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 17:59:29 +0200 (CEST)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-60700a745e5so2149583a12.3
 for ; Thu, 05 Jun 2025 08:59:29 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-60566c2aba9sm10443034a12.2.2025.06.05.08.59.22
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 08:59:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0fc10a4e-4226-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749139163; x=1749743963; darn=lists.xenproject.org;
        h=content-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=8ovFmXA1UGXAtGGADABCiptgNt0/VbJsXEb5lSAcJ+w=;
        b=D5H+P7JAVlzAyI9l3neesNNWrS+ohzxZrt3AMghVcjFNk10YY7SF500T6i5KtAc5sq
         AiQvAdSicoAdEjFbBMVK+EFigs2nKcP0ojT1v8OFEwUuFtgnVbyjKZCZUaxhS7957FvG
         M3nLmc2yUCjc9xyGcSd4Rr++TAm+hoNV7GMZZzV+t1y08Tg0iXF5PlhlD6IpjmRFt/wH
         c4sbSpVzaXKS3LHR9oxPhrbTWk+DKe3y+xavYfq7SxxVYS1E8c2h9Hemv8zTCy7ZAKqi
         uZPxHdzlSR+I6ZdSHfeubW6OE9y9RY8fAJUCiEMkDPCa8nicDQMtByGvcwSuhEYPIRnE
         ENyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749139163; x=1749743963;
        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=8ovFmXA1UGXAtGGADABCiptgNt0/VbJsXEb5lSAcJ+w=;
        b=N0FxxalzA8FspI2gUoHMtSE703h7nGwc91Q6X4u/eLC0rFPwHyBFyMAxwcpQ9UML31
         xCt+MgylgzGuoKFnSILf4KbPhsNAHxrHw+pWkOyZ/n3Y7Jx19sBjSJgOGECZ8Zw/4wFW
         6qKcdSMZK9Rn6gKDj76+zb0C26F7DBnP/rYSbHJeh5+ZhshVpJxw4Ltf66DLrW35Jtzx
         EU3pdSMJQzCOzyUa4aBUHUvu8x2MpnUOPsjuItwPLQHI+PJzEM55aF5lpH3IlEkcn569
         I3dZCWptg2YL0gXisptkyPXtCUm0H132e8ymQTwCtTdSXzpnzkc4ZiqViwQNrXULbJan
         CmsQ==
X-Gm-Message-State: AOJu0Ywm8IdlNvv8kiaIzbnt7W6YSwzE3235kZqBIELziThEKxaegLCY
	TCZ18mP9HEx9HPO+StR7sJ41L+b2XJtnKIEt97jg2n+ZqPPEMqoCIdq0mvMJQw==
X-Gm-Gg: ASbGncsnON91FTUKYXaII0tcHubvIKDIPLjo8bU5YA4cHx/+BWYR5/Y0yOf0O6nUkep
	I04WD6t7d7DjXkO0BCCHyiqpaKnkn/rbPJYHn3stgxGxIS/uAPqUrO1H6YdzmkiD9uAW3aXUZF5
	C2V5Mu3PhNYvVSAqy6lCru03k+UbBnoSmUR/hVJ4Pv8jbPwEL7k/5drIaf0DhCtcWz2mqL9X1uA
	PFsXiUTNBIWT7s4jjX4tEkelSgDPsiVSQzOBu1IA+c+Bq/efL2uyJ7AKLV2JrZoY5Jvqch/SZJT
	TqrZ5LeYJpFHkKy/cTlG09Lr/i/RpMNTv0ArkpiM/0BlwFY8gGpovmK2hhSP/whMTeoZCeI1ys8
	WDvnNY8moOnwuEdgVTuPcAXzgG7Ka
X-Google-Smtp-Source: AGHT+IGiKozMXs76mhqmQRjxPg/vaDVehgBJBskLlP1rKEzmzMq8d3rg8rqpjs455MmbG2b488tCZA==
X-Received: by 2002:a05:6402:510e:b0:606:df70:7aa2 with SMTP id 4fb4d7f45d1cf-606ea3a78d7mr7351408a12.31.1749139163381;
        Thu, 05 Jun 2025 08:59:23 -0700 (PDT)
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 ,
	Romain Caritey 
Subject: [PATCH v4 8/9] xen/riscv: implement setup_irq()
Date: Thu,  5 Jun 2025 17:59:04 +0200
Message-ID: <4f2c15a95b1fb2720ba0643f668f080e8b390613.1749121437.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Introduce support for IRQ setup on RISC-V by implementing setup_irq() and
__setup_irq(), adapted and extended from an initial implementation by [1].

__setup_irq() does the following:
  - Sets up an IRQ action.
  - Validates that shared IRQs have non-NULL `dev_id` and are only used when
    existing handlers allow sharing.
  - Uses smp_wmb() to enforce memory ordering after assigning desc->action
    to ensure visibility before enabling the IRQ.
  - Supports multi-action setups via CONFIG_IRQ_HAS_MULTIPLE_ACTION.

setup_irq() does the following:
  - Converts IRQ number to descriptor and acquires its lock.
  - Rejects registration if the IRQ is already assigned to a guest domain,
    printing an error.
  - Delegates the core setup to __setup_irq().
  - On first-time setup, disables the IRQ, routes it to Xen using
    intc_route_irq_to_xen(), sets default CPU affinity (current CPU),
    calls the handler’s startup routine, and finally enables the IRQ.

irq_set_affinity() invokes set_affinity() callback from the IRQ handler
if present.

Defined IRQ_NO_PRIORITY as default priority used when routing IRQs to Xen.

[1] https://gitlab.com/xen-project/people/olkur/xen/-/commit/7390e2365828b83e27ead56b03114a56e3699dd5

Co-developed-by: Romain Caritey 
Signed-off-by: Oleksii Kurochko 
---
Changes in V3-4:
 - Nothing changed. Only rebase.
---
Changes in V2:
 - Added implenmtation of aplic_set_irq_type() as it is going to be used in
   this commit. And also, update the implementation of it. Make default case
   of switch to do panic().
 - Move all forward declaration up  in asm/irq.h.
 - s/__setup_irq/_setup_irq.
 - Code style fixes.
 - Update commit message.
 - use smp_wmb() instead of smp_mb() in _setup_irq().
 - Drop irq_set_affinity().
 - Use plain C operator instead if {clear,set}_bit() for desc->status as it
   is always used under spinlock().
 - Drop set_bit(_IRQ_DISABLED, &desc->status) in setup_irq() as in the case
   when IRQ is setuped for a first time, desc->status should be already set
   to IRQ_DISABLED in init_one_irq_desc().
----
 xen/arch/riscv/include/asm/irq.h |  2 +
 xen/arch/riscv/irq.c             | 84 ++++++++++++++++++++++++++++++++
 2 files changed, 86 insertions(+)

diff --git a/xen/arch/riscv/include/asm/irq.h b/xen/arch/riscv/include/asm/irq.h
index 94151eb083..f633636dc3 100644
--- a/xen/arch/riscv/include/asm/irq.h
+++ b/xen/arch/riscv/include/asm/irq.h
@@ -17,6 +17,8 @@
  */
 #define NR_IRQS 1024
 
+#define IRQ_NO_PRIORITY 0
+
 /* TODO */
 #define nr_irqs 0U
 #define nr_static_irqs 0
diff --git a/xen/arch/riscv/irq.c b/xen/arch/riscv/irq.c
index 466f1b4ba9..25d3295002 100644
--- a/xen/arch/riscv/irq.c
+++ b/xen/arch/riscv/irq.c
@@ -7,6 +7,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -63,6 +64,89 @@ int platform_get_irq(const struct dt_device_node *device, int index)
     return dt_irq.irq;
 }
 
+static int _setup_irq(struct irq_desc *desc, unsigned int irqflags,
+                      struct irqaction *new)
+{
+    bool shared = irqflags & IRQF_SHARED;
+
+    ASSERT(new != NULL);
+
+    /*
+     * Sanity checks:
+     *  - if the IRQ is marked as shared
+     *  - dev_id is not NULL when IRQF_SHARED is set
+     */
+    if ( desc->action != NULL && (!(desc->status & IRQF_SHARED) || !shared) )
+        return -EINVAL;
+    if ( shared && new->dev_id == NULL )
+        return -EINVAL;
+
+    if ( shared )
+        desc->status |= IRQF_SHARED;
+
+#ifdef CONFIG_IRQ_HAS_MULTIPLE_ACTION
+    new->next = desc->action;
+#endif
+
+    desc->action = new;
+    smp_wmb();
+
+    return 0;
+}
+
+int setup_irq(unsigned int irq, unsigned int irqflags, struct irqaction *new)
+{
+    int rc;
+    unsigned long flags;
+    struct irq_desc *desc = irq_to_desc(irq);
+    bool disabled;
+
+    spin_lock_irqsave(&desc->lock, flags);
+
+    disabled = (desc->action == NULL);
+
+    if ( desc->status & IRQ_GUEST )
+    {
+        spin_unlock_irqrestore(&desc->lock, flags);
+        /*
+         * TODO: would be nice to have functionality to print which domain owns
+         *       an IRQ.
+         */
+        printk(XENLOG_ERR "ERROR: IRQ %u is already in use by a domain\n", irq);
+        return -EBUSY;
+    }
+
+    rc = _setup_irq(desc, irqflags, new);
+    if ( rc )
+        goto err;
+
+    /* First time the IRQ is setup */
+    if ( disabled )
+    {
+        /* Route interrupt to xen */
+        intc_route_irq_to_xen(desc, IRQ_NO_PRIORITY);
+
+        /*
+         * We don't care for now which CPU will receive the
+         * interrupt.
+         *
+         * TODO: Handle case where IRQ is setup on different CPU than
+         *       the targeted CPU and the priority.
+         */
+        desc->handler->set_affinity(desc, cpumask_of(smp_processor_id()));
+
+        desc->handler->startup(desc);
+
+        /* Enable irq */
+        desc->status &= ~IRQ_DISABLED;
+    }
+
+ err:
+    spin_unlock_irqrestore(&desc->lock, flags);
+
+    return rc;
+}
+
 int arch_init_one_irq_desc(struct irq_desc *desc)
 {
     desc->arch.type = IRQ_TYPE_INVALID;
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 16:04:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 16:04:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007154.1386452 (Exim 4.92)
	(envelope-from )
	id 1uND4f-0005o7-9G; Thu, 05 Jun 2025 16:04:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007154.1386452; Thu, 05 Jun 2025 16:04: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 1uND4f-0005o0-6L; Thu, 05 Jun 2025 16:04:13 +0000
Received: by outflank-mailman (input) for mailman id 1007154;
 Thu, 05 Jun 2025 16:04: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 1uND4e-0005nu-50
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 16:04:12 +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 b733ec22-4226-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 18:04:10 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a528243636so706619f8f.3
 for ; Thu, 05 Jun 2025 09:04:10 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-747affafbfcsm13004807b3a.89.2025.06.05.09.04.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 09:04:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b733ec22-4226-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749139449; x=1749744249; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=y8oW7pQ5BcrODanKo9P3TQDy87pYMla9FTv6g//9z5c=;
        b=bgS72avwDZnzmk3+lFOlhkqq5l0HfzS/7J9Fq9FXNzQl5M7Y/1yctWoi2M50+pAAz+
         V8SrCERTnzoQp1dr1vrnNw8e2qpsT6qqurgvsr2h5nA3WHwkua1GSqU6/SGD++I+Ohq1
         +jkQkic/txcGgL95llIKfckaj5zhu9tmtacxlPtMUrHdlxXJ2E2T/1SWuRjuWZBII5GF
         WvLcz4hgo3zjMturAuQDsxByBFcsRUpQPKG2SAm1exvGEGzz2PGPDg6duTIicuC6rTb1
         oOXvUb/nXaPCmkXV73z9j9vYIUPwOI4IvNsA+45pDoGcGKXCWhOTNMJ70EhMlGr4tOMB
         AH2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749139449; x=1749744249;
        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=y8oW7pQ5BcrODanKo9P3TQDy87pYMla9FTv6g//9z5c=;
        b=bimShgEAFP3OYvZy2S5OxMSyLsNgnMuA0ZL7zT7e/IK4EHdBpoZLm9aYgMbSXADcKD
         Yw/gpNyk6EloVfpHudpYfATUADXLigt2zPYQIpYE7M+6iy0QTcRl2/nBolgk45By2ST0
         zHYVRv9Z2ZwooTCvTNhZp+k12wI3/AwedhgslPwdiYmcjzorNkaFHADrny4YZxO8hatw
         rt5yw0y9GWX3llgjy3Rwm9ZXMofeAPIsTxqJn7oppjXAaUfq79MozHgkFRG2LYCbP2PY
         0pVF3MPTqKhfJE3ThYx6VTUb0X0cljYU02ME3k7tU1kqWoTexbv0cW7d4ba+LJIQl6sd
         qCpw==
X-Forwarded-Encrypted: i=1; AJvYcCVtF8j9oLCMPUKt7GjKokeMmM+bgDkfKaOC/84FAFPAabrOEK9zW1TsGXC+0W/AXyt7MtCihEXm+y0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwfE3GLTUo275rWaXDkgY4VhH8IOI9PDrFCF6wuVCqFCtU/cFjY
	4d9lWbWcJmwEc4nlAN/u/ZnHhWTS0GtU9N9jAjwaN+mpmoLIDXkXSP+UdIntO8errA==
X-Gm-Gg: ASbGncuWRdfkjzR98qvuYNRQV/QJ2ansQVZ+WDAkYMAxeD94nLMID4p3zKkWidrnfY1
	drVgTj1a3tojdquW4RAarPUsoNgYzho3smsh0ivLIy6CcQEKz25iT8zirI1+/fOl2i9jtPCsMzx
	OEvrOe6ynaxuueOfGNfRcC9PSkxEage0doV9uOeksi5XlcVhwP/KkTqKgwNe8l+Pwd1GU4jqjhY
	T5PIHDFoRdMine3DoN46VOK3/1XMGHwb/C/qGe8994xoiGfCGpKO6kJ9IOzme12/nWWNOCqqZXL
	Ie9/BSjaqAJ6Hs7KQGBpDPbDoHADF1odOmodg0lKJR3wOqXWpLgexik2zfIKqWPXnTeYFxCT+qD
	wsAN1Sdc5f+sRJbJPSpX7ied/6kPsHWI9m3Qz
X-Google-Smtp-Source: AGHT+IFpyCfLQMstZOpHAy8FWHq7RTrhoR+trZB3+Q7HrzLI53Yy2XvlNwSOB36G5XVJKobt2k0NNQ==
X-Received: by 2002:a05:6000:40d9:b0:3a4:ea8f:efe4 with SMTP id ffacd0b85a97d-3a51d921736mr6439695f8f.18.1749139449288;
        Thu, 05 Jun 2025 09:04:09 -0700 (PDT)
Message-ID: <698660d3-ab00-4942-872b-b73687e0350e@suse.com>
Date: Thu, 5 Jun 2025 18:04:01 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] vmx: Introduce vcpu single context VPID invalidation
To: Teddy Astie 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <83d0e7dfc076e9453fb6537e5948c03d90e947da.1748594036.git.teddy.astie@vates.tech>
 <4ed9d6ce-5634-4dd9-86e9-5d1f84a43e10@suse.com>
 <76bf2d72-3834-4455-8023-a20c84db58d0@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: <76bf2d72-3834-4455-8023-a20c84db58d0@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 05.06.2025 17:17, Teddy Astie wrote:
> Le 05/06/2025 à 16:51, Jan Beulich a écrit :
>> On 30.05.2025 10:48, Teddy Astie wrote:
>>> +    /*
>>> +     * If single context invalidation is not supported, we escalate to
>>> +     * use all context invalidation.
>>> +     */
>>> +    if ( likely(cpu_has_vmx_vpid_invvpid_single_context) )
>>> +        goto execute_invvpid;
>>> +
>>> +    type = INVVPID_ALL_CONTEXT;
>>> +
>>> +execute_invvpid:
>>
>> There no reason at all to use "goto" here (and with that replaced there's
>> then also no style issue with the label placement).
> 
> Should a similar treatment be made for vpid_sync_vcpu_gva ?

I wouldn't require anyone to do a re-work, but the latest when it is touched
the next time it likely should be polished some. For context, while iirc we
didn't accept that rule, Misra in principle also demands that "goto" not be
used.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 16:05:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 16:05:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007159.1386464 (Exim 4.92)
	(envelope-from )
	id 1uND5e-0006KQ-JC; Thu, 05 Jun 2025 16:05:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007159.1386464; Thu, 05 Jun 2025 16:05:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uND5e-0006KJ-FG; Thu, 05 Jun 2025 16:05:14 +0000
Received: by outflank-mailman (input) for mailman id 1007159;
 Thu, 05 Jun 2025 16:05: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 1uND5d-0006KD-Aj
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 16:05:13 +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 dc5a195b-4226-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 18:05:12 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a36748920cso1182184f8f.2
 for ; Thu, 05 Jun 2025 09:05:12 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b2eceb02a66sm10454509a12.1.2025.06.05.09.05.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 09:05:11 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: dc5a195b-4226-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749139512; x=1749744312; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Wqj6OlcbgO0YyjN1kGvVd4r8f1UZYdWIdKiSngFptn8=;
        b=OLK+sEF9qYUx7+aJb7tD3qHrfo0BiKgoOIN549P9ggA6NF7u1LD5tY0ErXI3QJk+TN
         lPemJulFJyQAZj3lsDhQaDSlXs1m3162ElRmU9DiAVy0/p3NwMvAIilo8luGVYdOjQG/
         WVPmzv6XpOzYV/GVd8oEDJn3n4JH11gh/pg2B4s6cHW6yh49lkODNNGf7ezVD+GpgWcu
         vxujAp2f4l9VjEgsC3iNxD3pCVZJk21voemXXIKj+0oDujEBLnMReEd7Qy9ehxAYq69g
         1VA7u95i7F5aOCYGnSjkpBoO2TthUOpUGE0pcwJdor7Im+KRzT86nz2fegKoGoY7Pmkl
         yhyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749139512; x=1749744312;
        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=Wqj6OlcbgO0YyjN1kGvVd4r8f1UZYdWIdKiSngFptn8=;
        b=bR4VGXNSyiGnarqBlo5ANZXC3kEnfna07Ob4uJ/eBJYTA5+Eil5FxMXYSoRmgRjnmJ
         09mKnJCHDlO4ZLpadw/CLDOBrDXz1mx3cHq4YA4nOqYyRWn015Omv3uiwgyQaf5BnNhd
         JOmI22hbikBJ5CvKUfwwx34qpabVH5/p0pIfHye4T/uKPEBsiL6O2R2+gZPvZBH6fz0H
         VbhRBkkYo2eWVtafZky+Z020v6YIrdz/Y/T75O2T+zTM/1rudmzU1oiAiWIoxFDY4eim
         N0zdilfgvFNFq2mGaL5hKCANFXqdEzkjsFKRmEyEZ8FdpgbKjAH5RTNUVcybxwrR0PpB
         TWtg==
X-Gm-Message-State: AOJu0YxWFmWClAivYkqg6lIJDc5ozXslELxLghQlDgCBpIxgGvorKvJE
	sBJnaeXqC6302+ZL6FB+9sD7A6HfjehFDvvNApB30Zp+dXNYPCqBjuayxGGB06ViSg==
X-Gm-Gg: ASbGncsrAAqk3hyxptkbyFEarh11E7PWZ6lenrje4US01vVB06GNN4pWkWpiuvINCMc
	I8NEXn3E0bUsZ9XmoJYvTYukux/D3dErG7mg1Gbe5Wa4oEhGlb3rvKKQMsS5Nr/tgcGyrewC3qt
	2ZGii2NGLW/61IYH+hnk8HS6P1MQMLLQqBmf4au0i8XYXMTsRK3bAetLkohxKwASSqPqJ1x7lz0
	2a9r8rS/jUDygJAFE1/GlmpDs/5dfe144xyvvEgBy/4FtGIwGzs0nobrJf66u6wfFzM+PFb9Efr
	OZoU6O0XMhSnpmtiP/XRYjESB3BWm9Sp4hrPnTAxug5lInpr6H16GgXMKQ4oRgD3Cqmdl47WSOg
	286ksVsv1SkiOUvd2yOgqL2GFwl9+eK2qBrSr
X-Google-Smtp-Source: AGHT+IEfUSw1ZXD/eeCPtT5vaOlN9gz7Pxc44RukLfMdNf+RqU519TEGg95nNrVNs9uYY2Vbz66+jg==
X-Received: by 2002:a05:6000:25c4:b0:3a4:d4cd:b06 with SMTP id ffacd0b85a97d-3a51d95dfb2mr6725737f8f.34.1749139511599;
        Thu, 05 Jun 2025 09:05:11 -0700 (PDT)
Message-ID: 
Date: Thu, 5 Jun 2025 18:05:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/5] console: add relocation hook
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 
Cc: xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini ,
 Andrew Cooper 
References: 
 <4f1889dc03ec4aa2cc0cd2bd14523a2c6f670bdb.1748182535.git-series.marmarek@invisiblethingslab.com>
 <0b17da9c-57db-4a8b-90af-e53e45cb1243@citrix.com> 
 <66cfdee6-5dc2-4139-8550-ef441fa7a7a0@suse.com> 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 05.06.2025 16:51, Marek Marczykowski-Górecki wrote:
> On Thu, Jun 05, 2025 at 04:42:53PM +0200, Jan Beulich wrote:
>> On 26.05.2025 17:39, Marek Marczykowski-Górecki wrote:
>>> On Mon, May 26, 2025 at 04:08:17PM +0100, Andrew Cooper wrote:
>>>> On 25/05/2025 3:15 pm, Marek Marczykowski-Górecki wrote:
>>>>> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
>>>>> index 25189541244d..3ef819a252e4 100644
>>>>> --- a/xen/arch/x86/setup.c
>>>>> +++ b/xen/arch/x86/setup.c
>>>>> @@ -1481,6 +1481,8 @@ void asmlinkage __init noreturn __start_xen(void)
>>>>>          highmem_start &= ~((1UL << L3_PAGETABLE_SHIFT) - 1);
>>>>>  #endif
>>>>>  
>>>>> +    console_init_pre_relocate();
>>>>> +
>>>>>      /*
>>>>>       * Iterate backwards over all superpage-aligned RAM regions.
>>>>>       *
>>>>> @@ -1606,6 +1608,12 @@ void asmlinkage __init noreturn __start_xen(void)
>>>>>      if ( !xen_phys_start )
>>>>>          panic("Not enough memory to relocate Xen\n");
>>>>>  
>>>>> +    /*
>>>>> +     * Notify console drivers about relocation, before reusing old Xen's
>>>>> +     * memory.
>>>>> +     */
>>>>> +    console_init_post_relocate();
>>>>> +
>>>>
>>>> With reference to the next patch, there are printk()'s in this region
>>>> which want to work (in case something goes very wrong), so I don't think
>>>> setting dbc->suspended is the best approach.
>>>
>>> I guess the post_relocate hook might be moved a bit earlier, but still,
>>> once relocation happens, the xhci console is not functional until it
>>> gets relocated too (for example - it would post new TRBs into a ring
>>> that isn't actually monitored by the controller).
>>
>> Why is it that this ring is dependent upon Xen's position? If the ring was
>> dynamically allocated, it wouldn't change position when Xen is moved.
> 
> The console is setup quite early, I don't think I can allocate memory at
> this stage, no?

But you allocate before Xen is moved, I suppose.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 16:08:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 16:08:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007165.1386472 (Exim 4.92)
	(envelope-from )
	id 1uND95-0006sj-03; Thu, 05 Jun 2025 16:08:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007165.1386472; Thu, 05 Jun 2025 16:08:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uND94-0006sc-Ta; Thu, 05 Jun 2025 16:08:46 +0000
Received: by outflank-mailman (input) for mailman id 1007165;
 Thu, 05 Jun 2025 16:08: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 1uND93-0006sW-55
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 16:08:45 +0000
Received: from fhigh-a7-smtp.messagingengine.com
 (fhigh-a7-smtp.messagingengine.com [103.168.172.158])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 572efe1b-4227-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 18:08:39 +0200 (CEST)
Received: from phl-compute-02.internal (phl-compute-02.phl.internal
 [10.202.2.42])
 by mailfhigh.phl.internal (Postfix) with ESMTP id B5AA9114013C;
 Thu,  5 Jun 2025 12:08:37 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-02.internal (MEProxy); Thu, 05 Jun 2025 12:08:37 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 5 Jun 2025 12:08:35 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 572efe1b-4227-11f0-b894-0df219b8e170
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=1749139717;
	 x=1749226117; bh=89STe5fw1aNVbaA6KjPAdtlHp3gpOhHgWSnH4egnfqI=; b=
	Tj1hUyVjYFuFXISRUW+UKKoDCQ9wHqlzGxqrNw7+i2gx4d2qgaiRXno4JMdMxq+U
	SqC3pxn7/0jOKrkIU6DV2z5kBM/xADfsvVxQW74JEzV8dlQAy1aj/9q1jvjI/qIF
	+KPyDzrY1zQnsV2OnHIwAeV+Uln8gw3+fHlys9fC/b37cY/aCGL+mdhQfu10kv9P
	+AmSxFTOe7Wla4afZ4d3wWH8jqTWo4qur6cFddEWDoiissnHJHNZSOciHqJ+2WhF
	QuOVq2laMNZ3gkGxd05jVrUDBMz2IIrSU9c3BR6/PJCiM0TJhBWmauduT23bLWql
	Wpav1Q5xB3iJic0h/mZ5vg==
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=
	1749139717; x=1749226117; bh=89STe5fw1aNVbaA6KjPAdtlHp3gpOhHgWSn
	H4egnfqI=; b=kGtjrsIWXLUMadpb64p+MAYQ7jwHuA+g1U1cRHs/Vsren66qAZK
	IuDsFQXkkeRPkzzkBFqtAyrUdEw0MWguHfaHp5hl845s+haQxRKkRqyfxN8yheJX
	p3cth+va1uavwmqsmADJiaeOWLqwEnfK/RAjEmETIBYI9YiyxkNXeGIzy3RYN6aC
	8Rnn2wzC1jVDAh/dcdezB8T5k+9yg7l1aH4njsA94U6rgNKQxUaWQ1TZr+Ui/J4j
	NlgUxIDfXs6FUSP8Ko7o39UnQAwxdWXOReEfzy3eYjvY+XrbEukBTaF5PCVLwHS1
	OrSfo87ulUCES9uBEDib6pNvwRaptC/256g==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugdefkeeiucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtjeen
    ucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomh
    grrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggft
    rfgrthhtvghrnhepgfduleetfeevhfefheeiteeliefhjefhleduveetteekveettddvge
    euteefjedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho
    mhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnh
    gspghrtghpthhtohepkedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepjhgsvghu
    lhhitghhsehsuhhsvgdrtghomhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsth
    hsrdigvghnphhrohhjvggtthdrohhrghdprhgtphhtthhopehrohhgvghrrdhprghusegt
    ihhtrhhigidrtghomhdprhgtphhtthhopegrnhhthhhonhihrdhpvghrrghrugesvhgrth
    gvshdrthgvtghhpdhrtghpthhtohepmhhitghhrghlrdhorhiivghlsegrmhgurdgtohhm
    pdhrtghpthhtohepjhhulhhivghnseigvghnrdhorhhgpdhrtghpthhtohepshhsthgrsg
    gvlhhlihhniheskhgvrhhnvghlrdhorhhgpdhrtghpthhtoheprghnughrvgifrdgtohho
    phgvrhefsegtihhtrhhigidrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Thu, 5 Jun 2025 18:08:33 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Jan Beulich 
Cc: xen-devel@lists.xenproject.org,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Stefano Stabellini ,
	Andrew Cooper 
Subject: Re: [PATCH v1 1/5] console: add relocation hook
Message-ID: 
References: 
 <4f1889dc03ec4aa2cc0cd2bd14523a2c6f670bdb.1748182535.git-series.marmarek@invisiblethingslab.com>
 <0b17da9c-57db-4a8b-90af-e53e45cb1243@citrix.com>
 
 <66cfdee6-5dc2-4139-8550-ef441fa7a7a0@suse.com>
 
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="s1Rvo7knGHNqT0rK"
Content-Disposition: inline
In-Reply-To: 


--s1Rvo7knGHNqT0rK
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 5 Jun 2025 18:08:33 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Jan Beulich 
Cc: xen-devel@lists.xenproject.org,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Stefano Stabellini ,
	Andrew Cooper 
Subject: Re: [PATCH v1 1/5] console: add relocation hook

On Thu, Jun 05, 2025 at 06:05:02PM +0200, Jan Beulich wrote:
> On 05.06.2025 16:51, Marek Marczykowski-G=C3=B3recki wrote:
> > On Thu, Jun 05, 2025 at 04:42:53PM +0200, Jan Beulich wrote:
> >> Why is it that this ring is dependent upon Xen's position? If the ring=
 was
> >> dynamically allocated, it wouldn't change position when Xen is moved.
> >=20
> > The console is setup quite early, I don't think I can allocate memory at
> > this stage, no?
>=20
> But you allocate before Xen is moved, I suppose.

Well, I have those buffers in BSS exactly to avoid the need to allocate
them (or rather: have bootloader allocate them for me).

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

--s1Rvo7knGHNqT0rK
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmhBwQIACgkQ24/THMrX
1ywW5wf/Sclq4O4yTiinMcc8gjohwtODTH28YG7DrzS1Pe7b8drGVY4hJVEoHq5b
hKJahZByn1jrT3+MfexUwal62m2bBjbKV7hu9RtXTy17T2ulMt2Idf57jhC0athj
eor514yIuBcsFMihLjYoTQc8k/O8nFYYwJv/6HG7ON1WzcZMmn1cwpHnrMYD6p0s
pm9GK9jDbqbIruzfJsmjntK+QMkcnKGt1B+xM/n+CHf3UBJXfuTD31LiVSKFCMBG
BJEQhPStaX0MH0uYW6uV/M7I4gyHlzx+n6FPu7WXVpkbC5hwV/WaYItdSz05G2kT
D0rnaxeWfIWErAHOp3gGvAfW2mtQfw==
=Anx9
-----END PGP SIGNATURE-----

--s1Rvo7knGHNqT0rK--


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 16:17:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 16:17:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007170.1386483 (Exim 4.92)
	(envelope-from )
	id 1uNDHe-0000hY-RH; Thu, 05 Jun 2025 16:17:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007170.1386483; Thu, 05 Jun 2025 16:17: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 1uNDHe-0000hR-Oi; Thu, 05 Jun 2025 16:17:38 +0000
Received: by outflank-mailman (input) for mailman id 1007170;
 Thu, 05 Jun 2025 16:17: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 1uNDHc-0000hK-Uu
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 16:17:37 +0000
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com
 [2a00:1450:4864:20::32b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9775d6ea-4228-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 18:17:35 +0200 (CEST)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-450ce671a08so7496135e9.3
 for ; Thu, 05 Jun 2025 09:17:35 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a4efe5b871sm25315533f8f.13.2025.06.05.09.17.34
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 09:17:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9775d6ea-4228-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749140255; x=1749745055; 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=Ta81yL4tdv/oVA3HF7172+CR2eK5+N3u4gx48LVUX+8=;
        b=QEvqItSDmJQEutsfF0AOnm3uHV++WdXvsZoQyTZX4x4uHYfHZxAmn+YH9C2pThzw0d
         0S0wToDCJDzJFkVpdJXs5ff3XHNgyuLm4xGwKWjE/DMx9Xw4RVuzgXwgQ25c+4wRYAAz
         U8AYAA2JEj0r06WslFyc0HZ0x0k2KikQb85mU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749140255; x=1749745055;
        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=Ta81yL4tdv/oVA3HF7172+CR2eK5+N3u4gx48LVUX+8=;
        b=rnutHEH5crfrN8As02CjSrmsIrhg9x+s+QirMG5XaML6lQ4PPUfWvftTC0BWMRyNRv
         aNdOOSS1qdKT72oQ5mqPyQ1emRNpHOShdvH6V7L8ab6RAJzsucWRE774k5XZ4At0RCrJ
         jpqilGHp0YAaptFpikYPLbHZQ68Udr8bLQ91+DP2Kv6jsjSg3U6F64VdSjm1Ham5P/LY
         rhFnsUVEbxhIiFfQ9W0DGNS5Vg3VLm0A0JaZqg408yznX8AvLu0tFg+9HIGCg5n0LgZE
         MJGB6PlKclqTwhcUQEm2uVEpl5KVkXO5EtvwbTBm4NQOtYxM4tM1CmH9c4g8YD4deFo7
         +N1Q==
X-Gm-Message-State: AOJu0YwysEj1FxFZL4+rQ3mCeczmmKUfoiufnxiSjv5auK2K8R+ENGIJ
	7/xEBaCDYjSB7NEex2ya0VISh5slmtKYZBgKczXdXdWLZxLUWI6CZg6kq50ZlzYtwPIw8ybVCST
	Fh6LN
X-Gm-Gg: ASbGnct0Lg0+23GaLNYSUi6nY0+d1QmcOu5osOKuKjIAE2te74Q1t2vUnKUK3JN8nxo
	ako9cIjgsiFtMcZ746dkKRhRbtJQ2HCoPuRwKdC0ES+7gQpOAcSShaloTiRfEZr5yDu0MbP1IHd
	0vNXDIaaZn2p4pBr3PfsHJGeI680fwfojFP2gBzKLepSbQ5D/fkHjK5Won8/2+/UoalofZlwcMx
	t/uVc77uoYM4gOJAR9rnhJ84fnrbonqcUHzEQ7ovQEr0bwsQnd1EBXjqb+Y2GpiFD9WpAOC9L/r
	f7c7vUpmU0+DvArGGvK/ockg39gq62y6kZEo2q8LD4Xiz3ufKLF18xjHPH2ReaHidY3iY7F57He
	JYu/2NI1vTSYRiY8WC28=
X-Google-Smtp-Source: AGHT+IGO+iiA+oLkMFpNylIfK80cSm1Yr2gKS1mu7bAh28rC/CuIlLWHmSCaWcIoAaPJ+vfMOHvNbA==
X-Received: by 2002:a05:600c:4f47:b0:450:d204:34ca with SMTP id 5b1f17b1804b1-451f0b07680mr70901855e9.18.1749140254666;
        Thu, 05 Jun 2025 09:17:34 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Anthony PERARD ,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Juergen Gross ,
	Anthoine Bourgeois 
Subject: [PATCH v3] x86/hvmloader: select xenpci MMIO BAR UC or WB MTRR cache attribute
Date: Thu,  5 Jun 2025 18:16:59 +0200
Message-ID: <20250605161659.18201-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The Xen PCI device (vendor ID 0x5853) exposed to x86 HVM guests doesn't
have the functionality of a traditional PCI device.  The exposed MMIO BAR
is used by some guests (including Linux) as a safe place to map foreign
memory, including the grant table itself.

Traditionally BARs from devices have the uncacheable (UC) cache attribute
from the MTRR, to ensure correct functionality of such devices.  hvmloader
mimics this behavior and sets the MTRR attributes of both the low and high
PCI MMIO windows (where BARs of PCI devices reside) as UC in MTRR.

This however causes performance issues for users of the Xen PCI device BAR,
as for the purposes of mapping remote memory there's no need to use the UC
attribute.  On Intel systems this is worked around by using iPAT, that
allows the hypervisor to force the effective cache attribute of a p2m entry
regardless of the guest PAT value.  AMD however doesn't have an equivalent
of iPAT, and guest PAT values are always considered.

Linux commit:

41925b105e34 xen: replace xen_remap() with memremap()

Attempted to mitigate this by forcing mappings of the grant-table to use
the write-back (WB) cache attribute.  However Linux memremap() takes MTRRs
into account to calculate which PAT type to use, and seeing the MTRR cache
attribute for the region being UC the PAT also ends up as UC, regardless of
the caller having requested WB.

As a workaround to allow current Linux to map the grant-table as WB using
memremap() introduce an xl.cfg option (xenpci_bar_uc=0) that can be used to
select whether the Xen PCI device BAR will have the UC attribute in MTRR.
Such workaround in hvmloader should also be paired with a fix for Linux so
it attempts to change the MTRR of the Xen PCI device BAR to WB by itself.

Overall, the long term solution would be to provide the guest with a safe
range in the guest physical address space where mappings to foreign pages
can be created.

Some vif throughput performance figures provided by Anthoine from a 8
vCPUs, 4GB of RAM HVM guest(s) running on AMD hardware:

Without this patch:
vm -> dom0: 1.1Gb/s
vm -> vm:   5.0Gb/s

With the patch:
vm -> dom0: 4.5Gb/s
vm -> vm:   7.0Gb/s

Reported-by: Anthoine Bourgeois 
Signed-off-by: Roger Pau Monné 
---
Changes since v2:
 - Add default value in xl.cfg.
 - List xenstore path in the pandoc file.
 - Adjust comment in hvmloader.
 - Fix commit message MIO -> MMIO.

Changes since v1:
 - Leave the xenpci BAR as UC by default.
 - Introduce an option to not set it as UC.
---
 docs/man/xl.cfg.5.pod.in                |  8 ++++
 docs/misc/xenstore-paths.pandoc         |  5 +++
 tools/firmware/hvmloader/config.h       |  2 +-
 tools/firmware/hvmloader/pci.c          | 49 ++++++++++++++++++++++++-
 tools/firmware/hvmloader/util.c         |  2 +-
 tools/include/libxl.h                   |  9 +++++
 tools/libs/light/libxl_create.c         |  1 +
 tools/libs/light/libxl_dom.c            |  9 +++++
 tools/libs/light/libxl_types.idl        |  1 +
 tools/xl/xl_parse.c                     |  2 +
 xen/include/public/hvm/hvm_xs_strings.h |  2 +
 11 files changed, 86 insertions(+), 4 deletions(-)

diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index c388899306c2..ddbff6fffc16 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -2351,6 +2351,14 @@ Windows L.
 Setting B with the default device_model "qemu-xen"
 requires at least QEMU 1.6.
 
+
+=item B
+
+B Select whether the memory BAR of the Xen PCI device should have
+uncacheable (UC) cache attribute set in MTRR.
+
+Default is B.
+
 =item B or B
 
 The groups of Microsoft Hyper-V (AKA viridian) compatible enlightenments
diff --git a/docs/misc/xenstore-paths.pandoc b/docs/misc/xenstore-paths.pandoc
index 01a340fafcbe..073bed91eec1 100644
--- a/docs/misc/xenstore-paths.pandoc
+++ b/docs/misc/xenstore-paths.pandoc
@@ -234,6 +234,11 @@ These xenstore values are used to override some of the default string
 values in the SMBIOS table constructed in hvmloader. See the SMBIOS
 table specification at http://www.dmtf.org/standards/smbios/ 
 
+#### ~/hvmloader/pci/xenpci-bar-uc = ("1"|"0") [HVM,INTERNAL]
+
+Select whether the Xen PCI device MMIO BAR will have the uncacheable cache
+attribute set in the MTRRs by hvmloader.
+
 #### ~/bios-strings/oem-* = STRING [HVM,INTERNAL]
 
 1 to 99 OEM strings can be set in xenstore using values of the form
diff --git a/tools/firmware/hvmloader/config.h b/tools/firmware/hvmloader/config.h
index 6e1da137d779..c159db30eea9 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -58,7 +58,7 @@ extern uint32_t *cpu_to_apicid;
 #define ACPI_TIS_HDR_ADDRESS 0xFED40F00UL
 
 extern uint32_t pci_mem_start;
-extern const uint32_t pci_mem_end;
+extern uint32_t pci_mem_end;
 extern uint64_t pci_hi_mem_start, pci_hi_mem_end;
 
 extern bool acpi_enabled;
diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index cc67b18c0361..747f6cfb6794 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -30,7 +30,7 @@
 #include 
 
 uint32_t pci_mem_start = HVM_BELOW_4G_MMIO_START;
-const uint32_t pci_mem_end = RESERVED_MEMBASE;
+uint32_t pci_mem_end = RESERVED_MEMBASE;
 uint64_t pci_hi_mem_start = 0, pci_hi_mem_end = 0;
 
 /*
@@ -116,6 +116,8 @@ void pci_setup(void)
      * experience the memory relocation bug described below.
      */
     bool allow_memory_relocate = 1;
+    /* Select the MTRR cache attribute of the xenpci device BAR. */
+    bool xenpci_bar_uc = false;
 
     BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_IO !=
                  PCI_COMMAND_IO);
@@ -130,6 +132,12 @@ void pci_setup(void)
     printf("Relocating guest memory for lowmem MMIO space %s\n",
            allow_memory_relocate?"enabled":"disabled");
 
+    s = xenstore_read(HVM_XS_XENPCI_BAR_UC, NULL);
+    if ( s )
+        xenpci_bar_uc = strtoll(s, NULL, 0);
+    printf("XenPCI device BAR MTRR cache attribute set to %s\n",
+           xenpci_bar_uc ? "UC" : "WB");
+
     s = xenstore_read("platform/mmio_hole_size", NULL);
     if ( s )
         mmio_hole_size = strtoll(s, NULL, 0);
@@ -271,6 +279,43 @@ void pci_setup(void)
             if ( bar_sz == 0 )
                 continue;
 
+            if ( !xenpci_bar_uc &&
+                 ((bar_data & PCI_BASE_ADDRESS_SPACE) ==
+                   PCI_BASE_ADDRESS_SPACE_MEMORY) &&
+                 vendor_id == 0x5853 &&
+                 (device_id == 0x0001 || device_id == 0x0002) )
+            {
+                if ( is_64bar )
+                {
+                     printf("xenpci dev %02x:%x unexpected MMIO 64bit BAR%u\n",
+                            devfn >> 3, devfn & 7, bar);
+                     continue;
+                }
+
+                if ( bar_sz > pci_mem_end ||
+                     ((pci_mem_end - bar_sz) & ~(bar_sz - 1)) < pci_mem_start )
+                {
+                     printf("xenpci dev %02x:%x BAR%u size %llx overflows low PCI hole\n",
+                            devfn >> 3, devfn & 7, bar, bar_sz);
+                     continue;
+                }
+
+                /* Put unconditionally at the end of the low PCI MMIO hole. */
+                pci_mem_end -= bar_sz;
+                pci_mem_end &= ~(bar_sz - 1);
+                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
+                bar_data |= pci_mem_end;
+                pci_writel(devfn, bar_reg, bar_data);
+                pci_devfn_decode_type[devfn] |= PCI_COMMAND_MEMORY;
+
+                /* Prefix BAR address with a 0 to match format used below. */
+                printf("pci dev %02x:%x bar %02x size "PRIllx": 0%08x\n",
+                       devfn >> 3, devfn & 7, bar_reg,
+                       PRIllx_arg(bar_sz), bar_data);
+
+                continue;
+            }
+
             for ( i = 0; i < nr_bars; i++ )
                 if ( bars[i].bar_sz < bar_sz )
                     break;
@@ -310,7 +355,7 @@ void pci_setup(void)
         }
 
         /* Enable bus master for this function later */
-        pci_devfn_decode_type[devfn] = PCI_COMMAND_MASTER;
+        pci_devfn_decode_type[devfn] |= PCI_COMMAND_MASTER;
     }
 
     if ( mmio_hole_size )
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 79c0e6bd4ad2..31b4411db7b4 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -867,7 +867,7 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
         config->table_flags |= ACPI_HAS_HPET;
 
     config->pci_start = pci_mem_start;
-    config->pci_len = pci_mem_end - pci_mem_start;
+    config->pci_len = RESERVED_MEMBASE - pci_mem_start;
     if ( pci_hi_mem_end > pci_hi_mem_start )
     {
         config->pci_hi_start = pci_hi_mem_start;
diff --git a/tools/include/libxl.h b/tools/include/libxl.h
index b7ad7735ca4c..7ce7678e6836 100644
--- a/tools/include/libxl.h
+++ b/tools/include/libxl.h
@@ -1503,6 +1503,15 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst, const libxl_mac *src);
  */
 #define LIBXL_HAVE_CREATEINFO_XEND_SUSPEND_EVTCHN_COMPAT
 
+/*
+ * LIBXL_HAVE_XENPCI_BAR_UC
+ *
+ * libxl_domain_build_info contains a boolean 'u.hvm.xenpci_bar_uc' field to
+ * signal whether the XenPCI device BAR should have UC cache attribute set in
+ * MTRR.
+ */
+#define LIBXL_HAVE_XENPCI_BAR_UC
+
 typedef char **libxl_string_list;
 void libxl_string_list_dispose(libxl_string_list *sl);
 int libxl_string_list_length(const libxl_string_list *sl);
diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_create.c
index 8bc768b5156c..962fa820faec 100644
--- a/tools/libs/light/libxl_create.c
+++ b/tools/libs/light/libxl_create.c
@@ -313,6 +313,7 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
         libxl_defbool_setdefault(&b_info->u.hvm.usb,                false);
         libxl_defbool_setdefault(&b_info->u.hvm.vkb_device,         true);
         libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci,   true);
+        libxl_defbool_setdefault(&b_info->u.hvm.xenpci_bar_uc,      true);
         libxl_defbool_setdefault(&b_info->u.hvm.pirq,               false);
 
         libxl_defbool_setdefault(&b_info->u.hvm.spice.enable, false);
diff --git a/tools/libs/light/libxl_dom.c b/tools/libs/light/libxl_dom.c
index 4d67b0d28294..60ec0354d19a 100644
--- a/tools/libs/light/libxl_dom.c
+++ b/tools/libs/light/libxl_dom.c
@@ -819,6 +819,15 @@ static int hvm_build_set_xs_values(libxl__gc *gc,
             goto err;
     }
 
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM &&
+        libxl_defbool_val(info->u.hvm.xenpci_bar_uc)) {
+        path = GCSPRINTF("/local/domain/%d/"HVM_XS_XENPCI_BAR_UC, domid);
+        ret = libxl__xs_printf(gc, XBT_NULL, path, "%d",
+                               libxl_defbool_val(info->u.hvm.xenpci_bar_uc));
+        if (ret)
+            goto err;
+    }
+
     return 0;
 
 err:
diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl
index 198515383012..6054350b83c7 100644
--- a/tools/libs/light/libxl_types.idl
+++ b/tools/libs/light/libxl_types.idl
@@ -691,6 +691,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
                                        ("vkb_device",       libxl_defbool),
                                        ("soundhw",          string),
                                        ("xen_platform_pci", libxl_defbool),
+                                       ("xenpci_bar_uc",    libxl_defbool),
                                        ("usbdevice_list",   libxl_string_list),
                                        ("vendor_device",    libxl_vendor_device),
                                        # See libxl_ms_vm_genid_generate()
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index 219e924779ff..4da3bb9e91ab 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -2917,6 +2917,8 @@ skip_usbdev:
         xlu_cfg_replace_string (config, "soundhw", &b_info->u.hvm.soundhw, 0);
         xlu_cfg_get_defbool(config, "xen_platform_pci",
                             &b_info->u.hvm.xen_platform_pci, 0);
+        xlu_cfg_get_defbool(config, "xenpci_bar_uc",
+                            &b_info->u.hvm.xenpci_bar_uc, 0);
 
         if(b_info->u.hvm.vnc.listen
            && b_info->u.hvm.vnc.display
diff --git a/xen/include/public/hvm/hvm_xs_strings.h b/xen/include/public/hvm/hvm_xs_strings.h
index e1ed078628a0..ebb07b9fba56 100644
--- a/xen/include/public/hvm/hvm_xs_strings.h
+++ b/xen/include/public/hvm/hvm_xs_strings.h
@@ -14,6 +14,8 @@
 #define HVM_XS_BIOS                    "hvmloader/bios"
 #define HVM_XS_GENERATION_ID_ADDRESS   "hvmloader/generation-id-address"
 #define HVM_XS_ALLOW_MEMORY_RELOCATE   "hvmloader/allow-memory-relocate"
+/* Set xenpci device BAR as UC in MTRR */
+#define HVM_XS_XENPCI_BAR_UC           "hvmloader/pci/xenpci-bar-uc"
 
 /* The following values allow additional ACPI tables to be added to the
  * virtual ACPI BIOS that hvmloader constructs. The values specify the guest
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 16:43:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 16:43:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007187.1386493 (Exim 4.92)
	(envelope-from )
	id 1uNDgD-0005pt-Py; Thu, 05 Jun 2025 16:43:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007187.1386493; Thu, 05 Jun 2025 16: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 1uNDgD-0005pm-NF; Thu, 05 Jun 2025 16:43:01 +0000
Received: by outflank-mailman (input) for mailman id 1007187;
 Thu, 05 Jun 2025 16:43:00 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uNDgC-0005pg-FC
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 16:43:00 +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 23768184-422c-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 18:42:59 +0200 (CEST)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-451d54214adso10551825e9.3
 for ; Thu, 05 Jun 2025 09:42:59 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a526057278sm3275358f8f.63.2025.06.05.09.42.57
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 09:42:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 23768184-422c-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749141778; x=1749746578; 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=jS5ousCDstlmnF7/5OSdRCNjs1Jf2SFLpZF6K4Qv/2A=;
        b=ujzpC09fULOULxDs93CXsb/jLswQTJ3QGsUXFbdYnB91lCzM4VFlxRSeiT3LU575+S
         AfFw9ilsbF+9uAI2BmVlWJe50GndLtYI5be44a4OBQJI3fuSx8EYsAt02EZiyh5Mxjk6
         MtXirI9ODe/3lar6ILC9ud4RwKB7ZfyJ5x0C8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749141778; x=1749746578;
        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=jS5ousCDstlmnF7/5OSdRCNjs1Jf2SFLpZF6K4Qv/2A=;
        b=luWUmZPrFOnfVrEHx6FuAft++GPEPSiMWIvKntoVcmiiZ1//9GqDi1S1uFTXuOmfEm
         VE2ragBqvUJwEGWnVlUD90ty/rW1qCgJvLbcO3/qJvvmVXw2zswCpx8reWFvmMsWreqK
         BP0tSEuomICaUUuTU/Bva7bWJJdA+Djrb1gjPI3xoNpG0gksH4h86iehZklKECt+sRqo
         +A4VqjdJeTiYC5zdeHepL+TGJGzZkRg9FOcm/+osO2ERwrM123MsR7msFZQRbGbICcXV
         BNx2ljbevzmZO7V16RCCXivv6oalnryJpi5gY0Rj+MYKtn0GDla10Nz3UrFRVeth+qbJ
         L+sw==
X-Gm-Message-State: AOJu0YywxOAS2fu8LgUW1zyQOeNcWHWd90PqFk4MGXC09XpnmmFkS3nA
	dP3xPGnmxYUu9fFWjeMjjF+u/+224BEOX90yvv2wKdi1dqVvGskftYk8QueG0a+bnpE=
X-Gm-Gg: ASbGncvx7CZxxumLiNNSFQbE3luElHiJydSp76TchCg61yffFKKTI9hxVbPARyNEUaT
	8X2p/mFt7/DkYsp1L+0vNr5muhygD0W6D6MO+/F9NBFuQZY+2m32g6b45I1E/ESvYP8SPjeLzAj
	QKBt+z75NDR+ZdUqT1M3KBJc7U+PQ/D/RnQWS/U8yzE85+Xk+hofvf76tIdK5cMB+zkcrkb/6Nr
	93PULKnj39Khn3nxgTOxzkKkFNp736Vtph3q6faO1BVWLCPm+DKIdSkSoHlpOxSjs3Xhkoh98Iw
	iz44+sPV2DSKtJFyE7+62in7XulaQMCDnudlTP28LA8vQoiZ9laUUoOqhly/jW/bAh/exYwdGBi
	CEfwI/2inMm458qmZ/l0=
X-Google-Smtp-Source: AGHT+IGW4zfyxVASdZjZXU2t5k0+1CB0DezzCdUkhzOB1D2Oso+yde2xrRETt41dj3ttXfPLUOCJ5w==
X-Received: by 2002:a05:600c:3b2a:b0:43c:fceb:91a with SMTP id 5b1f17b1804b1-451f0a76e2dmr75227615e9.11.1749141778497;
        Thu, 05 Jun 2025 09:42:58 -0700 (PDT)
Date: Thu, 5 Jun 2025 18:42:57 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Alejandro Vallejo 
Cc: xen-devel@lists.xenproject.org,
	Bernhard Kaindl ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH 02/11] xen/page_alloc: Remove `claim` from
 domain_set_outstanding_pages()
Message-ID: 
References: <20250314172502.53498-1-alejandro.vallejo@cloud.com>
 <20250314172502.53498-3-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250314172502.53498-3-alejandro.vallejo@cloud.com>

On Fri, Mar 14, 2025 at 05:24:53PM +0000, Alejandro Vallejo wrote:
> With a single global count for the claims it's easy to substract
> domain_tot_pages() from the claim so the number given in the hypercall
> is the real reservation of the domain. This is the current behaviour.
> 
> However, a later patch introduces exact-node claims and those interact
> very poorly with such a scheme. Since accounting domain_tot_pages() in
> one case but not the other seems strictly worse than not accounting them
> at all (which is at least consistent), this patch stops substracting
> tot_pages from the claim and instead checks that claimed memory +
> allocated memory don't exceed max_mem.

Hm, while I don't have any specific interest in keeping the current
behavior, XENMEM_claim_pages is part of the stable ABI (it's not a
domctl), and hence should be stable.  Note also the comment above the
definition of XENMEM_claim_pages how it states the specific behavior
that you are trying to change (and which should have been adjusted as
part of this change).

I have no idea why this was made a xenmem rather than a domctl
hypercall, but if you want to change the semantics I think the only
option is introducing a new hypercall.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 16:46:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 16:46:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007201.1386504 (Exim 4.92)
	(envelope-from )
	id 1uNDjg-0006P2-7f; Thu, 05 Jun 2025 16:46:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007201.1386504; Thu, 05 Jun 2025 16:46:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNDjg-0006Ov-3e; Thu, 05 Jun 2025 16:46:36 +0000
Received: by outflank-mailman (input) for mailman id 1007201;
 Thu, 05 Jun 2025 16:46: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 1uNDjf-0006Op-EJ
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 16:46:35 +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 a3f06573-422c-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 18:46:34 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a375888297so832794f8f.1
 for ; Thu, 05 Jun 2025 09:46:34 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a4efe5b962sm24680645f8f.7.2025.06.05.09.46.33
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 05 Jun 2025 09:46:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a3f06573-422c-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749141994; x=1749746794; 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=tF2RYmlrfsihfCJDHABaxRuBbzTraqXR8hxQV/ylMr8=;
        b=gr33vLP4I8lCoR2AWm90kohEu7MqlWwGESCaAHU+XuTnYL3nS+OF+a9tzBWIOgc/xI
         5fJw3SpDCbitdS4ku8/M22Qfeao9H/KV7Y/D5w5w3vJ4wLHLkdY5uaKN36ALx4nX9EC7
         bmonZg2HcBUAxiq/6kRHni1OebIgwrBT3UfQ0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749141994; x=1749746794;
        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=tF2RYmlrfsihfCJDHABaxRuBbzTraqXR8hxQV/ylMr8=;
        b=tCS1GF39+H8KLJkc0feSvHIgOAZz6KjmtAkz0ugI044B40NHYmoV9CMFvxnwoFbWol
         JiMOhh36Nvh6DLaqxofqZKVCYEBtUv7BHa2OSyKHgv6kNYaAp7BxZOigkQ4dBf8x6pG+
         LRgnCMG6MIeDYL03WX9+hy9OZRHjox/D189k4pCMLQIkMsryFgH6PSEQVbKarsvIoR7N
         75AW6NjS2w4uy6pov8VTwHDcSp2T2RlPZAIIKA76jV10uOC0ARimWAlXWZfrhtDmkMVE
         OonP64RrOeJyngbDVMwyC2FZoYmp2WNHFkFEAt3+dJMNzVqFJJFNi5VRFx15GbQ2ccLk
         Ljyg==
X-Gm-Message-State: AOJu0YwgnvNKH0u0MFnVx0TQ8c4+YymWWf4YakrF3w6k1zo3uV7ULtZI
	WPZADywT0BIwCQUVbhObrIGwuZDp2+WTBi/dLXg+wM1jTuC5fvZJ9JOjG7A2R1AmvkQ=
X-Gm-Gg: ASbGncsm8NcsmXF0gUE8Orloj0BaioK7iVHWuHSea2oEGyk+5kh/JOO3wiA2Pm4b2XW
	uVBK2Lj1qehps6O3hDTBBdGrPi4S0azgZeVlyFfgx2J1KeZQuch9SV1TNWaP4TkGCzChnM9WOy7
	F38tUPPD/iWnWCWqC0zg8tij78ZOhLfwGkAOeswGIBHEOCfnS3yF/wlxGe2Q9dzVxDVj6YTw3rN
	7mjNQEsD0jNeSm7+kUZiNUPJCmlxJDy/M4Sn1O7iszoSPoYTG/RwIzHE9Q6ouS9V9YwbuXA+Ppp
	U5tjyQWrcwO9vU8bsTSf+5M1G3Ff6+srSMh13eZL+v1wTxjqjhnBJIY61rSaXX0v0KFkbXK/3cl
	LuMEsDoWzMyGYFwYZ3oM=
X-Google-Smtp-Source: AGHT+IG/mMzq/AsY9m/PASllsxJuaaE8S5HeQ9m4s0iN+w5ISImeeXMzN421WZNvEjhRvXAxvbV+Mw==
X-Received: by 2002:a5d:5f96:0:b0:3a4:d685:3de7 with SMTP id ffacd0b85a97d-3a526dcdd91mr3846479f8f.8.1749141994007;
        Thu, 05 Jun 2025 09:46:34 -0700 (PDT)
Date: Thu, 5 Jun 2025 18:46:32 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Alejandro Vallejo 
Cc: xen-devel@lists.xenproject.org,
	Bernhard Kaindl ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH 03/11] xen/page_alloc: Add static per-node counts of free
 pages
Message-ID: 
References: <20250314172502.53498-1-alejandro.vallejo@cloud.com>
 <20250314172502.53498-4-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250314172502.53498-4-alejandro.vallejo@cloud.com>

On Fri, Mar 14, 2025 at 05:24:54PM +0000, Alejandro Vallejo wrote:
> These are effectively the sum of free memory in all zones of each node.
> It's an optimization to avoid doing that operation frequently in
> following patches that introduce exact-node claims.
> 
> Signed-off-by: Alejandro Vallejo 
> ---
>  xen/common/page_alloc.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
> index 49c3258169db..733b0300a767 100644
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -485,6 +485,9 @@ static unsigned long node_need_scrub[MAX_NUMNODES];
>  static unsigned long *avail[MAX_NUMNODES];
>  static long total_avail_pages;
>  
> +/* Per-node counts of free pages */
> +static unsigned long pernode_avail_pages[MAX_NUMNODES];
> +
>  static DEFINE_SPINLOCK(heap_lock);
>  static long outstanding_claims; /* total outstanding claims by all domains */
>  
> @@ -1033,6 +1036,7 @@ static struct page_info *alloc_heap_pages(
>  
>      ASSERT(avail[node][zone] >= request);
>      avail[node][zone] -= request;
> +    pernode_avail_pages[node] -= request;

Since it's done for the per-zone tracking, you might as well add:

ASSERT(pernode_avail_pages[node] >= request);

here?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 16:48:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 16:48:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007207.1386513 (Exim 4.92)
	(envelope-from )
	id 1uNDlL-0006v3-H2; Thu, 05 Jun 2025 16:48:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007207.1386513; Thu, 05 Jun 2025 16: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 1uNDlL-0006uw-EE; Thu, 05 Jun 2025 16:48:19 +0000
Received: by outflank-mailman (input) for mailman id 1007207;
 Thu, 05 Jun 2025 16: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 1uNDlK-0006un-Nr
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 16:48:18 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20602.outbound.protection.outlook.com
 [2a01:111:f403:200a::602])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e0160857-422c-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 18:48:17 +0200 (CEST)
Received: from BL1PR13CA0141.namprd13.prod.outlook.com (2603:10b6:208:2bb::26)
 by DM4PR12MB6495.namprd12.prod.outlook.com (2603:10b6:8:bc::19) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.35; Thu, 5 Jun
 2025 16:48:12 +0000
Received: from BL6PEPF0001AB54.namprd02.prod.outlook.com
 (2603:10b6:208:2bb:cafe::2e) by BL1PR13CA0141.outlook.office365.com
 (2603:10b6:208:2bb::26) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Thu,
 5 Jun 2025 16:48:12 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL6PEPF0001AB54.mail.protection.outlook.com (10.167.241.6) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Thu, 5 Jun 2025 16:48:12 +0000
Received: from localhost (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, 5 Jun
 2025 11:48:09 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e0160857-422c-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=APCmNb+QpUhZJB6Xg96ZWi+qOChMFqJw3R0YAccDVmWKjS8Zlk3HqzhAbxbDWMbyrI0qk0rjHliNZ6dqtKEir4RC3TVaKG6EK7T732yclMfyw804wZECFOsUVjhlA1wfta/Uzl3J//z+a9rMyznjUC5gpgQFhrxFstXZ+guwFy8nTLJGD/3YRqFAaXII12wZPCzWbGeRuF5JGGWXmzXIKHas6+BEAznwAnllWj7FyNgLnvftIFa92Znd6Xs1URddNLxXbWnxzLM7sVjMrEonMlnIsjmdq4TJuR/8WBS/PuuOQnOXe6qTnvOutdmlozDbXlOBqIYxvrRoO/kcXRGykw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=brQBMa16MGPBhDyBTlggoh/GIRLyydfBBwScQfBaSsA=;
 b=SXy2w8GRgEXd0HK3kRKhMW/blUex6qitkZzzVTK3h3xNWtgPi8uxwBX8QYqTX7dKeSrT9IhcYLpCMvEaO6nUm4fVhqW9QpEkZXnb/nJhI7fcsPXIaS1K6sjw41UP6qYopO+l0BWce0QsYUtCe9ps28ub9NJtPe+JnTNQpLfRzG81eVQ4CS+KRee/PmkhJEiO4zZB9U3Dc0BKNFOYWFBq1aCuvn/6Ab7Nw7EIQo+MrRdqVRblOKVVqYTDClyQgMq23uBmlbvRHLMwWDS5E+9cFXrrIip47FTp2FPDnWRXG5M++E5TUbGf65uaKYVzrrfP/CXxrwJpnBDBtljI4WdeCQ==
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=brQBMa16MGPBhDyBTlggoh/GIRLyydfBBwScQfBaSsA=;
 b=yGcqc70cfQakgeie9+Fxv5jtOETTd6wfLTT79X+uAC1kbUMLYHnOlGiRLNvumD6Cbdlp7yZ32TkUhrWxsgRh37JbJ7UHaRAOeHrNQYxQteSCcYBudNfaaL81sDH2EKh7Rp6kshqvVNvuZfQ0JzTUG0dXkk7mwKEdwSTMPYiSSSI=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 5 Jun 2025 18:48:08 +0200
Message-ID: 
CC: Alistair Francis , Bob Eshleman
	, Connor Davis , "Oleksii
 Kurochko" , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	=?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini
	, "Daniel P. Smith" ,
	
Subject: Re: [PATCH 06/19] xen: Clean up asm-generic/device.h
From: Alejandro Vallejo 
To: Jan Beulich 
X-Mailer: aerc 0.20.1
References: 
 <20250530120242.39398-1-agarciav@amd.com>
 <20250530120242.39398-7-agarciav@amd.com>
 
 
 
 
 <8768b970-6c62-4fc4-8ef5-b74f1aa650e6@suse.com>
In-Reply-To: <8768b970-6c62-4fc4-8ef5-b74f1aa650e6@suse.com>
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: BL6PEPF0001AB54:EE_|DM4PR12MB6495:EE_
X-MS-Office365-Filtering-Correlation-Id: 5766f39d-338e-41dc-e491-08dda450c28a
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|7416014|376014|82310400026|1800799024|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?eW8xYW1MOFk2ci9QZ0RBTDZvUEw3WUNsVUZXd2RSaU1IcnhvYndwT0dwdzRZ?=
 =?utf-8?B?L3prZ3JxeEhyUnFEVHVIeXdua1B0RHdXaGdmRjZzZEE2NkQrYXd6b0JyVFBy?=
 =?utf-8?B?bHJxZlFJZVRpYXRGdFZLallOMnNsUGRFaXQzOFJyaTloQnlEanROVkd5SHNZ?=
 =?utf-8?B?TUhDbHRZVng0dU05d1NuVnN6NnFYZU95b0MwUHhVR0JLSXQ1TGtKZ3ZqR0Ix?=
 =?utf-8?B?OGZyUFA4cC9zNDJUWk5zYU01dzNmU0ZqWUg3UHlxdWJQTGpsSUhRcEdXWHdL?=
 =?utf-8?B?Z1Vrc3E3bkJCNnNxOVBaQ0U4S0NBRzFqTEtSM0dCZEVQaTJ1VkF0cHZ6VzMx?=
 =?utf-8?B?ZjVlQUJmRCtVQnNXTXVIZjVrdnNjUm9MeTVpNnZvanJEOEhvRnJWSythdUgx?=
 =?utf-8?B?NGljQWI2eE1yS3hBc29vcXI0ZlMvSkdlNExadFlhS3l0VFAwS2VjbjkvcDVz?=
 =?utf-8?B?ek9HYWxFUml2Ti84M1JObUZJR0dRWHRsY3Q2L2F4WkFLTjEwRWEzN3pJY0Zq?=
 =?utf-8?B?d3JiTWNFVHlMT09UblprSDY1U2h3WHQ4QnZxaUpmN3hPM3djeHNRUEkvR3RY?=
 =?utf-8?B?VVo4NWpUTlU5RmVZM2pIUW8rdDNQeE81NHQ0NEU2MW5wY1VYZmJEckRpemVl?=
 =?utf-8?B?cXBpalI3MnZsSzFWcHk1dTQwNC9iallTNlNuK1d5VEtQcXZyZ3RPMldKbFh3?=
 =?utf-8?B?c05LOWx1NDN3cmt1N1BmZVhHenRIK3I1OUFnUCtTMERQaHBtVE5DZkFMYUJE?=
 =?utf-8?B?TVRsbDhTU3RuK3Z3RWxWN0RMMW05RStJMVVLU3NUL3BIOUNpdCtsajFsbzNm?=
 =?utf-8?B?SFFoOW5rUGNtUmNxZHEyWUtFaXlRb3k1NHpYWXFlZVVMNG9jQnRmdHlSK0da?=
 =?utf-8?B?bFVDanZBSVNETUN3emNKZ2hjK01VNnZyME5idkcwZ1czS3lmMU9wQWMyVVAw?=
 =?utf-8?B?Wml3dnptOVcyMVRFdnhRMGZGZWoyN3o1eHRBa0VIUG8xaTU5bU53amNIWTF0?=
 =?utf-8?B?djFBRWFteDRsdjRnQW1TQ2ZpOThIVmluZjJCbG9ZQVFiZ2dlWXc5S2RwUlVz?=
 =?utf-8?B?clRHQkxlMGdOLy9rbnBjRCsyRHcvS1A1NHZaSmpuRm4yUngyb3VBMExDUHAr?=
 =?utf-8?B?OWphWTJVK2VOc0Z6OXNiU1hBb3BMWmc5bEIvVmkzeEFVMlR2ellWTHZmaWRT?=
 =?utf-8?B?ckwyQXdid0JLOFFWd3NNV0ZPaStIRW1aS2IvT3lIKzIwTVZNNzlCSHJPR0lo?=
 =?utf-8?B?SjUxOHo5Y1E3ZXZlMmhXWk0rLzIwdlp5MXljTzF4QmtwRnByeWY5QnNSdlZQ?=
 =?utf-8?B?dzdYbTdsT1VFU09BUnRVVGhsMlc5T25hWDRDNU1lWE9EUDBhTkJyU3RGQ25k?=
 =?utf-8?B?QXpMb05sV3pzcUxoOU1EclY1U2xsVXVqK2JUcTRMa2NHZWFTV243Y3E0SXpo?=
 =?utf-8?B?bVYyZXB0czE3Q2FFS29UYm1pclJ3aVFsdDVhWEJjcndrUU1UVHB0UU1JVG9h?=
 =?utf-8?B?aERZWW9KdHE5aXNYQktDV1J4Zmt2OERZNUp4YTkxcXNrU0dBQnAyckVHWi96?=
 =?utf-8?B?UEFkTjVWS2FwbXdZRlJFQjhsekUrWCt0bW9xcGRzQkYzd3NaQzdURDVsWEVO?=
 =?utf-8?B?VnVBYkRMckNyWnJUUkU3V205eUFqcno2ZVM3eExvNUFPNTgvQjYxbFk2TVZS?=
 =?utf-8?B?U29FTUdNZXBkR1BMN2hmWU9VdUNnMVhOZlEwN1pQZlZCMk0xekMzbG05Y25O?=
 =?utf-8?B?REE0VFlQdlVmaVF5bUFSVEthUUMxSU5ZcjhINmo0Wi9aUEl3clhROE9jbkZq?=
 =?utf-8?B?VnFXTW1YWDdaMW1DZG5WUWNkNjNyVXN6SjhRaVErd0QybmpJOUFzNlBBTW51?=
 =?utf-8?B?Y2tSTC9ld3hLYlo2UG1JTWdLelB1T3ZBR2V1VFl0WHNMVjNCNWRqcDZpNHlW?=
 =?utf-8?B?U1ZuU3BFNXYzMitUeEZKeTBvMSt0WUxFVU9NaFNZbU5Zb0pTQVlVTTg5MzZ3?=
 =?utf-8?B?MG93ek1ZUlhqdy9sdml2Q0oxSXRCNFU1MmZZaWNLTmRJZzF5S0ZuUDBLZ1Yv?=
 =?utf-8?Q?7V4ZW+?=
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)(1800799024)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jun 2025 16:48:12.4137
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5766f39d-338e-41dc-e491-08dda450c28a
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:
	BL6PEPF0001AB54.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6495

On Thu Jun 5, 2025 at 4:20 PM CEST, Jan Beulich wrote:
> On 05.06.2025 16:15, Alejandro Vallejo wrote:
>> On Mon Jun 2, 2025 at 4:24 PM CEST, Jan Beulich wrote:
>>> On 02.06.2025 16:19, Alejandro Vallejo wrote:
>>>> On Mon Jun 2, 2025 at 9:51 AM CEST, Jan Beulich wrote:
>>>>> On 30.05.2025 14:02, Alejandro Vallejo wrote:
>>>>>> --- a/xen/include/asm-generic/device.h
>>>>>> +++ b/xen/include/asm-generic/device.h
>>>>>> @@ -6,9 +6,7 @@
>>>>>> =20
>>>>>>  enum device_type
>>>>>>  {
>>>>>> -#ifdef CONFIG_HAS_DEVICE_TREE
>>>>>>      DEV_DT,
>>>>>> -#endif
>>>>>
>>>>> Why would this enumerator need exposing on a non-DT arch? In fact I w=
ould have
>>>>> hoped for ...
>>>>
>>>> A non-DT arch would not include this. x86 doesn't.
>>>
>>> Both here and ...
>>>
>>>>>>      DEV_PCI
>>>>>
>>>>> ... this to be hidden for arch-es not supporting PCI.
>>>>>
>>>>> Similar concerns elsewhere in this change.
>>>>
>>>> This file is exclusively used by arches supporting DT to abstract away=
 where
>>>> the device came from. x86 does not use it at all, and while it wouldn'=
t be
>>>> impossible to compile-out DEV_PCI, it would needlessly pollute the cod=
ebase with
>>>> no measurable gain, because the abstractions still need to stay.
>>>
>>> ... here: In "xen/include/asm-generic/device.h" there's nothing at all =
saying
>>> that this file is a DT-only one. Instead there is something in there sa=
ying
>>> that it's suitable to use in the entirely "generic" case.
>>>
>>> Jan
>>=20
>> Try to use it from x86 and observe the build system catch fire. It could=
 be made
>> to not go on fire, but it implies heavy refactoring in x86 (particularly=
 IOMMU
>> code) for no good reason because there's no devices in a DTB to disambig=
uate.
>>=20
>> How about adding this to the top of the header?
>>=20
>> ```
>>  /*
>>   * This header helps DTB-based architectures abstract away where a part=
icular
>>   * device comes from; be it the DTB itself or enumerated on a PCI bus.=
=20
>>   */
>>=20
>>   [snip]
>>=20
>>  #ifndef CONFIG_HAS_DEVICE_TREE
>>  #error "Header meant to be used exclusively by DTB-base architectures."
>>  #endif
>> ```
>
> Might be fine, together with giving the file a name somewhat referring to=
 DT.
>
> Jan

That would bring it out of sync with x86's asm/device.h. Both of them defin=
e
device_t and doing so in differently named headers would just be confusing =
for
everyone.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 16:59:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 16:59:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007214.1386526 (Exim 4.92)
	(envelope-from )
	id 1uNDw2-0000UZ-Gj; Thu, 05 Jun 2025 16:59:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007214.1386526; Thu, 05 Jun 2025 16:59: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 1uNDw2-0000US-E5; Thu, 05 Jun 2025 16:59:22 +0000
Received: by outflank-mailman (input) for mailman id 1007214;
 Thu, 05 Jun 2025 16:59: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 1uNDw1-0000UM-H5
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 16:59:21 +0000
Received: from mail36.us4.mandrillapp.com (mail36.us4.mandrillapp.com
 [205.201.136.36]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6b294e8a-422e-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 18:59:19 +0200 (CEST)
Received: from pmta15.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail36.us4.mandrillapp.com (Mailchimp) with ESMTP id 4bCrJj4h0RzS62TTh
 for ; Thu,  5 Jun 2025 16:59:17 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 c5a0f23d0add42c99c15c3006c6f0ad8; Thu, 05 Jun 2025 16:59: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: 6b294e8a-422e-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1749142757; x=1749412757;
	bh=nJRgkP5vL2W6h9s/7X+kDF22JRxUuQPxBXBvy+T4DqA=;
	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=uEkpiBCHR5H3xBd3uv1CCtFKfRvmIzIQtUdbNcvSUxL5sdJmr5YOf59iKULsgCNFk
	 JEUzeRsXeTSBnVoHJxd0ei1sFOpMV3cMQL4PP9wvuWYU9SsPmhJT8Ro7dYZqbWTUmQ
	 MVh5Yl5jAOO5gGR2LsLimpci+DDofYZ+ueya0M4h5mzoAfPeEXly7HnwMFyTMWe8ma
	 3Uqh2pYmqZ677/q8MfztKKhAFBmXl1RuIoIg5Z0Zcx+suS9hGIoYTY+w4pcyCQX+BX
	 9klhKrPzjlAN8Oda6lUp+UJFq/PDSPviCFg50BCBSwak0gpSOq6+CZQrWNpJlX5vvn
	 2vlBBikjMgIew==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1749142757; x=1749403257; i=teddy.astie@vates.tech;
	bh=nJRgkP5vL2W6h9s/7X+kDF22JRxUuQPxBXBvy+T4DqA=;
	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=1iuhBHyfzNLWJO6Gi1Uvnxd+zCMsCk6wln79/gTQZQlSHOpcFZJtiNXO8R8KCaNaZ
	 jGbvtD8XbBEJ5ORzT/7vegWU3E8yeSQUc/MANL8Whct9TyUzzLyGo3fUxHsRRPpAqz
	 pZ57S4pzZK4HD/z+yJVo5ptwRJBFVZA1y/LJH8juoaSJMgtP6MT+P8nQbf17XaESEy
	 k88n+zpG+3q3u9G7smEw3RmC0rC4wNu85UOikaNLQBRotpX2DxzPommA6iEORH3SMU
	 xZo4v3y+pDVJRYkICAZ1JsKyDR0cHAjPATnW1vLqxMmOw29dVWP36PbRIO7DGDR7Ki
	 JCp3oxl37yMJQ==
From: "Teddy Astie" 
Subject: =?utf-8?Q?Re:=20[PATCH=20v5=202/6]=20x86:=20re-work=20memset()?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1749142756596
Message-Id: 
To: "Jan Beulich" , xen-devel@lists.xenproject.org
Cc: "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" 
References: <73481cbf-337f-4e85-81d2-3487366cd822@suse.com> <4592a702-acf3-4229-9069-d5b639151657@suse.com>
In-Reply-To: <4592a702-acf3-4229-9069-d5b639151657@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.c5a0f23d0add42c99c15c3006c6f0ad8?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250605:md
Date: Thu, 05 Jun 2025 16:59:17 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Le 05/06/2025 =C3=A0 12:26, Jan Beulich a =C3=A9crit=C2=A0:
> Move the function to its own assembly file. Having it in C just for the
> entire body to be an asm() isn't really helpful. Then have two flavors:
> A "basic" version using qword steps for the bulk of the operation, and an
> ERMS version for modern hardware, to be substituted in via alternatives
> patching.
> 
> For RET to be usable in an alternative's replacement code, extend the
> CALL/JMP patching to cover the case of "JMP __x86_return_thunk" coming
> last in replacement code.
> 
> Signed-off-by: Jan Beulich 
> ---
> We may want to consider branching over the REP STOSQ as well, if the
> number of qwords turns out to be zero.
> We may also want to consider using non-REP STOS{L,W,B} for the tail.
> ---
> v5: Re-base.
> v4: Use %r8 instead of %rsi in a few places.
> v3: Re-base.
> 
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -47,6 +47,7 @@ obj-$(CONFIG_RETURN_THUNK) +=3D indirect-t
>   obj-$(CONFIG_PV) +=3D ioport_emulate.o
>   obj-y +=3D irq.o
>   obj-$(CONFIG_KEXEC) +=3D machine_kexec.o
> +obj-y +=3D memset.o
>   obj-y +=3D mm.o x86_64/mm.o
>   obj-$(CONFIG_VM_EVENT) +=3D monitor.o
>   obj-y +=3D mpparse.o
> --- a/xen/arch/x86/alternative.c
> +++ b/xen/arch/x86/alternative.c
> @@ -346,6 +346,12 @@ static int init_or_livepatch _apply_alte
>           /* 0xe8/0xe9 are relative branches; fix the offset. */
>           if ( a->repl_len >=3D 5 && (*buf & 0xfe) =3D=3D 0xe8 )
>               *(int32_t *)(buf + 1) +=3D repl - orig;
> +        else if ( IS_ENABLED(CONFIG_RETURN_THUNK) &&
> +                  a->repl_len > 5 && buf[a->repl_len - 5] =3D=3D 0xe9 &&
> +                  ((long)repl + a->repl_len +
> +                   *(int32_t *)(buf + a->repl_len - 4) =3D=3D
> +                   (long)__x86_return_thunk) )
> +            *(int32_t *)(buf + a->repl_len - 4) +=3D repl - orig;

That looks a bit confusing, to me that probably some comment explaining 
what instructions transform it's looking to make.

>   
>           a->priv =3D 1;
>   
> --- /dev/null
> +++ b/xen/arch/x86/memset.S
> @@ -0,0 +1,30 @@
> +#include 
> +

It would be nice to have a reminder of the calling convention (i.e what 
register maps to what memset parameter) as it will definitely help 
future readers.

If I understand correctly here :
- rdi: destination (s)
- rsi: byte to write (c)
- rdx: number of bytes to write (n)
- eventually that rcx =3D rdx (mov %rdx, %rcx) in memset/memset_erms

> +.macro memset
> +        and     $7, %edx
> +        shr     $3, %rcx
> +        movzbl  %sil, %esi
> +        mov     $0x0101010101010101, %rax
> +        imul    %rsi, %rax
> +        mov     %rdi, %r8
> +        rep stosq
> +        or      %edx, %ecx
> +        jz      0f
> +        rep stosb
> +0:
> +        mov     %r8, %rax
> +        RET
> +.endm
> +
> +.macro memset_erms
> +        mov     %esi, %eax
> +        mov     %rdi, %r8
> +        rep stosb
> +        mov     %r8, %rax
> +        RET
> +.endm
> +

Overall, I am a bit confused on the mixing of 32-bits (edx, esi, ...) 
and 64-bits registers (rax, ...). But it looks ok to me.

> +FUNC(memset)
> +        mov     %rdx, %rcx
> +        ALTERNATIVE memset, memset_erms, X86_FEATURE_ERMS
> +END(memset)
> --- a/xen/arch/x86/string.c
> +++ b/xen/arch/x86/string.c
> @@ -22,19 +22,6 @@ void *(memcpy)(void *dest, const void *s
>       return dest;
>   }
>   
> -void *(memset)(void *s, int c, size_t n)
> -{
> -    long d0, d1;
> -
> -    asm volatile (
> -        "rep stosb"
> -        : "=3D&c" (d0), "=3D&D" (d1)
> -        : "a" (c), "1" (s), "0" (n)
> -        : "memory");
> -
> -    return s;
> -}
> -
>   void *(memmove)(void *dest, const void *src, size_t n)
>   {
>       long d0, d1, d2;
> 
> 

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 Jun 05 17:01:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 17:01:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007224.1386535 (Exim 4.92)
	(envelope-from )
	id 1uNDxi-00028V-US; Thu, 05 Jun 2025 17:01:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007224.1386535; Thu, 05 Jun 2025 17:01:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNDxi-00028O-Rk; Thu, 05 Jun 2025 17:01:06 +0000
Received: by outflank-mailman (input) for mailman id 1007224;
 Thu, 05 Jun 2025 17: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 1uNDxh-00028G-Lt
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 17:01:05 +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 aa9dd74f-422e-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 19:01:04 +0200 (CEST)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-45024721cbdso10331695e9.2
 for ; Thu, 05 Jun 2025 10:01:04 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a528fd6810sm2335786f8f.27.2025.06.05.10.01.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 10:01:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: aa9dd74f-422e-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749142864; x=1749747664; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=YfivrmoX0ONYTeqvomWWAChfQ+T9BIWZ3/FlVOJC+Bc=;
        b=tC1y8k7s+ozjjZv/6LMr6BGdsJQb1q1WtRif9uzs+m1VbyEtyYKkjOEXETbgX5EINN
         8LzTXAIIsdqN4FE6GxBSCq4BDgi9e3ZGsrpfoIcPLs4z/w7oXX2wKX/RzR1cNrM3dtrb
         uZV/zghvdyul9vrwyUwgOQVFCNEc4/8JqEO8k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749142864; x=1749747664;
        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=YfivrmoX0ONYTeqvomWWAChfQ+T9BIWZ3/FlVOJC+Bc=;
        b=lcMJ5BSeD0mV24V50o2fKdnHZnGqZsp4x/ZGKGIrzDqfyBff/yzhZVlkjGFF9I14ht
         GfSWV+/x87/761a19BWLpaAFESPjKw88U+y7F/GUjU4FBOhFGisp01ETpZR8HzrE9Ynz
         QNerhaJ9YKKl8IeUk8vstVudOEVly3SMLX6YwNJ/5xQS2uIZ5TAku8N0D5Opokhjb6Mp
         IALmo4jMr7iS7tNyxrjX/tGdajG+K0Ymsh4OJ+cDJGbZ1Kg8R5xcQX8Kxb98TstvQPxe
         0LHQ4HNL0feJKLQDPqtN90xQmhVabnj/5HjgQXaNmwH1UQwogVkxBIImemhPF7jRC5IG
         Me6g==
X-Forwarded-Encrypted: i=1; AJvYcCVS6VS8h/m2GHAG4WbMHE+FnnC+l7QMmg/ecNsqqfwYS7fQ7epx415hwamqTrDQO7XUggh4dQ7ot5w=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyBddkLCzhumD4HQkhNPpma2qtX6svSIpVMAV4g5kl3YSfk70Fh
	wiyQ+G5IzxRkYSitHq0Il9xpVpMBHqzEnKpUbLObHMOZocHobnhTx5W9R/P0+q5PaLg=
X-Gm-Gg: ASbGncsujkzOcNwn0K6ujl4zX9XCYrdSyQR6XCnMf+VuQ2LtmdlO5jpTAygqJ9MvfoQ
	cys+Lv+c7LdmXXGySyvKKtgYMAxCvPo4WdKjucRb4jsjgBp8NcLZM1iGL3ARgUd8xCQpo/g+Zs8
	U5q0Z7MWPYPO4J/8SsfN+0w8pkRDv5WebpCHP9wkjiEEUE1NgbWCYXbNknZujQX9fnoRQ1xdkqc
	x4T0nbwDGdJrNHoG97+xJ/hfV+G8dXezfmp1WlAwm5zR8docwMtBa7UfifrABOppN1zSx/+ZBsU
	F+KsdwsT9RJpI6CSxybUmSU12NtU360e60zVbMD667bt8W4x5HauxZS7Hdlvw/rFIJm+baXVzJ/
	Ko8K/Zw+hKJXNMaRJ
X-Google-Smtp-Source: AGHT+IFHPcrElHFm4KZc6ptBsMWQHeWeUPAcwIRRjh8Nr1ykv4GXNv/IxliRBHVugqeuDb1XACqtJw==
X-Received: by 2002:a05:600c:8b43:b0:43d:fa59:af97 with SMTP id 5b1f17b1804b1-45201427c5amr201105e9.32.1749142864028;
        Thu, 05 Jun 2025 10:01:04 -0700 (PDT)
Message-ID: <9200277c-aa8e-4fd9-ab6a-f9e106114f54@citrix.com>
Date: Thu, 5 Jun 2025 18:01:02 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/3] x86/EFI: Fix detection of buildid
To: Jan Beulich 
Cc: Ross Lagerwall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 "Daniel P . Smith" ,
 Xen-devel 
References: <20250605111638.2869914-1-andrew.cooper3@citrix.com>
 <20250605111638.2869914-2-andrew.cooper3@citrix.com>
 <0a314400-126a-4c2a-b36c-dda61bb0b751@suse.com>
 
 <4d1f1b70-e309-453b-bae6-e066d49a417a@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: <4d1f1b70-e309-453b-bae6-e066d49a417a@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 05/06/2025 2:24 pm, Jan Beulich wrote:
> On 05.06.2025 14:14, Andrew Cooper wrote:
>> On 05/06/2025 1:02 pm, Jan Beulich wrote:
>>> On 05.06.2025 13:16, Andrew Cooper wrote:
>>>> The format of the buildid is a property of the binary, not a property of how
>>>> it was loaded.  This fixes buildid recognition when starting xen.efi from it's
>>>> MB2 entrypoint.
>>>>
>>>> Suggested-by: Ross Lagerwall 
>>>> Signed-off-by: Andrew Cooper 
>>> I'll pick this up without a Fixes: tag, but I think it ought to have one. (I
>>> didn't check whether MB2 or build-id support came later, hence introducing the
>>> issue.)
>> MB2+EFI came long before any buildid support.  If you want a fixes tag,
>> it's eee5909e9d1
> That commit talks of an earlier hack, though. And no, MB2 work came later,
> albeit still in the 4.9 dev window (commit 9180f53655245).

The "previous hack" was embedding note.o (from the livepatch test
infrastructure) back in the main xen binary.

That's still present.  For xen.gz you get an elf note.  For xen.efi, it
may be an elf note or a CodeView region, depending on the toolchain.

>
>>>> --- a/xen/common/version.c
>>>> +++ b/xen/common/version.c
>>>> @@ -203,8 +203,11 @@ void __init xen_build_init(void)
>>>>      rc = xen_build_id_check(n, sz, &build_id_p, &build_id_len);
>>>>  
>>>>  #ifdef CONFIG_X86
>>>> -    /* Alternatively we may have a CodeView record from an EFI build. */
>>>> -    if ( rc && efi_enabled(EFI_LOADER) )
>>>> +    /*
>>>> +     * xen.efi built with a new enough toolchain will have a CodeView record,
>>>> +     * not an ELF note.
>>>> +     */
>>>> +    if ( rc )
>>> Instead of dropping the efi_enabled(), I think you want to replace EFI_LOADER
>>> by EFI_BOOT.
>> No - that's differently buggy.  I suppose the commit message wasn't
>> clear enough?
>>
>> We'd still have a CodeView record if we booted xen.efi using it's MB2
>> entrypoint without the EFI extensions.
> Hmm, if that's a possible mode of operation (as said in reply to Marek, I
> wasn't aware of that) - yes.

It's how I found the bug.

There's an awful lot of hackery in the patch-queue holding it together,
but in this case it's not really about MB2 or anything else; it's
xen_build_init() being incorrect in how it determines whether there's a
CodeView region or not.

>
>> This really is a property of being a PE32+ binary, and nothing to do
>> with EFI.
> Which still can be checked for without having this code path being taken
> for xen.gz, too: You could e.g. check for &efi > &_end. That's firmly an
> image property (yet I expect you're going to sigh about yet another hack).

It's all hacks, but no.

I'm amazed MISRA hasn't spotted that we've got a global `struct efi
efi;` and a label named efi, creating an alias for the object with it
out of bounds in the compiled image.  But even then, it's based on
XEN_BUILD_EFI not XEN_BUILD_PE and does not distinguish the property
that matters.

But the argument I'm going to make this this:  Why do you want a check,
even if you can find a correct one (and as said before, I cannot)?

This function is run exactly once.  We've excluded "nothing given by the
toolchain", and excluded "what the toolchain gave us was not the
expected ELF note".  The only thing left (modulo toolchain bugs) is the
CodeView region, and if it's not a valid CodeView region then we've
wasted a handful of cycles.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 17:07:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 17:07:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007239.1386545 (Exim 4.92)
	(envelope-from )
	id 1uNE3O-00031K-H8; Thu, 05 Jun 2025 17:06:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007239.1386545; Thu, 05 Jun 2025 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 1uNE3O-00031D-Ec; Thu, 05 Jun 2025 17:06:58 +0000
Received: by outflank-mailman (input) for mailman id 1007239;
 Thu, 05 Jun 2025 17: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 1uNE3M-000317-UO
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 17:06:57 +0000
Received: from mail36.us4.mandrillapp.com (mail36.us4.mandrillapp.com
 [205.201.136.36]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7b509377-422f-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 19:06:55 +0200 (CEST)
Received: from pmta15.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail36.us4.mandrillapp.com (Mailchimp) with ESMTP id 4bCrTV1kv6zS63LyK
 for ; Thu,  5 Jun 2025 17:06:54 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 6c9a378f36024232a7564311669ba435; Thu, 05 Jun 2025 17: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: 7b509377-422f-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1749143214; x=1749413214;
	bh=fKuSwTCyXu9Im5b8kMkxc1XVU5MJZjNRA+QKFgbejZQ=;
	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=sn7MBWNYJQINSk1ehIS4/BS9g/m2TKO7euQGrr8nA9nwDJLyWFYjHNYzHKjbb3eXi
	 JeUjuxWL9+VxUmlTzwQ+hiRfsFHUyINp7nx1iAjGkxpIiw9sWmln+Ql9VTs1c9qqTN
	 XuiLEJopgNN2drfPsxr6ZLVJjjOokPjRZkSfGvXdRhnLwS6K/Jd5At3+WMA6l+zrDS
	 DQo7f0vDat7++QIusW0K7OmjEWPhqHGYHVE4IK4gARGYm/IgEoTmBi63vBDz7tOzIZ
	 Wb3D0JhXVynn7y5zeR6ietFOMcHINWYSWgE4nAUl7VwAdfFEAboaxpcATbcJGCqQ4W
	 YrFed2Yt9n8kQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1749143214; x=1749403714; i=teddy.astie@vates.tech;
	bh=fKuSwTCyXu9Im5b8kMkxc1XVU5MJZjNRA+QKFgbejZQ=;
	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=xrB+24ihoyBNlOvQR07ThvppBH13Qi6W+lpoJ746ymHrQBtEWr+JIGjgEXuXbIrTG
	 1vax12DaclQTuewSlw7anO23AgsyDknH/CcMW10DrNHdtmSXzGo1C2Rbk+a1UyJf5u
	 Aitua51QQgsOW8DDZGU4lbCcrsG+fAZe5sHsprZEj6zMiC2T+U4aRuazVuiUpMFl9d
	 T0eHKe0nAmKuKSr4ft4njCMPsXMxrPRB6DeNT19WkOv+WLagvBE/V97dvREPXcXwij
	 astTigq3wpnZXzYUp8ucP6aTE5TwcmdHrXKLdzNv4JHjI/YYHUuRp+7yWAMmpjEFhi
	 gPactjBjCKdWQ==
From: "Teddy Astie" 
Subject: =?utf-8?Q?Re:=20[PATCH=20v5=203/6]=20x86:=20re-work=20memcpy()?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1749143213293
Message-Id: <81da4e8e-9dcf-4630-a535-39ce0b07260c@vates.tech>
To: "Jan Beulich" , xen-devel@lists.xenproject.org
Cc: "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" 
References: <73481cbf-337f-4e85-81d2-3487366cd822@suse.com> <017e689a-41a2-4722-a5e7-19ffef27500f@suse.com>
In-Reply-To: <017e689a-41a2-4722-a5e7-19ffef27500f@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.6c9a378f36024232a7564311669ba435?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250605:md
Date: Thu, 05 Jun 2025 17:06:54 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Le 05/06/2025 =C3=A0 12:27, Jan Beulich a =C3=A9crit=C2=A0:
> Move the function to its own assembly file. Having it in C just for the
> entire body to be an asm() isn't really helpful. Then have two flavors:
> A "basic" version using qword steps for the bulk of the operation, and an
> ERMS version for modern hardware, to be substituted in via alternatives
> patching.
> 
> Alternatives patching, however, requires an extra precaution: It uses
> memcpy() itself, and hence the function may patch itself. Luckily the
> patched-in code only replaces the prolog of the original function. Make
> sure this remains this way.
> 

We can probably workaround that by using a separate memcpy for 
alternatives patching. So it wouldn't end up patching itself.

> Additionally alternatives patching, while supposedly safe via enforcing
> a control flow change when modifying already prefetched code, may not
> really be. Afaict a request is pending to drop the first of the two
> options in the SDM's "Handling Self- and Cross-Modifying Code" section.
> Insert a serializing instruction there.
> 
> Signed-off-by: Jan Beulich 
> ---
> We may want to consider branching over the REP MOVSQ as well, if the
> number of qwords turns out to be zero.
> We may also want to consider using non-REP MOVS{L,W,B} for the tail.
> 
> TBD: We may further need a workaround similar to Linux'es 8ca97812c3c8
>       ("x86/mce: Work around an erratum on fast string copy
>       instructions").
> 
> TBD: Some older AMD CPUs have an issue with REP MOVS when source and
>       destination are misaligned with one another (modulo 32?), which may
>       require a separate memcpy() flavor.
> ---
> v5: Re-base.
> v4: Use CR2 write as serializing insn, and limit its use to boot time.
> v3: Re-base.
> 
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -47,6 +47,7 @@ obj-$(CONFIG_RETURN_THUNK) +=3D indirect-t
>   obj-$(CONFIG_PV) +=3D ioport_emulate.o
>   obj-y +=3D irq.o
>   obj-$(CONFIG_KEXEC) +=3D machine_kexec.o
> +obj-y +=3D memcpy.o
>   obj-y +=3D memset.o
>   obj-y +=3D mm.o x86_64/mm.o
>   obj-$(CONFIG_VM_EVENT) +=3D monitor.o
> --- a/xen/arch/x86/alternative.c
> +++ b/xen/arch/x86/alternative.c
> @@ -195,12 +195,16 @@ void *place_ret(void *ptr)
>    * executing.
>    *
>    * "noinline" to cause control flow change and thus invalidate I$ and
> - * cause refetch after modification.
> + * cause refetch after modification.  While the SDM continues to suggest=
 this
> + * is sufficient, it may not be - issue a serializing insn afterwards as=
 well,
> + * unless this is for live-patching.
>    */
>   static void init_or_livepatch noinline
>   text_poke(void *addr, const void *opcode, size_t len)
>   {
>       memcpy(addr, opcode, len);
> +    if ( system_state < SYS_STATE_active )
> +        asm volatile ( "mov %%rax, %%cr2" ::: "memory" );
>   }
>   
>   extern void *const __initdata_cf_clobber_start[];
> --- /dev/null
> +++ b/xen/arch/x86/memcpy.S
> @@ -0,0 +1,20 @@
> +#include 
> +
> +FUNC(memcpy)
> +        mov     %rdx, %rcx
> +        mov     %rdi, %rax
> +        /*
> +         * We need to be careful here: memcpy() is involved in alternati=
ves
> +         * patching, so the code doing the actual copying (i.e. past set=
ting
> +         * up registers) may not be subject to patching (unless further
> +         * precautions were taken).
> +         */
> +        ALTERNATIVE "and $7, %edx; shr $3, %rcx", \
> +                    STR(rep movsb; RET), X86_FEATURE_ERMS
> +        rep movsq
> +        or      %edx, %ecx
> +        jz      1f
> +        rep movsb
> +1:
> +        RET
> +END(memcpy)
> --- a/xen/arch/x86/string.c
> +++ b/xen/arch/x86/string.c
> @@ -7,21 +7,6 @@
>   
>   #include 
>   
> -void *(memcpy)(void *dest, const void *src, size_t n)
> -{
> -    long d0, d1, d2;
> -
> -    asm volatile (
> -        "   rep ; movs"__OS" ; "
> -        "   mov %k4,%k3      ; "
> -        "   rep ; movsb        "
> -        : "=3D&c" (d0), "=3D&D" (d1), "=3D&S" (d2)
> -        : "0" (n/BYTES_PER_LONG), "r" (n%BYTES_PER_LONG), "1" (dest), "2=
" (src)
> -        : "memory" );
> -
> -    return dest;
> -}
> -
>   void *(memmove)(void *dest, const void *src, size_t n)
>   {
>       long d0, d1, d2;
> 
> 

Aside that:
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 Jun 05 17:23:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 17:23:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007252.1386555 (Exim 4.92)
	(envelope-from )
	id 1uNEJ1-0006L4-R6; Thu, 05 Jun 2025 17:23:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007252.1386555; Thu, 05 Jun 2025 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 1uNEJ1-0006Kx-O2; Thu, 05 Jun 2025 17:23:07 +0000
Received: by outflank-mailman (input) for mailman id 1007252;
 Thu, 05 Jun 2025 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 1uNEJ0-0006Kr-B4
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 17:23:06 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20628.outbound.protection.outlook.com
 [2a01:111:f403:2412::628])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bc58ccfe-4231-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 19:23:05 +0200 (CEST)
Received: from BN9PR03CA0874.namprd03.prod.outlook.com (2603:10b6:408:13c::9)
 by PH7PR12MB7427.namprd12.prod.outlook.com (2603:10b6:510:202::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.37; Thu, 5 Jun
 2025 17:23:00 +0000
Received: from MN1PEPF0000F0E4.namprd04.prod.outlook.com
 (2603:10b6:408:13c:cafe::37) by BN9PR03CA0874.outlook.office365.com
 (2603:10b6:408:13c::9) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Thu,
 5 Jun 2025 17:22:59 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 MN1PEPF0000F0E4.mail.protection.outlook.com (10.167.242.42) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Thu, 5 Jun 2025 17:22:59 +0000
Received: from localhost (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, 5 Jun
 2025 12:22:57 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bc58ccfe-4231-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ctZm2dkUGRSZWsMZS3ZvpbvQQfng/nt/Z3o6YAXXvIJ57a+aoJ5DqHUQQNkmXUVW9ttEK6hvOgGl6iUuN1YM029pWo6ifgCNG6WkVAI20IljRf2cTKyb+BRSU988HNQs2FwkJWnEx7YMnD2Pfp/b7I1T1jKQmwEpvspi90UBpNHzN2v3gYGkBAuCW8KQ4Y3ekRpJPSKQ9YGOuOktpvme8UhcbH78U1MTDt1n8jbhBvYriY8PclLHCNHXjGQM/YSpsp1PagcQVxL6zmH5iUDB7uQ7ovpWigsE7Aqro395sF+9J/qq/HyqJB3W5ib8u0TYId/T8JjWGiNaOL4WFiHGLw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=H6kfwSE7s6bQuZ3N1lUT5jMKzInmxmzg2O+OG1b5az8=;
 b=qMXsh8/8CL5F81hIibkrmiW5ZFt2OqMEax+Qnel40CYJkNf8YAvIetBW4qKkF0soKaRWqm0UvWS045K4TwGmXwofxTQsF/xQ1AmfsNxGuSintEA9TWJ43pAiXbsyauaQhWdnh/TE3N05v+XvatJFmmg+rVP9N/K2brMOpwusmY4EzVswoszViFAEZ1CXupgBAWCFLSDrmyhJ0MksASL0hrf0jMcaL9CBF0pU6RjaG6pw3oXjYpE78tUK7+YeXi7uKEu98HoipABmzLJC6iU0baRQXJfPZ5Vr4tt2BmUAtgqQ314lE1ztmfLGoxYcjLkZFDEk79kFHWoRQUixZdlz2A==
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=H6kfwSE7s6bQuZ3N1lUT5jMKzInmxmzg2O+OG1b5az8=;
 b=xS7AG1GftEABFU2Bz+FTEDfOE/8mLRTsAQMTC2RU64SWJSBdYXkUU/OxS2VLs4XOMgJ9OKR7+cM8fiAXu1ecAWgF4I5A2OCLfLYUzuH+jqcBv13pitq7znAM7p4h25CZkOP1voW6LDiPCnerrBkmjLlgk0Yuj/8WZekjac9Jqfk=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 5 Jun 2025 19:22:56 +0200
Message-ID: 
From: Alejandro Vallejo 
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?=
	, "Daniel P. Smith" ,
	
Subject: Re: [PATCH 07/19] arm/gnttab: Break cycle between asm/grant_table.h
 and xen/grant_table.h
X-Mailer: aerc 0.20.1
References: 
 <20250530120242.39398-1-agarciav@amd.com>
 <20250530120242.39398-8-agarciav@amd.com>
 <5f3de127-70cd-422f-a368-6c23d83c6cf9@suse.com>
 
 <6cc4d172-793b-4d3e-990e-f8fd0d4bbabc@suse.com>
 
 <87224eb9-d4a6-4589-8cc2-e222619f8dde@suse.com>
In-Reply-To: <87224eb9-d4a6-4589-8cc2-e222619f8dde@suse.com>
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: MN1PEPF0000F0E4:EE_|PH7PR12MB7427:EE_
X-MS-Office365-Filtering-Correlation-Id: 5ce2dff7-95d0-4cbb-cc8f-08dda4559eaa
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|82310400026|7416014|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?ZjZXMHk3T3BWenNnQWc4SDkvZWFVSW5KQitqaDhyOXpWVTBPQzhRd0pLaVIz?=
 =?utf-8?B?bU82QVFieHBrZzNtT0xzb3R2VUxCa0ZvVklKcWtVQm1ENld1TzZsN25GWWVi?=
 =?utf-8?B?Ky9YSlZTa3owQjFhM1hsQjJzREtlYjNaNklKVElSQ1RTSUEzVVUrZHVwc2d3?=
 =?utf-8?B?QWh1VnRTSFZySmtxa3RrUlVEdkFydDlCdlpyenRuRVpqZUhGclV0cHpXOWNM?=
 =?utf-8?B?WWVjOUpIbVUwTUZ4NXJpSFpybW1CM0RuV0tlVE1LbDBRT1d6V2hhdlBSVTA5?=
 =?utf-8?B?L2FMSGJNMWpoS1FCVHg1b3NTRTZnSUhWMWYwcFZOVHFFdTA2YWROQ0wvejFs?=
 =?utf-8?B?b1Z5REpabXF4Z0ZHNEYvaE9leHE3c0gwaDRtdmdyWUxtQ3dJbU5pMHBxR2F0?=
 =?utf-8?B?SUVJWGlyc1B2M2dwSFJLSzRieVBxY3VzTjEzUndEaTl4bTNQOEpKT2RNWTA3?=
 =?utf-8?B?cmlUTUZvdzJHMVFsL0NsRWFoREJsUnJOekhoOGFoQysrL3VJWHpqaCtoRXFG?=
 =?utf-8?B?c2YrQng5Z1JBckNyQytnNGRpZnRNVE1zcHhCdU9iVnkyQTJOejltUk5wZWky?=
 =?utf-8?B?WnVJUkxqQzNDWjBUSDJqZkxNdE85YTVUNm1xUGhaRjVQQjdtMVhTcEdlZ3ZV?=
 =?utf-8?B?emFrU2d5bWxoMnRzQXk1YTc4cEE2ZTdqTXpjNFhpOURLM2VzZ3lGSUxvbFd0?=
 =?utf-8?B?TG41ZUhJK2RKNVlHSld0WGVxQ3pDUE9yYkFVcU1qM2VYckFwMGFjeTdZSnBQ?=
 =?utf-8?B?UkVVUThISzdYSGxSK2k1dzhmTGlFVjFEamxWOE45ejJvTzV6K0JSZGN3RGFG?=
 =?utf-8?B?QnZaTURlTkMycWlmV29JNngwS0pDNW16eDdNeW5sUmFSZWVnWng3dzBVQ3JI?=
 =?utf-8?B?eVVGNFJkdnByOERNSHJicTZjeUhISFh4d0VSNGVibE13Yko2TGJoUURzeUhW?=
 =?utf-8?B?ZTVOYVNtKzdhZnp3OEI4OUQ3ZytMUk0za0o1ekN5WkNBdmRTUHJ4dXQ4Wm1R?=
 =?utf-8?B?dk02cFZXak9RbmsvalVvNWVwNzA3UmRiV0tWbGdUN0RibTZaRWNVQmpneEpW?=
 =?utf-8?B?bFNxSGIvT1o0bFNTVUxxZ3EwS21OaFkyUFBETmIyQUN5OTkrc0ZSOGd4Rmpo?=
 =?utf-8?B?U2Z1Vy9UaVFnYnhobk5lVXV1ZTZ5cGU4bWgvY2dNbTFTczhDVjBwekhCU2tB?=
 =?utf-8?B?TlcxOGN0Mlg1eWVZTTBUaEozZXhhcjdmMTFBWG9EeXZkS1VheTNURGNkR2Er?=
 =?utf-8?B?bGM3ZUgvbzdVMmJKbHZNMDYyYnd0SFJCQ0FsODI4bVZVb1BZeHM5ekd5TTFD?=
 =?utf-8?B?V3B3R1R1a2ZmUmpUL2Z2UDFmMG9oQU16eERuZjhvam1nYzZiTEtoVlFoMkVH?=
 =?utf-8?B?R015V29ZbVZNcFh6QUdRcWd0Qk42UFAyWVVOVGE3cDhuV3F3VlpEK2QzNjQ1?=
 =?utf-8?B?YVZJMEhkaE8va2MxSWtONEJQS0prYmJHUlhsUSt3eDc4NmRHMWFpOVpKb3Ix?=
 =?utf-8?B?NmZXNU4xdjE3M0doWGN3Y2t3TDN0VjRiMnNmRGdLYVloTzl5eEtoZHExWkph?=
 =?utf-8?B?Qyt2dGtSUUU5TENHTkxzNWFWZFVGa3NUNFUrcTZvR2N1Qzhtd1h2aGs0d0w1?=
 =?utf-8?B?dXBWckg3M3JSd2RObkRyNUFSWEpaWlFiN2hoU3VtOEZ5STJzT2J1SkJiY1lL?=
 =?utf-8?B?ME8vNzdiZ1UrL3Nyclo0SUtaNWRISkhOdkV3OE1XRjdTdHV4cjVHTmx4eWtj?=
 =?utf-8?B?WmZ0dnNOQmJ0L0NPRWVwWnBVVTlPODIyaEU2TkVHTnB0SDJrZWJNMGxaUU9J?=
 =?utf-8?B?bEJ3MnF1dEJlMlRlVTJsZk5rbWhUUEErMC9RQUZ5cUhyWlZtWWxZZEJEYzJX?=
 =?utf-8?B?MmRqbitPVzdBYmNQUVovTzNaeTdsYnRwM3BCMWd3dy93OEZOT3dHYjdodWNs?=
 =?utf-8?B?RU5nMGdYbG11U1QzSjEveW9nM3lDd095Uks4N1dDTFYxVWxwblJpT0lJcDZk?=
 =?utf-8?B?NGhkemJXNzBnL0hjSEV2enlKRnVZVEpQd0wzakZ4NlQ0WXh2ZDBnQWI1U2M3?=
 =?utf-8?Q?dEmKnE?=
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)(7416014)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jun 2025 17:22:59.7188
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5ce2dff7-95d0-4cbb-cc8f-08dda4559eaa
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:
	MN1PEPF0000F0E4.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB7427

On Tue Jun 3, 2025 at 9:04 AM CEST, Jan Beulich wrote:
> On 02.06.2025 18:39, Alejandro Vallejo wrote:
>> On Mon Jun 2, 2025 at 4:51 PM CEST, Jan Beulich wrote:
>>> On 02.06.2025 16:30, Alejandro Vallejo wrote:
>>>> On Mon Jun 2, 2025 at 9:53 AM CEST, Jan Beulich wrote:
>>>>> On 30.05.2025 14:02, Alejandro Vallejo wrote:> --- a/xen/include/xen/=
grant_table.h
>>>>>> +++ b/xen/include/xen/grant_table.h
>>>>>> @@ -27,7 +27,7 @@
>>>>>>  #include 
>>>>>>  #include 
>>>>>> =20
>>>>>> -#ifdef CONFIG_GRANT_TABLE
>>>>>> +#if __has_include("asm/grant_table.h")
>>>>>>  #include 
>>>>>>  #endif
>>>>>
>>>>> This change looks wrong (or otherwise is lacking justification): With=
 GRANT_TABLE=3Dn
>>>>> the arch header isn't supposed to be included.
>>>>
>>>> It's not equivalent to the previous code; but that's a feature, not a =
bug.
>>>>
>>>> Not including the header with GRANT_TABLE=3Dn  was the best we could w=
ith
>>>> the older toolchains in order to not try to include a header that migh=
t not
>>>> exist. The high number of sequential inclusions of xen/grant_table.h a=
nd
>>>> asm/grant_table.h seem to attest to that.
>>>>
>>>> I can ammend the commit message to be clearer, but IMO this is what it=
 was always
>>>> meant to be. I can replace the current commit message with:
>>>>
>>>>   "The previous toolchain base version didn't provide __has_include(),=
 which
>>>>    allows conditional inclusion based on a header's existence. Lacking=
 that
>>>>    feature the inclusion was guarded by the GRANT_TABLE option being p=
resent
>>>>    but even then sometimes the arch-specific header is required even w=
hen
>>>>    the option is not selected. This causes inclusion sites to needless=
ly
>>>>    include both asm/grant_table.h and xen/grant_table.h.
>>>>
>>>>    Using __has_include() removes this requirement at inclusion sites."
>>>>
>>>> Thoughts?
>>>
>>> So why would we include a header we don't need when GRANT_TABLE=3Dn? Ov=
erall
>>> we're trying to reduce dependency trees rather than growing them furthe=
r.
>>=20
>> Because we do need it or the code doesn't compile. gnttab_dom0_frames(),=
 for
>> instance, exists and is used in unguarded statements.
>
> I fear I don't understand this: Things are building fine right now, aren'=
t
> they?
>
>> There's more case like
>> that. It may be possible to break those dependencies so the inclusion is
>> not always expected, but the reality is that you tend to need the other =
header
>> for pretty much the same class of reasons you needed xen/grant_table.h t=
o begin
>> with.
>>=20
>> Forcing the code to include both seems counter-productive to me.
>
> Depends on how frequent the double inclusion is, imo.
>
> Jan

Not as much as I feared. I've removed both linkages for v2.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 17:24:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 17:24:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007262.1386566 (Exim 4.92)
	(envelope-from )
	id 1uNEKX-0006vV-8J; Thu, 05 Jun 2025 17:24:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007262.1386566; Thu, 05 Jun 2025 17:24: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 1uNEKX-0006vO-4M; Thu, 05 Jun 2025 17:24:41 +0000
Received: by outflank-mailman (input) for mailman id 1007262;
 Thu, 05 Jun 2025 17:24: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 1uNEKW-0006uq-33
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 17:24:40 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20607.outbound.protection.outlook.com
 [2a01:111:f403:2009::607])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f5200518-4231-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 19:24:39 +0200 (CEST)
Received: from BN9PR03CA0843.namprd03.prod.outlook.com (2603:10b6:408:13d::8)
 by SA3PR12MB8022.namprd12.prod.outlook.com (2603:10b6:806:307::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.37; Thu, 5 Jun
 2025 17:24:27 +0000
Received: from MN1PEPF0000F0DF.namprd04.prod.outlook.com
 (2603:10b6:408:13d:cafe::2b) by BN9PR03CA0843.outlook.office365.com
 (2603:10b6:408:13d::8) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Thu,
 5 Jun 2025 17:24:26 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 MN1PEPF0000F0DF.mail.protection.outlook.com (10.167.242.37) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Thu, 5 Jun 2025 17:24:26 +0000
Received: from localhost (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, 5 Jun
 2025 12:24:25 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f5200518-4231-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=yTuFHoG1hlasG3u/d/rk/TWbJl+Rw2jQB0bf+1jSi2hRLUuqCoymYl1vWK021gUk+5AxgFVyLXX4tOrdCk1Mjxg8a64RckjsdrUII17dupFug8TPIvEtzqAAQA2HWQK6yxtya3QYtJHIUhhLHPv/brIjoBfEBUSN5quztJ2wNS+8MDLy4HRhexYKznH/Wb/un9sd0rqsoLz8n9B8KZs+q1VigAH36biPyMipjmUYOJKDS/zWgKpbUVEHK9cqm5jgJNgjHDZkodOsJjtXp93oPYCSp+bPoBygPb1VWhL+ZxZnDjv3HIJ5wgjoc5VxunuandDz6OSpc255V3yRgW8vvg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=D80S4PzSvkkZeEbj9tYBBYrE8wdR2yvAkrGC5poV8v0=;
 b=lEI3BJBlbH2nrYmYKUOXX0q0V1Pnsn2QD2MVfv4aQdAsurbJz0xRiUTdnmlyI1aI+JptOvrsnqTOvSDH6x3FPLLdhJ+7Mvu3RIJjfFuaLSH3oP18SeDqCZn8ru5S/JLueL0e0HIWANqyqOnSdHRWZ/5n/HeIb39eqRwD55eCC4imBWefUJpy2ksJ/f66E51fi5JlSEnhle1iIRM8hlGL1NudDUpi50zVBTEWObH6FMJP0UFvjXAZGgJ1eZDmM4ONHVWdhBGWJS/p8nSasOkfFtaS3wdYGzL/KVFVYNuaN0IT2u6Yj9ydrLdM7L9Ul1ZWk6V9Or3lW8rpofXhNpuxkQ==
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=D80S4PzSvkkZeEbj9tYBBYrE8wdR2yvAkrGC5poV8v0=;
 b=o7dzvxfEAV0bs79j3hW5rZeHKc8mUHzOBwXK+QEapl1NCFotRQ6upq/wh1rc+62tQf5PUDZk28ZNs/2YCZUeNI0Hv4BsvibqBI/OgM12ViEoB7dCnJEFUmNaj6Pc9dgDvtoux/QiMKgj5n04Su13gpwNYSnrLrnhq7lGhrg+KWw=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 5 Jun 2025 19:24:23 +0200
Message-ID: 
CC: , Julien Grall , "Bertrand
 Marquis" , Michal Orzel ,
	"Daniel P. Smith" 
Subject: Re: [PATCH 08/19] xen/dt: Add BOOTMOD_MICROCODE
From: Alejandro Vallejo 
To: Stefano Stabellini 
X-Mailer: aerc 0.20.1
References: 
 <20250530120242.39398-1-agarciav@amd.com>
 <20250530120242.39398-9-agarciav@amd.com>
 
In-Reply-To: 
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: MN1PEPF0000F0DF:EE_|SA3PR12MB8022:EE_
X-MS-Office365-Filtering-Correlation-Id: da19c4d0-53a0-4d50-a7aa-08dda455d278
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|82310400026|376014|1800799024|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?TWxhT0pkdlRuOG5RUWNJaXRZQTBrSnZYQzUvSWViUjIwSytZeERRSnpoaDNm?=
 =?utf-8?B?aHJNcnZuRjB2Mi9PTVJDem9QMXFDNGNFc0VSSkpnTzRLRjV0VHIvUUh2M1Zp?=
 =?utf-8?B?d25WRFpPRzNoc2s3TkNaNytIUEZ3UVZ1T1c1aXJUaGVKUmIrZVdMRUJzRFZu?=
 =?utf-8?B?V1Vpa1hiUXdUeVhHQkdoRXJvcTRIYS94c2Ridk11akFDYXIzelNNTTE1YnZP?=
 =?utf-8?B?YWRSUDd2ZXNpbGdqcGxFdm1ncE5pd1ZqQ2RjdkhRc0dNa3R6dlJoUCswS0hZ?=
 =?utf-8?B?dnA0YjJhWlI2Z2pGMlFpK3JoYUtMbThPN3pBUDlpWDJManhkYWNCV1VEWnE2?=
 =?utf-8?B?R0pRWWlqWGhKTUtneDdLMlVvOGw0UWYySFZKTEpMWkJOa1l6Q2NVWEdyYWZ6?=
 =?utf-8?B?ODh3Z3ZoUDY5TmVWY3ducGhwOW9UOEE5L2JndGNlYWdpL01McmtZUE1VbU5F?=
 =?utf-8?B?b3JRT3l2TU9lQ1lRTEM3UWxRaGthTWMraXBSdGxMMkhTSFdBQU9nb2dKbHZZ?=
 =?utf-8?B?KytOamNRRVBsRVp0bVlzNnFEZEgwUksvZXNvTzFKaVREenBXUFM1TC82RmVM?=
 =?utf-8?B?M291a2VnMmd1WGhqY2lUUXdoWUFZMVkzc2F0ZXZpMmNXZk0xb2VqWUZXdW5t?=
 =?utf-8?B?TzRURk50bFJFcno2TFkwb3pHTnRiVVdQUG8zSXJRRlRGTTBTcFhsajBGV3Nm?=
 =?utf-8?B?UFpuL2FaQm5BMXM5VHgyc3d1eURjK0t6Q25Bblc0U0pmSDAwT3lXSkR4WVlp?=
 =?utf-8?B?Q3ZwbTNNYXB0K2NkN2VpSFZidi82MW5LaStXa1g2Z0V2eDFKOFdpQTFLOUw1?=
 =?utf-8?B?dXZHL3hDS0U2MXdDMmJ1RUozRzc4bnA3S0NmMkhpN3BPTm9mQ243L0hUdWtK?=
 =?utf-8?B?WHRJRUtVa0tTVzJZNTcxbU0rYnZHcXZmbElnRXk4ZXk5cUNZcWlzb2R1Z2F2?=
 =?utf-8?B?SCtlNWM0R1BDVEZPbG40a040OUg5MXZncTFQNHRBNUw5RmVuY1F2Sk9hNnp0?=
 =?utf-8?B?RlVpM0o3T2QzY0hoblRUNUFDTFJMbkhiaHBCdmhyN1ZDUnZGOXdjdUdaZjE2?=
 =?utf-8?B?NmVsVkVRNlpyM29vMVR5Um0rSjlNUXR2Vmd5UWtqbUE0TllCY3JKZHRHRGZH?=
 =?utf-8?B?dkpHVEFDdWNqYmJ6bFMya2dOVkRiR1phMXFldVVsVW1iQ3dqOXBRek92Slh3?=
 =?utf-8?B?a1BGRWQ4QVhxcDhSTzNCa1RuRnVkMnduSUJaaTUrWXlHOVlOL29HY1lpNHd5?=
 =?utf-8?B?eStPNDdBZDhMaFNLQnJ5N2RKdjdwbTU3YWM0eWdZdTczM043bkVIcVlJeVdN?=
 =?utf-8?B?YXgyODRFRVJIVGgyTUZ5K1Noa2hHTHBvTnU0N0l5eDRwMGtXZXFINTNHQlhN?=
 =?utf-8?B?S0JYUkkrcElXTERsK2tCeUFtbUVNc2NpTFc5NkdUMGxheVRBNDIwQjErN0FQ?=
 =?utf-8?B?U2VOc2EvMDBqQVNUa3lQVVNBQVJDSUEyOEJwVWdBZDVQakY4M0hjU2RUU1dQ?=
 =?utf-8?B?SGRWSnF2ZUJTVml3RmRTdVlSZFpmMlNhNUMyeit4dG9QRDlXcTZzaUVnVzVp?=
 =?utf-8?B?Y1RnWm43UVA1QWVncEl4QjdpaFJvbkpKaDVOdXFsV0QrazRGVVFYZlZyMWg0?=
 =?utf-8?B?TG5kMkwvSCttWDNhZEJIZG9ybFAxZTRMd0RoWlFmY0pReWdOVm5wQWFZMXc1?=
 =?utf-8?B?dG9VS3NYc1VJTkNRMnhLWWNjUHZXNkZVOW1NTjhCNUlFcEJhK3pIZGNEK0dm?=
 =?utf-8?B?bDFEUUIwWk5Pd3ZVUktMZm4rOWF3V0pOZXlzUnlEZVIrNm5DY001c0dzS3Zk?=
 =?utf-8?B?RDlBNk1paWJWcmJPbU1McmxRMU1zY2NsbTMraUJ6bTg4NnNpdS9OT0pSUUU4?=
 =?utf-8?Q?OrnzQK+yPCYsS?=
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)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jun 2025 17:24:26.6343
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: da19c4d0-53a0-4d50-a7aa-08dda455d278
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:
	MN1PEPF0000F0DF.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR12MB8022

On Sat May 31, 2025 at 2:59 AM CEST, Stefano Stabellini wrote:
> On Fri, 30 May 2025, Alejandro Vallejo wrote:
>> In preparation for x86 to start using bootmodule instead of boot_module
>>=20
>> Signed-off-by: Alejandro Vallejo 
>
> Reviewed-by: Stefano Stabellini 

Thanks.

Note to self though, I should be probing for "multiboot,microcode" in the
early scan path now that this new variant is here, to identify the kind of
the blob.

Will do it for v2.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 17:24:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 17:24:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007263.1386575 (Exim 4.92)
	(envelope-from )
	id 1uNEKf-0007CI-FT; Thu, 05 Jun 2025 17:24:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007263.1386575; Thu, 05 Jun 2025 17:24: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 1uNEKf-0007CB-C8; Thu, 05 Jun 2025 17:24:49 +0000
Received: by outflank-mailman (input) for mailman id 1007263;
 Thu, 05 Jun 2025 17:24: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 1uNEKd-0007B4-O4
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 17:24:47 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20608.outbound.protection.outlook.com
 [2a01:111:f403:2418::608])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f8baeb5e-4231-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 19:24:45 +0200 (CEST)
Received: from BLAPR03CA0088.namprd03.prod.outlook.com (2603:10b6:208:329::33)
 by PH7PR12MB8425.namprd12.prod.outlook.com (2603:10b6:510:240::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Thu, 5 Jun
 2025 17:24:41 +0000
Received: from MN1PEPF0000F0E2.namprd04.prod.outlook.com
 (2603:10b6:208:329:cafe::a0) by BLAPR03CA0088.outlook.office365.com
 (2603:10b6:208:329::33) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.34 via Frontend Transport; Thu,
 5 Jun 2025 17:24:41 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 MN1PEPF0000F0E2.mail.protection.outlook.com (10.167.242.40) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Thu, 5 Jun 2025 17:24:40 +0000
Received: from localhost (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, 5 Jun
 2025 12:24:39 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f8baeb5e-4231-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=bNWRAQhcgyxgIcmjrzglXaR9o3AY0a84Y48CMFUSvkd79EP5InWuRsCaqNzfQ8/MVM8MTs2Wtl7PppqYuSqPVGV9tfv8NIz0WERy0BfCmMwpcFtAElYrkXU/NJwQQ/HpiuVR3vsGX6LifUItEqqM6+r2KVx3wOSYlO2/0zErEMGrG/olnmyu2EWBLru1GH7Kb5lpfFiAMMAYDxEpzpBfBGgsEMht/wWFLDy/MviDZQl9KEQPq+jvPiBczwehUJqo4UWVs8OTeGdVjHQFAFqUy4goFnoorl2hytGbbzAJ0ss8WYdFLD/3wzjBJH0vlT/keCuW0BFmGXxqI7d392sNvw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=hpmexu2+sCiQj18H24S9Ey/Mz6uQd491ofVzFdM9REw=;
 b=hJAWF2OV1JUYPuQ3EuzGrBiUsKc0EZk4WywGcWWsOXI6xq0VKNMuLyWq2bfk33RQY6aREzRM3BewEuC+HPdNh7og1Fc0TKXSejiVX+pXsFvD6SAtat0wWMPOBO71AC9BAYYUVO6FdkhfINb/6/fgrkGB8Ju9D1PYS3xmdeaecLsYsNz5plRcgNoEz/THZ7RqH3jLIutbPWx5Ov3oCBBhIiT9NdEJlQDdOtBqXQt7tIK0hCMRDAoMflFaqZrBHq3cA9fOAFBS1o6wdG0YOmSnm5NI3rqE1ZRMG2KlpeAHm7Vwrn2hQudBykapuIgOmVxdx5nD/Xt5blVJZeYp0Tw1rQ==
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=hpmexu2+sCiQj18H24S9Ey/Mz6uQd491ofVzFdM9REw=;
 b=sghFNBv1Md8MFvMsZFs4zecYA+/3RwT8NxcXutVUM6XzPbzAMUsamufuYMfrtUMiJ41cZLf7kCx9dUQ7e3Sksqp95l7ZOlH/il1G8GNgcirZm47JTgBuwD5/vsfmmK5K2jXgSzFtkUwxRygsEuz1Y4GH5VwFHgwb6YwM1wkZyxQ=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 5 Jun 2025 19:24:37 +0200
Message-ID: 
CC: Andrew Cooper ,
	=?utf-8?q?Roger_Pau_Monn=C3=A9?= , "Daniel P. Smith"
	, 
Subject: Re: [PATCH 09/19] x86: Preinitialise all modules to be of kind
 BOOTMOD_UNKNOWN
From: Alejandro Vallejo 
To: Jan Beulich 
X-Mailer: aerc 0.20.1
References: 
 <20250530120242.39398-1-agarciav@amd.com>
 <20250530120242.39398-10-agarciav@amd.com>
 <2548f9a0-76f8-4e6e-8330-759b118b777b@suse.com>
In-Reply-To: <2548f9a0-76f8-4e6e-8330-759b118b777b@suse.com>
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: MN1PEPF0000F0E2:EE_|PH7PR12MB8425:EE_
X-MS-Office365-Filtering-Correlation-Id: f9591976-8117-4f52-95a6-08dda455dac4
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?M0VEVno2RVExWXNTbU5VWGtURVVlMlF0L3E0RTFBWFBnaWdGOFh1eXBsN01E?=
 =?utf-8?B?U1h0dEpoVFlTdVcxMmY0bzE4QWQ4NjA1RXJXUjRzdGIxeXU0MnM5bWdkTmxw?=
 =?utf-8?B?ZmdoOEVUTElCT0dqVVdrMnplTlRPSkZrL1pRNVhvYnhra1VKRm1yQ3o1R21l?=
 =?utf-8?B?UG1meEhVaHp1ZktHK3BSbWRNY2RQNENwaGk4WURpVUNvUWExbk84WTczdkVi?=
 =?utf-8?B?TzVDdjk5eVBOWWQwaVRXNWZnS2I5MEFheGtGenRBVlhVNzdwQ0JMMWVISm5C?=
 =?utf-8?B?NkxUbDdhNytzSzVrTDhLc2pxTC8rZzRKVnBEVXlKWU1nTjJ5T0F1ZDlLeEZM?=
 =?utf-8?B?a09HS2tQZUxxTDhzUjRHaWpVS3FWRVRiME1RMWhueVkvaTM2VWh6ZlNRbWV3?=
 =?utf-8?B?OWJ6UWhaOGJ4YUJqWmhFd3Rzb2puSFFSc2xTZFRrdFl3OVA0Ym1lK3BzT2R6?=
 =?utf-8?B?MWpUM1o2L0tXNWQ0WkZRU3RuWk9vNW5keE1XZjVVc281ZkJWa3lrd3pFb0RM?=
 =?utf-8?B?SmtONTFWdGtlY3VDZVIwSjRVUGw0MndZaWVqL0s1c1czaGxpckVQWitPclIw?=
 =?utf-8?B?UGVhRWdwUENTWGNOL2twQStxdS9reCtBelpUYzRUTi9ZN2NYU3F2cXd4aEJw?=
 =?utf-8?B?MVJwaTBQZE5uMy9SVlovZ2pHSkhudWtTMksxbFlwU3ZCeFQwd1N0YzB1QkRs?=
 =?utf-8?B?SGN6TFJka0s5M01Ncm8zb1RlR3F2NWduOVdPSHdXL1QvUXg5MjhYVVZaWWg4?=
 =?utf-8?B?WTFSVFdXbks2MFVQUWM0cDd3aDdySk9ncHBxRk03WitsTUZuRjl6UTdpRC9B?=
 =?utf-8?B?Ty9HNi9hOGIzYWVxYWJIczBYTXJ4YjgrQmRhMWdMRGNKNUg2dlJSWVdWYXcr?=
 =?utf-8?B?YVJmMDBDcG5wbzFnUklmUnNTVi84eEdwalRqdzNrVzEzQUNUcjlua2o5ZUMv?=
 =?utf-8?B?RTczUzRVbWV3KytwMTFidHExNmVBT2hDTmM5QWNyWEFNSlRLenpOSmRpYnVv?=
 =?utf-8?B?Zm53cWFtR3hzT3hNNlVRVEdPcEsvMFhRQzgzVGRhT0s5akNOR2VYOXpMcVhp?=
 =?utf-8?B?WFFBMDhLOFA3OHlPL1dPYXNYMHkya3dwQnJCcUhJZFhBT1NHUGtHZ25sR0hx?=
 =?utf-8?B?WVcxSGM5Sk95QVk4eWRiOGZKSmh1bnliWFJZZEkxckZrWmFtSjNYUm9RMmd6?=
 =?utf-8?B?emM5ZWtPSGJjbUM0VWRwa2Z6bFlkcWRCK0kxZDVDKzVFOXRSYWhWWEFOQlM3?=
 =?utf-8?B?MHR0TllvbE5EWWM5Z0x4K0N3UTdLdU80bTJkL1lXdmE2VGp1RkJIemR6NXI2?=
 =?utf-8?B?Z0VtbVJNSXQ0TFJHS1lRSll0cWdVbWRQdExhcng0RGpna3RJL1FxQ2FsZ3lw?=
 =?utf-8?B?ME5PeHY1OHJHa21aaEN0dHgwaDVyblp2Q1puWGZrMGJCMVBtY0NkdWc0eVVl?=
 =?utf-8?B?MWhsZzBFR0NhRU5KdTdlZVo1czFhejc2Z2Y2aHI3aU5PTFhCOWRQTjAwYTVH?=
 =?utf-8?B?cHROUll3Y2FMT2xPYnFiaWRVc21kc2lrK0gzaU1EbFJ2d3hZanlmcnR2OGx5?=
 =?utf-8?B?U0R0RUFabG5ydEh4a29WNE5MMWQ5SnIzK21ITlJ0THgwTFFDd0c1ZWtjM2dX?=
 =?utf-8?B?MUM2cGtiVDJJTzE3c01OdU1ZMGVwdVlZaEhOL2w2QlpZY2lFQ0FPTVhFaDRF?=
 =?utf-8?B?cjRkeU9ZYitaQ0crZmZSY1puS1RYWVZyTlRFSXVIZHo5NjhXSDB6SmJrcDJk?=
 =?utf-8?B?NThnU0h5QzliVlp2NGtid00vbXdlZUY4TDh4cXJaaStNeUptUUlJbDJvMk9M?=
 =?utf-8?B?bnE0RjRrcStVUWhKR0RWMmk5MnhpaFVUYlhFcUY1YWk5emFpNnVmYjZRU2Rx?=
 =?utf-8?B?MjR3bytYREhYSCtLYkxkbTZxNTU5Q0NHeXlIU3k5ZUxaekp4dDdWOTg3TVhF?=
 =?utf-8?B?M1o4OFV6N010aU9adVBqdllVNlc4dGhkQ1lqMzZKMExaQzl5c2JUT3ptMncz?=
 =?utf-8?B?OVpmY0drMVNrMkR2YXM4UTBkdUlqWE15YWJPT0c4RXM4ejJSM0p1WkFhTHpU?=
 =?utf-8?Q?QaCNbI?=
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 Jun 2025 17:24:40.5527
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f9591976-8117-4f52-95a6-08dda455dac4
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:
	MN1PEPF0000F0E2.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB8425

On Mon Jun 2, 2025 at 9:55 AM CEST, Jan Beulich wrote:
> On 30.05.2025 14:02, Alejandro Vallejo wrote:
>> A later patch removes boot_module and replaces its uses with bootmodule.
>> The equivalent field for "type" doesn't have BOOTMOD_UNKNOWN as a zero
>> value, so it must be explicitly set in the static xen_boot_info.
>>=20
>> Not a functional change.
>>=20
>> Signed-off-by: Alejandro Vallejo 
>> ---
>>  xen/arch/x86/setup.c | 1 +
>>  1 file changed, 1 insertion(+)
>>=20
>> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
>> index 1f5cb67bd0..5da9df33c9 100644
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -298,6 +298,7 @@ struct boot_info __initdata xen_boot_info =3D {
>>      .loader =3D "unknown",
>>      .cmdline =3D "",
>>      .domains =3D { [0 ... MAX_NR_BOOTDOMS - 1] =3D { .domid =3D DOMID_I=
NVALID } },
>> +    .mods =3D { [0 ... MAX_NR_BOOTMODS] =3D { .type =3D BOOTMOD_UNKNOWN=
 } },
>>  };
>
> A brief comment may be nice, to help readers understand that there is no =
off-
> by-1 here.
>
> Jan

Sure.

Cheers,
Alejandro



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 17:25:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 17:25:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007268.1386586 (Exim 4.92)
	(envelope-from )
	id 1uNEKv-0007if-MF; Thu, 05 Jun 2025 17:25:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007268.1386586; Thu, 05 Jun 2025 17:25: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 1uNEKv-0007iY-J6; Thu, 05 Jun 2025 17:25:05 +0000
Received: by outflank-mailman (input) for mailman id 1007268;
 Thu, 05 Jun 2025 17: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 1uNEKt-0007B4-O7
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 17:25:03 +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 014c0be6-4232-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 19:24:58 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a4f72cba73so1808771f8f.1
 for ; Thu, 05 Jun 2025 10:24:58 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a526f4c808sm2871357f8f.28.2025.06.05.10.24.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 10:24:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 014c0be6-4232-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749144298; x=1749749098; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=aT4xlVdmPM3dcSL4LpqxBEaD/CpUWMmlGqv27BCEQ3U=;
        b=NirD4fFr0Fnj2IClbILsbMnV2c+8ku4FAKiuvXon0rxHjilmh+w2FpHVuwxuqRehLL
         LHgMErkHw9jxKf1dvJcmvCV/kza7Au/JX/NKihLK/ePa3ezpL81WB4UQSfO3Vzull5L3
         SdvUBEJ5TM107eHRtaDay/rDD8mEBJvj4Ihjw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749144298; x=1749749098;
        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=aT4xlVdmPM3dcSL4LpqxBEaD/CpUWMmlGqv27BCEQ3U=;
        b=rBcsqVB8gPJCRm8VFQVNAsSkQMyXF6ZoJBkA0VQ46cdv7kwFaeYlC//3JB+IBk4Gp5
         TDq7GQ9Bm8DZVYVfUZJVKQnba0C/QFtoH8+9w6R5NhFvm4Kx4TJtp6tJD+QgFPH73SYs
         AHrbABXbUz6v/5Q1mHH8YgOCpZ4nuQ8z//vJ6mc2aNQ/bKYAr6Xg6llZg+IYv4Po3BA1
         bw0zDLPErlwWOEQUnxFs1t+43p07Qbx7+EyWUD4Fddf52XXwdz54AzEM+tM358Xp1vQD
         luR48494UTEyhskPwXwRUHLxnphnchlSzeUBD6aO4ZBrPHsroeCg4BDhpJRpLqXCqhjd
         BUfw==
X-Forwarded-Encrypted: i=1; AJvYcCWO5RF/DlrrqfuvBeG1LipwBwrLxOnHpGyU7kBO9h+7YHgkpicuxbfkax+a390QN+ha6sHQWeHGsIk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxUGExaD6ArJzxdRsfk+BUcbiwLGUFxUsKbQqYl19ledKNOVr1J
	2NAvTqkDerqRbs7MNvfaUnZtUJHBo0eLsnbCufnYdgewuxiydvyQeUNwflKf9bG42fE=
X-Gm-Gg: ASbGnctt/aiWERwJOtx8jdF0SRETlyeueTyKOALJ5mIgXy9/Z8mgJz0CsbQoYRoi+bb
	6PgzvomWbN2NncaZqJlWEZ/zeWaEgt6yl79sIUIyRy/cK8hqN3wziNapVyl7yOtY9isuXxaJvz3
	kp2rQfE74cBh6wnzDeNOrzDONO0Ixh3NaoJkkh6XxrHeu3lbQeZ2q+vfOXUPKswx3tE767i80e9
	k5il702BX9i2XJeI0NbD5ZgMc2HlCAqMYU8L/yWAWcMcxuaCmVAt0Oj1HexDpVV++CheiwND4+G
	P4iT/rD8AZf8tNWL/hwKk0nWE5XRK/23EUBROI/8iMGOYB+eZgrv91e3l4M+2X0hCMSz4GW/Ec5
	B+aCVzANZhRyiaFUm
X-Google-Smtp-Source: AGHT+IGC0eTU31ibD9zhhg55NHqzmmE+JYBds4NIPodJDnlj28KR92dp7BEIo1woQDP+sYkIG5enzA==
X-Received: by 2002:a05:6000:144e:b0:3a4:ce5c:5e8d with SMTP id ffacd0b85a97d-3a526e0cf3emr4350327f8f.20.1749144298111;
        Thu, 05 Jun 2025 10:24:58 -0700 (PDT)
Message-ID: 
Date: Thu, 5 Jun 2025 18:24:57 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 3/6] x86: re-work memcpy()
To: Jan Beulich ,
 "xen-devel@lists.xenproject.org" 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <73481cbf-337f-4e85-81d2-3487366cd822@suse.com>
 <017e689a-41a2-4722-a5e7-19ffef27500f@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: <017e689a-41a2-4722-a5e7-19ffef27500f@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 05/06/2025 11:25 am, Jan Beulich wrote:
> --- a/xen/arch/x86/alternative.c
> +++ b/xen/arch/x86/alternative.c
> @@ -195,12 +195,16 @@ void *place_ret(void *ptr)
>   * executing.
>   *
>   * "noinline" to cause control flow change and thus invalidate I$ and
> - * cause refetch after modification.
> + * cause refetch after modification.  While the SDM continues to suggest this
> + * is sufficient, it may not be - issue a serializing insn afterwards as well,
> + * unless this is for live-patching.
>   */
>  static void init_or_livepatch noinline
>  text_poke(void *addr, const void *opcode, size_t len)
>  {
>      memcpy(addr, opcode, len);
> +    if ( system_state < SYS_STATE_active )
> +        asm volatile ( "mov %%rax, %%cr2" ::: "memory" );
>  }

This hunk wants pulling out separately.  It's not really related to
memcpy(), and probably ought to be backported.

Architecturally, both the APM and SDM say you're ok doing nothing on
64bit capable CPUs.

However, there are errata, and at least one recent AMD CPU needs
serialisation for self modifying code.  (Not sure if the rev guide has
been updated yet, and I can't remember offhand which CPU it is.)

You should also discuss the choice of serialising instruction in a
comment.  Mov to %cr2 is serialising on everything more modern than the
486, and least likely to be intercepted under virt (== most performant).

You also need to explain that we only do true SMC during boot.  After
boot for livepatch, it's prior to addr going live.

Finally, you're loading rubble into %cr2.  It's not even reliably 'addr'
because of the transformations the compiler is permitted to make on
memcpy().  I really think you should be reliably feeding in 0.  We're
doing self-modifying code here with serialisation; an extra xor won't be
measurable.

~Andrew

P.S. We should drop the noinline.  That's only applicable to the P5(?)
and earlier where you had to use branches to flush the prefetch queue. 
It's irrelevant on 64bit capable CPUs.


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 17:27:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 17:27:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007279.1386596 (Exim 4.92)
	(envelope-from )
	id 1uNENb-0008Uo-2T; Thu, 05 Jun 2025 17:27:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007279.1386596; Thu, 05 Jun 2025 17:27: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 1uNENa-0008Uh-V5; Thu, 05 Jun 2025 17:27:50 +0000
Received: by outflank-mailman (input) for mailman id 1007279;
 Thu, 05 Jun 2025 17:27: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 1uNENZ-0008Ub-Hn
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 17:27:49 +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 65fbb34e-4232-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 19:27:47 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a365a6804eso910053f8f.3
 for ; Thu, 05 Jun 2025 10:27:47 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a4f009745esm25319920f8f.71.2025.06.05.10.27.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 10:27:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 65fbb34e-4232-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749144467; x=1749749267; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=wG53aF3P/FVLr8FUd22VowQZ62LTgckKUyZxkDap7hI=;
        b=WFNQqTCWo8SbEDWxUcxGqWRD9RPJ0/usGSa4M3Wc3VVv67/Ms9m5QPi2AZcJnnV6sz
         aXjOJw7KwlIrLKB6iKY8SQPpdLYlEMx19Hd8os1WJvDHDms+voTsKxcgsplugRjjlVbs
         0KN83veL3JJ/I5y5UPSA9nXQyrJID1vJ4k4Rg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749144467; x=1749749267;
        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=wG53aF3P/FVLr8FUd22VowQZ62LTgckKUyZxkDap7hI=;
        b=uq0CMW/3rvPMzHdHuwdB1P0KS2+NrPBjas4eGvavQV1aRWzLt396KSU2HAVe+HHF0q
         K+xoAThUcs2hI/np24c7KxMCKaGRCAcW5+jmM5EFyUwVLMta2dFWIC1rZk+gIUccPak+
         QnLjrGbvtimQKecu34yLDgV0rXXAwWGYYG6/E4Ljcwim1fsbWWGrHhFlfhQbxdC5BBcU
         lqwnt2B3kG2qUkKGpg1MOtC8xTRdh2zL/Q2n3mM1GhqyYdy9Z6ImVwoDAFfvoZXgLO2x
         FASJ1ocHeM+Sv1XWWrPqwvK6ZVJrKMMKcmciyvUJmJNu4H6mqri44aijRqlAJpY//etT
         MuUg==
X-Forwarded-Encrypted: i=1; AJvYcCWnOS29ZsSgmycOHBQ13bkitc2TQoTuFVuIIm5E64qC+M1nKJ5DyBsIxjGQcIrL7vln2IuxYGBNkFY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxQFaQLTP4Q5qA30CW2cDosBCtuMu2dFXEoriw1ZROPtelNAFR2
	NJ2JiKjg3QWqATx6WsU4dctD+BI1AFKAu8EnttgD98unZ8V1g3Px6Lnd9RMntYzLphA=
X-Gm-Gg: ASbGnctqUm5s0kQYv9xlseL5JcvYmSJ4Ir+A4A1PWuWJL9wwSjsuPvV0vmMB+zvgknk
	xIbQtbE/XCQ9o5Gn8wwXSOxmFfH1Gdkj52CU5HzpMehOCM8XXm5ifO0bKzbcdeLZCSxjeP6A0MQ
	PceuY9uWCbD0qD4vi0JaWm+/823zzs0yXYTj41/I4FGWIb1qWjgJLwmwmk9mqZXWE0GaxOYlLNs
	aNN+oq6YLvnw1jTfTfvER4zNSxBnpr3msuL8kBERJP55TBuMdya8qGP9ONL7viJ/sFPslrIiW5A
	JyuEQTdiXaJFwThv5LZ/qok9+iYZqmpt8NNOts4zXUUO8WwvoLaNNrEpJYaZAVJIr1Lessc9nvc
	bItj7ybFtdodAncji
X-Google-Smtp-Source: AGHT+IF//QMHvHUk6ZzTvJKR/CMoCbHcdoxm3Sgr/huzSN5eLZho3fvDuf9HIzoI2ekojma+H65Bcg==
X-Received: by 2002:a05:6000:18a9:b0:3a5:2cb5:6402 with SMTP id ffacd0b85a97d-3a52cb56953mr2511721f8f.12.1749144467062;
        Thu, 05 Jun 2025 10:27:47 -0700 (PDT)
Message-ID: 
Date: Thu, 5 Jun 2025 18:27:46 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 3/6] x86: re-work memcpy()
To: Teddy Astie , Jan Beulich ,
 xen-devel@lists.xenproject.org
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <73481cbf-337f-4e85-81d2-3487366cd822@suse.com>
 <017e689a-41a2-4722-a5e7-19ffef27500f@suse.com>
 <81da4e8e-9dcf-4630-a535-39ce0b07260c@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: <81da4e8e-9dcf-4630-a535-39ce0b07260c@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 05/06/2025 6:06 pm, Teddy Astie wrote:
> Le 05/06/2025 à 12:27, Jan Beulich a écrit :
>> Move the function to its own assembly file. Having it in C just for the
>> entire body to be an asm() isn't really helpful. Then have two flavors:
>> A "basic" version using qword steps for the bulk of the operation, and an
>> ERMS version for modern hardware, to be substituted in via alternatives
>> patching.
>>
>> Alternatives patching, however, requires an extra precaution: It uses
>> memcpy() itself, and hence the function may patch itself. Luckily the
>> patched-in code only replaces the prolog of the original function. Make
>> sure this remains this way.
>>
> We can probably workaround that by using a separate memcpy for 
> alternatives patching. So it wouldn't end up patching itself.

Not memcpy() you can't.

The compiler is permitted to invent calls to memset()/memcpy() out of
thin air, e.g. struct big_foo = {}; as a local on the stack.

This is the same reason why it's impossible to do speculation safety in
C; you cannot guarantee to get protections ahead of the first RET.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 17:28:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 17:28:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007283.1386606 (Exim 4.92)
	(envelope-from )
	id 1uNENy-0000WF-E7; Thu, 05 Jun 2025 17:28:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007283.1386606; Thu, 05 Jun 2025 17:28: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 1uNENy-0000Vr-B2; Thu, 05 Jun 2025 17:28:14 +0000
Received: by outflank-mailman (input) for mailman id 1007283;
 Thu, 05 Jun 2025 17:28: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 1uNENw-0008Ub-TX
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 17:28:12 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20622.outbound.protection.outlook.com
 [2a01:111:f403:2412::622])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 73ecbf1e-4232-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 19:28:11 +0200 (CEST)
Received: from PH7PR17CA0012.namprd17.prod.outlook.com (2603:10b6:510:324::12)
 by DM4PR12MB6422.namprd12.prod.outlook.com (2603:10b6:8:b9::18) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Thu, 5 Jun
 2025 17:28:05 +0000
Received: from CY4PEPF0000EE3A.namprd03.prod.outlook.com
 (2603:10b6:510:324:cafe::54) by PH7PR17CA0012.outlook.office365.com
 (2603:10b6:510:324::12) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.34 via Frontend Transport; Thu,
 5 Jun 2025 17:28:05 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CY4PEPF0000EE3A.mail.protection.outlook.com (10.167.242.12) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Thu, 5 Jun 2025 17:28:05 +0000
Received: from localhost (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, 5 Jun
 2025 12:28:03 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 73ecbf1e-4232-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=slhFKtAi/znIfiSNnQ8DPwEk5K6l8KF3+uiAWRoJ41/3LJF2pOSvi6JCQKXJciNv6PatGq0o150MkFEsMrMmKNwvdElaAVZLwFJM9pudFfsW8iL+8J26l6UB0FDl7iAB2Yjpz56OKcxcpf4oPe/SLUjS8KVHFX0E9wqEL7yqL+Mtve0Vgab3hNeVb9e6sLwgZCfIp5HrZnKo4rOVX+TUfNyOY5XCpzyYgfaoeOUcGgvypA8o0r6r4BPKA0Jy9Mw7ml+RiOKWcEDiJpdHpgeIL00MXJk0Z3HQ0baWGvgf8mr9XqFDLS8+o7B5Zo3dvFRvOVuwrEaE5GtKL/+70q+zKQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=v45liQZ9u4g8rrXd0GBP0aliU2oTKBvp3+NCfl7FqCY=;
 b=YkZ0oGK+O30SSpwJsUtuVrYwQU2bf0dvkPtnDA8n6/e46oNASOF9MF9O5xTZI0VoOXDigoXHscuEz4Ch1xO8q3Zo3o0TqUmblR6qL/pi3YnnLDL2kBaAUddI5wVrWAjEYxJvNuSweHVGUjfmspy5R9icnQKY4AM1JHKwFKdv3Fc70gYtxVSZeeIVovnx2H5vGhYpyjPf8dwTv6eR6GDQPLl2A2PrgHaw0WzAMI2jnfG5FLgpVnSDxdahNnFSxp6N373hTQ26OJV4jDGZLKbPbuFpX/O5THw2I2qW6YTXcCQfhZVQZQG3hp48BsfzB+x960XUkVVs8WyZbkYOpGiB2g==
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=v45liQZ9u4g8rrXd0GBP0aliU2oTKBvp3+NCfl7FqCY=;
 b=ZiAy7Y4oD+rH8Mv8kfdJ+YW9yC25F7GJS1jRtsb+hx7ajTLceOabZcogaAAafyameqEcAdlgDVQtpvyZZbwYIkyPsQxU6reszbYahVq7xOQs/+aT6HFHysui4livKojHMaQ+A0hNCINa1CwKh+i2WmQWZQMlfSN3PUSyPJN7pes=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 5 Jun 2025 19:28:01 +0200
Message-ID: 
CC: Jan Beulich , =?utf-8?q?Roger_Pau_Monn=C3=A9?=
	, Stefano Stabellini , "Julien
 Grall" , Bertrand Marquis , "Michal
 Orzel" , "Daniel P. Smith"
	
Subject: Re: [PATCH 10/19] x86: Replace boot_module with bootmodule
From: Alejandro Vallejo 
To: Andrew Cooper ,
	
X-Mailer: aerc 0.20.1
References: 
 <20250530120242.39398-1-agarciav@amd.com>
 <20250530120242.39398-11-agarciav@amd.com>
 <214c8863-5cd4-4be9-948e-e44b67f541bd@citrix.com>
In-Reply-To: <214c8863-5cd4-4be9-948e-e44b67f541bd@citrix.com>
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: CY4PEPF0000EE3A:EE_|DM4PR12MB6422:EE_
X-MS-Office365-Filtering-Correlation-Id: 61c912a7-95fc-43b5-ea75-08dda45654c1
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|82310400026|376014|30052699003;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?WVcvc3YrODhpZUdWVDUxY2lsNk5NaWJTanhDRjE5cjl3UW40bmZzd2piMzZr?=
 =?utf-8?B?MUVzSFhNZG1MSnp3YnV4SmRFeFBZRU1URVpYWmc1c0lGeGpYS0JhMUJaWVV3?=
 =?utf-8?B?UG1sSzNLeGEzN1ZIUVJDSDhZc3NOSldMVko5WHZZTWpnTzZEd0NMRSsrbDlj?=
 =?utf-8?B?cjBMOTdHQTQ4Y0pCZVc3dFFtU3VKRjk1Z3FLNUV1S3YzcjNsTWNoQjBZM1A1?=
 =?utf-8?B?UU50T25XcjdSeDdXSkxMTVBURUJnLzhndUl1eG9wWkVSUzZJU2R4T3VxVGtZ?=
 =?utf-8?B?ZVdVK0NIRitOUnczTk1kcWNBcUlCWElKTlNSRmVkMkx2MGlUWlpVYWhBM1kr?=
 =?utf-8?B?RjlIS2w5SzBzK1ZYY2RIU1Q3a2F2RUNyTzNyL1dUSEZtWE9SUzVvcnBNY3RR?=
 =?utf-8?B?S1ZBWFJQbWtXaWpoZ09yS2NhRWhWczlYbUE2UVdYZHhvOGRRc3h1dVV6YXNQ?=
 =?utf-8?B?c0E4cEppaDAySGllVVJuMUpncTU3WVBkM0RQSi8zTUFyUVZya2lZZWJ4Q0Fr?=
 =?utf-8?B?RnorY21FVGRFZWY1NUVrMUt2eHlsUnlNelFCRWtCYUhFRnVNeGVwaFB6WEto?=
 =?utf-8?B?aG9qbWpUN0xDZDNoOTJDZWVwMU1aVWdmNm4zUFIvbEFXWG4ySWU5MVFnVmVU?=
 =?utf-8?B?UFVYeGxaY1RQa0dZNHh6MlQ3SWdtcVlwcGc0THlyMGlCZFFhWVlaSEVTMytU?=
 =?utf-8?B?TTFpVVVabENqWjdXMklwY1pKVExoUkxpZXQ2V0dtZFdscW5LU3pVRGU2SmdW?=
 =?utf-8?B?azBnYlF5ZmFDYksxWkRtUkppSDByZUJUWTlJcFIwU1hwSjh3dHVtR0xPTWZP?=
 =?utf-8?B?eC9lTE5kM1U3NUpGUVE4NUFFNkZkN1BxazRMN3pEV25GMDg1eEhESlMvU05x?=
 =?utf-8?B?Q2pNUzRPUTVPTmtFK21VV2tRaWsyVDBmQzZkd0tYem95dTF6Ukt6NVc5MEVi?=
 =?utf-8?B?ME5yYW9hL25Ca3hBRXhybDVCOGE0Szd6M3oxTHdUSGZ2RUpHR0N2V0t4T1Nh?=
 =?utf-8?B?Rm9NNGRSNVVmTTgyZng4NzY4M1BjZC9BeUFnSGo2OE9zYTFET0NXS3p5cmZt?=
 =?utf-8?B?UFFuOW43YmVjUU53aGlnaDJwRFkwc2FlSmg4dDdPZ1gvMXlsZjJaZHdXVVc3?=
 =?utf-8?B?WjRZTU5INkJuNmdhaUFId3FnbFhDK25ySzZSRFlIMXZpZUNIRTVYZ2RIRlJW?=
 =?utf-8?B?aTM4blQ0N2JkVHRTd1dJMWpVQXhyZmFnT1lReHFjdmdDVHJrMXV5OTdFLzQ5?=
 =?utf-8?B?d2FZWG1oSXZBNVcrRTV5NHNubm5MMXBVZWFSbHdKems5WDNudVltdlNoaDZT?=
 =?utf-8?B?SzhzOGdaYmhUM1pPTkc5bDV3TEMzYnhDU0xzUUJhODdVTlQ5SnJyem5UVUlw?=
 =?utf-8?B?ZXNCYW9GZUJEM3MwY2wzNGEzN0tCakNjeHhxUUpWS1gxQ2FROXNkTjJRS0Fq?=
 =?utf-8?B?TTFMdVUrWUwxK1FuZWhoVithcWthS2ZkejN6a3pUTFpHd2xJb3JHMnZ3ODBR?=
 =?utf-8?B?ZGRSK2pUTFBWRzViRTZlSU1lM2NlS3djc1U5aHdTNllnQ3luSzFxUzMzRHhi?=
 =?utf-8?B?NmNGem0xcDBPOHc3eFlTY0I4c0JqTkpWa1BJajBJd3RCalA3ZnY2S3QwekUv?=
 =?utf-8?B?NzZnQzJJSFBKTGIzUHZvTjBCd0NCMkxNZmk2TkF6aEVFOEJsb0xPVTVweG9P?=
 =?utf-8?B?Vkp3MDQ1YWppeWNBbXpvbWdHY0J0eEZQWkVUT3BMcFJIZnpIa3ZnM1RraFIx?=
 =?utf-8?B?am05Vy9pcHJ3VzlrYkVYUGpMZEJiUlk2UXoyQVQ2ZFRiTXJLeEoxTHNGckZa?=
 =?utf-8?B?eEtIUk94WVBVOEtMV0laQnhzeWN5NnV2NGdMV3hONU5CNEVJT3dFSEhQQUpl?=
 =?utf-8?B?b3R2UUVwVXZtOHFWWk9zUlBHZTE4alBFOE5JM0RsbGdqMWFoMGgzSWI2djBP?=
 =?utf-8?B?UGE4aUd1L29lUUFoMEZZRlhvelVNRzZYN0FXOW5lbHFRaEYzNjIwd0NvVlJL?=
 =?utf-8?B?MzNnU1dBZTA1RElWdXRvTUIyOGoxUHgxTWxZTi83TWF6SmdtODlYSVZab3dR?=
 =?utf-8?Q?9M2aJl?=
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)(30052699003);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jun 2025 17:28:05.1680
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 61c912a7-95fc-43b5-ea75-08dda45654c1
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:
	CY4PEPF0000EE3A.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6422

On Mon Jun 2, 2025 at 7:00 PM CEST, Andrew Cooper wrote:
> On 30/05/2025 1:02 pm, Alejandro Vallejo wrote:
>> These types resemble each other very closely in layout and intent, and
>> with "struct bootmodule" already in common code it makes perfect sense
>> to merge them. In order to do so, add an arch-specific area for
>> x86-specific tidbits.
>>
>> Signed-off-by: Alejandro Vallejo 
>
> Yet this is a distinct backwards step in terms of legibility.
>
> How about modifying the common code to be more legible, rather than
> regressing the x86 code.
>
> ~Andrew

I meant to ifdef out the fields unused on x86, but after some massaging I
think I got it lookin much nicer. It's essentially using the common parts o=
f
kernel_info and boot_domain as a header to kernel_info.

That way, x86 keeps using a substantially smaller (yet common) data structu=
re
while the rest of dom0less can keep using the original as-is.

Refactoring kernel_info to rationalise its contents is somewhere in my TODO
list, but I have much more urgent fish to fry first.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 17:33:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 17:33:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007297.1386615 (Exim 4.92)
	(envelope-from )
	id 1uNET8-0002dq-25; Thu, 05 Jun 2025 17:33:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007297.1386615; Thu, 05 Jun 2025 17:33: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 1uNET7-0002dj-Vb; Thu, 05 Jun 2025 17:33:33 +0000
Received: by outflank-mailman (input) for mailman id 1007297;
 Thu, 05 Jun 2025 17:33: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 1uNET6-0002dF-RN
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 17:33:32 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on2062f.outbound.protection.outlook.com
 [2a01:111:f403:2418::62f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2e3ab347-4233-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 19:33:26 +0200 (CEST)
Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
 by MW4PR12MB8610.namprd12.prod.outlook.com (2603:10b6:303:1ef::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Thu, 5 Jun
 2025 17:33:20 +0000
Received: from PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264]) by PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264%2]) with mapi id 15.20.8792.035; Thu, 5 Jun 2025
 17:33: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: 2e3ab347-4233-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Dyp6MH4bJbdRxLpW2ikRdWWbPajPuQlBHZpxIRBvwfp4HhotmDMwh+DSmB7My1GK8u4NXQBYdg2V7FxlwSrMGFRrAvp5qDOijZxNa3WD20x8ofShU/xx3KRfOEh3dp1I17IgAwA49bVnHxoTEgz5/AZMdALSNVA4ZBM8z7yVHUat+tobo0yQZVuNHdaFcQQ4JRItArlaRsZB0xsbQ5xYmgSf72BBEVbkLu3O9SdDshzNrSm97CpsjevKbBFUGY0IqEh32+JvNga3fc/j9aJpPrssZZZ9U3EoNIGrPLEYOZGnsfE3LC6qhctanKbdd4GNBA38lx+BpRfb8neo8ay7GQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=T452VS/Mby59853ocm9Cv7Ej6u9owIfqBYLtoDm0x08=;
 b=MfTPfDyRcaQcG+LquWi7unnSUbIzoFJCtxMx0QNaXbahJ2XUVtk/6BdjbV09ukF86q08B32mhMyM/eUS6Ws3GWBopuU5rCLz1QqZri3VGWvitOwNpc6pyTNyP2SyMegiub8BN5K7MrPTcQWFdmqT+0JclhBKRAQ1+LnwyzIHlPw6MTqsZexJUTgT/pVH1uA0rv0L5tq63xW2ffsqV0ZkxbEpfmtGVT4B3N6qRwx/8JsneB1NWUB+BSC2anm4voM0ZA7hM/NJgn80mkQ5TGmo2K+H6Bbuf4lZA3dTfLJCbb+OD0uuUTFGjadOIDBuXqs8hYzDNtRMW0CmCaJ/N1kR7g==
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=T452VS/Mby59853ocm9Cv7Ej6u9owIfqBYLtoDm0x08=;
 b=H4COKr2nDflVt2IuGO6QmVfooQYVD4VcqDHeIf0JPlW9lLHQmsP3es+yZ7Q8GhXD71QxxXQ6oCCu0aMWzhL/6+TEes6eJM6ckdJjXeEkVhRZnOSr8WJHTs9lv6FNPdHm1LqrVfTW1cAS11Pp1DuFrkwRw87Z0B7PqnxcifAHOBs=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Thu, 5 Jun 2025 18:33:16 +0100
User-Agent: Mozilla Thunderbird
Content-Language: en-GB
To: "xen-devel@lists.xenproject.org" ,
 xen-users@lists.xenproject.org, xen-announce@lists.xenproject.org
Cc: Stefano Stabellini 
From: Ayan Kumar Halder 
Subject: [ANNOUNCE] Xen Summit 2025 , our call for papers closes on 1st July
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: AS8PR05CA0013.eurprd05.prod.outlook.com
 (2603:10a6:20b:311::18) To PH8PR12MB7326.namprd12.prod.outlook.com
 (2603:10b6:510:216::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|MW4PR12MB8610:EE_
X-MS-Office365-Filtering-Correlation-Id: f3459053-a624-4743-d45e-08dda4571081
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?elNvbEw0YnMzeElHZWc1NjErZU93alF0bUVxSjNWMTRQYVJpd043NkVQeEI1?=
 =?utf-8?B?ZlZUK2VjenlhZnRDSy9VcFhEc29jei96M3Fhb215bXRsNXhKZE5kZFdXK29M?=
 =?utf-8?B?dzlZcm8rUEV6cHhSR09vOEF1RFdkVWduMk1ScGdKMkRvZlVsMEdnSm9zdGVD?=
 =?utf-8?B?YkdZL1JhYzVHZ2tDelhvdE5XUkJKYklQaFdUeVhSQnRJa2F1Yi9KaW9iWWRQ?=
 =?utf-8?B?dkU2RmEyVjkvRFdWeXVBT0hEN0pEN2xlWk1MbEd0N2YwNjdENG9xUWNuWEJq?=
 =?utf-8?B?TFlJZVIwZGYzM0VkaXVOUGhHNTVSWmRBZDhvUnlCRTJQbzJiK0ZJWFUwT3o4?=
 =?utf-8?B?eTFVV2dFZ3BHSUEyaVp5MFRJNFZ2Y0VaS1hIUFNVbTlTYzQvUUJteGdFazJE?=
 =?utf-8?B?V0JXRzRNdHNHcUJOeFNaM1dkMG43MHBJRnFjM3RXRDM3ZUpEYzVGdjNLMjZP?=
 =?utf-8?B?QnI4OUZldGFLdlBpb0t2K01ZUXNLN3Ivb20ybHgyUzdOR0E3TTNKVGhUNXlI?=
 =?utf-8?B?ZFFIbnFuUkNPc1FScmR0UkxvcENNZ3oxN0c1aVpCWkhoL1l5Nmc5ZXZ5Ym9L?=
 =?utf-8?B?TTlVMEZWUTlESHRGczVSU3J5L0s5MFd3Tm5pa2I5WUNvUWxnazVFaXhiaC9W?=
 =?utf-8?B?djVDRGlMWmhhdlFlMkh5RzRleXZSbzJXZ2M5bkIyNDlpQXR5RDJxUFhsaTZL?=
 =?utf-8?B?MTJ5ald2N0xaaVV3aWJOdjZCL29ZNDhSNkJoMW9CRVdrQ3FtUHNZUHlZeEpP?=
 =?utf-8?B?U25LMVZoR1Q5VTRDL0lMWnpWRnBpOU4yTkNSeUFXNHpldWhOSUlSSDBDVHNF?=
 =?utf-8?B?OHR0RWlTVUxyd1pEY2thUXFDMytVdXd5UW03VWR4Z2JVbjNENEc5eU1HRHdx?=
 =?utf-8?B?Si9WeDhLeVpsNUdPR2RWc1ByOE9PZ2tUYVhuelRtT01QNlNqdU50WVFUZCtl?=
 =?utf-8?B?Y0g1Y1lxLzFwVVVTWjhWdCtlOWk4WmxHUTFkNHR6Zy9qemhlRDc2Wk1Kd0ZL?=
 =?utf-8?B?VzEzSUZlNjZnZW9aenRKYVVKcTBpb3hXb2ZZWE5aSkp4Rm52Q3RSeGZSZ2lM?=
 =?utf-8?B?WWxoSkZTS25IdnhoTXJRY1dEalRVWHdrNWkrNWMxeWxyb3JKSkhxVXZUQUhy?=
 =?utf-8?B?S2lzVC9oczdKMmt0djRVTnk2U2NvSTNzN3pDYmRBUC9yLytYQ0wrdW1lenR1?=
 =?utf-8?B?QmVxNTQ0cDdhOWxHVThTNE1uRGROTWgwK2c0dWpLR3hNNjBwOXB3TldxV1FX?=
 =?utf-8?B?aHh0SUh6WFdIa3UvNmhvSjdxS0VPYVhSTDBPZlh0cHo3VHBxU2FoamhFeEJO?=
 =?utf-8?B?cmJXN3Q5UDM2SlM2NUdaN0R5ZjN5d1lyR2RTRkJSK1hVTHpqVCtBR21yK1d0?=
 =?utf-8?B?MklUdXdEMlBwdlBmVThaUVZEM2pPaGpCa3JnZTkrZEJ4Slk3c2F1R2oxUkNI?=
 =?utf-8?B?dis0eXB6ZFdGTzdpZVJKSmF5YXlaSXBPL1VnYjR4MFBYUmpiOTlST0gzemtY?=
 =?utf-8?B?V2NEcHUxZHdQUmx2blBUa2hNTGM0dTZSV1E5R1pGSGpvVzBpanJFZ1hmSjJI?=
 =?utf-8?B?MlNKeURpZDhMWTdLOHJTOGMwQ3ZBelRnZlEzZEYzbVhXQlk0bTRFcTFLYkJ4?=
 =?utf-8?B?ZHZ6MkMza3Q3OWE0ODhqRnZsUHNqOUNPK1YyRHVGU0sxQW9reDFFWktxOVpH?=
 =?utf-8?B?L0VBN1plK0cyNU1oU2tWVjd5eG5tLy9sdU5PeWgxRVpZM0lpdFpkRGR3TEMv?=
 =?utf-8?B?T1BzZ29yMG9kMjcwTU5sNUlLeEQxdzdyMDgxdzZUYndPVThrclBrdm9MZzZP?=
 =?utf-8?Q?gb9D4x1xIm8DeO2gFbvUKA9kgek2nCtI25lZ4=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?anZiUVFuOEp1Ung1THliL2puYU1UNndtcE1BbGhJRkNzR1h2bVIxMUZLQSt2?=
 =?utf-8?B?UUJJenljNVZCZDZTOTNScjVXUXJIME85V3plSktST0Y4ZStHZDE0dnQ2QkVj?=
 =?utf-8?B?R1hGYW1XOHFzZ3p1a1dlRmVvWnN0WDY4VDY3a2F3T2pWV1BWcHBqTWppTWpP?=
 =?utf-8?B?REpTdndITmZ4MmdoVTJDTzczWm1lZkVCaTlxN05EN3Z2bUZiTEFqYjd1ejdX?=
 =?utf-8?B?VmRJaXExRmFnVkl1T0dyQzlLa09VQitndW05N3dxQmdmSmNxL0JPNEtYbXFu?=
 =?utf-8?B?aUd4bENqUnVsTWIrMFVoeGNqMmRNdUE5TmI4T09uc3l2SWNNeGdsWGZnMHYx?=
 =?utf-8?B?ay9tNzFhcFFuWGZvMHZNZGJvM3RxdUhKMUw5NzA3dVdqSWFzanN3SitISXZ2?=
 =?utf-8?B?UE1MMjB4U2l1bmViNWpQd05rdnR3VEErRGExVUVtZ2ZaQTEvcXVkY1ZtVko1?=
 =?utf-8?B?ZGRWV0tTTVBqRG9IbStXY0VGRmZIMkJmRkxkQVZtcGNoWnlsaXV2clZwbFhy?=
 =?utf-8?B?SVpMN2ppQlArb0xtNWdGZHgwUTRZNE50c3IrUUtuK1JRQ21hRDU2M1FwL29G?=
 =?utf-8?B?WXRrVEk0MjRVL3YvUTR2bmFWRnpxd1ZEdmZ3VnNtZDREQzFyS1R1cE5DbDMy?=
 =?utf-8?B?c0NKb0g5MnNkWkhqbWRWWDdCcStTVzAxNm9PNmxEQ1ZOVkltaWQ3R2FLelho?=
 =?utf-8?B?cXQrYmtvOStXYmhTeWdTeitIMkJuOWpOeUxIeVB0S1h0bTlMbXdkSy9lS3A5?=
 =?utf-8?B?dERQWGlpU1NFY2cvNW9EbDZDaktGTUhMOTNwcDQ4R0QwK0ZmWk50dmxibnE5?=
 =?utf-8?B?Tm1YR2lyRUpmK2lRMnV6c3M2THlaazd0cUYrcXFUUDkzZjkrWGdMT2F6emhs?=
 =?utf-8?B?ZHpqYmE4MnhTSnp3WXhJbko3bGp6TzlUVWlkTkZqVTRabC8zTURBM3hhQzZP?=
 =?utf-8?B?UmZrV3VtTlJpNEMvRU5VZVZLOHNLcnNFaEk2VEhGbjcrV0FHQngwV2E5eGNQ?=
 =?utf-8?B?RDM4VlptTXludjgxSFcrL1hqcThBZnBXdzBuMnRpNVZLUDUyK0h3S1pTSlRo?=
 =?utf-8?B?NDBPNkpQdmdNZDlMZGpNMmVPT3NQb1FHNUtsT1g2YkJDenlJUnFkeG9jUEw0?=
 =?utf-8?B?ZFIyL21LdmRSNU5FbnFpNzZKTHc1dkxSRHBGM2FkNGUzdjRiZEsxNTJObVlk?=
 =?utf-8?B?S0RvZ09yUksvdis1K05URlR4dGtudWNLVUZ1UGlVa0ZXTmMvWi9wVG8vV1Jk?=
 =?utf-8?B?Y3pJMVdxaHRWWGNMZ1J2c3RUVXRjRHRkbStHdnBTdkczSzlucWpGRW0xa2M1?=
 =?utf-8?B?dFVXLzJ5RE5XZC9oamFnT3FlTGY1WGJBYSt5YTdiVVhUUUhEUkQ5KzZ3QkVN?=
 =?utf-8?B?SDhKOW9DYjlpZEgreDdUV2U2clhycHFOYU44YUtLYjV6RjUzYm1ZZjBPVm1W?=
 =?utf-8?B?QmN6SXZGRGdhekxVYlp1S2NhWVVjL05seE1PYjN1R1BkRE0xQ29Vcyt1cWpl?=
 =?utf-8?B?YTkvdTZvdjN1YUtPVTVkTklxdy82MjRxcVdkalY5YVFJUE9CbjZiaVF1RkNI?=
 =?utf-8?B?ZXFicjI3bHc1ZkdxVjZocURSeTc3U0ROdkVReElQZVRJMnplRHRJU1dwVVI0?=
 =?utf-8?B?ekl2NURqcVhwdUw1M3VvR1ppanViZW8xSStDSVpwWkhpVUpabzkyai9jenQy?=
 =?utf-8?B?eHYrYlpoUGFLa00zaHhpUXovb2VqUkZqbmNNOHZPWW04T1IrUklORjdicjVX?=
 =?utf-8?B?aTI4b2Fuc3A1VFZzZytDWHkrcGtmYUtrU3RJcjF3TmtzT3lxblNkZk84QjJO?=
 =?utf-8?B?V0VDNXNOcGNZdHpLYmpBNENCUGNsUWhVNlBtdk1jRVFKOXRYZ2J0OFBHb3pU?=
 =?utf-8?B?WUpYTUdUb3BZTFNjbDNKaVNkZ1ZRMmZidnp4N2Mrb0VmVGhLaXN4OUhtN25L?=
 =?utf-8?B?R1d3QjVYMGFabkF6ZFFxam0yc3NvZFZ6Znh1eUwrcjM0K1RzWEQxTGwwOGZG?=
 =?utf-8?B?QnhyOHU0emxIdm5ZNEp6ZEZHNmtqUnhPUHhyQllKbWxPdCtweHRIZVlqcnd5?=
 =?utf-8?B?WDF0aFBZZjJxdmpPS0wybTZmaTk3bmR2WTN5RUt3Z01vdkF0UHh3Um43YnF3?=
 =?utf-8?Q?KtRyJzu4AKE9Nu6gcutaQdAoL?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f3459053-a624-4743-d45e-08dda4571081
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jun 2025 17:33:20.7144
 (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: yl8f4434nBtdUStZPNyk4e9CZsEqgsYFikgAi5iqAoDQjdiUquJHgrLf5sv8tSjIigB0BwPTvJjtCrd5Wz5taw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB8610

Hi,

Please submit your talk for Xen summit.

Details - https://sessionize.com/xen-summit-2025/


You can find the talks for our previous summit at 
https://tinyurl.com/4ak2ys8x


Kind regards,

Ayan



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 17:34:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 17:34:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007303.1386625 (Exim 4.92)
	(envelope-from )
	id 1uNETc-00035N-Bb; Thu, 05 Jun 2025 17:34:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007303.1386625; Thu, 05 Jun 2025 17: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 1uNETc-00035G-8y; Thu, 05 Jun 2025 17:34:04 +0000
Received: by outflank-mailman (input) for mailman id 1007303;
 Thu, 05 Jun 2025 17:34: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 1uNETb-0002yp-7V
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 17:34:03 +0000
Received: from mail36.us4.mandrillapp.com (mail36.us4.mandrillapp.com
 [205.201.136.36]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 44e13c02-4233-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 19:34:02 +0200 (CEST)
Received: from pmta15.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail36.us4.mandrillapp.com (Mailchimp) with ESMTP id 4bCs4m6kfNzS63JDF
 for ; Thu,  5 Jun 2025 17:34:00 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 0bb2d6427e0a4913b4838eba3db60dae; Thu, 05 Jun 2025 17:34: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: 44e13c02-4233-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1749144840; x=1749414840;
	bh=7Qk+zJcuYuF4MWrIpDTvZSnqn9QBaHc5YiwsuPDkMs8=;
	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=ROEOnonTh3gvTGBqJwDIgY0rh3RCsMkM/N5StLGf5LDy6yavlKDyPkKQDEz6t4hjt
	 9IjFXfbOry94/xbH2zJXHgHDjwjtMZ5XF499FTdFW0lOMmGFYktIlwyPJPUCqjBGPW
	 VogNAOUP+oEYLD6SxEpO12fuR7z9pym9NmJ7euyi/lqZwpXe0cAsKdavNv5MxU8/Od
	 2rZCP/1i+cxI0pFNHWA2n9RG5Sz4Oz0E1jyc9Q9xmfujwvznsiNzZvdbhq6vBW0VjF
	 nS/h2SrMXVe+CzoPCadCpxoCvpUc2oRkUZqgcGlLn/NzWKZjP3TP0av8fXJbfLhAvd
	 Z5n/Qus0IHs9A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1749144840; x=1749405340; i=teddy.astie@vates.tech;
	bh=7Qk+zJcuYuF4MWrIpDTvZSnqn9QBaHc5YiwsuPDkMs8=;
	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=cGbh0gEWbi27YfH+h8/CH5UBm7ZyZbRey60OPjdz6vtWlR/KeUJq4TxTr/1XOsMpl
	 dSl1H4t5xKidoluR3xqkxZ8R0Cmchat6jOGcCxvHD5EIZN7CcQzjURr37UTFKWl5N6
	 8QdBwIuKwUbtDIThHkrKDoZsYihGUQLa8HeP9kWPrLyu4So3qENtpZsq6vCFvgdCgx
	 vkcDPNdnlZA4ZmrGcCObIYLTgC1jsNJ3kcGcRziIyPtnGW29dBcC/PrCJB49tknQjt
	 5LlMSY5mao5MRzKakKfrcvavWyuLLGh0PBgSHhU5yBtAj/effaXcnLJM/g89uPM6ZX
	 kl43NO+VzkBkw==
From: "Teddy Astie" 
Subject: =?utf-8?Q?Re:=20[PATCH=20v5=204/6]=20x86:=20control=20memset()=20and=20memcpy()=20inlining?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1749144839800
Message-Id: 
To: "Jan Beulich" , xen-devel@lists.xenproject.org
Cc: "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" 
References: <73481cbf-337f-4e85-81d2-3487366cd822@suse.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.0bb2d6427e0a4913b4838eba3db60dae?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250605:md
Date: Thu, 05 Jun 2025 17:34:00 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Le 05/06/2025 =C3=A0 12:28, Jan Beulich a =C3=A9crit=C2=A0:
> Stop the compiler from inlining non-trivial memset() and memcpy() (for
> memset() see e.g. map_vcpu_info() or kimage_load_segments() for
> examples). This way we even keep the compiler from using REP STOSQ /
> REP MOVSQ when we'd prefer REP STOSB / REP MOVSB (when ERMS is
> available).
> 

If the size is known and constant, and the compiler is able to generate 
a trivial rep movs/stos (usually with a mov $x, %ecx before). I don't 
see a reason to prevent it or forcing it to make a function call, as I 
suppose it is very likely that the plain inline rep movs/stos will 
perform better than a function call (even if it is not the prefered rep 
movsb/stosb), eventually also being smaller.

I wonder if it is possible to only generate inline rep movs/stos for 
"trivial cases" (i.e preceded with a plain mov $x, %ecx), and rely on 
either inline movs or function call in other cases (non-trivial ones).

> With gcc10 this yields a modest .text size reduction (release build) of
> around 2k.
> 
> Unfortunately these options aren't understood by the clang versions I
> have readily available for testing with; I'm unaware of equivalents.
> 
> Note also that using cc-option-add is not an option here, or at least I
> couldn't make things work with it (in case the option was not supported
> by the compiler): The embedded comma in the option looks to be getting
> in the way.
> 
> Requested-by: Andrew Cooper 
> Signed-off-by: Jan Beulich 
> ---
> v3: Re-base.
> v2: New.
> ---
> The boundary values are of course up for discussion - I wasn't really
> certain whether to use 16 or 32; I'd be less certain about using yet
> larger values.
> 
> Similarly whether to permit the compiler to emit REP STOSQ / REP MOVSQ
> for known size, properly aligned blocks is up for discussion.
> 
> --- a/xen/arch/x86/arch.mk
> +++ b/xen/arch/x86/arch.mk
> @@ -58,6 +58,9 @@ endif
>   $(call cc-option-add,CFLAGS_stack_boundary,CC,-mpreferred-stack-boundar=
y=3D3)
>   export CFLAGS_stack_boundary
>   
> +CFLAGS +=3D $(call cc-option,$(CC),-mmemcpy-strategy=3Dunrolled_loop:16:=
noalign$(comma)libcall:-1:noalign)
> +CFLAGS +=3D $(call cc-option,$(CC),-mmemset-strategy=3Dunrolled_loop:16:=
noalign$(comma)libcall:-1:noalign)
> +
>   ifeq ($(CONFIG_UBSAN),y)
>   # Don't enable alignment sanitisation.  x86 has efficient unaligned acc=
esses,
>   # and various things (ACPI tables, hypercall pages, stubs, etc) are won=
t-fix.
> 
> 

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 Jun 05 17:40:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 17:40:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007326.1386648 (Exim 4.92)
	(envelope-from )
	id 1uNEZe-0005Mq-8u; Thu, 05 Jun 2025 17:40:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007326.1386648; Thu, 05 Jun 2025 17:40: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 1uNEZe-0005Mg-57; Thu, 05 Jun 2025 17:40:18 +0000
Received: by outflank-mailman (input) for mailman id 1007326;
 Thu, 05 Jun 2025 17:40: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 1uNEZd-0005MZ-FU
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 17:40:17 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20607.outbound.protection.outlook.com
 [2a01:111:f403:2417::607])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 224736f4-4234-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 19:40:14 +0200 (CEST)
Received: from MW4PR04CA0095.namprd04.prod.outlook.com (2603:10b6:303:83::10)
 by DS0PR12MB6560.namprd12.prod.outlook.com (2603:10b6:8:d0::22) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Thu, 5 Jun
 2025 17:40:09 +0000
Received: from SN1PEPF0002BA52.namprd03.prod.outlook.com
 (2603:10b6:303:83:cafe::a3) by MW4PR04CA0095.outlook.office365.com
 (2603:10b6:303:83::10) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.30 via Frontend Transport; Thu,
 5 Jun 2025 17:40:08 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF0002BA52.mail.protection.outlook.com (10.167.242.75) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Thu, 5 Jun 2025 17:40:07 +0000
Received: from localhost (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, 5 Jun
 2025 12:40:05 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 224736f4-4234-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=TZ3Pv6SgxG19IwwD1YTqrWyRSpU+e2H/ZgVQgv6ydlHH+CDpe1qwKdQhSluc9xCaJ1bcBrcc1OJR9ziOvaQVHtqf7VkkOMFtceyagyxERE8EvIqE6MdLVoiVpghestijsq7OO+U9GtoVzcChjEJV3bEL8RzWByygGqs/gGlhWefz63xJ8/BYOwxHLkGpooG/mY048RBuPqMzKg20hulVLqCkzqRBl5wxJWnVKQVzdEnmDhkf/nszatKwEXcglMrB2qz9hcQjqdYB4doYnGM+CnZjQTVpFAXAjZuSq9Iw64+BBkX6ej9ZEZHNn5oLx+WI6a5cEiO5DTo6+6e/jCHvxw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=vimpMPdHYL+YnBg+U0CubumFa/MHj4vNVUVgGMMZS2M=;
 b=GadJzo62gFhEzZD8z6sfH4Exfg+u0hw50bgr5jqqW7pqgNDdcfcVDaQ/EpPc8TZxjrctY7XjxhOJn3u0ZBOFeF5SbRDOAolLdbCH2+gTc9CsCzj+cs6F0BcI33MBhTI2u2Q8YqUoKgA9afBRSakZZ1XQetqunCB8IaGyi66jeTl3BRX8gnR/ceteL+bPAOl3W81O3RNcvPQ4ztM1+J18wASZl6s4zgsnzsU+k+k1EJ2n4wn1CsfCjDFJS4xdAZRGrlEbEp0wOuFPGsxlCOknnT1RaOhNLzg2s8sxU7sna4EcS0F01pmO52fJG8jTitW16bmvoDCG89G5j7ZGwAomhA==
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=vimpMPdHYL+YnBg+U0CubumFa/MHj4vNVUVgGMMZS2M=;
 b=xIsMF4kylfp19o8AZojX43vjmZwoNf2HO+sE3Zgop5c3TWwwjefbsexh+ca2C19vNv8C3ohdu4PO0Vmrat5DSqKpCEA2X0C8AumYY41xRLNY8/t1frk4twtMCWmC/xJhxt/pGJ0qRz9NTBfinCW+UN7Q7SvIGNuYvZIPGxQG10Q=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 5 Jun 2025 19:40:04 +0200
Message-ID: 
CC: Jan Beulich , =?utf-8?q?Roger_Pau_Monn=C3=A9?=
	, Stefano Stabellini , "Julien
 Grall" , Bertrand Marquis , "Michal
 Orzel" , "Daniel P. Smith"
	, Xen-devel
	
Subject: Re: [PATCH 10/19] x86: Replace boot_module with bootmodule
From: Alejandro Vallejo 
To: Alejandro Vallejo , Andrew Cooper
	, 
X-Mailer: aerc 0.20.1
References: 
 <20250530120242.39398-1-agarciav@amd.com>
 <20250530120242.39398-11-agarciav@amd.com>
 <214c8863-5cd4-4be9-948e-e44b67f541bd@citrix.com>
 
In-Reply-To: 
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: SN1PEPF0002BA52:EE_|DS0PR12MB6560:EE_
X-MS-Office365-Filtering-Correlation-Id: 1c1352ad-9aac-402c-fdb1-08dda4580350
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:
	=?utf-8?B?TEU4VUI4V0hnb2dFVkJtYS9zN2J4dm1zeWlsU25nc3lRVkM5OFFWenlyaGoz?=
 =?utf-8?B?VmhvWTluK0lLY2o5c2pDOXErRUxJVzl3bmg5MmFZdUFXNTRFMmkzTllhekh0?=
 =?utf-8?B?blhCbG5NSnJJYktjb2JzV01ydGdQRjBHeDY5d0dGVUVYT3VNd0VVTWxzMGRY?=
 =?utf-8?B?SjZpeW9KMWZDNFExb0I4VzZ1U3RKQjY3QVIyMEU2czFmcGpNMkRKcUpoMFNU?=
 =?utf-8?B?MzBXNVJYc3FTMXgwUTY0V1ZIRGozNHMxUktwM0orVmJyV1MvT0s3MnRuTW1W?=
 =?utf-8?B?UzJtbExZc0U0RFNaVzcvS1JCR1p1bm43VnlyOVg2d3phU3NBV0l3NEcwVmE3?=
 =?utf-8?B?RWJlRldQdjF1NEtXcnRrMjBxbFlLV2JFOE5udUt4UGwyTmZWRCtyUjA5eWxS?=
 =?utf-8?B?ZGxYWkpnSG5pOHV0OGlXbXQ3NE8zWTh1a2M1VTNodGtNbXFaTmhxbjRSNG1i?=
 =?utf-8?B?OS9IdlVFZFdid2ZuUE1FU1ZwdTZtL2oyV1dSUEoyK3JSZjZ4ZGN6SEhOZDRm?=
 =?utf-8?B?bmlEcTJDWUMzTzFkejVsT3d0UEhaQVJ4TTN1MnlFRkZvckFidHJVWUp3dTBm?=
 =?utf-8?B?dXRXa2tUaWllanJHeFZhN0VVMXFHTW40UnV2anFUOG9LbWk2ZHQ1ZHBVNy81?=
 =?utf-8?B?dGJWSVl0YmJlNDB4dkR6UXFORVgzNXdXN0tWc0RFeDhPUGdSVFJPRlJrUUNG?=
 =?utf-8?B?RDNKOVl1M2JQdlRxblBkU3NtNWlEZHdJRkh3YXg5M3c0VllJN1NNZE1mMUds?=
 =?utf-8?B?bngwaVN6YzhBZk1uQWorVTg1Wis2OWxjV0Z2ZXJFQXFqdlNiUGJTaXhKdFJK?=
 =?utf-8?B?ZXJ4bi9IcHZ4TGh2NUF6S1dSaERmQXNUSXRhZTBaeDB0d2R5eUxldVZndTlL?=
 =?utf-8?B?T3ZpdWJtbEJpcUVUKzZNKzR1cHBZd1Q3TUNLbm9sZE5EQURNUnlIRVVVaHBQ?=
 =?utf-8?B?L1lYTjdTTVkvZDljZTg0UVpXclYvYUdNbUhZcVF1b2dTejlCWm05OURUUnBO?=
 =?utf-8?B?R1h6bDl3WEpiTzNSUmtXT3ZocnJTWXRodzBrWFJSdjh6dGhwamh2TnJSZEp3?=
 =?utf-8?B?cHpVR2tLSmxpODdXSE4rSTlQdHlHZFJ3VitYclpVMytsWm9LaXkwQ0FzSmo1?=
 =?utf-8?B?VEF6K2R4R3dWZGdmV3pkeHY2YTY3TlhVZlpVMTZxNnV3RVpvMEc1bE9mOXlW?=
 =?utf-8?B?eFFCeUpuWG9yOVFwekVWZHd1dGhoZ3UrMFNHc01uNDhGTm8yRGR2WHU3RzJv?=
 =?utf-8?B?a3d4NTh0bXpaYjVkNHg2eHpVQkExbjNGVXMrTlRXS2hDZDIxbDZZMHh6K3NW?=
 =?utf-8?B?MWlEMWltcFZVUnpUUEVpbkFrOVRUTXlNNHN1bUdoYkNnNUFJRzZVWVpybmNy?=
 =?utf-8?B?RlIzbkdGVGtuQUl0VHoxaGFNUk1URlNEdGN4Ym8vRHB0eWVTOHZOSlZJN25T?=
 =?utf-8?B?VjBjMDJMS1BQNHBKZXZOZ0IzSmkvc2RrM2pIcDBnYngyMndHVVZDWXNlNkZ4?=
 =?utf-8?B?bDRMT2lKalM5V3J2VEtpL0dBMktMNVo2SVBGU0xpc05OczZLc2VxNkhxOVpy?=
 =?utf-8?B?SmEwdGZsRDJ4N3kvWWpjVzhvYXRPYmlnZ2tjV09KZjVhTU5IeVordXZQeFR1?=
 =?utf-8?B?bVdpYkd0TXUrYk84SDJwZnRSMERRcmhOcWUxQytzTGtHeDFwOXA2T3ZzRkd0?=
 =?utf-8?B?YUlndjUrUDRUTGVNa1JMQUZ0dVRhVFRFRTA2OVU0cEdEcGltNFoyaE5TQXR0?=
 =?utf-8?B?WlFlNmc0ME5NM1hJWVpXc3dTQVV3cEZwd0hPT0FoMHI5NXd5MkhDdEx4ZGRC?=
 =?utf-8?B?L3p4YUNpVnp4dnFlcSsxTGcwRTJoTEF5T2cySnp6YzJJMVp5RjB6Z1RHMEZJ?=
 =?utf-8?B?TkZqZGxUMHVMSFFXOEw4bzFaNTYxbWZHaUd6LytHRFdUSDRINWJxRjMwU0s1?=
 =?utf-8?B?Tjh6S010dHAzdDVhQnpITlVDcXU3cW9mdDZmOFNwNHlJejJsSENLL1pIazhE?=
 =?utf-8?B?UDMxaFdmYms0eVZHNnpIZXcvUCsxSUZPRC90RXNjeWJnWm9xL3pSL2loODh3?=
 =?utf-8?Q?Guymux?=
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: 05 Jun 2025 17:40:07.5538
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1c1352ad-9aac-402c-fdb1-08dda4580350
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:
	SN1PEPF0002BA52.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB6560

On Thu Jun 5, 2025 at 7:28 PM CEST, Alejandro Vallejo wrote:
> On Mon Jun 2, 2025 at 7:00 PM CEST, Andrew Cooper wrote:
>> On 30/05/2025 1:02 pm, Alejandro Vallejo wrote:
>>> These types resemble each other very closely in layout and intent, and
>>> with "struct bootmodule" already in common code it makes perfect sense
>>> to merge them. In order to do so, add an arch-specific area for
>>> x86-specific tidbits.
>>>
>>> Signed-off-by: Alejandro Vallejo 
>>
>> Yet this is a distinct backwards step in terms of legibility.
>>
>> How about modifying the common code to be more legible, rather than
>> regressing the x86 code.
>>
>> ~Andrew
>
> I meant to ifdef out the fields unused on x86, but after some massaging I
> think I got it lookin much nicer. It's essentially using the common parts=
 of
> kernel_info and boot_domain as a header to kernel_info.
>
> That way, x86 keeps using a substantially smaller (yet common) data struc=
ture
> while the rest of dom0less can keep using the original as-is.
>
> Refactoring kernel_info to rationalise its contents is somewhere in my TO=
DO
> list, but I have much more urgent fish to fry first.
>
> Cheers,
> Alejandro

... I misread the comment and thought it was in the following patch rather =
than this one.

If it was indeed intended here, I'm at a loss as to what you'd rather do.
Common bindings need a common ground. This is such ground. The data structu=
res
are virtually identical and used for identical purposes.

What's the legibility step you're talking about?

If not in this form, then in another, but I do need some data structure
understandable on every architecture for this very use or hooking dom0less
binding support from common in a non-hacky way becomes impossible.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 17:44:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 17:44:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007338.1386657 (Exim 4.92)
	(envelope-from )
	id 1uNEd9-0006c0-Q8; Thu, 05 Jun 2025 17:43:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007338.1386657; Thu, 05 Jun 2025 17:43:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNEd9-0006bt-Mv; Thu, 05 Jun 2025 17:43:55 +0000
Received: by outflank-mailman (input) for mailman id 1007338;
 Thu, 05 Jun 2025 17:43: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 1uNEd7-0006bn-To
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 17:43:54 +0000
Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com
 [205.220.165.32]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a1133c67-4234-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 19:43:47 +0200 (CEST)
Received: from pps.filterd (m0333521.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 555FtV2O003111;
 Thu, 5 Jun 2025 17:43:35 GMT
Received: from phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com
 (phxpaimrmta01.appoci.oracle.com [138.1.114.2])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 471g8bpkbw-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Thu, 05 Jun 2025 17:43:34 +0000 (GMT)
Received: from pps.filterd
 (phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1])
 by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (8.18.1.2/8.18.1.2)
 with ESMTP id 555HUOD0039260; Thu, 5 Jun 2025 17:43:33 GMT
Received: from dm5pr21cu001.outbound.protection.outlook.com
 (mail-centralusazon11011014.outbound.protection.outlook.com [52.101.62.14])
 by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id
 46yr7cd6dj-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Thu, 05 Jun 2025 17:43:33 +0000
Received: from DS0PR10MB7224.namprd10.prod.outlook.com (2603:10b6:8:f5::14) by
 IA3PR10MB8662.namprd10.prod.outlook.com (2603:10b6:208:570::22) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8813.19; Thu, 5 Jun
 2025 17:43:14 +0000
Received: from DS0PR10MB7224.namprd10.prod.outlook.com
 ([fe80::c57:383f:cfb2:47f8]) by DS0PR10MB7224.namprd10.prod.outlook.com
 ([fe80::c57:383f:cfb2:47f8%4]) with mapi id 15.20.8813.018; Thu, 5 Jun 2025
 17:43: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: a1133c67-4234-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=
	corp-2025-04-25; bh=DBIA2YeJBswscGO/aSzs+i6/Sq1MaUxJv3wNEDcBOgg=; b=
	QbyLFEB8Yzxutqgoouq1E2DjZbXTaSSCxwb4neNm/20NbEdc5aiM6rM6gLVYJpk9
	SjN12Y0Up9Cxqea9RdzGTkEm+OQ/b3VfISXHfSjHHxw40AfPyeWurhYLuvup6FPX
	YTiJj7EfGTZMR7Z3suYectAQ5d/4+Npm/P07ZaFszvuXF1lr3+j9NXZ3x8Wfbgx2
	C6Qpwaive/v4qFT8GDPhASLvp15STpwrAU3f+GTNb87fSVPAVy/OjRK6qSSzOQ6p
	2/EjnceywiL/u/4JebeeAFCUKtDbyMa9l9H0YnGPtwh2T6fDXtrda6wAog3WvS60
	MMUk4DxGsjL2L41xnZpaFA==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=a7QhyVzFTQjEDDDfT+vKo/670eGuaQmp44EpzjJ5FgJ0Xt6bQABesSoGcvnuiD47yMhRvRYx6TdbeAU72Y3QqrwGoAwOgEEghawSDRQs61R20dWJTwONNt0wqzMyJHHZjR87Zr+ut85GAF4ii4+FsLXjFWq81hiXIr9wyJyCnnJoBft+LZnQXl3FRIRljvpPcrH57RW7+WnxPotFeEXgzlTlBIO4ZP3RcjUD1NA5ASBOqBukGSGhEKu9sSbVpTpUTwbM1kfdTqGOyssGU1G9514T6/dTq/f+vqwfL20WNDEb0+d8o20DuhKVeg+lPXZPC/eEElw2OYiHOrXdbTb89Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=DBIA2YeJBswscGO/aSzs+i6/Sq1MaUxJv3wNEDcBOgg=;
 b=clUHPJqUcVCt+QM7Ag+JABF+p46BDZsWI+X5UZEiWdKaHuKSDnCfWlnZYym3vhrUZDsm19X9kWVBkuItcePi9TErxA1KTb0SCVaSeg1AAGNNjGWXnJiwM8Ydb6tVqBuop24fW4858Qzc4Q+vgTfjgPWQSbqexEuycoIdVXajQIht1TmXOJobz74PP7rfdEaHtIJaCBI8J5pJAxTxsQnMOfWVEfowWsGIi1tk4z/NmuElWyxWNzoEEnW3KOp5yZozmAl3bJ5lP2vvRl1KHNXjclayCiyU8AdhrpB4nsM2/ITDxijLt5sVFi5D1JDpTCJZ8tRkqLFjPc04QziUyEId+w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=DBIA2YeJBswscGO/aSzs+i6/Sq1MaUxJv3wNEDcBOgg=;
 b=Noo4KfwK1MxjEUgOwZQYdWY989UJgve6fu9aiflmYaWb0nnIK0sSHZsey8Plk8WJMcSaOs8rOxUO2xr/I4Ck2B83KI4Tdk2t+eIHpnbc7NEy7zyJjfD7i27Novtx3EX/rueymJ4vXsbrvFkGesdYoRaI7RBPEaVqqQZBbrOWhJY=
Message-ID: 
Date: Thu, 5 Jun 2025 10:43:10 -0700
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 10/22] x86/tpm.c: code for early hashing and extending
 PCRs (for TPM1.2)
To: Sergii Dmytruk , xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
        Andrew Cooper
 ,
        =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 ,
        "Daniel P. Smith" ,
        trenchboot-devel@googlegroups.com, ross.philipson@oracle.com
References: 
 <0c249037eeda4809b565a55c6473bb21cdd0304e.1748611041.git.sergii.dmytruk@3mdeb.com>
Content-Language: en-US
From: ross.philipson@oracle.com
In-Reply-To: <0c249037eeda4809b565a55c6473bb21cdd0304e.1748611041.git.sergii.dmytruk@3mdeb.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: BN8PR03CA0006.namprd03.prod.outlook.com
 (2603:10b6:408:94::19) To DS0PR10MB7224.namprd10.prod.outlook.com
 (2603:10b6:8:f5::14)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS0PR10MB7224:EE_|IA3PR10MB8662:EE_
X-MS-Office365-Filtering-Correlation-Id: c465c1c9-370f-4c86-19bc-08dda4587236
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?eldOVGdPSDZab0FKWlh3Y0ZGMkNVODNGOS9ZQ3JveFZLZjVNL2EwRjFuRHFy?=
 =?utf-8?B?Yk1Hb2Z3WWJZZHJ3ajg5WnlkdGVGSkpIcndZZmM1azlxU1BZaHFDTVdQOVJU?=
 =?utf-8?B?WkU5SG5iN3RuMExIeVJRYXhleXJ6OXV5bmVSdDhjc0dWNXIvMHhyWGxLMHdt?=
 =?utf-8?B?NlhuUDNseGdYU05XWGI5aE1vazhGVlN6TnIrekpnTCs1MmZPTjdlWnBEYi8v?=
 =?utf-8?B?ZDAzMHZLb0hjUWVBSElZZ2JaZllSNTR3OGM5RG5hM0VzdzFDUzdlaE9JQ2ZL?=
 =?utf-8?B?OU5oS1ZUYUF2b0FJYkhIYmJTcTNxUHE5bDJnWXlSV1diU2ZYbTBXWG8yWEJs?=
 =?utf-8?B?QzlNa2p4Tm11U1h3by9DTHIxcEdvdmtXaDhTODd3bU0xWnhLOTNzNlNJelZv?=
 =?utf-8?B?ZnIveHhtTDYwU3NLY09yQkpiMVRQZVJUVG1lUnZ2MjRZbE5leUhJSlFQVSts?=
 =?utf-8?B?cGVrdWVHRDFYZ0lWL0dZUTNmditxR3dSRWU4Tnd2TDR3TTNaVWdPNllUd0xP?=
 =?utf-8?B?YzZ6YnRHSWYvSVNrc0hBQ3BrdGV1M3FYV0R2dDhqQXRrOElpQWNNY0c1c3NI?=
 =?utf-8?B?em92QklrSmlmM2tnNFhWd3N0M1ZUTXFWbXpEUTV2Mm02QXVmNmZEVTJmZ0ZZ?=
 =?utf-8?B?RE1PMkduVEF4VDRQOHRSd1R2QXJqVHBvRnkySzB4YWNJTVZmWDJFQTAwWGNo?=
 =?utf-8?B?ZXdDdGFlelhScTNib0xvZGlkb1ZlWEJRVWRQQ2lFbGFwajlRRzA2M2I3djQx?=
 =?utf-8?B?a2x5WVd4TExqbHJPb001ZDJqNkNtWGU5bThFQ3BBdnR1OERBS3J5TU03aWl2?=
 =?utf-8?B?SEF0ZklRV0tKeXR4aE5wN2trMXl4S1FBMm00cCtkZzE1Zk5EVkxqQ1ZtdGNr?=
 =?utf-8?B?L3NVTlBQM0NXRThPeUtYbHJPV21Ub3EvVStjTnJoK1hmaEtyZWZHNkdGditG?=
 =?utf-8?B?bkpSTnB0VnJ5WkxXcXV0WTB0cDRxVVMzeGV6YllLS1lLVXBBSS84YW5zY1RF?=
 =?utf-8?B?dWFDeStxNTBhV0kyWWhHaWpxc1NpYmExdnU1RC9Md0JsdG9yM2MrTEt6aGVv?=
 =?utf-8?B?dkZHbVQxZzFlY2pndi84U0xnbXVEcnJCbzFscmVIMnIyZDFXTk96cER6ZmlU?=
 =?utf-8?B?R1FlUGVkWXliQlNpOVBKRWFsdStkZnl0T1BmNTRYaXhFVjZuRkNmVGN6bksy?=
 =?utf-8?B?NmtoVThRaGU3NEkxMFR0QXM1YVFzemRndjBidXlvZXU2QUlsaTZzZDFOYTQ4?=
 =?utf-8?B?bUtCd09OVkhEMzZaSGlsSkQyM2hjYWd3Zmxwa2xZdWRha0dmTktmNnZ2YlRn?=
 =?utf-8?B?L09OVXZkSWtNMFdvVzJGYlYwa0ZUN1kwem5RWkM2UUo0bkQ3SmVMckdUNFox?=
 =?utf-8?B?aWFKRXdUdGhkUEZVb3hFT2JZTXFTZ09WdmtWbGJocUZrMjdUUWg2Ry8wTVFN?=
 =?utf-8?B?VUErSTNDYVMxbEJLOGhMZDJqQ1RvdERRRGdpQThoOHNNa1d3MWRDTkJ6eVJN?=
 =?utf-8?B?eDJWMUVTamV5akFrMFBOWlR4aXFXUWQ4aUFwazBoNzRCUkJBbFpoSU95VWl4?=
 =?utf-8?B?NkhVdmptTUdsbVhGVWFGQnlFL1B5YitDNGk1dk0yT0ZTbGFhaitQRlo1QTBZ?=
 =?utf-8?B?aUJyNG1Jb2xiU1QrbVlORXRGbXdRRmx3Zzl5TURiRFgxNnptVWFyNVBnMzVG?=
 =?utf-8?B?RUYxajVCdDVWN0d6bGVnOW93ajNlRTNMM3h1aHNXMUxnSWRXNkFTVVQ5cEdo?=
 =?utf-8?B?bzlEWUNHZlh5WnZXYUFCZmlEN0ZyVmZyVnhIaEQ1cVFJVnJHWVkrSG5lZ28y?=
 =?utf-8?B?N2xxQnpETC9ST01EcFY4azhrK2ZDOVNqYml1R0ZjNUJtWXNqUi81V1gxV0N2?=
 =?utf-8?B?RkF5NnVzaDkvUDgvc3ltWGhMK2JNbUV1UzBwdVNKUlpEUjJhZEw2T21LRzZQ?=
 =?utf-8?Q?zbOJ2khq5n8=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS0PR10MB7224.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?UEFabjZZWFVsTzQ5QXJxLytiaFJJN3RrL2ErKzVCYktlbldNWHRNQWdMS05v?=
 =?utf-8?B?enVCRWVQVlpvSWxtczVYZWFLLy9EWVFsWFkvVU83OG1OVnF6VExrQ096MzBj?=
 =?utf-8?B?bVBXYmNjN2pxaU9hVFEwMkRJK3BlUWhNRnpFWHNzMjNFSCtMdkRCY052cTlK?=
 =?utf-8?B?aStwZ3NuV1ZxcjdyS09yamovWFVpR3FDd0NzUUJ2VHM5WWJseWZuNm1TeE9P?=
 =?utf-8?B?NFB2ek9iK3NKWVdTOEpBcjVaTE9QME0rc2RPcVBVWDcvc0luRVpDa2FVcEU5?=
 =?utf-8?B?RjUwR1UzMWNvb2xqaW9uMGppME5vM1NPYzJreFlGMDdzbmZ0S3Z2Rjh4TCtZ?=
 =?utf-8?B?Z3FtNk9OZXZqeUFhdkJQQXllNWhkWW9ic3RtSWg4SEQvV0lQWUhFSDdZTUZR?=
 =?utf-8?B?dmh5UHVmZXYxbUU4bWpyOGF0b0Fkc2FJK0gyNDBhamNWUnl2Y1lmY2ZONGpD?=
 =?utf-8?B?ZStXQUJHU096emI0L00rbnZ3YitteWtJdHo0ZXM1TExtTmEra2s2Y2VmcStW?=
 =?utf-8?B?K20xQlV0NmlGbDdwUjZIZW52NlJORXVxOWxSN0NxRUJmMkduUjZ4cC9CbWEx?=
 =?utf-8?B?TFZlNlh0U25EZlFFMEpKSlhoTXkwRGZ2TXdBTkFDWStuZGlaa2NFeEhLcnB1?=
 =?utf-8?B?bExpQW45V1NBK0lFWUQ4NUQwRHZUTUloMlNlY3JWcVh4aXFSeGRFN1NGcWhl?=
 =?utf-8?B?UDc0NUp0bFo4N1RXREZuakdaWW1ocGdYNWM3eERxU1QwaVh5WFFZRGVlWmVw?=
 =?utf-8?B?YXlmdFdtVkUxb0tkemJqbzZNODJNMklmWmtaa3ZwRTg3SUxYOEZycDF2MGVI?=
 =?utf-8?B?QzBuK2FHMWkySkVEbXVvMzJpbWJCMlNaUkhTY2pTc2VLTnZXVFJUYVo2d3lj?=
 =?utf-8?B?ZlR1TVhxUjBmYVVzbjg1VVFJNkVPZkVsdWhUb1EvazR5UzRmbzkxaWxQeTRV?=
 =?utf-8?B?T2pHRU5yMHIrU1BXTlF1ckJXVCs1dlN2OTlOT2VyTVZIUUR0L0FzQ01WSWV3?=
 =?utf-8?B?Z0NoNGtpMDFydk1BeitTK2RlN25xUVpsdVVXT2swOXViZVcrS2VjV0V1TE56?=
 =?utf-8?B?aE5LcVVsVjJ0OHBEVUVrTDhTdzlRekJKUndwbGlEajhvRlJJVjhvSXlVRGZ3?=
 =?utf-8?B?Mk5wKzNWUm0wTzlOMHZnSUdrc2FQZmRrUWhZeWlnVllIME1RSGdwdU9WSXRv?=
 =?utf-8?B?eFlwYW16OElJWVp1NkEzVXIxVldaakFVWDRaWnVNNGFkNjZIclBrM0t5ZTFo?=
 =?utf-8?B?cnhXbndmbTRIZ3lqbFBwYU1BVG1MMEt2elV6MHAxbnoxUm53T0JrWUU2a0dz?=
 =?utf-8?B?cmtwQkZtTnBXTU9vU2M2SmVkbDFwSERxY0tKZk5KVDhRRzVDUEZvS2hnK3pO?=
 =?utf-8?B?MUVrbFQ5cFhKSDRzdWlOeGRTZnJtekV1K0ZvY051TTA3QTNkb0FkMXRjT2wr?=
 =?utf-8?B?ZlptYUEyTmduMUhrTWp5U01OdWNDT0dMdEpMWnNRNDZBTmhhZjM0WDZiSlJH?=
 =?utf-8?B?S1lPMHdkYVVOQnBySDZ4KzJIaUl6Vk92TzFzOGhsUFlKQ0d0bkRNK0ZHa0VY?=
 =?utf-8?B?TklIZSthMHdxMDV6eEdvQ1ZnbzBMREJCMnduUTRRcldhb1luaEJ5cjFORTA4?=
 =?utf-8?B?Wmk0RnVDdDJFWnluWWgxd0RsMVFOczBRUHlJeG5IRWlSVkRJd29YR3Bwa0dS?=
 =?utf-8?B?c1hDMlFmT2dqSEJvL0oyejY2NytDajM0Ri9WWEM2NnFCREFLTGZJT1l1Tmsw?=
 =?utf-8?B?TnlnbVRmTktuVVFRU2N2cHhqZzl3Mk9PNWdJS0pvWUZVWnJ0WDV6MnFpMnpy?=
 =?utf-8?B?TkRIdkpxbGw0NXhqcEdFaUdYN1A2YXpWcnB4TWU2K0E5QVdRUmFsaWVqekh4?=
 =?utf-8?B?UEtDLzU2eWpxN2hiWkJUdVh4UnN5dTJIeXd0c2UwNWRhakZ5U3ljWFAzRktF?=
 =?utf-8?B?Rml6Mlg5TXJmVkdIbE5SYmJTT0FabDY1QUtRc3dxUHZGaThUelhBNGpsMkYw?=
 =?utf-8?B?U2VrOTFQWDBXemVmc0ZxbDNwa01ESmtUV0FqRkhEdkhzUk5nUEV3alNNa0hN?=
 =?utf-8?B?RExUd2JIWG9ybmJjUENDYXRQN3oyWG9rakhtd05MZ2g2blg2ZWJjcDRvbWxB?=
 =?utf-8?B?NFBxME1mY3Y5U1FaWFM5NkVobVFZZjZXNi92NER5SkNpRjZvekhVZHhod085?=
 =?utf-8?B?U3c9PQ==?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	D2PiAkpdpI0DIPpryOcV9TaUUP1A+RoYc7EizMG/sDppiDnwHo4B1Un8uP/EvhHzMdHZjXwknvSiNfoA2T0yuhvw+lbGBR9Av7ojOQL9TEXoeHkG2+OhPblxXBdwQWi8QB70GIs5VzisUqe6O/sOhlEfTl7Vu8kRH5dXKWBPeg40WU0r89q9C3rWaHVUaghgLztTq/DhEKv6g1NkgslktsflcAnHVBVCSazqllDPIGJTqlLVB/j/duepW0MgtPA0aW/dBuzw67RR2LLpJOXUa3pwzgFSkU3slS23Xl2QbpTvNRveuEeafu2jRQ4YmLMlxh11q2ZVooAr3lDVONoBVYcZ1mx/hfhfIPi9/wGDRi/3WWUxL1JZ/M5VqMou+HshLgx/JQmNBB/H9V/O2udwptFgoZ0xbE1pAyUkXeMoaj6cydTLcQTmYAtLokbZ0Jll7WkRYFlwGGzV6RuYBRvU4t/C+FLL4u26aMDO/7oIOSHXqWKUzrHkJXIi0yfVCKM8IvcxhpM9sol86d/fieWGaROvexRIehKIV4o9nzLJTtczs/MoDxdaNcb9QRCFy+7K4xX1utqNdnDVIyNbW1OS3a/Qr6sxov3xCfgy0WJJjh8=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c465c1c9-370f-4c86-19bc-08dda4587236
X-MS-Exchange-CrossTenant-AuthSource: DS0PR10MB7224.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jun 2025 17:43:13.9428
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: fpelPo7Z8hC6J//eikjSv6VJOZn+A00bUYwWBNNvODLLYxZo/38m/nHJd0Tu1QmVWy0Aepk8wyoD6yHeoVKI2VOXHZREDaSebc8kFuNkUoI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA3PR10MB8662
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40
 definitions=2025-06-05_04,2025-06-05_01,2025-03-28_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 bulkscore=0 suspectscore=0
 phishscore=0 mlxlogscore=999 adultscore=0 malwarescore=0 mlxscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2505160000
 definitions=main-2506050157
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjA1MDE1NyBTYWx0ZWRfX0ZEvprsXi4h2 VuG/msr2WYxnCKlydpd3I14txxacz8X8lcYbUC0jRr/OBryOL1lh25LrOSOoDVi203uaHTBqSPq 0iUeFkOBlC2CRygJTd82l3wf/Ar7SVTC74hUOAEaR91PxUV10fQRbbE1GAVBtAkuTBw5h5yKRJU
 k3udq7ah8wiJWH3vbfjW9BBNvRRUwveSw/D44y2oeKOHLD8gGTH4O4MOuvJnVJ+b6Z2IpzYQzDV p+GKTPM9HUt1wlCK0hDijWqbpjtQjBaHa3KPQiDa/OFSIXfb5SbkyQyp6U1ydw1SqKH5djtHk1/ p1jUJiTA1/djh718n8ge/t7aEkyRlCwfyNUkXYUsMNOzeCK22WPTAUJU9icNMW3rye2PtpYmyEW
 osUoe/UvPYcxathOW7KYZZPgmrZcEbG3B5Je5BZWu3slRwmCU6wE9R/mEI8Nc8B/n9ONB9vy
X-Proofpoint-GUID: k4W6lV0chOB61NAug6fxlevEMZD8vSAJ
X-Proofpoint-ORIG-GUID: k4W6lV0chOB61NAug6fxlevEMZD8vSAJ
X-Authority-Analysis: v=2.4 cv=H+Dbw/Yi c=1 sm=1 tr=0 ts=6841d746 cx=c_pps a=XiAAW1AwiKB2Y8Wsi+sD2Q==:117 a=XiAAW1AwiKB2Y8Wsi+sD2Q==:17 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19
 a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=6IFa9wvqVegA:10 a=GoEa3M9JfhUA:10 a=C_d68mY_AAAA:8 a=0S3p-o084Hdno6JN4usA:9 a=QEXdDO2ut3YA:10 a=wASdygnoxNaGnvDdgHrj:22

On 5/30/25 6:17 AM, Sergii Dmytruk wrote:
> From: Krystian Hebel 
> 
> This file is built twice: for early 32b mode without paging to measure
> MBI and for 64b code to measure dom0 kernel and initramfs. Since MBI
> is small, the first case uses TPM to do the hashing. Kernel and
> initramfs on the other hand are too big, sending them to the TPM would
> take multiple minutes.
> 
> Signed-off-by: Krystian Hebel 
> Signed-off-by: Sergii Dmytruk 
> ---
>   xen/arch/x86/Makefile              |   1 +
>   xen/arch/x86/boot/Makefile         |   7 +-
>   xen/arch/x86/boot/head.S           |   3 +
>   xen/arch/x86/include/asm/slaunch.h |  14 +
>   xen/arch/x86/include/asm/tpm.h     |  19 ++
>   xen/arch/x86/slaunch.c             |   7 +-
>   xen/arch/x86/tpm.c                 | 437 +++++++++++++++++++++++++++++
>   7 files changed, 486 insertions(+), 2 deletions(-)
>   create mode 100644 xen/arch/x86/include/asm/tpm.h
>   create mode 100644 xen/arch/x86/tpm.c
> 
> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> index 5788898166..2d008a5f52 100644
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -66,6 +66,7 @@ obj-y += spec_ctrl.o
>   obj-y += srat.o
>   obj-y += string.o
>   obj-y += time.o
> +obj-y += tpm.o
>   obj-y += traps-setup.o
>   obj-y += traps.o
>   obj-$(CONFIG_INTEL) += tsx.o
> diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
> index 5471b966dd..55fbe155b6 100644
> --- a/xen/arch/x86/boot/Makefile
> +++ b/xen/arch/x86/boot/Makefile
> @@ -6,6 +6,7 @@ obj32 := cmdline.32.o
>   obj32 += reloc.32.o
>   obj32 += reloc-trampoline.32.o
>   obj32 += slaunch-early.32.o
> +obj32 += tpm-early.32.o
>   
>   obj64 := reloc-trampoline.o
>   
> @@ -31,6 +32,10 @@ $(obj)/%.32.o: $(src)/%.c FORCE
>   
>   $(obj)/slaunch-early.32.o: XEN_CFLAGS += -D__EARLY_SLAUNCH__
>   
> +$(obj)/tpm-early.32.o: XEN_CFLAGS += -D__EARLY_SLAUNCH__
> +$(obj)/tpm-early.32.o: $(src)/../tpm.c FORCE
> +	$(call if_changed_rule,cc_o_c)
> +
>   orphan-handling-$(call ld-option,--orphan-handling=error) := --orphan-handling=error
>   LDFLAGS_DIRECT-$(call ld-option,--warn-rwx-segments) := --no-warn-rwx-segments
>   LDFLAGS_DIRECT += $(LDFLAGS_DIRECT-y)
> @@ -84,7 +89,7 @@ cmd_combine = \
>                 --bin1      $(obj)/built-in-32.base.bin \
>                 --bin2      $(obj)/built-in-32.offset.bin \
>                 --map       $(obj)/built-in-32.base.map \
> -              --exports   cmdline_parse_early,reloc,reloc_trampoline32,slaunch_early_init \
> +              --exports   cmdline_parse_early,reloc,reloc_trampoline32,slaunch_early_init,tpm_extend_mbi \
>                 --output    $@
>   
>   targets += built-in-32.S
> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
> index b4cf423c80..9a272155e9 100644
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -527,6 +527,9 @@ __start:
>           /* Store MBI address in EBX where MB2 code expects it. */
>           mov     %eax, %ebx
>   
> +        /* tpm_extend_mbi(mbi/eax, slrt/edx) using fastcall. */
> +        call    tpm_extend_mbi
> +
>           /* Move magic number expected by Multiboot 2 to EAX and fall through. */
>           movl    $MULTIBOOT2_BOOTLOADER_MAGIC, %eax
>   
> diff --git a/xen/arch/x86/include/asm/slaunch.h b/xen/arch/x86/include/asm/slaunch.h
> index 7891d60035..3b38045864 100644
> --- a/xen/arch/x86/include/asm/slaunch.h
> +++ b/xen/arch/x86/include/asm/slaunch.h
> @@ -10,6 +10,20 @@
>   #include 
>   #include 
>   
> +#define DRTM_LOC                   2
> +#define DRTM_CODE_PCR              17
> +#define DRTM_DATA_PCR              18
> +
> +/*
> + * Secure Launch event log entry types. The TXT specification defines the base
> + * event value as 0x400 for DRTM values, use it regardless of the DRTM for
> + * consistency.
> + */
> +#define DLE_EVTYPE_BASE            0x400
> +#define DLE_EVTYPE_SLAUNCH         (DLE_EVTYPE_BASE + 0x102)
> +#define DLE_EVTYPE_SLAUNCH_START   (DLE_EVTYPE_BASE + 0x103)
> +#define DLE_EVTYPE_SLAUNCH_END     (DLE_EVTYPE_BASE + 0x104)
> +
>   /* Indicates an active Secure Launch boot. */
>   extern bool slaunch_active;
>   
> diff --git a/xen/arch/x86/include/asm/tpm.h b/xen/arch/x86/include/asm/tpm.h
> new file mode 100644
> index 0000000000..d1e791fc69
> --- /dev/null
> +++ b/xen/arch/x86/include/asm/tpm.h
> @@ -0,0 +1,19 @@
> +/*
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + *
> + * Copyright (c) 2022-2025 3mdeb Sp. z o.o. All rights reserved.
> + */
> +
> +#ifndef X86_TPM_H
> +#define X86_TPM_H
> +
> +#include 
> +
> +#define TPM_TIS_BASE  0xfed40000U
> +#define TPM_TIS_SIZE  0x00010000U
> +
> +void tpm_hash_extend(unsigned loc, unsigned pcr, const uint8_t *buf,
> +                     unsigned size, uint32_t type, const uint8_t *log_data,
> +                     unsigned log_data_size);
> +
> +#endif /* X86_TPM_H */
> diff --git a/xen/arch/x86/slaunch.c b/xen/arch/x86/slaunch.c
> index ac3b43942b..5f91fe5ad0 100644
> --- a/xen/arch/x86/slaunch.c
> +++ b/xen/arch/x86/slaunch.c
> @@ -13,6 +13,7 @@
>   #include 
>   #include 
>   #include 
> +#include 
>   
>   /*
>    * These variables are assigned to by the code near Xen's entry point.
> @@ -66,16 +67,20 @@ struct slr_table *__init slaunch_get_slrt(void)
>   
>   void __init slaunch_map_mem_regions(void)
>   {
> +    int rc;
>       void *evt_log_addr;
>       uint32_t evt_log_size;
>   
> +    rc = slaunch_map_l2(TPM_TIS_BASE, TPM_TIS_SIZE);
> +    BUG_ON(rc != 0);
> +
>       /* Vendor-specific part. */
>       txt_map_mem_regions();
>   
>       find_evt_log(slaunch_get_slrt(), &evt_log_addr, &evt_log_size);
>       if ( evt_log_addr != NULL )
>       {
> -        int rc = slaunch_map_l2((uintptr_t)evt_log_addr, evt_log_size);
> +        rc = slaunch_map_l2((uintptr_t)evt_log_addr, evt_log_size);
>           BUG_ON(rc != 0);
>       }
>   }
> diff --git a/xen/arch/x86/tpm.c b/xen/arch/x86/tpm.c
> new file mode 100644
> index 0000000000..7fb19ce4fa
> --- /dev/null
> +++ b/xen/arch/x86/tpm.c
> @@ -0,0 +1,437 @@
> +/*
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + *
> + * Copyright (c) 2022-2025 3mdeb Sp. z o.o. All rights reserved.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#ifdef __EARLY_SLAUNCH__
> +
> +#ifdef __va
> +#error "__va defined in non-paged mode!"
> +#endif
> +
> +#define __va(x)     _p(x)
> +
> +/* Implementation of slaunch_get_slrt() for early TPM code. */
> +static uint32_t slrt_location;
> +struct slr_table *slaunch_get_slrt(void)
> +{
> +    return __va(slrt_location);
> +}
> +
> +/*
> + * The code is being compiled as a standalone binary without linking to any
> + * other part of Xen.  Providing implementation of builtin functions in this
> + * case is necessary if compiler chooses to not use an inline builtin.
> + */
> +void *(memcpy)(void *dest, const void *src, size_t n)
> +{
> +    const uint8_t *s = src;
> +    uint8_t *d = dest;
> +
> +    while ( n-- )
> +        *d++ = *s++;
> +
> +    return dest;
> +}
> +
> +#else   /* __EARLY_SLAUNCH__ */
> +
> +#include 
> +#include 
> +
> +#endif  /* __EARLY_SLAUNCH__ */
> +
> +#define TPM_LOC_REG(loc, reg)   (0x1000 * (loc) + (reg))
> +
> +#define TPM_ACCESS_(x)          TPM_LOC_REG(x, 0x00)
> +#define ACCESS_REQUEST_USE       (1 << 1)
> +#define ACCESS_ACTIVE_LOCALITY   (1 << 5)
> +#define TPM_INTF_CAPABILITY_(x) TPM_LOC_REG(x, 0x14)
> +#define INTF_VERSION_MASK        0x70000000
> +#define TPM_STS_(x)             TPM_LOC_REG(x, 0x18)
> +#define TPM_FAMILY_MASK          0x0C000000
> +#define STS_DATA_AVAIL           (1 << 4)
> +#define STS_TPM_GO               (1 << 5)
> +#define STS_COMMAND_READY        (1 << 6)
> +#define STS_VALID                (1 << 7)
> +#define TPM_DATA_FIFO_(x)       TPM_LOC_REG(x, 0x24)
> +
> +#define swap16(x)       __builtin_bswap16(x)
> +#define swap32(x)       __builtin_bswap32(x)
> +
> +static inline volatile uint32_t tis_read32(unsigned reg)
> +{
> +    return *(volatile uint32_t *)__va(TPM_TIS_BASE + reg);
> +}
> +
> +static inline volatile uint8_t tis_read8(unsigned reg)
> +{
> +    return *(volatile uint8_t *)__va(TPM_TIS_BASE + reg);
> +}
> +
> +static inline void tis_write8(unsigned reg, uint8_t val)
> +{
> +    *(volatile uint8_t *)__va(TPM_TIS_BASE + reg) = val;
> +}
> +
> +static inline void request_locality(unsigned loc)
> +{
> +    tis_write8(TPM_ACCESS_(loc), ACCESS_REQUEST_USE);
> +    /* Check that locality was actually activated. */
> +    while ( (tis_read8(TPM_ACCESS_(loc)) & ACCESS_ACTIVE_LOCALITY) == 0 );
> +}
> +
> +static inline void relinquish_locality(unsigned loc)
> +{
> +    tis_write8(TPM_ACCESS_(loc), ACCESS_ACTIVE_LOCALITY);
> +}
> +
> +static void send_cmd(unsigned loc, uint8_t *buf, unsigned i_size,
> +                     unsigned *o_size)
> +{
> +    /*
> +     * Value of "data available" bit counts only when "valid" field is set as
> +     * well.
> +     */
> +    const unsigned data_avail = STS_VALID | STS_DATA_AVAIL;
> +
> +    unsigned i;

Is this all that is needed to do the send? I would have thought you 
would at least also need that burst count logic to know when the TPM is 
ready for more data. There are also a number of timeouts that are 
supposed to be used. Maybe Daniel has some thoughts too.

> +
> +    /* Make sure TPM can accept a command. */
> +    if ( (tis_read8(TPM_STS_(loc)) & STS_COMMAND_READY) == 0 )
> +    {
> +        /* Abort current command. */
> +        tis_write8(TPM_STS_(loc), STS_COMMAND_READY);
> +        /* Wait until TPM is ready for a new one. */
> +        while ( (tis_read8(TPM_STS_(loc)) & STS_COMMAND_READY) == 0 );
> +    }
> +
> +    for ( i = 0; i < i_size; i++ )
> +        tis_write8(TPM_DATA_FIFO_(loc), buf[i]);
> +
> +    tis_write8(TPM_STS_(loc), STS_TPM_GO);
> +
> +    /* Wait for the first byte of response. */
> +    while ( (tis_read8(TPM_STS_(loc)) & data_avail) != data_avail);
> +
> +    for ( i = 0; i < *o_size && tis_read8(TPM_STS_(loc)) & data_avail; i++ )
> +        buf[i] = tis_read8(TPM_DATA_FIFO_(loc));
> +
> +    if ( i < *o_size )
> +        *o_size = i;
> +
> +    tis_write8(TPM_STS_(loc), STS_COMMAND_READY);
> +}
> +
> +static inline bool is_tpm12(void)
> +{
> +    /*
> +     * If one of these conditions is true:
> +     *  - INTF_CAPABILITY_x.interfaceVersion is 0 (TIS <= 1.21)
> +     *  - INTF_CAPABILITY_x.interfaceVersion is 2 (TIS == 1.3)
> +     *  - STS_x.tpmFamily is 0
> +     * we're dealing with TPM1.2.
> +     */
> +    uint32_t intf_version = tis_read32(TPM_INTF_CAPABILITY_(0))
> +                          & INTF_VERSION_MASK;
> +    return (intf_version == 0x00000000 || intf_version == 0x20000000 ||
> +            (tis_read32(TPM_STS_(0)) & TPM_FAMILY_MASK) == 0);
> +}
> +
> +/****************************** TPM1.2 specific *******************************/
> +#define TPM_ORD_Extend              0x00000014
> +#define TPM_ORD_SHA1Start           0x000000A0
> +#define TPM_ORD_SHA1Update          0x000000A1
> +#define TPM_ORD_SHA1CompleteExtend  0x000000A3
> +
> +#define TPM_TAG_RQU_COMMAND         0x00C1
> +#define TPM_TAG_RSP_COMMAND         0x00C4

I am not sure what the long term goal for a TPM driver in Xen might be 
but my suggestion is to lay out the driver more cleanly up front. Split 
the specification defined things (e.g. these things and other from TCG 
etc) from the driver implementation specific definitions and put them in 
separate headers. There is little enough core code now that just putting 
it all in tpm.c seems fine. Just my $0.02...

Thanks,
Ross

> +
> +/* All fields of following structs are big endian. */
> +struct tpm_cmd_hdr {
> +    uint16_t    tag;
> +    uint32_t    paramSize;
> +    uint32_t    ordinal;
> +} __packed;
> +
> +struct tpm_rsp_hdr {
> +    uint16_t    tag;
> +    uint32_t    paramSize;
> +    uint32_t    returnCode;
> +} __packed;
> +
> +struct extend_cmd {
> +    struct tpm_cmd_hdr h;
> +    uint32_t pcrNum;
> +    uint8_t inDigest[SHA1_DIGEST_SIZE];
> +} __packed;
> +
> +struct extend_rsp {
> +    struct tpm_rsp_hdr h;
> +    uint8_t outDigest[SHA1_DIGEST_SIZE];
> +} __packed;
> +
> +struct sha1_start_cmd {
> +    struct tpm_cmd_hdr h;
> +} __packed;
> +
> +struct sha1_start_rsp {
> +    struct tpm_rsp_hdr h;
> +    uint32_t maxNumBytes;
> +} __packed;
> +
> +struct sha1_update_cmd {
> +    struct tpm_cmd_hdr h;
> +    uint32_t numBytes;          /* Must be a multiple of 64 */
> +    uint8_t hashData[];
> +} __packed;
> +
> +struct sha1_update_rsp {
> +    struct tpm_rsp_hdr h;
> +} __packed;
> +
> +struct sha1_complete_extend_cmd {
> +    struct tpm_cmd_hdr h;
> +    uint32_t pcrNum;
> +    uint32_t hashDataSize;      /* 0-64, inclusive */
> +    uint8_t hashData[];
> +} __packed;
> +
> +struct sha1_complete_extend_rsp {
> +    struct tpm_rsp_hdr h;
> +    uint8_t hashValue[SHA1_DIGEST_SIZE];
> +    uint8_t outDigest[SHA1_DIGEST_SIZE];
> +} __packed;
> +
> +struct TPM12_PCREvent {
> +    uint32_t PCRIndex;
> +    uint32_t Type;
> +    uint8_t Digest[SHA1_DIGEST_SIZE];
> +    uint32_t Size;
> +    uint8_t Data[];
> +};
> +
> +struct txt_ev_log_container_12 {
> +    char        Signature[20];      /* "TXT Event Container", null-terminated */
> +    uint8_t     Reserved[12];
> +    uint8_t     ContainerVerMajor;
> +    uint8_t     ContainerVerMinor;
> +    uint8_t     PCREventVerMajor;
> +    uint8_t     PCREventVerMinor;
> +    uint32_t    ContainerSize;      /* Allocated size */
> +    uint32_t    PCREventsOffset;
> +    uint32_t    NextEventOffset;
> +    struct TPM12_PCREvent   PCREvents[];
> +};
> +
> +#ifdef __EARLY_SLAUNCH__
> +/*
> + * TPM1.2 is required to support commands of up to 1101 bytes, vendors rarely
> + * go above that. Limit maximum size of block of data to be hashed to 1024.
> + */
> +#define MAX_HASH_BLOCK      1024
> +#define CMD_RSP_BUF_SIZE    (sizeof(struct sha1_update_cmd) + MAX_HASH_BLOCK)
> +
> +union cmd_rsp {
> +    struct sha1_start_cmd start_c;
> +    struct sha1_start_rsp start_r;
> +    struct sha1_update_cmd update_c;
> +    struct sha1_update_rsp update_r;
> +    struct sha1_complete_extend_cmd finish_c;
> +    struct sha1_complete_extend_rsp finish_r;
> +    uint8_t buf[CMD_RSP_BUF_SIZE];
> +};
> +
> +/* Returns true on success. */
> +static bool tpm12_hash_extend(unsigned loc, const uint8_t *buf, unsigned size,
> +                              unsigned pcr, uint8_t *out_digest)
> +{
> +    union cmd_rsp cmd_rsp;
> +    unsigned max_bytes = MAX_HASH_BLOCK;
> +    unsigned o_size = sizeof(cmd_rsp);
> +    bool success = false;
> +
> +    request_locality(loc);
> +
> +    cmd_rsp.start_c = (struct sha1_start_cmd) {
> +        .h.tag = swap16(TPM_TAG_RQU_COMMAND),
> +        .h.paramSize = swap32(sizeof(struct sha1_start_cmd)),
> +        .h.ordinal = swap32(TPM_ORD_SHA1Start),
> +    };
> +
> +    send_cmd(loc, cmd_rsp.buf, sizeof(struct sha1_start_cmd), &o_size);
> +    if ( o_size < sizeof(struct sha1_start_rsp) )
> +        goto error;
> +
> +    if ( max_bytes > swap32(cmd_rsp.start_r.maxNumBytes) )
> +        max_bytes = swap32(cmd_rsp.start_r.maxNumBytes);
> +
> +    while ( size > 64 )
> +    {
> +        if ( size < max_bytes )
> +            max_bytes = size & ~(64 - 1);
> +
> +        o_size = sizeof(cmd_rsp);
> +
> +        cmd_rsp.update_c = (struct sha1_update_cmd){
> +            .h.tag = swap16(TPM_TAG_RQU_COMMAND),
> +            .h.paramSize = swap32(sizeof(struct sha1_update_cmd) + max_bytes),
> +            .h.ordinal = swap32(TPM_ORD_SHA1Update),
> +            .numBytes = swap32(max_bytes),
> +        };
> +        memcpy(cmd_rsp.update_c.hashData, buf, max_bytes);
> +
> +        send_cmd(loc, cmd_rsp.buf, sizeof(struct sha1_update_cmd) + max_bytes,
> +                 &o_size);
> +        if ( o_size < sizeof(struct sha1_update_rsp) )
> +            goto error;
> +
> +        size -= max_bytes;
> +        buf += max_bytes;
> +    }
> +
> +    o_size = sizeof(cmd_rsp);
> +
> +    cmd_rsp.finish_c = (struct sha1_complete_extend_cmd) {
> +        .h.tag = swap16(TPM_TAG_RQU_COMMAND),
> +        .h.paramSize = swap32(sizeof(struct sha1_complete_extend_cmd) + size),
> +        .h.ordinal = swap32(TPM_ORD_SHA1CompleteExtend),
> +        .pcrNum = swap32(pcr),
> +        .hashDataSize = swap32(size),
> +    };
> +    memcpy(cmd_rsp.finish_c.hashData, buf, size);
> +
> +    send_cmd(loc, cmd_rsp.buf, sizeof(struct sha1_complete_extend_cmd) + size,
> +             &o_size);
> +    if ( o_size < sizeof(struct sha1_complete_extend_rsp) )
> +        goto error;
> +
> +    if ( out_digest != NULL )
> +        memcpy(out_digest, cmd_rsp.finish_r.hashValue, SHA1_DIGEST_SIZE);
> +
> +    success = true;
> +
> +error:
> +    relinquish_locality(loc);
> +    return success;
> +}
> +
> +#else
> +
> +union cmd_rsp {
> +    struct extend_cmd extend_c;
> +    struct extend_rsp extend_r;
> +};
> +
> +/* Returns true on success. */
> +static bool tpm12_hash_extend(unsigned loc, const uint8_t *buf, unsigned size,
> +                              unsigned pcr, uint8_t *out_digest)
> +{
> +    union cmd_rsp cmd_rsp;
> +    unsigned o_size = sizeof(cmd_rsp);
> +
> +    sha1_hash(out_digest, buf, size);
> +
> +    request_locality(loc);
> +
> +    cmd_rsp.extend_c = (struct extend_cmd) {
> +        .h.tag = swap16(TPM_TAG_RQU_COMMAND),
> +        .h.paramSize = swap32(sizeof(struct extend_cmd)),
> +        .h.ordinal = swap32(TPM_ORD_Extend),
> +        .pcrNum = swap32(pcr),
> +    };
> +
> +    memcpy(cmd_rsp.extend_c.inDigest, out_digest, SHA1_DIGEST_SIZE);
> +
> +    send_cmd(loc, (uint8_t *)&cmd_rsp, sizeof(struct extend_cmd), &o_size);
> +
> +    relinquish_locality(loc);
> +
> +    return (o_size >= sizeof(struct extend_rsp));
> +}
> +
> +#endif /* __EARLY_SLAUNCH__ */
> +
> +static void *create_log_event12(struct txt_ev_log_container_12 *evt_log,
> +                                uint32_t evt_log_size, uint32_t pcr,
> +                                uint32_t type, const uint8_t *data,
> +                                unsigned data_size)
> +{
> +    struct TPM12_PCREvent *new_entry;
> +
> +    new_entry = (void *)(((uint8_t *)evt_log) + evt_log->NextEventOffset);
> +
> +    /*
> +     * Check if there is enough space left for new entry.
> +     * Note: it is possible to introduce a gap in event log if entry with big
> +     * data_size is followed by another entry with smaller data. Maybe we should
> +     * cap the event log size in such case?
> +     */
> +    if ( evt_log->NextEventOffset + sizeof(struct TPM12_PCREvent) + data_size
> +         > evt_log_size )
> +        return NULL;
> +
> +    evt_log->NextEventOffset += sizeof(struct TPM12_PCREvent) + data_size;
> +
> +    new_entry->PCRIndex = pcr;
> +    new_entry->Type = type;
> +    new_entry->Size = data_size;
> +
> +    if ( data && data_size > 0 )
> +        memcpy(new_entry->Data, data, data_size);
> +
> +    return new_entry->Digest;
> +}
> +
> +/************************** end of TPM1.2 specific ****************************/
> +
> +void tpm_hash_extend(unsigned loc, unsigned pcr, const uint8_t *buf,
> +                     unsigned size, uint32_t type, const uint8_t *log_data,
> +                     unsigned log_data_size)
> +{
> +    void *evt_log_addr;
> +    uint32_t evt_log_size;
> +
> +    find_evt_log(slaunch_get_slrt(), &evt_log_addr, &evt_log_size);
> +    evt_log_addr = __va((uintptr_t)evt_log_addr);
> +
> +    if ( is_tpm12() )
> +    {
> +        uint8_t sha1_digest[SHA1_DIGEST_SIZE];
> +
> +        struct txt_ev_log_container_12 *evt_log = evt_log_addr;
> +        void *entry_digest = create_log_event12(evt_log, evt_log_size, pcr,
> +                                                type, log_data, log_data_size);
> +
> +        /* We still need to write computed hash somewhere. */
> +        if ( entry_digest == NULL )
> +            entry_digest = sha1_digest;
> +
> +        if ( !tpm12_hash_extend(loc, buf, size, pcr, entry_digest) )
> +        {
> +#ifndef __EARLY_SLAUNCH__
> +            printk(XENLOG_ERR "Extending PCR%u failed\n", pcr);
> +#endif
> +        }
> +    }
> +}
> +
> +#ifdef __EARLY_SLAUNCH__
> +void asmlinkage tpm_extend_mbi(uint32_t *mbi, uint32_t slrt_pa)
> +{
> +    /* Need this to implement slaunch_get_slrt() for early TPM code. */
> +    slrt_location = slrt_pa;
> +
> +    /* MBI starts with uint32_t total_size. */
> +    tpm_hash_extend(DRTM_LOC, DRTM_DATA_PCR, (uint8_t *)mbi, *mbi,
> +                    DLE_EVTYPE_SLAUNCH, NULL, 0);
> +}
> +#endif



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 18:03:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 18:03:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007352.1386668 (Exim 4.92)
	(envelope-from )
	id 1uNEw1-0001yb-C7; Thu, 05 Jun 2025 18:03:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007352.1386668; Thu, 05 Jun 2025 18:03: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 1uNEw1-0001yU-8v; Thu, 05 Jun 2025 18:03:25 +0000
Received: by outflank-mailman (input) for mailman id 1007352;
 Thu, 05 Jun 2025 18:03: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 1uNEvz-0001yO-RQ
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 18:03:23 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20616.outbound.protection.outlook.com
 [2a01:111:f403:2408::616])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5b7a97cb-4237-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 20:03:18 +0200 (CEST)
Received: from SA9PR13CA0030.namprd13.prod.outlook.com (2603:10b6:806:21::35)
 by DS4PR12MB9682.namprd12.prod.outlook.com (2603:10b6:8:27f::11) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Thu, 5 Jun
 2025 18:03:15 +0000
Received: from SN1PEPF00036F3C.namprd05.prod.outlook.com
 (2603:10b6:806:21:cafe::cb) by SA9PR13CA0030.outlook.office365.com
 (2603:10b6:806:21::35) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Thu,
 5 Jun 2025 18:03:14 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF00036F3C.mail.protection.outlook.com (10.167.248.20) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Thu, 5 Jun 2025 18:03:13 +0000
Received: from localhost (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, 5 Jun
 2025 13:03:11 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5b7a97cb-4237-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=qdYdMgr++/P9ntTJ7gqyngj3T0QT3fC5a3dqpyF5VzxSjaPypChMS8+v/1VurHN1Wj7qAwUgq78psjwLYH4i4xfPlsE8y7Ni58JvLKDHOorUwHq6+LFJG2C50JFdVSH7OhSBeYfET/iK/F6njvyrWnUdRfipKhYTPnutNlgLH7yeMxAmySK96Js8Me/xqx+Yh6ImJXJtiI6V7a55rKv9owoS3iRdDfUFa7WfMmLp2wWt7i+YiXnIWTly0WmdkYjQenHPk5W+5PKC2PGoukqMVNhEhTKGnrhJ+L4EGuqibZx0p1kCW5Duz8ML0yMEmK66SVjWAZ1vPHD6wPRxJHBO8g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=LQaIIJRniKD+GuB6JGARqRaiARUWmfX5G84pNUynaSI=;
 b=HTByM6F+Rxx9WM2ruGkk/L8L0Lj8gMwXVFF2lNWIuwErLBUpLIdp0uxiilmw9CNvWDgT2SNchznl8it7oMVaTHFvxrWd7O24RS5bm6VRXbR4kVY/DHwIq7OkyMldFt6U58M8xBDQJJz/8GN3JO4JdLFmjRZ33XvYDRpL4N75CifJqoTLbRUHBtNIS4k3xUGuTVfbQQ41WufuDytnPhK5hLBMMHBeex5ttfjZxEWgMhl0vOzlPIP7jlsNc2Xya78IIagglt3YvDaB8fS3eYocH/v32C3xF67JTpOFBmkb8O4xrf+3gKyAo24xeyFL6e2yNY4IjiE7X36QxCv5gyR7Lg==
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=LQaIIJRniKD+GuB6JGARqRaiARUWmfX5G84pNUynaSI=;
 b=Dz//smGXtMLWn13XU7F4sEJMbfUMtyYtzWEIlYMt8C5ym5yRTeIjBhQodDa+1SCgWkfQikJc0pfGgE1j/OzLl6tuDQ3PKSl+iI0BCdkq7SB7KMKK0YrDVXW4zo3fv7U+lcfxL4O37ICQMs3vhn4dFZw8P/CXXg45e/Csm46QRww=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 5 Jun 2025 20:03:10 +0200
Message-ID: 
Subject: Re: [PATCH 12/19] xen/dt: Move bootfdt functions to xen/bootfdt.h
From: Alejandro Vallejo 
To: "Daniel P. Smith" ,
	
CC: Stefano Stabellini , Julien Grall
	, Bertrand Marquis , Michal Orzel
	, Volodymyr Babchuk 
X-Mailer: aerc 0.20.1
References: 
 <20250530120242.39398-1-agarciav@amd.com>
 <20250530120242.39398-13-agarciav@amd.com>
 
In-Reply-To: 
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: SN1PEPF00036F3C:EE_|DS4PR12MB9682:EE_
X-MS-Office365-Filtering-Correlation-Id: 06be062c-6fa7-443c-c35e-08dda45b3d71
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:
	=?utf-8?B?MmUxUWVjWTN0MDhyYys0MlA1aW1NOGJSdkgyTENvbHVKMjI2ako4d0xEelZt?=
 =?utf-8?B?R05LVWFqK2FiMUZWaWdYOTN5M3dWUWxKbHN5cU9tZ0YyellDMWJZb1NmeEx6?=
 =?utf-8?B?MFo4UmM5Mll5bEJYUXdvTzBNWW0wMFRla3ZhUVJNNE1FOU8yNWt5Wk42eC9L?=
 =?utf-8?B?dUYvM2tNd3QyREFGYXBtckM2WnE1bHk2eGdzNXh4TVZrNVEyaEdiTk43Z1Rv?=
 =?utf-8?B?UjR5R0RnZUVSM3RFL3IwTkUzYUVvSWJmYTRLK1R6QmRrWWk3QkNHT0YydzIv?=
 =?utf-8?B?UFNGdkdDaEhxdGhhYmxKRDFXMndUYUxLYWkxWGNBdDUvdmwyc1BJWVZ0dmlC?=
 =?utf-8?B?alh4ZHROMFNpYitKeHRHM0t4Nm1USFQyTll5OTY1R01zbUtMVWllZmVEODhy?=
 =?utf-8?B?SHh4WnFJT1JQQVhLUWZJNDladjd6UTd0aXFkcGl5eEc4bFd2MGVQYVU4YWs1?=
 =?utf-8?B?eWU3YWo1TDFlRWpwdTZjQlZJZjU5elBCci9TdkVTSDQwb2NZdlpkaGIzYTZU?=
 =?utf-8?B?MFJTbHRUTFJwWmRqeFRkNWNLL3JDTlVIOHFEWHYyd1VoNXlZVFdxVkRBdkx0?=
 =?utf-8?B?Mi81aFdBdi81cFhnM3I3QWFuQ3ZhTkp2ZDY4WUxneDJKWUM5bDlzZ3lZQWh2?=
 =?utf-8?B?WnRLelNJNzIwZTJKLzNnSEJ1MzVabnozMzhtNUZKaE5IZkxCZTdNUXUrRjVy?=
 =?utf-8?B?bHdta0Q3M0daWTQrTzVFTEFFZ25KdzU1Z3ZySXJqS0JldnZoK2lCYlBGM2pD?=
 =?utf-8?B?b0NoUFZUT0RYZXVJNjRFZmp5WXA0OVhjTzNTY1J4S2NIcEhIVHJOcXExbjk3?=
 =?utf-8?B?SzBPanBydmg1UkR3Nk9yTjcxRXdZZmh0aDNLREx3a3ZQODdHNTZyYkF2ejFu?=
 =?utf-8?B?UllQaVo5YUJTYnNVTnNSc01Fb2lwcER2N2pWNktpb2diMis1bkNHckhOelVV?=
 =?utf-8?B?MCsrWnNLNk5nU3J3djJERU1lcHJNU1M2cDlVL0ZiRmNmcDVUZERjcUQzV0FG?=
 =?utf-8?B?dXVsSlhuLzRIcEdlZ3JtNndLaWdjd0hraEJYOG9aODhIaEhuUnNWcFFSTlQv?=
 =?utf-8?B?MUtDTVlGcGgzWkJLZHFqeGExSjlpRDcrQUx3OHQ3anh3REp1OXRtYVpnT0dW?=
 =?utf-8?B?ZUpEeGZDOWdtdUpzVDdMcnF2U1UrempUVkdnMzVVTHdHMkdtN0h0ZkFZa2kr?=
 =?utf-8?B?Qjd0Wm1iNWkrVUhzWGh0cjV0aW1iWGRHb2JhT1A5RTgraHlVTTBSVWJxNlFy?=
 =?utf-8?B?VzFUL1VLNGt3TTM4YW5YR1ZMRUk2U0NpNzVPelkyZVpMMWtoZW5qQmN2WVRK?=
 =?utf-8?B?MU1pbnUvcVlZTkNITjR0MU9tT1QwL0QvNllCT2F3d3VjaWs4anIyN0c5L2w2?=
 =?utf-8?B?MEhKMzN2U3BGTllQU2hQMjYyVnRGaStrbGRWQXVBZGhTZVoybXNFMWY0WHFx?=
 =?utf-8?B?bUhhZFpKbzNpUk4zZDlhOXhXVm9GYW4xd2NPUWhjQlF6Wk5GeUlrNUYybnpY?=
 =?utf-8?B?RG5DbzcrUjhycE1zQWYyd3VJcnJrTUszcm0zSjJaL1pRdVNpOGZ0SWszZllO?=
 =?utf-8?B?QU05M0lWZEdEYUxibEM5MFBmM2svNXR3eVM2KzNTYW54Z3VEWjZ6aExhVWFx?=
 =?utf-8?B?VXhiQTRQWnFkY0hNWEZ5Y1FUdTlIcXZkUmFqY29BWER4a0FLbWhKU0YvUGJW?=
 =?utf-8?B?WDFlWlFWMFhWMGpOVDUxaTJOTndRY0VCalNYaFM4b3JMR3FYbks3RHAwb201?=
 =?utf-8?B?QWszeU1FR0l1NVVPRXh2Ky9ZNXI1TDcySnpYUCszOURVc1hmN2xJaHhsQWs2?=
 =?utf-8?B?Vmd3NFdVekdnNVNKZTVZYTJBU296ajhGVTRSSWpIZjdxMWRkWHp6WWJacnpE?=
 =?utf-8?B?SGQwWjBnTjV4c3RReTRWMXhtN3Q5Tis2WFhOTDVWYzB3WkpGa2ZzQzlLZE9k?=
 =?utf-8?B?MWREcDVYUVorMlBtYlJPUUdWOW5vamhpcm96ZkQvRVUyRWs4blJmNkpBbDNE?=
 =?utf-8?B?dFd5M2hvOEMyeHpnTWQwQmJoZWdlN0QvbTgybGpSU0lDQU9rcDh4VlF2N0Zh?=
 =?utf-8?Q?oayNkM?=
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: 05 Jun 2025 18:03:13.5590
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 06be062c-6fa7-443c-c35e-08dda45b3d71
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:
	SN1PEPF00036F3C.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS4PR12MB9682

On Mon Jun 2, 2025 at 10:25 PM CEST, Daniel P. Smith wrote:
>> +/* Helper to read a big number; size is in cells (not bytes) */
>> +static inline u64 dt_read_number(const __be32 *cell, int size)
>> +{
>> +    u64 r =3D 0;
>> +
>> +    while ( size-- )
>> +        r =3D (r << 32) | be32_to_cpu(*(cell++));
>> +    return r;
>> +}
>
> I know you are trying to keep code changes to a minimal but let's not=20
> allow poorly constructed logic like this to continue to persist. This is=
=20
> an unbounded, arbitrary read function that is feed parameters via=20
> externally input. The DT spec declares only two number types for a=20
> property, u32 and u64, see Table 2.3 in Section 2.2.4. There is no=20
> reason to have an unbounded, arbitrary read function lying around=20
> waiting to be leveraged in exploitation.

Seeing how it's a big lump of code motion, I really don't want to play game=
s
or I will myself lose track of what I changed and what I didn't.

While I agree it should probably be a switch statement (or factored away
altogether), this isn't the place for it.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 18:04:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 18:04:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007356.1386678 (Exim 4.92)
	(envelope-from )
	id 1uNEwv-0002Rv-LT; Thu, 05 Jun 2025 18:04:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007356.1386678; Thu, 05 Jun 2025 18: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 1uNEwv-0002Ro-Hx; Thu, 05 Jun 2025 18:04:21 +0000
Received: by outflank-mailman (input) for mailman id 1007356;
 Thu, 05 Jun 2025 18:04: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 1uNEwt-0002Pu-LU
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 18:04:19 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20618.outbound.protection.outlook.com
 [2a01:111:f403:2408::618])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7d131c11-4237-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 20:04:15 +0200 (CEST)
Received: from SN7P222CA0005.NAMP222.PROD.OUTLOOK.COM (2603:10b6:806:124::22)
 by SJ2PR12MB8882.namprd12.prod.outlook.com (2603:10b6:a03:537::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.27; Thu, 5 Jun
 2025 18:04:09 +0000
Received: from SN1PEPF00036F3F.namprd05.prod.outlook.com
 (2603:10b6:806:124:cafe::96) by SN7P222CA0005.outlook.office365.com
 (2603:10b6:806:124::22) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.34 via Frontend Transport; Thu,
 5 Jun 2025 18:04:09 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF00036F3F.mail.protection.outlook.com (10.167.248.23) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Thu, 5 Jun 2025 18:04:09 +0000
Received: from localhost (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, 5 Jun
 2025 13:04:06 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7d131c11-4237-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=hMeICOW18kgXJUNVlIwDenzVC12DzqsPHEqdiT1Smb9EFKDebNuy0imIdxfjUjbYnomOUptJCg8f+2c6Jjl78qE8TzjL/6HFOoRd/NWPjqITfwbCTRQbJmviD0UHTegzG7AjdSb+lzjXn6IVB5DQXnNvauT7ggyi/E38pD/cVVaJgcXdxeIZ1PJDI/VuRNe0iPTxAE6M0ZQLavZGBFhrg71OqxugCq8f+SelzdNUw34VTBtJoXQGEZe0BBczZCBsuGXnioRHW/xjsouZg1GH1sAbF8p4zxRxzZyWCm+lP4mt2nySp/bPEbJTsqY5TRBTuDMcSBrz7W4eMKl566bY5g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=EiLnOrisgAz1u9VniU4nunJ84BlQ/KNE/r2YdbvGLF0=;
 b=Ng6GMQBrwloB4tWCmVSSPUVtfT+xkzKoBqeX+Lu9d2oLDD2viXdKkstEVm+a6ECPkJinTNfjfiohet6xiWgUTrKwD94nr1TMG2m9KKDfQWW7xgrDfAoKUI0IGs3FyIiqKqRfu8qSdlGgmG57SjrMKR7xgvB9vmEAK8gAEav34EIjJUykceB5w7KSxKG8xfbR8i9tVHN7vRuuWZ+8uIy/Auim8GBzRlYV14od8qMak/zcUzaDTv+rVWiWEDmooi0jl96iXMALPusuypWwSd92z5UJBED/VRrtjGZMQqXfsU3TFGPiJj7bqG6suJ2DCm1vcLKjJbG/1Tt9KMGJ+7Mf2A==
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=EiLnOrisgAz1u9VniU4nunJ84BlQ/KNE/r2YdbvGLF0=;
 b=jfKCXbAWVoVoO5hzvedQ2Rlg7g6fICTZFkC2oL/+w35oZ4k92c2vH4yuqK3UxaTYVVYKS46nXCbZSFuPwV389bmy8YROODLaLSwBfpkrNCBaofSok5d1mqdkg0FUWxZjsLPqPaEDGd5pelHzkhpVkvumJ8kbZGbDhjhFANfpf0A=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 5 Jun 2025 20:04:04 +0200
Message-ID: 
To: Stefano Stabellini 
CC: , Julien Grall , "Bertrand
 Marquis" , Michal Orzel ,
	Volodymyr Babchuk , Andrew Cooper
	, Anthony PERARD , "Jan
 Beulich" , =?utf-8?q?Roger_Pau_Monn=C3=A9?=
	, Alistair Francis , "Bob
 Eshleman" , Connor Davis ,
	Oleksii Kurochko , "Daniel P. Smith"
	
Subject: Re: [PATCH 13/19] xen/dt: Move bootinfo functions to a new
 bootinfo.h
From: Alejandro Vallejo 
X-Mailer: aerc 0.20.1
References: 
 <20250530120242.39398-1-agarciav@amd.com>
 <20250530120242.39398-14-agarciav@amd.com>
 
In-Reply-To: 
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: SN1PEPF00036F3F:EE_|SJ2PR12MB8882:EE_
X-MS-Office365-Filtering-Correlation-Id: 5b934531-4681-4bb8-9e07-08dda45b5e8b
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|36860700013|7416014|82310400026|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?RGRjaCtLUDMyOTlnSjdQN3BWTS9pdWFuVVE5YThTNkZXRUtBeFhuaUNDNW1s?=
 =?utf-8?B?ZldxRVZuSlFrYlhMVGZlUlErM3NEQW9TcHRDQkVzdFMxbkpEZEJMcnJrTW5h?=
 =?utf-8?B?MlovM0VRdmc3aTJlSkxNLzZJekJyMGtmQ2M2KytVOWVtR0kxRTZ5bENkZFlN?=
 =?utf-8?B?bEFCNGxLanhrMGNMeElzMmRqVjJwS3d6ekVKYkFyTWZHL1kvSVlGcDZvYmFr?=
 =?utf-8?B?VzR2WDlNYS9uMjVLOGV0V2tqS3djR0NvNzg0SjJDdVlWR1lCUmExSk8wMVR1?=
 =?utf-8?B?VUJEZGpLV0RZZTQ3SHhacUx6UWRRNlpxcFMrUThvbml6SFRoYjM3QjlscnQv?=
 =?utf-8?B?bk90bzQ1elZPQXkrVHY5Y1ZsRlF3REN3NmZTZDRLOWhrMGd1US9ZZGJYSkV3?=
 =?utf-8?B?UlJ6K2lwU1NTd2FYeTRxd0dRVlI2VnZ6eEkxT1h4alVrRmpnbi93c0tQRU1F?=
 =?utf-8?B?eUxFOGhQbXViVVdjdDE2UnpiSi9PdTMrWUJRdEhSbWd0Vk94a3l6NUZpTXhh?=
 =?utf-8?B?R3J2d2sySFlabk8vaUJacm5KZ0N4KzNOQlloWU1GRUc1QmJFWlltN0grWnk0?=
 =?utf-8?B?b1hDbjRsR3VmeTlXWXFPRWlKelNodWU1ZHlVcW5QZk5TSFpqeFMzS2dDeEpQ?=
 =?utf-8?B?S3ZPMHhlVFNXRnk0dkEwbG9zbS8rQUNVN2lvdWQ1Y0pSalNPTHkwOHNISFph?=
 =?utf-8?B?UHhtWnBiMzF6b2h0UkdwRXkxdXB4YTRqWkFkOHV1clJSbzVsSStkY3NXbDlS?=
 =?utf-8?B?aG93cmhhbU0yMndMTGtMWkVreG90WDBCYXpFVzh4VFZKZU1tOStLNTkxMkQx?=
 =?utf-8?B?cThjcHVXMENNWGlLWjNFZGs2YkxrMFVvV3B5eTFZelloZUJJemI3K3AyNlFJ?=
 =?utf-8?B?eWxFaEhWQXhRaVZCVVZRZVBPTnJ2bDhsc3gxeGtUZ21xMkVrbXhGNGh1b0Jq?=
 =?utf-8?B?dzZZaVA3ZExHQ3RLb0NvK1l1Q1pvMWNFQ0FBWi9SbVVtTzRucU4weEI0LzMy?=
 =?utf-8?B?U0NhT2w5Rzc5QzRZNFVOTUpYa1Rmb3R4TVhTRU9WUjVaUGk1NW01T3Z3Lzcv?=
 =?utf-8?B?VnU3bE1rR2pxRExhTVJZSElndG83aGJ0VDZNN2JxeFpuOFE4THB6dC8xbnhn?=
 =?utf-8?B?My81MUhTeWlXU21IRUZidFBpZ29pRk51VGVTc1Mvc0FIQVN3MW0vYWtoUTZB?=
 =?utf-8?B?MjVrbWVHR3RpaE5CenlwaUFrdWxUOXJ3MzRISHFhZGNsQkFLanc2emI5eE13?=
 =?utf-8?B?b2hLWVNINTd0d2tuNWhFOVhhaCtkdEVUM0JyWkZ6ZmNSZGhkb0NMT29pTEln?=
 =?utf-8?B?Nm94ZFBTWTEwTlRUd0k2d0xsRjg1WHlCTnZtY3JlZmZaS1BwZnp4YXhSekVa?=
 =?utf-8?B?L1kxK0JDMnhKOUhVRHFjR0orK0dpM25JenVlZVROU016Wjc4a0oyeHlxZGNy?=
 =?utf-8?B?TGxpcVRqQ1dIQzhKejU3dHB5Z1BEdWgwQldqTC9yUTRYOEVsMHRxNVZMeU1P?=
 =?utf-8?B?dGlVVU9EUGNWNGp1Nkl6cGFDeHM3RjNNdm55R244NTFIdnIvSHNweDJ6MkY0?=
 =?utf-8?B?NnE3SzE2eXlUOXliQ0pndTBLWnp1ZytBcTNybkoxY3gzcGkrZHljL3J1QUFn?=
 =?utf-8?B?b1QwLzRkdGh2ZDQvSTZ2Tmx5NzVjVFNLN0ppSHpneFJDVE1TUjliNHVIOTNM?=
 =?utf-8?B?dDEyVzJSNDVqdURWTXk1MDJSN243djAzeVhYeGk0RHBBV1dYellhbjliajdN?=
 =?utf-8?B?NFFKU2FKY1lkWnRVV1NUZDhNSWtlSUJzdTZiZy90cUJGVG8wbVFENWljdlB1?=
 =?utf-8?B?ZVM0eTVlSWNPN0pla2UvTDV2V3dXSGJaeU9RLzdJQlZtNTUzNDlQWkxyUlFw?=
 =?utf-8?B?M3EzekRKa09aTTQwYzBsNTIzbWl6dVdIQ0g2UHdCTlZ6L1d4WmNrc1BFVGha?=
 =?utf-8?B?Vkx2cjlycmVibG05UEMxN0t5VFFzOHBBY3R1bVFzNVBMeGl4N0FLQjVCL3ls?=
 =?utf-8?B?NHcxdlJoTWpXaC9nVnQvZnNuK0hJWFBMWjhjN2hGMVE4Qi9WeUhtZlgvajJn?=
 =?utf-8?Q?R5WGAo?=
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)(7416014)(82310400026)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jun 2025 18:04:09.0934
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5b934531-4681-4bb8-9e07-08dda45b5e8b
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:
	SN1PEPF00036F3F.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB8882

On Sat May 31, 2025 at 3:42 AM CEST, Stefano Stabellini wrote:
> On Fri, 30 May 2025, Alejandro Vallejo wrote:
>> Part of an unpicking process to extract bootfdt contents independent of
>> bootinfo to a separate file for x86 to take.
>>=20
>> With this, bootfdt.h can be cleanly included from x86. A later patch
>> extracts the definitions so the functions may be called too.
>>=20
>> Not a functional change.
>>=20
>> Signed-off-by: Alejandro Vallejo 
>> ---
>>  xen/arch/arm/domain_build.c             |   1 +
>>  xen/arch/arm/mmu/mm.c                   |   1 +
>>  xen/arch/riscv/mm.c                     |   2 +-
>>  xen/arch/riscv/setup.c                  |   2 +-
>>  xen/common/device-tree/bootfdt.c        |   1 +
>>  xen/common/device-tree/bootinfo.c       |   2 +-
>>  xen/common/device-tree/dom0less-build.c |   2 +-
>>  xen/common/device-tree/domain-build.c   |   2 +-
>>  xen/common/device-tree/kernel.c         |   2 +-
>>  xen/include/xen/bootfdt.h               | 206 -----------------------
>>  xen/include/xen/bootinfo.h              | 212 ++++++++++++++++++++++++
>>  xen/include/xen/device_tree.h           |   2 +-
>>  xen/include/xen/fdt-domain-build.h      |   2 +-
>>  xen/include/xen/fdt-kernel.h            |   2 +-
>>  14 files changed, 224 insertions(+), 215 deletions(-)
>>  create mode 100644 xen/include/xen/bootinfo.h
>>=20
>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> index 11cc03e5db..c53da76682 100644
>> --- a/xen/arch/arm/domain_build.c
>> +++ b/xen/arch/arm/domain_build.c
>> @@ -1,5 +1,6 @@
>>  /* SPDX-License-Identifier: GPL-2.0-only */
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> diff --git a/xen/arch/arm/mmu/mm.c b/xen/arch/arm/mmu/mm.c
>> index 9c50479c63..77f82757bb 100644
>> --- a/xen/arch/arm/mmu/mm.c
>> +++ b/xen/arch/arm/mmu/mm.c
>> @@ -1,5 +1,6 @@
>>  /* SPDX-License-Identifier: GPL-2.0-or-later */
>> =20
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
>> index d3ece9f132..040db73d00 100644
>> --- a/xen/arch/riscv/mm.c
>> +++ b/xen/arch/riscv/mm.c
>> @@ -1,6 +1,6 @@
>>  /* SPDX-License-Identifier: GPL-2.0-only */
>> =20
>> -#include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
>> index 4e416f6e44..0a2d0dc1eb 100644
>> --- a/xen/arch/riscv/setup.c
>> +++ b/xen/arch/riscv/setup.c
>> @@ -2,7 +2,7 @@
>> =20
>>  #include 
>>  #include 
>> -#include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/b=
ootfdt.c
>> index 529c91e603..fb4ac06390 100644
>> --- a/xen/common/device-tree/bootfdt.c
>> +++ b/xen/common/device-tree/bootfdt.c
>> @@ -6,6 +6,7 @@
>>   */
>> =20
>>  #include 
>
> Is this kept on purpose?

No. Should've been subsumed

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 18:11:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 18:11:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007363.1386687 (Exim 4.92)
	(envelope-from )
	id 1uNF45-0004W2-Bq; Thu, 05 Jun 2025 18:11:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007363.1386687; Thu, 05 Jun 2025 18:11: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 1uNF45-0004Vv-9D; Thu, 05 Jun 2025 18:11:45 +0000
Received: by outflank-mailman (input) for mailman id 1007363;
 Thu, 05 Jun 2025 18:11: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 1uNF43-0004Vp-30
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 18:11:43 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20613.outbound.protection.outlook.com
 [2a01:111:f403:2413::613])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8675f907-4238-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 20:11:40 +0200 (CEST)
Received: from SJ0PR13CA0103.namprd13.prod.outlook.com (2603:10b6:a03:2c5::18)
 by SJ2PR12MB9005.namprd12.prod.outlook.com (2603:10b6:a03:53d::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Thu, 5 Jun
 2025 18:11:33 +0000
Received: from SJ5PEPF000001F4.namprd05.prod.outlook.com
 (2603:10b6:a03:2c5:cafe::c5) by SJ0PR13CA0103.outlook.office365.com
 (2603:10b6:a03:2c5::18) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.8 via Frontend Transport; Thu, 5
 Jun 2025 18:11:33 +0000
Received: from SATLEXMB04.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.8792.29 via Frontend Transport; Thu, 5 Jun 2025 18:11:33 +0000
Received: from localhost (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, 5 Jun
 2025 13:11:31 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8675f907-4238-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=UY6EKDzeJ+Adj5OtlwYMavbjnL2v50vpazeC2C/eK64Kht3xfW8svOQoMdo9PmDINaKdJ483df0TbF4i3xE0zpSIR+YvEAKa7RLSgBvqHeftYpawJ4OOthKn+CH4curop1weI3m/POR+zn+UbRXvOLnOi6uyyjSqLca09NostajiRO2XJtoD2huBxkypUXyuxqfO07ExB/vsnEFBEiweDWVYfxp+REM9IKW07BAsD+8s4a4FiJVOd8XPHB8zA3ce6zjnW1fVEhchoqlfy7vFfq275H+Zhor2bJ3bLSjnr8gGeQzkEUNX8MmOhxf5hwP9tuwmrDBR0Gf6kfgpOdqNag==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=q6hEQ0Ew2urFydC8CohtLWSYByzbPs1HBrvhTlbfXdo=;
 b=KrOtF/K3XLHCgekTfMYvvJRihmJB7ihgUtHmrO/cacmo6+XrlVkh1nz58SUKnivKigJRWys6w/OGGq0xwR7SD0Hh4EmhX7yFY05C2TPJpjOjTe0khaHS7auxyLEXwqeDPFsdavsJhG+BdesOkDc+BuRdpXguLIVeL4SRFu+26Z44kU2hHSr4epP/sRer+v0+Qwy3t6mmNEcVUF/RCrHdUIMyTwsRXjf7fyBJP5vdP3BNhc9zv5Kb1bvM11w2IPp/SB9AZVbVpCu2ud4L4xwynDlkiD3j3NGaM1ASc+20omBl+w+eCeNS+Pt/u+1AUImOEf6V3o/dzRBAbCZ9dypEHA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=proton.me 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=q6hEQ0Ew2urFydC8CohtLWSYByzbPs1HBrvhTlbfXdo=;
 b=aGLBe+Htc3RWnJpecDK05vTAEV80dkF4z9y7y6n5XSJgrkZY6p7BO0gGvr40zXCiLMbdNw7rSLMX7kvx+7uPejXbbm+7NpZVDPifA5hOLZdEVj05O3S7da1CTfMECu7uHVYHnp+D8wi62xA5a0Wnn1fB379hcLTYYC7wZWzqbkY=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 5 Jun 2025 20:11:29 +0200
Message-ID: 
Subject: Re: [PATCH 15/19] xen/dt: Move bootinfo-independent helpers out of
 bootinfo-fdt.c
From: Alejandro Vallejo 
To: 
CC: , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Daniel P.
 Smith" 
X-Mailer: aerc 0.20.1
References: 
 <20250530120242.39398-1-agarciav@amd.com>
 <20250530120242.39398-16-agarciav@amd.com> 
In-Reply-To: 
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: SJ5PEPF000001F4:EE_|SJ2PR12MB9005:EE_
X-MS-Office365-Filtering-Correlation-Id: 6eca36b0-5f7a-440b-9d47-08dda45c678c
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?Y0E5dlMwT1RFcE96V3hMd2VDcCt5STRNeHkwSktwN3I4VnF4aWhJU2Y4UFQ2?=
 =?utf-8?B?UlRkRzZzTFhRb0NHUHdydWxpc0JFN2ZUM2JIcTNUL3loc2I4dGFVTVlvbjlo?=
 =?utf-8?B?SDNRdm95SktTZ3Z3NENoOStXekZUYkM2KzFLMG83S3Brdm55THdRb2IxaXhO?=
 =?utf-8?B?ODF5K2pjNC94akNWbElPVC9zbnZ3di9wQVBYWFRRY04xcUFxUmNNTC9ydXlS?=
 =?utf-8?B?SGZyQ244RDJwREprbExJYWdEZ2dlbTB5NG1iM053Yyt0Z0xsNFgvQWVVRGl4?=
 =?utf-8?B?dGRrKzk3TVFnRDFMWUxkcDMxZkJaWDRmRFFYRGpJcFZXKzc0TUtxMlNtMTZ1?=
 =?utf-8?B?dWlCaHp3YTFvU0JmMjB0NXU1RGxkaUs3RW8vSHF3ekp4VUFPL210bENaNjZw?=
 =?utf-8?B?VS9QU2Q5N1dJcVc3WU8wdmpXcSt0ZlVnMm1tdTRtSGg1VnlQL3VtS1VTNWhx?=
 =?utf-8?B?M0FxMk9TbitEVThIUVRjcnFndjBueUhSTGpVdnlsNjZMZFArZ2ltTnBKYVVS?=
 =?utf-8?B?N1BwZHA5S25wUDcveWNnbXJlZUk4OXVXMVFRaGF4SERnOFV5RGZqOEJoQzdC?=
 =?utf-8?B?ZWkyNHh5cFFkWUpIMGVuOEF1WjJXSEhHTDJYbU1ZNE5LV0M3c20wcllKRy9j?=
 =?utf-8?B?ajMrcjdGTXV0cmZUSlhXZGVBRGZvbkZ0TXVzbVpiNzc5K0VOS2V5RnZoNjBN?=
 =?utf-8?B?SXZPY3ZZUnZrQkVkOHhzK2FWY21wRm1laElObS9xcEUrdmZHc1BteHp2Q3hv?=
 =?utf-8?B?d0VJbmNBWUVSSWRMSVBkZklHb3R0SUhQNDJ0ZnRUQ2VFbUZaL09XRXQ5TmI5?=
 =?utf-8?B?Unc1MXpNV2l6bEFzSmJoTFlZU2xMRDJvT1dQZkQvWUVWTUloZm1yTnJTalF0?=
 =?utf-8?B?ZUFWUEpxRnF6WjlZVVVkWmROTCtyVDlyTXpKb2VCK2xOV1Q1UW1ZN0dFWkdZ?=
 =?utf-8?B?OEN5WWhYekVDL0ZSYmRtS282VVc3ZWw4YTlON0tlcmFKWWw3bDNWb1JGMUZG?=
 =?utf-8?B?Rjl0MVErbGhxMktibzUrbk1pM0NxTGMweGRPS2F3RmdWZTMvREtXcDVvVkQw?=
 =?utf-8?B?VFV3bkI0RTY2Z01lYXNiUGxhV1BXSWVQNXhHdU9NZDF2N1VxdnlpSFNBRHpV?=
 =?utf-8?B?cUxKZjhUdkp0bTRjVTZCSTg0c3h4dWJYMHBEOXM4bGpzYTBkajRoMm11c2x3?=
 =?utf-8?B?SkYrNG9nN0c1U2h1RHZ4dUkwUjNPWVR1bEhSazYxckdNcitvK3VBZkZTYXdL?=
 =?utf-8?B?d3krYWF3WXlSTDJ2QUVkcGZTdW85ME8wSjBJVjE0Vm1iZXRBc2xhQzhMUkF6?=
 =?utf-8?B?OTZxem03NnZmRlJua2MvQ0Vlc29tSDBnaVpGblZ6SkVIWFZ6ajlwN1JIS05R?=
 =?utf-8?B?UHVjT1ltV1krUDhGOExVeFE4eU5CeVlVMCtDMmVGUWRtL3NjU3RkSEU0OGs5?=
 =?utf-8?B?cWEwclc3SmlpV29LZlRuOXREUDI2K0pLWDBHU01HY3c3eU5FLzYvaGo2S1Uw?=
 =?utf-8?B?QXRVVWdXTWhOS210MWEyYXdPL1NpWmgrdHdtbDF0RFVqUkNkWm9HbjlrWFkr?=
 =?utf-8?B?dDVySGRGT2FKUzhRSTlya0FWaEhFd3AzS01QRzdzTXBEMzlMSmdKQzg0U0FC?=
 =?utf-8?B?bzFZWVVlZzVUaSs5QnBrVlNZTU5TWms3bjFhcmc1Nzd0VDlpS3p2VjJlRXR3?=
 =?utf-8?B?c1o1M2FXNHhlenhpVkFEVXAyZGZQcWhJRXowMGYvS2puTVB5akhWWHRQRC9I?=
 =?utf-8?B?U25CT3N0T3hzQXFWZmRraWc0cDJ5Qi9GYTdScVVCWXRRd0dROU5QVXB3M3Mx?=
 =?utf-8?B?bEhaOCtLMlJiUmdWb3lZSVZvVmU2d1dxc3ZnN09ET0JZa2NnZzh0Y3JrNDN6?=
 =?utf-8?B?NWJCejNPZjdSYmh2WjR5WVM3VUcvVjBZSG9lMWxDS3JWbFRLMzdvSVdoUTVn?=
 =?utf-8?B?SjFsR1B0cGRBZUVuS1IyYmpZeFRUSk5VamVJU0pnd2owU2Nid3lzZWFRQS83?=
 =?utf-8?B?WkdzVzgvck1lZk4xQTgwWVhZUEZ1NnFzOFFFdEI3a3M4OXVJUWRMeWZmSVEv?=
 =?utf-8?Q?XbxpJJ?=
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: 05 Jun 2025 18:11:33.6367
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 6eca36b0-5f7a-440b-9d47-08dda45c678c
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:
	SJ5PEPF000001F4.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB9005

On Sat May 31, 2025 at 2:39 AM CEST, dmkhn wrote:
> On Fri, May 30, 2025 at 02:02:23PM +0200, Alejandro Vallejo wrote:
>> ... back into bootfdt.c
>>=20
>> These will be required by x86 later on to detect modules in the early sc=
an of
>> the FDT. They are independent of bootinfo, so it's cleaner for them to e=
xist in
>> a separate file.
>>=20
>> Not a functional change.
>>=20
>> Signed-off-by: Alejandro Vallejo 
>> ---
>>  xen/common/device-tree/Makefile       |   1 +
>>  xen/common/device-tree/bootfdt.c      |  97 ++++++++++++++++++++++++
>>  xen/common/device-tree/bootinfo-fdt.c | 104 --------------------------
>>  3 files changed, 98 insertions(+), 104 deletions(-)
>>  create mode 100644 xen/common/device-tree/bootfdt.c
>>=20
>> diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Ma=
kefile
>> index bb6d5ddec5..922c5bba9b 100644
>> --- a/xen/common/device-tree/Makefile
>> +++ b/xen/common/device-tree/Makefile
>> @@ -1,3 +1,4 @@
>> +obj-y +=3D bootfdt.init.o
>>  obj-y +=3D bootinfo-fdt.init.o
>>  obj-y +=3D bootinfo.init.o
>>  obj-y +=3D device-tree.o
>> diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/b=
ootfdt.c
>> new file mode 100644
>> index 0000000000..5decf17faf
>> --- /dev/null
>> +++ b/xen/common/device-tree/bootfdt.c
>> @@ -0,0 +1,97 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +uint32_t __init device_tree_get_u32(const void *fdt, int node,
>> +                                    const char *prop_name, uint32_t dfl=
t)
>> +{
>> +    const struct fdt_property *prop;
>> +
>> +    prop =3D fdt_get_property(fdt, node, prop_name, NULL);
>> +    if ( !prop || prop->len < sizeof(u32) )
>> +        return dflt;
>> +
>> +    return fdt32_to_cpu(*(uint32_t*)prop->data);
>> +}
>> +
>> +int __init device_tree_for_each_node(const void *fdt, int node,
>> +                                     device_tree_node_func func,
>> +                                     void *data)
>> +{
>> +    /*
>> +     * We only care about relative depth increments, assume depth of
>> +     * node is 0 for simplicity.
>> +     */
>> +    int depth =3D 0;
>> +    const int first_node =3D node;
>> +    u32 address_cells[DEVICE_TREE_MAX_DEPTH];
>> +    u32 size_cells[DEVICE_TREE_MAX_DEPTH];
>> +    int ret;
>> +
>> +    do {
>> +        const char *name =3D fdt_get_name(fdt, node, NULL);
>> +        u32 as, ss;
>> +
>> +        if ( depth >=3D DEVICE_TREE_MAX_DEPTH )
>> +        {
>> +            printk("Warning: device tree node `%s' is nested too deep\n=
",
>> +                   name);
>
> Use XENLOG_WARNING?
>
>> +            continue;
>> +        }
>> +
>> +        as =3D depth > 0 ? address_cells[depth-1] : DT_ROOT_NODE_ADDR_C=
ELLS_DEFAULT;
>> +        ss =3D depth > 0 ? size_cells[depth-1] : DT_ROOT_NODE_SIZE_CELL=
S_DEFAULT;
>> +
>> +        address_cells[depth] =3D device_tree_get_u32(fdt, node,
>> +                                                   "#address-cells", as=
);
>> +        size_cells[depth] =3D device_tree_get_u32(fdt, node,
>> +                                                "#size-cells", ss);
>> +
>> +        /* skip the first node */
>> +        if ( node !=3D first_node )
>> +        {
>> +            ret =3D func(fdt, node, name, depth, as, ss, data);
>> +            if ( ret !=3D 0 )
>> +                return ret;
>> +        }
>> +
>> +        node =3D fdt_next_node(fdt, node, &depth);
>> +    } while ( node >=3D 0 && depth > 0 );
>> +
>> +    return 0;
>> +}
>> +
>> +void __init device_tree_get_reg(const __be32 **cell, uint32_t address_c=
ells,
>> +                                uint32_t size_cells, paddr_t *start,
>> +                                paddr_t *size)
>> +{
>> +    uint64_t dt_start, dt_size;
>> +
>> +    /*
>> +     * dt_next_cell will return uint64_t whereas paddr_t may not be 64-=
bit.
>> +     * Thus, there is an implicit cast from uint64_t to paddr_t.
>> +     */
>> +    dt_start =3D dt_next_cell(address_cells, cell);
>> +    dt_size =3D dt_next_cell(size_cells, cell);
>> +
>> +    if ( dt_start !=3D (paddr_t)dt_start )
>> +    {
>> +        printk("Physical address greater than max width supported\n");
>
> I would add current and expected dt_start values to the printout.
>
>> +        WARN();
>> +    }
>> +
>> +    if ( dt_size !=3D (paddr_t)dt_size )
>> +    {
>> +        printk("Physical size greater than max width supported\n");
>> +        WARN();
>> +    }
>> +
>> +    /*
>> +     * Xen will truncate the address/size if it is greater than the max=
imum
>> +     * supported width and it will give an appropriate warning.
>> +     */
>> +    *start =3D dt_start;
>> +    *size =3D dt_size;
>> +}
>> diff --git a/xen/common/device-tree/bootinfo-fdt.c b/xen/common/device-t=
ree/bootinfo-fdt.c
>> index bb5f45771e..736f877616 100644
>> --- a/xen/common/device-tree/bootinfo-fdt.c
>> +++ b/xen/common/device-tree/bootinfo-fdt.c
>> @@ -112,39 +112,6 @@ static bool __init device_tree_is_memory_node(const=
 void *fdt, int node,
>>      return true;
>>  }
>>=20
>> -void __init device_tree_get_reg(const __be32 **cell, uint32_t address_c=
ells,
>> -                                uint32_t size_cells, paddr_t *start,
>> -                                paddr_t *size)
>> -{
>> -    uint64_t dt_start, dt_size;
>> -
>> -    /*
>> -     * dt_next_cell will return uint64_t whereas paddr_t may not be 64-=
bit.
>> -     * Thus, there is an implicit cast from uint64_t to paddr_t.
>> -     */
>> -    dt_start =3D dt_next_cell(address_cells, cell);
>> -    dt_size =3D dt_next_cell(size_cells, cell);
>> -
>> -    if ( dt_start !=3D (paddr_t)dt_start )
>> -    {
>> -        printk("Physical address greater than max width supported\n");
>> -        WARN();
>> -    }
>> -
>> -    if ( dt_size !=3D (paddr_t)dt_size )
>> -    {
>> -        printk("Physical size greater than max width supported\n");
>> -        WARN();
>> -    }
>> -
>> -    /*
>> -     * Xen will truncate the address/size if it is greater than the max=
imum
>> -     * supported width and it will give an appropriate warning.
>> -     */
>> -    *start =3D dt_start;
>> -    *size =3D dt_size;
>> -}
>> -
>>  static int __init device_tree_get_meminfo(const void *fdt, int node,
>>                                            const char *prop_name,
>>                                            u32 address_cells, u32 size_c=
ells,
>> @@ -205,77 +172,6 @@ static int __init device_tree_get_meminfo(const voi=
d *fdt, int node,
>>      return 0;
>>  }
>>=20
>> -u32 __init device_tree_get_u32(const void *fdt, int node,
>> -                               const char *prop_name, u32 dflt)
>> -{
>> -    const struct fdt_property *prop;
>> -
>> -    prop =3D fdt_get_property(fdt, node, prop_name, NULL);
>> -    if ( !prop || prop->len < sizeof(u32) )
>> -        return dflt;
>> -
>> -    return fdt32_to_cpu(*(uint32_t*)prop->data);
>> -}
>> -
>> -/**
>> - * device_tree_for_each_node - iterate over all device tree sub-nodes
>> - * @fdt: flat device tree.
>> - * @node: parent node to start the search from
>> - * @func: function to call for each sub-node.
>> - * @data: data to pass to @func.
>> - *
>> - * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
>> - *
>> - * Returns 0 if all nodes were iterated over successfully.  If @func
>> - * returns a value different from 0, that value is returned immediately=
.
>> - */
>> -int __init device_tree_for_each_node(const void *fdt, int node,
>> -                                     device_tree_node_func func,
>> -                                     void *data)
>> -{
>> -    /*
>> -     * We only care about relative depth increments, assume depth of
>> -     * node is 0 for simplicity.
>> -     */
>> -    int depth =3D 0;
>> -    const int first_node =3D node;
>> -    u32 address_cells[DEVICE_TREE_MAX_DEPTH];
>> -    u32 size_cells[DEVICE_TREE_MAX_DEPTH];
>> -    int ret;
>> -
>> -    do {
>> -        const char *name =3D fdt_get_name(fdt, node, NULL);
>> -        u32 as, ss;
>> -
>> -        if ( depth >=3D DEVICE_TREE_MAX_DEPTH )
>> -        {
>> -            printk("Warning: device tree node `%s' is nested too deep\n=
",
>> -                   name);
>> -            continue;
>> -        }
>> -
>> -        as =3D depth > 0 ? address_cells[depth-1] : DT_ROOT_NODE_ADDR_C=
ELLS_DEFAULT;
>> -        ss =3D depth > 0 ? size_cells[depth-1] : DT_ROOT_NODE_SIZE_CELL=
S_DEFAULT;
>> -
>> -        address_cells[depth] =3D device_tree_get_u32(fdt, node,
>> -                                                   "#address-cells", as=
);
>> -        size_cells[depth] =3D device_tree_get_u32(fdt, node,
>> -                                                "#size-cells", ss);
>> -
>> -        /* skip the first node */
>> -        if ( node !=3D first_node )
>> -        {
>> -            ret =3D func(fdt, node, name, depth, as, ss, data);
>> -            if ( ret !=3D 0 )
>> -                return ret;
>> -        }
>> -
>> -        node =3D fdt_next_node(fdt, node, &depth);
>> -    } while ( node >=3D 0 && depth > 0 );
>> -
>> -    return 0;
>> -}
>> -
>>  static int __init process_memory_node(const void *fdt, int node,
>>                                        const char *name, int depth,
>>                                        u32 address_cells, u32 size_cells=
,
>> --
>> 2.43.0
>>=20
>>=20

As I answered to Daniel, as I'd rather not introduce functional changes in
code motion commits. I draw the line at trivial retyping (e.g: u32->uint32_=
t)

Otherwise it's just very confusing to future readers.

Cheers,
Alejandro



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 19:49:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 19:49:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007461.1386795 (Exim 4.92)
	(envelope-from )
	id 1uNGaI-0004Zk-82; Thu, 05 Jun 2025 19:49:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007461.1386795; Thu, 05 Jun 2025 19:49:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNGaI-0004Yd-2g; Thu, 05 Jun 2025 19:49:06 +0000
Received: by outflank-mailman (input) for mailman id 1007461;
 Thu, 05 Jun 2025 19:49: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 1uNGaG-0002fZ-F9
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 19:49:04 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20608.outbound.protection.outlook.com
 [2a01:111:f403:2416::608])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2091667a-4246-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 21:49:02 +0200 (CEST)
Received: from BN9PR03CA0349.namprd03.prod.outlook.com (2603:10b6:408:f6::24)
 by SA0PR12MB4384.namprd12.prod.outlook.com (2603:10b6:806:9f::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Thu, 5 Jun
 2025 19:48:56 +0000
Received: from BN2PEPF000055DA.namprd21.prod.outlook.com
 (2603:10b6:408:f6:cafe::ce) by BN9PR03CA0349.outlook.office365.com
 (2603:10b6:408:f6::24) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.27 via Frontend Transport; Thu,
 5 Jun 2025 19:48:56 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN2PEPF000055DA.mail.protection.outlook.com (10.167.245.4) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.2 via Frontend Transport; Thu, 5 Jun 2025 19:48:55 +0000
Received: from xcbagarciav01.xilinx.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, 5 Jun
 2025 14:48:53 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2091667a-4246-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=rm7lLfsnHQ6j4Z8m+IlsPwOkvG6nj+0Ifxg/ZBuDkVpxeflVYHB8YAVGpvGRIGb3WvXWiz4OdrT2js4x+yq0vZeKcqaMRk4C4aJc7dFdMlXdBoN+xlemewpNw5YJS3oGW7p/LwCZEgpLg/FYKhj+etVLH+Puvppgj6lVJGoopUmtNszNvl6dQofqLN/Gjs8R5ChimFl5OfixfdRagqBZvyYOkGsgxBwKXgJkoR9weOKwGnSEM6DDDsR84Vdi9LonvPoqbdMsoa31Ajj+691enTG5FJ7RYcxIDikdcL06YGf55rRVB0KwPeC1IBAj1JiTWMDU0NjJYSOunYcz+WOY7Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=SrlalRNV1guuVey9xud5aOv5ovVuWNN63mokafP5a1A=;
 b=ANMYrHgq6JtUQmR0CarAC30s1vMmecjogYazCMRRdCw9QpR9joTTUJ/DslgGK/QcWr51qKpenDr8btzVY/fm/ZevoGBPsMbqwIj07gu8fG0oIWmteciS2FV7HNLxSaRWCvJ23ugg+cb8lumoCXvcvachIoCLrOtyxAXi5Hdua4529EBgRDgDY/9ngGWfXWe3umbsBxDLwrtUQANK1evE76t4L7hG2Y8geVzjzhA6VdK7kJD42432Tx9FkslgYPvgbVnh6+EM9uDkr2jv3IFFAroXr/teVZTh0Qf6HWWju+HszZ6ebTxaJnLjJ87VstgORj5aByi9yRWCTVSiohYIHw==
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=SrlalRNV1guuVey9xud5aOv5ovVuWNN63mokafP5a1A=;
 b=CPMpjI6X7b5EWr68GJHmwAU8fRvu9op7JblkEchuABoqMo9Aao6EAioRh7JbjcJHqMXnBVZ8IWDvOTPmHmnE4rz9Y19+SOC7WQUC3RX7A+Doj0LHXHkB9amB/1te8y1uh+SqpvRoyPFtpF2LjXFo9LgXTrrN8FiryD4UnEPbZGg=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Stefano
 Stabellini" , Julien Grall ,
	"Bertrand Marquis" , Michal Orzel
	, "Daniel P. Smith" 
Subject: [PATCH v2 07/15] x86: Replace boot_domain with bootdomain
Date: Thu, 5 Jun 2025 21:47:59 +0200
Message-ID: <20250605194810.2782031-8-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250605194810.2782031-1-agarciav@amd.com>
References: <20250605194810.2782031-1-agarciav@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: BN2PEPF000055DA:EE_|SA0PR12MB4384:EE_
X-MS-Office365-Filtering-Correlation-Id: 879dcbff-4227-4bff-1600-08dda46a01b9
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?qOmpaUKcExd5+w6X4HWUp+9wPVPclz6zxy5XYzqkVGgKRZOOJc3gNCr4Xxzq?=
 =?us-ascii?Q?wdxJYkqGbBBeqqxZlYJsskFzYkaQdJAaJ5OEllyMBGqHLQFEDCvZdZ9iLMek?=
 =?us-ascii?Q?OLGGKhwCb82mzrK1ekuxDE5gq4LST+lQDGqZG5dhpyoGOwd4Xs8eYK25UZEF?=
 =?us-ascii?Q?Dy5D7nMIy/b4SPlT3ykphCUdGefu98GQN0f41Ru2jFkitZGz7qjPXZcHXl/o?=
 =?us-ascii?Q?gqCe5uVZ3uGFFPru03XfhI4IdAbvtrMBZxmk6LO0ufmTF6QdPEfjpl0d4OL8?=
 =?us-ascii?Q?6d8UUo6UbwSaORnd5Hh/6YFRyg01yCJO1zidbn3AyH98/z9ri4OJkCYig1cu?=
 =?us-ascii?Q?xTQC209xHUcUh2s7Ud0i9Rf0nPQtTF3EMqQQTp6PZEraKzy84EFRlA3FcVsQ?=
 =?us-ascii?Q?4PRoHMMo2zbMGEIqr3vLmPp6jNnmpW1N5EAqVIlfxvP0nd1R1OxcDBjCxy0c?=
 =?us-ascii?Q?j4YpBmDfsFoOoJScxLYgVKaHnJKsUt/lHmhvcZhc+OfBtqPjEUMnWcO0Ltmi?=
 =?us-ascii?Q?BXnbcvxSSAHMWn5ruGCR3cnVvsXzK9Kim2UlgM1xTYap7M54zh3H7Th9iO2y?=
 =?us-ascii?Q?aOvlk3t08+HOL6D9zfHVmBP6s8j+sFf5rV2zzjTQIcfJK7vjQ8J2uvZj6jyx?=
 =?us-ascii?Q?zvAA517EJazA2aU6AsGWDdeLhDpCwF6VjNgogMCvEzA7K36whk6AuR/ujHXJ?=
 =?us-ascii?Q?AJlRpYe2cesk+b9S+nWGA2/lq846vwxRP2brURtE5bKAOoiDSfnN/gR9G8hq?=
 =?us-ascii?Q?nEOb4NOc7Vk1QEf8YifFnzFPrEMJ4RUhtCGW3rhC2Uukx1zdWeBITEVLvi8G?=
 =?us-ascii?Q?HxR1EUhEjCdQXrVGK1AGliJG1Uk9eDIQbrx+Vz6l3vQR9/pzBozTdRt4Fx3U?=
 =?us-ascii?Q?3NJRJ1BPrAuYqUDA7j+QTraZHXUew6PqsHCQY2Zgi1v8ylcDxi44g6iiHLqw?=
 =?us-ascii?Q?xwnboUrL0mpRVxTilTQ+T697kJMzLq+r5hmIuMov9XGkilaNwDfNbAdWt8kc?=
 =?us-ascii?Q?kYp9sOeTe1vPiydGmRJEnLK0A7Qxvv05e+TI7Bak3wnOKS9oR8LAwqKrbGjU?=
 =?us-ascii?Q?ROyB+nUnNmaRbjwc8MNEZ+OJsQKYijHeIBIQbhwweXu8Y4xe5PUpX0ypXQcM?=
 =?us-ascii?Q?jiznMtxeCUeSC4myiSZ6z0UfOMcgo3pnsyI14xBFPGDAzK0iaHXGDa6HeTMa?=
 =?us-ascii?Q?Up0KGK33Ua+cWVNsM/yW5wqlJjCKtuIJuMBoJka3xUsMa6DXzGYlgJERrw57?=
 =?us-ascii?Q?obMZ3cX7xi0ixKEdlHKrwOk+vHBKpREq8/Mt+TsJaPQhPyn0up4KSySy3I6B?=
 =?us-ascii?Q?ofTvl/bRdjtMTfBJXmDJcZ1DiXf6G7LgTNKsvd/ZV0UcNK/qnCRFBJdVa/wr?=
 =?us-ascii?Q?yJ2Zk6wxx3+Gd4pZY/OOrDvBAarlHpg8fcQ13Bnf3llAj67c99nRglAM/unM?=
 =?us-ascii?Q?udxTeJlgBahc48DQ0OC2pNjcmV5eLcY7bz3NC8cEtpPFbLa8M7fuumbJhqEs?=
 =?us-ascii?Q?/kyn5jsZFk0qggiQF8Qfo2hTYpmY/ZXp1g2V?=
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 Jun 2025 19:48:55.8461
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 879dcbff-4227-4bff-1600-08dda46a01b9
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:
	BN2PEPF000055DA.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR12MB4384

No functional change intended.

Signed-off-by: Alejandro Vallejo 
---
v2:
  * Replaces the previous patch in which kernel_info replaced boot_domain
---
 xen/arch/x86/dom0_build.c              |  2 +-
 xen/arch/x86/hvm/dom0_build.c          |  6 ++---
 xen/arch/x86/include/asm/boot-domain.h | 33 --------------------------
 xen/arch/x86/include/asm/bootfdt.h     |  7 ++++++
 xen/arch/x86/include/asm/bootinfo.h    |  3 +--
 xen/arch/x86/include/asm/dom0_build.h  |  6 ++---
 xen/arch/x86/include/asm/setup.h       |  4 ++--
 xen/arch/x86/pv/dom0_build.c           |  6 ++---
 xen/arch/x86/setup.c                   | 16 +++++++------
 xen/include/xen/bootfdt.h              |  4 ++++
 10 files changed, 33 insertions(+), 54 deletions(-)
 delete mode 100644 xen/arch/x86/include/asm/boot-domain.h

diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 0b467fd4a4..1c8c5140a3 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -615,7 +615,7 @@ int __init dom0_setup_permissions(struct domain *d)
     return rc;
 }
 
-int __init construct_dom0(const struct boot_domain *bd)
+int __init construct_dom0(const struct bootdomain *bd)
 {
     int rc;
     const struct domain *d = bd->d;
diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 96410344a8..85c000b259 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -644,11 +644,11 @@ static bool __init check_and_adjust_load_address(
 }
 
 static int __init pvh_load_kernel(
-    const struct boot_domain *bd, paddr_t *entry, paddr_t *start_info_addr)
+    const struct bootdomain *bd, paddr_t *entry, paddr_t *start_info_addr)
 {
     struct domain *d = bd->d;
     struct bootmodule *image = bd->kernel;
-    struct bootmodule *initrd = bd->module;
+    struct bootmodule *initrd = bd->initrd;
     void *image_base = bootstrap_map_bm(image);
     void *image_start = image_base + image->arch.headroom;
     unsigned long image_len = image->size;
@@ -1329,7 +1329,7 @@ static void __hwdom_init pvh_setup_mmcfg(struct domain *d)
     }
 }
 
-int __init dom0_construct_pvh(const struct boot_domain *bd)
+int __init dom0_construct_pvh(const struct bootdomain *bd)
 {
     paddr_t entry, start_info;
     struct domain *d = bd->d;
diff --git a/xen/arch/x86/include/asm/boot-domain.h b/xen/arch/x86/include/asm/boot-domain.h
deleted file mode 100644
index 242e9c9c2b..0000000000
--- a/xen/arch/x86/include/asm/boot-domain.h
+++ /dev/null
@@ -1,33 +0,0 @@
-/* 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__
-
-#include 
-
-struct boot_domain {
-    domid_t domid;
-
-    struct bootmodule *kernel;
-    struct bootmodule *module;
-    const char *cmdline;
-
-    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/bootfdt.h b/xen/arch/x86/include/asm/bootfdt.h
index 2fc705a1cd..b30132381e 100644
--- a/xen/arch/x86/include/asm/bootfdt.h
+++ b/xen/arch/x86/include/asm/bootfdt.h
@@ -4,6 +4,13 @@
 
 #include 
 
+#include 
+
+struct arch_bootdomain
+{
+    domid_t domid;
+};
+
 struct arch_bootmodule
 {
     /*
diff --git a/xen/arch/x86/include/asm/bootinfo.h b/xen/arch/x86/include/asm/bootinfo.h
index f3210b7d6a..b8280ba357 100644
--- a/xen/arch/x86/include/asm/bootinfo.h
+++ b/xen/arch/x86/include/asm/bootinfo.h
@@ -12,7 +12,6 @@
 #include 
 #include 
 #include 
-#include 
 
 /* Max number of boot modules a bootloader can provide in addition to Xen */
 #define MAX_NR_BOOTMODS 63
@@ -34,7 +33,7 @@ struct boot_info {
 
     unsigned int nr_modules;
     struct bootmodule mods[MAX_NR_BOOTMODS + 1];
-    struct boot_domain domains[MAX_NR_BOOTDOMS];
+    struct bootdomain  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 ff021c24af..df03189870 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_domain;
-int dom0_construct_pv(const struct boot_domain *bd);
-int dom0_construct_pvh(const struct boot_domain *bd);
+struct bootdomain;
+int dom0_construct_pv(const struct bootdomain *bd);
+int dom0_construct_pvh(const struct bootdomain *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 c7deaba109..a8647f0fdf 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_domain;
-int construct_dom0(const struct boot_domain *bd);
+struct bootdomain;
+int construct_dom0(const struct bootdomain *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 e6c77413f5..a6f212fe0a 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(const struct boot_domain *bd)
+static int __init dom0_construct(const struct bootdomain *bd)
 {
     unsigned int i;
     int rc, order, machine;
@@ -375,7 +375,7 @@ static int __init dom0_construct(const struct boot_domain *bd)
     struct vcpu *v = d->vcpu[0];
 
     struct bootmodule *image = bd->kernel;
-    struct bootmodule *initrd = bd->module;
+    struct bootmodule *initrd = bd->initrd;
     void *image_base;
     unsigned long image_len;
     void *image_start;
@@ -1070,7 +1070,7 @@ out:
     return rc;
 }
 
-int __init dom0_construct_pv(const struct boot_domain *bd)
+int __init dom0_construct_pv(const struct bootdomain *bd)
 {
     unsigned long cr4 = read_cr4();
     int rc;
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index e9a70c2c2b..726adad0e5 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -297,7 +297,9 @@ static const char *cmdline_cook(const char *p, const char *loader_name);
 struct boot_info __initdata xen_boot_info = {
     .loader = "unknown",
     .cmdline = "",
-    .domains = { [0 ... MAX_NR_BOOTDOMS - 1] = { .domid = DOMID_INVALID } },
+    .domains = { [0 ... MAX_NR_BOOTDOMS - 1] = {
+        .arch.domid = DOMID_INVALID
+    }},
     /*
      * There's a MAX_NR_BOOTMODS-th entry in the array. It's not off by one.
      *
@@ -987,7 +989,7 @@ static unsigned int __init copy_bios_e820(struct e820entry *map, unsigned int li
 }
 
 static size_t __init domain_cmdline_size(const struct boot_info *bi,
-                                         const struct boot_domain *bd)
+                                         const struct bootdomain *bd)
 {
     size_t s = bi->kextra ? strlen(bi->kextra) : 0;
     const struct arch_bootmodule *abm = &bd->kernel->arch;
@@ -1022,7 +1024,7 @@ 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 bootdomain *bd = &bi->domains[0];
     struct domain *d;
 
     if ( opt_dom0_pvh )
@@ -1039,11 +1041,11 @@ 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();
-    d = domain_create(bd->domid, &dom0_cfg,
+    bd->arch.domid = get_initial_domain_id();
+    d = domain_create(bd->arch.domid, &dom0_cfg,
                       pv_shim ? 0 : CDF_privileged | CDF_hardware);
     if ( IS_ERR(d) )
-        panic("Error creating d%u: %ld\n", bd->domid, PTR_ERR(d));
+        panic("Error creating d%u: %ld\n", bd->arch.domid, PTR_ERR(d));
 
     init_dom0_cpuid_policy(d);
 
@@ -2162,7 +2164,7 @@ void asmlinkage __init noreturn __start_xen(void)
     if ( initrdidx < MAX_NR_BOOTMODS )
     {
         bi->mods[initrdidx].kind = BOOTMOD_RAMDISK;
-        bi->domains[0].module = &bi->mods[initrdidx];
+        bi->domains[0].initrd = &bi->mods[initrdidx];
         if ( first_boot_module_index(bi, BOOTMOD_UNKNOWN) < MAX_NR_BOOTMODS )
             printk(XENLOG_WARNING
                    "Multiple initrd candidates, picking module #%u\n",
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index e6d52a599f..19d2ff0f0c 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -108,6 +108,10 @@ struct bootdomain {
     struct bootmodule *initrd;
 
     const char* cmdline;
+
+#if __has_include()
+    struct arch_bootdomain arch;
+#endif
 };
 
 /*
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 19:49:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 19:49:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007452.1386727 (Exim 4.92)
	(envelope-from )
	id 1uNGa8-0002tL-Nw; Thu, 05 Jun 2025 19:48:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007452.1386727; Thu, 05 Jun 2025 19:48: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 1uNGa8-0002tE-K3; Thu, 05 Jun 2025 19:48:56 +0000
Received: by outflank-mailman (input) for mailman id 1007452;
 Thu, 05 Jun 2025 19:48: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 1uNGa7-0002fZ-MU
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 19:48:55 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20612.outbound.protection.outlook.com
 [2a01:111:f403:2009::612])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1bc05c60-4246-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 21:48:54 +0200 (CEST)
Received: from BN9P223CA0028.NAMP223.PROD.OUTLOOK.COM (2603:10b6:408:10b::33)
 by SA0PR12MB7462.namprd12.prod.outlook.com (2603:10b6:806:24b::5)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.35; Thu, 5 Jun
 2025 19:48:50 +0000
Received: from BN2PEPF000055DF.namprd21.prod.outlook.com
 (2603:10b6:408:10b:cafe::a4) by BN9P223CA0028.outlook.office365.com
 (2603:10b6:408:10b::33) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.19 via Frontend Transport; Thu,
 5 Jun 2025 19:48:50 +0000
Received: from SATLEXMB04.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.8835.2 via Frontend Transport; Thu, 5 Jun 2025 19:48:50 +0000
Received: from xcbagarciav01.xilinx.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, 5 Jun
 2025 14:48:46 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1bc05c60-4246-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=xNVPyuWLYTQT7XtRq8yNETWeiaxysNWfyMttO3W9GP2w7QvLtOJX6UEy0W5pctNWxf2OE+Y8LRDT9JT1dsItcL7Vo0lDCJMjiQMTu8KvnHNejAlCBgZ8eLWyoNQo6ZceYVL3Aa1IlNV3bBCLJB2LA1t1jXLl/6ErY79zNF1qjKTxR0KflHroylqlOQqOCtZXH+6fDuHtqnLjIylAXHJdMEyH/lAJj+1cA8ZHL1IcZchxl3PDGcb3aHGY1Tts8/tbA51RU+uLzfgOIliklcMkO06IbGds9/67sCifyvOuX0fdkOCnbf75L8rYdB+l3bWZD08h3vfcvZaO3TxRmuzlbA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=PdgGRU93owYApIHVcIm7iZ88U71h29ScJQ/Sz6iodgg=;
 b=rgZvr7REDjzjKpuGKPnVSD0WYZsGMPB43armjmgbzmG/aWJTlDe7gPr+e3hmsiqF7hJ5++K8afkTzhPVpnPKPjLnidFKOQkYMJlKk6nAIwqDi4tSY0uv/FtMQFilymMy+eKakLPgRIc2hcdd9FouFPxFQHYm4fa2wjkO54uIVjJI64irHTkaxlO63aGiuPAgipnuZBqNaJ2/BiG4ftQ/P70gta7XRFbABAznghEZwmiLq0VZBb9SSYgR3abgSN2YhKxwtGcSYmzNUgYq/jKembrj0FT1ViLjWTnx11vkpDy4+lIXLuuNR86cZ/0BHm7Ld49ILzL8Yf0M8fcLe6+dTg==
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=PdgGRU93owYApIHVcIm7iZ88U71h29ScJQ/Sz6iodgg=;
 b=ZFb9GzLT6Bg6MO/vN8q3zZ6yL2tTJUzH85NXxk/lNq6DAUX8K15A5UNst4yK3PA0K5wSK/Lznf6a9bgb8JiA+O6D9gd9sgRABr5WcaFtvIi4VjyKkcUJbvvNJuMInFVy6vteRbmELah8B67tJH3EPMzpnG47wELnXp1TwUGI5RA=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Daniel P.
 Smith" 
Subject: [PATCH v2 03/15] xen/dt: Add BOOTMOD_MICROCODE
Date: Thu, 5 Jun 2025 21:47:55 +0200
Message-ID: <20250605194810.2782031-4-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250605194810.2782031-1-agarciav@amd.com>
References: <20250605194810.2782031-1-agarciav@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: BN2PEPF000055DF:EE_|SA0PR12MB7462:EE_
X-MS-Office365-Filtering-Correlation-Id: 16efe8ab-8de1-4893-c800-08dda469fe88
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:
	=?us-ascii?Q?9bzTa0F8shATQti5V+211cPeq8ykB+KppC3oqZPQTJfwBuixmixGuP7U8/Rh?=
 =?us-ascii?Q?uN1vErjkUHY1+fnZuaJgBgdFuNS6Lk+mqFkBSR+vWXpZBoNqDT9ZZeYiIEdn?=
 =?us-ascii?Q?bE4TCdEhJxDvZ7ZzAx961N0PTi0odwl8ZnFLc4Xkz8d9yqryIH4+e0LzhkWv?=
 =?us-ascii?Q?TgR/2D5OINH/LhstA58LSCEieeR8nJQbaUCJcdEBcGmBS/xUYOzXixGv0JFy?=
 =?us-ascii?Q?1Xa2BJgRIQSeSenGBIHEui9zv3+YR+Wb9AH3qZQTDbhnu5v7AjUkW/glXSeq?=
 =?us-ascii?Q?kohzn8Rjh91h4R9fZEVSS/8mWvGFNcje6AcLaY3bHNL/jcOJ+ZngRuimdqst?=
 =?us-ascii?Q?yIh8mtf8BTqhwCfCoWrHZej3ww0MyslJLE0tARIr5Pju3v+GBJy8SS7Fm68f?=
 =?us-ascii?Q?GbQeBNpikrGkSYq9m601JhI4BnOvsX+IudAMEc7fZogctpZjCmcM87x1PQLZ?=
 =?us-ascii?Q?Ihd0l85mAgI3wmhGVgv0Casl+65gx028C+C/3bDE5w19Sg8YVvy8w8YC3oXk?=
 =?us-ascii?Q?fiKa0GZYKnrXi1UaJkYAj9VmebS9KG9sMEPIo6/HJiTI6xdBTd42UiyzzahE?=
 =?us-ascii?Q?CdNekEPpdmLimzYCGza4kNcz7B12onAUjxveYVDp0MMPvaybV5l9D6UITt9o?=
 =?us-ascii?Q?qZ5L2FeVMmRsMJ5kD9IgKMXXHx01va8b3+wKoNRNtJbGT1AW3/mt9u/Z3SxF?=
 =?us-ascii?Q?5bs1Ux3I0/G4n8mH8m9ZOfRPa/JPdAQifB78qE6UmR0x6Olqq3iD/rI68lb7?=
 =?us-ascii?Q?fEmSZkrprHKMeX+TI4eTCAfA0y3ZLtL7HOlC0JA8S3VUbdA+VgkT2MAR4jtx?=
 =?us-ascii?Q?AQDnd/SxWkRQXN0pnv/NE1ebByurNFeCWGmehXHzCRt+kmhevgpIbYbsj3s+?=
 =?us-ascii?Q?taNu+Z6Q/iFFDOE8Ec1zGejgll5nuzCafO9qPIMxuIdDBFlEwuJeB+t1J0EA?=
 =?us-ascii?Q?PCFZGQfsUrJnlWHAxBW/TXyKwQZEP8EVhBBC/73YNzmIuiHIiNgooiuIy52l?=
 =?us-ascii?Q?s5E8Hh88IvWRRMLkiSkAQXi3XRkdVY3d5OC/wV9eOSUKqkpr2c0z7GWnILAN?=
 =?us-ascii?Q?UPKz0mPlZR6dei6sW0m5qiv4e03CdLIvIBmEI9xzumGEiM9spRLbfIUO/jzG?=
 =?us-ascii?Q?7K5MiZwPf95oXThq+Xxf5RTjzcQ1fz30BJAbdETiRoYZd2nDpE+za0H0bvBk?=
 =?us-ascii?Q?O8Ok2YdZSs09XE0QaI+P7FHRwAA3ME6GhyP9L9m4XskY+p5YVuqXV82qoCNT?=
 =?us-ascii?Q?Vkncux1ac/g1SXAjOXToE5KKWtz/25/fZzz8kVZ50RH2rO2fbB89lkhT8u8M?=
 =?us-ascii?Q?VjmOJ1k9tSrDw2bS9E20/UvMQqzaORT0pBkPv/xK+Pm0VX1J0+tM2rxPukAg?=
 =?us-ascii?Q?GvCNTo3ZwMBYwZtYbW9Irl2Z8jSVTrRJ2DW2DG4IvAc0dRrKws3FUj7hOhhS?=
 =?us-ascii?Q?lktOL4ijDVX8DcHLeSaDrrEeT0wfILDCIFALt4e/cX4yTMVZG+rvJ5T8NsTf?=
 =?us-ascii?Q?v1gw5yit2QHkxjQnDE7sf93ugbZ6vNYxjtWi?=
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: 05 Jun 2025 19:48:50.4949
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 16efe8ab-8de1-4893-c800-08dda469fe88
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:
	BN2PEPF000055DF.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR12MB7462

In preparation for x86 to start using bootmodule instead of boot_module

Signed-off-by: Alejandro Vallejo 
---
v2:
  * Added microcode detection in early probing
---
 xen/common/device-tree/bootfdt.c  | 2 ++
 xen/common/device-tree/bootinfo.c | 1 +
 xen/include/xen/bootfdt.h         | 1 +
 3 files changed, 4 insertions(+)

diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
index 9df80291b1..9daea06e57 100644
--- a/xen/common/device-tree/bootfdt.c
+++ b/xen/common/device-tree/bootfdt.c
@@ -351,6 +351,8 @@ static void __init process_multiboot_node(const void *fdt, int node,
         kind = BOOTMOD_XSM;
     else if ( fdt_node_check_compatible(fdt, node, "multiboot,device-tree") == 0 )
         kind = BOOTMOD_GUEST_DTB;
+    else if ( fdt_node_check_compatible(fdt, node, "multiboot,microcode") == 0 )
+        kind = BOOTMOD_MICROCODE;
     else
         kind = BOOTMOD_UNKNOWN;
 
diff --git a/xen/common/device-tree/bootinfo.c b/xen/common/device-tree/bootinfo.c
index 76d652c0de..717cfa0962 100644
--- a/xen/common/device-tree/bootinfo.c
+++ b/xen/common/device-tree/bootinfo.c
@@ -31,6 +31,7 @@ const char * __init boot_module_kind_as_string(bootmodule_kind kind)
     case BOOTMOD_RAMDISK: return "Ramdisk";
     case BOOTMOD_XSM:     return "XSM";
     case BOOTMOD_GUEST_DTB:     return "DTB";
+    case BOOTMOD_MICROCODE:     return "Microcode";
     case BOOTMOD_UNKNOWN: return "Unknown";
     default: BUG();
     }
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index 64db48f4fe..ff40f3078e 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -21,6 +21,7 @@ typedef enum {
     BOOTMOD_RAMDISK,
     BOOTMOD_XSM,
     BOOTMOD_GUEST_DTB,
+    BOOTMOD_MICROCODE,
     BOOTMOD_UNKNOWN
 }  bootmodule_kind;
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 19:49:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 19:49:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007453.1386737 (Exim 4.92)
	(envelope-from )
	id 1uNGaA-00037g-Up; Thu, 05 Jun 2025 19:48:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007453.1386737; Thu, 05 Jun 2025 19:48: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 1uNGaA-00037Z-R2; Thu, 05 Jun 2025 19:48:58 +0000
Received: by outflank-mailman (input) for mailman id 1007453;
 Thu, 05 Jun 2025 19:48: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 1uNGa9-0002tD-AD
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 19:48:57 +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 1d27cfbb-4246-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 21:48:55 +0200 (CEST)
Received: from BN9P223CA0008.NAMP223.PROD.OUTLOOK.COM (2603:10b6:408:10b::13)
 by SJ1PR12MB6313.namprd12.prod.outlook.com (2603:10b6:a03:458::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.37; Thu, 5 Jun
 2025 19:48:46 +0000
Received: from BN2PEPF000055DF.namprd21.prod.outlook.com
 (2603:10b6:408:10b:cafe::ec) by BN9P223CA0008.outlook.office365.com
 (2603:10b6:408:10b::13) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.30 via Frontend Transport; Thu,
 5 Jun 2025 19:48:44 +0000
Received: from SATLEXMB04.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.8835.2 via Frontend Transport; Thu, 5 Jun 2025 19:48:44 +0000
Received: from xcbagarciav01.xilinx.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, 5 Jun
 2025 14:48:41 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1d27cfbb-4246-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=CcG5aCmN+sLVcWelr4FxqvUy/uLTWAXBl91zZl/UgIjZ34jaA6OkR9QHnXLI1iu9xSXbzDp2IbE8sXR0EW8cOGZl2gVKIrFTPK/Paqw1Oo1ZyaNJXJnBFDWOez9AZplwR4c6pJTItz0eEbwmrFr8THqgoaOGXg0O59PCkjdjMrNwewq0v3jv3qvPupnEVDPvCLM4VNzE1FWRQcjXEAyVcIVsvqb/QgheIvhbreeDgQmYVGEIqhNrgnbcPecJtTil2uIn7GPS/r8JVMlrkrHncZPrALTdhlRyZu0I1OdSvb3P7v+jtcyOVgAdse2qqjj+6uBGAjrCvSWttbWx9Qdjng==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=gVCZ4mr10xTNgUay/BsdsDmnmul66uI4HIiTZagqRPM=;
 b=R2UDXpaK84TanGZczMHhnxSeq1fvFH/v062teWAYc1tiNQAg1ryBtMzB3r7p3/0YQY2Xp6hC1KJZarMhyNcQd1WMbKphGiin0Z8vcnuHyPfLbjkBNhK46Unr/MyKIbz5KPknHRWL5BRyQan/9myj7rTh+bGlfDC+jHAlqcAtyospachncVzB1GJKjy1JkLpEMhqCmR2Ee/jE6hZF5ZoQzAe+fINEy7uhX6XBOR2Ps1huvd67xKJw23jU0tl096Qs98aZiKepxP+IVVysmPPSpQl/bbGcdU6Mc+B0t/MT/sKrdUH3vxLHUqoi63cqYRI5ZOO090+wdn/dG3mm50Gicw==
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=gVCZ4mr10xTNgUay/BsdsDmnmul66uI4HIiTZagqRPM=;
 b=G4WyiA4A61SpCvTrL7SP97jmXCNur67B3FjtOSIK9OCbav2iyeVP8tKYQ6Jf/ObiRV1330yLc22YmRdWknF+MAgXHnor7dfgwY89Nuh2H1igguVOiSaRK8oqV94xBoBbNgRDA/u5Ex+IARfx++IuMpoisSKWlKCIMnVhZDWSBlI=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Alistair Francis
	, Bob Eshleman , "Connor
 Davis" , Oleksii Kurochko
	, 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 v2 01/15] xen: Clean up asm-generic/device.h
Date: Thu, 5 Jun 2025 21:47:53 +0200
Message-ID: <20250605194810.2782031-2-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250605194810.2782031-1-agarciav@amd.com>
References: <20250605194810.2782031-1-agarciav@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: BN2PEPF000055DF:EE_|SJ1PR12MB6313:EE_
X-MS-Office365-Filtering-Correlation-Id: a59c1263-a5a8-4539-92c3-08dda469fad9
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|7416014|36860700013|82310400026|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?vDIhsNdrI+3eujkFCT3CvpeGvRK0mbh5K73lYh7GeQJe9WAQyubWO5cB/0nc?=
 =?us-ascii?Q?qLQHX9N73X9KEdCBwwKIOThuuZPmBI5YSQSdnYtMB75rk9xgt8rxV8308jEs?=
 =?us-ascii?Q?LzblDRoTKPEjlIaa3PxiitnN44UGi498EYw6+kR+H/vxJH2ylsL8fwT3UOK6?=
 =?us-ascii?Q?NFbCDQVQLMkex+wHvs/QEyCcDG69NggEyhLfAQbVCebhceOQXB+NF/owSc3X?=
 =?us-ascii?Q?t8E/nbfghWmy8SghX26KvY4gxCx9sTfMb3qCZ/5ljjpXcKN9YN/oXgA3CoGe?=
 =?us-ascii?Q?1iyAGD0UTLWaLOhFVKVDhycUGAQN4vNx6ipLjBkkSBArJt6sT8SYVreqSQ+J?=
 =?us-ascii?Q?qDy9Kt+4SLtIwm8kGuFQq9I9ZFaP9d1z4v4jCwMQ32p5YRv7Ik1xpkhm3frF?=
 =?us-ascii?Q?D+t83janXvt1kSDAbiU/cHimOo8c9yO+4mRZDFY3bWCiwuPSG7Q0+iDmiJiH?=
 =?us-ascii?Q?uMndviypPU5a4fo2Nzdh3N0UJN927xz7CW4/D6pHFCNwRzsgk90zFXHVVLMg?=
 =?us-ascii?Q?SZfkd3T1C3XFAduE3XjlYVOpENeVFXW6tLuvYrGEKThD3tV1vGGV6OTMHVnG?=
 =?us-ascii?Q?NG6GIlt2W4eTrbl5rnFIOKJZd3qwOp+oC/is736kGLPJrml0i9Eqs68WzADm?=
 =?us-ascii?Q?I9tuUgkMHBnYNP4ekxPhmL1fnHeemSveUaVi18C/lMh8mbjayo8w9oyQ1JNW?=
 =?us-ascii?Q?30FiadWKBpqPpyva5eAnln6jVBgASBqTLkyGg/GOXOHOCfLDXZ9YDQ+I2Eud?=
 =?us-ascii?Q?4h8/pjNzsRxxpoNR1yKtWI1tx73OMkH1eyvaGgm4E9KckPLbxT/pvuHp5dpu?=
 =?us-ascii?Q?laQN4rtq0IpRVhdIbp68X+Y1uFZ6/ewakLF6TG034tQ5CqX2zh3CETGyh++Q?=
 =?us-ascii?Q?OufF2su/j74+p69zo+BRRGWEYL+hcsBohwRBm7clOcCwijujJCTPR0/REe2k?=
 =?us-ascii?Q?6Q9LfFXecta4Gkfinnpv7lQtIBYIKGps5A10/q+sp5ayRyW9xxDluvI7tmpy?=
 =?us-ascii?Q?wMFMZLw9I1u0UqAFitNjavoUcrS+HJWSJYJMgj+Rx7V6FzWLuQmLGRhP0GMq?=
 =?us-ascii?Q?w1nGuGQbfw95uDE3Bb91D72BNrUkGD4wTJFH6MeiDn4Zwf3fVVrPKfP0eoSK?=
 =?us-ascii?Q?pmlBFUzO2WlqC5n7MtBg6ejtnn82IGlS10beMH61eVNBtTUrWVRndAfFvQsN?=
 =?us-ascii?Q?5/BnU/qeefb1KoZAwC48IO3EPDp+nsgIWobGVdUbQEOqJn7MAvPka0rohfKl?=
 =?us-ascii?Q?bUJiABFooc42lgB44NVtxt6KUwnB5Bw/i+QQ4rL/QgGd8t8/FaN+d2bYsyV6?=
 =?us-ascii?Q?w2og6bcJgNa4igfP5WDNiLW1xLMBTOXNYAVcnsETVbrKGMiZELqRDt/z5m2F?=
 =?us-ascii?Q?HzZseg1Wr0Ze8rOwMaPxxexCDWudskkmgJG30ustuRKKf5lIDSbV6Q2ISMjG?=
 =?us-ascii?Q?xPQXIDZX3gKDMSATMJ1G22WZvdbWkmaYn1X5gL4Y6pU1OaC055qiUfo+sCBS?=
 =?us-ascii?Q?DUe3CMHsdDY32C5xI6iTt13Johr/kH6q2eCn?=
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)(36860700013)(82310400026)(1800799024)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jun 2025 19:48:44.3121
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: a59c1263-a5a8-4539-92c3-08dda469fad9
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:
	BN2PEPF000055DF.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ1PR12MB6313

There's some pretense this header may be used without
CONFIG_HAS_DEVICE_TREE, but that's just wishful thinking. Only x86 lacks
that option, and it fully overrides this header, typedeffing struct
pci_dev to be device_t.

Furthermore there's an include for xen/device_tree.h halfway through the
header, but that header already includes asm/device.h, creating a cycle.

Clean up the header removing ifdef guards, merging the typedef onto the
struct definition for device_t and removing the spurious include.

The only affected file is aplic.c, in riscv, which is forced now to
include device_tree.h directly.

Not a functional change.

Signed-off-by: Alejandro Vallejo 
Reviewed-by: Stefano Stabellini 
---
v2:
  * Add new comment and ifdef guard with #error
---
 xen/arch/riscv/aplic.c           |  3 ++-
 xen/include/asm-generic/device.h | 26 ++++++++++----------------
 2 files changed, 12 insertions(+), 17 deletions(-)

diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c
index 10ae81f7ac..dd7a274c52 100644
--- a/xen/arch/riscv/aplic.c
+++ b/xen/arch/riscv/aplic.c
@@ -9,13 +9,14 @@
  * Copyright (c) 2024-2025 Vates
  */
 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 
-#include 
 #include 
 
 static struct intc_info __ro_after_init aplic_info = {
diff --git a/xen/include/asm-generic/device.h b/xen/include/asm-generic/device.h
index 1acd1ba1d8..631dab046a 100644
--- a/xen/include/asm-generic/device.h
+++ b/xen/include/asm-generic/device.h
@@ -1,14 +1,20 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * This header helps DTB-based architectures abstract away where a particular
+ * device came from, be it the DTB itself or enumerated on a PCI bus.
+ */
 #ifndef __ASM_GENERIC_DEVICE_H__
 #define __ASM_GENERIC_DEVICE_H__
 
+#ifndef CONFIG_HAS_DEVICE_TREE
+#error "Header for exclusive use of DTB-based architectures"
+#endif
+
 #include 
 
 enum device_type
 {
-#ifdef CONFIG_HAS_DEVICE_TREE
     DEV_DT,
-#endif
     DEV_PCI
 };
 
@@ -23,23 +29,15 @@ enum device_class
 };
 
 /* struct device - The basic device structure */
-struct device
+typedef struct device
 {
     enum device_type type;
-#ifdef CONFIG_HAS_DEVICE_TREE
     struct dt_device_node *of_node; /* Used by drivers imported from Linux */
-#endif
 #ifdef CONFIG_HAS_PASSTHROUGH
     void *iommu; /* IOMMU private data */;
     struct iommu_fwspec *iommu_fwspec; /* per-device IOMMU instance data */
 #endif
-};
-
-typedef struct device device_t;
-
-#ifdef CONFIG_HAS_DEVICE_TREE
-
-#include 
+} device_t;
 
 #define dev_is_dt(dev)  ((dev)->type == DEV_DT)
 
@@ -87,10 +85,6 @@ struct device_desc {
     int (*init)(struct dt_device_node *dev, const void *data);
 };
 
-#else /* !CONFIG_HAS_DEVICE_TREE */
-#define dev_is_dt(dev) ((void)(dev), false)
-#endif /* CONFIG_HAS_DEVICE_TREE */
-
 #define dev_is_pci(dev) ((dev)->type == DEV_PCI)
 
 #ifdef CONFIG_ACPI
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 19:49:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 19:49:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007456.1386767 (Exim 4.92)
	(envelope-from )
	id 1uNGaD-0003nB-2d; Thu, 05 Jun 2025 19:49:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007456.1386767; Thu, 05 Jun 2025 19:49:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNGaC-0003n1-VX; Thu, 05 Jun 2025 19:49:00 +0000
Received: by outflank-mailman (input) for mailman id 1007456;
 Thu, 05 Jun 2025 19:48: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 1uNGaA-0002fZ-WF
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 19:48:59 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20623.outbound.protection.outlook.com
 [2a01:111:f403:2413::623])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1d1bde3f-4246-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 21:48:57 +0200 (CEST)
Received: from BN9P223CA0007.NAMP223.PROD.OUTLOOK.COM (2603:10b6:408:10b::12)
 by PH0PR12MB8823.namprd12.prod.outlook.com (2603:10b6:510:28e::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.35; Thu, 5 Jun
 2025 19:48:47 +0000
Received: from BN2PEPF000055DF.namprd21.prod.outlook.com
 (2603:10b6:408:10b:cafe::cb) by BN9P223CA0007.outlook.office365.com
 (2603:10b6:408:10b::12) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Thu,
 5 Jun 2025 19:48:47 +0000
Received: from SATLEXMB04.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.8835.2 via Frontend Transport; Thu, 5 Jun 2025 19:48:47 +0000
Received: from xcbagarciav01.xilinx.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, 5 Jun
 2025 14:48:44 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1d1bde3f-4246-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=MCkKidObom17MOavgs/GidT57hFvSOGtso0Ar0I1O0/+vikZ+inEVblUxW+12btWFLbOXkbVOLUlXlhfuHjkypgt01ZUHPPcG7bMnsiRaU8M5qdfPgv0UVhHIAL4UFv3aftREVTNpJo4NtjbadP+e4Ewf77WaD0I1+PoC9op1zpFf8C7Hrmq7nNFITRPzPPy09Gle75wQQmUx5+XCVmlm9kLDD1S+eDCorlJPWqRfAmu0+iJa+Nn3MJUyPJaw1hlaG1D+jX+YhN12kZHpaYuHwN6UhubPAlsdD3X9DKPEGEPIY/I7JW1L4aZF2MX3sVG1vvWfWbTKYdIuhgBTlGuZg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=DszMyD20ThXf63bYWe7ewf2cnMilx+Yg49wMmABHUYw=;
 b=GPnp5AB++9S5kpFVS01Yv2wYOHMIuiFls4vU2RJbN8TGuxUF3A/k52Fb31hOs1Yy+Pei+bIFzyUSt56sAxiQ0Zu/oJnEZWNekqGfHyWiTSt44kTWiA2sBo1RxgTpbtvRziXoIWMHJCDrEJ8o0wTp6eKT2P4VoPTXFvrM7iC+silxf6Rz2HloocgZWz5YCNdOiRfcuerr9LHt7oFL6gDEIGGbEwhIH1ruEq1Wpr4IV33mVeD0KUY6+AIY2nh1ybNG1MlyFUfkNt9t+fPCuI65iIVr8wARTLwl4dX7dYXBoCgtp1HxCmp7saOyK4AyjrXn80W4+LyLKF4+CVJ5t3TBmA==
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=DszMyD20ThXf63bYWe7ewf2cnMilx+Yg49wMmABHUYw=;
 b=gKoveL4/UOdtyLvMW4VcP2PJajkktXvT5bF8nhD9qmOR6QmTL7nUHoaZn3sQk4EF78bhhMEctI1kjF9xb1k5srK6dEMgc6Sr1Gg6Sh8Nkkzse2YAIkpeP6B+HjkT6Ux2q+1CZUfnPwYGe1qOGaYANVXr0lBcASkg8hFO0R9o6Fg=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , Andrew Cooper
	, Anthony PERARD , "Jan
 Beulich" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, "Daniel P. Smith" 
Subject: [PATCH v2 02/15] arm/gnttab: Break links between asm/grant_table.h and xen/grant_table.h
Date: Thu, 5 Jun 2025 21:47:54 +0200
Message-ID: <20250605194810.2782031-3-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250605194810.2782031-1-agarciav@amd.com>
References: <20250605194810.2782031-1-agarciav@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: BN2PEPF000055DF:EE_|PH0PR12MB8823:EE_
X-MS-Office365-Filtering-Correlation-Id: 1927f5ab-f940-4e54-c5c9-08dda469fca1
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|82310400026|1800799024|376014|7416014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?1n50+s2bFGK3tOOGk0E/0alKu1ghwWao2pJjpWHjiYm8taOJ6KY4hzPmTwTr?=
 =?us-ascii?Q?/WzjanoK45HsqKeiDBMBsKj+x1V+IfVBAmefxd+eF9ap/9jRZ9W7zRZ75MHV?=
 =?us-ascii?Q?wUw9jsvYYbb35pJlMZOQG+im3YOsGU1kNHzu8sLYi5ySVdA23yDbHHg6DpzO?=
 =?us-ascii?Q?LdL2MkpkHkvIJd6fsWB0zqpMKzuUoSiPsUNTUoSeNSY9g9jwWmIrEueJc8JF?=
 =?us-ascii?Q?yfplsUrUVcsSfCuVkOyG/0UVb5oWw9loxmlFsAh/sUA8BgFcpmt6prYso26N?=
 =?us-ascii?Q?9hvOjOlg1WaYp0hv9xsIZfJ5XJfDeYvu81UX2SpoeWBzg0ePM5cQGQJQtcdm?=
 =?us-ascii?Q?eNlf0YvugXYTL0NClTALtecw6LlfcV/vWGE1ZfMCi5bpFjXWo5Jp1O+n3iTJ?=
 =?us-ascii?Q?4duJnf4K735Geuocwvqh9AWxtuQ5fgqmirsd/r8uiZEPsZE4Q3xJ9wkzfLnQ?=
 =?us-ascii?Q?ZVhe24VNKoLzrJ/gNrWke80Dryh8X3vsyuZd4XCKNZZQUlJaN7g7LSWiWllc?=
 =?us-ascii?Q?g603xXaP6cJEcuJzXUIpYRnWTHYnzc4NKHfEtWiJ3EC2UTD6xH9GIjKqrML/?=
 =?us-ascii?Q?wb+cA6kaoOdjVB2ZdRdN3UK2f6U/bLiFdfOBcwl2U23p6F2pW/tnZVUZ/cC8?=
 =?us-ascii?Q?5nWNG7YZ/idBZqNzwzelxdovV9x9xaBJlVD4PADtmPMrkNnDRfjeckRG+Vta?=
 =?us-ascii?Q?CaKyhg4NJxDNRpa6jFp1AxVbAPiey4LnNd1HtbgwTT5HZ311wbBGD0V+fxnG?=
 =?us-ascii?Q?Tv05qPykEOds9wMgjee/8eLLqRgb3IHrcF7PVM5KeFKC0N+KeKRj7lwOyviJ?=
 =?us-ascii?Q?wMQofoBn7iUvlEg2zZxuIoXWhS3jC18ixR8lxyUdBPJ+plhwgzaf2tsBOvtY?=
 =?us-ascii?Q?Q+++e7TLS4UQ0TW8oSecIrhH+tokOjWqildVqUT0KUkzU0sN4g8JH1/FnB2E?=
 =?us-ascii?Q?KpmT/ZTr5DsWks7rvvM67nGtw5YGtpaje396TEjmPF8z39Nn3nMPj4pRPdW8?=
 =?us-ascii?Q?KFnrsnI924pwdkdfWm5hZPwGlOsc5G3NEn/BFiejWiGE6Zn0MxpRfHcMBaLj?=
 =?us-ascii?Q?SXD0jIlM4x9jvqAdxPHQfZ+jmdUjpS4iJA71rCZgfOdF5CNqMcbcFQuG+Vdv?=
 =?us-ascii?Q?Yu+lM1KQaIrSnUcW4MFvHX0n4AAwaVnbnTBYThocE4WHw59Z/TC8dhfb5qIU?=
 =?us-ascii?Q?oQT6Ze+3fysWnS63rSCea67SPcVgd37nQr5mXlhQ2/ALtcLyDDSwYfHkoTPE?=
 =?us-ascii?Q?Af9KraqQf7q1w4fP5lfie8zIaSJ1mSwctn2lb9uzgm8znSiq3tCWT6X+l3gR?=
 =?us-ascii?Q?pZbmfH+qW7CXebIauwjRUhWWbQm/HFnG4PXjVzv/bhoDXpCtUqOsbdid++nk?=
 =?us-ascii?Q?Ucw0mfKpjcd6eCpk45t42Kqq6eaEm4T5FtjfXVeAdjgqS54VxWeTAajcDSa0?=
 =?us-ascii?Q?envOzjIU183+eOdEx7gw+oiSVhbxr88KJL2hU5vE0HeZ814QX7kjdYuVjYC6?=
 =?us-ascii?Q?72VbcQhT9Ws9AkeRVfbFHWfXUsvPVLjZHoND?=
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)(7416014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jun 2025 19:48:47.3027
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1927f5ab-f940-4e54-c5c9-08dda469fca1
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:
	BN2PEPF000055DF.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB8823

Not a functional change

Signed-off-by: Alejandro Vallejo 
---
v2:
  * Remove both links rather than just one.
---
 xen/arch/arm/include/asm/grant_table.h  | 1 -
 xen/common/device-tree/dom0less-build.c | 1 +
 xen/common/grant_table.c                | 2 ++
 xen/include/xen/grant_table.h           | 4 ----
 4 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/include/asm/grant_table.h b/xen/arch/arm/include/asm/grant_table.h
index c5d87b60c4..c47058a3a0 100644
--- a/xen/arch/arm/include/asm/grant_table.h
+++ b/xen/arch/arm/include/asm/grant_table.h
@@ -1,7 +1,6 @@
 #ifndef __ASM_GRANT_TABLE_H__
 #define __ASM_GRANT_TABLE_H__
 
-#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
index 3d503c6973..d5bb1d5d35 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -26,6 +26,7 @@
 #include 
 
 #include 
+#include 
 #include 
 
 #include 
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index cf131c43a1..1e437eff50 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -42,8 +42,10 @@
 #include 
 #include 
 #include 
+
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_PV_SHIM
 #include 
diff --git a/xen/include/xen/grant_table.h b/xen/include/xen/grant_table.h
index 297d7669e9..98c4f4136b 100644
--- a/xen/include/xen/grant_table.h
+++ b/xen/include/xen/grant_table.h
@@ -27,10 +27,6 @@
 #include 
 #include 
 
-#ifdef CONFIG_GRANT_TABLE
-#include 
-#endif
-
 struct grant_table;
 
 /* Seed a gnttab entry for Hyperlaunch/dom0less. */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 19:49:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 19:49:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007458.1386781 (Exim 4.92)
	(envelope-from )
	id 1uNGaG-0004Co-SA; Thu, 05 Jun 2025 19:49:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007458.1386781; Thu, 05 Jun 2025 19:49:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNGaG-0004Bf-O7; Thu, 05 Jun 2025 19:49:04 +0000
Received: by outflank-mailman (input) for mailman id 1007458;
 Thu, 05 Jun 2025 19:49: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 1uNGaF-0002tD-13
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 19:49:03 +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 1ff139ef-4246-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 21:49:01 +0200 (CEST)
Received: from LV3P220CA0015.NAMP220.PROD.OUTLOOK.COM (2603:10b6:408:234::25)
 by LV3PR12MB9119.namprd12.prod.outlook.com (2603:10b6:408:1a2::9)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.38; Thu, 5 Jun
 2025 19:48:57 +0000
Received: from BN2PEPF000055DE.namprd21.prod.outlook.com
 (2603:10b6:408:234:cafe::3d) by LV3P220CA0015.outlook.office365.com
 (2603:10b6:408:234::25) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.35 via Frontend Transport; Thu,
 5 Jun 2025 19:48:57 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN2PEPF000055DE.mail.protection.outlook.com (10.167.245.8) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.2 via Frontend Transport; Thu, 5 Jun 2025 19:48:57 +0000
Received: from xcbagarciav01.xilinx.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, 5 Jun
 2025 14:48:55 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1ff139ef-4246-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=J675nKOhYsqiQO5Kkemo03/UTOmqxx77LGX3EBEFCLmKnC4ZnPYGEJTBniCRG8FU1hZsZarG0drUiow0W10d72MsNDgDCDmRDlbD/TdLvY9No/NOV95+YZjMYmSWltaK258c+iYtFMZly7Ez73KxXdQ7YkXBGgSWSfOOmcfqZthc7qLSWl36Q+Sub+EzBj9oWng2yEdzqnv+AMCtltcVPF3VjMs09zvWHIr9ufKrJyKgGkWmyOrrWLFu5lJC3aHZxqQbyxAIO4Aq9TPqdI6VwmowjYe6QjDbwpdIviei0R2N5d1wr2CC437Wi67sq48rsTdmal+ka4b34VGdVWl72A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=T8nPofpxazoCxEYwpzGMgVEbLO3KBjjKiS7lZ9jpSZU=;
 b=q70gIi1pYEOWQ6jd1vlwwa6a8ioz73+loBnALocqfIN405/277rEdCRKXEw1zE7+KlwqkKFBNpYIbZbNKysDMfU4URvtXDVJ9eSIs/Jv46d8NgroR7mp+v9oP4VWcr3MZSJE4Rlk/r8y43mkvkWU9Hf7ZlcJz5alO6yH0cP1t0Zbrln/VOcsWhLjlMIWKQ25Puf5arddGovlMrB0ekdxE3Bxzbbm3LayGCa6HoNozbFDNDx3FgIq3TknOXR/8x+vzDABYxdaWU6tTY1Kc/FhMvt961wmvqwdldF+KrfWX2Bz2yj/LWK9m5ZlJgTczr7sbvlAzaN46KnFbN+0cDNONw==
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=T8nPofpxazoCxEYwpzGMgVEbLO3KBjjKiS7lZ9jpSZU=;
 b=xBjC9FTDT5yyWqiKcx58kQKbU5cVTbzihUsLm5cgJ9d7PMPXaji9J3SbimADBqU1ZRbfS8JD2dE1T+BnMAycnd7hiuIaMtw6AbmvGIi8LVpEwsVKZIrLTvWsJ5B97mIf7cSDo8PLrQ0Chpk/9IMXHulxv6o0T+1Pnc5GPKscG8o=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , "Daniel P. Smith"
	
Subject: [PATCH v2 08/15] xen/dt: Move bootfdt functions to xen/bootfdt.h
Date: Thu, 5 Jun 2025 21:48:00 +0200
Message-ID: <20250605194810.2782031-9-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250605194810.2782031-1-agarciav@amd.com>
References: <20250605194810.2782031-1-agarciav@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: BN2PEPF000055DE:EE_|LV3PR12MB9119:EE_
X-MS-Office365-Filtering-Correlation-Id: 63b0f128-3582-4ff5-ac98-08dda46a02b0
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?xi+rJG6pTly3bY9yCINgvBFSuDZ7PqTXwyfnuWRLDB15yR1ymUtqnV6k3BCB?=
 =?us-ascii?Q?OgF2ID6EZuZPWwDiOogy8FOgkoa7naA1uk/Oje3uBYsBET7wvm7ZB3Q0HvsN?=
 =?us-ascii?Q?Zht/Z6HbCF2lc1wXRKljGNAVj+z+oyRWKeR1q2ZHHoeE6ltKQI7rB5Ug1uFi?=
 =?us-ascii?Q?hHvZ2g2x0LoPQBesznEy2J/iA5H3qi9/t3Impicg9dNwkVDPVsJwPc4t8Vxr?=
 =?us-ascii?Q?kKgZftfpGPJTDSXjnf/AHiV/lnqR7NmLBqw/iayYGb+Qv+qcM8cHtqKvE2RQ?=
 =?us-ascii?Q?0z7eZo8NnDB41CfaLBu1kMHylFTI45gmAIH80Ic5bYLODRtFgmhGbZ76RFv0?=
 =?us-ascii?Q?YGzMn5QvwiAwleu5Ld9ihSAfRTGcV+QL2/stgkJmUqo2MExOO3LglGuMi+7c?=
 =?us-ascii?Q?yUSr5897OoJ/ARq8kJt/XrOVjlrm2iV+VT2TZeoJOzFHTnwbqThV3ubBBosc?=
 =?us-ascii?Q?05DJiyGhltZrFJd507yXJ4w3ZwhCLOBRM9Hk4JNiEMHxED56vgEgkbihuLll?=
 =?us-ascii?Q?Q4CicGhulV+cqmW2PUWAKlMUMHYfbGxQW38NlmDgQDZusoyEc0tL8BFzBGOk?=
 =?us-ascii?Q?Fz+eluGFdx32VVHTbXNFrwSsSQCoJRqEvzve8njNKJQA/3Ar3EQSrJQgARKF?=
 =?us-ascii?Q?JPGupBW63ypLjEiQZ2SvjqjH6NGrQoLREpnMj4GEA7fvbE7vvk0tbFETFbvx?=
 =?us-ascii?Q?8UnTMvcyHdOiEkT8icMz4LZR3sHUlEthK3d6EC5uzU+LuScI76XxGCTUNzsM?=
 =?us-ascii?Q?GevsYGzDKtuRiWPlSkEiw+A9J970mhAdKmk6a3xCavMG2wZ5OE/OVq3FVv+7?=
 =?us-ascii?Q?0xEhlduBgZdgdoiYQmKYgk2gtrmiV5pmcLzR9k7PdwHDgSr5ZYKZIx8MkX2J?=
 =?us-ascii?Q?nfT6BsYer650b9ywoMKDAJ5kvkwcnMmvunVwDpHDEf9Pn5E7+t5UCrfoX3Bs?=
 =?us-ascii?Q?ckmNUHTRphOufuuE/Q8Xn7xvMEqs27q5eDNUDTthvHOv3eZ7x/iHTPry549P?=
 =?us-ascii?Q?8zGUsy4U8w5KnQPTuMRjQ70xXzBECeMrvAFwRepuITTJACF1FTe9TMZcnDz7?=
 =?us-ascii?Q?at7WJr3p2VC81Aq7+7WhedXXSfTIfeV1F8xlkYJKZPU5Usgz2atz7uG2qVxR?=
 =?us-ascii?Q?obzgdlEhyCaEqd73eG9IW71c5FtKPOP/qL3x69iOM/k7gtc28EI/+aZyrymS?=
 =?us-ascii?Q?pbr6F/rVBwKtqvFQlW/XXjxCxDC8jTaXR7OSZYHQZO9H/RGVQvkaqgRZqhCK?=
 =?us-ascii?Q?zDypRJ1kCo+xvxCgHqPykYHhBSRkwVCKEjtOZz8bNcCmTtLtATWl1nd/YZZ0?=
 =?us-ascii?Q?nOiuEC76Ouyob8LDDgh7cpN6eG8Z7EMXtVTIKZNBpDIUWcVirbYB63l7VV+3?=
 =?us-ascii?Q?3/BgzFV9IXSFUacSFvdeXZXBjavqUoAukmHnkm+wbjAH0q1IqJ8XXnUgC5Ux?=
 =?us-ascii?Q?Fh0FZdVq2BFUT7hleb88I4yBQn/r7s69PBUtdAVD5werqpszZ2r5MLTromV7?=
 =?us-ascii?Q?+AbdHT0GRCqAoGHTOJxkLB1NXh9P2vQRgSE0?=
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 Jun 2025 19:48:57.4665
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 63b0f128-3582-4ff5-ac98-08dda46a02b0
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:
	BN2PEPF000055DE.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR12MB9119

Part of an unpicking process to extract bootfdt contents independent of bootinfo
to a separate file for x86 to take.

Move functions required for early FDT parsing from device_tree.h and arm's
setup.h onto bootfdt.h

Declaration motion only. Not a functional change.

Signed-off-by: Alejandro Vallejo 
---
v2:
  * Remove the u32 identifiers in the device_tree_get_u32() implementation
  * Fix an existing const-stripping case.
---
 xen/arch/arm/include/asm/setup.h |  6 ----
 xen/common/device-tree/bootfdt.c |  8 ++---
 xen/include/xen/bootfdt.h        | 62 ++++++++++++++++++++++++++++++++
 xen/include/xen/device_tree.h    | 34 +-----------------
 4 files changed, 67 insertions(+), 43 deletions(-)

diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
index 6cf272c160..2b58549c1a 100644
--- a/xen/arch/arm/include/asm/setup.h
+++ b/xen/arch/arm/include/asm/setup.h
@@ -53,12 +53,6 @@ void setup_mm(void);
 extern uint32_t hyp_traps_vector[];
 void init_traps(void);
 
-void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
-                         uint32_t size_cells, paddr_t *start, paddr_t *size);
-
-u32 device_tree_get_u32(const void *fdt, int node,
-                        const char *prop_name, u32 dflt);
-
 int handle_device(struct domain *d, struct dt_device_node *dev, p2m_type_t p2mt,
                   struct rangeset *iomem_ranges, struct rangeset *irq_ranges);
 
diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
index 9daea06e57..ab449db8d6 100644
--- a/xen/common/device-tree/bootfdt.c
+++ b/xen/common/device-tree/bootfdt.c
@@ -202,16 +202,16 @@ static int __init device_tree_get_meminfo(const void *fdt, int node,
     return 0;
 }
 
-u32 __init device_tree_get_u32(const void *fdt, int node,
-                               const char *prop_name, u32 dflt)
+uint32_t __init device_tree_get_u32(const void *fdt, int node,
+                                    const char *prop_name, uint32_t dflt)
 {
     const struct fdt_property *prop;
 
     prop = fdt_get_property(fdt, node, prop_name, NULL);
-    if ( !prop || prop->len < sizeof(u32) )
+    if ( !prop || prop->len < sizeof(uint32_t) )
         return dflt;
 
-    return fdt32_to_cpu(*(uint32_t*)prop->data);
+    return fdt32_to_cpu(*(const uint32_t*)prop->data);
 }
 
 /**
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index 19d2ff0f0c..1b89986e10 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -2,6 +2,7 @@
 #ifndef XEN_BOOTFDT_H
 #define XEN_BOOTFDT_H
 
+#include 
 #include 
 #include 
 #include 
@@ -16,8 +17,53 @@
 #define NR_MEM_BANKS 256
 #define NR_SHMEM_BANKS 32
 
+/* Default #address and #size cells */
+#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
+#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
+
 #define MAX_MODULES 32 /* Current maximum useful modules */
 
+#define DEVICE_TREE_MAX_DEPTH 16
+
+/* Helper to read a big number; size is in cells (not bytes) */
+static inline u64 dt_read_number(const __be32 *cell, int size)
+{
+    u64 r = 0;
+
+    while ( size-- )
+        r = (r << 32) | be32_to_cpu(*(cell++));
+    return r;
+}
+
+static inline u64 dt_next_cell(int s, const __be32 **cellp)
+{
+    const __be32 *p = *cellp;
+
+    *cellp = p + s;
+    return dt_read_number(p, s);
+}
+
+typedef int (*device_tree_node_func)(const void *fdt,
+                                     int node, const char *name, int depth,
+                                     u32 address_cells, u32 size_cells,
+                                     void *data);
+
+/**
+ * device_tree_for_each_node - iterate over all device tree sub-nodes
+ * @fdt: flat device tree.
+ * @node: parent node to start the search from
+ * @func: function to call for each sub-node.
+ * @data: data to pass to @func.
+ *
+ * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
+ *
+ * Returns 0 if all nodes were iterated over successfully.  If @func
+ * returns a value different from 0, that value is returned immediately.
+ */
+int device_tree_for_each_node(const void *fdt, int node,
+                              device_tree_node_func func,
+                              void *data);
+
 typedef enum {
     BOOTMOD_XEN,
     BOOTMOD_FDT,
@@ -261,4 +307,20 @@ static inline struct membanks *membanks_xzalloc(unsigned int nr,
     return banks;
 }
 
+/*
+ * Interpret the property `prop_name` of `node` as a u32.
+ *
+ * Returns the property value on success; otherwise returns `dflt`.
+ */
+uint32_t device_tree_get_u32(const void *fdt, int node,
+                             const char *prop_name, uint32_t dflt);
+
+/*
+ * Interpret the property `prop_name` of `node` as a "reg".
+ *
+ * Returns outputs in `start` and `size`.
+ */
+void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
+                         uint32_t size_cells, paddr_t *start, paddr_t *size);
+
 #endif /* XEN_BOOTFDT_H */
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 6dc1fb5159..0a22b1ba1d 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -10,6 +10,7 @@
 #ifndef __XEN_DEVICE_TREE_H__
 #define __XEN_DEVICE_TREE_H__
 
+#include 
 #include 
 
 #include 
@@ -22,8 +23,6 @@
 #include 
 #include 
 
-#define DEVICE_TREE_MAX_DEPTH 16
-
 /*
  * Struct used for matching a device
  */
@@ -164,17 +163,8 @@ struct dt_raw_irq {
     u32 specifier[DT_MAX_IRQ_SPEC];
 };
 
-typedef int (*device_tree_node_func)(const void *fdt,
-                                     int node, const char *name, int depth,
-                                     u32 address_cells, u32 size_cells,
-                                     void *data);
-
 extern const void *device_tree_flattened;
 
-int device_tree_for_each_node(const void *fdt, int node,
-                              device_tree_node_func func,
-                              void *data);
-
 /**
  * dt_unflatten_host_device_tree - Unflatten the host device tree
  *
@@ -245,10 +235,6 @@ void intc_dt_preinit(void);
 #define dt_node_cmp(s1, s2) strcasecmp((s1), (s2))
 #define dt_compat_cmp(s1, s2) strcasecmp((s1), (s2))
 
-/* Default #address and #size cells */
-#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
-#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
-
 #define dt_for_each_property_node(dn, pp)                   \
     for ( pp = (dn)->properties; (pp) != NULL; pp = (pp)->next )
 
@@ -258,16 +244,6 @@ void intc_dt_preinit(void);
 #define dt_for_each_child_node(dt, dn)                      \
     for ( dn = (dt)->child; (dn) != NULL; dn = (dn)->sibling )
 
-/* Helper to read a big number; size is in cells (not bytes) */
-static inline u64 dt_read_number(const __be32 *cell, int size)
-{
-    u64 r = 0;
-
-    while ( size-- )
-        r = (r << 32) | be32_to_cpu(*(cell++));
-    return r;
-}
-
 /* Wrapper for dt_read_number() to return paddr_t (instead of uint64_t) */
 static inline paddr_t dt_read_paddr(const __be32 *cell, int size)
 {
@@ -307,14 +283,6 @@ static inline int dt_size_to_cells(int bytes)
     return (bytes / sizeof(u32));
 }
 
-static inline u64 dt_next_cell(int s, const __be32 **cellp)
-{
-    const __be32 *p = *cellp;
-
-    *cellp = p + s;
-    return dt_read_number(p, s);
-}
-
 static inline const char *dt_node_full_name(const struct dt_device_node *np)
 {
     return (np && np->full_name) ? np->full_name : "";
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 19:49:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 19:49:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007457.1386777 (Exim 4.92)
	(envelope-from )
	id 1uNGaG-00048F-EA; Thu, 05 Jun 2025 19:49:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007457.1386777; Thu, 05 Jun 2025 19:49:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNGaG-000485-9Z; Thu, 05 Jun 2025 19:49:04 +0000
Received: by outflank-mailman (input) for mailman id 1007457;
 Thu, 05 Jun 2025 19:49: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 1uNGaE-0002tD-0w
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 19:49:02 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on2062d.outbound.protection.outlook.com
 [2a01:111:f403:2417::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 206ed3a3-4246-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 21:49:01 +0200 (CEST)
Received: from LV3P220CA0004.NAMP220.PROD.OUTLOOK.COM (2603:10b6:408:234::16)
 by MN6PR12MB8489.namprd12.prod.outlook.com (2603:10b6:208:474::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.33; Thu, 5 Jun
 2025 19:48:53 +0000
Received: from BN2PEPF000055DE.namprd21.prod.outlook.com
 (2603:10b6:408:234:cafe::33) by LV3P220CA0004.outlook.office365.com
 (2603:10b6:408:234::16) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.31 via Frontend Transport; Thu,
 5 Jun 2025 19:48:53 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN2PEPF000055DE.mail.protection.outlook.com (10.167.245.8) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.2 via Frontend Transport; Thu, 5 Jun 2025 19:48:53 +0000
Received: from xcbagarciav01.xilinx.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, 5 Jun
 2025 14:48:51 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 206ed3a3-4246-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=PFk/ADoRt8dP9SFysFwSwM3oEbcD50z13W2eHrQHoSBawxX1W/Wd+CFQ19gyAm/M9/UDZFUWzJLo9NSBa8UHwyHaHcIR4Wjm+Nu1x6/M8h1aCnyB5645faHfz6ucH+iefdIYO3ZzB113x4XZJwzlDiXeU/Xo0t/AVRoW4p9koidYfDQVYcJUoOC2pEBGBs2NpNFerQFqyw9A4NMhvgUfZcw2ZptP82tYOdrgEREzIKqtFhWz8dFqtuicwEpDg+NdIfL8hhd1tutwCG04Gf+fmR33PM+ASQnrICca6Ms7gjqvO6YPNjRk6xlpkMA4P9EXpIIc5d7qG2KvpJ+qsuC0sQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=23cn4AM6kYMSovW9UaT7nqIuXlTzvgh1AnMLD88KkLo=;
 b=C+skJ8TNtwMirYYF+ypU3ui82he1TFfrn4NtiTKmTLDi4UZpbMvy6lIInSpEW+uafRDuR/k0RqaX35tmze6uET5kvMLx7WklHurh4ZGVI9JuwcP63pm1RwAJ26SGWiLzTsMc47lzaUELx9ZyWehKDiLnUFAzbuCYh93g9o/aKcH11iOOXHmWZL5BPcpi9mIB4/hGfZTMgmLMtbDAiyWHhQdJ9LMvJKRBYQYapYtYjofQF4EpRNw6ft92fDuBLgAdLg2CYdHzUmceNeYJUNyEDzDhIzhhhWMLsQDHPC47NzUXcqOsshEPU4XQPmcPlPJSVsQfRBZ9piqqZ16xa/Ih1Q==
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=23cn4AM6kYMSovW9UaT7nqIuXlTzvgh1AnMLD88KkLo=;
 b=mgce521k67/YHPIr6X0sOa36YL0R6Mk4Em1PigbeplRXTqHYzkkXocKfCNKEjinfGoGcdPoO3KoZJKgL+aybXV0WmLv98qAJ1DJnuQmqxX7QsjxWiMP9VIka8wQJSeHSpCNaJrQ2E6RSBiv/c3Xnk/o6dv4ezcXW5YIDbimjS6g=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , Andrew Cooper
	, Anthony PERARD , "Jan
 Beulich" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, "Daniel P. Smith" 
Subject: [PATCH v2 06/15] xen: Refactor kernel_info to have a header like boot_domain
Date: Thu, 5 Jun 2025 21:47:58 +0200
Message-ID: <20250605194810.2782031-7-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250605194810.2782031-1-agarciav@amd.com>
References: <20250605194810.2782031-1-agarciav@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: BN2PEPF000055DE:EE_|MN6PR12MB8489:EE_
X-MS-Office365-Filtering-Correlation-Id: 2a54ed97-8e85-4b9e-787e-08dda46a008a
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|82310400026|1800799024|376014|7416014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?gW16kUUzrY2ovJQq9PG90457oO9kqszeQ1sohVwQ/ZtkYhkTP3Mkt7nOZUCk?=
 =?us-ascii?Q?ZBrVikQCHsChOcjxdxaq+KuMJPRX9PxsqWN9hmh3v0xta8Jqb6AQvavO7gu+?=
 =?us-ascii?Q?oDE/yNir0Le3ttoL55+W/MYqez3rQa+3vBwn55I2Cviuq67kz57YxVP5tE81?=
 =?us-ascii?Q?TtA04Ce+G5fx5rh69aOaZ50xVwUYtU7gQDMw6rcvTtrEk0kSVIjQKCsFaZBW?=
 =?us-ascii?Q?KujKkV1Iu1h2eVEryu3dN7eWbqCg+KqcdwiZeBuhX8/JxXdbDe14yy4VIfgp?=
 =?us-ascii?Q?o5oD76YjZfk4KIBRaUvccIduTo/Bj1aT+05xmd2gZPeGwmEuQqMbSAmzGLLq?=
 =?us-ascii?Q?vwddWQ0VKV/YRbSXumS964f+TIDL4sUFfaSZJvxYKNtbJVIIUbfKno1dkQqT?=
 =?us-ascii?Q?arg7r+LKSJmJ6r89yrQZrashVmzMzf1KN53ZWArGaFrraN2XbzfeAin7O2sW?=
 =?us-ascii?Q?FZfcDLF6vxNLiHLdPYSVeQIseaJH75I3ASsBQ9XlzCn/U5bPs+p8Py16S0XZ?=
 =?us-ascii?Q?KG+BvL+Zvd0Hntn6QPLgrjDdAs0q4JilGVN3p2WAPnP1hoIPUcOPqsFF2oCc?=
 =?us-ascii?Q?bnxB0gDvu2g8ZeBk+a5dxna1YK3qjyFBe05DF5qavb6+AUnAtChZEHr2xIks?=
 =?us-ascii?Q?cfDGVpLSLtxNQ1NyHAZlOt/eZlkxjxsso8nI9fip1xOcWEL5+GbudcPchgEM?=
 =?us-ascii?Q?eic9UinoCcV4eBoh3t9fPDP3IvEWPAxIywe/9jj5BoNmdqEv6tiM6sa4rNzp?=
 =?us-ascii?Q?kH/tgdSCw5zcmRIO4YrXbI817+u2NEBr4+ndkf7P+gkTXWctHzWEx6pbWo+S?=
 =?us-ascii?Q?XzFicHR6osPffs4d8OK6pPUnQkFGtlpfzKXVX9I5ozXgV5SJYLqPYu5TLAVj?=
 =?us-ascii?Q?DGUMBojrpbfpJPm0K/9Au/85HRZjhMqFEe4MWEbC1L8jSitcfe+FAy5PR3jl?=
 =?us-ascii?Q?+azigVY0pPOrvgd5OEHxXbkSmkIqlI/pmKU5T/+sshBMAAKiRavnhiD9kvJL?=
 =?us-ascii?Q?T4ULfBWxMZE84O5zuhhlsyEBck7a9x9qdfb4sHR7aua1UAk+Q4PHX+wHE0Pi?=
 =?us-ascii?Q?41ju678xgKGMCIew5kI7BtKavCkZgvb9EC9f31Ms1KGfYSkUVU163MNUZcy1?=
 =?us-ascii?Q?rZFL4RA6OEXWLmuZ/8REzBdsmt4CCOXOJnWZhm/LDNDZOXmLgKgWn3BmdQuV?=
 =?us-ascii?Q?vYhrbgKKaITlYL3ZDaNzYKWWzKNZ/KRvOkKwsH7RQp5YiCUx8jltetg8Xdhx?=
 =?us-ascii?Q?BTU3Tdm6B3XKBHirEkJB08f1XgyMzK/aBaPM0I8MteUCWsNMGS208C3Gbd90?=
 =?us-ascii?Q?tfStptflfc/lq/ShFomuOiyGMMI/gf8GgbfINjgECDC0NOi8lWieQGbJ+VPV?=
 =?us-ascii?Q?e0DtWEwlEmNJudoB7eEgJV3133JI8i4ZS0snjcgBb9ddLYwIcs9g5M+nnlWJ?=
 =?us-ascii?Q?3umef+X9j0/owh/Bnn+U0d2Dl6cz4yEJjGwMs2lZPUWElOlGfXN3P7C+o8bR?=
 =?us-ascii?Q?BQKTTdlGZXtVhrWefBA3KBOBdO1d+h94gD75?=
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)(7416014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jun 2025 19:48:53.8628
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 2a54ed97-8e85-4b9e-787e-08dda46a008a
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:
	BN2PEPF000055DE.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN6PR12MB8489

Create a struct header with the contents common to kernel_info and
boot_domain, and define that header in common code. This enables x86 to
use that header as-is.

Not a functional change.

Signed-off-by: Alejandro Vallejo 
---
v2:
  * New patch
---
 xen/arch/arm/dom0less-build.c           |  8 ++++----
 xen/arch/arm/domain_build.c             | 20 ++++++++++----------
 xen/arch/arm/kernel.c                   |  8 ++++----
 xen/common/device-tree/dom0less-build.c | 18 +++++++++---------
 xen/common/device-tree/domain-build.c   | 20 ++++++++++----------
 xen/common/device-tree/kernel.c         | 20 ++++++++++----------
 xen/include/xen/bootfdt.h               | 10 ++++++++++
 xen/include/xen/fdt-kernel.h            |  5 ++---
 8 files changed, 59 insertions(+), 50 deletions(-)

diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index 20aabf6be5..a335551484 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -32,7 +32,7 @@ static int __init make_gicv2_domU_node(struct kernel_info *kinfo)
     int res = 0;
     __be32 reg[(GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS) * 2];
     __be32 *cells;
-    const struct domain *d = kinfo->d;
+    const struct domain *d = kinfo->hdr.d;
 
     res = domain_fdt_begin_node(fdt, "interrupt-controller",
                                 vgic_dist_base(&d->arch.vgic));
@@ -85,7 +85,7 @@ static int __init make_gicv3_domU_node(struct kernel_info *kinfo)
     void *fdt = kinfo->fdt;
     int res = 0;
     __be32 *reg, *cells;
-    const struct domain *d = kinfo->d;
+    const struct domain *d = kinfo->hdr.d;
     unsigned int i, len = 0;
 
     res = domain_fdt_begin_node(fdt, "interrupt-controller",
@@ -152,7 +152,7 @@ static int __init make_gicv3_domU_node(struct kernel_info *kinfo)
 
 int __init make_intc_domU_node(struct kernel_info *kinfo)
 {
-    switch ( kinfo->d->arch.vgic.version )
+    switch ( kinfo->hdr.d->arch.vgic.version )
     {
 #ifdef CONFIG_GICV3
     case GIC_V3:
@@ -175,7 +175,7 @@ static int __init make_vpl011_uart_node(struct kernel_info *kinfo)
     gic_interrupt_t intr;
     __be32 reg[GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS];
     __be32 *cells;
-    struct domain *d = kinfo->d;
+    struct domain *d = kinfo->hdr.d;
 
     res = domain_fdt_begin_node(fdt, "sbsa-uart", d->arch.vpl011.base_addr);
     if ( res )
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 590f38e520..5317665555 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -464,8 +464,8 @@ static int __init write_properties(struct domain *d, struct kernel_info *kinfo,
     int had_dom0_bootargs = 0;
     struct dt_device_node *iommu_node;
 
-    if ( kinfo->cmdline && kinfo->cmdline[0] )
-        bootargs = &kinfo->cmdline[0];
+    if ( kinfo->hdr.cmdline && kinfo->hdr.cmdline[0] )
+        bootargs = &kinfo->hdr.cmdline[0];
 
     /*
      * We always skip the IOMMU device when creating DT for hwdom if there is
@@ -579,7 +579,7 @@ static int __init write_properties(struct domain *d, struct kernel_info *kinfo,
 
     if ( dt_node_path_is_equal(node, "/chosen") )
     {
-        const struct bootmodule *initrd = kinfo->initrd_bootmodule;
+        const struct bootmodule *initrd = kinfo->hdr.initrd;
 
         if ( bootargs )
         {
@@ -1386,7 +1386,7 @@ int __init make_timer_node(const struct kernel_info *kinfo)
     if ( res )
         return res;
 
-    if ( !is_64bit_domain(kinfo->d) )
+    if ( !is_64bit_domain(kinfo->hdr.d) )
         res = fdt_property_string(fdt, "compatible", "arm,armv7-timer");
     else
         res = fdt_property_string(fdt, "compatible", "arm,armv8-timer");
@@ -1398,7 +1398,7 @@ int __init make_timer_node(const struct kernel_info *kinfo)
      * It always exposes an active-low level-sensitive interrupt.
      */
 
-    if ( is_hardware_domain(kinfo->d) )
+    if ( is_hardware_domain(kinfo->hdr.d) )
     {
         irq[TIMER_PHYS_SECURE_PPI] = timer_get_irq(TIMER_PHYS_SECURE_PPI);
         irq[TIMER_PHYS_NONSECURE_PPI] =
@@ -1447,7 +1447,7 @@ int __init make_chosen_node(const struct kernel_info *kinfo)
 {
     int res;
     const char *bootargs = NULL;
-    const struct bootmodule *initrd = kinfo->initrd_bootmodule;
+    const struct bootmodule *initrd = kinfo->hdr.initrd;
     void *fdt = kinfo->fdt;
 
     dt_dprintk("Create chosen node\n");
@@ -1455,9 +1455,9 @@ int __init make_chosen_node(const struct kernel_info *kinfo)
     if ( res )
         return res;
 
-    if ( kinfo->cmdline && kinfo->cmdline[0] )
+    if ( kinfo->hdr.cmdline && kinfo->hdr.cmdline[0] )
     {
-        bootargs = &kinfo->cmdline[0];
+        bootargs = &kinfo->hdr.cmdline[0];
         res = fdt_property(fdt, "bootargs", bootargs, strlen(bootargs) + 1);
         if ( res )
            return res;
@@ -1906,7 +1906,7 @@ static int __init construct_dom0(struct domain *d)
     d->max_pages = dom0_mem >> PAGE_SHIFT;
 
     kinfo.unassigned_mem = dom0_mem;
-    kinfo.d = d;
+    kinfo.hdr.d = d;
 
     rc = kernel_probe(&kinfo, NULL);
     if ( rc < 0 )
@@ -1918,7 +1918,7 @@ static int __init construct_dom0(struct domain *d)
 int __init construct_hwdom(struct kernel_info *kinfo,
                            const struct dt_device_node *node)
 {
-    struct domain *d = kinfo->d;
+    struct domain *d = kinfo->hdr.d;
     int rc;
 
     iommu_hwdom_init(d);
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index cb1efb19e7..0561d60d5a 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -46,7 +46,7 @@ static void __init place_modules(struct kernel_info *info,
                                  paddr_t kernbase, paddr_t kernend)
 {
     /* Align DTB and initrd size to 2Mb. Linux only requires 4 byte alignment */
-    const struct bootmodule *mod = info->initrd_bootmodule;
+    const struct bootmodule *mod = info->hdr.initrd;
     const struct membanks *mem = kernel_info_get_mem(info);
     const paddr_t initrd_len = ROUNDUP(mod ? mod->size : 0, MB(2));
     const paddr_t dtb_len = ROUNDUP(fdt_totalsize(info->fdt), MB(2));
@@ -152,12 +152,12 @@ static void __init kernel_zimage_load(struct kernel_info *info)
 
     kernel = ioremap_wc(paddr, len);
     if ( !kernel )
-        panic("Unable to map the %pd kernel\n", info->d);
+        panic("Unable to map the %pd kernel\n", info->hdr.d);
 
-    rc = copy_to_guest_phys_flush_dcache(info->d, load_addr,
+    rc = copy_to_guest_phys_flush_dcache(info->hdr.d, load_addr,
                                          kernel, len);
     if ( rc != 0 )
-        panic("Unable to copy the kernel in the %pd memory\n", info->d);
+        panic("Unable to copy the kernel in the %pd memory\n", info->hdr.d);
 
     iounmap(kernel);
 }
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
index d5bb1d5d35..809cb3c232 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -168,18 +168,18 @@ static int __init handle_passthrough_prop(struct kernel_info *kinfo,
             return -EINVAL;
         }
 
-        res = iomem_permit_access(kinfo->d, paddr_to_pfn(mstart),
+        res = iomem_permit_access(kinfo->hdr.d, paddr_to_pfn(mstart),
                                   paddr_to_pfn(PAGE_ALIGN(mstart + size - 1)));
         if ( res )
         {
             printk(XENLOG_ERR "Unable to permit to dom%d access to"
                    " 0x%"PRIpaddr" - 0x%"PRIpaddr"\n",
-                   kinfo->d->domain_id,
+                   kinfo->hdr.d->domain_id,
                    mstart & PAGE_MASK, PAGE_ALIGN(mstart + size) - 1);
             return res;
         }
 
-        res = map_regions_p2mt(kinfo->d,
+        res = map_regions_p2mt(kinfo->hdr.d,
                                gaddr_to_gfn(gstart),
                                PFN_DOWN(size),
                                maddr_to_mfn(mstart),
@@ -218,7 +218,7 @@ static int __init handle_passthrough_prop(struct kernel_info *kinfo,
         return -EINVAL;
     }
 
-    res = map_device_irqs_to_domain(kinfo->d, node, true, NULL);
+    res = map_device_irqs_to_domain(kinfo->hdr.d, node, true, NULL);
     if ( res < 0 )
         return res;
 
@@ -230,7 +230,7 @@ static int __init handle_passthrough_prop(struct kernel_info *kinfo,
     if ( xen_force && !dt_device_is_protected(node) )
         return 0;
 
-    return iommu_assign_dt_device(kinfo->d, node);
+    return iommu_assign_dt_device(kinfo->hdr.d, node);
 }
 
 static int __init handle_prop_pfdt(struct kernel_info *kinfo,
@@ -297,14 +297,14 @@ static int __init handle_prop_pfdt(struct kernel_info *kinfo,
                                       address_cells, size_cells);
         if ( res < 0 )
         {
-            printk(XENLOG_ERR "Failed to assign device to %pd\n", kinfo->d);
+            printk(XENLOG_ERR "Failed to assign device to %pd\n", kinfo->hdr.d);
             return res;
         }
     }
     else if ( (xen_path && !xen_reg) || (xen_reg && !xen_path && !xen_force) )
     {
         printk(XENLOG_ERR "xen,reg or xen,path missing for %pd\n",
-               kinfo->d);
+               kinfo->hdr.d);
         return -EINVAL;
     }
 
@@ -607,7 +607,7 @@ static int __init alloc_xenstore_page(struct domain *d)
 
 static int __init alloc_xenstore_params(struct kernel_info *kinfo)
 {
-    struct domain *d = kinfo->d;
+    struct domain *d = kinfo->hdr.d;
     int rc = 0;
 
 #ifdef CONFIG_HVM
@@ -775,7 +775,7 @@ static int __init construct_domU(struct domain *d,
 
     d->max_pages = ((paddr_t)mem * SZ_1K) >> PAGE_SHIFT;
 
-    kinfo.d = d;
+    kinfo.hdr.d = d;
 
     rc = kernel_probe(&kinfo, node);
     if ( rc < 0 )
diff --git a/xen/common/device-tree/domain-build.c b/xen/common/device-tree/domain-build.c
index 6b8b8d7cac..e602cb91c9 100644
--- a/xen/common/device-tree/domain-build.c
+++ b/xen/common/device-tree/domain-build.c
@@ -76,7 +76,7 @@ bool __init allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn,
                                  paddr_t tot_size)
 {
     struct membanks *mem = kernel_info_get_mem(kinfo);
-    struct domain *d = kinfo->d;
+    struct domain *d = kinfo->hdr.d;
     struct membank *bank;
 
     /*
@@ -170,7 +170,7 @@ int __init find_unallocated_memory(const struct kernel_info *kinfo,
     unsigned int i, j;
     int res;
 
-    ASSERT(domain_use_host_layout(kinfo->d));
+    ASSERT(domain_use_host_layout(kinfo->hdr.d));
 
     unalloc_mem = rangeset_new(NULL, NULL, 0);
     if ( !unalloc_mem )
@@ -331,23 +331,23 @@ void __init dtb_load(struct kernel_info *kinfo,
     unsigned long left;
 
     printk("Loading %pd DTB to 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
-           kinfo->d, kinfo->dtb_paddr,
+           kinfo->hdr.d, kinfo->dtb_paddr,
            kinfo->dtb_paddr + fdt_totalsize(kinfo->fdt));
 
-    left = copy_to_guest(kinfo->d, kinfo->dtb_paddr,
+    left = copy_to_guest(kinfo->hdr.d, kinfo->dtb_paddr,
                          kinfo->fdt,
                          fdt_totalsize(kinfo->fdt));
 
     if ( left != 0 )
         panic("Unable to copy the DTB to %pd memory (left = %lu bytes)\n",
-              kinfo->d, left);
+              kinfo->hdr.d, left);
     xfree(kinfo->fdt);
 }
 
 void __init initrd_load(struct kernel_info *kinfo,
                         copy_to_guest_phys_cb copy_to_guest)
 {
-    const struct bootmodule *mod = kinfo->initrd_bootmodule;
+    const struct bootmodule *mod = kinfo->hdr.initrd;
     paddr_t load_addr = kinfo->initrd_paddr;
     paddr_t paddr, len;
     int node;
@@ -363,7 +363,7 @@ void __init initrd_load(struct kernel_info *kinfo,
     len = mod->size;
 
     printk("Loading %pd initrd from %"PRIpaddr" to 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
-           kinfo->d, paddr, load_addr, load_addr + len);
+           kinfo->hdr.d, paddr, load_addr, load_addr + len);
 
     /* Fix up linux,initrd-start and linux,initrd-end in /chosen */
     node = fdt_path_offset(kinfo->fdt, "/chosen");
@@ -386,12 +386,12 @@ void __init initrd_load(struct kernel_info *kinfo,
 
     initrd = ioremap_wc(paddr, len);
     if ( !initrd )
-        panic("Unable to map the %pd initrd\n", kinfo->d);
+        panic("Unable to map the %pd initrd\n", kinfo->hdr.d);
 
-    res = copy_to_guest(kinfo->d, load_addr,
+    res = copy_to_guest(kinfo->hdr.d, load_addr,
                         initrd, len);
     if ( res != 0 )
-        panic("Unable to copy the initrd in the %pd memory\n", kinfo->d);
+        panic("Unable to copy the initrd in the %pd memory\n", kinfo->hdr.d);
 
     iounmap(initrd);
 }
diff --git a/xen/common/device-tree/kernel.c b/xen/common/device-tree/kernel.c
index cb04cd9d50..3960f951f7 100644
--- a/xen/common/device-tree/kernel.c
+++ b/xen/common/device-tree/kernel.c
@@ -136,16 +136,16 @@ int __init kernel_probe(struct kernel_info *info,
     /* domain is NULL only for the hardware domain */
     if ( domain == NULL )
     {
-        ASSERT(is_hardware_domain(info->d));
+        ASSERT(is_hardware_domain(info->hdr.d));
 
         mod = boot_module_find_by_kind(BOOTMOD_KERNEL);
 
-        info->kernel_bootmodule = mod;
-        info->initrd_bootmodule = boot_module_find_by_kind(BOOTMOD_RAMDISK);
+        info->hdr.kernel = mod;
+        info->hdr.initrd = boot_module_find_by_kind(BOOTMOD_RAMDISK);
 
         cmd = boot_cmdline_find_by_kind(BOOTMOD_KERNEL);
         if ( cmd )
-            info->cmdline = &cmd->cmdline[0];
+            info->hdr.cmdline = &cmd->cmdline[0];
     }
     else
     {
@@ -162,7 +162,7 @@ int __init kernel_probe(struct kernel_info *info,
                 dt_get_range(&val, node, &kernel_addr, &size);
                 mod = boot_module_find_by_addr_and_kind(
                         BOOTMOD_KERNEL, kernel_addr);
-                info->kernel_bootmodule = mod;
+                info->hdr.kernel = mod;
             }
             else if ( dt_device_is_compatible(node, "multiboot,ramdisk") )
             {
@@ -171,7 +171,7 @@ int __init kernel_probe(struct kernel_info *info,
 
                 val = dt_get_property(node, "reg", &len);
                 dt_get_range(&val, node, &initrd_addr, &size);
-                info->initrd_bootmodule = boot_module_find_by_addr_and_kind(
+                info->hdr.initrd = boot_module_find_by_addr_and_kind(
                         BOOTMOD_RAMDISK, initrd_addr);
             }
             else if ( dt_device_is_compatible(node, "multiboot,device-tree") )
@@ -192,7 +192,7 @@ int __init kernel_probe(struct kernel_info *info,
         name = dt_node_name(domain);
         cmd = boot_cmdline_find_by_name(name);
         if ( cmd )
-            info->cmdline = &cmd->cmdline[0];
+            info->hdr.cmdline = &cmd->cmdline[0];
     }
     if ( !mod || !mod->size )
     {
@@ -201,10 +201,10 @@ int __init kernel_probe(struct kernel_info *info,
     }
 
     printk("Loading %pd kernel from boot module @ %"PRIpaddr"\n",
-           info->d, info->kernel_bootmodule->start);
-    if ( info->initrd_bootmodule )
+           info->hdr.d, info->hdr.kernel->start);
+    if ( info->hdr.initrd )
         printk("Loading ramdisk from boot module @ %"PRIpaddr"\n",
-               info->initrd_bootmodule->start);
+               info->hdr.initrd->start);
 
     /*
      * uImage isn't really used nowadays thereby leave kernel_uimage_probe()
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index 4cab5d5202..e6d52a599f 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -100,6 +100,16 @@ struct shared_meminfo {
     struct shmem_membank_extra extra[NR_SHMEM_BANKS];
 };
 
+
+struct bootdomain {
+    struct domain *d;
+
+    struct bootmodule *kernel;
+    struct bootmodule *initrd;
+
+    const char* cmdline;
+};
+
 /*
  * The domU flag is set for kernels and ramdisks of "xen,domain" nodes.
  * The purpose of the domU flag is to avoid getting confused in
diff --git a/xen/include/xen/fdt-kernel.h b/xen/include/xen/fdt-kernel.h
index 1939c3ebf7..dd009f01d0 100644
--- a/xen/include/xen/fdt-kernel.h
+++ b/xen/include/xen/fdt-kernel.h
@@ -16,7 +16,7 @@
 #endif
 
 struct kernel_info {
-    struct domain *d;
+    struct bootdomain hdr;
 
     void *fdt; /* flat device tree */
     paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
@@ -34,8 +34,7 @@ struct kernel_info {
     paddr_t gnttab_size;
 
     /* boot blob load addresses */
-    const struct bootmodule *kernel_bootmodule, *initrd_bootmodule, *dtb_bootmodule;
-    const char* cmdline;
+    const struct bootmodule *dtb_bootmodule;
     paddr_t dtb_paddr;
     paddr_t initrd_paddr;
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 19:49:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 19:49:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007454.1386741 (Exim 4.92)
	(envelope-from )
	id 1uNGaB-0003A1-7J; Thu, 05 Jun 2025 19:48:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007454.1386741; Thu, 05 Jun 2025 19:48: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 1uNGaB-00039W-1g; Thu, 05 Jun 2025 19:48:59 +0000
Received: by outflank-mailman (input) for mailman id 1007454;
 Thu, 05 Jun 2025 19:48: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 1uNGa9-0002tD-Kb
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 19:48:57 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20624.outbound.protection.outlook.com
 [2a01:111:f403:2408::624])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1d8bcc7f-4246-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 21:48:57 +0200 (CEST)
Received: from BN9P223CA0028.NAMP223.PROD.OUTLOOK.COM (2603:10b6:408:10b::33)
 by SJ2PR12MB7943.namprd12.prod.outlook.com (2603:10b6:a03:4c8::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.32; Thu, 5 Jun
 2025 19:48:51 +0000
Received: from BN2PEPF000055DF.namprd21.prod.outlook.com
 (2603:10b6:408:10b:cafe::94) by BN9P223CA0028.outlook.office365.com
 (2603:10b6:408:10b::33) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.19 via Frontend Transport; Thu,
 5 Jun 2025 19:48:51 +0000
Received: from SATLEXMB04.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.8835.2 via Frontend Transport; Thu, 5 Jun 2025 19:48:51 +0000
Received: from xcbagarciav01.xilinx.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, 5 Jun
 2025 14:48:47 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1d8bcc7f-4246-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=QqttT4haV1WbWrIVWeaTR5v2WtV6e8UNiX3ZkwWYVWsRqPHk5unITK6hMp8a9D6qIRSliKqPgdPtbOh+lPstRDu+jY4dS5c+LpDyw6On1xHnpsrz2RG7uRN+5NI8ANU1oEiiirf4G5KA2anXqX11PoserTcyA8z4k/T+e+top9qQJ7Gp/xKR0gIkQAdQph6PG/a1wxOBnFVWqIhKwGTYqu7QLmo/PJ9pmqN+qdB2UxOoSBO27IdcY0PUw9FR3fHXMw3hmyyyEtbVai70QBDK/aUNIy/Yjg1WbYDq9qgc2czrbruDtE+LuKOcwiIXWH10pH9D809eRDX1hJDnIe7a3w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=3VkYpXY3zUXAOIvQP6YVzVO5MyvNvAMex59q1ydAmDM=;
 b=hA2UYD3tkKBV+RDbOPt5t0tLn/VRNqMjw1ee2OzljljS+u6eSnYmEYrorkZF2eD9gPvD0F6VB3RUez1iUqbBgxsK5XBDiIN7e0B6ekQGgPVw7JpGMwhoJk+q5JqgfcLA00RsFMVmfWQU9y/3Pwg18UxS8WJkNmKUJsy+R3wuRKKpwYwDITUQf2MSaGt10MaJ+ZQOtLhtbsTNTFxmTKpJ2Do2UX8znOm4sSHThDRJkz/VbFFUg5v/iVP8BzpZKvKfkQ/OYXgdQkHhyR26JKN87nXbzgraNSuKfFXYgOT5ZTjn/G7qhTjO7WY1a+mC1RvMWQZr/tYc+Fzcnr/R8VxF4A==
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=3VkYpXY3zUXAOIvQP6YVzVO5MyvNvAMex59q1ydAmDM=;
 b=qTa/i+OeKTw+mQZGuKDuTQ7heGlkuLiiVY0AbCD6971giuPeQ11N5Pghwlan7fOE2dv5FSKnfE1fHJQjNYKU6uRQncxPnH61erUh4O5AbqXk+LklXktj7a/OZPFsMS+B1k8vLnl1pVkhYl7ORnDCHPLiFXP+Tn3dQpdcSETq+rc=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Daniel P.
 Smith" , Stefano Stabellini
	
Subject: [PATCH v2 04/15] x86: Preinitialise all modules to be of kind BOOTMOD_UNKNOWN
Date: Thu, 5 Jun 2025 21:47:56 +0200
Message-ID: <20250605194810.2782031-5-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250605194810.2782031-1-agarciav@amd.com>
References: <20250605194810.2782031-1-agarciav@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: BN2PEPF000055DF:EE_|SJ2PR12MB7943:EE_
X-MS-Office365-Filtering-Correlation-Id: 52aba572-4434-4afe-583a-08dda469fef1
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?yp5qpJdcIurZPS6HYNVgpEw2lXTcfp7HauI44JIG/rdSBKBwxRgYBeyHCbXy?=
 =?us-ascii?Q?C3+FudbaGUw+z23H8iLjWtZKnorLkiHG8Ub0kkyr0acIjtsGZ9fHQn/L565t?=
 =?us-ascii?Q?jQxt00Xyt+tOlO7QNV0FgRJ036YsM8TdDLygsz4x2vJeabq9B/xN3fdlB6tb?=
 =?us-ascii?Q?UK7tLXtMH6xPlHE1NqLiKyRRcCGg4JwNyNoQRkmVqji2q3RK9c9e/t+Sxf9W?=
 =?us-ascii?Q?4QVEqpm6PXGJkgg0FbKy/MozAaRa08ct3kis+X8dlN6GZPLBQQhSEENUlmmz?=
 =?us-ascii?Q?syWVj5jMQd6wOxEMGebMthOIcubT2QCY1osBStIxBhjatNt/uq4fxydctP9V?=
 =?us-ascii?Q?hrhwzv0VioyjWGtlW5xy+N1sBHYLYr6lg7JOt7050YEBlXyM+WS7dvz6R525?=
 =?us-ascii?Q?oBJMwkIaisZMNEtnD/zuF3N3P+Pmsz3dvztv+UA1lPMmNzbIs34uAK1Ekof5?=
 =?us-ascii?Q?XO0fy1rGudLT8ICSnmHeKwXhIS7fyeUUSa0M0zaRZvZWQvHEzvCrYp3pDikX?=
 =?us-ascii?Q?LfCcmvPl8yJmTKfMuX59iDar/0pDAaNpJhq64fxMNyrZ4qe8IcRY9+Ul+bZz?=
 =?us-ascii?Q?oF1YwfTJlevL6SJpUz/+1sB7wqof9/tAxye3JsHCW23KQK3F1oOY6vvMZLPS?=
 =?us-ascii?Q?umksFa7B2aCHIPlA5i9LfyIQtS8wHsZTZpL5WNULa1BoyrjUfWJ/fyDuoEVM?=
 =?us-ascii?Q?GmnK4OmUKmR7uiU/S0FSpK5Wd/o+ZPFReBhK6xxAkZxU72DAxnZse0nZgTOD?=
 =?us-ascii?Q?qciIxEjdUsqj50MPOD3/M8/qLXCg4fOr122Rj+h+k5fKZAPyHGRSm3aB/8gl?=
 =?us-ascii?Q?ZI31R+X324adH8o4zt7oKCZF53GAQvSXnlyvN3H3iTqF1GVfOliNFLXENRwb?=
 =?us-ascii?Q?emkrncY8i8d5yCCvT0sGjZb/IdQon5WfpT+2FpNJTQrpbK6TysXzC+6Ec7WH?=
 =?us-ascii?Q?EvyYFH+9ZrmR58ULDfUw+zXJP68rA+C7DVvxu02i5/XaLUH1RpgcEQDKf5+C?=
 =?us-ascii?Q?PkPoj+vEbfg2caO0qZxYHiM8LEj9rYDE+9sBVCPibwjpA53BZGHw0LkuDZGH?=
 =?us-ascii?Q?f8NaBQ0fys/Xiwz0b/ixMQcLI1kKvUUFSS4ne5/TgnrOjrjiZ35KaZjKQryi?=
 =?us-ascii?Q?pwW27TXm9karSULsHuvHVizzpLT/Og0r6QTEsTwB0P/eRswu1jK89crDkHFd?=
 =?us-ascii?Q?vGGdPfBuW3nymZN2a3tLNJpxlKs5+S/Ui7SKXuH51D0Yw04HHsSAtrZ8dTRf?=
 =?us-ascii?Q?En2evMgaiXcNXe3PQY/KSXf+m9Pw/vyZolR7oiNopjfIj/ncqQqiIeloStvS?=
 =?us-ascii?Q?mTewl72zA2NkpRTemmBDfBYBfe3BauODz1/wINfv/ZEpXBHT2AAf/dWitPQ9?=
 =?us-ascii?Q?mOKReJhANHlYQqtg4J1ofGu6/Tk+bPC3L6QhRtI/S9zoxYT8ZeV9RB3jDTmA?=
 =?us-ascii?Q?4gxgAzh3MqujcIjKkOV0DWs/Vl+LW9Hpo6+PTWRLMy6mYrjMBtWBdNkNJDa/?=
 =?us-ascii?Q?nMiF4R1xyLzTz20ozw6RHE+cGjGd2aJd5UJZ?=
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: 05 Jun 2025 19:48:51.1799
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 52aba572-4434-4afe-583a-08dda469fef1
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:
	BN2PEPF000055DF.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB7943

A later patch removes boot_module and replaces its uses with bootmodule.
The equivalent field for "type" doesn't have BOOTMOD_UNKNOWN as a zero
value, so it must be explicitly set in the static xen_boot_info.

Not a functional change.

Signed-off-by: Alejandro Vallejo 
Reviewed-by: Stefano Stabellini 
---
v2:
  * Add comment stating why mods initialiser isn't off by one.
---
 xen/arch/x86/setup.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 1f5cb67bd0..7d3b30e1db 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -298,6 +298,12 @@ struct boot_info __initdata xen_boot_info = {
     .loader = "unknown",
     .cmdline = "",
     .domains = { [0 ... MAX_NR_BOOTDOMS - 1] = { .domid = DOMID_INVALID } },
+    /*
+     * There's a MAX_NR_BOOTMODS-th entry in the array. It's not off by one.
+     *
+     * The extra entry exists to be able to add the Xen image as a module.
+     */
+    .mods = { [0 ... MAX_NR_BOOTMODS] = { .type = BOOTMOD_UNKNOWN } },
 };
 
 static struct boot_info *__init multiboot_fill_boot_info(
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 19:49:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 19:49:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007455.1386748 (Exim 4.92)
	(envelope-from )
	id 1uNGaB-0003HB-NC; Thu, 05 Jun 2025 19:48:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007455.1386748; Thu, 05 Jun 2025 19:48: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 1uNGaB-0003Fw-HG; Thu, 05 Jun 2025 19:48:59 +0000
Received: by outflank-mailman (input) for mailman id 1007455;
 Thu, 05 Jun 2025 19:48: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 1uNGaA-0002tD-G1
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 19:48:58 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20627.outbound.protection.outlook.com
 [2a01:111:f403:2418::627])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1d204b87-4246-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 21:48:56 +0200 (CEST)
Received: from BN9P223CA0016.NAMP223.PROD.OUTLOOK.COM (2603:10b6:408:10b::21)
 by CYYPR12MB8962.namprd12.prod.outlook.com (2603:10b6:930:c4::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Thu, 5 Jun
 2025 19:48:52 +0000
Received: from BN2PEPF000055DF.namprd21.prod.outlook.com
 (2603:10b6:408:10b:cafe::72) by BN9P223CA0016.outlook.office365.com
 (2603:10b6:408:10b::21) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.35 via Frontend Transport; Thu,
 5 Jun 2025 19:48:52 +0000
Received: from SATLEXMB04.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.8835.2 via Frontend Transport; Thu, 5 Jun 2025 19:48:52 +0000
Received: from xcbagarciav01.xilinx.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, 5 Jun
 2025 14:48:49 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1d204b87-4246-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=CMvqIfYvdfkEPCeyfpGjvm9q6EB+YLZUKiRe5vwswLaX/Jr9rx2pf43APaxJggrQhkJ2JledLgCBKt20EvyqaKt0GQdawabSNCInYfMob13X/dAlvPIImtnpN02inWSuvnKOyrUiFAlqBJXSMAPFx94UrWHGzQcmyv4YQs+TGW/flLlGtu5wDrK1ZS0W3tPJkFyd986dj4eP/sFl1WFQCmpBFu0vScayNa/JBiZpwVRGCxggEuUW9koklO7+p6997s2B1sdzf+jrHUFR+srdqyh0cOJzrtxfUEXw1MXJOk/KtQkPOAzHVWiHs2OmF+1k/fW4yM6rjwH0ZltfnuIGlA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ArwUcGoNTf1o6R567cJORGEFIrUC5cYy26HnoRll94w=;
 b=B8pTMYbyHNnEBw3Mcpqe8h01ohKKRG5gMhpeciQbVQAlAdpOhmwHwZkTJJ6pbUYStjffdyiDoMpt3XdJy5S765i+n+X8rFWWLFRulQoeM3NNHX3mGxOL2a9MUZHCyZqC7EZt8ApP8+JNgxDIQtXBYT5JRp8ghtyOJzrmGfm1AX5Uf8BxKfUw4B2Ou8GF2o88iqqqVntA6bej2q6Ob6mjR0xGvBaKtMHy8NkMxLcY/mopJRBBC45+Y7Tyb/1bqh6e5CR4n4buxIYvLEuPCT5uS2WpWR/G0bxgF19NnJUmHztWw9U4FaY0Cg3Fm8ESzKKxfgijTol9BZ1qMqhHhXb1jA==
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=ArwUcGoNTf1o6R567cJORGEFIrUC5cYy26HnoRll94w=;
 b=VEY2A4i20wScLxvAYIQFhShcCW+qoH++w4VSVvkuGWZAMazPhDaSTJnL+Zgi+yxjLZNASm19OoVDsszhDc7ik9/316P+oYiZ9xYfYpuKNublkf1b6nd/+Jvs8TAwQnstMTRTP1Bi6PIpb0Y84DbQrbsQcVxHRx36rWAym9ldxzY=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Stefano
 Stabellini" , Julien Grall ,
	"Bertrand Marquis" , Michal Orzel
	, "Daniel P. Smith" 
Subject: [PATCH v2 05/15] x86: Replace boot_module with bootmodule
Date: Thu, 5 Jun 2025 21:47:57 +0200
Message-ID: <20250605194810.2782031-6-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250605194810.2782031-1-agarciav@amd.com>
References: <20250605194810.2782031-1-agarciav@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: BN2PEPF000055DF:EE_|CYYPR12MB8962:EE_
X-MS-Office365-Filtering-Correlation-Id: 2b018c87-2db1-4b35-f640-08dda469ff8d
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?GwS9RDJrmdBBt7WiqqAsZH2RCFpXilLJ5nvJcTxXS4rpUbXp44IMr/mZnZTJ?=
 =?us-ascii?Q?+dk5+iT0+YHPcDhKOAy6iyLvI6GOJl/wu6OOz91heptl2soDR/Ajo9pjttWD?=
 =?us-ascii?Q?K4khtSb+o5z7uNN6lQ2EvBYZ2nscLd0C0SRqvN0O60mzPB2giTZo8cB0PBYd?=
 =?us-ascii?Q?lGfyL+3AeQxodZzaCk2FjGDv4J/dEyW9lAsNXttCQvR78CsloGGpa2EiC4oq?=
 =?us-ascii?Q?ye1SYn42zzDfy/kaYm829n6DX0X2hppjjJ1PME6J7iPPc1G5PqBKCh4h/105?=
 =?us-ascii?Q?i6jx67Vx+3mUIoYgcMbIPPhhEDBb8iNjxfdb0jDcjFUjIyr0ZrEP08TGGLIQ?=
 =?us-ascii?Q?X8ZTmcr+N8lYZ7DqMRbFNrLD6sPb1KRoBbdx+5Qw7865MBP8Qtzih4pcXCgU?=
 =?us-ascii?Q?6SvVrOAEaeSsAif/2zi22ZXZQ3Xijm+Ipf3dMQEQhxmrwEH4TGs9bZ1YHX9R?=
 =?us-ascii?Q?EIf4stElQN22+IciP9ZqQ5XlTcRVH3EwU9p7sHu6ITp494awT5SvCw2Z43IE?=
 =?us-ascii?Q?VpJp9Ce7tPc/bOWEAmfXFzU21mJbyCEMPdHTPjWMPbaDWAba8oLarKFbkKAM?=
 =?us-ascii?Q?nuTcuroaDGqP7+Dm66f8K3YU3h0SHWg9sdUby08bU+2VC7+47PkD3kKX/u2C?=
 =?us-ascii?Q?wKRyqfNt8Vkh1dlfljzmV8TcJtbU0jhR2W8vEWFwycm89cC8ixrbD8BraM/m?=
 =?us-ascii?Q?00W1BDV2e9FVbAyylm7h3FWQouGb5UrX3zUQdS0M+RX0MiJrE1jwsuYIfKaQ?=
 =?us-ascii?Q?sViOkNWEC7GZSde1pdmpsmRiT0G8VU/z0X8LUhHqRXN/FN5HxUFiwCnE4Bja?=
 =?us-ascii?Q?15GNdZ9Ab3ZiG4vbbBtKvsDezDQXOqsXQxGESPbPoRl9YyAogzLoNZKQOQ1f?=
 =?us-ascii?Q?Lat+QhC8H8IFn5HDw7Ata4rrBhZsuyw69h6899/m1i0rjQxrCpF7rmAoXE3S?=
 =?us-ascii?Q?1YrS9vurauNikeHu/4c1hXYb2wfuVOvxecfxBx+4nhyjDWiqP00N+LpFKJOO?=
 =?us-ascii?Q?qqpBvsfXk82bQbta3nIdMGO7FPCjdcQZ/znNC87G6vOuBvnvoZx8NyKKyPeA?=
 =?us-ascii?Q?3uSXLpJOiO/6iCzes/p/B0474TP+42JvTrZbysFadHtgYOrYoRFh09ZM7LH8?=
 =?us-ascii?Q?03mu0kax9DLut2Lnc+M5LyqWvH43L2YBmMwZQjn8hDmaQpvSUuV5q3VKtM/1?=
 =?us-ascii?Q?r0nzWB46KJT1Jhyr9Xor+W4Qr4oL78huUD1SGkNlldwC39IpGx8FxV/01BCA?=
 =?us-ascii?Q?daLHd7BKdNdKBlk/dc+FJlgimIhleZivejcxpMNc/bHFgPyNdFE1mxOvjT7L?=
 =?us-ascii?Q?CTp2oOslqN3IPKTYit3APOCAoqkNJfL6pRY32mY/yQKRwrXle6ubyXQCO2LA?=
 =?us-ascii?Q?oL0SHXj+OUvgqM9VEuqu62QcoqYpBiK65KrnrR2GQFGcigtlbjE8QS28a/Ra?=
 =?us-ascii?Q?6HRmCDBhZ4Z/JuU7HAP7zSEVxZ9cnDWwgtnyntRI1Xx3sGxaBvqjbs3WD7b1?=
 =?us-ascii?Q?Eic8k+wiHIUhcIQTWvEXjKOUaMDoQHkaDsV3?=
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: 05 Jun 2025 19:48:52.2074
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 2b018c87-2db1-4b35-f640-08dda469ff8d
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:
	BN2PEPF000055DF.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYYPR12MB8962

These types resemble each other very closely in layout and intent, and
with "struct bootmodule" already in common code it makes perfect sense
to merge them. In order to do so, add an arch-specific area for
x86-specific tidbits.

Signed-off-by: Alejandro Vallejo 
--
v2:
  * Remove spurious fdt_cmdline from the new arch_bootmodule
---
 xen/arch/x86/cpu/microcode/core.c      |  9 ++--
 xen/arch/x86/hvm/dom0_build.c          | 10 ++---
 xen/arch/x86/include/asm/boot-domain.h |  4 +-
 xen/arch/x86/include/asm/bootfdt.h     | 50 ++++++++++++++++++++++
 xen/arch/x86/include/asm/bootinfo.h    | 58 +++-----------------------
 xen/arch/x86/include/asm/setup.h       |  6 +--
 xen/arch/x86/pv/dom0_build.c           |  8 ++--
 xen/arch/x86/setup.c                   | 52 ++++++++++++-----------
 xen/include/xen/bootfdt.h              |  9 ++++
 xen/xsm/xsm_policy.c                   |  4 +-
 10 files changed, 111 insertions(+), 99 deletions(-)
 create mode 100644 xen/arch/x86/include/asm/bootfdt.h

diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c
index 34a94cd25b..0111ef9156 100644
--- a/xen/arch/x86/cpu/microcode/core.c
+++ b/xen/arch/x86/cpu/microcode/core.c
@@ -760,12 +760,11 @@ static int __init early_microcode_load(struct boot_info *bi)
     {
         for ( idx = 0; idx < bi->nr_modules; ++idx )
         {
-            const struct boot_module *bm = &bi->mods[idx];
+            const struct bootmodule *bm = &bi->mods[idx];
             struct cpio_data cd;
 
             /* Search anything unclaimed or likely to be a CPIO archive. */
-            if ( bm->type != BOOTMOD_UNKNOWN &&
-                 bm->type != BOOTMOD_RAMDISK )
+            if ( bm->kind != BOOTMOD_UNKNOWN && bm->kind != BOOTMOD_RAMDISK )
                 continue;
 
             size = bm->size;
@@ -815,12 +814,12 @@ static int __init early_microcode_load(struct boot_info *bi)
             return -ENODEV;
         }
 
-        if ( bi->mods[idx].type != BOOTMOD_UNKNOWN )
+        if ( bi->mods[idx].kind != BOOTMOD_UNKNOWN )
         {
             printk(XENLOG_WARNING "Microcode: Chosen module %d already used\n", idx);
             return -ENODEV;
         }
-        bi->mods[idx].type = BOOTMOD_MICROCODE;
+        bi->mods[idx].kind = BOOTMOD_MICROCODE;
 
         size = bi->mods[idx].size;
         data = bootstrap_map_bm(&bi->mods[idx]);
diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index a038e58c11..96410344a8 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -647,10 +647,10 @@ static int __init pvh_load_kernel(
     const 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->module;
+    struct bootmodule *image = bd->kernel;
+    struct bootmodule *initrd = bd->module;
     void *image_base = bootstrap_map_bm(image);
-    void *image_start = image_base + image->headroom;
+    void *image_start = image_base + image->arch.headroom;
     unsigned long image_len = image->size;
     unsigned long initrd_len = initrd ? initrd->size : 0;
     size_t cmdline_len = bd->cmdline ? strlen(bd->cmdline) + 1 : 0;
@@ -721,9 +721,9 @@ static int __init pvh_load_kernel(
     {
         size_t initrd_space = elf_round_up(&elf, initrd_len);
 
-        if ( initrd->cmdline_pa )
+        if ( initrd->arch.cmdline_pa )
         {
-            initrd_cmdline = __va(initrd->cmdline_pa);
+            initrd_cmdline = __va(initrd->arch.cmdline_pa);
             if ( !*initrd_cmdline )
                 initrd_cmdline = NULL;
         }
diff --git a/xen/arch/x86/include/asm/boot-domain.h b/xen/arch/x86/include/asm/boot-domain.h
index d7c6042e25..242e9c9c2b 100644
--- a/xen/arch/x86/include/asm/boot-domain.h
+++ b/xen/arch/x86/include/asm/boot-domain.h
@@ -13,8 +13,8 @@
 struct boot_domain {
     domid_t domid;
 
-    struct boot_module *kernel;
-    struct boot_module *module;
+    struct bootmodule *kernel;
+    struct bootmodule *module;
     const char *cmdline;
 
     struct domain *d;
diff --git a/xen/arch/x86/include/asm/bootfdt.h b/xen/arch/x86/include/asm/bootfdt.h
new file mode 100644
index 0000000000..2fc705a1cd
--- /dev/null
+++ b/xen/arch/x86/include/asm/bootfdt.h
@@ -0,0 +1,50 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef X86_BOOTFDT_H
+#define X86_BOOTFDT_H
+
+#include 
+
+struct arch_bootmodule
+{
+    /*
+     * Module State Flags:
+     *   relocated:   indicates module has been relocated in memory.
+     *   released:    indicates module's pages have been freed.
+     */
+    bool relocated:1;
+    bool released:1;
+
+    /*
+     * A boot module may need decompressing by Xen.  Headroom is an estimate of
+     * the additional space required to decompress the module.
+     *
+     * Headroom is accounted for at the start of the module.  Decompressing is
+     * done in-place with input=start, output=start-headroom, expecting the
+     * pointers to become equal (give or take some rounding) when decompression
+     * is complete.
+     *
+     * Memory layout at boot:
+     *
+     *               start ----+
+     *                         v
+     *   |<-----headroom------>|<------size------->|
+     *                         +-------------------+
+     *                         | Compressed Module |
+     *   +---------------------+-------------------+
+     *   |           Decompressed Module           |
+     *   +-----------------------------------------+
+     */
+    unsigned long headroom;
+    paddr_t cmdline_pa;
+};
+
+#endif /* X86_BOOTFDT_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/bootinfo.h b/xen/arch/x86/include/asm/bootinfo.h
index 3afc214c17..f3210b7d6a 100644
--- a/xen/arch/x86/include/asm/bootinfo.h
+++ b/xen/arch/x86/include/asm/bootinfo.h
@@ -8,6 +8,7 @@
 #ifndef X86_BOOTINFO_H
 #define X86_BOOTINFO_H
 
+#include 
 #include 
 #include 
 #include 
@@ -19,55 +20,6 @@
 /* Max number of boot domains that Xen can construct */
 #define MAX_NR_BOOTDOMS 1
 
-/* Boot module binary type / purpose */
-enum bootmod_type {
-    BOOTMOD_UNKNOWN,
-    BOOTMOD_XEN,
-    BOOTMOD_KERNEL,
-    BOOTMOD_RAMDISK,
-    BOOTMOD_MICROCODE,
-    BOOTMOD_XSM_POLICY,
-};
-
-struct boot_module {
-    enum bootmod_type type;
-
-    /*
-     * Module State Flags:
-     *   relocated: indicates module has been relocated in memory.
-     *   released:  indicates module's pages have been freed.
-     */
-    bool relocated:1;
-    bool released:1;
-
-    /*
-     * A boot module may need decompressing by Xen.  Headroom is an estimate of
-     * the additional space required to decompress the module.
-     *
-     * Headroom is accounted for at the start of the module.  Decompressing is
-     * done in-place with input=start, output=start-headroom, expecting the
-     * pointers to become equal (give or take some rounding) when decompression
-     * is complete.
-     *
-     * Memory layout at boot:
-     *
-     *               start ----+
-     *                         v
-     *   |<-----headroom------>|<------size------->|
-     *                         +-------------------+
-     *                         | Compressed Module |
-     *   +---------------------+-------------------+
-     *   |           Decompressed Module           |
-     *   +-----------------------------------------+
-     */
-    unsigned long headroom;
-
-    paddr_t cmdline_pa;
-
-    paddr_t start;
-    size_t size;
-};
-
 /*
  * Xen internal representation of information provided by the
  * bootloader/environment, or derived from the information.
@@ -81,7 +33,7 @@ struct boot_info {
     size_t memmap_length;
 
     unsigned int nr_modules;
-    struct boot_module mods[MAX_NR_BOOTMODS + 1];
+    struct bootmodule mods[MAX_NR_BOOTMODS + 1];
     struct boot_domain domains[MAX_NR_BOOTDOMS];
 };
 
@@ -94,16 +46,16 @@ struct boot_info {
  *      Failure - a value greater than MAX_NR_BOOTMODS
  */
 static inline unsigned int __init next_boot_module_index(
-    const struct boot_info *bi, enum bootmod_type t, unsigned int start)
+    const struct boot_info *bi, bootmodule_kind k, unsigned int start)
 {
     unsigned int i;
 
-    if ( t == BOOTMOD_XEN )
+    if ( k == BOOTMOD_XEN )
         return bi->nr_modules;
 
     for ( i = start; i < bi->nr_modules; i++ )
     {
-        if ( bi->mods[i].type == t )
+        if ( bi->mods[i].kind == k )
             return i;
     }
 
diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/asm/setup.h
index ac34c69855..c7deaba109 100644
--- a/xen/arch/x86/include/asm/setup.h
+++ b/xen/arch/x86/include/asm/setup.h
@@ -36,11 +36,11 @@ extern struct boot_info xen_boot_info;
 unsigned long initial_images_nrpages(nodeid_t node);
 void free_boot_modules(void);
 
-struct boot_module;
-void *bootstrap_map_bm(const struct boot_module *bm);
+struct bootmodule;
+void *bootstrap_map_bm(const struct bootmodule *bm);
 void bootstrap_unmap(void);
 
-void release_boot_module(struct boot_module *bm);
+void release_boot_module(struct bootmodule *bm);
 
 struct rangeset;
 int remove_xen_ranges(struct rangeset *r);
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index e1b78d47c2..e6c77413f5 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -374,8 +374,8 @@ static int __init dom0_construct(const struct boot_domain *bd)
     struct domain *d = bd->d;
     struct vcpu *v = d->vcpu[0];
 
-    struct boot_module *image = bd->kernel;
-    struct boot_module *initrd = bd->module;
+    struct bootmodule *image = bd->kernel;
+    struct bootmodule *initrd = bd->module;
     void *image_base;
     unsigned long image_len;
     void *image_start;
@@ -422,7 +422,7 @@ static int __init dom0_construct(const struct boot_domain *bd)
 
     image_base = bootstrap_map_bm(image);
     image_len = image->size;
-    image_start = image_base + image->headroom;
+    image_start = image_base + image->arch.headroom;
 
     d->max_pages = ~0U;
 
@@ -659,7 +659,7 @@ static int __init dom0_construct(const struct boot_domain *bd)
              * pages. Tell the boot_module handling that we've freed it, so the
              * memory is left alone.
              */
-            initrd->released = true;
+            initrd->arch.released = true;
         }
 
         iommu_memory_setup(d, "initrd", mfn_to_page(_mfn(initrd_mfn)),
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 7d3b30e1db..e9a70c2c2b 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -303,7 +303,7 @@ struct boot_info __initdata xen_boot_info = {
      *
      * The extra entry exists to be able to add the Xen image as a module.
      */
-    .mods = { [0 ... MAX_NR_BOOTMODS] = { .type = BOOTMOD_UNKNOWN } },
+    .mods = { [0 ... MAX_NR_BOOTMODS] = { .kind = BOOTMOD_UNKNOWN } },
 };
 
 static struct boot_info *__init multiboot_fill_boot_info(
@@ -338,7 +338,7 @@ static struct boot_info *__init multiboot_fill_boot_info(
      */
     for ( i = 0; i < MAX_NR_BOOTMODS && i < bi->nr_modules; i++ )
     {
-        bi->mods[i].cmdline_pa = mods[i].string;
+        bi->mods[i].arch.cmdline_pa = mods[i].string;
 
         if ( efi_enabled(EFI_LOADER) )
         {
@@ -361,7 +361,7 @@ 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;
+    bi->mods[i].kind = BOOTMOD_XEN;
 
     return bi;
 }
@@ -386,13 +386,13 @@ unsigned long __init initial_images_nrpages(nodeid_t node)
     return nr;
 }
 
-void __init release_boot_module(struct boot_module *bm)
+void __init release_boot_module(struct bootmodule *bm)
 {
-    ASSERT(!bm->released);
+    ASSERT(!bm->arch.released);
 
     init_domheap_pages(bm->start, bm->start + PAGE_ALIGN(bm->size));
 
-    bm->released = true;
+    bm->arch.released = true;
 }
 
 void __init free_boot_modules(void)
@@ -402,7 +402,7 @@ void __init free_boot_modules(void)
 
     for ( i = 0; i < bi->nr_modules; ++i )
     {
-        if ( bi->mods[i].released )
+        if ( bi->mods[i].arch.released )
             continue;
 
         release_boot_module(&bi->mods[i]);
@@ -524,7 +524,7 @@ static void *__init bootstrap_map_addr(paddr_t start, paddr_t end)
     return ret;
 }
 
-void *__init bootstrap_map_bm(const struct boot_module *bm)
+void *__init bootstrap_map_bm(const struct bootmodule *bm)
 {
     return bootstrap_map_addr(bm->start, bm->start + bm->size);
 }
@@ -694,7 +694,7 @@ static void __init noinline move_xen(void)
 #undef BOOTSTRAP_MAP_LIMIT
 
 static uint64_t __init consider_modules(
-    uint64_t s, uint64_t e, uint32_t size, const struct boot_module *mods,
+    uint64_t s, uint64_t e, uint32_t size, const struct bootmodule mods[],
     unsigned int nr_mods, unsigned int this_mod)
 {
     unsigned int i;
@@ -990,8 +990,9 @@ static size_t __init domain_cmdline_size(const struct boot_info *bi,
                                          const struct boot_domain *bd)
 {
     size_t s = bi->kextra ? strlen(bi->kextra) : 0;
+    const struct arch_bootmodule *abm = &bd->kernel->arch;
 
-    s += bd->kernel->cmdline_pa ? strlen(__va(bd->kernel->cmdline_pa)) : 0;
+    s += abm->cmdline_pa ? strlen(__va(abm->cmdline_pa)) : 0;
 
     if ( s == 0 )
         return s;
@@ -1055,9 +1056,10 @@ 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->arch.cmdline_pa )
             strlcpy(cmdline,
-                    cmdline_cook(__va(bd->kernel->cmdline_pa), bi->loader),
+                    cmdline_cook(__va(bd->kernel->arch.cmdline_pa),
+                                 bi->loader),
                     cmdline_size);
 
         if ( bi->kextra )
@@ -1079,7 +1081,7 @@ static struct domain *__init create_dom0(struct boot_info *bi)
             strlcat(cmdline, " acpi=", cmdline_size);
             strlcat(cmdline, acpi_param, cmdline_size);
         }
-        bd->kernel->cmdline_pa = 0;
+        bd->kernel->arch.cmdline_pa = 0;
         bd->cmdline = cmdline;
     }
 
@@ -1292,7 +1294,7 @@ void asmlinkage __init noreturn __start_xen(void)
     }
 
     /* Dom0 kernel is always first */
-    bi->mods[0].type = BOOTMOD_KERNEL;
+    bi->mods[0].kind = BOOTMOD_KERNEL;
     bi->domains[0].kernel = &bi->mods[0];
 
     if ( pvh_boot )
@@ -1463,7 +1465,7 @@ void asmlinkage __init noreturn __start_xen(void)
 
     if ( xen_phys_start )
     {
-        struct boot_module *xen = &bi->mods[bi->nr_modules];
+        struct bootmodule *xen = &bi->mods[bi->nr_modules];
 
         relocated = true;
 
@@ -1476,7 +1478,7 @@ void asmlinkage __init noreturn __start_xen(void)
         xen->size  = __2M_rwdata_end - _stext;
     }
 
-    bi->mods[0].headroom =
+    bi->mods[0].arch.headroom =
         bzimage_headroom(bootstrap_map_bm(&bi->mods[0]), bi->mods[0].size);
     bootstrap_unmap();
 
@@ -1557,10 +1559,10 @@ void asmlinkage __init noreturn __start_xen(void)
         /* Is the region suitable for relocating the multiboot modules? */
         for ( j = bi->nr_modules - 1; j >= 0; j-- )
         {
-            struct boot_module *bm = &bi->mods[j];
-            unsigned long size = PAGE_ALIGN(bm->headroom + bm->size);
+            struct bootmodule *bm = &bi->mods[j];
+            unsigned long size = PAGE_ALIGN(bm->arch.headroom + bm->size);
 
-            if ( bm->relocated )
+            if ( bm->arch.relocated )
                 continue;
 
             /* Don't overlap with other modules (or Xen itself). */
@@ -1570,12 +1572,12 @@ void asmlinkage __init noreturn __start_xen(void)
             if ( highmem_start && end > highmem_start )
                 continue;
 
-            if ( s < end && (bm->headroom || (end - size) > bm->start) )
+            if ( s < end && (bm->arch.headroom || (end - size) > bm->start) )
             {
-                move_memory(end - size + bm->headroom, bm->start, bm->size);
+                move_memory(end - size + bm->arch.headroom, bm->start, bm->size);
                 bm->start = (end - size);
-                bm->size += bm->headroom;
-                bm->relocated = true;
+                bm->size += bm->arch.headroom;
+                bm->arch.relocated = true;
             }
         }
 
@@ -1601,7 +1603,7 @@ void asmlinkage __init noreturn __start_xen(void)
 #endif
     }
 
-    if ( bi->mods[0].headroom && !bi->mods[0].relocated )
+    if ( bi->mods[0].arch.headroom && !bi->mods[0].arch.relocated )
         panic("Not enough memory to relocate the dom0 kernel image\n");
     for ( i = 0; i < bi->nr_modules; ++i )
     {
@@ -2159,7 +2161,7 @@ void asmlinkage __init noreturn __start_xen(void)
     initrdidx = first_boot_module_index(bi, BOOTMOD_UNKNOWN);
     if ( initrdidx < MAX_NR_BOOTMODS )
     {
-        bi->mods[initrdidx].type = BOOTMOD_RAMDISK;
+        bi->mods[initrdidx].kind = BOOTMOD_RAMDISK;
         bi->domains[0].module = &bi->mods[initrdidx];
         if ( first_boot_module_index(bi, BOOTMOD_UNKNOWN) < MAX_NR_BOOTMODS )
             printk(XENLOG_WARNING
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index ff40f3078e..4cab5d5202 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -7,6 +7,10 @@
 #include 
 #include 
 
+#if __has_include()
+#include 
+#endif
+
 #define MIN_FDT_ALIGN 8
 
 #define NR_MEM_BANKS 256
@@ -106,8 +110,13 @@ struct shared_meminfo {
 struct bootmodule {
     bootmodule_kind kind;
     bool domU;
+
     paddr_t start;
     paddr_t size;
+
+#if __has_include()
+    struct arch_bootmodule arch;
+#endif
 };
 
 /* DT_MAX_NAME is the node name max length according the DT spec */
diff --git a/xen/xsm/xsm_policy.c b/xen/xsm/xsm_policy.c
index 7f70d860bd..0c2cdea8ed 100644
--- a/xen/xsm/xsm_policy.c
+++ b/xen/xsm/xsm_policy.c
@@ -40,7 +40,7 @@ int __init xsm_multiboot_policy_init(
 
     for_each_boot_module_by_type ( i, bi, BOOTMOD_UNKNOWN )
     {
-        struct boot_module *bm = &bi->mods[i];
+        struct bootmodule *bm = &bi->mods[i];
 
         _policy_start = bootstrap_map_bm(bm);
         _policy_len   = bm->size;
@@ -53,7 +53,7 @@ int __init xsm_multiboot_policy_init(
             printk("Policy len %#lx, start at %p.\n",
                    _policy_len,_policy_start);
 
-            bm->type = BOOTMOD_XSM_POLICY;
+            bm->kind = BOOTMOD_XSM;
             break;
 
         }
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 19:49:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 19:49:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007451.1386716 (Exim 4.92)
	(envelope-from )
	id 1uNGa7-0002fo-He; Thu, 05 Jun 2025 19:48:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007451.1386716; Thu, 05 Jun 2025 19:48: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 1uNGa7-0002fg-DY; Thu, 05 Jun 2025 19:48:55 +0000
Received: by outflank-mailman (input) for mailman id 1007451;
 Thu, 05 Jun 2025 19:48: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 1uNGa5-0002fZ-PB
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 19:48:53 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20609.outbound.protection.outlook.com
 [2a01:111:f403:200a::609])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 18a66b3d-4246-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 21:48:49 +0200 (CEST)
Received: from LV3P220CA0002.NAMP220.PROD.OUTLOOK.COM (2603:10b6:408:234::15)
 by SA1PR12MB8641.namprd12.prod.outlook.com (2603:10b6:806:388::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Thu, 5 Jun
 2025 19:48:42 +0000
Received: from BN2PEPF000055DE.namprd21.prod.outlook.com
 (2603:10b6:408:234:cafe::37) by LV3P220CA0002.outlook.office365.com
 (2603:10b6:408:234::15) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.21 via Frontend Transport; Thu,
 5 Jun 2025 19:48:42 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN2PEPF000055DE.mail.protection.outlook.com (10.167.245.8) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.2 via Frontend Transport; Thu, 5 Jun 2025 19:48:42 +0000
Received: from xcbagarciav01.xilinx.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, 5 Jun
 2025 14:48:39 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 18a66b3d-4246-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=XBWjBNgY4M9GRUmR3rsrSvDNMQoP14COihvCzFmFmDF/q9XYoz/5dbPCeuaJS9Y53ziCafV1VbT1oeu5mkAitQdmQcinF/4SR/2dKExmIhuBUOahJgWIy6X9TC9WXONAsInBqCXlgsofJJ76HPMmu4dydRA/++V7YBPJ7qAo7V6wZ3sJDd50xbnsYYNy4n73jvUxmU+3fmq3c4zr7ee+SdlcmFAgsYqRQ6o/GyS+BPY6NoAHCPg2Q1fM/edMyYuFAjBiS/B/m1E0lZqBFsuFkosIBTIPbhrMBaCzoVKQhAd0/TXnLOPfIT9rdsXOq4UN5rx72BFibwRyqV0Qu4qW2Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=xaUjHWWOa3B7T9r66+7ntRsIWcKccRUyDVFbl5PIyiM=;
 b=oxVlIrjeHleMsAQ+vPbNL8rLySuCa+OxtxsIy6F1Pavsth8SzuGY+aCbw7YNB9wPYgW1TbAll4QOah18BQM9NXERW6S4M7E+sgAVwj3gShRgw9+rASqwPvaVSVMqYbN+PDtUoOU4Mu8WqtLJuU8SyPbncr2fFPU+FpToO5cEkYgwxAocN1njxSl0VA49bViVWN1C0HimhWJQM4FZ5wZA1WU+uzt9i7/ds6z1BCTbsH3shgauXnnVsEFwb+oucErE+4fnGbQsTW8LC3JYO/N12L8v53dbDLcJjU5lq0rLGllRb7mnLbvqKx5YT/VLOufs9l5CgnQGfbPlHvf9vG7wCA==
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=xaUjHWWOa3B7T9r66+7ntRsIWcKccRUyDVFbl5PIyiM=;
 b=eTATmw3zdLU77N7ELl+3HxHTXvGO7+9fvldQVyUGMmIwkI4gSalYwOXZCRkzti2BR6pVQpvurN56nYYEvjPrJb8Y9EfjaAApr++1FlNFbuZuDKRS7DO5s9UaGhCdStaHYHYhuVyZEsuhjYSvr8Se9ut7bellBkJ0qZatKf1ve4Y=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Alistair Francis
	, Bob Eshleman , "Connor
 Davis" , Oleksii Kurochko
	, Andrew Cooper ,
	Anthony PERARD , Michal Orzel
	, Jan Beulich , Julien Grall
	, =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, "Stefano Stabellini" ,
	Bertrand Marquis , Volodymyr Babchuk
	, "Daniel P. Smith"
	
Subject: [PATCH v2 00/15] Allow x86 to unflatten DTs
Date: Thu, 5 Jun 2025 21:47:52 +0200
Message-ID: <20250605194810.2782031-1-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: 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: BN2PEPF000055DE:EE_|SA1PR12MB8641:EE_
X-MS-Office365-Filtering-Correlation-Id: a05de07d-d94f-4ef8-d4bd-08dda469f99c
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|7416014|376014|1800799024|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?/7p1Wv+Xks2w0w6Oe5vOG5myXoGz65G6ZtYpKI1fgYTwvZRY+PHTPhAfd7Qc?=
 =?us-ascii?Q?wdRg7BsDPz5w+TSksao8/EabJOohYVsqEXN5oSjfy/7hX9hEHkONm82ZpFf+?=
 =?us-ascii?Q?eZi3QqkHXtITPDmQRqDewhsDL70Vrr+Gj8JhYGu7bOkr7LaZjYF9BEst4R5p?=
 =?us-ascii?Q?dAt2XZSoLJS+gi+2j6hBdG44ucDv3L0VjxzMNeIXrBusWyJnlsKoWHdut/FB?=
 =?us-ascii?Q?/paNMorVk84cQE9QGfhWuho8Zp1tdPq1muLc/KO7Ygg79ZqNbXkHVpercHqn?=
 =?us-ascii?Q?wiCI5eU7hKzDIY3d+W/uxWbqEFtmOK6c15QuyR7xVfXQfWh8NrFzE3otua/l?=
 =?us-ascii?Q?NjTbupWrjlTkvtoPrzBF92o85ksIw/KmSwLz6Ta/LByQXlfoLGlSJ3QQ/Axj?=
 =?us-ascii?Q?jVPg7J53dXOf1QLuVYrCriFbhJ0a1q5O1vB9IG1S7p9jKhm4Thf990RicR1A?=
 =?us-ascii?Q?yf66GT/22llktO9B7gKQ8gmM+JN5q9kCZvNm812VV70U1Cd39eioRBRwuYgN?=
 =?us-ascii?Q?wokNIM8rMxXcz5HAQ4Il/tUXMhVvmC5MnO0Pf1/3C7OhEajNcIGNa2PSP68R?=
 =?us-ascii?Q?x/WHgmaWOY+qHfZdILtwR26iKU0RAi9gHio+73vUQjavGTV4NbXsRU7LEos9?=
 =?us-ascii?Q?duBjVI/5/2FkCgyopo9Wzf4JYpso9GYeeI1xHGSFEGNWhfO4RRxZJ8BO65qr?=
 =?us-ascii?Q?WSE87scS7zE7dvDrXGmgD9DHU5l9cwgwhHblQoNLp03y7/90I1ItEDTq6Y37?=
 =?us-ascii?Q?sZPtsp1J62hI3xPW+Yz20QmRnn4FBc5sJGOJZ1e3L2T2uTaqi8CVnHxfvrfY?=
 =?us-ascii?Q?ZFJCPfPSETJz/m605nZukejypiI3wIm9TIBWl5flKIc+UMzcH0VrXdStYoEr?=
 =?us-ascii?Q?OjbsfZoggX29qel1gTFk6P8jyr4EFdkcAbjU4Qf4PAEv0mQfOCIpjatWOEes?=
 =?us-ascii?Q?wh8yprnzs/7ABW/rB6wHcwAM3Ok8FJRBfh3cJ69BvavCX8nvkVtzblIw8tnv?=
 =?us-ascii?Q?/MVc//rYY3UZsFt0gw/gUB2fawyk9GyJSA0vXY2fpkIUGY2bOD6JEv7+wqhz?=
 =?us-ascii?Q?J0SyQx+ciaoEwDxPmmTVqQBlwEK84TrIzups2IVvW6b1DBm9R0kmjcGIXsJ1?=
 =?us-ascii?Q?Jz9hPZwS3WRB2jIXLAP4JCBOT9ik2iq5ms5C8Kk1aSxxElvA9iz2wKGka+9x?=
 =?us-ascii?Q?hk5ZcZE3kBe/sXtpPh4FQu9GtA8hX48QLMtZ353dvxjax1VQ/XxH9VNoObzI?=
 =?us-ascii?Q?jo843yGpgFK7OnA4lrsQEd4wUOsLzseQTpeceXqf9VHd5jL1xRIW8kpB8Hcf?=
 =?us-ascii?Q?PSxeoVDZWycobptIgj6bXfURRM5owu//SkHAzGlivXP21OCNfmEz10Y9UUfu?=
 =?us-ascii?Q?yBSNGdSTjma9ZJ0RQk63rnXePzAdQdTgjSgSKYbNGHY7PWnwOFGKFAJjbH+U?=
 =?us-ascii?Q?DNdImNT23VfA7EtFX2Q54UpKKYQOMHnSO4+2t02HPDF3vB8SUD38ZQ=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)(7416014)(376014)(1800799024)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jun 2025 19:48:42.2334
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: a05de07d-d94f-4ef8-d4bd-08dda469f99c
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:
	BN2PEPF000055DE.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB8641

v2 pipeline: https://gitlab.com/xen-project/people/agvallejo/xen/-/pipelines/1855777776

v1: https://lore.kernel.org/xen-devel/20250530120242.39398-1-agarciav@amd.com/

Original cover letter:

This is the aftermath of this discussion:

  https://lore.kernel.org/xen-devel/DA1WWRUQLCAG.ZTVR1HXJ85V0@amd.com/https://lore.kernel.org/xen-devel/DA1WWRUQLCAG.ZTVR1HXJ85V0@amd.com/

It's a first round of cleanup and preparation to have a much easier time
later when integrating dom0less boot into hyperlaunch.

The refactor on device-tree/ is _fine_ by I'm open to other suggestions
to achieve the same thing. In particular, after this series x86 can
unflatten the DT host device tree when it has CONFIG_DOM0LESS_BOOT set,
which enables the builder to use factored-out functions from
dom0less-build.c (not done here).

The diffstat is deceptive because I renamed a large file and then
created a new file with the same name. There aren't that many LoC
changes.

Alejandro Vallejo (15):
  xen: Clean up asm-generic/device.h
  arm/gnttab: Break links between asm/grant_table.h and
    xen/grant_table.h
  xen/dt: Add BOOTMOD_MICROCODE
  x86: Preinitialise all modules to be of kind BOOTMOD_UNKNOWN
  x86: Replace boot_module with bootmodule
  xen: Refactor kernel_info to have a header like boot_domain
  x86: Replace boot_domain with bootdomain
  xen/dt: Move bootfdt functions to xen/bootfdt.h
  xen/dt: Move bootinfo functions to a new bootinfo.h
  xen/dt: Rename bootfdt.c -> bootinfo-fdt.c
  xen/dt: Move bootinfo-independent helpers out of bootinfo-fdt.c
  xen/dt: Extract helper to map nodes to module kinds
  xen/dt: ifdef out DEV_DT-related bits from device_tree.{c,h}
  xen/dt: Allow CONFIG_DOM0LESS_BOOT to include device-tree/
  kconfig: Allow x86 to pick CONFIG_DOM0LESS_BOOT

 xen/arch/arm/dom0less-build.c           |   8 +-
 xen/arch/arm/domain_build.c             |  21 +-
 xen/arch/arm/include/asm/grant_table.h  |   1 -
 xen/arch/arm/include/asm/setup.h        |   6 -
 xen/arch/arm/kernel.c                   |   8 +-
 xen/arch/arm/mmu/mm.c                   |   1 +
 xen/arch/arm/setup.c                    |   1 +
 xen/arch/riscv/aplic.c                  |   3 +-
 xen/arch/riscv/mm.c                     |   2 +-
 xen/arch/riscv/setup.c                  |   2 +-
 xen/arch/x86/Kconfig                    |   1 +
 xen/arch/x86/cpu/microcode/core.c       |   9 +-
 xen/arch/x86/dom0_build.c               |   2 +-
 xen/arch/x86/hvm/dom0_build.c           |  14 +-
 xen/arch/x86/include/asm/boot-domain.h  |  33 --
 xen/arch/x86/include/asm/bootfdt.h      |  57 ++
 xen/arch/x86/include/asm/bootinfo.h     |  61 +--
 xen/arch/x86/include/asm/dom0_build.h   |   6 +-
 xen/arch/x86/include/asm/setup.h        |  10 +-
 xen/arch/x86/pv/dom0_build.c            |  12 +-
 xen/arch/x86/setup.c                    |  72 +--
 xen/common/Kconfig                      |  13 +-
 xen/common/Makefile                     |   2 +-
 xen/common/device-tree/Makefile         |   9 +-
 xen/common/device-tree/bootfdt.c        | 666 ++----------------------
 xen/common/device-tree/bootinfo-fdt.c   | 583 +++++++++++++++++++++
 xen/common/device-tree/bootinfo.c       |   3 +-
 xen/common/device-tree/device-tree.c    |   2 +
 xen/common/device-tree/dom0less-build.c |  21 +-
 xen/common/device-tree/domain-build.c   |  22 +-
 xen/common/device-tree/kernel.c         |  22 +-
 xen/common/grant_table.c                |   2 +
 xen/include/asm-generic/device.h        |  26 +-
 xen/include/xen/bootfdt.h               | 273 +++-------
 xen/include/xen/bootinfo.h              | 213 ++++++++
 xen/include/xen/device_tree.h           |  38 +-
 xen/include/xen/fdt-domain-build.h      |   2 +-
 xen/include/xen/fdt-kernel.h            |   7 +-
 xen/include/xen/grant_table.h           |   4 -
 xen/xsm/xsm_policy.c                    |   4 +-
 40 files changed, 1146 insertions(+), 1096 deletions(-)
 delete mode 100644 xen/arch/x86/include/asm/boot-domain.h
 create mode 100644 xen/arch/x86/include/asm/bootfdt.h
 create mode 100644 xen/common/device-tree/bootinfo-fdt.c
 create mode 100644 xen/include/xen/bootinfo.h

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 19:49:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 19:49:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007468.1386807 (Exim 4.92)
	(envelope-from )
	id 1uNGaP-0005WO-Sr; Thu, 05 Jun 2025 19:49:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007468.1386807; Thu, 05 Jun 2025 19:49: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 1uNGaP-0005W6-NH; Thu, 05 Jun 2025 19:49:13 +0000
Received: by outflank-mailman (input) for mailman id 1007468;
 Thu, 05 Jun 2025 19:49: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 1uNGaP-0002tD-2D
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 19:49:13 +0000
Received: from NAM04-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam04on2061e.outbound.protection.outlook.com
 [2a01:111:f403:2409::61e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 26b1802c-4246-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 21:49:12 +0200 (CEST)
Received: from BL1PR13CA0134.namprd13.prod.outlook.com (2603:10b6:208:2bb::19)
 by SN7PR12MB6932.namprd12.prod.outlook.com (2603:10b6:806:260::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Thu, 5 Jun
 2025 19:49:09 +0000
Received: from BN2PEPF000055DB.namprd21.prod.outlook.com
 (2603:10b6:208:2bb:cafe::c7) 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.8835.10 via Frontend Transport; Thu,
 5 Jun 2025 19:49:09 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN2PEPF000055DB.mail.protection.outlook.com (10.167.245.5) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.2 via Frontend Transport; Thu, 5 Jun 2025 19:49:08 +0000
Received: from xcbagarciav01.xilinx.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, 5 Jun
 2025 14:49:00 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 26b1802c-4246-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=JIe7tuAnxcM7EPDHGGEpLsAy4MMIvrNU5390kH1ikzk5J9OOxmgzwq7ooklboA1qluxUKF0SKPRnm+vRNvnKXaaMquECKwFavMKkn5oWTa3cxizE59HDEr1EBbnFKb9lAes/0nJP2B2r9t7oIPY7wcl6NGmKdK/SBr5aLDRA3xZdk9hE5+64S2sz0d7oZGK2uilFXmvjBXYoE1mI5nmXkPq43JadZi2S0VSFPFGiRIon81nNULslDupRe/EVvSd8omJHGYassr6VtFjePkGgi2LJ6/7n6+d1bgfELhxYxRk3CH7yGhAHzxbgBdyANBXr/nZFXntchlSGM5sT22evZQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=xcW3d8L8LfyXlkpJp/idqPtEvoD18OvPCNwy0JjhwWc=;
 b=dKQz6V5l4WkCnKp5YgEukdy880MzQ1N/TQkD1hwbXcA7/M/pisgsXzZj3niTOIhnyDtDCmAeG7BI4Vkr0kI8206chGr8et2X7ZqrDcJ9Ph5ShPWrpNY0zwUA46eknM0omOSFU+Gjkcq7Ga/Bc6qdYNdDJHtv4ofBSkkayfHguovKbRB12Eppx6O8pzAJPb0DKzY00BtfJx8fAU6oOlFixPNwk+RAt/bvtjFytR7gCW24pDVgv5Q9ap44Us1xOiZ/Q4y5qIe4b94ADBThEw1aLj3DuPOXNjE8KqktWCaFDbCezZKynS2fglIKsuDofmvQ0IKr10d6Dr5zqvbdLUAezg==
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=xcW3d8L8LfyXlkpJp/idqPtEvoD18OvPCNwy0JjhwWc=;
 b=SdbGoCWIFLJzeY/1nsCPiFYraUSh64mZzkXrZZt2mBciq4UQw1V8ZKa0p6FCvkv8GlWd1OYN289fZ8p/02041Aj/FQDI7FRWjeqZ7TQJX+qk3BEx7xrvY7g04Xkr+j7vE3pACPAkfuArH4+LspmqvC4HK+P0qaQA7IXdkAG8Jro=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Daniel P.
 Smith" 
Subject: [PATCH v2 10/15] xen/dt: Rename bootfdt.c -> bootinfo-fdt.c
Date: Thu, 5 Jun 2025 21:48:02 +0200
Message-ID: <20250605194810.2782031-11-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250605194810.2782031-1-agarciav@amd.com>
References: <20250605194810.2782031-1-agarciav@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: BN2PEPF000055DB:EE_|SN7PR12MB6932:EE_
X-MS-Office365-Filtering-Correlation-Id: d496c9a4-f549-4c45-f851-08dda46a0974
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?wHyOmQhsow9yAH807JTGodDYGGG/Ia/fhmpeIHFg66Kdoyfmii8TtpDjAkIr?=
 =?us-ascii?Q?VXKZ1+4Ug2jw9SpgCKLEkl4MSxqvLGGn63vtqdkYIat3AuQ0FvcUL9to3qmZ?=
 =?us-ascii?Q?IkDkg2E2GT12cxFeWwDQMDNJkToMeQisG6rVACEeR/s+4jzgB7GDjdkBP+k+?=
 =?us-ascii?Q?NPGkmQlssIPePZp+sxVvV2/tGnnI9W4ESlHjoUaM1w2gWwmaNqYdf3QakvIy?=
 =?us-ascii?Q?NFaZuvoJCAxbOKMaegDzOgCtI+OMbf21WkwtdS7l1DFhsf7L+CA+vLXeHt61?=
 =?us-ascii?Q?TLK0i3D/N9r7QRSBJ6hwIQdgR9mdJ8k3mc80C0L4/fU99cvsG4DRgmbySFIc?=
 =?us-ascii?Q?pdLYtxchRLjUjO0fdKN8r5rk6QcDV1H9gkva1hA5lfGCQSgQ3EIw90spcY+M?=
 =?us-ascii?Q?M4zP/cei0xPkfo2s2JiSzfGi89THw5W9aARvyXhv405gGUyPNVo9SKhyU34O?=
 =?us-ascii?Q?xFo65pyuui2/cdMwyYkpJlURJAdVyye8pdDXtlAob9WrEmKHf/H7L/nHct0Z?=
 =?us-ascii?Q?ikxLtb2qKBQA8YgsXPdIbhcncpX6MgKdmJcKfCaZa6aYDan5lSY6cB2RefDF?=
 =?us-ascii?Q?Rux0Gdr/qMDXec3B+StvonklvJTaJsXiwK7Iw0Rjsf2pYQdPmmSkfnJMP/zz?=
 =?us-ascii?Q?5sTBO4kxaO4HoqYijqHhR3p/qtjo2crenTShvMgSxEckdxESDWjRsdNyrRKZ?=
 =?us-ascii?Q?3wQNoWICFU++x811LaImoTjWN+/4H5JGwbLwc/YuvBzAU/ERReMIK1+ppiB8?=
 =?us-ascii?Q?8sxifLL1DMNJMZGRyPpYR7RG429atI+gj2eI7cNkuNDI6yInMgr6qAOrxW3d?=
 =?us-ascii?Q?qNq2qxilENC9snoxt+RJKIeulFdFH8Lvw2UCB3Gdujb7EJH6QGpRctjlhhkl?=
 =?us-ascii?Q?UG6c0gAjIvyVdsMD6mjcOdSun/31elorr+QZn+bkb5tihp4hXkYB/1SWKhAQ?=
 =?us-ascii?Q?anpYTD8iSYPdLzR624bkpDqtWFubikNJS/acJxdhsaJqLjnwsl9DE6U/JFjS?=
 =?us-ascii?Q?1K+7v8BriZzdzWjJ84jfU0OcH2JFhNWbRT1rnMsL4aGvxztNieT2qYhjwK+y?=
 =?us-ascii?Q?dseZ+YJSInXKWzC4bNvKYC/kIXrwmpSzBxo6ONaOocJmOObcwt2nV81/rbFq?=
 =?us-ascii?Q?pBO9YEI1+weGXIcn5hcOCJtd+Cr5NDqOfMR60H10AMaRodgmvJYe1lbht50k?=
 =?us-ascii?Q?zDW+n9iXjXdT6/SqttboXLXNrm/Hsfcj+55jYSnNpERy9U2bWtOZb3PQamaL?=
 =?us-ascii?Q?eO9xKFd6JftM27Pv10JbN9T74E5VoB42taDHFJMIrR1OIBK1V3hQM7tkEP7I?=
 =?us-ascii?Q?Qh/oco4IXLLkY72ElTS1OehFryOMBAzd4RCcGVxaoY7Tnqwm6odjJdO9a2Mq?=
 =?us-ascii?Q?VomC3GkgGBRS0cUMZld+7fQKrBhgObu3RKNf8qTw7EBdMzQPq9ALGAC+zV7K?=
 =?us-ascii?Q?bH0qxt/obalyHuNuue8+09oN6rET4pKEEJEvDSLwh9XKuGYC5KwdK8fi6v46?=
 =?us-ascii?Q?lZb04SLLpQKrZKAmyjcHl0/qc8ijqrxYg8FS?=
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: 05 Jun 2025 19:49:08.8171
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d496c9a4-f549-4c45-f851-08dda46a0974
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:
	BN2PEPF000055DB.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB6932

This file will eventually contain bootfdt helpers that make heavy use of
bootinfo. To simplify git history do the rename here explicitly. A later
patch extracts bootinfo-independent helpers into bootfdt.c.

Doing so here would needlessly pollute the diffs.

Not a functional change.

Signed-off-by: Alejandro Vallejo 
Reviewed-by: Stefano Stabellini 
---
 xen/common/device-tree/Makefile                      | 2 +-
 xen/common/device-tree/{bootfdt.c => bootinfo-fdt.c} | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
 rename xen/common/device-tree/{bootfdt.c => bootinfo-fdt.c} (99%)

diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
index 13127296cb..8a3f2be89e 100644
--- a/xen/common/device-tree/Makefile
+++ b/xen/common/device-tree/Makefile
@@ -1,4 +1,4 @@
-obj-y += bootfdt.init.o
+obj-y += bootinfo-fdt.init.o
 obj-y += bootinfo.init.o
 obj-y += device-tree.o
 obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.init.o
diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootinfo-fdt.c
similarity index 99%
rename from xen/common/device-tree/bootfdt.c
rename to xen/common/device-tree/bootinfo-fdt.c
index 7ff62e1e3e..195249f700 100644
--- a/xen/common/device-tree/bootfdt.c
+++ b/xen/common/device-tree/bootinfo-fdt.c
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 /*
- * Early Device Tree
+ * Early Device Tree with bootinfo hooks
  *
  * Copyright (C) 2012-2014 Citrix Systems, Inc.
  */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 19:50:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 19:50:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007485.1386817 (Exim 4.92)
	(envelope-from )
	id 1uNGbW-0000CF-58; Thu, 05 Jun 2025 19:50:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007485.1386817; Thu, 05 Jun 2025 19: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 1uNGbW-0000C8-1a; Thu, 05 Jun 2025 19:50:22 +0000
Received: by outflank-mailman (input) for mailman id 1007485;
 Thu, 05 Jun 2025 19:50: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 1uNGbU-00009i-N4
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 19:50:20 +0000
Received: from NAM02-SN1-obe.outbound.protection.outlook.com
 (mail-sn1nam02on2060d.outbound.protection.outlook.com
 [2a01:111:f403:2406::60d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4e66e888-4246-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 21:50:19 +0200 (CEST)
Received: from BL1PR13CA0125.namprd13.prod.outlook.com (2603:10b6:208:2bb::10)
 by BL1PR12MB5947.namprd12.prod.outlook.com (2603:10b6:208:39a::9)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.33; Thu, 5 Jun
 2025 19:50:10 +0000
Received: from BN2PEPF000055DB.namprd21.prod.outlook.com
 (2603:10b6:208:2bb:cafe::3e) by BL1PR13CA0125.outlook.office365.com
 (2603:10b6:208:2bb::10) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.34 via Frontend Transport; Thu,
 5 Jun 2025 19:49:10 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN2PEPF000055DB.mail.protection.outlook.com (10.167.245.5) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.2 via Frontend Transport; Thu, 5 Jun 2025 19:49:10 +0000
Received: from xcbagarciav01.xilinx.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, 5 Jun
 2025 14:49:04 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4e66e888-4246-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=IZK944V3yBHApVJdZkCyK9nw9HInaDPiZKilwlKaw7UGEKFC+dEMLvS/SN3C8X6WYAjRaXy2cmFuKsuMdFticp4nBdk4t3hT7PR5n6eJG9hHMJthJTQxWwjMlCeUKBJ6ph5gTIg3eVV5Bo8RmyaYeVTMmNaGaypcVzphL2sG65gD4e2ZXQzj3OeOVjdlSp4MJXTQ4LREpXn7uPWJD130uAG0HpYSLC77xsyzTZQFkB78Dj10lfZTycBv9EhpAdT0oc9pE73iUVYK4GsOahomOdH1OlWMHUbff43RL9UH3ROm7Itso/IIu2R38dA/FmgkZNHMJyCLUmeOcJgdRbl69w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=brxUSyWoWAWqxgYUG8qaIMM7Yyx7/AEhfufohTwOIXw=;
 b=jL1ZPRRUjcDMvNYoil/hZsQ14reRfD3OWuYNUxM9dK5puA7A34IsP2HniQiVyAHEPAvMQo23rDMndAFqPYdl1CDYVksZzCJZk0q8m5iDFTZJXfCJLN3BJa4UfCWEpG5oEvzlJj9zcC84YiK9QVz3w6/K3nn1n6GZA2D+5RnZWlGewyH1D18fxU8KeiofvIeCT7Z4k3SWDWwDnybgYuWlmLl9qVW/HmBScj+MdUEeb8RoJk7z95yYTvGnNxKCz/Z75ejNsh20pKyGBFa4RiEKHRrf5vJwieVJ3iRiVf0ODsWtYMYelq76+GecBthDHHW2VmXZVrPnHz4IAF2h5iNKvg==
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=brxUSyWoWAWqxgYUG8qaIMM7Yyx7/AEhfufohTwOIXw=;
 b=Epz/+jZNSAX+VWNpa3IRKEBg81zXpzk06tE7BnZXxKXvv1XtPYeJBWnSC0saLm9Aorrka1NX6WaUE3LCgsTxjUs78HT7jkqY+0jTVpLqw1J+9t+rLn3mdrzp+PS7WUiIWb7TMjQNW4+EFDqsh+aJPSCo2mt1M5uStdMZPEfhLII=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Daniel P.
 Smith" 
Subject: [PATCH v2 13/15] xen/dt: ifdef out DEV_DT-related bits from device_tree.{c,h}
Date: Thu, 5 Jun 2025 21:48:05 +0200
Message-ID: <20250605194810.2782031-14-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250605194810.2782031-1-agarciav@amd.com>
References: <20250605194810.2782031-1-agarciav@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: BN2PEPF000055DB:EE_|BL1PR12MB5947:EE_
X-MS-Office365-Filtering-Correlation-Id: 8e4c0063-8ef4-4ba8-5d10-08dda46a0a8b
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:
	=?us-ascii?Q?CcT0X+hGUGdt3k9SU8KUcL6xYFyNMFGzLj0B4lUNmtkGCPsjZqgcs4col1Gk?=
 =?us-ascii?Q?nfbQ3O/ZcX30a9EY1WNmUauvOk6UWHZD3mlztmobHrePSE55R8J3hHnBf7Rh?=
 =?us-ascii?Q?bQ6L4X1DbVod7F9yBR2Ko7w+oymZzSCvKEf75HltYxsyOwqc/kv67CJGxvs7?=
 =?us-ascii?Q?ZJX0bIZWdJhQHGQAGakx7/fScfwZz6nhJd1D8YH2h37yFnZV0iMJun9jE7YX?=
 =?us-ascii?Q?FLuBvy2U9finDwQ4ZCUxOprt8Pwe1Jr92hc71+f7fvDFS1/WGFtRNuoxI+8a?=
 =?us-ascii?Q?BtMVmZTR3RAGYqwMIarsSg+tbob3jV+eKK/rEJqfD3yH5GGrXGScaWsLC8M/?=
 =?us-ascii?Q?SzcEQ5XSrzjIFtaNOb0x9zu8Ron+QkqGADSUFsZPQ5rT30yyOKqTx82fK+eP?=
 =?us-ascii?Q?lvopN38HFrHDrnWxpxzoj0dQRS1HyRRe2vuD3vhpdeUOlpF5O6pywQyvRIUu?=
 =?us-ascii?Q?7I/B5SplFcUwaYIg0ja7zvzfynrXZCp6Y6MO0xIo+OV1SXMREBwdFqBXB2zQ?=
 =?us-ascii?Q?2MGzHzf0tQ0GFfLBaCdT5DsEAiVWm6ypTgY8pwqgWTDc5JcCRJduXgIxN2jU?=
 =?us-ascii?Q?qx8lHf8dLHXZPM/PCHg9kwTf+6KAEQAigquAZb6sg3xVutJyp72EGnimbSYB?=
 =?us-ascii?Q?qF2ZJ4Dd+BbqtTR+sFMcbuNzsQtVJKp1hrFemukL3yKo6fIVZgN/16XvL3Oy?=
 =?us-ascii?Q?ChNFZ7KkC/HPrGGO3mOJauzAVPTjv+jA57b0xfwGZg2medZadul0pdTZyqZD?=
 =?us-ascii?Q?1l238RQ8OKmRPIRqyML8bLf1tds1wZFDvgxuKi86H6iAtEPUfP3UkLWORB/2?=
 =?us-ascii?Q?ENf5jWGCoUq24sKLQLiFiVdOnpb6+AVvmGMRepoM6LBLYRlzqnj5aCfEoS/N?=
 =?us-ascii?Q?RroGgGh0HJzPIThtTUbWO3Q5zqtqREWZWfckEmy6Qe1oXDj3Bn9dbRWKAxKI?=
 =?us-ascii?Q?e4Fm+9jxpVco+G0vXI+kQXvRs+Wy5BPHiHXQ/BmQcZJJ2T/oYAosbtV1KjMv?=
 =?us-ascii?Q?OkoMQK6vwg0WU8QQa3wUvZzfUjZlm/F2FZSDdUPVBIsiuOEI0KA3ayju75RR?=
 =?us-ascii?Q?6TgEAgVUpg96wrOeGiJMlG0Ml0xKumF7PnQsk/5MsnXz8zUaiA5Cu+7Au18U?=
 =?us-ascii?Q?ejO2bFP3Jcw0cSwqZ2Hhu5Z9o/fwjxZcJEaqU5+CdZBxUajRMaETdRN4RRou?=
 =?us-ascii?Q?vYSJxDI6Vr7OphqtsP6qElBNwQKVyY0tF49jixdfDwNlFqQrZclhLhVN3wnQ?=
 =?us-ascii?Q?chCT4PJlx50S89AE2jSeLgky/L+jrvEZ8dqNKaje4O0BO6X66NBIiWbmwU2h?=
 =?us-ascii?Q?g87tvtdvjpGSwyoQq80HYvYxMhSLUTwJuFN0Qo343KTx5441rAd1QSYIWdIZ?=
 =?us-ascii?Q?rUimROQBXdPGqKoJ6Zn2BlqFJzekKbD59f8Dfy9oNEWstUp6UYb91Fm5JgYm?=
 =?us-ascii?Q?2wgrfRivGQSx5eT/A4uiOSI0mcFkELDsgAEWbCv7so3UTU8fY+VJmSFFLZzJ?=
 =?us-ascii?Q?i8lVzPmCuMCbWwQFPITmOgY2lqmqRxUkdGhe?=
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)(82310400026)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jun 2025 19:49:10.6453
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 8e4c0063-8ef4-4ba8-5d10-08dda46a0a8b
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:
	BN2PEPF000055DB.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR12MB5947

... which means, device-tree.c stops requiring strictly CONFIG_HAS_DEVICE_TREE
and may function without it.

Not a functional change on architectures that currently use these files,
as they already select CONFIG_HAS_DEVICE_TREE.

Signed-off-by: Alejandro Vallejo 
---
 xen/common/device-tree/device-tree.c | 2 ++
 xen/include/xen/device_tree.h        | 4 ++++
 2 files changed, 6 insertions(+)

diff --git a/xen/common/device-tree/device-tree.c b/xen/common/device-tree/device-tree.c
index 886e6c7712..c8a9c0e46a 100644
--- a/xen/common/device-tree/device-tree.c
+++ b/xen/common/device-tree/device-tree.c
@@ -2028,9 +2028,11 @@ static unsigned long unflatten_dt_node(const void *fdt,
             ((char *)pp->value)[sz - 1] = 0;
             dt_dprintk("fixed up name for %s -> %s\n", pathp,
                        (char *)pp->value);
+#ifdef CONFIG_HAS_DEVICE_TREE
             /* Generic device initialization */
             np->dev.type = DEV_DT;
             np->dev.of_node = np;
+#endif /* CONFIG_HAS_DEVICE_TREE */
         }
     }
     if ( allnextpp )
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 7d1c8bc305..641f24518d 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -109,9 +109,12 @@ struct dt_device_node {
      */
     struct list_head domain_list;
 
+#ifdef CONFIG_HAS_DEVICE_TREE
     struct device dev;
+#endif /* CONFIG_HAS_DEVICE_TREE */
 };
 
+#ifdef CONFIG_HAS_DEVICE_TREE
 #define dt_to_dev(dt_node)  (&(dt_node)->dev)
 
 static inline struct dt_device_node *dev_to_dt(struct device *dev)
@@ -120,6 +123,7 @@ static inline struct dt_device_node *dev_to_dt(struct device *dev)
 
     return container_of(dev, struct dt_device_node, dev);
 }
+#endif /* CONFIG_HAS_DEVICE_TREE */
 
 #define MAX_PHANDLE_ARGS 16
 struct dt_phandle_args {
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 19:50:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 19:50:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007491.1386827 (Exim 4.92)
	(envelope-from )
	id 1uNGbr-0000jy-Bj; Thu, 05 Jun 2025 19:50:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007491.1386827; Thu, 05 Jun 2025 19:50:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNGbr-0000jr-98; Thu, 05 Jun 2025 19:50:43 +0000
Received: by outflank-mailman (input) for mailman id 1007491;
 Thu, 05 Jun 2025 19:50: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 1uNGaT-0002fZ-6i
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 19:49:17 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20624.outbound.protection.outlook.com
 [2a01:111:f403:2009::624])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 29334f25-4246-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 21:49:15 +0200 (CEST)
Received: from BL1PR13CA0137.namprd13.prod.outlook.com (2603:10b6:208:2bb::22)
 by MN2PR12MB4223.namprd12.prod.outlook.com (2603:10b6:208:1d3::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.37; Thu, 5 Jun
 2025 19:49:09 +0000
Received: from BN2PEPF000055DB.namprd21.prod.outlook.com
 (2603:10b6:208:2bb:cafe::18) by BL1PR13CA0137.outlook.office365.com
 (2603:10b6:208:2bb::22) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.14 via Frontend Transport; Thu,
 5 Jun 2025 19:49:09 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN2PEPF000055DB.mail.protection.outlook.com (10.167.245.5) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.2 via Frontend Transport; Thu, 5 Jun 2025 19:49:09 +0000
Received: from xcbagarciav01.xilinx.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, 5 Jun
 2025 14:49:01 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 29334f25-4246-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ZMMU8rbe3/QzAwdQ11F2p682dL93A/MYUBAlykvXLFTpG7E127aUvYwcZjXjsYdI/QXIVp4Pv0IOsWa3r3vMVOIP1ywWajvK3Jlf4cUV20KIxKunZpMccqMhG3M4Qd6dcrmHx0JJVZmI1FA1Du/auYVSOwueLbzvbP7Apx8LHoPWDHbCdDlbQXtGRozbT0KpcRkuTib1thW4y/tGdlwTwguMlqTcB/6RFQLjalqwupvmWqo2ee3LJ47K68s/EcdTKP25k90xsOBJ7IHG+ZpxuVAJVxj6SVlHMthtaSpTt55Xn1o8GW/8TR620yntidCdxwmsHzdxWGouspNPC8eqjQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Wv0EfzD3T04lsgipc7vZMP9PeSx4rOo21HvvmAlamVQ=;
 b=PnFOwcZ9EYEFTvshjx9fjIVtqFTSK8L3QcUBnhrk1Qw27mEDHBpvfN+u4wXpc08GZP9gCKk2VpzVsmqUpKYjqJV8Ykl877g9dlhDcgqfYdz39eQMyZmr954qzMjHJysr06BmM6oB4TNo6riFNlHaoHN48ma4WD397ZPcrFGse6NqAPdNICe9WBU/y9Tgh1ma+cX/GofvSfs/g8fwNnjMrTN6dE/m48i9B0/M2+U0uzT6rmRRsrfVkES60lC2AdAegMkgXpKCqMqLw6EAJQz/WtIGmsy+GYQC5G4krhAHW3ucuGjaH1QkOFOc/DNHI5Pcd4O1ZK4cPS0eI8HH1tT5Ng==
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=Wv0EfzD3T04lsgipc7vZMP9PeSx4rOo21HvvmAlamVQ=;
 b=pKT87fxpLTK7UgkNmqhQZcn1JY6zvbqhLjsVEdCM2P4EYnPkgH9ds94a2kNHhG0cnGqIsxfT1SVwQsqXIRNMe8hQz0Y4/6pQ3jXwAYSVktg4F+rRGXzLrMKQnDRdNLOBFzqnI7t4iBJ2CzaNiyhJbvImuw/M6ZYP5Yd0nk7+i44=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Daniel P.
 Smith" 
Subject: [PATCH v2 11/15] xen/dt: Move bootinfo-independent helpers out of bootinfo-fdt.c
Date: Thu, 5 Jun 2025 21:48:03 +0200
Message-ID: <20250605194810.2782031-12-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250605194810.2782031-1-agarciav@amd.com>
References: <20250605194810.2782031-1-agarciav@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: BN2PEPF000055DB:EE_|MN2PR12MB4223:EE_
X-MS-Office365-Filtering-Correlation-Id: 89c9c659-cce0-47a1-fda4-08dda46a09f9
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|376014|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?QxIFPJv+YrXur05ETNHacvihuswF+nsPPW9b8IE8rC13PB62PTowruXbJL+J?=
 =?us-ascii?Q?ZQ5UvUSlu7doukQ1eWxzDF0hSntPMo4+VLbO55c7wNBMj1v+ZDFoB6Itxxy8?=
 =?us-ascii?Q?0CjevLJiA7ILanjNkBkwcRfnJWwpe3W6Y0/KwPDAyWfTwdp0dqBtT1qLmHDl?=
 =?us-ascii?Q?mmyUt9y0enp1YwsTLqABdT0Ypkbv1n0EYuF+edL0QlGG7XWQXieDK8IgEtin?=
 =?us-ascii?Q?2Fug4+uknDembLiSnLw2E2askB3LpaCCYul5VBilJTjd9DM6EV6WI8twKFr3?=
 =?us-ascii?Q?o2FOnwIKuT2NuL8q6xUd2unY2E9ltuxrJEBfPZZNK+tr65oJNttVXa+xB5YP?=
 =?us-ascii?Q?Xbn81UobLS+7Ts2qfdVq7OtpoA309CQf4byDrc43PrctVor7crBE1/zNIP6X?=
 =?us-ascii?Q?MmEWD2U87INGLWU3siTw3M6QRK3rFZVf16/XsmVKFMFkT7GmxfgIwCzSH7/l?=
 =?us-ascii?Q?9KSZehNmp2G0RMeLiDmG0FDG+W2BXjExYcgA8KIOiET1vJCVj0cwDmw5Elj3?=
 =?us-ascii?Q?Y0JEZaVnKYWNT1sE8cHz9zGtSco1U5e+ivZoZIBc7gGmmfG2faOEPhqqwCsF?=
 =?us-ascii?Q?5gHtwYQaWN6TQLjCpxym1CZy32dJSaKz7cviYhLZbJa3ieSYCUBVOf3bf3Ap?=
 =?us-ascii?Q?0RtpIL2uvPz5IRVC9chwMuJCRbdICItHRCsa5Eat3fOjp6sL2XdXTTQfFUqe?=
 =?us-ascii?Q?fQbxj3nlsYtvj9Gdri1My1dzoLyEVx8FFP6bKBKHfpuCW6jB9ohGsy+fBCrv?=
 =?us-ascii?Q?BYnszt3F3urnsBzyI4xywPZ9GB4FN4c7hgCq2OSn57eIcGhOUaybktntPiKd?=
 =?us-ascii?Q?fbq3veW3zkoL5ZkmWQ5JM0jmYyCrXc1cwk4/3VfcWiVncLZeWuDD1WPFbKug?=
 =?us-ascii?Q?3McXAZYM6I02zCRiBfSlKdFPhkYQdVRjvKLxDocShXxEJL8Fx3YKmSdqy78m?=
 =?us-ascii?Q?P/F8PTKrZEaL6LLJEyCerMG0PQkSGcKD0pRU0H0yRL9cJv2ka3NDbEEFnhOe?=
 =?us-ascii?Q?oHVAj1A3KgV0felTRoU86jHSY6bxxFkUpFbvgZgEpKLgDMjuENZYlnzjI4ou?=
 =?us-ascii?Q?/oNewcMKEqPecz2E9W5ec9CE1nFPQrEYV4n5+Yw32fboXg58rZgeGWd+rm3m?=
 =?us-ascii?Q?zoYcoHUNQrC9rInN7tqLQstXaiGZ1Bo3+nbn1UZbvAUEiTswu6Vs3u8dTsK2?=
 =?us-ascii?Q?iBBgxzea8ZZfBAL3jipSqYK4yd/TN7X0QK+BUYG1LpcbMd3o4Om1csUwrKHP?=
 =?us-ascii?Q?ZricSHWz0kChPg3qQZFzLHtiv1Izl3DtpWyQjFmKRmMNYUQsTLSyp5sCLmV5?=
 =?us-ascii?Q?5EiI50ahQThoA2MJ4lznGrweNKB7WbtA2MBf3s04Se2Vbs8jUVzN18U/GBsc?=
 =?us-ascii?Q?yBeoPZsL+AsGnMuHeD1Ui/GTD+BqfgKM4YD00Czd0xh+6cMaBwvlclU5yxaj?=
 =?us-ascii?Q?1PZWjVodIPRDOcex1xu/fWbbOvoDet03FTiEyeEycWf3xIrICIKKONk9PcLx?=
 =?us-ascii?Q?xdxZ8YwGetZfzFChk5c1hzeP9Fko7lFFn5X4?=
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);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jun 2025 19:49:09.6921
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 89c9c659-cce0-47a1-fda4-08dda46a09f9
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:
	BN2PEPF000055DB.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4223

... back into bootfdt.c

These will be required by x86 later on to detect modules in the early scan of
the FDT. They are independent of bootinfo, so it's cleaner for them to exist in
a separate file.

Not a functional change.

Signed-off-by: Alejandro Vallejo 
---
 xen/common/device-tree/Makefile       |   1 +
 xen/common/device-tree/bootfdt.c      |  97 ++++++++++++++++++++++++
 xen/common/device-tree/bootinfo-fdt.c | 104 --------------------------
 3 files changed, 98 insertions(+), 104 deletions(-)
 create mode 100644 xen/common/device-tree/bootfdt.c

diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
index 8a3f2be89e..8abc069c4b 100644
--- a/xen/common/device-tree/Makefile
+++ b/xen/common/device-tree/Makefile
@@ -1,3 +1,4 @@
+obj-y += bootfdt.init.o
 obj-y += bootinfo-fdt.init.o
 obj-y += bootinfo.init.o
 obj-y += device-tree.o
diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
new file mode 100644
index 0000000000..6acf83d197
--- /dev/null
+++ b/xen/common/device-tree/bootfdt.c
@@ -0,0 +1,97 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#include 
+#include 
+#include 
+#include 
+
+uint32_t __init device_tree_get_u32(const void *fdt, int node,
+                                    const char *prop_name, uint32_t dflt)
+{
+    const struct fdt_property *prop;
+
+    prop = fdt_get_property(fdt, node, prop_name, NULL);
+    if ( !prop || prop->len < sizeof(uint32_t) )
+        return dflt;
+
+    return fdt32_to_cpu(*(const uint32_t*)prop->data);
+}
+
+int __init device_tree_for_each_node(const void *fdt, int node,
+                                     device_tree_node_func func,
+                                     void *data)
+{
+    /*
+     * We only care about relative depth increments, assume depth of
+     * node is 0 for simplicity.
+     */
+    int depth = 0;
+    const int first_node = node;
+    uint32_t address_cells[DEVICE_TREE_MAX_DEPTH];
+    uint32_t size_cells[DEVICE_TREE_MAX_DEPTH];
+    int ret;
+
+    do {
+        const char *name = fdt_get_name(fdt, node, NULL);
+        uint32_t as, ss;
+
+        if ( depth >= DEVICE_TREE_MAX_DEPTH )
+        {
+            printk("Warning: device tree node `%s' is nested too deep\n",
+                   name);
+            continue;
+        }
+
+        as = depth > 0 ? address_cells[depth-1] : DT_ROOT_NODE_ADDR_CELLS_DEFAULT;
+        ss = depth > 0 ? size_cells[depth-1] : DT_ROOT_NODE_SIZE_CELLS_DEFAULT;
+
+        address_cells[depth] = device_tree_get_u32(fdt, node,
+                                                   "#address-cells", as);
+        size_cells[depth] = device_tree_get_u32(fdt, node,
+                                                "#size-cells", ss);
+
+        /* skip the first node */
+        if ( node != first_node )
+        {
+            ret = func(fdt, node, name, depth, as, ss, data);
+            if ( ret != 0 )
+                return ret;
+        }
+
+        node = fdt_next_node(fdt, node, &depth);
+    } while ( node >= 0 && depth > 0 );
+
+    return 0;
+}
+
+void __init device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
+                                uint32_t size_cells, paddr_t *start,
+                                paddr_t *size)
+{
+    uint64_t dt_start, dt_size;
+
+    /*
+     * dt_next_cell will return uint64_t whereas paddr_t may not be 64-bit.
+     * Thus, there is an implicit cast from uint64_t to paddr_t.
+     */
+    dt_start = dt_next_cell(address_cells, cell);
+    dt_size = dt_next_cell(size_cells, cell);
+
+    if ( dt_start != (paddr_t)dt_start )
+    {
+        printk("Physical address greater than max width supported\n");
+        WARN();
+    }
+
+    if ( dt_size != (paddr_t)dt_size )
+    {
+        printk("Physical size greater than max width supported\n");
+        WARN();
+    }
+
+    /*
+     * Xen will truncate the address/size if it is greater than the maximum
+     * supported width and it will give an appropriate warning.
+     */
+    *start = dt_start;
+    *size = dt_size;
+}
diff --git a/xen/common/device-tree/bootinfo-fdt.c b/xen/common/device-tree/bootinfo-fdt.c
index 195249f700..695c4bfc49 100644
--- a/xen/common/device-tree/bootinfo-fdt.c
+++ b/xen/common/device-tree/bootinfo-fdt.c
@@ -109,39 +109,6 @@ static bool __init device_tree_is_memory_node(const void *fdt, int node,
     return true;
 }
 
-void __init device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
-                                uint32_t size_cells, paddr_t *start,
-                                paddr_t *size)
-{
-    uint64_t dt_start, dt_size;
-
-    /*
-     * dt_next_cell will return uint64_t whereas paddr_t may not be 64-bit.
-     * Thus, there is an implicit cast from uint64_t to paddr_t.
-     */
-    dt_start = dt_next_cell(address_cells, cell);
-    dt_size = dt_next_cell(size_cells, cell);
-
-    if ( dt_start != (paddr_t)dt_start )
-    {
-        printk("Physical address greater than max width supported\n");
-        WARN();
-    }
-
-    if ( dt_size != (paddr_t)dt_size )
-    {
-        printk("Physical size greater than max width supported\n");
-        WARN();
-    }
-
-    /*
-     * Xen will truncate the address/size if it is greater than the maximum
-     * supported width and it will give an appropriate warning.
-     */
-    *start = dt_start;
-    *size = dt_size;
-}
-
 static int __init device_tree_get_meminfo(const void *fdt, int node,
                                           const char *prop_name,
                                           u32 address_cells, u32 size_cells,
@@ -202,77 +169,6 @@ static int __init device_tree_get_meminfo(const void *fdt, int node,
     return 0;
 }
 
-uint32_t __init device_tree_get_u32(const void *fdt, int node,
-                                    const char *prop_name, uint32_t dflt)
-{
-    const struct fdt_property *prop;
-
-    prop = fdt_get_property(fdt, node, prop_name, NULL);
-    if ( !prop || prop->len < sizeof(uint32_t) )
-        return dflt;
-
-    return fdt32_to_cpu(*(const uint32_t*)prop->data);
-}
-
-/**
- * device_tree_for_each_node - iterate over all device tree sub-nodes
- * @fdt: flat device tree.
- * @node: parent node to start the search from
- * @func: function to call for each sub-node.
- * @data: data to pass to @func.
- *
- * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
- *
- * Returns 0 if all nodes were iterated over successfully.  If @func
- * returns a value different from 0, that value is returned immediately.
- */
-int __init device_tree_for_each_node(const void *fdt, int node,
-                                     device_tree_node_func func,
-                                     void *data)
-{
-    /*
-     * We only care about relative depth increments, assume depth of
-     * node is 0 for simplicity.
-     */
-    int depth = 0;
-    const int first_node = node;
-    u32 address_cells[DEVICE_TREE_MAX_DEPTH];
-    u32 size_cells[DEVICE_TREE_MAX_DEPTH];
-    int ret;
-
-    do {
-        const char *name = fdt_get_name(fdt, node, NULL);
-        u32 as, ss;
-
-        if ( depth >= DEVICE_TREE_MAX_DEPTH )
-        {
-            printk("Warning: device tree node `%s' is nested too deep\n",
-                   name);
-            continue;
-        }
-
-        as = depth > 0 ? address_cells[depth-1] : DT_ROOT_NODE_ADDR_CELLS_DEFAULT;
-        ss = depth > 0 ? size_cells[depth-1] : DT_ROOT_NODE_SIZE_CELLS_DEFAULT;
-
-        address_cells[depth] = device_tree_get_u32(fdt, node,
-                                                   "#address-cells", as);
-        size_cells[depth] = device_tree_get_u32(fdt, node,
-                                                "#size-cells", ss);
-
-        /* skip the first node */
-        if ( node != first_node )
-        {
-            ret = func(fdt, node, name, depth, as, ss, data);
-            if ( ret != 0 )
-                return ret;
-        }
-
-        node = fdt_next_node(fdt, node, &depth);
-    } while ( node >= 0 && depth > 0 );
-
-    return 0;
-}
-
 static int __init process_memory_node(const void *fdt, int node,
                                       const char *name, int depth,
                                       u32 address_cells, u32 size_cells,
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 19:51:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 19:51:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007518.1386836 (Exim 4.92)
	(envelope-from )
	id 1uNGcL-0001mI-NP; Thu, 05 Jun 2025 19:51:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007518.1386836; Thu, 05 Jun 2025 19: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 1uNGcL-0001m9-Kl; Thu, 05 Jun 2025 19:51:13 +0000
Received: by outflank-mailman (input) for mailman id 1007518;
 Thu, 05 Jun 2025 19:51: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 1uNGau-0002fZ-VD
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 19:49:44 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on2061d.outbound.protection.outlook.com
 [2a01:111:f403:2414::61d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 39b5f8fa-4246-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 21:49:43 +0200 (CEST)
Received: from BN9PR03CA0353.namprd03.prod.outlook.com (2603:10b6:408:f6::28)
 by IA1PR12MB7615.namprd12.prod.outlook.com (2603:10b6:208:428::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Thu, 5 Jun
 2025 19:49:39 +0000
Received: from BN2PEPF000055DA.namprd21.prod.outlook.com
 (2603:10b6:408:f6:cafe::5a) by BN9PR03CA0353.outlook.office365.com
 (2603:10b6:408:f6::28) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.31 via Frontend Transport; Thu,
 5 Jun 2025 19:49:39 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN2PEPF000055DA.mail.protection.outlook.com (10.167.245.4) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.2 via Frontend Transport; Thu, 5 Jun 2025 19:49:39 +0000
Received: from xcbagarciav01.xilinx.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, 5 Jun
 2025 14:49:08 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 39b5f8fa-4246-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=dqrn+eRwFYb8IeyOs+q7asxyq4jvhOPsbC+AtByC6rA87zw7Vka68XAD09HuruPhVMK4xJ2+8PMHGgV6lagNVEdKYtVX03INFZWYsOpxe5GrVW1g5Hz9hxRW65Rfq2i79Fe+O0i16YsCTuaQfnHpfpCYqp8TsR6SgPQWE/YSggttQzL9Xw9c5tErDmRG9q4lIhdMRggTCrBeZ2+8NcnU/zof2kRiJ8LkK9KX+QOnfRiId8kLjF/kSTu4yahLzY9GqDSyEj+o0ojQxwxEFULx+MJHQ1YQXNWSBr4Y6DZYzJpX/RhyP468l8xnY7U39oIUeQqPv0gOsk/MsGH9BcQHiQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=qBMHO1HIupXAcwfOdVU4/7q8edByJCbA+TOtQ6T2SUo=;
 b=TBUjHDIEzn2eHHxTNTmaEfOf8nvrbxqCkuuqpHk0vi6hRM2exHDL5aGDRqryg3oyZ7zBLMB/cOaTfKD1sEmoqIkCurMXAJQEOwhoTbGQ3BZePdmyE50rxNiH/f4j35BTSmn+u1TapGdJ4JoEtnxa3ACTgLTycpGmF2FVYxP71BrgZ9vA3YkMJmnP3LJqzQCQeXwl6dV8MKpFb8IwUZaggwvX0VN2AUsXLJexAsk7n79EuTTtdQnwmhpzPnA8joqVYVLvRV/9dPYDEhgo9KNOkseJN9NZiXO6yjuJywaaSEtbeuhE2+s4BpZKQNVcqZJZryB7VIr7Hdccp7QuJ2bv1A==
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=qBMHO1HIupXAcwfOdVU4/7q8edByJCbA+TOtQ6T2SUo=;
 b=rdbGbY6FkvOOlr0ymnp3nYs3plHUd09dmFhPf1S5oYMEp/m0mE0Cb+iGigrb3pYlvc5QgA0SiYmhZaw44JP60iO5VunDWHOgAUgyfqPrHA5Eu+LBd49JcRKobhfFhrYVtwWKhn9C9f9ZQvDLh3N8ENFtB7HLcFJi66U7Xaxk+2Q=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Anthony PERARD
	, Michal Orzel , "Julien
 Grall" , Stefano Stabellini ,
	"Bertrand Marquis" , "Daniel P. Smith"
	
Subject: [PATCH v2 15/15] kconfig: Allow x86 to pick CONFIG_DOM0LESS_BOOT
Date: Thu, 5 Jun 2025 21:48:07 +0200
Message-ID: <20250605194810.2782031-16-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250605194810.2782031-1-agarciav@amd.com>
References: <20250605194810.2782031-1-agarciav@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: BN2PEPF000055DA:EE_|IA1PR12MB7615:EE_
X-MS-Office365-Filtering-Correlation-Id: e9760123-a68b-4eea-5822-08dda46a1b96
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?e1QfQJBTKobVhuf7KNjYIs6V/h4wodUoT4EfCGxWqV8k4/CKmVjKYHrn3rI2?=
 =?us-ascii?Q?H2PSLNUP15CySrvDWM3ANwUfozyCrjvZJAvumwkwBJmD3FogAiqrtctLSA7P?=
 =?us-ascii?Q?d4p+xSLUa0DeY/F/J8ARKW5X6JGaqg3GOy7TdPHorSxr/svPLGYtkUMaghEx?=
 =?us-ascii?Q?gnt/Fpi9Ku3Phe5CyWCX/WQlqrc9pvZbrIa26DNzJU5buIFjZ7eA1eI+hhKS?=
 =?us-ascii?Q?0K03Vvet2QteQu4lMXNYhmsDCn1cTARGkvD+HHKEYl5S4F+YrT4We6QpmKYf?=
 =?us-ascii?Q?Hi7Nhd9ih/gTA/MoqhldvYvbKe8xGdUnYRHC9PO4Z6YI0OTiASZdCCIM7TPX?=
 =?us-ascii?Q?stEvktKpb4mwolPUEGfYfX9n0QqPA/XTc30Yrb6jpFcOH5u1xIUwE51hsw/9?=
 =?us-ascii?Q?0o3L8tdEx6pUipzbnfRq0aal8Qlin9YX+O6dPWCorzaJnOCMvDjQ907nyKjI?=
 =?us-ascii?Q?/XHWlvhxan0LAvnGyIksA/BXNGaxSB2uBAXxi+UiRknuyuEdr9utonKuYzpX?=
 =?us-ascii?Q?Q25k52Kq1MMEuvakeVJNab96+EwXJCvgv79QZhVDIjdrVIUe3ts4wQWts6Fs?=
 =?us-ascii?Q?YyjbB42CkIye7UPlyqDPu/Zh9aV9kjluVxgZsX8NvLcWurF3yCMO+EcrcqsA?=
 =?us-ascii?Q?voMnkbXIWWkOLUBqwkb10U9QzwMZZrIXH6tAO1jVEd0+hXXWs4M9QICZHkO4?=
 =?us-ascii?Q?95dssUSrsfSvJZ7CRfyaH7zNGQ2qPg8z05Q/5u/KbDMlAerLXttEnzTZ8fWE?=
 =?us-ascii?Q?Alu9ZgG24xUMCvLzihBY0yHQjVJH8U2ZxZiENU7yqIqFrpx12TcnHwaZRzOs?=
 =?us-ascii?Q?oV/HaIg8JuFqSp6L1NcOFNVJVRklJROXI1paHICxV6KO52qA4dPUGmsGjF9Q?=
 =?us-ascii?Q?DSBMGX9cGlI/1vaDrI/bicCtjvZgTeIakDZSiep6sJb/4W2k5h5GypeipwnA?=
 =?us-ascii?Q?xBXN5Y40n0TIOlW8xWvWLHfHS6yBTrOu7fO8xpcTxml/YO3rba0QsJMSNVAK?=
 =?us-ascii?Q?B2aqioAsY/vWPgUp68uDqoPHo8j5UTUsrtg77Bv7i8dh90yKi09SCJRnXV8U?=
 =?us-ascii?Q?ZmlQaxhimCxuvpF+72YNUSU6RTA7/IkoSqDC2fJzl/fuyTASM5APNuM581fO?=
 =?us-ascii?Q?3605QWcvlaEGt6EKQpipCfthFqjtbc3qpqfDzFWXgjzYpEMT3Vxx1I/LPVE+?=
 =?us-ascii?Q?ZkcXXXn/TA0xmbSP1DxA9ugeVx5xlQqhqjtHgWNVJ3voNv4biAKW0KchLBrl?=
 =?us-ascii?Q?FkZ2qDxkuvVUjhaAkowt1DSNgaCS0nOKrogIIpbQBqEA19s23DFQ7Ez1i2xe?=
 =?us-ascii?Q?+Gr8XLkt9UOpObR6b1l8/VvRWZNfIhBh8QEL3BMps8rVrWVlzEo0nrgYVlEA?=
 =?us-ascii?Q?8ztF4Mpxkylfx+dH/KHCXF65cgqWQAU9cFJIIERE8w/ogT4yt1fEGxtxn+yN?=
 =?us-ascii?Q?6KLanifox63fIqQy91kK8gwm44fJzR5i1I3fAdgeKmdkY05lh8H1MPN4um6j?=
 =?us-ascii?Q?n4259CcMewz3QLSuStdFqqVSYoggpeRVS702?=
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: 05 Jun 2025 19:49:39.2372
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e9760123-a68b-4eea-5822-08dda46a1b96
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:
	BN2PEPF000055DA.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB7615

Without picking CONFIG_HAS_DEVICE_TREE.

In order to do that. Allow CONFIG_DOM0LESS_BOOT to enable a subset
of the common/device-tree/ directory. x86 doesn't want dom0less-build.c,
as that's tightly integrated still to the ARM way of building domains.

Requires "unsupported" for the time being until all required patches
make it through.

Signed-off-by: Alejandro Vallejo 
---
v2:
  * (required on rebase) Add an explicit dependency on HAS_DEVICE_TREE
    for STATIC_MEMORY and STATIC_EVTCHN so they're not pulled-in. Could
    use !X86 as well.
---
 xen/arch/x86/Kconfig            |  1 +
 xen/common/Kconfig              | 12 +++++++-----
 xen/common/device-tree/Makefile |  2 +-
 3 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 7afe879710..4344b4289c 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -18,6 +18,7 @@ config X86
 	select HAS_COMPAT
 	select HAS_CPUFREQ
 	select HAS_DIT
+	select HAS_DOM0LESS
 	select HAS_EHCI
 	select HAS_EX_TABLE
 	select HAS_FAST_MULTIPLY
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 5353874e87..bcf87b4d9d 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -13,15 +13,17 @@ config CORE_PARKING
 	depends on NR_CPUS > 1
 
 config DOM0LESS_BOOT
-	bool "Dom0less boot support" if EXPERT
+	bool "Dom0less boot support" if EXPERT && (!X86 || UNSUPPORTED)
 	select LIBFDT
-	depends on HAS_DOM0LESS && HAS_DEVICE_TREE && DOMAIN_BUILD_HELPERS
-	default y
+	depends on HAS_DOM0LESS && (X86 || (HAS_DEVICE_TREE && DOMAIN_BUILD_HELPERS))
+	default y if !X86
 	help
 	  Dom0less boot support enables Xen to create and start domU guests during
 	  Xen boot without the need of a control domain (Dom0), which could be
 	  present anyway.
 
+	  If unsure on x86, say N.
+
 config DOMAIN_BUILD_HELPERS
 	bool
 
@@ -152,7 +154,7 @@ config NUMA
 
 config STATIC_MEMORY
 	bool "Static Allocation Support (UNSUPPORTED)" if UNSUPPORTED
-	depends on DOM0LESS_BOOT
+	depends on HAS_DEVICE_TREE && DOM0LESS_BOOT
 	help
 	  Static Allocation refers to system or sub-system(domains) for
 	  which memory areas are pre-defined by configuration using physical
@@ -171,7 +173,7 @@ config STATIC_SHM
 
 config STATIC_EVTCHN
 	bool "Static event channel support on a dom0less system"
-	depends on DOM0LESS_BOOT
+	depends on HAS_DEVICE_TREE && DOM0LESS_BOOT
 	default y
 	help
 	  This option enables establishing static event channel communication
diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
index cc56f42df9..f5410e685b 100644
--- a/xen/common/device-tree/Makefile
+++ b/xen/common/device-tree/Makefile
@@ -3,7 +3,7 @@ obj-$(CONFIG_HAS_DEVICE_TREE) += bootinfo-fdt.init.o
 obj-$(CONFIG_HAS_DEVICE_TREE) += bootinfo.init.o
 obj-$(CONFIG_HAS_DEVICE_TREE) += device-tree.o
 obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.init.o
-obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.init.o
+obj-$(filter-out $(CONFIG_X86),$(CONFIG_DOM0LESS_BOOT)) += dom0less-build.init.o
 obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o
 obj-$(CONFIG_HAS_DEVICE_TREE) += intc.o
 obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 19:51:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 19:51:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007530.1386847 (Exim 4.92)
	(envelope-from )
	id 1uNGcR-0002FL-Uo; Thu, 05 Jun 2025 19:51:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007530.1386847; Thu, 05 Jun 2025 19: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 1uNGcR-0002FB-RP; Thu, 05 Jun 2025 19:51:19 +0000
Received: by outflank-mailman (input) for mailman id 1007530;
 Thu, 05 Jun 2025 19:51: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 1uNGaR-0002tD-St
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 19:49:15 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on2061b.outbound.protection.outlook.com
 [2a01:111:f403:2415::61b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 285d73b9-4246-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 21:49:15 +0200 (CEST)
Received: from BL1PR13CA0130.namprd13.prod.outlook.com (2603:10b6:208:2bb::15)
 by CH3PR12MB9080.namprd12.prod.outlook.com (2603:10b6:610:1a7::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Thu, 5 Jun
 2025 19:49:10 +0000
Received: from BN2PEPF000055DB.namprd21.prod.outlook.com
 (2603:10b6:208:2bb:cafe::1c) by BL1PR13CA0130.outlook.office365.com
 (2603:10b6:208:2bb::15) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.17 via Frontend Transport; Thu,
 5 Jun 2025 19:49:10 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN2PEPF000055DB.mail.protection.outlook.com (10.167.245.5) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.2 via Frontend Transport; Thu, 5 Jun 2025 19:49:09 +0000
Received: from xcbagarciav01.xilinx.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, 5 Jun
 2025 14:49:03 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 285d73b9-4246-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=xormJYxutVFXv21/aq/SfW1E4oU0hX6Nvvf1gRdaBgwixDt5a8Bnhn2gOqFYAQKQjAkszqondgmfQGrmBdnmIaUAAkzCV+G+yUS3SkqvqY/qRXIKQ2I3VpfbbTuyJ0uZ1NJkP7n7dwRE4w97V3HNxcSNa/xnunnq4Puvzp8Vy02Ptzm2C7UhTlVHZdFrSaRxiqL3Y/wjsknnpMgoarbmt5xiPIx4DF+egvcBxk3PAGf5KtFEOLDTKocg3A6pRNKS4j6k2SxGCSAWftWPn7vJPDPlo4qzxccYiLT6/B0N77twyu9QPu0tKcJzkfayUJqFp+g+aLEQRlxrhtu6lxBqkQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=i8prgYMg1Iae8KvOYuV1o/xOVsXEhepIuqEAO+9pqk0=;
 b=OfXAtYuskj1trl3R1JoXrG/2hCvkueDAnLSB/tuYP+t5eqFUkOzzZYZtD4F67nq3MkoIlH0/rFnwMHW6cEUIQwEoz2jyi1wFAlHz3RqzcJV0mqKWVggdHg1V6Adqsau5DkQfAh6+/MpiSxZdR3Y9/4BHfQhNr9S5kfq7EsXUyuJ9TFBBsA2/olf2zBZr0rI8+XV+QSccHabtP6MVKqbwIOIUlQoUQ/drN64c5k0uPy72ATl/OOVulORHnQhNKIJu7jYG+qw+Mw5vdJlIzdFsIVJoOXtxNwGweawLHyhjkuRWxocP/Y6TZX7zfsJ1e4JvlMM+CeopVvqHBOXSXDIwqw==
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=i8prgYMg1Iae8KvOYuV1o/xOVsXEhepIuqEAO+9pqk0=;
 b=yk+vgjtYsTZ7s41tgdKBEMD84kBNDc6fVM0HEaidLADsC6Wy2dTCJy1NCY4FmqVznccsUSFuJ1zfCW2HVEwO446JCUHwKjFR7ncCr94N/niaGy2Oj2AuVjJ/MKl/1fkXnuHm6r8FALnQII2HJ68meYFjQJOahkQfWNeJZj3dwFs=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Daniel P.
 Smith" 
Subject: [PATCH v2 12/15] xen/dt: Extract helper to map nodes to module kinds
Date: Thu, 5 Jun 2025 21:48:04 +0200
Message-ID: <20250605194810.2782031-13-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250605194810.2782031-1-agarciav@amd.com>
References: <20250605194810.2782031-1-agarciav@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: BN2PEPF000055DB:EE_|CH3PR12MB9080:EE_
X-MS-Office365-Filtering-Correlation-Id: 096e87a5-0baf-44b1-469e-08dda46a0a27
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?Fpi1ABCaJD/TpIuI/nmDMDQAEIkF2wehtiXNEKwx6HTv0LvXWQPLu7Zrd+Jn?=
 =?us-ascii?Q?Y2bzzA7V4iYwicj7EjCrP6p0psV9mjcVJuHKTpY/MwcGKstNSHmi3R8/TLde?=
 =?us-ascii?Q?CyCW5mkVTPoI3Dh8346wyJU/wS3VJDR9GfBfm9JXMfpIX3EhYByJR3sug5Kz?=
 =?us-ascii?Q?vLESLoig+m314MXIflhTBeMe+7GP/cXqFbMmr6KeC24CRNYZeroLr6P8oTYZ?=
 =?us-ascii?Q?13Lcw801qcUkEaNai93aNhQOkRZ9R/uYrZ2OnvWvR5JBtDadX0ovVbO1Gjm3?=
 =?us-ascii?Q?F/ly7xkyHmGYeq0hJjYc34gyeiTHy7mK6esr9GYDjlA2iJu1eFJIhAUwUpFA?=
 =?us-ascii?Q?j4tbvl73RYX605TindMonIKXxYBx2c6ebhpoRTxaYozZJstYKxvwxxDzIZBp?=
 =?us-ascii?Q?Oq1l8plYSjVLajfW05stCvxZHm/Ipm/4Ahnn53alg5v2Ubxlz+Xi0xtweCGk?=
 =?us-ascii?Q?qPqiWQawWV2c0o9JlCbX+A2OOvmBQNso6VDWr0jNjnyYNKqf0bfBhOenop1W?=
 =?us-ascii?Q?hWa8UJHx6jVuDCuhOfrD8plA4xYokXKqjZAfwQOgJCmrfO2+IxRIKbXS27m3?=
 =?us-ascii?Q?lWywvWOGb85LnRpLWBPdJ1G13FbqI46dOE9cnqGlMFxBmR54Gu4vqgRjrTEG?=
 =?us-ascii?Q?w1wNjJTktF+kUaFlLh8iS7mAUlV7B4bbZ/8Smjx4seRcOi7foClfmVVoX2te?=
 =?us-ascii?Q?7X6qFFaWqnpdaa/34SwlC9tVQetYmApCEH8goAhk37xRogU6HzAskaYK5+3d?=
 =?us-ascii?Q?eYx8M6oW3gmPUjdI7Xo6RP69BZHXm9gLOizNUWDBPSdamSzjyPJoYfK0UlkH?=
 =?us-ascii?Q?DrVUtN8jqGQiIDQJdF7f0W+z5rIzgzA9KNbV+J3/z8Dk2BtrO4lAN29bGPHX?=
 =?us-ascii?Q?+sQjjBXdEf9iNZJQ6ck3knxo9ykVtwTeejUQLo9WQswi7eGxrLBrNP/xEjCw?=
 =?us-ascii?Q?/P+Xr5EeVGKRZXdCkRuDv2/FiZihkvqk62sAyzQyW74WCSkGWbaV0Zllr9TH?=
 =?us-ascii?Q?YbDw+mgS1NwAObHhc4Wlwxa/VPMIaInTUoqkrn7qjTLD51+QbtLZ/ATk5Tyk?=
 =?us-ascii?Q?0XHKSxw7F4Zc/poN2bvKFSReb730I7k8zbeBmG4D3GlhhBeRAZ//HLuZlXdj?=
 =?us-ascii?Q?V7NmbmvM/0Gp+MXERWJYZVIjgcPimF1o3C1+hWRZi5D8ggceH5yqIM8HHP2p?=
 =?us-ascii?Q?BCXqj3DQjZHhCc9sc5Q6W0j1YcIjHHRUyX29oBEWJ7vgVqGy7O/S5npHJXij?=
 =?us-ascii?Q?y/SeImO8p7t+Yd4AehgoatZgFwCwn4nEPvh7C1hasL1yolSziZh1eFR1I/KX?=
 =?us-ascii?Q?VDzUG5c1w3h/o3GZu+/f+OpJM1Y35lMbqyzIbF5XZcgPq0fAXCFjA0ZrUCCi?=
 =?us-ascii?Q?ny5IjW+djRJmAc4rATzTsJ4P3diI4j9X1CrFWX2tzciIIeop3g2vOp25OBS6?=
 =?us-ascii?Q?Cbsf1IRk74pqvNd61k59V/4Prm+XKwJvr764rP75r2NkrcSXQyWDjUBo227l?=
 =?us-ascii?Q?p6WYPS1FFLPsm6HtCEPj5JljE/TUkQEQFAwJ?=
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: 05 Jun 2025 19:49:09.9891
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 096e87a5-0baf-44b1-469e-08dda46a0a27
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:
	BN2PEPF000055DB.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB9080

This will be required later by x86 code in order to do early identification
of boot modules when booting off a DTB.

Not a functional change.

Signed-off-by: Alejandro Vallejo 
Reviewed-by: Stefano Stabellini 
---
 xen/common/device-tree/bootfdt.c      | 18 ++++++++++++++++++
 xen/common/device-tree/bootinfo-fdt.c | 16 +---------------
 xen/include/xen/bootfdt.h             |  7 +++++++
 3 files changed, 26 insertions(+), 15 deletions(-)

diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
index 6acf83d197..474d719d2f 100644
--- a/xen/common/device-tree/bootfdt.c
+++ b/xen/common/device-tree/bootfdt.c
@@ -4,6 +4,24 @@
 #include 
 #include 
 
+bootmodule_kind __init fdt_node_to_kind(const void *fdt, int node)
+{
+    if ( fdt_node_check_compatible(fdt, node, "xen,linux-zimage") == 0 ||
+         fdt_node_check_compatible(fdt, node, "multiboot,kernel") == 0 )
+        return BOOTMOD_KERNEL;
+    if ( fdt_node_check_compatible(fdt, node, "xen,linux-initrd") == 0 ||
+         fdt_node_check_compatible(fdt, node, "multiboot,ramdisk") == 0 )
+        return BOOTMOD_RAMDISK;
+    if ( fdt_node_check_compatible(fdt, node, "xen,xsm-policy") == 0 )
+        return BOOTMOD_XSM;
+    if ( fdt_node_check_compatible(fdt, node, "multiboot,device-tree") == 0 )
+        return BOOTMOD_GUEST_DTB;
+    if ( fdt_node_check_compatible(fdt, node, "multiboot,microcode") == 0 )
+        return BOOTMOD_MICROCODE;
+
+    return BOOTMOD_UNKNOWN;
+}
+
 uint32_t __init device_tree_get_u32(const void *fdt, int node,
                                     const char *prop_name, uint32_t dflt)
 {
diff --git a/xen/common/device-tree/bootinfo-fdt.c b/xen/common/device-tree/bootinfo-fdt.c
index 695c4bfc49..20821e9ee8 100644
--- a/xen/common/device-tree/bootinfo-fdt.c
+++ b/xen/common/device-tree/bootinfo-fdt.c
@@ -236,21 +236,7 @@ static void __init process_multiboot_node(const void *fdt, int node,
 
     cell = (const __be32 *)prop->data;
     device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
-
-    if ( fdt_node_check_compatible(fdt, node, "xen,linux-zimage") == 0 ||
-         fdt_node_check_compatible(fdt, node, "multiboot,kernel") == 0 )
-        kind = BOOTMOD_KERNEL;
-    else if ( fdt_node_check_compatible(fdt, node, "xen,linux-initrd") == 0 ||
-              fdt_node_check_compatible(fdt, node, "multiboot,ramdisk") == 0 )
-        kind = BOOTMOD_RAMDISK;
-    else if ( fdt_node_check_compatible(fdt, node, "xen,xsm-policy") == 0 )
-        kind = BOOTMOD_XSM;
-    else if ( fdt_node_check_compatible(fdt, node, "multiboot,device-tree") == 0 )
-        kind = BOOTMOD_GUEST_DTB;
-    else if ( fdt_node_check_compatible(fdt, node, "multiboot,microcode") == 0 )
-        kind = BOOTMOD_MICROCODE;
-    else
-        kind = BOOTMOD_UNKNOWN;
+    kind = fdt_node_to_kind(fdt, node);
 
     /**
      * Guess the kind of these first two unknowns respectively:
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index a87b5212a6..13d19562c7 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -115,4 +115,11 @@ uint32_t device_tree_get_u32(const void *fdt, int node,
 void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
                          uint32_t size_cells, paddr_t *start, paddr_t *size);
 
+/*
+ * Probe an FDT node thought to be a boot module to identify its kind.
+ *
+ * If correctly identified, returns the detected kind, otherwise BOOTMOD_UNKNOWN
+ */
+bootmodule_kind fdt_node_to_kind(const void *fdt, int node);
+
 #endif /* XEN_BOOTFDT_H */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 19:51:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 19:51:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007531.1386852 (Exim 4.92)
	(envelope-from )
	id 1uNGcS-0002If-CH; Thu, 05 Jun 2025 19:51:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007531.1386852; Thu, 05 Jun 2025 19:51:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNGcS-0002HU-3O; Thu, 05 Jun 2025 19:51:20 +0000
Received: by outflank-mailman (input) for mailman id 1007531;
 Thu, 05 Jun 2025 19:51: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 1uNGat-0002tD-TO
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 19:49:43 +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 39378f82-4246-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 21:49:43 +0200 (CEST)
Received: from BN9PR03CA0349.namprd03.prod.outlook.com (2603:10b6:408:f6::24)
 by IA1PR12MB6650.namprd12.prod.outlook.com (2603:10b6:208:3a1::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.33; Thu, 5 Jun
 2025 19:49:38 +0000
Received: from BN2PEPF000055DA.namprd21.prod.outlook.com
 (2603:10b6:408:f6:cafe::2b) by BN9PR03CA0349.outlook.office365.com
 (2603:10b6:408:f6::24) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.27 via Frontend Transport; Thu,
 5 Jun 2025 19:49:38 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN2PEPF000055DA.mail.protection.outlook.com (10.167.245.4) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.2 via Frontend Transport; Thu, 5 Jun 2025 19:49:38 +0000
Received: from xcbagarciav01.xilinx.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, 5 Jun
 2025 14:49:06 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 39378f82-4246-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=N8938yO0mVKFuKWFi7rxf9enYJSyo2gaPVFbb63KOvXODb5GiFQDyUvP6kx6afgJoP+REP6BpR71ros2PPqiSHO0hVpsF7B4fvngyA3eBojqxtXiKYaN6xOo3rve8HGTCO9LJ08uJ3UzhEt8O6VvFo9jm1AxqgvvtQSOezLcY9hgwCdz6RBMlRxOkwh8pl4U5hvgAeuHdnB8j/tH5kFx8FYkCexkHidt9bzmWCbxolMo0fuf+mt1zj6/Nvie8ZXzdzpgeCPYBkR076CXCJAQBl3Uo7WKfluzRWWXF5LlbUYvkLm3HmSTZVNEKawTpHcvPcV9diKGQxn6xhsk0QCsGA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=gdndZEIM1HxoHu9OMJDmh4wFBWnq69aZLgl89O7wXQ8=;
 b=gpbOMfTauuQiv6AUE7+ljh1bmECDN8eQqgqv1qRaSX+SSujkXAqtvWsFYoQqRTy/coO908dGZV7ytOQdckLjfe1a/2jsT2+A4wjV0aOIWa354NC59YD+CoIakRgMzCzW1T8Ro3lmYJcqKd75Sj4WkRb4Ttg47QIHi0LR0HWLrg+A6PpU+Soe/TyP3LN+jGAJSC3ufu0SFSl8mfh/LX5t1dn2cssm0dNpj4DFs1elvawIU3aIJRLgNwMbyxrVPxcdt2+2P+oJbVXzPQPCENI9uaOWOKV+b3NSYrOkcrGUADrbEWjcWDyiCsn39Ygoy+oyKng6fqLb5CvfNhLrmX3hpQ==
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=gdndZEIM1HxoHu9OMJDmh4wFBWnq69aZLgl89O7wXQ8=;
 b=ZJ4jUrHeHkz2O3HBl0xvbdZf/ChwqPas1rOjb0SU11xVTf63cSOndKs40VIXK+3Xbi1/AdbYyUPsgyrD9Lm1C9P2YlON/9c7eo3xphMJ8Dbkxois5oMwrIpokjnf8NPGeM7p9oLfGEOMdhrjl35oO2IiHkFmajYpB1mbM7AIp+k=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , "Julien
 Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Stefano Stabellini ,
	"Bertrand Marquis" , "Daniel P. Smith"
	
Subject: [PATCH v2 14/15] xen/dt: Allow CONFIG_DOM0LESS_BOOT to include device-tree/
Date: Thu, 5 Jun 2025 21:48:06 +0200
Message-ID: <20250605194810.2782031-15-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250605194810.2782031-1-agarciav@amd.com>
References: <20250605194810.2782031-1-agarciav@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: BN2PEPF000055DA:EE_|IA1PR12MB6650:EE_
X-MS-Office365-Filtering-Correlation-Id: b99fce7d-d344-409b-2887-08dda46a1b5d
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:
	=?us-ascii?Q?T/loZNKjtCnzwQmmvvxW34ZQfZoIIfAM711B7nVMHRAWVzcyNzyApAvX39aw?=
 =?us-ascii?Q?nGSPJ0OZR044qBhJCIFoGUKI7nen+dHGfe8VCsuiZ39EqvBHEU5jWZC3bQ9h?=
 =?us-ascii?Q?CFPJUc8FBBiVc7krjYbxo2egPAwZqaikQc8V6OAHqWs5qBwiEA2cdHtktmpg?=
 =?us-ascii?Q?f0asplYIraHhME8ZhwYiqQjHAQ2RoZDqaVs/pI7Ia7LOVfJrlHkNDXmFr+3N?=
 =?us-ascii?Q?/wy2UO9uinJKpVniEOlZ8AsBz7YEaePCPwuVWFyA8HzU8VmZIXmZjTb1FqFv?=
 =?us-ascii?Q?cdmKMvMdvSrbm9KHd8Ck1D1oIhD6KjefMcTts7NYmICQpt+d9uFtlQd4Fv16?=
 =?us-ascii?Q?RjXVtdWsa6J3oxkW43K+WsBSlVjLOF8kq8uk0EdTfoqN/BjcUWt4U9yb3n48?=
 =?us-ascii?Q?3wzepptsnsxcINoEoZ3eVr+YXj1X9fRHIIMCXSlLQnJkhflerW3HwGPyS96E?=
 =?us-ascii?Q?00iMBcO7lYvWCsaChXUdCa0WI36bghIdUlXqLC+KipbdAg5hVo+eyIWKHCdx?=
 =?us-ascii?Q?idIJnoQUV764jic/FLZcskUg3cdIBvJ6Yyfhd3nvKLDBPnfs7KpcRE2qDL5A?=
 =?us-ascii?Q?mnzGPcYlItCrZ5RtxX2zwhgL11jcP6y1eOQldQ81liyQXDpGqNc2N+42zRtc?=
 =?us-ascii?Q?MFoMh6xUV7hupYvsEYOe/EzQLwkFCNGrSihhImwtRE1RzZIMqS+vEqqLquu5?=
 =?us-ascii?Q?D3w2CHDdUwkm6zsG3aQtoGmK3Zs6HqCV4dFmT033KvhlXn5fbv0eCHAxumxO?=
 =?us-ascii?Q?V50TEjpiOsFf/rubkL3RPGJTWzCJCslsm617AAo48SsLuyVmf8YKSaOpTPaH?=
 =?us-ascii?Q?lFYC48k6e1rxtn1bWU8IajKDA+Dn1ywWN4Ve/pmdcFof/+XBTkEQO6aFzI2Q?=
 =?us-ascii?Q?8sC2P91M2l5PUBuXKGSS7Cz6Jjl625dWtapGtLdEmw2VCUQtuP12M7FufSSH?=
 =?us-ascii?Q?NjpvXdMetStevct7CIkl4dH6PhBgr6sK5AMDWud+jpqo4ze5XIyFRFU5QzKM?=
 =?us-ascii?Q?GsJC/raDFFjm13QY75K68lwcvBnu+vNOc1sr6+I7zbtXmYLSjYsqGnMDiHKj?=
 =?us-ascii?Q?/xfG4zlny1ePo0Mt/fqsnzuxANLEWyidxo1VZ7weWV6kaZbGmvYAwT1vryU/?=
 =?us-ascii?Q?xQZLSKMtNwCT4C4GzDyy94tKMItDQ3pxyk6KdIchuIWyi09pR9uRR/h/zE/4?=
 =?us-ascii?Q?Al708fxuN9t7Jm9VBYcdNv9mETY5dhqmiO5jEn5r9S32aoOy+l8kuNFG2U1z?=
 =?us-ascii?Q?RArnJxCcDYX6Czi0m77fjTO430ZtC+0JltsE6+iMsQiM5E2MjFXyxIneR4PL?=
 =?us-ascii?Q?RSgh5tqs1sejxNfAIl1B8KjeVFzLmPZ92viNC5eo9/CkgRZtWlRA2zRqAZ9v?=
 =?us-ascii?Q?IdVQuMbER4Vz34/FPUm/BPPHALQnC+EG2qNYl0FBe0yJiRiyW47l6Ydrtpl9?=
 =?us-ascii?Q?uE6kKZG9XqkikGCQMgg8aydBlnvDH3VewOQIPOFxY6Mw5sQNTb15smzmQt3b?=
 =?us-ascii?Q?tHKHk7P1cdfVgTnVsGk2N8JrDH3kCEbdOK0/?=
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)(82310400026)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jun 2025 19:49:38.8622
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b99fce7d-d344-409b-2887-08dda46a1b5d
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:
	BN2PEPF000055DA.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB6650

... without CONFIG_HAS_DEVICE_TREE

Signed-off-by: Alejandro Vallejo 
---
 xen/common/Kconfig              | 1 +
 xen/common/Makefile             | 2 +-
 xen/common/device-tree/Makefile | 8 ++++----
 3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index eece1370a3..5353874e87 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -14,6 +14,7 @@ config CORE_PARKING
 
 config DOM0LESS_BOOT
 	bool "Dom0less boot support" if EXPERT
+	select LIBFDT
 	depends on HAS_DOM0LESS && HAS_DEVICE_TREE && DOMAIN_BUILD_HELPERS
 	default y
 	help
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 98f0873056..2717c81f9c 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -8,7 +8,7 @@ obj-y += cpu.o
 obj-$(CONFIG_DEBUG_TRACE) += debugtrace.o
 obj-$(CONFIG_HAS_DEVICE_TREE) += device.o
 obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) += device.o
-obj-$(CONFIG_HAS_DEVICE_TREE) += device-tree/
+obj-$(firstword $(CONFIG_HAS_DEVICE_TREE) $(CONFIG_DOM0LESS_BOOT)) += device-tree/
 obj-$(CONFIG_IOREQ_SERVER) += dm.o
 obj-y += domain.o
 obj-y += event_2l.o
diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
index 8abc069c4b..cc56f42df9 100644
--- a/xen/common/device-tree/Makefile
+++ b/xen/common/device-tree/Makefile
@@ -1,11 +1,11 @@
 obj-y += bootfdt.init.o
-obj-y += bootinfo-fdt.init.o
-obj-y += bootinfo.init.o
-obj-y += device-tree.o
+obj-$(CONFIG_HAS_DEVICE_TREE) += bootinfo-fdt.init.o
+obj-$(CONFIG_HAS_DEVICE_TREE) += bootinfo.init.o
+obj-$(CONFIG_HAS_DEVICE_TREE) += device-tree.o
 obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.init.o
 obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.init.o
 obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o
-obj-y += intc.o
+obj-$(CONFIG_HAS_DEVICE_TREE) += intc.o
 obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o
 obj-$(CONFIG_STATIC_EVTCHN) += static-evtchn.init.o
 obj-$(CONFIG_STATIC_MEMORY) += static-memory.init.o
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 20:05:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 20:05:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007570.1386867 (Exim 4.92)
	(envelope-from )
	id 1uNGpr-00068R-KN; Thu, 05 Jun 2025 20:05:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007570.1386867; Thu, 05 Jun 2025 20:05:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNGpr-00068K-HT; Thu, 05 Jun 2025 20:05:11 +0000
Received: by outflank-mailman (input) for mailman id 1007570;
 Thu, 05 Jun 2025 20:05: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 1uNGpq-00068E-1x
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 20:05:10 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on2061c.outbound.protection.outlook.com
 [2a01:111:f403:2408::61c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5fb22deb-4248-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 22:05:07 +0200 (CEST)
Received: from MW4PR03CA0348.namprd03.prod.outlook.com (2603:10b6:303:dc::23)
 by CY8PR12MB7362.namprd12.prod.outlook.com (2603:10b6:930:52::5) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Thu, 5 Jun
 2025 20:05:02 +0000
Received: from CO1PEPF000066E8.namprd05.prod.outlook.com
 (2603:10b6:303:dc:cafe::5f) by MW4PR03CA0348.outlook.office365.com
 (2603:10b6:303:dc::23) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.29 via Frontend Transport; Thu,
 5 Jun 2025 20:05:02 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CO1PEPF000066E8.mail.protection.outlook.com (10.167.249.6) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Thu, 5 Jun 2025 20:05:01 +0000
Received: from xcbagarciav01.xilinx.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, 5 Jun
 2025 14:48:57 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5fb22deb-4248-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=vf5AAkYsdY9rqGuzQviVB4rpgP7ycKTcJ8tkI71TXoVkbM2gLJK1xuwWhICnaaAZ1FgVjB/WHT4WGx55R70ZkpmGGNbpzMNbJ1nh2EJrjklo171qP5gUOGgsLXehDA7hDB9WSpe8N9+iD67sQqb4BLdXCuMap7QLFwgaTUN52AVIp/koSTd3KMUC3nlWUlzOfLw9nbkW9I+Wej715S6h3yizvuSE3EKilIKe8j9mqESuiOxi22deLEGOJCCx1E40Rb9S621Cd3lway56EX0s/rNAQmqFuCH0amZ3GpZ2YobWmKus69h5qjXP3h/feRWdOBb6HphMIADstqdolMX7dQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=hou+jj44bbtPOsTjw0RXt40/BL0AezOYjWqTEtsXsjI=;
 b=yukSyFN16oOwDmJdRwfMkzed8uWMWkJ4h67rb+hXFKwTh6kFJVUZuKKbeM8Daz6kf08zYgPCiq9nRF1qHYyDtqtsFF0Sdy8D5sv/K0zsE5lNjVBHq0uY1adPhD+UDlcDZwViCb5oWRso5PSZw3fK59GbZdZXuex3OmO1TomRCpQiapUgnGAbfj8ob3fiZ6z/BOTC38iNAufagnZIFKMKRhbgJt5VUcVPg0G1CTRKlKl3lvB+r1WgqEFPRTReJN2YyNVuIQrNSI3arFl08YVQdNzCuHUfmAhN9d3v9hFgqx58yICxlWpoq51U2RUzP+4OLMqTKUQDheK/V/B+eh87og==
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=hou+jj44bbtPOsTjw0RXt40/BL0AezOYjWqTEtsXsjI=;
 b=Ty1LG2/Y6YFnpgs04YbNd/yswvn9LgmmAseHTcfKhQ9UTq0tJ0zlLUMjt9TUJXTn3dwkY8bi+I6l9yEMI9ns3wML9W5szfwl30zzUWP+iT3z+lh790+PDbDF/pIpRa9436GP5ZEeZgmQhFRSDdYPlsgW24FXge61aPo024hY7Ks=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , 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"
	
Subject: [PATCH v2 09/15] xen/dt: Move bootinfo functions to a new bootinfo.h
Date: Thu, 5 Jun 2025 21:48:01 +0200
Message-ID: <20250605194810.2782031-10-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250605194810.2782031-1-agarciav@amd.com>
References: <20250605194810.2782031-1-agarciav@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: CO1PEPF000066E8:EE_|CY8PR12MB7362:EE_
X-MS-Office365-Filtering-Correlation-Id: e9937991-f520-49e2-dc97-08dda46c4117
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|82310400026|1800799024|376014|7416014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?/PheiT4Ra8FsN4mFx6kKXPjAdh0X2rIRL6pO1xwjpm50KloAe+CeqnUOTLPe?=
 =?us-ascii?Q?EIBVoWLmcRhBCpEZJp1fn1Wx11S4G+O3s4OtXLUCpZ7HpaFVmLrzWh0kWjdg?=
 =?us-ascii?Q?omNjHHGi4fEXeurfgNvJNiSc9thlUWcK45lS1aNZAyxl7PIHCqSatU68o+5X?=
 =?us-ascii?Q?1817Z85fUZGpxjqBYPeo6Ub0OmmgHew+cFS8JyQxaB36169frhjc0OpWoEcN?=
 =?us-ascii?Q?WlGlsll3AKVLW3sq1S6kB8/bVezJ1zgXd/2nEoeUC/tc2g075j6QaR59sYri?=
 =?us-ascii?Q?Xu+FaW7kDSjlGQk28Drw8SVXqFNGRXIdOhA4r63mbFTf9wbxCdDeVe+x3CG5?=
 =?us-ascii?Q?+iCxc4aPCtPV96FxGH3Yy5U5urOUQBE3adRxhLlAE7gokou9t1pVZcBMRraN?=
 =?us-ascii?Q?8dIhx9FABmWMyCbuRjRclxWRwOrm+FOfLEKL5d7PRtx7bYEm1cvDd68am7SS?=
 =?us-ascii?Q?xJtoYH/8W/XcDCeRMBPq2iPfuhfFi8O+oWihuajiPfm2mejcO7ZlbXGmA7lO?=
 =?us-ascii?Q?G4998W035mXH8vnjGRVwUgHH2dnlMG8/Qr3s9yUnq7Bc0e+ibVptmVNnHKDO?=
 =?us-ascii?Q?O7vr/B2QzZKn+I3ERKGtUtVSJ3Qiy7GuDK5aF01X3fVE2G1wo+CHu9bovpaC?=
 =?us-ascii?Q?3IENTrgaOohl7Xje4t95nHIbPwvB6zwALE02k7xhtsZdeLZJmelJPafHGNUZ?=
 =?us-ascii?Q?ASFnp2wBFMBCZeKQozidVzHwePq7M7Jy903WQejKVaAK5s4ky20Hb8xy47Z3?=
 =?us-ascii?Q?18Yp8UR0quf/Wel6jvcUelBRXXzrb+eOZNKCCDnINFilpUqgi/I++FTCoyt1?=
 =?us-ascii?Q?P4vu1uY8iw71LvacVXj3XdfyIIwVZqFmAgRh6hMIzv7VV//oab55mk6IUXGR?=
 =?us-ascii?Q?vgetG7jT3fGoak9ygBBJU1w44ujHP262cKGoQwW2XSgCriXIdyQ7thi6LRpP?=
 =?us-ascii?Q?cQF+JN+7qg5gooKEO6h4oI7UgF8MOHzcT8j+kVD9Ut2vngdeGhtSKtOoEck6?=
 =?us-ascii?Q?iUXC8XixWh9t2kVaJO/NPLMOqn2Gm6xzxIRRGvxX2Av05fQpK/0DmqDr4lcD?=
 =?us-ascii?Q?6xoQCYIzC/tG81ELMCibGSm9FMbABbGZImorK6MJqd432z96H6AcmMZpv/KO?=
 =?us-ascii?Q?qq2AvGM7NQPfWB59sXoPfodTTKqo/sjbct4QoUHiX2vSGD+xBfrh9f1gv76p?=
 =?us-ascii?Q?+5IuwmTbO88XvVp2JnGMypuV19cSL7OOaUlxvDKNEcrBXfoMNMYi3QM+p/BL?=
 =?us-ascii?Q?F0DkCG/zVKjHbYeo6My8EbfUPPXtxvWooN8FMvkxU0YAxlEntahdTG8V2/Hh?=
 =?us-ascii?Q?e0mEKEo3fA5CYKVoMUKV+MT/3rYSdlClaPuqSN1c7Ypg/BLKOYXlrAXPWQhy?=
 =?us-ascii?Q?6y/E4L6Y8MXjr2pwbZEQbvhkXs+7PoJ9+AJ236WPNW+mhYqSdDXos3CH7mt+?=
 =?us-ascii?Q?uI6OX4U+z50gejkNsu2a2T6lZN//6v9lfbaCJtdmiYAQsARtSNRgM/Sc/ffI?=
 =?us-ascii?Q?SUfWamJyYu6O7qIyjSv1ofs3T38fgLMU2z9j?=
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)(7416014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jun 2025 20:05:01.0503
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e9937991-f520-49e2-dc97-08dda46c4117
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:
	CO1PEPF000066E8.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7362

Part of an unpicking process to extract bootfdt contents independent of
bootinfo to a separate file for x86 to take.

With this, bootfdt.h can be cleanly included from x86. A later patch
extracts the definitions so the functions may be called too.

Not a functional change.

Signed-off-by: Alejandro Vallejo 
---
 xen/arch/arm/domain_build.c             |   1 +
 xen/arch/arm/mmu/mm.c                   |   1 +
 xen/arch/arm/setup.c                    |   1 +
 xen/arch/riscv/mm.c                     |   2 +-
 xen/arch/riscv/setup.c                  |   2 +-
 xen/common/device-tree/bootfdt.c        |   2 +-
 xen/common/device-tree/bootinfo.c       |   2 +-
 xen/common/device-tree/dom0less-build.c |   2 +-
 xen/common/device-tree/domain-build.c   |   2 +-
 xen/common/device-tree/kernel.c         |   2 +-
 xen/include/xen/bootfdt.h               | 208 -----------------------
 xen/include/xen/bootinfo.h              | 213 ++++++++++++++++++++++++
 xen/include/xen/device_tree.h           |   2 +-
 xen/include/xen/fdt-domain-build.h      |   2 +-
 xen/include/xen/fdt-kernel.h            |   2 +-
 15 files changed, 226 insertions(+), 218 deletions(-)
 create mode 100644 xen/include/xen/bootinfo.h

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 5317665555..497cfbe860 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1,5 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/arm/mmu/mm.c b/xen/arch/arm/mmu/mm.c
index 9c50479c63..77f82757bb 100644
--- a/xen/arch/arm/mmu/mm.c
+++ b/xen/arch/arm/mmu/mm.c
@@ -1,5 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-or-later */
 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 734e23da44..439b1d9df2 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -8,6 +8,7 @@
  * Copyright (c) 2011 Citrix Systems.
  */
 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
index 4047d67c0e..6ccd38091b 100644
--- a/xen/arch/riscv/mm.c
+++ b/xen/arch/riscv/mm.c
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 8bcd19218d..3e99e2e194 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -2,7 +2,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
index ab449db8d6..7ff62e1e3e 100644
--- a/xen/common/device-tree/bootfdt.c
+++ b/xen/common/device-tree/bootfdt.c
@@ -5,7 +5,7 @@
  * Copyright (C) 2012-2014 Citrix Systems, Inc.
  */
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/device-tree/bootinfo.c b/xen/common/device-tree/bootinfo.c
index 717cfa0962..69491bdb0b 100644
--- a/xen/common/device-tree/bootinfo.c
+++ b/xen/common/device-tree/bootinfo.c
@@ -10,7 +10,7 @@
  */
 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
index 809cb3c232..42165e78af 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/device-tree/domain-build.c b/xen/common/device-tree/domain-build.c
index e602cb91c9..80235aa56a 100644
--- a/xen/common/device-tree/domain-build.c
+++ b/xen/common/device-tree/domain-build.c
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/device-tree/kernel.c b/xen/common/device-tree/kernel.c
index 3960f951f7..0463bfd8df 100644
--- a/xen/common/device-tree/kernel.c
+++ b/xen/common/device-tree/kernel.c
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index 1b89986e10..a87b5212a6 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -4,9 +4,6 @@
 
 #include 
 #include 
-#include 
-#include 
-#include 
 
 #if __has_include()
 #include 
@@ -14,15 +11,10 @@
 
 #define MIN_FDT_ALIGN 8
 
-#define NR_MEM_BANKS 256
-#define NR_SHMEM_BANKS 32
-
 /* Default #address and #size cells */
 #define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
 #define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
 
-#define MAX_MODULES 32 /* Current maximum useful modules */
-
 #define DEVICE_TREE_MAX_DEPTH 16
 
 /* Helper to read a big number; size is in cells (not bytes) */
@@ -75,78 +67,6 @@ typedef enum {
     BOOTMOD_UNKNOWN
 }  bootmodule_kind;
 
-enum membank_type {
-    /*
-     * The MEMBANK_DEFAULT type refers to either reserved memory for the
-     * device/firmware (when the bank is in 'reserved_mem') or any RAM (when
-     * the bank is in 'mem').
-     */
-    MEMBANK_DEFAULT,
-    /*
-     * The MEMBANK_STATIC_DOMAIN type is used to indicate whether the memory
-     * bank is bound to a static Xen domain. It is only valid when the bank
-     * is in reserved_mem.
-     */
-    MEMBANK_STATIC_DOMAIN,
-    /*
-     * The MEMBANK_STATIC_HEAP type is used to indicate whether the memory
-     * bank is reserved as static heap. It is only valid when the bank is
-     * in reserved_mem.
-     */
-    MEMBANK_STATIC_HEAP,
-    /*
-     * The MEMBANK_FDT_RESVMEM type is used to indicate whether the memory
-     * bank is from the FDT reserve map.
-     */
-    MEMBANK_FDT_RESVMEM,
-};
-
-enum region_type {
-    MEMORY,
-    RESERVED_MEMORY,
-    STATIC_SHARED_MEMORY
-};
-
-/* Indicates the maximum number of characters(\0 included) for shm_id */
-#define MAX_SHM_ID_LENGTH 16
-
-struct shmem_membank_extra {
-    char shm_id[MAX_SHM_ID_LENGTH];
-    unsigned int nr_shm_borrowers;
-};
-
-struct membank {
-    paddr_t start;
-    paddr_t size;
-    union {
-        enum membank_type type;
-#ifdef CONFIG_STATIC_SHM
-        struct shmem_membank_extra *shmem_extra;
-#endif
-    };
-};
-
-struct membanks {
-    __struct_group(membanks_hdr, common, ,
-        unsigned int nr_banks;
-        unsigned int max_banks;
-        enum region_type type;
-    );
-    struct membank bank[];
-};
-
-struct meminfo {
-    struct membanks_hdr common;
-    struct membank bank[NR_MEM_BANKS];
-};
-
-struct shared_meminfo {
-    struct membanks_hdr common;
-    struct membank bank[NR_SHMEM_BANKS];
-    struct shmem_membank_extra extra[NR_SHMEM_BANKS];
-};
-
-
 struct bootdomain {
     struct domain *d;
 
@@ -179,134 +99,6 @@ struct bootmodule {
 #endif
 };
 
-/* DT_MAX_NAME is the node name max length according the DT spec */
-#define DT_MAX_NAME 41
-struct bootcmdline {
-    bootmodule_kind kind;
-    bool domU;
-    paddr_t start;
-    char dt_name[DT_MAX_NAME];
-    char cmdline[BOOTMOD_MAX_CMDLINE];
-};
-
-struct bootmodules {
-    int nr_mods;
-    struct bootmodule module[MAX_MODULES];
-};
-
-struct bootcmdlines {
-    unsigned int nr_mods;
-    struct bootcmdline cmdline[MAX_MODULES];
-};
-
-struct bootinfo {
-    struct meminfo mem;
-    /* The reserved regions are only used when booting using Device-Tree */
-    struct meminfo reserved_mem;
-    struct bootmodules modules;
-    struct bootcmdlines cmdlines;
-#ifdef CONFIG_ACPI
-    struct meminfo acpi;
-#endif
-#ifdef CONFIG_STATIC_SHM
-    struct shared_meminfo shmem;
-#endif
-};
-
-#ifdef CONFIG_ACPI
-#define BOOTINFO_ACPI_INIT                          \
-    .acpi.common.max_banks = NR_MEM_BANKS,          \
-    .acpi.common.type = MEMORY,
-#else
-#define BOOTINFO_ACPI_INIT
-#endif
-
-#ifdef CONFIG_STATIC_SHM
-#define BOOTINFO_SHMEM_INIT                         \
-    .shmem.common.max_banks = NR_SHMEM_BANKS,       \
-    .shmem.common.type = STATIC_SHARED_MEMORY,
-#else
-#define BOOTINFO_SHMEM_INIT
-#endif
-
-#define BOOTINFO_INIT                               \
-{                                                   \
-    .mem.common.max_banks = NR_MEM_BANKS,           \
-    .mem.common.type = MEMORY,                      \
-    .reserved_mem.common.max_banks = NR_MEM_BANKS,  \
-    .reserved_mem.common.type = RESERVED_MEMORY,    \
-    BOOTINFO_ACPI_INIT                              \
-    BOOTINFO_SHMEM_INIT                             \
-}
-
-extern struct bootinfo bootinfo;
-
-bool check_reserved_regions_overlap(paddr_t region_start,
-                                    paddr_t region_size,
-                                    bool allow_memreserve_overlap);
-
-struct bootmodule *add_boot_module(bootmodule_kind kind,
-                                   paddr_t start, paddr_t size, bool domU);
-struct bootmodule *boot_module_find_by_kind(bootmodule_kind kind);
-struct bootmodule * boot_module_find_by_addr_and_kind(bootmodule_kind kind,
-                                                             paddr_t start);
-void add_boot_cmdline(const char *name, const char *cmdline,
-                      bootmodule_kind kind, paddr_t start, bool domU);
-struct bootcmdline *boot_cmdline_find_by_kind(bootmodule_kind kind);
-struct bootcmdline * boot_cmdline_find_by_name(const char *name);
-const char *boot_module_kind_as_string(bootmodule_kind kind);
-
-void populate_boot_allocator(void);
-
-size_t boot_fdt_info(const void *fdt, paddr_t paddr);
-
-const char *boot_fdt_cmdline(const void *fdt);
-int domain_fdt_begin_node(void *fdt, const char *name, uint64_t unit);
-
-static inline struct membanks *bootinfo_get_reserved_mem(void)
-{
-    return container_of(&bootinfo.reserved_mem.common, struct membanks, common);
-}
-
-static inline struct membanks *bootinfo_get_mem(void)
-{
-    return container_of(&bootinfo.mem.common, struct membanks, common);
-}
-
-#ifdef CONFIG_ACPI
-static inline struct membanks *bootinfo_get_acpi(void)
-{
-    return container_of(&bootinfo.acpi.common, struct membanks, common);
-}
-#endif
-
-#ifdef CONFIG_STATIC_SHM
-static inline struct membanks *bootinfo_get_shmem(void)
-{
-    return container_of(&bootinfo.shmem.common, struct membanks, common);
-}
-
-static inline struct shmem_membank_extra *bootinfo_get_shmem_extra(void)
-{
-    return bootinfo.shmem.extra;
-}
-#endif
-
-static inline struct membanks *membanks_xzalloc(unsigned int nr,
-                                                enum region_type type)
-{
-    struct membanks *banks = xzalloc_flex_struct(struct membanks, bank, nr);
-
-    if ( !banks )
-        goto out;
-
-    banks->max_banks = nr;
-    banks->type = type;
-
- out:
-    return banks;
-}
-
 /*
  * Interpret the property `prop_name` of `node` as a u32.
  *
diff --git a/xen/include/xen/bootinfo.h b/xen/include/xen/bootinfo.h
new file mode 100644
index 0000000000..670fe771a4
--- /dev/null
+++ b/xen/include/xen/bootinfo.h
@@ -0,0 +1,213 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef XEN_BOOTINFO_H
+#define XEN_BOOTINFO_H
+
+#include 
+#include 
+#include 
+#include 
+
+#define NR_MEM_BANKS 256
+#define NR_SHMEM_BANKS 32
+
+#define MAX_MODULES 32 /* Current maximum useful modules */
+
+enum membank_type {
+    /*
+     * The MEMBANK_DEFAULT type refers to either reserved memory for the
+     * device/firmware (when the bank is in 'reserved_mem') or any RAM (when
+     * the bank is in 'mem').
+     */
+    MEMBANK_DEFAULT,
+    /*
+     * The MEMBANK_STATIC_DOMAIN type is used to indicate whether the memory
+     * bank is bound to a static Xen domain. It is only valid when the bank
+     * is in reserved_mem.
+     */
+    MEMBANK_STATIC_DOMAIN,
+    /*
+     * The MEMBANK_STATIC_HEAP type is used to indicate whether the memory
+     * bank is reserved as static heap. It is only valid when the bank is
+     * in reserved_mem.
+     */
+    MEMBANK_STATIC_HEAP,
+    /*
+     * The MEMBANK_FDT_RESVMEM type is used to indicate whether the memory
+     * bank is from the FDT reserve map.
+     */
+    MEMBANK_FDT_RESVMEM,
+};
+
+enum region_type {
+    MEMORY,
+    RESERVED_MEMORY,
+    STATIC_SHARED_MEMORY
+};
+
+/* Indicates the maximum number of characters(\0 included) for shm_id */
+#define MAX_SHM_ID_LENGTH 16
+
+struct shmem_membank_extra {
+    char shm_id[MAX_SHM_ID_LENGTH];
+    unsigned int nr_shm_borrowers;
+};
+
+struct membank {
+    paddr_t start;
+    paddr_t size;
+    union {
+        enum membank_type type;
+#ifdef CONFIG_STATIC_SHM
+        struct shmem_membank_extra *shmem_extra;
+#endif
+    };
+};
+
+struct membanks {
+    __struct_group(membanks_hdr, common, ,
+        unsigned int nr_banks;
+        unsigned int max_banks;
+        enum region_type type;
+    );
+    struct membank bank[];
+};
+
+struct meminfo {
+    struct membanks_hdr common;
+    struct membank bank[NR_MEM_BANKS];
+};
+
+struct shared_meminfo {
+    struct membanks_hdr common;
+    struct membank bank[NR_SHMEM_BANKS];
+    struct shmem_membank_extra extra[NR_SHMEM_BANKS];
+};
+
+/* DT_MAX_NAME is the node name max length according the DT spec */
+#define DT_MAX_NAME 41
+struct bootcmdline {
+    bootmodule_kind kind;
+    bool domU;
+    paddr_t start;
+    char dt_name[DT_MAX_NAME];
+    char cmdline[BOOTMOD_MAX_CMDLINE];
+};
+
+struct bootmodules {
+    int nr_mods;
+    struct bootmodule module[MAX_MODULES];
+};
+
+struct bootcmdlines {
+    unsigned int nr_mods;
+    struct bootcmdline cmdline[MAX_MODULES];
+};
+
+struct bootinfo {
+    struct meminfo mem;
+    /* The reserved regions are only used when booting using Device-Tree */
+    struct meminfo reserved_mem;
+    struct bootmodules modules;
+    struct bootcmdlines cmdlines;
+#ifdef CONFIG_ACPI
+    struct meminfo acpi;
+#endif
+#ifdef CONFIG_STATIC_SHM
+    struct shared_meminfo shmem;
+#endif
+};
+
+#ifdef CONFIG_ACPI
+#define BOOTINFO_ACPI_INIT                          \
+    .acpi.common.max_banks = NR_MEM_BANKS,          \
+    .acpi.common.type = MEMORY,
+#else
+#define BOOTINFO_ACPI_INIT
+#endif
+
+#ifdef CONFIG_STATIC_SHM
+#define BOOTINFO_SHMEM_INIT                         \
+    .shmem.common.max_banks = NR_SHMEM_BANKS,       \
+    .shmem.common.type = STATIC_SHARED_MEMORY,
+#else
+#define BOOTINFO_SHMEM_INIT
+#endif
+
+#define BOOTINFO_INIT                               \
+{                                                   \
+    .mem.common.max_banks = NR_MEM_BANKS,           \
+    .mem.common.type = MEMORY,                      \
+    .reserved_mem.common.max_banks = NR_MEM_BANKS,  \
+    .reserved_mem.common.type = RESERVED_MEMORY,    \
+    BOOTINFO_ACPI_INIT                              \
+    BOOTINFO_SHMEM_INIT                             \
+}
+
+extern struct bootinfo bootinfo;
+
+bool check_reserved_regions_overlap(paddr_t region_start,
+                                    paddr_t region_size,
+                                    bool allow_memreserve_overlap);
+
+struct bootmodule *add_boot_module(bootmodule_kind kind,
+                                   paddr_t start, paddr_t size, bool domU);
+struct bootmodule *boot_module_find_by_kind(bootmodule_kind kind);
+struct bootmodule * boot_module_find_by_addr_and_kind(bootmodule_kind kind,
+                                                             paddr_t start);
+void add_boot_cmdline(const char *name, const char *cmdline,
+                      bootmodule_kind kind, paddr_t start, bool domU);
+struct bootcmdline *boot_cmdline_find_by_kind(bootmodule_kind kind);
+struct bootcmdline * boot_cmdline_find_by_name(const char *name);
+const char *boot_module_kind_as_string(bootmodule_kind kind);
+
+void populate_boot_allocator(void);
+
+size_t boot_fdt_info(const void *fdt, paddr_t paddr);
+const char *boot_fdt_cmdline(const void *fdt);
+int domain_fdt_begin_node(void *fdt, const char *name, uint64_t unit);
+
+static inline struct membanks *bootinfo_get_reserved_mem(void)
+{
+    return container_of(&bootinfo.reserved_mem.common, struct membanks, common);
+}
+
+static inline struct membanks *bootinfo_get_mem(void)
+{
+    return container_of(&bootinfo.mem.common, struct membanks, common);
+}
+
+#ifdef CONFIG_ACPI
+static inline struct membanks *bootinfo_get_acpi(void)
+{
+    return container_of(&bootinfo.acpi.common, struct membanks, common);
+}
+#endif
+
+#ifdef CONFIG_STATIC_SHM
+static inline struct membanks *bootinfo_get_shmem(void)
+{
+    return container_of(&bootinfo.shmem.common, struct membanks, common);
+}
+
+static inline struct shmem_membank_extra *bootinfo_get_shmem_extra(void)
+{
+    return bootinfo.shmem.extra;
+}
+#endif
+
+static inline struct membanks *membanks_xzalloc(unsigned int nr,
+                                                enum region_type type)
+{
+    struct membanks *banks = xzalloc_flex_struct(struct membanks, bank, nr);
+
+    if ( !banks )
+        goto out;
+
+    banks->max_banks = nr;
+    banks->type = type;
+
+ out:
+    return banks;
+}
+
+#endif /* XEN_BOOTINFO_H */
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 0a22b1ba1d..7d1c8bc305 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -10,7 +10,7 @@
 #ifndef __XEN_DEVICE_TREE_H__
 #define __XEN_DEVICE_TREE_H__
 
-#include 
+#include 
 #include 
 
 #include 
diff --git a/xen/include/xen/fdt-domain-build.h b/xen/include/xen/fdt-domain-build.h
index 45981dbec0..60565fdbf9 100644
--- a/xen/include/xen/fdt-domain-build.h
+++ b/xen/include/xen/fdt-domain-build.h
@@ -3,7 +3,7 @@
 #ifndef __XEN_FDT_DOMAIN_BUILD_H__
 #define __XEN_FDT_DOMAIN_BUILD_H__
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/include/xen/fdt-kernel.h b/xen/include/xen/fdt-kernel.h
index dd009f01d0..cb211d242f 100644
--- a/xen/include/xen/fdt-kernel.h
+++ b/xen/include/xen/fdt-kernel.h
@@ -7,7 +7,7 @@
 #ifndef __XEN_FDT_KERNEL_H__
 #define __XEN_FDT_KERNEL_H__
 
-#include 
+#include 
 #include 
 #include 
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 20:59:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 20:59:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007592.1386876 (Exim 4.92)
	(envelope-from )
	id 1uNHfp-0005pn-EQ; Thu, 05 Jun 2025 20:58:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007592.1386876; Thu, 05 Jun 2025 20:58: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 1uNHfp-0005pg-Bg; Thu, 05 Jun 2025 20:58:53 +0000
Received: by outflank-mailman (input) for mailman id 1007592;
 Thu, 05 Jun 2025 20:58: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 1uNHfo-0005pa-M9
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 20:58:52 +0000
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com
 [2a00:1450:4864:20::229])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id df96ca3e-424f-11f0-a300-13f23c93f187;
 Thu, 05 Jun 2025 22:58:50 +0200 (CEST)
Received: by mail-lj1-x229.google.com with SMTP id
 38308e7fff4ca-32a61af11ffso15830671fa.1
 for ; Thu, 05 Jun 2025 13:58:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: df96ca3e-424f-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749157126; x=1749761926; 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=0TgkpRK/oltZr7kizvAssmxFNxTBwjN1tXXnvLvlvRo=;
        b=bOm6CrxrJ3Y78ch0JxUXCGX4R8xHY9k4EUhlehrnGfmHSTUDOrQ0XK1NLCjayJbHoz
         uPK/86mlrTZQ6mX+EJRfBh8+cyqNEnTEyzZLvE7N3LJqhDt4LduBjIkXzEEltJht4vCr
         VTdQZO0isTAp6icgO92LwWRyFELSNhZSGfYMMewAiE2wYeKDNiWi2FvPdRImwLVLu168
         02RH+iurDpPtnP1QTKFV/M7t1cR5258pCWSMTv0dEvRYJ5kIMp4ya6cAD1iuFoyqoHMd
         fPDQ546zXIE/4Gi024dxVb7z2i28ZpaZWRQNam5zpAg53S0Uno8zXxiWoUqcv6HVRLEZ
         y8iw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749157126; x=1749761926;
        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=0TgkpRK/oltZr7kizvAssmxFNxTBwjN1tXXnvLvlvRo=;
        b=JGxmSMXbeU07wJewslclbHpMebQAfiyZW2nL5+J48Gu3neV2B+30TtM3ZEqHWVBjUG
         c1Z94o5pNMtNGWONcAQkduM8hhwGPdQFeco0CDTveY22VWKtssvf71kS+KwhsvZRoVB8
         a3EC9lhb++RW3jQNZqetdRckRPz1trfGHwFBxDqOwV0RfypJjyQu8gZCJpFua0GTxgZF
         1OBg9aa5Cb3Mf8jr4jjUItgLXUqgri+yG/NfxYnoWSJO97SAvdJhlGmiYfvaAFZHwlJY
         /Uz42mGySh/GVpplUvU3+80try7Cw0ea0sj0wIlXgHcPOyNv3iutkK+EWwPkTrYNUkRR
         bS7A==
X-Gm-Message-State: AOJu0YxUstJ0toUsWn2G5rK1vUdElLvPc0S2ASMGQAFeTZ2neUQfN6wg
	d98hcYf6A57Yivj8w7QsA63uc5DaZSwhmarbcR8NoCWbSPPshiERSxwCRGv5Rr/OQqBJ+HcH0q5
	+nwdmGLYEziLN/TsBsp74VC8m4i6e5sY=
X-Gm-Gg: ASbGnctwDeiV0d46+Bvc1D6UlcZy8AZ3eF3NZ54KnNMc/sDLHhBLTEtWBcyMptF5Q/u
	MRVba9dXGsWwi5hy+z0JpW3vgcoiH5G8MiUijSXO1LM7rt5gj5m1XjepCvyKeO2nguQaLDUrIeT
	mYE5w+oCMP7z5QngdA/7/s6MpajYW058Q=
X-Google-Smtp-Source: AGHT+IGLAXRYJ1kj0oTaQ+zdoFvMv1FkKnoq45sTpsEu5vEl5dHXU5S4gdLBALfBiCfyHD84Hc0jXG6TIBHUbqJF8U0=
X-Received: by 2002:a05:651c:1a0c:b0:329:143e:ca3d with SMTP id
 38308e7fff4ca-32ad11c3e29mr15481731fa.11.1749157126118; Thu, 05 Jun 2025
 13:58:46 -0700 (PDT)
MIME-Version: 1.0
References: <20250528211040.10562-1-christopher.w.clark@gmail.com> 
In-Reply-To: 
From: Christopher Clark 
Date: Thu, 5 Jun 2025 21:58:34 +0100
X-Gm-Features: AX0GCFtqAAxkT7e_oERL_Qkze87xfEf3IKtv5qc-Rvr82bKQubYMW4WV68nKi10
Message-ID: 
Subject: Re: [PATCH v3 1/3] docs: add documentation for Argo as a feature
To: Teddy Astie 
Cc: xen-devel@lists.xenproject.org, 
	Daniel Smith , Rich Persaud , 
	Andrew Cooper , Anthony PERARD , 
	Michal Orzel , Jan Beulich , Julien Grall , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Stefano Stabellini 
Content-Type: multipart/alternative; boundary="00000000000028a3ce0636d961cd"

--00000000000028a3ce0636d961cd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, May 29, 2025 at 11:40=E2=80=AFPM Teddy Astie  wrote:

> Hello Christopher,
>

Hi Teddy, thanks for the review.


>
> Le 28/05/2025 =C3=A0 23:13, Christopher Clark a =C3=A9crit :
> > Adds approachable documentation describing system components and
> > introduces the support statement for feature status.
> ...
> > +# Overview
> > +
> > +Argo is a lightweight data transport for communication between virtual
> > +machines, with a simple hypervisor interface that is accessible for
> > +building embedded systems and designed to work with familiar primitive=
s
> > +within guest OS kernels. It supports policy control over communication
> > +and isolation between VMs.
> > +
> > +# User details
> > +
> > +Argo is present in Xen, included since Xen 4.12. A Linux device driver
> > +and userspace library are available and Argo is regularly tested in th=
e
> > +Xen Continuous Integration system.
> > +
>
> Not really related to the documentation itself, but it would be
> preferable to have the Linux driver upstreamed such as this sentence
> sounds more as "it is supported" rather than "it's possible to make it
> work".
>

I agree and I can work on a better description for the next posting.


>
> It would also make Argo easier to integrate in Xen-based projects.
>

Yes (for systems with Linux).


>
> > +To configure a Xen system to enable Argo:
> > +
> > +* ensure that Argo is enabled in the hypervisor with KConfig option
> > +
> > +* enable Argo on the Xen hypervisor command line
> > +
> > +* load the Argo guest kernel device driver
> > +
> > +* ensure that the Argo guest libraries are installed
> > +
> > +The guest userspace libraries support software designed for Argo
> > +interfaces and also enables software designed for networks to
> > +communicate between VMs by Argo.  This allows platform software to be
> > +plumbed easily between virtual machines, without requiring networking
> > +and with system policy controls over this communication.
> > +
> > +# Technical details
> > +
> > +## Argo components
> > +
> > +* Xen: Argo in the hypervisor provides communication between virtual
> > +  machines.
> > +
> > +* Guest kernel: driver provides interfaces for data transport for use
> > +  within the kernel, and implements familiar abstractions for
> > +  networking software.
> > +
> > +* Guest libraries: provide application-level support for interdomain
> > +  communication.
> > +
>
> That sounds a bit confusing to me, the guest kernel provides familiar
> abstractions for networking software (I hear through that something like
> sockets), yet we still have guest libraries for application-level support=
.
>
> I think the guest libraries provide a shim for some of the argo-specific
> aspects (like ioctls and sockaddr_argo related bits); while the
> interface is more unix-oriented with regular sockets operations
> (sendmsg, ...).
>

OK, I wasn't sure what level of detail would be wanted for this so it's
useful to know, thanks.


>
> > +## Argo implementation within Xen
> > +
> > +See the public Xen headers for the primary interface documentation.
> > +
>
> There is the design document in docs/designs/argo.pandoc that explains
> the inner design inside Xen. I think the public headers are more for
> guest consumption.
>

OK, I'll add reference to the design document.


>
> As this document also targets guest developers, it would be great to
> have some guidance (e.g a docs document) on how a guest should implement
> argo support.
>

Thanks, I appreciate the enthusiasm for it to be written!

best,

Christopher

--00000000000028a3ce0636d961cd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


    On Thu, May 29, 2025 at 11:40=E2=80=AFPM =
Teddy Astie <teddy.astie@vates.tech> wrote:
    Hello Christopher,

    Hi Teddy, thanks=
 for the review.
    =C2=A0
    

    
Le 28/05/2025 =C3=A0 23:13, Christopher Clark a =C3=A9crit=C2=A0:
    
> Adds approachable documentation describing system components and
    
> introduces the support statement for feature status.
    ...
    
> +# Overview
    
> +
    
> +Argo is a lightweight data transport for communication between virtua=
l
    
> +machines, with a simple hypervisor interface that is accessible for
> +building embedded systems and designed to work with familiar primitiv=
es
    
> +within guest OS kernels. It supports policy control over communicatio=
n
    
> +and isolation between VMs.
    
> +
    
> +# User details
    
> +
    
> +Argo is present in Xen, included since Xen 4.12. A Linux device drive=
r
    
> +and userspace library are available and Argo is regularly tested in t=
he
    
> +Xen Continuous Integration system.
    
> +
    

    
Not really related to the documentation itself, but it would be 
    
preferable to have the Linux driver upstreamed such as this sentence 
    
sounds more as "it is supported" rather than "it's possi=
ble to make it 
    
work".

    I agree and I can work on a=
 better description for the next posting.
    =C2=A0
    

    
It would also make Argo easier to integrate in Xen-based projects.

    Yes (for systems with Linux).
    =C2=A0<=
/div>
    

    
> +To configure a Xen system to enable Argo:
    
> +
    
> +* ensure that Argo is enabled in the hypervisor with KConfig option
> +
    
> +* enable Argo on the Xen hypervisor command line
    
> +
    
> +* load the Argo guest kernel device driver
    
> +
    
> +* ensure that the Argo guest libraries are installed
    
> +
    
> +The guest userspace libraries support software designed for Argo
    
> +interfaces and also enables software designed for networks to
    
> +communicate between VMs by Argo.=C2=A0 This allows platform software =
to be
    
> +plumbed easily between virtual machines, without requiring networking=

    
> +and with system policy controls over this communication.
    
> +
    
> +# Technical details
    
> +
    
> +## Argo components
    
> +
    
> +* Xen: Argo in the hypervisor provides communication between virtual<=
br>
> +=C2=A0 machines.
    
> +
    
> +* Guest kernel: driver provides interfaces for data transport for use=

    
> +=C2=A0 within the kernel, and implements familiar abstractions for
> +=C2=A0 networking software.
    
> +
    
> +* Guest libraries: provide application-level support for interdomain<=
br>
> +=C2=A0 communication.
    
> +
    

    
That sounds a bit confusing to me, the guest kernel provides familiar 
    
abstractions for networking software (I hear through that something like 
sockets), yet we still have guest libraries for application-level support.<=
br>

    
I think the guest libraries provide a shim for some of the argo-specific 
aspects (like ioctls and sockaddr_argo related bits); while the 
    
interface is more unix-oriented with regular sockets operations 
    
(sendmsg, ...).

    OK, I wasn't sure w=
hat level of detail would be wanted for this so it's useful to know, th=
anks.
    =C2=A0
    

    
> +## Argo implementation within Xen
    
> +
    
> +See the public Xen headers for the primary interface documentation.
> +
    

    
There is the design document in docs/designs/argo.pandoc that explains 
    
the inner design inside Xen. I think the public headers are more for 
    
guest consumption.

    OK, I'll add ref=
erence to the design document.
    =C2=A0
    

    
As this document also targets guest developers, it would be great to 
    
have some guidance (e.g a docs document) on how a guest should implement 
argo support.

    Thanks, I appreciate the =
enthusiasm for it to be written!

    best,
    <=
br>
    Christopher
    =C2=A0

    

--00000000000028a3ce0636d961cd--


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 21:30:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 21:30:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007617.1386887 (Exim 4.92)
	(envelope-from )
	id 1uNIAJ-0002pc-Tr; Thu, 05 Jun 2025 21:30:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007617.1386887; Thu, 05 Jun 2025 21:30: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 1uNIAJ-0002pV-R4; Thu, 05 Jun 2025 21:30:23 +0000
Received: by outflank-mailman (input) for mailman id 1007617;
 Thu, 05 Jun 2025 21:30: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 1uNIAI-0002p6-7K
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 21:30:22 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on2060f.outbound.protection.outlook.com
 [2a01:111:f403:2414::60f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 45edf36a-4254-11f0-b894-0df219b8e170;
 Thu, 05 Jun 2025 23:30:16 +0200 (CEST)
Received: from MN0PR03CA0006.namprd03.prod.outlook.com (2603:10b6:208:52f::26)
 by DM4PR12MB6064.namprd12.prod.outlook.com (2603:10b6:8:af::12) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Thu, 5 Jun
 2025 21:30:10 +0000
Received: from MN1PEPF0000F0E2.namprd04.prod.outlook.com
 (2603:10b6:208:52f:cafe::26) by MN0PR03CA0006.outlook.office365.com
 (2603:10b6:208:52f::26) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.27 via Frontend Transport; Thu,
 5 Jun 2025 21:30:09 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 MN1PEPF0000F0E2.mail.protection.outlook.com (10.167.242.40) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Thu, 5 Jun 2025 21:30:09 +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 Jun
 2025 16:30:08 -0500
Received: from [172.26.5.4] (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 Jun 2025 16:30:07 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 45edf36a-4254-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=LltGfoTmcVA8/teRyZ6q5TrFZgFDX9h2q5sRUPQjMCQZwNU2yoUgUOt1NrG71LHiJPZO/4B9mQCDEBr1eS3mqAFRuCiAvWvwnOcqZhiYpQNkMXkxzJsF1L3fVGMtwVurzoKFCxTr/sU8tfrWuK/NKgIZXVRnAFRBKtJ356UyYT67kmFzTSmz+ZsnAqXsf+0j0Nxcl2Zvsa6Rj5eV2lxnXpNL2ruRtndkGThaqv7YthB5R9bl9bIGx3m99Nqkto5msMu1Ins5ZM+qP2s/KEWGpt6YfragxUGrMwM8QZJnAkCPcNpQkyITjSSWSlMFuWeC5sBKrrDSjVZt8zQpreMofQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=g8Ch1cuPlQdbV1+LMksGfTsDEBPpIObOV7gI7mE0jc4=;
 b=QSR9AAAIXWj3ovZ2DDPDYvAM1SKi/F+NXxK+hwvFBnthS9thPdDYGff1huT3ZfdgEbi+F3sMqTZnCHyt34XfPAFSEUxcZ6XC70nUtQo7lit1a8881ehOduWlsn9nXC2jmg9PfvhdeSI/Cc4akzvVNzBXsVc3rJTqgjlk4UNbtbg7k93s1+jzTK7XpPBunF9yV6+8Hdiiiuo0H7i+QacQqymeoLEtoqC546BF45ymthfJsQ7J7QSFwIl5ykNGihUSNFBCpJeJJFfLmaKYDfr2Dggon0MLzRBxRwCeEAgw8evpQNfblZJDKswtFJsakqYxF86mNDb+BpkXMKmt7ZeKGg==
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=g8Ch1cuPlQdbV1+LMksGfTsDEBPpIObOV7gI7mE0jc4=;
 b=UOhbnq4tVayvuZ0fDqZiDT/HuNsrlpMSiGNPwea3YQzn6A32atcK4+DrX53864S1PI6r4GPYiGwXSWX5cZqO0pDdl7mOXyhUTb+QDk1ZE0SF5OesdQA+DP/yibqnWH9EDkdAG0zto9HcLZnXHQHTT/TUJtZcDCRU6vKHA6GsS08=
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 Jun 2025 17:30:07 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/2] xen/arm: exclude xen,reg from direct-map domU
 extended regions
To: "Orzel, Michal" , 
CC: Stefano Stabellini , Julien Grall
	, Bertrand Marquis , "Volodymyr
 Babchuk" , Andrew Cooper
	, Anthony PERARD , "Jan
 Beulich" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	
References: <20250513195452.699600-1-stewart.hildebrand@amd.com>
 <20250513195452.699600-2-stewart.hildebrand@amd.com>
 <54c3d341-1d7f-428d-89a7-ce4fcae8a5db@amd.com>
 <4bd41362-6ee4-44d7-9f9b-0ffd78f1e6f8@amd.com>
 <28b22fa6-c6f9-463e-8e7e-0a00eae88737@amd.com>
 
 <861e66c8-c225-4913-b00e-4dfb2c1e0e39@amd.com>
Content-Language: en-US
From: Stewart Hildebrand 
In-Reply-To: <861e66c8-c225-4913-b00e-4dfb2c1e0e39@amd.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
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: MN1PEPF0000F0E2:EE_|DM4PR12MB6064:EE_
X-MS-Office365-Filtering-Correlation-Id: 5ad4a97e-9b9d-4eba-e760-08dda4782602
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?L2ZyMHhVandnL09tcW1DUFJacjlnRStmK1haQ3kxYmNwM29ZQXBNWHRBL2Y3?=
 =?utf-8?B?SUN4Tzl0U040ODZjQ1lsNkdQMlpxN1VsOGJQdFdFN0FzRjM1OWl4SjNHMWt0?=
 =?utf-8?B?UnVZNldrYUF3ZzltMFdBQ3VpZ1Rwc2JSN0hrcGhIc3hIOXdsbFBqclpqRGdN?=
 =?utf-8?B?T29CL1JoU0JCRVF0TEx0Q1NXVnY1aldOWmduUE5Ya0VBcDZLNThqQWg1b3NV?=
 =?utf-8?B?eVViTHRndkI4MlFmemZWQ0RrTGZIYmJoeG9LcTNuWWV6eVVWcTFEaWpoZFdI?=
 =?utf-8?B?ZVk0T3Bsb0F3TENTMTF0T3R5Wm1qWk9TNUo3SjdLSThBOEk5OU5IQzBIS0tv?=
 =?utf-8?B?RFY4OW1ndHF3cFFGRnlYb1h1Tkhpb1FoQ1RSODdzUGVFbDVxamVoWmQ1eC9a?=
 =?utf-8?B?UUdQdWE5b0RCclpVNzVxRTFlRmg0aU1kU2JXcnpacDJLaGFmZ01WTmFURHQ3?=
 =?utf-8?B?MGdySkZkR1JaSDgwNHJxWlJXaU1EY0Y1cFZYQ0ZqV3JFKzU4OENLWUMrSXht?=
 =?utf-8?B?TU4vSXFVMDYxQ2l3M21ZSWI2SGQrVlJNL1ZKNGIxdlQxTTV2RVo0M25zczlr?=
 =?utf-8?B?YTQ0M0NzZ1A2TVZOa0M3bUxIRGV5OWFLb1ptTWh2aHVwaEJJNGNEVktWTmZJ?=
 =?utf-8?B?OFZPOHVIdThqd0pkNVpWeUx1djg0b3ZSK3dDMW9xQXkyNDUyOUhxeGZTamF2?=
 =?utf-8?B?RDRpV1pxOHpQdUs3RnoxQlZXMFVuWEYrKzZUc1VoalRQUXNibXpiVEUrSlRF?=
 =?utf-8?B?SVRpTnFuTUdLMHhNLzZWT0VWTytVY1dubXJPMmI1dFUwdWFOUGI5MHBVeW1G?=
 =?utf-8?B?a0NheFlQeTFZendHNFV5WC84SVJwV1U1R0JzWFZaS203SGM4OWt0QzNEVGZJ?=
 =?utf-8?B?T0syRjNjejRnM081WUU2RG0zNWZhaUJqTDFqbzQxZmlJL3VNMGRySlk2dzFZ?=
 =?utf-8?B?cDRKSU1HV2ZOazNqVklGWWhqTHJKaWRySUYwRlNwWkxDZ3I5N0RTVGFJZXZG?=
 =?utf-8?B?WXJiS0x4MjNVZCtkQnZOLzd1L0NrU24xSHRwVWJRUkxGMmhBSEZPelA5L29P?=
 =?utf-8?B?a0R6VnZ6Y3J0alF3aC8wUGxRSGw5bGluUHN4OWI3ZEJFeXNSTDFtRjF4ZVFH?=
 =?utf-8?B?eHdIN2pYNzFuYXVMOE1TaGRjL3ZaTkwrWXdtSmE1bUtxaVNuUkpldnpvLzhC?=
 =?utf-8?B?a2VlMm1CVCs2UVNzb2k2aG11ZnRyWmkwWXRybjlQYVkwRHJDZ01VbFFJS2NU?=
 =?utf-8?B?ZmFYbHIzZ0Z1clJrM1cwOW1kWkNaWFhzN1lTMVZRN3pjSHhOT1hnd0NUY3Zp?=
 =?utf-8?B?MmpnM25WZnFNOTZ5aDVlTzdONW9qcC96K1djNmtyK2xxRUp6ZmtUdXZlM1JC?=
 =?utf-8?B?cDU3cENFTEdHaTU4ZnlDSlFQQVZtdHpwSy8xR2Q2WkxGOXBtT2ZhZ3ZUMDF4?=
 =?utf-8?B?eGJZWGpDYXNobTgxUU5TbVhPWFBJR1I4c0Z3YlpFbHBrTVJ5SmswdUN6R2Rl?=
 =?utf-8?B?NUMvc2FXeDZmT2JzQUtPMDVsTWNmc3NJMVh1Z3VqNjM4QXFiS3NmSXZsMVo0?=
 =?utf-8?B?cnJBeVFjOG5iM1FJZTN5MVFDc05HTVRMZjFaZUlTQU00bk50VHV2emVsenly?=
 =?utf-8?B?K0ZDdU5wZUJha0QvWWhtQnF0RWZpVmJ6NU94RWdqUTdRMkpMbTY2L1Qzd1JH?=
 =?utf-8?B?YloxcXJEaldPWmp3WDVQRGFFQTh1bW9iQVUreDhmMlBzSThRSi94VmhCdDBt?=
 =?utf-8?B?d2MrbjVFL2FFSWJTY2NaV3JzWjN6Z2hSdWpEbTdHRnVUMzRHUzdablA2Z0Fv?=
 =?utf-8?B?TEJXZXExbDVJbXdwems4b25nYUROV0pTZGZna1FCSnp1akRiTHRsVEtxRy9k?=
 =?utf-8?B?UzZESWJaRGtxZlVtNzNpRm4xdE9hdFRCeUtaS0M5Sll0Nmk1Q204VXZtNFpa?=
 =?utf-8?B?L3BLSzVEZ0pvWm1oK29iVkxZbDlRbDI0QWpWNHc3a2NYWGRTaS80MHlxVjh2?=
 =?utf-8?B?amI3Q2diZ3krNVJxUnpLdFpWT0UzWnRYUW1TZzk3Qk1pYmpMY3dNWllpWkxU?=
 =?utf-8?Q?4/dfYJ?=
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: 05 Jun 2025 21:30:09.6755
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5ad4a97e-9b9d-4eba-e760-08dda4782602
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:
	MN1PEPF0000F0E2.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6064

On 6/5/25 02:45, Orzel, Michal wrote:
> On 04/06/2025 21:51, Stewart Hildebrand wrote:
>> On 6/4/25 03:00, Orzel, Michal wrote:
>>> On 03/06/2025 23:15, Stewart Hildebrand wrote:
>>>> On 5/14/25 03:31, Orzel, Michal wrote:
>>>>> On 13/05/2025 21:54, Stewart Hildebrand wrote:
>>>>>> Similarly to fba1b0974dd8, when a device is passed through to a
>>>>>> direct-map dom0less domU, the xen,reg ranges may overlap with the
>>>>>> extended regions. Remove xen,reg from direct-map domU extended regions.
>>>>>>
>>>>>> Introduce rangeset_count_ranges().
>>>>>>
>>>>>> Take the opportunity to update the comment ahead of find_memory_holes().
>>>>>>
>>>>>> Signed-off-by: Stewart Hildebrand 
>>>>>> ---
>>>>>> v2->v3:
>>>>>> * new patch
>>>>>> ---
>>>>>>  xen/arch/arm/domain_build.c | 57 +++++++++++++++++++++++++++++++++----
>>>>>>  xen/common/rangeset.c       | 14 +++++++++
>>>>>>  xen/include/xen/rangeset.h  |  2 ++
>>>>>>  3 files changed, 68 insertions(+), 5 deletions(-)
>>>>>>
>>>>>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>>>>>> index b189a7cfae9f..3cdf5839bc98 100644
>>>>>> --- a/xen/arch/arm/domain_build.c
>>>>>> +++ b/xen/arch/arm/domain_build.c
>>>>>> @@ -824,15 +824,17 @@ static int __init handle_pci_range(const struct dt_device_node *dev,
>>>>>>  }
>>>>>>  
>>>>>>  /*
>>>>>> - * Find the holes in the Host DT which can be exposed to Dom0 as extended
>>>>>> - * regions for the special memory mappings. In order to calculate regions
>>>>>> - * we exclude every addressable memory region described by "reg" and "ranges"
>>>>>> - * properties from the maximum possible addressable physical memory range:
>>>>>> + * Find the holes in the Host DT which can be exposed to Dom0 or a direct-map
>>>>>> + * domU as extended regions for the special memory mappings. In order to
>>>>>> + * calculate regions we exclude every addressable memory region described by
>>>>>> + * "reg" and "ranges" properties from the maximum possible addressable physical
>>>>>> + * memory range:
>>>>>>   * - MMIO
>>>>>>   * - Host RAM
>>>>>>   * - PCI aperture
>>>>>>   * - Static shared memory regions, which are described by special property
>>>>>>   *   "xen,shared-mem"
>>>>>> + * - xen,reg mappings
>>>>>>   */
>>>>>>  static int __init find_memory_holes(const struct kernel_info *kinfo,
>>>>>>                                      struct membanks *ext_regions)
>>>>>> @@ -914,6 +916,13 @@ static int __init find_memory_holes(const struct kernel_info *kinfo,
>>>>>>          }
>>>>>>      }
>>>>>>  
>>>>>> +    if ( kinfo->xen_reg_assigned )
>>>>>> +    {
>>>>>> +        res = rangeset_subtract(mem_holes, kinfo->xen_reg_assigned);
>>>>>> +        if ( res )
>>>>>> +            goto out;
>>>>>> +    }
>>>>>> +
>>>>>>      start = 0;
>>>>>>      end = (1ULL << p2m_ipa_bits) - 1;
>>>>>>      res = rangeset_report_ranges(mem_holes, PFN_DOWN(start), PFN_DOWN(end),
>>>>>> @@ -994,11 +1003,30 @@ static int __init find_domU_holes(const struct kernel_info *kinfo,
>>>>>>      return res;
>>>>>>  }
>>>>>>  
>>>>>> +static int __init rangeset_to_membank(unsigned long s_gfn, unsigned long e_gfn,
>>>>>> +                                      void *data)
>>>>>> +{
>>>>>> +    struct membanks *membank = data;
>>>>>> +    paddr_t s = pfn_to_paddr(s_gfn);
>>>>>> +    paddr_t e = pfn_to_paddr(e_gfn + 1) - 1;
>>>>>> +
>>>>>> +    if ( membank->nr_banks >= membank->max_banks )
>>>>>> +        return 0;
>>>>>> +
>>>>>> +    membank->bank[membank->nr_banks].start = s;
>>>>>> +    membank->bank[membank->nr_banks].size = e - s + 1;
>>>>>> +    membank->nr_banks++;
>>>>>> +
>>>>>> +    return 0;
>>>>>> +}
>>>>>> +
>>>>>>  static int __init find_host_extended_regions(const struct kernel_info *kinfo,
>>>>>>                                               struct membanks *ext_regions)
>>>>>>  {
>>>>>>      int res;
>>>>>>      struct membanks *gnttab = membanks_xzalloc(1, MEMORY);
>>>>>> +    struct membanks *xen_reg = membanks_xzalloc(
>>>>>> +        max(1, rangeset_count_ranges(kinfo->xen_reg_assigned)), MEMORY);
>>>>> You allocate at least 1 membank even though xen_reg_assigned may be empty because:
>>>>>  - this function is called for hwdom - no xen,reg
>>>>>  - there may be no xen,reg i.e. no passthrough
>>>>
>>>> Ah, sorry, there's no need to allocate at least 1. This can just be:
>>>>
>>>>     struct membanks *xen_reg = membanks_xzalloc(
>>>>         rangeset_count_ranges(kinfo->arch.xen_reg_assigned), MEMORY);
>>> No, it cannot. membanks_xzalloc() calls xzalloc_flex_struct(). If you pass 0
>>> as size, the latter will calculate offset to FAM[0]. In other words, the
>>> allocation will succeed but only for members up to FAM[0] (i.e. only for struct
>>> membanks_hdr).
>>
>> If we pass 0 as the size, these members (and their ->common.*
>> counterparts) will be allocated:
>> xen_reg->nr_banks
>> xen_reg->max_banks
>> xen_reg->type
>>
>> but there will not be allocated any space for the flexible array member:
>> xen_reg->bank[]
>>
>> Since ->max_banks will be set to 0, and ->nr_banks shouldn't exceed
>> ->max_banks, it should work. At least for the (inner) loop in
>> find_unallocated_memory(), when ->nr_banks is 0, it won't dereference
>> ->bank[]. FWIW, I also tested this with UBSAN enabled.
>>
>> I admit it does give me a weird feeling not allocating any space for a
>> member in a struct, but it's a C standard flexible array member, and the
>> array's size would be 0. We deviated relevant MISRA rule 18.7 in
>> b87697fc1a6f ("automation/eclair: fully deviate MISRA C:2012 Rules 5.7
>> and 18.7").
>>
>> With that said, I'd be happy either way (i.e. either allocating exactly
>> what's returned by rangeset_count_ranges() or max(1,
>> rangeset_count_ranges()), but I just want to ensure we have the same
>> understanding on the technicalities.
> Hmm, why do you want to allocate memory in the first place? If xen_reg_assigned
> is NULL, we should not allocate anything. Instead you suggest to allocate either
> full structure or part of it. That's where I disagree.

Ah, alright, I see now. I'll conditionally allocate xen_reg, and ...

>>
>>> Also, even if you conditionally allocate for xen_reg_assigned or set NULL, in
>>> latter case you will end up with mem_banks containing NULL member. AFAICT that's
>>> not something expected by the users of mem_banks (+ it gives unneeded iteration).
>>
>> Agreed, it would be a bad idea to set xen_reg = NULL (leading to a NULL
>> member in mem_banks), because then find_unallocated_memory() would not
>> be happy.

... I'll adjust find_unallocated_memory() to skip over NULL entries.


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 21:59:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 21:59:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007630.1386897 (Exim 4.92)
	(envelope-from )
	id 1uNIbt-0006Ao-3h; Thu, 05 Jun 2025 21:58:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007630.1386897; Thu, 05 Jun 2025 21:58: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 1uNIbt-0006Ah-14; Thu, 05 Jun 2025 21:58:53 +0000
Received: by outflank-mailman (input) for mailman id 1007630;
 Thu, 05 Jun 2025 21:58:51 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uNIbr-0006Ab-QP
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 21:58:51 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uNIbr-003lko-0D;
 Thu, 05 Jun 2025 21:58:51 +0000
Received: from [2a02:8012:3a1:0:7807:532b:1d1d:b850]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uNIbr-007llA-0S;
 Thu, 05 Jun 2025 21:58: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" 
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=LXPlgXRyBH0nJQdK+aeWw/DSc//K16J41kysLCmOTo0=; b=u5pMc4KqnBzHbZRvYo4lWDw3gS
	2jyfDJyYgdjmZkWMuzcWV06GYdYYfEjXDkOEkTOCnbIyyYFZfNTncqlONJXYBQyc48qmRrJEUv4oR
	AEHNtDdMtoDtwTkHEHz30wC5nztKRIDzqurUMsjjVtgykniy9+FYC6NR+ct7mUiZ6C/M=;
Message-ID: 
Date: Thu, 5 Jun 2025 22:58:48 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 1/3] xen/domain: unify domain ID allocation
Content-Language: en-GB
To: dmkhn@proton.me, xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com,
 roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech,
 dmukhin@ford.com
References: <20250528225030.2652166-1-dmukhin@ford.com>
 <20250528225030.2652166-2-dmukhin@ford.com>
From: Julien Grall 
In-Reply-To: <20250528225030.2652166-2-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Denis,

On 28/05/2025 23:50, dmkhn@proton.me wrote:
> From: Denis Mukhin 
> 
> From: Denis Mukhin 
> 
> Currently, hypervisor code has two different domain ID allocation
> implementations:
> 
>    (a) Sequential IDs allocation in dom0less Arm code based on max_init_domid;
> 
>    (b) Sequential IDs allocation in XEN_DOMCTL_createdomain; does not use
>        max_init_domid (both Arm and x86).
> 
> The domain ID allocation covers dom0 or late hwdom, predefined domains,
> post-boot domains, excluding Xen system domains (domid >=
> DOMID_FIRST_RESERVED).
> 
> It makes sense to have a common helper code for such task across architectures
> (Arm and x86) and between dom0less / toolstack domU allocation.
> 
> Wrap the domain ID allocation as an arch-independent function domid_alloc() in
> common/domain.c based on the bitmap.
> 
> Allocation algorithm:
> - If an explicit domain ID is provided, verify its availability and use it if
>    ID is not used;
> - If DOMID_INVALID is provided, search the range [0..DOMID_FIRST_RESERVED-1],
>    starting from the last used ID and wrapping around as needed. It guarantees
>    that two consecutive calls will never return the same ID. ID#0 is excluded
>    to account for late hwdom case.
> 
> Also, remove is_free_domid() helper as it is not needed now.
> 
> No functional change intended.
> 
> Signed-off-by: Denis Mukhin 
> ---
> Changes since v8:
> - skip ID #0 in domid_alloc() to account for late hwdom
> ---
>   xen/arch/arm/domain_build.c             | 17 +++++---
>   xen/arch/x86/setup.c                    | 11 +++--
>   xen/common/device-tree/dom0less-build.c | 10 +++--
>   xen/common/domain.c                     | 54 +++++++++++++++++++++++++
>   xen/common/domctl.c                     | 42 +++----------------
>   xen/include/xen/domain.h                |  3 ++
>   6 files changed, 87 insertions(+), 50 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index b189a7cfae..e9d563c269 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -2010,6 +2010,7 @@ void __init create_dom0(void)
>           .grant_opts = XEN_DOMCTL_GRANT_version(opt_gnttab_max_version),
>       };
>       unsigned int flags = CDF_privileged | CDF_hardware;
> +    domid_t domid;
>       int rc;
>   
>       /* The vGIC for DOM0 is exactly emulating the hardware GIC */
> @@ -2034,19 +2035,25 @@ void __init create_dom0(void)
>       if ( !llc_coloring_enabled )
>           flags |= CDF_directmap;
>   
> -    dom0 = domain_create(0, &dom0_cfg, flags);
> +    domid = domid_alloc(0);
> +    if ( domid == DOMID_INVALID )
> +        panic("Error allocating domain ID 0\n");
> +
> +    dom0 = domain_create(domid, &dom0_cfg, flags);
>       if ( IS_ERR(dom0) )
> -        panic("Error creating domain 0 (rc = %ld)\n", PTR_ERR(dom0));
> +        panic("Error creating domain %d (rc = %ld)\n", domid, PTR_ERR(dom0));

The change in the panic here and below seems unrelated to the goal of 
the patch. I am ok to keep them here, but I think it should be mentioned 
in the commit message.

>   
>       if ( llc_coloring_enabled && (rc = dom0_set_llc_colors(dom0)) )
> -        panic("Error initializing LLC coloring for domain 0 (rc = %d)\n", rc);
> +        panic("Error initializing LLC coloring for domain %pd (rc = %d)\n",
> +              dom0, rc);
>   
>       if ( alloc_dom0_vcpu0(dom0) == NULL )
> -        panic("Error creating domain 0 vcpu0\n");
> +        panic("Error creating domain %pdv0\n", dom0);
>   
>       rc = construct_dom0(dom0);
>       if ( rc )
> -        panic("Could not set up DOM0 guest OS (rc = %d)\n", rc);
> +        panic("Could not set up guest OS for domain %pd (rc = %d)\n",
> +              dom0, rc);
>   
>       set_xs_domain(dom0);
>   }
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index 1f5cb67bd0..b36ce4491b 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -1031,8 +1031,11 @@ 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();
> +    /* Allocate initial domain ID. Not d0 for pvshim. */

NIT: The two spaces were valid here. This is in fact quite common to 
unambiguously mark the end of a sentence.

> +    bd->domid = domid_alloc(get_initial_domain_id());
> +    if ( bd->domid == DOMID_INVALID )
> +        panic("Error allocating domain ID %d\n", get_initial_domain_id());
> +
>       d = domain_create(bd->domid, &dom0_cfg,
>                         pv_shim ? 0 : CDF_privileged | CDF_hardware);
>       if ( IS_ERR(d) )
> @@ -1064,7 +1067,7 @@ static struct domain *__init create_dom0(struct boot_info *bi)
>   
>           if ( (strlen(acpi_param) == 0) && acpi_disabled )
>           {
> -            printk("ACPI is disabled, notifying Domain 0 (acpi=off)\n");
> +            printk("ACPI is disabled, notifying domain %pd (acpi=off)\n", d);
>               safe_strcpy(acpi_param, "off");
>           }
>   
> @@ -1079,7 +1082,7 @@ static struct domain *__init create_dom0(struct boot_info *bi)
>   
>       bd->d = d;
>       if ( construct_dom0(bd) != 0 )
> -        panic("Could not construct domain 0\n");
> +        panic("Could not construct domain %pd\n", d);
>   
>       bd->cmdline = NULL;
>       xfree(cmdline);
> diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
> index 39cb2cd5c7..a509f8fecd 100644
> --- a/xen/common/device-tree/dom0less-build.c
> +++ b/xen/common/device-tree/dom0less-build.c
> @@ -850,15 +850,13 @@ void __init create_domUs(void)
>           struct xen_domctl_createdomain d_cfg = {0};
>           unsigned int flags = 0U;
>           bool has_dtb = false;
> +        domid_t domid;
>           uint32_t val;
>           int rc;
>   
>           if ( !dt_device_is_compatible(node, "xen,domain") )
>               continue;
>   
> -        if ( (max_init_domid + 1) >= DOMID_FIRST_RESERVED )

I can't find a similar check in domid_alloc(). But if the value is 
unlikely above DOMID_FIRST_RESERVED, then we would end up to allocate a 
random domid.

> -            panic("No more domain IDs available\n");
> -
 >           d_cfg.max_evtchn_port = 1023;> 
d_cfg.max_grant_frames = -1;
>           d_cfg.max_maptrack_frames = -1;
> @@ -981,7 +979,11 @@ void __init create_domUs(void)
>            * very important to use the pre-increment operator to call
>            * domain_create() with a domid > 0. (domid == 0 is reserved for Dom0)
>            */
> -        d = domain_create(++max_init_domid, &d_cfg, flags);
> +        domid = domid_alloc(++max_init_domid);

In the commit message you wrote:


"""
     (b) Sequential IDs allocation in XEN_DOMCTL_createdomain; does not use
         max_init_domid (both Arm and x86).
"""

I read it as max_init_domid should have been moved to common code. I see 
this is done in the next patch. So I would suggest to clarify this will 
be handled separately.


> +        if ( domid == DOMID_INVALID )
> +            panic("Error allocating ID for domain %s\n", dt_node_name(node));
> +
> +        d = domain_create(domid, &d_cfg, flags);
>           if ( IS_ERR(d) )
>               panic("Error creating domain %s (rc = %ld)\n",
>                     dt_node_name(node), PTR_ERR(d));
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index abf1969e60..ae0c44fcbb 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -66,6 +66,10 @@ DEFINE_RCU_READ_LOCK(domlist_read_lock);
>   static struct domain *domain_hash[DOMAIN_HASH_SIZE];
>   struct domain *domain_list;
>   
> +/* Non-system domain ID allocator. */
> +static DEFINE_SPINLOCK(domid_lock);
> +static DECLARE_BITMAP(domid_bitmap, DOMID_FIRST_RESERVED);
> +
>   /*
>    * 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.
> @@ -1449,6 +1453,8 @@ void domain_destroy(struct domain *d)
>   
>       TRACE_TIME(TRC_DOM0_DOM_REM, d->domain_id);
>   
> +    domid_free(d->domain_id);
> +
>       /* Remove from the domlist/hash. */
>       domlist_remove(d);
>   
> @@ -2405,6 +2411,54 @@ domid_t get_initial_domain_id(void)
>       return hardware_domid;
>   }
>   
> +domid_t domid_alloc(domid_t domid)
> +{
> +    spin_lock(&domid_lock);
> +
> +    if ( domid < DOMID_FIRST_RESERVED )
> +    {
> +        if ( __test_and_set_bit(domid, domid_bitmap) )
> +            domid = DOMID_INVALID;
> +    }
> +    else
> +    {
> +        static domid_t domid_last;
> +        /* NB: account for late hwdom case, skip ID#0 */

I am somewhat confused with this comment. For the late hwdom case, I 
thought we were using a non-zero ID. Dom0 should also always be the 
first dom0 to be reserved. Can you clarify?

That said, if you want to skip to dom0. Wouldn't it be better to have
domid_last set to 1 and then ...

 > +        const domid_t reserved_domid = 0;> +        const bool 
reserved = __test_and_set_bit(reserved_domid, domid_bitmap);
> +
> +        domid = find_next_zero_bit(domid_bitmap, DOMID_FIRST_RESERVED,
> +                                   domid_last);
> +
> +        if ( domid == DOMID_FIRST_RESERVED )
> +            domid = find_next_zero_bit(domid_bitmap, DOMID_FIRST_RESERVED, 0);

... use 1 here? This would avoid to temporarily mark the domid 0 as 
reserved.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 22:05:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 22:05:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007636.1386906 (Exim 4.92)
	(envelope-from )
	id 1uNIiR-0007xs-Og; Thu, 05 Jun 2025 22:05:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007636.1386906; Thu, 05 Jun 2025 22:05: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 1uNIiR-0007xl-M5; Thu, 05 Jun 2025 22:05:39 +0000
Received: by outflank-mailman (input) for mailman id 1007636;
 Thu, 05 Jun 2025 22:05:38 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uNIiQ-0007xf-6u
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 22:05:38 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uNIiP-003luZ-1F;
 Thu, 05 Jun 2025 22:05:37 +0000
Received: from [2a02:8012:3a1:0:7807:532b:1d1d:b850]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uNIiP-0080sf-1s;
 Thu, 05 Jun 2025 22:05: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=G3DEaH/aPg1f1xdeQjwQocPfTfFGy3VvbeZYsCW/q9U=; b=kVBqH/w0gqUVv452qZCjeyMHHt
	a2Hk+4W57GmfsNNOEq5ZAWoPvkJlMksGvcUhF0YhcU4ov6VfccTZG39GxjVqYr2PER0MA+ydjqPiV
	qaNY5MymHQKrA8K5orGeQNz01z2/XUVwmM6hKH/zyynuf5HPY3Px7y5RNnUAHayy1XeY=;
Message-ID: <63087c42-d709-4e53-a2c3-8b812f13190a@xen.org>
Date: Thu, 5 Jun 2025 23:05:34 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 2/3] xen/domain: adjust domain ID allocation for Arm
Content-Language: en-GB
To: dmkhn@proton.me, xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com,
 roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech,
 dmukhin@ford.com
References: <20250528225030.2652166-1-dmukhin@ford.com>
 <20250528225030.2652166-3-dmukhin@ford.com>
From: Julien Grall 
In-Reply-To: <20250528225030.2652166-3-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Denis,

On 28/05/2025 23:50, dmkhn@proton.me wrote:
> From: Denis Mukhin 
> 
> From: Denis Mukhin 
> 
> Remove the hardcoded domain ID 0 allocation for hardware domain and replace it
> with a call to get_initial_domain_id() (returns the value of hardware_domid on
> Arm).

I am not entirely why this is done. Are you intending to pass a 
different domain ID? If so...

> 
> Update domid_alloc(DOMID_INVALID) case to ensure that get_initial_domain_id()
> ID is skipped during domain ID allocation to cover domU case in dom0less
> configuration. That also fixes a potential issue with re-using ID#0 for domUs
> when get_initial_domain_id() returns non-zero.
> 
> Signed-off-by: Denis Mukhin 
> ---
> Changes since v8:
> - rebased
> ---
>   xen/arch/arm/domain_build.c             | 4 ++--
>   xen/common/device-tree/dom0less-build.c | 9 +++------
>   xen/common/domain.c                     | 4 ++--
>   3 files changed, 7 insertions(+), 10 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index e9d563c269..0ad80b020a 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -2035,9 +2035,9 @@ void __init create_dom0(void)

... naming like create_dom0() probably wants to be renamed.

That said, I am not convinced a domain other than 0 should have full 
privilege by default. So I would argue it should stay as ...

>       if ( !llc_coloring_enabled )
>           flags |= CDF_directmap;
>   
> -    domid = domid_alloc(0);
> +    domid = domid_alloc(get_initial_domain_id());

... 0.

>       if ( domid == DOMID_INVALID )
> -        panic("Error allocating domain ID 0\n");
> +        panic("Error allocating domain ID %d\n", get_initial_domain_id());
>   
>       dom0 = domain_create(domid, &dom0_cfg, flags);
>       if ( IS_ERR(dom0) )
> diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
> index a509f8fecd..9a6015f4ce 100644
> --- a/xen/common/device-tree/dom0less-build.c
> +++ b/xen/common/device-tree/dom0less-build.c
> @@ -974,14 +974,11 @@ void __init create_domUs(void)
>   
>           arch_create_domUs(node, &d_cfg, flags);
>   
> -        /*
> -         * The variable max_init_domid is initialized with zero, so here it's
> -         * very important to use the pre-increment operator to call
> -         * domain_create() with a domid > 0. (domid == 0 is reserved for Dom0)
> -         */
> -        domid = domid_alloc(++max_init_domid);
> +        domid = domid_alloc(DOMID_INVALID);
>           if ( domid == DOMID_INVALID )
>               panic("Error allocating ID for domain %s\n", dt_node_name(node));
> +        if ( max_init_domid < domid )
> +            max_init_domid = domid;
>   
>           d = domain_create(domid, &d_cfg, flags);
>           if ( IS_ERR(d) )
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index ae0c44fcbb..129b4fcb37 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -2423,8 +2423,8 @@ domid_t domid_alloc(domid_t domid)
>       else
>       {
>           static domid_t domid_last;
> -        /* NB: account for late hwdom case, skip ID#0 */
> -        const domid_t reserved_domid = 0;
> +        /* NB: account for late hwdom case */
> +        const domid_t reserved_domid = get_initial_domain_id();

This is somewhat confusing to modify domid_alloc() in a patch that is 
meant to modify only the Arm allocation. Can you clarify why this can't 
be done earlier?

>           const bool reserved = __test_and_set_bit(reserved_domid, domid_bitmap);
>   
>           domid = find_next_zero_bit(domid_bitmap, DOMID_FIRST_RESERVED,

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 22:20:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 22:20:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007647.1386919 (Exim 4.92)
	(envelope-from )
	id 1uNIx2-0002ia-3F; Thu, 05 Jun 2025 22:20:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007647.1386919; Thu, 05 Jun 2025 22:20: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 1uNIx2-0002iT-0g; Thu, 05 Jun 2025 22:20:44 +0000
Received: by outflank-mailman (input) for mailman id 1007647;
 Thu, 05 Jun 2025 22:20:43 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uNIx1-0002iN-0e
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 22:20:43 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uNIws-003mA7-1S;
 Thu, 05 Jun 2025 22:20:34 +0000
Received: from [2a02:8012:3a1:0:7807:532b:1d1d:b850]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uNIws-008YHd-2H;
 Thu, 05 Jun 2025 22:20: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=BSLNWzQBa/OTEkLfdyJ+SddJxCasEKJV2JDoScP/uB4=; b=kkZjMQ2I5rt93CpL2iKmxLzQGC
	CIGTjazszLuvmflqIfQ7u5W+T3bs83SEcJmz6CLE+9Dq7Ro4xCzfqk+TSNwxRCrsGG8iWhQPGPZNb
	5+OTT+u0n1L/A5EnSo8z4WNZBIzsu1rGAm7ZgT+raaXGm1+QXUfg6grHIjNxb+fIUY4E=;
Message-ID: 
Date: Thu, 5 Jun 2025 23:20:32 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 3/4] xen/console: remove max_init_domid dependency
Content-Language: en-GB
To: Jan Beulich , dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech,
 michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org,
 dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250530231841.73386-1-dmukhin@ford.com>
 <20250530231841.73386-4-dmukhin@ford.com>
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Jan,

On 04/06/2025 13:55, Jan Beulich wrote:
> On 31.05.2025 01:19, dmkhn@proton.me wrote:
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -2461,6 +2461,39 @@ void domid_free(domid_t domid)
>>       spin_unlock(&domid_lock);
>>   }
>>   
>> +/*
>> + * Find the ID of the next possible console owner domain.
>> + *
>> + * @return Domain ID: DOMID_XEN or non-system domain IDs within
>> + * the range of [0..DOMID_FIRST_RESERVED-1].
>> + */
>> +domid_t domid_find_with_input_allowed(domid_t hint)
>> +{
>> +    domid_t domid = DOMID_XEN;
>> +
>> +    if ( hint < DOMID_FIRST_RESERVED )
>> +    {
>> +        struct domain *d;
>> +
>> +        rcu_read_lock(&domlist_read_lock);
>> +
>> +        for ( d = domid_to_domain(hint);
> 
> If the domain with ID "hint" went away, what is being switched to changes
> compared to behavior prior to this patch, if I'm not mistaken. While this
> _may_ be acceptable, not saying so in the description is imo a no-go.
> 
>> +              d && get_domain(d) && d->domain_id < DOMID_FIRST_RESERVED;
> 
> What's the DOMID_FIRST_RESERVED check for? And where's the put_domain()
> for the get_domain() here?
> 
>> +              d = rcu_dereference(d->next_in_list) )
>> +        {
>> +            if ( d->console.input_allowed )
>> +            {
>> +                domid = d->domain_id;
>> +                break;
>> +            }
>> +        }
>> +
>> +        rcu_read_unlock(&domlist_read_lock);
>> +    }
>> +
>> +    return domid;
>> +}
> 
> My concern remains: With many domains, the loop here may take quite a few
> iterations. That's even more concerning because it regresses right away in
> environments where along with boot-time created domains (eligible for
> console focus) later further domains are created (non of which are eligible
> for console focus). That is, the step from last boot-time created back to
> DOMID_XEN may now take excessively long.

+1. I vaguely recall making the same concern earlier in the review. One 
possibility would be to have a list of domains where the console is 
supported. I don't think it would be necessary to have the list sorted 
as I view the console switching a debug facility.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 22:40:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 22:40:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007657.1386929 (Exim 4.92)
	(envelope-from )
	id 1uNJG8-0005mc-Jk; Thu, 05 Jun 2025 22:40:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007657.1386929; Thu, 05 Jun 2025 22:40:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNJG8-0005mV-HB; Thu, 05 Jun 2025 22:40:28 +0000
Received: by outflank-mailman (input) for mailman id 1007657;
 Thu, 05 Jun 2025 22:40:27 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uNJG7-0005mP-Ku
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 22:40:27 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uNJG6-003mVw-2l;
 Thu, 05 Jun 2025 22:40:26 +0000
Received: from [2a02:8012:3a1:0:7807:532b:1d1d:b850]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uNJG7-009EbD-0G;
 Thu, 05 Jun 2025 22:40: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" 
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=51Crap5g3tsMLD8ahdQD1PZAJ1EohChB9g94IGRzfms=; b=Cek3+6WHYCv3muiJKpe7/ZUyzh
	CENGK/B3kWr4t2OUIM87QDk+aus+olsP4ORnmLOQ+le6vD9GaDleiBfBDWAd+5E/35umMYh2ycfb6
	GP+js+zKpSPXwhFoQvmw8qTDQ4mjKizeV6AAEPeqUDQLINvKkysBTu5fP85K0oW5Tr3A=;
Message-ID: <928d741e-7fa3-4b93-88b8-b45b9bd8b8f2@xen.org>
Date: Thu, 5 Jun 2025 23:40:23 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v4 0/8] xen/arm: scmi: introduce SCI SCMI SMC
 multi-agent support
Content-Language: en-GB
To: Oleksii Moisieiev ,
 "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Bertrand Marquis , Jan Beulich
 , Juergen Gross ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini ,
 Volodymyr Babchuk ,
 Grygorii Strashko 
References: 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Oleksii,

On 19/05/2025 16:50, Oleksii Moisieiev wrote:
 > >   MAINTAINERS                                   |   6 +
>   .../arm/firmware/arm-scmi-proposal.rst        | 224 +++++
>   .../arm/firmware/arm-scmi.rst                 | 442 +++++++++
>   docs/hypervisor-guide/arm/index.rst           |   9 +
>   docs/hypervisor-guide/index.rst               |   1 +
>   docs/man/xl.cfg.5.pod.in                      |  47 +
>   docs/misc/arm/device-tree/booting.txt         |  75 ++
>   docs/misc/xen-command-line.pandoc             |  18 +
>   tools/include/libxl.h                         |   5 +
>   tools/libs/light/libxl_arm.c                  |  18 +
>   tools/libs/light/libxl_types.idl              |  12 +
>   tools/xl/xl_parse.c                           |  48 +
>   xen/arch/arm/device.c                         |   5 +
>   xen/arch/arm/dom0less-build.c                 |  49 +
>   xen/arch/arm/domain.c                         |  12 +-
>   xen/arch/arm/domain_build.c                   |  11 +-
>   xen/arch/arm/firmware/Kconfig                 |  36 +-
>   xen/arch/arm/firmware/Makefile                |   2 +
>   xen/arch/arm/firmware/sci.c                   | 191 ++++
>   xen/arch/arm/firmware/scmi-proto.h            | 164 ++++
>   xen/arch/arm/firmware/scmi-shmem.c            | 173 ++++
>   xen/arch/arm/firmware/scmi-shmem.h            |  45 +
>   xen/arch/arm/firmware/scmi-smc-multiagent.c   | 860 ++++++++++++++++++
>   xen/arch/arm/firmware/scmi-smc.c              | 191 +++-
>   xen/arch/arm/include/asm/domain.h             |   5 +
>   xen/arch/arm/include/asm/firmware/sci.h       | 214 +++++
>   xen/arch/arm/include/asm/firmware/scmi-smc.h  |  41 -
>   xen/arch/arm/vsmc.c                           |   4 +-
>   xen/common/domctl.c                           |  19 +
>   xen/drivers/passthrough/device_tree.c         |   6 +
>   xen/include/asm-generic/device.h              |   1 +
>   xen/include/public/arch-arm.h                 |   8 +
>   32 files changed, 2856 insertions(+), 86 deletions(-)
>   create mode 100644 docs/hypervisor-guide/arm/firmware/arm-scmi-proposal.rst
>   create mode 100644 docs/hypervisor-guide/arm/firmware/arm-scmi.rst
>   create mode 100644 docs/hypervisor-guide/arm/index.rst
>   create mode 100644 xen/arch/arm/firmware/sci.c
>   create mode 100644 xen/arch/arm/firmware/scmi-proto.h
>   create mode 100644 xen/arch/arm/firmware/scmi-shmem.c
>   create mode 100644 xen/arch/arm/firmware/scmi-shmem.h
>   create mode 100644 xen/arch/arm/firmware/scmi-smc-multiagent.c
>   create mode 100644 xen/arch/arm/include/asm/firmware/sci.h
>   delete mode 100644 xen/arch/arm/include/asm/firmware/scmi-smc.h

Looking at the list above, I don't see an update to SUPPORT.md. So I 
believe, this would fall under:

### 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

I think this should be updated for the multi-agent support to tech preview.

Cheers,


> 

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 22:44:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 22:44:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007664.1386939 (Exim 4.92)
	(envelope-from )
	id 1uNJJy-0006Zp-2u; Thu, 05 Jun 2025 22:44:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007664.1386939; Thu, 05 Jun 2025 22:44:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNJJy-0006Zi-0L; Thu, 05 Jun 2025 22:44:26 +0000
Received: by outflank-mailman (input) for mailman id 1007664;
 Thu, 05 Jun 2025 22:44:25 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uNJJx-0006Zc-C8
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 22:44:25 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uNJJw-003mb4-2K;
 Thu, 05 Jun 2025 22:44:24 +0000
Received: from [2a02:8012:3a1:0:7807:532b:1d1d:b850]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uNJJx-009MrP-00;
 Thu, 05 Jun 2025 22:44: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" 
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=Q1/hezIP1lWTTjViNwl+8ErXum4/EN7WBrCvfzxq4bk=; b=1qR8tAoA4ckC+ezUwQRnbIVsBW
	Dlv9h7kNYNFwyhb2fVjrNcLWoW75pUVxUqX6vRRkkLisXxjKoxd1e0Z2aXtvpnE93Xoga9vXvyUG+
	wjfMppocLABFT/FrrbfeDY5l6tO7CsnUOelK9kob0W6XxMOfZ5leEPIq7dVYGqmxUMPQ=;
Message-ID: 
Date: Thu, 5 Jun 2025 23:44:22 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC
 multi-agent driver
Content-Language: en-GB
To: Stefano Stabellini ,
 Oleksii Moisieiev 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper ,
 Anthony PERARD ,
 Bertrand Marquis , Jan Beulich
 , Juergen Gross ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Volodymyr Babchuk ,
 Grygorii Strashko 
References: 
 <318044ae12f13b6b297b3f5fda577a1a6cd143da.1747669845.git.oleksii_moisieiev@epam.com>
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Oleksii & Stefano,

On 23/05/2025 21:06, Stefano Stabellini wrote:
>> +SCMI SMC multi-agent support
>> +============================
>> +
>> +For enabling the ARM SCMI SMC multi-agent support (enabled by CONFIG_SCMI_SMC_MA)
>> +the Xen specific SCMI Agent's configuration shell be provided in the Host DT
>> +according to the SCMI compliant EL3 Firmware specification with
>> +ARM SMC/HVC transport using property "xen,scmi-secondary-agents" under
>> +the top-level "chosen" node:
>> +
>> +- xen,scmi-secondary-agents
>> +
>> +    Defines a set of SCMI agents configuration supported by SCMI EL3 FW and
>> +    available for Xen. Each Agent defined as triple consisting of:
>> +    SCMI agent_id,
>> +    SMC/HVC function_id assigned for the agent transport ("arm,smc-id"),
>> +    phandle to SCMI SHM assigned for the agent transport ("arm,scmi-shmem").
>> +
>> +As an example:
>> +
>> +chosen {
>> +    xen,scmi-secondary-agents = <
>> +        1 0x82000003 &scmi_shm_1
>> +        2 0x82000004 &scmi_shm_2
>> +        3 0x82000005 &scmi_shm_3
>> +        4 0x82000006 &scmi_shm_4>;
>> +}
> 
> NIT: it should be };
> 
> Looking at scmi_probe, collect_agents, and the following SCMI
> SCMI_BASE_DISCOVER_AGENT request, I wonder: do we actually need this
> information?
> 
> It looks like we can discover the agend_ids for every channel, I guess
> what we need to know is the shmem location for every channel? But the
> full list of shmem channel is available below thanks to the scmi-shmem
> nodes.
> 
> So, we have the list of scmi-shmem anyway, and we can probe the
> agent_id. The only parameter left is the smc_id/func_id.
> 
> Or maybe smc_id/func_id can be calculated from agent_id?
> 
> I am asking mostly because if a user is supposed to add this
> xen,scmi-secondary-agents property, where are they supposed to find the
> smc_id/func_id information?
> 
> It is important that we write down in this document how the user is
> expected to find out what 1 is 0x82000003 which is scmi_shm_1.

I was actually going to write something similar to what you wrote. I 
think this is error-prone to let the user specify the full SMC ID. It 
would be better if this can be computed from a base + an agent ID.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Thu Jun 05 23:19:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 23:19:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007686.1386950 (Exim 4.92)
	(envelope-from )
	id 1uNJrp-0002YF-L9; Thu, 05 Jun 2025 23:19:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007686.1386950; Thu, 05 Jun 2025 23:19: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 1uNJrp-0002Y8-H8; Thu, 05 Jun 2025 23:19:25 +0000
Received: by outflank-mailman (input) for mailman id 1007686;
 Thu, 05 Jun 2025 23:19: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 1uNJro-0002X0-3e
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 23:19:24 +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 831defed-4263-11f0-a300-13f23c93f187;
 Fri, 06 Jun 2025 01:19:22 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 000485C4B0F;
 Thu,  5 Jun 2025 23:17:03 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 24098C4CEE7;
 Thu,  5 Jun 2025 23:19: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: 831defed-4263-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749165560;
	bh=alA63gTBbzXXVmHAEUYuMUxgGLSdAJkDIn+1a+EE9qM=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=HlLeOwUYmLeH7cCM8jSgyJqrvKLGLvZ3FODc5ZbrcJ3FmyOfW/VjYXvNFIc8UPkb8
	 LrEphA3zFNAokPi/y8LauaSP6HHpmbEFJ0xEg6eNxQLOb2CsIsEA5ddM8iio++w7TW
	 bY5Raten4uF/VOXCmrZjcJcwEsKH4RgSjz2ZjMka1XYWhvgSg8aYukillTJAKHvWh4
	 Isoot9RlbFHp/03UieCulTEzASLmfhtQoboxECRVIUSlRxQJsaNH7/jfhrmqO5i4Y8
	 JqeWYVv1G40puZkxr5QuHDPO8FEYTv9uXszcCPXe5qoybfuMIgmEEO0YulYzD/4KWk
	 BHher1zAtSgXA==
Date: Thu, 5 Jun 2025 16:19:18 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: "Daniel P. Smith" , 
    xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk 
Subject: Re: [PATCH 12/19] xen/dt: Move bootfdt functions to xen/bootfdt.h
In-Reply-To: 
Message-ID: 
References:  <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-13-agarciav@amd.com>  
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Thu, 5 Jun 2025, Alejandro Vallejo wrote:
> On Mon Jun 2, 2025 at 10:25 PM CEST, Daniel P. Smith wrote:
> >> +/* Helper to read a big number; size is in cells (not bytes) */
> >> +static inline u64 dt_read_number(const __be32 *cell, int size)
> >> +{
> >> +    u64 r = 0;
> >> +
> >> +    while ( size-- )
> >> +        r = (r << 32) | be32_to_cpu(*(cell++));
> >> +    return r;
> >> +}
> >
> > I know you are trying to keep code changes to a minimal but let's not 
> > allow poorly constructed logic like this to continue to persist. This is 
> > an unbounded, arbitrary read function that is feed parameters via 
> > externally input. The DT spec declares only two number types for a 
> > property, u32 and u64, see Table 2.3 in Section 2.2.4. There is no 
> > reason to have an unbounded, arbitrary read function lying around 
> > waiting to be leveraged in exploitation.
> 
> Seeing how it's a big lump of code motion, I really don't want to play games
> or I will myself lose track of what I changed and what I didn't.
> 
> While I agree it should probably be a switch statement (or factored away
> altogether), this isn't the place for it.

The improvement suggested by Daniel should be in a separate patch from
the code movement to make it easier to review, but it can still be part
of the patch series.


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 23:40:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 23:40:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007698.1386960 (Exim 4.92)
	(envelope-from )
	id 1uNKBj-0005Uy-70; Thu, 05 Jun 2025 23:39:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007698.1386960; Thu, 05 Jun 2025 23:39:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNKBj-0005Ur-41; Thu, 05 Jun 2025 23:39:59 +0000
Received: by outflank-mailman (input) for mailman id 1007698;
 Thu, 05 Jun 2025 23:39: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 1uNKBh-0005Ul-Gd
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 23:39:57 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 60166b1b-4266-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 01:39:52 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id A01FD629FB;
 Thu,  5 Jun 2025 23:39:50 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6C01EC4CEF4;
 Thu,  5 Jun 2025 23:39: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: 60166b1b-4266-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749166790;
	bh=/7eTanIN2cOphn116VXxlxBPs/r6D0Mt5hQpzOL7zcY=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=mU4/8KiParUT1mmYlNUpRhhO0PTB1zE7nN/GhE6R5tIc3YK2OpxVmE3fBPKWru0E8
	 TyTt33jfwXb0H9Bf4AsUEI2Z2BO9UAljvqOOfR9MGCrV5tlins5ecNNcczHmz/M2Av
	 xAAOKvpqlMonsX/5Hhtd50eO3rTQVFarA3MMe+K8eR4f55GLMCfkNbIVlV1wbtwGCN
	 gIbnroZbG8Q7Tu3MrEGV+Y+ITRBLQrpT7dfYpvABPZ2zVfS8re+1bmQ+/qxpo7M8wx
	 0puKkj6heKROsXpTAduHLqAJjoBerLo6IoyGkijE85vMQw2Fttr70l48/NboKf5CsW
	 ZwOLVBUBDYwLA==
Date: Thu, 5 Jun 2025 16:39:48 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Stefano Stabellini , 
    Andrew Cooper , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Alessandro Zucchelli , 
    xen-devel@lists.xenproject.org, nicola.vetrini@bugseng.com, 
    federico.serafini@bugseng.com
Subject: Re: [PATCH] x86: remove memcmp calls non-compliant with Rule
 21.16.
In-Reply-To: 
Message-ID: 
References: <20250604233537.2892206-1-stefano.stabellini@amd.com> 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Thu, 5 Jun 2025, Jan Beulich wrote:
> On 05.06.2025 01:35, Stefano Stabellini wrote:
> > From: Alessandro Zucchelli 
> > 
> > MISRA C Rule 21.16 states the following: "The pointer arguments to
> > the Standard Library function `memcmp' shall point to either a pointer
> > type, an essentially signed type, an essentially unsigned type, an
> > essentially Boolean type or an essentially enum type".
> > 
> > Comparing string literals with char arrays is more appropriately
> > done via strncmp.
> 
> More appropriately - maybe. Yet less efficiently. IOW I view ...
> 
> > No functional change.
> 
> ... this as at the edge of not being true.
> 
> > Signed-off-by: Alessandro Zucchelli 
> 
> Missing your own S-o-b.
>
> Also (nit) may I ask that you drop the full stop from the patch subject?

I'll add the S-o-B and fix the subject


> > --- a/xen/arch/x86/dmi_scan.c
> > +++ b/xen/arch/x86/dmi_scan.c
> > @@ -233,7 +233,7 @@ void __init dmi_efi_get_table(const void *smbios, const void *smbios3)
> >  	const struct smbios_eps *eps = smbios;
> >  	const struct smbios3_eps *eps3 = smbios3;
> >  
> > -	if (eps3 && memcmp(eps3->anchor, "_SM3_", 5) == 0 &&
> > +	if (eps3 && strncmp(eps3->anchor, "_SM3_", 5) == 0 &&
> 
> Unlike the last example given in the doc, this does not pose the risk of
> false "not equal" returns. Considering there's no example there exactly
> matching this situation, I'm not convinced a change is actually needed.
> (Applies to all other changes here, too.)

If we consider string literals "pointer types", then I think you are
right that this would fall under what is permitted by 21.16. Nicola,
what do you think?


> > @@ -302,7 +302,7 @@ const char *__init dmi_get_table(paddr_t *base, u32 *len)
> >  				continue;
> >  			memcpy_fromio(&eps.dmi + 1, q + sizeof(eps.dmi),
> >  			              sizeof(eps.smbios3) - sizeof(eps.dmi));
> > -			if (!memcmp(eps.smbios3.anchor, "_SM3_", 5) &&
> > +			if (strncmp(eps.smbios3.anchor, "_SM3_", 5) == 0 &&
> 
> Here and below there's a further (style) change, moving from ! to "== 0"
> (or from implicit boolean to "!= 0"). As we use the original style in many
> other places, some justification for this extra change would be needed in
> the description (or these extra adjustments be dropped).
 
The adjustments can be dropped


> > @@ -720,10 +720,10 @@ static void __init efi_check_config(void)
> >  	__set_fixmap(FIX_EFI_MPF, PFN_DOWN(efi.mps), __PAGE_HYPERVISOR);
> >  	mpf = fix_to_virt(FIX_EFI_MPF) + ((long)efi.mps & (PAGE_SIZE-1));
> >  
> > -	if (memcmp(mpf->mpf_signature, "_MP_", 4) == 0 &&
> > -	    mpf->mpf_length == 1 &&
> > -	    mpf_checksum((void *)mpf, 16) &&
> > -	    (mpf->mpf_specification == 1 || mpf->mpf_specification == 4)) {
> > +	if (strncmp(mpf->mpf_signature, "_MP_", 4) == 0 &&
> > +            mpf->mpf_length == 1 &&
> > +            mpf_checksum((void *)mpf, 16) &&
> > +            (mpf->mpf_specification == 1 || mpf->mpf_specification == 4)) {
> >  		smp_found_config = true;
> >  		printk(KERN_INFO "SMP MP-table at %08lx\n", efi.mps);
> >  		mpf_found = mpf;
> 
> There are extra (indentation) changes here which ought to be dropped.

Yes 


From xen-devel-bounces@lists.xenproject.org Thu Jun 05 23:46:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jun 2025 23:46:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007712.1386970 (Exim 4.92)
	(envelope-from )
	id 1uNKHi-0007B7-Pq; Thu, 05 Jun 2025 23:46:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007712.1386970; Thu, 05 Jun 2025 23:46: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 1uNKHi-0007B0-NH; Thu, 05 Jun 2025 23:46:10 +0000
Received: by outflank-mailman (input) for mailman id 1007712;
 Thu, 05 Jun 2025 23:46: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 1uNKHh-0007Au-F4
 for xen-devel@lists.xenproject.org; Thu, 05 Jun 2025 23:46:09 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3fc6aa1a-4267-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 01:46:07 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 1C5666154E;
 Thu,  5 Jun 2025 23:46:06 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 37598C4CEE7;
 Thu,  5 Jun 2025 23:46:04 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3fc6aa1a-4267-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749167165;
	bh=gLHEgdpM3Jus7sfz9wERNI99jnA3VG3T8lURiWMaNYU=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=Y6ypvT25SdnQtcCofwbFlv6FoLDFtsR8IkiItrXi8cA+c2h2QUvMDc+lEwGdUGMle
	 9QkACEfwNVlDxZasUlyDNtEnajM7w3LvsnWJK3s/AHwTGfmhYbAL4DkPi393+CWZI2
	 okwtPftLFy6HREhrnH0nlSZsPQ2K2IK565PXIW9OukIop+Y6cMkM/uXNaRi3sETgCk
	 JWRILgxRksmc1/JlGOegP/WJBFr3CmXjQihxuqY9gW4Oca/sO6o+ObIinaRLS8N24U
	 48w3L0hhT2hhf/+cjlW33prBUN4b39JYrcLHtdorchzIeyyL6xX/WHFLoFCfVQyg/n
	 IDXE3lme1daEg==
Date: Thu, 5 Jun 2025 16:46:03 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: dmkhn@proton.me, sstabellini@kernel.org, andrew.cooper3@citrix.com, 
    anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com, 
    roger.pau@citrix.com, teddy.astie@vates.tech, dmukhin@ford.com, 
    xen-devel@lists.xenproject.org
Subject: Re: [PATCH v5 1/2] xen/domain: introduce common hardware emulation
 flags
In-Reply-To: <8412c795-610b-416e-8d22-4149d2492517@suse.com>
Message-ID: 
References: <20250602191717.148361-1-dmukhin@ford.com> <20250602191717.148361-2-dmukhin@ford.com> <093dc85d-ebf3-4982-8888-db4e7cfd0e45@suse.com>  <8412c795-610b-416e-8d22-4149d2492517@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, 5 Jun 2025, Jan Beulich wrote:
> On 05.06.2025 03:17, dmkhn@proton.me wrote:
> > On Wed, Jun 04, 2025 at 12:36:17PM +0200, Jan Beulich wrote:
> >> On 02.06.2025 21:17, dmkhn@proton.me wrote:
> >>> From: Denis Mukhin 
> >>>
> >>> Add common emulation_flags for configuring domain emulation features.
> >>>
> >>> Print d->emulation_flags from 'q' keyhandler for better traceability while
> >>> debugging.
> >>>
> >>> Signed-off-by: Denis Mukhin 
> >>> Reviewed-by: Stefano Stabellini 
> >>
> >> It's not becoming clear why this would want doing, nor in how far some of
> >> the bits there may gain "common" meaning, too. Imo this kind of change is
> >> meaningful only in a series where later the common-ness is also used.
> > 
> > I have a set of upcoming changes here:
> >   https://gitlab.com/xen-project/people/dmukhin/xen/-/tree/vuart-framework?ref_type=heads
> > 
> > Specifically,
> >  https://gitlab.com/xen-project/people/dmukhin/xen/-/commit/17f44d23c1904374963c4ec839bc8219041b5d26
> > 
> > enables the use of emulation_flags on Arm.
> > 
> > I can move this patch to the upcoming series, if needed, but looks like it is
> > OK to have it for Arm even now.
> 
> Prior to that series making it to a ready-to-be-committed state, it'll be
> (effectively) dead code on Arm. Which strictly speaking Misra objects to.
> I wonder if you, Stefano, considered that when giving your R-b.

We have not been enforcing the "no dead code" rule (R2.2) especially on
a per patch basis. In general in my view, it is better to reduce dead
code rather than increase dead code, but it is OK to do so temporarily.


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 00:08:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 00:08:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007722.1386980 (Exim 4.92)
	(envelope-from )
	id 1uNKcv-0002QU-Fj; Fri, 06 Jun 2025 00:08:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007722.1386980; Fri, 06 Jun 2025 00: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 1uNKcv-0002QN-C1; Fri, 06 Jun 2025 00:08:05 +0000
Received: by outflank-mailman (input) for mailman id 1007722;
 Fri, 06 Jun 2025 00:08:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uNKcu-0002QH-OG
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 00:08:04 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 485d9e14-426a-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 02:07:50 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id E347C4AA17;
 Fri,  6 Jun 2025 00:07:48 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id AB073C4CEEF;
 Fri,  6 Jun 2025 00:07:47 +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: 485d9e14-426a-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749168468;
	bh=pFWt8ixJ5bjgXwtwhuvejUDxPeu3bdN7Wc76r3o+ct0=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=dSGoeiiEwe/9WvxgWLIwyw+UWy6uw8IxY/yuXS2qhvNb1rGw5NePhNfBkKfGgti7R
	 EfNXcUGI2oGPVY++pqeY+Ht5v7qstcDIO20HO9fBsI1FP0rh2ai8H9iwK/0CaMdF6j
	 p4eDrlUWnDAn/WTc91NPlKXEzlgPk2CSQyA8TUzXA3suzcugNuvUu3mJ9vfmJilWLc
	 f5OOzYl7gYKO+LBE2DRVkQzn7u5QpPfNpT3xqrUs3Tf0+OCsKwZJk2NYn5s6+tcy+F
	 JIfdz9nJUSok9Pn9I7Mv2GsSvSs/4alxlBX9Wujz6fT8I4xKRHiKkbJPzSXpCwx8/L
	 c5ghbVP9YiDhw==
Date: Thu, 5 Jun 2025 17:07:46 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Stefano Stabellini , andrew.cooper3@citrix.com, 
    anthony.perard@vates.tech, michal.orzel@amd.com, julien@xen.org, 
    roger.pau@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH] xen: add header guards to generated asm generic
 headers
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 Thu, 5 Jun 2025, Jan Beulich wrote:
> On 05.06.2025 01:09, Stefano Stabellini wrote:
> > --- a/xen/scripts/Makefile.asm-generic
> > +++ b/xen/scripts/Makefile.asm-generic
> > @@ -32,7 +32,12 @@ old-headers := $(wildcard $(obj)/*.h)
> >  unwanted    := $(filter-out $(generic-y) $(generated-y),$(old-headers))
> >  
> >  quiet_cmd_wrap = WRAP    $@
> > -      cmd_wrap = echo "\#include " > $@
> > +      cmd_wrap = \
> > +	upper=$$(echo $*.h | tr a-z A-Z | tr '/.' '__'); \
> > +	printf "\#ifndef ASM_GENERIC_$${upper}\n" > $@; \
> > +	printf "\#define ASM_GENERIC_$${upper}\n" >> $@; \
> > +	printf "\#include \n" >> $@; \
> > +	printf "\#endif /* ASM_GENERIC_$${upper} */\n" >> $@
> 
> I'm curious: In what is now a0f56da94c3e I had to resort to "define" to
> get the rule to work (including a correct .*.cmd being generated). I
> can't claim I actually understood why things didn't work the "simple
> macro" way, and hence it's unclear to me whether the way it's done here
> will work with all make versions.

This works:

cmd_xlat_h = \
	printf "\#ifndef COMPAT_XLAT_H\n" >$@.new; \
	printf "\#define COMPAT_XLAT_H\n" >>$@.new; \
	cat $(filter %.h,$^) >>$@.new; \
	printf "" >>$@.new; \
	printf "\#endif /* COMPAT_XLAT_H */\n" >>$@.new; \
	mv -f $@.new $@

I made these changes:
- tab instead of spaces
- printf instead of echo
- escape # and add \n



> One further difference to that other commit: If make is interrupted in
> the middle of any of these printf-s, an incomplete file may remain. The
> cmd_xlat_h rule specifically uses "mv -f $@.new $@" to cover that corner
> case.

Good point I can fix it


> Finally - is ASM_GENERIC_$${upper} actually correct? Isn't that the
> guard that ought to be used _in_ asm-generic/$*.h?

You are right


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 00:08:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 00:08:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007726.1386990 (Exim 4.92)
	(envelope-from )
	id 1uNKdZ-0002ro-Mz; Fri, 06 Jun 2025 00:08:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007726.1386990; Fri, 06 Jun 2025 00:08:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNKdZ-0002rh-KJ; Fri, 06 Jun 2025 00:08:45 +0000
Received: by outflank-mailman (input) for mailman id 1007726;
 Fri, 06 Jun 2025 00:08:44 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uNKdY-0002fD-L1
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 00:08:44 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 67bdeb19-426a-11f0-a300-13f23c93f187;
 Fri, 06 Jun 2025 02:08:43 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 0E13D43D24;
 Fri,  6 Jun 2025 00:08:42 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id E086CC4CEE7;
 Fri,  6 Jun 2025 00:08: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: 67bdeb19-426a-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749168521;
	bh=Y0eNZf6WgSeSHgRZA85F4qsPOOHxtJMS7AUAA/I8TwU=;
	h=Date:From:To:cc:Subject:From;
	b=bZA9lSmeC54sxYeWMGJVdUIc3DPPaR+6pXLgioqJbQLmx1f5Yd9GmW2ziogqQgREa
	 bRAfMiLfrwyHb2ZEtU0drE57WOgULctqFoDIhgM+QuduNVesQPjPue0Z1vmk2D7Y2L
	 kfbWBuyFmpXXDcE7SipEiM1ap41gxgZThfors7AmjqOeTB/oxTxRPjuzNT4ryrvO8V
	 MxIHKPL+4aFsNYABugqW0zg33ghNnggFTGjmNhL1sTwQ4giFCzF+lGxDZENKdum/Ai
	 c/ehTdwYrTC4sJNmauUNCABYVIKv8TgVKsJwEU+0Msgc9geqBRufwOKbMmZc1bqHL0
	 3/Sk1dD9qeZoA==
Date: Thu, 5 Jun 2025 17:08:40 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: xen-devel@lists.xenproject.org
cc: sstabellini@kernel.org, andrew.cooper3@citrix.com, 
    anthony.perard@vates.tech, michal.orzel@amd.com, jbeulich@suse.com, 
    julien@xen.org, roger.pau@citrix.com
Subject: [PATCH v2] xen: add header guards to generated asm generic headers
Message-ID: 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

MISRA D4.10 requires to have proper header guards in place in all header
files. Add header guards for generated asm generic headers as well.

Suggested-by: Jan Beulich 
Signed-off-by: Stefano Stabellini 
---
Changes in v2:
- write to $@.new and move the file
- change the header guard name
---
 xen/scripts/Makefile.asm-generic | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/xen/scripts/Makefile.asm-generic b/xen/scripts/Makefile.asm-generic
index b0d356bfa3..1e85a92c32 100644
--- a/xen/scripts/Makefile.asm-generic
+++ b/xen/scripts/Makefile.asm-generic
@@ -32,7 +32,14 @@ old-headers := $(wildcard $(obj)/*.h)
 unwanted    := $(filter-out $(generic-y) $(generated-y),$(old-headers))
 
 quiet_cmd_wrap = WRAP    $@
-      cmd_wrap = echo "\#include " > $@
+      cmd_wrap = \
+	arch=$$(echo $@ | sed -n 's:.*arch/\([^/]*\)/.*:\1:p' | tr a-z A-Z); \
+	upper=$$(echo $*.h | tr a-z A-Z | tr '/.' '__'); \
+	printf "\#ifndef $${arch}_GENERIC_$${upper}\n" > $@.new; \
+	printf "\#define $${arch}_GENERIC_$${upper}\n" >> $@.new; \
+	printf "\#include \n" >> $@.new; \
+	printf "\#endif /* $${arch}_GENERIC_$${upper} */\n" >> $@.new; \
+	mv -f $@.new $@
 
 quiet_cmd_remove = REMOVE  $(unwanted)
       cmd_remove = rm -f $(unwanted)
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Fri Jun 06 00:09:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 00:09:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007734.1386999 (Exim 4.92)
	(envelope-from )
	id 1uNKe0-0003MV-V2; Fri, 06 Jun 2025 00:09:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007734.1386999; Fri, 06 Jun 2025 00:09: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 1uNKe0-0003MO-Rt; Fri, 06 Jun 2025 00:09:12 +0000
Received: by outflank-mailman (input) for mailman id 1007734;
 Fri, 06 Jun 2025 00:09: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 1uNKe0-0003Ie-8H
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 00:09:12 +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 78043bd3-426a-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 02:09:10 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id D6FE85C563C;
 Fri,  6 Jun 2025 00:06:51 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9D0B6C4CEE7;
 Fri,  6 Jun 2025 00:09: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: 78043bd3-426a-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749168548;
	bh=V4uGtqs0QvK0S+Uq3jDGTv7De4yMkb77VND9KJjkUfw=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=T1Hhd76ziWeF5BctAc/kRCSfnV8eh/5Bu8rgHlSfdx2VBEqKYwq4idDAAkiyg/kHH
	 0MEW2J7AV99vojNqSSxb2HibPzviN7IbHH1CFmiDhyqaoSQyQN3OxfsV3kLEhdAeRl
	 M+wKtZKk20fNdY/PBjVAImTtWAoK61Fpn4AU96QSBE34hlAcF2T/cV9Qpa6O1qSYc3
	 vaCn8PPOoEVXBhWS6ttZNqKSbkuPA+lwAlptyiWo82QGSgPHNv/TdRlf9XN6GYciuA
	 SfwraKPP8b+UdFGG6+z+T23ka4oJEUXgfmvrrThmYeg0tENu7TpuJflzAjmOrZm77h
	 gKIU9ws6G5zhA==
Date: Thu, 5 Jun 2025 17:09:05 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Nicola Vetrini , victorm.lira@amd.com, 
    Andrew Cooper , 
    Anthony PERARD , 
    Michal Orzel , Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=83=C2=A9?= , 
    Stefano Stabellini , 
    Federico Serafini , 
    Bertrand Marquis , 
    xen-devel@lists.xenproject.org
Subject: Re: [PATCH 1/3] xen/keyhandler: add missing noreturn attribute
In-Reply-To: 
Message-ID: 
References: <20250604235034.1595881-1-victorm.lira@amd.com> <9e3a7b1b-7fbe-428b-888a-c18c95d8ee37@suse.com>  <3b24b1df1a0ce4a62b53067b09fe9a02@bugseng.com> 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Thu, 5 Jun 2025, Jan Beulich wrote:
> On 05.06.2025 14:26, Nicola Vetrini wrote:
> > On 2025-06-05 14:22, Nicola Vetrini wrote:
> >> On 2025-06-05 09:17, Jan Beulich wrote:
> >>> On 05.06.2025 01:49, victorm.lira@amd.com wrote:
> >>>> From: Nicola Vetrini 
> >>>>
> >>>> Function `reboot_machine' does not return, but lacks the `noreturn' 
> >>>> attribute,
> >>>> therefore causing a violation of MISRA C Rule 2.1: "A project shall 
> >>>> not contain
> >>>> unreachable code".
> >>>
> >>> Is this (uniformly) true? Looking at ...
> >>>
> >>>> --- a/xen/common/keyhandler.c
> >>>> +++ b/xen/common/keyhandler.c
> >>>> @@ -251,7 +251,7 @@ static void cf_check 
> >>>> dump_hwdom_registers(unsigned char key)
> >>>>      }
> >>>>  }
> >>>>
> >>>> -static void cf_check reboot_machine(unsigned char key, bool unused)
> >>>> +static void noreturn cf_check reboot_machine(unsigned char key, bool 
> >>>> unused)
> >>>>  {
> >>>>      printk("'%c' pressed -> rebooting machine\n", key);
> >>>>      machine_restart(0);
> >>>
> >>> ... generated code here, I can see that the compiler is perfectly able 
> >>> to
> >>> leverage the noreturn that machine_restart() has, resulting in no
> >>> unreachable code to be generated. That is - neither in source nor in
> >>> binary there is any unreachable code. Therefore I'm having a hard time
> >>> seeing what the violation is here.
> >>>
> >>> That said, I certainly don't mind the addition of the (seemingly) 
> >>> missing
> >>> attribute. Otoh I wonder whether an attribute the removal of which has 
> >>> no
> >>> effect wouldn't count as "dead code" or alike, violating some other 
> >>> rule.
> >>>
> >>
> >> Inlining does not play a role in this case. Here reboot_machine() is 
> >> marked as a violation because machine_restart() is noreturn and there 
> >> is no other path upon which reboot_machine() may return, hence any 
> >> function calling reboot_machine() could have portions that are 
> >> inadvertently unreachable (as in never executed due to divergence) by 
> >> not having the annotation.
> 
> Just that there's not going to be a 2nd caller, considering the purpose
> of the function.
> 
> >> That said, in such trivial cases compilers 
> >> are typically able to derive the property automatically, but they are 
> >> not obliged to and, more importantly, the behavior may even differ with 
> >> the same compiler using different optimization levels.
> > 
> > Just a note: in later revisions of MISRA C this has become a rule of its 
> > own [1], which helps reduce confusion, but up to MISRA C:2012 Amendment 
> > 2 (currently used by Xen), this is part of Rule 2.1.
> > 
> > [1] Rule 17.11: "A function that never returns should be declared with a 
> > _Noreturn function specifier"
> 
> Oh, that's indeed quite a bit more explicit.

Does it mean you would ack the patch? :-)


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 03:52:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 03:52:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007821.1387010 (Exim 4.92)
	(envelope-from )
	id 1uNO86-0005jc-1R; Fri, 06 Jun 2025 03:52:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007821.1387010; Fri, 06 Jun 2025 03: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 1uNO85-0005jV-UX; Fri, 06 Jun 2025 03:52:29 +0000
Received: by outflank-mailman (input) for mailman id 1007821;
 Fri, 06 Jun 2025 03:52:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uNO84-0005jP-Lm
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 03:52:28 +0000
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com
 [2a00:1450:4864:20::135])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a9c7ae88-4289-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 05:52:27 +0200 (CEST)
Received: by mail-lf1-x135.google.com with SMTP id
 2adb3069b0e04-55324587a53so2699470e87.0
 for ; Thu, 05 Jun 2025 20:52:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a9c7ae88-4289-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749181947; x=1749786747; 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=HmiYJOGEmn+SreHNF+cjFhFXeNKSNS2Go8sLiTo6kNM=;
        b=fTMTnAmmOX7gfMsIIhFbGGn4qLhxN7tqcbvkU1cPrHMrIcQZ5+wQW9VzDXxUdaJ77P
         fjnyFmLPWO9me/9SXrk51lKoMe/DnacegRsIy8y0aV1rB39nZfjU3rglvAJxNvSFqZWs
         /MlIWfsySBlodL1N2F+yOKaFeHocL8vGyN8n2gBXqTo+AdBYFdr1/keIf8MscpG6vRhK
         Vd+1+y3kZi0M9ZtvYr1QVIPc7HKhKqaJC3d+SeLQ8gPvnfm3MUh/ZUYNrqMX4HmZEhfQ
         EH0+hF0LkSvKR9XQNOWlFE5dY1EIAgOHPDoXdES+TSMSsjK9e2OY+Eml6nH9sLpBiAx5
         II2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749181947; x=1749786747;
        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=HmiYJOGEmn+SreHNF+cjFhFXeNKSNS2Go8sLiTo6kNM=;
        b=KTOwG5DY5XPfhBIiKJES7ZPa+MLRvHkzuA84bcBXwtRSEUUhl0mngy7aGvL2M5XwYW
         h0Y+ekE7CX1P/PcThaqdPa0GqDAGzKYPwNadxn+L2Qy5mQgJxqh2sJ6jeI4Npk2/dXTv
         Kp5C2XOSTxJqUHZiiOyyh3OL2cb/GCSf7/KP7zCqLjqSTQdhIrAhqZYM/A3Q2JNkcJSS
         Ha/qr92Wpc/QNMddRENVzjl5S/R467/QeuVY3VdUT8GlUdeKoq3Po+StDjzrcWn1yW25
         TpVFGtbyp/UuUXXaaSPyFU3Og0wLS1VbdiFuvmuOBzltWRxsGLU9DaHiarHzrYh/lGYk
         xlwg==
X-Gm-Message-State: AOJu0YxSmNC4mA1bfi/I72i5yIk6KorwDhPFqoY8O6mms/GJ/koRn1oG
	v1HKq0+C+cgE1wBEfu366QCZBkYz8qocE3fuN050q5dD9ubHibPP7EmkWhreQLbIZ/KmCldKt+r
	Aux7xfdO5ObjLXz783GK3x0p7SxWYVgc=
X-Gm-Gg: ASbGncuxU5OzsU2YxAbm4ftWvGS7f7DmZ3KScNpIs8laI0y5cVLhe0NsSpnpJm53MY7
	Ag4NL5nlUOWpOmPWml1Dyww22ezE7RWRpGMfZ86uqh0Axr1goypjPcwGk0AjrKpgX/OZPJWiBK2
	TuX5wPAhjPC2OH5Hn2XMiIYOl4r/ghKCNSKR15JbqFlA==
X-Google-Smtp-Source: AGHT+IGPCKORvjhbabzeVA3cghdGLj7c/CSBHt53h+MhHd1T77RvEyZUrgbv50HxMgZsjJ7BUlidFuAJ450CJwao9QQ=
X-Received: by 2002:a05:6512:1282:b0:553:268e:5011 with SMTP id
 2adb3069b0e04-5535d93f0d3mr1709876e87.26.1749181946578; Thu, 05 Jun 2025
 20:52:26 -0700 (PDT)
MIME-Version: 1.0
References:  <1a8313537603bee36636b0fcd2fdc2f76a2374fb.1748337249.git.mykola_kvach@epam.com>
 
In-Reply-To: 
From: Mykola Kvach 
Date: Fri, 6 Jun 2025 06:52:15 +0300
X-Gm-Features: AX0GCFtWMMuHO8vdIV_xNLhjvMOcEk_D7c8xKcyVE0sbgk-PTaKA85ZT1YqYc4Y
Message-ID: 
Subject: Re: [PATCH v4][PART 1 2/4] xen/arm: Implement PSCI SYSTEM_SUSPEND
 call for guests
To: Julien Grall 
Cc: xen-devel@lists.xenproject.org, Mykola Kvach , 
	Stefano Stabellini , Bertrand Marquis , 
	Michal Orzel , Volodymyr Babchuk 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi, @Julien Grall

On Wed, Jun 4, 2025 at 2:00=E2=80=AFAM Julien Grall  wrote:
>
> Hi Mykola,
>
> On 27/05/2025 10:18, Mykola Kvach wrote:
> > From: Mykola Kvach 
> >
> > This patch adds support for the PSCI SYSTEM_SUSPEND function in the vPS=
CI
> > (virtual PSCI) interface, allowing guests to request suspend via the PS=
CI
> > v1.0 SYSTEM_SUSPEND call (both 32-bit and 64-bit variants).
> >
> > The implementation:
> > - Adds SYSTEM_SUSPEND function IDs to PSCI definitions
> > - Implements trapping and handling of SYSTEM_SUSPEND in vPSCI
> > - Allows only non-hardware domains to invoke SYSTEM_SUSPEND; for the
> >    hardware domain, PSCI_NOT_SUPPORTED is returned to avoid halting the
> >    system in hwdom_shutdown() called from domain_shutdown
> > - Ensures all secondary VCPUs of the calling domain are offline before
> >    allowing suspend due to PSCI spec
> > - Treats suspend as a "standby" operation: the domain is shut down with
> >    SHUTDOWN_suspend, and resumes execution at the instruction following
> >    the call
>
> Looking at the specification, I am still not convinced you can implement
> PSCI SUSPEND as a NOP. For instance, in the section "5.1.19
> SYSTEM_SUSPEND", the wording implies the call cannot return when it is
> successul.
>
> I understand that 5.20.2 ("Caller reponsabilities" for SYSTEM_SUSPEND)
> suggests the caller should apply all the rules from 5.4 ("Caller
> responsabilties" for CPU_SUSPEND), but it is also mentioned that
> SYSTEM_SUSPEND behave as the deepest power down state.
>
> So I don't think standby is an option. I would like an opinion from the
> other maintainers.

Sure, let's discuss this with the others.

>
> > +static int32_t do_psci_1_0_system_suspend(register_t epoint, register_=
t cid)
>  > +{> +    struct vcpu *v;
> > +    struct domain *d =3D current->domain;
> > +
> > +    /* Drop this check once SYSTEM_SUSPEND is supported in hardware do=
main */
> > +    if ( is_hardware_domain(d) )
> > +        return PSCI_NOT_SUPPORTED;
> > +
> > +    /* Ensure that all CPUs other than the calling one are offline */
> > +    for_each_vcpu ( d, v )
> > +    {
> > +        if ( v !=3D current && is_vcpu_online(v) )
>
> I think this is racy because you can still turn on a vCPU afterwards
> from a vCPU you haven't checked.
>

I'll think about how to protect against such cases.
Thank you for pointing that out.

> Did you add this check just to follow the specification, or is there any
> other problem in Xen?

Yes, it's just to comply with the specification =E2=80=94 at least,
I've never seen PSCI_DENIED triggered because of this check.
It's a leftover from a previous patch series.

>
> > +            return PSCI_DENIED;
>  > +    }> +
> > +    /*
> > +     * System suspend requests are treated as performing standby
> > +     * as this simplifies Xen implementation.
> > +     *
> > +     * Arm Power State Coordination Interface (DEN0022F.b)
>
> This comment is a bit too verbose. There is no need to copy/paste the
> specification. You can just write a couple of sentence with link to the
> specification.

Got it, I'll revise the comment accordingly.

>
> Cheers,
>
> --
> Julien Grall
>

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 04:05:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 04:05:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007832.1387019 (Exim 4.92)
	(envelope-from )
	id 1uNOKf-0007Y9-3i; Fri, 06 Jun 2025 04:05:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007832.1387019; Fri, 06 Jun 2025 04: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 1uNOKf-0007Y2-0Y; Fri, 06 Jun 2025 04:05:29 +0000
Received: by outflank-mailman (input) for mailman id 1007832;
 Fri, 06 Jun 2025 04:05: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 1uNOKe-0007Xw-EV
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 04:05:28 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20621.outbound.protection.outlook.com
 [2a01:111:f403:2416::621])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7964b09d-428b-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 06:05:26 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by SJ0PR12MB6902.namprd12.prod.outlook.com (2603:10b6:a03:484::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Fri, 6 Jun
 2025 04:05:22 +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.8792.034; Fri, 6 Jun 2025
 04:05: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: 7964b09d-428b-11f0-a301-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=XBvoD4d/a/s2ruYvHYkDTRN90zm6//mlRPZ2vH2Mq8nTTajiAT5A/wde7m+Pn9ziI9/FplzzcfqYUYUEx4d8dYY55UebNmYBJ6h7quwzj1GVoyHFjUbjfr+JH3OWzbCR3vv4SypU/srZUE3di6DMSjfpTs08aHwAHQp7Vd4q/rYA0w2/1XQekO0Mq2dB+qkPQSdDSi+U18mgXMJJLGs6xku3bUEdWMx/AV2tTbJbS3fFWZF/dpidLFftI5p/qLBCsrqnPhUo/N28sqghaz8c6lf9G8np+TY/4m5FU8UcVwho67RddV/aGBYbNBaYdb64z5s+Ml8zbkARCzYEXf5YKQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=6v0J+gcqrgdV++gz0L83VAg7D22l/I30zVfFVEbKdwI=;
 b=gaUQdNjkNcLbsZe68RjW9iKua5/ET7RNpk6vX00aK9VmI6vNwtTlyP3MikJXzqbrN0qMT9d/z0ULsgdCsKpeeHN3/BlXAYrB7TGu+bZRzk1qQwajpR3EEshSrzKlb1RUfSlAnymGhej5OlfIWEPXl5v7t3AlDd0yfwldSa8rq+c3YpuwGopbdOYXKELxp1anRWnPc6yAkK6JIkJ8T93AvLcW7WIopK8wuWyGMtDBWOWwf3k4gtdq+mTfg6lMjMe+3UpiAviT6JUJL1hT/xXOMywW3wCg78xduEaiSS4MHjXhCZvm5nYIEcjTj4WM5S8J+yGfwmomlNzWAJNyDegDPA==
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=6v0J+gcqrgdV++gz0L83VAg7D22l/I30zVfFVEbKdwI=;
 b=3YIdXNU2zz6o7H8AB8vaNEDLt47WXmAgx3WgQiRlFYVT7YB9G4TzkrYo52goaYIok2yngrc7NVq7hBQi7jNILQdgkQdLFrXccAMfGist+lAi1meYo+yiB7iYWUKUy6oe+dnr0LVWSdZDbxd03MjQigdWUBDE9axLiZttepU4Bho=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= 
CC: "xen-devel@lists.xenproject.org" , "Huang,
 Ray" , "Chen, Jiqian" 
Subject: Re: [PATCH v5 03/10] vpci/header: Emulate extended capability list
 for dom0
Thread-Topic: [PATCH v5 03/10] vpci/header: Emulate extended capability list
 for dom0
Thread-Index: AQHbziMKXidFnyDUhE6S9bEvnc+iZ7P0fIKAgAGdrYA=
Date: Fri, 6 Jun 2025 04:05:21 +0000
Message-ID:
 
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
 <20250526094559.140423-4-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.8792.033)
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_|SJ0PR12MB6902:EE_
x-ms-office365-filtering-correlation-id: f3c1951a-92c2-41e1-9bce-08dda4af5b8e
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?ODlWeUV2VERUdzBIVlMvOUNSUkhUdVRnZE8vSDhuZlpBUkZwMll1TXFwaU9z?=
 =?utf-8?B?Wllhdk1rSGRwVHlZcm5JOWNTdFdLM2ZCdjMvbWptZzJ5ajM5QW9nVlJzcDFp?=
 =?utf-8?B?SXdDV0ErM2dYdFM5STNWVGRYT3ZINDZjbGNwUFUyZE5qRGFtMk41T3NVLzVM?=
 =?utf-8?B?TENpZU40Q2xIZG5aSnhoZ2IvMXZnK1Vkb2o5V0R3ZmF3TXpOaXZ5WER2UkRC?=
 =?utf-8?B?N3NoaHpkQStMZEx2em9PRUYyVjJEWGxJTFNXWkxRYlgxektlQnJqbkpTRlBu?=
 =?utf-8?B?SWJBM3hRWWZ0T3F1Z05wRGZMT0hlNlRoQytCVXNmUHBkenhNSEVOaXpua3Fv?=
 =?utf-8?B?cUNqWStDTTFpOEx0cmJEQWgvczJ2TEc3SjllRDlaaXBNT3ZrbWJlWU9CeUlv?=
 =?utf-8?B?ZXdHZ2RWeVdkbVpsWmhqL3M2OC9QTWVTdE4xM1ZrQ3QvcHNxcEdzcDlaWHQr?=
 =?utf-8?B?MlJqWW42OWFIdDVWZ244V0d2YlhtU1dwQWU1bTA0R3NDSWRGVTMxQ1F6Vkky?=
 =?utf-8?B?L1l3QTBHZ09Ua0hqeE9wdDE5SUxuS1ZDYUpJWXl3VXJ6bUdhNXlaRHNudHZz?=
 =?utf-8?B?MzJUMUxVQVE4Y3ZaRk5lNm9rMXVoUGY5UXZKU0dGSFRJdTcxbTBHd2xFYUp6?=
 =?utf-8?B?azIzaE9FVlhubU54VEhtdEN4aDNva29oMjBNTWt1R2k0UktXbnhac1FmL2J6?=
 =?utf-8?B?L0xtSThMbHZCRGhaRkUxQzFIdEJQQ2k5TUsxSUp6WmMwOVUvQVd6L0c3ZEVR?=
 =?utf-8?B?QUZyc0J5TEFVK2kwcTI2YVAwWEw4ZGVjRlRYL256TkJnbktHZzVhSFR3R2FT?=
 =?utf-8?B?anczRUVVaEZ1OE1xclpnTXVlWlhhTHhpc3UyNnNrWGdRaFVuTFcyTFp5QURt?=
 =?utf-8?B?MWRCME1uVEU2bDFIKy9uK3NRYzFXbHFSeUlDMVhubyt3eFYrUTRWSktVeUc4?=
 =?utf-8?B?TVFZRmFWbk8vTFZ4MEo2RnhhdmpiRGp0eXkrcEJPbnR2aEVTYy8vUXpjOWI2?=
 =?utf-8?B?eVNuOTNQVjBtemNmT3BGL3NMd1ZXVk12TDM0cGFYWG5HeGI2ejQ1OGkwTTVL?=
 =?utf-8?B?ci9PSWNQQWVPMTBOL0NRMWY3QUMrem5MU09HSzZBTU1hTVBTWDZ6UVNGQXRU?=
 =?utf-8?B?RW1TM0RMOHR3aFhzYUs5am52WSt2Z1lOdzFycURtRWs1K0JQNDhabWt4Zzd4?=
 =?utf-8?B?RUw0ZERlQVVvR0YveERkVERkQW9WVXhUU0RpMytJQWRadnJDMUdzMEN2cEFN?=
 =?utf-8?B?UVZ1VUdoTU42akgwNWg5TkFQNko5dllHYWQ1U3pIQmNrYk83MGhuVkN0R0tW?=
 =?utf-8?B?WkRrSkVMMU42a0pCaVlmME9RVXdmVUpqR1RFa2JQVEhDUzdJTGpOSklKenhK?=
 =?utf-8?B?SUt0cnd0cHd6TmJuMlFBOTk4RGFmNGxER2V4c3VTQ0xZM0x0Uy92UndhNGFS?=
 =?utf-8?B?c2VxakRzc1dCeXZKd3RmSEFSYkZORzQ5RG1ac0pBdzlRdEpualo0TlgxNGl0?=
 =?utf-8?B?MFlOK3B6eHJFcHdhRE4rYUFITkcwTkppM1BydDdReTJKMHh6VWFlU1pISDJv?=
 =?utf-8?B?VllXMEppNTNPT0tOdW5VTUxtVkVJMXVLT2pNOWZoWkhFTzVDWlcyYjMraUt6?=
 =?utf-8?B?KzgzRHR5MDdOYTdiYUNCRzVrWW9KQ3ZWWmZsek5OSEJ4dDMyb2dycjBpVkI1?=
 =?utf-8?B?eGVjQ0cydjFHOFV1MmFsWmQ5dlZySlAxZlpQZnU0ZkhDaGJRQmZWemloR056?=
 =?utf-8?B?RnVsOXFJeUxlbThIS1ZqUHFMZi96QjZocFBOSGM0Uit6M1BnU2RCSUpzQXhz?=
 =?utf-8?B?OE02RytUU3lVbzV6emdnbGtGWjQxWUJQbFA3YTVnc2NjUStzU3JXSlJuTEdw?=
 =?utf-8?B?SmJ0cEIyQXNZNHRWdXN3WWIxamZjNzBpMlpQREVUU01HTG1IUGNZamlsWFFt?=
 =?utf-8?B?U1gzRnh4eXBUcXZsd3NFcGVmYzNSVkowS3ByNzRGR29YdENPeGtmSjk1ZCtS?=
 =?utf-8?B?YVEyZzliQitnPT0=?=
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?bnhKSFpReklaa0xrS0pnTk9hdTA2Rm9ESDAvTGNYM0RNRVVTcWpISGU2WTEw?=
 =?utf-8?B?RW1NdGQxNzBBcFpLUjNjU0oxSTVMK0wrS2RkSFpWY2lmOFNCZDdKYXlBdlY0?=
 =?utf-8?B?VTNVdFJRMDAvSS9XMWxlclMzYzJyY0UvZlFwUGQyaXRLaE1wYTZYTVBBV0I5?=
 =?utf-8?B?YVdEeDdWVWVZY3ZkN2lEZ215ZzRXaCtwRjBNVHFoYnE1NC8rdURIVUpzWUo5?=
 =?utf-8?B?VGZkdmVtWlNHcE1jQS9HUzNDS1M5a1VQcjRacUMyU3FtaWk4UEh4QWNWL3RC?=
 =?utf-8?B?d3hFYkc5SGgyZTFaYUhJTnhHUnB0QUg5NGFTb2VHUFN4Uy9tY3VqU0hyT2l6?=
 =?utf-8?B?SDhpd0d5RFpWdlRTOGhPS1I0WFc3aTJPN0ZDK1QzMVhaZXl6dG1rdkJnOU10?=
 =?utf-8?B?clRHWG5CcGJDNjNFYnJySzFhYVczQWVZMmFyWU4rZit4MTRvTlI4L3ppMnBw?=
 =?utf-8?B?dmNENGNTTDNlYmdVV1Fzcm93bnFHeW5OeHdsWkI2ZStnR2JEbzlGQkM4NWFi?=
 =?utf-8?B?SU4wVGlsSStDTWE2aHBuMmZXZ3Jta2pwajBCZldhOUpFaU5kZTJWRWxlYlNK?=
 =?utf-8?B?ZDBoN3o4TGlVbVpEa250RGt6bEU2anVNcGUxSGJIa2ZMTzAyMS84dFlJQWRI?=
 =?utf-8?B?YTBxNEpmUmZwYkV0Skp0ZzRZMStON2NkY3hXbHRuN01HNHpybHJiMngvVFgy?=
 =?utf-8?B?ZCtwQTdTci93VWU3UThNSEwvL2JwcTlpMzRNMmFNdGZWQTlzdjNULzFtTFdu?=
 =?utf-8?B?Z3JBaUJhVjFGVkpmN1o0NHdNRjBiTzJyY1o5a3lqVFFsNE1CUVd5b3dlZG0y?=
 =?utf-8?B?dWZyYitRTXM2UTJKNmRSamRmamZxd2graGFxQmthTi9peG1hTEVhZFVXU1RD?=
 =?utf-8?B?RDIwUWdqeTBVV3pXMGM5dWlCSHhHTnNPRVBVTWw3d0NSYkEvU1BWZHV6a1Rj?=
 =?utf-8?B?bUJUUnZEMmNJQ20vRG1NbGVVcWVhVWJoeXdlNmo1QXJWYmJLeHBDN2tzMTlO?=
 =?utf-8?B?d2hObDRvdzc4RlRlbm1PbTUraFoxc2FEREswT1RKd0hEVWxMM2JwRjgwRHc0?=
 =?utf-8?B?YTl0bkROZkRoa0tBVDVKa0RyYTQ0UW9HdXNhdGthSUNHb2NJa2xxdDlLMjNK?=
 =?utf-8?B?MllrRkx6MmlQbFFOSmVRMkNFYkh4QlZXNnVHVUVwejFIdXQwYjN6a3NsZGRq?=
 =?utf-8?B?dXgvc0lXMXlmWFdsTzVNcy9rbVN3dk4vTldTeDlMMWtOU1E5L3o2cVJIZnJw?=
 =?utf-8?B?ZzR2NzlxMHZYNGRyRXNTZFdWTU1HdUhiSmJuVGFkU29QcktQNUlITDZ6SFJq?=
 =?utf-8?B?OTlFWkY5cGJqd0s5OXBlak9ybjNmdWdyaGd3U0RhdXZuQTM4WXdTazI1enp3?=
 =?utf-8?B?ZE5aaVlXSHpSNGt1bG9oVmExdFZmRnlKb0I2OW1HVExwOEpOVFhRaUI1aFZN?=
 =?utf-8?B?THVPR3QrSkRmMEJ5RGVQaStOQW14THVuNCt2L1BrbHFUZmtDV08wMEwxT0Zx?=
 =?utf-8?B?UWRwV1d5TmE5YUY0MFBQSjlqRmFjN2krQWZvM0toMzR4NnhJSnNyRjlYdmV4?=
 =?utf-8?B?SU12TVpJaHdrOHdtVlMyeGlBdHBVWno2OWtyTCtxMHJaME93R3NnNFJhTEw1?=
 =?utf-8?B?ZnkrTWlMemRud3VOamFENnA5TlNUWnd6RGlhbFdoZnhwMzdmZGVCS0VCTlg4?=
 =?utf-8?B?cjNUM0YzeTNZa0hZdW9CNTljMkNDSHNjMUhHT1JQd2FrYzZpNXhkUCt0NUZ2?=
 =?utf-8?B?U0d3NUJxd3FmanVReTcvQVRYWWZFeitUYUZFY1lhSDgwdkFRYXpPV3AyTnRD?=
 =?utf-8?B?dUtlUFdseGFKd0xZMGZUWHF0VlB2SzBueSsvOXdkdWswVXlmU1NNYTFmZ25K?=
 =?utf-8?B?dkp6VFQ2cjBMOFpLVjc5ZEFhTGRlTWI0Y3pnRkhuWGk1eXFEZUhOcGc0dUR6?=
 =?utf-8?B?YlZMSWRYWXNlUnUrbWlDcVFJZmgxTTdaaktNOTVNUW0zcHMzN1o0WGVoTGRS?=
 =?utf-8?B?eTF6ajgzS3RiQUZvVVFTenArZXlvSlNQWjdnT0FEZzNrdWNvakp2VFhSanNT?=
 =?utf-8?B?amlrSmxFcEd2SUEzWlJrcjJGTDJXSGlFVUFtMUNxTEQzenltNkVuYkZtdHRB?=
 =?utf-8?Q?HJrg=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: f3c1951a-92c2-41e1-9bce-08dda4af5b8e
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2025 04:05:21.8460
 (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: Cigay1WntRDpmBlV/ViOPSqAubbzje8GWGQ2gK8G1KRPyzrThRv0Ppp3KWyLujpZHu2ykZWOgPnfOtExoMSADw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB6902

T24gMjAyNS82LzUgMTk6MjQsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+IE9uIE1vbiwgTWF5
IDI2LCAyMDI1IGF0IDA1OjQ1OjUyUE0gKzA4MDAsIEppcWlhbiBDaGVuIHdyb3RlOg0KPj4gQWRk
IGEgbmV3IGZ1bmN0aW9uIHRvIGVtdWxhdGUgZXh0ZW5kZWQgY2FwYWJpbGl0eSBsaXN0IGZvciBk
b20wLA0KPj4gYW5kIGNhbGwgaXQgaW4gaW5pdF9oZWFkZXIoKS4gU28gdGhhdCBpdCB3aWxsIGJl
IGVhc3kgdG8gaGlkZSBhDQo+PiBleHRlbmRlZCBjYXBhYmlsaXR5IHdob3NlIGluaXRpYWxpemF0
aW9uIGZhaWxzLg0KPj4NCj4+IEFzIGZvciB0aGUgZXh0ZW5kZWQgY2FwYWJpbGl0eSBsaXN0IG9m
IGRvbVUsIGp1c3QgbW92ZSB0aGUgbG9naWMNCj4+IGludG8gYWJvdmUgZnVuY3Rpb24gYW5kIGtl
ZXAgaGlkaW5nIGl0IGZvciBkb21VLg0KPj4NCj4+IFNpZ25lZC1vZmYtYnk6IEppcWlhbiBDaGVu
IDxKaXFpYW4uQ2hlbkBhbWQuY29tPg0KPj4gLS0tDQo+PiBjYzogIlJvZ2VyIFBhdSBNb25uw6ki
IDxyb2dlci5wYXVAY2l0cml4LmNvbT4NCj4+IC0tLQ0KPj4gdjQtPnY1IGNoYW5nZXM6DQo+PiAq
IEFkZCBjaGVjazogaWYgY2FwYWJpbGl0eSBsaXN0IG9mIGhhcmR3YXJlIGhhcyBhIG92ZXJsYXAs
IHByaW50IHdhcm5pbmcgYW5kIHJldHVybiAwLg0KPj4NCj4+IHYzLT52NCBjaGFuZ2VzOg0KPj4g
KiBBZGQgY2hlY2sgImlmICggIWhlYWRlciApICAgcmV0dXJuIDA7IiB0byBhdm9pZCBhZGRpbmcg
aGFuZGxlciBmb3INCj4+ICAgZGV2aWNlIHRoYXQgaGFzIG5vIGV4dGVuZGVkIGNhcGFiaWxpdGll
cy4NCj4+DQo+PiB2Mi0+djMgY2hhbmdlczoNCj4+ICogSW4gdnBjaV9pbml0X2V4dF9jYXBhYmls
aXR5X2xpc3QoKSwgd2hlbiBkb21haW4gaXMgZG9tVSwgZGlyZWN0bHkgcmV0dXJuIGFmdGVyIGFk
ZGluZyBhIGhhbmRsZXIoaGlkaW5nIGFsbCBleHRlbmRlZCBjYXBhYmlsaXR5IGZvciBkb21VKS4N
Cj4+ICogSW4gdnBjaV9pbml0X2V4dF9jYXBhYmlsaXR5X2xpc3QoKSwgY2hhbmdlIGNvbmRpdGlv
biB0byBiZSAid2hpbGUgKCBwb3MgPj0gMHgxMDBVICYmIHR0bC0tICkiIGluc3RlYWQgb2YgIndo
aWxlICggcG9zICYmIHR0bC0tICkiLg0KPj4gKiBBZGQgbmV3IGZ1bmN0aW9uIHZwY2lfaHdfd3Jp
dGUzMiwgYW5kIHBhc3MgaXQgdG8gZXh0ZW5kZWQgY2FwYWJpbGl0eSBoYW5kbGVyIGZvciBkb20w
Lg0KPj4NCj4+IHYxLT52MiBjaGFuZ2VzOg0KPj4gbmV3IHBhdGNoDQo+Pg0KPj4gQmVzdCByZWdh
cmRzLA0KPj4gSmlxaWFuIENoZW4uDQo+PiAtLS0NCj4+ICB4ZW4vZHJpdmVycy92cGNpL2hlYWRl
ci5jIHwgNDcgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKystLS0tLS0tDQo+PiAgeGVu
L2RyaXZlcnMvdnBjaS92cGNpLmMgICB8ICA2ICsrKysrDQo+PiAgeGVuL2luY2x1ZGUveGVuL3Zw
Y2kuaCAgICB8ICAyICsrDQo+PiAgMyBmaWxlcyBjaGFuZ2VkLCA0NyBpbnNlcnRpb25zKCspLCA4
IGRlbGV0aW9ucygtKQ0KPj4NCj4+IGRpZmYgLS1naXQgYS94ZW4vZHJpdmVycy92cGNpL2hlYWRl
ci5jIGIveGVuL2RyaXZlcnMvdnBjaS9oZWFkZXIuYw0KPj4gaW5kZXggZDI2Y2JiYTA4ZWUxLi40
YjJmNzYxYzljMjQgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vZHJpdmVycy92cGNpL2hlYWRlci5jDQo+
PiArKysgYi94ZW4vZHJpdmVycy92cGNpL2hlYWRlci5jDQo+PiBAQCAtODM2LDYgKzgzNiw0MiBA
QCBzdGF0aWMgaW50IHZwY2lfaW5pdF9jYXBhYmlsaXR5X2xpc3Qoc3RydWN0IHBjaV9kZXYgKnBk
ZXYpDQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBDSV9TVEFUVVNfUlNW
RFpfTUFTSyk7DQo+PiAgfQ0KPj4gIA0KPj4gK3N0YXRpYyBpbnQgdnBjaV9pbml0X2V4dF9jYXBh
YmlsaXR5X2xpc3Qoc3RydWN0IHBjaV9kZXYgKnBkZXYpDQo+PiArew0KPj4gKyAgICB1bnNpZ25l
ZCBpbnQgcG9zID0gUENJX0NGR19TUEFDRV9TSVpFLCB0dGwgPSA0ODA7DQo+IA0KPiBJIHRoaW5r
IHlvdSBjYW4gZHJvcCB0aGUgdHRsIHZhcmlhYmxlLCBhcyBzYWlkIGJ5IEphbiBpbiBhIHByZXZp
b3VzDQo+IHJldmlldywgdGhlIHB1cnBvc2Ugb2YgdGhhdCBjb3VudGVyIGlzIHRvIGRldGVjdCBv
dmVybGFwcyBpbiB0aGUgUENJZQ0KPiBjb25maWcgc3BhY2UsIGJ1dCBmb3IgdGhlIGNvbnRleHQg
aGVyZSB0aGUgY2FsbCB0byB2cGNpX2FkZF9yZWdpc3RlcigpDQo+IGFscmVhZHkgc2VydmVzIHRo
YXQgcHVycG9zZSBieSByZXR1cm5pbmcgLUVFWElTVC4NCldpbGwgZG8gaW4gbmV4dCB2ZXJzaW9u
Lg0KDQo+IA0KPiBUaGFua3MsIFJvZ2VyLg0KDQotLSANCkJlc3QgcmVnYXJkcywNCkppcWlhbiBD
aGVuLg0K


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 06:07:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 06:07:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007858.1387029 (Exim 4.92)
	(envelope-from )
	id 1uNQEX-0005lM-HD; Fri, 06 Jun 2025 06:07:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007858.1387029; Fri, 06 Jun 2025 06:07: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 1uNQEX-0005lF-EL; Fri, 06 Jun 2025 06:07:17 +0000
Received: by outflank-mailman (input) for mailman id 1007858;
 Fri, 06 Jun 2025 06:07: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 1uNQEU-0005l7-TD
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 06:07:16 +0000
Received: from mail-24416.protonmail.ch (mail-24416.protonmail.ch
 [109.224.244.16]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7d423395-429c-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 08:07:13 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7d423395-429c-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1749190032; x=1749449232;
	bh=N8xZEme2Mh/YhfBG/P9ruymjFMKE8qF7nI9WILeO5WA=;
	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=QbzS0SEsZXhf/y7UZK+ksd0rUz9azPN0hlkl5AtjbvMj1FVfWwJSGtuTwe+7HOprb
	 Nplj/jLPjjYS1k7LC6mbeNUu8+uDaFTTc5OCuFmKK7ztayBJSsr+ev0y5yD/aflFNL
	 MbvlqHgpGaT2fsQTR693Uj55ePlW6aUIDE0BFxCFDFK5N3hgxU0GNylV1ejpHpOc3Q
	 4bnBuiQMb8JRTIAAWcsU0H5Hmkd0G2lJj67XeWDJUORbzy/4NjisYxAoDe48dnQ5eW
	 o1RvkC5o5njjGHchG/ShkSFv2vlL/2+jZrm02iHuyvZ166sG7Rh935Ja4irq9sJTCq
	 JkrHBL8Y1ygpw==
Date: Fri, 06 Jun 2025 06:07:06 +0000
To: Julien Grall 
From: dmkhn@proton.me
Cc: Jan Beulich , andrew.cooper3@citrix.com, anthony.perard@vates.tech, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v5 3/4] xen/console: remove max_init_domid dependency
Message-ID: 
In-Reply-To: 
References: <20250530231841.73386-1-dmukhin@ford.com> <20250530231841.73386-4-dmukhin@ford.com>  
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 877e604a28035a8d8076cc6aba3c0a1639f3d8f3
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 05, 2025 at 11:20:32PM +0100, Julien Grall wrote:
> Hi Jan,
>=20
> On 04/06/2025 13:55, Jan Beulich wrote:
> > On 31.05.2025 01:19, dmkhn@proton.me wrote:
> >> --- a/xen/common/domain.c
> >> +++ b/xen/common/domain.c
> >> @@ -2461,6 +2461,39 @@ void domid_free(domid_t domid)
> >>       spin_unlock(&domid_lock);
> >>   }
> >>
> >> +/*
> >> + * Find the ID of the next possible console owner domain.
> >> + *
> >> + * @return Domain ID: DOMID_XEN or non-system domain IDs within
> >> + * the range of [0..DOMID_FIRST_RESERVED-1].
> >> + */
> >> +domid_t domid_find_with_input_allowed(domid_t hint)
> >> +{
> >> +    domid_t domid =3D DOMID_XEN;
> >> +
> >> +    if ( hint < DOMID_FIRST_RESERVED )
> >> +    {
> >> +        struct domain *d;
> >> +
> >> +        rcu_read_lock(&domlist_read_lock);
> >> +
> >> +        for ( d =3D domid_to_domain(hint);
> >
> > If the domain with ID "hint" went away, what is being switched to chang=
es
> > compared to behavior prior to this patch, if I'm not mistaken. While th=
is
> > _may_ be acceptable, not saying so in the description is imo a no-go.
> >
> >> +              d && get_domain(d) && d->domain_id < DOMID_FIRST_RESERV=
ED;
> >
> > What's the DOMID_FIRST_RESERVED check for? And where's the put_domain()
> > for the get_domain() here?
> >
> >> +              d =3D rcu_dereference(d->next_in_list) )
> >> +        {
> >> +            if ( d->console.input_allowed )
> >> +            {
> >> +                domid =3D d->domain_id;
> >> +                break;
> >> +            }
> >> +        }
> >> +
> >> +        rcu_read_unlock(&domlist_read_lock);
> >> +    }
> >> +
> >> +    return domid;
> >> +}
> >
> > My concern remains: With many domains, the loop here may take quite a f=
ew
> > iterations. That's even more concerning because it regresses right away=
 in
> > environments where along with boot-time created domains (eligible for
> > console focus) later further domains are created (non of which are elig=
ible
> > for console focus). That is, the step from last boot-time created back =
to
> > DOMID_XEN may now take excessively long.
>=20
> +1. I vaguely recall making the same concern earlier in the review. One
> possibility would be to have a list of domains where the console is
> supported. I don't think it would be necessary to have the list sorted
> as I view the console switching a debug facility.

Jan, Julien,

Thanks for the feedback!
Will rework.

>=20
> Cheers,
>=20
> --
> Julien Grall
>=20
>=20



From xen-devel-bounces@lists.xenproject.org Fri Jun 06 06:24:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 06:24:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007873.1387040 (Exim 4.92)
	(envelope-from )
	id 1uNQVQ-0000LX-UC; Fri, 06 Jun 2025 06:24:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007873.1387040; Fri, 06 Jun 2025 06:24:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNQVQ-0000LQ-QJ; Fri, 06 Jun 2025 06:24:44 +0000
Received: by outflank-mailman (input) for mailman id 1007873;
 Fri, 06 Jun 2025 06: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 1uNQVP-0000LK-9X
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 06:24:43 +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 eb25a77b-429e-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 08:24:38 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a375e72473so834450f8f.0
 for ; Thu, 05 Jun 2025 23:24:36 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-31349f17bd2sm682193a91.5.2025.06.05.23.24.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 23:24:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: eb25a77b-429e-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749191076; x=1749795876; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=c6ZmDoNRz4N6sQ+bbBK0fVk623wioHylixoxsvSDo64=;
        b=eSLY8RpS+QgnWLqharuI5XMIuXsB0kGRfwbJJzCExt5qNyu2wZbAgfkRMQcxvAYo1a
         2uZEC+3dmpu836r26JJh4a40kMwo/Lu4my4smOg0Jkg1NQbfKqRdbJfrjqc+wVZY9BWo
         D67f1Fzr0KVXeAMy91Cihbq7+bw2Nj4+4SBKzp41lh3y7AYDm4Wt2N3bveuuFl5ncF3x
         WPLdXs5fMvBMT7+MpPhRKougS9Fzh1NvMfNOklqO+R/rC6j4ASHMo4/pz3xNmwF5zrOa
         UB07yC2G4Qo7Zh3S1hai9cK6/jVmHN6DUv0oeYlNXiXKswabIs/bNfQCRVrpdZWaTy70
         Vo/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749191076; x=1749795876;
        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=c6ZmDoNRz4N6sQ+bbBK0fVk623wioHylixoxsvSDo64=;
        b=CVXmgPBE0QVeoLw+k3h5mCwUXPsyyLtc92hHUb7ckaiVQ7qYZJNyxp2p8Z9K4UVt/W
         SboUO1KNVQ9jJvS5AYz1DPrgY22XP/EvoKXrGQcJ103qf0yrNPFHPXX9exltGCjXTQGG
         CfZncMqXE81faTHHeFm3/Bc/D/BMhylaopS3WZPpoHKnh+/POwYu4C2m13ME/EDj70sY
         XoFi/a1m9hO9nVC9Iku3VZEcQ6ewxg/91a9Um1Cu/rKBfWR5FyukP5BvT9NmD8yceCDS
         ZwEzTRdu7FePerAV7NSdO4PjKhiuShfcN/kN/YfbH/tl3ZcZiNyGzc5jnWWlOQIFrkSw
         fc7g==
X-Forwarded-Encrypted: i=1; AJvYcCUASIjFr4lUM3KGjGUc4sIEZyFObV3R/X6CA3PY1iqVyD5XFxPOIIIQQOkm0CV72hRGKNec1zvP52k=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yznz1QhRN/efgk3jb3nJY72cmWPPqLC6QCpUcau8W9UxYEdTJge
	jlPNWTNDjKEKM368pvvfNU+CKB9Y7U2pD7gMI1nHAI5IjZMByiNW0apRH7UtVCImnw==
X-Gm-Gg: ASbGncufizqYaDuh9VaQTW03xtvI6HlXUeGtqH0TfIywxrIdRSV+PzIPPOX5t+5wOxs
	v69ddjElQ6sTM7hPQXRLz2I6oONgJE/3UvLXFD/cQ/xmGTZwJPLon95YBVZaaQl3gqZu5iCq+Rz
	KbZzrmYroCEwVm4lyb4DrFKnjHU1GZHQ5WHuGxaHBG0VsA+ejjY2IAQrvfAEJet+AfIr8HFS7Au
	sMh33cKdrBVvaLhquRCB2F4Uk2xouNjVR8KlcFzrrNK54JdfC9psAsC8F6heAAaUd5gu9jTJsQD
	7eALFlGU7zN+ayviT7aQHbgsxo6P/n3t1e+pHNCG4xdiHGU9owVZUWDFuwm69PEgDsPkgwhVrOE
	8s/+DMnuCJQCKkOT7SWnJKywAnEC0VsKUC5Apy/9nTc/CBnet0dkeHHKv/Q==
X-Google-Smtp-Source: AGHT+IFWlqB67XrpaM7QjiSiwfMBJ9W7/iEIAezUwB2uCvQHvPDbqJO4g8zEEUul9usGkeSiPLIyLw==
X-Received: by 2002:a05:6000:4013:b0:3a4:edf5:b942 with SMTP id ffacd0b85a97d-3a531cc1aaemr1789843f8f.57.1749191076029;
        Thu, 05 Jun 2025 23:24:36 -0700 (PDT)
Message-ID: <34dc92c0-9046-482b-b1e2-fab62972da8e@suse.com>
Date: Fri, 6 Jun 2025 08:24:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 06/19] xen: Clean up asm-generic/device.h
To: Alejandro Vallejo 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Oleksii Kurochko ,
 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: 
 <20250530120242.39398-1-agarciav@amd.com>
 <20250530120242.39398-7-agarciav@amd.com>
 
 
 
 
 <8768b970-6c62-4fc4-8ef5-b74f1aa650e6@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 05.06.2025 18:48, Alejandro Vallejo wrote:
> On Thu Jun 5, 2025 at 4:20 PM CEST, Jan Beulich wrote:
>> On 05.06.2025 16:15, Alejandro Vallejo wrote:
>>> On Mon Jun 2, 2025 at 4:24 PM CEST, Jan Beulich wrote:
>>>> On 02.06.2025 16:19, Alejandro Vallejo wrote:
>>>>> On Mon Jun 2, 2025 at 9:51 AM CEST, Jan Beulich wrote:
>>>>>> On 30.05.2025 14:02, Alejandro Vallejo wrote:
>>>>>>> --- a/xen/include/asm-generic/device.h
>>>>>>> +++ b/xen/include/asm-generic/device.h
>>>>>>> @@ -6,9 +6,7 @@
>>>>>>>  
>>>>>>>  enum device_type
>>>>>>>  {
>>>>>>> -#ifdef CONFIG_HAS_DEVICE_TREE
>>>>>>>      DEV_DT,
>>>>>>> -#endif
>>>>>>
>>>>>> Why would this enumerator need exposing on a non-DT arch? In fact I would have
>>>>>> hoped for ...
>>>>>
>>>>> A non-DT arch would not include this. x86 doesn't.
>>>>
>>>> Both here and ...
>>>>
>>>>>>>      DEV_PCI
>>>>>>
>>>>>> ... this to be hidden for arch-es not supporting PCI.
>>>>>>
>>>>>> Similar concerns elsewhere in this change.
>>>>>
>>>>> This file is exclusively used by arches supporting DT to abstract away where
>>>>> the device came from. x86 does not use it at all, and while it wouldn't be
>>>>> impossible to compile-out DEV_PCI, it would needlessly pollute the codebase with
>>>>> no measurable gain, because the abstractions still need to stay.
>>>>
>>>> ... here: In "xen/include/asm-generic/device.h" there's nothing at all saying
>>>> that this file is a DT-only one. Instead there is something in there saying
>>>> that it's suitable to use in the entirely "generic" case.
>>>>
>>>> Jan
>>>
>>> Try to use it from x86 and observe the build system catch fire. It could be made
>>> to not go on fire, but it implies heavy refactoring in x86 (particularly IOMMU
>>> code) for no good reason because there's no devices in a DTB to disambiguate.
>>>
>>> How about adding this to the top of the header?
>>>
>>> ```
>>>  /*
>>>   * This header helps DTB-based architectures abstract away where a particular
>>>   * device comes from; be it the DTB itself or enumerated on a PCI bus. 
>>>   */
>>>
>>>   [snip]
>>>
>>>  #ifndef CONFIG_HAS_DEVICE_TREE
>>>  #error "Header meant to be used exclusively by DTB-base architectures."
>>>  #endif
>>> ```
>>
>> Might be fine, together with giving the file a name somewhat referring to DT.
> 
> That would bring it out of sync with x86's asm/device.h. Both of them define
> device_t and doing so in differently named headers would just be confusing for
> everyone.

Okay, then the name can't change. In which case the #ifdef-ary needs to remain,
imo, to keep the header being "generic".

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 06:26:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 06:26:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007888.1387050 (Exim 4.92)
	(envelope-from )
	id 1uNQXR-0000tk-8G; Fri, 06 Jun 2025 06:26:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007888.1387050; Fri, 06 Jun 2025 06:26:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNQXR-0000td-5J; Fri, 06 Jun 2025 06:26:49 +0000
Received: by outflank-mailman (input) for mailman id 1007888;
 Fri, 06 Jun 2025 06:26: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 1uNQXP-0000iu-KX
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 06:26:47 +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 37077029-429f-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 08:26:44 +0200 (CEST)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3a4ef2c2ef3so1448189f8f.2
 for ; Thu, 05 Jun 2025 23:26:44 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2360307832dsm5697815ad.52.2025.06.05.23.26.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 23:26:43 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 37077029-429f-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749191203; x=1749796003; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=i03ce/j8kWJ56FGCgn62re4EOYij4bYvFBCVqTSi/7A=;
        b=CvqwIqSNDe0FkPBlPR6gZjpvozJfOSw50zqq2rtOBMusErtQ5ajqhzvNCAG+rkKpgU
         Chzw+G+IHoqC4Hp2d3+zQ+BGJgt7/zoD3vLpA/Sa9MQCxu8pXLyhbredMXed0zIHyiRH
         b6E2bJqplMEDxe95KsR5MSxsLXAMmcXLWjtNEt0SbEP+VcTq5uYY+5ak+u0XwHfEM3Kj
         bNOH8Um6Gl6X3Hg393EtMFGWeVhP6Xl3GjwB5+xCzGmVnQ/3LmAoQA611A1N36v15Lkz
         s6kWGy94aY+MRR6oG4AEBcYflWLDVgd/eSgZiCH4tqTnfcm/Ohnnwv17riAi8NFzfk5S
         bA/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749191203; x=1749796003;
        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=i03ce/j8kWJ56FGCgn62re4EOYij4bYvFBCVqTSi/7A=;
        b=dymg6dtY4JQHvtCP3LEFQQxnomWGEukO6s2lRUXjJpId5NBlhZyQmKlTV9uSCOoXJ2
         r77Mi2Nyanlq5sAqt8770ewaEH5esmCrIxJTQ6NY0Q8SA2k0002cYVM6WDM5Kg3NszPB
         CrtYiteQHMYe8t6w/p+9ml2pPhPw5NgH6Kfs57VJHqwRuUUZICYLZs5Yhure8+6LeT13
         BAGZeCg5k209/U3c+mjV+wwwr18nppE3sk/+gRRwL5vCN+WuoUiGUF7/Ag/wziqmu8Ac
         qtuH5LXtI1dylrm+jYA658rlY4i0qKwuhgAzVF5j8eE6MLDFPgxrvLyzL7JxJxuTO6jF
         EB+A==
X-Gm-Message-State: AOJu0YyH6omP2+KuO8SlHM0dO3UUzTdVvLdGKTPrRzaUhLcK+Lhnt9cp
	KofH48FarP7UDuneQcwMakkw7NjMIevpXBE7G02MAQ3KLoBKaTnHOV+9/BnIWQbKCw==
X-Gm-Gg: ASbGncu9X19uwlHqTB8dDiLyQeMwMheXZa//Yx7H2NWMDTvFZymdEZm13Ar5mcqOuVP
	0Q0fAAfec7r0254c4QjuuS2lcbuU3QpHrYZhxl4l9wAaDvFIJpOLzpfAxXEgXXPLL3iZqgBWP61
	Oqd5xh01vNYwvCzezGeDUnwrj3gNAL6Tv4PvrO1LiAg980aOYDBll9VbIVQBUiwlfPYmqWcDJ8R
	zeISix+fNSXAabVGEz9BFTzOgEuut9GAVADZmP/1Jh1y0oULHzXup3KXYE1S/bz9f3O9SLXSTxR
	dKJ+dajBf5Sm8DFEHLQrERB9cAyi2CSYYTsUSe3pCN9MTGVoPBARqDXewYLmgr1Qb3Uq+/91zA8
	0izdnf//NUvu11p1kI56HDRTchmNHLx3N06uo
X-Google-Smtp-Source: AGHT+IFLEYwVXmlMX4cd+pA0o9hHP0KQcsPN5qRXbFPr+e8ZMRQIbim4evRJLzOtGdf7Csu9fRm9BA==
X-Received: by 2002:a5d:584e:0:b0:3a4:d5e8:e352 with SMTP id ffacd0b85a97d-3a5319b6a33mr1689221f8f.7.1749191203460;
        Thu, 05 Jun 2025 23:26:43 -0700 (PDT)
Message-ID: <83c22da9-62c5-4fb2-bc2d-f34ad5956d3e@suse.com>
Date: Fri, 6 Jun 2025 08:26:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/5] console: add relocation hook
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 
Cc: xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini ,
 Andrew Cooper 
References: 
 <4f1889dc03ec4aa2cc0cd2bd14523a2c6f670bdb.1748182535.git-series.marmarek@invisiblethingslab.com>
 <0b17da9c-57db-4a8b-90af-e53e45cb1243@citrix.com> 
 <66cfdee6-5dc2-4139-8550-ef441fa7a7a0@suse.com> 
  
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 05.06.2025 18:08, Marek Marczykowski-Górecki wrote:
> On Thu, Jun 05, 2025 at 06:05:02PM +0200, Jan Beulich wrote:
>> On 05.06.2025 16:51, Marek Marczykowski-Górecki wrote:
>>> On Thu, Jun 05, 2025 at 04:42:53PM +0200, Jan Beulich wrote:
>>>> Why is it that this ring is dependent upon Xen's position? If the ring was
>>>> dynamically allocated, it wouldn't change position when Xen is moved.
>>>
>>> The console is setup quite early, I don't think I can allocate memory at
>>> this stage, no?
>>
>> But you allocate before Xen is moved, I suppose.
> 
> Well, I have those buffers in BSS exactly to avoid the need to allocate
> them (or rather: have bootloader allocate them for me).

Yet them remaining in .bss is now getting in the way. Imo moving them to
.init.* and adding proper allocation is going to be easier than the hook-
ary you are proposing.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 06:29:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 06:29:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007893.1387059 (Exim 4.92)
	(envelope-from )
	id 1uNQaR-0001WH-Lo; Fri, 06 Jun 2025 06:29:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007893.1387059; Fri, 06 Jun 2025 06:29:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNQaR-0001WA-J7; Fri, 06 Jun 2025 06:29:55 +0000
Received: by outflank-mailman (input) for mailman id 1007893;
 Fri, 06 Jun 2025 06:29: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 1uNQaP-0001W4-Ma
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 06:29:53 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20630.outbound.protection.outlook.com
 [2a01:111:f403:2009::630])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a6c4658a-429f-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 08:29:52 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by MN0PR12MB6367.namprd12.prod.outlook.com (2603:10b6:208:3d3::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.37; Fri, 6 Jun
 2025 06:29:47 +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.8792.034; Fri, 6 Jun 2025
 06:29: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: a6c4658a-429f-11f0-a301-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=xIG+sD265Ce9bwS9m0y9/7Rl+DWEc9yuqeKJegAWpg3MCdNYnYLX/P4IxFkEzOVv1hURz0PQx1dX09DiRn23yR6tYAYM+smZLlzAMemqzKCPTSBMbv7NR+tMmMAr0YaxzkpSOixeI+DjyfbP2C2lzqjMNonnmNEhXzaRrDHi0NvIDCyaI7ZU3SPwfT/6fMcThUp4cr5POYgg/LzmPHOr8wITu+cfiHexO02GxqSN24wre92JI3rTX/g/9d23ImhVQxg+CuN0CCnj3VF9Mh2qHWF9slb6rruLYfwbMxOIHuxZeIICeTymL3mUi0c0KBaJDi7KeqzlZxk8w9Fy03L+gQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=2ODpApV8++fZhni54UUkYqHUI2FmV1s3GyGW/3+zx1s=;
 b=pSsvbbrHDSJfw0NZ3XXep9TgkiePkhklQ5UB3dIwmVh2Yp9nqhS8+0TP4qCFnuW53MBBw0VSXrCvVzzE4ieH0oUvyB6egDI009HUPhJ9GWYRfxLEp6/eUMPSSZVGrMVFBNm3U5kjXTUlEHXGTXtzozyIgBzsLEVfSpVMpASFxewsO+OyqGBd43FbSNvxYjrF6j3PjSMwhLITKhSvov/r8zPZiPObyDivw4bJKTSbL90eeSildipoTZl9nYQeVkwMH6i69IkP/2PPw8xBZQCeX9wsFC4XTiok++kZLkL5lU14A6pL6Yyf4fbivOSehvr9Z7Koyoz8NZFZ4xg9M1jHBA==
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=2ODpApV8++fZhni54UUkYqHUI2FmV1s3GyGW/3+zx1s=;
 b=eHPTA9930s7nzx5fOMY7vGRmz/QrpvLGGDuRTbP9uo3vhfHVG46I95GGNfBOlA3SA7852uvuM6D9Vnc1FFumWXQPg4Z3Wcrk29jxC2XnGL2qptO8Adl7qkWe8FKP7b8KAQNm3fU4m5iTje6xBjQuv07IJrvFkQltHHRzeWTR+Hs=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= 
CC: "xen-devel@lists.xenproject.org" , "Huang,
 Ray" , Andrew Cooper , Anthony
 PERARD , "Orzel, Michal" ,
	Jan Beulich , Julien Grall , Stefano
 Stabellini , "Chen, Jiqian" 
Subject: Re: [PATCH v5 04/10] vpci: Refactor REGISTER_VPCI_INIT
Thread-Topic: [PATCH v5 04/10] vpci: Refactor REGISTER_VPCI_INIT
Thread-Index: AQHbziMOHCuaHG697kCTYWoBETQpzrP0lKSAgAGsWwA=
Date: Fri, 6 Jun 2025 06:29:46 +0000
Message-ID:
 
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
 <20250526094559.140423-5-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.8792.033)
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_|MN0PR12MB6367:EE_
x-ms-office365-filtering-correlation-id: 2beb7f04-e992-4239-51f7-08dda4c3880c
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?ckMxc2Q5S2RBa25GaW8rQUtDTDVpR1Fqd0xCdEg4bUNVVEIyYmdSZ1FTakNy?=
 =?utf-8?B?cVdYYU9ibHNoUkF2bkNNUGpvRmJ1WjVzakhmUjN6ekcwa211SmYxSVdRNW9P?=
 =?utf-8?B?Wk5iVU9SQWQ5WnE1TTdWTW1mL2g3R3p3eWVGeE55b1BhSG9WMHdyQUhVZkUy?=
 =?utf-8?B?cGJJVHhOZHU5VTFuTWFhblBNRldHRCtWaHVSUTRDeGNBOVM1NkN2RnQvNEht?=
 =?utf-8?B?aDh1TW9rWEhVZHlTS3RQZGZBQ0tuY0t0aDArSlpGdkRCdHlGVnRKcmIxQlB0?=
 =?utf-8?B?bjRUQWo4UnZZMzV5amdlR0o5bk5CbldrS3ZuOVlBandPNWthQXNMSTR6NC9o?=
 =?utf-8?B?cGhJWHhiMUJLdTJzUmN6Z2xISU05b1ltTGk4Y3gzcERtSUdsOFd1SmdibmRT?=
 =?utf-8?B?Q21SaHhVaGFpUHk0LzJIOUF1cXRCdGs0QmdDTGJDUGEvZkcvTkZ5ekh6WHI1?=
 =?utf-8?B?SnlwTEhWTFVTbnpwTEtoWHZPSkw3dDFBQVluR1NnTXdwZnl5cnBHR0RqRUVh?=
 =?utf-8?B?ak9vNnBzTTBTZld6R0d2eFg4QXBzaDFDaW9YQTNhNFQyUEkvUzBZK3pjcndm?=
 =?utf-8?B?b1lyUkJtWDFwMUlOeTZXT05CeWtGQWZRcE90RHJHY2RvN2tOd2NyNjNIRjRI?=
 =?utf-8?B?Nm1vR2dMZXc3ZFVabHhqVkMrZkFzRXF5THBjd21RVmQ1VXFnaFo2c1JnMWI5?=
 =?utf-8?B?NFE1UVRBMmdUWHZ3Snk1bDdwc3MrTXFrWHVZTkdML0Zmemo4clN4Qmd2MXJE?=
 =?utf-8?B?OWxjRHpmb09nWG9FclM0YThCbXlJbzFTWWVaOEZrS3FiVWl2NGNyMXV3M3Nu?=
 =?utf-8?B?TUh5OCt1ZXBWQUo4MXJTSEI2WmMrbWdkUjZ0azQ1dGsybFp6bWdGZzVIVTRo?=
 =?utf-8?B?aG5oWm9YNmhuYlhsTFZlQ2JCbHpXOUNCM2s4anZwdldkQ3dvZzJIc1Jwd1J4?=
 =?utf-8?B?T2ZwSHd5V3cyNjJkYllSaHVIU1liTldpTkdRNEQ0MHlFKzJyKyt1V2tGaHVR?=
 =?utf-8?B?RHk5WDR1U0cyL21TemVDVG5HYU1ORUl6RlRMWnhtOTcydlhTVjJnTURDQVZ5?=
 =?utf-8?B?UitsWkhEcEcrYnUrSHkvVjVQaWNZemhReVNKditRRkJ3cVFXNTRDSEdscWVN?=
 =?utf-8?B?VU9GZVkrN3pKK0hwdnBBOWNiWGVOR3dLWStjd0UzcmVOa1FadGhWU1czS0kw?=
 =?utf-8?B?TjcyOTJFaldWc1AvMXhvSFNCdlhla1R1RUlwZGlWaFpMcXdVdGc4bkI2amFH?=
 =?utf-8?B?cmRaNGEwbloxSTlXeFM3V1diTndQZUQ3LzF0Wk00WERMb05UeXV2b2hGcktD?=
 =?utf-8?B?bmhDZXpkd3FTWERBTWRaZDkrdys5ZFNGWmVqWDU0RkdDcE1ueGZOYWpPOEdK?=
 =?utf-8?B?dnl5dmFaV3FrWDRBaFlqUjFMWk1oamtuM3RkdWl2bUJrd2pnWXRYMXI1dW8v?=
 =?utf-8?B?dzQ3RFlhS3RIbWUwZTFvSmNjaXZqMmkwcXZHSnNEUTVEVHkrWVpIQkpjcWFC?=
 =?utf-8?B?LzF0TjJMNnMxdENxZ3RZTzVXd0ZMQlNWdXp2NU5JU0lUR2VIeDhUZHNaeWxU?=
 =?utf-8?B?My9Va01kZFdyT2VVMEh3a0M4RXkxcUVFYVlnb3pmZjRVYndJcWtKbWNhZzk3?=
 =?utf-8?B?SkdxYWRhWUJTOG5DaEVEWm96Q3A4OVZ3UlVtV0RyRlRCQkp1Y0pZc0hLSGxj?=
 =?utf-8?B?V0NtYy9rajRFSG9aZUkvV3Vra1pmd05tNEpwam5uZXVRUUx3bDIxV3hoTm05?=
 =?utf-8?B?THlSZWVxbGJWcjkyUnVWWURvSEpoVUNGMURpNDdWYlN2SUtMcjZPVmJBYzha?=
 =?utf-8?B?dGVwdExvS01IZndiYkFCdlRPbG5PN3hqa09sVjRHUkx1cmRaRWtOMG9WYUpK?=
 =?utf-8?B?WXlmK0g0Mk9MbG9HMjdYU3lHb0pwMlZZRG1wdGhUVkRIN3V0UDBSMkx2WWQx?=
 =?utf-8?B?TW4yZGNmTzY2ZllKRE5sZlY3eC90TmMwQ01qQ0dvRkZaUE9IL0RwYTJjL2xU?=
 =?utf-8?Q?JwmeK6jpctdnKvv8C39mh3imnVriso=3D?=
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?R241VFNnN1ZscEluclU4SlF0NDRuSmdBaHk2NlphVEF1WUM5Y3o5RWFIZmxk?=
 =?utf-8?B?ZFZpc3IydlhpYm5uaDJkdXZKajNLRVIxK1FsbFJqelg1Q1VmWE9QUEs3OGxF?=
 =?utf-8?B?SzBCUWpZb3VRYm1nSUIxM3VQZ1MrOGpIMjJlWHNUSmxEdG1NMzhwZEE1RHVO?=
 =?utf-8?B?TnZsQm9VQjBYeXZqYUVqK3lZUGZaLzVrWm5MMDVZby9MU3FWcHpSaHNseWpQ?=
 =?utf-8?B?Ylh6NVQyN2VTanF4UURoNzB6MmhKRC9tdzUza2l3cjV5OXRmUlBDckdmZkVn?=
 =?utf-8?B?bS9DemVBMzJoWGpXNGRIVzZhMWkxcDlWempDN1JoTUpSNFVHbCtkYVUzV2ZV?=
 =?utf-8?B?UFhXOVVZTzBreGxrdUFqQzRhc0FSMC9ndmhQalNXbGhZRTAvYjBBUUtFaFh1?=
 =?utf-8?B?dkFPK1gzRm53U0dZUzI3UkhxODJqb0dIQlNwMGxrdFkxS3FMOHBtVVAySXE1?=
 =?utf-8?B?OFpydTlWMjlhdnVwbmZ2bTdVZnVjMzVTZWRScmM3ZFB1QWU5UjhoU1dPd2hO?=
 =?utf-8?B?R0tXeGd6UlV1T0dJcFZVQytGejhNNzEzVUdoNERKVmNHL3pkQXJ6SWJvVzlX?=
 =?utf-8?B?ZnFyVm1uYTBlUTBENmd5alZhcU90cTRjYW10SWpmc3d4cEl0bU5TM000Sng2?=
 =?utf-8?B?cHR1Wk5JMmMrOHc5dGNJRXB1TGNHYU5TaW1EblFFMjJGVVdIR1ZjakIvTEtX?=
 =?utf-8?B?bUV3cnN4bWltU21LbGF4RW4zNGxuZHoxbWlZbEMxMlZuTnlhQ0ZqT3N0a0p0?=
 =?utf-8?B?Z2Y0V2tGTEp6eXdMMmEwNlByOVllUHh2RU95Z2U1cXc3amJlZVlQeXdyNGFk?=
 =?utf-8?B?NnlZZ3ZVNnVsbGdISVJ2QTY0eEJqS3Y2M1ZvQWs5enkrNjlzUjhCMjZYNXlT?=
 =?utf-8?B?dmR0NGM1QmxZRVpmZGhOUzlDMk9OK0xPcmM3WEVMZ21MN0o0L1B4cDc1VlJJ?=
 =?utf-8?B?aVBUYmxqdXBMVDllQXZKQVNRcm1ORmpORHpoVUMyY2ZnVjFXazhUcngxeHFH?=
 =?utf-8?B?Ny8rVExlZXUvRWc1dmxJbTJvZzhkaWxWMDE5OC9IUE1JM2JXWmh0ZWZwMHZk?=
 =?utf-8?B?NUpPcytzUERIUjRncEVrOFoxRHovRUVaZ1VieXoxbjducFFQcXAzbXNvdUNh?=
 =?utf-8?B?eW15VHZ6RzRYRTRpVlVqd0JKdmdwYnRtZ3BRY1UzK3FpOHZNZnBMUGE2UWY3?=
 =?utf-8?B?NFpRaUhmVlVQNVlVVFdYUkhvOWYwWDJhQzVHWkxTUGIxY2FTNmhib1BQRk9E?=
 =?utf-8?B?YUgvcGlLZ0hudC9BMGtqOXlQWTQ0c1NUc1BNZjY0amdkTHdLNlByeVh5Q3JW?=
 =?utf-8?B?ZmNuU2xVYk5hTEdJdVhrdlJvTDQxbS84OHFWaHVTLzJ0cGxZQ1d4ejRyRUV1?=
 =?utf-8?B?cGFqc0pCandhVVFaN1gxMkJtTDZYQld1S01JenUwR1hIRzVyajF4ci9CSlhQ?=
 =?utf-8?B?M2I5U0dqWVZrT0xzbHo2S0d2WTA4aEFRQlRTUjlzZlN2MkV1ZG9pL3lGMmZZ?=
 =?utf-8?B?cFpWemFhL1BGUG9lSGE5ejFuWE9VZ1ZzQmpNQWxOK1BjNmRtS2RmT1lwMGhG?=
 =?utf-8?B?cTdsK0ZLc1lLaHlSZlZxbldqZ1hDQUVNU1FmdG0rQ1JTdVF2UVowQ2RwaTdo?=
 =?utf-8?B?aWplM2RmNGNFOGYwVnpzTGlPSE9LbytnOHZ5MnRZWXJ1VktnWVQyckticFZK?=
 =?utf-8?B?VGdkZ1lySzVjMkgybnN2SEFBMFY5OVJ3YS9teTE4cSt2UTdxdjhGMkRDUmNQ?=
 =?utf-8?B?YXNrSzBPV28xNkNHd2tIRHVBeFR5WlBUeks0U0JheTY3bmpBcFZQRWpKOW14?=
 =?utf-8?B?WFYwbk5LTVd2cVM3NGdTYlhyN1loRXdUdFNCQ0xheklUSEg0UnNlY0JJTDZl?=
 =?utf-8?B?blpYaGNYQlRjcENMbm9jZ0I0dlZ0VXlwaVl3MFRlTnN1SkMzc2o4UWV1Yzhj?=
 =?utf-8?B?My9lejhhR2pac0xoVzJveDFtaFdJR2FrQ05SUWxxK3ArVkJqTTFnYTJ4RGZq?=
 =?utf-8?B?V0JMMm43MkRnSkRvTkFsbDkxc2NiMlorMmdVMmVoWkVSVXQ0azljNmdsTzBC?=
 =?utf-8?B?bEFpK0pFYm5SYzJUZzUwYkJPNmttRTFUSWl3ejczSXV0ZC9KU2EwdktQOS80?=
 =?utf-8?Q?r6cg=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <2504BE9D796D954AB58D55EBEFD12728@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: 2beb7f04-e992-4239-51f7-08dda4c3880c
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2025 06:29:46.4310
 (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: LU+OfErI7QsFpnGcTo+jhVe75TKuIfLFpUTBzwXqcVyhJVjEQuorhEy63innDvv111RbEm8doIy1cUEhqXcFhQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6367

T24gMjAyNS82LzUgMjA6NTAsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+IE9uIE1vbiwgTWF5
IDI2LCAyMDI1IGF0IDA1OjQ1OjUzUE0gKzA4MDAsIEppcWlhbiBDaGVuIHdyb3RlOiANCj4+ICsg
IH07IFwNCj4+ICsgIHN0YXRpYyB2cGNpX2NhcGFiaWxpdHlfdCAqY29uc3QgZmluaXQjI19lbnRy
eSAgXA0KPj4gKyAgICAgICAgICAgICAgIF9fdXNlZF9zZWN0aW9uKCIuZGF0YS52cGNpIikgPSAm
ZmluaXQjI190DQo+IA0KPiBJTU8gdGhpcyBzaG91bGQgYmV0dGVyIHVzZSAucm9kYXRhIGluc3Rl
YWQgb2YgLmRhdGEuIA0KSXMgYmVsb3cgY2hhbmdlIGNvcnJlY3Q/DQoNCisgICAgc3RhdGljIGNv
bnN0IHZwY2lfY2FwYWJpbGl0eV90ICpjb25zdCBmaW5pdCMjX2VudHJ5ICBcDQorICAgICAgICBf
X3VzZWRfc2VjdGlvbigiLnJvZGF0YSIpID0gJmZpbml0IyNfdA0KDQo+IE5vdCB0aGF0IGl0IG1h
dHRlcnMgbXVjaCBpbiBwcmFjdGljZSwgYXMgd2UgcGxhY2UgaXQgaW4gLnJvZGF0YSBhbnl3YXku
ICBOb3RlDQo+IGhvd2V2ZXIgeW91IHdpbGwgaGF2ZSB0byBtb3ZlIHRoZSBwbGFjZW1lbnQgb2Yg
dGhlIFZQQ0lfQVJSQVkgaW4gdGhlDQo+IGxpbmtlciBzY3JpcHQgYWhlYWQgb2YgKigucm9kYXRh
LiopLCBvdGhlcndpc2UgdGhhdCBzZWN0aW9uIG1hdGNoIHdpbGwNCj4gY29uc3VtZSB0aGUgdlBD
SSBkYXRhLg0KSSBhbSBzb3JyeSwgaG93IHRvIG1vdmUgaXQgYWhlYWQgb2YgKigucm9kYXRhLiop
ID8NCklzIGJlbG93IGNoYW5nZSBjb3JyZWN0Pw0KDQpkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUv
eGVuL3hlbi5sZHMuaCBiL3hlbi9pbmNsdWRlL3hlbi94ZW4ubGRzLmgNCmluZGV4IDc5M2QwZTEx
NDUwYy4uMzgxNzY0MjEzNWFhIDEwMDY0NA0KLS0tIGEveGVuL2luY2x1ZGUveGVuL3hlbi5sZHMu
aA0KKysrIGIveGVuL2luY2x1ZGUveGVuL3hlbi5sZHMuaA0KQEAgLTE4OCw3ICsxODgsNyBAQA0K
ICNkZWZpbmUgVlBDSV9BUlJBWSAgICAgICAgICAgICAgIFwNCiAgICAgICAgLiA9IEFMSUdOKFBP
SU5URVJfQUxJR04pOyBcDQogICAgICAgIF9fc3RhcnRfdnBjaV9hcnJheSA9IC47ICAgXA0KLSAg
ICAgICAqKFNPUlQoLmRhdGEudnBjaS4qKSkgICAgIFwNCisgICAgICAgKigucm9kYXRhKSAgICAg
ICAgICAgICBcDQogICAgICAgIF9fZW5kX3ZwY2lfYXJyYXkgPSAuOw0KDQo+IA0KPj4gKw0KPj4g
KyNkZWZpbmUgUkVHSVNURVJfVlBDSV9DQVAoY2FwLCBmaW5pdCwgZmNsZWFuKSBcDQo+PiArICAg
ICAgICAgICAgICAgIFJFR0lTVEVSX1BDSV9DQVBBQklMSVRZKGNhcCwgZmluaXQsIGZjbGVhbiwg
ZmFsc2UpDQo+PiArI2RlZmluZSBSRUdJU1RFUl9WUENJX0VYVENBUChjYXAsIGZpbml0LCBmY2xl
YW4pIFwNCj4+ICsgICAgICAgICAgICAgICAgUkVHSVNURVJfUENJX0NBUEFCSUxJVFkoY2FwLCBm
aW5pdCwgZmNsZWFuLCB0cnVlKQ0KPiANCj4gU2luY2UgeW91IGFyZSBtb2RpZnlpbmcgdGhvc2Us
IGNhbiB1c2UgNCBzcGFjZXMgYXMgaW5kZW50YXRpb24/DQo+IFRoZXJlJ3Mgbm8gbmVlZCB0byBo
YXZlIHN1Y2ggcGFkZGluZy4NCj4gDQo+IFRoYW5rcywgUm9nZXIuDQoNCi0tIA0KQmVzdCByZWdh
cmRzLA0KSmlxaWFuIENoZW4uDQo=


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 06:31:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 06:31:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007903.1387070 (Exim 4.92)
	(envelope-from )
	id 1uNQbx-0003CU-4N; Fri, 06 Jun 2025 06:31:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007903.1387070; Fri, 06 Jun 2025 06: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 1uNQbx-0003CN-0g; Fri, 06 Jun 2025 06:31:29 +0000
Received: by outflank-mailman (input) for mailman id 1007903;
 Fri, 06 Jun 2025 06:31: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 1uNQbw-0003C1-8M
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 06:31:28 +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 dfd9be80-429f-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 08:31:27 +0200 (CEST)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-450cf0120cdso16769955e9.2
 for ; Thu, 05 Jun 2025 23:31:27 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3134b127f6esm595828a91.26.2025.06.05.23.31.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 23:31:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: dfd9be80-429f-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749191487; x=1749796287; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=IJ4L3al+6jhMV6LDrCNwkecQvy/feUGeb88f6h/wgwk=;
        b=JHvVtSe/i3tzkVyH/kWG8pTaVSLBLR3pmycibYGLlXmAaxpyWwnt3vErNyA469oQw3
         Rfl0nRA5LzcCQVM82Nr1Tk689go3TTH9a/ADFWwW+9V135fdelRLiY0p7MkW5xJwFODE
         vCheC6kL+d6YSE2yNpUvvBQf4jGon/FIklew3XRwigQkmsxJzsDyBT1Qz2bG5OrTZMIm
         IiZz8iGGDGsg2SdHyoELp9tfZkOwMc8N83ANc8PcgDTVEKMybBo2MNQA4eWRLotqoOTt
         zKiLvfn7t/VqdRst3eWVpmIJnBdPzTIGsaPh1TnJkP1EYkKhYqFk/92XfBC94Q16v8tr
         /Jjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749191487; x=1749796287;
        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=IJ4L3al+6jhMV6LDrCNwkecQvy/feUGeb88f6h/wgwk=;
        b=Hox///Oat5fxL1P6XqUbefy1wU8sYlyFBr50GBMwyPp+wF++b/V2socbLgXgav189Y
         A//TbZCDdSsuxNUnpbLo3Xp5QSSktWr+Dgzdrk/z4zlYd/8jLGhzMQjafmJ7HUwivjz1
         6xUL+JHkCNNfW2btgZPh6CozKCEQ5yBGUyXmZcG3Jr6M4qiXExzdJoZT75r2PqbEn/62
         Uw2xb4DoOVvWOdgn8C5Kcesslz6YeF9EfX4vC34w5iD/vWxm406ElGYoZksKmn8h0D33
         ICOQShtNeLdUO/EENptD/A/UDuSxyor/6MyXk3UmExaE69cG4gTlww6auKh+uC13XyZB
         G7BQ==
X-Forwarded-Encrypted: i=1; AJvYcCWEJXJKTMUTAMbKcHaehV7SxQYGp0axzoc19HysrhBSb46y+ICD6XRDX8vVwhlMIzgxtrcTjLzOBFs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwGJTyFHO1Iq7qa4Cq83265n7CghQPR50kEgPQOYbPiarHziKj3
	LxccHNBGI5LIGRK2QwoFje0ASMmR6TPANVrZGOuyDDgivqWEkOWA9MySqC8+bWcQfQ==
X-Gm-Gg: ASbGncv0Z3hbaepgUgILL/H0XsCDin7rQWA0ySKJvaMCzNjHJP76YqJQZ9dJSEnetpk
	gCuuTynfInUHcjxQlf7h2v9ca1UUc5PTAJGTLx9pqNnRsKfmuvi0hxdOpvayXpsgoHUjAhvP4rR
	x7Jodz2XMPoYh4nY96DvyjjPh3qskTwpE4loh2RzJh8PhwlKbAIqw2tkHPxvO0N2dCwBWEIe09h
	cw2wC5+oj1aSRt77UHy6UuAuelgB4Udm8ljaMu/RosgZmHdrkzq31IPZu1WMXL+Dg1he+S2Fvdc
	gBFVE7nPZ/btBpdj2XrsK8yEcuya3VX4B52x4bimcmNQtxmOBFCNLQgTTk10VrF1EKWdyCAjlS0
	mChhW5xmKkp13iqKZ9sgWVST13573kADC/R8oY9HreyDqnTbVYCmQ/eFujA==
X-Google-Smtp-Source: AGHT+IGW1nMeCN1vPl7+cN5+bc8GgG2aELXo2yNLtPa2evzvyQ7e1On6lPIRON9YXMoFNo6+gGAD1g==
X-Received: by 2002:adf:f147:0:b0:3a4:f661:c3e0 with SMTP id ffacd0b85a97d-3a531ce1495mr1428146f8f.45.1749191486650;
        Thu, 05 Jun 2025 23:31:26 -0700 (PDT)
Message-ID: 
Date: Fri, 6 Jun 2025 08:31:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen: add header guards to generated asm generic headers
To: Stefano Stabellini 
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech,
 michal.orzel@amd.com, julien@xen.org, roger.pau@citrix.com,
 xen-devel@lists.xenproject.org
References: 
 
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.06.2025 02:07, Stefano Stabellini wrote:
> On Thu, 5 Jun 2025, Jan Beulich wrote:
>> On 05.06.2025 01:09, Stefano Stabellini wrote:
>>> --- a/xen/scripts/Makefile.asm-generic
>>> +++ b/xen/scripts/Makefile.asm-generic
>>> @@ -32,7 +32,12 @@ old-headers := $(wildcard $(obj)/*.h)
>>>  unwanted    := $(filter-out $(generic-y) $(generated-y),$(old-headers))
>>>  
>>>  quiet_cmd_wrap = WRAP    $@
>>> -      cmd_wrap = echo "\#include " > $@
>>> +      cmd_wrap = \
>>> +	upper=$$(echo $*.h | tr a-z A-Z | tr '/.' '__'); \
>>> +	printf "\#ifndef ASM_GENERIC_$${upper}\n" > $@; \
>>> +	printf "\#define ASM_GENERIC_$${upper}\n" >> $@; \
>>> +	printf "\#include \n" >> $@; \
>>> +	printf "\#endif /* ASM_GENERIC_$${upper} */\n" >> $@
>>
>> I'm curious: In what is now a0f56da94c3e I had to resort to "define" to
>> get the rule to work (including a correct .*.cmd being generated). I
>> can't claim I actually understood why things didn't work the "simple
>> macro" way, and hence it's unclear to me whether the way it's done here
>> will work with all make versions.
> 
> This works:
> 
> cmd_xlat_h = \
> 	printf "\#ifndef COMPAT_XLAT_H\n" >$@.new; \
> 	printf "\#define COMPAT_XLAT_H\n" >>$@.new; \
> 	cat $(filter %.h,$^) >>$@.new; \
> 	printf "" >>$@.new; \
> 	printf "\#endif /* COMPAT_XLAT_H */\n" >>$@.new; \
> 	mv -f $@.new $@
> 
> I made these changes:
> - tab instead of spaces
> - printf instead of echo
> - escape # and add \n

Hmm, out of these I guess it were the un-escaped #-es then. In your rule
I think the simpler "echo" would also be preferable.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 06:48:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 06:48:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007914.1387079 (Exim 4.92)
	(envelope-from )
	id 1uNQs1-0005C9-Dp; Fri, 06 Jun 2025 06:48:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007914.1387079; Fri, 06 Jun 2025 06:48:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNQs1-0005C2-B7; Fri, 06 Jun 2025 06:48:05 +0000
Received: by outflank-mailman (input) for mailman id 1007914;
 Fri, 06 Jun 2025 06:48: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 1uNQs0-0005Bw-DI
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 06:48:04 +0000
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com
 [2a00:1450:4864:20::431])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 30cedcf0-42a2-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 08:48:02 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a4f379662cso1508309f8f.0
 for ; Thu, 05 Jun 2025 23:48:02 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23603092682sm6057865ad.80.2025.06.05.23.47.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 23:48:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 30cedcf0-42a2-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749192481; x=1749797281; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=O0EeORl8VmtHtnu/aZ+ijH5ixvSHn/MNgR47VfzSOqM=;
        b=T62OfZX+FjFwQmbDk4FYLflgzYegoHdHUvjWLBoeHAb8p/DAQ9Lhe7Ghe0X1wxut0K
         v0a3Hf2zHdbqfZRQoP/vidxOHZoNZKO0Lp3GHiIGbOlxDikfGbUTUMxFfnQ9KXYVdPnv
         LWNVtlr72qgMOyABYXt/V4XAndkzFBHsJ7rWvO6HRNPbA9cuy/b8VvDf/D34+POVL+qT
         IScjVnf/4VCrBzUGifou7r+FQ0nSw1rbI8x7g6QN5NJtO/6Way2+L0+9XDYdhVpG23df
         qDf+T/hfLPqWHpeJSdPCTl1x2Wb1uozGvpi8TUYZ5CeyEN50UO5IE9CbujSojwkctOox
         Jwxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749192481; x=1749797281;
        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=O0EeORl8VmtHtnu/aZ+ijH5ixvSHn/MNgR47VfzSOqM=;
        b=FvEpINF6tqhL9O03mbcKIdpWh0JMWfTBtVbQ9XYpaZfm7TVau3LJmE8ovjPQMSGCkw
         xrArX2JFhDkDdWijeQWj4PcoBkETV3t3fVcYeeW/LlN8ObIG5k2Ov1pgyTbl3xJTcV0g
         thOLlxN7hTTR0+xaP0RV5eGR8GV28Cxic7+jOc81bkcwnGNyrNHSzXHaIP+Nlj4pUIlx
         VTxwovQC9/yV/VbBc9Cd12tn3PdhOTAXmug0FsSqwj5SFARl1pwm+XuGYRkZmRQppOEA
         fo8fGjaonc/4DwwO/vdBeHj/xzbkwdLW88Hh5kASez/qHMXGrKiSqXShBud9KtP+/28q
         Us5w==
X-Forwarded-Encrypted: i=1; AJvYcCWt4k7Ns1Q/7u2tCJ1VjXkaMb7D0F4btzh1HCtyuN35lcqSRka2i4RuvKO9tTECm3/AkDUQWv7Jk/o=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwhMoxilTsdMJrY9rrqV3VSs4wzml+EHTQVDepWlWc6UIyTe1mP
	CGWg0X9F8ii+a0+sjhqbCJxp3FBLvjLvEbB4mz4RZ/QaQabaf3s6l47EdEpPO11N2Q==
X-Gm-Gg: ASbGncvBOLVb183lpPVrDwrMpG9C9iGXq9VWeBm4WRzQFeByzjjZlmNc7i5q9LARWEO
	81WBTsDvJ7Oepjln9thy059EUwLFZSsn7XuwBU494gt8Ow0m9aelUnj+2gYQDfrDcHbd/tbUUiq
	6Jsw+ff+I1niiHcFp9PkM7gXsIYJiOH/vnIaMN4ApfVHZbOJ3Jc0kQGZRiDoG9Kl/6bsiFUus9/
	6P5MvoGqlpIB4msKCklXQe3IMOv5I0C+FjsTqz5ncC0PaKh1HZNp7et+S8hminGkEbzflPvWimI
	5vwM1rp4mm/2QUXGInOBFl6nxl5s1fTzEKsGKhi2bkdr7fShDCsQgDXVQH41wZ0IHoZl6dXmFnt
	YOIaDZ7kCo4i/JMt7MzGgKAhCWosLFo3kLGt5
X-Google-Smtp-Source: AGHT+IGTVXcX9qKrevZdmJmZufmwiqDx2/wkT+dO2FzgZu0IAmZHNpyr8IsAdbqWgtzrr+DLz4C0yA==
X-Received: by 2002:a05:6000:250f:b0:3a4:e7b7:3851 with SMTP id ffacd0b85a97d-3a531cf3622mr1648166f8f.58.1749192481423;
        Thu, 05 Jun 2025 23:48:01 -0700 (PDT)
Message-ID: <2e579f10-3a9d-4f78-8963-f2fdd448a636@suse.com>
Date: Fri, 6 Jun 2025 08:47:50 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/3] xen/keyhandler: add missing noreturn attribute
To: Stefano Stabellini 
Cc: Nicola Vetrini , victorm.lira@amd.com,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?B?Um9nZXIgUGF1IE1vbm7Dg8Kp?= ,
 Federico Serafini ,
 Bertrand Marquis , xen-devel@lists.xenproject.org
References: <20250604235034.1595881-1-victorm.lira@amd.com>
 <9e3a7b1b-7fbe-428b-888a-c18c95d8ee37@suse.com>
 
 <3b24b1df1a0ce4a62b53067b09fe9a02@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 06.06.2025 02:09, Stefano Stabellini wrote:
> On Thu, 5 Jun 2025, Jan Beulich wrote:
>> On 05.06.2025 14:26, Nicola Vetrini wrote:
>>> On 2025-06-05 14:22, Nicola Vetrini wrote:
>>>> On 2025-06-05 09:17, Jan Beulich wrote:
>>>>> On 05.06.2025 01:49, victorm.lira@amd.com wrote:
>>>>>> From: Nicola Vetrini 
>>>>>>
>>>>>> Function `reboot_machine' does not return, but lacks the `noreturn' 
>>>>>> attribute,
>>>>>> therefore causing a violation of MISRA C Rule 2.1: "A project shall 
>>>>>> not contain
>>>>>> unreachable code".
>>>>>
>>>>> Is this (uniformly) true? Looking at ...
>>>>>
>>>>>> --- a/xen/common/keyhandler.c
>>>>>> +++ b/xen/common/keyhandler.c
>>>>>> @@ -251,7 +251,7 @@ static void cf_check 
>>>>>> dump_hwdom_registers(unsigned char key)
>>>>>>      }
>>>>>>  }
>>>>>>
>>>>>> -static void cf_check reboot_machine(unsigned char key, bool unused)
>>>>>> +static void noreturn cf_check reboot_machine(unsigned char key, bool 
>>>>>> unused)
>>>>>>  {
>>>>>>      printk("'%c' pressed -> rebooting machine\n", key);
>>>>>>      machine_restart(0);
>>>>>
>>>>> ... generated code here, I can see that the compiler is perfectly able 
>>>>> to
>>>>> leverage the noreturn that machine_restart() has, resulting in no
>>>>> unreachable code to be generated. That is - neither in source nor in
>>>>> binary there is any unreachable code. Therefore I'm having a hard time
>>>>> seeing what the violation is here.
>>>>>
>>>>> That said, I certainly don't mind the addition of the (seemingly) 
>>>>> missing
>>>>> attribute. Otoh I wonder whether an attribute the removal of which has 
>>>>> no
>>>>> effect wouldn't count as "dead code" or alike, violating some other 
>>>>> rule.
>>>>>
>>>>
>>>> Inlining does not play a role in this case. Here reboot_machine() is 
>>>> marked as a violation because machine_restart() is noreturn and there 
>>>> is no other path upon which reboot_machine() may return, hence any 
>>>> function calling reboot_machine() could have portions that are 
>>>> inadvertently unreachable (as in never executed due to divergence) by 
>>>> not having the annotation.
>>
>> Just that there's not going to be a 2nd caller, considering the purpose
>> of the function.
>>
>>>> That said, in such trivial cases compilers 
>>>> are typically able to derive the property automatically, but they are 
>>>> not obliged to and, more importantly, the behavior may even differ with 
>>>> the same compiler using different optimization levels.
>>>
>>> Just a note: in later revisions of MISRA C this has become a rule of its 
>>> own [1], which helps reduce confusion, but up to MISRA C:2012 Amendment 
>>> 2 (currently used by Xen), this is part of Rule 2.1.
>>>
>>> [1] Rule 17.11: "A function that never returns should be declared with a 
>>> _Noreturn function specifier"
>>
>> Oh, that's indeed quite a bit more explicit.
> 
> Does it mean you would ack the patch? :-)

With an improved description I may at least no longer object to it.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 06:51:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 06:51:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007920.1387090 (Exim 4.92)
	(envelope-from )
	id 1uNQv6-0006tB-Sf; Fri, 06 Jun 2025 06:51:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007920.1387090; Fri, 06 Jun 2025 06:51: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 1uNQv6-0006t4-Or; Fri, 06 Jun 2025 06:51:16 +0000
Received: by outflank-mailman (input) for mailman id 1007920;
 Fri, 06 Jun 2025 06:51: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 1uNQv5-0006sx-4t
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 06:51:15 +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 a2c2ff6f-42a2-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 08:51:13 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3a376ba6f08so1029123f8f.1
 for ; Thu, 05 Jun 2025 23:51:13 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-236030780f4sm6166245ad.51.2025.06.05.23.51.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 23:51:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a2c2ff6f-42a2-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749192673; x=1749797473; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=lM+ixva8RNUICoRA6RVAaDbs6O4yD/Fhumlo8hSYTfA=;
        b=Oiy3sOmNL7WNxxxqKOjE/ZBbASqI+sEldnlrKjXIgvm7PMrOP2k+YAzCfB6ONQXX5g
         jhDzQXKlyAodpUsnKdauDMZtfuuBc5mQgHDvN8yMz4w8U/DH6faVb1sPHIhcDOHpWL3b
         nSw8ZofmdIDVOttsFAeeWvYbbF0PRrOS2QPvbfrY05U2hlgQNw1CVkacmPLfqb+bqjr4
         uWvvFPpcBzIUEb7wSfI9IafVf7Gi6kk0kLiFDWm7nNWUJtWodLJwF2CFCx1BgBV3zzNV
         61c3MUTrd9OuJ/Z+/s457Wa+eJ/3CV4AHEbPyicygv3ayVkQ1icYvxkA6u5lfgM9uhMA
         DhGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749192673; x=1749797473;
        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=lM+ixva8RNUICoRA6RVAaDbs6O4yD/Fhumlo8hSYTfA=;
        b=sNto3eHaJ4aCePP3eD+GuySdgq73onQz05uAzsXeBqUpCEfT9DraFxoNJ/epGiLbOW
         vsIK3YqR5CSjUPkUkngQpBO+yen8W8ddztguG43w/1nAptfW4AvGapMrJC3m/fz+H4ul
         V4UPOo4H4kXHq2DkGzZA7KLWCM83mv4G5UG/xfNHZ1gWta+IfddIFyo5TZiI+3rxzX4O
         9UIManP3N70O6ozhysugxWc7dGzx90h6hLNNTRHFiISW3QBiAoPqRM3O4siumZ2H6Xr0
         58L4HoAeeQjxGEu3QPIusXr0RhxnUZODe8SffEBHQ6oUmiI3JA3YHEDQoVDVfprhUYtH
         R4rw==
X-Forwarded-Encrypted: i=1; AJvYcCX5Jiy1/CKM6sfBBYflzEUBos5Z2hKDy77qfFUlDXB3a5NZ9U4xs0eps4k/ulZTYc+10mePAbmnEhM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyxpMSm/T0G2jUQD84PWJmpoN8iCehjd1j3oh38tpLdGXW2y2l9
	anQBJRyRqFAKn2WBTg9AKU9nHhgd6b57HlW2VtsGyh6pMaI/VkMHmNP3G3MDnKrkvg==
X-Gm-Gg: ASbGncvlTenPlNA5n8uIsuVAS9rKBkbeMeomzyETXuKodTowtLUDutaZbTuX7d8nNrg
	sCqMn4v8qAH4GSho42DCrkj8DiGX5L+Xl0bL12KvBeManAk/XxNaDzjXylEz0BXjbKRhl7pKtiQ
	Gq/WT2iARb5s/i8zdEQku9tOT6tVMe4fyO/Y9Q2TYXdmmHTRrILhGIWf73sc1bXVwhHiJn9cOMi
	TQBqQeeQrq3p1rt+2x4in9x0krCO8VQM6U+e3iR0RVrbd37KfVY8jEfuNXpyT2CgDEouskbkYeJ
	IEI+Hunudo8inZbWZFJaHs2BnpfUcjHH2q69xzo2DLCwYMAsG9ct1NmRcS9KQLCF9DMsHxEMIWB
	Kw5ChrVAXzzQ3gcOwcHVDpxWs6lNJzESNncHbEAE8DGsiHtQ=
X-Google-Smtp-Source: AGHT+IGUFBFFUWfOiRsXf7z52Y74JvrWfpNC2dyqAAnm0XW6dEMcEmFSYcaByG9rKsZQPNP5CqsFzA==
X-Received: by 2002:a5d:4dcd:0:b0:3a4:fefb:c8d3 with SMTP id ffacd0b85a97d-3a5319a7a59mr1533197f8f.40.1749192672737;
        Thu, 05 Jun 2025 23:51:12 -0700 (PDT)
Message-ID: <38104467-fb7e-4aa3-9c78-0f9bf23183eb@suse.com>
Date: Fri, 6 Jun 2025 08:51:01 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 01/15] xen: Clean up asm-generic/device.h
To: Alejandro Vallejo 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Oleksii Kurochko ,
 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: <20250605194810.2782031-1-agarciav@amd.com>
 <20250605194810.2782031-2-agarciav@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: <20250605194810.2782031-2-agarciav@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 05.06.2025 21:47, Alejandro Vallejo wrote:
> --- a/xen/include/asm-generic/device.h
> +++ b/xen/include/asm-generic/device.h
> @@ -1,14 +1,20 @@
>  /* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * This header helps DTB-based architectures abstract away where a particular
> + * device came from, be it the DTB itself or enumerated on a PCI bus.
> + */
>  #ifndef __ASM_GENERIC_DEVICE_H__
>  #define __ASM_GENERIC_DEVICE_H__
>  
> +#ifndef CONFIG_HAS_DEVICE_TREE
> +#error "Header for exclusive use of DTB-based architectures"
> +#endif
> +
>  #include 
>  
>  enum device_type
>  {
> -#ifdef CONFIG_HAS_DEVICE_TREE
>      DEV_DT,
> -#endif
>      DEV_PCI
>  };

My objection to these changes remains; as a generic header it ought to be what
that attribute says - generic.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 06:53:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 06:53:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007925.1387100 (Exim 4.92)
	(envelope-from )
	id 1uNQwl-0007Oo-6g; Fri, 06 Jun 2025 06:52:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007925.1387100; Fri, 06 Jun 2025 06:52: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 1uNQwl-0007Oh-3s; Fri, 06 Jun 2025 06:52:59 +0000
Received: by outflank-mailman (input) for mailman id 1007925;
 Fri, 06 Jun 2025 06:52: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 1uNQwj-0007Ob-BW
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 06:52:57 +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 dfacd3a4-42a2-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 08:52:55 +0200 (CEST)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-3a4e742dc97so1823152f8f.0
 for ; Thu, 05 Jun 2025 23:52:55 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b2f5ee851efsm637547a12.31.2025.06.05.23.52.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 23:52:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: dfacd3a4-42a2-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749192775; x=1749797575; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=LzB4mRNnbhI6ZmujJOdTcsEs2mXKlzNBii3rirIvmBQ=;
        b=EUxA2uihhtkRZE6dC/GaRs9EL01CKvgNBwqtp+b/g+nup0RgqpsKyGbflADAJp2i17
         GMZ1ooJQJTp9HvJvbicy3irn/YeHZit30O0JtpoGWrLgq2mP+SJtGGCLF7mvOtCSFY/E
         xxe+MhxwMFVgAB/BnzYFqBv5+2m9MAakZVVXw3XhufDS7eButYG8UYMrrvqSvWPCw/vN
         Ux35R4JotwIDZZyFOEurBvhlc/sDhBGbd/t9/vY7vP0TYHwim/LWaTlgrU5niArMZCRQ
         m59fJi0yMggKClJ0QmdqH41XKhS+VN0ABIuYFe36Zu4fdTqvkGtry6GpGYnUkhv72lH5
         P94Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749192775; x=1749797575;
        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=LzB4mRNnbhI6ZmujJOdTcsEs2mXKlzNBii3rirIvmBQ=;
        b=CAeDtXQUZMmpV9lHKNqQN3h2FeKOpdd5589UzaRscvjPHi3WKtA8D7QKTYRNXRjrjD
         T1cFRnMdrqfBhq/z8QBCU/x9Tdv6NT9It97CvwhhAXD6OFAZPfTAhH4CJLHYEUf2SnPb
         prqgJOy5uosSjgEQHJEiw5O520F94bCWLQoTOoimEp9xGv2bfHLmNu2KZyZzaBX2Ayoh
         CvBlcKw+gIChd58+dttGMpybeRv9pz1KRS7lhl0XEJSFHp4lZqrLzyy3lM3iGYjmM8Ix
         DX00GQZxuAo1SRM07YXnv05kK830Asze3QPufahoJfs8rLSk4+EpPY+8Sq07ozSLcjxY
         8uhw==
X-Forwarded-Encrypted: i=1; AJvYcCWQ8T0htH74FnTpJ7hVyDDroRn/t//y2Ie2ZrLBUxzk5pmK9qjpJ2Kgy/x7HVyS3YaT76YRTQNVTdQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxiQZLAck+BUKXmw1RRF77TMfLwFbyh9lpfErzk3BVFCxgPRAyy
	oZxXVV6hXaSs4S+O7WEVv9tJJLUWJeIW9da7ZTfMiap0FLVA/P5SVqwOlroNv2PNZg==
X-Gm-Gg: ASbGncvbkRqOFZEBYac5gnGdxHE+CRbgmafwd78RQ3sqKTConT619tjvyuI5IgiuBpS
	SrLw6UYiWs9FSaZMv1aYM0EcyBkkPfdODjFZNz6BU2rGKm/vaW0s9DkD7NVKak4K3wSiLx7h0Ig
	cWRy+gSAq4ZwBbtg2Hy6yjZHcr5bkbN/FGG5l0YW/qQspc/sKAi0KY5k+K7HErtkUyf8E93usWs
	ghd79cOnr7Z3nc4M5bMYd0u25MpmL72F5ctoNdKcJOdr8F/9flK0/9pwezeKXdMsagM6bNgVLwi
	JJXABMRWJOqdYurLdc0id7XyqIWjU1A/kyxm3OmIahEmbwpxpFYWFWhZqpvGBGMUebfvJgPuFzF
	A0A4iVUAQVIi8g1zz1ahAdxjq7l0NjOaxafip
X-Google-Smtp-Source: AGHT+IGBT04TaFXGugovn+YgV+0OEbaWut9dvnScLYuUZrXQBZfvGyePLInN+TJL3zzivCUm+ockzA==
X-Received: by 2002:adf:a405:0:b0:3a5:2b1e:c49b with SMTP id ffacd0b85a97d-3a52b1ec589mr3496494f8f.29.1749192774838;
        Thu, 05 Jun 2025 23:52:54 -0700 (PDT)
Message-ID: <765d42ec-a421-4b8c-80bd-30c909e81e8d@suse.com>
Date: Fri, 6 Jun 2025 08:52:44 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 02/15] arm/gnttab: Break links between
 asm/grant_table.h and xen/grant_table.h
To: Alejandro Vallejo 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org
References: <20250605194810.2782031-1-agarciav@amd.com>
 <20250605194810.2782031-3-agarciav@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: <20250605194810.2782031-3-agarciav@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 05.06.2025 21:47, Alejandro Vallejo wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -42,8 +42,10 @@
>  #include 
>  #include 
>  #include 
> +
>  #include 
>  #include 
> +#include 
>  
>  #ifdef CONFIG_PV_SHIM
>  #include 
> --- a/xen/include/xen/grant_table.h
> +++ b/xen/include/xen/grant_table.h
> @@ -27,10 +27,6 @@
>  #include 
>  #include 
>  
> -#ifdef CONFIG_GRANT_TABLE
> -#include 
> -#endif
> -
>  struct grant_table;
>  
>  /* Seed a gnttab entry for Hyperlaunch/dom0less. */

The description doesn't make clear why these two files need changing.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 06:55:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 06:55:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007935.1387110 (Exim 4.92)
	(envelope-from )
	id 1uNQzK-00081t-MR; Fri, 06 Jun 2025 06:55:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007935.1387110; Fri, 06 Jun 2025 06:55: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 1uNQzK-00081m-JG; Fri, 06 Jun 2025 06:55:38 +0000
Received: by outflank-mailman (input) for mailman id 1007935;
 Fri, 06 Jun 2025 06:55: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 1uNQzI-00081f-FA
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 06:55:37 +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 3e34ee37-42a3-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 08:55:34 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3e34ee37-42a3-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1749192932; x=1749452132;
	bh=iVWTtAlXZPIUCCqlJJu2YtHiSgf61XcJ9kO3TkASNDM=;
	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=X3aurnJYW+no1NmCfR4YkujfThakW7ktJm3DD3uimajCMiqZlJ5EazO7Yfj4d/XmB
	 5uvH98h3w43dyFIO0MjbZ9CFVIdxDiKc7d9khFgHgsR4d4jwpSnh4xWb1iXASv7pxl
	 tSFRU8SB0B3ASl2hIN4V9bCLsGtgqq/eTA0qOLvO5274O5nZ/fgxDQ8OhHIXApeHFS
	 6F+uTAEWETmZ0VqPICKcgD5lbiiEEV3qpr/ERRJC3Fcgu/xKH8eEvw/jiz+8GNSfza
	 /eXpOk3GP7c8f51kFrrJzn7li6PlG3/N4aF38w4QQ7r8yVWi5NQQN5hPzUF17AtjtM
	 CNg+gzoRFWzsA==
Date: Fri, 06 Jun 2025 06:55:26 +0000
To: Julien Grall 
From: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com
Subject: Re: [PATCH v9 1/3] xen/domain: unify domain ID allocation
Message-ID: 
In-Reply-To: 
References: <20250528225030.2652166-1-dmukhin@ford.com> <20250528225030.2652166-2-dmukhin@ford.com> 
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 60c800d892fe51859f77e4f018191c785f9565ed
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 05, 2025 at 10:58:48PM +0100, Julien Grall wrote:
> Hi Denis,
>=20
> On 28/05/2025 23:50, dmkhn@proton.me wrote:
> > From: Denis Mukhin 
> >
> > From: Denis Mukhin 
> >
> > Currently, hypervisor code has two different domain ID allocation
> > implementations:
> >
> >    (a) Sequential IDs allocation in dom0less Arm code based on max_init=
_domid;
> >
> >    (b) Sequential IDs allocation in XEN_DOMCTL_createdomain; does not u=
se
> >        max_init_domid (both Arm and x86).
> >
> > The domain ID allocation covers dom0 or late hwdom, predefined domains,
> > post-boot domains, excluding Xen system domains (domid >=3D
> > DOMID_FIRST_RESERVED).
> >
> > It makes sense to have a common helper code for such task across archit=
ectures
> > (Arm and x86) and between dom0less / toolstack domU allocation.
> >
> > Wrap the domain ID allocation as an arch-independent function domid_all=
oc() in
> > common/domain.c based on the bitmap.
> >
> > Allocation algorithm:
> > - If an explicit domain ID is provided, verify its availability and use=
 it if
> >    ID is not used;
> > - If DOMID_INVALID is provided, search the range [0..DOMID_FIRST_RESERV=
ED-1],
> >    starting from the last used ID and wrapping around as needed. It gua=
rantees
> >    that two consecutive calls will never return the same ID. ID#0 is ex=
cluded
> >    to account for late hwdom case.
> >
> > Also, remove is_free_domid() helper as it is not needed now.
> >
> > No functional change intended.
> >
> > Signed-off-by: Denis Mukhin 
> > ---
> > Changes since v8:
> > - skip ID #0 in domid_alloc() to account for late hwdom
> > ---
> >   xen/arch/arm/domain_build.c             | 17 +++++---
> >   xen/arch/x86/setup.c                    | 11 +++--
> >   xen/common/device-tree/dom0less-build.c | 10 +++--
> >   xen/common/domain.c                     | 54 ++++++++++++++++++++++++=
+
> >   xen/common/domctl.c                     | 42 +++----------------
> >   xen/include/xen/domain.h                |  3 ++
> >   6 files changed, 87 insertions(+), 50 deletions(-)
> >
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index b189a7cfae..e9d563c269 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -2010,6 +2010,7 @@ void __init create_dom0(void)
> >           .grant_opts =3D XEN_DOMCTL_GRANT_version(opt_gnttab_max_versi=
on),
> >       };
> >       unsigned int flags =3D CDF_privileged | CDF_hardware;
> > +    domid_t domid;
> >       int rc;
> >
> >       /* The vGIC for DOM0 is exactly emulating the hardware GIC */
> > @@ -2034,19 +2035,25 @@ void __init create_dom0(void)
> >       if ( !llc_coloring_enabled )
> >           flags |=3D CDF_directmap;
> >
> > -    dom0 =3D domain_create(0, &dom0_cfg, flags);
> > +    domid =3D domid_alloc(0);
> > +    if ( domid =3D=3D DOMID_INVALID )
> > +        panic("Error allocating domain ID 0\n");
> > +
> > +    dom0 =3D domain_create(domid, &dom0_cfg, flags);
> >       if ( IS_ERR(dom0) )
> > -        panic("Error creating domain 0 (rc =3D %ld)\n", PTR_ERR(dom0))=
;
> > +        panic("Error creating domain %d (rc =3D %ld)\n", domid, PTR_ER=
R(dom0));
>=20
> The change in the panic here and below seems unrelated to the goal of
> the patch. I am ok to keep them here, but I think it should be mentioned
> in the commit message.

Will do.

>=20
> >
> >       if ( llc_coloring_enabled && (rc =3D dom0_set_llc_colors(dom0)) )
> > -        panic("Error initializing LLC coloring for domain 0 (rc =3D %d=
)\n", rc);
> > +        panic("Error initializing LLC coloring for domain %pd (rc =3D =
%d)\n",
> > +              dom0, rc);
> >
> >       if ( alloc_dom0_vcpu0(dom0) =3D=3D NULL )
> > -        panic("Error creating domain 0 vcpu0\n");
> > +        panic("Error creating domain %pdv0\n", dom0);
> >
> >       rc =3D construct_dom0(dom0);
> >       if ( rc )
> > -        panic("Could not set up DOM0 guest OS (rc =3D %d)\n", rc);
> > +        panic("Could not set up guest OS for domain %pd (rc =3D %d)\n"=
,
> > +              dom0, rc);
> >
> >       set_xs_domain(dom0);
> >   }
> > diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> > index 1f5cb67bd0..b36ce4491b 100644
> > --- a/xen/arch/x86/setup.c
> > +++ b/xen/arch/x86/setup.c
> > @@ -1031,8 +1031,11 @@ static struct domain *__init create_dom0(struct =
boot_info *bi)
> >       if ( iommu_enabled )
> >           dom0_cfg.flags |=3D XEN_DOMCTL_CDF_iommu;
> >
> > -    /* Create initial domain.  Not d0 for pvshim. */
> > -    bd->domid =3D get_initial_domain_id();
> > +    /* Allocate initial domain ID. Not d0 for pvshim. */
>=20
> NIT: The two spaces were valid here. This is in fact quite common to
> unambiguously mark the end of a sentence.

Yep, I changed the text in comment and forgot to keep the double space.

>=20
> > +    bd->domid =3D domid_alloc(get_initial_domain_id());
> > +    if ( bd->domid =3D=3D DOMID_INVALID )
> > +        panic("Error allocating domain ID %d\n", get_initial_domain_id=
());
> > +
> >       d =3D domain_create(bd->domid, &dom0_cfg,
> >                         pv_shim ? 0 : CDF_privileged | CDF_hardware);
> >       if ( IS_ERR(d) )
> > @@ -1064,7 +1067,7 @@ static struct domain *__init create_dom0(struct b=
oot_info *bi)
> >
> >           if ( (strlen(acpi_param) =3D=3D 0) && acpi_disabled )
> >           {
> > -            printk("ACPI is disabled, notifying Domain 0 (acpi=3Doff)\=
n");
> > +            printk("ACPI is disabled, notifying domain %pd (acpi=3Doff=
)\n", d);
> >               safe_strcpy(acpi_param, "off");
> >           }
> >
> > @@ -1079,7 +1082,7 @@ static struct domain *__init create_dom0(struct b=
oot_info *bi)
> >
> >       bd->d =3D d;
> >       if ( construct_dom0(bd) !=3D 0 )
> > -        panic("Could not construct domain 0\n");
> > +        panic("Could not construct domain %pd\n", d);
> >
> >       bd->cmdline =3D NULL;
> >       xfree(cmdline);
> > diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/devic=
e-tree/dom0less-build.c
> > index 39cb2cd5c7..a509f8fecd 100644
> > --- a/xen/common/device-tree/dom0less-build.c
> > +++ b/xen/common/device-tree/dom0less-build.c
> > @@ -850,15 +850,13 @@ void __init create_domUs(void)
> >           struct xen_domctl_createdomain d_cfg =3D {0};
> >           unsigned int flags =3D 0U;
> >           bool has_dtb =3D false;
> > +        domid_t domid;
> >           uint32_t val;
> >           int rc;
> >
> >           if ( !dt_device_is_compatible(node, "xen,domain") )
> >               continue;
> >
> > -        if ( (max_init_domid + 1) >=3D DOMID_FIRST_RESERVED )
>=20
> I can't find a similar check in domid_alloc(). But if the value is
> unlikely above DOMID_FIRST_RESERVED, then we would end up to allocate a
> random domid.

Yes, thanks.
I think I need to add tools/tests with a self-test for the domain ID alloca=
tion
code.

>=20
> > -            panic("No more domain IDs available\n");
> > -
>  >           d_cfg.max_evtchn_port =3D 1023;>
> d_cfg.max_grant_frames =3D -1;
> >           d_cfg.max_maptrack_frames =3D -1;
> > @@ -981,7 +979,11 @@ void __init create_domUs(void)
> >            * very important to use the pre-increment operator to call
> >            * domain_create() with a domid > 0. (domid =3D=3D 0 is reser=
ved for Dom0)
> >            */
> > -        d =3D domain_create(++max_init_domid, &d_cfg, flags);
> > +        domid =3D domid_alloc(++max_init_domid);
>=20
> In the commit message you wrote:
>=20
>=20
> """
>      (b) Sequential IDs allocation in XEN_DOMCTL_createdomain; does not u=
se
>          max_init_domid (both Arm and x86).
> """
>=20
> I read it as max_init_domid should have been moved to common code. I see
> this is done in the next patch. So I would suggest to clarify this will
> be handled separately.

Will do.

>=20
>=20
> > +        if ( domid =3D=3D DOMID_INVALID )
> > +            panic("Error allocating ID for domain %s\n", dt_node_name(=
node));
> > +
> > +        d =3D domain_create(domid, &d_cfg, flags);
> >           if ( IS_ERR(d) )
> >               panic("Error creating domain %s (rc =3D %ld)\n",
> >                     dt_node_name(node), PTR_ERR(d));
> > diff --git a/xen/common/domain.c b/xen/common/domain.c
> > index abf1969e60..ae0c44fcbb 100644
> > --- a/xen/common/domain.c
> > +++ b/xen/common/domain.c
> > @@ -66,6 +66,10 @@ DEFINE_RCU_READ_LOCK(domlist_read_lock);
> >   static struct domain *domain_hash[DOMAIN_HASH_SIZE];
> >   struct domain *domain_list;
> >
> > +/* Non-system domain ID allocator. */
> > +static DEFINE_SPINLOCK(domid_lock);
> > +static DECLARE_BITMAP(domid_bitmap, DOMID_FIRST_RESERVED);
> > +
> >   /*
> >    * 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.
> > @@ -1449,6 +1453,8 @@ void domain_destroy(struct domain *d)
> >
> >       TRACE_TIME(TRC_DOM0_DOM_REM, d->domain_id);
> >
> > +    domid_free(d->domain_id);
> > +
> >       /* Remove from the domlist/hash. */
> >       domlist_remove(d);
> >
> > @@ -2405,6 +2411,54 @@ domid_t get_initial_domain_id(void)
> >       return hardware_domid;
> >   }
> >
> > +domid_t domid_alloc(domid_t domid)
> > +{
> > +    spin_lock(&domid_lock);
> > +
> > +    if ( domid < DOMID_FIRST_RESERVED )
> > +    {
> > +        if ( __test_and_set_bit(domid, domid_bitmap) )
> > +            domid =3D DOMID_INVALID;
> > +    }
> > +    else
> > +    {
> > +        static domid_t domid_last;
> > +        /* NB: account for late hwdom case, skip ID#0 */
>=20
> I am somewhat confused with this comment. For the late hwdom case, I
> thought we were using a non-zero ID. Dom0 should also always be the
> first dom0 to be reserved. Can you clarify?

My current understanding is:
- the ID of "domain 0" (privileged domain) can be overridden at the boot-ti=
me
  via hardware_domid parameter.

- there's only one reserved (and configurable) domain ID =3D=3D hardware_do=
mid in
  the allocation range (which is 0 by default).

- get_initial_domain_id() returns the reserved domain ID value (which is
  used in the in the follow on change to keep the change isolated).

Is my understanding correct?

I will update the comment.

>=20
> That said, if you want to skip to dom0. Wouldn't it be better to have
> domid_last set to 1 and then ...
>=20
>  > +        const domid_t reserved_domid =3D 0;> +        const bool
> reserved =3D __test_and_set_bit(reserved_domid, domid_bitmap);
> > +
> > +        domid =3D find_next_zero_bit(domid_bitmap, DOMID_FIRST_RESERVE=
D,
> > +                                   domid_last);
> > +
> > +        if ( domid =3D=3D DOMID_FIRST_RESERVED )
> > +            domid =3D find_next_zero_bit(domid_bitmap, DOMID_FIRST_RES=
ERVED, 0);
>=20
> ... use 1 here? This would avoid to temporarily mark the domid 0 as
> reserved.
>=20
> Cheers,
>=20
> --
> Julien Grall
>=20
>=20



From xen-devel-bounces@lists.xenproject.org Fri Jun 06 06:56:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 06:56:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007941.1387119 (Exim 4.92)
	(envelope-from )
	id 1uNR08-0008V9-Ub; Fri, 06 Jun 2025 06:56:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007941.1387119; Fri, 06 Jun 2025 06:56:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNR08-0008V2-RT; Fri, 06 Jun 2025 06:56:28 +0000
Received: by outflank-mailman (input) for mailman id 1007941;
 Fri, 06 Jun 2025 06:56: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 1uNR08-00081f-7Y
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 06:56:28 +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 5d8a954b-42a3-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 08:56:26 +0200 (CEST)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-450cf0120cdso16931965e9.2
 for ; Thu, 05 Jun 2025 23:56:26 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3134b13ba47sm635844a91.40.2025.06.05.23.56.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 05 Jun 2025 23:56:25 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5d8a954b-42a3-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749192986; x=1749797786; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=42e5ZGOtOGSOXXptCVVuYFxeFbUysynhGiyilV+BZkE=;
        b=ZtGJSRHQMdhRAbQSlp4Uf8XXxLPbf4qZjB+aLxTG/BAxaZh1QTIQRi4oo01QB7/NiX
         Iuk51VTqQjXzN0DxR4KR+gAo0ZLJcd0Twjruov19A/X9OOV0glkrdNAd6JA1nG1F+qUi
         uQl9e68WHYD1LwncTlMiVRkM1SWAKtvWR/Fa05LpvnOeqjqXQmHOCc+9gfKajkgMmd0e
         j7oH4N79FQnat5njdfpxbe+xhB16G1d/U+sdm2EA4InX86Zq47kbx44bFKHrQMJX9gtz
         ey6ZQ6sjh95gg0pvgBxbcmZA1BKVkdBK22tAvHCYZWKGC89QDlaLcIPV0Ruc3TH/gEB8
         R3Ug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749192986; x=1749797786;
        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=42e5ZGOtOGSOXXptCVVuYFxeFbUysynhGiyilV+BZkE=;
        b=QdDEcB7B4f3vfKdavdlIZzeafPD9J7q1G8aATklf6nvtJlzvo0q8Wl8I4gzenXZLlJ
         Meyj0YTXvgrQcG2ZrsmR4frktWlhpJtcVhpa4tKKIYaOLYc3jieerk0j0iPypMnHx3+0
         lso3oENbd6MvZNcqX54Ahx+ayAq7SdS8Wour3yhNVHOJvfrJNFw4JBqxlwazvGRE9sQy
         xGFBXKMqNblBi1JLI98OyIT3Q3jmeTaWG4bjH+Sb6ilr4XD7/Mqrr0qjcaLICsy5M4/i
         qCcqyvxGB2c4psbuvl6uH7hMbAuel6+C/7p2Ar/Ryyz1c53xqE2zPiU8MGY6FFezNoTm
         ZjqA==
X-Forwarded-Encrypted: i=1; AJvYcCXG+57eFg1Ly0jrPNmj8MZ40lOs1qzAk4scbHj/wcuKUH9PCLuK1uxMTUf4XOEt3XwA9TcM5fiF7d8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxhB60hI62LxgbT2D8MjpeOX+ey+hC8MrWfRToY0mxbaaWxvivZ
	29HkhLQJewJfGMkh8k688mYY+Dsf+efiomnPHxHtjhL8mTVecPMOKrDtP8MJUAkzuQ==
X-Gm-Gg: ASbGncsc9COim2Xx/dJH4odMHZ24s+Z6PRkjc0H69HT3bN4Ml0wcfpS3iqSRUjuCM2v
	CGoELSgtidtp8K+G2jsWrKFujEUJ1zB+w+C3NalXwUgg8QVH/yygIUiFXmK6RF2mPdM//7PPxJE
	Vo6y6ZjxsOb94LjtRZYC7kGJNsVN0t6rtJS2e7NTkED935g2QeeSxSX5pVlBdo1aLveZWnh5e+s
	/TspaYFPf26fwyvMGrlUjA5Il5+hP64NeVZWFsy1bH5DvsAkE7LbRVhQhT9lIc6hF16J6b3KFkc
	5tzeTgQGaUccx+s6lV0EUKP0VTmDiCffWl7iJKPp51Qa6qUmjdsMEj5v60FMcVcbcWdvHbUjGRG
	N8c0EEC0/bsqVQz6xBr+CP7NE0Q52+igPTE6K1IKdIGHO/vs=
X-Google-Smtp-Source: AGHT+IECLLRbhY8X5pS6svFkV7sqMOJz0VhKRUuItsE4WO2h+iCgE37iGHnpx9c55uXmZHPuPcuqcQ==
X-Received: by 2002:a5d:5f4f:0:b0:3a4:f41d:696e with SMTP id ffacd0b85a97d-3a531cb3b6amr1926884f8f.27.1749192986042;
        Thu, 05 Jun 2025 23:56:26 -0700 (PDT)
Message-ID: <6490abdd-ac7c-4178-a174-25d13065ae04@suse.com>
Date: Fri, 6 Jun 2025 08:56:16 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 10/19] x86: Replace boot_module with bootmodule
To: Alejandro Vallejo 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 "Daniel P. Smith" ,
 Andrew Cooper , xen-devel@lists.xenproject.org
References: 
 <20250530120242.39398-1-agarciav@amd.com>
 <20250530120242.39398-11-agarciav@amd.com>
 <214c8863-5cd4-4be9-948e-e44b67f541bd@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 05.06.2025 19:40, Alejandro Vallejo wrote:
> On Thu Jun 5, 2025 at 7:28 PM CEST, Alejandro Vallejo wrote:
>> On Mon Jun 2, 2025 at 7:00 PM CEST, Andrew Cooper wrote:
>>> On 30/05/2025 1:02 pm, Alejandro Vallejo wrote:
>>>> These types resemble each other very closely in layout and intent, and
>>>> with "struct bootmodule" already in common code it makes perfect sense
>>>> to merge them. In order to do so, add an arch-specific area for
>>>> x86-specific tidbits.
>>>>
>>>> Signed-off-by: Alejandro Vallejo 
>>>
>>> Yet this is a distinct backwards step in terms of legibility.
>>>
>>> How about modifying the common code to be more legible, rather than
>>> regressing the x86 code.
>>>
>>> ~Andrew
>>
>> I meant to ifdef out the fields unused on x86, but after some massaging I
>> think I got it lookin much nicer. It's essentially using the common parts of
>> kernel_info and boot_domain as a header to kernel_info.
>>
>> That way, x86 keeps using a substantially smaller (yet common) data structure
>> while the rest of dom0less can keep using the original as-is.
>>
>> Refactoring kernel_info to rationalise its contents is somewhere in my TODO
>> list, but I have much more urgent fish to fry first.
>>
>> Cheers,
>> Alejandro
> 
> ... I misread the comment and thought it was in the following patch rather than this one.
> 
> If it was indeed intended here, I'm at a loss as to what you'd rather do.
> Common bindings need a common ground. This is such ground. The data structures
> are virtually identical and used for identical purposes.
> 
> What's the legibility step you're talking about?

The loss of the underscore (separating the words) in the struct tag, aiui.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 06:59:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 06:59:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007948.1387130 (Exim 4.92)
	(envelope-from )
	id 1uNR3I-0000eM-C5; Fri, 06 Jun 2025 06:59:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007948.1387130; Fri, 06 Jun 2025 06:59: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 1uNR3I-0000eF-9W; Fri, 06 Jun 2025 06:59:44 +0000
Received: by outflank-mailman (input) for mailman id 1007948;
 Fri, 06 Jun 2025 06:59: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 1uNR3H-0000e9-3S
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 06:59:43 +0000
Received: from mail-10631.protonmail.ch (mail-10631.protonmail.ch
 [79.135.106.31]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d13a7422-42a3-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 08:59:40 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d13a7422-42a3-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1749193179; x=1749452379;
	bh=yrBq7J3abC+2OEi32nZd7QSjmZdO+4cFXKHZuZxtBLc=;
	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=a8T6TF588a2ZnhxpEScnjeVD2kuoAYuIzVPC7VxZ7diPn+wIDWNYOsVd7k3SmETwe
	 2KDsZMiLe8C/Ng18Ngq6DnBGGFJvNToemawoY40bNjXjCmnUukkMQs7i0GTmXLQ96H
	 5dUYQlG9jGFkhYRLfM78xLTUZDipsywvxOFX1BXm/bmOV6h0vKvxEydtKfaiZHOlO1
	 OBiVBR5BCa+D/CVMnxtj/fXTKjAMlv33kf4D4EDG9yxTtB3bnUQ5nDphyWLCurLpBN
	 /lYSRCVB+LS84lUaLt3y8sNrEe/8xlbHPBtTgl979kJAvm+CBju2J32ljOwVyEE2rq
	 txhF5HarB2hKA==
Date: Fri, 06 Jun 2025 06:59:34 +0000
To: Jan Beulich 
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v5 3/4] xen/console: remove max_init_domid dependency
Message-ID: 
In-Reply-To: 
References: <20250530231841.73386-1-dmukhin@ford.com> <20250530231841.73386-4-dmukhin@ford.com> 
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 91d1e15326ea1fc77aa2080c4ab4b00bf6c94818
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 04, 2025 at 02:55:40PM +0200, Jan Beulich wrote:
> On 31.05.2025 01:19, dmkhn@proton.me wrote:
> > --- a/xen/common/domain.c
> > +++ b/xen/common/domain.c
> > @@ -2461,6 +2461,39 @@ void domid_free(domid_t domid)
> >      spin_unlock(&domid_lock);
> >  }
> >
> > +/*
> > + * Find the ID of the next possible console owner domain.
> > + *
> > + * @return Domain ID: DOMID_XEN or non-system domain IDs within
> > + * the range of [0..DOMID_FIRST_RESERVED-1].
> > + */
> > +domid_t domid_find_with_input_allowed(domid_t hint)
> > +{
> > +    domid_t domid =3D DOMID_XEN;
> > +
> > +    if ( hint < DOMID_FIRST_RESERVED )
> > +    {
> > +        struct domain *d;
> > +
> > +        rcu_read_lock(&domlist_read_lock);
> > +
> > +        for ( d =3D domid_to_domain(hint);
>=20
> If the domain with ID "hint" went away, what is being switched to changes
> compared to behavior prior to this patch, if I'm not mistaken. While this
> _may_ be acceptable, not saying so in the description is imo a no-go.

Will correct, thanks.

>=20
> > +              d && get_domain(d) && d->domain_id < DOMID_FIRST_RESERVE=
D;
>=20
> What's the DOMID_FIRST_RESERVED check for? And where's the put_domain()
> for the get_domain() here?
>=20
> > +              d =3D rcu_dereference(d->next_in_list) )
> > +        {
> > +            if ( d->console.input_allowed )
> > +            {
> > +                domid =3D d->domain_id;
> > +                break;
> > +            }
> > +        }
> > +
> > +        rcu_read_unlock(&domlist_read_lock);
> > +    }
> > +
> > +    return domid;
> > +}
>=20
> My concern remains: With many domains, the loop here may take quite a few
> iterations. That's even more concerning because it regresses right away i=
n
> environments where along with boot-time created domains (eligible for
> console focus) later further domains are created (non of which are eligib=
le
> for console focus). That is, the step from last boot-time created back to
> DOMID_XEN may now take excessively long.

Julien in the other reply suggested to have a list of domains with console
input permission only. Will rework.

>=20
> Jan



From xen-devel-bounces@lists.xenproject.org Fri Jun 06 07:03:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 07:03:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007954.1387139 (Exim 4.92)
	(envelope-from )
	id 1uNR6b-0002Qh-Pz; Fri, 06 Jun 2025 07:03:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007954.1387139; Fri, 06 Jun 2025 07:03:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNR6b-0002Qa-NM; Fri, 06 Jun 2025 07:03:09 +0000
Received: by outflank-mailman (input) for mailman id 1007954;
 Fri, 06 Jun 2025 07:03: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 1uNR6Z-0002QP-QE
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 07:03:08 +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 4b0a0725-42a4-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 09:03:05 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by DS2PR12MB9615.namprd12.prod.outlook.com (2603:10b6:8:275::18) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.35; Fri, 6 Jun
 2025 07:03:02 +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.8792.034; Fri, 6 Jun 2025
 07:03: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: 4b0a0725-42a4-11f0-a301-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=IGqsFduzVEpQ0t089xMgsSVcwi8YAnEH7bglD0lxCimXpg03QeyBL/6Mt4cLijCbL4FTHUYPPbPhF58mk/S3SFn/wp4/ZiQhAi3S0N4+uybuvIpAnCLjFN9hVZqRQkOzQai304ZB/YzmzWE/f44sYXQX4EqyTGTf1FYD5K22PqaUNvwnG0LIfvj2VuwekbHDEXS3mtiAygolALUrwtOzbQR0kMZAsuXeCZw62385XvS8N9ha4r7lT/o3RqOpjsvkZz2xtegna67y3Xja9jU9FVmplvqiThCkhmbODAkia4yVUy+iTXDp3nODtnyLLAWxGDszNQyrRIO2+NF8Zrpshg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=19dzd/s09cZpzHnREnq1VC1mq30cTkWtlbdS6Ypikpw=;
 b=d1t+/iCPC7kxIQxNDKJgDqFbIXYF57YBo5qw8fbsiC51N7pRzCKVBvGFv6OPcJSNVv6jcFJmTiXeti8Fvz0YuW/Ic9D0jGbCoZ7J/ai2dmrqb5TJKFLw/sS10XYaKxCjwialAsrMYwu1pZNW+LIHjGrdpWZdXW54bjK7P6ULbBm62FuF82B/UJG8BmbJNlODZLzkJ2nG5i0uPU9M2p+YpN1eh5cj/rp56m8+dZjv100xB7dOHPa9DLxBQO4EwWYzShYBV0L0Zf0106sImedK3ViDMNGjj8Z4y9gCQD/EFA6YEeJQXwmGsOaU0JLDFpGl68aE5/Fn0Fk+g6iRxlsIeQ==
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=19dzd/s09cZpzHnREnq1VC1mq30cTkWtlbdS6Ypikpw=;
 b=5I0QfUHlH/xWMM+oVUSi8bUt3N+DpNH6ROujcZ94I7XQFDa8tEdtMJ888YZPg9O3Sn5vqYBekpHJ1nHSkxCL909/odgaReHR5n7hSV7D4jifnklcFHHWSEbuZbeLUgUCMDdaLPgG6VhD7/gGfIWZsfsj1tq3xCJuQNyAZzME6HE=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= 
CC: "xen-devel@lists.xenproject.org" , "Huang,
 Ray" , "Chen, Jiqian" 
Subject: Re: [PATCH v5 05/10] vpci: Hide legacy capability when it fails to
 initialize
Thread-Topic: [PATCH v5 05/10] vpci: Hide legacy capability when it fails to
 initialize
Thread-Index: AQHbziMO3mNxygxpLk+KcCvN8aYRhbP0oTMAgAGqEgA=
Date: Fri, 6 Jun 2025 07:03:02 +0000
Message-ID:
 
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
 <20250526094559.140423-6-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.8792.033)
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_|DS2PR12MB9615:EE_
x-ms-office365-filtering-correlation-id: ea981e23-2550-4027-7410-08dda4c82d88
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?VVFJM3djRHovb3F4bSttMjhVMnVqL0RvUzlUTmRrUm5DbEJDTWdFTGpsOTdY?=
 =?utf-8?B?TkhBVGprWDFwWWxwVkxtVHdkNFk5dU5PZVFpK3VtWU1GL3NDeGYyNE51d3Ar?=
 =?utf-8?B?aHo1WDJiUHpld2JZOEl2NTFYbklpRFdUeG9Jb3hKQWFuTEllZ3ZyQTgrZ1Bi?=
 =?utf-8?B?clVOSkhSQ3hnMmsydU44OEt1WDdMUks1OXVGb2tjNjNwZXBiOGNhZ0p2WDVv?=
 =?utf-8?B?TkxtTURiWU9QVk1RZDJCZUxDbmpKZW1UTWNhdmlBSzM5ZzYzOS8wUlFTRmE0?=
 =?utf-8?B?ZEZqSjFjYnFJSHNXemF1am9SeDA3dnFCWWxacWMwNVRyYkJGM0JwaE9tQzFR?=
 =?utf-8?B?M2FBV09pOExaNlp1Y1hYS3JSVWUwRm93dUtsNlk2QTZ4aFI1b0hxVFhjd3Ey?=
 =?utf-8?B?NkxQakdJRWdBS09QOWQ4VW10VHFKUEpaam5MUU52QUt2SFU0cTFQR0IvR3Vx?=
 =?utf-8?B?WHRxYnBCSHFqZkpXTU5QWGpqbGJPTmJVd0pESktGU0Vhc0ZxbFVuU1VCQkFO?=
 =?utf-8?B?bkZhZlIvTExHcmtKekwxQmlWSC9SeU9qRlJudmVhaHduZzAyQy9oRUJ0QmNS?=
 =?utf-8?B?QlBJME5FL0dmcmxQK0dYcDVtZlZVOHVGaVRER3VqN1BlQjMrRTQ2aUZsYVQ2?=
 =?utf-8?B?YXhIK0F0MkZlZE82OUd4NVFYTEpia2NSWmFzYlp1ZmJaa0s5YUk0QUNUT3dz?=
 =?utf-8?B?RDRhL0cyeit2SmpTQjNKNldWT2Zma3BDbEVPWnR1ZllHOVg5dDZydmxNak5K?=
 =?utf-8?B?bG4wT1hJUmNtVTM3R1FrcmYxOUpTcytGQ25HcVY0VlBNSU1IZE0yQkZ6Ukgz?=
 =?utf-8?B?VjJGbjRRSEh0ZG42VDE1TE50V0hzSERNSFNpaWNGRm5WM2IzOVZJeG96eVBX?=
 =?utf-8?B?MEVESFkzZWIweWRESVBJZVNGZWNad3pTTGluWkYrQytrdkxXNXpYcko4TDBV?=
 =?utf-8?B?TlRWd3lTdjNub0I1WjREZk5peFp1dzF3L2hZVVc5QnJMK2E1d0xKMnRPdVpw?=
 =?utf-8?B?OTVXS2c0NmYwdmJOMkVzeU14dit0N1ZRbFhsVEcraHZLbWliQ3hlbCtNR2Vu?=
 =?utf-8?B?SThDV2tLZVJvZTU3OWdXZXZlbzRqUkUzTC8wYTJXSm92MFIwNWx5RTUyRHds?=
 =?utf-8?B?cTlsNzdhR3V1bEFtZ2hqdVFPU3dPRTE2VHNKUUpJdG5mRkZqTnk2eFB5endI?=
 =?utf-8?B?Q3VvUkdCL3dIOFc2dThCT3g0Nng1Y001OXNFQ1V4d0UzS2FUU3JiS3JVekxx?=
 =?utf-8?B?OUVnTTYya3J6RlhqcW1yelhuM1ZkczdBcSsyVHlqK1d2UVhTWFJveitGYzlN?=
 =?utf-8?B?ZFZXSUtrdW8rMGZvTmMxSUVXUDlmSUFqL2wzZHFTU3lkU3VIZG5PZWdvcnE3?=
 =?utf-8?B?b081UktURGxDWjhhekp4cXRlVkFoZjl1K1FOUU9sRnlKWndleC9rTDd3NkJn?=
 =?utf-8?B?enVtV201d0hsRDltSlNSZFBBajdhOXZ5U29QK203VlFjMm5yRnZDc2ZRallI?=
 =?utf-8?B?d1l6TGpPdk1jV09RblFrRVNUNjlPQUozV2tWcHA4MUZRQ1cwV0ZqTXlRZjl4?=
 =?utf-8?B?Z0VpTDBydU9SaXpNNllMQ285dHdxa0tNRUkvY3hMNExKVnFPUEMwaEIrQ0dC?=
 =?utf-8?B?RE1pbDNiU2lnNCtBaytVSllGYklyaFlSUGYxczJtL3MxcXpxNU03bGljS3Fi?=
 =?utf-8?B?TnR3eC9Oc08vTjNrdi8yUEZRSncxTzFCWUYvREFOZkFLT2R2Sms4U0tjMmxz?=
 =?utf-8?B?eHpnVEJwdG1EUEFUa1pKRGcrNFJjSnZVWkQ5emphTUZTTFZZOFRheE5yYy90?=
 =?utf-8?B?QmsvQnJOM3B1ekZGajBzSnFGR1V5aU9tL093RkNmdWhFVHg5d2NVUkJsc2JJ?=
 =?utf-8?B?WnpLMTZ6OTdieVpIRWM0K3JVYkZHVWFKTElrblpoSkJsdTlQNVJjTmh2eDlG?=
 =?utf-8?B?eHRNVFc1UWZ6SGdhb3M0Qk5EYVlmS1VGWTIvQTJ6SHd6aFNZNTVCVjkvR2ho?=
 =?utf-8?Q?krWyVIHXFcjUHlCStRSOtOiPNdpuGs=3D?=
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?VmRocFdleUVzbEZZTGhKaW1IRXp3blNsbmF2d1FyWCtNb0FDNUFiczZCZnpD?=
 =?utf-8?B?Q0xFb080NkduMjBBQjNKQlRMcDFCdFZHWHk0eGw5RmdEY1hIVkI3Tncwaktr?=
 =?utf-8?B?STJZa2lQYUpucmhFb0ZCZkNwNjluLzdkK1psOGZ0OTFPNlE3eFVNNU1pbllq?=
 =?utf-8?B?MDJtLzNURGxNdWtjSDhtd3AyZzBBQ0lyVGJIRm1wbk1oUXBFbmFta2hSM0xj?=
 =?utf-8?B?bG9VdTBPL2srUUlsd1Fmc2NWZnhpTFZXZzdpUUJ5aVJXZnlKbWphOFZhajVE?=
 =?utf-8?B?WnRRYk5zdTNvdHIzZk5ndGZLelgyNi9hN1FTWldiZ3NIY0huZlU4VU9INEJ6?=
 =?utf-8?B?blNqcTZnT2M5VmhnMk0vRWZUYjJ2bG9Jbk8zS2E0ZHJrNXF6V2psT1huWmxu?=
 =?utf-8?B?TXdBMy84OHJ4MWlQZ2s1QjRBODRhM3VjMnRXRkJaZEJpYnVKZGNQN21PVzBG?=
 =?utf-8?B?RFFTVjFqUWN1S2dIcEFPVUNsNWhrcmxCd0RhL1lmZlM1U0E2YVlxK0w2T3lP?=
 =?utf-8?B?c09LNDdaY25XWnZ1QzNISVlrd3J2UDZkUGNENlAvbHJROHVyRlFFN1BiM1I1?=
 =?utf-8?B?ZVNUSzMwYTQ4QkdrRytqSng3RXhBbzkvQmVnRWdPUm1SL1NSMWk3Y1o2T2xJ?=
 =?utf-8?B?a3ZPM09ueWtFSW1LWnZENU1wL3hCRURxZkFsVWxNaTk4MG9XeGdzczRvR3VE?=
 =?utf-8?B?Qk9IdnRObTRlVW11bkJIc0VKQmRzSDFFMEpPK0NGOHNOVmlOSERnQ0s2VzR5?=
 =?utf-8?B?N2kyNkpjbjVzbE9FMlpjVHViSi9GYjZtUUJpT21wUEF0TGR0bHlNRFpwdGhj?=
 =?utf-8?B?amt0ZlU5WkxjWHpMcS9sTVRjMVpSaGc2T0ZseEp2d3gyVSt3NmdBRnMxQmdT?=
 =?utf-8?B?OG9VaVZUZGJLMmdSY09ScEFDWDNvenVWWjMwRldEeUNXY2F2OHIrY0NRZHlr?=
 =?utf-8?B?MW5ZZ01QNDdtZnBBT1FDd01QeElxdmlzbjdOS1dmd2hZeHBBczJwUnpReGFP?=
 =?utf-8?B?OFZYVVVQNGI5bWNqYTFibEtjN2Nnb0xYV24wQTVSYjhVL1JXZk5WeWMwMko0?=
 =?utf-8?B?SnA1WlJTbzMrZ0I5c1ZDOCtxVGdIL1p2NnovQlVYcUtkcXlNenJxeUpXbkFa?=
 =?utf-8?B?MjJxSVIyYkNCVFh6MW5iTzRUM05UOU83UGpyNkpMR1JuM3I4Sk9INnMwQUVw?=
 =?utf-8?B?cWhSR1RjTGI0c0FKN084L2Q1WjZMajNhRmhndnBmbi83eVE4WDNiTFZVeXho?=
 =?utf-8?B?RTNzN3FYSFFNMFdvaVdBdVlKaWYvZjBpbWFNSHg0WFViQ0thWExTVjNHeGJF?=
 =?utf-8?B?MG1GUmczMUxibGVGeVB5OFZEdWhmQU85MmE2VnZVejg2NUxBOVdpWXhPZFlq?=
 =?utf-8?B?aWJMQUFoamRuTXpidUZJRllPd0NPWFAvZGEwWCtlTUhjMXZjSXpzZ044ZWZW?=
 =?utf-8?B?UExNNEZxdVh3MEhrTDNnNHF6Zlp0WC9sUlFFNTBjTml6L1ZtRVhJZ3dVRHpr?=
 =?utf-8?B?WThzZTEydjAzcS9jNkxZdHppWS83OXpMUUtsZnJEeVpCS2E0UndCdkIxandl?=
 =?utf-8?B?UzJlWHhSeEJ0cEFKekE4enhFanNHbXhKL0JRR0ZROGo1Z1AvNE5neTI5Y1Fp?=
 =?utf-8?B?TXJmYlJtNWxIeHlBU3BtYXA0UnZ0cnFzWmZ4RitJcThIZ1c4cDRWVk1GTE5a?=
 =?utf-8?B?Q0JsZXNGbEtuc2xpTDYxWmJRMDAyL0REOEtBWnhBN3ZWanlNOEFzS05ZVlhK?=
 =?utf-8?B?bFArUDZIOXJCTWdsdThRekI4UFNLLzNsaHRmMExDQW1Cby9FNVIvWjUybUdm?=
 =?utf-8?B?V1lnNWpSdlhMOVpQazR1dHF1S2xBMk5rd0s1OVd2ZE1sa2JWU3VwbDJsbnY4?=
 =?utf-8?B?bEJoeGVmVm5POGpKQ2tlbGZmcmtUb3Iyb1hoM2JGSklxK1dsUVFsY2R5OThS?=
 =?utf-8?B?MVZ2UHcxcDlBWk9lYy9wNXFxbUQ2VGxKQUUrNlNiWDZnS052UkszOThubGZr?=
 =?utf-8?B?b0RnYmNBQkVCNlV3ZXV5d3M5ek91T2FGUTFsWmpBWThBc0RwSHplL1RDb0o4?=
 =?utf-8?B?Zm94Z2dQYllPRnYyeVQxVWoxS3hHWDJ0Uml5RWx5OUFIRFFNejZ1ekhNZWU3?=
 =?utf-8?Q?TQDA=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <81C12B50AB0D8D43928177DAEF4F7268@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: ea981e23-2550-4027-7410-08dda4c82d88
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2025 07:03:02.0473
 (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: fH3ctnjJCF07xbFFIf4XsmJAM5+JlHUHEnm1LY1L5s8/A50YZBH+E7AVdYC7Um+1wSVNLLHkYGQOk/67Y/UH2A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS2PR12MB9615

T24gMjAyNS82LzUgMjE6MzUsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+IE9uIE1vbiwgTWF5
IDI2LCAyMDI1IGF0IDA1OjQ1OjU0UE0gKzA4MDAsIEppcWlhbiBDaGVuIHdyb3RlOg0KPj4gV2hl
biB2cGNpIGZhaWxzIHRvIGluaXRpYWxpemUgYSBsZWdhY3kgY2FwYWJpbGl0eSBvZiBkZXZpY2Us
IGl0IGp1c3QNCj4+IHJldHVybnMgYW4gZXJyb3IgYW5kIHZQQ0kgZ2V0cyBkaXNhYmxlZCBmb3Ig
dGhlIHdob2xlIGRldmljZS4gIFRoYXQNCj4+IG1vc3QgbGlrZWx5IHJlbmRlcnMgdGhlIGRldmlj
ZSB1bnVzYWJsZSwgcGx1cyBwb3NzaWJseSBjYXVzaW5nIGlzc3Vlcw0KPj4gdG8gWGVuIGl0c2Vs
ZiBpZiBndWVzdCBhdHRlbXB0cyB0byBwcm9ncmFtIHRoZSBuYXRpdmUgTVNJIG9yIE1TSS1YDQo+
PiBjYXBhYmlsaXRpZXMgaWYgcHJlc2VudC4NCj4+DQo+PiBTbywgYWRkIG5ldyBmdW5jdGlvbiB0
byBoaWRlIGxlZ2FjeSBjYXBhYmlsaXR5IHdoZW4gaW5pdGlhbGl6YXRpb24NCj4+IGZhaWxzLiBB
bmQgcmVtb3ZlIHRoZSBmYWlsZWQgbGVnYWN5IGNhcGFiaWxpdHkgZnJvbSB0aGUgdnBjaSBlbXVs
YXRlZA0KPj4gbGVnYWN5IGNhcGFiaWxpdHkgbGlzdC4NCj4+DQo+PiBTaWduZWQtb2ZmLWJ5OiBK
aXFpYW4gQ2hlbiA8SmlxaWFuLkNoZW5AYW1kLmNvbT4NCj4+IC0tLQ0KPj4gY2M6ICJSb2dlciBQ
YXUgTW9ubsOpIiA8cm9nZXIucGF1QGNpdHJpeC5jb20+DQo+PiAtLS0NCj4+IHY0LT52NSBjaGFu
Z2VzOg0KPj4gKiBNb2RpZnkgdnBjaV9nZXRfcmVnaXN0ZXIoKSB0byBkZWxldGUgc29tZSB1bm5l
Y2Vzc2FyeSBjaGVjaywgc28gdGhhdCBJIGRvbid0IG5lZWQgdG8gbW92ZSBmdW5jdGlvbiB2cGNp
X3JlZ2lzdGVyX2NtcCgpLg0KPj4gKiBSZW5hbWUgdnBjaV9jYXBhYmlsaXR5X21hc2soKSB0byB2
cGNpX2NhcGFiaWxpdHlfaGlkZSgpLg0KPj4NCj4+IHYzLT52NCBjaGFuZ2VzOg0KPj4gKiBNb2Rp
ZnkgdGhlIGNvbW1pdCBtZXNzYWdlLg0KPj4gKiBJbiBmdW5jdGlvbiB2cGNpX2dldF9wcmV2aW91
c19jYXBfcmVnaXN0ZXIoKSwgYWRkIGFuIEFTU0VSVF9VTlJFQUNIQUJMRSgpIGlmIG9mZnNldCBi
ZWxvdyAweDQwLg0KPj4gKiBNb2RpZnkgdnBjaV9jYXBhYmlsaXR5X21hc2soKSB0byByZXR1cm4g
ZXJyb3IgaW5zdGVhZCBvZiB1c2luZyBBU1NFUlQuDQo+PiAqIFVzZSB2cGNpX3JlbW92ZV9yZWdp
c3RlciB0byByZW1vdmUgUENJX0NBUF9MSVNUX0lEIHJlZ2lzdGVyIGluc3RlYWQgb2Ygb3BlbiBj
b2RlLg0KPj4gKiBBZGQgY2hlY2sgImlmICggIW9mZnNldCApIiBpbiB2cGNpX2NhcGFiaWxpdHlf
bWFzaygpLg0KPj4NCj4+IHYyLT52MyBjaGFuZ2VzOg0KPj4gKiBTZXBhcmF0ZWQgZnJvbSB0aGUg
bGFzdCB2ZXJzaW9uIHBhdGNoICJ2cGNpOiBIaWRlIGNhcGFiaWxpdHkgd2hlbiBpdCBmYWlscyB0
byBpbml0aWFsaXplIg0KPj4gKiBXaG9sZSBpbXBsZW1lbnRhdGlvbiBjaGFuZ2VkIGJlY2F1c2Ug
bGFzdCB2ZXJzaW9uIGlzIHdyb25nLg0KPj4gICBUaGlzIHZlcnNpb24gYWRkcyBhIG5ldyBoZWxw
ZXIgZnVuY3Rpb24gdnBjaV9nZXRfcmVnaXN0ZXIoKSBhbmQgdXNlcyBpdCB0byBnZXQNCj4+ICAg
dGFyZ2V0IGhhbmRsZXIgYW5kIHByZXZpb3VzIGhhbmRsZXIgZnJvbSB2cGNpLT5oYW5kbGVycywg
dGhlbiByZW1vdmUgdGhlIHRhcmdldC4NCj4+DQo+PiB2MS0+djIgY2hhbmdlczoNCj4+ICogUmVt
b3ZlZCB0aGUgInByaW9yaXRpZXMiIG9mIGluaXRpYWxpemluZyBjYXBhYmlsaXRpZXMgc2luY2Ug
aXQgaXNuJ3QgdXNlZCBhbnltb3JlLg0KPj4gKiBBZGRlZCBuZXcgZnVuY3Rpb24gdnBjaV9jYXBh
YmlsaXR5X21hc2soKSBhbmQgdnBjaV9leHRfY2FwYWJpbGl0eV9tYXNrKCkgdG8NCj4+ICAgcmVt
b3ZlIGZhaWxlZCBjYXBhYmlsaXR5IGZyb20gbGlzdC4NCj4+ICogQ2FsbGVkIHZwY2lfbWFrZV9t
c2l4X2hvbGUoKSBpbiB0aGUgZW5kIG9mIGluaXRfbXNpeCgpLg0KPj4NCj4+IEJlc3QgcmVnYXJk
cywNCj4+IEppcWlhbiBDaGVuLg0KPj4gLS0tDQo+PiAgeGVuL2RyaXZlcnMvdnBjaS92cGNpLmMg
fCAxMTcgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKystLQ0KPj4gIDEgZmls
ZSBjaGFuZ2VkLCAxMTMgaW5zZXJ0aW9ucygrKSwgNCBkZWxldGlvbnMoLSkNCj4+DQo+PiBkaWZm
IC0tZ2l0IGEveGVuL2RyaXZlcnMvdnBjaS92cGNpLmMgYi94ZW4vZHJpdmVycy92cGNpL3ZwY2ku
Yw0KPj4gaW5kZXggMjg2MTU1N2UwNmQyLi42MGU3NjU0ZWMzNzcgMTAwNjQ0DQo+PiAtLS0gYS94
ZW4vZHJpdmVycy92cGNpL3ZwY2kuYw0KPj4gKysrIGIveGVuL2RyaXZlcnMvdnBjaS92cGNpLmMN
Cj4+IEBAIC04Myw2ICs4Myw5OSBAQCBzdGF0aWMgaW50IGFzc2lnbl92aXJ0dWFsX3NiZGYoc3Ry
dWN0IHBjaV9kZXYgKnBkZXYpDQo+PiAgDQo+PiAgI2VuZGlmIC8qIENPTkZJR19IQVNfVlBDSV9H
VUVTVF9TVVBQT1JUICovDQo+PiAgDQo+PiArc3RhdGljIHN0cnVjdCB2cGNpX3JlZ2lzdGVyICp2
cGNpX2dldF9yZWdpc3RlcihzdHJ1Y3QgdnBjaSAqdnBjaSwNCj4+ICsgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVuc2lnbmVkIGludCBvZmZzZXQsDQo+PiAr
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBp
bnQgc2l6ZSkNCj4+ICt7DQo+PiArICAgIHN0cnVjdCB2cGNpX3JlZ2lzdGVyICpybTsNCj4gDQo+
IE5pdDogSSB0aGluayB5b3UgcmUtdXNlZCBwYXJ0IG9mIHRoZSBjb2RlIGZyb20gdnBjaV9yZW1v
dmVfcmVnaXN0ZXIoKQ0KPiB0aGF0IG5hbWVzIHRoZSBsb2NhbCB2YXJpYWJsZSBybSAoYmVjYXVz
ZSBpdCdzIGZvciByZW1vdmFsKS4gIEhlcmUgaXQNCj4gd291bGQgYmV0dGVyIHRvIGp1c3QgbmFt
ZSBpdCAncicgKGZvciByZWdpc3RlcikuDQpXaWxsIGNoYW5nZS4NCj4gDQo+PiArDQo+PiArICAg
IEFTU0VSVChzcGluX2lzX2xvY2tlZCgmdnBjaS0+bG9jaykpOw0KPj4gKw0KPj4gKyAgICBsaXN0
X2Zvcl9lYWNoX2VudHJ5ICggcm0sICZ2cGNpLT5oYW5kbGVycywgbm9kZSApDQo+PiArICAgIHsN
Cj4+ICsgICAgICAgIGlmICggcm0tPm9mZnNldCA9PSBvZmZzZXQgJiYgcm0tPnNpemUgPT0gc2l6
ZSApDQo+PiArICAgICAgICAgICAgcmV0dXJuIHJtOw0KPj4gKw0KPj4gKyAgICAgICAgaWYgKCBv
ZmZzZXQgPD0gcm0tPm9mZnNldCApDQo+PiArICAgICAgICAgICAgYnJlYWs7DQo+PiArICAgIH0N
Cj4+ICsNCj4+ICsgICAgcmV0dXJuIE5VTEw7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyBzdHJ1
Y3QgdnBjaV9yZWdpc3RlciAqdnBjaV9nZXRfcHJldmlvdXNfY2FwX3JlZ2lzdGVyKA0KPj4gKyAg
ICBzdHJ1Y3QgdnBjaSAqdnBjaSwgdW5zaWduZWQgaW50IG9mZnNldCkNCj4+ICt7DQo+PiArICAg
IHVpbnQzMl90IG5leHQ7DQo+PiArICAgIHN0cnVjdCB2cGNpX3JlZ2lzdGVyICpyOw0KPj4gKw0K
Pj4gKyAgICBpZiAoIG9mZnNldCA8IDB4NDAgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBBU1NF
UlRfVU5SRUFDSEFCTEUoKTsNCj4+ICsgICAgICAgIHJldHVybiBOVUxMOw0KPj4gKyAgICB9DQo+
PiArDQo+PiArICAgIHIgPSB2cGNpX2dldF9yZWdpc3Rlcih2cGNpLCBQQ0lfQ0FQQUJJTElUWV9M
SVNULCAxKTsNCj4+ICsgICAgaWYgKCAhciApDQo+PiArICAgICAgICByZXR1cm4gTlVMTDsNCj4+
ICsNCj4+ICsgICAgbmV4dCA9ICh1aW50MzJfdCkodWludHB0cl90KXItPnByaXZhdGU7DQo+PiAr
ICAgIHdoaWxlICggbmV4dCA+PSAweDQwICYmIG5leHQgIT0gb2Zmc2V0ICkNCj4+ICsgICAgew0K
Pj4gKyAgICAgICAgciA9IHZwY2lfZ2V0X3JlZ2lzdGVyKHZwY2ksIG5leHQgKyBQQ0lfQ0FQX0xJ
U1RfTkVYVCwgMSk7DQo+PiArICAgICAgICBpZiAoICFyICkNCj4+ICsgICAgICAgICAgICByZXR1
cm4gTlVMTDsNCj4+ICsgICAgICAgIG5leHQgPSAodWludDMyX3QpKHVpbnRwdHJfdClyLT5wcml2
YXRlOw0KPj4gKyAgICB9DQo+PiArDQo+PiArICAgIGlmICggbmV4dCA8IDB4NDAgKQ0KPj4gKyAg
ICAgICAgcmV0dXJuIE5VTEw7DQo+IA0KPiBUaGUgY29kZSBiZWxvdyBJIHRoaW5rIGl0J3MgYSBi
aXQgc2ltcGxlciAoYW5kIGNvbXBhY3QpIGJ5IGhhdmluZyBhDQo+IHNpbmdsZSByZXR1cm4gaW5z
dGVhZCBvZiBtdWx0aXBsZSBvbmVzOg0KPiANCj4gZm9yICggciA9IHZwY2lfZ2V0X3JlZ2lzdGVy
KHZwY2ksIFBDSV9DQVBBQklMSVRZX0xJU1QsIDEpOyByOw0KPiAgICAgICByID0gbmV4dCA+PSAw
eDQwID8gdnBjaV9nZXRfcmVnaXN0ZXIodnBjaSwNCj4gICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIG5leHQgKyBQQ0lfQ0FQX0xJU1RfTkVYVCwgMSkNCj4gICAgICAg
ICAgICAgICAgICAgICAgICA6IE5VTEwgKQ0KPiB7DQo+ICAgICBuZXh0ID0gKHVpbnQzMl90KSh1
aW50cHRyX3Qpci0+cHJpdmF0ZTsNCj4gICAgIEFTU0VSVChuZXh0ID09ICh1aW50cHRyX3Qpci0+
cHJpdmF0ZSk7DQpXaHkgbmVlZCB0aGlzIEFTU0VSVCBoZXJlPw0KDQo+ICAgICBpZiAoIG5leHQg
PT0gb2Zmc2V0ICkNCj4gICAgICAgICBicmVhazsNCj4gfQ0KPiANCj4gcmV0dXJuIHI7DQo+IA0K
PiBJIGhhdmVuJ3QgdGVzdGVkIGl0IGhvd2V2ZXIuDQpXaWxsIGNoYW5nZSBhbmQgdGVzdC4NCg0K
PiANCj4+ICsNCj4+ICsgICAgcmV0dXJuIHI7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyBpbnQg
dnBjaV9jYXBhYmlsaXR5X2hpZGUoc3RydWN0IHBjaV9kZXYgKnBkZXYsIHVuc2lnbmVkIGludCBj
YXApDQo+PiArew0KPj4gKyAgICBjb25zdCB1bnNpZ25lZCBpbnQgb2Zmc2V0ID0gcGNpX2ZpbmRf
Y2FwX29mZnNldChwZGV2LT5zYmRmLCBjYXApOw0KPj4gKyAgICBzdHJ1Y3QgdnBjaV9yZWdpc3Rl
ciAqcHJldl9uZXh0X3IsICpuZXh0X3I7DQo+IA0KPiBJIHRoaW5rIGl0IG1pZ2h0IGJlIGNsZWFy
IHRvIGp1c3QgbmFtZSB0aGlzIHByZXZfciwgbmV4dF9yLA0KPiBwcmV2X25leHRfciBpcyBJTU8g
YSBiaXQgY29uZnVzaW5nLiAgSSB1bmRlcnN0YW5kIGl0IHJlZmVycyB0byB0aGUgbmV4dA0KPiBj
YXBhYmlsaXR5IHJlZ2lzdGVyIGluIHRoZSBwcmV2aW91cyBjYXBhYmlsaXR5LCBhbmQgSSB0aGlu
ayBwcmV2X3INCj4gbWlnaHQgYmUgZW5vdWdoLg0KV2lsbCBjaGFuZ2UuDQo+IA0KPj4gKyAgICBz
dHJ1Y3QgdnBjaSAqdnBjaSA9IHBkZXYtPnZwY2k7DQo+PiArDQo+PiArICAgIGlmICggIW9mZnNl
dCApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIEFTU0VSVF9VTlJFQUNIQUJMRSgpOw0KPj4gKyAg
ICAgICAgcmV0dXJuIDA7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgc3Bpbl9sb2NrKCZ2cGNp
LT5sb2NrKTsNCj4+ICsgICAgbmV4dF9yID0gdnBjaV9nZXRfcmVnaXN0ZXIodnBjaSwgb2Zmc2V0
ICsgUENJX0NBUF9MSVNUX05FWFQsIDEpOw0KPj4gKyAgICBpZiAoICFuZXh0X3IgKQ0KPj4gKyAg
ICB7DQo+PiArICAgICAgICBzcGluX3VubG9jaygmdnBjaS0+bG9jayk7DQo+PiArICAgICAgICBy
ZXR1cm4gLUVOT0RFVjsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICBwcmV2X25leHRfciA9IHZw
Y2lfZ2V0X3ByZXZpb3VzX2NhcF9yZWdpc3Rlcih2cGNpLCBvZmZzZXQpOw0KPj4gKyAgICBpZiAo
ICFwcmV2X25leHRfciApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIHNwaW5fdW5sb2NrKCZ2cGNp
LT5sb2NrKTsNCj4+ICsgICAgICAgIHJldHVybiAtRU5PREVWOw0KPj4gKyAgICB9DQo+IA0KPiBZ
b3UgY2FuIGpvaW4gYm90aCB0aGUgYWJvdmUgaW50byBhIHNpbmdsZSBjaGVjayBJTU86DQo+IA0K
PiBuZXh0X3IgPSB2cGNpX2dldF9yZWdpc3Rlcih2cGNpLCBvZmZzZXQgKyBQQ0lfQ0FQX0xJU1Rf
TkVYVCwgMSk7DQo+IHByZXZfciA9IHZwY2lfZ2V0X3ByZXZpb3VzX2NhcF9yZWdpc3Rlcih2cGNp
LCBvZmZzZXQpOw0KPiBpZiAoICFuZXh0X3IgfHzCoCFwcmV2X3IgKQ0KPiB7DQo+ICAgICBzcGlu
X3VubG9jaygmdnBjaS0+bG9jayk7DQo+ICAgICByZXR1cm4gLUVOT0RFVjsNCj4gfQ0KPiANCj4g
VGhlcmUncyBubyBiZW5lZml0IGluIHVzaW5nIHR3byBlcXVhbCBlcnJvciBjb25kaXRpb24gY2hl
Y2tzIChqdXN0DQo+IG1ha2VzIHRoZSBjb2RlIGxvbmdlcikNCldpbGwgY2hhbmdlLg0KPiANCj4+
ICsNCj4+ICsgICAgcHJldl9uZXh0X3ItPnByaXZhdGUgPSBuZXh0X3ItPnByaXZhdGU7DQo+PiAr
ICAgIC8qDQo+PiArICAgICAqIE5vdCBjYWxsaW5nIHZwY2lfcmVtb3ZlX3JlZ2lzdGVyKCkgaGVy
ZSBpcyB0byBhdm9pZCByZWRvaW5nDQo+PiArICAgICAqIHRoZSByZWdpc3RlciBzZWFyY2gNCj4+
ICsgICAgICovDQo+PiArICAgIGxpc3RfZGVsKCZuZXh0X3ItPm5vZGUpOw0KPj4gKyAgICBzcGlu
X3VubG9jaygmdnBjaS0+bG9jayk7DQo+PiArICAgIHhmcmVlKG5leHRfcik7DQo+PiArDQo+PiAr
ICAgIGlmICggIWlzX2hhcmR3YXJlX2RvbWFpbihwZGV2LT5kb21haW4pICkNCj4+ICsgICAgICAg
IHJldHVybiB2cGNpX3JlbW92ZV9yZWdpc3Rlcih2cGNpLCBvZmZzZXQgKyBQQ0lfQ0FQX0xJU1Rf
SUQsIDEpOw0KPj4gKw0KPj4gKyAgICByZXR1cm4gMDsNCj4+ICt9DQo+PiArDQo+PiAgc3RhdGlj
IGludCB2cGNpX2luaXRfY2FwYWJpbGl0aWVzKHN0cnVjdCBwY2lfZGV2ICpwZGV2KQ0KPj4gIHsN
Cj4+ICAgICAgZm9yICggdW5zaWduZWQgaW50IGkgPSAwOyBpIDwgTlVNX1ZQQ0lfSU5JVDsgaSsr
ICkNCj4+IEBAIC05MSw3ICsxODQsNiBAQCBzdGF0aWMgaW50IHZwY2lfaW5pdF9jYXBhYmlsaXRp
ZXMoc3RydWN0IHBjaV9kZXYgKnBkZXYpDQo+PiAgICAgICAgICBjb25zdCB1bnNpZ25lZCBpbnQg
Y2FwID0gY2FwYWJpbGl0eS0+aWQ7DQo+PiAgICAgICAgICBjb25zdCBib29sIGlzX2V4dCA9IGNh
cGFiaWxpdHktPmlzX2V4dDsNCj4+ICAgICAgICAgIHVuc2lnbmVkIGludCBwb3M7DQo+PiAtICAg
ICAgICBpbnQgcmM7DQo+PiAgDQo+PiAgICAgICAgICBpZiAoICFpc19leHQgKQ0KPj4gICAgICAg
ICAgICAgIHBvcyA9IHBjaV9maW5kX2NhcF9vZmZzZXQocGRldi0+c2JkZiwgY2FwKTsNCj4+IEBA
IC0xMDMsOSArMTk1LDI2IEBAIHN0YXRpYyBpbnQgdnBjaV9pbml0X2NhcGFiaWxpdGllcyhzdHJ1
Y3QgcGNpX2RldiAqcGRldikNCj4+ICAgICAgICAgIGlmICggIXBvcyApDQo+PiAgICAgICAgICAg
ICAgY29udGludWU7DQo+PiAgDQo+PiAtICAgICAgICByYyA9IGNhcGFiaWxpdHktPmluaXQocGRl
dik7DQo+PiAtICAgICAgICBpZiAoIHJjICkNCj4+IC0gICAgICAgICAgICByZXR1cm4gcmM7DQo+
PiArICAgICAgICBpZiAoIGNhcGFiaWxpdHktPmluaXQocGRldikgKQ0KPiANCj4gSSB0aGluayB5
b3Ugd2FudCB0byBzdG9yZSByYyBoZXJlIHRvIHByaW50IGl0IGluIHRoZSB3YXJuaW5nIG1lc3Nh
Z2UNCj4gYmVsb3cuDQo+IA0KPj4gKyAgICAgICAgew0KPj4gKyAgICAgICAgICAgIGludCByYzsN
Cj4+ICsNCj4+ICsgICAgICAgICAgICBpZiAoIGNhcGFiaWxpdHktPmNsZWFudXAgKSB7DQo+PiAr
ICAgICAgICAgICAgICAgIHJjID0gY2FwYWJpbGl0eS0+Y2xlYW51cChwZGV2KTsNCj4+ICsgICAg
ICAgICAgICAgICAgaWYgKCByYyApDQo+PiArICAgICAgICAgICAgICAgICAgICByZXR1cm4gcmM7
DQo+IA0KPiBIZXJlIHdoZXJlIGJvdGggaW5pdCBhbmQgY2xlYW51cCBmYWlsZWQsIHlvdSBzaW1w
bHkgZG9uJ3QgcHJpbnQgYW55DQo+IG1lc3NhZ2UuDQpHb3QgaXQgLCB3aWxsIHByaW50IG1lc3Nh
Z2Ugd2hlbiBpbml0LCBjbGVhbnVwIGFuZCBoaWRlIGZhaWwuDQoNCj4gDQo+PiArICAgICAgICAg
ICAgfQ0KPj4gKw0KPj4gKyAgICAgICAgICAgIHByaW50ayhYRU5MT0dfV0FSTklORyAiJXBkICVw
cDogJXMgY2FwICV1IGluaXQgZmFpbCwgbWFzayBpdFxuIiwNCj4+ICsgICAgICAgICAgICAgICAg
ICAgcGRldi0+ZG9tYWluLCAmcGRldi0+c2JkZiwNCj4+ICsgICAgICAgICAgICAgICAgICAgaXNf
ZXh0ID8gImV4dGVuZGVkIiA6ICJsZWdhY3kiLCBjYXApOw0KPiANCj4gSSB0aGluayB0aGlzIG5l
ZWRzIHRvIGJlIGRvbmUgYWhlYWQgb2YgdGhlIGNsZWFudXAoKSwgYW5kIHByaW50IHRoZQ0KPiBy
ZXR1cm5lZCBlcnJvciBjb2RlLiAgT3ZlcmFsbCB3ZSBuZWVkIG1lc3NhZ2VzIHByaW50ZWQgd2hl
biBhbnkgb2YNCj4gdGhvc2UgZmFpbHMsIGFzIHRoYXQgbWFrZXMgaXQgZWFzaWVyIHRvIGRlYnVn
IHdoZW4gdGhpbmdzIGdvIHdyb25nLg0KPiANCj4gVGhhbmtzLCBSb2dlci4NCg0KLS0gDQpCZXN0
IHJlZ2FyZHMsDQpKaXFpYW4gQ2hlbi4NCg==


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 07:03:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 07:03:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007955.1387147 (Exim 4.92)
	(envelope-from )
	id 1uNR6c-0002Tx-2j; Fri, 06 Jun 2025 07:03:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007955.1387147; Fri, 06 Jun 2025 07:03: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 1uNR6b-0002T6-TN; Fri, 06 Jun 2025 07:03:09 +0000
Received: by outflank-mailman (input) for mailman id 1007955;
 Fri, 06 Jun 2025 07:03: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 1uNR6a-0002QP-EG
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 07:03:08 +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 4bfafc25-42a4-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 09:03:06 +0200 (CEST)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-450dd065828so13099155e9.2
 for ; Fri, 06 Jun 2025 00:03:06 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-31349f17be8sm746051a91.3.2025.06.06.00.03.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 06 Jun 2025 00:03:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4bfafc25-42a4-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749193386; x=1749798186; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=fBDXHMOf8VCTc+4VoPNOfZfdMeTaEz/GjWIXf6YvVBM=;
        b=CKrtcByEdiszg9f2GaO72/xVPp5G+boWzgriy9rPNyefytqZnQtavHPHfQG5GlChwP
         cJ3bncPDQYoq25qTjG2KaPvbOy7fbIJ2Gidl4/cdSov3xVHUAs2tqug5Mg5mi1IjuPSx
         xAdA59cKPIQpyb+Dah1Fq8Hcbbe5ICHny8lzbw+xtiYnYTxWx6a8g4z31NsnQcpX07mG
         StsWJUod/F/2mh1aqO3bPxWD6HoWdpNbif0bJs6xlmECWBFgz4Hkk8EGnQmlzjAvtUrH
         GscE8cd/MmrVgx22sGlZU5oqxAvLb87//DRuHp8/qNKZA4IQaGzxFDtJvfGluq2w2KSJ
         SmeA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749193386; x=1749798186;
        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=fBDXHMOf8VCTc+4VoPNOfZfdMeTaEz/GjWIXf6YvVBM=;
        b=BY65D7QoWHlV084F/ysDO+aZPeKmCAH61gaeK2Z3+w0B0hV+P6/rHghtM9p4AUB4la
         4cfGsyoNQy8lMuiUqB6xwpCLQU8kQhOsgE6m30C502XphpFZq1BM8bAMWYLqSNkuxjPb
         XgW0Z5HSQOw8zYYph7QEEvxhE1Ddk4qliaB5JYQaqH3LdEJxcdygyZf+ae3yg/Zf5soj
         mqxwXcr3faZlJeByFFjxMcB1D+B/mP9/Ou+uZNTGEuKVZ2WD9+wVOR3hnyPSw8YmZkV/
         6D2krHYZO0gqZnd5D2+HYWo530L1vKra1r3TKIC8h0rYjwfvj0j+2l006OeXfFD/BgaG
         cekQ==
X-Forwarded-Encrypted: i=1; AJvYcCWkcSaUz0MDmGdr79Vd9juimJz7PnCsTev04VoK9yhpHYkczXl5ogIygdrAMVsslOXoyNYzVtvvrCE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx5u3l4/GnensFz/h+2xhqg9Y26eCe7sd4+Ty/Kv7A9N/PUwelo
	H9dxXF7uGHSfHSA0ggvLH6EjDN/zXO4mQwr58GXJlyvbPAHWbbgFxHYzNoL6EWP2+g==
X-Gm-Gg: ASbGnctUPWTDBtCy07kXL+WEPS7yBCMw8U1trGLZR/AdmDGIZeloxEycmhi/07M+kj2
	yTQDUBhKx1iAUll3ksFEv2qhohkUN/FGJwdLVG7NJvYaUDMAMcUk3SMN4laupZVm+tce20WRiAe
	SbkjOK95X592yhBNOeJZdugm8GNCdzwrmtRdt1tYWxLkAx7SzOu2ZBbTGLRz7lWkVDW7Iclqpu5
	8cCpxtc0MRGY/LTcXQ3PBzvUp1xwFBDZNdrwAIcOMXijsRC9F9qfre6/8QYT9Rury7WZCTm4Y/E
	6doP3+jAiI9Ry1ozm9BvAxpYROnGpmgo7WMbzRWChyfh1gUGzbMvpzJb3Z3Mo/zQiTmzEpaRZSP
	xfw/p+cSX1G795nxJq6IfZHb11FzP6KqKJ0T6
X-Google-Smtp-Source: AGHT+IHj2Unn7b5F6ZZjwBs8kYLc5dVD/p2AKif0YOsKpjMyIObHi9IG5wLMNqUsdmf8WgGQGrIzCA==
X-Received: by 2002:a05:6000:2888:b0:3a4:c909:ce16 with SMTP id ffacd0b85a97d-3a531ab6c62mr1774054f8f.49.1749193386032;
        Fri, 06 Jun 2025 00:03:06 -0700 (PDT)
Message-ID: 
Date: Fri, 6 Jun 2025 09:02:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 1/3] xen/domain: unify domain ID allocation
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech,
 dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250528225030.2652166-1-dmukhin@ford.com>
 <20250528225030.2652166-2-dmukhin@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: <20250528225030.2652166-2-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 29.05.2025 00:50, dmkhn@proton.me wrote:
> @@ -1079,7 +1082,7 @@ static struct domain *__init create_dom0(struct boot_info *bi)
>  
>      bd->d = d;
>      if ( construct_dom0(bd) != 0 )
> -        panic("Could not construct domain 0\n");
> +        panic("Could not construct domain %pd\n", d);

Just one nit I only noticed when reading Julien's reply: The word "domain" is
now becoming redundant here, and hence would imo better be dropped.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 07:05:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 07:05:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007969.1387159 (Exim 4.92)
	(envelope-from )
	id 1uNR8y-0003V0-HI; Fri, 06 Jun 2025 07:05:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007969.1387159; Fri, 06 Jun 2025 07:05: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 1uNR8y-0003Ut-Dv; Fri, 06 Jun 2025 07:05:36 +0000
Received: by outflank-mailman (input) for mailman id 1007969;
 Fri, 06 Jun 2025 07:05: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 1uNR8x-0003Um-Da
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 07:05:35 +0000
Received: from rein-hpcbdc09 (unknown [1.7.42.26])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a1be8be0-42a4-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 09:05:33 +0200 (CEST)
Received: by rein-hpcbdc09 (Postfix, from userid 1000)
 id D7D7E80C0C4F; Fri,  6 Jun 2025 12:35:28 +0530 (IST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a1be8be0-42a4-11f0-a301-13f23c93f187
From: Jahan Murudi 
To: sstabellini@kernel.org,
	julien@xen.org,
	bertrand.marquis@arm.com,
	michal.orzel@amd.com,
	Volodymyr_Babchuk@epam.com
Cc: xen-devel@lists.xenproject.org,
	Jahan Murudi 
Subject: [PATCH xen/arm 1/1] xen/arm: Standardize R-Car platform Kconfig descriptions
Date: Fri,  6 Jun 2025 12:35:01 +0530
Message-Id: <20250606070501.3470801-1-jahan.murudi.zg@renesas.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Changed "RCar3/RCar4" to "R-Car Gen3/Gen4" to match official Renesas branding
Aligns with documentation and industry-standard terminology

Signed-off-by: Jahan Murudi 
---
 xen/arch/arm/platforms/Kconfig | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig
index 87bf614788..c8bc0bfae3 100644
--- a/xen/arch/arm/platforms/Kconfig
+++ b/xen/arch/arm/platforms/Kconfig
@@ -22,21 +22,23 @@ config QEMU
 	  machine.
 
 config RCAR3
-	bool "Renesas RCar3 support"
+	bool "Renesas R-Car Gen3 support"
 	depends on ARM_64
 	select HAS_SCIF
 	select IPMMU_VMSA
 	help
-	  Enable all the required drivers for Renesas RCar3
+	  Enable support for Renesas R-Car Generation 3 SoCs (H3, M3, etc.).
+	  Includes all required drivers and platform-specific features.
 
 config RCAR4
-	bool "Renesas RCar4 support"
+	bool "Renesas R-Car Gen4 support"
 	depends on ARM_64
 	select HAS_SCIF
 	select HAS_ITS
 	select IPMMU_VMSA
 	help
-	Enable all the required drivers for Renesas RCar4
+	  Enable support for Renesas R-Car Generation 4 SoCs (V4H, V4M, etc.).
+	  Includes all required drivers and platform-specific features.
 
 config MPSOC
 	bool "Xilinx Ultrascale+ MPSoC support"
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Jun 06 07:06:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 07:06:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007973.1387170 (Exim 4.92)
	(envelope-from )
	id 1uNR9M-0003xq-Of; Fri, 06 Jun 2025 07:06:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007973.1387170; Fri, 06 Jun 2025 07:06: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 1uNR9M-0003xj-Li; Fri, 06 Jun 2025 07:06:00 +0000
Received: by outflank-mailman (input) for mailman id 1007973;
 Fri, 06 Jun 2025 07:05: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 1uNR9L-0003Um-CY
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 07:05:59 +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 b299b98b-42a4-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 09:05:58 +0200 (CEST)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-3a36748920cso1712655f8f.2
 for ; Fri, 06 Jun 2025 00:05:58 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-7482b085085sm663614b3a.88.2025.06.06.00.05.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 06 Jun 2025 00:05:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b299b98b-42a4-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749193558; x=1749798358; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=fnQ/mq9SNiuCv2qjezEcnkEkN+zpWwHyLhaamzituXE=;
        b=e38gpIMK5vAJ7kO+VhiNUuWibKziQHixaAZsIuAmZdnRqPn/pCnVXBcpAla2CN3x75
         e8eslfkHS0Yzjvj2X0a4sCxV7J0kBjxVBwgb0L/7d+xEYwmzq2Gx6E7q3QckJMLGPF/8
         XBPPVsOJ9kyZpYgJxEixwtxvloTU4pTCp6M7spEjUFbjlmzT3bqnpS8CAc3XsqjXNchG
         8ELpRLtbduB6mBK5WmIPWZO/l4IV3C+suBZ6OpFojXwrDHGOYSiNnmyadtoEBdnkwM+G
         txg9r69kz7F1TvR9eFYdkZOZOkK+vWYOdOHj8XReNWy38F9meyDzBs6wcH7Hiww5vP80
         2Lkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749193558; x=1749798358;
        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=fnQ/mq9SNiuCv2qjezEcnkEkN+zpWwHyLhaamzituXE=;
        b=mrFO2kqjwopd8a3kg3XqdR6lYcJbQ9Z7GTE3G67rJ5Y/ugKnSyZPxDQzWqBehCmSuU
         nz57pVSjHJMAeLRGJeL/79DAehByj0Xe7szbBubEpsHgf2gUz+inSxB/mLlUa0FEv+gh
         Sjhc/vuP83qh1Sct4RC3dt4t8+q0+2YjTS33sRxqYIa0b/JyR0tunAlupnPplAyQyLDa
         XObphe+18JM+as/7k9Yb0ylxRauT6xJ68ZF0K1drnuwJC4RSpAtzRF6dcIXHE+fPRFNn
         Iz6IrXSkxTTM4JnQCcfPFHL4j3erQ9vOwqUBcUPz6E+PlonAlH8XPCLafX5LcM0vqvWY
         lk6w==
X-Gm-Message-State: AOJu0YxlC8LUy+fENDq9qNyGTLecrJGMBs9p7ltXaXf7g+EgnZeDEE7t
	71oiH6zug3Bmh+eR984f5zJ6iIvHAAEgBUvd/kfa2CDZPeZNzR0JCC4MuidVky7rGw==
X-Gm-Gg: ASbGnctr4QXJrJuWcDnmbuosgeLOtialBnd14eKYf7eAnpDIFjUgMx8vHyaQgVBZiX9
	JqXoFXLEWezjmGvJWegdju7CZ1H7TBGuWI5fyOWkwxB2HBtSTCazU1XzOvTl6zBAXBgYppNmAms
	GF1YafNVZOePx+Fxnp3wzlfD1mw9VXZGlCTrSA3vYXQgbczgstsMa2J5V9Ffm8PKygpQRbDgBA6
	+nyRzbw5uYoezbYJMzQ4o9UmUi5iW0QRZouWy4MKGuZ0DSjROjediOO7jIl4GBPcWCQ2mUm1XrR
	0SYi0OBrH6dCY0UxxhaSUCuCu1uWFdXEscRmIhwNziHxXiYp+IpReNhDrr4QMyBYBxnpYjjyVj4
	tLO31jEEVw8Oe/sw8fEF7hH0qBFgPsoFNxZDz
X-Google-Smtp-Source: AGHT+IEzuJp6p463iTNdzvc9StdbTn6acCO3dRsCzqcd4eGRyzf1Ozy5A1CmBnB4i2Jyu+dpO30wpg==
X-Received: by 2002:a05:6000:2001:b0:3a4:f7dd:234b with SMTP id ffacd0b85a97d-3a531450c6dmr1787084f8f.0.1749193558149;
        Fri, 06 Jun 2025 00:05:58 -0700 (PDT)
Message-ID: <752cff02-cef6-4a4c-80b9-eba3bbf9b264@suse.com>
Date: Fri, 6 Jun 2025 09:05:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 04/10] vpci: Refactor REGISTER_VPCI_INIT
To: "Chen, Jiqian" 
Cc: "xen-devel@lists.xenproject.org" ,
 "Huang, Ray" , Andrew Cooper ,
 Anthony PERARD ,
 "Orzel, Michal" , Julien Grall ,
 Stefano Stabellini ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
 <20250526094559.140423-5-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 06.06.2025 08:29, Chen, Jiqian wrote:
> On 2025/6/5 20:50, Roger Pau Monné wrote:
>> On Mon, May 26, 2025 at 05:45:53PM +0800, Jiqian Chen wrote: 
>>> +  }; \
>>> +  static vpci_capability_t *const finit##_entry  \
>>> +               __used_section(".data.vpci") = &finit##_t
>>
>> IMO this should better use .rodata instead of .data. 
> Is below change correct?
> 
> +    static const vpci_capability_t *const finit##_entry  \
> +        __used_section(".rodata") = &finit##_t

No, specifically because ...

>> Not that it matters much in practice, as we place it in .rodata anyway.  Note
>> however you will have to move the placement of the VPCI_ARRAY in the
>> linker script ahead of *(.rodata.*), otherwise that section match will
>> consume the vPCI data.
> I am sorry, how to move it ahead of *(.rodata.*) ?
> Is below change correct?
> 
> diff --git a/xen/include/xen/xen.lds.h b/xen/include/xen/xen.lds.h
> index 793d0e11450c..3817642135aa 100644
> --- a/xen/include/xen/xen.lds.h
> +++ b/xen/include/xen/xen.lds.h
> @@ -188,7 +188,7 @@
>  #define VPCI_ARRAY               \
>         . = ALIGN(POINTER_ALIGN); \
>         __start_vpci_array = .;   \
> -       *(SORT(.data.vpci.*))     \
> +       *(.rodata)             \

... this isn't - you'd move _all_ of .rodata into here, which definitely
isn't what you want. What I understand Roger meant was a .rodata-like
section, e.g. .rodata.vpci.* (much like it was .data.vpci.* before).

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 07:06:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 07:06:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007981.1387181 (Exim 4.92)
	(envelope-from )
	id 1uNRAD-0004Wj-2l; Fri, 06 Jun 2025 07:06:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007981.1387181; Fri, 06 Jun 2025 07: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 1uNRAC-0004Wc-Uy; Fri, 06 Jun 2025 07:06:52 +0000
Received: by outflank-mailman (input) for mailman id 1007981;
 Fri, 06 Jun 2025 07:06: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 1uNRAB-0004WO-Ls
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 07:06:51 +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 d0bde79e-42a4-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 09:06:49 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d0bde79e-42a4-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1749193608; x=1749452808;
	bh=F9GJcWMma2EoiodwWTOaBiwQYbZpsYFPaJI18LDuaNA=;
	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=NiGJyfwfh8+lNcFjkou755Sj6KzFT131Q9F/iBKniO8gxDfc2OiTv+tDOJNOUZGm8
	 6SpMvKZJGVQ0pJtghn4xnLcj30bc8v/S9hz4aZpABqgJq+FMLGqORemh/61gO0BBkm
	 BFzTqSfpQBB+ujJdg+6+RQucIwDbSvhdnLa/pHHcZMjUO1AI90MqhZM+rHc3jeDhwu
	 3GHaOlibKW0aIICljRxEJnNLGvJZO0l+uNV4Cf2vbIbVeWBi8plw+78j7J4shsPR4S
	 63s+ORYrGYh9jrfZUML8WNIUZhNK4auixT57DY0RMHRbcZVuhkqULlQObY/oXGx9jj
	 Zv3FpMM8ZQuZg==
Date: Fri, 06 Jun 2025 07:06:44 +0000
To: Jan Beulich 
From: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: Re: [PATCH v2 2/2] xen/console: unify printout behavior for UART emulators
Message-ID: 
In-Reply-To: <842528df-d0ba-4ab2-b182-b6f824c82dc1@suse.com>
References: <20250605004601.1142090-1-dmukhin@ford.com> <20250605004601.1142090-3-dmukhin@ford.com> <842528df-d0ba-4ab2-b182-b6f824c82dc1@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 350579f0741ba047922ec9ffb663dccc7066337b
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 05, 2025 at 08:18:34AM +0200, Jan Beulich wrote:
> On 05.06.2025 02:46, dmkhn@proton.me wrote:
> > From: Denis Mukhin 
> >
> > If virtual UART from domain X prints on the physical console, the behav=
ior is
> > updated to (see [1]):
> > - console focus in domain X: do not prefix messages;
> > - no console focus in domain X: prefix all messages with "(dX)".
> >
> > Use guest_printk() without rate-limiting in all current in-hypervisor U=
ART
> > emulators. That aligns the behavior with debug I/O port 0xe9 handler on=
 x86 and
> > slightly improves the logging since guest_printk() already prints the d=
omain
> > ID. guest_printk() was modified to account for console focus ownership.
> >
> > Modify guest_console_write() for hardware domain case by adding domain =
ID to
> > the message when hwdom does not have console focus.
> >
> > [1] https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2412121655360=
.463523@ubuntu-linux-20-04-desktop/
> > Signed-off-by: Denis Mukhin 
> > ---
> > Changes since v1:
> > - dropped change for debug port and for HYPERVISOR_console_io hypercall
>=20
> Yet then what about ...
>=20
> > --- 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 !=3D '\n' )
> >              uart->buf[uart->idx++] =3D '\n';
> >          uart->buf[uart->idx] =3D '\0';
> > -        printk(XENLOG_G_DEBUG "DOM%u: %s", d->domain_id, uart->buf);
> > +        guest_printk(d, "%s", uart->buf);
> >          uart->idx =3D 0;
> >      }
> >      spin_unlock(&uart->lock);
>=20
> ... this dropping of XENLOG_G_DEBUG? In fact I'd have expected such to
> be _added_ where presently missing.

vUART is a debugging facility. This flavor of UART is specifically for gues=
t OS
early boot debugging.
I think it is not desirable to potentially lose guest messages while doing =
such
early guest OS boot debugging.

>=20
> Jan



From xen-devel-bounces@lists.xenproject.org Fri Jun 06 07:11:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 07:11:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007987.1387190 (Exim 4.92)
	(envelope-from )
	id 1uNREM-00066w-Hz; Fri, 06 Jun 2025 07:11:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007987.1387190; Fri, 06 Jun 2025 07:11:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNREM-00066p-Dw; Fri, 06 Jun 2025 07:11:10 +0000
Received: by outflank-mailman (input) for mailman id 1007987;
 Fri, 06 Jun 2025 07:11: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 1uNREL-00066f-2l
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 07:11:09 +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 698dbd2f-42a5-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 09:11:05 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3a3798794d3so1393066f8f.1
 for ; Fri, 06 Jun 2025 00:11:06 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-236032fccd6sm6400785ad.134.2025.06.06.00.11.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 06 Jun 2025 00:11:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 698dbd2f-42a5-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749193865; x=1749798665; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=XLz9ZFSK9NlzDWp/ZMK6ZIDBrWw+SmS1Bo2uzbLLy+8=;
        b=Wi+IdzljW91jzgD83cbWQDRrRJzV0qspo1enbysEo9BqpvpOcyqpqBmJuQFhHUwcpQ
         xufAZyZ9AakYWeVFzahwkHLa5Ai3RjPE6XfFyC1mOHi7y9mrRZxoaWBh7J3IX92uxEKo
         LXriOcU+cuiBjDncAtNOKTGLlpUkEGy3EC2pBIQyLOFkcEjBSH2rurPXeotEUyAx3W0/
         j1bWQYalO4POKAnpE6iOyP2j8lQYcjvIRWgoJ+vi9udZA+1PCdDy5TFZE1IFzxLZTwxg
         3jQ/AiGKTLNhaJ4d8uL7l+giEXOKf8K9mdrVk+c6RAVqNnTA6t1KSpDtBH4Secs63fLC
         9siw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749193865; x=1749798665;
        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=XLz9ZFSK9NlzDWp/ZMK6ZIDBrWw+SmS1Bo2uzbLLy+8=;
        b=iEvT2hmV6zzVq3K2Ju6PbddOMbHAzpPox3oZfR/vV/JE8FP56NVU6Y4TiimIF43PyV
         ezFDgf68OHHoXql6X3N4IwSRCCjgYGpKGUAqd/aJXNvcOt85CAYMTjOyYxbwVSPX713y
         ws1a0UJwwbh0beNcou0yJGhb1XkRyOEZr8umTJfi8nm2edMaEJKDrrE6NW3U+fa5dn6R
         0VKeXOIKJPM+9C94JkTh+vkrCcjHLObpobLh+w8iZ8SwuUciUbCo7WRYGU+o4UoUB9F3
         wenJqK3wFR585Up6IMwDhkAJnJ5YoR8oOELwEMkOP1kB8rn9ZG05jBjiFDxmgYdVashK
         b0kw==
X-Forwarded-Encrypted: i=1; AJvYcCWkSxMXuReFSGY+HkkV+v3cIfATlvMgdhlO68ygpROaMR0mUb41fHO6MOJ9Ik3rVxAI78LSQfmpw8s=@lists.xenproject.org
X-Gm-Message-State: AOJu0YziuQBows2sSmzSHyDfOtCBtjdHBdpllwl4fTK/hB1fxnWE6o1q
	QxgwQ4w4kcKX9Aby2P09bQtooTyL0AZIUMMkroKGOGvDeMxhmhFMzizId1DmYjPcFg==
X-Gm-Gg: ASbGncsZ8iT62DG89mjmx/f6kyZc9NbWZEtRaFMiGmTkxHeSbP8bTBF8/W8UWFFvi4z
	YUY5LXkvqTx8n20TikLTzhC4fSgxicAgQ91jLXun4sj5cWsPvMrOKKBEgiStVKfwZmJSpaQyw6v
	tCxG0lNMfrEEiqOQ7XDYo7f8UNeZSU2Eff5fE4VQdVXvQsxykDQxqVRd9r87wQxUr5y4XODihOD
	6fhSafG8/dZYMwsDlQWU8j1deaqMuKK3tY7AZeQTzgL1coPDeEyBlmZVBYUrPcNyNVStKxjhOWw
	TG30xtdTFzVfNCbo+luHdLn6w8MgvhnkyMpUGe08lRvMn/IktEfpJlThzaK+2Uu92YqQjEudL61
	AZRG6qvVKCCG1+QmA33HOZ8wSBY3MVaW03E18
X-Google-Smtp-Source: AGHT+IFA5Bsb3yQaWX91X+X3j17QthABBwaBUxjr0ZPHXIqvLoWbgVly3JN5LWLUCCWKu6S02IyXZQ==
X-Received: by 2002:a5d:4e85:0:b0:3a5:3517:de3e with SMTP id ffacd0b85a97d-3a53517ded1mr525184f8f.35.1749193865517;
        Fri, 06 Jun 2025 00:11:05 -0700 (PDT)
Message-ID: 
Date: Fri, 6 Jun 2025 09:10:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen: add header guards to generated asm generic
 headers
To: Stefano Stabellini 
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech,
 michal.orzel@amd.com, julien@xen.org, roger.pau@citrix.com,
 xen-devel@lists.xenproject.org
References: 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.06.2025 02:08, Stefano Stabellini wrote:
> MISRA D4.10 requires to have proper header guards in place in all header
> files. Add header guards for generated asm generic headers as well.
> 
> Suggested-by: Jan Beulich 
> Signed-off-by: Stefano Stabellini 

Acked-by: Jan Beulich 
albeit, as mentioned elsewhere, preferably with ...

> --- a/xen/scripts/Makefile.asm-generic
> +++ b/xen/scripts/Makefile.asm-generic
> @@ -32,7 +32,14 @@ old-headers := $(wildcard $(obj)/*.h)
>  unwanted    := $(filter-out $(generic-y) $(generated-y),$(old-headers))
>  
>  quiet_cmd_wrap = WRAP    $@
> -      cmd_wrap = echo "\#include " > $@
> +      cmd_wrap = \
> +	arch=$$(echo $@ | sed -n 's:.*arch/\([^/]*\)/.*:\1:p' | tr a-z A-Z); \
> +	upper=$$(echo $*.h | tr a-z A-Z | tr '/.' '__'); \
> +	printf "\#ifndef $${arch}_GENERIC_$${upper}\n" > $@.new; \
> +	printf "\#define $${arch}_GENERIC_$${upper}\n" >> $@.new; \
> +	printf "\#include \n" >> $@.new; \
> +	printf "\#endif /* $${arch}_GENERIC_$${upper} */\n" >> $@.new; \
> +	mv -f $@.new $@
>  
>  quiet_cmd_remove = REMOVE  $(unwanted)
>        cmd_remove = rm -f $(unwanted)

... echo instead of printf (and then respective adjustments to the strings), if
that's technically possible.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 07:12:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 07:12:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1007997.1387200 (Exim 4.92)
	(envelope-from )
	id 1uNRFT-0006mP-T3; Fri, 06 Jun 2025 07:12:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1007997.1387200; Fri, 06 Jun 2025 07:12: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 1uNRFT-0006mI-QN; Fri, 06 Jun 2025 07:12:19 +0000
Received: by outflank-mailman (input) for mailman id 1007997;
 Fri, 06 Jun 2025 07:12: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 1uNRFS-0006m5-5G
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 07:12:18 +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 9426a53b-42a5-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 09:12:17 +0200 (CEST)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-450d668c2a1so20039745e9.0
 for ; Fri, 06 Jun 2025 00:12:17 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b2f5ed58d5bsm664288a12.14.2025.06.06.00.12.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 06 Jun 2025 00:12:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9426a53b-42a5-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749193937; x=1749798737; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=JTiPZ9vuQoMWmNUBBOl9xiWho2oF5oPhLBgvl/VL6F0=;
        b=cz1VTrioomRgOCqHecRpbZVorINNaIVgLkbrf/6zTk2KthU1Yjld7fmTls0CRinv3S
         GjetHddPYyrVyBtRw8gZzwgYE8x+zqor9LtA0/GRjMYl+LnuMxp2f9E92pGl73czzSJs
         1MbA8tQBg0vWiK/qTvG+vsCuouUrBnVLLc/FFiZo93XXAgQy6kfQAPHrfr9hz5sWl+LC
         OeSOdCRn4yFzxIu/hg0dpx2mPkIfjWhEX05TwZTR6aCKlBEDpPoUz5+lNBYXYS3tpwRl
         14eiyKMDwlSo9RM514D7vTH78pQswcDKrCFhe6nygSKh02oCeBwhQcsrCSrd+bTitn4D
         xYmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749193937; x=1749798737;
        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=JTiPZ9vuQoMWmNUBBOl9xiWho2oF5oPhLBgvl/VL6F0=;
        b=vk0z0xa0A6RL2KYu3pgcrMJlSSvEvGEWJ9UgP7PP/CR0xZKjLe4ypf4tpd8NtHqFvA
         c7hXbZsrZ/K7GsZb0wMFmeH1kmUfrzlC96ET6oDAvPGORGt9dIIKVl72Gcy+aC1GPjf1
         OfUFTGLIPbcKZMv7MAx4pJFmUWv8Ukd/mgsVb1k0hMZSDjrEPEtoRbF5IqsBBr9Sz0KR
         yz/68OzO2gXqE0R5W+Ngwmyiexk+so8dj899T3K3ZRUNjrydZKXCd5FjkIYseVWpK0OB
         1PiwWXg1LX8oGl3b8Zr5q2g20dg1byK2FnfzsBcMAop5rY27V6sB1E0IFepbjSUUI8Qo
         M6lA==
X-Gm-Message-State: AOJu0YwY0I4l59I3oK/Qvb9eXcO5Qp2/3pF8OPFrDoxQkvAgP2cW8dlH
	LEeNDA3Nh6WD5aD8i68n4Rd2UAPhCe2O3hOvKBp8O0qtGYdgQ7mdd/3f9JjVQi1Exg==
X-Gm-Gg: ASbGnctez3oiTfg279yPI7QU6En/OJAl0J29l1UPZoykqmsYz+YWxZKFdtG1GnSCl0p
	CumypgLpmur4wK6qKyioczyp9sOSJd8Q9MRkl3oDaAtVqKtKHvhUZkyHKez5revpyMUI3SbnNqv
	9uL0ma1bpEMPaii09Ik4ykbUFhlASCAQ+AwRUmXk9h/lcyj/4OR6jWARnc45S5fdr5LaoklTX+w
	xCkEcnKcgxXKYx1gzb0ST9bp8aiEv8bRAsodReCKnaD49GEsxw07nJIfSSsb78PGg4xTZGht5s9
	kDLjuAXFbw1cYX9/8OGY3asC1fjAOJEK3WoYaCb317+LzSR4y7ay9DFsf4MAg7mC2viGk7ZmBjp
	Te5Za7eJjy1u/jqQVPbGFdqi/hA/Vkw8Nkz3psrHsUxhh4uQ=
X-Google-Smtp-Source: AGHT+IESxVjUJOpbxFmC6PHgIA+KFMj4c99r1EcX22Cfd+aAUhq+l++wtdzA+mPIfZ50Wml3lpv8RA==
X-Received: by 2002:a05:6000:40e1:b0:3a4:e238:6496 with SMTP id ffacd0b85a97d-3a526e0cc1dmr5996779f8f.18.1749193936654;
        Fri, 06 Jun 2025 00:12:16 -0700 (PDT)
Message-ID: 
Date: Fri, 6 Jun 2025 09:12:06 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/2] xen/console: unify printout behavior for UART
 emulators
To: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com,
 anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com,
 roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
References: <20250605004601.1142090-1-dmukhin@ford.com>
 <20250605004601.1142090-3-dmukhin@ford.com>
 <842528df-d0ba-4ab2-b182-b6f824c82dc1@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 06.06.2025 09:06, dmkhn@proton.me wrote:
> On Thu, Jun 05, 2025 at 08:18:34AM +0200, Jan Beulich wrote:
>> On 05.06.2025 02:46, dmkhn@proton.me wrote:
>>> From: Denis Mukhin 
>>>
>>> If virtual UART from domain X prints on the physical console, the behavior is
>>> updated to (see [1]):
>>> - console focus in domain X: do not prefix messages;
>>> - no console focus in domain X: prefix all messages with "(dX)".
>>>
>>> Use guest_printk() without rate-limiting in all current in-hypervisor UART
>>> emulators. That aligns the behavior with debug I/O port 0xe9 handler on x86 and
>>> slightly improves the logging since guest_printk() already prints the domain
>>> ID. guest_printk() was modified to account for console focus ownership.
>>>
>>> Modify guest_console_write() for hardware domain case by adding domain ID to
>>> the message when hwdom does not have console focus.
>>>
>>> [1] https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2412121655360.463523@ubuntu-linux-20-04-desktop/
>>> Signed-off-by: Denis Mukhin 
>>> ---
>>> Changes since v1:
>>> - dropped change for debug port and for HYPERVISOR_console_io hypercall
>>
>> Yet then what about ...
>>
>>> --- 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);
>>
>> ... this dropping of XENLOG_G_DEBUG? In fact I'd have expected such to
>> be _added_ where presently missing.
> 
> vUART is a debugging facility. This flavor of UART is specifically for guest OS
> early boot debugging.
> I think it is not desirable to potentially lose guest messages while doing such
> early guest OS boot debugging.

That is the host admin's decision, not a policy we should enforce.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 07:12:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 07:12:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008004.1387210 (Exim 4.92)
	(envelope-from )
	id 1uNRG4-0007L0-50; Fri, 06 Jun 2025 07:12:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008004.1387210; Fri, 06 Jun 2025 07:12:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNRG4-0007Kr-26; Fri, 06 Jun 2025 07:12:56 +0000
Received: by outflank-mailman (input) for mailman id 1008004;
 Fri, 06 Jun 2025 07:12: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 1uNRG3-0007K6-6M
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 07:12:55 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a95a309c-42a5-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 09:12:52 +0200 (CEST)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 (Authenticated sender: nicola)
 by support.bugseng.com (Postfix) with ESMTPA id 918824EE7C3E;
 Fri,  6 Jun 2025 09:12:52 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a95a309c-42a5-11f0-b894-0df219b8e170
Authentication-Results: bugseng.com; arc=none smtp.remote-ip=162.55.131.47
ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1749193972;
	b=KEuBOrWrt8hxb4KviAmQMkmbOAYfrWVBihPQKiE4Z6vYZLFCniY3e6gYoBFEEkssDtsz
	 qanDT/xJDub4NiiClVDsHe5v5JrgMZGPK8GjoOr39aGvR4SFKiMhXTr64TfcbJHXvsKRm
	 7omy4MH8p/Sc/K0LuUQscORpxMKGEjo/gP49IFZN+1Jn44eWeGggmKJmmQbI800kSrLv2
	 9/Ah8ZQozM35VdHD4dpB1WQ46xBjHVjDN5q6bGpD+qG3RjIA4H+3ADydZBGgjqYzkbtoa
	 +d4FZ3x6FnFR3a21w20lbbqdax7bge3t4e0kCpdFYhQboiFHh6arLs2n7i032DTrgvxsH
	 Bp4zm5upq3ANcgVlrpLQ4+dVe+g5S9GKpQdmu2Z7yLRSChuSGQAQ+YXcmGJBakBEs+Unw
	 AX7Onzf1O0UVIg0lbPyvSyhXimKCT61oQZYLmZMhmcW0HHl4/HS4bmm1Z9pgvR4KPYsvA
	 InIJ8y4fpBnBte7D4IuyGc/nk3cvHdGoF7yZDNQYSD5Sx39RJTi1v6DoFsAR4crl2eut4
	 L59WiCRIjZA7k86xmrGeQhf+dRvO8GM4pqMURf+h94EWztdeIDDbs9IZFaO7rJEufhNkG
	 Rr8F/3J/BBVt2lkNQbNKplXF1V0MEq37fpyVBsrC4e6FxVkZjWUNWG4bqBL3nJE=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1749193972;
	h=DKIM-Signature:MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:
	 References:Message-ID:X-Sender:Organization:Content-Type:
	 Content-Transfer-Encoding;
	bh=8XlTGpk6rzDC9YecCj+wib31GFHYBlMi6psmQaX3a3A=;
	b=IAwwlNB7U6/yb08y8pVNMcP5IfonrVuB9NoD4rMyn525y/Mvh4LQExN92gFNaQgnapiA
	 12+Sfr8RBVGdXGBRKx+kq76SYyZlICZ2NGlZDaqE+VYdvzCKXmYAtF8rCp0jvQiZCfTym
	 AyFv6tsSbdLQZxZfRfBbgS5IRoc3xRnnFs4BTxfVYABqVYOl5BoQuMszF85ISFwj/P55h
	 sx/D8lEdKhdI4hrlRB+lnNujBuvHx+DVXCYoZ/dhhZ/Uf/LBNrK7YkUDYY8LuSur8Q+a4
	 f+1t5vXiYqZWvhuJERmTNLZ4kkIbba+kPUxSI8fZ2G8Mt0sDdInsJQ9kIR2xHwMS6PNbS
	 PRpl0c1vPE8BuylcgBHC660Dh1hBDyb/9cLo2mf8k3a3OdaVKXdrXLREx10glzYaG5rgg
	 TYXEFCC2/teOG3eRyRpAzLOsxUc7TDPxWisZup+pGnbX5o1bzkS0ZZNAWujm9L1JRpjVF
	 03dxvfkfQ4Q4TepvSltFY0pHmSUOzKxy7CbaGaHtnIuTQjlAtxFtZskesou/QrJrwy2QO
	 zgy3WMqUMpuGc+zTA4mCbmhWY8ljy5PJIa/rXALxV9/urCTDyPbKnn7xBhIQN+H1zOHTh
	 0LNOrYT59fQ20k6HguP5l8KjfNu5VKz+pHRQYzdGbMeFGLbiOhEB2rUzI3JdsrM=
ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1749193972; bh=MEIswzf9AbMH3RMOi3FfrqAXmVJCATQH/G9GbmTX6tw=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=QfDQXTEVnPG5O4XNPs9ZtjaDCP2BxSUEJ/Idh1RJcksDCQi0GpdzCjXjI9E/ZIL/Y
	 SHXLHKy/hokTl8AsExks8NB6J9h1VcnZQcOWumTDc7vJfp+xO0Tn/AqzwP2X57BRYc
	 CSEGkHRTFvNLt6lS8BDXlPnMXvltcFtnpIkHvPMmEpjxgV2x9Gs9Fd2wIACQXgomMS
	 yxRBh8+hoKiPzI8jzOxsEFegAaeCw5Q7suFG0V9HwBBbZXEgkKykEsUGM7cTMp4E4F
	 Uv7e9TJLoWXP5O8qEpHk+M8EpzqWFrx8b3a4vA+iCbUetutN1+2oJULK1YbVldXnkd
	 H+bngwkfX3Xrg==
MIME-Version: 1.0
Date: Fri, 06 Jun 2025 09:12:52 +0200
From: Nicola Vetrini 
To: Stefano Stabellini 
Cc: Jan Beulich , Stefano Stabellini
 , Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alessandro
 Zucchelli ,
 xen-devel@lists.xenproject.org, federico.serafini@bugseng.com
Subject: Re: [PATCH] x86: remove memcmp calls non-compliant with Rule 21.16.
In-Reply-To: 
References: <20250604233537.2892206-1-stefano.stabellini@amd.com>
 
 
Message-ID: <13ad335c1868bcc02e2dc0a8da521f6d@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 2025-06-06 01:39, Stefano Stabellini wrote:
> On Thu, 5 Jun 2025, Jan Beulich wrote:
>> On 05.06.2025 01:35, Stefano Stabellini wrote:
>> > From: Alessandro Zucchelli 
>> >
>> > MISRA C Rule 21.16 states the following: "The pointer arguments to
>> > the Standard Library function `memcmp' shall point to either a pointer
>> > type, an essentially signed type, an essentially unsigned type, an
>> > essentially Boolean type or an essentially enum type".
>> >
>> > Comparing string literals with char arrays is more appropriately
>> > done via strncmp.
>> 
>> More appropriately - maybe. Yet less efficiently. IOW I view ...
>> 
>> > No functional change.
>> 
>> ... this as at the edge of not being true.
>> 

Then our views of what constitutes a functional change clearly differ. 
If you are concerned about performance the patch may be dropped, but 
then does it make sense to apply the rule at all? An alternative 
suggestion might be that of deviating the rule for memcmp applied to 
string literals in either the first or second argument, or both).

>> > Signed-off-by: Alessandro Zucchelli 
>> 
>> Missing your own S-o-b.
>> 
>> Also (nit) may I ask that you drop the full stop from the patch 
>> subject?
> 
> I'll add the S-o-B and fix the subject
> 
> 
>> > --- a/xen/arch/x86/dmi_scan.c
>> > +++ b/xen/arch/x86/dmi_scan.c
>> > @@ -233,7 +233,7 @@ void __init dmi_efi_get_table(const void *smbios, const void *smbios3)
>> >  	const struct smbios_eps *eps = smbios;
>> >  	const struct smbios3_eps *eps3 = smbios3;
>> >
>> > -	if (eps3 && memcmp(eps3->anchor, "_SM3_", 5) == 0 &&
>> > +	if (eps3 && strncmp(eps3->anchor, "_SM3_", 5) == 0 &&
>> 
>> Unlike the last example given in the doc, this does not pose the risk 
>> of
>> false "not equal" returns. Considering there's no example there 
>> exactly
>> matching this situation, I'm not convinced a change is actually 
>> needed.
>> (Applies to all other changes here, too.)
> 
> If we consider string literals "pointer types", then I think you are
> right that this would fall under what is permitted by 21.16. Nicola,
> what do you think?
> 

While I agree that the result of the comparison is correct either way in 
these cases, the rule is written to be simple to apply (i.e., not 
limited only to those cases that may differ), and in particular in the 
rationale it is indicated that using memcmp to compare string *may* 
indicate a mistake. As written above, deviating the string literal 
comparisons is an option, which can be justified with efficiency 
concerns, but it goes a bit against the rationale of the rule itself.

> 
>> > @@ -302,7 +302,7 @@ const char *__init dmi_get_table(paddr_t *base, u32 *len)
>> >  				continue;
>> >  			memcpy_fromio(&eps.dmi + 1, q + sizeof(eps.dmi),
>> >  			              sizeof(eps.smbios3) - sizeof(eps.dmi));
>> > -			if (!memcmp(eps.smbios3.anchor, "_SM3_", 5) &&
>> > +			if (strncmp(eps.smbios3.anchor, "_SM3_", 5) == 0 &&
>> 
>> Here and below there's a further (style) change, moving from ! to "== 
>> 0"
>> (or from implicit boolean to "!= 0"). As we use the original style in 
>> many
>> other places, some justification for this extra change would be needed 
>> in
>> the description (or these extra adjustments be dropped).
> 
> The adjustments can be dropped
> 
> 
>> > @@ -720,10 +720,10 @@ static void __init efi_check_config(void)
>> >  	__set_fixmap(FIX_EFI_MPF, PFN_DOWN(efi.mps), __PAGE_HYPERVISOR);
>> >  	mpf = fix_to_virt(FIX_EFI_MPF) + ((long)efi.mps & (PAGE_SIZE-1));
>> >
>> > -	if (memcmp(mpf->mpf_signature, "_MP_", 4) == 0 &&
>> > -	    mpf->mpf_length == 1 &&
>> > -	    mpf_checksum((void *)mpf, 16) &&
>> > -	    (mpf->mpf_specification == 1 || mpf->mpf_specification == 4)) {
>> > +	if (strncmp(mpf->mpf_signature, "_MP_", 4) == 0 &&
>> > +            mpf->mpf_length == 1 &&
>> > +            mpf_checksum((void *)mpf, 16) &&
>> > +            (mpf->mpf_specification == 1 || mpf->mpf_specification == 4)) {
>> >  		smp_found_config = true;
>> >  		printk(KERN_INFO "SMP MP-table at %08lx\n", efi.mps);
>> >  		mpf_found = mpf;
>> 
>> There are extra (indentation) changes here which ought to be dropped.
> 
> Yes

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 07:18:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 07:18:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008013.1387219 (Exim 4.92)
	(envelope-from )
	id 1uNRLo-000862-Ov; Fri, 06 Jun 2025 07:18:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008013.1387219; Fri, 06 Jun 2025 07:18: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 1uNRLo-00085v-MH; Fri, 06 Jun 2025 07:18:52 +0000
Received: by outflank-mailman (input) for mailman id 1008013;
 Fri, 06 Jun 2025 07:18: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 1uNRLm-00085p-Lo
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 07:18:51 +0000
Received: from mail-10628.protonmail.ch (mail-10628.protonmail.ch
 [79.135.106.28]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 776363b4-42a6-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 09:18:38 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 776363b4-42a6-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1749194317; x=1749453517;
	bh=kHTft95SokdX/vhaJIbupMclTjGrHlhG6AlJxlMLmCU=;
	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=FRjisVGZlP4pXB4m8+8/B+lx/AjxEXr7LI7NNeKwlcgCy9qkB6P7K+/zaOh7+yRlu
	 +P7UugF0mCcfwimCO8alfBC+knuH5d1fuXmTn4ethRbrxoau7Z0r5vSZ/tAsMpnEN2
	 TMDdajpbeRRZ/hHa1GXhbY0iun6q+2XUB8cy6EbAIto7Q/HjvK7gykAinNMm75pYX0
	 2mBvjFGMS6PynbSjF80nJ17LoBtfQaEPx8PXJbZNJITHkWF2kZelzQ1C7ygMSGQxjL
	 uop/2/J+E5q7F78Nu/UJ61iUq4oUbOtXGDgBOAbrjjLZii0zsnfmg1+0YYk21FVntL
	 oNj9OVaDJv7Tw==
Date: Fri, 06 Jun 2025 07:18:32 +0000
To: =?utf-8?Q?Roger_Pau_Monn=C3=A9?= 
From: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com
Subject: Re: [PATCH v5 1/2] xen/domain: introduce common hardware emulation flags
Message-ID: 
In-Reply-To: 
References: <20250602191717.148361-1-dmukhin@ford.com> <20250602191717.148361-2-dmukhin@ford.com> 
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 32b51bb41785c6dabfc55254e3f5dacc563899a1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 05, 2025 at 11:08:07AM +0200, Roger Pau Monn=C3=A9 wrote:
> On Mon, Jun 02, 2025 at 07:17:30PM +0000, dmkhn@proton.me wrote:
> > From: Denis Mukhin 
> >
> > Add common emulation_flags for configuring domain emulation features.
> >
> > Print d->emulation_flags from 'q' keyhandler for better traceability wh=
ile
> > debugging.
> >
> > Signed-off-by: Denis Mukhin 
> > Reviewed-by: Stefano Stabellini 
> > ---
> > Changes since v4:
> > - kept Stefano's R-b
> > ---
> >  xen/arch/x86/domain.c             |  2 +-
> >  xen/arch/x86/domctl.c             |  2 +-
> >  xen/arch/x86/include/asm/domain.h | 25 +++++++++++--------------
> >  xen/common/keyhandler.c           |  1 +
> >  xen/include/xen/sched.h           |  2 ++
> >  5 files changed, 16 insertions(+), 16 deletions(-)
> >
> > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> > index 7536b6c871..0363ccb384 100644
> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -831,7 +831,7 @@ int arch_domain_create(struct domain *d,
> >                 emflags);
> >          return -EOPNOTSUPP;
> >      }
> > -    d->arch.emulation_flags =3D emflags;
> > +    d->emulation_flags =3D emflags;
> >
> >  #ifdef CONFIG_PV32
> >      HYPERVISOR_COMPAT_VIRT_START(d) =3D
> > diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
> > index 3044f706de..37d848f683 100644
> > --- a/xen/arch/x86/domctl.c
> > +++ b/xen/arch/x86/domctl.c
> > @@ -144,7 +144,7 @@ void arch_get_domain_info(const struct domain *d,
> >      if ( paging_mode_hap(d) )
> >          info->flags |=3D XEN_DOMINF_hap;
> >
> > -    info->arch_config.emulation_flags =3D d->arch.emulation_flags;
> > +    info->arch_config.emulation_flags =3D d->emulation_flags;
> >      info->gpaddr_bits =3D hap_paddr_bits;
> >  }
> >
> > diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/a=
sm/domain.h
> > index 8c0dea12a5..eafd5cfc90 100644
> > --- a/xen/arch/x86/include/asm/domain.h
> > +++ b/xen/arch/x86/include/asm/domain.h
> > @@ -455,9 +455,6 @@ struct arch_domain
> >
> >      /* Don't unconditionally inject #GP for unhandled MSRs. */
> >      bool msr_relaxed;
> > -
> > -    /* Emulated devices enabled bitmap. */
> > -    uint32_t emulation_flags;
> >  } __cacheline_aligned;
> >
> >  #ifdef CONFIG_HVM
> > @@ -494,17 +491,17 @@ struct arch_domain
> >                                   X86_EMU_PIT | X86_EMU_USE_PIRQ |     =
  \
> >                                   X86_EMU_VPCI)
> >
> > -#define has_vlapic(d)      (!!((d)->arch.emulation_flags & X86_EMU_LAP=
IC))
> > -#define has_vhpet(d)       (!!((d)->arch.emulation_flags & X86_EMU_HPE=
T))
> > -#define has_vpm(d)         (!!((d)->arch.emulation_flags & X86_EMU_PM)=
)
> > -#define has_vrtc(d)        (!!((d)->arch.emulation_flags & X86_EMU_RTC=
))
> > -#define has_vioapic(d)     (!!((d)->arch.emulation_flags & X86_EMU_IOA=
PIC))
> > -#define has_vpic(d)        (!!((d)->arch.emulation_flags & X86_EMU_PIC=
))
> > -#define has_vvga(d)        (!!((d)->arch.emulation_flags & X86_EMU_VGA=
))
> > -#define has_viommu(d)      (!!((d)->arch.emulation_flags & X86_EMU_IOM=
MU))
> > -#define has_vpit(d)        (!!((d)->arch.emulation_flags & X86_EMU_PIT=
))
> > -#define has_pirq(d)        (!!((d)->arch.emulation_flags & X86_EMU_USE=
_PIRQ))
> > -#define has_vpci(d)        (!!((d)->arch.emulation_flags & X86_EMU_VPC=
I))
> > +#define has_vlapic(d)      (!!((d)->emulation_flags & X86_EMU_LAPIC))
> > +#define has_vhpet(d)       (!!((d)->emulation_flags & X86_EMU_HPET))
> > +#define has_vpm(d)         (!!((d)->emulation_flags & X86_EMU_PM))
> > +#define has_vrtc(d)        (!!((d)->emulation_flags & X86_EMU_RTC))
> > +#define has_vioapic(d)     (!!((d)->emulation_flags & X86_EMU_IOAPIC))
> > +#define has_vpic(d)        (!!((d)->emulation_flags & X86_EMU_PIC))
> > +#define has_vvga(d)        (!!((d)->emulation_flags & X86_EMU_VGA))
> > +#define has_viommu(d)      (!!((d)->emulation_flags & X86_EMU_IOMMU))
> > +#define has_vpit(d)        (!!((d)->emulation_flags & X86_EMU_PIT))
> > +#define has_pirq(d)        (!!((d)->emulation_flags & X86_EMU_USE_PIRQ=
))
> > +#define has_vpci(d)        (!!((d)->emulation_flags & X86_EMU_VPCI))
> >
> >  #define gdt_ldt_pt_idx(v) \
> >        ((v)->vcpu_id >> (PAGETABLE_ORDER - GDT_LDT_VCPU_SHIFT))
> > diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
> > index 0bb842ec00..cd731452ba 100644
> > --- a/xen/common/keyhandler.c
> > +++ b/xen/common/keyhandler.c
> > @@ -306,6 +306,7 @@ static void cf_check dump_domains(unsigned char key=
)
> >              if ( test_bit(i, &d->watchdog_inuse_map) )
> >                  printk("    watchdog %d expires in %d seconds\n",
> >                         i, (u32)((d->watchdog_timer[i].expires - NOW())=
 >> 30));
> > +        printk("    emulation_flags %#x\n", d->emulation_flags);
>=20
> No strong opinion, but my preference would be to print those as
> strings if possible, ie:
>=20
> printk("    emulation_flags: %s%s%s...(%#x)\n",
>        !d->emulation_flags ? "none " : "",
>        has_vlapic(d) ? "vlapic " : "",
>        has_vhpet(d) ? "hpet " : "",
>        ...,
>        d->emulation_flags);

Thanks for suggestion.

There was the same feedback already:
  https://lore.kernel.org/xen-devel/aDd9Z3eY3RQgTTdy@kraken/

Is it OK to address it in the follow on change for both Arm and x86?

>=20
> Thanks, Roger.



From xen-devel-bounces@lists.xenproject.org Fri Jun 06 07:22:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 07:22:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008019.1387229 (Exim 4.92)
	(envelope-from )
	id 1uNRPQ-0001VM-74; Fri, 06 Jun 2025 07:22:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008019.1387229; Fri, 06 Jun 2025 07: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 1uNRPQ-0001VF-4J; Fri, 06 Jun 2025 07:22:36 +0000
Received: by outflank-mailman (input) for mailman id 1008019;
 Fri, 06 Jun 2025 07: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 1uNRPO-0001V9-Np
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 07:22:34 +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 034a5696-42a7-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 09:22:33 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a507e88b0aso1651589f8f.1
 for ; Fri, 06 Jun 2025 00:22:33 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2360309266bsm6588095ad.74.2025.06.06.00.22.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 06 Jun 2025 00:22:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 034a5696-42a7-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749194552; x=1749799352; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=7ntZFmKiwYH95etsfz9OpmHkTVQttLVLgGPMkYGx32s=;
        b=Cieza3+td0sVzYCAJrolj4+ke6VjqwvVgCW1VEph56P7WiycssDmDBPa0Ps6Ap/eHu
         MszQcz00KppE28NMBTKIHIC79cQlOmdPtbcEccT0EQ0CLywJNc3p3j4IQIXH6MSjhKUz
         2uOZLB0s+znrdKwCFu5kDm7X3YAJxWYtqs0/g4JJi6LtknVYsLaxGvr99JVqhXkyfH+0
         0413Njv+vqWzD3CjdPwNCTmFn6CZCjQwBn89OZk22WVsUvcWp0/E/kbBTt4NccnMPgj7
         +jdWEg22d0hNyLBRt6U4EcmI+Dx6uw2YJY/+GgH8zJgp7oquleDm9aH5wCbjc1XlClHU
         RIlw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749194552; x=1749799352;
        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=7ntZFmKiwYH95etsfz9OpmHkTVQttLVLgGPMkYGx32s=;
        b=bBYxL0c4a63zsXzNP7V7vn4otukgoLvVpn9YgSf46Bhx10J/uZ5b2sm9lEge0tL8QO
         U/CCfWSl8SEw5vqr0eocTtw+KGuQDHxOHmLlDxPhL9aKU0z5TCNJfQ2ykZqdahWbUhS+
         Ae2Maa4DzC8U2qS/Zq9+lIVXFkY44ewUTYpqsFbDGxDEJMEuOOmIWHuWwt5GoDUC87C8
         dtSVWoSnBurf/dBSW6dzWRp9SsMzEy012N5HVTLU23GE4ugD2XIWEiafNiMT4+jKXEx9
         iPVINS1K4EK7DVXMSIxM3Bo7GVxIGzTf0NvNz04xmTqVbfTWpGUGuOGOl/rfQVErl8zP
         DE/w==
X-Forwarded-Encrypted: i=1; AJvYcCWlYELDrh4gBH9k9gAJzfhOdRTQcVmy1OES1PsgBTupBmZKr3OM6wO0rwq8Uj6J+r0oGIoe3M1cXdY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzyBtdpYelADVxJ7EZFRRd0dvVsrKvvHaBZ7YjNwk1v1RehDd1k
	M6IGo28/rUoiDC35y80De2MKe5tCXpQ0yNObsH+aUW++uvE83pB/bGlwsgOVTbhHOQ==
X-Gm-Gg: ASbGncveTRrco4eJLRbJ73W6rDsSY1EstnrBzNKTjybKCgavREl9+zz6OBBVl0i+5Ff
	VqHqbwcPy5fCZ1NwlghKOUTQDNjyg0K/WFm8yQDWgmRJLsrneX2xzaLkNR2RDErVO1G4Wzwi1nV
	d1rHD36wwjHBsG5M66lniUMW5k/+CCjaF+Onj4ZicSUr499OuqZNp1ERcnWhmnpn+UMBzvIHhe0
	9QQ2jYUJhulykBfSWSJ6XAwitjEpEbp7YI7jDK0Rgi6+sp4s4x/6BZUv2XAsa07mRGxlj61BUcx
	tEcwnJTR3wxqGneodHTGeoiEYcw0CvuNYice7H5rutfRg38JzVdwj4O+h+Mnjui1yKXw7GOwYvZ
	eZ6Hperxlqu8UjNV3deGYeXMrikp6B8mAmFNhAL5PK35OhtcuzR5Tpy2grw==
X-Google-Smtp-Source: AGHT+IEPunL/Z6eliYTF1BSH1171nPVhYPNEsdmzlYZdkbO8omc4VYwOyuMNPLtVsRDJoY8ObzXQDQ==
X-Received: by 2002:a05:6000:4023:b0:3a4:e68e:d33c with SMTP id ffacd0b85a97d-3a531ab7294mr1612704f8f.47.1749194552533;
        Fri, 06 Jun 2025 00:22:32 -0700 (PDT)
Message-ID: <6eaf2b27-969a-4326-9726-8b6e0994e006@suse.com>
Date: Fri, 6 Jun 2025 09:22:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/3] x86/EFI: Fix detection of buildid
To: Andrew Cooper 
Cc: Ross Lagerwall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 "Daniel P . Smith" ,
 Xen-devel 
References: <20250605111638.2869914-1-andrew.cooper3@citrix.com>
 <20250605111638.2869914-2-andrew.cooper3@citrix.com>
 <0a314400-126a-4c2a-b36c-dda61bb0b751@suse.com>
 
 <4d1f1b70-e309-453b-bae6-e066d49a417a@suse.com>
 <9200277c-aa8e-4fd9-ab6a-f9e106114f54@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: <9200277c-aa8e-4fd9-ab6a-f9e106114f54@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 05.06.2025 19:01, Andrew Cooper wrote:
> On 05/06/2025 2:24 pm, Jan Beulich wrote:
>> On 05.06.2025 14:14, Andrew Cooper wrote:
>>> On 05/06/2025 1:02 pm, Jan Beulich wrote:
>>>> On 05.06.2025 13:16, Andrew Cooper wrote:
>>> This really is a property of being a PE32+ binary, and nothing to do
>>> with EFI.
>> Which still can be checked for without having this code path being taken
>> for xen.gz, too: You could e.g. check for &efi > &_end. That's firmly an
>> image property (yet I expect you're going to sigh about yet another hack).
> 
> It's all hacks, but no.
> 
> I'm amazed MISRA hasn't spotted that we've got a global `struct efi
> efi;` and a label named efi, creating an alias for the object with it
> out of bounds in the compiled image.  But even then, it's based on
> XEN_BUILD_EFI not XEN_BUILD_PE and does not distinguish the property
> that matters.

The use of XEN_BUILD_EFI in the linker script should have been switched
to XEN_BUILD_PE when the split was introduced.

> But the argument I'm going to make this this:  Why do you want a check,
> even if you can find a correct one (and as said before, I cannot)?
> 
> This function is run exactly once.  We've excluded "nothing given by the
> toolchain", and excluded "what the toolchain gave us was not the
> expected ELF note".  The only thing left (modulo toolchain bugs) is the
> CodeView region, and if it's not a valid CodeView region then we've
> wasted a handful of cycles.

Two reasons: Having code which cannot possibly do anything useful isn't
good. Misra calls the latest the body of the inner if() "unreachable code"
and objects to the presence of such in a build. (I'm pretty sure Eclair
wouldn't spot it, but that doesn't eliminate this being a violation of
the respective rule.)

And then, based on your reasoning above, why don't you also drop the
#ifdef CONFIG_X86?

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 07:23:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 07:23:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008028.1387239 (Exim 4.92)
	(envelope-from )
	id 1uNRQa-00023K-IC; Fri, 06 Jun 2025 07:23:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008028.1387239; Fri, 06 Jun 2025 07: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 1uNRQa-00023D-Fc; Fri, 06 Jun 2025 07:23:48 +0000
Received: by outflank-mailman (input) for mailman id 1008028;
 Fri, 06 Jun 2025 07:23: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 1uNRQZ-000236-99
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 07:23:47 +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 2e0a816a-42a7-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 09:23:44 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3a375888297so1144088f8f.1
 for ; Fri, 06 Jun 2025 00:23:45 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3134b05c4c0sm680810a91.19.2025.06.06.00.23.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 06 Jun 2025 00:23:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2e0a816a-42a7-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749194625; x=1749799425; 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=KariCyR0dGZDPIE40ZrelzTAXlwAXQCM1p379V0kows=;
        b=L0jO3fQtGYVgfurOrvZWmY+su/mLMvKx05L58YjrTTkvnzO0YvZciDZ9XLY1BAX4cw
         Q8O9EOEkudXJLqKzjiAfHA6maTdQh4+xBJyDhoclH8XICW+tFXNhRd8LjZZy6a4mjDto
         fyscHcIiK7jlUH3gOLXZaYrVIypNbbqZLgXMOY2MJLHLxVaq0qAfbRnT3l/FzMkaBPLx
         +2u+0RechoP+WW4Y3jUG4mW8ylz6VbE3IuuZBxvNfvboxMTDNuRl56SJqiS0uWpJcb0U
         Rm/r+2S2M/xRfFUDEICQyoK3JIIHW6pXGoCSrFWxn6T++ZV5nuYMHmyRCBqT/h9lXUn3
         QevA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749194625; x=1749799425;
        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=KariCyR0dGZDPIE40ZrelzTAXlwAXQCM1p379V0kows=;
        b=iY8kfQa7j4YJqPRctb7kxfTP+4JtpxX5LuaLH0Te9H5Uhcgt155G+D8JRrLOQJ1JAA
         ZZLo0lqbsxAA1IySNnhoobpi+c5AlFUlqo9YRyqu3H2D4q+oPZ9fAPAuXv1CMcg0Tdl4
         6vHZyTP4uVYSPU0QY8/BzqYE/JuHHaxXlD8Iv5dZ/NOcfL9Yzm00lFGQi4S0RBSxTBOB
         wXVRyadk8SlyLbHJjsV2OeuVd0d5BfHuxbyT/M0NgvQWEiY66REFQ79fEd3BBkN4ITqE
         dcOdGuXRd75pz4NGsrrhJxQjFSK3OLrDrlCIQwdLD6iOq7rlsOAiNB26iO1ryUb28q1m
         mjYA==
X-Forwarded-Encrypted: i=1; AJvYcCVW67sltwnCywezME2Ut62IjvTFGnC916ln9pEYst8LfQ9jQOx6QJUyDvxQnVhC4hKEJ/5sLlVH5Ww=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxy2S6HcMEjuIHq0nz9+SY4A61IU1npCz5Nb7tmm3Y3wwa13++4
	F6NG47H/hVUcYmo7zUqpHBwwSWP/X5li97RpCM9zymOgwlDMiRxrFI6Jb9Z/zKzxqg==
X-Gm-Gg: ASbGncuYaaKI9ESigMKxuRr2kcuMTFfgPDkkoI7x2RJsaSPs+2iBaN7wY9tMf8AWIjK
	6SISAqiGMwX0ltwPcB7iNtMwwUP7Z+cXk06UEUHK7AXdNr+EXXYgBfBs/XFEcMA6z0uLGe42GJa
	D3KcJ4foMxb/Vpt8nXM90zheoEB74qiPrHOaW2KgFB1xphF48fzMOlVgtbdfAfBa6swFsLwOuko
	YizJmpcR+cwcpuh8vtOQGJZbgAwkKi6gi8erRRDIAkhh62C/E9vU4CFpp3VvL0YaCmsxbuzCa70
	brxZ5EjjUTEfQlr4vyxRFpPOdcHXtc4Y4nsshn+L22CkzMcyPHq+bDuphOFj9CTPG89JMb2N/Dt
	oF/wogbsUqdbSSMHMdi5lg+zkyftA9NddRsFv
X-Google-Smtp-Source: AGHT+IGv6Z7GJARK7IlmLqRuy9scT1aAnFqw0/ILl3vuL2nuWsB3WAd7pInbSJ7D5d/hvMGyieqAnA==
X-Received: by 2002:a05:6000:1acf:b0:3a4:eb7a:2ccb with SMTP id ffacd0b85a97d-3a526ddbaeamr5749196f8f.16.1749194624752;
        Fri, 06 Jun 2025 00:23:44 -0700 (PDT)
Message-ID: 
Date: Fri, 6 Jun 2025 09:23:36 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/3] x86/EFI: Fix detection of buildid
From: Jan Beulich 
To: Andrew Cooper 
Cc: Ross Lagerwall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 "Daniel P . Smith" ,
 Xen-devel 
References: <20250605111638.2869914-1-andrew.cooper3@citrix.com>
 <20250605111638.2869914-2-andrew.cooper3@citrix.com>
 <0a314400-126a-4c2a-b36c-dda61bb0b751@suse.com>
 
 <4d1f1b70-e309-453b-bae6-e066d49a417a@suse.com>
 <9200277c-aa8e-4fd9-ab6a-f9e106114f54@citrix.com>
 <6eaf2b27-969a-4326-9726-8b6e0994e006@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: <6eaf2b27-969a-4326-9726-8b6e0994e006@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 06.06.2025 09:22, Jan Beulich wrote:
> On 05.06.2025 19:01, Andrew Cooper wrote:
>> On 05/06/2025 2:24 pm, Jan Beulich wrote:
>>> On 05.06.2025 14:14, Andrew Cooper wrote:
>>>> On 05/06/2025 1:02 pm, Jan Beulich wrote:
>>>>> On 05.06.2025 13:16, Andrew Cooper wrote:
>>>> This really is a property of being a PE32+ binary, and nothing to do
>>>> with EFI.
>>> Which still can be checked for without having this code path being taken
>>> for xen.gz, too: You could e.g. check for &efi > &_end. That's firmly an
>>> image property (yet I expect you're going to sigh about yet another hack).
>>
>> It's all hacks, but no.
>>
>> I'm amazed MISRA hasn't spotted that we've got a global `struct efi
>> efi;` and a label named efi, creating an alias for the object with it
>> out of bounds in the compiled image.  But even then, it's based on
>> XEN_BUILD_EFI not XEN_BUILD_PE and does not distinguish the property
>> that matters.
> 
> The use of XEN_BUILD_EFI in the linker script should have been switched
> to XEN_BUILD_PE when the split was introduced.
> 
>> But the argument I'm going to make this this:  Why do you want a check,
>> even if you can find a correct one (and as said before, I cannot)?
>>
>> This function is run exactly once.  We've excluded "nothing given by the
>> toolchain", and excluded "what the toolchain gave us was not the
>> expected ELF note".  The only thing left (modulo toolchain bugs) is the
>> CodeView region, and if it's not a valid CodeView region then we've
>> wasted a handful of cycles.
> 
> Two reasons: Having code which cannot possibly do anything useful isn't
> good. Misra calls the latest the body of the inner if() "unreachable code"
> and objects to the presence of such in a build. (I'm pretty sure Eclair
> wouldn't spot it, but that doesn't eliminate this being a violation of
> the respective rule.)
> 
> And then, based on your reasoning above, why don't you also drop the
> #ifdef CONFIG_X86?

..., saying in the description "we can as well check for this uniformly"

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 07:27:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 07:27:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008034.1387249 (Exim 4.92)
	(envelope-from )
	id 1uNRTm-0002ck-VV; Fri, 06 Jun 2025 07:27:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008034.1387249; Fri, 06 Jun 2025 07:27: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 1uNRTm-0002cd-Sw; Fri, 06 Jun 2025 07:27:06 +0000
Received: by outflank-mailman (input) for mailman id 1008034;
 Fri, 06 Jun 2025 07: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 1uNRTk-0002cO-Vj
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 07:27:04 +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 a3c58f25-42a7-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 09:27:02 +0200 (CEST)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-450d668c2a1so20118905e9.0
 for ; Fri, 06 Jun 2025 00:27:02 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23603405e6esm6620405ad.170.2025.06.06.00.26.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 06 Jun 2025 00:27:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a3c58f25-42a7-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749194822; x=1749799622; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=F2PNFm1B6tEmudltOwJqkR8JnZtHtLpwvfP7Dqa3JbQ=;
        b=A9M9EEkMRCKg6RBCF1f+1Qh37ZN1rZtkf9FX/vEXf6cqSmwWVffzhueVuNB3tti9u+
         5biknl8+vfREJIKbwvTC/HzWY1vyLwwWQSnMOG1DzfqCvXc1oVwStW9sFPuL01fg2MvZ
         iWEFdD2a2DhEVxBn7iYttrmiHr51NrLaVpS1wzBjnpq3pmavvlpOVh+izkz2yPa7KPH9
         WDvgCHxbqc2txTf9gv6euipRTtlPy6qfBb4red7Wa0bnO4sSiUVuf5DA+WoqimTJDCjT
         dwGug5//CYPcPKXe3rSVzRwU9gLpG1OV9A7n3t5/vK13B2tF6GM2nsXX9A6NDWpwiZ4C
         I+5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749194822; x=1749799622;
        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=F2PNFm1B6tEmudltOwJqkR8JnZtHtLpwvfP7Dqa3JbQ=;
        b=W0gSH3ukWxFA6sBxGndnEWc+HlWg915fKq+q9gqiZkOJlXhHeD+5aoHPjXBpCWjh3G
         QcAd5Eh5PTa5PJvFabCDE6HinmJsgpZAFI4ay3w9ejheO6txCdilZWrU0b2NoAM1FhvX
         SuXzA5gTPMvSmQIVh88gzXy3pDZ6OnyfYCOuziggYZOpg0N9FBMQE8AGh/XSr2e4EF0/
         wjKWH5iTeuX2L6ykiyaNfavWQO9ExldPhK1EZYOuIbZ2UGsPp2hlEa8ZcapW5FLlhXid
         +1oLyCSGARjxPZKt1D9hDcVQUf3EBKuxKAS9IOJ3VPfYKG1pLus5KFljSQNAXuiJJdF+
         5vhQ==
X-Forwarded-Encrypted: i=1; AJvYcCXOtL2VyLy8WTR1jBjBXzBaASczUa8AjA+DVOYRKJx4Lsfyj+e8MJSio3uEEyC4pVXiYthxPEExrqo=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy+BAp9fy+0UxAo3TmxvV/4oKpTh0RX+C4nhL84EziqVBNEtInH
	dok0rOEN9AesaC9XmF+25U+HfN9I95mQvBueCsyFuts+UfhZ5ryz0neEgfOoZ7pSWQ==
X-Gm-Gg: ASbGncsyljSb/hPdoITphWI7/h9K2qKWDzpFtn9JDnCmlhzJxeQGDQIVLoS1ZlwQvfX
	pN2/KVHzHaIGX7rUCIZmDD4HkCBS9WxeygMo34YZRbcID8g1R+pc8EhRX986Fpo2J+aIv/7h+o9
	xFiIzh78OsrvhmrtstnmCtSQm0pa8rdqpt7tRYPB5qpcdYsKSKMrHb9BwwVItKdFLpRNSONPr82
	nsjCNcjW+wpGeeVDPxEh5DdCkCRI6NeBSmubT0FvjtjkQUW16+8XKoTnLWwp8M4Hi4/7La4wBbI
	o4YBgKFusa0aASesfdkDH2D5XKwmINmSbHaDm5OIBRizy0KZTDfYsPzJMz4qyM/iRxes+BkuC+2
	TtZnw42JV92YKnP+i9T9wu8+bTKv3Xxk45MkM/QEr6RpjAGY=
X-Google-Smtp-Source: AGHT+IGWZUGUQBl9TiCWlpo0ejevE5OzoxR4HkvPBDqBzXJnXnVQqQYWZzno2z0BRQ7wC+hVSFdPiA==
X-Received: by 2002:a05:6000:240a:b0:3a5:1360:6b34 with SMTP id ffacd0b85a97d-3a526dc524cmr5756747f8f.2.1749194822160;
        Fri, 06 Jun 2025 00:27:02 -0700 (PDT)
Message-ID: <20badf36-f103-48af-ac9b-7e6f331cc0ac@suse.com>
Date: Fri, 6 Jun 2025 09:26:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86: remove memcmp calls non-compliant with Rule 21.16.
To: Nicola Vetrini ,
 Stefano Stabellini 
Cc: Stefano Stabellini ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Alessandro Zucchelli ,
 xen-devel@lists.xenproject.org, federico.serafini@bugseng.com
References: <20250604233537.2892206-1-stefano.stabellini@amd.com>
 
 
 <13ad335c1868bcc02e2dc0a8da521f6d@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: <13ad335c1868bcc02e2dc0a8da521f6d@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.06.2025 09:12, Nicola Vetrini wrote:
> On 2025-06-06 01:39, Stefano Stabellini wrote:
>> On Thu, 5 Jun 2025, Jan Beulich wrote:
>>> On 05.06.2025 01:35, Stefano Stabellini wrote:
>>>> From: Alessandro Zucchelli 
>>>>
>>>> MISRA C Rule 21.16 states the following: "The pointer arguments to
>>>> the Standard Library function `memcmp' shall point to either a pointer
>>>> type, an essentially signed type, an essentially unsigned type, an
>>>> essentially Boolean type or an essentially enum type".
>>>>
>>>> Comparing string literals with char arrays is more appropriately
>>>> done via strncmp.
>>>
>>> More appropriately - maybe. Yet less efficiently. IOW I view ...
>>>
>>>> No functional change.
>>>
>>> ... this as at the edge of not being true.
>>>
> 
> Then our views of what constitutes a functional change clearly differ. 
> If you are concerned about performance the patch may be dropped, but 
> then does it make sense to apply the rule at all? An alternative 
> suggestion might be that of deviating the rule for memcmp applied to 
> string literals in either the first or second argument, or both).

FTAOD (since Stefano also said it like this) - it's not just "string
literal". The additional requirement is that the last argument passed
must equal sizeof() for the comparison to work
correctly.

Jan

>>>> Signed-off-by: Alessandro Zucchelli 
>>>
>>> Missing your own S-o-b.
>>>
>>> Also (nit) may I ask that you drop the full stop from the patch 
>>> subject?
>>
>> I'll add the S-o-B and fix the subject
>>
>>
>>>> --- a/xen/arch/x86/dmi_scan.c
>>>> +++ b/xen/arch/x86/dmi_scan.c
>>>> @@ -233,7 +233,7 @@ void __init dmi_efi_get_table(const void *smbios, const void *smbios3)
>>>>  	const struct smbios_eps *eps = smbios;
>>>>  	const struct smbios3_eps *eps3 = smbios3;
>>>>
>>>> -	if (eps3 && memcmp(eps3->anchor, "_SM3_", 5) == 0 &&
>>>> +	if (eps3 && strncmp(eps3->anchor, "_SM3_", 5) == 0 &&
>>>
>>> Unlike the last example given in the doc, this does not pose the risk 
>>> of
>>> false "not equal" returns. Considering there's no example there 
>>> exactly
>>> matching this situation, I'm not convinced a change is actually 
>>> needed.
>>> (Applies to all other changes here, too.)
>>
>> If we consider string literals "pointer types", then I think you are
>> right that this would fall under what is permitted by 21.16. Nicola,
>> what do you think?
>>
> 
> While I agree that the result of the comparison is correct either way in 
> these cases, the rule is written to be simple to apply (i.e., not 
> limited only to those cases that may differ), and in particular in the 
> rationale it is indicated that using memcmp to compare string *may* 
> indicate a mistake. As written above, deviating the string literal 
> comparisons is an option, which can be justified with efficiency 
> concerns, but it goes a bit against the rationale of the rule itself.
> 
>>
>>>> @@ -302,7 +302,7 @@ const char *__init dmi_get_table(paddr_t *base, u32 *len)
>>>>  				continue;
>>>>  			memcpy_fromio(&eps.dmi + 1, q + sizeof(eps.dmi),
>>>>  			              sizeof(eps.smbios3) - sizeof(eps.dmi));
>>>> -			if (!memcmp(eps.smbios3.anchor, "_SM3_", 5) &&
>>>> +			if (strncmp(eps.smbios3.anchor, "_SM3_", 5) == 0 &&
>>>
>>> Here and below there's a further (style) change, moving from ! to "== 
>>> 0"
>>> (or from implicit boolean to "!= 0"). As we use the original style in 
>>> many
>>> other places, some justification for this extra change would be needed 
>>> in
>>> the description (or these extra adjustments be dropped).
>>
>> The adjustments can be dropped
>>
>>
>>>> @@ -720,10 +720,10 @@ static void __init efi_check_config(void)
>>>>  	__set_fixmap(FIX_EFI_MPF, PFN_DOWN(efi.mps), __PAGE_HYPERVISOR);
>>>>  	mpf = fix_to_virt(FIX_EFI_MPF) + ((long)efi.mps & (PAGE_SIZE-1));
>>>>
>>>> -	if (memcmp(mpf->mpf_signature, "_MP_", 4) == 0 &&
>>>> -	    mpf->mpf_length == 1 &&
>>>> -	    mpf_checksum((void *)mpf, 16) &&
>>>> -	    (mpf->mpf_specification == 1 || mpf->mpf_specification == 4)) {
>>>> +	if (strncmp(mpf->mpf_signature, "_MP_", 4) == 0 &&
>>>> +            mpf->mpf_length == 1 &&
>>>> +            mpf_checksum((void *)mpf, 16) &&
>>>> +            (mpf->mpf_specification == 1 || mpf->mpf_specification == 4)) {
>>>>  		smp_found_config = true;
>>>>  		printk(KERN_INFO "SMP MP-table at %08lx\n", efi.mps);
>>>>  		mpf_found = mpf;
>>>
>>> There are extra (indentation) changes here which ought to be dropped.
>>
>> Yes
> 



From xen-devel-bounces@lists.xenproject.org Fri Jun 06 07:33:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 07:33:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008040.1387261 (Exim 4.92)
	(envelope-from )
	id 1uNRZR-0004aK-Jm; Fri, 06 Jun 2025 07:32:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008040.1387261; Fri, 06 Jun 2025 07: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 1uNRZR-0004aD-F7; Fri, 06 Jun 2025 07:32:57 +0000
Received: by outflank-mailman (input) for mailman id 1008040;
 Fri, 06 Jun 2025 07:32: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 1uNRZP-0004a7-So
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 07:32:55 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 74c796d8-42a8-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 09:32:53 +0200 (CEST)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 (Authenticated sender: nicola)
 by support.bugseng.com (Postfix) with ESMTPA id 9C5024EE7C3E;
 Fri,  6 Jun 2025 09:32:52 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 74c796d8-42a8-11f0-b894-0df219b8e170
Authentication-Results: bugseng.com; arc=none smtp.remote-ip=162.55.131.47
ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1749195172;
	b=OjcHRYvUB2s1PuOMSOma4wzlzxwgkam1pXi3/uhpybt/wG3KIU6cWC9Ey0blJYeJ4zw3
	 HtZk72AzWvsBozyrkHO8aN8fkb4d3GY5xCrEeAK+omqu2/5tc8qgc/G+lW/EDhlcVCD8D
	 ZO6NoconcRMJNDO/vnhy8IIsBAXw2fDqn7H2MwgRFTdGt6zRxrL7hRXa0xX0wS7lVMD+U
	 qOpHS2gfikqm9y69+puBT5Hl4Deo9BcVz5SFA1EqTe5eJqDt79pfFn3Nl6lItEtwlglKM
	 qtvGIJP2hpwrYjL8bKV5e+LAUw5n9o4RUdP7dGJVuHlL2oSBexxtIV32nnE6WsMZ5H9wq
	 ct8l23CADPQT82WoJLa6T6kg3e4zCEZULfbZoMbj7KeBGS41drnTJhDvClfgppJW1OL/5
	 gmB/jzVaKOz8/x4nG2JpAOm1FlGiRCUck7585Bh7AcJCoOqfALiYbF/bUvQcoDIPxnNmW
	 k29ThVtDDj8V2A8mfWED5QItZbcI6nWlDUQGzu4zLPUfBCO7dsH9hZUJ+12REwYL3xOv9
	 lTTbsDTbRM3oCB2DXqAKonsMsMYeqpoi1DgpoP3PeKCnuj1PHOPhcn3dawRVjz0dYkAtQ
	 F1j6XlwvyFcr/UhtCscDDvA9tUWYbK2FVAhhtFmvmdLQC8VL9jv3ZHxXyR/GIRw=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1749195172;
	h=DKIM-Signature:MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:
	 References:Message-ID:X-Sender:Organization:Content-Type:
	 Content-Transfer-Encoding;
	bh=HgPNedsYlwbOc7cUQmy6ljCINsFGRyE9RhUOFRSvwDE=;
	b=rayagchkWZa5wJp/ziT8Wd069P2HYSBQdZzEUwyzUDmHcYLvne/jYeXUE4SepzCzzQlC
	 /g2WH5KDgCTiuXUkpXajOa108jQ0Q/CDwKRfxXsn/BIotPEazE5cV4JIA/BsffWcSKNzT
	 14//7y2IzyafGMNPUJyKMxRotxjp8TgPkwP6SoVG4AAnsAYN/q2CVkGO3me3TpoDMeHsQ
	 Q9Ms6sKlkgLSbcqaTZphB5NMYg/sANp9k9cvpqCbsJeyaeoyS0pUOb4iEo7mgslnXZOuL
	 HV3f49izBXYcRlivPGUFW00TWQssMiEyp1VqkIdIfyqNzimwQMwLGUaEQq6K319Cs132n
	 DBIrLSZrpLkPVU2aDJt+NNX/wezL5yahKOHuyFK1HVKFT4Z91NP7R0M/8tLyvObse+oaM
	 rlTeDXFZFTx0/Qf3gwAw+l1EkrPrf6c4hJfqiJXOxtFYVmYrXXXOLMxieNXeUu7MClGW1
	 e0HFTXRZgOs1smRY3vyzNoIPa9OciDuQhw6Jx67t92IvhdkuIdNpqv1rxXu4NHncLvVTs
	 TjCqqRBU7BD0t1A7A0Ci/RJkQKxO3wsg+BWwLccjAr8ZkyL0ihOQWmrMxwGOUot2xrovo
	 LRwDK0J4o9nO5JTYtcY3UUpGNM0zoNAkAVIKCX8oFoAWd5H1qp6Jki+5sgwyJcQ=
ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1749195172; bh=rEhwkFNAQFk8bQpiUn8z+pVnKBcVmNgI04eY5APAy4M=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=ZyZ587RkIWBZX0/gGmdSmoF3xEFjLRfhvtTezJq7KLQGrWQ2dmvCiRvfygDB81GhT
	 FY2Gj0AtNtvMIWM65Wt7AN5IzdiMSyL40ZEhxZMCZYs4XpIOBj5DcWowY4DJAJXRnJ
	 fOfoBChlZnNPncv0gVhiHsLDYGUBNv14lY0ckCcqrIlMOBXlHWZrnYi4OJvkRkBHHW
	 7Ms2S2NyW2ewaQvl0yr1CWPa86lzGzsnbQQPA5Il9yt8C+blc/GCgKlJQFdE26mu0Y
	 i0nkxh8Plnh+mBl4bglD/YuPfKHS1VRs5cWyqacEEyUVNU01xrhxY71VEcJ+0s2ZEU
	 GxeLU1AfG6WgQ==
MIME-Version: 1.0
Date: Fri, 06 Jun 2025 09:32:52 +0200
From: Nicola Vetrini 
To: Jan Beulich 
Cc: Stefano Stabellini , Stefano Stabellini
 , Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alessandro
 Zucchelli ,
 xen-devel@lists.xenproject.org, federico.serafini@bugseng.com
Subject: Re: [PATCH] x86: remove memcmp calls non-compliant with Rule 21.16.
In-Reply-To: <20badf36-f103-48af-ac9b-7e6f331cc0ac@suse.com>
References: <20250604233537.2892206-1-stefano.stabellini@amd.com>
 
 
 <13ad335c1868bcc02e2dc0a8da521f6d@bugseng.com>
 <20badf36-f103-48af-ac9b-7e6f331cc0ac@suse.com>
Message-ID: <95e51c4d5b6b016972a2198aa10b6cfc@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 2025-06-06 09:26, Jan Beulich wrote:
> On 06.06.2025 09:12, Nicola Vetrini wrote:
>> On 2025-06-06 01:39, Stefano Stabellini wrote:
>>> On Thu, 5 Jun 2025, Jan Beulich wrote:
>>>> On 05.06.2025 01:35, Stefano Stabellini wrote:
>>>>> From: Alessandro Zucchelli 
>>>>> 
>>>>> MISRA C Rule 21.16 states the following: "The pointer arguments to
>>>>> the Standard Library function `memcmp' shall point to either a 
>>>>> pointer
>>>>> type, an essentially signed type, an essentially unsigned type, an
>>>>> essentially Boolean type or an essentially enum type".
>>>>> 
>>>>> Comparing string literals with char arrays is more appropriately
>>>>> done via strncmp.
>>>> 
>>>> More appropriately - maybe. Yet less efficiently. IOW I view ...
>>>> 
>>>>> No functional change.
>>>> 
>>>> ... this as at the edge of not being true.
>>>> 
>> 
>> Then our views of what constitutes a functional change clearly differ.
>> If you are concerned about performance the patch may be dropped, but
>> then does it make sense to apply the rule at all? An alternative
>> suggestion might be that of deviating the rule for memcmp applied to
>> string literals in either the first or second argument, or both).
> 
> FTAOD (since Stefano also said it like this) - it's not just "string
> literal". The additional requirement is that the last argument passed
> must equal sizeof() for the comparison to work
> correctly.
> 
> Jan
> 

That is due to another (mandatory) rule to prevent UB: Rule 21.18 "The 
size_t argument passed to any function in  shall have an 
appropriate value", which is also true for memcmp

>>>>> Signed-off-by: Alessandro Zucchelli 
>>>>> 
>>>> 
>>>> Missing your own S-o-b.
>>>> 
>>>> Also (nit) may I ask that you drop the full stop from the patch
>>>> subject?
>>> 
>>> I'll add the S-o-B and fix the subject
>>> 
>>> 
>>>>> --- a/xen/arch/x86/dmi_scan.c
>>>>> +++ b/xen/arch/x86/dmi_scan.c
>>>>> @@ -233,7 +233,7 @@ void __init dmi_efi_get_table(const void 
>>>>> *smbios, const void *smbios3)
>>>>>  	const struct smbios_eps *eps = smbios;
>>>>>  	const struct smbios3_eps *eps3 = smbios3;
>>>>> 
>>>>> -	if (eps3 && memcmp(eps3->anchor, "_SM3_", 5) == 0 &&
>>>>> +	if (eps3 && strncmp(eps3->anchor, "_SM3_", 5) == 0 &&
>>>> 
>>>> Unlike the last example given in the doc, this does not pose the 
>>>> risk
>>>> of
>>>> false "not equal" returns. Considering there's no example there
>>>> exactly
>>>> matching this situation, I'm not convinced a change is actually
>>>> needed.
>>>> (Applies to all other changes here, too.)
>>> 
>>> If we consider string literals "pointer types", then I think you are
>>> right that this would fall under what is permitted by 21.16. Nicola,
>>> what do you think?
>>> 
>> 
>> While I agree that the result of the comparison is correct either way 
>> in
>> these cases, the rule is written to be simple to apply (i.e., not
>> limited only to those cases that may differ), and in particular in the
>> rationale it is indicated that using memcmp to compare string *may*
>> indicate a mistake. As written above, deviating the string literal
>> comparisons is an option, which can be justified with efficiency
>> concerns, but it goes a bit against the rationale of the rule itself.
>> 
>>> 
>>>>> @@ -302,7 +302,7 @@ const char *__init dmi_get_table(paddr_t *base, 
>>>>> u32 *len)
>>>>>  				continue;
>>>>>  			memcpy_fromio(&eps.dmi + 1, q + sizeof(eps.dmi),
>>>>>  			              sizeof(eps.smbios3) - sizeof(eps.dmi));
>>>>> -			if (!memcmp(eps.smbios3.anchor, "_SM3_", 5) &&
>>>>> +			if (strncmp(eps.smbios3.anchor, "_SM3_", 5) == 0 &&
>>>> 
>>>> Here and below there's a further (style) change, moving from ! to 
>>>> "==
>>>> 0"
>>>> (or from implicit boolean to "!= 0"). As we use the original style 
>>>> in
>>>> many
>>>> other places, some justification for this extra change would be 
>>>> needed
>>>> in
>>>> the description (or these extra adjustments be dropped).
>>> 
>>> The adjustments can be dropped
>>> 
>>> 
>>>>> @@ -720,10 +720,10 @@ static void __init efi_check_config(void)
>>>>>  	__set_fixmap(FIX_EFI_MPF, PFN_DOWN(efi.mps), __PAGE_HYPERVISOR);
>>>>>  	mpf = fix_to_virt(FIX_EFI_MPF) + ((long)efi.mps & (PAGE_SIZE-1));
>>>>> 
>>>>> -	if (memcmp(mpf->mpf_signature, "_MP_", 4) == 0 &&
>>>>> -	    mpf->mpf_length == 1 &&
>>>>> -	    mpf_checksum((void *)mpf, 16) &&
>>>>> -	    (mpf->mpf_specification == 1 || mpf->mpf_specification == 4)) 
>>>>> {
>>>>> +	if (strncmp(mpf->mpf_signature, "_MP_", 4) == 0 &&
>>>>> +            mpf->mpf_length == 1 &&
>>>>> +            mpf_checksum((void *)mpf, 16) &&
>>>>> +            (mpf->mpf_specification == 1 || mpf->mpf_specification 
>>>>> == 4)) {
>>>>>  		smp_found_config = true;
>>>>>  		printk(KERN_INFO "SMP MP-table at %08lx\n", efi.mps);
>>>>>  		mpf_found = mpf;
>>>> 
>>>> There are extra (indentation) changes here which ought to be 
>>>> dropped.
>>> 
>>> Yes
>> 

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 07:34:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 07:34:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008055.1387270 (Exim 4.92)
	(envelope-from )
	id 1uNRaY-00058t-11; Fri, 06 Jun 2025 07:34:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008055.1387270; Fri, 06 Jun 2025 07:34: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 1uNRaX-00058m-TH; Fri, 06 Jun 2025 07:34:05 +0000
Received: by outflank-mailman (input) for mailman id 1008055;
 Fri, 06 Jun 2025 07:34: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 1uNRaX-0004a7-Ct
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 07:34:05 +0000
Received: from mail-24416.protonmail.ch (mail-24416.protonmail.ch
 [109.224.244.16]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9cd0a1bc-42a8-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 09:34:00 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9cd0a1bc-42a8-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1749195239; x=1749454439;
	bh=0ltrY4YTx1PzxgNm8BeA4OIevlzd0Vv26Vp/6NgNERM=;
	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=QitM77XUs7G1Kanzggu+daXBgL91Jp/ZWczb4UOG20Cmo92C85TNAH3jdsd+CfEyr
	 HYqOfiklaAr/JLH8u5yNIYZfRLkRHep0JZ0/KfDIHA6i2I1YWZFpW41UkP6z2sN9Yp
	 4pK1U5uo3kpEznO0eBeH5plGQwKunAuKJhRoVtWkWShmbtv16kgg/stn5x7UEciFH6
	 JpKOt/fQQ4KIDgaoOPhWXtdlYRD4ZzfBIOoFigMRJprEtuKvVC9IUwP8iBW7DeLsmr
	 fphDLeC/BCc1G9o6NtXlnyVgPkUh3qN8c/pznW5BsNd+HoGmVAsC7NCvxSkVNkFfy6
	 IHmJOaPTv1IBw==
Date: Fri, 06 Jun 2025 07:33:53 +0000
To: Jan Beulich 
From: dmkhn@proton.me
Cc: sstabellini@kernel.org, andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, teddy.astie@vates.tech, dmukhin@ford.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v5 1/2] xen/domain: introduce common hardware emulation flags
Message-ID: 
In-Reply-To: <8412c795-610b-416e-8d22-4149d2492517@suse.com>
References: <20250602191717.148361-1-dmukhin@ford.com> <20250602191717.148361-2-dmukhin@ford.com> <093dc85d-ebf3-4982-8888-db4e7cfd0e45@suse.com>  <8412c795-610b-416e-8d22-4149d2492517@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: f8640ee5601bd53ca4592b8645f1708040af78b4
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 05, 2025 at 08:44:30AM +0200, Jan Beulich wrote:
> On 05.06.2025 03:17, dmkhn@proton.me wrote:
> > On Wed, Jun 04, 2025 at 12:36:17PM +0200, Jan Beulich wrote:
> >> On 02.06.2025 21:17, dmkhn@proton.me wrote:
> >>> From: Denis Mukhin 
> >>>
> >>> Add common emulation_flags for configuring domain emulation features.
> >>>
> >>> Print d->emulation_flags from 'q' keyhandler for better traceability =
while
> >>> debugging.
> >>>
> >>> Signed-off-by: Denis Mukhin 
> >>> Reviewed-by: Stefano Stabellini 
> >>
> >> It's not becoming clear why this would want doing, nor in how far some=
 of
> >> the bits there may gain "common" meaning, too. Imo this kind of change=
 is
> >> meaningful only in a series where later the common-ness is also used.
> >
> > I have a set of upcoming changes here:
> >   https://gitlab.com/xen-project/people/dmukhin/xen/-/tree/vuart-framew=
ork?ref_type=3Dheads
> >
> > Specifically,
> >  https://gitlab.com/xen-project/people/dmukhin/xen/-/commit/17f44d23c19=
04374963c4ec839bc8219041b5d26
> >
> > enables the use of emulation_flags on Arm.
> >
> > I can move this patch to the upcoming series, if needed, but looks like=
 it is
> > OK to have it for Arm even now.
>=20
> Prior to that series making it to a ready-to-be-committed state, it'll be
> (effectively) dead code on Arm. Which strictly speaking Misra objects to.
> I wonder if you, Stefano, considered that when giving your R-b.
>=20
> Further - what about PPC and RISC-V?

I have no problem plumbing this patch to the follow on series.
Will re-adjust.

>=20
> Jan
>=20



From xen-devel-bounces@lists.xenproject.org Fri Jun 06 07:57:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 07:57:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008063.1387280 (Exim 4.92)
	(envelope-from )
	id 1uNRww-0008Dp-Pa; Fri, 06 Jun 2025 07:57:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008063.1387280; Fri, 06 Jun 2025 07:57:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNRww-0008Di-Mt; Fri, 06 Jun 2025 07:57:14 +0000
Received: by outflank-mailman (input) for mailman id 1008063;
 Fri, 06 Jun 2025 07:57: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 1uNRwv-0008Da-VD
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 07:57:14 +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 dac4d464-42ab-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 09:57:12 +0200 (CEST)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3a510432236so1401273f8f.0
 for ; Fri, 06 Jun 2025 00:57:12 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a5324364c9sm1135469f8f.51.2025.06.06.00.57.11
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 06 Jun 2025 00:57:11 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: dac4d464-42ab-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749196632; x=1749801432; 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=x2qGQxHKxE0fltri3e56FljztxCxBXPQkvQrP4WGYKs=;
        b=SZfKFELz36g2N+eqobgaGmNJ+pSXTNleH4gQv2nKee3I7UiuXEVFp3vPTXdS4wuMEQ
         qQ8uxtxmHkpXYPgcJzwaUCpszwKeYAohX5glgx2i1wMKN8dmaaUpC1pV1D0HslToi+f6
         ZCrbRblx8X2sUAWHbXWtrgNzVQXlp+EI+Wvz0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749196632; x=1749801432;
        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=x2qGQxHKxE0fltri3e56FljztxCxBXPQkvQrP4WGYKs=;
        b=NoCe2z0ncyL4NdgzOAHZTVVm3gFaq1dG/NXFRkWNA0kJgiznkKYn5INTQsTONHYBKJ
         DZLAfBRUS9IY32dc7ssfqgVKmHOom2Liy5UTstY/Hwhpccpgs+zHnguzvIGronIUrPtn
         33yfoL1rsRSdcUjKLidQFbTD96rH2CsIdt/I13bvDzf4CZeTaJTVrZ0FqmAG281WoGBD
         fEChK1fNPU5ggnrIEpguNgfkk3LFs4Do/lTEdVvIp8+E44bTxUsGIDyh78bmyHDRttHw
         owM/xo4rCEcw+vx8uEe0lUsxEUPLnwo3Fz975moWNQ6JKn11iSCFok6iiJyd+WnYbGm/
         tzSQ==
X-Gm-Message-State: AOJu0YxjlAedfxith8OmDa4402YlgxUW2xQf1MJhmN89IU+8+NxRia04
	bhPcjCt6gWLe94H1g3jFcxTKcCxMdZYU80+mwej9+eNN47nKZ+boZFbjqL0t3FK8R2w=
X-Gm-Gg: ASbGncvK9pASvjOzK+FMEazLcOdxe9n8H4aEwTEwQvhQ3P/OWR2RMUOw+htoXhc4JX6
	KkkqLVTj5hrGCihswZUCJ5k/e7dQvaf3U+UGXKpo+6Mzn2IiKDUVXzbnZQafMBjSJl46EllKiAn
	HfM5udQSzA8od8SW1SBwaKXQYxiELoX2HiwbTj+lpiPJtGVPuTaQnVn0nAw41cx/ayX4OpNZEeF
	9Edvp9mS/6nIEOD6rmkeTeV3/oSeDvIvq4h9wsn4WVHa/Hfgskus3hleiBOnmQC2aic6tHxEG8m
	i2wBilt2ZWrdcHGjqiEYVTkSFwIT55N06JAemgC0GZshSFIFoUBc8RgkQxrpdI7y2mBGRwwK6Nb
	XdVgn+xYVOmuV4Z5OwMdfku0Ymv55Xg==
X-Google-Smtp-Source: AGHT+IHQQHdAd5H92gMabdzfVxPQznKlbBnOg55WUIqgbYGdQ/KfGkqEFKOpZHpwxTUp7tnJLBF2rg==
X-Received: by 2002:a05:6000:250e:b0:3a5:2670:e220 with SMTP id ffacd0b85a97d-3a531cb01b7mr1892342f8f.32.1749196632070;
        Fri, 06 Jun 2025 00:57:12 -0700 (PDT)
Date: Fri, 6 Jun 2025 09:57:10 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Alejandro Vallejo 
Cc: xen-devel@lists.xenproject.org,
	Bernhard Kaindl ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Stefano Stabellini ,
	Tamas K Lengyel 
Subject: Re: [PATCH 04/11] xen: Add node argument to
 domain_{adjust_tot_pages,set_outstanding_pages}()
Message-ID: 
References: <20250314172502.53498-1-alejandro.vallejo@cloud.com>
 <20250314172502.53498-5-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250314172502.53498-5-alejandro.vallejo@cloud.com>

On Fri, Mar 14, 2025 at 05:24:55PM +0000, Alejandro Vallejo wrote:
> domain_adjust_tot_pages() decreases the outstanding claims of a domain
> as pages are allocated, so that'll need to take into account the node in
> which an allocation is done. Deallocations just pass NUMA_NO_NODE.
> 
> domain_set_outstanding_pages() takes the node on which to to stake an
> exact-node claim, or NUMA_NO_NODE if it's a non-exact claim.
> 
> Not a functional change, as neither function uses the arguments for
> anything yet. It's a prerequisite to simplify for the following patch
> that introduces per-node claim counts.
> 
> Signed-off-by: Alejandro Vallejo 
> ---
>  xen/arch/x86/mm.c             |  3 ++-
>  xen/arch/x86/mm/mem_sharing.c |  4 ++--
>  xen/common/domain.c           |  2 +-
>  xen/common/grant_table.c      |  4 ++--
>  xen/common/memory.c           |  6 ++++--
>  xen/common/page_alloc.c       | 17 ++++++++++++-----
>  xen/include/xen/mm.h          |  6 ++++--
>  7 files changed, 27 insertions(+), 15 deletions(-)
> 
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index bfdc8fb01949..89f87d013099 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4458,7 +4458,8 @@ int steal_page(
>      page_list_del(page, &d->page_list);
>  
>      /* Unlink from original owner. */
> -    if ( !(memflags & MEMF_no_refcount) && !domain_adjust_tot_pages(d, -1) )
> +    if ( !(memflags & MEMF_no_refcount) &&
> +         !domain_adjust_tot_pages(d, NUMA_NO_NODE, -1) )
>          drop_dom_ref = true;
>  
>      nrspin_unlock(&d->page_alloc_lock);
> diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
> index da28266ef076..2551c0d86e80 100644
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -720,7 +720,7 @@ static int page_make_sharable(struct domain *d,
>      if ( !validate_only )
>      {
>          page_set_owner(page, dom_cow);
> -        drop_dom_ref = !domain_adjust_tot_pages(d, -1);
> +        drop_dom_ref = !domain_adjust_tot_pages(d, NUMA_NO_NODE, -1);
>          page_list_del(page, &d->page_list);
>      }
>  
> @@ -766,7 +766,7 @@ static int page_make_private(struct domain *d, struct page_info *page)
>      ASSERT(page_get_owner(page) == dom_cow);
>      page_set_owner(page, d);
>  
> -    if ( domain_adjust_tot_pages(d, 1) == 1 )
> +    if ( domain_adjust_tot_pages(d, page_to_nid(page), 1) == 1 )
>          get_knownalive_domain(d);
>      page_list_add_tail(page, &d->page_list);
>      nrspin_unlock(&d->page_alloc_lock);
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 585fd726a941..72d8d62bc1e8 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -1205,7 +1205,7 @@ int domain_kill(struct domain *d)
>          rspin_barrier(&d->domain_lock);
>          argo_destroy(d);
>          vnuma_destroy(d->vnuma);
> -        domain_set_outstanding_pages(d, 0);
> +        domain_set_outstanding_pages(d, NUMA_NO_NODE, 0);
>          /* fallthrough */
>      case DOMDYING_dying:
>          rc = domain_teardown(d);
> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
> index 6c77867f8cdd..d8c5321185c6 100644
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -2403,7 +2403,7 @@ gnttab_transfer(
>          }
>  
>          /* Okay, add the page to 'e'. */
> -        if ( unlikely(domain_adjust_tot_pages(e, 1) == 1) )
> +        if ( unlikely(domain_adjust_tot_pages(e, page_to_nid(page), 1) == 1) )
>              get_knownalive_domain(e);
>  
>          /*
> @@ -2429,7 +2429,7 @@ gnttab_transfer(
>               * page in the page total
>               */
>              nrspin_lock(&e->page_alloc_lock);
> -            drop_dom_ref = !domain_adjust_tot_pages(e, -1);
> +            drop_dom_ref = !domain_adjust_tot_pages(e, NUMA_NO_NODE, -1);
>              nrspin_unlock(&e->page_alloc_lock);
>  
>              if ( okay /* i.e. e->is_dying due to the surrounding if() */ )
> diff --git a/xen/common/memory.c b/xen/common/memory.c
> index 8ca4e1a8425b..1ab0bac4e7da 100644
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -773,7 +773,8 @@ static long memory_exchange(XEN_GUEST_HANDLE_PARAM(xen_memory_exchange_t) arg)
>  
>                  nrspin_lock(&d->page_alloc_lock);
>                  drop_dom_ref = (dec_count &&
> -                                !domain_adjust_tot_pages(d, -dec_count));
> +                                !domain_adjust_tot_pages(d, NUMA_NO_NODE,
> +                                -dec_count));

Nit: it would be best if dec_count is aligned with the parenthesis:

                                !domain_adjust_tot_pages(d, NUMA_NO_NODE,
                                                         -dec_count));

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 08:08:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 08:08:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008076.1387289 (Exim 4.92)
	(envelope-from )
	id 1uNS7h-0002N0-Rk; Fri, 06 Jun 2025 08:08:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008076.1387289; Fri, 06 Jun 2025 08:08: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 1uNS7h-0002Mt-Ov; Fri, 06 Jun 2025 08:08:21 +0000
Received: by outflank-mailman (input) for mailman id 1008076;
 Fri, 06 Jun 2025 08:08: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 1uNS7g-0002Ma-B9
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 08:08:20 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on2062f.outbound.protection.outlook.com
 [2a01:111:f403:2412::62f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 667b168c-42ad-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 10:08:18 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by BN3PR12MB9595.namprd12.prod.outlook.com (2603:10b6:408:2cb::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Fri, 6 Jun
 2025 08:08:12 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8792.034; Fri, 6 Jun 2025
 08:08: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: 667b168c-42ad-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=e522IREaWf3rKqZaVtpAtW50X1pw2vukLGNwF5TOSUUdgih/B7tEpGTvv6MXKkzCOfV0xWXIXndIdVnESfVytH8toHZ8uE3A7aVn7YnjY0qAklsqaspjxLETpVeIRWqnle2fmVUC0UkPxVuazmbRj9zAehSwQF4kTmqoDiscKlca7x674pg0bCzZO9Mpzah4xw9l6K0i3c247NbO11jkoihlDnDTd5XV+/eLa4Th3APDXaoHH3Lrl/mlcN/8vVprLLP2bVyvSnMHzobUAHJgzl+BbyfX5LgiSrNGll1xIn9iqxY6g+o/An9eCaN+YJKGZQr6gcSAdpInuspxwnksSg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=/H1oDzcywQO9/UntSnvfvZiyyNydwEGkaN2gA6gebSI=;
 b=xmMy7tw/AsEcJJWydkGLy8NXwjHhIue+MLCt5tDfKlke8ZPcIIKdPQf/PcIobD2qN96c+Bt/jLzWxkkGhQX1ikzv3uTS6BkSBMgmI+NmKFmEzsluIPevaxhIK5jh3Y42T2FbeFxyiIbUOaUNqAe189GQWGVQFQt0JTasPblon96nqXsJC9fuh6ITcqNdpiAcOQcC/nVmRPEe4xLRtMQQ2nk5dY9wC1cOiSLIRWAJsCGL3P0AzTCtoNCej42BhlgVWRkNpikX+MPP4icOTOsgVFXsUnuH5w/S7nRaOAWjL57LV43+QctbBGsyRJ34bQSeOE3gcdWmwcx3wDD1ckKOqw==
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=/H1oDzcywQO9/UntSnvfvZiyyNydwEGkaN2gA6gebSI=;
 b=W1nbIL1cunoxDLsO1IdGmxFHggqYVFXG1DV1ip/vE1SC1ZmLOO+451u4KlPxUSejxh1TexA2wPmjHZ/GoMSdQuykOtzc5jit2oIIh55nEFPsSpC7kEFTl0+1LUbVxvqHdcvlIWM48Z3dI1oC9rnJlQZhyAJWa8tom8wHKn9S7y0=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Fri, 6 Jun 2025 10:08:09 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH xen/arm 1/1] xen/arm: Standardize R-Car platform Kconfig
 descriptions
To: Jahan Murudi , sstabellini@kernel.org,
 julien@xen.org, bertrand.marquis@arm.com, Volodymyr_Babchuk@epam.com
Cc: xen-devel@lists.xenproject.org
References: <20250606070501.3470801-1-jahan.murudi.zg@renesas.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250606070501.3470801-1-jahan.murudi.zg@renesas.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: AM6P193CA0084.EURP193.PROD.OUTLOOK.COM
 (2603:10a6:209:88::25) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|BN3PR12MB9595:EE_
X-MS-Office365-Filtering-Correlation-Id: 0e1fb8f9-fbf0-4a7e-74f0-08dda4d1484d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?Z2JzRXlwVENFcXNhakNEaTBmekJhRnptNmtmWS9TV00zaGt1WG5RNGdjUVo5?=
 =?utf-8?B?SlVna2h6NENudW56NWtObXQ1MmhvRW5CQkpGYjVpcWEzRnBXUU1OME1iMElC?=
 =?utf-8?B?ZyttMXB3c1pkWldzVUxmQkRIZUdnd0VOUGlFT0dUNWNRRDdzU2I3UnVJY252?=
 =?utf-8?B?ZHlOU0Q3N3o1dUFjVy9VeFZVTU1UeWRsWDZPaXpKd0tzcDYydTVZN0U5eTZi?=
 =?utf-8?B?NzJNdExhSjljT0NDVkk5dmxTWWwwY3krV2NUZm9HRDBaQzBzUnhLajhYUjIz?=
 =?utf-8?B?OXNwOW1Nc1M0cnNvc1dBVVlPUEozaVM3L3Z0Q0J2Y29WSkdEZkx1VG1XNkxv?=
 =?utf-8?B?ZjREcEVETG9OcUppbitFV25lMTFYL3dRUWlRazBWSlE3TkY5c1VBc3oyL3cw?=
 =?utf-8?B?RFZSUjdtSTBGbXkzN0RmcUdGanJuUjQvUmtYdzhoVGI5bmd6TTN2N1RBVGFs?=
 =?utf-8?B?R2hOQkdzMlZkYzg0dS9KbElkQ2NWWHhUYWxkU0RRY0V4RllxS0ZyaTE4SlFh?=
 =?utf-8?B?Tld2Vit0dXFheEZiM0NIbHdkU2hlVENOUUF3eHNzNXZsd3E1ZndzeXVLaXBM?=
 =?utf-8?B?SUJsbE1zTGtzRnZUTHluNXRsNXFmYk1UVEM5ZitIYjdXdHB3U3I1Sjd2bm5F?=
 =?utf-8?B?NDVuaTcxNHowWGhtSXJBN0dWYXNlL0c5OGRUMzBpMk1Nd3l4NHFIVCtSM09N?=
 =?utf-8?B?KzdYdDg2K0xKN2I1ODQwaVAya3g2TnhlY1FxOU9ZdWlyOGtvd0hQbHFzbUJr?=
 =?utf-8?B?QmNTMXdVN0R5dmkyQzV4OFp4ck9xWU9jVDZ1dzI1NUg1aVh6aEF0NnFNM3lp?=
 =?utf-8?B?aktSZmpCYzQrSmVaQ01QZHpCaHNZeUNjY2N0bk1VUEptSzJXUUhnSmRvdDZp?=
 =?utf-8?B?RzdJWGVVOXMweFZjczdNZ3A3dXBnczZyUm0wRnc5TTVielFmaGk0T0F0R2hT?=
 =?utf-8?B?QS9mUnJ2Q2tERmpxcVp5TDh6akFMSkJCSmhRdCtBTGxyekRWanlWcFZ3SUda?=
 =?utf-8?B?ZDE0eWowM09wU0dDbkRiTEF6cWpnSmJIUjNPOC9tVmR3TjhaVEN4eDlNWm1l?=
 =?utf-8?B?dWtjS0JnWGJXcnRKeHlMS3FMbzd1S3IyVllGNHdtQUxneXlFVHQ2R3NrSFZO?=
 =?utf-8?B?Z1ZQeWs4TGZnb2VGN3pTM2dnZVZmMWZ1a3JmWDBQczc3Rko0WWJaMTQzdmF0?=
 =?utf-8?B?V01VSUMxVnNBQ1dLRDlYcmg0cTFIQ3g4S3VTWm5YVkxaR3ZEb01FTkpuaFFq?=
 =?utf-8?B?bkcveEFDcWo2QlUzRkRPTG0wa0sveE13dTVlN2pTZnd1cjEzNStBQ3BMQzY1?=
 =?utf-8?B?VkVIU2g2UzRSVmN6NG1IRWo2MHZ4akRXSzliR0tRemVjUElZVzVLTDU2TW1W?=
 =?utf-8?B?bGtZTTl4a1dJUzAzdk9nY3hGbUZxYkRCZHNPL2toVU1wMzBtWGVVRXZwRzdC?=
 =?utf-8?B?ZXB0clY1NHhRbXpjVUc4SkM0R2lnWFM1b3BuL1MvcmZVbTBxL2pMN2x2VHZi?=
 =?utf-8?B?bDV5VGJSMHo3RE1Td1JUVFlmeFZWdEdyUmVLWm9zNGxkcTF4RVJmdWZnWlpZ?=
 =?utf-8?B?V0RsclFRMC9CQ1hlaTM5N25mQ2M4NUJVM3JSUHlRbmN2SUhqdjJKR2xMckVr?=
 =?utf-8?B?dXpQdnhyZ05aNzFSaEhISExiQUs1aEhmZG9ibzZnNVozM09ZZjd3VjdVOHBp?=
 =?utf-8?B?Q05QcWZWVmp4Tm9BTEQwSzNsbExHY0szUzhXQm9wL3JONTNHR1RJamRtWHNT?=
 =?utf-8?B?U1I3YlB1Sm9qbml1VWJiWWc4WlFjaXgyT2gxazM3ODhSclNYTk9nRTI4RzJI?=
 =?utf-8?B?Nkw1a1dRMUx5c0VZR0JnZWNUQ2hEcVlTVjlvb1doYVYvcHVYNkFHeERlR295?=
 =?utf-8?B?dWRhaDhOb2wzSVZLYktYTXQ1L1dFOEcxVFh0cTNCQkdzTk9GVlpxQ3B0a2R2?=
 =?utf-8?Q?jMbZcdchDs4=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?WUtveFEybjYwMVlRTHRjdXpqV0w0ZWZDVjdJeGF0VENteXhwWWpVWEtJTnRp?=
 =?utf-8?B?V0hnays4Z3p5M2FqeklkcFZnWjMzNjNPSlFqTFo2dmJOejdNbWNQQk44bDE0?=
 =?utf-8?B?TWhPNzdzdTk3akhIaHRMdmdtbFA3QW1naHFDMysybHRvNGtrOHZGaVd6ZEFH?=
 =?utf-8?B?Qk1ucWFaaUl3RW4zWTY0Zmx2aUlOdlFxWFFSdDArME1KQ28rdkJtSnJuTFBY?=
 =?utf-8?B?YTBwL2xISEp2UXNNa0VIZVVRSDBqRy9pdndQRUJsMHZxTDRkUk1pK1k4U0lM?=
 =?utf-8?B?aWIwSm80Mk9HUjVaMlJUVlVpN01Iam5jdWpiVTlmS3d6TUNTNlZ1alM2Rll2?=
 =?utf-8?B?R2xWaXlmMVJ1ZlplNTNIU0RqalA2UElVQU45UVpieXk0cFFqYUFYNDhXam96?=
 =?utf-8?B?aGRLMDh4ajNnQWFJenFzeTZjMmFqZFA4NG1RYUdIZFE4ZWNtN3hLWmQ2c1JW?=
 =?utf-8?B?ZHd2RkJHeVJ1YkRUNDhMcVB4bHVZOHBEZGNSc0ZZY0xhTmxoYzU0YzNNUlpr?=
 =?utf-8?B?c1JXendTTlFpQW02enFiQThKUWROTkhMTHdTeUxDMVpaanROT3pBR0ovL3Ra?=
 =?utf-8?B?a2tsOUlJYjUwTytiM01DQWZBV0FUMUVLUm13NkFYTEZTQUJ1N3hDMDVjZ0J5?=
 =?utf-8?B?UXkzbHNST2ZRaDBHeE0xZXJ5V1FYdStSKzY4ZFpPUFpJMjRKVkpUNHJ1RTlE?=
 =?utf-8?B?WktpUjFFbzBhZnVHTnFSU0RuSENsOXlMNXBac0dMWHhvcC85VkFRUU8rY3RE?=
 =?utf-8?B?VkNWTWh6WjJsL003ZFpsMnZ4NjBibWZhdjZ2bWUxQkRkaVgyRXhEMWwvRHNY?=
 =?utf-8?B?RE5WTlFrdUQvRGtrakh5WG4yVjZDYlhYN3ZaTEt2R3ZZdG1hd2dyRURHTWMy?=
 =?utf-8?B?OXQ0d2dGbTNmV3dVMFMyUVVkVVZQRjVYZitUUGFrYzNyN3lIVURUbmFmNGxN?=
 =?utf-8?B?K1V0dXJvUmtrVE92eUI5NWFHREZOTm44N05vdnBxNjQ0U1hFbDlVN0dOVk1G?=
 =?utf-8?B?ei9PR2NscGRVM3lacFYrYmpWekJ6cHZ2Ry8ra0RDd1FYOE5TNU10azVDS1c1?=
 =?utf-8?B?NnNONll3c2VneThxN0w3ODZQUld5REsyZnpvRmpwUHI1SmRkblJBOTkzck5D?=
 =?utf-8?B?UHN0Vm1mcE5JZ0RrNDFiVkw1TmxSMmNOLzdreWlxWVdaTXRtZ2RlL0ZyclVv?=
 =?utf-8?B?b3hRV1gwN3g3azExSGlQK2JDVDlJM0dxTjRORTZsc1FvMnE1bCt4Zms0ZjY2?=
 =?utf-8?B?Q0tyRFFXYmJDMk5RK2x6bzk0S3IrbWo3VENhcWJzeHRySFVMRCtOU2Z2OVkv?=
 =?utf-8?B?MGxIYmdtOEdIc0ZySWRxL1JDNXhkSlpkOHBpcXVBQlowanE2T3NvcmVRcEJH?=
 =?utf-8?B?TjJ1elY5c3VWSTRleXdzekRPdGViNXhxTEcyWG5GdVFWY1RtS0Z0ZmxNMzl6?=
 =?utf-8?B?OVVhaHlmMExYRndLOHJWTDJzc0FMM2c1d2JHdDFzc3BoTmRJOXVKNG1Pd0lW?=
 =?utf-8?B?U2dMdW1hL3ZvSlh6RE94eDROQXhGb1cxRHczVnpjNXNUM1FTdVFHckdaaEVp?=
 =?utf-8?B?ZjdTeTJVakRnY0c5TFlHWWJ5TksrMUhiRlRRNUs4MThzWG5GaXhhT3JOaXU5?=
 =?utf-8?B?YzBnK2l3TU5SMkw2c2FSN1BYbGc5blJnemVpSk9oUVptWENLc05hdUxoNXBi?=
 =?utf-8?B?eVhzVkQzSVNqbmtXVXRTZXpneXFldDdMY1J2NVA3dExla3dMWkZubS8yckhJ?=
 =?utf-8?B?Y1N1R2NQUUJPRldGR2t5cW1ibGRaTW9zcGlhRkt4NEdoNk1IbnVWc0JMeUJI?=
 =?utf-8?B?TUxnUXFFdzRGcnl6RXg3RzAvVHZmV0kwWE9ZS0NqOWxXMWVvWEZwUFU0eXp6?=
 =?utf-8?B?bVFMY0crZ1BLQ0hYelBsZVdteWZpTGNweGs4NHNnWVJUVWVTYU93UG9jRzlK?=
 =?utf-8?B?bXpJSXV0a2pnZ29jdXlQZm90cHhBeVBDSlMreVJqWUp2SkJMQUdQdERUVGE2?=
 =?utf-8?B?UVN2Q2o3bm1Dd1B0V2phTlQzWnVkSDc1bHBLYUd5QXJVKzE2Q3B0cEZpYVM0?=
 =?utf-8?B?WVgzN1k0bTVLRHdqenJvbzkvbnBZMkswdWZSRm1YNW5kWm4xWVNJMXpyTE9n?=
 =?utf-8?Q?biG/uDNerQ//TBQk6kO/3iAEE?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0e1fb8f9-fbf0-4a7e-74f0-08dda4d1484d
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jun 2025 08:08:12.6294
 (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: 2VgbeWivVIG0a7xI4gMyQYXmcHNg1y+ofxnh1fKj3OnmXWTou9AbPDio+xI6O0EL
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR12MB9595



On 06/06/2025 09:05, Jahan Murudi wrote:
> Changed "RCar3/RCar4" to "R-Car Gen3/Gen4" to match official Renesas branding
I mentioned this in the previous review. Please use imperative mood:
s/Changed/Change. Also, you're missing a dot at the end of sentence.

> Aligns with documentation and industry-standard terminology
> 
> Signed-off-by: Jahan Murudi 
Reviewed-by: Michal Orzel 

~Michal

> ---
>  xen/arch/arm/platforms/Kconfig | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig
> index 87bf614788..c8bc0bfae3 100644
> --- a/xen/arch/arm/platforms/Kconfig
> +++ b/xen/arch/arm/platforms/Kconfig
> @@ -22,21 +22,23 @@ config QEMU
>  	  machine.
>  
>  config RCAR3
> -	bool "Renesas RCar3 support"
> +	bool "Renesas R-Car Gen3 support"
>  	depends on ARM_64
>  	select HAS_SCIF
>  	select IPMMU_VMSA
>  	help
> -	  Enable all the required drivers for Renesas RCar3
> +	  Enable support for Renesas R-Car Generation 3 SoCs (H3, M3, etc.).
> +	  Includes all required drivers and platform-specific features.
>  
>  config RCAR4
> -	bool "Renesas RCar4 support"
> +	bool "Renesas R-Car Gen4 support"
>  	depends on ARM_64
>  	select HAS_SCIF
>  	select HAS_ITS
>  	select IPMMU_VMSA
>  	help
> -	Enable all the required drivers for Renesas RCar4
> +	  Enable support for Renesas R-Car Generation 4 SoCs (V4H, V4M, etc.).
> +	  Includes all required drivers and platform-specific features.
>  
>  config MPSOC
>  	bool "Xilinx Ultrascale+ MPSoC support"



From xen-devel-bounces@lists.xenproject.org Fri Jun 06 08:14:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 08:14:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008089.1387300 (Exim 4.92)
	(envelope-from )
	id 1uNSDW-00045A-Fc; Fri, 06 Jun 2025 08:14:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008089.1387300; Fri, 06 Jun 2025 08:14: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 1uNSDW-000453-CK; Fri, 06 Jun 2025 08:14:22 +0000
Received: by outflank-mailman (input) for mailman id 1008089;
 Fri, 06 Jun 2025 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 1uNSDU-00044Y-UF
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 08:14:20 +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 3ecf7775-42ae-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 10:14:19 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-450d668c2a1so20418015e9.0
 for ; Fri, 06 Jun 2025 01:14:19 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-45209ce0b97sm15915745e9.9.2025.06.06.01.14.18
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 06 Jun 2025 01:14:18 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3ecf7775-42ae-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749197659; x=1749802459; 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=p/nGcUxEK+SuKmowKg4XVxySr0bBKdS76bK7pSzUDSE=;
        b=bTmUBwNNYQoXtWjKgnzjSo8ZsUeAN9PPS32sq6uVI4FFco4uqE6BaPNYHVjbYPTwyx
         /oZDsz6GrNUr1HghWDmA7Yr6GuWqLXMmcils8J610vk8pVzmRqLX1UxRLSziEEBatpjN
         j7j/HVCOY1XM2w29+eCz72nWCMuaIZxswIfdk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749197659; x=1749802459;
        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=p/nGcUxEK+SuKmowKg4XVxySr0bBKdS76bK7pSzUDSE=;
        b=WeWOMxzKi4retnoHL3r7wf7Cdm46LyP/hxIXrDwUO9l8BQNVNT3FCbTGM+xKsmV2iK
         TKR+DT9Sl16O3TbHCqSX+oMarqEenqfGzlw5AJnzLOzHqTI5JnhgvuKtaVerLpQmmgxI
         hV7XjYtrKwS5NpFOsSC6//ICqHSfAG4u2vCMcvFB34GJKxnbfJEoEHpHZR1T+nBUwtZx
         Tb6dnbhn5MK2BEWwngxwGL8Amer2UvVfF3IlsQJyC7qnXfmrg8PvEkVQ9gLErwT3UGkr
         p/kQAljfQqK0UJ+lhaHQyDXz7PJLvTqPoGWp7qbFLrB/ur6xtZf2zRlUEYFIkkk8VmNP
         yFMw==
X-Gm-Message-State: AOJu0YxRbhd+apt1Ib146tSkDVJbF6acYmf5XKmyWIoR+aUsskWaIc7t
	D0Sq73fqgVfy6IfDBgJHfcQQR7rnJnMkLIeXP9AvZ89qEG+etfwb8W2pm6BATRIDtOY=
X-Gm-Gg: ASbGnctzpgb4PknOQxxKLEgCecGEN3cc/z2WeTeuiXXJ4hH7djjTcuhVtSv0LTWY8jO
	BP1wqzFf4LMsPCLDy6TbVctI37LcbdxwFtSfLn68YloAFDCfZX91d5ZNs5GI33jcP1yFW0/P/lS
	yi1NTU+om5IYPEdgzSbor3gWgfAcR07QTpWqeH29wr8ZePCCQSIwOeZcYBrG7Xm5tb3HetF8N+t
	sp2xxz2opcXkrns+EnxjHxmqJdu1KALFQGg7zq0f34pkLbu/FGDDlfivVR2JNj7oyaG0aL5755g
	CNj/goJ/SOCZkXSMuWjNvFmeJh3VisnCYDXD9g2XEtJJOJLAfsM27yXs1nJjazdpshQzaTrR2zP
	UJY1nYJE24N762z3UBfJTUtsRQwgN2A==
X-Google-Smtp-Source: AGHT+IF/1F3RsuJWsGXxmuB7HnlsS8mPbZFuIiUG+pKNCKu8rKvucsSpCE7Wt1mnPATcavGdCZF62Q==
X-Received: by 2002:a05:600c:1c92:b0:441:d228:3a07 with SMTP id 5b1f17b1804b1-451f88bead1mr76413145e9.13.1749197658847;
        Fri, 06 Jun 2025 01:14:18 -0700 (PDT)
Date: Fri, 6 Jun 2025 10:14:17 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Alejandro Vallejo 
Cc: xen-devel@lists.xenproject.org,
	Bernhard Kaindl ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH 05/11] xen: Create per-node outstanding claims
Message-ID: 
References: <20250314172502.53498-1-alejandro.vallejo@cloud.com>
 <20250314172502.53498-6-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250314172502.53498-6-alejandro.vallejo@cloud.com>

On Fri, Mar 14, 2025 at 05:24:56PM +0000, Alejandro Vallejo wrote:
> Extends domain_set_outstanding_claims() to allow staking claims on an
> exact node. Also creates global per-node claim counts analogous to
> `outstanding_claims`. Note that the per-node counts can't replace the
> global one if we want exact-node claims to coexist with non-exact
> claims.
> 
> Signed-off-by: Alejandro Vallejo 
> ---
>  xen/common/page_alloc.c | 32 +++++++++++++++++++++++++++++++-
>  xen/include/xen/sched.h |  3 +++
>  2 files changed, 34 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
> index 9243c4f51370..7fe574b29407 100644
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -490,6 +490,7 @@ static unsigned long pernode_avail_pages[MAX_NUMNODES];
>  
>  static DEFINE_SPINLOCK(heap_lock);
>  static long outstanding_claims; /* total outstanding claims by all domains */
> +static unsigned long pernode_oc[MAX_NUMNODES]; /* per-node outstanding claims */
>  
>  unsigned long domain_adjust_tot_pages(struct domain *d, nodeid_t node,
>                                        long pages)
> @@ -501,20 +502,31 @@ unsigned long domain_adjust_tot_pages(struct domain *d, nodeid_t node,
>       * can test d->outstanding_pages race-free because it can only change
>       * if d->page_alloc_lock and heap_lock are both held, see also
>       * domain_set_outstanding_pages below
> +     *
> +     * If `d` has an exact-node claim, we must exit early if this is an
> +     * adjustment attributed to another node.
>       */
> -    if ( !d->outstanding_pages || pages <= 0 )
> +    if ( !d->outstanding_pages || pages <= 0 ||
> +         (d->claim_node != NUMA_NO_NODE && d->claim_node != node) )
>          goto out;
>  
> +
>      spin_lock(&heap_lock);
>      BUG_ON(outstanding_claims < d->outstanding_pages);
>      if ( d->outstanding_pages < pages )
>      {
>          /* `pages` exceeds the domain's outstanding count. Zero it out. */
> +        if ( d->claim_node != NUMA_NO_NODE )
> +            pernode_oc[d->claim_node] -= d->outstanding_pages;
> +
>          outstanding_claims -= d->outstanding_pages;
>          d->outstanding_pages = 0;
>      }
>      else
>      {
> +        if ( d->claim_node != NUMA_NO_NODE )
> +            pernode_oc[d->claim_node] -= pages;
> +
>          outstanding_claims -= pages;
>          d->outstanding_pages -= pages;
>      }
> @@ -542,6 +554,10 @@ int domain_set_outstanding_pages(struct domain *d, nodeid_t node,
>      if ( pages == 0 )
>      {
>          outstanding_claims -= d->outstanding_pages;
> +
> +        if ( d->claim_node != NUMA_NO_NODE )
> +            pernode_oc[d->claim_node] -= d->outstanding_pages;
> +
>          d->outstanding_pages = 0;
>          ret = 0;
>          goto out;
> @@ -564,12 +580,26 @@ int domain_set_outstanding_pages(struct domain *d, nodeid_t node,
>      /* how much memory is available? */
>      avail_pages = total_avail_pages - outstanding_claims;
>  
> +    /* This check can't be skipped for the NUMA case, or we may overclaim */
>      if ( pages > avail_pages )
>          goto out;
>  
> +    if ( node != NUMA_NO_NODE )
> +    {
> +        avail_pages = pernode_avail_pages[node] - pernode_oc[node];
> +
> +        if ( pages > avail_pages )
> +            goto out;
> +    }
> +
>      /* yay, claim fits in available memory, stake the claim, success! */
>      d->outstanding_pages = pages;
>      outstanding_claims += d->outstanding_pages;
> +    d->claim_node = node;
> +
> +    if ( node != NUMA_NO_NODE )
> +        pernode_oc[node] += pages;
> +
>      ret = 0;
>  
>  out:
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index 559d201e0c7e..307a9d749f5d 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -406,6 +406,9 @@ struct domain
>      unsigned int     max_pages;         /* maximum value for domain_tot_pages() */
>      unsigned int     extra_pages;       /* pages not included in domain_tot_pages() */
>  
> +    /* NUMA node from which outstanding pages have been reserved */
> +    unsigned int     claim_node;

This should possibly be nodeid_t rather than unsigned int?

But why is this a single node?  The interface should allow for a
domain to claim memory from multiple different nodes.

The interface here seems to be focused on domains only being allowed
to allocate from a single node, or otherwise you must first allocate
memory from a node before moving to the next one (which defeats the
purpose of claims?).

I think we want to instead convert d->outstanding_pages into a
per-node array, so that a domain can have outstanding claims for
multiple NUMA nodes?

The hypercall interface becomes a bit awkward then, as the toolstack
has to perform a different hypercall for each memory claim from a
different node (and rollback in case of failure).  Ideally we would
need to introduce a new hypercall that allows making claims from
multiple nodes in a single locked region, as to ensure success or
failure in an atomic way.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 08:23:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 08:23:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008102.1387309 (Exim 4.92)
	(envelope-from )
	id 1uNSLs-0005tZ-DL; Fri, 06 Jun 2025 08:23:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008102.1387309; Fri, 06 Jun 2025 08: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 1uNSLs-0005tS-Aj; Fri, 06 Jun 2025 08:23:00 +0000
Received: by outflank-mailman (input) for mailman id 1008102;
 Fri, 06 Jun 2025 08:22: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 1uNSLr-0005tM-4j
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 08:22:59 +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 73f84b8b-42af-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 10:22:58 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-451d6ade159so15842945e9.1
 for ; Fri, 06 Jun 2025 01:22:58 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-45213726c44sm16165835e9.28.2025.06.06.01.22.57
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 06 Jun 2025 01:22:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 73f84b8b-42af-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749198178; x=1749802978; 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=LEqruCKXtuU4GhnlLVJr9x+2zLD92RBcnIFW5NVEHPQ=;
        b=X5DDI6jvnPX7Y5WXbLuEI+FlmwhhQK8+o7JCXkKOhzz6U9GW09cYD1ZP13D+X+hYWL
         nMejrG1Xy2QTDPhQv8gFql/pBbj2VT0/ZYlauiTJMaQey/ZNe0MnNRVkGv8v2iXi6lYm
         3x3uYOi8fSokqK46rKDqeKrf1YrmrDXMTP0H4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749198178; x=1749802978;
        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=LEqruCKXtuU4GhnlLVJr9x+2zLD92RBcnIFW5NVEHPQ=;
        b=w+GoBiP8C5P34BJgv11/RC/PyQcIgSQ6QX/K7LILN5Q0rW58U4BsCW/hUptG6ajfny
         6iu3CycDC7aZ0YIAS7uUkqNZM+LENHXG/O/zD50qloQhRd6UwTNM0JGrSdpz4EoJF167
         KiIvTlfKBmoXcpPim93BcUvE4QCbnjpiWcPohppjxoP8Z6aLtAzeMSoKamkjjQdG1hTy
         e9zT0ROcSMtnXuACYUASXNOVbFX6dbEyB2DUBiDv4pkVWVAq8bgdfdwsZYVI8xygjd+g
         9ePHYOILeV0BH1Vg8B6iB+agfUxy/g22r+Fm0rigtfZAMVLkSnPDRwoPByWVxA1povfH
         6kQg==
X-Gm-Message-State: AOJu0YzJAjH6XiAlHhSwM1URuTGFwfqhvgriUgIF/W0aE5zXMbHnamC5
	UUqQxYMuJymRfEV4ADJJ69AZp2Kh9HHkMU/1a95S5XN9rK/u5TY3WpWM60wACUGRKyc=
X-Gm-Gg: ASbGnctYue4HM6Blyk1htkXvigOD+n1phDFdw+aMUbYslnIoen57ge+dFFG99Ff+F5u
	cU3Zf4Jdm7pdWW2ZEGLoOzivSEeCqn+3kK3MX+iQYFfQljUz05DofjGSNznYG74Kq/NWZECcMcj
	Y2tAA2saYT4BGz25eEsnr6UFaYpNwsbRKNxkQogeljIjU1jIBvBXmqrurGH8V7GT1k7+o3C0x8R
	Pj3viWIPmjUYbmwpV9g5vx88INq7i1GIUec+VeNRFfkJiTj0FjzrWx4Q4YwlTui56008PvJ6K+a
	daJ2ImMg9jdqZwbDpgRRt8U8/XyPdNHE8Ht4ZRjOn8FqqD3rlXKNatiSd6j1/jvlPKfLQ2KKHDu
	KXn20cyMUsS8Y4ggWWJ6tu2zU1q/ncQ==
X-Google-Smtp-Source: AGHT+IExsMr2tJqj8pWknFB5DxVstQonM3TFEcr+WvfBdd9KWPgathayxMCgZs/udbEnSOB5ErwIjw==
X-Received: by 2002:a05:600c:6099:b0:440:61eb:2ce5 with SMTP id 5b1f17b1804b1-452013bb38dmr31216295e9.17.1749198177596;
        Fri, 06 Jun 2025 01:22:57 -0700 (PDT)
Date: Fri, 6 Jun 2025 10:22:56 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Alejandro Vallejo 
Cc: xen-devel@lists.xenproject.org,
	Bernhard Kaindl ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH 06/11] xen/page_alloc: Hook per-node claims to
 alloc_heap_pages()
Message-ID: 
References: <20250314172502.53498-1-alejandro.vallejo@cloud.com>
 <20250314172502.53498-7-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250314172502.53498-7-alejandro.vallejo@cloud.com>

On Fri, Mar 14, 2025 at 05:24:57PM +0000, Alejandro Vallejo wrote:
> Extend the claim checks in alloc_heap_pages() to exact-node claims. The
> logic is slightly more complicated, so the patch moves it all to an
> auxiliary function.
> 
> exact-node claims also follow global claims in order to ensure both can
> coexist in the same system.
> 
> Signed-off-by: Alejandro Vallejo 
> ---
>  xen/common/page_alloc.c | 44 ++++++++++++++++++++++++++++++++++++++---
>  1 file changed, 41 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
> index 7fe574b29407..cfaa64d3b858 100644
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -991,6 +991,46 @@ static void init_free_page_fields(struct page_info *pg)
>      page_set_owner(pg, NULL);
>  }
>  
> +/*
> + * Determine whether a heap allocation is allowed after considering all
> + * outstanding claims in the system.
> + *
> + * Exact-node allocations must also take into account global claims!
> + *
> + * e.g:
> + *   Consider a domain for which toolstack issued a non-exact claim of 75% of
> + *   host memory and another domain for which toolstack tries to issue an
> + *   exact-node claim of 50% of host memory. If the exact claim didn't consider
> + *   non-exact claims too we would overallocate, which is exactly what claims

s/overallocate/overclaim/ or maybe "attempt to overallocate".

> + *   are trying to prevent.
> + */
> +static bool can_alloc(struct domain *d, unsigned int memflags,

d can be const here, this helper is just a checker that doesn't modify
anything.

> +                      unsigned long request)
> +{
> +    nodeid_t node = (memflags & MEMF_exact_node) ? MEMF_get_node(memflags) :
> +                                                   NUMA_NO_NODE;
> +
> +    if ( outstanding_claims + request <= total_avail_pages )
> +    {
> +        if ( node == NUMA_NO_NODE )
> +            return true;
> +
> +        if ( pernode_oc[node] + request <= pernode_avail_pages[node] )
> +            return true;
> +    }

You can possibly join all conditions in a single clause?

if ( outstanding_claims + request <= total_avail_pages &&
     (node == NUMA_NO_NODE ||
      pernode_oc[node] + request <= pernode_avail_pages[node]) )
    return true;

> +
> +    /*
> +     * Not enough unclaimed memory. Only allow if it's already claimed on the
> +     * right node. d->claim_node == NUMA_NO_NODE if the claim isn't on an
> +     * exact node.
> +     *
> +     * Only refcounted allocs attributed to domains may have been claimed

Nit: missing full stop at the end of the sentence.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 08:26:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 08:26:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008108.1387320 (Exim 4.92)
	(envelope-from )
	id 1uNSPY-0006SG-Tq; Fri, 06 Jun 2025 08:26:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008108.1387320; Fri, 06 Jun 2025 08:26: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 1uNSPY-0006S9-R6; Fri, 06 Jun 2025 08:26:48 +0000
Received: by outflank-mailman (input) for mailman id 1008108;
 Fri, 06 Jun 2025 08:26: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 1uNSPX-0006S3-Jr
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 08:26: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 fc300eae-42af-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 10:26:46 +0200 (CEST)
Received: by mail-lf1-x12a.google.com with SMTP id
 2adb3069b0e04-54d98aa5981so2373666e87.0
 for ; Fri, 06 Jun 2025 01:26:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fc300eae-42af-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749198406; x=1749803206; 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=ewAT+odme99bLYZdokTwmbq8XUKEDDDi1p+vKpGkV5M=;
        b=NP+iymKb6LWouUQoiUC0wGlW5wOz/CBX5gg1SR7IleVv7y5q2nP5YIy5ippg6nd6FV
         j1JOfq3mVToPnSoa9Xbz8+mwZPfeMPlGnnQzGSyEIgLI7xUJsJ/ZGZNLOOrL77iGEQ3D
         QqtwTundCAc56HyBSKpYkUZ2dUe/WjE5CM7lfExWIDjeQBllLN0h+9Dd+AdK67mu9DYW
         yTyQKvzus+674ajCJBp2JPD8Jl5mGiUJXQnsolpFTsHE3BupKlqm3A+0Erx5jHONh8pi
         UTMJmKQIemUqsqw/VX+bPPiIzJlFyIWL26J1By+F5qC15dRI9+eX2l4aWBX0phPdxgPu
         N2bw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749198406; x=1749803206;
        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=ewAT+odme99bLYZdokTwmbq8XUKEDDDi1p+vKpGkV5M=;
        b=ZnS0jfxaI+cUQ5dcDbqTTyB1PII4HceWVyHlPVQaH5w3EbEqNsSZTj79KZp6WPp5D8
         uirwTrtyFKr1ouEAdqJSLBTVXQsry3hxRztF5vwuKdv5JK7LzbUWKpQeVo8rY7BqiU7J
         jmqqnnyeW2wqxWCwdzOQMIzTHDPX1/5qwhCkZl2TQDud3bTqDfVZy/Yc109lozWD/EAi
         Vu6HSyrP14c4uRs0gTmXVCeQbfaoj5UOrfDBWfRLSPO0xX5AtPI9GJzyxaKADlZ53gfP
         tftZtzvslNwG+MYAkQCOHVZYSeSbRQWITZ+Rv2gfJrZQB7fa3bM2kk36Jght3MESR3y0
         didw==
X-Gm-Message-State: AOJu0YyFg2wd3u4KGaczOkH95nKRo0xA9hozru1Qfzk8aWq7jM9j2VD1
	EWGGd5LMpDZRnHQrF37bu6hdxmiM6DmA0R4juGLDKVK0Dtk9ugZGJRIyrcrHcZgER+ZOkYzzoSE
	tzXOzsEx9bSmNgTsXwmiAZ5FsHVlVObc=
X-Gm-Gg: ASbGncvc8Kvb8VWZGBMHXbxRJoDR/J07vmtNGxx/5mYSftq1PS7/WxjBH00HE+CGKjr
	jpwgcM1Y8/sxXKZdRW9BCpmeusshYJQZAY/6e8FdidjepapQKvchtprt+9yyu1Gw/Jh8KkRoJAA
	GKNJLoo03IkIvcAUHmPsM5DzeUWgKxDVE=
X-Google-Smtp-Source: AGHT+IHeilxyUONEo2ILQlZXyR3O/JIsnNDwVU9ZZERBT8aTXV4a1X8mr53Q44zy52xz86Ekq4PCqZXwvI+tEhVtP2s=
X-Received: by 2002:a05:6512:2316:b0:553:51a2:441b with SMTP id
 2adb3069b0e04-55366bd3acemr613366e87.4.1749198405777; Fri, 06 Jun 2025
 01:26:45 -0700 (PDT)
MIME-Version: 1.0
References:  <1a8313537603bee36636b0fcd2fdc2f76a2374fb.1748337249.git.mykola_kvach@epam.com>
  
In-Reply-To: 
From: Mykola Kvach 
Date: Fri, 6 Jun 2025 11:26:33 +0300
X-Gm-Features: AX0GCFvPM3HQcgvBk5Xh5SNf_keyTVM5lYQ_KYha90uNAE4vEPGLZRoddmk-ykA
Message-ID: 
Subject: Re: [PATCH v4][PART 1 2/4] xen/arm: Implement PSCI SYSTEM_SUSPEND
 call for guests
To: Julien Grall 
Cc: xen-devel@lists.xenproject.org, Mykola Kvach , 
	Stefano Stabellini , Bertrand Marquis , 
	Michal Orzel , Volodymyr Babchuk 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 6, 2025 at 6:52=E2=80=AFAM Mykola Kvach  wrote:
>
> Hi, @Julien Grall
>
> On Wed, Jun 4, 2025 at 2:00=E2=80=AFAM Julien Grall  wrot=
e:
> >
> > Hi Mykola,
> >
> > On 27/05/2025 10:18, Mykola Kvach wrote:
> > > From: Mykola Kvach 
> > >
> > > This patch adds support for the PSCI SYSTEM_SUSPEND function in the v=
PSCI
> > > (virtual PSCI) interface, allowing guests to request suspend via the =
PSCI
> > > v1.0 SYSTEM_SUSPEND call (both 32-bit and 64-bit variants).
> > >
> > > The implementation:
> > > - Adds SYSTEM_SUSPEND function IDs to PSCI definitions
> > > - Implements trapping and handling of SYSTEM_SUSPEND in vPSCI
> > > - Allows only non-hardware domains to invoke SYSTEM_SUSPEND; for the
> > >    hardware domain, PSCI_NOT_SUPPORTED is returned to avoid halting t=
he
> > >    system in hwdom_shutdown() called from domain_shutdown
> > > - Ensures all secondary VCPUs of the calling domain are offline befor=
e
> > >    allowing suspend due to PSCI spec
> > > - Treats suspend as a "standby" operation: the domain is shut down wi=
th
> > >    SHUTDOWN_suspend, and resumes execution at the instruction followi=
ng
> > >    the call
> >
> > Looking at the specification, I am still not convinced you can implemen=
t
> > PSCI SUSPEND as a NOP. For instance, in the section "5.1.19
> > SYSTEM_SUSPEND", the wording implies the call cannot return when it is
> > successul.
> >
> > I understand that 5.20.2 ("Caller reponsabilities" for SYSTEM_SUSPEND)
> > suggests the caller should apply all the rules from 5.4 ("Caller
> > responsabilties" for CPU_SUSPEND), but it is also mentioned that
> > SYSTEM_SUSPEND behave as the deepest power down state.
> >
> > So I don't think standby is an option. I would like an opinion from the
> > other maintainers.
>
> Sure, let's discuss this with the others.
>
> >
> > > +static int32_t do_psci_1_0_system_suspend(register_t epoint, registe=
r_t cid)
> >  > +{> +    struct vcpu *v;
> > > +    struct domain *d =3D current->domain;
> > > +
> > > +    /* Drop this check once SYSTEM_SUSPEND is supported in hardware =
domain */
> > > +    if ( is_hardware_domain(d) )
> > > +        return PSCI_NOT_SUPPORTED;
> > > +
> > > +    /* Ensure that all CPUs other than the calling one are offline *=
/
> > > +    for_each_vcpu ( d, v )
> > > +    {
> > > +        if ( v !=3D current && is_vcpu_online(v) )
> >
> > I think this is racy because you can still turn on a vCPU afterwards
> > from a vCPU you haven't checked.
> >
>
> I'll think about how to protect against such cases.
> Thank you for pointing that out.

Is that actually possible in this context? If suspend is successful, we pau=
se
all present vCPUs (including the current one), and control is not returned =
to
the guest until either resume or an error occurs in this function. Since th=
is
runs as part of a trap, the current function can't be preempted.

Also, from the use of _VPF_down (via is_vcpu_online) on Arm, it looks like
guest requests are what manipulate this bit, which further limits what can
happen concurrently.

Maybe I missed something=E2=80=94if so, please share some details on how th=
is could
happen.

Note: It looks like the same behavior is present for VCPUOP_down as well.

>
> > Did you add this check just to follow the specification, or is there an=
y
> > other problem in Xen?
>
> Yes, it's just to comply with the specification =E2=80=94 at least,
> I've never seen PSCI_DENIED triggered because of this check.
> It's a leftover from a previous patch series.
>
> >
> > > +            return PSCI_DENIED;
> >  > +    }> +
> > > +    /*
> > > +     * System suspend requests are treated as performing standby
> > > +     * as this simplifies Xen implementation.
> > > +     *
> > > +     * Arm Power State Coordination Interface (DEN0022F.b)
> >
> > This comment is a bit too verbose. There is no need to copy/paste the
> > specification. You can just write a couple of sentence with link to the
> > specification.
>
> Got it, I'll revise the comment accordingly.
>
> >
> > Cheers,
> >
> > --
> > Julien Grall
> >
>
> Best regards,
> Mykola


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 08:28:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 08:28:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008119.1387330 (Exim 4.92)
	(envelope-from )
	id 1uNSQk-0006xG-6R; Fri, 06 Jun 2025 08:28:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008119.1387330; Fri, 06 Jun 2025 08: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 1uNSQk-0006x9-3X; Fri, 06 Jun 2025 08:28:02 +0000
Received: by outflank-mailman (input) for mailman id 1008119;
 Fri, 06 Jun 2025 08: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 1uNSQj-0006kQ-9G
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 08:28:01 +0000
Received: from rein-hpcbdc09 (unknown [1.7.42.26])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 25962777-42b0-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 10:27:58 +0200 (CEST)
Received: by rein-hpcbdc09 (Postfix, from userid 1000)
 id 6B6A080C0C9F; Fri,  6 Jun 2025 13:57:54 +0530 (IST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 25962777-42b0-11f0-b894-0df219b8e170
From: Jahan Murudi 
To: xen-devel@lists.xenproject.org
Cc: Jahan Murudi ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH v2] xen/arm: Standardize R-Car platform Kconfig descriptions
Date: Fri,  6 Jun 2025 13:57:35 +0530
Message-Id: <20250606082735.3475058-1-jahan.murudi.zg@renesas.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Change "RCar3/RCar4" to "R-Car Gen3/Gen4" to match official Renesas branding.
Aligns with documentation and industry-standard terminology.

Signed-off-by: Jahan Murudi 
---
 xen/arch/arm/platforms/Kconfig | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig
index 87bf614788..c8bc0bfae3 100644
--- a/xen/arch/arm/platforms/Kconfig
+++ b/xen/arch/arm/platforms/Kconfig
@@ -22,21 +22,23 @@ config QEMU
 	  machine.
 
 config RCAR3
-	bool "Renesas RCar3 support"
+	bool "Renesas R-Car Gen3 support"
 	depends on ARM_64
 	select HAS_SCIF
 	select IPMMU_VMSA
 	help
-	  Enable all the required drivers for Renesas RCar3
+	  Enable support for Renesas R-Car Generation 3 SoCs (H3, M3, etc.).
+	  Includes all required drivers and platform-specific features.
 
 config RCAR4
-	bool "Renesas RCar4 support"
+	bool "Renesas R-Car Gen4 support"
 	depends on ARM_64
 	select HAS_SCIF
 	select HAS_ITS
 	select IPMMU_VMSA
 	help
-	Enable all the required drivers for Renesas RCar4
+	  Enable support for Renesas R-Car Generation 4 SoCs (V4H, V4M, etc.).
+	  Includes all required drivers and platform-specific features.
 
 config MPSOC
 	bool "Xilinx Ultrascale+ MPSoC support"
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Jun 06 08:30:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 08:30:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008128.1387339 (Exim 4.92)
	(envelope-from )
	id 1uNSTT-00008B-It; Fri, 06 Jun 2025 08:30:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008128.1387339; Fri, 06 Jun 2025 08:30: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 1uNSTT-00007w-G9; Fri, 06 Jun 2025 08:30:51 +0000
Received: by outflank-mailman (input) for mailman id 1008128;
 Fri, 06 Jun 2025 08:30: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 1uNSTR-00006e-Nh
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 08:30:49 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on20629.outbound.protection.outlook.com
 [2a01:111:f403:2407::629])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8b0a4cbc-42b0-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 10:30:47 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by SJ2PR12MB9008.namprd12.prod.outlook.com (2603:10b6:a03:543::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.35; Fri, 6 Jun
 2025 08:30:43 +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.8792.034; Fri, 6 Jun 2025
 08:30: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: 8b0a4cbc-42b0-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=rBHmOE3KJ8r9V96uoi0OfISIkEDFL2fQLR5OMeQ8usnu4Uio34UDTIhO85G7x/uOPcJKyUAhhvhlsPG6770SW8GzY9DYhGiOGmXVheMCOLU9l9lWF3ui4x3NjTl4vxTqize98+XuB3USmScZBTZM2fh96h2J1lAUt7C6sq7D2ZmO4A5kowsBjj8jQ/027bGqeG2miPnOqMIJkSJGhlQR3A96p6UXebkEuO2iLoX7tjDXlgRcAZ89dfWURY5uiRKoE1Kbxg8YZohWUS+rXiHlN/0WiRpfdcJK6sNQI4JF3vNDLaQfAGEgBsPwV7uxU0A1r+6YhHS8Q9rZYdnSXEBbgg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=bnJWdfe/SOAy8RCWb6bHzfj8lUUdohWXzMSMUbN/Hec=;
 b=mACYxELJ6SuqBuSRZ1k+4MIsy5zn2UfAV2vBhkPLvCuDQrIqPYzn5WPjJdCdrDlBorrJrTVIZ//eI3yrfO/j4/PBzn93Vypicuu0MYIgDw8nDN6DrDw52hRDKpxc5ZTM2CDYH72xqq07K12YN/MFGxo7eDqFY87WmQ8ZSMPKmtfJT9+/qSEj6cV/N4878NV3SmGiLWn/7vixjluxu1GKGU51ZfJafap24haX8MCiLnVXcqGlOk7SH29qM5FbFGWdZ3ut5X2y1gcgKTGLZzwHN0HVuuvFiwuOzjbndkW5p4mlVGpV7FqQT0UMarRzE/gio1WG9jKEAPmrT/aKH+mDOg==
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=bnJWdfe/SOAy8RCWb6bHzfj8lUUdohWXzMSMUbN/Hec=;
 b=HkMAgO23DMRwAkDCLwsuiPZkpyW7V/50X/dYy0JpE/U+1NpsddwC0b7hmFCaLsO9TXSWi7SSf22E8me4En0rCoANjDzCjhPHW/XEJ89YTZUGH0SC1JC4H0YGOXrr4dJER/9XyRcEm4aZ4YgeIn7aYJHSqoHbQxZYXeEPq2JmQEI=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= 
CC: "xen-devel@lists.xenproject.org" , "Huang,
 Ray" , Andrew Cooper , Anthony
 PERARD , "Orzel, Michal" ,
	Jan Beulich , Julien Grall , Stefano
 Stabellini , "Chen, Jiqian" 
Subject: Re: [PATCH v5 06/10] vpci: Hide extended capability when it fails to
 initialize
Thread-Topic: [PATCH v5 06/10] vpci: Hide extended capability when it fails to
 initialize
Thread-Index: AQHbziMQOFXw7E5CI0yZ6+lzG6YWFbP0tR2AgAGudAA=
Date: Fri, 6 Jun 2025 08:30:42 +0000
Message-ID:
 
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
 <20250526094559.140423-7-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.8792.033)
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_|SJ2PR12MB9008:EE_
x-ms-office365-filtering-correlation-id: c8bfb6b8-e579-4a77-e7ca-08dda4d46cdb
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?NXZJVndTaCtyL0NMWnB2Nnl1L2l0c2Qrb1JJRUdvbllIWU1MOWVISWdoNHRC?=
 =?utf-8?B?aVVPM3dqZStmbzlpdkJZNitCQjA3eTh3Tkh6ZlVPY3VLWUdWS2VmOW1qcDUy?=
 =?utf-8?B?NnRUWnZXMEw4WExhUDE4MGlhODB5cDVhT2tyUUZtNllwM2tBcndpV1Z4bmox?=
 =?utf-8?B?QnRnR3lTWk90VWh2MndpUXVoOTV6eVZCL3c0Uzk0aVJhN3NTam9ld0UvL2s1?=
 =?utf-8?B?a0t4OC96T1l6UC9FYW9Ldm04Rk92U0xEMDVJeTlBQ01qMUZJWTJKeHJLazd6?=
 =?utf-8?B?WkJPdTJIcEl1Qm11bU5taTNnSUhJaWg0M0FYczZxMUQzR28rY2pUYmUzQkRx?=
 =?utf-8?B?NmpPNkNlL1NnVnI2ZWRMQjBoVkdoMUUwRlo4STdHUlBoRWppc2NLdFNld3h5?=
 =?utf-8?B?SUtzUVVwQWJycHNKYkEvUG5ocGFOSGNKQzMxeVRnb0hSeVU1ektiYkJsK2JS?=
 =?utf-8?B?VS9VeW1PVmszMzh4b2JaM2V6cEdadTFiY2UzTmhHRXM4cUFIZlBFTUpYSHor?=
 =?utf-8?B?cHpTeGtYdCtSZkVCQy9YeWttOW1QcytUMG5tM2tRT001T2NldUlEMGdyc21y?=
 =?utf-8?B?VzJFZHFYRG5JTStMamFoYytWMEw2YmlIN0tMM1FEdnVKQnY4bVU0aW8wU1JR?=
 =?utf-8?B?UDF6V3dxMk9RMjJQbDJXLzczTEthZGJHaEh6aEoraForcnIvdHZBa2haOUxT?=
 =?utf-8?B?eEo0U0JiNlBKWjVrU1F2dU5INjlaaXUxOXl2enM3ZjFtQUtrTE9rNllrR3Ax?=
 =?utf-8?B?SFVLSEpoQmxPbnRHaDEzVkhmN1B5TU9XaE9KWlBZSENZM0ZBMisxeDEwbWZ4?=
 =?utf-8?B?bzk5M2gvdGFXNW03Y2dYMHV2OFhPRWY3anplendYTTFTd1JjLzU2UGZGUVNt?=
 =?utf-8?B?QU1YZ1dFU3F4dnF1aGpWd3hKOXQ5VjVQVExMS1ExQUpEeGlXNytUVC9CS3p2?=
 =?utf-8?B?dU1jQWZkVjl2UUtmenBFcmdRS204ME1IZ1JIN3RHYjhmdXVBMGRtRkU0YVhU?=
 =?utf-8?B?ekUyNXNrQlpSZXdZSktLWFNLVTJaQ3hKdnNqS3NXTVFHZmQ0bk9nL0U2ZVBi?=
 =?utf-8?B?bE5FcnhFcS9XbW5qMGxiK2V1Z0tDM0xibnVlNnRFOG1BdEw2Z2Q5MEFXNEpj?=
 =?utf-8?B?R2c4aUdITGhocE9hakhJRmFGRnFKMCtyUkFtUGlCMGZUUS9mamhFc2ZFVFRt?=
 =?utf-8?B?NjVIWjZiV2M3U0RSTnd6MVFoYWlxRXZlSUpwOStzSTJYV2JoSmVrZ1JoVENT?=
 =?utf-8?B?aE9hRm1sZFk2WHUrZFk2emVTTWN6REgzWFd5UjVOSXl3TXRJdVl3UitnenUz?=
 =?utf-8?B?WjFndzNYM0ZYSi9nc1ljS1d3Rmdkc29JaG1xK2JlVFdpNXRHVjNsY2pnYUJs?=
 =?utf-8?B?OXl1RFREWW42SnFScGVleUN2S2lQb1Y2bHplQWNUcU1HV3NoVnY4RkxZMWNt?=
 =?utf-8?B?cGM3eENwdXRTT3BrY3kvZXVDckU2Q1k3K2VuSTh3R2VGaUpwWkJ1cHQzc045?=
 =?utf-8?B?d0tzMUhuZ1lyV3QwY1RMVjNHVHNpYTlHbkdlQk03bjV0MWpLVVhTeGZEd1N1?=
 =?utf-8?B?K2ZyZm9Bckp6NER0UmFMVm9nV2dqTkhmNEVUbWJXNUFhLzBaZDFENjF1a0U0?=
 =?utf-8?B?MHJjUWJjS1V6cWcvbTcvd1ZTQTlXeDYwVlZLcnZITVpLdldYUmxEc2c2ZFNC?=
 =?utf-8?B?NFByYkZkdGFneXVjayswV1hlVENtOFFwamtiZThLaWNTbVlTQU9xMU9FbVVi?=
 =?utf-8?B?V0pXVHBnUWtZNVdDcUpta0RnQkZHYjRLU2doc0FhTHM2OUFQS0FVYjRTR3Vm?=
 =?utf-8?B?WG4xTjdXYmxXOVdrUTI5Znk0b25KY21xQkVxU0h2aThhTnF1S211VGRCYld4?=
 =?utf-8?B?MGFkamtLZUZzY0IvNU0raloyOVRCb2lxbkhoME5aYXVkbFJvR2xCNXNvTDl1?=
 =?utf-8?B?NGtJaEk4VnZRZXY0ZEZQcmFmazFYUUlCdXR0b0JERmhMRGpYalNRaTFTM3BX?=
 =?utf-8?Q?+nsmxbpC3iZrP57+XupaVFbzCN0zeM=3D?=
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?ZmtwTVJ2dmt6TjBFeXgwZmxKeTViMnQ4Mnk5VHBGWkUweXlWWWQ4STdRUFQr?=
 =?utf-8?B?M0FxSzJYK1NEUzk5ZThrSk1GWjdlTUlQV1VxQnFRMzRDODJaQmNPWGZTUHFG?=
 =?utf-8?B?elh2TFQzTVZLUHgvTlowTHQzT0ttbllFYjNCZC8xaFVMcDN0cW5WQ1RTcFZW?=
 =?utf-8?B?OUphQk56dXk0MXpWbUxtdkl3bGdKMjZLUnF4bEJ4cmpncFFJWkFtTkI2djFv?=
 =?utf-8?B?V3BEcmJvM2tJdlpLYnE3MzBCak40bkMyeVlGakg3bTBORVZLV0MzSmowYUp1?=
 =?utf-8?B?cUd4eXp1MGJHY0JsYmRuSjR0MzZHMisvOFdaendlbWNyaEs1eHFNZW5HNmlI?=
 =?utf-8?B?Z0htQVRNWW1GaHlmclJtT0tKc2tyL21GVUVrblZER3NnOEl5Wm40ZkVJaHBn?=
 =?utf-8?B?eG9LeWs0UEJBQllPbFlkajg2NEloQ0NrVGU4MGQxVHBZWGNNbDBTR0QxalQv?=
 =?utf-8?B?cDFVY3JzVk9xT1crNWQvdEQxTXl6V29SSUtabFZXUmowV3NjN3Y2Zkd6Y245?=
 =?utf-8?B?Ni9Ga0hmYXoyejIyZ3FMRmYyVkh6ZWFwOU40WlFiWFEyZDFJTDlUSkZXMHQy?=
 =?utf-8?B?K29iVmw5b3Y3aFpoV1VqcXgreE9LSFUxSEtocnI2Q0pQUGNaSGgwZGJGUXdE?=
 =?utf-8?B?ZmNHaFFUc3FrUnFGUUNRemJqYTFieE5XaVRnNkt6TjRhbExNanlEbmNZMzY1?=
 =?utf-8?B?ZzFGVmNLekZ2K1F5VVFzRDR6dnV0VVZtVDgycnJ1MXNWbmcyU0RDbHRuSEtk?=
 =?utf-8?B?L1hmTjFWVTBQL2dnVnJCZ0NjbnJreHlSM1JHN3ZtTXI0WnZGdk9sMjFFRjI1?=
 =?utf-8?B?SFFTOWpTMmNqbmJjVDBQUlVjd0x3WjJneUI1bGJxWUpGSGxWVTk1NmNLSERC?=
 =?utf-8?B?bXl6UFlUblNISmdDTVpISVI4VGFoMDBwaHhTaFBjZGVWTzBqVTdnWHRNN2xL?=
 =?utf-8?B?WGJPU3UzdGl1VHVxY2JlRE1OUHZ2Q1VYbHJuaWcrbVZPWmo0RHFrdzMrQUxV?=
 =?utf-8?B?UXNMYWl0SGRXTm53Ti9kbFZUdzAyUDB2VkVLT2hJVWgwZ05wMlcrMzZEamN4?=
 =?utf-8?B?Ni9Wd2E4RFhGR2E1RGh5SmZlNHNmZnFvNnZkdUpUVnRZY0x1cDV4eG9FTmd2?=
 =?utf-8?B?UzRoTWpsakVBR1FXRkkvZlcvSFFhTDBjQXBzMEYxQllSVzAwSWM3TUVXOTV3?=
 =?utf-8?B?V2hEWjFUV3o5SUpVdXdtRVoxalJGdFI3V1YycGt3cC80clhrOTFVTlI5U1Fn?=
 =?utf-8?B?WnlSN3BFQVJGbENFZzVnQml6RGxKUnZNWUR5em9nS1VWakpWak1kLytkQjVB?=
 =?utf-8?B?b0dZTTl2RlVuRkkxMnpPVS8yaXBlMFlUclQ2cDdDQldiWWlKUzB4OW0wMVVH?=
 =?utf-8?B?VzNubFJxeUw2VENUMW1aZjdjZ1NkMlJtclA0RjFHQmliV2lybFRQNjNXMGk1?=
 =?utf-8?B?WXdHU0NTOTIvK1dqWkFoNXAzdEtMT0t6a09oYmVqamhwWWFrbXZkbXRFT2tT?=
 =?utf-8?B?aWlVcHNWaTRYRzY2aXZZak1RdDNEU1Q2SVVJaHl5SGZkTndMK1RLT1lEdmd2?=
 =?utf-8?B?NDhBazA1ZitqVWdxb1Y2UWV5WGNxNnBSZUViZlhkdEJuV2luSVlCRFFudG5r?=
 =?utf-8?B?aGI3N2IyMEpTNVgvZzFVYTNDa2tZRjZ3WGV6NjhyLzdyRkZiQWFoSGV2bUYx?=
 =?utf-8?B?UXd2KzhMK3B6Z2RCR0hmNDkvN21sS0VvaU1ETkxvcTl2RWVhNEt3eVFrVW5V?=
 =?utf-8?B?WElmV1QxbXlXMElQT01WOEFtN1VvMWlRcDYrQlQvdStwcnJ2a0FvWUFyUko2?=
 =?utf-8?B?L1ZMM2kyNXR2UytDOTNkWFFKc2RUcjV0S3dHUEtJUGFvQUlUT1JTMjNScUJH?=
 =?utf-8?B?QklmMGg0ZzNaNmpBd3VhblRiYmJOaHVMM3BPUnlFeWthc0NnKzZIdlFuMDJT?=
 =?utf-8?B?RndMWGgxWkF5WnJBa2NsdDFnWS8yR2VUOXp5SmRtK0s2Z0RiNjdRTXpabjFJ?=
 =?utf-8?B?NW82WmRTQStNdXRjdnQwejBmMU1BKzUwK3BWazZvY1NzZWJuamQ5ZkdFQUdB?=
 =?utf-8?B?dVcxWXM0Q1haQ3JrbnNRUE1BbWNQbHZ2Y3h5ZnlweXgzVEZKb21mWlMzSmIv?=
 =?utf-8?Q?zxm8=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <0121CA09580CD14A9EFD77988AEEE606@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: c8bfb6b8-e579-4a77-e7ca-08dda4d46cdb
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2025 08:30:42.2491
 (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: cWqtQj0wx8SizYIPLEft4nYh3ZiXPwXcNc2e/+h57UeE9eC071NAJ9OMhnJQNINGy5LEQNOvewPUf6Jpg+x++g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB9008

T24gMjAyNS82LzUgMjI6NDcsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+IE9uIE1vbiwgTWF5
IDI2LCAyMDI1IGF0IDA1OjQ1OjU1UE0gKzA4MDAsIEppcWlhbiBDaGVuIHdyb3RlOg0KPj4gV2hl
biB2cGNpIGZhaWxzIHRvIGluaXRpYWxpemUgYSBleHRlbmRlZCBjYXBhYmlsaXR5IG9mIGRldmlj
ZSwgaXQNCj4+IGp1c3QgcmV0dXJucyBhbiBlcnJvciBhbmQgdlBDSSBnZXRzIGRpc2FibGVkIGZv
ciB0aGUgd2hvbGUgZGV2aWNlLg0KPj4NCj4+IFNvLCBhZGQgZnVuY3Rpb24gdG8gaGlkZSBleHRl
bmRlZCBjYXBhYmlsaXR5IHdoZW4gaW5pdGlhbGl6YXRpb24NCj4+IGZhaWxzLiBBbmQgcmVtb3Zl
IHRoZSBmYWlsZWQgZXh0ZW5kZWQgY2FwYWJpbGl0eSBoYW5kbGVyIGZyb20gdnBjaQ0KPj4gZXh0
ZW5kZWQgY2FwYWJpbGl0eSBsaXN0Lg0KPj4NCj4+IFNpZ25lZC1vZmYtYnk6IEppcWlhbiBDaGVu
IDxKaXFpYW4uQ2hlbkBhbWQuY29tPg0KPj4gLS0tDQo+PiBjYzogIlJvZ2VyIFBhdSBNb25uw6ki
IDxyb2dlci5wYXVAY2l0cml4LmNvbT4NCj4+IGNjOiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29v
cGVyM0BjaXRyaXguY29tPg0KPj4gY2M6IEFudGhvbnkgUEVSQVJEIDxhbnRob255LnBlcmFyZEB2
YXRlcy50ZWNoPg0KPj4gY2M6IE1pY2hhbCBPcnplbCA8bWljaGFsLm9yemVsQGFtZC5jb20+DQo+
PiBjYzogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KPj4gY2M6IEp1bGllbiBHcmFs
bCA8anVsaWVuQHhlbi5vcmc+DQo+PiBjYzogU3RlZmFubyBTdGFiZWxsaW5pIDxzc3RhYmVsbGlu
aUBrZXJuZWwub3JnPg0KPj4gLS0tDQo+PiB2NC0+djUgY2hhbmdlczoNCj4+ICogTW9kaWZ5IHRo
ZSBoZXggZGlnaXRzIG9mIFBDSV9FWFRfQ0FQX05FWFRfTUFTSyBhbmQgUENJX0VYVF9DQVBfTkVY
VCB0byBiZSBsb3cgY2FzZS4NCj4+ICogUmVuYW1lIHZwY2lfZXh0X2NhcGFiaWxpdHlfbWFzayB0
byB2cGNpX2V4dF9jYXBhYmlsaXR5X2hpZGUuDQo+Pg0KPj4gdjMtPnY0IGNoYW5nZXM6DQo+PiAq
IENoYW5nZSBkZWZpbml0aW9uIG9mIFBDSV9FWFRfQ0FQX05FWFQgdG8gYmUgIiNkZWZpbmUgUENJ
X0VYVF9DQVBfTkVYVChoZWFkZXIpIChNQVNLX0VYVFIoaGVhZGVyLCBQQ0lfRVhUX0NBUF9ORVhU
X01BU0spICYgMHhGRkNVKSIgdG8gYXZvaWQgcmVkdW5kYW5jeS4NCj4+ICogTW9kaWZ5IHRoZSBj
b21taXQgbWVzc2FnZS4NCj4+ICogQ2hhbmdlIHZwY2lfZXh0X2NhcGFiaWxpdHlfbWFzaygpIHRv
IHJldHVybiBlcnJvciBpbnN0ZWFkIG9mIHVzaW5nIEFTU0VSVC4NCj4+ICogU2V0IHRoZSBjYXBh
YmlsaXR5IElEIHBhcnQgdG8gYmUgemVybyB3aGVuIHdlIG5lZWQgdG8gaGlkZSB0aGUgY2FwYWJp
bGl0eSBvZiBwb3NpdGlvbiAweDEwMFUuDQo+PiAqIEFkZCBjaGVjayAiaWYgKCAhb2Zmc2V0ICki
IGluIHZwY2lfZXh0X2NhcGFiaWxpdHlfbWFzaygpLg0KPj4NCj4+IHYyLT52MyBjaGFuZ2VzOg0K
Pj4gKiBTZXBhcmF0ZWQgZnJvbSB0aGUgbGFzdCB2ZXJzaW9uIHBhdGNoICJ2cGNpOiBIaWRlIGNh
cGFiaWxpdHkgd2hlbiBpdCBmYWlscyB0byBpbml0aWFsaXplIi4NCj4+ICogV2hvbGUgaW1wbGVt
ZW50YXRpb24gY2hhbmdlZCBiZWNhdXNlIGxhc3QgdmVyc2lvbiBpcyB3cm9uZy4NCj4+ICAgVGhp
cyB2ZXJzaW9uIGdldHMgdGFyZ2V0IGhhbmRsZXIgYW5kIHByZXZpb3VzIGhhbmRsZXIgZnJvbSB2
cGNpLT5oYW5kbGVycywgdGhlbiByZW1vdmUgdGhlIHRhcmdldC4NCj4+ICogTm90ZTogYSBjYXNl
IGluIGZ1bmN0aW9uIHZwY2lfZXh0X2NhcGFiaWxpdHlfbWFzaygpIG5lZWRzIHRvIGJlIGRpc2N1
c3NlZCwNCj4+ICAgYmVjYXVzZSBpdCBtYXkgY2hhbmdlIHRoZSBvZmZzZXQgb2YgbmV4dCBjYXBh
YmlsaXR5IHdoZW4gdGhlIG9mZnNldCBvZiB0YXJnZXQNCj4+ICAgY2FwYWJpbGl0eSBpcyAweDEw
MFUodGhlIGZpcnN0IGV4dGVuZGVkIGNhcGFiaWxpdHkpLCBteSBpbXBsZW1lbnRhdGlvbiBpcyBq
dXN0IHRvDQo+PiAgIGlnbm9yZSBhbmQgbGV0IGhhcmR3YXJlIHRvIGhhbmRsZSB0aGUgdGFyZ2V0
IGNhcGFiaWxpdHkuDQo+Pg0KPj4gdjEtPnYyIGNoYW5nZXM6DQo+PiAqIFJlbW92ZWQgdGhlICJw
cmlvcml0aWVzIiBvZiBpbml0aWFsaXppbmcgY2FwYWJpbGl0aWVzIHNpbmNlIGl0IGlzbid0IHVz
ZWQgYW55bW9yZS4NCj4+ICogQWRkZWQgbmV3IGZ1bmN0aW9uIHZwY2lfY2FwYWJpbGl0eV9tYXNr
KCkgYW5kIHZwY2lfZXh0X2NhcGFiaWxpdHlfbWFzaygpIHRvDQo+PiAgIHJlbW92ZSBmYWlsZWQg
Y2FwYWJpbGl0eSBmcm9tIGxpc3QuDQo+PiAqIENhbGxlZCB2cGNpX21ha2VfbXNpeF9ob2xlKCkg
aW4gdGhlIGVuZCBvZiBpbml0X21zaXgoKS4NCj4+DQo+PiBCZXN0IHJlZ2FyZHMsDQo+PiBKaXFp
YW4gQ2hlbi4NCj4+IC0tLQ0KPj4gIHhlbi9kcml2ZXJzL3ZwY2kvdnBjaS5jICAgIHwgMTAwICsr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrLS0NCj4+ICB4ZW4vaW5jbHVkZS94ZW4v
cGNpX3JlZ3MuaCB8ICAgNSArLQ0KPj4gIDIgZmlsZXMgY2hhbmdlZCwgMTAwIGluc2VydGlvbnMo
KyksIDUgZGVsZXRpb25zKC0pDQo+Pg0KPj4gZGlmZiAtLWdpdCBhL3hlbi9kcml2ZXJzL3ZwY2kv
dnBjaS5jIGIveGVuL2RyaXZlcnMvdnBjaS92cGNpLmMNCj4+IGluZGV4IDYwZTc2NTRlYzM3Ny4u
MmQ0Nzk0ZmYzZGVhIDEwMDY0NA0KPj4gLS0tIGEveGVuL2RyaXZlcnMvdnBjaS92cGNpLmMNCj4+
ICsrKyBiL3hlbi9kcml2ZXJzL3ZwY2kvdnBjaS5jDQo+PiBAQCAtMTc2LDYgKzE3Niw5OCBAQCBz
dGF0aWMgaW50IHZwY2lfY2FwYWJpbGl0eV9oaWRlKHN0cnVjdCBwY2lfZGV2ICpwZGV2LCB1bnNp
Z25lZCBpbnQgY2FwKQ0KPj4gICAgICByZXR1cm4gMDsNCj4+ICB9DQo+PiAgDQo+PiArc3RhdGlj
IHN0cnVjdCB2cGNpX3JlZ2lzdGVyICp2cGNpX2dldF9wcmV2aW91c19leHRfY2FwX3JlZ2lzdGVy
KA0KPj4gKyAgICBzdHJ1Y3QgdnBjaSAqdnBjaSwgdW5zaWduZWQgaW50IG9mZnNldCkNCj4+ICt7
DQo+PiArICAgIHVpbnQzMl90IGhlYWRlcjsNCj4+ICsgICAgdW5zaWduZWQgaW50IHBvcyA9IFBD
SV9DRkdfU1BBQ0VfU0laRTsNCj4+ICsgICAgc3RydWN0IHZwY2lfcmVnaXN0ZXIgKnI7DQo+PiAr
DQo+PiArICAgIGlmICggb2Zmc2V0IDw9IFBDSV9DRkdfU1BBQ0VfU0laRSApDQo+PiArICAgIHsN
Cj4+ICsgICAgICAgIEFTU0VSVF9VTlJFQUNIQUJMRSgpOw0KPj4gKyAgICAgICAgcmV0dXJuIE5V
TEw7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgciA9IHZwY2lfZ2V0X3JlZ2lzdGVyKHZwY2ks
IHBvcywgNCk7DQo+PiArICAgIGlmICggIXIgKQ0KPj4gKyAgICAgICAgcmV0dXJuIE5VTEw7DQo+
PiArDQo+PiArICAgIGhlYWRlciA9ICh1aW50MzJfdCkodWludHB0cl90KXItPnByaXZhdGU7DQo+
PiArICAgIHBvcyA9IFBDSV9FWFRfQ0FQX05FWFQoaGVhZGVyKTsNCj4+ICsgICAgd2hpbGUgKCBw
b3MgPiBQQ0lfQ0ZHX1NQQUNFX1NJWkUgJiYgcG9zICE9IG9mZnNldCApDQo+PiArICAgIHsNCj4+
ICsgICAgICAgIHIgPSB2cGNpX2dldF9yZWdpc3Rlcih2cGNpLCBwb3MsIDQpOw0KPj4gKyAgICAg
ICAgaWYgKCAhciApDQo+PiArICAgICAgICAgICAgcmV0dXJuIE5VTEw7DQo+PiArICAgICAgICBo
ZWFkZXIgPSAodWludDMyX3QpKHVpbnRwdHJfdClyLT5wcml2YXRlOw0KPj4gKyAgICAgICAgcG9z
ID0gUENJX0VYVF9DQVBfTkVYVChoZWFkZXIpOw0KPj4gKyAgICB9DQo+PiArDQo+PiArICAgIGlm
ICggcG9zIDw9IFBDSV9DRkdfU1BBQ0VfU0laRSApDQo+PiArICAgICAgICByZXR1cm4gTlVMTDsN
Cj4gDQo+IFNhbWUgY29tbWVudCBhcyBpbiB0aGUgcHJldmlvdXMgcGF0Y2gsIEkgdGhpbmsgdGhl
IHByb3Bvc2VkIGZvciBsb29wDQo+IHRoZXJlIGNhbiBhbHNvIGJlIHVzZWQgaGVyZSB0byByZWR1
Y2UgYSBiaXQgdGhlIGNvZGUgc2l6ZSAoYW5kIHVuaWZ5DQo+IHRoZSByZXR1cm4gcGF0aHMpLg0K
PiANCj4+ICsNCj4+ICsgICAgcmV0dXJuIHI7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyBpbnQg
dnBjaV9leHRfY2FwYWJpbGl0eV9oaWRlKHN0cnVjdCBwY2lfZGV2ICpwZGV2LCB1bnNpZ25lZCBp
bnQgY2FwKQ0KPj4gK3sNCj4+ICsgICAgY29uc3QgdW5zaWduZWQgaW50IG9mZnNldCA9IHBjaV9m
aW5kX2V4dF9jYXBhYmlsaXR5KHBkZXYtPnNiZGYsIGNhcCk7DQo+PiArICAgIHN0cnVjdCB2cGNp
X3JlZ2lzdGVyICpybSwgKnByZXZfcjsNCj4gDQo+IHMvcm0vci8NCj4gDQo+PiArICAgIHN0cnVj
dCB2cGNpICp2cGNpID0gcGRldi0+dnBjaTsNCj4+ICsgICAgdWludDMyX3QgaGVhZGVyLCBwcmVf
aGVhZGVyOw0KPj4gKw0KPj4gKyAgICBpZiAoICFvZmZzZXQgKQ0KPiANCj4gSSB0aGluayB5b3Ug
d2FudCBvZmZzZXQgPCBQQ0lfQ0ZHX1NQQUNFX1NJWkUgaGVyZT8NCj4gDQo+PiArICAgIHsNCj4+
ICsgICAgICAgIEFTU0VSVF9VTlJFQUNIQUJMRSgpOw0KPj4gKyAgICAgICAgcmV0dXJuIDA7DQo+
PiArICAgIH0NCj4+ICsNCj4+ICsgICAgc3Bpbl9sb2NrKCZ2cGNpLT5sb2NrKTsNCj4+ICsgICAg
cm0gPSB2cGNpX2dldF9yZWdpc3Rlcih2cGNpLCBvZmZzZXQsIDQpOw0KPj4gKyAgICBpZiAoICFy
bSApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIHNwaW5fdW5sb2NrKCZ2cGNpLT5sb2NrKTsNCj4+
ICsgICAgICAgIHJldHVybiAtRU5PREVWOw0KPj4gKyAgICB9DQo+PiArDQo+PiArICAgIGhlYWRl
ciA9ICh1aW50MzJfdCkodWludHB0cl90KXJtLT5wcml2YXRlOw0KPj4gKyAgICBpZiAoIG9mZnNl
dCA9PSBQQ0lfQ0ZHX1NQQUNFX1NJWkUgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBpZiAoIFBD
SV9FWFRfQ0FQX05FWFQoaGVhZGVyKSA8PSBQQ0lfQ0ZHX1NQQUNFX1NJWkUgKQ0KPj4gKyAgICAg
ICAgICAgIHJtLT5wcml2YXRlID0gKHZvaWQgKikodWludHB0cl90KTA7DQo+PiArICAgICAgICBl
bHNlDQo+PiArICAgICAgICAgICAgLyoNCj4+ICsgICAgICAgICAgICAgKiBJZiB0aGlzIGNhc2Ug
cmVtb3ZlcyB0YXJnZXQgY2FwYWJpbGl0eSBvZiBwb3NpdGlvbiAweDEwMFUsIHRoZW4NCj4+ICsg
ICAgICAgICAgICAgKiBpdCBuZWVkcyB0byBtb3ZlIHRoZSBuZXh0IGNhcGFiaWxpdHkgdG8gYmUg
aW4gcG9zaXRpb24gMHgxMDBVLA0KPj4gKyAgICAgICAgICAgICAqIHRoYXQgd291bGQgY2F1c2Ug
dGhlIG9mZnNldCBvZiBuZXh0IGNhcGFiaWxpdHkgaW4gdnBjaSBkaWZmZXJlbnQNCj4+ICsgICAg
ICAgICAgICAgKiBmcm9tIHRoZSBoYXJkd2FyZSwgdGhlbiBjYXVzZSBlcnJvciBhY2Nlc3Nlcywg
c28gaGVyZSBjaG9vc2VzIHRvDQo+PiArICAgICAgICAgICAgICogc2V0IHRoZSBjYXBhYmlsaXR5
IElEIHBhcnQgdG8gYmUgemVyby4NCj4gDQo+IC8qDQo+ICAqIFRoZSBmaXJzdCBleHRlbmRlZCBj
YXBhYmlsaXR5ICgweDEwMCkgY2Fubm90IGJlIHJlbW92ZWQgZnJvbSB0aGUgbGlua2VkDQo+ICAq
IGxpc3QsIHNvIGluc3RlYWQgbWFzayBpdHMgY2FwYWJpbGl0eSBJRCB0byByZXR1cm4gMCBhbmQg
Zm9yY2UgT1Nlcw0KPiAgKiB0byBza2lwIGl0Lg0KPiAgKi8NCj4gDQo+IElzIHNpbXBsZXIgSU1P
IGFuZCBjb252ZXlzIHRoZSBzYW1lIG1lc3NhZ2UuDQo+IA0KPj4gKyAgICAgICAgICAgICAqLw0K
Pj4gKyAgICAgICAgICAgIHJtLT5wcml2YXRlID0gKHZvaWQgKikodWludHB0cl90KShoZWFkZXIg
Jg0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB+UENJ
X0VYVF9DQVBfSUQoaGVhZGVyKSk7DQo+PiArDQo+PiArICAgICAgICBzcGluX3VubG9jaygmdnBj
aS0+bG9jayk7DQo+PiArICAgICAgICByZXR1cm4gMDsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAg
ICBwcmV2X3IgPSB2cGNpX2dldF9wcmV2aW91c19leHRfY2FwX3JlZ2lzdGVyKHZwY2ksIG9mZnNl
dCk7DQo+PiArICAgIGlmICggIXByZXZfciApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIHNwaW5f
dW5sb2NrKCZ2cGNpLT5sb2NrKTsNCj4+ICsgICAgICAgIHJldHVybiAtRU5PREVWOw0KPj4gKyAg
ICB9DQo+PiArDQo+PiArICAgIHByZV9oZWFkZXIgPSAodWludDMyX3QpKHVpbnRwdHJfdClwcmV2
X3ItPnByaXZhdGU7DQo+PiArICAgIHByZXZfci0+cHJpdmF0ZSA9ICh2b2lkICopKHVpbnRwdHJf
dCkoKHByZV9oZWFkZXIgJg0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB+UENJX0VYVF9DQVBfTkVYVF9NQVNLKSB8DQo+PiArICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgKGhlYWRlciAmIFBDSV9FWFRfQ0FQX05FWFRfTUFTSykp
Ow0KPiANCj4gTm8gc3Ryb25nIG9waW5pb24gKGFuZCB5b3VyIGNvZGUgaXMgY29ycmVjdCksIGJ1
dCBpdCBtaWdodCBiZSBlYXNpZXINCj4gdG8gcmVhZCBhczoNCj4gDQo+IHByZV9oZWFkZXIgJj0g
flBDSV9FWFRfQ0FQX05FWFRfTUFTSzsNCj4gcHJlX2hlYWRlciB8PSBoZWFkZXIgJiBQQ0lfRVhU
X0NBUF9ORVhUX01BU0s7DQo+IHByZXZfci0+cHJpdmF0ZSA9ICh2b2lkICopKHVpbnRwdHJfdClw
cmVfaGVhZGVyOw0KPiANCj4gSXQncyBzdGlsbCB0cmVlIGxpbmVzIG9mIGNvZGUgYXQgdGhlIGVu
ZC4gIEkgd291bGQgYWxzbyBhZGQgYSBuZXdsaW5lDQo+IHRvIHNlcGFyYXRlIGZyb20gdGhlIHJl
bW92YWwgb2Ygcm0uDQo+IA0KPj4gKyAgICBsaXN0X2RlbCgmcm0tPm5vZGUpOw0KPj4gKyAgICBz
cGluX3VubG9jaygmdnBjaS0+bG9jayk7DQo+PiArICAgIHhmcmVlKHJtKTsNCj4gDQo+IE5ld2xp
bmUgYmVmb3JlIHRoZSByZXR1cm4gcHJlZmVyYWJseS4NCldpbGwgY2hhbmdlIG15IHBhdGNoIGFj
Y29yZGluZyB0byBhbGwgeW91ciBjb21tZW50cy4NCg0KPiANCj4+ICsgICAgcmV0dXJuIDA7DQo+
PiArfQ0KPj4gKw0KPj4gIHN0YXRpYyBpbnQgdnBjaV9pbml0X2NhcGFiaWxpdGllcyhzdHJ1Y3Qg
cGNpX2RldiAqcGRldikNCj4+ICB7DQo+PiAgICAgIGZvciAoIHVuc2lnbmVkIGludCBpID0gMDsg
aSA8IE5VTV9WUENJX0lOSVQ7IGkrKyApDQo+PiBAQCAtMjA5LDExICszMDEsMTEgQEAgc3RhdGlj
IGludCB2cGNpX2luaXRfY2FwYWJpbGl0aWVzKHN0cnVjdCBwY2lfZGV2ICpwZGV2KQ0KPj4gICAg
ICAgICAgICAgICAgICAgICBwZGV2LT5kb21haW4sICZwZGV2LT5zYmRmLA0KPj4gICAgICAgICAg
ICAgICAgICAgICBpc19leHQgPyAiZXh0ZW5kZWQiIDogImxlZ2FjeSIsIGNhcCk7DQo+PiAgICAg
ICAgICAgICAgaWYgKCAhaXNfZXh0ICkNCj4+IC0gICAgICAgICAgICB7DQo+PiAgICAgICAgICAg
ICAgICAgIHJjID0gdnBjaV9jYXBhYmlsaXR5X2hpZGUocGRldiwgY2FwKTsNCj4+IC0gICAgICAg
ICAgICAgICAgaWYgKCByYyApDQo+PiAtICAgICAgICAgICAgICAgICAgICByZXR1cm4gcmM7DQo+
PiAtICAgICAgICAgICAgfQ0KPj4gKyAgICAgICAgICAgIGVsc2UNCj4+ICsgICAgICAgICAgICAg
ICAgcmMgPSB2cGNpX2V4dF9jYXBhYmlsaXR5X2hpZGUocGRldiwgY2FwKTsNCj4+ICsgICAgICAg
ICAgICBpZiAoIHJjICkNCj4+ICsgICAgICAgICAgICAgICAgcmV0dXJuIHJjOw0KPiANCj4gQ291
bGQgdGhlIGNvZGUgaW4gdGhlIHByZXZpb3VzIHBhdGNoIGJlOg0KPiANCj4gaWYgKCAhaXNfZXh0
ICkNCj4gICAgIHJjID0gdnBjaV9jYXBhYmlsaXR5X2hpZGUocGRldiwgY2FwKTsNCj4gDQo+IGlm
ICggcmMgKQ0KPiAgICAgcmV0dXJuIHJjOw0KPiANCj4gU28gdGhhdCB5b3VyIGludHJvZHVjdGlv
biBoZXJlIGlzIHNpbXBsZXI/DQpPSywgYnV0IHRoZSBsb2dpYyBvZiB0aGUgcHJldmlvdXMgcGF0
Y2ggd2lsbCBiZWNvbWUgYSBsaXR0bGUgc3RyYW5nZS4NCkFueXdheSwgdGhlIHN0cmFuZ2Ugd2ls
bCBkaXNhcHBlYXIgYWZ0ZXIgYXBwbHlpbmcgdGhpcyBwYXRjaC4NCg0KPiANCj4gVGhhbmtzLCBS
b2dlci4NCg0KLS0gDQpCZXN0IHJlZ2FyZHMsDQpKaXFpYW4gQ2hlbi4NCg==


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 08:32:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 08:32:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008138.1387350 (Exim 4.92)
	(envelope-from )
	id 1uNSUm-0000kJ-04; Fri, 06 Jun 2025 08:32:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008138.1387350; Fri, 06 Jun 2025 08:32: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 1uNSUl-0000kC-TW; Fri, 06 Jun 2025 08:32:11 +0000
Received: by outflank-mailman (input) for mailman id 1008138;
 Fri, 06 Jun 2025 08:32: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 1uNSUk-0000k2-UD
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 08:32:10 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20613.outbound.protection.outlook.com
 [2a01:111:f403:2412::613])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bb4a64ba-42b0-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 10:32:08 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by PH0PR12MB7931.namprd12.prod.outlook.com (2603:10b6:510:289::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.29; Fri, 6 Jun
 2025 08:32:04 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8792.034; Fri, 6 Jun 2025
 08:32: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: bb4a64ba-42b0-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=niKRyPSuas780ImQN6DcoiH0q5HCS+NAlwTr8/8Zu3YC0TALwiOUHkQsm6qRtCnLvxjeDjdA9lFVOeTPgarK7K0sn1ognbHVH80VyPxJXtDXxGOTGrgBaOJNHTosvplqRH2QA4fSR+ooAZdaZi1DyWF4EYqS9ZOZidwANFDMWdvi7j/A3UIHPoDORlfwVbODAGm/6t0sMuIDlweqfvc4Tu2vAb5wreInVsb4gBYRh1UEqmrr88R2DfwPKIepw16VAqHJ4RA1SQA1WCBxTGUD98fqMfXlCzyAeHiB+Q6xr7fXtWi98uroZpMf47GvZ95Asj035ioy2JUsfjRizdJqgQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=N/TCQW1pd3VI+rRHtffuWj3s8ar1Gu95HAPmXHB6XyI=;
 b=DHy1401XYBIKaSnVIS94Gm9Dy6zRAfXQA75WkAfm4fiQNqW2apuPUMPTexCBpWd3E63ZiXb9fzopmX7Hqz9sZjHUc/0YzdoBRfSmUtn2XjG7RK5yBq/NYsZp1AUP5fBwqxHM9NKzD32b+iQWQnZUy49AXAe2q+wv3/Xu6fhKOofn/VEK8z2PE/ybwBrIez6b7zqTRkLgSYzIzzSzelH4IWm81SmsY4ByHAEFZVqZSV9fzCDqTkAXg81bhseJZ5AaALwopkNPgrHSaC1Rhl84+o0LfnyEtj4q6FjaJWauwbf8aA0gOQJ7p6wlzcvWuXjHL460Y3Kh+KQbes4vQw8iPw==
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=N/TCQW1pd3VI+rRHtffuWj3s8ar1Gu95HAPmXHB6XyI=;
 b=Jn5NooB6ZjWQoXfhaPGtRnm1CYbePKZKCkZYgmLbkgiH64JEnhDZ+5/gtJ6XlIqeNp39508L6z+kO9KaEVtFTvhJwBrHlPF691W6QCpOIQSQxgiWiAjQttyod3XF1E5MP64uoQsL4WdAEqD2DH96f0CYKGhqpxfqdooDdV1Wor8=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Fri, 6 Jun 2025 10:32:01 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen/arm: Standardize R-Car platform Kconfig
 descriptions
To: Jahan Murudi , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250606082735.3475058-1-jahan.murudi.zg@renesas.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250606082735.3475058-1-jahan.murudi.zg@renesas.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: DU2PR04CA0296.eurprd04.prod.outlook.com
 (2603:10a6:10:28c::31) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|PH0PR12MB7931:EE_
X-MS-Office365-Filtering-Correlation-Id: ab03fdd6-4c3a-49fa-021e-08dda4d49de3
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?M0R4TnZQUjN4dk5Rbjc0Q0lGWWJMcmY0RWdnY3cwb05wemRCTXF2bFY5clZQ?=
 =?utf-8?B?MDF4S3ZQUEtDYjN2a0VFanVqSkRrdy9mdHB5Tm9rSjZhYlI1Wit6bms0Mkh5?=
 =?utf-8?B?Q1FEV0c1akMyVDhXUkJzOVZobEVqMkY1N3YrTlJZOGRGb01INWY4NHZXZDR2?=
 =?utf-8?B?cnVmMmRMQ20zZmFXNCtQRVBLaWwyRXFidDZyeGV3emw5Ymk2YVVNcnRLZ0cz?=
 =?utf-8?B?VWhoZURNeFUzS1FPZE0ydkMyVnlKR1llMTQybWZ2V2pVc0RaM2hZMElsME1s?=
 =?utf-8?B?R0VlZzF0akJwallMVldXeEFJYlR6VlQxVlRuMDMxL3VKMXNOTmJJOGNIbyth?=
 =?utf-8?B?NGQ5LzJDRkhoeTVtblZXZ1J2Zm9lTWRQRTA4amhiN0hid1QyclNhb0lJQWxE?=
 =?utf-8?B?QWNwZFRZMkd4VHZsbzF0MEpzVmxjT0tNbHJDZk1SVHVTMk1IUUJmd2VDMC9x?=
 =?utf-8?B?N2ZhTGtMS3ZKd0xmOHpOTGhIUjkzUnMxZVhwb3Y5dmxzK2lNMU01MERheElJ?=
 =?utf-8?B?SVJCbFI2S2lxT2VUNUhBKzBQNm9RTkhvaXg0bk4xS1ZUejBXNUg0b3EvaHJE?=
 =?utf-8?B?Z0xzWTllSEZqeHlSUHVXN3FOdVdEc05Xd3J4OVQreWN6REJweGtxL1dKSUV2?=
 =?utf-8?B?Ymx0b2FydjNZbHRObVlqQ0lXWHJkMnFSbkdrdlRkTUFIbUhXUHY4ZUVaRHNH?=
 =?utf-8?B?azltdmZXS0ZBcm1ZWWUwS0trWE1xQU5hanVMc2dVaWV6ZEwrdnBiR2lOTHB3?=
 =?utf-8?B?NHVkZmw5bmRsRW05K3NGVE1qeHJJOEVMbjBzU1FkcWxqazZOVlZFbUJHZ21T?=
 =?utf-8?B?L3JXakcyRHRvOXMvMHBpMlExbzVWWTZmZG92MjVNSGppcUpxeW5EQ1NyYWhn?=
 =?utf-8?B?VGNYMTl2REFDNytLbmdMc2doYnYyRlhSRDR0cDVRMG1jYzgvZFZGZEg0Z1dt?=
 =?utf-8?B?VzRXSks5RWoyVlUvejZsMVRSR2ZranhocTRSNDNKS2VWSVJvRGpIVzJHQ1BD?=
 =?utf-8?B?Z0ZLajkvM2FDL3dieTN2b1dFbTM2UStBVjBtU1hQYzRXMDNJYU1seGZsUWVt?=
 =?utf-8?B?Q1VLMkVzZThmZkFXQ3VodzZSS3lBYTdWTGtKbmtITzNtY04rRXFQR0hSb0NF?=
 =?utf-8?B?WDdWWkhMVXozaG1VeDZud2FMMk9sT2JlQTRxaTBPemJibFc0T2NCbG5iTlQ0?=
 =?utf-8?B?bDhRZzVQVHhERFMzWUV3NFQ3eFFnQS9Zd1BzcWhYV1dUa0w1c29teHRML2RW?=
 =?utf-8?B?SzQvZFB2VFVDUmlIQmhPcFV1dDhPaEJuQ25xMmtKejBuREF2am9GOVNIcHk3?=
 =?utf-8?B?MFVmSHJ1bm5MNXdPbkN5SHNIdGpVaVdTVFVTa3RycllFVlQyQ1diZ0lQdXVK?=
 =?utf-8?B?b1NFUHArcGtLUjcxY0JOVjA3UHlNQnRzUk4vZXFqclZHU3pIMll6cjJmTFQ5?=
 =?utf-8?B?N2xrdmxhTTBFYUtzK0JSUXBWUnIya2hUMXZpWnJwdzQ3M2k5NFdqTUY3TCtQ?=
 =?utf-8?B?MnBJeGlUT0JTb0NVUk1MbHJXSC9wOEsrcE4rRS9NTVh6YjFOYWdCeE1rMERM?=
 =?utf-8?B?cDdvTzlKZ21IbnlOaHhsOTRadHFGek1haVZCYjF2OGMzblU0VVAvQ2s0MFZZ?=
 =?utf-8?B?cUlrNCt5KzU4Tllsbm9lem9RWnRyR2o5ZHZteFR5SGdwMGNZQzZLMjBMSi9l?=
 =?utf-8?B?STNFUkNpZ2JMcEVmYUZTQVRkcE9HME52anI3eVorcTVIWDBjbjBaaEJBa21o?=
 =?utf-8?B?aGpOcVMrQStUcUl2RmEzT091bjM3c2dKMWJzVWY2NmF4aHdLWXlkYTdmbFhX?=
 =?utf-8?B?bmVFOEppdlp5K3N2bHg2WUNSK3d2R2V0RzhIZ2pCb3RQZjRVL0NxSWNrUmtF?=
 =?utf-8?B?bjNQSFJBVldEZDJNWXROZ21vUHBSbmoxTGNSQmx0TXJGTE5sRjR2cVBFZml6?=
 =?utf-8?Q?b0x5Kip6Qf0=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?dXRvMFlBNUphRlZpblpyWk1kQ1lyOW96cjYyTVBZTXpHRFFxMGFaZEpqcE1h?=
 =?utf-8?B?bmdGZkgwZVRsQ0RoRHE0d2UyNUhoeVFZQXhvU0kzeWlJRHRmMEFnby9hSzl1?=
 =?utf-8?B?R3hXMi9JUDFBak9nUW0xSUhseG82UTJjMCtneU0wYzBzNHExTDVsSFZlUnBz?=
 =?utf-8?B?cUpwaENQWFVWMHl3R1ljVWdJYXg2b1N3WStDNmd2WXEzbThjTUtNcWx0YnJ0?=
 =?utf-8?B?Y3JjV2FISTNnOHMyYW0xUG9FMjBWckMwb0pxWFZCU1puWGZDSEp5VlNmaERO?=
 =?utf-8?B?SE1rRlhtS3hLNkZCVmpFRUpONHlORllLcTVsYXNtMTFiOVpBbHNqdlV5R1RI?=
 =?utf-8?B?SGxBTTdGbUNrMFZGOWZkdDVzVXN1T1BzYXFEdHEzNkhIMjRHVkhDOFRkWVdw?=
 =?utf-8?B?UXFscEhlbndKMjJuaHlSZXlWdkF0Uy8xN0FDNUx2Zm1UUG5jM3BvTWdTTk9U?=
 =?utf-8?B?Q3Z2eFdlR1Y0QmwyOExUM3hpOWFtVlFlWno5RThvTEVEeDV6NDRNK0pNa3Bp?=
 =?utf-8?B?YlFoQmZLTXZtNHBEbHR4ZkZGbml3bXVpREZGTUx3MzRDVEtWRjEzYndkUkhi?=
 =?utf-8?B?amdqQ3hrQkw3cmxFZUlWclJkSmRKdnRLV3FxeEVVTjgyUllRS0hhK295T1V6?=
 =?utf-8?B?WHFxVUhBUE5oR1l4NzNwQUtQdEpPSStVeVhrMXprcTl6ajNwL25OdTZPRTZw?=
 =?utf-8?B?YmVlZENRY1ZaQlZzMmN6cFlSNUQ2OUZBaFhvUHl0dVZnY1ZSL25DeHFHVWJG?=
 =?utf-8?B?dWl3K29pZHZ1aUkwYlpxUmhQajJHRHV5VU0relRnTktWRm5pbmpiTXI4Znp5?=
 =?utf-8?B?bld0akhtYzlmWUk2V1FabHZOeW1ZQzhWRTUzN3NXdzZ0eDBrVFFjQmV6dE04?=
 =?utf-8?B?SjdpOU5taWRXSWlCNWhkRU5BcHF5UFl1a3cwTkRHZllsQUxZYnJ6UWJscmlU?=
 =?utf-8?B?VUNjNHQzMm1VRjQ5V0xpbmF5djluNlcxOW5OZ1hHODNNTnBKd2E1NU9QWVVT?=
 =?utf-8?B?SGswT0JKZXFsUUsxek1OeGowWWlKekJXME4vWjM2TnRlUlh2S01rMnNhcVNV?=
 =?utf-8?B?VnczdGhQTWl1MS9URVdQNDIrQXZNeTJtSkFhN1k5bWZqa1h2c1ZSalBRM2Ns?=
 =?utf-8?B?ZDgxeU1RcHk2cnpHeWdRYkFSUWhCRGk4OU9wYmxZS3M4aGlNU3RLYVg0a1Yr?=
 =?utf-8?B?V21yOTl5VlQxdUx3UThuczZDL1ByRHZUUEoxRDBUWGxLOGlGS3hxRmVBYzYr?=
 =?utf-8?B?ZVR4NkRtT2FFYkNlTCt5WU5oelVEU0VOWmxsTGw2cFpJVnhjRUl4ZmdUbUl6?=
 =?utf-8?B?M3ArdXdKaWNvS0o4ZmIrdzgxcFZ3UGJGU1ROUFhxZlVkdHRvR3JNVXArZEhn?=
 =?utf-8?B?emNNcThvVjQvb2dxTnROZmNSZlN5OEN2M2EzVS94Z2MyYWhqay9Zc2JDSjNj?=
 =?utf-8?B?MDBxbWl6Ym1RMmtaY3c4bHphWEhSQmNKRHoxdXNFbnZTbm1EL1BPUmdkdytR?=
 =?utf-8?B?R05NN2pZV3QyUzF6L0lRMFVoSnBIMkQ5R00xakNDbTJhSTRNWmlvUEVPelFt?=
 =?utf-8?B?azdqS3pia0FQcWdKMWF3ZndnYWhCVG9Yb1BkbFJxTnZwd0lkVjBFMWNSYWFJ?=
 =?utf-8?B?c1NYYnlBVGFYWjAvODM0OGpxNk53eHBmenJlTzMzb0U0SHY5eEFPOWUrQ3ZD?=
 =?utf-8?B?bm1wOHFnL0FabGtKWThQbFhLN1NIOTU4WEF0RnhMaWJaOXBkMkRwWXgxVEth?=
 =?utf-8?B?K1VDNFhncHhTRTN2S2J2ZDAzSTVLQ1oyY3lLUWdYeWxLZXdaRmw4K2U3Ukc2?=
 =?utf-8?B?MFhiMlNyWFFFWHREV2lMNWlyZ09DbVo0d1RQL2h6dGIvRnlVSUtRclIyNW4z?=
 =?utf-8?B?MVFsdlF4TmZWNmpNRkdST1B1SGpkbkdKNkM2aVVsejgwMnhldW1Nci9HdWxw?=
 =?utf-8?B?VDZvR2RZMWd1UDJPN3p0QjNodHB5STF5cThJaXFOeUg2cXpLdVhsN3VzbGpV?=
 =?utf-8?B?MlFpUHUwbkpDQ05nNkxSdTU5Y25MWXpManpYZVkvbzlVS0pFU1VFRTQvK2Rr?=
 =?utf-8?B?RDJsZ3RyOU4yMFg3bjdKL1ZXTmI5VzFWR3RVK1hqbUxwL3RrNUs5Zm1aTWhX?=
 =?utf-8?Q?ooxU=3D?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ab03fdd6-4c3a-49fa-021e-08dda4d49de3
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jun 2025 08:32:04.6752
 (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: QnYi7GRuIEtD3YwxeSdXjBllTPc/uBUXxDzg0xL4xejiWEzCPIpkAp7YooSwV3zH
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB7931



On 06/06/2025 10:27, Jahan Murudi wrote:
> Change "RCar3/RCar4" to "R-Car Gen3/Gen4" to match official Renesas branding.
> Aligns with documentation and industry-standard terminology.
> 
> Signed-off-by: Jahan Murudi 
I already gave Rb in v1, so you should have picked it.

Reviewed-by: Michal Orzel 

~Michal

> ---
>  xen/arch/arm/platforms/Kconfig | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig
> index 87bf614788..c8bc0bfae3 100644
> --- a/xen/arch/arm/platforms/Kconfig
> +++ b/xen/arch/arm/platforms/Kconfig
> @@ -22,21 +22,23 @@ config QEMU
>  	  machine.
>  
>  config RCAR3
> -	bool "Renesas RCar3 support"
> +	bool "Renesas R-Car Gen3 support"
>  	depends on ARM_64
>  	select HAS_SCIF
>  	select IPMMU_VMSA
>  	help
> -	  Enable all the required drivers for Renesas RCar3
> +	  Enable support for Renesas R-Car Generation 3 SoCs (H3, M3, etc.).
> +	  Includes all required drivers and platform-specific features.
>  
>  config RCAR4
> -	bool "Renesas RCar4 support"
> +	bool "Renesas R-Car Gen4 support"
>  	depends on ARM_64
>  	select HAS_SCIF
>  	select HAS_ITS
>  	select IPMMU_VMSA
>  	help
> -	Enable all the required drivers for Renesas RCar4
> +	  Enable support for Renesas R-Car Generation 4 SoCs (V4H, V4M, etc.).
> +	  Includes all required drivers and platform-specific features.
>  
>  config MPSOC
>  	bool "Xilinx Ultrascale+ MPSoC support"



From xen-devel-bounces@lists.xenproject.org Fri Jun 06 08:32:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 08:32:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008144.1387361 (Exim 4.92)
	(envelope-from )
	id 1uNSVG-0001Da-8k; Fri, 06 Jun 2025 08:32:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008144.1387361; Fri, 06 Jun 2025 08:32:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNSVG-0001DT-4J; Fri, 06 Jun 2025 08:32:42 +0000
Received: by outflank-mailman (input) for mailman id 1008144;
 Fri, 06 Jun 2025 08:32: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 1uNSVF-0000k2-26
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 08:32:41 +0000
Received: from NAM02-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam02on20605.outbound.protection.outlook.com
 [2a01:111:f403:2405::605])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cdc7529d-42b0-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 10:32:39 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by SJ2PR12MB9008.namprd12.prod.outlook.com (2603:10b6:a03:543::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.35; Fri, 6 Jun
 2025 08:32:36 +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.8792.034; Fri, 6 Jun 2025
 08:32: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: cdc7529d-42b0-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ax9NaYCk2HAXr155pC/gberOicZIj/zHtoXzYHpKobnuldNGkkjynnaFwmLN6Kqi5gVVDNNC+Buj1vNe2gRbrWFWeaVUy2L4dZ++Lg/vNHK09iAoNUxmNzlwKxhcfGnOhF6+4m/cKntamnhfluaW21piwdiOBj2exlFNWpQw0jwcr3TI1ZhojmP7Z5j2OAcn19ebww2ltRxdtwW+fqk7JW9P/VfCU6jUR+WL1BCgSFTvyChlo4eFzTLfbzC6nj1BsCberNVhjBCh9Bl6yHpy0Jmrg9O4S+30DdNcndU+6ZBONVJyGiD4gMI7hhXssp16a+mXuwOhg8O/nRnQ0JjDCQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=1GpoamSMunsvFeR74MN8OcfzZgcA+45yqhKevz0JsSs=;
 b=aQfPYdDlW/99RVgeqwzZRBIbeL9eHNjW/D9lzOj5B59sKDuJIMQPSA3AxD2RJ5Sb9KBuGEMlPe7CshcqbdgwtteNV7JapdfZyWPPnHaz7hbmT3wqFppjg96sBRknHq0YUlD1WzxByWL+XWWc3kpTNjITT2ZRw/NbZgOg63tn9Zo1CV03YMCU5qXLbI4KRP5Z1xgX4kaNfNndrmYHScuFS+i2F0Nps1T8dLtAqycsllDoQUTOX5VWlyMuB+3RgXTpCJrjDcSplLaVSTMxuaIa0xByN5ewrZyZztK+WKYTysH/p9X92JT0NB0PP5bQPxc17rTedWc2HE6keHkDNCoyuw==
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=1GpoamSMunsvFeR74MN8OcfzZgcA+45yqhKevz0JsSs=;
 b=CDz2Qaha7uJkqpOAAcptA9jhIEyh+Njk/uQnp4avhBVNQFevWpuqQFGN2qz3iJLrT9vrp5d7TEwM4ENLvFQsD0g8L4AP3lDGzmZTLAbEge8JePNtXv1Qf1A1yAVpEgEuMqRy/4mTU/uBXb1H8kyPptdiE6hKA9IBc30XfrydxUE=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= 
CC: "xen-devel@lists.xenproject.org" , "Huang,
 Ray" , "Chen, Jiqian" 
Subject: Re: [PATCH v5 08/10] vpci/rebar: Free Rebar resources when
 init_rebar() fails
Thread-Topic: [PATCH v5 08/10] vpci/rebar: Free Rebar resources when
 init_rebar() fails
Thread-Index: AQHbziMRPzOlFqwgb0K+e9/00F6hg7P0vO6AgAGnwoA=
Date: Fri, 6 Jun 2025 08:32:35 +0000
Message-ID:
 
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
 <20250526094559.140423-9-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.8792.033)
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_|SJ2PR12MB9008:EE_
x-ms-office365-filtering-correlation-id: dc33fa90-48b5-4f5c-aedc-08dda4d4b09a
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?MGI4RU04ZG1CQTIraHc5N25OYTdYY1NrWW03eGhYUzlEZStCMk9CWFhUcTJt?=
 =?utf-8?B?YlRJeFRBYXZLazE0NkxMNlR5MnBXNEt5UlkzKzdoSWxPWUsxU2dVSlB5SVlM?=
 =?utf-8?B?MWhYTzdqM21EeUw4ZVN4N1lkSlMxU1BBbGlLakVCUFZLN2J1UFA5cHZ6VVYr?=
 =?utf-8?B?WmdCNGxCaWZsb2VpNUNPMHpXL0RTVlRXY3dmNlpzVVo2aUZ3K21valhKVE9O?=
 =?utf-8?B?NmJjVktLSzN6TTEwNzZqbStNdFlRanBFQ1ZiWHduUkRnY0JvMDdWaDRiL1da?=
 =?utf-8?B?bjVONGRWLzdtZEhIdmQwTmY2SThhOW85K2doTExSNmpEL2VFc1piR21wUmtV?=
 =?utf-8?B?bTVqYkxpVVc5Nnh5UklTZG5zb1RzeW5GUll3eGtMOTNnMEhtVk1jekN6UHhi?=
 =?utf-8?B?TWpzOWJPRVFzM1R0UDR4N2laVzRUWlV6MGthOEpHTEJxLysvN3BLcGJhaCt6?=
 =?utf-8?B?VkJoM0x2QzhPbUdqWVY4QU5TVDlSVmgrZkZ6MlM3ZDQ4SnZaQm9WRUhkdUxn?=
 =?utf-8?B?M0hoRVJIQ1hHQ09tNDJEdytxMU0wMjlUOXF3b1FvZXpLeXNnRjZWKzM4WUtS?=
 =?utf-8?B?YlhTakRRTTV3SjVQN0tYWmRpbHd5R3hneG9JRHlUdUI0M21SUEJDUkpKYk12?=
 =?utf-8?B?SXBla1NDclh1Z3FzY3BpSHgrZVEzaW9wdys2cGFoUEpOUC8yYlpJcU83c21v?=
 =?utf-8?B?SG1hUUZCVmo1ZXkvTXNNVkpxNVpnbFJXZG5XZEJHdTJROXFueVdoRE00LzNh?=
 =?utf-8?B?VnFLTTdHSmNib0h6RExyYUJHSm16T0lVMlFjZnlVZU9hdTJTcGQrSHJkcUJr?=
 =?utf-8?B?VnBJTjVIdTZSMnp6Tkpqc0gvWE5OUDEzWGFXSzBpV3ZTdTI1MGNvNUN5WjBI?=
 =?utf-8?B?MUN4a3hrbmlhelU0Y2NaRkk4MDRRNzYrT01vcmNnY1ZreERGejJrWkIvQnJw?=
 =?utf-8?B?aTlQL25RbHdCNXBZL00ralFKN0FSUm5pNFhMcXBUalJYRVV5NFJLNWZlNVgy?=
 =?utf-8?B?NmxCcHV2N3VJemYwb3gxZUFtL1JleDhZbEpBb0VLVlFPNDhUUU81N3pYampV?=
 =?utf-8?B?WERUUURkeUUxVElvNGdpS0VLbHlKaENhYUI5STRxTk84dmNYSk9NWmYxTDV6?=
 =?utf-8?B?YkQ0cXdJNHM2OWhDU0JEU043dHBiNXF2bmlhLzRKUktnUEErYzllRWx6ZldL?=
 =?utf-8?B?amFPMUliNmRHMURKOGgwMHB4MlpUZFZWZlkwN2J6OElHMURkTVZXRDZNbjdR?=
 =?utf-8?B?NjBZbDArdklpdG51MDJYQjQ4R1ZTSjhNYTFuQ2p0QXZCMzM4TDZGS2pPM2JU?=
 =?utf-8?B?RWIrQjF0dDMyNU9pUTRYV0YveFhCWURaNmt2UFpuaHk1dVEycUVmcnMyVzQy?=
 =?utf-8?B?Wk8yTkNNbW45K2NTelhzMmZINUNQdERlczg3T1dVZS9xeG1XTUMvNEpDRHhp?=
 =?utf-8?B?N3dsZXZiRnhCMW9RbXRaZVY1cnFuRFErSkk2dnR0QWtWQkFqcTA1WTFIQTR5?=
 =?utf-8?B?V2VrOWtGQ2tUNjJNaHhid0ZjWkdyUWFxdXNpYTg5eEtWN1Y3VVFseWVIdFpz?=
 =?utf-8?B?dVQycVZwWTFMQVFQbmFrRUZybW5Zc1o1NHlkVzY0OWw1MlVKMjNsM25jYllw?=
 =?utf-8?B?K0s3SVpqb3FmVTFLRlFENXh0SXlCdGZVbHZHQ1NROHM0dlhRS0hBUkNZSCtL?=
 =?utf-8?B?d01wSDUxVUJPaFRCQnlMUUdaL2F0S05TSzNIbDRsUzY1V0ZhUFBKL205bExi?=
 =?utf-8?B?MjI4QlN4ZmxuUU15aU9YRVJtQ3I1UUVUazZOWDY4L2huazlETUt2RVF2Uytu?=
 =?utf-8?B?TDVlYU4welBMdjd0dGIwOWNxUXFVa3FIZkFwTFBsbkZFdkppNHhSVFFwdko3?=
 =?utf-8?B?L3lab3RHVE82SnJuM0w5Z3ArUlB1TnZ4YUYzcEdQajVwbVYzREN0ZjBiZFpv?=
 =?utf-8?B?K08yL1Y4cnZMV1dVMWw4a0phcHNQRVJUMlMzZlJYSi8wOC9OZlNscnRUbzJH?=
 =?utf-8?B?ZjBoOUx0ZXZRPT0=?=
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?U3pJd1pERWl5S1hjL3VyakVxcWUrYUNPZVEvSHpOeTN6T05aWWVMOFo5cTh4?=
 =?utf-8?B?cGx4RTJrV2NGK3pPWnFTYlF2bjJ5WGlTcmZQYUhVdWtnaG9pWVBQc29MWmVO?=
 =?utf-8?B?TnZaam1oT2VsZnpscUllTzNTd1RlV3k0czNRL0s2YTNpTkxSS0E4WUVQelJT?=
 =?utf-8?B?Ump1eWttd2pLYXg3UVU5N3dzWDNHTSs3TW1rREpzUW9PR2JES2VKQlJLR0dR?=
 =?utf-8?B?QVY2UUIyeFYrM2doZmM5ME5QYlNDWlAyZXpFWFo2R0tSRXo0TjJZck4xVnRq?=
 =?utf-8?B?amJ1NFJqZHFNRlJNRE1DQURPOXdHRngwS1F2N2NJM0xBVTh6SHNXVTFxWjBm?=
 =?utf-8?B?cWVRVVdCTmlRZ2xXZDBJdXNFbCtzZXZ5T2luYzdFRTVGZ01CS3lNT0NOcnZv?=
 =?utf-8?B?aGR0ZzArWWZjSlE0MEs2QVB2Y0ROSVNRMEFHeWJQSHR2eW05aEIwU3ZHK0ds?=
 =?utf-8?B?NjlmVGJDYUp4MW1zZ1pIUHdsUUZQd1lNcUNLczRtRndJYVZqaEkreFYvMUZz?=
 =?utf-8?B?RStGdHI2cHN3Mlp5VWRzYVRwRzk1RnpPb04xajQ1d3dXbnpQUUFYTEFqaFpN?=
 =?utf-8?B?ajNYaE0vOGcxZVRqTU1pd3hnbk5PdzlXTXFoMlpsOGQ5UlN4K3pCS0thWGJn?=
 =?utf-8?B?TWcwdTY5ZXdJVUhiVDY2WWhoTC9ZYWcvd3FmSnU3UzdpbStoeGtxcm5raXZz?=
 =?utf-8?B?RkRUbmN5Wm1Sdm9lM1F6b0w3SFNWamxTZ0VlMkxjd1p3ZkVKSkJMeUxZaHBG?=
 =?utf-8?B?V3kvS0NFZGwyOE1leWx6RFM2WE04V2V5Y1ZPMVM1U2IrRzNpNjZXTnFzMmlz?=
 =?utf-8?B?TFFRWFVsbGVvTUsya1d0eEFQVGtlblBWSDBXWG4vRkNEa244TElUZjNQU2lB?=
 =?utf-8?B?Q1Z5cCt4U1E2bTExek5xSzJnSS95V1JZRlBiL0RCaVlaa0lkSXNHM1BGMzVU?=
 =?utf-8?B?eDl2TTNQZHoxbXJLQjB0NkkyMFdvamtxaVk3em83NzE4YnNWcDh3NWRXWW1j?=
 =?utf-8?B?bHFJa01GL212YnVPeEJwd2gxSVB3MTJhcitYSGxJdXR2T0dGUnRLNWFObHcy?=
 =?utf-8?B?amM3K3RVVWxVMTAySGRKVFR3TWdWS3hPK2F5UDBoYkNoQ3oyV1dYWnNydzRP?=
 =?utf-8?B?VnhYb0pCdldyVUU1UFBFb3Bua2xGWjFDVjFRVTg0eDhiQTFnbWdjWVlhSERZ?=
 =?utf-8?B?MGR6cTJnWGJyaS9nOHhNcE9WTVh1YWczOWU0UmhGMnNpc0g0ZGFKRHIwb3Jh?=
 =?utf-8?B?SkVHb3M1NlF6ZGQ0L3FkZFFhM2ptWitXdHNQb3Q0K2c1bU5UeDFEckE1bUFJ?=
 =?utf-8?B?SC9HOWgwblg0Z3BzaXVPRmFNdVF5aTdBZE9qSWtXeW5qTnlpcUlGY2owaDJF?=
 =?utf-8?B?algva2dMRTBYaS91Q2h1SWUyWVB1SFJkdnZuQ21qMzBJWFZPeHdraHIzQnFB?=
 =?utf-8?B?UG8vTFZRTzNJT21PUm95Sm10ZjVUdEV6cmU0cG8rWno4T0t1OTZpWTFidW5B?=
 =?utf-8?B?eWEwdW53ZHlTTDVZTFdrdGtnVENTQTAvb2dKQnNjdU5XMGY1NldSaG9Vc0sy?=
 =?utf-8?B?U1drQ0xqY0RlM1Z4R0JDLzFOZnVzM1Y1Y2c1d0Y3K1V1Sm9DSWg0TkVqUTlt?=
 =?utf-8?B?akZUUUdFMHF6UjRwcVZaQmFkSU5TVnFva2tPRW9tUWF2OGMyV29FT0FnNFox?=
 =?utf-8?B?SUtzc25TanBPZTYveFplMzY3M093SlRSQVA5VnNkeGFEMTBYajl4SUQwSFNJ?=
 =?utf-8?B?aGZ4ZE0wa21RekM2dG9EM3BEalk2dDBYbTc2N3Rlc2FMb3VQZ3Q5bDFFV2kw?=
 =?utf-8?B?RE9tLzRMRThSWGxvN3FoUjIzT3pXOGZnRUdFcW84WFRwcFVhZFJGcUdlNjBH?=
 =?utf-8?B?V0d4dWd3eTh0QWlPQXV3L1dPb0doQ05ERUZXZHk1bC9XMHo2UE5yN0JzQ2h5?=
 =?utf-8?B?dkFWbWVDeVE4bWxNS25wMjVtU0l3dm9pRHptZVViYVV0Zkx1NjNScUNBWi9K?=
 =?utf-8?B?TTNWai80WjFzTTVrK1Z4YVpZdWRoVEFsejNVZksrYjlDR3FrZS93WkxpSjc0?=
 =?utf-8?B?citaN2ZCbnRjTnhadmxXdmx1VU1VSS9JMit4QUFNMVVreTZoK2RvbWFxbVYv?=
 =?utf-8?Q?krxc=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: dc33fa90-48b5-4f5c-aedc-08dda4d4b09a
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2025 08:32:35.9327
 (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: CcW7pU59fHb85z3DqAuu32kDfJhtxgMG0eVZWaC1t72mL9rsK/qNcZj5k9WKuKC/tYkIE53+pOtLG1rpi7O6WQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB9008

T24gMjAyNS82LzUgMjM6MTQsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+IE9uIE1vbiwgTWF5
IDI2LCAyMDI1IGF0IDA1OjQ1OjU3UE0gKzA4MDAsIEppcWlhbiBDaGVuIHdyb3RlOg0KPj4gV2hl
biBpbml0X3JlYmFyKCkgZmFpbHMsIGN1cnJlbnQgbG9naWMgcmV0dXJuIGZhaWwgYW5kIGZyZWUg
UmViYXItcmVsYXRlZA0KPj4gcmVzb3VyY2VzIGluIHZwY2lfZGVhc3NpZ25fZGV2aWNlKCkuIEJ1
dCB0aGUgcHJldmlvdXMgbmV3IGNoYW5nZXMgd2lsbA0KPj4gaGlkZSBSZWJhciBjYXBhYmlsaXR5
IGFuZCByZXR1cm4gc3VjY2VzcywgaXQgY2FuJ3QgcmVhY2gNCj4+IHZwY2lfZGVhc3NpZ25fZGV2
aWNlKCkgdG8gcmVtb3ZlIHJlc291cmNlcyBpZiBoaWRpbmcgc3VjY2Vzcywgc28gdGhvc2UNCj4+
IHJlc291cmNlcyBtdXN0IGJlIHJlbW92ZWQgaW4gY2xlYW51cCBmdW5jdGlvbiBvZiBSZWJhci4N
Cj4+DQo+PiBUbyBkbyB0aGF0LCBpbXBsZW1lbnQgY2xlYW51cCBmdW5jdGlvbiBmb3IgUmViYXIu
DQo+Pg0KPj4gU2lnbmVkLW9mZi1ieTogSmlxaWFuIENoZW4gPEppcWlhbi5DaGVuQGFtZC5jb20+
DQo+IA0KPiBMR1RNLCBqdXN0IG9uZSBuaXQgYWJvdXQgYSBib3VuZHMgY2hlY2suDQo+IA0KPj4g
LS0tDQo+PiBjYzogIlJvZ2VyIFBhdSBNb25uw6kiIDxyb2dlci5wYXVAY2l0cml4LmNvbT4NCj4+
IC0tLQ0KPj4gdjQtPnY1IGNoYW5nZXM6DQo+PiAqIENoYW5nZSBkZWZpbml0aW9uICJzdGF0aWMg
dm9pZCBjbGVhbnVwX3JlYmFyIiB0byAic3RhdGljIGludCBjZl9jaGVjayBjbGVhbnVwX3JlYmFy
IiBzaW5jZSBjbGVhbnVwIGhvb2sgaXMgY2hhbmdlZCB0byBiZSBpbnQuDQo+Pg0KPj4gdjMtPnY0
IGNoYW5nZXM6DQo+PiAqIENoYW5nZSBmdW5jdGlvbiBuYW1lIGZyb20gZmluaV9yZWJhcigpIHRv
IGNsZWFudXBfcmViYXIoKS4NCj4+ICogQ2hhbmdlIHRoZSBlcnJvciBudW1iZXIgdG8gYmUgRTJC
SUcgYW5kIEVOWElPIGluIGluaXRfcmViYXIoKS4NCj4+DQo+PiB2Mi0+djMgY2hhbmdlczoNCj4+
ICogVXNlIGZpbmlfcmViYXIoKSB0byByZW1vdmUgYWxsIHJlZ2lzdGVyIGluc3RlYWQgb2YgaW4g
dGhlIGZhaWx1cmUgcGF0aCBvZiBpbml0X3JlYmFyKCk7DQo+Pg0KPj4gdjEtPnYyIGNoYW5nZXM6
DQo+PiAqIENhbGxlZCB2cGNpX3JlbW92ZV9yZWdpc3RlcnMoKSB0byByZW1vdmUgYWxsIHBvc3Np
YmxlIHJlZ2lzdGVyZWQgcmVnaXN0ZXJzIGluc3RlYWQgb2YgdXNpbmcgYSBhcnJheSB0byByZWNv
cmQgYWxsIHJlZ2lzdGVyZWQgcmVnaXN0ZXIuDQo+Pg0KPj4gQmVzdCByZWdhcmRzLA0KPj4gSmlx
aWFuIENoZW4uDQo+PiAtLS0NCj4+ICB4ZW4vZHJpdmVycy92cGNpL3JlYmFyLmMgfCAzNSArKysr
KysrKysrKysrKysrKysrKysrKystLS0tLS0tLS0tLQ0KPj4gIDEgZmlsZSBjaGFuZ2VkLCAyNCBp
bnNlcnRpb25zKCspLCAxMSBkZWxldGlvbnMoLSkNCj4+DQo+PiBkaWZmIC0tZ2l0IGEveGVuL2Ry
aXZlcnMvdnBjaS9yZWJhci5jIGIveGVuL2RyaXZlcnMvdnBjaS9yZWJhci5jDQo+PiBpbmRleCA5
Y2FmZDgwY2EyYzkuLjRiMTg5MmZhYjNkNiAxMDA2NDQNCj4+IC0tLSBhL3hlbi9kcml2ZXJzL3Zw
Y2kvcmViYXIuYw0KPj4gKysrIGIveGVuL2RyaXZlcnMvdnBjaS9yZWJhci5jDQo+PiBAQCAtNDks
NiArNDksMjYgQEAgc3RhdGljIHZvaWQgY2ZfY2hlY2sgcmViYXJfY3RybF93cml0ZShjb25zdCBz
dHJ1Y3QgcGNpX2RldiAqcGRldiwNCj4+ICAgICAgYmFyLT5ndWVzdF9hZGRyID0gYmFyLT5hZGRy
Ow0KPj4gIH0NCj4+ICANCj4+ICtzdGF0aWMgaW50IGNmX2NoZWNrIGNsZWFudXBfcmViYXIoc3Ry
dWN0IHBjaV9kZXYgKnBkZXYpDQo+PiArew0KPj4gKyAgICB1aW50MzJfdCBjdHJsOw0KPj4gKyAg
ICB1bnNpZ25lZCBpbnQgbmJhcnM7DQo+PiArICAgIHVuc2lnbmVkIGludCByZWJhcl9vZmZzZXQg
PSBwY2lfZmluZF9leHRfY2FwYWJpbGl0eShwZGV2LT5zYmRmLA0KPj4gKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUENJX0VYVF9DQVBfSURf
UkVCQVIpOw0KPj4gKw0KPj4gKyAgICBpZiAoICFyZWJhcl9vZmZzZXQgfHwgIWlzX2hhcmR3YXJl
X2RvbWFpbihwZGV2LT5kb21haW4pICkNCj4gDQo+IEkgdGhpbmsgeW91IGNvdWxkIGNoZWNrIHJl
YmFyX29mZnNldCA8IFBDSV9DRkdfU1BBQ0VfU0laRSB0byBiZSBtb3JlDQo+IGFjY3VyYXRlPw0K
T0suDQpEbyBJIG5lZWQgdG8gY2hhbmdlIGluIGluaXRfcmViYXIoKT8NCg0KPiANCj4gVGhhbmtz
LCBSb2dlci4NCg0KLS0gDQpCZXN0IHJlZ2FyZHMsDQpKaXFpYW4gQ2hlbi4NCg==


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 08:34:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 08:34:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008150.1387370 (Exim 4.92)
	(envelope-from )
	id 1uNSWb-0001lu-IZ; Fri, 06 Jun 2025 08:34:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008150.1387370; Fri, 06 Jun 2025 08:34: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 1uNSWb-0001lm-EH; Fri, 06 Jun 2025 08:34:05 +0000
Received: by outflank-mailman (input) for mailman id 1008150;
 Fri, 06 Jun 2025 08:34: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 1uNSWa-0001ld-0i
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 08:34:04 +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 ff90ff0e-42b0-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 10:34:02 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3a36748920cso1781820f8f.2
 for ; Fri, 06 Jun 2025 01:34:01 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a5323ab1a2sm1188690f8f.28.2025.06.06.01.34.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 06 Jun 2025 01:34:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ff90ff0e-42b0-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749198841; x=1749803641; 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=T/mxGPzUIk+ckZet2Chr7DDg9OAclwNjuncsWCHNZ08=;
        b=tyfqTlkGbXrbmR4JiGDYW9FRuTrKzgo7ll1hN1XUd5LmTsVBzE+y8mP6YA+jO1DCks
         rc+MlEAlxj8CVZCxMPkOS4EUThdXHidA9bd7XBAx3Fg1sBglY9n+TFZcKYOnkeCkaiTw
         z40Luu2+0PZ3L2sIxEK0o8WojEDfHUTq5GTgc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749198841; x=1749803641;
        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=T/mxGPzUIk+ckZet2Chr7DDg9OAclwNjuncsWCHNZ08=;
        b=Zb4Qn5RJG4gfZ50GwyE54vInTNeDRKw08aIZCsSpCud8Vpy9eTZdLkiKzOg+FHAXEX
         ZmKVr2uCUK36xldfvw+3jj/Fr/W9nxbGSIswgNV9YJbxoN+viQtnbrn2UTXtnwVH6iei
         LzvZp6DAABlnOGHgI5Tp3kzi4W1SmKWb5ICV+DYHrWi0FIh17CYDo7QcoQRVQXjWJuIV
         DrlEVd8+lHsiMYM6bfGw8aqcvvSlLK1HueDCE17hrxZEidEkqxDycZvroeOgDW0o2nWS
         9ZkPPwuAWe9CBP8t6YlX29j2gDuYly1q7eafe1bTVi5081B7NXq/1lvPXLTLCP6wD4tx
         lVCg==
X-Gm-Message-State: AOJu0Yw6Ki5un5IaDnx5wtAT6GIjZ6mru8Vi7iijic6JwZyMCvCQERzD
	DzxNyVeekTd1/xfP6EmCEMi+X7KOVjwaqWGU/dPFNRMpx5NBghVKU8UWQj5h5+FvG9I=
X-Gm-Gg: ASbGnct9P06Yc2TaxX+4K+GgaQMPYbynpZlZ0GD6rvvsnnNIIabU6AWNHLvSN60lFpl
	/8MtZoe1k3Ogf1dv41O3voVnX8tuEgQeZttnbFRhVk+Q9aVrPfLn2ziEIEg8GiuL5SodEK/FROQ
	/9LrHvyfagvTCn88O4eMqHI3Ckhsp11z2cY6jPfg8+ojyT6gTqDAykCUfXGQLmXbonOtH3jFq/M
	mYP4AQL33ltS5is2UkWV+OV0kInt5uPeAIHY5/Ee8J3HSxbtrCR1jCyaFU0pQoPyclcPuUYGp/s
	z+WrYpJCIoonTL7duCR6fu2ih0SoZ6BxDz5Kc+kKWx6lxSQBalJFMjP2Oq22WbwXVnMhBymstSH
	JJBoLIEb0p0217CcKvn4ajvaS1m88ZQ==
X-Google-Smtp-Source: AGHT+IEBdPNi/syLaKKYtpbhxofPgsueHrL8usQGc/yYQ53Qw4lBFk0cK5NOLo95e3oZcoptw+wnHA==
X-Received: by 2002:a05:6000:18ac:b0:3a5:298a:3207 with SMTP id ffacd0b85a97d-3a531cb07b8mr2134316f8f.48.1749198841270;
        Fri, 06 Jun 2025 01:34:01 -0700 (PDT)
Date: Fri, 6 Jun 2025 10:34:00 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Alejandro Vallejo 
Cc: xen-devel@lists.xenproject.org,
	Bernhard Kaindl ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH 07/11] xen/page_alloc: Set node affinity when claiming
 pages from an exact node
Message-ID: 
References: <20250314172502.53498-1-alejandro.vallejo@cloud.com>
 <20250314172502.53498-8-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250314172502.53498-8-alejandro.vallejo@cloud.com>

On Fri, Mar 14, 2025 at 05:24:58PM +0000, Alejandro Vallejo wrote:
> Set the domain's node affinity to the claimed node if the claim
> specified an exact node. Do it immediately before making any changes in
> case setting the affinity fails (even though it shouldn't).
> 
> This allows preferentially allocating from the closest NUMA node when
> "exact" is not specified (e.g: p2m tables, etc).
> 
> Signed-off-by: Alejandro Vallejo 
> ---
> Toolstacks can just do it themselves, but it's more error prone. If it
> claimed pages from an exact node (and remember we can only hold a single
> claim at a time) it makes no sense for the domain to be intentionally
> allocating from NUMA nodes other than its home node.
> ---
>  xen/common/page_alloc.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
> index cfaa64d3b858..e69a5fcc8d31 100644
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -586,10 +586,16 @@ int domain_set_outstanding_pages(struct domain *d, nodeid_t node,
>  
>      if ( node != NUMA_NO_NODE )
>      {
> -        avail_pages = pernode_avail_pages[node] - pernode_oc[node];
> +        nodemask_t affinity = NODE_MASK_NONE;
>  
> +        avail_pages = pernode_avail_pages[node] - pernode_oc[node];
>          if ( pages > avail_pages )
>              goto out;
> +
> +        node_set(node, affinity);
> +        ret = domain_set_node_affinity(d, &affinity);

You can use nodemask_of_node(node) here?

> +        if ( ret )
> +            goto out;

This seems a bit too much, specially failing the claim if the affinity
cannot be fulfilled.

If would maybe print a message if the claim is made against a
non-affine node, but that would be it.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 08:36:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 08:36:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008160.1387379 (Exim 4.92)
	(envelope-from )
	id 1uNSZC-0002P4-10; Fri, 06 Jun 2025 08:36:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008160.1387379; Fri, 06 Jun 2025 08:36:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNSZB-0002Ox-Uf; Fri, 06 Jun 2025 08:36:45 +0000
Received: by outflank-mailman (input) for mailman id 1008160;
 Fri, 06 Jun 2025 08:36: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 1uNSZA-0002Or-Pp
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 08:36:44 +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 6009e1c3-42b1-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 10:36:43 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a525eee2e3so1309511f8f.2
 for ; Fri, 06 Jun 2025 01:36:43 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a532435b16sm1202100f8f.46.2025.06.06.01.36.42
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 06 Jun 2025 01:36:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6009e1c3-42b1-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749199003; x=1749803803; 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=dT8fO8t9WtIEPvhYjTWhihtqz0QAIwi8CBDgqTH75jk=;
        b=p95YxYZIncr0xFSJMJqz848F7T8jeRmICc4lFUz6laR3CtUpWPNi96XBAyUduwG9yt
         1umxvxPDBUDtQHXA0AZipzCEE01v5iS6dP8sp2OLVKXAW3sPfnU3KV/B+am8UdeVSuD8
         5qstCG7SR2nKvrTR01U1Rn/0cBjx3AyA4/H4s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749199003; x=1749803803;
        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=dT8fO8t9WtIEPvhYjTWhihtqz0QAIwi8CBDgqTH75jk=;
        b=kJR08h/JQeSHRc7M7ME744XzUp61RSF+7cIKHdo4aCuHuGPIC4oEIdawGBTCyY73a7
         rTBvUiQ7CSSekmIrNh2B6U57nFNcdLr0N9bykoKteE+vwrnG7kPZ1kaLDv+N7TSihrV7
         LZ1N65a6eDwAOvaIgbUxTQjvcfguw8833ZuQjzOyASbQOILL7YJf0gIdotmLL3G1zTae
         97KYCiV/zUYquFa/Asf1M++1Qna/pEHMaUqaziGZq0/uQBB/dZSM+u3gzeeMb22a3f2L
         v7JHWPWZqOizM8aoc59gRgBSmApKUf8GMBoQ97/Ckj+dnpdNS6JjukqKuhhfGNJ/xYeG
         Sgfw==
X-Gm-Message-State: AOJu0Yx5OAjievCwO4mO7RFO7/Iw8z6l6t2vL24Z99fxJUEN+G2yi/t3
	WmDr4OdPuDwk6zfgfsyPmvtTFF2yskD1rbiKtAu/G6XfZNC02MgUCI1PV7HUExE8h572HEZ1fwp
	LKaR8
X-Gm-Gg: ASbGncuE5pS4H9RzA96dVi4yXlxSqiWMsINYAadpSDmKzUyaptfo5puYTOWmkTinlc1
	LC1yLi4QP0JDQZOzcnLXV+zrsGSN77kYgyTMt34Y9EKucIPgcMUzPl2Y76N+7xgPNkvQh9e4iCK
	mM9XbDkhHUB9unocWAg0eJHoVE1MvBeqN1lIrOkoQ5k3ExjkLAbFz6QNYexm8dv3eyWGfCvs/jz
	XqyxbNvn1rg4t9TJ2x1iK+oG9+iVTA7Fo2kBy5EVBWnWODDFjP4u8HCVz3VPOkH/vUsd0bBu6kc
	6tp/XFu/XqaRb+FHgs19LSOzw/5clCXH+HV9Or6a3whsF+FJBk9wk0CkzSHO80KpPhDeXhGmNL5
	tD4T7bt0Gd679f7EdvY1BiqBX
X-Google-Smtp-Source: AGHT+IFinnKEf16aL0QNgiL1hnTdntYyv77jqIBgjz/WlrYHb9jKNVyH/2R+z3q83R+hfzrSQYW5hA==
X-Received: by 2002:a05:6000:2512:b0:3a3:67bb:8f46 with SMTP id ffacd0b85a97d-3a531abd9c3mr2087026f8f.57.1749199003150;
        Fri, 06 Jun 2025 01:36:43 -0700 (PDT)
Date: Fri, 6 Jun 2025 10:36:42 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Alejandro Vallejo 
Cc: xen-devel@lists.xenproject.org,
	Bernhard Kaindl ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH 05/11] xen: Create per-node outstanding claims
Message-ID: 
References: <20250314172502.53498-1-alejandro.vallejo@cloud.com>
 <20250314172502.53498-6-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250314172502.53498-6-alejandro.vallejo@cloud.com>

On Fri, Mar 14, 2025 at 05:24:56PM +0000, Alejandro Vallejo wrote:
> Extends domain_set_outstanding_claims() to allow staking claims on an
> exact node. Also creates global per-node claim counts analogous to
> `outstanding_claims`. Note that the per-node counts can't replace the
> global one if we want exact-node claims to coexist with non-exact
> claims.
> 
> Signed-off-by: Alejandro Vallejo 
> ---
>  xen/common/page_alloc.c | 32 +++++++++++++++++++++++++++++++-
>  xen/include/xen/sched.h |  3 +++
>  2 files changed, 34 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
> index 9243c4f51370..7fe574b29407 100644
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -490,6 +490,7 @@ static unsigned long pernode_avail_pages[MAX_NUMNODES];
>  
>  static DEFINE_SPINLOCK(heap_lock);
>  static long outstanding_claims; /* total outstanding claims by all domains */
> +static unsigned long pernode_oc[MAX_NUMNODES]; /* per-node outstanding claims */
>  
>  unsigned long domain_adjust_tot_pages(struct domain *d, nodeid_t node,
>                                        long pages)
> @@ -501,20 +502,31 @@ unsigned long domain_adjust_tot_pages(struct domain *d, nodeid_t node,
>       * can test d->outstanding_pages race-free because it can only change
>       * if d->page_alloc_lock and heap_lock are both held, see also
>       * domain_set_outstanding_pages below
> +     *
> +     * If `d` has an exact-node claim, we must exit early if this is an
> +     * adjustment attributed to another node.
>       */
> -    if ( !d->outstanding_pages || pages <= 0 )
> +    if ( !d->outstanding_pages || pages <= 0 ||
> +         (d->claim_node != NUMA_NO_NODE && d->claim_node != node) )
>          goto out;
>  
> +
>      spin_lock(&heap_lock);
>      BUG_ON(outstanding_claims < d->outstanding_pages);
>      if ( d->outstanding_pages < pages )
>      {
>          /* `pages` exceeds the domain's outstanding count. Zero it out. */
> +        if ( d->claim_node != NUMA_NO_NODE )
> +            pernode_oc[d->claim_node] -= d->outstanding_pages;
> +
>          outstanding_claims -= d->outstanding_pages;
>          d->outstanding_pages = 0;
>      }
>      else
>      {
> +        if ( d->claim_node != NUMA_NO_NODE )
> +            pernode_oc[d->claim_node] -= pages;
> +
>          outstanding_claims -= pages;
>          d->outstanding_pages -= pages;
>      }
> @@ -542,6 +554,10 @@ int domain_set_outstanding_pages(struct domain *d, nodeid_t node,
>      if ( pages == 0 )
>      {
>          outstanding_claims -= d->outstanding_pages;
> +
> +        if ( d->claim_node != NUMA_NO_NODE )
> +            pernode_oc[d->claim_node] -= d->outstanding_pages;
> +
>          d->outstanding_pages = 0;
>          ret = 0;
>          goto out;
> @@ -564,12 +580,26 @@ int domain_set_outstanding_pages(struct domain *d, nodeid_t node,
>      /* how much memory is available? */
>      avail_pages = total_avail_pages - outstanding_claims;
>  
> +    /* This check can't be skipped for the NUMA case, or we may overclaim */
>      if ( pages > avail_pages )
>          goto out;
>  
> +    if ( node != NUMA_NO_NODE )
> +    {
> +        avail_pages = pernode_avail_pages[node] - pernode_oc[node];

Forgot to mention in my previous reply, should there be some sanity
check that node < MAX_NUMNODES?  It's hard to tell whether it should
be an assert or an if check, as there are no callers here that pass
node != NUMA_NO_NODE.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 08:39:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 08:39:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008172.1387390 (Exim 4.92)
	(envelope-from )
	id 1uNSbO-0002vl-Ch; Fri, 06 Jun 2025 08:39:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008172.1387390; Fri, 06 Jun 2025 08:39: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 1uNSbO-0002ve-9b; Fri, 06 Jun 2025 08:39:02 +0000
Received: by outflank-mailman (input) for mailman id 1008172;
 Fri, 06 Jun 2025 08:39: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 1uNSbM-0002vY-TG
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 08:39:00 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20616.outbound.protection.outlook.com
 [2a01:111:f403:2413::616])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b06c833e-42b1-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 10:38:58 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by CH3PR12MB9281.namprd12.prod.outlook.com (2603:10b6:610:1c8::5)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Fri, 6 Jun
 2025 08:38:54 +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.8792.034; Fri, 6 Jun 2025
 08:38:49 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b06c833e-42b1-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Oao2gTWIxev4eZwzhbnp8fKbDx/RVRHP0mpKgbiu4qHPt7WUMqnKXwh5+6107BTH2t1p9lvYdg1Yj8tnu3Zbu7cENaHifwyQjGnYfxIjJd3DsmE1A+05lPpbGXEHys/BlR/qw6nLV+iRBQuMqSVHHu5rNY/tlQN0d9zkxb3yG18DdxrZv+LlRp9DbIwwr6QdTSz9BaGdoO7OTPZCs4JDTmcYrUaFmsvvofsPfZq+LatIGapCdii01cxsTogVWlnnMD4/rhKBFbV/9jWO+7Duragf+QE5epPrrI38/Gwudegzzj3DgLs6WYKDJP9Bv/B19qU7FFCtrjhNI2Yy5IZXOQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=mt32hQ7p33+cAqjPXWJDotYMJWDtFrIXhzS9EoW4sB8=;
 b=mtWNr5dxenlcKfIl4EeL7RSOkgdyuJr3eIIKiz5VsyTxB8NXz+qmbHjbcxduCyPL0xYSIrtTsxJMxdAYZ/JKj5ZHgq6bFB+5kTR/4zOUFyQptmWif5y3KPa6EN5uCWMSdkkA/Rwa2xj/MJA1T1fnhPw/FvC77GloaTrcJwPjRt/Jh93zoN+ReWAk7lEYxnmLyoRnZ4dpsCu3oQLThiJh903K1fcQHWjvdoNnHG+HNZ8t436fQafqIoLshSNncEG6AtRds6ijblUBen+NqzyzRzWo1e8ILxOrf5AUGtX+LPqFR3ZibrR67saD1YPcXLWzaCKIR9AQsWycXDP7E54uzw==
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=mt32hQ7p33+cAqjPXWJDotYMJWDtFrIXhzS9EoW4sB8=;
 b=2D51moHV7X5PxcDPOAEEmHU/V9wJCi74AOfk7NVu3B0ViaIN0r3hjScE5d0PKavNDxIDvbsba5jvfjbtEdXxTqc6eql2yr0ZhB5VeJzN1FA2ASGuyB4eThI2yxqY5Vj5DSunm0UsHdcW5avee4iKp1ZOlgRtmyMuwRwr8tUi/mQ=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= 
CC: "xen-devel@lists.xenproject.org" , "Huang,
 Ray" , "Chen, Jiqian" 
Subject: Re: [PATCH v5 09/10] vpci/msi: Free MSI resources when init_msi()
 fails
Thread-Topic: [PATCH v5 09/10] vpci/msi: Free MSI resources when init_msi()
 fails
Thread-Index: AQHbziMSzFnidHY0zEiSVFmg3K6sv7P0vj8AgAGoAoA=
Date: Fri, 6 Jun 2025 08:38:49 +0000
Message-ID:
 
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
 <20250526094559.140423-10-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.8792.033)
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_|CH3PR12MB9281:EE_
x-ms-office365-filtering-correlation-id: de2f9b61-f6c2-4a1b-cd49-08dda4d58f03
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?ZlhVVmVWL2lVZW5yWmp4MWF2Umo2d29hWXNjNGNjTnVYUzk1K0pabHJKYldN?=
 =?utf-8?B?dTVJSld6Wko2UUJrMS9YNG1xYzRCSDBRRURmU3NzbWZOTlIwRC9pcFZmREtz?=
 =?utf-8?B?NkhtaUsrMzVHbVpodU8yT0pVa3RjMTd1aGc4V0ZBVzUxQlVKOTlWRmtPNWtr?=
 =?utf-8?B?NkVWZS9MSm54VG5sSVpjUDJiazE0ZHhBZS9lbklrdENIMHlObUJvVFdkNkh5?=
 =?utf-8?B?dUhqNERSZ1FUWjZZK044WUkwQWtIVmZDTzNoUVRkblJIamp1ZmsreWZXLzgr?=
 =?utf-8?B?WnlETHZ4MittdmsrSFJ3SW5vb2dEdFU0bnZ5bXkrMW90KzQxanRtUzgwOEhO?=
 =?utf-8?B?Rm9NRUFBVXREczJBcExYazd6ZWdZcjNUUFVKSWZrdzZUNXNJWnB4R2VBbFNj?=
 =?utf-8?B?V3krclFGVlgwSEJUeThDcTc4N2c5SEhYakJBNmhkOUd6T0llMmp2aUQ4R0J3?=
 =?utf-8?B?UzhzSkJCNzZzVXlKWlJPZm10UTAxTFNIVWpYNXFIOElZdCtTWFlHTmxqMU9w?=
 =?utf-8?B?akEzQmpVT3BhQmwxeWhJZUZJeWdPaDB3T3RGNVphdUZmMjBzTXJkYlZOb1Vt?=
 =?utf-8?B?TFBrMVRuSXJIZlNDU2pVRzU4K3hsUTVoa25xKzEzbExITWNqc1Axa0NEREVG?=
 =?utf-8?B?Q1hCMDZrY21FUE5xalkrZDJOcWlaRTRDMUkzOWZ2T0VQYzR1ODlLcHhhV0Jq?=
 =?utf-8?B?YzBCN2V1NCttZUdaMXMyUE9kRVJkSUNwS1V0K1orQURrRGYwSTNCSXl5UE5J?=
 =?utf-8?B?M0VTQS82YmtxeitEWXZmWTBIdklHdXJNa041dlI0UVFEK2JpYms2SlBHQ0ww?=
 =?utf-8?B?ZFNRN2R0eGpPQkJQWWVIQUkydDNuR0Fmd3BZclNqN2d0c0JadlBwNWQvcHdr?=
 =?utf-8?B?WHROOGgrRTBYWVZ3NWprY1lKM1drZUdMZFBNWG5aQWVRS0lIQVd3WjdCWG11?=
 =?utf-8?B?Q2FOWDdoR3h0c0VEWHRIdzJSTVZyUE9FNjY0aUFhY2FoektwTFVWTS9iR1pm?=
 =?utf-8?B?Z05lc3M4a2g1Z3JuUUFoTkFNNTVHSnF4UWhQRmxSNGVsSVcyeEJNdjMraEph?=
 =?utf-8?B?RTd2bndIakwvUW9pdi9hY2VsWnBHTjNRMHV4eDZ1N0JxdklGWGY0NDl2Uzlk?=
 =?utf-8?B?QkM5Zy9uQlpJTms0aFhuRm41YXNmVWNUelZ4TUlTZTZhL2Vxd0QxeXdTMFMw?=
 =?utf-8?B?WFJ1c1V6dDU2ZkpweFdMNUN0aTZDNFNsRFQxUW9kRlR3VW9xNHJRaXpGMmhD?=
 =?utf-8?B?UXRuYmdvcmhDbnlod0U2Q3VxY3BDTHpnOHh6MmRWZHFRUkxBc2FvOEpWZ3FD?=
 =?utf-8?B?cHhYU1B5Q1B0WWF5ODFwbFN0Z000TUNFN0ZxOFlRNTZiNGFNVWpTbTl6aG5W?=
 =?utf-8?B?MndnRHpNbVRHVTJRZDM0TXJPbHM4VkZzckJYSEJ3bk9NMmI5eklVY2h6VTha?=
 =?utf-8?B?dXNoMHk1em85YzhlbUd5RHR0enlZODNtSEo5WmllUml2TFZKTGZYZ2tCZVVG?=
 =?utf-8?B?YVF4OEJqTjVucUUxcHdIeE9MVnBOd28rV3grNHhEVjZBaHBleEpvdEg2VUtW?=
 =?utf-8?B?a0svQUEwVFR6YUtTYUY0dWk0OXllTGttdmdYRE9oYVh1VmtKNWp6MkZuQkhz?=
 =?utf-8?B?U1lOc2o3Ylh4VmwrME9jY0FXbnpXWVFNcGdSek0rQXV5djB4TG9hT3Vmb25t?=
 =?utf-8?B?d0lVeWdrUGI4anlWcm5IMm5XVDZRZzFRYzVidEVDOGxpcGEzN0VkQVFNa2Z5?=
 =?utf-8?B?Z2xWd2RmU1N6UEhwNzVIeS9QVHdEZ3VYTFZ5YkFZbDBtMk5NbVN1M0MxbVRG?=
 =?utf-8?B?eHNJYm1kQjlFVUJGcmJsaUV0Y0tGS3g3NUY5ZDgrSXpTNVd1KzFoU05DYzlz?=
 =?utf-8?B?UUlzMFd6cjJWdlE3OTBjMFBmMlByUjZTcHl4ekY4MkE5UVV5RkFGOFhFZ2Ey?=
 =?utf-8?B?VW4yOGxkcmE4Nk4rRk1reUJOU0N2OFZQbmlWamNzVE9FRGtoUGdkSHFKNjhJ?=
 =?utf-8?Q?uZ6RZMP2l73hvHe315RcCn+cyLHv04=3D?=
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?bGJpaUhMV3JXZkh2YndUd01qZnpXeHpObXE2U0p3Zmlsd2UzNzdXakhablZI?=
 =?utf-8?B?OUxYT294cFNrREJqdTUyMnJDN3NzMjRxQmt3VDFLN2JoaEpnNGRHdHhERGgz?=
 =?utf-8?B?ei9vRFJrY0J0NS9jWDgrM2Q3ZHliaDcrMEJpQUFnVElobTBGenRUZlNpQjZB?=
 =?utf-8?B?aXRLV3NpQXZjcEVUVXkvK1RIM3pqSUpwZjdtUWpYMEFUK0QyejRuemhzZjNs?=
 =?utf-8?B?aUxQRXpZbHZFT2N0WE1zdmtrYXErZFpBZUMyd0xQMnZFRXBwMHJiQ1IzTHRM?=
 =?utf-8?B?L2xyQ05YTGE4VFVoL3J4U2hPcjUyb3JycEhQQ3lNZUJ0UGRVemhqZU5CUjZV?=
 =?utf-8?B?NDR2UUZ4Z0VqMTByU3c2TmJYc0xJNkZtUG1kc1BmeEdtK2xTTFBKUnROZGdD?=
 =?utf-8?B?NnZaV1JIbTlwaVJKVmtwN1NwOHVvRFdiUWN6OWtYWlRQUGp4allWMFFlOC9Z?=
 =?utf-8?B?Q3d3VUJkVmhaQWYvUUxNZEtUWFMrUW1aMzhCSUlWRWdRTzZOU0VDRVNJUkhX?=
 =?utf-8?B?bE1xZjZKc0hZb0ZNbGtuUklZamtVMFdzVVBuQjFZSFhwQTAyMFhTdTBXTGlZ?=
 =?utf-8?B?eERPRG83N0tjVnlLS0prZ0VRQ29wS1VUbmVWczZkZ3h0dW8zN05uNlhNTzVU?=
 =?utf-8?B?UlRmTGtWcElNam5VSytsTzdQVUJWVm9YYmxKL29iSktEYlpPVzYwblhoOTdx?=
 =?utf-8?B?Tnl4UWxna2FlLzFHUUdJNXh4eEVqSllkTllMWVZMUmtReWNXYXRqR3A4Um94?=
 =?utf-8?B?RlovN0czWm1VeHFGMmRCZXo0NXplWHBYRE80R1dZMHp5VTJaOGNOdnlQaG5q?=
 =?utf-8?B?Q2FmZHlWbVVtSmIrRUdvWXJPVU5rR01jM0JZcUJUbDN6K3hZaWt4OWpDTGVl?=
 =?utf-8?B?NGxvZndQaVJRK3c5S2IxZFVneWRvNXhPcnFBcUcyYXc0NVF2VUI5UWlLRVVn?=
 =?utf-8?B?bGNhT3hQKzgvQytwdFZteEsyN2xDaTU2SmhxYkRvRkpzK1pwaHMxYnVUbXNF?=
 =?utf-8?B?REY2WFFIMzd0cnpvK2ZIUnFkODU3YkwraHdPUDN2Y3FqZWptVko3ZUJEVjBp?=
 =?utf-8?B?ZnZWcjJqUFZFOVJmZlYxakZsSC8rNEk5c2s4SlZlbnY1WHN1YUlRUXYzbDR0?=
 =?utf-8?B?WDVSVHVBUkVTSTVLNXZuQXNiQlZzUFl4RU9UY1Z6Y0F0dStVdW5EQ2ZjMVpZ?=
 =?utf-8?B?N0Rmb0w3aFJuQ3dJb25seVQwSGxlQXR3YTZ5L2dVb2dsYzNVTHlFRkhCTGJT?=
 =?utf-8?B?TnlSTzl5Tm8vWnFJZGR6ODBQTk5RMm9tSUY3dlR4Rk1pVTRwZkxrdTRubFZj?=
 =?utf-8?B?aE56TDV2REFORzJ5NjQ4WVdKTE9kb3MzZ2J0MElxbEFXZE93aUxScWZ0cC9X?=
 =?utf-8?B?Nk1lM3JFelFLYnNJVlpUb09YUkRzNzc2QVoyRzFLV0c2bW9acUR5UFdBQzUw?=
 =?utf-8?B?RUVKOGRzZWlYc1puayt6SXRXcFY0Q2VXVDdEc1BQamsrcW83MjZ0c2lOUStL?=
 =?utf-8?B?Uk9nUm4xRURHWnpCM0lKblpObERPWlYvaVpJMW9ORmhFVld3TFZjWllZaW5F?=
 =?utf-8?B?ZnFwM2xVYVNJMDN4cENVR2VZeXE4cW52ZEVBWWxlS1N6TDQ1ODgyYTVkQTh5?=
 =?utf-8?B?azNmZ0x1aU53Tk5iL1pnWEw5TU1jaUVDOWJseG5aeGUvQXpQZ0NCYnpGOGN5?=
 =?utf-8?B?NzluOG1rZy9Yd2IxR0xNcmU5WCtWZGVSN1I0eDF0ZlRoZzA2MUh4MnAvL3VE?=
 =?utf-8?B?eUNzcVFCUVpXbnlER1hjWjJWdzgvalViTmFFeklVVFJXS1pnbjNwMG10aEVq?=
 =?utf-8?B?bG5OMnMzdUdYNmQ4SSthM2tZYjVQSFpBZTdVWUJzL2pUa3UvaDJCUE9xV0Jm?=
 =?utf-8?B?VEJsbERWZUZpSTBnZ1h6VkI1aGs1RUFlcFhaeFRzVkdXUlE4aU55NFdhdlRs?=
 =?utf-8?B?cnZmbHpaZENxMnhqOTRycVB1RjJzU2ZPNlZHc2ZGQWRqZ1VyQTh3dXlZOHRw?=
 =?utf-8?B?ME1RR3hmbGV1ZFdEOXAwMFBXRDl0SW1ndHBrNjQ5ZlhLYlpscmowYmJDWWdV?=
 =?utf-8?B?S21PYVNUMlcrdTE1ZGxRRm1aU0FWbS9DMlhpRldVVHNEZHAveldTTm5GbU4v?=
 =?utf-8?Q?pBig=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <9001755FC4EE4449BAE6688AD33F6E81@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: de2f9b61-f6c2-4a1b-cd49-08dda4d58f03
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2025 08:38:49.0797
 (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: 5qZHdgp7JUivbaRXUKZpPuTO6J+XLVZ+VKNNVam7yGA+NMeuA2OG/DbtiNeK65coWJpPuqvrJ2C0ri7/KHjbug==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB9281

T24gMjAyNS82LzUgMjM6MTksIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+IE9uIE1vbiwgTWF5
IDI2LCAyMDI1IGF0IDA1OjQ1OjU4UE0gKzA4MDAsIEppcWlhbiBDaGVuIHdyb3RlOg0KPj4gV2hl
biBpbml0X21zaSgpIGZhaWxzLCBjdXJyZW50IGxvZ2ljIHJldHVybiBmYWlsIGFuZCBmcmVlIE1T
SS1yZWxhdGVkDQo+PiByZXNvdXJjZXMgaW4gdnBjaV9kZWFzc2lnbl9kZXZpY2UoKS4gQnV0IHRo
ZSBwcmV2aW91cyBuZXcgY2hhbmdlcyB3aWxsDQo+PiBoaWRlIE1TSSBjYXBhYmlsaXR5IGFuZCBy
ZXR1cm4gc3VjY2VzcywgaXQgY2FuJ3QgcmVhY2gNCj4+IHZwY2lfZGVhc3NpZ25fZGV2aWNlKCkg
dG8gcmVtb3ZlIHJlc291cmNlcyBpZiBoaWRpbmcgc3VjY2Vzcywgc28gdGhvc2UNCj4+IHJlc291
cmNlcyBtdXN0IGJlIHJlbW92ZWQgaW4gY2xlYW51cCBmdW5jdGlvbiBvZiBNU0kuDQo+Pg0KPj4g
VG8gZG8gdGhhdCwgaW1wbGVtZW50IGNsZWFudXAgZnVuY3Rpb24gZm9yIE1TSS4NCj4+DQo+PiBT
aWduZWQtb2ZmLWJ5OiBKaXFpYW4gQ2hlbiA8SmlxaWFuLkNoZW5AYW1kLmNvbT4NCj4+IC0tLQ0K
Pj4gY2M6ICJSb2dlciBQYXUgTW9ubsOpIiA8cm9nZXIucGF1QGNpdHJpeC5jb20+DQo+PiAtLS0N
Cj4+IHY0LT52NSBjaGFuZ2VzOg0KPj4gKiBDaGFuZ2UgZGVmaW5pdGlvbiAic3RhdGljIHZvaWQg
Y2xlYW51cF9tc2kiIHRvICJzdGF0aWMgaW50IGNmX2NoZWNrIGNsZWFudXBfbXNpIiBzaW5jZSBj
bGVhbnVwIGhvb2sgaXMgY2hhbmdlZCB0byBiZSBpbnQuDQo+PiAqIEFkZCBhIHJlYWQtb25seSBy
ZWdpc3RlciBmb3IgTVNJIENvbnRyb2wgUmVnaXN0ZXIgaW4gdGhlIGVuZCBvZiBjbGVhbnVwX21z
aS4NCj4+DQo+PiB2My0+djQgY2hhbmdlczoNCj4+ICogQ2hhbmdlIGZ1bmN0aW9uIG5hbWUgZnJv
bSBmaW5pX21zaSgpIHRvIGNsZWFudXBfbXNpKCkuDQo+PiAqIFJlbW92ZSB1bm5lY2Vzc2FyeSBj
b21tZW50Lg0KPj4gKiBDaGFuZ2UgdG8gdXNlIFhGUkVFIHRvIGZyZWUgdnBjaS0+bXNpLg0KPj4N
Cj4+IHYyLT52MyBjaGFuZ2VzOg0KPj4gKiBSZW1vdmUgYWxsIGZhaWwgcGF0aCwgYW5kIHVzZSBm
aW5pX21zaSgpIGhvb2sgaW5zdGVhZC4NCj4+ICogQ2hhbmdlIHRoZSBtZXRob2QgdG8gY2FsY3Vs
YXRpbmcgdGhlIHNpemUgb2YgbXNpIHJlZ2lzdGVycy4NCj4+DQo+PiB2MS0+djIgY2hhbmdlczoN
Cj4+ICogQWRkZWQgYSBuZXcgZnVuY3Rpb24gZmluaV9tc2kgdG8gZnJlZSBhbGwgTVNJIHJlc291
cmNlcyBpbnN0ZWFkIG9mIHVzaW5nIGFuIGFycmF5IHRvIHJlY29yZCByZWdpc3RlcmVkIHJlZ2lz
dGVycy4NCj4+DQo+PiBCZXN0IHJlZ2FyZHMsDQo+PiBKaXFpYW4gQ2hlbi4NCj4+IC0tLQ0KPj4g
IHhlbi9kcml2ZXJzL3ZwY2kvbXNpLmMgfCAyOSArKysrKysrKysrKysrKysrKysrKysrKysrKysr
LQ0KPj4gIDEgZmlsZSBjaGFuZ2VkLCAyOCBpbnNlcnRpb25zKCspLCAxIGRlbGV0aW9uKC0pDQo+
Pg0KPj4gZGlmZiAtLWdpdCBhL3hlbi9kcml2ZXJzL3ZwY2kvbXNpLmMgYi94ZW4vZHJpdmVycy92
cGNpL21zaS5jDQo+PiBpbmRleCAyZDQ1Yzc4NjdkZTcuLjRlMTA2YzM5ZWZhZSAxMDA2NDQNCj4+
IC0tLSBhL3hlbi9kcml2ZXJzL3ZwY2kvbXNpLmMNCj4+ICsrKyBiL3hlbi9kcml2ZXJzL3ZwY2kv
bXNpLmMNCj4+IEBAIC0xOTMsNiArMTkzLDMzIEBAIHN0YXRpYyB2b2lkIGNmX2NoZWNrIG1hc2tf
d3JpdGUoDQo+PiAgICAgIG1zaS0+bWFzayA9IHZhbDsNCj4+ICB9DQo+PiAgDQo+PiArc3RhdGlj
IGludCBjZl9jaGVjayBjbGVhbnVwX21zaShzdHJ1Y3QgcGNpX2RldiAqcGRldikNCj4+ICt7DQo+
PiArICAgIGludCByYzsNCj4+ICsgICAgdW5zaWduZWQgaW50IGVuZCwgc2l6ZTsNCj4+ICsgICAg
c3RydWN0IHZwY2kgKnZwY2kgPSBwZGV2LT52cGNpOw0KPj4gKyAgICBjb25zdCB1bnNpZ25lZCBp
bnQgbXNpX3BvcyA9IHBkZXYtPm1zaV9wb3M7DQo+PiArICAgIGNvbnN0IHVuc2lnbmVkIGludCBj
dHJsID0gbXNpX2NvbnRyb2xfcmVnKG1zaV9wb3MpOw0KPj4gKw0KPj4gKyAgICBpZiAoICFtc2lf
cG9zIHx8ICF2cGNpLT5tc2kgKQ0KPiANCj4gUG9zc2libHkgc2FtZSByZXF1ZXN0IGFzIHRoZSBw
cmV2aW91cyBwYXRjaCwgbXNpX3BvcyBzaG91bGQgYmUgYWZ0ZXINCj4gdGhlIFBDSSBzdGFuZGFy
ZCBoZWFkZXIuDQptc2lfcG9zIDw9IFBDSV9DQVBBQklMSVRZX0xJU1QgPw0KT3IgbXNpX3BvcyA8
IDB4NDAgPw0KDQo+IA0KPiBUaGFua3MsIFJvZ2VyLg0KDQotLSANCkJlc3QgcmVnYXJkcywNCkpp
cWlhbiBDaGVuLg0K


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 08:40:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 08:40:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008178.1387401 (Exim 4.92)
	(envelope-from )
	id 1uNScP-0004CU-Nl; Fri, 06 Jun 2025 08:40:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008178.1387401; Fri, 06 Jun 2025 08:40:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNScP-0004CN-I8; Fri, 06 Jun 2025 08:40:05 +0000
Received: by outflank-mailman (input) for mailman id 1008178;
 Fri, 06 Jun 2025 08:40:04 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uNScO-00040Y-SW
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 08:40:04 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uNScO-005B20-0I;
 Fri, 06 Jun 2025 08:40:04 +0000
Received: from [2a02:8012:3a1:0:14ae:50d0:36ad:cee3]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uNScO-005ZX9-0q;
 Fri, 06 Jun 2025 08:40: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" 
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=YhE94qPD8J4izqCm+ASbSBQeFXzwAy4B0QbwiIbPLwE=; b=hU0dDL2VKret2LqiaMO0gy90KG
	H8QPShijby2RhcMEDc/Lfq/bpFGzLhvUN6sou0q+3WLXC/vqXVp/4HhQl4yR/2pgIYOz4zz0m00Yg
	6uKhzW3sND3adbe3HB80Hy/oD2tklTHnsqvLZ5swXVqpubJXixvXyguLTN3aMgDsOHzs=;
Message-ID: 
Date: Fri, 6 Jun 2025 09:40:01 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4][PART 1 2/4] xen/arm: Implement PSCI SYSTEM_SUSPEND
 call for guests
Content-Language: en-GB
To: Mykola Kvach 
Cc: xen-devel@lists.xenproject.org, Mykola Kvach ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: 
 <1a8313537603bee36636b0fcd2fdc2f76a2374fb.1748337249.git.mykola_kvach@epam.com>
 
 
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Mykola,

On 06/06/2025 09:26, Mykola Kvach wrote:
> On Fri, Jun 6, 2025 at 6:52 AM Mykola Kvach  wrote:
>>
>> Hi, @Julien Grall
>>
>> On Wed, Jun 4, 2025 at 2:00 AM Julien Grall  wrote:
>>>
>>> Hi Mykola,
>>>
>>> On 27/05/2025 10:18, Mykola Kvach wrote:
>>>> From: Mykola Kvach 
>>>>
>>>> This patch adds support for the PSCI SYSTEM_SUSPEND function in the vPSCI
>>>> (virtual PSCI) interface, allowing guests to request suspend via the PSCI
>>>> v1.0 SYSTEM_SUSPEND call (both 32-bit and 64-bit variants).
>>>>
>>>> The implementation:
>>>> - Adds SYSTEM_SUSPEND function IDs to PSCI definitions
>>>> - Implements trapping and handling of SYSTEM_SUSPEND in vPSCI
>>>> - Allows only non-hardware domains to invoke SYSTEM_SUSPEND; for the
>>>>     hardware domain, PSCI_NOT_SUPPORTED is returned to avoid halting the
>>>>     system in hwdom_shutdown() called from domain_shutdown
>>>> - Ensures all secondary VCPUs of the calling domain are offline before
>>>>     allowing suspend due to PSCI spec
>>>> - Treats suspend as a "standby" operation: the domain is shut down with
>>>>     SHUTDOWN_suspend, and resumes execution at the instruction following
>>>>     the call
>>>
>>> Looking at the specification, I am still not convinced you can implement
>>> PSCI SUSPEND as a NOP. For instance, in the section "5.1.19
>>> SYSTEM_SUSPEND", the wording implies the call cannot return when it is
>>> successul.
>>>
>>> I understand that 5.20.2 ("Caller reponsabilities" for SYSTEM_SUSPEND)
>>> suggests the caller should apply all the rules from 5.4 ("Caller
>>> responsabilties" for CPU_SUSPEND), but it is also mentioned that
>>> SYSTEM_SUSPEND behave as the deepest power down state.
>>>
>>> So I don't think standby is an option. I would like an opinion from the
>>> other maintainers.
>>
>> Sure, let's discuss this with the others.
>>
>>>
>>>> +static int32_t do_psci_1_0_system_suspend(register_t epoint, register_t cid)
>>>   > +{> +    struct vcpu *v;
>>>> +    struct domain *d = current->domain;
>>>> +
>>>> +    /* Drop this check once SYSTEM_SUSPEND is supported in hardware domain */
>>>> +    if ( is_hardware_domain(d) )
>>>> +        return PSCI_NOT_SUPPORTED;
>>>> +
>>>> +    /* Ensure that all CPUs other than the calling one are offline */
>>>> +    for_each_vcpu ( d, v )
>>>> +    {
>>>> +        if ( v != current && is_vcpu_online(v) )
>>>
>>> I think this is racy because you can still turn on a vCPU afterwards
>>> from a vCPU you haven't checked.
>>>
>>
>> I'll think about how to protect against such cases.
>> Thank you for pointing that out.
> 
> Is that actually possible in this context? If suspend is successful, we pause
> all present vCPUs (including the current one), and control is not returned to
> the guest until either resume or an error occurs in this function. Since this
> runs as part of a trap, the current function can't be preempted.

AFAIU, this code is called before suspend is completed. At that point 
you don't know yet the state of the vCPUs. They may be scheduled on a 
different pCPU. At which point, they can issue PSCI_CPU_ON.

> 
> Also, from the use of _VPF_down (via is_vcpu_online) on Arm, it looks like
> guest requests are what manipulate this bit, which further limits what can
> happen concurrently.

I don't see how this help. See why above. So you will want to at least 
pause the domain before checking if all the vCPUs are offline.

 > Note: It looks like the same behavior is present for VCPUOP_down as well.

 From a brief look, I agree the same behavior is present there.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Fri Jun 06 08:43:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 08:43:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008184.1387410 (Exim 4.92)
	(envelope-from )
	id 1uNSfD-0005IJ-3P; Fri, 06 Jun 2025 08:42:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008184.1387410; Fri, 06 Jun 2025 08: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 1uNSfC-0005IC-VX; Fri, 06 Jun 2025 08:42:58 +0000
Received: by outflank-mailman (input) for mailman id 1008184;
 Fri, 06 Jun 2025 08:42: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 1uNSfB-0005I6-Kz
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 08:42:57 +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 3e13c5b1-42b2-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 10:42:56 +0200 (CEST)
Received: by mail-il1-x12e.google.com with SMTP id
 e9e14a558f8ab-3da73df6c4eso16248865ab.0
 for ; Fri, 06 Jun 2025 01:42:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3e13c5b1-42b2-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749199375; x=1749804175; 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=5Y50bpedkxKFeoMDlm0zVMdyfNFBuYl1yYyag+al4b8=;
        b=g/DZXPh3PyLERRFwZMu6MA36iUU7ER1Bv45nzMweyxub0Ru8mgxun2icIWoy7kJy6v
         1fq297CxjFhlVwnEmADgWuUv4e6yOKYFonXOENHbkns9EtCfNAwc8xq+s1L6slDEsBBg
         mBhll36ox8Ou/4sCAiAm/L1XO72tUqSr/b8S4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749199375; x=1749804175;
        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=5Y50bpedkxKFeoMDlm0zVMdyfNFBuYl1yYyag+al4b8=;
        b=lJsRjkksEaVmLxReYZehh/7kfsFUSnmavcGXMKB9pgE3/QUrjj3Q7Vn5b0QfpWjBKh
         lt7FLBkhmekzFieiLeSPHWkyspKQH43qL83Mi4W6P+5SiMJTfH+rJ8k0NA1I1XtYoR4V
         kL1nxb/YYxKoKy6YuEqoTa5eIDISwVeQqHL47DHY3m88mNVqOEdHHO+7A2reWtI4BBQT
         natb2Q2rQbVuudg47JK5rRCXWv5M7010ouEHGc+xUcyaCCAtpywCFixosmK/TPuYmxKr
         OpHY5e4G6e9hzqbcvVaALeHT8QCXrvH25fvM7iJg5puh4rg08UJOftqwQbA0xAJg/WO/
         jkTA==
X-Forwarded-Encrypted: i=1; AJvYcCXGfJWdKEJZSoKoIigKSbkKzm80A+KpRd7m/S/yoqMDy0kNb5F2cucVI/chfBNHRDnj4z03RrcflN8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywklw6qkXg2JqRytPGTm5QyX4z4aVGqU2F4Y1uo+7orO81V+NoC
	7YTfaCgot/CLvzgFhOFgb0ullvV8SIzGbN4amSI7O2WNFhSQaeQSZ0dpq+7vni8b5jrzRh8VlfW
	5DmwwldjcjRp1YUx8H4jqYA5eR6Eh5tPd9syby0Xu6ZiihRuOOxQ=
X-Gm-Gg: ASbGncsIxYuQzqFfoH19Ffrck897Iy+lTkJ1+YQBSLHSxbPhd36+7di90lv2L3QZk0d
	0TV0NR3c/hhVyJcfGp6CNj073vFr4+hPOPD+FZ4rbX7KFtH26h452X+02BUEh0T7eUPHFve+S0/
	CW5XwE+A9ZQjvDPHHafBzKDd98WEUzHm+IBuH4viLSJg==
X-Google-Smtp-Source: AGHT+IH8bp9IZxDHBL0knAOb/iNuYFt+e6X7+2aGL2ZinMHm5AjvYsRDRuX84gUaWbDCspaAUprAdEMDu2LPOpGkGvo=
X-Received: by 2002:a05:6808:6f8d:b0:407:59ac:d73f with SMTP id
 5614622812f47-409051f2c1fmr1794876b6e.21.1749199363766; Fri, 06 Jun 2025
 01:42:43 -0700 (PDT)
MIME-Version: 1.0
References: <20250527152635.2451449-1-ross.lagerwall@citrix.com>
 <20250527152635.2451449-2-ross.lagerwall@citrix.com> <202b9b4f-edd1-4bb4-a61a-a1fcf8333108@suse.com>
In-Reply-To: <202b9b4f-edd1-4bb4-a61a-a1fcf8333108@suse.com>
From: Ross Lagerwall 
Date: Fri, 6 Jun 2025 09:42:32 +0100
X-Gm-Features: AX0GCFvc76-59S6WzumYHm7FESMlUCdmE0fcmtT2eqAPn-erq9KuTgEVGLRGiNM
Message-ID: 
Subject: Re: [PATCH v3 1/5] x86/pmstat: Check size of PMSTAT_get_pxstat buffers
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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 5, 2025 at 11:10=E2=80=AFAM Jan Beulich  wro=
te:
>
> On 27.05.2025 17:26, Ross Lagerwall wrote:
> > --- a/xen/include/public/sysctl.h
> > +++ b/xen/include/public/sysctl.h
> > @@ -215,11 +215,22 @@ typedef struct pm_px_val pm_px_val_t;
> >  DEFINE_XEN_GUEST_HANDLE(pm_px_val_t);
> >
> >  struct pm_px_stat {
> > -    uint8_t total;        /* total Px states */
> > +    /*
> > +     * IN: Number of elements in pt, number of rows/columns in trans_p=
t
> > +     *     (PMSTAT_get_pxstat)
> > +     * OUT: total Px states (PMSTAT_get_max_px, PMSTAT_get_pxstat)
> > +     */
> > +    uint8_t total;
> >      uint8_t usable;       /* usable Px states */
> >      uint8_t last;         /* last Px state */
> >      uint8_t cur;          /* current Px state */
> > -    XEN_GUEST_HANDLE_64(uint64) trans_pt;   /* Px transition table */
> > +    /*
> > +     * OUT: Px transition table. This should have total * total elemen=
ts.
> > +     *      As it is a 2-D array, this will not be copied if it is sma=
ller than
> > +     *      the hypervisor's Px transition table. (PMSTAT_get_pxstat)
> > +     */
> > +    XEN_GUEST_HANDLE_64(uint64) trans_pt;
> > +    /* OUT: This should have total elements (PMSTAT_get_pxstat) */
> >      XEN_GUEST_HANDLE_64(pm_px_val_t) pt;
> >  };
>
> Commentary here is still confusing imo: Since "total" now has two meaning=
s,
> saying "This should have .." in OUT: descriptions is ambiguous. Imo for
> trans_pt you want to say something like "will not be copied if input tota=
l is
> less than output total", and for pt "the number of elements copied is the
> smaller of input and output total".
>
> If that's okay with you, I can edit things along these lines while commit=
ting,
> at which point
> Reviewed-by: Jan Beulich 
>

Sure, that's fine with me.

Thanks,
Ross


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 08:44:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 08:44:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008194.1387419 (Exim 4.92)
	(envelope-from )
	id 1uNSgK-0005qo-EE; Fri, 06 Jun 2025 08:44:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008194.1387419; Fri, 06 Jun 2025 08: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 1uNSgK-0005qh-BY; Fri, 06 Jun 2025 08:44:08 +0000
Received: by outflank-mailman (input) for mailman id 1008194;
 Fri, 06 Jun 2025 08: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 1uNSgI-0005qQ-Ke
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 08:44:06 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20629.outbound.protection.outlook.com
 [2a01:111:f403:2413::629])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 675b8dcb-42b2-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 10:44:05 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by CH3PR12MB9281.namprd12.prod.outlook.com (2603:10b6:610:1c8::5)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Fri, 6 Jun
 2025 08:44:02 +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.8792.034; Fri, 6 Jun 2025
 08:44: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: 675b8dcb-42b2-11f0-a301-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=sV1Wnv0AHnWdznHQGD1RzOI16qSApVICcjPpsvr0t/5LI0WmNXDhR4KggUeDDYWyCpLdUxniyLUrQU48RUrwEYidi6QKg+XH+E66kWnkwxLXZm2yfxUbUSVvXYi2Vc1D66x02ZIHqaB+IIghm/A5Bhqwi85O+7pgpg8MuMAswZYsQxumoSa0UGednUeOLNe4BitVuef0tE/6c3WQOt26pZBhkjiBBDieQ6zlXOsQ7pZ/rbfdApZ1uESA+nMOvL7IKxFUu2KcjtGoziuyjVX9k8k8tzHFy67JEur/f5GWgR5L8e73wFV+z6LTAQp3SRcP47nH07+z4mn0H8g+BVKNiQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Io3dMfdBKgUW1y+TKqfLJgdQwWxKRLi6oYFFFcNT3/w=;
 b=ABcKmXvt6alBurM9+8+wa/vVGadLezhjSwiOSp2D0AuZhkdVu1kY5bYNITfoSWAIuW4NKIFcqIRBwvzsg4Td4DgjxSoUBgY4ee1O7QKHE9wUfFTaDjN8gM+CaXHj5iPJ0ZGqEyrP+0YqifX5YWVHzENllZjm6hgu7pNt17FNdTYAAlcsAeGSiFr1RNWk+3jwzMGQ036DREFTdKkVn4ez2mf6s53S8qfojfogwqc4S13V96dHsBNJ6Hfmhir/BSYl7eIhJkO0W5aOHvkXU2sqAdYGhfXrxyezENXM5g++X+ogkyOTy5bMj9YmySIHsFEI0s8df0xuaYu6U8J9FeDuNQ==
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=Io3dMfdBKgUW1y+TKqfLJgdQwWxKRLi6oYFFFcNT3/w=;
 b=Kad+RJRDSlhNLK/ermAFfkmvhDekUmH3JkScLPwoWnAhQOxXUXsEc4EXBF+FOd34IYSrE40YM+7tMINmALf6pfJxTOTmldfER1CiJnI9S9M+DkEc/qdzH8gOwEC5CTYY2rKc10jNNxMWRwk2J+ZbpdN2acc+zJDuLY/hnV0sHLI=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= 
CC: "xen-devel@lists.xenproject.org" , "Huang,
 Ray" , "Chen, Jiqian" 
Subject: Re: [PATCH v5 10/10] vpci/msix: Free MSIX resources when init_msix()
 fails
Thread-Topic: [PATCH v5 10/10] vpci/msix: Free MSIX resources when init_msix()
 fails
Thread-Index: AQHbziMTqeagkRx4hES1pSa65nFeRrP0wkuAgAGlSYA=
Date: Fri, 6 Jun 2025 08:44:02 +0000
Message-ID:
 
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
 <20250526094559.140423-11-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.8792.033)
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_|CH3PR12MB9281:EE_
x-ms-office365-filtering-correlation-id: 134a3f3b-3294-406e-da7d-08dda4d64991
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?NjJaYWlpMjEzTlhMQ01Ycnd1RU9yN2Uxc0hoNG5hV1VQZGhFeGxhQWdSbURS?=
 =?utf-8?B?Ykl2YjJJUlVySnBsVjVvdmZpakl6NWRpZkxENk53cDJIakRsK2F0MVVwRGVG?=
 =?utf-8?B?MXMxYU9aK21kSWl1Tk1XOTVZdlo4T3NSc2dzTmRGd09IRGJrTDlJODVVdWxN?=
 =?utf-8?B?QzJ6OEIyYkhqUm1XQkN5YTNRQnByNWlsMmNlNFp3bkZZSHhBVkgwUGtMTVp5?=
 =?utf-8?B?YUpRNkpoRUlucmkzZEgwVjFKNDhBWEl3UUUrTzZaM0RlZnFtSU9FQXcxWStk?=
 =?utf-8?B?ZWE2cmpXeElPL1M0RWxSN2FHTG5DNzlJUEo3Tit0Q3JrQXNvNmNoY1h1R0JT?=
 =?utf-8?B?eHc3MHpBM3dSeHhHZ0dsdDdVUHNMYnhsYlAzZWZjdnp4TWJOd3gyUS91RTJ2?=
 =?utf-8?B?QlI2SWcvdUpvVDlEK0JySFVXYkNqamZ6QkI1WUQ2amdxaTQvbWpZUkNEVEdX?=
 =?utf-8?B?V0hLOXMzdnZxTURmNWQ3aFluVzMvdVplWTM4NnZGQy9HVS9SaWphNGlhZEgw?=
 =?utf-8?B?bUlDUEtyN3JtOEkyR0NST0hyVmZmRGdWY09UNnZtOU9xVTRsLzRyMDhmTnpr?=
 =?utf-8?B?RFFYQTZuaEUrbkdsbHdUOXhmdzh1RmV1ZlBEb3hiamRCVWVFcG9EdDY3R2xN?=
 =?utf-8?B?em9oM1RFaWFod0JBOUhVRzJoOWEzWnhlWEk5elFncjhIMXdIMjVnbTd1Wmho?=
 =?utf-8?B?MWR6VzBsV0JXekNIRjdNOVhSeWVmd1RDcWRVN1ZyTzdndjYrMmpJSkN0L25a?=
 =?utf-8?B?VXBsSnFhdGkwZ2h2R2F5YWhWRkZNL3NjS2dnWVdWdG9qNmpPNFNTMU1hNFIw?=
 =?utf-8?B?aDVqT2pQYXRBTjAxL1lEMGEzbzlsT3gzK0dKMXVNUmJmSGFUU3NuRWF0Rm9R?=
 =?utf-8?B?aUdEU1ExRlVnZGs2c0Fha0c1MndMSU5sai8rR29TVGVMWmsyK056UlprQ3Jt?=
 =?utf-8?B?UVJRNkY4MlErb01lMDMxMTdockFLb3lUelVUN2hkbm1JRG9iNVZUSU45Q2di?=
 =?utf-8?B?Y2NNNHN6ZVlVMGZMTVJ2cHpXVnpXZ0ZzSG9idW4zeFBUVUN0Sm9ROEMxNXAr?=
 =?utf-8?B?dEg5SElXM1I4UFd6UWxFaHpGZkg3WExkRmppNjFjek16L25FMnU4QUVRZDE2?=
 =?utf-8?B?bFBvUHhTcWVFdjdKdXBFU2tkR0VtVngybjJtMTZQKy9CQnZSY2lNbmpJdGwx?=
 =?utf-8?B?cXlsTzVMZ3hUQnlCNDhkdGxGeTQrdkdkZjVPQUVNOG80ZjR2T1QwN09MK2Qr?=
 =?utf-8?B?Q0syd3FjbnkwZ2VTaFVHUUZRU1huVVY0bWNkYTlqR3VhU0hvSHJ0WXo4K0NX?=
 =?utf-8?B?TitqeVRUblRsalBhV1pCZlB3L2VrMXlZV2dkOUc4T3V2ZEJOTjBhY0RNeU9L?=
 =?utf-8?B?REdHbklVMnVmbmEzTmdVUjhTaEVNRVlSM0xaYWdFSm9ET0hxazlDQWw1dzdU?=
 =?utf-8?B?ckJnS2U5OERiSkJHQW1IeDhlVzNKaXVRMWUrTmUyRDA2WXBiTkN5aGhnMHZX?=
 =?utf-8?B?ODJIQW4waUVUK0xrWmtwYkluV041MDQ3M0x5aTNwK3MxdVNJT0hCdWVnZmFY?=
 =?utf-8?B?RC8xM253NitrTmVFc05QSFdmemV4M0F5NjM5WnZDSDl3NW5lanNGcm50SXN5?=
 =?utf-8?B?QWM2TlhCblZyV09ROThGVmQyVzBZMVF0QzhyU1d6QzRKbndJd2xZMGJBZ0ZV?=
 =?utf-8?B?M0hGS0VVelkySEZmYzFPcmF5aWc4QkhXK0NwVEg3ajlTS1QvN2hpNVhpeEta?=
 =?utf-8?B?TkhjNmkvSWdhdmo2dE1NUlM1eDRWc254SnY2UVlUdUovU0UveHVvS3YrbkxB?=
 =?utf-8?B?UEtnRVl4UytaK2d2Y3BIN0ViOUgrRFM5Y2Rlbjh6d3NBVEE2b1E5VXVjSXY2?=
 =?utf-8?B?Qi94Z2VoTFZNa1pYeGZad09uTzBrUWlTeVdOck1YajhSWm5KZ2pSc0tHRkxk?=
 =?utf-8?B?bGV3eXMyRGtvVlg0ek12c0c2R1JPU2ZPY29ZWHErUmE0KzBSQnNscFhseVkx?=
 =?utf-8?Q?XWntnhfXHEkKF3klu4uxbVRZaVG4TY=3D?=
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?WFlPZkY3dUJQVjd4NU1rZmJqTHQ1cmlpaW05UEcrdlJZWVhkazNxMENRZ291?=
 =?utf-8?B?VEptdTRuci9XQ3pqQU5lTEJXM1JHY1U3a2h2WWdTU2RWSGlIVzBXVk5iOUtY?=
 =?utf-8?B?MUk5RnJnVkEzWFFIeEI0OFJ4MEdwM3ZXMGRRT3lLVUZkMUIwWTgrNkQ1cHdM?=
 =?utf-8?B?VGM5TklRNjN3dEh3V0NFams1T0o3S3pDL2x6V0NvQ3M4akVudHQxWXhLMklL?=
 =?utf-8?B?WGd5Q1pNV0NtMnAySGttLzEyK2prQWV4NlB2Slowelg1UytGVHhaV2tZZFRC?=
 =?utf-8?B?OXZvdXJuRWo3SDN1NDV4U2xMMGNNVlh3amlLUFFEZjZINng3dlZCZE9wcmd6?=
 =?utf-8?B?S3ZCTmIwRncwbVNGRkJxS0xLb25icFF6RXVTbjg5MnFvOUZqV0xGajFoV1RX?=
 =?utf-8?B?QjE5cUUwc1czYXlydVBHWGh4RjRCQkhwTEhuQ01SUE5YS3IzWGxqenpKd0pi?=
 =?utf-8?B?YmZwQ0lxUEZUTnMxNnVwSGgvNS82MzNIZkdKS2FNWSsvUGNIckk1ajFvdHRF?=
 =?utf-8?B?c1dTQ0wySllQb0Y5ZVRHVVJvUElDVkV6b0dmRUNJV1kyeFBKNXA1RW1haU9J?=
 =?utf-8?B?ci9QS29EOUwybjdpcU9PbXBhVnF5VHNrSUNHVEtFbjBreUdXcWVBQ0hiTE1l?=
 =?utf-8?B?YXRKaU5BelZ1QzllUXQyeHdvTVJ0akZMZktIVTg3MVdrb3lFaFErcm1MNGxn?=
 =?utf-8?B?UHp2L1V2SnRFUEY1MXNWUFc2RW9PWi9nSGM1YjRZM2NVWnVqNkFOeGd2WUpD?=
 =?utf-8?B?VE1NTUFOeVZqZ1lncGZLQlpuemVCRlBjRjAzcDdzTFdpenI5QUJxTVVBQzJI?=
 =?utf-8?B?ajhCbHF5cGJkM1A5WkgzZ3NSczRiRFpyWXFNcVpsRytINEJvMktRWjBMaEF2?=
 =?utf-8?B?NTNxSEZmMjhHV0lTM0M4c29VSzNXUTFGZktLbkNKc09oS1puUUFMeUJGWFQy?=
 =?utf-8?B?Q2JwcXVUQzNvK1VFTzI2OUpIZFNtWWlUdWhFekVzdGFSdnpqYUFncjdKbzBY?=
 =?utf-8?B?S25TNURHZTYxclgxejBaRzRxWUtVNGlRWU9Kb1U1amo4bDJUVEExWlByN2ln?=
 =?utf-8?B?c0E0R0JUNTBpZ1hlVG9vUDU1SzI1cDBvMVJyZ3FWd3hSRkthMGN1Q0V5R3Zp?=
 =?utf-8?B?OG9ZOVl1elRvc3dVdW94anZBcXdGVVkxQzcvekZWRXhrK0FENit2T1NocWNv?=
 =?utf-8?B?ajVObEVRTHRXcjZGRkt0U3Z6SXEwTVdGbUwzTnZGU2ttdGdxVXVPQWdkTTUx?=
 =?utf-8?B?aU1PclJwWUdEVE9MSC9MRHl5R21UdXZGdU95MzUzalJ3NjZHOTF0cDVkdmFV?=
 =?utf-8?B?cFFEME9GcFNJVzk1cTg3bkYrR0w0TTdhZnIrU3ZtS2tXV1dWL29WbHBJV2lx?=
 =?utf-8?B?QmYzRlBVNjVrWTg5blNXWTQ1QmMzSHhxY3AzOXlNVFd0cjl6ZjBkTyt0bW12?=
 =?utf-8?B?QUZQMGJDME81OWMrVHlEOTUvRFFOK3ZtbU9nUWJoNGZHU2RGRFc2R0RMdTZ1?=
 =?utf-8?B?bFI4NGYxRENuNWhkM09wd1NBS0kzSDlsOEQwT2c4VDlVM2VLOHg5aHFVbzFa?=
 =?utf-8?B?S09zWmd4OU4zWFhyNXV4VnJiTjdWNEFVVEtHYXVUUE4rNjVMVmRScVUrazF6?=
 =?utf-8?B?emgrNzBOMEsrRTNhV25NY2paM1NuM2hNTEh2NE5hZ1E1SXlnb0hTL1BvL2kz?=
 =?utf-8?B?aFBGTE8wa3pxQnNQM0QraDdmWlp4SjB6TDBGelpwSDVaTENiSmxJbUxaMXNQ?=
 =?utf-8?B?elZaYzJuSm53YksxTk5nUnRVeERRbHIyU2lBVURRT3VOM3BtWDRhTFVJaStl?=
 =?utf-8?B?MmI1cXVubmYvNU40UEhXZWV4MmRFTktRaFpMZGlFTFBDaFowOE1hRStDU1Vs?=
 =?utf-8?B?VVpvWmdnRTRrQUFRM2hvZG5YMVl0L0R5My9zOHNnOGRBbXc5V0VxVUtKMW8w?=
 =?utf-8?B?eURDVnM0MGwrTVc1S3dZNkk0TCt6VksxdWZ6WDBKbFphMkljbEVhYUpOdmtF?=
 =?utf-8?B?aXc3VHRTTlNuNVgvQnRJZGhhTTJnKzZDK2U2U2t5enhFQzRrdHUwdm9zVVps?=
 =?utf-8?B?SXdwZ2NSNEdYajNjNkFINHZLdTRXSjhkQURPNk1TVnBRejNLUTNNZlovN0lT?=
 =?utf-8?Q?O3QQ=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <89DCB45A0A219743B122B6FA3E669B90@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: 134a3f3b-3294-406e-da7d-08dda4d64991
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2025 08:44:02.0635
 (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: gG/m0ruOBX1h8QNebW0GUAJBsFrig82iS646+sBW+LTVaRUR6+RSxrJoRAYjbpvf2ZxX3EDvyMIKc8d1ghGcaA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB9281

T24gMjAyNS82LzUgMjM6MzQsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+IE9uIE1vbiwgTWF5
IDI2LCAyMDI1IGF0IDA1OjQ1OjU5UE0gKzA4MDAsIEppcWlhbiBDaGVuIHdyb3RlOg0KPj4gV2hl
biBpbml0X21zaXgoKSBmYWlscywgY3VycmVudCBsb2dpYyByZXR1cm4gZmFpbCBhbmQgZnJlZSBN
U0lYLXJlbGF0ZWQNCj4+IHJlc291cmNlcyBpbiB2cGNpX2RlYXNzaWduX2RldmljZSgpLiBCdXQg
dGhlIHByZXZpb3VzIG5ldyBjaGFuZ2VzIHdpbGwNCj4+IGhpZGUgTVNJWCBjYXBhYmlsaXR5IGFu
ZCByZXR1cm4gc3VjY2VzcywgaXQgY2FuJ3QgcmVhY2gNCj4+IHZwY2lfZGVhc3NpZ25fZGV2aWNl
KCkgdG8gcmVtb3ZlIHJlc291cmNlcyBpZiBoaWRpbmcgc3VjY2Vzcywgc28gdGhvc2UNCj4+IHJl
c291cmNlcyBtdXN0IGJlIHJlbW92ZWQgaW4gY2xlYW51cCBmdW5jdGlvbiBvZiBNU0lYLg0KPj4N
Cj4+IFRvIGRvIHRoYXQsIGltcGxlbWVudCBjbGVhbnVwIGZ1bmN0aW9uIGZvciBNU0lYLg0KPj4N
Cj4+IFNpZ25lZC1vZmYtYnk6IEppcWlhbiBDaGVuIDxKaXFpYW4uQ2hlbkBhbWQuY29tPg0KPiAN
Cj4gDQo+IA0KPj4gLS0tDQo+PiBjYzogIlJvZ2VyIFBhdSBNb25uw6kiIDxyb2dlci5wYXVAY2l0
cml4LmNvbT4NCj4+IC0tLQ0KPj4gdjQtPnY1IGNoYW5nZXM6DQo+PiAqIENoYW5nZSBkZWZpbml0
aW9uICJzdGF0aWMgdm9pZCBjbGVhbnVwX21zaXgiIHRvICJzdGF0aWMgaW50IGNmX2NoZWNrIGNs
ZWFudXBfbXNpeCIgc2luY2UgY2xlYW51cCBob29rIGlzIGNoYW5nZWQgdG8gYmUgaW50Lg0KPj4g
KiBBZGQgYSByZWFkLW9ubHkgcmVnaXN0ZXIgZm9yIE1TSVggQ29udHJvbCBSZWdpc3RlciBpbiB0
aGUgZW5kIG9mIGNsZWFudXBfbXNpeCgpLg0KPj4NCj4+IHYzLT52NCBjaGFuZ2VzOg0KPj4gKiBD
aGFuZ2UgZnVuY3Rpb24gbmFtZSBmcm9tIGZpbmlfbXNpeCgpIHRvIGNsZWFudXBfbXNpeCgpLg0K
Pj4gKiBDaGFuZ2UgdG8gdXNlIFhGUkVFIHRvIGZyZWUgdnBjaS0+bXNpeC4NCj4+ICogSW4gY2xl
YW51cCBmdW5jdGlvbiwgY2hhbmdlIHRoZSBzZXF1ZW5jZSBvZiBjaGVjayBhbmQgcmVtb3ZlIGFj
dGlvbiBhY2NvcmRpbmcgdG8gaW5pdF9tc2l4KCkuDQo+Pg0KPj4gdjItPnYzIGNoYW5nZXM6DQo+
PiAqIFJlbW92ZSB1bm5lY2Vzc2FyeSBjbGVhbiBvcGVyYXRpb25zIGluIGZpbmlfbXNpeCgpLg0K
Pj4NCj4+IHYxLT52MiBjaGFuZ2VzOg0KPj4gbmV3IHBhdGNoLg0KPj4NCj4+IEJlc3QgcmVnYXJk
cywNCj4+IEppcWlhbiBDaGVuLg0KPj4gLS0tDQo+PiAgeGVuL2RyaXZlcnMvdnBjaS9tc2l4LmMg
fCAyOSArKysrKysrKysrKysrKysrKysrKysrKysrKysrLQ0KPj4gIDEgZmlsZSBjaGFuZ2VkLCAy
OCBpbnNlcnRpb25zKCspLCAxIGRlbGV0aW9uKC0pDQo+Pg0KPj4gZGlmZiAtLWdpdCBhL3hlbi9k
cml2ZXJzL3ZwY2kvbXNpeC5jIGIveGVuL2RyaXZlcnMvdnBjaS9tc2l4LmMNCj4+IGluZGV4IDY3
NDgxNWVhZDAyNS4uY2Y3OTMyMGQzYjZmIDEwMDY0NA0KPj4gLS0tIGEveGVuL2RyaXZlcnMvdnBj
aS9tc2l4LmMNCj4+ICsrKyBiL3hlbi9kcml2ZXJzL3ZwY2kvbXNpeC5jDQo+PiBAQCAtNjU1LDYg
KzY1NSwzMyBAQCBpbnQgdnBjaV9tYWtlX21zaXhfaG9sZShjb25zdCBzdHJ1Y3QgcGNpX2RldiAq
cGRldikNCj4+ICAgICAgcmV0dXJuIDA7DQo+PiAgfQ0KPj4gIA0KPj4gK3N0YXRpYyBpbnQgY2Zf
Y2hlY2sgY2xlYW51cF9tc2l4KHN0cnVjdCBwY2lfZGV2ICpwZGV2KQ0KPj4gK3sNCj4+ICsgICAg
aW50IHJjOw0KPj4gKyAgICBzdHJ1Y3QgdnBjaSAqdnBjaSA9IHBkZXYtPnZwY2k7DQo+PiArICAg
IGNvbnN0IHVuc2lnbmVkIGludCBtc2l4X3BvcyA9IHBkZXYtPm1zaXhfcG9zOw0KPj4gKw0KPj4g
KyAgICBpZiAoICFtc2l4X3BvcyApDQpOZWVkIHRvIGNoYW5nZSB0aGlzIGNoZWNrIGFzIHByZXZp
b3VzIHBhdGNoLCBJIHRoaW5rLg0KDQo+PiArICAgICAgICByZXR1cm4gMDsNCj4+ICsNCj4+ICsg
ICAgcmMgPSB2cGNpX3JlbW92ZV9yZWdpc3RlcnModnBjaSwgbXNpeF9jb250cm9sX3JlZyhtc2l4
X3BvcyksIDIpOw0KPj4gKyAgICBpZiAoIHJjICkNCj4+ICsgICAgICAgIHJldHVybiByYzsNCj4+
ICsNCj4+ICsgICAgaWYgKCAhdnBjaS0+bXNpeCApDQo+PiArICAgICAgICByZXR1cm4gMDsNCj4g
DQo+IFlvdSBjYW5ub3Qgc2hvcnQtY2lyY3VpdCBoZXJlLCBhcyBpdCB0aGVuIHByZXZlbnRzIGFk
ZGluZyB0aGUgZHVtbXkNCj4gaGFuZGxlcnMgZG9uZSBpbiB0aGUgbGFzdCByZXR1cm4uDQo+IA0K
Pj4gKw0KPj4gKyAgICBmb3IgKCB1bnNpZ25lZCBpbnQgaSA9IDA7IGkgPCBBUlJBWV9TSVpFKHZw
Y2ktPm1zaXgtPnRhYmxlKTsgaSsrICkNCj4+ICsgICAgICAgIGlmICggdnBjaS0+bXNpeC0+dGFi
bGVbaV0gKQ0KPj4gKyAgICAgICAgICAgIGlvdW5tYXAodnBjaS0+bXNpeC0+dGFibGVbaV0pOw0K
Pj4gKw0KPj4gKyAgICBsaXN0X2RlbCgmdnBjaS0+bXNpeC0+bmV4dCk7DQo+PiArICAgIFhGUkVF
KHZwY2ktPm1zaXgpOw0KPj4gKw0KPj4gKyAgICByZXR1cm4gdnBjaV9hZGRfcmVnaXN0ZXIocGRl
di0+dnBjaSwgdnBjaV9od19yZWFkMTYsIE5VTEwsDQo+PiArICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBtc2l4X2NvbnRyb2xfcmVnKG1zaXhfcG9zKSwgMiwgTlVMTCk7DQo+IA0KPiBUaGUg
YWJvdmUgbmVlZHMgdG8gYmUgYWRkZWQgZXZlbiBpZiAhdnBjaS0+bXNpeC4NCk9oLCByaWdodC4N
Ckkgd2lsbCBjaGFuZ2UgdG8NCg0KICAgIGlmICggdnBjaS0+bXNpeCApDQogICAgew0KICAgICAg
ICBmb3IgKCB1bnNpZ25lZCBpbnQgaSA9IDA7IGkgPCBBUlJBWV9TSVpFKHZwY2ktPm1zaXgtPnRh
YmxlKTsgaSsrICkNCiAgICAgICAgICAgIGlmICggdnBjaS0+bXNpeC0+dGFibGVbaV0gKQ0KICAg
ICAgICAgICAgICAgIGlvdW5tYXAodnBjaS0+bXNpeC0+dGFibGVbaV0pOw0KDQogICAgICAgIGxp
c3RfZGVsKCZ2cGNpLT5tc2l4LT5uZXh0KTsNCiAgICAgICAgWEZSRUUodnBjaS0+bXNpeCk7DQog
ICAgfQ0KDQogICAgcmV0dXJuIHZwY2lfYWRkX3JlZ2lzdGVyKHBkZXYtPnZwY2ksIHZwY2lfaHdf
cmVhZDE2LCBOVUxMLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtc2l4X2NvbnRyb2xf
cmVnKG1zaXhfcG9zKSwgMiwgTlVMTCk7DQoNCg0KPiANCj4gVGhhbmtzLCBSb2dlci4NCg0KLS0g
DQpCZXN0IHJlZ2FyZHMsDQpKaXFpYW4gQ2hlbi4NCg==


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 08:48:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 08:48:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008200.1387429 (Exim 4.92)
	(envelope-from )
	id 1uNSkA-0006Qc-UQ; Fri, 06 Jun 2025 08:48:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008200.1387429; Fri, 06 Jun 2025 08: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 1uNSkA-0006QV-Ru; Fri, 06 Jun 2025 08:48:06 +0000
Received: by outflank-mailman (input) for mailman id 1008200;
 Fri, 06 Jun 2025 08:48: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 1uNSk9-0006QP-Jd
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 08:48:05 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20608.outbound.protection.outlook.com
 [2a01:111:f403:2408::608])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f2d70955-42b2-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 10:48:00 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by SN7PR12MB7249.namprd12.prod.outlook.com (2603:10b6:806:2a9::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Fri, 6 Jun
 2025 08:47:57 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8792.034; Fri, 6 Jun 2025
 08:47: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: f2d70955-42b2-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=VQkxvSoQ8nFiO1r1jXsoXDKEQOUt3rJwhb8gsbUf2h7MzXKSseOyFYhLbvDiySDBlKDuALoYoWgriEK6TXQRpYLxwf8efOLT/VOCXK7WTBYMMfgUBy2CYaP0zu56laWOqcW2k4H0UinDKo3K/YJMIM1QK67qZSbfWrQLTQ14TlCu47TVNXJE67iav7b+12/TeIClnzrYSmGLy64t5UZOHbNWwfdhQj67RTb57dNfqyJR5EAYKSSyDQ/eIR2A8jk780B4jwZkoH8R1wkubvDloSX5XdnkJqCxG/0Zhx9OsihZdSiypwiUK8QSdeC4m+XbM+dyDngU/WRA4WZ/10Z2RQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=/ewidhrATVjlQ/N+7yA9RGXlYoqwFSBej2a0wTWBTJM=;
 b=cII7FjI28Q2Y1R2Oqw4ablIoFQw7QustwfS1NL4GHMGyMZZ+0VCHI7P6f9ARRt/ckd4jkKVkpGLoNuAgKWOxLMuBoHIOymRz5M3ltbvcvCaghqlAbYamkWh2cojri7yvG/uIZUvs50Nk9Pa7RNuWVcq8VoUOG3IR1pdpfNQiBq84+2Wli8xyXQiDeou4iukO/orzUL96YWnspzKvzGWW/b6mCnRQFJkAJna+VW6jTsWy44r2Tj94yC4XU9jYAT5hGuXDqDcDTSKhgNgIueAUgbLyoGO9R2u0m/wlEreKNpwSlFWHh5thiQN520HTUc664xkM7ts3h/vrO5UsE//SUw==
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=/ewidhrATVjlQ/N+7yA9RGXlYoqwFSBej2a0wTWBTJM=;
 b=larG2uQ8yGqBjNL4R0iM5qpNsl/HQm3QneVDA4vZpH8aT9Ykx4sL//BwlIZIT5fj0xBAWCbJIlZwMlD4qyLfperrCtpapTicTdXxXSdlRZE46TkLy+BrAPvoZHMIPz7ehPT35Ed59TnO0pqv+8S115QE3N74NAyKSb8uHWYxE0s=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Fri, 6 Jun 2025 10:47:51 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 03/15] xen/dt: Add BOOTMOD_MICROCODE
To: Alejandro Vallejo , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 "Daniel P. Smith" 
References: <20250605194810.2782031-1-agarciav@amd.com>
 <20250605194810.2782031-4-agarciav@amd.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250605194810.2782031-4-agarciav@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR2P281CA0062.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:93::20) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|SN7PR12MB7249:EE_
X-MS-Office365-Filtering-Correlation-Id: 24959e41-5079-44aa-540a-08dda4d6d56b
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?M09pWnViZHdCZXVwSzZ0UEE1YU9WTHlPaVA3NDZ0Zk5EVXdKV2R6SGJ3THVq?=
 =?utf-8?B?Uk81d2ZYMno0emF1L2lxQ1M1L09EWHZ0YnNxb1BqWEl6aURObkJ0bWZYUnBi?=
 =?utf-8?B?ejhIUjJLWU83cnZaS3FhQlJ1WHVyeWxIQkFicjJFZzRyTk1MYzNaSXlwSVlF?=
 =?utf-8?B?bkc4QmR4Nlg1NHYwK2c4SVp6L3B4QXlweG1ZK2I4WHhJYTd5R085MGxzamxY?=
 =?utf-8?B?alVqc3hUNGhweXRjNE1KbkMxZ1I3cmtrL3ZENmhwWlg3c3Z3dHAxcTRkMGla?=
 =?utf-8?B?SkFwRzM2Z0puSGcxeENWbTM3bTZkNmNqdEJyam5nbUJFUUFaUVdXcGJFNVl6?=
 =?utf-8?B?dmw0aGdSUlF3NTlGWEt0cEdTTnB4VG5rd0h0Mlhyc2ZJOUdoN3ZVaWNaNVBz?=
 =?utf-8?B?TlZrQmRDTEZEbURjWi82QXVqZDkvaUQ2NTBTRU84ZnR6bVh0UWJwcVhib1pZ?=
 =?utf-8?B?dlQwUFlSQTBQTDd4VnU0ZnhCZGYwQ3dWS3dtYjd3ZTB5Z0tMbDZNYjcvTnpT?=
 =?utf-8?B?aU9iQ04xTlZsb0pHdEQ1Y25rK21QQjVUUkhCRlUzNEE1akFpTmVVRm9FS0ho?=
 =?utf-8?B?blpEOXBPQjl0aDhDWjZNOFplV2ZkODFxOGNKTEpUM0liMytCMGhhSWtjcEs1?=
 =?utf-8?B?cVVYTlJlZkZWSDJFeWhVY2Zib2pmQzI1bWdSWWMrWlZEQVZ1Nk1pekVCQy9N?=
 =?utf-8?B?bUV1ckdJd3ZBa1V0dUprcGtvRnN1VUg1bVZRc1hxV2xqZTREYkxjdlN3b1NM?=
 =?utf-8?B?Wk1vUVlNOWJsMWVCUWhVRHE5bjRyN1RVM2J4QkxJZW1pZDRyQzdKcHNHMzQ1?=
 =?utf-8?B?T0h4YXFST2N4NnFwYnhDbEltYWZ5Y2RseGkwQXhjTVJiYWl6ZTNqeVlteTVY?=
 =?utf-8?B?aUE4ZlE1cmptcmNhbFRCaGZnbXZvVGNtNDU2ZjdMZnNleFcrTGxSdUpUazNU?=
 =?utf-8?B?WmNsd0JNcVdqTjVsVy9TRnVzZmlRVE1JVE05QXVqSnRtWnVuK1cxd0dEN2Vj?=
 =?utf-8?B?WE0vc29Pc3NHVHM5dXU4eWd2YWgycWhJVXNFVVA2REFKN3JTeVJZWEFhYytD?=
 =?utf-8?B?K1Rzb0VEd1lhci9lL2h3OXlBTUovSzg0Qy9rb0NFK3dEUVVjYUIvcWh6QU4v?=
 =?utf-8?B?R09ac0VvbTNHcnZrUDNQcHNtUjZTd1dvc2RXK2NSckR3S1pTOExNQ1ZVVFNR?=
 =?utf-8?B?a3pjbzNxYlZIMktRK0N6a0p2WmcvQkhBUTNIT0JRRFdOL2ZpRjRsUjZhMXdl?=
 =?utf-8?B?ejlQL2ZVcUZ1OGF6aTdLVG1KREN4UkY0UjFXVjhhUkQzdFhibnhLNkxUVG5k?=
 =?utf-8?B?dWtaV1R6U0Job0F2UUdvcWluc0R4YjNSckRPbnRuNXVnK3k0SWhSWGpWMkJU?=
 =?utf-8?B?NXRpSS85b1Ivd0RxZHRaYWlTemkxV2V0ak1ER3A5YXpFeEhvdGo4RU5mZUI2?=
 =?utf-8?B?NTJybXRVYTQ5ckwzT0NRbE9kL0pIQ0dNWFcrMy96bjVyd21tNkJRL1pJQTlG?=
 =?utf-8?B?dDZLRjNlMjdCMlNDUDdpM0JITGlaVlRiZFBRSjBQUzF6dVV5elBML05zcGRZ?=
 =?utf-8?B?S3JLVE5maVFuL1dZWnNqSGxTOGtXU0lTVVVaRGt4SUxLL0hOdzAzaXJraWNn?=
 =?utf-8?B?VVZLeHZ3cmhWNWVMWmUrRzlncklEaU1sOTU4NUkrQWZYOHVNV2pIZ1I4WVJ1?=
 =?utf-8?B?SC91L3Z3cW5qMnB0RGJWSWxxK2RGRWxlOThhRkQzM1J5aGJ3OXZvWFI0SVhF?=
 =?utf-8?B?NDE2NHVtU3dDS0RPMzBBYlh6eUpyNlhlbE5WajBtUFdiMTVmYkRTTHowZnl5?=
 =?utf-8?B?YnhsdUQ3WlFxT1dIRUh5K2xvSlJVUGh5UnRPbURjUVBVS3BOSlZ1TFRpYko1?=
 =?utf-8?B?UkNGdzZlcHRNRDJ6cE5OdnRhUHFvZlFwSndocWlQbnIzZGp5cnhyY1oya21s?=
 =?utf-8?Q?uLLkyvhi92g=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.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?cklzTVhvNGk3K1pkd2VwKzk4M3FabHkzMGUzTmR3Z2RVdUZodTZPbFFhOXMz?=
 =?utf-8?B?OURadFFFaTlEVllKNU5Pa0Y3bC9jQ2czRmJINkVicjc5WmV1U0VwYkRsVzkz?=
 =?utf-8?B?aTBNOWQ5dlJUUUFlQVRtOWlod215NXhrYjJVZkhhUS9SdVY5bEcrN2drZzFC?=
 =?utf-8?B?ZG50dHFyUHF1a29VRFhNOE1Ec3BWRTZJMWlMbXZSME5wS3lDckRuZjU2R2Zu?=
 =?utf-8?B?NElwZlBPclJzYWtkTnp4cVdBUUFzYWxlMWJyRno3djFrODg5Mi93WStvdWNj?=
 =?utf-8?B?WHlkNS8veEJTYjVZZWx3Y0szMm9YcE1xRlJMbHBjK3UxcmJxN0JpRWp0VXQ0?=
 =?utf-8?B?NVR0ZEJqNzdTanYzNjB2VjExT2Y0S3hQSlZ6TEVGMlhZSWcwRWNia3lqd1pj?=
 =?utf-8?B?LzVMR1ZQQ3BhYSs2ckN6RTZGbTNldnpxV3V1R2VZTzg0Q2ZibTdNa0lPdzRM?=
 =?utf-8?B?L1FUVEVJeUdTNlVuSk0xUU5uTjJGMEFXdlhITHE5QnRLV2J4WnJuZ2JldTRP?=
 =?utf-8?B?QURpMWExZjNsTE56bG1RRW90RmNTZWR6bTlTRmluampKbXh3NzFIVU1tTUdO?=
 =?utf-8?B?UFpLSUlWeTUzZ0p5MzNTZm9vTXNGVkw2eENVK0Vjcng5cThQN0dsREoxY29Q?=
 =?utf-8?B?bE5ZSHVXUjRlKzJBaU9ad2FSQUxwbytYQzVBNVljWHRDbkcvR0hIZ2M4R1hT?=
 =?utf-8?B?NmFxMkVtYThOdGc2MFdaYVZydWQ0SXYxaFQ0c2VEVGtLb251UUlTQmpZRnVz?=
 =?utf-8?B?RVpOR1E3bnNWUTJCR2ZtMFpZYktSaVF0YVp6ZmtBU0dBQVV2T1ZnL1ZHdFhw?=
 =?utf-8?B?blRtNjlOOVJGMTZjRGNKaXBRRDRtcEhMRHRQWi9nSXdmeGFjQjFmM1hrN2Yy?=
 =?utf-8?B?eUtlUmd3Qk5CWFAwRGFKWDltVkRnbDUva0R0bkk3TWh1cm1jaW5zUzRha3FP?=
 =?utf-8?B?UytkdFFLN2NCTTMrR0RWbU0vQzl5Z2lvQWY4d0pnbTFKejE2Y1dDcDFyZ2dX?=
 =?utf-8?B?MXREajZnQldZeEEzYXVqS2lTdXhVclFwc1g3SW5hdDJnWVhMUDg2dmN1dnZF?=
 =?utf-8?B?LzBhZWVWS1hKMldzb0hQcTVEZzNQcWE2aU5qSE94VmVmaGhwVVM5aTJNUU9O?=
 =?utf-8?B?dytJaGVTOXpsdFU0dkFFSHJiNWREVnJEbm81MUU4eUk5a0QwRVdraDZ6VlBV?=
 =?utf-8?B?STNZUU9IZ2RHYUpJUXJlQWZrRmo2QkpnbWF1TnJSMFA3ODFqMkwxMER2d3ls?=
 =?utf-8?B?RzB5dEM1eTlkQ0VJb0Q2bm5sWmt3YnN4ZCtwYVN2cXN6QkI4bVdhbVBLaW15?=
 =?utf-8?B?dHcvVFdNRkFHVXpXOVFvanZKNjR4TmxKS1NXZlpKaVdkSkV1akxQNVhXV0RS?=
 =?utf-8?B?MC9JOGh6ejU5UFpvZGYvcnMySHZ6TGFXS09PZWpLQmRoeWtMWDRqNVNkRmd0?=
 =?utf-8?B?cDNXNk92anRPdVhpK3ZEcVZ2c0ZvL1REd09yVkNIcCtUQS9BenFXNmM2MERi?=
 =?utf-8?B?N2FVRUErZmR3T214UzJkakJyNm5VRUJlbEVSeGhsa0tuQWdMOFRNYnBVWEZZ?=
 =?utf-8?B?ZUpQL3FlRW9RQXhIYkNIR3lISDBnZG1nN2REQ1ZBSFZuZHI2TjRtam5KN2FL?=
 =?utf-8?B?ak01elpRN2ZoVWN5NWMycTZKQ01iTEhzYXpDazA2djJCTERyaWptQTRpWmhJ?=
 =?utf-8?B?QkZKcUIxdUNrV0ZRaE9VTHdqT09uUnBJYXpMN0VMalhzcEVsQ051UmxWT1ZS?=
 =?utf-8?B?NHh5RlJFWXlmbXNFU1FTdmRrZjJXQVM1c1JYa1k1T2sxaTNsWnBnUFdsY2Q4?=
 =?utf-8?B?RXp1TkdkeUNjNjJ4QzQzQ2Rocmh0eTNwcFl3Ly9kb0d0WjdQRG9PbnJJTXZ5?=
 =?utf-8?B?MTgrK0hKRmcxMW5LWHBabVRPdnJWWXo5TzZxRS91WDlNMWFocEZwUW9YRkdu?=
 =?utf-8?B?WGlyQXQ4azNLZzhoMWIwdnhWTkI3aWJaVlFqTnBjdW9xWGhleW9zdWZOaTdt?=
 =?utf-8?B?ZVYzT3BxcGhweXRWeUtqTmg2RytId2NiUkU2THNlWWVEbTdyQ3hXZnhVWjJY?=
 =?utf-8?B?MXZMNXJNR0RBaE9FOU5kclVCT3FDdjR5SS9HUVllTFBmVkRpT1pKSy9EakEv?=
 =?utf-8?Q?kiI0=3D?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 24959e41-5079-44aa-540a-08dda4d6d56b
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jun 2025 08:47:56.9187
 (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: Lj2oHsgR8yoqH4wAXyooG1SJ96Q0vVz0ZAmATTGLCET8icmG8zFThHBHH+RcjNc0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7249



On 05/06/2025 21:47, Alejandro Vallejo wrote:
> In preparation for x86 to start using bootmodule instead of boot_module
> 
> Signed-off-by: Alejandro Vallejo 
Reviewed-by: Michal Orzel 

~Michal



From xen-devel-bounces@lists.xenproject.org Fri Jun 06 08:51:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 08:51:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008205.1387440 (Exim 4.92)
	(envelope-from )
	id 1uNSnZ-0008N6-CD; Fri, 06 Jun 2025 08:51:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008205.1387440; Fri, 06 Jun 2025 08:51:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNSnZ-0008Mz-9T; Fri, 06 Jun 2025 08:51:37 +0000
Received: by outflank-mailman (input) for mailman id 1008205;
 Fri, 06 Jun 2025 08:51: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 1uNSnX-0008La-K5
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 08:51: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 7277c777-42b3-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 10:51:33 +0200 (CEST)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-452f9735424so871005e9.3
 for ; Fri, 06 Jun 2025 01:51:33 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-4521370961csm16644095e9.22.2025.06.06.01.51.32
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 06 Jun 2025 01:51:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7277c777-42b3-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749199893; x=1749804693; 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=PPZ6NqnXL6q+xDv3eAG4B/cDE9WJLsYSFLo93I5zeHQ=;
        b=FZqJg2TDzRznNbnuCdXJU+qo7wuGsr9NuRugerwbuF6pc5ZqGUZOEyP3HqU/4WIvjJ
         5oXxoriMPhgaGUrenQrF8fZnqd2jZwp4wZ2By24oU90bOvSaSx7GLHUcyVfwEI0QYKKa
         ve5uUJ3CpjdQNISClZBuLCpKeecPaviUOe8Xg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749199893; x=1749804693;
        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=PPZ6NqnXL6q+xDv3eAG4B/cDE9WJLsYSFLo93I5zeHQ=;
        b=ePhVCopfvuQPPEPy7NQukLJhh8BDTBMmXMEyV0IyHmxfAZvNuREyHMWgMuGBo0FUkr
         ppi0NJdS89wswOsQQ3Ac0kKcDcpWcohlE26LX9/hGuZ1p+Ycqzs7SUhob0vRWaJQKyXt
         C+2xNaWH0Neia39WU2LxQb/B6xwaH31TnyFxbAbSLPM/GlrsplMFLKVvkWrd8GeJ6gSs
         ipWTrsZV43RXErHJyl7WiWiq7z9ekjC3QeFES5D5gGy3c8ntY+1cgyd6YJBevJSiofNZ
         z5+JZPmBtUk1QDnJnDcB4hli4o8nitL4BpgoD12Y7j4P6zKdUrS9axt97i5KwLv8BMwP
         daFw==
X-Gm-Message-State: AOJu0YzOZaT6LqNXPbuoT372TQMRi28IffA0ouZfZd9zIWk6tTrwwrX9
	k2EUMFE7zmsr86X2xGhKvjgCeuMv3uSIUfnEzb6VJIfH5O65FR2w0p0Mk+ifXk7MWJU=
X-Gm-Gg: ASbGnctdkte5Wttcq89gapM/OoJmqKsbfl4uZK4A2VaihloRoiG+E9hs8Hi1Tr/RzM6
	AWqcKSo6NsMlitsdgCPYCC7nGOuqVYRb1AQBNmx5rZAleT3eecdcrNHtbpibOtu+qvj5vYYb+o5
	whPFxhn0SEaHET7blCWltxp9XeC1ly3ubBNVpyAM0qTF9R8fKz/lxL1uHlPLeV3G3uqGbiCmbSI
	S6z8lBJ2iGn3mBCZpWPSSB/esZUwGMC3Fu6Xgd74+XESevAFQB2VWEY1KouwJR7M7FBjhzS+uEO
	FvuWb5i118zptro7ufaK8dPNBDResl9tPGmuSICHLSlxMuR8t2KjfmS03vBdU9BOWJXMB++kAoN
	FoEOUJIn62Lfp6XIsadl7/v6imUucdr6zJGg=
X-Google-Smtp-Source: AGHT+IErWMbsB0wY3O+wdtNi2PpUslq4ockNbaK6je8AWwJc2Xf0c1Ec3+JGjy1W3I0xHZhwxbPwbw==
X-Received: by 2002:a05:600c:83cf:b0:445:1984:2479 with SMTP id 5b1f17b1804b1-45201417666mr27578295e9.5.1749199893054;
        Fri, 06 Jun 2025 01:51:33 -0700 (PDT)
Date: Fri, 6 Jun 2025 10:51:32 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Alejandro Vallejo 
Cc: xen-devel@lists.xenproject.org,
	Bernhard Kaindl ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH 08/11] xen/memory: Enable parsing NUMA node argument in
 XENMEM_claim_pages
Message-ID: 
References: <20250314172502.53498-1-alejandro.vallejo@cloud.com>
 <20250314172502.53498-9-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250314172502.53498-9-alejandro.vallejo@cloud.com>

On Fri, Mar 14, 2025 at 05:24:59PM +0000, Alejandro Vallejo wrote:
> Extract a NUMA node from mem_flags. This _must_ be an exact node, and
> has the semantics of making a claim on a specific node.
> 
> Signed-off-by: Alejandro Vallejo 
> ---
>  xen/common/memory.c | 23 ++++++++++++++++++++---
>  1 file changed, 20 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/common/memory.c b/xen/common/memory.c
> index 1ab0bac4e7da..28f9db89ba62 100644
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -1659,6 +1659,9 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>          break;
>  
>      case XENMEM_claim_pages:
> +    {
> +        nodeid_t node;
> +
>          if ( unlikely(start_extent) )
>              return -EINVAL;
>  
> @@ -1671,9 +1674,23 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>          if ( reservation.extent_order != 0 )
>              return -EINVAL;
>  
> -        if ( reservation.mem_flags != 0 )
> +        /* Only allow NUMA-related memory flags to claim on exact nodes */
> +        if ( (reservation.mem_flags &
> +              !XENMEMF_exact_node(XENMEMF_node_mask - 1)) != 0 )

Are you sure the above is correct?

!XENMEMF_exact_node(XENMEMF_node_mask - 1) resolves unconditionally to
false, and hence you are doing:

(reservation.mem_flags & 0) != 0

Which can never be true?

I think you want ~ instead of !.

>              return -EINVAL;
>  
> +        node = XENMEMF_get_node(reservation.mem_flags);
> +        if ( node != NUMA_NO_NODE )
> +        {
> +            /* Disallow advisory nodes. If present, must be exact */
> +            if ( !(reservation.mem_flags & XENMEMF_exact_node_request) )
> +                return -EINVAL;
> +
> +            /* Disallow nodes that would overflow the in-hypervisor arrays */
> +            if ( node >= MAX_NUMNODES )
> +                return -EINVAL;

You can likely join all checks in a single condition.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 08:52:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 08:52:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008215.1387450 (Exim 4.92)
	(envelope-from )
	id 1uNSok-0000Y8-O5; Fri, 06 Jun 2025 08:52:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008215.1387450; Fri, 06 Jun 2025 08: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 1uNSok-0000Xz-LJ; Fri, 06 Jun 2025 08:52:50 +0000
Received: by outflank-mailman (input) for mailman id 1008215;
 Fri, 06 Jun 2025 08:52: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 1uNSok-0000Xt-9G
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 08:52:50 +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 9f93ba39-42b3-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 10:52:49 +0200 (CEST)
Received: by mail-lf1-x12a.google.com with SMTP id
 2adb3069b0e04-5536b9be5f6so121195e87.1
 for ; Fri, 06 Jun 2025 01:52:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9f93ba39-42b3-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749199969; x=1749804769; 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=S3Nf4nRdpm8xP37eHHBxcbHah62cYVPy+P3J3XUcmyc=;
        b=JyH+5U+rmKl5dwBirfe6u3EACqrvl+x2OjLRstgZvK199kxnHoRdOG1bn4ddtln230
         OWaEtxWoR2yX7k7KSOBGCYqvHXpffiZhlOIm/bWY43tdkxl4fMVp0/gG/TxpotPX+L4c
         sk0gVFWHX5e+KJS1fxXby2mwooauiy/zv8ySpMrDHfQ7dNXEPopgwX+1WMKxl3YbPyo3
         IN8flc0b7CRd9jOowntJscFg3Z0RsGtcD8bu38inTFfZjWFIC+sD+MDRggDXLqI4lPGQ
         8BJn3MxU/fuCjEQDFtviAVk+C8aqRhPta7cRGnekLsSqlrSX5Hgl7UevHDANVueKw77B
         P3rw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749199969; x=1749804769;
        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=S3Nf4nRdpm8xP37eHHBxcbHah62cYVPy+P3J3XUcmyc=;
        b=clwrfgpG8JTU9B4bf4aEM6ArshtG1gfhITswhLCJLgHZEVGriXzOVucX+ExWqHap8Z
         NW8+DBMAf6nIWWh9iDMm0i9x/Nb0TUGKyCJZOBY7iwUW82ZMcbpZFI6VRP1G77mV2mVK
         LFTc2u9IYFH5GXAHSHEDzvMxJsO4a5aqXyBPK26Qgpi1rc02qEDmz81aVv910eQ6U46Z
         yaAZ55DVYyR4Ok4e1DzTnyEKZ0I8SryULrzodNJGC48sOB1ve7vaiugIJha+UFvyAvTq
         Q8fl8TsN13fd1zdL1qE77rLlT09zvtPcRHC/DRiHA4xaResNyEhyAPPYr8UpLhhJqKqV
         bJxA==
X-Gm-Message-State: AOJu0Yyb6Kqk3gL4G01lqfDxF7LfVcGQ9inG4VyeSfENriNQMFezk8dS
	Y1BOimn7ArsFm1U3LBllvhmSLVNlf6w7DcfF4grPed5FxO+EKJudh+sygWDX5kcRN4TwFkdA5KV
	Ut6KjmHflWAQ1GM4kH4/DGb424rl8g9E=
X-Gm-Gg: ASbGncuwhkfFnJTUeZcWVmL70zn7TXFZrrH4G4i2WTISNkCtF01l19yBhXi6wVzBrIX
	NTIcUVCDD/RtcHK90sVFTLNl5vG457DLhU19TZuYAO/HM2th4rLJ2uDZ/OTMqFzx1RjhuoVZSsY
	vu8fHvX1tHnG3m31rtly3o9atyZStSSaRhdRMsC4tchg==
X-Google-Smtp-Source: AGHT+IG/4FjqOIqTJlSdM9LbyL3BroQn9ZmIQthGyrfyi1Z8DsSBdASAua3/hxY5j36DXQhJwa5M+Lyv7DA2ls/NxT4=
X-Received: by 2002:a05:6512:1152:b0:552:41b:1c79 with SMTP id
 2adb3069b0e04-55366e3392fmr633324e87.49.1749199968385; Fri, 06 Jun 2025
 01:52:48 -0700 (PDT)
MIME-Version: 1.0
References:  <1a8313537603bee36636b0fcd2fdc2f76a2374fb.1748337249.git.mykola_kvach@epam.com>
  
  
In-Reply-To: 
From: Mykola Kvach 
Date: Fri, 6 Jun 2025 11:52:27 +0300
X-Gm-Features: AX0GCFsYfcnfvTo_OfEkwLkYsRhAayuPBc4W_HWX2GBiN3-wManB95tRLkfvsxg
Message-ID: 
Subject: Re: [PATCH v4][PART 1 2/4] xen/arm: Implement PSCI SYSTEM_SUSPEND
 call for guests
To: Julien Grall 
Cc: xen-devel@lists.xenproject.org, Mykola Kvach , 
	Stefano Stabellini , Bertrand Marquis , 
	Michal Orzel , Volodymyr Babchuk 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 6, 2025 at 11:40=E2=80=AFAM Julien Grall  wrote=
:
>
> Hi Mykola,
>
> On 06/06/2025 09:26, Mykola Kvach wrote:
> > On Fri, Jun 6, 2025 at 6:52=E2=80=AFAM Mykola Kvach  wrote:
> >>
> >> Hi, @Julien Grall
> >>
> >> On Wed, Jun 4, 2025 at 2:00=E2=80=AFAM Julien Grall  w=
rote:
> >>>
> >>> Hi Mykola,
> >>>
> >>> On 27/05/2025 10:18, Mykola Kvach wrote:
> >>>> From: Mykola Kvach 
> >>>>
> >>>> This patch adds support for the PSCI SYSTEM_SUSPEND function in the =
vPSCI
> >>>> (virtual PSCI) interface, allowing guests to request suspend via the=
 PSCI
> >>>> v1.0 SYSTEM_SUSPEND call (both 32-bit and 64-bit variants).
> >>>>
> >>>> The implementation:
> >>>> - Adds SYSTEM_SUSPEND function IDs to PSCI definitions
> >>>> - Implements trapping and handling of SYSTEM_SUSPEND in vPSCI
> >>>> - Allows only non-hardware domains to invoke SYSTEM_SUSPEND; for the
> >>>>     hardware domain, PSCI_NOT_SUPPORTED is returned to avoid halting=
 the
> >>>>     system in hwdom_shutdown() called from domain_shutdown
> >>>> - Ensures all secondary VCPUs of the calling domain are offline befo=
re
> >>>>     allowing suspend due to PSCI spec
> >>>> - Treats suspend as a "standby" operation: the domain is shut down w=
ith
> >>>>     SHUTDOWN_suspend, and resumes execution at the instruction follo=
wing
> >>>>     the call
> >>>
> >>> Looking at the specification, I am still not convinced you can implem=
ent
> >>> PSCI SUSPEND as a NOP. For instance, in the section "5.1.19
> >>> SYSTEM_SUSPEND", the wording implies the call cannot return when it i=
s
> >>> successul.
> >>>
> >>> I understand that 5.20.2 ("Caller reponsabilities" for SYSTEM_SUSPEND=
)
> >>> suggests the caller should apply all the rules from 5.4 ("Caller
> >>> responsabilties" for CPU_SUSPEND), but it is also mentioned that
> >>> SYSTEM_SUSPEND behave as the deepest power down state.
> >>>
> >>> So I don't think standby is an option. I would like an opinion from t=
he
> >>> other maintainers.
> >>
> >> Sure, let's discuss this with the others.
> >>
> >>>
> >>>> +static int32_t do_psci_1_0_system_suspend(register_t epoint, regist=
er_t cid)
> >>>   > +{> +    struct vcpu *v;
> >>>> +    struct domain *d =3D current->domain;
> >>>> +
> >>>> +    /* Drop this check once SYSTEM_SUSPEND is supported in hardware=
 domain */
> >>>> +    if ( is_hardware_domain(d) )
> >>>> +        return PSCI_NOT_SUPPORTED;
> >>>> +
> >>>> +    /* Ensure that all CPUs other than the calling one are offline =
*/
> >>>> +    for_each_vcpu ( d, v )
> >>>> +    {
> >>>> +        if ( v !=3D current && is_vcpu_online(v) )
> >>>
> >>> I think this is racy because you can still turn on a vCPU afterwards
> >>> from a vCPU you haven't checked.
> >>>
> >>
> >> I'll think about how to protect against such cases.
> >> Thank you for pointing that out.
> >
> > Is that actually possible in this context? If suspend is successful, we=
 pause
> > all present vCPUs (including the current one), and control is not retur=
ned to
> > the guest until either resume or an error occurs in this function. Sinc=
e this
> > runs as part of a trap, the current function can't be preempted.
>
> AFAIU, this code is called before suspend is completed. At that point
> you don't know yet the state of the vCPUs. They may be scheduled on a
> different pCPU. At which point, they can issue PSCI_CPU_ON.

Got it, thank you.

>
> >
> > Also, from the use of _VPF_down (via is_vcpu_online) on Arm, it looks l=
ike
> > guest requests are what manipulate this bit, which further limits what =
can
> > happen concurrently.
>
> I don't see how this help. See why above. So you will want to at least
> pause the domain before checking if all the vCPUs are offline.
>
>  > Note: It looks like the same behavior is present for VCPUOP_down as we=
ll.
>
>  From a brief look, I agree the same behavior is present there.
>
> Cheers,
>
> --
> Julien Grall
>


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 09:00:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 09:00:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008221.1387459 (Exim 4.92)
	(envelope-from )
	id 1uNSvf-0001Ac-Do; Fri, 06 Jun 2025 08:59:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008221.1387459; Fri, 06 Jun 2025 08:59: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 1uNSvf-0001AV-Au; Fri, 06 Jun 2025 08:59:59 +0000
Received: by outflank-mailman (input) for mailman id 1008221;
 Fri, 06 Jun 2025 08:59: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 1uNSve-0001AP-LA
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 08:59:58 +0000
Received: from NAM04-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam04on20603.outbound.protection.outlook.com
 [2a01:111:f403:240a::603])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9d76056c-42b4-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 10:59:55 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by MW4PR12MB7030.namprd12.prod.outlook.com (2603:10b6:303:20a::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Fri, 6 Jun
 2025 08:59:51 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8792.034; Fri, 6 Jun 2025
 08:59: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: 9d76056c-42b4-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=TdrSDoUy6ZG8QGr9ZS0JbuZV0lofNP5UOu02L8VRFJQw+WVfxuhy279tQvX2XHfvaKyDxKFYmQblcsSfc3sp78HHKaRfI7aYpGj3aUX3vCWpjDIZMR3GScYvPdJD4uQrIFG+4HtfS868bDf9luMGEQHS4a1BGKMqWsUSRRF5VI7iNbg8UdfAiQWDZ5G6PTU8FUK/I+JhCEDApP/3mNSf5XlpuHNU3/kSdjZKVIUyB7iLX/E28fCnYvTCPmeQJSATMHp2rOoRhQR0E+iXTmgxrouwEJ5tVRutJihMhNQBHM3WyGyUCRc2HY987fye+H0QAPqgfYNM2vVofGWPH7ovnw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=lt7+JgPak//uhAmKdPFbycTD6ldH9c/uva0/xO3FQBY=;
 b=U7zX5gvIjWKhjRQPsF0qL9AZOMP4/465uMD77Grr4tSs7mSRLVLqS0QI/+KqDQIsnCOssO7HgoOvw+O6N8tduTPQxqn2zcoBcLTQA/hi8zwOOtwt+SBYFqmkGFGSf+jZdhln//RYdCXF5zIGfPl4hSOkbX+vLcP7Qo1cmewBPjxOvlF5l6mpIczV21wjIVz9b951WypG6X6JonaUcHMeGo7AAeqp6noPBwnwqTaLLppM6NBh1dA+JGiWnPK5chgpC7hntDzip6iXCXIYZp8b1la9cWXgtTQmCxuHDzvXWhuro//VRSJ5x/12CtwBOKWkNKGMoI1dTIyjjUsOmkbVKw==
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=lt7+JgPak//uhAmKdPFbycTD6ldH9c/uva0/xO3FQBY=;
 b=wHjh2sC5EkrhbnUSZbrqaHS7Dvszu0VzsFUMFknZnS4LKDhs8EFIwYWhWJYCpyPRQH/BYlVlraC+t5habrwroX7sAm6wcq5Oj+xYHiRlRJwG0diBWgJFIaQVgdH9TnNyGemeDuoxPp7fpzl2f/wPJ+fvRULczgCSPxyq4l82d6Y=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <633ffa7f-cf26-4ec3-a153-28404c39d882@amd.com>
Date: Fri, 6 Jun 2025 10:59:42 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 08/15] xen/dt: Move bootfdt functions to xen/bootfdt.h
To: Alejandro Vallejo , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk ,
 "Daniel P. Smith" 
References: <20250605194810.2782031-1-agarciav@amd.com>
 <20250605194810.2782031-9-agarciav@amd.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250605194810.2782031-9-agarciav@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: DXXP273CA0018.AREP273.PROD.OUTLOOK.COM
 (2603:1086:300:2::30) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|MW4PR12MB7030:EE_
X-MS-Office365-Filtering-Correlation-Id: 8813d543-1282-46e8-f593-08dda4d87f3b
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?NDlDMmluWno1cG1wRjIxSS80V2xVL3I5VTMySHZKMUlrMDJnM0h5K3NLMmNx?=
 =?utf-8?B?L0lBR3dWb3Bpb25EYnZxSWNhbndxd0dVci8zSjdDUHVKM1h4ZExpWENycUl4?=
 =?utf-8?B?ZmkxVHZIUHV4RGRLaHhwcUNqa1IvVzRvTGtqeHRRNFcvZTRKcEdJUmZqUWVj?=
 =?utf-8?B?TXJMMWxqajBva0Z6UHZYZXZ0K3p6aXVmYnNqWUxObFRxZ21xeVlFdTduZDZr?=
 =?utf-8?B?MU5GeEVaMkJ6S1E2YW5QL0ZnenEzUDRBbEJxRFJWeW41Tmt6MlNCYURSSjBQ?=
 =?utf-8?B?M0dSc1JyYUhTZ1pxZmV4c0dNUXlEOEI4dW85US8xUlZMdGkwaHRoRnJtZVdM?=
 =?utf-8?B?QnBiK2lGN2V4THNOQ2k3NkdFcjlpVGpqTDluUFZwdUsydTFJbFl1RXhLeEdO?=
 =?utf-8?B?MXVMa0FKa2ZmSTk3YUl3d01PYjBjTVlYMmkzVm9iM3A4eHkrakpaOVVHaEVR?=
 =?utf-8?B?T1k2eFFWMFJKR0RNKzdGTUlhRFJzV3ZTa0RlUFZpdmxyVjFERXU0ZUh5RDNR?=
 =?utf-8?B?NTJBK2J4bUtvdzBWajhsUFYyYjBudkkrM0YwcFFGVTdWQWpWZlhEQkFZamNO?=
 =?utf-8?B?UXBhdm8rcWh2NlVqMEwwOW5QZDlLbWNHRU9IV0hpd0xiRmwrL20xbDNnN0Vx?=
 =?utf-8?B?S3ZOcVFqcWdTL0VGSE5QQVAzelVPcUQ5ZDJDc0RDN2pRNEZpblhwcjZ4QzlT?=
 =?utf-8?B?Y3A4U3BpV0VlV0tTYXRtd0F0a1R1TFlXUXY4My9ad1hXSDNwM29EeGlyc01y?=
 =?utf-8?B?aHBiNFhaWjk5cXIyRzlabTdvSU96THNyOFdycThyWWpWTWwwUEE3ZTdEMzhy?=
 =?utf-8?B?LzZ1aHZqSWd0UTUwK1pWWlZ6elZLL3p5bzhlN1M5akZHbFlpM2p4R0tkOFNU?=
 =?utf-8?B?UVRabU5MUWpsTXhMai9TOXEvL3Z6T3owWjFmZC9aNXF4clBZbjlXMXN3QjU0?=
 =?utf-8?B?Y1BEZDZqL3AxUFBhaW1EQ0dWZDNuZGttbVZOQXA1OVdiVmMrZUlGR21hTVcz?=
 =?utf-8?B?Y3RFTU9Pb3AvdnpmT1dlYjdpVy9ua0RNSldOZVV1RHNweGZzbmU3MXpDRUpI?=
 =?utf-8?B?RHBFQnA1WVgydGN5QjFVSmsraWNaakxESkkrNWNyQlNjNFJCNmViU2M0RTJr?=
 =?utf-8?B?QlFSM1ExUWNCTWpjeUZBMk9NUzk4aWlMdjVrZ1FxRTRRU3N5aGFBTjBHRExJ?=
 =?utf-8?B?TkY5M0ZCeE1jdmM5UjBPRVZCeS9EdE91bGtGVVFneXU1amtGRTFWSkdMRGZB?=
 =?utf-8?B?VjRMenEzSGFKNmJFc29KYTA4aEcwaGhTcXYrZGVlQlJsMkxNQkVDT0pXbGFi?=
 =?utf-8?B?ZGZKQVJZdGpLU0VkZDlqQTc3R0xXM3J3dFE1U3ZhU25BYVNoY3NRMzY1eDEz?=
 =?utf-8?B?YTJENVZyK0NWano5cldzSERQeU9RUEdTNjRpMkZRQ1d3bUxmVTc2bXN1dy9y?=
 =?utf-8?B?WkM4RlNYWUtKU0RiK1lZZ3pTR0hWSWZHNXVCVFdTQUUwVjJZRXkzVHl3OTNs?=
 =?utf-8?B?cDRBWEVKbkVHdUtFYzYwdGJyZWorTGZWUVdQOWllTUI4MldYQkhyNGhVL0xJ?=
 =?utf-8?B?VU1QbG1aaVArS2lzUzVMMUJqcUFFdjFLZFRVanYzNXc3Mi9JWjJRb1o5Z0NT?=
 =?utf-8?B?aG5EM0lFRnUveHJ6M0YzWDcrQi95QlVkNkVlOFBUOVRzVkpnQVc4L0xPaHgy?=
 =?utf-8?B?RklEb0xjelArcHFrMkI2ZE1xd3kyT1l4amNHYW4wTG9NOWJka0s3M3Q4UEtn?=
 =?utf-8?B?Zjg2YWxHK1BXZWdvMUp2VTBDM01pUksyOTFockJyV01PSHlDSDlhTHFhdGZK?=
 =?utf-8?B?UzlEczQrRWtsL0g4cHI3Z3JmSm95K2swVStZUGlaUFBacWJ6TUk5OVlNdkM5?=
 =?utf-8?B?OHU1YjJwT1d2d1NpVVBUREhpTm40RmZHZlRJTkhrSWd6RXdnU2hEc0hlbUgz?=
 =?utf-8?Q?YUXyoeDlNJs=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.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?YW12Z2IyckdXLy9ES1F3bjhOZ3I5Mmh5WDk2ZThyTFhLL0YvVGRIcnIwYjgy?=
 =?utf-8?B?alhiRXpXbGRhbnoyWUZxQ1dVU2VqZ2xaN1IrUnRTY3h5aHdOTVJoM09TY1g1?=
 =?utf-8?B?dm9NZVlLNGhJOEpaZzBvN3RNckxqcWhpVlVaRW5lR3VORWxXTk1kd3E2WlBN?=
 =?utf-8?B?RWw5M3Q1VDZLaTlMaW9yU0lLU3VnVlExU1FlMUhPZWRadjFWK1c4akt0cUo4?=
 =?utf-8?B?a2psbkVIa0tITHA5S3NiakM1N3JUV0N2L0MwVjJZb0tiVTJtaVJycFZDSW5a?=
 =?utf-8?B?WFJ1Rk4rd1k1SXQ0VGRibXphNVhxcFFtREh0NUlnVm56N1FYNld5RFdSTnVp?=
 =?utf-8?B?N0VLVnZmZVBnblg5dWNNdDFSVmhkdVl1TXRPM0hwRmlMb2FoNTh3QXN6TjRZ?=
 =?utf-8?B?MU40N0tyOXZuSkp1aWVvNk9Lc1JnS0RsOXJKTzFDd01rUndxVWhwS28yTllY?=
 =?utf-8?B?eXl0SUo0RHpKeFUxOExKemQrdXpLVnQ5dEZFSy9qT2hwc3JPRWg0OG1xZHVT?=
 =?utf-8?B?NjhYZ1FwaXMxVG96T25nSHFXRURuYVF1RzE5b0pKeDdIMnE5N2p4RFBhZnMw?=
 =?utf-8?B?bXdJQ2ROeFRvQ1MrTFBOYXFxcWQ1Qzg3MlZRcHpjUlU5YVFmLzl1YnR1S0hM?=
 =?utf-8?B?RGxnb2JqeEEwTk9GanQwNmZDeFdyM1ZHUVhRQmlLRUFqSmZCakhzNFpoUUdZ?=
 =?utf-8?B?STlaWkkvUFd5M2NwODVTRWVVRk9ER1ZwVFJjdnkydHVXWGNUbWZ6dHE4Uytt?=
 =?utf-8?B?Zk9KQmhsNFZsc3hRcU9DMlJTbWVxdVdGRGF1TmhUb3lrUzJudkpCTVdqVjZS?=
 =?utf-8?B?N1Zka1FLbVRwTHF1c0hJQjVDYTN6MW0zVTYrSndWcDZyYllGZ2FiQkQ5VWdx?=
 =?utf-8?B?TU9HUC82MndMUGdSMGR4U1NnUHEza3ZIaXlwRExoR28zd0ZObVUzTWdsTGVj?=
 =?utf-8?B?NFNTREozMFlKTncvTWE5cnJJd3V4aDB6cy9icXZLeVp2VkVKNEwvY3lQKy9p?=
 =?utf-8?B?cTVucVBqQW41TkZWZ2VuMllnWG9pWnk0S0xJOHdxYW1LeFNQdjVyWW5wdFBm?=
 =?utf-8?B?Z3lYcUZYU0dJZUp1RnRhanV1YnJCNDBnM2Q5Sy9nUExzOHZmczg4am5zVzY1?=
 =?utf-8?B?L3puQlZlTWU4L0lxRjVnemFtbEZyQzdkbjY2V2RWMDhsZmJBUCthTUU5dHlz?=
 =?utf-8?B?N2txalN1Q09tb2pCUUZwOWI1YUN5MEpTcENtdjZjYzlkVE9acVp6VmdXS3Fm?=
 =?utf-8?B?b0VTVUdubFFJaTF3dTdVQ2NZVCtsVU1xOXBlay84ZHZOVEZDd1ZSTTFtbXUx?=
 =?utf-8?B?K0ZCK2JnTHRhM3ZQWEtNT0ZocDdjQURNTmUxUFRhRkdYaGtJMmtsWFVWVE96?=
 =?utf-8?B?Z0RGV0w1N1phNTFmckhJT0ErRGpyRzU3Mzl4Qm1MZk83OVQrSUdVSEFReURB?=
 =?utf-8?B?Qk96aUJ1Y25JelZYVXFha3EwOW4ybEV0YXAvSTV2Z0IwRTJlbTJVMDRjcHJC?=
 =?utf-8?B?dHRqWThSamN4SWZpV3dzWjkrNDllako1cTRQYlE0NXR5cmxIK2tuQXlFand2?=
 =?utf-8?B?dW91UVh3WkM0MU9tM3F3S1d0THlXaThZazZ1L2I5MEVLUzlvWDczNmNoc29Z?=
 =?utf-8?B?UFdoTENiV3FWN0FnaTB5TGdPTU5yWWZGZm1PZVFOeUpsL2hQM1pvc0VkWmlS?=
 =?utf-8?B?U2NmaWdOMFRRWk9LQk1KZHU2MGI3MjNvTit3aHMyS1VQejZMaEo1QVRlMk1q?=
 =?utf-8?B?bkdqK2czN0ZNNUl3azlOZk52dUZzTFdCWTdkV2R0dk9ySE0zWUpiS3dKMXpq?=
 =?utf-8?B?bkRuTEUxWDVRcStSaFJHS0ZZYUgzRjQ1Q0FPNkhIZXBRaGVxa1UvK2lmUzlR?=
 =?utf-8?B?RWFPQU5Vbk5OVG95aTBlRDlRdXpla1llRXpIYUNSK3FwRUtOSHhCd2hsTHJT?=
 =?utf-8?B?OVBuN1FOSEdjVTVHUFJIV3JaZWplOGYvQzhBOEp0MXltSUdYTjZUU1RPcllZ?=
 =?utf-8?B?ZWQxWEJvWW8yRmlKdkcwWWZTaUhXSVBBOWREN2lTVkxBdTFldzJNMktieUdB?=
 =?utf-8?B?RE00Rk5Na29ZS2U3OEpTbUllRC8yTTc0aHl6L1EyVXpNTmpRN3Vhd20wMCtt?=
 =?utf-8?Q?FpGTDQ1vIMgYFw6pYEtBdatx1?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8813d543-1282-46e8-f593-08dda4d87f3b
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jun 2025 08:59:51.3739
 (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: lH06Z38FbWKAp8BOrp535pYGKzc7TL78nXFDoCK9m1kRKeEvWo1sYzyUrBPuq3lC
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB7030



On 05/06/2025 21:48, Alejandro Vallejo wrote:
> Part of an unpicking process to extract bootfdt contents independent of bootinfo
> to a separate file for x86 to take.
> 
> Move functions required for early FDT parsing from device_tree.h and arm's
> setup.h onto bootfdt.h
> 
> Declaration motion only. Not a functional change.
> 
> Signed-off-by: Alejandro Vallejo 
> ---
> v2:
>   * Remove the u32 identifiers in the device_tree_get_u32() implementation
I don't understand the reasoning behind changing u32->uint32_t only for one
function in this patch while leaving others unmodified. Also what about u64?
Either don't change any or change all.

>   * Fix an existing const-stripping case.
These points should be mentioned in the commit msg.

~Michal



From xen-devel-bounces@lists.xenproject.org Fri Jun 06 09:00:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 09:00:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008223.1387470 (Exim 4.92)
	(envelope-from )
	id 1uNSvw-0002Qj-L8; Fri, 06 Jun 2025 09:00:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008223.1387470; Fri, 06 Jun 2025 09:00: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 1uNSvw-0002Qa-IU; Fri, 06 Jun 2025 09:00:16 +0000
Received: by outflank-mailman (input) for mailman id 1008223;
 Fri, 06 Jun 2025 09:00: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 1uNSvv-0002Dw-I2
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 09:00:15 +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 a937c99d-42b4-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 11:00:15 +0200 (CEST)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3a5257748e1so1348581f8f.2
 for ; Fri, 06 Jun 2025 02:00:15 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a53246b678sm1226372f8f.101.2025.06.06.02.00.13
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 06 Jun 2025 02:00:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a937c99d-42b4-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749200414; x=1749805214; 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=sIQeF0JzJfg6T+6jInSQ/eMC6mJ4jlezcTRlvUnaYeE=;
        b=gDolB50ZLylGJEIvXqVbwW8t+wUKxDnTYFoyqWieFYF01C2CUGrR7pChNA2ibhNHEG
         raYELR+4iLsQXUDYgrC+88nBfV+z2GjcU2h9pppAzJ5xI141pzn7EAYud4lOyBq1bj8N
         dmm7AkRj/jeuMuiKUFSe2mRoJYKQSxrvRGEO8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749200414; x=1749805214;
        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=sIQeF0JzJfg6T+6jInSQ/eMC6mJ4jlezcTRlvUnaYeE=;
        b=bo/R+7mlYCClfn+0tBUYE7T0HXnLQucQLO3HvE5lSU9tKbSIBJOIRs55d1C0XthjUs
         VNl1h/qdbiNR8rISVTiuiVhseZTyFNFOybGEQAOI/npAqLIA01PUnPZYXCUSo01xPm2m
         5rBhrR+/7MZGeeqnIM07TauzO3C3sOR1WPhJv/lf1qxrSUKN9ev3QAdjltzz84iSq+Xu
         XfrCP2fUTiO4AakyFRX6Yci8KvChH2hgTL+wmQGJj/NIlP9hjMs9Ph7RZKxK1kaJqBzO
         7JQTwHeer8RzaTNxl1rjuym6+kr54i8ggUMPK7Rf47lu1VW1tb5sEsM0pAQ9xz/VGdF9
         TQag==
X-Gm-Message-State: AOJu0YwPrbQcH4h9zbrO/LCZAuZosOuliIlZ1GPdmXdf5ZVkZktejK+J
	ovm+e42Bv5mV7cI948zqoH+k4ek0gmKfFu1Adt8t9bMxFLJpPG8dF7VlhcEx8cXt7iw=
X-Gm-Gg: ASbGnctrT41Qms+qbUFDuJ3ck/6Ku3yZwjR0OpVEmaJl2nl6Jqh/jpNNa5eXN8o3mIc
	ESKO6YaeXIgPdGQnFcjR1z2ilOs4nKjqXKXmNchg2fnQ5lMeg9FJWidm/8W8yqfxgd3Bqp/pfsc
	65Z+huKR1b6qyVatKVhL2TJiREZocSPxH+0lJc7dAdyRAZcoutpSFFy/5AKocn7DSF75QPzbCAO
	cSWb/FRuIz7Dpxxvqrz84DKI75ZQkfMkVsVNVUuYOz33Wdx++sOIcOO1CMvRsu0TKp+3uRCzQ6g
	j3CiPqVxqgsm5RFfqEzNjbypEIya0E3Mm5KzH6yzrdIdeRrfv/TsvShYD2LI31dPPs/Qg7WLh9k
	Ldn4h0zVoscxaD0aBYAYFV5gNe5TrhOHXMBE=
X-Google-Smtp-Source: AGHT+IEYUq22b8s6sFSJmvBfWMP1dqZvMXqz4eR7Ov8LwfMBpm/2Gbg4kAYHyB+SjZVx2Uin1H5GoQ==
X-Received: by 2002:a05:6000:2dc9:b0:3a3:6415:96c8 with SMTP id ffacd0b85a97d-3a5319a78fcmr1912174f8f.41.1749200414092;
        Fri, 06 Jun 2025 02:00:14 -0700 (PDT)
Date: Fri, 6 Jun 2025 11:00:09 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Alejandro Vallejo 
Cc: xen-devel@lists.xenproject.org,
	Bernhard Kaindl ,
	Nick Rosbrook ,
	George Dunlap ,
	Anthony PERARD ,
	Juergen Gross 
Subject: Re: [PATCH 10/11] tools/xl: Expose a "claim_on_node" setting in
 xl.cfg
Message-ID: 
References: <20250314172502.53498-1-alejandro.vallejo@cloud.com>
 <20250314172502.53498-11-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250314172502.53498-11-alejandro.vallejo@cloud.com>

On Fri, Mar 14, 2025 at 05:25:01PM +0000, Alejandro Vallejo wrote:
> Expose a setting to explicitly select a NUMA node for created domains
> 
> If the hypervisor can't reserve enough memory in the relevant NUMA node
> it fails the claim early. Also, disable automatic NUMA placement when
> this new option is enabled.

Overall it would be more helpful for users if soft-affinity was taken
into consideration when doing the claims, as that's the node where the
memory will ultimately be allocated?

Otherwise it's not very helpful IMO, as it's unlikely for the user to
know which NUMA the domain will get assigned to ahead of having
created it.

> Signed-off-by: Alejandro Vallejo 
> ---
>  tools/golang/xenlight/helpers.gen.go |  2 ++
>  tools/golang/xenlight/types.gen.go   |  1 +
>  tools/include/xenguest.h             |  7 +++++++
>  tools/libs/guest/xg_dom_core.c       |  1 +
>  tools/libs/guest/xg_dom_x86.c        | 18 +++++++++---------
>  tools/libs/light/libxl_dom.c         |  2 ++
>  tools/libs/light/libxl_types.idl     |  3 ++-
>  tools/xl/xl_parse.c                  | 11 +++++++++++
>  8 files changed, 35 insertions(+), 10 deletions(-)
> 
> diff --git a/tools/golang/xenlight/helpers.gen.go b/tools/golang/xenlight/helpers.gen.go
> index 90846ea8e882..9204020224d5 100644
> --- a/tools/golang/xenlight/helpers.gen.go
> +++ b/tools/golang/xenlight/helpers.gen.go
> @@ -1108,6 +1108,7 @@ x.LlcColors[i] = uint32(v)
>  if err := x.ClaimMode.fromC(&xc.claim_mode);err != nil {
>  return fmt.Errorf("converting field ClaimMode: %v", err)
>  }
> +x.ClaimOnNode = uint32(xc.claim_on_node)
>  x.EventChannels = uint32(xc.event_channels)
>  x.Kernel = C.GoString(xc.kernel)
>  x.Cmdline = C.GoString(xc.cmdline)
> @@ -1472,6 +1473,7 @@ cLlcColors[i] = C.uint32_t(v)
>  if err := x.ClaimMode.toC(&xc.claim_mode); err != nil {
>  return fmt.Errorf("converting field ClaimMode: %v", err)
>  }
> +xc.claim_on_node = C.uint32_t(x.ClaimOnNode)
>  xc.event_channels = C.uint32_t(x.EventChannels)
>  if x.Kernel != "" {
>  xc.kernel = C.CString(x.Kernel)}
> diff --git a/tools/golang/xenlight/types.gen.go b/tools/golang/xenlight/types.gen.go
> index e7667f1ce3a3..1c6319200411 100644
> --- a/tools/golang/xenlight/types.gen.go
> +++ b/tools/golang/xenlight/types.gen.go
> @@ -577,6 +577,7 @@ Irqs []uint32
>  Iomem []IomemRange
>  LlcColors []uint32
>  ClaimMode Defbool
> +ClaimOnNode uint32
>  EventChannels uint32
>  Kernel string
>  Cmdline string
> diff --git a/tools/include/xenguest.h b/tools/include/xenguest.h
> index e01f494b772a..08aae1e24e4c 100644
> --- a/tools/include/xenguest.h
> +++ b/tools/include/xenguest.h
> @@ -185,6 +185,13 @@ struct xc_dom_image {
>      uint32_t guest_domid;
>      int claim_enabled; /* 0 by default, 1 enables it */
>  
> +    /*
> +     * Exact NUMA node on which to allocate memory from.
> +     *
> +     * XC_NUMA_NO_NODE by default.
> +     */
> +    unsigned int claim_on_node;
> +
>      int xen_version;
>      xen_capabilities_info_t xen_caps;
>  
> diff --git a/tools/libs/guest/xg_dom_core.c b/tools/libs/guest/xg_dom_core.c
> index 595b0a667c03..152ec8ea6591 100644
> --- a/tools/libs/guest/xg_dom_core.c
> +++ b/tools/libs/guest/xg_dom_core.c
> @@ -775,6 +775,7 @@ struct xc_dom_image *xc_dom_allocate(xc_interface *xch,
>      dom->parms->p2m_base = UNSET_ADDR;
>  
>      dom->flags = SIF_VIRT_P2M_4TOOLS;
> +    dom->claim_on_node = XC_NUMA_NO_NODE;
>  
>      dom->alloc_malloc += sizeof(*dom);
>      return dom;
> diff --git a/tools/libs/guest/xg_dom_x86.c b/tools/libs/guest/xg_dom_x86.c
> index ac05106a8c1c..4fe816b9bcb4 100644
> --- a/tools/libs/guest/xg_dom_x86.c
> +++ b/tools/libs/guest/xg_dom_x86.c
> @@ -1199,7 +1199,7 @@ static int meminit_pv(struct xc_dom_image *dom)
>      if ( dom->claim_enabled )
>      {
>          rc = xc_domain_claim_pages(dom->xch, dom->guest_domid,
> -                                   XC_NUMA_NO_NODE,
> +                                   dom->claim_on_node,
>                                     dom->total_pages);
>          if ( rc )
>              return rc;
> @@ -1209,9 +1209,10 @@ static int meminit_pv(struct xc_dom_image *dom)
>       * that this is a valid state if libxl doesn't provide any
>       * vNUMA information.
>       *
> -     * The dummy values make libxc allocate all pages from
> -     * arbitrary physical nodes. This is the expected behaviour if
> -     * no vNUMA configuration is provided to libxc.
> +     * If there's an outstanding claim on a node, memory is allocated from that
> +     * node. Otherwise the dummy values make libxc allocate all pages from
> +     * arbitrary physical nodes. This is the expected behaviour if no vNUMA
> +     * configuration is provided to libxc and.

Stray 'and' or truncated sentence?

>       *
>       * Note that the following hunk is just for the convenience of
>       * allocation code. No defaulting happens in libxc.
> @@ -1227,7 +1228,7 @@ static int meminit_pv(struct xc_dom_image *dom)
>  
>          nr_vnodes = 1;
>          vnode_to_pnode = dummy_vnode_to_pnode;
> -        vnode_to_pnode[0] = XC_NUMA_NO_NODE;
> +        vnode_to_pnode[0] = dom->claim_on_node;
>      }
>      else
>      {
> @@ -1357,7 +1358,6 @@ static int meminit_hvm(struct xc_dom_image *dom)
>      unsigned long stat_normal_pages = 0, stat_2mb_pages = 0,
>          stat_1gb_pages = 0;
>      unsigned int memflags = 0;
> -    int claim_enabled = dom->claim_enabled;
>      uint64_t total_pages;
>      xen_vmemrange_t dummy_vmemrange[2];
>      unsigned int dummy_vnode_to_pnode[1];
> @@ -1397,7 +1397,7 @@ static int meminit_hvm(struct xc_dom_image *dom)
>              nr_vmemranges++;
>          }
>  
> -        dummy_vnode_to_pnode[0] = XC_NUMA_NO_NODE;
> +        dummy_vnode_to_pnode[0] = dom->claim_on_node;
>          nr_vnodes = 1;
>          vmemranges = dummy_vmemrange;
>          vnode_to_pnode = dummy_vnode_to_pnode;
> @@ -1443,8 +1443,8 @@ static int meminit_hvm(struct xc_dom_image *dom)
>       * actually allocates memory for the guest. Claiming after memory has been
>       * allocated is pointless.
>       */
> -    if ( claim_enabled ) {
> -        rc = xc_domain_claim_pages(xch, domid, XC_NUMA_NO_NODE,
> +    if ( dom->claim_enabled ) {
> +        rc = xc_domain_claim_pages(xch, domid, dom->claim_on_node,
>                                     target_pages - dom->vga_hole_size);
>          if ( rc != 0 )
>          {
> diff --git a/tools/libs/light/libxl_dom.c b/tools/libs/light/libxl_dom.c
> index 94fef374014e..1a5500702239 100644
> --- a/tools/libs/light/libxl_dom.c
> +++ b/tools/libs/light/libxl_dom.c
> @@ -663,6 +663,7 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
>      dom->xenstore_evtchn = state->store_port;
>      dom->xenstore_domid = state->store_domid;
>      dom->claim_enabled = libxl_defbool_val(info->claim_mode);
> +    dom->claim_on_node = info->claim_on_node;
>      dom->max_vcpus = info->max_vcpus;
>  
>      if (info->num_vnuma_nodes != 0) {
> @@ -1090,6 +1091,7 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
>      mem_size = (uint64_t)(info->max_memkb - info->video_memkb) << 10;
>      dom->target_pages = (uint64_t)(info->target_memkb - info->video_memkb) >> 2;
>      dom->claim_enabled = libxl_defbool_val(info->claim_mode);
> +    dom->claim_on_node = info->claim_on_node;
>      if (info->u.hvm.mmio_hole_memkb) {
>          uint64_t max_ram_below_4g = (1ULL << 32) -
>              (info->u.hvm.mmio_hole_memkb << 10);
> diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl
> index bd4b8721ff19..a252b36c2b5d 100644
> --- a/tools/libs/light/libxl_types.idl
> +++ b/tools/libs/light/libxl_types.idl
> @@ -617,7 +617,8 @@ libxl_domain_build_info = Struct("domain_build_info",[
>      ("irqs",             Array(uint32, "num_irqs")),
>      ("iomem",            Array(libxl_iomem_range, "num_iomem")),
>      ("llc_colors",       Array(uint32, "num_llc_colors")),
> -    ("claim_mode",	     libxl_defbool),
> +    ("claim_mode",       libxl_defbool),
> +    ("claim_on_node",    uint32),
>      ("event_channels",   uint32),
>      ("kernel",           string),
>      ("cmdline",          string),
> diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
> index 089a88935aff..5880a032e6d6 100644
> --- a/tools/xl/xl_parse.c
> +++ b/tools/xl/xl_parse.c
> @@ -1558,6 +1558,17 @@ void parse_config_data(const char *config_source,
>          exit(1);
>  
>      libxl_defbool_set(&b_info->claim_mode, claim_mode);
> +    e = xlu_cfg_get_bounded_long (config, "claim_on_node", 0,

You seem to introduce a new xl.cfg option, but there are no man page
changes as part of the patch?

> +                                  254, &l, 1);
> +    if (e == ESRCH) /* not specified */
> +        b_info->claim_on_node = ~0U;
> +    else if (!e) {
> +        libxl_defbool_set(&b_info->numa_placement, false);
> +        libxl_defbool_set(&b_info->claim_mode, true);
> +        b_info->claim_on_node = l;
> +    }

This setting of defaults should better be done in
libxl__domain_build_info_setdefault() IMO.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 09:02:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 09:02:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008237.1387480 (Exim 4.92)
	(envelope-from )
	id 1uNSxp-0003i8-4o; Fri, 06 Jun 2025 09:02:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008237.1387480; Fri, 06 Jun 2025 09:02: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 1uNSxp-0003i1-1a; Fri, 06 Jun 2025 09:02:13 +0000
Received: by outflank-mailman (input) for mailman id 1008237;
 Fri, 06 Jun 2025 09:02: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 1uNSxn-0003hr-49
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 09:02:11 +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 ed5338f2-42b4-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 11:02:09 +0200 (CEST)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-450cf0025c0so12438035e9.3
 for ; Fri, 06 Jun 2025 02:02:09 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-451f8fb57b1sm26298255e9.1.2025.06.06.02.02.08
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 06 Jun 2025 02:02:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ed5338f2-42b4-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749200529; x=1749805329; 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=H1fq8LjeXC0AbfZfiFKAbz1qtQjwey0NB6K9CmJxqWU=;
        b=o13mpexGzmu5kk3zrhwU9jE0nvElXGQsrZaBBl8zBKj9Vcn3bgb9cxkjYbFgaXbIio
         lkONwQyL4Z/468zFr0CyFvMRrA0uHCGotupGj5BkMRD7HXcBBtXixtJ8vfOzsFCvx8ae
         tLzcWDOskGDqXh7U23rBwWGeOQ0uYRox2PUrM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749200529; x=1749805329;
        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=H1fq8LjeXC0AbfZfiFKAbz1qtQjwey0NB6K9CmJxqWU=;
        b=XEk0kplEfHRlJgRveDuXUbzZdXwGhoOh8ymqeI1g+e1aKHtJiqJCm9COuho36GsUqA
         Qag43MRYwk1nyqCjnBvBg7GXtt4v+tiHdDmzYQxwWGCXCvLJInQOjGqW/Z1ciOmwTPfo
         W7P5V0HdnAqd61NZjuMrYiwFbFUeYpU5HleENhYE/3GW7n4WFZGS5du3xOFYD17LCM5X
         ylhGSgleQm4L8g1TNfGm+miLsw7uL6JlRr6fxeo0NoWlCA5LoXiN5KyLii37mfFzBxrK
         1B24/ENRhaBsMYnKUpgtLftP2hPHPU+q3eyNGTbqdl4at3kksndopPhBYtf037Fi5W00
         xf/w==
X-Gm-Message-State: AOJu0Yx6ZRV5Un+OorlV7suc7mAGEoBxWurSvGLwbg5WOmW30nYj+80f
	SDCfXQjqYs5HAugnq7/EVBMjT3oVCBiBCbddIru8CN050IDnyMepARVIJZuN9DJlTY0=
X-Gm-Gg: ASbGncvaZwuwtujgbXxBu67Nz1u5tgYpCIp/MUsQdLW2Qti2eZ/yyYyKS6sgY1ZBdu4
	9q1XS8gFB7kAJAltSEVXtLBjouzvvRxNlfZHhG9vi9yArAX0RGZxIIlxszRuhmiUXwkENXeuRGS
	OaivvNIRhgT58khi1csXKB3VcR16zPK1sH/Xlbi1gZGBAUXH5A9zylT2YavRZTThVfjMoL7XEHR
	dVScDlnLVypq4BifiHqdUHeFWMgMRpwBDBGSPHuSwUC8CVlfYA2AbbWOZ9pb7B8hJbbDPVwTDuh
	avvuM9qor1lVsAEElA/Ajl0h24tSSZ1GouoLk3xpFGVxKuJplx9SCzrpJF9fhdAhihqBiLsIcmf
	kYvUsRQ4jiXTq1jrTI/XHV0y7
X-Google-Smtp-Source: AGHT+IEr0hSgJEC5/sNM6RD1PQ8oDaQhE8v9Eg60kOE0aLNHqVNuD7eTGb0tn+QQD86YQgVfsi/oaw==
X-Received: by 2002:a05:600c:1da8:b0:43a:b0ac:b10c with SMTP id 5b1f17b1804b1-452fcaf0aa4mr2264275e9.26.1749200528668;
        Fri, 06 Jun 2025 02:02:08 -0700 (PDT)
Date: Fri, 6 Jun 2025 11:02:07 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Alejandro Vallejo 
Cc: xen-devel@lists.xenproject.org,
	Bernhard Kaindl ,
	Anthony PERARD ,
	Juergen Gross 
Subject: Re: [PATCH 09/11] tools/xc: Add `node` argument to
 xc_domain_claim_pages()
Message-ID: 
References: <20250314172502.53498-1-alejandro.vallejo@cloud.com>
 <20250314172502.53498-10-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250314172502.53498-10-alejandro.vallejo@cloud.com>

On Fri, Mar 14, 2025 at 05:25:00PM +0000, Alejandro Vallejo wrote:
> Add a node argument to make an exact-node claim. NUMA_NO_NODE means to
> make a regular any-node claim.
> 
> No functional change.
> 
> Signed-off-by: Alejandro Vallejo 
> ---
>  tools/include/xenctrl.h       |  1 +
>  tools/libs/ctrl/xc_domain.c   | 13 ++++++++++++-
>  tools/libs/guest/xg_dom_x86.c |  8 +++++---
>  3 files changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
> index 495598123133..2b63992e1246 100644
> --- a/tools/include/xenctrl.h
> +++ b/tools/include/xenctrl.h
> @@ -1322,6 +1322,7 @@ int xc_domain_populate_physmap_exact(xc_interface *xch,
>  
>  int xc_domain_claim_pages(xc_interface *xch,
>                                 uint32_t domid,
> +                               unsigned int node,
>                                 unsigned long nr_pages);
>  
>  int xc_domain_memory_exchange_pages(xc_interface *xch,
> diff --git a/tools/libs/ctrl/xc_domain.c b/tools/libs/ctrl/xc_domain.c
> index 2ddc3f4f426d..f2c6eda875dc 100644
> --- a/tools/libs/ctrl/xc_domain.c
> +++ b/tools/libs/ctrl/xc_domain.c
> @@ -20,6 +20,7 @@
>   */
>  
>  #include "xc_private.h"
> +#include "xenguest.h"
>  #include 
>  #include 
>  
> @@ -1072,13 +1073,23 @@ int xc_domain_remove_from_physmap(xc_interface *xch,
>  
>  int xc_domain_claim_pages(xc_interface *xch,
>                                 uint32_t domid,
> +                               unsigned int node,
>                                 unsigned long nr_pages)
>  {
>      int err;
> +    unsigned int mem_flags = 0;
> +
> +    if ( node != XC_NUMA_NO_NODE )
> +    {
> +        if ( node >= 0xFF )

You should have XENMEMF_node_mask available here which is better than
open-coding 0xff.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 09:04:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 09:04:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008243.1387489 (Exim 4.92)
	(envelope-from )
	id 1uNSzd-0004FP-Ev; Fri, 06 Jun 2025 09:04:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008243.1387489; Fri, 06 Jun 2025 09:04: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 1uNSzd-0004FI-Bb; Fri, 06 Jun 2025 09:04:05 +0000
Received: by outflank-mailman (input) for mailman id 1008243;
 Fri, 06 Jun 2025 09:04: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 1uNSzb-0004FC-Bg
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 09:04:03 +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 3031a8d9-42b5-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 11:04:01 +0200 (CEST)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-451d3f72391so24328365e9.3
 for ; Fri, 06 Jun 2025 02:04:01 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-451f8ef98b1sm37805535e9.1.2025.06.06.02.04.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 06 Jun 2025 02:04:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3031a8d9-42b5-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749200641; x=1749805441; 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=N/pwpR1wZgNyQUp3b4XDKg0uOmmDvQmw5MfQwI5UI6w=;
        b=BNVUpm2ZHT/LfkpH5TIqMd8DoYP3G8MzPfTOsM4GMg8HqDqbCUGIetgMzYo6KznxFj
         QXHErPQ/hItJsjS3Xvpf/UsrzHNk6JFnv4EJgK36fWIaF93PkstEEABg1ZN1JBHQXpA9
         pyHSMpy4yDdLeWc73PBquUzguZ1Fk35loEO3Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749200641; x=1749805441;
        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=N/pwpR1wZgNyQUp3b4XDKg0uOmmDvQmw5MfQwI5UI6w=;
        b=wRe2wfVvc1/tMuuEq3OCTFj65s9gzQeEfC0ksExXW9ZlF6mriFz1ONS5xmvMEvkHch
         udIXASN/zl0Bv/UzIlEpxJyHHwuRBxvVAqLIrYhb6nw92ROZsF8Pz5IfNUEROYkwHEnV
         h35QRkvc/TbKfLWPV0EYbmodGCzZa1vd3Yu4DrqKqXh4ctpYsOg55DHQP7F4caqEwfdY
         57IAFBYlv3T48V8jRbNG8oxmzBb6x2qyBulFs9NW/bSeLRWSwdNHAm0/6+gxV/94RJFE
         dxsWdbdjlCfWuIWhcpEYMKsjr6qQNImnw6fIIUNyDcuAYq/NvqNDvlZISwCsd2y8DUUb
         rtTA==
X-Gm-Message-State: AOJu0Yziq8xPlbk3SSES6bNzfa7JumLNF4Y1VjKMtMpF40Xb0GwqKq/5
	i+jVtJNkMduZgI07qfBHCdVjUp/pWdeyzUYRqrixZpy+EQIils/O9bMva3sISp2cBIa1SyZlrBx
	Qt4pv
X-Gm-Gg: ASbGncteeyzP6hrWWKaj9Cgg8NnuLCexaubcxnu51fzfQfq2tYNeR+BA4G1Rnx3Aqab
	QA4vFfNzSmCeMq6rzoDSP1ckmdaUG3PgVuUYztbwzTP9VVTxPLgaW+BQYQRP9Gw/9LIpVQLsdX1
	g2DXwU+bx8Go1ZP5BMSSs1Dtn7Ivdi0fto1RXsFd2fGrF6le9qC02wpTptajQZp/s/ylZz23Mbo
	JnNAdmKM3O1zNn7We/YgemvIDWF/qsIKkQdDLXRhA/y+t9ICKCQtw9cmV7j5uxqt/eez0z5dHYN
	IEbf+5MgEVh7O41aRuFtno/M3aYBrrriyC1LQFUMWWyzlBTBO4teFy8jTIrFUaaDxA9VIpKJG1q
	gHdEOkY153k3jlAWyD2q68Mww
X-Google-Smtp-Source: AGHT+IHO1kexPx1BpsdJMljr2CT3uDUXPGYUvzf9DtILXnxJ7eMTaYD+4i2d8XMtHzA3HrK9imTi7Q==
X-Received: by 2002:a05:600c:c178:b0:442:dcdc:41c8 with SMTP id 5b1f17b1804b1-4520147f531mr22898695e9.19.1749200640906;
        Fri, 06 Jun 2025 02:04:00 -0700 (PDT)
Date: Fri, 6 Jun 2025 11:03:59 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Alejandro Vallejo 
Cc: xen-devel@lists.xenproject.org,
	Bernhard Kaindl ,
	Anthony PERARD 
Subject: Re: [PATCH 11/11] docs/man: Document the new claim_on_node option
Message-ID: 
References: <20250314172502.53498-1-alejandro.vallejo@cloud.com>
 <20250314172502.53498-12-alejandro.vallejo@cloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250314172502.53498-12-alejandro.vallejo@cloud.com>

On Fri, Mar 14, 2025 at 05:25:02PM +0000, Alejandro Vallejo wrote:
> ... and while at it, add missing relevant links to xl-numa-placement(7)
> in xl.1.pod.in and xl.cfg.5.pod.in, which describes libxl's behaviour on
> NUMA placement.

Oh, here it is.  This should be part of the previous patch.

I still have my concerns of the option being generally helpful, as
said in the previous patch it would be better if this new per-node
claim mode was somehow tied with the soft-affinity placement by
default.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 09:11:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 09:11:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008248.1387499 (Exim 4.92)
	(envelope-from )
	id 1uNT6v-0006HC-4W; Fri, 06 Jun 2025 09:11:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008248.1387499; Fri, 06 Jun 2025 09:11: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 1uNT6v-0006H5-1Q; Fri, 06 Jun 2025 09:11:37 +0000
Received: by outflank-mailman (input) for mailman id 1008248;
 Fri, 06 Jun 2025 09:11: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 1uNT6t-0006Gz-RQ
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 09:11:35 +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 3dd78683-42b6-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 11:11:33 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a375888297so1206346f8f.1
 for ; Fri, 06 Jun 2025 02:11:33 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-236032fccf1sm8377235ad.97.2025.06.06.02.11.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 06 Jun 2025 02:11:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3dd78683-42b6-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749201093; x=1749805893; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=yuXnGITwwjCcJzqb+2/9XK9tqWFcCA2oZSa8lNn6TgI=;
        b=AE2TZLYS22f2GODLqMl4meD+HdTt3z3IuewDCTLxFEq0xHCTujkWEfOL3xwJPj9Cut
         0+ljfI0f4aZc03a74CnbIdNf4GUC9j98AIU5S5SgP7M3cNuwVOm9pnpt1cH8PWx2ZNcM
         j2nJZXikjvjqlRiNpvBX3Wn3d3SvkxscSpRO3du4SjWwrr0hqCcZiYtQkgV97bVY8lZ3
         YJP4TzA3bCuGCoLVcIVh6kOC0vCcknRX1OcQSlP9m3wZ4FLMzmJapiTITvsXYLXgRfGW
         ab1bbsu8S5pSrywu5gf0mDYFY2wJfxNjyp7N/VfSrsfOy0KyQPTtDG5dLBE5z6/rPH33
         PjnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749201093; x=1749805893;
        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=yuXnGITwwjCcJzqb+2/9XK9tqWFcCA2oZSa8lNn6TgI=;
        b=cSDfZmNJYrhvuqzFu1vjnMQoeFwbxQ8vq7dn2D6YVrs2FeBqAcJKeuq3pm/Mjn4m4R
         i7Q2noJLWICZylTpWmTrZFoYZ/LU80ZcHvLemZWPGlqeShtmccOMpy1WxfSJ0redOPkI
         JnejpK4yP+FXW+emHCwWvSBoGgTm/czVdETBQUsWuMl4sb5S8MP4vO2RLI/gfUt/wwEq
         lWnEPOsrGo43TDFI7WlULtM98Q8ZrVaFrigDLP1xedmSgYkzCCZU5VNE0LD13AyOFdWy
         qbqBANE5bBLUatct8EpG92S9mkvp8o2Vx635hDqnIUDE9lscPusaDG6R7ddNOZJFiVA+
         9wmw==
X-Forwarded-Encrypted: i=1; AJvYcCXsB9+cNiW1sjln9aDAURE59UIAFXIdZEUHX+RUROTZNH4Tuc2XnFApiiQHhlFZtfpldQlQb7kmeaY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxr5JFviZs7LSQYyXRlqD+Ex98HsWA7+LN1i9PoKQAyQ7c5hVLa
	1kAcE9eTjL52iYdOx8If6w4y/jhzvf7A2D5QcT9KIW0oOiPC4pNgkHlBvWbbULVM6w==
X-Gm-Gg: ASbGncv8l1v6tMbuCv0pzfPTFvsSYUgEcZeGR3pY9DSXsZS9YL4P4pv5X/JIpu/OSWw
	xFqDuBkxamKzB2enYWws5Wq18HoSxiQxaqIs3/RcWBs87lnn4/DSiZYEkNm4XOnoXX8fPHhGL4B
	NEI4j06E58C3/7pKG7IlcjOsyChnSt7h8coMOGP1jFQ2VauONR6xub23CQtddVJvlAGYeabuJjb
	Trv9DXjLu0a+lKRwSpr54L1CyDTyjxvKRfBC/QZl3OhCzxkY/Qk7epr8Gg4CklHzvm7KowzRamc
	P9T6fr8C7Y0XbuyFpda4bnbMOdvRQRdL4b+IcA5FnhxKSYR9N+d70mOOBZQAzJl8DCdEhosTNR8
	RPDmxgondn4+zubBuyj6RtV66Lx+In7uY7ulH
X-Google-Smtp-Source: AGHT+IHEYRJuQ0UxSTYS4yRDrMVFzajdesySE7JCtJMSmSPwoajs1ZIK6azSJVrOYGh03XhnqZYF+w==
X-Received: by 2002:a5d:5f51:0:b0:3a4:e61e:dc93 with SMTP id ffacd0b85a97d-3a526dc53e9mr6798091f8f.1.1749201093237;
        Fri, 06 Jun 2025 02:11:33 -0700 (PDT)
Message-ID: 
Date: Fri, 6 Jun 2025 11:11:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 2/6] x86: re-work memset()
To: Teddy Astie 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <73481cbf-337f-4e85-81d2-3487366cd822@suse.com>
 <4592a702-acf3-4229-9069-d5b639151657@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 05.06.2025 18:59, Teddy Astie wrote:
> Le 05/06/2025 à 12:26, Jan Beulich a écrit :
>> --- a/xen/arch/x86/alternative.c
>> +++ b/xen/arch/x86/alternative.c
>> @@ -346,6 +346,12 @@ static int init_or_livepatch _apply_alte
>>           /* 0xe8/0xe9 are relative branches; fix the offset. */
>>           if ( a->repl_len >= 5 && (*buf & 0xfe) == 0xe8 )
>>               *(int32_t *)(buf + 1) += repl - orig;
>> +        else if ( IS_ENABLED(CONFIG_RETURN_THUNK) &&
>> +                  a->repl_len > 5 && buf[a->repl_len - 5] == 0xe9 &&
>> +                  ((long)repl + a->repl_len +
>> +                   *(int32_t *)(buf + a->repl_len - 4) ==
>> +                   (long)__x86_return_thunk) )
>> +            *(int32_t *)(buf + a->repl_len - 4) += repl - orig;
> 
> That looks a bit confusing, to me that probably some comment explaining 
> what instructions transform it's looking to make.

It's still the same comment ahead of the if() that applies here. This will all
become easier with Andrew's decode-light, at which point we'll be able to spot
CALL/JMP anywhere  in a blob.

>> --- /dev/null
>> +++ b/xen/arch/x86/memset.S
>> @@ -0,0 +1,30 @@
>> +#include 
>> +
> 
> It would be nice to have a reminder of the calling convention (i.e what 
> register maps to what memset parameter) as it will definitely help 
> future readers.
> 
> If I understand correctly here :
> - rdi: destination (s)
> - rsi: byte to write (c)
> - rdx: number of bytes to write (n)

I don't think the (default) ABI needs re-stating for every function in every
assembly file.

>> +.macro memset
>> +        and     $7, %edx
>> +        shr     $3, %rcx
>> +        movzbl  %sil, %esi
>> +        mov     $0x0101010101010101, %rax
>> +        imul    %rsi, %rax
>> +        mov     %rdi, %r8
>> +        rep stosq
>> +        or      %edx, %ecx
>> +        jz      0f
>> +        rep stosb
>> +0:
>> +        mov     %r8, %rax
>> +        RET
>> +.endm
>> +
>> +.macro memset_erms
>> +        mov     %esi, %eax
>> +        mov     %rdi, %r8
>> +        rep stosb
>> +        mov     %r8, %rax
>> +        RET
>> +.endm
>> +
> 
> Overall, I am a bit confused on the mixing of 32-bits (edx, esi, ...) 
> and 64-bits registers (rax, ...). But it looks ok to me.

Since 64-bit forms require REX, 32-bit ones are used wherever that's sufficient
for the purpose.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 09:13:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 09:13:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008254.1387510 (Exim 4.92)
	(envelope-from )
	id 1uNT8R-0006mF-EV; Fri, 06 Jun 2025 09:13:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008254.1387510; Fri, 06 Jun 2025 09: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 1uNT8R-0006m8-Bd; Fri, 06 Jun 2025 09:13:11 +0000
Received: by outflank-mailman (input) for mailman id 1008254;
 Fri, 06 Jun 2025 09:13: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 1uNT8Q-0006m0-De
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 09:13:10 +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 763f35f3-42b6-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 11:13:08 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3a4f71831abso1782399f8f.3
 for ; Fri, 06 Jun 2025 02:13:08 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-31349fc3e72sm930172a91.31.2025.06.06.02.13.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 06 Jun 2025 02:13:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 763f35f3-42b6-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749201188; x=1749805988; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=3jUHxb0lKIug35Ut90AkAc+cVTWHgCRZEKL2C55fXF4=;
        b=gcK3awgTmNpaaT47jdUkU/JzOIzeaoET1KkaLk6cAXG00JttQ1Vu6ekSHZtejDCvkj
         jsPN0nhZfRGOWIE3o2mebgZdCzRGfxb4DDKLVClnFpybRt24bN5hCBJD2w47IsrVISpc
         GrUjlrqBz/j/RfpXj3n+gEyDOT6jcMfdsX8QTaegO7RT7yDHElI08jh9sTv8+/27ruSS
         dC9sZmSn624sR/Dw4xCMzm1YA9Hg+682GRCXr0ldLkgre9iZa0KprosSOlpycN2X3MYG
         J12D6o/1Y8eJRGu5Jq4Owb2YHgrBgH6rIh/ej5SHT1/y1OU1SmVM4YSUVGwdRQqB9FGV
         T+Ow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749201188; x=1749805988;
        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=3jUHxb0lKIug35Ut90AkAc+cVTWHgCRZEKL2C55fXF4=;
        b=Sj1l4tG5J7ZWz615xCjljAZvmMH/pj93oR6p5/8ybE3WM8nrO8jV7Bux19w4Vt7Bc5
         r9CfJlU3xykMS6vUgg/1j4KGLZhPUDDXU83ldRUXM45km/N4kvflNpGdY2G80E1cDcRU
         TAEaBjok+Y4NT6vgzyggiAYcEmu3Y0ENyuPQbp4j+loAvdKBe+jkLfcWcnNcFlSUbKO+
         +Fc64XUNu0AL/vXMvLII6vqbUIu0Y1aDOJWkSwvxNQJ5TJq2mWWl3qygpxBskRgqrY/H
         0eWjr9HXlLYrlsbX8PYMlzCx2SILluOAqEH0eoNVQElnJ3t7wxdeArKOPNDYJYvMtXM+
         9/KQ==
X-Forwarded-Encrypted: i=1; AJvYcCV/RXG5MToIqmM2JutQEy6ZRoCc6Yiaj1TSJuhRNQGRZFbf+MAxqZ44Ov05Y66+uLNnpAL3lnkgGjY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwHeEW+RBPDXeurmveNkCELbkWqHyDtQBP28H7xpiPPSsbXBnSS
	hDiKj+28tjp50FoT53niJl8T1Zqu1GglsNpSiSzpRdgOO9DE0XUXfDb0JF+0Wxa1Hg==
X-Gm-Gg: ASbGnctGrs6JtkFypI92LTksH0FmINhZXiehcB0nzV8V97J2rsbAEsZotkwi0aSRVra
	qJSMeLwFokPaMSMqZlgvh8v7tBkcXjAj5Cd+CEQL6R0OybbzbBvcLxq5Wu01EuaR5dXjLZVJnu4
	9kIB7hB1RSNTqlqh2I7OlBJM+0noABE5gPB7yM8mGi0WIhrPEFw1GOwem/bT7c0QNr+pc7g+USC
	2LXqbPBD/09ey0MsLMJ+DRnPxlXUZB8vk95g1e6geVA4cjcVLcYGnll2mvIpagoktG9jAtstYgV
	k+J3jTy2ac1uEZKIXN7prc0eWpX5ZuIXti3FlESyeGaDSw71KhJTbATlauyh4erSo1aGaeu2hnQ
	R/jqrdPdJ//mJ6yhDoZjDFNaB2RJtn6fm1NeC
X-Google-Smtp-Source: AGHT+IGvuoYMyYUnQ8n/LQEDFxFJOc7hyvFm6gr4Msic7md6lRnyuq70UnCa3taYl6fcies92JWHfg==
X-Received: by 2002:a05:6000:2307:b0:3a4:f519:ed3 with SMTP id ffacd0b85a97d-3a531abc793mr2235363f8f.44.1749201187963;
        Fri, 06 Jun 2025 02:13:07 -0700 (PDT)
Message-ID: 
Date: Fri, 6 Jun 2025 11:13:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 3/6] x86: re-work memcpy()
To: Teddy Astie 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <73481cbf-337f-4e85-81d2-3487366cd822@suse.com>
 <017e689a-41a2-4722-a5e7-19ffef27500f@suse.com>
 <81da4e8e-9dcf-4630-a535-39ce0b07260c@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: <81da4e8e-9dcf-4630-a535-39ce0b07260c@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 05.06.2025 19:06, Teddy Astie wrote:
> Le 05/06/2025 à 12:27, Jan Beulich a écrit :
>> Move the function to its own assembly file. Having it in C just for the
>> entire body to be an asm() isn't really helpful. Then have two flavors:
>> A "basic" version using qword steps for the bulk of the operation, and an
>> ERMS version for modern hardware, to be substituted in via alternatives
>> patching.
>>
>> Alternatives patching, however, requires an extra precaution: It uses
>> memcpy() itself, and hence the function may patch itself. Luckily the
>> patched-in code only replaces the prolog of the original function. Make
>> sure this remains this way.
> 
> We can probably workaround that by using a separate memcpy for 
> alternatives patching. So it wouldn't end up patching itself.

We could, yes, but imo we better wouldn't.

> Aside that:
> Reviewed-by: Teddy Astie 

Please clarify whether this applies without that suggestion of yours taken
care of.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 09:14:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 09:14:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008259.1387520 (Exim 4.92)
	(envelope-from )
	id 1uNT9M-0007Fl-NP; Fri, 06 Jun 2025 09:14:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008259.1387520; Fri, 06 Jun 2025 09:14: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 1uNT9M-0007Fe-Kd; Fri, 06 Jun 2025 09:14:08 +0000
Received: by outflank-mailman (input) for mailman id 1008259;
 Fri, 06 Jun 2025 09:14: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 1uNT9L-0007FW-Pm
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 09:14:07 +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 9616ecc1-42b6-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 11:14:02 +0200 (CEST)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-43edecbfb94so21510895e9.1
 for ; Fri, 06 Jun 2025 02:14:02 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a53229d9adsm1278618f8f.9.2025.06.06.02.14.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 06 Jun 2025 02:14:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9616ecc1-42b6-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749201241; x=1749806041; 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=+kRDJw2A6HRmYkmknLlDaEb2F350dVP5YmdjLdI5kB8=;
        b=RCJuoUtwN7oajH0B2Sp0qWkn4sxOHANq6aO8WlH3tXOnHiQXf7uKMMALSEEDqdj6lf
         E9OV6DO6sy1zwStXKwfb543l0cTIwn6lguWF5SfGDxVIh2VvSEmyrCnzpx8QGdEz3VSf
         GqS8QwBI8j06pD0UpF571ENVoLBUGJyMbqAsQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749201241; x=1749806041;
        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=+kRDJw2A6HRmYkmknLlDaEb2F350dVP5YmdjLdI5kB8=;
        b=NiFmizmNILyKh+5NbNYQ3X0MEF4sMqkYCvucfYVdZOKHI5rmBaXLUFiwtv9hGnsAps
         8LGVWxq8DTuJ7F0ValkuzUmNiYiAm1K2sNBrBwUPryrbkkmK9RUoieNXoHLfBIoJF9fY
         Ru7hEEZUYmALRoO8uFi4WaWE8bRwFtb7f5iGbFjOWn1vocwhrAb40FW3ZxSCZ9mshkoo
         TtZXec7s+FkSOM2nx2yGDW9UGLBKdZucY2d/R5iJsAMluB+Xfix8ELKqPRljmskYQq18
         5XswexffGFF8qllDTQBt9Ya26H2qfbTHz9+3SDooyvzz9KGdlHMv2Hf8nVGIXGY8B2ii
         4cVQ==
X-Forwarded-Encrypted: i=1; AJvYcCU4Zzx8lYa2Y/09HpSPPqn9yavNI2zy494jaT/sLt/RTJpaQJmBFsg14oT/cCAxQuFBl+J3UW1K4no=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzG7Dt21ls7nd+WC1dNR7fqWlhlxDn6IZBRy63nCKvgbi7aLVUO
	d9IP4Jqfl5V8tjH1oCScw7bvHRh+LatQeu1EAQJbhcQ/g3ra+D6gJynr7n/2UE2jnuI=
X-Gm-Gg: ASbGncsAhNYmlMMQtd5HEP8IqKk2rcK3S9ZxdiXYfIQXwK8+r/UJOUJJWetBvzF0QML
	kjnPXNtS7E4Wyh9uoGm40BhpiIV2dD8w0oJ8V8mbcj3FqMRc5ckGbIqlu0yyD54Azuhee+ziCoc
	Yt9qjwYLBV8UwnrOTeKE0KQi9LSUjd7SKRyN4uRoZNjlDCzxAJKKELlGU87tbnzCsfsVZgaFFl9
	3wJr+nmxiVNF79GhzFLaZl0Lmi7Ezkww7hAHbRACieozVdhblLAzzY/ACdWr91aUfpSMHtPunUz
	PUebiatAilCrBxrQdddNoUK+wdMxVdch4C2fjL/Yh+hvswMQJMJXF4mA/CWmxkaUFfCtwDVCWGP
	UTj7in1Uf7AA0bym5Hd4p+znWwGpMSw==
X-Google-Smtp-Source: AGHT+IEcl6uxqmbauJ9/VpdWI0a4BkY1cBa7klEKA+fULonAOoPCL1Z3WH1WJxAv4gEhY1b3MAbFLQ==
X-Received: by 2002:a05:6000:290c:b0:3a5:27ba:47c7 with SMTP id ffacd0b85a97d-3a531cea375mr1994138f8f.48.1749201241284;
        Fri, 06 Jun 2025 02:14:01 -0700 (PDT)
Date: Fri, 6 Jun 2025 11:14:00 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: "Chen, Jiqian" ,
	"xen-devel@lists.xenproject.org" ,
	"Huang, Ray" ,
	Andrew Cooper ,
	Anthony PERARD ,
	"Orzel, Michal" ,
	Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v5 04/10] vpci: Refactor REGISTER_VPCI_INIT
Message-ID: 
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
 <20250526094559.140423-5-Jiqian.Chen@amd.com>
 
 
 <752cff02-cef6-4a4c-80b9-eba3bbf9b264@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <752cff02-cef6-4a4c-80b9-eba3bbf9b264@suse.com>

On Fri, Jun 06, 2025 at 09:05:48AM +0200, Jan Beulich wrote:
> On 06.06.2025 08:29, Chen, Jiqian wrote:
> > On 2025/6/5 20:50, Roger Pau Monné wrote:
> >> On Mon, May 26, 2025 at 05:45:53PM +0800, Jiqian Chen wrote: 
> >>> +  }; \
> >>> +  static vpci_capability_t *const finit##_entry  \
> >>> +               __used_section(".data.vpci") = &finit##_t
> >>
> >> IMO this should better use .rodata instead of .data. 
> > Is below change correct?
> > 
> > +    static const vpci_capability_t *const finit##_entry  \
> > +        __used_section(".rodata") = &finit##_t
> 
> No, specifically because ...
> 
> >> Not that it matters much in practice, as we place it in .rodata anyway.  Note
> >> however you will have to move the placement of the VPCI_ARRAY in the
> >> linker script ahead of *(.rodata.*), otherwise that section match will
> >> consume the vPCI data.
> > I am sorry, how to move it ahead of *(.rodata.*) ?
> > Is below change correct?
> > 
> > diff --git a/xen/include/xen/xen.lds.h b/xen/include/xen/xen.lds.h
> > index 793d0e11450c..3817642135aa 100644
> > --- a/xen/include/xen/xen.lds.h
> > +++ b/xen/include/xen/xen.lds.h
> > @@ -188,7 +188,7 @@
> >  #define VPCI_ARRAY               \
> >         . = ALIGN(POINTER_ALIGN); \
> >         __start_vpci_array = .;   \
> > -       *(SORT(.data.vpci.*))     \
> > +       *(.rodata)             \
> 
> ... this isn't - you'd move _all_ of .rodata into here, which definitely
> isn't what you want. What I understand Roger meant was a .rodata-like
> section, e.g. .rodata.vpci.* (much like it was .data.vpci.* before).

Indeed, my suggestion was merely to use .rodata instead of .data, as
that's more accurate IMO.  I think it should be *(.rodata.vpci) (and
same section change for the __used_section() attribute.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 09:17:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 09:17:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008273.1387531 (Exim 4.92)
	(envelope-from )
	id 1uNTC8-0007vW-Bb; Fri, 06 Jun 2025 09:17:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008273.1387531; Fri, 06 Jun 2025 09:17: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 1uNTC8-0007vP-6R; Fri, 06 Jun 2025 09:17:00 +0000
Received: by outflank-mailman (input) for mailman id 1008273;
 Fri, 06 Jun 2025 09:16: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 1uNTC7-0007vJ-4Z
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 09:16:59 +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 ff443834-42b6-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 11:16:58 +0200 (CEST)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-452f9735424so991725e9.3
 for ; Fri, 06 Jun 2025 02:16:58 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a5324360fasm1298816f8f.56.2025.06.06.02.16.57
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 06 Jun 2025 02:16:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ff443834-42b6-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749201418; x=1749806218; 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=ZZiVLXY+uRhcDUBodbSeE9pVkYvBo/5taz01lkfc+YM=;
        b=JayzBE0iS1evRTDQlW3qTVkNANF9vHb/YGffG23SzYHXlPk6wiV9nMnUW3lBMdymGc
         LradeDMuMzSmMahiWNKh9FuqXSYa5bszDZ2npRGYVVlfgFZNmU1ZnypITR0JeNGRN0cC
         CwgOgiY099wBzKP3VkRb72oX50GwIVdMnj66Q=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749201418; x=1749806218;
        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=ZZiVLXY+uRhcDUBodbSeE9pVkYvBo/5taz01lkfc+YM=;
        b=eaegfcnSJOHgjbcQVJLvEiAmdqz8gN7doNRg0C2HpmzUNSxl2tvvscrxZVgKPY/R6b
         6tK6JuCm6Gs9AWR2lMOTbUr1KfqNio75gPxPSOnRcj1FaxDdl66agTw7uN388wzuX84P
         S8XByHXhy00EQ9Wdjptr/oHhgtsGKtbTD5a5mTqNNcKEWTlUfY3C6/nScqiloLavq59j
         VJ7QIGGrgbP+mRNEKatsvZEUZEsrejAaKNT1uf90S9upIwQcignPlLI10bMJixAVbiHk
         LjQUC2VBAOS+765RvbM+hppmXefQnEXSTHruzN2/4/dLlxyDUO5uR8NhtskAwX9m9hPe
         Um/g==
X-Gm-Message-State: AOJu0YwnLgE+rbhdv/QkHrsAkwhwuRLw4P1ta5MBal7WxV75NRBvyyCH
	rHdk8FbXPOSPaUqWVwlxtWtCjnW3fHcbgp80QJmEN2JhRuDpO1VMjnEI6mQgffXaX+U=
X-Gm-Gg: ASbGncuWVKCpBszB6KwFu93xbWyMoJtRFIeNu2Xj0TqQNv4eVf1LBPSW9rGyHrrhPRB
	sWgArL0CXp2hha2Td045tPtOypjavVJ/wG1MMW6cUDHlqdXBminwVjxolNyT1r8TIVlWmRlCUEO
	U4N0QSVxCHD5K6fQ1sY4YkLCZ7BN+DYNRcr9YQQGIXfFFjEWctH3tV/aEIzWsZ+wI7UDTfkKlqk
	Pp8ir7i7nKPhF26plssJlLHl7iz5gsVS2iqIIZMBYVqmm6mR19PMccy4trH2erTlu6dwraX86Vr
	DI81KojwU2s6Yo299gv6GRItzQlEeBnrM1PVsVna9YRu54jjkrA/ESUHzMwBryjYVKQJ6YZWswQ
	CmqLqt3cXGMi4TxpwA9gSRz5UVheH7YiIy6dMEMDY
X-Google-Smtp-Source: AGHT+IHFcCHl5V6DhX8mIa5lPED8cmkbmC4IgiZigrPJe5cWZpSYCWv+tnV1Vxgp879LFjvFU4SPZw==
X-Received: by 2002:a05:600c:1c25:b0:43c:f81d:34 with SMTP id 5b1f17b1804b1-45201437847mr27460425e9.9.1749201417639;
        Fri, 06 Jun 2025 02:16:57 -0700 (PDT)
Date: Fri, 6 Jun 2025 11:16:56 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: "Chen, Jiqian" 
Cc: "xen-devel@lists.xenproject.org" ,
	"Huang, Ray" 
Subject: Re: [PATCH v5 05/10] vpci: Hide legacy capability when it fails to
 initialize
Message-ID: 
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
 <20250526094559.140423-6-Jiqian.Chen@amd.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Fri, Jun 06, 2025 at 07:03:02AM +0000, Chen, Jiqian wrote:
> On 2025/6/5 21:35, Roger Pau Monné wrote:
> > On Mon, May 26, 2025 at 05:45:54PM +0800, Jiqian Chen wrote:
> >> When vpci fails to initialize a legacy capability of device, it just
> >> returns an error and vPCI gets disabled for the whole device.  That
> >> most likely renders the device unusable, plus possibly causing issues
> >> to Xen itself if guest attempts to program the native MSI or MSI-X
> >> capabilities if present.
> >>
> >> So, add new function to hide legacy capability when initialization
> >> fails. And remove the failed legacy capability from the vpci emulated
> >> legacy capability list.
> >>
> >> Signed-off-by: Jiqian Chen 
> >> ---
> >> cc: "Roger Pau Monné" 
> >> ---
> >> v4->v5 changes:
> >> * Modify vpci_get_register() to delete some unnecessary check, so that I don't need to move function vpci_register_cmp().
> >> * Rename vpci_capability_mask() to vpci_capability_hide().
> >>
> >> v3->v4 changes:
> >> * Modify the commit message.
> >> * In function vpci_get_previous_cap_register(), add an ASSERT_UNREACHABLE() if offset below 0x40.
> >> * Modify vpci_capability_mask() to return error instead of using ASSERT.
> >> * Use vpci_remove_register to remove PCI_CAP_LIST_ID register instead of open code.
> >> * Add check "if ( !offset )" in vpci_capability_mask().
> >>
> >> v2->v3 changes:
> >> * Separated from the last version patch "vpci: Hide capability when it fails to initialize"
> >> * Whole implementation changed because last version is wrong.
> >>   This version adds a new helper function vpci_get_register() and uses it to get
> >>   target handler and previous handler from vpci->handlers, then remove the target.
> >>
> >> v1->v2 changes:
> >> * Removed the "priorities" of initializing capabilities since it isn't used anymore.
> >> * Added new function vpci_capability_mask() and vpci_ext_capability_mask() to
> >>   remove failed capability from list.
> >> * Called vpci_make_msix_hole() in the end of init_msix().
> >>
> >> Best regards,
> >> Jiqian Chen.
> >> ---
> >>  xen/drivers/vpci/vpci.c | 117 ++++++++++++++++++++++++++++++++++++++--
> >>  1 file changed, 113 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
> >> index 2861557e06d2..60e7654ec377 100644
> >> --- a/xen/drivers/vpci/vpci.c
> >> +++ b/xen/drivers/vpci/vpci.c
> >> @@ -83,6 +83,99 @@ static int assign_virtual_sbdf(struct pci_dev *pdev)
> >>  
> >>  #endif /* CONFIG_HAS_VPCI_GUEST_SUPPORT */
> >>  
> >> +static struct vpci_register *vpci_get_register(struct vpci *vpci,
> >> +                                               unsigned int offset,
> >> +                                               unsigned int size)
> >> +{
> >> +    struct vpci_register *rm;
> > 
> > Nit: I think you re-used part of the code from vpci_remove_register()
> > that names the local variable rm (because it's for removal).  Here it
> > would better to just name it 'r' (for register).
> Will change.
> > 
> >> +
> >> +    ASSERT(spin_is_locked(&vpci->lock));
> >> +
> >> +    list_for_each_entry ( rm, &vpci->handlers, node )
> >> +    {
> >> +        if ( rm->offset == offset && rm->size == size )
> >> +            return rm;
> >> +
> >> +        if ( offset <= rm->offset )
> >> +            break;
> >> +    }
> >> +
> >> +    return NULL;
> >> +}
> >> +
> >> +static struct vpci_register *vpci_get_previous_cap_register(
> >> +    struct vpci *vpci, unsigned int offset)
> >> +{
> >> +    uint32_t next;
> >> +    struct vpci_register *r;
> >> +
> >> +    if ( offset < 0x40 )
> >> +    {
> >> +        ASSERT_UNREACHABLE();
> >> +        return NULL;
> >> +    }
> >> +
> >> +    r = vpci_get_register(vpci, PCI_CAPABILITY_LIST, 1);
> >> +    if ( !r )
> >> +        return NULL;
> >> +
> >> +    next = (uint32_t)(uintptr_t)r->private;
> >> +    while ( next >= 0x40 && next != offset )
> >> +    {
> >> +        r = vpci_get_register(vpci, next + PCI_CAP_LIST_NEXT, 1);
> >> +        if ( !r )
> >> +            return NULL;
> >> +        next = (uint32_t)(uintptr_t)r->private;
> >> +    }
> >> +
> >> +    if ( next < 0x40 )
> >> +        return NULL;
> > 
> > The code below I think it's a bit simpler (and compact) by having a
> > single return instead of multiple ones:
> > 
> > for ( r = vpci_get_register(vpci, PCI_CAPABILITY_LIST, 1); r;
> >       r = next >= 0x40 ? vpci_get_register(vpci,
> >                                            next + PCI_CAP_LIST_NEXT, 1)
> >                        : NULL )
> > {
> >     next = (uint32_t)(uintptr_t)r->private;
> >     ASSERT(next == (uintptr_t)r->private);
> Why need this ASSERT here?

Extra safety to ensure the value is not truncated (which will indicate
something is off).  I would not argue strongly for it to be added if
you don't think it's needed.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 09:18:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 09:18:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008279.1387540 (Exim 4.92)
	(envelope-from )
	id 1uNTDr-0008QX-JZ; Fri, 06 Jun 2025 09:18:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008279.1387540; Fri, 06 Jun 2025 09: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 1uNTDr-0008QQ-G0; Fri, 06 Jun 2025 09:18:47 +0000
Received: by outflank-mailman (input) for mailman id 1008279;
 Fri, 06 Jun 2025 09: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 1uNTDp-0008QI-Em
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 09:18:45 +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 3e901612-42b7-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 11:18:44 +0200 (CEST)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-451d3f72391so24510635e9.3
 for ; Fri, 06 Jun 2025 02:18:44 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-45213709729sm17336525e9.19.2025.06.06.02.18.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 06 Jun 2025 02:18:43 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3e901612-42b7-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749201524; x=1749806324; 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=3IdQjJF9gZnyZYYf1r4pKU7xWWviktuD/x3iuFyCOdw=;
        b=XX+SkDpmprctbr81n9+0lOfYvPYL+Tdh3NSHTVPBeB+3Inya1DQgbumI30sl2ED5Na
         WBYgq/MSmu/rFnJj9ovzaFqFuulHNVo3DJ6+v+pGPdvcHYtRSHcokB3bzaUps7+G6fGo
         ouofhhylmTdqPyX3p1avzgYuJlvvCCWO5bcm4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749201524; x=1749806324;
        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=3IdQjJF9gZnyZYYf1r4pKU7xWWviktuD/x3iuFyCOdw=;
        b=PLY4W6hLShx+RW3ptNCO0eTFVi9wah1QglNuX1p/ZPPlW64LljnrxqZzyzimRPZuO3
         h7aRdzUHSYgda6qEfee5r/TP0BJigV8T2CT0v9kvhARIpef793Oaq9PLTUSW3EZhEi7G
         dr58gOp8PnPxIp5PgxSFhM7DX7hV9KqDa/hkB9VtvASQeBBJQ+swQXVZbXXcEvBghwSA
         5acMolsPWq+3zYBbSXXGzGGTEJCkm2X9WShF3pexAfRg59i8GTzUIs0iKnQGCZg/v/eB
         KaaLW/2wHlit3qp3HpnV6Y9exIxj2fdJf0m1gCAqXF3HC79MqAnu5mF1N3QQbR0qtteq
         cB7A==
X-Gm-Message-State: AOJu0Yzk+zyw4Tr9wRohz9bz+l9gnRFpk0vJptDlTiXdxe2MvM8pk9zv
	DBL4OKaMPJWO/ARcqKAT3eP6mMjWfYBCw72+zXWj4ipG67hcfWAQ48jjdGh4+wpC9iw=
X-Gm-Gg: ASbGncuBxb5+bFfuNXCowoeZLj1CdgNo71i5wjivfCMyA6Wj12bjwW6pVUkkg9QnUWV
	vuFiVmqp6exCkycRiZVmVhOVfSsY4+iPB4cp6mHGtrplbGyh29wC3Qnv629QuXaKffe95E4XAgO
	7DjB4mvLqTpNNqNlhg/aOOVV9TyFcqvWRy3vbSy+n8CfyViDLtQ3lUgiHZ/SgIsO+DE/5sTZB5b
	fQcZrE6HhO+aL76g5Hgv1OIUA05N9QWxlz/IuFJL+rn1w4FiAMa441cmdRoJaESk954n482OvuT
	Np8owoaFA2YxFqNs++b6yTTo0Wq2vTbph+1fEwvLfGclzu+JkxLldr2XCqeHiHlP3q1vzJaRcME
	27QFS5JSiiSe0hkyrO6Y=
X-Google-Smtp-Source: AGHT+IGJnJW33vQrfOLwL4KX9GbDUx9QKMz1GNvQtmGPgxfc+PEz7TniH5IOht6bN5736iKHv8YxLQ==
X-Received: by 2002:a05:600c:6085:b0:442:f485:6fa4 with SMTP id 5b1f17b1804b1-452014ea837mr26105615e9.31.1749201523973;
        Fri, 06 Jun 2025 02:18:43 -0700 (PDT)
Date: Fri, 6 Jun 2025 11:18:42 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: "Chen, Jiqian" 
Cc: "xen-devel@lists.xenproject.org" ,
	"Huang, Ray" ,
	Andrew Cooper ,
	Anthony PERARD ,
	"Orzel, Michal" ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v5 06/10] vpci: Hide extended capability when it fails to
 initialize
Message-ID: 
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
 <20250526094559.140423-7-Jiqian.Chen@amd.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Fri, Jun 06, 2025 at 08:30:42AM +0000, Chen, Jiqian wrote:
> On 2025/6/5 22:47, Roger Pau Monné wrote:
> > On Mon, May 26, 2025 at 05:45:55PM +0800, Jiqian Chen wrote:
> >> @@ -209,11 +301,11 @@ static int vpci_init_capabilities(struct pci_dev *pdev)
> >>                     pdev->domain, &pdev->sbdf,
> >>                     is_ext ? "extended" : "legacy", cap);
> >>              if ( !is_ext )
> >> -            {
> >>                  rc = vpci_capability_hide(pdev, cap);
> >> -                if ( rc )
> >> -                    return rc;
> >> -            }
> >> +            else
> >> +                rc = vpci_ext_capability_hide(pdev, cap);
> >> +            if ( rc )
> >> +                return rc;
> > 
> > Could the code in the previous patch be:
> > 
> > if ( !is_ext )
> >     rc = vpci_capability_hide(pdev, cap);
> > 
> > if ( rc )
> >     return rc;
> > 
> > So that your introduction here is simpler?
> OK, but the logic of the previous patch will become a little strange.
> Anyway, the strange will disappear after applying this patch.

No strong opinion really, was mostly a recommendation to avoid extra
changes here.  In a series it's best if you try to arrange the code so
that it's only modified once (if possible, obviously).

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 09:19:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 09:19:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008285.1387550 (Exim 4.92)
	(envelope-from )
	id 1uNTEY-0000U7-R4; Fri, 06 Jun 2025 09:19:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008285.1387550; Fri, 06 Jun 2025 09:19: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 1uNTEY-0000U0-OU; Fri, 06 Jun 2025 09:19:30 +0000
Received: by outflank-mailman (input) for mailman id 1008285;
 Fri, 06 Jun 2025 09:19: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 1uNTEX-0008QI-Kq
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 09:19:29 +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 5903e3e7-42b7-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 11:19:29 +0200 (CEST)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-ad89ee255easo335448966b.3
 for ; Fri, 06 Jun 2025 02:19:28 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ade1d754235sm86366666b.5.2025.06.06.02.19.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 06 Jun 2025 02:19:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5903e3e7-42b7-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749201568; x=1749806368; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=KdvN2IHJeL4rJjEJixfXVkFNCRLcPZ8fs39/M63KUfg=;
        b=KYfRCnpQ746QgM/N+sw8iI2eRPgElwp3G5SRWqwCL+dGHthlPlHlM+OUSClFDNL4tA
         qkL3FNBdTcgql/kUvIwpVYYmYYs2sNoaQ12Z+V6eFzc1D/leA6GL4EQ7EUsjO6qkXYf6
         tTzhnAouUrVobCkVXBaJfAaMMKLV8H8G3cSl1qlTOa9AXcix1uUwumBmL8bBbbDlHY24
         ShLXZA0pZMTMNYGqm9Cs+AM8yQRLWcE4+E+FCAucCWTbbhQxayGwJL3jkSTSUA0U3uau
         1guiC2/mDsNTD5H11TzG6+pe2ESkr9vHXzFzOdVncKY8rbNTqrPYG35wwydBAThZA7f+
         TBOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749201568; x=1749806368;
        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=KdvN2IHJeL4rJjEJixfXVkFNCRLcPZ8fs39/M63KUfg=;
        b=d8bIbdzC23OW0Bu1ZC5Gw2JBWREpLbPKSHTtd5EKbD+7ddmHK4FIF1rPB9lF7h0HGC
         u9/6NpbiOq92ehKY+ofQjrEX0evE3pZ7PTzMoeS+xeUhEFnwBC/akVFwpgKIcGVoyNpc
         1njQf70yrnyBWnXaTDopOpC/pc9hzDAjIj8ARlS0DtnsRWIGcsvCQjsr5ht5TbFLopmn
         qjsrkAbdBVCDuQApHXbkgx7FpRdjYF3qgw7Epf1RqIqoenrsRHn8dAQfE1oZ930AT9Tu
         LDFpkEoKiloNftCRTy//1/3bWxHX/D+mqHdEc0ODXNbIAk/PBQYeKc3McnftukE7Cqr/
         1JIA==
X-Forwarded-Encrypted: i=1; AJvYcCXl0+56sSbCtLrS3wgBnY7+pxZx6R8xMZnO+EeJJgZ4F4Yx/Yg0D/AH8aNM05YzOTS2lZVOCYkgMHY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzNyZRPQEEHodbjbLOEWUrfT4De3qEyfCw3A1zVD9XhDBPCJkk+
	vHaSlrW0ypGGH6vC//hP3pWN7CS0g5vlmAl53oq3wo8ztkDYZY9X71M3roWQRRhleQ==
X-Gm-Gg: ASbGncsG/9jj3nkJbOK3Q7a2ntRU3ifmrWzqfuoGleykk367cBXUPnqSzILpkoGes7f
	Zb/AIQd32wM2qXm3TEcB4mAcTFqmIlUtK+z7VFWdfRk9RZCHxMbgT8N/WT8oz6Bcxe7rebMpqrO
	stktJDR/hTLZUGgDAj5BjINWLM3LhylbTEllyvIEHdIe1rwu2yWALcpjeIxWjXjY2/0+jz7kloB
	uOA4Lxu1aKfHZLf1C33ORO9waYUoDP/w2bmyHg/ASnVjo5xrBwbXCbSwUtnxOIYldsFegkpaKVD
	e+1rQvg6nhW8MK0FHg9iBpHPrIugS3CO8nDRHnnLPVGqTEjryW8jZYEhW/5Nhhdfspj9E7cvq3b
	rfVW3uHWtUzwcYzf/EhsSwDiXb7KKKVhgrZKC
X-Google-Smtp-Source: AGHT+IGbqMjZbZmUBJv8ubaBJQnz9w6RlLlu1EPzewPKM8G9q5DQivztGt0QgvxD5w/0Nl03bUPKBQ==
X-Received: by 2002:a17:907:868c:b0:ad2:2d75:d7fb with SMTP id a640c23a62f3a-ade1a9ed821mr241838366b.55.1749201568399;
        Fri, 06 Jun 2025 02:19:28 -0700 (PDT)
Message-ID: <0c9d2432-3c5c-4f93-8c07-99894d7f8606@suse.com>
Date: Fri, 6 Jun 2025 11:19:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 4/6] x86: control memset() and memcpy() inlining
To: Teddy Astie 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <73481cbf-337f-4e85-81d2-3487366cd822@suse.com>
 
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 05.06.2025 19:34, Teddy Astie wrote:
> Le 05/06/2025 à 12:28, Jan Beulich a écrit :
>> Stop the compiler from inlining non-trivial memset() and memcpy() (for
>> memset() see e.g. map_vcpu_info() or kimage_load_segments() for
>> examples). This way we even keep the compiler from using REP STOSQ /
>> REP MOVSQ when we'd prefer REP STOSB / REP MOVSB (when ERMS is
>> available).
>>
> 
> If the size is known and constant, and the compiler is able to generate 
> a trivial rep movs/stos (usually with a mov $x, %ecx before). I don't 
> see a reason to prevent it or forcing it to make a function call, as I 
> suppose it is very likely that the plain inline rep movs/stos will 
> perform better than a function call (even if it is not the prefered rep 
> movsb/stosb), eventually also being smaller.
> 
> I wonder if it is possible to only generate inline rep movs/stos for 
> "trivial cases" (i.e preceded with a plain mov $x, %ecx), and rely on 
> either inline movs or function call in other cases (non-trivial ones).

Note how the description starts with "Stop the compiler from inlining
non-trivial ...", which indeed remain unaffected according to my
observations (back at the time).

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 09:20:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 09:20:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008291.1387559 (Exim 4.92)
	(envelope-from )
	id 1uNTFy-0002A2-4Y; Fri, 06 Jun 2025 09:20:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008291.1387559; Fri, 06 Jun 2025 09: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 1uNTFy-00029v-23; Fri, 06 Jun 2025 09:20:58 +0000
Received: by outflank-mailman (input) for mailman id 1008291;
 Fri, 06 Jun 2025 09:20: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 1uNTFw-00028W-IU
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 09:20:56 +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 8ccccd57-42b7-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 11:20:55 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a4f379662cso1618250f8f.0
 for ; Fri, 06 Jun 2025 02:20:55 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a532463ed4sm1292910f8f.94.2025.06.06.02.20.54
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 06 Jun 2025 02:20:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8ccccd57-42b7-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749201655; x=1749806455; 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=+wYFZDVcY/cjwfdDAJEk59Nw/L3QBi9m9OTDsBJRPWo=;
        b=OIt+t/ic2b6O30Ty4z2lOU1yma8TdkflsC87juOF7SEi5NZNug9VcEuF3ctTgnyK3R
         ZZ0VeaR0zyL/Y3HP6FsK67HDR+jyGxwhPhGMt0kjWYKPhA2utEVpkNNnZ1PgwE9qRkse
         nnLWBhGaBCAKJNxgiGtqOv69FIYioyOtDW8g0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749201655; x=1749806455;
        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=+wYFZDVcY/cjwfdDAJEk59Nw/L3QBi9m9OTDsBJRPWo=;
        b=AfbqAL0Zih+mtCH9vuD8yb5vijc4MfFhK3tCXJG79jLQG+t1aj+MIoXy6I4GCyxzll
         e6JQzawq3UkqDbbdWxGKvhnbpKKzXyEJCbtmh5g6e0L7uycWbBkx0UIS5DCTMjuwlSUO
         DRqXNj/mIKRnidodcByVQpp6niDQIg/WmKPpqlLLZmS7dPgu6mg/aqHMnlr/sU7Hx84j
         sG6+FYA+S63ZyVxnCzUWvX+Scl1+GxwdTF9k3P9lWE+4J38Js2f1U/3D5cg+jtQ9+CGX
         D8j2gqXkw2j2KtRl5XfQ+zxiPJABQt32G8pV37/16i2EJSoZEen2KABE76t7XeP63yhX
         knMA==
X-Gm-Message-State: AOJu0Yy+YQnRsByYtpY0KjSDJjiPGULgwgB8ZlI5SWj+skdDPPsTV6Jm
	/Ol6K5uW8x7Ntx/P1mje/uDQwWcn1EDGiWm1sJcrwRYHUCUOUfZKkHPGI+s4cGpbT48=
X-Gm-Gg: ASbGncvKbi86EP1mLvF25lPBAVYXNb0q6uWP2WctKawzz/pkXSJ+aN/blefHmlp+yQu
	CzGYVenXuWCsMR5sft9ShVlJuIlhuoJ+dsLOHzF1b+0qEEIdlWDcT4EWHHoxER4/4qIU14327WT
	ukdg83ULXuHZ3Wt6pukEFJ7esVzbh6TIFwKHdFcnviEA8wzEqHODVb0ZECtiPRuSxo3ZbU55cdc
	j6KsU46hg/JRgXMfrI2CbJ9Yf2cv9yZJyV+ncrnl0N96Mf2VqLaKvHgohY4FzhdQtlL+OrJWx7d
	C8jltzIr/OyRHT0LknPoho1br25T3v8M1EfPosKztOHES/mIZIGFQm4jG2lu8f+B5mqafJ6bgg2
	cUfcEjWIOs9SQIhoxdnNDNH+HmIcI9y3sLTxkX5Go
X-Google-Smtp-Source: AGHT+IHivSmPCtrOzpDbTYjf+ajVUtwyz68nYd5L/b6kcgvfU1LmgKf2eJy/EHZlpdGnfkjGSJmS6Q==
X-Received: by 2002:a05:6000:40de:b0:3a4:f52d:8b11 with SMTP id ffacd0b85a97d-3a531ca7f9dmr2229059f8f.20.1749201655155;
        Fri, 06 Jun 2025 02:20:55 -0700 (PDT)
Date: Fri, 6 Jun 2025 11:20:54 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: "Chen, Jiqian" 
Cc: "xen-devel@lists.xenproject.org" ,
	"Huang, Ray" 
Subject: Re: [PATCH v5 08/10] vpci/rebar: Free Rebar resources when
 init_rebar() fails
Message-ID: 
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
 <20250526094559.140423-9-Jiqian.Chen@amd.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Fri, Jun 06, 2025 at 08:32:35AM +0000, Chen, Jiqian wrote:
> On 2025/6/5 23:14, Roger Pau Monné wrote:
> > On Mon, May 26, 2025 at 05:45:57PM +0800, Jiqian Chen wrote:
> >> When init_rebar() fails, current logic return fail and free Rebar-related
> >> resources in vpci_deassign_device(). But the previous new changes will
> >> hide Rebar capability and return success, it can't reach
> >> vpci_deassign_device() to remove resources if hiding success, so those
> >> resources must be removed in cleanup function of Rebar.
> >>
> >> To do that, implement cleanup function for Rebar.
> >>
> >> Signed-off-by: Jiqian Chen 
> > 
> > LGTM, just one nit about a bounds check.
> > 
> >> ---
> >> cc: "Roger Pau Monné" 
> >> ---
> >> v4->v5 changes:
> >> * Change definition "static void cleanup_rebar" to "static int cf_check cleanup_rebar" since cleanup hook is changed to be int.
> >>
> >> v3->v4 changes:
> >> * Change function name from fini_rebar() to cleanup_rebar().
> >> * Change the error number to be E2BIG and ENXIO in init_rebar().
> >>
> >> v2->v3 changes:
> >> * Use fini_rebar() to remove all register instead of in the failure path of init_rebar();
> >>
> >> v1->v2 changes:
> >> * Called vpci_remove_registers() to remove all possible registered registers instead of using a array to record all registered register.
> >>
> >> Best regards,
> >> Jiqian Chen.
> >> ---
> >>  xen/drivers/vpci/rebar.c | 35 ++++++++++++++++++++++++-----------
> >>  1 file changed, 24 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/xen/drivers/vpci/rebar.c b/xen/drivers/vpci/rebar.c
> >> index 9cafd80ca2c9..4b1892fab3d6 100644
> >> --- a/xen/drivers/vpci/rebar.c
> >> +++ b/xen/drivers/vpci/rebar.c
> >> @@ -49,6 +49,26 @@ static void cf_check rebar_ctrl_write(const struct pci_dev *pdev,
> >>      bar->guest_addr = bar->addr;
> >>  }
> >>  
> >> +static int cf_check cleanup_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 || !is_hardware_domain(pdev->domain) )
> > 
> > I think you could check rebar_offset < PCI_CFG_SPACE_SIZE to be more
> > accurate?
> OK.
> Do I need to change in init_rebar()?

Hm, pci_find_ext_capability() will never return a value <
PCI_CFG_SPACE_SIZE different than 0, so maybe none of this is needed.
Just leave it like you have, and please ignore the other requests to
change the checks, sorry for the fuss.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 09:21:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 09:21:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008300.1387569 (Exim 4.92)
	(envelope-from )
	id 1uNTGT-0002vC-FP; Fri, 06 Jun 2025 09:21:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008300.1387569; Fri, 06 Jun 2025 09:21: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 1uNTGT-0002v4-Ct; Fri, 06 Jun 2025 09:21:29 +0000
Received: by outflank-mailman (input) for mailman id 1008300;
 Fri, 06 Jun 2025 09:21: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 1uNTGS-0002cH-Eu
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 09:21:28 +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 9f5108ff-42b7-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 11:21:26 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3a365a6804eso1264935f8f.3
 for ; Fri, 06 Jun 2025 02:21:26 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a5323b653dsm1313155f8f.39.2025.06.06.02.21.25
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 06 Jun 2025 02:21:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9f5108ff-42b7-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749201686; x=1749806486; 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=XDjRAfe21aPSN4PV54jmcZ7Bl2LRjvbfpaSIkqhQ05o=;
        b=vq5Nq9td40tGbcgSwTyl8ldb4UxnxNH9/Pj/vIu1kv1obMlI4gDTapOh/2GO+ecu1N
         xge8yuCdS7FLVH3k6m0QEiGzFUauQ1JpfpV3eP8YE4jEzKszutBehT9WCgN04t6T/GD4
         /XWG42KNFWPmP/ywPQsr92RfjxXqlfLBdusoY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749201686; x=1749806486;
        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=XDjRAfe21aPSN4PV54jmcZ7Bl2LRjvbfpaSIkqhQ05o=;
        b=ccijgPu52NrHDhcxiiBvKiT0fruLagpOJvE/89hAiycnt0DJFwT4Hf5II73wIsad2G
         jZYji1A3Sm8WLt4e3bIVeCKtmz6nCQKWecYfPI7WD2xSDge2RQL9IcaRFiGPS+Lb2t4t
         R/2Mao03gmVn9zbDg7cu8llgomypefWNf2ufv3I+TCeV7B6misNb/hbRqBy1NFSZrjhF
         8auqURZUcvJoagF/O4egM8jhmDEkOzPJtxofqaIMSEBa0WkLousvgtANWrku79M3i8bN
         VN2erIrxqpXwSMn66YczAJMNl7KO/RljQX/lKCrp1hybWj4+f6luP6/fwUo9RKtKc9RC
         ndfA==
X-Gm-Message-State: AOJu0YwaXrCXP/e5p7dcT3n4Yc6Ou4sXgjjhP+Ry/bys/eihywbw9K5U
	MqlYOj+/8usHkzCYxm2vgn/McFrUK3BjXt9sEmT33FeBOTEc4+BFzLqsmpYJRjXVJNnlzE0qc/W
	zAEVq
X-Gm-Gg: ASbGnctb9FGqzJDCR1FrsFAReD8Q7lEkrcJiWBHxS2EMUJFX368bA0XaoBgsNwtBVKR
	r4xCU4tYif5NufZHqWqZZe54/eAF1+flwMD4lVR6tOCZ+pK5EWWbtaqAVI/xBgiqRBvgMIDdCRe
	oBhoTpXk2OgY6RVl5NoTDde5wJnj3lSXvuZxTzTxDPCy0wuiIKVsB8cb8OSpSkxR7P3G5J/kq1x
	R0Xmwji/klbVqKshS9TQipC80E4XtWc55iILSTqy3i75809fJK9c8SQZVrDdrKtNA1tPpN7mg5w
	g7o0Dl7ZGsrsYo/ynqc236y1nop6jaHXhZMzqxFIBMf/wC0X1yITbgEq8loTRHz4qhZR5AjQdJo
	ocEQLvmvSd4PqXtdcTCeckokb++vSKw==
X-Google-Smtp-Source: AGHT+IEhNXAiXaJITIXO5z84uL2rCHNHexjmI1AqwbZyYxKhSpdCOyEHtvraokHwkuUPr7BhL6I5KA==
X-Received: by 2002:a05:6000:290f:b0:3a3:7ba5:93a5 with SMTP id ffacd0b85a97d-3a531cb27e9mr2130150f8f.26.1749201686325;
        Fri, 06 Jun 2025 02:21:26 -0700 (PDT)
Date: Fri, 6 Jun 2025 11:21:25 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: "Chen, Jiqian" 
Cc: "xen-devel@lists.xenproject.org" ,
	"Huang, Ray" 
Subject: Re: [PATCH v5 09/10] vpci/msi: Free MSI resources when init_msi()
 fails
Message-ID: 
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
 <20250526094559.140423-10-Jiqian.Chen@amd.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Fri, Jun 06, 2025 at 08:38:49AM +0000, Chen, Jiqian wrote:
> On 2025/6/5 23:19, Roger Pau Monné wrote:
> > On Mon, May 26, 2025 at 05:45:58PM +0800, Jiqian Chen wrote:
> >> When init_msi() fails, current logic return fail and free MSI-related
> >> resources in vpci_deassign_device(). But the previous new changes will
> >> hide MSI capability and return success, it can't reach
> >> vpci_deassign_device() to remove resources if hiding success, so those
> >> resources must be removed in cleanup function of MSI.
> >>
> >> To do that, implement cleanup function for MSI.
> >>
> >> Signed-off-by: Jiqian Chen 
> >> ---
> >> cc: "Roger Pau Monné" 
> >> ---
> >> v4->v5 changes:
> >> * Change definition "static void cleanup_msi" to "static int cf_check cleanup_msi" since cleanup hook is changed to be int.
> >> * Add a read-only register for MSI Control Register in the end of cleanup_msi.
> >>
> >> v3->v4 changes:
> >> * Change function name from fini_msi() to cleanup_msi().
> >> * Remove unnecessary comment.
> >> * Change to use XFREE to free vpci->msi.
> >>
> >> v2->v3 changes:
> >> * Remove all fail path, and use fini_msi() hook instead.
> >> * Change the method to calculating the size of msi registers.
> >>
> >> v1->v2 changes:
> >> * Added a new function fini_msi to free all MSI resources instead of using an array to record registered registers.
> >>
> >> Best regards,
> >> Jiqian Chen.
> >> ---
> >>  xen/drivers/vpci/msi.c | 29 ++++++++++++++++++++++++++++-
> >>  1 file changed, 28 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/xen/drivers/vpci/msi.c b/xen/drivers/vpci/msi.c
> >> index 2d45c7867de7..4e106c39efae 100644
> >> --- a/xen/drivers/vpci/msi.c
> >> +++ b/xen/drivers/vpci/msi.c
> >> @@ -193,6 +193,33 @@ static void cf_check mask_write(
> >>      msi->mask = val;
> >>  }
> >>  
> >> +static int cf_check cleanup_msi(struct pci_dev *pdev)
> >> +{
> >> +    int rc;
> >> +    unsigned int end, size;
> >> +    struct vpci *vpci = pdev->vpci;
> >> +    const unsigned int msi_pos = pdev->msi_pos;
> >> +    const unsigned int ctrl = msi_control_reg(msi_pos);
> >> +
> >> +    if ( !msi_pos || !vpci->msi )
> > 
> > Possibly same request as the previous patch, msi_pos should be after
> > the PCI standard header.
> msi_pos <= PCI_CAPABILITY_LIST ?
> Or msi_pos < 0x40 ?

Hm, no, ignore this, sorry.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 09:23:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 09:23:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008307.1387580 (Exim 4.92)
	(envelope-from )
	id 1uNTI1-0003cs-Pc; Fri, 06 Jun 2025 09:23:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008307.1387580; Fri, 06 Jun 2025 09:23: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 1uNTI1-0003cl-MF; Fri, 06 Jun 2025 09:23:05 +0000
Received: by outflank-mailman (input) for mailman id 1008307;
 Fri, 06 Jun 2025 09:23: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 1uNTI0-0003cd-Nt
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 09:23:04 +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 d9314f31-42b7-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 11:23:04 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3a4e742dc97so1914945f8f.0
 for ; Fri, 06 Jun 2025 02:23:04 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a532464581sm1310620f8f.95.2025.06.06.02.23.02
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 06 Jun 2025 02:23:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d9314f31-42b7-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749201783; x=1749806583; 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=vDxlvwlA58ZhsEIhri6RBySwLFlTdx7Xvm/kRtk0QwA=;
        b=Pe79+G8+4tjq+8MqUi7QCT+z3bgnHMHu4dGD57fssgPTDArKr79rXC8VbpQiqA5Hlx
         H+SV+g5vctKFX3auEILYQgAC0uSNjnyAdvh2Hfy1OXKbWDgccT5YDGMkjAYXDkOb/Oc+
         rEAXmFAUdf8LVE3v+FpzhbLLnrYuZKGeXsfHo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749201783; x=1749806583;
        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=vDxlvwlA58ZhsEIhri6RBySwLFlTdx7Xvm/kRtk0QwA=;
        b=vfvddiAR0AQ3CHpZQmPeJ1Ou72C73yvXbtO5IpDQjR0Pz+hQtel6ANg/Z4KRSyk2Qh
         CtlAcqqWP41qxvYjXcScFl/0oVsM1NrNe8PDJvFnx+XKMa49mGPbRIdXs+JVLP24IMd1
         rE5+KHpZtuSMuvJomRlh3fhZu+wmxkJckN+IQpK061759elJSa7MDPRB43mTXqLrf4mL
         RFSEdNPq3aqHOdeSgQ9nKO2nqDmVwQ2PdXIlPx8KtNECmGzoeSReh5gRCwWT3214Lfdm
         sorDGM9ArF/dLGjvl/ux8GEXdSxnFFGB8Y+JInGdE260E8N2V0H1ZAs+fKhdfvmy3MEH
         IAZw==
X-Gm-Message-State: AOJu0Yy1FFhNi2g+JFvsWBOtXjyj4112tZzA3VpIGFkzHNe7g0Vpdi2H
	vTq+zCdq9MVs4L/yV9tXB5oR/w1urg3sucOpjNuCImYNTuFG1hIaa21kRNcXSE5Vsjkvzt8SEdo
	cX4z8
X-Gm-Gg: ASbGncufVEO8yisfJXjhSPqSkeuBE4fDPre8p6uv2KREdaqCK7NxSDyA9ykPV/7+9JE
	HvNNBoECG18p8oLkGngqUIiELPvSuPdbACu2HhYvRLxhIPjulVn2vkGbhJ5EV89xX3rpLMfVNVV
	GqOgqEJbjJLDHy6mGrDs9RjYLcaES2EC+wn+Q3E4Z/3lkTKd1EtKroCGTdVqzIsTL/ybGCvlrhS
	qQTrjMHq9zS3QEnP7VQqJmlcbDjA95mqUYq889lir9H5PkyI4LsTn5CDZm5LuNxjt5kf2BAECaq
	D0QZFE+7TKWEGe/HA3shywGK2hOSpDlkklA1q7WTnom+1DDj4/XTRPNIU0aotJn8ttGBDue6XLe
	mHd8BFYwN6D+mR+9/Mv8=
X-Google-Smtp-Source: AGHT+IHWDLBAAv5bxIu+sSYJCKoiwdCT4iWQTnaFGD/sqri1cHaBnHljsiAosMYzxjsCyx/a/p7vfw==
X-Received: by 2002:a05:6000:2211:b0:3a4:eee4:f73a with SMTP id ffacd0b85a97d-3a5314342dbmr2869051f8f.22.1749201783339;
        Fri, 06 Jun 2025 02:23:03 -0700 (PDT)
Date: Fri, 6 Jun 2025 11:23:02 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: "Chen, Jiqian" 
Cc: "xen-devel@lists.xenproject.org" ,
	"Huang, Ray" 
Subject: Re: [PATCH v5 10/10] vpci/msix: Free MSIX resources when init_msix()
 fails
Message-ID: 
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
 <20250526094559.140423-11-Jiqian.Chen@amd.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Fri, Jun 06, 2025 at 08:44:02AM +0000, Chen, Jiqian wrote:
> On 2025/6/5 23:34, Roger Pau Monné wrote:
> > On Mon, May 26, 2025 at 05:45:59PM +0800, Jiqian Chen wrote:
> >> When init_msix() fails, current logic return fail and free MSIX-related
> >> resources in vpci_deassign_device(). But the previous new changes will
> >> hide MSIX capability and return success, it can't reach
> >> vpci_deassign_device() to remove resources if hiding success, so those
> >> resources must be removed in cleanup function of MSIX.
> >>
> >> To do that, implement cleanup function for MSIX.
> >>
> >> Signed-off-by: Jiqian Chen 
> > 
> > 
> > 
> >> ---
> >> cc: "Roger Pau Monné" 
> >> ---
> >> v4->v5 changes:
> >> * Change definition "static void cleanup_msix" to "static int cf_check cleanup_msix" since cleanup hook is changed to be int.
> >> * Add a read-only register for MSIX Control Register in the end of cleanup_msix().
> >>
> >> v3->v4 changes:
> >> * Change function name from fini_msix() to cleanup_msix().
> >> * Change to use XFREE to free vpci->msix.
> >> * In cleanup function, change the sequence of check and remove action according to init_msix().
> >>
> >> v2->v3 changes:
> >> * Remove unnecessary clean operations in fini_msix().
> >>
> >> v1->v2 changes:
> >> new patch.
> >>
> >> Best regards,
> >> Jiqian Chen.
> >> ---
> >>  xen/drivers/vpci/msix.c | 29 ++++++++++++++++++++++++++++-
> >>  1 file changed, 28 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/xen/drivers/vpci/msix.c b/xen/drivers/vpci/msix.c
> >> index 674815ead025..cf79320d3b6f 100644
> >> --- a/xen/drivers/vpci/msix.c
> >> +++ b/xen/drivers/vpci/msix.c
> >> @@ -655,6 +655,33 @@ int vpci_make_msix_hole(const struct pci_dev *pdev)
> >>      return 0;
> >>  }
> >>  
> >> +static int cf_check cleanup_msix(struct pci_dev *pdev)
> >> +{
> >> +    int rc;
> >> +    struct vpci *vpci = pdev->vpci;
> >> +    const unsigned int msix_pos = pdev->msix_pos;
> >> +
> >> +    if ( !msix_pos )
> Need to change this check as previous patch, I think.

No, please ignore those previous requests, sorry.

> >> +        return 0;
> >> +
> >> +    rc = vpci_remove_registers(vpci, msix_control_reg(msix_pos), 2);
> >> +    if ( rc )
> >> +        return rc;
> >> +
> >> +    if ( !vpci->msix )
> >> +        return 0;
> > 
> > You cannot short-circuit here, as it then prevents adding the dummy
> > handlers done in the last return.
> > 
> >> +
> >> +    for ( unsigned int i = 0; i < ARRAY_SIZE(vpci->msix->table); i++ )
> >> +        if ( vpci->msix->table[i] )
> >> +            iounmap(vpci->msix->table[i]);
> >> +
> >> +    list_del(&vpci->msix->next);
> >> +    XFREE(vpci->msix);
> >> +
> >> +    return vpci_add_register(pdev->vpci, vpci_hw_read16, NULL,
> >> +                             msix_control_reg(msix_pos), 2, NULL);
> > 
> > The above needs to be added even if !vpci->msix.
> Oh, right.
> I will change to
> 
>     if ( vpci->msix )
>     {
>         for ( unsigned int i = 0; i < ARRAY_SIZE(vpci->msix->table); i++ )
>             if ( vpci->msix->table[i] )
>                 iounmap(vpci->msix->table[i]);
> 
>         list_del(&vpci->msix->next);
>         XFREE(vpci->msix);
>     }

LGTM, thanks.

Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 09:55:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 09:55:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008320.1387590 (Exim 4.92)
	(envelope-from )
	id 1uNTnc-0008Vh-Tc; Fri, 06 Jun 2025 09:55:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008320.1387590; Fri, 06 Jun 2025 09:55: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 1uNTnc-0008Va-R0; Fri, 06 Jun 2025 09:55:44 +0000
Received: by outflank-mailman (input) for mailman id 1008320;
 Fri, 06 Jun 2025 09:55: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 1uNTnb-0008VU-9l
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 09:55:43 +0000
Received: from NAM02-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam02on20601.outbound.protection.outlook.com
 [2a01:111:f403:2405::601])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 66f04c62-42bc-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 11:55:40 +0200 (CEST)
Received: from CH0PR03CA0071.namprd03.prod.outlook.com (2603:10b6:610:cc::16)
 by CH3PR12MB8849.namprd12.prod.outlook.com (2603:10b6:610:178::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Fri, 6 Jun
 2025 09:55:34 +0000
Received: from CH2PEPF0000013C.namprd02.prod.outlook.com
 (2603:10b6:610:cc:cafe::81) by CH0PR03CA0071.outlook.office365.com
 (2603:10b6:610:cc::16) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.27 via Frontend Transport; Fri,
 6 Jun 2025 09:55:34 +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.8792.29 via Frontend Transport; Fri, 6 Jun 2025 09:55:34 +0000
Received: from localhost (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; Fri, 6 Jun
 2025 04:55:32 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 66f04c62-42bc-11f0-a301-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=eQGd5PVRmF0qnee5IcahzymV9IsiSxcaUDaROc0EHMbtNULsHIQuXXVsATwB1OF3f5XBxLz7yh+Ls73L55fiXPC9fq73VgztdUJ+l0wxmwpUktEowWiGbaZQGN63vSlr5HJUTkzjB30+TiIpGELaB/thCFAEJKmG0EyJAfZzhP/qP30WfEJS/KZhVaL5RHAqLCtnsA+b/vRSOpQIItsIOstaMhrzvaJce7BjCwtfnzPi/MTVFyksMqlue6/3el5NOC1icR5KzJQXlC63qym9s7IDkWwEfbxcxOZTEOZuI/ftV4KdmAWlNwLNIeXao2NGo/PCVO633qUXYB8ApOikbA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=k3sq9ZSeuYfZ6qSVtrYHI1s8YoEhXWX1JYfCFAdlAOY=;
 b=sAp1COQCz4TJLgLz1mb8fCVT19SOuQuyeZxnuyd7OU1sp/VXMX/CTQ2llXkf5cgzFG5jv5ByamLskyfbCQFUUsFGag9KxuTNLnYBRnQQJzHUewXia4KuYg/sQmBZdI/k1ceqnpdt1VWLcgqALWQM9GmkTlubXONOA+I2iCQXwMaewt1NPePncFKeivzQ973YaCljWe5GCBItrixd8/gY7WR8n+ecnqQ/g5FZz1r+2NAS7XWm1RK3Yrd9M4Gh52Gx45bynalv9odpULDmXwoP2Wei7vhGR5iSMwLs4r9jJhT4wRpHz+cSz5Vprq5IbuQSJFRW3fo8XqdsjIce2rjQAw==
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=k3sq9ZSeuYfZ6qSVtrYHI1s8YoEhXWX1JYfCFAdlAOY=;
 b=eWJpGZEURSF6/75J+pUv2uDmKKUtNR7tjxbDsuTRRdgX8MgnzPpygZtnBZD9Yfb5rc/z7jxSBVG3n8UnszOuMFxpcL2+gKlfPFVjXrrnwQLL4EJ5buyk3WgoaSB2TRUVD37ONv3lyqrdgkKlhtBGS9tw8lyCLjVBj3lbwv2ln1g=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 6 Jun 2025 11:55:30 +0200
Message-ID: 
CC: Alistair Francis , Bob Eshleman
	, Connor Davis , "Oleksii
 Kurochko" , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	=?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini
	, "Daniel P. Smith" ,
	
Subject: Re: [PATCH v2 01/15] xen: Clean up asm-generic/device.h
From: Alejandro Vallejo 
To: Jan Beulich 
X-Mailer: aerc 0.20.1
References: <20250605194810.2782031-1-agarciav@amd.com>
 <20250605194810.2782031-2-agarciav@amd.com>
 <38104467-fb7e-4aa3-9c78-0f9bf23183eb@suse.com>
In-Reply-To: <38104467-fb7e-4aa3-9c78-0f9bf23183eb@suse.com>
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: CH2PEPF0000013C:EE_|CH3PR12MB8849:EE_
X-MS-Office365-Filtering-Correlation-Id: 2877acb6-72f4-4bc0-6511-08dda4e04828
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|7416014|376014|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?QmI5VVB5SEtmTG1iRG93enc4S0lvYlZReHZxcloxVE1kWnBpMHE4TG9sVGw4?=
 =?utf-8?B?dXZ1d05kd25JNXZDcEZTM1RLQnY1MXVrZktCSmdtL0ljL1VRbTNKc1RXYjFy?=
 =?utf-8?B?bDdka1lhQ2g3SnhNSUxYbjdJdWU0YTNDWCtGWHFPSGVsdjRNcjVsUERnWWVo?=
 =?utf-8?B?Mk9lcFRIOUFRRGVWcy9NQ0p0MFpONXRGSXdORFpqNzVJYUNrS3hnSTVhUzVJ?=
 =?utf-8?B?RmFIWkpJZXlGS0JZWkdGTlYzQ0RldWtYeWJ5V3BEaklGZWdETkU4bENHMFdN?=
 =?utf-8?B?V29LazFTdlhqYTFTTlVKNzhwMWFGNlN1T2hmcDdQNGN2emMwY3lZdzZvNUhi?=
 =?utf-8?B?RzZSeVVxcDdXaERlR1lKL3FiUlZwem1sYzBHL2NVV1ZlNlo1aXR2cTYxN0RR?=
 =?utf-8?B?dWhvbjJSVDVrNXo5cXRkRE9GTEwzZ1BMN1NsN3VnZ3dMYndiSnZlU01IUFMv?=
 =?utf-8?B?a2RLcUtKUEg5Umc5d3ZnNnZDMXMydEtEVDVVRzFHMXNvZmhWUkxVaVRacE1i?=
 =?utf-8?B?bmJ6azA1bnk1ckJTblBMdUdpVFdhWVJmWCtiTXpxRjBoSFRYclZXSWVSeHN3?=
 =?utf-8?B?ZjdRU3EwQ1YwNzBaa1F3cGxyVE9LSzd4b3lSTjVJRFdNb0J6Rk10UnlzN24x?=
 =?utf-8?B?cmgrNjM2NU5QazRNbm1LbjY2ZmtwUWxqL1lGQm02Lytob2Mya1AvSFZrRndI?=
 =?utf-8?B?ZmpzeFVXVDYxZlBwc1hxbnpxVFhSeHV0L09yWUJhbU9UWURybHFXYWlNb1l1?=
 =?utf-8?B?UjZoZEpnK2NpVjRPM1d2aVNENk92aE1wRkJEQWJiUVh2UnNqd1FCbU8xcm1O?=
 =?utf-8?B?MVQ3STU0eGp4Z0dIdC81amhlVlJ2WURSWHhYMjM3OTFJZUJGTm56ZCt2NU9G?=
 =?utf-8?B?QzBwcjJnZmR2bWRPN0wyNXZ0bkllTnAyUUZmQ0EwOEpYTzVFcVFTTHNlV2NI?=
 =?utf-8?B?bFkxcnF2VmxNdVVqalFUS3hQVkZXWjNmckJQZEhxUExacWx2NU94V1UvM2dj?=
 =?utf-8?B?MmhlNjQwZnhYdWphWEF2K2MvUEM2OHRjOVAwaFVDZ3F2bHUrUVkva0FwbGZJ?=
 =?utf-8?B?VWVvYW9rZTkvR3FnMmFROHlJN1FQK2l6SFp0aVpCZEhRYnJWN1lmTTIxbzBo?=
 =?utf-8?B?MGxtejI5YzN3SGtXc1RKL0szRkR3VkRjYTJ4bkZrQTZoY0VxdlBLaWpvdGE1?=
 =?utf-8?B?VndlVk15S0RCMHgzNlhkUHdXcHNTdHR1K1Z1T1gvQ2VKNklhOFpuRUdzZ3Qx?=
 =?utf-8?B?R1cyQWF1SXNFWVFudlQ4anE4bEcrR29wVnZocFc5RGJ3MllxWEZwMi9YMkNh?=
 =?utf-8?B?cktzTEl5VHQrdzQra3lpYURXNzh5Ri91YTY4b3kzV2NnMm9ycWN5dnVhRzE2?=
 =?utf-8?B?T0k4SjNpQjRySkdDbkJtWmEwcW1TalhrNlNBN005QVV5Z0MzUUJxZkR0M20y?=
 =?utf-8?B?emU0WFZmSkxIZ3hlajlTK3B4UmpUMFBwS3ZMVEFKamgyTXJYRmMrYWI1bXAw?=
 =?utf-8?B?VU0yY1J3Q1JUL1NQRWxadzNtUDFlVXM3K1FralZwanhFZUR2K0pqY2h0Qlpz?=
 =?utf-8?B?Z2NhOEVmNnE1My9Id1g1TEU3SURTTVVZTm5SMmVPbTVjRE82QytIMXNTT1hK?=
 =?utf-8?B?WUNUQjVYSGl2MEJqREdOeHUrWlNIeWhTTFNhNDNNQktMeHZReEpSWHlkcUxN?=
 =?utf-8?B?SE43SUJOaTR5UHRrTWZwQlNGb3AvQVRmTVRUL0gzSDNvanFEaHdDcDZFOXNO?=
 =?utf-8?B?TGkzOW5zOHFQMGNZb2g4eGwwaGkwSS90UWZ0THRwTGJSYjlJREtxQkw0Y2Yx?=
 =?utf-8?B?SEx3d2QyeGVTQm9DZFB5UWdzNlYxdTV6Z0NwSVlLdFBxQjdJSHZ2Z3V2YVdL?=
 =?utf-8?B?YWo1NVlvcno3bVRLbnhOMVBremIzbVZrUmxFUTliT213M3RsMkFDdlo4NU5m?=
 =?utf-8?B?ekJod240TVpHc083eGI0MlRWVUc0UlJ2QkppT2tQak9FckhjZjd3Mm9XbWVT?=
 =?utf-8?B?V3dOeXFIVmxCZUZlQ1JnSVRGbURnT2VrNEtKUVd6Y3g0cHhhbW1majVlaTlx?=
 =?utf-8?Q?xJRGZX?=
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)(7416014)(376014)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jun 2025 09:55:34.6183
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 2877acb6-72f4-4bc0-6511-08dda4e04828
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: CH3PR12MB8849

On Fri Jun 6, 2025 at 8:51 AM CEST, Jan Beulich wrote:
> On 05.06.2025 21:47, Alejandro Vallejo wrote:
>> --- a/xen/include/asm-generic/device.h
>> +++ b/xen/include/asm-generic/device.h
>> @@ -1,14 +1,20 @@
>>  /* SPDX-License-Identifier: GPL-2.0-only */
>> +/*
>> + * This header helps DTB-based architectures abstract away where a part=
icular
>> + * device came from, be it the DTB itself or enumerated on a PCI bus.
>> + */
>>  #ifndef __ASM_GENERIC_DEVICE_H__
>>  #define __ASM_GENERIC_DEVICE_H__
>> =20
>> +#ifndef CONFIG_HAS_DEVICE_TREE
>> +#error "Header for exclusive use of DTB-based architectures"
>> +#endif
>> +
>>  #include 
>> =20
>>  enum device_type
>>  {
>> -#ifdef CONFIG_HAS_DEVICE_TREE
>>      DEV_DT,
>> -#endif
>>      DEV_PCI
>>  };
>
> My objection to these changes remains; as a generic header it ought to be=
 what
> that attribute says - generic.
>
> Jan

It is generic for any architecture where platform DTs exist (that is, anyth=
ing
but x86).

As the commit message states, these guards are useless, provide no function=
ality
and create the fiction that somehow this header is still relevant on an
architecture where only PCI is available. And that's just not true. x86 bei=
ng
the sole architecture without DTs actively overrides it, and relies on devi=
ce_t
(defined as struct device here) to be a "struct pci_dev" instead in
x86/include/asm/device.h, with dev_to_pci() and pci_to_dev() being irreleva=
nt
because device_t* and struct pci_dev* are identical types in x86. Removing =
that
override header is not just a matter of performance. All the IOMMU ops are
referencing device_t, while the drivers are assuming pci_dev, so all IOMMU
code breaks immediately when x86 tries to use this.

To be perfectly clear, this patch isn't strictly required to do DT unflatte=
ning
on x86. But it's a piece of arm tech debt that Xen is better off without.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 10:02:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 10:02:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008326.1387599 (Exim 4.92)
	(envelope-from )
	id 1uNTu7-0001x3-In; Fri, 06 Jun 2025 10:02:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008326.1387599; Fri, 06 Jun 2025 10: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 1uNTu7-0001ww-G9; Fri, 06 Jun 2025 10:02:27 +0000
Received: by outflank-mailman (input) for mailman id 1008326;
 Fri, 06 Jun 2025 10:02: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 1uNTu5-0001wq-Pv
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 10:02:25 +0000
Received: from NAM04-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam04on20631.outbound.protection.outlook.com
 [2a01:111:f403:2409::631])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5772767f-42bd-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 12:02:24 +0200 (CEST)
Received: from SJ0PR03CA0132.namprd03.prod.outlook.com (2603:10b6:a03:33c::17)
 by BL4PR12MB9484.namprd12.prod.outlook.com (2603:10b6:208:58e::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.35; Fri, 6 Jun
 2025 10:02:21 +0000
Received: from SJ5PEPF000001C8.namprd05.prod.outlook.com
 (2603:10b6:a03:33c:cafe::24) by SJ0PR03CA0132.outlook.office365.com
 (2603:10b6:a03:33c::17) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Fri,
 6 Jun 2025 10:02:20 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ5PEPF000001C8.mail.protection.outlook.com (10.167.242.36) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Fri, 6 Jun 2025 10:02:20 +0000
Received: from localhost (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; Fri, 6 Jun
 2025 05:02:17 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5772767f-42bd-11f0-a301-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=TyZnNCqeWhSFYgtKcPaffar21qUXvNsmh2Y3bgiA52cFj7HWP4MlidB+SPbZF463Ww8/HpJpLCUfWnkL+JQnzD+Cli7CbtGKiYJBy0R4M8HRmJKOgOl/SXaxlW6kQtR/oy+5JLJoc9luN6np1omNNjldpbg7Fw5E6RiC+Avrkrw0lj4nlh8HYByXa4SFY6ERiWKnwannuD3AKozjfTwpiUmFd0PGHP3nfzJcO3qdTrPMDtxGjl5xhNgJ+lBmE/wfE9NUC6Jb4fnhLv+eBR9QYZ1kpHeFYpS/0D0WPTm0IfBnQYffrRQ7L0Ry3sZr1DdRCXFmeEE+TDwKRyDdM6KZdQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=xfChG2vv9hSuddW3XR6SAVF6w9YZVG42YBzF3FgoU2w=;
 b=PmMC1VYDz/RUo1zUmkN/p44IBFKyll8BTeSKjFmunxf4BKWZkMU2wyQ9GzOwNtufJx6UQt+QS+l6dHWtIpSQreH2IlADGcJyKcLdKG9WL5J2bBvXcnfKoYhljU+4MIGUSXtgTbLKfvdQKpI6966HIni7q9pwoZx8gmCeHBGOH7ORWT9Cr5SlO7BaXzE8E2KE6XDOduUJ/gR43MrgL5z6MWVN9tsc2g43Ufxdfe6FjVES8q7FBexpaaI22CvZzZaHJ8u/LFnvyRnWJrqI076/kL5CMHXxndXRguw4CYpC4HpoLHD7EQElBBDjkXYoOe0FBD6vB8w4ahOFRXPUiFMB3Q==
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=xfChG2vv9hSuddW3XR6SAVF6w9YZVG42YBzF3FgoU2w=;
 b=XLZSaRXLXonju4VhTdR6oYoHpQ0G9ArAODlCSkwyr7B0Yh4/VIX4yq1VrL2ojyx6pa7MHpJuM6YfjfY4IkDUgD1rv3q5n6Xi1+Esyc/o1QYmUqYCRrNK+kRhjEiE+Oj1IHxK8ND6xOh1cqz6rn4zx7myVoe6DQIxD1eHlHtp3/Q=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 6 Jun 2025 12:02:16 +0200
Message-ID: 
CC: Stefano Stabellini , Julien Grall
	, Bertrand Marquis , Michal Orzel
	, Volodymyr Babchuk ,
	Andrew Cooper , Anthony PERARD
	, =?utf-8?q?Roger_Pau_Monn=C3=A9?=
	, "Daniel P. Smith" ,
	
Subject: Re: [PATCH v2 02/15] arm/gnttab: Break links between
 asm/grant_table.h and xen/grant_table.h
From: Alejandro Vallejo 
To: Jan Beulich 
X-Mailer: aerc 0.20.1
References: <20250605194810.2782031-1-agarciav@amd.com>
 <20250605194810.2782031-3-agarciav@amd.com>
 <765d42ec-a421-4b8c-80bd-30c909e81e8d@suse.com>
In-Reply-To: <765d42ec-a421-4b8c-80bd-30c909e81e8d@suse.com>
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: SJ5PEPF000001C8:EE_|BL4PR12MB9484:EE_
X-MS-Office365-Filtering-Correlation-Id: f318c788-fcb4-4571-c629-08dda4e13a42
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|7416014|376014|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?UW5WVkRjZksxaTVCZkhlSm1iMmlNMWRrWlVZV2Q5bVkzRUJyNUV5a3RrTGtQ?=
 =?utf-8?B?azR3Z1J5ZlNnODM3bXdCS0tWU0JuMVl1bStoUitvUGo4cjdZc25VcTdvWURS?=
 =?utf-8?B?SWQvVjR0VmhhZlJ1R2owQU9PQUs2MDlINlhxWGpHaGkvdnpjdk42NVROU0Rx?=
 =?utf-8?B?ZDFDSGgwNmVtOTJQYkovd2JXcEs5SHZyUG8rM1lXTFhhZDZhaVYrN2VtNGlu?=
 =?utf-8?B?MzUxSXQ1OCtMMU52Z2lwYktPU3QvSkdnQmN6MEFZR3NHcWlUZUhWS1JvM0pP?=
 =?utf-8?B?M08xajNUMU42NFZvb2JwaEdNQ3QyTVpEa2dEV3AzR1JjaG9xVzdEUCtra3lS?=
 =?utf-8?B?SFhRbW5FNHh6eE4wajBsZmhSTTMxN2Q5aUlOV2d0K2RERmdxU05rdXM2M0VF?=
 =?utf-8?B?Qm9lVjNMcXBWbUtER2pvOUxxWEFrdnVBbVpOUzVvOFpFMzA2dXQ5M2FXYWd5?=
 =?utf-8?B?WDgrbjNDSkFiWFNJZ2ZiMG9aY2pQenFrbG9KVjdHdEJobmpkSjgyUnZKWkJi?=
 =?utf-8?B?dG10VXlxK0ZnZkl4MFlNZEVMa2IwVWJKZEtpcU0xb1VFVGYrU2pJQWg0Uytq?=
 =?utf-8?B?ZWZLQlhJY0ppVXJ5UkJLNGFJNVBYUW11czhLeHVIMFc5SWFFaFJKNzhZb0xT?=
 =?utf-8?B?TnNGVzFsZHY5Z0lEa3AwYTl0R1cyZERRdFRVeHkyUHdSakpwZlUrTGkxNFpE?=
 =?utf-8?B?RmFEd2QxSEJsL0I5RURsUUk0YTZUUGNTOE9QaGxWNGtXeVBSYXlsS3FUNUpT?=
 =?utf-8?B?anlnc3FYenR1azZMeDdjM205NzlMS2F5R0xiUzh6ZXZLd1dSSHVwSG1vQ0J3?=
 =?utf-8?B?cy9jNEpsSW5rMzJRL3pwMVNPQTIvcXJSMFdVdlhEdG9mRnNjanpPbHNsM2tZ?=
 =?utf-8?B?MlNFcTlDM0VvSUFpdDhPYTNHUnViNUUxS0pGcU11Mmx3a0R1QWlzYTM0TGV6?=
 =?utf-8?B?dEhicU1LNzVkMXhhdGZ3Y2xqYi82RGdKM1ZhY1doeXhNQkVlOTlDcGNQMWYr?=
 =?utf-8?B?ZmdNd21XekxyTldTS3NGRDc2d3pIK1JsTndzcFRPVDI4M0VrVy9Vd21jMm5a?=
 =?utf-8?B?OTRMcGR5Q00xOUdoaW1CdEc0Q3dKNmptSmdoNUZGUkVvNmg0TzdsQ2QvUW1o?=
 =?utf-8?B?MmdjUldLOUhYeUZMQ3YvUnAvMi9RR09XQTVzeG5hRkZwS0hqOWprZm5qVkNa?=
 =?utf-8?B?OTVyYXB1MkZJSWEyQXowRFU2bEYzQ0c3R1lwL3hPYitzZFAwNGdvUS9ibzR5?=
 =?utf-8?B?YkNKSitQNWQwVmFmUnpkQVRXajVzK3lsTlBPaGZRd3FZS1d3RE53bERTYlcw?=
 =?utf-8?B?NXZPTWdsRWhBdEgzK1l0Z0RsK3RLajl6QjFmRkhhdEJTMk1pUzhKRldlMWVU?=
 =?utf-8?B?WFNvbUV6ODhWd2RBTmg0amZMMnZOOWV3L3pHamxBNlJ2YkdtOWJrSTNrS3lJ?=
 =?utf-8?B?eFFGWUdzOHc0OE04dkFuSGViYzg1MXpiWWxMaTRFUXUwUXBIWUsxczhIbGRR?=
 =?utf-8?B?emxxL213YTNYU3k1QllpVmpONmZIK08zK3M4TXlxTTZWTGpYNGhCOVZsUm1X?=
 =?utf-8?B?dGJQdGFVd290eDhIZ1RET3QvcUJXS1BpTjgra1I3bWV1a3YwbHB6azU5RTZO?=
 =?utf-8?B?aFNlazd4ZkdBd05qTnM4NDMxWGxUT2Y0WjRqRUo0VW1scllNN2dPYVVibEc1?=
 =?utf-8?B?cUpjSDBSUTdzZ05iR3d1UjVZNlJLSXYybW9hVGlhTFUzK0JXRTdrSmFrb1Zt?=
 =?utf-8?B?N2NDTWs0ZUZPcTNuekZaeWh0dUp0NkVpMjBEaVhYcFpkZTJyS0xMZWJFd05x?=
 =?utf-8?B?MXMwWEFGazRROHVkdnVFNEVkSVllVG5jTmdlc0prQnpMeFVFMFZjMVRHbXMz?=
 =?utf-8?B?UVdzeDB4MmdOaTdIdFlnWmxrZVVZWU5hMjRSVkhyS3U0Y2RIWS9KTGErM0tB?=
 =?utf-8?B?c2NUVysxV3ZkVncyK1ArTXFiekd4aTdUNi9zVkRIYUtBL1dpaW9Hbk1GV1Yr?=
 =?utf-8?B?UHhlQmUzcHVvV01QTXFsQlYzUmVGVTJ4bHptb0c0MDlBajdxQUU2UWd0enJZ?=
 =?utf-8?Q?57y5Ii?=
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)(7416014)(376014)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jun 2025 10:02:20.7160
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f318c788-fcb4-4571-c629-08dda4e13a42
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:
	SJ5PEPF000001C8.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL4PR12MB9484

On Fri Jun 6, 2025 at 8:52 AM CEST, Jan Beulich wrote:
> On 05.06.2025 21:47, Alejandro Vallejo wrote:
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -42,8 +42,10 @@
>>  #include 
>>  #include 
>>  #include 
>> +
>>  #include 
>>  #include 
>> +#include 
>> =20
>>  #ifdef CONFIG_PV_SHIM
>>  #include 
>> --- a/xen/include/xen/grant_table.h
>> +++ b/xen/include/xen/grant_table.h
>> @@ -27,10 +27,6 @@
>>  #include 
>>  #include 
>> =20
>> -#ifdef CONFIG_GRANT_TABLE
>> -#include 
>> -#endif
>> -
>>  struct grant_table;
>> =20
>>  /* Seed a gnttab entry for Hyperlaunch/dom0less. */
>
> The description doesn't make clear why these two files need changing.
>
> Jan

What sort of description? I removed a conditional include  and added it to =
one
of the few places it didn't include it already along with xen/grant_table.h=
.

The title does say the patch removes the crossed includes in asm/grant_tabl=
e.h
and xen/grant_table.h.

It's, I hope, self-explanatory regular spring cleanup.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 10:03:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 10:03:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008335.1387609 (Exim 4.92)
	(envelope-from )
	id 1uNTvM-0002V2-V3; Fri, 06 Jun 2025 10:03:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008335.1387609; Fri, 06 Jun 2025 10: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 1uNTvM-0002Uv-SY; Fri, 06 Jun 2025 10:03:44 +0000
Received: by outflank-mailman (input) for mailman id 1008335;
 Fri, 06 Jun 2025 10:03: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 1uNTvM-0002Up-AY
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 10:03:44 +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 871f75f0-42bd-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 12:03:43 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a36e090102so1160360f8f.2
 for ; Fri, 06 Jun 2025 03:03:43 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b2f5f66a622sm888967a12.38.2025.06.06.03.03.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 06 Jun 2025 03:03:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 871f75f0-42bd-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749204223; x=1749809023; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=c8vug/+ZTsi8T4CoWMG4LEtISTJClyp/VV+jTSRjkZ0=;
        b=Vo3FBbSPjKwK5fbSil5dkaUrev/HQvGRIc8c19/UWPw5dle0xMP/qfIvnVmuX7ve7a
         pSgoIW6j/MOFkXEhVuECSIE9fC1A+DF+a6XZGHbdCvrhOiga0zM5fAR7u9ACUb3nwoFZ
         u3IoHedJVZ+neGijDjW3K6KcAzJiDzyN5DhPdkEjF1X5sAqBnTY95Tv1b8Td4qpf/oNw
         4X25aOV+dwC3NV8qHoeRVbLzurpM5QiZKBBYWieaIgeO1KS8N8o3wckr18S3LOqSGqK9
         tAQgkO4cQ3h2qLbAv5Gj8ALMKOb16Lkn6CDUWkJIvFbZWHAo/XkmlAUEKeQ0R0jVcLA1
         6uKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749204223; x=1749809023;
        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=c8vug/+ZTsi8T4CoWMG4LEtISTJClyp/VV+jTSRjkZ0=;
        b=OHauMKtGb36ZZIvcWYsrJy7s8YehrsQ7/cMEUDFPWm3cZ0OCEk/wFh/LRft0dxZ4Ro
         WDc90PLpVwS5kH5ra9aZlNsztm34eIcobUhSUqCPB9dYmZtcEw+FxXQGkFuv0ezaD+MG
         klRwTgFFfqjfc+rvV4XDpcZ5giaAAlmAwftt/k2wQXKnEZ+ktgtTExBxJUSY+tQOrStO
         X49pf+0phRV5m0jOD/JLLYXfzIvPHmLetZlsmGxl6X6tDhk11UPTJ+ixfTGP1ntPh2uf
         SWZIokiXxwbTat8yTt6cK4/FRJ5d1U8X754XP/pgEBtd6MfVabxG18LdaW+2ZV0wWHWA
         0YWQ==
X-Forwarded-Encrypted: i=1; AJvYcCXjqp7hBaya16ZMTeiQL9U7QLcmz1XBPvT0qIHfx9x7s0YK8JT/KfweS0h+l/54ZcB/D7xoT8f8/Gc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxH6DbjTcLaDea3qqYTI7AAeq8YYLcqIJqL6gQMuZsAP0KVibQw
	AuUqM57rde3BdJELMbyCzDaV2rhXh9cBnvoNERBCj46tSqdpD84jOleIv2tfa6Kg3w==
X-Gm-Gg: ASbGncvHGzF0PWIH1Ve/T6kcM9elr4XriQmHCWmSjwPirgVMbMOfaaSdzQmFT+Qi3GK
	A1lQxa31d1aqh2dAZTvH+JWpGVpokdBLmJly5vLTBHdLCXIroaAp0ppx4z+IQNsGwCce46ZkRbx
	0YiNCIFsRMHHhAOzbxWSGZs40rfHX8TUBJLDUw7sBdRnfFSUMyTVPqleleCgSSHIKT/a7sJCFJ0
	J8oe4PR+OQg9tko0pHqrBnne2GG2lPxGgLYs2yAPBOH3xPgb8Wu0oeDJruVfjmpsDqprwKG2/JX
	NTAqdiMtoZCwcLTnOPQKGb7OHtGyKYDpay4sfWGA3lsznaCIgzlH5iHQfGhoH9wYxzeZdFjH4GA
	cwpbYqzEXjOegvU+TRSwflmFLG83GBxWi5zb7
X-Google-Smtp-Source: AGHT+IF0Bk6XCQvcCd9IOYay9d0mIQrpTJgAeJu87lkMcUWIyJ+V72xLHJmoBmQvPN2V1lGZ1n9OKw==
X-Received: by 2002:a05:6000:2484:b0:3a4:d9fa:f1ed with SMTP id ffacd0b85a97d-3a53189aacdmr2422601f8f.13.1749204222594;
        Fri, 06 Jun 2025 03:03:42 -0700 (PDT)
Message-ID: <20e6673b-bf85-4f9d-9938-7005a481b898@suse.com>
Date: Fri, 6 Jun 2025 12:03:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 01/15] xen: Clean up asm-generic/device.h
To: Alejandro Vallejo 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Oleksii Kurochko ,
 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: <20250605194810.2782031-1-agarciav@amd.com>
 <20250605194810.2782031-2-agarciav@amd.com>
 <38104467-fb7e-4aa3-9c78-0f9bf23183eb@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 06.06.2025 11:55, Alejandro Vallejo wrote:
> On Fri Jun 6, 2025 at 8:51 AM CEST, Jan Beulich wrote:
>> On 05.06.2025 21:47, Alejandro Vallejo wrote:
>>> --- a/xen/include/asm-generic/device.h
>>> +++ b/xen/include/asm-generic/device.h
>>> @@ -1,14 +1,20 @@
>>>  /* SPDX-License-Identifier: GPL-2.0-only */
>>> +/*
>>> + * This header helps DTB-based architectures abstract away where a particular
>>> + * device came from, be it the DTB itself or enumerated on a PCI bus.
>>> + */
>>>  #ifndef __ASM_GENERIC_DEVICE_H__
>>>  #define __ASM_GENERIC_DEVICE_H__
>>>  
>>> +#ifndef CONFIG_HAS_DEVICE_TREE
>>> +#error "Header for exclusive use of DTB-based architectures"
>>> +#endif
>>> +
>>>  #include 
>>>  
>>>  enum device_type
>>>  {
>>> -#ifdef CONFIG_HAS_DEVICE_TREE
>>>      DEV_DT,
>>> -#endif
>>>      DEV_PCI
>>>  };
>>
>> My objection to these changes remains; as a generic header it ought to be what
>> that attribute says - generic.
> 
> It is generic for any architecture where platform DTs exist (that is, anything
> but x86).

Here you're limiting things to what Xen presently "knows". I'm sure there are
other architectures where DT is entirely unknown.

Furthermore isn't the work here part of the hyperlaunch effort, where DT will
be introduced to x86? Hence "anything but" isn't quite right either then.

Jan

> As the commit message states, these guards are useless, provide no functionality
> and create the fiction that somehow this header is still relevant on an
> architecture where only PCI is available. And that's just not true. x86 being
> the sole architecture without DTs actively overrides it, and relies on device_t
> (defined as struct device here) to be a "struct pci_dev" instead in
> x86/include/asm/device.h, with dev_to_pci() and pci_to_dev() being irrelevant
> because device_t* and struct pci_dev* are identical types in x86. Removing that
> override header is not just a matter of performance. All the IOMMU ops are
> referencing device_t, while the drivers are assuming pci_dev, so all IOMMU
> code breaks immediately when x86 tries to use this.
> 
> To be perfectly clear, this patch isn't strictly required to do DT unflattening
> on x86. But it's a piece of arm tech debt that Xen is better off without.
> 
> Cheers,
> Alejandro



From xen-devel-bounces@lists.xenproject.org Fri Jun 06 10:08:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 10:08:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008342.1387619 (Exim 4.92)
	(envelope-from )
	id 1uNTzQ-00037L-F5; Fri, 06 Jun 2025 10:07:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008342.1387619; Fri, 06 Jun 2025 10:07: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 1uNTzQ-00037E-CS; Fri, 06 Jun 2025 10:07:56 +0000
Received: by outflank-mailman (input) for mailman id 1008342;
 Fri, 06 Jun 2025 10:07: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 1uNTzO-000378-Qk
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 10:07:54 +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 1bdf9024-42be-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 12:07:52 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3a36e090102so1164451f8f.2
 for ; Fri, 06 Jun 2025 03:07:52 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-7482af3824fsm998040b3a.19.2025.06.06.03.07.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 06 Jun 2025 03:07:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1bdf9024-42be-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749204472; x=1749809272; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=AmikAL5cavKLcJ/8zdC6DtKWA3lk6mN6+P5caqth2G0=;
        b=ND2DtpOfX91kfK1zcgEPNCWK3U35V0a1JEXIFsedfEbYcT8SalpktYLz4ruV4OwQe8
         W+Htjv2OOXV7x94p+uviZUd1TLA3e6VB56yMAhub+jOqdtNiJat3qgH/XLSlEKAV5lYb
         r6id2nfcRdwgcTdIdRfdn5JX6IQcpuKE+24kwXG3SOfQXuVnI4aB7odG/Hxm92QbGjac
         io7WmmuVmQVzk0AZ45kPsJx+G3qKC6Vqr84xP/Wg7ZCy76f5qNgF66DLsxYlYa7VYI/W
         NmOgGnK/JoYz8WU+Tdn6uxuUWZmB0KX0ddREYDKx2DsuphatHgJ4RAIDhoqnubXuQObh
         tNPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749204472; x=1749809272;
        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=AmikAL5cavKLcJ/8zdC6DtKWA3lk6mN6+P5caqth2G0=;
        b=EBQ3tgiu2J7evy0wZBy1slkS1IcwXfXm5d4iTJ3qtiJI1h7fO0HVMiG5TFPOVUnpQ8
         rY0lqcEZiIiZ9cG9TLbtM+VaeewkhepZZSFwj27+34+fiLVCXAJmhpCr8cSEWHYnnjAj
         WMklOwhN9Ua/Locx91t5UJ96/dV4FzUD5f3Z9TRk7qn/Yf8ZZhjHOgpG1jgcqwq35ayx
         Z3ir83gLbTIiReVUvcGvasq6wyTBaQ9mo46PljoufQNCaiB2cv4uysGIUjkvpuwW/75S
         WNIxNm9fZh82bk22hcXMxjmoVvMS0s6OCRyo+gCFcJmJwFD5STx7x3OQk7M2BfP8y5fE
         My/g==
X-Forwarded-Encrypted: i=1; AJvYcCXLJ6/2y+6a+JEK/B/6JHILDXsF19W8dfn2iiFrK6RerHn87d6s47LCJpbYNYpzy+sqxCJWLUy2ZCo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxXGDieXQsKxfxP2UscOJbT+nhB5jBLl62pArFRjIWbMRcEUhio
	TeSh9qzrAa+7DpwG8chZFgO9f3zbXtVhr/USrcTKfcowxHoLa3lmDUBx7LuD0SuL+A==
X-Gm-Gg: ASbGncsehcq2r1DPIOCeon9pfJzNwWrQQqYrvr4oyg44WNqMSvK+GP4puvAiLwf69/d
	IlVUQ/otxpDAaGHaANavZlTzgWUYx60+g3D9m3HSQIu75iEgMh5VLVH/doKDVFUz38jpwb+K9Qh
	csdsbi6ZCwHjZr3nrOJ7JJOrmemPT71mSC43fE6/KM1shmy9KoYUbr7FnsdTsOsNeDZViLrwFJn
	T8qQBLd/i3dXAzdSniXW1nHxb7SlS7qBCKjbDc8/bIozZKFJ6sEMBWSDwywes1rz8E78WVI2iaQ
	Dd/LtkFa/A8BBPJTv6ThlB0IjhEH/biZMg6s5Zzt5O0XWTZcuO9e1pOqG1CH4xdIulqgF2LZO+i
	wyyIy0w4KT5MVLIktbWod8afBv4ugnFeMyaVU
X-Google-Smtp-Source: AGHT+IFeaZmCnY/jHj3OxcFpsPXKvhxf185KrVZvz4XgthDZfpBxzhS2qU93cr3TwnfDNZf2KQksQA==
X-Received: by 2002:a05:6000:2504:b0:3a5:2653:7322 with SMTP id ffacd0b85a97d-3a53188a710mr2531258f8f.3.1749204472287;
        Fri, 06 Jun 2025 03:07:52 -0700 (PDT)
Message-ID: <66d75dad-4407-4b09-8dd3-c61b5d05ed91@suse.com>
Date: Fri, 6 Jun 2025 12:07:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 02/15] arm/gnttab: Break links between
 asm/grant_table.h and xen/grant_table.h
To: Alejandro Vallejo 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org
References: <20250605194810.2782031-1-agarciav@amd.com>
 <20250605194810.2782031-3-agarciav@amd.com>
 <765d42ec-a421-4b8c-80bd-30c909e81e8d@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 06.06.2025 12:02, Alejandro Vallejo wrote:
> On Fri Jun 6, 2025 at 8:52 AM CEST, Jan Beulich wrote:
>> On 05.06.2025 21:47, Alejandro Vallejo wrote:
>>> --- a/xen/common/grant_table.c
>>> +++ b/xen/common/grant_table.c
>>> @@ -42,8 +42,10 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +
>>>  #include 
>>>  #include 
>>> +#include 
>>>  
>>>  #ifdef CONFIG_PV_SHIM
>>>  #include 
>>> --- a/xen/include/xen/grant_table.h
>>> +++ b/xen/include/xen/grant_table.h
>>> @@ -27,10 +27,6 @@
>>>  #include 
>>>  #include 
>>>  
>>> -#ifdef CONFIG_GRANT_TABLE
>>> -#include 
>>> -#endif
>>> -
>>>  struct grant_table;
>>>  
>>>  /* Seed a gnttab entry for Hyperlaunch/dom0less. */
>>
>> The description doesn't make clear why these two files need changing.
> 
> What sort of description? I removed a conditional include  and added it to one
> of the few places it didn't include it already along with xen/grant_table.h.
> 
> The title does say the patch removes the crossed includes in asm/grant_table.h
> and xen/grant_table.h.
> 
> It's, I hope, self-explanatory regular spring cleanup.

Then I'm sorry, to me it isn't. "Break links" has an entirely different (file
system) meaning to me, in the common case. Plus that says what is being done,
but not why. And it's the "why" that I'm seeking clarification on. From your
response to my remarks on v1 I was concluding that the issue is that in a few
places asm/grant_table.h would need including additionally. I didn't expect
any #include to (need to) go away.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 10:09:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 10:09:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008346.1387630 (Exim 4.92)
	(envelope-from )
	id 1uNU0a-0003ZU-Oy; Fri, 06 Jun 2025 10:09:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008346.1387630; Fri, 06 Jun 2025 10: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 1uNU0a-0003ZN-Lc; Fri, 06 Jun 2025 10:09:08 +0000
Received: by outflank-mailman (input) for mailman id 1008346;
 Fri, 06 Jun 2025 10: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 1uNU0Z-0003ZF-Bo
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 10:09:07 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20609.outbound.protection.outlook.com
 [2a01:111:f403:2416::609])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4719aa92-42be-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 12:09:05 +0200 (CEST)
Received: from MW4PR04CA0380.namprd04.prod.outlook.com (2603:10b6:303:81::25)
 by MN2PR12MB4141.namprd12.prod.outlook.com (2603:10b6:208:1d5::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Fri, 6 Jun
 2025 10:08:59 +0000
Received: from SJ5PEPF000001F2.namprd05.prod.outlook.com
 (2603:10b6:303:81:cafe::f0) by MW4PR04CA0380.outlook.office365.com
 (2603:10b6:303:81::25) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.31 via Frontend Transport; Fri,
 6 Jun 2025 10:08:58 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ5PEPF000001F2.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.8792.29 via Frontend Transport; Fri, 6 Jun 2025 10:08:58 +0000
Received: from localhost (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; Fri, 6 Jun
 2025 05:08:56 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4719aa92-42be-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=oC47nUlXDQAKHr8TOlVZHVU4py0hjJCLYAUpQM4viMsrJoWG4nf674fy6xTi5Ep4fMVLPzdBuoB7Dpgi1FcEiPfRPP+75W/w5p6yiBUdaNRQCp+WkdExhB8NxOtkbDCxqkUzAtyr0ctl4c3Dvd9DaVxnbrXCaH0BaPu/jitb/0XbwiWv0zSrJ7vVpxdOodwHtGNtaPjBdwTihl++FMoCyFh8FpSAGqZb0/LZjFXpL5zQIyXqldujFQ4OxvmVoUNvYvazNsbNuogw5W+3ajN0Tl1E2I6tr4M/C0GlpQyrjfxGtyi3L3kKzGL90X+Ff644Bq9uRsYprUcyDXC7ULfnCA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=lx3IxXBN5k5RcDcTzIpFvym+VVOBpMuufrYqlv1pobs=;
 b=p+7V5wy376wWdzq3tMn0By1Mb8Af+EAhtyhIYI7vYR2G6MZpp6ptCnw1vsT3hYuGgyxEXVxNcI/hWY2syET5eORuGkQDvuwi8/D3k1BZAxBFv+xAWO9U5E9VmUfVBOZZ512eCxSWxwsbZ4zcysml5G4CylnQ89kzVBkkvjoIA20cKpitb0HjFKhv1CxUpr82Ew/ovcFYh5ZEqx9v9XVIgzWjs+d8Np7zYkqgjld5QzUrSbjygSA3tsm/JMamrpdLwDM9U3Pg5ed0ZpA5ylPdn5QyYFFNF0mfo1d/13lZlQvOp/l2qR4k/XKHUehRrJrBWelCbOryhjmF6PGULMkEBA==
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=lx3IxXBN5k5RcDcTzIpFvym+VVOBpMuufrYqlv1pobs=;
 b=JL3dbiT+qFtDTyJmrsc5H4L2mtz6x55I9GnU0Wiozm+NvkrTNbcz8nBXx85yULylZaajLvcJWq67Lwg+/jb8H7A4ohYNWCLWYbOYF/1YwbbDh2wnXC9BKJUzz9X39cOrN3MS9p+e6N5q/9J2a1PGl1yvz/uG0fI+udWRjyp3R4Y=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 6 Jun 2025 12:08:54 +0200
Message-ID: 
CC: Stefano Stabellini , Julien Grall
	, Bertrand Marquis , "Volodymyr
 Babchuk" , "Daniel P. Smith"
	
Subject: Re: [PATCH v2 08/15] xen/dt: Move bootfdt functions to
 xen/bootfdt.h
From: Alejandro Vallejo 
To: "Orzel, Michal" , 
X-Mailer: aerc 0.20.1
References: <20250605194810.2782031-1-agarciav@amd.com>
 <20250605194810.2782031-9-agarciav@amd.com>
 <633ffa7f-cf26-4ec3-a153-28404c39d882@amd.com>
In-Reply-To: <633ffa7f-cf26-4ec3-a153-28404c39d882@amd.com>
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: SJ5PEPF000001F2:EE_|MN2PR12MB4141:EE_
X-MS-Office365-Filtering-Correlation-Id: c822ac83-a4b2-4283-a9eb-08dda4e2272e
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?OFlHRXhjRHdEZi9JZXpsYXREMzIwajdRYUFKemV3amR4UWRqR294bEhKbjBk?=
 =?utf-8?B?aVNqMTF6czZ5TWFMV0orZHVVMVZPRVVkeEZKcCtzNVZjSHgyVHo5Q0ZEbVFq?=
 =?utf-8?B?Z0llZDltbUFhVCs0Z2pnS0ZJL242MnErSTNIU2VKVEJTYndyd2Y1YjU4YVN1?=
 =?utf-8?B?bmRHWGF1M1JSZ2dsb0JER2VmalcwY3Q0NnpMVWRZbDgveUdEeWt0dnJYOG1h?=
 =?utf-8?B?VE1TRXZTdk84RUFYMHdqRGRzVzVnK2NLN2lLL1J0d2lsQlQyRG9CSCtQMmRt?=
 =?utf-8?B?ZEFVUXVvOXNzY1dYdGJmUFp1L0tWcWFlbVBBcWdYWXhXMWc2c3VLUnNHUVN1?=
 =?utf-8?B?alc1ZmRtOG0rUUkyZCtOU0xDa050cDd5S0ZpNVZwU0dXRGlacWZaOWhlVkZ5?=
 =?utf-8?B?QTZwKzVqTzRKOThFQ1dyNENYdkUzR0tEMTN3WHFTR0JBdkxFTU5kTnMvQktr?=
 =?utf-8?B?VkFRNS9qSVpoZzlXcFRTMDFla2JubFMxOTR0a2pyQmwwOEF1Z2NWS2hyU0wv?=
 =?utf-8?B?OTZScDVGNkg0NUtUTDd6TGErVFVvUzF0bnVZVzdBYTZDaERvNEVNUW16cUxj?=
 =?utf-8?B?Z2xxUzVTZmloRDdkbFJQWjN3cGNCY2dJcXNOTVdHNm1MQ3hYOHFYWXRVSUtL?=
 =?utf-8?B?RUZyU0o4RkZCYzErTjVrTFNMMXAwL1VjNVRmN1Y2elhSNHg4cDlXbjFNbFF5?=
 =?utf-8?B?QzV2cVhMWWJqQytnTWlYd0YzTzdhNUhCY1lLdWtYeEYrZGROK3dONkd3Tlox?=
 =?utf-8?B?Tm1TMDBuZ1RVL1NHaHk1c1FjajV0eVN6eEk2Z0Jhc0hBNzQ5NlhxRUpYWDZS?=
 =?utf-8?B?SHU1TW1ranpEYWRZUXBlckFGOWFuRTl5SWdoa0VSRFBFa0dmcEI1M0VNWjBu?=
 =?utf-8?B?VUw1VFdPQm1ycmdrRWExY3JTYUIxUGlXTnd1cHpTTW9ONXArME9IT3dkc1R6?=
 =?utf-8?B?YmNlZFZDL2NZWTJldmtiemxCMmpzZTRVS0RyQVd6YmQ5MGRZQ3Ewa2lUWGVl?=
 =?utf-8?B?Y1VJVTFZam83L2pSVnZrbGZlU2FSZmJ2VkZ4ZWlSZzR2S3dSQ21SUHMyWlFi?=
 =?utf-8?B?YkJidFpKNDIrSWF4cWpUOURQbDdJK1pZZm1uZmNqRWlsWndrb0pJbmFRbDVZ?=
 =?utf-8?B?WXZCWWFQMHhrQlBTV1E2d0dEZzNQRWY4WFJlODJyMlFRUEdWZ2RTd2F1NWN6?=
 =?utf-8?B?Q3ZCSTd2a3IvNTN2UWEwcFBYNU5Yekt5Q2dJZEMrUkJLYlR6eVFlYm5pZktK?=
 =?utf-8?B?UDkwQWI5a3dJR1ZUeGt6Y3VaVC9kMCtTUGJjMW1MNkw0djh1OE1rNjBzM2NJ?=
 =?utf-8?B?Qm9aVE1wbk45emppSFZaaUxjK05YTGRxRzdDZmRmRVhtQjNCdHJ2N0tONGs2?=
 =?utf-8?B?N2JiUUQ4K1d3Mmkvd2Q4bm5vMDdLQ0tEVkVlRkdNTC9mbE9vN3BzMEp4R04z?=
 =?utf-8?B?dEs5bWpGUWR1K3pEczkzaXBSQTZ4eXlBcXRqQk9ab2xHYWxJenBTWkxKTGRz?=
 =?utf-8?B?V0Q2VW1ndTYxZCtpTFQ2d1Zod0p6NEd3RW9udlFla0REVGo3SXJqV052dkF2?=
 =?utf-8?B?bjRRK2g4RmRCaVg0cVlQeUt2ZmRTUlM1RkUwV3JYNllmWVdGREFlZ3pwVHRo?=
 =?utf-8?B?Uys0cUEzTFVTcW9CYm9JRmNuRm9nWkdrNHUyQkpHcXlwbllNOXRoVndTT1FF?=
 =?utf-8?B?S3FSanM3eHhEMEZPeWlhVFNDSVVaM3FiWHo4eGFxejJsUm1ENStaeVpIRUky?=
 =?utf-8?B?YTN0MUJNdzJLNFFRa3dOTzJLZGRDNktGL1BJWFkva0RtY01YYitiUDFSL1ln?=
 =?utf-8?B?WDAxdmNhVm5zNFZ4UG9YRFY2aGhwMk8rOU95dWtWamtSbFVOZVY2SXp3cS9h?=
 =?utf-8?B?SzJNUDROTFpsUFFLdUp4bUpXYmp3SUs0WlY0Z2VHSXd5aE1YV1o2Y1drQ09k?=
 =?utf-8?B?UW9oZlR1L2NHZSswTk41OHJQaXIyY2J4M1NqU0w1RkNoMDdpKzR6MzhXZ1lr?=
 =?utf-8?B?WUhrU1BaUVdlMEFkMWxiOHZ3MjNhaU5ha1dScVEzbkw4eUtPUXllYy9lLzdS?=
 =?utf-8?Q?b/8Jif?=
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: 06 Jun 2025 10:08:58.2060
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c822ac83-a4b2-4283-a9eb-08dda4e2272e
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:
	SJ5PEPF000001F2.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4141

On Fri Jun 6, 2025 at 10:59 AM CEST, Michal Orzel wrote:
>
>
> On 05/06/2025 21:48, Alejandro Vallejo wrote:
>> Part of an unpicking process to extract bootfdt contents independent of =
bootinfo
>> to a separate file for x86 to take.
>>=20
>> Move functions required for early FDT parsing from device_tree.h and arm=
's
>> setup.h onto bootfdt.h
>>=20
>> Declaration motion only. Not a functional change.
>>=20
>> Signed-off-by: Alejandro Vallejo 
>> ---
>> v2:
>>   * Remove the u32 identifiers in the device_tree_get_u32() implementati=
on
> I don't understand the reasoning behind changing u32->uint32_t only for o=
ne
> function in this patch while leaving others unmodified. Also what about u=
64?
> Either don't change any or change all.

Sure. Let's call the original u32->uint32_t change a misplaced mutation and
move on. The point is the motion, not these cleanups on top.

>
>>   * Fix an existing const-stripping case.
> These points should be mentioned in the commit msg.

Sure.

>
> ~Michal

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 10:12:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 10:12:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008359.1387640 (Exim 4.92)
	(envelope-from )
	id 1uNU3C-0005SC-3l; Fri, 06 Jun 2025 10:11:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008359.1387640; Fri, 06 Jun 2025 10:11: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 1uNU3C-0005S5-1C; Fri, 06 Jun 2025 10:11:50 +0000
Received: by outflank-mailman (input) for mailman id 1008359;
 Fri, 06 Jun 2025 10: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 1uNU3A-0005Rm-Ho
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 10:11:48 +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 a744b4c1-42be-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 12:11:46 +0200 (CEST)
Received: by mail-lf1-x131.google.com with SMTP id
 2adb3069b0e04-5534edc646dso2113755e87.1
 for ; Fri, 06 Jun 2025 03:11:46 -0700 (PDT)
Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-553677389d5sm143592e87.259.2025.06.06.03.11.44
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 06 Jun 2025 03:11:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a744b4c1-42be-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749204706; x=1749809506; 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=m/d5gb5VGmAwDho9Wku4Y6/OMgxq0De4Fzf9ZgJsnJk=;
        b=V8rH0zTFZyCf5vv1tTjLDsRdJ/5cF+JVpBuZvlkC0Rn4gLee3e7+gqGtEDpFzwHVUS
         6AmQ7TLeVkb9PhHND5NXtizVAIirKiAcw2PnH0mKJgPI8au5g2G8w2qbwZ/1SMI1GrKb
         Va3rc+aTEbjy1pniKg8NgLv6BDD8A1AHn7184oc1gXYdUPBijt+ponDaU/ocTQ/KLtE2
         OtfkvULnGGzRR8eo49CTO2DSswe7Kdugv+5fjGkj12K8j+OjPgj+8o86HyQCPdv3A029
         62gnhaWFUVJH8iqyRfr0aQeWF7t/nvpzt/c4U2RmDW0SaSaHEc5JvxsVxIDtw/6Xuuzq
         prTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749204706; x=1749809506;
        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=m/d5gb5VGmAwDho9Wku4Y6/OMgxq0De4Fzf9ZgJsnJk=;
        b=uPKG6+Hy/3e4Nlq0tfm0oee1uq75nKXtbESnPGOXME1R2uTDb/txS46GEDYblyJ/Kp
         mV1PvLNTkkYTTJOSovWhl7xx+DgXofTUyDGIg2HNRvlzNEeE+tCkTjypQb9if/VrBEDL
         xngq8gJwSId/kgWNRc3mHw3VDnTGoFn2MpqcMdcBEOeYLKIKRti1GXy/t/7ClDz4dcaC
         J9F1iEmZBqX5jC70zr0lU/KYGLM1bEfZYoy34wf7uuc/4f0SPHxxfwSzbDaFnQoqoY/q
         XRZ77sO1yfyhhuuUs7/mYkedh+P+Xhzvc30KhOWktMfqpQn3LBnYwl4K7zw+SOryj/J5
         ul8A==
X-Gm-Message-State: AOJu0YzF9ofkiONBCwLFjRxPwI2OgFuy6BgLX0qV9tqqvJtHa1eijnZz
	goobqiwRzl3Ma5Ea+uLUUaGdNfGYORP7rCccN0B+KofasakVuXxgm4TLxTVDLKRl
X-Gm-Gg: ASbGncv8FZOvKWzR8BYiyehSITngKfp6n2S7wB3tuY+g9MwsR0oBCkYjxcEHHWmR0dJ
	BwEaWo602W4GwagWvqiPJSzR1I2Yq4cPASX5khQFTP2xI5scN0/iGxX7NSNRs1l6oAlpTfB7Y2D
	uGjYL9r/U6tE2nEgKl0/YShn77V9OtO97bnVIW2tmlCEehYkwu3COpgDGO4Uqpjy6ye37pSPPQQ
	CrrsBcBKidcwx9Tav36IJDWbSQE+/0sqB/CBXKRBRtXeftHQMkokweIuJFZHUmBruERoSZThKLW
	wHfGqrnj3A/2jZOwJxfAIyAKsIor7rIkSdu6zoqZvhWMEb7ILIp3Ua+cAx9+9qsDEDgRENJif37
	bVACPEclBa+ecNlHQIE5meRTy8oLd93teR+yb
X-Google-Smtp-Source: AGHT+IH99V9BjKSR+AsHPLn+5vRM1Boboc/C8z0N2fXx8O+FRBuz18cAvL4urRI1t9gUSkeCHNtbLQ==
X-Received: by 2002:a05:6512:3a94:b0:553:2f47:ed21 with SMTP id 2adb3069b0e04-55366c0e640mr693268e87.41.1749204705504;
        Fri, 06 Jun 2025 03:11:45 -0700 (PDT)
From: Mykola Kvach 
To: xen-devel@lists.xenproject.org
Cc: Mykola Kvach ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	Stefano Stabellini ,
	Bertrand Marquis ,
	Volodymyr Babchuk 
Subject: [PATCH v3 0/2] Add CONFIG_SYSTEM_SUSPEND and SCIF UART suspend/resume handlers
Date: Fri,  6 Jun 2025 13:11:40 +0300
Message-ID: 
X-Mailer: git-send-email 2.48.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Mykola Kvach 

Hi all,

This patch series introduces CONFIG_SYSTEM_SUSPEND to Xen and implements
suspend/resume handlers for the SCIF UART driver. These changes address
feedback and discussions on the Xen-devel mailing list:

    https://lists.xenproject.org/archives/html/xen-devel/2025-03/msg00169.html
    https://lists.xenproject.org/archives/html/xen-devel/2025-03/msg02188.html

I am marking this series as v2, as it is a logical continuation of the
discussion linked above regarding the SCIF driver changes.

Patch 1:
  Introduces the CONFIG_SYSTEM_SUSPEND infrastructure, which enables Xen to
support suspend-to-RAM functionality. It adds three new Kconfig options:
    - HAS_SYSTEM_SUSPEND: Indicates whether the architecture supports suspend.
    - SYSTEM_SUSPEND_ALWAYS_ON: Forces suspend support on platforms that
      require it (e.g., x86).
    - SYSTEM_SUSPEND: The user-facing option to enable suspend support,
      enabled by default when SYSTEM_SUSPEND_ALWAYS_ON is set.
      
  This approach is intended to be easily extendable to other architectures in
the future.

Patch 2:
  Implements suspend/resume callbacks for the SCIF UART driver. These functions
ensure proper shutdown and reinitialization of the UART hardware across
suspend/resume cycles. Their inclusion is gated by the CONFIG_SYSTEM_SUSPEND
option.
  The SCIF suspend/resume functionality has been tested on the Renesas R-Car H3
Starter Kit board.

  Compared to v1, the main change in this version is the addition of a
CONFIG_SYSTEM_SUSPEND check around the SCIF driver's suspend/resume logic.

Changes introduced in v3:
- select HAS_SYSTEM_SUSPEND from SYSTEM_SUSPEND_ALWAYS_ON
- drop selecting HAS_SYSTEM_SUSPEND from X86
- simplify default setting in SYSTEM_SUSPEND
- hide prompt of SYSTEM_SUSPEND when SYSTEM_SUSPEND_ALWAYS_ON is enabled
- move HAS_SYSTEM_SUSPEND alongside other HAS_* configs

Best regards,
Mykola Kvach

Mykyta Poturai (1):
  xen: Introduce system suspend config option

Volodymyr Babchuk (1):
  xen/char: implement suspend/resume calls for SCIF driver

 xen/arch/x86/Kconfig         |  1 +
 xen/common/Kconfig           | 18 ++++++++++++++++
 xen/drivers/char/scif-uart.c | 40 ++++++++++++++++++++++++++++++++++--
 3 files changed, 57 insertions(+), 2 deletions(-)

-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Fri Jun 06 10:12:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 10:12:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008360.1387650 (Exim 4.92)
	(envelope-from )
	id 1uNU3D-0005g9-ED; Fri, 06 Jun 2025 10:11:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008360.1387650; Fri, 06 Jun 2025 10: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 1uNU3D-0005fy-BN; Fri, 06 Jun 2025 10:11:51 +0000
Received: by outflank-mailman (input) for mailman id 1008360;
 Fri, 06 Jun 2025 10:11: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 1uNU3B-0005Rm-Hk
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 10:11:49 +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 a8aeaa0b-42be-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 12:11:49 +0200 (CEST)
Received: by mail-lf1-x12c.google.com with SMTP id
 2adb3069b0e04-55365c63fa5so946653e87.1
 for ; Fri, 06 Jun 2025 03:11:49 -0700 (PDT)
Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-553677389d5sm143592e87.259.2025.06.06.03.11.46
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 06 Jun 2025 03:11:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a8aeaa0b-42be-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749204708; x=1749809508; darn=lists.xenproject.org;
        h=content-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=9dWxP7Icxj1+b68Zu3OZEwOOJEHkIKPApD7TkfsOeh4=;
        b=NWnFApOn6agP8AoJCRiexbt3oZuRnUVeB0Yv9rRmn/uFgZscNdmpOt3CCygmVV7bev
         5g3co1JWI963iab/o8ZmjQ//TQZvshu5chxTKLJ0LdLpsBiopLI1uMpkUT8+txw2KB7Q
         6mr9FlerLBxVIKfrZWB49P88lEiZDadfVAgMwqy9M1Uf7/9son1ACSqH+xcpO3EGozUc
         1cLcvUtFejT5cPJ7278QzKaoiEa0MeSesffI3jEd3Gnl19X5/vCba0RViHKTT17qFhmB
         H0ZEHs8bfqpWWxTVgUOYxTmhoIxWSKtIaRwP579BC8ZVzNjLCBi8JrOBGMBXUbRmCYKJ
         9i1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749204708; x=1749809508;
        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=9dWxP7Icxj1+b68Zu3OZEwOOJEHkIKPApD7TkfsOeh4=;
        b=Eeor0SkvFT8+bxN4gc7S8Bi58RVzYbFB7yLuyL8+voPWmA1xyI+0LYIYX9fTqJtqQ5
         CkpwxfXhmUGg2VF7HHrL4W3CXJ1m6RawaDeW2/xnyQx1roydBIszZaLNteU+E+xAkbwO
         dS2ILkr3kOyvAAQQykfqFlR5d8JWI/YLdYym7pOcPpD546kY+GwQcxQQrkHVSn8z1Hr2
         oP9wkPxyfGn4OAD0sl0gh1ORq/LZ7vvfFYUvPVWe7yes/7bEZ5OnDJoWQneM8NXUKOXB
         fL+bMWlojS0jsrvEyTBO7xvyueDh7CasunG50xIKtxhwl29wno8yXOz+S/+TMlY8ngTZ
         7gUA==
X-Gm-Message-State: AOJu0YzYGNrZutouLcWVMa01nkIbF0qHg7ycEc2bPh8dgO6ac3ucuEw/
	N/YRbVcTpkjaPH1HCJgo79MJk1ILduuEIPRyrWwb/yQLJNv7VEizKLg4hJrv7VKJ
X-Gm-Gg: ASbGncsX+62RGZ+NdUY/GYfs1vyp7ETgLG2T5uJQlM2Wpz7tyzVuGnqTIjnQ2oshNUL
	i49lZKG1Us4zLm9PF1pa1y+I0eAr9pJpDNBS6jwZpm0n3Jh1tDXlTIDxwO/u2ScuguYr6Cea54Y
	Xknt1Q/WpIXHnpaP6F+WDQ06tIoU+2F16VZ72OyEDWS7ODd/+MZMtQyczwz0ugyhnq+H5oFKsNh
	KcmKhYCK51DYg68tealsMpokVF++xhfGKUE5DJb5Yp+XfFN81yViMgmZJm2VmpvLLcaYlhOdo0f
	qRfgGWBO/+ye9ozBXycF7veKs16+VINXqpsqOSu9WUIZEvQZ9txeEGkosGTsxb0HXlFgyuRhWM7
	WQ5t5fPdgAd8nWUsA9bFIqKzMwQ==
X-Google-Smtp-Source: AGHT+IFtTWG82lj9kW60Ux7/zGpH+k9xbSgOEp6QEHnyKcsn4vfhrvxUPy+hETCT0HhwTVgiuuYEFw==
X-Received: by 2002:a05:6512:2345:b0:553:2dce:3abc with SMTP id 2adb3069b0e04-55366c38984mr725671e87.50.1749204707935;
        Fri, 06 Jun 2025 03:11:47 -0700 (PDT)
From: Mykola Kvach 
To: xen-devel@lists.xenproject.org
Cc: Volodymyr Babchuk ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Oleksandr Andrushchenko ,
	Mykola Kvach 
Subject: [PATCH v3 2/2] xen/char: implement suspend/resume calls for SCIF driver
Date: Fri,  6 Jun 2025 13:11:42 +0300
Message-ID: <3be3369910ec5159eab3cb26155da645dd1df83b.1749204282.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.48.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Volodymyr Babchuk 

The changes have been tested only on the Renesas R-Car H3 Starter Kit board.

Signed-off-by: Volodymyr Babchuk 
Signed-off-by: Oleksandr Andrushchenko 
Signed-off-by: Mykola Kvach 
---
In patch v2, I just added a CONFIG_SYSTEM_SUSPEND check around
the suspend/resume functions in the SCIF driver.
---
 xen/drivers/char/scif-uart.c | 40 ++++++++++++++++++++++++++++++++++--
 1 file changed, 38 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/char/scif-uart.c b/xen/drivers/char/scif-uart.c
index 757793ca45..888821a3b8 100644
--- a/xen/drivers/char/scif-uart.c
+++ b/xen/drivers/char/scif-uart.c
@@ -139,9 +139,8 @@ static void scif_uart_interrupt(int irq, void *data)
     }
 }
 
-static void __init scif_uart_init_preirq(struct serial_port *port)
+static void scif_uart_disable(struct scif_uart *uart)
 {
-    struct scif_uart *uart = port->uart;
     const struct port_params *params = uart->params;
 
     /*
@@ -155,6 +154,14 @@ static void __init scif_uart_init_preirq(struct serial_port *port)
 
     /* Reset TX/RX FIFOs */
     scif_writew(uart, SCIF_SCFCR, SCFCR_RFRST | SCFCR_TFRST);
+}
+
+static void scif_uart_init_preirq(struct serial_port *port)
+{
+    struct scif_uart *uart = port->uart;
+    const struct port_params *params = uart->params;
+
+    scif_uart_disable(uart);
 
     /* Clear all errors and flags */
     scif_readw(uart, params->status_reg);
@@ -271,6 +278,31 @@ static void scif_uart_stop_tx(struct serial_port *port)
     scif_writew(uart, SCIF_SCSCR, scif_readw(uart, SCIF_SCSCR) & ~SCSCR_TIE);
 }
 
+#ifdef CONFIG_SYSTEM_SUSPEND
+
+static void scif_uart_suspend(struct serial_port *port)
+{
+    struct scif_uart *uart = port->uart;
+
+    scif_uart_stop_tx(port);
+    scif_uart_disable(uart);
+}
+
+static void scif_uart_resume(struct serial_port *port)
+{
+    struct scif_uart *uart = port->uart;
+    const struct port_params *params = uart->params;
+    uint16_t ctrl;
+
+    scif_uart_init_preirq(port);
+
+    /* Enable TX/RX and Error Interrupts  */
+    ctrl = scif_readw(uart, SCIF_SCSCR);
+    scif_writew(uart, SCIF_SCSCR, ctrl | params->irq_flags);
+}
+
+#endif /* CONFIG_SYSTEM_SUSPEND */
+
 static struct uart_driver __read_mostly scif_uart_driver = {
     .init_preirq  = scif_uart_init_preirq,
     .init_postirq = scif_uart_init_postirq,
@@ -281,6 +313,10 @@ static struct uart_driver __read_mostly scif_uart_driver = {
     .start_tx     = scif_uart_start_tx,
     .stop_tx      = scif_uart_stop_tx,
     .vuart_info   = scif_vuart_info,
+#ifdef CONFIG_SYSTEM_SUSPEND
+    .suspend      = scif_uart_suspend,
+    .resume       = scif_uart_resume,
+#endif
 };
 
 static const struct dt_device_match scif_uart_dt_match[] __initconst =
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Fri Jun 06 10:12:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 10:12:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008361.1387655 (Exim 4.92)
	(envelope-from )
	id 1uNU3D-0005il-Nh; Fri, 06 Jun 2025 10:11:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008361.1387655; Fri, 06 Jun 2025 10: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 1uNU3D-0005iC-IT; Fri, 06 Jun 2025 10:11:51 +0000
Received: by outflank-mailman (input) for mailman id 1008361;
 Fri, 06 Jun 2025 10:11: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 1uNU3B-0005Rs-KU
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 10:11:49 +0000
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com
 [2a00:1450:4864:20::236])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a7f2526a-42be-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 12:11:47 +0200 (CEST)
Received: by mail-lj1-x236.google.com with SMTP id
 38308e7fff4ca-32ac52f78c1so20381081fa.3
 for ; Fri, 06 Jun 2025 03:11:47 -0700 (PDT)
Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-553677389d5sm143592e87.259.2025.06.06.03.11.45
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 06 Jun 2025 03:11:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a7f2526a-42be-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749204707; x=1749809507; darn=lists.xenproject.org;
        h=content-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=7hPQ4VxBdVLnFqUBMXQnHxRKZBnEmnRXk//zaua6W64=;
        b=G2rmIWx4KAYDgvDdM626qRTYuIsOZJIiY9y6odYDCBRI1emvvtPv49LxKuanablqjk
         wYjbIAvigMtjNheuq2KMbhFfiDWfsR49Z4HB+i2LzBCtIC4pW5dog+mu08gKax8zsEoX
         ReYz1PwqZ2sW3Y3XGokyjMCAOFV6iqPmee5ZINIGgIf0mE2/uIz4081aaLjiJ/3lcpw0
         xr94sbtGUKyQbf6OYZhRulBOQ9Y606W6u8VR392ZMxFEGednYSUzJVtwI0W8TAbYMkNX
         lWl4nmMcENvUu1n4Yf9ssbKV7Tt7moFYigFEWvVpgsLInw1Ivst1RrMUPSNUXD9I3Oq+
         CHWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749204707; x=1749809507;
        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=7hPQ4VxBdVLnFqUBMXQnHxRKZBnEmnRXk//zaua6W64=;
        b=JvXBGoCtamkGRMmiCAVE3TSFOAZd3i+PQLkf7NBBAG8imFgl4GdYIgZg9u8aVmRmy6
         woTjsqIRv4MWLmJ//3GpFQsp3J1sVDzAYc1nWC2VSO/WTjS+m+m4TGRPhx/gS264aHOy
         hclN/HDO8awPTs8cGlqvoiybc+bH9BGa/S9xAo8rkdfA8LANY5TCa2L0rUNaXNi723Zx
         T6HtbiUz0vhPDTNl1bPlVe9EaWBS0d8LJAWdZKTxZDodiX8QSSs3wiZjJMDdAWWUAio0
         hSxpFKdgBVbJSGzfzbbXgHfu3x5+LAC5OXgF4YCe7nlHAVUk+9wZs5q0f5NipxeeVt95
         JjIA==
X-Gm-Message-State: AOJu0YxtIzpxspIT4cPdROwMd7K8g0MtUjSj1hNa5D6NAZFfCPJw6jMp
	dEstY2xhGeBTkHxE6YF3LX3zeKChK76PpDz6QgkblWTopvVbGQ8lp6qy33bndNMF
X-Gm-Gg: ASbGnctR/7dIh3dQRnjUvlpXjMa7KbCBp1GAxdn3nc3GVQVN5cvt3odw7g1yCYD39r1
	ZYiB4DccrLy8uLlSWdyRBrmAVucqGHgBqad2NihducWgUiJrtYHs0FrOLQIwqf1eh3RMyNPDi1G
	iBPcOLduQihqyQpHPA1meX/djqcYJtVk6aqZWXF0y6T4a5MXJz9J0wOuZ2LGZoGxwxuhsafcNbj
	Wm2fIMgExwPQJI468eI9JkIzzG33qkKYRjYB+3tawoY/pOZkHNzONa6f7G3HrfwuiWw3ZjnAsQ5
	Olm77dw5y8O+7npg0Xzc4xZ1UrHLV1gfcQ/sxyjH2b8fVXLKQk4kQXFJWkYwq+WNvIMs+rryL0g
	/yiZJmlViA0Saund+UNvPrW/ENg==
X-Google-Smtp-Source: AGHT+IHcPVMXpXDFxKZ1ggDEsOO/oqjCw4oEwbGk6ItH8L5RwFF1woqnv9iCGDdBGtqaQdLse2gqFg==
X-Received: by 2002:a05:6512:ba7:b0:553:27cb:b84e with SMTP id 2adb3069b0e04-55366c2ff7amr779327e87.41.1749204706738;
        Fri, 06 Jun 2025 03:11:46 -0700 (PDT)
From: Mykola Kvach 
To: xen-devel@lists.xenproject.org
Cc: Mykyta Poturai ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	Stefano Stabellini ,
	Mykola Kvach 
Subject: [PATCH v3 1/2] xen: Introduce system suspend config option
Date: Fri,  6 Jun 2025 13:11:41 +0300
Message-ID: <412d2b68741182fe0528cb85c0af2a29a2ebec3a.1749204282.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.48.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Mykyta Poturai 

This option enables the system suspend support. This is the mechanism that
allows the system to be suspended to RAM and later resumed.

The patch introduces three options:
- HAS_SYSTEM_SUSPEND: indicates suspend support is available on the platform.
- SYSTEM_SUSPEND_ALWAYS_ON: used for architectures where suspend must always
  be enabled.
- SYSTEM_SUSPEND: user-facing option to enable/disable suspend if supported.
  Defaults to enabled if SYSTEM_SUSPEND_ALWAYS_ON is set and depends on
  HAS_SYSTEM_SUSPEND.

On x86, both HAS_SYSTEM_SUSPEND and SYSTEM_SUSPEND_ALWAYS_ON are selected by
default, making suspend support always enabled. The options are designed to
be easily extensible to other architectures (e.g., PPC, RISC-V) as future
support is added.

Signed-off-by: Mykyta Poturai 
Signed-off-by: Mykola Kvach 
---
Changes introduced in v3:
- select HAS_SYSTEM_SUSPEND from SYSTEM_SUSPEND_ALWAYS_ON
- drop selecting HAS_SYSTEM_SUSPEND from X86
- simplify default setting in SYSTEM_SUSPEND
- hide prompt of SYSTEM_SUSPEND when SYSTEM_SUSPEND_ALWAYS_ON is enabled
- move HAS_SYSTEM_SUSPEND alongside other HAS_* configs

Discussion on adding the SYSTEM_SUSPEND config can be found here:
https://lists.xenproject.org/archives/html/xen-devel/2025-03/msg00169.html
---
 xen/arch/x86/Kconfig |  1 +
 xen/common/Kconfig   | 18 ++++++++++++++++++
 2 files changed, 19 insertions(+)

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 7afe879710..752d5141bb 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -33,6 +33,7 @@ config X86
 	select HAS_VMAP
 	select HAS_VPCI if HVM
 	select NEEDS_LIBELF
+	select SYSTEM_SUSPEND_ALWAYS_ON
 
 config ARCH_DEFCONFIG
 	string
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index eece1370a3..867710134a 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -122,6 +122,9 @@ config HAS_SCHED_GRANULARITY
 config HAS_STACK_PROTECTOR
 	bool
 
+config HAS_SYSTEM_SUSPEND
+	bool
+
 config HAS_UBSAN
 	bool
 
@@ -593,4 +596,19 @@ config BUDDY_ALLOCATOR_SIZE
 	  Amount of memory reserved for the buddy allocator to serve Xen heap,
 	  working alongside the colored one.
 
+config SYSTEM_SUSPEND_ALWAYS_ON
+	bool
+	select HAS_SYSTEM_SUSPEND
+
+config SYSTEM_SUSPEND
+	bool "System suspend support" if !SYSTEM_SUSPEND_ALWAYS_ON
+	depends on HAS_SYSTEM_SUSPEND
+	default SYSTEM_SUSPEND_ALWAYS_ON
+	help
+	  This option enables the system suspend support. This is the
+	  mechanism that allows the system to be suspended to RAM and
+	  later resumed.
+
+	  If unsure, say N.
+
 endmenu
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Fri Jun 06 10:14:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 10:14:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008380.1387670 (Exim 4.92)
	(envelope-from )
	id 1uNU5D-00074b-2y; Fri, 06 Jun 2025 10:13:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008380.1387670; Fri, 06 Jun 2025 10: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 1uNU5C-00074U-Vc; Fri, 06 Jun 2025 10:13:54 +0000
Received: by outflank-mailman (input) for mailman id 1008380;
 Fri, 06 Jun 2025 10:13: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 1uNU5B-00074L-Fa
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 10:13:53 +0000
Received: from NAM04-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam04on2060e.outbound.protection.outlook.com
 [2a01:111:f403:240a::60e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f0c76958-42be-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 12:13:51 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by CY8PR12MB9035.namprd12.prod.outlook.com (2603:10b6:930:77::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.35; Fri, 6 Jun
 2025 10:13:46 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8792.034; Fri, 6 Jun 2025
 10:13: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: f0c76958-42be-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=NTbPGgJk7iRFbqOEqvMpEVpMcK2QQjIjO4wDn5e6KAXoQjVhsMLx4pNWOMsO1OOSqxninr4QWsgQ0ijdmOIxHNrZQDl+KkJP9PH2qyFZu9bYhsqgMMMbXA2Fw7vZZO6DfzwRDj+taGASHuPwmfLsxMTeirOswxyCLfNao3ilHqIG6/CtcMuKZV6gQF4SDOGJ04+LU5Xg1tUMnjMKK4xsISXYXP+5kmVqf6/CgTTqWAfT/VIYgH6k8w6IRl+9syLAol7mM3rvu+6ArkByFNSh4Iok178p0NEUm288R6S2C57/OTpj9K6FAAHvfp1gPaDa42VBPO3tCdDnW4xKnJs1IA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ns4AgFo9XDRbp1s0mhDM41O9Qa5PyQc6OVVfa2WSwKI=;
 b=QLGjoolehJWQwLdmdN/TdVG2yF0ifo8P5ElQwCD+IcKjx6l2vtS3iz5sYonqFR7piFtriNYMvZ9suivJHDHOA29ZdSg0UcOJnTSAaH6C9yQlEtNXIObSSeO9iQmnTpGEpPyjUDIX8HQAdZ2Ah1iXnoIDuDCaUa59ludnB5/+VyQVltHj2cFyIDIIdvtlKnATQvCaLdtX8WuMfo1+c1PmesQM/ZP7U2q1ZUlsKK77gbXS2U4uT4aOvYKIMQuMBwnGxI60NVrgiCbP+btQ6nShfRjV5Jo4/E9p5eyvc7ITMGa8pXUXPazjw0nJaV7XMpgowBAt5JIly1y0wuqvnLdB0Q==
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=ns4AgFo9XDRbp1s0mhDM41O9Qa5PyQc6OVVfa2WSwKI=;
 b=fQj6hnTZUvYbkfCxqn8En+8HItse46gvye8LhiRW5kMUNrrCpzLCvAw2axIVzSIwbWksWj6zLbsry8oUJmHuFsyW+fus4Rwq5bXrgg2DrXfi8BHxv6vSiSwlYv3aAf6PNsNXUm8AILyFwm4oTFJsKLIIoggjUNIg6xn+2hZa/hQ=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Fri, 6 Jun 2025 12:13:33 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/3] arm/mpu: Introduce MPU memory region map structure
To: Ayan Kumar Halder ,
 Ayan Kumar Halder , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250604174311.754899-1-ayan.kumar.halder@amd.com>
 <20250604174311.754899-2-ayan.kumar.halder@amd.com>
 
 
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: AUXP273CA0011.AREP273.PROD.OUTLOOK.COM
 (2603:1086:200:2::23) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|CY8PR12MB9035:EE_
X-MS-Office365-Filtering-Correlation-Id: 2ef0a836-16ca-431f-8904-08dda4e2d2b2
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?WUc2T3QvZmhaMEl0RS93SUc3Z1JmNlc3RjRzakRwa3NNeFZGbTN6QkF2eGlY?=
 =?utf-8?B?WjREMVFhbis0ZzBySzdKaE5FSTlXOUE3bGVuWGRrZ0VJSFVlWkF6cTV5d3Jj?=
 =?utf-8?B?RVhjTjVrZE12dHBrTkltdzF4QjN1UWxOMjA0VVp3U1l0b0VQRWpuV283RWQr?=
 =?utf-8?B?blZiSlBaTWpFN3VzUTc3ZXVxaXJ6WEJuY2NOK01uZ2t4VEpjTnVxSWlqV1ls?=
 =?utf-8?B?WmxDcGw4K01JUVpYM1l6b3FrNWF2akVhSlBKcDhHNms3V05SVXBVOFZxRDFV?=
 =?utf-8?B?ZjhQeGJFV2J0SEdpOE4wa1ROVGk1dmVIVzFHZGFmQ1c2QVpzNXd0NDFhdkRI?=
 =?utf-8?B?N254OFpjckJFdzJWdEpoNUZUSmdCRHdlT1huQzZ3QldjVkx0d3V3NktkMmlK?=
 =?utf-8?B?VTBmb1Rma3VybDZDbklXaS9hcEJUK2M4TjJBVEVPd1dhMFJjTmxCcnJtcmZw?=
 =?utf-8?B?eVc5TzBVRGJMS3ZSMlRrVkpvbmZCTGtLNm5SRXNFWFlWSGpnT1FLUCtGNEIz?=
 =?utf-8?B?eDhtSUVSbVBycjdvek5UOTdETXpzK2hlMUh3ZnhFbjBKc25peXNvbFlKR3Va?=
 =?utf-8?B?UUxkOUthKzBiQ1lSU21ScnJiNWNDQ2l1UFUzUE81TW5LMW1ZV28yNHVabFJj?=
 =?utf-8?B?dDVxcHlBcExNT1hzWml4Wm9xb1N3cFYvY1IyV0RXeXRZajBKQnBhOFNUNlVE?=
 =?utf-8?B?cm9CMitpd0krWlJ2d0Y1eXltRzFPbVVrRkhiczNCbkFWNzRnWEFhWDJicmln?=
 =?utf-8?B?TWJ4eDhLYWROUUp0RlJxQkQ3VEtDa1BvTzMvMVU3amxyVDVLbUVpbG04UmxT?=
 =?utf-8?B?S2puY08wdjJwUzR5emk4WXlLZDRBbldydTg2N2JXYVBaUlVXU3BseFd5dWxp?=
 =?utf-8?B?dDBnTGFGdGpGeDNnU0ZDeFRUVXJIbGpGMGJDQlRPOU1KRmlZVlJLZUxVczdm?=
 =?utf-8?B?bXE5VjR5ejFpMlhDM1VVaUk2aGRsZmlON2JQLzBkYXk0aFZHV2Q0ajYrQWdt?=
 =?utf-8?B?RWVKbnQwWkVRVW90VWVBQmF6OXlaSWQ4SUZFQXpid2VSV2xaWm5EdUdsL0N1?=
 =?utf-8?B?RDRHZUdwWEluTk9XU1BjSTBKRUxYbnoydk4vYjdlalZsZW5salU0MmlIRzAx?=
 =?utf-8?B?K0xyZkdsWUcxZXlLMTBKSTcvVjVjSzRzbnVheXUyK1ltdlc4NEl1K2xKWnM0?=
 =?utf-8?B?SUorNlhQNE43QVZ5STZyR0VFT3RDSmdKU0R5VzZ5aWp2T2xicC91UmZidzFj?=
 =?utf-8?B?U3lnMy9GRk1GM0g0RmJaYU9XL0o3Nk5BZG10OVIwMi9JdU1peW9YK2VHOUdN?=
 =?utf-8?B?OTN0YzhNd0VORVNpaVphVkxsd1NGTkhFb1Y5RlFCZzFaRHVMQmdoLzkwWFlp?=
 =?utf-8?B?VUxzdmdaWll1ZVY5Q2VlWGNPNm5GZi9iMHVXbXhYWGZoRTdHdGNZd1JhR2pH?=
 =?utf-8?B?cHA4NW5wUXpQajlUaTAxRnR3NUVxUmlVUHFvMG13cmw1d2RYSGNzZ091SHVz?=
 =?utf-8?B?RkwvL2FEeEVrT05GSzNwaytVZW9wYlBzRDlNbEFvS0V6cmoxcjZJSzBlQ1hp?=
 =?utf-8?B?R0lLaDRkdnVPbWhJa3dPdzYyRlJ0N3ZsQ1dDODZZZ0drS0pPc25wd0JMUGxr?=
 =?utf-8?B?N1FBZHlsNGc4RG1MUE10NHlnWWJndXJWSEF3VzNlUVdWYktINjg0dkllZE5i?=
 =?utf-8?B?Y2VIeHJhOTdYVGZ4dXc5aC9Yd2p6ZnY4SmdYZmZrbkROL2kwczkvWDJJbVQw?=
 =?utf-8?B?RmI0elpQZ3lxeUJza0g2VkI4VlkycFZTOU1Vbm9RVStMbmVldUpKb295dDVv?=
 =?utf-8?B?azZsQmxHVjFIT01KTDE5YnlPSUI3TjkwektiOTJYK3cyc3NVTGpydjcvQkl4?=
 =?utf-8?B?QWlNWUk0SFFQYXJNVEltd2RSZkRPa1FXeWExTVVjT0Y4bVJISkcwVlc3ZG96?=
 =?utf-8?Q?PzdZXSYVUmw=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.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?R3ZTb1Y3TVgrNmVrajhEYXBPZDN2b3pGM3ppaTk3RHpnVHA1SGNpV3JXTlB0?=
 =?utf-8?B?akNsVXZSMmlvdCtycnFtdFh6bnY2OElvVFNpekZnR2VFMVlnQzFRQzlkeFE5?=
 =?utf-8?B?QXpiM0RFc2Z6T09heCtLOUNVaCttLzlPbmJ6UzVvREdieXgwVWc5SUgrNmFW?=
 =?utf-8?B?SDJ5djd6MU5OTTRvQVBYL0VPTUNmYjJJSk1GMTlZRWJKcDgwaElSdFlPdStF?=
 =?utf-8?B?RHJnU01BaEl2akZwVW8wRnpvdVVsVUxjUVgrb0QvZitsME4zODhTdk5mMmpo?=
 =?utf-8?B?N09YOXpiaFZaRjgxQUVMOEpOeTMvbElMN1ZaN1c0bVZNVzQ1UmZLRzRVby81?=
 =?utf-8?B?eVNLUkNjZzNhMEFQdjE5YlNKMVQxak44MHY3bW9MajhHYndHNWJ5cUUwVjBp?=
 =?utf-8?B?ejZnem0rWVRDM2F1S1A2aTJKUVR4SnV4Z3UwcU1KcnFhR0ZEU0tQbUpRdmhJ?=
 =?utf-8?B?UjR0elA0WE9lUk9XS29mYi9HUnNZRkw1RE93bGpvQ05GNFdkUjJqbjVmTkZn?=
 =?utf-8?B?S2o4dHRhYkd0b2RkcStWeWNnbUc5YUJ0M1F6TTNCaVNyeUZhcnRPQ1NBRGU1?=
 =?utf-8?B?SXYxcWJ4NEJjOGJzN3FpeVV3UUJMTnZGbEFFbDBEQS9PeFFtOG1FTC9HOU5k?=
 =?utf-8?B?YTV0Q2V3MmhFdkVGeTJ3dDdqaEt1eGR3dkNkc1VmNHp4bE9vNUtOS3RFTnlm?=
 =?utf-8?B?cldwUFMyZ1Q1dURCdkR6ZERxeFlaUHBERHlsYlNYRldiUGljUWZKREhwOXov?=
 =?utf-8?B?aTdmRmlJTm9ZZm15c3hMc1dwWFdGQUNuZW5ZSmtjc1M3Sk9wOWJwZEorTUNp?=
 =?utf-8?B?T0l3cVh3YU5Ya1d0SlNGR0h6ZndoclRXbXBlRU45YmJiZmVVYUhqSDlxNVZn?=
 =?utf-8?B?L2pEanladWRzMmFIbFZBdFJCNGNVZHVkSjRaVnpUTURnMlFoZDRHbWZUc1Zy?=
 =?utf-8?B?TDBGSk1TMmxEQlhUVWUvdUhScFJ1T1g5VlF0TjlUakpub1NXVTRQTjhKbXlx?=
 =?utf-8?B?T2VCQTgvTm5RK2VLT05ScGQ2UGJPcGlXN3Y1SHlXUTVDZGJHaWRWb0hNZFhj?=
 =?utf-8?B?djM5V05jV0JlYVYrQjNVOVJvMnUwSnd4cGI3UW1RYXF5bHZ2UmNjbHJZN2lD?=
 =?utf-8?B?MUtkakF1KzBvcVRLbnZOKy9IektkSFl4L2JRVXpnd253S0RBQjZBaCs5RnIz?=
 =?utf-8?B?b2RCYU9JR29kcFd6aGtaN3I3NnVNR1N1MXFHMXc4cXl2SndXS0RKZ2FkaVpI?=
 =?utf-8?B?VVNlYVJqRkswRkJKSG5LZ29Ba1FjTEhSbWRZUGV2WVB5QnRFRmtkanhVd1pJ?=
 =?utf-8?B?M2lucERlWHN5VUxaTlMvVlk2YS9TQXZwOW1NYU56OW1nUHNONUsxNkZjMHdK?=
 =?utf-8?B?VGtLbVpOR2xsNFlaRGw1ZXlMSGNFd1J2cHFpU0UxbnZwN0lMZlJYUXYwaTFq?=
 =?utf-8?B?blA5YXJZTHl1WUlVREVMMHNtdHJxSmI1U1pRS2t6TldMZVhHdWZoSEtCcThZ?=
 =?utf-8?B?bWc0bzVGbzFRbVdDOVJLT1huTVBpRFJaSkladVkrTHZnT1lXbmd3bzhxOWtL?=
 =?utf-8?B?UWdlazBEWmtKU3BVbzVzSnhxTzk3azB5a2Zqd2d0WXI0ank4ZmNwSERjazVY?=
 =?utf-8?B?T1YxWWJFNHRQVG5HdDZMdDM0eVI3TjJzOTZnVUlsMzVRUE5LR2JtNHhqeTRu?=
 =?utf-8?B?V25veGtQWWdsT1JhUEx1eU5rS3IyWHg1aitMSDF1Q3hTZFVvc0U1QWF6YXQw?=
 =?utf-8?B?QjZSaWZxRHNyU1A5QzVlOVhQNUFRcG5JOHlTOFdnOFYxK1N4eHpEczRqcXc0?=
 =?utf-8?B?ZG95TGkyVDAvbHMrNjBVWkFVQUUxc3NLWTgyWDBQZWg5VklMeFFyejBUM043?=
 =?utf-8?B?Vjc5K2NZdXUvSHFqaitVOXhmVGI2ZUJSdDFGdzRBZGRwSVBqT2U3eXd1c053?=
 =?utf-8?B?MHJpM1Y1dDlaNWdZMW9qUUtDdUV5Q3lham1qTmE1T3J3SFBSWjk5NzY3aldN?=
 =?utf-8?B?bXZMbG9JV2NvMVlMUVRnSzRaZGw0a0pKbUp5MEp3UHQ5anR4UDdoQW1YZXlq?=
 =?utf-8?B?Zis0ZjZXS25CTTI2eW1PUllxclJMSzhneElxbGticHJDQ0RkSTJtMnhXa1My?=
 =?utf-8?Q?VguPW43QbiFTgue9gQ9v4KyhI?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2ef0a836-16ca-431f-8904-08dda4e2d2b2
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jun 2025 10:13:46.3892
 (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: DStJy91VYEWwMwPUkrnhCVlOmxMY/6ONyIzdVCgnR15lPSArvqKhrpMzJVLepV+E
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB9035



On 05/06/2025 15:39, Ayan Kumar Halder wrote:
> Hi Michal,
> 
> On 05/06/2025 08:06, Orzel, Michal wrote:
>>
>> On 04/06/2025 19:43, Ayan Kumar Halder wrote:
>>> Introduce pr_t typedef which is a structure having the prbar and prlar members,
>>> each being structured as the registers of the AArch32 Armv8-R architecture.
>>>
>>> Also, define MPU_REGION_RES0 to 0 as there are no reserved 0 bits beyond the
>>> BASE or LIMIT bitfields in prbar or prlar respectively.
>>>
>>> Move pr_t definition to common code.
>>> Also, enclose xn_0 within ARM64 as it is not present for ARM32.
>>>
>>> Signed-off-by: Ayan Kumar Halder 
>>> ---
>>>   xen/arch/arm/include/asm/arm32/mpu.h | 30 +++++++++++++++++++++++-----
>>>   xen/arch/arm/include/asm/arm64/mpu.h |  6 ------
>>>   xen/arch/arm/include/asm/mpu.h       |  6 ++++++
>>>   xen/arch/arm/mpu/mm.c                |  2 ++
>>>   4 files changed, 33 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/xen/arch/arm/include/asm/arm32/mpu.h b/xen/arch/arm/include/asm/arm32/mpu.h
>>> index f0d4d4055c..ae3b661fde 100644
>>> --- a/xen/arch/arm/include/asm/arm32/mpu.h
>>> +++ b/xen/arch/arm/include/asm/arm32/mpu.h
>>> @@ -5,11 +5,31 @@
>>>   
>>>   #ifndef __ASSEMBLY__
>>>   
>>> -/* MPU Protection Region */
>>> -typedef struct {
>>> -    uint32_t prbar;
>>> -    uint32_t prlar;
>>> -} pr_t;
>>> +#define MPU_REGION_RES0       0x0
>> The name of the macro does not make a lot of sense in AArch32 context
>> and can create a confusion for the reader.
> 
> I know, but I want to avoid introducing ifdef or have separate 
> implementation (for arm32 and arm64) for the following
> 
> Refer xen/arch/arm/include/asm/mpu.h
> 
> static inline void pr_set_base(pr_t *pr, paddr_t base)
> {
>      pr->prbar.reg.base = ((base & ~MPU_REGION_RES0) >> MPU_REGION_SHIFT);
> }
> 
> Let me know your preference.
I did not mean #ifdef-ing. I was more like suggesting to use a different macro
name that would be more meaningful than this one.

> 
>>
>>> +
>>> +/* Hypervisor Protection Region Base Address Register */
>>> +typedef union {
>>> +    struct {
>>> +        unsigned int xn:1;       /* Execute-Never */
>>> +        unsigned int ap_0:1;     /* Acess Permission */
>> If you write AP[1] below, I would expect here AP[0]
> 
> Again same reason as before, let me know if you want to have additional 
> ifdef in pr_of_addr() or separate functions for arm32 and arm64
I don't understand. My comment was only about changing comment to say /* Access
Permission AP[0] */ because below you have a comment with AP[1].

~Michal



From xen-devel-bounces@lists.xenproject.org Fri Jun 06 10:15:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 10:15:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008385.1387679 (Exim 4.92)
	(envelope-from )
	id 1uNU6a-0007cR-BY; Fri, 06 Jun 2025 10:15:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008385.1387679; Fri, 06 Jun 2025 10:15: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 1uNU6a-0007cK-8a; Fri, 06 Jun 2025 10:15:20 +0000
Received: by outflank-mailman (input) for mailman id 1008385;
 Fri, 06 Jun 2025 10:15:18 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uNU6Y-0007c5-F5
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 10:15:18 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20627.outbound.protection.outlook.com
 [2a01:111:f403:2415::627])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 22bfc8b0-42bf-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 12:15:15 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by CY8PR12MB9035.namprd12.prod.outlook.com (2603:10b6:930:77::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.35; Fri, 6 Jun
 2025 10:15:11 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8792.034; Fri, 6 Jun 2025
 10:15: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: 22bfc8b0-42bf-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ieH81qo0rIA3nxunL/+vjQ/nmMVNob3aJX2EoYy54MjOwQ9BtNZdwaiDThBah01/8ttFDYtsY2WCgAiKRSRKh2kyNhjqOMS2krmI0e2wSBw6RfndObXFDZIvbx6KLxlIEg4nNJ4leY1vkLTZWXUId0WlndivUSiEnZz/n5mTUt0XDF6qJHUWPpQ6kqK3o1emWwaDtGYW4kbTjQG6ZC7ur/zYkSOqAnLrHH7KzIRJ7cIpJXMHfDmKOswUsB5o8MoGjL70B8OOvRgPRypSa9ws4jRrGU3t/PixEOGhOATJ3mdQ+SclNcERSBmOqEnSZr44m/XEm87Qbsqq5b4pHA5IqQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=9Ufu3gGc+URal0FOVV605N524/8ns7uIDRLE5fGwWHg=;
 b=HZAIzmUMWo3qDafGxyNh02TaOff/Y4B4anOWRzQV1R35li6Od0X0vPDnvaQjG/U+WXdYWt3VlpMKXfooPxVCiRk7K7h7OIf2+KW77kJ+JwsLB98iQvyG1XTTfdUwEnCeSZz9oZIZN8jhiwPG9V2oo7TQawCLfgTodTVwvMNtAvRXtpGrNhMiEk0rRKLqPwxDE2TgWAoxOF6i3ag42uGimZtrAORRwxnAVGkOy7yvJw1Wl1LrMv7FY83A/6BXfin68QLp7CSItiUnCQf+aNSfacQhJAbI3bF9T0NM1Gu1psuQE+rYbohEjXp+4FSi+GUM70IxYuVNOl3RrxZNX5+C2g==
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=9Ufu3gGc+URal0FOVV605N524/8ns7uIDRLE5fGwWHg=;
 b=i1bXQP+oADRP1XwuZznFeU7QaU7i3DdP7TV6BKGWKOm1VgWM+gKTB4Eu6Q+tZfseMBXGtH1RhCOebbEBWZskFRc+DdaSmxX/M0q9QXcxcMnEpe8uL4pOZzokG3EvgaGPGd/9284o8BBiLYhkpcr4WlKTkyJqVPGSXlLs33TYYZA=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Fri, 6 Jun 2025 12:15:07 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/3] arm/mpu: Provide and populate MPU C data
 structures
To: Ayan Kumar Halder ,
 Ayan Kumar Halder , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250604174311.754899-1-ayan.kumar.halder@amd.com>
 <20250604174311.754899-3-ayan.kumar.halder@amd.com>
 <50c8e74e-95f6-4cea-b979-8b81d7575a21@amd.com>
 
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P123CA0216.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:1a5::23) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|CY8PR12MB9035:EE_
X-MS-Office365-Filtering-Correlation-Id: ef986078-a0ba-47d0-eaa8-08dda4e30599
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?QnlQREpOYVc0NjBtVWdVbEpXTFN6S1ppdEVEUFlJUFZTMm9wR3B6SUxnTTJS?=
 =?utf-8?B?ZTBtV2w1SDQ4bXdmMlRrLzRKdlluYU1JOW0yQ0c4S0oxK2Z6V3VsTnBtNGIx?=
 =?utf-8?B?UjErSnpra0dBMHZ6VStZVXA0MUpIQWdZUi9MUC9SWHovbDREWFNNRXFyUGpJ?=
 =?utf-8?B?cTlBTE02ZEhMRnM5WWRSYkw1VnhrdUwxbnp1QXUxcEQ2RnJpVFFCaWhyNFVn?=
 =?utf-8?B?M2s4M3NKengwRjJKYXM3MmNEVnZFMWNMWkdXVW1aNVdWUm1GcHQ3eHpZRGFQ?=
 =?utf-8?B?L1pVUGNYcVB0WDZZMzc3NC9pYUVRUWxTeGNXQ0UyaWQ2Q0Q5b2VlT01scS9V?=
 =?utf-8?B?bzVpZUQ2SWZaVFdUZmU2TnE2b2lUbXhLVjJqUTl1ektQNzlFSUFnV1paZVRa?=
 =?utf-8?B?amRjcC9MSFFodFMvRzZ2N2VLNlA4dm1aMW5SNy9xd3Z0QXlNRjNTWmxKK2NQ?=
 =?utf-8?B?RjkzWWhPTHhmQ0Z0WVF3SUhoY05URVVwVXFyMkkzTmtNeWQ2MHhZL1Q3TGZ2?=
 =?utf-8?B?ZzgrYWo5NzZQcmxxL0JuTFcxR2NQdEJGcmZFb0llRk1obFV3NmRQS2l5UlVU?=
 =?utf-8?B?bjc2ZjNuYTY1clJ5UnI2a3ptLzgvdjFnNjBxUFRmbmxOTHgrTEwvd1MzbmR5?=
 =?utf-8?B?UnFNbDlpZEh6Yjd3Mjk0cVJaUTl1VkU4ZEVDMGZPZUxsYjNDSEhWYnZqaUR3?=
 =?utf-8?B?QlBwWWxkTk5RcmRCcy8xR3ltN3IyWUYzQzRtbGt1cnNaTzJTaGh0NEJJOTJ5?=
 =?utf-8?B?TFpzcE1rR25uNGZjUnJyRmdnYkZIL1VDNW1GMWcxVzc3anFTLzdkVkxIVElw?=
 =?utf-8?B?akxNUXhSUkpqbUxNZW5aUGdDQ1N5Z3lESC9pTnhFTUM4VFp6cnhnbUtkc2ZX?=
 =?utf-8?B?aWE0T1VWYkE2cTJtOVlBNklXbEI3RDEzL1A5dmtDdktSUmNVY01JSENLS05I?=
 =?utf-8?B?emN3bGxHdWdMTytaU3MvdTFyb1BORTlpdUQzTWhkUjBPNGtCZ3ltbFM5aWRt?=
 =?utf-8?B?MXo4blcyTmt4QmRXRndzR3lKR0pLSkJKOTJwRU9RTTIzUktkczJCclcyM3Ax?=
 =?utf-8?B?RFQzVDZJUzgzelg4T0daVHBvWFBPSnFSQSthNUtzTnBVVnpQMTMweGEzT2Jr?=
 =?utf-8?B?dzJRdlJ3TDdNMnlrU0J1NUgxMVZidjFHRmhpZ25zVjNXUHk0MmxmTG8xUG5Z?=
 =?utf-8?B?T01DZjZ3OGdlSXdBRy8vZWRxUlFNbng3ZlFUUm0rbnA2Q0VkdFpwa251QU9E?=
 =?utf-8?B?ZTRZOHlZTk4zYUxuVkJUcWZIWDBXK1I5U25hSlBEUEJ3Mi9OdDFZajRUaWo2?=
 =?utf-8?B?VVAxYU1EWlU1Y1lCdExqdHVUQkdVWXJFdW5rckwwMWxCTkVlUjBJNFR4UWFy?=
 =?utf-8?B?bmcxTzBIOFpxR2dPWGRPcTcwVDV0Z09Bckh6cHB1Ykh3NnhxNXlQclM2SStr?=
 =?utf-8?B?ZW0rTlFSMFg5OTcxN2dPL25jSXB6TkFmKzRhdzNEWVBLcWJ3SDhJSFIyUmhW?=
 =?utf-8?B?czhlYk5KTFl4OG5hdUFJNmRIbG02dWEvYkNqeUJGRGdhNHp2U0NtbVI3eEVi?=
 =?utf-8?B?bW9VcnBBUi9GTFZGM20zL3A0Zm4rMW9xMDRKaXkvdlZaU25ZODNmL3pJaUg4?=
 =?utf-8?B?ZGFwM3RJcVdKRVV5MDdtWGtLcjFOZUY0MlRZUDA5ZlVWWTFoOXJFRUJ5cTFq?=
 =?utf-8?B?MEUwajZhb1NBaWtkam5XKzdyTGVJUnc3NUc5cGpnVzd4WnJSbEQvaDZuallu?=
 =?utf-8?B?TTJXaWk4SEFXSnpzWG1NQ1JkVnhYaTZUUEVxcElQcVBYNHNJR1hEcDJMZDFn?=
 =?utf-8?B?V2xtNlJSOCs4MlNlMnIwMlVUKy9FMFlpZmZ3cXJXbWlMb0Mwb1RUTTZ3ZFRv?=
 =?utf-8?B?Y3pWU3g5OE4xWGpaYWFpNWdNUjdwNVJkbW12UTlyVnQwcVNkL2dtaERiRWxp?=
 =?utf-8?Q?4kuIYovb5ng=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.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?aFhkSldhYWtxL0UzMW14emdSS1duZVVhWUkzOU9zNGRrWkh3eVVyTGJ1cXV5?=
 =?utf-8?B?d0tEc1NYSm80UnhjbXovdWRyT2w1b0Y5UjdOZ3pRR3g5dytIb1Q3VjRpaTJl?=
 =?utf-8?B?NnN0aXNFSmUrczBpQ0JLRVJFNkgxbktPc0crd29UOWVBcllzUVhzNEZGcWhP?=
 =?utf-8?B?YzFacnVxNGJWQy9qSWRiKzhsRS9HUkxvR3JaTjlxMktJc1l6eklPTDhuZzVR?=
 =?utf-8?B?K0R1S2pHVVpyVWtGNVRtNFJxTHVtZVVhYkJweENKYW1oZHp4ZERLVUJsaVRa?=
 =?utf-8?B?dWp5UTlSYll1dkt1ZmRJcjhUR0c1eVAvcEpLM1Vhdm9Eb0F1U3M0dGEzWjN6?=
 =?utf-8?B?SSt1SkR2clY3U0U5UHFJdVNRQ3poNjJRNnBMN3JOeXJOaG5US25NVkxTeSs4?=
 =?utf-8?B?azY1cUpvTk1MbjlXSi9ZdVhjYVBtenYwajJ3YXd1bTVPUkdqOUQwSUJTWlI3?=
 =?utf-8?B?V1JFaUVXL3RGYlZpS3A4UTU4SjRlWnVKZHBGUjRpRHB3QnpmUm5uZ05pU1l4?=
 =?utf-8?B?cHY5M3MrRlFtakV4dUFNcHBlRFBDS0R4alR2Vm5IcmM2WmcwcWlXTys5TVpQ?=
 =?utf-8?B?aVpKUk9nR21iTUJKSU9GNjhweUJSdmxSYWJxTlhLa0xnZ3dBRGdDeDlteWVp?=
 =?utf-8?B?M3FoOFVDaHdrRmV6M0ZOV0tKSWZKWXBIcUM1UUw4UmJVNVZJOHRHSlc3TTJS?=
 =?utf-8?B?MEV1WlR5cE5Panc0OHlCR0Iwa3FOTW1XT1U3RnJQVlNLb1BqU2FkR3ltVE1k?=
 =?utf-8?B?Y05qNjdJcnpzWVJCd0RxaEQ0cUFnNGQxQVl1TlFFL3FwcXFNbnVsdjRteVBP?=
 =?utf-8?B?WVROOG9JbjNlQlNjVEE0bXMvRkF5QUJjSU5iL0ZjWW1KWmNEc2xJTktVdWo2?=
 =?utf-8?B?TkkyUmdxb3Vjc2pWcVFrWXFNblFXdm9OZFYvTXdoVGJGdXpoa01hNmkyMjdV?=
 =?utf-8?B?WUluelhmS0txNDV2ZmZ1bjNJNFhlRXBjVzJMcnVhOVBOdWNtQjNHTmh5R2ZG?=
 =?utf-8?B?UFdXM3dsb1lhV2VPR1FhS3dqMC9MNEt4NWp3ZVJLK1hEb3gvSzFoWDZCR1FZ?=
 =?utf-8?B?VTBBaGd3SVBDZEhzTmd2Q00wcGpYVHFOLzN2UXltdkVsR3FMSDBGczcwUWE0?=
 =?utf-8?B?RVlJY1h3clZCZ2YzRWRkcldid1ltcFpCempDQ0UwTUlQREhRVTdoek9NTGVm?=
 =?utf-8?B?SlNVUmpjWnRWTzZwSVB3S2g0SnhObHpad2drMkhOV1lGZjIrQzNOZ29ySndR?=
 =?utf-8?B?STRVOEI3YjJrN3VpcmpOa0VRZ2llYjBLcXA0elJ1VTY1YWc3MUdFdjZnL1N3?=
 =?utf-8?B?QlVrT2xVNnRHaXdsSTUzS1BOcUw5SWxIZFdTQ2JTb3IwcS9GanNVbmIxcGps?=
 =?utf-8?B?eFJUcW1jMEpDTkRLT09QWFJCRzBCWk9KdFdlTGt4MHB5YVN4ZWhkNGpia2xw?=
 =?utf-8?B?SEpIZXRxbTNSTFN4RWcvdEQxbzhLNWlrUGVjaDJ4VFJLRG1ib2IwK2ZkZ1Fm?=
 =?utf-8?B?d2lYRzZMNE8zTXF0a25JcVNReFBYRkdrU3hZZGp4MFJRRUZUbDhSU2dnemNt?=
 =?utf-8?B?dFMxUkh3YlYvc3lMUDlWT1hJaTB0czFENkRLSVhkR1Y1QTBHcFZMM1NsZVhO?=
 =?utf-8?B?MVAxT0FPbklxSnZzNDA3TkYvTjlXQXY5cWZpalQyM0NoMEx0emY4Ry8remh0?=
 =?utf-8?B?NENheVFUUVN2Z2QrSDZuTmJaL1Y5djFzTHlsRUEvMmdaemlyREtUS0RWT1Ax?=
 =?utf-8?B?N3JtZHg4RFlBVXNBcWtRQzMxOVFpeXdmcjhPMWVWbjllbS90QmxVOGp6blVr?=
 =?utf-8?B?YjdEYUNwdkwzajFLTWNIUm9uYWlYR25teW1Mejl0Q3hpbXFhVlcyTC9NVlZw?=
 =?utf-8?B?c2orcG1qT3Vib3VlcUVncUpkTXhRTExvbmZLTnZkRWZLTjJBQ1N0a3FaUlpQ?=
 =?utf-8?B?SHFoZkJlQVVyYTkvYWRCSldQVmo1czdpL0tqZkUxTFg0ZFJKR1BVVGhydmJt?=
 =?utf-8?B?emRzUGZGVXpveWNZbGxqbGdBUS9Bb3VkTGhuZDFtNFJYYmRMMndYWVVzL2Vy?=
 =?utf-8?B?c1ErNjVYTEdnNUp3cGZZZzVvUGc0b1d5akw2RkpjbnZRWWlpanZ3dnkvUmdE?=
 =?utf-8?Q?4vWX86RNdzqCd50f/QGqzlUe8?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ef986078-a0ba-47d0-eaa8-08dda4e30599
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jun 2025 10:15:11.7156
 (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: AZUVC9GwF6fiPEZliHq7snwA4sVXTuakYgw4IcAh754kvtlGY5tP+fRFQnLmB2Z2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB9035



On 05/06/2025 16:27, Ayan Kumar Halder wrote:
> Hi Michal/Julien,
> 
> On 05/06/2025 08:44, Orzel, Michal wrote:
>>
>> On 04/06/2025 19:43, Ayan Kumar Halder wrote:
>>> Do the arm32 equivalent initialization for commit id ca5df936c4.
>> This is not a good commit msg.
>> Also, we somewhat require passing 12 char long IDs.
> 
> Modify Arm32 assembly boot code to reset any unused MPU region, 
> initialise 'max_mpu_regions' with the number of supported MPU regions 
> and set/clear the bitmap 'xen_mpumap_mask' used to track the enabled 
> regions.
> 
> Use the macro definition for "dcache_line_size" from linux.
> 
> Does ^^^ read fine ?
Yes, it certainly reads better.

~Michal

> 
>>
>>> Signed-off-by: Ayan Kumar Halder 
>>> ---
>>>   xen/arch/arm/arm32/asm-offsets.c         |  6 +++
>>>   xen/arch/arm/arm32/mpu/head.S            | 57 ++++++++++++++++++++++++
>>>   xen/arch/arm/include/asm/mpu/regions.inc |  8 +++-
>>>   3 files changed, 70 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/xen/arch/arm/arm32/asm-offsets.c b/xen/arch/arm/arm32/asm-offsets.c
>>> index 8bbb0f938e..c203ce269d 100644
>>> --- a/xen/arch/arm/arm32/asm-offsets.c
>>> +++ b/xen/arch/arm/arm32/asm-offsets.c
>>> @@ -75,6 +75,12 @@ void __dummy__(void)
>>>   
>>>      OFFSET(INITINFO_stack, struct init_info, stack);
>>>      BLANK();
>>> +
>>> +#ifdef CONFIG_MPU
>>> +   DEFINE(XEN_MPUMAP_MASK_sizeof, sizeof(xen_mpumap_mask));
>>> +   DEFINE(XEN_MPUMAP_sizeof, sizeof(xen_mpumap));
>>> +   BLANK();
>>> +#endif
>>>   }
>>>   
>>>   /*
>>> diff --git a/xen/arch/arm/arm32/mpu/head.S b/xen/arch/arm/arm32/mpu/head.S
>>> index b2c5245e51..1f9eec6e68 100644
>>> --- a/xen/arch/arm/arm32/mpu/head.S
>>> +++ b/xen/arch/arm/arm32/mpu/head.S
>>> @@ -10,6 +10,38 @@
>>>   #include 
>>>   #include 
>>>   
>>> +/*
>>> + * dcache_line_size - get the minimum D-cache line size from the CTR register.
>>> + */
>> I do think we should have a cache.S file to store cache related ops just like
>> for Arm64.
> ok, I will introduce a new file.
>> Also, no need for multiline comment.
> ack.
>>
>>> +    .macro  dcache_line_size, reg, tmp1, tmp2
>> I would prefer to use the macro from Linux that uses one temporary register
> /*
>   * dcache_line_size - get the minimum D-cache line size from the CTR 
> register
>   * on ARMv7.
>   */
>      .macro  dcache_line_size, reg, tmp
>      mrc p15, 0, \tmp, c0, c0, 1     /* read ctr */
>      lsr \tmp, \tmp, #16
>      and \tmp, \tmp, #0xf             /* cache line size encoding */
>      mov \reg, #4                          /* bytes per word */
>      mov \reg, \reg, lsl \tmp         /* actual cache line size */
>      .endm
> 
>>
>>> +    mrc CP32(\reg, CTR)           // read CTR
>> NIT: wrong comment style + wrong alignment
> yes, I should use /* ... */
>>
>>> +    ubfx   \tmp1, \reg, #16, #4   // Extract DminLine (bits 19:16) into tmp1
>>> +    mov    \tmp2, #1
>>> +    lsl    \tmp2, \tmp2, \tmp1    // tmp2 = 2^DminLine
>>> +    lsl    \tmp2, \tmp2, #2       // tmp2 = 4 * 2^DminLine = cache line size in bytes
>>> +    .endm
>>> +
>>> +/*
>>> + * __invalidate_dcache_area(addr, size)
>>> + *
>>> + * Ensure that the data held in the cache for the buffer is invalidated.
>>> + *
>>> + * - addr - start address of the buffer
>>> + * - size - size of the buffer
>>> + */
>>> +FUNC(__invalidate_dcache_area)
>>> +    dcache_line_size r2, r3, r4
>>> +    add   r1, r0, r1
>>> +    sub   r4, r2, #1
>>> +    bic   r0, r0, r4
>>> +1:  mcr   CP32(r0, DCIMVAC)     /* invalidate D line / unified line */
>>> +    add   r0, r0, r2
>>> +    cmp   r0, r1
>>> +    blo   1b
>>> +    dsb   sy
>>> +    ret
>>> +END(__invalidate_dcache_area)
>>> +
>>>   /*
>>>    * Set up the memory attribute type tables and enable EL2 MPU and data cache.
>>>    * If the Background region is enabled, then the MPU uses the default memory
>>> @@ -49,6 +81,10 @@ FUNC(enable_boot_cpu_mm)
>>>       mrc   CP32(r5, MPUIR_EL2)
>>>       and   r5, r5, #NUM_MPU_REGIONS_MASK
>>>   
>>> +    ldr   r0, =max_mpu_regions
>> Why ldr and not mov_w?
> mov_w   r0, max_mpu_regions
>>
>>> +    str   r5, [r0]
>>> +    mcr   CP32(r0, DCIMVAC) /* Invalidate cache for max_mpu_regions addr */
>>> +
>>>       /* x0: region sel */
>>>       mov   r0, #0
>>>       /* Xen text section. */
>>> @@ -83,6 +119,27 @@ FUNC(enable_boot_cpu_mm)
>>>       prepare_xen_region r0, r1, r2, r3, r4, r5, attr_prbar=REGION_DEVICE_PRBAR, attr_prlar=REGION_DEVICE_PRLAR
>>>   #endif
>>>   
>>> +zero_mpu:
>>> +    /* Reset remaining MPU regions */
>>> +    cmp   r0, r5
>>> +    beq   out_zero_mpu
>>> +    mov   r1, #0
>>> +    mov   r2, #1
>>> +    prepare_xen_region r0, r1, r2, r3, r4, r5, attr_prlar=REGION_DISABLED_PRLAR
>>> +    b     zero_mpu
>>> +
>>> +out_zero_mpu:
>>> +    /* Invalidate data cache for MPU data structures */
>>> +    mov r5, lr
>>> +    ldr r0, =xen_mpumap_mask
>> Why not mov_w?
> mov_w r0, xen_mpumap_mask
>>
>>> +    mov r1, #XEN_MPUMAP_MASK_sizeof
>>> +    bl __invalidate_dcache_area
>>> +
>>> +    ldr r0, =xen_mpumap
>>> +    mov r1, #XEN_MPUMAP_sizeof
>>> +    bl __invalidate_dcache_area
>>> +    mov lr, r5
>>> +
>>>       b    enable_mpu
>>>   END(enable_boot_cpu_mm)
>>>   
>>> diff --git a/xen/arch/arm/include/asm/mpu/regions.inc b/xen/arch/arm/include/asm/mpu/regions.inc
>>> index 6b8c233e6c..943bcda346 100644
>>> --- a/xen/arch/arm/include/asm/mpu/regions.inc
>>> +++ b/xen/arch/arm/include/asm/mpu/regions.inc
>>> @@ -24,7 +24,13 @@
>>>   #define XEN_MPUMAP_ENTRY_SHIFT  0x3     /* 8 byte structure */
>>>   
>>>   .macro store_pair reg1, reg2, dst
>>> -    .word 0xe7f000f0                    /* unimplemented */
>>> +    str \reg1, [\dst]
>>> +    add \dst, \dst, #4
>>> +    str \reg2, [\dst]
>> AFAIR there is STM instruction to do the same
> strd \reg1, \reg2, [\dst]
>>
>>> +.endm
>>> +
>>> +.macro invalidate_dcache_one reg
>>> +    mcr CP32(\reg, DCIMVAC)
>> Why? You don't seem to use this macro
> 
> oh, this can be removed.
> 
> - Ayan
> 
>>
>>>   .endm
>>>   
>>>   #endif
>> ~Michal
>>



From xen-devel-bounces@lists.xenproject.org Fri Jun 06 10:22:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 10:22:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008405.1387690 (Exim 4.92)
	(envelope-from )
	id 1uNUCu-0001GG-3w; Fri, 06 Jun 2025 10:21:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008405.1387690; Fri, 06 Jun 2025 10:21:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNUCu-0001G9-0y; Fri, 06 Jun 2025 10:21:52 +0000
Received: by outflank-mailman (input) for mailman id 1008405;
 Fri, 06 Jun 2025 10:21:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uNUCs-0001Et-61
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 10:21:50 +0000
Received: from NAM02-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam02on20617.outbound.protection.outlook.com
 [2a01:111:f403:2405::617])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0b4a0176-42c0-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 12:21:45 +0200 (CEST)
Received: from DM6PR06CA0061.namprd06.prod.outlook.com (2603:10b6:5:54::38) by
 SN7PR12MB7909.namprd12.prod.outlook.com (2603:10b6:806:340::21) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.37; Fri, 6 Jun
 2025 10:21:37 +0000
Received: from DS1PEPF00017099.namprd05.prod.outlook.com
 (2603:10b6:5:54:cafe::e5) by DM6PR06CA0061.outlook.office365.com
 (2603:10b6:5:54::38) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Fri,
 6 Jun 2025 10:21:37 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 DS1PEPF00017099.mail.protection.outlook.com (10.167.18.103) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Fri, 6 Jun 2025 10:21:37 +0000
Received: from localhost (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; Fri, 6 Jun
 2025 05:21:34 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0b4a0176-42c0-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=mNubjrCPpIv+4+oKumy4iBnED8LUiZTSeWZrS/F1EQ7jxIPNHmAMCCaLn3TwgJC2AHreYy2L7xVs+xG7D8xdAz1Z51OUMRpmBUA+s6zZN+OC4zjIOGZRBtG2Sxr5g138Dh6ShxcI9d3D3nm5LQ3tAplT90rF/118Qh9rn9HiuXBJpkAhY+OjIHhTbSABQgytjiEKKZrVE1DmVMvU4W+/I+rEqoc+0ZF9lf5TKJlWCLpZ8T5AUUSOznrLPxki/Z5SgxwuwcSl7oA6VZLLV2+NdVR1QkX4MutLggHlzF64GrUiPDsHLzg5HpSwSs8jlHtOekIR9JipVClZAlpgzaCH3Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=e9VZL+7u7O0wdQzIObCKnPDKU6jDyEgg825DwfufhCI=;
 b=uYnfU7n9F1Tj8SuuQpkmOsfX89DSy6STxZThamSxEdrkX6V4fwD9PEffD+ZevVX8xN394liZUo5UxbHv80kDZ/iohSqFt6v77w0cj7HoTOQJDoiVF3mJTyJWMSZvOW1RgHV7vhPuQLkiXk2/t8jjveNUeLNtPSwkokCdEzxEdWGKkOqp40lF2sAuLf52Wtz3t7viiPojPV2u2dNakHEMUsWuJj7lAj6L+Oeq9ZRDQPwzftbzQ+yom+NsasgHMK70+OLTwof/qz417mHF/UjtHJdqG2fG5+JRWQfGY9NUbuzgW5vmO2/tF5ptGOioefOQHqGk63P571+qneH6WCvKHw==
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=e9VZL+7u7O0wdQzIObCKnPDKU6jDyEgg825DwfufhCI=;
 b=kGmOC7K0CWExcWJVASmKxeX7rZJsoCqjDNmovN5RWMaavVwcBH5i8jOcct4GOItl8dWNbJq2kCfEO+JnJbYuzz0frczfHJBDJbk5zVahlmUJy5t34DoL2FqRAV3dWHcdK+3bVnhPfiPmXD9WZldRBY7EypxgGVOtzSUOBvfEWBA=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 6 Jun 2025 12:21:32 +0200
Message-ID: 
CC: Alistair Francis , Bob Eshleman
	, Connor Davis , "Oleksii
 Kurochko" , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	=?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini
	, "Daniel P. Smith" ,
	
Subject: Re: [PATCH v2 01/15] xen: Clean up asm-generic/device.h
From: Alejandro Vallejo 
To: Jan Beulich 
X-Mailer: aerc 0.20.1
References: <20250605194810.2782031-1-agarciav@amd.com>
 <20250605194810.2782031-2-agarciav@amd.com>
 <38104467-fb7e-4aa3-9c78-0f9bf23183eb@suse.com>
 
 <20e6673b-bf85-4f9d-9938-7005a481b898@suse.com>
In-Reply-To: <20e6673b-bf85-4f9d-9938-7005a481b898@suse.com>
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: DS1PEPF00017099:EE_|SN7PR12MB7909:EE_
X-MS-Office365-Filtering-Correlation-Id: 823466d1-5f5e-4251-f9d4-08dda4e3ebc6
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|7416014|376014|82310400026|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?U29yNkY3TG1xeW56TWphNW5XRmtKVllvaVpkUk9uOElnRndqQlZHaU95bVlz?=
 =?utf-8?B?YXpSOFJ0M0FmUkpHaHYwa3lDaEpEWFdlSE81Rmw2TmttVnpyRjg2NW9QQ291?=
 =?utf-8?B?T3RwNGNSNTlzTjRYVEdFaWoxQ0c4bFJDN3VhMU01SkgrTStRWlAxa1Y4REp5?=
 =?utf-8?B?VXBBbW1YcXAzNGtlS2NodkVLaGJmODZtUnpuc3UrV3ZBZXFPc1FxK1FUWDlM?=
 =?utf-8?B?MkF1MXQ1dDR3NmFxcnRwbUttdTJ6eHFVUXJVS1lhS2loUmVRdjloTVc4dmo0?=
 =?utf-8?B?ZjRhZnZ0d2lFY3JzaUw4a2k4czBSZk83OXRtNUVSVEhQUEJaNkhodmRyK3Ir?=
 =?utf-8?B?STN1Y3BweTBmV0ZXQjNCc2lQWGgwMGt2eldrNE5lVC9teG5lcXI3VmpaNXE0?=
 =?utf-8?B?K0t0UVZ2MVl0RkFoWlkwakQ1U3JseFh6NXo2QTVZcUMrZEtVR1dwdnI0Sjdo?=
 =?utf-8?B?dG9rRmh0OFRjakljRyt1RWNGTHNCR3VKc28vaHplNHVka3c2amxQTmp3RWhX?=
 =?utf-8?B?SUJ6bEVMZ3ZVMkZVYUN1c3Rra1FoME9ick8rZ05MRkpsTUJ5YzdSQTlZcFJW?=
 =?utf-8?B?TVVxb2lnK1pQVjJBbEhYWFJHOHZ4eDBsMG84dFI5RE5Gd0hkWTFtTGhweWdt?=
 =?utf-8?B?R1RIVmFaeUdLcFpDSFNPeFM5c3hkaVJFMXhOMUcvYTNBWkVFUVZwSnNuU0lP?=
 =?utf-8?B?eFVVZ0RDajRYdi9tRjd2N0oxNGxiV3hBcjQ1RlFhM2RqY0tNVUFyRCtkRGVM?=
 =?utf-8?B?STNjWmVsNTd5NmRILy9YSUtCWFNzeXI0YThFQjMybXVqS0JrYTNCaXAzUTB0?=
 =?utf-8?B?UVFHQTlRM2JEdFJoOXlqVzNFZXMrdW14MUhjSHNabmhYYjl1T1M1YjhlRXVU?=
 =?utf-8?B?bnlBR2VWcHlZRlN3Q2Eyc3VySjVQZnI5NlMrMzJRZmhkRnprT0lJbU5vb2lj?=
 =?utf-8?B?OTh5YWoxR3FCMUdiRTcrYThZMk9VUjF6NHZUdThDWFhoalEybHFPaWZlVkdX?=
 =?utf-8?B?MUdtWFFMcFJXMTM5NjNqbndyQ2gyTmJLRjdqbEI5REc0S3lnQWM3UjQvQ2hU?=
 =?utf-8?B?T2xLdGdqZmNzZmJZZGJHMlJleWZ0bzdTV2RuclY1WnA3cVpBc0dBcjZoY1lQ?=
 =?utf-8?B?S0J6UXlqT0NydTJKaVl6NlRhQXhHaG1KZWpXU1FTQUtyU2h5ZGEwUkpJYTda?=
 =?utf-8?B?T3h3T0JhV0N3dTljYlBqdENKM0dVeDNsdkJpU3pxRnArZVYweFJOaXN0dWJm?=
 =?utf-8?B?Qkk0UTFHV3g0WEY5T3FnN3FDNzQ2S0pnK1RLWS9tUXIyL1I5YkYyQWh3V3Ew?=
 =?utf-8?B?SG80Ykc1NU1hWmhoMFdSZ2hVWFgydVdaQXJ6MnVUT3I4ZEFUeGNIY0F4NXEy?=
 =?utf-8?B?S1ozMzVHSkJPWnhLbW5GMFdja0tNY1BiOE8vVUlPVmgvaG1BdVUvRHZDTEFz?=
 =?utf-8?B?NmtRRVFiVmFPSXl2bUhPSzlZWURCV09zM0c3bkwwbnVDZmVJUm41N2k3V01M?=
 =?utf-8?B?SHJBaFUzQ1NZRUpwclZMUTh4SzRBOC93TjhMY1NPSEFPT1hlY20wWXVYNmQx?=
 =?utf-8?B?ZnYrckY3YkZNa2RFK2pTQzNIc20wT3MydjVZckg0elgyVFhhQTR0aHRDQjZ4?=
 =?utf-8?B?ejdIdG1rdjE1S3AydEoyNGl4YzlZdVl5SksyNkpUTE5UM2VjSEdDY3lGSGpj?=
 =?utf-8?B?cFo5VHRYVHI4Z2kxN2w4UjhST0VvdmxwUU9Iem5hZHgwYUxIUFM1emM2ZjU4?=
 =?utf-8?B?UkNQSlk3Y3Z1bFdtenVzZ2VHTHZqeFdKVWVDamM2UDlJSEttSHA4dVZ1Q3c5?=
 =?utf-8?B?dlZ5dVozcWhVSis2N0tveW44OXVCdTNHUTRYTVVjSlBUbnhhbWUvdlRZcHRX?=
 =?utf-8?B?UFhnRlQvV1BrbW1JMkU4RjRlZzdYVHZUSVl6ZUtMVTRRa1J5SEVlK1d3cjc2?=
 =?utf-8?B?ZkI4cGlraUthSjlPRlJ0UEtJNjMrdmlyOW1rVHNTWXN1enE1bG5QRHBPT0xZ?=
 =?utf-8?B?blhCb3VhditoQWk2WGR4US96cVA5YWxOR1dBZVZzVlFUVFR5MmFmYWlyeXVy?=
 =?utf-8?Q?5Cn3HH?=
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)(7416014)(376014)(82310400026)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jun 2025 10:21:37.5902
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 823466d1-5f5e-4251-f9d4-08dda4e3ebc6
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:
	DS1PEPF00017099.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7909

On Fri Jun 6, 2025 at 12:03 PM CEST, Jan Beulich wrote:
> On 06.06.2025 11:55, Alejandro Vallejo wrote:
>> On Fri Jun 6, 2025 at 8:51 AM CEST, Jan Beulich wrote:
>>> On 05.06.2025 21:47, Alejandro Vallejo wrote:
>>>> --- a/xen/include/asm-generic/device.h
>>>> +++ b/xen/include/asm-generic/device.h
>>>> @@ -1,14 +1,20 @@
>>>>  /* SPDX-License-Identifier: GPL-2.0-only */
>>>> +/*
>>>> + * This header helps DTB-based architectures abstract away where a pa=
rticular
>>>> + * device came from, be it the DTB itself or enumerated on a PCI bus.
>>>> + */
>>>>  #ifndef __ASM_GENERIC_DEVICE_H__
>>>>  #define __ASM_GENERIC_DEVICE_H__
>>>> =20
>>>> +#ifndef CONFIG_HAS_DEVICE_TREE
>>>> +#error "Header for exclusive use of DTB-based architectures"
>>>> +#endif
>>>> +
>>>>  #include 
>>>> =20
>>>>  enum device_type
>>>>  {
>>>> -#ifdef CONFIG_HAS_DEVICE_TREE
>>>>      DEV_DT,
>>>> -#endif
>>>>      DEV_PCI
>>>>  };
>>>
>>> My objection to these changes remains; as a generic header it ought to =
be what
>>> that attribute says - generic.
>>=20
>> It is generic for any architecture where platform DTs exist (that is, an=
ything
>> but x86).
>
> Here you're limiting things to what Xen presently "knows". I'm sure there=
 are
> other architectures where DT is entirely unknown.

You'll struggle a lot to find one such arch unless you want to revive the
itanium port, and even then itanium would simply re-use x86's asm override.

>
> Furthermore isn't the work here part of the hyperlaunch effort, where DT =
will
> be introduced to x86? Hence "anything but" isn't quite right either then.
>
> Jan

Not a general DTB, no. A DTB defines the platform (in the same vein as a AC=
PI/
DSDT), with all platform devices enumerated there. x86 will not get any of =
that.

Without devices defined in the DTB, my original point still stands.

In general, if you don't have DT devices you typedef device_t to pci_dev to
avoid these wrappers altogether, and if you do you don't and the ifdef guar=
ds
stop having meaning.

If you remain unconvinced and others don't pitch in I'll just drop it from =
v3.
As I said, it's not essential.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 10:30:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 10:30:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008412.1387703 (Exim 4.92)
	(envelope-from )
	id 1uNULS-0002yN-UT; Fri, 06 Jun 2025 10:30:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008412.1387703; Fri, 06 Jun 2025 10:30:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNULS-0002yG-Rd; Fri, 06 Jun 2025 10:30:42 +0000
Received: by outflank-mailman (input) for mailman id 1008412;
 Fri, 06 Jun 2025 10:30: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 1uNULS-0002yA-I8
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 10:30:42 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on2060c.outbound.protection.outlook.com
 [2a01:111:f403:2412::60c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4a4ab52a-42c1-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 12:30:40 +0200 (CEST)
Received: from MN2PR18CA0020.namprd18.prod.outlook.com (2603:10b6:208:23c::25)
 by PH7PR12MB7939.namprd12.prod.outlook.com (2603:10b6:510:278::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.27; Fri, 6 Jun
 2025 10:30:35 +0000
Received: from MN1PEPF0000ECD9.namprd02.prod.outlook.com
 (2603:10b6:208:23c:cafe::55) by MN2PR18CA0020.outlook.office365.com
 (2603:10b6:208:23c::25) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.23 via Frontend Transport; Fri,
 6 Jun 2025 10:30:34 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 MN1PEPF0000ECD9.mail.protection.outlook.com (10.167.242.138) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Fri, 6 Jun 2025 10:30:34 +0000
Received: from localhost (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; Fri, 6 Jun
 2025 05:30:32 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4a4ab52a-42c1-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=dUpvWkEymrz7LxdVAiYzVbKiuQA4hI1oTG0FbKshCSp1DnlX8OS/aa4l5XuN2HaUp+lsGXELib1pmGoMi5fu/HHZodpM0aEuuNEER6jNahDQHD3dJgMxWcokR/6A3utVSvDtGMBbz0s84Dkqqf9OUzqHtGPiua6kS/jPhm2O/brua6BnmiYAaQd85R1n6nWEMTkBKflTmnq6PmwLOyfdiOxsH0rTiN6BbBXvQDhIyN8x7ziTm3ewsVpPfnODM9vyTII7Uw3R9FiL7A/dx0IBY3aA/2X3Ez0k3e9sw5Y3jZqmefBnm8U6V7MGLEYxWm0n8qLyRlV1qjCalo8Xrk+HXQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=wlI4OHdxVjEPk5j1MB5u+ErzkzH5FUOQtE2SUIybIJ8=;
 b=sSX9IBU0ZEEABfgA0ThCaVzRMUNXiLPZpJSQ5Y65gqU9PksNs+yBDEvXZv9536sS2GjrHT/G5XOqeJ1aw31zCanttEh9LlTlSpKZybtcTzhn9NvfLOxAJijChDmHQ7DF5QWyOKygeZAeqEY4tkYCAS+2Om/ngakeM1jJf1ddIJD0if0F99Ih7LT9nIsasQY9Yn3t4vuNAYIyNWovz3a2N2DBcZ77F4/uNjTMfzCHW8BaJQaQy66iGr8CV30I5BF4gek8wDjYSqopKZ/YHQE5bGA/P2EYDNjFysQiGfwMO49jQh5nj3PrV9p/aVdHfkRH6PV7xGoD1ksiFtu5lnBDCA==
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=wlI4OHdxVjEPk5j1MB5u+ErzkzH5FUOQtE2SUIybIJ8=;
 b=43tbBtC/7jPbo4vgijqy33nRKDOwWOQtuQT9r77CUqLat/dBVSIVj1Dv6juzr+owgxB1d0xzaB2gORIwwuKe4xIACVRHF8DHDA9isVP2IN8FNauqXBoPyIp+Zn3uvTYE+KyDjsKASnoKD5UZ6GLpyg8vAn1s34LOOzogI/xF9Ug=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 6 Jun 2025 12:30:31 +0200
Message-ID: 
CC: Stefano Stabellini , Julien Grall
	, Bertrand Marquis , Michal Orzel
	, Volodymyr Babchuk ,
	Andrew Cooper , Anthony PERARD
	, =?utf-8?q?Roger_Pau_Monn=C3=A9?=
	, "Daniel P. Smith" ,
	
Subject: Re: [PATCH v2 02/15] arm/gnttab: Break links between
 asm/grant_table.h and xen/grant_table.h
From: Alejandro Vallejo 
To: Jan Beulich 
X-Mailer: aerc 0.20.1
References: <20250605194810.2782031-1-agarciav@amd.com>
 <20250605194810.2782031-3-agarciav@amd.com>
 <765d42ec-a421-4b8c-80bd-30c909e81e8d@suse.com>
 
 <66d75dad-4407-4b09-8dd3-c61b5d05ed91@suse.com>
In-Reply-To: <66d75dad-4407-4b09-8dd3-c61b5d05ed91@suse.com>
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: MN1PEPF0000ECD9:EE_|PH7PR12MB7939:EE_
X-MS-Office365-Filtering-Correlation-Id: fea09f2a-1183-4a72-e267-08dda4e52bf4
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|82310400026|36860700013|1800799024|7416014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?VzBrcm1Pc2ZhdVZsZzhQTkE3QUl1YjIrcVo5dEhuVGlGejlOODNXMGVCcFdx?=
 =?utf-8?B?YmlPSVlERWJGbEZqLzlhUThXRmMwVUthdG5aSVJtS2t1UUhGNmRibVFDRE9R?=
 =?utf-8?B?UkVOc2RZYTRzZ3BwS0lYMVZsd01SR2VnaTRVWnZQVEZ0T2xDSTVPd284MWJH?=
 =?utf-8?B?aWVUUjYxQm16TFhPdi8remdneUhRRW9Nd1RnQmhxZmJDN1BLTHhqTG1EdE1K?=
 =?utf-8?B?S1dMb2VBL1d3enpsOG9GUzhpWkZlak4zU3luTzBiaW5jSUx6ZXY4UXFra01a?=
 =?utf-8?B?YzNIWmxkWTl1enoxYTJzK0lWRzBIaHNRR3RWOFcxMVVRays1TEo2TDRUMlJj?=
 =?utf-8?B?UldlVHBWWncxYUlBODFHVHdaUDM0eWQ4UnphL2FzQlBpZElLZENkeEd2V3pi?=
 =?utf-8?B?dHBBdXVTNHk0NVVrRllOL094OTAvb1ZzY2dWeEV6cXBWUFFPTDluTWt2a00r?=
 =?utf-8?B?WnRLSVBPdjFCWFB0cjhScG1ld3FsdWU1alRWV2dHRDBySnRlZ3ZiWndNYU5n?=
 =?utf-8?B?eUZmbkhYQU9zMUI0ZDZFNHRUS2JHMWh2dnV5Vkt1bkdqUnBVRWl2d0NFT0RO?=
 =?utf-8?B?ODZIYWVpT0s2S0kvV2g1dlFVY0toQ3Fwa2gyOGtFc1VGVjM2NVU3NFowRnpz?=
 =?utf-8?B?YjdGRWhuZisvMFIwNXFLMzgwUmdYYy9QYkVNT1ZmUjhaM3BueGtUdzNQVzBz?=
 =?utf-8?B?UHdVNnYwZURYSUxGcTNvb2Jpc2hmWTQvSE9Kdll4RXFGbmhSTWZ3WWJkdjRm?=
 =?utf-8?B?YmFkN3MyeEE3ckQ3M05KcWVneDJVV1hrelFhMTZkOUFlQndReEhwdnlwKzFJ?=
 =?utf-8?B?cWJVeGczci9xQ01oZkxVYUlLWHcra1ZnV0p5ME1jSTBnQWVZbS93Q0VEUHU5?=
 =?utf-8?B?RjJYamFibXkzOGZmQVFwOWdDOVZzbU5yUDF2V2VFWGJjNGp6Z3g2YUg0MnhM?=
 =?utf-8?B?UkFhT0drSmt6V0NDYnYzc2FTVlFwVHc3eDVOS0FDR0NubEJvemJmSVNZckht?=
 =?utf-8?B?WVhrcDlpUEVzaWF4TkxGNGw3RCt2aGl4dEFoTXRZcU1vRjB1N0J0VTdFOWdR?=
 =?utf-8?B?RncvN1B2S1NOYVBzdVRqVy9HUXljeE5OSjFWZUM5NFN0WmFlWmJLL1NLak5o?=
 =?utf-8?B?ZnlEYUVIaFZ0anI0Q3F6WllrV0ZBckdtTHh1dzVZS2lMYWwvMnJKeUtubzhh?=
 =?utf-8?B?Zm5wdmRBVVVyb1kwS1ZGTGJNV0k0MlRYTDlkVzl0cmcrNGUvYnNlbnlDMDda?=
 =?utf-8?B?TUFvZTZBRi9UcnIrUUhWRUtqZ1pRZEFsdEZzakVFZ0JtNWJObHFVSERIdkhF?=
 =?utf-8?B?UHVlYzVuQmlCQjZoVTg2NzdPK3k3b1AzL3luaGJERnFGYVNpSGkwUHdMeHMw?=
 =?utf-8?B?M1h2Zm14ZUZkRXJFSTFCdEJOT0FDbEZ3UXpOeER2eURtNklMY3R6WDRDQWZV?=
 =?utf-8?B?QS9ydGdRUXJKRjFEQWN3M3R2UXlJU1M2TS9kWVNieXRka0w3VXA2a2MzS2xo?=
 =?utf-8?B?VDl4NTJzSUtGeUg0MzBReitiSU5xVk82MEtyTTBXV3Q3TTBFT3JUbkhvTitW?=
 =?utf-8?B?UkFrMUlRZGZDbC8rRVI2dS9GZEtsUENvbzR2Ukt1aklBalR3VXgzdmFwdHdT?=
 =?utf-8?B?MGJqY0ZmZEhud083Ry96OHdqWGY5NmlDSUdBTEZiVDZpcnFUclIyRG5WbzZz?=
 =?utf-8?B?SWowbzVYd0pGQll5eDlwTkErVlMwVlMxa00yTFlKOWU3TDQwM3o0aHlCL21D?=
 =?utf-8?B?MUUyazdvc3RmLytYc0VDNFJLaHNEekZHOTF5Si9Rc0lCQ3JjU3dPby80NHov?=
 =?utf-8?B?UjBUMHZPUjNYd09YeGFZcllQZHZIOExUeitVQzdaRy8zSXgvYktpT2paVjFz?=
 =?utf-8?B?Q3FpK0ROYWVvRmdrM1lyYSt0cGFtZkYwVXRqRC8yeVhoUS9pTkc5WGluRHo5?=
 =?utf-8?B?NWx4bVFzWHgySHVYRnlrYllvU3hOdE84K2RncHdSaWd2QllwMmdXVTk5T2Rx?=
 =?utf-8?B?eFordXJXOElJajZkaDhvOXd5eDFJaTFtdjFtVStkZkhRcXJURk52cG8zS0Zy?=
 =?utf-8?Q?sEglyl?=
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)(7416014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jun 2025 10:30:34.7945
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: fea09f2a-1183-4a72-e267-08dda4e52bf4
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:
	MN1PEPF0000ECD9.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB7939

On Fri Jun 6, 2025 at 12:07 PM CEST, Jan Beulich wrote:
> On 06.06.2025 12:02, Alejandro Vallejo wrote:
>> On Fri Jun 6, 2025 at 8:52 AM CEST, Jan Beulich wrote:
>>> On 05.06.2025 21:47, Alejandro Vallejo wrote:
>>>> --- a/xen/common/grant_table.c
>>>> +++ b/xen/common/grant_table.c
>>>> @@ -42,8 +42,10 @@
>>>>  #include 
>>>>  #include 
>>>>  #include 
>>>> +
>>>>  #include 
>>>>  #include 
>>>> +#include 
>>>> =20
>>>>  #ifdef CONFIG_PV_SHIM
>>>>  #include 
>>>> --- a/xen/include/xen/grant_table.h
>>>> +++ b/xen/include/xen/grant_table.h
>>>> @@ -27,10 +27,6 @@
>>>>  #include 
>>>>  #include 
>>>> =20
>>>> -#ifdef CONFIG_GRANT_TABLE
>>>> -#include 
>>>> -#endif
>>>> -
>>>>  struct grant_table;
>>>> =20
>>>>  /* Seed a gnttab entry for Hyperlaunch/dom0less. */
>>>
>>> The description doesn't make clear why these two files need changing.
>>=20
>> What sort of description? I removed a conditional include  and added it =
to one
>> of the few places it didn't include it already along with xen/grant_tabl=
e.h.
>>=20
>> The title does say the patch removes the crossed includes in asm/grant_t=
able.h
>> and xen/grant_table.h.
>>=20
>> It's, I hope, self-explanatory regular spring cleanup.
>
> Then I'm sorry, to me it isn't. "Break links" has an entirely different (=
file
> system) meaning to me, in the common case. Plus that says what is being d=
one,
> but not why. And it's the "why" that I'm seeking clarification on. From y=
our
> response to my remarks on v1 I was concluding that the issue is that in a=
 few
> places asm/grant_table.h would need including additionally. I didn't expe=
ct
> any #include to (need to) go away.
>
> Jan

Let me take a step back then. How about this commit message for this same p=
atch?

  xen/gnttab: Remove cyclic includes in xen/grant_table.h and arm's asm/gra=
nt_table.h

  The way they currently include each other, with one of the includes being=
 conditional
  on CONFIG_GRANT_TABLE, makes it hard to know which contents are included =
when.

  Seeing how nothing in either header depends on the other, let the include=
 sites
  include both if both are needed.

  Signed-off-by: Alejandro Vallejo 

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 12:05:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 12:05:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008465.1387739 (Exim 4.92)
	(envelope-from )
	id 1uNVoe-0006mL-0T; Fri, 06 Jun 2025 12:04:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008465.1387739; Fri, 06 Jun 2025 12:04: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 1uNVod-0006mE-TA; Fri, 06 Jun 2025 12:04:55 +0000
Received: by outflank-mailman (input) for mailman id 1008465;
 Fri, 06 Jun 2025 12:04: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 1uNVob-0006m2-Oa
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 12:04:53 +0000
Received: from NAM04-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam04on20615.outbound.protection.outlook.com
 [2a01:111:f403:240a::615])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 71f265ff-42ce-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 14:04:50 +0200 (CEST)
Received: from SJ0PR03CA0268.namprd03.prod.outlook.com (2603:10b6:a03:3a0::33)
 by PH8PR12MB6890.namprd12.prod.outlook.com (2603:10b6:510:1ca::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Fri, 6 Jun
 2025 12:04:46 +0000
Received: from SN1PEPF0002BA51.namprd03.prod.outlook.com
 (2603:10b6:a03:3a0:cafe::5c) by SJ0PR03CA0268.outlook.office365.com
 (2603:10b6:a03:3a0::33) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Fri,
 6 Jun 2025 12:04:46 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SN1PEPF0002BA51.mail.protection.outlook.com (10.167.242.74) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Fri, 6 Jun 2025 12:04:45 +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, 6 Jun
 2025 07:04:45 -0500
Received: from [172.26.5.4] (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, 6 Jun 2025 07:04:44 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 71f265ff-42ce-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=XIgamSVNy/go73t3KWs83YbHQWVO5EbZ9LfDLFPN/Hs8goSBqaISIRRoTfP+vb+iAD8GHjeb1dXEH9JhVVXfXra0vpunNHlThl1H8U6yDptRf/QcL4LGuytCtqWL3dQwxJQl8dBemQ56ZHo4tMyzUYB+a+1ghjJxxxjb8P+50fY3QDRHVtU35HD0ozfIo9MN4DNdlr3cvy8pJPvqJIPp2nCcmVkB+uuYVEpoL1ft5HFN43dXbVo+B6sQ/MwyqedxZSDAVxmSOWFqTMh7C8kj3GbU3UWqYN2j2AVvik13dZlHSMRvTS1GxinbOIPK8Sbh6pkIjt9/xnlYg6gUXYS2IQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=FDHgc0Z1OVo3mN5DyXW2eRyjhMEoj80iTby6hxyWtOM=;
 b=DEfQEVq/j3yW0+Y9qGUmWWXZ5aLQUCmZ2TTIe6nUkpZgiEBwfPJauA951YMoYpjb94G7jVtJDNIIbQkVam7k97CIy2E1aIhdouKUKd0RKpIAmaKR1UwImEqQW7ybgM1QBUBM45NT4l8Fd322qqwZealApfrxP3D6KrE/MriJdxdTUN61Kp2Ju4aIc5lEcn5L/ocGSB9Yo3kW3zsPfPr71fTIgNPiAZY0ja8J1d1PL4/zKcS0NtQfXCJwYfzbg6QrvR0HggBhCg9SrMRCsBqluNiFzSQB7NRmQ5uIg9RPGZljUWsz3d2fOy8Y7XwiL7xdTG2ClWAWaY9dbE+DjXjxMw==
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=FDHgc0Z1OVo3mN5DyXW2eRyjhMEoj80iTby6hxyWtOM=;
 b=Ml69vi+h/g53ZiWBB28ef1BM4qJ6VQBjfdv4SGYpxD/gVUKE+atbYxDSlpwI2w/cKXHDNwnE8HAD3tmiER8W3GE2SiGC0zl8v4CF57Sno5oyF5YtYm29luzXsWT4dbQt1/oLao1cHvdX5F43acqcsRkyJM9zAknm6xmWBYAr/B4=
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, 6 Jun 2025 08:04:40 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/2] xen/arm: exclude xen,reg from direct-map domU
 extended regions
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?=
	, 
References: <20250513195452.699600-1-stewart.hildebrand@amd.com>
 <20250513195452.699600-2-stewart.hildebrand@amd.com>
 <2491389a-cd47-4917-9ade-7082f1ebc678@suse.com>
Content-Language: en-US
From: Stewart Hildebrand 
In-Reply-To: <2491389a-cd47-4917-9ade-7082f1ebc678@suse.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
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: SN1PEPF0002BA51:EE_|PH8PR12MB6890:EE_
X-MS-Office365-Filtering-Correlation-Id: 889fcc9f-cca8-4914-9686-08dda4f25443
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?S1RmN0trWUtaYTcrOUt0ekZwNHpQczVTK1VaK3JGK1oxa3Rqd05aMFp0NWN3?=
 =?utf-8?B?WXdpdkhjRTViWG9zNmZXNFJlbGMrY2Jwc1ZwSDd1SER6Wm9GaHNUYUdDbEZG?=
 =?utf-8?B?U25UVU1pSC9IemNLak9SdEJiRmhhb285YXMxK2Z1VlZMc21DeXpTd0hmallt?=
 =?utf-8?B?Tm5hT05FVktrSWxaRS9OT1J6VUQrMTAwbEJoNnB1NXg1Tng0QzhDa3FTeFdN?=
 =?utf-8?B?VHhCSWVMNUpURC9YR1J4R01lVFZGLzlqcldra3V3cnJ5bHI3YmNLN0tWS2dV?=
 =?utf-8?B?STVQT21jT0ZUV2IxY3MrbSs0bzM3SDJWU1J0K3kwQVpBMDVrTDRpRFkrbkdW?=
 =?utf-8?B?cTRuT0cvZG9aNldTV2pFTlpzY1dJdlNNcjdxNzhNNTdnYkc1NUhmNnlaTHdp?=
 =?utf-8?B?VnJHc3IwTjhNaiszRlh3MmhnUFltWnF2ZXZGUEYvU2gwN3lKOXdUVE5WVE5u?=
 =?utf-8?B?TmhJS2dKcXF0a01zbDVpMUVSM1B4Q3hiNGFZU0U3RHhKYmlZaHRNVmo1VzNt?=
 =?utf-8?B?cWhLYlZtcllWR2RQWE5yc1ZKRHVoSkQvb21aUnFkR3NYQUNWWFFLWWJoWTJ5?=
 =?utf-8?B?NUJJUTIyTTVrV0FqYkVHTUtwWjkwdUFad2V6T3VEdmJReWx1SU92bmVnRDdy?=
 =?utf-8?B?TTlNOEtrd3pPWUVkSm0zUGIwQThpcDFHSENKQWsrTkVPUENCa0F5RTV0bjNn?=
 =?utf-8?B?N3lFOVRyNXVPN25IT3BBbTMydXU2aGtOTFFCQnJkZUtaSjBjZlBQUzFyTWJi?=
 =?utf-8?B?THNjdjY2WTQ1ZU5RVVcyT21PRThHeTdKZEp6MWNRTEJmRllWQWR4UldtOUF4?=
 =?utf-8?B?dTZOVVlvemtiM3NGNi9pbW50bEJaeUFRNk0wNS9sOG1NWFhIazgxVVlLZE9o?=
 =?utf-8?B?bDZ5NnBhS0FFcG9LRS9Vak9mWHhzc1p4YlBhWEFrRXlWdVc0MUNQMHlQdjFa?=
 =?utf-8?B?VVBFUTJxUENjWEp4TS9Nc1FUUzh1RXh1cDdIWkNKaTVtamxpcFRQd0VIOEpu?=
 =?utf-8?B?czQyVm5IclM5aU1UbzlGTGN1YkF0ek9HV0cyUkJLN05aNVNjbFlGQzBUMkQr?=
 =?utf-8?B?WllSSEtSc2JBWWw1dDlZRFdpT1VrR0RBdDI0WDUyRXl1MjJ1YjZqU2NGd0hz?=
 =?utf-8?B?UTNEbHdIdE5BOXRsN3ZocVk2aEJpZExXa2dKTzBkUWNYS2F1cGRPYngza3BJ?=
 =?utf-8?B?bWNXa2NMZFdEV2tBbXlsSVhkLzRCbTVjU1hQMDVlank3VVRxMUZwUjh4d1NQ?=
 =?utf-8?B?Nk45a1o1end5eGZQMjRMWnpxejBjckJydm1IMGdoZnNOdmVGWTVRSVRUUENa?=
 =?utf-8?B?MytCWmNqNkJ4Vy9Cc0Ewck9UckN2V2FGYzFjWFJDZmxsU3Z4eFFxU1cydVNt?=
 =?utf-8?B?T200OVJva2hDVlJEMTRwNThJZm9wUExzSWpxYXd5RXVYeVpRWFFXS2RqR0U1?=
 =?utf-8?B?TGZMMy9lMUdYbjV2TVBSbFRIRFBXTldDbHRmYU1obFZiUndlYTN4bnZJKzNO?=
 =?utf-8?B?N0ZMWU5WdnNHbFpXNHA5dkhoZ2ZGNVRQZStyRWR5d25yRmlEbS9iQ2tpVUdM?=
 =?utf-8?B?c0ZjSVJwVTdRbzljd0QyZ0FPQUtZSWVPZlUwSnM2MEUyeW9yaHZwODBRSitU?=
 =?utf-8?B?c0ZEdlBJeFFhdit5b2czTXFrYlNkQndua1c1MnNNanAxbHo0L1RReG9pTDVj?=
 =?utf-8?B?VDNJVk5uRWdUT3UycUNwdmxqeTNDOUdKTGFTbDR3UTdlVHNRd01FdFNEb081?=
 =?utf-8?B?eXlRMHQxTDlPc3Y0M3NiNGZQNnJxSWYzM1hhRlZiVSt5cEI5aUpjSEpzT1NK?=
 =?utf-8?B?RDBSUGNpeUZFUU50S3FaQkNpMHhHT3czYzRublVpQm5NTGlSazJmMzZlUjZn?=
 =?utf-8?B?cWljY052VWVYc1Z4WU5CcTBML1FlV0FERUc4aTlBVlZ0V1ZtakYvS1lxSGhX?=
 =?utf-8?B?c0J0T1Eyd1FJNmVza0NSZVlmWGl2blR2eVVaSHBXaXorZnFoZ0RBb0Y3VG9S?=
 =?utf-8?B?UlBCUWlDUEhzZmxBVDF2S3d2SlRGUitVaVg2KzVjaWVnZWMyWVkvY1ZPZmJ6?=
 =?utf-8?Q?/sT9ot?=
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: 06 Jun 2025 12:04:45.8495
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 889fcc9f-cca8-4914-9686-08dda4f25443
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:
	SN1PEPF0002BA51.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB6890

On 5/14/25 02:49, Jan Beulich wrote:
> On 13.05.2025 21:54, Stewart Hildebrand wrote:
>> --- a/xen/common/rangeset.c
>> +++ b/xen/common/rangeset.c
>> @@ -433,6 +433,20 @@ bool rangeset_is_empty(
>>      return ((r == NULL) || list_empty(&r->range_list));
>>  }
>>  
>> +int rangeset_count_ranges(const struct rangeset *r)
>> +{
>> +    int nr = 0;
> 
> Ehem - this and the function's return type want to be unsigned.
> 
>> +    struct list_head *list;
>> +
>> +    if ( r == NULL )
>> +        return 0;
>> +
>> +    list_for_each( list, &r->range_list )
> 
> Nit: Either you deem list_for_each a pseudo-keyword (then a blank is
> missing) or you don't (then there are excess blanks).
> 
> Further I don't think this is valid to do without holding the rangeset's
> lock in read mode (irrespective of the function return value potentially
> being stale by the time the caller gets to look at it, which is no
> different from other functions, i.e. falls in the caller's
> responsibilities).
> 
>> +        nr++;
> 
> And then, if already abstraction is wanted, wouldn't this loop better be
> yet another helper (macro?) in xen/list.h?
> 
>> +    return nr;
>> +}
> 
> Finally: If this is to be commonly used in several places, having such a
> helper is likely fine. As it stands, the sole caller is an __init
> function, and hence this is unreachable code post-init (which while not
> formally a Misra violation in my eyes effectively still is one). Aiui
> the same can be achieved using rangeset_report_ranges(), with a new
> (__init and static) callback function.

Moving rangeset_count_ranges() to rangeset.h might change the situation
slightly, but I'm not aware of any other potential callers so I'll just
use rangeset_report_ranges().


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 12:23:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 12:23:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008494.1387768 (Exim 4.92)
	(envelope-from )
	id 1uNW6n-0001Df-K3; Fri, 06 Jun 2025 12:23:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008494.1387768; Fri, 06 Jun 2025 12: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 1uNW6n-0001DY-HF; Fri, 06 Jun 2025 12:23:41 +0000
Received: by outflank-mailman (input) for mailman id 1008494;
 Fri, 06 Jun 2025 12:23: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 1uNW6n-0001DS-1e
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 12:23:41 +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 1318c193-42d1-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 14:23:38 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a4fd1ba177so1512094f8f.0
 for ; Fri, 06 Jun 2025 05:23:38 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23603078d65sm11356755ad.5.2025.06.06.05.23.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 06 Jun 2025 05:23:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1318c193-42d1-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749212618; x=1749817418; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=KHdzGdxdJ9jH5o+5dFL/LcSH6lFlDVOsAbHtZ/Eh9bU=;
        b=YjdNE+qmzOxukwUVqOPtOnkdEVR1FK5Xy+vGsUW+LJZmCo+mh7p/1V5goUW03T42PU
         AHFg9kIDM+XbayyfHzhmpZG8fsVOpHnDsDFS1P8llnTRoa4JqZzi8QqdVtBQUGONFJJB
         yuQMLNQ7lmW0m9vjVPX187vIZtdBJFj6V7z67NpX9uWx3DAK/Gtkn+BF2IfGY3jxNsn8
         KEViR2C4NNIwjbUQ++qu7HCwXF0f50Q85gZ7Ql/VOzh+ylIt7A4y+asw6dRvYcp/RhKW
         wV9ByeZRHBY7GpNEDKn4CQVMY0jzYH/1sZ5ZALxUrT9is/3c+BkDMomyQmc4zIfnmvjT
         9J4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749212618; x=1749817418;
        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=KHdzGdxdJ9jH5o+5dFL/LcSH6lFlDVOsAbHtZ/Eh9bU=;
        b=pQaQZLLIR2XHFoNvR3WIoNOe6dorqvXeb51I6o9cSc2yMMr4N9o1r62X1Nh+UNJPf2
         NxxmW4sG2YDu/PhDo0EKIeyhA7Tv0mDm1uuwz1q/+XALL3lgApPLHvcdgqJD39Md38Mz
         V5ppIcf5fVddn+5fcJxyESCQcfxFlxuevYteazpfs/xswgZKQ3M2HyKGRB6GT/+U/MDo
         37h9X+t0GNtwJ55BRL+zYvsWo89gPwIxAOW+uyMP5Y8dvs7biSVLAFBI5IIOMUTlfnxg
         SY3HYy2e+UbleR9iSY9o7dLbMckNBHkYASWQHD/0HQDoqRo0LyVdlVJI+LHWn+sSKJ0G
         PwZA==
X-Forwarded-Encrypted: i=1; AJvYcCVlH0LFo8zpR0Nc/VKCoT95pH6q8caEa5H5FFlHcJSfMM+txHxrZnajjCPY95DYYMftrOmhx7R8Cs4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxP9+74Zh58qflYmDvDn6XX4ooRpCdjcMIPr8xOp/7ur/Hn2viD
	FkjJW2z3YASq++SQ12V0BEAFYAzu3XOahY8Cfi7LU/XTv5v1nNr1CbQS3qAxzF0ZNA==
X-Gm-Gg: ASbGncuUKV6F/jEw/zctfsTlo84PFIqGTS/5R/d5U9s5cGE9phGylP28oP7SLILsIcK
	ME01GpcVWhTyWtoml9SjEw9f9KivtF2yklUG6SXA0c0P9FL0fOvIqdNaMFG/mDxxSZuFg1Qd0sl
	aRkpwdM6ZWGCglRgtkGkJ21cG4pCBZBsURgQ0Xfwz1KMuBPDR2PNarGHMLRX5Tnw7zXyYVrK7Jp
	M5yONFtgAw1hp2B2fHd4rBEXXtDvFgsRCmnl+3wWfbnOK0IlO/e3spBq9VvIpoUoVBEoj6exTyg
	OpI49IflxPvQovrucYt5Jl1K1KMcye43eEhJp5QybEeDHJZ/zCJvokgpTeDz8q1wewY7UT4DGpO
	gSiO6kzbb1IPHvSVbh5gz1Oat2aWmw1RD1UMoZ7pJ4IzBoBg=
X-Google-Smtp-Source: AGHT+IHborE7MT15/hhoZpac9B1XuwQpHpW0607nfflNxpEHBfKMPLUyExfowzvylOUEumQCiEJr7w==
X-Received: by 2002:a05:6000:2507:b0:3a4:da0e:5170 with SMTP id ffacd0b85a97d-3a526e1ed18mr6679358f8f.27.1749212617920;
        Fri, 06 Jun 2025 05:23:37 -0700 (PDT)
Message-ID: <34c4a8a0-e4fb-4db5-a8b4-19f3e34957ac@suse.com>
Date: Fri, 6 Jun 2025 14:23:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 02/15] arm/gnttab: Break links between
 asm/grant_table.h and xen/grant_table.h
To: Alejandro Vallejo 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org
References: <20250605194810.2782031-1-agarciav@amd.com>
 <20250605194810.2782031-3-agarciav@amd.com>
 <765d42ec-a421-4b8c-80bd-30c909e81e8d@suse.com>
 
 <66d75dad-4407-4b09-8dd3-c61b5d05ed91@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 06.06.2025 12:30, Alejandro Vallejo wrote:
> On Fri Jun 6, 2025 at 12:07 PM CEST, Jan Beulich wrote:
>> On 06.06.2025 12:02, Alejandro Vallejo wrote:
>>> On Fri Jun 6, 2025 at 8:52 AM CEST, Jan Beulich wrote:
>>>> On 05.06.2025 21:47, Alejandro Vallejo wrote:
>>>>> --- a/xen/common/grant_table.c
>>>>> +++ b/xen/common/grant_table.c
>>>>> @@ -42,8 +42,10 @@
>>>>>  #include 
>>>>>  #include 
>>>>>  #include 
>>>>> +
>>>>>  #include 
>>>>>  #include 
>>>>> +#include 
>>>>>  
>>>>>  #ifdef CONFIG_PV_SHIM
>>>>>  #include 
>>>>> --- a/xen/include/xen/grant_table.h
>>>>> +++ b/xen/include/xen/grant_table.h
>>>>> @@ -27,10 +27,6 @@
>>>>>  #include 
>>>>>  #include 
>>>>>  
>>>>> -#ifdef CONFIG_GRANT_TABLE
>>>>> -#include 
>>>>> -#endif
>>>>> -
>>>>>  struct grant_table;
>>>>>  
>>>>>  /* Seed a gnttab entry for Hyperlaunch/dom0less. */
>>>>
>>>> The description doesn't make clear why these two files need changing.
>>>
>>> What sort of description? I removed a conditional include  and added it to one
>>> of the few places it didn't include it already along with xen/grant_table.h.
>>>
>>> The title does say the patch removes the crossed includes in asm/grant_table.h
>>> and xen/grant_table.h.
>>>
>>> It's, I hope, self-explanatory regular spring cleanup.
>>
>> Then I'm sorry, to me it isn't. "Break links" has an entirely different (file
>> system) meaning to me, in the common case. Plus that says what is being done,
>> but not why. And it's the "why" that I'm seeking clarification on. From your
>> response to my remarks on v1 I was concluding that the issue is that in a few
>> places asm/grant_table.h would need including additionally. I didn't expect
>> any #include to (need to) go away.
> 
> Let me take a step back then. How about this commit message for this same patch?
> 
>   xen/gnttab: Remove cyclic includes in xen/grant_table.h and arm's asm/grant_table.h
> 
>   The way they currently include each other, with one of the includes being conditional
>   on CONFIG_GRANT_TABLE, makes it hard to know which contents are included when.
> 
>   Seeing how nothing in either header depends on the other, let the include sites
>   include both if both are needed.
> 
>   Signed-off-by: Alejandro Vallejo 

While definitely better as a description, I still don't see the point of removing
the conditional #include from xen/grant_table.h.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 12:43:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 12:43:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008500.1387778 (Exim 4.92)
	(envelope-from )
	id 1uNWQD-0003z1-56; Fri, 06 Jun 2025 12:43:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008500.1387778; Fri, 06 Jun 2025 12:43: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 1uNWQD-0003yu-2S; Fri, 06 Jun 2025 12:43:45 +0000
Received: by outflank-mailman (input) for mailman id 1008500;
 Fri, 06 Jun 2025 12:43: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 1uNWQB-0003yo-FU
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 12:43:43 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20628.outbound.protection.outlook.com
 [2a01:111:f403:2412::628])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id dfa4c857-42d3-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 14:43:40 +0200 (CEST)
Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
 by SA3PR12MB9130.namprd12.prod.outlook.com (2603:10b6:806:37f::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Fri, 6 Jun
 2025 12:43:36 +0000
Received: from PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264]) by PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264%2]) with mapi id 15.20.8792.035; Fri, 6 Jun 2025
 12:43: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: dfa4c857-42d3-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Btvxw47Pm4qB/W6gM+nsOGl32mLWbhpu1H6AKzoel2oKfFsoyHND9Rq1Vxj8fnlb5yCbAOzdd92qwKlKbx0LLxcKoYCzBVB27CtNqKZhz45x93na8cLhIVXPHjkdn3u3A0SZ/xWywcfoPsH1kNL+d7/40NkYm3NAMQOufnnukCplouRwplHP9uflurrkQzkTidMFkU+NQ7XrHPqMwLdjUePnqpH+UoBw8SDOzMHXx1cVhkgZ1ZQn9TRBX0x87jBfsKg+TTVz9CWxft6KVnzxXkldAQAUHgxrNW0E4KIqWZyns+L8n3zyHy4bdGPXxdUKwqewr0fm/Kzfpx4QsYDWtQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=0FXMRtkayhpDdmr07UxFIaSnVNcobeRmDbPAwfEKrCU=;
 b=swwpeMQBiGWPmgdaeK15jkd5AFmgQDqMNRXj7ashAgEaAGxM5RQP+a8a2pAkULsft8eF0hkzkTtYFKH2Imnc+eLQ4m6+ZSJr/g/0U7CAwY720HKR5W1YAgdDQQ6jVOZCAsmpOLA8xmqG1LRu8j8GDq0AYCZyN+iRnkDFPRx1gdahnN13w1jI3gQrCzCfqxcswoWPiRiQ8iBkOvZJdobdshhyMffVwe5RytoECl5OkZBCGhBzr4zIU/7LwNVU/ICcgVBP95HYDRF7IgsJNuklSJj/IyuPOsh29I/TUBvLSdJEuZdHx4acc9PUhAm5/7+TqAOjjxMtjMUhx4IxZvVyxw==
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=0FXMRtkayhpDdmr07UxFIaSnVNcobeRmDbPAwfEKrCU=;
 b=DnUEUFNR5rxEKqBSPuoM2e/EJ9ORe6rwuImYmTVWISuL1B9/qyeMDyMmffewSup0DOG8jiL81lgVaIudHGXksDacmwd5WVZuEVlY9YntnAT/AehxHifZX3X+vQcWykK6LL9c3UccqiqgovquymUBxT5OfgiawjW2Rm0xtP2usrk=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <253dc1cc-b6b7-4cdc-a0e1-9fbd6be4efa0@amd.com>
Date: Fri, 6 Jun 2025 13:43:32 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/3] arm/mpu: Introduce MPU memory region map structure
Content-Language: en-GB
To: "Orzel, Michal" ,
 Ayan Kumar Halder , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250604174311.754899-1-ayan.kumar.halder@amd.com>
 <20250604174311.754899-2-ayan.kumar.halder@amd.com>
 
 
 
From: Ayan Kumar Halder 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P123CA0230.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:1a6::19) To PH8PR12MB7326.namprd12.prod.outlook.com
 (2603:10b6:510:216::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|SA3PR12MB9130:EE_
X-MS-Office365-Filtering-Correlation-Id: eae483c6-b1f5-442e-6667-08dda4f7c137
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?ZHY3a3VjdktaNlgzZVYreEg1d3RvU1lxQnVRK1UwNElFMzlvK05LWSthbzJI?=
 =?utf-8?B?MXVMV2xGcXovYUE1SCsvOHVyY3pVS0poN0Raa1JmaHhMMUhIS1JGeG5xRXdP?=
 =?utf-8?B?NHk1ZC92WWc3WXJkM3BIUzRTZzluV3BnS3BVVzNlbjRScG0rZTJyblVldWk3?=
 =?utf-8?B?RVlEUGhkUDVVaURTZWpNOUtnSnc0RHJPaEh5MDlHK1ZOTFk5OG5ydVliajVH?=
 =?utf-8?B?bnE5clptZWFNU3Z4U1Jwa3REcmlmZEgzNU9MOFFSYzFXZG9BZE9VQ3NJQkFX?=
 =?utf-8?B?Q2RFNVF3MTlQckNtQnZER1V5Z3ZFTTFUMi9DTGlzOUI0SHoyUE1YMk9PQktX?=
 =?utf-8?B?dFE4Y0Yya05xNCt4QnJCdHc3YlVyNHhKVVQ0eExLcktXaGdZVWVrQklVV1dp?=
 =?utf-8?B?bkw1emQ4cFAvOUVTcEFidjFzQWs1L1BUUU9vUVlnODNDRjUyTWtaQUw2akFX?=
 =?utf-8?B?bDgxTHZ2YlJHSzJIdmV5ZTB6cC9SZmVIaEl5OWZQL1VVNVN1b3JoY1h3Q1Br?=
 =?utf-8?B?bTE1QUFjSUxocXhBLzhJNFVyQUVQRzFMbHN1Zmp5UjRmTWE2Q3JBeWxRdFBL?=
 =?utf-8?B?ejNjWWRkOXFacnpkdlQ4RDZrcjFNSHdkMW0xQUd2Nm5xWklZZ1JZa2dXeVhZ?=
 =?utf-8?B?NWlZd3J4VzF5aG96MmxsaTlUbDg0SmNxdDNNYXVxQXdXeUFVbzZvSFZFK2xi?=
 =?utf-8?B?UFBSekNxMXpESy9USVVZSVZWcVBuSWgxODJLb3QrNDZrdzNTWElQYUp0K3Zk?=
 =?utf-8?B?b3BBRE15dWpZOFRGcUwvVUo2TVB4TUNFMUdFeE1JNit2R0JjN2liazZJcFlH?=
 =?utf-8?B?UlZGSjlVanczNG5nMGd2VitwN1dQS2ZTN2I5dWhESUEyVEVwWnZnMHNlSjdD?=
 =?utf-8?B?YW5yemJwbUtVOVpnaWJwQ2E2bnNpNmZ6S3NoTnRhZ0QzVytSaTIweXE1YUhT?=
 =?utf-8?B?NW5qcEZwNDVvUUIrMHNETUhSRy9NTkY0M3gwWS9XaWUvUUFiNG9OeDcyelpu?=
 =?utf-8?B?cnlTNWd2bi82c001bGlyUEZkeWx1Q3l6N1BGejFuQjhUMVVGTUhkeTZ1ZlJX?=
 =?utf-8?B?UHRWTjBDa2R0Ym9weSszaks0a3VqL0VqTTFnNVdyVlpZZ254cER5TUU1amk4?=
 =?utf-8?B?VzR5TU8xc2o2M1lIcGozZlIrRDE1elg0RmUzNzN4SE1rc3JVVW5BcGIyaVd2?=
 =?utf-8?B?WWNIR0NGeVVmenB2NXluQlpuVkQ0ZUNva3lyaUhTdXZwQy9EajVlTzE3UGFU?=
 =?utf-8?B?dGFkV1lsUUVPT3B0dzBNNXJHZmJ1eGhMaHVDbHM1cFZYTVFWSWxlUE4xWStK?=
 =?utf-8?B?WktrbytROWx3aFl3ZEhrT1l6UmhoaEhxMGkxRTIyeXNqYUhkVU81UENMYmVO?=
 =?utf-8?B?eHdiZlJtSzI1SVQvOUI5L05kSDRUS1phR3JMME96WHBqOFJzb3JsbTdiZ0Js?=
 =?utf-8?B?RjVEY0JvcW1UVk12MFFYNFIxUkxESVV5N2ViV1RCYmNOOFIyVTJFME44TkY2?=
 =?utf-8?B?YjNGWXFQZGxoK0piUU5vN0lNVURKb3BTdS92U2dJMjVhcHJ0VjlkUWtvRCtx?=
 =?utf-8?B?aXdoWmYrZm1jdmUxSjYyc0NiWXpwdXNqZ3lwdFROcm1lczVVaklSWGgxdC85?=
 =?utf-8?B?SDJ1TnIzNGJINENIWEY0MENLb0FlUVRwYTd5WVJ4d0hMYWI0STQ1d0NlT3NN?=
 =?utf-8?B?NXpzcGRYcjA5S0dEUDZCU0xocUVJN0VqMzNCUjVuWkkzcTlFZ3lzZytOOTA4?=
 =?utf-8?B?WmRiaGtlN2RQQ2NTMFhJaERJcjhWRC8wMDhxd3lMY3VDMzgzcUw3cEtDdk5Y?=
 =?utf-8?B?NXFYRzNZeUZzNWpFK3R4R3lFeGVab3IxZnhRL2xISGxSdGhadE9BNXFHaTEw?=
 =?utf-8?B?U2sxM1dwQk1abjNvbnhsK2NPZ2N6c3JZeHgzRW9wM2VDR3p4ZzdEbEJmcDM4?=
 =?utf-8?Q?0rMH/yMci14=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)(376014)(366016)(1800799024);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?V3lNUll5MURZRjRLVTF6N0dPaHVqYkxNRTU4eFR2blJCc09IOUsveWtuaXpX?=
 =?utf-8?B?SGZsbC8wbXc1QSthbER4c2xXMjMzODh4WCtEZWZ0MmlmN1ZkYnhmVTN4R0Qz?=
 =?utf-8?B?MUxKTWptOHhsYkhBTCtoSERaeHJ4dnd1eHJ1UHp5TUxtdW1zZzN1b3ljVmNi?=
 =?utf-8?B?ZW9mRVVvdG9jK3hPbnBNWUVVYXUwd0ZRMmtweDdZZy9Yc2NhYUNWNWI1ZEVG?=
 =?utf-8?B?em1IMkExQlNMcGU3ZzBYMXZhTUNWcktvVDc5RStjV1hMZ2VuNjVXNy9YNlY0?=
 =?utf-8?B?K0luaWN6U0JDRnBaaUUrY1VpMnZtKzVtYWVzemRrUjZsU2hhajJjK3h0Q0NM?=
 =?utf-8?B?aGZKY3NkRXplYTQ2M1paUVZZNEtrcWdlRjhFQjRPWDYxeUxuQ2JyNjNya251?=
 =?utf-8?B?bGdGclEwNk1YNW04WUNuME1kRm8xWU9yaVpHQnFqOVdablM1dHVoVlVhQmIv?=
 =?utf-8?B?SVVDR0p3VkFRdXRkMGdRRGFpcnNYZC8rZGJoY3IveDdVMXpUSCtOTDQvM3Nv?=
 =?utf-8?B?NVRlSU5xQXFraUZtaFBoc2Z6a1Q0UmpEb0g0aGxPRWRmUXlaOUxMU0c5V0RI?=
 =?utf-8?B?bWFsZTZCT3Nka29haFZmdkhVTVBmaEd4QXhSQllDaTg3OElaZU5vV0hFT2ZB?=
 =?utf-8?B?UlVxRXhiNElFc3ZhYm5vRHpBTkJUNk15M0V0Rno3WGpxTU1XdVNTVGVORWxU?=
 =?utf-8?B?WWRzSExVeVEwZkdBbTQxMklzUitIV3VIMUNBam5Qc2FxZFlWaitQUElGSDVr?=
 =?utf-8?B?SDI4Rm5XclgxSVRPbVlPL0tXR0FoMC8zaUdlRXM0K2tFdzI2KzFHRU1xVlhn?=
 =?utf-8?B?T2JLK0FuQ0diMzNxYmM5WHkzK2FnbFRhWkJhZlljZXhwdk5iajRoRzJwL0gv?=
 =?utf-8?B?cXRwRWVWRERReW5Jcm4yVHRwMEdBV1dWcFhqK1kwMlA2TVhnSUE1OFFpL2lR?=
 =?utf-8?B?SDZsdTRXK0ZpWlhqL3REc0tKaGRTaWlNYkg5WVFINktZRC84Q205di9WSERu?=
 =?utf-8?B?c0hlK21GOEFIaDlRa2dKV081bk1kNTFzME9MamRNVkJvVGlNaUlvL3h5c2tT?=
 =?utf-8?B?K0p5MjI5WnRoZ2MvOTczOVlxQzF6Vitha0l6dTY5Z3N5VFZKeWRKTHYzeDkv?=
 =?utf-8?B?WkI1b1VhUmRFYXladi9rZ2g4VGtQNW45eW91cEF3b1BOTzE1amVuK25yWFd1?=
 =?utf-8?B?WHlvY2IwaXVDWjNSZUxaaXlTOXU2cm5mYWpnNHVYU205a0hiKytPeU5pZE9Y?=
 =?utf-8?B?Z0ZvZitKRGVLbXp5YWVucjdQZzNMRVZQR3hjVjFVYmxHMkNjQ0VmQi9xUFhD?=
 =?utf-8?B?dUhGSzRjblhoVHdkUGNNV252UEQvaUo5MFdZR00xYmVVcUlCa2NxY1BVTlRi?=
 =?utf-8?B?SWVXMDJrV2RSUkI0SEhZaXgwd1NSVVZWQlVFRS9RNVFtT2lKZmFuUS9XcTk1?=
 =?utf-8?B?TjY0Rm5OU1k3ZUZNbGtJbmNlQkwvU0o2eGtHMDl4RTlHN3VaK0JPd0xDYlhX?=
 =?utf-8?B?c0JjVnlQYTlTOWZzYVZwR3Vtc3c0amVCTllOUnhhcjV2Z1FsNkZsaTRFQmJS?=
 =?utf-8?B?NXJnSVNOcSsxcG9qdjNqS2RMRHJraTBDaVgwVXV4Y1ptOVBoOUJDQU85Qkt6?=
 =?utf-8?B?T2NhNXRlaXZFcVpRLzd2dUppUEpzSnJtc0puLy95T3Z3Qm14MUxEOEtuQ2tB?=
 =?utf-8?B?N0pQVG9SUk5wSzRRR1B4bEJvS0QzZmJESWxqNFZVMFNQWHdtNTE2cjlHV2Ix?=
 =?utf-8?B?aGt3Q0xjNzMzaFZSL290MFQ2a3dZRzZTQ204S2VXclpzTU1seThnSG5JUFVr?=
 =?utf-8?B?WjcwWC9zdVZhdktzejBwd2JTaTUzMGdxcnNmeTdqeGhSYWUwbDBaeHR3TklZ?=
 =?utf-8?B?QmNZeUQ1c0E1NCswZk9FbjJFUnI2UXRVRjlQQ0dtUUtmcW9JNmRlMmhETVNJ?=
 =?utf-8?B?Snd3ZVFMeEQvbU0xbkdzNURFV1BMaEY5cGtRWDlWNnR2ZjZSQUhZQ2orYmpF?=
 =?utf-8?B?YjJqR01hU0RSMVhIK09VNm9pK3RDR0VCSkV0aENOVlN0WjVjU01VU2ttY2NE?=
 =?utf-8?B?OWp0YmUwUGJsK1hjRHRBVGVZS29NY2cxY2xwMVNwT2t2SXpUV01OS2V4eGtl?=
 =?utf-8?Q?zOEhDLa0FiAv1v4XBdgYBypz+?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: eae483c6-b1f5-442e-6667-08dda4f7c137
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jun 2025 12:43:36.5092
 (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: U+Z4hd114qmgX9X4+wepgsM5g7TlsS9rgszoQ6iltsi6DIbOdDXnJaXoCvWhJX2dHc9uarxeHRv8M+yTSu5YaQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR12MB9130

Hi Michal,

On 06/06/2025 11:13, Orzel, Michal wrote:
>
> On 05/06/2025 15:39, Ayan Kumar Halder wrote:
>> Hi Michal,
>>
>> On 05/06/2025 08:06, Orzel, Michal wrote:
>>> On 04/06/2025 19:43, Ayan Kumar Halder wrote:
>>>> Introduce pr_t typedef which is a structure having the prbar and prlar members,
>>>> each being structured as the registers of the AArch32 Armv8-R architecture.
>>>>
>>>> Also, define MPU_REGION_RES0 to 0 as there are no reserved 0 bits beyond the
>>>> BASE or LIMIT bitfields in prbar or prlar respectively.
>>>>
>>>> Move pr_t definition to common code.
>>>> Also, enclose xn_0 within ARM64 as it is not present for ARM32.
>>>>
>>>> Signed-off-by: Ayan Kumar Halder 
>>>> ---
>>>>    xen/arch/arm/include/asm/arm32/mpu.h | 30 +++++++++++++++++++++++-----
>>>>    xen/arch/arm/include/asm/arm64/mpu.h |  6 ------
>>>>    xen/arch/arm/include/asm/mpu.h       |  6 ++++++
>>>>    xen/arch/arm/mpu/mm.c                |  2 ++
>>>>    4 files changed, 33 insertions(+), 11 deletions(-)
>>>>
>>>> diff --git a/xen/arch/arm/include/asm/arm32/mpu.h b/xen/arch/arm/include/asm/arm32/mpu.h
>>>> index f0d4d4055c..ae3b661fde 100644
>>>> --- a/xen/arch/arm/include/asm/arm32/mpu.h
>>>> +++ b/xen/arch/arm/include/asm/arm32/mpu.h
>>>> @@ -5,11 +5,31 @@
>>>>    
>>>>    #ifndef __ASSEMBLY__
>>>>    
>>>> -/* MPU Protection Region */
>>>> -typedef struct {
>>>> -    uint32_t prbar;
>>>> -    uint32_t prlar;
>>>> -} pr_t;
>>>> +#define MPU_REGION_RES0       0x0
>>> The name of the macro does not make a lot of sense in AArch32 context
>>> and can create a confusion for the reader.
>> I know, but I want to avoid introducing ifdef or have separate
>> implementation (for arm32 and arm64) for the following
>>
>> Refer xen/arch/arm/include/asm/mpu.h
>>
>> static inline void pr_set_base(pr_t *pr, paddr_t base)
>> {
>>       pr->prbar.reg.base = ((base & ~MPU_REGION_RES0) >> MPU_REGION_SHIFT);
>> }
>>
>> Let me know your preference.
> I did not mean #ifdef-ing. I was more like suggesting to use a different macro
> name that would be more meaningful than this one.

Now I understand you. However, I can't thing of a better name to make it 
more meaningful.

I have added a comment on top. Is this helpful ?

/* Unlike arm64, there are no reserved 0 bits beyond base in prbar 
register */

>
>>>> +
>>>> +/* Hypervisor Protection Region Base Address Register */
>>>> +typedef union {
>>>> +    struct {
>>>> +        unsigned int xn:1;       /* Execute-Never */
>>>> +        unsigned int ap_0:1;     /* Acess Permission */
>>> If you write AP[1] below, I would expect here AP[0]
>> Again same reason as before, let me know if you want to have additional
>> ifdef in pr_of_addr() or separate functions for arm32 and arm64
> I don't understand. My comment was only about changing comment to say /* Access
> Permission AP[0] */ because below you have a comment with AP[1].

Ah makes sense now.

- Ayan

>
> ~Michal
>


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 12:51:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 12:51:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008511.1387789 (Exim 4.92)
	(envelope-from )
	id 1uNWX9-0005fJ-Tr; Fri, 06 Jun 2025 12:50:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008511.1387789; Fri, 06 Jun 2025 12:50: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 1uNWX9-0005fC-Qx; Fri, 06 Jun 2025 12:50:55 +0000
Received: by outflank-mailman (input) for mailman id 1008511;
 Fri, 06 Jun 2025 12:50: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 1uNWX8-0005f6-DR
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 12:50:54 +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 e07f615b-42d4-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 14:50:52 +0200 (CEST)
Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
 by IA0PR12MB8746.namprd12.prod.outlook.com (2603:10b6:208:490::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Fri, 6 Jun
 2025 12:50:49 +0000
Received: from PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264]) by PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264%2]) with mapi id 15.20.8792.035; Fri, 6 Jun 2025
 12:50: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: e07f615b-42d4-11f0-a301-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=oThYLVF9msLT3G+2ZGnVlvIlbDhd5c2W4f5ua9Z1tDViP/DM344SP0KgAeKy/Y8mj1sv9n/kEFi8HVQAtdYNF95lU9cvXjShi8wIPfp9jvmEn21SwIy9Pr5oqsqVZaoeogFOSsvfaN40uIkldEUVw81M3snCqo9BSPYdBEisE7i4BFV8V67ALOAWd+WJI8E9CI8bmgFOyP3x28iqiQ+ed6J19P2sZvmZFY6FVbpqSki3plGCBVX0t4MRoQf2JpX/RHsU7PcctzkuZKvNVXQmza8RLRTaF1N3SqRIK5cz6Uq++SRnTMoHPlfdEqE3RvwYSqNTra3ZCgiZmAxnMLk4lA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=jrekXxE7JMULCUejOBDPfwepwcIwYR0UA/vNmY58Ghk=;
 b=SmBibunbAchAbPpJQaf+oZU2zZEAcGIgofjWCFCF//r9zzMjqjvAB/Dv5OHqtzQvF3eoQcdqfq4oGmVrmW4s2N1sA1nlP/IxXtBgVEQOxEgGokozdn7SJwYJkcef16OWncyAwwSWktab+LSRUhEF/NlraKsgrSFrVKpUhFDIdmZnyIw6H3bPxTCQ0o33loygKAV6dcSxqB0wf5btjBjH1suYgiNSinfOiOuFod8SM/jQY/B64V92Wqbvgja1cE2JdQqMCYcfHIiw3kOFv9TYltQI/0RnH5hE7GchsAHMzAMt1A9BTOZ7gG0YQVvCf1Ujg19iDUP/vENXPdQlfQcbYA==
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=jrekXxE7JMULCUejOBDPfwepwcIwYR0UA/vNmY58Ghk=;
 b=2OToSkrrmzahOtLkRNKAubnWMgaDhn4OPe+OH46YGaS63+8XnHY7YKgezS9gFmkr0FGPeRTZq3bO9ffiAR++h8I3aU99uzTkZ4NNBB05AaC2pV/QyY/fbBgmIAL0ak1mRbytCgfyE1pgRCdl0VMwNNXl16CoamfSGWJ7zdkR+Y8=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Fri, 6 Jun 2025 13:50:44 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/3] arm/mpu: Introduce MPU memory region map structure
Content-Language: en-GB
From: Ayan Kumar Halder 
To: "Orzel, Michal" ,
 Ayan Kumar Halder , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250604174311.754899-1-ayan.kumar.halder@amd.com>
 <20250604174311.754899-2-ayan.kumar.halder@amd.com>
 
 
 
 <253dc1cc-b6b7-4cdc-a0e1-9fbd6be4efa0@amd.com>
In-Reply-To: <253dc1cc-b6b7-4cdc-a0e1-9fbd6be4efa0@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P123CA0372.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:18e::17) To PH8PR12MB7326.namprd12.prod.outlook.com
 (2603:10b6:510:216::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|IA0PR12MB8746:EE_
X-MS-Office365-Filtering-Correlation-Id: 7c1e347a-2a9a-432e-dc64-08dda4f8c2c7
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?UUNLVlk2RkpFNmhmM2tGQTM4cGgzb2UybTkxMnI4Y1NsM1NGSUYrdjlaRVVQ?=
 =?utf-8?B?dHBpSGlpMmhjT3RmdVBzYm9oVDRaakNQVisxR0pwTFFTeHZxV1pMQXVFSnpk?=
 =?utf-8?B?RFhJMmlLYTdZOXFNMGxkSzlJRy9iUk5CZDgrMWhNSDR2UnRiWm1jcTRUS1dN?=
 =?utf-8?B?OWgzTi8yN3B0ODhrOGlmcHNlL1VWRHRYK05xSE8vQmlkRjJXbEY2ZnAwYWlD?=
 =?utf-8?B?eVlRemxuN1lJR1lpd0xmSmpZVksza04zRlFMdzJtSVNteUg2ZG54djNROTdw?=
 =?utf-8?B?eWJUaWJYbHJVNVgrbzJ3SFFoRzd4NHIvVEQwY0RmQkt0M3RXc3FLbURub1Rx?=
 =?utf-8?B?dzZ5ayt2Y0plYnVXMEpXME1FK25UNThzUGgzY1FpZ042dXJYUHdsZ256aGxu?=
 =?utf-8?B?Z2N3cXF6bGp4TlE0eW9CWHVIblVuditXeUJVMVpMWjFLQ3FweWF2RXZZZDhU?=
 =?utf-8?B?Z1Y0dEdDWGFDaEw3VGVTcGpwVnhKNE4yMnl6MkhGVUZOZnpKbEFKcWxtdWhJ?=
 =?utf-8?B?UzlLK1A5WE1BTzNNY2RIZHUzS3dQeTl5c3Jrcy9jTm40Y0VGRkdMRXFtVzg2?=
 =?utf-8?B?TXV4cGM0RkxsZUs1RXQ2UVhydEgzeVByWmFmV0VsL1dtVVNOc3VrRkt4Q1hY?=
 =?utf-8?B?N3FYMkprTzJLQkp2dENLa2JxVTVnU2pxN09OYlhVeDB3UnZJa2ZqaDdBeDFE?=
 =?utf-8?B?S2lZU21sUUtadXZyMnZ2bGd5aW50dmhBUzdvOHowMkozN0NVYUJNY3NST1dW?=
 =?utf-8?B?ZDBrQWZTK1NXZVdoR3J4K09SSUdWVzZ6SHUxU0ZCTU5LMmlkYjhDTStVcCt2?=
 =?utf-8?B?dTdLVWMxRkVlNm9lTHVnZlFuMXdmUElTalh4LzBabzlZdG9FQ05Xa1BVSC9h?=
 =?utf-8?B?cEpYNStycnNySlBBMDJnSldoUDZBbTRtZ25nTW5YcWtTMjVpTFJjb1JtY1RK?=
 =?utf-8?B?ZDZrRmVsUG9BZU9IZjRRQ0c0QUMyS2tUcHNEa1hDVWtMKzBQcnBxU3B1SVhm?=
 =?utf-8?B?K2dKVWk5UDBla05oajNwQ0RkR3hyRHpmYlBqbE5qRVdqQ1hNTVhnZjY3Risv?=
 =?utf-8?B?MDA1QWo0ZkFrTlJONVRBVC81RTJrY3BGN0tTaHFEZ292UkFjeEVERzZhZGFG?=
 =?utf-8?B?aDY3MTV5NTJTbHg0REFva0dEc2hsR1prRVhSMWgwTFlFWmR3V0o0bDZ1WnZZ?=
 =?utf-8?B?RmpzemxJdHZydUw2VEd4dk9kZ1I3K0p3bFF6MDY3VEhBQXdBYXlmd2doazk4?=
 =?utf-8?B?MlVOL0tEa1I0TUYveUNWTUdMRDhyV0g5U2VJVFZ0ZmovMWxkZ3FSMGNuTGZI?=
 =?utf-8?B?YTcwNkRQeXQ3SWNkSWJqdlN4NHYzVUZaMnhNUVcvY2o4VFlYYjVBZThNeEoz?=
 =?utf-8?B?Wmx1bTNoVkRwR0tTVVNidGt2RzdwNjcycU1land2Wmg1OXRQdW5QWis0WGtL?=
 =?utf-8?B?dS9oOEJabmhwdXltRG9qT3ZURGsxTmp3aGlkb2M0ZDRFUUZUcHVFbmZnOTR2?=
 =?utf-8?B?aTczTlFzVFNlbVlXRXhRSE01b05QYUZsYWllZllaSUV3YjhqZ0l0YVRWWDJK?=
 =?utf-8?B?d25mSkkyaFd1cUFUb3IxQy96YzUzREJ6WlhST0F2Q0pLVHQ4cTZLSVhOdmpW?=
 =?utf-8?B?NnQwaHNYMys1eUlwK2VNTC9NeXJkbXF4eUxmcW5uNUdaMWN6c2Q5Z3AvRjMr?=
 =?utf-8?B?WjVIbTF6dG5JNFEvMVFNeU0vRHdaZVBwUkRwMTlqVFY0Vk9SQzRHbVFybGlD?=
 =?utf-8?B?N3pqQU9MZnUzOG82RngzbHFrNEhxZ2pUNm03YWRVdmtwbkNCbWJyZGZ2Nm5r?=
 =?utf-8?B?MFo4OVpBUWdTc3Q4WjBzMEM1SlBYUUNmQ2V0MWtxUit3QjZxeS80aDNQTXRx?=
 =?utf-8?B?d3BjaTNPQ2o2VDFsZkwveHlxT25YYjNnTUZJK25xZytqWU5TL0pxNC9nanpy?=
 =?utf-8?Q?+dSxmVS7H5s=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)(1800799024)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?anFRMlFwdTErUWYxQU9uY2ZWV09HVUFyaFpIU0xDMnE5Y1AzSjNqdU5ZWUdX?=
 =?utf-8?B?ODFiVVBWZTh3UE80cVEwQVBuVkJ6WXF6UG50NUhoWUdtQUFmWVA3YkwxODBx?=
 =?utf-8?B?TXBWOVNzTGgyMU5FZ1lqWDhNVEFwY2xNUzlIRzRieE9lNCtiL09TVFRLUWU1?=
 =?utf-8?B?aVpudjlmT3NXRnVySEMxemF2TkVwNFBFcFZhWjRvanFMeG1jZW5ld2V1MXU1?=
 =?utf-8?B?TTU3UldoTmVyUnVzb1NVWVpEaFM1OWp2YU85bDAyN3phNWlKbXQ1TG80bldU?=
 =?utf-8?B?Sy95a2ltbGpZNWZ0M2Y0cU5PT3RKNmI0aVV4M1QxSEQxK2lZNktQMEx6a0FM?=
 =?utf-8?B?M1YzT25aMnRVWjV6aVdlcVRGbkJBMEFSdW9tUnl5eHlnOXdlYXhNQ203dWFJ?=
 =?utf-8?B?STZaVmpGN1Erc2RzQzNjN3cvQmRGTHhOcG5lQVlpMGpyMmMwSVhneXhiN1E2?=
 =?utf-8?B?dmE0cnkwekhqWWNKTlNiMFBObG9Wbk1Cc09PenJxUE9jelFSMzM0Q2NxMUJt?=
 =?utf-8?B?WGdYd3JZU29wcDZsMTY2eHN4TFBlM1Zvd3Z4cGFJcmVINkRIOWY2MUpPaVpk?=
 =?utf-8?B?UkZmaVFwSWtER3pTZldNZlRoY1V0bVd3TFJtNm8rMmJvcVVFOWtSaVFWanJN?=
 =?utf-8?B?Vy9nUjQvT2dlTWh1T3FLakJ5WklOZ3VyTHNpZGJxTEFGRnZGamlqSkJqTnhZ?=
 =?utf-8?B?ZzE2THkxbjg0NTA3MlNtOUVweEJwZW41OUhvZzZvejErOFFNMGw0aGlDMFF0?=
 =?utf-8?B?SjFyekJGQUY5ZCt1aU5OS3l1blBVK2FFRnArczkrdkRubisvZVdhR3NnSEJW?=
 =?utf-8?B?dTRmeDBXeGNKcSt0U1JmditXWEdDMERuQ3kraE1SNEs2SGw0YTU1OFFtVnp1?=
 =?utf-8?B?NEVDQ1FpMHRHT0N6dEllU1lncEk2VXhpRUlCakJjak9CMElUcG83eHQwK1BD?=
 =?utf-8?B?TFI2T3htNEFvMG83RmFpcStRM3N4S05UV0szOCtiT09KU2JEcDRKMy9iRzl4?=
 =?utf-8?B?MTQ3dElKUFg0Q0JnU3Axc2NSL1hRZ3ZrL2FWeUlLb29IQmpyb0p0Rm4xaHZm?=
 =?utf-8?B?elo3cndDWWtaVW81RDNDYStvK01NVFBzRFVob1k5dHhTREoxNFBCejBFZWlY?=
 =?utf-8?B?WGc0T0FMUVpLQ1NLcXgxVURTclZYUTVMOStkRDFwWSs0TkxPeW1BbHpuNHEv?=
 =?utf-8?B?RUxPeENLRFNKWVlNQVFoS2RSdmpvTEhlZklHUzRITXpiUFdHQ0czNlVmdFpz?=
 =?utf-8?B?Y08vZlJTSUMzdTFvWEs3V1k4eThHTVQ5dVVocTdLRHpBRTVSYmNYZXljczVW?=
 =?utf-8?B?MEl3aXFXT1FmWmxIcUNBbFhRUy8xVUQ1M2FiVWgzZ0dkK1VqRjJtSXFkcW9I?=
 =?utf-8?B?MmMvMjNqWEIza1UxU0tuMXVmMzdWRHVLRXBRY1ZibWMrV2xYQ0k0TUJGQXly?=
 =?utf-8?B?M2s3ZkRqZkVDaUZoMWJMQzdrYTJQUU8vQ3ppc1U2Qk8vRkFCTzRBaW5yaEdk?=
 =?utf-8?B?cGtLTEs1V0tFRUVYYm51YXYzWHprUHJTUGFkMFY4Q1hWdHIvQWVmQk14MkR6?=
 =?utf-8?B?SFJIb3VVSS9hSm5PbUltSHhCN3pVN25mVTdXWkNOQTVsMHRSUEIrdEppUXRH?=
 =?utf-8?B?dlhJMmc0ZEdYNkdZbWxLQ3VlTWFwc29USTBnaXpQZXQyUEMwd0dWTDhKUUJl?=
 =?utf-8?B?UzRXSVE0bFRZM2lVbUZHVitBRkI5MDhvYnBLNmorZW9tZmlhakNlMHRyU1VJ?=
 =?utf-8?B?Ym9tQ2pQZ1ppZ0tHZTU5cFgrSi8vb1B1QW04OWpLbUpiK080R2pqalZmcERq?=
 =?utf-8?B?cGNMbEZGZkRka2wwdFM4c25RVnFDOFRRejBOVDZoMVpHSkloSDh4TU5JUWoy?=
 =?utf-8?B?M3dLMzZEUDY3UElqL0hkS241aHJvS2N2TVA1dVNFbEhTbER0RExuTHVSR3Fp?=
 =?utf-8?B?VXdkcEVpMDNGanJrcnZWVHA1VmRraG0zTjVYYlNLSzIwSmFoZGZ3QkJmNVVp?=
 =?utf-8?B?MG9rcXhzSVhEQ1pPa2lGQm1ralJsS3ZERjY1MGNISURpeUFoTE1iZnJnRFBx?=
 =?utf-8?B?RUJqd3NxL25mTlhxV0pDZTRacEZlSWlsbWJxa3FPaHZaVnRJTmZpYTkxSWdk?=
 =?utf-8?Q?5KgwG0Tyj/Qb4lF3v3ACZT4+4?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7c1e347a-2a9a-432e-dc64-08dda4f8c2c7
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jun 2025 12:50:48.5893
 (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: bHBbl/rRSIOjN+D5NeczxaAGxeKY9dx5szWnu22FBkA3KV7dhPfmIyy8sVkJqSv6HmWIFxfGy2ta7rSA//Zu+w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB8746


On 06/06/2025 13:43, Ayan Kumar Halder wrote:
> Hi Michal,
>
> On 06/06/2025 11:13, Orzel, Michal wrote:
>>
>> On 05/06/2025 15:39, Ayan Kumar Halder wrote:
>>> Hi Michal,
>>>
>>> On 05/06/2025 08:06, Orzel, Michal wrote:
>>>> On 04/06/2025 19:43, Ayan Kumar Halder wrote:
>>>>> Introduce pr_t typedef which is a structure having the prbar and 
>>>>> prlar members,
>>>>> each being structured as the registers of the AArch32 Armv8-R 
>>>>> architecture.
>>>>>
>>>>> Also, define MPU_REGION_RES0 to 0 as there are no reserved 0 bits 
>>>>> beyond the
>>>>> BASE or LIMIT bitfields in prbar or prlar respectively.
>>>>>
>>>>> Move pr_t definition to common code.
>>>>> Also, enclose xn_0 within ARM64 as it is not present for ARM32.
>>>>>
>>>>> Signed-off-by: Ayan Kumar Halder 
>>>>> ---
>>>>>    xen/arch/arm/include/asm/arm32/mpu.h | 30 
>>>>> +++++++++++++++++++++++-----
>>>>>    xen/arch/arm/include/asm/arm64/mpu.h |  6 ------
>>>>>    xen/arch/arm/include/asm/mpu.h       |  6 ++++++
>>>>>    xen/arch/arm/mpu/mm.c                |  2 ++
>>>>>    4 files changed, 33 insertions(+), 11 deletions(-)
>>>>>
>>>>> diff --git a/xen/arch/arm/include/asm/arm32/mpu.h 
>>>>> b/xen/arch/arm/include/asm/arm32/mpu.h
>>>>> index f0d4d4055c..ae3b661fde 100644
>>>>> --- a/xen/arch/arm/include/asm/arm32/mpu.h
>>>>> +++ b/xen/arch/arm/include/asm/arm32/mpu.h
>>>>> @@ -5,11 +5,31 @@
>>>>>       #ifndef __ASSEMBLY__
>>>>>    -/* MPU Protection Region */
>>>>> -typedef struct {
>>>>> -    uint32_t prbar;
>>>>> -    uint32_t prlar;
>>>>> -} pr_t;
>>>>> +#define MPU_REGION_RES0       0x0
>>>> The name of the macro does not make a lot of sense in AArch32 context
>>>> and can create a confusion for the reader.
>>> I know, but I want to avoid introducing ifdef or have separate
>>> implementation (for arm32 and arm64) for the following
>>>
>>> Refer xen/arch/arm/include/asm/mpu.h
>>>
>>> static inline void pr_set_base(pr_t *pr, paddr_t base)
>>> {
>>>       pr->prbar.reg.base = ((base & ~MPU_REGION_RES0) >> 
>>> MPU_REGION_SHIFT);
>>> }
>>>
>>> Let me know your preference.
>> I did not mean #ifdef-ing. I was more like suggesting to use a 
>> different macro
>> name that would be more meaningful than this one.
>
> Now I understand you. However, I can't thing of a better name to make 
> it more meaningful.
>
> I have added a comment on top. Is this helpful ?
>
> /* Unlike arm64, there are no reserved 0 bits beyond base in prbar 
> register */
/*
  * Unlike arm64, there are no reserved 0 bits beyond base and limit 
bitfield in
  * prbar and prlar registers respectively.
  */


- Ayan



From xen-devel-bounces@lists.xenproject.org Fri Jun 06 13:00:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 13:00:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008526.1387799 (Exim 4.92)
	(envelope-from )
	id 1uNWgK-0007H4-Oj; Fri, 06 Jun 2025 13:00:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008526.1387799; Fri, 06 Jun 2025 13: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 1uNWgK-0007Gx-Lz; Fri, 06 Jun 2025 13:00:24 +0000
Received: by outflank-mailman (input) for mailman id 1008526;
 Fri, 06 Jun 2025 13: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 1uNWgJ-0007Gr-2o
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 13:00:23 +0000
Received: from mail36.us4.mandrillapp.com (mail36.us4.mandrillapp.com
 [205.201.136.36]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 33a53015-42d6-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 15:00:21 +0200 (CEST)
Received: from pmta15.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail36.us4.mandrillapp.com (Mailchimp) with ESMTP id 4bDLyW5NjYzS646YZ
 for ; Fri,  6 Jun 2025 13:00:19 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 4cd0901772964c1a977820f463d04020; Fri, 06 Jun 2025 13:00: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: 33a53015-42d6-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1749214819; x=1749484819;
	bh=kR4+96UQbS+FzQOrA4QYtX61B6OuEKqx78JOtEMdgtU=;
	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=nVT5hmA2okz4FVkg6QKPaD71BuSljLpeoBbonqEkDDnsCYV8F3pipO3dStEAxP0Lw
	 BaEYXQS5kgbMtowi0U4dU7GSP3wJMu4tVqyL7LoZzRCkA+7T495EYbLApX7yEN6XS9
	 p2MzSE6jAep/fLgnaAe/FEfhrzbDrmBnZKKwKTq+HJ8h9EkJAi+MrJ3+Rf3AdKSuED
	 PvG0MAQO6bm9nfXnUtxVWgzgOJypp2CtkIG14oOZKiKAX1ktQ0m8NMtmUhcBpb5PY6
	 8++my48HiCZvySIpHtx8gfFmKHaRsOMOfR22CCp/kRBB0ar9r8Ke+4DvO+r6l5jUaI
	 TyinguAKwz/kg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1749214819; x=1749475319; i=ngoc-tu.dinh@vates.tech;
	bh=kR4+96UQbS+FzQOrA4QYtX61B6OuEKqx78JOtEMdgtU=;
	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=fuqZadNO1w/svYOdkdYrdZtebox83A5alT5kDB60RxQ6efeCOs8tkkoOJY7qIzNRw
	 xTuNTfOSm8WZaUrcHHVw9nf3VgjMyosfo8o0U7gZ+hQBcmdAq3C6e8VR8U9ieoc7hW
	 xYZM5FTdOYk7Tk12nJlSi1XogLaw2Y0UZLEpGyVLIW7SOPWpzeIfAcBQ9LgY7rZT27
	 5XdYOqVYzXxyQtSv5amnFeHSPai150TZMTwfPmvVM7RlUFGw12UzQ1Pmk4+io1ImU4
	 gSwbp2CFpdT/dGsQ4bVX5iEkGhAyd+RDd5GrXS54PZAnGSZDtEUDmMw15O8xcR4Y5X
	 p7duh3FvOT0FA==
From: "Tu Dinh" 
Subject: =?utf-8?Q?Re:=20[PATCH=20v3]=20x86/hvmloader:=20select=20xenpci=20MMIO=20BAR=20UC=20or=20WB=20MTRR=20cache=20attribute?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1749214817188
Message-Id: <1b290503-078e-491a-8552-b884df7ac747@vates.tech>
To: "Roger Pau Monne" , xen-devel@lists.xenproject.org
Cc: "Anthony PERARD" , "Andrew Cooper" , "Michal Orzel" , "Jan Beulich" , "Julien Grall" , "Stefano Stabellini" , "Juergen Gross" , "Anthoine Bourgeois" 
References: <20250605161659.18201-1-roger.pau@citrix.com>
In-Reply-To: <20250605161659.18201-1-roger.pau@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.4cd0901772964c1a977820f463d04020?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250606:md
Date: Fri, 06 Jun 2025 13:00:19 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Roger,

On 05/06/2025 18:20, Roger Pau Monne wrote:
> The Xen PCI device (vendor ID 0x5853) exposed to x86 HVM guests doesn't
> have the functionality of a traditional PCI device.  The exposed MMIO BAR
> is used by some guests (including Linux) as a safe place to map foreign
> memory, including the grant table itself.
> 
> Traditionally BARs from devices have the uncacheable (UC) cache attribute
> from the MTRR, to ensure correct functionality of such devices.  hvmloade=
r
> mimics this behavior and sets the MTRR attributes of both the low and hig=
h
> PCI MMIO windows (where BARs of PCI devices reside) as UC in MTRR.
> 
> This however causes performance issues for users of the Xen PCI device BA=
R,
> as for the purposes of mapping remote memory there's no need to use the U=
C
> attribute.  On Intel systems this is worked around by using iPAT, that
> allows the hypervisor to force the effective cache attribute of a p2m ent=
ry
> regardless of the guest PAT value.  AMD however doesn't have an equivalen=
t
> of iPAT, and guest PAT values are always considered.
> 
> Linux commit:
> 
> 41925b105e34 xen: replace xen_remap() with memremap()
> 
> Attempted to mitigate this by forcing mappings of the grant-table to use
> the write-back (WB) cache attribute.  However Linux memremap() takes MTRR=
s
> into account to calculate which PAT type to use, and seeing the MTRR cach=
e
> attribute for the region being UC the PAT also ends up as UC, regardless =
of
> the caller having requested WB.
> 
> As a workaround to allow current Linux to map the grant-table as WB using
> memremap() introduce an xl.cfg option (xenpci_bar_uc=3D0) that can be use=
d to
> select whether the Xen PCI device BAR will have the UC attribute in MTRR.
> Such workaround in hvmloader should also be paired with a fix for Linux s=
o
> it attempts to change the MTRR of the Xen PCI device BAR to WB by itself.
> 
> Overall, the long term solution would be to provide the guest with a safe
> range in the guest physical address space where mappings to foreign pages
> can be created.
> 
> Some vif throughput performance figures provided by Anthoine from a 8
> vCPUs, 4GB of RAM HVM guest(s) running on AMD hardware:
> 
> Without this patch:
> vm -> dom0: 1.1Gb/s
> vm -> vm:   5.0Gb/s
> 
> With the patch:
> vm -> dom0: 4.5Gb/s
> vm -> vm:   7.0Gb/s
> 
> Reported-by: Anthoine Bourgeois 
> Signed-off-by: Roger Pau Monn=C3=A9 
> ---
> Changes since v2:
>   - Add default value in xl.cfg.
>   - List xenstore path in the pandoc file.
>   - Adjust comment in hvmloader.
>   - Fix commit message MIO -> MMIO.
> 
> Changes since v1:
>   - Leave the xenpci BAR as UC by default.
>   - Introduce an option to not set it as UC.
> ---
>   docs/man/xl.cfg.5.pod.in                |  8 ++++
>   docs/misc/xenstore-paths.pandoc         |  5 +++
>   tools/firmware/hvmloader/config.h       |  2 +-
>   tools/firmware/hvmloader/pci.c          | 49 ++++++++++++++++++++++++-
>   tools/firmware/hvmloader/util.c         |  2 +-
>   tools/include/libxl.h                   |  9 +++++
>   tools/libs/light/libxl_create.c         |  1 +
>   tools/libs/light/libxl_dom.c            |  9 +++++
>   tools/libs/light/libxl_types.idl        |  1 +
>   tools/xl/xl_parse.c                     |  2 +
>   xen/include/public/hvm/hvm_xs_strings.h |  2 +
>   11 files changed, 86 insertions(+), 4 deletions(-)
> 
> diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> index c388899306c2..ddbff6fffc16 100644
> --- a/docs/man/xl.cfg.5.pod.in
> +++ b/docs/man/xl.cfg.5.pod.in
> @@ -2351,6 +2351,14 @@ Windows L.
>   Setting B with the default device_model "qemu-xen=
"
>   requires at least QEMU 1.6.
>   
> +
> +=3Ditem B
> +
> +B Select whether the memory BAR of the Xen PCI device should =
have
> +uncacheable (UC) cache attribute set in MTRR.
> +
> +Default is B.
> +
>   =3Ditem B or B
>   
>   The groups of Microsoft Hyper-V (AKA viridian) compatible enlightenment=
s
> diff --git a/docs/misc/xenstore-paths.pandoc b/docs/misc/xenstore-paths.p=
andoc
> index 01a340fafcbe..073bed91eec1 100644
> --- a/docs/misc/xenstore-paths.pandoc
> +++ b/docs/misc/xenstore-paths.pandoc
> @@ -234,6 +234,11 @@ These xenstore values are used to override some of t=
he default string
>   values in the SMBIOS table constructed in hvmloader. See the SMBIOS
>   table specification at http://www.dmtf.org/standards/smbios/
>   
> +#### ~/hvmloader/pci/xenpci-bar-uc =3D ("1"|"0") [HVM,INTERNAL]
> +
> +Select whether the Xen PCI device MMIO BAR will have the uncacheable cac=
he
> +attribute set in the MTRRs by hvmloader.
> +
>   #### ~/bios-strings/oem-* =3D STRING [HVM,INTERNAL]
>   
>   1 to 99 OEM strings can be set in xenstore using values of the form
> diff --git a/tools/firmware/hvmloader/config.h b/tools/firmware/hvmloader=
/config.h
> index 6e1da137d779..c159db30eea9 100644
> --- a/tools/firmware/hvmloader/config.h
> +++ b/tools/firmware/hvmloader/config.h
> @@ -58,7 +58,7 @@ extern uint32_t *cpu_to_apicid;
>   #define ACPI_TIS_HDR_ADDRESS 0xFED40F00UL
>   
>   extern uint32_t pci_mem_start;
> -extern const uint32_t pci_mem_end;
> +extern uint32_t pci_mem_end;
>   extern uint64_t pci_hi_mem_start, pci_hi_mem_end;
>   
>   extern bool acpi_enabled;
> diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pc=
i.c
> index cc67b18c0361..747f6cfb6794 100644
> --- a/tools/firmware/hvmloader/pci.c
> +++ b/tools/firmware/hvmloader/pci.c
> @@ -30,7 +30,7 @@
>   #include 
>   
>   uint32_t pci_mem_start =3D HVM_BELOW_4G_MMIO_START;
> -const uint32_t pci_mem_end =3D RESERVED_MEMBASE;
> +uint32_t pci_mem_end =3D RESERVED_MEMBASE;
>   uint64_t pci_hi_mem_start =3D 0, pci_hi_mem_end =3D 0;
>   
>   /*
> @@ -116,6 +116,8 @@ void pci_setup(void)
>        * experience the memory relocation bug described below.
>        */
>       bool allow_memory_relocate =3D 1;
> +    /* Select the MTRR cache attribute of the xenpci device BAR. */
> +    bool xenpci_bar_uc =3D false;

Since this is meant to be a workaround, I wonder if it makes more sense 
to flip the setting (`xenpci_bar_wb`) and make it 0 by default? It also 
simplifies the logic for both hvmloader and the consumer (no need for 
double negatives).

>   
>       BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_IO !=3D
>                    PCI_COMMAND_IO);
> @@ -130,6 +132,12 @@ void pci_setup(void)
>       printf("Relocating guest memory for lowmem MMIO space %s\n",
>              allow_memory_relocate?"enabled":"disabled");
>   
> +    s =3D xenstore_read(HVM_XS_XENPCI_BAR_UC, NULL);
> +    if ( s )
> +        xenpci_bar_uc =3D strtoll(s, NULL, 0);
> +    printf("XenPCI device BAR MTRR cache attribute set to %s\n",
> +           xenpci_bar_uc ? "UC" : "WB");
> +
>       s =3D xenstore_read("platform/mmio_hole_size", NULL);
>       if ( s )
>           mmio_hole_size =3D strtoll(s, NULL, 0);
> @@ -271,6 +279,43 @@ void pci_setup(void)
>               if ( bar_sz =3D=3D 0 )
>                   continue;
>   
> +            if ( !xenpci_bar_uc &&
> +                 ((bar_data & PCI_BASE_ADDRESS_SPACE) =3D=3D
> +                   PCI_BASE_ADDRESS_SPACE_MEMORY) &&
> +                 vendor_id =3D=3D 0x5853 &&
> +                 (device_id =3D=3D 0x0001 || device_id =3D=3D 0x0002) )
> +            {
> +                if ( is_64bar )
> +                {
> +                     printf("xenpci dev %02x:%x unexpected MMIO 64bit BA=
R%u\n",
> +                            devfn >> 3, devfn & 7, bar);
> +                     continue;
> +                }
> +
> +                if ( bar_sz > pci_mem_end ||
> +                     ((pci_mem_end - bar_sz) & ~(bar_sz - 1)) < pci_mem_=
start )
> +                {
> +                     printf("xenpci dev %02x:%x BAR%u size %llx overflow=
s low PCI hole\n",
> +                            devfn >> 3, devfn & 7, bar, bar_sz);
> +                     continue;
> +                }
> +
> +                /* Put unconditionally at the end of the low PCI MMIO ho=
le. */
> +                pci_mem_end -=3D bar_sz;
> +                pci_mem_end &=3D ~(bar_sz - 1);
> +                bar_data &=3D ~PCI_BASE_ADDRESS_MEM_MASK;
> +                bar_data |=3D pci_mem_end;
> +                pci_writel(devfn, bar_reg, bar_data);
> +                pci_devfn_decode_type[devfn] |=3D PCI_COMMAND_MEMORY;
> +
> +                /* Prefix BAR address with a 0 to match format used belo=
w. */
> +                printf("pci dev %02x:%x bar %02x size "PRIllx": 0%08x\n"=
,
> +                       devfn >> 3, devfn & 7, bar_reg,
> +                       PRIllx_arg(bar_sz), bar_data);
> +
> +                continue;
> +            }
> +
>               for ( i =3D 0; i < nr_bars; i++ )
>                   if ( bars[i].bar_sz < bar_sz )
>                       break;
> @@ -310,7 +355,7 @@ void pci_setup(void)
>           }
>   
>           /* Enable bus master for this function later */
> -        pci_devfn_decode_type[devfn] =3D PCI_COMMAND_MASTER;
> +        pci_devfn_decode_type[devfn] |=3D PCI_COMMAND_MASTER;
>       }
>   
>       if ( mmio_hole_size )
> diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/u=
til.c
> index 79c0e6bd4ad2..31b4411db7b4 100644
> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -867,7 +867,7 @@ void hvmloader_acpi_build_tables(struct acpi_config *=
config,
>           config->table_flags |=3D ACPI_HAS_HPET;
>   
>       config->pci_start =3D pci_mem_start;
> -    config->pci_len =3D pci_mem_end - pci_mem_start;
> +    config->pci_len =3D RESERVED_MEMBASE - pci_mem_start;
>       if ( pci_hi_mem_end > pci_hi_mem_start )
>       {
>           config->pci_hi_start =3D pci_hi_mem_start;
> diff --git a/tools/include/libxl.h b/tools/include/libxl.h
> index b7ad7735ca4c..7ce7678e6836 100644
> --- a/tools/include/libxl.h
> +++ b/tools/include/libxl.h
> @@ -1503,6 +1503,15 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst=
, const libxl_mac *src);
>    */
>   #define LIBXL_HAVE_CREATEINFO_XEND_SUSPEND_EVTCHN_COMPAT
>   
> +/*
> + * LIBXL_HAVE_XENPCI_BAR_UC
> + *
> + * libxl_domain_build_info contains a boolean 'u.hvm.xenpci_bar_uc' fiel=
d to
> + * signal whether the XenPCI device BAR should have UC cache attribute s=
et in
> + * MTRR.
> + */
> +#define LIBXL_HAVE_XENPCI_BAR_UC
> +
>   typedef char **libxl_string_list;
>   void libxl_string_list_dispose(libxl_string_list *sl);
>   int libxl_string_list_length(const libxl_string_list *sl);
> diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_cre=
ate.c
> index 8bc768b5156c..962fa820faec 100644
> --- a/tools/libs/light/libxl_create.c
> +++ b/tools/libs/light/libxl_create.c
> @@ -313,6 +313,7 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc=
,
>           libxl_defbool_setdefault(&b_info->u.hvm.usb,                fal=
se);
>           libxl_defbool_setdefault(&b_info->u.hvm.vkb_device,         tru=
e);
>           libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci,   tru=
e);
> +        libxl_defbool_setdefault(&b_info->u.hvm.xenpci_bar_uc,      true=
);
>           libxl_defbool_setdefault(&b_info->u.hvm.pirq,               fal=
se);
>   
>           libxl_defbool_setdefault(&b_info->u.hvm.spice.enable, false);
> diff --git a/tools/libs/light/libxl_dom.c b/tools/libs/light/libxl_dom.c
> index 4d67b0d28294..60ec0354d19a 100644
> --- a/tools/libs/light/libxl_dom.c
> +++ b/tools/libs/light/libxl_dom.c
> @@ -819,6 +819,15 @@ static int hvm_build_set_xs_values(libxl__gc *gc,
>               goto err;
>       }
>   
> +    if (info->type =3D=3D LIBXL_DOMAIN_TYPE_HVM &&
> +        libxl_defbool_val(info->u.hvm.xenpci_bar_uc)) {
> +        path =3D GCSPRINTF("/local/domain/%d/"HVM_XS_XENPCI_BAR_UC, domi=
d);
> +        ret =3D libxl__xs_printf(gc, XBT_NULL, path, "%d",
> +                               libxl_defbool_val(info->u.hvm.xenpci_bar_=
uc));
> +        if (ret)
> +            goto err;
> +    }
> +
>       return 0;
>   
>   err:
> diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_ty=
pes.idl
> index 198515383012..6054350b83c7 100644
> --- a/tools/libs/light/libxl_types.idl
> +++ b/tools/libs/light/libxl_types.idl
> @@ -691,6 +691,7 @@ libxl_domain_build_info =3D Struct("domain_build_info=
",[
>                                          ("vkb_device",       libxl_defbo=
ol),
>                                          ("soundhw",          string),
>                                          ("xen_platform_pci", libxl_defbo=
ol),
> +                                       ("xenpci_bar_uc",    libxl_defboo=
l),
>                                          ("usbdevice_list",   libxl_strin=
g_list),
>                                          ("vendor_device",    libxl_vendo=
r_device),
>                                          # See libxl_ms_vm_genid_generate=
()
> diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
> index 219e924779ff..4da3bb9e91ab 100644
> --- a/tools/xl/xl_parse.c
> +++ b/tools/xl/xl_parse.c
> @@ -2917,6 +2917,8 @@ skip_usbdev:
>           xlu_cfg_replace_string (config, "soundhw", &b_info->u.hvm.sound=
hw, 0);
>           xlu_cfg_get_defbool(config, "xen_platform_pci",
>                               &b_info->u.hvm.xen_platform_pci, 0);
> +        xlu_cfg_get_defbool(config, "xenpci_bar_uc",
> +                            &b_info->u.hvm.xenpci_bar_uc, 0);
>   
>           if(b_info->u.hvm.vnc.listen
>              && b_info->u.hvm.vnc.display
> diff --git a/xen/include/public/hvm/hvm_xs_strings.h b/xen/include/public=
/hvm/hvm_xs_strings.h
> index e1ed078628a0..ebb07b9fba56 100644
> --- a/xen/include/public/hvm/hvm_xs_strings.h
> +++ b/xen/include/public/hvm/hvm_xs_strings.h
> @@ -14,6 +14,8 @@
>   #define HVM_XS_BIOS                    "hvmloader/bios"
>   #define HVM_XS_GENERATION_ID_ADDRESS   "hvmloader/generation-id-address=
"
>   #define HVM_XS_ALLOW_MEMORY_RELOCATE   "hvmloader/allow-memory-relocate=
"
> +/* Set xenpci device BAR as UC in MTRR */
> +#define HVM_XS_XENPCI_BAR_UC           "hvmloader/pci/xenpci-bar-uc"
>   
>   /* The following values allow additional ACPI tables to be added to the
>    * virtual ACPI BIOS that hvmloader constructs. The values specify the =
guest



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 Jun 06 13:01:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 13:01:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008536.1387808 (Exim 4.92)
	(envelope-from )
	id 1uNWhj-0007wb-6v; Fri, 06 Jun 2025 13:01:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008536.1387808; Fri, 06 Jun 2025 13: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 1uNWhj-0007wU-4M; Fri, 06 Jun 2025 13:01:51 +0000
Received: by outflank-mailman (input) for mailman id 1008536;
 Fri, 06 Jun 2025 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 1uNWhi-0007wL-L8
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 13:01:50 +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 68ac2bc3-42d6-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 15:01:49 +0200 (CEST)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-451d3f72391so27116375e9.3
 for ; Fri, 06 Jun 2025 06:01:49 -0700 (PDT)
Received: from [192.168.86.29] ([90.250.112.104])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a53244e0e3sm1854027f8f.68.2025.06.06.06.01.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 06 Jun 2025 06:01:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 68ac2bc3-42d6-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749214909; x=1749819709; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=iXkBU6+oOy/U/qvVLCoKemScuo3O3lcWcaPZjmBt/Gs=;
        b=unnkFhKP0z73k6c8sQFzb0BqtyBFb0WHUgMjbvFWxbNLJnaEUWWNcsEQ1C4rg9dMz3
         mnEFD7epHEyuYXAuQAEVw/VXVgYR19UpXHEXrFMbm+y4S4zKs1n7xTtoP8njr3caA9a5
         efYIZj9DvoO7oa4o3i0bR9Yy1w55tJsrDBZuo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749214909; x=1749819709;
        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=iXkBU6+oOy/U/qvVLCoKemScuo3O3lcWcaPZjmBt/Gs=;
        b=f9hdMZZLogQ6BMZ8V31R6CMIAPGPgiKUsYVptbXJCiAcBy1Q9Z5O3R2GOldEo1+Tj4
         rPyC7ryMQhGXi1VNUez6wJxUwrAClescNcEuXclywD/y0Tydt0dbySuS97zRqns6S1IE
         NyTBsP6F5BUwzWwOE4sDmSWyA8PX5vR754mEX5GJaFKfPJsu0tixE8ilJT2UDs3Gj6Gy
         /etIy1JN05B2TZJJvMHrMGGdkCAeTDf+4Kp+nQgIRz1AVtsne0swrSUQb0mJcubpmPSw
         6WbeGQGhUf286G2tBYVjLMLMk4taJozVUv34vMUA02psqYRgrkqYYdV+OzDrlqdv/MHj
         0yKA==
X-Forwarded-Encrypted: i=1; AJvYcCXjSCaeD+WgMvWVo0kQbatP/Zenz4gOKUuiqN+lOWq3ulT4yqe8sXRZwaQuoBFUXaZ2mgifLmNA+fY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy/7yjd9r8TBcSyTv+WK3fNpC4Gnmd/GhNJb5T1xs+73fx+UG8E
	V+Ft+LPIFWRKGsByighfFotXJ26TVEkD2rfifWuBcJlID5mZ0M7iXDegakVzq6rT8Ws=
X-Gm-Gg: ASbGnct2XajDLZMpCmaWiDoFlcNlXocLYG2KAXJmUKjlhEBIxlmO7NvS9tSskaOFjkP
	U3fo+OTdEyY53u9qEyVHR3pRDI0i7MYSHTr0eC6oZTejagfrsw8EUAMf2e55HW0LD0cgPyCzZo6
	V2c6riQqjWSeaDfz1M6YPcufAalLEQuT7UUjbkJKDePQC+DURJIIa7nB+CS0g/jHmVNTjjiVn/A
	2sh7snnxjDbwsJdVlULq2SnXXKUU8HhVEBxG0I62phMGDB3fV8hPDW/pKMpvrudlyzy0sl1t9QO
	eCxo9onshihu6OOfZdsHXrfkTw/ONzDJG90jt2/FSoCRr/sCmXjgMxlzeaVBqiGe
X-Google-Smtp-Source: AGHT+IFptYsBBmSNadLGBzowwbqtxhjTcnz7MrLKvM4FxNNKpD0SRr446xN2DLxjPkuppyJWOgayXg==
X-Received: by 2002:a05:6000:1ac6:b0:3a5:2f23:377d with SMTP id ffacd0b85a97d-3a531cb1037mr2759637f8f.50.1749214908847;
        Fri, 06 Jun 2025 06:01:48 -0700 (PDT)
Message-ID: <307835ed-178d-4561-9529-5be4433d503c@citrix.com>
Date: Fri, 6 Jun 2025 14:01:41 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86: remove memcmp calls non-compliant with Rule 21.16.
To: Stefano Stabellini ,
 xen-devel@lists.xenproject.org
Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 ,
 Alessandro Zucchelli 
References: <20250604233537.2892206-1-stefano.stabellini@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: <20250604233537.2892206-1-stefano.stabellini@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 05/06/2025 12:35 am, Stefano Stabellini wrote:
> From: Alessandro Zucchelli 
>
> MISRA C Rule 21.16 states the following: "The pointer arguments to
> the Standard Library function `memcmp' shall point to either a pointer
> type, an essentially signed type, an essentially unsigned type, an
> essentially Boolean type or an essentially enum type".
>
> Comparing string literals with char arrays is more appropriately
> done via strncmp.
>
> No functional change.
>
> Signed-off-by: Alessandro Zucchelli 
> ---
>  xen/arch/x86/dmi_scan.c | 20 ++++++++++----------
>  xen/arch/x86/mpparse.c  | 10 +++++-----
>  2 files changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/xen/arch/x86/dmi_scan.c b/xen/arch/x86/dmi_scan.c
> index eb65bc86bb..b6edd7a965 100644
> --- a/xen/arch/x86/dmi_scan.c
> +++ b/xen/arch/x86/dmi_scan.c
> @@ -233,7 +233,7 @@ void __init dmi_efi_get_table(const void *smbios, const void *smbios3)
>  	const struct smbios_eps *eps = smbios;
>  	const struct smbios3_eps *eps3 = smbios3;
>  
> -	if (eps3 && memcmp(eps3->anchor, "_SM3_", 5) == 0 &&
> +	if (eps3 && strncmp(eps3->anchor, "_SM3_", 5) == 0 &&
>  	    eps3->length >= sizeof(*eps3) &&
>  	    dmi_checksum(eps3, eps3->length)) {
>  		efi_smbios3_address = eps3->address;

This is a good example where MISRAs dictats make the code worse rather
than better.

The anchor is a magic number, and memcmp() is the correct check.  It
really is "is this byte pattern identical?"

It's just that the byte pattern is chosen to be coherent and logic in
ASCII, so the use of a "string" is also correct.

Previously 4cd66fb56dc697 was done, but that was on the belief that
those where the only two examples.

What variety of compilers has this been tried on?  Both Clang and GCC
have warnings about str*() functions on arrays and overflows, and
switching to mem*() was the solution.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 13:14:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 13:14:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008546.1387819 (Exim 4.92)
	(envelope-from )
	id 1uNWu5-0001JS-8y; Fri, 06 Jun 2025 13:14:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008546.1387819; Fri, 06 Jun 2025 13:14: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 1uNWu5-0001JL-5t; Fri, 06 Jun 2025 13:14:37 +0000
Received: by outflank-mailman (input) for mailman id 1008546;
 Fri, 06 Jun 2025 13:14: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 1uNWu4-0001JF-7h
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 13:14:36 +0000
Received: from mail36.us4.mandrillapp.com (mail36.us4.mandrillapp.com
 [205.201.136.36]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2df0a66d-42d8-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 15:14:30 +0200 (CEST)
Received: from pmta15.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail36.us4.mandrillapp.com (Mailchimp) with ESMTP id 4bDMGs32Q0zS6490c
 for ; Fri,  6 Jun 2025 13:14:29 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 943029341ed845ecaf7c959627a851d3; Fri, 06 Jun 2025 13:14: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: 2df0a66d-42d8-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1749215669; x=1749485669;
	bh=rmA1dBtxjSRg0bWhkqTxNO3I99+IO9Y74gvQliIpfNc=;
	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=0jnppKPRD/OzlNfjsep+/dt149kl1fAMZ2LbiujpQa7hslW0G0VP02McgbZyTQc+v
	 GQnUXP8EVk3CpuG81/6PqDHfVG9jkVGcSgTlZMC061ODYTaMgzEBVedTjizfKUWXNM
	 Y9Yszrpnbo86fH5PbipvSeavh4ij2/otzQRog1ctG2IhU4y/VwRS2sIQYcmUMfueJv
	 5cCXfn8oNSW9FSvhdp3030056tyYWc8iGjUwfEu3KBysO6HSmjgM5/TKA6wJpu3LhZ
	 p21Mlg0umRvklYTzYH1s9JbTtE68qL9vOqaVHpWVQ8+dt0q8msbniFvkQro000bGCJ
	 d1OF/15uc5uLA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1749215669; x=1749476169; i=teddy.astie@vates.tech;
	bh=rmA1dBtxjSRg0bWhkqTxNO3I99+IO9Y74gvQliIpfNc=;
	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=sk8wCndjKmPKUHXmVVnfS0mVElr09SzICnb1T7mWKEn53K/zRMlVVLTOf8oTbmHd/
	 cLzcP2tyvZi8iRP3q5C2QuUwO0wKp9ceFyhYNZmxzYibcrak60MToO4tQkX/iRx+uM
	 V3tFQSQYYxeU8/OACWofhYswn9QexJT/y8ierJZsY03uEKA0+kJ7qqp0cBH786UgiC
	 jNN+VhzYDUMnn6uG9dOo6WgbH3S37ObePj4gQqhoxCANF5oU5RTG5zLkhK0Vtbihsa
	 5tVQon2VLZE+QlW4hlxp0Ecqy/WhfLEIQyWZVdf2/QJfQUV+HhPjTaF+PL6g81BX2a
	 URCF939aCLgDQ==
From: "Teddy Astie" 
Subject: =?utf-8?Q?Re:=20[PATCH=20v5=204/6]=20x86:=20control=20memset()=20and=20memcpy()=20inlining?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1749215668377
Message-Id: <0c955c01-fc47-499f-b900-61de814cf16e@vates.tech>
To: "Jan Beulich" 
Cc: "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , xen-devel@lists.xenproject.org
References: <73481cbf-337f-4e85-81d2-3487366cd822@suse.com>   <0c9d2432-3c5c-4f93-8c07-99894d7f8606@suse.com>
In-Reply-To: <0c9d2432-3c5c-4f93-8c07-99894d7f8606@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.943029341ed845ecaf7c959627a851d3?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250606:md
Date: Fri, 06 Jun 2025 13:14:29 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Le 06/06/2025 =C3=A0 11:21, Jan Beulich a =C3=A9crit=C2=A0:
> On 05.06.2025 19:34, Teddy Astie wrote:
>> Le 05/06/2025 =C3=A0 12:28, Jan Beulich a =C3=A9crit=C2=A0:
>>> Stop the compiler from inlining non-trivial memset() and memcpy() (for
>>> memset() see e.g. map_vcpu_info() or kimage_load_segments() for
>>> examples). This way we even keep the compiler from using REP STOSQ /
>>> REP MOVSQ when we'd prefer REP STOSB / REP MOVSB (when ERMS is
>>> available).
>>>
>>
>> If the size is known and constant, and the compiler is able to generate
>> a trivial rep movs/stos (usually with a mov $x, %ecx before). I don't
>> see a reason to prevent it or forcing it to make a function call, as I
>> suppose it is very likely that the plain inline rep movs/stos will
>> perform better than a function call (even if it is not the prefered rep
>> movsb/stosb), eventually also being smaller.
>>
>> I wonder if it is possible to only generate inline rep movs/stos for
>> "trivial cases" (i.e preceded with a plain mov $x, %ecx), and rely on
>> either inline movs or function call in other cases (non-trivial ones).
> 
> Note how the description starts with "Stop the compiler from inlining
> non-trivial ...", which indeed remain unaffected according to my
> observations (back at the time).

Yes, at least it is what appears to happen when testing using GCC 14.2.0 
where non-trivial memset/memcpy are replaced with explicit functions 
call, and some trivial ones still use rep movsb/l/q.

Though,

> unrolled_loop:16:noalign,libcall:-1:noalign

to me sounds like :
- use a inline unrolled loop for 0-16 memcpy/memset
- call memset/memcpy for other cases
(thus no rep-prefix shall be used)

The align/noalign meaning being vaguely documented in GCC documentation, 
so it's unclear if it only affects "non-aligned" copies, or potentially 
all of them.

> 
> Jan
> 

Teddy


Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech




From xen-devel-bounces@lists.xenproject.org Fri Jun 06 13:23:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 13:23:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008557.1387828 (Exim 4.92)
	(envelope-from )
	id 1uNX2O-00031N-12; Fri, 06 Jun 2025 13:23:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008557.1387828; Fri, 06 Jun 2025 13:23: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 1uNX2N-00031G-Ui; Fri, 06 Jun 2025 13:23:11 +0000
Received: by outflank-mailman (input) for mailman id 1008557;
 Fri, 06 Jun 2025 13: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 1uNX2M-00031A-Mi
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 13:23:10 +0000
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com
 [2a00:1450:4864:20::431])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 63bc92bc-42d9-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 15:23:10 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a4f71831abso2012608f8f.3
 for ; Fri, 06 Jun 2025 06:23:09 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a53229ddf6sm1863121f8f.2.2025.06.06.06.23.08
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 06 Jun 2025 06:23:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 63bc92bc-42d9-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749216189; x=1749820989; 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=+RA3oAA0fRjkxd8M6I3h2YvnmRV+aiAIRF8e64DSjPo=;
        b=rIHdotuHoavV515OwnyAzIG72XDIM8M7uk9dzLuM0e2lWLcc38aMtIL8d3V3arAGJr
         L04pn0ue/cPl/IxzUdQNaFFK3zHc6j+t+A4hzRdwqVfqb0ieh1k39R8tZOvMGldTDOQM
         hNuOqlhnfnsaWXEA5jTdZEvLNDl4mJOAvsH14=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749216189; x=1749820989;
        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=+RA3oAA0fRjkxd8M6I3h2YvnmRV+aiAIRF8e64DSjPo=;
        b=orERWWOxsnL0VMuCH5bkV9jotuALMfvIuZpwuOQck4HReiWA7og6tOWohgd0MEfW4W
         ci0CSPsjmQ2T3GIm7nGBnM/DC54cKVmqJyc0GpGe4Zisma9XdyRyp1i1aCA3Mx7Aib2i
         VQRGdyIsB7sBBO9eBChybTeboN9IZZrgolde+hl9Bjcp9fzKWMYaFod5mV71YxhLferi
         AgTp8OQEzLv/NfF+rt6Mpc9Ae2UEnwi/4b0K69zFbawNfmbs2z4A3oYo/HXLkYI8Da1j
         PzZHBvH9Tr7FL+ShZvi/H3jB/dmxpyqWHV01EJfwVwn4Cz3L0R+vXP4x6H7xOYIlaSLb
         n29w==
X-Gm-Message-State: AOJu0Yzt42SBHe/MmIlpkcqdKjPHE4C7GjEfbaE4lXvWGV+HnDMcG7gr
	/xENjWY1IwWDbfkLxxGNE2VmFsV/LnkkeiWiVj+vj0uiOzk+woRsPbqutvwiz0tPUy0=
X-Gm-Gg: ASbGncvXxk/qz7h/4bRa/CgkwVvxSX+supUJF1Htbe/Let0pdSspujNRTIH7Mu/+fFH
	P5UOce8zFijPcnDsJVAQOBEc0Li3rBtCK1MyI/j3LaEUWJZXZZI/LLnAdT1ofM6/hPrZPWLqvbG
	6zTGUnyQejNo/9vMZwCTwKoazDR3uxQXGNiVL6WKGKGTFj8rLmrKWFAgmWUOIM7I5PhPMvrKMDb
	aBeY5bTWWOs2BurZNYylC16pgRhJ7huVj6REFSg2in/bh+ErbGXrv7aQWlZgS13EQ4fUkhf3peu
	cysa8o2Msluh4hSGZFlEY7Fqc2r5abB/LZE0N6fLE/xrQPBSWRWbaU2v4uzk7GxRBOK1rrqemAe
	YhLlcahPXvZJROhrr1Hk5yXmXRLMMVTVfIAE=
X-Google-Smtp-Source: AGHT+IHOuMOYkbX/SGvuPG6MvYOClUqiW/SLGQhRVNIwMcJSevBOU0Ahgr9uTuGGEm0BGvmAlEs4UQ==
X-Received: by 2002:a05:6000:4023:b0:3a0:9dfc:da4 with SMTP id ffacd0b85a97d-3a531ab6dd4mr2272631f8f.42.1749216189069;
        Fri, 06 Jun 2025 06:23:09 -0700 (PDT)
Date: Fri, 6 Jun 2025 15:23:07 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Tu Dinh 
Cc: xen-devel@lists.xenproject.org,
	Anthony PERARD ,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini ,
	Juergen Gross ,
	Anthoine Bourgeois 
Subject: Re: [PATCH v3] x86/hvmloader: select xenpci MMIO BAR UC or WB MTRR
 cache attribute
Message-ID: 
References: <20250605161659.18201-1-roger.pau@citrix.com>
 <1b290503-078e-491a-8552-b884df7ac747@vates.tech>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1b290503-078e-491a-8552-b884df7ac747@vates.tech>

On Fri, Jun 06, 2025 at 01:00:19PM +0000, Tu Dinh wrote:
> Hi Roger,
> 
> On 05/06/2025 18:20, Roger Pau Monne wrote:
> > The Xen PCI device (vendor ID 0x5853) exposed to x86 HVM guests doesn't
> > have the functionality of a traditional PCI device.  The exposed MMIO BAR
> > is used by some guests (including Linux) as a safe place to map foreign
> > memory, including the grant table itself.
> >
> > Traditionally BARs from devices have the uncacheable (UC) cache attribute
> > from the MTRR, to ensure correct functionality of such devices.  hvmloader
> > mimics this behavior and sets the MTRR attributes of both the low and high
> > PCI MMIO windows (where BARs of PCI devices reside) as UC in MTRR.
> >
> > This however causes performance issues for users of the Xen PCI device BAR,
> > as for the purposes of mapping remote memory there's no need to use the UC
> > attribute.  On Intel systems this is worked around by using iPAT, that
> > allows the hypervisor to force the effective cache attribute of a p2m entry
> > regardless of the guest PAT value.  AMD however doesn't have an equivalent
> > of iPAT, and guest PAT values are always considered.
> >
> > Linux commit:
> >
> > 41925b105e34 xen: replace xen_remap() with memremap()
> >
> > Attempted to mitigate this by forcing mappings of the grant-table to use
> > the write-back (WB) cache attribute.  However Linux memremap() takes MTRRs
> > into account to calculate which PAT type to use, and seeing the MTRR cache
> > attribute for the region being UC the PAT also ends up as UC, regardless of
> > the caller having requested WB.
> >
> > As a workaround to allow current Linux to map the grant-table as WB using
> > memremap() introduce an xl.cfg option (xenpci_bar_uc=0) that can be used to
> > select whether the Xen PCI device BAR will have the UC attribute in MTRR.
> > Such workaround in hvmloader should also be paired with a fix for Linux so
> > it attempts to change the MTRR of the Xen PCI device BAR to WB by itself.
> >
> > Overall, the long term solution would be to provide the guest with a safe
> > range in the guest physical address space where mappings to foreign pages
> > can be created.
> >
> > Some vif throughput performance figures provided by Anthoine from a 8
> > vCPUs, 4GB of RAM HVM guest(s) running on AMD hardware:
> >
> > Without this patch:
> > vm -> dom0: 1.1Gb/s
> > vm -> vm:   5.0Gb/s
> >
> > With the patch:
> > vm -> dom0: 4.5Gb/s
> > vm -> vm:   7.0Gb/s
> >
> > Reported-by: Anthoine Bourgeois 
> > Signed-off-by: Roger Pau Monné 
> > ---
> > Changes since v2:
> >   - Add default value in xl.cfg.
> >   - List xenstore path in the pandoc file.
> >   - Adjust comment in hvmloader.
> >   - Fix commit message MIO -> MMIO.
> >
> > Changes since v1:
> >   - Leave the xenpci BAR as UC by default.
> >   - Introduce an option to not set it as UC.
> > ---
> >   docs/man/xl.cfg.5.pod.in                |  8 ++++
> >   docs/misc/xenstore-paths.pandoc         |  5 +++
> >   tools/firmware/hvmloader/config.h       |  2 +-
> >   tools/firmware/hvmloader/pci.c          | 49 ++++++++++++++++++++++++-
> >   tools/firmware/hvmloader/util.c         |  2 +-
> >   tools/include/libxl.h                   |  9 +++++
> >   tools/libs/light/libxl_create.c         |  1 +
> >   tools/libs/light/libxl_dom.c            |  9 +++++
> >   tools/libs/light/libxl_types.idl        |  1 +
> >   tools/xl/xl_parse.c                     |  2 +
> >   xen/include/public/hvm/hvm_xs_strings.h |  2 +
> >   11 files changed, 86 insertions(+), 4 deletions(-)
> >
> > diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> > index c388899306c2..ddbff6fffc16 100644
> > --- a/docs/man/xl.cfg.5.pod.in
> > +++ b/docs/man/xl.cfg.5.pod.in
> > @@ -2351,6 +2351,14 @@ Windows L.
> >   Setting B with the default device_model "qemu-xen"
> >   requires at least QEMU 1.6.
> >
> > +
> > +=item B
> > +
> > +B Select whether the memory BAR of the Xen PCI device should have
> > +uncacheable (UC) cache attribute set in MTRR.
> > +
> > +Default is B.
> > +
> >   =item B or B
> >
> >   The groups of Microsoft Hyper-V (AKA viridian) compatible enlightenments
> > diff --git a/docs/misc/xenstore-paths.pandoc b/docs/misc/xenstore-paths.pandoc
> > index 01a340fafcbe..073bed91eec1 100644
> > --- a/docs/misc/xenstore-paths.pandoc
> > +++ b/docs/misc/xenstore-paths.pandoc
> > @@ -234,6 +234,11 @@ These xenstore values are used to override some of the default string
> >   values in the SMBIOS table constructed in hvmloader. See the SMBIOS
> >   table specification at http://www.dmtf.org/standards/smbios/
> >
> > +#### ~/hvmloader/pci/xenpci-bar-uc = ("1"|"0") [HVM,INTERNAL]
> > +
> > +Select whether the Xen PCI device MMIO BAR will have the uncacheable cache
> > +attribute set in the MTRRs by hvmloader.
> > +
> >   #### ~/bios-strings/oem-* = STRING [HVM,INTERNAL]
> >
> >   1 to 99 OEM strings can be set in xenstore using values of the form
> > diff --git a/tools/firmware/hvmloader/config.h b/tools/firmware/hvmloader/config.h
> > index 6e1da137d779..c159db30eea9 100644
> > --- a/tools/firmware/hvmloader/config.h
> > +++ b/tools/firmware/hvmloader/config.h
> > @@ -58,7 +58,7 @@ extern uint32_t *cpu_to_apicid;
> >   #define ACPI_TIS_HDR_ADDRESS 0xFED40F00UL
> >
> >   extern uint32_t pci_mem_start;
> > -extern const uint32_t pci_mem_end;
> > +extern uint32_t pci_mem_end;
> >   extern uint64_t pci_hi_mem_start, pci_hi_mem_end;
> >
> >   extern bool acpi_enabled;
> > diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
> > index cc67b18c0361..747f6cfb6794 100644
> > --- a/tools/firmware/hvmloader/pci.c
> > +++ b/tools/firmware/hvmloader/pci.c
> > @@ -30,7 +30,7 @@
> >   #include 
> >
> >   uint32_t pci_mem_start = HVM_BELOW_4G_MMIO_START;
> > -const uint32_t pci_mem_end = RESERVED_MEMBASE;
> > +uint32_t pci_mem_end = RESERVED_MEMBASE;
> >   uint64_t pci_hi_mem_start = 0, pci_hi_mem_end = 0;
> >
> >   /*
> > @@ -116,6 +116,8 @@ void pci_setup(void)
> >        * experience the memory relocation bug described below.
> >        */
> >       bool allow_memory_relocate = 1;
> > +    /* Select the MTRR cache attribute of the xenpci device BAR. */
> > +    bool xenpci_bar_uc = false;
> 
> Since this is meant to be a workaround, I wonder if it makes more sense
> to flip the setting (`xenpci_bar_wb`) and make it 0 by default?

I originally didn't want to go that route, because while it's true
that the default MTRR type is set to WB, and so any memory not covered
by a MTRR range will default to that memory type I got the impression
this was inferring too much.

Overall my intention would be for inverting the default long term, and
libxl setting build_info->u.hvm.xenpci_bar_uc = false by default,
which then makes all the naming nicer IMO.

> It also
> simplifies the logic for both hvmloader and the consumer (no need for
> double negatives).

I don't think there are double negatives?  That would happen if the
variable was named xenpci_bar_no_uc or similar?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 13:25:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 13:25:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008568.1387838 (Exim 4.92)
	(envelope-from )
	id 1uNX52-0003aB-Dy; Fri, 06 Jun 2025 13:25:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008568.1387838; Fri, 06 Jun 2025 13: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 1uNX52-0003a4-BG; Fri, 06 Jun 2025 13:25:56 +0000
Received: by outflank-mailman (input) for mailman id 1008568;
 Fri, 06 Jun 2025 13:25: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 1uNX51-0003Zy-0m
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 13:25:55 +0000
Received: from mail132-4.atl131.mandrillapp.com
 (mail132-4.atl131.mandrillapp.com [198.2.132.4])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c5145c55-42d9-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 15:25:53 +0200 (CEST)
Received: from pmta09.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail132-4.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4bDMX02tCjzlgMHS
 for ; Fri,  6 Jun 2025 13:25:52 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 a41518aacceb4cd2865e87b16ebd8c84; Fri, 06 Jun 2025 13:25: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: c5145c55-42d9-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1749216352; x=1749486352;
	bh=pKtdmWwVTl323wr3IxBBT/chgkj+dBGCyHJFfn9HzSs=;
	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=LOBADznMdhQixqm8UQ/+5eQPcpdZQo7Vp/YU8g5fL6mjf1clJndOZLjA/aB6sI6cI
	 rGCO7kDvuTxdVaj6B6+Wznt5ejV3jN5Hxi+AruIOgpLPKPoCz6fDL59QThN/x6lrID
	 TrZiPOxJqeOv2/aEnGC80IHJKU5i6adDyVMl/gpBT5n4iWzmPb/OmtXFar7k95SwLX
	 wogFZagTnMghTjcu0Qpiivvy1Pch/rdBqz1uySrjLzPp/LZtDrJ2H8yynPeZZibar7
	 vXqK3ODQpUSgEnAxzIyZx3ymYmtFonSXWW/xZckL+pRCUVR/OZIH65DfDymsUlnCqe
	 o6AkA+Xix7Gzg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1749216352; x=1749476852; i=teddy.astie@vates.tech;
	bh=pKtdmWwVTl323wr3IxBBT/chgkj+dBGCyHJFfn9HzSs=;
	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=1tpbsm825U1rLjA4A4S27fNxDvyUZzBOHQAjn9oziDymk4uARvBkHir+kpWP8ZngO
	 K9JXo2ojV0q7LGJSCtGSrZzyrdKa6KJU3AL3gXABlHHWRvs44GtjbL1qnrhAEuvPE7
	 HNY5EQLyAdW/eefd8eaXDj9Jz1g6Fzx5Mx78/oXjo3je5r5QUFu7SQS3fNMaTjtdvv
	 xQwE8mRZvo1NDfPgNEgrulKzW6+U+K/bkNzDoSbcpc+4G2g1eiKwzVFeB/+NtPfXQu
	 gkaqMfUiTZl7HOyjlJgltr0zXPuDVhvkUxGi8QUrqTsKkFvT8Xb5iZM6F69pEn0NWy
	 7hDHD6kiX6GFA==
From: "Teddy Astie" 
Subject: =?utf-8?Q?Re:=20[PATCH=20v5=203/6]=20x86:=20re-work=20memcpy()?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1749216351289
Message-Id: 
To: "Jan Beulich" 
Cc: "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , xen-devel@lists.xenproject.org
References: <73481cbf-337f-4e85-81d2-3487366cd822@suse.com> <017e689a-41a2-4722-a5e7-19ffef27500f@suse.com> <81da4e8e-9dcf-4630-a535-39ce0b07260c@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.a41518aacceb4cd2865e87b16ebd8c84?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250606:md
Date: Fri, 06 Jun 2025 13:25:52 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Le 06/06/2025 =C3=A0 11:13, Jan Beulich a =C3=A9crit=C2=A0:
> On 05.06.2025 19:06, Teddy Astie wrote:
>> Le 05/06/2025 =C3=A0 12:27, Jan Beulich a =C3=A9crit=C2=A0:
>>> Move the function to its own assembly file. Having it in C just for the
>>> entire body to be an asm() isn't really helpful. Then have two flavors:
>>> A "basic" version using qword steps for the bulk of the operation, and =
an
>>> ERMS version for modern hardware, to be substituted in via alternatives
>>> patching.
>>>
>>> Alternatives patching, however, requires an extra precaution: It uses
>>> memcpy() itself, and hence the function may patch itself. Luckily the
>>> patched-in code only replaces the prolog of the original function. Make
>>> sure this remains this way.
>>
>> We can probably workaround that by using a separate memcpy for
>> alternatives patching. So it wouldn't end up patching itself.
> 
> We could, yes, but imo we better wouldn't.
> 

As Andrew pointed out that it's not that simple to use a separate 
memcpy. So should probably keep the current approach.

>> Aside that:
>> Reviewed-by: Teddy Astie 
> 
> Please clarify whether this applies without that suggestion of yours take=
n
> care of.
> 

Yes.

> Jan

Teddy


Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech




From xen-devel-bounces@lists.xenproject.org Fri Jun 06 13:38:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 13:38:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008580.1387848 (Exim 4.92)
	(envelope-from )
	id 1uNXGh-0005S0-H5; Fri, 06 Jun 2025 13:37:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008580.1387848; Fri, 06 Jun 2025 13:37: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 1uNXGh-0005Rt-E7; Fri, 06 Jun 2025 13:37:59 +0000
Received: by outflank-mailman (input) for mailman id 1008580;
 Fri, 06 Jun 2025 13:37: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 1uNXGf-0005Rn-AC
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 13:37:57 +0000
Received: from mail36.us4.mandrillapp.com (mail36.us4.mandrillapp.com
 [205.201.136.36]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 736fb3ea-42db-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 15:37:55 +0200 (CEST)
Received: from pmta15.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail36.us4.mandrillapp.com (Mailchimp) with ESMTP id 4bDMnt3fJzzS62JQf
 for ; Fri,  6 Jun 2025 13:37:54 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 4168c5e9f2574c5d8e300645e2c4cfbb; Fri, 06 Jun 2025 13:37: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: 736fb3ea-42db-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1749217074; x=1749487074;
	bh=FVH3r1YoO0xTmK+f/mZlpEPpzXh0CkRhWDBPMn7fC+k=;
	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=ylC+Q38s9Q8Gc3eNpa4h1koVjN1c/rBgBewd2EJxKZm8ghKasGXzJynJZywb+BlUt
	 cNyT0ar8c3iExxtBPJNecUFfto90IiWOKD+y1BL9h6GC//yzdmSRmbFNnWezeQIK4v
	 YDn+7IJtlJB9zs27aSe6xt1HtkZt05N685YlRT1NC217e1cnIhVlBZKnzWQszMIkMf
	 nnsvIlBX2bLZZxVZ52dqM7qdBokCedMn08yhUIBDBvD1tiEosik9GzskZWXkcUaQlH
	 DgT7q41MKy+do5VRcSHilvTDj/hEarIKox4O9pWhsPvMqC2eb05cx0YVjrqz/nftzk
	 muHJLF1pnupfA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1749217074; x=1749477574; i=ngoc-tu.dinh@vates.tech;
	bh=FVH3r1YoO0xTmK+f/mZlpEPpzXh0CkRhWDBPMn7fC+k=;
	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=gP+EmS43DaKryPOr69N23kYl14w6P91D6PeidIrFcPFTFaJMliXOcCXhEFSMhVKBn
	 cxod87EhaQVN3kEfe/x0LNv038tXfPP2EJrTF/oBRQytja+Ne71J2GLwKdUnE3MCPD
	 NYaCRYT2cpMNdXjslx/pxleET5mYbxuSeFO7SQIxK7M0DdCQeGjO/3RGJz5r/CH6wM
	 vNpmi9W3FUpdp+BXw057G3drjRTj6XteB8Fl+Hv2Fg/iALlLSEN2EBzV//uOlXafTF
	 PrkX1u/hBiuIZOkiUvgkowdkJ7Gnou3ZkyTQswgC1VZs27FYMIcQWzh2iMuSm0Od8P
	 S2PVP/wBtRRGg==
From: "Tu Dinh" 
Subject: =?utf-8?Q?Re:=20[PATCH=20v3]=20x86/hvmloader:=20select=20xenpci=20MMIO=20BAR=20UC=20or=20WB=20MTRR=20cache=20attribute?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1749217073208
Message-Id: <5e6b51ba-1550-4896-bbc9-eb5076ce057c@vates.tech>
To: "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" 
Cc: xen-devel@lists.xenproject.org, "Anthony PERARD" , "Andrew Cooper" , "Michal Orzel" , "Jan Beulich" , "Julien Grall" , "Stefano Stabellini" , "Juergen Gross" , "Anthoine Bourgeois" 
References: <20250605161659.18201-1-roger.pau@citrix.com> <1b290503-078e-491a-8552-b884df7ac747@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.4168c5e9f2574c5d8e300645e2c4cfbb?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250606:md
Date: Fri, 06 Jun 2025 13:37:54 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 06/06/2025 15:23, Roger Pau Monn=C3=A9 wrote:
[...]
>>
>> Since this is meant to be a workaround, I wonder if it makes more sense
>> to flip the setting (`xenpci_bar_wb`) and make it 0 by default?
> 
> I originally didn't want to go that route, because while it's true
> that the default MTRR type is set to WB, and so any memory not covered
> by a MTRR range will default to that memory type I got the impression
> this was inferring too much.
> 
> Overall my intention would be for inverting the default long term, and
> libxl setting build_info->u.hvm.xenpci_bar_uc =3D false by default,
> which then makes all the naming nicer IMO.
> 
>> It also
>> simplifies the logic for both hvmloader and the consumer (no need for
>> double negatives).
> 
> I don't think there are double negatives?  That would happen if the
> variable was named xenpci_bar_no_uc or similar?

It's because from the flag consumer's viewpoint, I saw the flag 
`xenpci_bar_uc` as rather "xenpci_bar_dont_apply_wb_workaround`. But if 
the intention is to eventually make it default then the naming is OK for me=
.

> 
> Thanks, Roger.




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 Jun 06 13:41:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 13:41:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008587.1387858 (Exim 4.92)
	(envelope-from )
	id 1uNXKP-0007BG-Vw; Fri, 06 Jun 2025 13:41:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008587.1387858; Fri, 06 Jun 2025 13: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 1uNXKP-0007B9-TA; Fri, 06 Jun 2025 13:41:49 +0000
Received: by outflank-mailman (input) for mailman id 1008587;
 Fri, 06 Jun 2025 13: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 1uNXKP-0007B3-6x
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 13:41:49 +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 fdc19003-42db-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 15:41:47 +0200 (CEST)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-450ccda1a6eso19867935e9.2
 for ; Fri, 06 Jun 2025 06:41:47 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-4526e155500sm21536425e9.9.2025.06.06.06.41.46
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 06 Jun 2025 06:41:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fdc19003-42db-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749217307; x=1749822107; 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=Ymo80vA0vHQD5Iy1MDAQhM1cAuhmA0PNB+gvHFqilmQ=;
        b=qqsv4bWDRABsSllhvOOEUTIE+qWRgE06DFr8LAW4cvhqnYQbPrC/56wG3Pnsvkghc2
         2H6RWTdqR7KO/XUbCerVJGVcAhnAapcs5vRmx5KGrPVFXPg6IYzXuTwkAvLrlzjbReQP
         1neCjDJIyH14fCCohSVJh27+vLIyHcd6SgfEM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749217307; x=1749822107;
        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=Ymo80vA0vHQD5Iy1MDAQhM1cAuhmA0PNB+gvHFqilmQ=;
        b=P0kuUMvpiFwJkx1cSu9hgt46aAz0E7ekbmQxPX9tSSjSL5rEdaNrMV94UFWRR96oU5
         dgs9GnT1xVdg4sse3M7O8j+tyxbdtPqsUuLbV+Du/3kgPkgaLEHeBBAb9hx4seqgGBnD
         czIfnbisWuF8t5V2SJ9IHe6KUHtjPP4/Od0woHx3xfHaogxIYlnnU8pgvBdxPaXZo/bo
         ZcWeLqH96UKN08aiCGoOyaKcSF6FmmUZz75AiSTudH3xa0clXuiXimOyGprJNYHlSt0i
         md+C+j8o7AqAKfXuEoRBy71rkvS1jf1uezrfJliw+f0xKqdDYtfVPfg2/Z3eoJb/kzdr
         qHFw==
X-Gm-Message-State: AOJu0Yw4pM1T1P42QMhvRn3ucZ83T2RgD9C8hgl77fwLPg5JZPXXNtQ9
	f+nNYRIjS7Bie2agJD5grWZVyk7QToUO9gTWU2k2advnwhjPELOk0+U26w9ptSwP7so=
X-Gm-Gg: ASbGncvtSrmErvfHFuP++j81uRd2rfvD0FfNE+26e+Wyo7XUg7rsHZWy7Y+BdMaPovi
	8HSHC+hOGZ0nrkHJw9lWVtvAYRnHf9X0sixqbF94TtkDKWderMKVrS2B/JojY1Lpgnxm8JzwzeX
	YMTHfFw2laqjFgiI1UouED5IlUBqPHz63/SMSHWY5AUuI56HJkDxG/PSCuzXV3p4KoA+rXSudMh
	RgcvZH5WPUST4Iv3lDjvAVIHHRhGmxH5Z6s+raCMvgKaTvSIbzb+CszFPdudcl915l+dYrkfhX5
	Kh6G0gbPNDHrWBTwVp+XbM/C77UpcW1WZ0yZBw2hqWAhk7HEH090Q5HkxXZ7uHVaBCEexz5gm8l
	ZtscnlmUi0nnigQCEqFI11ic6xtJJPHROfA+WhNRdaCXfHA==
X-Google-Smtp-Source: AGHT+IG60L6n74zZ0jBzJQchWI5qq3g1s6FH6k7jETvY0XsYkfVjcSy/TZ4Ql5DQHNFI3Rfu+vOuZw==
X-Received: by 2002:a05:600c:548d:b0:43d:3df:42d8 with SMTP id 5b1f17b1804b1-45201437aa8mr35379895e9.6.1749217306590;
        Fri, 06 Jun 2025 06:41:46 -0700 (PDT)
Date: Fri, 6 Jun 2025 15:41:45 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Oleksii Kurochko 
Cc: xen-devel@lists.xenproject.org,
	Anthony PERARD ,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini ,
	Juergen Gross ,
	Anthoine Bourgeois 
Subject: Re: [PATCH v3] x86/hvmloader: select xenpci MMIO BAR UC or WB MTRR
 cache attribute
Message-ID: 
References: <20250605161659.18201-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: <20250605161659.18201-1-roger.pau@citrix.com>

On Thu, Jun 05, 2025 at 06:16:59PM +0200, Roger Pau Monne wrote:
> The Xen PCI device (vendor ID 0x5853) exposed to x86 HVM guests doesn't
> have the functionality of a traditional PCI device.  The exposed MMIO BAR
> is used by some guests (including Linux) as a safe place to map foreign
> memory, including the grant table itself.
> 
> Traditionally BARs from devices have the uncacheable (UC) cache attribute
> from the MTRR, to ensure correct functionality of such devices.  hvmloader
> mimics this behavior and sets the MTRR attributes of both the low and high
> PCI MMIO windows (where BARs of PCI devices reside) as UC in MTRR.
> 
> This however causes performance issues for users of the Xen PCI device BAR,
> as for the purposes of mapping remote memory there's no need to use the UC
> attribute.  On Intel systems this is worked around by using iPAT, that
> allows the hypervisor to force the effective cache attribute of a p2m entry
> regardless of the guest PAT value.  AMD however doesn't have an equivalent
> of iPAT, and guest PAT values are always considered.
> 
> Linux commit:
> 
> 41925b105e34 xen: replace xen_remap() with memremap()
> 
> Attempted to mitigate this by forcing mappings of the grant-table to use
> the write-back (WB) cache attribute.  However Linux memremap() takes MTRRs
> into account to calculate which PAT type to use, and seeing the MTRR cache
> attribute for the region being UC the PAT also ends up as UC, regardless of
> the caller having requested WB.
> 
> As a workaround to allow current Linux to map the grant-table as WB using
> memremap() introduce an xl.cfg option (xenpci_bar_uc=0) that can be used to
> select whether the Xen PCI device BAR will have the UC attribute in MTRR.
> Such workaround in hvmloader should also be paired with a fix for Linux so
> it attempts to change the MTRR of the Xen PCI device BAR to WB by itself.
> 
> Overall, the long term solution would be to provide the guest with a safe
> range in the guest physical address space where mappings to foreign pages
> can be created.
> 
> Some vif throughput performance figures provided by Anthoine from a 8
> vCPUs, 4GB of RAM HVM guest(s) running on AMD hardware:
> 
> Without this patch:
> vm -> dom0: 1.1Gb/s
> vm -> vm:   5.0Gb/s
> 
> With the patch:
> vm -> dom0: 4.5Gb/s
> vm -> vm:   7.0Gb/s
> 
> Reported-by: Anthoine Bourgeois 
> Signed-off-by: Roger Pau Monné 
> ---
> Changes since v2:
>  - Add default value in xl.cfg.
>  - List xenstore path in the pandoc file.
>  - Adjust comment in hvmloader.
>  - Fix commit message MIO -> MMIO.
> 
> Changes since v1:
>  - Leave the xenpci BAR as UC by default.
>  - Introduce an option to not set it as UC.
> ---
>  docs/man/xl.cfg.5.pod.in                |  8 ++++
>  docs/misc/xenstore-paths.pandoc         |  5 +++
>  tools/firmware/hvmloader/config.h       |  2 +-
>  tools/firmware/hvmloader/pci.c          | 49 ++++++++++++++++++++++++-
>  tools/firmware/hvmloader/util.c         |  2 +-
>  tools/include/libxl.h                   |  9 +++++
>  tools/libs/light/libxl_create.c         |  1 +
>  tools/libs/light/libxl_dom.c            |  9 +++++
>  tools/libs/light/libxl_types.idl        |  1 +
>  tools/xl/xl_parse.c                     |  2 +
>  xen/include/public/hvm/hvm_xs_strings.h |  2 +
>  11 files changed, 86 insertions(+), 4 deletions(-)

I've noticed this is missing a changelog entry, I propose the
following:

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 1ee2f42e7405..23215a8cc1e6 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -15,6 +15,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
  - On x86:
    - Restrict the cache flushing done as a result of guest physical memory map
      manipulations and memory type changes.
+   - Allow controlling the MTRR cache attribute of the Xen PCI device BAR
+     for HVM guests, to improve performance of guests using it to map the grant
+     table or foreign memory.
 
 ### Added
  - On x86:

I can fold into the patch if Oleksii and others agree.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 15:01:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 15:01:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008623.1387869 (Exim 4.92)
	(envelope-from )
	id 1uNYZZ-0000sA-Fb; Fri, 06 Jun 2025 15:01:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008623.1387869; Fri, 06 Jun 2025 15:01: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 1uNYZZ-0000s3-Cg; Fri, 06 Jun 2025 15:01:33 +0000
Received: by outflank-mailman (input) for mailman id 1008623;
 Fri, 06 Jun 2025 15:01: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 1uNYZY-0000rx-O3
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 15:01:32 +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 218b9694-42e7-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 17:01:31 +0200 (CEST)
Received: by mail-lf1-x12f.google.com with SMTP id
 2adb3069b0e04-54afb5fcebaso2559795e87.3
 for ; Fri, 06 Jun 2025 08:01:31 -0700 (PDT)
Received: from [192.168.86.29] ([90.250.112.104])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45213709670sm26906945e9.25.2025.06.06.08.01.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 06 Jun 2025 08:01:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 218b9694-42e7-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749222091; x=1749826891; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=+nHSm0VmCP01wzN9C94Ehkh0QkA9bkuYeAVcGZ4qWLM=;
        b=SgxnddYzkKBSb+I/coQjOO7MHos9wDjbSoihN/YVjCDaBebB1UVFgnmJOT5145ZMQj
         b6Ey4+9S9cVVN0vXVZ+pff+Nz4uL37C2NxeZnQiRvR/h6kkTUQZ/g5NtRk/BjL5jOxE1
         6HFm5dAAkZUmPVqkConQPRoVrheTaHZpoeIYM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749222091; x=1749826891;
        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=+nHSm0VmCP01wzN9C94Ehkh0QkA9bkuYeAVcGZ4qWLM=;
        b=M26go2u4ePCfKZJNa1liu2XAKkS4nj6fAKZ9eX3AFdAldbqXjHcfy7BgbpKFy+tMl8
         Aj9CH0M6YBh4xFUqg8JwttdVc+fHSv1KeD7hFpe3bbrQZnWktY/sOFGCQ3+2D+5lYPS3
         9GNcaaH/y4hCeA3YcOE7+oG7JRfjO7h1rymABxLLLxhLVh2Fy5jQKsMPDFgituETona7
         1zOW3dfmOhc73wW7MrDD2e/ueTZ2xXR+ZbIHaJ5U4SKjjZy0M5zmZjFq/DaQ4SPIGw6h
         uP6l5DnaTncr3Ub5pFbnE3/tyQ+zLs0DCvWM8zaHUEOxfYwpN5popBwcGJGL3WEgwr31
         fxpw==
X-Forwarded-Encrypted: i=1; AJvYcCUeHmeWMU3v62DCSXJF9Glb+Rs3IAK3QW3lVU9BfbJoHofpz6SCUObn6nMBDVAIDJLQ/C3DxbxIP/E=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzITelZ8n1xpLf/U7VxMewGYLIy+r5D2uGHuIuXq2Qvp2CA1XG8
	S0pJO387kpAFVJER6Z7dnaIvOJ4uFiIohvi1BMCwTtceWA7v0Dr3MyeAHVOrMz8its4fPN/pVvy
	+1FGk
X-Gm-Gg: ASbGncvNhLZEJpnTI0IKjbQV0mLAViUn2KsK5Y4wdnrh4yuUiDfYf1YdkV/JQAhYYVu
	jGwnorXzrDz+StBEmlYg/UfUVDBJQUy05T2jXf7pv6rJamveyd9cYnER3Qh7cZD8kU6O8sQvfnj
	aDwQdpdr6TCjk4Y54irxBavtRa8mLE/lLFKoR0aE67cbFaKXR9ffXivHR6MJ0ftOdUpxOFN33Lf
	kxgGdaJUzYLA53HycdUPlFlZMRV7t/rUeACmQBke5EQV7VduV9eCxxdu3tO48ezDH6OVlPzBYJD
	8StuaoZl1nMwz3AYH+67z0R1sfrkQf+qVQ4uhuU4b5p8XA1wHdpgnS790SJS2lV/aCk7skIKDP8
	=
X-Google-Smtp-Source: AGHT+IGSN9XfLtAcfIHxSPt/jW3uzPjLx+u/8tbbeWI5ipmEnZGm5UGTTZEms0kKajAdHOR9L3153w==
X-Received: by 2002:a05:600c:83cf:b0:442:e147:bea6 with SMTP id 5b1f17b1804b1-45201391335mr40926935e9.11.1749222077174;
        Fri, 06 Jun 2025 08:01:17 -0700 (PDT)
Message-ID: <3f9c5a18-2ea1-4e2d-80a0-773abc3598ae@citrix.com>
Date: Fri, 6 Jun 2025 16:01:15 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/3] x86/EFI: Fix detection of buildid
To: Jan Beulich 
Cc: Ross Lagerwall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 "Daniel P . Smith" ,
 Xen-devel 
References: <20250605111638.2869914-1-andrew.cooper3@citrix.com>
 <20250605111638.2869914-2-andrew.cooper3@citrix.com>
 <0a314400-126a-4c2a-b36c-dda61bb0b751@suse.com>
 
 <4d1f1b70-e309-453b-bae6-e066d49a417a@suse.com>
 <9200277c-aa8e-4fd9-ab6a-f9e106114f54@citrix.com>
 <6eaf2b27-969a-4326-9726-8b6e0994e006@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: <6eaf2b27-969a-4326-9726-8b6e0994e006@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 06/06/2025 8:22 am, Jan Beulich wrote:
> On 05.06.2025 19:01, Andrew Cooper wrote:
>> On 05/06/2025 2:24 pm, Jan Beulich wrote:
>>> On 05.06.2025 14:14, Andrew Cooper wrote:
>>>> On 05/06/2025 1:02 pm, Jan Beulich wrote:
>>>>> On 05.06.2025 13:16, Andrew Cooper wrote:
>>>> This really is a property of being a PE32+ binary, and nothing to do
>>>> with EFI.
>>> Which still can be checked for without having this code path being taken
>>> for xen.gz, too: You could e.g. check for &efi > &_end. That's firmly an
>>> image property (yet I expect you're going to sigh about yet another hack).
>> It's all hacks, but no.
>>
>> I'm amazed MISRA hasn't spotted that we've got a global `struct efi
>> efi;` and a label named efi, creating an alias for the object with it
>> out of bounds in the compiled image.  But even then, it's based on
>> XEN_BUILD_EFI not XEN_BUILD_PE and does not distinguish the property
>> that matters.
> The use of XEN_BUILD_EFI in the linker script should have been switched
> to XEN_BUILD_PE when the split was introduced.

That doesn't build.  As I already explained, the stubs aren't split in a
way that allows that.
>> But the argument I'm going to make this this:  Why do you want a check,
>> even if you can find a correct one (and as said before, I cannot)?
>>
>> This function is run exactly once.  We've excluded "nothing given by the
>> toolchain", and excluded "what the toolchain gave us was not the
>> expected ELF note".  The only thing left (modulo toolchain bugs) is the
>> CodeView region, and if it's not a valid CodeView region then we've
>> wasted a handful of cycles.
> Two reasons: Having code which cannot possibly do anything useful isn't
> good. Misra calls the latest the body of the inner if() "unreachable code"
> and objects to the presence of such in a build.

It's not unreachable code, not even theoretically.

*If* there was a suitable check, I'd be using it, but everything you've
proposed has been buggy or doesn't even compile.

> And then, based on your reasoning above, why don't you also drop the
> #ifdef CONFIG_X86?

Because that's the one non-buggy way of excluding an impossible case.

x86 is the only architecture possibly linking with pep emulation, and
therefore the only architecture to possibly have a CodeView record.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 15:54:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 15:54:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008640.1387882 (Exim 4.92)
	(envelope-from )
	id 1uNZOt-0006tW-DG; Fri, 06 Jun 2025 15:54:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008640.1387882; Fri, 06 Jun 2025 15:54:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNZOt-0006tP-9W; Fri, 06 Jun 2025 15:54:35 +0000
Received: by outflank-mailman (input) for mailman id 1008640;
 Fri, 06 Jun 2025 15:54: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 1uNZOs-0006t0-8n
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 15:54:34 +0000
Received: from fhigh-a5-smtp.messagingengine.com
 (fhigh-a5-smtp.messagingengine.com [103.168.172.156])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 87f580ff-42ee-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 17:54:31 +0200 (CEST)
Received: from phl-compute-04.internal (phl-compute-04.phl.internal
 [10.202.2.44])
 by mailfhigh.phl.internal (Postfix) with ESMTP id 6A76A1140138;
 Fri,  6 Jun 2025 11:54:29 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-04.internal (MEProxy); Fri, 06 Jun 2025 11:54:29 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
 6 Jun 2025 11:54:27 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 87f580ff-42ee-11f0-a301-13f23c93f187
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=1749225269;
	 x=1749311669; bh=d0iuc7C3aHvVo35g/BrZQyYViTr46z18Vum1rG9J824=; b=
	pSuoQLl/lPuWdJJOcvBISjqgEhqkB1R8dxTveIJh7VSZzSVhLMKV/eykR5ETzx5b
	tGi+BxpbaDWsUJLBq9Z4VWoQSm8HTu509VnvD/M3w0K+oW/DdUj/crkOc0cVGne/
	Wt6wAIXgezwE6jWG8pyy2CUvsmSvyTe613UIbo89s8i9SD1RJDI9/DdZUt77XVB4
	toj2m2iq1A6P3HY5LgrxYVJ1TTL6nZpCxPXqWp6TrpzHUCM3yS2czFW8QbSWAYtz
	g411RfBFtVgX1oH1qrpkUqLWAi/NWGWZr87TslnFIZsFay4GGCUZ4bKRtrf2CBwF
	3ri2AbEBeSFdR39lQOdtZA==
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=
	1749225269; x=1749311669; bh=d0iuc7C3aHvVo35g/BrZQyYViTr46z18Vum
	1rG9J824=; b=UYpuudYql+aSk7nAnD0BqjSfpNDobzUmDbO7mkWtk+d26Lm+njg
	OlrObRoKYiNIvPWkfa4TJKuSBN3Utv6b30JGHHydGNr0uGSNKYf1GvC+8g/6+pE7
	UiUzcFn2VAET2WnyPvWKrJnUhwWBQMGFKY0pg5wb6vsR1oFIsBDTqwTs9KQsVHyP
	BZqHy8iotPoK5gFAEqBvc0I6LH/kn/DRRyLsoYCvqLPURhMsbI36SqT4sEBTvYoS
	lbAFc22synHLiov+zxY2kDuPG1XdG/fhhFoVJkJYoisW9/eQLl3QbFtctTHK26Vq
	7rXhItPaqaTRyxNpLOS8UFn5wOfzW3FE8Lg==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugdehvdelucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtjeen
    ucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomh
    grrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggft
    rfgrthhtvghrnhepgfduleetfeevhfefheeiteeliefhjefhleduveetteekveettddvge
    euteefjedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho
    mhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnh
    gspghrtghpthhtohepkedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepjhgsvghu
    lhhitghhsehsuhhsvgdrtghomhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsth
    hsrdigvghnphhrohhjvggtthdrohhrghdprhgtphhtthhopehrohhgvghrrdhprghusegt
    ihhtrhhigidrtghomhdprhgtphhtthhopegrnhhthhhonhihrdhpvghrrghrugesvhgrth
    gvshdrthgvtghhpdhrtghpthhtohepmhhitghhrghlrdhorhiivghlsegrmhgurdgtohhm
    pdhrtghpthhtohepjhhulhhivghnseigvghnrdhorhhgpdhrtghpthhtohepshhsthgrsg
    gvlhhlihhniheskhgvrhhnvghlrdhorhhgpdhrtghpthhtoheprghnughrvgifrdgtohho
    phgvrhefsegtihhtrhhigidrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Fri, 6 Jun 2025 15:54:25 +0000
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Jan Beulich 
Cc: xen-devel@lists.xenproject.org,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Stefano Stabellini ,
	Andrew Cooper 
Subject: Re: [PATCH v1 1/5] console: add relocation hook
Message-ID: 
References: 
 <4f1889dc03ec4aa2cc0cd2bd14523a2c6f670bdb.1748182535.git-series.marmarek@invisiblethingslab.com>
 <0b17da9c-57db-4a8b-90af-e53e45cb1243@citrix.com>
 
 <66cfdee6-5dc2-4139-8550-ef441fa7a7a0@suse.com>
 
 
 
 <83c22da9-62c5-4fb2-bc2d-f34ad5956d3e@suse.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="nmE0Uw0NEhG79Tq6"
Content-Disposition: inline
In-Reply-To: <83c22da9-62c5-4fb2-bc2d-f34ad5956d3e@suse.com>


--nmE0Uw0NEhG79Tq6
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Fri, 6 Jun 2025 15:54:25 +0000
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Jan Beulich 
Cc: xen-devel@lists.xenproject.org,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Stefano Stabellini ,
	Andrew Cooper 
Subject: Re: [PATCH v1 1/5] console: add relocation hook

On Fri, Jun 06, 2025 at 08:26:33AM +0200, Jan Beulich wrote:
> On 05.06.2025 18:08, Marek Marczykowski-G=C3=B3recki wrote:
> > On Thu, Jun 05, 2025 at 06:05:02PM +0200, Jan Beulich wrote:
> >> On 05.06.2025 16:51, Marek Marczykowski-G=C3=B3recki wrote:
> >>> On Thu, Jun 05, 2025 at 04:42:53PM +0200, Jan Beulich wrote:
> >>>> Why is it that this ring is dependent upon Xen's position? If the ri=
ng was
> >>>> dynamically allocated, it wouldn't change position when Xen is moved.
> >>>
> >>> The console is setup quite early, I don't think I can allocate memory=
 at
> >>> this stage, no?
> >>
> >> But you allocate before Xen is moved, I suppose.
> >=20
> > Well, I have those buffers in BSS exactly to avoid the need to allocate
> > them (or rather: have bootloader allocate them for me).
>=20
> Yet them remaining in .bss is now getting in the way. Imo moving them to
> .init.* and adding proper allocation is going to be easier than the hook-
> ary you are proposing.

So, when would you propose to allocate them? Wouldn't that be yet
another hook?

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

--nmE0Uw0NEhG79Tq6
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmhDDzEACgkQ24/THMrX
1yy0Rgf+I5DQTFUK5vLWZ/ahlpVUczjl7mp/aKVc22gHuBTNUd4IWOL8g/B7325o
PhECA9Dpg0FcrYYElhNU76asCmUbru0C+WnopeG7bhabZkw1NY55M90uf0DdhK1o
91U5kE2M9xkGpnq0E5erUczeDI5jxqr7ePaFpQIqAv9UymHlsMR4nBzwwwyOO78C
N1XL18wjg9m6r8DsUfOuUuKjyr+RoA1WI4h6TyZIJ+O/zIUb+Cfbs5/a3FZUvB8W
1P8Ms8v3ITTOzVzYfF67RUJO0fL7zPx8RWMmPKCs0mVAJtnhZmKtKQnkyd23sv/X
PSnIKlRgHslrgZv5GPAJdgVSAIbfgw==
=GT85
-----END PGP SIGNATURE-----

--nmE0Uw0NEhG79Tq6--


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 16:49:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 16:49:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008671.1387902 (Exim 4.92)
	(envelope-from )
	id 1uNaFp-0005E8-Gs; Fri, 06 Jun 2025 16:49:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008671.1387902; Fri, 06 Jun 2025 16:49: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 1uNaFp-0005E1-Dq; Fri, 06 Jun 2025 16:49:17 +0000
Received: by outflank-mailman (input) for mailman id 1008671;
 Fri, 06 Jun 2025 16:49: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 1uNaFo-00050H-RO
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 16:49:16 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20623.outbound.protection.outlook.com
 [2a01:111:f403:2417::623])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2e9aa7b4-42f6-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 18:49:16 +0200 (CEST)
Received: from CH0PR04CA0056.namprd04.prod.outlook.com (2603:10b6:610:77::31)
 by DS7PR12MB9550.namprd12.prod.outlook.com (2603:10b6:8:24e::16) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Fri, 6 Jun
 2025 16:49:11 +0000
Received: from CH1PEPF0000AD7C.namprd04.prod.outlook.com
 (2603:10b6:610:77:cafe::4c) by CH0PR04CA0056.outlook.office365.com
 (2603:10b6:610:77::31) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.19 via Frontend Transport; Fri,
 6 Jun 2025 16:49:11 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH1PEPF0000AD7C.mail.protection.outlook.com (10.167.244.84) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Fri, 6 Jun 2025 16:49:11 +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, 6 Jun
 2025 11:49:10 -0500
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; Fri, 6 Jun 2025 11:49:09 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2e9aa7b4-42f6-11f0-a301-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=VglBKkGaI9rDsaZDcVZL2kGtzvOIFRQgquXkHA7ZUm9PI0FdVNL9qmEodRnGnsTXdN1CsRZHzDISTLWWrXEIwG9pmAYRy/Wdepf1baDgpStfyGsmlOWFXvtv4MG8OwYB9xzSklLPVuoTCOkuTdK0/w9oR73yzIJ+5eXi9s1LvDJfwelA4UQcv+geab+sZKgKOBNjt8jWgxKh2rkxP2E9eZ7yGZ3nzVLvKg4lly7EXFY77ff+AwSL/v2zKiRpj8eLkNk6rAm4q6DAg0YJeOVuAUnV2HY+fKyci2L8pD2WL1n95eg2GbRn3birSqMC1kN33MYMb4UxDG6ZAsS9pQB++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=/vqF429rt6MRA2T2jT5QlPFZoAnquuWxtF2jQiOBgAU=;
 b=OHS4+VHMQXpPdfi73ceQ0x2YmW/EPgF7QlyY/hvw5Y4a47PtzN/JG5gVBUlX5ebuRtteQJuR8w1xlp1UC1kkGq0HibhRvleTk31G5PYJwjqacT5YKieUW5CE/zDkp4t2HilM7xRXY+IqrjvissIJpjHs6YkaXUVwr57YpMZrfw/DFlJYl3ukzxL0Tik0Rvr3z21O9504xgtIymJRWxE8kMm3U5yPw7hEFMJ9FEQoKY15pSI8S0I9jhBl0eLezXiNDoXoEgl9IDtXwUctXP294Q/OyKkgLWslm9pwjhniytp75XUNXmDnJIsZ44dogSrIB+aQ8vfJx70hy1ysk0bxVg==
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=/vqF429rt6MRA2T2jT5QlPFZoAnquuWxtF2jQiOBgAU=;
 b=IgX5ZmmX7JV/qz7vpcY4mKozwNFBt9sa2sqU5nUX4y4tmDCjowOWNZdla4CzQ3snuDDLMlp1mLSv0sSabxFpk8/GPEDEmCnuBp/YjIDvFgH4OKqW007hC/rgpEz/vce2fmEcW1lm1WlmpSXglp9t5IZxqGAhOI11zJC4dZp8UEE=
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 v2 1/3] arm/mpu: Introduce MPU memory region map structure
Date: Fri, 6 Jun 2025 17:48:52 +0100
Message-ID: <20250606164854.1551148-2-ayan.kumar.halder@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20250606164854.1551148-1-ayan.kumar.halder@amd.com>
References: <20250606164854.1551148-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: CH1PEPF0000AD7C:EE_|DS7PR12MB9550:EE_
X-MS-Office365-Filtering-Correlation-Id: 269d8a5c-974d-4ca6-b7af-08dda51a100c
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?ZHiYc5GdmEdplGeHlnWSXRVQotcbjhivhF6s363c6PsASqrOJA3frsdNjmUY?=
 =?us-ascii?Q?Htv3qhCECOHuSHph58l4N73exK9yOanwEO0r2V7zK0AOqWwCklvvjilwIpm7?=
 =?us-ascii?Q?9JADs0uvMLpURWe75XJVKz2ZzlRvF4tdlMmJnVH6rtQ9In9YyhkZgzUliLva?=
 =?us-ascii?Q?fNIgK0/gThwSTsYK99+6t0KMjRC95QmQ81qjOE4+25fxvvcjgM/uoAIu8dmu?=
 =?us-ascii?Q?1LcTrWZwLULAj8OGC9YudeXrZgewZNYhWuNdHtFevd+jRP9rJPGU8KxO9JUf?=
 =?us-ascii?Q?mkIsGEkDwxpmU6ogsLidm36SzrgleQxmFRTX3F4qXUBio1+yEHJw6bWV5q+0?=
 =?us-ascii?Q?vVr2lStZo0GW9EPQxzFzClQUco95dP01uO/O5SdM6oVIjYLMFGBX6F9jmHtv?=
 =?us-ascii?Q?XmIeFXdRd6Hbkjx8VVIBTFMVPJyT7uvKOKi2sa9WgH0P+UuX4VG2ri7afr9C?=
 =?us-ascii?Q?LZ4TvqUzqJjCyfwrJd6C86phMpjt4T++NNsEWYfcHi9r74XVI/Yk2ctxBkLn?=
 =?us-ascii?Q?gNyCLNHhGOE72kOHHqWXxfgi/ToG9DiMwM0KqvV9AALMWnXRewNqcloU2zgl?=
 =?us-ascii?Q?+hMs3py0D/cqQunSQt39GD2yR7WxgGGh7zzsLQbUgVrFW1nUWPy4mcmpXaFK?=
 =?us-ascii?Q?/BXIDC/fHeaok4PyyJwxHheeRQCzjPh83deQBNihzdSkm2jag5IeIaNBo67X?=
 =?us-ascii?Q?Ps/DnEKnEnUM4bkQHJcIKt8aBM4R8fZR4APEoSEETTutfsK2S1W/I9K//fr9?=
 =?us-ascii?Q?NDg6vmz5pOQ/fIp+uNPZ6pi3DrnmqCoZ4PnuvskQNIb3kzbNjsXgz1I+v6mR?=
 =?us-ascii?Q?7cb8UKHVv2eBH/86nU2l0XS2OUzwSwPe6p10m1hui5SaLkTKpfXSogrcyIeC?=
 =?us-ascii?Q?/pyhpDfd4ryGBuX1mAAm5PVrIaEdkHEOyYY5be6sdpm+YdaTCudyMTivuQFZ?=
 =?us-ascii?Q?HNszhGhDiY3q5dSuXAUTVNq0ZjTxXus56bGP0ErMgOcXXJ93Oo4WJa82vqe8?=
 =?us-ascii?Q?mCMGdQP7FF/D1qos8V2s8JpiXUw6HXcLXhhXz6VW699xp+qjtSVR3vdVTWYg?=
 =?us-ascii?Q?9Rru2Z5ISIgUOEd4bORNNMJQLC90IX+BrrAjzF3nQIgabOVY9LPDH3x+ipsy?=
 =?us-ascii?Q?S0ZbwXt0IcVgsCaSC3piUP3KP+GEioy9KQwnljPowii06hGKI8Tdw3ItCAMo?=
 =?us-ascii?Q?amiwVtmo598o2jFOWHNJAEloe3S0ARIW3oOxyX0TUq48v5zQYgMs9j2CElRf?=
 =?us-ascii?Q?zbX/orkmS7mS7uLZdof1mqsDPLcsN2yIX/fv4/cAs5BLBRIZiKo0ytP+IFqz?=
 =?us-ascii?Q?AgEQBITe5LEbZvp7rgkqMammi63rh4385byH3pgIMcSj9NP41V5zbVm0e8+d?=
 =?us-ascii?Q?icNmyxNoIvlG247pAWvXjroVdH7bek9PTvxxExXB7J4e0f/lSRJ4Ehq0mEfZ?=
 =?us-ascii?Q?EohvBYkSs8iirMEWT6E6Agtxqw5lI7N5rQTVKxWT3nA7XJd0LacufNdxAEM+?=
 =?us-ascii?Q?X2G2DevyxBGNK8jdYIziH4ADTJG6Y++TT31/?=
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: 06 Jun 2025 16:49:11.2942
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 269d8a5c-974d-4ca6-b7af-08dda51a100c
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:
	CH1PEPF0000AD7C.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB9550

Introduce pr_t typedef which is a structure having the prbar and prlar members,
each being structured as the registers of the AArch32 Armv8-R architecture.

Also, define MPU_REGION_RES0 to 0 as there are no reserved 0 bits beyond the
BASE or LIMIT bitfields in prbar or prlar respectively.

Signed-off-by: Ayan Kumar Halder 
---
Changes from v1 :-

1. Preserve pr_t typedef in arch specific files.

2. Fix typo.

 xen/arch/arm/include/asm/arm32/mpu.h | 34 ++++++++++++++++++++++++++--
 xen/arch/arm/mpu/mm.c                |  2 ++
 2 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/include/asm/arm32/mpu.h b/xen/arch/arm/include/asm/arm32/mpu.h
index f0d4d4055c..fe139a2abe 100644
--- a/xen/arch/arm/include/asm/arm32/mpu.h
+++ b/xen/arch/arm/include/asm/arm32/mpu.h
@@ -5,10 +5,40 @@
 
 #ifndef __ASSEMBLY__
 
+/*
+ * Unlike arm64, there are no reserved 0 bits beyond base and limit bitfield in
+ * prbar and prlar registers respectively.
+ */
+#define MPU_REGION_RES0       0x0
+
+/* Hypervisor Protection Region Base Address Register */
+typedef union {
+    struct {
+        unsigned int xn:1;       /* Execute-Never */
+        unsigned int ap_0:1;     /* Access Permission AP[0] */
+        unsigned long ro:1;      /* Access Permission AP[1] */
+        unsigned int sh:2;       /* Shareability */
+        unsigned int res0:1;
+        unsigned int base:26;    /* Base Address */
+    } reg;
+    uint32_t bits;
+} prbar_t;
+
+/* Hypervisor Protection Region Limit Address Register */
+typedef union {
+    struct {
+        unsigned int en:1;     /* Region enable */
+        unsigned int ai:3;     /* Memory Attribute Index */
+        unsigned int res0:2;
+        unsigned int limit:26; /* Limit Address */
+    } reg;
+    uint32_t bits;
+} prlar_t;
+
 /* MPU Protection Region */
 typedef struct {
-    uint32_t prbar;
-    uint32_t prlar;
+    prbar_t prbar;
+    prlar_t prlar;
 } pr_t;
 
 #endif /* __ASSEMBLY__ */
diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
index 86fbe105af..2fb6b822c6 100644
--- a/xen/arch/arm/mpu/mm.c
+++ b/xen/arch/arm/mpu/mm.c
@@ -167,7 +167,9 @@ pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags)
     /* Build up value for PRBAR_EL2. */
     prbar = (prbar_t) {
         .reg = {
+#ifdef CONFIG_ARM64
             .xn_0 = 0,
+#endif
             .xn = PAGE_XN_MASK(flags),
             .ap_0 = 0,
             .ro = PAGE_RO_MASK(flags)
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Fri Jun 06 16:49:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 16:49:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008670.1387893 (Exim 4.92)
	(envelope-from )
	id 1uNaFm-00050U-BV; Fri, 06 Jun 2025 16:49:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008670.1387893; Fri, 06 Jun 2025 16: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 1uNaFm-00050N-6t; Fri, 06 Jun 2025 16:49:14 +0000
Received: by outflank-mailman (input) for mailman id 1008670;
 Fri, 06 Jun 2025 16:49: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 1uNaFk-00050H-NJ
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 16:49:12 +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 2a9805ae-42f6-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 18:49:10 +0200 (CEST)
Received: from CH2PR20CA0011.namprd20.prod.outlook.com (2603:10b6:610:58::21)
 by MW6PR12MB8868.namprd12.prod.outlook.com (2603:10b6:303:242::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Fri, 6 Jun
 2025 16:49:06 +0000
Received: from CH2PEPF00000149.namprd02.prod.outlook.com
 (2603:10b6:610:58:cafe::5b) by CH2PR20CA0011.outlook.office365.com
 (2603:10b6:610:58::21) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.31 via Frontend Transport; Fri,
 6 Jun 2025 16:49:05 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CH2PEPF00000149.mail.protection.outlook.com (10.167.244.106) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Fri, 6 Jun 2025 16:49: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; Fri, 6 Jun
 2025 11:49:05 -0500
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, 6 Jun
 2025 11:49:04 -0500
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; Fri, 6 Jun 2025 11:49:03 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2a9805ae-42f6-11f0-a301-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=alH14zjTbnbFDT0XXWzjQMtHET7kFvNMlVIWTLiqgrXSZWmG7KcxiFlIyZmlananl35dz5ivHctsJ0iHFr4BcA5wDMTXHS+5HSl9TO5oa/MC7rg2deShdHAv+PbqBHyVbCmQauYuIJcK3rslk++hAV3v2tZn/ID6MwuIHj8DVgez/ilG9DRamqKqUi8ivVk01WoS8gRnfkI60JaXPg43DCN/uY62sgVTi9L4CuqlBSr+/ApyEsefg2BtuVWgrsAEVUknRHL1Elmi27hKElkp06gaIjLEiEOdt1C/pR7KUYI0yVz3/e5rWBG1RfIkeyALHIgkvyWo9/teI6tipr0Qdg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=b4q+6YmroSAhn3e6pTGRGz5dLRFnLkReiw0P2RtEIco=;
 b=x06X2dX/Q9GqyKxa5q56hZkkdrfrU3tGERE7y5GuSTE5fMGq+GkARI/BMFfXxYtXpnIPCDYFZgOHdOhN6G1tUnMoxv4Vxn7tf2imkncE/x7xC6LMZw64AaXM1ZjYYIUGXVKy7rO4yrB0h4uwdZT27VUtsd4TJ0wkN81dxi8owoGW8Is4FhDmbsKgk4fabM0UZ1Rhk2HbO4BXF5g8pKa5ndTlvSBgwwMQ+2jnJVLJgF3QKmSJ2k0wry7dCXW0/WvKjteMVZWGv9u2vj099vzUDqn5QaEKvjgWQSZPSPdMAsrglD/Ckglja8i0FFu7fAZYwclPZ8UdAk85zggbv1EiUg==
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=b4q+6YmroSAhn3e6pTGRGz5dLRFnLkReiw0P2RtEIco=;
 b=dbxAvDwav4kZH8ykRJSu9etKczZO8hcCz46P4urRbtt9SVphHMf4vIFveabXZAI/HkdLstkCEBKklXcUq5/AHTADrqrx/FRdZd9qb8nHiWfcn6NDcJae38y8kU/pIYP4Wihz/6rP+kp8wo2Ix8rtTUo/tVRMznL+vfssrXzA1ME=
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: Ayan Kumar Halder , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" 
Subject: [PATCH v2 0/3] Enable R52 support for the first chunk of MPU support
Date: Fri, 6 Jun 2025 17:48:51 +0100
Message-ID: <20250606164854.1551148-1-ayan.kumar.halder@amd.com>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PEPF00000149:EE_|MW6PR12MB8868:EE_
X-MS-Office365-Filtering-Correlation-Id: c130fd62-d0ba-49c8-7dd2-08dda51a0c86
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?wI0SCccucf6nI9ZVyvh5+675bai/KScPbNMBaEnvlqkZMotMKuw9PNVwIdZD?=
 =?us-ascii?Q?OiYbWoSVoXQl0L0LIoESFNLlHpmSGZN+mWg7bWjilLsX/D8eGoQtzhkjbwSs?=
 =?us-ascii?Q?Rrnf2oLc6ZkZYb0ItZGZK9RMp5BkNEUqAXx5YB29KlT0o5933v6W5yHOhXqj?=
 =?us-ascii?Q?6VGo1H83NiAm/+gWtgqQIoe9u/I0RTeV0js/uWmdmpQ5KhHLpi8J1V6HzMTm?=
 =?us-ascii?Q?NlhkPCtxzSygzRLbe5h1Fgo2LLn3RoPR6snRAHRqkNM2LZzs71Bc37zSl41G?=
 =?us-ascii?Q?19HYupT2oQsPXASviPJxP4xTDxF6BhWgxWGkSpGCiTKrBFTF4KZ4mLDLY3Bg?=
 =?us-ascii?Q?DCXwpVcGGp4l4QbuJLHClci9sSYjNa5mhrxc1PAOGwE1D2tNTcS/+cAi7+zY?=
 =?us-ascii?Q?g6WpaaQDR4TYIFXluSUq9N0oxAZ9HiOickj6n0y7IcXlGZbJ6TfDkipIVrBB?=
 =?us-ascii?Q?Gpg6T/LlK8/qVnT4jPSyXa1mi6LWyK+g/iQt9cWri8tgNg062vHKoy/OO5Qx?=
 =?us-ascii?Q?YdIetMvn6V6WyearooNLJcF1bUs82IPoZC6yhM765rHeRa1G3lHYFSSUraaE?=
 =?us-ascii?Q?6sKar9twFlJm9swQXro9J6IbaotqDVn+pMxub4/oo/E2S0PLPlDcB4z7HdHu?=
 =?us-ascii?Q?3yUCeV71EIpW49IdB5CmLJnKk44uvucoXtP+3tgg0EKvbUr2YxgCv4Y0Fs5A?=
 =?us-ascii?Q?M4Y4DOYzmdF4WwAcEYLRhupCztGx0Oaxx32PA2Rdnd5u8kpdZGjrE2lKStqu?=
 =?us-ascii?Q?aQfOWrcjEoH2b14Y01MB61xwP12Mry3cboo7VvNJ7WvU8m6tFXgEBJsrc/jB?=
 =?us-ascii?Q?tnj13X9m8i04NACwTd6Is2mKyd13cm2X7zWLtD01sTy1kUFSfxtzgM1noHgN?=
 =?us-ascii?Q?fEZhdaM6V0K7UomrY5AixabuW3hwaCHSrMJp3odFDKqVNGPWBYAj07ioNbXX?=
 =?us-ascii?Q?DrzsnUY9XJmr7PzAPSdUSolXh8a4xLkJag5FAXa2i90xehPMo8aFdopKVUwZ?=
 =?us-ascii?Q?3BCA8asea7PVSzMW0ir5g0SsS8HNLzhJQxRYsNXkIdVjTZDwYWVxTNewpeMS?=
 =?us-ascii?Q?854aD6eK7dnuwM4KGoC87KW+ygbP41OdISme2MClGvLp0B2GCcOdyWx/VU6L?=
 =?us-ascii?Q?Pk81jnwlctkQRQd/aGX4irwYMSMl4DNgrkT4oRG5JPizC1aG52or6lFR5YO6?=
 =?us-ascii?Q?B3FVblmWAjRr1vs5r+Z75FG5hNXNEo8Y/Iw7tOxNEj6722eZy0+YuGqCDgqH?=
 =?us-ascii?Q?Qiis2BGLutNio/P6KprAtrzTOi5tmP2qjq4uByc0KFG2jwgChNjTy+NCZOYt?=
 =?us-ascii?Q?cL4tpB9tCBtYZvVGbFaDYCX4+fi8pso5p1oL8fR2ztwsA0UHxUGJ0aWrFS/d?=
 =?us-ascii?Q?EkPy84javQ9kHJ58bkMezvQV56eMHSAGZjdTSL9Vr1GRyd/Xly+vO3MwPS6m?=
 =?us-ascii?Q?EdX5cul50eiycqLgmEwNPGbFNMNI9nusiaN1I9MdFQ4EaLQunZzym9vtuWUF?=
 =?us-ascii?Q?DIiClOYvHxDKrXkXySLyW27fHZ8a79EGfhtN?=
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: 06 Jun 2025 16:49:05.3779
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c130fd62-d0ba-49c8-7dd2-08dda51a0c86
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:
	CH2PEPF00000149.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW6PR12MB8868

Hi all,

This patch serie enables R52 support based on Luca's series.
"[PATCH v6 0/6] First chunk for Arm R82 and MPU support".

Ayan Kumar Halder (3):
  arm/mpu: Introduce MPU memory region map structure
  arm/mpu: Provide and populate MPU C data structures
  arm/mpu: Provide access to the MPU region from the C code

 xen/arch/arm/arm32/Makefile              |  1 +
 xen/arch/arm/arm32/asm-offsets.c         |  6 ++
 xen/arch/arm/arm32/cache.S               | 41 ++++++++++++++
 xen/arch/arm/arm32/mpu/head.S            | 25 ++++++++
 xen/arch/arm/include/asm/arm32/mpu.h     | 34 ++++++++++-
 xen/arch/arm/include/asm/mpu.h           |  2 -
 xen/arch/arm/include/asm/mpu/cpregs.h    | 72 +++++++++++++++++++++++-
 xen/arch/arm/include/asm/mpu/regions.inc |  2 +-
 xen/arch/arm/mpu/mm.c                    | 51 +++++++++++++++--
 9 files changed, 224 insertions(+), 10 deletions(-)
 create mode 100644 xen/arch/arm/arm32/cache.S

-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Fri Jun 06 16:49:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 16:49:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008673.1387912 (Exim 4.92)
	(envelope-from )
	id 1uNaFx-0005YV-PV; Fri, 06 Jun 2025 16:49:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008673.1387912; Fri, 06 Jun 2025 16:49: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 1uNaFx-0005YH-MK; Fri, 06 Jun 2025 16:49:25 +0000
Received: by outflank-mailman (input) for mailman id 1008673;
 Fri, 06 Jun 2025 16:49: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 1uNaFw-00050H-3A
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 16:49:24 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on20620.outbound.protection.outlook.com
 [2a01:111:f403:2407::620])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3274324c-42f6-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 18:49:23 +0200 (CEST)
Received: from CH2PR18CA0030.namprd18.prod.outlook.com (2603:10b6:610:4f::40)
 by PH0PR12MB7960.namprd12.prod.outlook.com (2603:10b6:510:287::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.29; Fri, 6 Jun
 2025 16:49:18 +0000
Received: from CH1PEPF0000AD83.namprd04.prod.outlook.com
 (2603:10b6:610:4f:cafe::c9) by CH2PR18CA0030.outlook.office365.com
 (2603:10b6:610:4f::40) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.27 via Frontend Transport; Fri,
 6 Jun 2025 16:49:16 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH1PEPF0000AD83.mail.protection.outlook.com (10.167.244.85) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Fri, 6 Jun 2025 16:49:16 +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, 6 Jun
 2025 11:49:15 -0500
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, 6 Jun
 2025 11:49:15 -0500
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; Fri, 6 Jun 2025 11:49:14 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3274324c-42f6-11f0-a301-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=V+CcROi8Wd/y7RvPAvwS127I/MWFJli9hlWeLUWJPfksc3EtvZqDGe/cOESGdY0wTMFbaQ1cPpyNhHUsQC0GbDouv4CyOLS12MGPRm4Qmod/gc+jcZ/7gWUm5cH16l2gt7sKvh8zexR2NxwZs1cH30M4M4KO3x18VSLppVm1sWxIx2NOyHzWEG75n8zF6RqSlYKLlpGRszuEgj3nTySdeR2NkTkDYiAE7LHIfJdWG+X9XDNFnHCbpBnnANdNrlTiJKyukG6Y6sJux0p4cF/1hyUdamtY8ftSWp64tYE6EBB+eGdQhsr4H/xWm6VLwRP2BB0LUPLh0SjEp3UhYsCCKg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=3Z65srZ6IJX0cHUKpTkJ8aRG8R6BLyaHE4ywRt3gjSM=;
 b=t6QHmxa+5npaVHyBJKUiG5H2PveqZghxTMv/AMtz1S6McgHZg7DAeQAzNhSDYXEOf7ZPg/r01he/2XI0Jbac4bqAaaLsWTP5VOYD5mj4nHLgZI6E4wfSGBthzQTgJwzOXFUHOMZYPddkbEXbd+3E5S3DSZOZzcMpGiVuN0Ky0LIuiZDjnYNSasXhR/MM1XF+bfqq9aklsJ5NCv3Qjc+ZPwCwEdogRtgOo5ls8Hb9OdbcXGKdTSNOV/mMbeB71VUHr/i6DzemJebyoRNd6dp5A3SzW0wyyZUo3/QIPQs/NimKaZmgh2x8xoDpcQSM9SmxnQPeyvpWSDwx4FVbFwOvWg==
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=3Z65srZ6IJX0cHUKpTkJ8aRG8R6BLyaHE4ywRt3gjSM=;
 b=0KLphs4pOgZkkikhJPwi9se2mvg/i4KzQKay8QbO4CVzFtwzY7bi4dbcb1iBbB0d9kmkE3j5jtMfBgYds2Lgnn3XXYUAYsXpcuUwkmg8/G9D4leXg9EUUdB7Ps3uavWdhlWd27Bd3zJVs1w8lRRGT0chKPS8QrfvxiQhrOCLTFM=
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 v2 2/3] arm/mpu: Provide and populate MPU C data structures
Date: Fri, 6 Jun 2025 17:48:53 +0100
Message-ID: <20250606164854.1551148-3-ayan.kumar.halder@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20250606164854.1551148-1-ayan.kumar.halder@amd.com>
References: <20250606164854.1551148-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: CH1PEPF0000AD83:EE_|PH0PR12MB7960:EE_
X-MS-Office365-Filtering-Correlation-Id: 9315d8c5-3ea9-4d47-fc84-08dda51a1326
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?JP44zMI/Z5A5U58h4pXO0a5iyojJzkhf65PWHbJ0I7EXCvgJAkOq09QXaF5p?=
 =?us-ascii?Q?tCf7f8JBGQclY9mKV/T7x2KEARToyo/FIoFa+N8XNbKQU/mwGOXofJI+KGLF?=
 =?us-ascii?Q?DNFD4uhSBt1hc/uc3GEyX1OuJkyTfvB4AiCyR33yTg0rezUmp7qtnl+JRHvl?=
 =?us-ascii?Q?aKV1E0MNO56y7+mON1mxPHw/51QQuXpq0+TFe3H19xlfWAJmJ/njjLV8bfh/?=
 =?us-ascii?Q?PKzWkEJ32HiZhUAOgnlHYtRGyMPpUboxra3CfLDKmsebmxL/zAdug6YSdhQm?=
 =?us-ascii?Q?PCPjuXHzZ3geN5SysBdjDWlYKIxRHd3S8qiuGUwI59c0c4e84RjS1+tyc2V7?=
 =?us-ascii?Q?/slvlggTkzAR/xXrnkHrfu+HfhE3FSjhcoz8MG1BpwZH7mmvwfAGC7CxLB7O?=
 =?us-ascii?Q?ND43jAPDJkk6YASGxk2v+4tX2BybibM5oRHMeAKo3QPspAQDgBNctDIaHs3E?=
 =?us-ascii?Q?Y6ibAiDcbDYL/unuft/E6CYi21oGhfVRHJvpyOp1x6PXN29yCOeXA9lQoAfo?=
 =?us-ascii?Q?EIkevbEBi896OJC7woaHm1i/tmRAcYaVdEItKbVXMt3BQG20PGrtUjFUTJc/?=
 =?us-ascii?Q?nmvFDYUtmoRsuL+/68E5Uus7xMdcpH50JqMe870BCzXE9rfk59K0IoY0udxO?=
 =?us-ascii?Q?Ddu8phO0DRruo9j0ygFnWYRFPYkSBRoA58EvVhQDLmuztiYkTvARFfAyKFuw?=
 =?us-ascii?Q?ozKQQmTM8S/OfatHWlPQ74GOfe2Lr1HFCACxr6pYZKgay9USXqOopCb3cCz3?=
 =?us-ascii?Q?WBVp3NyNpMbRpKQETNTAVtrhE9QrXJfQr3Fz7/1rqlGYSYgCPYf4uQlfFz85?=
 =?us-ascii?Q?f5h0W82JNFoaUFS7+HxcbAoRcLd/KEM7D//4eltVQv53hsJ3guIrOZrmpy3V?=
 =?us-ascii?Q?2RVuifrAgn4KONxmBdME45/HVGR6SEY3ze3FJ05VuyIzudMA08FsL4k76jrG?=
 =?us-ascii?Q?YKxcI7oV+4Ci3SYmd2UiEFMtgcNa4Qbx+okGZFhCrukyW2q4295HZroTjX5y?=
 =?us-ascii?Q?c7KzeD1gSpq9KOHFyuWfvyTlH1YxaQcdTeUewuqHHu0PjHehQR0g7Oys7vPo?=
 =?us-ascii?Q?m3K9+7GhjoLkFBm9v136HnzZzdHCAG4688QMfCttB09T4z70nlwOjUqwHG9a?=
 =?us-ascii?Q?7D5zGwzMWdINl6ewlhag7myKCFmD5SlvGQevn6svNOnyZupmzqCHmqPwlKgj?=
 =?us-ascii?Q?FBy/clcUfR9LrC/JCVyqYCmNso0ccX2Rwv8RQvavEcsL8bZao1hahtAP9+qi?=
 =?us-ascii?Q?ttzMAM1Bwq/0R/HZhVvg8q4veAHY0aRY9glXzE+YyrSXjJYjmfHYSPvobqjX?=
 =?us-ascii?Q?omcxBWQqtTg3Qht6vbBVeD8kyxNWV0WxkBriIaW6E7pCJGTbuM9rEdoN+Leo?=
 =?us-ascii?Q?3AQhbdZIn2OTcBlRFTldLzgJOiJN+O7WZ2RO9C/EWOUcFL73WGToDLQAjljv?=
 =?us-ascii?Q?bd2zpY7r2cuOBYmhARfSHEy2hzQx7PLRf0tWDFiv+pkhSCe9CQjUXD6+NQpF?=
 =?us-ascii?Q?zYTOQF9npdNSkAbYt+kllKUCJt8r2Ee15gUv?=
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: 06 Jun 2025 16:49:16.4996
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9315d8c5-3ea9-4d47-fc84-08dda51a1326
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:
	CH1PEPF0000AD83.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB7960

Modify Arm32 assembly boot code to reset any unused MPU region, initialise
'max_mpu_regions' with the number of supported MPU regions and set/clear the
bitmap 'xen_mpumap_mask' used to track the enabled regions.

Use the macro definition for "dcache_line_size" from linux.

Signed-off-by: Ayan Kumar Halder 
---
Changes from v1 :-

1. Introduce cache.S to hold arm32 cache initialization instructions.

2. Use dcache_line_size macro definition from linux.

3. Use mov_w instead of ldr.

4. Use a single stm instruction for 'store_pair' macro definition.

 xen/arch/arm/arm32/Makefile              |  1 +
 xen/arch/arm/arm32/asm-offsets.c         |  6 ++++
 xen/arch/arm/arm32/cache.S               | 41 ++++++++++++++++++++++++
 xen/arch/arm/arm32/mpu/head.S            | 25 +++++++++++++++
 xen/arch/arm/include/asm/mpu/regions.inc |  2 +-
 5 files changed, 74 insertions(+), 1 deletion(-)
 create mode 100644 xen/arch/arm/arm32/cache.S

diff --git a/xen/arch/arm/arm32/Makefile b/xen/arch/arm/arm32/Makefile
index 537969d753..531168f58a 100644
--- a/xen/arch/arm/arm32/Makefile
+++ b/xen/arch/arm/arm32/Makefile
@@ -2,6 +2,7 @@ obj-y += lib/
 obj-$(CONFIG_MMU) += mmu/
 obj-$(CONFIG_MPU) += mpu/
 
+obj-y += cache.o
 obj-$(CONFIG_EARLY_PRINTK) += debug.o
 obj-y += domctl.o
 obj-y += domain.o
diff --git a/xen/arch/arm/arm32/asm-offsets.c b/xen/arch/arm/arm32/asm-offsets.c
index 8bbb0f938e..c203ce269d 100644
--- a/xen/arch/arm/arm32/asm-offsets.c
+++ b/xen/arch/arm/arm32/asm-offsets.c
@@ -75,6 +75,12 @@ void __dummy__(void)
 
    OFFSET(INITINFO_stack, struct init_info, stack);
    BLANK();
+
+#ifdef CONFIG_MPU
+   DEFINE(XEN_MPUMAP_MASK_sizeof, sizeof(xen_mpumap_mask));
+   DEFINE(XEN_MPUMAP_sizeof, sizeof(xen_mpumap));
+   BLANK();
+#endif
 }
 
 /*
diff --git a/xen/arch/arm/arm32/cache.S b/xen/arch/arm/arm32/cache.S
new file mode 100644
index 0000000000..00ea390ce4
--- /dev/null
+++ b/xen/arch/arm/arm32/cache.S
@@ -0,0 +1,41 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/* Cache maintenance */
+
+#include 
+
+/* dcache_line_size - get the minimum D-cache line size from the CTR register */
+    .macro  dcache_line_size, reg, tmp
+    mrc p15, 0, \tmp, c0, c0, 1     /* read ctr */
+    lsr \tmp, \tmp, #16
+    and \tmp, \tmp, #0xf            /* cache line size encoding */
+    mov \reg, #4                    /* bytes per word */
+    mov \reg, \reg, lsl \tmp        /* actual cache line size */
+    .endm
+
+/*
+ * __invalidate_dcache_area(addr, size)
+ *
+ * Ensure that the data held in the cache for the buffer is invalidated.
+ *
+ * - addr - start address of the buffer
+ * - size - size of the buffer
+ */
+FUNC(__invalidate_dcache_area)
+    dcache_line_size r2, r3
+    add   r1, r0, r1
+    sub   r3, r2, #1
+    bic   r0, r0, r3
+1:  mcr   CP32(r0, DCIMVAC)     /* invalidate D line / unified line */
+    add   r0, r0, r2
+    cmp   r0, r1
+    blo   1b
+    dsb   sy
+    ret
+END(__invalidate_dcache_area)
+
+/*
+ * Local variables:
+ * mode: ASM
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/arm32/mpu/head.S b/xen/arch/arm/arm32/mpu/head.S
index b2c5245e51..435b140d09 100644
--- a/xen/arch/arm/arm32/mpu/head.S
+++ b/xen/arch/arm/arm32/mpu/head.S
@@ -49,6 +49,10 @@ FUNC(enable_boot_cpu_mm)
     mrc   CP32(r5, MPUIR_EL2)
     and   r5, r5, #NUM_MPU_REGIONS_MASK
 
+    mov_w   r0, max_mpu_regions
+    str   r5, [r0]
+    mcr   CP32(r0, DCIMVAC) /* Invalidate cache for max_mpu_regions addr */
+
     /* x0: region sel */
     mov   r0, #0
     /* Xen text section. */
@@ -83,6 +87,27 @@ FUNC(enable_boot_cpu_mm)
     prepare_xen_region r0, r1, r2, r3, r4, r5, attr_prbar=REGION_DEVICE_PRBAR, attr_prlar=REGION_DEVICE_PRLAR
 #endif
 
+zero_mpu:
+    /* Reset remaining MPU regions */
+    cmp   r0, r5
+    beq   out_zero_mpu
+    mov   r1, #0
+    mov   r2, #1
+    prepare_xen_region r0, r1, r2, r3, r4, r5, attr_prlar=REGION_DISABLED_PRLAR
+    b     zero_mpu
+
+out_zero_mpu:
+    /* Invalidate data cache for MPU data structures */
+    mov r4, lr
+    mov_w r0, xen_mpumap_mask
+    mov r1, #XEN_MPUMAP_MASK_sizeof
+    bl __invalidate_dcache_area
+
+    ldr r0, =xen_mpumap
+    mov r1, #XEN_MPUMAP_sizeof
+    bl __invalidate_dcache_area
+    mov lr, r4
+
     b    enable_mpu
 END(enable_boot_cpu_mm)
 
diff --git a/xen/arch/arm/include/asm/mpu/regions.inc b/xen/arch/arm/include/asm/mpu/regions.inc
index 6b8c233e6c..631b0b2b86 100644
--- a/xen/arch/arm/include/asm/mpu/regions.inc
+++ b/xen/arch/arm/include/asm/mpu/regions.inc
@@ -24,7 +24,7 @@
 #define XEN_MPUMAP_ENTRY_SHIFT  0x3     /* 8 byte structure */
 
 .macro store_pair reg1, reg2, dst
-    .word 0xe7f000f0                    /* unimplemented */
+    stm \dst, {\reg1, \reg2}  /* reg2 should be a higher register than reg1 */
 .endm
 
 #endif
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Fri Jun 06 16:49:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 16:49:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008674.1387917 (Exim 4.92)
	(envelope-from )
	id 1uNaFy-0005bw-3k; Fri, 06 Jun 2025 16:49:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008674.1387917; Fri, 06 Jun 2025 16:49:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNaFx-0005bP-Tu; Fri, 06 Jun 2025 16:49:25 +0000
Received: by outflank-mailman (input) for mailman id 1008674;
 Fri, 06 Jun 2025 16:49: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 1uNaFw-00050H-AL
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 16:49:24 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20608.outbound.protection.outlook.com
 [2a01:111:f403:2417::608])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 323fc10f-42f6-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 18:49:23 +0200 (CEST)
Received: from CH2PR14CA0057.namprd14.prod.outlook.com (2603:10b6:610:56::37)
 by PH7PR12MB6610.namprd12.prod.outlook.com (2603:10b6:510:212::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Fri, 6 Jun
 2025 16:49:20 +0000
Received: from CH2PEPF00000143.namprd02.prod.outlook.com
 (2603:10b6:610:56:cafe::c6) by CH2PR14CA0057.outlook.office365.com
 (2603:10b6:610:56::37) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.19 via Frontend Transport; Fri,
 6 Jun 2025 16:49:20 +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.8792.29 via Frontend Transport; Fri, 6 Jun 2025 16:49:19 +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, 6 Jun
 2025 11:49:19 -0500
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; Fri, 6 Jun 2025 11:49:18 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 323fc10f-42f6-11f0-a301-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=PorDi+nDR9+eJyTvu0mx6wr6nbkmzW64RFl0gU0mSZlDoxZbv6yz8mg29Om8QIafCtVyiR/7ea1iB2XX49ng6SjOtfEJ8OMyiMrZPU3SihnpHusPbhn+S3PJUAKCFsYQzSekt5ZaaC2/92sXt5WOmgREoaeZV2FGBEl0v7TZaXFrD6m2LltjvAY79HqeefCMw2ZAd2AXNqUlZkz1k7gfjfHCVhtTvVUANdH1o1wmE22C82xudh8HQlRgO/jGZ2b3KmVLW+LlWr2TkgBQfAJibLlCCnlEFgc/FhvYdvMfwHJ6JgYt4hiQxhCv7lAp1bcxWz8+HOWPr1ggD5ND1n4aJQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=uQcBHCwDQIPOHrssJVI2Ikm6vmDVkzGZdiJ1UJXecoo=;
 b=iicc764N758FN+yVm1uJgKbRm/0IzZpSqUsvq7BPTgsVtrpfYJjiXHHx+Gh41Y4kLa6gDobWJYAKtcxl6N4Ka9jWeMD6OM35jYdrqi4DRq3AFmNs4UMkZZL/G6JIsYgFvU17e6GOto2geZDkxpLPcVfFLoMF8XN7KcyUfvm029yjGObTUde2dzkB5ZfVuuyRzDdgSMEcs1o2tZh8DEABjMr6fN/KtM0swSqRFvEZKxqkuxiw5Pg0Ch1Y0UVt5uPm17geG7v0Seh8FZqramJQnSQCYVKCglz6rkUZQrAdjRiE/EqW7vMT0mRi/rGg9Tkhebq2XU4IzWF8djnK5DG9og==
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=uQcBHCwDQIPOHrssJVI2Ikm6vmDVkzGZdiJ1UJXecoo=;
 b=fG/b0iO1Zv3CI2xu0yoksV9cxTdm62y4bAeThlNTL1PUEg7SreONlLRzh/RQH/kfKAmsHBtyIBhw1nbnjD1raZYA0vjIWn71NdLhgRDf8j7LNBDM4bJWwsUedi5O3Uxw3v8+HRCowO7P41JNm2oeszNkKKXqw5/AWKG81SQlSZY=
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: Ayan Kumar Halder , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" 
Subject: [PATCH v2 3/3] arm/mpu: Provide access to the MPU region from the C code
Date: Fri, 6 Jun 2025 17:48:54 +0100
Message-ID: <20250606164854.1551148-4-ayan.kumar.halder@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20250606164854.1551148-1-ayan.kumar.halder@amd.com>
References: <20250606164854.1551148-1-ayan.kumar.halder@amd.com>
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: CH2PEPF00000143:EE_|PH7PR12MB6610:EE_
X-MS-Office365-Filtering-Correlation-Id: 9eb33d62-20c4-4337-877d-08dda51a151e
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?ar43zj/9YmJ0qRM/AkxBKPuhkKisdK02xoPsICxyvU9XyoSpfupeBKPi3oEU?=
 =?us-ascii?Q?8Bb7b1focE7oT+J1MRV3LoE5uH7+9MaoONQpqOEA7YFtlOjgy7J6+mIQ5dsI?=
 =?us-ascii?Q?dV6J0X5Pn95e49nZBRwfPD51HI9zIL7jqWzY68auPlHUbgpghv5p5nYKfRYn?=
 =?us-ascii?Q?YUgiR9qOE56PTAnRXEmN/lDjqP/uq9O4mn6fDl5Ne8adxpL43B1e4/T0OxPc?=
 =?us-ascii?Q?SZ8bOfecDX/G3g3Xp+BSkt6hHRqfHcATimPsCGcjWbAavdML4n3sIBrR67W5?=
 =?us-ascii?Q?y6KpyNwzX4E8Rym+Fb9ftyYx94/onBl/Bi1Dlyh/81wySrcdzqT/USRq8azJ?=
 =?us-ascii?Q?gyUv2udrU0D2Hlc5zOwY+qKRkVMKyG+QvzN0n6m7Ykk8PlfOjdd8WvH5eDja?=
 =?us-ascii?Q?twxjlsCPVLTLVRu1zk/4x6nKF9zgE2HdF/maW7Fm2Hwgx509/7V5RXeYZIcy?=
 =?us-ascii?Q?xU3FSJD3clOwKE17NC2EpnLuYYWEMhVV530fjs0R4RU/ns1GVYvvKEm7O+0D?=
 =?us-ascii?Q?GNRUwiYcVC4GVu1ZoCA/Oh+mLlJpN0I0z3d0It1FAwjxgttZIqH8kIb4FiMj?=
 =?us-ascii?Q?BLq3jPCoYJOzKYFqfaEIkZoI4o6WN0Ogis1VAd8hioII8nbNHmtrsEua9qtz?=
 =?us-ascii?Q?eFHrn1BDH98lSHG0ofQMi33sVWQxTBnRS6nvX+VLZxKdr2yxm73SMA+cnFt9?=
 =?us-ascii?Q?FWz65KHJAPfuGeLUGxDmEJtTw65C/g8pEqyJes91W8fcK2QfGnYy2aodLS62?=
 =?us-ascii?Q?QL0+4vJs5dOzoFdHEmp9VImuPnRCXQGGu3NDD4Uza9S4IysoalMkHCOw/Fm2?=
 =?us-ascii?Q?JiT8X6L7BRPnEOlXfx3GTy35VEEw9R56P5rdQR4nuBKTXCcoRGrq5TS6EfQz?=
 =?us-ascii?Q?C34HRPn8ogqSPfAc2mFxISpN7NbElxtD+9/fauUj8nT1xO0fw/pE9XZ/4K+1?=
 =?us-ascii?Q?I61zELyn55R7oH8qiX0YdIiPIhUHWLm1XkJ8gPpQsFaaW+DdBO9A76knUR22?=
 =?us-ascii?Q?rUnTGZgmpQXNYF1QmEbKUsac55G+RHkhGDafaegUhQv0qk/gZ2KD5UgCGAVJ?=
 =?us-ascii?Q?PZJ7s2yTjoZqtu/+/vEfRZsf6GRAy27gUpBEnOCVnUt+J5gwT6TP1R9Cop7k?=
 =?us-ascii?Q?+DMKv2knICigonP4/jtbLEdjpjBBs8bDKibfP1awMxiznuZeUF2OHOLIIWaG?=
 =?us-ascii?Q?AkQa5GkIUyqTsn3DDH51nOKSv/TkCzAQzcEw1zcShzoVwDloQ3W+ve1viNag?=
 =?us-ascii?Q?1NzaL4ipSNaVjHHtQ5p3aJtqbgrAXRMyrjksJZ+4yB718Wu+hUNdhiemJ7XN?=
 =?us-ascii?Q?wJBxWeTif4BFPEoLefWeTcvNXM24ta+LlTzFm0JibFRvl4t0KeRhPWYmlMAs?=
 =?us-ascii?Q?VjnsSGM4RmTEATIRDDqDpFo8GjLZhLnI6aTxnQx9UJmyPqc2sF6PhGZi/V4G?=
 =?us-ascii?Q?S2pb4tbVynPGfPdKCZWza5h/2BQuMmI9HnvCRnNADHG1Zl2i9slnNF41JJ6w?=
 =?us-ascii?Q?2wi9hg5xW5nGl4epfdOeQ+t+6fj1r8JhZAHI?=
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: 06 Jun 2025 16:49:19.7999
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9eb33d62-20c4-4337-877d-08dda51a151e
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: PH7PR12MB6610

Enable the helper functions defined in mpu/mm.c and asm/mpu.h for ARM32.
Define the register definitions for HPRBAR{0..31} and HPRLAR{0..31}.
One can directly access the first 32 MPU regions using the above registers
without the use of PRSELR.

Also fix the register definition for HPRLAR.

Signed-off-by: Ayan Kumar Halder 
---
Change from :-

v1 - 1. Enable write_protection_region() for aarch32.

 xen/arch/arm/include/asm/mpu.h        |  2 -
 xen/arch/arm/include/asm/mpu/cpregs.h | 72 ++++++++++++++++++++++++++-
 xen/arch/arm/mpu/mm.c                 | 49 ++++++++++++++++--
 3 files changed, 116 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/include/asm/mpu.h b/xen/arch/arm/include/asm/mpu.h
index 8f06ddac0f..63560c613b 100644
--- a/xen/arch/arm/include/asm/mpu.h
+++ b/xen/arch/arm/include/asm/mpu.h
@@ -25,7 +25,6 @@
 
 #ifndef __ASSEMBLY__
 
-#ifdef CONFIG_ARM_64
 /*
  * Set base address of MPU protection region.
  *
@@ -85,7 +84,6 @@ static inline bool region_is_valid(const pr_t *pr)
 {
     return pr->prlar.reg.en;
 }
-#endif /* CONFIG_ARM_64 */
 
 #endif /* __ASSEMBLY__ */
 
diff --git a/xen/arch/arm/include/asm/mpu/cpregs.h b/xen/arch/arm/include/asm/mpu/cpregs.h
index d5cd0e04d5..9f3b32acd7 100644
--- a/xen/arch/arm/include/asm/mpu/cpregs.h
+++ b/xen/arch/arm/include/asm/mpu/cpregs.h
@@ -6,16 +6,86 @@
 /* CP15 CR0: MPU Type Register */
 #define HMPUIR          p15,4,c0,c0,4
 
+/* CP15 CR6: Protection Region Enable Register */
+#define HPRENR          p15,4,c6,c1,1
+
 /* CP15 CR6: MPU Protection Region Base/Limit/Select Address Register */
 #define HPRSELR         p15,4,c6,c2,1
 #define HPRBAR          p15,4,c6,c3,0
-#define HPRLAR          p15,4,c6,c8,1
+#define HPRLAR          p15,4,c6,c3,1
+
+/* CP15 CR6: MPU Protection Region Base/Limit Address Register */
+#define HPRBAR0         p15,4,c6,c8,0
+#define HPRLAR0         p15,4,c6,c8,1
+#define HPRBAR1         p15,4,c6,c8,4
+#define HPRLAR1         p15,4,c6,c8,5
+#define HPRBAR2         p15,4,c6,c9,0
+#define HPRLAR2         p15,4,c6,c9,1
+#define HPRBAR3         p15,4,c6,c9,4
+#define HPRLAR3         p15,4,c6,c9,5
+#define HPRBAR4         p15,4,c6,c10,0
+#define HPRLAR4         p15,4,c6,c10,1
+#define HPRBAR5         p15,4,c6,c10,4
+#define HPRLAR5         p15,4,c6,c10,5
+#define HPRBAR6         p15,4,c6,c11,0
+#define HPRLAR6         p15,4,c6,c11,1
+#define HPRBAR7         p15,4,c6,c11,4
+#define HPRLAR7         p15,4,c6,c11,5
+#define HPRBAR8         p15,4,c6,c12,0
+#define HPRLAR8         p15,4,c6,c12,1
+#define HPRBAR9         p15,4,c6,c12,4
+#define HPRLAR9         p15,4,c6,c12,5
+#define HPRBAR10        p15,4,c6,c13,0
+#define HPRLAR10        p15,4,c6,c13,1
+#define HPRBAR11        p15,4,c6,c13,4
+#define HPRLAR11        p15,4,c6,c13,5
+#define HPRBAR12        p15,4,c6,c14,0
+#define HPRLAR12        p15,4,c6,c14,1
+#define HPRBAR13        p15,4,c6,c14,4
+#define HPRLAR13        p15,4,c6,c14,5
+#define HPRBAR14        p15,4,c6,c15,0
+#define HPRLAR14        p15,4,c6,c15,1
+#define HPRBAR15        p15,4,c6,c15,4
+#define HPRLAR15        p15,4,c6,c15,5
+#define HPRBAR16        p15,5,c6,c8,0
+#define HPRLAR16        p15,5,c6,c8,1
+#define HPRBAR17        p15,5,c6,c8,4
+#define HPRLAR17        p15,5,c6,c8,5
+#define HPRBAR18        p15,5,c6,c9,0
+#define HPRLAR18        p15,5,c6,c9,1
+#define HPRBAR19        p15,5,c6,c9,4
+#define HPRLAR19        p15,5,c6,c9,5
+#define HPRBAR20        p15,5,c6,c10,0
+#define HPRLAR20        p15,5,c6,c10,1
+#define HPRBAR21        p15,5,c6,c10,4
+#define HPRLAR21        p15,5,c6,c10,5
+#define HPRBAR22        p15,5,c6,c11,0
+#define HPRLAR22        p15,5,c6,c11,1
+#define HPRBAR23        p15,5,c6,c11,4
+#define HPRLAR23        p15,5,c6,c11,5
+#define HPRBAR24        p15,5,c6,c12,0
+#define HPRLAR24        p15,5,c6,c12,1
+#define HPRBAR25        p15,5,c6,c12,4
+#define HPRLAR25        p15,5,c6,c12,5
+#define HPRBAR26        p15,5,c6,c13,0
+#define HPRLAR26        p15,5,c6,c13,1
+#define HPRBAR27        p15,5,c6,c13,4
+#define HPRLAR27        p15,5,c6,c13,5
+#define HPRBAR28        p15,5,c6,c14,0
+#define HPRLAR28        p15,5,c6,c14,1
+#define HPRBAR29        p15,5,c6,c14,4
+#define HPRLAR29        p15,5,c6,c14,5
+#define HPRBAR30        p15,5,c6,c15,0
+#define HPRLAR30        p15,5,c6,c15,1
+#define HPRBAR31        p15,5,c6,c15,4
+#define HPRLAR31        p15,5,c6,c15,5
 
 /* Aliases of AArch64 names for use in common code */
 #ifdef CONFIG_ARM_32
 /* Alphabetically... */
 #define MPUIR_EL2       HMPUIR
 #define PRBAR_EL2       HPRBAR
+#define PRENR_EL2       HPRENR
 #define PRLAR_EL2       HPRLAR
 #define PRSELR_EL2      HPRSELR
 #endif /* CONFIG_ARM_32 */
diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
index 2fb6b822c6..74e96ca571 100644
--- a/xen/arch/arm/mpu/mm.c
+++ b/xen/arch/arm/mpu/mm.c
@@ -40,7 +40,10 @@ pr_t __cacheline_aligned __section(".data") xen_mpumap[MAX_MPU_REGION_NR];
 #define PRBAR_EL2_(n)   PRBAR##n##_EL2
 #define PRLAR_EL2_(n)   PRLAR##n##_EL2
 
-#endif /* CONFIG_ARM_64 */
+#else  /* CONFIG_ARM_64 */
+#define PRBAR_EL2_(n)   HPRBAR##n
+#define PRLAR_EL2_(n)   HPRLAR##n
+#endif /* !CONFIG_ARM_64 */
 
 #define GENERATE_WRITE_PR_REG_CASE(num, pr)                                 \
     case num:                                                               \
@@ -68,7 +71,6 @@ static void __init __maybe_unused build_assertions(void)
     BUILD_BUG_ON(PAGE_SIZE != SZ_4K);
 }
 
-#ifdef CONFIG_ARM_64
 /*
  * Armv8-R supports direct access and indirect access to the MPU regions through
  * registers:
@@ -85,6 +87,7 @@ static void __init __maybe_unused build_assertions(void)
  */
 static void prepare_selector(uint8_t *sel)
 {
+#ifdef CONFIG_ARM_64
     uint8_t cur_sel = *sel;
 
     /*
@@ -98,7 +101,8 @@ static void prepare_selector(uint8_t *sel)
         WRITE_SYSREG(cur_sel, PRSELR_EL2);
         isb();
     }
-    *sel &= 0xFU;
+    *sel = *sel & 0xFU;
+#endif
 }
 
 void read_protection_region(pr_t *pr_read, uint8_t sel)
@@ -123,6 +127,24 @@ void read_protection_region(pr_t *pr_read, uint8_t sel)
         GENERATE_READ_PR_REG_CASE(13, pr_read);
         GENERATE_READ_PR_REG_CASE(14, pr_read);
         GENERATE_READ_PR_REG_CASE(15, pr_read);
+#ifdef CONFIG_ARM_32
+        GENERATE_READ_PR_REG_CASE(16, pr_read);
+        GENERATE_READ_PR_REG_CASE(17, pr_read);
+        GENERATE_READ_PR_REG_CASE(18, pr_read);
+        GENERATE_READ_PR_REG_CASE(19, pr_read);
+        GENERATE_READ_PR_REG_CASE(20, pr_read);
+        GENERATE_READ_PR_REG_CASE(21, pr_read);
+        GENERATE_READ_PR_REG_CASE(22, pr_read);
+        GENERATE_READ_PR_REG_CASE(23, pr_read);
+        GENERATE_READ_PR_REG_CASE(24, pr_read);
+        GENERATE_READ_PR_REG_CASE(25, pr_read);
+        GENERATE_READ_PR_REG_CASE(26, pr_read);
+        GENERATE_READ_PR_REG_CASE(27, pr_read);
+        GENERATE_READ_PR_REG_CASE(28, pr_read);
+        GENERATE_READ_PR_REG_CASE(29, pr_read);
+        GENERATE_READ_PR_REG_CASE(30, pr_read);
+        GENERATE_READ_PR_REG_CASE(31, pr_read);
+#endif
     default:
         BUG(); /* Can't happen */
         break;
@@ -151,6 +173,24 @@ void write_protection_region(const pr_t *pr_write, uint8_t sel)
         GENERATE_WRITE_PR_REG_CASE(13, pr_write);
         GENERATE_WRITE_PR_REG_CASE(14, pr_write);
         GENERATE_WRITE_PR_REG_CASE(15, pr_write);
+#ifdef CONFIG_ARM_32
+        GENERATE_WRITE_PR_REG_CASE(16, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(17, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(18, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(19, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(20, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(21, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(22, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(23, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(24, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(25, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(26, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(27, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(28, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(29, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(30, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(31, pr_write);
+#endif
     default:
         BUG(); /* Can't happen */
         break;
@@ -208,7 +248,9 @@ pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags)
     /* Build up value for PRLAR_EL2. */
     prlar = (prlar_t) {
         .reg = {
+#ifdef CONFIG_ARM_64
             .ns = 0,        /* Hyp mode is in secure world */
+#endif
             .ai = attr_idx,
             .en = 1,        /* Region enabled */
         }};
@@ -225,7 +267,6 @@ pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags)
 
     return region;
 }
-#endif /* CONFIG_ARM_64 */
 
 void __init setup_mm(void)
 {
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Fri Jun 06 17:14:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 17:14:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008715.1387932 (Exim 4.92)
	(envelope-from )
	id 1uNadp-0002K3-0b; Fri, 06 Jun 2025 17:14:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008715.1387932; Fri, 06 Jun 2025 17:14: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 1uNado-0002Jw-UF; Fri, 06 Jun 2025 17:14:04 +0000
Received: by outflank-mailman (input) for mailman id 1008715;
 Fri, 06 Jun 2025 17:14: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 1uNadn-0002Jq-OK
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 17:14:03 +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 a3a46a42-42f9-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 19:14:01 +0200 (CEST)
Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
 by SA5PPFCAFD069B8.namprd12.prod.outlook.com
 (2603:10b6:80f:fc04::8e1) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.19; Fri, 6 Jun
 2025 17:13:55 +0000
Received: from PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264]) by PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264%2]) with mapi id 15.20.8792.035; Fri, 6 Jun 2025
 17:13: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: a3a46a42-42f9-11f0-a301-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=rx73MiSuAcx+unc/Iox1kZsbO7JQLC5geQ2FebKTLHna2YRqPi0ULAj92lf1M9gp0b9VJf1bDHgwwFSbNGQ0bj6B5Rpff2+2t2y7pnYBLblC0kZr8e3WJuI5Pd3if88JRo+iEEZMPIh2ov6lkZ0iQO1CEUg7uOocQyljTNKR0IzqfHtTI3QzuvHSo46SpqBR4dU1qVRaL4D0NarcKsdk2NxsR9CvT9AtM046WBeagV/tsDslCgviTNG8hWF7tMC9BpJ/LALIHE2HJnHDqdShbadgvBopE0/ZLk1fFPTe0fpWnaKfQU8H1saM1eEzkRVol18hetfiHvnmI25rY6TYDw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=YCMWIPiPqhgHfQNQvgOTeK6iIwwzGiacbh9de7UPWPQ=;
 b=HGJ5vFBl2JtvyAaAAeAMZEPx7RrX4EgFgZdLBmM3PXGytkH71VPV/tknheWldEHf8W0nHTKZZm+Q6cj7Liv71rgI71GPVLnApCMQIjwSCz4PIpkSkKVDxHfFz/WBJ0/vY5imDROvVBNwXeLDtDPezBAsyFOuqzqI3r6u/JHR4nVA8CuJOiNW9cf6egvdZ+TiJ+eOm4q2CYDU7gZ3Wd8xj8sZ4yycjLVhvhmB4T7htL8CTrUn5RfZAkqLTrEeEfYTQIwmEo54qzAUtkes1Dl04vMWC4oVqjALKg0qPA8GCCo4yKm1oKrBeAvH0m8TRmNADTPMUTIDMbj4XTHyMeaI1g==
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=YCMWIPiPqhgHfQNQvgOTeK6iIwwzGiacbh9de7UPWPQ=;
 b=5nDHkuAUeWsNC5mu3t6YhSNT3N4o3DijZcuczaJHaFfkqNqEawzfaHUyUpCtnpitrg9NMpWoQ+H2a7iutaHKF8tQaS0tIkbwd3n1frCze/S0nASWtusqHj+0Pja+25FtKziSS+L+7CZN1t7Cso/ry5ZyrO0oDFffBIHuUnvFeqE=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Fri, 6 Jun 2025 18:13:51 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 0/3] Enable R52 support for the first chunk of MPU
 support
Content-Language: en-GB
To: Ayan Kumar Halder ,
 xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: <20250604174311.754899-1-ayan.kumar.halder@amd.com>
From: Ayan Kumar Halder 
In-Reply-To: <20250604174311.754899-1-ayan.kumar.halder@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LO2P265CA0105.GBRP265.PROD.OUTLOOK.COM
 (2603:10a6:600:c::21) To PH8PR12MB7326.namprd12.prod.outlook.com
 (2603:10b6:510:216::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|SA5PPFCAFD069B8:EE_
X-MS-Office365-Filtering-Correlation-Id: ab9f3cf3-7e26-4ee3-275c-08dda51d846d
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?RkpTZ3VxRGNNeElYeU1RK0h4MHVtaVpGbWFrVmNsYkJXcFprLzhLRTR6QVRk?=
 =?utf-8?B?eDJqSlBlTXhlblVuK0FOMDI2UXBUY1pKTGhoemtaM1g1azNXWHYyK1RwUnpU?=
 =?utf-8?B?NFBmR0hRYTVoTENlQWlJMVYwNWhveGc3TXIyd2RBZlViU3BDclJWL3ExM04r?=
 =?utf-8?B?QU9XNWhTTWw0OC8wbmdJWjVCNENqQjFUVFNZYWtFVG1UYlh5bjNJWGlCa1dN?=
 =?utf-8?B?OU5ObWhTZGR4T3o5ZUJhWFByNEtReit1UkZuVmxqZGpjUWVHMldWQTJ5V085?=
 =?utf-8?B?b1pXK3p5dUlQWmRyOUFNOExIZVdYL3FsMG9GTnUrQlA5VENjVENtVUJtUlFo?=
 =?utf-8?B?dXlFYmxsU0xVeXM2MkxTNjlsUG02T2dXclJLemNOdFUvcFIvcElJeFRscWRs?=
 =?utf-8?B?S3R1bkNaYW5vMGc2YXFEOXhGRlQzUWFLWXpMb1RyM2ZwNmFmNHd4MmR2WXVN?=
 =?utf-8?B?dEhWdlhxaW5HYWJwcWRET2tBSWFoZVhhK0UvMDRrMHIxYWliSnQyRUhOclRx?=
 =?utf-8?B?WUFPRHkzTStZRWw1S2I2RFZGZGJONGVEd1JVYU9QQ0syUXBmQ1ZBVm9tV1Fx?=
 =?utf-8?B?MGVxdEptK2FsVlFYNmQyanFEWk51aVc4WlBWMFFnTkVKR3dTQ3RhNDlqSG80?=
 =?utf-8?B?VDg0ZTRONHNpUjltREd0eE5MTXVjU2RtV05OQnRZVDB0QUh2VzE0dWI1SURq?=
 =?utf-8?B?TWFyNXBYNklKU2wrc0RrYmUyQTJMdmQ5MkVTTzBVMmdIUzhsTEM2OFFoK25h?=
 =?utf-8?B?cExTRUpOZ3R2RzlhdU1TdjdjbG94UGtUZGVQclVvOTNNMkh2UDZxdWFnc2pD?=
 =?utf-8?B?L1hTWkY1YjlGRHZWUHNwK2tXTzI5Ynp0d0tqS0p0b1dhM2lzN2JMU0w4S2xQ?=
 =?utf-8?B?SHdIVzVxTHFHaWwzQjlESWJsaHBMdGkrZy92NWowc29rb3FBeEhGWDFpUWlI?=
 =?utf-8?B?cUVCUmtmblhGc1F2Qi9NZS9WdmZUS0xXL2NFZFRaaGtma3QxNWd0ZkdyVWFT?=
 =?utf-8?B?OE9ZQnJ1QWlXVk44YjVpY2ZydXBMU1JtQWpEdWIzQUJuSnlha1kwMmhvYzBm?=
 =?utf-8?B?STVVdW1VSjE5dS9IU3FDRnNheUFPMitqbklMM3VKM24wdkx6Y0RqRC9BblU3?=
 =?utf-8?B?NnI3ZjRwMTJzL3ByaDl6b1hXbGp1dVVVUERrNE5qSzl6bU9HR1kvemtTbmRi?=
 =?utf-8?B?b1dISHN2dDZMaEthaG1GY3Z1WXRwbmZLOXc3WnRLeHhLMWtiN3g4OGVvUzlX?=
 =?utf-8?B?UnlFUG5nVHlMUy9yMWVwd0lQN0tzMmVpQmJ5MDU3Zlg3N1c4ZFV4cWRiN2Jr?=
 =?utf-8?B?VWNoalpqTDBKWEd3aG9xbWcyenZyYzlIUUlueW1wWGJOYm9Lc1BPaDhBVnp2?=
 =?utf-8?B?MURrMGszdnk5amJ5YXloWFJucEloZWFMeHZDbG1yNGdYVGdWdytEVEdqQUJi?=
 =?utf-8?B?eThCc21mWW9MMXJDTDgwMHdmY0hVQk80V2NWV3VIVFJ2WjVuWUU0bU03NGJX?=
 =?utf-8?B?NWtDMDFDejlLVlJlNGcvSnJWRGdQTGJlSTVxdUFKTEJTOWxYMm8zbFR3Ny9r?=
 =?utf-8?B?cTJYS3BSLzVjV1l6cEVMaW5lTmE0VWhKN21nNDF3cHhHMjVvcXA2RkNpTWk3?=
 =?utf-8?B?RjVJS0xoeDRYYzlFSEVaNFJNajFWcUw0Q0lJWkNvT3hoQnRUeXNsdURVdm5v?=
 =?utf-8?B?c0dvTkVWK1phWTlqVXhUbUJjMWlXSVlicUxQS0hGSTJuMHdvNG1UT25XSEJu?=
 =?utf-8?B?a09BRTIycW5SZzJaM3IyZ2pTV0lHNTZVNkR2SHZpNGZ4bi8zdnkwQjRBMnYy?=
 =?utf-8?B?VDJHOXg3Q29uUGhBOXA0Mk13Snp3K2tLMXFMbHNDRkVFWDNMU3hlSDNhQmtO?=
 =?utf-8?B?bzVmSUJHNGkxUHVzUzNRNlV0Tk9UcDAvTVd5djZRU051elE9PQ==?=
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)(376014)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?Ujl1YjBOTEtDL1RYTmJBcEVaZzBkaEJJTXlob096RjBmUFhOSTFJNkFiR1oy?=
 =?utf-8?B?WW5WNG1vQ0h1UTQ5ZHJwelkwekhrVVNNZnUwaGU3bjBlNm1HcFQzWnRFRjcz?=
 =?utf-8?B?YkZrMWFTRE5WYlVEcGY1TTB2c3dIM3VIbkFUV3dmRDg2ZGY4TkJvVmxPdzdv?=
 =?utf-8?B?U3FaTURWQzZGRUZZR0UzcmdGSkhrdkpmSnVSRUVlMm40c0t5dEJlbFlQMCt4?=
 =?utf-8?B?NDdFMTVwWlV5OE1wQTVkbnNjcUUxUUpmWGlIc0NUQVhoTE9pTSs3QmFyN3Rn?=
 =?utf-8?B?NmtJU05JWVBnWTIzaUZWUHlLRlg5ZHlMdkJPOGJ0b3RlMUxyT0NheXRybXFM?=
 =?utf-8?B?SElUMmdQSk1lN09iMDdFZ1Z2SWhpK1pqcmE1M05Ba2RObDNsd3BpTW1hc2Fm?=
 =?utf-8?B?NjIvMWNtd3NNWXRDbVNGanBGRWxvWTZsajA1RFZram5OZ3NGdW52Ym5ZOThx?=
 =?utf-8?B?OTkyUWhkckpTZzV6Zk53VGhkV0x4dUFXcEpPRVBVcFVUQWlaR1JCZjZCck5s?=
 =?utf-8?B?bTZIK1ZFVzIxODliRWJFWnQ0ZVFqNnc2OE9XVTlGVU9TTVdLK01UMDZ3VWZE?=
 =?utf-8?B?eTZPZzJ3Z2JvUis5MUtzbHlIM1JTRkhEUW9hS1A1SVgzbklDSDJvcHptbExz?=
 =?utf-8?B?YVVkdmE2R3R0MWpPck9BbmZKaWQ5dlY0RytyK3BCRnVkbklqbGxSNFRTV21i?=
 =?utf-8?B?aklGSEtRZmdYVGM3ZUhuZWc5TXM0T00zcmhmVk9pVCtNZzBVcDcxakpPeTdB?=
 =?utf-8?B?OWczaHo3bWRYL0d4bWliZndyQXFGdG1Ma3ZsZ2dUaGFwUUFRSzM4Q2tkaFA5?=
 =?utf-8?B?RmZocnZkSWJiRWZxZk52NmhVbW9kOXgzT1JkSWE5STZFbHpHdFR4VStHNEl0?=
 =?utf-8?B?b1ArbjhBMzZnRnNIcFJYTm5UWk1zb0FJb3Z4VDVxZWZNWGFQU1duRkRqVE9P?=
 =?utf-8?B?UzB4aVNuWldDUlBqWkNJS2RUNWI3NmM3RmJ2RXFSc2gwejNBdE5sakhCdjh2?=
 =?utf-8?B?TXROam5SMm5MRVF2YkhQS2VJbkRIVExwayttdXYzUHJwMDVtZDVnMjNkTmdX?=
 =?utf-8?B?elFsOVZKd29sd2lGaVBIY0xiQk1NdEpUREtQWUZzOE9kSmNObnN0YjJ2ekpZ?=
 =?utf-8?B?blp5Nyt1aWhYZUdkK2xzTGhUdERRZTA1c0lKMVVPa3M0VDFMTEttOG91Nnoy?=
 =?utf-8?B?SmNWcG9SeVRxd3hhQk1jZFpFM0pIc3BuVExkcU1ETm85SUJjbkFXaVlpR2Mx?=
 =?utf-8?B?YW5XL0VuWTdrOVl2Mk1WM0lkYUZMV2MzWnhVTkZuVS9qVFpaekc1amJUMlNG?=
 =?utf-8?B?L3hZQ3M5OU4wZU96bFRtdVJjZFBaSVZjeFVEQVZZc2FhdmZCM2UvRmlpNDBW?=
 =?utf-8?B?RUdxT2Ria3RkcXhidmZsUHNaSytpZHhoa1pJV0tSQWFPVnVrR3h1RU9kemVv?=
 =?utf-8?B?ZUVsQXhuVnRaL1hpS3JpVTcxYmI2K0krSmxUam81eGpHWSs0d0dQZlJXaUhN?=
 =?utf-8?B?RUFTLzdrQURJWTl2WXhHVTloL3VXdTJrK0VrUzRBVVpRNndjUzAxZ1BjVTdi?=
 =?utf-8?B?THlpZzRlUzAyajRIRDNadERtL1BEeXJNOXZwZFlCbFV6UzhCbWZVNlFXU21V?=
 =?utf-8?B?VWJ4dHNyRnltU0M3N3pzK2NCRjBYbDViQlc1UTJ4RWkvOXdiWEMvdndHT3N0?=
 =?utf-8?B?N2hSeUJtNm94djRmWVg0TkdPakV2V09RYTlkTXlHRmt0TmFuUnp4OHdFcFVP?=
 =?utf-8?B?NDc0Nm1NTFlJdWp5TEZoK3E2NmpxM1FhNnBENHBDQ1p1L2RrSUVxSUg1OEF2?=
 =?utf-8?B?K2laditqVk9zaUZoWllJemlBMGpsUndieGpKb2Q0d096OHUxSDMxbkpSejJm?=
 =?utf-8?B?OHJ6czB4Ym55a3NhbjA3OUdjT0U2enpYdUR3bjBVcWxJQitpS2pJUFpWZ3g4?=
 =?utf-8?B?VmpHZHhVcDhtcE1nVHcwMzNYQUs5RE1ZZmsyRmhJbWFNV2swY1p3TjU5SnAx?=
 =?utf-8?B?eXd5bXNVNDNUczUxRGxrM1lZK2ZjTitWMVVRaWFYVWgwN0JJcytYN2w4N3d6?=
 =?utf-8?B?aWFqV2xzQlZrQTlIb09SZlNWUkpKY29nVEN0RXBPcHhYWHVUbXJKdStNZ0xS?=
 =?utf-8?Q?koVTtDDx5vIL7akn7rIB1pGRP?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ab9f3cf3-7e26-4ee3-275c-08dda51d846d
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jun 2025 17:13:55.5114
 (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: IgFvasjs80cGFYgPId+Sbymk7pT77kmy53oNVkGSbfy08cw3PC2e5OkHFLGYAU+7pQ64yYMRlDjkKntploSb2A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA5PPFCAFD069B8

Hi,

On 04/06/2025 18:43, Ayan Kumar Halder wrote:
> Hi all,
>
> This patch serie enables R52 support based on Luca's series.
> "[PATCH v6 0/6] First chunk for Arm R82 and MPU support".

I have submitted a v2 "[PATCH v2 0/3] Enable R52 support for the first 
chunk of MPU support" with all the comments addressed.

- Ayan



From xen-devel-bounces@lists.xenproject.org Fri Jun 06 19:47:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 19:47:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008778.1387942 (Exim 4.92)
	(envelope-from )
	id 1uNd25-0003SL-45; Fri, 06 Jun 2025 19:47:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008778.1387942; Fri, 06 Jun 2025 19: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 1uNd25-0003SE-1H; Fri, 06 Jun 2025 19:47:17 +0000
Received: by outflank-mailman (input) for mailman id 1008778;
 Fri, 06 Jun 2025 19: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 1uNd23-0003S8-B6
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 19:47:16 +0000
Received: from mail-24418.protonmail.ch (mail-24418.protonmail.ch
 [109.224.244.18]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 09df2f02-430f-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 21:47:12 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 09df2f02-430f-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1749239231; x=1749498431;
	bh=BnQE95nEhr0HeFTdXiQDqAjIj1g84try2SvlY9hQV+A=;
	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=YIbBOrtn7M3MJiF7TYxMud2A3RgFlZmO9P1tahoLxn1ma9VYNXDJQS4ZeWw8BJ7qj
	 HKmORPiq3rAVsPaJPjKRwF52lde3nsuA5kmDPsUbFisjeKalLGJW3/Vcrh5vqSXh2e
	 3RErj7ACjahspGrtCLrlfsTpzaFHW2ZXkJW7W1MXT/TqJyKj9SQueK6QxqIoL5+NSW
	 2MGRidLa0GTY2pwfOwd+otP71eVt9xGcVIfqfwqDPQmcYH7TVRdxVoe+uLlScEqV0N
	 Lac5TXz8f5/uaNBN+xpxQlQMYv4tDnNAZd9NaWyAcdUYDFF0eJa49y4TAVJt4oXeOb
	 lRiZdPCPLvMBg==
Date: Fri, 06 Jun 2025 19:47:04 +0000
To: Jan Beulich 
From: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: Re: [PATCH v2 2/2] xen/console: unify printout behavior for UART emulators
Message-ID: 
In-Reply-To: 
References: <20250605004601.1142090-1-dmukhin@ford.com> <20250605004601.1142090-3-dmukhin@ford.com> <842528df-d0ba-4ab2-b182-b6f824c82dc1@suse.com>  
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 2d98d9230effb9e26878d248d16ae17a9faf88e3
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 06, 2025 at 09:12:06AM +0200, Jan Beulich wrote:
> On 06.06.2025 09:06, dmkhn@proton.me wrote:
> > On Thu, Jun 05, 2025 at 08:18:34AM +0200, Jan Beulich wrote:
> >> On 05.06.2025 02:46, dmkhn@proton.me wrote:
> >>> From: Denis Mukhin 
> >>>
> >>> If virtual UART from domain X prints on the physical console, the beh=
avior is
> >>> updated to (see [1]):
> >>> - console focus in domain X: do not prefix messages;
> >>> - no console focus in domain X: prefix all messages with "(dX)".
> >>>
> >>> Use guest_printk() without rate-limiting in all current in-hypervisor=
 UART
> >>> emulators. That aligns the behavior with debug I/O port 0xe9 handler =
on x86 and
> >>> slightly improves the logging since guest_printk() already prints the=
 domain
> >>> ID. guest_printk() was modified to account for console focus ownershi=
p.
> >>>
> >>> Modify guest_console_write() for hardware domain case by adding domai=
n ID to
> >>> the message when hwdom does not have console focus.
> >>>
> >>> [1] https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.24121216553=
60.463523@ubuntu-linux-20-04-desktop/
> >>> Signed-off-by: Denis Mukhin 
> >>> ---
> >>> Changes since v1:
> >>> - dropped change for debug port and for HYPERVISOR_console_io hyperca=
ll
> >>
> >> Yet then what about ...
> >>
> >>> --- 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 !=3D '\n' )
> >>>              uart->buf[uart->idx++] =3D '\n';
> >>>          uart->buf[uart->idx] =3D '\0';
> >>> -        printk(XENLOG_G_DEBUG "DOM%u: %s", d->domain_id, uart->buf);
> >>> +        guest_printk(d, "%s", uart->buf);
> >>>          uart->idx =3D 0;
> >>>      }
> >>>      spin_unlock(&uart->lock);
> >>
> >> ... this dropping of XENLOG_G_DEBUG? In fact I'd have expected such to
> >> be _added_ where presently missing.
> >
> > vUART is a debugging facility. This flavor of UART is specifically for =
guest OS
> > early boot debugging.
> > I think it is not desirable to potentially lose guest messages while do=
ing such
> > early guest OS boot debugging.
>=20
> That is the host admin's decision, not a policy we should enforce.

re: policy: agreed, I will drop that hunk.

I think for the policy control, there can be a compile time setting (separa=
te
patch) which enables/disables the debug output rate-limiting - and that set=
ting
applies to:
  - vUARTs (currently vpl011 and "vuart", later ns16550 (x86) and upcoming
    emulator for RISC-V)
  - debug port on x86
  - HYPERVISOR_console_io

What do you think?

>=20
> Jan



From xen-devel-bounces@lists.xenproject.org Fri Jun 06 19:50:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 19:50:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008789.1387951 (Exim 4.92)
	(envelope-from )
	id 1uNd4p-00050o-JP; Fri, 06 Jun 2025 19:50:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008789.1387951; Fri, 06 Jun 2025 19:50: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 1uNd4p-00050h-GJ; Fri, 06 Jun 2025 19:50:07 +0000
Received: by outflank-mailman (input) for mailman id 1008789;
 Fri, 06 Jun 2025 19:50: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 1uNd4o-0004ub-F0
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 19:50:06 +0000
Received: from mail-10631.protonmail.ch (mail-10631.protonmail.ch
 [79.135.106.31]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7086adf3-430f-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 21:50:04 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7086adf3-430f-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1749239403; x=1749498603;
	bh=0LQ6dCGUKxJWJXyfgNN99Fw8rnMvgk0zd1TarhjT780=;
	h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
	 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector:
	 List-Unsubscribe:List-Unsubscribe-Post;
	b=LqWHsDtRLIvOA8Ja+86cRfRCYiO0ytu2K0ODBgLmHfTERf6mnFPnwr+nUWaHlG7Vw
	 YWauQrL7pgMyu2R3NnDaIXW74rDYOdzXZF2QwXPiXXmGTANINj0Teh8Qqr9Zvl/u9a
	 W/ACsoL5yamhZz/agVUiI9AvyR37KRQHTj6y5iA1nHJCdrHOGIJhBDIgJP0ADlWouM
	 2oTkrtjW0ZMU+TLT+k1+X5DHRuGydgJv5jBZCFthSns5b/NoncmT5MLqFcbGV4iJ7r
	 eqdcVRFZqbL0L3VgVxi+tuXoJCo8Jk5O1kDGL+Exhlyq/0e7L+6g3M06zrPRdzHmBQ
	 WL2WeDl+E2LMQ==
Date: Fri, 06 Jun 2025 19:49:57 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v1] xen/console: group pbuf under console field
Message-ID: <20250606194937.2412579-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 375e6bda5775af11fff66bdb2b858c00a6f37865
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Group all pbuf-related data structures under domain's console field.

No functional change.

Signed-off-by: Denis Mukhin 
---
 xen/arch/x86/hvm/hvm.c     | 14 +++++++-------
 xen/common/domain.c        |  8 ++++----
 xen/drivers/char/console.c | 19 +++++++++++--------
 xen/include/xen/sched.h    | 12 ++++++------
 4 files changed, 28 insertions(+), 25 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 4cb2e13046..17d1fd42ce 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -571,16 +571,16 @@ static int cf_check hvm_print_line(
     if ( !is_console_printable(c) )
         return X86EMUL_OKAY;
=20
-    spin_lock(&cd->pbuf_lock);
+    spin_lock(&cd->console.pbuf_lock);
     if ( c !=3D '\n' )
-        cd->pbuf[cd->pbuf_idx++] =3D c;
-    if ( (cd->pbuf_idx =3D=3D (DOMAIN_PBUF_SIZE - 1)) || (c =3D=3D '\n') )
+        cd->console.pbuf[cd->console.pbuf_idx++] =3D c;
+    if ( (cd->console.pbuf_idx =3D=3D (DOMAIN_PBUF_SIZE - 1)) || (c =3D=3D=
 '\n') )
     {
-        cd->pbuf[cd->pbuf_idx] =3D '\0';
-        guest_printk(cd, XENLOG_G_DEBUG "%s\n", cd->pbuf);
-        cd->pbuf_idx =3D 0;
+        cd->console.pbuf[cd->console.pbuf_idx] =3D '\0';
+        guest_printk(cd, XENLOG_G_DEBUG "%s\n", cd->console.pbuf);
+        cd->console.pbuf_idx =3D 0;
     }
-    spin_unlock(&cd->pbuf_lock);
+    spin_unlock(&cd->console.pbuf_lock);
=20
     return X86EMUL_OKAY;
 }
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 153cd75340..dd1867b2fe 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -669,7 +669,7 @@ static void _domain_destroy(struct domain *d)
     BUG_ON(!d->is_dying);
     BUG_ON(atomic_read(&d->refcnt) !=3D DOMAIN_DESTROYED);
=20
-    xfree(d->pbuf);
+    xfree(d->console.pbuf);
=20
     argo_destroy(d);
=20
@@ -862,7 +862,7 @@ struct domain *domain_create(domid_t domid,
     spin_lock_init(&d->shutdown_lock);
     d->shutdown_code =3D SHUTDOWN_CODE_INVALID;
=20
-    spin_lock_init(&d->pbuf_lock);
+    spin_lock_init(&d->console.pbuf_lock);
=20
     rwlock_init(&d->vnuma_rwlock);
=20
@@ -956,8 +956,8 @@ struct domain *domain_create(domid_t domid,
         goto fail;
=20
     err =3D -ENOMEM;
-    d->pbuf =3D xzalloc_array(char, DOMAIN_PBUF_SIZE);
-    if ( !d->pbuf )
+    d->console.pbuf =3D xzalloc_array(char, DOMAIN_PBUF_SIZE);
+    if ( !d->console.pbuf )
         goto fail;
=20
     if ( (err =3D sched_init_domain(d, config->cpupool_id)) !=3D 0 )
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 616f4968b0..3855962af7 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -769,22 +769,25 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARA=
M(char) buffer,
             } while ( --kcount > 0 );
=20
             *kout =3D '\0';
-            spin_lock(&cd->pbuf_lock);
+            spin_lock(&cd->console.pbuf_lock);
             kcount =3D kin - kbuf;
             if ( c !=3D '\n' &&
-                 (cd->pbuf_idx + (kout - kbuf) < (DOMAIN_PBUF_SIZE - 1)) )
+                 cd->console.pbuf_idx + kout - kbuf < DOMAIN_PBUF_SIZE - 1=
 )
             {
                 /* buffer the output until a newline */
-                memcpy(cd->pbuf + cd->pbuf_idx, kbuf, kout - kbuf);
-                cd->pbuf_idx +=3D (kout - kbuf);
+                memcpy(cd->console.pbuf + cd->console.pbuf_idx,
+                       kbuf,
+                       kout - kbuf);
+                cd->console.pbuf_idx +=3D (kout - kbuf);
             }
             else
             {
-                cd->pbuf[cd->pbuf_idx] =3D '\0';
-                guest_printk(cd, XENLOG_G_DEBUG "%s%s\n", cd->pbuf, kbuf);
-                cd->pbuf_idx =3D 0;
+                cd->console.pbuf[cd->console.pbuf_idx] =3D '\0';
+                guest_printk(cd,
+                             XENLOG_G_DEBUG "%s%s\n", cd->console.pbuf, kb=
uf);
+                cd->console.pbuf_idx =3D 0;
             }
-            spin_unlock(&cd->pbuf_lock);
+            spin_unlock(&cd->console.pbuf_lock);
         }
=20
         guest_handle_add_offset(buffer, kcount);
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index fe53d4fab7..637aa09ec4 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -562,12 +562,6 @@ struct domain
     /* Control-plane tools handle for this domain. */
     xen_domain_handle_t handle;
=20
-    /* hvm_print_line() and guest_console_write() logging. */
-#define DOMAIN_PBUF_SIZE 200
-    char       *pbuf;
-    unsigned int pbuf_idx;
-    spinlock_t  pbuf_lock;
-
     /* OProfile support. */
     struct xenoprof *xenoprof;
=20
@@ -654,6 +648,12 @@ struct domain
=20
     /* Console settings. */
     struct {
+        /* hvm_print_line() and guest_console_write() logging. */
+#define DOMAIN_PBUF_SIZE 200
+        char *pbuf;
+        unsigned int pbuf_idx;
+        spinlock_t pbuf_lock;
+
         /* Permission to take ownership of the physical console input. */
         bool input_allowed;
     } console;
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Fri Jun 06 19:59:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 19:59:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008804.1387962 (Exim 4.92)
	(envelope-from )
	id 1uNdEF-0005iw-Dq; Fri, 06 Jun 2025 19:59:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008804.1387962; Fri, 06 Jun 2025 19:59: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 1uNdEF-0005ip-AU; Fri, 06 Jun 2025 19:59:51 +0000
Received: by outflank-mailman (input) for mailman id 1008804;
 Fri, 06 Jun 2025 19:59: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 1uNdEE-0005gT-5h
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 19:59:50 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ccd23e1a-4310-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 21:59:49 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 89DC849F5B;
 Fri,  6 Jun 2025 19:59:47 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6B55FC4CEEB;
 Fri,  6 Jun 2025 19:59: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: ccd23e1a-4310-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749239987;
	bh=/A3ZcJBNH2YZ/Vl+1PMhBqGcJeXmBWYHrJbmCgyR3G8=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=NcTbdQV2c6d5rpagNxX9KMuGytDBABiruDVXXpU+GfnEnf2gV+8IkC5xmV0HxQi0J
	 OqqZR3y8w/YzAix3RMdEZ81eU321IlJKjFE60jf5vrQG22pId8JVB0JAJ8t32NSt8u
	 MX9h/1MhN6xXk3XtDqshnPqhQLc8VUv6OfdCR/hiU5K0j0rQXzMvjVzsDB4pQ1jHKk
	 e43xnFqGzXnMbFCpsxiFbF9za5Czy7uq7k/r9pmhtGlSEawxABRwCq1PWPhfh7pTdd
	 1cALO2TdqPNOLao1buZoupDemBYm2+tdQWhdEgQ9f8nKyFT0uTn35czeVFlYiwHAMA
	 Q5SK4elmeZ6Uw==
Date: Fri, 6 Jun 2025 12:59:45 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: "Orzel, Michal" , xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Volodymyr Babchuk , 
    "Daniel P. Smith" 
Subject: Re: [PATCH v2 08/15] xen/dt: Move bootfdt functions to
 xen/bootfdt.h
In-Reply-To: 
Message-ID: 
References: <20250605194810.2782031-1-agarciav@amd.com> <20250605194810.2782031-9-agarciav@amd.com> <633ffa7f-cf26-4ec3-a153-28404c39d882@amd.com> 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 6 Jun 2025, Alejandro Vallejo wrote:
> On Fri Jun 6, 2025 at 10:59 AM CEST, Michal Orzel wrote:
> >
> >
> > On 05/06/2025 21:48, Alejandro Vallejo wrote:
> >> Part of an unpicking process to extract bootfdt contents independent of bootinfo
> >> to a separate file for x86 to take.
> >> 
> >> Move functions required for early FDT parsing from device_tree.h and arm's
> >> setup.h onto bootfdt.h
> >> 
> >> Declaration motion only. Not a functional change.
> >> 
> >> Signed-off-by: Alejandro Vallejo 
> >> ---
> >> v2:
> >>   * Remove the u32 identifiers in the device_tree_get_u32() implementation
> > I don't understand the reasoning behind changing u32->uint32_t only for one
> > function in this patch while leaving others unmodified. Also what about u64?
> > Either don't change any or change all.
> 
> Sure. Let's call the original u32->uint32_t change a misplaced mutation and
> move on. The point is the motion, not these cleanups on top.

Yes I agree. I know from past experience that Jan doesn't mind changes
during code movements, but for me it is important that changes and code
movement are separate. That is because I have almost automatic ways to
check that code movement is correct if there are no changes. It saves me
a lot of time during review. Then I can look at the individual changes
separately.


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 20:11:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 20:11:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008812.1387981 (Exim 4.92)
	(envelope-from )
	id 1uNdPW-0000As-JC; Fri, 06 Jun 2025 20:11:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008812.1387981; Fri, 06 Jun 2025 20:11: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 1uNdPW-0000Ai-Gg; Fri, 06 Jun 2025 20:11:30 +0000
Received: by outflank-mailman (input) for mailman id 1008812;
 Fri, 06 Jun 2025 20:11: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 1uNdPU-00009b-DZ
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 20:11:28 +0000
Received: from mail-24416.protonmail.ch (mail-24416.protonmail.ch
 [109.224.244.16]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6b281b22-4312-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 22:11:23 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6b281b22-4312-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=ifubwuzdrngs7k2lxbfr5quiby.protonmail; t=1749240681; x=1749499881;
	bh=GdEbK8D2ZDN7Lr8LitkKUBGodl297aVwXtvJS3LFQEE=;
	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=dxJKsf2KYlnsgOS0HqmrmgLopO40zDwgsWN4j5QYgvjNTiMZEudh67hVi8pFTPiPr
	 xMpYOS/lGlFTxqRVY8Ho6RWV5IZ+qGwIwTnporf6ztbZl1Sw/2x+/4+dyVgTMNygVJ
	 rQIQiB18gDJUFKJst3HEd6bYd/7UgmA+JXpKm/zfaCMX1randC8DMM0XZMp0v35aC0
	 Y/vk38l9/dpC8ofoR+taD1XRJpSONu7wEyJ3G+g8bpzqTOik3mkHawW/wCxAbzCQ3X
	 EYTfk6fiSEPDB2KT/qu8pnf6sFw3iJXbUFBSwTRiKmIwXbxixcluQPWZmDDNICSZLG
	 bVgzFqvALYamg==
Date: Fri, 06 Jun 2025 20:11:17 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v3 1/2] xen/console: introduce CONSOLE_PREFIX
Message-ID: <20250606201102.2414022-2-dmukhin@ford.com>
In-Reply-To: <20250606201102.2414022-1-dmukhin@ford.com>
References: <20250606201102.2414022-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: e1dd58d38b52f9c478d11af804f89d4558dcda61
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Add CONSOLE_PREFIX symbol to keep the prefix of the hypervisor's diagnostic
messages.

No functional change.

Signed-off-by: Denis Mukhin 
---
Changes since v2:
- n/a
---
 xen/drivers/char/console.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index e3731bf174..6e77b4af82 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -61,6 +61,9 @@ enum {
     CONSOLE_ALL             =3D CONSOLE_DEFAULT | CONSOLE_RING,
 };
=20
+/* Prefix for hypervisor's diagnostic console messages. */
+#define CONSOLE_PREFIX      "(XEN) "
+
 static void console_send(const char *str, size_t len, unsigned int flags);
=20
 /* console: comma-separated list of console outputs. */
@@ -1017,7 +1020,7 @@ static void vprintk_common(const char *fmt, va_list a=
rgs, const char *prefix)
=20
 void vprintk(const char *fmt, va_list args)
 {
-    vprintk_common(fmt, args, "(XEN) ");
+    vprintk_common(fmt, args, CONSOLE_PREFIX);
 }
=20
 void printk(const char *fmt, ...)
@@ -1288,7 +1291,7 @@ int __printk_ratelimit(int ratelimit_ms, int ratelimi=
t_burst)
             snprintf(lost_str, sizeof(lost_str), "%d", lost);
             /* console_lock may already be acquired by printk(). */
             rspin_lock(&console_lock);
-            printk_start_of_line("(XEN) ");
+            printk_start_of_line(CONSOLE_PREFIX);
             __putstr("printk: ");
             __putstr(lost_str);
             __putstr(" messages suppressed.\n");
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Fri Jun 06 20:11:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 20:11:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008811.1387971 (Exim 4.92)
	(envelope-from )
	id 1uNdPP-0008NV-C7; Fri, 06 Jun 2025 20:11:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008811.1387971; Fri, 06 Jun 2025 20: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 1uNdPP-0008NO-9e; Fri, 06 Jun 2025 20:11:23 +0000
Received: by outflank-mailman (input) for mailman id 1008811;
 Fri, 06 Jun 2025 20: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 1uNdPM-0008NH-9b
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 20:11:21 +0000
Received: from mail-24418.protonmail.ch (mail-24418.protonmail.ch
 [109.224.244.18]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 673db203-4312-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 22:11:17 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 673db203-4312-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1749240675; x=1749499875;
	bh=Lp5h+FAjm96E/U9mx+er7ay1xqPjAsWEpNjB2aWoz0w=;
	h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
	 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector:
	 List-Unsubscribe:List-Unsubscribe-Post;
	b=lhqE34pEL5bZKydIo6keS7n88huBrluHONcspfGiyTl2oWGQ6tCCBqfSvJ8wxzC9B
	 XTmMRDq+iJVKajpnavL6rDpUAzKuqMPpNwALvB7xoTMBntwkiz45Xf2Fw4lasuJkC1
	 OO1Vg4bsDv+M3g37ualJW8FrrtpO67kQekJHFPrNxBE0OrtG8qhqILyatamAx9cytj
	 bA8KP3XA+360ONBUAYkfRMuaGRXxDbPmplVHzWXYLphXajcgbqOqoiNzIS06INCsEV
	 kDHHillJOZJyx0Ap94depQSH3Xo5/e9SPGdi/nmqz5zolpLBCWnQpDomlukvFnipcs
	 iVQGbvsieQSVQ==
Date: Fri, 06 Jun 2025 20:11:08 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v3 0/2] xen/console: updates to diagnostic messages prefixes
Message-ID: <20250606201102.2414022-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 08c35cdaee586a798b484ebc1549e5acb79253c3
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Patch 1 is purely cosmetic change, adds a symbol for hypervisor's messages.

Patch 2 updates the logic how the domain prefix is formed for guest message=
s
sent over emulated UART.

[1] Link to v2: https://lore.kernel.org/xen-devel/20250605004601.1142090-1-=
dmukhin@ford.com/
[2] Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelin=
es/1857923457

Denis Mukhin (2):
  xen/console: introduce CONSOLE_PREFIX
  xen/console: unify printout behavior for UART emulators

 xen/arch/arm/vpl011.c      |  6 +++---
 xen/arch/arm/vuart.c       |  2 +-
 xen/drivers/char/console.c | 30 ++++++++++++++++++++++++++----
 3 files changed, 30 insertions(+), 8 deletions(-)

--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Fri Jun 06 20:11:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 20:11:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008814.1387991 (Exim 4.92)
	(envelope-from )
	id 1uNdPc-0000Sz-QR; Fri, 06 Jun 2025 20:11:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008814.1387991; Fri, 06 Jun 2025 20:11: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 1uNdPc-0000Ss-NB; Fri, 06 Jun 2025 20:11:36 +0000
Received: by outflank-mailman (input) for mailman id 1008814;
 Fri, 06 Jun 2025 20:11: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 1uNdPb-00009b-IW
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 20:11:35 +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 71233d18-4312-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 22:11:33 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 71233d18-4312-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1749240692; x=1749499892;
	bh=w1aYox814ENiGX0kzo/wv0psYSfdQIkk6c5aSghtUUw=;
	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=jilGMtNfSwS7UfclOajsb05eshx9elibnWNZ0dLxs2VaJ2CfG13Iuef4Paye2ViCz
	 eoUi+k+jDP2QAWWPooH1DXCxhnULWYBvjuPxmwJmTbpm2AUmdfG3OgyyGcwvaTYbyx
	 qWGk7g2IEfpMQULjolj50UP4QBd79ju1n75gZi/UrXeVerI13ZwxCLSRMtRMn/rxsO
	 dr+8xemqv2Z81yPlHX+RoTFD4D8j5mmU54rhJbKJ/2MfnRU+B8rTvE4F+uwBHzMueH
	 +ANN/8BkJBx/2LSUvOpJJ+XYFmTnkR7jkhLkrsnUh2OzrT1AwrxK7nvm/DtoP5zy1j
	 bDRVhTWVba6ug==
Date: Fri, 06 Jun 2025 20:11:26 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v3 2/2] xen/console: unify printout behavior for UART emulators
Message-ID: <20250606201102.2414022-3-dmukhin@ford.com>
In-Reply-To: <20250606201102.2414022-1-dmukhin@ford.com>
References: <20250606201102.2414022-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: cadaa70cd81e68ac9141d280fefdfcb0acf2c0a5
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

If virtual UART from domain X prints on the physical console, the behavior =
is
updated to (see [1]):
- console focus in domain X: do not prefix messages;
- no console focus in domain X: prefix all messages with "(dX)".

Use guest_printk() in all current in-hypervisor UART emulators. That aligns=
 the
behavior with debug I/O port 0xe9 handler on x86 and slightly improves the
logging since guest_printk() already prints the domain ID. guest_printk() w=
as
modified to account for console focus ownership.

Modify guest_console_write() for hardware domain case by adding domain ID t=
o
the message when hwdom does not have console focus.

[1] https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2412121655360.463=
523@ubuntu-linux-20-04-desktop/
Signed-off-by: Denis Mukhin 
---
Changes since v2:
- dropped rate-limiting change for vuart
---
 xen/arch/arm/vpl011.c      |  6 +++---
 xen/arch/arm/vuart.c       |  2 +-
 xen/drivers/char/console.c | 23 +++++++++++++++++++++--
 3 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 480fc664fc..2b6f2a09bc 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -87,7 +87,7 @@ static void vpl011_write_data_xen(struct domain *d, uint8=
_t data)
     {
         if ( intf->out_prod =3D=3D 1 )
         {
-            printk("%c", data);
+            guest_printk(d, "%c", data);
             intf->out_prod =3D 0;
         }
         else
@@ -95,7 +95,7 @@ static void vpl011_write_data_xen(struct domain *d, uint8=
_t data)
             if ( data !=3D '\n' )
                 intf->out[intf->out_prod++] =3D '\n';
             intf->out[intf->out_prod++] =3D '\0';
-            printk("%s", intf->out);
+            guest_printk(d, "%s", intf->out);
             intf->out_prod =3D 0;
         }
     }
@@ -107,7 +107,7 @@ static void vpl011_write_data_xen(struct domain *d, uin=
t8_t data)
             if ( data !=3D '\n' )
                 intf->out[intf->out_prod++] =3D '\n';
             intf->out[intf->out_prod++] =3D '\0';
-            printk("DOM%u: %s", d->domain_id, intf->out);
+            guest_printk(d, "%s", intf->out);
             intf->out_prod =3D 0;
         }
     }
diff --git a/xen/arch/arm/vuart.c b/xen/arch/arm/vuart.c
index bd2f425214..6641f9d775 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 !=3D '\n' )
             uart->buf[uart->idx++] =3D '\n';
         uart->buf[uart->idx] =3D '\0';
-        printk(XENLOG_G_DEBUG "DOM%u: %s", d->domain_id, uart->buf);
+        guest_printk(d, XENLOG_G_DEBUG "%s", uart->buf);
         uart->idx =3D 0;
     }
     spin_unlock(&uart->lock);
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 6e77b4af82..3855962af7 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -740,7 +740,17 @@ 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 */
+            char prefix[16] =3D "";
+            struct domain *consd;
+
+            consd =3D console_get_domain();
+            if ( consd !=3D cd )
+                snprintf(prefix, sizeof(prefix), "(d%d) ", cd->domain_id);
+            console_put_domain(consd);
+
             nrspin_lock_irq(&console_lock);
+            if ( prefix[0] !=3D '\0' )
+                console_send(prefix, strlen(prefix), flags);
             console_send(kbuf, kcount, flags);
             nrspin_unlock_irq(&console_lock);
         }
@@ -1032,12 +1042,21 @@ void printk(const char *fmt, ...)
     va_end(args);
 }
=20
+/*
+ * Print message from the guest on the diagnostic console.
+ * Prefixes all messages w/ "(dX)" if domain X does not own physical conso=
le
+ * focus.
+ */
 void guest_printk(const struct domain *d, const char *fmt, ...)
 {
     va_list args;
-    char prefix[16];
+    char prefix[16] =3D "";
+    struct domain *consd;
=20
-    snprintf(prefix, sizeof(prefix), "(d%d) ", d->domain_id);
+    consd =3D console_get_domain();
+    if ( consd !=3D d )
+        snprintf(prefix, sizeof(prefix), "(d%d) ", d->domain_id);
+    console_put_domain(consd);
=20
     va_start(args, fmt);
     vprintk_common(fmt, args, prefix);
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Fri Jun 06 20:14:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 20:14:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008831.1388001 (Exim 4.92)
	(envelope-from )
	id 1uNdSp-0001VP-7u; Fri, 06 Jun 2025 20:14:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008831.1388001; Fri, 06 Jun 2025 20:14: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 1uNdSp-0001VI-5R; Fri, 06 Jun 2025 20:14:55 +0000
Received: by outflank-mailman (input) for mailman id 1008831;
 Fri, 06 Jun 2025 20:14: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 1uNdSo-0001VC-1w
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 20:14: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 e6a3902d-4312-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 22:14:51 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 23A8A5C5B03;
 Fri,  6 Jun 2025 20:12:33 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 61D8FC4CEEF;
 Fri,  6 Jun 2025 20:14:48 +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: e6a3902d-4312-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749240889;
	bh=kzLpwseiVUQYwPvBV3QbnE8pI2WTTjcdXhv/mrBBSmc=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=hbJvNY9FfUhTHPoUouI+yacqb8QXqxC3TLKBFcmedA4v9Vrm12i7lRpanrpAFSw7E
	 o7nnPABX5J0flrOwCSZqdOyUsUTIcFtHPpLW1PA9jgrSpXzs260KWp8A5fkk11JaDF
	 sAQquGX3q+CV6Xw0a+NAH7SL67pQqud/xHOaP33I4hR/4vywXRMNmQCWjcJ6FxPkSx
	 WtYSQUa+q5fly5DO9WN+QNxvbakUbMRqxtCXLJzTX8l7UY3i79pYwOvSlV9kOSW8Ka
	 5HeQe0IQB0eP1PvPnrSvWF62TWKbBeNvia3tcWJhxK2ArVaVUkhqE2bEQ9zxKfTuVA
	 irO4NP/fHAjWA==
Date: Fri, 6 Jun 2025 13:14:47 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Alejandro Vallejo , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    "Daniel P. Smith" , 
    Andrew Cooper , xen-devel@lists.xenproject.org
Subject: Re: [PATCH 10/19] x86: Replace boot_module with bootmodule
In-Reply-To: <6490abdd-ac7c-4178-a174-25d13065ae04@suse.com>
Message-ID: 
References:  <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-11-agarciav@amd.com> <214c8863-5cd4-4be9-948e-e44b67f541bd@citrix.com>  
 <6490abdd-ac7c-4178-a174-25d13065ae04@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 6 Jun 2025, Jan Beulich wrote:
> On 05.06.2025 19:40, Alejandro Vallejo wrote:
> > On Thu Jun 5, 2025 at 7:28 PM CEST, Alejandro Vallejo wrote:
> >> On Mon Jun 2, 2025 at 7:00 PM CEST, Andrew Cooper wrote:
> >>> On 30/05/2025 1:02 pm, Alejandro Vallejo wrote:
> >>>> These types resemble each other very closely in layout and intent, and
> >>>> with "struct bootmodule" already in common code it makes perfect sense
> >>>> to merge them. In order to do so, add an arch-specific area for
> >>>> x86-specific tidbits.
> >>>>
> >>>> Signed-off-by: Alejandro Vallejo 
> >>>
> >>> Yet this is a distinct backwards step in terms of legibility.
> >>>
> >>> How about modifying the common code to be more legible, rather than
> >>> regressing the x86 code.
> >>>
> >>> ~Andrew
> >>
> >> I meant to ifdef out the fields unused on x86, but after some massaging I
> >> think I got it lookin much nicer. It's essentially using the common parts of
> >> kernel_info and boot_domain as a header to kernel_info.
> >>
> >> That way, x86 keeps using a substantially smaller (yet common) data structure
> >> while the rest of dom0less can keep using the original as-is.
> >>
> >> Refactoring kernel_info to rationalise its contents is somewhere in my TODO
> >> list, but I have much more urgent fish to fry first.
> >>
> >> Cheers,
> >> Alejandro
> > 
> > ... I misread the comment and thought it was in the following patch rather than this one.
> > 
> > If it was indeed intended here, I'm at a loss as to what you'd rather do.
> > Common bindings need a common ground. This is such ground. The data structures
> > are virtually identical and used for identical purposes.
> > 
> > What's the legibility step you're talking about?
> 
> The loss of the underscore (separating the words) in the struct tag, aiui.

As I wrote in reply to the other patch, I would ask that we keep the
code movement and the renaming separate.

With that said, I don't mind a global s/bootmodule/boot_module/g across
the codebase, but please let's keep it as a separate patch to make it
easier to review.

However, we don't actually have a code style asking for _ in struct
tags. So while I don't mind the global s/bootmodule/boot_module/g, it
might be best we at least briefly discuss it as a group to make sure we
are all aligned.


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 20:24:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 20:24:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008849.1388011 (Exim 4.92)
	(envelope-from )
	id 1uNdcP-0003D6-0o; Fri, 06 Jun 2025 20:24:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008849.1388011; Fri, 06 Jun 2025 20:24: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 1uNdcO-0003Cz-U3; Fri, 06 Jun 2025 20:24:48 +0000
Received: by outflank-mailman (input) for mailman id 1008849;
 Fri, 06 Jun 2025 20:24: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 1uNdcN-0003Cm-Ex
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 20:24:47 +0000
Received: from mail132-4.atl131.mandrillapp.com
 (mail132-4.atl131.mandrillapp.com [198.2.132.4])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 49205a47-4314-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 22:24:46 +0200 (CEST)
Received: from pmta09.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail132-4.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4bDXqJ1QW5zlgJ81
 for ; Fri,  6 Jun 2025 20:24:44 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 aeed00e7af684050a1ed30281fe96756; Fri, 06 Jun 2025 20:24: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: 49205a47-4314-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1749241484; x=1749511484;
	bh=qWTqrUaJ22be3xQmtAEmq7viKiC+H8tahl5o7BAj8Pg=;
	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=OOLHcxROYxDFclRyRFTW6GgvQ3IIdSfKs9RPZKAVSOr7Hxr2hB0L+jicbTcWN+WaP
	 XcWsNyxCOCoJRF50v4FJ4/YxJkNAfVChi8AAafJiwdSmxbZdYZu7YnFdy2c0VSGg70
	 NyZHw9Ytw8XN2IBHdEblWpU9Vcd3TBni/w2foiPRFqVqCma4UDOafVGw4PdeFZmepd
	 WC8sBEXAXpya5NBCPO6Q2GuCaJRl9MQVMadsmsosroeCcs6ux1qPuWOlgbtv5FW7PH
	 W0ZQbcrTUsiEbulWKxvDMV7+sS+aRkvt+XWLZdmDA5plSkGUfXcLnyeO8ApCuVnyFk
	 ixkiuF3Ui3zww==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1749241484; x=1749501984; i=teddy.astie@vates.tech;
	bh=qWTqrUaJ22be3xQmtAEmq7viKiC+H8tahl5o7BAj8Pg=;
	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=akiWoQVAlRF5kRS80/BEmVIxStLHNW5VUNSxU+W65AbAbVusy42LioJDIKIPdn6SZ
	 sG3B6eRuroAgrmasl/hY0sz7U/jbWJvWXc3hycPzr1bjW08jKjIUgPM7qtqysorkOb
	 7wmKWIlILKrt20a+nRDa0IRP81qQJrb2keVwtjW+T1N/5h78HeP241y5IDgMFAL3V4
	 0OX69dPNWSgobo9Is+cWqgh2GEGYpqClPwmYu0/k/lNWC2WcEijI5jZV8jFU39Eab1
	 6lOw/xRwi+SjUI/USXzlxM2WN6iDfsmiGOL0D14Fj9XFhB1Y+R65svicaoHkaRNwrS
	 XQz525kHxQQNg==
From: "Teddy Astie" 
Subject: =?utf-8?Q?Re:=20[PATCH=20v1]=20xen/console:=20group=20pbuf=20under=20console=20field?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1749241482674
Message-Id: <00ffcc4b-b63e-4b4d-8b8f-8d02fb7ef234@vates.tech>
To: dmkhn@proton.me, xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
References: <20250606194937.2412579-1-dmukhin@ford.com>
In-Reply-To: <20250606194937.2412579-1-dmukhin@ford.com>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.aeed00e7af684050a1ed30281fe96756?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250606:md
Date: Fri, 06 Jun 2025 20:24:44 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hello,

Le 06/06/2025 =C3=A0 21:51, dmkhn@proton.me a =C3=A9crit=C2=A0:
> From: Denis Mukhin 
> 
> Group all pbuf-related data structures under domain's console field.
> 
> No functional change.
> 
> Signed-off-by: Denis Mukhin 
> ---
>   xen/arch/x86/hvm/hvm.c     | 14 +++++++-------
>   xen/common/domain.c        |  8 ++++----
>   xen/drivers/char/console.c | 19 +++++++++++--------
>   xen/include/xen/sched.h    | 12 ++++++------
>   4 files changed, 28 insertions(+), 25 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 4cb2e13046..17d1fd42ce 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -571,16 +571,16 @@ static int cf_check hvm_print_line(
>       if ( !is_console_printable(c) )
>           return X86EMUL_OKAY;
>   
> -    spin_lock(&cd->pbuf_lock);
> +    spin_lock(&cd->console.pbuf_lock);
>       if ( c !=3D '\n' )
> -        cd->pbuf[cd->pbuf_idx++] =3D c;
> -    if ( (cd->pbuf_idx =3D=3D (DOMAIN_PBUF_SIZE - 1)) || (c =3D=3D '\n')=
 )
> +        cd->console.pbuf[cd->console.pbuf_idx++] =3D c;
> +    if ( (cd->console.pbuf_idx =3D=3D (DOMAIN_PBUF_SIZE - 1)) || (c =3D=
=3D '\n') )
>       {
> -        cd->pbuf[cd->pbuf_idx] =3D '\0';
> -        guest_printk(cd, XENLOG_G_DEBUG "%s\n", cd->pbuf);
> -        cd->pbuf_idx =3D 0;
> +        cd->console.pbuf[cd->console.pbuf_idx] =3D '\0';
> +        guest_printk(cd, XENLOG_G_DEBUG "%s\n", cd->console.pbuf);
> +        cd->console.pbuf_idx =3D 0;
>       }
> -    spin_unlock(&cd->pbuf_lock);
> +    spin_unlock(&cd->console.pbuf_lock);
>   
>       return X86EMUL_OKAY;
>   }
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 153cd75340..dd1867b2fe 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -669,7 +669,7 @@ static void _domain_destroy(struct domain *d)
>       BUG_ON(!d->is_dying);
>       BUG_ON(atomic_read(&d->refcnt) !=3D DOMAIN_DESTROYED);
>   
> -    xfree(d->pbuf);
> +    xfree(d->console.pbuf);
>   
>       argo_destroy(d);
>   
> @@ -862,7 +862,7 @@ struct domain *domain_create(domid_t domid,
>       spin_lock_init(&d->shutdown_lock);
>       d->shutdown_code =3D SHUTDOWN_CODE_INVALID;
>   
> -    spin_lock_init(&d->pbuf_lock);
> +    spin_lock_init(&d->console.pbuf_lock);
>   
>       rwlock_init(&d->vnuma_rwlock);
>   
> @@ -956,8 +956,8 @@ struct domain *domain_create(domid_t domid,
>           goto fail;
>   
>       err =3D -ENOMEM;
> -    d->pbuf =3D xzalloc_array(char, DOMAIN_PBUF_SIZE);
> -    if ( !d->pbuf )
> +    d->console.pbuf =3D xzalloc_array(char, DOMAIN_PBUF_SIZE);
> +    if ( !d->console.pbuf )
>           goto fail;
>   
>       if ( (err =3D sched_init_domain(d, config->cpupool_id)) !=3D 0 )
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index 616f4968b0..3855962af7 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -769,22 +769,25 @@ static long guest_console_write(XEN_GUEST_HANDLE_PA=
RAM(char) buffer,
>               } while ( --kcount > 0 );
>   
>               *kout =3D '\0';
> -            spin_lock(&cd->pbuf_lock);
> +            spin_lock(&cd->console.pbuf_lock);
>               kcount =3D kin - kbuf;
>               if ( c !=3D '\n' &&
> -                 (cd->pbuf_idx + (kout - kbuf) < (DOMAIN_PBUF_SIZE - 1))=
 )
> +                 cd->console.pbuf_idx + kout - kbuf < DOMAIN_PBUF_SIZE -=
 1 )

I don't think we want to drop the parentheses here.

>               {
>                   /* buffer the output until a newline */
> -                memcpy(cd->pbuf + cd->pbuf_idx, kbuf, kout - kbuf);
> -                cd->pbuf_idx +=3D (kout - kbuf);
> +                memcpy(cd->console.pbuf + cd->console.pbuf_idx,
> +                       kbuf,
> +                       kout - kbuf);
> +                cd->console.pbuf_idx +=3D (kout - kbuf);
>               }
>               else
>               {
> -                cd->pbuf[cd->pbuf_idx] =3D '\0';
> -                guest_printk(cd, XENLOG_G_DEBUG "%s%s\n", cd->pbuf, kbuf=
);
> -                cd->pbuf_idx =3D 0;
> +                cd->console.pbuf[cd->console.pbuf_idx] =3D '\0';
> +                guest_printk(cd,
> +                             XENLOG_G_DEBUG "%s%s\n", cd->console.pbuf, =
kbuf);
> +                cd->console.pbuf_idx =3D 0;
>               }
> -            spin_unlock(&cd->pbuf_lock);
> +            spin_unlock(&cd->console.pbuf_lock);
>           }
>   
>           guest_handle_add_offset(buffer, kcount);
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index fe53d4fab7..637aa09ec4 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -562,12 +562,6 @@ struct domain
>       /* Control-plane tools handle for this domain. */
>       xen_domain_handle_t handle;
>   
> -    /* hvm_print_line() and guest_console_write() logging. */
> -#define DOMAIN_PBUF_SIZE 200
> -    char       *pbuf;
> -    unsigned int pbuf_idx;
> -    spinlock_t  pbuf_lock;
> -
>       /* OProfile support. */
>       struct xenoprof *xenoprof;
>   
> @@ -654,6 +648,12 @@ struct domain
>   
>       /* Console settings. */
>       struct {
> +        /* hvm_print_line() and guest_console_write() logging. */
> +#define DOMAIN_PBUF_SIZE 200
> +        char *pbuf;
> +        unsigned int pbuf_idx;
> +        spinlock_t pbuf_lock;
> +
>           /* Permission to take ownership of the physical console input. =
*/
>           bool input_allowed;
>       } console;


Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech




From xen-devel-bounces@lists.xenproject.org Fri Jun 06 20:34:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 20:34:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008857.1388021 (Exim 4.92)
	(envelope-from )
	id 1uNdlg-0004rQ-S0; Fri, 06 Jun 2025 20:34:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008857.1388021; Fri, 06 Jun 2025 20: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 1uNdlg-0004rJ-PP; Fri, 06 Jun 2025 20:34:24 +0000
Received: by outflank-mailman (input) for mailman id 1008857;
 Fri, 06 Jun 2025 20:34:23 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uNdlf-0004qR-Fq
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 20:34:23 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a04d5cf9-4315-11f0-a301-13f23c93f187;
 Fri, 06 Jun 2025 22:34:22 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 36CCE4A2E4;
 Fri,  6 Jun 2025 20:34:20 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1C4D1C4CEEB;
 Fri,  6 Jun 2025 20:34: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: a04d5cf9-4315-11f0-a301-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749242060;
	bh=DEGB4w7NTqmb4nl/oEsiOGm0rJ+4lnd18izXzzlo6Hk=;
	h=Date:From:To:cc:Subject:From;
	b=uZ5VREu1dKhklCl83ph1vrPXfD7ffzFUQdq6c/E8C2FG+hhBrCbiIOiIJH8dAPwUY
	 yXw+y+sMQ3t15r16n3qhtdVuFNODXgaomxr5mWq8Ybip6M7hlzQRR26Bo3jJXhRyNS
	 F6/38i1uQE5hha7eSktq1ZmY2Afy8G5MLRnmNnEltv8DF+DDB+o3sMT4lWvacn2DPa
	 LRhA7A89DRlUTxCbRf9XK58QgjXcBxYsUvk4sU2pbQq9HjzN4Pav8kUC27UhlKCf5V
	 4C8vbp++zId75SPJKw/OO+TvfZH6LrkfsquxwvDAdT7/Ixxg4Uf9pWCbzNbCHoyMIA
	 zEshGUEssdhJQ==
Date: Fri, 6 Jun 2025 13:34:17 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: xen-devel@lists.xenproject.org
cc: sstabellini@kernel.org, andrew.cooper3@citrix.com, 
    anthony.perard@vates.tech, michal.orzel@amd.com, jbeulich@suse.com, 
    julien@xen.org, roger.pau@citrix.com
Subject: [PATCH v3] xen: add header guards to generated asm generic headers
Message-ID: 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

MISRA D4.10 requires to have proper header guards in place in all header
files. Add header guards for generated asm generic headers as well.

Suggested-by: Jan Beulich 
Signed-off-by: Stefano Stabellini 
Acked-by: Jan Beulich 
---
Changes in v3:
- switch from printf to echo
---
 xen/scripts/Makefile.asm-generic | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/xen/scripts/Makefile.asm-generic b/xen/scripts/Makefile.asm-generic
index b0d356bfa3..b082801808 100644
--- a/xen/scripts/Makefile.asm-generic
+++ b/xen/scripts/Makefile.asm-generic
@@ -32,7 +32,14 @@ old-headers := $(wildcard $(obj)/*.h)
 unwanted    := $(filter-out $(generic-y) $(generated-y),$(old-headers))
 
 quiet_cmd_wrap = WRAP    $@
-      cmd_wrap = echo "\#include " > $@
+      cmd_wrap = \
+	arch=$$(echo $@ | sed -n 's:.*arch/\([^/]*\)/.*:\1:p' | tr a-z A-Z); \
+	upper=$$(echo $*.h | tr a-z A-Z | tr '/.' '__'); \
+	echo "\#ifndef $${arch}_GENERIC_$${upper}" > $@.new; \
+	echo "\#define $${arch}_GENERIC_$${upper}" >> $@.new; \
+	echo "\#include " >> $@.new; \
+	echo "\#endif /* $${arch}_GENERIC_$${upper} */" >> $@.new; \
+	mv -f $@.new $@
 
 quiet_cmd_remove = REMOVE  $(unwanted)
       cmd_remove = rm -f $(unwanted)
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Fri Jun 06 20:50:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 20:50:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008864.1388033 (Exim 4.92)
	(envelope-from )
	id 1uNe0p-0006tW-5e; Fri, 06 Jun 2025 20:50:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008864.1388033; Fri, 06 Jun 2025 20:50:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNe0p-0006t0-0t; Fri, 06 Jun 2025 20:50:03 +0000
Received: by outflank-mailman (input) for mailman id 1008864;
 Fri, 06 Jun 2025 20:50: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 1uNe0n-0006Zl-N6
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 20:50:01 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cf619af4-4317-11f0-a303-13f23c93f187;
 Fri, 06 Jun 2025 22:50:00 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 62A254A004;
 Fri,  6 Jun 2025 20:49:58 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 21248C4CEEB;
 Fri,  6 Jun 2025 20:49: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: cf619af4-4317-11f0-a303-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749242998;
	bh=xAy6gZUzwwIuy9i+E0bR+GSdhMng2kiIqWPC2S9quIk=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=kv6hC3yYXEo3j9YzmQZAzC46fIpzTdVbfy++M3Bcw5k8iGFmeJKFb7voDlU6QY6bn
	 jmWV25qqXF1EsJqJ/8e3ANtilF9HUsse6w6TfdnRc7huO2100IP8LvWmvIM1XOaiRJ
	 b7ZO4AamEZbJ9CqiB6ZldbI18xtnv8V0MCiZxGE3gMp3t18WL33ek2qKeSXxXV02eX
	 9+TQfsH5qVxy42lkKpJpKhG7xRF/+GXFA/upAOUHyIcgTagwreiOvl5w6sWhUzWdg5
	 OItIQDCddDwcsqoy1BeNq180akgMn4U5KqhyTj+R/42yeiJciSmZA0m9XTOfuA+3sR
	 f1irPngEc9BOw==
Date: Fri, 6 Jun 2025 13:49:56 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Nicola Vetrini 
cc: Stefano Stabellini , 
    Jan Beulich , 
    Stefano Stabellini , 
    Andrew Cooper , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Alessandro Zucchelli , 
    xen-devel@lists.xenproject.org, federico.serafini@bugseng.com
Subject: Re: [PATCH] x86: remove memcmp calls non-compliant with Rule
 21.16.
In-Reply-To: <13ad335c1868bcc02e2dc0a8da521f6d@bugseng.com>
Message-ID: 
References: <20250604233537.2892206-1-stefano.stabellini@amd.com>   <13ad335c1868bcc02e2dc0a8da521f6d@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, 6 Jun 2025, Nicola Vetrini wrote:
> > > > Signed-off-by: Alessandro Zucchelli 
> > > 
> > > Missing your own S-o-b.
> > > 
> > > Also (nit) may I ask that you drop the full stop from the patch subject?
> > 
> > I'll add the S-o-B and fix the subject
> > 
> > 
> > > > --- a/xen/arch/x86/dmi_scan.c
> > > > +++ b/xen/arch/x86/dmi_scan.c
> > > > @@ -233,7 +233,7 @@ void __init dmi_efi_get_table(const void *smbios,
> > > const void *smbios3)
> > > >  	const struct smbios_eps *eps = smbios;
> > > >  	const struct smbios3_eps *eps3 = smbios3;
> > > >
> > > > -	if (eps3 && memcmp(eps3->anchor, "_SM3_", 5) == 0 &&
> > > > +	if (eps3 && strncmp(eps3->anchor, "_SM3_", 5) == 0 &&
> > > 
> > > Unlike the last example given in the doc, this does not pose the risk of
> > > false "not equal" returns. Considering there's no example there exactly
> > > matching this situation, I'm not convinced a change is actually needed.
> > > (Applies to all other changes here, too.)
> > 
> > If we consider string literals "pointer types", then I think you are
> > right that this would fall under what is permitted by 21.16. Nicola,
> > what do you think?
> > 
> 
> While I agree that the result of the comparison is correct either way in these
> cases, the rule is written to be simple to apply (i.e., not limited only to
> those cases that may differ), and in particular in the rationale it is
> indicated that using memcmp to compare string *may* indicate a mistake. As
> written above, deviating the string literal comparisons is an option, which
> can be justified with efficiency concerns, but it goes a bit against the
> rationale of the rule itself.

Also looking at Andrew's reply, it seems that the preference is to
deviate string literals. The change to docs/misra/rules.rst is easy
enough, but I am not sure how to make the corresponding change to
analysis.ecl.

diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
index e1c26030e8..56b6e351df 100644
--- a/docs/misra/rules.rst
+++ b/docs/misra/rules.rst
@@ -813,7 +813,7 @@ maintainers if you want to suggest a change.
        shall point to either a pointer type, an essentially signed type,
        an essentially unsigned type, an essentially Boolean type or an
        essentially enum type
-     - void* arguments are allowed
+     - void* and string literals arguments are allowed
 
    * - `Rule 21.17 `_
      - Mandatory


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 21:04:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 21:04:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008878.1388042 (Exim 4.92)
	(envelope-from )
	id 1uNeF0-0000pP-AG; Fri, 06 Jun 2025 21:04:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008878.1388042; Fri, 06 Jun 2025 21:04: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 1uNeF0-0000pI-6j; Fri, 06 Jun 2025 21:04:42 +0000
Received: by outflank-mailman (input) for mailman id 1008878;
 Fri, 06 Jun 2025 21:04: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 1uNeEy-0000p9-Rz
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 21:04:40 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d94b8d4d-4319-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 23:04:35 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 1B5EB629D9;
 Fri,  6 Jun 2025 21:04:34 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9887FC4CEF1;
 Fri,  6 Jun 2025 21:04: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: d94b8d4d-4319-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749243873;
	bh=X8cYOL4YCMIKMC8uDJlrxH6w/ePZilNmWdJ2hhxLK8U=;
	h=Date:From:To:cc:Subject:From;
	b=WB5qk2004qx6eVgaTXdhl4aXvyTOvtYDFZ/sRLesYsRsJhy2iJ2OMBfsG8Ntaug6q
	 U/Y/MHM5ZhQ0d7kUpXtpG1tfCUkI6n4p3iJFUPM/EnLrHbYhEpSkDhAVPJ3BTRC2Rc
	 PPIFktCu69d6Bu2mLBZP/r+m0VvUDZ+Jzap4S4+AvfN4p6X3lwhGhbSGDTHAsbQTRf
	 BQ5CblkmA+2UtkR3jHSxk+CV9Qm99y27gw5XYAQFkmtZnXg3sriZnM8hdFxIKjjX/p
	 ntZjD7qdBovNUzLtN8QKvb34edKXDJYTn+0cfu4BActwJe2RSy/kgFng0x2bwOuGvP
	 Ybw7e/c/m0QdQ==
Date: Fri, 6 Jun 2025 14:04:32 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: xen-devel@lists.xenproject.org
cc: Andrew Cooper , 
    Stefano Stabellini , michal.orzel@amd.com, 
    jbeulich@suse.com, julien@xen.org, roger.pau@citrix.com, 
    sstabellini@kernel.org, bertrand.marquis@arm.com, 
    federico.serafini@bugseng.com, Nicola Vetrini 
Subject: [PATCH v4] automation/eclair: update configuration of D4.10
Message-ID: 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

MISRA C Directive 4.10 states that "Precautions shall be taken in order
to prevent the contents of a header file being included more than
once".

Add a SAF tag to the existing comment on top of cpufeatures.h.
Add a header inclusion guard to compile.h.

Update ECLAIR configuration to:
- extend existing deviation to other comments explicitly saying a file
  is intended for multiple inclusion;
- extend existing deviation to other autogenerated files;
- tag the guidelines as clean.

Update deviations.rst accordingly.

Signed-off-by: Federico Serafini 
Signed-off-by: Stefano Stabellini 
---
Changes in v4:
- remove deviation for
  xen/arch/{arm,x86}/include/generated/asm/\*
---
 automation/eclair_analysis/ECLAIR/deviations.ecl | 11 +++++++----
 automation/eclair_analysis/ECLAIR/tagging.ecl    |  1 +
 docs/misra/deviations.rst                        | 12 ++++++++++++
 xen/arch/x86/include/asm/cpufeatures.h           |  8 +++++---
 xen/include/xen/compile.h.in                     |  3 +++
 xen/tools/process-banner.sed                     |  5 +++++
 6 files changed, 33 insertions(+), 7 deletions(-)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index 9c67358d46..3b5bc87e1d 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -72,11 +72,14 @@ they are not instances of commented-out code."
 -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."
+-doc_begin="Files that are intended to be included more than once (and have
+a comment that says this explicitly) do not need to conform to the directive."
 -config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* This file is intended to be 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$)))"}
+-config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* Generated file, do not edit! \\*/$, begin-3...begin-2))"}
+-doc_end
+
+-doc_begin="Autogenerated files that do not need to conform to the directive."
+-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
diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl b/automation/eclair_analysis/ECLAIR/tagging.ecl
index f9da5d5f4d..b95f07feb0 100644
--- a/automation/eclair_analysis/ECLAIR/tagging.ecl
+++ b/automation/eclair_analysis/ECLAIR/tagging.ecl
@@ -23,6 +23,7 @@
 "MC3A2.D1.1||
 MC3A2.D2.1||
 MC3A2.D4.1||
+MC3A2.D4.10||
 MC3A2.D4.11||
 MC3A2.D4.14||
 MC3A2.R1.1||
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index fe0b1e10a2..63caa8f4a2 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -30,6 +30,18 @@ Deviations related to MISRA C:2012 Directives:
        not to add an additional encapsulation layer.
      - Tagged as `deliberate` for ECLAIR.
 
+   * - D4.10
+     - Files that are intended to be included more than once (and have
+       a comment that says this explicitly) do not need to conform to the
+       directive.
+     - Tagged as `safe` for ECLAIR.
+
+   * - D4.10
+     - There are autogenerated files that do not need to comply to the
+       directive.
+     - Tagged as `safe` for ECLAIR. Such files are:
+        - xen/include/generated/autoconf.h
+
    * - D4.10
      - Including multiple times a .c file is safe because every function or data item
        it defines would in (the common case) be already defined.
diff --git a/xen/arch/x86/include/asm/cpufeatures.h b/xen/arch/x86/include/asm/cpufeatures.h
index 9e3ed21c02..bd1f00f5d2 100644
--- a/xen/arch/x86/include/asm/cpufeatures.h
+++ b/xen/arch/x86/include/asm/cpufeatures.h
@@ -1,6 +1,6 @@
-/*
- * Explicitly intended for multiple inclusion.
- */
+/* This file is intended to be included multiple times. */
+/*#ifndef X86_CPUFEATURES_H */
+/*#define X86_CPUFEATURES_H */
 
 #include 
 
@@ -63,3 +63,5 @@ XEN_CPUFEATURE(USE_VMCALL,        X86_SYNTH(30)) /* Use VMCALL instead of VMMCAL
 
 /* Total number of capability words, inc synth and bug words. */
 #define NCAPINTS (FSCAPINTS + X86_NR_SYNTH + X86_NR_BUG) /* N 32-bit words worth of info */
+
+/*#endif X86_CPUFEATURES_H */
diff --git a/xen/include/xen/compile.h.in b/xen/include/xen/compile.h.in
index 3151d1e7d1..9206341ba6 100644
--- a/xen/include/xen/compile.h.in
+++ b/xen/include/xen/compile.h.in
@@ -1,3 +1,6 @@
+#ifndef XEN_COMPILE_H
+#define XEN_COMPILE_H
+
 #define XEN_COMPILE_DATE	"@@date@@"
 #define XEN_COMPILE_TIME	"@@time@@"
 #define XEN_COMPILE_BY		"@@whoami@@"
diff --git a/xen/tools/process-banner.sed b/xen/tools/process-banner.sed
index 56c76558bc..4cf3f9a116 100755
--- a/xen/tools/process-banner.sed
+++ b/xen/tools/process-banner.sed
@@ -12,3 +12,8 @@ s_(.*)_"\1\\n"_
 
 # Trailing \ on all but the final line.
 $!s_$_ \\_
+
+# Append closing header guard
+$a\
+\
+#endif /* XEN_COMPILE_H */
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Fri Jun 06 21:27:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 21:27:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008886.1388057 (Exim 4.92)
	(envelope-from )
	id 1uNebB-0003b8-8o; Fri, 06 Jun 2025 21:27:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008886.1388057; Fri, 06 Jun 2025 21:27:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNebB-0003aL-30; Fri, 06 Jun 2025 21:27:37 +0000
Received: by outflank-mailman (input) for mailman id 1008886;
 Fri, 06 Jun 2025 21:27: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 1uNebA-0003YS-9i
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 21:27:36 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20604.outbound.protection.outlook.com
 [2a01:111:f403:2415::604])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0d537d6e-431d-11f0-a303-13f23c93f187;
 Fri, 06 Jun 2025 23:27:32 +0200 (CEST)
Received: from MW4PR04CA0146.namprd04.prod.outlook.com (2603:10b6:303:84::31)
 by CY8PR12MB7434.namprd12.prod.outlook.com (2603:10b6:930:52::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.32; Fri, 6 Jun
 2025 21:27:26 +0000
Received: from SN1PEPF000252A1.namprd05.prod.outlook.com
 (2603:10b6:303:84:cafe::67) by MW4PR04CA0146.outlook.office365.com
 (2603:10b6:303:84::31) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.31 via Frontend Transport; Fri,
 6 Jun 2025 21:27:26 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SN1PEPF000252A1.mail.protection.outlook.com (10.167.242.8) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Fri, 6 Jun 2025 21:27:26 +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; Fri, 6 Jun
 2025 16:27:23 -0500
Received: from xsjvictlira50.xilinx.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 via Frontend
 Transport; Fri, 6 Jun 2025 16:27:23 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0d537d6e-431d-11f0-a303-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=p27fMDvd4gVQqfJBOEYh68yVDFJlGUhI6KPsrTKUeM+mre4TjBzghDOgxGyRpp3E/kxpXJ6Eda30zjWadmp01sMOVnarW9QT1qVRGvau99znBXQUsHiH837mgQAdk6jx9qvOKfc2a3tCGG81/KiYIVRuzV/vyYcAFQLejF97Sh4xq07+1I7cZObb/Rzjp/FsC/numrUWZk8SA33f3h1fCTr88ImR4Z2s1a/XMD3G4HOeBVAX1XJz/OzYl5NUjMh8gbCvcKAcm17n8FiOfTxXE7ifnI7b4C15GfApn9Pv9tR7P4uiMLP+JEiljvTfHN+jtwBFKnPg/kAYFzL/DGWOLw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=r93UQ2OGt46J18SmdFjIeojQ9Xy2SF7hXLY3jAZxNDo=;
 b=HPTdA9h3KZiycoPSvauL2NzAp7WnWjQFl19iMvkLOT8OAgWW5DUuTxOsa+SX7/HQG7Xrxtk1giDWpKbWXwmW7e1CZfrmXFFsN5f8VtSjuCEad7fG61QPkET+P6pWJxk7mG0raiHsThlNV+VPnyv7b0ygxp/ZVwbULPzqZLneIMMq12SItBXzfYlufzG5IvYSjkpV1F1FSp4+8qGNSZ+jPTUsTXw1/5jiiQATNYl4Arv3v0FaPhPb9ybveJKYKgXy5VrbhGRAoePlTF2io/pLU2deLthXah6MaQBLqD952OggkewxiI8C4mvZgVYe1mLvSJFs8NVml2z57W7ZQOt4sw==
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=r93UQ2OGt46J18SmdFjIeojQ9Xy2SF7hXLY3jAZxNDo=;
 b=OVjifLiLyB29OAS1EyEI9Ov2E+5tWbcJLgl005pnUwzbhLv8FRxb5RrKzYiJDR0jIZaRdb+uQND5ajxA6M6JcCAdKDIsLnkysJtDJBRBRolicN95TQYX9gIWhvF2CmY4cx4sx8GxP12PTLOvAigxxRVlQEDaaqq2YfaOEiCYtJ0=
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: 
To: 
CC: Nicola Vetrini , Victor Lira
	, Andrew Cooper , "Anthony
 PERARD" , Michal Orzel ,
	"Jan Beulich" , Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=83=C2=A9?= , "Stefano
 Stabellini" , Federico Serafini
	, Bertrand Marquis 
Subject: [PATCH v2 2/3] xen/arm: add missing noreturn attributes
Date: Fri, 6 Jun 2025 14:27:08 -0700
Message-ID: <20250606212712.1901838-2-victorm.lira@amd.com>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250606212712.1901838-1-victorm.lira@amd.com>
References: <20250606212712.1901838-1-victorm.lira@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB03.amd.com: victorm.lira@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF000252A1:EE_|CY8PR12MB7434:EE_
X-MS-Office365-Filtering-Correlation-Id: a66f60a9-c84c-48e4-d256-08dda540eeea
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|7416014|82310400026|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?S1lyVUhuZGxHbk1waFR6WW5RYlRIUkJxVXZSNUJ1Q01ETHhSYU1GblVKNXd1?=
 =?utf-8?B?Q1JhQ0FXRWxtVkFTaUhubnZwZUZmQzRGVStWSENIeEZXcUU1U1MwUGtRVmc4?=
 =?utf-8?B?cG9LcXBwM3FXUW9aVG81ZmJXQWpSdzJ6NHQ1RnZET3dHRnovM01rRlJrS3BK?=
 =?utf-8?B?OUV3R1A5MS9pQUFBWjdlN3k3a1FUZnpid2JsamlyYVEzSHBOYUQ3bHViaFRY?=
 =?utf-8?B?NkFOUkFRb3BrR0FiZmE5djcxeENZZ2FRWE5HMlNCeTdMKzBxTHZlVGhKcTI0?=
 =?utf-8?B?SEtUWStzUCtoRnpiK3Fya2hmV1ZDWWhoSE1mSkJKYktoeG9vVVFZUnZoNWw0?=
 =?utf-8?B?UWtxd25KMkF6b1R0MjkwYnFuaHRmMjF6aG8rK0tQRFluK09sZzhsWjJnZDFu?=
 =?utf-8?B?dzlPb3d4NEtLUlpZUUZPVGtBSmp3aEVaQlRUMGZPUmY5RDMrcHc0OU1wUkFi?=
 =?utf-8?B?SEEvQ0doQlllWFc1cUNIWGlGSGNxQ04yVHU4MWQyL0h1aGRCSWtJbktuY2E4?=
 =?utf-8?B?UVV5ZmtsdDZYNEhONFM0dytqRE9hb0p3cWtGQzNXVFdSMEZtWEF1am53QmFp?=
 =?utf-8?B?Kzc4NnhlZG5WVmpKazlRcE9kYzg2ZGFTOUdwWXBKcUpYYmQ0T25EeFE4YnRG?=
 =?utf-8?B?aFltZnp5S0poRnJUMllVTDhQMGUrdER2cGYzMGt5Zlg2NlBtemRWU1dLVnJM?=
 =?utf-8?B?QUpwbVBLUStuS3VVVk42ZnFSMkgrb3dvUFd2UDhSNDBpUDZkTFA1cFVCQksw?=
 =?utf-8?B?SkdBUm1pTjVPK3RLZU9LUGxXYXZrV0RNanZUc1UvTU50SFdLQ3lzNG44QllK?=
 =?utf-8?B?NDFtd1U0Um0ySCtqeEhraS84K3cwVjdtd1ZyQXdGTE90YS9HOHU2c0FUT0Uz?=
 =?utf-8?B?bklxN1BMcWdNSXo5dnlUQ2F0bEdpU3NIcnJ2Y2NEamdFZFpUV21qcTg1MG1J?=
 =?utf-8?B?KzBmaC82WHhuRExEMjJVa0tydTd3R1NaSldGY2NKY2RoYzlsT2ZROTM1aERR?=
 =?utf-8?B?SmpETXV4UFk1d3NVdWtLTjhLd3ZGVGlCdU1rYVpheE4zbFpRbEtEUDNZL1Rj?=
 =?utf-8?B?aWwxMVlsemVJSGI2Wjl2bFFya0ZSYVlVUlI0WGxDcEFYVWw5aUI0UXM5clEr?=
 =?utf-8?B?OWJKcXRPOGhNZUd3MUV5cGhKVTBkRWVTVVFqT3lUTm0xaytYZm4zNmc5TW1Z?=
 =?utf-8?B?MGxlQkZRQXJFUTJ0Ni9UdmZZZFJJaHRGNHBiZDRjVHJOMlVBY3FtaE9hNnFp?=
 =?utf-8?B?YXBoQ2lUeUt1TkgxTnpBQzN0M3ppem05V1ZkUldHbGlWbllRQ3BWUlgwejZF?=
 =?utf-8?B?RUhLbFFadWVHbnBxcE5uWWtFenRyL2xnci9kS3NmSzBrQ3N4VmpZb3BpSExU?=
 =?utf-8?B?MTVBMkoxZmZxTGNNOVdkdDJLZnVKaEd5NFI2MXJEdVVlOVlkVDBqdDZUOGpU?=
 =?utf-8?B?VWk5WmlCV25RRzlwQWJ4SVA5bGhCMSsyelRzMjNkTmFEZGRCRmg1WGZiR3Vs?=
 =?utf-8?B?Q3NmVXBJRE5qZi8xUjl2RFJGWE9NREN6Qmp2RG1BQmVrUDg0SEU5K3RTMXZ0?=
 =?utf-8?B?WC9hbWJmMlp4TnpXR3AyVXd0cFg0YnQ4eExUWjhMVW9LWElXQnZqcDZQbDhH?=
 =?utf-8?B?NVdhakJPakUwQ0FLUkIrcnU0NGhQeW1ZQmNLdGtYU2ZpazhuRVdsa2NrdVJq?=
 =?utf-8?B?cEQweHVoMng4bU9KbllrM2ZqMGhrVXZhY1ZzWkN5dVhjSVczbVp1YjYySWJy?=
 =?utf-8?B?ajVoVjJnZG1McjdEc0xtd3hwbFVTWjMvSGw0Wjl1ZElFOE1tR01PUVZRaUh3?=
 =?utf-8?B?VWUwdmdrVzcwVkIxb1l0YWdDTnhXZWZzOFJLVzY3bEVRNXFhMkVWM05KYkxC?=
 =?utf-8?B?enpvdHhpclY3SEMxdUhaT2ZOdDgxTm9KVVorYlBVMkloSjFYTHErK285T1Jm?=
 =?utf-8?B?SGdRU0NQMkVnSSt1R1NvNW9iR0d0UnZPVXQzMFh1SjQ1QU1KcDlSeVlyMkg3?=
 =?utf-8?B?SWgwaHlhcXdYQTNCZWo0dGNGdDNvZzVpWjl6dzI3SXBOcFJ2bEE5KzIrMUsx?=
 =?utf-8?Q?A4sUSD?=
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)(7416014)(82310400026)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jun 2025 21:27:26.0596
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: a66f60a9-c84c-48e4-d256-08dda540eeea
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:
	SN1PEPF000252A1.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7434

From: Nicola Vetrini 

The marked functions never return to their caller, but lack the
`noreturn' attribute.

Functions that never return should be declared with a `noreturn'
attribute.

The lack of `noreturn' causes a violation of MISRA C Rule 17.11 (not
currently accepted in Xen), and also Rule 2.1: "A project shall not
contain unreachable code". Depending on the compiler used and the
compiler optimization used, the lack of `noreturn' might lead to the
presence of unreachable code.

No functional change.

Signed-off-by: Nicola Vetrini 
Signed-off-by: Victor Lira 
---
Changes in v2:
- improved commit message
---
Cc: Andrew Cooper 
Cc: Anthony PERARD 
Cc: Michal Orzel 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Roger Pau Monné 
Cc: Stefano Stabellini 
Cc: Nicola Vetrini 
Cc: Federico Serafini 
Cc: Bertrand Marquis 
---
 xen/arch/arm/efi/efi-boot.h            | 2 +-
 xen/arch/arm/include/asm/arm64/traps.h | 2 +-
 xen/arch/arm/include/asm/processor.h   | 2 +-
 xen/arch/arm/setup.c                   | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
index d2a09ad3a1..ee80560e13 100644
--- a/xen/arch/arm/efi/efi-boot.h
+++ b/xen/arch/arm/efi/efi-boot.h
@@ -934,7 +934,7 @@ static void __init efi_arch_blexit(void)
         efi_bs->FreePool(memmap);
 }

-static void __init efi_arch_halt(void)
+static void noreturn __init efi_arch_halt(void)
 {
     stop_cpu();
 }
diff --git a/xen/arch/arm/include/asm/arm64/traps.h b/xen/arch/arm/include/asm/arm64/traps.h
index 3be2fa69ee..b7435c6e73 100644
--- a/xen/arch/arm/include/asm/arm64/traps.h
+++ b/xen/arch/arm/include/asm/arm64/traps.h
@@ -6,7 +6,7 @@ void inject_undef64_exception(struct cpu_user_regs *regs);
 void do_sysreg(struct cpu_user_regs *regs,
                const union hsr hsr);

-void do_bad_mode(struct cpu_user_regs *regs, int reason);
+void noreturn do_bad_mode(struct cpu_user_regs *regs, int reason);

 #endif /* __ASM_ARM64_TRAPS__ */
 /*
diff --git a/xen/arch/arm/include/asm/processor.h b/xen/arch/arm/include/asm/processor.h
index 9cbc4f9110..92c8bc1a31 100644
--- a/xen/arch/arm/include/asm/processor.h
+++ b/xen/arch/arm/include/asm/processor.h
@@ -571,7 +571,7 @@ extern register_t __cpu_logical_map[];
 #endif

 #ifndef __ASSEMBLY__
-void panic_PAR(uint64_t par);
+void noreturn panic_PAR(uint64_t par);

 /* Debugging functions are declared with external linkage to aid development. */
 void show_registers(const struct cpu_user_regs *regs);
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 734e23da44..ed72317af3 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -63,7 +63,7 @@ bool __read_mostly acpi_disabled;

 domid_t __read_mostly max_init_domid;

-static __used void init_done(void)
+static __used void noreturn init_done(void)
 {
     int rc;

--
2.25.1


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 21:27:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 21:27:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008887.1388072 (Exim 4.92)
	(envelope-from )
	id 1uNebF-00041m-IL; Fri, 06 Jun 2025 21:27:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008887.1388072; Fri, 06 Jun 2025 21:27: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 1uNebF-00041f-FE; Fri, 06 Jun 2025 21:27:41 +0000
Received: by outflank-mailman (input) for mailman id 1008887;
 Fri, 06 Jun 2025 21:27: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 1uNebD-0003tc-OL
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 21:27:39 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on2061a.outbound.protection.outlook.com
 [2a01:111:f403:2413::61a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0e87d69c-431d-11f0-b894-0df219b8e170;
 Fri, 06 Jun 2025 23:27:32 +0200 (CEST)
Received: from MW4PR04CA0121.namprd04.prod.outlook.com (2603:10b6:303:84::6)
 by DM4PR12MB6255.namprd12.prod.outlook.com (2603:10b6:8:a4::18) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.33; Fri, 6 Jun
 2025 21:27:27 +0000
Received: from SN1PEPF000252A1.namprd05.prod.outlook.com
 (2603:10b6:303:84:cafe::24) by MW4PR04CA0121.outlook.office365.com
 (2603:10b6:303:84::6) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.29 via Frontend Transport; Fri,
 6 Jun 2025 21:27:27 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SN1PEPF000252A1.mail.protection.outlook.com (10.167.242.8) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Fri, 6 Jun 2025 21:27:27 +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; Fri, 6 Jun
 2025 16:27:25 -0500
Received: from xsjvictlira50.xilinx.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 via Frontend
 Transport; Fri, 6 Jun 2025 16:27:24 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0e87d69c-431d-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=oMKL5dPCByndrIR0xjno/vYZVVsEOMtxgvbKIYn+qXKOPDvVX9AyBHDo4I2GoTsToQ1hY6MU9RevolTGPWJA3PPkr0m0jhAvsLkw+z7PkYTuiWCRPO3xTec6askLKLNkJRIuYSVdhP9ZfftUa1bhWgiZMkyn0FRlCZXDEObhoukeKJ4JjIoILLg2zqdpQPhhOJu17UlUiom+PbJ8W1BAErQRjx2P/yhSFX06+zSM2kvHqwkAWtF2+yDVudvVPrJg/97L2HxvlB21tUi3q+imN78hMMhRprj4DXVNfPbXStmL2UUijBQkb5J68RbCRzRPgU0VnDw23nPMzLRNIzxABA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=FX+Ldn95Q/8+1w/SZKDv25VhdZMtWs+GiRN7M+zwb8w=;
 b=VNX7h/l98FqrKdxxn7gcTmufi1rnQ6dBoRE6c7MzOr/ROJf2TbYJBsFswFLiK8P5uct2+9tw4wzxhlyIWE+NAh/I9+i0A7WbnItCkF4EHGnZMkWYJnjZMBegVbK4rO9GT0tjJELdW3ZGhSbsmqDOmPN0zLaCIHCMxRejo4SGtorBjivnAQuYx2/uVb9iYlvPbYauUAOOEqOslEfT0moPDYqC+JY+FM71l8znqeryAh4E7DLTdHDhM7AkVcSPs0xjaMro7fGTllig0a85i4gvidaCliL2B3mfEM6qGSAyzul/mul4tX0pmA7aGYXSLCnnqKOOvy2ufTrlNSe7cMrFbw==
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=FX+Ldn95Q/8+1w/SZKDv25VhdZMtWs+GiRN7M+zwb8w=;
 b=yFV4N6ZLPwJp37IqJXihqq1lp8Pm8+mO24cZuyZKxB88dRLWtJLxCfeL1MPx9zSyv4mQ5dGjqoKq4OgA6Fuf7lK6GjGL0fbQNoHhHrW2ZebEy+LtIJL8nHO7dnYcvPoSR8oV7Zo1F6107I/5XT1pikPkUbID9VfInUFk4+/URNc=
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: 
To: 
CC: Nicola Vetrini , Victor Lira
	, Andrew Cooper , "Anthony
 PERARD" , Michal Orzel ,
	"Jan Beulich" , Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=83=C2=A9?= , "Stefano
 Stabellini" , Federico Serafini
	, Bertrand Marquis 
Subject: [PATCH v2 3/3] xen/x86: add missing noreturn attributes
Date: Fri, 6 Jun 2025 14:27:09 -0700
Message-ID: <20250606212712.1901838-3-victorm.lira@amd.com>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250606212712.1901838-2-victorm.lira@amd.com>
References: <20250606212712.1901838-1-victorm.lira@amd.com>
 <20250606212712.1901838-2-victorm.lira@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB03.amd.com: victorm.lira@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF000252A1:EE_|DM4PR12MB6255:EE_
X-MS-Office365-Filtering-Correlation-Id: b8b8e0bc-bf8a-4939-20c1-08dda540ef7e
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|7416014|376014|36860700013|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?Q2M2TTRNaStpYzdwRDFwc2tYczJGWWsvZE1pMElYS1NySk0waFZ2U1lmMkZ5?=
 =?utf-8?B?ck8rUkJWdVkyektSeDRUNG9Jc3ZCZ2JuV05PYWdsandScXAyeWxwYmFFeHU2?=
 =?utf-8?B?UEZUZTl3R21EQUMxU0ZvcHBRUHp5c1NWVHVFRWxvd0tPeFhvTC9FdUpVMUFj?=
 =?utf-8?B?V2lKUzJZS0V6QjdsOVNUazd5bUhnUmdwa2JmUWVUL3E5UnZkTUNDaFREd1o0?=
 =?utf-8?B?OVpoODBmSGhXYmRqSXlLTmxMeWxua09mN2Ivc1psUTFBY2xwYlpBcUEzcGRj?=
 =?utf-8?B?blp6dTdTVG5BUkg2eHluanUwMkhMSDhHMVhYdFNIb29KaWFFVndwNi9neTFx?=
 =?utf-8?B?UUxZT0hLZHZtdXdwelQ3Wm51YWhhMzhZYzFVU2Q1TlcxcEMzdGNlTFRBTmdk?=
 =?utf-8?B?cDJUQnVBa0ZXOWVpck9EcitBc1JHdWJiWnd4bldicVJtbXdnUzNQbHRGdzIw?=
 =?utf-8?B?OGd6MVQ4YTFNNmsxYUxQZEN1YlE0RVU0eEZzakhjOTZpVU8wamVpNEFGNlow?=
 =?utf-8?B?a2Z4ZmQ5WDk0djhzano4TitaQUpvdDZ3bWczVExSVFlKMHJWc3c2RTh0QUVv?=
 =?utf-8?B?NlQvcmVVTW9reHYwaG9mSit0cjgzUGhsSjk1Qjh1dkZzcTJDVkQvaE04U3RY?=
 =?utf-8?B?ZTEwbE8vY3FZdkFoU2NobCt4RWJVS2x3V1QwNjh6NUs0NzJVdnVVbXZ3Y0JW?=
 =?utf-8?B?QmtiVThoL0ZhZnBReUsxM1k0bjlmNHJuWXR0bE4vTTVMY3VLaHZ3WnZkdUdm?=
 =?utf-8?B?QjlLdkEzVTNyaHBueUhRU29sV3o4N00ySXR3Q0xWN1EzekE2N2FLNGhKa29Q?=
 =?utf-8?B?S0dpQkV0UWVDNDhsWTNwVkZzNnBaVlBFUHNJY2pJelp3MVNYam5NTmlGQWFv?=
 =?utf-8?B?ZUJkUmQ4dkhBSVllNVdoalVoRCs5TU96SjMrWTNNNnZrdS85bFI0ZVRXTlhZ?=
 =?utf-8?B?dUFvUUh0UWkwYUlEdk92KzlRS3lyVVViYlBFNkRHUDZjRVRlYWFnZjFZNTRu?=
 =?utf-8?B?KzAzYXNoMWdTMUlmNmFId2ZrRGlqbll0b040OGNXc0FWRW5lMnFNbVovMEtU?=
 =?utf-8?B?K3o2OEVHNlJIWmViaUp4dkNTbUYxUGd1NllZdDNDNVJObHRMWTNVUklWN2FJ?=
 =?utf-8?B?cHpVZEpsZmlVZm91ZVZCb2szV3BNcGVmT3RWU1JmUFJYVVFjYWgyWEpsKzFX?=
 =?utf-8?B?UlQrbktWd1JvUEIzTll4R3JFb0VwSjd6QXBWTnNYY0FvZUtGT0hFaFdwRytO?=
 =?utf-8?B?ZEw5a01KT0lwTjd4WjM5Nm5mVlhVcWlNaGIrbGJldUdxRUFLem1xMC9KMnlh?=
 =?utf-8?B?ZDZ6azl6OEhQTUZBTU9jS243Rm43RzRFeW1HaFdJK3hMN0VJMjdHZVQ0Mndm?=
 =?utf-8?B?dHdZTGIwZ3hVdEJrU0FvR0F1Q2YrTnp6ZHpHSy8yeGtOdmtrYS9YWUFEWHgy?=
 =?utf-8?B?YklVRVFkNjVaMHp2eWo5MnNQdFFmYkVHSFVkSUQvZFVLT2RzRFhwb2cwelZH?=
 =?utf-8?B?ZXZkN0FmU1NUcFVRYmpPQkEyb0YxUnNhNlliMlFvQjcyMVNwUytvTm8rOXFE?=
 =?utf-8?B?UllibStxWHdmK1FRRHk4RGVEaEJ4eEJzUGcwenBZZjRycnhsL2lnanozNm5p?=
 =?utf-8?B?MlIyOSt0MjhWL0pNYlY0MmJKY3h3bzdsaGdlRzNjM0NNSnYrMkttek9CYzFK?=
 =?utf-8?B?NkFsd0NYNU9NYXNaOUJZT1J0a2h6bFZsaWRJZG05TFduNUYyNm1EUmpvMmJF?=
 =?utf-8?B?T0J5R2JVeFp4WTJQUG9WWkVWVCtIVlgwbyt1V2lZTWVmczVGdE9xZ1N1UjRh?=
 =?utf-8?B?TFY3UGJ5cUlNN0xuZElsTkI3bjltbkdsMWJBZk9LaHd0SGZRVGNoMjVROUlo?=
 =?utf-8?B?bmtxQ0J6bXQ3Q1Uwa3FTbEh2bzNOYVRLWmVYOXlGNW90Nnlhbnd4Ny9JS1hj?=
 =?utf-8?B?Sy9Pdldyc1V1NG4wcm1BNEFzQzgyL3RnWWdFZ0JXL1ZhMkFGREJHR1F2UUNI?=
 =?utf-8?B?SVBVdUhrTWFzdVlwbWRtZTZ4NGxtUWFoMFVmTnhGc0h6K3NhSWxCejVOU1Fr?=
 =?utf-8?Q?UOyKhP?=
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);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jun 2025 21:27:27.0249
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b8b8e0bc-bf8a-4939-20c1-08dda540ef7e
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:
	SN1PEPF000252A1.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6255

From: Nicola Vetrini 

The marked functions never return to their caller, but lack the
`noreturn' attribute.

Functions that never return should be declared with a `noreturn'
attribute.

The lack of `noreturn' causes a violation of MISRA C Rule 17.11 (not
currently accepted in Xen), and also Rule 2.1: "A project shall not
contain unreachable code". Depending on the compiler used and the
compiler optimization used, the lack of `noreturn' might lead to the
presence of unreachable code.

No functional change.

Signed-off-by: Nicola Vetrini 
Signed-off-by: Victor Lira 
---
Changes in v2:
- improved commit message
---
Cc: Andrew Cooper 
Cc: Anthony PERARD 
Cc: Michal Orzel 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Roger Pau Monné 
Cc: Stefano Stabellini 
Cc: Nicola Vetrini 
Cc: Federico Serafini 
Cc: Bertrand Marquis 
---
 xen/arch/x86/cpu/mcheck/mce.c | 3 ++-
 xen/arch/x86/efi/efi-boot.h   | 2 +-
 xen/arch/x86/smp.c            | 2 +-
 xen/arch/x86/traps.c          | 2 +-
 xen/arch/x86/x86_64/traps.c   | 2 +-
 5 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 1c348e557d..79214ce56b 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -79,7 +79,8 @@ static int __init cf_check mce_set_verbosity(const char *str)
 custom_param("mce_verbosity", mce_set_verbosity);

 /* Handle unconfigured int18 (should never happen) */
-static void cf_check unexpected_machine_check(const struct cpu_user_regs *regs)
+static void noreturn cf_check
+unexpected_machine_check(const struct cpu_user_regs *regs)
 {
     console_force_unlock();
     printk("Unexpected Machine Check Exception\n");
diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
index 0ecf4ca53f..0194720003 100644
--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -769,7 +769,7 @@ static void __init efi_arch_blexit(void)
         efi_bs->FreePages(ucode.addr, PFN_UP(ucode.size));
 }

-static void __init efi_arch_halt(void)
+static void noreturn __init efi_arch_halt(void)
 {
     local_irq_disable();
     for ( ; ; )
diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c
index 516dab5528..7936294f5f 100644
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -343,7 +343,7 @@ void __stop_this_cpu(void)
     cpumask_clear_cpu(smp_processor_id(), &cpu_online_map);
 }

-static void cf_check stop_this_cpu(void *dummy)
+static void noreturn cf_check stop_this_cpu(void *dummy)
 {
     const bool *stop_aps = dummy;

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 092c7e4197..34dc077cad 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -805,7 +805,7 @@ void fatal_trap(const struct cpu_user_regs *regs, bool show_remote)
           (regs->eflags & X86_EFLAGS_IF) ? "" : " IN INTERRUPT CONTEXT");
 }

-void asmlinkage do_unhandled_trap(struct cpu_user_regs *regs)
+void asmlinkage noreturn do_unhandled_trap(struct cpu_user_regs *regs)
 {
     fatal_trap(regs, false);
 }
diff --git a/xen/arch/x86/x86_64/traps.c b/xen/arch/x86/x86_64/traps.c
index c77f304bb0..8460a4a1ae 100644
--- a/xen/arch/x86/x86_64/traps.c
+++ b/xen/arch/x86/x86_64/traps.c
@@ -293,7 +293,7 @@ void show_page_walk(unsigned long addr)
            l1_table_offset(addr), l1e_get_intpte(l1e), pfn);
 }

-void asmlinkage do_double_fault(struct cpu_user_regs *regs)
+void asmlinkage noreturn do_double_fault(struct cpu_user_regs *regs)
 {
     unsigned int cpu;
     struct extra_state state;
--
2.25.1


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 21:27:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 21:27:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008885.1388052 (Exim 4.92)
	(envelope-from )
	id 1uNebB-0003Yl-0A; Fri, 06 Jun 2025 21:27:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008885.1388052; Fri, 06 Jun 2025 21:27:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNebA-0003Ye-Sq; Fri, 06 Jun 2025 21:27:36 +0000
Received: by outflank-mailman (input) for mailman id 1008885;
 Fri, 06 Jun 2025 21:27: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 1uNeb9-0003YS-Ua
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 21:27:36 +0000
Received: from NAM04-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam04on20613.outbound.protection.outlook.com
 [2a01:111:f403:240a::613])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0e810917-431d-11f0-a303-13f23c93f187;
 Fri, 06 Jun 2025 23:27:34 +0200 (CEST)
Received: from MW4PR04CA0143.namprd04.prod.outlook.com (2603:10b6:303:84::28)
 by BL3PR12MB6643.namprd12.prod.outlook.com (2603:10b6:208:38f::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.37; Fri, 6 Jun
 2025 21:27:25 +0000
Received: from SN1PEPF000252A1.namprd05.prod.outlook.com
 (2603:10b6:303:84:cafe::26) by MW4PR04CA0143.outlook.office365.com
 (2603:10b6:303:84::28) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.33 via Frontend Transport; Fri,
 6 Jun 2025 21:27:24 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SN1PEPF000252A1.mail.protection.outlook.com (10.167.242.8) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Fri, 6 Jun 2025 21:27:23 +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; Fri, 6 Jun
 2025 16:27:22 -0500
Received: from xsjvictlira50.xilinx.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 via Frontend
 Transport; Fri, 6 Jun 2025 16:27:22 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0e810917-431d-11f0-a303-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=wBD30eMPy3TePdkw1d8L9N+fPYHq+lG9Uq4kPtKX7+Qf1xWKfzPPuaYsqQJAt1/KaVqHZZM33NE5M+0uEcIfBL3VQGnvlJ47cIFMNhUNzuNwiDWrcGiOvBbK4ABuOa0TeVyY2AUMK5J4Nxg3Ci5EQcLc9Q2jSw7ykf5z10mdPIOz6Q2e8evFB2RbWDPNpt+PIRTPAR6YpzHU88kJ/INmBiq92qmbAunNT1pSzMjJjunBvOVePoXzv3fVRaOm1KfCYBn+YNV8qTjQXX2lmMb3ZAmBqhajyKiI7r8M40ibovn6QUxJ1NCBsHdV4QPXC05WnxUkj8Dl9mBe43tgzqNa9w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=N5YW/b3b+f5TMgHQiFZZLzwDRl6w9W7KsuqV06/eSyM=;
 b=NdLzZ9+lP1mNSZjJ8+jcwEAWsKVQijgrbHhff9bhXfEmzx9dGtr/yqXzxd3DvcT/bp3Sup1j29Kos8oOlh+2ulmMnZK+rBjBapTxwqI9V+0LpBstM2RkV7l1PKUjUAtpACvHqOngAChB5m8HMtucf5yAbyXvsJ3Re+jVRDRT/zb2auVNi5qg0nH8CdmBfidBW862N+IbR0KFexJdPvPhN2kRajYgBxXT4VugscokgKj1aqoKbg5WIL4M2L8j1cy6+baX8Ct3BLx9t69Hbebme3BaIUPWTPHht/XJTc9vllXb6Rrk3k81F29JYok3UN8iFiBKW7aGGzoxEt/Ef1qUhg==
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=N5YW/b3b+f5TMgHQiFZZLzwDRl6w9W7KsuqV06/eSyM=;
 b=0qLA/3c9avhq9NxIgo2krWk/94mjkoXFNKOZ9b7vxOkjJxi0rUQOX5N3kryuUkf4lrYvKuQnGF2SCCfVt5dMQWo4Efx+b3B11O7y9gyAjptUlKULesPPhIYk9FW3SUcwzpX7qR7Ro1dG5L2+MmWZgxUQxvycy5y5PoXMRtgm2rY=
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: 
To: 
CC: Nicola Vetrini , Victor Lira
	, Andrew Cooper , "Anthony
 PERARD" , Michal Orzel ,
	"Jan Beulich" , Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=83=C2=A9?= , "Stefano
 Stabellini" , Federico Serafini
	, Bertrand Marquis 
Subject: [PATCH v2 1/3] xen/keyhandler: add missing noreturn attribute
Date: Fri, 6 Jun 2025 14:27:07 -0700
Message-ID: <20250606212712.1901838-1-victorm.lira@amd.com>
X-Mailer: git-send-email 2.47.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB03.amd.com: victorm.lira@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF000252A1:EE_|BL3PR12MB6643:EE_
X-MS-Office365-Filtering-Correlation-Id: 246bdf8d-3111-4185-254f-08dda540ed62
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|1800799024|7416014|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?cGx1YStBSGZDQlQvaER5N1ZpTWM3TGlqWVE5UkU2VHdOMVlqM2kwaVhTbEJQ?=
 =?utf-8?B?Ly94c0FJN2QyS2JWQjcvZzdHNkt4ckFwb3V5bWFVT3ZqRExtczNjVlE3TnlZ?=
 =?utf-8?B?TFVERUoxUHFkZFo0V040akRTOFdmWTZoWGF4Q08rSTZPeTVNTDZwSmtQaXhm?=
 =?utf-8?B?V09ldEFVbGlZK2E0V2o1WW9uRW4xNDhxQXhOSzd6dWo3dDFtbmtScjhmMzRJ?=
 =?utf-8?B?VGlQV0x2Q2k4NXpaUytnOVdURTVDYWlhc2JHWEp2aDJzajNrdUxKK29mWFFJ?=
 =?utf-8?B?a0grN0puZ053TitOb2lxM2RseHByektWMk9VS3JyelRoeXFLNEdLeVlEODlk?=
 =?utf-8?B?TGo4ZUh0eTRDYVBvYlMwL2ZhcWVGZWxrZnFFZUlRWUdmUkRmK0ZmRmdkd1Yz?=
 =?utf-8?B?bnkzM1l1RG1kclBjOUMwR2UreXBiTG15NkpVZTBjS2QyMGtmY09lOGRmL0p3?=
 =?utf-8?B?eERZQTBzZ05Ma1p3Z1p6bXpkRU5oV0NSMGorSkN3ZWZFVEU2d25wTEsyWkZS?=
 =?utf-8?B?M1hYNlo4R0l3VEJWUWExam1oWFh3elJRU0IyWHo1MU9URnhuMnR5Ky9qS1RF?=
 =?utf-8?B?eTdjcktoYmYxemgwWDFSLzgvK2d5RjNpalhCYUJJYkNKNjN4eWczYWVmSFVY?=
 =?utf-8?B?SXJtaEdLc0xUbVB1dFdJckIrbFJPUzVXeWRyT0hRS2tkU2ZSZ1psOFZnbW0z?=
 =?utf-8?B?dE05UUNRbXdPZ1FGNXVyNUNleU5UZmVnV1QrK1paSUU2eEFvaklsSDRkaDVx?=
 =?utf-8?B?WVhvL2V6dy8wZzdUV3MyV1dNbDNmdGFiYmtBS29VcUFIUXMvdW9mVmV0ZlhD?=
 =?utf-8?B?WDZXTVB2bXc3MkZyUCtCV0VMYmZDYTFSSkJ6WkpXejdiYjcvTmQwVmFMRm5S?=
 =?utf-8?B?cVB0dzdyZm1OQklnWFZuSWdBVGMzbmN2ZVB1NFRLRHJCVUlHSmE2R2xLVXBi?=
 =?utf-8?B?a1VqSmt1TTRqQzBLRS9RZnRrY1ZrNzdseW9QYnQwYXBGUnRzekhKRWNpNWJn?=
 =?utf-8?B?RkVrbGJvK0hNcUJBZmVCbkpXb2NtelN4bXlFUUtkd25RUzB0SDZVdmxYZ25C?=
 =?utf-8?B?dDlLSDhxOFlhSmYyNWttanFEYWVLekRBTEpEQnpVTUlQV3dHalJtd1p6alRn?=
 =?utf-8?B?NENSMnhRWkJ0dTZhclpHc3JBTjBwVUtMa1drRnpwb0x2b0tzMEMydGV5WTZ5?=
 =?utf-8?B?L2RHSGRZditTMWZubGgvUTVuWVZxNXpNWjY4Yy9jQmc5VlVDRi9uazFnbkJz?=
 =?utf-8?B?YkUzdGpHNTlpbjc2VVYwVk94SjZrN0F4VHpNSDV6ajRmQitPcCtwek9SczFR?=
 =?utf-8?B?ajBGT2pEcjJQOWxGcHdiVU5LTFpnV2pDQ1JKWHAxSldXaWdnb1FMdUEvaFJi?=
 =?utf-8?B?VTNpcGJJQnZVdDFxQ1p0RjdEVWppZFZXMk5SWVdmU3RDenFVc0M0SG5KMy9a?=
 =?utf-8?B?b3RUZ29KOFlHVlZJSVRJM0drK2hjOHlNVnI1TklORFhDdjdiWGR6SW9RYVVq?=
 =?utf-8?B?Q0FtaEFZT1JidWVlV3ZuU1FMMGVoMnpvU2E4Wm05MW8wR3lpcjRrWkpxSWs2?=
 =?utf-8?B?bWxST0ozZkQ4YVQ5bkhQSVVVR0pNYW1zY3hPaEs3anpqUTZsLzRwRjdUeVZQ?=
 =?utf-8?B?K0hrOExRK0tnUnl4MEFza3l2UmxpeExyK21jQnpFNnlrQUJIdU5qNkMzY1FQ?=
 =?utf-8?B?ZWtHeFhmT3RkaTlIWWZURmZ0dDI2dVdwN1plakJObGZwamhwVWRrdTZuOG1h?=
 =?utf-8?B?NFNpNWw5TTkvUXFLcWxzZ0FKYWZ3WmNEc2VDK3ZKYTBpd3dGWlZQQVMweFYw?=
 =?utf-8?B?N1ArUkw5Wmk0cW8xN1RTY2JxcndOYVVuOVBPZG1rUmd3cWx1cGFtZlkvbUVM?=
 =?utf-8?B?eTg5ZE1Ya29iVkV0YXYwL0MzcVcvaXBzaTB4dnprc3Z1OE5kWXdhNllJOUhW?=
 =?utf-8?B?ZjN2VlFHM3FsMTgxYml0cTkrdXlNQUREOUFGS2FVb2R0L010VVEzNE1rWDJ4?=
 =?utf-8?B?akpRakZlUzZRZHJEL2lVMnliRHZiMmx5STVkaC8rT0lHcXZta0dBT3g1MkpG?=
 =?utf-8?Q?sJKB80?=
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)(7416014)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jun 2025 21:27:23.4867
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 246bdf8d-3111-4185-254f-08dda540ed62
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:
	SN1PEPF000252A1.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL3PR12MB6643

From: Nicola Vetrini 

Function `reboot_machine' does not return, but lacks the `noreturn'
attribute.

Functions that never return should be declared with a `noreturn'
attribute.

The lack of `noreturn' causes a violation of MISRA C Rule 17.11 (not
currently accepted in Xen), and also Rule 2.1: "A project shall not
contain unreachable code". Depending on the compiler used and the
compiler optimization used, the lack of `noreturn' might lead to the
presence of unreachable code.

No functional change.

Signed-off-by: Nicola Vetrini 
Signed-off-by: Victor Lira 
---
Changes in v2:
- improved commit message
---
Cc: Andrew Cooper 
Cc: Anthony PERARD 
Cc: Michal Orzel 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Roger Pau Monné 
Cc: Stefano Stabellini 
Cc: Nicola Vetrini 
Cc: Federico Serafini 
Cc: Bertrand Marquis 
---
 xen/common/keyhandler.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index 0bb842ec00..b0a2051408 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -251,7 +251,7 @@ static void cf_check dump_hwdom_registers(unsigned char key)
     }
 }

-static void cf_check reboot_machine(unsigned char key, bool unused)
+static void noreturn cf_check reboot_machine(unsigned char key, bool unused)
 {
     printk("'%c' pressed -> rebooting machine\n", key);
     machine_restart(0);
--
2.25.1


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 21:29:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 21:29:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008910.1388082 (Exim 4.92)
	(envelope-from )
	id 1uNedH-0005AY-Vf; Fri, 06 Jun 2025 21:29:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008910.1388082; Fri, 06 Jun 2025 21:29:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNedH-0005AP-RU; Fri, 06 Jun 2025 21:29:47 +0000
Received: by outflank-mailman (input) for mailman id 1008910;
 Fri, 06 Jun 2025 21:29:46 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uNedG-0005AC-3V
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 21:29:46 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uNedF-005Qr9-1K;
 Fri, 06 Jun 2025 21:29:45 +0000
Received: from [2a02:8012:3a1:0:7807:532b:1d1d:b850]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uNedF-00DlA1-1x;
 Fri, 06 Jun 2025 21:29: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" 
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=9MZAmwPMX6E6UhQcBqbToxnHspEw0+bZS2FT2iZhTrM=; b=sHUZxim7am7U6zsb59BZvxlsmb
	MhTm9Bsc+mEPz+YxkyNoobd7lpGZ+GXblz92t5+TXovYUXPIh0VJGpYIRDq3Q8jXVkDggdCPz6RJS
	FM1otTGmLej69y/H0XvZXWCKu/3ZrM1yYhMQKshKg9Gc27U/t6d+3rQ5fqdrLTo8+Tsg=;
Message-ID: 
Date: Fri, 6 Jun 2025 22:29:43 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 2/3] xen/domain: adjust domain ID allocation for Arm
Content-Language: en-GB
From: Julien Grall 
To: dmkhn@proton.me, xen-devel@lists.xenproject.org,
 Jan Beulich 
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech,
 roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech,
 dmukhin@ford.com
References: <20250528225030.2652166-1-dmukhin@ford.com>
 <20250528225030.2652166-3-dmukhin@ford.com>
 <63087c42-d709-4e53-a2c3-8b812f13190a@xen.org>
In-Reply-To: <63087c42-d709-4e53-a2c3-8b812f13190a@xen.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Denis,

On 05/06/2025 23:05, Julien Grall wrote:
> Hi Denis,
> 
> On 28/05/2025 23:50, dmkhn@proton.me wrote:
>> From: Denis Mukhin 
>>
>> From: Denis Mukhin 
>>
>> Remove the hardcoded domain ID 0 allocation for hardware domain and 
>> replace it
>> with a call to get_initial_domain_id() (returns the value of 
>> hardware_domid on
>> Arm).
> 
> I am not entirely why this is done. Are you intending to pass a 
> different domain ID? If so...
> 
>>
>> Update domid_alloc(DOMID_INVALID) case to ensure that 
>> get_initial_domain_id()
>> ID is skipped during domain ID allocation to cover domU case in dom0less
>> configuration. That also fixes a potential issue with re-using ID#0 
>> for domUs
>> when get_initial_domain_id() returns non-zero.
>>
>> Signed-off-by: Denis Mukhin 
>> ---
>> Changes since v8:
>> - rebased
>> ---
>>   xen/arch/arm/domain_build.c             | 4 ++--
>>   xen/common/device-tree/dom0less-build.c | 9 +++------
>>   xen/common/domain.c                     | 4 ++--
>>   3 files changed, 7 insertions(+), 10 deletions(-)
>>
>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> index e9d563c269..0ad80b020a 100644
>> --- a/xen/arch/arm/domain_build.c
>> +++ b/xen/arch/arm/domain_build.c
>> @@ -2035,9 +2035,9 @@ void __init create_dom0(void)
> 
> ... naming like create_dom0() probably wants to be renamed.
> 
> That said, I am not convinced a domain other than 0 should have full 
> privilege by default. So I would argue it should stay as ...
> 
>>       if ( !llc_coloring_enabled )
>>           flags |= CDF_directmap;
>> -    domid = domid_alloc(0);
>> +    domid = domid_alloc(get_initial_domain_id());
> 
> ... 0.

Looking at the implementation of get_initial_domain_id(), I noticed the 
behavior was changed for x86 by [1].

Before, get_initial_domain_id() was returning 0 except for the PV shim.
But now, it would could return the domain ID specified on the command 
line (via hardware_dom).

 From my understanding, the goal of the command line was to create the 
hardware domain *after* boot. So initially we create dom0 and then 
initialize the hardware domain. With the patch below, this has changed.

However, from the commit message, I don't understand why. It seems like 
we broke late hwdom?

For instance, late_hwdom_init() has the following assert:

     dom0 = rcu_lock_domain_by_id(0);
     ASSERT(dom0 != NULL);

Jan, I saw you were involved in the review of the series. Any idea why 
this was changed?

Cheers,

[1] https://lore.kernel.org/all/20250306075819.154361-1-dmkhn@proton.me/

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Fri Jun 06 23:07:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 23:07:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008963.1388092 (Exim 4.92)
	(envelope-from )
	id 1uNg9W-0000Jd-Tc; Fri, 06 Jun 2025 23:07:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008963.1388092; Fri, 06 Jun 2025 23:07:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNg9W-0000JQ-OP; Fri, 06 Jun 2025 23:07:10 +0000
Received: by outflank-mailman (input) for mailman id 1008963;
 Fri, 06 Jun 2025 23:07: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 1uNg9U-0000JK-73
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 23:07:09 +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 f6b16186-432a-11f0-b894-0df219b8e170;
 Sat, 07 Jun 2025 01:07:05 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f6b16186-432a-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1749251224; x=1749510424;
	bh=qbaqTN/mef++TeA9JmNKxIFqEwBNLbAgRNs6naITzf0=;
	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=Y5RZ1nVoSUlHhYsCSs0lFQ1GF/dJ99RjG19Y0SRlFYcRiEz1eFlxSnx0Z+cpyORV3
	 UYQZ5c4+VG/Gv+ucF3qIbeeTvKw1jKVRoaSSSKMsjT4XkIvwpbmZ4vr3AvQU8yPDEJ
	 quzPFWFJwaLKSa4HM9VETXS3jC6tqJnFT4Wi5SgYQx+YfQCOucP/yNTYicjsNIwrcY
	 qbrCqzliHJ/bWiNkwpOtm9Sq6H/ViBJ7zVgzqwxChydqC85ZYdnfTmj2w4Tdh/i1Ut
	 xep/2Wp4R9oGXZLMuD4FgP1PzzAAG+sW6c4gu3fschWS9tk0eT2PY8LiLDyL68RwkJ
	 xQmvz87VTjfaQ==
Date: Fri, 06 Jun 2025 23:06:57 +0000
To: Teddy Astie 
From: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: Re: [PATCH v1] xen/console: group pbuf under console field
Message-ID: 
In-Reply-To: <00ffcc4b-b63e-4b4d-8b8f-8d02fb7ef234@vates.tech>
References: <20250606194937.2412579-1-dmukhin@ford.com> <00ffcc4b-b63e-4b4d-8b8f-8d02fb7ef234@vates.tech>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 36aa3f7d241158689357caf906bfc4bce5689522
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 06, 2025 at 08:24:44PM +0000, Teddy Astie wrote:
> Hello,
>=20
> Le 06/06/2025 =C3=A0 21:51, dmkhn@proton.me a =C3=A9crit=C2=A0:
> > From: Denis Mukhin 
> >
> > Group all pbuf-related data structures under domain's console field.
> >
> > No functional change.
> >
> > Signed-off-by: Denis Mukhin 
> > ---
> >   xen/arch/x86/hvm/hvm.c     | 14 +++++++-------
> >   xen/common/domain.c        |  8 ++++----
> >   xen/drivers/char/console.c | 19 +++++++++++--------
> >   xen/include/xen/sched.h    | 12 ++++++------
> >   4 files changed, 28 insertions(+), 25 deletions(-)
> >
> > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> > index 4cb2e13046..17d1fd42ce 100644
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -571,16 +571,16 @@ static int cf_check hvm_print_line(
> >       if ( !is_console_printable(c) )
> >           return X86EMUL_OKAY;
> >
> > -    spin_lock(&cd->pbuf_lock);
> > +    spin_lock(&cd->console.pbuf_lock);
> >       if ( c !=3D '\n' )
> > -        cd->pbuf[cd->pbuf_idx++] =3D c;
> > -    if ( (cd->pbuf_idx =3D=3D (DOMAIN_PBUF_SIZE - 1)) || (c =3D=3D '\n=
') )
> > +        cd->console.pbuf[cd->console.pbuf_idx++] =3D c;
> > +    if ( (cd->console.pbuf_idx =3D=3D (DOMAIN_PBUF_SIZE - 1)) || (c =
=3D=3D '\n') )
> >       {
> > -        cd->pbuf[cd->pbuf_idx] =3D '\0';
> > -        guest_printk(cd, XENLOG_G_DEBUG "%s\n", cd->pbuf);
> > -        cd->pbuf_idx =3D 0;
> > +        cd->console.pbuf[cd->console.pbuf_idx] =3D '\0';
> > +        guest_printk(cd, XENLOG_G_DEBUG "%s\n", cd->console.pbuf);
> > +        cd->console.pbuf_idx =3D 0;
> >       }
> > -    spin_unlock(&cd->pbuf_lock);
> > +    spin_unlock(&cd->console.pbuf_lock);
> >
> >       return X86EMUL_OKAY;
> >   }
> > diff --git a/xen/common/domain.c b/xen/common/domain.c
> > index 153cd75340..dd1867b2fe 100644
> > --- a/xen/common/domain.c
> > +++ b/xen/common/domain.c
> > @@ -669,7 +669,7 @@ static void _domain_destroy(struct domain *d)
> >       BUG_ON(!d->is_dying);
> >       BUG_ON(atomic_read(&d->refcnt) !=3D DOMAIN_DESTROYED);
> >
> > -    xfree(d->pbuf);
> > +    xfree(d->console.pbuf);
> >
> >       argo_destroy(d);
> >
> > @@ -862,7 +862,7 @@ struct domain *domain_create(domid_t domid,
> >       spin_lock_init(&d->shutdown_lock);
> >       d->shutdown_code =3D SHUTDOWN_CODE_INVALID;
> >
> > -    spin_lock_init(&d->pbuf_lock);
> > +    spin_lock_init(&d->console.pbuf_lock);
> >
> >       rwlock_init(&d->vnuma_rwlock);
> >
> > @@ -956,8 +956,8 @@ struct domain *domain_create(domid_t domid,
> >           goto fail;
> >
> >       err =3D -ENOMEM;
> > -    d->pbuf =3D xzalloc_array(char, DOMAIN_PBUF_SIZE);
> > -    if ( !d->pbuf )
> > +    d->console.pbuf =3D xzalloc_array(char, DOMAIN_PBUF_SIZE);
> > +    if ( !d->console.pbuf )
> >           goto fail;
> >
> >       if ( (err =3D sched_init_domain(d, config->cpupool_id)) !=3D 0 )
> > diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> > index 616f4968b0..3855962af7 100644
> > --- a/xen/drivers/char/console.c
> > +++ b/xen/drivers/char/console.c
> > @@ -769,22 +769,25 @@ static long guest_console_write(XEN_GUEST_HANDLE_=
PARAM(char) buffer,
> >               } while ( --kcount > 0 );
> >
> >               *kout =3D '\0';
> > -            spin_lock(&cd->pbuf_lock);
> > +            spin_lock(&cd->console.pbuf_lock);
> >               kcount =3D kin - kbuf;
> >               if ( c !=3D '\n' &&
> > -                 (cd->pbuf_idx + (kout - kbuf) < (DOMAIN_PBUF_SIZE - 1=
)) )
> > +                 cd->console.pbuf_idx + kout - kbuf < DOMAIN_PBUF_SIZE=
 - 1 )
>=20
> I don't think we want to drop the parentheses here.

The line will will exceed 80 chars if I keep parentheses.

Will something like the following work:

-                 (cd->pbuf_idx + (kout - kbuf) < (DOMAIN_PBUF_SIZE - 1)) )
+                 (cd->console.pbuf_idx + (kout - kbuf) <
+                    (DOMAIN_PBUF_SIZE - 1)) )

?

>=20
> >               {
> >                   /* buffer the output until a newline */
> > -                memcpy(cd->pbuf + cd->pbuf_idx, kbuf, kout - kbuf);
> > -                cd->pbuf_idx +=3D (kout - kbuf);
> > +                memcpy(cd->console.pbuf + cd->console.pbuf_idx,
> > +                       kbuf,
> > +                       kout - kbuf);
> > +                cd->console.pbuf_idx +=3D (kout - kbuf);
> >               }
> >               else
> >               {
> > -                cd->pbuf[cd->pbuf_idx] =3D '\0';
> > -                guest_printk(cd, XENLOG_G_DEBUG "%s%s\n", cd->pbuf, kb=
uf);
> > -                cd->pbuf_idx =3D 0;
> > +                cd->console.pbuf[cd->console.pbuf_idx] =3D '\0';
> > +                guest_printk(cd,
> > +                             XENLOG_G_DEBUG "%s%s\n", cd->console.pbuf=
, kbuf);
> > +                cd->console.pbuf_idx =3D 0;
> >               }
> > -            spin_unlock(&cd->pbuf_lock);
> > +            spin_unlock(&cd->console.pbuf_lock);
> >           }
> >
> >           guest_handle_add_offset(buffer, kcount);
> > diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> > index fe53d4fab7..637aa09ec4 100644
> > --- a/xen/include/xen/sched.h
> > +++ b/xen/include/xen/sched.h
> > @@ -562,12 +562,6 @@ struct domain
> >       /* Control-plane tools handle for this domain. */
> >       xen_domain_handle_t handle;
> >
> > -    /* hvm_print_line() and guest_console_write() logging. */
> > -#define DOMAIN_PBUF_SIZE 200
> > -    char       *pbuf;
> > -    unsigned int pbuf_idx;
> > -    spinlock_t  pbuf_lock;
> > -
> >       /* OProfile support. */
> >       struct xenoprof *xenoprof;
> >
> > @@ -654,6 +648,12 @@ struct domain
> >
> >       /* Console settings. */
> >       struct {
> > +        /* hvm_print_line() and guest_console_write() logging. */
> > +#define DOMAIN_PBUF_SIZE 200
> > +        char *pbuf;
> > +        unsigned int pbuf_idx;
> > +        spinlock_t pbuf_lock;
> > +
> >           /* Permission to take ownership of the physical console input=
. */
> >           bool input_allowed;
> >       } console;
>=20
>=20
> Teddy Astie | Vates XCP-ng Developer
>=20
> XCP-ng & Xen Orchestra - Vates solutions
>=20
> web: https://vates.tech
>=20
>=20



From xen-devel-bounces@lists.xenproject.org Fri Jun 06 23:28:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 23:28:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008970.1388102 (Exim 4.92)
	(envelope-from )
	id 1uNgU1-00031j-F7; Fri, 06 Jun 2025 23:28:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008970.1388102; Fri, 06 Jun 2025 23:28:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNgU1-00031c-C2; Fri, 06 Jun 2025 23:28:21 +0000
Received: by outflank-mailman (input) for mailman id 1008970;
 Fri, 06 Jun 2025 23:28: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 1uNgTz-00031W-I7
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 23:28:19 +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 ebe22f9a-432d-11f0-a303-13f23c93f187;
 Sat, 07 Jun 2025 01:28:16 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id ECBCB5C5D46;
 Fri,  6 Jun 2025 23:25:58 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1F1AAC4CEEB;
 Fri,  6 Jun 2025 23:28: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: ebe22f9a-432d-11f0-a303-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749252495;
	bh=qeSnsN3zYcNKQLmQMewBuJH7juTCHiyv2r+0SZjrPnI=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=GJCZRkUNnfsea98SvoiZLnfKkxrHbYJsq35cifW3EFlePyy7JIxSKoS7G4WQdV45/
	 NthlaO0QSli141iLh8RobfKy6B8jzx+0f2SoubaCbN/haZRPgXG1y0Gc9XZN4TTBx7
	 yF8UgF9V/968XEMQ1cZGisUBsat4OswM6Bizkcon/SsKhu/pcj/qMwerAovnnmWOXx
	 4uX9RYIJybCDlp9/f/a+tAx7LDF3ngCGa3UR3ODXzk0SMH0k1M1H/xNnazW6+CJPYP
	 P7ytPKPqDEj5M4U7hFU2cMjEo5UwdSpaYbb5QqWJEVohGVYWjneMc3yPd9ANmbrOvd
	 F196bgB+PgkXA==
Date: Fri, 6 Jun 2025 16:28:13 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: xen-devel@lists.xenproject.org, Jan Beulich , 
    Andrew Cooper , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    "Daniel P. Smith" 
Subject: Re: [PATCH v2 07/15] x86: Replace boot_domain with bootdomain
In-Reply-To: <20250605194810.2782031-8-agarciav@amd.com>
Message-ID: 
References: <20250605194810.2782031-1-agarciav@amd.com> <20250605194810.2782031-8-agarciav@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Thu, 5 Jun 2025, Alejandro Vallejo wrote:
> No functional change intended.
> 
> Signed-off-by: Alejandro Vallejo 
> ---
> v2:
>   * Replaces the previous patch in which kernel_info replaced boot_domain
> ---
>  xen/arch/x86/dom0_build.c              |  2 +-
>  xen/arch/x86/hvm/dom0_build.c          |  6 ++---
>  xen/arch/x86/include/asm/boot-domain.h | 33 --------------------------
>  xen/arch/x86/include/asm/bootfdt.h     |  7 ++++++
>  xen/arch/x86/include/asm/bootinfo.h    |  3 +--
>  xen/arch/x86/include/asm/dom0_build.h  |  6 ++---
>  xen/arch/x86/include/asm/setup.h       |  4 ++--
>  xen/arch/x86/pv/dom0_build.c           |  6 ++---
>  xen/arch/x86/setup.c                   | 16 +++++++------
>  xen/include/xen/bootfdt.h              |  4 ++++
>  10 files changed, 33 insertions(+), 54 deletions(-)
>  delete mode 100644 xen/arch/x86/include/asm/boot-domain.h
> 
> diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
> index 0b467fd4a4..1c8c5140a3 100644
> --- a/xen/arch/x86/dom0_build.c
> +++ b/xen/arch/x86/dom0_build.c
> @@ -615,7 +615,7 @@ int __init dom0_setup_permissions(struct domain *d)
>      return rc;
>  }
>  
> -int __init construct_dom0(const struct boot_domain *bd)
> +int __init construct_dom0(const struct bootdomain *bd)
>  {
>      int rc;
>      const struct domain *d = bd->d;
> diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
> index 96410344a8..85c000b259 100644
> --- a/xen/arch/x86/hvm/dom0_build.c
> +++ b/xen/arch/x86/hvm/dom0_build.c
> @@ -644,11 +644,11 @@ static bool __init check_and_adjust_load_address(
>  }
>  
>  static int __init pvh_load_kernel(
> -    const struct boot_domain *bd, paddr_t *entry, paddr_t *start_info_addr)
> +    const struct bootdomain *bd, paddr_t *entry, paddr_t *start_info_addr)
>  {
>      struct domain *d = bd->d;
>      struct bootmodule *image = bd->kernel;
> -    struct bootmodule *initrd = bd->module;
> +    struct bootmodule *initrd = bd->initrd;
>      void *image_base = bootstrap_map_bm(image);
>      void *image_start = image_base + image->arch.headroom;
>      unsigned long image_len = image->size;
> @@ -1329,7 +1329,7 @@ static void __hwdom_init pvh_setup_mmcfg(struct domain *d)
>      }
>  }
>  
> -int __init dom0_construct_pvh(const struct boot_domain *bd)
> +int __init dom0_construct_pvh(const struct bootdomain *bd)
>  {
>      paddr_t entry, start_info;
>      struct domain *d = bd->d;
> diff --git a/xen/arch/x86/include/asm/boot-domain.h b/xen/arch/x86/include/asm/boot-domain.h
> deleted file mode 100644
> index 242e9c9c2b..0000000000
> --- a/xen/arch/x86/include/asm/boot-domain.h
> +++ /dev/null
> @@ -1,33 +0,0 @@
> -/* 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__
> -
> -#include 
> -
> -struct boot_domain {
> -    domid_t domid;
> -
> -    struct bootmodule *kernel;
> -    struct bootmodule *module;
> -    const char *cmdline;
> -
> -    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/bootfdt.h b/xen/arch/x86/include/asm/bootfdt.h
> index 2fc705a1cd..b30132381e 100644
> --- a/xen/arch/x86/include/asm/bootfdt.h
> +++ b/xen/arch/x86/include/asm/bootfdt.h
> @@ -4,6 +4,13 @@
>  
>  #include 
>  
> +#include 
> +
> +struct arch_bootdomain
> +{
> +    domid_t domid;
> +};
> +
>  struct arch_bootmodule
>  {
>      /*
> diff --git a/xen/arch/x86/include/asm/bootinfo.h b/xen/arch/x86/include/asm/bootinfo.h
> index f3210b7d6a..b8280ba357 100644
> --- a/xen/arch/x86/include/asm/bootinfo.h
> +++ b/xen/arch/x86/include/asm/bootinfo.h
> @@ -12,7 +12,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  
>  /* Max number of boot modules a bootloader can provide in addition to Xen */
>  #define MAX_NR_BOOTMODS 63
> @@ -34,7 +33,7 @@ struct boot_info {
>  
>      unsigned int nr_modules;
>      struct bootmodule mods[MAX_NR_BOOTMODS + 1];
> -    struct boot_domain domains[MAX_NR_BOOTDOMS];
> +    struct bootdomain  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 ff021c24af..df03189870 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_domain;
> -int dom0_construct_pv(const struct boot_domain *bd);
> -int dom0_construct_pvh(const struct boot_domain *bd);
> +struct bootdomain;
> +int dom0_construct_pv(const struct bootdomain *bd);
> +int dom0_construct_pvh(const struct bootdomain *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 c7deaba109..a8647f0fdf 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_domain;
> -int construct_dom0(const struct boot_domain *bd);
> +struct bootdomain;
> +int construct_dom0(const struct bootdomain *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 e6c77413f5..a6f212fe0a 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(const struct boot_domain *bd)
> +static int __init dom0_construct(const struct bootdomain *bd)
>  {
>      unsigned int i;
>      int rc, order, machine;
> @@ -375,7 +375,7 @@ static int __init dom0_construct(const struct boot_domain *bd)
>      struct vcpu *v = d->vcpu[0];
>  
>      struct bootmodule *image = bd->kernel;
> -    struct bootmodule *initrd = bd->module;
> +    struct bootmodule *initrd = bd->initrd;
>      void *image_base;
>      unsigned long image_len;
>      void *image_start;
> @@ -1070,7 +1070,7 @@ out:
>      return rc;
>  }
>  
> -int __init dom0_construct_pv(const struct boot_domain *bd)
> +int __init dom0_construct_pv(const struct bootdomain *bd)
>  {
>      unsigned long cr4 = read_cr4();
>      int rc;
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index e9a70c2c2b..726adad0e5 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -297,7 +297,9 @@ static const char *cmdline_cook(const char *p, const char *loader_name);
>  struct boot_info __initdata xen_boot_info = {
>      .loader = "unknown",
>      .cmdline = "",
> -    .domains = { [0 ... MAX_NR_BOOTDOMS - 1] = { .domid = DOMID_INVALID } },
> +    .domains = { [0 ... MAX_NR_BOOTDOMS - 1] = {
> +        .arch.domid = DOMID_INVALID
> +    }},
>      /*
>       * There's a MAX_NR_BOOTMODS-th entry in the array. It's not off by one.
>       *
> @@ -987,7 +989,7 @@ static unsigned int __init copy_bios_e820(struct e820entry *map, unsigned int li
>  }
>  
>  static size_t __init domain_cmdline_size(const struct boot_info *bi,
> -                                         const struct boot_domain *bd)
> +                                         const struct bootdomain *bd)
>  {
>      size_t s = bi->kextra ? strlen(bi->kextra) : 0;
>      const struct arch_bootmodule *abm = &bd->kernel->arch;
> @@ -1022,7 +1024,7 @@ 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 bootdomain *bd = &bi->domains[0];
>      struct domain *d;
>  
>      if ( opt_dom0_pvh )
> @@ -1039,11 +1041,11 @@ 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();
> -    d = domain_create(bd->domid, &dom0_cfg,
> +    bd->arch.domid = get_initial_domain_id();
> +    d = domain_create(bd->arch.domid, &dom0_cfg,
>                        pv_shim ? 0 : CDF_privileged | CDF_hardware);
>      if ( IS_ERR(d) )
> -        panic("Error creating d%u: %ld\n", bd->domid, PTR_ERR(d));
> +        panic("Error creating d%u: %ld\n", bd->arch.domid, PTR_ERR(d));
>  
>      init_dom0_cpuid_policy(d);
>  
> @@ -2162,7 +2164,7 @@ void asmlinkage __init noreturn __start_xen(void)
>      if ( initrdidx < MAX_NR_BOOTMODS )
>      {
>          bi->mods[initrdidx].kind = BOOTMOD_RAMDISK;
> -        bi->domains[0].module = &bi->mods[initrdidx];
> +        bi->domains[0].initrd = &bi->mods[initrdidx];
>          if ( first_boot_module_index(bi, BOOTMOD_UNKNOWN) < MAX_NR_BOOTMODS )
>              printk(XENLOG_WARNING
>                     "Multiple initrd candidates, picking module #%u\n",
> diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
> index e6d52a599f..19d2ff0f0c 100644
> --- a/xen/include/xen/bootfdt.h
> +++ b/xen/include/xen/bootfdt.h
> @@ -108,6 +108,10 @@ struct bootdomain {
>      struct bootmodule *initrd;
>  
>      const char* cmdline;
> +
> +#if __has_include()
> +    struct arch_bootdomain arch;
> +#endif
>  };

One suggestion for improvement:

diff --git a/xen/arch/x86/include/asm/bootfdt.h b/xen/arch/x86/include/asm/bootfdt.h
index b30132381e..892a0e2373 100644
--- a/xen/arch/x86/include/asm/bootfdt.h
+++ b/xen/arch/x86/include/asm/bootfdt.h
@@ -6,11 +6,6 @@
 
 #include 
 
-struct arch_bootdomain
-{
-    domid_t domid;
-};
-
 struct arch_bootmodule
 {
     /*
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 726adad0e5..39f294b88b 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -297,9 +297,6 @@ static const char *cmdline_cook(const char *p, const char *loader_name);
 struct boot_info __initdata xen_boot_info = {
     .loader = "unknown",
     .cmdline = "",
-    .domains = { [0 ... MAX_NR_BOOTDOMS - 1] = {
-        .arch.domid = DOMID_INVALID
-    }},
     /*
      * There's a MAX_NR_BOOTMODS-th entry in the array. It's not off by one.
      *
@@ -1026,6 +1023,7 @@ static struct domain *__init create_dom0(struct boot_info *bi)
     };
     struct bootdomain *bd = &bi->domains[0];
     struct domain *d;
+    domid_t domid;
 
     if ( opt_dom0_pvh )
     {
@@ -1041,11 +1039,11 @@ 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->arch.domid = get_initial_domain_id();
-    d = domain_create(bd->arch.domid, &dom0_cfg,
+    domid = get_initial_domain_id();
+    d = domain_create(domid, &dom0_cfg,
                       pv_shim ? 0 : CDF_privileged | CDF_hardware);
     if ( IS_ERR(d) )
-        panic("Error creating d%u: %ld\n", bd->arch.domid, PTR_ERR(d));
+        panic("Error creating d%u: %ld\n", domid, PTR_ERR(d));
 
     init_dom0_cpuid_policy(d);
 
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index 19d2ff0f0c..e6d52a599f 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -108,10 +108,6 @@ struct bootdomain {
     struct bootmodule *initrd;
 
     const char* cmdline;
-
-#if __has_include()
-    struct arch_bootdomain arch;
-#endif
 };
 
 /*


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 23:40:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 23:40:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008977.1388112 (Exim 4.92)
	(envelope-from )
	id 1uNgfN-0005TF-Gc; Fri, 06 Jun 2025 23:40:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008977.1388112; Fri, 06 Jun 2025 23:40:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNgfN-0005Sp-C6; Fri, 06 Jun 2025 23:40:05 +0000
Received: by outflank-mailman (input) for mailman id 1008977;
 Fri, 06 Jun 2025 23:40: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 1uNgfL-0004s7-77
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 23:40:03 +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 8e442794-432f-11f0-a303-13f23c93f187;
 Sat, 07 Jun 2025 01:39:58 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 7D9515C4988;
 Fri,  6 Jun 2025 23:37:40 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id E3028C4CEEB;
 Fri,  6 Jun 2025 23:39:54 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8e442794-432f-11f0-a303-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749253196;
	bh=7bugLH7yQWuKXLQIDqiHWCvYAlf5FJpAPgGIqIuVhWw=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=SXES9RuGD2JvVXwQCVXjUa0819EcWhuDZlRsbmpp3Hu1Ru0MaVhIqs7/Jv7uoZ6Hg
	 QHiiWU6BD639khBgvPomTduVMyRVhW5qHuGLqM/TuT6UotmgpQHMcsbHnDe4L4bvJ0
	 /6R5QEIpxIJtaS2wgsR3SrO7Z4WxQfxF24uws8TIVPXwZdZqbnzumyBbHiXoLGAfTl
	 DOY6cSV35oosVe73DztJHfSNkdOM7BNLRWMjmy8bhwWfszOq0dUB/3kQhMveI6nFVW
	 9U3BTcLqbPYCnE1db5EVpN8HQkyGwP102EIp26HgbIgNZzuPKI+Bqn6+NFY8tF31j+
	 mwR+jzg1XGcpw==
Date: Fri, 6 Jun 2025 16:39:54 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    Andrew Cooper , 
    Anthony PERARD , 
    Jan Beulich , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Alistair Francis , 
    Bob Eshleman , 
    Connor Davis , 
    Oleksii Kurochko , 
    "Daniel P. Smith" 
Subject: Re: [PATCH v2 09/15] xen/dt: Move bootinfo functions to a new
 bootinfo.h
In-Reply-To: <20250605194810.2782031-10-agarciav@amd.com>
Message-ID: 
References: <20250605194810.2782031-1-agarciav@amd.com> <20250605194810.2782031-10-agarciav@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Thu, 5 Jun 2025, Alejandro Vallejo wrote:
> Part of an unpicking process to extract bootfdt contents independent of
> bootinfo to a separate file for x86 to take.
> 
> With this, bootfdt.h can be cleanly included from x86. A later patch
> extracts the definitions so the functions may be called too.
> 
> Not a functional change.
> 
> Signed-off-by: Alejandro Vallejo 
> ---
>  xen/arch/arm/domain_build.c             |   1 +
>  xen/arch/arm/mmu/mm.c                   |   1 +
>  xen/arch/arm/setup.c                    |   1 +
>  xen/arch/riscv/mm.c                     |   2 +-
>  xen/arch/riscv/setup.c                  |   2 +-
>  xen/common/device-tree/bootfdt.c        |   2 +-
>  xen/common/device-tree/bootinfo.c       |   2 +-
>  xen/common/device-tree/dom0less-build.c |   2 +-
>  xen/common/device-tree/domain-build.c   |   2 +-
>  xen/common/device-tree/kernel.c         |   2 +-
>  xen/include/xen/bootfdt.h               | 208 -----------------------
>  xen/include/xen/bootinfo.h              | 213 ++++++++++++++++++++++++
>  xen/include/xen/device_tree.h           |   2 +-
>  xen/include/xen/fdt-domain-build.h      |   2 +-
>  xen/include/xen/fdt-kernel.h            |   2 +-
>  15 files changed, 226 insertions(+), 218 deletions(-)
>  create mode 100644 xen/include/xen/bootinfo.h
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 5317665555..497cfbe860 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1,5 +1,6 @@
>  /* SPDX-License-Identifier: GPL-2.0-only */
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/xen/arch/arm/mmu/mm.c b/xen/arch/arm/mmu/mm.c
> index 9c50479c63..77f82757bb 100644
> --- a/xen/arch/arm/mmu/mm.c
> +++ b/xen/arch/arm/mmu/mm.c
> @@ -1,5 +1,6 @@
>  /* SPDX-License-Identifier: GPL-2.0-or-later */
>  
> +#include 

It doesn't look like this is needed.

Other than that:

Reviewed-by: Stefano Stabellini 


>  #include 
>  #include 
>  #include 
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 734e23da44..439b1d9df2 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -8,6 +8,7 @@
>   * Copyright (c) 2011 Citrix Systems.
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
> index 4047d67c0e..6ccd38091b 100644
> --- a/xen/arch/riscv/mm.c
> +++ b/xen/arch/riscv/mm.c
> @@ -1,6 +1,6 @@
>  /* SPDX-License-Identifier: GPL-2.0-only */
>  
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
> index 8bcd19218d..3e99e2e194 100644
> --- a/xen/arch/riscv/setup.c
> +++ b/xen/arch/riscv/setup.c
> @@ -2,7 +2,7 @@
>  
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
> index ab449db8d6..7ff62e1e3e 100644
> --- a/xen/common/device-tree/bootfdt.c
> +++ b/xen/common/device-tree/bootfdt.c
> @@ -5,7 +5,7 @@
>   * Copyright (C) 2012-2014 Citrix Systems, Inc.
>   */
>  
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/xen/common/device-tree/bootinfo.c b/xen/common/device-tree/bootinfo.c
> index 717cfa0962..69491bdb0b 100644
> --- a/xen/common/device-tree/bootinfo.c
> +++ b/xen/common/device-tree/bootinfo.c
> @@ -10,7 +10,7 @@
>   */
>  
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
> index 809cb3c232..42165e78af 100644
> --- a/xen/common/device-tree/dom0less-build.c
> +++ b/xen/common/device-tree/dom0less-build.c
> @@ -1,6 +1,6 @@
>  /* SPDX-License-Identifier: GPL-2.0-only */
>  
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/xen/common/device-tree/domain-build.c b/xen/common/device-tree/domain-build.c
> index e602cb91c9..80235aa56a 100644
> --- a/xen/common/device-tree/domain-build.c
> +++ b/xen/common/device-tree/domain-build.c
> @@ -1,6 +1,6 @@
>  /* SPDX-License-Identifier: GPL-2.0-only */
>  
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/xen/common/device-tree/kernel.c b/xen/common/device-tree/kernel.c
> index 3960f951f7..0463bfd8df 100644
> --- a/xen/common/device-tree/kernel.c
> +++ b/xen/common/device-tree/kernel.c
> @@ -1,6 +1,6 @@
>  /* SPDX-License-Identifier: GPL-2.0-only */
>  
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
> index 1b89986e10..a87b5212a6 100644
> --- a/xen/include/xen/bootfdt.h
> +++ b/xen/include/xen/bootfdt.h
> @@ -4,9 +4,6 @@
>  
>  #include 
>  #include 
> -#include 
> -#include 
> -#include 
>  
>  #if __has_include()
>  #include 
> @@ -14,15 +11,10 @@
>  
>  #define MIN_FDT_ALIGN 8
>  
> -#define NR_MEM_BANKS 256
> -#define NR_SHMEM_BANKS 32
> -
>  /* Default #address and #size cells */
>  #define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
>  #define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
>  
> -#define MAX_MODULES 32 /* Current maximum useful modules */
> -
>  #define DEVICE_TREE_MAX_DEPTH 16
>  
>  /* Helper to read a big number; size is in cells (not bytes) */
> @@ -75,78 +67,6 @@ typedef enum {
>      BOOTMOD_UNKNOWN
>  }  bootmodule_kind;
>  
> -enum membank_type {
> -    /*
> -     * The MEMBANK_DEFAULT type refers to either reserved memory for the
> -     * device/firmware (when the bank is in 'reserved_mem') or any RAM (when
> -     * the bank is in 'mem').
> -     */
> -    MEMBANK_DEFAULT,
> -    /*
> -     * The MEMBANK_STATIC_DOMAIN type is used to indicate whether the memory
> -     * bank is bound to a static Xen domain. It is only valid when the bank
> -     * is in reserved_mem.
> -     */
> -    MEMBANK_STATIC_DOMAIN,
> -    /*
> -     * The MEMBANK_STATIC_HEAP type is used to indicate whether the memory
> -     * bank is reserved as static heap. It is only valid when the bank is
> -     * in reserved_mem.
> -     */
> -    MEMBANK_STATIC_HEAP,
> -    /*
> -     * The MEMBANK_FDT_RESVMEM type is used to indicate whether the memory
> -     * bank is from the FDT reserve map.
> -     */
> -    MEMBANK_FDT_RESVMEM,
> -};
> -
> -enum region_type {
> -    MEMORY,
> -    RESERVED_MEMORY,
> -    STATIC_SHARED_MEMORY
> -};
> -
> -/* Indicates the maximum number of characters(\0 included) for shm_id */
> -#define MAX_SHM_ID_LENGTH 16
> -
> -struct shmem_membank_extra {
> -    char shm_id[MAX_SHM_ID_LENGTH];
> -    unsigned int nr_shm_borrowers;
> -};
> -
> -struct membank {
> -    paddr_t start;
> -    paddr_t size;
> -    union {
> -        enum membank_type type;
> -#ifdef CONFIG_STATIC_SHM
> -        struct shmem_membank_extra *shmem_extra;
> -#endif
> -    };
> -};
> -
> -struct membanks {
> -    __struct_group(membanks_hdr, common, ,
> -        unsigned int nr_banks;
> -        unsigned int max_banks;
> -        enum region_type type;
> -    );
> -    struct membank bank[];
> -};
> -
> -struct meminfo {
> -    struct membanks_hdr common;
> -    struct membank bank[NR_MEM_BANKS];
> -};
> -
> -struct shared_meminfo {
> -    struct membanks_hdr common;
> -    struct membank bank[NR_SHMEM_BANKS];
> -    struct shmem_membank_extra extra[NR_SHMEM_BANKS];
> -};
> -
> -
>  struct bootdomain {
>      struct domain *d;
>  
> @@ -179,134 +99,6 @@ struct bootmodule {
>  #endif
>  };
>  
> -/* DT_MAX_NAME is the node name max length according the DT spec */
> -#define DT_MAX_NAME 41
> -struct bootcmdline {
> -    bootmodule_kind kind;
> -    bool domU;
> -    paddr_t start;
> -    char dt_name[DT_MAX_NAME];
> -    char cmdline[BOOTMOD_MAX_CMDLINE];
> -};
> -
> -struct bootmodules {
> -    int nr_mods;
> -    struct bootmodule module[MAX_MODULES];
> -};
> -
> -struct bootcmdlines {
> -    unsigned int nr_mods;
> -    struct bootcmdline cmdline[MAX_MODULES];
> -};
> -
> -struct bootinfo {
> -    struct meminfo mem;
> -    /* The reserved regions are only used when booting using Device-Tree */
> -    struct meminfo reserved_mem;
> -    struct bootmodules modules;
> -    struct bootcmdlines cmdlines;
> -#ifdef CONFIG_ACPI
> -    struct meminfo acpi;
> -#endif
> -#ifdef CONFIG_STATIC_SHM
> -    struct shared_meminfo shmem;
> -#endif
> -};
> -
> -#ifdef CONFIG_ACPI
> -#define BOOTINFO_ACPI_INIT                          \
> -    .acpi.common.max_banks = NR_MEM_BANKS,          \
> -    .acpi.common.type = MEMORY,
> -#else
> -#define BOOTINFO_ACPI_INIT
> -#endif
> -
> -#ifdef CONFIG_STATIC_SHM
> -#define BOOTINFO_SHMEM_INIT                         \
> -    .shmem.common.max_banks = NR_SHMEM_BANKS,       \
> -    .shmem.common.type = STATIC_SHARED_MEMORY,
> -#else
> -#define BOOTINFO_SHMEM_INIT
> -#endif
> -
> -#define BOOTINFO_INIT                               \
> -{                                                   \
> -    .mem.common.max_banks = NR_MEM_BANKS,           \
> -    .mem.common.type = MEMORY,                      \
> -    .reserved_mem.common.max_banks = NR_MEM_BANKS,  \
> -    .reserved_mem.common.type = RESERVED_MEMORY,    \
> -    BOOTINFO_ACPI_INIT                              \
> -    BOOTINFO_SHMEM_INIT                             \
> -}
> -
> -extern struct bootinfo bootinfo;
> -
> -bool check_reserved_regions_overlap(paddr_t region_start,
> -                                    paddr_t region_size,
> -                                    bool allow_memreserve_overlap);
> -
> -struct bootmodule *add_boot_module(bootmodule_kind kind,
> -                                   paddr_t start, paddr_t size, bool domU);
> -struct bootmodule *boot_module_find_by_kind(bootmodule_kind kind);
> -struct bootmodule * boot_module_find_by_addr_and_kind(bootmodule_kind kind,
> -                                                             paddr_t start);
> -void add_boot_cmdline(const char *name, const char *cmdline,
> -                      bootmodule_kind kind, paddr_t start, bool domU);
> -struct bootcmdline *boot_cmdline_find_by_kind(bootmodule_kind kind);
> -struct bootcmdline * boot_cmdline_find_by_name(const char *name);
> -const char *boot_module_kind_as_string(bootmodule_kind kind);
> -
> -void populate_boot_allocator(void);
> -
> -size_t boot_fdt_info(const void *fdt, paddr_t paddr);
> -
> -const char *boot_fdt_cmdline(const void *fdt);
> -int domain_fdt_begin_node(void *fdt, const char *name, uint64_t unit);
> -
> -static inline struct membanks *bootinfo_get_reserved_mem(void)
> -{
> -    return container_of(&bootinfo.reserved_mem.common, struct membanks, common);
> -}
> -
> -static inline struct membanks *bootinfo_get_mem(void)
> -{
> -    return container_of(&bootinfo.mem.common, struct membanks, common);
> -}
> -
> -#ifdef CONFIG_ACPI
> -static inline struct membanks *bootinfo_get_acpi(void)
> -{
> -    return container_of(&bootinfo.acpi.common, struct membanks, common);
> -}
> -#endif
> -
> -#ifdef CONFIG_STATIC_SHM
> -static inline struct membanks *bootinfo_get_shmem(void)
> -{
> -    return container_of(&bootinfo.shmem.common, struct membanks, common);
> -}
> -
> -static inline struct shmem_membank_extra *bootinfo_get_shmem_extra(void)
> -{
> -    return bootinfo.shmem.extra;
> -}
> -#endif
> -
> -static inline struct membanks *membanks_xzalloc(unsigned int nr,
> -                                                enum region_type type)
> -{
> -    struct membanks *banks = xzalloc_flex_struct(struct membanks, bank, nr);
> -
> -    if ( !banks )
> -        goto out;
> -
> -    banks->max_banks = nr;
> -    banks->type = type;
> -
> - out:
> -    return banks;
> -}
> -
>  /*
>   * Interpret the property `prop_name` of `node` as a u32.
>   *
> diff --git a/xen/include/xen/bootinfo.h b/xen/include/xen/bootinfo.h
> new file mode 100644
> index 0000000000..670fe771a4
> --- /dev/null
> +++ b/xen/include/xen/bootinfo.h
> @@ -0,0 +1,213 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef XEN_BOOTINFO_H
> +#define XEN_BOOTINFO_H
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define NR_MEM_BANKS 256
> +#define NR_SHMEM_BANKS 32
> +
> +#define MAX_MODULES 32 /* Current maximum useful modules */
> +
> +enum membank_type {
> +    /*
> +     * The MEMBANK_DEFAULT type refers to either reserved memory for the
> +     * device/firmware (when the bank is in 'reserved_mem') or any RAM (when
> +     * the bank is in 'mem').
> +     */
> +    MEMBANK_DEFAULT,
> +    /*
> +     * The MEMBANK_STATIC_DOMAIN type is used to indicate whether the memory
> +     * bank is bound to a static Xen domain. It is only valid when the bank
> +     * is in reserved_mem.
> +     */
> +    MEMBANK_STATIC_DOMAIN,
> +    /*
> +     * The MEMBANK_STATIC_HEAP type is used to indicate whether the memory
> +     * bank is reserved as static heap. It is only valid when the bank is
> +     * in reserved_mem.
> +     */
> +    MEMBANK_STATIC_HEAP,
> +    /*
> +     * The MEMBANK_FDT_RESVMEM type is used to indicate whether the memory
> +     * bank is from the FDT reserve map.
> +     */
> +    MEMBANK_FDT_RESVMEM,
> +};
> +
> +enum region_type {
> +    MEMORY,
> +    RESERVED_MEMORY,
> +    STATIC_SHARED_MEMORY
> +};
> +
> +/* Indicates the maximum number of characters(\0 included) for shm_id */
> +#define MAX_SHM_ID_LENGTH 16
> +
> +struct shmem_membank_extra {
> +    char shm_id[MAX_SHM_ID_LENGTH];
> +    unsigned int nr_shm_borrowers;
> +};
> +
> +struct membank {
> +    paddr_t start;
> +    paddr_t size;
> +    union {
> +        enum membank_type type;
> +#ifdef CONFIG_STATIC_SHM
> +        struct shmem_membank_extra *shmem_extra;
> +#endif
> +    };
> +};
> +
> +struct membanks {
> +    __struct_group(membanks_hdr, common, ,
> +        unsigned int nr_banks;
> +        unsigned int max_banks;
> +        enum region_type type;
> +    );
> +    struct membank bank[];
> +};
> +
> +struct meminfo {
> +    struct membanks_hdr common;
> +    struct membank bank[NR_MEM_BANKS];
> +};
> +
> +struct shared_meminfo {
> +    struct membanks_hdr common;
> +    struct membank bank[NR_SHMEM_BANKS];
> +    struct shmem_membank_extra extra[NR_SHMEM_BANKS];
> +};
> +
> +/* DT_MAX_NAME is the node name max length according the DT spec */
> +#define DT_MAX_NAME 41
> +struct bootcmdline {
> +    bootmodule_kind kind;
> +    bool domU;
> +    paddr_t start;
> +    char dt_name[DT_MAX_NAME];
> +    char cmdline[BOOTMOD_MAX_CMDLINE];
> +};
> +
> +struct bootmodules {
> +    int nr_mods;
> +    struct bootmodule module[MAX_MODULES];
> +};
> +
> +struct bootcmdlines {
> +    unsigned int nr_mods;
> +    struct bootcmdline cmdline[MAX_MODULES];
> +};
> +
> +struct bootinfo {
> +    struct meminfo mem;
> +    /* The reserved regions are only used when booting using Device-Tree */
> +    struct meminfo reserved_mem;
> +    struct bootmodules modules;
> +    struct bootcmdlines cmdlines;
> +#ifdef CONFIG_ACPI
> +    struct meminfo acpi;
> +#endif
> +#ifdef CONFIG_STATIC_SHM
> +    struct shared_meminfo shmem;
> +#endif
> +};
> +
> +#ifdef CONFIG_ACPI
> +#define BOOTINFO_ACPI_INIT                          \
> +    .acpi.common.max_banks = NR_MEM_BANKS,          \
> +    .acpi.common.type = MEMORY,
> +#else
> +#define BOOTINFO_ACPI_INIT
> +#endif
> +
> +#ifdef CONFIG_STATIC_SHM
> +#define BOOTINFO_SHMEM_INIT                         \
> +    .shmem.common.max_banks = NR_SHMEM_BANKS,       \
> +    .shmem.common.type = STATIC_SHARED_MEMORY,
> +#else
> +#define BOOTINFO_SHMEM_INIT
> +#endif
> +
> +#define BOOTINFO_INIT                               \
> +{                                                   \
> +    .mem.common.max_banks = NR_MEM_BANKS,           \
> +    .mem.common.type = MEMORY,                      \
> +    .reserved_mem.common.max_banks = NR_MEM_BANKS,  \
> +    .reserved_mem.common.type = RESERVED_MEMORY,    \
> +    BOOTINFO_ACPI_INIT                              \
> +    BOOTINFO_SHMEM_INIT                             \
> +}
> +
> +extern struct bootinfo bootinfo;
> +
> +bool check_reserved_regions_overlap(paddr_t region_start,
> +                                    paddr_t region_size,
> +                                    bool allow_memreserve_overlap);
> +
> +struct bootmodule *add_boot_module(bootmodule_kind kind,
> +                                   paddr_t start, paddr_t size, bool domU);
> +struct bootmodule *boot_module_find_by_kind(bootmodule_kind kind);
> +struct bootmodule * boot_module_find_by_addr_and_kind(bootmodule_kind kind,
> +                                                             paddr_t start);
> +void add_boot_cmdline(const char *name, const char *cmdline,
> +                      bootmodule_kind kind, paddr_t start, bool domU);
> +struct bootcmdline *boot_cmdline_find_by_kind(bootmodule_kind kind);
> +struct bootcmdline * boot_cmdline_find_by_name(const char *name);
> +const char *boot_module_kind_as_string(bootmodule_kind kind);
> +
> +void populate_boot_allocator(void);
> +
> +size_t boot_fdt_info(const void *fdt, paddr_t paddr);
> +const char *boot_fdt_cmdline(const void *fdt);
> +int domain_fdt_begin_node(void *fdt, const char *name, uint64_t unit);
> +
> +static inline struct membanks *bootinfo_get_reserved_mem(void)
> +{
> +    return container_of(&bootinfo.reserved_mem.common, struct membanks, common);
> +}
> +
> +static inline struct membanks *bootinfo_get_mem(void)
> +{
> +    return container_of(&bootinfo.mem.common, struct membanks, common);
> +}
> +
> +#ifdef CONFIG_ACPI
> +static inline struct membanks *bootinfo_get_acpi(void)
> +{
> +    return container_of(&bootinfo.acpi.common, struct membanks, common);
> +}
> +#endif
> +
> +#ifdef CONFIG_STATIC_SHM
> +static inline struct membanks *bootinfo_get_shmem(void)
> +{
> +    return container_of(&bootinfo.shmem.common, struct membanks, common);
> +}
> +
> +static inline struct shmem_membank_extra *bootinfo_get_shmem_extra(void)
> +{
> +    return bootinfo.shmem.extra;
> +}
> +#endif
> +
> +static inline struct membanks *membanks_xzalloc(unsigned int nr,
> +                                                enum region_type type)
> +{
> +    struct membanks *banks = xzalloc_flex_struct(struct membanks, bank, nr);
> +
> +    if ( !banks )
> +        goto out;
> +
> +    banks->max_banks = nr;
> +    banks->type = type;
> +
> + out:
> +    return banks;
> +}
> +
> +#endif /* XEN_BOOTINFO_H */
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> index 0a22b1ba1d..7d1c8bc305 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -10,7 +10,7 @@
>  #ifndef __XEN_DEVICE_TREE_H__
>  #define __XEN_DEVICE_TREE_H__
>  
> -#include 
> +#include 
>  #include 
>  
>  #include 
> diff --git a/xen/include/xen/fdt-domain-build.h b/xen/include/xen/fdt-domain-build.h
> index 45981dbec0..60565fdbf9 100644
> --- a/xen/include/xen/fdt-domain-build.h
> +++ b/xen/include/xen/fdt-domain-build.h
> @@ -3,7 +3,7 @@
>  #ifndef __XEN_FDT_DOMAIN_BUILD_H__
>  #define __XEN_FDT_DOMAIN_BUILD_H__
>  
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/xen/include/xen/fdt-kernel.h b/xen/include/xen/fdt-kernel.h
> index dd009f01d0..cb211d242f 100644
> --- a/xen/include/xen/fdt-kernel.h
> +++ b/xen/include/xen/fdt-kernel.h
> @@ -7,7 +7,7 @@
>  #ifndef __XEN_FDT_KERNEL_H__
>  #define __XEN_FDT_KERNEL_H__
>  
> -#include 
> +#include 
>  #include 
>  #include 
>  
> -- 
> 2.43.0
> 


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 23:44:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 23:44:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008989.1388122 (Exim 4.92)
	(envelope-from )
	id 1uNgjG-0006Nu-1Y; Fri, 06 Jun 2025 23:44:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008989.1388122; Fri, 06 Jun 2025 23:44: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 1uNgjF-0006Nn-VD; Fri, 06 Jun 2025 23:44:05 +0000
Received: by outflank-mailman (input) for mailman id 1008989;
 Fri, 06 Jun 2025 23:44:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uNgjE-0006NF-UM
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 23:44:04 +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 1f7049a7-4330-11f0-b894-0df219b8e170;
 Sat, 07 Jun 2025 01:44:02 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 42B795C5430;
 Fri,  6 Jun 2025 23:41:44 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id C596BC4CEEB;
 Fri,  6 Jun 2025 23:43: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: 1f7049a7-4330-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749253440;
	bh=UxnHsLBxKoqqdULPyLYsw8tJWQSBh6OiK9hn8z55btc=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=FIqDEzPr2MZBXnpsfxwjEy5pYzkK3uF/EbeBG1GRITX7bWco3+gJOaPsTGnk3yhSP
	 ZKjbSflOGowqvW7H79uQ8PESmDl6cMZIYW/CWYU89HZsbp31BO9u6UixGf+BUwwSNl
	 /TV0G+F92VyVablaLuw6ScwcksF2o63ckVYxPyQbXTRcbTDwtILYf3bjqD5EGBv35A
	 jpmzbSteUiMEk+8PowfGGWQZDABHspoVIMDHY6uMkOctqCTLP+aWm+jmuKPEZv19AF
	 BWHdOxe3CugCDCfyQ/9ocCm0zjcd8cGAr/ASwGIP80Q5yo1vULPFWGqXSyZbRH7WHT
	 L6kWTQNsGhSgA==
Date: Fri, 6 Jun 2025 16:43:59 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    "Daniel P. Smith" 
Subject: Re: [PATCH v2 11/15] xen/dt: Move bootinfo-independent helpers out
 of bootinfo-fdt.c
In-Reply-To: <20250605194810.2782031-12-agarciav@amd.com>
Message-ID: 
References: <20250605194810.2782031-1-agarciav@amd.com> <20250605194810.2782031-12-agarciav@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Thu, 5 Jun 2025, Alejandro Vallejo wrote:
> ... back into bootfdt.c
> 
> These will be required by x86 later on to detect modules in the early scan of
> the FDT. They are independent of bootinfo, so it's cleaner for them to exist in
> a separate file.
> 
> Not a functional change.
> 
> Signed-off-by: Alejandro Vallejo 

In retrospect, it would have been better to keep the code movement as is
and do any changes as a separate patch. But given that I was the one to
ask for it:

Reviewed-by: Stefano Stabellini 


> ---
>  xen/common/device-tree/Makefile       |   1 +
>  xen/common/device-tree/bootfdt.c      |  97 ++++++++++++++++++++++++
>  xen/common/device-tree/bootinfo-fdt.c | 104 --------------------------
>  3 files changed, 98 insertions(+), 104 deletions(-)
>  create mode 100644 xen/common/device-tree/bootfdt.c
> 
> diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
> index 8a3f2be89e..8abc069c4b 100644
> --- a/xen/common/device-tree/Makefile
> +++ b/xen/common/device-tree/Makefile
> @@ -1,3 +1,4 @@
> +obj-y += bootfdt.init.o
>  obj-y += bootinfo-fdt.init.o
>  obj-y += bootinfo.init.o
>  obj-y += device-tree.o
> diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
> new file mode 100644
> index 0000000000..6acf83d197
> --- /dev/null
> +++ b/xen/common/device-tree/bootfdt.c
> @@ -0,0 +1,97 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +uint32_t __init device_tree_get_u32(const void *fdt, int node,
> +                                    const char *prop_name, uint32_t dflt)
> +{
> +    const struct fdt_property *prop;
> +
> +    prop = fdt_get_property(fdt, node, prop_name, NULL);
> +    if ( !prop || prop->len < sizeof(uint32_t) )
> +        return dflt;
> +
> +    return fdt32_to_cpu(*(const uint32_t*)prop->data);
> +}
> +
> +int __init device_tree_for_each_node(const void *fdt, int node,
> +                                     device_tree_node_func func,
> +                                     void *data)
> +{
> +    /*
> +     * We only care about relative depth increments, assume depth of
> +     * node is 0 for simplicity.
> +     */
> +    int depth = 0;
> +    const int first_node = node;
> +    uint32_t address_cells[DEVICE_TREE_MAX_DEPTH];
> +    uint32_t size_cells[DEVICE_TREE_MAX_DEPTH];
> +    int ret;
> +
> +    do {
> +        const char *name = fdt_get_name(fdt, node, NULL);
> +        uint32_t as, ss;
> +
> +        if ( depth >= DEVICE_TREE_MAX_DEPTH )
> +        {
> +            printk("Warning: device tree node `%s' is nested too deep\n",
> +                   name);
> +            continue;
> +        }
> +
> +        as = depth > 0 ? address_cells[depth-1] : DT_ROOT_NODE_ADDR_CELLS_DEFAULT;
> +        ss = depth > 0 ? size_cells[depth-1] : DT_ROOT_NODE_SIZE_CELLS_DEFAULT;
> +
> +        address_cells[depth] = device_tree_get_u32(fdt, node,
> +                                                   "#address-cells", as);
> +        size_cells[depth] = device_tree_get_u32(fdt, node,
> +                                                "#size-cells", ss);
> +
> +        /* skip the first node */
> +        if ( node != first_node )
> +        {
> +            ret = func(fdt, node, name, depth, as, ss, data);
> +            if ( ret != 0 )
> +                return ret;
> +        }
> +
> +        node = fdt_next_node(fdt, node, &depth);
> +    } while ( node >= 0 && depth > 0 );
> +
> +    return 0;
> +}
> +
> +void __init device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
> +                                uint32_t size_cells, paddr_t *start,
> +                                paddr_t *size)
> +{
> +    uint64_t dt_start, dt_size;
> +
> +    /*
> +     * dt_next_cell will return uint64_t whereas paddr_t may not be 64-bit.
> +     * Thus, there is an implicit cast from uint64_t to paddr_t.
> +     */
> +    dt_start = dt_next_cell(address_cells, cell);
> +    dt_size = dt_next_cell(size_cells, cell);
> +
> +    if ( dt_start != (paddr_t)dt_start )
> +    {
> +        printk("Physical address greater than max width supported\n");
> +        WARN();
> +    }
> +
> +    if ( dt_size != (paddr_t)dt_size )
> +    {
> +        printk("Physical size greater than max width supported\n");
> +        WARN();
> +    }
> +
> +    /*
> +     * Xen will truncate the address/size if it is greater than the maximum
> +     * supported width and it will give an appropriate warning.
> +     */
> +    *start = dt_start;
> +    *size = dt_size;
> +}
> diff --git a/xen/common/device-tree/bootinfo-fdt.c b/xen/common/device-tree/bootinfo-fdt.c
> index 195249f700..695c4bfc49 100644
> --- a/xen/common/device-tree/bootinfo-fdt.c
> +++ b/xen/common/device-tree/bootinfo-fdt.c
> @@ -109,39 +109,6 @@ static bool __init device_tree_is_memory_node(const void *fdt, int node,
>      return true;
>  }
>  
> -void __init device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
> -                                uint32_t size_cells, paddr_t *start,
> -                                paddr_t *size)
> -{
> -    uint64_t dt_start, dt_size;
> -
> -    /*
> -     * dt_next_cell will return uint64_t whereas paddr_t may not be 64-bit.
> -     * Thus, there is an implicit cast from uint64_t to paddr_t.
> -     */
> -    dt_start = dt_next_cell(address_cells, cell);
> -    dt_size = dt_next_cell(size_cells, cell);
> -
> -    if ( dt_start != (paddr_t)dt_start )
> -    {
> -        printk("Physical address greater than max width supported\n");
> -        WARN();
> -    }
> -
> -    if ( dt_size != (paddr_t)dt_size )
> -    {
> -        printk("Physical size greater than max width supported\n");
> -        WARN();
> -    }
> -
> -    /*
> -     * Xen will truncate the address/size if it is greater than the maximum
> -     * supported width and it will give an appropriate warning.
> -     */
> -    *start = dt_start;
> -    *size = dt_size;
> -}
> -
>  static int __init device_tree_get_meminfo(const void *fdt, int node,
>                                            const char *prop_name,
>                                            u32 address_cells, u32 size_cells,
> @@ -202,77 +169,6 @@ static int __init device_tree_get_meminfo(const void *fdt, int node,
>      return 0;
>  }
>  
> -uint32_t __init device_tree_get_u32(const void *fdt, int node,
> -                                    const char *prop_name, uint32_t dflt)
> -{
> -    const struct fdt_property *prop;
> -
> -    prop = fdt_get_property(fdt, node, prop_name, NULL);
> -    if ( !prop || prop->len < sizeof(uint32_t) )
> -        return dflt;
> -
> -    return fdt32_to_cpu(*(const uint32_t*)prop->data);
> -}
> -
> -/**
> - * device_tree_for_each_node - iterate over all device tree sub-nodes
> - * @fdt: flat device tree.
> - * @node: parent node to start the search from
> - * @func: function to call for each sub-node.
> - * @data: data to pass to @func.
> - *
> - * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
> - *
> - * Returns 0 if all nodes were iterated over successfully.  If @func
> - * returns a value different from 0, that value is returned immediately.
> - */
> -int __init device_tree_for_each_node(const void *fdt, int node,
> -                                     device_tree_node_func func,
> -                                     void *data)
> -{
> -    /*
> -     * We only care about relative depth increments, assume depth of
> -     * node is 0 for simplicity.
> -     */
> -    int depth = 0;
> -    const int first_node = node;
> -    u32 address_cells[DEVICE_TREE_MAX_DEPTH];
> -    u32 size_cells[DEVICE_TREE_MAX_DEPTH];
> -    int ret;
> -
> -    do {
> -        const char *name = fdt_get_name(fdt, node, NULL);
> -        u32 as, ss;
> -
> -        if ( depth >= DEVICE_TREE_MAX_DEPTH )
> -        {
> -            printk("Warning: device tree node `%s' is nested too deep\n",
> -                   name);
> -            continue;
> -        }
> -
> -        as = depth > 0 ? address_cells[depth-1] : DT_ROOT_NODE_ADDR_CELLS_DEFAULT;
> -        ss = depth > 0 ? size_cells[depth-1] : DT_ROOT_NODE_SIZE_CELLS_DEFAULT;
> -
> -        address_cells[depth] = device_tree_get_u32(fdt, node,
> -                                                   "#address-cells", as);
> -        size_cells[depth] = device_tree_get_u32(fdt, node,
> -                                                "#size-cells", ss);
> -
> -        /* skip the first node */
> -        if ( node != first_node )
> -        {
> -            ret = func(fdt, node, name, depth, as, ss, data);
> -            if ( ret != 0 )
> -                return ret;
> -        }
> -
> -        node = fdt_next_node(fdt, node, &depth);
> -    } while ( node >= 0 && depth > 0 );
> -
> -    return 0;
> -}
> -
>  static int __init process_memory_node(const void *fdt, int node,
>                                        const char *name, int depth,
>                                        u32 address_cells, u32 size_cells,
> -- 
> 2.43.0
> 


From xen-devel-bounces@lists.xenproject.org Fri Jun 06 23:55:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 23:55:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1008996.1388132 (Exim 4.92)
	(envelope-from )
	id 1uNgth-00086y-V9; Fri, 06 Jun 2025 23:54:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1008996.1388132; Fri, 06 Jun 2025 23:54:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNgth-00086r-SV; Fri, 06 Jun 2025 23:54:53 +0000
Received: by outflank-mailman (input) for mailman id 1008996;
 Fri, 06 Jun 2025 23:54: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 1uNgtg-00086l-Qt
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 23:54:52 +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 a213015d-4331-11f0-b894-0df219b8e170;
 Sat, 07 Jun 2025 01:54:50 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 73591A50B77;
 Fri,  6 Jun 2025 23:54:49 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id D3671C4CEED;
 Fri,  6 Jun 2025 23:54:47 +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: a213015d-4331-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749254088;
	bh=44MjKNPOARN8t9LHoRfQTQDq0eeo+ZnR1nLbNcNSuAw=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=gANAS0V7NUwsKoSwkWt37zn+7cfCK1T3Vi8NmHpdGud088KCfbcWY+fV0BIbWlnb1
	 80kfDHZwS3ilGtD5SJuy+VXs7QrLfnvvM6g/QViEKfflAZ9hdr597k6RbE01yVHTUR
	 2bupF9Pt6TknsscwSv5AWzlFDWSjWr8BTukYyGj/6qEXWSMNiIgHNeFBr2LHNQBTZ/
	 kvBhU72fJNE4muDop6lJBPqo997Re5k0J+ISCFpuR6Dty7FLhtSdcQOYG4bLd7vlQd
	 eIRJJxlbk9ue8AOwaVTSH0elcixbxq81BaLuLRrnzFM/IY9qX7WsE/LmJW8DDMaKES
	 umV4U5n7y7EYg==
Date: Fri, 6 Jun 2025 16:54:46 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    "Daniel P. Smith" 
Subject: Re: [PATCH v2 13/15] xen/dt: ifdef out DEV_DT-related bits from
 device_tree.{c,h}
In-Reply-To: <20250605194810.2782031-14-agarciav@amd.com>
Message-ID: 
References: <20250605194810.2782031-1-agarciav@amd.com> <20250605194810.2782031-14-agarciav@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Thu, 5 Jun 2025, Alejandro Vallejo wrote:
> ... which means, device-tree.c stops requiring strictly CONFIG_HAS_DEVICE_TREE
> and may function without it.
> 
> Not a functional change on architectures that currently use these files,
> as they already select CONFIG_HAS_DEVICE_TREE.
> 
> Signed-off-by: Alejandro Vallejo 

Reviewed-by: Stefano Stabellini 



From xen-devel-bounces@lists.xenproject.org Fri Jun 06 23:55:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 23:55:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1009000.1388142 (Exim 4.92)
	(envelope-from )
	id 1uNguD-00007u-63; Fri, 06 Jun 2025 23:55:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1009000.1388142; Fri, 06 Jun 2025 23:55: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 1uNguD-00007n-3G; Fri, 06 Jun 2025 23:55:25 +0000
Received: by outflank-mailman (input) for mailman id 1009000;
 Fri, 06 Jun 2025 23:55: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 1uNguB-00007O-Ir
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 23:55:23 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b48baee3-4331-11f0-b894-0df219b8e170;
 Sat, 07 Jun 2025 01:55:21 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 37E1860EDF;
 Fri,  6 Jun 2025 23:55:20 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 91735C4CEEB;
 Fri,  6 Jun 2025 23:55: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: b48baee3-4331-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749254119;
	bh=oMpEOIZKt/a1V4QeZJ1oEQ4kNXi9FwkTwzJ09ZlFaR0=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=NiqBHYNeLm8pokj+NZL1jhAjzMu9R89MWU9itm538lydY+QUJQA4sx6h11rXaUgo4
	 YtJSN8eEL4yhksEABO5U+P8sLL3UpqXYO56xGQJScxfWvPlDpL1suVpbiyV6gvsv50
	 yJeAcq1A7Z5Y2LvcMJ0a2sFc0vGkoKJ2+q/yS2ObLn3J5rlAUpU+KxOxQ9A21PPauQ
	 shV729bguxf4sSDqUkL1Yaoa/b4ht1dYtrwxTQfzsJcYLooZMJ6Cvny4grYL4iIS3Q
	 0v7ko4NShMvie7dPiW6pnYdM2+1OdxSs9Jxn0c2g53xnUKacmOuYRq3Y9e2MWuur5p
	 AUtDhlukjzmFw==
Date: Fri, 6 Jun 2025 16:55:17 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
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 , 
    Bertrand Marquis , 
    "Daniel P. Smith" 
Subject: Re: [PATCH v2 14/15] xen/dt: Allow CONFIG_DOM0LESS_BOOT to include
 device-tree/
In-Reply-To: <20250605194810.2782031-15-agarciav@amd.com>
Message-ID: 
References: <20250605194810.2782031-1-agarciav@amd.com> <20250605194810.2782031-15-agarciav@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Thu, 5 Jun 2025, Alejandro Vallejo wrote:
> ... without CONFIG_HAS_DEVICE_TREE
> 
> Signed-off-by: Alejandro Vallejo 

Reviewed-by: Stefano Stabellini 



From xen-devel-bounces@lists.xenproject.org Fri Jun 06 23:57:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jun 2025 23:57:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1009008.1388152 (Exim 4.92)
	(envelope-from )
	id 1uNgwD-0000hA-HE; Fri, 06 Jun 2025 23:57:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1009008.1388152; Fri, 06 Jun 2025 23: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 1uNgwD-0000h3-Dp; Fri, 06 Jun 2025 23:57:29 +0000
Received: by outflank-mailman (input) for mailman id 1009008;
 Fri, 06 Jun 2025 23:57: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 1uNgwB-0000gw-HW
 for xen-devel@lists.xenproject.org; Fri, 06 Jun 2025 23:57:27 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org
 [2600:3c04:e001:324:0:1991:8:25])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fe99b582-4331-11f0-a303-13f23c93f187;
 Sat, 07 Jun 2025 01:57:26 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 648D660EDF;
 Fri,  6 Jun 2025 23:57:25 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id BE081C4CEEB;
 Fri,  6 Jun 2025 23:57: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: fe99b582-4331-11f0-a303-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749254245;
	bh=7k95ME6hm6nyrfXdhqK/1HpmPSqG90IAsONq42yRleM=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=rFgJpU/3lX0qgCWVhr83D4ZKfzGtXPVYVj8R4L1FQdW6z91AIWiA83yd6mWNchiqr
	 TUB/lQHZbLGAI/2Z1lF/5kdwHkaf+TVyW4igaosQHvIqpqCn+x1rdcCGELY2hBQKpo
	 yAvdsQAcQpP9E2RSjvBhE0cIro/QEd6h6/7SZqHAbfmHOsuhvxtCJJ7QAfKl6yIaRZ
	 ink3IME0biUqFwshr+wKb5hPxXIYo2yK39h1g28iIqGRpxWHepQP7BoSrA/p7AX9Kr
	 5BzHI4MHMCPhMp0vgYU+4YI6m/6I9XLjuBSns++iEQ2mTKs0jl8Rb/+WNfyeD5W3UO
	 okJXjiEqk0Zgg==
Date: Fri, 6 Jun 2025 16:57:22 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: xen-devel@lists.xenproject.org, Jan Beulich , 
    Andrew Cooper , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Anthony PERARD , 
    Michal Orzel , Julien Grall , 
    Stefano Stabellini , 
    Bertrand Marquis , 
    "Daniel P. Smith" 
Subject: Re: [PATCH v2 15/15] kconfig: Allow x86 to pick
 CONFIG_DOM0LESS_BOOT
In-Reply-To: <20250605194810.2782031-16-agarciav@amd.com>
Message-ID: 
References: <20250605194810.2782031-1-agarciav@amd.com> <20250605194810.2782031-16-agarciav@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Thu, 5 Jun 2025, Alejandro Vallejo wrote:
> Without picking CONFIG_HAS_DEVICE_TREE.
> 
> In order to do that. Allow CONFIG_DOM0LESS_BOOT to enable a subset
> of the common/device-tree/ directory. x86 doesn't want dom0less-build.c,
> as that's tightly integrated still to the ARM way of building domains.
> 
> Requires "unsupported" for the time being until all required patches
> make it through.
> 
> Signed-off-by: Alejandro Vallejo 

Reviewed-by: Stefano Stabellini 



From xen-devel-bounces@lists.xenproject.org Sat Jun 07 07:19:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Jun 2025 07:19:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1009168.1388162 (Exim 4.92)
	(envelope-from )
	id 1uNnpI-0000JK-1Q; Sat, 07 Jun 2025 07:18:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1009168.1388162; Sat, 07 Jun 2025 07:18:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uNnpH-0000JD-U4; Sat, 07 Jun 2025 07:18:47 +0000
Received: by outflank-mailman (input) for mailman id 1009168;
 Sat, 07 Jun 2025 07:18:47 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uNnpH-0000J7-5Q
 for xen-devel@lists.xenproject.org; Sat, 07 Jun 2025 07:18:47 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uNnpG-006oKL-1H;
 Sat, 07 Jun 2025 07:18:46 +0000
Received: from [2a02:8012:3a1:0:7807:532b:1d1d:b850]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uNnpG-00Gx7Q-23;
 Sat, 07 Jun 2025 07: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" 
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=59QHEkKEeW5Owl9sVRCdlgls8zxxBjK7/Nu3Dbot8vE=; b=xFZfrTMz/7+eIG96lC1/AVXi42
	hiCvOOqofqt8cibFLPQteHao7wVRbIDrXCTYI8vqys/XUwGVa0zQz7FOmhs2E3gEZX0l9wH+JfoKP
	8NoR0ne3P0mmOdtL42/49lT97Md6qdb47JLO4JgRe5PQhhG4aAvQwzrgB7aNja6Zob5k=;
Message-ID: <4512cd95-efea-4962-a20d-6165c2c0d2a5@xen.org>
Date: Sat, 7 Jun 2025 08:18:44 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 1/3] xen/domain: unify domain ID allocation
Content-Language: en-GB
To: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com,
 anthony.perard@vates.tech, jbeulich@suse.com, roger.pau@citrix.com,
 sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com
References: <20250528225030.2652166-1-dmukhin@ford.com>
 <20250528225030.2652166-2-dmukhin@ford.com>
  
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Denis,

On 06/06/2025 07:55, dmkhn@proton.me wrote:
> On Thu, Jun 05, 2025 at 10:58:48PM +0100, Julien Grall wrote:
>>> +        if ( domid == DOMID_INVALID )
>>> +            panic("Error allocating ID for domain %s\n", dt_node_name(node));
>>> +
>>> +        d = domain_create(domid, &d_cfg, flags);
>>>            if ( IS_ERR(d) )
>>>                panic("Error creating domain %s (rc = %ld)\n",
>>>                      dt_node_name(node), PTR_ERR(d));
>>> diff --git a/xen/common/domain.c b/xen/common/domain.c
>>> index abf1969e60..ae0c44fcbb 100644
>>> --- a/xen/common/domain.c
>>> +++ b/xen/common/domain.c
>>> @@ -66,6 +66,10 @@ DEFINE_RCU_READ_LOCK(domlist_read_lock);
>>>    static struct domain *domain_hash[DOMAIN_HASH_SIZE];
>>>    struct domain *domain_list;
>>>
>>> +/* Non-system domain ID allocator. */
>>> +static DEFINE_SPINLOCK(domid_lock);
>>> +static DECLARE_BITMAP(domid_bitmap, DOMID_FIRST_RESERVED);
>>> +
>>>    /*
>>>     * 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.
>>> @@ -1449,6 +1453,8 @@ void domain_destroy(struct domain *d)
>>>
>>>        TRACE_TIME(TRC_DOM0_DOM_REM, d->domain_id);
>>>
>>> +    domid_free(d->domain_id);
>>> +
>>>        /* Remove from the domlist/hash. */
>>>        domlist_remove(d);
>>>
>>> @@ -2405,6 +2411,54 @@ domid_t get_initial_domain_id(void)
>>>        return hardware_domid;
>>>    }
>>>
>>> +domid_t domid_alloc(domid_t domid)
>>> +{
>>> +    spin_lock(&domid_lock);
>>> +
>>> +    if ( domid < DOMID_FIRST_RESERVED )
>>> +    {
>>> +        if ( __test_and_set_bit(domid, domid_bitmap) )
>>> +            domid = DOMID_INVALID;
>>> +    }
>>> +    else
>>> +    {
>>> +        static domid_t domid_last;
>>> +        /* NB: account for late hwdom case, skip ID#0 */
>>
>> I am somewhat confused with this comment. For the late hwdom case, I
>> thought we were using a non-zero ID. Dom0 should also always be the
>> first dom0 to be reserved. Can you clarify?
> 
> My current understanding is:
> - the ID of "domain 0" (privileged domain) can be overridden at the boot-time
>    via hardware_domid parameter.
 > > - there's only one reserved (and configurable) domain ID == 
hardware_domid in
>    the allocation range (which is 0 by default).
 > > - get_initial_domain_id() returns the reserved domain ID value 
(which is
>    used in the in the follow on change to keep the change isolated).
> 
> Is my understanding correct?

I have replied yesterday night on a separate thread about this behavior 
[1]. Rather than duplicating it, I would suggest to move the 
conversation there.

In short, I believe the late domain support was recently broken.

Cheers,

[1] 
https://lore.kernel.org/xen-devel/20250528225030.2652166-1-dmukhin@ford.com/T/#mdcdf3802a913859243ff6ce841
445cfab265145f

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Sat Jun 07 20:56:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Jun 2025 20:56:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1009521.1388172 (Exim 4.92)
	(envelope-from )
	id 1uO0aD-0008WL-MX; Sat, 07 Jun 2025 20:56:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1009521.1388172; Sat, 07 Jun 2025 20:56:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uO0aD-0008W6-Gf; Sat, 07 Jun 2025 20:56:05 +0000
Received: by outflank-mailman (input) for mailman id 1009521;
 Sat, 07 Jun 2025 20:56: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 1uO0aC-0008W0-De
 for xen-devel@lists.xenproject.org; Sat, 07 Jun 2025 20:56:04 +0000
Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d177efef-43e1-11f0-a304-13f23c93f187;
 Sat, 07 Jun 2025 22:56:02 +0200 (CEST)
Received: from m5p.com (mailhost.m5p.com [IPv6:2001:470:8ac4:0:0:0:0:f7])
 by mailhost.m5p.com (8.18.1/8.17.1) with ESMTPS id 557Ktk99099307
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
 Sat, 7 Jun 2025 16:55:52 -0400 (EDT) (envelope-from ehem@m5p.com)
Received: (from ehem@localhost)
 by m5p.com (8.18.1/8.15.2/Submit) id 557KtkLS099306;
 Sat, 7 Jun 2025 13:55:46 -0700 (PDT) (envelope-from ehem)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d177efef-43e1-11f0-a304-13f23c93f187
Date: Sat, 7 Jun 2025 13:55:46 -0700
From: Elliott Mitchell 
To: me@alex0.net
Cc: xen-devel@lists.xenproject.org
Subject: Re: xen_acpi_processor driver is bound to dom0 vcpu count
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 Fri, May 23, 2025 at 12:22:44AM +0100, me@alex0.net wrote:
> I think I’ve just uncovered a rather nasty bug in the xen_acpi_processor driver in dom0. If the vcpu count in dom0 is set to anything other than the exact number of physical cores, the xen_acpi_processor kernel driver will fail to upload the C-state information for those cores to Xen, resulting in Xen never knowing about the C-states, which significantly impacts battery life on mobile platforms.
> 

While I dislike this bug, I don't think it qualifies as "nasty" since it
doesn't severely break anything.  Your system ends up using rather more
power than it should, but everything else continues to works as expected.

The simplest workaround is to not use dom0_max_vcpus, and instead do
`xl vcpu-set 0 #` to offline vCPUs after boot.  This leaves domain 0
allocating per-processor memory for unused processors, but does reduce
domain 0's vCPU use.

I believe this is partially bugs with Xen's ACPI support, but also an
issue with the Linux kernel module.  I've observed patches going by which
appeared aimed towards this problem, but for now this remains.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include  O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445




From xen-devel-bounces@lists.xenproject.org Sun Jun 08 09:49:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Jun 2025 09:49:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1009830.1388182 (Exim 4.92)
	(envelope-from )
	id 1uOCeO-0002h5-15; Sun, 08 Jun 2025 09:49:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1009830.1388182; Sun, 08 Jun 2025 09:49: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 1uOCeN-0002gx-Sc; Sun, 08 Jun 2025 09:49:11 +0000
Received: by outflank-mailman (input) for mailman id 1009830;
 Sun, 08 Jun 2025 09:49: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 1uOCeM-0002gr-Nb
 for xen-devel@lists.xenproject.org; Sun, 08 Jun 2025 09:49:10 +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 d2566a88-444d-11f0-b894-0df219b8e170;
 Sun, 08 Jun 2025 11:49:08 +0200 (CEST)
Received: by mail-lj1-x230.google.com with SMTP id
 38308e7fff4ca-32a806ef504so26740581fa.3
 for ; Sun, 08 Jun 2025 02:49:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d2566a88-444d-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749376147; x=1749980947; 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=Lho+8TmrzraE4kuO5oYi+PN34j0t0i7LoT4n3zIzQ3A=;
        b=c8mwwYC4YDDmnbX/mNwjbJo4fEvu/xTZvhZqBKaIrBdg4zlESa/ZWTl1R5IIgCiSHt
         7nVV813zPsh9HAMvEBTmzceAdnMsa8R9RHpo6WFux/m4ZsCGIVzjENX7Py6khJ3h58+y
         uYctVWmCXjaUCWdqjjLrczc/SGk1Kn5o5t/KlG+BXkq9jC9Ygi8RxyP4SCmDTP5BRNRe
         gATwXHwNMPrb89N0h17CB5I6wsfrqvvW73uVhO8m+ahBsKDmitbJX/KBRGldh7n9B83+
         ZxH+xNrMPI9n5YlxM3TnbWpCwPZKEf1+/sWKNIecDWZVL+0Fvg3PFptVaJ/QV6Wr6SR8
         GcPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749376147; x=1749980947;
        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=Lho+8TmrzraE4kuO5oYi+PN34j0t0i7LoT4n3zIzQ3A=;
        b=mry6XNIW4Wz9JS5AUUof10Motna46Opyrbt1Eu6EjHFR16MAuQMxfZQgYBWtQByYj+
         EeIjvaCo0TUm0NMq4y9ltFaM9R8Gw9obZa15Gk0gPaspOFBc2bZIXYLBUPFghnplGcox
         Qnut2hbg9TbgVlOXt9kPYUrcKahot71RNpcyxO3LPZZIWZWkocZmfxg76NOwBBarIse1
         uus/oi/D5isu8GGLkYwTj1NdJZs+SvorlZ0Fv/DX4DAEZ9nCu5EOnHbMKETY6PQ1Rc8e
         fpsaoCb5HBwXP76dz6qGcPLapswxY2VVDPDK5kyEhSGYAdtUB1aYdM8NoGvBLOFEr8A5
         IwIA==
X-Forwarded-Encrypted: i=1; AJvYcCXkFUmRoOWWZ0Oc7JEiXsPfRENwMeRSOQHwlIzeqQTPtAA2Of+IRRZIadt9fkYnawHT+g3M1oflZl0=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz2KxJjE46BV/Ee27/8ZSZRKTs28w7OsXxC7C4FOY2pA9hRMay1
	J6K7av45tbbMcGQETduskvSFCTUTy3XYpzHdhJqf1FG6M4Pr4H4DNL1u6v8B4pxe78eaKra8bAY
	rkic1m7W3/MflDrM05kdt3LJ5Vn7gYyE=
X-Gm-Gg: ASbGnctFwFDXNOKE0r9tYo9mKEPPjri9qj2eeVLs7tX05v1VMNBHjMx7/J64qGVDB5J
	a/hPFPX1hkF0YMEAtU/sgicATh62nS2X3/fxqrxSxfdwaVN4pmulOmPJd2SjgRfxWzuMgvh3Lz7
	2ag4RPOg7OTVA2PDecNljWuy0UPwhh7fo=
X-Google-Smtp-Source: AGHT+IGjYMGUINRU+YhQ9P2FvvafnAs0jQvZxnhTwX4KyJObpxEKGNsqlbaqhxrmfo6c7lhSK8xUacgk5ias5CFs3Rs=
X-Received: by 2002:a2e:a9a0:0:b0:32a:6c8a:570c with SMTP id
 38308e7fff4ca-32adfc0efcfmr26379681fa.25.1749376146894; Sun, 08 Jun 2025
 02:49:06 -0700 (PDT)
MIME-Version: 1.0
References: <20250528211040.10562-1-christopher.w.clark@gmail.com>
  
In-Reply-To: 
From: Christopher Clark 
Date: Sun, 8 Jun 2025 10:48:55 +0100
X-Gm-Features: AX0GCFuww2J3Al28WE4LiPuwCmhymMegSf7S2NkFJuP_X3ENL6lx_6GSii_0p2Y
Message-ID: 
Subject: Re: [PATCH v3 1/3] docs: add documentation for Argo as a feature
To: Jason Andryuk 
Cc: Teddy Astie , xen-devel@lists.xenproject.org, 
	Daniel Smith , Rich Persaud , 
	Andrew Cooper , Anthony PERARD , 
	Michal Orzel , Jan Beulich , Julien Grall , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Stefano Stabellini 
Content-Type: multipart/alternative; boundary="000000000000d0778206370c5f92"

--000000000000d0778206370c5f92
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 4, 2025 at 5:14=E2=80=AFPM Jason Andryuk  wrote:

> On 2025-05-29 18:40, Teddy Astie wrote:
> > Hello Christopher,
> >
> > Le 28/05/2025 =C3=A0 23:13, Christopher Clark a =C3=A9crit :
>
> >> +## Argo and VirtIO
> >> +
> >> +References to design documentation for the development of an Argo
> >> +transport for VirtIO are available via:
> >> +https://wiki.xenproject.org/wiki/Virtio_On_Xen
> >> +
> >
> > Are there news regarding this ?
> >
> > There is work done on virtio-msg [1], which looks fairly similar to
> > virtio-argo (or at least, virtio-msg could work with Argo in a similar
> > fashion to what's described on the virtio-argo design).
> >
> > [1] https://linaro.atlassian.net/wiki/spaces/HVAC/overview


I appreciate the interest - I don't have additional material on it at the
moment.


>
> I think this should be dropped.  We don't need a link to a design
> document without an implementation.  You can add it once you've
> upstreamed the implementation.
>

OK, I'll remove this section for the next version of the series.


>
> >> +# Known issues
> >> +
> >> +* For development: sysctl/domctls for toolstack to control per-VM
> access
> >> +  to Argo
> >> +
> >
> > Is it regarding disabling the argo on a per-guest basis, or regarding i=
f
> > a specific VM can communicate with another VM ? i.e can the toolstack
> > decide to prevent 2 guest from communicating ?
> >
> > IIRC, in Argo, a guest on his own can decide who can communicate with
> > him using separate registered rings. But I am not sure if there is more
> > on that regard.
>

It's to do with enabling administrative controls for the toolstack to be
able to govern access to Argo by individual VMs on a per-VM basis. At the
moment there is a host boot option that turns it on or off for the system
and there are XSM/Flask policy controls that govern access to Argo by
individual VMs on a per-VM basis, but that is less accessible for a system
administrator to apply changes to VM access and less dynamic than some use
cases may require.


>
> Yes, I think the existing text needs to be rephrased to be more explicit
> on the issue.  I can guess what it is, but I shouldn't have to.  I'd
> recommend stating the issue as it exists, and then optionally clearly
> state a proposed solution.
>

Fair, thanks, will revise it.

Christopher

--000000000000d0778206370c5f92
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


    On Wed, Jun 4, 2025 at 5:14=E2=80=AFPM Ja=
son Andryuk <jason.andryuk@amd.=
com> wrote:
    On 2025-05-29 18:40, Teddy =
Astie wrote:
    
> Hello Christopher,
    
> 
    
> Le 28/05/2025 =C3=A0 23:13, Christopher Clark a =C3=A9crit=C2=A0:
    

    
>> +## Argo and VirtIO
    
>> +
    
>> +References to design documentation for the development of an Argo=

    
>> +transport for VirtIO are available via:
    
>> +https://wiki.xenproject.org/wiki/Virtio_On_X=
en
    
>> +
    
> 
    
> Are there news regarding this ?
    
> 
    
> There is work done on virtio-msg [1], which looks fairly similar to
> virtio-argo (or at least, virtio-msg could work with Argo in a similar=

    
> fashion to what's described on the virtio-argo design).
    
> 
    
> [1] https://linaro.atlassian.net/wiki/spa=
ces/HVAC/overview

    I appreciate the inte=
rest - I don't have additional material on it at the moment.
    =
=C2=A0

    
I think this should be dropped.=C2=A0 We don't need a link to a design =

    
document without an implementation.=C2=A0 You can add it once you've 
upstreamed the implementation.

    OK, I=
9;ll remove this section for the next version of the series.
    =C2=
=A0
    

    
>> +# Known issues
    
>> +
    
>> +* For development: sysctl/domctls for toolstack to control per-VM=
 access
    
>> +=C2=A0 to Argo
    
>> +
    
> 
    
> Is it regarding disabling the argo on a per-guest basis, or regarding =
if
    
> a specific VM can communicate with another VM ? i.e can the toolstack<=
br>
> decide to prevent 2 guest from communicating ?
    
> 
    
> IIRC, in Argo, a guest on his own can decide who can communicate with<=
br>
> him using separate registered rings. But I am not sure if there is mor=
e
    
> on that regard.

    It's to do wit=
h enabling administrative controls for the toolstack to be able to govern a=
ccess to Argo by individual VMs on a per-VM basis. At the moment there is a=
 host boot option that turns it on or off for the system and there are XSM/=
Flask policy controls that govern access=C2=A0to Argo by individual VMs on =
a per-VM basis, but that is less accessible for a system administrator to a=
pply changes to VM access and less dynamic than some use cases may require.=

    =C2=A0
    

    
Yes, I think the existing text needs to be rephrased to be more explicit 
on the issue.=C2=A0 I can guess what it is, but I shouldn't have to.=C2=
=A0 I'd 
    
recommend stating the issue as it exists, and then optionally clearly 
    
state a proposed solution.

    Fair, thanks=
, will revise it.

    Christopher
    

--000000000000d0778206370c5f92--


From xen-devel-bounces@lists.xenproject.org Sun Jun 08 18:38:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Jun 2025 18:38:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010000.1388195 (Exim 4.92)
	(envelope-from )
	id 1uOKtz-0004Bm-AS; Sun, 08 Jun 2025 18:37:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010000.1388195; Sun, 08 Jun 2025 18: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 1uOKtz-0004BU-5V; Sun, 08 Jun 2025 18:37:51 +0000
Received: by outflank-mailman (input) for mailman id 1010000;
 Sun, 08 Jun 2025 18:37: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 1uOKty-0004BM-BR
 for xen-devel@lists.xenproject.org; Sun, 08 Jun 2025 18:37:50 +0000
Received: from mail-il1-x136.google.com (mail-il1-x136.google.com
 [2607:f8b0:4864:20::136])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id acbd757e-4497-11f0-a304-13f23c93f187;
 Sun, 08 Jun 2025 20:37:48 +0200 (CEST)
Received: by mail-il1-x136.google.com with SMTP id
 e9e14a558f8ab-3ddd2710d14so20267485ab.2
 for ; Sun, 08 Jun 2025 11:37:48 -0700 (PDT)
Received: from smtpclient.apple (216-131-77-230.ord.as62651.net.
 [216.131.77.230]) by smtp.gmail.com with ESMTPSA id
 8926c6da1cb9f-500df421ba4sm1427875173.44.2025.06.08.11.37.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 08 Jun 2025 11:37:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: acbd757e-4497-11f0-a304-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749407867; x=1750012667; darn=lists.xenproject.org;
        h=to:in-reply-to:cc:references:message-id:date:subject:mime-version
         :from:content-transfer-encoding:from:to:cc:subject:date:message-id
         :reply-to;
        bh=pX/ARDRvaQNzbhhMjpqA1HTQhNfsIMGOzvjaAGIsCgk=;
        b=DTxhmbdhO8bb6MrurWdSJ9htzI3EJ29Y+JuATkeDHaUsRt9HfN/F54r3irxmNYULOU
         rqi6ZGwOmuLmgxZ6aoyIX7EdZr7xY1q0LeP7rExzsODDdEBx3ZN36XeDLcOYNQT7uhuA
         p52VwVVBUoLNZPvgPjxHDQNULutdbQOEjvDl/QXQcn/E36Izp34mewIKmyI6zk72wJt5
         rQDyVg1NnQwfGsRD+d80hqjUxDZeDVlc3z7Rvz+lGr+yLfbp3IjGzIxqWMu+Cvls9zbA
         KVx7K83KspQ4dKn1smZubNywyjP5oJUYTkPF/7vNsECSX837l9I4sdmCKv6mBvt1ZOTL
         19eQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749407867; x=1750012667;
        h=to:in-reply-to:cc:references:message-id:date:subject:mime-version
         :from:content-transfer-encoding:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=pX/ARDRvaQNzbhhMjpqA1HTQhNfsIMGOzvjaAGIsCgk=;
        b=bALkvNpviC4pcALOR2v/duyCOTinzXzgjuxcZmD/nHp6aNywuQ2g1TnryHiNxJrbYw
         lBKAhG8pDkoaqqyzgA0W0z7aNjaBhWn3ea/2OmTXxmblzE3jjjXH+x24Cwbh67+4rDoz
         gfJvKz5npE6vCHsm+Qzk6H+bnKvXnzEcm8qY9JvJ+eC7FoU/PWprjR1C26rl5hJ/VCWt
         116H/Mzrh0sEyvuJ0fuXSQPOPAq7qMNWCORt/Ncx1YEe5TPV6ZZUfsiNDQbr+dT+PnnV
         iRwpoE/g4tSPE8MiGnlNC6DdFgrMPU3DV9s6KTnpP6DY2rV8mhSqAISzf/a5lWmWh5oO
         vRVg==
X-Forwarded-Encrypted: i=1; AJvYcCXQ3X8YYhbSi79z8OPjgX0E0fGZFs8OlArH+SaLXeCEXf70pax5INoeAEx+mAfSAOLQ8e35GV4EVbw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yze1vM7PaeFFa+Hra6lZgs4BLHpcu07cO8b92/r1WgBYMYqnSad
	yGFcMCHFrMyZ50Jua04AX7Ve4qhnatWmUZ8yjgdNOn7+vCGYVTnupBlD
X-Gm-Gg: ASbGncuZWNDG0ynYgNnR/lkdH+EqcRkTC5oPkLukGFNTq+OY63K/L0DiscEa8/eE+AM
	IfdhjLcE3X+X5h3O1yGVXGmOmVaB559BDY7xhshFWRisCbs0UY4MQjuDE05c07VsU3XiPfTJvT3
	lvdvAg9kYvuUv2FtxqaftouyKPACb8mBuBcVHDvtYEMgukq85qMawvKSZ5z0YhIn2417YqptI+b
	T0qxZmt193bB8r1qTrXBC4nJzx5B0VgADU6h2fS+GqN2bfkseOAq0dusrFV8DD6pkXrfn7RsV/H
	dUIM5tSIJ9BawKn/l5G2taEJCAMIIJMd8xLZoHVUa5UJvc1c5hmHgVngSLD1wIaNn1wikGuFJGn
	pxQ9MjNbBFlxDITQUssEGBQ==
X-Google-Smtp-Source: AGHT+IGHzSRBU/gbP2XiSJzFgmFqnJUGk52IWbYBo/VgYbQXExah2tmVxcd6eXF799keQEBAEJVOZQ==
X-Received: by 2002:a05:6e02:1a26:b0:3dd:c78c:ec3e with SMTP id e9e14a558f8ab-3ddce49109emr128643415ab.22.1749407867060;
        Sun, 08 Jun 2025 11:37:47 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-04498CCF-82CE-41A8-8EBA-F5EE56B73C31
Content-Transfer-Encoding: 7bit
From: Rich Persaud 
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH v3 1/3] docs: add documentation for Argo as a feature
Date: Sun, 8 Jun 2025 14:37:34 -0400
Message-Id: <2EAAC8E1-2342-48F4-9B2E-849551291F22@gmail.com>
References: 
Cc: Jason Andryuk ,
 Teddy Astie ,
 Daniel Smith ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Julien Grall ,
 =?utf-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini 
In-Reply-To: 
To: Christopher Clark ,
 xen-devel@lists.xenproject.org
X-Mailer: iPad Mail (22F76)


--Apple-Mail-04498CCF-82CE-41A8-8EBA-F5EE56B73C31
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


    On J=
un 8, 2025, at 5:49=E2=80=AFAM, Christopher Clark <christopher.w.clark@gm=
ail.com> wrote:
    =EF=BB=BF=

    On Wed, Jun 4, 2025 at 5:14=E2=80=AFPM Jason Andryuk <=
;jason.andryuk@amd.com> wrot=
e:

    
I think this should be dropped.  We don't need a link to a design 
    
document without an implementation.  You can add it once you've 
    
upstreamed the implementation.

    OK, I'll r=
emove this section for the next version of the series.

    What's the recommended location of Xen design docume=
nts, requirements for future improvements, roadmaps or pointers to related w=
ork in adjacent open-source communities? The Xen wiki is being deprecated.

    What's the recommended way for the Xen community to d=
iscover the existence of Argo documentation that is not hosted by the Xen co=
mmunity? If necessary, we can create a new semantic label or Xen docs direct=
ory tree, to host technical content that might otherwise be lost.
    =

    Should we add a sentence to Xen's Argo documentation, to the e=
ffect of "Please refer to the Xen [wiki in archive.org, website, mailing lis=
t], external sites [A, B, C, D], or your preferred [search engine, LLM] for m=
ore technical documents on Argo design and implementation"?

    Rich
    =

--Apple-Mail-04498CCF-82CE-41A8-8EBA-F5EE56B73C31--


From xen-devel-bounces@lists.xenproject.org Sun Jun 08 20:52:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Jun 2025 20:52:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010038.1388204 (Exim 4.92)
	(envelope-from )
	id 1uON0D-00031j-5Y; Sun, 08 Jun 2025 20:52:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010038.1388204; Sun, 08 Jun 2025 20: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 1uON0D-00031c-2B; Sun, 08 Jun 2025 20:52:25 +0000
Received: by outflank-mailman (input) for mailman id 1010038;
 Sun, 08 Jun 2025 20:52:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uON0B-00031W-Ko
 for xen-devel@lists.xenproject.org; Sun, 08 Jun 2025 20:52:23 +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 78f44b1b-44aa-11f0-b894-0df219b8e170;
 Sun, 08 Jun 2025 22:52:21 +0200 (CEST)
Received: by mail-lj1-x230.google.com with SMTP id
 38308e7fff4ca-32b019bdeaaso3597621fa.0
 for ; Sun, 08 Jun 2025 13:52:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 78f44b1b-44aa-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749415941; x=1750020741; 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=jiD4rSsm0cbKmHaYBj8e0g7Y2LMzANTCDe2PowGXfAs=;
        b=Dt6Ih2LVuljTpvzjPxckey0oTy6dcdfGfeA5acZgiVrQHX2OnsO93xZvkL6xJcrpgD
         05lyr+h5unCkNJYDs9whiqn7YZp7nEBAEt2YHVkQEvh8TvLbtrbef6jbAvEpUSHB1+nv
         wqmKa2a531SPzeU927lekvGklltjaSJD5SR4x6KToyJOEh9KCLQkIFR+7h+z6lSsa3lY
         JgU6KN/eid9eSTQfm1GcdjzfURv2RGWJ4HTTYjd1ifuUMBdXzbhC/xHoqozdNBqxPMnU
         sPcJwlbQIP5rneditAfGIQgYvb4sXQUrb+zfgLOsdRmyfMQk8jOfG7eTSGsgF/85e2R0
         Cv7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749415941; x=1750020741;
        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=jiD4rSsm0cbKmHaYBj8e0g7Y2LMzANTCDe2PowGXfAs=;
        b=NUWQ/o/kfGsHu6elS5jmE15TIh5qdEd/TtN2qOo64I+1DFhuy+IIT2u9Jfqs75UfVD
         2tyiJiutI9rJUa6JcALKsTzPdkcwJ4Ajx8/g8k0NktGigmSvPxwaYHz49lRvsJZ8K2yo
         pf4N9001F06k9pjzvkVWQvWE9X56SO1ojrD1TAo6l4ShQRShxSJWHmN4LqTqMYSt9lx8
         AyJz4yiMnXeG1WwH9fAq4BsV0J9rNx/locdwOxVjKqVSv4lRQYqMHVEOAcGmB6WLYFWG
         4+sq1qisjZtSZZleY6c5cMtvEeLqiRlA1j/4OdJQt2lBiXcP8ARdTRhnDldOC1RLu8bo
         HgCQ==
X-Gm-Message-State: AOJu0YyiGdsqtUDdlRHXEAokXXDEvzK/cruNYyOvScFVc6j7czSIJue9
	4yab/sPUBHrHoFqyW2aP619CSRypNjxRkvBW3uQWowvW+i3s3hPC2oBKh2DHrjI6y9ieIzQeh3K
	aKyEH/mUDXnlKPB4Xj49/m/JyvMTkCHI=
X-Gm-Gg: ASbGncuFFcOLZ3Jcmk7FecytpAu1Wopkep9gwhWuBldS4uCmV4L+xz2fShZEySLv6uw
	9O4bQsWd1RdQc8MSgoKunGkSVlcEOA74NfDeDq+LLlqiYs7iPpBfT/ojl7g1ZbxsUJTo+aKLOmT
	ZusSgdpuyCeU9G0ougZ2+sxoK1gBm357dLoX69OL67pg==
X-Google-Smtp-Source: AGHT+IELmomZm+dVKeBh2MmdMlQBzwDw4r9+kpmn1u0Tmr4m+OSd5O5GSwKGL25Mw9NewgnghMJaPtJxPkBYzacTLwU=
X-Received: by 2002:a2e:a585:0:b0:32a:864a:46e4 with SMTP id
 38308e7fff4ca-32adfcd4f8cmr28300131fa.3.1749415940394; Sun, 08 Jun 2025
 13:52:20 -0700 (PDT)
MIME-Version: 1.0
References: 
 <2EAAC8E1-2342-48F4-9B2E-849551291F22@gmail.com>
In-Reply-To: <2EAAC8E1-2342-48F4-9B2E-849551291F22@gmail.com>
From: Christopher Clark 
Date: Sun, 8 Jun 2025 21:52:09 +0100
X-Gm-Features: AX0GCFuTtWHOqhfNn6nlrKGXPPjvcpB2tuRNY3y8Vi5WOGJ21wdupvh_2yNhgdI
Message-ID: 
Subject: Re: [PATCH v3 1/3] docs: add documentation for Argo as a feature
To: Rich Persaud 
Cc: xen-devel@lists.xenproject.org, Jason Andryuk , 
	Teddy Astie , Daniel Smith , 
	Andrew Cooper , Anthony PERARD , 
	Michal Orzel , Jan Beulich , Julien Grall , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Stefano Stabellini , 
	Community Manager 
Content-Type: multipart/alternative; boundary="000000000000b1148d063715a347"

--000000000000b1148d063715a347
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Jun 8, 2025 at 7:37=E2=80=AFPM Rich Persaud  wro=
te:

> On Jun 8, 2025, at 5:49=E2=80=AFAM, Christopher Clark <
> christopher.w.clark@gmail.com> wrote:
>
> =EF=BB=BF
>
> On Wed, Jun 4, 2025 at 5:14=E2=80=AFPM Jason Andryuk 
> wrote:
>
>>
>> I think this should be dropped.  We don't need a link to a design
>> document without an implementation.  You can add it once you've
>> upstreamed the implementation.
>>
>
> OK, I'll remove this section for the next version of the series.
>
>
> What's the recommended location of Xen design documents, requirements for
> future improvements, roadmaps or pointers to related work in adjacent
> open-source communities? The Xen wiki is being deprecated.
>

Others CCd are likely better qualified than I to answer these (reasonable)
questions, and I am interested to learn from any further answers.

My preferred option is not to deprecate the wiki, or at least not without a
replacement for it. I have found the wiki to be useful for many years for
both publishing technical content and for access to helpful material not
available anywhere else, even if the contents are rougher than the formal
documentation. Its accessibility is an essential part of enabling that.

If the wiki is deprecated, the available alternatives appear to be:

* Pursuing formal acceptance of documents into one of the Xen git
repositories;
>From my experience of doing so, less documentation will be produced if this
is the standard required and unique knowledge will be lost at an ongoing
cost to both the developer community and users of Xen. Review capacity is
already scarce and this will further deplete that.

* Publishing on the platforms of adjacent communities;
Documentation will be less discoverable and at the mercy of external tools
and processes, again at a cost to collaboration within the Xen community.

* Repurposing the Xen issue tracker
This would be a horrible bodge. Please no.

* Self-hosting - similar to publishing in an adjacent community, but worse
I would prefer not to have to do this and may not have time available to
do so. Not everyone is able to.

* Replace the wiki with another collaboratively-edited document hosting
platform
I am open to learning more about options for this if it is the recommended
direction.


> What's the recommended way for the Xen community to discover the existenc=
e
> of Argo documentation that is not hosted by the Xen community? If
> necessary, we can create a new semantic label or Xen docs directory tree,
> to host technical content that might otherwise be lost.
>
> Should we add a sentence to Xen's Argo documentation, to the effect of
> "Please refer to the Xen [wiki in archive.org, website, mailing list],
> external sites [A, B, C, D], or your preferred [search engine, LLM] for
> more technical documents on Argo design and implementation"?
>

The Virtio & Argo design documents, produced within an adjacent community
so they are hosted there, are relevant to Xen and ought to be enabled to be
discoverable (and if necessary hostable) via Xen community platforms.
They are also a single instance of a general class: there will be
developments of other Xen-related features within XCP-ng, Qubes and Linaro
projects - and other adjacent communities - that also warrant description
and linking from within Xen community documentation.

To Jason's review point: I am willing to accept leaving the VirtIO section
out of this specific Argo feature document but I do need an appropriate
alternative place for it - eg. the Argo design document (already within the
Xen source tree) could be extended to introduce it instead. The externally
referenced design documents are part of how such future
features get implemented, so referencing prior to implementation is helpful
and supportive of the continued development of the technology.

Christopher

--000000000000b1148d063715a347
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




    On Sun, Jun 8, =
2025 at 7:37=E2=80=AFPM Rich Persaud <persaur@gmail.com> wrote:
    On Jun 8, 2025, at 5:49=E2=80=AFAM, Christopher Clark <christopher.w.clark@gm=
ail.com> wrote:
    =EF=
=BB=BF
    On Wed, Jun 4, 2025 at 5:14=E2=80=AFPM Jason And=
ryuk <jason.a=
ndryuk@amd.com> wrote:

    
I think this should be dropped.=C2=A0 We don't need a link to a design =

    
document without an implementation.=C2=A0 You can add it once you've 
upstreamed the implementation.

    OK, I=
9;ll remove this section for the next version of the series.

    What's the recommended location of Xen d=
esign documents, requirements for future improvements, roadmaps or pointers=
 to related work in adjacent open-source communities? The Xen wiki is being=
 deprecated.

    Others CCd are lik=
ely better qualified than I to answer these (reasonable) questions, and I a=
m interested to learn from any further answers.

    My=
 preferred option is not to deprecate the wiki,=C2=A0or at least not withou=
t a replacement for it.=C2=A0I have found the wiki to be useful for many ye=
ars for both publishing technical content and for access to helpful materia=
l not available anywhere else, even if the contents are rougher than the fo=
rmal documentation. Its accessibility is an essential part of enabling that=
.

    If the wiki is deprecated, the available alterna=
tives appear to be:

    * Pursuing formal acceptance o=
f documents into one of the Xen git repositories;
    From my experience of =
doing so, less documentation will be produced if this is the standard requi=
red and unique knowledge will be lost at an ongoing cost to both the develo=
per community and users of Xen. Review capacity is already scarce and this =
will further deplete that.

    * Publishing on the platforms of a=
djacent communities;
    Documentation will be less discoverable and at the =
mercy of external tools and processes, again at a cost to collaboration wit=
hin the Xen community.

    * Repurposing the Xen issue tracker
    This w=
ould be a horrible bodge. Please no.

    * Self-hosting - similar to pub=
lishing in an adjacent community, but worse
    I would prefer no=
t to have to do this and may not have time available to do=C2=A0so. Not eve=
ryone is able to.=C2=A0

    * Replace the wiki with an=
other collaboratively-edited=C2=A0document hosting platform
    I am =
open to learning more about options for this if it is the recommended direc=
tion.


    What's the recommended way for t=
he Xen community to discover the existence of Argo documentation that is no=
t hosted by the Xen community? If necessary, we can create a new semantic l=
abel or Xen docs directory tree, to host technical content that might other=
wise be lost.

    Should we add a sentence to Xen'=
s Argo documentation, to the effect of "Please refer to the Xen [wiki =
in archive.org, websit=
e, mailing list], external sites [A, B, C, D], or your preferred [search en=
gine, LLM] for more technical documents on Argo design and implementation&q=
uot;?

    The Virtio & Argo des=
ign documents, produced within an adjacent community so they are hosted the=
re, are relevant to Xen and ought to be enabled to be discoverable (and if =
necessary hostable) via Xen community platforms. They=C2=A0are also a singl=
e instance of a general class: there will be developments of other Xen-rela=
ted features within XCP-ng, Qubes and Linaro projects - and other=C2=A0adja=
cent communities - that also warrant description and linking from within Xe=
n community documentation.

    To Jason's review p=
oint: I am willing to accept leaving the VirtIO section out of this specifi=
c Argo feature document but I do need an appropriate alternative place for =
it - eg. the Argo design document (already within the Xen source tree) coul=
d be extended to introduce it instead. The externally referenced=C2=A0desig=
n documents are part of how such future features=C2=A0get=C2=A0implemented,=
 so referencing prior to implementation is helpful and supportive of the co=
ntinued development of the technology.

    Christopher=

    

--000000000000b1148d063715a347--


From xen-devel-bounces@lists.xenproject.org Mon Jun 09 07:31:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jun 2025 07:31:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010106.1388223 (Exim 4.92)
	(envelope-from )
	id 1uOWyT-0006t4-QV; Mon, 09 Jun 2025 07:31:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010106.1388223; Mon, 09 Jun 2025 07: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 1uOWyT-0006sx-Nv; Mon, 09 Jun 2025 07:31:17 +0000
Received: by outflank-mailman (input) for mailman id 1010106;
 Mon, 09 Jun 2025 07:31: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 1uOWyR-0006sV-Sc
 for xen-devel@lists.xenproject.org; Mon, 09 Jun 2025 07:31:16 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on2062c.outbound.protection.outlook.com
 [2a01:111:f403:2417::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b4cb051f-4503-11f0-b894-0df219b8e170;
 Mon, 09 Jun 2025 09:31:08 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by DS0PR12MB8813.namprd12.prod.outlook.com (2603:10b6:8:14e::11) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Mon, 9 Jun
 2025 07:31:04 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8792.034; Mon, 9 Jun 2025
 07:31:04 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b4cb051f-4503-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=kfuBlFgzuRytQ3Vecw8Uqz4axHrebsHyNSCTeZbwCJrsAvBVJtSmhuucntIkppqYJTxy+kIaCr6QfnDLqioe4BG9M0CZRER6qZN4AhHCM7BqReamFAjIj184yCVo3jaxyQJl+NbKph3710nv4hPIV5xKl/qL2ufGVxhqQqO/JV03JNwET2+VK90rKI5DZh02iwL7IGqj0i2lf6M62++j5aJJfV2W1OROvVCKjHlClz6W8wOhYHQ3hS0mcek0YFl6KbXcQR8I+OqAX3MfIwE0PKDEINOQRzdlFqH/KJid216mA7Le5ojgqP7bYzzoryeANLtKxbmiYC0uTWL16latsQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=A/TamHO6pSL2Whnqo7Fx/IHd2dhXDBll+2sO2VIYHQg=;
 b=EdLuN2QVRJPfChk8E248+TzpsWrYvAem6m8+oehAG4lJaTo58L/5bTZHdbTFcp/y+kIWqnZaiSkEeqp6q5CQTAQgyndLq+lwducVU1AcrQTKeP8LZY/v/J0eMAiqbvHzG7QNtlOY1uG4jWb9QhYe2WyhgZ58Zcg4zJv4hejEk0ru/yHzATNynO3tVBG5u3qQyllJcdLMctqvt65SjQw70llWUbtKvM8w1jwSdcUfPAhupm7d83fxSk55Lgc7czzQ8CbUPcHuQvkl9wdKsy14UdxcgqnKnYLC2ixNem7E17lWdrtUonmXLujVAPjNTeDez72uJ/IEvsBztPjKpdKMmg==
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=A/TamHO6pSL2Whnqo7Fx/IHd2dhXDBll+2sO2VIYHQg=;
 b=zYxtQrIJ46bEqmPaSAaUlX67auF9WngewmklUGa6/06Jj5Yr3u+F5utpaE7815lxuus3Px/MktcqurxArqV1ZnIPV8NPW1ngmG2gz+kQ90+8PCeV/Bhw/g10wE8eGZSvKECS4qPCUVq4jZsFxi1LLlOOSNXEg4QMGX/K9YQ8oTw=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Mon, 9 Jun 2025 09:31:00 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/3] arm/mpu: Introduce MPU memory region map structure
To: Ayan Kumar Halder ,
 xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250606164854.1551148-1-ayan.kumar.halder@amd.com>
 <20250606164854.1551148-2-ayan.kumar.halder@amd.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250606164854.1551148-2-ayan.kumar.halder@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: SV0P279CA0030.NORP279.PROD.OUTLOOK.COM
 (2603:10a6:f10:12::17) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|DS0PR12MB8813:EE_
X-MS-Office365-Filtering-Correlation-Id: 727300fb-0f18-4f46-986c-08dda727972e
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?ZkhGMENNL25Va0tJdzlBSExDVVpnRklDRHh5elhlU0gybERUWEFGUy9qeXF4?=
 =?utf-8?B?RGRSUndsL2dnK1kxbVBla2M0TVcrWUlYY3FpNUFrVnY0bENDaGgydUhhUktT?=
 =?utf-8?B?ZDhxWUc1STd2NU1WTVJiQTY2Nm1LTS8vY0R3alQzeXNzUTV4MnYydU42M2Jx?=
 =?utf-8?B?V2UyLzNKSkNJZ0JIMXJMUEVCaC80cGN5ZUxMbGVEQTFQbEdTRDZjdG5xK3Fo?=
 =?utf-8?B?aVRjY3JCVFh4L2tlU0tROUM2SVZ5c1Vpa1B6bVBLdjh0ZmFVb29OK3NndDcx?=
 =?utf-8?B?VEk0QWQ1SUVuV080ZzBDVnVQTVVhNmVhbWpzcHQ0MDB6MjdaOExlY0xEQXNw?=
 =?utf-8?B?NGRETS9ZTkwxU0p1cnlXVHV1cGhWOWJTanFwa1JYUWFsditPNEhBLzVmR1Fz?=
 =?utf-8?B?T0JsSXc4VnpwMjV0Nm5mTkRLVHAyRGprSWloeG5haFhOWXNJeEwrSkQxVlZn?=
 =?utf-8?B?U2hDWnNLY0ZvVXY3Tmo0Z3hUWEV2UVhZM1l0ZjJ6OWNtVGpxTjV6eFppb05V?=
 =?utf-8?B?SGE1OGpCbHdyWXJ2eE1mY2FncDFmWkFvUlFvcjNsOGRtUURGQnNIZXFJcTFw?=
 =?utf-8?B?WU9FaEZRY21WcnNxem15dWxWcVMrUzlFT1lXUkZ1b0JIZ3RrdW96eGoyeEdm?=
 =?utf-8?B?VFRUY2Z4dERXOFZQaysyZENRZmtRa2tPUG5vamw2Umt3T1hrSHppdWxuK3Vv?=
 =?utf-8?B?ZkVnUzMrckY4WjJJeVdkaUtmQ1hhdEJLbUtDdi9WT21iU2Z5bUdUdVFpdUxH?=
 =?utf-8?B?OWRTS1JvdmcvbWFHRG1UelpkMFNPaC9XNjRkWkZRRis4a2JoTzEvY08reE42?=
 =?utf-8?B?eGVsYTQ1UDJSaG53dkh1RktRRHZtSkpZTmVvUE1xUGZIUlhDT0xRL3VUemdx?=
 =?utf-8?B?REwwQTlkK2d1a28vWWVJVkIreEdkRVdpSXNLYjhJSGFtZjBjOFpEWmFvelNu?=
 =?utf-8?B?T0svU3ZqVERnQ1RWMThGSElucFhtZllMMFQ1RFhWRGR2SndVSlJ0bW9WOTBt?=
 =?utf-8?B?SERpbWRtaVJRdkZGNnB2c25la1UzOFFMbk5PZ0JnbGl2VFJnMHJ0WkVLd1FN?=
 =?utf-8?B?L3NPUGppS254TlkyVmNKZTg4WExLWWZ5Y1dZMjBxWGFaQU5CMXArbkRBOC9D?=
 =?utf-8?B?WktFdWozdWlJa2JkTG5jbzJ1cmxHbnh1a0Zoam94K0ZtMU9ORHpZR1FLb0FG?=
 =?utf-8?B?NktOUzlnc2FMYURWL1BvM3hJbUdmOU5CYVMzV3VRNitLVURWendVMEczQ0Ja?=
 =?utf-8?B?OCtyRFZNUEdUUTFFaHFneGNjazh3MTdSa2pVRmpwUEtHM21VZG1HRHphMXJQ?=
 =?utf-8?B?V1l5Q1dFb1FHWUNRWWVpTS9UcjlpN2NHcm5UYTc2WlN2SWlHRFRhaGJJRkJD?=
 =?utf-8?B?VDliYWRTTmk2RnFrVG5hV245blh4akhFN0JiMmxrdm11dXRaSyt2ZnVXMUs2?=
 =?utf-8?B?a3JXaVVUQzFaZzBkVUIvMVoyOXhOcmxvUGdvTWtuZ2lUalVibFVabHZEV1Jz?=
 =?utf-8?B?V1FrcHRidnUxU1drSWt4OXhCUXhWQS9WOG9BaU9wRjBsN2hRbjZ4eTB4ZTJq?=
 =?utf-8?B?cjQxbkk0ZUd0SHFQYTVXTVpmaTJ3OTAzRjBuci95OGhKQ0ovRG5LUmx0UzEx?=
 =?utf-8?B?V2FGYjZVc1R0dUZaOVFDMCtHZlM0VEtKNTRRWXNKS2dyOEVKZjhGK0RmYStp?=
 =?utf-8?B?SndQOVFGRkJkNWM0WlVQUExKU0FzZEF4T1lCWUNoZ25KNE81OGtlYkRFcGsw?=
 =?utf-8?B?YndDejFza2UxcGpWdG1tS3pUTXA5L0lLc2d2TWN5VEhnUDVHVWQzYyszd2FT?=
 =?utf-8?B?K2xRcVk3OUpVTVBCeWFUVUoyblRrYlo3SEowSDNybXhObWlUVUFwSHdEeURO?=
 =?utf-8?B?ckNEd3Fxc1NqR3NUM0RraGlwclFjMnN1eEFjRDNPbnZ3VGdZUnJKR0E1ZWZo?=
 =?utf-8?Q?3PwwIpqQl2g=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?dDNDVm1DQUlzMVFQL1hrMHlLZkU2ZHhDTng5Y3VqbE9LYzVDOWpJdU5jbGor?=
 =?utf-8?B?QnArNU01ZWdxZnhva3E0NU5lOUc3WEJsNk9Bbyt1Z1ROT1pTOHg2OXo1TUFi?=
 =?utf-8?B?Uzl3NGc0eStTVlRxL2JHbWZab3dnM3VpeW1CeXYzMWpiOXNpNFRweDd3WE1Y?=
 =?utf-8?B?WnVPT25NOENiYzA4TGlGbFJ1TmpUZ2MrNlYrWjJyTmszM1lDbjJFNGRKMjJo?=
 =?utf-8?B?S214cDFlUTQ0ZnJiRlNnRUpmVGp0aXlHZEZTdkh0Vi9XcWVtN0lSbnJReEdW?=
 =?utf-8?B?RWRrVXArVzFZcFJvRFFOd1dYclNmVktiZWtjYVA0aVpxMUY1US9wMGVSLzNZ?=
 =?utf-8?B?S2FvMzJPUHJTbHpJMEZOeVE3MlNqRnJvbm4xRmtuUHd0cUxrWk1pMmJsUEt6?=
 =?utf-8?B?NVNSRjdMY21VQTV4dWhkM1pzdmp6VmI0cERSdzJlTWpYdmV4bmI0a1YzYTBM?=
 =?utf-8?B?eW82RHZIZVZwTjB5bTczM1poZVlXdzBUTEpZa0x3NzlTeTJnU09xa3o0WTFK?=
 =?utf-8?B?RGMxdktXZEZhQ09qOU9rTXU4Qmk2dE1ZNDIwcmN1YXM0MVl5K2toazRUV1FT?=
 =?utf-8?B?TXN2d01FMnluaEwwYzFPMmdvN1pmcGZpNGcxaE9BaGkrTzRwZ090QWhIU0hv?=
 =?utf-8?B?dXd1ckkwLzRueE0yL2tCbHgrZ2dlMjdLUUVEZjFNd0liamM4ZnlsZlI2V3d4?=
 =?utf-8?B?cTFFTEtDbU5wcGUzZ0FYeHhWbjh5RDZpOXVDNUxnWmJ5KzFHOCtUQ2FZSGx2?=
 =?utf-8?B?VW53SEV0elZyMTlNYktlZ2IvU3pCMWllMmZObWRtYjNDWFZkaXhreEVKUnhq?=
 =?utf-8?B?QmNNTkllMjdiTVZrb0dlZ2czUlIrK2s1eS93dGtFcGp2b2FVWDRxTGF2VVVy?=
 =?utf-8?B?VmdtTFhOcThwZHJyOHRqTndmSlAvUiswTXh6NDdpWVd1TEV2TVk1UnFhSG5K?=
 =?utf-8?B?VGNoU3FUZUc0S1pyQTF0d3FLanpqa3BFMUdmWWFEUkNwRndsZkxneEZ3TUlk?=
 =?utf-8?B?aVZJSDIrYnlhK01qSkMwVFVublZyT21hdk5mK0dsaEJERklVb1ZrZ3llZXQ3?=
 =?utf-8?B?dEc0QVV3bWJIVFFmY29XSzdxWlFDTmdqbkYxaXloenppU0dqU2JSYTFPbmNs?=
 =?utf-8?B?c3hLNHZMRGhnYVhjOHRhZHNmaEpEc3JDREhKa09uQTh2Z0hOeHBmRWNyc0pC?=
 =?utf-8?B?RElCMWhtYlVHUmY3RWpOUUZ0bi9tRktuU0t4S1lKZm9wbnJ3QjQyQnJSeHFK?=
 =?utf-8?B?UkNUMjJ4TlQzN1hWTzdUSkp3cTF4QWx0ajlpTlNLSkxiMStEUWJUaHVHVnd1?=
 =?utf-8?B?MWU4TEl2UE10dHB3WE4wMEozSHlhZjJwaTdzZ2hpendDRU9aZW5YNm41THFn?=
 =?utf-8?B?elhwNmNVS3Fpa3lLVXl4QmtuTFQvRm5hM1pOeWludU5uQ2k1S2tua3E0Sm1j?=
 =?utf-8?B?VGM1V0lPSWtiVFlTa3REb0U5V1dqWmFETXNPZ3NvbTZXTVRtM2E2VzZpYzRN?=
 =?utf-8?B?UzM5R2k3NWdRMkVHUzFXQnA2Mk9vRzV1WnBvOVdXVHJUaDQ0dmFvbUZFQXhY?=
 =?utf-8?B?Y1Uyd3pMcXdscFUxeEFxOXhLbCtOQUpiVWs2RC9OMm1MV0g2L2FVSkxITEgy?=
 =?utf-8?B?RzJXZ0xZLzJCeTd6TGpOQ2wvWWV6QUU3M0UvMTBrU1gvR2dXMGdQSTV6Q0k4?=
 =?utf-8?B?SGR4eGtUTUlVdHUvQnpFT3NmYUlmWW1SWVM0MENSY3c4bThLSUlwcUVWSWsy?=
 =?utf-8?B?VGpWWkZZU005VVhYRnNWb0wrcnBqVENYNG04MGlCK0p1TGlhOElaSjFIZ3cz?=
 =?utf-8?B?alM2VFdyU2lKNnNWd3oxTm4zdERWWVdudzh4RUdVTVE3eFdaVzdJcytOUXZh?=
 =?utf-8?B?ZVlZNkVGMUo5K3QrR1RreU1jWlBEekZZMjdMVkVVeGxLUlp4c1V1YXhTTjBR?=
 =?utf-8?B?Y0piS3UvUlNSNjlNVlpDWnBiVEplanQ2N3hUcm5VZXk0clFaTHZJY0R3SkpH?=
 =?utf-8?B?dmdWZ2daZzlIMlVuckRST09JR0dqMW93b2pIblhZK29ad1ZqZFhXR2d2OFdG?=
 =?utf-8?B?K2N1c2tuNDVrbmpEcVd6Zy9zSE5HZFJDZ2s4TkxVYUZ4b25rb3BkSm15UC9u?=
 =?utf-8?Q?/6CW9oAxlXaEYbyBZjLdGv+He?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 727300fb-0f18-4f46-986c-08dda727972e
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jun 2025 07:31:04.0970
 (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: c3ckc4mxbRuDGFG7iYVGbtLtohPkEp1SLtof2qYe1Ml6ayUoPhfhXv8iWZkiv8MV
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB8813



On 06/06/2025 18:48, Ayan Kumar Halder wrote:
> Introduce pr_t typedef which is a structure having the prbar and prlar members,
> each being structured as the registers of the AArch32 Armv8-R architecture.
> 
> Also, define MPU_REGION_RES0 to 0 as there are no reserved 0 bits beyond the
> BASE or LIMIT bitfields in prbar or prlar respectively.
> 
> Signed-off-by: Ayan Kumar Halder 
> ---
> Changes from v1 :-
> 
> 1. Preserve pr_t typedef in arch specific files.
> 
> 2. Fix typo.
> 
>  xen/arch/arm/include/asm/arm32/mpu.h | 34 ++++++++++++++++++++++++++--
>  xen/arch/arm/mpu/mm.c                |  2 ++
>  2 files changed, 34 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/include/asm/arm32/mpu.h b/xen/arch/arm/include/asm/arm32/mpu.h
> index f0d4d4055c..fe139a2abe 100644
> --- a/xen/arch/arm/include/asm/arm32/mpu.h
> +++ b/xen/arch/arm/include/asm/arm32/mpu.h
> @@ -5,10 +5,40 @@
>  
>  #ifndef __ASSEMBLY__
>  
> +/*
> + * Unlike arm64, there are no reserved 0 bits beyond base and limit bitfield in
> + * prbar and prlar registers respectively.
> + */
> +#define MPU_REGION_RES0       0x0
> +
> +/* Hypervisor Protection Region Base Address Register */
> +typedef union {
> +    struct {
> +        unsigned int xn:1;       /* Execute-Never */
> +        unsigned int ap_0:1;     /* Access Permission AP[0] */
> +        unsigned long ro:1;      /* Access Permission AP[1] */
It should be unsigned int, not long.

With that fixed:
Reviewed-by: Michal Orzel 

~Michal



From xen-devel-bounces@lists.xenproject.org Mon Jun 09 07:42:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jun 2025 07:42:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010115.1388233 (Exim 4.92)
	(envelope-from )
	id 1uOX8r-0000Jc-SA; Mon, 09 Jun 2025 07:42:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010115.1388233; Mon, 09 Jun 2025 07: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 1uOX8r-0000JV-PZ; Mon, 09 Jun 2025 07:42:01 +0000
Received: by outflank-mailman (input) for mailman id 1010115;
 Mon, 09 Jun 2025 07:42: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 1uOX8q-0000JP-E9
 for xen-devel@lists.xenproject.org; Mon, 09 Jun 2025 07:42:00 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on2060f.outbound.protection.outlook.com
 [2a01:111:f403:2418::60f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3587eda8-4505-11f0-a304-13f23c93f187;
 Mon, 09 Jun 2025 09:41:53 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by PH8PR12MB7205.namprd12.prod.outlook.com (2603:10b6:510:227::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.38; Mon, 9 Jun
 2025 07:41:49 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8792.034; Mon, 9 Jun 2025
 07:41: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: 3587eda8-4505-11f0-a304-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=rZ2Ic8RZ1XYBzTgYZbeLj/swKZ53ms4rWjOTsOivrU8WxHN4NK+qQIZsM+RPbFZa6fIY+4LTlswAm0Djf5L80Rq7qH3FiySbc8fJV4j265MYMSWv8tWdzemTlM/8/8Hp8ywitPo2JSMX0XyaPsYgzpUMVjh7q8LSEMFegQwdpow7bQHWICfHzuqav0INI/NuzrA/ASHJxWc3rCdXA01vjcA2YXRWps9HUWX9x/IcHsLiTTSg5U6QQNH1cb9peGqSsbR66Sy7pRbqQR8gbM3+gfsyVbkSbQE9ZXaO4ZwfZ1YzEkts+/zcepZxqS/zZ9Pc/kftDu9lBgOHhIqXCU8aig==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=b2vBVMgHaVve863q3YYs1WwI5y+XWFqqCtBTfREES6U=;
 b=iPQoWniueKBC9BELiB99SXlaMWEtNvJKhPy4DJ0VpAokNNVbgtGe6sM7BExeUwC5Pc/2lCo6nWD8SS+FXYQbKw0u7kMibJLmAT4vdy6cLEX0hWfKcqx9gtG1St6yWjatZa+fN3OVPtgqUu5/7Y5ds0GCA7IHa8LMdsPedhBWgs95xobvTXHLVYQSt73K1QjIFurkrREq47n4IgmCixNhYEPngb8FmoJQxt/Kwenw4fKaDDjqlhq7P5fwXnBoXw2wAMQKBYUepkajapr9EwBXYOJpGrW8QQLatFdIa3qC41fFzlzpUf9zJtlqpy2fEUI+b3FplMQO/mW9irVhhYwpGA==
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=b2vBVMgHaVve863q3YYs1WwI5y+XWFqqCtBTfREES6U=;
 b=q2AQQHXKVdkYrkr1dv/Z1uq/8RzC91uQ8qa91wKEf1pJaJvPERwBQkeHtpzToSc3A0WOh6n9HzfrO899TDDMBm16B6tjSlRz+FcocX2PmVBXwbH0DnggbC3kGFpe5M68Sx9fccFXTQCpQ12+VC0b36+vSwavrwnq9B/Oj9qqfEc=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Mon, 9 Jun 2025 09:41:45 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/3] arm/mpu: Provide and populate MPU C data
 structures
To: Ayan Kumar Halder ,
 xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250606164854.1551148-1-ayan.kumar.halder@amd.com>
 <20250606164854.1551148-3-ayan.kumar.halder@amd.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250606164854.1551148-3-ayan.kumar.halder@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: HE1PR0902CA0034.eurprd09.prod.outlook.com
 (2603:10a6:7:15::23) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|PH8PR12MB7205:EE_
X-MS-Office365-Filtering-Correlation-Id: df4c6311-c71b-400c-bbdd-08dda72917b3
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?ZTYzMmRNVzNTZFhNbzQyMEd1cTkxTXhWdTAwMGpIR3pMWlVHTFBJWVArZ2Vw?=
 =?utf-8?B?dUhaU3NNYkVpK3owVGlRSFhwaVd0eE5FT0dFWVJHQ1ZrT3EyRE9ldHhhSzda?=
 =?utf-8?B?RkhMbXZMdHdtTU1nWjJZbm00UnRaTVdmMmp1dmlnaG5jR1VkTmtQbWl4eWYw?=
 =?utf-8?B?Q0I3LzhWcHpTT0hUektHbkhoVGMxSTVGMCtabXF6TmRxaUJobUVtbG5Ra3Jh?=
 =?utf-8?B?RnFPcm1ZaHp2Ym1RRkZydCtOejEvZmtyM0VGbTF5cDZjSmhBODVUbklMWSsx?=
 =?utf-8?B?aWZ4WlV6YjQrUkJmbm9CL296OGY2OXM3OCt6SGRHRWJ5cDREV0podjcyNUVV?=
 =?utf-8?B?TFRueUlZaGxwZGlvZE5kanpTQU1YUS9GandaRjB4dzRWQUdERFVoZldmVFdW?=
 =?utf-8?B?SmszaTFwdkJpZFFCcDI1Qmdac1NhT1ZFZXR3TXJzTGNibGdpWFJLVE9QVzI5?=
 =?utf-8?B?NXZMdnEvTmFLZFBtU2htUWV2WVJwRk1XeVdUYlJiRXpRcGQ4UjBGeGdEWmJ5?=
 =?utf-8?B?dG4zUFRNRnFFZmUvNVVZQVNwdldTS0NuSWk3aG11NlVsc3Q1M0czaGp2dWIw?=
 =?utf-8?B?ZVVnYUtqbko2ZjlVeXpzdDJjdnlscmx0NUkvMHBLL1hwNkVqQVNDamdvYTFz?=
 =?utf-8?B?WXVIRndia2ZLTkhzeTI2MFRoNEFJOGd5c3ArcW4wYmtMNWRYbktqNVZJbDJH?=
 =?utf-8?B?N3ZpSE5WWG4walQ5ZWQ3NWc5cXRLc0pvMDUrNW9GMnJPTE5pZDB2RVMyRmxl?=
 =?utf-8?B?OVJsbk91Y3E4c0FGSnNpaU1hSS9OWUhSWU9nNy93VlBBNitpcWxMY1huK1JV?=
 =?utf-8?B?K3MvczJuRzVsYnB4V3FyZ0ZLQXlWeUNIWWh1UXFSWVBuaWc2ZTlKdVVmNDQ1?=
 =?utf-8?B?eWFPdS9JaXo2ZTRMZDlTNEljdE82ckR2dHZxdUNBVWNXWFlCak1wdEJLd2dP?=
 =?utf-8?B?V0Y0T3duNHNaN2tnWjlFaktnY3NNZzlRUUFwRURXeGF2VVNEb0VzRHdVNGtU?=
 =?utf-8?B?VHBQS3ZZVm5SZVowTDMycnlsam5qVDVmUUViNm9wbU14QmlNQnZicDVORVJS?=
 =?utf-8?B?b3lwUVcraE05N21IQ2gwczVmdnVyL21DanRnT2hteFVYVDU2V1RJTC8ydnJJ?=
 =?utf-8?B?VjB4VVJ2elltVHZiVnE3Vy9NS3FMSWFRZjRJOEZqUGxaeW00ZkxFOW1ReXd1?=
 =?utf-8?B?WDFSdnp1cDdMZ0E1bWE0QnZENmloQzNhYW5lcml0YnkwK0RuMWErV1JtY0xM?=
 =?utf-8?B?bDBGRENnL0F1cXo1Wjh4aDdEVnhidnlZNkVkc1Q4dGVhYmF5VzZLUk9vOTlz?=
 =?utf-8?B?S2xBWXNQeHM3a1ptZlpHYVJpNlFtVHYyaG1LWGM3ZVQ1enpTZ1dlSmxHMHhn?=
 =?utf-8?B?by9QS0tlanY0YzBidE9LNDVTS0hWa2xvZm02S0QycFkxUFJ5SG5uczl0YjNq?=
 =?utf-8?B?K0pZWUJpOG1ZdFI2d0UveVJleVZPcDhuU2ZXUlBKdzVNUlpKTnV1aXJuSnQ2?=
 =?utf-8?B?b1NsWFIzZ2xXMXNyQS9CZCtMT2ZTODlCVnh1VUVvMi9RTUZML01WeVliVU0r?=
 =?utf-8?B?T3R6K1VWU2lTWjB4K1FhQnY0NmxGQTQ4VHNJL2Q2YUZLeEN3UlB1LzNpN1dB?=
 =?utf-8?B?Y0NSK2I0dzR5Mm1lTzNKQUFwS3NoRU83QVZEdjc3OXFKM0N6S1h6dTFaVzRH?=
 =?utf-8?B?SVFQa0l5ekF2WTZOTUJ5MlhlcFFXR3g5YXBKRk9Dek1tdEZhUUpWeXpiRnJS?=
 =?utf-8?B?Rk9BR29INks0K2ZaQXJjdDhsdVVKb0Y2eTZVV1o4N0ZoYzdHbUhDM1JDYVRj?=
 =?utf-8?B?aG1ZbXVQRkVNTWdxcVdqcGdVbDJnbmtCdnBuMU02d1NBakpJK3lJKy9vb3Zk?=
 =?utf-8?B?SFlNSzMyTm9zZnJUNjk4bTJvMFppK3dSYmpLK09CK25VS2xrajJ2WFllMUhq?=
 =?utf-8?Q?gPQA8C0mxQU=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.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?a0wrbWhReElRU3kvajRsTlRKR1dVWmYwRUNCTHpwQ1BJVm9CazFabE5qeCtO?=
 =?utf-8?B?cjNjYlBZZ2pLMXJRY2RuSjZyZDdhVzcrdkhic0Q3MDdadGNZQ1E0YXlOMUlj?=
 =?utf-8?B?OE10TURJMEZ5MllDT3dFRGpnUVpYRTZBQWcxSnZvNVhMejJtK0xYUmN5bXJI?=
 =?utf-8?B?dXlRYnlCM2w0NmZJWUNWUU5EOGt1V0IvUGtnc1BJOVRKQTBxS2pOQUJzeFNk?=
 =?utf-8?B?YnRWaXBFQ3FJVUp4dm5XMHJsdEhITXhGQ0RjVnVKZFJDT1ZRTmNpRysrYnl2?=
 =?utf-8?B?M2FtOFR5LzdzcjJFc2tWOHBQSlA4NWxZL25zcG92b3FuQjJCRCtCSlNHMm1a?=
 =?utf-8?B?RlRPaXB4S1Q2ZzIzbXloSyt4M0dCSHkwTk40RnJJejFpTjNUL0dDbmJZZDBu?=
 =?utf-8?B?TVJidzFXbUZOQk5DTnlkaDZ1ZXBKMmw4cC8wY1gxdjVpYU5LZlQzVGEzbHhn?=
 =?utf-8?B?L0NKNDZPZVZTYlprUjZFOWYzTit6ZHZRS2Z3TkgzTGRFb2djNWJ2WWZkeHVI?=
 =?utf-8?B?Q0VHdm5POEJ4N2I4NHpLNHYzZXpZb3U0U3gzUUp5ejlyU0hjS0JEZDVlT3dD?=
 =?utf-8?B?Qm95SDhEa0tIYlhVbUw3UkhHNEphMWU4K0lrVExzRkIwb05aM1RDdFFCaFpJ?=
 =?utf-8?B?S0NoTkZ2MENSNDdKejZ1SzdMZzU3U0dodDJpOWU0TFdaVG9Tc0UzTkZKK00y?=
 =?utf-8?B?UGFhK0NseUJGb0h6S25DSFpDVFlpV25qMWxsYVdWeER2am5kbXcwZkNtZ1Er?=
 =?utf-8?B?ditIWXBDOU54Y2FJc1JUemZyd3R0R0ZUTHF5R1Q0N3N3QTRGTnh0UXVFVHRM?=
 =?utf-8?B?WUZDSDVwelJjYjcyeDROd0FKMDZ3Wm5xc2x3WEkyUW1UZjE3Z2ZPNW9Ubmlw?=
 =?utf-8?B?RGk2Ni9IZXpTU3hNRng3eUVXZGVTZDFNcXRHZk9zQkZHblp5TWJQc3lPSDdj?=
 =?utf-8?B?RjBGbWc4cW16REw1dEpWbytXQTBuUXZnMFBKVmJiajNSeUFWMXYvZWZra1Nj?=
 =?utf-8?B?ZTZORnRCeGdaaStSY0JJc2VpRGtwSXlhVXBlQXA3SlppV25wNmRTUHZ6VUZx?=
 =?utf-8?B?L09OQmlnTXNjajhiUUZOd0c0c0pMSWE0Mi9RZTRiM0oydHk3OHE5aEpIaEl2?=
 =?utf-8?B?UmFCcU8vd3ZUQlRxVTB5UURvWkRITGZwVkMyUnpSSENDbitGY1pNQ25USlNV?=
 =?utf-8?B?ZTYyMU1DVW83cW5ST3RIcm5xT1dETTJsN3hTaW5tSzNzTk0xTEZDMFppeWVY?=
 =?utf-8?B?bks1c1VhYTVMdWJSaGVwRkxnbXR4ckVUcncyOGpoUjhRdnVNZWcwZFdXNXE4?=
 =?utf-8?B?SjB4TS9rU1BrWUs2QzlyK1ZVb3lIcEwzU2pjMENWeCtyTmFuRzRzVjF3ZkUx?=
 =?utf-8?B?a0FXS1Z4RFN0SFFiU0tXRjNvUHRZSGVCQWxSN3pqcHFkT1hoR1RNMm0zWVpN?=
 =?utf-8?B?dkFwb3h5Z2E5SFkwNDczL0FoYk9VRFYrZS9xdnI1TEk4NW9YU3cyV0txUFZo?=
 =?utf-8?B?eU8xWXpmOHVuK3MyUkJLRC9yZGFMQlY2YVFDWlpZRFpWY3loeGdXamo1VytL?=
 =?utf-8?B?ZWp3TU1aZDRTTnhpZWVvbVJ3SGYwUzYrR25aN2pSRUpHRnFtR09ONnpmTlZn?=
 =?utf-8?B?MkZVWk9Dcm1iWVpSUFp0UWZVd0hjaWtiaHV5ZjRLNDJlMytpaVVmRGNTRm91?=
 =?utf-8?B?aXhqYkVqejUyd3ZyckRRUEd3SzNOaGR5Y1MxOElTZjB4RGFpWW5rVXNhY0Yz?=
 =?utf-8?B?cjZJRjZDTXNyRHE2cjZDUzdma0xjL2ZhU3NGTXhsL00rYkI3dTBuSjlrbmZ0?=
 =?utf-8?B?U1NyUXRUTE9pMm13b1J2SG9yZWl1QmpBYUU2RFlNVlRteERXMHFFRGkvK3JR?=
 =?utf-8?B?b01aSC9EOEY5eFlRSS9mOEVrbStra3ZYUXAzTjhZOWpILytlcHNhN1hXeng3?=
 =?utf-8?B?aVpzOUE3VFhxOUYrUUNuR2FpdG9heEV2SENYeE5Vc2dGTERSRUhXcjU4bExB?=
 =?utf-8?B?RmRqUnVsYXJGSnl0R1pSMW9ieTA3NnZYVkFCZU93VnhSc3d1RjQvaEk4NDdp?=
 =?utf-8?B?SkRsYUJHOWpQQkVPdHZ2Vm1MRUczRXVCYWw5QjdqaWQxLzRTT0Z4QmVqNVUx?=
 =?utf-8?Q?3TeiowaHRHQB7AIcO2Yjl8udt?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: df4c6311-c71b-400c-bbdd-08dda72917b3
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jun 2025 07:41:49.2201
 (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: zpeHtgzAki2PoimubjuPmJDmM6YzpYVzl6qdPZuloxr5YsqrWrpfbc9GStSNmTcs
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7205



On 06/06/2025 18:48, Ayan Kumar Halder wrote:
> Modify Arm32 assembly boot code to reset any unused MPU region, initialise
> 'max_mpu_regions' with the number of supported MPU regions and set/clear the
> bitmap 'xen_mpumap_mask' used to track the enabled regions.
> 
> Use the macro definition for "dcache_line_size" from linux.
> 
> Signed-off-by: Ayan Kumar Halder 
> ---
> Changes from v1 :-
> 
> 1. Introduce cache.S to hold arm32 cache initialization instructions.
> 
> 2. Use dcache_line_size macro definition from linux.
> 
> 3. Use mov_w instead of ldr.
> 
> 4. Use a single stm instruction for 'store_pair' macro definition.
> 
>  xen/arch/arm/arm32/Makefile              |  1 +
>  xen/arch/arm/arm32/asm-offsets.c         |  6 ++++
>  xen/arch/arm/arm32/cache.S               | 41 ++++++++++++++++++++++++
>  xen/arch/arm/arm32/mpu/head.S            | 25 +++++++++++++++
>  xen/arch/arm/include/asm/mpu/regions.inc |  2 +-
>  5 files changed, 74 insertions(+), 1 deletion(-)
>  create mode 100644 xen/arch/arm/arm32/cache.S
> 
> diff --git a/xen/arch/arm/arm32/Makefile b/xen/arch/arm/arm32/Makefile
> index 537969d753..531168f58a 100644
> --- a/xen/arch/arm/arm32/Makefile
> +++ b/xen/arch/arm/arm32/Makefile
> @@ -2,6 +2,7 @@ obj-y += lib/
>  obj-$(CONFIG_MMU) += mmu/
>  obj-$(CONFIG_MPU) += mpu/
>  
> +obj-y += cache.o
>  obj-$(CONFIG_EARLY_PRINTK) += debug.o
>  obj-y += domctl.o
>  obj-y += domain.o
> diff --git a/xen/arch/arm/arm32/asm-offsets.c b/xen/arch/arm/arm32/asm-offsets.c
> index 8bbb0f938e..c203ce269d 100644
> --- a/xen/arch/arm/arm32/asm-offsets.c
> +++ b/xen/arch/arm/arm32/asm-offsets.c
> @@ -75,6 +75,12 @@ void __dummy__(void)
>  
>     OFFSET(INITINFO_stack, struct init_info, stack);
>     BLANK();
> +
> +#ifdef CONFIG_MPU
> +   DEFINE(XEN_MPUMAP_MASK_sizeof, sizeof(xen_mpumap_mask));
> +   DEFINE(XEN_MPUMAP_sizeof, sizeof(xen_mpumap));
> +   BLANK();
> +#endif
>  }
>  
>  /*
> diff --git a/xen/arch/arm/arm32/cache.S b/xen/arch/arm/arm32/cache.S
> new file mode 100644
> index 0000000000..00ea390ce4
> --- /dev/null
> +++ b/xen/arch/arm/arm32/cache.S
> @@ -0,0 +1,41 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/* Cache maintenance */
> +
> +#include 
> +
> +/* dcache_line_size - get the minimum D-cache line size from the CTR register */
> +    .macro  dcache_line_size, reg, tmp
> +    mrc p15, 0, \tmp, c0, c0, 1     /* read ctr */
Why open coding macro CTR? Especially if below you use DCIMVAC.

> +    lsr \tmp, \tmp, #16
> +    and \tmp, \tmp, #0xf            /* cache line size encoding */
> +    mov \reg, #4                    /* bytes per word */
> +    mov \reg, \reg, lsl \tmp        /* actual cache line size */
> +    .endm
> +
> +/*
> + * __invalidate_dcache_area(addr, size)
> + *
> + * Ensure that the data held in the cache for the buffer is invalidated.
> + *
> + * - addr - start address of the buffer
> + * - size - size of the buffer
> + */
I do think that for new functions in assembly we should write what registers are
clobbered. Arm64 cache.S originated from Linux, hence it lacks this information.

> +FUNC(__invalidate_dcache_area)
> +    dcache_line_size r2, r3
> +    add   r1, r0, r1
> +    sub   r3, r2, #1
> +    bic   r0, r0, r3
> +1:  mcr   CP32(r0, DCIMVAC)     /* invalidate D line / unified line */
> +    add   r0, r0, r2
> +    cmp   r0, r1
> +    blo   1b
> +    dsb   sy
> +    ret
> +END(__invalidate_dcache_area)
> +
> +/*
> + * Local variables:
> + * mode: ASM
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/arch/arm/arm32/mpu/head.S b/xen/arch/arm/arm32/mpu/head.S
> index b2c5245e51..435b140d09 100644
> --- a/xen/arch/arm/arm32/mpu/head.S
> +++ b/xen/arch/arm/arm32/mpu/head.S
> @@ -49,6 +49,10 @@ FUNC(enable_boot_cpu_mm)
>      mrc   CP32(r5, MPUIR_EL2)
>      and   r5, r5, #NUM_MPU_REGIONS_MASK
>  
> +    mov_w   r0, max_mpu_regions
> +    str   r5, [r0]
> +    mcr   CP32(r0, DCIMVAC) /* Invalidate cache for max_mpu_regions addr */
> +
>      /* x0: region sel */
>      mov   r0, #0
>      /* Xen text section. */
> @@ -83,6 +87,27 @@ FUNC(enable_boot_cpu_mm)
>      prepare_xen_region r0, r1, r2, r3, r4, r5, attr_prbar=REGION_DEVICE_PRBAR, attr_prlar=REGION_DEVICE_PRLAR
>  #endif
>  
> +zero_mpu:
> +    /* Reset remaining MPU regions */
> +    cmp   r0, r5
> +    beq   out_zero_mpu
> +    mov   r1, #0
> +    mov   r2, #1
> +    prepare_xen_region r0, r1, r2, r3, r4, r5, attr_prlar=REGION_DISABLED_PRLAR
> +    b     zero_mpu
> +
> +out_zero_mpu:
> +    /* Invalidate data cache for MPU data structures */
> +    mov r4, lr
> +    mov_w r0, xen_mpumap_mask
> +    mov r1, #XEN_MPUMAP_MASK_sizeof
> +    bl __invalidate_dcache_area
> +
> +    ldr r0, =xen_mpumap
> +    mov r1, #XEN_MPUMAP_sizeof
> +    bl __invalidate_dcache_area
> +    mov lr, r4
> +
>      b    enable_mpu
>  END(enable_boot_cpu_mm)
>  
> diff --git a/xen/arch/arm/include/asm/mpu/regions.inc b/xen/arch/arm/include/asm/mpu/regions.inc
> index 6b8c233e6c..631b0b2b86 100644
> --- a/xen/arch/arm/include/asm/mpu/regions.inc
> +++ b/xen/arch/arm/include/asm/mpu/regions.inc
> @@ -24,7 +24,7 @@
>  #define XEN_MPUMAP_ENTRY_SHIFT  0x3     /* 8 byte structure */
>  
>  .macro store_pair reg1, reg2, dst
> -    .word 0xe7f000f0                    /* unimplemented */
> +    stm \dst, {\reg1, \reg2}  /* reg2 should be a higher register than reg1 */
Didn't we agree not to use STM (I suggested it but then Julien pointed out that
it's use in macro might not be the best)?

~Michal



From xen-devel-bounces@lists.xenproject.org Mon Jun 09 07:44:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jun 2025 07:44:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010121.1388243 (Exim 4.92)
	(envelope-from )
	id 1uOXB6-0000sZ-7B; Mon, 09 Jun 2025 07:44:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010121.1388243; Mon, 09 Jun 2025 07:44:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uOXB6-0000sS-49; Mon, 09 Jun 2025 07:44:20 +0000
Received: by outflank-mailman (input) for mailman id 1010121;
 Mon, 09 Jun 2025 07: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 1uOXB4-0000sM-VL
 for xen-devel@lists.xenproject.org; Mon, 09 Jun 2025 07:44:18 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20622.outbound.protection.outlook.com
 [2a01:111:f403:2418::622])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 861f0378-4505-11f0-b894-0df219b8e170;
 Mon, 09 Jun 2025 09:44:08 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by PH8PR12MB7205.namprd12.prod.outlook.com (2603:10b6:510:227::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.38; Mon, 9 Jun
 2025 07:44:04 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8792.034; Mon, 9 Jun 2025
 07:44: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: 861f0378-4505-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=OojlPjAIyureiYJdgeLVSLIlhCiKfYjYeIfzHstzYlrNhu2Bap5SGHTYFKKfMn1gcILBnBIzvEct48czcrln8LPeFdL8zyFXWzsTyHr3k2hxHVqXhsmvtt8iaMit9ptvcgfoqwwAAwwiZlTF/Wm+BgGJ3h92Dxj1kAPtwFcfx5KiVRQMkFHUclYGDyLW8keuosGX2oR8zK7937Bm9FcvEWT26w58BPFUuZ/sEUWjPUwZgYgc6g6NFNFjvcVe9u8YLCd45y7BrXiNKtn3leASIcoNYGpSNlffHhZncqUkn4iLyiuLtbb00PNrVtEnEnS67Hcn1XK1NJfnY7N9bDjMqw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=LbZq1FlxOZLsXAQgS6CVyajnSwlb5nFirlVj6n4k11U=;
 b=CPkpb5FThayMWbhg2up+z3A3AbnxHGsNqTNqm8nS2ods3b2fdA5bacuL00lB7r90KBg6dsMx6Zgw+5gXT0Q1yfvnDdj7YPCdXO6dDBwnyb+5FBHpMemYtMslKGexQN+Bi4bRrU+NfnMzF8RaEs7j4dve9QWjRKM2zyX25x01S03HhKzkcZvqM0d9sr4mFkue4X++bdB85hGmQSM0/FESZkExUP3jdyLdeyh6COjreMi23lQmEWoY3piuBHk2x2rEEF6LBXbDIZJUBfBSfLTAzEszANtERXnt2gSoIvic3vTkN+NPetMTY4/IoDWE49fwC3kH/Y41hm8yOkk+D6LdHA==
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=LbZq1FlxOZLsXAQgS6CVyajnSwlb5nFirlVj6n4k11U=;
 b=GrmXp6fSJePqWybEbE74og6acNWWW4xyWPhCYrKibVVlEyx/S9xLcEZqOssz9PgdI4pP/7tgRet2X1ELryuISEsRw1c68R+X9qUoMSl0ZtCWyrTryjj1jERDyQNOhWhJLaABQyXqZlnz28oA2ULNMEx9o9AM13x3UEKM1Z2rnic=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <976f7d40-c8fb-45a6-a7d1-1e5cfd36fb24@amd.com>
Date: Mon, 9 Jun 2025 09:44:00 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/3] arm/mpu: Provide access to the MPU region from the
 C code
To: Ayan Kumar Halder ,
 xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250606164854.1551148-1-ayan.kumar.halder@amd.com>
 <20250606164854.1551148-4-ayan.kumar.halder@amd.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250606164854.1551148-4-ayan.kumar.halder@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR2P281CA0146.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:98::7) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|PH8PR12MB7205:EE_
X-MS-Office365-Filtering-Correlation-Id: 8a086494-5f0a-4841-0e58-08dda729681d
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?dTZNbzhIL0ZKaytEQ1lIU01VZGtUNzRYbHV3aGhmMWlwb3Nxd3RiVHUveW5L?=
 =?utf-8?B?RHlPY3pGcW0yeDFrVDYrKzlCMkNZcjJvT212VnU0SlV2SWFNa3M3Tmk3K0NO?=
 =?utf-8?B?TU81ZDd2YTU4M201eXhFWnVDWWZQSWRISjRlcVFnblRFWWNtamptRFRYcEJB?=
 =?utf-8?B?WG05b0FtTUFvVjgxdkN0M0FrZzFKS0N6dGd0S2dqWlloU3pqaTFjRlBaMG0z?=
 =?utf-8?B?RnEvQzFFUXFJM1pHaVluTE5SRkhjRG5FQmVsdGgwaUVWNWVyVGdqWHpwUjM3?=
 =?utf-8?B?Z0FxMEliRmR3RjNZUjl2RmsyS0JHYXZJamFudG9zek00RXFVOXdDdEtGYzlr?=
 =?utf-8?B?cVlwdTMxUWtQaHpDRHBXOUVtMjQvYUhZeHFicHRRMVlXZk1GbE5UTTVzWWtu?=
 =?utf-8?B?cFhyUlZSOC95MjhRaVNUSE41UlN5SlVNdDBvMWtsajFMR1h5NlcxOGxTWEVT?=
 =?utf-8?B?TncwUDJnaVU4dmRrWGkvZ1BsV0hEUWxVczUzd0FYeFlWc3N3WHo0RktsNjE3?=
 =?utf-8?B?OE5iK1RISXRjamZPTkR6Mm1xazBlNmtKOUxOelhXNG8wQzhQMDdrY0J4NDY4?=
 =?utf-8?B?TzREQXNDQzRFVURPUHZBYkdnN2pGL2tCVzZnTUgzTWNoajRnb1hLZUYwNGlo?=
 =?utf-8?B?eVhOYUJydHZpek5iYTh0YWRJK3VLdTZzRTc5eXc3bW9RVTJGSWF5eVlObmxT?=
 =?utf-8?B?S1djSjlLUjZJaVh0ODhkaXJWM2VGcGVqWFV6T3BDWEtJTUVDdFhGdlZuWlhK?=
 =?utf-8?B?VnlBMGlQczF3RndYZ1RXcUN1Z2VPVWllU3RwelU0WjB6NW1walRTaUcvUU1G?=
 =?utf-8?B?bmVPVmpTRVRBZEw4RXpnT2poMU9TUFVob01JRTRXcWs2M0N1Sm5GMU5odDRM?=
 =?utf-8?B?elJ1VXlZRDVNVmlOaVdXZmNoN1Nhek1xMUl6VlNhV1E5ZUVLenZmd3M4T2Vo?=
 =?utf-8?B?YVhrSURaOUJZUUN3dGJRVmRDWjFEalh0QWJQNHNMKzlhbUdhakhCOG5DVkNP?=
 =?utf-8?B?cGJnaWc0UnlYMklTZUlZV0tlZ0Jsb0FjYStKL21GcS9kOXFXQnJNWWYzd29v?=
 =?utf-8?B?MDdEQjljOU9XWkdhbGcyU3ZNTXgyT1RaNndUMzlxekRSYkJkWldwSzF2ZXJI?=
 =?utf-8?B?QVpVcmVrazRTY2xKSjhNaEQ5QmFpZklQMXJnSGJIWDIyUWcvdncxR0dyQTJC?=
 =?utf-8?B?czhoY0hTWGE1a1gydktsNytHQ3EySmE0TUJJc0RHUzJzQjlJeGlVd1FtUG9L?=
 =?utf-8?B?MStKZUpDajUxQkEzZFNKam1vWDZRODIwRTVVY2V6bkJKVUxDTFhXTEVuVnZZ?=
 =?utf-8?B?OWNqV0lZcFNTMHJsczk3WGlGcGRwYnB0bW1QREdHOThEMjhiK3NIR3lUcU9R?=
 =?utf-8?B?TjRKTU1BY29MUnY5Uzh2dFpVUzFtWXFpVDBHRUVTeUN2MUI1K2hQaXVDOTNS?=
 =?utf-8?B?bU5IdzgrbEhWeWVVRlUvcnIvQVVWVWovelROeGpqcERuQUV1bDVKTHlZd0NF?=
 =?utf-8?B?Wkp0RXp5amJuSjJuOEhuZHpZQkRoQUx5MXRsd0U2dkJHZjJ6dVcycWxnVE41?=
 =?utf-8?B?QXB4NjBqOUVjTExsMWNwTWx1VFRUZDdpMHB6UGROeVI3U3o5Q2xjSzkyVmVs?=
 =?utf-8?B?TWh1UHJ2L0IwblczQUdTR2tFRGJkeG5PYVVBWlMvbzQ0bWd0UVdqeUlTMi9S?=
 =?utf-8?B?cjI2MFNMU0xWc1JMK2FNNjU0bTJ5T3RnVEp5R1N4OHNsOHlJNzhZSGFIL0hl?=
 =?utf-8?B?QkhjL1lrb0xabkNDb3ZDc2dxdDNuQUNaYlcvYktZMFppb3ZGQThVUUhROUVH?=
 =?utf-8?B?RmZMTXRUVnhyclRIZkZjNzRNWEduOW9QME5DSXUyUGpFVU1nRVBmcjJabWF2?=
 =?utf-8?B?MUxQRm85TEpjbXFtRFV4WnVXUWdOOFZqTkgyMklYNk04ek1jbTlLZG43M2l2?=
 =?utf-8?Q?cWvVS9f1pK8=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.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?RzBOZEpNZDcwd09mQkN0QzhSTGtWYmZKcFFXT2x3U3RoSDcwMjBDMlMvdmpL?=
 =?utf-8?B?M09sNmNCQkJjUHNxWTFTTXNQZnA3cFljZ3V6dnBKUmllZTQwSmdocWFoZnZr?=
 =?utf-8?B?elk0c2VvNnkvMGpicVNUblJ3b2dKMDNuYmZTRzZMV1dqaDZBVWdWdnFOZFND?=
 =?utf-8?B?MDJ1RTB4YWh4eWVrM1ZKblJRUVdGaFBBVVJrNzdJTDhrR3gwS1VHWEpXaWhp?=
 =?utf-8?B?MFRvekRsanhZaC9IRjZtNGhJMGV5bTdQdWNpbjV4YXZVV091eWVBa2NMcllL?=
 =?utf-8?B?anJtSWtzbUdTUkxIMXQzaUtWRFJNeTNVa2VDQkJkenJkTXdxWE1ZNW9xWDJL?=
 =?utf-8?B?Z0ZVbWJJUHlOUVpJNk41SU1RanFkU1NOc0pWVnlwelg4alBPSXFJVk0rNmFq?=
 =?utf-8?B?YUFFMUc0b0hRRHdSNGJaYmhMRkFFQzRLMm9BbzlXZ1RRTUxmVE4vVVFqNmRU?=
 =?utf-8?B?Tkl2c1ZzRWVCcHlrU1NNU0VnUXpGUUVFeVNLMUFXZTJzak51NkVCZVVmdlI2?=
 =?utf-8?B?NUFRdWMwVEE1TDZOaVY5M014TmlqNTh2NDRDUTR1VkRBKzBhcDdMeHBSZGo3?=
 =?utf-8?B?aVB4OGM2QkN1bFlDd1B4bVBPVjY4MDRaNlRtWk9uTnViWVdwNE9Fa2ZvV1Zv?=
 =?utf-8?B?L3lwaE1uR1hLVVRPNGhQVzlMb0MxczVERDFBblRPNldZTGJhZzVNemlITHJT?=
 =?utf-8?B?S1B5d3Y0WEV3T09pQ2lzWGt4N1hXbUtRMzVzRlFtRjJRN2dxTlhZSkJDS1Ex?=
 =?utf-8?B?SW5PRkgrcHRvd1dnZlQyS0IwRHVJY1J0TlhMS0JhR052ME1aOUJKbituUlpk?=
 =?utf-8?B?UjRjOHQyZ1pmTmVGOGRyV1JzZVIvUmZhaU9nRXpiTUtydG5nQkdVcnZLblp0?=
 =?utf-8?B?K044bWdTSDEzZWhCYkJGOHdRa1BjbHFQTE1FU3dsYVRyRnNNUGs3MitPeHlL?=
 =?utf-8?B?MzQ4UlJnR1VvNEQ5WlRzbnE1M3VvUmFVQ3VGZGM1cHdiOEwzVHhCY3FFNGZT?=
 =?utf-8?B?K2d3aTF6V1BvdHdXQUR6SmtPb3dTMFp5RGNIaTJ5ZldQUXQva2w1YitqRDRS?=
 =?utf-8?B?ZTJBdXR2Qng1akZaSDVLcWU3Y3ZmNkdhR01VY3BaU2EwU3dGVVlKL1MwMVBO?=
 =?utf-8?B?NVVhUE1hQkFURXdJMjJXakFjTFphN2dISTZHN2hxVEVGeFhST2JvaGhqMFZj?=
 =?utf-8?B?U01SWlJ5V2NYcjJ3N054Qlp2YU11a2VjMnNVTnFNOFVZckJ5RmJXMUlBMUJK?=
 =?utf-8?B?U0ladmQrdm5Yb0U1VmNSU2t4QXYydVZBZ3YxRmM3QVFJdkxxV2ZJd1h2OUhm?=
 =?utf-8?B?ZDRWdjk5eGNYMVlwclU4WW5FTWNoOFZYUlVJU3BZMERlU2NpeWpJbzlMK2kr?=
 =?utf-8?B?ZEZvMG1MYlRsMkN4STU2TjJLTndJUTVMYjVwRGl6dWdUMlFCMnIrSzBQaGZQ?=
 =?utf-8?B?bkZHTW5tV1dtbnZJU2h4cVYxT3d3UnRXRWFkMVI0UVRBRkJBSkc2Y1dPNjJ5?=
 =?utf-8?B?T2ZDLzhkTm1uRVJ1bmh6Yjk3L2RDOE94UU44c3A4LzNBUXZhUGRYWFAwSW1H?=
 =?utf-8?B?eHVJSWEyWHdIQnc2ekUzN3lCSjA0aTVTNVZTdTFaUEtQNkZJNmZKQWIrV2ZQ?=
 =?utf-8?B?UTZ5VGpyWXk2VFZKY0l1V3NlMHp2MWpzc0pHbFVQRnZEUzU4bXlZNzZ2d1hS?=
 =?utf-8?B?WVhLKzBZMXdQQkFQeWliaFVhMXhFYXl0WXliYkViOS9wK3hINWlycTFNSjZO?=
 =?utf-8?B?Z2xGOWpJWmJjdUM2dktsazZlWmRvd2d1NDdPS0M0TWd1aE02Uy9UbE52MG9K?=
 =?utf-8?B?RDRUSHdwd0ZueFVrVURCd1ZlY005dHdHNkRZV1N3WXhLUVhpR3IyamIxNkRh?=
 =?utf-8?B?SGVWV2JFM1dHZlNqQ09ORXIyVnRuNEtNaElINGc0QW5kcm1HV2k3OFN0VjRk?=
 =?utf-8?B?TmxtbG5YUkNZdkloN21pcktGbzdCU2dBKytuT1c0TVNFVXIxaUZVR0lxVEhM?=
 =?utf-8?B?bUhlVG5YTmxodFh5VDFWT3JkSllpZVpjRjdsODQ2aHQwOEtxbEpSRGdvYVZF?=
 =?utf-8?B?SDFuSXdJRTBUV09JbHJjS2VIY3JsYkd3SjJkL0xDNDk0Vy9SODNUTGRkWjBR?=
 =?utf-8?Q?ab3GTw1cqaPTrMeGrQ1ZfoQth?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8a086494-5f0a-4841-0e58-08dda729681d
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jun 2025 07:44:04.0456
 (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: FE5qBOPJ3gmRXm8R6N2CkROlq1l2k8X3z3cHmbDIPUtrU0PhHpS04xhB1ww+CtwT
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7205



On 06/06/2025 18:48, Ayan Kumar Halder wrote:
> Enable the helper functions defined in mpu/mm.c and asm/mpu.h for ARM32.
> Define the register definitions for HPRBAR{0..31} and HPRLAR{0..31}.
> One can directly access the first 32 MPU regions using the above registers
> without the use of PRSELR.
> 
> Also fix the register definition for HPRLAR.
> 
> Signed-off-by: Ayan Kumar Halder 
It looks good apart from ...

[snip]

> @@ -98,7 +101,8 @@ static void prepare_selector(uint8_t *sel)
>          WRITE_SYSREG(cur_sel, PRSELR_EL2);
>          isb();
>      }
> -    *sel &= 0xFU;
> +    *sel = *sel & 0xFU;
this change. Why?

Apart from that:
Acked-by: Michal Orzel 

~Michal



From xen-devel-bounces@lists.xenproject.org Mon Jun 09 07:50:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jun 2025 07:50:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010126.1388254 (Exim 4.92)
	(envelope-from )
	id 1uOXH4-0002SW-SZ; Mon, 09 Jun 2025 07:50:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010126.1388254; Mon, 09 Jun 2025 07:50: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 1uOXH4-0002SP-Ns; Mon, 09 Jun 2025 07:50:30 +0000
Received: by outflank-mailman (input) for mailman id 1010126;
 Mon, 09 Jun 2025 07:50: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 1uOXH2-0002SJ-T9
 for xen-devel@lists.xenproject.org; Mon, 09 Jun 2025 07:50:29 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on2060b.outbound.protection.outlook.com
 [2a01:111:f403:2412::60b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 66f602f0-4506-11f0-b894-0df219b8e170;
 Mon, 09 Jun 2025 09:50:26 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by PH7PR12MB6491.namprd12.prod.outlook.com (2603:10b6:510:1f4::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.39; Mon, 9 Jun
 2025 07:50:22 +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.8792.034; Mon, 9 Jun 2025
 07:50:21 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 66f602f0-4506-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lV8838/isRcgM8PDKODHwtBgS8AXAOvigH4uDRBGnL56KY9dSXiNaDEnnHxgZ+MZjRVTd48gVf7YmP1ACdF+l+5LT8eKlyXz01FgaPT8Ryx20D1kxZeV9U3i6nkHT09ItQ+H5vzJsiuRHQZnx2FQGfCWLf3G4IUAYjjzKxmYZ9NZCf7VBlJhIKzzfS3zfeNXwU1IgrtjiONVeHK5ilQlOuLzT6CZ+4r64ynhePghXO7Ps5xwCAdTlly0B6dNFNVm5Hlok90uHPcUNkOXGEzXtsT38dXhJSVykyeo0UlnpvIRCo+LuKqwKMlY0KXPJt7JTNEY9w8lMX4ttWzRr1j2Cg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=EDxaw/c+RqHUnZ8gksJuimafw04no1Sl+VNFdaQb/DU=;
 b=Tva3Hjen3EYsuSj2Eg2Yo2tCYLvEhtSIcvWb59nTu7NGlt7tP5jirZ9crqejdtfBI9nctRFb3QFevaSBd911CSQ2cMsH+b/uL/WysV8ut6B2rcc9wra/sdlLzRyZjoUA28Mg+wAD1fB5qKlzwQqEIbH9oy0fh9LfDZIM9fmSUb3wnYPZdlAAhsbPbIeYGgUNL8Dc4RSQ5cJcc1sYQoYpMar3UD2hNLOgTvxDjjeh0HEqADn1lJ/FKZFa8AI0qGkzE0OQyw8SLXapVj77lQ46VoNIKZH/0uNstEnmjhGcpbmmKKgkleGk6mjRtvuMFYF2grnI/1C7djo0keUkeTOKLQ==
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=EDxaw/c+RqHUnZ8gksJuimafw04no1Sl+VNFdaQb/DU=;
 b=o6iXFmECe+kWYVmYu7R/yIvfbkGI/5Mxh/KweJQncrg+xRu/rwZKWO68F4gU3y7EwuwSB0PVEBXfjkW3ty4kTadkLa4i2LO4YFyyQWIrx9QjioL6WVOFI2EBQNJyNDaKB1UFwsEW48aDDXcfn8gplcSDs6Kdi8ApO2/71LMdwIs=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= 
CC: "xen-devel@lists.xenproject.org" , Jan
 Beulich , Andrew Cooper ,
	Anthony PERARD , "Orzel, Michal"
	, Julien Grall , Stefano Stabellini
	, "Huang, Ray" , "Chen, Jiqian"
	
Subject: Re: [PATCH v5 04/10] vpci: Refactor REGISTER_VPCI_INIT
Thread-Topic: [PATCH v5 04/10] vpci: Refactor REGISTER_VPCI_INIT
Thread-Index: AQHbziMOHCuaHG697kCTYWoBETQpzrP0lKSAgAGsWwD//4WWAIAAI9IAgAUkMwA=
Date: Mon, 9 Jun 2025 07:50:21 +0000
Message-ID:
 
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
 <20250526094559.140423-5-Jiqian.Chen@amd.com>
 
 
 <752cff02-cef6-4a4c-80b9-eba3bbf9b264@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.8792.033)
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_|PH7PR12MB6491:EE_
x-ms-office365-filtering-correlation-id: 132bc3bf-33a6-4b4a-5497-08dda72a496f
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?bEl4em5VdkVVeUdoWmgzQS9WdEFraXJEZjl3V2pVZFYyWEcrQ0JZeFlYZk5l?=
 =?utf-8?B?UUVJVG5VU2hvc2tQbTJtRC9PZFNRdDhXbUMwbE5BTmtMaFdkTnZ6enhHajlh?=
 =?utf-8?B?YktVM2xWZFZWUHRkajJTRTVidS9QN3hweFJ2eTUvM25oZVZXYVA4cFNRbWM0?=
 =?utf-8?B?NmRWNkZnTzBoNVZsZEl6RXZ5aDZRR3VUQ1NxNldLSW9hekVVZW9iN1ViUmhx?=
 =?utf-8?B?SVltc0NQem8zdktmbjAzZllUTFhKN01nb2hxeGlyR0F5Nmdpd2NBckxyNlZt?=
 =?utf-8?B?cnkwRWJYNVRvK21pRUpMNzdkNVd3Y2FMQXFsdGRIRDZvbjRQZThmMkJYc1dU?=
 =?utf-8?B?aFFhUUZqZEJQVmQxMnhtajNBQXhIaUNrTjJReE4wMHV3cm9WdCt2UEpuZk82?=
 =?utf-8?B?L2cweGE1Vmd5aWJ6RUxNMXhSZ1RWTmw1UlNlZXo0bHluaThScmU3ZTB2L3Zj?=
 =?utf-8?B?Q3Frd0M2c2JoYlJqdHFzQ1IvN0hXRGY0ZUc0WWxRSm8yRm8yM1hTY2ltSVQx?=
 =?utf-8?B?ZjdyeGRYa2cwdDhnZG9lb1Z1Mm5lSXBjN005a1kzazNxd3orbGtzVnlVMzJL?=
 =?utf-8?B?Nlkrem1MM1REMkVEcGt5ZTRhanl0Sm01T1pJbXdUa1VmemJEUXVsN0thcEp5?=
 =?utf-8?B?ajRlV1cvSFVOUHRwMHhIVlpLSG5vaFRIdWJVMEpwaEFnRy9KQ2Z6aHQ1SmYw?=
 =?utf-8?B?eU8zMFJHREVQbXkvNXA1MkpDZHVKL1ZndHQ5eUd6YVhIZ3NzOExqbHczT28r?=
 =?utf-8?B?cEdXWVpOZTdueDd1TWl0S3YraXcwZmNDTlJ0S0J2OFdwK2h1OGora2M0ZHdz?=
 =?utf-8?B?SVVrYWlET2JoRzJxMFdhYm5ONXpoVEQveEVUSzRXQzNyNHpoTkVrdmhTQTVq?=
 =?utf-8?B?c0UxUGZJdUJ4aWp3Tkova0dnbU9KeG1SZjUybHE3bDFzeGtjbGUvL0lrOTJs?=
 =?utf-8?B?WFBWNVFQYlh0MHVBYnNQMzNRSnRRY25lUVJuZjlqNnVRM290N3JqWnAwZkJu?=
 =?utf-8?B?MVZ2bG5Bc2F5aEhhaHNiemZ6N3F4L3VrNlVXMzVtYlJmUFRBMGliaDVNU3Ji?=
 =?utf-8?B?bldhS2tuYVBSRXI3dWM4b0RiRUl4NWp4WTRQS2xaNDFxeEJud0l3a0g2bWRJ?=
 =?utf-8?B?TTBnQkxsU3A0UEl2RlVxcmJGSHN4bWxaK1ArWm5SMWkwSW5JMDM5aFVPTHdj?=
 =?utf-8?B?M0VpeDBwNTF5eUp4MCtSci9aK0cyOVZpblZ1cE9JRXQvL3NGVUtJdVNOWlJY?=
 =?utf-8?B?dTY1K2ZSaHRWQXUvQnZNemRxRk51dGpwc2I2Z2xyTW9waFA2a3ppWFl3RzMz?=
 =?utf-8?B?Rk0vOEdxdGhFWG1kYldkUjVQTGk0THZ6UEU4MnFrejlqWXN5QXRIbzhkS2c0?=
 =?utf-8?B?RS9zRFR3U1IyclRZbG9rcWhLS3N3OXJaRkJWTFFIelhjN1U4KzdKa05uQmpk?=
 =?utf-8?B?UHhGWjJibWpMYm5ONjFGWTE2eVA3ZFZIVmZ2L25RcStIYmp5S3B4Z0dhalcx?=
 =?utf-8?B?RkdnZnF0R0JFSE8wZ3BCaXBOOU0yMmlVa1RudzVXbmk3aHFvcW56OE8yaHZt?=
 =?utf-8?B?a0ljbFBlTGh6b2VML1JnV1J0Tjc5QVdBbFEyRWlLSk9JVDY0c1l2Sk5qWDE2?=
 =?utf-8?B?TURSZEdiaE14YWZFMzcvK212MDhYQ25UYTEyS2JNcTBCYW5RMUtIeTNIOU84?=
 =?utf-8?B?UEt2dEErcEhCeWxyQjVuZU9uNE9RNFlQbnVmUGFLZVQrTXRVNDRXZFZFdk9K?=
 =?utf-8?B?WE5JaDRBdkhwWEkzdXZ1cm91MnRFQTN0a2Vjb3k5a1RmRjBxSldvdTgvanRX?=
 =?utf-8?B?ODU2SUl2dE1HemExcW1sRHhKMTBlTGloTTBvejkxM1I1a2tSWmdGRWhxN2Ew?=
 =?utf-8?B?K0RseXowQVdxa3Y2ZnRYR1B2dnRHMVBPZi9RbzAwQlJtNGxtMUcveW5Ha09n?=
 =?utf-8?B?eENJYzA5TUQvYTRVL01Nek1EbUxuMEQ4MEdTSWxWVmNkSU82S0R0eUk0YUM5?=
 =?utf-8?B?YnFJSDlPbVZRPT0=?=
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?bTBFYU1yWCtCcHM4ZGNYQ3hwYmNVVzVNMU5haHZ6NnAxSGh0a2JpbUlGTGky?=
 =?utf-8?B?MDZ2VnZCYTB1QThmdFlmZHljRWcwbXhYa2VHbmdHZlR1SnQzRDRKNmIzc3F6?=
 =?utf-8?B?a000UVZTZ1djaUQ2L1FjTEtkSk4wZDBKS2N3ZHFmSy9ERFpHSFJIaGprcjhU?=
 =?utf-8?B?TFZqdkdGWVpwdlhHdnFqNm05ODlRZm9QZ3NsTEtYRWFWaXVCYnFlODBUSjla?=
 =?utf-8?B?dVdEYzlpQ0JXamN5dmlxckk2WmoyWGkxczZ2cGRmNExHeDg4UVRXemc0NkhH?=
 =?utf-8?B?b3dzMnZGNHdjRitTdjVQdWk5VHFIdW12eWxQVTk5WlVvWTQxVWtKSzFIYWFT?=
 =?utf-8?B?TGd0QlBiYTZuUHlrM21tb0t0N2hRRFZXeFNtbFAwaEVPVFBKRVJjcEtQd2tZ?=
 =?utf-8?B?NnlEMkRaZE1wcWdNVVV1NG8rSjFhM3BvRXhuRlVET1ljdFBSWTc0aHcwZHli?=
 =?utf-8?B?YXJ4OTA0NThrTjVBRTdic2Y3Tzd2QnQ2OUtYcUExdG1qTWZXVDNvM0FjYUk0?=
 =?utf-8?B?MHRYYm5xVFRpeHJEcVBUWkUvZEJPMk9pdTBEcnVPWkpNa2l4aEpYT0hWMHNk?=
 =?utf-8?B?S1RwVE9Fa3Y0aEIxME51SW92UWYxSkNkcDEybVJXUmQ1KzVJRTZUbnREaXJE?=
 =?utf-8?B?Z2FDME1mY2JKQVo2cjh2T1N6UWZmQmlQM0dhb2d2eWwyWUZxSW12Ry9CUGpj?=
 =?utf-8?B?RnpOd1VMWDh1ZXpzWlZJbTlVTksxM1ZBR2dPTWhRWmQzVldPdHZXb0xTMloy?=
 =?utf-8?B?ZTdZNDkwTURUbi81WGxKTngvbjZkOUFDVlE0aXhPZTRKaE4vRkJhK0padDNR?=
 =?utf-8?B?MWRkVStiMG5vVG44NkNLZUQyYnJETWVrMktWSjB1UW5LNFRpUSsvb3FpQ1J4?=
 =?utf-8?B?RjFDNVVoZHJxSU5wQ2NnR3JqeENnbFJkd01aQjVHSVlKanRWYWxtNVhzUnU2?=
 =?utf-8?B?UlIvNGwveFZYR3hWeEZaMWMyTmsyc3VLeWY5NzMzN3NISGk5bVFHVWVGZWQw?=
 =?utf-8?B?dDh5THZPd0J2U2xvNjhHSFBFK21IaUhMUUEvaGZpQk5MYzcvSC9GRStEQWpp?=
 =?utf-8?B?WlViNHhvT1ZFRkF2bTdTWWt5dkhlWHNTTklYUC9JZTh4WmhYMEVwWjg2V2JZ?=
 =?utf-8?B?R2o1VWhLdFdaNnJIaUR3UUVSOEowWVJ6SFB6bTZPeGpJczJOdjhaZExaQ0F5?=
 =?utf-8?B?Y0JPbkhzbDA3N29yLzBLbmh1SWRmKzB1WDgyRjFJNlVyNE92OUxGM1ROM1Vt?=
 =?utf-8?B?WWhrK1pOWmNOQVJlTnJQVEFlb0hsUGluOXhiRG1JTTgya1Z2MzZWTCs1TGJH?=
 =?utf-8?B?RitLMVd6a0s0UXlPaVRTZEpOaXpZVmZoZTdncnYySFBpck1tSlJ0VFVBdGZl?=
 =?utf-8?B?UGJjaEhpOXdZaE1XSzd3Q0JqR2piR0E5YzJQdTJyalJHTWNtSnZDbFRjQ2lZ?=
 =?utf-8?B?cnVQN3NvYmtyOUp1NnNvUjlEMDJxbkRmajVITkdpMCtrM0tiUG5qQnZnQWQ3?=
 =?utf-8?B?bzdXVjFkcEFTbHlPT1Rta3ZPcGtNTDlybnJGTUJnbFFJS0R0Y3hMSmE4T1Vq?=
 =?utf-8?B?RGRmWGhxYkhzcnBON2g4YUdkZEEvVWNFZ0dUditHYk9wUmpQeUY0L2IvbUN0?=
 =?utf-8?B?YUxpVFloUWswMTRBMFEvWWwzdThpemhJUUNRTFkzaFVBU3F0ejQ3OHFBVkhv?=
 =?utf-8?B?T24wSGd0YWZZM0V2THpFSVo2cXhJTjFoRTl3R1BQcGZKRFFhdnJhT2dxVFJF?=
 =?utf-8?B?d0JxdThYU1pPK3NCTnJ3Y2QxeE0rajNQWkpvcWo2aGxDNXRZczVoQWlsbkM3?=
 =?utf-8?B?L3VLYUZCSTd1YmhzTkduUWJiZkxSbCtBZkhpWldpVDdXQlU2bkxxR0svb2Z6?=
 =?utf-8?B?dElzOS9kTlViZHVjSDVKV2JpNzBuQVFLTGlRVXVJN0dBOFMrSFZRM0drbU9l?=
 =?utf-8?B?K3o5ZzZxK0tQS2xTQk13dHhNMTAwNmpvSGpUdlJKMHo2VlovNXBKcEx4YWhU?=
 =?utf-8?B?dGw5QlYyYkJmY1ptSmtQcGpmR0FLL0JQWEJlazgyYnVzMmk0eGdCajlHbkMr?=
 =?utf-8?B?Uys5ckprK1A3bi9vcG9GZnV0S0k2N0wxZVpXYlNzakQrM0R5Snc5YVB2Y3pD?=
 =?utf-8?Q?esXw=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <4355642E3E1139448B27D97C77AADB25@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: 132bc3bf-33a6-4b4a-5497-08dda72a496f
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2025 07:50:21.8543
 (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: l0GJYLN3FB1vASO4HYJScxd5eMdqc+UzxAt3hGe5jSxQ7rYSoS90Pti2j1JIUc4xSEXGs8ikgmaod3temIOMbg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6491

T24gMjAyNS82LzYgMTc6MTQsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+IE9uIEZyaSwgSnVu
IDA2LCAyMDI1IGF0IDA5OjA1OjQ4QU0gKzAyMDAsIEphbiBCZXVsaWNoIHdyb3RlOg0KPj4gT24g
MDYuMDYuMjAyNSAwODoyOSwgQ2hlbiwgSmlxaWFuIHdyb3RlOg0KPj4+IE9uIDIwMjUvNi81IDIw
OjUwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOg0KPj4+PiBPbiBNb24sIE1heSAyNiwgMjAyNSBh
dCAwNTo0NTo1M1BNICswODAwLCBKaXFpYW4gQ2hlbiB3cm90ZTogDQo+Pj4+PiArICB9OyBcDQo+
Pj4+PiArICBzdGF0aWMgdnBjaV9jYXBhYmlsaXR5X3QgKmNvbnN0IGZpbml0IyNfZW50cnkgIFwN
Cj4+Pj4+ICsgICAgICAgICAgICAgICBfX3VzZWRfc2VjdGlvbigiLmRhdGEudnBjaSIpID0gJmZp
bml0IyNfdA0KPj4+Pg0KPj4+PiBJTU8gdGhpcyBzaG91bGQgYmV0dGVyIHVzZSAucm9kYXRhIGlu
c3RlYWQgb2YgLmRhdGEuIA0KPj4+IElzIGJlbG93IGNoYW5nZSBjb3JyZWN0Pw0KPj4+DQo+Pj4g
KyAgICBzdGF0aWMgY29uc3QgdnBjaV9jYXBhYmlsaXR5X3QgKmNvbnN0IGZpbml0IyNfZW50cnkg
IFwNCj4+PiArICAgICAgICBfX3VzZWRfc2VjdGlvbigiLnJvZGF0YSIpID0gJmZpbml0IyNfdA0K
Pj4NCj4+IE5vLCBzcGVjaWZpY2FsbHkgYmVjYXVzZSAuLi4NCj4+DQo+Pj4+IE5vdCB0aGF0IGl0
IG1hdHRlcnMgbXVjaCBpbiBwcmFjdGljZSwgYXMgd2UgcGxhY2UgaXQgaW4gLnJvZGF0YSBhbnl3
YXkuICBOb3RlDQo+Pj4+IGhvd2V2ZXIgeW91IHdpbGwgaGF2ZSB0byBtb3ZlIHRoZSBwbGFjZW1l
bnQgb2YgdGhlIFZQQ0lfQVJSQVkgaW4gdGhlDQo+Pj4+IGxpbmtlciBzY3JpcHQgYWhlYWQgb2Yg
Kigucm9kYXRhLiopLCBvdGhlcndpc2UgdGhhdCBzZWN0aW9uIG1hdGNoIHdpbGwNCj4+Pj4gY29u
c3VtZSB0aGUgdlBDSSBkYXRhLg0KPj4+IEkgYW0gc29ycnksIGhvdyB0byBtb3ZlIGl0IGFoZWFk
IG9mICooLnJvZGF0YS4qKSA/DQo+Pj4gSXMgYmVsb3cgY2hhbmdlIGNvcnJlY3Q/DQo+Pj4NCj4+
PiBkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUveGVuL3hlbi5sZHMuaCBiL3hlbi9pbmNsdWRlL3hl
bi94ZW4ubGRzLmgNCj4+PiBpbmRleCA3OTNkMGUxMTQ1MGMuLjM4MTc2NDIxMzVhYSAxMDA2NDQN
Cj4+PiAtLS0gYS94ZW4vaW5jbHVkZS94ZW4veGVuLmxkcy5oDQo+Pj4gKysrIGIveGVuL2luY2x1
ZGUveGVuL3hlbi5sZHMuaA0KPj4+IEBAIC0xODgsNyArMTg4LDcgQEANCj4+PiAgI2RlZmluZSBW
UENJX0FSUkFZICAgICAgICAgICAgICAgXA0KPj4+ICAgICAgICAgLiA9IEFMSUdOKFBPSU5URVJf
QUxJR04pOyBcDQo+Pj4gICAgICAgICBfX3N0YXJ0X3ZwY2lfYXJyYXkgPSAuOyAgIFwNCj4+PiAt
ICAgICAgICooU09SVCguZGF0YS52cGNpLiopKSAgICAgXA0KPj4+ICsgICAgICAgKigucm9kYXRh
KSAgICAgICAgICAgICBcDQo+Pg0KPj4gLi4uIHRoaXMgaXNuJ3QgLSB5b3UnZCBtb3ZlIF9hbGxf
IG9mIC5yb2RhdGEgaW50byBoZXJlLCB3aGljaCBkZWZpbml0ZWx5DQo+PiBpc24ndCB3aGF0IHlv
dSB3YW50LiBXaGF0IEkgdW5kZXJzdGFuZCBSb2dlciBtZWFudCB3YXMgYSAucm9kYXRhLWxpa2UN
Cj4+IHNlY3Rpb24sIGUuZy4gLnJvZGF0YS52cGNpLiogKG11Y2ggbGlrZSBpdCB3YXMgLmRhdGEu
dnBjaS4qIGJlZm9yZSkuDQo+IA0KPiBJbmRlZWQsIG15IHN1Z2dlc3Rpb24gd2FzIG1lcmVseSB0
byB1c2UgLnJvZGF0YSBpbnN0ZWFkIG9mIC5kYXRhLCBhcw0KPiB0aGF0J3MgbW9yZSBhY2N1cmF0
ZSBJTU8uICBJIHRoaW5rIGl0IHNob3VsZCBiZSAqKC5yb2RhdGEudnBjaSkgKGFuZA0KPiBzYW1l
IHNlY3Rpb24gY2hhbmdlIGZvciB0aGUgX191c2VkX3NlY3Rpb24oKSBhdHRyaWJ1dGUuDQoNCklm
IEkgdW5kZXJzdGFuZCBjb3JyZWN0bHksIHRoZSBuZXh0IHZlcnNpb24gd2lsbCBiZToNCg0KKyAg
ICBzdGF0aWMgY29uc3QgdnBjaV9jYXBhYmlsaXR5X3QgKmNvbnN0IGZpbml0IyNfZW50cnkgIFwN
CisgICAgICAgIF9fdXNlZF9zZWN0aW9uKCIucm9kYXRhLnZwY2kiKSA9ICZmaW5pdCMjX3QNCisN
Cg0KYW5kDQoNCiAjZGVmaW5lIFZQQ0lfQVJSQVkgICAgICAgICAgICAgICBcDQogICAgICAgIC4g
PSBBTElHTihQT0lOVEVSX0FMSUdOKTsgXA0KICAgICAgICBfX3N0YXJ0X3ZwY2lfYXJyYXkgPSAu
OyAgIFwNCi0gICAgICAgKihTT1JUKC5kYXRhLnZwY2kuKikpICAgICBcDQorICAgICAgICooLnJv
ZGF0YS52cGNpKSAgICAgICAgICAgXA0KICAgICAgICBfX2VuZF92cGNpX2FycmF5ID0gLjsNCg0K
QnV0LCB0aGF0IGVuY291bnRlcmVkIGFuIHdhcm5pbmcgd2hlbiBjb21waWxpbmcuDQoiIHtzdGFu
ZGFyZCBpbnB1dH06IEFzc2VtYmxlciBtZXNzYWdlczoNCntzdGFuZGFyZCBpbnB1dH06MTE2MDog
V2FybmluZzogc2V0dGluZyBpbmNvcnJlY3Qgc2VjdGlvbiBhdHRyaWJ1dGVzIGZvciAucm9kYXRh
LnZwY2kNCntzdGFuZGFyZCBpbnB1dH06IEFzc2VtYmxlciBtZXNzYWdlczoNCntzdGFuZGFyZCBp
bnB1dH06MzAzNDogV2FybmluZzogc2V0dGluZyBpbmNvcnJlY3Qgc2VjdGlvbiBhdHRyaWJ1dGVz
IGZvciAucm9kYXRhLnZwY2kNCntzdGFuZGFyZCBpbnB1dH06IEFzc2VtYmxlciBtZXNzYWdlczoN
CntzdGFuZGFyZCBpbnB1dH06NjY4NjogV2FybmluZzogc2V0dGluZyBpbmNvcnJlY3Qgc2VjdGlv
biBhdHRyaWJ1dGVzIGZvciAucm9kYXRhLnZwY2kgIg0KDQpBbmQsIGR1cmluZyBib290aW5nIFhl
biwgYWxsIHZhbHVlIG9mIF9fc3RhcnRfdnBjaV9hcnJheSBpcyBpbmNvcnJlY3QuDQpEbyBJIG1p
c3MgYW55dGhpbmc/DQoNCj4gDQo+IFRoYW5rcywgUm9nZXIuDQoNCi0tIA0KQmVzdCByZWdhcmRz
LA0KSmlxaWFuIENoZW4uDQo=


From xen-devel-bounces@lists.xenproject.org Mon Jun 09 08:27:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jun 2025 08:27:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010140.1388271 (Exim 4.92)
	(envelope-from )
	id 1uOXqq-0007YX-Md; Mon, 09 Jun 2025 08:27:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010140.1388271; Mon, 09 Jun 2025 08:27: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 1uOXqq-0007YQ-JT; Mon, 09 Jun 2025 08:27:28 +0000
Received: by outflank-mailman (input) for mailman id 1010140;
 Mon, 09 Jun 2025 08:27: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 1uOXqp-0007YK-1O
 for xen-devel@lists.xenproject.org; Mon, 09 Jun 2025 08:27:27 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on2062c.outbound.protection.outlook.com
 [2a01:111:f403:2009::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 91136224-450b-11f0-b894-0df219b8e170;
 Mon, 09 Jun 2025 10:27:24 +0200 (CEST)
Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
 by SJ2PR12MB9211.namprd12.prod.outlook.com (2603:10b6:a03:55e::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Mon, 9 Jun
 2025 08:27:20 +0000
Received: from PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264]) by PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264%2]) with mapi id 15.20.8792.035; Mon, 9 Jun 2025
 08:27: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: 91136224-450b-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=QdGhAB+W1l2svRQPMTzmlp+z2mdwJfRiyfPAsbc6gyhJfDHXmj+3sj2zMlU7VNnjNU0PUoBEUHju5HJFOZsHPcL5D8M1L8KJ7vCXwLFmCOnWrrxIGiUoUnBgFJ7NQVKkVhBTpUlAJbzhgEjoz485+dDiSu2Ftb5HaxXyKYZk3xPS0s7e6Rk8mvBfEVbJFX/xTQjtwDqagcBTIuCDA2JtIjPpfc2Ng6lc8aSJztiA1O4CPRDV6VN1SAaPs+OQi4HbV+DYUwKXll+84ooezGYUQI5kLsF53Me38s1CXorWq16IQuej/FRHBlfw5qg6TpGbEGueIPLX+ofj644rmLHQFg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=thTDNQ0aEfZfGJMhkEE5KLaEV6e1Bzn3CLrqLYwuLW8=;
 b=Kso9RCRmTYh3yWBK/FPAaxU0Vrp0kko5KEF6o+lAE7FeWWACwXGskRoIdZPk/3/49AEf/7kBmajeqgUb3pOjbBAa4Nn3hoBOHUUb0NlshDWClbVRu5CweqBVkCiBngIVL1mmV9ZkCZ4voyxevjnwvCl+iI1ml3mkgbYLb5G429zYSGA/KE63oe16bS3NzIyn7Isajjc5aGvbOYX0KqAsah8fgBtOjWWVYiOFTWQa+GdiInrjPkNvLMQXUpkY/Vwvfa7aoo7MWnRrGF6lWsv1+bS+cbrLhZuTl6Kakx3h0ZkfN2y82HJr4gBPUq0hy4cqgC340zF6WoJAq7Ipve6aBg==
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=thTDNQ0aEfZfGJMhkEE5KLaEV6e1Bzn3CLrqLYwuLW8=;
 b=qw9prf9Tx5wLToR3Lms33UiPgbk9ufAbFF7cI8AxsOFbnVCXgYzfYnOVT3TRk8KSyfz+14X6WWuV5mglOnbMBvr+prZx2F1sheWMFpqCmiRP4IhB+1+AXtIUZ6huttZSvh/bOBKQh4uhLooBLKL7IzID3pi8BI+4TF3VZ3htgmg=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Mon, 9 Jun 2025 09:27:15 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/3] arm/mpu: Provide and populate MPU C data
 structures
To: "Orzel, Michal" ,
 Ayan Kumar Halder , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250606164854.1551148-1-ayan.kumar.halder@amd.com>
 <20250606164854.1551148-3-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: 8bit
X-ClientProxiedBy: ZR0P278CA0046.CHEP278.PROD.OUTLOOK.COM
 (2603:10a6:910:1d::15) To PH8PR12MB7326.namprd12.prod.outlook.com
 (2603:10b6:510:216::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|SJ2PR12MB9211:EE_
X-MS-Office365-Filtering-Correlation-Id: 1fe6a7e0-69c1-4e79-f2b7-08dda72f7348
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?UHFKQnQrcnUva3hCRFFCWUcyT3NONXQvVnJhMnpzTGhiUHZuVFRpZjNvMkpT?=
 =?utf-8?B?eG13eDdkbHI4RWhSRVYxbS9iZW9zQjl4WjkwcWVHV0UvbVdIQU5tZXUyMzBh?=
 =?utf-8?B?bzNWbFBLVm8rM2lxNHhBcHI3TUFqTzdCTUpUYWhwSmFyQ2p3SEhNcVB0M1Ex?=
 =?utf-8?B?b2hSSmh4R0xWVWs3MWFZS2Q5OW5WV0M1dDk2ZFcrOHF0N1g0REdSR0dZNk82?=
 =?utf-8?B?ZXRJalVJVG52QmJYMCs5ZWUvQUZTd1ZuVFkybUJ2SEN4ZHdsOHhQc0pDa0pq?=
 =?utf-8?B?S1lBM1g4Z0lzNzNwRER5VzJzdWk1d0gvazU0QVl6bEw1aFpTZVNBSFB4aURQ?=
 =?utf-8?B?b2kvaXY2T09TenNJRFZRWkgrOHNPWUtVYzZSYXN1bXdjK3g2dUtFYm1RaVVj?=
 =?utf-8?B?TEVkdllwUjA2VmhDcDNQek8wQWZaWFlGUk84cnN6U091QnFqM3RvWDJhK3lF?=
 =?utf-8?B?L2lPdWZ2WUE5TWZZVVdWMjkzbWJkdm95SUdnUVlGaEdyaUc2OWVKR0lVUFRu?=
 =?utf-8?B?d3hwUlU2QmdrSnhXcFZnUTVQbXUyMFllRUZHUWNpazhTM3lacEtQL0RnS2lZ?=
 =?utf-8?B?eVgwWjVkdEg2ZGhLRERlU2MxSHg4R1ZBejJmRnNjdUd1cldnamIzSjlUTU8z?=
 =?utf-8?B?YTlsYzVtRHQ0cEVJUzBGOERNanRYdWhvVE04UzJGSTl3SElrTit0RkNKNVRU?=
 =?utf-8?B?YmV6ZzlidlpkQzdra1h1Ly9uVS9DS29CdEQ4M3dJK285d0Z5RmlKL1NlS1hn?=
 =?utf-8?B?alVxUDFVZGl1TkxoT3ZpR2FQOWVNQm9MUGFuZ25uUVd1L3NtcGpuYVdnaXVv?=
 =?utf-8?B?OGxsMUZBMUdkczU5T3RnZjkzNXByU1gxTCswWWF2MWc4R2NrOE80b0p2Vzdn?=
 =?utf-8?B?TndFTmVaZHhzemJwUVNzYUpIcUI5R0ZVVUp1VXpkVkdhT20ydmRuNUlIMWsw?=
 =?utf-8?B?aHI3bE5YQ2dibGQvVGtrSzdPVHRwTThJSmJlWGpqWWErSERzV0lVcnh2aDIy?=
 =?utf-8?B?aW55aWFoU2F6T2N2a2lyaVlBVmRjLytmeUNwZWVyTXpNclM1MWw5emFTYi9H?=
 =?utf-8?B?RHZSRnVGQlpneklWd0hHREh5R0pMQ0thUDh6QWxnSUtZWjhlcFAvV05ZWGY4?=
 =?utf-8?B?SlhCZG9MK1daUk42N1N0SSsvaGFLNmJkV3JDTjBXU1RlTjJHVnBJUm10RG00?=
 =?utf-8?B?eHd4NDJPNDNpaEVOaFF3MGlyMmliZmVjMGs0WjU1UXVoVENCSHNzdEF4blI2?=
 =?utf-8?B?b0NhV0l0Q3RjWUVTTXEzaGI3SzNYd0l1VndRWVpEeFo0eXRZUUhMMVN1d21T?=
 =?utf-8?B?V1g0MjFYWUozL2twcHNCdi9xdDZiOGo4NUczVnVJQVN3SkRUOTVFOVl1ajRp?=
 =?utf-8?B?d2ZUYWtNcklZQ0hnWWc1MjUrTit5Um5TWHN6RVBWdlUzZDVKSWx3WUwwZHRT?=
 =?utf-8?B?KzdzZWZzemMvZWJOZkYyKzFzYzR5Mnp0U3BpMm8rVXhQVXN0SVRmSW5TRDRk?=
 =?utf-8?B?cmdtZm9uOEZFMHBGUnZmNjU3c3RNSHBneWhRZzRCTnNOU2xDNTNjb240aXNl?=
 =?utf-8?B?d3UyeVR4dFF5RUROaGxlN0J6SHpGQ1JQZlpqbmdFQWdLYjltQTBVRUVuZytt?=
 =?utf-8?B?bHlwaGM4Y01lVnUyVGV2ekJWb0NqZGFwYitoT3AvYk13TmRqVktSU1pZWFNJ?=
 =?utf-8?B?Q3ZmNHFLVEswQ1dkVmtZOFAzaS95SXF2dUlEQjQ4QzZrRlpWMTJrWDZVOWNk?=
 =?utf-8?B?ZWFMWWZ1aWNBSksyYzFGelRzUGVONTNWNDVlbVVHVklUMXNzUGtLQmFDN1Nh?=
 =?utf-8?B?UVZRT0tPZDREQVBlM09aaVkyY3pMbG04S0g4elNMNlpydUJ6NFV5MWxYbVpl?=
 =?utf-8?B?ZUZmTGZDc1B2ZzB2NytkZ21ZZlFZSUhHdnNlMitSc1lTeXQ4YkNPWjI0QzBV?=
 =?utf-8?Q?vROF9C6ay7I=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)(1800799024)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?bENsQzN0MDhod3NqUXZiTFpFQ1RaWDJJOGRWdnJCZ3FrZmFpcEkreDVET0lL?=
 =?utf-8?B?cTl2QTlORklwb1lrU2hZY01nRTJabUJQK2R2MlA2OE45RHArMTFjYjlLNkFo?=
 =?utf-8?B?aHlaNjFXYUNiZEZndEdhKzRQL0tCWjBkdnd0NDRxaXk1MnNFZzhGaHpTK2xD?=
 =?utf-8?B?Q0lOL0ZaSE9jUE9Qc1dyYmR6eXh4Q2x5ZGxEVk40SDdaSktQWW5wQlJSbno4?=
 =?utf-8?B?a2RLK0sycllOM0JVelJWRGUrQWUvc2N2QVAxZW40VG82NzlvNWhmWUx3dm1o?=
 =?utf-8?B?MjZEcGVOYXpYS0xJamlldUZlaGxvYnQzeTZ3eGVsM25Yc25nWEwzS1ZVLzZT?=
 =?utf-8?B?ellkbkIxdE1UZ1lYVjllUDlCWkNRY2Vlb21mSXFtc0N3bVdiYWdvQTdQS1I0?=
 =?utf-8?B?VVlWdDVKVGs4TkFEUjg3NDV3Tk01K3ZCSEtvYlNYK0VQM1RmMDZEUVBwNWNp?=
 =?utf-8?B?SCtFYWFta0ltcTNRR0wvZ3R4Y2s5US9VbU9Objd1RnV5NG5OaTRObHg4dEp2?=
 =?utf-8?B?aHVTNnFjSzNGc29sVjg1RVl5YzdwRGppQUZyamVFKzQ1bkREZk53bXk0MFFK?=
 =?utf-8?B?M1RiV21xb1drNlMrUmpvVjE1dmdOUDVPbG16VVpLZERHTEs4OHY0RjRJS1oy?=
 =?utf-8?B?cktMSlhYbC9weVhWYzFHR0VMbXZwbVMydW1ZLytWaWdIL1pHczdMTFZiNWs1?=
 =?utf-8?B?NTRpUmRCVEQ4bWlvZVdZN1pMaXBkWkp5VUVQdlB0Tm1QL1Y2THBqemNYZjNx?=
 =?utf-8?B?dS9NSk1pQzFWUmcxWWRheEZhbk93UUlmWFRWSHhBalFLUE40KzRHWHl4alVK?=
 =?utf-8?B?T0MwbTRucWZ6MFRmRS9YaThmRi9wbHNBR0lkV2o2ellGR1JFTnRkL05yZUtx?=
 =?utf-8?B?a3ZjOWE4a3VZUXlMY1QvaUZpVDVsaUIxK1JaeXVXeWdMaXIrUTM1UWFWaHhy?=
 =?utf-8?B?WGlQWC8wRTcxSzNRbkNpRU1YK2ZiSCtXYkpKY1M0dU8zYVdSYTQrZUZQdWxG?=
 =?utf-8?B?NE9kZ2I0aCt3ZmVqSU1FVVg1WTZSL2pIRUp0TU9GK2VOZmdNQzB6YktSWGRm?=
 =?utf-8?B?dVJTd29nOTRYRlFpTXRRK3ZuaGIzK1hVV0NBZGQyQTRzdzVCRkZabmZqNjJs?=
 =?utf-8?B?b3lkbDNudi9jQ21wdjlGKytrck1QV2gzNVNqam9abE9kbFhOVUc5cnBXUnp3?=
 =?utf-8?B?YUtzWWozbUlBcDJTZmtyK1A2eldnVCs0N09jYXI5dFh2RUpISVRMT0EvTzhq?=
 =?utf-8?B?N1BMN293Sm40ckJ3cFc1bmc4cXpKekQzU0tUTjBNWUVjQXNYdDZoY3RDc1lZ?=
 =?utf-8?B?QmZIWXBIcUgzSWtTQUxHUEFaMU1mSkJkK3U1RHZaODl5V1dWYUhSbm5vVTRJ?=
 =?utf-8?B?RlRUc0JGZXVRcmZRY1hqUHFiMUFTRTF1QVh2eFBORUF5ZEQ4UDZ3ck5KWkht?=
 =?utf-8?B?Q3htbDB5UFlOTlhXMHZzRURkRUM0dVZQSHRaSVRDM1FudHM0bEdWKzN6NTBp?=
 =?utf-8?B?dmVlTWdVTUd4UTBEUGRUTExiSVhHd0IyUFk0VmhyV1VudkdqSzg0aU5kbG5m?=
 =?utf-8?B?WlN3cGU1YXRTeXBSM3BaRndwU2k5elpUZ2tER1pWZDNpL3BZVlRYZjFOQlhO?=
 =?utf-8?B?ZzUzZTNXdm81WjExeHA1ZEJWZ3JqQmNwR2dLVkNiMlZ2YXZXc0l2MTlLS09E?=
 =?utf-8?B?c2lyQ3FvUlRTdHpoRGNmMVQ4dkRPZzA4blZPOStvcHNBS1NGTFJheGpoZ0tm?=
 =?utf-8?B?UkViK3RUdVV2RWtkZzdUU0tCdGxjajlCQm9mS1VrVm1lOVBTekpkV0g3eWJG?=
 =?utf-8?B?cjNSdnN5a0pvYktQNGs2b2FjSldsOWw4bGNqdW1OTHJ1UHRIelF2Mjkyc2Vy?=
 =?utf-8?B?aEFiN1lxVklVMEJRSWRCaTBGZkxud0VEMHg0MmlvYkNVS1VjcCtmOXIvbklD?=
 =?utf-8?B?YTJRV2dkOHlXWEVGM2FaK3U3NGU3UFFIdDVYcUdZN2ROSFVVcEsxWEpXZE9L?=
 =?utf-8?B?UDhwUDluMEMrN0REREVJZndzRzBuK083eWFYQ2RaeEhPYXRTd2txQzNWRWJQ?=
 =?utf-8?B?YjJYeFZUWmM2NnJjQWo1V0lUN0EyWmtDNzF1L2dzbFUzRFRWK25uMXF5ejFK?=
 =?utf-8?Q?5Afq0gk+nEjdsx2dHQAwPAAkK?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1fe6a7e0-69c1-4e79-f2b7-08dda72f7348
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jun 2025 08:27:19.7601
 (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: eYurvA6+xX+05yaqX3Yd4sYE+FyqN1stKM4onkt8RVU1oNjMuz8Q50rs0j3hGJXhUVcOn7/q+JiDPylCMKoQbA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB9211

Hi Michal,

On 09/06/2025 08:41, Orzel, Michal wrote:
>
> On 06/06/2025 18:48, Ayan Kumar Halder wrote:
>> Modify Arm32 assembly boot code to reset any unused MPU region, initialise
>> 'max_mpu_regions' with the number of supported MPU regions and set/clear the
>> bitmap 'xen_mpumap_mask' used to track the enabled regions.
>>
>> Use the macro definition for "dcache_line_size" from linux.
>>
>> Signed-off-by: Ayan Kumar Halder 
>> ---
>> Changes from v1 :-
>>
>> 1. Introduce cache.S to hold arm32 cache initialization instructions.
>>
>> 2. Use dcache_line_size macro definition from linux.
>>
>> 3. Use mov_w instead of ldr.
>>
>> 4. Use a single stm instruction for 'store_pair' macro definition.
>>
>>   xen/arch/arm/arm32/Makefile              |  1 +
>>   xen/arch/arm/arm32/asm-offsets.c         |  6 ++++
>>   xen/arch/arm/arm32/cache.S               | 41 ++++++++++++++++++++++++
>>   xen/arch/arm/arm32/mpu/head.S            | 25 +++++++++++++++
>>   xen/arch/arm/include/asm/mpu/regions.inc |  2 +-
>>   5 files changed, 74 insertions(+), 1 deletion(-)
>>   create mode 100644 xen/arch/arm/arm32/cache.S
>>
>> diff --git a/xen/arch/arm/arm32/Makefile b/xen/arch/arm/arm32/Makefile
>> index 537969d753..531168f58a 100644
>> --- a/xen/arch/arm/arm32/Makefile
>> +++ b/xen/arch/arm/arm32/Makefile
>> @@ -2,6 +2,7 @@ obj-y += lib/
>>   obj-$(CONFIG_MMU) += mmu/
>>   obj-$(CONFIG_MPU) += mpu/
>>   
>> +obj-y += cache.o
>>   obj-$(CONFIG_EARLY_PRINTK) += debug.o
>>   obj-y += domctl.o
>>   obj-y += domain.o
>> diff --git a/xen/arch/arm/arm32/asm-offsets.c b/xen/arch/arm/arm32/asm-offsets.c
>> index 8bbb0f938e..c203ce269d 100644
>> --- a/xen/arch/arm/arm32/asm-offsets.c
>> +++ b/xen/arch/arm/arm32/asm-offsets.c
>> @@ -75,6 +75,12 @@ void __dummy__(void)
>>   
>>      OFFSET(INITINFO_stack, struct init_info, stack);
>>      BLANK();
>> +
>> +#ifdef CONFIG_MPU
>> +   DEFINE(XEN_MPUMAP_MASK_sizeof, sizeof(xen_mpumap_mask));
>> +   DEFINE(XEN_MPUMAP_sizeof, sizeof(xen_mpumap));
>> +   BLANK();
>> +#endif
>>   }
>>   
>>   /*
>> diff --git a/xen/arch/arm/arm32/cache.S b/xen/arch/arm/arm32/cache.S
>> new file mode 100644
>> index 0000000000..00ea390ce4
>> --- /dev/null
>> +++ b/xen/arch/arm/arm32/cache.S
>> @@ -0,0 +1,41 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +/* Cache maintenance */
>> +
>> +#include 
>> +
>> +/* dcache_line_size - get the minimum D-cache line size from the CTR register */
>> +    .macro  dcache_line_size, reg, tmp
>> +    mrc p15, 0, \tmp, c0, c0, 1     /* read ctr */
> Why open coding macro CTR? Especially if below you use DCIMVAC.
>
>> +    lsr \tmp, \tmp, #16
>> +    and \tmp, \tmp, #0xf            /* cache line size encoding */
>> +    mov \reg, #4                    /* bytes per word */
>> +    mov \reg, \reg, lsl \tmp        /* actual cache line size */
>> +    .endm
>> +
>> +/*
>> + * __invalidate_dcache_area(addr, size)
>> + *
>> + * Ensure that the data held in the cache for the buffer is invalidated.
>> + *
>> + * - addr - start address of the buffer
>> + * - size - size of the buffer
>> + */
> I do think that for new functions in assembly we should write what registers are
> clobbered. Arm64 cache.S originated from Linux, hence it lacks this information.
>
>> +FUNC(__invalidate_dcache_area)
>> +    dcache_line_size r2, r3
>> +    add   r1, r0, r1
>> +    sub   r3, r2, #1
>> +    bic   r0, r0, r3
>> +1:  mcr   CP32(r0, DCIMVAC)     /* invalidate D line / unified line */
>> +    add   r0, r0, r2
>> +    cmp   r0, r1
>> +    blo   1b
>> +    dsb   sy
>> +    ret
>> +END(__invalidate_dcache_area)
>> +
>> +/*
>> + * Local variables:
>> + * mode: ASM
>> + * indent-tabs-mode: nil
>> + * End:
>> + */
>> diff --git a/xen/arch/arm/arm32/mpu/head.S b/xen/arch/arm/arm32/mpu/head.S
>> index b2c5245e51..435b140d09 100644
>> --- a/xen/arch/arm/arm32/mpu/head.S
>> +++ b/xen/arch/arm/arm32/mpu/head.S
>> @@ -49,6 +49,10 @@ FUNC(enable_boot_cpu_mm)
>>       mrc   CP32(r5, MPUIR_EL2)
>>       and   r5, r5, #NUM_MPU_REGIONS_MASK
>>   
>> +    mov_w   r0, max_mpu_regions
>> +    str   r5, [r0]
>> +    mcr   CP32(r0, DCIMVAC) /* Invalidate cache for max_mpu_regions addr */
>> +
>>       /* x0: region sel */
>>       mov   r0, #0
>>       /* Xen text section. */
>> @@ -83,6 +87,27 @@ FUNC(enable_boot_cpu_mm)
>>       prepare_xen_region r0, r1, r2, r3, r4, r5, attr_prbar=REGION_DEVICE_PRBAR, attr_prlar=REGION_DEVICE_PRLAR
>>   #endif
>>   
>> +zero_mpu:
>> +    /* Reset remaining MPU regions */
>> +    cmp   r0, r5
>> +    beq   out_zero_mpu
>> +    mov   r1, #0
>> +    mov   r2, #1
>> +    prepare_xen_region r0, r1, r2, r3, r4, r5, attr_prlar=REGION_DISABLED_PRLAR
>> +    b     zero_mpu
>> +
>> +out_zero_mpu:
>> +    /* Invalidate data cache for MPU data structures */
>> +    mov r4, lr
>> +    mov_w r0, xen_mpumap_mask
>> +    mov r1, #XEN_MPUMAP_MASK_sizeof
>> +    bl __invalidate_dcache_area
>> +
>> +    ldr r0, =xen_mpumap
>> +    mov r1, #XEN_MPUMAP_sizeof
>> +    bl __invalidate_dcache_area
>> +    mov lr, r4
>> +
>>       b    enable_mpu
>>   END(enable_boot_cpu_mm)
>>   
>> diff --git a/xen/arch/arm/include/asm/mpu/regions.inc b/xen/arch/arm/include/asm/mpu/regions.inc
>> index 6b8c233e6c..631b0b2b86 100644
>> --- a/xen/arch/arm/include/asm/mpu/regions.inc
>> +++ b/xen/arch/arm/include/asm/mpu/regions.inc
>> @@ -24,7 +24,7 @@
>>   #define XEN_MPUMAP_ENTRY_SHIFT  0x3     /* 8 byte structure */
>>   
>>   .macro store_pair reg1, reg2, dst
>> -    .word 0xe7f000f0                    /* unimplemented */
>> +    stm \dst, {\reg1, \reg2}  /* reg2 should be a higher register than reg1 */
> Didn't we agree not to use STM (I suggested it but then Julien pointed out that
> it's use in macro might not be the best)?

Ah my last response was not sent.

I realized that I cannot use strd due to the following error

Error: first transfer register must be even -- `strd r3,r4,[r1]'

So,  I am using stm with the following comment

stm \dst, {\reg1, \reg2}  /* reg2 should be a higher register than reg1 */

- Ayan

>
> ~Michal
>


From xen-devel-bounces@lists.xenproject.org Mon Jun 09 08:38:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jun 2025 08:38:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010146.1388282 (Exim 4.92)
	(envelope-from )
	id 1uOY1k-0000or-OJ; Mon, 09 Jun 2025 08:38:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010146.1388282; Mon, 09 Jun 2025 08:38: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 1uOY1k-0000ok-JP; Mon, 09 Jun 2025 08:38:44 +0000
Received: by outflank-mailman (input) for mailman id 1010146;
 Mon, 09 Jun 2025 08:38: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 1uOY1j-0000oe-Oj
 for xen-devel@lists.xenproject.org; Mon, 09 Jun 2025 08:38:44 +0000
Received: from DB3PR0202CU003.outbound.protection.outlook.com
 (mail-northeuropeazlp170100001.outbound.protection.outlook.com
 [2a01:111:f403:c200::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 227ac615-450d-11f0-b894-0df219b8e170;
 Mon, 09 Jun 2025 10:38:36 +0200 (CEST)
Received: from AS4PR10CA0030.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:5d8::11)
 by DU0PR08MB9749.eurprd08.prod.outlook.com (2603:10a6:10:447::5) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8813.21; Mon, 9 Jun
 2025 08:38:33 +0000
Received: from AMS0EPF000001B4.eurprd05.prod.outlook.com
 (2603:10a6:20b:5d8:cafe::ad) by AS4PR10CA0030.outlook.office365.com
 (2603:10a6:20b:5d8::11) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.35 via Frontend Transport; Mon,
 9 Jun 2025 08:38:33 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 AMS0EPF000001B4.mail.protection.outlook.com (10.167.16.168) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.15
 via Frontend Transport; Mon, 9 Jun 2025 08:38:33 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com (2603:10a6:5:1c::25) by
 DU0PR08MB7437.eurprd08.prod.outlook.com (2603:10a6:10:354::16) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8813.21; Mon, 9 Jun 2025 08:37:58 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668]) by DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668%2]) with mapi id 15.20.8813.024; Mon, 9 Jun 2025
 08:37: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: 227ac615-450d-11f0-b894-0df219b8e170
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=ypm1DFotUmNI3WNXSqra9LTl4EfQGfwmNkaqK9GXXl5P+Dh9OWgGlVAhZgNYtqWPPiZjLjKsUXOFfNgWoB+QO8kBgAY5ICRKjjwnM7iFa2VlYDpcc2G5uT92h1XjAI40iiSQI/PJ+Vg3P6TiO3AYR8c2Ln6yRsYTWiBwmyOSUo3/BATXkptNnb0oJTpqvT+Wrwyyh1HECrLzJfJ+cBqcI8BecIAurh3UeljODBohWvySFSRRe7r3VwhmYYll+VHrJul+6u3fgfjSeY2k9xqkdgQNt/rOkuUEsqZ0dplAy1k+1NmD7nFuU68tESQM2fBYp8PDCTUfscx9lTPb/rpU8A==
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=bSv3WluM2C0ZHzKojUv6lJqxvK8XihoWm2roduIx/qA=;
 b=rqKOswlKZNnsoQsWUXJpv/fI8jqStKEkTTiqe8k4VWdyRQ9CehNaIBvDQANRIf41/dBwZdx1Nt2uTq4O44WyMfyJA+6ilcZp57nS0yptZcpjejXbH4pzDSUbpv44A1KIYnSBWtnst738oLL/rdqYrcOxehHDtUiPV6qs/GKMYc0pf+aJJWoyhH7H6aNEMRUg14UQaUNjG+QnfmnYopocAE8KdDGpaUFmo8GDrtdvaVua/Yy7QHuCC5HdgYb5N/3G5Qj2L+IdUAeenD9PtMu5n9q16aZT7u/LNWyN/n5TfmIsVl9InAbtJfugoxajV6Ac8zVOQZvhL+HjVM/z4K7Cnw==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=amd.com smtp.mailfrom=arm.com; dmarc=pass
 (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
 (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=bSv3WluM2C0ZHzKojUv6lJqxvK8XihoWm2roduIx/qA=;
 b=ppbClE5pcbFQcskR1dUGGSjdOWGHurTxjI9vSf3AXQN9css24HuRQJ3pzN+y4ijWumkmin2rxXpcLX540amUrMw/31Gc7V14W140C0AwdI1dIcGQFLXPA2JXeXQ61o0gd5I5RVBqdFxqjsEs37lh0YBZ6qU2MpuxmaSJ/GmppwQ=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=SHyZQ+XFAck4MORuj2rzZfOjlcCvf0pya2PWUYI0tVhaVpik7QNZUWlWQ5XX3hfmztqrlyTps6MMQPXaXZUErlQyEB2GVQ79WpX/9qXwC/xahqyglwoBaWP+zI1EPx+ke/+5gh9DMI2grzjN0UbEo6+zAU1AGbf6k4Roy0vDb946HrPUR4v+Wjt77BcaLfSlipjs1mb/0unmecEObEaTE1O4FBVak4UHVIOJdl3gCPZhcG/OigaW1Xn+8N0IroNN7Rt9u0W72AzD23tr47pjBujCo/dzmYixOJn+hIBPtvKb8OTTgnFQoP6JHkrzVaYGNggxnn7dyWJhB9HPqm+uAQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=bSv3WluM2C0ZHzKojUv6lJqxvK8XihoWm2roduIx/qA=;
 b=bS0yRkgbZPspa0ASaEZrXtaS5Xc0HLPrhEjlG9kPq59WRhxvQVmL4Dq2KqE9fqlYRajy3sbEM1MmMLfwJdyKBtXUmG87O5ZmOXc5H655u3jN9s5lw7IRolEaN0DvE3jY7iRm/zJozl0uqP+8rrpnagrNBf0TgR9FRsNOQ+QR5fzlshOAADio9Nh/L6fg92j/Leb8eZKWEOap4WMVILQW5LopXu1n5t7+9+P7ss78SyFGf6aMse/8RhWplbvmtVz24ylXUelEYo2XKKrBDeIXUuEDPHDzGdRtE5YSW5BIl3TsEfBqLA3ektpml3T0VHwHrxjTf1EB0AncW4BAzQD4Kw==
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=bSv3WluM2C0ZHzKojUv6lJqxvK8XihoWm2roduIx/qA=;
 b=ppbClE5pcbFQcskR1dUGGSjdOWGHurTxjI9vSf3AXQN9css24HuRQJ3pzN+y4ijWumkmin2rxXpcLX540amUrMw/31Gc7V14W140C0AwdI1dIcGQFLXPA2JXeXQ61o0gd5I5RVBqdFxqjsEs37lh0YBZ6qU2MpuxmaSJ/GmppwQ=
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 3/3] arm/mpu: Provide access to the MPU region from the
 C code
Thread-Topic: [PATCH v2 3/3] arm/mpu: Provide access to the MPU region from
 the C code
Thread-Index: AQHb1wMFgqp5jCI+gEaPA46nKsooErP6hW+A
Date: Mon, 9 Jun 2025 08:37:57 +0000
Message-ID: 
References: <20250606164854.1551148-1-ayan.kumar.halder@amd.com>
 <20250606164854.1551148-4-ayan.kumar.halder@amd.com>
In-Reply-To: <20250606164854.1551148-4-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.600.51.1.1)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB7PR08MB2987:EE_|DU0PR08MB7437:EE_|AMS0EPF000001B4:EE_|DU0PR08MB9749:EE_
X-MS-Office365-Filtering-Correlation-Id: a1e73f13-0c7d-498b-97c1-08dda73104bd
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:
 =?us-ascii?Q?3J7bHATidvyvcbRveQNf7GuSEv1zI4mBWFhDUieHSGWNtugWnlE3s7A9EJq0?=
 =?us-ascii?Q?Df3xzaI8nwTgn+2+/AcmisRygtZdEO0bW7urW8FcjMfKaU71Tt6gT8P1pbi+?=
 =?us-ascii?Q?0EMjkmOVzKVPecGD3bH2ggSUfvyvxXAZOyVCQA1XkDwA58++k6eGr9zrnZz7?=
 =?us-ascii?Q?HzKETabb3KoW98ySvRYzDGhwA49rbyTL6jlAUBTw+UsTmt0dECW65D3l7yHY?=
 =?us-ascii?Q?sH/VnKpUpseJQBHyg5OqOaTPkua+66ztht07MLMUiUpPMzasv9HsXAqer6c2?=
 =?us-ascii?Q?hxuxz3XqkwhxyVH+GmtqzXPN1yuYCcwAvmyQFjXgqnRgaAszjj9LZQriT+Jb?=
 =?us-ascii?Q?FrDL97h4mbwja2aGfi1VZfhe1cptP5W53CjdrzJ1fOhNQJlRGuRfpa710JcU?=
 =?us-ascii?Q?79ux7MZjHcOpAGCHg9ZExTbIhcm2Bh0B+AhKOZleN7GEN8jqFjqiVodUb1iH?=
 =?us-ascii?Q?HHU6IRl5ieYaPDwxD1mpAPZixcUmdjXuNG/oq17PU/9yTNoDT7c5e2JyJCTT?=
 =?us-ascii?Q?uV1qkaO1a4kuTXGT8nNsSuGMxeWr37WjYSdG0UHd7eSLZt1rT8zLUirexTLo?=
 =?us-ascii?Q?4l+A5ckU1haaLsS948Id1NjF5WvHKpf1BstyWrSPwuF4GGlokSobsz4HHjS1?=
 =?us-ascii?Q?QVDf8F0hKrPjZnYIUIhpkAUK+EWCN0HhPISv8VI08P6x8V5L0FTGNPMVgNjN?=
 =?us-ascii?Q?/QMN1T1Ujh3Hoy5+t/ofiXs5kc1uirK3FvkPJvjC5ZPYiMJy055hM9xCkNfM?=
 =?us-ascii?Q?zr/GOOBb/1LXEBV2F1eRE5+TTm4f8ixqcXPtK81sbmyMM8YT5CQzM+HkmbPs?=
 =?us-ascii?Q?mmTUeLY0RoxTWE9p8j+uMOVmEq/7qZGMKA4jtB12PRcriZVpc8oZsyicwaLI?=
 =?us-ascii?Q?26gJce8Eojld50DBrRb5fSJ5CWP0fF2f8JI9/d1WBLezEYaXV6n4YzOfGHL4?=
 =?us-ascii?Q?HWctfMhUoYw2AUWTMhiqUfF5jUmcZBqYE+g+FNIIA58rqlbiTUGDvs3c7DeK?=
 =?us-ascii?Q?7ACpTgi529UC0jeC3FO2W/qL4Lc/QZX6Fa8+fEz8deI94bhbqfrL5m1XmKF7?=
 =?us-ascii?Q?0PU6loRSDcZCx37/mxEwkI1frxgQcxXFDEqeIG40X2Al9o8nPMbXh0m2Qbol?=
 =?us-ascii?Q?Um1Hhc5XnKsrB3kdrcCjKB2RS4U6ImybtmsI4ze6ARd9LStxNTN58crmGSo1?=
 =?us-ascii?Q?QAc0/EDPLrZhWNtKw2z1Me0r/T7kMhDQImDfd9jn3XptiCyyKajPQzNcBVyB?=
 =?us-ascii?Q?IHWOsnpcjFHv0hG1jaoq0IyG+EYy8o2a+yUk6DuGMmpAH8t0NrNt4GPL2BIJ?=
 =?us-ascii?Q?PrvsbiJuNRQ9fRIU0E1GdClGMnUzldb/Hreg5iNHAThZI/zJDjO2N5dejUbt?=
 =?us-ascii?Q?Nf7hqJJomS6b/ln8UYpdQDjTCSthfsoLfmyy7b82wgenRo5909xQ4oVAz2+Y?=
 =?us-ascii?Q?D9tJoK66OVnTz29FkyJ5vBTBlzFj1S20EocHJqECv4zqF2Bh/+rAaw=3D=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB7PR08MB2987.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(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: DU0PR08MB7437
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AMS0EPF000001B4.eurprd05.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	64f56e70-87dc-4aec-45e7-08dda730efc0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|376014|35042699022|14060799003|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?UVLYV8W7/yINuxr2Xw0vuiH1Js/Fv5u7dveyeyr4JV+r14McAh5ihkGybGrV?=
 =?us-ascii?Q?HHd3/mM3ouYvjbsLtz8/m+Asp3hFwoaKhFwpD86r2YBeBR7rPrl/wulN2M5z?=
 =?us-ascii?Q?mEJcnaV0W3knft6DMw8F4ZAFf/lGuiPFecnfKtZeS/2MbPH9VdPxrXTo4XKA?=
 =?us-ascii?Q?nitZxZIr4tMDgYbuS3a+uNqqzs3lrJbkf5pP0EhPaAcGtyYOsooRMF7urDmv?=
 =?us-ascii?Q?fEZ8CrMxciWMvDtw6UXA+KRWFajU+Kl+H56nYYGisCN9gZprdyXtjs2A1FcS?=
 =?us-ascii?Q?2k4ioHNrBPKtCcMCDpq+6w+x/3RWprzYIXkgiko0F+QC8774VGK6n2Uzymx4?=
 =?us-ascii?Q?0niVnFmSFO2KDlPY5JjvAG87ka9RMhCvu+iuIDljN0LDruJGQ+qcfJo0oncT?=
 =?us-ascii?Q?1PEvXmFlRNVeHuolhuhuvbjtjOkP1THoRc3gi0TtftipeqklTeYoz/WnlEP7?=
 =?us-ascii?Q?yk9ZDvUlDrCKJ7HKSRc5rKBmkTbsBxSBc8R7cHZ5ugsa5Mwq376XMeBAzHh3?=
 =?us-ascii?Q?u5Jvq1Z5ZPhBZUEwG3kgzrm6op1f44EegchK061dcZo0ois1AlFWnWeEj5YM?=
 =?us-ascii?Q?LecxgsI0p6zI7/XNHW5MP8RtlOM3bxg+DCZ4tlt7lRXhE2siqfb9L7dOAYit?=
 =?us-ascii?Q?1yc2vniAUDjJL4zekD/1tfb/PjtNApExIdmgEBG4p8Znc8C1VVj41p18OUmm?=
 =?us-ascii?Q?zW2asqQmIHaJopCOVkTapf1xoA8IJw439dq+5mxpXgW86QfBc5XhbLn5KmTq?=
 =?us-ascii?Q?ld/MyIrp+TTdhUD440K4ztYeHR9FOC+yKpga7jnQV171sUsGBac0UZHhot/4?=
 =?us-ascii?Q?q68MHpL/TtDKyc9qqveyXWODYQjVv/T5WKjkvEPv9IElLnH2qObuMvD2saua?=
 =?us-ascii?Q?ozOaUhwQXrV2VZDwddH88/zSf5q/ArZ6Nzbgzq6h3V5tRjZeR1b7xxl9vlyZ?=
 =?us-ascii?Q?HObjdJ8m+xUKTPSl4CVu6maqLoLHmDtveg+YXD1GDwMaVssIXo2eGwK2DhH0?=
 =?us-ascii?Q?27n59Pon5OKO3zcmk1fuPiYlPiYmY9fYD0ItiujzVAgKfllEyTsUV5k3QkTR?=
 =?us-ascii?Q?ObG58zVClaSWoZR2fGnuoYIhk1mT+mtooX/2fLCusRYpYRSwZCFj2GWe7J8Q?=
 =?us-ascii?Q?avG8e0/n4elwArCTr6SLDbLIsO7bwr2EfAzPygJ+mUOqeDd/E3jem/pujly4?=
 =?us-ascii?Q?udoWEuk7/Ez/LmgoDTQ70dSNu4PoHC/rHCJ2ycN5wIvg1CluRMC2uik6N0fD?=
 =?us-ascii?Q?luVaG0U3WhlBGGxXRH38evcWP6cFxJesKCg8zV8STqTQKMtstXA7ZEG+tWV2?=
 =?us-ascii?Q?aJouw9oS4XikehX8LUMk6LWOAI+bsjXloPFjncIMjBnBeQhsznOwmaPfhTbA?=
 =?us-ascii?Q?avwIPM+cJou93JPEp4JqeTJDDEzyhoJ2WFAquxI8CQ7kqZgHMIkpSgjgGdnD?=
 =?us-ascii?Q?q01h32h/+KhS9wWNrMW4HWa+0sy2dGM1tgmivDCfF/CUTBb86H8kUfQVhcPL?=
 =?us-ascii?Q?wgE7NrGseInTsGLI6dKlSRfd87ii9YOfa8Ji?=
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(376014)(35042699022)(14060799003)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jun 2025 08:38:33.0365
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: a1e73f13-0c7d-498b-97c1-08dda73104bd
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com]
X-MS-Exchange-CrossTenant-AuthSource:
	AMS0EPF000001B4.eurprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB9749

Hi Ayan,

If I understand correctly Armv8-R AArch32 supports up to 255 regions, so I =
would expect ...

> /*
>  * Armv8-R supports direct access and indirect access to the MPU regions =
through
>  * registers:
> @@ -85,6 +87,7 @@ static void __init __maybe_unused build_assertions(void=
)
>  */
> static void prepare_selector(uint8_t *sel)
> {
> +#ifdef CONFIG_ARM_64
>     uint8_t cur_sel =3D *sel;
>=20
>     /*
> @@ -98,7 +101,8 @@ static void prepare_selector(uint8_t *sel)
>         WRITE_SYSREG(cur_sel, PRSELR_EL2);
>         isb();
>     }
> -    *sel &=3D 0xFU;
> +    *sel =3D *sel & 0xFU;
> +#endif

something here to check if the selector is 0-31 or not and:

- set the selector to 0 if set is 0-31
- set the selector to 32-255 if sel > 32

And ...


> }
>=20
> void read_protection_region(pr_t *pr_read, uint8_t sel)
> @@ -123,6 +127,24 @@ void read_protection_region(pr_t *pr_read, uint8_t s=
el)
>         GENERATE_READ_PR_REG_CASE(13, pr_read);
>         GENERATE_READ_PR_REG_CASE(14, pr_read);
>         GENERATE_READ_PR_REG_CASE(15, pr_read);
> +#ifdef CONFIG_ARM_32
> +        GENERATE_READ_PR_REG_CASE(16, pr_read);
> +        GENERATE_READ_PR_REG_CASE(17, pr_read);
> +        GENERATE_READ_PR_REG_CASE(18, pr_read);
> +        GENERATE_READ_PR_REG_CASE(19, pr_read);
> +        GENERATE_READ_PR_REG_CASE(20, pr_read);
> +        GENERATE_READ_PR_REG_CASE(21, pr_read);
> +        GENERATE_READ_PR_REG_CASE(22, pr_read);
> +        GENERATE_READ_PR_REG_CASE(23, pr_read);
> +        GENERATE_READ_PR_REG_CASE(24, pr_read);
> +        GENERATE_READ_PR_REG_CASE(25, pr_read);
> +        GENERATE_READ_PR_REG_CASE(26, pr_read);
> +        GENERATE_READ_PR_REG_CASE(27, pr_read);
> +        GENERATE_READ_PR_REG_CASE(28, pr_read);
> +        GENERATE_READ_PR_REG_CASE(29, pr_read);
> +        GENERATE_READ_PR_REG_CASE(30, pr_read);
> +        GENERATE_READ_PR_REG_CASE(31, pr_read);
> +#endif
>     default:

have something here for Arm32 to access the regions 32-255


>         BUG(); /* Can't happen */
>         break;
> @@ -151,6 +173,24 @@ void write_protection_region(const pr_t *pr_write, u=
int8_t sel)
>         GENERATE_WRITE_PR_REG_CASE(13, pr_write);
>         GENERATE_WRITE_PR_REG_CASE(14, pr_write);
>         GENERATE_WRITE_PR_REG_CASE(15, pr_write);
> +#ifdef CONFIG_ARM_32
> +        GENERATE_WRITE_PR_REG_CASE(16, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(17, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(18, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(19, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(20, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(21, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(22, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(23, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(24, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(25, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(26, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(27, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(28, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(29, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(30, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(31, pr_write);
> +#endif
>     default:

also here have something for Arm32 to access the regions 32-255

>         BUG(); /* Can't happen */
>         break;


Please let me know your thoughts.

Cheers,
Luca




From xen-devel-bounces@lists.xenproject.org Mon Jun 09 08:42:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jun 2025 08:42:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010156.1388290 (Exim 4.92)
	(envelope-from )
	id 1uOY5g-0002V6-98; Mon, 09 Jun 2025 08:42:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010156.1388290; Mon, 09 Jun 2025 08:42:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uOY5g-0002Uw-5t; Mon, 09 Jun 2025 08:42:48 +0000
Received: by outflank-mailman (input) for mailman id 1010156;
 Mon, 09 Jun 2025 08:42:46 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uOY5e-0002Uq-P8
 for xen-devel@lists.xenproject.org; Mon, 09 Jun 2025 08:42:46 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uOY5d-00ABHs-30;
 Mon, 09 Jun 2025 08:42:45 +0000
Received: from [2a02:8012:3a1:0:943c:2fd5:7003:a460]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uOY5e-005TRz-05;
 Mon, 09 Jun 2025 08:42: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" 
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=JcLmnWct7oMFe8GGl8/UqyWiVrtuYkMmtsSEb5AY9mY=; b=kLuvKlOPZ9tW0rjXPTXRsEZa5I
	Xhz5XvdRPT1Mck2/Jt0eGJ+k6E/+4TGvNYAvQNXW7Gj217CB5pP5e1TwNZAJnI01KqFFM12+mvhdB
	QEau2R3dKMvmNPBLTeo3MlAuIUGZDTJCfDhGpvONd5BSAhntvL2n2wA2e4iH07FA3IYA=;
Message-ID: 
Date: Mon, 9 Jun 2025 09:42:43 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/3] arm/mpu: Provide and populate MPU C data
 structures
Content-Language: en-GB
To: Ayan Kumar Halder , "Orzel, Michal"
 , Ayan Kumar Halder ,
 xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250606164854.1551148-1-ayan.kumar.halder@amd.com>
 <20250606164854.1551148-3-ayan.kumar.halder@amd.com>
 
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Ayan,

On 09/06/2025 09:27, Ayan Kumar Halder wrote:
> On 09/06/2025 08:41, Orzel, Michal wrote:
>>> diff --git a/xen/arch/arm/include/asm/mpu/regions.inc b/xen/arch/arm/ 
>>> include/asm/mpu/regions.inc
>>> index 6b8c233e6c..631b0b2b86 100644
>>> --- a/xen/arch/arm/include/asm/mpu/regions.inc
>>> +++ b/xen/arch/arm/include/asm/mpu/regions.inc
>>> @@ -24,7 +24,7 @@
>>>   #define XEN_MPUMAP_ENTRY_SHIFT  0x3     /* 8 byte structure */
>>>   .macro store_pair reg1, reg2, dst
>>> -    .word 0xe7f000f0                    /* unimplemented */
>>> +    stm \dst, {\reg1, \reg2}  /* reg2 should be a higher register 
>>> than reg1 */
>> Didn't we agree not to use STM (I suggested it but then Julien pointed 
>> out that
>> it's use in macro might not be the best)?
> 
> Ah my last response was not sent.
> 
> I realized that I cannot use strd due to the following error
> 
> Error: first transfer register must be even -- `strd r3,r4,[r1]'

Ah I missed the "even" part when reading the specification. However, we 
control the set of registers, so we can't we follow the restriction? 
This would be better...

> 
> So,  I am using stm with the following comment

... than a comment and hoping the developper/reviewer will notice it 
(the code is also misplaced). I am ready to bet this will likely cause 
some problem in the future.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Mon Jun 09 08:57:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jun 2025 08:57:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010161.1388301 (Exim 4.92)
	(envelope-from )
	id 1uOYKE-0004EO-Fl; Mon, 09 Jun 2025 08:57:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010161.1388301; Mon, 09 Jun 2025 08:57: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 1uOYKE-0004EH-CH; Mon, 09 Jun 2025 08:57:50 +0000
Received: by outflank-mailman (input) for mailman id 1010161;
 Mon, 09 Jun 2025 08:57: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 1uOYKC-0004EB-Qo
 for xen-devel@lists.xenproject.org; Mon, 09 Jun 2025 08:57:49 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20629.outbound.protection.outlook.com
 [2a01:111:f403:2418::629])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cdbb8926-450f-11f0-b894-0df219b8e170;
 Mon, 09 Jun 2025 10:57:42 +0200 (CEST)
Received: from PH7P220CA0176.NAMP220.PROD.OUTLOOK.COM (2603:10b6:510:33b::29)
 by DM4PR12MB6493.namprd12.prod.outlook.com (2603:10b6:8:b6::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Mon, 9 Jun
 2025 08:57:33 +0000
Received: from SJ1PEPF000026C4.namprd04.prod.outlook.com
 (2603:10b6:510:33b:cafe::4) by PH7P220CA0176.outlook.office365.com
 (2603:10b6:510:33b::29) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.35 via Frontend Transport; Mon,
 9 Jun 2025 08:57:32 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ1PEPF000026C4.mail.protection.outlook.com (10.167.244.101) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Mon, 9 Jun 2025 08:57:32 +0000
Received: from localhost (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, 9 Jun
 2025 03:57:29 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cdbb8926-450f-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ldCkX0qDcKSazz/64T+VlRh2oxAZ8jYyEG8QaUJnkiTUM9/shUiI+mycW8keryyGpUFoI0aR/nj0U6DLo1sFXWu7L5bcgWU5KceSOCq3nDHKAYdVd1dROuClpipEMSuzo2IQcnnH77nSGx4ZuSHPFHCSdv+GNmTrxnerulwu6tFO9rpwGGzOCSdj4Gw3nxjM/BzNA/nRMiRoIqtD9sordXeqe88uP/8uh1XsgGVMq7wIAxlz4U3m6oPVcpei9/LScUEvWanTPDNQt0zAfXkmHDcY/IV9q7yUZygC9gbO3auEx3XiJTdd+NziE3S9DH0gJGZtUB73gm4QI5FLaVZv0g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=//rOgV1lkZ3K+GPF2ikpI2nbOZsOTAvgIfp/KleYHoA=;
 b=Qh2tj/dprvbBByHXoOJk/WJh3zmU32718ktp1ywrGrFJQbKimffBWZPYI4DNsjKpcpAUlo3bER4EMSmznzQHYGY3WZ6/6uQZapgI3gX86Dli4QFaCgSuA9WlIwEDrFUkpz15X8iErgW8tv+vQl/J1/ShlVrRQFX9n9UTjn7b9YuyV8AS4SL3mHmjoJbzlNnhiEAM4pekeVH2oIpAHdvSyI6LvuoaNzzK4u/Bl/Ej8go77pgBNsB5sGTp/ZsDFsZhn3o9DuetnvO2ZQdWl3aU7ENr82+RmMqr3V2lRyjpNtcGWG9w7puE8BT79X1QrEodDw8Uun1YQjlVOtzaBeWpaA==
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=//rOgV1lkZ3K+GPF2ikpI2nbOZsOTAvgIfp/KleYHoA=;
 b=QkjzDF3A9Vj37krYXfmyUFSVB6P2iTW7A5PLpkYVa3PrLCGoebDTkH6mGuxUuA4KuPdHUUWzcllw60EOareSA5GLxjxaamteBGZ4cMGBZMyD/ZcW90kaXlkfiVaeaNvxr/xv2WaC3nlSb+ltp//SGmwqOqJTXN0sFXXkNY/m1zk=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 9 Jun 2025 10:57:27 +0200
Message-ID: 
From: Alejandro Vallejo 
To: Stefano Stabellini 
CC: , Jan Beulich , "Andrew
 Cooper" , =?utf-8?q?Roger_Pau_Monn=C3=A9?=
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Daniel P.
 Smith" 
Subject: Re: [PATCH v2 07/15] x86: Replace boot_domain with bootdomain
X-Mailer: aerc 0.20.1
References: <20250605194810.2782031-1-agarciav@amd.com>
 <20250605194810.2782031-8-agarciav@amd.com>
 
In-Reply-To: 
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: SJ1PEPF000026C4:EE_|DM4PR12MB6493:EE_
X-MS-Office365-Filtering-Correlation-Id: 2f24e586-fda7-41ce-d658-08dda733ac02
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?L2N4bzdNSFZBVHNvdW1tU1l2V25nYkxDN21JOFQ3NmZqT2g0M1FacnZORVV6?=
 =?utf-8?B?RHhDc2hTcmF1SjA2aTdYeVRoSmFieGpyL3htK2hmejVzN0laTXQwZXp6L1l2?=
 =?utf-8?B?dk5vSzc2UE94V016Y2E0QWNUWEZKYjk1V0tNWWZWcjFJZzRKSVliNHdod3N2?=
 =?utf-8?B?R3F4R3EvK3A5NDZLbTYyaUZBQ2pzY01YdnpGSzlWazRQTUZnVFkxQWZvakZX?=
 =?utf-8?B?czdpaTFHWDJBVFFkY05hN3Q1N1U4Mkx0dDhkNTNpbVEzaFFwTmYyU2Y0MkNp?=
 =?utf-8?B?a3hydjdlQms5YmlpRUkreTdmTkNQWDdENksvZ1NyM2orRGNRTkdqS2tOMkxv?=
 =?utf-8?B?WUVBT3M0MWVqQ0o5WXFmQXdUd3hIK2Q1cXVnbW1kTE41TU9CMmhIVTRvYTI1?=
 =?utf-8?B?MXQ5b2NSMGhWd2pEUlkwekNvY05VZ3o3YmFWMlNIc0hHaEZlOWQ4K3FSNFpr?=
 =?utf-8?B?TzI4YmR6eEdha2FyWjNUU1VhRlhKU2Erbk1tdE02V1JhMVJ5SzB6MmVSMm9u?=
 =?utf-8?B?bDBmK3JUbmxoTzI3a0tEUE1sUmU2T0RqcXZ2bHR6clUvbHNUajE2RzNqczlK?=
 =?utf-8?B?R05DV2J4QXk4M2xvWXpJYXFBeXRsYzN1aTllOGl1WW5FNk14S25FanlHZXpC?=
 =?utf-8?B?dGtndmh3bXpNcWdBMnk2Qktpd0pKQjNJV1gyRzVYZ1dZanNJRmtVbmRCYUx3?=
 =?utf-8?B?UDlHclVGYjRzV2NBcE4xQ2Q1ZkRuUVhrVVpyb3JpUG5sN3pLTnVQZXVrK2FW?=
 =?utf-8?B?cnNvSE1yZjVrcnE5SUJsQklwSjVGcGtXRkR3aXZDUTd6VnhUemhKcUo3N3gv?=
 =?utf-8?B?MjVyN3BtbjZaNlRPV3BJVWJYc0hqU0pXYlZNNUN2UmdXTEVoY1JqUVdMN1Qw?=
 =?utf-8?B?c2pST2hVU2JPS3FDZ0ZUd0FNRDdwTmpBK1VUVVA2N2Y5NHhQWDF5SmxzS0RF?=
 =?utf-8?B?V2t0bHlEZEEzTU5vN2RyL3d5Z1JCSUVSd1dBOG9zai9xc3U4WVo5YmFhN2I1?=
 =?utf-8?B?cGpsU0M2b2pUTFV0cGZDN0cxSTIzWmhDVnEwdVNFL0dIaG4wdVlhSzJGRE9t?=
 =?utf-8?B?cEwxNmNkWU5XcXowbkMzTVNuSXRYb1hGeWE4NW5rVGdvcnhSeDZXdTh4ekQ4?=
 =?utf-8?B?Si9UT0RlTzdpM1lNVmV4c1V6OVFNbHhBL1JCVlZBRmh6MEdCSVVEeExqK2RU?=
 =?utf-8?B?R2FyMkY4Y1d5clhVZW1hMFNVUmVmVGVHY3RQZ1lLYnBCZTgzUnNTQVR0cWNp?=
 =?utf-8?B?aG9zVVdZbHVEd3FjT2FKdzdjbFZFalFBMGpGVzFSMG1yUnJaQ1FvYnlNYTJQ?=
 =?utf-8?B?cTZPQlJKV0dqY1FoWEJ1MnJCSytLVjlMbDJqQnkvTS9KZ0hlcVRjSTd0UW5q?=
 =?utf-8?B?YmRqRmo3N3VZTWhUT0t6ZStwelZ3b1FHY3FRRjRwV0pwYk5SeWxOVUNpcWt5?=
 =?utf-8?B?blBiSGdOdTJJV1VGMG13NTRlR2xFRXRYVWhkVG11aXBJVko2RFlDTnp5Z20r?=
 =?utf-8?B?TVNQK0pLdytKNU9OZ3h6eFEyNkhHeVNWcWlHeVVtTjlUN2VvM3hzdkp1Slh3?=
 =?utf-8?B?N1pRNXJ2VXRicjV3cHFXKzNyaXVncjRucVlENzVrczlaY3QwTzJqZXFxRnFU?=
 =?utf-8?B?c2xhb0Q3Z28vcEJFNXkwL2pnTlBCbzBhS2czUnBMV2szVEVnUEZOM1daOU1Y?=
 =?utf-8?B?SGRvV1oxRWptZUc1S1Z6c2xyaWgzVExvWDdMVlJiWWErcXhwYXc5UFJGMDNv?=
 =?utf-8?B?eUpYWDN0bllxRGFrV1o4Q2l2Wmx1WjI2SWJVQ0N5Y3d6M1dFdFZ0Rzl1WVdX?=
 =?utf-8?B?eTNYSG13SHpEZnZHdk00NDhZZlR3b0ZOd1B3WE4yczJXT255VWxaRFArVEli?=
 =?utf-8?B?UVB4Y1VlN3hCNXFZYmc0WkIzUkNMcHBSOE11RHFFeFR1SkVvMFVtcFM1VHgw?=
 =?utf-8?B?OTU0L1dEMHRldmpGamlsVUcxSm9LVnRaSDVnR3R4QVVvRnh4ZnQvb0JUVUU1?=
 =?utf-8?B?NStpdEcrVFg4dWZrMjdTbTE5Q1VNV1ZlblBWWTZiWFhvenhQTDI2TExBc1Js?=
 =?utf-8?Q?SERyml?=
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 Jun 2025 08:57:32.6236
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 2f24e586-fda7-41ce-d658-08dda733ac02
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:
	SJ1PEPF000026C4.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6493

On Sat Jun 7, 2025 at 1:28 AM CEST, Stefano Stabellini wrote:
> On Thu, 5 Jun 2025, Alejandro Vallejo wrote:
>> No functional change intended.
>>=20
>> Signed-off-by: Alejandro Vallejo 
>> ---
>> v2:
>>   * Replaces the previous patch in which kernel_info replaced boot_domai=
n
>> ---
>>  xen/arch/x86/dom0_build.c              |  2 +-
>>  xen/arch/x86/hvm/dom0_build.c          |  6 ++---
>>  xen/arch/x86/include/asm/boot-domain.h | 33 --------------------------
>>  xen/arch/x86/include/asm/bootfdt.h     |  7 ++++++
>>  xen/arch/x86/include/asm/bootinfo.h    |  3 +--
>>  xen/arch/x86/include/asm/dom0_build.h  |  6 ++---
>>  xen/arch/x86/include/asm/setup.h       |  4 ++--
>>  xen/arch/x86/pv/dom0_build.c           |  6 ++---
>>  xen/arch/x86/setup.c                   | 16 +++++++------
>>  xen/include/xen/bootfdt.h              |  4 ++++
>>  10 files changed, 33 insertions(+), 54 deletions(-)
>>  delete mode 100644 xen/arch/x86/include/asm/boot-domain.h
>>=20
>> diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
>> index 0b467fd4a4..1c8c5140a3 100644
>> --- a/xen/arch/x86/dom0_build.c
>> +++ b/xen/arch/x86/dom0_build.c
>> @@ -615,7 +615,7 @@ int __init dom0_setup_permissions(struct domain *d)
>>      return rc;
>>  }
>> =20
>> -int __init construct_dom0(const struct boot_domain *bd)
>> +int __init construct_dom0(const struct bootdomain *bd)
>>  {
>>      int rc;
>>      const struct domain *d =3D bd->d;
>> diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build=
.c
>> index 96410344a8..85c000b259 100644
>> --- a/xen/arch/x86/hvm/dom0_build.c
>> +++ b/xen/arch/x86/hvm/dom0_build.c
>> @@ -644,11 +644,11 @@ static bool __init check_and_adjust_load_address(
>>  }
>> =20
>>  static int __init pvh_load_kernel(
>> -    const struct boot_domain *bd, paddr_t *entry, paddr_t *start_info_a=
ddr)
>> +    const struct bootdomain *bd, paddr_t *entry, paddr_t *start_info_ad=
dr)
>>  {
>>      struct domain *d =3D bd->d;
>>      struct bootmodule *image =3D bd->kernel;
>> -    struct bootmodule *initrd =3D bd->module;
>> +    struct bootmodule *initrd =3D bd->initrd;
>>      void *image_base =3D bootstrap_map_bm(image);
>>      void *image_start =3D image_base + image->arch.headroom;
>>      unsigned long image_len =3D image->size;
>> @@ -1329,7 +1329,7 @@ static void __hwdom_init pvh_setup_mmcfg(struct do=
main *d)
>>      }
>>  }
>> =20
>> -int __init dom0_construct_pvh(const struct boot_domain *bd)
>> +int __init dom0_construct_pvh(const struct bootdomain *bd)
>>  {
>>      paddr_t entry, start_info;
>>      struct domain *d =3D bd->d;
>> diff --git a/xen/arch/x86/include/asm/boot-domain.h b/xen/arch/x86/inclu=
de/asm/boot-domain.h
>> deleted file mode 100644
>> index 242e9c9c2b..0000000000
>> --- a/xen/arch/x86/include/asm/boot-domain.h
>> +++ /dev/null
>> @@ -1,33 +0,0 @@
>> -/* 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__
>> -
>> -#include 
>> -
>> -struct boot_domain {
>> -    domid_t domid;
>> -
>> -    struct bootmodule *kernel;
>> -    struct bootmodule *module;
>> -    const char *cmdline;
>> -
>> -    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/bootfdt.h b/xen/arch/x86/include/a=
sm/bootfdt.h
>> index 2fc705a1cd..b30132381e 100644
>> --- a/xen/arch/x86/include/asm/bootfdt.h
>> +++ b/xen/arch/x86/include/asm/bootfdt.h
>> @@ -4,6 +4,13 @@
>> =20
>>  #include 
>> =20
>> +#include 
>> +
>> +struct arch_bootdomain
>> +{
>> +    domid_t domid;
>> +};
>> +
>>  struct arch_bootmodule
>>  {
>>      /*
>> diff --git a/xen/arch/x86/include/asm/bootinfo.h b/xen/arch/x86/include/=
asm/bootinfo.h
>> index f3210b7d6a..b8280ba357 100644
>> --- a/xen/arch/x86/include/asm/bootinfo.h
>> +++ b/xen/arch/x86/include/asm/bootinfo.h
>> @@ -12,7 +12,6 @@
>>  #include 
>>  #include 
>>  #include 
>> -#include 
>> =20
>>  /* Max number of boot modules a bootloader can provide in addition to X=
en */
>>  #define MAX_NR_BOOTMODS 63
>> @@ -34,7 +33,7 @@ struct boot_info {
>> =20
>>      unsigned int nr_modules;
>>      struct bootmodule mods[MAX_NR_BOOTMODS + 1];
>> -    struct boot_domain domains[MAX_NR_BOOTDOMS];
>> +    struct bootdomain  domains[MAX_NR_BOOTDOMS];
>>  };
>> =20
>>  /*
>> diff --git a/xen/arch/x86/include/asm/dom0_build.h b/xen/arch/x86/includ=
e/asm/dom0_build.h
>> index ff021c24af..df03189870 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);
>> =20
>> -struct boot_domain;
>> -int dom0_construct_pv(const struct boot_domain *bd);
>> -int dom0_construct_pvh(const struct boot_domain *bd);
>> +struct bootdomain;
>> +int dom0_construct_pv(const struct bootdomain *bd);
>> +int dom0_construct_pvh(const struct bootdomain *bd);
>> =20
>>  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 c7deaba109..a8647f0fdf 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);
>> =20
>>  void init_IRQ(void);
>> =20
>> -struct boot_domain;
>> -int construct_dom0(const struct boot_domain *bd);
>> +struct bootdomain;
>> +int construct_dom0(const struct bootdomain *bd);
>> =20
>>  void setup_io_bitmap(struct domain *d);
>> =20
>> diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
>> index e6c77413f5..a6f212fe0a 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;
>>  }
>> =20
>> -static int __init dom0_construct(const struct boot_domain *bd)
>> +static int __init dom0_construct(const struct bootdomain *bd)
>>  {
>>      unsigned int i;
>>      int rc, order, machine;
>> @@ -375,7 +375,7 @@ static int __init dom0_construct(const struct boot_d=
omain *bd)
>>      struct vcpu *v =3D d->vcpu[0];
>> =20
>>      struct bootmodule *image =3D bd->kernel;
>> -    struct bootmodule *initrd =3D bd->module;
>> +    struct bootmodule *initrd =3D bd->initrd;
>>      void *image_base;
>>      unsigned long image_len;
>>      void *image_start;
>> @@ -1070,7 +1070,7 @@ out:
>>      return rc;
>>  }
>> =20
>> -int __init dom0_construct_pv(const struct boot_domain *bd)
>> +int __init dom0_construct_pv(const struct bootdomain *bd)
>>  {
>>      unsigned long cr4 =3D read_cr4();
>>      int rc;
>> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
>> index e9a70c2c2b..726adad0e5 100644
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -297,7 +297,9 @@ static const char *cmdline_cook(const char *p, const=
 char *loader_name);
>>  struct boot_info __initdata xen_boot_info =3D {
>>      .loader =3D "unknown",
>>      .cmdline =3D "",
>> -    .domains =3D { [0 ... MAX_NR_BOOTDOMS - 1] =3D { .domid =3D DOMID_I=
NVALID } },
>> +    .domains =3D { [0 ... MAX_NR_BOOTDOMS - 1] =3D {
>> +        .arch.domid =3D DOMID_INVALID
>> +    }},
>>      /*
>>       * There's a MAX_NR_BOOTMODS-th entry in the array. It's not off by=
 one.
>>       *
>> @@ -987,7 +989,7 @@ static unsigned int __init copy_bios_e820(struct e82=
0entry *map, unsigned int li
>>  }
>> =20
>>  static size_t __init domain_cmdline_size(const struct boot_info *bi,
>> -                                         const struct boot_domain *bd)
>> +                                         const struct bootdomain *bd)
>>  {
>>      size_t s =3D bi->kextra ? strlen(bi->kextra) : 0;
>>      const struct arch_bootmodule *abm =3D &bd->kernel->arch;
>> @@ -1022,7 +1024,7 @@ static struct domain *__init create_dom0(struct bo=
ot_info *bi)
>>              .misc_flags =3D opt_dom0_msr_relaxed ? XEN_X86_MSR_RELAXED =
: 0,
>>          },
>>      };
>> -    struct boot_domain *bd =3D &bi->domains[0];
>> +    struct bootdomain *bd =3D &bi->domains[0];
>>      struct domain *d;
>> =20
>>      if ( opt_dom0_pvh )
>> @@ -1039,11 +1041,11 @@ static struct domain *__init create_dom0(struct =
boot_info *bi)
>>          dom0_cfg.flags |=3D XEN_DOMCTL_CDF_iommu;
>> =20
>>      /* Create initial domain.  Not d0 for pvshim. */
>> -    bd->domid =3D get_initial_domain_id();
>> -    d =3D domain_create(bd->domid, &dom0_cfg,
>> +    bd->arch.domid =3D get_initial_domain_id();
>> +    d =3D domain_create(bd->arch.domid, &dom0_cfg,
>>                        pv_shim ? 0 : CDF_privileged | CDF_hardware);
>>      if ( IS_ERR(d) )
>> -        panic("Error creating d%u: %ld\n", bd->domid, PTR_ERR(d));
>> +        panic("Error creating d%u: %ld\n", bd->arch.domid, PTR_ERR(d));
>> =20
>>      init_dom0_cpuid_policy(d);
>> =20
>> @@ -2162,7 +2164,7 @@ void asmlinkage __init noreturn __start_xen(void)
>>      if ( initrdidx < MAX_NR_BOOTMODS )
>>      {
>>          bi->mods[initrdidx].kind =3D BOOTMOD_RAMDISK;
>> -        bi->domains[0].module =3D &bi->mods[initrdidx];
>> +        bi->domains[0].initrd =3D &bi->mods[initrdidx];
>>          if ( first_boot_module_index(bi, BOOTMOD_UNKNOWN) < MAX_NR_BOOT=
MODS )
>>              printk(XENLOG_WARNING
>>                     "Multiple initrd candidates, picking module #%u\n",
>> diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
>> index e6d52a599f..19d2ff0f0c 100644
>> --- a/xen/include/xen/bootfdt.h
>> +++ b/xen/include/xen/bootfdt.h
>> @@ -108,6 +108,10 @@ struct bootdomain {
>>      struct bootmodule *initrd;
>> =20
>>      const char* cmdline;
>> +
>> +#if __has_include()
>> +    struct arch_bootdomain arch;
>> +#endif
>>  };
>
> One suggestion for improvement:

That would function today, but that field is important later on when we
retrieve the domid from the DTB. That's where it's stored until we create t=
hem.

>
> diff --git a/xen/arch/x86/include/asm/bootfdt.h b/xen/arch/x86/include/as=
m/bootfdt.h
> index b30132381e..892a0e2373 100644
> --- a/xen/arch/x86/include/asm/bootfdt.h
> +++ b/xen/arch/x86/include/asm/bootfdt.h
> @@ -6,11 +6,6 @@
> =20
>  #include 
> =20
> -struct arch_bootdomain
> -{
> -    domid_t domid;
> -};
> -
>  struct arch_bootmodule
>  {
>      /*
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index 726adad0e5..39f294b88b 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -297,9 +297,6 @@ static const char *cmdline_cook(const char *p, const =
char *loader_name);
>  struct boot_info __initdata xen_boot_info =3D {
>      .loader =3D "unknown",
>      .cmdline =3D "",
> -    .domains =3D { [0 ... MAX_NR_BOOTDOMS - 1] =3D {
> -        .arch.domid =3D DOMID_INVALID
> -    }},
>      /*
>       * There's a MAX_NR_BOOTMODS-th entry in the array. It's not off by =
one.
>       *
> @@ -1026,6 +1023,7 @@ static struct domain *__init create_dom0(struct boo=
t_info *bi)
>      };
>      struct bootdomain *bd =3D &bi->domains[0];
>      struct domain *d;
> +    domid_t domid;
> =20
>      if ( opt_dom0_pvh )
>      {
> @@ -1041,11 +1039,11 @@ static struct domain *__init create_dom0(struct b=
oot_info *bi)
>          dom0_cfg.flags |=3D XEN_DOMCTL_CDF_iommu;
> =20
>      /* Create initial domain.  Not d0 for pvshim. */
> -    bd->arch.domid =3D get_initial_domain_id();
> -    d =3D domain_create(bd->arch.domid, &dom0_cfg,
> +    domid =3D get_initial_domain_id();
> +    d =3D domain_create(domid, &dom0_cfg,
>                        pv_shim ? 0 : CDF_privileged | CDF_hardware);
>      if ( IS_ERR(d) )
> -        panic("Error creating d%u: %ld\n", bd->arch.domid, PTR_ERR(d));
> +        panic("Error creating d%u: %ld\n", domid, PTR_ERR(d));
> =20
>      init_dom0_cpuid_policy(d);
> =20
> diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
> index 19d2ff0f0c..e6d52a599f 100644
> --- a/xen/include/xen/bootfdt.h
> +++ b/xen/include/xen/bootfdt.h
> @@ -108,10 +108,6 @@ struct bootdomain {
>      struct bootmodule *initrd;
> =20
>      const char* cmdline;
> -
> -#if __has_include()
> -    struct arch_bootdomain arch;
> -#endif
>  };
> =20
>  /*

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Mon Jun 09 08:59:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jun 2025 08:59:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010167.1388311 (Exim 4.92)
	(envelope-from )
	id 1uOYLg-0004jC-PD; Mon, 09 Jun 2025 08:59:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010167.1388311; Mon, 09 Jun 2025 08: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 1uOYLg-0004j5-MH; Mon, 09 Jun 2025 08:59:20 +0000
Received: by outflank-mailman (input) for mailman id 1010167;
 Mon, 09 Jun 2025 08: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 1uOYLf-0004iv-C0
 for xen-devel@lists.xenproject.org; Mon, 09 Jun 2025 08:59:19 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20603.outbound.protection.outlook.com
 [2a01:111:f403:200a::603])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 050a61f7-4510-11f0-b894-0df219b8e170;
 Mon, 09 Jun 2025 10:59:17 +0200 (CEST)
Received: from PH8P223CA0012.NAMP223.PROD.OUTLOOK.COM (2603:10b6:510:2db::17)
 by SJ2PR12MB8181.namprd12.prod.outlook.com (2603:10b6:a03:4f6::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.40; Mon, 9 Jun
 2025 08:59:12 +0000
Received: from SJ1PEPF000026C5.namprd04.prod.outlook.com
 (2603:10b6:510:2db:cafe::11) by PH8P223CA0012.outlook.office365.com
 (2603:10b6:510:2db::17) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.35 via Frontend Transport; Mon,
 9 Jun 2025 08:59:12 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ1PEPF000026C5.mail.protection.outlook.com (10.167.244.102) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Mon, 9 Jun 2025 08:59:12 +0000
Received: from localhost (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, 9 Jun
 2025 03:59:09 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 050a61f7-4510-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=uLIY4K6tmvvkPfXnEA4Qvfah2KNxnqfUksN9JV9eXyLqxbmQwvfjWHr4n5JAZFbKEZwA5/e0wJNqJ/3TzyscoZ151mzUF2dJjg0HiplGQan8GggsuPBxJRuc7Yk7BiqaMuSw8bS/+CrwSg6BrnsIqmePEpvCv6GpADO5qDxODYv1f2JjEOhaOwmg+DCszoM3iE+PbzyWbKQGZ487zBCM2cwQjAIUds4+1xfWCLyYuKi/KmMMBTC1BjusoyAlsy8mMDFzVHsi4e+FdIlMJ600YJiibQfzyTGaH0T6hR0XhGWok6kbZhloZLYthBNO0+zJNADcXs0E4dkRZ0Cn7LuzgA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Kwg2NlTBP35hrmM41Wfoti+1rVU/0ScUPqHf0lNvWgY=;
 b=Ru5zOd8fPY7PricdW9z5BmFdHnLI8EksNSB6Pa3WXVvgwS60wtfLA9pnYK/ZgJPS8FLVUT8UYXgd21EWN0cd7/5eZvo0wdyDTECpb+0mWtypz9zDJIo/LTPt84F969Wc7Wy7X6NdfNCZL11znP9lvAyUbf0bs3FG0wKh7QpNe/9MNSCBY8ES2CHBWpZlw7p8qbJOQLRf1J5/qYq7g78YOL7HXhyRIEc9405wrDifF8YkpXhGL5ggcPBQJWdCs68t8KEj51plsEpEfzvueauGYmey1rVXmgd5ZMgkBCKlFoCRhnCLPd8iLfUbMYb15GEQq0Ful6X8lDTJc3VMzjjwbA==
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=Kwg2NlTBP35hrmM41Wfoti+1rVU/0ScUPqHf0lNvWgY=;
 b=16XLdnRqwPXpEgokoD4QtsTMQmBcgZk6Pzz178pDp6age+tLP0kM942jV2k7fLLgR8o/PB9kzYbBAVEsGc1NBd9lhnd8iAUpg0J/E642DZbOawElOr3ca2chzBZNZQeRiRxvJVqEk7xTXc2CasXEtiakeVAURj0EDJtpoIPrhO8=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 9 Jun 2025 10:59:06 +0200
Message-ID: 
CC: "Orzel, Michal" , ,
	Julien Grall , Bertrand Marquis ,
	Volodymyr Babchuk , "Daniel P. Smith"
	
Subject: Re: [PATCH v2 08/15] xen/dt: Move bootfdt functions to
 xen/bootfdt.h
From: Alejandro Vallejo 
To: Stefano Stabellini 
X-Mailer: aerc 0.20.1
References: <20250605194810.2782031-1-agarciav@amd.com>
 <20250605194810.2782031-9-agarciav@amd.com>
 <633ffa7f-cf26-4ec3-a153-28404c39d882@amd.com>
 
 
In-Reply-To: 
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: SJ1PEPF000026C5:EE_|SJ2PR12MB8181:EE_
X-MS-Office365-Filtering-Correlation-Id: ef0b8268-462f-452d-9468-08dda733e772
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?Rm85VGZ6QVhDazdjVHFmU3hSWGV6cDB6a3pGYUlDMFFXUVZvZEl5NTFBaFRz?=
 =?utf-8?B?MjVKZ3VEaWk5MFhRdEFJZzY2Y2Uyd2xqVEhLTDF0Z0NnQUtISWxNcElPR0pT?=
 =?utf-8?B?MnZuY0RHQUpoQWpxWEMzeVVMZTlWU0pGK1VoOHFWU1VwZ0ZLRHQvQjVianVK?=
 =?utf-8?B?NG9NenR6R2JCZWF4M1dCUjd4aVhsSWR1U09YVUZtSlgvUE4xYlZvV1hJL3dP?=
 =?utf-8?B?WjdVT3NwWExIUC9kMUZYZ1IrT1FaV0lOSGJLMnZ6YVdGMzUxRm9BNWgyUUVK?=
 =?utf-8?B?Rjc5TlVuMStoOUFnZ25lUlFobDVvQmVXRUlWQXRmSVFzaFRJTVRMRlhmQVdZ?=
 =?utf-8?B?NmMrRXVKb3hGeEFDc05pdWJ3aFNCclNhcmQ2bUZkSHF2cVVSZWUzNkdXNUpQ?=
 =?utf-8?B?VkI4YWJTNzRRRmxnRWJ3THZid0tvaDhpVWU1eTJyWUdVMjVGOWRuaWowMFhn?=
 =?utf-8?B?eFlMbzFETHVUSG9YTTVMLzBjbjZhRWVkVjdiZCt1Z2ltejZhL3UyNTRDeEw3?=
 =?utf-8?B?VEJwTUNXTnREak83NUlPd2RnZWl2WDh5MHh2QVVFRWY1YW5KaGJ5Z0d2VERv?=
 =?utf-8?B?WXMzNTJPZ3dWbm9YSzA5RTZMWGNwQnJSWjNmVFVvRi83c245bStlelRTUHo1?=
 =?utf-8?B?VlhsYU84cGNxVk1oMFlYdEVyQyt1MnJ4T2tOenFXL1ExU3R4cGRMTHkyRXla?=
 =?utf-8?B?VHhhUEZveWNuT0NwSnJXOFJYVDRMbUw0Z0NQbXVaWm5VZDVxMXdTazQrMk96?=
 =?utf-8?B?c0JKK091SWpwM1JwbitacUYrb3lvVDVlVlZkMk1PNmJYdjA2UVhTR0FNdERM?=
 =?utf-8?B?N2QwUU4vV0p1bGZhbVg1enRCa1FDb25abFI3OVVYRlJiRWlkM0J0SXExQk9w?=
 =?utf-8?B?aEpyK3YvYUU2LzBiRUo3ZDkrZ0NveFZUWnZ5ZDhScUtuZFlxSlNzTlJhTUZo?=
 =?utf-8?B?TjZRWmh1TUVVZklUaDBnemZUaWZpcjdKbHFYQ2VnYVBJMXZTRjU3ZUFmTURX?=
 =?utf-8?B?SDhaVUZqdzBUeVppU1g0cmJ5SmhDVDFNZFBITzlxeGwramV3STlLM1Zrb0pY?=
 =?utf-8?B?NTJ3OFZLbkFSeWlnRENWeU03YkVIQ2FpZ1hkbU5FeFNJOXlkT0hDakR5aUdJ?=
 =?utf-8?B?RHE5cnU5cmxmNkovU1pXcmNDVXdrUUluNlRLTHRlQ0pvb3p1b1hvN2pQbWVv?=
 =?utf-8?B?TGlxcElNL29Zb0MyU0tZT09taDFTSUJJWldSdmxPTGtpU0pjeUhzOXhVbEI2?=
 =?utf-8?B?OENSWUpKQ0F3Q2dwUnJpbys5VVo0dFVMd09JUmVwaWgyRU5nbWFFUDBIKyt3?=
 =?utf-8?B?S0RTUzdzaVhZZ0Zab1NnMnRJQmFJdXUxRGpqVDlYdmczWHZ3Um5jVHF5VGJ6?=
 =?utf-8?B?VEo3VGkrOFdpd0JkNU45UjlzN2JlQWVlekJ6Yjl6SjVyQ0x0NGR3YnNkWVJI?=
 =?utf-8?B?UFFvQW5US2FXSERLb3hTNTVVdFNlTm1CSTdrd24wOUMxMGRXbUU5dFNRbDJp?=
 =?utf-8?B?Y1pTL2pYaC9tMUhYMlc2SGh5V1ZsWTU4WlZEOHZVRFZMVTlzK1o0SFdqMlBV?=
 =?utf-8?B?MFg0YTcwblpuTTVZdk9DVEJpbVN1Wm5TRTZyem04ckpOMDhENFAxTU8wUWln?=
 =?utf-8?B?c3VYV0pkL3cxTjl6NFNzOGlwRjRmNFpVNGtXaTU4WlZQSS9JdE5YRTJwMlVN?=
 =?utf-8?B?Rkp4Vlh3YWE5cEtaUzVleW44bjV4M1V2ZEdINlVnVUZjVnZHQ0huTS9XWW5q?=
 =?utf-8?B?QTV3eEc5VUg4eGZteTVXUFBIYk10M0g2OWExSWtZV0dhaExKOEY0QWh2dGpl?=
 =?utf-8?B?MEhOcGJzSVlxOXM2RzdKT3RMK3doRS95dFdWNEd2RlQ1YnFSanlMS2xER0dv?=
 =?utf-8?B?RFV4SXVaZ0dUVFl0eWY4Z2RZbzgwMkZzYnFMMGd0S09BVWhSZnFZYTNkak94?=
 =?utf-8?B?c09YWXB3a05yOXhHM1M2Q1hMakN1VUtQcnlQUloyd3R5N1l4a1c5UllieUtE?=
 =?utf-8?B?V0RYdmo3S1NnVGsvZGY1a0kzQWVaZmJDSXZiL1FxZFExTzAra09nOU81eFYy?=
 =?utf-8?Q?IEEoFm?=
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: 09 Jun 2025 08:59:12.3433
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ef0b8268-462f-452d-9468-08dda733e772
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:
	SJ1PEPF000026C5.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB8181

On Fri Jun 6, 2025 at 9:59 PM CEST, Stefano Stabellini wrote:
> On Fri, 6 Jun 2025, Alejandro Vallejo wrote:
>> On Fri Jun 6, 2025 at 10:59 AM CEST, Michal Orzel wrote:
>> >
>> >
>> > On 05/06/2025 21:48, Alejandro Vallejo wrote:
>> >> Part of an unpicking process to extract bootfdt contents independent =
of bootinfo
>> >> to a separate file for x86 to take.
>> >>=20
>> >> Move functions required for early FDT parsing from device_tree.h and =
arm's
>> >> setup.h onto bootfdt.h
>> >>=20
>> >> Declaration motion only. Not a functional change.
>> >>=20
>> >> Signed-off-by: Alejandro Vallejo 
>> >> ---
>> >> v2:
>> >>   * Remove the u32 identifiers in the device_tree_get_u32() implement=
ation
>> > I don't understand the reasoning behind changing u32->uint32_t only fo=
r one
>> > function in this patch while leaving others unmodified. Also what abou=
t u64?
>> > Either don't change any or change all.
>>=20
>> Sure. Let's call the original u32->uint32_t change a misplaced mutation =
and
>> move on. The point is the motion, not these cleanups on top.
>
> Yes I agree. I know from past experience that Jan doesn't mind changes
> during code movements, but for me it is important that changes and code
> movement are separate. That is because I have almost automatic ways to
> check that code movement is correct if there are no changes. It saves me
> a lot of time during review. Then I can look at the individual changes
> separately.

That's interesting. Could you please share the runes? That's one side of
review I still struggle with.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Mon Jun 09 09:17:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jun 2025 09:17:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010177.1388321 (Exim 4.92)
	(envelope-from )
	id 1uOYck-0007hS-6z; Mon, 09 Jun 2025 09:16:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010177.1388321; Mon, 09 Jun 2025 09:16:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uOYck-0007hL-4D; Mon, 09 Jun 2025 09:16:58 +0000
Received: by outflank-mailman (input) for mailman id 1010177;
 Mon, 09 Jun 2025 09:16: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 1uOYcj-0007hF-FZ
 for xen-devel@lists.xenproject.org; Mon, 09 Jun 2025 09:16:57 +0000
Received: from AM0PR83CU005.outbound.protection.outlook.com
 (mail-westeuropeazlp170100001.outbound.protection.outlook.com
 [2a01:111:f403:c201::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7c60e150-4512-11f0-b894-0df219b8e170;
 Mon, 09 Jun 2025 11:16:54 +0200 (CEST)
Received: from PA7P264CA0230.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:372::6)
 by AS2PR08MB10295.eurprd08.prod.outlook.com (2603:10a6:20b:647::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8813.29; Mon, 9 Jun
 2025 09:16:49 +0000
Received: from AM2PEPF0001C709.eurprd05.prod.outlook.com
 (2603:10a6:102:372:cafe::27) by PA7P264CA0230.outlook.office365.com
 (2603:10a6:102:372::6) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.35 via Frontend Transport; Mon,
 9 Jun 2025 09:16:49 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 AM2PEPF0001C709.mail.protection.outlook.com (10.167.16.197) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.15
 via Frontend Transport; Mon, 9 Jun 2025 09:16:48 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com (2603:10a6:5:1c::25) by
 DU0PR08MB7464.eurprd08.prod.outlook.com (2603:10a6:10:357::21) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8813.24; Mon, 9 Jun 2025 09:16:16 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668]) by DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668%2]) with mapi id 15.20.8813.024; Mon, 9 Jun 2025
 09:16: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: 7c60e150-4512-11f0-b894-0df219b8e170
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=s1yszyKpz8vfsMN66RwDFL3ZuNz4SrKHtF6JmEOJ/tJsw6SgueJINKFvKwGAvgMMC/gRZ3vI+P+cRGHw6LKlMuxnHx4SFbB8YVTR3FWwreKQNvcueQCdIjw5/kQ52JngTaEje5eJSHUxFzxqFpXMlFraIH9RiiHCDP8IhjS94fUxCKW10bDTXVG/tpoqg8B0IHyGIdWlavTXvKZwD88yLrj18BmPOhqtjSfPrth75GVrb/LRVRykMKyf9nm9q0sXyEo0tKp4IuWvz6XhS6h1HQom2AJEALZe31flNF6sYQ50ffVKncgZ1u2U6ZgTLbAqCoDHPBj/KAHLluNSw2WXXA==
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=rqtYAZbExr7a/SRh+FO9mHhJg2my/N5wz5txP3vo9S4=;
 b=MDl6nrwxkPR7CxB/Xhcjvi9DV6SrdkJ1VmkWJzl4JeEnweAg64nSDY+YOCTXTWyelGF84tJ7akPu/nV9EKUFNx3YXwiex8amFmZ4LIOJ9M3GYQd//cZh4AVYNj+XYOk/Ck5XWw0ibteu4AF6ZHVk3kF2OL1S1allVDQmyTz9Z4e3bX1TV+9CFndOEnlkM4T6c14neFAOhV0nm1SscxiUyoYfUSiL2sDrwuYnjNxDJecysRA/86xUVGC8vzc+KtDG6G3aWVHa5s14xd/KCd84mmPQK0wOGWr3qcnoE9P9yFgmDhdMmsjxTk3/sTTOzibd0WN4SRi+Sdy8gVGI018Tag==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=amd.com smtp.mailfrom=arm.com; dmarc=pass
 (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
 (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=rqtYAZbExr7a/SRh+FO9mHhJg2my/N5wz5txP3vo9S4=;
 b=MYJb1gJuXQl6a4p7JMNxff3AhmVQVEsFFUrbCpDEK3jQZjJC+GI7Rjzqf/tHzrs8uaKAvFpXP3uz/dpwKvoqWY/7R+R87dJy2coWh92CJz6ENskcf4FEY8STmQFRxwnjiJplSSWCOvs2k6xqMBbBjJ1Ruwl9fMnpcV4aCSKXtdY=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=vRDtCMR2wOffvsZ08AKzjaKeHva/7HncbvbKGz0L0HQhuiprEkMxPg+crXsDgSsBatmryKNmWRBKzjUXnUETWGHMulBdjJan8LzQC8bz9T6+OUdTIBssWtvi6nPCUCGj5kDyydaS++gkIiTZlvN3Q9V35czbX+IryOgSfTkY9iqfBVpA/6vxhJJ/G7he67rtC4uzyZXl/WuMMiVchiSpR5UYMMGfT91/OuN7WwyhwyCkb6cR1grM+SfSbxLJ1LHwy1f7t3MkIemkztQ3Z3m+AsOSlqzgHr8PUhrjZ542FfMo1ZEibwygmE04+Gq3c3fPQidUKRZG93d4jcm4LqM4Rw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=rqtYAZbExr7a/SRh+FO9mHhJg2my/N5wz5txP3vo9S4=;
 b=OE1llSExb51uzC+FhYL9Z5U0+FMv3RvJxrqgFfuRm0IxuiRCICrahd21zfpnIdrD4qVV+LRb7AjL/D0E6csZDW0aa1aYUiWX7DJE7apSu3zt8GwWkhDs31t5a/LNIQ9Wbx/OeClXL3AUhM1AWlLhgAlss6SZ/P8dT4fVlZnln1x5cFgdxWIYKbpHjS9RugRQh7H2gc+7EeGl/dhBw0oqFQKHGm5epFSdYuPiBpQJLTvsTjy98fE2siIKah13tV63tTS6dKw/UviPwa0EPWgj1TGVFOxixLDdGRa8SybOGWdQ6DaQmjE0rw/jE7XGB0sSKNnAKi8pSzG+9o2nBP4sDA==
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=rqtYAZbExr7a/SRh+FO9mHhJg2my/N5wz5txP3vo9S4=;
 b=MYJb1gJuXQl6a4p7JMNxff3AhmVQVEsFFUrbCpDEK3jQZjJC+GI7Rjzqf/tHzrs8uaKAvFpXP3uz/dpwKvoqWY/7R+R87dJy2coWh92CJz6ENskcf4FEY8STmQFRxwnjiJplSSWCOvs2k6xqMBbBjJ1Ruwl9fMnpcV4aCSKXtdY=
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 3/3] arm/mpu: Provide access to the MPU region from the
 C code
Thread-Topic: [PATCH v2 3/3] arm/mpu: Provide access to the MPU region from
 the C code
Thread-Index: AQHb1wMFgqp5jCI+gEaPA46nKsooErP6hW+AgAAKtIA=
Date: Mon, 9 Jun 2025 09:16:15 +0000
Message-ID: 
References: <20250606164854.1551148-1-ayan.kumar.halder@amd.com>
 <20250606164854.1551148-4-ayan.kumar.halder@amd.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.600.51.1.1)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB7PR08MB2987:EE_|DU0PR08MB7464:EE_|AM2PEPF0001C709:EE_|AS2PR08MB10295:EE_
X-MS-Office365-Filtering-Correlation-Id: ec9d947d-0e10-40f7-3a6d-08dda7365d15
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:
 =?us-ascii?Q?U+HyPelVOUyegyiqr5D52hyTFvpTvDfl5vQGebRS5yiVZNNX5sfkH9zUrlYV?=
 =?us-ascii?Q?Al1U/ZUYw3pjHsiC8QJBCHfYerplKswEsC/R0iCMWuVdS/Mxmro+lHYPF8Mi?=
 =?us-ascii?Q?NuYeyowTTqeEkg2z62eSCExhVHcJoQ/vVAlz6y7+q0EtpK+bZcWYwWIbVVJ0?=
 =?us-ascii?Q?40+NftB7mxCSXhG1Zd5odlZ+52Yixkf9mrzu8MAQEA6U/S/8DNS/7+TohUDd?=
 =?us-ascii?Q?tSuKoGV955woCu+90LsxFp0QK9KlG3Q1fmFsfDSu20jCd+4iRFn2HYXSNZe0?=
 =?us-ascii?Q?dK5GqXiQyxG08BlML0nr617TtnzRdUL2hhPgzBS5ItroA11BAHvTotNQbm7/?=
 =?us-ascii?Q?dv1h5VUae1rrxuPaM9xtz8LZsxSEBqrSIRLaClz/Size6rbh3HO9JPhrC4KV?=
 =?us-ascii?Q?lEjwrjAcCiV6hQ8QyPs+ryNhip96KmtzKKwqhdPTExBy8PxrY62pVCCZuOUa?=
 =?us-ascii?Q?wl8iLDXqWfi4RCemIrlcWHOvOkfYkTCt890VBO93GSuUmCXYEEpcOhRLAOjW?=
 =?us-ascii?Q?FMuxpkOUHYba6WDFYNNPRBl3353gAuaAhVuap9bo15ylBqcqBO9fiAuQVs3s?=
 =?us-ascii?Q?zzwEK0/QflbXhwI2hW97Nma/9x62+ZqYe9m7678kq13yoDOh36tb6JLo6HCR?=
 =?us-ascii?Q?IoH8HREoZ7iUM/v+LH4BMbPvV2JbPE0ecLKVLo3h7rVBUug90mUtpRGTTgqw?=
 =?us-ascii?Q?4sq/4VLljX8S8LWXJ27X/Q8uJ3XL0CeeRk/q0Z1lbtnyRMg506nHMH0ocLQY?=
 =?us-ascii?Q?hy2YhYVpTyGhIwIgk05Hr6I048UFvPEFVYcAVgO1aCTNlCmmaq3KHz44zhi4?=
 =?us-ascii?Q?Gn9XuzUmfAjZpVO8onu6qIbGFRYAQVZl90Ip0pSpKiK50Rk2L2FQM5jvhCnB?=
 =?us-ascii?Q?ikrVgUAqseRh4nUHvkaVlTBEOBLVNiSGeNrqsT22xb0X7hB9WzBE2CUouR7B?=
 =?us-ascii?Q?XDfZWG4l1xkJMKXrov0L3mOgNF8wO5cp3GkWSvmvFCVjwEyWXT6ww6OEWZqs?=
 =?us-ascii?Q?JraHprit4/xFlMB9G0l7JTymIdtuExv+SWeaPrx+2Scsmgx7kj6JMH+T/uI8?=
 =?us-ascii?Q?Phumgsnr8MuyNYc/kgD8HOAVVMHMII1nc7Z8WMX/DzXWKkrTYwbzokQVN9/5?=
 =?us-ascii?Q?myXQZNHVttAgZ+xSzQx2gN7DZYj9COzeuvyN6Onv+Yi1rNNPXaRroGhpW0/s?=
 =?us-ascii?Q?Q96oBXcGDg72hD7cp+EOX3WFuJMj5aqKQtQOmgpUloE1UERXdsm2zNHFmM1d?=
 =?us-ascii?Q?QDnmhmAqJSY7NNAF1VQoeBM2cSQ/ow0S3P6j6tzkp8sz/c2ieNbfH8iCYa2Z?=
 =?us-ascii?Q?B+mV67rxy/bYHO+iII8PmGWqvVNFybhiWtt3Ur+M3db2Y29JIB55+7boeA/S?=
 =?us-ascii?Q?Bq4rAtogjs1zavfTAebAE/VLuzi+FRjIRbpUEf6MnJqxSulQOjaTskBNTpoU?=
 =?us-ascii?Q?nInfJHT8C+L/lgJmTyMSrKRsM2sKrzzBPRAqSmK18xtV/GRImo3AoQ=3D=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB7PR08MB2987.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(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: DU0PR08MB7464
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AM2PEPF0001C709.eurprd05.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	c9d5c719-b8b8-48cd-7bc5-08dda7364981
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|35042699022|82310400026|36860700013|1800799024|14060799003;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?H8cKyiMawnWM7N/5tVxeMeXkd4zyuPbJemDCaTJh6QFcXw85gNEvrx6GApAM?=
 =?us-ascii?Q?O+2GMvtmnxSL1Fk6ljLRAzu7YmxAfROGvZcisGl8Ke334atyaFFppKyAEOhg?=
 =?us-ascii?Q?gKhhzOTh6jq1ehHyix+wscmI1WEhv5r+Tm631cOUxwZ22+Sffwnvhdst20nK?=
 =?us-ascii?Q?AQnBl9C4X7FHQ9Wxi5Cncsy9XmLazBjz3ZQcvxwk1iHZT7DtSVqaa8i5zHBO?=
 =?us-ascii?Q?EkjeNvLRVLZ9grh78CdQrMSKTIpGb44vNBWp6UfAwGF3PlIMmTlPkOzdfkR6?=
 =?us-ascii?Q?TIJ61q3CdEV9kI2CtMedS89khJIt3nWZCnJu982bULJbaZZvOPi+F0StoSah?=
 =?us-ascii?Q?VHHByh8sqt7oYaVMve5lWbMlEzePf32Q0kbB5RBjD71LfPSNsfgHdgMTBVzz?=
 =?us-ascii?Q?IpLl6WbCdHt66MAGobDQ26LlUna+SUciMhcclxgE9u/jbISGYrtqgEUszbSJ?=
 =?us-ascii?Q?TPxLaZHOuVcmoKGswNQdao+svUP6LxpmRq3sjdRS8gvSgQAkCW7sEkZjiHFB?=
 =?us-ascii?Q?S2DB7dgCy7EQfwmlviPxF7LSP5uhWP8aAplwqu0yiksPwX938rEVHlWokTyV?=
 =?us-ascii?Q?yjVZ7I/bY8zi8INg7VoSKydP/aX0EaXeYOvEzskTfpWSiSWjwUF+yWTWiWXe?=
 =?us-ascii?Q?czyDG+94WC95i6jz7iG9JqHGcGcZ314y6XObg3D/nHSjDp1DFkJmmnaGauj1?=
 =?us-ascii?Q?c/mWfn2wyEPcLOMd9hskZa3M1Q2xiZYo57aO+5AJBLiIcoirEZFuca7b3FHr?=
 =?us-ascii?Q?3CjKnG4GlI7wlX2b0NTnRGJgCKn1UATbyf6l2s0FSoC7XUVlGbPSBPzd7kiB?=
 =?us-ascii?Q?aTYXHdo/cBctrQT8Z+LYMNJdDIYNd52qvvKzeWpoQ6yd3SK6X5OnvXSe5dZv?=
 =?us-ascii?Q?g0R8Y19vf90NrMA0e/k46N3n1my+flIpxPvma1qbaS5jXRAIITkhyHUvU2Sb?=
 =?us-ascii?Q?+Xsp29CBDF4jhyvUWjtQuWYvSySeL+iy+8mw97/HI5QP6g+x6KyCkqDi/Rin?=
 =?us-ascii?Q?1FPYxOisV75iL/1RzZgJrx6Q8KyYcCfY2tR/YyChmI2P8rq0rO9n91At6UUe?=
 =?us-ascii?Q?axTc2BqSFZCXgZcwGDOWzMuueruN3coNSfQg15mdIJ8lPZuP+dzQoIG4L3Xh?=
 =?us-ascii?Q?QlhDsQ6j7A3AJFDBkOAL1JCmnsrorWNmn/S6EWZzCcyXRJ0qgTBxlO4xaV/V?=
 =?us-ascii?Q?wMmSy6/2mwlTzCfhlieVUI4aScry/di2t5j5pHtRrG7tJEhsS45jJyZGx6p0?=
 =?us-ascii?Q?DQyHg5XMdyg71e+t5jPqy1ikuOTprJGCXWUnsdqpTeumOs2ERzZGvwzuX2dK?=
 =?us-ascii?Q?cJUYMicO6Z9gnJ6vzSvSgnkIZRTt+Pwe0I0WeeF10Zl3JU3mZZz2alz9Cvk2?=
 =?us-ascii?Q?jlVE+UWZW5B0s4OyNSZT+kGgT8fbwSD53oj8/Rsd0A9lwKNVAoph5qay1sEM?=
 =?us-ascii?Q?S4m9Xqg8lijD/LdIskkSjduAIk/AuPw6OXwNcBa1uaBWVofdZOZLlXSggr2n?=
 =?us-ascii?Q?jkkDAOxP+B8Peb9QDAqZulZF4pyitQfTrOmN?=
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(35042699022)(82310400026)(36860700013)(1800799024)(14060799003);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jun 2025 09:16:48.7336
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ec9d947d-0e10-40f7-3a6d-08dda7365d15
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com]
X-MS-Exchange-CrossTenant-AuthSource:
	AM2PEPF0001C709.eurprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR08MB10295

Oh sorry forgot one thing ...
>=20
>> /*
>> * Armv8-R supports direct access and indirect access to the MPU regions =
through
>> * registers:
>> @@ -85,6 +87,7 @@ static void __init __maybe_unused build_assertions(voi=
d)
>> */
>> static void prepare_selector(uint8_t *sel)
>> {
>> +#ifdef CONFIG_ARM_64
>>    uint8_t cur_sel =3D *sel;
>>=20
>>    /*
>> @@ -98,7 +101,8 @@ static void prepare_selector(uint8_t *sel)
>>        WRITE_SYSREG(cur_sel, PRSELR_EL2);
>>        isb();
>>    }
>> -    *sel &=3D 0xFU;
>> +    *sel =3D *sel & 0xFU;

this line is not part of this commit, maybe rebase clash?=20

Cheers,
Luca




From xen-devel-bounces@lists.xenproject.org Mon Jun 09 09:17:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jun 2025 09:17:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010178.1388331 (Exim 4.92)
	(envelope-from )
	id 1uOYcn-0007vG-Eo; Mon, 09 Jun 2025 09:17:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010178.1388331; Mon, 09 Jun 2025 09: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 1uOYcn-0007v8-B8; Mon, 09 Jun 2025 09:17:01 +0000
Received: by outflank-mailman (input) for mailman id 1010178;
 Mon, 09 Jun 2025 09:17: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 1uOYcm-0007hF-CX
 for xen-devel@lists.xenproject.org; Mon, 09 Jun 2025 09:17:00 +0000
Received: from NAM02-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam02on20611.outbound.protection.outlook.com
 [2a01:111:f403:2405::611])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7bef1e63-4512-11f0-b894-0df219b8e170;
 Mon, 09 Jun 2025 11:16:55 +0200 (CEST)
Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
 by SN7PR12MB7348.namprd12.prod.outlook.com (2603:10b6:806:29b::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.42; Mon, 9 Jun
 2025 09:16:51 +0000
Received: from PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264]) by PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264%2]) with mapi id 15.20.8792.035; Mon, 9 Jun 2025
 09:16: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: 7bef1e63-4512-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=PGqsXG/HUGFv5Y2N4sDF0OwEMjWEUfYmNCmVx2JVQsuikg0P9BJrTVdD0nUdb8sCEqoQd7E3in7hh+2kbutc7myw69GKLf8BGHys3cN/7XV9IVq7Fsmg/p2TRaRGrbLSxWyVLz7HRnqNI5ZvLrKrmciKpkM6LFJ+MtSStAbflEhXcATBeDC8TWV40V7yZ8yiBWiwARW0s46b/3XnURtfJCFLY3Z5765IWfeXy0SdkEaGIWPu+AyFwAouQNmgAHlnBNmr14K6L81Dv9qINgvXxr/Xe0NQZ5R5DxkplU2AHgeNYXsQRcSOXVZdPz0TGHaIC0m+gOBkf4H3BlmoZKibtA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Brup6HiEi6MvCymS0nURt6bPUnMSK4zX0JwNbDIjnig=;
 b=yJ4xBF9f7Io9ekHNUEikV7Y0mkWit0kxX/UgozBafCfXofLLjny6r+wsNlUAs4uN7SljTEgkb6YRi0N3qFMvRu31cb9qp/Zc9o/AGwrieh4KPGZdmnz6Y4j5aQptnTqpEst+tFrJmWIA9INTBPqoKGKSO6NEl+mKIO5+4zatowXnahAbRoQtuDY3G4acgs0Jzx9IKTMYUuCfi6UpiBxsgtQzNb+LcBjTvhAno/sDdx3CjHnxwHCM/VmZtb2qXmqxMLmDsMZS+VsTBjfCCxQU/xjTKWJtpP+bqCmJ0N/jtILDKAvEVTqAKP/Viqy53vI/YXyQz7Jg2REhUa1C4PzowQ==
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=Brup6HiEi6MvCymS0nURt6bPUnMSK4zX0JwNbDIjnig=;
 b=DodcbLOmvEK85MKNbfYhdiKDA5uFPBCyU6Afuc7pCf1V5x1WeShGHdjMJnHTGD2ubvCYAFVhmWtuTxUwxzztpggoQmOCS72owi1eC9LuZWheipoE55ueUW6yzBlulrq65bv6lDqWmYfVX1jKyXe86sJ4GKzvR1iNvLYaIa+ciUg=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Mon, 9 Jun 2025 10:16:47 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/3] arm/mpu: Provide and populate MPU C data
 structures
Content-Language: en-GB
To: Julien Grall , "Orzel, Michal" ,
 Ayan Kumar Halder , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250606164854.1551148-1-ayan.kumar.halder@amd.com>
 <20250606164854.1551148-3-ayan.kumar.halder@amd.com>
 
 
 
From: Ayan Kumar Halder 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P123CA0475.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:1a8::12) To PH8PR12MB7326.namprd12.prod.outlook.com
 (2603:10b6:510:216::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|SN7PR12MB7348:EE_
X-MS-Office365-Filtering-Correlation-Id: 8beb8657-8f34-493d-cfbe-08dda7365e5e
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?cEVKNE9QVzlvbHJnb2lWUGZEb1N1R3BSM1dyanUwaXlTN1NDdFQzTXB5cFA4?=
 =?utf-8?B?OVVpakFXTjJFMWlGdU5wNzRsZlJNcmVMQXN2NUVlYTJyck1HQVFXNE1vZytX?=
 =?utf-8?B?Z2tzSDZONHFJTGtjWU5KUkVXd1o0d1c1ZUlYTEdNMzFURGdyTE83bC9reUov?=
 =?utf-8?B?bm1iaWJQRXl1RHRyTDZqWGp1Zm5lbzlwaDFCbVZYWGFEcVQxUlZEQjlscVNz?=
 =?utf-8?B?ZWJEZTluTVVGandwYXZITGtLZmZvdkZvSUtXUzNnZHVtbm9Sb1dmSXFOaXFs?=
 =?utf-8?B?Z2ZUSStaSHEyL2h1eElRdDhqUWd2dmNSa09CVUdKTVlxV2YwT3Y5Mzd2aEUv?=
 =?utf-8?B?TFREeE91YXJlSUV3R0oxZ3NTZjl3ZnBlVVF2dENMNm1RcGhTVndmbWp0bG5S?=
 =?utf-8?B?VTVKZHp5MlA2bkRuSVdMOXlMMEltR0hOcEs0VTZTMTRJa1ZDR3pKQlRSbm9P?=
 =?utf-8?B?WFhKbjRwNzVRZkcwNUFjY21lNnNRQ2hnZVNBMnhpbW5FQ0ZPRmpBeXdCSjhN?=
 =?utf-8?B?Y1VkdUZheGJSUTd5dUR2MldCTXJFM2d2SU9GamVpVkFDVUFlOTE5WWwwRGV1?=
 =?utf-8?B?RnJQNHNwaFRlUXBKb0JxcklHK3pFd00rTC9Ld0wxNlhUaE5rcHNLenU0Z3A1?=
 =?utf-8?B?dGFkZ2lzYVo1WnlmN0Q0SzY1ODM0U0VBcTlNTzZpUGpVYk4zbFRrOG4rMU82?=
 =?utf-8?B?aFhHQXQ0UHY0cXpTWUwrbFlJc0VRQWxJeW9RZ1RZNmNIbElkOXhHTzNzbmtW?=
 =?utf-8?B?RFJ2RThjNWg3TkhuR01HQjROZ25JVWt0amhoL3lleGE5VkJHZ2d5TUhoL1pD?=
 =?utf-8?B?MDJjM082a1RsZml6cDZvQ3M5UlNYZGpCUnNLRm8rRWxoU0xQRXI1ZEt3VU9O?=
 =?utf-8?B?TzMvb21ZN0tpaTU4eDZiQ0xxdVBENmxwUEJraFlVTE9JTzFmd1E3WHE1YUl1?=
 =?utf-8?B?UHZJbElMaUFzSlJTQmRMeXhGbk4vMDl1LzZGOEdNd1RJeTFZNC9PWnNYWXJY?=
 =?utf-8?B?T1M0MUFZK1hUVWVnZGgxcmVxM1hRMDlkSEsxMDlYM25pQmFmMytFbmlyVXNu?=
 =?utf-8?B?TnRWZklkbmJ3ZkE5N0JZQWd1ZmxGaGduM21pcmwvckZvL1A0d1UzcTllV2c1?=
 =?utf-8?B?eVhPN1hOQWNqQUVRVmJubW1lRkgySWZnVjhoLzNDQXI0VHFyaENiNDFRdlRL?=
 =?utf-8?B?ODdWdm9CczEzM1pEaEVLNFllWHhmTXJva2hNbHY0cEVYY25HQ2ZtSFBUaTdm?=
 =?utf-8?B?ZnRzcUFXaW5YcFVxakZ1c0pqUTcyZlluSXdha0gvdVh4eUJtbUlLK0RSeXVS?=
 =?utf-8?B?WHhCZlFsTWpIUTM2R29wT1JvR1JOUWZ6ZkV0eFdhOHdjWWxNM2wydzhxYklw?=
 =?utf-8?B?UjJlRyt2ZXF6QmJha3VaL0ZnWStPTGUyMWx5ZUlMS2RaczQ4cHZrVkZCRmpx?=
 =?utf-8?B?WlI0aDM4NEt0MnQ1QXFmbzM1MlZycjJCcGt6VmxydVpxQUFvVyswM2wxR25R?=
 =?utf-8?B?cDlVODRFbEFGWUhZVHQxQlU2c0xjd2VkM1Y5ZHVLWUtZSmJQRzAwNVdrZURE?=
 =?utf-8?B?TjZwWUhxdzRuK2F0TmVtNGJRWGx3cGx1eGt5anNiTHJpV2dEbjZ6dEg3Sjht?=
 =?utf-8?B?VXpXQ1dBUkV5ejRTcVFha0tYOEk1MVVhYm52RTBQYTNRclk0OHY1a2YxTFJr?=
 =?utf-8?B?VFFRL2xtWmFPL0FEbVQvNDQreFJIY2Nha24waDhXcU05djZaNkprL3JjdHpZ?=
 =?utf-8?B?Q2RSUjV5L1p1aUMvU0NGZ3RRVENTVWZwMk1JSjgxYzRCRklmRll5TitTOHc3?=
 =?utf-8?B?VWZXdnEzZWl3UjR0bDlDeEZXYisrRU5HUFcwVWZDSE9qcmlTMDdxRXMxQ1ZM?=
 =?utf-8?B?Q2xueEZhY2xkbmpOdW9jVGRBSWJLeXFpK3cwc01aWEZhNXVuQXUwK2NGZWs0?=
 =?utf-8?Q?nJ1hFrgaSus=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?TTBVL2pSd3JEamM1SVJmd1JPZXNKdEFIOTZ3M2U1d3ErZ2hNQTdvRmJ3RkR2?=
 =?utf-8?B?ZWVOakhjUklyc2did2FXeHFqcVlja3BCWmlQVWVxb1E0Rkl0ZVBmempCRFor?=
 =?utf-8?B?blJHUlFOb2FEZnF6cjJDYWN5aDFGdDZEWWtjdkh3TGpicy9pVTcyM1FwTHFH?=
 =?utf-8?B?UnJaZGlaakl6VDh5TWlPRys2Y09oSDlvaDIxZENLeTJiTU12NEtFaXVXYSs2?=
 =?utf-8?B?NTF2dzVRRXNWY25WdUxLQjBpMTRyK1IwYkJhMThxVzRLNU9SYWlmamhwcTVi?=
 =?utf-8?B?Y3hIT1hzSm9lTnY2QjZKSW42dXVaNHYya1RNQklQZ0dQSlI4bFJodkRQNkNO?=
 =?utf-8?B?SkdMaFdJcjBoVDdrcWpoVzZMa3k3cm9FQ2lFcHpoMEN1b0xxZGpsWFpwc0NF?=
 =?utf-8?B?eS9xM0RUZE9WRU9nM2t4RXRLNXhPR1RjZ1RZa0xTcEprWndtdVVuZU50Q0Rr?=
 =?utf-8?B?QUZHR1Z1eWNMY0ovMXNhajFrc2NvbWRCaEJkNE1GdVl2eTV5MDVKVnk2Rmwv?=
 =?utf-8?B?ai9KUk43MjBqK3FHemNzZVU2RWprRkVVVkxCeHZTejJCbVcxZGp3RUxTcGF6?=
 =?utf-8?B?MWhRV3VwbzdIaXcyelhxTjduSHpncUtPT1ZSMHAxYnBjN3NGd2M4YXJnRWpZ?=
 =?utf-8?B?dGczQ1BEbGxSTVVEVWpzUjEyNlBuM0NTSUlZd3pqeDF3VTNxZTUzQjNhbjVo?=
 =?utf-8?B?M2ptcWxFK2FLYVArSGtzUDY5V21FbVorb1Q0djdtRVpOS3dEOWJSTFRJcnRT?=
 =?utf-8?B?cERjOS8yMWpWaTZOQ1ZMamFWeDRtVlhYcEJzM2RGQkhpNGpEcnRmeVBBd1RV?=
 =?utf-8?B?dWpEWnA4Y1dYdTk0WGxYQVY0Z2Y0T0F5SVFTMzRKU3p0MHNySWxFWTRRQ3Bk?=
 =?utf-8?B?N0ZNcGRkNGkwNmkxakM3QTc0RmhsOU05R1RYV0w1MjRjNFVkZElnVGZJK3Fw?=
 =?utf-8?B?MjJYdHlGdXlOOHpRSVVqcmJaTWp6OVc0SzVnL05nMnVYMEdoZjJ1dlFlWXVr?=
 =?utf-8?B?MWEzQ3lHdndVUTBhR1VybkFZb3ZEQy90OWREa2dOSjN1dlBhME5IUUFRQld0?=
 =?utf-8?B?VU90LzF5bysrdFZjeFc3LzdBeG9IQURmQjd1K0FRT002TVp5ZitEVmJxaUdp?=
 =?utf-8?B?MXM3M2hNTHdwWWl0TXpJcy8xNmlqb2xSMDA0RTB4SHVoNzlyTlgyQWNucUZh?=
 =?utf-8?B?MFJsQzV0RzZDNERiWSt5UHJKYzR2N3ZCUXpUWnNielNQcmhPREpMSjFWUlhh?=
 =?utf-8?B?NkxScnltV01YQ0p4dGVwLzViR244WU5rQWVGUTU3TzB1N1gyalhvaENwNmRv?=
 =?utf-8?B?RnNhYzZUOWRQZzA4WWoyYVJDRVgvS3JFS2tyaEJqY3l3bTdXNkxzYlJwSWox?=
 =?utf-8?B?R0M0ZStOckpCZkpYV2RrWTNtMDk3anQrZnZtVDhLS21NUEVzdmpBZkdBdkdV?=
 =?utf-8?B?NHFtUEM4djhMdEthWGc1Wi9icGcxKzJCZ1VnWkoxTzZ1TU5hQ3J4cm05Mmlk?=
 =?utf-8?B?dEZpdWlENFJwNnZBb3JuQWxzSVZ1YzdOUVlUTW1VcXd1dHZWdnY5VVlyRFQ1?=
 =?utf-8?B?bExCbHVrQzA1VXJNNjE0cUJ5OC9zS2lhSkhCRmxrRWh3SmxKWTEzcE1vZnlU?=
 =?utf-8?B?b3hjckI1cU95bmU3ZHZ6bldXR3RGZzM4YWV2eUR2MDVnQzJrTnhnN21ZcXBv?=
 =?utf-8?B?OFJVSVJZejQ3T0M5OEhIYTM4VU9WZXFsdWl3RVJteUNFOU9KbFZFSHF3S3ZY?=
 =?utf-8?B?OUlmVThHUnhPUzZoRjViTzF0cUI5d080aVlDOWc2WW9UQWh3SXhaV01sUSs1?=
 =?utf-8?B?ejQ0Q0NSd0dBWnA0TFdrSE9ZTWY1NUdTREJ3aTB6RlJoYy9VOVlYb1RMTnpt?=
 =?utf-8?B?a1dXS3ZKK213OEFBUFFxQzNGYi9RY05sNlh4T3pXNkFMK2tEc0RXRGpQSTZq?=
 =?utf-8?B?S3J6REFzcFZBZDMrU2NnMERkL3pMZTU0ODlPdW4zdFd1dC9jTWQrdWltTVgw?=
 =?utf-8?B?anBKWVYzUjRvYWJtODhreHpBSktrbGllamxlSnlMSUhMdHppRW5Jc2hCSTVw?=
 =?utf-8?B?NDBkc1hsWHJoSExieTJJK1hmaE45OHRIdDJDaUtWcm15VHp6TURUQi9ScEha?=
 =?utf-8?Q?SxKjoU2q9WD0z05ruL+uXH6DY?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8beb8657-8f34-493d-cfbe-08dda7365e5e
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jun 2025 09:16:51.2563
 (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: 8IWjdZ5z/58UE1BXvp5HxVYERDhezJt8SCz2pvBsnzvzEsm3K6Z2QZWgpwcCIHtyX2IWnBYLe6n/fphhzrB5qA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7348


On 09/06/2025 09:42, Julien Grall wrote:
> Hi Ayan,
Hi Julien,
>
> On 09/06/2025 09:27, Ayan Kumar Halder wrote:
>> On 09/06/2025 08:41, Orzel, Michal wrote:
>>>> diff --git a/xen/arch/arm/include/asm/mpu/regions.inc 
>>>> b/xen/arch/arm/ include/asm/mpu/regions.inc
>>>> index 6b8c233e6c..631b0b2b86 100644
>>>> --- a/xen/arch/arm/include/asm/mpu/regions.inc
>>>> +++ b/xen/arch/arm/include/asm/mpu/regions.inc
>>>> @@ -24,7 +24,7 @@
>>>>   #define XEN_MPUMAP_ENTRY_SHIFT  0x3     /* 8 byte structure */
>>>>   .macro store_pair reg1, reg2, dst
>>>> -    .word 0xe7f000f0                    /* unimplemented */
>>>> +    stm \dst, {\reg1, \reg2}  /* reg2 should be a higher register 
>>>> than reg1 */
>>> Didn't we agree not to use STM (I suggested it but then Julien 
>>> pointed out that
>>> it's use in macro might not be the best)?
>>
>> Ah my last response was not sent.
>>
>> I realized that I cannot use strd due to the following error
>>
>> Error: first transfer register must be even -- `strd r3,r4,[r1]'
>
> Ah I missed the "even" part when reading the specification. However, 
> we control the set of registers, so we can't we follow the 
> restriction? This would be better...

I am ok to follow this. I just want to make sure that this looks ok to you

prepare_xen_region() invokes store_pair(). They are in common header.

So we need to make the change wherever prepare_xen_region() is invoked 
from arm32/mpu/head.S. This would look like

--- a/xen/arch/arm/arm32/mpu/head.S
+++ b/xen/arch/arm/arm32/mpu/head.S
@@ -58,33 +58,33 @@ FUNC(enable_boot_cpu_mm)
      /* Xen text section. */
      mov_w   r1, _stext
      mov_w   r2, _etext
-    prepare_xen_region r0, r1, r2, r3, r4, r5, attr_prbar=REGION_TEXT_PRBAR
+    prepare_xen_region r0, r1, r2, r4, r3, r5, attr_prbar=REGION_TEXT_PRBAR

      /* Xen read-only data section. */
      mov_w   r1, _srodata
      mov_w   r2, _erodata
-    prepare_xen_region r0, r1, r2, r3, r4, r5, attr_prbar=REGION_RO_PRBAR
+    prepare_xen_region r0, r1, r2, r4, r3, r5, attr_prbar=REGION_RO_PRBAR

      /* Xen read-only after init and data section. (RW data) */
      mov_w   r1, __ro_after_init_start
      mov_w   r2, __init_begin
-    prepare_xen_region r0, r1, r2, r3, r4, r5
+    prepare_xen_region r0, r1, r2, r4, r3, r5

      /* Xen code section. */
      mov_w   r1, __init_begin
      mov_w   r2, __init_data_begin
-    prepare_xen_region r0, r1, r2, r3, r4, r5, attr_prbar=REGION_TEXT_PRBAR
+    prepare_xen_region r0, r1, r2, r4, r3, r5, attr_prbar=REGION_TEXT_PRBAR

      /* Xen data and BSS section. */
      mov_w   r1, __init_data_begin
      mov_w   r2, __bss_end
-    prepare_xen_region r0, r1, r2, r3, r4, r5
+    prepare_xen_region r0, r1, r2, r4, r3, r5

  #ifdef CONFIG_EARLY_PRINTK
      /* Xen early UART section. */
      mov_w   r1, CONFIG_EARLY_UART_BASE_ADDRESS
      mov_w   r2, (CONFIG_EARLY_UART_BASE_ADDRESS + CONFIG_EARLY_UART_SIZE)
-    prepare_xen_region r0, r1, r2, r3, r4, r5, 
attr_prbar=REGION_DEVICE_PRBAR, attr_prlar=REGION_DEVICE_PRLAR
+    prepare_xen_region r0, r1, r2, r4, r3, r5, 
attr_prbar=REGION_DEVICE_PRBAR, attr_prlar=REGION_DEVICE_PRLAR
  #endif

  zero_mpu:
@@ -93,7 +93,7 @@ zero_mpu:
      beq   out_zero_mpu
      mov   r1, #0
      mov   r2, #1
-    prepare_xen_region r0, r1, r2, r3, r4, r5, 
attr_prlar=REGION_DISABLED_PRLAR
+    prepare_xen_region r0, r1, r2, r4, r3, r5, 
attr_prlar=REGION_DISABLED_PRLAR

So this would look a different different from its arm64 counterpart.

Are you ok with this change ?

- Ayan

>
>>
>> So,  I am using stm with the following comment
>
> ... than a comment and hoping the developper/reviewer will notice it 
> (the code is also misplaced). I am ready to bet this will likely cause 
> some problem in the future.
>
> Cheers,
>


From xen-devel-bounces@lists.xenproject.org Mon Jun 09 09:26:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jun 2025 09:26:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010188.1388341 (Exim 4.92)
	(envelope-from )
	id 1uOYls-0001Tn-9C; Mon, 09 Jun 2025 09:26:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010188.1388341; Mon, 09 Jun 2025 09:26: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 1uOYls-0001Tg-6D; Mon, 09 Jun 2025 09:26:24 +0000
Received: by outflank-mailman (input) for mailman id 1010188;
 Mon, 09 Jun 2025 09:26:22 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uOYlq-0001Ta-Sl
 for xen-devel@lists.xenproject.org; Mon, 09 Jun 2025 09:26:22 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20608.outbound.protection.outlook.com
 [2a01:111:f403:200a::608])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ca77354c-4513-11f0-a304-13f23c93f187;
 Mon, 09 Jun 2025 11:26:16 +0200 (CEST)
Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
 by SN7PR12MB7348.namprd12.prod.outlook.com (2603:10b6:806:29b::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.42; Mon, 9 Jun
 2025 09:26: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%2]) with mapi id 15.20.8792.035; Mon, 9 Jun 2025
 09:26:12 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ca77354c-4513-11f0-a304-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=itZGYKydCxLsj91fsdbpDTaVnfvz2s3kAKFfcrg7ziNeq2xa8SQLrcveWNshroGKHNO3q3BrdVR8GTE37ql/Y+nz3KzyQd308i8uyMjCh6OUJprUKYuETklP/U5hiNH9YGsPciUX/4htoIDV6P03xgFzrJj3kwscVItqb/FumAKGgP4KMvWOphDuMpzsrt8bQUxxK2mnP9eCQYOvP4jrcHPQakp/HLZJZCJDzqwnrYvy/27J31I5hM1WLsl4PK/PPgc4Kmi2dU4WMKq0KkfQp1h0A7Lxkle09Eq1d/phStxiRMYYb3LtsoMzEflF2Pxrq55yEusghMKrZ92sKoGegw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=bV9V3ctW159g3ohB/uFFvqGu9vNhT1RlXvnJwzbTsho=;
 b=EIPSVLOxaGpriUplQHQBAnTRZQm/60pw2+NQp3SxqgGZz8CTtEzWOs/i7AqA+w/6BxdeVYr4bKT+JoodYTI7cpk543cnX2fO4jUHE9VChsUThcjYQHzBj+4nv8/9M/bummW0xQrigj4Tkt3aX/66NDNopJfTWqhk8Bd4ZkAOjTnZ5qCpAw3tbtmLbiSVk9LVsaRrZsbEG9doHHxzeihAsfXX/C3b+k4lyCpLo/xddu+TWGuBG3x2Djn7ARy1riqzs+9WB74vjr59zYQsvvhhyTUhikYk7qIuaPg7mWRiKSwp+M57G7w5Ak5ioSsN+kn+Vt5MFzPI0o8O28vZa+O1rg==
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=bV9V3ctW159g3ohB/uFFvqGu9vNhT1RlXvnJwzbTsho=;
 b=fRNTD3pJSOldhLNy8JrTbWomPTpOCzrJ53JwF/tiNnzHudVUBuAYVa/Gt7xSkcGL8Vso2GxLfvAnVdcdtnVx2QB1kQ3CInpH1FtZ4WIjmuwdLJitAYWii/bBL6Qv6WpeQ3VM6nqsdDiBHvbluyeAwY30CuAzVdRwfCdf6ROSw0o=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <56199c5f-77f8-4861-a09f-610dbcca8e7f@amd.com>
Date: Mon, 9 Jun 2025 10:26:08 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/3] arm/mpu: Provide access to the MPU region from the
 C code
Content-Language: en-GB
To: Luca Fancellu ,
 Ayan Kumar Halder 
Cc: "xen-devel@lists.xenproject.org" ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: <20250606164854.1551148-1-ayan.kumar.halder@amd.com>
 <20250606164854.1551148-4-ayan.kumar.halder@amd.com>
 
From: Ayan Kumar Halder 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LO2P265CA0029.GBRP265.PROD.OUTLOOK.COM
 (2603:10a6:600:61::17) To PH8PR12MB7326.namprd12.prod.outlook.com
 (2603:10b6:510:216::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|SN7PR12MB7348:EE_
X-MS-Office365-Filtering-Correlation-Id: a8566431-0e27-4815-b4cf-08dda737ace4
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?dzdYenlBQmNHTmhyUURzTlBydUhvRE9zR01wb3dDWW1LL2U0MWNaUnl0LzF3?=
 =?utf-8?B?NHYvR3NaOU5IeWVEbkZwcmZBK2NWbTBwSi96Vis3R2VCcVcxdE5KN2c5SVIz?=
 =?utf-8?B?RlA1UHpHVkF4VnZpSVJaT21BdXBXbmFGRU1OZm5hZUd5bTdLbEFUUU1XQmNX?=
 =?utf-8?B?WkFoZkx3T0NVckxhZmx5SEtBa2FsMGxNRjJsbCt1THg4WEp5ZGhtWVNRVWR2?=
 =?utf-8?B?YU1qYTRTbWREK3RmVlFkOHdTV2dlSjgyejZ5cDBONjJ0T3E0Z3FGSHFDUTI3?=
 =?utf-8?B?SUxyRkQ1dmMrcERXS240TnI1M2ZwS0hpV1p2ZDJmaXVQN05Zc1dLck45UXNh?=
 =?utf-8?B?VTBSKzlxbi90bjBYVXNEWHVEREJ2RnpNcm9vb05IejRXazg5ZlF6NEZYQ0Zr?=
 =?utf-8?B?bVR1Vmw2MFp2L1FWNUxaVUI4ZWtnY3ZwSTNhTzZubUNMcENOYnVQa0l1SnUz?=
 =?utf-8?B?ZDFFVU0yQStDUXp3anU3WVJJY3pBRlp6Sjl0QlNpTmZsS0JiUnhYOUNkaFJT?=
 =?utf-8?B?M21vRUhQWkhFcVVWZEpIR3FtQzRKL3ZCeHVuTGJPcTRCSHhXS2FKRURjZWRM?=
 =?utf-8?B?aG56OUdlcThzZ1BUOU1oZ1d3TXMrZmRNVHNLREJRcEtjNjZGMGRmcmRjY0tl?=
 =?utf-8?B?bDMxQkR5cTIwWmwydVdueWlKaWJyYUFBc2k5TjVoODNTTFBrRXIraDdBYnNx?=
 =?utf-8?B?a3lpZnNuNGFQWkQrRGVwTHhhWGo3Z3A3UUZoR0Z0ellxMlNVRmo1VklTTjRa?=
 =?utf-8?B?RHpWYkJhT0pqNDVyNE03WG9NYnpLdzdYWDVkQUkvWUdieHJKWHMzMzVZQzIv?=
 =?utf-8?B?emVRUHZvR3NrNlN2WEI5SDNNRk9CbTRZZVJTTVNRYTZDVjJWMTJmUjlGelhX?=
 =?utf-8?B?V1dQRndUK05vbEREamQxV1hWbDBlRFVIYmFOSUZnRzZUYjY2dC9zM3pDenFj?=
 =?utf-8?B?S3JyNkV1eElQLzVoMUFybURBelFKYzJSemsycnFTdGVWZkRUZlJhczEwUldB?=
 =?utf-8?B?VE0vanZWdHRmOGFnYlNxWkNTNXRVSWxvekgzbFNPUmYxUTdRa3R0akpta1VM?=
 =?utf-8?B?MHJySFlIcVZtbDdRZmwvOStDRUkvUmtXczBncnNKUzM1cTNlbThrcjVXUE5Y?=
 =?utf-8?B?eld6YVpXQVBKTUJCclExM0VrUGNVak5PdVJYR1Fvamh1U1ZpQVZueFpkWFhG?=
 =?utf-8?B?NFZTUEo2cyszc2RTN2pxeXNUTWxRazBqYnE3b1c4NnN0d29kR0RsN2x1Rkhy?=
 =?utf-8?B?UkxXcjIwN1hMMzEzYXJmS29SOGtVbVFhSmNoeDJWZVlyY3ZCY1ZVbWNXRW1V?=
 =?utf-8?B?Q00wajIxRWJ4NDZwbUFhK2JSUjE4VldBMi9yTXR6QWR3YWI2czgza2pmaTV3?=
 =?utf-8?B?OVZhZm5QQXZyMG1vNUF1dHEvSG5xNmhNUVBWdnFKNlJROW5aRnc2eUJtMWtO?=
 =?utf-8?B?bm50amFsZHUwUnNNSE5lUVVmNUlRTXorR1o3QUIzTFRpNThKZlVQTFFTa1Vl?=
 =?utf-8?B?QUh5Y045UVVidGpzcWxTV0o0S0lpN04zcy9sZEhpWHBRWnJyUUlUS2dqOWdr?=
 =?utf-8?B?dVdNSjBUc1BIRFNCSGtSZGJLeHBZaFhMT1ArYnZ4YTc3R1Z0VFJEejQrdERz?=
 =?utf-8?B?WkdFcUZSeHFKUk10dlJJcnJPaVoxQ1IxVmIrejZDRlZIdk5pMzhtZ0Y0dkVE?=
 =?utf-8?B?djRZaVA5WDBIOEhGR05Wd2s5V0R4M1prOTF4VUN2VzJCNnNMY21TanNOdmJW?=
 =?utf-8?B?OGpZeEZhdFlkL2Qxa0Z4R0UraEl0NlRVSkNkbk9UK2M3YkJWWXpNYk50Y1Va?=
 =?utf-8?B?UFEwaElIMGJNL2s0VG5rRDI4SFJ4aW9US2NWUE5PSys3L093R2tKbGRqb3Fi?=
 =?utf-8?B?Tmk3TWVuM2MxUWJ4VkJLMXBKNUdSM2M4Yi9DMlRoNG5nbjQ3ZnBZNEZlOWN4?=
 =?utf-8?Q?kfp6QLcUdN0=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?Q0p2R3E4d3VQOW9UcTVXOXNDWUZqMzg4OVBNOFEzaDVqYkpmS1djM3M2YXps?=
 =?utf-8?B?RTU4UVRaUys0ajFmaEd0YlBvcG5kZktrQmEzZkc2RHF4NjhvckxkN0tSb1Bt?=
 =?utf-8?B?YStvU0lrT0tpcngrNldoMFB1czA5Q2l1c1ljU0hMNmswWkMzQ3I5c2UrK1Vx?=
 =?utf-8?B?aVNOYlV0RFlINUYrd2syUjU3bm5RN01ZZVlXMWRzYzBETWhkQWVpZ20zQkwy?=
 =?utf-8?B?K3BPaGcycThJNERPSm4ydzExcFlPSFlUU2pMdUNVRVJTTGd4R0RUbGI3NDRt?=
 =?utf-8?B?RWJhdm1zamtrY1QvbDgzV1BoUmhXUnJ2Z09TKy9GY040czIxVjF1UVpDS0Nu?=
 =?utf-8?B?UFh4NStGdEw0MjBWZ0p0Q1JwVFVhdlcyd0RzWEFib0t5UHpMc0VJZzJ0dFl1?=
 =?utf-8?B?aFFJVlhEMGVHTkttSU1IU3R3cXNqSWpqV0twdnlsVHlrNFI0dVJqcnFveEN0?=
 =?utf-8?B?ZUROQ3VZS2JxRmhNRFlnSnkxald6N01LUEVRZXp1cUE5RTJUd2docjhrODJW?=
 =?utf-8?B?V2pFVEgzSWIvdW4rM3ZqSGI5Vy9sUHpjbXNFOG53VUZpVDBNbEpHcG51eDlq?=
 =?utf-8?B?M3Y3cFV6N3FseFJLUTFOVGNpRmhNeXVRR3cxUWZhL0s0clMrdnBiaTE4dDlu?=
 =?utf-8?B?eGFqVnVDT1owMFU3cStoNHAyL3Y3WFRzc2MvR3NQNVRxaGVyZ2tFTzJteGF2?=
 =?utf-8?B?QzA0U1hsR01ORHRRVFVaQ0tkcEl0dDAvZjJvbHlIYXI3dzhZUmU5MGdIdWVW?=
 =?utf-8?B?cHpNYjFNbTFsek4vZUdDWSthZ25wenB1ZFNIWEl0ZTdkMlBhNzlCYThiZmdm?=
 =?utf-8?B?Uk00bnJ1dE1HbE8yMEV5clhQZ0lZd2RPaFhPRlJlUmdkczFySlJJUWJsTW9I?=
 =?utf-8?B?aFoxdUNqTzVNUFY0emthOG01WHg5dVVuSHhFY3hJN3JrZUVib3lZQXlZT0dl?=
 =?utf-8?B?V3l1SUJ6ODdudFdQajNDWHN0V2hsK0dDQkVsb25FTTBXSzZPU00vbktUbk1C?=
 =?utf-8?B?bE9yV1pMMWc2U29ocEZKODY5K2YrNUtuY3JDNFJScDFxaEN1emRCRDBhcUlT?=
 =?utf-8?B?Z3hTUFpoWjQwSG16V2xJNUJLQVU0b3VIZno1WE16WFR1bGI3MXd0UmhramJp?=
 =?utf-8?B?Y2UrWUNXZGtKek5TMS9qMWwvZjlkSVJEa0lEdllxQ25IVlQ5VGdHQm1WRFdm?=
 =?utf-8?B?NmJDeEFWUkh3VERqRTdSRHF3TXVTd1JFQW1RY0FQS1JLRE9xM0hZYWE1dE40?=
 =?utf-8?B?dXVua09NdTAzL3FMN3pSVWxxOXZ5b1BEY1pkdmtYbXkxeUdJQkF3bUZOdGl5?=
 =?utf-8?B?dWFqVTF0cTNqY2JwWURIdk1LVEtkNC9wRHdQME56TUJPQ3pMenVyUXRHWnor?=
 =?utf-8?B?YzJObzAyNmYvaFg0N0doeDNmUHZsWW80cVlSM3JiMjRwZUVvSHFJTDJLQkFX?=
 =?utf-8?B?MjdEVW1pb2x0VmVIT3Fta0tLakMvemtqaGVsckN0S0IzazNBZDVtdU9sMTJi?=
 =?utf-8?B?bWRwOG1ibVYyNHlaZ0xTUit2ZEtyUmxBVGdlTU4rZGp5M2g4VjVpeGRQekhN?=
 =?utf-8?B?TlpqZVRTOEtuVjhsM0pXZ2FXNUkzR3RpT2JWS0ZmS1J5YkkyaFpoUVI5ZG1p?=
 =?utf-8?B?eU5KU3RIeE14VFFCeHA3ckNYb3hRbVYybUMyMzYwMkxNT0trRTMwcWdwcHJI?=
 =?utf-8?B?R0VKc3dBanNYd2lvQS92NVhLbk9GampTS3VBQ1o0SU5wVmpTQys0dXorNmdh?=
 =?utf-8?B?Z3R5YjU1dUFkSkc5aDZMZHpoVUxvd2VFWHl3alIrTUpsbDVKcUlMcTNJOHZE?=
 =?utf-8?B?Q2RlMEJpdGM5Vm90TGFSbUhsVDFKbEtxY1BXOGQxdmFtZXgxcUIycSt2T1FJ?=
 =?utf-8?B?ZFR0VVN4TjlqTmp1aS9ocXdFWWVkWTN0bUpKR1VCZ0NraDNGV2txQWJ6akdi?=
 =?utf-8?B?UDNGREorLzdSMXh0YnNZVk5OWllJaXFGTVJwK3hWcDRudlB0UFJTb1I0SkFw?=
 =?utf-8?B?WkJpa1U3UXk2b3JmR1h4S09iSGtxRnJENzBGTU94ajdINzNsTGJrSEt6ZlN5?=
 =?utf-8?B?SXcwdituemdsMjRlVEVCMmc5aXlXbGp5bVpnK2UyU04xeFFKZ0c3NmNhamhU?=
 =?utf-8?Q?9zAz4bgtXSfKn/zCD3YKoc3L/?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a8566431-0e27-4815-b4cf-08dda737ace4
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jun 2025 09:26:12.4816
 (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: Lp++kSBTSOU3gptNaNtffilRonpLA7yAMsdY/DECf7vkgA0Bzii9yvrI4G3rl/Mo0l6obPR28jP+EIkD2Ehwtg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7348


On 09/06/2025 09:37, Luca Fancellu wrote:
> Hi Ayan,
Hi Luca,
>
> If I understand correctly Armv8-R AArch32 supports up to 255 regions, so I would expect ...
>
>> /*
>>   * Armv8-R supports direct access and indirect access to the MPU regions through
>>   * registers:
>> @@ -85,6 +87,7 @@ static void __init __maybe_unused build_assertions(void)
>>   */
>> static void prepare_selector(uint8_t *sel)
>> {
>> +#ifdef CONFIG_ARM_64
>>      uint8_t cur_sel = *sel;
>>
>>      /*
>> @@ -98,7 +101,8 @@ static void prepare_selector(uint8_t *sel)
>>          WRITE_SYSREG(cur_sel, PRSELR_EL2);
>>          isb();
>>      }
>> -    *sel &= 0xFU;
>> +    *sel = *sel & 0xFU;
>> +#endif
> something here to check if the selector is 0-31 or not and:
>
> - set the selector to 0 if set is 0-31
> - set the selector to 32-255 if sel > 32

yes, good catch. I was initially thinking of supporting only the first 
32 regions for arm32. So, it would BUG() for region numbered 32 onwards.

I can expand the patch to support all the 255 regions.

>
> And ...
>
>
>> }
>>
>> void read_protection_region(pr_t *pr_read, uint8_t sel)
>> @@ -123,6 +127,24 @@ void read_protection_region(pr_t *pr_read, uint8_t sel)
>>          GENERATE_READ_PR_REG_CASE(13, pr_read);
>>          GENERATE_READ_PR_REG_CASE(14, pr_read);
>>          GENERATE_READ_PR_REG_CASE(15, pr_read);
>> +#ifdef CONFIG_ARM_32
>> +        GENERATE_READ_PR_REG_CASE(16, pr_read);
>> +        GENERATE_READ_PR_REG_CASE(17, pr_read);
>> +        GENERATE_READ_PR_REG_CASE(18, pr_read);
>> +        GENERATE_READ_PR_REG_CASE(19, pr_read);
>> +        GENERATE_READ_PR_REG_CASE(20, pr_read);
>> +        GENERATE_READ_PR_REG_CASE(21, pr_read);
>> +        GENERATE_READ_PR_REG_CASE(22, pr_read);
>> +        GENERATE_READ_PR_REG_CASE(23, pr_read);
>> +        GENERATE_READ_PR_REG_CASE(24, pr_read);
>> +        GENERATE_READ_PR_REG_CASE(25, pr_read);
>> +        GENERATE_READ_PR_REG_CASE(26, pr_read);
>> +        GENERATE_READ_PR_REG_CASE(27, pr_read);
>> +        GENERATE_READ_PR_REG_CASE(28, pr_read);
>> +        GENERATE_READ_PR_REG_CASE(29, pr_read);
>> +        GENERATE_READ_PR_REG_CASE(30, pr_read);
>> +        GENERATE_READ_PR_REG_CASE(31, pr_read);
>> +#endif
>>      default:
> have something here for Arm32 to access the regions 32-255
>
>
>>          BUG(); /* Can't happen */
>>          break;
>> @@ -151,6 +173,24 @@ void write_protection_region(const pr_t *pr_write, uint8_t sel)
>>          GENERATE_WRITE_PR_REG_CASE(13, pr_write);
>>          GENERATE_WRITE_PR_REG_CASE(14, pr_write);
>>          GENERATE_WRITE_PR_REG_CASE(15, pr_write);
>> +#ifdef CONFIG_ARM_32
>> +        GENERATE_WRITE_PR_REG_CASE(16, pr_write);
>> +        GENERATE_WRITE_PR_REG_CASE(17, pr_write);
>> +        GENERATE_WRITE_PR_REG_CASE(18, pr_write);
>> +        GENERATE_WRITE_PR_REG_CASE(19, pr_write);
>> +        GENERATE_WRITE_PR_REG_CASE(20, pr_write);
>> +        GENERATE_WRITE_PR_REG_CASE(21, pr_write);
>> +        GENERATE_WRITE_PR_REG_CASE(22, pr_write);
>> +        GENERATE_WRITE_PR_REG_CASE(23, pr_write);
>> +        GENERATE_WRITE_PR_REG_CASE(24, pr_write);
>> +        GENERATE_WRITE_PR_REG_CASE(25, pr_write);
>> +        GENERATE_WRITE_PR_REG_CASE(26, pr_write);
>> +        GENERATE_WRITE_PR_REG_CASE(27, pr_write);
>> +        GENERATE_WRITE_PR_REG_CASE(28, pr_write);
>> +        GENERATE_WRITE_PR_REG_CASE(29, pr_write);
>> +        GENERATE_WRITE_PR_REG_CASE(30, pr_write);
>> +        GENERATE_WRITE_PR_REG_CASE(31, pr_write);
>> +#endif
>>      default:
> also here have something for Arm32 to access the regions 32-255
>
>>          BUG(); /* Can't happen */
>>          break;
>
> Please let me know your thoughts.

Ack

- Ayan

>
> Cheers,
> Luca
>
>


From xen-devel-bounces@lists.xenproject.org Mon Jun 09 09:29:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jun 2025 09:29:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010198.1388351 (Exim 4.92)
	(envelope-from )
	id 1uOYpE-00025w-RY; Mon, 09 Jun 2025 09:29:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010198.1388351; Mon, 09 Jun 2025 09:29:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uOYpE-00025p-NX; Mon, 09 Jun 2025 09:29:52 +0000
Received: by outflank-mailman (input) for mailman id 1010198;
 Mon, 09 Jun 2025 09:29: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 1uOYpD-00025j-3q
 for xen-devel@lists.xenproject.org; Mon, 09 Jun 2025 09:29:51 +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 4a566e5e-4514-11f0-a304-13f23c93f187;
 Mon, 09 Jun 2025 11:29:50 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3a52874d593so4017516f8f.0
 for ; Mon, 09 Jun 2025 02:29:49 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a53244f07dsm9208001f8f.79.2025.06.09.02.29.48
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 09 Jun 2025 02:29:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4a566e5e-4514-11f0-a304-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749461389; x=1750066189; 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=BtrQJEnXi92/tm+p/7qv+7Zmn0bRhtMrAiRLe9dE06U=;
        b=A/rtboN7pJfhsiQPxaNs2fcI8X9cN8YXnN3uv6d/J3Emv5h1g8f5h+yzObKfZcJOTs
         s1P8xKenJAfOtjzlgFsPvVGCqMoB0/+g/qNXQTC8dPIEnNA+QL+0NonUjKeWFyxlHTZq
         F53/wPWS/1iS5vvW6hmZ9hABhC+2MUdktTi9s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749461389; x=1750066189;
        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=BtrQJEnXi92/tm+p/7qv+7Zmn0bRhtMrAiRLe9dE06U=;
        b=kYGKx6pci1GN4hrUZtbI32rgt3Vxy4cJXadW4w4GRfRlHYQcdB6+1anppUnJZfDo0h
         BaGcvFT+vjU56/CipDGZLFyYX2jgxR+21xojQ3sqkKboa1EQzzu0cU9oMJuNqcrHwrlN
         C2JEPJoLqGoUECBZ86oSYtihcM+I8tF9sWyaCqNOtJdzXBNUQ3/QznDAHeurz/YuAxzt
         DNbORQnRHiFupnQQE8L8qvbrL5gLO/O6lcIZZJ9a/Zk08fc+3oDUxgRSfazEJRJW9LSW
         xs+MgFDLKKAuiYYXQZZgKpA4SS34xmdU0XS6WOqgZk4n5YTB3XD5i/yuy15dNF2baQaQ
         kaTA==
X-Gm-Message-State: AOJu0Yy2cZhhVbPfV5H66qVFyKi7kCpOGDnTXBRahI+rl1CkWkKKNGQ7
	N/Wvski72ZyL91MHYsrDzU4451bTwvKrBitwKUE2Rv4NjAmF3btfwA/8gdOtQkOaRFQ=
X-Gm-Gg: ASbGncsASJdwmuOb71LHhsS67+ugubShzfT3S6eam4y/WyyJlhbdNSDRXwuJfd9ApB0
	3GnwXF1lCpIanZqr8JrKB6so0kPYqeaZsK/uraurtkVWz0IR/ZNfR/WweY39wehmm5HJVQcCby8
	zlD+PCR8kzkRZbiJRPM6EYAfOwrcbmGwtE180l1gh5u39D9ultKfUniqGwwWokgTFqk5CpV2Fg/
	BnLRJ7ucFuROIms5Xw9mk+7h80C+1tRT+wA5vQbeP7tBODbveNXzv3d4QO84z+7WMcHWOlj47Nl
	vzUSVnB05gF0AaFiA4U2bbtiHvkkSSu0tfeJMbbtBK2VvmD7un6rXlEHVqNalMkq5k0YPf/txSN
	yow2OGeckyC9LsinWRey8GePGtG40MQ==
X-Google-Smtp-Source: AGHT+IFRuvXDrPRKEOrumfu238VRd/wMQykXGd1N52ehiffAddKqSEmdyCH9HYppGPAHYjpy65JEbA==
X-Received: by 2002:a05:6000:2dc7:b0:3a3:71cb:f0bd with SMTP id ffacd0b85a97d-3a53188de8bmr9401210f8f.23.1749461389254;
        Mon, 09 Jun 2025 02:29:49 -0700 (PDT)
Date: Mon, 9 Jun 2025 11:29:48 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: "Chen, Jiqian" 
Cc: "xen-devel@lists.xenproject.org" ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	"Orzel, Michal" ,
	Julien Grall ,
	Stefano Stabellini ,
	"Huang, Ray" 
Subject: Re: [PATCH v5 04/10] vpci: Refactor REGISTER_VPCI_INIT
Message-ID: 
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
 <20250526094559.140423-5-Jiqian.Chen@amd.com>
 
 
 <752cff02-cef6-4a4c-80b9-eba3bbf9b264@suse.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Mon, Jun 09, 2025 at 07:50:21AM +0000, Chen, Jiqian wrote:
> On 2025/6/6 17:14, Roger Pau Monné wrote:
> > On Fri, Jun 06, 2025 at 09:05:48AM +0200, Jan Beulich wrote:
> >> On 06.06.2025 08:29, Chen, Jiqian wrote:
> >>> On 2025/6/5 20:50, Roger Pau Monné wrote:
> >>>> On Mon, May 26, 2025 at 05:45:53PM +0800, Jiqian Chen wrote: 
> >>>>> +  }; \
> >>>>> +  static vpci_capability_t *const finit##_entry  \
> >>>>> +               __used_section(".data.vpci") = &finit##_t
> >>>>
> >>>> IMO this should better use .rodata instead of .data. 
> >>> Is below change correct?
> >>>
> >>> +    static const vpci_capability_t *const finit##_entry  \
> >>> +        __used_section(".rodata") = &finit##_t
> >>
> >> No, specifically because ...
> >>
> >>>> Not that it matters much in practice, as we place it in .rodata anyway.  Note
> >>>> however you will have to move the placement of the VPCI_ARRAY in the
> >>>> linker script ahead of *(.rodata.*), otherwise that section match will
> >>>> consume the vPCI data.
> >>> I am sorry, how to move it ahead of *(.rodata.*) ?
> >>> Is below change correct?
> >>>
> >>> diff --git a/xen/include/xen/xen.lds.h b/xen/include/xen/xen.lds.h
> >>> index 793d0e11450c..3817642135aa 100644
> >>> --- a/xen/include/xen/xen.lds.h
> >>> +++ b/xen/include/xen/xen.lds.h
> >>> @@ -188,7 +188,7 @@
> >>>  #define VPCI_ARRAY               \
> >>>         . = ALIGN(POINTER_ALIGN); \
> >>>         __start_vpci_array = .;   \
> >>> -       *(SORT(.data.vpci.*))     \
> >>> +       *(.rodata)             \
> >>
> >> ... this isn't - you'd move _all_ of .rodata into here, which definitely
> >> isn't what you want. What I understand Roger meant was a .rodata-like
> >> section, e.g. .rodata.vpci.* (much like it was .data.vpci.* before).
> > 
> > Indeed, my suggestion was merely to use .rodata instead of .data, as
> > that's more accurate IMO.  I think it should be *(.rodata.vpci) (and
> > same section change for the __used_section() attribute.
> 
> If I understand correctly, the next version will be:
> 
> +    static const vpci_capability_t *const finit##_entry  \
> +        __used_section(".rodata.vpci") = &finit##_t
> +
> 
> and
> 
>  #define VPCI_ARRAY               \
>         . = ALIGN(POINTER_ALIGN); \
>         __start_vpci_array = .;   \
> -       *(SORT(.data.vpci.*))     \
> +       *(.rodata.vpci)           \
>         __end_vpci_array = .;

Did you also move the instances of VPCI_ARRAY in the linker scripts so
it's before the catch-all *(.rodata.*)?

> 
> But, that encountered an warning when compiling.
> " {standard input}: Assembler messages:
> {standard input}:1160: Warning: setting incorrect section attributes for .rodata.vpci
> {standard input}: Assembler messages:
> {standard input}:3034: Warning: setting incorrect section attributes for .rodata.vpci
> {standard input}: Assembler messages:
> {standard input}:6686: Warning: setting incorrect section attributes for .rodata.vpci "

What are the attributes for .rodata.vpci in the object files?  You can
get those using objdump or readelf, for example:

$ objdump -h xen/drivers/vpci/msi.o
[...]
 17 .data.vpci.9  00000008  0000000000000000  0000000000000000  00000a50  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, DATA

It should be READONLY, otherwise you will get those messages.

> And, during booting Xen, all value of __start_vpci_array is incorrect.
> Do I miss anything?

I think that's likely because you haven't moved the instance of
VPCI_ARRAY in the linker script?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Jun 09 10:19:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jun 2025 10:19:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010205.1388362 (Exim 4.92)
	(envelope-from )
	id 1uOZae-0000Iq-AC; Mon, 09 Jun 2025 10:18:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010205.1388362; Mon, 09 Jun 2025 10:18: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 1uOZae-0000Ij-5i; Mon, 09 Jun 2025 10:18:52 +0000
Received: by outflank-mailman (input) for mailman id 1010205;
 Mon, 09 Jun 2025 10:18: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 1uOZac-0000Id-CC
 for xen-devel@lists.xenproject.org; Mon, 09 Jun 2025 10:18:50 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20605.outbound.protection.outlook.com
 [2a01:111:f403:2418::605])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 20ec48cb-451b-11f0-a304-13f23c93f187;
 Mon, 09 Jun 2025 12:18:48 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by DM4PR12MB7742.namprd12.prod.outlook.com (2603:10b6:8:102::18) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Mon, 9 Jun
 2025 10:18:43 +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.8792.034; Mon, 9 Jun 2025
 10: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: 20ec48cb-451b-11f0-a304-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=u4e0Ef9Zh7Ol/bjgd+pEN13ymvSjPLwkUPudL5e1Y69o+SV1KukUzE84ycVmpX/kX0AAkc/c+s5gH9ixgsbYRUQRBzwu3jCUsdbda09xZUnPOZsGBpH6CRK1gpAmgGaZNljl6mtQ9gtdfps7elCRmp3ERqcoL6ILrT+7l1W+r5rlClJO9ahRKHYEG47BpnMHdW3nr4JbQVvfliiw5VYeQl9gqrIIbJ1PiCVbZ95zaG3sgp57m+8wOrF56pFW4njXpDzY+aeJ4U7k9ZpkegY8OwCXDbOlZRgsxv0+QLGQI1KPv5KbjKNE3oZp0LxdOPM9tVWL4FUhtpVxQdD9ZHP5RA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=pX3k29XG7qCf8P+McK8CkVI178boXwL+wwstIqutPLo=;
 b=y9OMY1lBFt0LfNoEn+6tqJk/hBJCXmpiQn2+Y1YRnnXyz8NVh6V73w3LfhbFCV0UMLbOsIR/cz/WK4oOYw8hBLdqyDZElB5Iln8UWtRAt9kGaoyp6D/ZBtW5fTstcm8gSjhhab91mYxLKm105o8f2ztYlJYpfYzjvJOkPgBqarKit3svTrQB3zXX3rQu2EjZx2V77G69SRbF85L273cBGD9lHxh/D556pfLF3/F8LA7yCasyYqdSVGYgnVd9dsMSHeiUNN49ISrlt4SMnq6tBuLP1SajHoDfwLjuEA/BwLVhQKCBOgNaDWngbU5Ofy+eJG8x25KKs8ZV55ykCtOrKQ==
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=pX3k29XG7qCf8P+McK8CkVI178boXwL+wwstIqutPLo=;
 b=OOINODKaZQNuzSS/YhJcXWl/3Snsx0ZKzNM65TRObdsPY+21U6AVDXMvMpYCIioHxX+3/Jicpd6VOozCigFsbJ6d1xMKuO/y3arGlhJR/e0OXiVCv3R05a0huA0dmyylDGOJWG2xMcrC86DAf+lITcGk3tvkUE4H7UJidUw5ZZw=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= 
CC: "xen-devel@lists.xenproject.org" , Jan
 Beulich , Andrew Cooper ,
	Anthony PERARD , "Orzel, Michal"
	, Julien Grall , Stefano Stabellini
	, "Huang, Ray" , "Chen, Jiqian"
	
Subject: Re: [PATCH v5 04/10] vpci: Refactor REGISTER_VPCI_INIT
Thread-Topic: [PATCH v5 04/10] vpci: Refactor REGISTER_VPCI_INIT
Thread-Index:
 AQHbziMOHCuaHG697kCTYWoBETQpzrP0lKSAgAGsWwD//4WWAIAAI9IAgAUkMwD//5c1AIAAk1OA
Date: Mon, 9 Jun 2025 10:18:42 +0000
Message-ID:
 
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
 <20250526094559.140423-5-Jiqian.Chen@amd.com>
 
 
 <752cff02-cef6-4a4c-80b9-eba3bbf9b264@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.8792.033)
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_|DM4PR12MB7742:EE_
x-ms-office365-filtering-correlation-id: 1a055cb6-c60f-4e3e-1bda-08dda73f02b4
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?bmdYQmJkS3FHZ0crMjBUSkZDamlFNUxEanY0VGNoZmhkMkJCQmNWYnRuZlc5?=
 =?utf-8?B?ZlROa2YvcUY4R0l5a3MxVVdTcFllM0RQUWt1MGUrNGdaMWhFQWNBemthVWRi?=
 =?utf-8?B?WDVaZi90ZmhTdVlCZEhDTjk3Y01ybkliTGoyZGo3N3JQVHNwb1hPZE9NTG93?=
 =?utf-8?B?YnZPajNrMXN6ZVArd3h2ZXZQYUs3ellsbmM0MGU2S2Y1YUsrMDNSaGhDQ3Yv?=
 =?utf-8?B?dEhsbkxXQ2RmV0lheUdUcjhYU0VaZXFVeWNnNkpzUXFaWkF1NVJScDRsc09Q?=
 =?utf-8?B?V2hEVWNrVVRsOXpnOXJ6ZzJTNnU5ZFNhOC9wN3ZZSzJjaUtEUHdWUGxtWU5l?=
 =?utf-8?B?alljb0xJQ1ZITE53MFB6S1VtZnFHSXRGdFA4VmNCd3VWMEhTK0x2WXptVDg1?=
 =?utf-8?B?eUxyNVNDTmFVSjhKekdXVmZwNlljNTUzdkpUVStOeWhQM3BOem9XLzdPMzBa?=
 =?utf-8?B?dmlQMnhmWW9SeUtGZWIzdVlualh0bWpla0NJbFZWWXNyL3pPL21SbVZ6VDE3?=
 =?utf-8?B?UzdCckxhaWN0T1N6NHVCWEhsa1hpTWpCWDhDaVdYV3lGVUhydFZqcXU0VjlL?=
 =?utf-8?B?UTRuSkI5dGJ0MUY5QTV2TEplQmJFYldrMlh5THkvRWNqR2RLVkVVaENnWlJ0?=
 =?utf-8?B?dU82L3pPdG5EV1l3MWNVUlVkYmFJSjBJTjRjYUVyUkFzSVZOWmZVeFQyUUtK?=
 =?utf-8?B?UGkzVWdSeFlhclNxRUU1V1FpKzVyTWxzUHVlWG1RSUdJZnI5Nzl2NStzSXlG?=
 =?utf-8?B?YUNIMHJUcHo3L3J6RkdWUzJ2eitoQW12U044Q1VsOEF1em5BdjcrR2E5NVpF?=
 =?utf-8?B?UjlFY0lWSnk2bERzTTAvNXJhK2lCWnY1RGRFTzZ1RWNSYm5NMW9tUlN5YlF3?=
 =?utf-8?B?VUs5SzhIcFppdzdsRUd3RWRzNmxDaVhiZjNyR1UrUUlQUVR4VHJpUTVQbllL?=
 =?utf-8?B?bHdmRWhoV3hEUDNydmdKODRCbWsvOXlpd09mOWVEL01jRmVTK2ViWGlUYkFV?=
 =?utf-8?B?WFVoUEpRV0ZGcmpkUWpta3RXOEFTSHpwNU9pc0NnSWIzZ0hQbUhDdnFRUTNs?=
 =?utf-8?B?SnU2ZkVVejQ4U0M3MmptdzdSWkFYOU4zNmpuT0pBaUlUaldzaGhRSWQraUF4?=
 =?utf-8?B?Qm1RWURTU1lkRmtxejh3d08zSk5mZkJsZFUvQm9QWUFrNGtvZGlBWlN3UDBP?=
 =?utf-8?B?U0l1MWZkR3dCVStaVE1udTlVTnlETWRVeHBKSDFmczZGeWpkOGZiV0xaakx1?=
 =?utf-8?B?elh2bmd4dkNNeUwvMXk5Z25LM3F3TkY1UmJhbEo4aHpOcXJ5QjcwTGlNNWlM?=
 =?utf-8?B?MVhtSFNpSEkya3Zsdk1IcEh1Y0t3ejBlMWpsZTI0YURSb1ZRb0xzYjRSMGFm?=
 =?utf-8?B?cWJ4NThLMTVYNENrVEZHR21qckNKbUZJaFJ4WGlpN2FDd0tsYm5TUDRNNVJS?=
 =?utf-8?B?UkZxMXhPTjQzdUVjRDNIYmtVdk54UzJKQzdIMy8xZUVNOHdPbUZSSWEzMC9s?=
 =?utf-8?B?SG1qK3k0YmVLTC9IZ0NNZjNzakNYbWhPN1hVcDMyaGxCNmlIMDEzbXdvd2NQ?=
 =?utf-8?B?SUNsNlJUV0NvVDNMTWZETE96Z0lVQWxRRHhIZjAyaU4xbENvaVl2OWRsaDZH?=
 =?utf-8?B?bVpHRkU2aU5TQU1WNFI0aXNLZW1NOXhqazZyRkV2SThqVWhWRHRyczhZd2Vo?=
 =?utf-8?B?LzBBSEx6RkVMTjBnMFRhSEZSRXJGaTUyVUlGMWNIUURtNUdSeXJtWkxvcDV2?=
 =?utf-8?B?WjhRQmpvOTdFVmJoZDFLVG1wLzhhQ29acThCYXNMS3gxTm03RW52eEpzL0hU?=
 =?utf-8?B?dWZwaUVGbkpHM2VvUW9nQmVhMHVSVGtoRzd3UGk3UjNNZHo0cWNQS2VEdmlO?=
 =?utf-8?B?UTRlUC9WNGlRbmJZc1FKMlk3TFUxRm5HdFJ0aFhTMmpoenI1YTNhZVZkeWc1?=
 =?utf-8?B?YmtlUE1XRmJVZThxRXVKelBUb1dCM2w2emlLQmhBY3NPd05KRE5sRUJRanNM?=
 =?utf-8?B?L3J3c3pvU1l3PT0=?=
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?VlJrV2FyWVhwMWQvN0VkU3o4QmNQVVRXOHZ3QTh6cHNOYmtOc0c4UGk5L1FP?=
 =?utf-8?B?V29icmFydlBBbDhGZWtnb1NxZFhob29qWjFhNGswTGc0bkl0enVWUjE2Qkp1?=
 =?utf-8?B?b0NaTEhFTlBQd1pFblBDRHN4YlI2NWR2SGJSZ2ZlbVpkRldIUmEwWmZ1VWxE?=
 =?utf-8?B?SUsyWjZpY1k2clhQQ1JobFB3ZGpnT0FFTDI2UlhEVlV5RVd3ZGdxZEdhYzFD?=
 =?utf-8?B?L2tyVzJhY2xUbWQyQmo3SlFyQ3Y4ZDVpU1dEZlM5ekVHS2RuY0lNWFBsZVc0?=
 =?utf-8?B?SFdwZXo2WGtkR0Zuc2gvejlIRWg2cWpOb2tZUTM1UTRzR2FIdW9FWjZBTWxH?=
 =?utf-8?B?TldtTXRQSHJjVEVwdHh6ZGZxQ1RnQjcyVmEzTVdGOTdaOWthS3hCRlE3ek92?=
 =?utf-8?B?YmJCdThuNWNQNzZTNXVlWkVhcU9nT3ZaelRzdGhvMVFxeExUUUtkNFFDR1ND?=
 =?utf-8?B?akp4dy83dktOR0xqR283OHNVdU52eGFsRXVjL0ZxTzBYa3U4VnU2ZGJQWGVM?=
 =?utf-8?B?aWJjbkkxZ1FEZ0ZOV2Jqb2NMT0JsR1YyUkdmbFpKZkVyaElKTzQ1ZmtZaVZv?=
 =?utf-8?B?N3YxRzJRUURKRW9jS3pxMlh3aG41VEEzRS9VbmxrVk50WmZnNG5YTnh2QnNZ?=
 =?utf-8?B?QVRJcmNDZ3BOWS9BbFZJd1E5Rk5adXROOG9QL0NsZFo1Rk5GRHFaQmxzbnV0?=
 =?utf-8?B?VmIrZmhFeVlJdGNLRFE2aUdYRWlBODcyWXlNN2ZlUUpVZEFRQjNxOTlYelVo?=
 =?utf-8?B?V3I5d0FIeGJ4d2d5Y3ovRWorL3VtVS9IcWs2R1B1QXNtNTJkVmdlSE5FbkJs?=
 =?utf-8?B?NmlZb1g5Y0FON0xTV1cvdjdsTVZCaGMvRnRTeVBGTDhITVQ1UW0xemJzUTN6?=
 =?utf-8?B?NEY0aTFKNVptT3RuTVZlYm1MTWhGcjQ2M2hvdUMweUZ1MDR0WDhCNHBoTytI?=
 =?utf-8?B?NEtvWHlOaHJ6Yk9rZ1RhSXBEaDVvMmhZWGFxWjRpOHRYTVVpNCtSWE9JWTVM?=
 =?utf-8?B?UVduWlBRUXA3Y3NiSkpYT0FMRGQ1blBTeUFmT1JZWGlVdVM3SEQzOWJ2Vy9S?=
 =?utf-8?B?dS9NUHlHZWRwV0JudCsrODZGVWNsVDEycVQvaVcvMkpqN2lJaW5DbXlIWnNv?=
 =?utf-8?B?U0tBOHJIRVZBVmxjNExaMDJvVmNDWmNCVEdZY0o2QU5OdXlvbTFveTl0OC9P?=
 =?utf-8?B?Q1czUVNnSjlJYTVSeUlFS2ZBY2p5WkFNMEw4S2NZNUh4Ykc1ZjRKSHYrd1Nh?=
 =?utf-8?B?cVRSS3JQRWEwMmhGSy9Xbm5EM281YXJaZmFCZkhSa0NlZ0VndnVOcytwTHd6?=
 =?utf-8?B?c0NCS1pSV3RMQzlhb2VpTjh3bndiVSt2cVljREU1emVkak9DcXB5bmZYSVFT?=
 =?utf-8?B?WkdWajhvRDVsR3JiOHVwblJCVHpRNnFzUzk0MEFqcHJSa21JS0Y1YTFndENi?=
 =?utf-8?B?OW1UL3cyN2FvN2xTZ21md000OFdEcmxxNG9pT21jaDZIU1RhVVJQNTN3bGc2?=
 =?utf-8?B?L3N3ZFdhSStHa2x6VVllcHJKSnUxWUJSQmx1TDYyaGhrbXN5dWhuREpvNisv?=
 =?utf-8?B?QmF0T2ZUWlh2Z1FxT2t2TjVpZVVTazRGQTM3U290TkZ2czhhSHNJRGNLMzVh?=
 =?utf-8?B?anpoWmRqbTZJaUdsVThHRkp6ZUh3eTZ2YnU3Q2pOcGh5dmV5RU9MdUpRR0to?=
 =?utf-8?B?RVVzTWtKUzNBL2hVSEhVU3A5VFNIcW5vT3JmZ3RjK2lRblBXOWw3aXdtL2FL?=
 =?utf-8?B?TFM5WFBTV2VCcjRkRzlTRWNURkhBeTJkUUZXbEM2a3NvQ01Ka253UzIyN0NF?=
 =?utf-8?B?czhrQU9ieUVFMnVQMlM0NFhjc1NKYXB1cHJlbUVJb2tCb0U2b2JnbTlEMWRE?=
 =?utf-8?B?NGJEMlNpSXVXcjF5NXgrK09wc1c5UzlNN2drYysrbmZubU5ZSTRSdjBhTkZ6?=
 =?utf-8?B?WncvdVdjY1o4Z0ZzZnJKdU92eTZnY0VXRnFVTms4bGZic3R6akVySkx6SlJ1?=
 =?utf-8?B?MFhTUlNtbVRxcU9KNU81aXB0ZlUvbVZ2Q2NMZDFubEg3T2FkYWVwcDQwdFJF?=
 =?utf-8?B?M1J3VFJ4cnh6aWo3WnNDUGRQc0ttbTJGeUN3UFhjbURIT1lXNm9YSHVUcXlj?=
 =?utf-8?Q?WBBY=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: 1a055cb6-c60f-4e3e-1bda-08dda73f02b4
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2025 10:18:42.6015
 (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: dXrp8BpomuU2rGm+FaqKfMafrfiBrDuuy21CHH53cHBNWgUv66vHvmk9g5Bg2BFnjIwjxxffMbM4rBSu8FU/3Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB7742

T24gMjAyNS82LzkgMTc6MjksIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+IE9uIE1vbiwgSnVu
IDA5LCAyMDI1IGF0IDA3OjUwOjIxQU0gKzAwMDAsIENoZW4sIEppcWlhbiB3cm90ZToNCj4+IE9u
IDIwMjUvNi82IDE3OjE0LCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOg0KPj4+IE9uIEZyaSwgSnVu
IDA2LCAyMDI1IGF0IDA5OjA1OjQ4QU0gKzAyMDAsIEphbiBCZXVsaWNoIHdyb3RlOg0KPj4+PiBP
biAwNi4wNi4yMDI1IDA4OjI5LCBDaGVuLCBKaXFpYW4gd3JvdGU6DQo+Pj4+PiBPbiAyMDI1LzYv
NSAyMDo1MCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToNCj4+Pj4+PiBPbiBNb24sIE1heSAyNiwg
MjAyNSBhdCAwNTo0NTo1M1BNICswODAwLCBKaXFpYW4gQ2hlbiB3cm90ZTogDQo+Pj4+Pj4+ICsg
IH07IFwNCj4+Pj4+Pj4gKyAgc3RhdGljIHZwY2lfY2FwYWJpbGl0eV90ICpjb25zdCBmaW5pdCMj
X2VudHJ5ICBcDQo+Pj4+Pj4+ICsgICAgICAgICAgICAgICBfX3VzZWRfc2VjdGlvbigiLmRhdGEu
dnBjaSIpID0gJmZpbml0IyNfdA0KPj4+Pj4+DQo+Pj4+Pj4gSU1PIHRoaXMgc2hvdWxkIGJldHRl
ciB1c2UgLnJvZGF0YSBpbnN0ZWFkIG9mIC5kYXRhLiANCj4+Pj4+IElzIGJlbG93IGNoYW5nZSBj
b3JyZWN0Pw0KPj4+Pj4NCj4+Pj4+ICsgICAgc3RhdGljIGNvbnN0IHZwY2lfY2FwYWJpbGl0eV90
ICpjb25zdCBmaW5pdCMjX2VudHJ5ICBcDQo+Pj4+PiArICAgICAgICBfX3VzZWRfc2VjdGlvbigi
LnJvZGF0YSIpID0gJmZpbml0IyNfdA0KPj4+Pg0KPj4+PiBObywgc3BlY2lmaWNhbGx5IGJlY2F1
c2UgLi4uDQo+Pj4+DQo+Pj4+Pj4gTm90IHRoYXQgaXQgbWF0dGVycyBtdWNoIGluIHByYWN0aWNl
LCBhcyB3ZSBwbGFjZSBpdCBpbiAucm9kYXRhIGFueXdheS4gIE5vdGUNCj4+Pj4+PiBob3dldmVy
IHlvdSB3aWxsIGhhdmUgdG8gbW92ZSB0aGUgcGxhY2VtZW50IG9mIHRoZSBWUENJX0FSUkFZIGlu
IHRoZQ0KPj4+Pj4+IGxpbmtlciBzY3JpcHQgYWhlYWQgb2YgKigucm9kYXRhLiopLCBvdGhlcndp
c2UgdGhhdCBzZWN0aW9uIG1hdGNoIHdpbGwNCj4+Pj4+PiBjb25zdW1lIHRoZSB2UENJIGRhdGEu
DQo+Pj4+PiBJIGFtIHNvcnJ5LCBob3cgdG8gbW92ZSBpdCBhaGVhZCBvZiAqKC5yb2RhdGEuKikg
Pw0KPj4+Pj4gSXMgYmVsb3cgY2hhbmdlIGNvcnJlY3Q/DQo+Pj4+Pg0KPj4+Pj4gZGlmZiAtLWdp
dCBhL3hlbi9pbmNsdWRlL3hlbi94ZW4ubGRzLmggYi94ZW4vaW5jbHVkZS94ZW4veGVuLmxkcy5o
DQo+Pj4+PiBpbmRleCA3OTNkMGUxMTQ1MGMuLjM4MTc2NDIxMzVhYSAxMDA2NDQNCj4+Pj4+IC0t
LSBhL3hlbi9pbmNsdWRlL3hlbi94ZW4ubGRzLmgNCj4+Pj4+ICsrKyBiL3hlbi9pbmNsdWRlL3hl
bi94ZW4ubGRzLmgNCj4+Pj4+IEBAIC0xODgsNyArMTg4LDcgQEANCj4+Pj4+ICAjZGVmaW5lIFZQ
Q0lfQVJSQVkgICAgICAgICAgICAgICBcDQo+Pj4+PiAgICAgICAgIC4gPSBBTElHTihQT0lOVEVS
X0FMSUdOKTsgXA0KPj4+Pj4gICAgICAgICBfX3N0YXJ0X3ZwY2lfYXJyYXkgPSAuOyAgIFwNCj4+
Pj4+IC0gICAgICAgKihTT1JUKC5kYXRhLnZwY2kuKikpICAgICBcDQo+Pj4+PiArICAgICAgICoo
LnJvZGF0YSkgICAgICAgICAgICAgXA0KPj4+Pg0KPj4+PiAuLi4gdGhpcyBpc24ndCAtIHlvdSdk
IG1vdmUgX2FsbF8gb2YgLnJvZGF0YSBpbnRvIGhlcmUsIHdoaWNoIGRlZmluaXRlbHkNCj4+Pj4g
aXNuJ3Qgd2hhdCB5b3Ugd2FudC4gV2hhdCBJIHVuZGVyc3RhbmQgUm9nZXIgbWVhbnQgd2FzIGEg
LnJvZGF0YS1saWtlDQo+Pj4+IHNlY3Rpb24sIGUuZy4gLnJvZGF0YS52cGNpLiogKG11Y2ggbGlr
ZSBpdCB3YXMgLmRhdGEudnBjaS4qIGJlZm9yZSkuDQo+Pj4NCj4+PiBJbmRlZWQsIG15IHN1Z2dl
c3Rpb24gd2FzIG1lcmVseSB0byB1c2UgLnJvZGF0YSBpbnN0ZWFkIG9mIC5kYXRhLCBhcw0KPj4+
IHRoYXQncyBtb3JlIGFjY3VyYXRlIElNTy4gIEkgdGhpbmsgaXQgc2hvdWxkIGJlICooLnJvZGF0
YS52cGNpKSAoYW5kDQo+Pj4gc2FtZSBzZWN0aW9uIGNoYW5nZSBmb3IgdGhlIF9fdXNlZF9zZWN0
aW9uKCkgYXR0cmlidXRlLg0KPj4NCj4+IElmIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHksIHRoZSBu
ZXh0IHZlcnNpb24gd2lsbCBiZToNCj4+DQo+PiArICAgIHN0YXRpYyBjb25zdCB2cGNpX2NhcGFi
aWxpdHlfdCAqY29uc3QgZmluaXQjI19lbnRyeSAgXA0KPj4gKyAgICAgICAgX191c2VkX3NlY3Rp
b24oIi5yb2RhdGEudnBjaSIpID0gJmZpbml0IyNfdA0KPj4gKw0KPj4NCj4+IGFuZA0KPj4NCj4+
ICAjZGVmaW5lIFZQQ0lfQVJSQVkgICAgICAgICAgICAgICBcDQo+PiAgICAgICAgIC4gPSBBTElH
TihQT0lOVEVSX0FMSUdOKTsgXA0KPj4gICAgICAgICBfX3N0YXJ0X3ZwY2lfYXJyYXkgPSAuOyAg
IFwNCj4+IC0gICAgICAgKihTT1JUKC5kYXRhLnZwY2kuKikpICAgICBcDQo+PiArICAgICAgICoo
LnJvZGF0YS52cGNpKSAgICAgICAgICAgXA0KPj4gICAgICAgICBfX2VuZF92cGNpX2FycmF5ID0g
LjsNCj4gDQo+IERpZCB5b3UgYWxzbyBtb3ZlIHRoZSBpbnN0YW5jZXMgb2YgVlBDSV9BUlJBWSBp
biB0aGUgbGlua2VyIHNjcmlwdHMgc28NCj4gaXQncyBiZWZvcmUgdGhlIGNhdGNoLWFsbCAqKC5y
b2RhdGEuKik/DQo+IA0KPj4NCj4+IEJ1dCwgdGhhdCBlbmNvdW50ZXJlZCBhbiB3YXJuaW5nIHdo
ZW4gY29tcGlsaW5nLg0KPj4gIiB7c3RhbmRhcmQgaW5wdXR9OiBBc3NlbWJsZXIgbWVzc2FnZXM6
DQo+PiB7c3RhbmRhcmQgaW5wdXR9OjExNjA6IFdhcm5pbmc6IHNldHRpbmcgaW5jb3JyZWN0IHNl
Y3Rpb24gYXR0cmlidXRlcyBmb3IgLnJvZGF0YS52cGNpDQo+PiB7c3RhbmRhcmQgaW5wdXR9OiBB
c3NlbWJsZXIgbWVzc2FnZXM6DQo+PiB7c3RhbmRhcmQgaW5wdXR9OjMwMzQ6IFdhcm5pbmc6IHNl
dHRpbmcgaW5jb3JyZWN0IHNlY3Rpb24gYXR0cmlidXRlcyBmb3IgLnJvZGF0YS52cGNpDQo+PiB7
c3RhbmRhcmQgaW5wdXR9OiBBc3NlbWJsZXIgbWVzc2FnZXM6DQo+PiB7c3RhbmRhcmQgaW5wdXR9
OjY2ODY6IFdhcm5pbmc6IHNldHRpbmcgaW5jb3JyZWN0IHNlY3Rpb24gYXR0cmlidXRlcyBmb3Ig
LnJvZGF0YS52cGNpICINCj4gDQo+IFdoYXQgYXJlIHRoZSBhdHRyaWJ1dGVzIGZvciAucm9kYXRh
LnZwY2kgaW4gdGhlIG9iamVjdCBmaWxlcz8gIFlvdSBjYW4NCj4gZ2V0IHRob3NlIHVzaW5nIG9i
amR1bXAgb3IgcmVhZGVsZiwgZm9yIGV4YW1wbGU6DQo+IA0KPiAkIG9iamR1bXAgLWggeGVuL2Ry
aXZlcnMvdnBjaS9tc2kubw0KPiBbLi4uXQ0KPiAgMTcgLmRhdGEudnBjaS45ICAwMDAwMDAwOCAg
MDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDBhNTAgIDIqKjMNCj4gICAg
ICAgICAgICAgICAgICAgQ09OVEVOVFMsIEFMTE9DLCBMT0FELCBSRUxPQywgREFUQQ0KPiANCj4g
SXQgc2hvdWxkIGJlIFJFQURPTkxZLCBvdGhlcndpc2UgeW91IHdpbGwgZ2V0IHRob3NlIG1lc3Nh
Z2VzLg0KPiANCj4+IEFuZCwgZHVyaW5nIGJvb3RpbmcgWGVuLCBhbGwgdmFsdWUgb2YgX19zdGFy
dF92cGNpX2FycmF5IGlzIGluY29ycmVjdC4NCj4+IERvIEkgbWlzcyBhbnl0aGluZz8NCj4gDQo+
IEkgdGhpbmsgdGhhdCdzIGxpa2VseSBiZWNhdXNlIHlvdSBoYXZlbid0IG1vdmVkIHRoZSBpbnN0
YW5jZSBvZg0KPiBWUENJX0FSUkFZIGluIHRoZSBsaW5rZXIgc2NyaXB0Pw0KT2gsIHJpZ2h0LiBT
b3JyeSwgSSBmb3Jnb3QgdG8gbW92ZSBpdC4NCkFmdGVyIGNoYW5naW5nIHRoaXMsIGl0IHdvcmtz
IG5vdy4NCg0KZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni94ZW4ubGRzLlMgYi94ZW4vYXJjaC94
ODYveGVuLmxkcy5TDQppbmRleCBiZjk1NmI2YzVmYzAuLmM4OGZkNjJmNGYwZCAxMDA2NDQNCi0t
LSBhL3hlbi9hcmNoL3g4Ni94ZW4ubGRzLlMNCisrKyBiL3hlbi9hcmNoL3g4Ni94ZW4ubGRzLlMN
CkBAIC0xMzQsNiArMTM0LDcgQEAgU0VDVElPTlMNCiAgICAgICAgQlVHRlJBTUVTDQoNCiAgICAg
ICAgKigucm9kYXRhKQ0KKyAgICAgICBWUENJX0FSUkFZDQogICAgICAgICooLnJvZGF0YS4qKQ0K
ICAgICAgICAqKC5kYXRhLnJlbC5ybykNCiAgICAgICAgKiguZGF0YS5yZWwucm8uKikNCkBAIC0x
NDgsNyArMTQ5LDYgQEAgU0VDVElPTlMNCiAgICAgICAgKigubm90ZS5nbnUuYnVpbGQtaWQpDQog
ICAgICAgIF9fbm90ZV9nbnVfYnVpbGRfaWRfZW5kID0gLjsNCiAjZW5kaWYNCi0gICAgICAgVlBD
SV9BUlJBWQ0KICAgfSBQSERSKHRleHQpDQoNCj4gDQo+IFRoYW5rcywgUm9nZXIuDQoNCi0tIA0K
QmVzdCByZWdhcmRzLA0KSmlxaWFuIENoZW4uDQo=


From xen-devel-bounces@lists.xenproject.org Mon Jun 09 10:29:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jun 2025 10:29:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010211.1388371 (Exim 4.92)
	(envelope-from )
	id 1uOZkp-0001vT-5A; Mon, 09 Jun 2025 10:29:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010211.1388371; Mon, 09 Jun 2025 10: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 1uOZkp-0001vI-20; Mon, 09 Jun 2025 10:29:23 +0000
Received: by outflank-mailman (input) for mailman id 1010211;
 Mon, 09 Jun 2025 10:29: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 1uOZko-0001vC-GZ
 for xen-devel@lists.xenproject.org; Mon, 09 Jun 2025 10:29:22 +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 9ae47d41-451c-11f0-a304-13f23c93f187;
 Mon, 09 Jun 2025 12:29:21 +0200 (CEST)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-adb2bb25105so655041966b.0
 for ; Mon, 09 Jun 2025 03:29:21 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ade38c11d28sm408418266b.12.2025.06.09.03.29.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 09 Jun 2025 03:29:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9ae47d41-451c-11f0-a304-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749464960; x=1750069760; 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=yj1IhCqqgHEjXOxBKFgKywQRgT0OBUStm3j3rXnSfO4=;
        b=J4Pqp/5hz9SHdusFNS/sFg5M/OXU4agGSHgdxwsWTOkeH5wAItkeThKlVzg5Y/ImIO
         hrfC/NSQmr1m1AY5CDtINag9V06Io2ntqIFVGlUcGRYTAYGS5cCmHfiJZRJ2b00G42ir
         gaXaefQsOYhNMXvffn7UPzTSUZiGfFuQymkat5f6TpMmVlFXHoMfAm2o9u1QcSsLZok/
         eyOug9g4UOqHE6/14i+GRyzRS4LyFOuz5DzmmV5vhHdbKnJpJvvPgM3RvJtuGO5OJFQJ
         21GIabqIQw9BtfRytMioY2BRMZd/PMZMUpoVARhti7EjAEFz2pmQZZCLVM86gLrBC8tt
         L3lQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749464960; x=1750069760;
        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=yj1IhCqqgHEjXOxBKFgKywQRgT0OBUStm3j3rXnSfO4=;
        b=TePos/6WsII72V7wqf1ra2VQIDleOz5TsaNwAyVsaNJDtNLnTIE+t1Xq8BfIcPRond
         ml9gh/yTSwYIPoZdn+kR+w6E+30+xETH/javJRb012GLvMkMhnmVE/0CXRC7gmEtJ/1M
         X5z4YWuHpznaeAqAPKHupKKNN446q0nsRP7BEtwYR4lIhjLmdfGlOljXezces7/vNlHD
         3Iar9qSu76mQNCXiILtDvngk9et4uaWmY3SHcOOI8ekXP/L1wUd4W0AIz1e7kS7lpZOH
         DOZgJl+bVEuYpBJh6hdI+UBvsEGs3vVuI0D1fFxqRMxw99nXGqOHrixNv0h73iJjRS0q
         9ZQA==
X-Gm-Message-State: AOJu0YwcVWvi8nWkkdMcCdJ/VHp8dL0QGHO1Lj38dZF47sSOxxRPF3v9
	nEKP2qtCdOiIBMx0eHAR4Tz3jM1yAYUgvOyOynMnoD8HiywKbNvs0FA1
X-Gm-Gg: ASbGncsH0XGY7hNAqiLB7cNeuS7L/CCA6ffhql9L0Gr18o/hLTdTUjxHLCFJ7HVni7T
	0LluWLhhNa5RNEQnWk7gjYi0dswEx/MP6okESQHoAqttWL1TUoG7+v+++bP2aQmd6HmQLsM1jyX
	ia8KM/uMEwGfolm2c4K6EvA/h2HaqeaVl+XYwVQCs6DwVeA0aJPUx7xhV1+kz6R1HPr98b96J58
	QmwM3q7bUIrHznQ5V3X3Lw0EjUvYPRyiR6iSVG/8U3oL55lv2ksgKx/GUq28Pr5Qc9BI8MJBTwk
	12p5xfo7pK0Mx2OHUUCmX9J2ChFrYs419ahMbUYy0xqCtjAbTPOonh5YZZXmFlhJwS+XSdkKm55
	xot4wfp+RrJhHd8oOez6ELacA
X-Google-Smtp-Source: AGHT+IGCQgw8gOACUHnUWwSZ1ZvlkkS7cCnyzq4l37WkcX6IgzcqFQuwlAudh1YMLXvPy5KH/8yyKw==
X-Received: by 2002:a17:907:3f0a:b0:ad5:a29c:efed with SMTP id a640c23a62f3a-ade1aab9c7emr1242410166b.33.1749464960073;
        Mon, 09 Jun 2025 03:29:20 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------m5fI4O5tmeltvp3INcdWr9He"
Message-ID: 
Date: Mon, 9 Jun 2025 12:29:18 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] x86/hvmloader: select xenpci MMIO BAR UC or WB MTRR
 cache attribute
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: xen-devel@lists.xenproject.org, Anthony PERARD
 , Andrew Cooper ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , Stefano Stabellini ,
 Juergen Gross ,
 Anthoine Bourgeois 
References: <20250605161659.18201-1-roger.pau@citrix.com>
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

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


On 6/6/25 3:41 PM, Roger Pau Monné wrote:
> On Thu, Jun 05, 2025 at 06:16:59PM +0200, Roger Pau Monne wrote:
>> The Xen PCI device (vendor ID 0x5853) exposed to x86 HVM guests doesn't
>> have the functionality of a traditional PCI device.  The exposed MMIO BAR
>> is used by some guests (including Linux) as a safe place to map foreign
>> memory, including the grant table itself.
>>
>> Traditionally BARs from devices have the uncacheable (UC) cache attribute
>> from the MTRR, to ensure correct functionality of such devices.  hvmloader
>> mimics this behavior and sets the MTRR attributes of both the low and high
>> PCI MMIO windows (where BARs of PCI devices reside) as UC in MTRR.
>>
>> This however causes performance issues for users of the Xen PCI device BAR,
>> as for the purposes of mapping remote memory there's no need to use the UC
>> attribute.  On Intel systems this is worked around by using iPAT, that
>> allows the hypervisor to force the effective cache attribute of a p2m entry
>> regardless of the guest PAT value.  AMD however doesn't have an equivalent
>> of iPAT, and guest PAT values are always considered.
>>
>> Linux commit:
>>
>> 41925b105e34 xen: replace xen_remap() with memremap()
>>
>> Attempted to mitigate this by forcing mappings of the grant-table to use
>> the write-back (WB) cache attribute.  However Linux memremap() takes MTRRs
>> into account to calculate which PAT type to use, and seeing the MTRR cache
>> attribute for the region being UC the PAT also ends up as UC, regardless of
>> the caller having requested WB.
>>
>> As a workaround to allow current Linux to map the grant-table as WB using
>> memremap() introduce an xl.cfg option (xenpci_bar_uc=0) that can be used to
>> select whether the Xen PCI device BAR will have the UC attribute in MTRR.
>> Such workaround in hvmloader should also be paired with a fix for Linux so
>> it attempts to change the MTRR of the Xen PCI device BAR to WB by itself.
>>
>> Overall, the long term solution would be to provide the guest with a safe
>> range in the guest physical address space where mappings to foreign pages
>> can be created.
>>
>> Some vif throughput performance figures provided by Anthoine from a 8
>> vCPUs, 4GB of RAM HVM guest(s) running on AMD hardware:
>>
>> Without this patch:
>> vm -> dom0: 1.1Gb/s
>> vm -> vm:   5.0Gb/s
>>
>> With the patch:
>> vm -> dom0: 4.5Gb/s
>> vm -> vm:   7.0Gb/s
>>
>> Reported-by: Anthoine Bourgeois
>> Signed-off-by: Roger Pau Monné
>> ---
>> Changes since v2:
>>   - Add default value in xl.cfg.
>>   - List xenstore path in the pandoc file.
>>   - Adjust comment in hvmloader.
>>   - Fix commit message MIO -> MMIO.
>>
>> Changes since v1:
>>   - Leave the xenpci BAR as UC by default.
>>   - Introduce an option to not set it as UC.
>> ---
>>   docs/man/xl.cfg.5.pod.in                |  8 ++++
>>   docs/misc/xenstore-paths.pandoc         |  5 +++
>>   tools/firmware/hvmloader/config.h       |  2 +-
>>   tools/firmware/hvmloader/pci.c          | 49 ++++++++++++++++++++++++-
>>   tools/firmware/hvmloader/util.c         |  2 +-
>>   tools/include/libxl.h                   |  9 +++++
>>   tools/libs/light/libxl_create.c         |  1 +
>>   tools/libs/light/libxl_dom.c            |  9 +++++
>>   tools/libs/light/libxl_types.idl        |  1 +
>>   tools/xl/xl_parse.c                     |  2 +
>>   xen/include/public/hvm/hvm_xs_strings.h |  2 +
>>   11 files changed, 86 insertions(+), 4 deletions(-)
> I've noticed this is missing a changelog entry, I propose the
> following:
>
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index 1ee2f42e7405..23215a8cc1e6 100644
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -15,6 +15,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>    - On x86:
>      - Restrict the cache flushing done as a result of guest physical memory map
>        manipulations and memory type changes.
> +   - Allow controlling the MTRR cache attribute of the Xen PCI device BAR
> +     for HVM guests, to improve performance of guests using it to map the grant
> +     table or foreign memory.
>   
>   ### Added
>    - On x86:
>
> I can fold into the patch if Oleksii and others agree.

It would be nice: Reviewed-by: Oleksii Kurochko

Thanks.

~ Oleksii

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



  
    
  
  
    

    
    
    
    
    On 6/6/25 3:41 PM, Roger Pau Monné
      wrote:
    
    
    
    
    
      
    On Thu, Jun 05, 2025 at 06:16:59PM +0200, Roger Pau Monne wrote:

    
      
    
        
    The Xen PCI device (vendor ID 0x5853) exposed to x86 HVM guests doesn't
have the functionality of a traditional PCI device.  The exposed MMIO BAR
is used by some guests (including Linux) as a safe place to map foreign
memory, including the grant table itself.

Traditionally BARs from devices have the uncacheable (UC) cache attribute
from the MTRR, to ensure correct functionality of such devices.  hvmloader
mimics this behavior and sets the MTRR attributes of both the low and high
PCI MMIO windows (where BARs of PCI devices reside) as UC in MTRR.

This however causes performance issues for users of the Xen PCI device BAR,
as for the purposes of mapping remote memory there's no need to use the UC
attribute.  On Intel systems this is worked around by using iPAT, that
allows the hypervisor to force the effective cache attribute of a p2m entry
regardless of the guest PAT value.  AMD however doesn't have an equivalent
of iPAT, and guest PAT values are always considered.

Linux commit:

41925b105e34 xen: replace xen_remap() with memremap()

Attempted to mitigate this by forcing mappings of the grant-table to use
the write-back (WB) cache attribute.  However Linux memremap() takes MTRRs
into account to calculate which PAT type to use, and seeing the MTRR cache
attribute for the region being UC the PAT also ends up as UC, regardless of
the caller having requested WB.

As a workaround to allow current Linux to map the grant-table as WB using
memremap() introduce an xl.cfg option (xenpci_bar_uc=0) that can be used to
select whether the Xen PCI device BAR will have the UC attribute in MTRR.
Such workaround in hvmloader should also be paired with a fix for Linux so
it attempts to change the MTRR of the Xen PCI device BAR to WB by itself.

Overall, the long term solution would be to provide the guest with a safe
range in the guest physical address space where mappings to foreign pages
can be created.

Some vif throughput performance figures provided by Anthoine from a 8
vCPUs, 4GB of RAM HVM guest(s) running on AMD hardware:

Without this patch:
vm -> dom0: 1.1Gb/s
vm -> vm:   5.0Gb/s

With the patch:
vm -> dom0: 4.5Gb/s
vm -> vm:   7.0Gb/s

Reported-by: Anthoine Bourgeois <anthoine.bourgeois@vates.tech>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Changes since v2:
 - Add default value in xl.cfg.
 - List xenstore path in the pandoc file.
 - Adjust comment in hvmloader.
 - Fix commit message MIO -> MMIO.

Changes since v1:
 - Leave the xenpci BAR as UC by default.
 - Introduce an option to not set it as UC.
---
 docs/man/xl.cfg.5.pod.in                |  8 ++++
 docs/misc/xenstore-paths.pandoc         |  5 +++
 tools/firmware/hvmloader/config.h       |  2 +-
 tools/firmware/hvmloader/pci.c          | 49 ++++++++++++++++++++++++-
 tools/firmware/hvmloader/util.c         |  2 +-
 tools/include/libxl.h                   |  9 +++++
 tools/libs/light/libxl_create.c         |  1 +
 tools/libs/light/libxl_dom.c            |  9 +++++
 tools/libs/light/libxl_types.idl        |  1 +
 tools/xl/xl_parse.c                     |  2 +
 xen/include/public/hvm/hvm_xs_strings.h |  2 +
 11 files changed, 86 insertions(+), 4 deletions(-)

    
      
    
      
    I've noticed this is missing a changelog entry, I propose the
following:

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 1ee2f42e7405..23215a8cc1e6 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -15,6 +15,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
  - On x86:
    - Restrict the cache flushing done as a result of guest physical memory map
      manipulations and memory type changes.
+   - Allow controlling the MTRR cache attribute of the Xen PCI device BAR
+     for HVM guests, to improve performance of guests using it to map the grant
+     table or foreign memory.
 
 ### Added
  - On x86:

I can fold into the patch if Oleksii and others agree.
    
    
    
    
    It would be nice: Reviewed-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

Thanks.

~ Oleksii
    
  


--------------m5fI4O5tmeltvp3INcdWr9He--


From xen-devel-bounces@lists.xenproject.org Mon Jun 09 10:36:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jun 2025 10:36:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010222.1388384 (Exim 4.92)
	(envelope-from )
	id 1uOZrf-0003c0-Ud; Mon, 09 Jun 2025 10:36:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010222.1388384; Mon, 09 Jun 2025 10:36:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uOZrf-0003bt-RX; Mon, 09 Jun 2025 10:36:27 +0000
Received: by outflank-mailman (input) for mailman id 1010222;
 Mon, 09 Jun 2025 10:36:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uOZre-0003bn-Tg
 for xen-devel@lists.xenproject.org; Mon, 09 Jun 2025 10:36:26 +0000
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com
 [2a00:1450:4864:20::32d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9826337c-451d-11f0-a304-13f23c93f187;
 Mon, 09 Jun 2025 12:36:25 +0200 (CEST)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-45024721cbdso36018055e9.2
 for ; Mon, 09 Jun 2025 03:36:25 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-452730c7761sm103435165e9.32.2025.06.09.03.36.24
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 09 Jun 2025 03:36:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9826337c-451d-11f0-a304-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749465385; x=1750070185; 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=j2eSCMgOBkowmSy5gboI/K/V/rdKxTHVWcyzbMiQh4A=;
        b=oM7s+V4ZJlSOW4AmiN6JsvQTdD80gxz5Rz5uUuYTp3cPRtA7ZR1GoGbNcMzKuCw/CC
         mCWJQnpTXCg1vHhZWkGy5UT2tHCDv95MHIrzkipmvM9iMiEizFVK8E5WRYNn/108o5la
         aCBllwh4UAS6ODyZHp+wEXnCOmbwVAoCis/KA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749465385; x=1750070185;
        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=j2eSCMgOBkowmSy5gboI/K/V/rdKxTHVWcyzbMiQh4A=;
        b=jlJX4QaJ64o+gRfu0jP8W6JRs3g+ZTh8t15qIiesVn7ioWo0TfhUTO+oAYIviJPzEP
         zCjbDmSbC3UvgWF0bHdfQY0UqSVG4bma+mJSHTLLqhw/lWximm21xLVKffwURpHYRfal
         CvUzyAXU1UPTnD+dUKtMh54TSTOvR8tswUYrXCdnlPlssn2MfNvy2irVL8K54YnM0Ccr
         ZXaaO7slsgTdol5s2DmtHPraJlmVDmLlrH3EdobulJZ9Vkr74rfwjBL+O502l3D5w5CM
         xFMBLSIDKY4fDG10Y3TkhSsCTtFbgk6N1jmN66suRxRgRH3XmAmnmWuk/jB+JucvhyqI
         8unw==
X-Gm-Message-State: AOJu0YzXPSd+c+PsbQZ1AgBpnGjZLK/DniLgLMz5kqNCgTvmdkVrj4u0
	0juh1hS39JUl3QVH1MqKMWPTKQM2rb1QKFrk8lpYbx+bn7M6qo2iYtfw65MV3JyCb/Y=
X-Gm-Gg: ASbGnctsNac2Cupk7vxrIH9qfT4XG2JEdZ7B8ViApV2jp2hb6CbmGg7hZDxsh3KQNPm
	lGqEh5ur3Z4aOCN2iEB2Qytqns5lGcbxqZGdI3s9cQ0YwB/z/rJsNkPjOfwVqIN5QP0MEQ3YG20
	grVeFdSTncsULQo1xlqCQlH3EdkYO1EvXqflP6vFp7i1sqihj/D2TMcekmfRZhMf9ljF9N/F6SU
	8Cu9hmYlEIp9lgbg6lDRTJsOKiJDiyKKR+eOm3LTQYD7p7z4Sv31iyj/Q56y2PXNanZfNRU0fts
	EFZihfpBfW9A4PAS2auI15LlFl+rOK5uPyV42FAtjWbrXOIkyh5f+urxpsBaxulAU9BsPMLHrBY
	3jxbN7iPJp9QsH4o55RU=
X-Google-Smtp-Source: AGHT+IHvpfKTS/HWCq4Cz8Z0xH36vvgGE8cBtHcnKsYx7yrlcQkSfEWEZ3KYDu0g3vPvL9BPSebhFw==
X-Received: by 2002:a05:600c:1391:b0:442:e9eb:cba2 with SMTP id 5b1f17b1804b1-452012b351amr130545445e9.0.1749465385208;
        Mon, 09 Jun 2025 03:36:25 -0700 (PDT)
Date: Mon, 9 Jun 2025 12:36:23 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" ,
	Andrew Cooper , Wei Liu 
Subject: Re: [PATCH v2] x86/HVM: restrict use of pinned cache attributes as
 well as associated flushing
Message-ID: 
References: <78b3ddeb-4317-4d54-ad52-9eb03bdf7942@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <78b3ddeb-4317-4d54-ad52-9eb03bdf7942@suse.com>

On Wed, Jun 04, 2025 at 11:48:00AM +0200, Jan Beulich wrote:
> We don't permit use of uncachable memory types elsewhere unless a domain
> meets certain criteria. Enforce this also during registration of pinned
> cache attribute ranges.
> 
> Furthermore restrict cache flushing to just uncachable range registration.
> While there, also (mainly be calling memory_type_changed())
> - take CPU self-snoop as well as IOMMU snoop into account (albeit the
>   latter still is a global property rather than a per-domain one),
> - avoid flushes when the domain isn't running yet (which ought to be the
>   common case).
> 
> Reported-by: Andrew Cooper 
> Signed-off-by: Jan Beulich 
> ---
> At the expense of yet larger a diff it would be possible to get away
> without any "goto", by moving the whole "new entry" handling into the
> switch(). Personally I'd prefer that, but the larger diff may be
> unwelcome.
> 
> I have to admit that I can't spot what part of epte_get_entry_emt() the
> comment refers to that is being deleted. The function does use
> hvm_get_mem_pinned_cacheattr(), yes, but there's nothing there that talks
> about cache flushes (and their avoiding) in any way.
> 
> Is it really sensible to add/remove ranges once the guest is already
> running? (If it is, limiting the scope of the flush would be nice, but
> would require knowing dirtyness for the domain wrt the caches, which
> currently we don't track.)
> 
> This is kind of amending XSA-428.
> ---
> v2: Use memory_type_changed() and conditionalize call to
>     p2m_memory_type_changed().
> 
> --- a/xen/arch/x86/hvm/mtrr.c
> +++ b/xen/arch/x86/hvm/mtrr.c
> @@ -582,6 +582,7 @@ int hvm_set_mem_pinned_cacheattr(struct
>  {
>      struct hvm_mem_pinned_cacheattr_range *range, *newr;
>      unsigned int nr = 0;
> +    bool flush = false;
>      int rc = 1;
>  
>      if ( !is_hvm_domain(d) )
> @@ -605,31 +606,35 @@ int hvm_set_mem_pinned_cacheattr(struct
>  
>                  type = range->type;
>                  call_rcu(&range->rcu, free_pinned_cacheattr_entry);
> -                p2m_memory_type_changed(d);
>                  switch ( type )
>                  {
> -                case X86_MT_UCM:
> +                case X86_MT_WB:
> +                case X86_MT_WP:
> +                case X86_MT_WT:
>                      /*
> -                     * For EPT we can also avoid the flush in this case;
> -                     * see epte_get_entry_emt().
> +                     * Flush since we don't know what the cachability is going
> +                     * to be.
>                       */
> -                    if ( hap_enabled(d) && cpu_has_vmx )
> -                case X86_MT_UC:
> -                        break;
> -                    /* fall through */
> -                default:
> -                    flush_all(FLUSH_CACHE);
> +                    if ( is_iommu_enabled(d) || cache_flush_permitted(d) )
> +                        flush = true;

Is the check here required?  memory_type_changed() will already check
for is_iommu_enabled() and cache_flush_permitted(), and hence you
could just set flush to true unconditionally here IMO.

>                      break;
>                  }
> -                return 0;
> +                rc = 0;
> +                goto finish;
>              }
>          domain_unlock(d);
>          return -ENOENT;
>  
>      case X86_MT_UCM:
>      case X86_MT_UC:
> -    case X86_MT_WB:
>      case X86_MT_WC:
> +        /* Flush since we don't know what the cachability was. */
> +        if ( !is_iommu_enabled(d) && !cache_flush_permitted(d) )
> +            return -EPERM;
> +        flush = true;
> +        break;
> +
> +    case X86_MT_WB:
>      case X86_MT_WP:
>      case X86_MT_WT:
>          break;
> @@ -682,9 +687,11 @@ int hvm_set_mem_pinned_cacheattr(struct
>  
>      xfree(newr);
>  
> -    p2m_memory_type_changed(d);
> -    if ( type != X86_MT_WB )
> -        flush_all(FLUSH_CACHE);
> + finish:
> +    if ( flush )
> +        memory_type_changed(d);
> +    else if ( d->vcpu && d->vcpu[0] )
> +        p2m_memory_type_changed(d);

FWIW, I would just call memory_type_changed() unconditionally
regardless of the change.  We suspect the hypercall is only used at
domain creation time (where memory_type_changed() won't do a cache
flush anyway).

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Jun 09 10:40:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jun 2025 10:40:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010228.1388395 (Exim 4.92)
	(envelope-from )
	id 1uOZvm-00057D-D2; Mon, 09 Jun 2025 10:40:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010228.1388395; Mon, 09 Jun 2025 10:40:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uOZvm-000576-AC; Mon, 09 Jun 2025 10:40:42 +0000
Received: by outflank-mailman (input) for mailman id 1010228;
 Mon, 09 Jun 2025 10:40: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 1uOZvl-000570-H2
 for xen-devel@lists.xenproject.org; Mon, 09 Jun 2025 10:40:41 +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 2fdc70d5-451e-11f0-a304-13f23c93f187;
 Mon, 09 Jun 2025 12:40:40 +0200 (CEST)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-453066fad06so9635435e9.2
 for ; Mon, 09 Jun 2025 03:40:40 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a5323b67ccsm9261407f8f.40.2025.06.09.03.40.39
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 09 Jun 2025 03:40:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2fdc70d5-451e-11f0-a304-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749465640; x=1750070440; 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=y9vtwJwC4yXW/Zm9wPRw+HunVVWlInElqaYADj5QPK8=;
        b=b1zBpd1U1kVIb/nmYTsamgPin9OE2QfDYu7Uae9IdqGf3IR4pASEQ4Rn/6XYTUyzXc
         OTSFbCXmWT0AksF4HmIUwA7tYOIOhmT/H0SUzdsi7C04UMbOabyCm8PceiOapoYZDaio
         whMEKuAL7x4Y5uhPclxD9L2LgKdlB6SOEtOrY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749465640; x=1750070440;
        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=y9vtwJwC4yXW/Zm9wPRw+HunVVWlInElqaYADj5QPK8=;
        b=Pa2WcVbkNuSgruAVvyE7tY0ZXFTpYkreA8vvZ4L+cjdRVNfI1thlLxN4IWAflyUVXG
         4DbWyGGOoLL5klu63ERJDG8//LmPd/jQikmKp1/ysFa6kvQzcXfdLgFdQGRMuFSNgytn
         09FRwh4GVs4MhtI+WEbInMJDxD+D/3nl9BIV4LcKsPWh0tT8qrZNXyQQv5f+Z9ksG9Bm
         c7hwhVIM7Ye+zvkblGn/t/KwxknZL7L78l5TRdD6puGDPtT9vC7Ddt4UZpbJz6etGxkp
         pE9IlYg55mZkw9O/zRIyeNJbN1QaqKax8D73OKfch7SGAznYcPAjeKUhrA2wBexPMwBG
         FlXw==
X-Gm-Message-State: AOJu0YwDDkCTl5QpNvSwd7tfBckist8hDcDP+jChQmrfu4ukGRSbISkP
	rc52YLBVal5lFjxZ49KXkOXwbyunqx7D0oTe0qBDLmje2BdKGovHCA7GQxbbcZtSWVs=
X-Gm-Gg: ASbGncu39+eIUvEWIUTGeYCs3ppQiFRhB5Zd+FW20i8XUveCnUbgq5SFYHOOzeY8Ffj
	Luq/O8esx1pLlnrnyXR0skalT2fCgjJp/wvneEa8GuZw8cZgVBaBlC1WH9vu0Jdu04bamprrLJt
	R5LEq1s4MSkzw1cEr5JTDr7hJASroWOyrKDIwovc0gzzntgwMYNoW0r17EVZW1TmRnibMPS1Hw+
	AZcXeimYC6N5tnQQpQ3eoi0m+GK+S0crPWwjqIeGpT/PNxjbWe4u2xw3+srIW7XcU3/tRqXfwtT
	sOroClqC8zFy81OXYCTlBz0JYgX0tmu2An79odjq4+moPSZvaBCawx3rsXe9ba5IsNz6iBqQIzd
	yptfzZxoEOC+dGIz3hDE6gCSqL9hraQ==
X-Google-Smtp-Source: AGHT+IHvM9B3HX+yuAtRiC0fNa3herefi7/3fe9LYJAdv0rjnvbQVxfA75DBCIofg93xb8X2Q5DsDg==
X-Received: by 2002:a05:600c:4751:b0:453:c39:d0d0 with SMTP id 5b1f17b1804b1-4530c39d65fmr41804505e9.13.1749465639749;
        Mon, 09 Jun 2025 03:40:39 -0700 (PDT)
Date: Mon, 9 Jun 2025 12:40:38 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: "Chen, Jiqian" 
Cc: "xen-devel@lists.xenproject.org" ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	"Orzel, Michal" ,
	Julien Grall ,
	Stefano Stabellini ,
	"Huang, Ray" 
Subject: Re: [PATCH v5 04/10] vpci: Refactor REGISTER_VPCI_INIT
Message-ID: 
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
 <20250526094559.140423-5-Jiqian.Chen@amd.com>
 
 
 <752cff02-cef6-4a4c-80b9-eba3bbf9b264@suse.com>
 
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Mon, Jun 09, 2025 at 10:18:42AM +0000, Chen, Jiqian wrote:
> On 2025/6/9 17:29, Roger Pau Monné wrote:
> > On Mon, Jun 09, 2025 at 07:50:21AM +0000, Chen, Jiqian wrote:
> >> On 2025/6/6 17:14, Roger Pau Monné wrote:
> >>> On Fri, Jun 06, 2025 at 09:05:48AM +0200, Jan Beulich wrote:
> >>>> On 06.06.2025 08:29, Chen, Jiqian wrote:
> >>>>> On 2025/6/5 20:50, Roger Pau Monné wrote:
> >>>>>> On Mon, May 26, 2025 at 05:45:53PM +0800, Jiqian Chen wrote: 
> >>>>>>> +  }; \
> >>>>>>> +  static vpci_capability_t *const finit##_entry  \
> >>>>>>> +               __used_section(".data.vpci") = &finit##_t
> >>>>>>
> >>>>>> IMO this should better use .rodata instead of .data. 
> >>>>> Is below change correct?
> >>>>>
> >>>>> +    static const vpci_capability_t *const finit##_entry  \
> >>>>> +        __used_section(".rodata") = &finit##_t
> >>>>
> >>>> No, specifically because ...
> >>>>
> >>>>>> Not that it matters much in practice, as we place it in .rodata anyway.  Note
> >>>>>> however you will have to move the placement of the VPCI_ARRAY in the
> >>>>>> linker script ahead of *(.rodata.*), otherwise that section match will
> >>>>>> consume the vPCI data.
> >>>>> I am sorry, how to move it ahead of *(.rodata.*) ?
> >>>>> Is below change correct?
> >>>>>
> >>>>> diff --git a/xen/include/xen/xen.lds.h b/xen/include/xen/xen.lds.h
> >>>>> index 793d0e11450c..3817642135aa 100644
> >>>>> --- a/xen/include/xen/xen.lds.h
> >>>>> +++ b/xen/include/xen/xen.lds.h
> >>>>> @@ -188,7 +188,7 @@
> >>>>>  #define VPCI_ARRAY               \
> >>>>>         . = ALIGN(POINTER_ALIGN); \
> >>>>>         __start_vpci_array = .;   \
> >>>>> -       *(SORT(.data.vpci.*))     \
> >>>>> +       *(.rodata)             \
> >>>>
> >>>> ... this isn't - you'd move _all_ of .rodata into here, which definitely
> >>>> isn't what you want. What I understand Roger meant was a .rodata-like
> >>>> section, e.g. .rodata.vpci.* (much like it was .data.vpci.* before).
> >>>
> >>> Indeed, my suggestion was merely to use .rodata instead of .data, as
> >>> that's more accurate IMO.  I think it should be *(.rodata.vpci) (and
> >>> same section change for the __used_section() attribute.
> >>
> >> If I understand correctly, the next version will be:
> >>
> >> +    static const vpci_capability_t *const finit##_entry  \
> >> +        __used_section(".rodata.vpci") = &finit##_t
> >> +
> >>
> >> and
> >>
> >>  #define VPCI_ARRAY               \
> >>         . = ALIGN(POINTER_ALIGN); \
> >>         __start_vpci_array = .;   \
> >> -       *(SORT(.data.vpci.*))     \
> >> +       *(.rodata.vpci)           \
> >>         __end_vpci_array = .;
> > 
> > Did you also move the instances of VPCI_ARRAY in the linker scripts so
> > it's before the catch-all *(.rodata.*)?
> > 
> >>
> >> But, that encountered an warning when compiling.
> >> " {standard input}: Assembler messages:
> >> {standard input}:1160: Warning: setting incorrect section attributes for .rodata.vpci
> >> {standard input}: Assembler messages:
> >> {standard input}:3034: Warning: setting incorrect section attributes for .rodata.vpci
> >> {standard input}: Assembler messages:
> >> {standard input}:6686: Warning: setting incorrect section attributes for .rodata.vpci "
> > 
> > What are the attributes for .rodata.vpci in the object files?  You can
> > get those using objdump or readelf, for example:
> > 
> > $ objdump -h xen/drivers/vpci/msi.o
> > [...]
> >  17 .data.vpci.9  00000008  0000000000000000  0000000000000000  00000a50  2**3
> >                   CONTENTS, ALLOC, LOAD, RELOC, DATA
> > 
> > It should be READONLY, otherwise you will get those messages.
> > 
> >> And, during booting Xen, all value of __start_vpci_array is incorrect.
> >> Do I miss anything?
> > 
> > I think that's likely because you haven't moved the instance of
> > VPCI_ARRAY in the linker script?
> Oh, right. Sorry, I forgot to move it.
> After changing this, it works now.
> 
> diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
> index bf956b6c5fc0..c88fd62f4f0d 100644
> --- a/xen/arch/x86/xen.lds.S
> +++ b/xen/arch/x86/xen.lds.S
> @@ -134,6 +134,7 @@ SECTIONS
>         BUGFRAMES
> 
>         *(.rodata)
> +       VPCI_ARRAY
>         *(.rodata.*)
>         *(.data.rel.ro)
>         *(.data.rel.ro.*)
> @@ -148,7 +149,6 @@ SECTIONS
>         *(.note.gnu.build-id)
>         __note_gnu_build_id_end = .;
>  #endif
> -       VPCI_ARRAY
>    } PHDR(text)

FWIW, I would put it ahead of *(.rodata).  Remember to also modify the
linker script for all the other arches, not just x86.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Jun 09 10:44:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jun 2025 10:44:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010234.1388405 (Exim 4.92)
	(envelope-from )
	id 1uOZz2-0005jT-QB; Mon, 09 Jun 2025 10:44:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010234.1388405; Mon, 09 Jun 2025 10:44:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uOZz2-0005jM-NS; Mon, 09 Jun 2025 10:44:04 +0000
Received: by outflank-mailman (input) for mailman id 1010234;
 Mon, 09 Jun 2025 10:44:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uOZz1-0005jG-IE
 for xen-devel@lists.xenproject.org; Mon, 09 Jun 2025 10:44:03 +0000
Received: from NAM04-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam04on2062b.outbound.protection.outlook.com
 [2a01:111:f403:2409::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a4a45f0a-451e-11f0-a304-13f23c93f187;
 Mon, 09 Jun 2025 12:43:57 +0200 (CEST)
Received: from MW4PR12MB7334.namprd12.prod.outlook.com (2603:10b6:303:219::21)
 by IA0PR12MB8226.namprd12.prod.outlook.com (2603:10b6:208:403::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.36; Mon, 9 Jun
 2025 10:43:54 +0000
Received: from MW4PR12MB7334.namprd12.prod.outlook.com
 ([fe80::2e77:557:17d5:86f8]) by MW4PR12MB7334.namprd12.prod.outlook.com
 ([fe80::2e77:557:17d5:86f8%4]) with mapi id 15.20.8792.038; Mon, 9 Jun 2025
 10: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: a4a45f0a-451e-11f0-a304-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lMgWITPgC69v+FjjFS7yj2gB1+q1GfXDHmhE0YS+LztRXO+BIT3ax4Z16lBTEA5cHdxUKWlLd0UtpFEkJN99a8FBcvWg1jytBWRHRECge43p+ZZe9lj2nSRGWA/TahME6miaDEY4czRyeXWR+/LjD3jZeH5+Ee7koEbJEE0IL+s5l2F18Mzpuh4bbRhW7W4MxmxW1dmNKUuD/xkA1Jx0jQmsDN/+lBeX1zO7ubxhxl0Qn3YwxyRKjXdqE6YUhJw08u9QbkcP6ozwlft5474CCRKBEqjPCibKebg8zkA8QBz2OdKT2jZLATmh0h3AcxrEENJGt0QQcQuSQxYXN6MVZA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Y6LUEIsuq0nFx2TIOmQ5bupBDyKIWNqB15EzXC+qyIM=;
 b=roLXBB/pYfH8Vy1iTorwILDWajrdL5zhi581JzH2G9HZU2PfqCx5shzAHYlmARjHKENY2XGc4jJ3gAxRFart+l3FGsXw31oKHSfqOce7TPvnlYLuyoPihipBGK9UCVqFMz00R2+IJxtxxpFWbeJFYURl2ryI8F2GTDKwwfBxgXsPlMl2GStLU/QVzN42h6ZZH34yYMDrS2qxtvvxUGRhesiWLgh4B5onZvXr/VVlrV6vJguX9tpM1KU8iFfF+WarECgyPsHGrSc9AYvFy+WQ81JIAZlA9bPTWVQNNiZijxNs4iojGgea6BFtNJxPdYiS5Srtn+BDCa6ug2yYr1U/lg==
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=Y6LUEIsuq0nFx2TIOmQ5bupBDyKIWNqB15EzXC+qyIM=;
 b=Ty31gMcuptSbQ37j3BU7kWi9NGUpbAN50lYuIshzABiyWbpb+g8QQAeBuGnyGWiRdWK6JQfTg+y+O+gJHXulBkvhVxfN/h7NEGbrrn5NgeNEtSMyMmWqmoifjCtECMW6+MMX/6PHnXguU+PkpzCB6IEWjqIPZ2wetr9xPWjlOAE=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <55f6d0ca-e622-48b9-8e08-4cc7b7951bd8@amd.com>
Date: Mon, 9 Jun 2025 11:43:48 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/3] arm/mpu: Provide and populate MPU C data
 structures
Content-Language: en-GB
From: Ayan Kumar Halder 
To: Julien Grall , "Orzel, Michal" ,
 Ayan Kumar Halder , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250606164854.1551148-1-ayan.kumar.halder@amd.com>
 <20250606164854.1551148-3-ayan.kumar.halder@amd.com>
 
 
 
 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO2P265CA0184.GBRP265.PROD.OUTLOOK.COM
 (2603:10a6:600:a::28) To PH8PR12MB7326.namprd12.prod.outlook.com
 (2603:10b6:510:216::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MW4PR12MB7334:EE_|IA0PR12MB8226:EE_
X-MS-Office365-Filtering-Correlation-Id: 273d1cc6-60f5-4941-bbaa-08dda74286c7
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?Wk5rQTFNNEpaWXpjeUJyaTdtaGhKUERwWVUvaXo0MktXMGtWSC9UZ010MUR0?=
 =?utf-8?B?YWRpV1pUUVZkSlNMeUVQMnFGdmRBVEwrUFo2WEtVQkZia1pwRXFJRlhWNzFi?=
 =?utf-8?B?WjFLK1lKa0NtalRxcjZEL2JFSDVoQ3FkcTdkTm00WEl4WnIrYWdKWUd6eDhJ?=
 =?utf-8?B?UE9GMmZFdmdJR2hLOWJDSFUzTk1pTEF4bFdCWEJESGN6SDFEWHJnQm5yNW9W?=
 =?utf-8?B?ZkRMdU1vM2lOaUFoREFHM0g2VjBGS3RvTEtKdTVFNmR1dlQ0WXlWc1p1SkQr?=
 =?utf-8?B?Y1EyQnlONjVoaWY2SkxKb0lmcld0Y1htRnNmOW00LzVoVUhWbyt6WE12OWda?=
 =?utf-8?B?OHJCYUM0Wm8zK0grNGtPS1puYUVMcjVUVWU1Q3ZnTnZNWDcrMmV1QmNlNVpv?=
 =?utf-8?B?VC9sSUJkSkI3QUw3TnhqYkdFQzdwdG5iSG1EeXNQS2Vva240S3pmR3ByK3k0?=
 =?utf-8?B?anBCcnMxUUFCbkhNVHhGNlpRNWx0WGl3VDhrcWR3MjAxZFdsM216ZDZVM1kv?=
 =?utf-8?B?aGlJUWlMOXlHVXViRTJBWU0xdXF6bUMvQXRrOGp4YUJ5K05PbnFobzVCUVVE?=
 =?utf-8?B?VjdMYXA0TXE0eEkvQ2xNbmhjOHdjT1duRUU5eEEwTkE0cTJ0OEdYVlp4bGJo?=
 =?utf-8?B?VXlWbmRGTGdqVGtPN2xjTXIyR0hLVy8rZFdPQklBWkRmamxOdmNzdmE1YVp2?=
 =?utf-8?B?c2JLUFFCNTU0QlFPR1NNOGsramI0bE53N3AyV0hjclIrNGdmeHF0aFRjQTJ5?=
 =?utf-8?B?RkkrSXFUczhZbGo4L0gyT3JvUWorRnlaTVZlVG02WHFSRkVmcGRFRUV4cHZ4?=
 =?utf-8?B?ZmNXUkpOMEVEeHAzOC8ycGs1VzdXRDZhVFUwUjB6cXFBT3FwK3NuQVJibHBm?=
 =?utf-8?B?aGs0eXB0WUdLYnRZNnM1b0JIUHZROHRBR0JNcThZanBjdmxWb1p6OU53S2ts?=
 =?utf-8?B?NEs2SnZzbVY2cWw5a2hBN0paQjFIcmpOWmtVNWgrdGtCMXMrRlBCRWFWdlpj?=
 =?utf-8?B?TjJITmRVV1UxUGlvcUtsNkVLeHM3WUhzcFZsUEFLSk9uTjFoQVM3aTh0MW5X?=
 =?utf-8?B?Zk0xYW13eGk3ZUY2eHlpOUdaSHdNbjRRUDF5SU5nei9rUWJzVWJlWFZwVnNT?=
 =?utf-8?B?aFFLSitxYWs0S2pxUlhEalNJcHFwTGpQMk5mcWlyYXcxbXE2M2YvTzArMTBm?=
 =?utf-8?B?TTJaUC9GcGM5QVhSeCtUb2NaODBJVzU0UFlXcXkrYmRDM21wakZCYnRBVXda?=
 =?utf-8?B?UmJjUjVFRDNhRStBTS9tT1BUQ1R0NDJ5RlppUm1QbURGMzRkR2grZmZ6Um83?=
 =?utf-8?B?VXU4dklPSExkOGdhNXQxUllORFZxdWtIaFBENjZkMnpmeHNFNmtETmQ1UEpW?=
 =?utf-8?B?bjFjTFBwUVV3NkE3V0VPQTZRVU1pTDVReEphdTlhcHN5eW1QOWU3aVlsS0tL?=
 =?utf-8?B?eDR3aXZ2aGl0bStqaDlnNmN1VUhvd2JhYS9Td1RqZU9naVNUbCtpQmtndzB0?=
 =?utf-8?B?THp0MDhQbWFOUXBqTGlwTzJleHViZWZldEE0TlpnNHdNTWVlVGJ4Z2llK0NT?=
 =?utf-8?B?NFdKS0tweVRGYUg5RXBtR0hoeVJMWTQyV09pQktkSkxoaXFhWVJtSFcxOTFH?=
 =?utf-8?B?dWd3MjVNaFBLTVBrRmE2akJsTWF3MG84bDc1MlpITUtuK2FkVFVyNEsyOU56?=
 =?utf-8?B?NkVla1BWTS9Qb05VVXhoek9KaTh2YlF4UmhhZllSbklVR0hBVFdjSHc4QjBR?=
 =?utf-8?B?K0Q5c3NZc2RvWWg3Sk9OVGt3TDIyL3crU0RKVkpONGRmNTdUTEpCcmFxb2Nr?=
 =?utf-8?B?Q2dQcUo1ZVhnZFdoVldyRWJOUUNoQm91blV1Z2xEZkRsR0hyU1NGaHF6TWZQ?=
 =?utf-8?B?NWdEVjgwUHI4NHYwYituSUt6KzhFK2ZNZlFYa1hqNEN5SDlrNGtialdvOVMz?=
 =?utf-8?Q?7p5lqiOcSGU=3D?=
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)(366016)(1800799024)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?YTZYUkp1QkR0aTF4NXE3eVpsYVBQdURrU3l4aWYrTGJFQTI3dG5iTlRXMDBx?=
 =?utf-8?B?YnM0SmtwR0xQcytFV0J5RVIwdy9STjVLZG5YcVhOblQ0R2o4WDRBQWlNZFRx?=
 =?utf-8?B?VUd2d1Q4dzNiSUhyMHFUTWlHelZjKzR0UjdjTmR0R1VIZmlYUnNoWnRsNFVF?=
 =?utf-8?B?TERweTV5R3ZSMDN6OFJoc0dwZVdyZWFlc2ZvblAwYkxhdHJtVVNiWlk3UFBt?=
 =?utf-8?B?YW1SNkVJSzJyMWRMVTJ0a25hV2lNdU5raUh4REMrUWZkWVFGOWxuMVoxWitC?=
 =?utf-8?B?MXNaNERhNHV1QXdtWnB2djFzU005TTFkZUkyMUk4NnZQVEIydm5LZUxEWFRi?=
 =?utf-8?B?UW5hQU1OWi9Qb1gwc1hrVnJHcEdmNC9maWxpT0NyR2doN3V4OWIyU1Q3U3VX?=
 =?utf-8?B?VUVjeEJvNUZRZzFNR25OSmxobmk1MTIyRmg5VllQRjllZUFGdFljL2RjSzYr?=
 =?utf-8?B?UFBOVWdWeEdGNVN0TTE5c3ovdm1aTmJrTXBXUnM5N1hkZEI0VjdQZlNFOXJT?=
 =?utf-8?B?R2lzZEJDdTk1NVF2U1pZVUt0cEE1bVFCVWpWNllnWFBPZmpPSm1HcHlzcm9r?=
 =?utf-8?B?NGhBNStXMmJaTmxJbU94eDZZK2hnejVSREo1VDZ0WlMyYjF4akQ0cm1uTHJO?=
 =?utf-8?B?RCtTWXpNdERGQS9vTHBFb052T1VnOUlGRjRqSG1EbVhTNktjbVNzQmt2cDJ2?=
 =?utf-8?B?K0FJMkhzc2E3MFl5Y0xKNlVpVWRlampHaENWMHhZT2kwOGVwekJRMlJIWDZ5?=
 =?utf-8?B?VVBIVms4ZUlkZ2lwUHBPMGJUMHQxRjcyMytyaEFjN2dhNENKeW1uYnlSY0ZZ?=
 =?utf-8?B?cGd6WDFwaUdIWTc4eVZlTUFPcFZMRFZpM0hyeitsY0MrT05VeDVpblpVVVFq?=
 =?utf-8?B?QS9NclZRTTJmOTVjN1N0dXVycDIrWEZxTlRaRlNyVXR2clplL0lKTXpYbmk4?=
 =?utf-8?B?YmZsZVJIU2taQUdxSG5RL0NkUDVHUk1neXUvWC9xaTVFdUp0THpMWnVQdE1E?=
 =?utf-8?B?NU1LR0lCRnJKMlQ3OTZyN2tvYkVhcTN4czNQZHZML3h5MjdzSmkvWVB2YzJB?=
 =?utf-8?B?NEQrd1NzZWhmRVhNRERxaGRBZXZ1S3c4SkhFSHJUNEExVnY3T0hDYjZ5a2kv?=
 =?utf-8?B?UU1FZkJxT3dHUENhb3F4RVFWRUVBbFFCUzhETEd3NXNCZHA0VFkyckRMSlBK?=
 =?utf-8?B?bnNIbmVVTWJHTm1ZVndxWEFDaklQWkk3c2VodjMvaytaL3NpWDErSWpQUU4v?=
 =?utf-8?B?emVEVWNyamlhTW93VGdxNjM4dWZPak11RFJIVjYrSjRWZktWVFhFaVpjK0Rs?=
 =?utf-8?B?VndaRVloY24xb3BVOTNCT0V2Z1NuY0praUhFWk9aUzNvckVqSm5hMmZCSTh0?=
 =?utf-8?B?WVAxaERCTU13ZGd4UnJVUnAvTWFKcGxQVVVLbmZXMnlmY1pSRUZCT3R0Tkdu?=
 =?utf-8?B?OHJBTjRWaVRId0wwTjBpR25EZGZVZjdINjdBdTM0M01heDFOakFnVmIyZ3lR?=
 =?utf-8?B?eHZiRTN3eDFaK2JTNkpnK3JiTi9teWpQVDdXTDREYTVvU2gxeTVlWE5XaFUx?=
 =?utf-8?B?b1F2c05nNnV1NWtFUEVLUzRqa2Evd2NQRU1QbnBPVHpEUDkrOEdoeTF1Wm1F?=
 =?utf-8?B?QkI1amhwd1lwcGU2RWhEU0x6QWh2UXhHL1V6YUJMcGg2clpVanBsUHZZK0ly?=
 =?utf-8?B?NXpldXhpTXBxQkxQMG9Ta2hvbEY2c1BzQ1d4MHB3c1hBdDRndkFjczRnN0Zq?=
 =?utf-8?B?cUkrbEtjd1BQM0JnOTQ3MHNBSlQ5eStaTXdRQkpxcUNSbVlnUDJFY2R2ajc2?=
 =?utf-8?B?TXNRNTRTMVBiYkxLVnptZ0pOTjhGb2VUMFNORGRXRENveFdaN1h1NVRjblh6?=
 =?utf-8?B?aGYvREZjVEhMT1paQ21Uc1Rya1VyQmNhV3dXcHFjUTN5aUdFREo5OE1sQzlL?=
 =?utf-8?B?Snd2OUZBTXV3L2dMUmM5U2JENW1UenlVQU5nTjVWdERJM29XNzl6dGFkU1pw?=
 =?utf-8?B?ZHlBWnEzUnl1YVc2QTA0SzFCd29KYi9FWkdiZHhBUTdscWphQ1dpeDJ6ZG5k?=
 =?utf-8?B?NnJXL1BrOUcvVVYvZmgxMDVzUzBIQVo5MmVZL0ZNSk9kWWNUb2hVNW1EWHMz?=
 =?utf-8?Q?Jn457jMMaR2ARWjrWIavcvapx?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 273d1cc6-60f5-4941-bbaa-08dda74286c7
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jun 2025 10:43:53.8396
 (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: PI7UihS00y94T9UrubJimBpuaNYJZWiptybWjlVZ7pmDggpM3CdfcavCNfg84OqsWDasEe0tzUdk7VrKXwNYmA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB8226

Hi,

On 09/06/2025 10:16, Ayan Kumar Halder wrote:
>
> On 09/06/2025 09:42, Julien Grall wrote:
>> Hi Ayan,
> Hi Julien,
>>
>> On 09/06/2025 09:27, Ayan Kumar Halder wrote:
>>> On 09/06/2025 08:41, Orzel, Michal wrote:
>>>>> diff --git a/xen/arch/arm/include/asm/mpu/regions.inc 
>>>>> b/xen/arch/arm/ include/asm/mpu/regions.inc
>>>>> index 6b8c233e6c..631b0b2b86 100644
>>>>> --- a/xen/arch/arm/include/asm/mpu/regions.inc
>>>>> +++ b/xen/arch/arm/include/asm/mpu/regions.inc
>>>>> @@ -24,7 +24,7 @@
>>>>>   #define XEN_MPUMAP_ENTRY_SHIFT  0x3     /* 8 byte structure */
>>>>>   .macro store_pair reg1, reg2, dst
>>>>> -    .word 0xe7f000f0                    /* unimplemented */
>>>>> +    stm \dst, {\reg1, \reg2}  /* reg2 should be a higher register 
>>>>> than reg1 */
>>>> Didn't we agree not to use STM (I suggested it but then Julien 
>>>> pointed out that
>>>> it's use in macro might not be the best)?
>>>
>>> Ah my last response was not sent.
>>>
>>> I realized that I cannot use strd due to the following error
>>>
>>> Error: first transfer register must be even -- `strd r3,r4,[r1]'
>>
>> Ah I missed the "even" part when reading the specification. However, 
>> we control the set of registers, so we can't we follow the 
>> restriction? This would be better...
>
> I am ok to follow this. I just want to make sure that this looks ok to 
> you
>
> prepare_xen_region() invokes store_pair(). They are in common header.
>
> So we need to make the change wherever prepare_xen_region() is invoked 
> from arm32/mpu/head.S. This would look like
>
> --- a/xen/arch/arm/arm32/mpu/head.S
> +++ b/xen/arch/arm/arm32/mpu/head.S
> @@ -58,33 +58,33 @@ FUNC(enable_boot_cpu_mm)
>      /* Xen text section. */
>      mov_w   r1, _stext
>      mov_w   r2, _etext
> -    prepare_xen_region r0, r1, r2, r3, r4, r5, 
> attr_prbar=REGION_TEXT_PRBAR
> +    prepare_xen_region r0, r1, r2, r4, r3, r5, 
> attr_prbar=REGION_TEXT_PRBAR

My mistake, It should be

prepare_xen_region r0, r1, r2, r4, r5, r6, attr_prbar=REGION_TEXT_PRBAR

We will be clobbering an extra register.

- Ayan



From xen-devel-bounces@lists.xenproject.org Mon Jun 09 11:27:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jun 2025 11:27:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010247.1388419 (Exim 4.92)
	(envelope-from )
	id 1uOaed-0002rC-2z; Mon, 09 Jun 2025 11:27:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010247.1388419; Mon, 09 Jun 2025 11:27: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 1uOaed-0002r5-0P; Mon, 09 Jun 2025 11:27:03 +0000
Received: by outflank-mailman (input) for mailman id 1010247;
 Mon, 09 Jun 2025 11:27:01 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uOaea-0002qz-U5
 for xen-devel@lists.xenproject.org; Mon, 09 Jun 2025 11:27:00 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uOaea-00AEQV-0e;
 Mon, 09 Jun 2025 11:27:00 +0000
Received: from [2a02:8012:3a1:0:943c:2fd5:7003:a460]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uOaea-005xls-1K;
 Mon, 09 Jun 2025 11:27: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=O2liooQ06yWBmc9LWnWW0tojfD8Jo9oAzMjEmwbtEM4=; b=w3YeZ0DPg+TG3CFkutgUHwyyeP
	vsfDsdYLEXDmLPjzC67K6whiLvTF0As9MlySk+hclvhpJLh/PzDYU6ogeZHOZuSy4wCmrzUcf2974
	y+viA2eFkjl/SA+s+DqFNjbP3YcNqXIqR3O/WQbOle0gDWhXDK3q//bUs2Hp9yYYFUqg=;
Message-ID: <36471193-6b9f-4658-91c4-ec25dd784436@xen.org>
Date: Mon, 9 Jun 2025 12:26:58 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/3] arm/mpu: Provide and populate MPU C data
 structures
Content-Language: en-GB
To: Ayan Kumar Halder , "Orzel, Michal"
 , Ayan Kumar Halder ,
 xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250606164854.1551148-1-ayan.kumar.halder@amd.com>
 <20250606164854.1551148-3-ayan.kumar.halder@amd.com>
 
 
 
 
 <55f6d0ca-e622-48b9-8e08-4cc7b7951bd8@amd.com>
From: Julien Grall 
In-Reply-To: <55f6d0ca-e622-48b9-8e08-4cc7b7951bd8@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Ayan,

On 09/06/2025 11:43, Ayan Kumar Halder wrote:
> Hi,
> 
> On 09/06/2025 10:16, Ayan Kumar Halder wrote:
>>
>> On 09/06/2025 09:42, Julien Grall wrote:
>>> Hi Ayan,
>> Hi Julien,
>>>
>>> On 09/06/2025 09:27, Ayan Kumar Halder wrote:
>>>> On 09/06/2025 08:41, Orzel, Michal wrote:
>>>>>> diff --git a/xen/arch/arm/include/asm/mpu/regions.inc b/xen/arch/ 
>>>>>> arm/ include/asm/mpu/regions.inc
>>>>>> index 6b8c233e6c..631b0b2b86 100644
>>>>>> --- a/xen/arch/arm/include/asm/mpu/regions.inc
>>>>>> +++ b/xen/arch/arm/include/asm/mpu/regions.inc
>>>>>> @@ -24,7 +24,7 @@
>>>>>>   #define XEN_MPUMAP_ENTRY_SHIFT  0x3     /* 8 byte structure */
>>>>>>   .macro store_pair reg1, reg2, dst
>>>>>> -    .word 0xe7f000f0                    /* unimplemented */
>>>>>> +    stm \dst, {\reg1, \reg2}  /* reg2 should be a higher register 
>>>>>> than reg1 */
>>>>> Didn't we agree not to use STM (I suggested it but then Julien 
>>>>> pointed out that
>>>>> it's use in macro might not be the best)?
>>>>
>>>> Ah my last response was not sent.
>>>>
>>>> I realized that I cannot use strd due to the following error
>>>>
>>>> Error: first transfer register must be even -- `strd r3,r4,[r1]'
>>>
>>> Ah I missed the "even" part when reading the specification. However, 
>>> we control the set of registers, so we can't we follow the 
>>> restriction? This would be better...
>>
>> I am ok to follow this. I just want to make sure that this looks ok to 
>> you
>>
>> prepare_xen_region() invokes store_pair(). They are in common header.
>>
>> So we need to make the change wherever prepare_xen_region() is invoked 
>> from arm32/mpu/head.S. This would look like
>>
>> --- a/xen/arch/arm/arm32/mpu/head.S
>> +++ b/xen/arch/arm/arm32/mpu/head.S
>> @@ -58,33 +58,33 @@ FUNC(enable_boot_cpu_mm)
>>      /* Xen text section. */
>>      mov_w   r1, _stext
>>      mov_w   r2, _etext
>> -    prepare_xen_region r0, r1, r2, r3, r4, r5, 
>> attr_prbar=REGION_TEXT_PRBAR
>> +    prepare_xen_region r0, r1, r2, r4, r3, r5, 
>> attr_prbar=REGION_TEXT_PRBAR
> 
> My mistake, It should be
> 
> prepare_xen_region r0, r1, r2, r4, r5, r6, attr_prbar=REGION_TEXT_PRBAR
> 
> We will be clobbering an extra register.

Why can't we use r3 instead of r6?

 > So this would look a different different from its arm64 counterpart.

I don't see the problem with that. The code is not common. And TBH 
prepare_xen_region should never have been common ... but I will not 
re-open this discussion :).

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Mon Jun 09 16:24:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jun 2025 16:24:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010371.1388465 (Exim 4.92)
	(envelope-from )
	id 1uOfHm-00049f-LC; Mon, 09 Jun 2025 16:23:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010371.1388465; Mon, 09 Jun 2025 16: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 1uOfHm-00049N-Fy; Mon, 09 Jun 2025 16:23:46 +0000
Received: by outflank-mailman (input) for mailman id 1010371;
 Mon, 09 Jun 2025 16: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 1uOfHk-00049F-QJ
 for xen-devel@lists.xenproject.org; Mon, 09 Jun 2025 16:23:44 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20609.outbound.protection.outlook.com
 [2a01:111:f403:2412::609])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1b8ec54a-454e-11f0-a305-13f23c93f187;
 Mon, 09 Jun 2025 18:23:42 +0200 (CEST)
Received: from PH7PR13CA0009.namprd13.prod.outlook.com (2603:10b6:510:174::12)
 by CY8PR12MB8194.namprd12.prod.outlook.com (2603:10b6:930:76::5) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Mon, 9 Jun
 2025 16:23:38 +0000
Received: from CY4PEPF0000EDD1.namprd03.prod.outlook.com
 (2603:10b6:510:174:cafe::8c) by PH7PR13CA0009.outlook.office365.com
 (2603:10b6:510:174::12) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.16 via Frontend Transport; Mon,
 9 Jun 2025 16:23:37 +0000
Received: from SATLEXMB04.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.8835.15 via Frontend Transport; Mon, 9 Jun 2025 16:23:36 +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 Jun
 2025 11:23:35 -0500
Received: from [172.26.5.4] (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 Jun 2025 11:23:35 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1b8ec54a-454e-11f0-a305-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=K7Yj1Ckf3egST2uuWOLq8CZSPY1f/ZtFMafy+Pb7CZgyWRrUIQzMDTCmiwOe2Er9W/tzLftl++LoZzIOsEr3gD1VRurHgbiHv/E+PEJPikipGHXHGMJYqGnJpzvvcwh21KL9G0P/yGOz+608j8A9FJgp0X5tbmQUqeZzfA+DEqVfNJQQwHdpYpeEnBK0kn9c2SLujQCxtYvuZ8xJ69h8Y/6BB46bbRxqdrUupu9CMwjjqhaK81snySWm92oQh7Pld/Aql5v1wmeIE7NGRALUfuOiIhht6dqJadC8rJmplAfUoMyVt+bxe46/5VsQLNfVJ8ePqIGG2FaDgfk3Bns32A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=OcKmRqFt8oLg8mBdcRRYugFNOQ/9rjX9V8ESvpHMtFg=;
 b=MJetPmUt3TyrnCWujF3vELywx1pFfweu8rU9qUTBnVdgCVqwuzdjPnKe8OTdC5ox//VyVEb34we+MUjrT9SyU1hvifq0wiGhLSp9oHgmav02DgruyhMAKBRAcx7BS8KngcQqLmHQpQhgxKvc3Gg+dMh5iAAV0dTRNHdqeKMEKQh39jo/ytLNzrJKXzLoB/xkga6oWKVc/WsGOdvv84uOm5L96Y2c8eSSsAkncxI2B3n4e09SxqHkF1QJN8snENiIGK2UWHoxa2pdTigSQcSv815O43RDvkMyZIweAz9h3GqN3c15Ockp+9ZCFr8S7wEEFlKqRowg1/GJ4Pc+oTLtYA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=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=OcKmRqFt8oLg8mBdcRRYugFNOQ/9rjX9V8ESvpHMtFg=;
 b=1Ofv15DFw80694oJmoRvdgun+JXyADLw++108bMhXuWYFXwdLGc2gXzJHXnVy+y1wrarakgdF657lKDykD2kfoYS08Cpun/wcLS4VvdU5HIXPE8jpGnKFeX104qDF9Lm39rvzQjBPw+6549CUNU4Ud0zxgCsQsNrJeIwkdaFKy4=
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 Jun 2025 12:23:34 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/2] tools/arm: exclude iomem from domU extended
 regions
To: Anthony PERARD 
CC: , Anthony PERARD
	, Juergen Gross 
References: <20250513195452.699600-1-stewart.hildebrand@amd.com>
 <20250513195452.699600-3-stewart.hildebrand@amd.com> 
Content-Language: en-US
From: Stewart Hildebrand 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB04.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000EDD1:EE_|CY8PR12MB8194:EE_
X-MS-Office365-Filtering-Correlation-Id: 503832f6-62b6-4ea9-7a29-08dda771fc79
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?UmlhKzZOS3FTRXZLUlNuV2MyTk5RbzJLeFFQSXlnbk1GZFpuUVBhZ3JhTlg4?=
 =?utf-8?B?OFMySC9ETmNIb2RFSFRmNHpHdlBrUlY4WW5RblIzenMxb2xyQTg1Z0dzSm9C?=
 =?utf-8?B?MFNGdzBBWDlZVHpvWVlhZEtKM2pxbFc5OFRTcXREN0RXOWtRK21mL2xiZFVa?=
 =?utf-8?B?LytnenYxbkZnUWU5Vjd3cFlITVh5NnhSVHFnMnl1WjFyM28rWlBoSXZJbEta?=
 =?utf-8?B?V1ZRQ3Z5SVBUbE5WNFJxRFc1UjM4R3g0VHFmYXkzWkxtbEhPWVhKNjJiR0Vq?=
 =?utf-8?B?Vy9oVmJXMGhKQVZOYnlGcElDKzBLb2Z4eS85R2x1YmpDaDBXVjRVYlZHditI?=
 =?utf-8?B?NnhYMmt0MUhZcksrVDZ3WWxFMEFNaXFveW1wcGJYZ01YRFlVMEFwZFpIaERI?=
 =?utf-8?B?UUc0bVgyeFROWksvcytkWFNkZ3ZDMVlWSUZOVUFnRWk4UW9ZdHBnRkMvc1lZ?=
 =?utf-8?B?dkRDZW9va2NKQWRzVGZGbVBBNmwzNmJwZUU4ditDcEVHRmJHSUlwSDhYL25q?=
 =?utf-8?B?YWx2b3p2ekNUZzIzeCtnWDhLNXE3SSsvV3F6M0FPTW9QTExQRmJybjhuVzlQ?=
 =?utf-8?B?b29PU2kvckxNTGhrUXBTZW5lTG5yVndMVWhaN3g4N2liZ0pCN1pmeGM5ZDhW?=
 =?utf-8?B?TWcxUFB4TXpzVm1OQk5QUFhtZEZEVGJ5R0d0TEVUUTdLSkkxb1dRVXQ3dUg0?=
 =?utf-8?B?Y0RSMUVRSlZHWWNoNXhpTThSTVhhSk1IWDAyUURNM0hwSXdTWEFZdnBRN1ov?=
 =?utf-8?B?L1pVVU9BZS9nODdnekcvRVp2aFhoUW5kQ3pSK0FGMGN4NXFhUHd0bHplZGdK?=
 =?utf-8?B?eGplOWIvK3BHV2cvaTZuc1dsTW1xNUpZaU14blc2V2NPbzZKOTNhbGQ0ZXh6?=
 =?utf-8?B?L2txbHZNZW1ROUpjMk8vQkY2eFA0TkNBVzBTZUhBS2JleGdLSXVNZ3Y4Z09h?=
 =?utf-8?B?b2E2czQrNlhtOGNtMTF4L1pSSGtZY3p2c21UNUdvNDJEd002emUvZHJZL04x?=
 =?utf-8?B?d2lTZ2xYY2cwY29RSFR6SXIxL1Y2akF6YkN1MjdncWxDbXhzdzczanY0Y0gy?=
 =?utf-8?B?QUprbGhUYVNXTlZrS3F0dWRGbnJZVFQ1TjUxdEprbTQrK1BNdllFYjJCRFc0?=
 =?utf-8?B?bHB0cDZTVVZBSndTSDloMEN5V29RbVpCa25yZ3N5WlBZdDUrVWtiWkkvRlBv?=
 =?utf-8?B?RWQ0TVE0TUxvRysxblVjRXdSdGxiSjM2enc1WlFHc2RSNFFJL3JMeG5qaDVR?=
 =?utf-8?B?WjJ4Z1NjdEt3TndLQXhUcHJwUWxQcndZbjNDbHdkL0J3NllwTWQzN3hJSncx?=
 =?utf-8?B?Ky9UbmZwYWlscWNkZm9oTUpYTllmQ3I0Q3VtMWVuV1FETjZPTGZBK0N1MjJQ?=
 =?utf-8?B?cUFnL1JYeEJFanBha3I5c0gzcVpEaHhUa0RuVE8reEdyQ0t2K0REU3FybmlP?=
 =?utf-8?B?a3NuN0Q4a2oyN2ZSN2Z2cC9QcjVTY2s2SklkM0NLUzEyV0ZHZjEyNXA2TFZJ?=
 =?utf-8?B?Ylk2UjFtNFdtMG1jaUFoVlQ5ZUdJdU0xd2R2Sk5kZkdPZ1pOZlVGd1gyRG0x?=
 =?utf-8?B?UHlCOHNKSDErOTFvUGQyWUpZTmJoR2hFOXExT3E0T1RZUmNPNkxOMnl5cDhK?=
 =?utf-8?B?QXowZ0owQ25HVnBVaXZXbmxnU3ZIRldKQXdRTEpSTkUyK2xsSjBWQTBiV01j?=
 =?utf-8?B?VlRlQndPZTRGZ1FjaHVPbkpuek4rWk1KdmdPcGxRNmR2Y2xFa0JiZjVnMXhF?=
 =?utf-8?B?UHB5WHBJN0UyNDAzdTZ2Wi84eC9yV2pQeUFDUHNJblV4dnROaElyR1NqQnND?=
 =?utf-8?B?cmJiVmtHR2NMRlp3L25mdkxmVS92NUYweDFHWDlqalFvQm0zRXZoeWloZXJZ?=
 =?utf-8?B?bGNoV0Rybjl6eTdWdGllQnBRNVFQbEJoRndlRVYyc2t2ZWlUd3grWHY2L2N4?=
 =?utf-8?B?ajQ0TzlnUFh4a1lvTFAyMTB0dzJrY0Rja09ZTTA2NUllRFh5Sy82aDRaeG1a?=
 =?utf-8?B?SVlPUGJPbFp5amNVSXZhd1NkVDlpNE9TclFlRkdmN0RWVWJOcVRwRWc1U093?=
 =?utf-8?Q?Ck87ze?=
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: 09 Jun 2025 16:23:36.4400
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 503832f6-62b6-4ea9-7a29-08dda771fc79
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:
	CY4PEPF0000EDD1.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB8194

Thanks for taking a look!

On 5/26/25 07:40, Anthony PERARD wrote:
> On Tue, May 13, 2025 at 03:54:50PM -0400, Stewart Hildebrand wrote:
>> diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
>> index 75c811053c7c..8ae16a1726fc 100644
>> --- a/tools/libs/light/libxl_arm.c
>> +++ b/tools/libs/light/libxl_arm.c
>> @@ -1542,20 +1556,90 @@ static int finalize_hypervisor_node(libxl__gc *gc, struct xc_dom_image *dom)
>>      if (info.gpaddr_bits > 64)
>>          return ERROR_INVAL;
>>  
>> +    qsort(b_info->iomem, b_info->num_iomem, sizeof(libxl_iomem_range),
>> +          compare_iomem);
>> +
>>      /*
>>       * Try to allocate separate 2MB-aligned extended regions from the first
>>       * and second RAM banks taking into the account the maximum supported
>>       * guest physical address space size and the amount of memory assigned
>>       * to the guest.
>>       */
>> -    for (i = 0; i < GUEST_RAM_BANKS; i++) {
>> -        region_base[i] = bankbase[i] +
>> +    for (i = 0; i < GUEST_RAM_BANKS && nr_regions < MAX_NR_EXT_REGIONS; i++) {
>> +        struct {
>> +            uint64_t start;
>> +            uint64_t end; /* inclusive */
>> +        } unallocated;
>> +        uint64_t size = 0;
>> +
>> +        unallocated.start = bankbase[i] +
>>              ALIGN_UP_TO_2MB((uint64_t)dom->rambank_size[i] << XC_PAGE_SHIFT);
>>  
>> -        bankend[i] = ~0ULL >> (64 - info.gpaddr_bits);
>> -        bankend[i] = min(bankend[i], bankbase[i] + banksize[i] - 1);
>> -        if (bankend[i] > region_base[i])
>> -            region_size[i] = bankend[i] - region_base[i] + 1;
>> +        unallocated.end = ~0ULL >> (64 - info.gpaddr_bits);
>> +        unallocated.end = min(unallocated.end, bankbase[i] + banksize[i] - 1);
>> +
>> +        if (unallocated.end > unallocated.start)
>> +            size = unallocated.end - unallocated.start + 1;
>> +
>> +        if (size < EXT_REGION_MIN_SIZE)
>> +            continue;
>> +
>> +        /* Exclude iomem */
>> +        for (j = 0; j < b_info->num_iomem && nr_regions < MAX_NR_EXT_REGIONS;
>> +             j++) {
>> +            struct {
>> +                uint64_t start;
>> +                uint64_t end; /* inclusive */
>> +            } iomem;
>> +
>> +            iomem.start = b_info->iomem[j].gfn << XC_PAGE_SHIFT;
>> +            iomem.end = ((b_info->iomem[j].gfn + b_info->iomem[j].number)
>> +                         << XC_PAGE_SHIFT) - 1;
>> +
>> +            if (iomem.end >= unallocated.start
>> +                && iomem.start <= unallocated.end) {
>> +
>> +                if (iomem.start <= unallocated.start) {
>> +                    unallocated.start = iomem.end + 1;
>> +
>> +                    if (iomem.end >= unallocated.end)
>> +                        /* Complete overlap, discard unallocated region */
>> +                        break;
>> +
>> +                    /* Beginning overlap */
>> +                    continue;
> 
> Instead of a `continue` and a comment that I don't understand what it is
> supposed to mean, you could just do if-else:
> 
> if (iomem.start <= unallocated.start) {
>     // code before this continue
> } else { // we have: iomem.start > unallocated.start
>     // the block of code bellow.
> }

Yep, that makes sense, will do.

>> +                }
>> +
>> +                if (iomem.start > unallocated.start) {
>> +                    assert(unallocated.end > unallocated.start);
> 
> I think this assert should be removed.

OK

> Instead, you could check that this property hold true every time there's
> a modification to `unallocated.start` in this function.
> 
> Maybe one way to make the algo easier to read, and to check that this
> property is still true, is to rewrite:
> 
>     unallocated.start = iomem.end + 1;
>     if (iomem.end >= unallocated.end)
>         // discard `unallocated`
>         break;
> 
> with
> 
>     unallocated.start = iomem.end + 1;
>     if (unallocated.start > unallocated.end)
>         // obvious: all allocated already
>         break;
> 
> Because checking for:
>     iomem.end >= unallocated.end
> is the same as checking for:
>     iomem.end + 1 > unallocated.end
>     unallocated.start > unallocated.end

Ah, yes, this makes more sense. Will do, thanks.

>> +                    size = iomem.start - unallocated.start;
> 
> Isn't `size` the size of the unallocated region? Why is it recalculated
> with `iomem`? I think it would be better to create a new variable.

You're right, "size" is being used here for something different. I'll
create a new variable to better distinguish.

>> +
>> +                    if (size >= EXT_REGION_MIN_SIZE) {
>> +                        region_base[nr_regions] = unallocated.start;
>> +                        region_size[nr_regions] = size;
>> +                        nr_regions++;
>> +                    }
>> @@ -1565,16 +1649,12 @@ static int finalize_hypervisor_node(libxl__gc *gc, struct xc_dom_image *dom)
>>      set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
>>                GUEST_GNTTAB_BASE, GUEST_GNTTAB_SIZE);
>>  
>> -    for (i = 0; i < GUEST_RAM_BANKS; i++) {
>> -        if (region_size[i] < EXT_REGION_MIN_SIZE)
>> -            continue;
>> -
>> +    for (i = 0; i < nr_regions; i++) {
>>          LOG(DEBUG, "Extended region %u: %#"PRIx64"->%#"PRIx64"",
>> -            nr_regions, region_base[i], region_base[i] + region_size[i]);
>> +            i, region_base[i], region_base[i] + region_size[i]);
> 
> Shouldn't we print "base + size - 1" for the end address?

OK


From xen-devel-bounces@lists.xenproject.org Mon Jun 09 16:55:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jun 2025 16:55:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010377.1388476 (Exim 4.92)
	(envelope-from )
	id 1uOfmX-00081Z-20; Mon, 09 Jun 2025 16:55:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010377.1388476; Mon, 09 Jun 2025 16: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 1uOfmW-00081S-TJ; Mon, 09 Jun 2025 16:55:32 +0000
Received: by outflank-mailman (input) for mailman id 1010377;
 Mon, 09 Jun 2025 16: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 1uOfmW-00081M-55
 for xen-devel@lists.xenproject.org; Mon, 09 Jun 2025 16:55:32 +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 85872c0c-4552-11f0-b894-0df219b8e170;
 Mon, 09 Jun 2025 18:55:18 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 5E6B8A50654;
 Mon,  9 Jun 2025 16:55:17 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id ADA4EC4CEEB;
 Mon,  9 Jun 2025 16:55: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: 85872c0c-4552-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749488117;
	bh=5n2knWaj7T5mQNjtDLMXh7xAptfM3zcBKO+L5sCu4Dk=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=BEZyHBbuwTjJ2q/6bqECB/uZDiX8jvL4prEuSpmawSf8zWpk47zNyZlmXHFVmOevd
	 8/KdhmilLQKAKOL9wgVdKSsXU+bQLF/IaLN6IwaXFVbPI/xKx1IJg3QsJ60/KKRQk4
	 JxIl/rlZpaYxRLgw6ZmmoIcVRfUVAQFfOEUbUiVKQzSVHtpWCqJ9X2Dm4fNcmBIDOW
	 HfTh/17IFpeNvbqUaivTqpSqwlbf2e7hJjPkvteqGaOz2AkVwa2s+T53sXfyK/6MrV
	 739R29dNWWMuTkBBdOXfn2oOEb5wwPV1g9v84rJ/zHtRGGylJDn1eSChkrM+on5+yF
	 vm49NMP8QiFqA==
Date: Mon, 9 Jun 2025 09:55:14 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: Stefano Stabellini , 
    "Orzel, Michal" , xen-devel@lists.xenproject.org, 
    Julien Grall , Bertrand Marquis , 
    Volodymyr Babchuk , 
    "Daniel P. Smith" 
Subject: Re: [PATCH v2 08/15] xen/dt: Move bootfdt functions to
 xen/bootfdt.h
In-Reply-To: 
Message-ID: 
References: <20250605194810.2782031-1-agarciav@amd.com> <20250605194810.2782031-9-agarciav@amd.com> <633ffa7f-cf26-4ec3-a153-28404c39d882@amd.com>  
 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 9 Jun 2025, Alejandro Vallejo wrote:
> On Fri Jun 6, 2025 at 9:59 PM CEST, Stefano Stabellini wrote:
> > On Fri, 6 Jun 2025, Alejandro Vallejo wrote:
> >> On Fri Jun 6, 2025 at 10:59 AM CEST, Michal Orzel wrote:
> >> >
> >> >
> >> > On 05/06/2025 21:48, Alejandro Vallejo wrote:
> >> >> Part of an unpicking process to extract bootfdt contents independent of bootinfo
> >> >> to a separate file for x86 to take.
> >> >> 
> >> >> Move functions required for early FDT parsing from device_tree.h and arm's
> >> >> setup.h onto bootfdt.h
> >> >> 
> >> >> Declaration motion only. Not a functional change.
> >> >> 
> >> >> Signed-off-by: Alejandro Vallejo 
> >> >> ---
> >> >> v2:
> >> >>   * Remove the u32 identifiers in the device_tree_get_u32() implementation
> >> > I don't understand the reasoning behind changing u32->uint32_t only for one
> >> > function in this patch while leaving others unmodified. Also what about u64?
> >> > Either don't change any or change all.
> >> 
> >> Sure. Let's call the original u32->uint32_t change a misplaced mutation and
> >> move on. The point is the motion, not these cleanups on top.
> >
> > Yes I agree. I know from past experience that Jan doesn't mind changes
> > during code movements, but for me it is important that changes and code
> > movement are separate. That is because I have almost automatic ways to
> > check that code movement is correct if there are no changes. It saves me
> > a lot of time during review. Then I can look at the individual changes
> > separately.
> 
> That's interesting. Could you please share the runes? That's one side of
> review I still struggle with.

I use vim to generate two source files, one with the code corresponding
to the - lines (with the - prefix) and one with the code corresponding
to the + lines (without the + prefix). Then I diff the two files. This
method is a bit crude but very effective and managed to spot issues this
way more than once.


From xen-devel-bounces@lists.xenproject.org Mon Jun 09 16:56:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jun 2025 16:56:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010382.1388484 (Exim 4.92)
	(envelope-from )
	id 1uOfnP-0008VX-8N; Mon, 09 Jun 2025 16:56:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010382.1388484; Mon, 09 Jun 2025 16:56: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 1uOfnP-0008VQ-5L; Mon, 09 Jun 2025 16:56:27 +0000
Received: by outflank-mailman (input) for mailman id 1010382;
 Mon, 09 Jun 2025 16:56: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 1uOfnN-0008Tq-Ob
 for xen-devel@lists.xenproject.org; Mon, 09 Jun 2025 16:56:25 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ac46fafc-4552-11f0-b894-0df219b8e170;
 Mon, 09 Jun 2025 18:56:23 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 062366112A;
 Mon,  9 Jun 2025 16:56:22 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 32554C4CEEB;
 Mon,  9 Jun 2025 16:56: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: ac46fafc-4552-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749488181;
	bh=xrLmpQbdrRacqh+bV1YDE6GpYPGI/SN2lkmaZPUWqt8=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=eS7PGbrD9QyOVZvcqWDh9f8uBn2RbMJm2/Cd5dHtjPyq7RmJ+NnYRFziLRXRZbYsj
	 zg5oCHk0O9BEyn0Y18Q4yize74R3wRRd0M6bbEQGHjl8ITwWsbEeAb2o+/cGvxOCLn
	 HnRngJC0HHlLF+YTB7WkRaN8tlzyJBHFR5AT+NXvHSQqjxiwpC29chc5eBbECo5jsI
	 3bOsI9rJVe5nsc6L5l+Q7+4AiN9KzSY46MTXqCYPVyV0OTSUZAVdw6eClUWTjDi+Wf
	 +diuLySrg1dffvtz/TzmtcTVSMjCBpxVpbQWxk3CJL6hC68gM34Swo7Y7i5PFcf/xU
	 TMukV9NECcKtA==
Date: Mon, 9 Jun 2025 09:56:18 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: Stefano Stabellini , 
    xen-devel@lists.xenproject.org, Jan Beulich , 
    Andrew Cooper , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Julien Grall , Bertrand Marquis , 
    Michal Orzel , 
    "Daniel P. Smith" 
Subject: Re: [PATCH v2 07/15] x86: Replace boot_domain with bootdomain
In-Reply-To: 
Message-ID: 
References: <20250605194810.2782031-1-agarciav@amd.com> <20250605194810.2782031-8-agarciav@amd.com>  
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 9 Jun 2025, Alejandro Vallejo wrote:
> On Sat Jun 7, 2025 at 1:28 AM CEST, Stefano Stabellini wrote:
> > On Thu, 5 Jun 2025, Alejandro Vallejo wrote:
> >> No functional change intended.
> >> 
> >> Signed-off-by: Alejandro Vallejo 
> >> ---
> >> v2:
> >>   * Replaces the previous patch in which kernel_info replaced boot_domain
> >> ---
> >>  xen/arch/x86/dom0_build.c              |  2 +-
> >>  xen/arch/x86/hvm/dom0_build.c          |  6 ++---
> >>  xen/arch/x86/include/asm/boot-domain.h | 33 --------------------------
> >>  xen/arch/x86/include/asm/bootfdt.h     |  7 ++++++
> >>  xen/arch/x86/include/asm/bootinfo.h    |  3 +--
> >>  xen/arch/x86/include/asm/dom0_build.h  |  6 ++---
> >>  xen/arch/x86/include/asm/setup.h       |  4 ++--
> >>  xen/arch/x86/pv/dom0_build.c           |  6 ++---
> >>  xen/arch/x86/setup.c                   | 16 +++++++------
> >>  xen/include/xen/bootfdt.h              |  4 ++++
> >>  10 files changed, 33 insertions(+), 54 deletions(-)
> >>  delete mode 100644 xen/arch/x86/include/asm/boot-domain.h
> >> 
> >> diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
> >> index 0b467fd4a4..1c8c5140a3 100644
> >> --- a/xen/arch/x86/dom0_build.c
> >> +++ b/xen/arch/x86/dom0_build.c
> >> @@ -615,7 +615,7 @@ int __init dom0_setup_permissions(struct domain *d)
> >>      return rc;
> >>  }
> >>  
> >> -int __init construct_dom0(const struct boot_domain *bd)
> >> +int __init construct_dom0(const struct bootdomain *bd)
> >>  {
> >>      int rc;
> >>      const struct domain *d = bd->d;
> >> diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
> >> index 96410344a8..85c000b259 100644
> >> --- a/xen/arch/x86/hvm/dom0_build.c
> >> +++ b/xen/arch/x86/hvm/dom0_build.c
> >> @@ -644,11 +644,11 @@ static bool __init check_and_adjust_load_address(
> >>  }
> >>  
> >>  static int __init pvh_load_kernel(
> >> -    const struct boot_domain *bd, paddr_t *entry, paddr_t *start_info_addr)
> >> +    const struct bootdomain *bd, paddr_t *entry, paddr_t *start_info_addr)
> >>  {
> >>      struct domain *d = bd->d;
> >>      struct bootmodule *image = bd->kernel;
> >> -    struct bootmodule *initrd = bd->module;
> >> +    struct bootmodule *initrd = bd->initrd;
> >>      void *image_base = bootstrap_map_bm(image);
> >>      void *image_start = image_base + image->arch.headroom;
> >>      unsigned long image_len = image->size;
> >> @@ -1329,7 +1329,7 @@ static void __hwdom_init pvh_setup_mmcfg(struct domain *d)
> >>      }
> >>  }
> >>  
> >> -int __init dom0_construct_pvh(const struct boot_domain *bd)
> >> +int __init dom0_construct_pvh(const struct bootdomain *bd)
> >>  {
> >>      paddr_t entry, start_info;
> >>      struct domain *d = bd->d;
> >> diff --git a/xen/arch/x86/include/asm/boot-domain.h b/xen/arch/x86/include/asm/boot-domain.h
> >> deleted file mode 100644
> >> index 242e9c9c2b..0000000000
> >> --- a/xen/arch/x86/include/asm/boot-domain.h
> >> +++ /dev/null
> >> @@ -1,33 +0,0 @@
> >> -/* 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__
> >> -
> >> -#include 
> >> -
> >> -struct boot_domain {
> >> -    domid_t domid;
> >> -
> >> -    struct bootmodule *kernel;
> >> -    struct bootmodule *module;
> >> -    const char *cmdline;
> >> -
> >> -    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/bootfdt.h b/xen/arch/x86/include/asm/bootfdt.h
> >> index 2fc705a1cd..b30132381e 100644
> >> --- a/xen/arch/x86/include/asm/bootfdt.h
> >> +++ b/xen/arch/x86/include/asm/bootfdt.h
> >> @@ -4,6 +4,13 @@
> >>  
> >>  #include 
> >>  
> >> +#include 
> >> +
> >> +struct arch_bootdomain
> >> +{
> >> +    domid_t domid;
> >> +};
> >> +
> >>  struct arch_bootmodule
> >>  {
> >>      /*
> >> diff --git a/xen/arch/x86/include/asm/bootinfo.h b/xen/arch/x86/include/asm/bootinfo.h
> >> index f3210b7d6a..b8280ba357 100644
> >> --- a/xen/arch/x86/include/asm/bootinfo.h
> >> +++ b/xen/arch/x86/include/asm/bootinfo.h
> >> @@ -12,7 +12,6 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> -#include 
> >>  
> >>  /* Max number of boot modules a bootloader can provide in addition to Xen */
> >>  #define MAX_NR_BOOTMODS 63
> >> @@ -34,7 +33,7 @@ struct boot_info {
> >>  
> >>      unsigned int nr_modules;
> >>      struct bootmodule mods[MAX_NR_BOOTMODS + 1];
> >> -    struct boot_domain domains[MAX_NR_BOOTDOMS];
> >> +    struct bootdomain  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 ff021c24af..df03189870 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_domain;
> >> -int dom0_construct_pv(const struct boot_domain *bd);
> >> -int dom0_construct_pvh(const struct boot_domain *bd);
> >> +struct bootdomain;
> >> +int dom0_construct_pv(const struct bootdomain *bd);
> >> +int dom0_construct_pvh(const struct bootdomain *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 c7deaba109..a8647f0fdf 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_domain;
> >> -int construct_dom0(const struct boot_domain *bd);
> >> +struct bootdomain;
> >> +int construct_dom0(const struct bootdomain *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 e6c77413f5..a6f212fe0a 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(const struct boot_domain *bd)
> >> +static int __init dom0_construct(const struct bootdomain *bd)
> >>  {
> >>      unsigned int i;
> >>      int rc, order, machine;
> >> @@ -375,7 +375,7 @@ static int __init dom0_construct(const struct boot_domain *bd)
> >>      struct vcpu *v = d->vcpu[0];
> >>  
> >>      struct bootmodule *image = bd->kernel;
> >> -    struct bootmodule *initrd = bd->module;
> >> +    struct bootmodule *initrd = bd->initrd;
> >>      void *image_base;
> >>      unsigned long image_len;
> >>      void *image_start;
> >> @@ -1070,7 +1070,7 @@ out:
> >>      return rc;
> >>  }
> >>  
> >> -int __init dom0_construct_pv(const struct boot_domain *bd)
> >> +int __init dom0_construct_pv(const struct bootdomain *bd)
> >>  {
> >>      unsigned long cr4 = read_cr4();
> >>      int rc;
> >> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> >> index e9a70c2c2b..726adad0e5 100644
> >> --- a/xen/arch/x86/setup.c
> >> +++ b/xen/arch/x86/setup.c
> >> @@ -297,7 +297,9 @@ static const char *cmdline_cook(const char *p, const char *loader_name);
> >>  struct boot_info __initdata xen_boot_info = {
> >>      .loader = "unknown",
> >>      .cmdline = "",
> >> -    .domains = { [0 ... MAX_NR_BOOTDOMS - 1] = { .domid = DOMID_INVALID } },
> >> +    .domains = { [0 ... MAX_NR_BOOTDOMS - 1] = {
> >> +        .arch.domid = DOMID_INVALID
> >> +    }},
> >>      /*
> >>       * There's a MAX_NR_BOOTMODS-th entry in the array. It's not off by one.
> >>       *
> >> @@ -987,7 +989,7 @@ static unsigned int __init copy_bios_e820(struct e820entry *map, unsigned int li
> >>  }
> >>  
> >>  static size_t __init domain_cmdline_size(const struct boot_info *bi,
> >> -                                         const struct boot_domain *bd)
> >> +                                         const struct bootdomain *bd)
> >>  {
> >>      size_t s = bi->kextra ? strlen(bi->kextra) : 0;
> >>      const struct arch_bootmodule *abm = &bd->kernel->arch;
> >> @@ -1022,7 +1024,7 @@ 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 bootdomain *bd = &bi->domains[0];
> >>      struct domain *d;
> >>  
> >>      if ( opt_dom0_pvh )
> >> @@ -1039,11 +1041,11 @@ 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();
> >> -    d = domain_create(bd->domid, &dom0_cfg,
> >> +    bd->arch.domid = get_initial_domain_id();
> >> +    d = domain_create(bd->arch.domid, &dom0_cfg,
> >>                        pv_shim ? 0 : CDF_privileged | CDF_hardware);
> >>      if ( IS_ERR(d) )
> >> -        panic("Error creating d%u: %ld\n", bd->domid, PTR_ERR(d));
> >> +        panic("Error creating d%u: %ld\n", bd->arch.domid, PTR_ERR(d));
> >>  
> >>      init_dom0_cpuid_policy(d);
> >>  
> >> @@ -2162,7 +2164,7 @@ void asmlinkage __init noreturn __start_xen(void)
> >>      if ( initrdidx < MAX_NR_BOOTMODS )
> >>      {
> >>          bi->mods[initrdidx].kind = BOOTMOD_RAMDISK;
> >> -        bi->domains[0].module = &bi->mods[initrdidx];
> >> +        bi->domains[0].initrd = &bi->mods[initrdidx];
> >>          if ( first_boot_module_index(bi, BOOTMOD_UNKNOWN) < MAX_NR_BOOTMODS )
> >>              printk(XENLOG_WARNING
> >>                     "Multiple initrd candidates, picking module #%u\n",
> >> diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
> >> index e6d52a599f..19d2ff0f0c 100644
> >> --- a/xen/include/xen/bootfdt.h
> >> +++ b/xen/include/xen/bootfdt.h
> >> @@ -108,6 +108,10 @@ struct bootdomain {
> >>      struct bootmodule *initrd;
> >>  
> >>      const char* cmdline;
> >> +
> >> +#if __has_include()
> >> +    struct arch_bootdomain arch;
> >> +#endif
> >>  };
> >
> > One suggestion for improvement:
> 
> That would function today, but that field is important later on when we
> retrieve the domid from the DTB. That's where it's stored until we create them.

Oh OK. In that case please add a note to the commit message


> > diff --git a/xen/arch/x86/include/asm/bootfdt.h b/xen/arch/x86/include/asm/bootfdt.h
> > index b30132381e..892a0e2373 100644
> > --- a/xen/arch/x86/include/asm/bootfdt.h
> > +++ b/xen/arch/x86/include/asm/bootfdt.h
> > @@ -6,11 +6,6 @@
> >  
> >  #include 
> >  
> > -struct arch_bootdomain
> > -{
> > -    domid_t domid;
> > -};
> > -
> >  struct arch_bootmodule
> >  {
> >      /*
> > diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> > index 726adad0e5..39f294b88b 100644
> > --- a/xen/arch/x86/setup.c
> > +++ b/xen/arch/x86/setup.c
> > @@ -297,9 +297,6 @@ static const char *cmdline_cook(const char *p, const char *loader_name);
> >  struct boot_info __initdata xen_boot_info = {
> >      .loader = "unknown",
> >      .cmdline = "",
> > -    .domains = { [0 ... MAX_NR_BOOTDOMS - 1] = {
> > -        .arch.domid = DOMID_INVALID
> > -    }},
> >      /*
> >       * There's a MAX_NR_BOOTMODS-th entry in the array. It's not off by one.
> >       *
> > @@ -1026,6 +1023,7 @@ static struct domain *__init create_dom0(struct boot_info *bi)
> >      };
> >      struct bootdomain *bd = &bi->domains[0];
> >      struct domain *d;
> > +    domid_t domid;
> >  
> >      if ( opt_dom0_pvh )
> >      {
> > @@ -1041,11 +1039,11 @@ 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->arch.domid = get_initial_domain_id();
> > -    d = domain_create(bd->arch.domid, &dom0_cfg,
> > +    domid = get_initial_domain_id();
> > +    d = domain_create(domid, &dom0_cfg,
> >                        pv_shim ? 0 : CDF_privileged | CDF_hardware);
> >      if ( IS_ERR(d) )
> > -        panic("Error creating d%u: %ld\n", bd->arch.domid, PTR_ERR(d));
> > +        panic("Error creating d%u: %ld\n", domid, PTR_ERR(d));
> >  
> >      init_dom0_cpuid_policy(d);
> >  
> > diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
> > index 19d2ff0f0c..e6d52a599f 100644
> > --- a/xen/include/xen/bootfdt.h
> > +++ b/xen/include/xen/bootfdt.h
> > @@ -108,10 +108,6 @@ struct bootdomain {
> >      struct bootmodule *initrd;
> >  
> >      const char* cmdline;
> > -
> > -#if __has_include()
> > -    struct arch_bootdomain arch;
> > -#endif
> >  };
> >  
> >  /*
> 
> Cheers,
> Alejandro
> 


From xen-devel-bounces@lists.xenproject.org Mon Jun 09 17:07:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jun 2025 17:07:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010390.1388496 (Exim 4.92)
	(envelope-from )
	id 1uOfxu-0001sn-Aa; Mon, 09 Jun 2025 17:07:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010390.1388496; Mon, 09 Jun 2025 17:07: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 1uOfxu-0001sg-6V; Mon, 09 Jun 2025 17:07:18 +0000
Received: by outflank-mailman (input) for mailman id 1010390;
 Mon, 09 Jun 2025 17:07: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 1uOfxs-0001sa-F1
 for xen-devel@lists.xenproject.org; Mon, 09 Jun 2025 17:07:16 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20600.outbound.protection.outlook.com
 [2a01:111:f403:2418::600])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2de15980-4554-11f0-b894-0df219b8e170;
 Mon, 09 Jun 2025 19:07:11 +0200 (CEST)
Received: from SA0PR11CA0060.namprd11.prod.outlook.com (2603:10b6:806:d0::35)
 by SJ2PR12MB7799.namprd12.prod.outlook.com (2603:10b6:a03:4d3::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.35; Mon, 9 Jun
 2025 17:07:07 +0000
Received: from SN1PEPF0002BA4B.namprd03.prod.outlook.com
 (2603:10b6:806:d0:cafe::f6) 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.8655.35 via Frontend Transport; Mon,
 9 Jun 2025 17:07:07 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SN1PEPF0002BA4B.mail.protection.outlook.com (10.167.242.68) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Mon, 9 Jun 2025 17:07:05 +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, 9 Jun
 2025 12:07:05 -0500
Received: from [172.27.195.250] (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 Jun 2025 12:07:03 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2de15980-4554-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=OOEjeE4wyC5Q9+OVem0Gcu4VVCNa8VQP2EjdghM+yGZ2jUFSN/EdexcUKubVFBzKcvkm8PgAJ/kk6/mFJCw5Nipb6KV4cGNY5XehBRYDvJDzBecy+mm5Qs8Hn2FXlZkUzG8WzP/cANY07xnoRemVUPiHPuoqlJf8LJoFr7b0fqUG2QbxX0XsMfg+2IUIRv88hDigzAnb6TVedPNPBBZVZLpNnFFnDelwT1hQwEYpCQ2WoUCSB04+BL5jVHVMc5hVgjVNrIy3RMrfW5LZF84f7WFF9qr6igz+Dl3M5FJqqbAK/K9xsHtZ6m7SJO85LMvfZ6Ej9Eyrx/nWC0Ya2tfa/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=u5BSugR0vnffgsQIou3yc8PFf2hPaHLWN4mLggwndVw=;
 b=qtpHlN80zsjpVIgFyZrSqKQl7lVAlReWVUzCwAc/dmWgygF//QqIVim0k3/DCdRE119xlMKp0aMvKLNqtkBf8oHyQvaaI5OQWHVHXDRtCeF+5BA8VEAyYc3z8YALIAYAgLebzudVCHjf6DxfBueWx699Rt2qlkRqEt99EaVcMO2w9Ya4iwKzxPpgj1YJaQ/lCZJzn9HdlH8b7zveE8XCd53fjIRW7HBA5X9xjjMEesTm26m6M71WJa49gz8y6NqPnFuMMjnolL8HXNnR4Ito+tqnmvFOPpEAN2DqwHvCT3IphSutVyJxS8i3F5lubw0klCbgvgBQKgmkw5k8iXpAAg==
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=u5BSugR0vnffgsQIou3yc8PFf2hPaHLWN4mLggwndVw=;
 b=TFkB8HqD325GyhFA46OVM1jV21enSrWOR4/bw2M5Osjn4EtXR5zVP9OjTXjvtnX21BOFG8JO3XO5UHBZOfwrjyF2DfCDzkhGjbYNH/ubCkGonQj0CfoFP3WzGZso0KcYouwetEik/Reu6dH4OCioPvYsWa/+k2Cf7v9pZBbw8JM=
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: <59f37fcc-9226-46c5-8dc8-7bd2100d8f59@amd.com>
Date: Mon, 9 Jun 2025 13:07:35 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 06/12] x86/hyperlaunch: obtain cmdline from device tree
To: Alejandro Vallejo , 
CC: "Daniel P. Smith" , Jan Beulich
	, Andrew Cooper ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD
	, Michal Orzel , "Julien
 Grall" , Stefano Stabellini ,
	"Bertrand Marquis" , Denis Mukhin
	
References: <20250429123629.20839-1-agarciav@amd.com>
 <20250429123629.20839-7-agarciav@amd.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <20250429123629.20839-7-agarciav@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: SN1PEPF0002BA4B:EE_|SJ2PR12MB7799:EE_
X-MS-Office365-Filtering-Correlation-Id: 81ce83d1-4cd0-4565-e95b-08dda7780fcd
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700013|82310400026|376014|7416014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?SU00Y3pWb2hwRUJkaWtud3NlQmxmVUkyWW42VWpic0JJd2tsMU1HSmp3QXJa?=
 =?utf-8?B?S25uSnlwN2c5YmdBL2J5dDJGQnZ1T2JFcm1EQ1lTaFdCM3FJVTlIVHd2dUU3?=
 =?utf-8?B?dlVubFhacjZhVHhUbStTY3o2R3lFRTQ5UWZ1R3RscGc2TjNDR05QSGx4VWFi?=
 =?utf-8?B?Nm5FUExMc3FHUzFXckdkbmNQUGhncCszQTdoeXY2TEk4aU16d0dKNUU0Ymwx?=
 =?utf-8?B?Qi95N01MRW5JL2luNjhzSkdIbmlYeVdxU3Z2SVhzdVk2WlEvY1dFZy9mdGR2?=
 =?utf-8?B?KzBuL3M4aWJUYUF5cDR6Vk9rUHNqQlA1LzQycmMzUXMxWGYrZmFEb2FEUGJ4?=
 =?utf-8?B?QURGSXJWUU1tSTJXZFF4Z09GcElQNk5iUm1uZFZ4eENsUi8rcm5OT3JjMGU0?=
 =?utf-8?B?WjRlNjhrZjlFUUVMdDNZMTNvaHB4ZklUTnJORzJGN1MwRm1ORStNR2N2Zjdp?=
 =?utf-8?B?cVNOaEw4Q1I5UHdxN0F6R3JhR3NMd2FoZ0JrRnpONkxrVlhnUHVPbWswNjFi?=
 =?utf-8?B?c09GNTcwOFpHbFo0OTFIQzNaMEhCQ0pFMGVXYkpTcktuZCtPNnUreUJQQzdY?=
 =?utf-8?B?SFZFeDJ3NFAyL2QzOUZ5a0t0YUtOTVRrNUVzZ2ZKQWxZQUxVMC9ac3V1S2Z5?=
 =?utf-8?B?WWg0MlMzdkNtK2dSWDVTWEhTZFpjRG5IWlNxN2t0a05pM1RIRUc1U2xSRXQy?=
 =?utf-8?B?b3ZPQzV3WVVmK0NlSG42di83UWoxdXRBRU5ETUkyNjQydHFMOUYyWmRicDlh?=
 =?utf-8?B?QXZXeTlLdG0weWdoOWdJdjJxK0NZdFl5RXovU1VtZ2pXVmw3RzBuZE92WWV1?=
 =?utf-8?B?RENHMk9LQm1ydmhxSm5ud0dncXJyVExwTXIvSW42QndvcXU5RWowZlNBU3BZ?=
 =?utf-8?B?YVl0MnFrYnBoRlUyZEJKYzAwNHNzdzk3UFowMXBuYU9sTmZQb0hqWHUzY3hz?=
 =?utf-8?B?aEgrV3Vqa1JFazN6VG9lcXJheVlLSGlFRGMwN1JSN1ZTR0FjTGFpVkZjcWFo?=
 =?utf-8?B?UlFJOEhTbFM2c1ZEOWk3RnJGNGRXMWY5UUU5SG80YU9ubmZNTWswWUYvcks3?=
 =?utf-8?B?T2lSTzNDbllZVyszMmNtV1F3U2dmd2VwUEVmRVpCa2VzZnpQb0liOGw3Y0FM?=
 =?utf-8?B?THkzdUxKNHVpQmJ1UFNFYURVR3hMSnRUWm1XSHZLMFNhMXdBeDNYL1R6TGZo?=
 =?utf-8?B?VjE1ODg0dnhaa0grMmZPUTVNbkJDYjFJcnBSNlB6cFJiS0gvMEVRdGliakVE?=
 =?utf-8?B?bjR0blpqektCT2xQZkU3WE9wYUx3eDNJU0RITW92Z0VTQWc3K1I4L2dGNUtL?=
 =?utf-8?B?d2tGaHFsN2QzZ0VsT1ZmcmEvclZEYVBSTTlvbDlINnZQWlYyVHMrYXFqUDRT?=
 =?utf-8?B?ZitIbXRqUitjK3gzakdTSnJJbUR4WGI1OEdJVXVKZkN0TmYvME1SenJ1cm55?=
 =?utf-8?B?L054VllLaldKem1DT2piMkxMTjdWMENxd0o5M1AyeGxKV2x1eHNaTnBCUy91?=
 =?utf-8?B?TVZ1ck9Ra0ZsemdXTFZPNFZCandSQ2I1SGN4TGVCc2xIU1Q3UmRlemo1emRJ?=
 =?utf-8?B?OEdERklHQ0NpODRzTmF3TUtBd1hrMUwyS2RCblcvbUlxNFg3YzJJU0hPRVpl?=
 =?utf-8?B?RUpZZHRyWkFLWmF6cG1oaWlkZlNQVWtCQ0dqeGhaVDZnL1BGWDlMREx3cWhN?=
 =?utf-8?B?MW5ES28xSFhNWUNXWlcySlAzNFFxQ2FmZUZRR09UN0I3TG9kWG9xSnVXNVdz?=
 =?utf-8?B?WGZXOEpwYS9HbVFCSG1qcE1GZ3Y1VmNoRHhKQmRoa2t6YUh3OGU1ZGl6ZzRj?=
 =?utf-8?B?WkRhV012TGRJWDFsT0JrUzlHa2VxaVovTzAyYTNoM1RRZUZjNDRvM2cvNXFI?=
 =?utf-8?B?Ym0vak50RlNoZVJIRlZGbzh3ak10ZjhES1dzNkdrMG1zam41S204TldGK1VF?=
 =?utf-8?B?cU9kU3dtaXZUWDdkeWdwS21ySndIYUVwS3FEVW5wQ21jdFk1aUkrM0FXVW9r?=
 =?utf-8?B?RG0yZzFNd1RNWGQyUitDeTFwMzR5NEg1Snd5Z1dUbWo0STlLV3Q0ODdnOXBi?=
 =?utf-8?Q?czGlGz?=
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)(7416014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jun 2025 17:07:05.8349
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 81ce83d1-4cd0-4565-e95b-08dda7780fcd
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:
	SN1PEPF0002BA4B.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB7799

On 2025-04-29 08:36, Alejandro Vallejo wrote:
> From: "Daniel P. Smith" 
> 
> Add support to read the command line from the hyperlaunch device tree.
> The device tree command line is located in the "bootargs" property of the
> "multiboot,kernel" node.
> 
> A boot loader command line, e.g. a grub module string field, takes
> precendence over the device tree one since it is easier to modify.
> 
> Signed-off-by: Daniel P. Smith 
> Signed-off-by: Jason Andryuk 
> Signed-off-by: Alejandro Vallejo 
> Reviewed-by: Denis Mukhin 
> ---

> diff --git a/xen/common/domain-builder/fdt.c b/xen/common/domain-builder/fdt.c
> index cbb0ed30a2..dabe201b04 100644
> --- a/xen/common/domain-builder/fdt.c
> +++ b/xen/common/domain-builder/fdt.c
> @@ -219,6 +219,12 @@ static int __init fdt_process_domain_node(
>               printk(XENLOG_INFO "  kernel: multiboot-index=%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] )

The logic is incorrect - it should be:

             if ( !bd->kernel->cmdline_pa ||
                  !((char *)__va(bd->kernel->cmdline_pa))[0] )

If there is no cmdline_pa (which happens with the "reg" property) or the 
if there is a 0-length string, then check the DT for bootargs.

This fixes the "reg" case to read from bootargs.

> +                bd->kernel->fdt_cmdline = fdt_get_prop_offset(
> +                    fdt, node, "bootargs", &bd->kernel->cmdline_pa);
>           }
>       }
>   

Just giving a heads up in case anyone is using it.

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Mon Jun 09 18:35:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jun 2025 18:35:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010405.1388516 (Exim 4.92)
	(envelope-from )
	id 1uOhKm-0004W7-MM; Mon, 09 Jun 2025 18:35:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010405.1388516; Mon, 09 Jun 2025 18:35:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uOhKm-0004W0-IO; Mon, 09 Jun 2025 18:35:00 +0000
Received: by outflank-mailman (input) for mailman id 1010405;
 Mon, 09 Jun 2025 18:35: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 1uOhKm-0004Vd-6X
 for xen-devel@lists.xenproject.org; Mon, 09 Jun 2025 18:35:00 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20618.outbound.protection.outlook.com
 [2a01:111:f403:2009::618])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 707f2a5f-4560-11f0-b894-0df219b8e170;
 Mon, 09 Jun 2025 20:34:56 +0200 (CEST)
Received: from MN0PR04CA0012.namprd04.prod.outlook.com (2603:10b6:208:52d::31)
 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.8792.34; Mon, 9 Jun
 2025 18:34:51 +0000
Received: from BN1PEPF00006000.namprd05.prod.outlook.com
 (2603:10b6:208:52d:cafe::ff) by MN0PR04CA0012.outlook.office365.com
 (2603:10b6:208:52d::31) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.35 via Frontend Transport; Mon,
 9 Jun 2025 18:34:51 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BN1PEPF00006000.mail.protection.outlook.com (10.167.243.232) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Mon, 9 Jun 2025 18:34:50 +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, 9 Jun
 2025 13:34:50 -0500
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, 9 Jun
 2025 13:34:50 -0500
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; Mon, 9 Jun 2025 13:34:49 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 707f2a5f-4560-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=fxs3JEd6KzLI9ubbxdOirv1MJ0MsHlh8R+E+jAcbtPLQK3TPlbXIfS1lRHip2eFTLopc8IZZ5o+RYsG5ib88A2pu582r+oOAuzkTtvWMK1/ppY0w5sOSIVkZLvxEMBLwdTt+5hNekMfDsiDjWi7iCy0enhLM/5q2wZAqDfp/Bpwozxo3sfpeLBxaTN62ch+AJWrwgmTqweSWraK4peJvNE1FBf+CmW3r4bn7BZxYcXnUUGfEbm4xYmzeMGi8kAUiwh8c2JN+62a3N3DoSYa71czPsH8tmQMne30znoB8cN+bWvIkX9usAZNuq1cBFHaP9oq6yWdmpANc4rnlf9KYmw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=jy3/PnBlKCLoGe2ac+z/3nKSFm8cz+n19wqlfOIaulw=;
 b=l/2jsWLL88Wu18wHcq3ZkeQAzLOa+B9T9N9FLm8E9T5lR11t7QPIYHYcnsxwjqpBfDW8WciBktbJN2x8oMCoOOBIm52d7wCIGr9vixVH5a/cu3P3M9MON1rQgq6/i+aJsCba8YpJ/45KcHeFtr3PyHIDLX6sBfLtJXV7wrjnHgHqUE2ZKiYKIdsSIrcHf3fVVo4UUrRb/JSvIvCzgBLOd8mP+89+EsnLAxBFSj3Uj6mBnWsKXJc23vYFI2+uzqbUhJuDzkSfPd9zuJ0VFPV2tf438Xi37DSrNZBbUsv3OacZH2PwZfRgbaIcZNfJyC8jqKF7UC7UHTnNGsMsiNm90g==
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=jy3/PnBlKCLoGe2ac+z/3nKSFm8cz+n19wqlfOIaulw=;
 b=q7LkVMOSzCu+waenvQURiNTRbwzWYrSk6tAyPd5BXChil+Vpt+uChaur+0V7Dx93J7dXpU1vwaH/w30Q6kghd8Zqx4uwYpTmaRHkq8KEwz7qV5ekN+K0+K33UhGFEoi01liw0yVnJ02bIBbYxYC8dFSBeuqTR0RBH0xcub40O4A=
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 , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" 
Subject: [PATCH v4 1/2] xen/arm: exclude xen,reg from direct-map domU extended regions
Date: Mon, 9 Jun 2025 14:34:32 -0400
Message-ID: <20250609183438.178214-2-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250609183438.178214-1-stewart.hildebrand@amd.com>
References: <20250609183438.178214-1-stewart.hildebrand@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN1PEPF00006000:EE_|CYYPR12MB8990:EE_
X-MS-Office365-Filtering-Correlation-Id: df7a48ae-f14b-48e9-ff03-08dda7845207
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?BEEOXhoRAhyj9OZ/YtV36p/PlgI/nSS42RhC8aMqnSN9DjzwM0XjvncrVOKV?=
 =?us-ascii?Q?4WhM3N9Nbl5JcjbH2Wl7lfzWF0tVPE8kgc1Ag1nbLmtCoqMBeLCUDCJUxO+d?=
 =?us-ascii?Q?lPe+c5zIztYUr9+5++ekVLbthsDEjFIxRX7LLger/tdVAspKlA5Alqa6ZAnx?=
 =?us-ascii?Q?eXcI4llv1eDDJ9MWTZr12H1m/dDVy82YouozyonpWonRqgpceamAB59866rn?=
 =?us-ascii?Q?vD/bymLAF4/eOiKUBYXpapMwEf+CZdFXWQfWpfzq0GYtPu6c07y4FLujEZcZ?=
 =?us-ascii?Q?Zc/CTzvvhTPkCwFEHUB2WQnLc1b0wOOiI/lwKo88AqxxF0ycDJ/wQbs8j8Sm?=
 =?us-ascii?Q?HGtXRKuRo3wo/A02hTDuWob47BPf6FraCxnipFBbQs4gV5NGHTbB40Ox/tXY?=
 =?us-ascii?Q?0HEyoPth5Sx2a7vNDk2unjararlFL5l/PK8x/3h2/Z+8kRch2F3QS4Co1QxY?=
 =?us-ascii?Q?jta3EfXfvAl/DF9DL51BrnW5q+oaz9kJsom65ZNcJo1AMeu5B3tfWEZgsuT/?=
 =?us-ascii?Q?yJG0u0kR61wuomXr2tbHQCXe1Iympbd2fhy+4TR/L33U4EkXmPwqUCn8VpLO?=
 =?us-ascii?Q?uLm/JxTCi342zeS/w4Uj4QkdPtOF0NXwpsGRkD7w/o6/TzBqxiftQpb4OLfB?=
 =?us-ascii?Q?YlNYVlkxaOBc550bTAY1As9D8/vk5BG1KEssLoKZyGVA/Jpyq1PrLhOl46s2?=
 =?us-ascii?Q?Zzt+OVWNF8UyuwmUKRef4S2Z+L4YXWenJh1W5wNIpQCnV5OcixRLMne0q/99?=
 =?us-ascii?Q?pkesfvSGZTGHqYWCawD360FSSWz49TWX+zIc77R0CqXUy8IsLbyBCvkCHSu/?=
 =?us-ascii?Q?Rsd3jvUT2VHvzH2Eob3UEOeBvhlFppUqNbyVPMppItse4lFJNRjYzIAMXqOK?=
 =?us-ascii?Q?2+6Vk/Y+3q1N+uZ4dQswseA5n6NDT9EKhykxGYqHEaglQcV0CI5zBDEbhCA8?=
 =?us-ascii?Q?Rw+MDJcn6h5rrgwumpVnSBQa9zloAT3+bAc5mMf3D5jTbRsY0uxiLY0nXf/n?=
 =?us-ascii?Q?v+niyGJ0N6IqEeTKxxYih5m8nWzsMQOt17xUYJxw6RKqikv1EZoYxgAHZA/9?=
 =?us-ascii?Q?+7odKILSkN7PAb+Pdm3j8HsccMAvPW9/jlEdnh9TUwq4N0/RkjlsvoxA9vvK?=
 =?us-ascii?Q?xTIHx6ynZ5E/hgvZvzLlNPorUXUy/5jSa5ZDVyA7mMNDSVxFVvJihBsrpB+y?=
 =?us-ascii?Q?N69Q2tZ0erFjYZqjlqaznukWW9ORJLj83q1hwwoeEwbjj8SeOFE826hB6Kz/?=
 =?us-ascii?Q?14Ezn1RpFPMumWu4oJsS6CmwywC/Ih8rN95wxJEoVwsdoTW0dZXx3RpIBjWn?=
 =?us-ascii?Q?3MtYb6BDdpo/9P8ygG3g9a23N845RVp3cAqp81aUCWNCAp/kldu0P7e/g3K0?=
 =?us-ascii?Q?J4l64m0ci6xTkdJ5eV3u9v2uD+ur6qBdSK2NaVTpAJavRhTof0Hn7IOMHrEH?=
 =?us-ascii?Q?EauC9hSR3nA17xlqmsJHXS0WnVwsM0XpLUZm5ZUfXJyIJPp+m3nLYEAa1fWJ?=
 =?us-ascii?Q?ZvI7qgkBWBcGlzW53RVrJcIUjvmR7w78Re1q?=
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: 09 Jun 2025 18:34:50.9833
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: df7a48ae-f14b-48e9-ff03-08dda7845207
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:
	BN1PEPF00006000.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYYPR12MB8990

Similarly to fba1b0974dd8, when a device is passed through to a
direct-map dom0less domU, the xen,reg ranges may overlap with the
extended regions. Remove xen,reg from direct-map domU extended regions.

Take the opportunity to update the comment ahead of find_memory_holes().

Signed-off-by: Stewart Hildebrand 
---
v3->v4:
* conditionally allocate xen_reg
* use rangeset_report_ranges()
* make find_unallocated_memory() cope with NULL entry

v2->v3:
* new patch
---
 xen/arch/arm/domain_build.c           | 77 +++++++++++++++++++++++++--
 xen/common/device-tree/domain-build.c |  5 ++
 2 files changed, 77 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 590f38e52053..6632191cf602 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -792,15 +792,17 @@ static int __init handle_pci_range(const struct dt_device_node *dev,
 }
 
 /*
- * Find the holes in the Host DT which can be exposed to Dom0 as extended
- * regions for the special memory mappings. In order to calculate regions
- * we exclude every addressable memory region described by "reg" and "ranges"
- * properties from the maximum possible addressable physical memory range:
+ * Find the holes in the Host DT which can be exposed to Dom0 or a direct-map
+ * domU as extended regions for the special memory mappings. In order to
+ * calculate regions we exclude every addressable memory region described by
+ * "reg" and "ranges" properties from the maximum possible addressable physical
+ * memory range:
  * - MMIO
  * - Host RAM
  * - PCI aperture
  * - Static shared memory regions, which are described by special property
  *   "xen,shared-mem"
+ * - xen,reg mappings
  */
 static int __init find_memory_holes(const struct kernel_info *kinfo,
                                     struct membanks *ext_regions)
@@ -882,6 +884,13 @@ static int __init find_memory_holes(const struct kernel_info *kinfo,
         }
     }
 
+    if ( kinfo->xen_reg_assigned )
+    {
+        res = rangeset_subtract(mem_holes, kinfo->xen_reg_assigned);
+        if ( res )
+            goto out;
+    }
+
     start = 0;
     end = (1ULL << p2m_ipa_bits) - 1;
     res = rangeset_report_ranges(mem_holes, PFN_DOWN(start), PFN_DOWN(end),
@@ -962,11 +971,48 @@ static int __init find_domU_holes(const struct kernel_info *kinfo,
     return res;
 }
 
+static int __init count(unsigned long s, unsigned long e, void *data)
+{
+    unsigned int *cnt = data;
+
+    (*cnt)++;
+
+    return 0;
+}
+
+static int __init rangeset_to_membank(unsigned long s_gfn, unsigned long e_gfn,
+                                      void *data)
+{
+    struct membanks *membank = data;
+    paddr_t s = pfn_to_paddr(s_gfn);
+    paddr_t e = pfn_to_paddr(e_gfn + 1) - 1;
+
+    if ( membank->nr_banks >= membank->max_banks )
+        return 0;
+
+    membank->bank[membank->nr_banks].start = s;
+    membank->bank[membank->nr_banks].size = e - s + 1;
+    membank->nr_banks++;
+
+    return 0;
+}
+
 static int __init find_host_extended_regions(const struct kernel_info *kinfo,
                                              struct membanks *ext_regions)
 {
     int res;
     struct membanks *gnttab = membanks_xzalloc(1, MEMORY);
+    struct membanks *xen_reg =
+        kinfo->xen_reg_assigned
+        ? ({
+            unsigned int xen_reg_cnt = 0;
+
+            rangeset_report_ranges(kinfo->xen_reg_assigned, 0,
+                                   PFN_DOWN((1ULL << p2m_ipa_bits) - 1), count,
+                                   &xen_reg_cnt);
+            membanks_xzalloc(xen_reg_cnt, MEMORY);
+          })
+        : NULL;
 
     /*
      * Exclude the following regions:
@@ -974,6 +1020,7 @@ static int __init find_host_extended_regions(const struct kernel_info *kinfo,
      * 2) Remove reserved memory
      * 3) Grant table assigned to domain
      * 4) Remove static shared memory (when the feature is enabled)
+     * 5) Remove xen,reg
      */
     const struct membanks *mem_banks[] = {
         kernel_info_get_mem_const(kinfo),
@@ -982,12 +1029,29 @@ static int __init find_host_extended_regions(const struct kernel_info *kinfo,
 #ifdef CONFIG_STATIC_SHM
         bootinfo_get_shmem(),
 #endif
+        xen_reg,
     };
 
     dt_dprintk("Find unallocated memory for extended regions\n");
 
     if ( !gnttab )
-        return -ENOMEM;
+    {
+        res = -ENOMEM;
+        goto out;
+    }
+
+    if ( kinfo->xen_reg_assigned )
+    {
+        if ( !xen_reg )
+        {
+            res = -ENOMEM;
+            goto out;
+        }
+
+        rangeset_report_ranges(kinfo->xen_reg_assigned, 0,
+                               PFN_DOWN((1ULL << p2m_ipa_bits) - 1),
+                               rangeset_to_membank, xen_reg);
+    }
 
     gnttab->nr_banks = 1;
     gnttab->bank[0].start = kinfo->gnttab_start;
@@ -995,6 +1059,9 @@ static int __init find_host_extended_regions(const struct kernel_info *kinfo,
 
     res = find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_banks),
                                   ext_regions, add_ext_regions);
+
+ out:
+    xfree(xen_reg);
     xfree(gnttab);
 
     return res;
diff --git a/xen/common/device-tree/domain-build.c b/xen/common/device-tree/domain-build.c
index 6b8b8d7cacb6..99ea81198a76 100644
--- a/xen/common/device-tree/domain-build.c
+++ b/xen/common/device-tree/domain-build.c
@@ -193,6 +193,10 @@ int __init find_unallocated_memory(const struct kernel_info *kinfo,
 
     /* Remove all regions listed in mem_banks */
     for ( i = 0; i < nr_mem_banks; i++ )
+    {
+        if ( !mem_banks[i] )
+            continue;
+
         for ( j = 0; j < mem_banks[i]->nr_banks; j++ )
         {
             start = mem_banks[i]->bank[j].start;
@@ -212,6 +216,7 @@ int __init find_unallocated_memory(const struct kernel_info *kinfo,
                 goto out;
             }
         }
+    }
 
     start = 0;
     end = (1ULL << p2m_ipa_bits) - 1;
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Mon Jun 09 18:35:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jun 2025 18:35:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010404.1388505 (Exim 4.92)
	(envelope-from )
	id 1uOhKe-0004HI-Bs; Mon, 09 Jun 2025 18:34:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010404.1388505; Mon, 09 Jun 2025 18:34:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uOhKe-0004HB-8t; Mon, 09 Jun 2025 18:34:52 +0000
Received: by outflank-mailman (input) for mailman id 1010404;
 Mon, 09 Jun 2025 18:34: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 1uOhKc-0004H5-G8
 for xen-devel@lists.xenproject.org; Mon, 09 Jun 2025 18:34:50 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on2061a.outbound.protection.outlook.com
 [2a01:111:f403:2412::61a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6b8d3b70-4560-11f0-a305-13f23c93f187;
 Mon, 09 Jun 2025 20:34:48 +0200 (CEST)
Received: from MW4PR03CA0358.namprd03.prod.outlook.com (2603:10b6:303:dc::33)
 by DM6PR12MB4356.namprd12.prod.outlook.com (2603:10b6:5:2aa::8) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.36; Mon, 9 Jun
 2025 18:34:44 +0000
Received: from CO1PEPF000066E9.namprd05.prod.outlook.com
 (2603:10b6:303:dc:cafe::a) by MW4PR03CA0358.outlook.office365.com
 (2603:10b6:303:dc::33) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Mon,
 9 Jun 2025 18:34:43 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CO1PEPF000066E9.mail.protection.outlook.com (10.167.249.11) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Mon, 9 Jun 2025 18:34:43 +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 Jun
 2025 13:34:42 -0500
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; Mon, 9 Jun 2025 13:34:41 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6b8d3b70-4560-11f0-a305-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=JnyUJuqB+++2Q5Kh1ZM+HXFTXR7m7OWcwNM77gZ/uZ5iR+kjbOFRuXAXfFN/n6smcW2hIAkSLT2simVRSVDSAvR4ma+s8KZKASkO8HXCgkylFqetvPNXVKKv7DmtgfksW//3LXUjLqLTPHk451L3AO6uycfO53hQzzKCO6JgqErdF+l1EepT74GQorXqvaVXktZBJRZIaMdRnQAQZDy4Eb4d0WPHiPqZRtuWPx5QMv6BfkTCyv7g8d7sZf8VZMZotQjOhVNzGXF9bJ/0QaZNEj6W8PMMS0v3NKLy0IHNZncY1hRBrgBA7mjiyz4FToBIPehs6fNFFGkD2E5maVz5OQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=fL1f4/8f25nFmIj75IpfJ3ScV+q0xaoS4/WYxH/aDGg=;
 b=bU0Wi5VTKTJNW/6M89xkPxpHE8pbwdANEASdCf9z/wMqRpYHUYT80XHVJNIN35mKkcRMdKGuihvaDHBN7W0+AroFCzQfR0oRsMY5Cn3ki1rDXseJmpHkLdMd+NKEND92mp7ppSndhDL5BOjKEABq8W1a6/cKvtDFaHlbxqngrvegYyEShi5JQw1LXfAfEgkfbtMd3az0IdOozqEoEsIbBxpsJ7K4nKoI478LHzsTgl4nqZcbllGGdsur3GQaKAitOCz3YJoaHLJg2K30fCQf1xk+I1Xcpq199HYsp2Oh01yvuyMDl5HgYqDlCNmAgDWOBxF5i8rmDFf8UI1ioc9tuw==
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=fL1f4/8f25nFmIj75IpfJ3ScV+q0xaoS4/WYxH/aDGg=;
 b=fA03eioRCyj2srIHwlVanuVDdGCT05Cahuq4XaGcNOvB6IXxOBwMtELrfymOIsOCa9/Y0TFveXkfOdBD8BkwpmUuE7cEuZpGEMPVc35SY9LovXgIiAqz3ZIn4juAZwXN9FY0XClUN1JrnKVoPdU1Y9qsCRKatbPyCIVXZsN6kx8=
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: Stewart Hildebrand 
To: 
CC: Stewart Hildebrand , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , Anthony PERARD
	, Juergen Gross 
Subject: [PATCH v4 0/2] arm: extended regions fixes
Date: Mon, 9 Jun 2025 14:34:31 -0400
Message-ID: <20250609183438.178214-1-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB04.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PEPF000066E9:EE_|DM6PR12MB4356:EE_
X-MS-Office365-Filtering-Correlation-Id: 72adae3a-1596-458c-3284-08dda7844d68
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?3n8nElrbcOvqTMnWGjyQx+h7fWYGnZFcPyPKk9mmWNcUSiJaSnahPg28Gzps?=
 =?us-ascii?Q?re7mosp3+DQibxktSm8nELmPa49NE2AkkDqQxfGnQYLsutzWbQFhiErSQuXf?=
 =?us-ascii?Q?lxyaE8B48Mo1yha0GLgYgaCcRGFDOiUiWEgzF6eZA0sqVoYRpWBejj5W/DxD?=
 =?us-ascii?Q?L+e9HOeB9w4s2YlmzzLHroGnBo3+e7sTRp9tqWU1Uhv8vMfKvmd5TQs4I8FH?=
 =?us-ascii?Q?xw3WBq1/qtI98iIeSJxW4WZjQEy9Pvb7ahh8EvolmMX/a1FnMCMA0BoVwZ5v?=
 =?us-ascii?Q?uY/2NGnjwqqo8RCzZpaMHB/dAa/xtrpv0Q7gNdbsmLG2dh7ftQePDfrygtHk?=
 =?us-ascii?Q?+DGPvzPy/ZBp6BoxzopFjTDCSj2qVHeihNz7XmPVldZzbFdTWA7fHUNvOBmQ?=
 =?us-ascii?Q?YAh7Oew6F7Bizw8WUZI1AeBcRaPWUyFUQ+TAsR0/FHrVCJQOvNAwGBsrJq7y?=
 =?us-ascii?Q?hivplh5E5H8kaQh5OEoVMz/k2uXZdYBFk4tgIughlPdcQysJM3U5uDMFY3mF?=
 =?us-ascii?Q?QiH7lIigGh2+QqWWgNLqPrzskJDto8iWrrNtawSI7cmxo1gln6wSD/dL1zlS?=
 =?us-ascii?Q?Tf1QKMirSNKivk6YdqLzdDw0VtBnE4OsFqQG0ZmSPAKaR4QAbDAcXQVM2fVJ?=
 =?us-ascii?Q?Jb1v3EGkhEmNftxdrb56RqTQYTzmGBb1dRGFprcD+VpUHVGu7j/BYpfEt/5r?=
 =?us-ascii?Q?kb9FRHO8I6p+NiiiYoQmFvREtgwDV/cJv4YkoG0xUHNuRAXTeHNuIb+zNJmc?=
 =?us-ascii?Q?21p00tGj8ItRtuDF+8woWETCgbYkdewinYn2C6GJxPQCkJJ7vQMy1cBiBnTT?=
 =?us-ascii?Q?Fz0z/39bzxDDCMK1OIX3bTlp0GEcr0H1SmTcDmjQlyeaHqzfjzNBwbMvzM5P?=
 =?us-ascii?Q?k0/CwPvIopI0e1kFPTfNU5nC9twqQzmC1RIrvxSCwHYpGir1vqD0u43cm6Vi?=
 =?us-ascii?Q?5/ZwuX73LRMscQc1vf/vJvCOYPukv9FpeEuJV85yb/UUNpqPsh03U/QKesln?=
 =?us-ascii?Q?4pud9TLMISdZXUuxV2Dd/C1voTEVG13VXHeQt4XKB6lV1iidYd4WcflgPMBJ?=
 =?us-ascii?Q?LSrU8qSKBolUwOiE9shlk0bg/UDUmSOYjgI5zg4gvdY3rc5DJf25z3/c+pfA?=
 =?us-ascii?Q?J4uw6ChlQmFyt5F7PocshDaWqq1Jd1DnH4v2jJhDa4r9NXpyeHIs/skvhGqR?=
 =?us-ascii?Q?1CCtD00EFQ2IZGhJQVJlCUdO4GN7/K0xX8rrwPuFUe9RRJTzo7+OCtrJzjvL?=
 =?us-ascii?Q?mfG5TyOoZi6S8BZu0b/EkSkEe4+CfbNjxezl1Yu4emYC/TD7aYZ6Qzh/g8Ff?=
 =?us-ascii?Q?ExPOTGeHQjkLcWHy4DE+wYS+q+cNH8IUrFaSS4RPoWx8Qf8QS5wE12XIyVL3?=
 =?us-ascii?Q?zs1kPFZzhQx6eCz8WT3ZxroOxEzSgOstLbXySL7CJHvpVzYrXBDtMJ1DHZF/?=
 =?us-ascii?Q?F3Zk9yOajdQhx9cznjOVsUZ38kFl8AidOTTym5jLAIkYexAWKdjYort8WIUO?=
 =?us-ascii?Q?CVLea3+TGqPw4RsXVTI43XFpdmMlOB7KJnYZ?=
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: 09 Jun 2025 18:34:43.1182
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 72adae3a-1596-458c-3284-08dda7844d68
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:
	CO1PEPF000066E9.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4356

v3->v4:
* see individual patches

v2->v3:
* drop committed patches
* add ("xen/arm: exclude xen,reg from direct-map domU extended regions")

v1->v2:
* rebase
* address feedback

Stewart Hildebrand (2):
  xen/arm: exclude xen,reg from direct-map domU extended regions
  tools/arm: exclude iomem from domU extended regions

 tools/libs/light/libxl_arm.c          | 110 +++++++++++++++++++++-----
 xen/arch/arm/domain_build.c           |  77 ++++++++++++++++--
 xen/common/device-tree/domain-build.c |   5 ++
 3 files changed, 168 insertions(+), 24 deletions(-)


base-commit: 86a12671c5d33063b6f958bdcca7c9d14cd5aac8
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Mon Jun 09 18:35:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jun 2025 18:35:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010407.1388524 (Exim 4.92)
	(envelope-from )
	id 1uOhKs-0004o1-0B; Mon, 09 Jun 2025 18:35:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010407.1388524; Mon, 09 Jun 2025 18: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 1uOhKr-0004nt-TW; Mon, 09 Jun 2025 18:35:05 +0000
Received: by outflank-mailman (input) for mailman id 1010407;
 Mon, 09 Jun 2025 18: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 1uOhKq-0004H5-Qv
 for xen-devel@lists.xenproject.org; Mon, 09 Jun 2025 18:35:04 +0000
Received: from NAM04-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam04on20631.outbound.protection.outlook.com
 [2a01:111:f403:2409::631])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 74c338c0-4560-11f0-a305-13f23c93f187;
 Mon, 09 Jun 2025 20:35:03 +0200 (CEST)
Received: from BN9PR03CA0759.namprd03.prod.outlook.com (2603:10b6:408:13a::14)
 by CH3PR12MB9455.namprd12.prod.outlook.com (2603:10b6:610:1c1::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Mon, 9 Jun
 2025 18:34:59 +0000
Received: from BN1PEPF00005FFE.namprd05.prod.outlook.com
 (2603:10b6:408:13a:cafe::94) by BN9PR03CA0759.outlook.office365.com
 (2603:10b6:408:13a::14) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.22 via Frontend Transport; Mon,
 9 Jun 2025 18:34:59 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BN1PEPF00005FFE.mail.protection.outlook.com (10.167.243.230) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Mon, 9 Jun 2025 18:34:57 +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, 9 Jun
 2025 13:34:57 -0500
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; Mon, 9 Jun 2025 13:34:56 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 74c338c0-4560-11f0-a305-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=DutKV8WaGTg8FhrMDrhoW84o1VELPxseDGz+BmJ11Wi/DzXM40+sBqVnhkFyFO1bGsZyYMTAGYDA0VEwQ4BZSdTHXrvfqk56Qv34bob/LZYxK/IgEcwbeWqqYX1Zm/Tpff1wnIIVCzOO6n7Vj9SBmIMhIdC5U/0YNFVlizG+9SJTnBJbvoD7XY5YSgg7lGq9ERKVPOYNl0+WLQYEYVBHuqRG9GJg0P/eddM67gHuEYuK6CVSUy+ygABApa/fn/fmD2Ov32avAURnBWtk34sT6SlGrgsN3emLDh/DmevzCL+82VqalD7s6SpI5xssJPr6GOCQYOP3uYqmOUM+U9L7wA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=bZnrDKYY3avTKdpFv8IWwACHQfdwIEteEIO5b/rIpco=;
 b=cyRtM30GBnrt45htqhBlYKXSahYToSXlmoUQKjE9J7yqKacgslL+VjMVL9FbIsNhJ5XEwenpZpzsZEVXOLNEnKOzBqXZbZsa5vNlfEZ+la0jdhgkQEThVimFF0tD+fbTtXouziJdlQtXEr/ThgoV+55I5AmHo+LFdj3FJjiXVVH/Q4wbF9JLx21jzEgg03gh1RW95IsCmd9Aw5WoQxkr0KDe75Jx/0dSVt5VTmhb+BGvWFUCkjcSsIcBkRju0/FiCsPg8Et/mv9mKT2XWm5MRiOn6arQJPAbmSUCwGVk186SCla36xItxt3mNOz0S7XAtUSYjfHrpr93JQsVZuryLA==
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=bZnrDKYY3avTKdpFv8IWwACHQfdwIEteEIO5b/rIpco=;
 b=OD5fX/1FHFr8bwUi/epX+5cOxtiS3ZBDmis00FpjTk5Bs9F7BPb7VYx/0SFZrZxzq3yuYivRkkUlBQHuNGv//DUcQYEr158c7pPzA3rCVn4k+saRDtmzBpwimiFYvc5I8nuM4XQrZ+uH0asRJZo5NZKwW5RaL8O85mSgLuDxGpU=
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 , Anthony PERARD
	, Juergen Gross , "Stefano
 Stabellini" 
Subject: [PATCH v4 2/2] tools/arm: exclude iomem from domU extended regions
Date: Mon, 9 Jun 2025 14:34:33 -0400
Message-ID: <20250609183438.178214-3-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250609183438.178214-1-stewart.hildebrand@amd.com>
References: <20250609183438.178214-1-stewart.hildebrand@amd.com>
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: BN1PEPF00005FFE:EE_|CH3PR12MB9455:EE_
X-MS-Office365-Filtering-Correlation-Id: 1d11a86f-b415-409e-6555-08dda7845630
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?bB6AZCM9q6CeSGTOOKudle/jWcvg9lqoVTV2uWjGEyL8cOetJBuEGQQVL3hW?=
 =?us-ascii?Q?q/VcsJ0+AwR10UlwMT5XJE1SQPFWbrXZ6l7a0rxtN2x9HlHaK5VHBF7DT8Zd?=
 =?us-ascii?Q?Wf+eq+9saCrTq4rZOOxfJ9QQBOoAeV8Nq4FUgJtB06Y7Wf6/ZT6+ulI4CimX?=
 =?us-ascii?Q?nHapiaWS7H8QovEuSbhJNN3nroFkLinkKzO4Zt6j1zVVreMSBmRLKBpY+1QE?=
 =?us-ascii?Q?j7+xU40j5AHF5+OltwMzRexR6z98qqz//lrpr57ahvbmTXDTpA0r5PjIxPjK?=
 =?us-ascii?Q?3F+dEVtZmoAgrBTliCHljL2mzbUyzgK+VPdlDJaGPsqAn8+t6/wLi3BVy88V?=
 =?us-ascii?Q?oADFqWJdkyjqxrb/11mdUox2bdNzSNXkQ9i7UCTIaiYA/5kswUlKLuUDjmQD?=
 =?us-ascii?Q?RxUlrg7jDTnb2in8LjvUmZnrWs4RwRck8u5HSLYduoRxkdy3pVzUAy7+KWmO?=
 =?us-ascii?Q?fI0ly34y+ZivD0TW90fVG3HiOKDtztSh/5V/d+EBuXStnR8MJfdY9he4LZIq?=
 =?us-ascii?Q?GtNS6ghkL+YN17W4BovO3ytpoEWjlSAkzcbU/hpJGVuRfZKfHf9kJnEUfEl8?=
 =?us-ascii?Q?ky2zycCYXUfkJPX/cdZ4x8XnNdO0+gzl6ilPutAzU+xrQoOawwecMWLI9abH?=
 =?us-ascii?Q?7isP8caZnhbPNPD50n2cmIgQuYdCN1HmwfjxIggMQHnw7AC7iwyN1a8gxoxv?=
 =?us-ascii?Q?IDnuhdaGUAEqXEf/PhH89kUxV3LnVYveWI2srrble2r1gFj2TWP39IF/8k/b?=
 =?us-ascii?Q?dZpVEj+nTerWbxr92Dx0JyQEeUYd7+GSfluBb+vprO3vaxdTjhqVmHyMN7lw?=
 =?us-ascii?Q?Eb9uLjEtEw2BiRoh4rk9hHnyfWt/v9g1koY0CvSi8+u9ezZoV8DTMfLfSWfx?=
 =?us-ascii?Q?vjZo6GtGG9XJlg4BtdiG7y93xORDIYuhqCvke71b+Di4vhzfpVw47gyDwioy?=
 =?us-ascii?Q?hIyEQvbNVfIFxHSLV9CO3WA5gqVOW1KtHL3feQS5yBUSZNpP5UMVuuqClTdk?=
 =?us-ascii?Q?Ddl7vL+5FqT30LRlLc6vitt23tJe++Q5jCylRXM75U1aoR4CvX5XcQp6wINe?=
 =?us-ascii?Q?xFap7qrFW5kRLyQ3BzWjBT3kvz+spIoKKgW12Z9Y9YVyP2t48hZLJBXOxo+Q?=
 =?us-ascii?Q?m7qGlGEg+kGRLqIxbwVDwKL8NX5JlcQS6t2o+IFOSECdu+NEtGrbt/dg3QY8?=
 =?us-ascii?Q?wUdiP8m7sHePtpmIJwQZmPxJdCT49VnbEZ7jGLey9k59D5QX4q8+zVivcQoT?=
 =?us-ascii?Q?bHui/8Qr3+rLjBliNAJkaKU8o++/1xu8OymLrPmQo3Z50C5207gNqzSzkgAX?=
 =?us-ascii?Q?NNBY58gnaceqnXW+QoJ5umdv73+maO7hkjkZp6Pf3UZEPN8F3t/XPx62Crd5?=
 =?us-ascii?Q?9yAFbfTQu2DtvIvGT+UVfJQ8R6VL7skzWS/DZdWqUhNCDaKaOj1RPFud/OfV?=
 =?us-ascii?Q?c1qhFz/vkFLuHtz3nr6syeTvumYi6bkzNIbf6RQKGjmhWui5BBnlDZnYnemM?=
 =?us-ascii?Q?yMdNqPlJNMH3LRWcDoVup2E4IMtYYgqu11ED?=
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);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jun 2025 18:34:57.9576
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1d11a86f-b415-409e-6555-08dda7845630
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:
	BN1PEPF00005FFE.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB9455

When a device is passed through to a xl domU, the iomem ranges may
overlap with the extended regions. Remove iomem from extended regions.

Signed-off-by: Stewart Hildebrand 
---
Not sure if we need a Fixes: tag, but if we do:
Fixes: 57f87857dc2d ("libxl/arm: Add handling of extended regions for DomU")

v3->v4:
* use "else" instead of continue + another if statement
* remove assert
* s/iomem.end >=/unallocated.start >/ in two conditions
* new variable to distinguish unallocated size from region size
* print base + size - 1

v2->v3:
* no change

v1->v2:
* no change
---
 tools/libs/light/libxl_arm.c | 110 +++++++++++++++++++++++++++++------
 1 file changed, 91 insertions(+), 19 deletions(-)

diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 75c811053c7c..3086c52acf83 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -798,6 +798,8 @@ static int make_timer_node(libxl__gc *gc, void *fdt,
     return 0;
 }
 
+#define MAX_NR_EXT_REGIONS   256
+
 static int make_hypervisor_node(libxl__gc *gc, void *fdt,
                                 const libxl_version_info *vers)
 {
@@ -821,7 +823,7 @@ static int make_hypervisor_node(libxl__gc *gc, void *fdt,
      */
     res = fdt_property_reg_placeholder(gc, fdt, GUEST_ROOT_ADDRESS_CELLS,
                                        GUEST_ROOT_SIZE_CELLS,
-                                       GUEST_RAM_BANKS + 1);
+                                       MAX_NR_EXT_REGIONS + 1);
     if (res) return res;
 
     /*
@@ -1517,17 +1519,29 @@ static void finalise_one_node(libxl__gc *gc, void *fdt, const char *uname,
 
 #define EXT_REGION_MIN_SIZE   xen_mk_ullong(0x0004000000) /* 64MB */
 
-static int finalize_hypervisor_node(libxl__gc *gc, struct xc_dom_image *dom)
+static int compare_iomem(const void *a, const void *b)
+{
+    const libxl_iomem_range *x = a, *y = b;
+
+    if (x->gfn < y->gfn)
+        return -1;
+    if (x->gfn > y->gfn)
+        return 1;
+    return 0;
+}
+
+static int finalize_hypervisor_node(libxl__gc *gc,
+                                    libxl_domain_build_info *b_info,
+                                    struct xc_dom_image *dom)
 {
     void *fdt = dom->devicetree_blob;
-    uint64_t region_size[GUEST_RAM_BANKS] = {0}, region_base[GUEST_RAM_BANKS],
-        bankend[GUEST_RAM_BANKS];
+    uint64_t region_base[MAX_NR_EXT_REGIONS], region_size[MAX_NR_EXT_REGIONS];
     uint32_t regs[(GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS) *
-                  (GUEST_RAM_BANKS + 1)];
+                  (MAX_NR_EXT_REGIONS + 1)];
     be32 *cells = ®s[0];
     const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
     const uint64_t banksize[] = GUEST_RAM_BANK_SIZES;
-    unsigned int i, len, nr_regions = 0;
+    unsigned int i, j, len, nr_regions = 0;
     libxl_dominfo info;
     int offset, rc;
 
@@ -1542,20 +1556,82 @@ static int finalize_hypervisor_node(libxl__gc *gc, struct xc_dom_image *dom)
     if (info.gpaddr_bits > 64)
         return ERROR_INVAL;
 
+    qsort(b_info->iomem, b_info->num_iomem, sizeof(libxl_iomem_range),
+          compare_iomem);
+
     /*
      * Try to allocate separate 2MB-aligned extended regions from the first
      * and second RAM banks taking into the account the maximum supported
      * guest physical address space size and the amount of memory assigned
      * to the guest.
      */
-    for (i = 0; i < GUEST_RAM_BANKS; i++) {
-        region_base[i] = bankbase[i] +
+    for (i = 0; i < GUEST_RAM_BANKS && nr_regions < MAX_NR_EXT_REGIONS; i++) {
+        struct {
+            uint64_t start;
+            uint64_t end; /* inclusive */
+        } unallocated;
+        uint64_t unallocated_size = 0;
+
+        unallocated.start = bankbase[i] +
             ALIGN_UP_TO_2MB((uint64_t)dom->rambank_size[i] << XC_PAGE_SHIFT);
 
-        bankend[i] = ~0ULL >> (64 - info.gpaddr_bits);
-        bankend[i] = min(bankend[i], bankbase[i] + banksize[i] - 1);
-        if (bankend[i] > region_base[i])
-            region_size[i] = bankend[i] - region_base[i] + 1;
+        unallocated.end = ~0ULL >> (64 - info.gpaddr_bits);
+        unallocated.end = min(unallocated.end, bankbase[i] + banksize[i] - 1);
+
+        if (unallocated.end >= unallocated.start)
+            unallocated_size = unallocated.end - unallocated.start + 1;
+
+        if (unallocated_size < EXT_REGION_MIN_SIZE)
+            continue;
+
+        /* Exclude iomem */
+        for (j = 0; j < b_info->num_iomem && nr_regions < MAX_NR_EXT_REGIONS;
+             j++) {
+            struct {
+                uint64_t start;
+                uint64_t end; /* inclusive */
+            } iomem;
+
+            iomem.start = b_info->iomem[j].gfn << XC_PAGE_SHIFT;
+            iomem.end = ((b_info->iomem[j].gfn + b_info->iomem[j].number)
+                         << XC_PAGE_SHIFT) - 1;
+
+            if (iomem.end >= unallocated.start
+                && iomem.start <= unallocated.end) {
+
+                if (iomem.start <= unallocated.start) {
+                    unallocated.start = iomem.end + 1;
+
+                    if (unallocated.start > unallocated.end)
+                        break;
+                } else {
+                    uint64_t size = iomem.start - unallocated.start;
+
+                    if (size >= EXT_REGION_MIN_SIZE) {
+                        region_base[nr_regions] = unallocated.start;
+                        region_size[nr_regions] = size;
+                        nr_regions++;
+                    }
+
+                    unallocated.start = iomem.end + 1;
+
+                    if (unallocated.start > unallocated.end)
+                        break;
+                }
+            }
+        }
+
+        if (unallocated.end >= unallocated.start
+            && nr_regions < MAX_NR_EXT_REGIONS)
+        {
+            uint64_t size = unallocated.end - unallocated.start + 1;
+
+            if (size >= EXT_REGION_MIN_SIZE) {
+                region_base[nr_regions] = unallocated.start;
+                region_size[nr_regions] = size;
+                nr_regions++;
+            }
+        }
     }
 
     /*
@@ -1565,16 +1641,12 @@ static int finalize_hypervisor_node(libxl__gc *gc, struct xc_dom_image *dom)
     set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
               GUEST_GNTTAB_BASE, GUEST_GNTTAB_SIZE);
 
-    for (i = 0; i < GUEST_RAM_BANKS; i++) {
-        if (region_size[i] < EXT_REGION_MIN_SIZE)
-            continue;
-
+    for (i = 0; i < nr_regions; i++) {
         LOG(DEBUG, "Extended region %u: %#"PRIx64"->%#"PRIx64"",
-            nr_regions, region_base[i], region_base[i] + region_size[i]);
+            i, region_base[i], region_base[i] + region_size[i] - 1);
 
         set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
                   region_base[i], region_size[i]);
-        nr_regions++;
     }
 
     if (!nr_regions)
@@ -1626,7 +1698,7 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc *gc,
 
     }
 
-    res = finalize_hypervisor_node(gc, dom);
+    res = finalize_hypervisor_node(gc, &d_config->b_info, dom);
     if (res)
         return res;
 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Mon Jun 09 20:54:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jun 2025 20:54:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010441.1388534 (Exim 4.92)
	(envelope-from )
	id 1uOjVr-0005hk-Id; Mon, 09 Jun 2025 20:54:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010441.1388534; Mon, 09 Jun 2025 20:54:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uOjVr-0005hd-Fr; Mon, 09 Jun 2025 20:54:35 +0000
Received: by outflank-mailman (input) for mailman id 1010441;
 Mon, 09 Jun 2025 20:54: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 1uOjVp-0005hX-UT
 for xen-devel@lists.xenproject.org; Mon, 09 Jun 2025 20:54:34 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20626.outbound.protection.outlook.com
 [2a01:111:f403:2009::626])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f088a1b0-4573-11f0-a305-13f23c93f187;
 Mon, 09 Jun 2025 22:54:31 +0200 (CEST)
Received: from SN7P220CA0027.NAMP220.PROD.OUTLOOK.COM (2603:10b6:806:123::32)
 by SJ0PR12MB8091.namprd12.prod.outlook.com (2603:10b6:a03:4d5::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.39; Mon, 9 Jun
 2025 20:54:27 +0000
Received: from SA2PEPF00003AE6.namprd02.prod.outlook.com
 (2603:10b6:806:123:cafe::46) by SN7P220CA0027.outlook.office365.com
 (2603:10b6:806:123::32) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.21 via Frontend Transport; Mon,
 9 Jun 2025 20:54:27 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SA2PEPF00003AE6.mail.protection.outlook.com (10.167.248.6) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Mon, 9 Jun 2025 20:54:25 +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, 9 Jun
 2025 15:54:25 -0500
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, 9 Jun
 2025 15:54:25 -0500
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; Mon, 9 Jun 2025 15:54:24 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f088a1b0-4573-11f0-a305-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ZMdVOyI5B5XfVQleCGRWs3Rf+YmSickz3FXn5tJvW2dGXvDQSBW1sCqWYMOa37+I1u3wZI/5s8FDi9xbr0/BGVTTBLKWxQ0d4VS8qG+bzC1WxZ5OadcscM4llMEMcDoK3as9soPIH/1jLXfEbLg+9DAxpsLR4IS5H6rIfz6EWSP/7ibd689Noa1VZN/5j5UOoI5yJXROjaOI4gGHKNjEG6VrZshmf3vmwNHASQGy06E3S8TSjwSZXjtpTz4HxHpE2hNM5QbulwHvI34LMeAhM1zGpJwd7owQgUWa46QtlF9lkoGHzyGzcdp/HwmW6ueBwTE3hH+B+WvMt9XQbrLWFA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=8wbtqZhYC108wtkPXEr0Ks9WzyBY007ozYY9rvrT0qI=;
 b=wmmBKT+FeKX/Yljem4d1fUtAS5ZHVkq+Tkp12lB+YW65q2W8fy7kyErYSz3a/WqW7nWnlzY2VRxIhyIJ1cW53ZHoIZQXKhKQnB/6kq1OjLt1f2M9uKxcMIXfp3nvWbNHRc9AWdYmCdIdYYV9jPl1gluJvtc1O5CcB8XUdmDjYgmMRNsbjLIjApRgIVW27EKgj7UZ05lnlbiiuscc4ekam9+rA2uQ2OR10ABhAoD2Fi1i/+XPuZr+ApHw/vmL+rb6+2bFGj/K8dUbU26F9i54QF01WdKDgNJLd1QJtPaF6rpJmf3VCh1ZVA+EKytPznV6XmgoXR8AmsUjt1vjdc+GiA==
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=8wbtqZhYC108wtkPXEr0Ks9WzyBY007ozYY9rvrT0qI=;
 b=geS0ogsVkMN8jKJ7zZYu6aSo6/rmD8oeVQIjoQtd64jVaUMjAf9xVzNNnTcRsqUU31WLiQy16mSb09ynOe/rjQvfeMYz3z/wFoYnVaZytP4EMNJ4gWoeddqEZf3AzHgSOT7+O+plkr8grRBlGTQgdxeazEsKL8DoiDkOxoNMVWM=
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: Stewart Hildebrand 
To: 
CC: Stewart Hildebrand , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	
Subject: [PATCH] xen/arm: fix build with HAS_PCI
Date: Mon, 9 Jun 2025 16:54:21 -0400
Message-ID: <20250609205422.180717-1-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB05.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SA2PEPF00003AE6:EE_|SJ0PR12MB8091:EE_
X-MS-Office365-Filtering-Correlation-Id: e7fc7de6-8366-4ef2-8270-08dda797d1ed
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?alVEUnQyYXN1YnRYS3hFb1lrRUE4WVdIOU9lRTBwbFFGdVF2Mk5MWmd1SHpj?=
 =?utf-8?B?OGlWK3pWL2RvcDhkSy9DK05WZGlHTm4zaU1jRVB4WkMrcGx4RDN3M2NHN0ZU?=
 =?utf-8?B?YlRtd2NCTWhHVVh1S0dCS1ZUSFBoQWZ1WVI1alVXL0JjNC92OTVMT1AycTVG?=
 =?utf-8?B?N2t4bGkyYi9NRWxONlJYdFRFYzZGY1htVDF5SnJlZ3phN05aUXFYMFBoeHRK?=
 =?utf-8?B?WFZtYjNET29YaTlkM0NydDNMa1BacTV3QmI4TzV4NVVzeGxOaUVvMVJvcGVO?=
 =?utf-8?B?VTlyQWRqVFByU3JRMDJEcm8vNjVhdnI1Y0FUVHpvKzlUdWFGU05GdHpibzZr?=
 =?utf-8?B?UkJCUENvekFOQ0FNdkNvN0xVWGI3WVJidnBJTkUrQjMrR0tzMWJwdG1FM21U?=
 =?utf-8?B?UGZPOVpVb2lMUjFYeFRINHMvRWtRL0paWVhrNXErbUpUK2ZJVEtIWjUvT0RQ?=
 =?utf-8?B?MUhlTE02SlpJVVR4cW02T1E2MWpyMzIyaVFiWkhJZFlGQ1lNUWY0TEtBVEk1?=
 =?utf-8?B?cTR3MWF2L0E1MC9nVnBHOU9IVjZNRGZSbTdDQi9RWWUwYi82M1hIb3FYK0R0?=
 =?utf-8?B?M2VoR3g5WVBRVnAwWXhtb0hOK290SGJYVjd6L2pLK25HQVBBNW5Db2RCQld5?=
 =?utf-8?B?N3FBNnB1V1dTNUdyZHJ2azltRzhnblNsSGEreENLT0N5bDJmNUEyYWpYbnZW?=
 =?utf-8?B?TlM0L2ZXN0J0WlI2eHBEeHBKYW15SGZnc0lsRzc1Z09yVnBwd2ljRUI4Uks3?=
 =?utf-8?B?eERLKzNBQW1iMGxSTmRJL2RibG5uejVUWlVsOG9tRFFVSTFBcDhxR2RwL3dx?=
 =?utf-8?B?Y1FQT3FQLzc4MnorWmJWWnNoVnN5aXdUTVQ3bnFtWTdJZTJidTRITWVtM3Np?=
 =?utf-8?B?cHBsZHJ1aHFrNFRXcTBqVFdhZ0I1QXVHVklkWkRNUVFzZkNQMGwrT3RPK2xK?=
 =?utf-8?B?K2tVeHlvN2FpTlNDWUVRYVc3ZmVyc0ZWeDFkbWVvWFFNSDcxU0VJUWgxQkxM?=
 =?utf-8?B?dVZwTlBVeDlnNUZPbGh5SzRaVENNMTFoT1ZheGluOUlMR01DNTl4RDFheUx4?=
 =?utf-8?B?cms3dzFhOXk3Y2FRYzNWNWtaclNhaS9QaU02WE9nMXEyb1R2UlpWUjk0QStO?=
 =?utf-8?B?OUhickI1cU1pMU1iRTZFbXJBQ21zMEtTanhHUFhrVFBuTTVNbDZsRXB4K2RU?=
 =?utf-8?B?amVJYWRlRnN5Z0tTRmtLQkhJSFN3ZXU5VUI4UDNLeWxpUG5Sc2hiaHgySUYz?=
 =?utf-8?B?QTE1elhNQk5WaHptZ2tXeEt6VTRza1M2dTFYNVlZeWcyemVqZlY1bU40Tm5q?=
 =?utf-8?B?TkFMOWRJN0s5RmdrMUJXRW1HQlBTTURWcGhXanlnUjhEVENMenpJa2UySDRH?=
 =?utf-8?B?UUNyWmFYK3kzdUZMZWMxYk5pMmFZY1pXWlVMQzJJeDlVWVhPN1VjSThuNG9V?=
 =?utf-8?B?TTFocEJlaDJ5RkFZTGpnTGJvSGFlTDkwWFIvMGZ3bDl0OGJyYmk5Tlo4ZHF4?=
 =?utf-8?B?YnlmdDJXTVNWazM2YUxwRjRkZFBrSFZBNTEyNVBrWTl6SWlTenM4OTZqUkVa?=
 =?utf-8?B?eDlMTGNockhTUXQvQkRGaWwrQkZyL0h2c2JNdnBrTUNaSkVhSXRTRkMrS1dW?=
 =?utf-8?B?alc4Y0NBV0gvb0VEV2J3MnNyZ1lOYnlvVGk2TWVHWWZUaEJMZ0JTd3VtRlJQ?=
 =?utf-8?B?SzFkbjg5NFNSNG9zcnp1b1NjdjVZM2pCNkRKNTRzS0VYby8zR2RYY2MwbTdG?=
 =?utf-8?B?dUpDbG9KRFVRWDRPTU5kc2VWQlNUTmRJc0J6c2tLNVhodHNGNW40eDNBYUhn?=
 =?utf-8?B?S2dXNmNLandWNFRTUDNGK05vQ2JqL2Q5c2xlUDFJSUh2UWJGcDBuTFJHbEFj?=
 =?utf-8?B?Zm9ZckhLcCtFL1JjUEtreVNsbTJtUVB0ZUYxME9EZ2Vyd05rR3JERlBWdVJR?=
 =?utf-8?B?dzJUZEdmTGl6SkJDN1JXRVp1dVNISE1uNG1Ec3BBazdUK0wwYnBmS0VmM1Az?=
 =?utf-8?B?ZXViWWdveFhKRkwySHRMWVZiVExBQ2hzWm13MWpFMnhuRC84bzlGaVA5WWpi?=
 =?utf-8?Q?QaD57+?=
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: 09 Jun 2025 20:54:25.9628
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e7fc7de6-8366-4ef2-8270-08dda797d1ed
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:
	SA2PEPF00003AE6.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB8091

In file included from ./include/xen/pci.h:72,
                 from drivers/pci/pci.c:8:
./arch/arm/include/asm/pci.h:131:50: error: ‘struct rangeset’ declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
  131 | static inline int pci_sanitize_bar_memory(struct rangeset *r)
      |                                                  ^~~~~~~~
cc1: all warnings being treated as errors

Fixes: 4acab25a9300 ("x86/vpci: fix handling of BAR overlaps with non-hole regions")
Signed-off-by: Stewart Hildebrand 
---
 xen/arch/arm/include/asm/pci.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/arch/arm/include/asm/pci.h b/xen/arch/arm/include/asm/pci.h
index 1605ec660d0b..1bbb9d780193 100644
--- a/xen/arch/arm/include/asm/pci.h
+++ b/xen/arch/arm/include/asm/pci.h
@@ -17,6 +17,8 @@
 
 #ifdef CONFIG_HAS_PCI
 
+#include 
+
 #include 
 
 #define pci_to_dev(pcidev) (&(pcidev)->arch.dev)

base-commit: 86a12671c5d33063b6f958bdcca7c9d14cd5aac8
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Mon Jun 09 22:44:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jun 2025 22:44:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010452.1388545 (Exim 4.92)
	(envelope-from )
	id 1uOlDg-0001Hk-Po; Mon, 09 Jun 2025 22:43:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010452.1388545; Mon, 09 Jun 2025 22:43: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 1uOlDg-0001Hd-N2; Mon, 09 Jun 2025 22:43:56 +0000
Received: by outflank-mailman (input) for mailman id 1010452;
 Mon, 09 Jun 2025 22:43: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 1uOlDf-0001HX-4B
 for xen-devel@lists.xenproject.org; Mon, 09 Jun 2025 22:43:55 +0000
Received: from sonic310-22.consmr.mail.gq1.yahoo.com
 (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.148])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 33ed73cf-4583-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 00:43:48 +0200 (CEST)
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic310.consmr.mail.gq1.yahoo.com with HTTP; Mon, 9 Jun 2025 22:43:45 +0000
Received: by hermes--production-ne1-9495dc4d7-jhk9q (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID 2aa59b495c54eb04322430ca52fe5ded; 
 Mon, 09 Jun 2025 22:43: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: 33ed73cf-4583-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netscape.net; s=a2048; t=1749509025; bh=7Bw3jXhW+wkA/wUNZMtibMU2KmDX3Hvp9ZvGY8+23r8=; h=Date:To:Cc:From:Subject:References:From:Subject:Reply-To; b=jl9FmF7JAkKQccD47YpFJdCq+k7/D9Tv2CegMDHO7qHIhIC/25Kf5mJjYilhydcAi6PvjEIC1aklanjKlqkfd9BHc3Zf3mXUao1oqo9ch6f0WP78j7fJMTCD6+HyISeLQaP4S+1F8vBDnWcCV0VLbQkzikmjMnYIIWadI8l0Fst5Uu+c9v1O3L+dG4/NMK0BT/g4Ii4tAdpOvNtUocdt4e3Do2AliCZ93AzVpp4/sai2EJV9QT8AQ5fBNjPrlFcmAShACwdbLRsgYbNXx4lsntSZpwD9CYtR0RfkXCYZ35yZJHlbHav3+C0kJ7zcgWmc6Y4kFZkduBNpNktw5jGCeg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1749509025; bh=nG2iMdVHZOX6wNMXyzYfBxmJDHQT5MDJHts4/Ckhamu=; h=X-Sonic-MF:Date:To:From:Subject:From:Subject; b=jnZNGEWa2zZ4Ly0kE+uVpLprnJC0zieGpSrko/3KdHu/AXJ27DWx8Em5+y9kWkKoricJxJU4scEXLXcpHh3AE9InKooBpqmlCiy/k8Of239Qy/f3AyOsu19sZjuNSirZUNEsDfAz9pQpTX4VmgSCQc8Z+mFJg19uYLFJfJlI1lIBtJfKxfkC2dvQCnWMFr2FFsNobQ6Xu+sHWpzJZ/uGZeq3b8mtStyt6iysrcBufqKNeYMGqYfIZYlcSlwUQwGf4itbS+PG6U0RGzmA8oV6taKDnXmGtKiI/opl1ZUOUnOJ6AHS+fCekvnJHnFL/tpKEGDUjYxZPfg4A+XmoPFPxw==
X-YMail-OSG: mjaEBDUVM1mziT1Wc_IHByQDroBWuuSdqxLiyffktXS2f60l5XiDlzQmO4Jjiqj
 ZF8VdF4G6jsvrZLhzbeToJsDbucH8ZLaV0oaptyCGenBCdr5hghGIIw6lYaGXAzOTvvYRjnNmfxk
 FEMFARgLGh_0d.a8gmqVplelCWaF9EPn5ztqivpRojwxfSrLFs.xxXr4aoPU7YxUbepR1nKblICj
 FwWeXS3bofHTg7iibwG4ihaMcDwaVhHdQ.GqIpztBW2obqChBiDZVr9fueSCuamOqZGTykwuFNvu
 .8oXPig.jkcLO5oZODMdqE26TCXLpWwiWhGS3bEUqO9BX5NneWUIIPCaATgmZJUJCH_4oshvJtUD
 u1PI1agO904f_ZyxOX709s11gMj4upYrHQaCh78jrBPS7lpjVPvqSes5V25bNvYB5IJa29.6BRNh
 _XQtzc670TgoDdkF63nvnrmRfTFmH0xhBMbJioubHf84OXMDWmweRL8d4KgaRPGD_eWvO7HgEgsz
 6LXVnHYSmHNPwnW3rS8DygBbtkdPSHA9.4QX21yG6NFKbGOmDOLXfcUkSvO01Yo8NMniRz1GvleX
 J59LYgR3bwSn1PuFcevahQmEK5DA0IzpULg5I7ooD23e2pp1V7mggDlweDorpij1kvaCiR87IBNt
 ql6TVMoMxDli_RbKdGdWjbtS554NAlCrCsrEqyfI6CDreNW3dhQpcXGy7ac.2NWNa9CW0NajpKCB
 q4uJj86ODy47CIyli2bp38wr2AkgAxVnrmSmXfPEXq1gk_WarsaZ2wYz.FXHgoeum4Cal5ha.bOP
 Z6lZ0H4b_OaxhvLZoz1Z0iSLeH.XDvQNL7UwQZPAct2XLY3X4Yw1nz47kF1kqBlrvssijrkLty4j
 J9KTGPbA8kBMqmjpRojyjYP7hRM8rSA8YsGG48Bp9Aq21i4VKVKJX3hc1YsG4hLAssvgv9yqdoWy
 FdInki_jHETdTk_v_SfR10Wh_y1ErwY0QxQcwZM.mjXKTTdDo.5KGbBRCS9YKmoQ1dCcMSmRX11M
 6Dq.qLmHXO60r7PeQi0bbGBwFYgnpgDquIDUadEm6GXNqp3iuPOZKYlXrPHHgb5J_Pkb9zVXAAju
 tfVmVSDOFs750Fpy2fwb7.QjBCK5vGX0QWegpyUc_aAxkd4csxwtcVBbKVjenr4wJBlKmKiQushF
 SpcIw77gyfInhyEDz8aqxygyTtD3G1qmrb.59G3p81g1maejkDHA9U3puHqos8BSQj7vXH4s9jdS
 WFgiwSmeHaIFHr4nzda4DGD6KrDazLvh3t8ybS6VqmEyhDAzYdugy2kLVhDk5b.EttQx6I0mY9qE
 9JVuT42QnG1VovAYmKtywa3jQaas9.C.DJw9cCUbAnhPGzdUVWAp_U78MslHNUyKIv0hmwZwVe6h
 f5Nwz69P9w193cvlqCjl2jWeuCShpIDKlLxgOAbDFxD3RcO_FTWnfMQkWyssixzeNh0TlT_cLHON
 84_QQ_GmlCT35GUbjS0vobb4neQpLUz7074XPMgZ.YFIalOYeXB2UjqvpAVLa7GMjWnd3CPGMBI8
 fe9fkMc3uhPnRaHUYq1GLJ1WTMO._oGdw3IjEuro4aflxBaa9Ecp7vPouZ4oAhmONRToEL0DUuJO
 E0pwr1OMbouqhT8.6vD4V_tEJdrTN6Z8swMXomJ9A37qoAr7t1eJ00GmTcj.nRJXQLloTMD3Y1FM
 byJlFyu9ml6VgOofu0ZmBHep6hK96H91XgKSRx1tyqhX0gIfQ2qbaDC5UN2a3E6HDzXg_8C_osdb
 BJRZy7ONjfqMBik2NU4bH5Go9gNYjtJiG8zYMfRGpwGU0564NyZWixkPYL.UtiXm480ST0BmS.aS
 S8ZjMpgf7r5gbiZgJ5wkSviGDSHiHTmlzWbATN_e7sAzRGh7Yw6XQqj7dwcWxHa5EwV2qHaic4DY
 Ac_8sywHkWW18dYNdpcuPIK7wfwc1ZXSeYSePIoVHCt4WFRQ6ftvquk_655G7wmAQdS296kEGjjO
 FNO_dEfnLeQiVT27HYXgz0c1J0CjwsxBXdRg8oNCpx7N73XUYhFghndZR3znIULKyaKsNXpnGGCI
 XMLmlJIsAubhZ0TI1BNXot1mTsE_pu8Y5uf8ASf_2vMVYkZub2K.Nrboa.PZRn9E6ZCzz0JY6wru
 XKC71sbfDjcY8o8ewpwvQkCs_ju638IRhC.4k2JRvI6EHwKYuVejGxFIpkqHmq0EMrW3KVmBV__U
 _l2GGc9dwTA--
X-Sonic-MF: 
X-Sonic-ID: 4b775504-7aeb-456f-8c31-c4ffb8f0136c
Message-ID: <8ed96ec9-7c84-4bb4-90ec-5b753be9fd40@netscape.net>
Date: Mon, 9 Jun 2025 18:43:41 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: stable@vger.kernel.org
Cc: regressions@lists.linux.dev, xen-devel ,
 Juergen Gross , Boris Ostrovsky 
From: Chuck Zmudzinski 
Subject: [REGRESSION] Linux 6.15.1 xen/dom0 domain_crash_sync called from
 entry.S
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
References: <8ed96ec9-7c84-4bb4-90ec-5b753be9fd40.ref@netscape.net>
X-Mailer: WebService/1.1.23956 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Content-Length: 3510

Hi,

I am seeing the following regression between Linux 6.14.8 and 6.15.1.

Kernel version 6.14.8 boots fine but version 6.15.1 crashes and
reboots on Xen. I don't know if 6.14.9 or 6.14.10 is affected, or
if 6.15 or the 6.15 release candidates are affected because I did
not test them.

Also, Linux 6.15.1 boots fine on bare metal without Xen.

Hardware: Intel i5-14500 Raptor Lake CPU, and ASRock B760M PG motherboard and 32 GB RAM.

Xen version: 4.19.2 (mockbuild@dynavirt.com) (gcc (GCC) 13.3.1 20240611 (Red Hat 13.3.1-2)) debug=n Sun Apr 13 15:24:29 PDT 2025

Xen Command line: placeholder dom0_mem=2G,max:2G conring_size=32k com1=9600,8n1,0x40c0,16,1:0.0 console=com1

Linux version 6.15.1-1.el9.elrepo.x86_64 (mockbuild@5b7a5dab3b71429898b4f8474fab8fa0) (gcc (GCC) 11.5.0 20240719 (Red Hat 11.5.0-5), GNU ld version 2.35.2-63.el9) #1 SMP PREEMPT_DYNAMIC Wed Jun  4 16:42:58 EDT 2025

Linux Kernel Command line: placeholder root=/dev/mapper/systems-rootalma ro crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M resume=UUID=2ddc2e3b-8f7b-498b-a4e8-bb4d33a1e5a7 console=hvc0

The Linux 6.15.1 dom0 kernel causes Xen to crash and reboot, here are
the last messages on the serial console (includes messages from both
dom0 and Xen) before crash:

[    0.301573] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl

[    0.301577] Register File Data Sampling: Vulnerable: No microcode

[    0.301581] ITS: Mitigation: Aligned branch/return thunks

[    0.301594] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'

[    0.301598] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'

[    0.301602] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'

[    0.301605] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256

[    0.301609] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'compacted' format.

(XEN) Pagetable walk from ffffc9003ffffff8:
(XEN)  L4[0x192] = 0000000855bee067 0000000000060e56
(XEN)  L3[0x000] = 0000000855bed067 0000000000060e55
(XEN)  L2[0x1ff] = 0000000855bf0067 0000000000060e58
(XEN)  L1[0x1ff] = 8010000855bf2025 0000000000060e5a
(XEN) domain_crash_sync called from entry.S: fault at ffff82d04036e5b0 x86_64/entry.S#domain_crash_page_fault_6x8+0/0x4
(XEN) Domain 0 (vcpu#0) crashed on cpu#11:
(XEN) ----[ Xen-4.19.2  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    11
(XEN) RIP:    e033:[]
(XEN) RFLAGS: 0000000000010206   EM: 1   CONTEXT: pv guest (d0v0)
(XEN) rax: ffffffff81fb12d0   rbx: 000000000000029a   rcx: 000000000000000c
(XEN) rdx: 000000000000029a   rsi: ffffffff81000b99   rdi: ffffc900400000f0
(XEN) rbp: 000000000000014d   rsp: ffffc90040000000   r8:  0000000000000f9c
(XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
(XEN) r12: 000000000000000c   r13: ffffffff82771530   r14: ffffffff827724cc
(XEN) r15: ffffc900400000f0   cr0: 0000000080050033   cr4: 0000000000b526e0
(XEN) cr3: 000000086ae24000   cr2: ffffc9003ffffff8
(XEN) fsb: 0000000000000000   gsb: ffff88819ac55000   gss: 0000000000000000
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
(XEN) Guest stack trace from rsp=ffffc90040000000:
(XEN)   Stack empty.
(XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds.
(XEN) Resetting with ACPI MEMORY or I/O RESET_REG.

I searched mailing lists but could not find a report similar to what I am
seeing here.

I don't know what to try except to git bisect, but I have not done that yet.

Chuck Zmudzinski


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 00:42:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 00:42:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010463.1388555 (Exim 4.92)
	(envelope-from )
	id 1uOn4d-0007WN-6B; Tue, 10 Jun 2025 00:42:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010463.1388555; Tue, 10 Jun 2025 00: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 1uOn4d-0007WG-39; Tue, 10 Jun 2025 00:42:43 +0000
Received: by outflank-mailman (input) for mailman id 1010463;
 Tue, 10 Jun 2025 00:42: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 1uOn4a-0007WA-Tc
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 00:42:41 +0000
Received: from mail-24418.protonmail.ch (mail-24418.protonmail.ch
 [109.224.244.18]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id caf5e65d-4593-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 02:42:31 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: caf5e65d-4593-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1749516148; x=1749775348;
	bh=3Kn+SRMaHCl+B8lAzrGsfMCNF9sC9Rlw+3e3xABI+Z8=;
	h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
	 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector:
	 List-Unsubscribe:List-Unsubscribe-Post;
	b=ZonQ6wHSLCVW6PplNXoHWqOcDRCXdwSKaWapTbbgt06wUpI3iKch/lzXCDUYbBk4B
	 H5A1Tq8PqGscc3v/g3XrD+Xiyq6ycAX4J0rVInT0gEq0DPdYyr5l898Ia2yKUNuAwG
	 r4Y8JW6g8uPyvlxRLKel1XKPdgy3xgIeqVhvjYTmIxnz9UhhxhDn9U1q63Md4E29C/
	 i825kuln/Zi6qcCKvY3Xtsw8L/X2aSxtHRXJGByvrjY2knkUVjrvwne/PewmX7Bwf/
	 gfAvvEt7+YjH3A/RrD/Yq/qIMUWShrgXLWvWPuatPwbvEjf4Piw60y6NFIDAC5b2SA
	 T8FCPZBduKG2g==
Date: Tue, 10 Jun 2025 00:42:22 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com
Subject: [PATCH v6] xen/domain: rewrite emulation_flags_ok()
Message-ID: <20250610004216.3012253-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: e3ce06358ded461b8b7e10989c1fef83beb2b810
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Rewrite emulation_flags_ok() to simplify future modifications.

No functional change intended.

Signed-off-by: Denis Mukhin 
---
Changes since v5:
- optimized `configs[]` table - just one record for PV case
- sorted entries in `configs[]` table by domain type: PV, then PVH, then HV=
M
  entries
- addressed `caps` initializaton
=20
Link to v5: https://lore.kernel.org/xen-devel/20250602191717.148361-3-dmukh=
in@ford.com/
Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/1=
861382846/
---
 xen/arch/x86/domain.c | 86 ++++++++++++++++++++++++++++++++++---------
 1 file changed, 68 insertions(+), 18 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 7536b6c871..82b126351b 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -743,32 +743,82 @@ int arch_sanitise_domain_config(struct xen_domctl_cre=
atedomain *config)
     return 0;
 }
=20
+/*
+ * Verify that the domain's emulation flags resolve to a supported configu=
ration.
+ *
+ * This ensures we only allow a known, safe subset of emulation combinatio=
ns
+ * (for both functionality and security). Arbitrary mixes are likely to ca=
use
+ * errors (e.g. null pointer dereferences).
+ *
+ * NB: use the internal X86_EMU_XXX symbols, not the public XEN_X86_EMU_XX=
X
+ * symbols.
+ */
 static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
 {
+    enum {
+        CAP_PV          =3D BIT(0, U),
+        CAP_HVM         =3D BIT(1, U),
+        CAP_HWDOM       =3D BIT(2, U),
+        CAP_DOMU        =3D BIT(3, U),
+    };
+    static const struct {
+        unsigned int caps;
+        uint32_t min;
+        uint32_t opt;
+    } configs[] =3D {
+#ifdef CONFIG_PV
+        /* PV dom0 and domU */
+        {
+            .caps   =3D CAP_PV | CAP_HWDOM | CAP_DOMU,
+            .min    =3D X86_EMU_PIT,
+        },
+#endif /* #ifdef CONFIG_PV */
+
+#ifdef CONFIG_HVM
+        /* PVH dom0 */
+        {
+            .caps   =3D CAP_HVM | CAP_HWDOM,
+            .min    =3D X86_EMU_LAPIC | X86_EMU_IOAPIC | X86_EMU_VPCI,
+        },
+
+        /* PVH domU */
+        {
+            .caps   =3D CAP_HVM | CAP_DOMU,
+            .min    =3D X86_EMU_LAPIC,
+        },
+
+        /* HVM domU */
+        {
+            .caps   =3D CAP_HVM | CAP_DOMU,
+            .min    =3D X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ),
+            /* HVM PIRQ feature is user-selectable. */
+            .opt    =3D X86_EMU_USE_PIRQ,
+        },
+#endif /* #ifdef CONFIG_HVM */
+    };
+    unsigned int i;
+    unsigned int caps =3D (is_pv_domain(d) ? CAP_PV : CAP_HVM) |
+                        (is_hardware_domain(d) ? CAP_HWDOM : CAP_DOMU);
+
+    /*
+     * NB: PV domain can have 0 in emulation_flags.
+     * See qemu-alpine-x86_64-gcc CI job.
+     * Inject fake flag to keep the code checks simple.
+     */
+    if ( (caps & CAP_PV) && emflags =3D=3D 0 )
+        emflags |=3D X86_EMU_PIT;
+
 #ifdef CONFIG_HVM
     /* This doesn't catch !CONFIG_HVM case but it is better than nothing *=
/
     BUILD_BUG_ON(X86_EMU_ALL !=3D XEN_X86_EMU_ALL);
 #endif
=20
-    if ( is_hvm_domain(d) )
-    {
-        if ( is_hardware_domain(d) &&
-             emflags !=3D (X86_EMU_VPCI | X86_EMU_LAPIC | X86_EMU_IOAPIC) =
)
-            return false;
-        if ( !is_hardware_domain(d) &&
-             /* HVM PIRQ feature is user-selectable. */
-             (emflags & ~X86_EMU_USE_PIRQ) !=3D
-             (X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ)) &&
-             emflags !=3D X86_EMU_LAPIC )
-            return false;
-    }
-    else if ( emflags !=3D 0 && emflags !=3D X86_EMU_PIT )
-    {
-        /* PV or classic PVH. */
-        return false;
-    }
+    for ( i =3D 0; i < ARRAY_SIZE(configs); i++ )
+        if ( (caps & configs[i].caps) =3D=3D caps &&
+             (emflags & ~configs[i].opt) =3D=3D configs[i].min )
+            return true;
=20
-    return true;
+    return false;
 }
=20
 void __init arch_init_idle_domain(struct domain *d)
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Tue Jun 10 03:52:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 03:52:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010470.1388565 (Exim 4.92)
	(envelope-from )
	id 1uOq2U-0002af-Fw; Tue, 10 Jun 2025 03:52:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010470.1388565; Tue, 10 Jun 2025 03:52: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 1uOq2U-0002aY-CF; Tue, 10 Jun 2025 03:52:42 +0000
Received: by outflank-mailman (input) for mailman id 1010470;
 Tue, 10 Jun 2025 03:52: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 1uOq2S-0002aS-CF
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 03:52:40 +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 5864037c-45ae-11f0-a305-13f23c93f187;
 Tue, 10 Jun 2025 05:52:37 +0200 (CEST)
Received: from PH7PR12MB5854.namprd12.prod.outlook.com (2603:10b6:510:1d5::20)
 by PH7PR12MB7454.namprd12.prod.outlook.com (2603:10b6:510:20d::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.41; Tue, 10 Jun
 2025 03:52:30 +0000
Received: from PH7PR12MB5854.namprd12.prod.outlook.com
 ([fe80::bd58:fa72:e622:dd76]) by PH7PR12MB5854.namprd12.prod.outlook.com
 ([fe80::bd58:fa72:e622:dd76%7]) with mapi id 15.20.8792.034; Tue, 10 Jun 2025
 03:52: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: 5864037c-45ae-11f0-a305-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=rGOFva877LfRX4mR4KrhM2O0NtLQ3E4rU4Dc8flCt0iQFQli1UkZDS08wKhSG0fx/yIzXVmmTlGUOPsUJOW7c7pyw8Y2L/6huj/7mdjY9LR2ARNDtcI/YSR4Dy3TqJqg6t7mZ5Uaw6OV/Veyy7YPvn/sKBKdO5WPiB+Jtx07DsGOptPAbOklkKv2KlY128gwtsFo5YycQV5RYFt+7CS6QyxPSCowBYQd2o1shezI0FM6ojk9wlIm3T1vDeblzbhedKicgpeO24ZZrjVKscFA1T6a+o4vhjeUTe7doLNA/7ETfwAgGIyjc2mxLAO55PGoAPZB/I1/Q8aJzK/J+K9/eQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=cGJ0Ga4H9xU/1WBXLRrXFNBVV1I3dH8rAJLJuWH4EW8=;
 b=IJYqVdMZjE+O8TQr+axFcCE5ekF6hteubQZXRhE9mDRJYaqq8fm9DPZfYesvV2NLs2YRY/FSFUpeW7ALZd9+L6EeC/RKVoDFMZ2AIPrwjyh+FoWlp+tQUtuSJd3IfsZ+ORvd+Kuaq4pHzutacJgYks5r853LvUes9O/AvCadeoHFma9Q4AqlfJJ8Lnl6kjdhduSQNiK+hs3m1tPHpmfLxolSUrTxl4Zq37v3YXBFMj/8M8zRyoBPPGQLkTarUBUje8dbrshiEwnmsWPTm4SC9/e1NGEpsFDNJI+9ox3Z1Rc+vDqISyZKx/soRhfh8fBWT7ceqs1CGHGTyWxvGY2vkA==
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=cGJ0Ga4H9xU/1WBXLRrXFNBVV1I3dH8rAJLJuWH4EW8=;
 b=hoG+iCKFy/EVCeuOy/bu2gmMOtj4cESmmNRIXfDlBxRegcnOziXwVU+MFlBG/qLNYJRjEC17T5Uojc5KZSFX/qyPmVdqjcnuJzDwnlk7mtCg80IZfppHQ5JJ1O1IzWg2mIMgxYw//4gz2YNi2z9/u9xfcFyr4iQi7d5Q+I6Ild0=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= 
CC: "xen-devel@lists.xenproject.org" , Jan
 Beulich , Andrew Cooper ,
	Anthony PERARD , "Orzel, Michal"
	, Julien Grall , Stefano Stabellini
	, "Huang, Ray" , "Chen, Jiqian"
	
Subject: Re: [PATCH v5 04/10] vpci: Refactor REGISTER_VPCI_INIT
Thread-Topic: [PATCH v5 04/10] vpci: Refactor REGISTER_VPCI_INIT
Thread-Index:
 AQHbziMOHCuaHG697kCTYWoBETQpzrP0lKSAgAGsWwD//4WWAIAAI9IAgAUkMwD//5c1AIAAk1OA//+AeAAANIYcgA==
Date: Tue, 10 Jun 2025 03:52:30 +0000
Message-ID:
 
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
 <20250526094559.140423-5-Jiqian.Chen@amd.com>
 
 
 <752cff02-cef6-4a4c-80b9-eba3bbf9b264@suse.com>
 
 
 
 
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: PH7PR12MB5854.namprd12.prod.outlook.com
 (15.20.8792.033)
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: PH7PR12MB5854:EE_|PH7PR12MB7454:EE_
x-ms-office365-filtering-correlation-id: 3fb40dd2-d8ac-4492-9350-08dda7d2395d
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|366016|1800799024|376014|4053099003|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?bkJMa1FlT01EZ3pYb2FPMjhTbnlwRk8vN1N2S0xRSmtCR3FLT0QwYS9FaEkx?=
 =?utf-8?B?SjJzbnRrMlIreGRUMjYwV3djVmhqcUQ1R1ZjOFprRzNaek9nbzhGSVl1VURR?=
 =?utf-8?B?aC80ZTVaQTQ5ZkZaNFNmT05ONjljRXZDQTZaak52SFl1R0Vja1EraFc3aGR1?=
 =?utf-8?B?YVBIUUtKbHI4Yy9nbDk3S1kveXViSTZvSUdDV3dHK0tBdWN5dmtUYUNIYy9S?=
 =?utf-8?B?R2VSWCsyWExDekgzQnVjSHdlb2ZtY0UyTFFTMnkxUlpDNFp6bnVicTdvMzli?=
 =?utf-8?B?R3NaVlNSNkw3d2JZaWJaMiszSmdncW1mSEVFOXJsemVWNTRUbTM5ZGhRREVT?=
 =?utf-8?B?amhhMGR6ellUdlBSckdjK1V4UzZoc0JWU1JLRVdFNlo5RkIrWkowak1lV3pi?=
 =?utf-8?B?L3QzcHFwVFZGRkUzT0l2TWFZV3JQTWlrYVJLeFI3NVNOZW8xSGphcVR2WUZl?=
 =?utf-8?B?cUxEVGxzL3NmYkkxekV4WGJvYnVIeE9NeVdJQlVrSXlpTDYrbjVDcG5DcFFQ?=
 =?utf-8?B?MW9NUklWTG9UbFE2Y1FWZUgvQXowRDE5bVBPWjlvcFNBdkhJeE5OMGFqTFJu?=
 =?utf-8?B?RDl3VlZpZThkekhsc2ZWK1BodmxzRWZPUGh0WUtyOXRIalJUWDkxLzFnUlZj?=
 =?utf-8?B?aWJSSy9DWmJoeFRicm9talhZancwaXFwTUMySXdsUVlLZXZkNXVHWmJBaTVp?=
 =?utf-8?B?NVRsM3prbStXTFlBc2lHMjk1UzM3WFFZa0sweFFiNHJ1Zldzek43TjR4b0Iz?=
 =?utf-8?B?U1hmNkNvTk94VW9pU1B0WlFZQWplUjF0QnRyMkdoRDBWSU51c3dTV21ZL0t5?=
 =?utf-8?B?QVdvaWt0WUV6V0dUQ2R2QldwWGY4N1BUNTlNU01sbVBHT2tzVE81Q2J6RmFh?=
 =?utf-8?B?WHMxSjZIa2Z0VWZDZUcreXNuZkppdDZreEkwL0xPcHd0clJjL25PWVJZR0tu?=
 =?utf-8?B?OFJhb29oTVdqZFRnWFl5UnFGT0VIbDkybnZMUGU1YXJ1WEJRSS9DYWdqU0Y0?=
 =?utf-8?B?Q2tqVlhIZFF0VDhLUllueEw5bm9PUHBHa2FZUnpjd2RqeTl0cEpmODlGZXBV?=
 =?utf-8?B?RENlMzlUSVlqYmZiRnFzejBlV3ZRYVlCc2VuZGVrRnBFaUlxT3JRSzk3L2hB?=
 =?utf-8?B?NWlzSTNVemM1N0ZiMVJqZE14RlJaUUU5UTVqbjh1VFEyZk9pL3B3bkNpYXhv?=
 =?utf-8?B?OHBWVE5wSkhiUktFZUxJOUl3RWlVOUNOT3pHR29uR0tYVXZWdTF3M3VmWUxl?=
 =?utf-8?B?SE5oZVNkRU14TmdMM2dnekFFU2N2WGtqeGtHVXBHd0lhUHNNZk5qLzRVV3pu?=
 =?utf-8?B?bnNJVUdWNldKZzdVaDgzbU9LZVdULzlCM3QwUHhXbEVkRitNTTEwNTJQQnA2?=
 =?utf-8?B?STZQNjREejNNV0dvSjhaekx6Y1IwaDg4ZHJWSlRWeXZYY2xKMWR1a3V5ZmRq?=
 =?utf-8?B?Yis3N1pwWkxESTlFTHNKRDVFdUF1MCttUmVGcEE3RmkzMGsvL1BTa1NnRkZL?=
 =?utf-8?B?d3F3QnZuNTdOZ0V1cWl4YXV0Q1lSN1BPbGdKd3ZzQ3gzWDNveEd6blhVVHZW?=
 =?utf-8?B?RHdQZWNoRWw4MUowa3hBYllGU2tQMkVjSFN0MnR3amtXTkVGdEQ5cUowdnBN?=
 =?utf-8?B?NHJsYk1ZYjd4M0U2emk1OFRSd2NWZU1GUTNzNi9mbXdCL0luV0JOeUVJUnZa?=
 =?utf-8?B?dTZiRVZnNjZWTVl2N2hiVk5COHhVNW9HcGwyTGR3dzBCK1lhN0lxWjRoaEUw?=
 =?utf-8?B?K3FhaEFJZmJVaGdzcEtVSVRoZ1YvVVNVMkhvTy9Xa08zZURmUnlLZlhweGRB?=
 =?utf-8?B?NWpXNHlKcUNwdUlFbXZvMHI0RkpwZ3JueVNJMDZUSC9LNWlWbGUrVFFqQlp1?=
 =?utf-8?B?bUlNNFQ0ZGVRVmw0KzBuVFdEMzdiMXpTY09TeG1FM0Y2TW5IRWc3azRTcHZx?=
 =?utf-8?B?czdXRTFSK0R2RkVuWDdXSFlwNEU2L2JhZndjNEE0VTcrNHBaeUxZenJXOU93?=
 =?utf-8?Q?M36/hdzZ9zYz0PRpkj7wBYdI4q68aA=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH7PR12MB5854.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(4053099003)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?MEpGcjZvMFJjZGVGZDkwbi8xNFFOc3NrUjVTWGwwbHd4VnVEa0lIRDRXTGNu?=
 =?utf-8?B?dmdMRDVLdlZ1NWdNbDEwT2lhMFhHbEs5akZjU09JTCtmYTZ2NFNiaHBNZkpQ?=
 =?utf-8?B?K2RZSitzSGpiT0JIbytJejM4T1JiMnJ0ZVZ4bUxJaDd0R1Q4bUJRa2tuOEE1?=
 =?utf-8?B?enArVUJHZDdSbDlnZGlWSFV2dElUVVZVZ3lzQW9mOXo4NDNHdkQvcmNCQkls?=
 =?utf-8?B?dXhSN2JvalljYUQrRnIrT1Q2a29VblA0UThrTWl2YzlsSm5jL3JFTG5xTThI?=
 =?utf-8?B?UDY4a3B5ck5ESGVJcktSem9Pa1NTYkhLcFliRE9VTmVlbHdwdXkzRjhKQ2Rk?=
 =?utf-8?B?Rnp4Wmp6V0VYbXI0RmROQXBWd0lBSGo1dnNmUmdTbTRNRWY3RjhzNUIyU3U5?=
 =?utf-8?B?azQ3VkZqQ2loMUtxNktNYXI4R1BrRHE0YzR0TGVZOGpac3k3empmUExDemJy?=
 =?utf-8?B?NU12VDE5OFcxcDNCT290bnJBWWFweUd5d2FkOUlQeHdpSXVjT1p2U29Kdm95?=
 =?utf-8?B?Q0FnTVFsS0xxU1FCaTY4Y3I2eXZLam5MWXI3Y01XMEUxM0x1RVU1Q2RlSm53?=
 =?utf-8?B?MjcrRCtsdXBjK3Z1dzhTSVRyb1FPcVRmb21qTU9PMDB5WUlWeFJzaG5qZTQw?=
 =?utf-8?B?NE1BZDkrTEdFOVd1L2lzMUJMTUs5WlA5R3ArNE1sZmhsMU14VjBkaHpCQzlJ?=
 =?utf-8?B?ZVdSK3FLa0dGVUp4alUrcEZUd1h0ZDdlMmtlZ1VLd1RRVGk1OHdmTUFZaUlG?=
 =?utf-8?B?Y25FQjhZNVQzSmRSd3krcjJwZVJsOTJORGpXZFFPQU1xeUpzZGJ6M0Z3bkkx?=
 =?utf-8?B?YXZJSU5sRjJQQzhSamdITGYzQ1ZDOVk2YzVBOVR3emZnYnhDTjMyWFhINEhJ?=
 =?utf-8?B?K0IydUVxTEVLYlRYMWphSTh1SnVpL3pLNUF2Z0NDWG5MNVl3bkNnMmFHOHd3?=
 =?utf-8?B?dEZ0a1dzSU1WRXJFZ2l1Ry8wR2oxcVRIUWxKQjVHNGVaRjl4dG1ScXd2UHpz?=
 =?utf-8?B?YmdmZUJjeldBajNJUlg0TEJCdjROaEkyd3lDRjFKQitXNzhsZy9Gd0ZGK2J5?=
 =?utf-8?B?MGFYd0RMNGhFVVg4TEo0RzExdjk5WE16M2EzbUlncHpRc1hhbFdwVDB2ekMy?=
 =?utf-8?B?d0xHZzBMVkl3ZEFUcjNVWDY0MFlJeGpnUzE4VlRjUGFWdkRsRVQ3YThEWUVT?=
 =?utf-8?B?aVJnZ3R0T25tQno0NGQrSXZzMCtTblA3RHJpbWdYQ3NHUVJhS0xyS2t2SnZz?=
 =?utf-8?B?VWVJazQ0RXora1Y4TzR0a1BaYnA2WHdZK3JZazNoWWZ1RUliSmlEUWFXS2dl?=
 =?utf-8?B?UjlVVmt4QWFxbVo5RFoxb0ZrUFVvdWRrbVNIS3pISXBqUkhveUVJSkFiK0tW?=
 =?utf-8?B?QTh3QmwzaDNNK2hqdHBzQTZsZHNVREtMWHRvVlBuN3lEK3NwRlJoOWlsQ0lR?=
 =?utf-8?B?eElKRWJBdXNJU1c5Z2QvUXpvUllDZHRNb04vVlgwL2NYMmxaRGJ4NGxnVXg5?=
 =?utf-8?B?Z2E3MnFkYVFRdnhYTm1PaTUxem5DWWlpdW1pQzAwZlpDWW1JTHh5N083K29k?=
 =?utf-8?B?S1IxT0xRdzlxSlE4enFCUWNRb1VTbFVranVTNVd0cUQ2N1pOSmszNE52ejNp?=
 =?utf-8?B?WGFveU8yY0s1dGVyOWE5NDZ0VUhFcWMrZS9vTGljOHl2QnlzZnI0OG0rbW4w?=
 =?utf-8?B?V29FQUE1eHBubzFSeGs1WGVwRHFCd2poK1UwUXlmZEpTZTRoUGVOa0M4QW1L?=
 =?utf-8?B?b2ZpTVRZVlordkJlaVNoMHpuQkgzV1V2T0RXNHBnMU8rRjZZbnFRY0Y4NEsy?=
 =?utf-8?B?QnZaSlhDNDNUVjlHNW1FL2I5KytXSTlvUUU5Vkpjd0xJNFdGLytZUUpPa2gw?=
 =?utf-8?B?ZnJoMjZpeXM4VGVrUDFDNGhnb0FFUzhiSGkrR2V5c3Q5SnNXRzdya3JYVm9y?=
 =?utf-8?B?S1c1NGVHN3MvMkNxa2dOUXNPVDd2TCt0cXg4NDVqTEhpT2xWT2VkQis1T0g5?=
 =?utf-8?B?ZEg2OHV0UTJFUEZpaVIrTDFwaFlPekNtTVZDeno0UU1kMUZLcWR3SitKVDlC?=
 =?utf-8?B?blIvWTYyVkMzZTVETmdBclM2d2dVbUhGUTh4Y1lzdXlRRFZUUzN6ZGdUMUlY?=
 =?utf-8?Q?wpXs=3D?=
Content-Type: multipart/mixed;
	boundary="_003_PH7PR12MB5854FC2E82CD17483B6B6BCFE76AAPH7PR12MB5854namp_"
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH7PR12MB5854.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3fb40dd2-d8ac-4492-9350-08dda7d2395d
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2025 03:52:30.3860
 (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: D/Tx5oYMUidBuiCW19GZIr1+nflXFwV57YzOik314LsMytOM7PNrxijRkcbhHCQxzkPkG8oi6hKEnJ/2SplJWQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB7454

--_003_PH7PR12MB5854FC2E82CD17483B6B6BCFE76AAPH7PR12MB5854namp_
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

T24gMjAyNS82LzkgMTg6NDAsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+IE9uIE1vbiwgSnVu
IDA5LCAyMDI1IGF0IDEwOjE4OjQyQU0gKzAwMDAsIENoZW4sIEppcWlhbiB3cm90ZToNCj4+IE9u
IDIwMjUvNi85IDE3OjI5LCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOg0KPj4+IE9uIE1vbiwgSnVu
IDA5LCAyMDI1IGF0IDA3OjUwOjIxQU0gKzAwMDAsIENoZW4sIEppcWlhbiB3cm90ZToNCj4+Pj4g
T24gMjAyNS82LzYgMTc6MTQsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+Pj4+PiBPbiBGcmks
IEp1biAwNiwgMjAyNSBhdCAwOTowNTo0OEFNICswMjAwLCBKYW4gQmV1bGljaCB3cm90ZToNCj4+
Pj4+PiBPbiAwNi4wNi4yMDI1IDA4OjI5LCBDaGVuLCBKaXFpYW4gd3JvdGU6DQo+Pj4+Pj4+IE9u
IDIwMjUvNi81IDIwOjUwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOg0KPj4+Pj4+Pj4gT24gTW9u
LCBNYXkgMjYsIDIwMjUgYXQgMDU6NDU6NTNQTSArMDgwMCwgSmlxaWFuIENoZW4gd3JvdGU6IA0K
Pj4+Pj4+Pj4+ICsgIH07IFwNCj4+Pj4+Pj4+PiArICBzdGF0aWMgdnBjaV9jYXBhYmlsaXR5X3Qg
KmNvbnN0IGZpbml0IyNfZW50cnkgIFwNCj4+Pj4+Pj4+PiArICAgICAgICAgICAgICAgX191c2Vk
X3NlY3Rpb24oIi5kYXRhLnZwY2kiKSA9ICZmaW5pdCMjX3QNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBJ
TU8gdGhpcyBzaG91bGQgYmV0dGVyIHVzZSAucm9kYXRhIGluc3RlYWQgb2YgLmRhdGEuIA0KPj4+
Pj4+PiBJcyBiZWxvdyBjaGFuZ2UgY29ycmVjdD8NCj4+Pj4+Pj4NCj4+Pj4+Pj4gKyAgICBzdGF0
aWMgY29uc3QgdnBjaV9jYXBhYmlsaXR5X3QgKmNvbnN0IGZpbml0IyNfZW50cnkgIFwNCj4+Pj4+
Pj4gKyAgICAgICAgX191c2VkX3NlY3Rpb24oIi5yb2RhdGEiKSA9ICZmaW5pdCMjX3QNCj4+Pj4+
Pg0KPj4+Pj4+IE5vLCBzcGVjaWZpY2FsbHkgYmVjYXVzZSAuLi4NCj4+Pj4+Pg0KPj4+Pj4+Pj4g
Tm90IHRoYXQgaXQgbWF0dGVycyBtdWNoIGluIHByYWN0aWNlLCBhcyB3ZSBwbGFjZSBpdCBpbiAu
cm9kYXRhIGFueXdheS4gIE5vdGUNCj4+Pj4+Pj4+IGhvd2V2ZXIgeW91IHdpbGwgaGF2ZSB0byBt
b3ZlIHRoZSBwbGFjZW1lbnQgb2YgdGhlIFZQQ0lfQVJSQVkgaW4gdGhlDQo+Pj4+Pj4+PiBsaW5r
ZXIgc2NyaXB0IGFoZWFkIG9mICooLnJvZGF0YS4qKSwgb3RoZXJ3aXNlIHRoYXQgc2VjdGlvbiBt
YXRjaCB3aWxsDQo+Pj4+Pj4+PiBjb25zdW1lIHRoZSB2UENJIGRhdGEuDQo+Pj4+Pj4+IEkgYW0g
c29ycnksIGhvdyB0byBtb3ZlIGl0IGFoZWFkIG9mICooLnJvZGF0YS4qKSA/DQo+Pj4+Pj4+IElz
IGJlbG93IGNoYW5nZSBjb3JyZWN0Pw0KPj4+Pj4+Pg0KPj4+Pj4+PiBkaWZmIC0tZ2l0IGEveGVu
L2luY2x1ZGUveGVuL3hlbi5sZHMuaCBiL3hlbi9pbmNsdWRlL3hlbi94ZW4ubGRzLmgNCj4+Pj4+
Pj4gaW5kZXggNzkzZDBlMTE0NTBjLi4zODE3NjQyMTM1YWEgMTAwNjQ0DQo+Pj4+Pj4+IC0tLSBh
L3hlbi9pbmNsdWRlL3hlbi94ZW4ubGRzLmgNCj4+Pj4+Pj4gKysrIGIveGVuL2luY2x1ZGUveGVu
L3hlbi5sZHMuaA0KPj4+Pj4+PiBAQCAtMTg4LDcgKzE4OCw3IEBADQo+Pj4+Pj4+ICAjZGVmaW5l
IFZQQ0lfQVJSQVkgICAgICAgICAgICAgICBcDQo+Pj4+Pj4+ICAgICAgICAgLiA9IEFMSUdOKFBP
SU5URVJfQUxJR04pOyBcDQo+Pj4+Pj4+ICAgICAgICAgX19zdGFydF92cGNpX2FycmF5ID0gLjsg
ICBcDQo+Pj4+Pj4+IC0gICAgICAgKihTT1JUKC5kYXRhLnZwY2kuKikpICAgICBcDQo+Pj4+Pj4+
ICsgICAgICAgKigucm9kYXRhKSAgICAgICAgICAgICBcDQo+Pj4+Pj4NCj4+Pj4+PiAuLi4gdGhp
cyBpc24ndCAtIHlvdSdkIG1vdmUgX2FsbF8gb2YgLnJvZGF0YSBpbnRvIGhlcmUsIHdoaWNoIGRl
ZmluaXRlbHkNCj4+Pj4+PiBpc24ndCB3aGF0IHlvdSB3YW50LiBXaGF0IEkgdW5kZXJzdGFuZCBS
b2dlciBtZWFudCB3YXMgYSAucm9kYXRhLWxpa2UNCj4+Pj4+PiBzZWN0aW9uLCBlLmcuIC5yb2Rh
dGEudnBjaS4qIChtdWNoIGxpa2UgaXQgd2FzIC5kYXRhLnZwY2kuKiBiZWZvcmUpLg0KPj4+Pj4N
Cj4+Pj4+IEluZGVlZCwgbXkgc3VnZ2VzdGlvbiB3YXMgbWVyZWx5IHRvIHVzZSAucm9kYXRhIGlu
c3RlYWQgb2YgLmRhdGEsIGFzDQo+Pj4+PiB0aGF0J3MgbW9yZSBhY2N1cmF0ZSBJTU8uICBJIHRo
aW5rIGl0IHNob3VsZCBiZSAqKC5yb2RhdGEudnBjaSkgKGFuZA0KPj4+Pj4gc2FtZSBzZWN0aW9u
IGNoYW5nZSBmb3IgdGhlIF9fdXNlZF9zZWN0aW9uKCkgYXR0cmlidXRlLg0KPj4+Pg0KPj4+PiBJ
ZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5LCB0aGUgbmV4dCB2ZXJzaW9uIHdpbGwgYmU6DQo+Pj4+
DQo+Pj4+ICsgICAgc3RhdGljIGNvbnN0IHZwY2lfY2FwYWJpbGl0eV90ICpjb25zdCBmaW5pdCMj
X2VudHJ5ICBcDQo+Pj4+ICsgICAgICAgIF9fdXNlZF9zZWN0aW9uKCIucm9kYXRhLnZwY2kiKSA9
ICZmaW5pdCMjX3QNCj4+Pj4gKw0KPj4+Pg0KPj4+PiBhbmQNCj4+Pj4NCj4+Pj4gICNkZWZpbmUg
VlBDSV9BUlJBWSAgICAgICAgICAgICAgIFwNCj4+Pj4gICAgICAgICAuID0gQUxJR04oUE9JTlRF
Ul9BTElHTik7IFwNCj4+Pj4gICAgICAgICBfX3N0YXJ0X3ZwY2lfYXJyYXkgPSAuOyAgIFwNCj4+
Pj4gLSAgICAgICAqKFNPUlQoLmRhdGEudnBjaS4qKSkgICAgIFwNCj4+Pj4gKyAgICAgICAqKC5y
b2RhdGEudnBjaSkgICAgICAgICAgIFwNCj4+Pj4gICAgICAgICBfX2VuZF92cGNpX2FycmF5ID0g
LjsNCj4+Pg0KPj4+IERpZCB5b3UgYWxzbyBtb3ZlIHRoZSBpbnN0YW5jZXMgb2YgVlBDSV9BUlJB
WSBpbiB0aGUgbGlua2VyIHNjcmlwdHMgc28NCj4+PiBpdCdzIGJlZm9yZSB0aGUgY2F0Y2gtYWxs
ICooLnJvZGF0YS4qKT8NCj4+Pg0KPj4+Pg0KPj4+PiBCdXQsIHRoYXQgZW5jb3VudGVyZWQgYW4g
d2FybmluZyB3aGVuIGNvbXBpbGluZy4NCj4+Pj4gIiB7c3RhbmRhcmQgaW5wdXR9OiBBc3NlbWJs
ZXIgbWVzc2FnZXM6DQo+Pj4+IHtzdGFuZGFyZCBpbnB1dH06MTE2MDogV2FybmluZzogc2V0dGlu
ZyBpbmNvcnJlY3Qgc2VjdGlvbiBhdHRyaWJ1dGVzIGZvciAucm9kYXRhLnZwY2kNCj4+Pj4ge3N0
YW5kYXJkIGlucHV0fTogQXNzZW1ibGVyIG1lc3NhZ2VzOg0KPj4+PiB7c3RhbmRhcmQgaW5wdXR9
OjMwMzQ6IFdhcm5pbmc6IHNldHRpbmcgaW5jb3JyZWN0IHNlY3Rpb24gYXR0cmlidXRlcyBmb3Ig
LnJvZGF0YS52cGNpDQo+Pj4+IHtzdGFuZGFyZCBpbnB1dH06IEFzc2VtYmxlciBtZXNzYWdlczoN
Cj4+Pj4ge3N0YW5kYXJkIGlucHV0fTo2Njg2OiBXYXJuaW5nOiBzZXR0aW5nIGluY29ycmVjdCBz
ZWN0aW9uIGF0dHJpYnV0ZXMgZm9yIC5yb2RhdGEudnBjaSAiDQo+Pj4NCj4+PiBXaGF0IGFyZSB0
aGUgYXR0cmlidXRlcyBmb3IgLnJvZGF0YS52cGNpIGluIHRoZSBvYmplY3QgZmlsZXM/ICBZb3Ug
Y2FuDQo+Pj4gZ2V0IHRob3NlIHVzaW5nIG9iamR1bXAgb3IgcmVhZGVsZiwgZm9yIGV4YW1wbGU6
DQo+Pj4NCj4+PiAkIG9iamR1bXAgLWggeGVuL2RyaXZlcnMvdnBjaS9tc2kubw0KPj4+IFsuLi5d
DQo+Pj4gIDE3IC5kYXRhLnZwY2kuOSAgMDAwMDAwMDggIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAw
MDAwMDAwMDAwMDAgIDAwMDAwYTUwICAyKiozDQo+Pj4gICAgICAgICAgICAgICAgICAgQ09OVEVO
VFMsIEFMTE9DLCBMT0FELCBSRUxPQywgREFUQQ0KPj4+DQo+Pj4gSXQgc2hvdWxkIGJlIFJFQURP
TkxZLCBvdGhlcndpc2UgeW91IHdpbGwgZ2V0IHRob3NlIG1lc3NhZ2VzLg0KPj4+DQo+Pj4+IEFu
ZCwgZHVyaW5nIGJvb3RpbmcgWGVuLCBhbGwgdmFsdWUgb2YgX19zdGFydF92cGNpX2FycmF5IGlz
IGluY29ycmVjdC4NCj4+Pj4gRG8gSSBtaXNzIGFueXRoaW5nPw0KPj4+DQo+Pj4gSSB0aGluayB0
aGF0J3MgbGlrZWx5IGJlY2F1c2UgeW91IGhhdmVuJ3QgbW92ZWQgdGhlIGluc3RhbmNlIG9mDQo+
Pj4gVlBDSV9BUlJBWSBpbiB0aGUgbGlua2VyIHNjcmlwdD8NCj4+IE9oLCByaWdodC4gU29ycnks
IEkgZm9yZ290IHRvIG1vdmUgaXQuDQo+PiBBZnRlciBjaGFuZ2luZyB0aGlzLCBpdCB3b3JrcyBu
b3cuDQo+Pg0KPj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni94ZW4ubGRzLlMgYi94ZW4vYXJj
aC94ODYveGVuLmxkcy5TDQo+PiBpbmRleCBiZjk1NmI2YzVmYzAuLmM4OGZkNjJmNGYwZCAxMDA2
NDQNCj4+IC0tLSBhL3hlbi9hcmNoL3g4Ni94ZW4ubGRzLlMNCj4+ICsrKyBiL3hlbi9hcmNoL3g4
Ni94ZW4ubGRzLlMNCj4+IEBAIC0xMzQsNiArMTM0LDcgQEAgU0VDVElPTlMNCj4+ICAgICAgICAg
QlVHRlJBTUVTDQo+Pg0KPj4gICAgICAgICAqKC5yb2RhdGEpDQo+PiArICAgICAgIFZQQ0lfQVJS
QVkNCj4+ICAgICAgICAgKigucm9kYXRhLiopDQo+PiAgICAgICAgICooLmRhdGEucmVsLnJvKQ0K
Pj4gICAgICAgICAqKC5kYXRhLnJlbC5yby4qKQ0KPj4gQEAgLTE0OCw3ICsxNDksNiBAQCBTRUNU
SU9OUw0KPj4gICAgICAgICAqKC5ub3RlLmdudS5idWlsZC1pZCkNCj4+ICAgICAgICAgX19ub3Rl
X2dudV9idWlsZF9pZF9lbmQgPSAuOw0KPj4gICNlbmRpZg0KPj4gLSAgICAgICBWUENJX0FSUkFZ
DQo+PiAgICB9IFBIRFIodGV4dCkNCj4gDQo+IEZXSVcsIEkgd291bGQgcHV0IGl0IGFoZWFkIG9m
ICooLnJvZGF0YSkuICBSZW1lbWJlciB0byBhbHNvIG1vZGlmeSB0aGUNCj4gbGlua2VyIHNjcmlw
dCBmb3IgYWxsIHRoZSBvdGhlciBhcmNoZXMsIG5vdCBqdXN0IHg4Ni4NCg0KV2hldGhlciBiZWZv
cmUgKigucm9kYXRhLiopIG9yIGJlZm9yZSAqKC5yb2RhdGEpLCB0aGVyZSBzdGlsbCBpcyB0aGUg
d2FybmluZyAiIFdhcm5pbmc6IHNldHRpbmcgaW5jb3JyZWN0IHNlY3Rpb24gYXR0cmlidXRlcyBm
b3IgLnJvZGF0YS52cGNpICINCkFuZCB0aGUgb2JqZHVtcCBzaG93cyAicm9kYXRhLnZwY2kiIGhh
cyBubyAicmVhZG9ubHkiIHdvcmQuDQpCdXQgc3RhcnRpbmcgWGVuIGRvbTAgaXMgT0suDQpJIGF0
dGFjaGVkIHRoZSBuZXcgdGhpcyBwYXRjaCBhbmQgdGhlIHJlc3VsdCBvZiAib2JqZHVtcCAtaCB4
ZW4vZHJpdmVycy92cGNpL21zaS5vIg0KDQo+IA0KPiBUaGFua3MsIFJvZ2VyLg0KDQotLSANCkJl
c3QgcmVnYXJkcywNCkppcWlhbiBDaGVuLg0K

--_003_PH7PR12MB5854FC2E82CD17483B6B6BCFE76AAPH7PR12MB5854namp_
Content-Type: text/plain; name="objdump_before_rodata.txt"
Content-Description: objdump_before_rodata.txt
Content-Disposition: attachment; filename="objdump_before_rodata.txt";
	size=5787; creation-date="Tue, 10 Jun 2025 03:50:28 GMT";
	modification-date="Tue, 10 Jun 2025 03:52:29 GMT"
Content-Transfer-Encoding: base64

Ci4veGVuL2RyaXZlcnMvdnBjaS9tc2kubzogICAgIGZpbGUgZm9ybWF0IGVsZjY0LXg4Ni02NAoK
U2VjdGlvbnM6CklkeCBOYW1lICAgICAgICAgIFNpemUgICAgICBWTUEgICAgICAgICAgICAgICBM
TUEgICAgICAgICAgICAgICBGaWxlIG9mZiAgQWxnbgogIDAgLnRleHQgICAgICAgICAwMDAwMDAw
MCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwNDAgIDIqKjAKICAg
ICAgICAgICAgICAgICAgQ09OVEVOVFMsIEFMTE9DLCBMT0FELCBSRUFET05MWSwgQ09ERQogIDEg
LmRhdGEgICAgICAgICAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAw
MCAgMDAwMDAwNDAgIDIqKjAKICAgICAgICAgICAgICAgICAgQ09OVEVOVFMsIEFMTE9DLCBMT0FE
LCBEQVRBCiAgMiAuYnNzICAgICAgICAgIDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwICAwMDAw
MDAwMDAwMDAwMDAwICAwMDAwMDA0MCAgMioqMAogICAgICAgICAgICAgICAgICBBTExPQwogIDMg
LnRleHQuX2Nhbl9yZWFkX2xvY2sgMDAwMDAwNTIgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAw
MDAwMDAwMDAgIDAwMDAwMDQwICAyKiowCiAgICAgICAgICAgICAgICAgIENPTlRFTlRTLCBBTExP
QywgTE9BRCwgUkVMT0MsIFJFQURPTkxZLCBDT0RFCiAgNCAudGV4dC5hZGRyZXNzX3JlYWQgMDAw
MDAwMGIgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDkyICAyKiow
CiAgICAgICAgICAgICAgICAgIENPTlRFTlRTLCBBTExPQywgTE9BRCwgUkVMT0MsIFJFQURPTkxZ
LCBDT0RFCiAgNSAudGV4dC5hZGRyZXNzX2hpX3JlYWQgMDAwMDAwMTAgIDAwMDAwMDAwMDAwMDAw
MDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDlkICAyKiowCiAgICAgICAgICAgICAgICAgIENP
TlRFTlRTLCBBTExPQywgTE9BRCwgUkVMT0MsIFJFQURPTkxZLCBDT0RFCiAgNiAudGV4dC5kYXRh
X3JlYWQgMDAwMDAwMGQgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAw
MGFkICAyKiowCiAgICAgICAgICAgICAgICAgIENPTlRFTlRTLCBBTExPQywgTE9BRCwgUkVMT0Ms
IFJFQURPTkxZLCBDT0RFCiAgNyAudGV4dC5tYXNrX3JlYWQgMDAwMDAwMGMgIDAwMDAwMDAwMDAw
MDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMGJhICAyKiowCiAgICAgICAgICAgICAgICAg
IENPTlRFTlRTLCBBTExPQywgTE9BRCwgUkVMT0MsIFJFQURPTkxZLCBDT0RFCiAgOCAudGV4dC5t
YXNrX3dyaXRlIDAwMDAwMDc4ICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwICAw
MDAwMDBjNiAgMioqMAogICAgICAgICAgICAgICAgICBDT05URU5UUywgQUxMT0MsIExPQUQsIFJF
TE9DLCBSRUFET05MWSwgQ09ERQogIDkgLnRleHQuYWRkcmVzc19oaV93cml0ZSAwMDAwMDAyNyAg
MDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAxM2UgIDIqKjAKICAgICAg
ICAgICAgICAgICAgQ09OVEVOVFMsIEFMTE9DLCBMT0FELCBSRUxPQywgUkVBRE9OTFksIENPREUK
IDEwIC50ZXh0LmNvbnRyb2xfcmVhZCAwMDAwMDA0ZSAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAw
MDAwMDAwMDAwMCAgMDAwMDAxNjUgIDIqKjAKICAgICAgICAgICAgICAgICAgQ09OVEVOVFMsIEFM
TE9DLCBMT0FELCBSRUxPQywgUkVBRE9OTFksIENPREUKIDExIC50ZXh0LmNvbnRyb2xfd3JpdGUg
MDAwMDAxNDQgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMWIzICAy
KiowCiAgICAgICAgICAgICAgICAgIENPTlRFTlRTLCBBTExPQywgTE9BRCwgUkVMT0MsIFJFQURP
TkxZLCBDT0RFCiAxMiAuYWx0aW5zdHJ1Y3Rpb25zIDAwMDAwMDcwICAwMDAwMDAwMDAwMDAwMDAw
ICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDJmNyAgMioqMAogICAgICAgICAgICAgICAgICBDT05U
RU5UUywgQUxMT0MsIExPQUQsIFJFTE9DLCBSRUFET05MWSwgREFUQQogMTMgLmRpc2NhcmQgICAg
ICAwMDAwMDAxMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAzNjcg
IDIqKjAKICAgICAgICAgICAgICAgICAgQ09OVEVOVFMsIEFMTE9DLCBMT0FELCBSRUFET05MWSwg
REFUQQogMTQgLmFsdGluc3RyX3JlcGxhY2VtZW50IDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAw
ICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDM3NyAgMioqMAogICAgICAgICAgICAgICAgICBDT05U
RU5UUywgQUxMT0MsIExPQUQsIFJFQURPTkxZLCBDT0RFCiAxNSAudGV4dC5fcmVhZF90cnlsb2Nr
IDAwMDAwMDkwICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDM3NyAg
MioqMAogICAgICAgICAgICAgICAgICBDT05URU5UUywgQUxMT0MsIExPQUQsIFJFTE9DLCBSRUFE
T05MWSwgQ09ERQogMTYgLnRleHQuX3JlYWRfdW5sb2NrIDAwMDAwMDM2ICAwMDAwMDAwMDAwMDAw
MDAwICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDQwNyAgMioqMAogICAgICAgICAgICAgICAgICBD
T05URU5UUywgQUxMT0MsIExPQUQsIFJFTE9DLCBSRUFET05MWSwgQ09ERQogMTcgLnRleHQuY2xl
YW51cF9tc2kgMDAwMDAwZGMgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAw
MDAwNDNkICAyKiowCiAgICAgICAgICAgICAgICAgIENPTlRFTlRTLCBBTExPQywgTE9BRCwgUkVM
T0MsIFJFQURPTkxZLCBDT0RFCiAxOCAucm9kYXRhLmluaXRfbXNpLnN0cjEuMSAwMDAwMDAyYSAg
MDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDA1MTkgIDIqKjAKICAgICAg
ICAgICAgICAgICAgQ09OVEVOVFMsIEFMTE9DLCBMT0FELCBSRUFET05MWSwgREFUQQogMTkgLnRl
eHQuaW5pdF9tc2kgMDAwMDAyNzAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAg
IDAwMDAwNTQzICAyKiowCiAgICAgICAgICAgICAgICAgIENPTlRFTlRTLCBBTExPQywgTE9BRCwg
UkVMT0MsIFJFQURPTkxZLCBDT0RFCiAyMCAuYnVnX2ZyYW1lcy4zIDAwMDAwMDIwICAwMDAwMDAw
MDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDdiNCAgMioqMgogICAgICAgICAgICAg
ICAgICBDT05URU5UUywgQUxMT0MsIExPQUQsIFJFTE9DLCBSRUFET05MWSwgREFUQQogMjEgLnRl
eHQuYWRkcmVzc193cml0ZSAwMDAwMDAzOSAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAw
MDAwMCAgMDAwMDA3ZDQgIDIqKjAKICAgICAgICAgICAgICAgICAgQ09OVEVOVFMsIEFMTE9DLCBM
T0FELCBSRUxPQywgUkVBRE9OTFksIENPREUKIDIyIC50ZXh0LmRhdGFfd3JpdGUgMDAwMDAwMjgg
IDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwODBkICAyKiowCiAgICAg
ICAgICAgICAgICAgIENPTlRFTlRTLCBBTExPQywgTE9BRCwgUkVMT0MsIFJFQURPTkxZLCBDT0RF
CiAyMyAucm9kYXRhLnZwY2lfZHVtcF9tc2kuc3RyMS4xIDAwMDAwMDlhICAwMDAwMDAwMDAwMDAw
MDAwICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDgzNSAgMioqMAogICAgICAgICAgICAgICAgICBD
T05URU5UUywgQUxMT0MsIExPQUQsIFJFQURPTkxZLCBEQVRBCiAyNCAucm9kYXRhLnZwY2lfZHVt
cF9tc2kuc3RyMS44IDAwMDAwMDdmICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAw
ICAwMDAwMDhkMCAgMioqMwogICAgICAgICAgICAgICAgICBDT05URU5UUywgQUxMT0MsIExPQUQs
IFJFQURPTkxZLCBEQVRBCiAyNSAudGV4dC52cGNpX2R1bXBfbXNpIDAwMDAwMmFmICAwMDAwMDAw
MDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDk0ZiAgMioqMAogICAgICAgICAgICAg
ICAgICBDT05URU5UUywgQUxMT0MsIExPQUQsIFJFTE9DLCBSRUFET05MWSwgQ09ERQogMjYgLnJv
ZGF0YS52cGNpICAwMDAwMDAwOCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMCAg
MDAwMDBjMDAgIDIqKjMKICAgICAgICAgICAgICAgICAgQ09OVEVOVFMsIEFMTE9DLCBMT0FELCBS
RUxPQywgREFUQQogMjcgLmRhdGEucmVsLnJvLmxvY2FsLmluaXRfbXNpX3QgMDAwMDAwMTggIDAw
MDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwYzEwICAyKio0CiAgICAgICAg
ICAgICAgICAgIENPTlRFTlRTLCBBTExPQywgTE9BRCwgUkVMT0MsIERBVEEKIDI4IC5kZWJ1Z19p
bmZvICAgMDAwMGFlODMgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAw
YzI4ICAyKiowCiAgICAgICAgICAgICAgICAgIENPTlRFTlRTLCBSRUxPQywgUkVBRE9OTFksIERF
QlVHR0lORywgT0NURVRTCiAyOSAuZGVidWdfYWJicmV2IDAwMDAwODkyICAwMDAwMDAwMDAwMDAw
MDAwICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwYmFhYiAgMioqMAogICAgICAgICAgICAgICAgICBD
T05URU5UUywgUkVBRE9OTFksIERFQlVHR0lORywgT0NURVRTCiAzMCAuZGVidWdfbG9jbGlzdHMg
MDAwMDBmZmMgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDBjMzNkICAy
KiowCiAgICAgICAgICAgICAgICAgIENPTlRFTlRTLCBSRUxPQywgUkVBRE9OTFksIERFQlVHR0lO
RywgT0NURVRTCiAzMSAuZGVidWdfYXJhbmdlcyAwMDAwMDEyMCAgMDAwMDAwMDAwMDAwMDAwMCAg
MDAwMDAwMDAwMDAwMDAwMCAgMDAwMGQzMzkgIDIqKjAKICAgICAgICAgICAgICAgICAgQ09OVEVO
VFMsIFJFTE9DLCBSRUFET05MWSwgREVCVUdHSU5HLCBPQ1RFVFMKIDMyIC5kZWJ1Z19ybmdsaXN0
cyAwMDAwMDIxMiAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMGQ0NTkg
IDIqKjAKICAgICAgICAgICAgICAgICAgQ09OVEVOVFMsIFJFTE9DLCBSRUFET05MWSwgREVCVUdH
SU5HLCBPQ1RFVFMKIDMzIC5kZWJ1Z19saW5lICAgMDAwMDBlMzAgIDAwMDAwMDAwMDAwMDAwMDAg
IDAwMDAwMDAwMDAwMDAwMDAgIDAwMDBkNjZiICAyKiowCiAgICAgICAgICAgICAgICAgIENPTlRF
TlRTLCBSRUxPQywgUkVBRE9OTFksIERFQlVHR0lORywgT0NURVRTCiAzNCAuZGVidWdfc3RyICAg
IDAwMDA1MDJiICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwZTQ5YiAg
MioqMAogICAgICAgICAgICAgICAgICBDT05URU5UUywgUkVBRE9OTFksIERFQlVHR0lORywgT0NU
RVRTCiAzNSAuZGVidWdfbGluZV9zdHIgMDAwMDA0NzAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAw
MDAwMDAwMDAwMDAgIDAwMDEzNGM2ICAyKiowCiAgICAgICAgICAgICAgICAgIENPTlRFTlRTLCBS
RUFET05MWSwgREVCVUdHSU5HLCBPQ1RFVFMKIDM2IC5jb21tZW50ICAgICAgMDAwMDAwMmMgIDAw
MDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDEzOTM2ICAyKiowCiAgICAgICAg
ICAgICAgICAgIENPTlRFTlRTLCBSRUFET05MWQogMzcgLm5vdGUuR05VLXN0YWNrIDAwMDAwMDAw
ICAwMDAwMDAwMDAwMDAwMDAwICAwMDAwMDAwMDAwMDAwMDAwICAwMDAxMzk2MiAgMioqMAogICAg
ICAgICAgICAgICAgICBDT05URU5UUywgUkVBRE9OTFkKIDM4IC5ub3RlLmdudS5wcm9wZXJ0eSAw
MDAwMDAyMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMTM5NjggIDIq
KjMKICAgICAgICAgICAgICAgICAgQ09OVEVOVFMsIEFMTE9DLCBMT0FELCBSRUFET05MWSwgREFU
QQogMzkgLmRlYnVnX2ZyYW1lICAwMDAwMDJkMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDAwMDAw
MDAwMDAwMCAgMDAwMTM5ODggIDIqKjMKICAgICAgICAgICAgICAgICAgQ09OVEVOVFMsIFJFTE9D
LCBSRUFET05MWSwgREVCVUdHSU5HLCBPQ1RFVFMK

--_003_PH7PR12MB5854FC2E82CD17483B6B6BCFE76AAPH7PR12MB5854namp_
Content-Type: application/octet-stream;
	name="0003-vpci-Refactor-REGISTER_VPCI_INIT.patch"
Content-Description: 0003-vpci-Refactor-REGISTER_VPCI_INIT.patch
Content-Disposition: attachment;
	filename="0003-vpci-Refactor-REGISTER_VPCI_INIT.patch"; size=11360;
	creation-date="Tue, 10 Jun 2025 03:50:18 GMT";
	modification-date="Tue, 10 Jun 2025 03:52:30 GMT"
Content-Transfer-Encoding: base64

RnJvbSBmZjJkNDNjMWI2MWU5ZmMxYmJiYTBhNDAyOGFiMjc4YWExYzIxYTdlIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBKaXFpYW4gQ2hlbiA8SmlxaWFuLkNoZW5AYW1kLmNvbT4KRGF0
ZTogV2VkLCAxNiBBcHIgMjAyNSAxNjozODowNyArMDgwMApTdWJqZWN0OiBbUEFUQ0ggMy85XSB2
cGNpOiBSZWZhY3RvciBSRUdJU1RFUl9WUENJX0lOSVQKTUlNRS1WZXJzaW9uOiAxLjAKQ29udGVu
dC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PVVURi04CkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rp
bmc6IDhiaXQKClJlZmFjdG9yIFJFR0lTVEVSX1ZQQ0lfSU5JVCB0byBjb250YWluIG1vcmUgY2Fw
YWJpbGl0eSBzcGVjaWZpYwppbmZvcm1hdGlvbiwgdGhpcyB3aWxsIGJlbmVmaXQgZnVydGhlciBm
b2xsb3ctb24gY2hhbmdlcyB0byBoaWRlCmNhcGFiaWxpdHkgd2hlbiBpbml0aWFsaXphdGlvbiBm
YWlscy4KCldoYXQncyBtb3JlLCBjaGFuZ2UgdGhlIGRlZmluaXRpb24gb2YgaW5pdF9oZWFkZXIo
KSBzaW5jZSBpdCBpcwpub3QgYSBjYXBhYmlsaXR5IGFuZCBpdCBpcyBuZWVkZWQgZm9yIGFsbCBk
ZXZpY2VzJyBQQ0kgY29uZmlnIHNwYWNlLgoKQWZ0ZXIgcmVmYWN0b3IsIHRoZSAicHJpb3JpdHki
IG9mIGluaXRpYWxpemluZyBjYXBhYmlsaXRpZXMgaXNuJ3QKbmVlZGVkIGFueW1vcmUsIHNvIGRl
bGV0ZSBpdHMgcmVsYXRlZCBjb2Rlcy4KCk5vdGU6CkNhbGwgdnBjaV9tYWtlX21zaXhfaG9sZSgp
IGluIHRoZSBlbmQgb2YgaW5pdF9tc2l4KCkgc2luY2UgdGhlIGNoYW5nZQpvZiBzZXF1ZW5jZSBv
ZiBpbml0X2hlYWRlcigpIGFuZCBpbml0X21zaXgoKS4KClRoZSBjbGVhbnVwIGhvb2sgaXMgYWxz
byBhZGRlZCBpbiB0aGlzIGNoYW5nZSwgZXZlbiBpZiBpdCdzIHN0aWxsCnVudXNlZC4gRnVydGhl
ciBjaGFuZ2VzIHdpbGwgbWFrZSB1c2Ugb2YgaXQuCgpTaWduZWQtb2ZmLWJ5OiBKaXFpYW4gQ2hl
biA8SmlxaWFuLkNoZW5AYW1kLmNvbT4KLS0tCmNjOiAiUm9nZXIgUGF1IE1vbm7DqSIgPHJvZ2Vy
LnBhdUBjaXRyaXguY29tPgpjYzogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4
LmNvbT4KY2M6IEFudGhvbnkgUEVSQVJEIDxhbnRob255LnBlcmFyZEB2YXRlcy50ZWNoPgpjYzog
TWljaGFsIE9yemVsIDxtaWNoYWwub3J6ZWxAYW1kLmNvbT4KY2M6IEphbiBCZXVsaWNoIDxqYmV1
bGljaEBzdXNlLmNvbT4KY2M6IEp1bGllbiBHcmFsbCA8anVsaWVuQHhlbi5vcmc+CmNjOiBTdGVm
YW5vIFN0YWJlbGxpbmkgPHNzdGFiZWxsaW5pQGtlcm5lbC5vcmc+Ci0tLQp2NS0+djYgY2hhbmdl
czoKKiBSZW5hbWUgUkVHSVNURVJfUENJX0NBUEFCSUxJVFkgdG8gUkVHSVNURVJfVlBDSV9DQVBB
QklMSVRZLgoqIE1vdmUgdnBjaV9jYXBhYmlsaXR5X3QgZW50cnkgZnJvbSAiLmRhdGEudnBjaSIg
dG8gIi5yb2RhdGEudnBjaSIgYW5kCiAgbW92ZSB0aGUgaW5zdGFuY2VzIG9mIFZQQ0lfQVJSQVkg
aW4gdGhlIGxpbmtlciBzY3JpcHRzIGJlZm9yZSAqKC5yb2RhdGEpLgoqIENoYW5nZSBfc3RhcnQv
ZW5kX3ZwY2lfYXJyYXlbXSB0byBiZSBjb25zdCBwb2ludGVyIGFycmF5LgoKdjQtPnY1IGNoYW5n
ZXM6CiogUmVuYW1lIFJFR0lTVEVSX1ZQQ0lfQ0FQIHRvIFJFR0lTVEVSX1BDSV9DQVBBQklMSVRZ
LCByZW5hbWUgUkVHSVNURVJfVlBDSV9MRUdBQ1lfQ0FQIHRvCiAgUkVHSVNURVJfVlBDSV9DQVAs
IHJlbmFtZSBSRUdJU1RFUl9WUENJX0VYVEVOREVEX0NBUCB0byBSRUdJU1RFUl9WUENJX0VYVENB
UC4KKiBDaGFuZ2UgY2xlYW51cCBob29rIG9mIHZwY2lfY2FwYWJpbGl0eV90IGZyb20gdm9pZCB0
byBpbnQuCgp2My0+djQgY2hhbmdlcwoqIERlbGV0ZSB0aGUgdXNlbGVzcyB0cmFpbGluZyBkb3Qg
b2Ygc2VjdGlvbiAiLmRhdGEudnBjaSIuCiogQWRkIGRlc2NyaXB0aW9uIGFib3V0IHByaW9yaXR5
IHNpbmNlIHRoaXMgcGF0Y2ggcmVtb3ZlcyB0aGUgaW5pdGlhbGl6aW5nIHByaW9yaXR5IG9mCiAg
Y2FwYWJpbGl0aWVzIGFuZCBwcmlvcml0eSBpcyBub3QgbmVlZGVkIGFueW1vcmUuCiogQ2hhbmdl
IHRoZSBob29rIG5hbWUgZnJvbSBmaW5pIHRvIGNsZWFudXAuCiogQ2hhbmdlIHRoZSBuYW1lIHgg
YW5kIHkgdG8gYmUgZmluaXQgYW5kIGZjbGVhbi4KKiBSZW1vdmUgdGhlIHVubmVjZXNzYXJ5IGNo
ZWNrICIhY2FwYWJpbGl0eS0+aW5pdCIKCnYyLT52MyBjaGFuZ2VzOgoqIFRoaXMgaXMgc2VwYXJh
dGVkIGZyb20gcGF0Y2ggInZwY2k6IEhpZGUgY2FwYWJpbGl0eSB3aGVuIGl0IGZhaWxzIHRvIGlu
aXRpYWxpemUiIG9mIHYyLgoqIERlbGV0ZSBfX21heWJlX3VudXNlZCBhdHRyaWJ1dGUgb2YgIm91
dCIgaW4gZnVuY3Rpb24gdnBjaV9hc3NpZ25fZGV2aWMoKS4KKiBSZW5hbWUgUkVHSVNURVJfVlBD
SV9FWFRFTkRfQ0FQIHRvIFJFR0lTVEVSX1ZQQ0lfRVhURU5ERURfQ0FQLgoKdjEtPnYyIGNoYW5n
ZXM6CiogUmVtb3ZlZCB0aGUgInByaW9yaXRpZXMiIG9mIGluaXRpYWxpemluZyBjYXBhYmlsaXRp
ZXMgc2luY2UgaXQgaXNuJ3QgdXNlZCBhbnltb3JlLgoqIEFkZGVkIG5ldyBmdW5jdGlvbiB2cGNp
X2NhcGFiaWxpdHlfbWFzaygpIGFuZCB2cGNpX2V4dF9jYXBhYmlsaXR5X21hc2soKSB0byByZW1v
dmUKICBmYWlsZWQgY2FwYWJpbGl0eSBmcm9tIGxpc3QuCiogQ2FsbGVkIHZwY2lfbWFrZV9tc2l4
X2hvbGUoKSBpbiB0aGUgZW5kIG9mIGluaXRfbXNpeCgpLgoKQmVzdCByZWdhcmRzLApKaXFpYW4g
Q2hlbi4KLS0tCiB4ZW4vYXJjaC9hcm0veGVuLmxkcy5TICAgIHwgIDMgKy0tCiB4ZW4vYXJjaC9w
cGMveGVuLmxkcy5TICAgIHwgIDMgKy0tCiB4ZW4vYXJjaC9yaXNjdi94ZW4ubGRzLlMgIHwgIDMg
Ky0tCiB4ZW4vYXJjaC94ODYveGVuLmxkcy5TICAgIHwgIDIgKy0KIHhlbi9kcml2ZXJzL3ZwY2kv
aGVhZGVyLmMgfCAgMyArLS0KIHhlbi9kcml2ZXJzL3ZwY2kvbXNpLmMgICAgfCAgMiArLQogeGVu
L2RyaXZlcnMvdnBjaS9tc2l4LmMgICB8ICA4ICsrKysrLS0KIHhlbi9kcml2ZXJzL3ZwY2kvcmVi
YXIuYyAgfCAgMiArLQogeGVuL2RyaXZlcnMvdnBjaS92cGNpLmMgICB8IDQ0ICsrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKy0tLS0tLS0tLQogeGVuL2luY2x1ZGUveGVuL3ZwY2kuaCAgICB8
IDMwICsrKysrKysrKysrKysrKysrKystLS0tLS0tCiB4ZW4vaW5jbHVkZS94ZW4veGVuLmxkcy5o
IHwgIDIgKy0KIDExIGZpbGVzIGNoYW5nZWQsIDcwIGluc2VydGlvbnMoKyksIDMyIGRlbGV0aW9u
cygtKQoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS94ZW4ubGRzLlMgYi94ZW4vYXJjaC9hcm0v
eGVuLmxkcy5TCmluZGV4IDViZmJlMWU5MmMxZS4uN2Q5NTA4ZWQwZmY1IDEwMDY0NAotLS0gYS94
ZW4vYXJjaC9hcm0veGVuLmxkcy5TCisrKyBiL3hlbi9hcmNoL2FybS94ZW4ubGRzLlMKQEAgLTU1
LDYgKzU1LDcgQEAgU0VDVElPTlMKIAogICAgICAgICBCVUdGUkFNRVMKIAorICAgICAgIFZQQ0lf
QVJSQVkKICAgICAgICAqKC5yb2RhdGEpCiAgICAgICAgKigucm9kYXRhLiopCiAgICAgICAgKigu
ZGF0YS5yZWwucm8pCkBAIC02NCw4ICs2NSw2IEBAIFNFQ1RJT05TCiAgICAgICAgX19wcm9jX2lu
Zm9fc3RhcnQgPSAuOwogICAgICAgICooLnByb2MuaW5mbykKICAgICAgICBfX3Byb2NfaW5mb19l
bmQgPSAuOwotCi0gICAgICAgVlBDSV9BUlJBWQogICB9IDp0ZXh0CiAKICNpZiBkZWZpbmVkKEJV
SUxEX0lEKQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gvcHBjL3hlbi5sZHMuUyBiL3hlbi9hcmNoL3Bw
Yy94ZW4ubGRzLlMKaW5kZXggMTM2NmUyODE5ZWVkLi4wMjk1YzkyMWY3MzUgMTAwNjQ0Ci0tLSBh
L3hlbi9hcmNoL3BwYy94ZW4ubGRzLlMKKysrIGIveGVuL2FyY2gvcHBjL3hlbi5sZHMuUwpAQCAt
NDksMTMgKzQ5LDEyIEBAIFNFQ1RJT05TCiAKICAgICAgICAgQlVHRlJBTUVTCiAKKyAgICAgICAg
VlBDSV9BUlJBWQogICAgICAgICAqKC5yb2RhdGEpCiAgICAgICAgICooLnJvZGF0YS4qKQogICAg
ICAgICAqKC5kYXRhLnJlbC5ybykKICAgICAgICAgKiguZGF0YS5yZWwucm8uKikKIAotICAgICAg
ICBWUENJX0FSUkFZCi0KICAgICAgICAgLiA9IEFMSUdOKFBPSU5URVJfQUxJR04pOwogICAgIH0g
OnRleHQKIApkaWZmIC0tZ2l0IGEveGVuL2FyY2gvcmlzY3YveGVuLmxkcy5TIGIveGVuL2FyY2gv
cmlzY3YveGVuLmxkcy5TCmluZGV4IDhjM2MwNmRlMDFmNi4uNmRmNGNiOTJhNmIyIDEwMDY0NAot
LS0gYS94ZW4vYXJjaC9yaXNjdi94ZW4ubGRzLlMKKysrIGIveGVuL2FyY2gvcmlzY3YveGVuLmxk
cy5TCkBAIC00NCwxMyArNDQsMTIgQEAgU0VDVElPTlMKIAogICAgICAgICBCVUdGUkFNRVMKIAor
ICAgICAgICBWUENJX0FSUkFZCiAgICAgICAgICooLnJvZGF0YSkKICAgICAgICAgKigucm9kYXRh
LiopCiAgICAgICAgICooLmRhdGEucmVsLnJvKQogICAgICAgICAqKC5kYXRhLnJlbC5yby4qKQog
Ci0gICAgICAgIFZQQ0lfQVJSQVkKLQogICAgICAgICAuID0gQUxJR04oUE9JTlRFUl9BTElHTik7
CiAgICAgfSA6dGV4dAogCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYveGVuLmxkcy5TIGIveGVu
L2FyY2gveDg2L3hlbi5sZHMuUwppbmRleCBiZjk1NmI2YzVmYzAuLmJhMDM1ZDZhNjczZiAxMDA2
NDQKLS0tIGEveGVuL2FyY2gveDg2L3hlbi5sZHMuUworKysgYi94ZW4vYXJjaC94ODYveGVuLmxk
cy5TCkBAIC0xMzMsNiArMTMzLDcgQEAgU0VDVElPTlMKIAogICAgICAgIEJVR0ZSQU1FUwogCisg
ICAgICAgVlBDSV9BUlJBWQogICAgICAgICooLnJvZGF0YSkKICAgICAgICAqKC5yb2RhdGEuKikK
ICAgICAgICAqKC5kYXRhLnJlbC5ybykKQEAgLTE0OCw3ICsxNDksNiBAQCBTRUNUSU9OUwogICAg
ICAgICooLm5vdGUuZ251LmJ1aWxkLWlkKQogICAgICAgIF9fbm90ZV9nbnVfYnVpbGRfaWRfZW5k
ID0gLjsKICNlbmRpZgotICAgICAgIFZQQ0lfQVJSQVkKICAgfSBQSERSKHRleHQpCiAKICNpZiBk
ZWZpbmVkKENPTkZJR19QVkhfR1VFU1QpICYmICFkZWZpbmVkKEVGSSkKZGlmZiAtLWdpdCBhL3hl
bi9kcml2ZXJzL3ZwY2kvaGVhZGVyLmMgYi94ZW4vZHJpdmVycy92cGNpL2hlYWRlci5jCmluZGV4
IGEzOWJmMmIxMjU4NS4uMmNmNTRjZTYwMjk3IDEwMDY0NAotLS0gYS94ZW4vZHJpdmVycy92cGNp
L2hlYWRlci5jCisrKyBiL3hlbi9kcml2ZXJzL3ZwY2kvaGVhZGVyLmMKQEAgLTg3Miw3ICs4NzIs
NyBAQCBzdGF0aWMgaW50IHZwY2lfaW5pdF9leHRfY2FwYWJpbGl0eV9saXN0KHN0cnVjdCBwY2lf
ZGV2ICpwZGV2KQogICAgIHJldHVybiAwOwogfQogCi1zdGF0aWMgaW50IGNmX2NoZWNrIGluaXRf
aGVhZGVyKHN0cnVjdCBwY2lfZGV2ICpwZGV2KQoraW50IHZwY2lfaW5pdF9oZWFkZXIoc3RydWN0
IHBjaV9kZXYgKnBkZXYpCiB7CiAgICAgdWludDE2X3QgY21kOwogICAgIHVpbnQ2NF90IGFkZHIs
IHNpemU7CkBAIC0xMDY4LDcgKzEwNjgsNiBAQCBzdGF0aWMgaW50IGNmX2NoZWNrIGluaXRfaGVh
ZGVyKHN0cnVjdCBwY2lfZGV2ICpwZGV2KQogICAgIHBjaV9jb25mX3dyaXRlMTYocGRldi0+c2Jk
ZiwgUENJX0NPTU1BTkQsIGNtZCk7CiAgICAgcmV0dXJuIHJjOwogfQotUkVHSVNURVJfVlBDSV9J
TklUKGluaXRfaGVhZGVyLCBWUENJX1BSSU9SSVRZX01JRERMRSk7CiAKIC8qCiAgKiBMb2NhbCB2
YXJpYWJsZXM6CmRpZmYgLS1naXQgYS94ZW4vZHJpdmVycy92cGNpL21zaS5jIGIveGVuL2RyaXZl
cnMvdnBjaS9tc2kuYwppbmRleCA2NmU1YThhMTE2YmUuLjJkNDVjNzg2N2RlNyAxMDA2NDQKLS0t
IGEveGVuL2RyaXZlcnMvdnBjaS9tc2kuYworKysgYi94ZW4vZHJpdmVycy92cGNpL21zaS5jCkBA
IC0yNzAsNyArMjcwLDcgQEAgc3RhdGljIGludCBjZl9jaGVjayBpbml0X21zaShzdHJ1Y3QgcGNp
X2RldiAqcGRldikKIAogICAgIHJldHVybiAwOwogfQotUkVHSVNURVJfVlBDSV9JTklUKGluaXRf
bXNpLCBWUENJX1BSSU9SSVRZX0xPVyk7CitSRUdJU1RFUl9WUENJX0NBUChQQ0lfQ0FQX0lEX01T
SSwgaW5pdF9tc2ksIE5VTEwpOwogCiB2b2lkIHZwY2lfZHVtcF9tc2kodm9pZCkKIHsKZGlmZiAt
LWdpdCBhL3hlbi9kcml2ZXJzL3ZwY2kvbXNpeC5jIGIveGVuL2RyaXZlcnMvdnBjaS9tc2l4LmMK
aW5kZXggNzQyMTEzMDFiYTEwLi42NzQ4MTVlYWQwMjUgMTAwNjQ0Ci0tLSBhL3hlbi9kcml2ZXJz
L3ZwY2kvbXNpeC5jCisrKyBiL3hlbi9kcml2ZXJzL3ZwY2kvbXNpeC5jCkBAIC03MDMsOSArNzAz
LDEzIEBAIHN0YXRpYyBpbnQgY2ZfY2hlY2sgaW5pdF9tc2l4KHN0cnVjdCBwY2lfZGV2ICpwZGV2
KQogICAgIHBkZXYtPnZwY2ktPm1zaXggPSBtc2l4OwogICAgIGxpc3RfYWRkKCZtc2l4LT5uZXh0
LCAmZC0+YXJjaC5odm0ubXNpeF90YWJsZXMpOwogCi0gICAgcmV0dXJuIDA7CisgICAgc3Bpbl9s
b2NrKCZwZGV2LT52cGNpLT5sb2NrKTsKKyAgICByYyA9IHZwY2lfbWFrZV9tc2l4X2hvbGUocGRl
dik7CisgICAgc3Bpbl91bmxvY2soJnBkZXYtPnZwY2ktPmxvY2spOworCisgICAgcmV0dXJuIHJj
OwogfQotUkVHSVNURVJfVlBDSV9JTklUKGluaXRfbXNpeCwgVlBDSV9QUklPUklUWV9ISUdIKTsK
K1JFR0lTVEVSX1ZQQ0lfQ0FQKFBDSV9DQVBfSURfTVNJWCwgaW5pdF9tc2l4LCBOVUxMKTsKIAog
LyoKICAqIExvY2FsIHZhcmlhYmxlczoKZGlmZiAtLWdpdCBhL3hlbi9kcml2ZXJzL3ZwY2kvcmVi
YXIuYyBiL3hlbi9kcml2ZXJzL3ZwY2kvcmViYXIuYwppbmRleCA3OTM5Mzc0NDlhZjcuLjljYWZk
ODBjYTJjOSAxMDA2NDQKLS0tIGEveGVuL2RyaXZlcnMvdnBjaS9yZWJhci5jCisrKyBiL3hlbi9k
cml2ZXJzL3ZwY2kvcmViYXIuYwpAQCAtMTE4LDcgKzExOCw3IEBAIHN0YXRpYyBpbnQgY2ZfY2hl
Y2sgaW5pdF9yZWJhcihzdHJ1Y3QgcGNpX2RldiAqcGRldikKIAogICAgIHJldHVybiAwOwogfQot
UkVHSVNURVJfVlBDSV9JTklUKGluaXRfcmViYXIsIFZQQ0lfUFJJT1JJVFlfTE9XKTsKK1JFR0lT
VEVSX1ZQQ0lfRVhUQ0FQKFBDSV9FWFRfQ0FQX0lEX1JFQkFSLCBpbml0X3JlYmFyLCBOVUxMKTsK
IAogLyoKICAqIExvY2FsIHZhcmlhYmxlczoKZGlmZiAtLWdpdCBhL3hlbi9kcml2ZXJzL3ZwY2kv
dnBjaS5jIGIveGVuL2RyaXZlcnMvdnBjaS92cGNpLmMKaW5kZXggODQ3NGMwZTNiOTk1Li42ZTc2
OGJiMzI0NDcgMTAwNjQ0Ci0tLSBhL3hlbi9kcml2ZXJzL3ZwY2kvdnBjaS5jCisrKyBiL3hlbi9k
cml2ZXJzL3ZwY2kvdnBjaS5jCkBAIC0zNiw4ICszNiw4IEBAIHN0cnVjdCB2cGNpX3JlZ2lzdGVy
IHsKIH07CiAKICNpZmRlZiBfX1hFTl9fCi1leHRlcm4gdnBjaV9yZWdpc3Rlcl9pbml0X3QgKmNv
bnN0IF9fc3RhcnRfdnBjaV9hcnJheVtdOwotZXh0ZXJuIHZwY2lfcmVnaXN0ZXJfaW5pdF90ICpj
b25zdCBfX2VuZF92cGNpX2FycmF5W107CitleHRlcm4gY29uc3QgdnBjaV9jYXBhYmlsaXR5X3Qg
KmNvbnN0IF9fc3RhcnRfdnBjaV9hcnJheVtdOworZXh0ZXJuIGNvbnN0IHZwY2lfY2FwYWJpbGl0
eV90ICpjb25zdCBfX2VuZF92cGNpX2FycmF5W107CiAjZGVmaW5lIE5VTV9WUENJX0lOSVQgKF9f
ZW5kX3ZwY2lfYXJyYXkgLSBfX3N0YXJ0X3ZwY2lfYXJyYXkpCiAKICNpZmRlZiBDT05GSUdfSEFT
X1ZQQ0lfR1VFU1RfU1VQUE9SVApAQCAtODMsNiArODMsMzIgQEAgc3RhdGljIGludCBhc3NpZ25f
dmlydHVhbF9zYmRmKHN0cnVjdCBwY2lfZGV2ICpwZGV2KQogCiAjZW5kaWYgLyogQ09ORklHX0hB
U19WUENJX0dVRVNUX1NVUFBPUlQgKi8KIAorc3RhdGljIGludCB2cGNpX2luaXRfY2FwYWJpbGl0
aWVzKHN0cnVjdCBwY2lfZGV2ICpwZGV2KQoreworICAgIGZvciAoIHVuc2lnbmVkIGludCBpID0g
MDsgaSA8IE5VTV9WUENJX0lOSVQ7IGkrKyApCisgICAgeworICAgICAgICBjb25zdCB2cGNpX2Nh
cGFiaWxpdHlfdCAqY2FwYWJpbGl0eSA9IF9fc3RhcnRfdnBjaV9hcnJheVtpXTsKKyAgICAgICAg
Y29uc3QgdW5zaWduZWQgaW50IGNhcCA9IGNhcGFiaWxpdHktPmlkOworICAgICAgICBjb25zdCBi
b29sIGlzX2V4dCA9IGNhcGFiaWxpdHktPmlzX2V4dDsKKyAgICAgICAgaW50IHJjOworICAgICAg
ICB1bnNpZ25lZCBpbnQgcG9zID0gMDsKKworICAgICAgICBpZiAoICFpc19leHQgKQorICAgICAg
ICAgICAgcG9zID0gcGNpX2ZpbmRfY2FwX29mZnNldChwZGV2LT5zYmRmLCBjYXApOworICAgICAg
ICBlbHNlIGlmICggaXNfaGFyZHdhcmVfZG9tYWluKHBkZXYtPmRvbWFpbikgKQorICAgICAgICAg
ICAgcG9zID0gcGNpX2ZpbmRfZXh0X2NhcGFiaWxpdHkocGRldi0+c2JkZiwgY2FwKTsKKworICAg
ICAgICBpZiAoICFwb3MgKQorICAgICAgICAgICAgY29udGludWU7CisKKyAgICAgICAgcmMgPSBj
YXBhYmlsaXR5LT5pbml0KHBkZXYpOworICAgICAgICBpZiAoIHJjICkKKyAgICAgICAgICAgIHJl
dHVybiByYzsKKyAgICB9CisKKyAgICByZXR1cm4gMDsKK30KKwogdm9pZCB2cGNpX2RlYXNzaWdu
X2RldmljZShzdHJ1Y3QgcGNpX2RldiAqcGRldikKIHsKICAgICB1bnNpZ25lZCBpbnQgaTsKQEAg
LTEyOCw3ICsxNTQsNiBAQCB2b2lkIHZwY2lfZGVhc3NpZ25fZGV2aWNlKHN0cnVjdCBwY2lfZGV2
ICpwZGV2KQogCiBpbnQgdnBjaV9hc3NpZ25fZGV2aWNlKHN0cnVjdCBwY2lfZGV2ICpwZGV2KQog
ewotICAgIHVuc2lnbmVkIGludCBpOwogICAgIGNvbnN0IHVuc2lnbmVkIGxvbmcgKnJvX21hcDsK
ICAgICBpbnQgcmMgPSAwOwogCkBAIC0xNTksMTQgKzE4NCwxMyBAQCBpbnQgdnBjaV9hc3NpZ25f
ZGV2aWNlKHN0cnVjdCBwY2lfZGV2ICpwZGV2KQogICAgICAgICBnb3RvIG91dDsKICNlbmRpZgog
Ci0gICAgZm9yICggaSA9IDA7IGkgPCBOVU1fVlBDSV9JTklUOyBpKysgKQotICAgIHsKLSAgICAg
ICAgcmMgPSBfX3N0YXJ0X3ZwY2lfYXJyYXlbaV0ocGRldik7Ci0gICAgICAgIGlmICggcmMgKQot
ICAgICAgICAgICAgYnJlYWs7Ci0gICAgfQorICAgIHJjID0gdnBjaV9pbml0X2hlYWRlcihwZGV2
KTsKKyAgICBpZiAoIHJjICkKKyAgICAgICAgZ290byBvdXQ7CisKKyAgICByYyA9IHZwY2lfaW5p
dF9jYXBhYmlsaXRpZXMocGRldik7CiAKLSBvdXQ6IF9fbWF5YmVfdW51c2VkOworIG91dDoKICAg
ICBpZiAoIHJjICkKICAgICAgICAgdnBjaV9kZWFzc2lnbl9kZXZpY2UocGRldik7CiAKZGlmZiAt
LWdpdCBhL3hlbi9pbmNsdWRlL3hlbi92cGNpLmggYi94ZW4vaW5jbHVkZS94ZW4vdnBjaS5oCmlu
ZGV4IDYxZDE2Y2M4Yjg5Ny4uNmVhNmZjZjU3OGYxIDEwMDY0NAotLS0gYS94ZW4vaW5jbHVkZS94
ZW4vdnBjaS5oCisrKyBiL3hlbi9pbmNsdWRlL3hlbi92cGNpLmgKQEAgLTEzLDExICsxMywxMiBA
QCB0eXBlZGVmIHVpbnQzMl90IHZwY2lfcmVhZF90KGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZGV2
LCB1bnNpZ25lZCBpbnQgcmVnLAogdHlwZWRlZiB2b2lkIHZwY2lfd3JpdGVfdChjb25zdCBzdHJ1
Y3QgcGNpX2RldiAqcGRldiwgdW5zaWduZWQgaW50IHJlZywKICAgICAgICAgICAgICAgICAgICAg
ICAgICAgdWludDMyX3QgdmFsLCB2b2lkICpkYXRhKTsKIAotdHlwZWRlZiBpbnQgdnBjaV9yZWdp
c3Rlcl9pbml0X3Qoc3RydWN0IHBjaV9kZXYgKmRldik7Ci0KLSNkZWZpbmUgVlBDSV9QUklPUklU
WV9ISUdIICAgICAgIjEiCi0jZGVmaW5lIFZQQ0lfUFJJT1JJVFlfTUlERExFICAgICI1IgotI2Rl
ZmluZSBWUENJX1BSSU9SSVRZX0xPVyAgICAgICAiOSIKK3R5cGVkZWYgc3RydWN0IHsKKyAgICB1
bnNpZ25lZCBpbnQgaWQ7CisgICAgYm9vbCBpc19leHQ7CisgICAgaW50ICgqaW5pdCkoc3RydWN0
IHBjaV9kZXYgKnBkZXYpOworICAgIGludCAoKmNsZWFudXApKHN0cnVjdCBwY2lfZGV2ICpwZGV2
KTsKK30gdnBjaV9jYXBhYmlsaXR5X3Q7CiAKICNkZWZpbmUgVlBDSV9FQ0FNX0JERihhZGRyKSAg
ICAgKCgoYWRkcikgJiAweDBmZmZmMDAwKSA+PiAxMikKIApAQCAtMjksOSArMzAsMjIgQEAgdHlw
ZWRlZiBpbnQgdnBjaV9yZWdpc3Rlcl9pbml0X3Qoc3RydWN0IHBjaV9kZXYgKmRldik7CiAgKi8K
ICNkZWZpbmUgVlBDSV9NQVhfVklSVF9ERVYgICAgICAgKFBDSV9TTE9UKH4wKSArIDEpCiAKLSNk
ZWZpbmUgUkVHSVNURVJfVlBDSV9JTklUKHgsIHApICAgICAgICAgICAgICAgIFwKLSAgc3RhdGlj
IHZwY2lfcmVnaXN0ZXJfaW5pdF90ICpjb25zdCB4IyNfZW50cnkgIFwKLSAgICAgICAgICAgICAg
IF9fdXNlZF9zZWN0aW9uKCIuZGF0YS52cGNpLiIgcCkgPSAoeCkKKyNkZWZpbmUgUkVHSVNURVJf
VlBDSV9DQVBBQklMSVRZKGNhcCwgZmluaXQsIGZjbGVhbiwgZXh0KSBcCisgICAgc3RhdGljIGNv
bnN0IHZwY2lfY2FwYWJpbGl0eV90IGZpbml0IyNfdCA9IHsgXAorICAgICAgICAuaWQgPSAoY2Fw
KSwgXAorICAgICAgICAuaW5pdCA9IChmaW5pdCksIFwKKyAgICAgICAgLmNsZWFudXAgPSAoZmNs
ZWFuKSwgXAorICAgICAgICAuaXNfZXh0ID0gKGV4dCksIFwKKyAgICB9OyBcCisgICAgc3RhdGlj
IGNvbnN0IHZwY2lfY2FwYWJpbGl0eV90ICpjb25zdCBmaW5pdCMjX2VudHJ5ICBcCisgICAgICAg
IF9fdXNlZF9zZWN0aW9uKCIucm9kYXRhLnZwY2kiKSA9ICZmaW5pdCMjX3QKKworI2RlZmluZSBS
RUdJU1RFUl9WUENJX0NBUChjYXAsIGZpbml0LCBmY2xlYW4pIFwKKyAgICBSRUdJU1RFUl9WUENJ
X0NBUEFCSUxJVFkoY2FwLCBmaW5pdCwgZmNsZWFuLCBmYWxzZSkKKyNkZWZpbmUgUkVHSVNURVJf
VlBDSV9FWFRDQVAoY2FwLCBmaW5pdCwgZmNsZWFuKSBcCisgICAgUkVHSVNURVJfVlBDSV9DQVBB
QklMSVRZKGNhcCwgZmluaXQsIGZjbGVhbiwgdHJ1ZSkKKworaW50IF9fbXVzdF9jaGVjayB2cGNp
X2luaXRfaGVhZGVyKHN0cnVjdCBwY2lfZGV2ICpwZGV2KTsKIAogLyogQXNzaWduIHZQQ0kgdG8g
ZGV2aWNlIGJ5IGFkZGluZyBoYW5kbGVycy4gKi8KIGludCBfX211c3RfY2hlY2sgdnBjaV9hc3Np
Z25fZGV2aWNlKHN0cnVjdCBwY2lfZGV2ICpwZGV2KTsKZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRl
L3hlbi94ZW4ubGRzLmggYi94ZW4vaW5jbHVkZS94ZW4veGVuLmxkcy5oCmluZGV4IDc5M2QwZTEx
NDUwYy4uYWMzNTljMzc1N2EyIDEwMDY0NAotLS0gYS94ZW4vaW5jbHVkZS94ZW4veGVuLmxkcy5o
CisrKyBiL3hlbi9pbmNsdWRlL3hlbi94ZW4ubGRzLmgKQEAgLTE4OCw3ICsxODgsNyBAQAogI2Rl
ZmluZSBWUENJX0FSUkFZICAgICAgICAgICAgICAgXAogICAgICAgIC4gPSBBTElHTihQT0lOVEVS
X0FMSUdOKTsgXAogICAgICAgIF9fc3RhcnRfdnBjaV9hcnJheSA9IC47ICAgXAotICAgICAgICoo
U09SVCguZGF0YS52cGNpLiopKSAgICAgXAorICAgICAgICooLnJvZGF0YS52cGNpKSAgICAgICAg
ICAgXAogICAgICAgIF9fZW5kX3ZwY2lfYXJyYXkgPSAuOwogI2Vsc2UKICNkZWZpbmUgVlBDSV9B
UlJBWQotLSAKMi4zNC4xCgo=

--_003_PH7PR12MB5854FC2E82CD17483B6B6BCFE76AAPH7PR12MB5854namp_--


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 04:22:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 04:22:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010482.1388576 (Exim 4.92)
	(envelope-from )
	id 1uOqVQ-0006a5-Vw; Tue, 10 Jun 2025 04:22:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010482.1388576; Tue, 10 Jun 2025 04: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 1uOqVQ-0006Zy-R8; Tue, 10 Jun 2025 04:22:36 +0000
Received: by outflank-mailman (input) for mailman id 1010482;
 Tue, 10 Jun 2025 04: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 1uOqVP-0006Zs-P2
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 04:22:35 +0000
Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com
 [2a00:1450:4864:20::544])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 85e0d0c4-45b2-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 06:22:30 +0200 (CEST)
Received: by mail-ed1-x544.google.com with SMTP id
 4fb4d7f45d1cf-60779962c00so4620784a12.0
 for ; Mon, 09 Jun 2025 21:22:30 -0700 (PDT)
Received: from ?IPV6:2003:e5:872a:8800:5c7b:1ac1:4fa0:423b?
 (p200300e5872a88005c7b1ac14fa0423b.dip0.t-ipconnect.de.
 [2003:e5:872a:8800:5c7b:1ac1:4fa0:423b])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ade1dc39c3fsm653224566b.140.2025.06.09.21.22.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 09 Jun 2025 21:22:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 85e0d0c4-45b2-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749529350; x=1750134150; 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=vtE6FqbXKVpkJpTRc7uA49IoSQWoz/UlJhOgGFdmCX0=;
        b=FiG7Ac+IY3F8OVcgExrlMcP4Nx/8LUy/Wn60YgRYhwNUJiVPZWNrM9SDEN0VQ6eSpM
         bVkMvHGXmI3JAub3sQcSrA7vyXbM4bvswx5+OS00zxmazmPYbHGD9tRKOez4V5vZzQJS
         s5ubI8gtjnqv0m8gLR/PwKfgk6O/whayWoJoD1Ym9XjNDjMshuDLTZ0PkFNiZWd9Idsz
         aBq57LDgOKH5Cxn1BJfoAJISkLcQnCsqHQwMRYrD7KoporO9umUcbKio+WYaELpe37yu
         e62fOazdJxc+rp5EHfM8oDPC2ojTh/KSYgxprAlfHERzavAJGirjCO5EqkztSlVKdpqj
         qinw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749529350; x=1750134150;
        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=vtE6FqbXKVpkJpTRc7uA49IoSQWoz/UlJhOgGFdmCX0=;
        b=K/69Cy957SBL6Hsz7HR+o6RzECQuKtU7Zm8qSbK0O9onZqO1neggpC5FNzgNrTrhtG
         2iJ25GAtvADEUS4XxU+SMlhShviBJmTzi4rnFpj943R7PYrKyQJv8P7R6NIgW/yG9Hlv
         m2QIyr4Im/1aatcBiPvyH7NgyNnCCym5vREw4Wu5lBKVQkMXLrGlEeR2yBtXUlF9G4jH
         bZOXm5k+nZncereBJ9w9KkZCpJPR/RMDLm58ttQ0Y8LYbWWI4W6GgszzxyA10nq4cSWQ
         TXe1rdbMCXFDFHMXcOcj9Kixi6PDymK3Tcy7XqHk3syIO9521fZ4iLa+X2gJZ9+maWF7
         ANCg==
X-Forwarded-Encrypted: i=1; AJvYcCUtEoyTNOfUgc9VA/PCJETxsEdQVpIfBcFvC+GHLrMxjppj5WomwOBSS+luDFCpCP3RfYwZ7VsY8eU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyQkZMoRnIHSiInFXGdTnOZoUCNuHOb8DnlsCCuqlPw5Yywlvjr
	bl3OVdqeU4FIT1PU01aZ7mtczJmJJxXacyR3H4kpKV5VvDzIlyttmLa3WV4PaTX9QkA=
X-Gm-Gg: ASbGncsIU4c3qnZnH8ygW4DGVvttGi32IX2HjFbUq4F0N1K9eLG8DyXxmU+koHpaYFl
	dsNEnTB0AW1LTtdy7cfph2vnAwUVSOTQztx2gzZEVWaTGrvxnKjnpCMALQnu/kL8S5iesarCHMl
	CQNeeLspCsXpNWApGQSRGno0vvtVrvvn7uIzY7FTRbCfWeOIFYh+DMnmadeZ6VvYkToKIbFtCOw
	fLsqRHaNhtDc5ryxUPqHK6/QmZR/ABFUyf3m/wWhiysupOa1/P6Ltdng0C6CE9tOMjSlZOquGNW
	JyYXXa3uqkLOiycRsPuEG5m8lnakAVvYt2n82yKT6XBFyl8VgT5s8r7dKdKG0R8qhDPwsBf7nBQ
	c99ux4Z26eU+c2JGaIxrxSTrllfQqSati81BtlZEAXfYEok6iJndK1F4x5KogVeORsGKY85no5g
	bcNRks569K9jQ=
X-Google-Smtp-Source: AGHT+IEWCebQ2XimYzy+I8VvIYOjz0xMZTBHp3Lj8BEv5gPVoXnMnc69oeCEBeVl7rEE6+nNHgKQdg==
X-Received: by 2002:a17:907:3f24:b0:ad8:a41a:3cc5 with SMTP id a640c23a62f3a-ade1a9170e1mr1401238066b.6.1749529349503;
        Mon, 09 Jun 2025 21:22:29 -0700 (PDT)
Message-ID: <8ad4304d-43bc-4584-bc69-822eb0661e7b@suse.com>
Date: Tue, 10 Jun 2025 06:22:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [REGRESSION] Linux 6.15.1 xen/dom0 domain_crash_sync called from
 entry.S
To: Chuck Zmudzinski , stable@vger.kernel.org
Cc: regressions@lists.linux.dev, xen-devel ,
 Boris Ostrovsky 
References: <8ed96ec9-7c84-4bb4-90ec-5b753be9fd40.ref@netscape.net>
 <8ed96ec9-7c84-4bb4-90ec-5b753be9fd40@netscape.net>
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: <8ed96ec9-7c84-4bb4-90ec-5b753be9fd40@netscape.net>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------0EbFx1IS9ivErK0O9PjmY4R5"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------0EbFx1IS9ivErK0O9PjmY4R5
Content-Type: multipart/mixed; boundary="------------OQLtB7JT21dg2AQFGuQitRgX";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Chuck Zmudzinski , stable@vger.kernel.org
Cc: regressions@lists.linux.dev, xen-devel ,
 Boris Ostrovsky 
Message-ID: <8ad4304d-43bc-4584-bc69-822eb0661e7b@suse.com>
Subject: Re: [REGRESSION] Linux 6.15.1 xen/dom0 domain_crash_sync called from
 entry.S
References: <8ed96ec9-7c84-4bb4-90ec-5b753be9fd40.ref@netscape.net>
 <8ed96ec9-7c84-4bb4-90ec-5b753be9fd40@netscape.net>
In-Reply-To: <8ed96ec9-7c84-4bb4-90ec-5b753be9fd40@netscape.net>

--------------OQLtB7JT21dg2AQFGuQitRgX
Content-Type: multipart/mixed; boundary="------------EOhNGRxKFthsm1FP655sH8HF"

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

T24gMTAuMDYuMjUgMDA6NDMsIENodWNrIFptdWR6aW5za2kgd3JvdGU6DQo+IEhpLA0KPiAN
Cj4gSSBhbSBzZWVpbmcgdGhlIGZvbGxvd2luZyByZWdyZXNzaW9uIGJldHdlZW4gTGludXgg
Ni4xNC44IGFuZCA2LjE1LjEuDQo+IA0KPiBLZXJuZWwgdmVyc2lvbiA2LjE0LjggYm9vdHMg
ZmluZSBidXQgdmVyc2lvbiA2LjE1LjEgY3Jhc2hlcyBhbmQNCj4gcmVib290cyBvbiBYZW4u
IEkgZG9uJ3Qga25vdyBpZiA2LjE0Ljkgb3IgNi4xNC4xMCBpcyBhZmZlY3RlZCwgb3INCj4g
aWYgNi4xNSBvciB0aGUgNi4xNSByZWxlYXNlIGNhbmRpZGF0ZXMgYXJlIGFmZmVjdGVkIGJl
Y2F1c2UgSSBkaWQNCj4gbm90IHRlc3QgdGhlbS4NCj4gDQo+IEFsc28sIExpbnV4IDYuMTUu
MSBib290cyBmaW5lIG9uIGJhcmUgbWV0YWwgd2l0aG91dCBYZW4uDQo+IA0KPiBIYXJkd2Fy
ZTogSW50ZWwgaTUtMTQ1MDAgUmFwdG9yIExha2UgQ1BVLCBhbmQgQVNSb2NrIEI3NjBNIFBH
IG1vdGhlcmJvYXJkIGFuZCAzMiBHQiBSQU0uDQo+IA0KPiBYZW4gdmVyc2lvbjogNC4xOS4y
IChtb2NrYnVpbGRAZHluYXZpcnQuY29tKSAoZ2NjIChHQ0MpIDEzLjMuMSAyMDI0MDYxMSAo
UmVkIEhhdCAxMy4zLjEtMikpIGRlYnVnPW4gU3VuIEFwciAxMyAxNToyNDoyOSBQRFQgMjAy
NQ0KPiANCj4gWGVuIENvbW1hbmQgbGluZTogcGxhY2Vob2xkZXIgZG9tMF9tZW09MkcsbWF4
OjJHIGNvbnJpbmdfc2l6ZT0zMmsgY29tMT05NjAwLDhuMSwweDQwYzAsMTYsMTowLjAgY29u
c29sZT1jb20xDQo+IA0KPiBMaW51eCB2ZXJzaW9uIDYuMTUuMS0xLmVsOS5lbHJlcG8ueDg2
XzY0IChtb2NrYnVpbGRANWI3YTVkYWIzYjcxNDI5ODk4YjRmODQ3NGZhYjhmYTApIChnY2Mg
KEdDQykgMTEuNS4wIDIwMjQwNzE5IChSZWQgSGF0IDExLjUuMC01KSwgR05VIGxkIHZlcnNp
b24gMi4zNS4yLTYzLmVsOSkgIzEgU01QIFBSRUVNUFRfRFlOQU1JQyBXZWQgSnVuICA0IDE2
OjQyOjU4IEVEVCAyMDI1DQo+IA0KPiBMaW51eCBLZXJuZWwgQ29tbWFuZCBsaW5lOiBwbGFj
ZWhvbGRlciByb290PS9kZXYvbWFwcGVyL3N5c3RlbXMtcm9vdGFsbWEgcm8gY3Jhc2hrZXJu
ZWw9MUctNEc6MTkyTSw0Ry02NEc6MjU2TSw2NEctOjUxMk0gcmVzdW1lPVVVSUQ9MmRkYzJl
M2ItOGY3Yi00OThiLWE0ZTgtYmI0ZDMzYTFlNWE3IGNvbnNvbGU9aHZjMA0KPiANCj4gVGhl
IExpbnV4IDYuMTUuMSBkb20wIGtlcm5lbCBjYXVzZXMgWGVuIHRvIGNyYXNoIGFuZCByZWJv
b3QsIGhlcmUgYXJlDQo+IHRoZSBsYXN0IG1lc3NhZ2VzIG9uIHRoZSBzZXJpYWwgY29uc29s
ZSAoaW5jbHVkZXMgbWVzc2FnZXMgZnJvbSBib3RoDQo+IGRvbTAgYW5kIFhlbikgYmVmb3Jl
IGNyYXNoOg0KPiANCj4gWyAgICAwLjMwMTU3M10gU3BlY3VsYXRpdmUgU3RvcmUgQnlwYXNz
OiBNaXRpZ2F0aW9uOiBTcGVjdWxhdGl2ZSBTdG9yZSBCeXBhc3MgZGlzYWJsZWQgdmlhIHBy
Y3RsDQo+IA0KPiBbICAgIDAuMzAxNTc3XSBSZWdpc3RlciBGaWxlIERhdGEgU2FtcGxpbmc6
IFZ1bG5lcmFibGU6IE5vIG1pY3JvY29kZQ0KPiANCj4gWyAgICAwLjMwMTU4MV0gSVRTOiBN
aXRpZ2F0aW9uOiBBbGlnbmVkIGJyYW5jaC9yZXR1cm4gdGh1bmtzDQo+IA0KPiBbICAgIDAu
MzAxNTk0XSB4ODYvZnB1OiBTdXBwb3J0aW5nIFhTQVZFIGZlYXR1cmUgMHgwMDE6ICd4ODcg
ZmxvYXRpbmcgcG9pbnQgcmVnaXN0ZXJzJw0KPiANCj4gWyAgICAwLjMwMTU5OF0geDg2L2Zw
dTogU3VwcG9ydGluZyBYU0FWRSBmZWF0dXJlIDB4MDAyOiAnU1NFIHJlZ2lzdGVycycNCj4g
DQo+IFsgICAgMC4zMDE2MDJdIHg4Ni9mcHU6IFN1cHBvcnRpbmcgWFNBVkUgZmVhdHVyZSAw
eDAwNDogJ0FWWCByZWdpc3RlcnMnDQo+IA0KPiBbICAgIDAuMzAxNjA1XSB4ODYvZnB1OiB4
c3RhdGVfb2Zmc2V0WzJdOiAgNTc2LCB4c3RhdGVfc2l6ZXNbMl06ICAyNTYNCj4gDQo+IFsg
ICAgMC4zMDE2MDldIHg4Ni9mcHU6IEVuYWJsZWQgeHN0YXRlIGZlYXR1cmVzIDB4NywgY29u
dGV4dCBzaXplIGlzIDgzMiBieXRlcywgdXNpbmcgJ2NvbXBhY3RlZCcgZm9ybWF0Lg0KPiAN
Cj4gKFhFTikgUGFnZXRhYmxlIHdhbGsgZnJvbSBmZmZmYzkwMDNmZmZmZmY4Og0KPiAoWEVO
KSAgTDRbMHgxOTJdID0gMDAwMDAwMDg1NWJlZTA2NyAwMDAwMDAwMDAwMDYwZTU2DQo+IChY
RU4pICBMM1sweDAwMF0gPSAwMDAwMDAwODU1YmVkMDY3IDAwMDAwMDAwMDAwNjBlNTUNCj4g
KFhFTikgIEwyWzB4MWZmXSA9IDAwMDAwMDA4NTViZjAwNjcgMDAwMDAwMDAwMDA2MGU1OA0K
PiAoWEVOKSAgTDFbMHgxZmZdID0gODAxMDAwMDg1NWJmMjAyNSAwMDAwMDAwMDAwMDYwZTVh
DQo+IChYRU4pIGRvbWFpbl9jcmFzaF9zeW5jIGNhbGxlZCBmcm9tIGVudHJ5LlM6IGZhdWx0
IGF0IGZmZmY4MmQwNDAzNmU1YjAgeDg2XzY0L2VudHJ5LlMjZG9tYWluX2NyYXNoX3BhZ2Vf
ZmF1bHRfNng4KzAvMHg0DQo+IChYRU4pIERvbWFpbiAwICh2Y3B1IzApIGNyYXNoZWQgb24g
Y3B1IzExOg0KPiAoWEVOKSAtLS0tWyBYZW4tNC4xOS4yICB4ODZfNjQgIGRlYnVnPW4gIE5v
dCB0YWludGVkIF0tLS0tDQo+IChYRU4pIENQVTogICAgMTENCj4gKFhFTikgUklQOiAgICBl
MDMzOls8ZmZmZmZmZmY4MTAwMTRmZT5dDQo+IChYRU4pIFJGTEFHUzogMDAwMDAwMDAwMDAx
MDIwNiAgIEVNOiAxICAgQ09OVEVYVDogcHYgZ3Vlc3QgKGQwdjApDQo+IChYRU4pIHJheDog
ZmZmZmZmZmY4MWZiMTJkMCAgIHJieDogMDAwMDAwMDAwMDAwMDI5YSAgIHJjeDogMDAwMDAw
MDAwMDAwMDAwYw0KPiAoWEVOKSByZHg6IDAwMDAwMDAwMDAwMDAyOWEgICByc2k6IGZmZmZm
ZmZmODEwMDBiOTkgICByZGk6IGZmZmZjOTAwNDAwMDAwZjANCj4gKFhFTikgcmJwOiAwMDAw
MDAwMDAwMDAwMTRkICAgcnNwOiBmZmZmYzkwMDQwMDAwMDAwICAgcjg6ICAwMDAwMDAwMDAw
MDAwZjljDQo+IChYRU4pIHI5OiAgMDAwMDAwMDAwMDAwMDAwMCAgIHIxMDogMDAwMDAwMDAw
MDAwMDAwMCAgIHIxMTogMDAwMDAwMDAwMDAwMDAwMA0KPiAoWEVOKSByMTI6IDAwMDAwMDAw
MDAwMDAwMGMgICByMTM6IGZmZmZmZmZmODI3NzE1MzAgICByMTQ6IGZmZmZmZmZmODI3NzI0
Y2MNCj4gKFhFTikgcjE1OiBmZmZmYzkwMDQwMDAwMGYwICAgY3IwOiAwMDAwMDAwMDgwMDUw
MDMzICAgY3I0OiAwMDAwMDAwMDAwYjUyNmUwDQo+IChYRU4pIGNyMzogMDAwMDAwMDg2YWUy
NDAwMCAgIGNyMjogZmZmZmM5MDAzZmZmZmZmOA0KPiAoWEVOKSBmc2I6IDAwMDAwMDAwMDAw
MDAwMDAgICBnc2I6IGZmZmY4ODgxOWFjNTUwMDAgICBnc3M6IDAwMDAwMDAwMDAwMDAwMDAN
Cj4gKFhFTikgZHM6IDAwMDAgICBlczogMDAwMCAgIGZzOiAwMDAwICAgZ3M6IDAwMDAgICBz
czogZTAyYiAgIGNzOiBlMDMzDQo+IChYRU4pIEd1ZXN0IHN0YWNrIHRyYWNlIGZyb20gcnNw
PWZmZmZjOTAwNDAwMDAwMDA6DQo+IChYRU4pICAgU3RhY2sgZW1wdHkuDQo+IChYRU4pIEhh
cmR3YXJlIERvbTAgY3Jhc2hlZDogcmVib290aW5nIG1hY2hpbmUgaW4gNSBzZWNvbmRzLg0K
PiAoWEVOKSBSZXNldHRpbmcgd2l0aCBBQ1BJIE1FTU9SWSBvciBJL08gUkVTRVRfUkVHLg0K
PiANCj4gSSBzZWFyY2hlZCBtYWlsaW5nIGxpc3RzIGJ1dCBjb3VsZCBub3QgZmluZCBhIHJl
cG9ydCBzaW1pbGFyIHRvIHdoYXQgSSBhbQ0KPiBzZWVpbmcgaGVyZS4NCj4gDQo+IEkgZG9u
J3Qga25vdyB3aGF0IHRvIHRyeSBleGNlcHQgdG8gZ2l0IGJpc2VjdCwgYnV0IEkgaGF2ZSBu
b3QgZG9uZSB0aGF0IHlldC4NCg0KVGhpcyBpcyBhIGtub3duIGlzc3VlLg0KDQpBIHBhdGNo
IHNlcmllcyB0byBmaXggdGhhdCBoYXMgYmVlbiBwb3N0ZWQ6DQoNCmh0dHBzOi8vbG9yZS5r
ZXJuZWwub3JnL2xrbWwvMjAyNTA2MDMxMTE0NDYuMjYwOTM4MS0xLXJwcHRAa2VybmVsLm9y
Zy8NCg0KDQpKdWVyZ2VuDQo=
--------------EOhNGRxKFthsm1FP655sH8HF
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-----

--------------EOhNGRxKFthsm1FP655sH8HF--

--------------OQLtB7JT21dg2AQFGuQitRgX--

--------------0EbFx1IS9ivErK0O9PjmY4R5
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/Ey8FAmhHswQFAwAAAAAACgkQsN6d1ii/Ey9l
Zgf9FX20+U9R5uBooiAQ+iucn8O0Z/vkwLGCbGuN6gH1x+GA3c4zVtjUe0ZVj6TpS25HUQdeoV9t
hR48V3ZTLGSrYE7+Dagad3LKcmF9usB60iq+Sn3fUbM5AHWGvDNdrB/SjeyxxArXg+APAQjDc+KY
xlQduAQX5fTlakRYcULYttoWzeVYafabDNPsNdsFLzqEcISA6xfvOyIQ+8UHCTNmdOIXhYxrzB44
Yvm6TN42tTQo+FmKsIT2u340Yl8w5rtJL5CYV5cno6NnBMDS1OVa5k5wmwA++DB1jkuDo/BLV1kp
RoAbCL5PpTqbSlImCEdyAp28kAGJ5n8dBOBlHevUzw==
=5Yjt
-----END PGP SIGNATURE-----

--------------0EbFx1IS9ivErK0O9PjmY4R5--


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 06:42:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 06:42:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010488.1388584 (Exim 4.92)
	(envelope-from )
	id 1uOsgx-0005h0-Kg; Tue, 10 Jun 2025 06:42:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010488.1388584; Tue, 10 Jun 2025 06:42:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uOsgx-0005gt-I1; Tue, 10 Jun 2025 06:42:39 +0000
Received: by outflank-mailman (input) for mailman id 1010488;
 Tue, 10 Jun 2025 06:42: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 1uOsgw-0005gn-EK
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 06:42:38 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on2060b.outbound.protection.outlook.com
 [2a01:111:f403:2417::60b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 14a3f460-45c6-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 08:42:31 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by SA0PR12MB7090.namprd12.prod.outlook.com (2603:10b6:806:2d5::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.39; Tue, 10 Jun
 2025 06:42:28 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8792.034; Tue, 10 Jun 2025
 06:42: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: 14a3f460-45c6-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=M1TnPe+ALRtBM2QHR8zilhmJ8VT946KywxDve9xcQmNN/IjYdnKNBbjTQMvBGR6Ah7mkRCQemXxI8MwBgX+qEFBEtMmCZv+Ux1DHibWzdQBtAt+y4ToT+QVgiw7qVunPxIKBn4ENK3quIuAjOoVlcgKV02PCt7wesZdwB+xp9T4HuPPtvcLLJLtv6aPTFSmvxkA2WOMPPvS2EWeZ9ArsWngoJG2un3t3rg4/23ZGmmQWBV55X0WnpoDwjM3GH6mQoMh7dsLYfZO98cXzePI9gwE6ySC9vZ4lk7FF2S7kB3z5aZrZ7sWUmDQBHVfjPK77mNwjG6gO6Aq/D4BHgG217w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=RPC9iPavFIQNXws7Q9IwJCwqAm2J9I8pLaLCui7orW8=;
 b=k0JN+004X+VRDukyqAarJm/wfGIOGiyo/mYLQqh69BRVCc0Iu+DqdKZf1+TLsToNn2EDa1SDJZ5H+/4sJc9NtCJt1gLtWEhJYaf0IVwK/2n6WlJa5u1E1iDVtd9IB6aKJrW8OFPRXJW5i4fsk7QxXV2l9h9i5fZv2NQP5zdVWvAJlGKeVlkr9kr8ova6wVHGWcCWQ0qZRPT/aG2zejVRf3MXwZvyw3wVOXPmfFiyN4DbaeDVe6o1Kko2DnnVB6a3Nm68fdA//05nmANi1+SdVBpqLChjV1g+7Oi/6NusBjW4Gw7AuSKxaG7QlXF9n9+h8Iz+QvqEVJFxE1TFOfybHQ==
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=RPC9iPavFIQNXws7Q9IwJCwqAm2J9I8pLaLCui7orW8=;
 b=qLClENRUB/20pNRzL0mGcoBkmiD/b7yH54478uQL9c/8QATAptVpSmWRVGt80yDRQm1E84iR17/3eL/xnN5Ojc7YewtXRXuCteLZZCO2EG+gYaaVIP182WKFE+BbRlcwBTLBARiqNzvEo8C8XrWquAymbGmT6S5uedXRwHRn0Vc=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Tue, 10 Jun 2025 08:42:23 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/arm: fix build with HAS_PCI
To: Stewart Hildebrand ,
 xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20250609205422.180717-1-stewart.hildebrand@amd.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250609205422.180717-1-stewart.hildebrand@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: FR5P281CA0012.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:f2::9) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|SA0PR12MB7090:EE_
X-MS-Office365-Filtering-Correlation-Id: 1e0bfba6-51b9-4714-8ddc-08dda7e9f76a
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?bzF6WU9EMUxTemMwdVhjQXhZRUNZOUc2Zk5tdzUyVzE5aDUwRGxNMXNhanN3?=
 =?utf-8?B?VzJEdE1PV1oxR0xZL1pKQlVFUzBRRE1DZWkwVnhOcnlwTXFSekJkeHRtYTls?=
 =?utf-8?B?S3VzRU1KRTEvK0hjT2I0WWFuRWRsTi9tTDIwOHJhWWtUQjZvRUFaS1dCRkVZ?=
 =?utf-8?B?MG1sQ25SUTRzTVNYbEc0akVERFNZNDZWeE5ORkVWM1VjNWh6czlDWHArS2VE?=
 =?utf-8?B?UGdzY0VUcGdSUlBXenRVaitadGZNSG9BeHlCL3M0V3V1elBhZjdlVTQ1WndO?=
 =?utf-8?B?cVVOd0NxdGlOVWM0YnlSOUY0Y2JNaDBpVzF4elVnZCttTy8xcG15S1ArZzlx?=
 =?utf-8?B?Q3VENE9FVGM1OUZQQ2hmOGt3TVYvTEd5ZFJyWW84MFQxSk8wSmViOXFlM1NF?=
 =?utf-8?B?RHFjbGp2S2dzd2I5ZTJnZHBWRllVUCtEZzJyTk5MWmIvYUlUNTNwTFlkUVMr?=
 =?utf-8?B?cGQ3SkU1TG9TTVE3SEJPSHJIdnNGYlZkdzY2RFlpTUdXWXg4bHFZZExtWnRx?=
 =?utf-8?B?VDFaSjRTVko4V3BKcDdDalFxZkd4d2lNVk1KenpzVGg0YmRCa2xPcHRucFdI?=
 =?utf-8?B?VWp4bWJpUlNXNWZjREVDTnQ2Vll4RTZ3MWRyUUVjZE5NM2NmWnJacEZKOWpo?=
 =?utf-8?B?c0IyVExFSU4vZTJSMERXSEJLa3V4NEVBeElzYTFBME9tTUpVaE5PUUxIT1k5?=
 =?utf-8?B?T3hDbkFRTlFvSG8zV3BuTm45UzNLRW93WlFwY1o5UjhuZC9MeWVOcTZkaHlv?=
 =?utf-8?B?WVNZdWp6c3ExRmIyRnR2a1pMcXlIOXFOdncvbG9oWGUrM0puSGo2UnkvcVBn?=
 =?utf-8?B?d2dWM1VDb01tMWNWYTlkS3B5MnREZFhVQzhoNEtNSndLMnAvOEJ5RkpndTIx?=
 =?utf-8?B?TVFVa1VSUkxPeitjd0RTVnk2eDN2QkpZaVNVN253TDJXNVJ4ZldHSHBnNUoy?=
 =?utf-8?B?NGs2a29KV25HSDdncVRJNjErekp2MzJHUTA3TzVHN2FrRGhFYUlUbEpUWFFt?=
 =?utf-8?B?WkhZSFNGdG9YLzdGUDR6dDk0dXVENmx0L054TUN0dFRvVUFsY0N2OE9PQ1Vp?=
 =?utf-8?B?RmF6RnU2aG9valR0WmtQOVNwNVl0SlpEMS9oS3RHdlBtQ2ZNT2lzSGZGRXk5?=
 =?utf-8?B?N01Zb2VDbmlWMm1BVFk1RzJIaGVKb3hQL0NxdThtcmVVaXJqc1RzdHVwTlRq?=
 =?utf-8?B?dnJldGR4Mjc4Y2NZM2JNOVFjRFZFaUc0SUE4cnJlMUc4cGJBQkVKNEg0RjR4?=
 =?utf-8?B?bURmNGVPQldhWGJoU01SSXE3NWpWeWhCOEV6cnZrNGxRVUh6VS9LNjBUdU9F?=
 =?utf-8?B?WE9VeFhXQVo1SzQ4SnVHTFZ0Q0JQTEVPUWRQNkZYaHoxZjlIZ1pjT3BpWVRL?=
 =?utf-8?B?SEVZRlZFdlhMTE5tKzhqZXpZaXVPOXdEVXFGWlgyUWp0NU92NnJhS05tQ2dJ?=
 =?utf-8?B?emw2R0F3bWV5RjhnQlFNWmhldXZaSzd4QmRDZ2dCYTV2L05xTjllZE9DS3VV?=
 =?utf-8?B?OTVJWWI0MGxtckd0MEs5QUEvdWRtdkRWYzM0Q0tRTkZrdnptVk9OZ0RxcWxE?=
 =?utf-8?B?ek1mbWJzSkpoNkl1UzJSNWp6RHduemFZbU40a3djUmRPczk2dUFEQjQrcVQ1?=
 =?utf-8?B?UnV0M282cVoxTHc3QTFKc0VGZmw0V21yT0hueE90V3VLOFNqR1JSaUlGNXEz?=
 =?utf-8?B?OXFYTTNaQk9xaCs4SE9LYTNDZlJwWGNqMUt2VTF5aXIvdU1zS0lRRmlvVjFM?=
 =?utf-8?B?Q3l2Q1l1Kyt0TVh2dWVPdFphMkZBSTdYWFFkUXNrdHRrV3hRbmZPck9RSUoy?=
 =?utf-8?B?NHRLYWdmK3hBeUVaTXg5SEtiUERoUW9aT0NoL3BpbkhtYWx2bnVDL2xvcG9h?=
 =?utf-8?B?Kzh3NUtwamIvWmd6TlNXZWNJRmROZTQvK21Pa280SFQrYlVCWUgxQUhrblBn?=
 =?utf-8?Q?X0+IDPLq6Sg=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.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?MTY4VkpFZnJkNzhUTldvdVhTaGY4anhhUEMxSjhmUW5TN2RLa0JkV1hmZE9l?=
 =?utf-8?B?TXIrRjhkL08xSGRHSFdkWkRYa3hjNUNqeU5LM3F4YmIvUUhCTFhneFJqNGNP?=
 =?utf-8?B?Nll0MWZsemFROWhYWnQydzNZblUwR3BkQzFmNWlFV0NKRjBKY0lDWHBHR0NV?=
 =?utf-8?B?dWoybk1vaUhXc2Q0cHY2SE9XNW04NktsNFRKZlFQNTFFdXVXZngwcE1ZcmhH?=
 =?utf-8?B?czRzdk5JdFhQTUQydzdzTnY0eUhSeWEzeU9NYm94bnRNSDYvQ0RaL2VLRU9N?=
 =?utf-8?B?dXVQb1AyTGczV01hQ2dCakFvQS8zVXN3UUlEaVdGSGJyM2tHZjRMWklYOFJi?=
 =?utf-8?B?d2dpTjI1SFpnK0daT2FWK3FWOGd3M1FrVCtCckE2KzZ1Nmlld2YzNi9IdUgy?=
 =?utf-8?B?RFAzUmFzREdueXRoWXpUT0dZaXVkRnhzWTFKZ0hWcy9WY28vS2lmRk5uNEl2?=
 =?utf-8?B?Z21QM2c4c1d3MzkxUEhPd2p0WWhhK3BBRkdBR3dSY0hHOEhYYTMranAzMkxY?=
 =?utf-8?B?T2N6QXJjWit2M2NoSlNTdTQ1MlVkZ01RdXQzRzJ1cHJBcDhSV2NSUjZLNDB1?=
 =?utf-8?B?R2JiYW14VndvUkdLdCtJNmhaRnhuSS8vMEhKTDBsKysrcVgvK2E0TERMNTYw?=
 =?utf-8?B?MXVDRTgva0d4dkRpNnRPYVMvSUNacXhnLzMvQVpRcUVEd2xna21zd3hKeGJm?=
 =?utf-8?B?aTc5OWhEVlBrWWFvQWZQZXlXOWhKMEZpQm9ZWVY2dWxWTVV1T09XWi9mMzZX?=
 =?utf-8?B?Mll4UUhEUzJRSnViRDNNRVVRTi9UQWJ6OVRWYjdKRDJiZklRVllqcUFzVWE1?=
 =?utf-8?B?YkNTNDdtbUxLVXFtRm5SaU0zMS9xL0FtMTgzeVhvSC85SzRJSDcyWHJRcm4y?=
 =?utf-8?B?WTladGlXUFJDbGFRZDRhMXBsUThrSVJCY1JlMzloSGVVYXBCQmgwektXdmp0?=
 =?utf-8?B?b2Q0TCtLU2xrbU80SndjMFZlaXhxSlcreFFKaURKT0JUbE1NMEYyR0tpeGd0?=
 =?utf-8?B?dlB5VEh1M2RXVEUyR1RmWDdGR1F2SFpwTFQvNng5aysxeUtRRGpDemhQdnFJ?=
 =?utf-8?B?dHdBcXFCbDFoL1JwTkVHc1Q4OHhHZitRdWo0aEdqdGY4QzVIZlB0RkpxVitE?=
 =?utf-8?B?cjZFUWVOYnhnb2dha21ZSnl0REdDMmp5Q1hGMjRXbExJVHZ2SnowOU5IUjA3?=
 =?utf-8?B?SnU0VGxhTVBXdlE3WTg1Y3pXSExONHJzQTd6MVhPTzBPeEgzN0FrMldLd3dl?=
 =?utf-8?B?b2hQSndlLzF4cTdVckNXWFh6aTJDU3dMeDJQRDg5K0xQc1dqazY2YllMN3J3?=
 =?utf-8?B?N3FCVi9xMTluMzhrMmc4UjJWOU91U2U1U1c0aFcyS1libW02ZVRxaVVJdjNq?=
 =?utf-8?B?RHBqNjFxZVhhTk5pSEJON0Jvc3BObmc1K1kzQWhLdW5RNDhqaW1YVFVjMTNY?=
 =?utf-8?B?a2hycmhvL0RNUlYzWW51eFRnK29BNXEzTUo2MzZXTlNERzZzRWpoWVQvMkMx?=
 =?utf-8?B?Nk5nN1h2SzJLeEkzSVZGZ3RDVkZydHY1d1JVb0ltM3NncUtyOSt4NTIySmVW?=
 =?utf-8?B?a3VuNGtaNWxONHM5bW5jYmwxMVo3S3A1b0ZrTEhUdnB3RGdLQXFGNFBKRWtz?=
 =?utf-8?B?WDhUbXNzOGFyZFN1aThlMFJqWTJTWXVxK1dNVjQ5UXlIZ3E5TWlMeFl5enN3?=
 =?utf-8?B?Q1g0aDdIeEFZcTVmTnJpaVBwRkdINFI5Umd0bU1RZGc5M1dWUnBkZTBqUnRy?=
 =?utf-8?B?UmxZTldmaktBTXFPMlB0ZEF5UG16STdPRmUxYUowMUxrczZlMjFzRWtwMzVD?=
 =?utf-8?B?WFIzS3JwTjNVTmMvTFRvbUxlK0NKZ0hEYkxFSUlSeHNuMFgyS0t6QXhxSFN3?=
 =?utf-8?B?Vm9sdjdDZFpqYWpWd0tyTk9Ca1dXUW1MeURZTkMvZ1hiZ2xYTEg4Uys0a2VZ?=
 =?utf-8?B?MHljeDN4WFZhMTNRT2FJVkd4TmtGNUVvdWgvT3U0Vnp0RmJNTURxekVGaW9n?=
 =?utf-8?B?a09HeUxPN0FqM1dZcnpBMlJYemVicHplTzREWXBVZjFRd25ORmQ3SFh1Yndm?=
 =?utf-8?B?SkdwNUhCUy9DaTJSUUZOQi9kSk9jeFlBK2t5TWNWWEVWWWxoSTdrM2M2Z3NX?=
 =?utf-8?Q?9a7B3vKoNg+fsCbYVV9b5gDiV?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1e0bfba6-51b9-4714-8ddc-08dda7e9f76a
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jun 2025 06:42:27.8650
 (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: P/ZeTSS8jTK6Ub8wvi1lDAXzylRZIi98c93igLS0yhaDPRdSsicjUb/munrvLOIQ
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR12MB7090



On 09/06/2025 22:54, Stewart Hildebrand wrote:
> In file included from ./include/xen/pci.h:72,
>                  from drivers/pci/pci.c:8:
> ./arch/arm/include/asm/pci.h:131:50: error: ‘struct rangeset’ declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
>   131 | static inline int pci_sanitize_bar_memory(struct rangeset *r)
>       |                                                  ^~~~~~~~
> cc1: all warnings being treated as errors
> 
> Fixes: 4acab25a9300 ("x86/vpci: fix handling of BAR overlaps with non-hole regions")
> Signed-off-by: Stewart Hildebrand 
> ---
>  xen/arch/arm/include/asm/pci.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/xen/arch/arm/include/asm/pci.h b/xen/arch/arm/include/asm/pci.h
> index 1605ec660d0b..1bbb9d780193 100644
> --- a/xen/arch/arm/include/asm/pci.h
> +++ b/xen/arch/arm/include/asm/pci.h
> @@ -17,6 +17,8 @@
>  
>  #ifdef CONFIG_HAS_PCI
>  
> +#include 
Just for the struct, I think it would be better to forward declare it (at least
this is what we recently started to prefer). Especially given that rangeset.h
also forward declares it.

That said, I don't find it mandatory, so with or without:
Reviewed-by: Michal Orzel 

~Michal



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 06:44:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 06:44:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010493.1388595 (Exim 4.92)
	(envelope-from )
	id 1uOsiE-0006AX-U3; Tue, 10 Jun 2025 06:43:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010493.1388595; Tue, 10 Jun 2025 06: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 1uOsiE-0006AQ-Qv; Tue, 10 Jun 2025 06:43:58 +0000
Received: by outflank-mailman (input) for mailman id 1010493;
 Tue, 10 Jun 2025 06:43: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 1uOsiD-00069l-Ad
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 06:43:57 +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 480b8629-45c6-11f0-a305-13f23c93f187;
 Tue, 10 Jun 2025 08:43:56 +0200 (CEST)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-3a510432236so3935322f8f.0
 for ; Mon, 09 Jun 2025 23:43:56 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4521370961csm130811365e9.22.2025.06.09.23.43.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 09 Jun 2025 23:43:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 480b8629-45c6-11f0-a305-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749537836; x=1750142636; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=0497diRMmIdHmG8eB0z+//O422UTY2BZrz9eG39NyrA=;
        b=Wsq0wTs3npPX1DQrYFzGt3ZHKzfr2deQ0aZTl/XDdwVNYSd1uco1FhoCsyFLuBhb2g
         Ta2ph9gADsvkhAJiStOKf90QKMIjjXF8uEfDX+Z9EXCUKCYadFfl+6YohEqRDHzUn+Lr
         cU1MTAl6YLr6aTz/vCea2z9k5vieFKpEl8dmT3GUF903MtCjxWofporRgZCmoe5NMdn1
         soKFHJ0RIBPgAbB3EugMWslHZw9j1zmz+Xp/qd+BhCXTcERm8R8/rFZv9XGIeGIzjqw0
         H21dvuRfCJ9X4kg9DIG/29efDPLLGDJW2rRPEw1OKjycteMpBaeoohwYsgyW9hmLQnPK
         2+5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749537836; x=1750142636;
        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=0497diRMmIdHmG8eB0z+//O422UTY2BZrz9eG39NyrA=;
        b=bERE7y6IFpLw1Z8l3w6Dp/LOy+OGsO/p1AnYe8QyuocBSLRE7Tck6dDK1hTTrxsIr7
         9HeJ99lSUPnYWgX/9ubpzOpaxt3iHY2DprT4g/B7FmRuZs2P5c+YqDa06Vw6CS6YIRKY
         aDbiWPTnO8J1CYfbVW8QleGnzFN7Hko18FX40yLKJK5y+i+UR0iUO0tONzQmrtJ662Vy
         PU7QSYA7VAKBhlKG9nK2fhHIhuz45t8kuk9IJQLEFjZ7bbPbeMG2K65zHySfr+E98J2z
         rjORj2TPmSoyS/ZGn9miA1U87+qM67W9kn9R1Ii0N3JP7J88AF3BCerTPsdKV4W3X7w4
         FSaw==
X-Gm-Message-State: AOJu0YxXrVTiBW56ZMtgWBZY+v4sfR/U3t/nXOaDSpi1hQfOlRscwgLf
	8GLTB/D0mTXzOAak0wnKlWMbqLvznj7Xmgm3aM//ZW7AemmEMdvsy21kJBDnl+Vj4A==
X-Gm-Gg: ASbGncueDFb9qxA8q4kYkmr9HP+7E3JFyIrr1TWiUvRl+B+DzDYbUMNrPOzh9hUUs0c
	4Xvw16IFpfAEiGY9DePsS+dxrPUhAyoQqHh/rLP3Hk3Y5Vw9oViCOox7xxfH238JQIbFXEbArkr
	Oyg0R484WOY9fBl84zjj12NzgRiy/mewMyZJLrHTtGXvb3FtbACr6oHXkRUT0zuEGcuVTKkkXxL
	W0iIFiI1AFXoAungTLt5Ka6+sGacCj2sHoCfQETt5b8M4eqhNI3YQ+zNNk8OuOjGSkECE4AxGg4
	F4eCwdVemtZ6MWcMDoWWvc9XxeYwa40pVQ8TQTX18/HfTw6pB69hK162BWemEu9ekHKM+oFVfET
	+MG9IChrnHd2ZR/jUvmkbPlFbvyXZvfdLJQeJkgmFk4cA0dcjNFUfXBhY0/6mVyRu3wbq5ojrTN
	sFk1Jz8pMa19737P07X2XV
X-Google-Smtp-Source: AGHT+IH+QdtC3LD/N3T/PM3BdTjfK15R74xinuSNxPe1G+V8mDHEDqxP1yPaX4m/hoCXgjQpScIt7g==
X-Received: by 2002:a5d:5c84:0:b0:3a4:fc37:70f5 with SMTP id ffacd0b85a97d-3a531cf1c12mr12249621f8f.58.1749537835811;
        Mon, 09 Jun 2025 23:43:55 -0700 (PDT)
Message-ID: 
Date: Tue, 10 Jun 2025 08:43:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/2] xen/console: unify printout behavior for UART
 emulators
To: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com,
 anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com,
 roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
References: <20250605004601.1142090-1-dmukhin@ford.com>
 <20250605004601.1142090-3-dmukhin@ford.com>
 <842528df-d0ba-4ab2-b182-b6f824c82dc1@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 06.06.2025 21:47, dmkhn@proton.me wrote:
> On Fri, Jun 06, 2025 at 09:12:06AM +0200, Jan Beulich wrote:
>> On 06.06.2025 09:06, dmkhn@proton.me wrote:
>>> On Thu, Jun 05, 2025 at 08:18:34AM +0200, Jan Beulich wrote:
>>>> On 05.06.2025 02:46, dmkhn@proton.me wrote:
>>>>> From: Denis Mukhin 
>>>>>
>>>>> If virtual UART from domain X prints on the physical console, the behavior is
>>>>> updated to (see [1]):
>>>>> - console focus in domain X: do not prefix messages;
>>>>> - no console focus in domain X: prefix all messages with "(dX)".
>>>>>
>>>>> Use guest_printk() without rate-limiting in all current in-hypervisor UART
>>>>> emulators. That aligns the behavior with debug I/O port 0xe9 handler on x86 and
>>>>> slightly improves the logging since guest_printk() already prints the domain
>>>>> ID. guest_printk() was modified to account for console focus ownership.
>>>>>
>>>>> Modify guest_console_write() for hardware domain case by adding domain ID to
>>>>> the message when hwdom does not have console focus.
>>>>>
>>>>> [1] https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2412121655360.463523@ubuntu-linux-20-04-desktop/
>>>>> Signed-off-by: Denis Mukhin 
>>>>> ---
>>>>> Changes since v1:
>>>>> - dropped change for debug port and for HYPERVISOR_console_io hypercall
>>>>
>>>> Yet then what about ...
>>>>
>>>>> --- 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);
>>>>
>>>> ... this dropping of XENLOG_G_DEBUG? In fact I'd have expected such to
>>>> be _added_ where presently missing.
>>>
>>> vUART is a debugging facility. This flavor of UART is specifically for guest OS
>>> early boot debugging.
>>> I think it is not desirable to potentially lose guest messages while doing such
>>> early guest OS boot debugging.
>>
>> That is the host admin's decision, not a policy we should enforce.
> 
> re: policy: agreed, I will drop that hunk.
> 
> I think for the policy control, there can be a compile time setting (separate
> patch) which enables/disables the debug output rate-limiting - and that setting
> applies to:
>   - vUARTs (currently vpl011 and "vuart", later ns16550 (x86) and upcoming
>     emulator for RISC-V)
>   - debug port on x86
>   - HYPERVISOR_console_io
> 
> What do you think?

I'm not convinced, but much would depend on the justification for such a change.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 06:45:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 06:45:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010504.1388605 (Exim 4.92)
	(envelope-from )
	id 1uOsk0-0006lW-C5; Tue, 10 Jun 2025 06:45:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010504.1388605; Tue, 10 Jun 2025 06:45: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 1uOsk0-0006lP-9M; Tue, 10 Jun 2025 06:45:48 +0000
Received: by outflank-mailman (input) for mailman id 1010504;
 Tue, 10 Jun 2025 06:45: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 1uOsjy-0006kt-Ir
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 06:45:46 +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 895d3f00-45c6-11f0-a305-13f23c93f187;
 Tue, 10 Jun 2025 08:45:46 +0200 (CEST)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-45310223677so15469205e9.0
 for ; Mon, 09 Jun 2025 23:45:46 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a53244d66dsm11309471f8f.70.2025.06.09.23.45.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 09 Jun 2025 23:45:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 895d3f00-45c6-11f0-a305-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749537945; x=1750142745; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=rPqqmChlsscHEQwEsLxtyHC0WCfJon+msaoELp0p7pI=;
        b=OomnDXjnwWGAjLhdqZf7SHKEoHTqIVX8+XiJ5EKP2En6a2p8iInWUboI7xcYTFHebM
         yYdi7p/lKkiltlCjiqkbfKgTIvGdvWLjSAvH4Ef9WYbtd5XoaVXtsi5u3mlyJ/y1p6M+
         tmGSGzUTtxN6egFQUwULfn9WovxEUMSX/bfSi6e2JRQ2JXYBce0N2gJTncDIoY+fICU8
         upsFIXTvR5gM9kgacl/RbScNa87csbtdfksDEllbHyoZP0IhoGDFjq6KHEwsN+EaPQxg
         D8e+fWu3R2s3TpcTMnWAatgEeBDIQ4a10Nm7zb1BIkB5OV6HhycMiAr+N8RlM537t2Hd
         0jlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749537945; x=1750142745;
        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=rPqqmChlsscHEQwEsLxtyHC0WCfJon+msaoELp0p7pI=;
        b=fnXZsc0hcSA7hh/W3wdmwQNbQ80L+0QnNmt54vrUeWvrRUy09wfVGO9DMHb0q8dj0y
         aGu3bFSXHzebbNi9y0qX3unFZED+/t1jVBPuh/uKaHjwasiup6MLHD+AB3B5ZZgH/spR
         AHetT2OHOjnfcXTrFFLSErXZv3IH4FhQ4NKrdHNmlqSYXhXFPMKaYfksFv/H1lljXBYW
         wQ5HVEW0S3MD6F0OknysXK6mjk7flAck3POMHGxdCuyqMfvaCoTNNSbU/AsZiX9YTdKF
         kgwp2xSwIGSuQRWTBP9IV08O7cWg9XEb8O0q2D52JT3qfFLYwu+ImReL6IVlYrEQQ34b
         A0Jw==
X-Forwarded-Encrypted: i=1; AJvYcCXjOrHb3F4+aGASCtSN0H4+N8Kk4ypkW1EiCgp6kRhn4hFOKxmRxFrM1VQNLXHAVyB8ppiHH99eF/o=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxJzT3SIooIJiWB07oNR6bAIe0pJiNh58tu9r4xhVd5sKj2Qq33
	edNCGGpaLClG6tsSzQpoYJArAJqYtddNwgBDKxva8k5h88YPXuFVW7caQnV/ZMg4DA==
X-Gm-Gg: ASbGncu6EbFQyovU+1o01mf2n//FEnwMoqoKV+U7RcbvZkUjrY1N2R/qnQVnjMYjGyH
	3Qkmrc2K3euKH1d7NvicIqJsWklpypT2BEizksIJ1qr7jCReVHf33GUUWRSp/ty7pYagnxkwDuO
	hB1xQgx/xxzx20IuJICDVxsD4r84shRvKd0HJJYr0lDgM2s2Y2k1lGyPdVUZFPQ5mFU8Z2pD2Fc
	CUIu6IclupTqyL/eFFSOCmGTP/LG95v5JEiceKcLW3SpMA8lDyKIWLvAFPJOUSossLbTVDzayn6
	prGV/v+peFq/PD5pVxQLLXQ5/5GbX1OE/f2Nj5rHpfFntn6Sg8BTnSsI/9sfObAjjG5IhbvzEm6
	AzsGMm1C0qJFvHJUdtYBv2aLwblbCscdIzrlFuQY9w0KYcsWoTlBVxRoGa6jIAPad1XZ5jL7uoH
	O/ghnGSKeoij5v774ZL6nW
X-Google-Smtp-Source: AGHT+IFDQ80SIxCcpCujF8xngt+sFTFE4Mll8+iFFyOmrlVzQ8Zs20zDC8WcyZDsHfGhEm2lactEEw==
X-Received: by 2002:a05:600c:a44:b0:43c:fcbc:9680 with SMTP id 5b1f17b1804b1-4520140470fmr127167715e9.25.1749537945407;
        Mon, 09 Jun 2025 23:45:45 -0700 (PDT)
Message-ID: <315e605d-2da6-4df5-b791-b3f59e0ff6d4@suse.com>
Date: Tue, 10 Jun 2025 08:45:44 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86: remove memcmp calls non-compliant with Rule 21.16.
To: Stefano Stabellini ,
 Nicola Vetrini 
Cc: Stefano Stabellini ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Alessandro Zucchelli ,
 xen-devel@lists.xenproject.org, federico.serafini@bugseng.com
References: <20250604233537.2892206-1-stefano.stabellini@amd.com>
 
 
 <13ad335c1868bcc02e2dc0a8da521f6d@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 06.06.2025 22:49, Stefano Stabellini wrote:
> On Fri, 6 Jun 2025, Nicola Vetrini wrote:
>>>>> Signed-off-by: Alessandro Zucchelli 
>>>>
>>>> Missing your own S-o-b.
>>>>
>>>> Also (nit) may I ask that you drop the full stop from the patch subject?
>>>
>>> I'll add the S-o-B and fix the subject
>>>
>>>
>>>>> --- a/xen/arch/x86/dmi_scan.c
>>>>> +++ b/xen/arch/x86/dmi_scan.c
>>>>> @@ -233,7 +233,7 @@ void __init dmi_efi_get_table(const void *smbios,
>>>> const void *smbios3)
>>>>>  	const struct smbios_eps *eps = smbios;
>>>>>  	const struct smbios3_eps *eps3 = smbios3;
>>>>>
>>>>> -	if (eps3 && memcmp(eps3->anchor, "_SM3_", 5) == 0 &&
>>>>> +	if (eps3 && strncmp(eps3->anchor, "_SM3_", 5) == 0 &&
>>>>
>>>> Unlike the last example given in the doc, this does not pose the risk of
>>>> false "not equal" returns. Considering there's no example there exactly
>>>> matching this situation, I'm not convinced a change is actually needed.
>>>> (Applies to all other changes here, too.)
>>>
>>> If we consider string literals "pointer types", then I think you are
>>> right that this would fall under what is permitted by 21.16. Nicola,
>>> what do you think?
>>>
>>
>> While I agree that the result of the comparison is correct either way in these
>> cases, the rule is written to be simple to apply (i.e., not limited only to
>> those cases that may differ), and in particular in the rationale it is
>> indicated that using memcmp to compare string *may* indicate a mistake. As
>> written above, deviating the string literal comparisons is an option, which
>> can be justified with efficiency concerns, but it goes a bit against the
>> rationale of the rule itself.
> 
> Also looking at Andrew's reply, it seems that the preference is to
> deviate string literals. The change to docs/misra/rules.rst is easy
> enough, but I am not sure how to make the corresponding change to
> analysis.ecl.
> 
> diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
> index e1c26030e8..56b6e351df 100644
> --- a/docs/misra/rules.rst
> +++ b/docs/misra/rules.rst
> @@ -813,7 +813,7 @@ maintainers if you want to suggest a change.
>         shall point to either a pointer type, an essentially signed type,
>         an essentially unsigned type, an essentially Boolean type or an
>         essentially enum type
> -     - void* arguments are allowed
> +     - void* and string literals arguments are allowed

Yet as per my earlier reply: This would go too far, wouldn't it?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 06:53:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 06:53:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010510.1388615 (Exim 4.92)
	(envelope-from )
	id 1uOsrE-0008QB-3N; Tue, 10 Jun 2025 06:53:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010510.1388615; Tue, 10 Jun 2025 06: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 1uOsrD-0008Q4-Vx; Tue, 10 Jun 2025 06:53:15 +0000
Received: by outflank-mailman (input) for mailman id 1010510;
 Tue, 10 Jun 2025 06: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 1uOsrC-0008Py-UZ
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 06:53:14 +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 945d98be-45c7-11f0-a305-13f23c93f187;
 Tue, 10 Jun 2025 08:53:14 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-450ccda1a6eso47235415e9.2
 for ; Mon, 09 Jun 2025 23:53:14 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a53244f07dsm11558364f8f.79.2025.06.09.23.53.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 09 Jun 2025 23:53:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 945d98be-45c7-11f0-a305-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749538393; x=1750143193; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=SfvW4Xlh/9Vx6YPL9vMgWdJg+jlNLW7lnjHTKilal9M=;
        b=G2RNDD/eDU6qnBRBKDkycS1RoqV5OCY4KB9BA66dZwM+H0sAp1QnMgS5tT4OuSdiFA
         D5JaHjO22T4VfpBGbpY/dIX2MOmmb2aKrRIinAl/hoKJL5U+qinDild8aid4OuGVoh3E
         YKTzQlDVdGbiekBWwOh0gwIWFkZu8Wj/zz9sw/aFEVa/qJ57mDTYoKIVJ0Mp44wL+OgK
         zDyScvMwwOnIqs2wD0KH78KkgW3kwNlz1BaM6VgYQVUNzate7IWdEAhhtbXmJUDZEH55
         CQQgjGtEUiYuY+iQDfpOTvCDXhwKiSLk8guMoWSRZUiwVyDrBrkPJjzhoR93+euuubIs
         YW2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749538393; x=1750143193;
        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=SfvW4Xlh/9Vx6YPL9vMgWdJg+jlNLW7lnjHTKilal9M=;
        b=FSLOvbn6OvHj1I/SRGYnJ8SFmygEuDSrhvCnmnxA0XMSYCJwmxDvRjeMifgpxSjNuU
         yGRVoQyzRBbw/0ZIINTdLgMg2HE00KCJTHeBaE4sKDL0pNlYY+zsolzfLj6OJ3om9nVy
         1I0DDB3F2ecwW8RD5KNaPbxxsQ3bWlYaWndKYQCv0m/x/qO+MU52rXh1DshtYX/1+fct
         a+hcH/X4i87vGhdok1wBrjFsRjaY2d8BPvPG1uVflzZNz6vb/F7ywSxtDDiKV2+21A+c
         GDWgVmpWWqRlsj3AqSmBBe+nzD0A3QCBevbyOgm8w0kNAa3LHb1z9W432h2puWd/pWq4
         cKuQ==
X-Forwarded-Encrypted: i=1; AJvYcCWHiazW4+v/juF9SbtOOZfDyK1hPIaTj+pB8qVTdy8O4imjnMiEkXgfy3J2tMMJnk6ypABORuSS7d0=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy1oe8YWneZ4tT/2gNkMN4K2nXZJsfopaEDTow00b+Xei3sId5o
	vNzlAsWrWZWExPIBk6yxFOcYN60gzs1nkzXYJ17t9g9da7pS5BNa9y+dlMFS4P0w+w==
X-Gm-Gg: ASbGncvYDR7dUwVpikAfV2kZwvqR9rqv/9GQNYLcI/M1M5KqAZIzLrWqbXeAElBQ4Sv
	NsNCF+7hhvwStKvGMw48LGZT8RUAuRqFccSS3ZqkZ7lr53S0p8GTI6wDtYwGZCKMpc1BC/1ppPk
	/hQHVi2VLUkPsK1b4kOC+B092om7nzCYe12uDwFRAZm/GSL++4+HO2uiB4LK65AeSnkAeoWv49N
	K5rrf0r4JdMX34T6QLkulKyCMjouocuIvuzgtXP5EVjAp3fe4sc0xoVaphtCZqWoarKtGrbjzq4
	raoVYDtZrPsSwPSW2JFzLRLpkeGB8rI+mitTWRztxgb0tpR3tpcmazH7Cl7tcb0rNM0m5OV8KO9
	0bjAixHhRhYopY1kJ+9JtOqnpktzP7V2qlzC/WscWZP1qN6qzVXWmYEvys1Jm2Mpz0P7yjDmk2j
	D3y5meeCzy9FtnMSLE1JIG
X-Google-Smtp-Source: AGHT+IFDHi+S1Yhxpm0uC7t6pV9GvEVh/xV66TGSImK1BpM9n/sDudrJwujBC62Qa9UqNeHAEFqqRg==
X-Received: by 2002:a05:600c:154c:b0:453:b44:eb69 with SMTP id 5b1f17b1804b1-4530b44f1acmr68227515e9.13.1749538393374;
        Mon, 09 Jun 2025 23:53:13 -0700 (PDT)
Message-ID: <30c01c78-5a5e-435f-9b1c-faca3af04a76@suse.com>
Date: Tue, 10 Jun 2025 08:53:12 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 2/3] xen/domain: adjust domain ID allocation for Arm
To: Julien Grall , dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech,
 roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech,
 dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250528225030.2652166-1-dmukhin@ford.com>
 <20250528225030.2652166-3-dmukhin@ford.com>
 <63087c42-d709-4e53-a2c3-8b812f13190a@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: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 06.06.2025 23:29, Julien Grall wrote:
> Hi Denis,
> 
> On 05/06/2025 23:05, Julien Grall wrote:
>> Hi Denis,
>>
>> On 28/05/2025 23:50, dmkhn@proton.me wrote:
>>> From: Denis Mukhin 
>>>
>>> From: Denis Mukhin 
>>>
>>> Remove the hardcoded domain ID 0 allocation for hardware domain and replace it
>>> with a call to get_initial_domain_id() (returns the value of hardware_domid on
>>> Arm).
>>
>> I am not entirely why this is done. Are you intending to pass a different domain ID? If so...
>>
>>>
>>> Update domid_alloc(DOMID_INVALID) case to ensure that get_initial_domain_id()
>>> ID is skipped during domain ID allocation to cover domU case in dom0less
>>> configuration. That also fixes a potential issue with re-using ID#0 for domUs
>>> when get_initial_domain_id() returns non-zero.
>>>
>>> Signed-off-by: Denis Mukhin 
>>> ---
>>> Changes since v8:
>>> - rebased
>>> ---
>>>   xen/arch/arm/domain_build.c             | 4 ++--
>>>   xen/common/device-tree/dom0less-build.c | 9 +++------
>>>   xen/common/domain.c                     | 4 ++--
>>>   3 files changed, 7 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>>> index e9d563c269..0ad80b020a 100644
>>> --- a/xen/arch/arm/domain_build.c
>>> +++ b/xen/arch/arm/domain_build.c
>>> @@ -2035,9 +2035,9 @@ void __init create_dom0(void)
>>
>> ... naming like create_dom0() probably wants to be renamed.
>>
>> That said, I am not convinced a domain other than 0 should have full privilege by default. So I would argue it should stay as ...
>>
>>>       if ( !llc_coloring_enabled )
>>>           flags |= CDF_directmap;
>>> -    domid = domid_alloc(0);
>>> +    domid = domid_alloc(get_initial_domain_id());
>>
>> ... 0.
> 
> Looking at the implementation of get_initial_domain_id(), I noticed the behavior was changed for x86 by [1].
> 
> Before, get_initial_domain_id() was returning 0 except for the PV shim.
> But now, it would could return the domain ID specified on the command line (via hardware_dom).
> 
> From my understanding, the goal of the command line was to create the hardware domain *after* boot. So initially we create dom0 and then initialize the hardware domain. With the patch below, this has changed.
> 
> However, from the commit message, I don't understand why. It seems like we broke late hwdom?
> 
> For instance, late_hwdom_init() has the following assert:
> 
>     dom0 = rcu_lock_domain_by_id(0);
>     ASSERT(dom0 != NULL);
> 
> Jan, I saw you were involved in the review of the series. Any idea why this was changed?

I simply overlooked this aspect when looking at the change. You're right, things
were broken there. Unless a simple and clean fix can be made relatively soon, I
think this simply needs reverting (which may mean to revert any later commits
that depend on that). I can't help noting that in this console rework there were
way too many issues, and I fear more than just this one may have slipped
through. I therefore wonder whether taken as a whole this was/is worth both the
submitter's and all the reviewers' time.

Jan

> [1] https://lore.kernel.org/all/20250306075819.154361-1-dmkhn@proton.me/
> 



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 06:56:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 06:56:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010516.1388625 (Exim 4.92)
	(envelope-from )
	id 1uOsu6-0000XN-G0; Tue, 10 Jun 2025 06:56:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010516.1388625; Tue, 10 Jun 2025 06: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 1uOsu6-0000XG-DP; Tue, 10 Jun 2025 06:56:14 +0000
Received: by outflank-mailman (input) for mailman id 1010516;
 Tue, 10 Jun 2025 06: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 1uOsu5-0000XA-Qc
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 06:56:13 +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 ff0cc77c-45c7-11f0-a305-13f23c93f187;
 Tue, 10 Jun 2025 08:56:13 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3a50fc7ac4dso3272358f8f.0
 for ; Mon, 09 Jun 2025 23:56:13 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a53244df34sm11567746f8f.71.2025.06.09.23.56.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 09 Jun 2025 23:56:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ff0cc77c-45c7-11f0-a305-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749538572; x=1750143372; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=897J7jDLs92ieMJFM2XGqS8hZldTET+6U7XnxbOkPpE=;
        b=bMXE8uTYA1BBEx30t1FpCGGB5z86oW5fDH2oAFjCpYGY6ipglTlLRBYWAIBq9Gnci9
         BpZd096qXdAhDaS1oeNBwASyWUCJPWXLr6WqYIfrWo+k5xHcFJNql5coUuOKJHzyzjwz
         nLcvFHq2hfqv3zbQE6s9nAf4BJbTGeivANPfSkI5E0loBxfpy0DcFqzRSTJt8TOrPtgm
         VFFTW3wOu1cZF5n975XsjMFHAZyqL6xnhK0eDh41aOKCG1Yon1v5NDEmWoc30AqGTg+j
         te75rA6SLGBIcxG0zTQ20KbkauN6foiBzI5xyRtTFiO/US8Nqrn90G/9MTquZzIgZ4fD
         3cNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749538572; x=1750143372;
        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=897J7jDLs92ieMJFM2XGqS8hZldTET+6U7XnxbOkPpE=;
        b=PNu/P+lU0kmKOjR9es30k6eHPF5u+H1EkmQCG4Ltob2mkHDO1ed3d+Bz+nEBFH1Z4d
         Lsb84l6TYwidp4q5yOKF9AOKCVn6+xTPy9tSFKS9rt8MYhKirFLDsOzoa5fyCiMNdwXl
         bkXsI97A4CP8WCLK3n5X7skRuDq7nXICoTExWKoSQrddkFmBc9VxcDOZQLSbTKCrW/x2
         ZRD2pD6coIFpoOjCykQ17JH6xWqm/JUE5V4382FrK8GFs0T0qmUXcAN0iIhqdO7U/w7R
         ODbm64WqEi5NmUCooTg5/joA9e2DUyFJBrcabSoI8V0Hl7ziaI+XxBrc5sqo1b+k8NwH
         oFIA==
X-Forwarded-Encrypted: i=1; AJvYcCVCgIKMv1qyNa+Jkm7A/hSyOVIfb1BDXc/HOoHCXPjxbCEC0o/Ivv6/K/ErXrkT5VxCKgv0aP2jamE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxmlg6MY607VhOKiMZ5cl2XOoH4hpUs0wRfTzMCMjgDzSmig+Kh
	gP73+lmuvI60SxlitkdOuSIXeQcgOjnnZycLop2GFSBJIGXfJXotblmXef3pTMqtuA==
X-Gm-Gg: ASbGnct7vT07YioddWYFohIaCgl7eptSd5/ZINkTlFxnkJDG+artA3opRxyjmLNsTt8
	i1vkblz5Yvi8B9yZizYWox0ro8J3i130ASVrftNME/2rMV+5XP50WNIrOi8XkKuug484hHO/e7Q
	j68XePThqXaUfn5FR4Jv922kgzn5Vv23fpqzO3kwTxhj6+Dz9qywFcUfAucnOGM/qpupofQzNrb
	FHddD+x9uJLAePt/HQYx5o+DB/wVjNP+92f55JbbPpo+7KCrO7xjmwLUWooL73fQM9TWOmHzpFy
	mNLD0PT3nlMtpIH0PwSYOVOIGDHhgieEltM4b4RS7/YjWsBoHMsaBQFTrt+3zGXx0IeazlF660M
	WxrokDGVseo6BRaHjnnSjbQKWEarkJqMvg4S60dRqDTg6cOIlvjnQ31T8tqnyiGisxA02UDBnw2
	Uo64RLd3TfRb6jXRbimKyn
X-Google-Smtp-Source: AGHT+IEQ4lLW9lzQsSdVtn4yNpxUQXAV0U93zKFJNvUmtvxoLfECYZ+zliTA9fdLVw28g0lCt9sGaA==
X-Received: by 2002:a05:6000:220d:b0:3a1:f5c4:b81b with SMTP id ffacd0b85a97d-3a5522786acmr1165699f8f.23.1749538572405;
        Mon, 09 Jun 2025 23:56:12 -0700 (PDT)
Message-ID: <02ffa9cf-b5cd-431a-834a-a11bbf310196@suse.com>
Date: Tue, 10 Jun 2025 08:56:11 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 06/12] x86/hyperlaunch: obtain cmdline from device tree
To: Jason Andryuk 
Cc: "Daniel P. Smith" ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini ,
 Bertrand Marquis , Denis Mukhin
 , Alejandro Vallejo ,
 xen-devel@lists.xenproject.org
References: <20250429123629.20839-1-agarciav@amd.com>
 <20250429123629.20839-7-agarciav@amd.com>
 <59f37fcc-9226-46c5-8dc8-7bd2100d8f59@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: <59f37fcc-9226-46c5-8dc8-7bd2100d8f59@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 09.06.2025 19:07, Jason Andryuk wrote:
> On 2025-04-29 08:36, Alejandro Vallejo wrote:
>> From: "Daniel P. Smith" 
>>
>> Add support to read the command line from the hyperlaunch device tree.
>> The device tree command line is located in the "bootargs" property of the
>> "multiboot,kernel" node.
>>
>> A boot loader command line, e.g. a grub module string field, takes
>> precendence over the device tree one since it is easier to modify.
>>
>> Signed-off-by: Daniel P. Smith 
>> Signed-off-by: Jason Andryuk 
>> Signed-off-by: Alejandro Vallejo 
>> Reviewed-by: Denis Mukhin 
>> ---
> 
>> diff --git a/xen/common/domain-builder/fdt.c b/xen/common/domain-builder/fdt.c
>> index cbb0ed30a2..dabe201b04 100644
>> --- a/xen/common/domain-builder/fdt.c
>> +++ b/xen/common/domain-builder/fdt.c
>> @@ -219,6 +219,12 @@ static int __init fdt_process_domain_node(
>>               printk(XENLOG_INFO "  kernel: multiboot-index=%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] )
> 
> The logic is incorrect - it should be:
> 
>             if ( !bd->kernel->cmdline_pa ||
>                  !((char *)__va(bd->kernel->cmdline_pa))[0] )
> 
> If there is no cmdline_pa (which happens with the "reg" property) or the if there is a 0-length string, then check the DT for bootargs.

Even that sounds bogus to me: There's a difference between "no command line"
and "empty command line".

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 07:08:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 07:08:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010522.1388634 (Exim 4.92)
	(envelope-from )
	id 1uOt5d-0002HQ-G1; Tue, 10 Jun 2025 07:08:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010522.1388634; Tue, 10 Jun 2025 07:08: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 1uOt5d-0002HJ-DS; Tue, 10 Jun 2025 07:08:09 +0000
Received: by outflank-mailman (input) for mailman id 1010522;
 Tue, 10 Jun 2025 07:08: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 1uOt5c-0002HD-13
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 07:08:08 +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 a60c5e40-45c9-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 09:08:02 +0200 (CEST)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-451e2f0d9c2so39086765e9.1
 for ; Tue, 10 Jun 2025 00:08:02 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a5323b33c3sm11559901f8f.34.2025.06.10.00.08.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 00:08:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a60c5e40-45c9-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749539282; x=1750144082; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=7OIufhB56DSUHISwapg5RX9lWzyFlOwrJcEowX+vfyQ=;
        b=cM+BfOQPbB9coTRvXK9VRCNfhxdou17KYe7zbm+fJYBHZ9c8XDHX2BJ/zUxahgP3hA
         FD5ncHm+w+AeD48lGZ/i7d6uDqurHcrXzzarNGAX42QVsT3fkd+50yIhMSWgGJKvzoLJ
         UGwZUzuHzBAA0XgL84EzEAYcScfYcylv/mwxLtvK6eZWAFdduZ39NlwBKUz2NN9HL5MI
         FxSCS0eV4RVBtlORMYIAQSFvHHDM31sVCsb9K4lnXV6y7OnbgNmHbOrTQdJX2htX3cNY
         Yvf+OYHUlJqFEutUrhAPDc+3f4JgX7LSX0iUaQcQdtuDUxoccWCzqcp83Tx+Eoyi9I8v
         HBug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749539282; x=1750144082;
        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=7OIufhB56DSUHISwapg5RX9lWzyFlOwrJcEowX+vfyQ=;
        b=h2rx5dT4huAaZAkl1xVkDfLyCRBME+tynII08gv6iv78pF6LfyUXBQ3pxxFDt/FA3C
         +KUxElMORmFqibseUAIH9v7w9R+SyLXlvVoonYj83QUYUacGN+LUW66n1DCwnJymN5v8
         y8Sv1Dq3GlCHOJIAb1GlJTTc6uDEzQVzjEZ+AgWe2n8dQ4APGnvEiJ0zWb9ARAwyaUdx
         xjE/+Y0IzlE27PYor4n5LpVYQzj6YANgRzm/9/QKVP2z54/JjsL7QJa6chSakOtqC+OT
         E9ZbK3NrxEpRLS9mppc4y51rQuN66Y9ZY1/JOJaVNCplimH7oZqBxDqxF+6nmRb4MXZN
         vh9A==
X-Gm-Message-State: AOJu0YwN2dEFjIu+AjDn5fVmiaL03YIabKgIqptM8CsxIptuUR4nn6lW
	HY+f0IVC7D7Wk7TFC0erGxwCqofLmiUnBJ1nopv7EgaUWThM3F4SP5tG87jpriQgvw==
X-Gm-Gg: ASbGnct4xF/Dig4vlGuhR/2QT3Z6iZgK3e4PLlNhQSW8yGV71YHAZTxfZBMXdne8J/H
	T1Ng8Ci6VchLC246r9OKXUaO5SnXp0bqi1VHD1FoQOpxBfX+XhkGtLK9wbWrgebq/ewDFvcAvJV
	/heT9i3MVCfe3rBCHxL2d4x0APJT0YJiTFPrT/4k0hXvGviNwXIRL6auoyGV+4gsKkF4f4kr+s1
	vE+ZreJoyrtJNNZnU1T4Fgjp7cyD1UzY1wE2wPa8f4yN6sTkIjiVyf3RsP5+CMhxdZRS0ARZQxg
	PgRsYen2i9Rd7DhE5FG4/MbHtoUak9q0V8Dp+So7C5ibGbnEZ6Epyex5gV3MCu+W+H20YtqJr7a
	Z+T1dHTS50Yssn7dfr7wSDTp30sysqXPQOcV75KVL0bKaraj3pRj0rL0zPsXr9MQ4jCitb/8xsw
	+AKp2LcFi1heyNSgaKPsyy
X-Google-Smtp-Source: AGHT+IGFHpwHP632fG6AuLr4Iw5WYTdABjxm7wzoJBz9rRgqaEW7nQrqP6Gz7sO5dhUxzogg0KSYiw==
X-Received: by 2002:a05:600c:5303:b0:442:f4a3:a2c0 with SMTP id 5b1f17b1804b1-4531cffa4bemr20889975e9.13.1749539282080;
        Tue, 10 Jun 2025 00:08:02 -0700 (PDT)
Message-ID: <6a7a1ab8-aabb-465b-bd22-a2bc1597b83b@suse.com>
Date: Tue, 10 Jun 2025 09:08:01 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 04/10] vpci: Refactor REGISTER_VPCI_INIT
To: "Chen, Jiqian" 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper ,
 Anthony PERARD ,
 "Orzel, Michal" , Julien Grall ,
 Stefano Stabellini , "Huang, Ray"
 , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
 <20250526094559.140423-5-Jiqian.Chen@amd.com>
 
 
 <752cff02-cef6-4a4c-80b9-eba3bbf9b264@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.06.2025 05:52, Chen, Jiqian wrote:
> On 2025/6/9 18:40, Roger Pau Monné wrote:
>> On Mon, Jun 09, 2025 at 10:18:42AM +0000, Chen, Jiqian wrote:
>>> On 2025/6/9 17:29, Roger Pau Monné wrote:
>>>> On Mon, Jun 09, 2025 at 07:50:21AM +0000, Chen, Jiqian wrote:
>>>>> On 2025/6/6 17:14, Roger Pau Monné wrote:
>>>>>> On Fri, Jun 06, 2025 at 09:05:48AM +0200, Jan Beulich wrote:
>>>>>>> On 06.06.2025 08:29, Chen, Jiqian wrote:
>>>>>>>> On 2025/6/5 20:50, Roger Pau Monné wrote:
>>>>>>>>> On Mon, May 26, 2025 at 05:45:53PM +0800, Jiqian Chen wrote: 
>>>>>>>>>> +  }; \
>>>>>>>>>> +  static vpci_capability_t *const finit##_entry  \
>>>>>>>>>> +               __used_section(".data.vpci") = &finit##_t
>>>>>>>>>
>>>>>>>>> IMO this should better use .rodata instead of .data. 
>>>>>>>> Is below change correct?
>>>>>>>>
>>>>>>>> +    static const vpci_capability_t *const finit##_entry  \
>>>>>>>> +        __used_section(".rodata") = &finit##_t
>>>>>>>
>>>>>>> No, specifically because ...
>>>>>>>
>>>>>>>>> Not that it matters much in practice, as we place it in .rodata anyway.  Note
>>>>>>>>> however you will have to move the placement of the VPCI_ARRAY in the
>>>>>>>>> linker script ahead of *(.rodata.*), otherwise that section match will
>>>>>>>>> consume the vPCI data.
>>>>>>>> I am sorry, how to move it ahead of *(.rodata.*) ?
>>>>>>>> Is below change correct?
>>>>>>>>
>>>>>>>> diff --git a/xen/include/xen/xen.lds.h b/xen/include/xen/xen.lds.h
>>>>>>>> index 793d0e11450c..3817642135aa 100644
>>>>>>>> --- a/xen/include/xen/xen.lds.h
>>>>>>>> +++ b/xen/include/xen/xen.lds.h
>>>>>>>> @@ -188,7 +188,7 @@
>>>>>>>>  #define VPCI_ARRAY               \
>>>>>>>>         . = ALIGN(POINTER_ALIGN); \
>>>>>>>>         __start_vpci_array = .;   \
>>>>>>>> -       *(SORT(.data.vpci.*))     \
>>>>>>>> +       *(.rodata)             \
>>>>>>>
>>>>>>> ... this isn't - you'd move _all_ of .rodata into here, which definitely
>>>>>>> isn't what you want. What I understand Roger meant was a .rodata-like
>>>>>>> section, e.g. .rodata.vpci.* (much like it was .data.vpci.* before).
>>>>>>
>>>>>> Indeed, my suggestion was merely to use .rodata instead of .data, as
>>>>>> that's more accurate IMO.  I think it should be *(.rodata.vpci) (and
>>>>>> same section change for the __used_section() attribute.
>>>>>
>>>>> If I understand correctly, the next version will be:
>>>>>
>>>>> +    static const vpci_capability_t *const finit##_entry  \
>>>>> +        __used_section(".rodata.vpci") = &finit##_t
>>>>> +
>>>>>
>>>>> and
>>>>>
>>>>>  #define VPCI_ARRAY               \
>>>>>         . = ALIGN(POINTER_ALIGN); \
>>>>>         __start_vpci_array = .;   \
>>>>> -       *(SORT(.data.vpci.*))     \
>>>>> +       *(.rodata.vpci)           \
>>>>>         __end_vpci_array = .;
>>>>
>>>> Did you also move the instances of VPCI_ARRAY in the linker scripts so
>>>> it's before the catch-all *(.rodata.*)?
>>>>
>>>>>
>>>>> But, that encountered an warning when compiling.
>>>>> " {standard input}: Assembler messages:
>>>>> {standard input}:1160: Warning: setting incorrect section attributes for .rodata.vpci
>>>>> {standard input}: Assembler messages:
>>>>> {standard input}:3034: Warning: setting incorrect section attributes for .rodata.vpci
>>>>> {standard input}: Assembler messages:
>>>>> {standard input}:6686: Warning: setting incorrect section attributes for .rodata.vpci "
>>>>
>>>> What are the attributes for .rodata.vpci in the object files?  You can
>>>> get those using objdump or readelf, for example:
>>>>
>>>> $ objdump -h xen/drivers/vpci/msi.o
>>>> [...]
>>>>  17 .data.vpci.9  00000008  0000000000000000  0000000000000000  00000a50  2**3
>>>>                   CONTENTS, ALLOC, LOAD, RELOC, DATA
>>>>
>>>> It should be READONLY, otherwise you will get those messages.
>>>>
>>>>> And, during booting Xen, all value of __start_vpci_array is incorrect.
>>>>> Do I miss anything?
>>>>
>>>> I think that's likely because you haven't moved the instance of
>>>> VPCI_ARRAY in the linker script?
>>> Oh, right. Sorry, I forgot to move it.
>>> After changing this, it works now.
>>>
>>> diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
>>> index bf956b6c5fc0..c88fd62f4f0d 100644
>>> --- a/xen/arch/x86/xen.lds.S
>>> +++ b/xen/arch/x86/xen.lds.S
>>> @@ -134,6 +134,7 @@ SECTIONS
>>>         BUGFRAMES
>>>
>>>         *(.rodata)
>>> +       VPCI_ARRAY
>>>         *(.rodata.*)
>>>         *(.data.rel.ro)
>>>         *(.data.rel.ro.*)
>>> @@ -148,7 +149,6 @@ SECTIONS
>>>         *(.note.gnu.build-id)
>>>         __note_gnu_build_id_end = .;
>>>  #endif
>>> -       VPCI_ARRAY
>>>    } PHDR(text)
>>
>> FWIW, I would put it ahead of *(.rodata).  Remember to also modify the
>> linker script for all the other arches, not just x86.
> 
> Whether before *(.rodata.*) or before *(.rodata), there still is the warning " Warning: setting incorrect section attributes for .rodata.vpci "
> And the objdump shows "rodata.vpci" has no "readonly" word.

Did you check what gcc emits? It may be requesting "aw" instead of the
wanted "a" in the section attributes. Since there are relocations here,
".rodata." may not be the correct prefix to use; it may instead need to
be ".data.rel.ro.".

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 07:22:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 07:22:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010532.1388646 (Exim 4.92)
	(envelope-from )
	id 1uOtJ4-0005AB-Pi; Tue, 10 Jun 2025 07:22:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010532.1388646; Tue, 10 Jun 2025 07:22: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 1uOtJ4-0005A4-La; Tue, 10 Jun 2025 07:22:02 +0000
Received: by outflank-mailman (input) for mailman id 1010532;
 Tue, 10 Jun 2025 07:22: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 1uOtJ2-00059y-S7
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 07:22:00 +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 8f7e5653-45cb-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 09:21:44 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-4530921461aso17457035e9.0
 for ; Tue, 10 Jun 2025 00:21:50 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4526e055d2asm130494025e9.2.2025.06.10.00.21.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 00:21:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8f7e5653-45cb-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749540110; x=1750144910; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=dF4qeiSKDT2LrxQnWuh/h6J4KwRcj8Nih2XAVbl6g2A=;
        b=f3SOpypHVqeM0JHomDmbuwySSvbAL03bG53Jg8jG/Io4H/+2wrvgiFusc/8hWkZdxw
         jbwUuJXSQBwQK62of9X1BkxduDZblLolR5i22I8ovB98+z4AjkI3z4Rmcpb7ptCAxsGW
         3IDnzrsTZdKImE/hstCUHnacV8kMsMlZPwtC6xi7lCDENFIdPQcirHn1QHIByVhtchya
         w+Borb8/S9xqN76+a7qjcAs596KfJdp1RkOmvBajwzbLKnHHMCn8bw9fp2j2o3xWYnEU
         g1gSCtFSEWYnOChjFxSD/X97eVF09qFFKfYWTPfYc2/NIsxA+KFipYD+hf9kJN5ibpVq
         9WKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749540110; x=1750144910;
        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=dF4qeiSKDT2LrxQnWuh/h6J4KwRcj8Nih2XAVbl6g2A=;
        b=H4RBdd4Gyywz+isxPYKN+fDufAJaDR+UUVmLLEID6LwhtrjmVoqdc3NSXKdo1dnTy1
         qhaG0o59qrkq6V4cLrzVztmYp91yCstdrNygG/jilCVU+mBXZXHzeQtI+Fj0XDoVbxnU
         k2L1hAy+I6wbeLx7quPEGWPn8EpWoZ1D3lmWXTB8mZMb0jDiBzN4Cz6lu6k42r8CX6qd
         AzygD5ZK7q5TQIIQIep57CIIXSTrUnhg9MwTVCz1tXozXGDFVYrbRAkpKOdNYGaRQiTm
         Bh9HjJ3oxfvepNb6OQU71JOaUtsKmzZsECQuMveaWIfg8unO2UuW3g6LnN1yfKBS79AS
         YE9w==
X-Gm-Message-State: AOJu0Yyh6SKJYk0WwKbKbA/Hlz+TMIIxLnhDNGmpKn/pvBeNTeeDQfe5
	ONP/92PcxYg9vmNP6PaqEq386ntqAgCKNzkv/iy4TfKtUUfGgyA2CcY5UvK00D+Y4A==
X-Gm-Gg: ASbGnctzG49r1Pr8k1Q39fU61x+qcKULTtINUg5WPmqGU0c4QeydjOxQbal9MaozG6Z
	CpI5H7SAySwEF6w3nXcucW/3hWgCmfzq8Ftwe2bwgowUe5KSr5UaDkWkwaWz/HxvJxgyjBzR91h
	K/9HGctxebxp3olsZ3Cf3YNCdLvY6HHMft5XKCtgNv3ERJjXpII5Xlvzz+b7pdadXYlLVVx3fNt
	7RrsX23FzI+C0SPGSN/r5W4RVlIMxK0Vz6lgQj0l05t+Mh7jPvQ62c8f4WVlW3Ot+z3VCnL4mld
	eGEJCiBoESZdTMOPKfxlOpB6RtwAaKPkHymMkKNXuReUnPUVEdOJhhjav4v5y6r8FpTfmrwcjD9
	VtolJ4DSdvYQAuNJca7e1SgmF4SDDAnm/lN/YOyCseypqe4rvGGRwPziVE1Qyvt0Sf7pT1miFua
	H/c8RnONY9GJ7Rs3OAPww6
X-Google-Smtp-Source: AGHT+IHaWCC74IuCPGl8z1fMX9Vgvt8ppW13eeYx9ACp+uzz8Y23A9CkLjZgRqAVOeiJFcoTQn4JIg==
X-Received: by 2002:a05:6000:2305:b0:3a4:f722:f00b with SMTP id ffacd0b85a97d-3a53188a524mr12984625f8f.11.1749540109747;
        Tue, 10 Jun 2025 00:21:49 -0700 (PDT)
Message-ID: 
Date: Tue, 10 Jun 2025 09:21:49 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1] xen/console: group pbuf under console field
To: dmkhn@proton.me, Teddy Astie 
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com,
 anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com,
 roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
References: <20250606194937.2412579-1-dmukhin@ford.com>
 <00ffcc4b-b63e-4b4d-8b8f-8d02fb7ef234@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: 8bit

On 07.06.2025 01:06, dmkhn@proton.me wrote:
> On Fri, Jun 06, 2025 at 08:24:44PM +0000, Teddy Astie wrote:
>> Le 06/06/2025 à 21:51, dmkhn@proton.me a écrit :
>>> --- a/xen/drivers/char/console.c
>>> +++ b/xen/drivers/char/console.c
>>> @@ -769,22 +769,25 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer,
>>>               } while ( --kcount > 0 );
>>>
>>>               *kout = '\0';
>>> -            spin_lock(&cd->pbuf_lock);
>>> +            spin_lock(&cd->console.pbuf_lock);
>>>               kcount = kin - kbuf;
>>>               if ( c != '\n' &&
>>> -                 (cd->pbuf_idx + (kout - kbuf) < (DOMAIN_PBUF_SIZE - 1)) )
>>> +                 cd->console.pbuf_idx + kout - kbuf < DOMAIN_PBUF_SIZE - 1 )
>>
>> I don't think we want to drop the parentheses here.

I don't see any issue with doing so - they don't serve much of a purpose here.

> The line will will exceed 80 chars if I keep parentheses.
> 
> Will something like the following work:
> 
> -                 (cd->pbuf_idx + (kout - kbuf) < (DOMAIN_PBUF_SIZE - 1)) )
> +                 (cd->console.pbuf_idx + (kout - kbuf) <
> +                    (DOMAIN_PBUF_SIZE - 1)) )
> 
> ?

Well, indentation of the latter of the two new lines is two too deep, as it
looks.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 07:28:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 07:28:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010538.1388655 (Exim 4.92)
	(envelope-from )
	id 1uOtP4-0005jf-Cp; Tue, 10 Jun 2025 07:28:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010538.1388655; Tue, 10 Jun 2025 07:28: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 1uOtP4-0005jY-9r; Tue, 10 Jun 2025 07:28:14 +0000
Received: by outflank-mailman (input) for mailman id 1010538;
 Tue, 10 Jun 2025 07:28: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 1uOtP2-0005jS-P6
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 07:28:12 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20600.outbound.protection.outlook.com
 [2a01:111:f403:200a::600])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 701e8ded-45cc-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 09:28:00 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by SA1PR12MB6701.namprd12.prod.outlook.com (2603:10b6:806:251::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Tue, 10 Jun
 2025 07:28:03 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8792.034; Tue, 10 Jun 2025
 07:28: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: 701e8ded-45cc-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ij/IJF7TkwFiNyKs0HuMR7sXl24bZwF0VCp/MZUK6KRA7iGSnLjSF/JEwSr3i1vW6JWvONTdfYWP3DnWPA+YatHo4YxoYrwWQ+l2mZDTnUoEUmcV7fupE7/bZ6xLXcuQfjQ9SzOj1nhZvQ6FAnB1fzQLSLqqMJIpyMzaYVF6LNcwc8T9+RgTgkD+k+ZZdaox+TjL4bHuo88eTsNhP2emMMDxoBpuog15rWKBfA5RGerm6/9dP2v/C6GKD1B1qNx6vHRERWhi+MxPnn8fRjCOhLBm7i4E0wZB4rHzQ7Qy9BwSKUs376GXbWPhpjyjUv+PUs02V6f0VZFlRWUFirf3PA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=RiAcE5GUvJDbX7VFRd5mc1mfxZgRcsDqd416ZPMpgJQ=;
 b=eMo+T9ZUtFFZvUHgcQxjd3mTAQS3csGSaeiz7+8d9jGGFyqhqu1DM1RKB9i97yX89Tenm6qCQ5h8GJQz0YW30ehce3F81CVSC7XRIMVc0vh4R1zeYl4JtmY5JFNYGEir4S/bx7NNTtnSgwnciQOX4J2y59EiKsLpTPnq1tUavg0zl02fJa/JtnvlV+1Vqsv/iDqbDwHULqPZCwBOj1+mO8rLtd0I8EC+vQoSp0Wn07Q17srNQIti8F/VsLJnj76vipugWTgO/nvyMBc/8YAHWeD/33zkpBXlfwb23ax+yc249H5J+Si+7GyEAWQ0C2ZJuOa2Csxqw3I31f9+lY0etA==
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=RiAcE5GUvJDbX7VFRd5mc1mfxZgRcsDqd416ZPMpgJQ=;
 b=LXNMZmsp9rNIYoT/UMyiG/n+KP08txUJ+XbIM8oJyF9glEZUokvEF9DG4G2QaGUUjuDWXol41yGtuAkNtzhPp5WeKXVpdGZRZHYjpOcOdzrkS1Qo5KXpa4HEmro3vccV5YS811TniT4sUUGMAqKqBSj6YtIKgJY1Ua9Gv/odrHM=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <6a52ad54-cac8-43fc-b396-87b0ac01d1dc@amd.com>
Date: Tue, 10 Jun 2025 09:27:59 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 1/2] xen/arm: exclude xen,reg from direct-map domU
 extended regions
To: Stewart Hildebrand ,
 xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250609183438.178214-1-stewart.hildebrand@amd.com>
 <20250609183438.178214-2-stewart.hildebrand@amd.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250609183438.178214-2-stewart.hildebrand@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR5P281CA0046.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:f0::9) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|SA1PR12MB6701:EE_
X-MS-Office365-Filtering-Correlation-Id: d80cefae-5bc8-43cf-0892-08dda7f05586
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?TnpyQzdOeXdmSDVVQ3o4WEdLY09hNEs4MjdjZGppOHZWUGRNc3lIMUZ1NHFo?=
 =?utf-8?B?bndOTjNuTFFsVU9aTEtMUlVTaExTM21UUmhLbmxkZGphdlpGb2ovaWhMMlE5?=
 =?utf-8?B?RnhRaG9WaSs1TVdLQ3IxWUpwV25QbHlMdHpPUTF0ZGQ1ZzU3bXR3ZXhPYWQx?=
 =?utf-8?B?UzJiMnpBUzhFUWg0UHdOVmRXNGE1ZFRHbi9lSVk0WUdMNkZBMHNtQkFNRUZo?=
 =?utf-8?B?eDdXQTJCSzFHNTk0Tk1BR2dza3Yxem1USXJreEJrRzFqQWlGSFM3QkhkY2lD?=
 =?utf-8?B?dlMwZ0xuMk1uZlFRZk9YUGxKd2ZjMGtqN2UxMlQ5M3NwUVdnaWRpOERmNExJ?=
 =?utf-8?B?U1RuUkVtSVlVZC9uNm9xOWdCKzNCaTB4UFZYY3drMXRraVJLRkVZQjc2bGJB?=
 =?utf-8?B?Y0RzK3RqcG56YjhyYmF5aW9kNGNVeGdOMDhnS3dKTXQ1bWhIb0lIbnBrQnI3?=
 =?utf-8?B?MjF3YTB6N2JnOGkydkxRQ21lWFlDWXlhSkhrbXEvU0xLeDc4a3Vyd2ZIZ1Jq?=
 =?utf-8?B?bjB2Sm5JbDFVT1RNbURTOXFLRG85cHpjU0pERk5tS1FFeU1IZEJNd1puZi9r?=
 =?utf-8?B?bUlnTUI5bE1vNE5KQllGVzlpS0Q1L1l6bTdZdzhNaDE5cWM0bEtqanVSQncw?=
 =?utf-8?B?MkpYOHEzRXA5UlNSdjErVUgvUnA4SEJxSUp0cUM1eFdNejY4bEFJci8rbUIv?=
 =?utf-8?B?Mjl3K1lycHEzY3Jmcnk1eFJZYUh4Q0F6QmpBekt5Wm1YL3ROOWhZZU92ZmlF?=
 =?utf-8?B?L3hRdVRSNlZKYVEvcDJ0MUd0TkRNck5pQ0x1azcwNjVjUWJqcXhCaWpIcGNS?=
 =?utf-8?B?cjJYRWhuQkFFR3Aya2xCYnhUWStTN3NpYmZhRmZWNVlGS3VQNy9PVXFnbGlX?=
 =?utf-8?B?ZUZGS1hPalJlSkdxWmxac2xVVUx2UEhoTmFmaWpEYUdpR1ZXUTcyZWdmZkJu?=
 =?utf-8?B?cDUybjBxaTRoZmx3VXRqRm9VaUVOSWZZTUNuWWIwd2RpcmNXYXVKWEdKMWRn?=
 =?utf-8?B?VWdVSUJwWTk0R09zbEtjZ2FrdDJpNXFOMzIzZndCVUVVdVlJeFJrSm1kaEo5?=
 =?utf-8?B?TTU2YjNzV3d4Q3pJYXRvUWlNeG83WHRyaGVJVkcvb2REaHpOalhES2lhZVZY?=
 =?utf-8?B?QURQL0pLRk9mVjlMeDVYTzNJbHYrckxpTlBER3A0QTZTOVJ3Yms4TkpIT2k2?=
 =?utf-8?B?TWRTNXRnVFRXbEFYS2NJUGVDVWpyR1l5bVp6SStEMURmRTFmMjJkVXVMTTFF?=
 =?utf-8?B?TFoxalJaR2dIYm9jWUZUZEhxZVpWVVV0aGxnUGRJOUkxYUs3UTNvMnVXYURP?=
 =?utf-8?B?YzZsUXVHcFJ3WVJyK3AzZVZ6Y2w0b1NRSjR5azZYc1VwbjNqVEpiaUNkWHg1?=
 =?utf-8?B?ZW0zY1pER09OZlBMUWFhSk00SFJGTjkyakRBVUFVTjBGa2NHdTJjb2QyR1By?=
 =?utf-8?B?R3BCdFlhdkFFQVh3NjdMUllDWVF2WUxLZGNLSHQ3Ri9Obmw0KzcyaXk2eTl4?=
 =?utf-8?B?OVE1Z0xMT3NONkkzZVJ2K1QrVGkrWkRaQkVLNmhsZlAvY215Yzc4UG12V3Nj?=
 =?utf-8?B?cEl0SFV2emNGcFNsUEVyQlhxbHRRUmtyZnpaQ0dnWDhoZFlIZE5Ec21vZmEw?=
 =?utf-8?B?T1lIc0pDZWJ6VjROcTZ2TjJLNDZQQWN1NU1MNHhPQnpaQkhHV01NWDErVXdL?=
 =?utf-8?B?Tkh5cUZ5Vy9aWGZveUV1S0RUVmxVd2hUclBqYS9VWXJXR1VDZzB1Y3lWL2tV?=
 =?utf-8?B?dUk0Z28xb3hYbmgyR3RoQitzZFd0QWx2b1lOZEpsaHZDOEJnMVVUMTV2VHAv?=
 =?utf-8?B?eE95RmsyZ0JTSHdOSjkxVjNPUXZQRlBzODRaVHo5RG4vZUNDU2g1UldaWktI?=
 =?utf-8?B?WS91cENJZ0E5d3lHMFJBTEdxM3Y1OVhBMGU5eis5cjcyVjQrS0pyM0E5WTNs?=
 =?utf-8?Q?G2FhNSwbsXo=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.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?d3E2bTlWSmJzU0hvYXNrMUtFNmpDM08vM05WNEt1bGw1bHBuTE9jakZIZHp6?=
 =?utf-8?B?Z3h6Z09nMnYzUWpnbDFWeGpzN1p4cmEzSFB4UGd6NEtZeFh2KzRTSzVvOGdY?=
 =?utf-8?B?QmE0Q2pXZ3g3ZStlRUQxYXZ2MmN4RGpVRlptdHdtb3dnSWQ0VjB3UlFsNzhK?=
 =?utf-8?B?bHBLZ3J1Vk9mL21kZXBlSE9vT2JXd3NrV1V3ZVRsZ2JFc2dZRWIwZVhCYkph?=
 =?utf-8?B?dytYcFZnZEg3Z2RzQWFROERvQlAycVRJV09RRnUwQmxYTnk4bE1MTjgxaEJB?=
 =?utf-8?B?ck4zRU15Tm1jeTZ4ckdIMFpQKzREMnFjdnNjVHFhZGxoTjYrbEdoeEJVSTNC?=
 =?utf-8?B?UnM1NTMxVU51YjY1c3lHam5pTnR0RVFGNlBGS2w1YUJWOUJIb1RoSjFNaUtu?=
 =?utf-8?B?M2VUMjZUWFg3aW5WZENtdmxldVlIMGlyRzRKWVFSQU9CUlBES25DdEt3ZlRC?=
 =?utf-8?B?OHl0QW5EcTY3eDA2eEsrR1oyYUtBQmxLUjEwQy93YkN4a0xlS2FNOEZtZ29n?=
 =?utf-8?B?eFozeGxBRUNVQTgzSndZdGRQM3pKczVBdHpLZmRIV1ZXSlFTTG9lVnl2eWxL?=
 =?utf-8?B?dUZ6NG04cUFaZEFLNTRTTUZaR3dMang1dDQ4MGlxaWFiWmZpNjNBeU5MbWp2?=
 =?utf-8?B?WW5TQ3FWbkFidWdDM0ExTmE2TnhPbUEyUWNiZytoU3ptN1pyOUwwMW1sVTNh?=
 =?utf-8?B?RXVzc1V0VHdyK3N3RlhIUjR0NmU0TTZCR1ducHNGbnlNQWJrRE9DR01MU0Jt?=
 =?utf-8?B?QkJNdXpLdG5aOUwvcDAwQXZpdUM1S2xjVlRWVHRuRjA3ZVQvcnFNajJrbkVx?=
 =?utf-8?B?em1UUVlEay9SY0dESHQzaW8yMHVXMlNEbTl2S0pGc3drdUdWSUhEWi84MHlq?=
 =?utf-8?B?NnZuNTVNdHJKZDVlamk3Rk5DeDlDU29GWkk5T1JaQjl4LzBnZE9ub0hjMzRB?=
 =?utf-8?B?UDdQR09XUjVWbjFSb3dCeHBYZ2Vvb25SRHdXdGNTZDVwY3A4Qzl0QXBTNUt4?=
 =?utf-8?B?YkFyNjAzZml5UllseFVTOCtnT1ZNWlpVZWFzWlVNM3JhM2JxeTBKczZ6akpH?=
 =?utf-8?B?VEVSOHB3c21KUXZZdFFhYjUvcTlUdGNZd0VqUUxFYVZIZFloNERsTkthR2JQ?=
 =?utf-8?B?RnRLemNNSzZaOUtHYXdQcVpyc2pUOGlzdDZUU2ZKdks1aUJUUGd6TDA5MjVh?=
 =?utf-8?B?RUdjRnNITzY0Zy9Wb2tWdnNKL2VkanUzRHBsZXpBblpzbzhRRi9ndG1WRXhT?=
 =?utf-8?B?ekZ4QkQ2bldQNlFyU1J6VW9HSlcxQ0V3MDdMN0wyUkgrb1J0WkNkSS9PY20y?=
 =?utf-8?B?ak10QnAvSmRYeEl4U052K3Z6b0pOemJlc2xyd0cxLzJldVAzZXBBK2U1dFk5?=
 =?utf-8?B?VUtUZk5oanNJZ3Zna282OFplZ2FGblA4ZFcvRmIybUVQZVFtQ2hTb2FhWXhi?=
 =?utf-8?B?bVJSanFJTjU1eGQvbjJyby9ETXFkZmJ4TXFNbk9DVlV1cnBVckNyVkZFRDg5?=
 =?utf-8?B?M1NmWWwxR1dzeGNabFRQdHdGbUxKZTNIT3BTbi9UWVA3aHc1SHM5YlhZNmFi?=
 =?utf-8?B?Uk1VLzBzcC8rMm5jQnZqMi9pcFVJQWhnbmw5YXhOWlB3WnNJUlRMdHAzVGNx?=
 =?utf-8?B?a3E1MlpId2pTeWJqclUrODVKcGpxSUNQRHlmN2J3azFSRURpZi94RnNVcVYy?=
 =?utf-8?B?QjNlYnUvR3NrbTYvbHNyVjdIVlROYVNLbWRib0FkMUFWTXU4bVV4VXdIMHBJ?=
 =?utf-8?B?NlpJVXlKRE1LTDRDRE5MZ2M0OUM5Wk1kelBjQ1ZORkZreFVFRFFaMmEvUlhK?=
 =?utf-8?B?bENwM3FwczArbEtoazU1V1VIRlNKTUVxWUlPTW52cTExTFRBQUVaSG1FN25K?=
 =?utf-8?B?TEJVNmN4L1o4K1ZlTGdXTXhCVHdBdENCcHlSZDFoVTRVa1MvaEs3Z1Z1TFdZ?=
 =?utf-8?B?czFaWmhvbGtTcERpbnZrbVR5Uy9veWVNSUV0ODMxTHRITkl5ZGppaVR3NGtO?=
 =?utf-8?B?dStxTzg0T3pwdVFVQlNHaTZVS0ZOcEdNNlU3NHVtRk1oY0tySlVHc0xxVkZM?=
 =?utf-8?B?TGFxK3ZkQVBZcDhtNjdUYytKdklIYWF1eXJNQnNGckp5VVFZMmIzR2tCQllE?=
 =?utf-8?Q?uqrY=3D?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d80cefae-5bc8-43cf-0892-08dda7f05586
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jun 2025 07:28:02.7229
 (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: gvQSryrq3TgMSfd9kxOFtAdq8o4a75+BDBa80Bl6IfZxePfrqMA56zRUQkb9fDqp
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB6701



On 09/06/2025 20:34, Stewart Hildebrand wrote:
> Similarly to fba1b0974dd8, when a device is passed through to a
> direct-map dom0less domU, the xen,reg ranges may overlap with the
> extended regions. Remove xen,reg from direct-map domU extended regions.
> 
> Take the opportunity to update the comment ahead of find_memory_holes().
> 
> Signed-off-by: Stewart Hildebrand 
> ---
> v3->v4:
> * conditionally allocate xen_reg
> * use rangeset_report_ranges()
> * make find_unallocated_memory() cope with NULL entry
> 
> v2->v3:
> * new patch
> ---
>  xen/arch/arm/domain_build.c           | 77 +++++++++++++++++++++++++--
>  xen/common/device-tree/domain-build.c |  5 ++
>  2 files changed, 77 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 590f38e52053..6632191cf602 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -792,15 +792,17 @@ static int __init handle_pci_range(const struct dt_device_node *dev,
>  }
>  
>  /*
> - * Find the holes in the Host DT which can be exposed to Dom0 as extended
> - * regions for the special memory mappings. In order to calculate regions
> - * we exclude every addressable memory region described by "reg" and "ranges"
> - * properties from the maximum possible addressable physical memory range:
> + * Find the holes in the Host DT which can be exposed to Dom0 or a direct-map
> + * domU as extended regions for the special memory mappings. In order to
> + * calculate regions we exclude every addressable memory region described by
> + * "reg" and "ranges" properties from the maximum possible addressable physical
> + * memory range:
>   * - MMIO
>   * - Host RAM
>   * - PCI aperture
>   * - Static shared memory regions, which are described by special property
>   *   "xen,shared-mem"
> + * - xen,reg mappings
>   */
>  static int __init find_memory_holes(const struct kernel_info *kinfo,
>                                      struct membanks *ext_regions)
> @@ -882,6 +884,13 @@ static int __init find_memory_holes(const struct kernel_info *kinfo,
>          }
>      }
>  
> +    if ( kinfo->xen_reg_assigned )
> +    {
> +        res = rangeset_subtract(mem_holes, kinfo->xen_reg_assigned);
> +        if ( res )
> +            goto out;
> +    }
> +
>      start = 0;
>      end = (1ULL << p2m_ipa_bits) - 1;
>      res = rangeset_report_ranges(mem_holes, PFN_DOWN(start), PFN_DOWN(end),
> @@ -962,11 +971,48 @@ static int __init find_domU_holes(const struct kernel_info *kinfo,
>      return res;
>  }
>  
> +static int __init count(unsigned long s, unsigned long e, void *data)
> +{
> +    unsigned int *cnt = data;
> +
> +    (*cnt)++;
> +
> +    return 0;
> +}
> +
> +static int __init rangeset_to_membank(unsigned long s_gfn, unsigned long e_gfn,
> +                                      void *data)
> +{
> +    struct membanks *membank = data;
> +    paddr_t s = pfn_to_paddr(s_gfn);
> +    paddr_t e = pfn_to_paddr(e_gfn + 1) - 1;
Why do you subtract 1 here if ...

> +
> +    if ( membank->nr_banks >= membank->max_banks )
> +        return 0;
> +
> +    membank->bank[membank->nr_banks].start = s;
> +    membank->bank[membank->nr_banks].size = e - s + 1;
you add it again here.

> +    membank->nr_banks++;
> +
> +    return 0;
> +}
> +
>  static int __init find_host_extended_regions(const struct kernel_info *kinfo,
>                                               struct membanks *ext_regions)
>  {
>      int res;
>      struct membanks *gnttab = membanks_xzalloc(1, MEMORY);
> +    struct membanks *xen_reg =
> +        kinfo->xen_reg_assigned
> +        ? ({
> +            unsigned int xen_reg_cnt = 0;
> +
> +            rangeset_report_ranges(kinfo->xen_reg_assigned, 0,
> +                                   PFN_DOWN((1ULL << p2m_ipa_bits) - 1), count,
> +                                   &xen_reg_cnt);
This does not look really nice with ({. Why can't we create a helper function to
report the count for xen_reg_assigned and call it here? You could then also open
code your 'count' function that is not used by anything else and is quite ambiguous.

~Michal

> +            membanks_xzalloc(xen_reg_cnt, MEMORY);
> +          })
> +        : NULL;
>  
>      /*
>       * Exclude the following regions:
> @@ -974,6 +1020,7 @@ static int __init find_host_extended_regions(const struct kernel_info *kinfo,
>       * 2) Remove reserved memory
>       * 3) Grant table assigned to domain
>       * 4) Remove static shared memory (when the feature is enabled)
> +     * 5) Remove xen,reg
>       */
>      const struct membanks *mem_banks[] = {
>          kernel_info_get_mem_const(kinfo),
> @@ -982,12 +1029,29 @@ static int __init find_host_extended_regions(const struct kernel_info *kinfo,
>  #ifdef CONFIG_STATIC_SHM
>          bootinfo_get_shmem(),
>  #endif
> +        xen_reg,
>      };
>  
>      dt_dprintk("Find unallocated memory for extended regions\n");
>  
>      if ( !gnttab )
> -        return -ENOMEM;
> +    {
> +        res = -ENOMEM;
> +        goto out;
> +    }
> +
> +    if ( kinfo->xen_reg_assigned )
> +    {
> +        if ( !xen_reg )
> +        {
> +            res = -ENOMEM;
> +            goto out;
> +        }
> +
> +        rangeset_report_ranges(kinfo->xen_reg_assigned, 0,
> +                               PFN_DOWN((1ULL << p2m_ipa_bits) - 1),
> +                               rangeset_to_membank, xen_reg);
> +    }
>  
>      gnttab->nr_banks = 1;
>      gnttab->bank[0].start = kinfo->gnttab_start;
> @@ -995,6 +1059,9 @@ static int __init find_host_extended_regions(const struct kernel_info *kinfo,
>  
>      res = find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_banks),
>                                    ext_regions, add_ext_regions);
> +
> + out:
> +    xfree(xen_reg);
>      xfree(gnttab);
>  
>      return res;
> diff --git a/xen/common/device-tree/domain-build.c b/xen/common/device-tree/domain-build.c
> index 6b8b8d7cacb6..99ea81198a76 100644
> --- a/xen/common/device-tree/domain-build.c
> +++ b/xen/common/device-tree/domain-build.c
> @@ -193,6 +193,10 @@ int __init find_unallocated_memory(const struct kernel_info *kinfo,
>  
>      /* Remove all regions listed in mem_banks */
>      for ( i = 0; i < nr_mem_banks; i++ )
> +    {
> +        if ( !mem_banks[i] )
> +            continue;
> +
>          for ( j = 0; j < mem_banks[i]->nr_banks; j++ )
>          {
>              start = mem_banks[i]->bank[j].start;
> @@ -212,6 +216,7 @@ int __init find_unallocated_memory(const struct kernel_info *kinfo,
>                  goto out;
>              }
>          }
> +    }
>  
>      start = 0;
>      end = (1ULL << p2m_ipa_bits) - 1;



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 07:40:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 07:40:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010544.1388664 (Exim 4.92)
	(envelope-from )
	id 1uOtb8-0008Uo-Dy; Tue, 10 Jun 2025 07:40:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010544.1388664; Tue, 10 Jun 2025 07:40:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uOtb8-0008Uh-BN; Tue, 10 Jun 2025 07:40:42 +0000
Received: by outflank-mailman (input) for mailman id 1010544;
 Tue, 10 Jun 2025 07:40: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 1uOtb7-0008TI-F5
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 07:40: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 303c4407-45ce-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 09:40:32 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3a3798794d3so4356603f8f.1
 for ; Tue, 10 Jun 2025 00:40:39 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a5324360a3sm11643349f8f.50.2025.06.10.00.40.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 00:40:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 303c4407-45ce-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749541238; x=1750146038; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=WGPmr254+fUvyiqnH6r2Z3+S7aNGdpLaH0Vp/MfxfO8=;
        b=Vl6UAVQq1n9+7YmJvZKIDxsDlEEZ24vKTa2KPpD9KA4EmFAqkSIRAc4gYz/KuBcs9x
         MQpuK78GcAYTXQvkDPYtggf9eHgS1jZrylh3pP8AJpXcQjSTbFj7fjV27sUNIoBfIJGH
         joY5KWWG+iK3vt7rTLOnPr0mWy65MB8rB+zZic8gNubyaUzMXWaPXmP68hBF1VhOJIKU
         2v8sKGzOBrlMbdp6LsU6kZfIEFcCyin3vYvEm7HQDX89I3BDiH9o9tg3qYc3uLw69I2L
         n7LjQf9N/ONcHfCD1dj/xTDvVqIpSjqMDX1PwVWkF++CKFKJpZiTb/R5K0BRPQJlk2VG
         v+5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749541238; x=1750146038;
        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=WGPmr254+fUvyiqnH6r2Z3+S7aNGdpLaH0Vp/MfxfO8=;
        b=g9OkWLdBFHwKjDNjaWATvUjY0ZeOzQqpKErXYEW2EPDN6M5JzL0ug58G+ZNlmo22Rx
         bWPtwT7dKX9e/2oj121c2ImzpDGExwvX2sS/9ku6gluZpGz54xM4PeXaKtflXEqm6h8u
         vd32YN07ubYpWEqYKgksjW7bTvQgFwI8vG43ufDnT6+TipETCvjkHVvrI7heFcyUE4ol
         7TgOtx1J/QaViAkIKb1GiwK7r1WDAJ0V8LnpYwbddd8R0H8AvZuF0AT+RjI7n8lfAFES
         Ohgwg3BAjjlK9eGqLjzcY3mjl/gxfM+tA9YjM1gyjHcn3jM1ieCDZbXC4mDL0ftwCNVr
         Knag==
X-Gm-Message-State: AOJu0YxqWLLjOvuTEEhY8Gt48QBzJixWGMmidU9hGEbPdgpis8gFsL/N
	d8V/kDYyy1O1+XGQChaX2crYCJatej+PRkGbw//RuwKckPRg3388apWzREFGQzp++Q==
X-Gm-Gg: ASbGncvZ72JpYn5SxlLlPFwVOST/z3N2BfGlSao/60tA+znja0rIx8ulF+hBAfUtKse
	wBoCrhLXH16qPbXjEuZZe7/q5RYZK28yMbJjWQhyIoGN7JD8Wiu7m1pAdrYE9pjJtNU4uIsKerv
	HmJruzWiStp7V+QAFG3X+MNXKlBEBe+20cdkiAYZ06/5cETfx9ufDKNlS8JmWE+3wDqYLQH7p5T
	E9AW3BPm2OEDCOAAwNyUejbj2ASw0BMi9rdB0QNf89KpoNZd44H3D37cYu9egaEsoYQrycOR87w
	w6Nv+TnMjyRUCegSTV5WlymMmwjMErdwZ/gYAJJ/phbbFoSM5AgSTLa/YgEmeCaWVkyIuA5QMbr
	Q7HucM4CdDbQ1bYU6eCmiZqQ36RoxOKKxD8nm85nDMavh3H8CE2jiWEipCuqwa6FZkiYzmIB+Ow
	rqiUDzfaFfHaAjAjvMNxp1OMdszqam5jo=
X-Google-Smtp-Source: AGHT+IH504FJdMWI939rh5fNfypQ3fKkpJw/a1y+bMxOAhBucalXorOPQ/jTWmkRcKxfLMsxAyYOhQ==
X-Received: by 2002:a05:6000:178f:b0:3a5:2694:d75f with SMTP id ffacd0b85a97d-3a531ce73bbmr12799646f8f.52.1749541238525;
        Tue, 10 Jun 2025 00:40:38 -0700 (PDT)
Message-ID: <6e9e84eb-f98b-4c06-8952-03aecc82c0ea@suse.com>
Date: Tue, 10 Jun 2025 09:40:38 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] x86/HVM: restrict use of pinned cache attributes as
 well as associated flushing
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper 
References: <78b3ddeb-4317-4d54-ad52-9eb03bdf7942@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.06.2025 12:36, Roger Pau Monné wrote:
> On Wed, Jun 04, 2025 at 11:48:00AM +0200, Jan Beulich wrote:
>> @@ -605,31 +606,35 @@ int hvm_set_mem_pinned_cacheattr(struct
>>  
>>                  type = range->type;
>>                  call_rcu(&range->rcu, free_pinned_cacheattr_entry);
>> -                p2m_memory_type_changed(d);
>>                  switch ( type )
>>                  {
>> -                case X86_MT_UCM:
>> +                case X86_MT_WB:
>> +                case X86_MT_WP:
>> +                case X86_MT_WT:
>>                      /*
>> -                     * For EPT we can also avoid the flush in this case;
>> -                     * see epte_get_entry_emt().
>> +                     * Flush since we don't know what the cachability is going
>> +                     * to be.
>>                       */
>> -                    if ( hap_enabled(d) && cpu_has_vmx )
>> -                case X86_MT_UC:
>> -                        break;
>> -                    /* fall through */
>> -                default:
>> -                    flush_all(FLUSH_CACHE);
>> +                    if ( is_iommu_enabled(d) || cache_flush_permitted(d) )
>> +                        flush = true;
> 
> Is the check here required?  memory_type_changed() will already check
> for is_iommu_enabled() and cache_flush_permitted(), and hence you
> could just set flush to true unconditionally here IMO.

The behavioral difference is when both predicates are false: The way I have
it now, p2m_memory_type_changed() will then still be called (conditionally),
better matching prior behavior.

>>                      break;
>>                  }
>> -                return 0;
>> +                rc = 0;
>> +                goto finish;
>>              }
>>          domain_unlock(d);
>>          return -ENOENT;
>>  
>>      case X86_MT_UCM:
>>      case X86_MT_UC:
>> -    case X86_MT_WB:
>>      case X86_MT_WC:
>> +        /* Flush since we don't know what the cachability was. */
>> +        if ( !is_iommu_enabled(d) && !cache_flush_permitted(d) )
>> +            return -EPERM;
>> +        flush = true;
>> +        break;
>> +
>> +    case X86_MT_WB:
>>      case X86_MT_WP:
>>      case X86_MT_WT:
>>          break;
>> @@ -682,9 +687,11 @@ int hvm_set_mem_pinned_cacheattr(struct
>>  
>>      xfree(newr);
>>  
>> -    p2m_memory_type_changed(d);
>> -    if ( type != X86_MT_WB )
>> -        flush_all(FLUSH_CACHE);
>> + finish:
>> +    if ( flush )
>> +        memory_type_changed(d);
>> +    else if ( d->vcpu && d->vcpu[0] )
>> +        p2m_memory_type_changed(d);
> 
> FWIW, I would just call memory_type_changed() unconditionally
> regardless of the change.

In which case the need for the "flush" local var would go away, if I
understand your suggestion correctly. Like above, there'll then be
more of a behavioral change than intended. In particular ...

>  We suspect the hypercall is only used at
> domain creation time (where memory_type_changed() won't do a cache
> flush anyway).

... "suspect" is not enough for my taste. The only alternative there
that I see (as mentioned in a post-commit-message remark) is to
refuse such "late" changes altogether. Yet for that we need to be
sure, which it looks like no-one of us is.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 07:52:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 07:52:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010554.1388674 (Exim 4.92)
	(envelope-from )
	id 1uOtmJ-0001t1-HS; Tue, 10 Jun 2025 07:52:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010554.1388674; Tue, 10 Jun 2025 07:52:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uOtmJ-0001su-Et; Tue, 10 Jun 2025 07:52:15 +0000
Received: by outflank-mailman (input) for mailman id 1010554;
 Tue, 10 Jun 2025 07:52: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 1uOtmH-0001so-LO
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 07:52:13 +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 cc30dc15-45cf-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 09:52:03 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-450cb2ddd46so30888125e9.2
 for ; Tue, 10 Jun 2025 00:52:10 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4526e155ce7sm130848755e9.10.2025.06.10.00.52.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 00:52:09 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cc30dc15-45cf-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749541929; x=1750146729; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=KY/jOI8qYpQJ+ZeafdeIyn8phetCCWvIhpbSGUsnip8=;
        b=KRDnMRshFHVIkuO9zVbeCHT/UrLfKxDe8Yb+YgUcdANdNGa/+VtLMWFjdVvqLRzI7w
         g8lJAQFXNbrwceIAoTW5J4Yeo3WzkzlP/7E3eLVwbgvA55NLwr4+hs0lUJN2Yfh2n4Tm
         +iSyOvDrioxKwCQRCYiz1qwPY2JH1EiV/YjH6SZjFGG5RLJVGLb3JjXJpTKTiHsmb926
         +FSQG+uiCaH9ypSO9dmwBEVIdzV6UYNrRQEUVyqwmmdr2k/twcxwAMbdUyqcW/AnQghU
         zNF/Tt9pl3k8A0BJxfmZc91jR1KvOdH/g8lFt3B+XW6pnWx/EtccKd4DQMjQztqlLx2k
         PbKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749541929; x=1750146729;
        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=KY/jOI8qYpQJ+ZeafdeIyn8phetCCWvIhpbSGUsnip8=;
        b=sAukoR184K3TbcPaacSQV1xgn/JAc+F5gTZphiqd74NiphpsaQBhw1mktqzdBDvB+5
         gUI17rlXZCzqGz+ZUgqI/61cLztc5HutPwLmVjWb6PHXuntAoF9AooXVuVCgmeSTpTlM
         cWE10RzoR7zIE7cZkLxVzu5BoyFlX5+DzLcuv/2pA9fz0ipyF+eTZbSbS/94y+oRPFiG
         b3NuaNc5cqF2/UiyXo5guJiQAltPnehH92lj0lt1scF0WfU3/QM4QCn2bq3LmVmAhmgg
         ebwmqzmvKlyznU44HcBNKY4ACMon7xoyjpP5tvKDxJaYKktaTmjf28yVOwpt4EfCa2bS
         gsDw==
X-Gm-Message-State: AOJu0YwAZPplqSUD8zmYPLaaSwMj9Tc2EIrQP69jdb8rnTNUjkLsJ/yl
	4nXIWG9Y+8mxacgiPRfpzd1npSopR9KHwZ3YrWhKlyZ+quz+NGTxnH8LU32FOdL9sA==
X-Gm-Gg: ASbGncsP3pPYB8L9PZEv8N4frj8+8k6ZSraJIXoFOIgoRrblaUajGI7Eb34tFzBPnoF
	a54rzUm+5Mn5Tc5Xp6juYYZzUSE8AtED+1dZkJO0w92M5Wt0Cz0SuVCGl21SYZtTWiyKoUuy/r8
	5JtahmBcwhG0JhxVmuTMWaYoiRiVXdPLrT7napbAQYcwoo3taIG+NeT2j4izOaMgcYb8h0QuRFM
	IMYF+NYWTfQM5yVtmHUkoOEzhMN2fwml7ltJ0zabqt88w9kLxHRbIx3LBRaxq89cn8uMR/DNfVr
	lpm92rEKQ+3ARKqeSX4SaNBq7ufnO/FrTz2T8uSMB0eHS34gI057KQ6V2azhGF2CpVMjm0aQlHw
	nMhXK/a12iHp7FOTfGmhjSzkX3sGNwy7UIXqD1un8//d/lezoPkHLMOwiam0564kuVBZobVR5qH
	7EP3MaYGnVrCYrXYUcQNgpy8HKyRCyQ2o=
X-Google-Smtp-Source: AGHT+IEBvhmq6OLscxvxgZhDTcta1KkQd0Yh9W3dpRnzVaFg0PYi+8esUxhmPV9bTlryNb4o9YIoFQ==
X-Received: by 2002:a05:600c:1d1c:b0:43c:e467:d6ce with SMTP id 5b1f17b1804b1-4531dde6bc9mr13579025e9.4.1749541929571;
        Tue, 10 Jun 2025 00:52:09 -0700 (PDT)
Message-ID: 
Date: Tue, 10 Jun 2025 09:52:08 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/5] console: add relocation hook
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 
Cc: xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini ,
 Andrew Cooper 
References: 
 <4f1889dc03ec4aa2cc0cd2bd14523a2c6f670bdb.1748182535.git-series.marmarek@invisiblethingslab.com>
 <0b17da9c-57db-4a8b-90af-e53e45cb1243@citrix.com> 
 <66cfdee6-5dc2-4139-8550-ef441fa7a7a0@suse.com> 
  
 <83c22da9-62c5-4fb2-bc2d-f34ad5956d3e@suse.com> 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 06.06.2025 17:54, Marek Marczykowski-Górecki wrote:
> On Fri, Jun 06, 2025 at 08:26:33AM +0200, Jan Beulich wrote:
>> On 05.06.2025 18:08, Marek Marczykowski-Górecki wrote:
>>> On Thu, Jun 05, 2025 at 06:05:02PM +0200, Jan Beulich wrote:
>>>> On 05.06.2025 16:51, Marek Marczykowski-Górecki wrote:
>>>>> On Thu, Jun 05, 2025 at 04:42:53PM +0200, Jan Beulich wrote:
>>>>>> Why is it that this ring is dependent upon Xen's position? If the ring was
>>>>>> dynamically allocated, it wouldn't change position when Xen is moved.
>>>>>
>>>>> The console is setup quite early, I don't think I can allocate memory at
>>>>> this stage, no?
>>>>
>>>> But you allocate before Xen is moved, I suppose.
>>>
>>> Well, I have those buffers in BSS exactly to avoid the need to allocate
>>> them (or rather: have bootloader allocate them for me).
>>
>> Yet them remaining in .bss is now getting in the way. Imo moving them to
>> .init.* and adding proper allocation is going to be easier than the hook-
>> ary you are proposing.
> 
> So, when would you propose to allocate them? Wouldn't that be yet
> another hook?

Exactly one, yes. Given Andrew's earlier reply my understanding was that to
get things correct in your proposed model would end up requiring more than
one. However, the point in time where move_xen() is called is still too
early to allocate memory a (somewhat) normal way - even the boot allocator
gets seeded only later. So I guess console_init_preirq() may need to inform
its caller how much memory is going to be needed later on (and what address
constraints there are, if any). Then a suitable chunk would need setting
aside kind of like it's done for kexec. That address would then need to be
passed into the new hook.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 08:01:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 08:01:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010564.1388684 (Exim 4.92)
	(envelope-from )
	id 1uOtvE-0004Bx-Dc; Tue, 10 Jun 2025 08:01:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010564.1388684; Tue, 10 Jun 2025 08:01: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 1uOtvE-0004Bq-Aq; Tue, 10 Jun 2025 08:01:28 +0000
Received: by outflank-mailman (input) for mailman id 1010564;
 Tue, 10 Jun 2025 08:01: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 1uOtvD-0004Bk-1p
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 08:01:27 +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 16b7fc16-45d1-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 10:01:18 +0200 (CEST)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-442f4a3a4d6so27504445e9.0
 for ; Tue, 10 Jun 2025 01:01:24 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-452ec06d9aesm127741865e9.15.2025.06.10.01.01.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 01:01:23 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 16b7fc16-45d1-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749542484; x=1750147284; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=sZk9paXdDCd27tnOfR27Ep0WF1h8iUcDD+Ad36raOo0=;
        b=MRe4d4rZ08xmqVVZgq9HY3iVXjxZAOMgd4OCIkcT4JYLI6CIjXGRjY+Kpx7WcB6276
         iUgG8WrW6PH5q5ynhj2wezitzQs1oFo/YJTfWS0DBrVU0g6fmytEJ79lUYTCeeUnoav0
         8D2L0AtywL/fwGGhIjktVSvhVKcRoNQHVU5SN6inqEENtd2UnDOakopTeHSAlECbzIvs
         BI+o8Ouy/CDh9p0qmJJCFqP8qOJog9sZbvybpF8hoeMQNMcjzLi1i7HOeI4Nh2140ULa
         apc3NIOptggJys1hD0lHTp27+6WCS4uT4B0syh5KCSEdRtjXm+8A/CHcpn+hyYCAPMF9
         YxgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749542484; x=1750147284;
        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=sZk9paXdDCd27tnOfR27Ep0WF1h8iUcDD+Ad36raOo0=;
        b=R27OfdD6D7307PkwD7qFO0D0Y0w84quDxSZjmVea+X+HL82TqAX8KLNt78GSBTsxpn
         llegGFvxiUJR+qlKN7jS/n9nR6ooO2FShW3GhB6Xc+UIumywhD5nSTLiRNwYBi5/TvfM
         9NYOr+36fpO9rE9bSlsuum7wn5N1VWXbP1o78Rsc4s+Uc62j8ldJFKxbP60spGYuwShJ
         XPB17qB7bLQ2+9QOokiWjwX15d2TX8SbRMQYDQF0LwA1aNzymB/jK3O9e2FfMlFhFElE
         Lqkx+fDpI+7VtRt9l/HckDjJOX8IgA9oXE7TQZhis7xtPWZuvoi6sLCCY/aRnSoR6xZd
         KrCQ==
X-Forwarded-Encrypted: i=1; AJvYcCVvGPOIQHOhMoUAW0oNPlbkfRhgz1wVfSj7S6084zZOFrDrVCSnAAenUgPtLmKjqrtWFzPJ5F1LSAs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzmZOtvF7p399N3RKaTLtt5JyuSG27pgxRrOmwso78ER4vkd7Ly
	a4bA+48XiqIirwfFdN+9VnapMAuhJ0ei8Y2Mxoig9XziI/Np4/zx+U6NlsKpifI80g==
X-Gm-Gg: ASbGncsCbhfMGH39ka6b5C1iA50FssIUNF/YeOTNelsiD4H9vgEkPwW0ahcqRE/nAe+
	K+sDOPAbeX599JvQDS7oYZVGQ55O3BsRgIQcM9dKpvJ9IR2R9fBTiJ7u+cSwgWTq0xuS7JVa1nS
	wRFo91WtS3JX8J/qIMSBi96xKcSdyTpBtQTdf2jAISiiOqowKvkgFHQgwlUsSiXa+lRJgMoH468
	w5fJBhFQ8M11FJ3PeDOKCkP4VsBAvIFFqOGiJrKqMt1aQ8Sdqj2c1t1yqLazog7tvbhGysKhFe0
	5IUoT4MN2I/EdsR5J2wjW+NcJI/mJmpn3Ydymjil0ZvAdNoQzgWupfu9mryhNSyYeoiWvQOhNsg
	DSzSSvRRZI2VCOI2pNvlizQTl12A7S7EYDFSsEUJk67pE55kU4uKXhoI7CbAbQ/uDmbtkzYLVLf
	j43IYafZS5DOjXewkoyxyE
X-Google-Smtp-Source: AGHT+IG+CtceMc5LT1PiMUiPq6ExPTO416qqDhd9Oiplj/HZc2qKyaTC85mtuRoNX7Op9k5fUBwiyQ==
X-Received: by 2002:a05:600c:1d0c:b0:439:8878:5029 with SMTP id 5b1f17b1804b1-4531ceb6109mr19686285e9.2.1749542484166;
        Tue, 10 Jun 2025 01:01:24 -0700 (PDT)
Message-ID: 
Date: Tue, 10 Jun 2025 10:01:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/3] x86/EFI: Fix detection of buildid
To: Andrew Cooper 
Cc: Ross Lagerwall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 "Daniel P . Smith" ,
 Xen-devel 
References: <20250605111638.2869914-1-andrew.cooper3@citrix.com>
 <20250605111638.2869914-2-andrew.cooper3@citrix.com>
 <0a314400-126a-4c2a-b36c-dda61bb0b751@suse.com>
 
 <4d1f1b70-e309-453b-bae6-e066d49a417a@suse.com>
 <9200277c-aa8e-4fd9-ab6a-f9e106114f54@citrix.com>
 <6eaf2b27-969a-4326-9726-8b6e0994e006@suse.com>
 <3f9c5a18-2ea1-4e2d-80a0-773abc3598ae@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: <3f9c5a18-2ea1-4e2d-80a0-773abc3598ae@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 06.06.2025 17:01, Andrew Cooper wrote:
> On 06/06/2025 8:22 am, Jan Beulich wrote:
>> On 05.06.2025 19:01, Andrew Cooper wrote:
>>> On 05/06/2025 2:24 pm, Jan Beulich wrote:
>>>> On 05.06.2025 14:14, Andrew Cooper wrote:
>>>>> On 05/06/2025 1:02 pm, Jan Beulich wrote:
>>>>>> On 05.06.2025 13:16, Andrew Cooper wrote:
>>>>> This really is a property of being a PE32+ binary, and nothing to do
>>>>> with EFI.
>>>> Which still can be checked for without having this code path being taken
>>>> for xen.gz, too: You could e.g. check for &efi > &_end. That's firmly an
>>>> image property (yet I expect you're going to sigh about yet another hack).
>>> It's all hacks, but no.
>>>
>>> I'm amazed MISRA hasn't spotted that we've got a global `struct efi
>>> efi;` and a label named efi, creating an alias for the object with it
>>> out of bounds in the compiled image.  But even then, it's based on
>>> XEN_BUILD_EFI not XEN_BUILD_PE and does not distinguish the property
>>> that matters.
>> The use of XEN_BUILD_EFI in the linker script should have been switched
>> to XEN_BUILD_PE when the split was introduced.
> 
> That doesn't build.  As I already explained, the stubs aren't split in a
> way that allows that.

Which then is a pretty clear indication that the split was wrong to do in
the first place, don't you agree?

>>> But the argument I'm going to make this this:  Why do you want a check,
>>> even if you can find a correct one (and as said before, I cannot)?
>>>
>>> This function is run exactly once.  We've excluded "nothing given by the
>>> toolchain", and excluded "what the toolchain gave us was not the
>>> expected ELF note".  The only thing left (modulo toolchain bugs) is the
>>> CodeView region, and if it's not a valid CodeView region then we've
>>> wasted a handful of cycles.
>> Two reasons: Having code which cannot possibly do anything useful isn't
>> good. Misra calls the latest the body of the inner if() "unreachable code"
>> and objects to the presence of such in a build.
> 
> It's not unreachable code, not even theoretically.

How is it not? If we build without this CodeView record, it very much is
unreachable.

> *If* there was a suitable check, I'd be using it, but everything you've
> proposed has been buggy or doesn't even compile.

Okay, but we draw different conclusions: You want to do it in a way that,
as per above, imo introduces unreachable code. Whereas I keep wanting to
find a suitable check (or if necessary introduce whatever is needed to
have one).

>> And then, based on your reasoning above, why don't you also drop the
>> #ifdef CONFIG_X86?
> 
> Because that's the one non-buggy way of excluding an impossible case.
> 
> x86 is the only architecture possibly linking with pep emulation, and
> therefore the only architecture to possibly have a CodeView record.

And how's the, say, Arm case different from the x86 case with no such
record built in? Either it's unreachable code in both cases, or it's
not.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 08:02:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 08:02:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010570.1388695 (Exim 4.92)
	(envelope-from )
	id 1uOtwO-0004gY-Mx; Tue, 10 Jun 2025 08:02:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010570.1388695; Tue, 10 Jun 2025 08:02: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 1uOtwO-0004gR-Jk; Tue, 10 Jun 2025 08:02:40 +0000
Received: by outflank-mailman (input) for mailman id 1010570;
 Tue, 10 Jun 2025 08: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 1uOtwN-0004gL-Bj
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 08:02:40 +0000
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 461b7680-45d1-11f0-a306-13f23c93f187;
 Tue, 10 Jun 2025 10:02:37 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 461b7680-45d1-11f0-a306-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1749542556; x=1749801756;
	bh=ZtXzfZoeozoo2V76hlgC4XSea52A0MjKHciBMqaNKY4=;
	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=OFIOEbY4Y84bsinZt5hwgIEmi0nNU1S3arUWzATkG/eBwAYvs0ljB+3i5xluG80yx
	 qaCjlLcm1G7V4n5eDUYHz36DLV9Riq+d0Awp3aX6zS4K5fp8k8pLSVLtdQw5GC8TeH
	 q7EfceCi39nD6Ws+zxXYxgy8qND4D9sXNPajfOcAU+LQpKUls40TVwrwERAdhSSY0t
	 n6uJ+lrZFAwYgxzOBA/OHaBwhbZQpW/0doNZqUyvnFzsz0a/NvvUrfrdI537FV9pZY
	 RRkbNb40yOIRn9IkWCo6izA1yiNug1W7Y+fstMOlWSBUh3qH+vtRtE4uCjG0sLK/mm
	 xPs394oi6UmEg==
Date: Tue, 10 Jun 2025 08:02:30 +0000
To: Jan Beulich 
From: dmkhn@proton.me
Cc: Julien Grall , andrew.cooper3@citrix.com, anthony.perard@vates.tech, roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v9 2/3] xen/domain: adjust domain ID allocation for Arm
Message-ID: 
In-Reply-To: <30c01c78-5a5e-435f-9b1c-faca3af04a76@suse.com>
References: <20250528225030.2652166-1-dmukhin@ford.com> <20250528225030.2652166-3-dmukhin@ford.com> <63087c42-d709-4e53-a2c3-8b812f13190a@xen.org>  <30c01c78-5a5e-435f-9b1c-faca3af04a76@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 18acf0b160f372eaa9111b20f5f605a10d3a0cf4
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 10, 2025 at 08:53:12AM +0200, Jan Beulich wrote:
> On 06.06.2025 23:29, Julien Grall wrote:
> > Hi Denis,
> >
> > On 05/06/2025 23:05, Julien Grall wrote:
> >> Hi Denis,
> >>
> >> On 28/05/2025 23:50, dmkhn@proton.me wrote:
> >>> From: Denis Mukhin 
> >>>
> >>> From: Denis Mukhin 
> >>>
> >>> Remove the hardcoded domain ID 0 allocation for hardware domain and r=
eplace it
> >>> with a call to get_initial_domain_id() (returns the value of hardware=
_domid on
> >>> Arm).
> >>
> >> I am not entirely why this is done. Are you intending to pass a differ=
ent domain ID? If so...
> >>
> >>>
> >>> Update domid_alloc(DOMID_INVALID) case to ensure that get_initial_dom=
ain_id()
> >>> ID is skipped during domain ID allocation to cover domU case in dom0l=
ess
> >>> configuration. That also fixes a potential issue with re-using ID#0 f=
or domUs
> >>> when get_initial_domain_id() returns non-zero.
> >>>
> >>> Signed-off-by: Denis Mukhin 
> >>> ---
> >>> Changes since v8:
> >>> - rebased
> >>> ---
> >>> =C2=A0 xen/arch/arm/domain_build.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | 4 ++--
> >>> =C2=A0 xen/common/device-tree/dom0less-build.c | 9 +++------
> >>> =C2=A0 xen/common/domain.c=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 | 4 ++--
> >>> =C2=A0 3 files changed, 7 insertions(+), 10 deletions(-)
> >>>
> >>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.=
c
> >>> index e9d563c269..0ad80b020a 100644
> >>> --- a/xen/arch/arm/domain_build.c
> >>> +++ b/xen/arch/arm/domain_build.c
> >>> @@ -2035,9 +2035,9 @@ void __init create_dom0(void)
> >>
> >> ... naming like create_dom0() probably wants to be renamed.
> >>
> >> That said, I am not convinced a domain other than 0 should have full p=
rivilege by default. So I would argue it should stay as ...
> >>
> >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if ( !llc_coloring_enabled )
> >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 flags |=3D CDF=
_directmap;
> >>> -=C2=A0=C2=A0=C2=A0 domid =3D domid_alloc(0);
> >>> +=C2=A0=C2=A0=C2=A0 domid =3D domid_alloc(get_initial_domain_id());
> >>
> >> ... 0.
> >
> > Looking at the implementation of get_initial_domain_id(), I noticed the=
 behavior was changed for x86 by [1].
> >
> > Before, get_initial_domain_id() was returning 0 except for the PV shim.
> > But now, it would could return the domain ID specified on the command l=
ine (via hardware_dom).
> >
> > From my understanding, the goal of the command line was to create the h=
ardware domain *after* boot. So initially we create dom0 and then initializ=
e the hardware domain. With the patch below, this has changed.
> >
> > However, from the commit message, I don't understand why. It seems like=
 we broke late hwdom?
> >
> > For instance, late_hwdom_init() has the following assert:
> >
> > =C2=A0=C2=A0=C2=A0 dom0 =3D rcu_lock_domain_by_id(0);
> > =C2=A0=C2=A0=C2=A0 ASSERT(dom0 !=3D NULL);
> >
> > Jan, I saw you were involved in the review of the series. Any idea why =
this was changed?
>=20
> I simply overlooked this aspect when looking at the change. You're right,=
 things
> were broken there. Unless a simple and clean fix can be made relatively s=
oon, I
> think this simply needs reverting (which may mean to revert any later com=
mits
> that depend on that). I can't help noting that in this console rework the=
re were
> way too many issues, and I fear more than just this one may have slipped
> through. I therefore wonder whether taken as a whole this was/is worth bo=
th the
> submitter's and all the reviewers' time.

Yes, sorry, I overlooked late_hwdom_init() modification.

IMO, the clean fix would be adding another command line parameter
`control_domid` (with default value 0), make get_initial_domain_id() return=
 it
instead of current `hardware_domid` and update late_hwdom_init() to use
`control_domid` insted of open-coded 0.

That should align with the effort of splitting priveleged dom0 into control=
 and
hardware domains: control domain will be the first domain ID allocated,
followed by the hardware domain.

>=20
> Jan
>=20
> > [1] https://lore.kernel.org/all/20250306075819.154361-1-dmkhn@proton.me=
/
> >
>=20



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 08:10:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 08:10:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010577.1388705 (Exim 4.92)
	(envelope-from )
	id 1uOu4K-0006Mt-FD; Tue, 10 Jun 2025 08:10:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010577.1388705; Tue, 10 Jun 2025 08:10: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 1uOu4K-0006Mm-Ao; Tue, 10 Jun 2025 08:10:52 +0000
Received: by outflank-mailman (input) for mailman id 1010577;
 Tue, 10 Jun 2025 08:10: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 1uOu4I-0006Gp-UB
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 08:10: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 68cea739-45d2-11f0-a306-13f23c93f187;
 Tue, 10 Jun 2025 10:10:45 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3a375e72473so2570134f8f.0
 for ; Tue, 10 Jun 2025 01:10:45 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a532435fbfsm11682508f8f.64.2025.06.10.01.10.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 01:10:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 68cea739-45d2-11f0-a306-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749543045; x=1750147845; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=qwWWPJTWMaorfeOcISTR/qpqWCjDp0p6zk5YlMsAqlw=;
        b=eiG/mubAmZBTfyCvUisDEixKFu8wTRY8vMcXqEjW7vHcGyvD9wtQSX5hQDsKbuW3nf
         oxs5qHDkLRYRVlT9U6yY6/j4OzBgnQoBXfwJpfYJ1czaXo5LeCJha3AoNMy+jkUhQF6m
         H0gYpwzT6a43yRvUN24qIeKcV9isx/Q7z2UA4uAVEuTGuG1DjXQ7zTxExWNAkIvf+03S
         +jrIHWhSI+BqSjAOFOC8v479JzKZqycEuEHIa5RqKWQYjp6evqutheMPdvnU1oPA+s3x
         cNQ1tFPh0x339nluQJOJ3oO8Sl6mFQGIndHkdFMXSjJm9LZQe1gJrqfe8xNEvmwtZqgY
         koYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749543045; x=1750147845;
        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=qwWWPJTWMaorfeOcISTR/qpqWCjDp0p6zk5YlMsAqlw=;
        b=K4OkAEB3E7oIUXj/c0xIMCPw7PvFJ9CBEMV6PeWaZ76RvOtnz2eqkHmyGa60QxqXSM
         aNDNs4NSHL3Qx1RbYFY8ZLaQ9qCNKaJ4yjelu8Dt09i9xxJ4dL2i+aawygZAvjCEonJ4
         zJGMp7kEVQeJC1Nz9BTcETNBPYek/weGpctMX9wled0g3LV85BWt/HEzDCfdEU/ZagpS
         7Jp9BtfXBVfT9wdUC6/b4j8Dj0zifwG3HqQ5c8XWBzOAByWrk9TjBYyWHz2wYdvNUXNy
         Iu0Swaxa7ZE28H9+fZN9nzkC1ISwci52jQ6A2pdHPlV3ZNyY0PrZco5B4O0BpnOCWWLt
         wmMg==
X-Forwarded-Encrypted: i=1; AJvYcCVowQ9XtcX/cc1jjCdbWLJKmwIHkNZEsQzPKPD6Mwv+pti5ct61h0Mf65FMXm+bJ99dyBB9/e86cb8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzOdb9lXf4sD/g7fI1NqWcOE77xxwwMHjgzFqAmjFpN4iwUZ1J5
	2Z2eHiQFjbKj1e/u7OL56K0UoMWF6ThDI2nw7V9RujRw4uZOvLt6hZn6wYR428ZS9A==
X-Gm-Gg: ASbGncugK9Gvwgtx5U30T6TMYN2MItbSLIyTlVVurpV45PnLQwkoTqznzFYN7y6Kh8O
	ccwNB4I5+bD959AE6h1J8C8o6Wtkf6zQlHVCeDjpXT6xzCVJdHIfu/8+hJoDW2LGUzki0qq7i56
	13lrDCMFpfkSrp0LBrqAVhautfmAXgTOJ3r/u4EI9LzCd/uCGGlh6nCTNh+VWRsb61Vr7xARg/P
	jH6dTE+kxlvexxbDbqf+Aj+qx5kteeijTi0Ye0uKqIwfJwkaFCClxwGXDumTCi50fNrtrKwwim2
	RfJmW6ugUALny+CG/QCOHkWAxDrfp6hiqx/pvrdqZviDmdeZqI6BpTfh4DGcFriozSdSmQrlUpT
	3GQiL/Nat+fbLtfU5gSf+HGsKNmJu3GYHp5x+qPx0GKDKRbNYhWVG8nI4kLYOaG2YKjzGq7o9My
	KWeS4NSsHsvm5f4TWaP4gR
X-Google-Smtp-Source: AGHT+IFIx3RdLabpI6UPVGW7/0QYCTzeLAx5Vpc0vRGyta7nj57QqSnHqcvxpM4TUFX0L9fFcHPIng==
X-Received: by 2002:a5d:5f8f:0:b0:3a3:7bad:29cb with SMTP id ffacd0b85a97d-3a531cba7afmr12547474f8f.52.1749543044792;
        Tue, 10 Jun 2025 01:10:44 -0700 (PDT)
Message-ID: 
Date: Tue, 10 Jun 2025 10:10:44 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1] xen/console: group pbuf under console field
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org,
 dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250606194937.2412579-1-dmukhin@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: <20250606194937.2412579-1-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.06.2025 21:49, dmkhn@proton.me wrote:
> From: Denis Mukhin 
> 
> Group all pbuf-related data structures under domain's console field.

Fine with me in principle, as I was indeed wondering about the lack of
grouping when the sub-struct was introduced, but ...

> @@ -654,6 +648,12 @@ struct domain
>  
>      /* Console settings. */
>      struct {
> +        /* hvm_print_line() and guest_console_write() logging. */
> +#define DOMAIN_PBUF_SIZE 200
> +        char *pbuf;
> +        unsigned int pbuf_idx;
> +        spinlock_t pbuf_lock;
> +
>          /* Permission to take ownership of the physical console input. */
>          bool input_allowed;
>      } console;

... since all uses of the fields need touching anyway, can we perhaps
think of giving the fields better names? I never understood what the
'p' in "pbuf" actually stands for, for example. My suggestion would
be to replace "pbuf" by "glog" (for "guest logging"), but surely there
are alternatives.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 08:21:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 08:21:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010586.1388714 (Exim 4.92)
	(envelope-from )
	id 1uOuEr-0008K6-GF; Tue, 10 Jun 2025 08:21:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010586.1388714; Tue, 10 Jun 2025 08:21:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uOuEr-0008Jz-DF; Tue, 10 Jun 2025 08:21:45 +0000
Received: by outflank-mailman (input) for mailman id 1010586;
 Tue, 10 Jun 2025 08:21: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 1uOuEq-0008Js-3v
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 08:21:44 +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 f01cbf76-45d3-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 10:21:41 +0200 (CEST)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-451d41e1ad1so40763205e9.1
 for ; Tue, 10 Jun 2025 01:21:41 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a53229d9ddsm11468200f8f.4.2025.06.10.01.21.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 01:21:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f01cbf76-45d3-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749543701; x=1750148501; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=x/9/yjQE7Q8N0Y/EC7l+Zl3+4gJyi+alReqTzeTmkTs=;
        b=FVAoAliX6Jy6kXajAXCyAAi/DMv7AZ9+e/lyUoKkmVngwwzUlnOQKf1j8WnBLoweGf
         lU57ZQ75HTnl+upvjtZsivNg+seTR9QLbEhfd6QFu0LvOG11MLOZdzrzSvAvWDwxSJnG
         8qhO/2HvGHklbCshy+xg7CasgbHV0nz6/PkVzUR2KQn3o086wxJM4A9B1PVuqpEoyUnK
         I2TGgDsPO2ErFtpp6+GmxLI64/Qa5yVjl2M41as8KU1l5bkZ/2vFnNB100CAS+4E/yho
         wZzVrbpt0/2wDxZvE/8eXHcycjtMoho+8ZFVMS6d9KkU6YMOjMx+YRCzGDb2Xl63N038
         T8zQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749543701; x=1750148501;
        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=x/9/yjQE7Q8N0Y/EC7l+Zl3+4gJyi+alReqTzeTmkTs=;
        b=WCJBHjVdfSwjNlPO7cWKo5KQ/Jm8UfCsTnUhvc98VUp+GdC93Ahutaa5g5+ZdWhvW4
         Snif9yC1a9sFIyG1SATBEIjMieZFD6nuAvuExENrMWGvIdIBFce/JblpPXKa5Vj9Hy3M
         3AYprTZSu4po3IOCMiQzFi82rQua1JTcKnUMK+wokDFagpK/yTNbXfarBZMKdITxIxhn
         yY6Umc5akfcFZ26TlwEkQnjdGsTCm/2OU0PrT0ak/9P4nQ6sN9h2W11xykna5k8GmZ6V
         ymHncv+S9gwAdPB2eBDFeVv5NAMUbafJAvUVLdPLrlRNvebQL5WG0JLlE9Mc7dt10p4X
         9Ekw==
X-Forwarded-Encrypted: i=1; AJvYcCWyc9Guxu1JtVnHaFmZ75CHhWpsthu6Rjg24RsKhlEH0dRwfaTbb2xWatBiV7Cm3Ag8gdtOcx77tNs=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxwlece4D/FJl3rE2JN9Z3WpAY5qUXTYZjLDHYPXxhWGV/3zkxX
	vFQZE8de/JGuXNAO19VL+ib0y8JMc/A0/0EimQQVmn8dI4A/TaAn/jRRs/S5LZMwfA==
X-Gm-Gg: ASbGncuIUHNxrzQiQftRwsMrXxBe1+1LhTL2C9sPfzdI0Nq1VA12KfLllYXOlwsWiwE
	MWfCZXDI3lgaaTKzLf3s7ZmEXa6bPAwAOc1Juws94Tg8evdxnC+Xy9R30Rm1skIeDnEd8nlQCQL
	2lhsFqDdx1tkyis6XJ4UDdWP7rrhGaydMdQFhkvkx1nqhs3jGmS3ZvMwoUxecNNJCdyTdVCg+J0
	CjbKbAQDm/dn+j11HOaXj7tvR6aIp6PF2NA0IIjrMNJhvirU73p/OSVDyfz2Ds78123qRZsUwtO
	OkOmL/AB76wQHgC6TTjs9PcbWXJ/xFVYYno0N8g6N8H0yIVKTNzWYhDNdd09IcE2Heves3SIwSu
	BstIL/w6nehcxmuPKF2Mxbip8sQsqu5tayONJvQzfdyGIJM0y8fMtz37CGvI8Jo72XpeqlIEhVj
	RDjfjw0Le06mfvqIaK3iYR
X-Google-Smtp-Source: AGHT+IFb4QL8wtEsn4E6xzaiCdPP1MT4ihH0HKy5KCpbSK4aL70aCsN479uYSTEROwL0BBm+yJXtXA==
X-Received: by 2002:a05:600c:a412:b0:453:697:6f08 with SMTP id 5b1f17b1804b1-45306977143mr71828795e9.26.1749543701325;
        Tue, 10 Jun 2025 01:21:41 -0700 (PDT)
Message-ID: 
Date: Tue, 10 Jun 2025 10:21:40 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/2] xen/console: unify printout behavior for UART
 emulators
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org,
 dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250606201102.2414022-1-dmukhin@ford.com>
 <20250606201102.2414022-3-dmukhin@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: <20250606201102.2414022-3-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.06.2025 22:11, dmkhn@proton.me wrote:
> From: Denis Mukhin 
> 
> If virtual UART from domain X prints on the physical console, the behavior is
> updated to (see [1]):
> - console focus in domain X: do not prefix messages;
> - no console focus in domain X: prefix all messages with "(dX)".

While, as indicated (much) earlier, I can see why omitting the prefix
may make sense for the domain having input focus, ...

> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -740,7 +740,17 @@ 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 */
> +            char prefix[16] = "";
> +            struct domain *consd;
> +
> +            consd = console_get_domain();
> +            if ( consd != cd )
> +                snprintf(prefix, sizeof(prefix), "(d%d) ", cd->domain_id);
> +            console_put_domain(consd);
> +
>              nrspin_lock_irq(&console_lock);
> +            if ( prefix[0] != '\0' )
> +                console_send(prefix, strlen(prefix), flags);
>              console_send(kbuf, kcount, flags);
>              nrspin_unlock_irq(&console_lock);
>          }

... this, aiui, is a behavioral change for the non-dom0less case, where
Dom0 output will suddenly also gain the prefix. Which I don't think is
wanted: Switching focus between Xen and Dom0 should remain unaffected
in this regard.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 08:26:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 08:26:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010594.1388726 (Exim 4.92)
	(envelope-from )
	id 1uOuJO-0000TW-50; Tue, 10 Jun 2025 08:26:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010594.1388726; Tue, 10 Jun 2025 08:26: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 1uOuJN-0000TP-WB; Tue, 10 Jun 2025 08:26:25 +0000
Received: by outflank-mailman (input) for mailman id 1010594;
 Tue, 10 Jun 2025 08:26: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 1uOuJM-0000TJ-8r
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 08:26:24 +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 97d66064-45d4-11f0-a306-13f23c93f187;
 Tue, 10 Jun 2025 10:26:23 +0200 (CEST)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-450dd065828so34588385e9.2
 for ; Tue, 10 Jun 2025 01:26:23 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4521370936esm133663955e9.20.2025.06.10.01.26.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 01:26:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 97d66064-45d4-11f0-a306-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749543983; x=1750148783; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=8OtPQd3BNGsbzCYQd7Cgvi5Cg+O5c+T2fPfHfNlcul8=;
        b=bKzeDZf/9XQ29g3ESVYxXsnMzcbthwTyP1kAoPEj+u5cbHjChJ1A7a0rdmHG+psuW0
         y7BGBjXDH6JuO4/iP1mvrYL9KMVuKtcwqXkJQnNhi1omKOoh+tsvfdzwSOM1r4JMhV2H
         aVCmE1kPQNq70McqttFz/MsXu4oHK0EIFvYn+fN1aivmLzWey1nNaEFvsmQEOMRVTaYA
         ct3Q/quhBlC1eeaXP3zuztfvz9yvSZaNU8S2eD0tFd4psHvJq3B2gxbftG5RRTnZDDsH
         /EVztYYhgtCDxnZ5HSZm5thwSlitYdwh+a5Y7yyk8xchQNmKF6OvaF9AbNb+eIRKd2Z1
         725g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749543983; x=1750148783;
        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=8OtPQd3BNGsbzCYQd7Cgvi5Cg+O5c+T2fPfHfNlcul8=;
        b=vZ+iaGkjaRR5pIy3WrFWF3MWkjdbDQmRJNeNV9wyxKRAaKqicE4PkAPMN8QJ7k3JMe
         Mmi7BwB7kBbXkLyjpcag0xf3DJcKg+Aw2w+E3/QtclPJVQGDNvrdwv3PJn33pGK8a4NB
         FJMRHgJDMax3jT38Yj4Qi8GdM2D4gRtG8aV9FWEZbouh4Jdt4TPcb2hrTyNbjtF8L+Ce
         rW/BdaqJhafJrpahCYlKjJArBbJHBcTE9cDkGaWVGm2fbq/lzub9FUkjyPF7u7NQ72bp
         +rbVz5xFpyFqdN1kLKkpLVlhgsPi3WXwqSPUWTvc5Ws0cVO5R4qvu3IL/ZNeSPMKZgQl
         b9Uw==
X-Forwarded-Encrypted: i=1; AJvYcCUDok03r4ibSALWbjZ5SS+O9rfW3x2F/dY7IYxlBzHHd7IuxKAmvK0dpCDfwsEbANbXdv8dg39LLMg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwlC1OdKI7rRd4THy+9iqLy6g7EhvOU5SUpWdlQQgjeHN3fWe8C
	daf5eiY3i1TS8HK5wzWVhCe5/4rRZNyj6BiM0UrCRhrs0ndF3KSLT0/UJIJikZH2Yg==
X-Gm-Gg: ASbGncs48UzEPY0hdRlVWcRaiDEAiyn3W5U0hC/8M4msAbmjzY2kOm5ZhpD4J/6rKn3
	Wbs7yi/e7P2FhRLltWqggcWEBEWCOfARKkapeDg+PdLehtcVtVFmDFCmkUfeJoq9tsXQ+5Hjosj
	TXbfm+HVdkxOlvWstVJmyZj9AlcmhCAlL3pr00pSXMlqLlvfgGrjijFEheXNI04qpyc4TEPlZSm
	tSf2TTHOrdSbmz/Y+48JdltWMWuT2WBL6D7T0ZZ3bRDOVoE2kOsPlDD5BI/LM9XWMHFTCwIrBDM
	Ddv4Mq0HiiQIAqGYLgmEyhI+O1mgwQO5eY6UpHsMymXMoMNGNKRscu2iHR6iZST66hovJoFX7Co
	9dzLPUen0gBv690+nlqYK8OwYgeftyl2VwHmn4dr7hGZ+wt9V42fCtleGuT5zXa/CWW3+rl2xNZ
	wWbjTyqGegrueQTO7hQ+uy
X-Google-Smtp-Source: AGHT+IFyk04OF2d0aTUnSZNb7vhYnP/WewiwxKAkvPJASxvHReRWoeXSxb6IopI1N3+f7i6N7YFZjw==
X-Received: by 2002:a05:600c:c163:b0:43c:fd27:a216 with SMTP id 5b1f17b1804b1-452fa7ed515mr113449025e9.23.1749543982676;
        Tue, 10 Jun 2025 01:26:22 -0700 (PDT)
Message-ID: <11ea9475-d963-473d-a85b-d1c461e7b213@suse.com>
Date: Tue, 10 Jun 2025 10:26:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 2/3] xen/domain: adjust domain ID allocation for Arm
To: dmkhn@proton.me
Cc: Julien Grall , andrew.cooper3@citrix.com,
 anthony.perard@vates.tech, roger.pau@citrix.com, sstabellini@kernel.org,
 teddy.astie@vates.tech, dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250528225030.2652166-1-dmukhin@ford.com>
 <20250528225030.2652166-3-dmukhin@ford.com>
 <63087c42-d709-4e53-a2c3-8b812f13190a@xen.org>
 
 <30c01c78-5a5e-435f-9b1c-faca3af04a76@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.06.2025 10:02, dmkhn@proton.me wrote:
> On Tue, Jun 10, 2025 at 08:53:12AM +0200, Jan Beulich wrote:
>> On 06.06.2025 23:29, Julien Grall wrote:
>>> Hi Denis,
>>>
>>> On 05/06/2025 23:05, Julien Grall wrote:
>>>> Hi Denis,
>>>>
>>>> On 28/05/2025 23:50, dmkhn@proton.me wrote:
>>>>> From: Denis Mukhin 
>>>>>
>>>>> From: Denis Mukhin 
>>>>>
>>>>> Remove the hardcoded domain ID 0 allocation for hardware domain and replace it
>>>>> with a call to get_initial_domain_id() (returns the value of hardware_domid on
>>>>> Arm).
>>>>
>>>> I am not entirely why this is done. Are you intending to pass a different domain ID? If so...
>>>>
>>>>>
>>>>> Update domid_alloc(DOMID_INVALID) case to ensure that get_initial_domain_id()
>>>>> ID is skipped during domain ID allocation to cover domU case in dom0less
>>>>> configuration. That also fixes a potential issue with re-using ID#0 for domUs
>>>>> when get_initial_domain_id() returns non-zero.
>>>>>
>>>>> Signed-off-by: Denis Mukhin 
>>>>> ---
>>>>> Changes since v8:
>>>>> - rebased
>>>>> ---
>>>>>   xen/arch/arm/domain_build.c             | 4 ++--
>>>>>   xen/common/device-tree/dom0less-build.c | 9 +++------
>>>>>   xen/common/domain.c                     | 4 ++--
>>>>>   3 files changed, 7 insertions(+), 10 deletions(-)
>>>>>
>>>>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>>>>> index e9d563c269..0ad80b020a 100644
>>>>> --- a/xen/arch/arm/domain_build.c
>>>>> +++ b/xen/arch/arm/domain_build.c
>>>>> @@ -2035,9 +2035,9 @@ void __init create_dom0(void)
>>>>
>>>> ... naming like create_dom0() probably wants to be renamed.
>>>>
>>>> That said, I am not convinced a domain other than 0 should have full privilege by default. So I would argue it should stay as ...
>>>>
>>>>>       if ( !llc_coloring_enabled )
>>>>>           flags |= CDF_directmap;
>>>>> -    domid = domid_alloc(0);
>>>>> +    domid = domid_alloc(get_initial_domain_id());
>>>>
>>>> ... 0.
>>>
>>> Looking at the implementation of get_initial_domain_id(), I noticed the behavior was changed for x86 by [1].
>>>
>>> Before, get_initial_domain_id() was returning 0 except for the PV shim.
>>> But now, it would could return the domain ID specified on the command line (via hardware_dom).
>>>
>>> From my understanding, the goal of the command line was to create the hardware domain *after* boot. So initially we create dom0 and then initialize the hardware domain. With the patch below, this has changed.
>>>
>>> However, from the commit message, I don't understand why. It seems like we broke late hwdom?
>>>
>>> For instance, late_hwdom_init() has the following assert:
>>>
>>>     dom0 = rcu_lock_domain_by_id(0);
>>>     ASSERT(dom0 != NULL);
>>>
>>> Jan, I saw you were involved in the review of the series. Any idea why this was changed?
>>
>> I simply overlooked this aspect when looking at the change. You're right, things
>> were broken there. Unless a simple and clean fix can be made relatively soon, I
>> think this simply needs reverting (which may mean to revert any later commits
>> that depend on that). I can't help noting that in this console rework there were
>> way too many issues, and I fear more than just this one may have slipped
>> through. I therefore wonder whether taken as a whole this was/is worth both the
>> submitter's and all the reviewers' time.
> 
> Yes, sorry, I overlooked late_hwdom_init() modification.
> 
> IMO, the clean fix would be adding another command line parameter
> `control_domid` (with default value 0), make get_initial_domain_id() return it
> instead of current `hardware_domid` and update late_hwdom_init() to use
> `control_domid` insted of open-coded 0.

No, no new command line option will address this. Original behavior needs to be
restored (either by correcting the earlier change or, as said, be reverting).

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 08:32:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 08:32:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010600.1388734 (Exim 4.92)
	(envelope-from )
	id 1uOuOv-0002Dp-MI; Tue, 10 Jun 2025 08:32:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010600.1388734; Tue, 10 Jun 2025 08: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 1uOuOv-0002Di-Jm; Tue, 10 Jun 2025 08:32:09 +0000
Received: by outflank-mailman (input) for mailman id 1010600;
 Tue, 10 Jun 2025 08: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 1uOuOu-0002Dc-10
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 08:32:08 +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 62b0d03b-45d5-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 10:32:03 +0200 (CEST)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-442ea341570so33298545e9.1
 for ; Tue, 10 Jun 2025 01:32:03 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a532436555sm11796928f8f.61.2025.06.10.01.32.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 01:32:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 62b0d03b-45d5-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749544323; x=1750149123; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=42DAYlwQ+tkYMtayZ9Mn7ArsepIwbn2TYcbLNZDnMhM=;
        b=Rqk0gO6UUaRScAY39f0bBZR0qr6IClmJ7M2azjDEIGAhRcwQgJZvPQAC5f7yrr15dK
         h6ZO6OtXMvEFZT5vOzg0PBTVwupEYHwQSQsBuD2jGiJLQIdBHmu7S9L8eud3cBnK9koj
         WCIf7BeCltB/lhvxR2tVI7W9KjhCcfNifEFptxetBhB97nMcTR+0bg6l3b33OmlC1OMY
         4Jb/mDqTspgLVUfbsMhQHke6X+o61lXfF7CcHYWLAlHnPmm/V1LK6cg9RV8QbsIL5Xli
         VaXKam9MDS6UHSrNcmzEUDer2F/qyVuOe3S9GS6y4ay9vx66A5VsJofPWf8pgzsPOzJU
         EbHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749544323; x=1750149123;
        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=42DAYlwQ+tkYMtayZ9Mn7ArsepIwbn2TYcbLNZDnMhM=;
        b=K478Z30CkijT+Zwis4AbkiiVEFvMpYthnRq1MbnyOPcVxET9890hCTrkTjL4hOs2eR
         t28eAlXPGZIYSWj5A9c0lGC08uITDZcD92grzy2Stwhf4TpnyVilEENgdoWw7+xPkbgA
         HJgbS7Owh75aGovFrjevvDnRUF5ocLKIWPKpCjYP2hbOWGr9KWECQSkw0I7gOqQm5xHN
         hZAPCuwgkem083IwPEQSZoGmWBbCo/W4R008Kpzrunhuc7hEHZ3x7eU8eFCOcVWV64Ey
         N1HXmY2Gj5HAOcXVoZ4isnALLkSPwsrDQC5TBZP0z3NJCVUNX31uDxeVQftfb360ynnI
         9XOg==
X-Forwarded-Encrypted: i=1; AJvYcCWf3k1wwZwByWyZ6q2TZe+ocBnObmdxFDFNWJvwQwOKJs7kRWtExzPVqeFI0Iq4dMGOHlcI+4X6dSw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyaQmxEXrcsPE5dHCrFnY/JjsH7epvX8GeeXG+PSZZ4kjOBtG/I
	jlLLiKboEmssUzFkv8BQ6XcR/VRUYOEy5gqtm36FGFlIvtqh1JnaLEKq7NgHs9jC1g==
X-Gm-Gg: ASbGncv1ymJFcoyrOWCc1OYFOsdc3QOJIIzqMQfixrxGYspPVftvgB+RRWc+9zT448b
	l1RlvXn19HYfje+Vrn4vXoB0KWqPewtxt7uD4sF8SMpb/IRlgPczqlx9WIXhe6Q2o8Sx3zR+f4M
	5CsdiuAeIPb94yxnrlrTccUNZCVafhsZaokxxEIfRpCGYUNkc7CaFiWJ/Tg8fn+N86gbi0hiya0
	KsSXzYNSfvIRo3MW/NaRfkrJGJLF++Ya9I6Bq+aGRXGUxK0QSeB6ymYbunVgiFc0GJBCptCeQkY
	5ejTCGIWHmZl7fYGw2Z0XvBDXW+QriF1inD/PzOqd5uhF4BoBP01XfrJMZy8bU3U4Y+wwbSLVHc
	zrbWNEdXxzQYiNIrbwPs/R10u8/iI0mIg8k4JuY3/kD5asFFkym+ZHT3ww6UDMAl/SI3vBDI8eD
	AK8p0587yS69l1RPji6viMHNdiCYEWUDM=
X-Google-Smtp-Source: AGHT+IFQYXvafICc4tU35a9BqF5V/cqDwFMrCpHjfchQ/XsSN3oLjx9PvVX4qPtTUAPxWvcQXeHu5Q==
X-Received: by 2002:a05:600c:5396:b0:441:b3eb:570a with SMTP id 5b1f17b1804b1-452013681efmr174664545e9.2.1749544323012;
        Tue, 10 Jun 2025 01:32:03 -0700 (PDT)
Message-ID: 
Date: Tue, 10 Jun 2025 10:32:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4] automation/eclair: update configuration of D4.10
To: Stefano Stabellini 
Cc: Andrew Cooper ,
 Stefano Stabellini , michal.orzel@amd.com,
 julien@xen.org, roger.pau@citrix.com, bertrand.marquis@arm.com,
 federico.serafini@bugseng.com, Nicola Vetrini ,
 xen-devel@lists.xenproject.org
References: 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.06.2025 23:04, Stefano Stabellini wrote:
> --- a/xen/arch/x86/include/asm/cpufeatures.h
> +++ b/xen/arch/x86/include/asm/cpufeatures.h
> @@ -1,6 +1,6 @@
> -/*
> - * Explicitly intended for multiple inclusion.
> - */
> +/* This file is intended to be included multiple times. */

While I can see that this may indeed be needed, ...

> +/*#ifndef X86_CPUFEATURES_H */
> +/*#define X86_CPUFEATURES_H */

... I wonder what this is about. Sorry, I didn't spot this as a change
in v3. If it's needed, these comments want to be well formed (have a
space between * and #).

Beyond this - why is this header ending up different from e.g.
public/errno.h, where a SAF-8 comment is used?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 08:36:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 08:36:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010606.1388745 (Exim 4.92)
	(envelope-from )
	id 1uOuSh-0002mh-4m; Tue, 10 Jun 2025 08:36:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010606.1388745; Tue, 10 Jun 2025 08:36: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 1uOuSh-0002ma-1o; Tue, 10 Jun 2025 08:36:03 +0000
Received: by outflank-mailman (input) for mailman id 1010606;
 Tue, 10 Jun 2025 08:36: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 1uOuSg-0002mT-Fo
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 08:36: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 f067370f-45d5-11f0-a306-13f23c93f187;
 Tue, 10 Jun 2025 10:36:01 +0200 (CEST)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-adb2bb25105so823979866b.0
 for ; Tue, 10 Jun 2025 01:36:01 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a5323b4e2fsm11631311f8f.36.2025.06.10.01.35.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 01:35:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f067370f-45d5-11f0-a306-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749544561; x=1750149361; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=1QwM8MjnnqQa6IzvTFhZa2Yfu4mvxmSyGlKAuPxVIBg=;
        b=dHP5HoNmIRVZnwkYXFGjAhyK92mNR1JRZzpsa6/6ZpNrhq9HO/F1yRiJeDEwmPgR2U
         03c/OiIdnLqb+6Q/OAdGeyFzDLhsfKqUczcSQQkt+nj5fLRp3K4iKDqRGXSwhyH7FCq/
         I4zVtqQ1frzDtot+jFHim+ttXI1ZL1JsSXSOvRKqSAKeld3LRrYFjXUVOMSs2Z483r4N
         2oRohiBk80KaGf6HLLGHXWtFI1u7FrZLUUn4fo+4steiIef/stzXqxu7CAnD3z19I0p6
         3qyJAUN/WnwGSBMx246COqQzwTiA5xhN0EMshHDRwo6Dw1UO6mZ3/S2CwqWHZYdQeEU2
         fzxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749544561; x=1750149361;
        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=1QwM8MjnnqQa6IzvTFhZa2Yfu4mvxmSyGlKAuPxVIBg=;
        b=vXRQBBQ34lv26rlpIm1hE3DhdYVBlzbkiSG6H44B+7/p/CmbXQePZKH85JfpEGDz1Q
         8W+N3qyLpDNWOdw5GXJervM7FjRehIBgHp3iUDgcCfpabXcPFS1kXJdRXp9liaIeAIvK
         rXS9OtM+lLAOWIsD9OkPD4DIY7CH5KGuuxMzMzf1jm3EGLx1s9zT41ilndHAofxNSRto
         rUKLx0rgEGE+Dj+wvek8ZzqLQMqBhM/KwYzsqJXtJByYIoIHT0LQ7xsdMAZ5C81sivnH
         eBWj4ltMu1YvOfetdpmLQtl7V4jgyGVeR7PvATrpWxlbp8Qji3NhjeA3uvDfwMk//9r8
         Yfjw==
X-Forwarded-Encrypted: i=1; AJvYcCWqrRCJItyr1diUwKM4pGkEWj8+JYdDLfiwI9ShYoRk8tbvvpexNaNKR+Eyt/iOLZeFrmdayDYUcGg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwZcaLhmJXv8dLP7y1ukpLn5ibweWoESmsNGMvsvLSaPIG5xrlc
	N6tUG2hopdOYYgbOjueoZ6cLbcz0M2vZbDP9L0uYrO1TBH+6796fxOBju5i6Jj8uwjo3rYzgmnI
	evvI=
X-Gm-Gg: ASbGnct0GC2SeCEd9mJhPETWIE0tpghFfcuJZm/c8aizKu9a1DI7EWo/9HLzW29qgxC
	yFi80VPeyLqTg6dTv4Mg1ylQWv5KGpVYFsCEMLIPcw6FIgAgLictF23NtRJPAq9HYCUyvGKQRVE
	JiAY++DzjSsSlW0brM0TVGBYY2KtZfrpHMSDMOPSnERkFfb9A2DOKYIzWqXJVOcoYeJo7brhsA5
	Xxf4sdtoKNJES5wTGWzJck3pJ5dCz6KL7obU93vUCfMUc+T2MiVXkk+VtAGd2FOEyO3CfDY+qDy
	rIjKVcevNP9iESs5pNPWW/sOqfJuL67Ua3nHonPPwWJV2MP7WEf6YjE6VCFPxfCJYJ/rS1ypC3S
	8D1LDDzzn51K4VtnbqFuWFGC//JGflHJVfGcZokT7bCueIwobcmOl9EwK2oMv5/LM4O9MceryHW
	EUOIC+X6aQzuxBWCMjcu8v
X-Google-Smtp-Source: AGHT+IFgK6+UpEs/eU4CgvUrfc5FBzjbHttoZA1oAmLu3QByXWhiKQ8l55KLc/fbaoHMWQePalIfbg==
X-Received: by 2002:a05:6000:40d9:b0:399:6dd9:9f40 with SMTP id ffacd0b85a97d-3a5318823bcmr13074382f8f.9.1749544548529;
        Tue, 10 Jun 2025 01:35:48 -0700 (PDT)
Message-ID: 
Date: Tue, 10 Jun 2025 10:35:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/3] xen/keyhandler: add missing noreturn attribute
To: victorm.lira@amd.com
Cc: Nicola Vetrini ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?B?Um9nZXIgUGF1IE1vbm7Dg8Kp?= ,
 Stefano Stabellini ,
 Federico Serafini ,
 Bertrand Marquis , xen-devel@lists.xenproject.org
References: <20250606212712.1901838-1-victorm.lira@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: <20250606212712.1901838-1-victorm.lira@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.06.2025 23:27, victorm.lira@amd.com wrote:
> From: Nicola Vetrini 
> 
> Function `reboot_machine' does not return, but lacks the `noreturn'
> attribute.
> 
> Functions that never return should be declared with a `noreturn'
> attribute.
> 
> The lack of `noreturn' causes a violation of MISRA C Rule 17.11 (not
> currently accepted in Xen), and also Rule 2.1: "A project shall not
> contain unreachable code". Depending on the compiler used and the
> compiler optimization used, the lack of `noreturn' might lead to the
> presence of unreachable code.

I continue to be unhappy about this: I still fail to see how this
"might" could materialize in the specific case here. My earlier
request for commit message improvement was specifically about making
the description match the particular case, not to add further general
wording. That said, if others feel like ack-ing this in this form, so
be it.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 08:56:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 08:56:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010615.1388754 (Exim 4.92)
	(envelope-from )
	id 1uOum7-000610-Qg; Tue, 10 Jun 2025 08:56:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010615.1388754; Tue, 10 Jun 2025 08:56:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uOum7-00060t-Nt; Tue, 10 Jun 2025 08:56:07 +0000
Received: by outflank-mailman (input) for mailman id 1010615;
 Tue, 10 Jun 2025 08:56: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 1uOum6-00060m-CJ
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 08:56:06 +0000
Received: from mail132-4.atl131.mandrillapp.com
 (mail132-4.atl131.mandrillapp.com [198.2.132.4])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ba6aed90-45d8-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 10:55:59 +0200 (CEST)
Received: from pmta09.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail132-4.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4bGjLk28S4zlfcLy
 for ; Tue, 10 Jun 2025 08:55:58 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 4d88861d8e4d4309b4dc06de647e39be; Tue, 10 Jun 2025 08:55: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: ba6aed90-45d8-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1749545758; x=1749815758;
	bh=V10wIIOg7o3xtwDUxgAJUC+V4RnqVBdqbqkJ2Fwxos0=;
	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=aGgDY2wutJwZabvk2xLksN1DMa3m2Vsr0ICdqZsoHmojXw0pxm3V3Zhq0xfIQXdYH
	 0gYdVza3KVNZlR/PtElHNVLvDqFB+0jBj1XwtVEN27d7zs8Plx+Dy23BW6lvZ0LFIH
	 PTKGdZOhld1Jc+F9NtZaRUn3sDXAp8im+IRyL0WWPUyYIylWmLb5Wb/w1R6DbBN2V6
	 FJKhrq/4m34CJ1Ka+bIxglSVp7s0LF8i0M4ONLAAufS3X7hPjoRV0QMMdabUgPGU7A
	 SYOl+v8sQUT7lupL2+n5d43sgqx9A1As5DHn0yyLtMXhYLVFKT5gEtbG9KRxDKnMZ0
	 oeMe/tMTOLMqA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1749545758; x=1749806258; i=teddy.astie@vates.tech;
	bh=V10wIIOg7o3xtwDUxgAJUC+V4RnqVBdqbqkJ2Fwxos0=;
	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=K0pB7iOokLZLhXJZZzaIbpac/aaxEwehAvB66508S91AMMWStzCV2AMIooJi9+gwq
	 HE60uKsenBrdIxzCzfWvQNpeJGAdAZ77DxLWXlJXKV5pbIsSg/uAGrX0PR3IZZuhhN
	 fXAjDVvdLrOHeg0oi0N3QTyDScKeif3ls79ompov0gwedlDywu1NtNie96qKTb20qL
	 AiaH99ZFpEWAyM85ura2CtwzwuCnUooaX3xJOAsdb24OgVqB03VrJ1S7xUlTy5c/h1
	 AtAK1x7xnwSD80SXlsN4Sy21bbYTbZTZNPghr7EWN+8NiMHAoiUjHa/US6ze4A0ZuR
	 ndxpacsV3TW1w==
From: "Teddy Astie" 
Subject: =?utf-8?Q?Re:=20[PATCH=20v6]=20xen/domain:=20rewrite=20emulation=5Fflags=5Fok()?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1749545755259
Message-Id: 
To: dmkhn@proton.me, xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
References: <20250610004216.3012253-1-dmukhin@ford.com>
In-Reply-To: <20250610004216.3012253-1-dmukhin@ford.com>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.4d88861d8e4d4309b4dc06de647e39be?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250610:md
Date: Tue, 10 Jun 2025 08:55:58 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hello,

Le 10/06/2025 =C3=A0 02:45, dmkhn@proton.me a =C3=A9crit=C2=A0:
> From: Denis Mukhin 
> 
> Rewrite emulation_flags_ok() to simplify future modifications.
> 
> No functional change intended.
> 
> Signed-off-by: Denis Mukhin 

Reviewed-by: Teddy Astie 

> ---
> Changes since v5:
> - optimized `configs[]` table - just one record for PV case
> - sorted entries in `configs[]` table by domain type: PV, then PVH, then =
HVM
>    entries
> - addressed `caps` initializaton
>   
> Link to v5: https://lore.kernel.org/xen-devel/20250602191717.148361-3-dmu=
khin@ford.com/
> Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines=
/1861382846/
> ---
>   xen/arch/x86/domain.c | 86 ++++++++++++++++++++++++++++++++++---------
>   1 file changed, 68 insertions(+), 18 deletions(-)
> 
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index 7536b6c871..82b126351b 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -743,32 +743,82 @@ int arch_sanitise_domain_config(struct xen_domctl_c=
reatedomain *config)
>       return 0;
>   }
>   
> +/*
> + * Verify that the domain's emulation flags resolve to a supported confi=
guration.
> + *
> + * This ensures we only allow a known, safe subset of emulation combinat=
ions
> + * (for both functionality and security). Arbitrary mixes are likely to =
cause
> + * errors (e.g. null pointer dereferences).
> + *
> + * NB: use the internal X86_EMU_XXX symbols, not the public XEN_X86_EMU_=
XXX
> + * symbols.
> + */
>   static bool emulation_flags_ok(const struct domain *d, uint32_t emflags=
)
>   {
> +    enum {
> +        CAP_PV          =3D BIT(0, U),
> +        CAP_HVM         =3D BIT(1, U),
> +        CAP_HWDOM       =3D BIT(2, U),
> +        CAP_DOMU        =3D BIT(3, U),
> +    };
> +    static const struct {
> +        unsigned int caps;
> +        uint32_t min;
> +        uint32_t opt;
> +    } configs[] =3D {
> +#ifdef CONFIG_PV
> +        /* PV dom0 and domU */
> +        {
> +            .caps   =3D CAP_PV | CAP_HWDOM | CAP_DOMU,
> +            .min    =3D X86_EMU_PIT,
> +        },
> +#endif /* #ifdef CONFIG_PV */
> +
> +#ifdef CONFIG_HVM
> +        /* PVH dom0 */
> +        {
> +            .caps   =3D CAP_HVM | CAP_HWDOM,
> +            .min    =3D X86_EMU_LAPIC | X86_EMU_IOAPIC | X86_EMU_VPCI,
> +        },
> +
> +        /* PVH domU */
> +        {
> +            .caps   =3D CAP_HVM | CAP_DOMU,
> +            .min    =3D X86_EMU_LAPIC,
> +        },
> +
> +        /* HVM domU */
> +        {
> +            .caps   =3D CAP_HVM | CAP_DOMU,
> +            .min    =3D X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ)=
,
> +            /* HVM PIRQ feature is user-selectable. */
> +            .opt    =3D X86_EMU_USE_PIRQ,
> +        },
> +#endif /* #ifdef CONFIG_HVM */
> +    };
> +    unsigned int i;
> +    unsigned int caps =3D (is_pv_domain(d) ? CAP_PV : CAP_HVM) |
> +                        (is_hardware_domain(d) ? CAP_HWDOM : CAP_DOMU);
> +
> +    /*
> +     * NB: PV domain can have 0 in emulation_flags.
> +     * See qemu-alpine-x86_64-gcc CI job.
> +     * Inject fake flag to keep the code checks simple.
> +     */
> +    if ( (caps & CAP_PV) && emflags =3D=3D 0 )
> +        emflags |=3D X86_EMU_PIT;
> +
>   #ifdef CONFIG_HVM
>       /* This doesn't catch !CONFIG_HVM case but it is better than nothin=
g */
>       BUILD_BUG_ON(X86_EMU_ALL !=3D XEN_X86_EMU_ALL);
>   #endif
>   
> -    if ( is_hvm_domain(d) )
> -    {
> -        if ( is_hardware_domain(d) &&
> -             emflags !=3D (X86_EMU_VPCI | X86_EMU_LAPIC | X86_EMU_IOAPIC=
) )
> -            return false;
> -        if ( !is_hardware_domain(d) &&
> -             /* HVM PIRQ feature is user-selectable. */
> -             (emflags & ~X86_EMU_USE_PIRQ) !=3D
> -             (X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ)) &&
> -             emflags !=3D X86_EMU_LAPIC )
> -            return false;
> -    }
> -    else if ( emflags !=3D 0 && emflags !=3D X86_EMU_PIT )
> -    {
> -        /* PV or classic PVH. */
> -        return false;
> -    }
> +    for ( i =3D 0; i < ARRAY_SIZE(configs); i++ )
> +        if ( (caps & configs[i].caps) =3D=3D caps &&
> +             (emflags & ~configs[i].opt) =3D=3D configs[i].min )
> +            return true;
>   
> -    return true;
> +    return false;
>   }
>   
>   void __init arch_init_idle_domain(struct domain *d)


Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech




From xen-devel-bounces@lists.xenproject.org Tue Jun 10 09:03:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 09:03:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010622.1388765 (Exim 4.92)
	(envelope-from )
	id 1uOut2-0007ln-H2; Tue, 10 Jun 2025 09:03:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010622.1388765; Tue, 10 Jun 2025 09:03: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 1uOut2-0007lg-EL; Tue, 10 Jun 2025 09:03:16 +0000
Received: by outflank-mailman (input) for mailman id 1010622;
 Tue, 10 Jun 2025 09:03: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 1uOut0-0007la-R5
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 09:03:15 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on2061a.outbound.protection.outlook.com
 [2a01:111:f403:2412::61a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b97f1550-45d9-11f0-a306-13f23c93f187;
 Tue, 10 Jun 2025 11:03:08 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by DS7PR12MB6192.namprd12.prod.outlook.com (2603:10b6:8:97::6) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8792.34; Tue, 10 Jun 2025 09:03:04 +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.8835.018; Tue, 10 Jun 2025
 09: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: b97f1550-45d9-11f0-a306-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=omTr7huueHHwmperRVGKiIZ2PdTPZt1Mb3gOynhshBV321p+oSixf1jJndhVaaMTZetc0JsfiucXjileGBokExavrRM5SBtH+t1oblD4aXH04llCxyCewhxL8AVSypGlXlOPAhpy4hErO5aZAcxwSZCkg5RaqOiKDYnCgYbCi1gkZKZzzFIZJXLbhnXdM7VUPUaY7ocDBt1Phl2es8kn5CTN3XvrOJthYjJ2Rmhiv3kPg4lVslSmC5zB87qRrMvT/FilDp0SZwzkKzM0icDXAEoSrDU6Z8LESIHdsJ6QJOxrPZRY5ieS6IgWkBHYUwv2DoDZwjwdZt1amb1fVgojIg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=pv+5URx8pFmGch36sWFjT6ZJ6wkJTqU61KduxwJA/N0=;
 b=jNegdgpk/At2X3SR7XGaR5tHFkVqsRMez+DTJ9o4NTPvQymOAiwf0fmtNjCvuvzIBZ1vHJsoMC64ewS2stvB1yWEptkNtA2tidmPGV8aQzZUytof82ypSbPrviJblJlmcHwMR+z0ieSh4mZI8wAaDfGuQ6hJee0IZY5FcPJzO6ioauhoMIQ7WA2k+ovzi9M3DScpP1tPM6DkkY/UHo2VkIRMR0aA77FI5FTjHAzjPZEUqZesWbbWIuiIw9KQ75d2svAauee9CGZSaXCfvl3xDReoHpqTGdYXnvgOrOZAdLxw2mjyFSfFdeA7CGPEwDiO9Q04IQ+9qv3FyeAOXiWTjA==
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=pv+5URx8pFmGch36sWFjT6ZJ6wkJTqU61KduxwJA/N0=;
 b=taXAEe74kj0slZsGUv7eCHTH/U/frT3qwm6Fqn8ZPageUulDTndS/nQSzln1VbXDDUMzm1JQlecGinhauFmBhtXYVzWXjwgT/EDlJCNtAKMNHiigq5RptEio9qvSQ4k3czM3aaC0SRp9A7OFszON9S6b4i6UOP5R77HM5/f0m+o=
From: "Chen, Jiqian" 
To: Jan Beulich 
CC: "xen-devel@lists.xenproject.org" , Andrew
 Cooper , Anthony PERARD
	, "Orzel, Michal" , Julien
 Grall , Stefano Stabellini , "Huang,
 Ray" , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, "Chen, Jiqian" 
Subject: Re: [PATCH v5 04/10] vpci: Refactor REGISTER_VPCI_INIT
Thread-Topic: [PATCH v5 04/10] vpci: Refactor REGISTER_VPCI_INIT
Thread-Index:
 AQHbziMOHCuaHG697kCTYWoBETQpzrP0lKSAgAGsWwD//4WWAIAAI9IAgAUkMwD//5c1AIAAk1OA//+AeAAANIYcgP//sryAgAClEwA=
Date: Tue, 10 Jun 2025 09:03:03 +0000
Message-ID:
 
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
 <20250526094559.140423-5-Jiqian.Chen@amd.com>
 
 
 <752cff02-cef6-4a4c-80b9-eba3bbf9b264@suse.com>
 
 
 
 
 
 
 <6a7a1ab8-aabb-465b-bd22-a2bc1597b83b@suse.com>
In-Reply-To: <6a7a1ab8-aabb-465b-bd22-a2bc1597b83b@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.8835.017)
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_|DS7PR12MB6192:EE_
x-ms-office365-filtering-correlation-id: c13b5b79-3812-40d6-d6c9-08dda7fd9bae
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?aGw2OFprZ2F3VHFOQVVzeVYzallXZ2JKUWRxMHZsdk9ndTBMV200RGtLbUZh?=
 =?utf-8?B?WHpINnRTYngzR0xRTGJNckhnekl5bzR0WW1GR3VuLzNHQmFhZ2E4L2dMRTIw?=
 =?utf-8?B?RCtLY3J3ajgydW1aRGlJNHpYQmZvU2ZOb0RxS3R0WXkxZU1LQUlacTJUZm5H?=
 =?utf-8?B?QzExSkRsdVBVWHZuUGQ5a1JsVnZBSVVTZ2tqNExqYzJKN2hvNklnL1pubU9X?=
 =?utf-8?B?MkNpRzByZzNGdDV2KzlBckJYc1BJY3h2b3M1OC9jcVpGVFRxcjRvclUwWlpF?=
 =?utf-8?B?S3ZWTzBaMHVvd3VhMkcwOW81emJvdWl1NEQvZW5scWJtN2VZbWE1eHk3R3Vj?=
 =?utf-8?B?NHZkU2t5dlUvRWsrMS9HL2MxSGRSUlFINm5DdGFUMEJybmNHRElLZ0RyS3Az?=
 =?utf-8?B?aUJMdTlzcFpiRU1iejIxNmpBcTFpdCtBYzlKSzk3byttL2pvMTRNWUh1bjZE?=
 =?utf-8?B?eEhISXhuSnIzeDgzaG4zMGsyMjVHTFYzQXFZYlc5MnFWdFhQN2FoaFJrT212?=
 =?utf-8?B?ZTRJbWV0MXdSVzY3aE1rM2tubFByK1Fob1U2RTVzU3hqOG1menhieWZ3allC?=
 =?utf-8?B?TGUrekg3Ui8rNk01cVlJMEFUekMwbDRkU1ZjTDYrS0Z0NkZ3MTNZS2NqUm1r?=
 =?utf-8?B?azkvdWZ5YnVGeEx3T2tWYnBrcm1YOUZqNVZ1RjJnLzFRbFdXTTAvN05lY0l1?=
 =?utf-8?B?STNTOWhyNnAraUtPSyt3WHVVLzljTnpoSEswRjZaUDhYTExQU1dKL1YvaWRm?=
 =?utf-8?B?bnYyZXhmK0hRaloxTWlCR25ZdXhNL2grQXB5eHBHTzRiVEZkTmxWNEdBeUdX?=
 =?utf-8?B?bFRmeVRrVTl6akQ1blRxUHo5bEZVUDEzcGpBSGNzQnc2VktHRll1dU5WMU1J?=
 =?utf-8?B?SWJ1bEVmNEdXVmhxWVpKNk4zcjJtaGVobld2Y1R3K1hUdm1oRmM4V3l3Wkh1?=
 =?utf-8?B?bUNGeXVQb0hmS3ZiUW9nSEp4NGhFck9WaFJFdWRxYndSSGlsbFJBSGh1SEQ0?=
 =?utf-8?B?VTVNbHc4Y3hrU1J4aG4yZ2VKcmFld2p5ZW9lUGJQRERVVFFNaHhrM1dzUUtH?=
 =?utf-8?B?V3J4YnN4SW01c3lmK1VGUWpock02NjdlZkR0b2tZK2FyaXhrUlpBRE5MVGNB?=
 =?utf-8?B?N2JXSkxreW1hWFR5UGgrUDNOSGQyVjVmYW1iU3N2dDNwd0tOVzFGdDVtaEk1?=
 =?utf-8?B?NWY0UkIxUUpzTXB4OUFIRHpOeFF0cEROaTRLbkp5VW04bExablhaWm85bzFy?=
 =?utf-8?B?TmZjcllqS051aGZhZEcyV2dSY1ZDV3FzWnBnQWQ2N29aV3ptblpYbCtvU0ZG?=
 =?utf-8?B?VXh6WXlKbnQ5YjJkcFk1Yy9pT09Bd2NVb0VrSjZnNGlvL25NZ0tVZmFNTzFh?=
 =?utf-8?B?YmlSN3FTd2pyVi9JdWRyR3RYS2R0OURvdmx0OStEdlpUY0VCcENsdHo3OTli?=
 =?utf-8?B?U1hNbHlvOHN5YXAyZGJkV1ZpeXd6eGU4bmllQzFYQmsxQjZXU2JVS1RUVVdJ?=
 =?utf-8?B?QVZxWEI4c0hIa1RscWRqMDBTWnZDZDJ6SGVkRFZVOXh6Z3hTNGJ2VUxWSkgy?=
 =?utf-8?B?MlhxeG9VZjl4MDNvLzBvZDRkYjcydFgwc0NOMG03SW9yd01GT2Ivd2tuWS9X?=
 =?utf-8?B?eGdWT2hJV29lbk0wTnpuMjBPR3JyeFJOR1lhV2xMQkFqWGt4Mk9iUDgzbXdq?=
 =?utf-8?B?WkJUUjJGeTlwakdqalJhUkh4T2lEczhkREdoUkp4M3RjUUdiWERtNU5sZUgz?=
 =?utf-8?B?SDFvYnZ1YXRWU2FkVDJwV0Q2YW9TZmJYNFJycXhOakdia1FNSzhUTkF3K25N?=
 =?utf-8?B?U2huUEFWRVU3S3V3MmRMN0VDcVo2UU9Pd2Q5eHhJd0c4RVVqNUxVZDFLNU9S?=
 =?utf-8?B?SXdhZ0RxdGlEM3pnWFdLVHF3bmt0V1IzV3lHWmJ2QTZtZk52ODVwdk9QTHhh?=
 =?utf-8?B?MGxBdkkyMkVDOVF3cWlSUWlYUlFPY3RyTmpabnBodFh6a2QwUUVxc2FzSWxD?=
 =?utf-8?B?WXZjWThRem9BPT0=?=
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?eUVTTVpVTHNFZ1NNS25BcmV1YUF2ZXZNa2FjK01RYzkyVHIvY0oyenZ3Z0NK?=
 =?utf-8?B?Y1hjd0pVU3pqSlc4WkNaMW95bmZmc0p5NXBaRXBuYWtrRDhLZXFMZC8wTTdh?=
 =?utf-8?B?QzVCVUZOMlhFQjB4QklVKzlmRkdmRXhJdVZpR1B1UC8yb0d3TWdOVisvKzQ5?=
 =?utf-8?B?NGhYT3RMZHJ3S2JqVlZTVlRET1dCaGlwdCtUb0pmZHA3bUNRalhVT092QmM2?=
 =?utf-8?B?bVk2S1R2UlIzemp2R1VhZ2ltandKTUlrb0NZczQ4ZXNjeWVwaEhqd1dodC82?=
 =?utf-8?B?WTJDVnAzSXQzUTZOTG1jQlZYaENMOTB4TWZVU092aE01N2hUVjM1R1NWNVFl?=
 =?utf-8?B?Ui9oTEw2QnJQRE9ZY3ZFcGREZWJLUnJuRVZxRTk5Wm5laXpuMFBJcVNqQzB2?=
 =?utf-8?B?NVQxVFlvQ2IwTTE5Tzh2cGFmTDBvSEx6TTN0bXhrcGpyVVU4c1lYYytldTh2?=
 =?utf-8?B?TUl2aHhhaEJqU1M2RTh5cGMyM09wZE9HWU55SWl4K0I5bnZBcmlRTjdzQlFN?=
 =?utf-8?B?WWpkUVo4dnRFZzFZekNNdzI5emVjSWd1b0JvVGN0V0h0enJIRkNFb1dRcXpR?=
 =?utf-8?B?alB5b0pMWGZmTXlId3JLNTIwNkZsbE5YRWcxWWVFeTNUa2ZBL0U5bVVtYklz?=
 =?utf-8?B?eXJSU1Y2Z1JLRlRCNE1pcHMrWm5yOUs4QnNTYzdzT3BZQUpkRXJtNUhFazNY?=
 =?utf-8?B?Nm05aTdMb250ZHEzVVdENmNmUlZ1R2ppMzBIQXVnRkdNczNyZ2xoa1VCMGZH?=
 =?utf-8?B?ZS9NczFtOWNyTzRMbGtWbGkrTnMzZzBOMXAwbWtFaTBrdjdnTmNkYVA5cjFP?=
 =?utf-8?B?VEpIcTBla0VScWFpYk0xNU1pWDhmdm5UY1FIL3NzeCtoR1N1L2ZFNlloWEF2?=
 =?utf-8?B?dkxJQnozWlZmQ3g4akl1Umw3RjFEejNxVWUybTI2RERBQmRkblR5dkc2bysw?=
 =?utf-8?B?MTh1dzUyRzBmTWNiNmZRSnFEbmhyVElGdElBLzl3Sktacys4TmREeFdPU3ZC?=
 =?utf-8?B?V05IZjhVR1pJREYweW9pNUpKSVNLbXZyS1lEdFh4UmhlS2ViVXpYOE1XcWha?=
 =?utf-8?B?YUhEYS9YT0RSck9FRnN6MTBVN1dDT2daNnlZVGx0UHpmRXZIbTMvVHUvUWQy?=
 =?utf-8?B?L1dRSnJMUmIrbTI3dlZ3K1dqdXNXRXQxelRvWVgvOFVBVHp3aCtqTmhyTEdW?=
 =?utf-8?B?eFVyd2ZGSWhIekZSRkJ4bmpHWEF6ZmN1TW04T0lVOW13eUdmZDkrUkhWRDR0?=
 =?utf-8?B?QnYzSm1HQ2NVTEYxMWZvcG81bUwxWHJ0R2RYQWJGaEFndC9oRlpJNUw2NUFN?=
 =?utf-8?B?NTBKb1I5TFoyOWRiMEp6RzNZWXZYV3dWWisrYkRSUGludWVDM1VFL1ZPdTNB?=
 =?utf-8?B?QURsVzJmOVl1Y1Jkc0cxeXNFZC9BTE1ZZmpYNzhHc1FpZDhma2FqWC9UbFls?=
 =?utf-8?B?RmllNE43dXhKdzdxd1RjWU5kZW9RaUxhQ0lTbDY5ZUhHQnBDRHF6cU9hY2N1?=
 =?utf-8?B?c2dnS3VndWZ0V1ZOZ0U2bmxCYlkvTm1DZnU2ZWxSZ0JEQjhvTGg0ZVMwV1Zh?=
 =?utf-8?B?M0RIOXJXYllmZGg0TkF4RzhuWUJZWE5SYTdWZGFjb0dUd3ZCdGFJS1J1cFJI?=
 =?utf-8?B?WWQ0SkttWnpvM09tVlRGSjRqTTNRZERlWmVRSFZibm9ZVzNNcmVrMUxHYUUy?=
 =?utf-8?B?ZUpDWFduYjhTYm81VDdIRUxrVUE5d3ZvUGxKQVJEZloxUkpHOUFhYmNwWEVl?=
 =?utf-8?B?eFExa0ZiNU1sZDhYamkxUTEwQUQ3Qis0azBBdFJTcGdObTRjb3E5SHgxdDk1?=
 =?utf-8?B?aU5CcXV5WWZKU3NzLzE2RU9SbmNpMmUyRlc3SEF1QThiRDR5WXdpRk5KTmFo?=
 =?utf-8?B?dHMvRW9nZVVXcGkwb3RCMG5UbmJ6c3hteHh3SUdicWhyUHNGUFpIQk4yQmNY?=
 =?utf-8?B?cVhJVDdXOVBGRit4UEY4NkVGNjlmRE9yd3NFa2tiWVlUVEFtdk1pdVFJWVpV?=
 =?utf-8?B?eUd1Q3NYbEV2Nm50M3orWk9WTGFKcFlDU2hSb3BrZGhRZVI0Nks5Q3dyK2RX?=
 =?utf-8?B?dldmWlpGdkhxOTc0dkRPeXc2Rkl4cmFOek9Fa3hnYXByWW1saHRTNGVWLzg0?=
 =?utf-8?Q?M6ZA=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <73ABBEF95019184FBD9AC3CF61F9797E@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: c13b5b79-3812-40d6-d6c9-08dda7fd9bae
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2025 09:03:03.6892
 (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: 3vYubJSfvG5P7ByuLlLMK+M4Y+S/14A2mWXCTa4I2V8Z2EokFI+n4i0ia2toS5ZUN04LPyDUDXJwlpS+GaO7Zg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB6192

T24gMjAyNS82LzEwIDE1OjA4LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMTAuMDYuMjAyNSAw
NTo1MiwgQ2hlbiwgSmlxaWFuIHdyb3RlOg0KPj4gT24gMjAyNS82LzkgMTg6NDAsIFJvZ2VyIFBh
dSBNb25uw6kgd3JvdGU6DQo+Pj4gT24gTW9uLCBKdW4gMDksIDIwMjUgYXQgMTA6MTg6NDJBTSAr
MDAwMCwgQ2hlbiwgSmlxaWFuIHdyb3RlOg0KPj4+PiBPbiAyMDI1LzYvOSAxNzoyOSwgUm9nZXIg
UGF1IE1vbm7DqSB3cm90ZToNCj4+Pj4+IE9uIE1vbiwgSnVuIDA5LCAyMDI1IGF0IDA3OjUwOjIx
QU0gKzAwMDAsIENoZW4sIEppcWlhbiB3cm90ZToNCj4+Pj4+PiBPbiAyMDI1LzYvNiAxNzoxNCwg
Um9nZXIgUGF1IE1vbm7DqSB3cm90ZToNCj4+Pj4+Pj4gT24gRnJpLCBKdW4gMDYsIDIwMjUgYXQg
MDk6MDU6NDhBTSArMDIwMCwgSmFuIEJldWxpY2ggd3JvdGU6DQo+Pj4+Pj4+PiBPbiAwNi4wNi4y
MDI1IDA4OjI5LCBDaGVuLCBKaXFpYW4gd3JvdGU6DQo+Pj4+Pj4+Pj4gT24gMjAyNS82LzUgMjA6
NTAsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+Pj4+Pj4+Pj4+IE9uIE1vbiwgTWF5IDI2LCAy
MDI1IGF0IDA1OjQ1OjUzUE0gKzA4MDAsIEppcWlhbiBDaGVuIHdyb3RlOiANCj4+Pj4+Pj4+Pj4+
ICsgIH07IFwNCj4+Pj4+Pj4+Pj4+ICsgIHN0YXRpYyB2cGNpX2NhcGFiaWxpdHlfdCAqY29uc3Qg
ZmluaXQjI19lbnRyeSAgXA0KPj4+Pj4+Pj4+Pj4gKyAgICAgICAgICAgICAgIF9fdXNlZF9zZWN0
aW9uKCIuZGF0YS52cGNpIikgPSAmZmluaXQjI190DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IElN
TyB0aGlzIHNob3VsZCBiZXR0ZXIgdXNlIC5yb2RhdGEgaW5zdGVhZCBvZiAuZGF0YS4gDQo+Pj4+
Pj4+Pj4gSXMgYmVsb3cgY2hhbmdlIGNvcnJlY3Q/DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiArICAg
IHN0YXRpYyBjb25zdCB2cGNpX2NhcGFiaWxpdHlfdCAqY29uc3QgZmluaXQjI19lbnRyeSAgXA0K
Pj4+Pj4+Pj4+ICsgICAgICAgIF9fdXNlZF9zZWN0aW9uKCIucm9kYXRhIikgPSAmZmluaXQjI190
DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gTm8sIHNwZWNpZmljYWxseSBiZWNhdXNlIC4uLg0KPj4+Pj4+
Pj4NCj4+Pj4+Pj4+Pj4gTm90IHRoYXQgaXQgbWF0dGVycyBtdWNoIGluIHByYWN0aWNlLCBhcyB3
ZSBwbGFjZSBpdCBpbiAucm9kYXRhIGFueXdheS4gIE5vdGUNCj4+Pj4+Pj4+Pj4gaG93ZXZlciB5
b3Ugd2lsbCBoYXZlIHRvIG1vdmUgdGhlIHBsYWNlbWVudCBvZiB0aGUgVlBDSV9BUlJBWSBpbiB0
aGUNCj4+Pj4+Pj4+Pj4gbGlua2VyIHNjcmlwdCBhaGVhZCBvZiAqKC5yb2RhdGEuKiksIG90aGVy
d2lzZSB0aGF0IHNlY3Rpb24gbWF0Y2ggd2lsbA0KPj4+Pj4+Pj4+PiBjb25zdW1lIHRoZSB2UENJ
IGRhdGEuDQo+Pj4+Pj4+Pj4gSSBhbSBzb3JyeSwgaG93IHRvIG1vdmUgaXQgYWhlYWQgb2YgKigu
cm9kYXRhLiopID8NCj4+Pj4+Pj4+PiBJcyBiZWxvdyBjaGFuZ2UgY29ycmVjdD8NCj4+Pj4+Pj4+
Pg0KPj4+Pj4+Pj4+IGRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS94ZW4veGVuLmxkcy5oIGIveGVu
L2luY2x1ZGUveGVuL3hlbi5sZHMuaA0KPj4+Pj4+Pj4+IGluZGV4IDc5M2QwZTExNDUwYy4uMzgx
NzY0MjEzNWFhIDEwMDY0NA0KPj4+Pj4+Pj4+IC0tLSBhL3hlbi9pbmNsdWRlL3hlbi94ZW4ubGRz
LmgNCj4+Pj4+Pj4+PiArKysgYi94ZW4vaW5jbHVkZS94ZW4veGVuLmxkcy5oDQo+Pj4+Pj4+Pj4g
QEAgLTE4OCw3ICsxODgsNyBAQA0KPj4+Pj4+Pj4+ICAjZGVmaW5lIFZQQ0lfQVJSQVkgICAgICAg
ICAgICAgICBcDQo+Pj4+Pj4+Pj4gICAgICAgICAuID0gQUxJR04oUE9JTlRFUl9BTElHTik7IFwN
Cj4+Pj4+Pj4+PiAgICAgICAgIF9fc3RhcnRfdnBjaV9hcnJheSA9IC47ICAgXA0KPj4+Pj4+Pj4+
IC0gICAgICAgKihTT1JUKC5kYXRhLnZwY2kuKikpICAgICBcDQo+Pj4+Pj4+Pj4gKyAgICAgICAq
KC5yb2RhdGEpICAgICAgICAgICAgIFwNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAuLi4gdGhpcyBpc24n
dCAtIHlvdSdkIG1vdmUgX2FsbF8gb2YgLnJvZGF0YSBpbnRvIGhlcmUsIHdoaWNoIGRlZmluaXRl
bHkNCj4+Pj4+Pj4+IGlzbid0IHdoYXQgeW91IHdhbnQuIFdoYXQgSSB1bmRlcnN0YW5kIFJvZ2Vy
IG1lYW50IHdhcyBhIC5yb2RhdGEtbGlrZQ0KPj4+Pj4+Pj4gc2VjdGlvbiwgZS5nLiAucm9kYXRh
LnZwY2kuKiAobXVjaCBsaWtlIGl0IHdhcyAuZGF0YS52cGNpLiogYmVmb3JlKS4NCj4+Pj4+Pj4N
Cj4+Pj4+Pj4gSW5kZWVkLCBteSBzdWdnZXN0aW9uIHdhcyBtZXJlbHkgdG8gdXNlIC5yb2RhdGEg
aW5zdGVhZCBvZiAuZGF0YSwgYXMNCj4+Pj4+Pj4gdGhhdCdzIG1vcmUgYWNjdXJhdGUgSU1PLiAg
SSB0aGluayBpdCBzaG91bGQgYmUgKigucm9kYXRhLnZwY2kpIChhbmQNCj4+Pj4+Pj4gc2FtZSBz
ZWN0aW9uIGNoYW5nZSBmb3IgdGhlIF9fdXNlZF9zZWN0aW9uKCkgYXR0cmlidXRlLg0KPj4+Pj4+
DQo+Pj4+Pj4gSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgdGhlIG5leHQgdmVyc2lvbiB3aWxs
IGJlOg0KPj4+Pj4+DQo+Pj4+Pj4gKyAgICBzdGF0aWMgY29uc3QgdnBjaV9jYXBhYmlsaXR5X3Qg
KmNvbnN0IGZpbml0IyNfZW50cnkgIFwNCj4+Pj4+PiArICAgICAgICBfX3VzZWRfc2VjdGlvbigi
LnJvZGF0YS52cGNpIikgPSAmZmluaXQjI190DQo+Pj4+Pj4gKw0KPj4+Pj4+DQo+Pj4+Pj4gYW5k
DQo+Pj4+Pj4NCj4+Pj4+PiAgI2RlZmluZSBWUENJX0FSUkFZICAgICAgICAgICAgICAgXA0KPj4+
Pj4+ICAgICAgICAgLiA9IEFMSUdOKFBPSU5URVJfQUxJR04pOyBcDQo+Pj4+Pj4gICAgICAgICBf
X3N0YXJ0X3ZwY2lfYXJyYXkgPSAuOyAgIFwNCj4+Pj4+PiAtICAgICAgICooU09SVCguZGF0YS52
cGNpLiopKSAgICAgXA0KPj4+Pj4+ICsgICAgICAgKigucm9kYXRhLnZwY2kpICAgICAgICAgICBc
DQo+Pj4+Pj4gICAgICAgICBfX2VuZF92cGNpX2FycmF5ID0gLjsNCj4+Pj4+DQo+Pj4+PiBEaWQg
eW91IGFsc28gbW92ZSB0aGUgaW5zdGFuY2VzIG9mIFZQQ0lfQVJSQVkgaW4gdGhlIGxpbmtlciBz
Y3JpcHRzIHNvDQo+Pj4+PiBpdCdzIGJlZm9yZSB0aGUgY2F0Y2gtYWxsICooLnJvZGF0YS4qKT8N
Cj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBCdXQsIHRoYXQgZW5jb3VudGVyZWQgYW4gd2FybmluZyB3
aGVuIGNvbXBpbGluZy4NCj4+Pj4+PiAiIHtzdGFuZGFyZCBpbnB1dH06IEFzc2VtYmxlciBtZXNz
YWdlczoNCj4+Pj4+PiB7c3RhbmRhcmQgaW5wdXR9OjExNjA6IFdhcm5pbmc6IHNldHRpbmcgaW5j
b3JyZWN0IHNlY3Rpb24gYXR0cmlidXRlcyBmb3IgLnJvZGF0YS52cGNpDQo+Pj4+Pj4ge3N0YW5k
YXJkIGlucHV0fTogQXNzZW1ibGVyIG1lc3NhZ2VzOg0KPj4+Pj4+IHtzdGFuZGFyZCBpbnB1dH06
MzAzNDogV2FybmluZzogc2V0dGluZyBpbmNvcnJlY3Qgc2VjdGlvbiBhdHRyaWJ1dGVzIGZvciAu
cm9kYXRhLnZwY2kNCj4+Pj4+PiB7c3RhbmRhcmQgaW5wdXR9OiBBc3NlbWJsZXIgbWVzc2FnZXM6
DQo+Pj4+Pj4ge3N0YW5kYXJkIGlucHV0fTo2Njg2OiBXYXJuaW5nOiBzZXR0aW5nIGluY29ycmVj
dCBzZWN0aW9uIGF0dHJpYnV0ZXMgZm9yIC5yb2RhdGEudnBjaSAiDQo+Pj4+Pg0KPj4+Pj4gV2hh
dCBhcmUgdGhlIGF0dHJpYnV0ZXMgZm9yIC5yb2RhdGEudnBjaSBpbiB0aGUgb2JqZWN0IGZpbGVz
PyAgWW91IGNhbg0KPj4+Pj4gZ2V0IHRob3NlIHVzaW5nIG9iamR1bXAgb3IgcmVhZGVsZiwgZm9y
IGV4YW1wbGU6DQo+Pj4+Pg0KPj4+Pj4gJCBvYmpkdW1wIC1oIHhlbi9kcml2ZXJzL3ZwY2kvbXNp
Lm8NCj4+Pj4+IFsuLi5dDQo+Pj4+PiAgMTcgLmRhdGEudnBjaS45ICAwMDAwMDAwOCAgMDAwMDAw
MDAwMDAwMDAwMCAgMDAwMDAwMDAwMDAwMDAwMCAgMDAwMDBhNTAgIDIqKjMNCj4+Pj4+ICAgICAg
ICAgICAgICAgICAgIENPTlRFTlRTLCBBTExPQywgTE9BRCwgUkVMT0MsIERBVEENCj4+Pj4+DQo+
Pj4+PiBJdCBzaG91bGQgYmUgUkVBRE9OTFksIG90aGVyd2lzZSB5b3Ugd2lsbCBnZXQgdGhvc2Ug
bWVzc2FnZXMuDQo+Pj4+Pg0KPj4+Pj4+IEFuZCwgZHVyaW5nIGJvb3RpbmcgWGVuLCBhbGwgdmFs
dWUgb2YgX19zdGFydF92cGNpX2FycmF5IGlzIGluY29ycmVjdC4NCj4+Pj4+PiBEbyBJIG1pc3Mg
YW55dGhpbmc/DQo+Pj4+Pg0KPj4+Pj4gSSB0aGluayB0aGF0J3MgbGlrZWx5IGJlY2F1c2UgeW91
IGhhdmVuJ3QgbW92ZWQgdGhlIGluc3RhbmNlIG9mDQo+Pj4+PiBWUENJX0FSUkFZIGluIHRoZSBs
aW5rZXIgc2NyaXB0Pw0KPj4+PiBPaCwgcmlnaHQuIFNvcnJ5LCBJIGZvcmdvdCB0byBtb3ZlIGl0
Lg0KPj4+PiBBZnRlciBjaGFuZ2luZyB0aGlzLCBpdCB3b3JrcyBub3cuDQo+Pj4+DQo+Pj4+IGRp
ZmYgLS1naXQgYS94ZW4vYXJjaC94ODYveGVuLmxkcy5TIGIveGVuL2FyY2gveDg2L3hlbi5sZHMu
Uw0KPj4+PiBpbmRleCBiZjk1NmI2YzVmYzAuLmM4OGZkNjJmNGYwZCAxMDA2NDQNCj4+Pj4gLS0t
IGEveGVuL2FyY2gveDg2L3hlbi5sZHMuUw0KPj4+PiArKysgYi94ZW4vYXJjaC94ODYveGVuLmxk
cy5TDQo+Pj4+IEBAIC0xMzQsNiArMTM0LDcgQEAgU0VDVElPTlMNCj4+Pj4gICAgICAgICBCVUdG
UkFNRVMNCj4+Pj4NCj4+Pj4gICAgICAgICAqKC5yb2RhdGEpDQo+Pj4+ICsgICAgICAgVlBDSV9B
UlJBWQ0KPj4+PiAgICAgICAgICooLnJvZGF0YS4qKQ0KPj4+PiAgICAgICAgICooLmRhdGEucmVs
LnJvKQ0KPj4+PiAgICAgICAgICooLmRhdGEucmVsLnJvLiopDQo+Pj4+IEBAIC0xNDgsNyArMTQ5
LDYgQEAgU0VDVElPTlMNCj4+Pj4gICAgICAgICAqKC5ub3RlLmdudS5idWlsZC1pZCkNCj4+Pj4g
ICAgICAgICBfX25vdGVfZ251X2J1aWxkX2lkX2VuZCA9IC47DQo+Pj4+ICAjZW5kaWYNCj4+Pj4g
LSAgICAgICBWUENJX0FSUkFZDQo+Pj4+ICAgIH0gUEhEUih0ZXh0KQ0KPj4+DQo+Pj4gRldJVywg
SSB3b3VsZCBwdXQgaXQgYWhlYWQgb2YgKigucm9kYXRhKS4gIFJlbWVtYmVyIHRvIGFsc28gbW9k
aWZ5IHRoZQ0KPj4+IGxpbmtlciBzY3JpcHQgZm9yIGFsbCB0aGUgb3RoZXIgYXJjaGVzLCBub3Qg
anVzdCB4ODYuDQo+Pg0KPj4gV2hldGhlciBiZWZvcmUgKigucm9kYXRhLiopIG9yIGJlZm9yZSAq
KC5yb2RhdGEpLCB0aGVyZSBzdGlsbCBpcyB0aGUgd2FybmluZyAiIFdhcm5pbmc6IHNldHRpbmcg
aW5jb3JyZWN0IHNlY3Rpb24gYXR0cmlidXRlcyBmb3IgLnJvZGF0YS52cGNpICINCj4+IEFuZCB0
aGUgb2JqZHVtcCBzaG93cyAicm9kYXRhLnZwY2kiIGhhcyBubyAicmVhZG9ubHkiIHdvcmQuDQo+
IA0KPiBEaWQgeW91IGNoZWNrIHdoYXQgZ2NjIGVtaXRzPyANCkkganVzdCBzYXcgYWJvdmUgd2Fy
bmluZy4NCj4gSXQgbWF5IGJlIHJlcXVlc3RpbmcgImF3IiBpbnN0ZWFkIG9mIHRoZQ0KPiB3YW50
ZWQgImEiIGluIHRoZSBzZWN0aW9uIGF0dHJpYnV0ZXMuIFNpbmNlIHRoZXJlIGFyZSByZWxvY2F0
aW9ucyBoZXJlLA0KPiAiLnJvZGF0YS4iIG1heSBub3QgYmUgdGhlIGNvcnJlY3QgcHJlZml4IHRv
IHVzZTsgaXQgbWF5IGluc3RlYWQgbmVlZCB0bw0KPiBiZSAiLmRhdGEucmVsLnJvLiIuDQpZb3Ug
bWF5IHJpZ2h0Lg0KRnJvbSAib2JqZHVtcCAtciB4ZW4vZHJpdmVycy92cGNpL21zaS5vIg0KSSBj
YW4gZ2V0DQoNClJFTE9DQVRJT04gUkVDT1JEUyBGT1IgWy5yb2RhdGEudnBjaV06DQpPRkZTRVQg
ICAgICAgICAgIFRZUEUgICAgICAgICAgICAgIFZBTFVFDQowMDAwMDAwMDAwMDAwMDAwIFJfWDg2
XzY0XzY0ICAgICAgIC5kYXRhLnJlbC5yby5sb2NhbC5pbml0X21zaV90DQoNCg0KUkVMT0NBVElP
TiBSRUNPUkRTIEZPUiBbLmRhdGEucmVsLnJvLmxvY2FsLmluaXRfbXNpX3RdOg0KT0ZGU0VUICAg
ICAgICAgICBUWVBFICAgICAgICAgICAgICBWQUxVRQ0KMDAwMDAwMDAwMDAwMDAwOCBSX1g4Nl82
NF82NCAgICAgICAudGV4dC5pbml0X21zaQ0KMDAwMDAwMDAwMDAwMDAxMCBSX1g4Nl82NF82NCAg
ICAgICAudGV4dC5jbGVhbnVwX21zaQ0KDQpBbmQgZnJvbSAib2JqZHVtcCAtRCB4ZW4vZHJpdmVy
cy92cGNpL21zaS5vIg0KSSBjYW4gZ2V0DQoNCkRpc2Fzc2VtYmx5IG9mIHNlY3Rpb24gLnJvZGF0
YS52cGNpOg0KDQowMDAwMDAwMDAwMDAwMDAwIDxpbml0X21zaV9lbnRyeT46DQogICAgICAgIC4u
Lg0KDQpEaXNhc3NlbWJseSBvZiBzZWN0aW9uIC5kYXRhLnJlbC5yby5sb2NhbC5pbml0X21zaV90
Og0KDQowMDAwMDAwMDAwMDAwMDAwIDxpbml0X21zaV90PjoNCiAgIDA6ICAgMDUgMDAgMDAgMDAg
MDAgICAgICAgICAgYWRkICAgICQweDAsJWVheA0KICAgICAgICAuLi4NCg0KPiANCj4gSmFuDQoN
Ci0tIA0KQmVzdCByZWdhcmRzLA0KSmlxaWFuIENoZW4uDQo=


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 09:05:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 09:05:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010628.1388775 (Exim 4.92)
	(envelope-from )
	id 1uOuul-0008Iq-SS; Tue, 10 Jun 2025 09:05:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010628.1388775; Tue, 10 Jun 2025 09:05:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uOuul-0008Ij-Oh; Tue, 10 Jun 2025 09:05:03 +0000
Received: by outflank-mailman (input) for mailman id 1010628;
 Tue, 10 Jun 2025 09:05: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 1uOuuj-0008Ib-BA
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 09:05:02 +0000
Received: from mail-10628.protonmail.ch (mail-10628.protonmail.ch
 [79.135.106.28]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f5fa4735-45d9-11f0-a306-13f23c93f187;
 Tue, 10 Jun 2025 11:04:48 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f5fa4735-45d9-11f0-a306-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1749546286; x=1749805486;
	bh=DIwHNIyJyDO2o6+soXYNXKpHOxv4wPgpvvjVZmBInwA=;
	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=KKTzLnmrUVGXTQLVJhYCYy+JVFtn1ihpGMuvFMUfDwwGq2qZlSW5fmD4JEjEytq15
	 I1Vr4jYT8q+nqelg71H+3pErM2gmngwoytJZ0xevbZDxr3yoOVUCA31gFZPy46g5ie
	 Ml3AhFCMpihsLae/LcTq+G31MIAC66eLpqcCgRf/BurNaCgkVme+GUAWFoXBD6SLnP
	 U1HfGrqCfWLYYR8i0q4w9PoATgwKaS8IAhxy6opMKAiN5fdzvMGElLivH1BQWBw8mk
	 w6zeG2bkpIXkC5mzwLWUrLN06YGYkj/1bWpkPT/3vXBisS9H4qs1dj6Vdi4ZwxK88g
	 itgIRYE7g+pdA==
Date: Tue, 10 Jun 2025 09:04:38 +0000
To: Jan Beulich 
From: dmkhn@proton.me
Cc: Julien Grall , andrew.cooper3@citrix.com, anthony.perard@vates.tech, roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v9 2/3] xen/domain: adjust domain ID allocation for Arm
Message-ID: 
In-Reply-To: <11ea9475-d963-473d-a85b-d1c461e7b213@suse.com>
References: <20250528225030.2652166-1-dmukhin@ford.com> <20250528225030.2652166-3-dmukhin@ford.com> <63087c42-d709-4e53-a2c3-8b812f13190a@xen.org>  <30c01c78-5a5e-435f-9b1c-faca3af04a76@suse.com>  <11ea9475-d963-473d-a85b-d1c461e7b213@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 31c2b238e99ddfa0cd44fb470db9b5c8f139185d
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 10, 2025 at 10:26:22AM +0200, Jan Beulich wrote:
> On 10.06.2025 10:02, dmkhn@proton.me wrote:
> > On Tue, Jun 10, 2025 at 08:53:12AM +0200, Jan Beulich wrote:
> >> On 06.06.2025 23:29, Julien Grall wrote:
> >>> Hi Denis,
> >>>
> >>> On 05/06/2025 23:05, Julien Grall wrote:
> >>>> Hi Denis,
> >>>>
> >>>> On 28/05/2025 23:50, dmkhn@proton.me wrote:
> >>>>> From: Denis Mukhin 
> >>>>>
> >>>>> From: Denis Mukhin 
> >>>>>
> >>>>> Remove the hardcoded domain ID 0 allocation for hardware domain and=
 replace it
> >>>>> with a call to get_initial_domain_id() (returns the value of hardwa=
re_domid on
> >>>>> Arm).
> >>>>
> >>>> I am not entirely why this is done. Are you intending to pass a diff=
erent domain ID? If so...
> >>>>
> >>>>>
> >>>>> Update domid_alloc(DOMID_INVALID) case to ensure that get_initial_d=
omain_id()
> >>>>> ID is skipped during domain ID allocation to cover domU case in dom=
0less
> >>>>> configuration. That also fixes a potential issue with re-using ID#0=
 for domUs
> >>>>> when get_initial_domain_id() returns non-zero.
> >>>>>
> >>>>> Signed-off-by: Denis Mukhin 
> >>>>> ---
> >>>>> Changes since v8:
> >>>>> - rebased
> >>>>> ---
> >>>>> =C2=A0 xen/arch/arm/domain_build.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | 4 ++--
> >>>>> =C2=A0 xen/common/device-tree/dom0less-build.c | 9 +++------
> >>>>> =C2=A0 xen/common/domain.c=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 | 4 ++--
> >>>>> =C2=A0 3 files changed, 7 insertions(+), 10 deletions(-)
> >>>>>
> >>>>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_buil=
d.c
> >>>>> index e9d563c269..0ad80b020a 100644
> >>>>> --- a/xen/arch/arm/domain_build.c
> >>>>> +++ b/xen/arch/arm/domain_build.c
> >>>>> @@ -2035,9 +2035,9 @@ void __init create_dom0(void)
> >>>>
> >>>> ... naming like create_dom0() probably wants to be renamed.
> >>>>
> >>>> That said, I am not convinced a domain other than 0 should have full=
 privilege by default. So I would argue it should stay as ...
> >>>>
> >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if ( !llc_coloring_enabled )
> >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 flags |=3D C=
DF_directmap;
> >>>>> -=C2=A0=C2=A0=C2=A0 domid =3D domid_alloc(0);
> >>>>> +=C2=A0=C2=A0=C2=A0 domid =3D domid_alloc(get_initial_domain_id());
> >>>>
> >>>> ... 0.
> >>>
> >>> Looking at the implementation of get_initial_domain_id(), I noticed t=
he behavior was changed for x86 by [1].
> >>>
> >>> Before, get_initial_domain_id() was returning 0 except for the PV shi=
m.
> >>> But now, it would could return the domain ID specified on the command=
 line (via hardware_dom).
> >>>
> >>> From my understanding, the goal of the command line was to create the=
 hardware domain *after* boot. So initially we create dom0 and then initial=
ize the hardware domain. With the patch below, this has changed.
> >>>
> >>> However, from the commit message, I don't understand why. It seems li=
ke we broke late hwdom?
> >>>
> >>> For instance, late_hwdom_init() has the following assert:
> >>>
> >>> =C2=A0=C2=A0=C2=A0 dom0 =3D rcu_lock_domain_by_id(0);
> >>> =C2=A0=C2=A0=C2=A0 ASSERT(dom0 !=3D NULL);
> >>>
> >>> Jan, I saw you were involved in the review of the series. Any idea wh=
y this was changed?
> >>
> >> I simply overlooked this aspect when looking at the change. You're rig=
ht, things
> >> were broken there. Unless a simple and clean fix can be made relativel=
y soon, I
> >> think this simply needs reverting (which may mean to revert any later =
commits
> >> that depend on that). I can't help noting that in this console rework =
there were
> >> way too many issues, and I fear more than just this one may have slipp=
ed
> >> through. I therefore wonder whether taken as a whole this was/is worth=
 both the
> >> submitter's and all the reviewers' time.
> >
> > Yes, sorry, I overlooked late_hwdom_init() modification.
> >
> > IMO, the clean fix would be adding another command line parameter
> > `control_domid` (with default value 0), make get_initial_domain_id() re=
turn it
> > instead of current `hardware_domid` and update late_hwdom_init() to use
> > `control_domid` insted of open-coded 0.
>=20
> No, no new command line option will address this. Original behavior needs=
 to be
> restored (either by correcting the earlier change or, as said, be reverti=
ng).

Correction of the earlier change:

  https://gitlab.com/xen-project/people/dmukhin/xen/-/commit/b7f194650307a0=
8a9e6da5aa9fdd1f8a9afd67eb

re: command line option: I meant something like this:

  https://gitlab.com/xen-project/people/dmukhin/xen/-/commit/51a519de6ea73f=
f3b650fd9bd4f3c5c63f64c069

>=20
> Jan



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 09:33:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 09:33:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010639.1388785 (Exim 4.92)
	(envelope-from )
	id 1uOvMS-00046K-1L; Tue, 10 Jun 2025 09:33:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010639.1388785; Tue, 10 Jun 2025 09: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 1uOvMR-00046D-UN; Tue, 10 Jun 2025 09:33:39 +0000
Received: by outflank-mailman (input) for mailman id 1010639;
 Tue, 10 Jun 2025 09:33: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 1uOvMP-000466-Ux
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 09:33:38 +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 faaa7546-45dd-11f0-a306-13f23c93f187;
 Tue, 10 Jun 2025 11:33:35 +0200 (CEST)
Received: from SA0PR13CA0001.namprd13.prod.outlook.com (2603:10b6:806:130::6)
 by IA1PR12MB9032.namprd12.prod.outlook.com (2603:10b6:208:3f3::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Tue, 10 Jun
 2025 09:33:29 +0000
Received: from SA2PEPF00003F64.namprd04.prod.outlook.com
 (2603:10b6:806:130:cafe::1e) by SA0PR13CA0001.outlook.office365.com
 (2603:10b6:806:130::6) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.12 via Frontend Transport; Tue,
 10 Jun 2025 09:33:29 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SA2PEPF00003F64.mail.protection.outlook.com (10.167.248.39) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Tue, 10 Jun 2025 09:33:28 +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; Tue, 10 Jun
 2025 04:33:28 -0500
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; Tue, 10 Jun
 2025 04:33:28 -0500
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 Jun 2025 04:33:27 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: faaa7546-45dd-11f0-a306-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=yEakf3QKw9GiWu0QDfnxnjWA+Tv9QnJFNDqXBnnMqMs2aynvS8auhnGwuMxVlcWKuD5uw2VLFWFrESfRF2JZFnxFv120jFveY2vhYrCRd1GT92XYkRz1L02UqGt7WJZEc0428m3XIHzYyDER32nN33RGTIn407JEetx4AC+yA1nx2hTTMsKCnf12YkruS7bOcuwVO9h03wA69qsWhMNO+ptSGybmA6YjMEJqk9tjuB6ASTHn+RDGGEH+wrDrGsM6pL+dR1speot8Hk5tY5tT/0aEVFBL5f6z9nuSj+Ca5tIHRoBxdTUm625GaBTmunURGNfd+UcTWvnbhf8dTjxa3g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=yvFNUsnb2CLbk+fKZWtVqD96AkaMpEGpKR+v0a3kJRM=;
 b=RtvaSecFqmRGz67kUlx3GYJUMXncdGJL3X2oCduofhL1Cf9SOAeuRt8e3bgSAwg82WIUU6ei3mhUdxnBXfH9Efbjl9iSJAsl3Unk+3ZmGRWJtGAFU3ZEQon2egxTrCjyyqk5rOXnzvWbtLsD7rGJatDGl84tEDbqW27Sy4bhMV5ilc7PwUpQTnN4TEAOyhuJa9Z/IKDc2l/XpBrxDbJ1BMzHhShqZPl4VjLksREXuX/oCkwXB5q+LwB6eZ5YEI6EbgumkdCpusqKHNLyhWnWrXY1ZwMi+yPg6m2sGEc/cT4eKy0PxxfoO+ANEzgYbYfK1ElsWDjraMJxEr5XieqZTw==
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=yvFNUsnb2CLbk+fKZWtVqD96AkaMpEGpKR+v0a3kJRM=;
 b=wdVC3N6zJusZ1IyoU3tF/jrzQc/2nf26ZE41sZYLvl18Q4C+EpZBWqE8ay22RtBB96/2m7e8MIHM95SRZMST1fBygwIG6ykutuZ7p5vh52M/hI0vCgvdghGNhLz3Rg0QeaY4cX7XH3wP+1xVgRwTZvA6hdNPOoT4+pHAR6H4dVs=
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 , Anthony PERARD
	
Subject: [PATCH] helpers: init-dom0less: Drop libxenevtchn from LDLIBS
Date: Tue, 10 Jun 2025 11:33:26 +0200
Message-ID: <20250610093326.114529-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 (SATLEXMB05.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SA2PEPF00003F64:EE_|IA1PR12MB9032:EE_
X-MS-Office365-Filtering-Correlation-Id: 1124bcfa-7bb7-4982-d297-08dda801db73
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?M8KOWfIPDSJYQDOvimLtxEGuwz0bUfZE+ri6FkbGZsGrqrjN/s119gbNtIDQ?=
 =?us-ascii?Q?OdR8J8/c5ZnybdfX9fXdI54wdx4Vos0lAQceM+Ye7Tybq4DaNd017FrP8tJQ?=
 =?us-ascii?Q?mAU/U0eqNW7fEkNnne/altbN4gUnFSxKotcZto3e1ak/kB8w801pdJlcan/M?=
 =?us-ascii?Q?4/gle5Y23mWuS2bBKwEAWxzr6eX152BH18sj9yW3XdGTc6+w45hv7dIJqQre?=
 =?us-ascii?Q?ilm/AnX+BdMntqIs2vPP7v5IPXaacf8+GTMQ2ssl//aeHUSFBYc0EqVtVVVT?=
 =?us-ascii?Q?n3K1DJsnavmckNlTDUT8u2G/Bug2GL1dOhbDB5Kl9WrYoF6dL1X3P0/XjPZ6?=
 =?us-ascii?Q?SKSQU24G2SjNvUrcVwaP5rCXpjG+4ZZA99hl/HtszImBgdKWDcM4ZprpKjUQ?=
 =?us-ascii?Q?wtf9Njm8D6d3TwHTbCccOJG47ktwpsHnxxr79TmhEWVUawjYwKS+8Ha4SCAV?=
 =?us-ascii?Q?HCkQgMd7pVRUU3jwqg8vLvRwkRLZWwg6qgl6V3w8yRndlVO1FxtPOTCzMl3Z?=
 =?us-ascii?Q?1x1tUY3AJT8GpERsKFhBQ3pypH9w3q/L5dKZ0ZrFAIhtnIctBet3IynWvXFI?=
 =?us-ascii?Q?YiOWrjhtx7OkDycXp0jlQEs3rLzCH7y6u49S6i3y+OMXPsKGZied8n3lyPx5?=
 =?us-ascii?Q?mBEp8OvxxwH8e/cRuXXrQ4+zyC7bXYmt7TXtB3LL22JrS2WnZjOzSKOJDX2Q?=
 =?us-ascii?Q?t0XPlLZC7rP9B7jlGgPNiV+UIPC5/pxhneIHDGbvC8yo4EeMiEmnNcXjZnW2?=
 =?us-ascii?Q?IGlqGb7B54bO+8AfktvIVzuy8tXHkUmE4a4VC4bwefRu/YM5QMgs7QLq1d8z?=
 =?us-ascii?Q?eOmhPtwX1YP7H7MhMtJkA0fFD43VzsIUbHnr91Y3SqePUUh7PLOnaIo0T1qa?=
 =?us-ascii?Q?O7WhtPYWFpMnicW4k7K/YibR/yHkrIaVhB6/8lOG1ISJ4mPIThtJVI4f+2D/?=
 =?us-ascii?Q?05iRTco3SNwNnsb+vCUScfAsMESdm4mHUfaOtSkARCZrGvOxe85bH5MdSD64?=
 =?us-ascii?Q?R6CWyDKyNJyuKoqyCKlvxig21gIRZGAL778+utrbBhsQPn3NPwCyLFP7o/y6?=
 =?us-ascii?Q?VorAOI3mj+BrvurTMkiGJXO6d7uRwTn7lFG5l1YkkoGTJu+V1ssfdeIf5rh3?=
 =?us-ascii?Q?/OrlTucLfQE7PWrL1giDhYRZgXAOdXztWK16g/N9CwAdpxmOuVIShfhQbikP?=
 =?us-ascii?Q?MwTjijgOlApYy9FxQk9ObziEQvNTj70BB4QjolsWRUhkFwCIjjZOIoWYITjD?=
 =?us-ascii?Q?cbLFkOt9Xg+OnkkbUZ9/VGsD6reitklK6yzyUwtWIZLRJ2pXk764urpCqk89?=
 =?us-ascii?Q?I9s0nBazs4TGcxHEFeUgqN/ohoXUhmAfy6d/h9taTlsJ3ch4qQuS4g3bhX7M?=
 =?us-ascii?Q?dGfQcCxtta/RJ13Y8V4pOV6oQXIEWeMgU39NxdpaCCRDE9M+NsHQ4CN2COO1?=
 =?us-ascii?Q?niFLdUSM9df7LFvlW0cGzY5Sk9CVkBI1rxMrL+MRax67MpgcitAzGx7IlNER?=
 =?us-ascii?Q?lYDTHFSPQsrmfGuwxbnI+eyD1IeSPan2OZFL?=
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: 10 Jun 2025 09:33:28.5967
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1124bcfa-7bb7-4982-d297-08dda801db73
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:
	SA2PEPF00003F64.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB9032

It hasn't been used since the introduction of the script. Also drop
relevant CFLAGS and header inclusion.

Signed-off-by: Michal Orzel 
---
 tools/helpers/Makefile        | 3 +--
 tools/helpers/init-dom0less.c | 1 -
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/tools/helpers/Makefile b/tools/helpers/Makefile
index 09590eb5b6f0..8262d9e75a2c 100644
--- a/tools/helpers/Makefile
+++ b/tools/helpers/Makefile
@@ -36,8 +36,7 @@ $(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxentoollog)
 $(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxenstore)
 $(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxenlight)
 $(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxenctrl)
-$(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxenevtchn)
-init-dom0less: LDLIBS += $(call xenlibs-ldlibs,ctrl evtchn toollog store light guest foreignmemory)
+init-dom0less: LDLIBS += $(call xenlibs-ldlibs,ctrl toollog store light guest foreignmemory)
 
 .PHONY: all
 all: $(TARGETS)
diff --git a/tools/helpers/init-dom0less.c b/tools/helpers/init-dom0less.c
index 91edf17b6cef..a182dce56353 100644
--- a/tools/helpers/init-dom0less.c
+++ b/tools/helpers/init-dom0less.c
@@ -10,7 +10,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 09:45:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 09:45:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010646.1388794 (Exim 4.92)
	(envelope-from )
	id 1uOvXN-0005nw-0O; Tue, 10 Jun 2025 09:44:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010646.1388794; Tue, 10 Jun 2025 09:44:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uOvXM-0005np-UD; Tue, 10 Jun 2025 09:44:56 +0000
Received: by outflank-mailman (input) for mailman id 1010646;
 Tue, 10 Jun 2025 09:44:55 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uOvXL-0005nd-HU
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 09:44:55 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uOvX7-00BvNa-1y;
 Tue, 10 Jun 2025 09:44:41 +0000
Received: from [15.248.2.232] (helo=[10.24.66.12])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uOvX7-00CyiR-14;
 Tue, 10 Jun 2025 09:44: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" 
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=s8k0A/3N1dTxtmQ1Y1+hGkVqR12l8gHfFGNYVRJu8V8=; b=s+wELxFrv4EvgD/7tpsraHmmQX
	bLwHUhIEtRV0ZhC03snd1Cn6YO07T3AMs+K332BEwZUOxU98E/2NoiOpwJKFNt3ATZM+7V8EZgqC4
	C2klS5VCi+fETM5NktipSHmHepuyusoebRetQyb2dzVlhRDZhxyUTjB9JuwQuwxxnF/I=;
Message-ID: <61e2ae99-041b-4c8c-81bb-c86b5cee936e@xen.org>
Date: Tue, 10 Jun 2025 10:44:39 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 2/3] xen/domain: adjust domain ID allocation for Arm
Content-Language: en-GB
To: dmkhn@proton.me, Jan Beulich 
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech,
 roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech,
 dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250528225030.2652166-1-dmukhin@ford.com>
 <20250528225030.2652166-3-dmukhin@ford.com>
 <63087c42-d709-4e53-a2c3-8b812f13190a@xen.org>
 
 <30c01c78-5a5e-435f-9b1c-faca3af04a76@suse.com> 
 <11ea9475-d963-473d-a85b-d1c461e7b213@suse.com> 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Denis,

On 10/06/2025 10:04, dmkhn@proton.me wrote:
> On Tue, Jun 10, 2025 at 10:26:22AM +0200, Jan Beulich wrote:
>> On 10.06.2025 10:02, dmkhn@proton.me wrote:
>>> On Tue, Jun 10, 2025 at 08:53:12AM +0200, Jan Beulich wrote:
>>>> On 06.06.2025 23:29, Julien Grall wrote:
>>>>> Hi Denis,
>>>>>
>>>>> On 05/06/2025 23:05, Julien Grall wrote:
>>>>>> Hi Denis,
>>>>>>
>>>>>> On 28/05/2025 23:50, dmkhn@proton.me wrote:
>>>>>>> From: Denis Mukhin 
>>>>>>>
>>>>>>> From: Denis Mukhin 
>>>>>>>
>>>>>>> Remove the hardcoded domain ID 0 allocation for hardware domain and replace it
>>>>>>> with a call to get_initial_domain_id() (returns the value of hardware_domid on
>>>>>>> Arm).
>>>>>>
>>>>>> I am not entirely why this is done. Are you intending to pass a different domain ID? If so...
>>>>>>
>>>>>>>
>>>>>>> Update domid_alloc(DOMID_INVALID) case to ensure that get_initial_domain_id()
>>>>>>> ID is skipped during domain ID allocation to cover domU case in dom0less
>>>>>>> configuration. That also fixes a potential issue with re-using ID#0 for domUs
>>>>>>> when get_initial_domain_id() returns non-zero.
>>>>>>>
>>>>>>> Signed-off-by: Denis Mukhin 
>>>>>>> ---
>>>>>>> Changes since v8:
>>>>>>> - rebased
>>>>>>> ---
>>>>>>>    xen/arch/arm/domain_build.c             | 4 ++--
>>>>>>>    xen/common/device-tree/dom0less-build.c | 9 +++------
>>>>>>>    xen/common/domain.c                     | 4 ++--
>>>>>>>    3 files changed, 7 insertions(+), 10 deletions(-)
>>>>>>>
>>>>>>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>>>>>>> index e9d563c269..0ad80b020a 100644
>>>>>>> --- a/xen/arch/arm/domain_build.c
>>>>>>> +++ b/xen/arch/arm/domain_build.c
>>>>>>> @@ -2035,9 +2035,9 @@ void __init create_dom0(void)
>>>>>>
>>>>>> ... naming like create_dom0() probably wants to be renamed.
>>>>>>
>>>>>> That said, I am not convinced a domain other than 0 should have full privilege by default. So I would argue it should stay as ...
>>>>>>
>>>>>>>        if ( !llc_coloring_enabled )
>>>>>>>            flags |= CDF_directmap;
>>>>>>> -    domid = domid_alloc(0);
>>>>>>> +    domid = domid_alloc(get_initial_domain_id());
>>>>>>
>>>>>> ... 0.
>>>>>
>>>>> Looking at the implementation of get_initial_domain_id(), I noticed the behavior was changed for x86 by [1].
>>>>>
>>>>> Before, get_initial_domain_id() was returning 0 except for the PV shim.
>>>>> But now, it would could return the domain ID specified on the command line (via hardware_dom).
>>>>>
>>>>>  From my understanding, the goal of the command line was to create the hardware domain *after* boot. So initially we create dom0 and then initialize the hardware domain. With the patch below, this has changed.
>>>>>
>>>>> However, from the commit message, I don't understand why. It seems like we broke late hwdom?
>>>>>
>>>>> For instance, late_hwdom_init() has the following assert:
>>>>>
>>>>>      dom0 = rcu_lock_domain_by_id(0);
>>>>>      ASSERT(dom0 != NULL);
>>>>>
>>>>> Jan, I saw you were involved in the review of the series. Any idea why this was changed?
>>>>
>>>> I simply overlooked this aspect when looking at the change. You're right, things
>>>> were broken there. Unless a simple and clean fix can be made relatively soon, I
>>>> think this simply needs reverting (which may mean to revert any later commits
>>>> that depend on that). I can't help noting that in this console rework there were
>>>> way too many issues, and I fear more than just this one may have slipped
>>>> through. I therefore wonder whether taken as a whole this was/is worth both the
>>>> submitter's and all the reviewers' time.
>>>
>>> Yes, sorry, I overlooked late_hwdom_init() modification.
>>>
>>> IMO, the clean fix would be adding another command line parameter
>>> `control_domid` (with default value 0), make get_initial_domain_id() return it
>>> instead of current `hardware_domid` and update late_hwdom_init() to use
>>> `control_domid` insted of open-coded 0.
>>
>> No, no new command line option will address this. Original behavior needs to be
>> restored (either by correcting the earlier change or, as said, be reverting).
> 
> Correction of the earlier change:
> 
>    https://gitlab.com/xen-project/people/dmukhin/xen/-/commit/b7f194650307a08a9e6da5aa9fdd1f8a9afd67eb
> 
> re: command line option: I meant something like this:
> 
>    https://gitlab.com/xen-project/people/dmukhin/xen/-/commit/51a519de6ea73ff3b650fd9bd4f3c5c63f64c069

I am with Jan here. This used to work before without "control_domid", so 
we ought to keep the same.

But even if we are ok to break compatibility, I don't see the value of 
"control_domid". The implication of setting "hardware_domid" is you will
have a separate control domain. At which point, why would it matter to 
specify the domain ID?

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 10:10:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 10:10:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010656.1388805 (Exim 4.92)
	(envelope-from )
	id 1uOvvb-0000KZ-3P; Tue, 10 Jun 2025 10:09:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010656.1388805; Tue, 10 Jun 2025 10:09:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uOvvb-0000KS-06; Tue, 10 Jun 2025 10:09:59 +0000
Received: by outflank-mailman (input) for mailman id 1010656;
 Tue, 10 Jun 2025 10:09: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 1uOvvZ-0000KF-Gc
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 10:09:57 +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 0ebde172-45e3-11f0-a306-13f23c93f187;
 Tue, 10 Jun 2025 12:09:55 +0200 (CEST)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3a531fcaa05so2030219f8f.3
 for ; Tue, 10 Jun 2025 03:09:55 -0700 (PDT)
Received: from [192.168.86.29] ([90.250.112.104])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a53244d10asm12053875f8f.67.2025.06.10.03.09.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 03:09:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0ebde172-45e3-11f0-a306-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749550195; x=1750154995; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=1u6iuOa6M6QPWsueTr5oZj/pv/UfFtzP76b/eOBfaXw=;
        b=Afb6r3gGEgh9q7IkMt6VfXXHm07P1SNfHudxylRHR5UWzgp5373AmDRm9DlbnK0gFs
         kZS1j8rSCqkN1WiXvfYey6PKjFkShpXeqaKwxvlWVzP1RnDRnbNCFs6bMrKGSrJmdDxK
         zJ64UqzspLwOC4v954zaXRZmnNZinyAtGiCms=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749550195; x=1750154995;
        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=1u6iuOa6M6QPWsueTr5oZj/pv/UfFtzP76b/eOBfaXw=;
        b=GR0pvfMrsAgk2OL3gx1Iu+UI6UOKM1RNT8c/7Hyf9KqMHwURT5JRs0xYuqk+rsnbf4
         g6ABhnus8taMbB7Yolrz98rfTO7UbfgBDGGCe3WN4OfPYx3zM5IC220z6wc4k1JC1vrO
         ES+67JxEZKqBKRryG0HimBwKC+c/o2Em4z1wfQc+risPh4z+a/fOb1hLeCNymdGiQu0g
         JTdLqgNgwruBsRFhTZhDsYTdzdyAup8frtAI1gReeKWANRbQP4t5eTZj1L03csUJ8t49
         OZt/x0qB+JPaUGLgGRLL9ob/32EptZziR0cbmg3IptDU67RExuYcTVEQukRYohHuWm4l
         WFDQ==
X-Forwarded-Encrypted: i=1; AJvYcCXpgTfqSqVBFIFkL+Ns+wSYqZ0kbeBi9qapdeS7V9jCE6IlD2D6m11ZJ2b0imp/X8Kgvu9ToZVUaBY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxgBr1lZMXJB604riAH9hCBlysTyU9BQGUE5dnm6nc375e3t562
	1bFs6ArNZSCS6MKtiBqY53wVdX7s/i1IMb2veriNAJx6Q68Ba5o3EJxnPsMYtleOFxE=
X-Gm-Gg: ASbGncsElfuQ4dUIisJkXn/S9VnNWvQN7pEvqYDnc8IGX7ziMuUc1GAYg8bEdPB+sRf
	p96xXVv3liAtj52EXJlZ3au/EEZojM+OKcH35GwptxY+L9y0xzGf4gUEBhSDBKtEn6wSlJNQrI9
	Mec3HinjoyphzORwMnEOlFR2iO87nmrXOD8u+EhCb5tR1QR1DIqHhjJuOppN3gnFdgJtFvO31yP
	F7bTf1j8mUpXPGwuavMbjqXVm+8uSe5YFR7OHLxpmr1beG7mi7WfdeJFAwubqQgy3tBL0Spow0O
	zBjU1DQfI2YuGyvj2gQhfkCD70Jsz5HgpAaSnUE/rZ5Dvyz2MApSXM4XqewOTDGgicAPJZGpnnE
	cfyx8L0KzQg==
X-Google-Smtp-Source: AGHT+IEFpyIVHpA67iWh1FOCxj8cE3D7laDEIJNZ1L6vKk9JmjsUCJpIzVwnnnN7PyRG9C3hbypdQw==
X-Received: by 2002:a05:6000:24c7:b0:3a4:eb80:762d with SMTP id ffacd0b85a97d-3a531ced4d6mr12908891f8f.56.1749550195065;
        Tue, 10 Jun 2025 03:09:55 -0700 (PDT)
Message-ID: <3a71f308-2398-4fa1-96d7-d4fe13052c20@citrix.com>
Date: Tue, 10 Jun 2025 11:09:54 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] helpers: init-dom0less: Drop libxenevtchn from LDLIBS
To: Michal Orzel , xen-devel@lists.xenproject.org
Cc: Anthony PERARD 
References: <20250610093326.114529-1-michal.orzel@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: <20250610093326.114529-1-michal.orzel@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10/06/2025 10:33 am, Michal Orzel wrote:
> It hasn't been used since the introduction of the script. Also drop
> relevant CFLAGS and header inclusion.
>
> Signed-off-by: Michal Orzel 

Acked-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 10:12:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 10:12:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010661.1388816 (Exim 4.92)
	(envelope-from )
	id 1uOvyQ-0001r6-GH; Tue, 10 Jun 2025 10:12:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010661.1388816; Tue, 10 Jun 2025 10:12: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 1uOvyQ-0001qz-CO; Tue, 10 Jun 2025 10:12:54 +0000
Received: by outflank-mailman (input) for mailman id 1010661;
 Tue, 10 Jun 2025 10: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 1uOvyO-0001qs-Pm
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 10:12:52 +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 7701616b-45e3-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 12:12:50 +0200 (CEST)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-450cfb6a794so33979105e9.1
 for ; Tue, 10 Jun 2025 03:12:50 -0700 (PDT)
Received: from localhost.localdomain (188.226.6.51.dyn.plus.net.
 [51.6.226.188]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45213709686sm137066145e9.23.2025.06.10.03.12.48
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 10 Jun 2025 03:12:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7701616b-45e3-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749550370; x=1750155170; 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=XelYdTZNWda+2F9NGJi8mxW1Fq92OkooZLmF3hYL8Dk=;
        b=VYSxk9xrs3IYp5zJgklcmGul2zYgh4NLFc924XUENSZax3fbEQLhxivS2n9Ywx/CLI
         Cd76U5CnHvpXYi+UPjUF6FG3oF07+9PZjzDIsaOHn+HhEILFins3Z4MZfQzssZYxXCWs
         5X29K59s1vpNMYF8ZnL4RcdCXZE1bDiMrdCW+mkPnRtI5pjuITVLbbx3bYNMPHsvSqPE
         QIF6gs5Lt+prFFA+LyuNm5Dd2b/rStt4cYMY1mXWntjzYbIErLxYsds7QDm0Nb47/25I
         2M4/bnwH3HIePt5/YELNPunv2++7P/g63Xm5bfNMvRGS9+ACcCcWr20GM+9e6cD8V2bL
         sxig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749550370; x=1750155170;
        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=XelYdTZNWda+2F9NGJi8mxW1Fq92OkooZLmF3hYL8Dk=;
        b=uWyVQk4NEElOaMV/okYcs1wg+3zwd6c5bAwEwDAYT/eYiZuwxVXvPIHhZ/XU9KG7on
         iEpmx1cNiYAJu2uyBd490I9eU6qSpH4TcVLtZFTJ65oPxoQsGgDlS2zVGyjqeOxLrgvt
         Yk1VtVQiAHM3kEZG2InTUDqc5IgNx44S2IXC9S/j/LmsZhvCCWH/MgKF19CtjuP64U88
         QnTmIwLQBS7LsgD6i9lyRcrqNweTIEkuZLC5VrzElwNZt12m0JFMCkc0RBiVMg0xIMTp
         c9gF/9FIH78Wyy4ClfTbU7oqRsyTHFWi0eChprady8JkN7NDRlnrj05FSpJ+VxvcO4oI
         fRiQ==
X-Gm-Message-State: AOJu0YzZfRYbLHERk4JQiDFJpivHqv4Bd7dlGwaKpzgAWDUyl93d1vs8
	PDCLPI7cXE7aSlpmD/wK2bibBp0OTMYqLfcvWx2j4GdMWPuGuq+czSl2TiMIb1f4
X-Gm-Gg: ASbGncu74zV9oo3d2Pk+aR8LlKPtKNo333Cv1KIEPreJilCulKHeYdK40aHfyK2+JIt
	W8sX/Jtp+C2mElzO4g0XeKKh8J08pJ0KSCgvfAwYwq7mlsFMj2q6hx0dYftHgp0DIVrdB88fwCX
	62zo/+a1UqrDIlKfFwn0Hh7JalFTXFyjOHcc8WwUPUCTsbHDRCqp8QgzuHWmVXpbA5dZ16T1ps0
	JwLy/61eijdfJiryjtij+uh6137dE3CxYlb1lySy0Q1b9wyKflbSXcZeYRj4lWzTh6qpqZPPcnK
	gN3TUFsMSyxsxpbpldejIp8bn8Rkr2pR7DIIaS5iVg4OH7EcYyvGDF/dGoUBXOnuX+uiwLDIPsy
	d1PBgLg8liku1ksZszKA6d7VlGcuUEYk=
X-Google-Smtp-Source: AGHT+IFidtGkkIAHlMh7sKk3uc+NT0X+ECpEPn5k3a2CU0xUMCzdMkB3BLdjl1nED04TsM1UztkTiA==
X-Received: by 2002:a05:600c:64c6:b0:43c:fceb:91a with SMTP id 5b1f17b1804b1-4531de0093emr18729805e9.11.1749550369654;
        Tue, 10 Jun 2025 03:12:49 -0700 (PDT)
From: Frediano Ziglio 
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH] xen: Strip xen.efi by default
Date: Tue, 10 Jun 2025 11:12:25 +0100
Message-ID: <20250610101228.24460-1-freddy77@gmail.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

For xen.gz file we strip all symbols and have an additional
xen-syms file version with all symbols.
Make xen.efi more coherent stripping all symbols too.
xen.efi.elf can be used for debugging.

Signed-off-by: Frediano Ziglio 
---
 docs/misc/efi.pandoc  |  8 +-------
 xen/Kconfig.debug     |  9 ++-------
 xen/Makefile          | 19 -------------------
 xen/arch/x86/Makefile |  1 +
 4 files changed, 4 insertions(+), 33 deletions(-)

diff --git a/docs/misc/efi.pandoc b/docs/misc/efi.pandoc
index 11c1ac3346..c66b18a66b 100644
--- a/docs/misc/efi.pandoc
+++ b/docs/misc/efi.pandoc
@@ -20,13 +20,7 @@ Xen to load the configuration file even if multiboot modules are found.
 Once built, `make install-xen` will place the resulting binary directly into
 the EFI boot partition, provided `EFI_VENDOR` is set in the environment (and
 `EFI_MOUNTPOINT` is overridden as needed, should the default of `/boot/efi` not
-match your system). When built with debug info, the binary can be quite large.
-Setting `INSTALL_EFI_STRIP=1` in the environment will cause it to be stripped
-of debug info in the process of installing. `INSTALL_EFI_STRIP` can also be set
-to any combination of options suitable to pass to `strip`, in case the default
-ones don't do. The xen.efi binary will also be installed in `/usr/lib64/efi/`,
-unless `EFI_DIR` is set in the environment to override this default. This
-binary will not be stripped in the process.
+match your system).
 
 The binary itself will require a configuration file (names with the `.efi`
 extension of the binary's name replaced by `.cfg`, and - until an existing
diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index d14093017e..cafbb1236c 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -147,12 +147,7 @@ config DEBUG_INFO
 	  Say Y here if you want to build Xen with debug information. This
 	  information is needed e.g. for doing crash dump analysis of the
 	  hypervisor via the "crash" tool.
-	  Saying Y will increase the size of the xen-syms and xen.efi
-	  binaries. In case the space on the EFI boot partition is rather
-	  limited, you may want to install a stripped variant of xen.efi in
-	  the EFI boot partition (look for "INSTALL_EFI_STRIP" in
-	  docs/misc/efi.pandoc for more information - when not using
-	  "make install-xen" for installing xen.efi, stripping needs to be
-	  done outside the Xen build environment).
+	  Saying Y will increase the size of the xen-syms and xen.efi.elf
+	  binaries.
 
 endmenu
diff --git a/xen/Makefile b/xen/Makefile
index 8fc4e042ff..664c4ea7b8 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -488,22 +488,6 @@ endif
 .PHONY: _build
 _build: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
 
-# Strip
-#
-# INSTALL_EFI_STRIP, if defined, will cause xen.efi to be stripped before it
-# is installed. If INSTALL_EFI_STRIP is '1', then the default option(s) below
-# will be used. Otherwise, INSTALL_EFI_STRIP value will be used as the
-# option(s) to the strip command.
-ifdef INSTALL_EFI_STRIP
-
-ifeq ($(INSTALL_EFI_STRIP),1)
-efi-strip-opt := --strip-debug --keep-file-symbols
-else
-efi-strip-opt := $(INSTALL_EFI_STRIP)
-endif
-
-endif
-
 .PHONY: _install
 _install: D=$(DESTDIR)
 _install: T=$(notdir $(TARGET))
@@ -530,9 +514,6 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
 		ln -sf $(T)-$(XEN_FULLVERSION).efi $(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).efi; \
 		ln -sf $(T)-$(XEN_FULLVERSION).efi $(D)$(EFI_DIR)/$(T).efi; \
 		if [ -n '$(EFI_MOUNTPOINT)' -a -n '$(EFI_VENDOR)' ]; then \
-			$(if $(efi-strip-opt), \
-			     $(STRIP) $(efi-strip-opt) -p -o $(TARGET).efi.stripped $(TARGET).efi && \
-			     $(INSTALL_DATA) $(TARGET).efi.stripped $(D)$(EFI_MOUNTPOINT)/efi/$(EFI_VENDOR)/$(T)-$(XEN_FULLVERSION).efi ||) \
 			$(INSTALL_DATA) $(TARGET).efi $(D)$(EFI_MOUNTPOINT)/efi/$(EFI_VENDOR)/$(T)-$(XEN_FULLVERSION).efi; \
 		elif [ "$(D)" = "$(patsubst $(shell cd $(XEN_ROOT) && pwd)/%,%,$(D))" ]; then \
 			echo 'EFI installation only partially done (EFI_VENDOR not set)' >&2; \
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index ce724a9daa..725bcef340 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -238,6 +238,7 @@ endif
 		> $@.map
 ifeq ($(CONFIG_DEBUG_INFO),y)
 	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) -O elf64-x86-64 $@ $@.elf
+	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(STRIP) $@
 endif
 	rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]*
 ifeq ($(CONFIG_XEN_IBT),y)
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 10:17:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 10:17:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010671.1388824 (Exim 4.92)
	(envelope-from )
	id 1uOw3G-0002UX-3G; Tue, 10 Jun 2025 10:17:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010671.1388824; Tue, 10 Jun 2025 10:17: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 1uOw3G-0002UQ-0Q; Tue, 10 Jun 2025 10:17:54 +0000
Received: by outflank-mailman (input) for mailman id 1010671;
 Tue, 10 Jun 2025 10:17: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 1uOw3E-0002UK-MJ
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 10:17: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 27f8917c-45e4-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 12:17:47 +0200 (CEST)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-45300c82c1cso9158055e9.3
 for ; Tue, 10 Jun 2025 03:17:47 -0700 (PDT)
Received: from [192.168.86.29] ([90.250.112.104])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a53244fd02sm11764767f8f.75.2025.06.10.03.17.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 03:17:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 27f8917c-45e4-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749550667; x=1750155467; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Lt6sfVsVl+j8zM2leOn1EGSSGr7V6Z/TllTIx5l3vS4=;
        b=q7uMp9nO5OUBOAFMrb7orSQn2/TOUHGpyUtW91CxMwGqZuZcKiMRVk9ZfrSSSW/tW1
         7phtsPiiY1QTfJ++uFf4enJQOweTZs5XcIcw2fD6gpTj+CM5tIPboOZZLroNrPs5j/Kr
         0NPn18wYtbV4gqdj3vPe3DMzshaGLMKPG5C5U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749550667; x=1750155467;
        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=Lt6sfVsVl+j8zM2leOn1EGSSGr7V6Z/TllTIx5l3vS4=;
        b=HmroViXDEU1JxgED+iz8C6C+cDk4pZMRQq+p0ATA00udRddGuI8/sMedpzyXMAHSre
         L7IrA7X+vrjWktOn3FCENhiICdw/lESKBQ+QnshMBKUNFDbL2N0xwFn2SGVWIRUd1QRH
         4R4vLtJXnvJYwlGet+LyI1xFMccCjfh05/IDHdAg+NSomQ8hetEMIkwHzj6MKN7bLA0z
         YHCZZBZO3AoMJsB/dDTok46S4/rNG9nzvhiKeDjPPpcewX6tY+co2CWOtKfWNAU1qp5Q
         SobAgUP4MA+AYE+irozcLZOi+aVYIqCkeBD1DYVWL4oqBTK3e09GnrW92IwgRNHjza8g
         Jiiw==
X-Forwarded-Encrypted: i=1; AJvYcCU2tUcliojKRScgdEKpFqwYgBDj42pZcuyklcuQLno1Tjl8FpgBtvR3cS4WusX76PS7eu7GcqMJ/tY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyDiJIBrs/dXN5/eFZTfIOmGQsenMZAzRu9H/H7tk+0Q83XuVaZ
	9IxNW77lR5o0AHoX7KzoaRFhJlHaaJR7FyXsVGFrZIvZDcvcw+BuLWmA3R9ft52bkwc=
X-Gm-Gg: ASbGncvqKYxiVzsJ9OYzmuKBGGa6gf8Fbt7Nx58lELyGk0EsRj12uB2Ty2xrovhf1d1
	CgWI9FHVaSW8rDMrXwWaVxV4outHWUpHTO891Vd8PEmRHzKAymiJJaHYPIEja6ClrULLOYFKz4R
	Rgs1NLxRzoYbrUVra3DymhsVVF0itMy0SZHForyI1+YF1EzCagATYAqIse+YVKB3Kd2PA5mi27w
	XETPJdl8u/sacGniiZxO9dJuc7AEg4Bw2SN5zbArMOF/9BvisH5qIp5dYCVOCKCGeg4r+E5swo3
	Guwr8Lp75kDZygCv/6UqxtOcH2B83XHfKP24xb8/p43kl0XDfcMvQvlv1hopdzBvlJFptAgMFaU
	=
X-Google-Smtp-Source: AGHT+IFAB4+/ho0kisvEuICIT7fXbdXci8yh7szyDGCuL/0CrNFMBhw9RNMbvmvJXsJzKI687UOoKA==
X-Received: by 2002:a05:600c:4fce:b0:453:a95:f086 with SMTP id 5b1f17b1804b1-4530a95f7aamr88187015e9.12.1749550667180;
        Tue, 10 Jun 2025 03:17:47 -0700 (PDT)
Message-ID: 
Date: Tue, 10 Jun 2025 11:17:45 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen: Strip xen.efi by default
To: Frediano Ziglio , 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: <20250610101228.24460-1-freddy77@gmail.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: <20250610101228.24460-1-freddy77@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 10/06/2025 11:12 am, Frediano Ziglio wrote:
> For xen.gz file we strip all symbols and have an additional
> xen-syms file version with all symbols.
> Make xen.efi more coherent stripping all symbols too.
> xen.efi.elf can be used for debugging.

Agreed.  What Xen previous had violates the principle of lease surprise.

> Signed-off-by: Frediano Ziglio 

Did you intend to send this patch personally?

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 10:37:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 10:37:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010676.1388836 (Exim 4.92)
	(envelope-from )
	id 1uOwLg-0005EX-JT; Tue, 10 Jun 2025 10:36:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010676.1388836; Tue, 10 Jun 2025 10: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 1uOwLg-0005EQ-F8; Tue, 10 Jun 2025 10:36:56 +0000
Received: by outflank-mailman (input) for mailman id 1010676;
 Tue, 10 Jun 2025 10:36: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 1uOwLg-0005EK-3t
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 10:36:56 +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 cf012aea-45e6-11f0-a306-13f23c93f187;
 Tue, 10 Jun 2025 12:36:46 +0200 (CEST)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-453066fad06so18121085e9.2
 for ; Tue, 10 Jun 2025 03:36:46 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a5324641c2sm12065737f8f.93.2025.06.10.03.36.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 03:36:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cf012aea-45e6-11f0-a306-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749551806; x=1750156606; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=y1SsjDRBEhCqV6/ummHzasNYJ3OG3FrfZSlRk2G2uWk=;
        b=fRlmEkMVJ6OjndfKzu/e+nZySCe5dWrXWnewYNhCcrOEba5TX1NjbWIQNoyZQOh+a0
         Vi3I3QSifTNDaPm4XzicQduwr065a40yC/N+LfoBYmNiXPPaTXASQdI5sN/C61haO22q
         Ex9kxCHwFRULFq1N5s5ZAjfIYs37YQoXGhnyKaxQdbOeaYlm7/SCK+o2pZbO0gKNspkP
         9XTzS4h3zN2CX+VRbrLD0IHbgIT6rw7JPEKbCBZvQu7maUQGOcW2lIuTJPkXNwYcmydh
         lNdRJoURn6/JpWRI5+/hnxzfteU9fh6FhMUTcRRMEF2/DZoyqz0vpGyTwdIuAiRj7soh
         gN0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749551806; x=1750156606;
        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=y1SsjDRBEhCqV6/ummHzasNYJ3OG3FrfZSlRk2G2uWk=;
        b=biZ/7i12PKA2b3MZ45GFpnog2ByKpLuxEHw37p6XgVGw4nXzkYkzl2DE9bKNh8/euc
         JV06PXeb/mllz6lcfHk8PdcD6D9lk03yOfojQPZvU6rsnNas424UysS0G1uNPDFMHuK0
         aNzNhQgiLzeFmKXM7bs0JS8Tb/EOL9duNl8EdUavtW29DAbDMvGSsvjq9/hGpPSB5AY6
         xwiIHJe48uXfyLy5FrS6U7CmYpJW1imJvQrCdaWmVb4NzhJhAX+5rrkWU01biKfhqq1a
         9rUJjsrgVuPLsCfG3+qWCmJFm8Kb8p3WAn6P/GTYl8COghaHRoOxmMFB4esXMKXDyN9g
         6dGw==
X-Forwarded-Encrypted: i=1; AJvYcCUYuAUbt7cNsURb//ZkqPQ+QSXQNinD2jIHDrx8VGvdVGmiKvI5EgSVCZIsR19vOMxuOrNz4glMys0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxOVsBk2ispvpua4TTo/RKg+g9uk8ZAp4D3iumKkW1DpxkbZ/kB
	MJ2Npz0x9qbyn0Gvs3O4+Z/wDmBSch27sV+SQXekyKJRz7oXRDGUg1CZ3cvJXC8eKA==
X-Gm-Gg: ASbGncuUYBX52WJdnpy4mv4bZBYHhapzoGI48wJ+Y8H51mQmC63n4BY/id5EoM2Bgtd
	kqC2riCY7DFoGbYW5kzCpnnpu2R9vvWETJhfUSkRqEMLRrjFVv+iN0zAV2kUXdloyIPfO/5LWhs
	EOXfe/Sa87s5FyyUmc+W9BRm8g5XggVoHTOPGd4/RGZYLdo3f8gwY9mGsNkeE949JGRmm1MgaTo
	+6zLULbRYaXUiYkdUJdv25Dk3bqFN0Sd7hALd7vrzG6rC257RxlDPfW4FiXXwaIkQaiU50tTEiK
	pg4NQeLz4vju0rb1MNRbp6v2hJYtd+/dLYGdMcIxvpbWRFFjGLSaV7KwNfD1TDaEl5JO26QgpIw
	mPgLeXBjnzhBtI3BNk4MDQ0XAaNFwjp2t+wTlbmMKBF1KTL7WEc1hdRbXZTZNXYXV0t3pBN3erj
	JVW8Nl+sl4upvX9zqVYLYcaXdqAVd4Dyg=
X-Google-Smtp-Source: AGHT+IF2IWmPbARw4qQjZA/VYF+87+PxOLfKPxe2RoO8BaxuGYvsoK1gbzn+mhBXqw7ufT0LlB69+A==
X-Received: by 2002:a05:600c:518d:b0:453:78f:fa9f with SMTP id 5b1f17b1804b1-453078ffb67mr93568885e9.11.1749551806204;
        Tue, 10 Jun 2025 03:36:46 -0700 (PDT)
Message-ID: 
Date: Tue, 10 Jun 2025 12:36:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen: Strip xen.efi by default
To: Andrew Cooper 
Cc: Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Frediano Ziglio , xen-devel@lists.xenproject.org
References: <20250610101228.24460-1-freddy77@gmail.com>
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 10.06.2025 12:17, Andrew Cooper wrote:
> On 10/06/2025 11:12 am, Frediano Ziglio wrote:
>> For xen.gz file we strip all symbols and have an additional
>> xen-syms file version with all symbols.
>> Make xen.efi more coherent stripping all symbols too.
>> xen.efi.elf can be used for debugging.
> 
> Agreed.  What Xen previous had violates the principle of lease surprise.

Except there was a reason for this: While you can point e.g. debuggers at
the file with symbol table and debug info for the ELF image, I have been
unaware of similar abilities when it comes to PE/COFF binaries in an
otherwise ELF world.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 10:37:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 10:37:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010677.1388845 (Exim 4.92)
	(envelope-from )
	id 1uOwLt-0005W3-Qd; Tue, 10 Jun 2025 10:37:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010677.1388845; Tue, 10 Jun 2025 10:37:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uOwLt-0005Vw-Nb; Tue, 10 Jun 2025 10:37:09 +0000
Received: by outflank-mailman (input) for mailman id 1010677;
 Tue, 10 Jun 2025 10:37: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 1uOwLs-0005EK-8h
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 10:37:08 +0000
Received: from mail-oa1-x35.google.com (mail-oa1-x35.google.com
 [2001:4860:4864:20::35])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id db2bafe8-45e6-11f0-a306-13f23c93f187;
 Tue, 10 Jun 2025 12:37:07 +0200 (CEST)
Received: by mail-oa1-x35.google.com with SMTP id
 586e51a60fabf-2ea34731c5dso1400854fac.0
 for ; Tue, 10 Jun 2025 03:37:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: db2bafe8-45e6-11f0-a306-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1749551826; x=1750156626; 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=HQllWdWvQ6GyUrcNbIKWc6GTA25rlnnJsfpyeRJ6bq8=;
        b=IaglCuio0JrWyAvqLKdWCczeC1hHCPhLgjBoJiTPNXOx8Upj7wCRuHUVVrbdxuTmQV
         XqZmU+CpPtGZ6tIH0jaYU+upO2y6h3r2dy64d/uOkzAErkQfuCqh3bYksqDGL9cm6SiJ
         mJAJhYlN7ZOLppGt4T1cGzdksxx0zlDVcKNJQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749551826; x=1750156626;
        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=HQllWdWvQ6GyUrcNbIKWc6GTA25rlnnJsfpyeRJ6bq8=;
        b=rtz+UUtZV5wVZtzsj8L7JUxVnLBXk6yFRd8BZ8ft2rplDEW0yNVvwMU2K48P8xvPqq
         V0inIZbMTlhOum4h7NQjsOMmL1Z8L0wWHgCn88j0xc92ExceMQvIopW4aCcCFZefBPfP
         RsPnf2CdII548VUDq7wQOUe59nOaVQPkrCeQqoz2Oo8j6N/zEDoZ9uRAUoPbSfsi2msO
         +cejsgUo5yrYdVTrgI1B6kTrTeiPkQs/dOtgjAZITkG+Ojqfb3fSDbYrrAhlBMOOiNjS
         wroAfwI42YCab2IFRa7bJaeUHHzf98CENT43xQkJyBRZrdCzT6Ej9/Q4rpPSQig3UERF
         oNiQ==
X-Forwarded-Encrypted: i=1; AJvYcCXiT40dVrM5hS/i/+IOi17p1EWVKhwUHh2E09q/SIKJPYyD8HTOEQsvHqMv0DHVlwFes2va+pydHmM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyZL+NVGn4PPACvdCUx/wCT/+2m64bKBifVj5is3AeEh+2TIXlK
	wmTSnQcNybSf/GVhXwmhPJcWczP9V9iDF0J3IdG/7iOxBqD6AnLN1NA01jkFwdKiKNKa198/zbD
	NBNdkUUrMce2WNTqRyG/aaN6f2NeVcYw+jjYRHv8ALQ==
X-Gm-Gg: ASbGnctGOpXafAMXTUzO40cXA/XZkMm5v8tu52Kl8BVYsFltQq3TDR8ydBbiTnvbJxP
	kPyf6qRZuuJcY9+clVUGGxCADxhJ4egms7wnDDRCPU62qJQRMrV46eLRdsjA6WLYOjtOWJf2CcF
	OsWVdf3LmB83Z2e41Xuz8eUTLEIlnB4RXMbHlZX3VX3Vg8pdFBx4TF
X-Google-Smtp-Source: AGHT+IEEI00uC9sZ7cAalAOoYq0t2BJVjAL/TiVQetB5KAFmU1n4zeIdDfGSt67mkbD818/2aVj8c81KOCgEW67UCcI=
X-Received: by 2002:a05:6871:4b06:b0:2c2:bd31:cf37 with SMTP id
 586e51a60fabf-2ea00679c87mr10431002fac.4.1749551826473; Tue, 10 Jun 2025
 03:37:06 -0700 (PDT)
MIME-Version: 1.0
References: <20250610101228.24460-1-freddy77@gmail.com> 
In-Reply-To: 
From: Frediano Ziglio 
Date: Tue, 10 Jun 2025 11:36:55 +0100
X-Gm-Features: AX0GCFurVAGi2D5Izvq0V7p4mEjR4f-o3SFD-pkM8FCxB3B1vDF2pbxYzRrrNRc
Message-ID: 
Subject: Re: [PATCH] xen: Strip xen.efi by default
To: Andrew Cooper 
Cc: Frediano Ziglio , xen-devel@lists.xenproject.org, 
	Anthony PERARD , Michal Orzel , 
	Jan Beulich , Julien Grall , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Stefano Stabellini 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 10, 2025 at 11:17=E2=80=AFAM Andrew Cooper
 wrote:
>
> On 10/06/2025 11:12 am, Frediano Ziglio wrote:
> > For xen.gz file we strip all symbols and have an additional
> > xen-syms file version with all symbols.
> > Make xen.efi more coherent stripping all symbols too.
> > xen.efi.elf can be used for debugging.
>
> Agreed.  What Xen previous had violates the principle of lease surprise.
>
> > Signed-off-by: Frediano Ziglio 
>
> Did you intend to send this patch personally?
>

I noted. No, it was developed as part of CSG work. I think some
configuration left from the time we had issues with the email.
Still me, so the signed off should be okay. Should I update and send it aga=
in?

> ~Andrew
>
Frediano


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 10:44:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 10:44:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010686.1388855 (Exim 4.92)
	(envelope-from )
	id 1uOwSm-0007Or-GE; Tue, 10 Jun 2025 10:44:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010686.1388855; Tue, 10 Jun 2025 10:44: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 1uOwSm-0007Ok-Ce; Tue, 10 Jun 2025 10:44:16 +0000
Received: by outflank-mailman (input) for mailman id 1010686;
 Tue, 10 Jun 2025 10:44: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 1uOwSk-0007Oe-Ot
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 10:44:14 +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 d9780688-45e7-11f0-a306-13f23c93f187;
 Tue, 10 Jun 2025 12:44:13 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3a5257748e1so3552554f8f.2
 for ; Tue, 10 Jun 2025 03:44:13 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-4521375b5e1sm139079185e9.37.2025.06.10.03.44.12
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 10 Jun 2025 03:44:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d9780688-45e7-11f0-a306-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749552253; x=1750157053; 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=XHlXqnj3di+1NstG3GDVx/HOeqSCRdzBnhKtBH49vU0=;
        b=brK8MMEl6OH9WJF0kF/ygJu70U3XcPnNPNPxtWeve5eRVjtCJzBOFWEc/HFpMtBf1l
         V+80dpKJJopB4VRRptOFBOBo2twqeEGY9djTtRHKkRSyJCUScbYp3RaIFwDDUgwvzKFc
         D4ufLcU13l+NPYo9J/PInrwu7bhUWocvtFSgo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749552253; x=1750157053;
        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=XHlXqnj3di+1NstG3GDVx/HOeqSCRdzBnhKtBH49vU0=;
        b=odlUWw4JGyn560jJEHllcnIC+RwZpau50svMA+DkdqzWnkesyiLCeOX8XgcWS9QRG4
         iND5dzwUwa4NT13idkU54ieLge3u4YEJiCkN3OjZMIti3KkjlXc7PhBRMtLhU+7O6Cr0
         +PnbSqYkPPcxNr8hXtYHLZd2rclh5j3Pv9bsLIFAbxV7YCP+CPoJDDJ1jaMeQhrhnmE4
         hDhaox7rCgJc8+sDGlJKTxZeZhZfkue4hHleOE91j8gY4ipQ4WXOj8+3TShnaVEc+RQ+
         lG1DwJcRBJoCPM28bliFtkbi5XyWxbTXs33zXuX2OJhBiFiKeNSkj5qUrMbv0mKzJiEp
         yFkw==
X-Gm-Message-State: AOJu0YwCMns7d5P8VxjnQ/KB1kPJfRFlQmSK0YHgnakOM9BS2pjVXckZ
	CVPCfl2cCdCtE5b0j07NMx7r8HoEStPchAab0smgOhN4gPX7O9C8tHDod7qsrqML6aI=
X-Gm-Gg: ASbGnctr+qZ5aGbJcSX7nXuypEaDKqaSTeJ98V3qDr219fCThKDJooXbz2lhyVb+3vG
	+aMsK1rldpUlxwINmdVkmGzHFmfqqGWhLLcIoNiYOWeNMrRVB56vpmA2vM375rziZZh5oK4P1nq
	fZC2PSqJrxjb2DqYX/HDjI0Tx1NjeNiUA9R4w/kCqOjSgYnLHLn2amP0KnYhP11Tk2BcOD+hzV6
	Oir7a/NslKHwrfquCiLQYVSDQICmlO1Uy23/Pc7ZMmVUgx8BjR1hY0BvSYbCbhmjXiQVlvHApE+
	Ck1LFhAGHm1sHSSSTZ3EWlJzj1m3iEVWvOWHdEJq7LIklgcxtnVDVV0IvuGNBxSfCnLxbFQ+ryw
	qIbe+EDrsayaHCO2aOff1+VIpEQL5Z8uvRGk=
X-Google-Smtp-Source: AGHT+IEbQ7b51Fk8Szk9nvVfHxMETQT7gRi1ktDmQmxnlznR4WhNe8rnJ+Wbkftsda3ZbRP93ugg6g==
X-Received: by 2002:a5d:588a:0:b0:3a5:2e9c:edc with SMTP id ffacd0b85a97d-3a531886a28mr13142012f8f.34.1749552253130;
        Tue, 10 Jun 2025 03:44:13 -0700 (PDT)
Date: Tue, 10 Jun 2025 12:44:11 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" ,
	Andrew Cooper 
Subject: Re: [PATCH v2] x86/HVM: restrict use of pinned cache attributes as
 well as associated flushing
Message-ID: 
References: <78b3ddeb-4317-4d54-ad52-9eb03bdf7942@suse.com>
 
 <6e9e84eb-f98b-4c06-8952-03aecc82c0ea@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <6e9e84eb-f98b-4c06-8952-03aecc82c0ea@suse.com>

On Tue, Jun 10, 2025 at 09:40:38AM +0200, Jan Beulich wrote:
> On 09.06.2025 12:36, Roger Pau Monné wrote:
> > On Wed, Jun 04, 2025 at 11:48:00AM +0200, Jan Beulich wrote:
> >> @@ -605,31 +606,35 @@ int hvm_set_mem_pinned_cacheattr(struct
> >>  
> >>                  type = range->type;
> >>                  call_rcu(&range->rcu, free_pinned_cacheattr_entry);
> >> -                p2m_memory_type_changed(d);
> >>                  switch ( type )
> >>                  {
> >> -                case X86_MT_UCM:
> >> +                case X86_MT_WB:
> >> +                case X86_MT_WP:
> >> +                case X86_MT_WT:
> >>                      /*
> >> -                     * For EPT we can also avoid the flush in this case;
> >> -                     * see epte_get_entry_emt().
> >> +                     * Flush since we don't know what the cachability is going
> >> +                     * to be.
> >>                       */
> >> -                    if ( hap_enabled(d) && cpu_has_vmx )
> >> -                case X86_MT_UC:
> >> -                        break;
> >> -                    /* fall through */
> >> -                default:
> >> -                    flush_all(FLUSH_CACHE);
> >> +                    if ( is_iommu_enabled(d) || cache_flush_permitted(d) )
> >> +                        flush = true;
> > 
> > Is the check here required?  memory_type_changed() will already check
> > for is_iommu_enabled() and cache_flush_permitted(), and hence you
> > could just set flush to true unconditionally here IMO.
> 
> The behavioral difference is when both predicates are false: The way I have
> it now, p2m_memory_type_changed() will then still be called (conditionally),
> better matching prior behavior.

I see.  Yes, p2m_memory_type_changed() needs to be called.

> 
> >>                      break;
> >>                  }
> >> -                return 0;
> >> +                rc = 0;
> >> +                goto finish;
> >>              }
> >>          domain_unlock(d);
> >>          return -ENOENT;
> >>  
> >>      case X86_MT_UCM:
> >>      case X86_MT_UC:
> >> -    case X86_MT_WB:
> >>      case X86_MT_WC:
> >> +        /* Flush since we don't know what the cachability was. */
> >> +        if ( !is_iommu_enabled(d) && !cache_flush_permitted(d) )
> >> +            return -EPERM;

When assigning IO resources without an IOMMU enabled we likely need
to allow the pinned cache attributes to be set, but there's no need to
propagate the changes to the p2m, as the EMT calculation won't take
into account the pinned attributes.

IOW: I don't think we can safely short-circuit and return -EPERM here
without agreeing that it's a behavioral difference form the previous
implementation.

> >> +        flush = true;
> >> +        break;
> >> +
> >> +    case X86_MT_WB:
> >>      case X86_MT_WP:
> >>      case X86_MT_WT:
> >>          break;
> >> @@ -682,9 +687,11 @@ int hvm_set_mem_pinned_cacheattr(struct
> >>  
> >>      xfree(newr);
> >>  
> >> -    p2m_memory_type_changed(d);
> >> -    if ( type != X86_MT_WB )
> >> -        flush_all(FLUSH_CACHE);
> >> + finish:
> >> +    if ( flush )
> >> +        memory_type_changed(d);
> >> +    else if ( d->vcpu && d->vcpu[0] )
> >> +        p2m_memory_type_changed(d);
> > 
> > FWIW, I would just call memory_type_changed() unconditionally
> > regardless of the change.
> 
> In which case the need for the "flush" local var would go away, if I
> understand your suggestion correctly. Like above, there'll then be
> more of a behavioral change than intended. In particular ...

There will be a behavioral change, but not one that the guest would
notice IMO.

> >  We suspect the hypercall is only used at
> > domain creation time (where memory_type_changed() won't do a cache
> > flush anyway).
> 
> ... "suspect" is not enough for my taste. The only alternative there
> that I see (as mentioned in a post-commit-message remark) is to
> refuse such "late" changes altogether. Yet for that we need to be
> sure, which it looks like no-one of us is.

Why do you say only alternative?

Calling memory_type_changed() unconditionally (without taking into
account the previous or new cache attributes) would also be an
acceptable solution, that might wide the cache flushing a bit, but
would still be correct and much simpler IMO.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 11:25:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 11:25:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010693.1388865 (Exim 4.92)
	(envelope-from )
	id 1uOx6E-0004FS-Fg; Tue, 10 Jun 2025 11:25:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010693.1388865; Tue, 10 Jun 2025 11: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 1uOx6E-0004FL-C8; Tue, 10 Jun 2025 11:25:02 +0000
Received: by outflank-mailman (input) for mailman id 1010693;
 Tue, 10 Jun 2025 11:25: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 1uOx6D-0004FD-8U
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 11:25:01 +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 8aded99d-45ed-11f0-a306-13f23c93f187;
 Tue, 10 Jun 2025 13:24:58 +0200 (CEST)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-451e2f0d9c2so41412355e9.1
 for ; Tue, 10 Jun 2025 04:24:58 -0700 (PDT)
Received: from [192.168.86.29] ([90.250.112.104])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-452730b9b33sm134892195e9.26.2025.06.10.04.24.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 04:24:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8aded99d-45ed-11f0-a306-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749554698; x=1750159498; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=uyQkh1DskgYGzW/KVChHLWEBLbwJXzSm7ZrBZmN9n8o=;
        b=a/0MjQEIeZ0GQoYx/ScRY0oFeyPE3a658478mBL3WmlmgsNQbsvD1O/lG4zBzga58U
         AqioN0qks6sVtrcwV9J2EEsnFgxGErWGQ9xRuiYKJWtFueLCkcAMtGU/cWxuMhIF/r8H
         Wx+mQ5U1K7hLDE0L8OocOuIZI1EVWp8nwxlgQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749554698; x=1750159498;
        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=uyQkh1DskgYGzW/KVChHLWEBLbwJXzSm7ZrBZmN9n8o=;
        b=mqdD1sp9wNNLhovT/JUXZHVZusdBOeQncOxM84JZMhV/iN1dKuC1v/kC8WGGbp7Qfw
         504df8CUDKwi1n58vBG9Z+DLDlfmHn4qFkbgVxSKLRD46ij0VR1ddG0INlsvsGPw6ZDr
         v/Ruy0F52erjUvXQve7eFd25RFF2odz+amS1abJ81DdqVLHk1FZyAVX73eSlRT9WI1YR
         BNngsDiV0la4mQpS/oBPEwJKlRS92MZnMjKtwJmAV48pJJHVumtOkGUSOiQ1NNrPYfwJ
         W6KZ6RVYf8+cqf31FRZkxZRRys6qDsWdwy0lg1/2tB75vVe9zx7ZmAhmH/ETd7sudkMq
         3V8Q==
X-Forwarded-Encrypted: i=1; AJvYcCWPEFF6z1tEKNJ5lS6ZV6cNDikRxDJR5KoVxiLH30u3VaADzNaOw15MNk55Gh1Fuyc8T0NT6BZiExw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyc8AnPKEFt2iEXa6pg3jGLWjlCYntxE7OiQ/LmGy/vi3zR/39j
	4XGKluglNJS4VsvDLOSK6o1L+pfIGMUz0tV3OZx9SXG70DxYNs/am3m4tji3dZLzKHY=
X-Gm-Gg: ASbGncv0jCkgRObR8z8jmZPYjjK1ZShyZ4zksQNg4DegtuGQFN2/R4iNPkl/o6lI2aF
	0tPDpWshxTkKoLDD6y8EKH+NwlmdkF2tpTJUpNztVKu5NW/9D4jwigs1RUDB16GUJO0xnvqgPsF
	r+9CTeMb8yKgA7jN2C2FOrnY30TeZr0RZa7thzjeyWoyCkRlgulvY/cwdQ8cVX7XrXEyRWpkP+H
	y5Rmpyjotnr/yDlk56mJwEfqgodYtjEISIESbinNF9bNrrubANogi/NL32MRjixTycYbTHU2tG5
	FtqChF5M8UygSuefdeHflAekuL2eKvu7dws0MBNETWNIURAnyq3DC39oqPrDLdMrSokO+kUNSDU
	=
X-Google-Smtp-Source: AGHT+IFP+1FCuHhsLkIuAcxWS5a9gmzUZo1R3okfH/QVzxxhN7UWy0brtEjCF1x0OksvivPjd0gA5Q==
X-Received: by 2002:a05:600c:1f1a:b0:43c:f509:2bbf with SMTP id 5b1f17b1804b1-4531cfe36dcmr30640865e9.15.1749554698256;
        Tue, 10 Jun 2025 04:24:58 -0700 (PDT)
Message-ID: <7f965335-68d9-4da5-8ce3-db68583db9a2@citrix.com>
Date: Tue, 10 Jun 2025 12:24:57 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1] xen/console: group pbuf under console field
To: Jan Beulich , dmkhn@proton.me
Cc: anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com,
 roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com,
 xen-devel@lists.xenproject.org
References: <20250606194937.2412579-1-dmukhin@ford.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 10/06/2025 9:10 am, Jan Beulich wrote:
> On 06.06.2025 21:49, dmkhn@proton.me wrote:
>> From: Denis Mukhin 
>>
>> Group all pbuf-related data structures under domain's console field.
> Fine with me in principle, as I was indeed wondering about the lack of
> grouping when the sub-struct was introduced, but ...
>
>> @@ -654,6 +648,12 @@ struct domain
>>  
>>      /* Console settings. */
>>      struct {
>> +        /* hvm_print_line() and guest_console_write() logging. */
>> +#define DOMAIN_PBUF_SIZE 200
>> +        char *pbuf;
>> +        unsigned int pbuf_idx;
>> +        spinlock_t pbuf_lock;
>> +
>>          /* Permission to take ownership of the physical console input. */
>>          bool input_allowed;
>>      } console;
> ... since all uses of the fields need touching anyway, can we perhaps
> think of giving the fields better names? I never understood what the
> 'p' in "pbuf" actually stands for, for example.

I always assumed it was Hungarian notation, so pointer.

As it's namespaced within .console, plain .buf, .idx and .lock names
work fine.

Separately, 200 is a silly and arbitrary number.  Furthermore the
allocation is unconditional, despite the fact that in !VERSBOSE builds,
domUs can't use this facility.  Also, where's the input buffer?

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 12:00:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 12:00:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010715.1388879 (Exim 4.92)
	(envelope-from )
	id 1uOxe1-0008LU-6N; Tue, 10 Jun 2025 11:59:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010715.1388879; Tue, 10 Jun 2025 11: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 1uOxe1-0008LN-3L; Tue, 10 Jun 2025 11:59:57 +0000
Received: by outflank-mailman (input) for mailman id 1010715;
 Tue, 10 Jun 2025 11:59:56 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uOxe0-0008LH-4F
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 11:59:56 +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 6b63c1a8-45f2-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 13:59:53 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3a4fea34e07so3075411f8f.1
 for ; Tue, 10 Jun 2025 04:59:53 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a532435f95sm7574175f8f.60.2025.06.10.04.59.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 04:59:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6b63c1a8-45f2-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749556793; x=1750161593; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=raWaNDVxzAzVk17YF8f5juSCqNsqhhgPnYBtY+XkZWc=;
        b=R4F3ZSubYnFXy35OTGpgvnVi6zmh5QPEwM6eGZAPypuldIabwM0uijq+gSUzprZNHC
         ebOAwnxQsMD8XwXszSsYCEykBzOsJLeAVe6U+RWf0wWSDx61SxfbbvjAaabCaj4Ua+HM
         gjOTKUITZWTDJzwees7wFWURTasiaGBGOHikS8F637dP7HvrVUeSMDbii+F/ew3YKdUc
         4zEb94udfKQM6T7Be9l1VVH6J7pKEbbK5Mo/XQjC2fxU6XyTl/tOAQIvGLchP6gqPRhN
         ooN+7mCsFa6jKS1SPBOYXCcB7nhjW9e1jihN0MUkhe9BX7VhX5Hx/Itftr7XD1rsTxUs
         AdfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749556793; x=1750161593;
        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=raWaNDVxzAzVk17YF8f5juSCqNsqhhgPnYBtY+XkZWc=;
        b=aBvrUVbVyVq2jHZSUVwD/LuD6juwxezpIpAtf9AMxyDi2AdqZ68W1AO9oi5FwzEeQs
         /FRSJNtd7MDl3NW4jr7A+C6++HuPFzrlLsBOmyy2u+vL/dX8efs0jds23qHLaJxE/uhd
         BbTLuG7xyW+QT7+9cB0r8gnsj0dgH/tRPZ0FGVxOtyQY5x4N3wR2kBGdSLbZIVPVuVnS
         iQt3GGbb6S0Y55Wnt7w5kbFYpfJztvO1HgI3gdQA4vcqHtHG+O/Nf3T/z1vufM1i347G
         Tb68AM66dCBkNxUSSe7ZYK4i9jwAvadYzv4TFuY93xHNzwk+aSso+/fKEPOZmHuufdqq
         tfgg==
X-Gm-Message-State: AOJu0YxEVgQuqW1asRADbftHsnUoVIKQegRqceWNRwNiarmI1qsgoI9y
	YMfn0nGdzuvJXtnQPKdkxs+I4B1HS9JJ1jQmbOjD6tnHaTPRHbpB1ZjF3dzqJ4p4Uw==
X-Gm-Gg: ASbGncvl/bo/MEojEcXvbexj1czUjBy4p/VIhE2SPbqOEWius3+vIQwuBp3OjrABOBu
	ff64IW7X1QufW3vv5ngO9OZaTnqXV9p/56EunMgvdtjhQ5eYS6kMfvDfklyRcE3irXDABrcpDg8
	Epa7+Sh4RrVqhKMUMbzPRs+uFwUn5AJb7zJ679cME6DzHGVLikxEk0G8le5RmlSYcwPpoZb7Xkv
	H8bEA/quQwzCXjs9k6FtBTtosvct7zee2sN/yTWN5K1dTf2bbRR+dlF2tiO3Xs7Vax4sDlUeTfO
	/lWpWAh0sZH0HTxDOedWQqWgRXsxye1hbxkmdEVVS+YpQ0qAw80K/AR00t3Gw3y1Ng/A0SMdP7h
	yE21IT9woteOg9FK3jEx88voL1UTaxl7V4ImKW/igf8o4OjpKQGJ9Tg7BJbx0GoVO0mDNPcwxuf
	h/5tvd5ako2H1sdVeIhCPX
X-Google-Smtp-Source: AGHT+IEtJA0pLD/Z9FE0bvaVzVlpVjClivVfcA8JL9INM182EtCS2wRRREmwZT2CIysBzZnJ3WN2Yg==
X-Received: by 2002:a05:6000:2088:b0:3a4:d98d:76b9 with SMTP id ffacd0b85a97d-3a531cadb37mr11442025f8f.41.1749556792874;
        Tue, 10 Jun 2025 04:59:52 -0700 (PDT)
Message-ID: <5f8d694f-e712-4869-879f-80b2c4907a45@suse.com>
Date: Tue, 10 Jun 2025 13:59:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] x86/HVM: restrict use of pinned cache attributes as
 well as associated flushing
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper 
References: <78b3ddeb-4317-4d54-ad52-9eb03bdf7942@suse.com>
 
 <6e9e84eb-f98b-4c06-8952-03aecc82c0ea@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.06.2025 12:44, Roger Pau Monné wrote:
> On Tue, Jun 10, 2025 at 09:40:38AM +0200, Jan Beulich wrote:
>> On 09.06.2025 12:36, Roger Pau Monné wrote:
>>> On Wed, Jun 04, 2025 at 11:48:00AM +0200, Jan Beulich wrote:
>>>> @@ -605,31 +606,35 @@ int hvm_set_mem_pinned_cacheattr(struct
>>>>  
>>>>                  type = range->type;
>>>>                  call_rcu(&range->rcu, free_pinned_cacheattr_entry);
>>>> -                p2m_memory_type_changed(d);
>>>>                  switch ( type )
>>>>                  {
>>>> -                case X86_MT_UCM:
>>>> +                case X86_MT_WB:
>>>> +                case X86_MT_WP:
>>>> +                case X86_MT_WT:
>>>>                      /*
>>>> -                     * For EPT we can also avoid the flush in this case;
>>>> -                     * see epte_get_entry_emt().
>>>> +                     * Flush since we don't know what the cachability is going
>>>> +                     * to be.
>>>>                       */
>>>> -                    if ( hap_enabled(d) && cpu_has_vmx )
>>>> -                case X86_MT_UC:
>>>> -                        break;
>>>> -                    /* fall through */
>>>> -                default:
>>>> -                    flush_all(FLUSH_CACHE);
>>>> +                    if ( is_iommu_enabled(d) || cache_flush_permitted(d) )
>>>> +                        flush = true;
>>>
>>> Is the check here required?  memory_type_changed() will already check
>>> for is_iommu_enabled() and cache_flush_permitted(), and hence you
>>> could just set flush to true unconditionally here IMO.
>>
>> The behavioral difference is when both predicates are false: The way I have
>> it now, p2m_memory_type_changed() will then still be called (conditionally),
>> better matching prior behavior.
> 
> I see.  Yes, p2m_memory_type_changed() needs to be called.
> 
>>
>>>>                      break;
>>>>                  }
>>>> -                return 0;
>>>> +                rc = 0;
>>>> +                goto finish;
>>>>              }
>>>>          domain_unlock(d);
>>>>          return -ENOENT;
>>>>  
>>>>      case X86_MT_UCM:
>>>>      case X86_MT_UC:
>>>> -    case X86_MT_WB:
>>>>      case X86_MT_WC:
>>>> +        /* Flush since we don't know what the cachability was. */
>>>> +        if ( !is_iommu_enabled(d) && !cache_flush_permitted(d) )
>>>> +            return -EPERM;
> 
> When assigning IO resources without an IOMMU enabled we likely need
> to allow the pinned cache attributes to be set, but there's no need to
> propagate the changes to the p2m, as the EMT calculation won't take
> into account the pinned attributes.

Why would it not do so? Am I overlooking a conditional there that would
cause hvm_get_mem_pinned_cacheattr() to not be called? The only related
one I see is

    if ( type != p2m_mmio_direct && !is_iommu_enabled(d) &&
         !cache_flush_permitted(d) )

covering the without-IOMMU case just the same as the "with" one. (The
"without" case looks dubious to me, as I don't think we arrange for
any identity mapping, but that's a separate topic.)

> IOW: I don't think we can safely short-circuit and return -EPERM here
> without agreeing that it's a behavioral difference form the previous
> implementation.

There's no question there is a behavioral change here. Without I/O
resources (and without IOMMU) we simply don't accept cache attributes
other then WB elsewhere; the change is to avoid doing so here as well,
to get things to be consistent. Hence the -EPERM return.

>>>> @@ -682,9 +687,11 @@ int hvm_set_mem_pinned_cacheattr(struct
>>>>  
>>>>      xfree(newr);
>>>>  
>>>> -    p2m_memory_type_changed(d);
>>>> -    if ( type != X86_MT_WB )
>>>> -        flush_all(FLUSH_CACHE);
>>>> + finish:
>>>> +    if ( flush )
>>>> +        memory_type_changed(d);
>>>> +    else if ( d->vcpu && d->vcpu[0] )
>>>> +        p2m_memory_type_changed(d);
>>>
>>> FWIW, I would just call memory_type_changed() unconditionally
>>> regardless of the change.
>>
>> In which case the need for the "flush" local var would go away, if I
>> understand your suggestion correctly. Like above, there'll then be
>> more of a behavioral change than intended. In particular ...
> 
> There will be a behavioral change, but not one that the guest would
> notice IMO.
> 
>>>  We suspect the hypercall is only used at
>>> domain creation time (where memory_type_changed() won't do a cache
>>> flush anyway).
>>
>> ... "suspect" is not enough for my taste. The only alternative there
>> that I see (as mentioned in a post-commit-message remark) is to
>> refuse such "late" changes altogether. Yet for that we need to be
>> sure, which it looks like no-one of us is.
> 
> Why do you say only alternative?

Oh, sorry, I meant "only" just in regard to options keeping the main
code structure of the change. I agree ...

> Calling memory_type_changed() unconditionally (without taking into
> account the previous or new cache attributes) would also be an
> acceptable solution, that might wide the cache flushing a bit, but
> would still be correct and much simpler IMO.

... that this, too, is a possibility. It would, however, go against the
stated purpose of the change (in the subject "... as well as associated
flushing"), which - after all - was the main goal here, seeing the
series this was originally part of.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 12:23:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 12:23:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010727.1388889 (Exim 4.92)
	(envelope-from )
	id 1uOy0t-0003hk-2i; Tue, 10 Jun 2025 12:23:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010727.1388889; Tue, 10 Jun 2025 12:23:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uOy0s-0003hd-Vk; Tue, 10 Jun 2025 12:23:34 +0000
Received: by outflank-mailman (input) for mailman id 1010727;
 Tue, 10 Jun 2025 12:23: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 1uOy0r-0003hX-Kx
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 12:23:33 +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 b6912ebe-45f5-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 14:23:28 +0200 (CEST)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-450d668c2a1so43238865e9.0
 for ; Tue, 10 Jun 2025 05:23:28 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-452730b92c9sm136768285e9.24.2025.06.10.05.23.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 05:23:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b6912ebe-45f5-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749558208; x=1750163008; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=4cD00wWmxfNau1SVpivJfeD9IwEnOTfInru4OFavM7g=;
        b=Wn/S/+VczZcnPL+dfJntjz3AWXHLUkUdJympanN1zPkXi4i+qVEpZL+ANtwsKTt1Wh
         Xc9BtNEtdta98MLT9AIWWv+uZMoFbpsNNQl5Z4TDTzQXPtu8ojTmhpqj/hsKsXgozb6u
         tPxftm5C4Oe6vF/1vrgWEH5ryV2KzNXV1DofTSgFGn8bCd2tQWEsZbfLoyA6q/HBj/4E
         lg1nl+idI4mfrla+wemeY18NNyVm379DaUTBvDkcFrkj1x6WX9AJHEhcWiDRZxac8N5i
         wMBJCfpV3uooqmxPl6XjTsBOJrU2SUKX2q/oss9wF93eAKGw+REwkgqyU7mqbiNVAO2N
         NTwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749558208; x=1750163008;
        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=4cD00wWmxfNau1SVpivJfeD9IwEnOTfInru4OFavM7g=;
        b=ovhE4Ho3AT/PWGRaVQBJ6rtIQPkel1ds4fkS6ki4+SWHqhrMaEco0gWS6LWbLTzp7T
         yBTtw0XUlYkdfpg7p9WdlVZ4miVSAMYjMW5nc3bswADvGp/9hu58cndRbsEDWglem9kn
         za3a3Coe+a6O0dr9dckQXd8xqdmtZUx9vrtPCzJWAoyqfZxqnUa1yVe+Qw+emz9dAiSF
         Hs4i2ACHi9t2BrYfUJVuM8zEpOzpWvPH2j2jb5B5xSi6aZ1DVk3VaBQefGZSC9pir7N6
         HZuFlHbSUFoyNjQyE2uuJwuHH4N3LAaP1QgVFhXozx9X5dIgHViWPAfjyyUjgkTCysMx
         /Xvg==
X-Gm-Message-State: AOJu0Yxy1qtYVVRUkQ0pqt+ny0o3xV6kJT/nJT2xHa6fJHxSP9Pq3SAf
	TYuk9s6su74OL0NAWAud+D3p+hcu6pyjHUqjRwp0DudfqgPPJzdbg16W/xZdZiCiZA==
X-Gm-Gg: ASbGncvwKm+WaPeBVIDhvDgGQivn7d3SmdBEYBG4lj+sYg3J+X9lPT+D9iZtbRKRHsS
	aalZB8kwmPtXDLOlZFo7yuE8+ER/nQlAENt6JWYjOaKp2J2HaNK9f9IcHfhwnEJnYJReFi+o2jv
	Isy8OvxEGK2zjZSsZ1EdMp5AACguGySHQiKOQgB3GZDepEd5uR5dawHq71XHhy1LW0jmnGTIwZN
	SNw9cZM/UoZSSJma50RsSz60bkKAEW6iGhzeCjwbGbhN6F/RKG4sYKwkBMbH4bMiwoMzuGDp7NS
	61V8coR+q7NTM5LWA1HPCTLG7CHhDdS49LDUMk9i4xKC6Qpn8iC0OsCBPsr0EpvRW4ptCMfVjcm
	D6DTSmG6XtIGT0h50Uc+GGd+5LzQYXudBSz/HmyVgC2NvGOjasM4AeDzrOECPeoYJv/hmemvH7G
	L9RF74pBSEHHa6Cqn+zjEC
X-Google-Smtp-Source: AGHT+IE7EDJsAH2HWqmKVf6AvdBQpis/Kxsa9DYkhGjbiIS3O0B49HK/TUbRFFV3nItj6ecGaK2ZvQ==
X-Received: by 2002:a05:6000:2dc7:b0:3a4:ed9a:7016 with SMTP id ffacd0b85a97d-3a551427f0emr3065473f8f.26.1749558207624;
        Tue, 10 Jun 2025 05:23:27 -0700 (PDT)
Message-ID: <89d4250e-20aa-4515-8199-7003afb0bcbf@suse.com>
Date: Tue, 10 Jun 2025 14:23:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 02/11] xen/page_alloc: Remove `claim` from
 domain_set_outstanding_pages()
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Alejandro Vallejo 
Cc: xen-devel@lists.xenproject.org,
 Bernhard Kaindl ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini 
References: <20250314172502.53498-1-alejandro.vallejo@cloud.com>
 <20250314172502.53498-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: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 05.06.2025 18:42, Roger Pau Monné wrote:
> On Fri, Mar 14, 2025 at 05:24:53PM +0000, Alejandro Vallejo wrote:
>> With a single global count for the claims it's easy to substract
>> domain_tot_pages() from the claim so the number given in the hypercall
>> is the real reservation of the domain. This is the current behaviour.
>>
>> However, a later patch introduces exact-node claims and those interact
>> very poorly with such a scheme. Since accounting domain_tot_pages() in
>> one case but not the other seems strictly worse than not accounting them
>> at all (which is at least consistent), this patch stops substracting
>> tot_pages from the claim and instead checks that claimed memory +
>> allocated memory don't exceed max_mem.
> 
> Hm, while I don't have any specific interest in keeping the current
> behavior, XENMEM_claim_pages is part of the stable ABI (it's not a
> domctl), and hence should be stable.

Is that true? It sits inside a

#if defined(__XEN__) || defined(__XEN_TOOLS__)

which generally de-marks unstable (tools-only) interfaces.

>  Note also the comment above the
> definition of XENMEM_claim_pages how it states the specific behavior
> that you are trying to change (and which should have been adjusted as
> part of this change).

This is the more important part, imo.

> I have no idea why this was made a xenmem rather than a domctl
> hypercall, but if you want to change the semantics I think the only
> option is introducing a new hypercall.

It _is_ a memory operation, and it re-uses one of the interface structs
there. (Yes, none of these would technically have prevented it from
being a domctl.)

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 12:37:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 12:37:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010733.1388898 (Exim 4.92)
	(envelope-from )
	id 1uOyEN-0005Sj-6M; Tue, 10 Jun 2025 12:37:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010733.1388898; Tue, 10 Jun 2025 12:37: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 1uOyEN-0005Sc-3p; Tue, 10 Jun 2025 12:37:31 +0000
Received: by outflank-mailman (input) for mailman id 1010733;
 Tue, 10 Jun 2025 12:37: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 1uOyEL-0005SW-N3
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 12:37:29 +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 aa76f58f-45f7-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 14:37:27 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a4f72cba73so4416782f8f.1
 for ; Tue, 10 Jun 2025 05:37:27 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a5324641c2sm12339184f8f.93.2025.06.10.05.37.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 05:37:25 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: aa76f58f-45f7-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749559046; x=1750163846; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=mrCuqKhFUgUTqPRFOhuZ8VovxipnNe4BanDZ77aEmcw=;
        b=FmlDEg/IYHfimvi/psmf0aAw4v6BI2agiEG5X4izu14gzortDAA419fxYLONPri8Sw
         OPY48yzHxwjgKOwytVACXpOg8BeFVeuyP3KBaYEIxAoztcrRubE5zHeyBOMaErzk0laO
         Q7/UrBLDo0kLHQSZB0tw5G2qPixagRBtwdTEMbAQy0Qwp1m4JPKqjXAWMDbqTSfsE2Cj
         R5yboZG9dLo9KIlr2SqYgWc8cWEm3EP1F3mzDB2u0FCaYkl/kkO56GgENDSaYaUglojE
         tkZy/0cdQjScIDcwenZ6MKMQSInitubCBwaZTw4Ae9W34vOzThX9FzMt0GZT1ze0Bhta
         rurQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749559046; x=1750163846;
        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=mrCuqKhFUgUTqPRFOhuZ8VovxipnNe4BanDZ77aEmcw=;
        b=hqZenDiwU+10HvqvqpAXWmH/xC/Wl0Y8vrUq8e7akmvg1WvOoqDIcPUzFBgaDxdpug
         44kNlkgBy1HLjh9rPQTFe9lAFBG4VlJeFRw973iwYtzle2Z9mMzgbLJToxh6h7FONkNy
         6X9q/iXeTAZYWOiMQVLoQpLreNsGcrpSS5ZIy4Uitj4HCTdxmmCUHAdj3WRQIQNTr4m3
         rYtqLIQyThI/4OSrzeWZg3gp0M+H6Nik+tnRNtVNQEq3Teftgvn6EKp0fL56cgQ0d1aG
         GfxQea9mV8bBaTVwtu1+VF8FLQyZxWjujwKRZt45nbMcTqZilnpLVEhPOi9jsTLxAg+u
         Bs1Q==
X-Forwarded-Encrypted: i=1; AJvYcCW459kA/DbmBEvLr/g08BC6fer2fdrgPOaLyfnRWxxYnzDTvP0nHLQtbm1ldl4wJ0fhpQtB81LHt+w=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx5eezrfGGq3cFkzZcRYyP6dTCVP6h2zsE0c3k30y9P3Vnei9gU
	4DQYoegRWivG8O3yBUBO8K9uda0NwJs5PUf1DungwoP+k1Fr0sDAM6mqAbjFfQiHBA==
X-Gm-Gg: ASbGncs7Sj6xXoSEIsTHzMauoZuM7Zl8SufYcxYtUe1X0uFmo4AtTlMuQaXVwZzsUuq
	YSA9K/W8wX6qa5Ji+4YNsvqFkT/ycg4Yrdiufu8EA+Ki8wFYEmUz9sEhrgBvpP739rvGreD8zyu
	ygFgGG7kfBwS5zQ6Nn5b3I+F4PIUOIQu7VzTQuP5cmij4egGMJbF/GFm3QgPh66Z9Ucm5yIbMua
	/2fzC2ad53OOyNNj9LerOVqHv8HCC9NjXT55w4aBM9WRIFUuqQk5AS0lH/wCrDSvZnTaQg6HSfN
	4Zh5CBJkW/CUQwEVvqVcrVEW2DlxxxxVVA/yr9lU+/tr3aareYC7xQ/4Fek8WSjmkpEVcNx4XOU
	zjOPaw4pSV0Smghf6iz2xce/9EH/3CYJ9/ZJ7BL0DwWOrgrTUPS/HkSNJfq3nV1fcEKmDhZbDYm
	XJ15ve+4VYKyPeUCvg6zh+
X-Google-Smtp-Source: AGHT+IHk1TIXnL7iSxQs9uuEX6kzC/QDR4bvlxG3KNz3Bd1K40HQZuNkV5CbZSMamNKGbG//OYwnwg==
X-Received: by 2002:adf:eb87:0:b0:3a4:f7dd:6fad with SMTP id ffacd0b85a97d-3a5513f5298mr2293811f8f.14.1749559046345;
        Tue, 10 Jun 2025 05:37:26 -0700 (PDT)
Message-ID: 
Date: Tue, 10 Jun 2025 14:37:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 02/11] xen/page_alloc: Remove `claim` from
 domain_set_outstanding_pages()
To: Alejandro Vallejo 
Cc: Bernhard Kaindl ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250314172502.53498-1-alejandro.vallejo@cloud.com>
 <20250314172502.53498-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: <20250314172502.53498-3-alejandro.vallejo@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.03.2025 18:24, Alejandro Vallejo wrote:
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -523,7 +523,7 @@ out:
>  int domain_set_outstanding_pages(struct domain *d, unsigned long pages)
>  {
>      int ret = -ENOMEM;
> -    unsigned long claim, avail_pages;
> +    unsigned long avail_pages;
>  
>      /*
>       * take the domain's page_alloc_lock, else all d->tot_page adjustments
> @@ -549,28 +549,21 @@ int domain_set_outstanding_pages(struct domain *d, unsigned long pages)
>          goto out;
>      }
>  
> -    /* disallow a claim not exceeding domain_tot_pages() or above max_pages */
> -    if ( (pages <= domain_tot_pages(d)) || (pages > d->max_pages) )
> +    /* Don't claim past max_pages */
> +    if ( (domain_tot_pages(d) + pages) > d->max_pages )

In addition to what Roger has said, how can such a behavioral change come without
any caller-side adjustment?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 12:46:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 12:46:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010738.1388910 (Exim 4.92)
	(envelope-from )
	id 1uOyNR-00077J-35; Tue, 10 Jun 2025 12:46:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010738.1388910; Tue, 10 Jun 2025 12:46:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uOyNQ-00077C-Ud; Tue, 10 Jun 2025 12:46:52 +0000
Received: by outflank-mailman (input) for mailman id 1010738;
 Tue, 10 Jun 2025 12:46: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 1uOyNP-000776-3s
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 12:46:51 +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 f97fb559-45f8-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 14:46:49 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-442fda876a6so48321625e9.0
 for ; Tue, 10 Jun 2025 05:46:49 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a532464e3csm12395498f8f.99.2025.06.10.05.46.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 05:46:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f97fb559-45f8-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749559608; x=1750164408; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=yDfzxJo6IHn2ojseQNrafzKIlvdEC0AItMszJe8rsEQ=;
        b=GsHIw87q2AosZO2HrqVzKYO+e+RJd5X6kzHk773rDIRQ1gBY8zopRmRW4a27/w4zdH
         3YquuhjQZdhISe9cwcz4oYEq9pG949So/XwrL4sy6bHeWlqeScN2cP/TpI9/amuCKU1J
         rERkYETVnyh/kx0ICWYBTIDnGRwJt81AamzHuT7ssP3Rm1H2mVFafVsPkBz4FcYG+g/K
         wl9+9tQfKFjFPgT9sZuLZq0XwmbKZdivbh3v6X+3teJLvPQKRhjgCFV1fDrppuAzjwX5
         d01yRCTSH9eCi8hGpIYneHDFlq7H10aYat+qGQYHu9kpSr5WkuZVSQkox6TWDrpYAeNf
         1QaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749559608; x=1750164408;
        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=yDfzxJo6IHn2ojseQNrafzKIlvdEC0AItMszJe8rsEQ=;
        b=V9+gll6ft4xgHKADR3E0D3nYIFhQRjU+n0bKOisPLYYASyjXSAy228+/+OTGAum7Kx
         o6mWd0Wd5PLmF02g88orOIJLeZaVUdt6Po/lNCn15zoFAmkL9k9UPSAYYFFRBGyBz9kc
         7fknqPiQ2xBuCvoUFok7gxbQ8CLsaYDjhPr0QYh58oI/W0BcFCvFZJBoqZCHoBks0dXU
         hmxyojYxK+HG/VHgJWWBgO/Spf1HK/zE1HvAniRM3XmnXRMJuUNVojsn3dHCsc/NwktK
         EkMRfH2ZnwwbBF+dMe0k2TwQMfkUb2DeTQR0kr/GTPUpQKaEyScAEt0fKtoJtsx68OZ5
         DpmQ==
X-Forwarded-Encrypted: i=1; AJvYcCV01jH3P2UeqQ3zseYDOqsMZM/Y/d4+cFr2U63cO/VaVh8O0XM69ewMZQ1CDNw8/B8ejVawAmRP4Ts=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz3cF0si7nqnEtEsm7x8arQNPSgOmmwNMgGMV5mcQJbru3zVP/D
	sVh8qthOyHp3nHNhxDrpUgOny/33NxszRFMNHR8IjMYWE+4rpFnYMwA9arGxqLtyIw==
X-Gm-Gg: ASbGncvY2CfPYCGaL8O3lllXaWtJtG06FPY9UubyOvW6SMx+mT9FHN3e+DFREmk+PDm
	k//M5udD1Og77VmlLcletmLvPmmxclSRD7JsFZxIyeaQs1Lc3e9/I9aSzjniMygaesLvOT/5A9x
	QGEgRpxP6RMwbdWWiubbzXarZbV1wjOSaaBVx77zi8KUWyzRcUKNY3WqfArs2/oqPhVuHU+SvrZ
	NzMXiKdYVjkfCk4GE2lIlPN/LYpDQ3ubYymtQzFgwveBeY0dQycvphPuK5k+0q69HeYjxngSEqK
	ZIo6kBN7oaVwhbOs4RF9hCMNXw4ALbuDc1yMsZQ7DE9qD17hPINrkcfBG3kPTHWMeiN9tYOO5kG
	ZYnD4q/fvuuMH2QVGnan0WsnxlH0LwlhVw9ys3I9AzRUICIKB2Lk5wbXozZJcu9L0KY+9bt8shk
	4+ufShWufQUB0CPzMhUHpJ7xwRzwDfyBo=
X-Google-Smtp-Source: AGHT+IFcizkwiewT60FnJVnN9g1Q0MgChMgA74ylY3euXamUBKI/dq73UeUVTTfpCxWt9IKN7kR/Mg==
X-Received: by 2002:a05:600c:1913:b0:453:9bf:6f7c with SMTP id 5b1f17b1804b1-45309bf71a7mr101084055e9.9.1749559608442;
        Tue, 10 Jun 2025 05:46:48 -0700 (PDT)
Message-ID: <6f705281-f7e3-4929-ab56-5fbe4e1db14c@suse.com>
Date: Tue, 10 Jun 2025 14:46:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 3/5] drivers/char: make dbc_uart_dump() a bit more
 useful
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: 
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 25.05.2025 16:15, Marek Marczykowski-Górecki wrote:
> Make it safe to call also if xhci console is not enabled. And make it
> non-static, to require one less modification when actually using it.
> When using it, one still needs to add its declaration in some header
> (or just next to the call site).
> 
> Signed-off-by: Marek Marczykowski-Górecki 
> ---
> IIUC Misra would not be happy about a declaration of an usused function.
> And I'd rather avoid extending DBC_DEBUG scope beyond that single file.

It's not going to be happy about a non-static one without declaration
either. Misra-wise this is pretty much a no-go.

Jan

> --- a/xen/drivers/char/xhci-dbc.c
> +++ b/xen/drivers/char/xhci-dbc.c
> @@ -1498,11 +1498,14 @@ static void dbc_dump(struct dbc *dbc)
>                readq(&r->cp) == virt_to_maddr(dbc->dbc_ctx));
>  }
>  
> -static void dbc_uart_dump(void)
> +void dbc_uart_dump(void)
>  {
>      struct dbc_uart *uart = &dbc_uart;
>      struct dbc *dbc = &uart->dbc;
>  
> +    if ( !dbc->enable )
> +        return;
> +
>      dbc_dump(dbc);
>  }
>  #endif



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 12:49:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 12:49:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010743.1388919 (Exim 4.92)
	(envelope-from )
	id 1uOyPT-0007dv-CL; Tue, 10 Jun 2025 12:48:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010743.1388919; Tue, 10 Jun 2025 12:48: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 1uOyPT-0007dn-9Z; Tue, 10 Jun 2025 12:48:59 +0000
Received: by outflank-mailman (input) for mailman id 1010743;
 Tue, 10 Jun 2025 12:48: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 1uOyPR-0007dh-OV
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 12:48:57 +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 44f46322-45f9-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 14:48:55 +0200 (CEST)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-451d7b50815so46819485e9.2
 for ; Tue, 10 Jun 2025 05:48:55 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a532435fbfsm12339136f8f.64.2025.06.10.05.48.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 05:48:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 44f46322-45f9-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749559735; x=1750164535; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=QVkMHdz8eFSaowDjP2uT7Oh30l/l+37j7QGCC6KJLaA=;
        b=LomDaOIR4bb/Hk+WM/ZqMbyBFOK2EHlXbbPr8Y5trehjERpmwi2NFVvPjMSG0xT8tr
         ntJizuzHqEzVwXkzbFaD3RAXTQDKUmejsIhyzR2J8IY23UQfndiPZMw9gmdSf5UCI5Fv
         gJXhs+cvZ+OanM2SKTxjHXuNRaoW9d7OGNGvn+bUf/EAToQ6LZPlLZcK9oIYA8tqC4s7
         q2bCs4+Ol0/YQ2Q3t4N/So/f1hoxL1LphFySzLjmdKF+1Zq2KgtF1Ng3Pa9P+XDkDsP/
         Rlb++GrwD5eEi44sRAGCeDS2wL/EOzaN3zpkL+dNuVEPn+yb1Io4VdRkrek9iOIIg7Xx
         pT6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749559735; x=1750164535;
        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=QVkMHdz8eFSaowDjP2uT7Oh30l/l+37j7QGCC6KJLaA=;
        b=pUgE/BFcwUqpgF5Uz/201NnitNTgLRujZ+cpES0IivPdnKf5OinqVsb9lbi72jgvb6
         62JC7eeIvWiB25DU8IjCKIBx9a4Yl25dESCKpiVSlhb7SYC/3eU4evvBbAah3d9dkc9m
         YOkmd1Ym+unpkBwlKM1cSTRwr2ysEjm9O8BaYIfQewlIiihl+dKgUiJlioD/+DZxHB8S
         nU+aNQK+FSV4GXjZtJDMZzFpLCxH412tsEkOnNY2l6BizfGIggv1JdKCpkfNND1a8T2c
         eCNeaHH0A1TsXMwN5VBcqRCfHfhmm2y4rDWQs/YtgQEgD4wrUNl9ihiMWTVT73TSO1Lk
         MEQA==
X-Forwarded-Encrypted: i=1; AJvYcCV8NFt+L3CkHm6A/ceSBM0FWD+r6Pkk+yzlqcTSXZaZPy28INVqAizjLDZC8sClQlRzFkgUJD8GPps=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy0zbAYU5jxkhMPSBYBSK7YqLQbP5RrzVGkKlZAkMAVTUPwafz4
	LkvQkMLwUy4JUHuvcwvj4Uh4aU9oNW/scdwvn7uqiF1J27a8OVwj6M1kd1jj1Xcxcg==
X-Gm-Gg: ASbGncsf5J1Dcyto6w5SRQyLkXA2et1Bn7Ezg66rOrDzxVwiGoBOhvAlKHp4XIHuIiU
	LSixbBhogag1P+nu/Ogt3NhtbJoEcGVAF4M4s7Mt0LVW83Oy7ZVSyRhz99PqNN7rRZFqvMS5V5h
	2KubwBMhYqDYbUTAZs9pF9oAxpanM7IyQny1UrYqUdzCMycf9sAnZGUY9N0QvbYxlmt92I6w2hz
	L0e7HQfoYLTuQORdZuQk8FcMJ2Gblr+QX+047ov2eiFwY1DiYAaCZJAS5JasaTNWL1fRXGYVGV8
	H1/BmF5Yy8TaDW++SL1vTc/yjXrW080Y8sHOThzrykyeZH5oqP1ySRU/ojlDcSg/X9hMrYXyfGu
	T9MDzO8xawK83YNFpYDvxs0WheBIVk8FugkJNZU6J4Z7Nqi/yY27S1v/npQfmKzadib4DdpWQ4+
	aU4eI2deb1H7I4+hgBe0macyNGqMxAuB4=
X-Google-Smtp-Source: AGHT+IEzqQZSchYocEd0xEEcKn6TL9V0Iu7nePF4uBGv3HcEgZOa1vpLiUTvd5YdhkE+UdNjpLv6Xw==
X-Received: by 2002:a05:6000:381:b0:3a4:d6ed:8df7 with SMTP id ffacd0b85a97d-3a531cf55d5mr15300580f8f.59.1749559735053;
        Tue, 10 Jun 2025 05:48:55 -0700 (PDT)
Message-ID: 
Date: Tue, 10 Jun 2025 14:48:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 5/5] console: support multiple serial console
 simultaneously
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 
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: 
 <98ff383ff2ee3dc162b2d12afaea2b3f1406d99e.1748182535.git-series.marmarek@invisiblethingslab.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: <98ff383ff2ee3dc162b2d12afaea2b3f1406d99e.1748182535.git-series.marmarek@invisiblethingslab.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 25.05.2025 16:15, Marek Marczykowski-Górecki wrote:
> Previously only one serial console was supported at the same time. Using
> console=com1,dbgp,vga silently ignored all but last serial console (in
> this case: only dbgp and vga were active).
> 
> Fix this by storing not a single sercon_handle, but an array of them, up
> to MAX_SERCONS entries. The value of MAX_SERCONS can be chosen in
> kconfig, the default (4) is arbitrary, inspired by the number of
> SERHND_IDX values.
> 
> Make console_steal() aware of multiple consoles too. It can now either
> steal output from specific console (for gdbstub), or from all of them at
> once (for console suspend).
> 
> Signed-off-by: Marek Marczykowski-Górecki 
> ---
> This was posted before as part of initial xhci console submission, it
> reached v6 (but last changes were in v4), but wasn't considered useful
> enough to review/ack:
> https://lore.kernel.org/xen-devel/Yu0XHUhsebE+WG0g@mail-itl/
> 
> Since I needed this feature again, to debug xhci console issue, I'm
> including this patch again in the series.

Beyond this narrow aspect, has anything changed in the picture, compared
to what was said / discussed earlier on?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 12:52:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 12:52:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010751.1388928 (Exim 4.92)
	(envelope-from )
	id 1uOyT0-0000ud-Vt; Tue, 10 Jun 2025 12:52:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010751.1388928; Tue, 10 Jun 2025 12:52: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 1uOyT0-0000uW-T4; Tue, 10 Jun 2025 12:52:38 +0000
Received: by outflank-mailman (input) for mailman id 1010751;
 Tue, 10 Jun 2025 12:52:38 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uOyT0-0000uQ-3h
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 12:52:38 +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 c8f6e0eb-45f9-11f0-a306-13f23c93f187;
 Tue, 10 Jun 2025 14:52:37 +0200 (CEST)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-4530921461aso20679305e9.0
 for ; Tue, 10 Jun 2025 05:52:37 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-45209ce5045sm140054855e9.16.2025.06.10.05.52.35
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 10 Jun 2025 05:52:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c8f6e0eb-45f9-11f0-a306-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749559956; x=1750164756; 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=QNwNGuZDjfSKW+hJnEnicX5F+61CXU5mF5s0DDQPyEo=;
        b=A0nwNhyHPM0/deqGnyBWXqFhvsBIC5pPh5e8VBQrNi5loKm6HUZSQW/9He6itOkcvH
         vnKna4rODjUI8czAUdoos8eD3t2V7GiRoU6LriTH7f18WHepE+l5mynj/TnfJEWGKABW
         JRXLRK93W6AnmexqXgN5zI3jp92dBv19Q1jxg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749559956; x=1750164756;
        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=QNwNGuZDjfSKW+hJnEnicX5F+61CXU5mF5s0DDQPyEo=;
        b=QwJcpKVwvZxjKhC0ZB6quDwht0fAZqOmf+qyy3Mf/d4PoYdlrBcmh7rLzNMIMot+h1
         MaFxqvBn5Ok4gVncnUIZ3Y69foNO1P/ow1gYkRpMq4hSK/W2NeKC4Zao4IM8rBoVDyh8
         dStwPs2AEEQxCWK+mdZclN34OCWVra1HufGlzd5Vi7zaK2CfmHYGg2G76e1lE/6n6B4L
         Yk52a0Mv2Orah1kXzEmPwwtb82xWWb5Q8dlUo3zo119fVIAR6ns+8F20TLtMMyniOeSq
         NIdVWX2FPPNOOcO2KlIHSFjZEZzTimUUbc6p/Gw0a+4vs8OEWSOdEeFPNfI/+gki5gtj
         ZSiA==
X-Forwarded-Encrypted: i=1; AJvYcCVmWxq7Ffpajc2g20XkUbjMUTZeR3mUNTlHBfnpPLZurBoSi/qXBHEStZlvwwr1uCY8SX4fJ9h9L2c=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw9RpeC6n/j7ND1vlz4lVyVSLGFmddnaJlCfotpVfs+lsssk+vO
	KkTFCoNZUtQef1ewCx0+iF7zpZc2lmTTsVNd8p/SXyfh74HNWIBVJb0X6r/eAuMxSMc=
X-Gm-Gg: ASbGncuM8zrf9m0WmlewLAOpS/0LnGhaX+fXnbaeD4LEV/aJjaDM6eS6d0B3VGYGHeR
	gYgasymz8Y18+h4v+lMNh0FcxXNIs2X0gJhgNjF1fvqERUtshc+JiWVe0GThR+4XeS8MRNNjLZp
	ZeebBG4R9P6hl7bW9O6xZ4nCIQOMO1jSB8aqCePEzS91wEcCiAOvZGhCS23ytsRqE0EmKYk8Sey
	WkhrJSUUPR//duhF5LHdteK0ahLkzsJMdgJyLqTpyWzZ/9KYe3ljJxKGD07kqNI2jhJKa/JDMXD
	qwQ+CEhODbJ0kqg0+i1t+b4znO9E1evEv9dL/AG4Njt1FR3lN5N8MZz8DkHljUr7EtieIAWsWO1
	npoDomcNLT4sN6oP6KciN6FbjPIzXMTzm0rI=
X-Google-Smtp-Source: AGHT+IGmy475I5ChoYkxK9sPKY1SL97jwihsfcdPWwI+lLhob3jS+PnFAN3hOM1t999T6d3ccfW8DQ==
X-Received: by 2002:a05:600c:3d94:b0:43c:fe90:1282 with SMTP id 5b1f17b1804b1-45201417fccmr141387435e9.7.1749559956263;
        Tue, 10 Jun 2025 05:52:36 -0700 (PDT)
Date: Tue, 10 Jun 2025 14:52:34 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Alejandro Vallejo , xen-devel@lists.xenproject.org,
	Bernhard Kaindl ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH 02/11] xen/page_alloc: Remove `claim` from
 domain_set_outstanding_pages()
Message-ID: 
References: <20250314172502.53498-1-alejandro.vallejo@cloud.com>
 <20250314172502.53498-3-alejandro.vallejo@cloud.com>
 
 <89d4250e-20aa-4515-8199-7003afb0bcbf@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <89d4250e-20aa-4515-8199-7003afb0bcbf@suse.com>

On Tue, Jun 10, 2025 at 02:23:26PM +0200, Jan Beulich wrote:
> On 05.06.2025 18:42, Roger Pau Monné wrote:
> > On Fri, Mar 14, 2025 at 05:24:53PM +0000, Alejandro Vallejo wrote:
> >> With a single global count for the claims it's easy to substract
> >> domain_tot_pages() from the claim so the number given in the hypercall
> >> is the real reservation of the domain. This is the current behaviour.
> >>
> >> However, a later patch introduces exact-node claims and those interact
> >> very poorly with such a scheme. Since accounting domain_tot_pages() in
> >> one case but not the other seems strictly worse than not accounting them
> >> at all (which is at least consistent), this patch stops substracting
> >> tot_pages from the claim and instead checks that claimed memory +
> >> allocated memory don't exceed max_mem.
> > 
> > Hm, while I don't have any specific interest in keeping the current
> > behavior, XENMEM_claim_pages is part of the stable ABI (it's not a
> > domctl), and hence should be stable.
> 
> Is that true? It sits inside a
> 
> #if defined(__XEN__) || defined(__XEN_TOOLS__)
> 
> which generally de-marks unstable (tools-only) interfaces.

Ops, my bad, I didn't realize it was inside such region.

> >  Note also the comment above the
> > definition of XENMEM_claim_pages how it states the specific behavior
> > that you are trying to change (and which should have been adjusted as
> > part of this change).
> 
> This is the more important part, imo.

I see.  Well, it's in a kind of a weird position then, because there's
no equivalent of XEN_DOMCTL_INTERFACE_VERSION that we could use to
signal callers of the changed interface, like we do for domctl.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 12:54:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 12:54:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010757.1388938 (Exim 4.92)
	(envelope-from )
	id 1uOyUS-0001RN-8n; Tue, 10 Jun 2025 12:54:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010757.1388938; Tue, 10 Jun 2025 12:54:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uOyUS-0001RG-6F; Tue, 10 Jun 2025 12:54:08 +0000
Received: by outflank-mailman (input) for mailman id 1010757;
 Tue, 10 Jun 2025 12:54: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 1uOyUQ-0001RA-VK
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 12:54:06 +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 fe175ccb-45f9-11f0-a306-13f23c93f187;
 Tue, 10 Jun 2025 14:54:06 +0200 (CEST)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-452f9735424so13255255e9.3
 for ; Tue, 10 Jun 2025 05:54:06 -0700 (PDT)
Received: from [192.168.86.29] ([90.250.112.104])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a5323b33c3sm12379957f8f.34.2025.06.10.05.54.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 05:54:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fe175ccb-45f9-11f0-a306-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749560046; x=1750164846; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=WNlZXeMraDrgtGtTXbICWe/QhiwuILX4YO9zqFplcpk=;
        b=rl9kSINQ1pqZRxRzdLuXL0REXlpnmSPM8Qdn0KyYkcHf7l/x3njgpLxjMBYp9G3Me3
         HmFFhJIpTqGCkwpu+aBTDIFCzaoIwUMIzEosDOO6GpFMTrBrUziPvzJdTUI2XJxxQ7lR
         OX9wNhzj+W3a8bDKRstUAGyVSMp1kwkBnbB+c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749560046; x=1750164846;
        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=WNlZXeMraDrgtGtTXbICWe/QhiwuILX4YO9zqFplcpk=;
        b=No3JMkgqCYLEyYoigolfeQ56Esv8KMlXb4CGpReEJIiJ3Q4CJs/O5oxCDZo/mdi+o1
         1syzmUohV5jyOr64n/17TizRyDBYVoRdTbcAHd42/VibOHWFYS701BE/Zpq4gqTRLqoA
         O9oIPZ1soqvTUviYeDH6bhrT/HdyapI58f2ywOHW3B9iBQ4+BInnuc4Ym/tYysZ2V5ii
         fdyt05r/RsHrG7mhZkI1bvSTZ3/igT9GfWASsL9Qbt7at2CSxQ2WOWzW6sxtBj+m95ep
         VNixHWrLYLibYVWwmZ03LPGO0DnuyqaMVPEnzaeS8EFMtdrzNzuTYg36zPDCLBSPox1y
         mO6w==
X-Gm-Message-State: AOJu0YwqjH604638y7OPui7NND8wE6THuLVwcAbFhqlqtpKdCpp3GlEq
	QuKZw1CBDY3FUJLYcFuRB/TyzDcLJbtpaVzUBuI72ejDv9w/Pjxd2IoNFuBKmiT+lAA=
X-Gm-Gg: ASbGncs5xzT16yWPrhE5Zgnbs7JyiAzn94dEjvA+bcx2YPUTj9KBDB+E/CC3rzJihl5
	GMAOSNVC88pS3c5QMTgAknV4A/UaEwMLNYCOCg9TZno8EcpdvWbcVF/ugQxTzjGluuwg7F+ujMo
	Pb0qKH1DsgzV6zdbTWy2aYipnYahwLf794HY+bvzyMReq29fhCLUdoR/ZnP/D3nMyxFEELbg+0I
	euNLFDJK3jgNWE0fMpbwySoVRqCFIFMa2tdi0LVuioPBsS/UNQ2awTTxsfmI3OuRivkcij47jwp
	X4eJgQy/Sazf4N3x79UZVCA8S6Q+0She3pO4aaSdN7fDZW2ODuc5CYMLwTElUEIzLUt9de9/IbM
	=
X-Google-Smtp-Source: AGHT+IFTQoa5AB2hLrhsfmA7M8Pw6aQPFwJ5PP0J2tzzYyVHbD4gfhZWxg+uJhXI2n0bmkTw5ukYww==
X-Received: by 2002:a05:600c:a08d:b0:442:d5dd:5b4b with SMTP id 5b1f17b1804b1-452014d4449mr170571685e9.31.1749560045476;
        Tue, 10 Jun 2025 05:54:05 -0700 (PDT)
Message-ID: <480626d3-550a-4836-adc3-0af96d7e1fd7@citrix.com>
Date: Tue, 10 Jun 2025 13:54:04 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/5] console: add relocation hook
To: Jan Beulich ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
Cc: xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini 
References: 
 <4f1889dc03ec4aa2cc0cd2bd14523a2c6f670bdb.1748182535.git-series.marmarek@invisiblethingslab.com>
 <0b17da9c-57db-4a8b-90af-e53e45cb1243@citrix.com> 
 <66cfdee6-5dc2-4139-8550-ef441fa7a7a0@suse.com> 
  
 <83c22da9-62c5-4fb2-bc2d-f34ad5956d3e@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: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 10/06/2025 8:52 am, Jan Beulich wrote:
> On 06.06.2025 17:54, Marek Marczykowski-Górecki wrote:
>> On Fri, Jun 06, 2025 at 08:26:33AM +0200, Jan Beulich wrote:
>>> On 05.06.2025 18:08, Marek Marczykowski-Górecki wrote:
>>>> On Thu, Jun 05, 2025 at 06:05:02PM +0200, Jan Beulich wrote:
>>>>> On 05.06.2025 16:51, Marek Marczykowski-Górecki wrote:
>>>>>> On Thu, Jun 05, 2025 at 04:42:53PM +0200, Jan Beulich wrote:
>>>>>>> Why is it that this ring is dependent upon Xen's position? If the ring was
>>>>>>> dynamically allocated, it wouldn't change position when Xen is moved.
>>>>>> The console is setup quite early, I don't think I can allocate memory at
>>>>>> this stage, no?
>>>>> But you allocate before Xen is moved, I suppose.
>>>> Well, I have those buffers in BSS exactly to avoid the need to allocate
>>>> them (or rather: have bootloader allocate them for me).
>>> Yet them remaining in .bss is now getting in the way. Imo moving them to
>>> .init.* and adding proper allocation is going to be easier than the hook-
>>> ary you are proposing.
>> So, when would you propose to allocate them? Wouldn't that be yet
>> another hook?
> Exactly one, yes. Given Andrew's earlier reply my understanding was that to
> get things correct in your proposed model would end up requiring more than
> one. However, the point in time where move_xen() is called is still too
> early to allocate memory a (somewhat) normal way - even the boot allocator
> gets seeded only later. So I guess console_init_preirq() may need to inform
> its caller how much memory is going to be needed later on (and what address
> constraints there are, if any). Then a suitable chunk would need setting
> aside kind of like it's done for kexec. That address would then need to be
> passed into the new hook.

How about initialising the console using _va(_pa(xxx)) of the Xen
datastructures?

Xen is mapped into the directmap (pagetable handling depends on this),
so these pointers will work right from the very outset, and will
(intentionally) refer to the old position.

After relocation (specifically, before we free the old Xen image), we
can drain in-flight requests and update the pointers.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 13:00:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 13:00:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010765.1388948 (Exim 4.92)
	(envelope-from )
	id 1uOyar-00036u-UT; Tue, 10 Jun 2025 13:00:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010765.1388948; Tue, 10 Jun 2025 13: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 1uOyar-00036n-RR; Tue, 10 Jun 2025 13:00:45 +0000
Received: by outflank-mailman (input) for mailman id 1010765;
 Tue, 10 Jun 2025 13:00: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 1uOyaq-00036h-Iu
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 13:00: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 eae77f53-45fa-11f0-a306-13f23c93f187;
 Tue, 10 Jun 2025 15:00:43 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3a5257748e1so3663320f8f.2
 for ; Tue, 10 Jun 2025 06:00:43 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a53229de53sm12177335f8f.8.2025.06.10.06.00.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 06:00:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: eae77f53-45fa-11f0-a306-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749560443; x=1750165243; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=xNp44KD4Or1m1CBQh/PgKZvs8rzRrWzGzLvzSCSzHa8=;
        b=CiWpFLV8ox1sKhJhgf+T5Zr9IMVckWQsZoiD/V4eH51wxDX9BRpmQTX2a7il9FQjNl
         EJeexgWI4RIfyPavXW1gxoFJzvavpHchnt0zpbv3HTY/eQ8MXQNamLUeNi1rwy/u3Qmm
         J843zWnZmdMPJPH04GrpGxPIIWzjxoB3E6PehFjw4OEx4T9bQwUwBVnTesIEKBN5t7MO
         1UclqYDGcOvr/OL85G7JQ8t4LTfpmWt+UrIWY3C3GAAR23tU3vBiasn8HouSTfYSbRTs
         OSsSN1CA/G3sFaILP0L9fVUSFulCDwaIWsA3TIaxxJ1fDPDJR9OANEp+C/cjqLcO6YAb
         g3Ew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749560443; x=1750165243;
        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=xNp44KD4Or1m1CBQh/PgKZvs8rzRrWzGzLvzSCSzHa8=;
        b=nmTiyBB+SHS2ZIusO0xr3hE8WbAy+p65R3TJ96NWiB35CXsusrlcrBBd9Fwxzl9dGU
         t1v6jNzLAhjxu6bavEQ1H5dcJQMh5IK/Zpvqj1MwubrPONjPoHiV57x+yYlbxIGx3Esp
         qjPsXHO6yjqb0YxltDG2Cs83Qh0t+afFInC/aDTHqR3nQU7clzb7Pq8o5y+rgTtrNf+m
         coaVusT8AunFSyLMrerdzQ6oC0+Kn9TtFp3rlJVe/0Wso6b9MeBC+f3JG17VW/dor1Kg
         2Z4p4gCre1vP2xC3lJ3IJcPRGGmMfXvXl38Saz8GO2f6y4wxPSw0HnDXz9fk3R7/V8gN
         6TlQ==
X-Forwarded-Encrypted: i=1; AJvYcCWxmMLPh7q+JUMHU4g0Mj4eOQ1MaUCQRUFb2Aek8bLKvkS7rpKUj8X79PSNxYr+lkpxB9PCJ+GJ6Js=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz6W4aqhQqIHzxgL0UzQwDx6+ExzJz9W9eQ7I+DPvhTzwDyNa6y
	Clo8ZaSEz4PMDHhoHVCqv+m1Hmkozp9ELlUGRF1OWIVLYNxVh+9p7f2j4kNrpwjSWw==
X-Gm-Gg: ASbGncsmc9oAB11GJLGA9juFAO4tJ64QmsIaqyccnNuDsKWcLIFPbvxDGz4oEapFTYL
	kiYLQSkdE79ol1VSOF8CQB4mXor8lLl0B+/k7oxB5xFGxl+Th0eIUgCaoGZCWGwWiCUu7U3JYwp
	/jO4TMF+AEhHs5SOAAKjxhVM3Ee0nN1Id/9x7o3uwa7D0FtK2NauCZcVbdOmdtejfgFXZC1lfDX
	s/I5+lOuXIh9FhNAi4VeYXfKE/gMlkQI+7GTaZ9KrP6MQNM6xtjUuGTz3HcrzaTI7NxK5YrLg8R
	GsMSwAwXHNM1cCa+vgy+DVfepahX0ONfwEUo//so/mitIyS/5VNwJb+nUG/OF6K8uR068U3GKWx
	k6tIikT4ukfJLwC14JWxKLGV+XbEhx02DMeMO8qZAZ802pvGxGddjaKx+ddEpMNa9xfTh0CrwKe
	7KBzShCLMqa/AlRJhygk8j
X-Google-Smtp-Source: AGHT+IGSIWt8/uaa+mouaHSon9+mLvPQTxFyLnP2VHzpSfUqC1ZIHqNUIzdquMQBqmkXnGPhJxGn1A==
X-Received: by 2002:a05:6000:2dc9:b0:3a3:6415:96c8 with SMTP id ffacd0b85a97d-3a5319a78fcmr12756224f8f.41.1749560442787;
        Tue, 10 Jun 2025 06:00:42 -0700 (PDT)
Message-ID: <1a73c720-012a-4795-9f47-f9c23b643de1@suse.com>
Date: Tue, 10 Jun 2025 15:00:42 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 03/20] xen/x86: remove "depends on !PV_SHIM_EXCLUSIVE"
To: Penny Zheng 
Cc: ray.huang@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
 <20250528091708.390767-4-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: <20250528091708.390767-4-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 28.05.2025 11:16, Penny Zheng wrote:
> Remove all "depends on !PV_SHIM_EXCLUSIVE" (also the functionally
> equivalent "if !...") in Kconfig file, since negative dependancy will badly
> affect allyesconfig. To make sure unchanging produced config file based
> on "pvshim_defconfig", we shall explicitly state according Kconfig is not set
> 
> Add "default y" for SHADOW_PAGING and TBOOT, otherwise we will have unset
> values when running make defconfig based on "x86_64_defconfig".

I fear I don't understand this, perhaps related to me also not seeing how ...

> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -143,7 +143,7 @@ config XEN_IBT
>  
>  config SHADOW_PAGING
>  	bool "Shadow Paging"
> -	default !PV_SHIM_EXCLUSIVE
> +	default y
>  	depends on PV || HVM
>  	help
>  
> @@ -175,7 +175,7 @@ config BIGMEM
>  config TBOOT
>  	bool "Xen tboot support (UNSUPPORTED)"
>  	depends on INTEL && UNSUPPORTED
> -	default !PV_SHIM_EXCLUSIVE
> +	default y
>  	select CRYPTO
>  	help
>  	  Allows support for Trusted Boot using the Intel(R) Trusted Execution

... these two fit with title and description. The justification for removing
the !PV_SHIM_EXCLUSIVE here is not "breaks allyesconfig".

> @@ -288,7 +288,6 @@ config PV_SHIM_EXCLUSIVE
>  
>  	  If unsure, say N.
>  
> -if !PV_SHIM_EXCLUSIVE
>  
>  config HYPERV_GUEST
>  	bool "Hyper-V Guest"
> @@ -298,7 +297,6 @@ config HYPERV_GUEST
>  
>  	  If unsure, say N.
>  
> -endif
>  
>  config REQUIRE_NX
>  	bool "Require NX (No eXecute) support"

Please don't leave double blank lines.

> --- a/xen/arch/x86/configs/pvshim_defconfig
> +++ b/xen/arch/x86/configs/pvshim_defconfig
> @@ -26,3 +26,8 @@ CONFIG_EXPERT=y
>  # CONFIG_INTEL_IOMMU is not set
>  # CONFIG_DEBUG is not set
>  # CONFIG_GDBSX is not set
> +# CONFIG_SHADOW_PAGING is not set
> +# CONFIG_TBOOT is not set
> +# HYPERV_HYPERV_GUEST is not set

This one doesn't look right, simply by its name.

> +# CONFIG_HVM is not set
> +# CONFIG_VGA is not set

Just to mention it - I'm unsure whether adding such at the end isn't going
to cause issues. But maybe I'm paranoid ...

> --- a/xen/drivers/video/Kconfig
> +++ b/xen/drivers/video/Kconfig
> @@ -3,10 +3,10 @@ config VIDEO
>  	bool
>  
>  config VGA
> -	bool "VGA support" if !PV_SHIM_EXCLUSIVE
> +	bool "VGA support"
>  	select VIDEO
>  	depends on X86
> -	default y if !PV_SHIM_EXCLUSIVE
> +	default y
>  	help
>  	  Enable VGA output for the Xen hypervisor.

Like above, this change also doesn't really fit with title and description.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 13:01:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 13:01:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010771.1388959 (Exim 4.92)
	(envelope-from )
	id 1uOybg-0003fk-6v; Tue, 10 Jun 2025 13:01:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010771.1388959; Tue, 10 Jun 2025 13: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 1uOybg-0003fd-39; Tue, 10 Jun 2025 13:01:36 +0000
Received: by outflank-mailman (input) for mailman id 1010771;
 Tue, 10 Jun 2025 13:01: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 1uOybf-0003VU-5e
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 13:01:35 +0000
Received: from fout-b1-smtp.messagingengine.com
 (fout-b1-smtp.messagingengine.com [202.12.124.144])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 08588eab-45fb-11f0-a306-13f23c93f187;
 Tue, 10 Jun 2025 15:01:33 +0200 (CEST)
Received: from phl-compute-08.internal (phl-compute-08.phl.internal
 [10.202.2.48])
 by mailfout.stl.internal (Postfix) with ESMTP id F2DAA1140138;
 Tue, 10 Jun 2025 09:01:31 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-08.internal (MEProxy); Tue, 10 Jun 2025 09:01:32 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 10 Jun 2025 09:01:29 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 08588eab-45fb-11f0-a306-13f23c93f187
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=1749560491;
	 x=1749646891; bh=pRcD5pALVM0dFl9dfhRKDUY0teVuhxRxNF8HPHYofwQ=; b=
	cXdel6H68HXY5s19eg0J3nO3qUi7svHFC4JC4f/y9kGwCgUvogumIEp5V/aWSnNP
	s6FbEwcKw6GESxTkT/WmJX3JYj0N8MHqnTd358R78QzT543oCar0EVbioh+GaxeQ
	IKdyRli4NVgyYYBJf7Znh1YEam2uhN3UyC9iXMfzDwfzyr5pQW6TVOAkoy2PjUJE
	DZL6YHamUha88N2C5yL81Gm8Of+FRsuJOfaNlQqDpcL3fsRX26oMUFxy5nMt3g71
	S/TiHeujBzMvQlDNqnFDrXIjpblLLXVJWy2YjRcAs/VsFQfx3ir1bXg1ezsgzooU
	dIIkF+h+fredSB70K1OOrg==
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=
	1749560491; x=1749646891; bh=pRcD5pALVM0dFl9dfhRKDUY0teVuhxRxNF8
	HPHYofwQ=; b=ZYBmfduLtM9Lz5yH0ngYcoL/MAyphV4r4Qed3PcGNZIU09PIgId
	wPq/gBwB27b5hnS4fmKPlir4bZ296ErZK75M2voscXHIRtFTee9HWAyfDXuTmskd
	JFOdMXqznCtWEb0LaXWrqm4Pk20xtiYClmItzkzXPPxoR3zCRZP2uH0h5a0XluDE
	yC6KcKErIzMZAW00S4txK3Czt4RzqMIB/FBMoSlMd1QqKlMFtBHjepFW+wfbYF/J
	p5chM/bHf7Hnq3b7Ag3XBnyIaQp3d1WckfgDJKV5wsqtF/zMg+pwgnGjeDUksWdb
	3ycW2T52pFm5OxkN3EaWDH5mdaG5ODthneA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugddutdejjecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp
    uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg
    hnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehgtderredttdej
    necuhfhrohhmpeforghrvghkucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoe
    hmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucgg
    tffrrghtthgvrhhnpefgudelteefvefhfeehieetleeihfejhfeludevteetkeevtedtvd
    egueetfeejudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr
    ohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpd
    hnsggprhgtphhtthhopeekpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegrnhgu
    rhgvfidrtghoohhpvghrfeestghithhrihigrdgtohhmpdhrtghpthhtohepjhgsvghulh
    hitghhsehsuhhsvgdrtghomhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhs
    rdigvghnphhrohhjvggtthdrohhrghdprhgtphhtthhopehrohhgvghrrdhprghusegtih
    htrhhigidrtghomhdprhgtphhtthhopegrnhhthhhonhihrdhpvghrrghrugesvhgrthgv
    shdrthgvtghhpdhrtghpthhtohepmhhitghhrghlrdhorhiivghlsegrmhgurdgtohhmpd
    hrtghpthhtohepjhhulhhivghnseigvghnrdhorhhgpdhrtghpthhtohepshhsthgrsggv
    lhhlihhniheskhgvrhhnvghlrdhorhhg
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Tue, 10 Jun 2025 15:01:27 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Andrew Cooper 
Cc: Jan Beulich , xen-devel@lists.xenproject.org,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v1 1/5] console: add relocation hook
Message-ID: 
References: <0b17da9c-57db-4a8b-90af-e53e45cb1243@citrix.com>
 
 <66cfdee6-5dc2-4139-8550-ef441fa7a7a0@suse.com>
 
 
 
 <83c22da9-62c5-4fb2-bc2d-f34ad5956d3e@suse.com>
 
 
 <480626d3-550a-4836-adc3-0af96d7e1fd7@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="k9kRAc7EJmbiy7Tp"
Content-Disposition: inline
In-Reply-To: <480626d3-550a-4836-adc3-0af96d7e1fd7@citrix.com>


--k9kRAc7EJmbiy7Tp
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 10 Jun 2025 15:01:27 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Andrew Cooper 
Cc: Jan Beulich , xen-devel@lists.xenproject.org,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v1 1/5] console: add relocation hook

On Tue, Jun 10, 2025 at 01:54:04PM +0100, Andrew Cooper wrote:
> On 10/06/2025 8:52 am, Jan Beulich wrote:
> > On 06.06.2025 17:54, Marek Marczykowski-G=C3=B3recki wrote:
> >> On Fri, Jun 06, 2025 at 08:26:33AM +0200, Jan Beulich wrote:
> >>> On 05.06.2025 18:08, Marek Marczykowski-G=C3=B3recki wrote:
> >>>> On Thu, Jun 05, 2025 at 06:05:02PM +0200, Jan Beulich wrote:
> >>>>> On 05.06.2025 16:51, Marek Marczykowski-G=C3=B3recki wrote:
> >>>>>> On Thu, Jun 05, 2025 at 04:42:53PM +0200, Jan Beulich wrote:
> >>>>>>> Why is it that this ring is dependent upon Xen's position? If the=
 ring was
> >>>>>>> dynamically allocated, it wouldn't change position when Xen is mo=
ved.
> >>>>>> The console is setup quite early, I don't think I can allocate mem=
ory at
> >>>>>> this stage, no?
> >>>>> But you allocate before Xen is moved, I suppose.
> >>>> Well, I have those buffers in BSS exactly to avoid the need to alloc=
ate
> >>>> them (or rather: have bootloader allocate them for me).
> >>> Yet them remaining in .bss is now getting in the way. Imo moving them=
 to
> >>> .init.* and adding proper allocation is going to be easier than the h=
ook-
> >>> ary you are proposing.
> >> So, when would you propose to allocate them? Wouldn't that be yet
> >> another hook?
> > Exactly one, yes. Given Andrew's earlier reply my understanding was tha=
t to
> > get things correct in your proposed model would end up requiring more t=
han
> > one. However, the point in time where move_xen() is called is still too
> > early to allocate memory a (somewhat) normal way - even the boot alloca=
tor
> > gets seeded only later. So I guess console_init_preirq() may need to in=
form
> > its caller how much memory is going to be needed later on (and what add=
ress
> > constraints there are, if any). Then a suitable chunk would need setting
> > aside kind of like it's done for kexec. That address would then need to=
 be
> > passed into the new hook.
>=20
> How about initialising the console using _va(_pa(xxx)) of the Xen
> datastructures?
>=20
> Xen is mapped into the directmap (pagetable handling depends on this),
> so these pointers will work right from the very outset, and will
> (intentionally) refer to the old position.
>=20
> After relocation (specifically, before we free the old Xen image), we
> can drain in-flight requests and update the pointers.

Ah, you mean to use directmap to access the ring pages. Yes, that should
work, and should be enough to not need the pre-relocate hook. The post
relocate would still be needed though (none of existing console init
hooks fits this purpose). I'll try that approach.

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

--k9kRAc7EJmbiy7Tp
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmhILKgACgkQ24/THMrX
1yzeyQgAmq+Y/Ug1zIi0Rg2V5AlPB+YeZ65onfb5omWiXxaO05H2b3BTYgl2MLdr
46UGnt977IzBOkt40o8oVVks652fuuJrwZ0Jy/dMfPsR8q43KNI94AoVy61VD/hc
P0QYWvzZqLGzWhLwD4TGRN4A2RSd4W0usQSW8SAt5EdPwT09ncLm9piZo9Aly4je
YMjkAsAQhIL+HZkm1lFS0Nm8NuH63jCapRn0IzKv9moKhg6K4GjJCqg/ffGZ63jQ
cFv9Dg8nEq7J3SzALqNW+wdmJdP8cxBiN6qwWGVjfS+zLQYbbKfpLxXznTu/3w7T
FW2UkAvmiftHuA2809N/pTK4edzdDw==
=QPrn
-----END PGP SIGNATURE-----

--k9kRAc7EJmbiy7Tp--


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 13:05:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 13:05:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010781.1388969 (Exim 4.92)
	(envelope-from )
	id 1uOyfW-0004Sz-P6; Tue, 10 Jun 2025 13:05:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010781.1388969; Tue, 10 Jun 2025 13:05: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 1uOyfW-0004Ss-MV; Tue, 10 Jun 2025 13:05:34 +0000
Received: by outflank-mailman (input) for mailman id 1010781;
 Tue, 10 Jun 2025 13:05: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 1uOyfV-0004Sm-84
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 13:05:33 +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 966250f1-45fb-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 15:05:31 +0200 (CEST)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-451e2f0d9c2so42325475e9.1
 for ; Tue, 10 Jun 2025 06:05:31 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a53229d96fsm12189776f8f.7.2025.06.10.06.05.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 06:05:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 966250f1-45fb-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749560731; x=1750165531; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=gi3pPyHFEG8zx8avEDB1D0KqiD+y6jBLgk8k2E2GV7Q=;
        b=P7YeoU/q6PpmfCpu7+/mE1IQpoM5qmIJemFKGTbjpqv0Vum7OnxrvaLKos7lQ5kGpL
         6/sy2q5YNeAxSDIXZl7274nNvH5xIdXQe5NlTnI5BIzN+2lKyKEE8sr1YAbukw/60vzf
         iX6gTbu3Y9xyiafaKVuwnIJEv1IqcjMmNqHaI2YvmwijsUlvtz1g6342Qks3MRSHHo8j
         GdNBfvT7wvn1W/OVklzTBMWjTroRkoEmJT6AtQV9L4sukrQQPRI1UDTE72mkhqPNsz2b
         A01gS/VO83BTDGiW97z1NxMeoJb5UNecl4+eFA2L8A4gpetjMGKIJkMgUZU7jyjXm9fa
         2Jyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749560731; x=1750165531;
        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=gi3pPyHFEG8zx8avEDB1D0KqiD+y6jBLgk8k2E2GV7Q=;
        b=oPttckV6uhBA61IoJS8VDomNzfwqIwHrlsIllniMh1InvSE3T5LUA9HBc36t3RoZdH
         7FHKVY/4qhzUSn8QbqePigFnHnF3FC+uyMRQjvE81iN3O1myjJrDHUiXjXw9zf3V4WXK
         QYpwgf6274vH1ZycyoJyrvXDbGpdBue0SoVDL5R3nRRNuseqqMiJMCkPJcovgprYe3Hi
         FQItecgn9eX6Fec4VRgFDtyByyWgbPMPnCgZurTrJLGuII10tX4F3k5FC6/+bG3oC2Yj
         UhPNl5UsuWLtXWu050PqMdfG/I4oNhK8kSTt19uaECAgBbPrslxnbLJJGwCTJV2p9yUL
         Guhg==
X-Forwarded-Encrypted: i=1; AJvYcCX69L3uHhsOzxM7uTKhxhXyWnE+E1h2C8iVINPiOLlnfDGav/a2YwWPbOaEg4DLUyiKPGEDTHezI5Y=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwNCr5FlZ72qESIgh3zwa15wxbbBieBsMSkcPvt0vgC2ozNlfRX
	8hGMTck21g6rLYnfu5GY14DiqPU8tnM51BI22TmnTB8isu1Z8HQaBXtgsL+5kp0Tiw==
X-Gm-Gg: ASbGnctsxDJm/0py4c8uNIOLp6AKZzDzkxok37JpsdCkJpsVKvDfTOfpSnfvZMlJJvA
	nbe/WTuDkIYpmddtm+3HNx+E9w+tZ5qiFxs1HAffR0iAqg0x88itc5XcWszFw3tADA3gBXiG3eK
	zn8fmWeQMbteC8uhu3Z+vBaqRI5yni5UO7DDmYxduQUtaHSPX3NdobI/RyAsRUlCsQYijxsIVJl
	II2SG30A46mQ42T37kXIHgpVdLsCU5FSl5IuBb8xh/FRgav3UZkLtTRP9y1kmhw/uy4c1s3ajT6
	VPl2rVTyLR8tCgVJAdrJsSgSM//bMNCD94An61Lbh+n1pfgfEiCMblmIVmy8MIdVKJkqwAX+utN
	Ti+TSgAG+EF2QbC2QXC5D9YTd2do6CZ/O2jiCmzZaN/4brihezC/m8usYAYhawKt6W19qYKVcls
	+XNCWOetMWyn33eg6ob55g
X-Google-Smtp-Source: AGHT+IGNGLafTRG/1OMOmz6DRYRAG40oF+vfbfglcbloBexFgE/l4sIwcaq+7D75ybgUcHMkGwdDCw==
X-Received: by 2002:a05:600c:3f09:b0:442:d9fb:d9a5 with SMTP id 5b1f17b1804b1-4531cfe2d25mr29619965e9.9.1749560730561;
        Tue, 10 Jun 2025 06:05:30 -0700 (PDT)
Message-ID: <51fde0e2-abca-43c8-9cfa-734219431970@suse.com>
Date: Tue, 10 Jun 2025 15:05:29 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 04/20] xen: introduce CONFIG_SYSCTL
To: Penny Zheng 
Cc: ray.huang@amd.com, Stefano Stabellini ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Sergiy Kibrik , xen-devel@lists.xenproject.org
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
 <20250528091708.390767-5-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: <20250528091708.390767-5-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 28.05.2025 11:16, Penny Zheng wrote:
> From: Stefano Stabellini 
> 
> We introduce a new Kconfig CONFIG_SYSCTL, which shall only be disabled
> on some dom0less systems or PV shim on x86, to reduce Xen footprint.
> 
> Making SYSCTL without prompt is transient and it will be fixed in the final

Nit: s/fixed/adjusted/ ? It's not a bug, after all.

> patch. Also, we will also state unsetting SYSCTL in pvshim_defconfig to
> explicitly make it unavailable for PV shim in the final patch.

Even without the double "also" this reads odd. But it's also unclear what
it has to do here, nor whether what is being said is actually correct.

> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -579,4 +579,15 @@ config BUDDY_ALLOCATOR_SIZE
>  	  Amount of memory reserved for the buddy allocator to serve Xen heap,
>  	  working alongside the colored one.
>  
> +menu "Supported hypercall interfaces"
> +	visible if EXPERT
> +
> +config SYSCTL
> +	bool "Enable sysctl hypercall"
> +	def_bool y

Why def_bool when you already have bool on the earlier line?

> +	help
> +	  This option shall only be disabled on some dom0less systems,
> +	  to reduce Xen footprint.

This isn't overly useful (but possibly misleading) as long as the prompt
isn#t going to be visible, yet.

> +endmenu

Blank line please ahead of this one.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 13:05:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 13:05:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010782.1388979 (Exim 4.92)
	(envelope-from )
	id 1uOyfe-0004ir-0u; Tue, 10 Jun 2025 13:05:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010782.1388979; Tue, 10 Jun 2025 13:05:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uOyfd-0004ik-Th; Tue, 10 Jun 2025 13:05:41 +0000
Received: by outflank-mailman (input) for mailman id 1010782;
 Tue, 10 Jun 2025 13: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 1uOyfd-0004iH-3B
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 13:05:41 +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 9b9dad31-45fb-11f0-a306-13f23c93f187;
 Tue, 10 Jun 2025 15:05:40 +0200 (CEST)
Received: by mail-ed1-x52d.google.com with SMTP id
 4fb4d7f45d1cf-607ec30df2bso4394220a12.1
 for ; Tue, 10 Jun 2025 06:05:39 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ade32c42770sm626465466b.41.2025.06.10.06.05.36
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 10 Jun 2025 06:05:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9b9dad31-45fb-11f0-a306-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749560739; x=1750165539; 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=emcWPlpqUTn7SorKViuI8m/xRSenM0PZhKHrrEHn8Bc=;
        b=XtHot2oIKeMXeP5yXH/sNS31ir15t57PQWCVnzvfQWjtmx3XXRuZBYuH/2yvT7bODd
         PjcON5SX4qqPerBVbj11wXctSrfzeJH6SsEcwkp8h8JWuMfzg7IY/mN12TpO0Upb4oBm
         fu+R3hO6wDKzeryuCuvpCj6M777JvxKcas9U3v1XvJhY8mBmRitKguKhqEfTLeZjNwYo
         3b9dIHI0RUQco4I9QvkQiwY1D/jWLfan4pwXgVoihowSEU1c2WjvHbb8BkN+5KRybaOQ
         Wupv2wtHmqEtUV+8ujR6NVRb5ZqHSTMKsuvhdmm8MGqS2bUeaki4RmO+HgxKTiu2iQRt
         PS4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749560739; x=1750165539;
        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=emcWPlpqUTn7SorKViuI8m/xRSenM0PZhKHrrEHn8Bc=;
        b=Z90ZSrVgOewaWcDqNIwIEfnaJVi6PaktGATDykJzwLV/5ILdFtGDc+iES77ymacbRD
         gNwsv931amwwnaVKqgSFitZEJDGWVYQjx0YZ0GN12I27CoJDWsakEmfsyNlHLNckdHyH
         xTcdyAXibfj7Ui7eNLZiKnxEirafaRnIEdWb0I4KXj+69DdCyMmfEEu2rXPq8IEEg4kp
         aUuDiUMZCVbG7kFCe5GcKWDOJsyeWsb1u0FqtwWBJ1k2Lr0cC1NIWXvPZLKPcp0wm0I0
         OP8PcbwFpi1TgukxbiUeG3WZg2LIVHt2eL++YK3sjMhwgf+b85iSiFdyL1gwirW6o6hz
         B1sA==
X-Gm-Message-State: AOJu0YwLHxyjknMbfR56DQ0LXGlNAoUYSe1aFpXq8CHWvr6u7TnRvYfT
	JzaxIRcZqOIjVeg78MBLhemdrBUvoPDXsHfh5NnHiyLaV6aAsYhjMmT30Ta3UA==
X-Gm-Gg: ASbGncv3zwzC/hdSU2/rk/SWHd2l6m2gE/0YxL9L0B36qCbcXmQ29QRFm6+gAXWB68g
	f6XVm0DvizKwqyuDE5R0EXtbZo/4oln0xzBE4dBslvGOSXVwIefOHMJmMQZDDWx3j06dxdKbY6o
	EcXdRMe32r9xwEHwHKaFP4SXrjTd5kPQDIZUBwK2pH9/ZmDcjEGZdXOWCUSuLTqO+gAslIiWY+t
	2IUuY+DpkMMRT0UhzuoWlB89xGWTBLHWDi/17vc64SeRspNmhxp/ILjLLKKIzaUkxMW18ZUq/QM
	x821Q0E4BFmcFS4XoKE7tnnWa4Ea8W+VmUR2ncgKU1+W7WUZ3D3KZbuVLtnkSZgepySCW/7eMa3
	3Negdr2DW5qZItqCL4OKEPZlfJKZ3xJhdhb8vJp4=
X-Google-Smtp-Source: AGHT+IHhwmZuryyfvylJjn3ZzNEohJbPYdrSUe952R/STsAXEExGw42aMovUCDb7ZiwV7/OUve6XEw==
X-Received: by 2002:a17:907:d06:b0:add:f2c8:7d3f with SMTP id a640c23a62f3a-ade7acf304emr223119866b.33.1749560738815;
        Tue, 10 Jun 2025 06:05:38 -0700 (PDT)
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 00/17] xen/riscv: introduce p2m functionality
Date: Tue, 10 Jun 2025 15:05:15 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

In this patch series are introduced necessary functions to build and manage
RISC-V guest page tables and MMIO/RAM mappings.

CI tests:
  https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/1862284573

---
Changes in V2:
 - Merged to staging:
   - [PATCH v1 1/6] xen/riscv: add inclusion of xen/bitops.h to asm/cmpxchg.h
 - New patches:
   - xen/riscv: implement sbi_remote_hfence_gvma{_vmid}().
 - Split patch "xen/riscv: implement p2m mapping functionality" into smaller
   one patches:
   - xen/riscv: introduce page_set_xenheap_gfn()
   - xen/riscv: implement guest_physmap_add_entry() for mapping GFNs to MFNs
   - xen/riscv: implement p2m_set_entry() and __p2m_set_entry()
   - xen/riscv: Implement p2m_free_entry() and related helpers
   - xen/riscv: Implement superpage splitting for p2m mappings
   - xen/riscv: implement p2m_next_level()
   - xen/riscv: Implement p2m_entry_from_mfn() and support PBMT configuration
 - Move root p2m table allocation to separate patch:
   xen/riscv: add root page table allocation
 - Drop dependency of this patch series from the patch witn an introduction of
   SvPBMT as it was merged.
 - Patch "[PATCH v1 4/6] xen/riscv: define pt_t and pt_walk_t structures" was
   renamed to xen/riscv: introduce pte_{set,get}_mfn() as after dropping of
   bitfields for PTE structure, this patch introduce only pte_{set,get}_mfn().
 - Rename "xen/riscv: define pt_t and pt_walk_t structures" to
   "xen/riscv: introduce pte_{set,get}_mfn()" as pt_t and pt_walk_t were
   dropped.
 - Introduce guest domain's VMID allocation and manegement.
 - Add patches necessary to implement p2m lookup:
   - xen/riscv: implement mfn_valid() and page reference, ownership handling helpers
   - xen/riscv: add support of page lookup by GFN
 - Re-sort patch series.
 - Add link to CI tests.
 - All other changes are patch-specific. Please check them.
---

Oleksii Kurochko (17):
  xen/riscv: implement sbi_remote_hfence_gvma()
  xen/riscv: introduce sbi_remote_hfence_gvma_vmid()
  xen/riscv: introduce guest domain's VMID allocation and manegement
  xen/riscv: construct the P2M pages pool for guests
  xen/riscv: introduce things necessary for p2m initialization
  xen/riscv: add root page table allocation
  xen/riscv: introduce pte_{set,get}_mfn()
  xen/riscv: add new p2m types and helper macros for type classification
  xen/riscv: introduce page_set_xenheap_gfn()
  xen/riscv: implement guest_physmap_add_entry() for mapping GFNs to
    MFNs
  xen/riscv: implement p2m_set_entry() and __p2m_set_entry()
  xen/riscv: Implement p2m_free_entry() and related helpers
  xen/riscv: Implement p2m_entry_from_mfn() and support PBMT
    configuration
  xen/riscv: implement p2m_next_level()
  xen/riscv: Implement superpage splitting for p2m mappings
  xen/riscv: implement mfn_valid() and page reference, ownership
    handling helpers
  xen/riscv: add support of page lookup by GFN

 xen/arch/riscv/Makefile                     |    1 +
 xen/arch/riscv/include/asm/domain.h         |   16 +
 xen/arch/riscv/include/asm/mm.h             |   45 +-
 xen/arch/riscv/include/asm/p2m.h            |  125 +-
 xen/arch/riscv/include/asm/page.h           |   33 +
 xen/arch/riscv/include/asm/riscv_encoding.h |    4 +
 xen/arch/riscv/include/asm/sbi.h            |   38 +
 xen/arch/riscv/mm.c                         |   97 +-
 xen/arch/riscv/p2m.c                        | 1188 +++++++++++++++++++
 xen/arch/riscv/sbi.c                        |   18 +
 xen/arch/riscv/setup.c                      |    3 +
 11 files changed, 1550 insertions(+), 18 deletions(-)
 create mode 100644 xen/arch/riscv/p2m.c

-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 13:05:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 13:05:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010783.1388989 (Exim 4.92)
	(envelope-from )
	id 1uOyff-0004y4-8F; Tue, 10 Jun 2025 13:05:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010783.1388989; Tue, 10 Jun 2025 13: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 1uOyff-0004xp-3l; Tue, 10 Jun 2025 13:05:43 +0000
Received: by outflank-mailman (input) for mailman id 1010783;
 Tue, 10 Jun 2025 13:05: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 1uOyfe-0004iH-3H
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 13:05: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 9c9454f3-45fb-11f0-a306-13f23c93f187;
 Tue, 10 Jun 2025 15:05:41 +0200 (CEST)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-ad891bb0957so885512666b.3
 for ; Tue, 10 Jun 2025 06:05:41 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ade32c42770sm626465466b.41.2025.06.10.06.05.38
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 10 Jun 2025 06:05:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9c9454f3-45fb-11f0-a306-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749560741; x=1750165541; darn=lists.xenproject.org;
        h=content-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=MQZA1jhqfJhA3+R1Io64wtcp1umLfxpBKyDauABhC/w=;
        b=hqsK6wcf3uNnk+qcB8JhRNx37mrZrDxuAx8GEne1YIIhAC4WM9DovmlBiMiKHqkbSY
         CyRIjXHrnwzbIMhahCaFVQiBIXem1v7xwplLRQthOk7saho/8kKC5B6q8yo7koJxXhxl
         wbhmY/0GLJUpklk0eDlUD008py5TF9AI0YinoH/n81PKP/iFn5PRByjbPAcvQ4CK92Es
         KSGAkGzwd8NOAs0tQqzmzCkZOPYahgxaj7/XSJDySgBQCiysWlcrCr7dGWiWEIG12+E3
         9mSFD+h/zFZTm2eBlOyRQUiwprPAqD+E7RA8nUXQ7HqYnv/W4vUAP1i+yV3R+5fxS/oy
         Ph7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749560741; x=1750165541;
        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=MQZA1jhqfJhA3+R1Io64wtcp1umLfxpBKyDauABhC/w=;
        b=hHV0qSGhhD6T34IfYvLgxqxNrrZO901JriMNg7ZRULD33B60EtDJbRxeTqBkaVrudx
         IIiSID/bF7ENoM2xQifBqPoZ7VRFa+WtJ2qqfGLCu+68YY0WoVlNpkyrCflSolqhAkfd
         QOX+p37ZUXFjuo063ptVBEYH/ZzMBAGh5H6qxsLj7ab75yK/H/jqimDCW5PkHkfBWbIC
         yDSNS6A4BlxhLW7EbzZhlA1Iin1Pn18Y0tjSq6uPZJ21PzP0Cmi85C5BMR9T2aSsajkf
         WqOhMEhTxZ3xFkJpbYj0EI5+6iQkosGa3TYuIvFMph1MqV3YCS7Pdg+B5e/Q/SxOm7bI
         OPZA==
X-Gm-Message-State: AOJu0Yzz+mrz9ukwOtJozRu6BMQj3xBuMm2uUmv+4JutnItgrz/pDdTq
	ug7Ri9vMNoplovv90Trnh26my53fKT7JIF49JBqAVAdViL1Kby00+I1nMz8g/A==
X-Gm-Gg: ASbGncs/+XaH6nbxMqYRPqbxzQFys0owwA+SgtSqZKthbErOV/C4D8ybKs1JT8LEHdH
	tJ8sqEHLlW6fN/Uiv5IAFVdeTDbyRPzyZmoqQGp+lf0QnHAAiRBMyLdkd/604uLnFx0CsI18f29
	+SS4mTmNaRNTuIcu58Ar/jCO4rHGj9SKCFClXvAx57tQfGC/WFe6BO6+gsQChQkH9gJyptrbtsC
	i/vrRAeePIUUv05VylNu/EiKDC/LlJdK8mAtqxo2Fwz6cXxB/hXAeYZ4bcLHcDVBAaPNS6GjfIW
	cKhvcxpq4zMgercV97/Z9SWP44AGG+zUFS5Qsv2A+4DAebzjJ3+7BA4t31ZWZ0AL72//D4Y5MA/
	P5SKrGn0dup4OsPs+vGtu4z2lPw3D
X-Google-Smtp-Source: AGHT+IHhI45EB7m1z/pBXSWPkP26t50qUS1diC2USA5GzGIHtA5mdJJ3bH2fCeA/V2zkhHzk3RL+tg==
X-Received: by 2002:a17:907:d24:b0:ad8:9a3b:b274 with SMTP id a640c23a62f3a-ade7ad31b03mr241390966b.52.1749560740226;
        Tue, 10 Jun 2025 06:05:40 -0700 (PDT)
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 01/17] xen/riscv: implement sbi_remote_hfence_gvma()
Date: Tue, 10 Jun 2025 15:05:16 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Instruct the remote harts to execute one or more HFENCE.GVMA instructions,
covering the range of guest physical addresses between start_addr and
start_addr + size for all the guests.

The remote fence operation applies to the entire address space if either:
 - start_addr and size are both 0, or
 - size is equal to 2^XLEN-1.

Signed-off-by: Oleksii Kurochko 
---
Changes in V2:
 - New patch.
---
 xen/arch/riscv/include/asm/sbi.h | 21 +++++++++++++++++++++
 xen/arch/riscv/sbi.c             |  9 +++++++++
 2 files changed, 30 insertions(+)

diff --git a/xen/arch/riscv/include/asm/sbi.h b/xen/arch/riscv/include/asm/sbi.h
index 527d773277..8e346347af 100644
--- a/xen/arch/riscv/include/asm/sbi.h
+++ b/xen/arch/riscv/include/asm/sbi.h
@@ -89,6 +89,27 @@ bool sbi_has_rfence(void);
 int sbi_remote_sfence_vma(const cpumask_t *cpu_mask, vaddr_t start,
                           size_t size);
 
+/*
+ * Instructs the remote harts to execute one or more HFENCE.GVMA
+ * instructions, covering the range of guest physical addresses
+ * between start_addr and start_addr + size for all the guests.
+ * This function call is only valid for harts implementing
+ * hypervisor extension.
+ *
+ * Returns 0 if IPI was sent to all the targeted harts successfully
+ * or negative value if start_addr or size is not valid.
+ *
+ * The remote fence operation applies to the entire address space if either:
+ *  - start_addr and size are both 0, or
+ *  - size is equal to 2^XLEN-1.
+ *
+ * @cpu_mask a cpu mask containing all the target CPUs (in Xen space).
+ * @param start virtual address start
+ * @param size virtual address range size
+ */
+int sbi_remote_hfence_gvma(const cpumask_t *cpu_mask, vaddr_t start,
+                           size_t size);
+
 /*
  * Initialize SBI library
  *
diff --git a/xen/arch/riscv/sbi.c b/xen/arch/riscv/sbi.c
index 4209520389..0613ad1cb0 100644
--- a/xen/arch/riscv/sbi.c
+++ b/xen/arch/riscv/sbi.c
@@ -258,6 +258,15 @@ int sbi_remote_sfence_vma(const cpumask_t *cpu_mask, vaddr_t start,
                       cpu_mask, start, size, 0, 0);
 }
 
+int sbi_remote_hfence_gvma(const cpumask_t *cpu_mask, vaddr_t start,
+                           size_t size)
+{
+    ASSERT(sbi_rfence);
+
+    return sbi_rfence(SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA,
+                      cpu_mask, start, size, 0, 0);
+}
+
 /* This function must always succeed. */
 #define sbi_get_spec_version()  \
     sbi_ext_base_func(SBI_EXT_BASE_GET_SPEC_VERSION)
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 13:05:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 13:05:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010784.1389000 (Exim 4.92)
	(envelope-from )
	id 1uOyfg-0005Ck-Ez; Tue, 10 Jun 2025 13:05:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010784.1389000; Tue, 10 Jun 2025 13:05: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 1uOyfg-0005Cd-Af; Tue, 10 Jun 2025 13:05:44 +0000
Received: by outflank-mailman (input) for mailman id 1010784;
 Tue, 10 Jun 2025 13:05: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 1uOyff-0004iH-2y
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 13:05:43 +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 9d2d16e2-45fb-11f0-a306-13f23c93f187;
 Tue, 10 Jun 2025 15:05:42 +0200 (CEST)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-adb2bb25105so866686166b.0
 for ; Tue, 10 Jun 2025 06:05:42 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ade32c42770sm626465466b.41.2025.06.10.06.05.40
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 10 Jun 2025 06:05:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9d2d16e2-45fb-11f0-a306-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749560742; x=1750165542; darn=lists.xenproject.org;
        h=content-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=CAFeKVvcyVUEFDWmR2Xc6msb8cPqppULN4b4iFqQNWg=;
        b=N/dhPzTebFgNqD2AE+nSlfRJE5UoXHfP4LZkN86b3qdQ/n7+/Door439K/Scd4OJs9
         jE0SdWpaQ8okUxCsUMynvzbt16AOzp4j+oRQMo2ge2IZdAxcSL0rR/uSACOIwraqAqHo
         ZY6xaViOYvEqum4qN24LWQuouGLWue7DRJPQDsdhXmIzsVjeIUBnUpYxOqwPpIV1we0Q
         ZRS46GiLYNon0S510qSlYgrz2AcTtJwDi8Z4KMo09dB5lt4h/GcYOtupxLGzmjahhsUT
         L+aS7bXgSPSvHddsJVnSiTSMhZJzEfk7iHBogAUtKLmQeCATOeovPKPeVQn3x0dzEwOd
         BDCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749560742; x=1750165542;
        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=CAFeKVvcyVUEFDWmR2Xc6msb8cPqppULN4b4iFqQNWg=;
        b=fvP5pqC4RCIE7li21xGZwmLEs2inmiCwiC7Hxtn7n9i+94rshUHMPxCN2X/d3FjAME
         06p+FFlHuhA0yh/RSu9osvpE9vTzQ4UvtLtRctxfyEHfvyvlcwc+BnEHDYm3M9HbX3I9
         ABlcKMqCwea61zx+TcV5K+ycknN53PR/KuwLDpu6qzgduTI1iNlzLVzJye3rvuDYdtUs
         /9t7CMcRT61/ClzjbH1kDJ0f+DocZpF9ft24J516fs8Udj7bbq37AelY3UCGiqoiiaUh
         ZULOBPq/Lq+LaBmyNNEBhoH1h0EFDYButTwDMyp7YDDu2nHUg0MCPY86by4lSsUix2M2
         qg/Q==
X-Gm-Message-State: AOJu0YzHepDHBXwahLFAi6eCW0J1VRhbKrYwI/WTybrMawWcn+VghsWY
	guT79cBteAYc9wLED8+wHdsvCgvwz4UnMkbGjRpzQ4GPOg94xkRN1sw5VH8MaA==
X-Gm-Gg: ASbGncv9NU7OIMMW/wGbSkOvX5TUorMindN1dkntUkMMCN/ZNviyN4TaRYu+3VW5lNj
	CQvcldiT2gvMxAk/OGua9Rd/42ktKeGxFQYIp0mHUywU3o/en0lMLs6BcRdxeeWtiqSZ8FZIIre
	gDTTnquPzgm+eONQhJlpb/+a0bQ4VQo+CJwZ59+cfZwb7CBpG20K/6Mx7XWqkSs3pmqifHNp3B/
	GNzgQCw/N/5tP/QO65ZDzaZ9ChMndXR1tMgFob+CvEpdHq56vspFzyyhoKxM275CyEnuxXcRsci
	CCzSyL4xlxP04URnLLMabnmR5BUml7PUVaY6xHu3fvakQAKKU+jsYbvAN9ldPmxiOdj0l5Dg7o+
	YS4PtA+ODMTTBFweWu01ZEUZZ0tlD
X-Google-Smtp-Source: AGHT+IHUecsZq3dhiCGc3K0O1u9og5INZT4pEdguTRCMHQSuZgHcV8qFojdIwwPPw3t0uFrzvAeBnA==
X-Received: by 2002:a17:907:5c1:b0:ad8:8efe:31fb with SMTP id a640c23a62f3a-ade1abc5eb0mr1502731266b.54.1749560741282;
        Tue, 10 Jun 2025 06:05:41 -0700 (PDT)
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 02/17] xen/riscv: introduce sbi_remote_hfence_gvma_vmid()
Date: Tue, 10 Jun 2025 15:05:17 +0200
Message-ID: <5c614593a1710c737f5509ebb165efd8f857df30.1749555949.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

It instructs the remote harts to execute one or more HFENCE.GVMA instructions
by making an SBI call, covering the range of guest physical addresses between
start_addr and start_addr + size only for the given VMID.

This function call is only valid for harts implementing hypervisor extension.

The remote fence operation applies to the entire address space if either:
  - start_addr and size are both 0, or
  - size is equal to 2^XLEN-1.

Signed-off-by: Oleksii Kurochko 
---
Changes in V2:
 - New patch.
---
 xen/arch/riscv/include/asm/sbi.h | 17 +++++++++++++++++
 xen/arch/riscv/sbi.c             |  9 +++++++++
 2 files changed, 26 insertions(+)

diff --git a/xen/arch/riscv/include/asm/sbi.h b/xen/arch/riscv/include/asm/sbi.h
index 8e346347af..2644833eb4 100644
--- a/xen/arch/riscv/include/asm/sbi.h
+++ b/xen/arch/riscv/include/asm/sbi.h
@@ -110,6 +110,23 @@ int sbi_remote_sfence_vma(const cpumask_t *cpu_mask, vaddr_t start,
 int sbi_remote_hfence_gvma(const cpumask_t *cpu_mask, vaddr_t start,
                            size_t size);
 
+/*
+ * Instruct the remote harts to execute one or more HFENCE.GVMA instructions,
+ * covering the range of guest physical addresses between start_addr and
+ * start_addr + size only for the given VMID. This function call is only
+ * valid for harts implementing hypervisor extension.
+ * The remote fence operation applies to the entire address space if either:
+ *  - start_addr and size are both 0, or
+ *  - size is equal to 2^XLEN-1.
+ *
+ * @cpu_mask a cpu mask containing all the target CPUs (in Xen space).
+ * @param start virtual address start
+ * @param size virtual address range size
+ * @param vmid virtual machine id
+ */
+int sbi_remote_hfence_gvma_vmid(const cpumask_t *cpu_mask, vaddr_t start,
+                                size_t size, unsigned long vmid);
+
 /*
  * Initialize SBI library
  *
diff --git a/xen/arch/riscv/sbi.c b/xen/arch/riscv/sbi.c
index 0613ad1cb0..bfd1193509 100644
--- a/xen/arch/riscv/sbi.c
+++ b/xen/arch/riscv/sbi.c
@@ -267,6 +267,15 @@ int sbi_remote_hfence_gvma(const cpumask_t *cpu_mask, vaddr_t start,
                       cpu_mask, start, size, 0, 0);
 }
 
+int sbi_remote_hfence_gvma_vmid(const cpumask_t *cpu_mask, vaddr_t start,
+                           size_t size, unsigned long vmid)
+{
+    ASSERT(sbi_rfence);
+
+    return sbi_rfence(SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA,
+                      cpu_mask, start, size, vmid, 0);
+}
+
 /* This function must always succeed. */
 #define sbi_get_spec_version()  \
     sbi_ext_base_func(SBI_EXT_BASE_GET_SPEC_VERSION)
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 13:05:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 13:05:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010785.1389010 (Exim 4.92)
	(envelope-from )
	id 1uOyfi-0005UG-Qr; Tue, 10 Jun 2025 13:05:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010785.1389010; Tue, 10 Jun 2025 13:05: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 1uOyfi-0005U1-LB; Tue, 10 Jun 2025 13:05:46 +0000
Received: by outflank-mailman (input) for mailman id 1010785;
 Tue, 10 Jun 2025 13:05: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 1uOyfg-0004iH-Mr
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 13:05:44 +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 9e20c52a-45fb-11f0-a306-13f23c93f187;
 Tue, 10 Jun 2025 15:05:44 +0200 (CEST)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-ade30256175so732529066b.1
 for ; Tue, 10 Jun 2025 06:05:44 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ade32c42770sm626465466b.41.2025.06.10.06.05.41
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 10 Jun 2025 06:05:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9e20c52a-45fb-11f0-a306-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749560743; x=1750165543; darn=lists.xenproject.org;
        h=content-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=dYwCKpM2AdDgMkM5pUxy/3g1cY3Ox3ZYugCCj6NxUk4=;
        b=ELZTfzinQqlZl4eH2hI2YrpentarNS8Of+PA9YGgUP+bQwuom/E6ceIxthdcD2o6tg
         GN37gQ2sxPN8nUtAIylf4SHGB94dhGd9qpgqmHrgB6ZGL3A9HU+EU7aKin/nbR2LfsEu
         y1irOlz4pRAQfX4q34s5Jd1iyhqjJiw9B+RNZilfZGL6dfwqwWF1x0A3YFwW5VfbSuNk
         5RjTnOBWcP2lVCKOYzjgVH5IeMqXVRiVVZb2ujlPF+ONodSfvZdWqQqVTnlC5ENygRvH
         omZtrLyinsyclr3N/Q3ms3U54QxyKxzB1tenaQjzFlY11G0gkDQjgfLiEnK/nvuLDxhe
         KdNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749560743; x=1750165543;
        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=dYwCKpM2AdDgMkM5pUxy/3g1cY3Ox3ZYugCCj6NxUk4=;
        b=ShfG/svXT5Ft4JvpWSLbUHb4Pvl+qFowRrEdYVZRHxf8HWBFPsdvIErPV9QJ8dic3G
         F546+jVRO1EgR4762gdZIlx6Z4NT0+YcKVLbjyTQqFtiUPVkNnHOarA8Lv1mWftMxlhD
         Yt6QFF9dLRl3icAMncnsVWU47oSXFrJNV6YWXUfgyElNtN2NOTH0hMDkaCLa0woLFewU
         oiMFftwtSN1k7jQ5ThxqqRBPJJX1enhTzqRfPsmIcqFHo7FbBJwTgmD58h2WbKhF6pgg
         6y08YWPOyHojdz37iuBdSZ9fEprZ2plYKBjiEZEh6GIPWHKEc5iR7XmrH0+FNfJZazDz
         BW1A==
X-Gm-Message-State: AOJu0YyEZkb5GJGB4v0HAbCZGj5eStci2YEiF7ihJOCrxdHURQtQV9Xy
	wSe+o+bj/fuHrMDwNLsN8YpJ7QqUwPMCRC2hPU57OFKSdJUqn1Ng5p+geXNIkA==
X-Gm-Gg: ASbGncvODGBvKWk8+bs9wthQS/87ZvdN11YBBqF6qz4NDivdrtZjl0uUG+KJlbyNUmi
	pfUrnrcPsjNI/EnlFGJGHq/eCdbNlzvF2EtM2uZ3t5xc7YEF01GG/iV7/8KBt6feuRxBjW0XhQi
	FnxRYi2Wv7ZJDKxZb9bpX2Gb7AtjSzEdaqYqeM7TtXKNenM8+wa9w2rHNAV3b3xnVgbYDVf76u3
	pOPRAPsG6AfUvc4SiiNql1Ebjtu4LoAJzvSb3OZl6HQrNWpK/LxP+ahS5jYhviNMxXfC4b4DGPf
	WJH5jsYlPYalbYOihxtU62Tt3j2GKCwllpvKKkBySJHHk2zsZCbFlCpCOyExcXRx3B8LVX4l/Wk
	FqLQb16jWrcMrUKFhPL7hN9G4qHRW
X-Google-Smtp-Source: AGHT+IEjMi5KqzHuFyzfiyMJz8eCJb0GUi4tJPNejv6sm92QokiGnhk6HzV5tiFCfi0GjnHS+iO74A==
X-Received: by 2002:a17:907:7289:b0:adb:229a:f8bd with SMTP id a640c23a62f3a-ade1a978096mr1571669266b.29.1749560742692;
        Tue, 10 Jun 2025 06:05:42 -0700 (PDT)
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 03/17] xen/riscv: introduce guest domain's VMID allocation and manegement
Date: Tue, 10 Jun 2025 15:05:18 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Implementation is based on Arm code with some minor changes:
 - Re-define INVALID_VMID.
 - Re-define MAX_VMID.
 - Add TLB flushing when VMID is re-used.

Also, as a part of this path structure p2m_domain is introduced with
vmid member inside it. It is necessary for VMID management functions.

Add a bitmap-based allocator to manage VMID space, supporting up to 127
VMIDs on RV32 and 16,383 on RV64 platforms, in accordance with the
architecture's hgatp VMID field (RV32 - 7 bit long, others - 14 bit long).

Reserve the highest VMID as INVALID_VMID to ensure it's not reused.

Implement p2m_alloc_vmid() and p2m_free_vmid() for dynamic allocation
and release of VMIDs per domain.

Integrate VMID initialization into p2m_init() and ensured domain-specific
TLB flushes on VMID release using sbi_remote_hfence_gvma_vmid().

Signed-off-by: Oleksii Kurochko 
---
Changes in V2:
 - New patch.
---
 xen/arch/riscv/Makefile             |   1 +
 xen/arch/riscv/include/asm/domain.h |   4 +
 xen/arch/riscv/include/asm/p2m.h    |  14 ++++
 xen/arch/riscv/p2m.c                | 115 ++++++++++++++++++++++++++++
 xen/arch/riscv/setup.c              |   3 +
 5 files changed, 137 insertions(+)
 create mode 100644 xen/arch/riscv/p2m.c

diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index a1c145c506..1034f2c9cd 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -6,6 +6,7 @@ obj-y += intc.o
 obj-y += irq.o
 obj-y += mm.o
 obj-y += pt.o
+obj-y += p2m.o
 obj-$(CONFIG_RISCV_64) += riscv64/
 obj-y += sbi.o
 obj-y += setup.o
diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h
index c3d965a559..b9a03e91c5 100644
--- a/xen/arch/riscv/include/asm/domain.h
+++ b/xen/arch/riscv/include/asm/domain.h
@@ -5,6 +5,8 @@
 #include 
 #include 
 
+#include 
+
 struct hvm_domain
 {
     uint64_t              params[HVM_NR_PARAMS];
@@ -18,6 +20,8 @@ struct arch_vcpu {
 
 struct arch_domain {
     struct hvm_domain hvm;
+
+    struct p2m_domain p2m;
 };
 
 #include 
diff --git a/xen/arch/riscv/include/asm/p2m.h b/xen/arch/riscv/include/asm/p2m.h
index 28f57a74f2..359408e1be 100644
--- a/xen/arch/riscv/include/asm/p2m.h
+++ b/xen/arch/riscv/include/asm/p2m.h
@@ -3,11 +3,21 @@
 #define ASM__RISCV__P2M_H
 
 #include 
+#include 
 
 #include 
 
 #define paddr_bits PADDR_BITS
 
+/* Get host p2m table */
+#define p2m_get_hostp2m(d) (&(d)->arch.p2m)
+
+/* Per-p2m-table state */
+struct p2m_domain {
+    /* Current VMID in use */
+    uint16_t vmid;
+};
+
 /*
  * List of possible type for each page in the p2m entry.
  * The number of available bit per page in the pte for this purpose is 2 bits.
@@ -93,6 +103,10 @@ static inline void p2m_altp2m_check(struct vcpu *v, uint16_t idx)
     /* Not supported on RISCV. */
 }
 
+void p2m_vmid_allocator_init(void);
+
+int p2m_init(struct domain *d);
+
 #endif /* ASM__RISCV__P2M_H */
 
 /*
diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
new file mode 100644
index 0000000000..9f7fd8290a
--- /dev/null
+++ b/xen/arch/riscv/p2m.c
@@ -0,0 +1,115 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+static spinlock_t vmid_alloc_lock = SPIN_LOCK_UNLOCKED;
+
+/*
+ * hgatp's VMID field is 7 or 14 bits. RV64 may support 14-bit VMID.
+ * Using a bitmap here limits us to 127 (2^7 - 1) or 16383 (2^14 - 1)
+ * concurrent domains. The bitmap space will be allocated dynamically
+ * based on whether 7 or 14 bit VMIDs are supported.
+ */
+static unsigned long *vmid_mask;
+static unsigned long *vmid_flushing_needed;
+
+/*
+ * -2 here because:
+ *    - -1 is needed to get the maximal possible VMID
+ *    - -1 is reserved for beinng used as INVALID_VMID
+ */
+#ifdef CONFIG_RISCV_32
+#define MAX_VMID (BIT(7, U) - 2)
+#else
+#define MAX_VMID (BIT(14, U) - 2)
+#endif
+
+/* Reserve the max possible VMID to be INVALID. */
+#define INVALID_VMID (MAX_VMID + 1)
+
+void p2m_vmid_allocator_init(void)
+{
+    /*
+     * Allocate space for vmid_mask and vmid_flushing_needed
+     * based on INVALID_VMID as it is the max possible VMID which just
+     * was reserved to be INVALID_VMID.
+     */
+    vmid_mask = xvzalloc_array(unsigned long, BITS_TO_LONGS(INVALID_VMID));
+    vmid_flushing_needed =
+        xvzalloc_array(unsigned long, BITS_TO_LONGS(INVALID_VMID));
+
+    if ( !vmid_mask || !vmid_flushing_needed )
+        panic("Could not allocate VMID bitmap space or VMID flushing map\n");
+
+    set_bit(INVALID_VMID, vmid_mask);
+}
+
+int p2m_alloc_vmid(struct domain *d)
+{
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+    int rc, nr;
+
+    spin_lock(&vmid_alloc_lock);
+
+    nr = find_first_zero_bit(vmid_mask, MAX_VMID);
+
+    ASSERT(nr != INVALID_VMID);
+
+    if ( nr == MAX_VMID )
+    {
+        rc = -EBUSY;
+        printk(XENLOG_ERR "p2m.c: dom%d: VMID pool exhausted\n", d->domain_id);
+        goto out;
+    }
+
+    set_bit(nr, vmid_mask);
+
+    if ( test_bit(p2m->vmid, vmid_flushing_needed) )
+    {
+        clear_bit(p2m->vmid, vmid_flushing_needed);
+        sbi_remote_hfence_gvma_vmid(d->dirty_cpumask, 0, 0, p2m->vmid);
+    }
+
+    p2m->vmid = nr;
+
+    rc = 0;
+
+out:
+    spin_unlock(&vmid_alloc_lock);
+    return rc;
+}
+
+void p2m_free_vmid(struct domain *d)
+{
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+    spin_lock(&vmid_alloc_lock);
+
+    if ( p2m->vmid != INVALID_VMID )
+    {
+        clear_bit(p2m->vmid, vmid_mask);
+        set_bit(p2m->vmid, vmid_flushing_needed);
+    }
+
+    spin_unlock(&vmid_alloc_lock);
+}
+
+int p2m_init(struct domain *d)
+{
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    int rc;
+
+    p2m->vmid = INVALID_VMID;
+
+    rc = p2m_alloc_vmid(d);
+    if ( rc )
+        return rc;
+
+    return 0;
+}
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 8bcd19218d..aa8f5646ea 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -134,6 +135,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
 
     intc_preinit();
 
+    p2m_vmid_allocator_init();
+
     printk("All set up\n");
 
     machine_halt();
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 13:05:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 13:05:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010786.1389013 (Exim 4.92)
	(envelope-from )
	id 1uOyfj-0005XC-4y; Tue, 10 Jun 2025 13:05:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010786.1389013; Tue, 10 Jun 2025 13:05:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uOyfi-0005WI-TX; Tue, 10 Jun 2025 13:05:46 +0000
Received: by outflank-mailman (input) for mailman id 1010786;
 Tue, 10 Jun 2025 13:05: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 1uOyfh-0004iH-BP
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 13:05:45 +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 9e90be84-45fb-11f0-a306-13f23c93f187;
 Tue, 10 Jun 2025 15:05:44 +0200 (CEST)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-acb5ec407b1so978046866b.1
 for ; Tue, 10 Jun 2025 06:05:44 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ade32c42770sm626465466b.41.2025.06.10.06.05.42
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 10 Jun 2025 06:05:43 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9e90be84-45fb-11f0-a306-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749560744; x=1750165544; darn=lists.xenproject.org;
        h=content-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=O5cGIp6lzcilrw8ShbCVkPARsAjo5L5Ne3xaR6XcYW4=;
        b=OFSzIbgKWbtgOUiRHZyf64fFHOHxgcwdnXvLJDaxPuTXYnXkALBtg3zB2pXbuDoQx5
         rB5ImVzsiIDRnvOpWDKvTsz1pLHEvl+2/cyvsCouopsFceEj+721fiYC5bS68D7Ybq8a
         yIPRKUqDMu9LeQJPSSqWMVAzKKnRuTcQwSH/lVKqyEiXloJtK1OsBq35fKx8WZvyrhFs
         IcqOHV0GlsTSjUcgFNuoyE543dUMV33rdCyD32kV+qDILJovc+EyCyYyDuEDBvi4Tnmw
         fiNG+zApYCWoUj2sQVYz6FFA5Hg2OJ7vdsSNKaYl443WpcS/p80Px2iZdolnHS54K6Rs
         62HQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749560744; x=1750165544;
        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=O5cGIp6lzcilrw8ShbCVkPARsAjo5L5Ne3xaR6XcYW4=;
        b=DIp35M450VG8W/4wo7osPNSBsvmcUhoAWOw9Hpn07/LsTxKUycgk92I6IqRc3gOuGQ
         pHzthnAijKh1Y43e1Hj2/xUfGkZCpFR9rgGIc27F4NhLIYoJFuJQ0KZx3tGuiqPFdkiz
         VlT4+3D92/Mw5Hl7Fzd9cW131pbr7Bm5lxcPuHgVNT75qmFRSxPs1bbWQQUokK0t6Yn2
         dK11n7/qOUB2ErD/IUZZLD+KqmDEqwKq9W5kcxg1uxonwAzyl38XbGz9Gaq6EEGCA8Se
         3x5nEW4IURQQrO4hR45Q8hkhrwVyGxrRAXtQj4SIIbQho3L2DLA+R+Z/okc8yMUV3PGj
         hICg==
X-Gm-Message-State: AOJu0YymSJtSei0x/6HSXvUS63wv0fqHj+JtKYWa2UgMSeo6rqnNeLgG
	9RQWKX3WltPgRgfFbRiBwQRNSFdGlnlcfmgyzNkNc0fuB9W/rml8KbqXFLmlWw==
X-Gm-Gg: ASbGncvA6S5nKOGDGZEEOlodGT5qF45yqlcLCdPllb1Lfoqx1d989lvMNuAOMhqQG6N
	aYmQzPY2CpUXOVE3Nvt4vvD5NYTO3WLaSNr+dRFJMGox0qSIiYVnTx0St+4gmyKeqbxzgXqwlQp
	HYGYEu8Hsw8OgRcyiMIZ75LzxREWDEHEOywDY/Ko3dVdrB+B/Pc2Ef9q/7Usl2dnLT2nc0oakx3
	T+Cz0vxOn8Gn6N7uUGfgv2F3u96wq+p2fAO1miZ37Zu5+mW8ImARsq9Cp9m8QER2GbHG4UVUSoz
	l3R7oqvIRUF8MQ5FshipndgLRMyAp5sZTHU24mHTRkq9dPagMUIGKIHA69jnAF8cMP/nYawb4pC
	kSqWHM9WCBhth+Uog7JtSPfhR1j97
X-Google-Smtp-Source: AGHT+IG+GuksJhWm+r89SaPyXR4MgjeFB20puLjU92lWbLXtuoPxVX1Hd0Ryeej0kxstXLeuped14g==
X-Received: by 2002:a17:907:c22:b0:ad8:87a0:62aa with SMTP id a640c23a62f3a-ade1aab90f1mr1740126066b.27.1749560743862;
        Tue, 10 Jun 2025 06:05:43 -0700 (PDT)
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 04/17] xen/riscv: construct the P2M pages pool for guests
Date: Tue, 10 Jun 2025 15:05:19 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Implement p2m_set_allocation() to construct p2m pages pool for guests
based on required number of pages.

This is implemented by:
- Adding a `struct paging_domain` which contains a freelist, a
  counter variable and a spinlock to `struct arch_domain` to
  indicate the free p2m pages and the number of p2m total pages in
  the p2m pages pool.
- Adding a helper `p2m_set_allocation` to set the p2m pages pool
  size. This helper should be called before allocating memory for
  a guest and is called from domain_p2m_set_allocation(), the latter
  is a part of common dom0less code.

Signed-off-by: Oleksii Kurochko 
---
Changes in v2:
 - Drop the comment above inclusion of  in riscv/p2m.c.
 - Use ACCESS_ONCE() for lhs and rhs for the expressions in
   p2m_set_allocation().
---
 xen/arch/riscv/include/asm/domain.h | 12 ++++++
 xen/arch/riscv/p2m.c                | 59 +++++++++++++++++++++++++++++
 2 files changed, 71 insertions(+)

diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h
index b9a03e91c5..b818127f9f 100644
--- a/xen/arch/riscv/include/asm/domain.h
+++ b/xen/arch/riscv/include/asm/domain.h
@@ -2,6 +2,8 @@
 #ifndef ASM__RISCV__DOMAIN_H
 #define ASM__RISCV__DOMAIN_H
 
+#include 
+#include 
 #include 
 #include 
 
@@ -18,10 +20,20 @@ struct arch_vcpu_io {
 struct arch_vcpu {
 };
 
+struct paging_domain {
+    spinlock_t lock;
+    /* Free P2M pages from the pre-allocated P2M pool */
+    struct page_list_head p2m_freelist;
+    /* Number of pages from the pre-allocated P2M pool */
+    unsigned long p2m_total_pages;
+};
+
 struct arch_domain {
     struct hvm_domain hvm;
 
     struct p2m_domain p2m;
+
+    struct paging_domain paging;
 };
 
 #include 
diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
index 9f7fd8290a..f33c7147ff 100644
--- a/xen/arch/riscv/p2m.c
+++ b/xen/arch/riscv/p2m.c
@@ -1,4 +1,5 @@
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -105,6 +106,9 @@ int p2m_init(struct domain *d)
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
     int rc;
 
+    spin_lock_init(&d->arch.paging.lock);
+    INIT_PAGE_LIST_HEAD(&d->arch.paging.p2m_freelist);
+
     p2m->vmid = INVALID_VMID;
 
     rc = p2m_alloc_vmid(d);
@@ -113,3 +117,58 @@ int p2m_init(struct domain *d)
 
     return 0;
 }
+
+/*
+ * Set the pool of pages to the required number of pages.
+ * Returns 0 for success, non-zero for failure.
+ * Call with d->arch.paging.lock held.
+ */
+int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
+{
+    struct page_info *pg;
+
+    ASSERT(spin_is_locked(&d->arch.paging.lock));
+
+    for ( ; ; )
+    {
+        if ( d->arch.paging.p2m_total_pages < pages )
+        {
+            /* Need to allocate more memory from domheap */
+            pg = alloc_domheap_page(d, MEMF_no_owner);
+            if ( pg == NULL )
+            {
+                printk(XENLOG_ERR "Failed to allocate P2M pages.\n");
+                return -ENOMEM;
+            }
+            ACCESS_ONCE(d->arch.paging.p2m_total_pages)++;
+            page_list_add_tail(pg, &d->arch.paging.p2m_freelist);
+        }
+        else if ( d->arch.paging.p2m_total_pages > pages )
+        {
+            /* Need to return memory to domheap */
+            pg = page_list_remove_head(&d->arch.paging.p2m_freelist);
+            if( pg )
+            {
+                ACCESS_ONCE(d->arch.paging.p2m_total_pages)--;
+                free_domheap_page(pg);
+            }
+            else
+            {
+                printk(XENLOG_ERR
+                       "Failed to free P2M pages, P2M freelist is empty.\n");
+                return -ENOMEM;
+            }
+        }
+        else
+            break;
+
+        /* Check to see if we need to yield and try again */
+        if ( preempted && general_preempt_check() )
+        {
+            *preempted = true;
+            return -ERESTART;
+        }
+    }
+
+    return 0;
+}
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 13:05:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 13:05:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010788.1389039 (Exim 4.92)
	(envelope-from )
	id 1uOyfm-0006JZ-Us; Tue, 10 Jun 2025 13:05:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010788.1389039; Tue, 10 Jun 2025 13:05:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uOyfm-0006JF-Oh; Tue, 10 Jun 2025 13:05:50 +0000
Received: by outflank-mailman (input) for mailman id 1010788;
 Tue, 10 Jun 2025 13:05: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 1uOyfl-0004iH-17
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 13:05:49 +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 a09ba216-45fb-11f0-a306-13f23c93f187;
 Tue, 10 Jun 2025 15:05:48 +0200 (CEST)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-addfe17ec0bso1197577466b.1
 for ; Tue, 10 Jun 2025 06:05:48 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ade32c42770sm626465466b.41.2025.06.10.06.05.45
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 10 Jun 2025 06:05:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a09ba216-45fb-11f0-a306-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749560747; x=1750165547; darn=lists.xenproject.org;
        h=content-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=G9hLIUfPcNIKsmfZjWqaz9gsdigw2uPwEp+WXF0YeaY=;
        b=RHpBVplvWGQO4tqk0h9Q6ECwXkuaG2kfCFS5NDDbNpRRBsKUY5NZC3qDbqia7zbB2q
         9yGtIy65Fj/U2fnsNwOGZwZ5yy7Q0HWJAoPpVuUCveFXwDH8QAW5EBX9i6ZBS5FMuNFp
         z00mhkIx+5G0WeqHX0QEqhGn2ljDQku9sgvmlYMVzLz8yOK2T2NHYh4zWM1s3vzAUIbO
         Dru4p716LQw1si6v0H5c/1MdDmRW8UDnJitRgMTXzwWDZO0PlM2p35C3/3f8O89qufIf
         p9TEYTzX3l6LpVJnO1IGbQR1kezQaOfxJt01et/5fOPAPkLOADN2SD6x4YGwjbB7fQJn
         wA8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749560747; x=1750165547;
        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=G9hLIUfPcNIKsmfZjWqaz9gsdigw2uPwEp+WXF0YeaY=;
        b=SaVwJru/ffUn2JRnpuiEF3pa/FVGwZpd+3iYXILbQVlkQovEqTtJouR9NF9Lp/SjXK
         Mr0/xJKP+tVz4KrvrouXC9I5rmLZfazyvYvA6dDuWlk1Kutt/xigkKIVQGbCOgZzoPnZ
         K8n/9xr6UdR5fjBUM8EWNWIaqi0sZpejDk0Rh4NRY2rFVKVZupUgA+9UuAwmqeLVso8n
         zr/gD3gpu1UKDDEgZo0SaDRTQXh58Ag+VArj2fycwdr4MDZ13JWkRONa24KWMH+4zWi4
         aX3j2/EI5b3yv+yOscu48LyLd9ezFNrlOBtUbxWNnC102NAZIk+q3b4Tx4L/jVr7MOPC
         ZmgA==
X-Gm-Message-State: AOJu0YzCSVFMgK5ao9QfrMc2LJphAx/GEHvVkoNrTDYvMbggsymS2A+a
	wEsd95976WCguUsQ+jQC5c0MmipZCU9mNnQlSPWsQM315Bx4ns6/xjTHQDedlA==
X-Gm-Gg: ASbGncuXaDqAPatycN0yBo+EHRcIaaRuaffRiPtnpAdE4yHrPis366jCR3PRoiBza3q
	RJ/d3LFH2D3cITPpm4KzbiPFlM5snOixbH3j+fUNJTEVBhQRQBFxcXzEOqERecA+JZ/Pe3M/qqA
	1DfBGGAONEjgMBgRVTFO8IomA3hg9WYiN+pEL0dtgevrKT+VTLwsv0V02kMoqcYFZaRGBNixi9y
	ussyro2fq5Rm5M3h/oZYrRM9b8Wii0ZpZnX00Jv/KW4R4hEw8yzg9+59gCmz6tUOCog0v0JR11W
	/JiN+JUeZ40HjyB5KJlok2/RUk2YDDLD6/jCYcXsT2U2OKPDjPAX+vnS5mGlhsVSqLTOW01A6DM
	/ll7LrVJPgX9PkI45g+pLByU4ZtmT
X-Google-Smtp-Source: AGHT+IFihu1rI2wMBHoXh5YoFH0UgxCCFKSkuzc1RFwjRhSWVuUdAk/0XgNrOroqtrfUkLA8y16lQQ==
X-Received: by 2002:a17:907:7ea2:b0:ad8:6dc0:6a8a with SMTP id a640c23a62f3a-ade771274a6mr309558066b.1.1749560746070;
        Tue, 10 Jun 2025 06:05:46 -0700 (PDT)
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 06/17] xen/riscv: add root page table allocation
Date: Tue, 10 Jun 2025 15:05:21 +0200
Message-ID: <76675ddb7517e4cceb63472c94944046b255da01.1749555949.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Introduce support for allocating and initializing the root page table
required for RISC-V stage-2 address translation.

To implement root page table allocation the following is introduced:
- p2m_get_clean_page() and p2m_allocate_root() helpers to allocate and
  zero a 16 KiB root page table, as mandated by the RISC-V privileged
  specification for Sv39x4/Sv48x4 modes.
- Add hgatp_from_page() to construct the hgatp register value from the
  allocated root page.
- Update p2m_init() to allocate the root table and initialize
  p2m->root and p2m->hgatp.
- Add maddr_to_page() and page_to_maddr() macros for easier address
  manipulation.
- Allocate root p2m table after p2m pool is initialized.

Signed-off-by: Oleksii Kurochko 
---
Changes in v2:
 - This patch was created from "xen/riscv: introduce things necessary for p2m
   initialization" with the following changes:
   - [clear_and_clean_page()] Add missed call of clean_dcache_va_range().
   - Drop p2m_get_clean_page() as it is going to be used only once to allocate
     root page table. Open-code it explicittly in p2m_allocate_root(). Also,
     it will help avoid duplication of the code connected to order and nr_pages
     of p2m root page table.
   - Instead of using order 2 for alloc_domheap_pages(), use
     get_order_from_bytes(KB(16)).
   - Clear and clean a proper amount of allocated pages in p2m_allocate_root().
   - Drop _info from the function name hgatp_from_page_info() and its argument
     page_info.
   - Introduce HGATP_MODE_MASK and use MASK_INSR() instead of shift to calculate
     value of hgatp.
   - Drop unnecessary parentheses in definition of page_to_maddr().
   - Add support of VMID.
   - Drop TLB flushing in p2m_alloc_root_table() and do that once when VMID
     is re-used. [Look at p2m_alloc_vmid()]
   - Allocate p2m root table after p2m pool is fully initialized: first
     return pages to p2m pool them allocate p2m root table.
---
 xen/arch/riscv/include/asm/mm.h             |  4 +
 xen/arch/riscv/include/asm/p2m.h            |  6 ++
 xen/arch/riscv/include/asm/riscv_encoding.h |  4 +
 xen/arch/riscv/p2m.c                        | 94 +++++++++++++++++++++
 4 files changed, 108 insertions(+)

diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
index 01bbd92a06..912bc79e1b 100644
--- a/xen/arch/riscv/include/asm/mm.h
+++ b/xen/arch/riscv/include/asm/mm.h
@@ -149,6 +149,10 @@ extern struct page_info *frametable_virt_start;
 #define mfn_to_page(mfn)    (frametable_virt_start + mfn_x(mfn))
 #define page_to_mfn(pg)     _mfn((pg) - frametable_virt_start)
 
+/* Convert between machine addresses and page-info structures. */
+#define maddr_to_page(ma) mfn_to_page(maddr_to_mfn(ma))
+#define page_to_maddr(pg) mfn_to_maddr(page_to_mfn(pg))
+
 static inline void *page_to_virt(const struct page_info *pg)
 {
     return mfn_to_virt(mfn_x(page_to_mfn(pg)));
diff --git a/xen/arch/riscv/include/asm/p2m.h b/xen/arch/riscv/include/asm/p2m.h
index 9570eff014..a31b05bd50 100644
--- a/xen/arch/riscv/include/asm/p2m.h
+++ b/xen/arch/riscv/include/asm/p2m.h
@@ -26,6 +26,12 @@ struct p2m_domain {
     /* Pages used to construct the p2m */
     struct page_list_head pages;
 
+    /* The root of the p2m tree. May be concatenated */
+    struct page_info *root;
+
+    /* Address Translation Table for the p2m */
+    paddr_t hgatp;
+
     /* Indicate if it is required to clean the cache when writing an entry */
     bool clean_pte;
 
diff --git a/xen/arch/riscv/include/asm/riscv_encoding.h b/xen/arch/riscv/include/asm/riscv_encoding.h
index 6cc8f4eb45..a71b7546ef 100644
--- a/xen/arch/riscv/include/asm/riscv_encoding.h
+++ b/xen/arch/riscv/include/asm/riscv_encoding.h
@@ -133,11 +133,13 @@
 #define HGATP_MODE_SV48X4		_UL(9)
 
 #define HGATP32_MODE_SHIFT		31
+#define HGATP32_MODE_MASK		_UL(0x80000000)
 #define HGATP32_VMID_SHIFT		22
 #define HGATP32_VMID_MASK		_UL(0x1FC00000)
 #define HGATP32_PPN			_UL(0x003FFFFF)
 
 #define HGATP64_MODE_SHIFT		60
+#define HGATP64_MODE_MASK		_ULL(0xF000000000000000)
 #define HGATP64_VMID_SHIFT		44
 #define HGATP64_VMID_MASK		_ULL(0x03FFF00000000000)
 #define HGATP64_PPN			_ULL(0x00000FFFFFFFFFFF)
@@ -170,6 +172,7 @@
 #define HGATP_VMID_SHIFT		HGATP64_VMID_SHIFT
 #define HGATP_VMID_MASK			HGATP64_VMID_MASK
 #define HGATP_MODE_SHIFT		HGATP64_MODE_SHIFT
+#define HGATP_MODE_MASK			HGATP64_MODE_MASK
 #else
 #define MSTATUS_SD			MSTATUS32_SD
 #define SSTATUS_SD			SSTATUS32_SD
@@ -181,6 +184,7 @@
 #define HGATP_VMID_SHIFT		HGATP32_VMID_SHIFT
 #define HGATP_VMID_MASK			HGATP32_VMID_MASK
 #define HGATP_MODE_SHIFT		HGATP32_MODE_SHIFT
+#define HGATP_MODE_MASK			HGATP32_MODE_MASK
 #endif
 
 #define TOPI_IID_SHIFT			16
diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
index e409997499..2419a61d8c 100644
--- a/xen/arch/riscv/p2m.c
+++ b/xen/arch/riscv/p2m.c
@@ -41,6 +41,91 @@ void p2m_write_unlock(struct p2m_domain *p2m)
     write_unlock(&p2m->lock);
 }
 
+static void clear_and_clean_page(struct page_info *page)
+{
+    clean_dcache_va_range(page, PAGE_SIZE);
+    clear_domain_page(page_to_mfn(page));
+}
+
+static struct page_info *p2m_allocate_root(struct domain *d)
+{
+    struct page_info *page;
+    unsigned int order = get_order_from_bytes(KB(16));
+    unsigned int nr_pages = _AC(1,U) << order;
+
+    /* Return back nr_pages necessary for p2m root table. */
+
+    if ( ACCESS_ONCE(d->arch.paging.p2m_total_pages) < nr_pages )
+        panic("Specify more xen,domain-p2m-mem-mb\n");
+
+    for ( unsigned int i = 0; i < nr_pages; i++ )
+    {
+        /* Return memory to domheap. */
+        page = page_list_remove_head(&d->arch.paging.p2m_freelist);
+        if( page )
+        {
+            ACCESS_ONCE(d->arch.paging.p2m_total_pages)--;
+            free_domheap_page(page);
+        }
+        else
+        {
+            printk(XENLOG_ERR
+                   "Failed to free P2M pages, P2M freelist is empty.\n");
+            return NULL;
+        }
+    }
+
+    /* Allocate memory for p2m root table. */
+
+    /*
+     * As mentioned in the Priviliged Architecture Spec (version 20240411)
+     * As explained in Section 18.5.1, for the paged virtual-memory schemes
+     * (Sv32x4, Sv39x4, Sv48x4, and Sv57x4), the root page table is 16 KiB
+     * and must be aligned to a 16-KiB boundary.
+     */
+    page = alloc_domheap_pages(d, order, MEMF_no_owner);
+    if ( page == NULL )
+        return NULL;
+
+    for ( unsigned int i = 0; i < nr_pages; i++ )
+        clear_and_clean_page(page + i);
+
+    return page;
+}
+
+static unsigned long hgatp_from_page(struct p2m_domain *p2m)
+{
+    struct page_info *p2m_root_page = p2m->root;
+    unsigned long ppn;
+    unsigned long hgatp_mode;
+
+    ppn = PFN_DOWN(page_to_maddr(p2m_root_page)) & HGATP_PPN;
+
+#if RV_STAGE1_MODE == SATP_MODE_SV39
+    hgatp_mode = HGATP_MODE_SV39X4;
+#elif RV_STAGE1_MODE == SATP_MODE_SV48
+    hgatp_mode = HGATP_MODE_SV48X4;
+#else
+#   error "add HGATP_MODE"
+#endif
+
+    return ppn | MASK_INSR(p2m->vmid, HGATP_VMID_MASK) |
+           MASK_INSR(hgatp_mode, HGATP_MODE_MASK);
+}
+
+static int p2m_alloc_root_table(struct domain *d)
+{
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+    p2m->root = p2m_allocate_root(d);
+    if ( !p2m->root )
+        return -ENOMEM;
+
+    p2m->hgatp = hgatp_from_page(p2m);
+
+    return 0;
+}
+
 static spinlock_t vmid_alloc_lock = SPIN_LOCK_UNLOCKED;
 
 /*
@@ -228,5 +313,14 @@ int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
         }
     }
 
+    /*
+    * First, wait for the p2m pool to be initialized. Then allocate the root
+    * table so that the necessary pages can be returned from the p2m pool,
+    * since the root table must be allocated using alloc_domheap_pages(...)
+    * to meet its specific requirements.
+    */
+    if ( !d->arch.p2m.root )
+        p2m_alloc_root_table(d);
+
     return 0;
 }
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 13:05:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 13:05:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010787.1389029 (Exim 4.92)
	(envelope-from )
	id 1uOyfl-00061x-Ca; Tue, 10 Jun 2025 13:05:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010787.1389029; Tue, 10 Jun 2025 13:05: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 1uOyfl-00061h-8N; Tue, 10 Jun 2025 13:05:49 +0000
Received: by outflank-mailman (input) for mailman id 1010787;
 Tue, 10 Jun 2025 13:05: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 1uOyfk-0004Sm-9I
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 13:05:48 +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 9f62feb6-45fb-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 15:05:46 +0200 (CEST)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-ad572ba1347so792286266b.1
 for ; Tue, 10 Jun 2025 06:05:46 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ade32c42770sm626465466b.41.2025.06.10.06.05.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 10 Jun 2025 06:05:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9f62feb6-45fb-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749560746; x=1750165546; darn=lists.xenproject.org;
        h=content-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=EXarRpVA36z28lQ7RkHAs0DFKKfiVvul0XZ2J2qt7Hc=;
        b=fVYEyRUTdngjtzd2Povt507A8TYl0D8f8YxlkeceNZ2XiFNkCyKSJpdqVrE30ayccy
         m0QxdQGH8WR17XAzKeeh0FpqmSjaWsCF8KLt1t47xrCORgKR2tPwz08XjDXtos05NGKC
         +AGyvvhjqgqQpiVHXUS8/5mYpYQKXpqWRhgf/LfgoeA68APnYwrG8Z9XshcJLEj0YN8r
         npHOf0k93NbHD+oSIuPYuLJXFBtZ4Iix/fMMQvxD6ydF5suqJwQNsPQKrCh7CAVIf492
         nLjLmg+HLzadMKomUTGV1Xd15HcJGVhkS0j1SGfPpC3Wdx9T1CJ7Vd2PuHDfLbrvm4Mo
         qRDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749560746; x=1750165546;
        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=EXarRpVA36z28lQ7RkHAs0DFKKfiVvul0XZ2J2qt7Hc=;
        b=AbGEe0Z7OR8CiDg6Rdc3Q4KBZ/vVlG8MkgLB9+LaptC2+EE00kznR+4l3ps8vxtleZ
         Ia8Wh/4m8kE9+7g/nJwP4pRtlMyfI/835FUrrosp5pFnSXdbZjq0zLH+sc5z81aa1WKW
         rGA4MAcceNKvmgx9b2U0yC6nLddMc7nbpOU0rhhocy4QBH5YcQw0k8VZqKwg17xEojf6
         cW5sHnuASaIC00+2P3Rcg21hEm1CQ/+TDl0izAge9MvwyUf0fRoCe6cOw7OGO9AUZBiA
         afKWjXQjWO8yv2XfGcW7ySxlZiihcyCrMvbu7wjzqdk4U2V265DFpfQ/ECb7ZVc8/BXH
         TCMg==
X-Gm-Message-State: AOJu0YwchGeNSS1uYFHJoSPItlTHctNStFyDX1+ttqDs/U7orKVaovoT
	32ZCj9Ka9YoV1UpzSehnl5IVGZO+c672Yi2XecYmwB5pwblH9niud3R/JfzlGg==
X-Gm-Gg: ASbGncug+w1Au9KKMryODUuRIJ6tFQ4Y3Up+owr2Vbx+2mzecl8RvVuB7UfbZciVn3m
	LuhfEfn3MjwnBEDL/P792rO5l1Y97KTUWgu3UkEZi/TrNvGpan1SAl8pYVv9cr0z0r7Ps+MQsk6
	cKTrwImCvloVNIGhAWB+WEnAvQ8edT9kqkJnXA9Tsxkih6KLH9LBn2tUu8gI9esdX/TUKYtLiy8
	o63bsxvckQL1N6bNvsYNTGio34S0V+lS3I0GXvNpWegEeAMtiE3nBNvtt28nZXgY264rRsSzYxe
	GqdaaX+hCH/obvIuUuoZHnLd8GSJ2mDaQu3OKL8JYVOXp35JszHzNJrigwI7gFetMG5/OvqBRtF
	3/QXUPQUzAIBfrU6b9Bu6nc5bL8Hy
X-Google-Smtp-Source: AGHT+IHwyPiGJS37+PX0GdCY66Zwx/DKdObjhSV3s5pHoY4KpTJ/uOq0y2ZsmygVOv78BL+hNDPXxA==
X-Received: by 2002:a17:907:7fa9:b0:ad8:9257:5733 with SMTP id a640c23a62f3a-ade1a905a8cmr1303884166b.20.1749560744967;
        Tue, 10 Jun 2025 06:05:44 -0700 (PDT)
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 05/17] xen/riscv: introduce things necessary for p2m initialization
Date: Tue, 10 Jun 2025 15:05:20 +0200
Message-ID: <443cb3566a60dcb5d5440c72410ff6d76a010a58.1749555949.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Introduce the following things:
- Update p2m_domain structure, which describe per p2m-table state, with:
  - lock to protect updates to p2m.
  - pool with pages used to construct p2m.
  - clean_pte which indicate if it is requires to clean the cache when
    writing an entry.
  - radix tree to store p2m type as PTE doesn't have enough free bits to
    store type.
  - default_access to store p2m access type for each page in the domain.
  - back pointer to domain structure.
- p2m_init() to initalize members introduced in p2m_domain structure.
- Introudce p2m_write_lock() and p2m_is_write_locked().
- Introduce p2m_force_tlb_flush_sync() to flush TLBs after p2m table
  update.

Signed-off-by: Oleksii Kurochko 
---
Changes in V2:
 - Use introduced erlier sbi_remote_hfence_gvma_vmid() for proper implementation
   of p2m_force_tlb_flush_sync() as TLB flushing needs to happen for each pCPU
   which potentially has cached a mapping, what is tracked by d->dirty_cpumask.
 - Drop unnecessary blanks.
 - Fix code style for # of pre-processor directive.
 - Drop max_mapped_gfn and lowest_mapped_gfn as they aren't used now.
 - [p2m_init()] Set p2m->clean_pte=false if CONFIG_HAS_PASSTHROUGH=n.
 - [p2m_init()] Update the comment above p2m->domain = d;
 - Drop p2m->need_flush as it seems to be always true for RISC-V and as a
   consequence drop p2m_tlb_flush_sync().
 - Move to separate patch an introduction of root page table allocation.
---
 xen/arch/riscv/include/asm/p2m.h | 39 +++++++++++++++++++++
 xen/arch/riscv/p2m.c             | 58 ++++++++++++++++++++++++++++++++
 2 files changed, 97 insertions(+)

diff --git a/xen/arch/riscv/include/asm/p2m.h b/xen/arch/riscv/include/asm/p2m.h
index 359408e1be..9570eff014 100644
--- a/xen/arch/riscv/include/asm/p2m.h
+++ b/xen/arch/riscv/include/asm/p2m.h
@@ -3,6 +3,10 @@
 #define ASM__RISCV__P2M_H
 
 #include 
+#include 
+#include 
+#include 
+#include 
 #include 
 
 #include 
@@ -14,6 +18,29 @@
 
 /* Per-p2m-table state */
 struct p2m_domain {
+    /*
+     * Lock that protects updates to the p2m.
+     */
+    rwlock_t lock;
+
+    /* Pages used to construct the p2m */
+    struct page_list_head pages;
+
+    /* Indicate if it is required to clean the cache when writing an entry */
+    bool clean_pte;
+
+    struct radix_tree_root p2m_type;
+
+    /*
+     * Default P2M access type for each page in the the domain: new pages,
+     * swapped in pages, cleared pages, and pages that are ambiguously
+     * retyped get this access type.  See definition of p2m_access_t.
+     */
+    p2m_access_t default_access;
+
+    /* Back pointer to domain */
+    struct domain *domain;
+
     /* Current VMID in use */
     uint16_t vmid;
 };
@@ -107,6 +134,18 @@ void p2m_vmid_allocator_init(void);
 
 int p2m_init(struct domain *d);
 
+static inline void p2m_write_lock(struct p2m_domain *p2m)
+{
+    write_lock(&p2m->lock);
+}
+
+void p2m_write_unlock(struct p2m_domain *p2m);
+
+static inline int p2m_is_write_locked(struct p2m_domain *p2m)
+{
+    return rw_is_write_locked(&p2m->lock);
+}
+
 #endif /* ASM__RISCV__P2M_H */
 
 /*
diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
index f33c7147ff..e409997499 100644
--- a/xen/arch/riscv/p2m.c
+++ b/xen/arch/riscv/p2m.c
@@ -1,13 +1,46 @@
 #include 
+#include 
 #include 
+#include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
 
+#include 
 #include 
 #include 
 
+/*
+ * Force a synchronous P2M TLB flush.
+ *
+ * Must be called with the p2m lock held.
+ */
+static void p2m_force_tlb_flush_sync(struct p2m_domain *p2m)
+{
+    struct domain *d = p2m->domain;
+
+    ASSERT(p2m_is_write_locked(p2m));
+
+    sbi_remote_hfence_gvma_vmid(d->dirty_cpumask, 0, 0, p2m->vmid);
+}
+
+/* Unlock the flush and do a P2M TLB flush if necessary */
+void p2m_write_unlock(struct p2m_domain *p2m)
+{
+    /*
+     * The final flush is done with the P2M write lock taken to avoid
+     * someone else modifying the P2M wbefore the TLB invalidation has
+     * completed.
+     */
+    p2m_force_tlb_flush_sync(p2m);
+
+    write_unlock(&p2m->lock);
+}
+
 static spinlock_t vmid_alloc_lock = SPIN_LOCK_UNLOCKED;
 
 /*
@@ -109,8 +142,33 @@ int p2m_init(struct domain *d)
     spin_lock_init(&d->arch.paging.lock);
     INIT_PAGE_LIST_HEAD(&d->arch.paging.p2m_freelist);
 
+    rwlock_init(&p2m->lock);
+    INIT_PAGE_LIST_HEAD(&p2m->pages);
+
     p2m->vmid = INVALID_VMID;
 
+    p2m->default_access = p2m_access_rwx;
+
+    radix_tree_init(&p2m->p2m_type);
+
+#ifdef CONFIG_HAS_PASSTHROUGH
+    /*
+     * Some IOMMUs don't support coherent PT walk. When the p2m is
+     * shared with the CPU, Xen has to make sure that the PT changes have
+     * reached the memory
+     */
+    p2m->clean_pte = is_iommu_enabled(d) &&
+        !iommu_has_feature(d, IOMMU_FEAT_COHERENT_WALK);
+#else
+    p2m->clean_pte = false;
+#endif
+
+    /*
+     * "Trivial" initialisation is now complete.  Set the backpointer so the
+     * users of p2m could get an access to domain structure.
+     */
+    p2m->domain = d;
+
     rc = p2m_alloc_vmid(d);
     if ( rc )
         return rc;
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 13:05:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 13:05:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010789.1389049 (Exim 4.92)
	(envelope-from )
	id 1uOyfp-0006gq-Ap; Tue, 10 Jun 2025 13:05:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010789.1389049; Tue, 10 Jun 2025 13: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 1uOyfp-0006g1-3j; Tue, 10 Jun 2025 13:05:53 +0000
Received: by outflank-mailman (input) for mailman id 1010789;
 Tue, 10 Jun 2025 13: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 1uOyfm-0004Sm-TA
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 13:05:50 +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 a127a942-45fb-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 15:05:49 +0200 (CEST)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-ad88eb71eb5so745252066b.0
 for ; Tue, 10 Jun 2025 06:05:49 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ade32c42770sm626465466b.41.2025.06.10.06.05.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 10 Jun 2025 06:05:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a127a942-45fb-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749560748; x=1750165548; darn=lists.xenproject.org;
        h=content-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=vgDItj/Bt+Pokzd4VeTK3tNuj4yPdCLljiPQUCHOaVk=;
        b=DZXqmF8yw+n8vHvFRijSCXknuC2VvQWVn++eiYu+oj42DewjK3jojqcLnew3D7qfBy
         N+eFPQaWKku3yl6QZMo8IgCtkla/RE2FAnkItjzdig4qO0e8RTMQGf96VBX2rpWDIlrM
         hw+r5Ma/9i6lH7ObwK0DqWtxNS4T0Z0ig6RNQYz+VuZ9ffbjJAHSGBNqM9AXORb3+eQs
         zBOydzOYx+t1Di7aqZpbdTimYPdA/FDX6+Ddu8NvPCmPpvwfLZgmkmRnylZXutVONx97
         cp72BM3vgfj6fMnDLe8LloFDJvhtAi6X+s01krFzfvqCguyDgExIgAT/lG/r8bjzEIF8
         kyIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749560748; x=1750165548;
        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=vgDItj/Bt+Pokzd4VeTK3tNuj4yPdCLljiPQUCHOaVk=;
        b=hfbAlK9P231waWe8rwFqcnhfktbr6HaaXpYWHbHwdpwYdvb1b3xV4jC9fbr5W1yptu
         UqcPylvYZZ0FUGWcJ3MVUie9Q6wMM/8eiV1++Y88usVC051LP/cPnD1L8uRA8xUpGXaD
         hG+c9mV5WYn2LlU7N5oya9qdV38K05uQbWrGo7UpANEwrYZZ0aUKIA2Qdf+PTCYYhiIl
         LZYm/1Rhmyz5j19zGQ8Mc1n+GW2szkYmMN3a3JEkKpwZ7/UHBMiRtdCll698AwWlJ/3a
         mo43KETx082Q/CeylibeYz0bja5a0RcO4q7FQ4DYgz+cINP+xu8LPl/n3uvBKFAeAA2f
         7Jwg==
X-Gm-Message-State: AOJu0YxxboOUVlI3CIKVsOdp09dzzcQ95VkKWt969YQcqWoXj6CvjJsP
	XxjHQk6RHGfkUmxozJyMfpTLqTEmw4Jca8OjaF8QaYnoyITWivojmaBphoZFnw==
X-Gm-Gg: ASbGnctXZZ9KBuYjpTcRNuQFSLV8xsGtD3PVtQOeQjp0/mESXvgJYgMwdvLj+iL61UH
	hH86FJ70QBum7WUQRg9ci2NRRGeAoTEun2OBg8m+Xt9dCt9xj5kpwgEoifLb/mlQX6eE1RmeZbu
	58U1HauCbp4zh2vcmwlZk+uRckH1JNnZee5B6InotJHis7G6ha8oOGMaGHV1riljRsVpURR68aq
	d/EOhFrb0iGS88+6J5vyRvaqOUfZt7rC9jJnSFG8jrVGAoh3FWjf6kGyd4eKo26ZUE0B61ZcANx
	Pz6Ed8FrhV1e19oGF5+vud/nq6ijkgl3vRwdPZvfk/exeyO3m2k/ITYwK6n3GxygFTlbqaTxg+R
	pmKIwH/HfjU7M5upbjrHLjxhvYGcJ
X-Google-Smtp-Source: AGHT+IHyp9el8zq0YS8Dtc+4LmQcBKrv1C8HmiuR5ZqVVMf5an/ANNzub+p9XkEnawpv2328xnzCVw==
X-Received: by 2002:a17:907:6d12:b0:ad8:a684:a1f7 with SMTP id a640c23a62f3a-ade7acdf570mr245655766b.30.1749560748353;
        Tue, 10 Jun 2025 06:05:48 -0700 (PDT)
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 07/17] xen/riscv: introduce pte_{set,get}_mfn()
Date: Tue, 10 Jun 2025 15:05:22 +0200
Message-ID: <5e2f0cea49ac1e0669be15811b1426bf4b4d2fec.1749555949.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Introduce helpers pte_{set,get}_mfn() to simplify setting and getting
of mfn.

Also, introduce PTE_PPN_MASK and add BUILD_BUG_ON() to be sure that
PTE_PPN_MASK remains the same for all MMU modes except Sv32.

Signed-off-by: Oleksii Kurochko 
---
Changes in V2:
 - Patch "[PATCH v1 4/6] xen/riscv: define pt_t and pt_walk_t structures" was
   renamed to xen/riscv: introduce pte_{set,get}_mfn() as after dropping of
   bitfields for PTE structure, this patch introduce only pte_{set,get}_mfn().
 - As pt_t and pt_walk_t were dropped, update implementation of
   pte_{set,get}_mfn() to use bit operations and shifts instead of bitfields.
 - Introduce PTE_PPN_MASK to be able to use MASK_INSR for setting/getting PPN.
 - Add BUILD_BUG_ON(RV_STAGE1_MODE > SATP_MODE_SV57) to be sure that when
   new MMU mode will be added, someone checks that PPN is still bits 53:10.
---
 xen/arch/riscv/include/asm/page.h | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h
index 4cb0179648..1b8b145663 100644
--- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -114,6 +114,30 @@ typedef struct {
 #endif
 } pte_t;
 
+#if RV_STAGE1_MODE != SATP_MODE_SV32
+#define PTE_PPN_MASK _UL(0x3FFFFFFFFFFC00)
+#else
+#define PTE_PPN_MASK _U(0xFFFFFC00)
+#endif
+
+static inline void pte_set_mfn(pte_t *p, mfn_t mfn)
+{
+    /*
+     * At the moment spec provides Sv32 - Sv57.
+     * If one day new MMU mode will be added it will be needed
+     * to check that PPN mask still continue to cover bits 53:10.
+     */
+    BUILD_BUG_ON(RV_STAGE1_MODE > SATP_MODE_SV57);
+
+    p->pte &= ~PTE_PPN_MASK;
+    p->pte |= MASK_INSR(mfn_x(mfn), PTE_PPN_MASK);
+}
+
+static inline mfn_t pte_get_mfn(pte_t p)
+{
+    return _mfn(MASK_EXTR(p.pte, PTE_PPN_MASK));
+}
+
 static inline pte_t paddr_to_pte(paddr_t paddr,
                                  unsigned int permissions)
 {
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 13:05:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 13:05:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010790.1389054 (Exim 4.92)
	(envelope-from )
	id 1uOyfp-0006mg-T8; Tue, 10 Jun 2025 13:05:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010790.1389054; Tue, 10 Jun 2025 13: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 1uOyfp-0006l6-JQ; Tue, 10 Jun 2025 13:05:53 +0000
Received: by outflank-mailman (input) for mailman id 1010790;
 Tue, 10 Jun 2025 13:05: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 1uOyfo-0004Sm-2h
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 13:05:52 +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 a1d624fb-45fb-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 15:05:50 +0200 (CEST)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-acae7e7587dso823661566b.2
 for ; Tue, 10 Jun 2025 06:05:50 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ade32c42770sm626465466b.41.2025.06.10.06.05.48
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 10 Jun 2025 06:05:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a1d624fb-45fb-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749560750; x=1750165550; darn=lists.xenproject.org;
        h=content-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=wljNhX5Z+KEFF48phAFs/NmPQwz56AjKrfG07RWLiVw=;
        b=Vn1/yWEBMYmo+Z/CrH+R8PICecpmbyqJHEGPrtvN8I723o0L0qIy09wOgkD0/r/d9E
         Xie3LqYjqr4appOhIUE4mm2ZGmxvCejmPH+HU3CzQIz2ZXFdpc+bIEvrz3V4Y6DxweuU
         Z3rPY074N/0bnv9w1/QsxGgCMjRbJL4B2iS5DsBQHa9lAFH0XYSoSoxZGOUiZOFynKRZ
         BnCwEiTIYI5dOY4mBfK3tBZqc573w6SZ1aEsnu1QsQSsazPGanpdtiQr/ShttTZrPeXF
         qNUBzfwewKawX+4B77odSYNQTFtddAFK9gGypPVROLDboS2G/MuhJ/r09It7ffqoM3RH
         h87A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749560750; x=1750165550;
        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=wljNhX5Z+KEFF48phAFs/NmPQwz56AjKrfG07RWLiVw=;
        b=lWSfSGnAahX1OmFtX80pzh2pVkGzrE26R11qitcn/AQ1O45gH6ZAMILp7tM2nPuRXB
         4rAKn0AbTQUmFre42DBNFNgXUVFQYcUYijWSX8bz0kAReEZZCfe2lViR96mltNTot3WV
         rxELeQmm/8NZnewrzFtXtyiWWG4tvA+zZAHHFD1Ji6io1GyiPDbQVT3UNN072Pohjk4m
         zHdxMZ1QwIn0XR/+58Fdxw0PzcD0mkIE5pl0xkaeXp2RnkFgKxQb7EsLgPMHkd0G9BLp
         4lAx5JLcHwQw6MzfBZqe7c1auNDX0XcOAOfv5PNZOn75TEBZbuM4i3qs8Z+1twC0afme
         jPMA==
X-Gm-Message-State: AOJu0YzAIYwNlISlFRaNFMBmP2S1Sp2x0wRUiPRIwpHs5bQY0sw77VKh
	dIVIa7bgOREzIIkdqlj3BKGQ3q1QH1Brw3tdztTFPdRpujyzXZZhOAKd7u/SZQ==
X-Gm-Gg: ASbGncudktniiDyI763MF8i6scDwyVU9KpnangAYNlDdG3MZ0pzFBl68dHV8UkyXzWy
	2DyLYBZFUINDAMj8mi2tBKQp/sz99Z8xOq13TNrjKbW2AHM+7asViHqzMcSLIh2uCIZj0TewhDm
	2UWFD95YmbWR9HpdoN9SN9bpfb0jOqM/am21HE7sVVPBPvc9DV5c6I96yD5lTqJWty8YvB+c27C
	/28gOFXXofMorwiXQD5omosRlcgnRtkSi8LWoAjVOPtMZpMm3mEAtEUTZtp/lHXVtNHi3qowlae
	BhRyOXlQf/dlWI6vMsB2XyukukIQxCEJdsknRFTIef+XVPEmNw8JQG4dP2PxZ/VxcOniG0o8DMR
	jU5Wgx4aIhZY01Dre1iPbIWlYPXC5
X-Google-Smtp-Source: AGHT+IGFjTXdFlS6sZvD06fXM72cWhnM/gD4j/C7i7+WrXUDNN4lIYkxwD7jGkhRmCOFEo4b6nz+FA==
X-Received: by 2002:a17:907:6ea8:b0:ade:450a:695a with SMTP id a640c23a62f3a-ade450a70e9mr993218466b.61.1749560749329;
        Tue, 10 Jun 2025 06:05:49 -0700 (PDT)
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 08/17] xen/riscv: add new p2m types and helper macros for type classification
Date: Tue, 10 Jun 2025 15:05:23 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

- Extended p2m_type_t with additional types: p2m_ram_ro, p2m_mmio_direct_dev,
  p2m_grant_map_{rw,ro}.
- Added macros to classify memory types: P2M_RAM_TYPES, P2M_GRANT_TYPES.
- Introduced helper predicates: p2m_is_ram(), p2m_is_any_ram().

Signed-off-by: Oleksii Kurochko 
---
Changes in V2:
 - Drop stuff connected to foreign mapping as it isn't necessary for RISC-V
   right now.
---
 xen/arch/riscv/include/asm/p2m.h | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/xen/arch/riscv/include/asm/p2m.h b/xen/arch/riscv/include/asm/p2m.h
index a31b05bd50..0c05b58992 100644
--- a/xen/arch/riscv/include/asm/p2m.h
+++ b/xen/arch/riscv/include/asm/p2m.h
@@ -61,8 +61,28 @@ struct p2m_domain {
 typedef enum {
     p2m_invalid = 0,    /* Nothing mapped here */
     p2m_ram_rw,         /* Normal read/write domain RAM */
+    p2m_ram_ro,         /* Read-only; writes are silently dropped */
+    p2m_mmio_direct_dev,/* Read/write mapping of genuine Device MMIO area */
+    p2m_grant_map_rw,   /* Read/write grant mapping */
+    p2m_grant_map_ro,   /* Read-only grant mapping */
 } p2m_type_t;
 
+/* We use bitmaps and mask to handle groups of types */
+#define p2m_to_mask(t_) BIT(t_, UL)
+
+/* RAM types, which map to real machine frames */
+#define P2M_RAM_TYPES (p2m_to_mask(p2m_ram_rw) | \
+                       p2m_to_mask(p2m_ram_ro))
+
+/* Grant mapping types, which map to a real frame in another VM */
+#define P2M_GRANT_TYPES (p2m_to_mask(p2m_grant_map_rw) | \
+                         p2m_to_mask(p2m_grant_map_ro))
+
+/* Useful predicates */
+#define p2m_is_ram(t_) (p2m_to_mask(t_) & P2M_RAM_TYPES)
+#define p2m_is_any_ram(t_) (p2m_to_mask(t_) & \
+                            (P2M_RAM_TYPES | P2M_GRANT_TYPES))
+
 #include 
 
 static inline int get_page_and_type(struct page_info *page,
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 13:05:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 13:05:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010791.1389067 (Exim 4.92)
	(envelope-from )
	id 1uOyfr-0007Cf-IA; Tue, 10 Jun 2025 13:05:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010791.1389067; Tue, 10 Jun 2025 13: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 1uOyfr-0007BD-8R; Tue, 10 Jun 2025 13:05:55 +0000
Received: by outflank-mailman (input) for mailman id 1010791;
 Tue, 10 Jun 2025 13:05: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 1uOyfp-0004iH-5G
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 13:05:53 +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 a3336bcd-45fb-11f0-a306-13f23c93f187;
 Tue, 10 Jun 2025 15:05:52 +0200 (CEST)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-60779962c00so5213372a12.0
 for ; Tue, 10 Jun 2025 06:05:52 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ade32c42770sm626465466b.41.2025.06.10.06.05.50
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 10 Jun 2025 06:05:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a3336bcd-45fb-11f0-a306-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749560752; x=1750165552; darn=lists.xenproject.org;
        h=content-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=gNkxZ42334+z6GmMxmxS+7HSKZw12YWQKs0/M8Vj5io=;
        b=VXGKD+3BuvSfjXDuVxFLUGSX/qdS+TkT9hIZOt5rs6BrZaMMYU3mLvV6mlqefJja7l
         n+XYMCFxUHGLsTB4L86733oc/5PfGcPh5mquKlLF+etXoiAMBGfr3lWX9GkQlNik5V/r
         rUmz3rzn3JMA9kc2Lmve4DdYEXThVRQk5msgRMcggnxe3zVDMvDXq/YaVijQ26R2pBw/
         G16s/YUGOyRojK4OHDBQzegbfRBBwHYpZS/lJOxYva0weBaMWMSI22O+7s/s8+E/WO5R
         QYL+P9oRcmDlqUFrULQHACAG20dxdynJaf6YCeDuvAPwcE4yqHIGYIGR5FF8rXDuJuSQ
         RHSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749560752; x=1750165552;
        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=gNkxZ42334+z6GmMxmxS+7HSKZw12YWQKs0/M8Vj5io=;
        b=BbsvKjPZKSFve0fqlJm6ATTN5IpTUAid6+sVt0GQhGf4zC4os82M0wTIoHs4V6/8XZ
         J14exGyFZrxcr8u4e9bXKIJdoap2VvN81SMQrtPGhPOE4oPnLp/JZajn7xVqCnFiJ9j9
         BYtDJHrFmoKUGS+aQ3h0KTNAK6fjmuScrHsnLXJDoRqMpXVqxL2wW6oE2E5R6O3iZkUS
         Vfe6GKL3frf3B2Nn0mQwokcM8LQ1VKuCoR2t/K918oRbbuLlaA7bzHcLrIHp3AfbUg+i
         PwwH2x3K/pcfhZXtgFL1WvLnPxWgpLnJqOUh5xDZ+5IsylMIAxxLSiUAu/YSiW96G+c3
         wAXw==
X-Gm-Message-State: AOJu0Yz6xb9nstFqwbX+yjfaiNNulmPOASU4GEZTcz+BbsLieuBIZi8r
	io+iEQtWkOBLi+w06ar9VMI+Gli6nqzou6ezIXng9vlgyPI3QNhQ6JPlgz87Cw==
X-Gm-Gg: ASbGncsOiyY6ulD8EfGY0R5JCWWX2gmq5zF/lOsA8vkq4KI4qfHpl57ojpzyt9zPl0V
	U240fYchdxPi+VS6gMzbnDChWlQtBeTQQVr6QBhTzf7w8gDktv0punB0+jz+YwkLYr4QG9CwbFQ
	2dWFKs7FS5+vVGwlCLFIUv4j44HxqDsEWTdhEriCkHkwR6z3Dlvvyr/v7dhBoNQsV+vtzX5Iifj
	BxFeT53aK94185MhnX0G7ur19z7+rzhf2w5OB38MUFi5rGVXr6eXNYlDTFbYkLf6B8e0ktZ66sD
	HzJQRb2hVo3o7VaClcJI1aOenuSx0Gecusc0TzCFY3MxG8PvclAzrIMluBWhWlv6pGTX0fY6peC
	QBerDTnWltJzb/ufbwL24ogLStaI4
X-Google-Smtp-Source: AGHT+IEwUk/N6nuaSDBPQ9NVq1w1pYsClr/9Kn8IdxMkNjnhzTDXDYOmLNhr3sE9Kt5YGObsT2BNMQ==
X-Received: by 2002:a17:907:9349:b0:ad2:5499:7599 with SMTP id a640c23a62f3a-ade1a93baf1mr1471045166b.18.1749560751517;
        Tue, 10 Jun 2025 06:05:51 -0700 (PDT)
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 10/17] xen/riscv: implement guest_physmap_add_entry() for mapping GFNs to MFNs
Date: Tue, 10 Jun 2025 15:05:25 +0200
Message-ID: <0b1f7ead7eb1b7c8687d388cca50b46eefb8e408.1749555949.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Introduce an initial implementation of guest_physmap_add_entry() on RISC-V
by adding a basic framework to insert guest physical memory mappings.
This allows mapping a range of GFNs to MFNs using a placeholder
p2m_set_entry() function, which currently returns -EOPNOTSUPP.

Changes included:
- Promoting guest_physmap_add_entry() from a stub to a functional
  interface calling a new p2m_insert_mapping() helper.
- Adding map_regions_p2mt() for generic mapping purposes.
- Introducing p2m_insert_mapping() and a skeleton for p2m_set_entry() to
  prepare for future support of actual page table manipulation.
- Enclosing the actual mapping logic within
  p2m_write_lock() / p2m_write_unlock() to ensure safe concurrent
  updates to the P2M.

Signed-off-by: Oleksii Kurochko 
---
Changes in v2:
 - This changes were part of "xen/riscv: implement p2m mapping functionality".
   No additional signigicant changes were done.
---
 xen/arch/riscv/include/asm/p2m.h | 12 ++++------
 xen/arch/riscv/p2m.c             | 41 ++++++++++++++++++++++++++++++++
 2 files changed, 45 insertions(+), 8 deletions(-)

diff --git a/xen/arch/riscv/include/asm/p2m.h b/xen/arch/riscv/include/asm/p2m.h
index 0c05b58992..af2025b9fd 100644
--- a/xen/arch/riscv/include/asm/p2m.h
+++ b/xen/arch/riscv/include/asm/p2m.h
@@ -118,14 +118,10 @@ static inline int guest_physmap_mark_populate_on_demand(struct domain *d,
     return -EOPNOTSUPP;
 }
 
-static inline int guest_physmap_add_entry(struct domain *d,
-                                          gfn_t gfn, mfn_t mfn,
-                                          unsigned long page_order,
-                                          p2m_type_t t)
-{
-    BUG_ON("unimplemented");
-    return -EINVAL;
-}
+int guest_physmap_add_entry(struct domain *d,
+                            gfn_t gfn, mfn_t mfn,
+                            unsigned long page_order,
+                            p2m_type_t t);
 
 /* Untyped version for RAM only, for compatibility */
 static inline int __must_check
diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
index 2419a61d8c..cea37c8bda 100644
--- a/xen/arch/riscv/p2m.c
+++ b/xen/arch/riscv/p2m.c
@@ -324,3 +324,44 @@ int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
 
     return 0;
 }
+
+static int p2m_set_entry(struct p2m_domain *p2m,
+                         gfn_t sgfn,
+                         unsigned long nr,
+                         mfn_t smfn,
+                         p2m_type_t t,
+                         p2m_access_t a)
+{
+    return -EOPNOTSUPP;
+}
+
+static int p2m_insert_mapping(struct domain *d, gfn_t start_gfn,
+                              unsigned long nr, mfn_t mfn, p2m_type_t t)
+{
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    int rc;
+
+    p2m_write_lock(p2m);
+    rc = p2m_set_entry(p2m, start_gfn, nr, mfn, t, p2m->default_access);
+    p2m_write_unlock(p2m);
+
+    return rc;
+}
+
+int map_regions_p2mt(struct domain *d,
+                     gfn_t gfn,
+                     unsigned long nr,
+                     mfn_t mfn,
+                     p2m_type_t p2mt)
+{
+    return p2m_insert_mapping(d, gfn, nr, mfn, p2mt);
+}
+
+int guest_physmap_add_entry(struct domain *d,
+                            gfn_t gfn,
+                            mfn_t mfn,
+                            unsigned long page_order,
+                            p2m_type_t t)
+{
+    return p2m_insert_mapping(d, gfn, (1 << page_order), mfn, t);
+}
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 13:05:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 13:05:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010792.1389074 (Exim 4.92)
	(envelope-from )
	id 1uOyfs-0007H7-9J; Tue, 10 Jun 2025 13:05:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010792.1389074; Tue, 10 Jun 2025 13:05: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 1uOyfr-0007Fz-Mb; Tue, 10 Jun 2025 13:05:55 +0000
Received: by outflank-mailman (input) for mailman id 1010792;
 Tue, 10 Jun 2025 13:05: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 1uOyfp-0004Sm-E0
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 13:05:53 +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 a2a0ba8a-45fb-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 15:05:51 +0200 (CEST)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-ade30256175so732559266b.1
 for ; Tue, 10 Jun 2025 06:05:51 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ade32c42770sm626465466b.41.2025.06.10.06.05.49
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 10 Jun 2025 06:05:50 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a2a0ba8a-45fb-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749560751; x=1750165551; darn=lists.xenproject.org;
        h=content-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=oVaSdEzC4kuCiD3ZiuCTTzD/g+ai4zWkigRCI0Mr+vI=;
        b=MWJGlQtF4LJiNfUNvmSLhz2vdmMcmBxnWqAjqQvbzm87PH6H9SnKpmbzXBbjahBj5R
         UtiwxXYLsSLKYZGDsYuCfrnZj7y8gIEm9kP9ggwHkBHOQU3BeE5DCZZWWfAbhnPP1rNq
         PONijfB0kTAz05H82T7jDDnP2QboPZbsSN+B6IFsj2kK3MEJsmsn12pVNFG7yeqv25k/
         ZEbslCg9jRKJp77S50eUa+CEZeSt6O3wZsaXo8jhDIJk6OrdQLzIMuirHLz5tCbtKJrx
         VCDgv+n5Pmq5PeGQ9BeSrudVLB0oaM2WE5XDBFgJPh/z1+ayB0QE1BD1BZYRYpcj2YQ9
         g4Sw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749560751; x=1750165551;
        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=oVaSdEzC4kuCiD3ZiuCTTzD/g+ai4zWkigRCI0Mr+vI=;
        b=fRvR4XvaUyg5zIn3vqjM8i/0mGrYNdokxduW2uBUbCwfLsDmQiATf/Xn7LnEhcoK7F
         IS6Nrd8OCt1CNgCuLhJlc9gtpNSWIrBCTDgTXOLnpfS9RTEMya5UN1uw516tKXAiVNoY
         p0HxiZL5vIX8qthvmoxO52jJNKWpvKG23iY/Odh8e8bNpe5CWSrX7TP8ucWxPqMYvvFC
         05yvfYlMrtJ0r+nZJC0TJzI9SXyU2aNrAhtWY2vUr8zbcevNnqPD7wC17Z76w0RCloEm
         5VXxHdkLnfZYCuOTSaH5gswLxB3NeV/hlJHeRO7x1JBPFGLQR7SXIXyE8dgbMABDGLPJ
         ZjfA==
X-Gm-Message-State: AOJu0YwPA4Up0/rqQxF6gfMqUqEEA9Z3vudrvWKq9atVZsDUA9tqvFC0
	Yhx7iHigu4kZeIzXXPhVctKm9aF0x2/aM2ovfSPCgnjtrbv7ipKQlxXwfy1G8g==
X-Gm-Gg: ASbGnctxsKx7td2q2cKr2y8fidJAzStxlsPeTh2Z7VFA5g21vyqrTXZGAC65X/vpAAb
	WrV2YTv0azGGYZ9mTBS/muuzTSH738MYrIQW8iXNL0Nz2Pm39HLhD0Ntm4VUxikWdnCGhegxDAJ
	/Z/7LL0cBWPmV8zHDTYhQsRTn9C0VS+V8WAZSuqeOcuifnaOCXaHjoKgX/QVBbcJwPjzjS/91Rv
	Q3zklYPvxDW94aLIxf+gj/+79i5ivmKIZR4vumOhi2pvEcffgRPso1L/gaSZ/dYIHdxxcZiU6Bx
	uHtZ94m0OkJirr+XSWXbLl3PwMC3oXWzLZK5sM0Dptahs+dq/aKZbJc8+B6L5wIEMwq3TrVI93E
	loVdU4mCHU6E7UzRBpDOtpM/9aHiG
X-Google-Smtp-Source: AGHT+IE57NqUZYYdmSJcp44+MSwcLpDkmkm3jzcquze2ekyofX7OKjw2jn8+5NYp/0z4UB7CpLhpug==
X-Received: by 2002:a17:907:c15:b0:adb:3272:7df5 with SMTP id a640c23a62f3a-ade1a93bb89mr1797332166b.16.1749560750536;
        Tue, 10 Jun 2025 06:05:50 -0700 (PDT)
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 09/17] xen/riscv: introduce page_set_xenheap_gfn()
Date: Tue, 10 Jun 2025 15:05:24 +0200
Message-ID: <186e4a778a6dfab205428dfb4d0c59584a162a9f.1749555949.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Introduce page_set_xenheap_gfn() helper to encode the GFN associated with
a Xen heap page directly into the type_info field of struct page_info.

Introduce a GFN field in the type_info of a Xen heap page by reserving 10
bits (sufficient for both Sv32 and Sv39+ modes), and define PGT_gfn_mask
and PGT_gfn_width accordingly. This ensures a consistent bit layout across
all RISC-V MMU modes, avoiding the need for mode-specific ifdefs.

Signed-off-by: Oleksii Kurochko 
---
Changes in v2:
 - This changes were part of "xen/riscv: implement p2m mapping functionality".
   No additional changes were done.
---
 xen/arch/riscv/include/asm/mm.h | 32 +++++++++++++++++++++++++++++---
 1 file changed, 29 insertions(+), 3 deletions(-)

diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
index 912bc79e1b..41bf9002d7 100644
--- a/xen/arch/riscv/include/asm/mm.h
+++ b/xen/arch/riscv/include/asm/mm.h
@@ -12,6 +12,7 @@
 #include 
 #include 
 
+#include 
 #include 
 
 extern vaddr_t directmap_virt_start;
@@ -229,9 +230,21 @@ static inline bool arch_mfns_in_directmap(unsigned long mfn, unsigned long nr)
 #define PGT_writable_page PG_mask(1, 1)  /* has writable mappings?         */
 #define PGT_type_mask     PG_mask(1, 1)  /* Bits 31 or 63.                 */
 
-/* Count of uses of this frame as its current type. */
-#define PGT_count_width   PG_shift(2)
-#define PGT_count_mask    ((1UL << PGT_count_width) - 1)
+ /* 9-bit count of uses of this frame as its current type. */
+#define PGT_count_mask    PG_mask(0x3FF, 10)
+
+/*
+ * Sv32 has 22-bit GFN. Sv{39, 48, 57} have 44-bit GFN.
+ * Thereby we can use for `type_info` 10 bits for all modes, having the same
+ * amount of bits for `type_info` for all MMU modes let us avoid introducing
+ * an extra #ifdef to that header:
+ *   if we go with maximum possible bits for count on each configuration
+ *   we would need to have a set of PGT_count_* and PGT_gfn_*).
+ */
+#define PGT_gfn_width     PG_shift(10)
+#define PGT_gfn_mask      (BIT(PGT_gfn_width, UL) - 1)
+
+#define PGT_INVALID_XENHEAP_GFN   _gfn(PGT_gfn_mask)
 
 /*
  * Page needs to be scrubbed. Since this bit can only be set on a page that is
@@ -283,6 +296,19 @@ static inline bool arch_mfns_in_directmap(unsigned long mfn, unsigned long nr)
 
 #define PFN_ORDER(pg) ((pg)->v.free.order)
 
+static inline void page_set_xenheap_gfn(struct page_info *p, gfn_t gfn)
+{
+    gfn_t gfn_ = gfn_eq(gfn, INVALID_GFN) ? PGT_INVALID_XENHEAP_GFN : gfn;
+    unsigned long x, nx, y = p->u.inuse.type_info;
+
+    ASSERT(is_xen_heap_page(p));
+
+    do {
+        x = y;
+        nx = (x & ~PGT_gfn_mask) | gfn_x(gfn_);
+    } while ( (y = cmpxchg(&p->u.inuse.type_info, x, nx)) != x );
+}
+
 extern unsigned char cpu0_boot_stack[];
 
 void setup_initial_pagetables(void);
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 13:05:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 13:05:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010794.1389086 (Exim 4.92)
	(envelope-from )
	id 1uOyfu-0007vB-PT; Tue, 10 Jun 2025 13:05:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010794.1389086; Tue, 10 Jun 2025 13:05:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uOyfu-0007to-Gh; Tue, 10 Jun 2025 13:05:58 +0000
Received: by outflank-mailman (input) for mailman id 1010794;
 Tue, 10 Jun 2025 13:05: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 1uOyfr-0004Sm-Qm
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 13:05:55 +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 a3dcafd2-45fb-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 15:05:53 +0200 (CEST)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-ad8826c05f2so1032951666b.3
 for ; Tue, 10 Jun 2025 06:05:53 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ade32c42770sm626465466b.41.2025.06.10.06.05.51
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 10 Jun 2025 06:05:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a3dcafd2-45fb-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749560753; x=1750165553; darn=lists.xenproject.org;
        h=content-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=QKgMuqwtGlngKUtxs7WkqY46iwjdHqw/qZ4SKOhC8y4=;
        b=FCYOwUWE5szHaOoORZcTt73x45EFNkV4QLHrSyKYkZbG3w5SHTWV4FpAqhPyAmYvNg
         rCCpTdiHizF6Iny8XLhDnYEBmda18G5L8B74IruRMx/i6q1o8ngfziI4BXc8YDraI4Tj
         0wnu3KliP8nvFke7MOA9qrF817Bih7HylSab13tBv+bytU2/i0iiIbBUExdvNtGdhmSl
         8kUCT9XjCaCLGTbf9x5j2FUOKTmTt8BkonCt/XogV3yfk05a04N5aCH5oW9WPstOYRzS
         8Ow1u7oBbzjaAzUsex6AVE1d+jkGkkvmaNN7zpdnx2F1t/bUbC2/rdk3te5XZv3K0Tka
         E4sw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749560753; x=1750165553;
        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=QKgMuqwtGlngKUtxs7WkqY46iwjdHqw/qZ4SKOhC8y4=;
        b=ndbSuFoOLR8Nlp4eNG+nR1fFSNalnlI3ZdBcndB/Ew/GIqj27Zu/ZgHmlcZDItyb/I
         B6LpLZhGAi8KlGuPFn1GLfb4nXNSN3X0Ck9U2Wel3M4sqY1jfJdw0yEHLwYE2nJR5ODQ
         PNLU3grAI28L5ipg2Kp/XnUwYCofaMSBiG03+xMNpJT8beGilZnjYiOPJA9fRvXnAVsZ
         zb9L6mUGdn8riBmW7+BbXrw+oHd5oKHEvW2kh01rsVUT3fnIhTT/vP3GUvsqvOO4igjp
         grByP+f+0XdplANrbHNAiDUL/Ymda3Z9ANrDtGzrZlJjvV8LS7RvZaFnGLeUdh8bTkbC
         SK8A==
X-Gm-Message-State: AOJu0YxQCmFfXU8rkrv3Q9OU4Z0bBBGy34lrx0QOB0IjhnG/DNx+ZwwU
	82aPmg/CpblRyqo4i2/A97mfA6RsKWei7+HbsloaLOKYH8VD/xewaQK7yqSg+w==
X-Gm-Gg: ASbGncvfl+NAmvZ19tXQCMqHhZpiDgTvv/YgW/r3Op9nqz/ZP04IpaeQ6lcK0DJr9H+
	aBz5PF6ZRZovXeD1Or6pJmFcjUkAmHEkzAh5JWKcfGgpuwo06oXgRah3uFpzTd+kGdSOgo+yebY
	R5V/6z+U/sZkJqXlQlJNWPm5Nmp4dKlBrQf3q0StYqKmoCIp9/2NeQ3kdbGjw9tuqYzXA7usLH8
	rATYD6swroaHwZUTNT8zfhftr7UlQNYMdKEDsFv9GIv4shFLHtjEG8BnTA6gzxkduQsOZv+8Q9f
	YBek2xmlxRDrJYblqlSUbANW2sXD7UVRYcQSWjMSF+m7dwBQWIsOrWB6ezAYdPXvsyAz3oNOaZi
	bKPmQhsSG9VjwIRMQPqFQ1vTBP5s0
X-Google-Smtp-Source: AGHT+IE/MrshjTl9H2fGWoqTEfbobX3NFO8EvJMxaYOPyEN628kL3PsU5h5YcCUYk6w2ymkbH+oNww==
X-Received: by 2002:a17:907:d16:b0:ad9:f54f:70a2 with SMTP id a640c23a62f3a-ade1aa07b5fmr1528915966b.22.1749560752677;
        Tue, 10 Jun 2025 06:05:52 -0700 (PDT)
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 11/17] xen/riscv: implement p2m_set_entry() and __p2m_set_entry()
Date: Tue, 10 Jun 2025 15:05:26 +0200
Message-ID: <7826732d2f6aa5888758942165f0f1e73fa84ffa.1749555949.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

This patch introduces p2m_set_entry() and its core helper __p2m_set_entry() for
RISC-V, based loosely on the Arm implementation, with several RISC-V-specific
modifications.

Key differences include:
- TLB Flushing: RISC-V allows caching of invalid PTEs and does not require
  break-before-make (BBM). As a result, the flushing logic is simplified.
  TLB invalidation can be deferred until p2m_write_unlock() is called.
  Consequently, the p2m->need_flush flag is always considered true and is
  removed.
- Page Table Traversal: The order of walking the page tables differs from Arm,
  and this implementation reflects that reversed traversal.
- Macro Adjustments: The macros P2M_ROOT_LEVEL, P2M_ROOT_ORDER, and
  P2M_ROOT_PAGES are updated to align with the new RISC-V implementation.

The main functionality is in __p2m_set_entry(), which handles mappings aligned
to page table block entries (e.g., 1GB, 2MB, or 4KB with 4KB granularity).

p2m_set_entry() breaks a region down into block-aligned mappings and calls
__p2m_set_entry() accordingly.

Stub implementations (to be completed later) include:
- p2m_free_entry()
- p2m_next_level()
- p2m_entry_from_mfn()
- p2me_is_valid()

Note: Support for shattering block entries is not implemented in this patch
and will be added separately.

Additionally, some straightforward helper functions are now implemented:
- p2m_write_pte()
- p2m_remove_pte()
- p2m_get_root_pointer()

Signed-off-by: Oleksii Kurochko 
---
Changes in V2:
 - New patch. It was a part of a big patch "xen/riscv: implement p2m mapping
   functionality" which was splitted to smaller.
 - Update the way when p2m TLB is flushed:
 - RISC-V does't require BBM so there is no need to remove PTE before making
   new so drop 'if /*pte_is_valid(orig_pte) */' and remove PTE only removing
   has been requested.
 - Drop p2m->need_flush |= !!pte_is_valid(orig_pte); for the case when
   PTE's removing is happening as RISC-V could cache invalid PTE and thereby
   it requires to do a flush each time and it doesn't matter if PTE is valid
   or not at the moment when PTE removing is happening.
 - Drop a check if PTE is valid in case of PTE is modified as it was mentioned
   above as BBM isn't required so TLB flushing could be defered and there is
   no need to do it before modifying of PTE.
 - Drop p2m->need_flush as it seems like it will be always true.
 - Drop foreign mapping things as it isn't necessary for RISC-V right now.
 - s/p2m_is_valid/p2me_is_valid.
 - Move definition and initalization of p2m->{max_mapped_gfn,lowest_mapped_gfn}
   to this patch.
---
 xen/arch/riscv/include/asm/p2m.h |  16 ++
 xen/arch/riscv/p2m.c             | 260 ++++++++++++++++++++++++++++++-
 2 files changed, 275 insertions(+), 1 deletion(-)

diff --git a/xen/arch/riscv/include/asm/p2m.h b/xen/arch/riscv/include/asm/p2m.h
index af2025b9fd..fdebd18356 100644
--- a/xen/arch/riscv/include/asm/p2m.h
+++ b/xen/arch/riscv/include/asm/p2m.h
@@ -9,8 +9,13 @@
 #include 
 #include 
 
+#include 
 #include 
 
+#define P2M_ROOT_LEVEL  HYP_PT_ROOT_LEVEL
+#define P2M_ROOT_ORDER  XEN_PT_LEVEL_ORDER(P2M_ROOT_LEVEL)
+#define P2M_ROOT_PAGES  BIT(P2M_ROOT_ORDER, U)
+
 #define paddr_bits PADDR_BITS
 
 /* Get host p2m table */
@@ -49,6 +54,17 @@ struct p2m_domain {
 
     /* Current VMID in use */
     uint16_t vmid;
+
+    /* Highest guest frame that's ever been mapped in the p2m */
+    gfn_t max_mapped_gfn;
+
+    /*
+     * Lowest mapped gfn in the p2m. When releasing mapped gfn's in a
+     * preemptible manner this is update to track recall where to
+     * resume the search. Apart from during teardown this can only
+     * decrease.
+     */
+    gfn_t lowest_mapped_gfn;
 };
 
 /*
diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
index cea37c8bda..27499a86bb 100644
--- a/xen/arch/riscv/p2m.c
+++ b/xen/arch/riscv/p2m.c
@@ -231,6 +231,8 @@ int p2m_init(struct domain *d)
     INIT_PAGE_LIST_HEAD(&p2m->pages);
 
     p2m->vmid = INVALID_VMID;
+    p2m->max_mapped_gfn = _gfn(0);
+    p2m->lowest_mapped_gfn = _gfn(ULONG_MAX);
 
     p2m->default_access = p2m_access_rwx;
 
@@ -325,6 +327,214 @@ int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
     return 0;
 }
 
+/*
+ * Find and map the root page table. The caller is responsible for
+ * unmapping the table.
+ *
+ * The function will return NULL if the offset of the root table is
+ * invalid.
+ */
+static pte_t *p2m_get_root_pointer(struct p2m_domain *p2m, gfn_t gfn)
+{
+    unsigned long root_table_indx;
+
+    root_table_indx = gfn_x(gfn) >> XEN_PT_LEVEL_ORDER(P2M_ROOT_LEVEL);
+    if ( root_table_indx >= P2M_ROOT_PAGES )
+        return NULL;
+
+    return __map_domain_page(p2m->root + root_table_indx);
+}
+
+static inline bool p2me_is_valid(struct p2m_domain *p2m, pte_t pte)
+{
+    panic("%s: isn't implemented for now\n", __func__);
+
+    return false;
+}
+
+static inline void p2m_write_pte(pte_t *p, pte_t pte, bool clean_pte)
+{
+    write_pte(p, pte);
+    if ( clean_pte )
+        clean_dcache_va_range(p, sizeof(*p));
+}
+
+static inline void p2m_remove_pte(pte_t *p, bool clean_pte)
+{
+    pte_t pte;
+
+    memset(&pte, 0x00, sizeof(pte));
+    p2m_write_pte(p, pte, clean_pte);
+}
+
+static pte_t p2m_entry_from_mfn(struct p2m_domain *p2m, mfn_t mfn,
+                                p2m_type_t t, p2m_access_t a)
+{
+    panic("%s: hasn't been implemented yet\n", __func__);
+
+    return (pte_t) { .pte = 0 };
+}
+
+#define GUEST_TABLE_MAP_NONE 0
+#define GUEST_TABLE_MAP_NOMEM 1
+#define GUEST_TABLE_SUPER_PAGE 2
+#define GUEST_TABLE_NORMAL 3
+
+/*
+ * Take the currently mapped table, find the corresponding GFN entry,
+ * and map the next table, if available. The previous table will be
+ * unmapped if the next level was mapped (e.g GUEST_TABLE_NORMAL
+ * returned).
+ *
+ * `alloc_tbl` parameter indicates whether intermediate tables should
+ * be allocated when not present.
+ *
+ * Return values:
+ *  GUEST_TABLE_MAP_NONE: a table allocation isn't permitted.
+ *  GUEST_TABLE_MAP_NOMEM: allocating a new page failed.
+ *  GUEST_TABLE_SUPER_PAGE: next level or leaf mapped normally.
+ *  GUEST_TABLE_NORMAL: The next entry points to a superpage.
+ */
+static int p2m_next_level(struct p2m_domain *p2m, bool alloc_tbl,
+                          unsigned int level, pte_t **table,
+                          unsigned int offset)
+{
+    panic("%s: hasn't been implemented yet\n", __func__);
+
+    return GUEST_TABLE_MAP_NONE;
+}
+
+/* Free pte sub-tree behind an entry */
+static void p2m_free_entry(struct p2m_domain *p2m,
+                           pte_t entry, unsigned int level)
+{
+    panic("%s: hasn't been implemented yet\n", __func__);
+}
+
+/*
+ * Insert an entry in the p2m. This should be called with a mapping
+ * equal to a page/superpage.
+ */
+static int __p2m_set_entry(struct p2m_domain *p2m,
+                           gfn_t sgfn,
+                           unsigned int page_order,
+                           mfn_t smfn,
+                           p2m_type_t t,
+                           p2m_access_t a)
+{
+    unsigned int level;
+    unsigned int target = page_order / PAGETABLE_ORDER;
+    pte_t *entry, *table, orig_pte;
+    int rc;
+    /* A mapping is removed if the MFN is invalid. */
+    bool removing_mapping = mfn_eq(smfn, INVALID_MFN);
+    DECLARE_OFFSETS(offsets, gfn_to_gaddr(sgfn));
+
+    ASSERT(p2m_is_write_locked(p2m));
+
+    /*
+     * Check if the level target is valid: we only support
+     * 4K - 2M - 1G mapping.
+     */
+    ASSERT(target <= 2);
+
+    table = p2m_get_root_pointer(p2m, sgfn);
+    if ( !table )
+        return -EINVAL;
+
+    for ( level = P2M_ROOT_LEVEL; level > target; level-- )
+    {
+        /*
+         * Don't try to allocate intermediate page table if the mapping
+         * is about to be removed.
+         */
+        rc = p2m_next_level(p2m, !removing_mapping,
+                            level, &table, offsets[level]);
+        if ( (rc == GUEST_TABLE_MAP_NONE) || (rc == GUEST_TABLE_MAP_NOMEM) )
+        {
+            /*
+             * We are here because p2m_next_level has failed to map
+             * the intermediate page table (e.g the table does not exist
+             * and they p2m tree is read-only). It is a valid case
+             * when removing a mapping as it may not exist in the
+             * page table. In this case, just ignore it.
+             */
+            rc = removing_mapping ?  0 : -ENOENT;
+            goto out;
+        }
+        else if ( rc != GUEST_TABLE_NORMAL )
+            break;
+    }
+
+    entry = table + offsets[level];
+
+    /*
+     * If we are here with level > target, we must be at a leaf node,
+     * and we need to break up the superpage.
+     */
+    if ( level > target )
+    {
+        panic("Shattering isn't implemented\n");
+    }
+
+    /*
+     * We should always be there with the correct level because
+     * all the intermediate tables have been installed if necessary.
+     */
+    ASSERT(level == target);
+
+    orig_pte = *entry;
+
+    /*
+     * The access type should always be p2m_access_rwx when the mapping
+     * is removed.
+     */
+    ASSERT(!mfn_eq(INVALID_MFN, smfn) || (a == p2m_access_rwx));
+
+    if ( removing_mapping )
+        p2m_remove_pte(entry, p2m->clean_pte);
+    else {
+        pte_t pte = p2m_entry_from_mfn(p2m, smfn, t, a);
+
+        p2m_write_pte(entry, pte, p2m->clean_pte);
+
+        p2m->max_mapped_gfn = gfn_max(p2m->max_mapped_gfn,
+                                      gfn_add(sgfn, (1UL << page_order) - 1));
+        p2m->lowest_mapped_gfn = gfn_min(p2m->lowest_mapped_gfn, sgfn);
+    }
+
+#ifdef CONFIG_HAS_PASSTHROUGH
+    if ( is_iommu_enabled(p2m->domain) &&
+         (pte_is_valid(orig_pte) || pte_is_valid(*entry)) )
+    {
+        unsigned int flush_flags = 0;
+
+        if ( pte_is_valid(orig_pte) )
+            flush_flags |= IOMMU_FLUSHF_modified;
+        if ( pte_is_valid(*entry) )
+            flush_flags |= IOMMU_FLUSHF_added;
+
+        rc = iommu_iotlb_flush(p2m->domain, _dfn(gfn_x(sgfn)),
+                               1UL << page_order, flush_flags);
+    }
+    else
+#endif
+        rc = 0;
+
+    /*
+     * Free the entry only if the original pte was valid and the base
+     * is different (to avoid freeing when permission is changed).
+     */
+    if ( p2me_is_valid(p2m, orig_pte) &&
+         !mfn_eq(pte_get_mfn(*entry), pte_get_mfn(orig_pte)) )
+        p2m_free_entry(p2m, orig_pte, level);
+
+out:
+    unmap_domain_page(table);
+
+    return rc;
+}
+
 static int p2m_set_entry(struct p2m_domain *p2m,
                          gfn_t sgfn,
                          unsigned long nr,
@@ -332,7 +542,55 @@ static int p2m_set_entry(struct p2m_domain *p2m,
                          p2m_type_t t,
                          p2m_access_t a)
 {
-    return -EOPNOTSUPP;
+    int rc = 0;
+
+    /*
+     * Any reference taken by the P2M mappings (e.g. foreign mapping) will
+     * be dropped in relinquish_p2m_mapping(). As the P2M will still
+     * be accessible after, we need to prevent mapping to be added when the
+     * domain is dying.
+     */
+    if ( unlikely(p2m->domain->is_dying) )
+        return -ENOMEM;
+
+    while ( nr )
+    {
+        unsigned long mask;
+        unsigned long order = 0;
+        /* 1gb, 2mb, 4k mappings are supported */
+        unsigned int i = ( P2M_ROOT_LEVEL > 2 ) ? 2 : P2M_ROOT_LEVEL;
+
+        /*
+         * Don't take into account the MFN when removing mapping (i.e
+         * MFN_INVALID) to calculate the correct target order.
+         *
+         * XXX: Support superpage mappings if nr is not aligned to a
+         * superpage size.
+         */
+        mask = !mfn_eq(smfn, INVALID_MFN) ? mfn_x(smfn) : 0;
+        mask |= gfn_x(sgfn) | nr;
+
+        for ( ; i != 0; i-- )
+        {
+            if ( !(mask & (BIT(XEN_PT_LEVEL_ORDER(i), UL) - 1)) )
+            {
+                    order = XEN_PT_LEVEL_ORDER(i);
+                    break;
+            }
+        }
+
+        rc = __p2m_set_entry(p2m, sgfn, order, smfn, t, a);
+        if ( rc )
+            break;
+
+        sgfn = gfn_add(sgfn, (1 << order));
+        if ( !mfn_eq(smfn, INVALID_MFN) )
+           smfn = mfn_add(smfn, (1 << order));
+
+        nr -= (1 << order);
+    }
+
+    return rc;
 }
 
 static int p2m_insert_mapping(struct domain *d, gfn_t start_gfn,
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 13:05:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 13:05:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010796.1389094 (Exim 4.92)
	(envelope-from )
	id 1uOyfv-00083l-Nx; Tue, 10 Jun 2025 13:05:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010796.1389094; Tue, 10 Jun 2025 13: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 1uOyfv-00081x-Bb; Tue, 10 Jun 2025 13:05:59 +0000
Received: by outflank-mailman (input) for mailman id 1010796;
 Tue, 10 Jun 2025 13:05: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 1uOyfs-0004Sm-Qb
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 13:05:56 +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 a4859e46-45fb-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 15:05:54 +0200 (CEST)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-ade76b8356cso198040066b.2
 for ; Tue, 10 Jun 2025 06:05:55 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ade32c42770sm626465466b.41.2025.06.10.06.05.52
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 10 Jun 2025 06:05:53 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a4859e46-45fb-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749560754; x=1750165554; darn=lists.xenproject.org;
        h=content-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=isW7H3XxNDJXOKkXKD+BdxkPdas0tvZOP6WE8bHGH6A=;
        b=J8Y4UlPzelSPjdd0gYIr+u56Vnc7QtThbAhLkFEQf5yZ4xEnez1elnd7+T4pIdvvjk
         LzGQjSAzQljlLcfeb5ywMyRHw6sA7GAKrMmtVUVK8/S+LGHFMhesK5CMJkBdodCd35+a
         R9Xog8JXZxpdixUJQ4pNToPvDQJaFaJWw0zajk1wcctoNMKq8Y2C9yKxDozRQ6ioQtro
         RyQX4hDtq4zGBMOXZ8rz27VQvLB2LS5HAalREPhCdmHROI7veb3sADsbEEfUX+ptT7Av
         iRjvDk4RlO7vYjFGC24z0RuBkDjGDT9sFA3V/q+wGPWvAF6b1WJvswCOxvsIm4dID1XY
         0C2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749560754; x=1750165554;
        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=isW7H3XxNDJXOKkXKD+BdxkPdas0tvZOP6WE8bHGH6A=;
        b=T9lpwnK3Rl9zirpfe3/eLONaZWcszJZKupGh6h4Eshj57MGpkhYlvooqJREITRN2LI
         +CHOhIouIMxhKGSvndIewbIp2CykwxQ489tbgidEfPysp1wWP23OQHI4Kz4RjlBL6oAi
         DhJC+x1A2rN1Z0HVfaVYQ33v0sA/3mPJY4l+Q2CDWIH6PB/QX95jdsugS9eGp8FSH7B2
         y3EfBbSh/Zt3Ksfrvug+oO17UcIxae533WsJfzbaLhG5kYX+VGIrzI3NGqTnbMcP5r+z
         SAbaUnxu3pFDPQaRMD7KBu6q0he9fnQlpUTIVsjrLozF3XrC2HM35sshIBQ/lcdwQMGu
         g7Dw==
X-Gm-Message-State: AOJu0YwXeLLXJz2sXSgWY8kceDwW93NUIKdtc5BDZAgoDdCrhSSb86N5
	OKMXl0Bsh+fIJEWiyy6zEIf/hrH/x0sEKMSHfq5vc6nMECqPJRmb9lOIbpWhEA==
X-Gm-Gg: ASbGncsI/euk7tuhEvOiqFKZ43r7vsPl2TY6LI3B/RgGg6YLNr5lkURl1KYwBDkkKgf
	C7BznwatN+dbuZ0+9E22xAGI/+iNiZBxSIGVkkmISBHaHBmf2gwfrMd1Dyw0gXieIZmQ5eKv57u
	Eqcu3BG4cKvGHjWgE1yDEuDcZDNi4qa1gJ7z6I5f6Lna7jrbIsHKYp7p04fBKVnz291x06NkrbL
	0fYx0BO37/Hvr6gFBZLVfZH77RdXFIj+myczfNpdVR964ENKlZaJtReDmd42eX1D7w4214FcMIF
	7eqWUl9Kf6/XiXIKAun9ud2m3iwV+ox3u015Jtyyj4+J+7u1QbXXieoeodr35fH8CPzNq9qpNI1
	IhSiGH6/T7SCGW/H33LTjL/zL0r2B
X-Google-Smtp-Source: AGHT+IEBQT2r9op963zJAFCCDKLZ1on4ycT0PLvFnyWKzzTEm0ROTgDFTDJZYhRR0a9pcYdIZ+ajbQ==
X-Received: by 2002:a17:907:1c8e:b0:ad8:a41a:3cd2 with SMTP id a640c23a62f3a-ade1a9058e7mr1682029166b.16.1749560753609;
        Tue, 10 Jun 2025 06:05:53 -0700 (PDT)
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 12/17] xen/riscv: Implement p2m_free_entry() and related helpers
Date: Tue, 10 Jun 2025 15:05:27 +0200
Message-ID: <67148a7cceffdcbc5d8a51cd6af0a0c83e5b93bc.1749555949.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

This patch introduces a working implementation of p2m_free_entry() for RISC-V
based on ARM's implementation of p2m_free_entry(), enabling proper cleanup
of page table entries in the P2M (physical-to-machine) mapping.

Only few things are changed:
- Use p2m_force_flush_sync() instead of p2m_tlb_flush_sync() as latter
  isn't implemented on RISC-V.
- Introduce and use p2m_type_radix_get() to get a type of p2m entry as
  RISC-V's PTE doesn't have enough space to store all necessary types so
  a type is stored in a radix tree.

Key additions include:
- p2m_free_entry(): Recursively frees page table entries at all levels. It
  handles both regular and superpage mappings and ensures that TLB entries
  are flushed before freeing intermediate tables.
- p2m_put_page() and helpers:
  - p2m_put_4k_page(): Clears GFN from xenheap pages if applicable.
  - p2m_put_2m_superpage(): Releases foreign page references in a 2MB
    superpage.
  - p2m_type_radix_get(): Extracts the stored p2m_type from the radix tree
    using the PTE.
- p2m_free_page(): Returns a page either to the domain's freelist or to
  the domheap, depending on whether the domain is hardware-backed.

Defines XEN_PT_ENTRIES in asm/page.h to simplify loops over page table
entries.

Signed-off-by: Oleksii Kurochko 
---
Changes in V2:
 - New patch. It was a part of a big patch "xen/riscv: implement p2m mapping
   functionality" which was splitted to smaller.
 - s/p2m_is_superpage/p2me_is_superpage.
---
 xen/arch/riscv/include/asm/page.h |   1 +
 xen/arch/riscv/p2m.c              | 144 +++++++++++++++++++++++++++++-
 2 files changed, 142 insertions(+), 3 deletions(-)

diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h
index 1b8b145663..c67b9578c9 100644
--- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -22,6 +22,7 @@
 #define XEN_PT_LEVEL_SIZE(lvl)      (_AT(paddr_t, 1) << XEN_PT_LEVEL_SHIFT(lvl))
 #define XEN_PT_LEVEL_MAP_MASK(lvl)  (~(XEN_PT_LEVEL_SIZE(lvl) - 1))
 #define XEN_PT_LEVEL_MASK(lvl)      (VPN_MASK << XEN_PT_LEVEL_SHIFT(lvl))
+#define XEN_PT_ENTRIES              (_AT(unsigned int, 1) << PAGETABLE_ORDER)
 
 /*
  * PTE format:
diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
index 27499a86bb..6b11e87b22 100644
--- a/xen/arch/riscv/p2m.c
+++ b/xen/arch/riscv/p2m.c
@@ -345,11 +345,33 @@ static pte_t *p2m_get_root_pointer(struct p2m_domain *p2m, gfn_t gfn)
     return __map_domain_page(p2m->root + root_table_indx);
 }
 
+static p2m_type_t p2m_type_radix_get(struct p2m_domain *p2m, pte_t pte)
+{
+    void *ptr;
+    gfn_t gfn = mfn_to_gfn(p2m->domain, mfn_from_pte(pte));
+
+    ptr = radix_tree_lookup(&p2m->p2m_type, gfn_x(gfn));
+
+    if ( !ptr )
+        return p2m_invalid;
+
+    return radix_tree_ptr_to_int(ptr);
+}
+
+/*
+ * In the case of the P2M, the valid bit is used for other purpose. Use
+ * the type to check whether an entry is valid.
+ */
 static inline bool p2me_is_valid(struct p2m_domain *p2m, pte_t pte)
 {
-    panic("%s: isn't implemented for now\n", __func__);
+    return p2m_type_radix_get(p2m, pte) != p2m_invalid;
+}
 
-    return false;
+static inline bool p2me_is_superpage(struct p2m_domain *p2m, pte_t pte,
+                                    unsigned int level)
+{
+    return p2me_is_valid(p2m, pte) && (pte.pte & PTE_ACCESS_MASK) &&
+           (level > 0);
 }
 
 static inline void p2m_write_pte(pte_t *p, pte_t pte, bool clean_pte)
@@ -404,11 +426,127 @@ static int p2m_next_level(struct p2m_domain *p2m, bool alloc_tbl,
     return GUEST_TABLE_MAP_NONE;
 }
 
+static void p2m_put_foreign_page(struct page_info *pg)
+{
+    /*
+     * It's safe to do the put_page here because page_alloc will
+     * flush the TLBs if the page is reallocated before the end of
+     * this loop.
+     */
+    put_page(pg);
+}
+
+/* Put any references on the single 4K page referenced by mfn. */
+static void p2m_put_4k_page(mfn_t mfn, p2m_type_t type)
+{
+    /* TODO: Handle other p2m types */
+
+    /* Detect the xenheap page and mark the stored GFN as invalid. */
+    if ( p2m_is_ram(type) && is_xen_heap_mfn(mfn) )
+        page_set_xenheap_gfn(mfn_to_page(mfn), INVALID_GFN);
+}
+
+/* Put any references on the superpage referenced by mfn. */
+static void p2m_put_2m_superpage(mfn_t mfn, p2m_type_t type)
+{
+    struct page_info *pg;
+    unsigned int i;
+
+    ASSERT(mfn_valid(mfn));
+
+    pg = mfn_to_page(mfn);
+
+    for ( i = 0; i < XEN_PT_ENTRIES; i++, pg++ )
+        p2m_put_foreign_page(pg);
+}
+
+/* Put any references on the page referenced by pte. */
+static void p2m_put_page(struct p2m_domain *p2m, const pte_t pte,
+                         unsigned int level)
+{
+    mfn_t mfn = pte_get_mfn(pte);
+    p2m_type_t p2m_type = p2m_type_radix_get(p2m, pte);
+
+    ASSERT(p2me_is_valid(p2m, pte));
+
+    /*
+     * TODO: Currently we don't handle level 2 super-page, Xen is not
+     * preemptible and therefore some work is needed to handle such
+     * superpages, for which at some point Xen might end up freeing memory
+     * and therefore for such a big mapping it could end up in a very long
+     * operation.
+     */
+    if ( level == 1 )
+        return p2m_put_2m_superpage(mfn, p2m_type);
+    else if ( level == 0 )
+        return p2m_put_4k_page(mfn, p2m_type);
+}
+
+static void p2m_free_page(struct domain *d, struct page_info *pg)
+{
+    if ( is_hardware_domain(d) )
+        free_domheap_page(pg);
+    else
+    {
+        spin_lock(&d->arch.paging.lock);
+        page_list_add_tail(pg, &d->arch.paging.p2m_freelist);
+        spin_unlock(&d->arch.paging.lock);
+    }
+}
+
 /* Free pte sub-tree behind an entry */
 static void p2m_free_entry(struct p2m_domain *p2m,
                            pte_t entry, unsigned int level)
 {
-    panic("%s: hasn't been implemented yet\n", __func__);
+    unsigned int i;
+    pte_t *table;
+    mfn_t mfn;
+    struct page_info *pg;
+
+    /* Nothing to do if the entry is invalid. */
+    if ( !p2me_is_valid(p2m, entry) )
+        return;
+
+    if ( p2me_is_superpage(p2m, entry, level) || (level == 0) )
+    {
+#ifdef CONFIG_IOREQ_SERVER
+        /*
+         * If this gets called then either the entry was replaced by an entry
+         * with a different base (valid case) or the shattering of a superpage
+         * has failed (error case).
+         * So, at worst, the spurious mapcache invalidation might be sent.
+         */
+        if ( p2m_is_ram( p2m_type_radix_get(p2m, entry)) &&
+             domain_has_ioreq_server(p2m->domain) )
+            ioreq_request_mapcache_invalidate(p2m->domain);
+#endif
+
+        p2m_put_page(p2m, entry, level);
+
+        return;
+    }
+
+    table = map_domain_page(pte_get_mfn(entry));
+    for ( i = 0; i < XEN_PT_ENTRIES; i++ )
+        p2m_free_entry(p2m, *(table + i), level - 1);
+
+    unmap_domain_page(table);
+
+    /*
+     * Make sure all the references in the TLB have been removed before
+     * freing the intermediate page table.
+     * XXX: Should we defer the free of the page table to avoid the
+     * flush?
+     */
+    p2m_force_tlb_flush_sync(p2m);
+
+    mfn = pte_get_mfn(entry);
+    ASSERT(mfn_valid(mfn));
+
+    pg = mfn_to_page(mfn);
+
+    page_list_del(pg, &p2m->pages);
+    p2m_free_page(p2m->domain, pg);
 }
 
 /*
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 13:06:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 13:06:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010797.1389101 (Exim 4.92)
	(envelope-from )
	id 1uOyfw-0008Da-Ig; Tue, 10 Jun 2025 13:06:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010797.1389101; Tue, 10 Jun 2025 13:06: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 1uOyfv-0008CX-WA; Tue, 10 Jun 2025 13:05:59 +0000
Received: by outflank-mailman (input) for mailman id 1010797;
 Tue, 10 Jun 2025 13:05: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 1uOyft-0004Sm-Qc
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 13:05:57 +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 a4ee2047-45fb-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 15:05:55 +0200 (CEST)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-ade4679fba7so484721166b.2
 for ; Tue, 10 Jun 2025 06:05:55 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ade32c42770sm626465466b.41.2025.06.10.06.05.53
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 10 Jun 2025 06:05:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a4ee2047-45fb-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749560755; x=1750165555; darn=lists.xenproject.org;
        h=content-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=tkn+ztvbcliHnyvY4DdG5JO4oKukWMaE/1eHKVZZcwQ=;
        b=OEBIKFzvPJhORclc8ZoqwHQENJQ/lL5gZVFXsCrdCtxIYA329GGRHT1p7nGbKkBy7E
         EZ4w+QTGjLF+Es5WD1wrJpQ2WsFwMeFKhr2j5Om/NAJKW+ZInkgciIioVa154z2zzu51
         fd+7DKcZo1QaYXDsBRH6Uus0GZw/bXTbrdlS/dxlGJI4WiuswpHdXPDCtm8nRp0cHPdH
         xUqrNnt0pq2H/f7GE9Ph/eSehOmGI9CaELTijdsQy/FHeDbaSnXMbNxuGEAah4ZaPgRE
         jRUrSVZQjl42PmTQK025Y/hG8/plIZb8yDmSGfTv7JFISiEMbArcyBioJo1s3medrdG5
         J4aw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749560755; x=1750165555;
        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=tkn+ztvbcliHnyvY4DdG5JO4oKukWMaE/1eHKVZZcwQ=;
        b=Hv9uuiYjPFh+576Cl9e6xOFE555iJfLged3SUOAnYpwd/nF5p3JD6GfY0UqywbZ/nt
         S04jf0eADKUaDsP4F4qknGHZBosHk52dOLQG6zKwkDxPuGK6AWgKl+JXlD+UsYniY7Md
         EFfMzmWXFdCZDu488hq2M1jLJSo7VG4mKpoWs8M7q5PovlpriWi4cVz5oLqDxExQuu7b
         74MFvWOogfQOFQNW0d6er4Ab64TD1p+ECYhOsrd/FQaltPXFNH2S+oQ+RQGxnn8t7b28
         3j9pMFvSS921tGfMyg/r+kWPkZ+4d0ui9N2MrPW4uFYsb1a3dYqkyzCg2a8LsC9GPi4N
         3uVQ==
X-Gm-Message-State: AOJu0YzrlqA7Odzr5pXhZXzoPf5XoeIO1LtK1KtxcZ2AZWJNCJx0tTr+
	tnFaS/UWoEbNYhLi9DAskmY3gWzHK1vqqWsYRc00J/86u3AB3Ge7H9uHADjdBQ==
X-Gm-Gg: ASbGncuHf9KhMwg0TRJb8w2Gn0U+jZyS8KbuHtTiiu7ARSnVGIHRvEkhmPLJS96pfr4
	5w2fErqdjJ+nYXYRDmOjSz+OCFdksW3EZacmP3aKdgPNwYn89A8qNdwnEk8O5ZxN8B40CpwQ7TA
	4t6bsKuGYqZ8jPP2cwcS1nOvqR0S8KGQjksQu0PgJRph7Ru4jNwZS3KugG6Uqb1js6gY3OPWB53
	2Qoi4iQgZ533aIxkCBnuDD1V30rzVCHCmpW7On1FEByjZ8EzXpZgpNFyUMBFWttfsFf02YvPzSi
	rp06hkY2H9c4DSDlG1CORi3YwiSe+0/whhiJvQTxSUcKM5deKpAKgEV5rS3y6Qzm3QBBplr2nPJ
	VU4nfW3aXBt9L4uX7W4wwiWLW9n0f
X-Google-Smtp-Source: AGHT+IFOKSIAXyNkA2Zfv91wJ8RYYuzvX7isb+GzFl8frSbbvBaTOWNsZDjJc4chk24vwzsmEl4ICg==
X-Received: by 2002:a17:907:9721:b0:ad8:af1f:938d with SMTP id a640c23a62f3a-ade1ab1fa84mr1436480066b.37.1749560754641;
        Tue, 10 Jun 2025 06:05:54 -0700 (PDT)
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 13/17] xen/riscv: Implement p2m_entry_from_mfn() and support PBMT configuration
Date: Tue, 10 Jun 2025 15:05:28 +0200
Message-ID: <994ab3dd6822c4cd02a6a576041da115abeff6ed.1749555949.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

This patch adds the initial logic for constructing PTEs from MFNs in the RISC-V
p2m subsystem. It includes:
- Implementation of p2m_entry_from_mfn(): Generates a valid PTE using the
  given MFN, p2m_type_t, and p2m_access_t, including permission encoding and
  PBMT attribute setup.
- New helper p2m_set_permission(): Encodes access rights (r, w, x) into the
  PTE based on both p2m type and access permissions.
- p2m_type_radix_set(): Stores the p2m type in a radix tree keyed by the PTE
  for later retrieval.

PBMT type encoding support:
- Introduces an enum pbmt_type_t to represent the PBMT field values.
- Maps types like p2m_mmio_direct_dev to pbmt_io, others default to pbmt_pma.

Signed-off-by: Oleksii Kurochko 
---
Changes in V2:
 - New patch. It was a part of a big patch "xen/riscv: implement p2m mapping
   functionality" which was splitted to smaller.
---
 xen/arch/riscv/include/asm/page.h |   8 +++
 xen/arch/riscv/p2m.c              | 103 ++++++++++++++++++++++++++++--
 2 files changed, 107 insertions(+), 4 deletions(-)

diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h
index c67b9578c9..1d1054fa5c 100644
--- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -76,6 +76,14 @@
 #define PTE_SMALL       BIT(10, UL)
 #define PTE_POPULATE    BIT(11, UL)
 
+enum pbmt_type_t {
+    pbmt_pma,
+    pbmt_nc,
+    pbmt_io,
+    pbmt_rsvd,
+    pbmt_max,
+};
+
 #define PTE_ACCESS_MASK (PTE_READABLE | PTE_WRITABLE | PTE_EXECUTABLE)
 
 #define PTE_PBMT_MASK   (PTE_PBMT_NOCACHE | PTE_PBMT_IO)
diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
index 6b11e87b22..cba04acf38 100644
--- a/xen/arch/riscv/p2m.c
+++ b/xen/arch/riscv/p2m.c
@@ -345,6 +345,26 @@ static pte_t *p2m_get_root_pointer(struct p2m_domain *p2m, gfn_t gfn)
     return __map_domain_page(p2m->root + root_table_indx);
 }
 
+static int p2m_type_radix_set(struct p2m_domain *p2m, pte_t pte, p2m_type_t t)
+{
+    int rc;
+    gfn_t gfn = mfn_to_gfn(p2m->domain, mfn_from_pte(pte));
+
+    rc = radix_tree_insert(&p2m->p2m_type, gfn_x(gfn),
+                           radix_tree_int_to_ptr(t));
+    if ( rc == -EEXIST )
+    {
+        /* If a setting already exists, change it to the new one */
+        radix_tree_replace_slot(
+            radix_tree_lookup_slot(
+                &p2m->p2m_type, gfn_x(gfn)),
+            radix_tree_int_to_ptr(t));
+        rc = 0;
+    }
+
+    return rc;
+}
+
 static p2m_type_t p2m_type_radix_get(struct p2m_domain *p2m, pte_t pte)
 {
     void *ptr;
@@ -389,12 +409,87 @@ static inline void p2m_remove_pte(pte_t *p, bool clean_pte)
     p2m_write_pte(p, pte, clean_pte);
 }
 
-static pte_t p2m_entry_from_mfn(struct p2m_domain *p2m, mfn_t mfn,
-                                p2m_type_t t, p2m_access_t a)
+static void p2m_set_permission(pte_t *e, p2m_type_t t, p2m_access_t a)
 {
-    panic("%s: hasn't been implemented yet\n", __func__);
+    /* First apply type permissions */
+    switch ( t )
+    {
+    case p2m_ram_rw:
+        e->pte |= PTE_ACCESS_MASK;
+        break;
+
+    case p2m_mmio_direct_dev:
+        e->pte |= (PTE_READABLE | PTE_WRITABLE);
+        e->pte &= ~PTE_EXECUTABLE;
+        break;
+
+    case p2m_invalid:
+        e->pte &= ~PTE_ACCESS_MASK;
+        break;
+
+    default:
+        BUG();
+        break;
+    }
+
+    /* Then restrict with access permissions */
+    switch ( a )
+    {
+    case p2m_access_rwx:
+        break;
+    case p2m_access_wx:
+        e->pte &= ~PTE_READABLE;
+        break;
+    case p2m_access_rw:
+        e->pte &= ~PTE_EXECUTABLE;
+        break;
+    case p2m_access_w:
+        e->pte &= ~(PTE_READABLE | PTE_EXECUTABLE);
+        e->pte &= ~PTE_EXECUTABLE;
+        break;
+    case p2m_access_rx:
+    case p2m_access_rx2rw:
+        e->pte &= ~PTE_WRITABLE;
+        break;
+    case p2m_access_x:
+        e->pte &= ~(PTE_READABLE | PTE_WRITABLE);
+        break;
+    case p2m_access_r:
+        e->pte &= ~(PTE_WRITABLE | PTE_EXECUTABLE);
+        break;
+    case p2m_access_n:
+    case p2m_access_n2rwx:
+        e->pte &= ~PTE_ACCESS_MASK;
+        break;
+    default:
+        BUG();
+        break;
+    }
+}
+
+static pte_t p2m_entry_from_mfn(struct p2m_domain *p2m, mfn_t mfn, p2m_type_t t, p2m_access_t a)
+{
+    pte_t e = (pte_t) { 1 };
+
+    switch ( t )
+    {
+    case p2m_mmio_direct_dev:
+        e.pte |= PTE_PBMT_IO;
+        break;
+
+    default:
+        break;
+    }
+
+    p2m_set_permission(&e, t, a);
+
+    ASSERT(!(mfn_to_maddr(mfn) & ~PADDR_MASK));
+
+    pte_set_mfn(&e, mfn);
+
+    BUG_ON(p2m_type_radix_set(p2m, e, t));
 
-    return (pte_t) { .pte = 0 };
+    return e;
 }
 
 #define GUEST_TABLE_MAP_NONE 0
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 13:06:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 13:06:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010798.1389106 (Exim 4.92)
	(envelope-from )
	id 1uOyfx-0008Uj-MS; Tue, 10 Jun 2025 13:06:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010798.1389106; Tue, 10 Jun 2025 13:06: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 1uOyfx-0008S9-61; Tue, 10 Jun 2025 13:06:01 +0000
Received: by outflank-mailman (input) for mailman id 1010798;
 Tue, 10 Jun 2025 13:05: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 1uOyft-0004iH-Ue
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 13:05:57 +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 a5fb739d-45fb-11f0-a306-13f23c93f187;
 Tue, 10 Jun 2025 15:05:57 +0200 (CEST)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-60179d8e65fso5067639a12.0
 for ; Tue, 10 Jun 2025 06:05:57 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ade32c42770sm626465466b.41.2025.06.10.06.05.54
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 10 Jun 2025 06:05:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a5fb739d-45fb-11f0-a306-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749560757; x=1750165557; darn=lists.xenproject.org;
        h=content-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=lH1ZHh1K+bIKxqRJUfRmKzme+LOvg3rfA9LFTdq0giM=;
        b=URDUhvExcyXwBpvSfXo2fFeGw8yLDIyhxsYPT3iOQ3XL8BHuLeLZiUigj54B2SKEGd
         qcKRetIVCbYw5LF/+3oT7xf4hBe3t5jgxQ55tDElhXJI1w8mLd+Y3XBu1LtLnaRBeILJ
         6mUPXUUSXExw7bFGiP2OfmoteVmb3LNZzrmcubWGOddqkydsMTRbavwi1f36cQDwMaB9
         UWRW3ezjb7qlCK22EbPswmhcInvXw+YsNUspg7yFEUVRJKLf2M92UM3bChZBrFbZa9Ee
         UCTikrJSn/TepScasCE3xh5bFW181GxB5Eia0uomeShixEOq2XCBx3N9EraT+vgAUrZi
         ptNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749560757; x=1750165557;
        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=lH1ZHh1K+bIKxqRJUfRmKzme+LOvg3rfA9LFTdq0giM=;
        b=UkJZIK4jgLd1W0gjhDM7/aAAyyU1er48Pc1ualwcl8FL2UPho+rQW2LJfQjKtZ2B+A
         LjAq9ljE9TRHiyn7XNvNy05FKtYa0BBcWzJfXemto2riVwCDGz6Se+ElmXHl3WFZAdt5
         MFidSjiEGEA59rAek6t1X7iPRUE2ie1CyLfp5fR5CwY5CnSA3QTs9X1oxgO2bpL5iLns
         pBLKtfOMhaFFZitcWE6D0HtV4mnsOLVWlm4BRazIHopEAIAaVB0E2kTdNYk6YQy5tOyl
         zbZudC1W+2DtRApvZaGvbG3HMiyw92dY1pTLzl+kGA3u8LeHyRRmww6Q+2uc73rVYMHa
         I0AA==
X-Gm-Message-State: AOJu0Yxek2ZPd+q4j7InoHWASPgdTgJal443iLetrUv2hQS+z9fY9UJD
	1+yT+CLJJxx6oCgf+THgIdAb7t8opsmwOYqDIxdMEQ2FAbgrwYAYCYJkPaHd3g==
X-Gm-Gg: ASbGnctcdMEXUq4jYw9/4NK9Bo/FPuPjHKdP8RANoduMBnEEcskFrPs6IKCIm+nB6yM
	Rg4D4JQwMNguMEqwtjRXCDcAkbBjkxPsWqa6Zb231BCLjTp6C7DNtplwhfhoMYoyM84jqKZ/yxI
	GoMYZ8Wk+hGLHjI9b+TztPJvoGSh5MbqmoCr7aSIa7thk3xawXULVfns5rnCNzA/tFAsTqvRgGx
	fCQbo6HbEZOOGsJhHJlt6MGCBj6ZAUJQBLtp1vc3Cz0h/ToPvnjrfqauZq1uN7Vf82ompBMTHIA
	MQwwGjIO4VXehqk6K3p8KBDVO5Z6MNbu1ygy47hZu6/5b801wyED5KkxjMz6mrD5g5RDg1ptXnD
	ddP0VvSNV0i0Et2UI631jLFGnmthX
X-Google-Smtp-Source: AGHT+IE6DUsF2JRpbY+BbpzpDedxFbnMl0ETK6qltI4CDqfked9uZsa0lA6xeKZ2cn5AVxbQOlyzvg==
X-Received: by 2002:a17:907:7fa2:b0:ade:9fb:b07d with SMTP id a640c23a62f3a-ade7ac2cd8emr266695966b.4.1749560755700;
        Tue, 10 Jun 2025 06:05:55 -0700 (PDT)
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 14/17] xen/riscv: implement p2m_next_level()
Date: Tue, 10 Jun 2025 15:05:29 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Implement the p2m_next_level() function, which enables traversal and dynamic
allocation of intermediate levels (if necessary) in the RISC-V
p2m (physical-to-machine) page table hierarchy.

To support this, the following helpers are introduced:
- p2me_is_mapping(): Determines whether a PTE represents a valid mapping.
- page_to_p2m_table(): Constructs non-leaf PTEs pointing to next-level page
  tables with correct attributes.
- p2m_alloc_page(): Allocates page table pages, supporting both hardware and
  guest domains.
- p2m_create_table(): Allocates and initializes a new page table page and
  installs it into the hierarchy.

Signed-off-by: Oleksii Kurochko 
---
Changes in V2:
 - New patch. It was a part of a big patch "xen/riscv: implement p2m mapping
   functionality" which was splitted to smaller.
 - s/p2m_is_mapping/p2me_is_mapping.
---
 xen/arch/riscv/p2m.c | 103 ++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 101 insertions(+), 2 deletions(-)

diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
index cba04acf38..87dd636b80 100644
--- a/xen/arch/riscv/p2m.c
+++ b/xen/arch/riscv/p2m.c
@@ -387,6 +387,17 @@ static inline bool p2me_is_valid(struct p2m_domain *p2m, pte_t pte)
     return p2m_type_radix_get(p2m, pte) != p2m_invalid;
 }
 
+/*
+ * pte_is_* helpers are checking the valid bit set in the
+ * PTE but we have to check p2m_type instead (look at the comment above
+ * p2me_is_valid())
+ * Provide our own overlay to check the valid bit.
+ */
+static inline bool p2me_is_mapping(struct p2m_domain *p2m, pte_t pte)
+{
+    return p2me_is_valid(p2m, pte) && (pte.pte & PTE_ACCESS_MASK);
+}
+
 static inline bool p2me_is_superpage(struct p2m_domain *p2m, pte_t pte,
                                     unsigned int level)
 {
@@ -492,6 +503,70 @@ static pte_t p2m_entry_from_mfn(struct p2m_domain *p2m, mfn_t mfn, p2m_type_t t,
     return e;
 }
 
+/* Generate table entry with correct attributes. */
+static pte_t page_to_p2m_table(struct p2m_domain *p2m, struct page_info *page)
+{
+    /*
+     * Since this function generates a table entry, according to "Encoding
+     * of PTE R/W/X fields," the entry's r, w, and x fields must be set to 0
+     * to point to the next level of the page table.
+     * Therefore, to ensure that an entry is a page table entry,
+     * `p2m_access_n2rwx` is passed to `mfn_to_p2m_entry()` as the access value,
+     * which overrides whatever was passed as `p2m_type_t` and guarantees that
+     * the entry is a page table entry by setting r = w = x = 0.
+     */
+    return p2m_entry_from_mfn(p2m, page_to_mfn(page), p2m_ram_rw, p2m_access_n2rwx);
+}
+
+static struct page_info *p2m_alloc_page(struct domain *d)
+{
+    struct page_info *pg;
+
+    /*
+     * For hardware domain, there should be no limit in the number of pages that
+     * can be allocated, so that the kernel may take advantage of the extended
+     * regions. Hence, allocate p2m pages for hardware domains from heap.
+     */
+    if ( is_hardware_domain(d) )
+    {
+        pg = alloc_domheap_page(d, MEMF_no_owner);
+        if ( pg == NULL )
+            printk(XENLOG_G_ERR "Failed to allocate P2M pages for hwdom.\n");
+    }
+    else
+    {
+        spin_lock(&d->arch.paging.lock);
+        pg = page_list_remove_head(&d->arch.paging.p2m_freelist);
+        spin_unlock(&d->arch.paging.lock);
+    }
+
+    return pg;
+}
+
+/* Allocate a new page table page and hook it in via the given entry. */
+static int p2m_create_table(struct p2m_domain *p2m, pte_t *entry)
+{
+    struct page_info *page;
+    pte_t *p;
+
+    ASSERT(!p2me_is_valid(p2m, *entry));
+
+    page = p2m_alloc_page(p2m->domain);
+    if ( page == NULL )
+        return -ENOMEM;
+
+    page_list_add(page, &p2m->pages);
+
+    p = __map_domain_page(page);
+    clear_page(p);
+
+    unmap_domain_page(p);
+
+    p2m_write_pte(entry, page_to_p2m_table(p2m, page), p2m->clean_pte);
+
+    return 0;
+}
+
 #define GUEST_TABLE_MAP_NONE 0
 #define GUEST_TABLE_MAP_NOMEM 1
 #define GUEST_TABLE_SUPER_PAGE 2
@@ -516,9 +591,33 @@ static int p2m_next_level(struct p2m_domain *p2m, bool alloc_tbl,
                           unsigned int level, pte_t **table,
                           unsigned int offset)
 {
-    panic("%s: hasn't been implemented yet\n", __func__);
+    pte_t *entry;
+    int ret;
+    mfn_t mfn;
+
+    entry = *table + offset;
+
+    if ( !p2me_is_valid(p2m, *entry) )
+    {
+        if ( !alloc_tbl )
+            return GUEST_TABLE_MAP_NONE;
+
+        ret = p2m_create_table(p2m, entry);
+        if ( ret )
+            return GUEST_TABLE_MAP_NOMEM;
+    }
+
+    /* The function p2m_next_level() is never called at the last level */
+    ASSERT(level != 0);
+    if ( p2me_is_mapping(p2m, *entry) )
+        return GUEST_TABLE_SUPER_PAGE;
+
+    mfn = mfn_from_pte(*entry);
+
+    unmap_domain_page(*table);
+    *table = map_domain_page(mfn);
 
-    return GUEST_TABLE_MAP_NONE;
+    return GUEST_TABLE_NORMAL;
 }
 
 static void p2m_put_foreign_page(struct page_info *pg)
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 13:06:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 13:06:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010799.1389115 (Exim 4.92)
	(envelope-from )
	id 1uOyfy-0000BC-QH; Tue, 10 Jun 2025 13:06:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010799.1389115; Tue, 10 Jun 2025 13:06: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 1uOyfx-00007P-Qw; Tue, 10 Jun 2025 13:06:01 +0000
Received: by outflank-mailman (input) for mailman id 1010799;
 Tue, 10 Jun 2025 13:05: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 1uOyfu-0004iH-Ue
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 13:05:58 +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 a644dc88-45fb-11f0-a306-13f23c93f187;
 Tue, 10 Jun 2025 15:05:57 +0200 (CEST)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-ad89c32a7b5so876016066b.2
 for ; Tue, 10 Jun 2025 06:05:57 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ade32c42770sm626465466b.41.2025.06.10.06.05.56
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 10 Jun 2025 06:05:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a644dc88-45fb-11f0-a306-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749560757; x=1750165557; darn=lists.xenproject.org;
        h=content-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=XAO1HvfCg38B6ugq8JOzW8h4WZl3XzGZna0ImJ4d1TY=;
        b=fBxc0i1wS9brnVIhIAvDXazFzIUXzfh93Nd2CBGTZ/5zDbtKF3QdjtraieLH4LmdqV
         4dA0AoP2U5kXuP+Tz6fterU5QOiAmZf+L/jwxCZ7jC0IzzFFJy8vfCofS2qvejLANteK
         RA9DU7/zz8tZquuy3fgMZcR2AO5zUSbmJ0a95Ye3SwCLFREp9ltUHyXKwcRQdlzOIuSy
         dLQCCP0a68Y/FKGBHsq7rSCfu8RKx/LpE136mhEm4slMHp5Qb3Um8sy20dj1PZnQNqaZ
         rhP59g2eRS00M1/ewawTFFzU8C/MdcTjo4BMbOUajs91XqVFcPkqEsH8eOtlIZUG0ogi
         Rcwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749560757; x=1750165557;
        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=XAO1HvfCg38B6ugq8JOzW8h4WZl3XzGZna0ImJ4d1TY=;
        b=qQbTqYUskgMsZ+kcMPacmSALjPf4hQwfNmA9QS3X15Tt9i9gu6l5CaDYbP/dHGshWH
         Z+PDHnx2Ig5OQz9nmaAFgfppgA1fWLNEAtR6Ntcle81Bb3tYS/MNUv41WcAMzK1xl/Wi
         1w6r5uZkOErRjzG/FDWzJiKsy99jjkNEUb6kgd0U+X9W7CG52udZFRuD49wizEebttPM
         2wYpNaif5l7o7+n/IZowc4v0OkDLo+FFUr+VhicI6ZJJkYEpjCooln6Q4stzxQxyVtUY
         TDa+W694Zaerdl4gEtqtVG6dZVr/MSQ5/hAoRLISYz2huZqxtElmlkOPfasPyH2AZXQC
         rkuQ==
X-Gm-Message-State: AOJu0YzxVmUnM4OVdu3ks/OKwmvi1xuRS9TjY+Te9iOaH0h1pt8+m3Zf
	Emn9LLCzv+hEGVFaRmZ7laY4pq3T48NdWoxR2sur9yARHyPqdOCeTkHODMxzsg==
X-Gm-Gg: ASbGnctVScqG3Eh8ToxlRphiWuq8vq4tRMM9zzaeFTUnLwVr1FVgSNQ0nZ66grqnLHH
	B3LQxaOho6XYBJHZ2PSEpMQ1nIPT38jMHWVoftlOlA38ggXkX3JD7cGH7naN2s1x3SJpTkTIo/c
	nC+MfdrPs+6RmSnqNGaOEiv5kgo91i4/Q0znDX+SDeHYSUdA1+MdRC8VJuDsbHv4BZPKjgxX3ni
	VUdfisBmKNnMpnPOFPVwer/F9XZVF0DSOJaT+gpDpWK5h3S8DUlJCAsKhqjpFG9+p1r6e8sZJun
	QtcJtNXESSBZEauhUOUlKOY1bQgfY6M4UPpFIM8sYCk886U/eNLGv9JYS7M/bC0PwZkkD2KvazD
	zFJdwRnNsuD1TWhMAiQtVmnR2rey6Q3Wv39Vch+c=
X-Google-Smtp-Source: AGHT+IH4jCCiEUNIHRyARWXyMcMwfkq8+JiAqUWpBRX5B6mdVZuFz6Pi1kIjhQ7UNLLrFtiggx+b2Q==
X-Received: by 2002:a17:906:fe08:b0:ade:4304:6b7d with SMTP id a640c23a62f3a-ade7acfab2bmr229932666b.49.1749560756791;
        Tue, 10 Jun 2025 06:05:56 -0700 (PDT)
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 15/17] xen/riscv: Implement superpage splitting for p2m mappings
Date: Tue, 10 Jun 2025 15:05:30 +0200
Message-ID: <7cdd3272f2eba32dfa00be4fd72da6921eac243d.1749555949.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add support for down large memory mappings ("superpages") in the RISC-V
p2m mapping so that smaller, more precise mappings ("finer-grained entries")
can be inserted into lower levels of the page table hierarchy.

To implement that the following is done:
- Introduce p2m_split_superpage(): Recursively shatters a superpage into
  smaller page table entries down to the target level, preserving original
  permissions and attributes.
- __p2m_set_entry() updated to invoke superpage splitting when inserting
  entries at lower levels within a superpage-mapped region.

This implementation is based on the ARM code, with modifications to the part
that follows the BBM (break-before-make) approach. Unlike ARM, RISC-V does
not require BBM, so there is no need to invalidate the PTE and flush the
TLB before updating it with the newly created, split page table.
Additionally, the page table walk logic has been adjusted, as ARM uses the
opposite walk order compared to RISC-V.

Signed-off-by: Oleksii Kurochko 
---
Changes in V2:
 - New patch. It was a part of a big patch "xen/riscv: implement p2m mapping
   functionality" which was splitted to smaller.
 - Update the commit above the cycle which creates new page table as
   RISC-V travserse page tables in an opposite to ARM order.
 - RISC-V doesn't require BBM so there is no needed for invalidating
   and TLB flushing before updating PTE.
---
 xen/arch/riscv/p2m.c | 102 ++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 101 insertions(+), 1 deletion(-)

diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
index 87dd636b80..79c4473f1f 100644
--- a/xen/arch/riscv/p2m.c
+++ b/xen/arch/riscv/p2m.c
@@ -743,6 +743,77 @@ static void p2m_free_entry(struct p2m_domain *p2m,
     p2m_free_page(p2m->domain, pg);
 }
 
+static bool p2m_split_superpage(struct p2m_domain *p2m, pte_t *entry,
+                                unsigned int level, unsigned int target,
+                                const unsigned int *offsets)
+{
+    struct page_info *page;
+    unsigned int i;
+    pte_t pte, *table;
+    bool rv = true;
+
+    /* Convenience aliases */
+    mfn_t mfn = pte_get_mfn(*entry);
+    unsigned int next_level = level - 1;
+    unsigned int level_order = XEN_PT_LEVEL_ORDER(next_level);
+
+    /*
+     * This should only be called with target != level and the entry is
+     * a superpage.
+     */
+    ASSERT(level > target);
+    ASSERT(p2me_is_superpage(p2m, *entry, level));
+
+    page = p2m_alloc_page(p2m->domain);
+    if ( !page )
+        return false;
+
+    page_list_add(page, &p2m->pages);
+    table = __map_domain_page(page);
+
+    /*
+     * We are either splitting a second level 1G page into 512 first level
+     * 2M pages, or a first level 2M page into 512 zero level 4K pages.
+     */
+    for ( i = 0; i < XEN_PT_ENTRIES; i++ )
+    {
+        pte_t *new_entry = table + i;
+
+        /*
+         * Use the content of the superpage entry and override
+         * the necessary fields. So the correct permission are kept.
+         */
+        pte = *entry;
+        pte_set_mfn(&pte, mfn_add(mfn, i << level_order));
+
+        write_pte(new_entry, pte);
+    }
+
+    /*
+     * Shatter superpage in the page to the level we want to make the
+     * changes.
+     * This is done outside the loop to avoid checking the offset to
+     * know whether the entry should be shattered for every entry.
+     */
+    if ( next_level != target )
+        rv = p2m_split_superpage(p2m, table + offsets[next_level],
+                                 level - 1, target, offsets);
+
+    /* TODO: why it is necessary to have clean here? Not somewhere in the caller */
+    if ( p2m->clean_pte )
+        clean_dcache_va_range(table, PAGE_SIZE);
+
+    unmap_domain_page(table);
+
+    /*
+     * Even if we failed, we should install the newly allocated PTE
+     * entry. The caller will be in charge to free the sub-tree.
+     */
+    p2m_write_pte(entry, page_to_p2m_table(p2m, page), p2m->clean_pte);
+
+    return rv;
+}
+
 /*
  * Insert an entry in the p2m. This should be called with a mapping
  * equal to a page/superpage.
@@ -806,7 +877,36 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
      */
     if ( level > target )
     {
-        panic("Shattering isn't implemented\n");
+        /* We need to split the original page. */
+        pte_t split_pte = *entry;
+
+        ASSERT(p2me_is_superpage(p2m, *entry, level));
+
+        if ( !p2m_split_superpage(p2m, &split_pte, level, target, offsets) )
+        {
+            /* Free the allocated sub-tree */
+            p2m_free_entry(p2m, split_pte, level);
+
+            rc = -ENOMEM;
+            goto out;
+        }
+
+        p2m_write_pte(entry, split_pte, p2m->clean_pte);
+
+        /* Then move to the level we want to make real changes */
+        for ( ; level < target; level++ )
+        {
+            rc = p2m_next_level(p2m, true, level, &table, offsets[level]);
+
+            /*
+             * The entry should be found and either be a table
+             * or a superpage if level 0 is not targeted
+             */
+            ASSERT(rc == GUEST_TABLE_NORMAL ||
+                   (rc == GUEST_TABLE_SUPER_PAGE && target > 0));
+        }
+
+        entry = table + offsets[level];
     }
 
     /*
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 13:12:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 13:12:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010862.1389139 (Exim 4.92)
	(envelope-from )
	id 1uOym6-0006EU-BO; Tue, 10 Jun 2025 13:12:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010862.1389139; Tue, 10 Jun 2025 13:12: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 1uOym6-0006EN-88; Tue, 10 Jun 2025 13:12:22 +0000
Received: by outflank-mailman (input) for mailman id 1010862;
 Tue, 10 Jun 2025 13:12: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 1uOyfw-0004iH-VI
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 13:06:00 +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 a76f8c09-45fb-11f0-a306-13f23c93f187;
 Tue, 10 Jun 2025 15:05:59 +0200 (CEST)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-ad56cbc7b07so794163866b.0
 for ; Tue, 10 Jun 2025 06:05:59 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ade32c42770sm626465466b.41.2025.06.10.06.05.56
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 10 Jun 2025 06:05:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a76f8c09-45fb-11f0-a306-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749560759; x=1750165559; darn=lists.xenproject.org;
        h=content-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=oLkVEHfi1jrO45zgqffaLAKyuwJWGqpdSuo4c300uoo=;
        b=a4WV+ObV8bS++SVIR1CCtOtfhlq9ARhXV62KFMUFzqhWqfVQJYFVq0zAdqr/wkijhJ
         JoCBo9nOmL9hm5R84LYsp/v+BTWkUiNmGcuLNJqxD+ad6LWfVC4eSbjzAxmvyRegsN4g
         WyN6jWZea9EAZic1TBbnu9N4Ayqz/TLpeOywjFtXGW8CcA86qNI6f+rrMzvVp718F26A
         I4urpZDz5DfcDZMTJGdkSikMa8Gs6ltYr6i+xAc/fuaJnNYu7Cr2nAOnYyTsXdUjnUGM
         JPH9/KPF3TNQ9CN0BXYprFnn5v8hN1JdeDKk7t726PSjsBh86cc/CyEYSbi7uYDebM/a
         DAaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749560759; x=1750165559;
        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=oLkVEHfi1jrO45zgqffaLAKyuwJWGqpdSuo4c300uoo=;
        b=WR0VGNwOSoK+bwqEKX7tBLZKa/pUpJzcTa/cqJrPhj/oD08G8gQr6cVJG/ZSTNC8CW
         n/myCJmtKnf8IaFVzDm3tHYnWEDXdKcVP4/Zw4jdF8x4ecTvqO0XKaAsdS+qdzSABbpC
         zMTX5swdt9Y5icgznaZBzst4/ts+r3WfodfIGLAmfj0g+qyY4ckygr6K7/BMVq+UcAZv
         GgdS11KWcil9Eiw4CZKy5WTm+9XUJr0epRFIe09PW5F+GNIrdQueA3yuB6/BqUps+3cx
         dWCvVfdvMzZ6RVObkmj6nLJayRPHzyDfXNMRUFdUO9BZtNPOxUIcAiEbwujVTpN6X7bC
         Ksng==
X-Gm-Message-State: AOJu0Yzrh5VbQrYtagzXM0j0NapFOIAbON71moIOaS4TdUAoJ5/kkUf+
	BqvEkN5RkBPtQgFf42cS6IGQzNUr4JiQF6xy+I+wLQYUlYVT1ULyjJ7ZoZ9Quw==
X-Gm-Gg: ASbGncuqKt5GFAZz7hMhwblM8SJRfMskay+qkLHzcPrRcSo4CqrggEgTxpBXeMfw7HL
	hfIi6OHeq9eKgUd5q2x61FBBh7kvcR6RDbNclzlMZOSLxWfcizvQ1hJuuzL4W/Ax89U2EVXOOM6
	6vEMGEuBkbWbeCiPEsllWeG8eSAaXZq69jLFguD1v+bUrQK8r7roXKzKy/MWaZpHxfYL1b8/nhy
	PaZ+IeOgjKtn15xDYOihCBXttW+AuVqeKPNo3GsJSqvgEuy5TodVppk+mgfgcjWz7HttJLqrJNz
	Ly99BLLgnoaWctDiNN5oosIYQH5o7Iy9hjFMjeJ8BDDGIAPePGM+q98yaBVsPTVmM7XNFSLbitq
	lYZ+cnV/W7mw1lb6GsLiWc5NznaP5VJPqbRoCByo=
X-Google-Smtp-Source: AGHT+IEBaIt1MD6aKhJxCYZ43RfPWThnVB8CtvWfUM39Lk0b4i2B38h1vrfVFizytmU7ODufwOjrjQ==
X-Received: by 2002:a17:907:3f23:b0:ad8:9c97:c2fa with SMTP id a640c23a62f3a-ade1a8da8f7mr1694147666b.4.1749560757808;
        Tue, 10 Jun 2025 06:05:57 -0700 (PDT)
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 16/17] xen/riscv: implement mfn_valid() and page reference, ownership handling helpers
Date: Tue, 10 Jun 2025 15:05:31 +0200
Message-ID: <50159d05e75c14ca62ee6cab5a4d30645981827a.1749555949.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Implement the mfn_valid() macro to verify whether a given MFN is valid by
checking that it falls within the range [start_page, max_page).
These bounds are initialized based on the start and end addresses of RAM.

As part of this patch, start_page is introduced and initialized with the
PFN of the first RAM page.

Also, after providing a non-stub implementation of the mfn_valid() macro,
the following compilation errors started to occur:
  riscv64-linux-gnu-ld: prelink.o: in function `__next_node':
  /build/xen/./include/xen/nodemask.h:202: undefined reference to `page_is_ram_type'
  riscv64-linux-gnu-ld: prelink.o: in function `get_free_buddy':
  /build/xen/common/page_alloc.c:881: undefined reference to `page_is_ram_type'
  riscv64-linux-gnu-ld: prelink.o: in function `alloc_heap_pages':
  /build/xen/common/page_alloc.c:1043: undefined reference to `page_get_owner_and_reference'
  riscv64-linux-gnu-ld: /build/xen/common/page_alloc.c:1098: undefined reference to `page_is_ram_type'
  riscv64-linux-gnu-ld: prelink.o: in function `ns16550_interrupt':
  /build/xen/drivers/char/ns16550.c:205: undefined reference to `get_page'
  riscv64-linux-gnu-ld: ./.xen-syms.0: hidden symbol `page_get_owner_and_reference' isn't defined
  riscv64-linux-gnu-ld: final link failed: bad value
  make[2]: *** [arch/riscv/Makefile:35: xen-syms] Error 1
To resolve these errors, the following functions have also been introduced,
based on their Arm counterparts:
- page_get_owner_and_reference() and its variant to safely acquire a
  reference to a page and retrieve its owner.
- put_page() and put_page_nr() to release page references and free the page
  when the count drops to zero.
  For put_page_nr(), code related to static memory configuration is wrapped
  with CONFIG_STATIC_MEMORY, as this configuration has not yet been moved to
  common code. Therefore, PGC_static and free_domstatic_page() are not
  introduced for RISC-V. However, since this configuration could be useful
  in the future, the relevant code is retained and conditionally compiled.
- A stub for page_is_ram_type() that currently always returns 0 and asserts
  unreachable, as RAM type checking is not yet implemented.

Signed-off-by: Oleksii Kurochko 
---
Changes in V2:
 - New patch.
---
 xen/arch/riscv/include/asm/mm.h |  9 ++-
 xen/arch/riscv/mm.c             | 97 +++++++++++++++++++++++++++++++--
 2 files changed, 99 insertions(+), 7 deletions(-)

diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
index 41bf9002d7..bd8511e5f9 100644
--- a/xen/arch/riscv/include/asm/mm.h
+++ b/xen/arch/riscv/include/asm/mm.h
@@ -5,6 +5,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -288,8 +289,12 @@ static inline bool arch_mfns_in_directmap(unsigned long mfn, unsigned long nr)
 #define page_get_owner(p)    (p)->v.inuse.domain
 #define page_set_owner(p, d) ((p)->v.inuse.domain = (d))
 
-/* TODO: implement */
-#define mfn_valid(mfn) ({ (void)(mfn); 0; })
+extern unsigned long start_page;
+
+#define mfn_valid(mfn) ({                                   \
+    unsigned long mfn__ = mfn_x(mfn);                       \
+    likely((mfn__ >= start_page) && (mfn__ < max_page));    \
+})
 
 #define domain_set_alloc_bitsize(d) ((void)(d))
 #define domain_clamp_alloc_bitsize(d, b) ((void)(d), (b))
diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
index 4047d67c0e..c88908d4f0 100644
--- a/xen/arch/riscv/mm.c
+++ b/xen/arch/riscv/mm.c
@@ -361,11 +361,6 @@ unsigned long __init calc_phys_offset(void)
     return phys_offset;
 }
 
-void put_page(struct page_info *page)
-{
-    BUG_ON("unimplemented");
-}
-
 void arch_dump_shared_mem_info(void)
 {
     BUG_ON("unimplemented");
@@ -525,6 +520,8 @@ static void __init setup_directmap_mappings(unsigned long base_mfn,
 #error setup_{directmap,frametable}_mapping() should be implemented for RV_32
 #endif
 
+unsigned long __read_mostly start_page;
+
 /*
  * Setup memory management
  *
@@ -577,6 +574,8 @@ void __init setup_mm(void)
     }
 
     setup_frametable_mappings(ram_start, ram_end);
+
+    start_page = PFN_DOWN(ram_start);
     max_page = PFN_DOWN(ram_end);
 }
 
@@ -613,3 +612,91 @@ void __iomem *ioremap(paddr_t pa, size_t len)
 {
     return ioremap_attr(pa, len, PAGE_HYPERVISOR_NOCACHE);
 }
+
+int page_is_ram_type(unsigned long mfn, unsigned long mem_type)
+{
+    ASSERT_UNREACHABLE();
+
+    return 0;
+}
+
+static struct domain *page_get_owner_and_nr_reference(struct page_info *page,
+                                                      unsigned long nr)
+{
+    unsigned long x, y = page->count_info;
+    struct domain *owner;
+
+    /* Restrict nr to avoid "double" overflow */
+    if ( nr >= PGC_count_mask )
+    {
+        ASSERT_UNREACHABLE();
+        return NULL;
+    }
+
+    do {
+        x = y;
+        /*
+         * Count ==  0: Page is not allocated, so we cannot take a reference.
+         * Count == -1: Reference count would wrap, which is invalid.
+         */
+        if ( unlikely(((x + nr) & PGC_count_mask) <= nr) )
+            return NULL;
+    }
+    while ( (y = cmpxchg(&page->count_info, x, x + nr)) != x );
+
+    owner = page_get_owner(page);
+    ASSERT(owner);
+
+    return owner;
+}
+
+struct domain *page_get_owner_and_reference(struct page_info *page)
+{
+    return page_get_owner_and_nr_reference(page, 1);
+}
+
+void put_page_nr(struct page_info *page, unsigned long nr)
+{
+    unsigned long nx, x, y = page->count_info;
+
+    do {
+        ASSERT((y & PGC_count_mask) >= nr);
+        x  = y;
+        nx = x - nr;
+    }
+    while ( unlikely((y = cmpxchg(&page->count_info, x, nx)) != x) );
+
+    if ( unlikely((nx & PGC_count_mask) == 0) )
+    {
+#ifdef CONFIG_STATIC_MEMORY
+        if ( unlikely(nx & PGC_static) )
+            free_domstatic_page(page);
+        else
+#endif
+            free_domheap_page(page);
+    }
+}
+
+void put_page(struct page_info *page)
+{
+    put_page_nr(page, 1);
+}
+
+bool get_page_nr(struct page_info *page, const struct domain *domain,
+                 unsigned long nr)
+{
+    const struct domain *owner = page_get_owner_and_nr_reference(page, nr);
+
+    if ( likely(owner == domain) )
+        return true;
+
+    if ( owner != NULL )
+        put_page_nr(page, nr);
+
+    return false;
+}
+
+bool get_page(struct page_info *page, const struct domain *domain)
+{
+    return get_page_nr(page, domain, 1);
+}
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 13:13:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 13:13:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010880.1389148 (Exim 4.92)
	(envelope-from )
	id 1uOyms-00071H-M1; Tue, 10 Jun 2025 13:13:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010880.1389148; Tue, 10 Jun 2025 13:13: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 1uOyms-00071A-JR; Tue, 10 Jun 2025 13:13:10 +0000
Received: by outflank-mailman (input) for mailman id 1010880;
 Tue, 10 Jun 2025 13:13: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 1uOymr-0006n8-MQ
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 13:13:09 +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 a73b390c-45fc-11f0-a306-13f23c93f187;
 Tue, 10 Jun 2025 15:13:09 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by AS2PR03MB9744.eurprd03.prod.outlook.com
 (2603:10a6:20b:60b::11) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8813.26; Tue, 10 Jun
 2025 13:13:05 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971%6]) with mapi id 15.20.8835.018; Tue, 10 Jun 2025
 13:13: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: a73b390c-45fc-11f0-a306-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=NG44DGHGS5XCnrTHbHR1U9mlPa000Q+50Q20HFgKUqb3F5VTfUBzWBPkV3ynb1thr4QVGZxA1gwoiErZlwiJ6ia5ttXdWczg012PzJsuannZD5wzAEfjknKYAbNYLovEmLcoeiUfX6O+1MNMkxcwrdVqjC5Q8f2ss2TOKXxMCCk2EcpXeHUNkSQrgwcKUVewnlqRjBXG1EVSajoykmukWhHESpv7eU1pEm/CwTheoYt/XJX0T12MeZo/Btk0jgEp5fDQosHbyCPM96s187rCKlN1cJ1ObLUa8jQHVGmDAJc9tL6/jBjBFxF8doIsNmEnNcfcme5E++AO+VhKXIcvXA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=YvbcEpNN7bl73+cW3vAAIqmqz4YiOIQio4FxnJZ4xQE=;
 b=c+3JkaZq0mfRw9HRWsnlwiP70mU29by2+DQOOcfBkUbBgEvUoYFFGMf6wS/chzLS79F9Iq5lz935XZaoM69c0K18MC2JBYrpMHl7MuUkNfztSjVS2SQNujegUBTYfh9nVWAEjFp9SU0BN9y7XD5BtIHz5HZ3Fs95ltEp6CqHhP3hrcxffDjhxOylHnOyIJOxl9kp8pWTKFVpxqXvJemrd+8GCpqeitQ6PTL6zTS7G0JGPvoXHkXucQnmR75tY3raSbBcIZQqH0eLbG9aLiTrGK+J9My7y9786cwmjCWQKsP/NuN8xJq7rt/eE5glTawLsNcEq0ccUlNVkF8+ySgCpA==
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=YvbcEpNN7bl73+cW3vAAIqmqz4YiOIQio4FxnJZ4xQE=;
 b=fuiv4Ltm9zv7bPmS4itHDrnkAa1oubQAI61Ppz6crFFcjKiLwOZ84BPQupewoHQs2jsyX1mjGsv7FDwQI3Q2ykL/SfqERpizBa/jh/8/OiItjI4cAffdREzJQbuQuis6G1bYfM8WUTmtOc5CpEfHe0uOgAJ3GRoQmuhwrBO4RQgtjUvWjkXteOh/fJay6HFCbA9gLGoaWiFZ9wQtE94+S8rsrdlquzk/M4XUM8mlv9BU8YIk9CsB6JQiPjeWCJF96umhJi82k05EoK5efoOIQWBUlrrPORybhObRpmaPOpW/zFhw5CV1gjawy8cLBrqVbFqpw0gwiZowIXKqRLXOqw==
From: Mykyta Poturai 
To: Julien Grall , Demi Marie Obenour ,
	"xen-devel@lists.xenproject.org" 
CC: Bertrand Marquis , Stefano Stabellini
	, Michal Orzel , Volodymyr
 Babchuk , Stewart Hildebrand
	
Subject: Re: [PATCH v11 4/7] xen/arm: smmuv3: Add PCI devices support for
 SMMUv3
Thread-Topic: [PATCH v11 4/7] xen/arm: smmuv3: Add PCI devices support for
 SMMUv3
Thread-Index: AQHbz7Cb+Z/yNKbLOEOjir1VN7bH5LPo3kyAgAogQYCACXTdAA==
Date: Tue, 10 Jun 2025 13:13:05 +0000
Message-ID: 
References: 
 <71741747bdc0cfcacbe86e66ddd6239ea2f5a3af.1748422217.git.mykyta_poturai@epam.com>
 <9bfc305b-602e-4c96-bd7a-763075e506d7@gmail.com>
 <56e44ec8-c9c0-4d58-98f3-730cc1c1bb86@xen.org>
In-Reply-To: <56e44ec8-c9c0-4d58-98f3-730cc1c1bb86@xen.org>
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_|AS2PR03MB9744:EE_
x-ms-office365-filtering-correlation-id: 5cf19e65-024d-4727-16cd-08dda8208981
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|1800799024|376014|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?OXBZZ0ZyY05SbTlPVmtmcFZCWHc4ZXlpZFZnbzNYRml4YUkwUFJ2VjlRUlZ6?=
 =?utf-8?B?OGV1bFNycGgvbERLeXhYOHdBN2xkSHlCcUVWYVZMaWkzMEdobzMyL0twTDJz?=
 =?utf-8?B?VmJQS3E2WTZtelJuUWhES28xUkFMUXRmZmNoV3FpRng5bFBRSjlFUStUampk?=
 =?utf-8?B?c2MrdUR4ckhZa0lLaXArNmY2WmZmbFJUMWFhbmxwb3BkSXVXaFgxcmxQazAw?=
 =?utf-8?B?cUE4RHFnY09wZ29QbEtZLytacDBSQi9pc0FvT09ZaEFZVmJISFd5ak5TZmpx?=
 =?utf-8?B?dE5XNFZaZWlFNFJoTGFoMXFndnRsR3crajBTZThtRGZTdXA2ZFF6THNwS1U4?=
 =?utf-8?B?N29DSWJLNXVSOWxLLzU0QjNqQklRcG9VZGh2Vm91RnpLYVhOQTFBOGdsbG1C?=
 =?utf-8?B?Qm01cm82Z2djZ1kvbzdIUXJpV2NMZXlGK0JLZzFyOUFPSEJKL2cxTTN0eWlz?=
 =?utf-8?B?eFdEQ1VrK0FNUU5WRjYwdzIvemJQSExlRHlFMXhVNUFhQjRZVWM5d2IxdkhU?=
 =?utf-8?B?WkVpNzBVWWNLeVRQNnIxNStnUmFYY2RHcWZ6RHJGVnRjNkFRbkZCQ2ppQ05w?=
 =?utf-8?B?OVowZ0ErWGw4NUx0dFMyN3dEM01Ld1pQU2VDK0lrcmw0NkpBaUoxTm1ENkgr?=
 =?utf-8?B?aWx4U3A1OHdRaCtBYy9aMGx0Y2tQOU5mOWxMbWhjYkpPMnJNZUNvQzlBOHE5?=
 =?utf-8?B?alJyd284MnMvSU5LMmxSc25NaXhrcFA1WEpBcFluRHBqaU1pN0tnZDdWTG1i?=
 =?utf-8?B?am1OZWdNSzZvL2JOQ1BXeTNBK200M0dsV0JkamIyYjV3b0szR3hNTUdETjBV?=
 =?utf-8?B?TEtjbmkyUXg4OXRwd1JRc1h5ZHFhNHgrM2ErNWw4VTZPTE1jNytGY0RWSGhN?=
 =?utf-8?B?bVdjdlpvMjE0Q0dHa2FkWXgra0REQ3FraE93cHNBVW9jV0hGcUtKbDQxdDJR?=
 =?utf-8?B?Z3NhUWhZbnYvS3hJZVYwOEtwZTRMVTdnV0dIU1g3MjBtWmc5bVI3YWcreEww?=
 =?utf-8?B?TmowVW5LY05qS2RRRzE4Qm5mcjdRS2xOdSswanQxSFMwaHNDeGt5TEF1dEgw?=
 =?utf-8?B?V3RrSlY4TzJ4ZkgxNFdwMWtlend1R0d6dytFOFRsZ1BpWThPRERJTVNFUzdh?=
 =?utf-8?B?TStjVytaOWNUL3lGaUJFWHVyMFYxSFJMR1ZKR0lQOWZ3aGpueWxGNjJvNmxH?=
 =?utf-8?B?dTFwY3lxVkg4VXBHcU8vNGNqSVdLNlNvWHU1UEVkRDNlZUI1bFIwRTJmZEpE?=
 =?utf-8?B?eDdJSnc5M21lbXdjY1VIRUhQMnVISEk0Vm5RLzRjWlUwMDRYUVJIT09PNFdU?=
 =?utf-8?B?Um9UaldjYW5IWkN1cHdXY3RPbHJnUEpBL3RWQkkyU0FkanBqOE9DRmpxU01B?=
 =?utf-8?B?czJBZWVyaHlGYkxJYnlqQ0pqZ0Q5SE04NVQvblJzZTc3bHNxaGZhQjhtQ1ky?=
 =?utf-8?B?dStub0tIT1ZUcDNwRGo1WTBQb3J5YWZyeEdNRUNTcjgycDRZOFlyYVpHQWZa?=
 =?utf-8?B?NVBLWFhRUks3K3d4NzR4cWdyaUJGRUdzUlJ1RXFHSlVJMWNXLytJMWhGNWVv?=
 =?utf-8?B?T2taZ3EzaGtDR2VNZ3FhaGQ1NUNSdmZCU3I4VWtuaDdzd1JIUFB3V0dJM0Y1?=
 =?utf-8?B?clhCRWFNSGhKTjdlMmZseVBXMXVRQXhWY2ZzbmV6alFCaGtWbDFPVEZGYk05?=
 =?utf-8?B?QTl3VFErQ281VWsya3RuQld1YzJVenZra1BZbmg2NkFpa2dhckcrV0U4WHRC?=
 =?utf-8?B?RjBLOGZPWVh3NnRQL3dQK3RMSlFvQ1R3WmQ4TDJkelNpdTIvYm45aHVPUXo0?=
 =?utf-8?B?ZWJHQlBkRHV1MThqcXMwRzdyMUgwaE1kVlY5cnJxN2NObUxqTlMzaHRETmR5?=
 =?utf-8?B?WmFpb1ZGQTNlVWtVemZ3U3lTakJ4cjVXZllqT3JrZ3F6dmtiRUFNNW5TQVpi?=
 =?utf-8?B?RGpnUy9YcDE5cm1ZMCtySGtCQWwxWGVFRTNYd0JySnBFK3o4NkpSZW9zb2kr?=
 =?utf-8?Q?fqdAad1tVQ9b5NNLgqdMQ+CSqtO0Jg=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)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?V1dtM3dXOEdtMUoxOGlQeDZxWm5OU3ZQTmpnWUYvM1IvbDN0eitFendXRnFD?=
 =?utf-8?B?N0tzTzExdlp5Qjl2djFQNXd3bkEvT3B3WEcrdkhPcWoyTDJUMFVvbGtmdGpu?=
 =?utf-8?B?ZUtDV2puT0IzVDhJZ2NmMUg2S3ZWRDdrN1FjSnlPS1dDUGtMVkRGbjM1U3Y4?=
 =?utf-8?B?UDZDOERTQVNmanEwOXZQSjZLeTlTTzFkamNubklLRHJkSnA4ZDJIVmVBYkZy?=
 =?utf-8?B?M3pVZzRpeUtjd3d2S0d2alJTRE5MbzNPa2JHN3M2WDlWTTN2NU16UkRnKzZj?=
 =?utf-8?B?cEE0VDJvd3lrUHg1WjZEc2V3RzVZWGhTNUNkQkJZTXdWME80ZjRiV216bDN1?=
 =?utf-8?B?d1RLWUxiMTVYOCtoaTkzdjNBc3d4ZHVFRWtYWCtRYlh6TVlHQ21vRlh5cXU2?=
 =?utf-8?B?TTd6bVNMTDY1b244MzZpNndVRHJ5b1JscEJzUnJGYXMzTzBCQWJFLzlUcVUr?=
 =?utf-8?B?VTdIaHRBQ2lGRURCaGpEWGVmSzAxeVQ2R29pcjVyeXZXUDc4YTNsWEhSVTY5?=
 =?utf-8?B?SmI3Sy9rR0F6TVFiSDgydDFKaEs0djFRaFNjbTBLeEhpQmdNdHBqcEdRckd2?=
 =?utf-8?B?V1BlUm90WUszeCt2aDNNaW9qeGhHMXVTUTFXQ0JpblVqa3RLOVhqdXFTcTJj?=
 =?utf-8?B?b053alJBdHl4TzBmZnN4OHRSeFZ5MXdoREtiYjdGRlB2RmQyNXZ1eGQyNHZu?=
 =?utf-8?B?M3kxQlBEeUFqU2pWUjdoc3lJQXZTNWJXZFZWQXpxZW9XK29peDhXcWVQbGMz?=
 =?utf-8?B?dzZEeWVDcnNRWEdqaEw4TWR2WGJBdzZHZ0RQNmJyYThFc3RwL2ZINjhpYzdm?=
 =?utf-8?B?QU1pNDhYZnFaOG9VUXNmQi9RZ05TUkRDMVloaFU5N3hZc3RxNU9wVjNrdEp3?=
 =?utf-8?B?eXMzVU1HNzc1aTEwNHpUaDdJZmdKMXJJYVVpU041TGNhVDFzVEMyV3g5d0gv?=
 =?utf-8?B?Qm5RK1pyNGhBZkJ4dDhjc3JqZFR2aVdobVUxVkdLZXlXbGFjOE5XeVZuU2Fy?=
 =?utf-8?B?V204RGF5UzNFTzRnUmxUK05mNFlRSzN6QXZiSE1GL2RsWlgzYTRXTE5PcytT?=
 =?utf-8?B?Rkdkd0FENkVuRUQ3YUdHZWtpRkZYbEVvcU1QRGJJZ2VmZDhETTNkOHp4S3lU?=
 =?utf-8?B?dGo1MTZia0xzcTFweGVxQkRpekhjV1hLZTBtWTZUMGsweW1YOWdBVDNRVXB6?=
 =?utf-8?B?dmtvbXlTUlAwa051M1BiNkpSc3NtQUQzYVNtNFNhV283MWpGTEVjYmU1MGww?=
 =?utf-8?B?Rzc3SGRHeGFxamhWS05lT1BnUE9sVjkxNVRnK0Vqc2VCSjA3Z0d0Zm9kYUxj?=
 =?utf-8?B?NmFLWkhZUDg1eXlsYWlOdE5ibTA5NFllWTVXK3U0SkNycThhMnFxdkxrcmIx?=
 =?utf-8?B?aVplSG5wdFV1V3B4b1NRZU45Wml6N3VxV0dqOHRRNEZrMkREUEhNSzB0US8r?=
 =?utf-8?B?Z1FyRk02VDA4TmdDY1NWWEg4YzhYYk80dUVocXFNRTBuN0E2SmlCK0pib2gz?=
 =?utf-8?B?Tmo5VnM0UTdPUXBUcjhjSnhuNWN0ZHE3UUQyRGtLQ0RXbitJbHBySi9rQWNT?=
 =?utf-8?B?cDl1NVZGS254bGhCWHJDd1F1S2dPZDk4VGxiMzJQZFdWTnRjK1NYNHJMMGVl?=
 =?utf-8?B?cGVyOXNaamFoL0JTeXBlYzBVbW5EY29BV1NJY215eTA2OGxkRmhKRkNZNXpC?=
 =?utf-8?B?SXI0VnlBWFpZa1FBckVwN0ZnbWMzN2NzaThrRzFka1luZVZ6aldmTUVaY3hK?=
 =?utf-8?B?K2hrT0dPK29Xazk1dzlodVdvTE1CNjluM1kyRkdhYmVDczg5dEx0Q0M5NFJM?=
 =?utf-8?B?VEpqMHhRbzBpNEhuSHcrckJmTXpEOTlYWCtkRlZLSG8xY2dHckJpaW00WEwv?=
 =?utf-8?B?OXpoQ1pKbk9ldStMdnQzUmIxTVpaRDFzTXNPd2JQN0xnZTFFL0ZlMEwweE9p?=
 =?utf-8?B?VEhQdFlDOFphOGllV0Y1YnhPUjR1bitOcWEvMWdXQjNFZDMzMGVCTVl3M0tB?=
 =?utf-8?B?aGEycWQ1b3hDZVNVcENJdm9FbkVJNDg1eHRRcDdPSG1idU9aZXdmMU5SV3Vu?=
 =?utf-8?B?cEVJMmJFcDBUMUZpb3JseGN0Sk5LQ090bm5lZGVXbHBEUlEzUzNINndYWG54?=
 =?utf-8?B?ZGxhVy84c1VBNkVCWEV4VDZPSURqditaaTIwYVNGd3lmeC9tUkpnU1BaQW5P?=
 =?utf-8?B?dWc9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <14181DB20FB32C428FBDC9BF608B9AE5@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PAVPR03MB10102.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5cf19e65-024d-4727-16cd-08dda8208981
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2025 13:13:05.5772
 (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: C1LU7AoTOSzpQeOpN2j2az9nN7illrbHGZjohnqPGUd/KpAAmyRDsS/i3GAmovGrTVVrn7Xk8oRmeN4e4f136g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB9744

T24gMjkvMDUvMjAyNSAwMzoxMCwgRGVtaSBNYXJpZSBPYmVub3VyIHdyb3RlOg0KDQo+PiBPbiA1
LzI4LzI1IDA1OjEyLCBNeWt5dGEgUG90dXJhaSB3cm90ZToNCj4+PiBGcm9tOiBSYWh1bCBTaW5n
aCA8cmFodWwuc2luZ2hAYXJtLmNvbT4NCj4+Pg0KPj4+IEltcGxlbWVudCBzdXBwb3J0IGZvciBQ
Q0kgZGV2aWNlcyBpbiB0aGUgU01NVSBkcml2ZXIuIFRyaWdnZXIgaW9tbXUtbWFwDQo+Pj4gcGFy
c2luZyB3aGVuIG5ldyBQQ0kgZGV2aWNlIGlzIGFkZGVkLiBBZGQgY2hlY2tzIHRvIGFzc2lnbi9k
ZWFzc2lnbg0KPj4+IGZ1bmN0aW9ucyB0byBlbnN1cmUgUENJIGRldmljZXMgYXJlIGhhbmRsZWQg
Y29ycmVjdGx5LiBJbXBsZW1lbnQgYmFzaWMNCj4+PiBxdWFyYW50aW5pbmcuDQo+Pj4NCj4+PiBB
bGwgcGNpIGRldmljZXMgYXJlIGF1dG9tYXRpY2FsbHkgYXNzaWduZWQgdG8gaGFyZHdhcmUgZG9t
YWluIGlmIGl0IA0KPj4+IGV4aXN0cw0KPj4+IHRvIGVuc3VyZSBpdCBjYW4gcHJvYmUgdGhlbS4N
Cj4+IFRoaXMgaXMgb25seSBzYWZlIGZvciBkZXZpY2VzIHByZXNlbnQgYXQgYm9vdCB0aW1lLiAg
SXTigJlzIG5vdCBzYWZlIGZvcg0KPj4gaG90cGx1Z2dlZCBkZXZpY2VzLCB3aGljaCBzaG91bGQg
YmUgcXVhcmFudGluZWQuDQo+IA0KDQpIaSBEZW1pLA0KDQpDb3VsZCB5b3UgcGxlYXNlIGV4cGxh
aW4gYSBsaXR0bGUgbW9yZSBpbiBkZXRhaWwgd2hhdCBkbyB5b3UgdGhpbmsgdGhlIA0KaXNzdWVz
IHdpbGwgYmUgaGVyZT8gQXMgZmFyIGFzIEkgdW5kZXJzdGFuZCBxdWFyYW50aW5pbmcgaXMgb25s
eSANCnJlbGV2YW50IGZvciB0cmFuc2l0aW9uaW5nIGRldmljZXMgYmV0d2VlbiBkb21haW5zLiBN
YXliZSBJIGFtIG1pc3NpbmcgDQpzb21ldGhpbmcgaGVyZS4NCg0KLS0gDQpNeWt5dGE=


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 13:14:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 13:14:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010902.1389159 (Exim 4.92)
	(envelope-from )
	id 1uOyo4-0007uY-0W; Tue, 10 Jun 2025 13:14:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010902.1389159; Tue, 10 Jun 2025 13:14: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 1uOyo3-0007uG-So; Tue, 10 Jun 2025 13:14:23 +0000
Received: by outflank-mailman (input) for mailman id 1010902;
 Tue, 10 Jun 2025 13:14: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 1uOyfx-0004Sm-S1
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 13:06: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 a79c32ec-45fb-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 15:06:00 +0200 (CEST)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-adb2e9fd208so1005453066b.3
 for ; Tue, 10 Jun 2025 06:06:00 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ade32c42770sm626465466b.41.2025.06.10.06.05.58
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 10 Jun 2025 06:05:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a79c32ec-45fb-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749560759; x=1750165559; darn=lists.xenproject.org;
        h=content-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=OxKP9f8ngOMBgx9560upayt7lSd7zzCQxJwGN9s2GJk=;
        b=m1ovLthoevvFCTP+/FCbMSh7wbea1ENmx1tXO32LyFI/RlpTLezvYSCGmN6ZnTFRhn
         iqoa3mlawgCHTENDdO66G6BITW53nAMxvbtd2BsbvUFSiTV7pcFGTzy3UofVxfFo0hqS
         M4NuFkkENFhtpOlLergJltgqjTEAdwQbQlWEMbmlisdtO59DMLphH7ZHBtOMGlDjpWvn
         eTVH8Fl/pUuZPNzVy4aADgvTJYV6DJM9HiRs4vdiDPXWZSHqPL0dApBtPpXmoRdGixVM
         Q6MbUTl82/7ezeQpaZlOM6eTyCWp3BH5mK+o6cHtvi5MWbE6r3XpUV1gyR4M0J20DLtO
         qpyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749560759; x=1750165559;
        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=OxKP9f8ngOMBgx9560upayt7lSd7zzCQxJwGN9s2GJk=;
        b=iFOKX4zrUZwqiwLB3PdS33UxRr6moIipwqiMt6lgYgEDi7LOAsNqhJREXF40rSEYxR
         iNUdopvJhOTgWC2InEM/6h06iAK3M9EYbCUrYsLdRhy1nIIqD50ztjnivMWCbWocyZCC
         h62xNs4XaOwnEzn0uYz/WNjJ0WLqae3AvjEWDx6WHCK8wN3Pr3DKgF9lDoYR08QSpLvh
         j+BRMOlvPKpyXwesCpdiIeH4Zi0sxhKXH28e1wl1GznhNQkgRhxoZkXgxtyTmA7PlYLy
         sfr+Q0X/CmzwbHb3XO7vzDIuswmJ2d7oCdv0Iuewc5H8yowIbwm1LGKDfMhp1XM5oL/j
         9P/g==
X-Gm-Message-State: AOJu0YzVW+dkGP/jMUnUI7b9Oz+oSBOuPnNI6utTIkcblF85iBQW6ajb
	6RSrIRRc/e2ccKS+VEu7XpUuqr3Cr3J7UxIB+2cX/IfP/BDXrQen39KCH3C8Gg==
X-Gm-Gg: ASbGncviwSBNZPIT1gJfprb0kRJDuAvGV7ZBBJWidvnuu/sPn6+RnoKw/jGmRzPQT+3
	pp4oe2bfGZKCq4YMHTMuNXizPBC/xcM6SRoocRcOM46wySjBD+rsu6jPRJih62mELfoERCsEDKw
	W79J9Df/5xhhwwdphp3zzqM6HoiexM1WkMMXzxyQpJFa4Eeskte92VLTOUeywfJsQ3Or/naB8m5
	WZB0vyO+rm86We1lB/b+ZMUb6FMMASEVBHbX7Vv71Pqv575rT+QsCRvDvzut1Nzla5OY9iYxlax
	Yd0CLrcpHbLDqhdPalYWNH0GXZu4CAIV03Yn2hgn4uAZ2ZKSnz5oNbgXK4mVnNl0mAFA6FzssFW
	vT/lvJZM95mZJMV9Bt4aUL19AnBI7mkYUPDgJt2Y=
X-Google-Smtp-Source: AGHT+IHWl8myTiCOtSxMJB1ph23F+y6qfnmNmU/sbGUTwauxrcWLbzCTqhwYVY34jrYRSFX6Z5wKoA==
X-Received: by 2002:a17:907:7248:b0:ad8:9257:5735 with SMTP id a640c23a62f3a-ade1aa0fc41mr1574508766b.3.1749560759079;
        Tue, 10 Jun 2025 06:05:59 -0700 (PDT)
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 17/17] xen/riscv: add support of page lookup by GFN
Date: Tue, 10 Jun 2025 15:05:32 +0200
Message-ID: <6281efb0dc9b0a9ab4dd8cee7952bff2a7745963.1749555949.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Introduce helper functions for safely querying the P2M (physical-to-machine)
mapping:
 - add p2m_read_lock(), p2m_read_unlock(), and p2m_is_locked() for managing
   P2M lock state.
 - Implement p2m_get_entry() to retrieve mapping details for a given GFN,
   including MFN, page order, and validity.
 - Add p2m_lookup() to encapsulate read-locked MFN retrieval.
 - Introduce p2m_get_page_from_gfn() to convert a GFN into a page_info
   pointer, acquiring a reference to the page if valid.

Implementations are based on Arm's functions with some minor modifications:
- p2m_get_entry():
  - Reverse traversal of page tables, as RISC-V uses the opposite order
    compared to Arm.
  - Removed the return of p2m_access_t from p2m_get_entry() since
    mem_access_settings is not introduced for RISC-V.
  - Updated BUILD_BUG_ON() to check using the level 0 mask, which corresponds
    to Arm's THIRD_MASK.
  - Replaced open-coded bit shifts with the BIT() macro.
  - Other minor changes, such as using RISC-V-specific functions to validate
    P2M PTEs, and replacing Arm-specific GUEST_* macros with their RISC-V
    equivalents.
- p2m_get_page_from_gfn():
  - Removed p2m_is_foreign() and related logic, as this functionality is not
    implemented for RISC-V.

Signed-off-by: Oleksii Kurochko 
---
Changes in V2:
 - New patch.
---
 xen/arch/riscv/include/asm/p2m.h |  18 +++++
 xen/arch/riscv/p2m.c             | 131 +++++++++++++++++++++++++++++++
 2 files changed, 149 insertions(+)

diff --git a/xen/arch/riscv/include/asm/p2m.h b/xen/arch/riscv/include/asm/p2m.h
index fdebd18356..96e0790dbc 100644
--- a/xen/arch/riscv/include/asm/p2m.h
+++ b/xen/arch/riscv/include/asm/p2m.h
@@ -184,6 +184,24 @@ static inline int p2m_is_write_locked(struct p2m_domain *p2m)
     return rw_is_write_locked(&p2m->lock);
 }
 
+static inline void p2m_read_lock(struct p2m_domain *p2m)
+{
+    read_lock(&p2m->lock);
+}
+
+static inline void p2m_read_unlock(struct p2m_domain *p2m)
+{
+    read_unlock(&p2m->lock);
+}
+
+static inline int p2m_is_locked(struct p2m_domain *p2m)
+{
+    return rw_is_locked(&p2m->lock);
+}
+
+struct page_info *p2m_get_page_from_gfn(struct domain *d, gfn_t gfn,
+                                        p2m_type_t *t);
+
 #endif /* ASM__RISCV__P2M_H */
 
 /*
diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
index 79c4473f1f..034b1888c5 100644
--- a/xen/arch/riscv/p2m.c
+++ b/xen/arch/riscv/p2m.c
@@ -1055,3 +1055,134 @@ int guest_physmap_add_entry(struct domain *d,
 {
     return p2m_insert_mapping(d, gfn, (1 << page_order), mfn, t);
 }
+
+/*
+ * Get the details of a given gfn.
+ *
+ * If the entry is present, the associated MFN will be returned and the
+ * access and type filled up. The page_order will correspond to the
+ * order of the mapping in the page table (i.e it could be a superpage).
+ *
+ * If the entry is not present, INVALID_MFN will be returned and the
+ * page_order will be set according to the order of the invalid range.
+ *
+ * valid will contain the value of bit[0] (e.g valid bit) of the
+ * entry.
+ */
+static mfn_t p2m_get_entry(struct p2m_domain *p2m, gfn_t gfn,
+                           p2m_type_t *t,
+                           unsigned int *page_order,
+                           bool *valid)
+{
+    paddr_t addr = gfn_to_gaddr(gfn);
+    unsigned int level = 0;
+    pte_t entry, *table;
+    int rc;
+    mfn_t mfn = INVALID_MFN;
+    p2m_type_t _t;
+    DECLARE_OFFSETS(offsets, addr);
+
+    ASSERT(p2m_is_locked(p2m));
+    BUILD_BUG_ON(XEN_PT_LEVEL_MAP_MASK(0) != PAGE_MASK);
+
+    /* Allow t to be NULL */
+    t = t ?: &_t;
+
+    *t = p2m_invalid;
+
+    if ( valid )
+        *valid = false;
+
+    /* XXX: Check if the mapping is lower than the mapped gfn */
+
+    /* This gfn is higher than the highest the p2m map currently holds */
+    if ( gfn_x(gfn) > gfn_x(p2m->max_mapped_gfn) )
+    {
+        for ( level = P2M_ROOT_LEVEL; level ; level-- )
+            if ( (gfn_x(gfn) & (XEN_PT_LEVEL_MASK(level) >> PAGE_SHIFT)) >
+                 gfn_x(p2m->max_mapped_gfn) )
+                break;
+
+        goto out;
+    }
+
+    table = p2m_get_root_pointer(p2m, gfn);
+
+    /*
+     * the table should always be non-NULL because the gfn is below
+     * p2m->max_mapped_gfn and the root table pages are always present.
+     */
+    if ( !table )
+    {
+        ASSERT_UNREACHABLE();
+        level = P2M_ROOT_LEVEL;
+        goto out;
+    }
+
+    for ( level = P2M_ROOT_LEVEL; level ; level-- )
+    {
+        rc = p2m_next_level(p2m, true, level, &table, offsets[level]);
+        if ( (rc == GUEST_TABLE_MAP_NONE) && (rc != GUEST_TABLE_MAP_NOMEM) )
+            goto out_unmap;
+        else if ( rc != GUEST_TABLE_NORMAL )
+            break;
+    }
+
+    entry = table[offsets[level]];
+
+    if ( p2me_is_valid(p2m, entry) )
+    {
+        *t = p2m_type_radix_get(p2m, entry);
+
+        mfn = pte_get_mfn(entry);
+        /*
+         * The entry may point to a superpage. Find the MFN associated
+         * to the GFN.
+         */
+        mfn = mfn_add(mfn,
+                      gfn_x(gfn) & (BIT(XEN_PT_LEVEL_ORDER(level), UL) - 1));
+
+        if ( valid )
+            *valid = pte_is_valid(entry);
+    }
+
+out_unmap:
+    unmap_domain_page(table);
+
+out:
+    if ( page_order )
+        *page_order = XEN_PT_LEVEL_ORDER(level);
+
+    return mfn;
+}
+
+static mfn_t p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t *t)
+{
+    mfn_t mfn;
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+    p2m_read_lock(p2m);
+    mfn = p2m_get_entry(p2m, gfn, t, NULL, NULL);
+    p2m_read_unlock(p2m);
+
+    return mfn;
+}
+
+struct page_info *p2m_get_page_from_gfn(struct domain *d, gfn_t gfn,
+                                        p2m_type_t *t)
+{
+    p2m_type_t p2mt = {0};
+    struct page_info *page;
+
+    mfn_t mfn = p2m_lookup(d, gfn, &p2mt);
+
+    if ( t )
+        *t = p2mt;
+
+    if ( !mfn_valid(mfn) )
+        return NULL;
+
+    page = mfn_to_page(mfn);
+
+    return get_page(page, d) ? page : NULL;
+}
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 13:24:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 13:24:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010920.1389168 (Exim 4.92)
	(envelope-from )
	id 1uOyxi-0002WW-S9; Tue, 10 Jun 2025 13:24:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010920.1389168; Tue, 10 Jun 2025 13:24: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 1uOyxi-0002WP-Ph; Tue, 10 Jun 2025 13:24:22 +0000
Received: by outflank-mailman (input) for mailman id 1010920;
 Tue, 10 Jun 2025 13:24:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uOyxg-0002WD-NH
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 13:24:20 +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 3700cc6c-45fe-11f0-a306-13f23c93f187;
 Tue, 10 Jun 2025 15:24:19 +0200 (CEST)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-450cf214200so50672385e9.1
 for ; Tue, 10 Jun 2025 06:24:19 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a53244f07dsm12490714f8f.79.2025.06.10.06.24.18
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 10 Jun 2025 06:24:18 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3700cc6c-45fe-11f0-a306-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749561859; x=1750166659; 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=EgP7TvOVxTD2h/sls15DC30PgtzRWFjQ5PWHsWNoWUw=;
        b=lxLdnIrtpN1huw3n2Cyj0y9NLGoWWfQNPtzkB9cMBX64akmHjkgd9z6p1U1LdRX7R6
         yTNODcL+h4vHDrSTM3NzLsv9tuoEKBlwiOrXSENdnskgcMiaz1H8mr38dkfdEOqdPPRQ
         K5y+k5hH4TfTf68RFoIyVKPd/Wrf4CVIDD+b4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749561859; x=1750166659;
        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=EgP7TvOVxTD2h/sls15DC30PgtzRWFjQ5PWHsWNoWUw=;
        b=nCgJS/v828wpB4/z4dPsT/5bAJpYpFucGcoX2mwOdQiUvN9o5J5QgcFuFcV+T68oPx
         7abWTwfMrTHPiDQm9jw3ZgUm34YZlCeuxMWejSyR9EzAmTqQUvk+DaPx0TnIh7N8B7mk
         lt0AlMEDbTakjPcp7Th6p3eD7l9rOInhR/4ce4R60rOB21HNj6vHZqjWEq/NZ4euRIv/
         xVsoSAf30pPWwgcShEh4cZ/ooNj60N9iPUt6ebN18WOtGYCOdioiNzNGaXSpJQtwEXcJ
         81XteRuDT4uGvfl15DdB4ngm59AX4IvW3GWYtN94+4MEfaBzxASsA/hyYcZyd6rL+M/p
         usdA==
X-Gm-Message-State: AOJu0YzAkGTIyihiJLlT7CXhL0NszNgZKEut67IYG7CJvMod8Ys7oIAa
	QohdUK3Mhf3nWo+hy4LLtKRBuJMSiMYqXVGyinuwJpTvD6vFaFPMxhmz/zDFXGUuj2/1vb6g4n0
	v2hfG
X-Gm-Gg: ASbGncsSNTZrmsAWgYppNYIvLPfGenTJ3x3D3RLEUMGlJwyQSlufwz8uLvluniU19Gx
	0BwUAXXll5zYGPJevSlDuW9FITR7tqalkdhSp/FlJtl4CbF7HxOEq7hwcg7gYebosI23XaiHFja
	BNtf0sOdNKfvLb1Z6lWAeSOIB/VNwg7qE8/Y5qJgwm5ZUBt4A+wIKzGiboUdCBkkva/dvTlvuYY
	KXSHW46ApO7W9i/MTwTgHaTl0zVHrSmUbR6mov6jgp0+9pCyDeibSRmINnQs803NRkMIjds6Dcw
	yjwGa459f/B9JVaj0Wz1OqKGrdzCgv5OVQm6m9BdJwPK2rLl78IJN4CzxYsMwmgBSLtPbdAfQbP
	Jt9DRrr0FH4smsDL5tvHEis23wJWFpQ==
X-Google-Smtp-Source: AGHT+IGpqvy7dm5XAcw5ASv7YmrVms1L6JEiggGXKssJeqAktc0oJJj6VLjIdE3guhX+/hopIQGd4w==
X-Received: by 2002:a05:6000:24c8:b0:3a4:bfda:1e9 with SMTP id ffacd0b85a97d-3a531ab73f7mr15401271f8f.46.1749561858865;
        Tue, 10 Jun 2025 06:24:18 -0700 (PDT)
Date: Tue, 10 Jun 2025 15:24:17 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" ,
	Andrew Cooper 
Subject: Re: [PATCH v2] x86/HVM: restrict use of pinned cache attributes as
 well as associated flushing
Message-ID: 
References: <78b3ddeb-4317-4d54-ad52-9eb03bdf7942@suse.com>
 
 <6e9e84eb-f98b-4c06-8952-03aecc82c0ea@suse.com>
 
 <5f8d694f-e712-4869-879f-80b2c4907a45@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <5f8d694f-e712-4869-879f-80b2c4907a45@suse.com>

On Tue, Jun 10, 2025 at 01:59:52PM +0200, Jan Beulich wrote:
> On 10.06.2025 12:44, Roger Pau Monné wrote:
> > On Tue, Jun 10, 2025 at 09:40:38AM +0200, Jan Beulich wrote:
> >> On 09.06.2025 12:36, Roger Pau Monné wrote:
> >>> On Wed, Jun 04, 2025 at 11:48:00AM +0200, Jan Beulich wrote:
> >>>> @@ -605,31 +606,35 @@ int hvm_set_mem_pinned_cacheattr(struct
> >>>>  
> >>>>                  type = range->type;
> >>>>                  call_rcu(&range->rcu, free_pinned_cacheattr_entry);
> >>>> -                p2m_memory_type_changed(d);
> >>>>                  switch ( type )
> >>>>                  {
> >>>> -                case X86_MT_UCM:
> >>>> +                case X86_MT_WB:
> >>>> +                case X86_MT_WP:
> >>>> +                case X86_MT_WT:
> >>>>                      /*
> >>>> -                     * For EPT we can also avoid the flush in this case;
> >>>> -                     * see epte_get_entry_emt().
> >>>> +                     * Flush since we don't know what the cachability is going
> >>>> +                     * to be.
> >>>>                       */
> >>>> -                    if ( hap_enabled(d) && cpu_has_vmx )
> >>>> -                case X86_MT_UC:
> >>>> -                        break;
> >>>> -                    /* fall through */
> >>>> -                default:
> >>>> -                    flush_all(FLUSH_CACHE);
> >>>> +                    if ( is_iommu_enabled(d) || cache_flush_permitted(d) )
> >>>> +                        flush = true;
> >>>
> >>> Is the check here required?  memory_type_changed() will already check
> >>> for is_iommu_enabled() and cache_flush_permitted(), and hence you
> >>> could just set flush to true unconditionally here IMO.
> >>
> >> The behavioral difference is when both predicates are false: The way I have
> >> it now, p2m_memory_type_changed() will then still be called (conditionally),
> >> better matching prior behavior.
> > 
> > I see.  Yes, p2m_memory_type_changed() needs to be called.

This is complicated.  Looking at memory_type_changed() it's true that
p2m_memory_type_changed() will only be called when
cache_flush_permitted() == true, however by cache_flush_permitted()
returning false we could also imply that there are no p2m_mmio_direct
entries in the p2m, and hence effectively nothing to flush?

> >>
> >>>>                      break;
> >>>>                  }
> >>>> -                return 0;
> >>>> +                rc = 0;
> >>>> +                goto finish;
> >>>>              }
> >>>>          domain_unlock(d);
> >>>>          return -ENOENT;
> >>>>  
> >>>>      case X86_MT_UCM:
> >>>>      case X86_MT_UC:
> >>>> -    case X86_MT_WB:
> >>>>      case X86_MT_WC:
> >>>> +        /* Flush since we don't know what the cachability was. */
> >>>> +        if ( !is_iommu_enabled(d) && !cache_flush_permitted(d) )
> >>>> +            return -EPERM;
> > 
> > When assigning IO resources without an IOMMU enabled we likely need
> > to allow the pinned cache attributes to be set, but there's no need to
> > propagate the changes to the p2m, as the EMT calculation won't take
> > into account the pinned attributes.
> 
> Why would it not do so? Am I overlooking a conditional there that would
> cause hvm_get_mem_pinned_cacheattr() to not be called? The only related
> one I see is
> 
>     if ( type != p2m_mmio_direct && !is_iommu_enabled(d) &&
>          !cache_flush_permitted(d) )

Sorry, what I wrote is nonsense.  I wanted to note that it should be
possible to set cache attributes ahead of assigning IO resources, and
so returning -EPERM might alter existing users of the interface.

However setting cache attributes ahead of having actually assigned IO
resources would seem like an out of order operation logic, and hence
there's no point in supporting it.

> covering the without-IOMMU case just the same as the "with" one. (The
> "without" case looks dubious to me, as I don't think we arrange for
> any identity mapping, but that's a separate topic.)
> 
> > IOW: I don't think we can safely short-circuit and return -EPERM here
> > without agreeing that it's a behavioral difference form the previous
> > implementation.
> 
> There's no question there is a behavioral change here. Without I/O
> resources (and without IOMMU) we simply don't accept cache attributes
> other then WB elsewhere; the change is to avoid doing so here as well,
> to get things to be consistent. Hence the -EPERM return.
> 
> >>>> @@ -682,9 +687,11 @@ int hvm_set_mem_pinned_cacheattr(struct
> >>>>  
> >>>>      xfree(newr);
> >>>>  
> >>>> -    p2m_memory_type_changed(d);
> >>>> -    if ( type != X86_MT_WB )
> >>>> -        flush_all(FLUSH_CACHE);
> >>>> + finish:
> >>>> +    if ( flush )
> >>>> +        memory_type_changed(d);
> >>>> +    else if ( d->vcpu && d->vcpu[0] )
> >>>> +        p2m_memory_type_changed(d);
> >>>
> >>> FWIW, I would just call memory_type_changed() unconditionally
> >>> regardless of the change.
> >>
> >> In which case the need for the "flush" local var would go away, if I
> >> understand your suggestion correctly. Like above, there'll then be
> >> more of a behavioral change than intended. In particular ...
> > 
> > There will be a behavioral change, but not one that the guest would
> > notice IMO.
> > 
> >>>  We suspect the hypercall is only used at
> >>> domain creation time (where memory_type_changed() won't do a cache
> >>> flush anyway).
> >>
> >> ... "suspect" is not enough for my taste. The only alternative there
> >> that I see (as mentioned in a post-commit-message remark) is to
> >> refuse such "late" changes altogether. Yet for that we need to be
> >> sure, which it looks like no-one of us is.
> > 
> > Why do you say only alternative?
> 
> Oh, sorry, I meant "only" just in regard to options keeping the main
> code structure of the change. I agree ...
> 
> > Calling memory_type_changed() unconditionally (without taking into
> > account the previous or new cache attributes) would also be an
> > acceptable solution, that might wide the cache flushing a bit, but
> > would still be correct and much simpler IMO.
> 
> ... that this, too, is a possibility. It would, however, go against the
> stated purpose of the change (in the subject "... as well as associated
> flushing"), which - after all - was the main goal here, seeing the
> series this was originally part of.

Given the recently added logic in memory_type_changed() to limit the
flushing, I'm not sure it would go against the patch subject.  Just
using memory_type_changed() as-is will already prevent flushing when
the guest is not yet started, and would also limit the flushing to the
cases where snooping accesses cannot be forced from the IOMMU.
It will mostly likely result in a reduction of the flushing, even if
the attribute type checking was removed.

IMO the added complexity here is not worth the performance
improvement, not without a clear justification that it's needed.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 13:31:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 13:31:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010930.1389179 (Exim 4.92)
	(envelope-from )
	id 1uOz4b-0004mN-Ly; Tue, 10 Jun 2025 13:31:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010930.1389179; Tue, 10 Jun 2025 13: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 1uOz4b-0004mF-JJ; Tue, 10 Jun 2025 13:31:29 +0000
Received: by outflank-mailman (input) for mailman id 1010930;
 Tue, 10 Jun 2025 13:31: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 1uOz4a-0004kw-6s
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 13:31:28 +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 35cfa4ab-45ff-11f0-a306-13f23c93f187;
 Tue, 10 Jun 2025 15:31:27 +0200 (CEST)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-ad1b94382b8so947981366b.0
 for ; Tue, 10 Jun 2025 06:31:27 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ade1dc3837asm725933366b.126.2025.06.10.06.31.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 06:31:25 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 35cfa4ab-45ff-11f0-a306-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749562286; x=1750167086; 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=fq3Y4rNcbO1HCEm99djykcuFV4Ao7obzej6I/Y2jK3I=;
        b=E5QSct0fWP8iPyPgO2MaCYl0czlWMWXludkBIukWNW1w3QlqlSJMQ2k6rELvyZLmfA
         hjWGZrnGu7xZ3/wByTlzsZ+QhmQvIocgOPRtrkg++DggIygaYqpRlZwVHM8e0gn1WF2j
         tr9nvYrmREv30xBDLWMUcO9VyPnnE9tuv9/AsJX4+tF3sDGdpWYDKI/dsRWeRsup44fH
         uqt2CaPInMrE6EKypseT1/8C4kdXo9vFIGGdLw1eP8TjlDcYhfEhlMw+CB1X+Fxwcu5v
         +GANLe60FIIVn0U5zVqn93T1JMxGcrlpIZ8YslCNzBuz3aLzh9EarjZaCUxO/o19UoCJ
         CG7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749562286; x=1750167086;
        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=fq3Y4rNcbO1HCEm99djykcuFV4Ao7obzej6I/Y2jK3I=;
        b=ROsFghGqeRaunoV9lwhVi5mRyW7ITYBWg4kYIqisRoE8qMvqqDxklzU4HeOenZr4xf
         rqtzq+ygT8w9OBZ/mp8XdemX2AFc7m2gn4uxqNarFArbgCl2KXPaS1UVRarOzKC+MVUd
         oMTKUStcL2Kw8EZKh7FCMOC+ZL0SG433rjSJdoR4iZVZCTBrVSNMGyZL6+/KgAao3beo
         rPyJe1Ce5q+1ZBUExzaST0DuAdVdU1bdqcgFs+LyGj5XgxuzXXc8LxovZL8CjM+cf+5f
         UhC8JnBNvxnvny0P8P3SO9nzV6yEvQznfSi/UyhMRgEabzwhvJP4xBAn1Zu9SgtOBs1e
         Hhaw==
X-Forwarded-Encrypted: i=1; AJvYcCUadleTb5RXdgpmM38P7gEwYaZktwH0G4sBXwkO668AjKXQ/2dEN+h+iT+Y1bvAQk2Numsshmz8vLQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxhsEF+1wW86OrXFkHEJv7uqLkD3cPqmjc3RcKI030o2GgdwJU3
	t2chEfDSEjo2Qey5QXhGYPEFkLP5VNnKpHK7uvKfLOlvkji/hsatU1IC
X-Gm-Gg: ASbGncs2XaoL8pphM1Kks+OsNzEmjUMBOnNcCi3l6qM0jo1FaymVLfmLMgGTaIDeVBk
	7LvuqoNxEn/B1aCBka+fpeyM4khKLH8r9ruaCzkM4XE7t2qUqLGS57JueBDBiX0PoU56NFgHdKf
	2taEQeV4H+UZSWCWQeMH9N+C94d43yPzRdixljq4bu2JGVF2brJlWTeuavo0/PtNHQ/uetTl+mw
	RQx//tWCfa+aqesUyKcozZAoiECMED+piY5TDZ9NT124X8TbzwjULqnadN0r1seTx6EqW2N2tOu
	XE1UsVHYb7zwSv9vqMOkphRkPV1FNqc4KQHN0db6xSjWV5bCMtk5BobJJtocKA7o8vcCwkB7DLj
	5xDk6ZVJ1ReKQYlf6usbF75baN0NWQMls+FhWA4dOeVDS+g==
X-Google-Smtp-Source: AGHT+IGP+g95mFEJR/IeHA/WMM9mq/zz/hq0XvhDeZq0IYbh+eonTPIgjX6pnM66rokGU24ZJ2aNcA==
X-Received: by 2002:a17:907:3f8b:b0:ad8:9257:5740 with SMTP id a640c23a62f3a-ade7ac53e18mr273409566b.13.1749562286128;
        Tue, 10 Jun 2025 06:31:26 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------0IFly4YCQMApzFg4B9RmvMse"
Message-ID: 
Date: Tue, 10 Jun 2025 15:31:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 6/6] mm: allow page scrubbing routine(s) to be arch
 controlled
To: Jan Beulich ,
 "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini ,
 Anthony PERARD ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Bertrand Marquis ,
 Volodymyr Babchuk ,
 Shawn Anastasio 
References: <73481cbf-337f-4e85-81d2-3487366cd822@suse.com>
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

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


On 6/5/25 12:28 PM, Jan Beulich wrote:
> Especially when dealing with large amounts of memory, memset() may not
> be very efficient; this can be bad enough that even for debug builds a
> custom function is warranted. We additionally want to distinguish "hot"
> and "cold" cases (with, as initial heuristic, "hot" being for any
> allocations a domain does for itself, assuming that in all other cases
> the page wouldn't be accessed [again] soon). The goal is for accesses
> of "cold" pages to not disturb caches (albeit finding a good balance
> between this and the higher latency looks to be difficult).
>
> Keep the default fallback to clear_page_*() in common code; this may
> want to be revisited down the road.
>
> Signed-off-by: Jan Beulich
> Acked-by: Julien Grall
> ---
> v4: Re-base.
> v3: Re-base.
> v2: New.
> ---
> The choice between hot and cold in scrub_one_page()'s callers is
> certainly up for discussion / improvement.
>
> --- a/xen/arch/arm/include/asm/page.h
> +++ b/xen/arch/arm/include/asm/page.h
> @@ -144,6 +144,12 @@ extern size_t dcache_line_bytes;
>   
>   #define copy_page(dp, sp) memcpy(dp, sp, PAGE_SIZE)
>   
> +#define clear_page_hot  clear_page
> +#define clear_page_cold clear_page
> +
> +#define scrub_page_hot(page) memset(page, SCRUB_BYTE_PATTERN, PAGE_SIZE)
> +#define scrub_page_cold      scrub_page_hot
> +
>   static inline size_t read_dcache_line_bytes(void)
>   {
>       register_t ctr;
> --- a/xen/arch/ppc/include/asm/page.h
> +++ b/xen/arch/ppc/include/asm/page.h
> @@ -188,6 +188,12 @@ static inline void invalidate_icache(voi
>   #define clear_page(page) memset(page, 0, PAGE_SIZE)
>   #define copy_page(dp, sp) memcpy(dp, sp, PAGE_SIZE)
>   
> +#define clear_page_hot  clear_page
> +#define clear_page_cold clear_page
> +
> +#define scrub_page_hot(page) memset(page, SCRUB_BYTE_PATTERN, PAGE_SIZE)
> +#define scrub_page_cold      scrub_page_hot
> +
>   /* TODO: Flush the dcache for an entire page. */
>   static inline void flush_page_to_ram(unsigned long mfn, bool sync_icache)
>   {
> --- a/xen/arch/riscv/include/asm/page.h
> +++ b/xen/arch/riscv/include/asm/page.h
> @@ -198,6 +198,12 @@ static inline void invalidate_icache(voi
>   #define clear_page(page) memset((void *)(page), 0, PAGE_SIZE)
>   #define copy_page(dp, sp) memcpy(dp, sp, PAGE_SIZE)
>   
> +#define clear_page_hot  clear_page
> +#define clear_page_cold clear_page
> +
> +#define scrub_page_hot(page) memset(page, SCRUB_BYTE_PATTERN, PAGE_SIZE)
> +#define scrub_page_cold      scrub_page_hot
> +

LGTM: Reviewed-by: Oleksii Kurochko

Thanks.

~ Oleksii

>   static inline void flush_page_to_ram(unsigned long mfn, bool sync_icache)
>   {
>       const void *v = map_domain_page(_mfn(mfn));
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -58,6 +58,7 @@ obj-y += pci.o
>   obj-y += physdev.o
>   obj-$(CONFIG_COMPAT) += x86_64/physdev.o
>   obj-$(CONFIG_X86_PSR) += psr.o
> +obj-bin-$(CONFIG_DEBUG) += scrub_page.o
>   obj-y += setup.o
>   obj-y += shutdown.o
>   obj-y += smp.o
> --- a/xen/arch/x86/include/asm/page.h
> +++ b/xen/arch/x86/include/asm/page.h
> @@ -226,6 +226,11 @@ void copy_page_sse2(void *to, const void
>   #define clear_page(_p)      clear_page_cold(_p)
>   #define copy_page(_t, _f)   copy_page_sse2(_t, _f)
>   
> +#ifdef CONFIG_DEBUG
> +void scrub_page_hot(void *);
> +void scrub_page_cold(void *);
> +#endif
> +
>   /* Convert between Xen-heap virtual addresses and machine addresses. */
>   #define __pa(x)             (virt_to_maddr(x))
>   #define __va(x)             (maddr_to_virt(x))
> --- /dev/null
> +++ b/xen/arch/x86/scrub_page.S
> @@ -0,0 +1,39 @@
> +        .file __FILE__
> +
> +#include 
> +#include 
> +#include 
> +
> +FUNC(scrub_page_cold)
> +        mov     $PAGE_SIZE/32, %ecx
> +        mov     $SCRUB_PATTERN, %rax
> +
> +0:      movnti  %rax,   (%rdi)
> +        movnti  %rax,  8(%rdi)
> +        movnti  %rax, 16(%rdi)
> +        movnti  %rax, 24(%rdi)
> +        add     $32, %rdi
> +        sub     $1, %ecx
> +        jnz     0b
> +
> +        sfence
> +        ret
> +END(scrub_page_cold)
> +
> +        .macro scrub_page_stosb
> +        mov     $PAGE_SIZE, %ecx
> +        mov     $SCRUB_BYTE_PATTERN, %eax
> +        rep stosb
> +        ret
> +        .endm
> +
> +        .macro scrub_page_stosq
> +        mov     $PAGE_SIZE/8, %ecx
> +        mov     $SCRUB_PATTERN, %rax
> +        rep stosq
> +        ret
> +        .endm
> +
> +FUNC(scrub_page_hot)
> +        ALTERNATIVE scrub_page_stosq, scrub_page_stosb, X86_FEATURE_ERMS
> +END(scrub_page_hot)
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -135,6 +135,7 @@
>   #include 
>   #include 
>   #include 
> +#include 
>   #include 
>   #include 
>   #include 
> @@ -779,27 +780,31 @@ static void page_list_add_scrub(struct p
>           page_list_add(pg, &heap(node, zone, order));
>   }
>   
> -/* SCRUB_PATTERN needs to be a repeating series of bytes. */
> -#ifndef NDEBUG
> -#define SCRUB_PATTERN        0xc2c2c2c2c2c2c2c2ULL
> -#else
> -#define SCRUB_PATTERN        0ULL
> +/*
> + * While in debug builds we want callers to avoid relying on allocations
> + * returning zeroed pages, for a production build, clear_page_*() is the
> + * fastest way to scrub.
> + */
> +#ifndef CONFIG_DEBUG
> +# undef  scrub_page_hot
> +# define scrub_page_hot clear_page_hot
> +# undef  scrub_page_cold
> +# define scrub_page_cold clear_page_cold
>   #endif
> -#define SCRUB_BYTE_PATTERN   (SCRUB_PATTERN & 0xff)
>   
> -static void scrub_one_page(const struct page_info *pg)
> +static void scrub_one_page(const struct page_info *pg, bool cold)
>   {
> +    void *ptr;
> +
>       if ( unlikely(pg->count_info & PGC_broken) )
>           return;
>   
> -#ifndef NDEBUG
> -    /* Avoid callers relying on allocations returning zeroed pages. */
> -    unmap_domain_page(memset(__map_domain_page(pg),
> -                             SCRUB_BYTE_PATTERN, PAGE_SIZE));
> -#else
> -    /* For a production build, clear_page() is the fastest way to scrub. */
> -    clear_domain_page(_mfn(page_to_mfn(pg)));
> -#endif
> +    ptr = __map_domain_page(pg);
> +    if ( cold )
> +        scrub_page_cold(ptr);
> +    else
> +        scrub_page_hot(ptr);
> +    unmap_domain_page(ptr);
>   }
>   
>   static void poison_one_page(struct page_info *pg)
> @@ -1079,12 +1084,14 @@ static struct page_info *alloc_heap_page
>       if ( first_dirty != INVALID_DIRTY_IDX ||
>            (scrub_debug && !(memflags & MEMF_no_scrub)) )
>       {
> +        bool cold = d && d != current->domain;
> +
>           for ( i = 0; i < (1U << order); i++ )
>           {
>               if ( test_and_clear_bit(_PGC_need_scrub, &pg[i].count_info) )
>               {
>                   if ( !(memflags & MEMF_no_scrub) )
> -                    scrub_one_page(&pg[i]);
> +                    scrub_one_page(&pg[i], cold);
>   
>                   dirty_cnt++;
>               }
> @@ -1349,7 +1356,7 @@ bool scrub_free_pages(void)
>                   {
>                       if ( test_bit(_PGC_need_scrub, &pg[i].count_info) )
>                       {
> -                        scrub_one_page(&pg[i]);
> +                        scrub_one_page(&pg[i], true);
>                           /*
>                            * We can modify count_info without holding heap
>                            * lock since we effectively locked this buddy by
> @@ -2074,7 +2081,7 @@ static struct page_info *alloc_color_hea
>       if ( !(memflags & MEMF_no_scrub) )
>       {
>           if ( need_scrub )
> -            scrub_one_page(pg);
> +            scrub_one_page(pg, d != current->domain);
>           else
>               check_one_page(pg);
>       }
> @@ -2225,7 +2232,7 @@ static void __init cf_check smp_scrub_he
>           if ( !mfn_valid(_mfn(mfn)) || !page_state_is(pg, free) )
>               continue;
>   
> -        scrub_one_page(pg);
> +        scrub_one_page(pg, true);
>       }
>   }
>   
> @@ -2930,7 +2937,7 @@ void unprepare_staticmem_pages(struct pa
>           if ( need_scrub )
>           {
>               /* TODO: asynchronous scrubbing for pages of static memory. */
> -            scrub_one_page(pg);
> +            scrub_one_page(pg, true);
>           }
>   
>           pg[i].count_info |= PGC_static;
> --- /dev/null
> +++ b/xen/include/xen/scrub.h
> @@ -0,0 +1,24 @@
> +#ifndef __XEN_SCRUB_H__
> +#define __XEN_SCRUB_H__
> +
> +#include 
> +
> +/* SCRUB_PATTERN needs to be a repeating series of bytes. */
> +#ifdef CONFIG_DEBUG
> +# define SCRUB_PATTERN       _AC(0xc2c2c2c2c2c2c2c2,ULL)
> +#else
> +# define SCRUB_PATTERN       _AC(0,ULL)
> +#endif
> +#define SCRUB_BYTE_PATTERN   (SCRUB_PATTERN & 0xff)
> +
> +#endif /* __XEN_SCRUB_H__ */
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
>
--------------0IFly4YCQMApzFg4B9RmvMse
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    

    
    
    
    
    On 6/5/25 12:28 PM, Jan Beulich wrote:
    
    
    
    
    
      
    Especially when dealing with large amounts of memory, memset() may not
be very efficient; this can be bad enough that even for debug builds a
custom function is warranted. We additionally want to distinguish "hot"
and "cold" cases (with, as initial heuristic, "hot" being for any
allocations a domain does for itself, assuming that in all other cases
the page wouldn't be accessed [again] soon). The goal is for accesses
of "cold" pages to not disturb caches (albeit finding a good balance
between this and the higher latency looks to be difficult).

Keep the default fallback to clear_page_*() in common code; this may
want to be revisited down the road.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <jgrall@amazon.com>
---
v4: Re-base.
v3: Re-base.
v2: New.
---
The choice between hot and cold in scrub_one_page()'s callers is
certainly up for discussion / improvement.

--- a/xen/arch/arm/include/asm/page.h
+++ b/xen/arch/arm/include/asm/page.h
@@ -144,6 +144,12 @@ extern size_t dcache_line_bytes;
 
 #define copy_page(dp, sp) memcpy(dp, sp, PAGE_SIZE)
 
+#define clear_page_hot  clear_page
+#define clear_page_cold clear_page
+
+#define scrub_page_hot(page) memset(page, SCRUB_BYTE_PATTERN, PAGE_SIZE)
+#define scrub_page_cold      scrub_page_hot
+
 static inline size_t read_dcache_line_bytes(void)
 {
     register_t ctr;
--- a/xen/arch/ppc/include/asm/page.h
+++ b/xen/arch/ppc/include/asm/page.h
@@ -188,6 +188,12 @@ static inline void invalidate_icache(voi
 #define clear_page(page) memset(page, 0, PAGE_SIZE)
 #define copy_page(dp, sp) memcpy(dp, sp, PAGE_SIZE)
 
+#define clear_page_hot  clear_page
+#define clear_page_cold clear_page
+
+#define scrub_page_hot(page) memset(page, SCRUB_BYTE_PATTERN, PAGE_SIZE)
+#define scrub_page_cold      scrub_page_hot
+
 /* TODO: Flush the dcache for an entire page. */
 static inline void flush_page_to_ram(unsigned long mfn, bool sync_icache)
 {
--- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -198,6 +198,12 @@ static inline void invalidate_icache(voi
 #define clear_page(page) memset((void *)(page), 0, PAGE_SIZE)
 #define copy_page(dp, sp) memcpy(dp, sp, PAGE_SIZE)
 
+#define clear_page_hot  clear_page
+#define clear_page_cold clear_page
+
+#define scrub_page_hot(page) memset(page, SCRUB_BYTE_PATTERN, PAGE_SIZE)
+#define scrub_page_cold      scrub_page_hot
+
    
    
    
    
    LGTM: Reviewed-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

Thanks.

~ Oleksii

    
    
    
      
     static inline void flush_page_to_ram(unsigned long mfn, bool sync_icache)
 {
     const void *v = map_domain_page(_mfn(mfn));
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -58,6 +58,7 @@ obj-y += pci.o
 obj-y += physdev.o
 obj-$(CONFIG_COMPAT) += x86_64/physdev.o
 obj-$(CONFIG_X86_PSR) += psr.o
+obj-bin-$(CONFIG_DEBUG) += scrub_page.o
 obj-y += setup.o
 obj-y += shutdown.o
 obj-y += smp.o
--- a/xen/arch/x86/include/asm/page.h
+++ b/xen/arch/x86/include/asm/page.h
@@ -226,6 +226,11 @@ void copy_page_sse2(void *to, const void
 #define clear_page(_p)      clear_page_cold(_p)
 #define copy_page(_t, _f)   copy_page_sse2(_t, _f)
 
+#ifdef CONFIG_DEBUG
+void scrub_page_hot(void *);
+void scrub_page_cold(void *);
+#endif
+
 /* Convert between Xen-heap virtual addresses and machine addresses. */
 #define __pa(x)             (virt_to_maddr(x))
 #define __va(x)             (maddr_to_virt(x))
--- /dev/null
+++ b/xen/arch/x86/scrub_page.S
@@ -0,0 +1,39 @@
+        .file __FILE__
+
+#include <asm/asm_defns.h>
+#include <xen/page-size.h>
+#include <xen/scrub.h>
+
+FUNC(scrub_page_cold)
+        mov     $PAGE_SIZE/32, %ecx
+        mov     $SCRUB_PATTERN, %rax
+
+0:      movnti  %rax,   (%rdi)
+        movnti  %rax,  8(%rdi)
+        movnti  %rax, 16(%rdi)
+        movnti  %rax, 24(%rdi)
+        add     $32, %rdi
+        sub     $1, %ecx
+        jnz     0b
+
+        sfence
+        ret
+END(scrub_page_cold)
+
+        .macro scrub_page_stosb
+        mov     $PAGE_SIZE, %ecx
+        mov     $SCRUB_BYTE_PATTERN, %eax
+        rep stosb
+        ret
+        .endm
+
+        .macro scrub_page_stosq
+        mov     $PAGE_SIZE/8, %ecx
+        mov     $SCRUB_PATTERN, %rax
+        rep stosq
+        ret
+        .endm
+
+FUNC(scrub_page_hot)
+        ALTERNATIVE scrub_page_stosq, scrub_page_stosb, X86_FEATURE_ERMS
+END(scrub_page_hot)
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -135,6 +135,7 @@
 #include <xen/pfn.h>
 #include <xen/types.h>
 #include <xen/sched.h>
+#include <xen/scrub.h>
 #include <xen/sections.h>
 #include <xen/softirq.h>
 #include <xen/spinlock.h>
@@ -779,27 +780,31 @@ static void page_list_add_scrub(struct p
         page_list_add(pg, &heap(node, zone, order));
 }
 
-/* SCRUB_PATTERN needs to be a repeating series of bytes. */
-#ifndef NDEBUG
-#define SCRUB_PATTERN        0xc2c2c2c2c2c2c2c2ULL
-#else
-#define SCRUB_PATTERN        0ULL
+/*
+ * While in debug builds we want callers to avoid relying on allocations
+ * returning zeroed pages, for a production build, clear_page_*() is the
+ * fastest way to scrub.
+ */
+#ifndef CONFIG_DEBUG
+# undef  scrub_page_hot
+# define scrub_page_hot clear_page_hot
+# undef  scrub_page_cold
+# define scrub_page_cold clear_page_cold
 #endif
-#define SCRUB_BYTE_PATTERN   (SCRUB_PATTERN & 0xff)
 
-static void scrub_one_page(const struct page_info *pg)
+static void scrub_one_page(const struct page_info *pg, bool cold)
 {
+    void *ptr;
+
     if ( unlikely(pg->count_info & PGC_broken) )
         return;
 
-#ifndef NDEBUG
-    /* Avoid callers relying on allocations returning zeroed pages. */
-    unmap_domain_page(memset(__map_domain_page(pg),
-                             SCRUB_BYTE_PATTERN, PAGE_SIZE));
-#else
-    /* For a production build, clear_page() is the fastest way to scrub. */
-    clear_domain_page(_mfn(page_to_mfn(pg)));
-#endif
+    ptr = __map_domain_page(pg);
+    if ( cold )
+        scrub_page_cold(ptr);
+    else
+        scrub_page_hot(ptr);
+    unmap_domain_page(ptr);
 }
 
 static void poison_one_page(struct page_info *pg)
@@ -1079,12 +1084,14 @@ static struct page_info *alloc_heap_page
     if ( first_dirty != INVALID_DIRTY_IDX ||
          (scrub_debug && !(memflags & MEMF_no_scrub)) )
     {
+        bool cold = d && d != current->domain;
+
         for ( i = 0; i < (1U << order); i++ )
         {
             if ( test_and_clear_bit(_PGC_need_scrub, &pg[i].count_info) )
             {
                 if ( !(memflags & MEMF_no_scrub) )
-                    scrub_one_page(&pg[i]);
+                    scrub_one_page(&pg[i], cold);
 
                 dirty_cnt++;
             }
@@ -1349,7 +1356,7 @@ bool scrub_free_pages(void)
                 {
                     if ( test_bit(_PGC_need_scrub, &pg[i].count_info) )
                     {
-                        scrub_one_page(&pg[i]);
+                        scrub_one_page(&pg[i], true);
                         /*
                          * We can modify count_info without holding heap
                          * lock since we effectively locked this buddy by
@@ -2074,7 +2081,7 @@ static struct page_info *alloc_color_hea
     if ( !(memflags & MEMF_no_scrub) )
     {
         if ( need_scrub )
-            scrub_one_page(pg);
+            scrub_one_page(pg, d != current->domain);
         else
             check_one_page(pg);
     }
@@ -2225,7 +2232,7 @@ static void __init cf_check smp_scrub_he
         if ( !mfn_valid(_mfn(mfn)) || !page_state_is(pg, free) )
             continue;
 
-        scrub_one_page(pg);
+        scrub_one_page(pg, true);
     }
 }
 
@@ -2930,7 +2937,7 @@ void unprepare_staticmem_pages(struct pa
         if ( need_scrub )
         {
             /* TODO: asynchronous scrubbing for pages of static memory. */
-            scrub_one_page(pg);
+            scrub_one_page(pg, true);
         }
 
         pg[i].count_info |= PGC_static;
--- /dev/null
+++ b/xen/include/xen/scrub.h
@@ -0,0 +1,24 @@
+#ifndef __XEN_SCRUB_H__
+#define __XEN_SCRUB_H__
+
+#include <xen/const.h>
+
+/* SCRUB_PATTERN needs to be a repeating series of bytes. */
+#ifdef CONFIG_DEBUG
+# define SCRUB_PATTERN       _AC(0xc2c2c2c2c2c2c2c2,ULL)
+#else
+# define SCRUB_PATTERN       _AC(0,ULL)
+#endif
+#define SCRUB_BYTE_PATTERN   (SCRUB_PATTERN & 0xff)
+
+#endif /* __XEN_SCRUB_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */


    
    
    
  


--------------0IFly4YCQMApzFg4B9RmvMse--


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 13:36:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 13:36:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010937.1389188 (Exim 4.92)
	(envelope-from )
	id 1uOz9M-0005Ok-83; Tue, 10 Jun 2025 13:36:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010937.1389188; Tue, 10 Jun 2025 13:36: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 1uOz9M-0005Od-5J; Tue, 10 Jun 2025 13:36:24 +0000
Received: by outflank-mailman (input) for mailman id 1010937;
 Tue, 10 Jun 2025 13:36: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 1uOz9L-0005OX-DW
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 13:36:23 +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 e4f1d5c4-45ff-11f0-a306-13f23c93f187;
 Tue, 10 Jun 2025 15:36:21 +0200 (CEST)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-450cfb6a794so35436055e9.1
 for ; Tue, 10 Jun 2025 06:36:21 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-452730c747dsm142209705e9.31.2025.06.10.06.36.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 06:36:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e4f1d5c4-45ff-11f0-a306-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749562580; x=1750167380; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=SDc6edZ/0ZDSzo+ysXzu+qN2+U9pkk+T+u8rLZm76Zg=;
        b=YNSQVs/5YFOGyhJ7o+qemq7x6qwDSzByyTSpuwgnNgk7ynLOc5EO8z2zpFa6RmBCRc
         /r2BpCrSUr16MwIHef9iPSBPU+bo7GGNbViqO3OdUH9LCoUtlufVWO75r/Ik+DEFucKY
         WHq+Cu0eQWIYQDd8eEsmnuD7argq1LY9EJp6w5cXPVEBoJ7tMKhHmAQAcQhArEVUvLn+
         RUva2YX5zpDTHvWrjP7udfOJ/fMzlNUsBGW5iNaqq58GkcahRZgvqVW2nUsvOQ3CQmb3
         TOXSMrT1JF4/H43UiL4LFTVaFHe+uhDXe61l+XJanvxvozuxlgS+/gqDS3Hxd4JhVgID
         6HsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749562580; x=1750167380;
        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=SDc6edZ/0ZDSzo+ysXzu+qN2+U9pkk+T+u8rLZm76Zg=;
        b=CrlDcEOs2mW36RRm2pL+cIrbkJQrMSHb79oFJziHkOKHH2EuTV45jdV+jVIIk+Gaik
         bFzN4kQ/l/TDh2T9NZukOQSKEuO9ozZzspesbt+9TXO+UJR6rkpeBCw+c4ydnI3c2hNm
         PBDzIRCaaeVwpUYQ/0StKxkMLeUvx02qH815Sj1nU3Z6yxKP860is6qvQ09+ctbR9mM5
         wPptKCYsWmQJYuHLMSoDGDGtTRrBqI5bERj7kVQbEYF1pzUl4Pi1rPh+eTJwHm/L0LVa
         SO+e2+Gam509QzUoK5WZb7AtxxRdJensRel/xk4HFgXhEhmr4P/vSf2Y8lTYiQcWKT83
         cPsw==
X-Forwarded-Encrypted: i=1; AJvYcCX3s1hG/MKeuNcHuXlqo7PmOLKLmGdW+x87JWu/8fVyrKGfmlThkC/vx3moTCne4cydKOIjDux81hU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxEs6PZzS8NtNSq1bcmwEPAAovKOlAM+U1pa8m9aFkxCpCwVnul
	OP250lHDrdG+2FxvKWbKV1aSt5urAUDgFofPLcojAvTO4dsi29MeOcpRHHub41z6qA==
X-Gm-Gg: ASbGncsm2z4RNTlF5QCICW77HO3CqnaF05miukIOjMpibIoeFtQ41cm6wcDHi8kY02t
	6GmLUZyXanNps16h4Yv1koAozFYRoYFC8QRBuZqxS+rJwzaE8n5VpMCuVCFZWbX+1K4XphH6t6d
	+eEWE13cmsCB0nzNNEXakczW3pb/TA+opalWaazSdwsAMNKAp3dDsIxNYLJJ1ot5GmxstpofYM1
	pOjRk0URA02zL0eUR2FA5q+M3Di1N/ojgCFepw/TcCagm/2PlrcS5gQ9JTgTszDZCe07Mq3nbEM
	HJRp0JI+KXO/RzDxuh/qQ2J0LY9CRszleJNEQDsdKICYQ5tUgFXVaoSQYzDk8H9RFjGApFBVprB
	fmnJvRaylpvyTdSCjASbcoFViqmhIHrmg+oTeMQtBznezpituI3/Hyg8KTIFqPMeoHxlcgHRMrL
	v8xo17d2ccy+1+/K+ICf8X
X-Google-Smtp-Source: AGHT+IEP101sT+jxIgMU+htN2retiEVArRJKQFf6YF9j4SYC8mf82NqNVSdqZ7l3nRGmMltuvAEirA==
X-Received: by 2002:a05:600c:444c:b0:451:edc8:7806 with SMTP id 5b1f17b1804b1-4531dea653emr21603115e9.32.1749562580335;
        Tue, 10 Jun 2025 06:36:20 -0700 (PDT)
Message-ID: <8226eeb6-1b19-41cf-9ffd-6440c1641e07@suse.com>
Date: Tue, 10 Jun 2025 15:36:18 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 00/20] xen: introduce CONFIG_SYSCTL
To: Penny Zheng 
Cc: ray.huang@amd.com, Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 "Daniel P. Smith" ,
 Dario Faggioli , Juergen Gross ,
 George Dunlap ,
 Nathan Studer ,
 Stewart Hildebrand ,
 Bertrand Marquis ,
 Volodymyr Babchuk ,
 Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Oleksii Kurochko ,
 xen-devel@lists.xenproject.org, xen-devel@dornerworks.com
References: <20250528091708.390767-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: <20250528091708.390767-1-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 28.05.2025 11:16, Penny Zheng wrote:
> It can be beneficial for some dom0less systems to further reduce Xen footprint
> via disabling 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:
> - sysctl
> - domctl
> - hvm
> - physdev
> - platform
> 
> This patch serie is only focusing on introducing CONFIG_SYSCTL. Different
> options will be covered in different patch serie.
> 
> Features, like LIVEPATCH, Overlay DTB, which fully rely on sysctl op, will
> be wrapped with CONFIG_SYSCTL, to reduce Xen footprint as much as possible.
> 
> It is based on Stefano Stabellini's commit "xen: introduce kconfig options to
> disable hypercalls"(
> https://lore.kernel.org/xen-devel/20241219092917.3006174-1-Sergiy_Kibrik@epam.com)

"Based on" can have two meanings - another series is a prereq, or your work
is derived from earlier work. Would be nice to be unambiguous, as in the
former case it would be unclear at what point (parts of) this series can go
in. You also will want to see about chasing acks for some of the patches
which are otherwise ready (or perhaps merely depend on a final version of
patch 04).

Jan

> Penny Zheng (18):
>   xen/pmstat: consolidate code into pmstat.c
>   xen: make avail_domheap_pages() inlined into get_outstanding_claims()
>   xen/x86: remove "depends on !PV_SHIM_EXCLUSIVE"
>   xen/xsm: wrap around xsm_sysctl with CONFIG_SYSCTL
>   xen/sysctl: wrap around XEN_SYSCTL_readconsole
>   xen/sysctl: make CONFIG_TRACEBUFFER depend on CONFIG_SYSCTL
>   xen/sysctl: wrap around XEN_SYSCTL_sched_id
>   xen/sysctl: wrap around XEN_SYSCTL_perfc_op
>   xen/sysctl: wrap around XEN_SYSCTL_lockprof_op
>   xen/pmstat: introduce CONFIG_PM_OP
>   xen/sysctl: introduce CONFIG_PM_STATS
>   xen/sysctl: wrap around XEN_SYSCTL_page_offline_op
>   xen/sysctl: wrap around XEN_SYSCTL_cpupool_op
>   xen/sysctl: wrap around XEN_SYSCTL_scheduler_op
>   xen/sysctl: wrap around XEN_SYSCTL_physinfo
>   xen/sysctl: make CONFIG_COVERAGE depend on CONFIG_SYSCTL
>   xen/sysctl: make CONFIG_LIVEPATCH depend on CONFIG_SYSCTL
>   xen/sysctl: wrap around arch-specific arch_do_sysctl
> 
> Stefano Stabellini (2):
>   xen: introduce CONFIG_SYSCTL
>   xen/sysctl: wrap around sysctl hypercall
> 
>  xen/Kconfig.debug                            |   2 +-
>  xen/arch/arm/Kconfig                         |   1 +
>  xen/arch/arm/Makefile                        |   2 +-
>  xen/arch/riscv/stubs.c                       |   2 +
>  xen/arch/x86/Kconfig                         |   6 +-
>  xen/arch/x86/Makefile                        |   2 +-
>  xen/arch/x86/acpi/cpu_idle.c                 |   2 +
>  xen/arch/x86/acpi/cpufreq/hwp.c              |   6 +
>  xen/arch/x86/acpi/cpufreq/powernow.c         |   4 +
>  xen/arch/x86/configs/pvshim_defconfig        |   6 +
>  xen/arch/x86/hvm/Kconfig                     |   1 -
>  xen/arch/x86/psr.c                           |  18 +
>  xen/common/Kconfig                           |  29 +-
>  xen/common/Makefile                          |   2 +-
>  xen/common/page_alloc.c                      |  55 +-
>  xen/common/perfc.c                           |   2 +
>  xen/common/sched/arinc653.c                  |   6 +
>  xen/common/sched/core.c                      |   4 +
>  xen/common/sched/cpupool.c                   |   8 +
>  xen/common/sched/credit.c                    |   4 +
>  xen/common/sched/credit2.c                   |   4 +
>  xen/common/sched/private.h                   |   4 +
>  xen/common/spinlock.c                        |   2 +
>  xen/common/sysctl.c                          |   4 +-
>  xen/drivers/acpi/Makefile                    |   3 +-
>  xen/drivers/acpi/pm-op.c                     | 397 +++++++++++++
>  xen/drivers/acpi/pmstat.c                    | 559 ++++++-------------
>  xen/drivers/char/console.c                   |   2 +
>  xen/drivers/cpufreq/cpufreq.c                |  31 +
>  xen/drivers/cpufreq/cpufreq_misc_governors.c |   2 +
>  xen/drivers/cpufreq/cpufreq_ondemand.c       |   2 +
>  xen/drivers/cpufreq/utility.c                | 204 -------
>  xen/drivers/video/Kconfig                    |   4 +-
>  xen/include/acpi/cpufreq/cpufreq.h           |   5 -
>  xen/include/acpi/cpufreq/processor_perf.h    |  14 +-
>  xen/include/hypercall-defs.c                 |   8 +-
>  xen/include/xen/mm.h                         |   1 -
>  xen/include/xsm/xsm.h                        |  18 +
>  xen/xsm/dummy.c                              |   6 +
>  xen/xsm/flask/hooks.c                        |  14 +
>  40 files changed, 798 insertions(+), 648 deletions(-)
>  create mode 100644 xen/drivers/acpi/pm-op.c
> 



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 13:41:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 13:41:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010947.1389198 (Exim 4.92)
	(envelope-from )
	id 1uOzDr-00077A-Qv; Tue, 10 Jun 2025 13:41:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010947.1389198; Tue, 10 Jun 2025 13:41: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 1uOzDr-000773-OP; Tue, 10 Jun 2025 13:41:03 +0000
Received: by outflank-mailman (input) for mailman id 1010947;
 Tue, 10 Jun 2025 13:41: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 1uOzDq-00074Y-AI
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 13:41:02 +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 8bd43c4b-4600-11f0-a306-13f23c93f187;
 Tue, 10 Jun 2025 15:41:01 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-450dd065828so37236615e9.2
 for ; Tue, 10 Jun 2025 06:41:01 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4532056486dsm9682605e9.1.2025.06.10.06.40.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 06:41:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8bd43c4b-4600-11f0-a306-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749562860; x=1750167660; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=MqFVYAcS2M41HQy6xFO9URHQlES9SLIDFSW476QpFTg=;
        b=K46xTP5mvyZsUCkPQx8fjJEpXcst9IuFpxyHsyiDvMM/xrcIAm+IswzgZHzJRsLiHO
         8//2B3UY+S0ixyJjPkliVilo4SyDiDtfXMq1ofZ9DabfpfjJvwseVLiTVSvd11V2OCWA
         iTs/Mf/gkzvSsEErAF/BpeDgaIy7zWP5Ape9+hw26Eq1M6BQENEDQFnBQJIdE+MyBPIQ
         bhtUCcKt2fU0LSBPcFba/Y6ge9SM+Z6vs7rmpF1NhbNKp2uohY1ciAx1ineHyIEwzODZ
         yo0zfE0mSkX8DoBqeAea1y8SN2FgnD3usQJeivv1rLIdMdwqOsmG5nkfFPo0l6u1Ed7c
         n5Bw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749562860; x=1750167660;
        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=MqFVYAcS2M41HQy6xFO9URHQlES9SLIDFSW476QpFTg=;
        b=M/HFtGfmDzcgqnonIn+uyXSwDFAnVQFWG5pfFL4Z/35nTXTBdePF4Vwnw2NEVpOFy1
         B5lnyZ+Wj9g5zbsh/SF9ZDKOALfp8j0qRLasaf6nXmn7cHULxk1xPl1QWn+Tsh1gvnj6
         46I8y95vxAYYIUeOSXBXiLFVvTU2dnL7pSOgUgHHn35wDz095KgkLomh28rDOsNn0S1q
         JOiuqID1uv/QKL+zEVrvBRpo7vRwkZmAimSJdsH5a4cOraaoEhdF6JMBG5/4QdzU4vc2
         Rq3TY5Fgu3+Kd2qWCqYXtxbOeW/YpToVosXKRGS7tanygShipwlxBz7E5RNx47+LdNC0
         lZ+A==
X-Forwarded-Encrypted: i=1; AJvYcCVXJUtIlh0lWfMOzzdgqYPvnf/YzFoHLskhD0xDTgyIwUiFOCJiquh182XCpRAmXOMSj/xxLB1TDb4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwNrvG1G/YL/n7WJAfsVj5NNUuI/M2bNFrN1ENZNLbhCX69nkE/
	vKOl9EYufunwhQ4rs2KHGrXfXU8eEL8CclOSNrTN494lg2v//ZQR0oxShEDfaFnYiA==
X-Gm-Gg: ASbGncuFcPL6G/O5Tmv9ML9lqlsf+BujDRcaUm65zeY+cd7FcvO0ka8XSQBWeZsPnS4
	T6bV5UiLctYMDtatK3urVylr0hwy00ulJMSvQazicctNG6PX0/u20V8lj2DS87JwN6wA9OPadIQ
	KYEQU+Iv4BA0nORAhbY9y5xFn/lqGOpH2eBsSMCIjYa1pkCi/uBoxlGiw44a/KwS6QqlMzq/fkk
	NasC8HQTTDLxuh9U1TABk6r2ONpW7JXyl6fiqcUK0rL/gasMPxSJDPTcJYv50UPmWPpnq1Ul+bn
	ZbtYyyagwlXw9N5XVLEgbClAREelVWxzRG1uHmFmR1wNADh+EMm1VK7WJEGEzKcbu8ap94fpzo5
	ZtFKMIzPJ1m3UcWVfRU/33N27tad9MgAtLiiRw/SSM63xVxv0pbwBIiaqQwQAZTvixfIjKZ5yHC
	pACk7buIxpsVU5UGt74QiI
X-Google-Smtp-Source: AGHT+IHgxmAsnk5KJYrw2CprFMwqJIpMudpEzpie9yOj31Y9bGJb6edNrDez+n5mSnP98W2jUB9qbQ==
X-Received: by 2002:a05:600c:1c99:b0:44a:b793:9e4f with SMTP id 5b1f17b1804b1-4520143724fmr132064875e9.19.1749562860404;
        Tue, 10 Jun 2025 06:41:00 -0700 (PDT)
Message-ID: <1a660f83-5d9a-402b-af28-ea82311b37ce@suse.com>
Date: Tue, 10 Jun 2025 15:40:59 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 11/20] xen/pmstat: introduce CONFIG_PM_OP
To: Penny Zheng 
Cc: ray.huang@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
 <20250528091708.390767-12-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: <20250528091708.390767-12-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 28.05.2025 11:16, Penny Zheng wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -591,4 +591,11 @@ config SYSCTL
>  	  to reduce Xen footprint.
>  endmenu
>  
> +config PM_OP
> +	bool "Enable Performance Management Operation"
> +	depends on ACPI && HAS_CPUFREQ && SYSCTL
> +	default y
> +	help
> +	  This option shall enable userspace performance management control
> +	  to do power/performance analyzing and tuning.
>  endmenu

Why is this being added outside of the "Supported hypercall interfaces"
menu? (No matter where it's added, please make sure there's a separating
blank line ahdead of the subsequent "endmenu".)

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 13:42:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 13:42:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010954.1389209 (Exim 4.92)
	(envelope-from )
	id 1uOzEv-0007nS-57; Tue, 10 Jun 2025 13:42:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010954.1389209; Tue, 10 Jun 2025 13:42:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uOzEv-0007nL-15; Tue, 10 Jun 2025 13:42:09 +0000
Received: by outflank-mailman (input) for mailman id 1010954;
 Tue, 10 Jun 2025 13:42: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 1uOzEt-0007n7-7V
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 13:42:07 +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 b1b95d7c-4600-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 15:42:04 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a5257748e1so3700262f8f.2
 for ; Tue, 10 Jun 2025 06:42:04 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a5323b59d0sm12472992f8f.38.2025.06.10.06.42.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 06:42:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b1b95d7c-4600-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749562924; x=1750167724; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=fhDeyK19gibeZGsY9trGql/r1sfwOYt4mnYHfG14W+k=;
        b=CJNlo9BIeQTqMbGXHF3BHhzEZk4j/SP1u5vRa8ndLRoYe54A6uiL5uKug8yxTcH06j
         RJ+QHfCLB8Q8JHpZtXjKpL88NCWZJj/taY02NHuKM92qVtinE6RaHRV21N8QbVjXYw44
         LcrqDE23/6MKXrU2dbgRtFdUEd7rJcm8FbptOzCpg/mgsd90lzViThK8osCaZyu2fPOr
         vyd4QVLFvlQlBcNWE4X3w2IysU10eSWM9c9FNSxTkY1euqWXuQWUN3FxeWb/kkgRyYEg
         ZkbapltwNjs2ogW0laj3MCRREqIa8FkpfZ3CCXZ7Qj2/R4aubAXXMiMj2fbezX9Sd/66
         ixqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749562924; x=1750167724;
        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=fhDeyK19gibeZGsY9trGql/r1sfwOYt4mnYHfG14W+k=;
        b=N3ZU1lWpLNxo1zknGL0EM9fSmCjOtO/HpynUs4Rm7ciFDQ1PXdtSvcqdHHcMthYdSe
         HzSsdNJ4BnaKih2unU6tE45dS5nHTX7zgtYJWturC6Ft9I5Vfy/Lw344q6DckeYwhh6Z
         JUai9NrLygCgHYwzxiqgMG3/9fkbDN1+UtX5N+SM5HGvjq2y30ciPwN+Xhhxel9j/1KU
         V9PIXprhtKJw1WOLO2ihPyAQroyhm/Ji9yPCjlGh/ixQUqmLP93B1nbie98iVccZ2ghR
         BvlpysBFOeI0OaiVFOziNXBR8nFkQD84et4uwJyhlVyplBGHYU3WsVt96zHMmnipvf3j
         cOTA==
X-Forwarded-Encrypted: i=1; AJvYcCWePjgdNaSQkUdpkjHY5T7VA6SWf4Djc/L4TeYKYxwT6uycZB7BoJc0OMe7BO+yyS96PcdH7xblc1A=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwHvu1QWSzdMjqWZ5XmD0KEHpMmBVo0hzsbnfNhFMRCAfn8lhbp
	VcmFCkLkvKmOkIyhAi/HT7NPHabak+cwTu3GmgBF1eb/oTUkHZPSaQyG1DYv15lRtA==
X-Gm-Gg: ASbGnctTKdg9el7lDLT6KsW00213kzuV2nncSRKpIuTPEnfG/r20rH9c3d/ykDCfp8W
	2f/dR+zlFbvL7YqhqvWBM9kpXjnz+6ryf2piuaTHWYNOQaaoLCJk/ovRaLkTbVMjXkVjVGay2RI
	gkjmovIuNeCfZScGoWZMwYScnssTMXyLYwrgO/7e+e75V19ici+d3FmGGfSBbekwPsDS7wIhQwt
	u91GqaK7KGOZlbBeEUXhyZ2TgPeUo3lQ2ThhwoIK9xWvZA3kHlEMLPQTS41iNv3Wlq1yZqHLajq
	esNt2mK6gky2tLl/kLB7BecCphW02oY3YJmA2UnDeZB035FQf/5KE75xsOZMellSPbx+RHXDOeu
	biy9IipoVxv6PWTsFq6r5LtgxnyS+ksQ1lD4zVvIkuYPZ+aKqnfsoCDDjypwso7KaEMib02wcKc
	SX8EePe8Vm0krolTU8HdaJ
X-Google-Smtp-Source: AGHT+IGEpLzt4qYukVYjaURPxBZ+KCw+RaHKM9w3Z+4jnT/vUdTFviAbrYTNYJEk53mgBYk0zEgqcQ==
X-Received: by 2002:a05:6000:40c9:b0:3a4:f6ba:51da with SMTP id ffacd0b85a97d-3a531786845mr14202400f8f.15.1749562924086;
        Tue, 10 Jun 2025 06:42:04 -0700 (PDT)
Message-ID: 
Date: Tue, 10 Jun 2025 15:42:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 12/20] xen/sysctl: introduce CONFIG_PM_STATS
To: Penny Zheng 
Cc: ray.huang@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
 <20250528091708.390767-13-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: <20250528091708.390767-13-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 28.05.2025 11:17, Penny Zheng wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -598,4 +598,12 @@ config PM_OP
>  	help
>  	  This option shall enable userspace performance management control
>  	  to do power/performance analyzing and tuning.
> +
> +config PM_STATS
> +	bool "Enable Performance Management Statistics"
> +	depends on ACPI && HAS_CPUFREQ && SYSCTL
> +	default y
> +	help
> +	  Enable collection of performance management statistics to aid in
> +	  analyzing and tuning power/performance characteristics of the system
>  endmenu

Same comments here as on the previous patch.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 13:47:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 13:47:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010962.1389219 (Exim 4.92)
	(envelope-from )
	id 1uOzKJ-0001OT-KN; Tue, 10 Jun 2025 13:47:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010962.1389219; Tue, 10 Jun 2025 13:47: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 1uOzKJ-0001OM-HC; Tue, 10 Jun 2025 13:47:43 +0000
Received: by outflank-mailman (input) for mailman id 1010962;
 Tue, 10 Jun 2025 13:47: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 1uOzKI-0001OG-1j
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 13:47:42 +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 798239b4-4601-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 15:47:39 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-450cb2ddd46so33047555e9.2
 for ; Tue, 10 Jun 2025 06:47:39 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-452f8f011c8sm138911695e9.3.2025.06.10.06.47.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 06:47:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 798239b4-4601-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749563259; x=1750168059; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=KrUvU1/a7/BiL6lFTe73Dy6Jg+5VeOIm2pPS/npSqrQ=;
        b=KqO9u9WisrpJZIDHPZYwrxku4gqeMiPlzfaQlUhkp/WWaiNH2DIj02RIzXB05fixD2
         Aqf9CishSqX9hRvuXh1LE36h1jlGsVK7+ZCG6xl7MAAJDhFmvRf+rCxSsfslv2Uu+gKG
         YKoY/MWmBymjO4hhR5ISMqk3Itk9y4l2tpr9HuaY7HyzgJsAy7VN+gJo4AIZetSOHSxH
         mYPBwDsVt2FgHu27y7z0wp096iq9nTUg1H06zsfxtVItR5g2Ue92U9ZtWP5/pUZjYgk3
         C65kr4YpFqqScSrkqVfbo5ZlBhlJxs/YgPjO7FOM7JHp/eH+tKj5D2L6nUTm+TDqKJj0
         N0CA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749563259; x=1750168059;
        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=KrUvU1/a7/BiL6lFTe73Dy6Jg+5VeOIm2pPS/npSqrQ=;
        b=A+2ReAvJIY+OkaXz2EQ6d0OiDSKrWUv0jGex8aX34Mfl8Vwq5+8Vi5ZJ7WEAJOeMBJ
         qdVtMCHk5vLExcndG+zzEIV06l2NxWRod15x9G8ZbpuQVEoJdMqcF5gjxJYWUcKRD6AZ
         8AMQQJe9YXY3/WJoGgyVRZqXimgknrKTsNcb+heTNiFxLfk9LALBOq6pWMGq7hr9uSHX
         z/zzaIKzeLm9JmGK8qadgedKOxvKOiAMDFIt6hOGJqCOvC1TnlKu/S3rswyZfPnzD/35
         QgrGXFpjyScOHVvbWY5wrKAH+ECzBMxkOse5pVTUie6pyRXyP63VycPzxkFVhYaNEg+e
         NOvg==
X-Forwarded-Encrypted: i=1; AJvYcCXKyuyKs6/mAof80fJN77yMUDbnHCXEOb29eLZOZR/0blq9ZHXlO42554+GFq8CRovGRHVJ6OlcWIg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx7NGZubv96KEWCOnw6N8bgWcEbVh/OB/mKezS3nGXe74Mle6IM
	fM33fOsaO6liKO2xRQXE4hqVKDGwkzCfX9CW3vwNrppScjp5IA3YnmNWzyezas5Xjw==
X-Gm-Gg: ASbGnctJgov6hyQRJ+Tpm7sBl7+3ZcpbHBXPM+PMTWXr57ZfDn5m0IjfLmu7yJbGqd9
	gWo8tZuvaeQ8rYdzRocSPNAdShDkxExTpv9MBgL0jCAnkyoBonVT6JERGvnggAsWgqS9pAT0Aym
	gWAIRfFMclrw9Rqu2moqY/MNEPnFK4UCFBt2lmDYdP8MArJy50fl+LcWch1vZ7ktxouBh26QlbF
	XMI+C33NOnn2iBy93o16W9CkjkeKrhQ+mTmdWCmXT2bVo3vRYRke1hJhDJw0bNFXci7IJcJ6PBq
	5TGO4GtMlris0oB5XtpOhS1NBuu0HjhSUMHvT43sHRQgKl9nh/M/Pqb3esefFlc9TbWgj20BK5u
	E+xfSXzwiq0Kr9xCVxOzQwAmqJoeYaLs/V5L1YsMP0bMXxrm3LNvR2zbX5R0+N3h/9N5Jk4volm
	J/C/4B63IVcIwfFTVWU9De
X-Google-Smtp-Source: AGHT+IET+108RstG7HFcII0VNyG2xCId9F7r3QS4hHGMgYf6p8h4pjeBvZLoGdA2xqR3QEYBssD6mA==
X-Received: by 2002:a05:600c:a10c:b0:442:c993:6f94 with SMTP id 5b1f17b1804b1-4531de00a37mr22533885e9.12.1749563259284;
        Tue, 10 Jun 2025 06:47:39 -0700 (PDT)
Message-ID: <9db2daa0-8905-4b21-8161-27b7fb96dfef@suse.com>
Date: Tue, 10 Jun 2025 15:47:38 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 17/20] xen/sysctl: make CONFIG_COVERAGE depend on
 CONFIG_SYSCTL
To: Penny Zheng 
Cc: ray.huang@amd.com, Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
 <20250528091708.390767-18-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: <20250528091708.390767-18-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 28.05.2025 11:17, Penny Zheng wrote:
> All coverage-related op shall be wrapped around with CONFIG_SYSCTL,
> so we shall make CONFIG_COVERAGE depend on CONFIG_SYSCTL.
> 
> Signed-off-by: Penny Zheng 
> Reviewed-by: Stefano Stabellini 
> ---
> v1 -> v2:
> - commit message refactor
> ---
> v3 -> v4:
> - commit message refactor

Despite these efforts the description still fails to say _why_ the
supposed wrapping is needed. And "supposed" because I can't really
see any wrapping. All you do is add a dependency.

And btw ...

> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -37,7 +37,7 @@ config SELF_TESTS
>  
>  config COVERAGE
>  	bool "Code coverage support"
> -	depends on !LIVEPATCH
> +	depends on !LIVEPATCH && SYSCTL

... "depends on SYSCTL && !LIVEPATCH" would feel more naturally to
me.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 13:49:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 13:49:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010968.1389228 (Exim 4.92)
	(envelope-from )
	id 1uOzLq-0001td-U8; Tue, 10 Jun 2025 13:49:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010968.1389228; Tue, 10 Jun 2025 13: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 1uOzLq-0001tW-Re; Tue, 10 Jun 2025 13:49:18 +0000
Received: by outflank-mailman (input) for mailman id 1010968;
 Tue, 10 Jun 2025 13:49: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 1uOzLq-0001tL-HB
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 13:49:18 +0000
Received: from fhigh-b7-smtp.messagingengine.com
 (fhigh-b7-smtp.messagingengine.com [202.12.124.158])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b0e14173-4601-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 15:49:13 +0200 (CEST)
Received: from phl-compute-02.internal (phl-compute-02.phl.internal
 [10.202.2.42])
 by mailfhigh.stl.internal (Postfix) with ESMTP id E56042540108;
 Tue, 10 Jun 2025 09:49:11 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-02.internal (MEProxy); Tue, 10 Jun 2025 09:49:12 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 10 Jun 2025 09:49:10 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b0e14173-4601-11f0-b894-0df219b8e170
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=1749563351;
	 x=1749649751; bh=Bx0FUwl99RzMl79cCwMd39gQYljvINpdxyewwdtObUc=; b=
	BGD2TPDEXDGvnHAfPFleIIPVdX9t9/hzzAtkVJ5eyFCRAEG7xuIgE49aknoXYFb3
	fppUKFiZsM+rVoWEWd4hj3h+UKD7Q1zuTNRECkGx8OSHJ51AWFqL/987pmOEEUrG
	SoauxnenvwfaiFBKHnFeemT9w4Rz1COPBNApM4vh9ga7sSYnFjXsD3bfHE6ONFJn
	GkQu42mx6Bs+/xwhiP7eT3d60nKY9UkaZ9GtYLUzyQi/27goBaCaaR3v2YciDy0h
	tPswEKwGu4mJyFN5oPhA5fWgVn4cb/Vd+kQ4Fv+rZHXDxRzAL+fR96oeF91i1Hez
	wGZM3GhyKKw8IJilgHYozg==
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=
	1749563351; x=1749649751; bh=Bx0FUwl99RzMl79cCwMd39gQYljvINpdxye
	wwdtObUc=; b=KJQWG9mcHQRk/OwbOUWN+wVbbW1ujgbHB4iQTi5Cxc0dYgVqRAA
	29Q8LfF34GFUAC/7YriJsSM7YYsO12zaGiVrCBVciPBtUzTEApTuDNF9fm25Aoy6
	dqe7Wfqv5gHrACnaTON5LmImS49AcJxsv9L97safjBwMG2gu652eAc/sL4xaEiiV
	cfYDCGsaifaTIJENJQnVjBSWPEJ11IqRNvAmFYvAd9gAN9KfdZdAdN6Gulx1gVNB
	h1efdXGyIjjXTXcgX3Xp6LgAiFfdj4cyF7FdBrZBIjOUF++DWt/zOylx5EASWnS0
	uf8PxOAQRD4M5lye9d9ats/KzmwZgsHBjmQ==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugddutdekvdcutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp
    uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg
    hnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehgtderredttdej
    necuhfhrohhmpeforghrvghkucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoe
    hmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucgg
    tffrrghtthgvrhhnpeeileduvdekjeeukefhffetgeefiefffeejjedvieejvdfgjeehte
    duvdekffduieenucffohhmrghinhepkhgvrhhnvghlrdhorhhgnecuvehluhhsthgvrhfu
    ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhvih
    hsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepkedpmhhouggv
    pehsmhhtphhouhhtpdhrtghpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtghomhdprh
    gtphhtthhopegrnhgurhgvfidrtghoohhpvghrfeestghithhrihigrdgtohhmpdhrtghp
    thhtoheprghnthhhohhnhidrphgvrhgrrhgusehvrghtvghsrdhtvggthhdprhgtphhtth
    hopehmihgthhgrlhdrohhriigvlhesrghmugdrtghomhdprhgtphhtthhopehjuhhlihgv
    nhesgigvnhdrohhrghdprhgtphhtthhopehrohhgvghrrdhprghusegtihhtrhhigidrtg
    homhdprhgtphhtthhopehsshhtrggsvghllhhinhhisehkvghrnhgvlhdrohhrghdprhgt
    phhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrgh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Tue, 10 Jun 2025 15:49:08 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Jan Beulich 
Cc: Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v1 5/5] console: support multiple serial console
 simultaneously
Message-ID: 
References: 
 <98ff383ff2ee3dc162b2d12afaea2b3f1406d99e.1748182535.git-series.marmarek@invisiblethingslab.com>
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="9KaVgZv5yGFTqEhj"
Content-Disposition: inline
In-Reply-To: 


--9KaVgZv5yGFTqEhj
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 10 Jun 2025 15:49:08 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Jan Beulich 
Cc: Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v1 5/5] console: support multiple serial console
 simultaneously

On Tue, Jun 10, 2025 at 02:48:54PM +0200, Jan Beulich wrote:
> On 25.05.2025 16:15, Marek Marczykowski-G=C3=B3recki wrote:
> > Previously only one serial console was supported at the same time. Using
> > console=3Dcom1,dbgp,vga silently ignored all but last serial console (in
> > this case: only dbgp and vga were active).
> >=20
> > Fix this by storing not a single sercon_handle, but an array of them, up
> > to MAX_SERCONS entries. The value of MAX_SERCONS can be chosen in
> > kconfig, the default (4) is arbitrary, inspired by the number of
> > SERHND_IDX values.
> >=20
> > Make console_steal() aware of multiple consoles too. It can now either
> > steal output from specific console (for gdbstub), or from all of them at
> > once (for console suspend).
> >=20
> > Signed-off-by: Marek Marczykowski-G=C3=B3recki 
> > ---
> > This was posted before as part of initial xhci console submission, it
> > reached v6 (but last changes were in v4), but wasn't considered useful
> > enough to review/ack:
> > https://lore.kernel.org/xen-devel/Yu0XHUhsebE+WG0g@mail-itl/
> >=20
> > Since I needed this feature again, to debug xhci console issue, I'm
> > including this patch again in the series.
>=20
> Beyond this narrow aspect, has anything changed in the picture, compared
> to what was said / discussed earlier on?

Not really. It's still quite useful for people doing console drivers
debugging and have the luxury of having many options at the same time.
For me it's xhci, but it could be useful also for debugging other
drivers (outside of x86 too). And it's still not very useful for anybody
else.

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

--9KaVgZv5yGFTqEhj
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmhIN9QACgkQ24/THMrX
1yxlZgf7Bm4HqeqtUWNtK+kGyetDUvfI0/l7AKgJoun+pbiF/UEVqipHqc62V8kv
QGrom1xdU19KMccG8RkkbfgO3DzuUlbUnllrwsGYqXzN+IUK36czVC0lUf/8ZL50
KovPtJj28PEfpUj88afpW7DjpEuE3T8uZC81tVrLVXkvjCRY6E9Pf3KsuexwlS0h
9CgYui1AOjxYGn2xgnJi9l2hqtytIP0WXyXqLUC2A/QNK5ANGQD16fT9qm77Sa1p
743g46K04iTwIcwzTtGJ23/AxS0prgVjaoHf2v3TM0zy4Dt5FA6XimNS0G08w1Dp
rkO3l+3+DCfT18/b4Bqn0YwlfHgOQw==
=7/9b
-----END PGP SIGNATURE-----

--9KaVgZv5yGFTqEhj--


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 13:53:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 13:53:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010978.1389239 (Exim 4.92)
	(envelope-from )
	id 1uOzPW-0004Xm-Fn; Tue, 10 Jun 2025 13:53:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010978.1389239; Tue, 10 Jun 2025 13:53: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 1uOzPW-0004Xf-D2; Tue, 10 Jun 2025 13:53:06 +0000
Received: by outflank-mailman (input) for mailman id 1010978;
 Tue, 10 Jun 2025 13:53: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 1uOzPV-0004XZ-O5
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 13:53:05 +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 3a2fa61b-4602-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 15:53:03 +0200 (CEST)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-451d3f72391so71265285e9.3
 for ; Tue, 10 Jun 2025 06:53:03 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4526e163113sm140988605e9.18.2025.06.10.06.53.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 06:53:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3a2fa61b-4602-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749563582; x=1750168382; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=dlJY4iRlUylEhN7xtuvFFCDc5o5qdJM0UQFUX1ID1TY=;
        b=MKbzkTJK/PBsycYb2Tj+k+jK8gZSqma/yzggjxsWiPfwMH9d9ws5r6k9X1kqLuBzCB
         m5TsinxtfsEsYuEaO88mK7H+r5MiTVRAWXndAvFX9Di1TOUmVVEznqluKbBQh6NTUcMf
         ehyNsMz9IRqXVr7DDykxIWJSnUb1+FWjshQ90tMwFef0Qjv/MKfCL9mzE54DO911hb4Z
         IJsz8ZZgXcUpuWNFLtK4n7E9Sibkk8RUAvPrv8np21T3pTlF7nkANHEZdxTW+fzgKcfy
         wQMzAhA9u2CgFgerNnSoFHIz+XmJhwy8NDw5oR5hSf5ySzjuoNvZivRDRU31B4xZJ5n/
         OvrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749563582; x=1750168382;
        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=dlJY4iRlUylEhN7xtuvFFCDc5o5qdJM0UQFUX1ID1TY=;
        b=VVqUcQdJ0TZY2g6fKyMuLKK0AuAvSK0BaU55mBDQvazS9sOj/eS/PLW/pRKId40EeH
         vCIxC0HppXG90pKtmMoVk9vNVXQzsHnYCUNLZ32KhJJzf2DftSu/8yH9mMm44jG7qc4f
         IqCi2zBxb6TAvCTB7k7COCqAS/BtLDNxwGKFCM9yb54JbZO9GDUa4uPetNqGOX64/aB4
         UsPgAe2WEH8mPYc6H/VEjPuLzFNyTgqPfXYwFQ0k9+bpqX6Er5FBjcouNz7jafk8uM5s
         L12+XkENrdbUgazKvsTiOFhS604n4dPZfz1PCJetxZuur/1noCVt212UdxMHDQlEB1KQ
         M1Pw==
X-Forwarded-Encrypted: i=1; AJvYcCXvXq6uM8lS9E5srkodyT4CSD4M/Ms/l6iGLWARbbSiGMf8WklldMfWMpdRDDSU57Twe0+HR13K5Uo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxPgkFozUEeGNfpZNsZw3yVaJK/Zv2XBkzfGqV+EW9GgMk0AR+w
	PqlTFIf8dlfT45q0aLZNEkwjTVRB3lej3PLq+wIFHLwZZcQeftnzW/M1JZ0wZojtoQ==
X-Gm-Gg: ASbGncvDyqt3z3xr1IoxEdQRyb+FrB0gJAoSdX5wl0GywKOq2838KjaaoLoTEQYLlU1
	dV+omXEyMVSgOxN6uaqepZrHLYBKJmR8m1O2TgrEAadK2aRYCpAhuQAghQRZui1dgnJF9get7ap
	p2t1Ek4Z6pieVeM/Cx+wexEppQy5gITO7XubSgq3u9D+KnQ/wec/Y6tExXxYqLrqqD8fQmEJ6B1
	7gNKpfFMJ5nkB7WwmAFbldQ/dJj7Pv7FEJ/6xqCvRAINYUA7uWlcgnfLeF1dJ0fuG7RUC5zaep4
	ZW2vXDFir11ItqlRzkux5uCA9BwY3TcyqPwmhbZ63x+jQPyPaDMdSIS37osj+ki5xghyvuGjtEl
	kpOlNRXv9ZVl+PZp6bf3ArlzTMVX5J3x2WfMRPJkIMcZrBj8TES+3A3lpb1JPA9+oj5Opn7vY+B
	CtMif5IabdbWmAgCwvF1HP
X-Google-Smtp-Source: AGHT+IGNfnUVAodBZAoWm4dNiFWX5uzrzypnwAIYHO+KUqv0pO9QHQITHVH0NPdufAKuQYOKrK2nZw==
X-Received: by 2002:a05:600c:6210:b0:44a:b7a3:b95f with SMTP id 5b1f17b1804b1-452014d99b7mr139911685e9.25.1749563582498;
        Tue, 10 Jun 2025 06:53:02 -0700 (PDT)
Message-ID: 
Date: Tue, 10 Jun 2025 15:53:01 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 20/20] xen/sysctl: wrap around sysctl hypercall
To: Penny Zheng 
Cc: ray.huang@amd.com, Stefano Stabellini ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini ,
 Sergiy Kibrik , xen-devel@lists.xenproject.org
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
 <20250528091708.390767-21-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: <20250528091708.390767-21-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 28.05.2025 11:17, Penny Zheng wrote:
> From: Stefano Stabellini 
> 
> Wrap sysctl hypercall def and sysctl.o with CONFIG_SYSCTL, and since
> PV_SHIM_EXCLUSIVE needs sorting in the future, we move them out of
> PV_SHIM_EXCLUSIVE condition at the same time.
> 
> We need to make SYSCTL with prompt back and state unsetting SYSCTL in
> pvshim_defconfig to explicitly make it unavailable for PV shim.

I'm struggling with this sentence. but nevertheless it seems pretty
clear that what the latter half of the sentence says is not the effect
of ...

> --- a/xen/arch/x86/configs/pvshim_defconfig
> +++ b/xen/arch/x86/configs/pvshim_defconfig
> @@ -31,3 +31,4 @@ CONFIG_EXPERT=y
>  # HYPERV_HYPERV_GUEST is not set
>  # CONFIG_HVM is not set
>  # CONFIG_VGA is not set
> +# CONFIG_SYSCTL is not set

... this change. The option is still going to be available; it's just
that the preset is "off" now.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 13:55:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 13:55:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010984.1389249 (Exim 4.92)
	(envelope-from )
	id 1uOzRI-00055U-Qy; Tue, 10 Jun 2025 13:54:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010984.1389249; Tue, 10 Jun 2025 13:54: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 1uOzRI-00055N-NH; Tue, 10 Jun 2025 13:54:56 +0000
Received: by outflank-mailman (input) for mailman id 1010984;
 Tue, 10 Jun 2025 13:54: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 1uOzRH-00055B-2o
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 13:54:55 +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 7c6616ec-4602-11f0-a306-13f23c93f187;
 Tue, 10 Jun 2025 15:54:54 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a4f72cba73so4488068f8f.1
 for ; Tue, 10 Jun 2025 06:54:54 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45209ce132csm142404935e9.12.2025.06.10.06.54.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 06:54:53 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7c6616ec-4602-11f0-a306-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749563693; x=1750168493; 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=CfmlorMBGCI3e9/1WMR5uy55JP9PDKEUOiWoLIBq5yI=;
        b=SSSTkDBhm5OhPV1JYGLVWkMiNRr/BTzUzr2vyEVSimgJWcTLRmpSrnaISlA5D5FUWy
         K6+5Bx1qAnyZ7e9OKVZq9ioQzTWgjAuE+3QX0ByhoiRYbrbThBu4hNAl9rCz/aEW+Yk+
         eTLcCf8kkAJ8uNRGUxIeOV2AOJgUeKyvf4tc8MtFCx2UXBhgM5c4vGnBfMLCjbNduiaY
         TyXNt9NXhpEeW0Vka05jE4Yz2Zx0ZxuNQC7Hoqi3yYHUJOwCAK4P/+3rbcutlWogOw1q
         QOxIFACiXFP/6vA/9n3sekrrxRrNJubhEdTlWRaXGP/6YCG4PuWHG57uID13yNV5dern
         5MLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749563693; x=1750168493;
        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=CfmlorMBGCI3e9/1WMR5uy55JP9PDKEUOiWoLIBq5yI=;
        b=kqZkzk8PW+kBViNRNOaD5tiOiVsUa4tljfN2Nk0rupfH0CF779Nj6m9MJO5E6JGoyA
         3Jjgp4eZbl5j6hm1fhM9sYa8M0AdxZkSZCkU2R9iNqAf2W7OoztQndv+7y9Y8AiD9QBo
         Nx9ys4LmNAgjCkVi3L8G7UAGPxGzKPnBbYxQuvNLg2myfFMjaRIrrJtZyP2dOeh9RN9q
         Pr+EZ5x6gQuYNOCz5pOL3Tj6HDFCOaLMJjaYQUpqQowCgtCuiToxZnt2bjqZJ43vMVLz
         8BY0anVF0HP1rZt83DHNGc6BHQXFtHXoVi1VRCf98Xj2mDg4svRZ1l4JkQePXNy0xQ4N
         Iepg==
X-Forwarded-Encrypted: i=1; AJvYcCVWmuJ0o8MC84Oz8ag4faWKroaPR7Fs0WilM2zioENsdbY0npCEkcqWg9DGo8oIJY3SPV5g+IEcOmE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx8MxmNYwmKJz3AWrltNllBmRf+JeymLHxERU9eg//0F1ukBFdg
	KxO8XUzVa/ABBl5rA6KtxuO5tOgilDg1wlcTlYlOqzObYNfZNAub916sigNisCJRRQ==
X-Gm-Gg: ASbGncuIykX3Tl0kMcowmn1ikiPibV7Ec25qwrX/2Tfb/HvtHvQ477KKBCON2sY6o9U
	d5ia1nYQDBIbqLAros+TS9iIIu1ofIl/tz2yr9JPqgoYIsnGPk6UDejQjIDj1Fpu2OqBbktcYdb
	+4GpYNr5wDEtXNqSZ6XoIKvELN1E3AJTjOCtMrVRQ5mv4jmoikZsfYIuod8DGLKmbzVxw2j6LEf
	vFjX1nKxnwptkGnDgbARMD5yxBO0PTYIGP4UCBRQPRypW/MwuhDOrnlgZowWjFY/Nb9fdoWRLsF
	m1ce4C0Qyu7/XCCUdTudREp3GHKT1MC2YsWN5QIR/ltlk/pzlSMHv8ttLt5GzMsUupdzDp0UR2o
	09/zhTo6JT8JFP0LHhKo4cgWqss8QVPjXaHkDC4hmnggggB1zsAFYVppJAuLOlhN9g4i1a+XyyN
	13GcjeUWTL0WGU/JLnnB5x
X-Google-Smtp-Source: AGHT+IGHQt+qzOX56YLMk6PTTA0XAfzGB5UWur8jH+qxDJUtniJ41QbtDmBEOs6jvwZI8NSLMAVkjg==
X-Received: by 2002:a05:6000:2913:b0:3a3:70ab:b274 with SMTP id ffacd0b85a97d-3a5513e84acmr3344834f8f.12.1749563693434;
        Tue, 10 Jun 2025 06:54:53 -0700 (PDT)
Message-ID: 
Date: Tue, 10 Jun 2025 15:54:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 04/20] xen: introduce CONFIG_SYSCTL
From: Jan Beulich 
To: Penny Zheng 
Cc: ray.huang@amd.com, Stefano Stabellini ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Sergiy Kibrik , xen-devel@lists.xenproject.org
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
 <20250528091708.390767-5-Penny.Zheng@amd.com>
 <51fde0e2-abca-43c8-9cfa-734219431970@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: <51fde0e2-abca-43c8-9cfa-734219431970@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.06.2025 15:05, Jan Beulich wrote:
> On 28.05.2025 11:16, Penny Zheng wrote:
>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
>> @@ -579,4 +579,15 @@ config BUDDY_ALLOCATOR_SIZE
>>  	  Amount of memory reserved for the buddy allocator to serve Xen heap,
>>  	  working alongside the colored one.
>>  
>> +menu "Supported hypercall interfaces"
>> +	visible if EXPERT
>> +
>> +config SYSCTL
>> +	bool "Enable sysctl hypercall"
>> +	def_bool y
> 
> Why def_bool when you already have bool on the earlier line?

It took me until the last patch to properly figure what's wrong here.
Whether "def_bool" or "default", neither makes the prompt invisible.
So you want to keep that line but remove the earlier one, for that to
be added in the final patch.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 14:09:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 14:09:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010990.1389259 (Exim 4.92)
	(envelope-from )
	id 1uOzf3-0007Kr-08; Tue, 10 Jun 2025 14:09:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010990.1389259; Tue, 10 Jun 2025 14: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 1uOzf2-0007Kk-TS; Tue, 10 Jun 2025 14:09:08 +0000
Received: by outflank-mailman (input) for mailman id 1010990;
 Tue, 10 Jun 2025 14:09: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 1uOzf1-0007Ke-4r
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 14:09:07 +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 736fbc39-4604-11f0-a307-13f23c93f187;
 Tue, 10 Jun 2025 16:08:58 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3a536ecbf6fso2336721f8f.2
 for ; Tue, 10 Jun 2025 07:08:58 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a532436668sm12592509f8f.54.2025.06.10.07.08.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 07:08:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 736fbc39-4604-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749564537; x=1750169337; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=F9CeBZObUAuzVxn4kdm5rVCoM3RplIXj9ZSWP0CUGk8=;
        b=ECHzlzi11nv54aaazN9HGRtLSLP3mZ2kMHfMU8hbSC8c81FFuUrKqKpXbxgddJw4g7
         Q2cGy0l9QaB5/9E0/kiz98FnYVtC+FT3GflwLpW0Y/6wVXHTaCZ8gdxbQVWQLIhiOgGY
         kTqEehGXMntQVMHHGvTnI8tCrpbFWm8lH0JM8H1w0OcXC06RZIYrqOrIwI8ZG+NuE975
         d/6dMKn/WWbn5oCH0m613bM0Mdgmy5v0PRuWMi00Cq1I0AzphR4+gMtQrg5/QXDC756k
         DpMhv4WzZmVkV3Z6/P+RgM0vwWJQpOSF0o8YUbWvAaiYQi+b5kIbRgO1xScmpYg3kA0W
         FrRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749564537; x=1750169337;
        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=F9CeBZObUAuzVxn4kdm5rVCoM3RplIXj9ZSWP0CUGk8=;
        b=oIogjlv7IQ6b0mvSgorUQveGRZSmy82VdBjOOQtfnfsDUCrXdEAEDDyyt+R3t5I9Vh
         iRPXvOEek4S7GXzUfPSzZ9gtTceJb9kB3QyN9Rv1yiaIC8UBkwk53iG0Ze9GFEk298kP
         0xryAv/A4BfWvDrnYDlksREnpFJub5ipsOgWmfF4OmD5qUyzDqrDrqzgy1L1NvbAtBHQ
         A2HKXoDz1GE3k0BlwEv8ykDKE7m8S/iEKoyUaUiJIGnsYUFL7dT/wkUCfZyGewJLXJjc
         4wqkDlQPNhQ4rwmXn+JsHTgDz8KxWdr6OWsOTBA9wkwraT2Izkrgppou/v/TNReLnbpS
         2UgQ==
X-Forwarded-Encrypted: i=1; AJvYcCVVaXfNhH7G9qL2AF9s/m2oLjWy9tnDCPhG+xj4lyahfo6dHc+FohyaCYf3qPPGurJdG4JJawpGPQ0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzJYpi78PWs/IHKiOq825xkz/h4wFsUZW+MHAu2ck3iv2Q+XVYw
	+Ymg3h0ls9xfzCqbsEFkf1q3x/Z+nFxzi4n9pENw1/x1fwTouAjMLj8usdXbAbM2Bg==
X-Gm-Gg: ASbGncvBsiyTDcTlDXSi6XSe1+1l00kU2dX1f93xYBC6SzxxwXzJFwfCZDphVYWskN3
	hkRKGwM8EaCXEx94H+KjyWQHFUUrvMGxz1xsGkMjCZMjAkjxQNYxdZZOXIzYr7e4aKXCLQmFMot
	utLBp20D/ivUMpEcI9SImvgtA/dJW0lIZYkurRM5rWzY3R2NYM8w03O0EuQTQP+NHBRsoNqNxo/
	JL1Q7XD+Vd06qMpnRtbBzj/uJM3Dp+RLKExx9ql5g6Yv/cykStwnHmiEMVZNbzg838GGuYq00Nh
	4njGwLG03qf701+cLrd0IAzVAt6uaAFZB4scqYXnPiWOh/YxPFgUL+Ph6lfl9x1/TZElt7MhCro
	oyzRpqdt3lmzLyoZAYPRa08Vpu35LkPqyHMG3/2d9pEOX2pltpXJ/u0yJKQ5xovYlJdJjQkhaxU
	bWSI20hpcuDiQ1k4kiMt32
X-Google-Smtp-Source: AGHT+IEsYCHMAKKxb62EDmD0ynVIQ7sEu0G8PUrA/p6Kzs/Zobi2sfZxAvurhyLIICx6Tst5NGqGbg==
X-Received: by 2002:a5d:4447:0:b0:3a5:1cc5:aa6f with SMTP id ffacd0b85a97d-3a55229bddemr1857281f8f.34.1749564537393;
        Tue, 10 Jun 2025 07:08:57 -0700 (PDT)
Message-ID: <6fe24545-1f76-4f3f-84bb-b0f8e225ac7b@suse.com>
Date: Tue, 10 Jun 2025 16:08:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 1/9] xen/riscv: dt_processor_hartid() implementation
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: 
 <751343d295c0fa6a9a7d8f2265ece3faecd44b64.1749121437.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: <751343d295c0fa6a9a7d8f2265ece3faecd44b64.1749121437.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 05.06.2025 17:58, Oleksii Kurochko wrote:
> @@ -14,3 +17,77 @@ void __init smp_prepare_boot_cpu(void)
>      cpumask_set_cpu(0, &cpu_possible_map);
>      cpumask_set_cpu(0, &cpu_online_map);
>  }
> +
> +/**
> + * dt_get_hartid - Get the hartid from a CPU device node
> + *
> + * @cpun: CPU number(logical index) for which device node is required
> + *
> + * Return: The hartid for the CPU node or ~0UL if not found.
> + */
> +static unsigned long dt_get_hartid(const struct dt_device_node *cpun)
> +{
> +    const __be32 *cell;
> +    unsigned int ac;
> +    uint32_t len;
> +    unsigned int max_cells = UINT32_MAX / sizeof(*cell);
> +
> +    ac = dt_n_addr_cells(cpun);
> +    cell = dt_get_property(cpun, "reg", &len);
> +
> +    if (ac > max_cells) {

Besides the (double) style issue, why's this needed? Can't you simply ...

> +        printk("%s: cell count overflow (ac=%u, max=%u)\n", __func__, ac,
> +               max_cells);
> +        return ~0UL;
> +    }
> +
> +    if ( !cell || !ac || ((sizeof(*cell) * ac) > len) )

... write the last part here in a way that there can't be overflow?
ac > len / sizeof(*cell) that is? (Remaining question then is what to
do when len isn't evenly divisible by sizeof(*cell).)

> +        return ~0UL;
> +
> +    return dt_read_number(cell, ac);

What meaning does this have for ac > 2? (As per your checking above
it can be up to UINT32_MAX / 4.)

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 14:13:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 14:13:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1010996.1389268 (Exim 4.92)
	(envelope-from )
	id 1uOzjV-0001X4-Gl; Tue, 10 Jun 2025 14:13:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1010996.1389268; Tue, 10 Jun 2025 14:13: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 1uOzjV-0001Wx-Dh; Tue, 10 Jun 2025 14:13:45 +0000
Received: by outflank-mailman (input) for mailman id 1010996;
 Tue, 10 Jun 2025 14:13: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 1uOzjT-0001Wr-UM
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 14:13:43 +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 1c98c9dd-4605-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 16:13:41 +0200 (CEST)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3a36748920cso4915383f8f.2
 for ; Tue, 10 Jun 2025 07:13:41 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-452730b9b33sm139323395e9.26.2025.06.10.07.13.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 07:13:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1c98c9dd-4605-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749564821; x=1750169621; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ex71dpPcu4sL/ml67o9G9wtzTJivuEtkA3sX8sj4GSI=;
        b=VE/w2lcHTxGbm+lVf/Lq1sLDjzMw6EmOTX+Zw+wdXOkoaE0d1nFH7Wq7y/WIBojhy/
         6IVByPZWswcZouYuyzi3vkD2fskJOUJ0BhW4G5aeM6bRqJZu/OR5W5Pen7XOnItbXkdV
         /mz307atpo13inGarwmRW4YtUKf49tNY3xL6EJTccsfe3EtU8M6HwQFymSZ2Q66NCTCz
         05nOBDl91YuE1M9kofSAjC+63Z/W52hgikWy98gHCEH27s6Api02ZylREfEbsd6Q8OnA
         m2bl+4wpwD78c6udbMbQHtCjNkywouHP95hvD6Qt+kgJLuMefy8+IHmxNPZZbk0LLnEB
         GdUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749564821; x=1750169621;
        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=ex71dpPcu4sL/ml67o9G9wtzTJivuEtkA3sX8sj4GSI=;
        b=oNh7VYWrJKCCXJ9gu9RFxAMFhP+J7OC5OHjY4Qod/5++NzZq1+S2uKAvyU+XLcTp87
         M86m9khhWhH6qPZzq77RFRTv7a8G4Ys2galSEKdEP5R/0Vz8aWqUC+aeTa3a/5BF4Wsf
         Aa1YdettUkUhjVJ5YITrlo0nzuRmKzbuarncEi3ZnC4nxTYstEbX3YAAcEz9BvEIet1W
         h8BdF7L8EIdSn7LlnhrRiizQ7E5OB/+9rb2smaKwpXq7grVFPju96KpM+PtdM38THfMY
         Cz7rhdHIJJapAqlLHB/OG6/gmqKmxoKAt8dDfPRiM7daxExt3lHE7M7U73WoMJZR75ZG
         Vhbg==
X-Gm-Message-State: AOJu0Yw2jRjMdcidF4pI7BGhmyLr5I5a2/uBMSumCMj7z5BOP9gL2ww4
	7PfnHuBCXftYBQMQKv+VNP5mahxhl5zXtgHkbmtiadhnOKCfi9nMCT0vD5J15NTjkQ==
X-Gm-Gg: ASbGncvOkghFNjJcSeIkuMC/SyXv65Ax+EJwLbF/Z0G0InCUlJFdO4+s96XSgYX2kJ5
	T8BrW/CAXCs9b4MqdeikgcSr8sez1KzhtdtUhvj0/JIwtzTifmOB/sOQYMMgKHOq+T5a7EBSgsR
	mR4j3DjfDoXLxVHgR6fC5VaTfmJxibYl2CFmzCUDfUKaJnTuS1xxaUf9a4Pdw6gfkAOJh9Sv8PD
	urto2itz+DugZAJhhvITWY/89YwQ1xQZzi+ad9C4HiO5S4JJPl7aFfwCVMG4P916TrJNGE4mYHq
	5GxkuqLiuqD/a0ip/2tAk/+Q1rGPCzQkMzOBus2VQ6XMGk+Y6AjR3gGuBRhdIC8PQlk+drLP4g1
	baAebJ+9Ytci+Cl+P/4xnU78dx3RY3XcCsWGx7qcRx+LdiIWh+GDmrtpKJS6o2PLpCO+EbZo7Ho
	Tx8IxJl1GaCxDFpPjtPS514ipFN0deVlM=
X-Google-Smtp-Source: AGHT+IFA0lm44U0Mn644kPczrGEb/nOMO0WF3Oouu8vXwPR6z1EvI/obSmYmIOMV4IAadzewMbXcyA==
X-Received: by 2002:a05:6000:40d9:b0:3a4:d4cd:b06 with SMTP id ffacd0b85a97d-3a5318a06b3mr13173184f8f.34.1749564821312;
        Tue, 10 Jun 2025 07:13:41 -0700 (PDT)
Message-ID: <3470dcc8-f08a-4a00-8760-b3564d78e638@suse.com>
Date: Tue, 10 Jun 2025 16:13:40 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] x86/HVM: restrict use of pinned cache attributes as
 well as associated flushing
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper 
References: <78b3ddeb-4317-4d54-ad52-9eb03bdf7942@suse.com>
 
 <6e9e84eb-f98b-4c06-8952-03aecc82c0ea@suse.com>
 
 <5f8d694f-e712-4869-879f-80b2c4907a45@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.06.2025 15:24, Roger Pau Monné wrote:
> IMO the added complexity here is not worth the performance
> improvement, not without a clear justification that it's needed.

Well, okay, I'll simply consider the patch in this shape rejected then.
I don't see much value in wasting further time on it.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 14:19:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 14:19:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011004.1389278 (Exim 4.92)
	(envelope-from )
	id 1uOzpJ-0002CZ-7W; Tue, 10 Jun 2025 14:19:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011004.1389278; Tue, 10 Jun 2025 14:19:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uOzpJ-0002CS-4v; Tue, 10 Jun 2025 14:19:45 +0000
Received: by outflank-mailman (input) for mailman id 1011004;
 Tue, 10 Jun 2025 14:19: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 1uOzpH-0002CM-Tc
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 14:19:44 +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 f27a07c0-4605-11f0-a307-13f23c93f187;
 Tue, 10 Jun 2025 16:19:42 +0200 (CEST)
Received: from MW4PR04CA0134.namprd04.prod.outlook.com (2603:10b6:303:84::19)
 by CY8PR12MB7634.namprd12.prod.outlook.com (2603:10b6:930:9d::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.36; Tue, 10 Jun
 2025 14:19:38 +0000
Received: from SJ1PEPF00002324.namprd03.prod.outlook.com
 (2603:10b6:303:84:cafe::b3) by MW4PR04CA0134.outlook.office365.com
 (2603:10b6:303:84::19) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.19 via Frontend Transport; Tue,
 10 Jun 2025 14:19:38 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SJ1PEPF00002324.mail.protection.outlook.com (10.167.242.87) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Tue, 10 Jun 2025 14:19:37 +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 Jun
 2025 09:19:37 -0500
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 Jun
 2025 09:19:36 -0500
Received: from [172.26.5.4] (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 Jun 2025 09:19:35 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f27a07c0-4605-11f0-a307-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=zKbDpDFpa0LB3lpXOQoGv2ssPFknT1IepbJdN9V8TjrjT6t9MBiErdVe/qbvSuro6t6WM65hsjVogZqeI1TwN430VFnB3vKqFNLIOXUUyPOReggqPLfZF2j3dYH3m/Q8+7/2jLTKF/N0k6xwzFB+Dx8ZM+az7s3KwEnLeui0oAJ6mfn7XB5MimlondfpYBz/5YpLZOZkjrgav193dJxA7hTdOU2b+K1VYiIeKIurGhx8JVXjnUugqKRW78OqbcMvSN8YkGGQyR8faIC6F4es5F1dobutxkey6E9zj6Ch4aLxXikvgBCKpd3dV7uGpreXNK/S6Jk/UfY6AQOOa8s8ag==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=sdhbKJJ0w+OYpWulNbyiqaGhEat653rrXsmKv12Sbt0=;
 b=RKC/8Nh2Tr4Ti78aYcrYsqD1Pe5sMO4QPqzu9A1OYbOWC6ispNDzyVqzoxxajL3cJc+elx6JqeNX9wVPkIANrWzoF0ecU6k2MPs7ULOYfvk7fMubTeffwGV7kMIvUOMzDFC4AvURHmJbk+eOPSZvxV+KPskqXYU5crB4kjghGjXZ31iZjPaGnH6D2cdx6iXaO3l40Dm/zb805djcFyfaMc3/8ThojzHJxh8B6hYndbodDp2jtM/9vgavys5TUsZP2bqHUa07nXSrQ1zihKAbjjt+ltzVx30i1ohvuYnhCarFpO4eAOKB7sUoVcA/viMIJI/D8Qg2lr5ptuO33FPedw==
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=sdhbKJJ0w+OYpWulNbyiqaGhEat653rrXsmKv12Sbt0=;
 b=SnEGnY+0av645IO/MisfrvF9J70VOt7FFrZHbYT+zGua1tz9jbwJtJhTaUUcD8L6Rt1sQXdVE3eEgUGImWjRBE6RCb8AJ+v11ZA3OwikagsXvTfc+xax3SUSULvNsOH0beWOV1wics1JeO1ljMawnHQFRGE9QYLux5OjHw638gU=
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: <6339d154-cb92-417e-b2ce-ef91ebbb52eb@amd.com>
Date: Tue, 10 Jun 2025 10:19:35 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/arm: fix build with HAS_PCI
To: "Orzel, Michal" , 
CC: Stefano Stabellini , Julien Grall
	, Bertrand Marquis , "Volodymyr
 Babchuk" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	
References: <20250609205422.180717-1-stewart.hildebrand@amd.com>
 
Content-Language: en-US
From: Stewart Hildebrand 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF00002324:EE_|CY8PR12MB7634:EE_
X-MS-Office365-Filtering-Correlation-Id: ba07c1c8-eb9c-479b-d9fc-08dda829d50e
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?bm9sNy9yK3Q1U05iY0RISEtmc3Jia1U0cFh4VzNwODZpMkJZb3MyZUdjbE5B?=
 =?utf-8?B?Q3dKM25sbzBZNFZ1ZGZoakVtTTFmNXBVYXhzSVd0RUdyaENDc1BTc1d2c2NE?=
 =?utf-8?B?TzlRMnZZWFB5cExVcG1ZRnUrVXQ1NFFpRXEzMWljUlJRYTRRRjlHWVdkb25P?=
 =?utf-8?B?YjE4dEs5VEtYd2NZemdXY1BHZTRUVHJVU0poSjlraUJDSGNwOWwzVHdpZXdk?=
 =?utf-8?B?SCtuaEQzOWJpWlc3MVFQNnl2U24zVjhodjMvOHR2R2tVM2ZTcUVJUjgyZjZs?=
 =?utf-8?B?NnhvVGNtZVFPVi8zZWx2cWN2RUNCbmRLbndMZHJLWk56SjY0bXAvaEMwSDYw?=
 =?utf-8?B?cjQvNktnd2htSEh1amZTcnhLSk84VmY4TlVjd0poYllMNC9tSWZ3NHczYWFP?=
 =?utf-8?B?TjNzSUJmNnc4QVR4Qm5IczBPSFcwblRoVEcxc1E0Yk1pMFc5cHgzdEw0TzhN?=
 =?utf-8?B?VFRRTHh6VGdzYW4zUHVPWTNHUXdxblZaV3VESFExY0ROWjRSZkZnVDZGQVVM?=
 =?utf-8?B?cVJONC8zZjlWTitPNWlRam4yMnJ0UmVOcFNKZ2lmY09ac0pWcjJRcFpFcXRU?=
 =?utf-8?B?eVRhaC9uSi8xM082SUdwb3RIVWZMZ3h3QUZOUjhudnZjSnROV2VXKzZZcDJr?=
 =?utf-8?B?WEx2SUdjUHQ2UTlQY3l4QzdLUnhnT2d1V0V5K1ptcm0yRjBtSzAzdWNFSldq?=
 =?utf-8?B?N3pUc2pRajY3Mnc5OTk0WS9tditZVkI5Zzljay9vRFVQcVN3Z1lHU1o4UXNs?=
 =?utf-8?B?SXhFT2VrNm9kRE13KzM0RXpNUUlOaEFjUzNoY254T3JPOXpmSTIwTnZXdlkx?=
 =?utf-8?B?bzFTS1dyRTJZWm1Ibi9PWklTN2FQVlBuaSs2MW5xRnR5YTNTTG1NWmt2VmVt?=
 =?utf-8?B?V281eDVoalZsc21LOGpHZ3R6aUxGMHNJdWs1NzB6SnZkZk5iU0VnUUxBaldU?=
 =?utf-8?B?WjZOL1BHOHhUUmttOWlybTdZSktvUHd4N0hVWjU4dUtqNUppR3Fma2FiOHNC?=
 =?utf-8?B?TU9Mei94QXZIT0w2OEhzWWI4UGlwdnNKclF5ME8vY3V6MUVNS3lYZml2ZWtk?=
 =?utf-8?B?QVRmVTFxR0RKdnVHNDNhL1V5czFLSXQ2bGlvOFhZVHEwRFdIdVpscjZkRFo4?=
 =?utf-8?B?NExhMExjM2h3ZnBpWkVmNGxRQnlMRzhmV2tIbjV1ZEpHeFllVlZ3M05CaHM1?=
 =?utf-8?B?eEFYRVRwcHNja3N5QjBmbFU5MFpMWkJaeU1Ia09rb2Q5RnFGc3kvb3VJaWxU?=
 =?utf-8?B?bTFzWHZ4aXp1WlJPOFJpbDhKSmxRWDk3OG0xTWRWczJINkt2L0VRNEtUUnVL?=
 =?utf-8?B?WWdLcitTbmhSNjg5VDJyL0xiMXFlUHVuaWJSMjNTeGgzWnN4VSs4MkFWUDQz?=
 =?utf-8?B?d01HNytNOGJFdFptVm84RlRlaEc2SmxQSlZvUnZsbnZMMHlKTXBROFg4ckxF?=
 =?utf-8?B?QmphdittTnFpWTJxaVNYUU5EeisreUxnUXlZK3BKd1RyM1o0U1JSK0pLTHd4?=
 =?utf-8?B?YmlVeVJvUjBBZmNEeVdvUjJNdnBBcWFDQnBYRWoxNW8wNXJhSUdHWCtZTEVW?=
 =?utf-8?B?SDdWUHlsR1NjTWw4NGVKd3lwaUE5T3M0dEtxT0xMNGtHQ3IxOUd2am9JdVlr?=
 =?utf-8?B?cVFPR21OOTVwT1JIMG5qRm5heUJZSTJjOGdmY2d4VThBMTd1blRPMk91WmFa?=
 =?utf-8?B?MEZQSDN1bU4rZThLbEZESFlqSWh6WEUvZzlsOTIrMUJNVHd1cDRpNHZwWGUv?=
 =?utf-8?B?WGI1M0RKdFJGUTBkU25SNk9SemN6MHFWL0NJM1F6RGRyRDVIZ3dwdzhHWldR?=
 =?utf-8?B?WkxJMlFXQjRHV3lIaGxKQTg0ZCtkRzJmRll4N1FuNjRsN3BhdkF1VUVNcXFW?=
 =?utf-8?B?Y0xqaGo3WkZ0eXh4dytZdzJHVFVUMDlKaHg4U0ZLdno5VDJQQ0xDaXdpNmh6?=
 =?utf-8?B?ZGc0eDVNWFJCd1lnb3ZEUVJoRVJ1ZE5iTTlRNm9MbDNUQjZvSStjSTBoVEVT?=
 =?utf-8?B?R1JqbnlEd3pIRDlCaTJhdjJ0MFRhYmlqUUxMQXQzVXNISHdhUHZTcGJQRnV4?=
 =?utf-8?Q?F7QNKD?=
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: 10 Jun 2025 14:19:37.6857
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ba07c1c8-eb9c-479b-d9fc-08dda829d50e
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:
	SJ1PEPF00002324.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7634

On 6/10/25 02:42, Orzel, Michal wrote:
> On 09/06/2025 22:54, Stewart Hildebrand wrote:
>> In file included from ./include/xen/pci.h:72,
>>                  from drivers/pci/pci.c:8:
>> ./arch/arm/include/asm/pci.h:131:50: error: ‘struct rangeset’ declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
>>   131 | static inline int pci_sanitize_bar_memory(struct rangeset *r)
>>       |                                                  ^~~~~~~~
>> cc1: all warnings being treated as errors
>>
>> Fixes: 4acab25a9300 ("x86/vpci: fix handling of BAR overlaps with non-hole regions")
>> Signed-off-by: Stewart Hildebrand 
>> ---
>>  xen/arch/arm/include/asm/pci.h | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/xen/arch/arm/include/asm/pci.h b/xen/arch/arm/include/asm/pci.h
>> index 1605ec660d0b..1bbb9d780193 100644
>> --- a/xen/arch/arm/include/asm/pci.h
>> +++ b/xen/arch/arm/include/asm/pci.h
>> @@ -17,6 +17,8 @@
>>  
>>  #ifdef CONFIG_HAS_PCI
>>  
>> +#include 
> Just for the struct, I think it would be better to forward declare it (at least
> this is what we recently started to prefer). Especially given that rangeset.h
> also forward declares it.

Forward declaring it does seem better. I'll send v2.

> That said, I don't find it mandatory, so with or without:
> Reviewed-by: Michal Orzel 
> 
> ~Michal


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 14:23:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 14:23:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011010.1389289 (Exim 4.92)
	(envelope-from )
	id 1uOzsj-0004XJ-MC; Tue, 10 Jun 2025 14:23:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011010.1389289; Tue, 10 Jun 2025 14:23: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 1uOzsj-0004XC-JU; Tue, 10 Jun 2025 14:23:17 +0000
Received: by outflank-mailman (input) for mailman id 1011010;
 Tue, 10 Jun 2025 14:23: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 1uOzsi-0004X6-QZ
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 14:23:16 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20631.outbound.protection.outlook.com
 [2a01:111:f403:2416::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 71a8f31d-4606-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 16:23:14 +0200 (CEST)
Received: from SJ0PR03CA0179.namprd03.prod.outlook.com (2603:10b6:a03:338::34)
 by DS0PR12MB7607.namprd12.prod.outlook.com (2603:10b6:8:13f::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.39; Tue, 10 Jun
 2025 14:23:10 +0000
Received: from SJ1PEPF00001CE4.namprd03.prod.outlook.com
 (2603:10b6:a03:338:cafe::4f) by SJ0PR03CA0179.outlook.office365.com
 (2603:10b6:a03:338::34) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Tue,
 10 Jun 2025 14:23:09 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SJ1PEPF00001CE4.mail.protection.outlook.com (10.167.242.20) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Tue, 10 Jun 2025 14:23:08 +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, 10 Jun
 2025 09:23:08 -0500
Received: from ubuntu.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; Tue, 10 Jun 2025 09:23:07 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 71a8f31d-4606-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=y2FLm4Wj2uC4k3gelN2BYFixuvS7L/3o2+w8NeQJEIy6/WFyasXNdE/PvHzv9le5r0n+DMsuxw5OBXmYn4iIfA+rGbvxrMZAiZuZv9NssReidwreMw8nf4qqO7OgEQc+anMhNAudvkS40DSZcy4oJmHuZULxMv6zzz7wKkdrfHnCDHmFz48XcAeaPCvMGcShov07kYM8phHfdnOsSl0mbOlAAJIGjm1XrihGUuVNXrth5I0SW0TxzVR5UgSYRZaCi3R9u4KvlHIi8TD/KoLaAHOoMxWSC7Ckqg586nGk+6fR6aM1cEJgGD/A/WQf4IxmsZA+cJmbsNwXqE1vA97XTg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=E5U8wbQNi3yTZwoPAKZ6ACj9OUN82gA50PwezWKLsZ4=;
 b=jKS8a3M5se0al4KW7WR/9YksMtN/9hjv/NbKxZ/SYbiNWLVx5Xn3fR+qAZGwFF2jNmsaKFRlnA3esfSkrYOZAGSG5w8Cj0Va+UCABCEJa0L4ItT/L08GQu8S8RuwdcDikABMLiNbroriikdF6UXZgYt8/eISLtIdZKJewj3Yrw+ZQ4TPiL6XfTVHL+1+fwW6CvOpR5g5ybnsiB5ZOMhlVxe3zp74+5LdXwc+YotX7WgbtsvocSWhZRS2BJqBifYhtyh9F8Yl8kJj8JOZom1GrvtDydWyYHve7vRBIA10MyO4mrZsQD8MGcrWnW4Orvk0lx96MTFWRAF2tCzYdZJ2mw==
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=E5U8wbQNi3yTZwoPAKZ6ACj9OUN82gA50PwezWKLsZ4=;
 b=qdNuQr2GSruOFmOwIA+DMqVTkwFaHsBKImQ7tv11N13sb2ZrnUg+UWwVRllpebvATcYdJNlgMhJP+0a+adAIXb1XkQajEIrNN5odhPKis+rGZFXu1K+P6KPSXAxSWoed3F+6xdxD9c4Va5bNInvowtALxrsSDBErgj3p9EuvT3g=
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 , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	
Subject: [PATCH v2] xen/arm: fix build with HAS_PCI
Date: Tue, 10 Jun 2025 10:22:57 -0400
Message-ID: <20250610142300.197599-1-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
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: SJ1PEPF00001CE4:EE_|DS0PR12MB7607:EE_
X-MS-Office365-Filtering-Correlation-Id: b11feb22-2881-4f14-a3f3-08dda82a52eb
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?WXhLMm93QmZPTVdTSDNwc0trYk9HYmhoTVR6eFRmbzVoU1JkTTFJNlVJQ3R1?=
 =?utf-8?B?UFlFajdOUEx0SmhqSFNlS0p6dkx4aUNYcGsrSkJZVjBDM3ZWSm1oMlJFa0F1?=
 =?utf-8?B?dWJxUnhoR1ZmaFFFTlR4YzNCUndqUlgxdStUVmFrb1VmTWdwRys1dnZuV2h1?=
 =?utf-8?B?eEgxdUYzMDJJL1VVNXo3WGx2SFpxNXQ5MlBmQWNzODB5aUlKQXlVZklnazh3?=
 =?utf-8?B?WmIrYlZZUHhiSVI4azRuejVBQ24vMEI2dDNMbHdYWS9TTWdyRjRRNVAyMnp6?=
 =?utf-8?B?UG8xb3VURjFJM05iU2xvUlUxTGZOUzZEbGRsOHZZT2ZaN1pKelFuREJ3em9j?=
 =?utf-8?B?d2U3UmhPYldCcW5ua2FNZklGV0lOUzM3MkNweDlNT2owNWtnaEtBRzRwcVgv?=
 =?utf-8?B?cWZhdW5zS1dTZ0ZOc1REcEp4Vk5ia200VEl5YVBiK3FMSUxBTGt1NE9nc1pU?=
 =?utf-8?B?NDhqbFp2RTBzN0loY3RqVHRNRElQbEJMc0htWXpJenNna3p5Q0RTL2REZDN0?=
 =?utf-8?B?K3VuSVY3K3dKbWI1Wm9SYWJpVjQ4bXJlbklwdm5ldmd3VzRhNEhoa0Y1cW1G?=
 =?utf-8?B?YUVNbTJYMU1YL3hySmhUN3ArVXFJYjZ6WExQOE1HLzEya0tUd1hCRHJLQjBn?=
 =?utf-8?B?bkI2UEdTOWVNSFJKZWIzeFJCV3VCTDB1NW9XMEFHOUwzTmtSNCs1eVB5QWFP?=
 =?utf-8?B?SjdQVUN4Mi8zOTkzV3VpTU5pbWwxREtMeFdDV3pHb0xKai8xcm5oSFRlTDFh?=
 =?utf-8?B?ZGs1cm8yaVZoZlBrMEwrUnpieERsQ1MvTmx3bm1uUEo5SU5Ldm8xQjA1N1NO?=
 =?utf-8?B?UkFhUGhQZkN4RkVlK05VTFFEUUx6cGtubmp4UDhwNVBSQXFWUXpyRTdpbHh4?=
 =?utf-8?B?SlhqYlprc0NEQ2hrUCt2TnV3VXJSTTUxdG5McS9uMmNGOVZNZFJCNWpzRTFo?=
 =?utf-8?B?OXdWOXNlbTJTaTVtQUcyd29kT2pBdnRNWWQ2REZhTHRYeVNRWFlhbGppVElU?=
 =?utf-8?B?Y0t5VHR3Z1BVaXlFNWEvVTdRbm9hTUxZTUpMREM2WGViOEVvaUZIUDdNSzJ0?=
 =?utf-8?B?UG1wMHlZUWJTVGxmRDNSSmN2dGlvWkozYmVPeVdCbEYyTUtNWHNqWmw0N2tW?=
 =?utf-8?B?aVlEa3dORy8wWmFRekNGUENoN0VkSHZtWkJ0TlJGMDg1SW1CVmJqaUtJRThp?=
 =?utf-8?B?ZmFOeWZIVHV6WVRaanhaT0JsOGNKT3ZBT1JyVmMraTFPVkUvZDQ1NldpRUNw?=
 =?utf-8?B?V1RXM25DeHN1MjJqUkFBYUZRUzdMVXFiTkg1V3dGSitWQStNV0c2RzdqRTVJ?=
 =?utf-8?B?MkE0eG41L1NyZHQzb1haUWx0VjNLQWU4TVpSVk1iNXVFa2N4R2hqNXQ3bVhF?=
 =?utf-8?B?RnpoZUlINnR3MDZ0WXNtUHVHdkxaaU5SVWdTRmNxMUxteGdoMDNSajREN0dl?=
 =?utf-8?B?L1JwTEtvLzhIcjhiNDhQUm5jUm5jc0YwSmQzakQwT3RFajdoNFdlbDhLei8w?=
 =?utf-8?B?emd2VzZaTEY1R1NMWCtKME44bVZVZm1OQkdNNzl0SVE4TDdNdGlsTDBxZFBV?=
 =?utf-8?B?YjArMU9SLzYreVRkKzd5R1ZyVXhFamtrTDVyK1JGeFVCTmh6SU84VGhrU3Aw?=
 =?utf-8?B?aXlGekZMVkhWS2UyeWNqM3FqZWpDdHFySWxCRGNaTS8rUG02d2RlenRMcVJK?=
 =?utf-8?B?VFVsOEZCTU56bU1VYXNtcmZndytCUXNzZWVwd01tWk9IbHBkU0QyNG9nWE9P?=
 =?utf-8?B?dExIZURYUzJaZDBUbVB0S00xQjhYODFXdjZVeTlManV1NXlSMVFzVFREMGNq?=
 =?utf-8?B?MnozT0hRRklGU1A0V2p5Z0ZwMXlxaTFYbWJYWTVrcTEyM3hzMEJ2YktzQ1lZ?=
 =?utf-8?B?MnRaVHBUZllSWnprd3JWZWJDRytrY1RvOW92eFNtano3TWZzZ0hRbUdCQkhV?=
 =?utf-8?B?MllSaUxOS041N2RGS3RDTFl0UUZBcGl6YnJCU21Rbzd0TU5JY2VyTldlS01B?=
 =?utf-8?B?WjBUN2p4TU1zc1FxaGZUTDNsUUlxUEtlY04wMDJjS1RWUVJ5cjAvcDhtV0Ja?=
 =?utf-8?Q?xUpOQ/?=
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 Jun 2025 14:23:08.8476
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b11feb22-2881-4f14-a3f3-08dda82a52eb
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:
	SJ1PEPF00001CE4.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB7607

In file included from ./include/xen/pci.h:72,
                 from drivers/pci/pci.c:8:
./arch/arm/include/asm/pci.h:131:50: error: ‘struct rangeset’ declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
  131 | static inline int pci_sanitize_bar_memory(struct rangeset *r)
      |                                                  ^~~~~~~~
cc1: all warnings being treated as errors

Fixes: 4acab25a9300 ("x86/vpci: fix handling of BAR overlaps with non-hole regions")
Signed-off-by: Stewart Hildebrand 
---
v1->v2:
* forward declare instead of #include
---
 xen/arch/arm/include/asm/pci.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/arch/arm/include/asm/pci.h b/xen/arch/arm/include/asm/pci.h
index 1605ec660d0b..64f0e6ce7e3b 100644
--- a/xen/arch/arm/include/asm/pci.h
+++ b/xen/arch/arm/include/asm/pci.h
@@ -23,6 +23,8 @@
 
 extern bool pci_passthrough_enabled;
 
+struct rangeset;
+
 /* Arch pci dev struct */
 struct arch_pci_dev {
     struct device dev;

base-commit: 86a12671c5d33063b6f958bdcca7c9d14cd5aac8
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 14:29:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 14:29:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011016.1389299 (Exim 4.92)
	(envelope-from )
	id 1uOzyS-00056e-9V; Tue, 10 Jun 2025 14:29:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011016.1389299; Tue, 10 Jun 2025 14:29: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 1uOzyS-00056X-6u; Tue, 10 Jun 2025 14:29:12 +0000
Received: by outflank-mailman (input) for mailman id 1011016;
 Tue, 10 Jun 2025 14:29: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 1uOzyR-00056R-5j
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 14:29:11 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on2060a.outbound.protection.outlook.com
 [2a01:111:f403:2413::60a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 450f9ab9-4607-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 16:29:08 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by DM3PR12MB9390.namprd12.prod.outlook.com (2603:10b6:0:42::19) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.35; Tue, 10 Jun
 2025 14:29:05 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8792.034; Tue, 10 Jun 2025
 14:29: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: 450f9ab9-4607-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=DHTvGQEgXLChwax2kEvPACD0IgZwgitBuNM/SekLEpHSWsDz76dSgXJSj4kBQUc3rm8e+QV32woWtkSJWm0hVye5R8AJNl80HSv1O7eUcp+ASJojfZg2RfBkU69+nvqcFuAPODQGrRtXl868mFuor4zwNm0XzLJLaRrgv/H7UiHbeEWq1wVaGPJZ8FUOd50Sws3DFn9r76vm+/FVfmSZkURoINAeMmHViDwgwb43ZIT3HOqAV0cac1Z2nXymtx6Ff+y4TehjcWkJ/EigEgk9Rah0BXTBn7OfxBfQigLY07p4DPao2Lt6eiO7QJJ4Dgm9eYOFkKvkus/lZBak+MEBDQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=4MpQqWueoqx+vif+WSO7hSWpdvQfqgL+pblYKOdJV8I=;
 b=xxl9tXs5tXZSP6aIPNHtomeNZV/EQ+etgGL+hOBzJMQZo/OHmVC24SWxKOLWtvcux8LgopI163awyeGt/cR97BN4FcAymKr62/LR//8foDe4RPCbrYvYoHV8l35o43oBqnkqH9no6RD5LlYWwR4x6B3jrgOrMyguYF+oAcPwHM5s5O/JyGgDYNJNsVZqolg91VK4h17GqmDCkZLjnltK9Ouadhinq4QWqPkSyRUovliKaVPa52v7qTlfqdC6x2ABdfzU+LZqOHgZxnpHUQ6ZVi60Y72KqWLd2XaceFnFmzrCu7bYVob1Ek33m4AyaOvzn5rLqKWVaK2pqjKk+5pkrg==
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=4MpQqWueoqx+vif+WSO7hSWpdvQfqgL+pblYKOdJV8I=;
 b=PkkeDEjQhFLdMjFshWa/+Kiyz4xVLpjG/XeBemvwMUj6C/0Nxts7XdE1ODaIiPeqeFTqvcTnurcV7jnQESFhQjf26c7Or8ULQIZlc9gfaCjz87Edyil+FKPx7xp6f9kRo59PFqK88mYLQt7hebvv8r+Vy4AoayY35yBXb+aWN+o=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <905c1306-4713-4650-aad2-95a580c656f3@amd.com>
Date: Tue, 10 Jun 2025 16:29:02 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen/arm: fix build with HAS_PCI
To: Stewart Hildebrand ,
 xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20250610142300.197599-1-stewart.hildebrand@amd.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250610142300.197599-1-stewart.hildebrand@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: FR5P281CA0043.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:f3::14) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|DM3PR12MB9390:EE_
X-MS-Office365-Filtering-Correlation-Id: 34e07088-93ba-48cd-83b8-08dda82b2726
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?YmN5TnMrbDR4M3lRdURuTy9oYkFXSTBSSVFVQlhOVVl5dm5wWW41RUEzKzVU?=
 =?utf-8?B?UXYva0tRT3BtOHhaUXBnVVFyMFR4NlI5RjB6ajhPY3hxdmZCL0JCakE2REMw?=
 =?utf-8?B?cktGVHY1clZtS2FBZnZycWJONlQxajVtL2F0bEQ3TGpNaTNzNmlZNnlLUmdu?=
 =?utf-8?B?QlJSTzlFeE5PcmJTbm9lZkt0cWtYcGUrM2todEowTjUzVFdzM09SS01BZzI0?=
 =?utf-8?B?SXM5cDE4MDFHZ0owUkF5L01pWnMvMUdxOVBVVDlyMEI5L0x1engrMEVoN2xu?=
 =?utf-8?B?NC9jd1NLZmVCZ3NOdTJDWEU3TzdBZXRrRzJJUTU3N3RDSWpUdWNTb3FHYkli?=
 =?utf-8?B?OCtvZ2JWZzBQUnRsSFdOak5MUE93YloyVStFbFJud1RGcFJNZmJkRDQ4RElP?=
 =?utf-8?B?OUswejJoSXJCdFlOSWh2ZzR0QjFpUHZwZjFCSnJHMENBV0dzaVgwSVN4Yk84?=
 =?utf-8?B?UTExeG9nbmVNZWZuOU9lOE1FU2lHYW9QbWFYalB2bHRnRjJzTzJzWk9QS2NC?=
 =?utf-8?B?QVo1aU1ndmJVMGdCL05VdTVPWGtnZEQ2YWdLU2JPd2pUMTBVUFV1MWkwTTJX?=
 =?utf-8?B?VVd3d1hweExuSUJxT1RqZklYYnZKYjluRUtDSnlMOTg2aWMzclBpa1B0UEV2?=
 =?utf-8?B?dEhsRXlHUC9NMlFDVDlhbmpnVWVLaENRcVljVkErN0pVSURxU2FEOElGMzNX?=
 =?utf-8?B?bXdvVHhnbVhHd09ORjN6U0JobWEzRjdCZVpjQzA3YXU5VTJ1RG5vUmNNTURU?=
 =?utf-8?B?OU9YWjl1WVlYZnVqckd0REExUGdpMmVkMUhMV3FGMDl0UjdldGs2Q2FkeDVq?=
 =?utf-8?B?WHpKcEtWR3lFNitBQnptOXpTQXduVVRjMGJwWm5BQmZNZC9ZeU1SbzQyTHZV?=
 =?utf-8?B?WXZHdUhjZmd4NWhlZERxQ1ZReHZVL1ZBZis3bU85OUFoVmhseVdrMGE5VE5J?=
 =?utf-8?B?dDBiUktYWUE3OU41cnJtWHlnOW0yRVpldDZaWWtvVXVON1dnaGNjbGUrZEN4?=
 =?utf-8?B?aGV0amtaWlVrbzlmclliUm9CWjJOQlp3ZzF0aEtqS2l0ejZYQWtBSVNRMTJq?=
 =?utf-8?B?dU9LcmpQRm1peTBrREUyREo2cTU5ZWRNT2pPSlVtbUFIMnlxNEJ3bG5jT0pr?=
 =?utf-8?B?akltc1BoWjdTQmF6TE5BZlBVOFVrWW9DSVVkQUFFcm5IUDhvZ2JDVEtmelly?=
 =?utf-8?B?eWdYQ0p6WVBLQ2RkdUVPa3lVQ01DeVlmeHVGUGJsOCtoc2M1ZjYvKzhOOWdP?=
 =?utf-8?B?YWd2OGxVeWs4Q0V5YkdDL0VWTVZXMXVnMm5Tb01qdXBhQnBkS3lML2NYVkhw?=
 =?utf-8?B?ZkZFemJiNEo4YVlCajlUQmZkY2JQZStlczhhaXdJS3UvcjVYZ0pqdVlSengy?=
 =?utf-8?B?TmtSbmxqM0tKWGpjZ2M2TEdnQ0pZWmdmbTV1d2NSK2FOM0drZjkrenNLYWNh?=
 =?utf-8?B?bFR1QVdRNUg4a2hWTUk2ZlBKaXhEWm5OaDdBemRmallnUTc3WW5LY0VyR3FI?=
 =?utf-8?B?Vitnd0ZKdC9FZkNCYWVEVlVPN3VXV3d4R0R3ZUZtdmV3SEduYUlCZGVkWmRU?=
 =?utf-8?B?VnB6dEFXQnpqN2I2Ym10V2N0ODlCbG03ZnRwVmU4RlJPNkpISDd1NGNBdHdN?=
 =?utf-8?B?U2tKWkZYeWdHTm0wODkwL3NXSjByYlFuS2wrdklGaUk5aTczcm1JNE1UNUVX?=
 =?utf-8?B?OTl6eXhpUm5PWUp5cUFNOFk3OWF5emNnRStEM1ZPOFMyZUVHNml2ZFNPVWJz?=
 =?utf-8?B?eGJKRHlEZGN1OEtOaEZxSVJITTJuU0FxbVNEZGRFMFh4MUJDZEdaMzltTXVX?=
 =?utf-8?B?ZG1MK1JaWGJpejdtb2c3MEdjR3dIMGhoMUVpaFNDK0hMa2xGRUhuVWMzZ21h?=
 =?utf-8?B?V2lJcnA4V1hiNXlvR2RRV1RUQ2ovKzBod2lpcGFHY0pwbWFjazZ6b0tuQnZD?=
 =?utf-8?Q?hk9T0Y15rTw=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?Z1h0Rm9rb0tHTmdHWHZzVlV1UlhuRmY1T2JqYXkzRmkwNVk2MS9MejBiMkFN?=
 =?utf-8?B?UytJd29KTmZjSmYyT1RWL1RrTnVsUWxSTzk4aVJDdnZQZ1lhd1NJT2k5Q3A2?=
 =?utf-8?B?dC9ZQ05DQkljeE9IMzRQaXM5ZWEyeHJERS9BOWFOczFUUldTeWllZ3hiMVVk?=
 =?utf-8?B?TmF2c3V6VUVlQ2lFZS9SM0poQlh1d3YyOW9XUDRnQVQxRHIyT0pDQWRuWnUy?=
 =?utf-8?B?aWxxUmJBVkJjZlB4TzZ2UDg1T2hZSjZ1VHRLUEdQOFBKMENBNTQvcE83QUdi?=
 =?utf-8?B?RGR4bmR3YlJ3bS9uckYwaG9kRGx2d2V3MEpnV1dybUZiKy9Fc0tQaGVGaTlx?=
 =?utf-8?B?ZE04eDBvYmowYjRWWXZSb1AvNk5mY0Z3dGU4dklJZkt5bWFuMDNkYWdWd0lG?=
 =?utf-8?B?Y2JKLzZjbDhvMTBicUsrbkxwK3ZIQTZxZ1dWWE54QXVjT3RMQUZJYnF4RkZl?=
 =?utf-8?B?VWhPZVJSaHB4aEJPR2IxbkhIMTdKenk4aFZ3M3ZwQmxwY20xajNqSEg2ejZJ?=
 =?utf-8?B?YTF6VUFUcURuclRwSHNEMThkUUcwZFJEVHpoLzd3S2xnY1BSVDdKMGNrbmFl?=
 =?utf-8?B?SlZkWUNEV2orUlZleHY1VGRNc2ZBNWJiMExxc1QrandpdmhYVS9XYWlkK0pK?=
 =?utf-8?B?NmJqVnVtUndMaGxzT3ZXaDYxa1NKZlhMN3EvNHJ6ZU5PMDU4QmM1Q0FOeVZz?=
 =?utf-8?B?dnFlWEtjWjZ3a1czcmdOS0ZhYTYvRUxMYWd3NCtRbjlvbXM3RnBwcEorTjBF?=
 =?utf-8?B?MlE2cERnVUJQWGUzcC9jekthZkMyMFc0dVBpbHUwRmZ0MU9oWVBhaCsvK0pX?=
 =?utf-8?B?cjI2TFpTcG9tekl3UUNMV2k0ZmhscnFFSTQ0Zm9qcitsaVdvb0tDOTYxZEF5?=
 =?utf-8?B?cXU1ZitKZzBmVkpzeDJtUFBIMHZUcEp2SllvdW0zenhXSVJ5cklnaGxrYTd6?=
 =?utf-8?B?RG5UV1lkeVpGcjM1dUl3dmxoNFNSU25Yd294cnZQZzc5ZVg1OGwvQWlOSGpH?=
 =?utf-8?B?M0tJTU9SS1VBQ2tQbVhXTlJ6dEJ2dUxOcmFIMXJaRnRmYnBiOUNkK3FQVW1t?=
 =?utf-8?B?bTQ1c0ZPVmp4QSswRHZnbXlWQUV2YXE5R0lSbk43VkVDRjQrOGNDaTZWMWty?=
 =?utf-8?B?cEEyZVU3bVY1UnJGYjFkMjlhejhjU1YxTXRJMFBhbXpzeG41YzcwbExWNEFs?=
 =?utf-8?B?V0Vsa3grbkFaeVF4ZWQ5ejdKUVpCVHJLR0oyZG5qVVAxVy9EczVGV05xVVNX?=
 =?utf-8?B?WmlOLy9SbTVmQzRSOXh0ZUhnUUtBN21RYS9BYmdoTXM3Ky9IRjFpKzlTQTc1?=
 =?utf-8?B?dEJmNVBCQkpTQnZJUVdXMStHeXlSdm54R05yUW1PclBidE43WHN0SlhnaitB?=
 =?utf-8?B?K3N1SVlkd2JpcXJjTkJ2TnB1ZUljU0VXTlQvaVVyaTRiVHJSa1R6dmFwWUtn?=
 =?utf-8?B?M3RGaFp0eFBrdHhISmdsR1k4eXVXckJEZ0U0L1E4RHBTTldiMG4rK3d0MVlF?=
 =?utf-8?B?c3V3ZThVSWR2b2QzYXhiZjludm4vcjRSWElKWFViellFeEV3ZzR2bTE2M0ZZ?=
 =?utf-8?B?LzhDVFpkUXZOMGczMGwxYVRZWGtLSjVpbGZUaHZwRENhc2lUWlI4NXUzZ0pC?=
 =?utf-8?B?aHUvTzRFaXRkY0d4eWp6VmcrMm14OVlGOE15UWNDQWM3cDFSbDJicVk2K3RU?=
 =?utf-8?B?TWVGZVQ3VnkzRi9uT1d2ZVpzS0ZsbDZTZ3EvakxCTWNzR3JiNGRUdVcvWnk3?=
 =?utf-8?B?VWlWR0Y2RUhqazJ0OEt4MHVhcTI4LzQvanNBSmNESDllS0JqWGNzR2NNMkhm?=
 =?utf-8?B?VWU5N0hDelhaWExBbXhFUXAwTVl4dS9MUDcvVjRJZGV2R0tnRGtPeG51YUl6?=
 =?utf-8?B?QXFoQVpaaThkK0JaL3M1UzFIbkltRng0cHkvOHAzcVRibEdFZDJTQksvaW53?=
 =?utf-8?B?ZlVzaDBuR2hhUjFGdmNRaGQ3SThXWVh3L2F5OHFxMHhzWUFveHY2dUNUM3FV?=
 =?utf-8?B?d1NIRGxwR3E1ZjJ2eENFZ202WC84Nml1MW04WmJraUVuUU1abmlOZXRwc09t?=
 =?utf-8?B?ckRMWGFhOHd5ZU1La2lSNjNPaFhuZnMrdm9QcWlGMGg4ZlNGS1BXeXhzbzh4?=
 =?utf-8?Q?irVc=3D?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 34e07088-93ba-48cd-83b8-08dda82b2726
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jun 2025 14:29:05.2882
 (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: AEdRe2DCmeIJjehFLMLhZ+488wAalZHQzUU/dcWlsn074jV5X10FbOYEzGJfnHTg
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3PR12MB9390



On 10/06/2025 16:22, Stewart Hildebrand wrote:
> In file included from ./include/xen/pci.h:72,
>                  from drivers/pci/pci.c:8:
> ./arch/arm/include/asm/pci.h:131:50: error: ‘struct rangeset’ declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
>   131 | static inline int pci_sanitize_bar_memory(struct rangeset *r)
>       |                                                  ^~~~~~~~
> cc1: all warnings being treated as errors
> 
> Fixes: 4acab25a9300 ("x86/vpci: fix handling of BAR overlaps with non-hole regions")
> Signed-off-by: Stewart Hildebrand 
Reviewed-by: Michal Orzel 

~Michal



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 14:41:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 14:41:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011028.1389312 (Exim 4.92)
	(envelope-from )
	id 1uP0AB-0000Bz-Ej; Tue, 10 Jun 2025 14:41:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011028.1389312; Tue, 10 Jun 2025 14:41:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uP0AB-0000Bs-Bl; Tue, 10 Jun 2025 14:41:19 +0000
Received: by outflank-mailman (input) for mailman id 1011028;
 Tue, 10 Jun 2025 14:41: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 1uP0A8-0000Bi-VJ
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 14:41:18 +0000
Received: from mail-10628.protonmail.ch (mail-10628.protonmail.ch
 [79.135.106.28]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ecbc64b2-4608-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 16:40:59 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ecbc64b2-4608-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1749566458; x=1749825658;
	bh=6bWOkAdXEnKQAQODlD2qLkfzKN8t0PvEMwSj30Kvyi8=;
	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=EUtQCMmF4UZ2BrA/QItWsfwzYSNV0ZqaCzljM1ZeULod07Mf5w8E2/GSkoWA8T0qE
	 uou9ojdi/4NQjil0tNcxEVpbaSbPswLCAT8aILBWkM7SRK23O/Z6UaE2mzxcLbLEdv
	 C+vCGN2W191CUHn12Rt5KH8GyYZSf/o69kcpHIcN9omWucjEwSN/qySLva8q6ggb5h
	 D1C3PRIcIPLKLzepsiSBLDg/nSfq2FJzOpdPEdVKaWYPPJhp1D6yJ2TiPr+ePrmAp0
	 xqZpCIPNZcbGiVmomzeqdjGd1XJQ0pFVm4VcqzgY2kGhTNYJd1YSKjasmtuqywJ/GA
	 fNRyodZwRe7ew==
Date: Tue, 10 Jun 2025 14:40:52 +0000
To: Teddy Astie 
From: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: Re: [PATCH v6] xen/domain: rewrite emulation_flags_ok()
Message-ID: 
In-Reply-To: 
References: <20250610004216.3012253-1-dmukhin@ford.com> 
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: f7e9a450fb503a1fd13dcf5881858a2b5044f820
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 10, 2025 at 08:55:58AM +0000, Teddy Astie wrote:
> Hello,
>=20
> Le 10/06/2025 =C3=A0 02:45, dmkhn@proton.me a =C3=A9crit=C2=A0:
> > From: Denis Mukhin 
> >
> > Rewrite emulation_flags_ok() to simplify future modifications.
> >
> > No functional change intended.
> >
> > Signed-off-by: Denis Mukhin 
>=20
> Reviewed-by: Teddy Astie 

Thanks!

There's a way to optimize PV case even further, so I will send v7.

>=20
> > ---
> > Changes since v5:
> > - optimized `configs[]` table - just one record for PV case
> > - sorted entries in `configs[]` table by domain type: PV, then PVH, the=
n HVM
> >    entries
> > - addressed `caps` initializaton
> >
> > Link to v5: https://lore.kernel.org/xen-devel/20250602191717.148361-3-d=
mukhin@ford.com/
> > Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelin=
es/1861382846/
> > ---
> >   xen/arch/x86/domain.c | 86 ++++++++++++++++++++++++++++++++++--------=
-
> >   1 file changed, 68 insertions(+), 18 deletions(-)
> >
> > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> > index 7536b6c871..82b126351b 100644
> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -743,32 +743,82 @@ int arch_sanitise_domain_config(struct xen_domctl=
_createdomain *config)
> >       return 0;
> >   }
> >
> > +/*
> > + * Verify that the domain's emulation flags resolve to a supported con=
figuration.
> > + *
> > + * This ensures we only allow a known, safe subset of emulation combin=
ations
> > + * (for both functionality and security). Arbitrary mixes are likely t=
o cause
> > + * errors (e.g. null pointer dereferences).
> > + *
> > + * NB: use the internal X86_EMU_XXX symbols, not the public XEN_X86_EM=
U_XXX
> > + * symbols.
> > + */
> >   static bool emulation_flags_ok(const struct domain *d, uint32_t emfla=
gs)
> >   {
> > +    enum {
> > +        CAP_PV          =3D BIT(0, U),
> > +        CAP_HVM         =3D BIT(1, U),
> > +        CAP_HWDOM       =3D BIT(2, U),
> > +        CAP_DOMU        =3D BIT(3, U),
> > +    };
> > +    static const struct {
> > +        unsigned int caps;
> > +        uint32_t min;
> > +        uint32_t opt;
> > +    } configs[] =3D {
> > +#ifdef CONFIG_PV
> > +        /* PV dom0 and domU */
> > +        {
> > +            .caps   =3D CAP_PV | CAP_HWDOM | CAP_DOMU,
> > +            .min    =3D X86_EMU_PIT,
> > +        },
> > +#endif /* #ifdef CONFIG_PV */
> > +
> > +#ifdef CONFIG_HVM
> > +        /* PVH dom0 */
> > +        {
> > +            .caps   =3D CAP_HVM | CAP_HWDOM,
> > +            .min    =3D X86_EMU_LAPIC | X86_EMU_IOAPIC | X86_EMU_VPCI,
> > +        },
> > +
> > +        /* PVH domU */
> > +        {
> > +            .caps   =3D CAP_HVM | CAP_DOMU,
> > +            .min    =3D X86_EMU_LAPIC,
> > +        },
> > +
> > +        /* HVM domU */
> > +        {
> > +            .caps   =3D CAP_HVM | CAP_DOMU,
> > +            .min    =3D X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIR=
Q),
> > +            /* HVM PIRQ feature is user-selectable. */
> > +            .opt    =3D X86_EMU_USE_PIRQ,
> > +        },
> > +#endif /* #ifdef CONFIG_HVM */
> > +    };
> > +    unsigned int i;
> > +    unsigned int caps =3D (is_pv_domain(d) ? CAP_PV : CAP_HVM) |
> > +                        (is_hardware_domain(d) ? CAP_HWDOM : CAP_DOMU)=
;
> > +
> > +    /*
> > +     * NB: PV domain can have 0 in emulation_flags.
> > +     * See qemu-alpine-x86_64-gcc CI job.
> > +     * Inject fake flag to keep the code checks simple.
> > +     */
> > +    if ( (caps & CAP_PV) && emflags =3D=3D 0 )
> > +        emflags |=3D X86_EMU_PIT;
> > +
> >   #ifdef CONFIG_HVM
> >       /* This doesn't catch !CONFIG_HVM case but it is better than noth=
ing */
> >       BUILD_BUG_ON(X86_EMU_ALL !=3D XEN_X86_EMU_ALL);
> >   #endif
> >
> > -    if ( is_hvm_domain(d) )
> > -    {
> > -        if ( is_hardware_domain(d) &&
> > -             emflags !=3D (X86_EMU_VPCI | X86_EMU_LAPIC | X86_EMU_IOAP=
IC) )
> > -            return false;
> > -        if ( !is_hardware_domain(d) &&
> > -             /* HVM PIRQ feature is user-selectable. */
> > -             (emflags & ~X86_EMU_USE_PIRQ) !=3D
> > -             (X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ)) &&
> > -             emflags !=3D X86_EMU_LAPIC )
> > -            return false;
> > -    }
> > -    else if ( emflags !=3D 0 && emflags !=3D X86_EMU_PIT )
> > -    {
> > -        /* PV or classic PVH. */
> > -        return false;
> > -    }
> > +    for ( i =3D 0; i < ARRAY_SIZE(configs); i++ )
> > +        if ( (caps & configs[i].caps) =3D=3D caps &&
> > +             (emflags & ~configs[i].opt) =3D=3D configs[i].min )
> > +            return true;
> >
> > -    return true;
> > +    return false;
> >   }
> >
> >   void __init arch_init_idle_domain(struct domain *d)
>=20
>=20
> Teddy Astie | Vates XCP-ng Developer
>=20
> XCP-ng & Xen Orchestra - Vates solutions
>=20
> web: https://vates.tech
>=20
>=20



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 14:45:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 14:45:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011034.1389321 (Exim 4.92)
	(envelope-from )
	id 1uP0E5-0000yP-T7; Tue, 10 Jun 2025 14:45:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011034.1389321; Tue, 10 Jun 2025 14:45: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 1uP0E5-0000yI-QN; Tue, 10 Jun 2025 14:45:21 +0000
Received: by outflank-mailman (input) for mailman id 1011034;
 Tue, 10 Jun 2025 14:45: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 1uP0E4-0000yC-Lu
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 14:45:20 +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 86f99796-4609-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 16:45:18 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 86f99796-4609-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1749566717; x=1749825917;
	bh=j8NChAoRRghHkw6bMdTgGH+7hSXGauASCqa0irGPmnE=;
	h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
	 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector:
	 List-Unsubscribe:List-Unsubscribe-Post;
	b=igWk0BbFYPUYflBR7P2G83gBqaHtDuV8TBMtx+BcbgaBK0txXjenS+bQc5frpT0db
	 yGMZFEQIP4El/tTlC937x3RRxUKcNTJWrHLyUdurp00u5LMU+LOGewogQWwKnrCWFf
	 5ztW81NrLauZqR/HcdDtLncA68QJi5x9cFVTm7rQx9jvtCqjO8EuzQ+1r/UqmD6F4W
	 v0pmPeX40Ythl2mZDcQrB/i0lJs9dPx+XkLRincAfntnyeNiFCK2Qe5qvd3HPvwyq4
	 HitoELmBlCkqYYXrozXy4Lg1L8rf/GSHpvMhALjDZzVntvQIEf/aSnt5U/X/l5ybpT
	 blI1pW0Nta+tA==
Date: Tue, 10 Jun 2025 14:45:12 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com
Subject: [PATCH v7] xen/domain: rewrite emulation_flags_ok()
Message-ID: <20250610144500.3176661-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 15c94af66adda4f24e222cb211be6c59b2f8fe66
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Rewrite emulation_flags_ok() to simplify future modifications.

No functional change intended.

Signed-off-by: Denis Mukhin 
---
Changes since v6:
- simplified checks for PV further

Link to v6: https://lore.kernel.org/xen-devel/20250610004216.3012253-1-dmuk=
hin@ford.com/
Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/1=
862559089
---
 xen/arch/x86/domain.c | 78 +++++++++++++++++++++++++++++++++----------
 1 file changed, 60 insertions(+), 18 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 7536b6c871..fdbd064ebf 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -743,32 +743,74 @@ int arch_sanitise_domain_config(struct xen_domctl_cre=
atedomain *config)
     return 0;
 }
=20
+/*
+ * Verify that the domain's emulation flags resolve to a supported configu=
ration.
+ *
+ * This ensures we only allow a known, safe subset of emulation combinatio=
ns
+ * (for both functionality and security). Arbitrary mixes are likely to ca=
use
+ * errors (e.g. null pointer dereferences).
+ *
+ * NB: use the internal X86_EMU_XXX symbols, not the public XEN_X86_EMU_XX=
X
+ * symbols.
+ */
 static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
 {
+    enum {
+        CAP_PV          =3D BIT(0, U),
+        CAP_HVM         =3D BIT(1, U),
+        CAP_HWDOM       =3D BIT(2, U),
+        CAP_DOMU        =3D BIT(3, U),
+    };
+    static const struct {
+        unsigned int caps;
+        uint32_t min;
+        uint32_t opt;
+    } configs[] =3D {
+#ifdef CONFIG_PV
+        /* PV dom0 and domU */
+        {
+            .caps   =3D CAP_PV | CAP_HWDOM | CAP_DOMU,
+            .opt    =3D X86_EMU_PIT,
+        },
+#endif /* #ifdef CONFIG_PV */
+
+#ifdef CONFIG_HVM
+        /* PVH dom0 */
+        {
+            .caps   =3D CAP_HVM | CAP_HWDOM,
+            .min    =3D X86_EMU_LAPIC | X86_EMU_IOAPIC | X86_EMU_VPCI,
+        },
+
+        /* PVH domU */
+        {
+            .caps   =3D CAP_HVM | CAP_DOMU,
+            .min    =3D X86_EMU_LAPIC,
+        },
+
+        /* HVM domU */
+        {
+            .caps   =3D CAP_HVM | CAP_DOMU,
+            .min    =3D X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ),
+            /* HVM PIRQ feature is user-selectable. */
+            .opt    =3D X86_EMU_USE_PIRQ,
+        },
+#endif /* #ifdef CONFIG_HVM */
+    };
+    unsigned int i;
+    unsigned int caps =3D (is_pv_domain(d) ? CAP_PV : CAP_HVM) |
+                        (is_hardware_domain(d) ? CAP_HWDOM : CAP_DOMU);
+
 #ifdef CONFIG_HVM
     /* This doesn't catch !CONFIG_HVM case but it is better than nothing *=
/
     BUILD_BUG_ON(X86_EMU_ALL !=3D XEN_X86_EMU_ALL);
 #endif
=20
-    if ( is_hvm_domain(d) )
-    {
-        if ( is_hardware_domain(d) &&
-             emflags !=3D (X86_EMU_VPCI | X86_EMU_LAPIC | X86_EMU_IOAPIC) =
)
-            return false;
-        if ( !is_hardware_domain(d) &&
-             /* HVM PIRQ feature is user-selectable. */
-             (emflags & ~X86_EMU_USE_PIRQ) !=3D
-             (X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ)) &&
-             emflags !=3D X86_EMU_LAPIC )
-            return false;
-    }
-    else if ( emflags !=3D 0 && emflags !=3D X86_EMU_PIT )
-    {
-        /* PV or classic PVH. */
-        return false;
-    }
+    for ( i =3D 0; i < ARRAY_SIZE(configs); i++ )
+        if ( (caps & configs[i].caps) =3D=3D caps &&
+             (emflags & ~configs[i].opt) =3D=3D configs[i].min )
+            return true;
=20
-    return true;
+    return false;
 }
=20
 void __init arch_init_idle_domain(struct domain *d)
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Tue Jun 10 15:17:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 15:17:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011040.1389331 (Exim 4.92)
	(envelope-from )
	id 1uP0j2-0005Qk-9Q; Tue, 10 Jun 2025 15:17:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011040.1389331; Tue, 10 Jun 2025 15:17:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uP0j2-0005Qd-6m; Tue, 10 Jun 2025 15:17:20 +0000
Received: by outflank-mailman (input) for mailman id 1011040;
 Tue, 10 Jun 2025 15:17:18 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uP0j0-0005QX-Rf
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 15:17:18 +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 fec89b6c-460d-11f0-a307-13f23c93f187;
 Tue, 10 Jun 2025 17:17:17 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-4530921461aso22357035e9.0
 for ; Tue, 10 Jun 2025 08:17:17 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a53244f04dsm12510034f8f.73.2025.06.10.08.17.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 08:17:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fec89b6c-460d-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749568637; x=1750173437; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=b+EI1t4yLwz4LE9dJEOj7asJ8CJKXkDQIPd3rCYuxJE=;
        b=DHC4Coe3zPyeEjCloJbk8Z+BY92QI0i6yS4RPRHonCmNKcj4ai9z3Jse8o0PYQlglj
         rWBalsypyC718XyuYi2hLsKCrKToUAagFwJiFd8jL8Zo5lb/bzohfxbO7oxJFBSblevc
         3uzqqyD8y6Iw3pCAcDFsEKyGnmO8ZO4cplsdIgEJM/OvK+IVmDRJjtS1gk8e9GPbKtAN
         gYLO0t+2znKHS3zzb2MZR1GaYXDzJPnLeuHcalxyWxXqCYLR2RlMufuqBdvYd6qHIMAU
         UkuuNhfX9wlin7ucfHLd6F19WNro8RZoTUsMMalWKBNIN71LApHe3WNyomO95poTQeEM
         FAXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749568637; x=1750173437;
        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=b+EI1t4yLwz4LE9dJEOj7asJ8CJKXkDQIPd3rCYuxJE=;
        b=aP0DPDazoNqufOAodNPSyT0ruE60LRB3/VLYrwy1K3Vrm1XDRrIjZakIulSQpLC5KT
         1YJNoW+zNuuMW1Qc4cKhO4V1eSgzCZvZyqD4qw+NYrUp1YRYzEqSNdow597pi8g0YGRx
         BkFqhv807iQNu/1z6e7BWwzsLSSWZZjYREMYmQbawtbInLocGDd1giikDPSXcDDOnv4Y
         XG65euTbnscqeBDlPdNy2Z0JTt0dd3it+EffUYsjEcXSfkjuUHQY0LbDH/QSChkFHA7j
         z88XAP7v89M7JSifMuSw+QuEK2oISEFq91DnxCkajyIjCH9qtBJqVDhTum/2dO6w6ZZ5
         x5Gg==
X-Forwarded-Encrypted: i=1; AJvYcCUY0gyndMO3wkTJeZ33g8OT2FT4mlltbkQuM/qj5hbvtZwyjO61MAOouGX6X0mAWitdzoPDiTrzI4E=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz17uduoot9psYpuNTvb/hFyBfTV7Cy5TCWbVgUT48hRDbjzyqf
	3sL9KQ+j+zMSmaHAnI+yWoociIdwKyYAV6/pYFpB9I43XxCqjtT/6H4rSKuqrDqvhw==
X-Gm-Gg: ASbGncsHDVw1guJwiOEJHB+5V4+D4O5xAxklrWK5r4KQNqCTIny7plTYYFj9hQkPzJa
	pKM/ZV+c6PfYhxyHj/uobh07C0TYFbWy7PK+627SGtGUAo20KpMt38AtUBFCkFJ1QZoWktsjooo
	48l/iJL9/k4rMhcaUUStCilpWfa4JPSMmcx1JbUi6zPP4yBKse4mEzvkOvNMynPRZ+3hrs30agO
	RLTE1A07CHNRAwHNLaGu99Oq41naq1Sc1Aaerc8gEPKsRz73JjqFKTTXefBn6RMchXFmtnKSzm+
	+7e3C566FFLjKkX6dFTDT0EZj9qOo3k/mbAnb8Slspn8LvE87//1YSaxQwoiVyaeavn/+RPArPc
	Am1pF1upaEs57r9hGesEnn5+j4GghlJh7Hpd2+I/1hLNSfFo6+pmJKaIEsUENeT8MkmRRiiQLO6
	E3cMFQjutRHz0Q1jlkinBx
X-Google-Smtp-Source: AGHT+IEK/l8vRvV8bzq+OsDJafI7PCcN9/JhQgBohhVEiRXPqIdQFNvmrpCDz3GXJR1cyausbfI0aA==
X-Received: by 2002:a05:6000:188f:b0:3a4:f7dc:8a62 with SMTP id ffacd0b85a97d-3a531453ce7mr13059408f8f.0.1749568636615;
        Tue, 10 Jun 2025 08:17:16 -0700 (PDT)
Message-ID: <910ea6a2-2bd1-4499-bdb1-debc4a778502@suse.com>
Date: Tue, 10 Jun 2025 17:17:15 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 3/9] xen/riscv: imsic_init() implementation
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 ,
 Romain Caritey , 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 05.06.2025 17:58, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/imsic.c
> @@ -0,0 +1,358 @@
> +/* SPDX-License-Identifier: MIT */
> +
> +/*
> + * xen/arch/riscv/imsic.c
> + *
> + * RISC-V Incoming MSI Controller support
> + *
> + * (c) Microchip Technology Inc.
> + * (c) Vates
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#define IMSIC_HART_SIZE(guest_bits_) (BIT(guest_bits_, U) * IMSIC_MMIO_PAGE_SZ)

Minor: Any particular reason for the trailing underscore here?

> +/*
> + * Initialize the imsic_cfg structure based on the IMSIC DT node.
> + *
> + * Returns 0 if initialization is successful, a negative value on failure,
> + * or IRQ_M_EXT if the IMSIC node corresponds to a machine-mode IMSIC,
> + * which should be ignored by the hypervisor.
> + */
> +int __init imsic_init(const struct dt_device_node *node)
> +{
> +    int rc;
> +    unsigned long reloff, hartid;
> +    unsigned int nr_parent_irqs, index, nr_handlers = 0;
> +    paddr_t base_addr;
> +    unsigned int nr_mmios;
> +    struct imsic_mmios *mmios;
> +    struct imsic_msi *msi = NULL;
> +
> +    /* Parse IMSIC node */
> +    rc = imsic_parse_node(node, &nr_parent_irqs, &nr_mmios);
> +    /*
> +     * If machine mode imsic node => ignore it.
> +     * If rc < 0 => parsing of IMSIC DT node failed.
> +     */
> +    if ( (rc == IRQ_M_EXT) || (rc < 0) )
> +        return rc;
> +
> +    /* Allocate MMIO resource array */
> +    mmios = xvzalloc_array(struct imsic_mmios, nr_mmios);
> +    if ( !mmios )
> +    {
> +        rc = -ENOMEM;
> +        goto imsic_init_err;
> +    }
> +
> +    msi = xvzalloc_array(struct imsic_msi, nr_parent_irqs);
> +    if ( !msi )
> +    {
> +        rc = -ENOMEM;
> +        goto imsic_init_err;
> +    }
> +
> +    /* Check MMIO register sets */
> +    for ( unsigned int i = 0; i < nr_mmios; i++ )
> +    {
> +        unsigned int guest_bits = imsic_cfg.guest_index_bits;
> +        unsigned long expected_mmio_size =
> +            IMSIC_HART_SIZE(guest_bits) * nr_parent_irqs;
> +
> +        rc = dt_device_get_address(node, i, &mmios[i].base_addr,
> +                                   &mmios[i].size);
> +        if ( rc )
> +        {
> +            printk(XENLOG_ERR "%s: unable to parse MMIO regset %u\n",
> +                   node->name, i);
> +            goto imsic_init_err;
> +        }
> +
> +        base_addr = mmios[i].base_addr;
> +        base_addr &= ~(BIT(guest_bits +
> +                           imsic_cfg.hart_index_bits +
> +                           IMSIC_MMIO_PAGE_SHIFT, UL) - 1);
> +        base_addr &= ~((BIT(imsic_cfg.group_index_bits, UL) - 1) <<
> +                       imsic_cfg.group_index_shift);
> +        if ( base_addr != imsic_cfg.base_addr )
> +        {
> +            rc = -EINVAL;
> +            printk(XENLOG_ERR "%s: address mismatch for regset %u\n",
> +                   node->name, i);
> +            goto imsic_init_err;
> +        }
> +
> +        if ( mmios[i].size != expected_mmio_size )
> +        {
> +            rc = -EINVAL;
> +            printk(XENLOG_ERR "%s: IMSIC MMIO size is incorrect %ld, "
> +                   "expeced MMIO size: %ld\n", node->name, mmios[i].size,

To aid grep-ability, please avoid wrapping format strings across lines.
(Same at least once more elsewhere.)

> +                   expected_mmio_size);
> +            goto imsic_init_err;
> +        }
> +    }
> +
> +    /* Configure handlers for target CPUs */
> +    for ( unsigned int i = 0; i < nr_parent_irqs; i++ )
> +    {
> +        unsigned long cpu;

Along the lines of questions on earlier versions: Any reason this isn't
unsigned int?

> +        rc = imsic_get_parent_hartid(node, i, &hartid);
> +        if ( rc )
> +        {
> +            printk(XENLOG_WARNING "%s: cpu ID for parent irq%u not found\n",
> +                   node->name, i);
> +            continue;
> +        }
> +
> +        cpu = hartid_to_cpuid(hartid);
> +
> +        if ( cpu >= num_possible_cpus() )
> +        {
> +            printk(XENLOG_WARNING "%s: unsupported hart ID=%#lx for parent "
> +                   "irq%u\n", node->name, hartid, i);
> +            continue;
> +        }
> +
> +        /* Find MMIO location of MSI page */
> +        reloff = i * BIT(imsic_cfg.guest_index_bits, UL) * IMSIC_MMIO_PAGE_SZ;

Any reason to open-code IMSIC_HART_SIZE() here and ...

> +        for ( index = 0; index < nr_mmios; index++ )
> +        {
> +            if ( reloff < mmios[index].size )
> +                break;
> +
> +            /*
> +             * MMIO region size may not be aligned to
> +             * BIT(global->guest_index_bits) * IMSIC_MMIO_PAGE_SZ
> +             * if holes are present.
> +             */
> +            reloff -= ROUNDUP(mmios[index].size,
> +                      BIT(imsic_cfg.guest_index_bits, UL) * IMSIC_MMIO_PAGE_SZ);

... here?

> +        }
> +
> +        if ( index == nr_mmios )
> +        {
> +            printk(XENLOG_WARNING "%s: MMIO not found for parent irq%u\n",
> +                   node->name, i);
> +            continue;
> +        }
> +
> +        if ( !IS_ALIGNED(msi[cpu].base_addr + reloff,

DYM mmios[index].base_addr here, considering that ...

> +                         IMSIC_MMIO_PAGE_SZ) )
> +        {
> +            printk(XENLOG_WARNING "%s: MMIO address %#lx is not aligned on "
> +                   "a page\n", node->name, msi[cpu].base_addr + reloff);
> +            msi[cpu].offset = 0;
> +            msi[cpu].base_addr = 0;
> +            continue;
> +        }
> +
> +        msi[cpu].base_addr = mmios[index].base_addr;
> +        msi[cpu].offset = reloff;

msi[cpu] is set only here?

Also is the setting to zero of both fields on the "continue" path really
needed, seeing that the array starts out zero-filled? Can the same CPU
be found twice, making it necessary(?) to invalidate the array slot later?

> +        nr_handlers++;
> +    }
> +
> +    if ( !nr_handlers )
> +    {
> +        printk(XENLOG_ERR "%s: No CPU handlers found\n", node->name);
> +        rc = -ENODEV;
> +        goto imsic_init_err;
> +    }
> +
> +    imsic_cfg.msi = msi;
> +
> +    XFREE(mmios);

No need to use the macro, and you really mean xvfree() now.

> +    return 0;
> +
> + imsic_init_err:
> +    XFREE(mmios);
> +    XFREE(msi);

Same here.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 15:22:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 15:22:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011046.1389342 (Exim 4.92)
	(envelope-from )
	id 1uP0nv-00077G-RV; Tue, 10 Jun 2025 15:22:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011046.1389342; Tue, 10 Jun 2025 15:22:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uP0nv-000779-Nl; Tue, 10 Jun 2025 15:22:23 +0000
Received: by outflank-mailman (input) for mailman id 1011046;
 Tue, 10 Jun 2025 15:22: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 1uP0nu-000773-4t
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 15:22:22 +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 b3f888fa-460e-11f0-a307-13f23c93f187;
 Tue, 10 Jun 2025 17:22:21 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-441d437cfaaso35600725e9.1
 for ; Tue, 10 Jun 2025 08:22:21 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-452730b9caasm141001195e9.20.2025.06.10.08.22.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 08:22:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b3f888fa-460e-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749568941; x=1750173741; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=tmmGaEsnvDUjUnQl8JBKrdKWGYxP5naWay+hjidSRKg=;
        b=MUFkoZROp95LKWqr2drYz3xfMUSgnXKBKRPrX/gjZmDL2jLlgub4f2Gn/2R599G1Pg
         rp0W7yvmFPThdRg9dQsAXt2NpX92TuyznDXqnx9EDhefLyBG4CrNHZz6RiM32znfwNhA
         YrNMq8tUj31BkJVCDOdHiGIDD4q1ukWvALM5MVyIWIj2ocrfEnGg200fucejT90GIL8W
         QgV/9RpWRhccRsJwwD6WEVqcwQblDuGfQ4J394mIS+fwa48QA1tbt5H6IkXp/fuquons
         xdP1qZD8l1SvbV5vEcSiOFbRB9yxW2dCI+8q5K8WJVgIwLpan1S7QhJvWcowv/SozND1
         5gMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749568941; x=1750173741;
        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=tmmGaEsnvDUjUnQl8JBKrdKWGYxP5naWay+hjidSRKg=;
        b=V/kzzxJxaS9ISFREXcerhro47T3LxtOUWkKy3mpKirW5L+byHQd0JcmpgPj78HnJt4
         0gIeh1FabGsXcTV1SJsHyZ3LjmZ4e6sHRS0cbS3/99TZX3zF/666yX6nnnecbYaFMdZu
         0l+iQZMf/6q7oXpgfB1BQR0P1vxmGLy86GrX1+i2JyfMo1ik2wHrfi8OHOxsWOMfustd
         DntY857v9aZ1bnZIvBjSrrrp1u1lKsfFaez+U3Eve9Ivo4fqVVguD/wp6UA1BpXbt301
         1uTIJIVEXDmryqZJLDnqYiWCE+PIrS4FGD+MFMEB9MIab45gJyQfCIHgbV3FhMYjVnkH
         XbJA==
X-Forwarded-Encrypted: i=1; AJvYcCVCSXxIxxfHKvsFFmdh/jThyg26LRT7sYGnzrO8nvKIG2fCARYxsn5CcZLynIQUo8Q7HD6ZNGeMw0s=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy0ZG1rdaVjyuoiHmEIH1YFrdydDX2qZjjgKfvgeuTSKMXAg4+w
	NdRB+etAU9VREcKcwMDg1cVq9P8zbZE/7qv/tK3IrH6OwBSRZaJKmXV/UISNjRomJw==
X-Gm-Gg: ASbGnctGYqP/E9TJ45pZEMc2a2+B8Pq7AZ9F4gvHaHAlj4jVK4u+3CfpSC1F/lcSFZb
	Kcq6AEGYNM8PpAbGIIih+XKR130HOCP62wASt/ZYAJEWsfSw0N+1L40ehDshUcqDr/60UnIOiTl
	qu+XlBQcw6jSaVXFN23jqsMnthocMljjC8wgYnbeHJTbdLz30Vn7aRPV2p6Wlaqde9qfW+DnIM2
	tDAJRUzWCbwcisHFGyAQpRurbJhESLq2UG3tjJJtPLzSnRYHIaXI5gEcWjGj/r+/KR32Z5l5QLn
	63afsMBckk3gqYov5CY3OV73iKt/Nb20dY5Xea8CFE/wYf3xI5pLepktAhRMckYVO3LFa/gXMPG
	SKAVl9CpMH9KBWHd8YUjp3+n+OFlJtWujh56E5I8U20+byi73vvZxdQLZVEIFpbZPJVE9Yl3iFC
	zOFM2PWPVG9lNFKQPFBNLt
X-Google-Smtp-Source: AGHT+IHNG/tq0IcOnNuzIA/MX+dFPVzd5OruvC4r13JTdmcr9HHZMOGCXxdhk8VFPhyErevx8WpgPw==
X-Received: by 2002:a05:600c:1e8a:b0:450:d37d:7c with SMTP id 5b1f17b1804b1-452014976b1mr149242475e9.21.1749568940641;
        Tue, 10 Jun 2025 08:22:20 -0700 (PDT)
Message-ID: <17943f73-8123-40c1-91cb-56dac6e1976e@suse.com>
Date: Tue, 10 Jun 2025 17:22:19 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 4/9] xen/riscv: aplic_init() implementation
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 ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <1913a653568d51ed630dbbda1e1364b41aa5db89.1749121437.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: <1913a653568d51ed630dbbda1e1364b41aa5db89.1749121437.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 05.06.2025 17:59, Oleksii Kurochko wrote:
> +static int __init cf_check aplic_init(void)
> +{
> +    dt_phandle imsic_phandle;
> +    const __be32 *prop;
> +    uint64_t size, paddr;
> +    const struct dt_device_node *imsic_node;
> +    const struct dt_device_node *node = aplic_info.node;
> +    int rc;
> +
> +    /* Check for associated imsic node */
> +    if ( !dt_property_read_u32(node, "msi-parent", &imsic_phandle) )
> +        panic("%s: IDC mode not supported\n", node->full_name);
> +
> +    imsic_node = dt_find_node_by_phandle(imsic_phandle);
> +    if ( !imsic_node )
> +        panic("%s: unable to find IMSIC node\n", node->full_name);
> +
> +    rc = imsic_init(imsic_node);
> +    if ( rc == IRQ_M_EXT )
> +        /* Machine mode imsic node, ignore this aplic node */
> +        return 0;
> +
> +    if ( rc )
> +        panic("%s: Failded to initialize IMSIC\n", node->full_name);

Nit: Stray 'd'.

> +    /* Find out number of interrupt sources */
> +    if ( !dt_property_read_u32(node, "riscv,num-sources",
> +                               &aplic_info.num_irqs) )
> +        panic("%s: failed to get number of interrupt sources\n",
> +              node->full_name);
> +
> +    if ( aplic_info.num_irqs > ARRAY_SIZE(aplic.regs->sourcecfg) )
> +        aplic_info.num_irqs = ARRAY_SIZE(aplic.regs->sourcecfg);
> +
> +    prop = dt_get_property(node, "reg", NULL);
> +    dt_get_range(&prop, node, &paddr, &size);
> +    if ( !paddr )
> +        panic("%s: first MMIO resource not found\n", node->full_name);
> +
> +    if ( !IS_ALIGNED(paddr, KB(4)) )
> +        panic("%s: paddr of memory-mapped control region should be 4Kb "
> +              "aligned:%#lx\n", __func__, paddr);
> +
> +    if ( !IS_ALIGNED(size, KB(4)) && (size < KB(16)) )

DYM || instead of && here?

> +        panic("%s: memory-mapped control region should be a multiple of 4 KiB "
> +              "in size and the smallest valid control is 16Kb: %#lx\n",
> +              __func__, size);

Here and above: See my remark on the earlier patch regarding the wrapping
of format strings.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 15:27:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 15:27:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011055.1389352 (Exim 4.92)
	(envelope-from )
	id 1uP0sS-0007kU-Gr; Tue, 10 Jun 2025 15:27:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011055.1389352; Tue, 10 Jun 2025 15:27: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 1uP0sS-0007kN-DW; Tue, 10 Jun 2025 15:27:04 +0000
Received: by outflank-mailman (input) for mailman id 1011055;
 Tue, 10 Jun 2025 15:27: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 1uP0sR-0007kH-Ai
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 15:27:03 +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 573f5511-460f-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 17:26:55 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a503d9ef59so4690444f8f.3
 for ; Tue, 10 Jun 2025 08:26:55 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a53229e014sm12527194f8f.3.2025.06.10.08.26.53
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 08:26:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 573f5511-460f-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749569215; x=1750174015; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=EJHvElI3KNhjRfVxoLk49hH8Wf1ZGRCL8DjojWz/gWE=;
        b=cVoxK7ocsIIb1Fj/XODSxoApE7BcM+PnRxBpubBgrggL96RfsLHkrqJkl0yjnVrOss
         BsqoWZ4ySiyX2CX86ikEaJ3TtKkxTvwn29L1z5S820+yaORvoWYT4JPukrubxjv8FKSq
         PvEUSAOLj5P/BcTUnSXTV1vFnz/0y4vGolM9m75lt6KZ7Zd7CJrr4aLKyjnqx/nJ5xbQ
         lkyjMmtRuVbh7bp2qJvNarUBd637Je/rtcNJ4fRIzGx0RFqkRvavsN1nIhmbSZtuqPa1
         k4QLroYqDWRCvytzL3DWedtVs5GWx+Si8lxoISeWaFjWHoiXtly2w44mn0u5kauq4Wd+
         xeVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749569215; x=1750174015;
        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=EJHvElI3KNhjRfVxoLk49hH8Wf1ZGRCL8DjojWz/gWE=;
        b=U8AXv+gWqhTwsqCyTXs9iDq/KfwgQD8wDhnzhv+/Tr2AGhHQXNzVgfb2pfaUMpzeRY
         NroWyOexyah3ed5jlBIiDCdNL1M4kNdqKgudTwAOJbC8muegPqmzWLfvH/RelNKdESXQ
         ikVNpL7hIfR01ycb1C0PoXzjAKhEpMdTQSqzAM+Tu/ssW1TH5Rca38lCi/1v9644VRC+
         F/IMWOs4dNeJQEYM8otIJ4XfdIG4VWEFo7wA6ZAvytcyfT3t7iH8ZwwHYBA8Vpq60uIp
         +7L5BfAs3qQY4qxU0I24BpEGhiqo67nxhVjkVVQkcDb+GqguyGEeZb/THvTXJu1AJ1/x
         9C3Q==
X-Forwarded-Encrypted: i=1; AJvYcCW8cwSwjjM8MBMmzQHbcduEVnu2cemE5sk4UIjj9zVzKfOHOnzifgWfDWHqTrSou6IQSlCPVmFahuQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxP9K8im2WRhsNWEXkgCoZ3YEcm5ty7jAvrFSgd7DlBnzGWnUIe
	F8cp8SZK0cK7s3McVXR+I56cnPZof+zbLXX40KasoS1v+4yEG4jsj+FXPWJmvdzexA==
X-Gm-Gg: ASbGnctxpHIZFX5Ny3sINSeNGMQh/n5v3B9Tw8rFB7BVVZm1/8MrglDmQbxqq6X9eWc
	RRq4l5fClOVo5S2DDZTlucv/Z9UGq7wWZXAqH2qV2l4sO3S2hXW5sIOlmhdNJJMEpukQ1QOi1xV
	MIFCQcEWLpXGXKYIt5SqosRd4ZEwa+PLWuWVPOR5JpWx53+mORUps/PZ9UlxF0qlFmSxp46gFyZ
	wpLmOuKffWzMTQHCAiTXNhldm0E8kW+Mg/c1hff3fuWsukc5MDWsUpmWbpTg2g6AEsZ524HmNwX
	Xr8XG4eVQjikxXtlj1BH/BeEOno2vkGs4bzao/K/yvSWqRZSvBdJbLV2UvSwlRopleYjoSMGQPj
	ncWaFIGBulMkS7e3D0s/RWSNlFPAQKiKgqASucpVpcyJVpmIkObSrCGR1fkcnc0gCxFs/DIUs5K
	vSiZb0rm0QjiIHJeI+G/Gi
X-Google-Smtp-Source: AGHT+IGTp7klgxZ2iBkdgy2VXV3eo2EX4dr++tru2KhxzhCWUJ3ai1p6g1uF3qjYQy4pAZYcY9yDeA==
X-Received: by 2002:a05:6000:26c8:b0:3a3:7077:aba1 with SMTP id ffacd0b85a97d-3a531ce677bmr14547341f8f.48.1749569214662;
        Tue, 10 Jun 2025 08:26:54 -0700 (PDT)
Message-ID: <072c6c93-7633-4662-982d-e57697993eed@suse.com>
Date: Tue, 10 Jun 2025 17:26:53 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 6/9] xen/riscv: implementation of aplic and imsic
 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 ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <2135173f5ca0e43b54e97052c221ba04c25f830c.1749121437.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: <2135173f5ca0e43b54e97052c221ba04c25f830c.1749121437.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 05.06.2025 17:59, Oleksii Kurochko wrote:
> Introduce interrupt controller descriptor for host APLIC to describe
> the low-lovel hardare. It includes implementation of the following functions:
>  - aplic_irq_startup()
>  - aplic_irq_enable()
>  - aplic_irq_disable()
>  - aplic_set_irq_affinity()
> 
> As APLIC is used in MSI mode it requires to enable/disable interrupts not
> only for APLIC but also for IMSIC. Thereby for the purpose of
> aplic_irq_{enable,disable}() it is introduced imsic_irq_{enable,disable)().
> 
> For the purpose of aplic_set_irq_affinity() aplic_get_cpu_from_mask() is
> introduced to get hart id.
> 
> Also, introduce additional interrupt controller h/w operations and
> host_irq_type for APLIC:
>  - aplic_host_irq_type
> 
> Patch is based on the code from [1].
> 
> [1] https://gitlab.com/xen-project/people/olkur/xen/-/commit/7390e2365828b83e27ead56b03114a56e3699dd5
> 
> Co-developed-by: Romain Caritey 
> Signed-off-by: Oleksii Kurochko 

Acked-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 15:28:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 15:28:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011061.1389362 (Exim 4.92)
	(envelope-from )
	id 1uP0tU-0008F4-PY; Tue, 10 Jun 2025 15:28:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011061.1389362; Tue, 10 Jun 2025 15:28: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 1uP0tU-0008Ex-Mr; Tue, 10 Jun 2025 15:28:08 +0000
Received: by outflank-mailman (input) for mailman id 1011061;
 Tue, 10 Jun 2025 15:28: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 1uP0tT-0008Ep-UP
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 15:28:07 +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 81e1e13a-460f-11f0-a307-13f23c93f187;
 Tue, 10 Jun 2025 17:28:06 +0200 (CEST)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-451d54214adso46144255e9.3
 for ; Tue, 10 Jun 2025 08:28:06 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45320562afbsm12568675e9.1.2025.06.10.08.27.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 08:27:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 81e1e13a-460f-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749569286; x=1750174086; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=tqewLUe37tMoevGPwcE5luilrW8eHUYK8jhzkI1O3Fo=;
        b=Gpc0oJW3uM2tXKmpA6pgtyecNpRG74xNNrlao0Xl6/Tyuo7V1yMnsbP2aA1Ztnx/84
         dMkE+HbKzfSbMUOBGDB77bcGo5DXAufYih/TwB+mMaxwBG7TJln6df4aDA+UcUfyEcjb
         VMAoy9jfgHzb0eXavEubp/oSVS6rvRWo529y+SUfRX1c1SSCy90FStg9RGF9HycqW94r
         3iILapQOMyxSkVOe7zQFeHtLJMAfrkzlZhgWXqHh5q7lMsRUzdMPh0h9bt9p3ZwuukYZ
         lAdk3UyJUzz4knrqvfHJGv+PMR8yIGRQ9aTB253gJ63gE4VG4BqnTh4mLhZD9Tx3ZekH
         5Afw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749569286; x=1750174086;
        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=tqewLUe37tMoevGPwcE5luilrW8eHUYK8jhzkI1O3Fo=;
        b=eP32FjNBg3v4zvvwuuVevO47oBe42qwsvRsDGgMEnXtJoEsu9T3ytKjBYtqaD4crzc
         butuhPbSyeBG6V4hgsSZjbBnPswk8G9T/SvuRugnby0fVBc+5h+Xy/a9HRmXANHIqOay
         4vbYM0IWkipZjXVmMjwnW6rlA1rcVcrZQ7MbOEBWv7pyvAcBNZ9b87OUIqYE65+6UN4F
         gU4QRAy18r4x/YOJRfmx+o5TfPKmDilrVPaNmbtnKvJ7NMRx7PXIChOLM/+pCMfcqRfi
         l3fO5LL+Q3YBa7RJabxPpe3phtuTL3fGjbrsOmUiMCJJs8fiSWCFrntsoYwPbvad1h1x
         /rrA==
X-Forwarded-Encrypted: i=1; AJvYcCVUbslMg1/5G4Xg+yDavBGPc6n7FsxT2shs+MgPIdpcZKpH6nxOLl6szWjW9dcWDOdQ+ujwEsR9aeY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz15e8Pf2i/X8dbcvsO8/tjkUkecbmCjRz1OwmPv5pLctACe1ZE
	w5Ymk1Z4HAd1icqnrmHHM1K2blDS3YVO5x53nsAz/kowkul7Xp2j2CvvpthIY8YQ9w==
X-Gm-Gg: ASbGnctqsFwdclfR5vRaBk8tOSzCSs5ZU380qHEFVTqmEBquiQTmS5fPK+GFeBsReMN
	qJGZrb28j/6dhAsCRXyPVA89U8ZsK61EZt3Ho48E2LSwWYiVBRPYw9lUFik2aLztoAInj0Ljk/Y
	lSsrMRUBwCCZaoEPY35VBwfn1KMkYBKEvtj4yugJmNE/uHSntZXQSzbtgIyf0ABE9HJR4/WHR0d
	2hdl3PKurQWbjG2+26RPos/c2ZCw0nZ+LD7GWUB5RMH1fJS3ggMqRFK0Tpn14a4oN17wSQADoIC
	U5i2v6uyOFczyM7pIDB/H+UQ/9Skn4SG3qUO8hcntzIPQr2JxXQYYm7rbfzBj2iHj4+WlTY82N/
	WOxbaCi3N3szE6DiDpz6NMbcr4FQzqTcF6kASX65YBvx3qcOwuEqrnEcLQT/9hqoTIjBJvDLCJj
	gBcJy0I/a5VZ5/7kD0PwnRy4GDqNzgbkw=
X-Google-Smtp-Source: AGHT+IEvyOZ8IIrWwPKwqHpTUNUO2BXx9Y28dJiU7jIIBeBC5IHzVLsKF/l8Jr3+dy/CBRfPhZaq2A==
X-Received: by 2002:a05:600c:3493:b0:450:d386:1afb with SMTP id 5b1f17b1804b1-4531de060c7mr29299765e9.9.1749569279945;
        Tue, 10 Jun 2025 08:27:59 -0700 (PDT)
Message-ID: <5f9fa474-27b1-4628-8c38-bc3c779f96e8@suse.com>
Date: Tue, 10 Jun 2025 17:27:59 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 8/9] xen/riscv: implement setup_irq()
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 ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <4f2c15a95b1fb2720ba0643f668f080e8b390613.1749121437.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: <4f2c15a95b1fb2720ba0643f668f080e8b390613.1749121437.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 05.06.2025 17:59, Oleksii Kurochko wrote:
> Introduce support for IRQ setup on RISC-V by implementing setup_irq() and
> __setup_irq(), adapted and extended from an initial implementation by [1].
> 
> __setup_irq() does the following:
>   - Sets up an IRQ action.
>   - Validates that shared IRQs have non-NULL `dev_id` and are only used when
>     existing handlers allow sharing.
>   - Uses smp_wmb() to enforce memory ordering after assigning desc->action
>     to ensure visibility before enabling the IRQ.
>   - Supports multi-action setups via CONFIG_IRQ_HAS_MULTIPLE_ACTION.
> 
> setup_irq() does the following:
>   - Converts IRQ number to descriptor and acquires its lock.
>   - Rejects registration if the IRQ is already assigned to a guest domain,
>     printing an error.
>   - Delegates the core setup to __setup_irq().
>   - On first-time setup, disables the IRQ, routes it to Xen using
>     intc_route_irq_to_xen(), sets default CPU affinity (current CPU),
>     calls the handler’s startup routine, and finally enables the IRQ.
> 
> irq_set_affinity() invokes set_affinity() callback from the IRQ handler
> if present.
> 
> Defined IRQ_NO_PRIORITY as default priority used when routing IRQs to Xen.
> 
> [1] https://gitlab.com/xen-project/people/olkur/xen/-/commit/7390e2365828b83e27ead56b03114a56e3699dd5
> 
> Co-developed-by: Romain Caritey 
> Signed-off-by: Oleksii Kurochko 

Acked-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 15:31:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 15:31:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011066.1389372 (Exim 4.92)
	(envelope-from )
	id 1uP0wI-0001S6-67; Tue, 10 Jun 2025 15:31:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011066.1389372; Tue, 10 Jun 2025 15: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 1uP0wI-0001Rl-2c; Tue, 10 Jun 2025 15:31:02 +0000
Received: by outflank-mailman (input) for mailman id 1011066;
 Tue, 10 Jun 2025 15: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 1uP0wG-0001Rf-VC
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 15:31:00 +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 e940d162-460f-11f0-a307-13f23c93f187;
 Tue, 10 Jun 2025 17:31:00 +0200 (CEST)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3a54700a46eso1889203f8f.1
 for ; Tue, 10 Jun 2025 08:31:00 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a532461211sm12370299f8f.86.2025.06.10.08.30.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 08:30:50 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e940d162-460f-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749569459; x=1750174259; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=DbBSNw/aB5/M+fUL9gpTOZkK6sxxbPb2HOp2jJ79Q1I=;
        b=GDStk3A+xXDk5C+7glYoqAk+u92+EY5sI+RPjR4F+GvuZNkSDDY/8EuoeKDcY2G+XD
         oiy2QpkOl5q30oSKagZG+uYRoLr+Z0YZuOTWu+tkaSzE15n94tG28ACjyzKm6cqnoMT9
         klsN1KfpOI2qvdH+4vUOpXWHFieX0m4cNhDYbnLqeNauUvuxVyO7spCWMnYE8bGnq1vn
         UQLlJMreZ1D/mQg6u2S+LBHvagYAYloNJmrjTDnxFvMuyg9FWKyZJjH9dLUeg8JqhO1P
         7019w3wLfcF0n9t8XjgG8ZfGevwE627WN39cVGNsTl5xMkX+p9eT3pTUHdnXQvIwAUDM
         TLqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749569459; x=1750174259;
        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=DbBSNw/aB5/M+fUL9gpTOZkK6sxxbPb2HOp2jJ79Q1I=;
        b=NAlF+dE3WTGBIT434xpOHxyjd6WwEM33ctEpmEqm5jPX9nTNGnQCVqxtXzVGkJsDJc
         2zzq29sNeD7JJDpQxZ5ZnvHGxsslDpF7Y15zlfqT+XIhmdmPfb5ohr5Bn7VOM66OLVuu
         UN3DAGw1FFcCvwLnr/UqazfHC+KguWwqSreEW6oAizRtqLACRBMtsBSrn1JYfJvRXCzs
         CoP6lUeqqvqDrE2F5geV+iIvSAbj+QZWHzOMnZOS19cN+FeJ/QEd+vHQamOk9PKwwZE7
         8Gc9D1XRlqsKqD7kGP980ElizUb7XJ+RsaEJgxNr7s4GKlMUI2Mq8qLbhgUlqgh9eEy0
         Y3bg==
X-Forwarded-Encrypted: i=1; AJvYcCVE+0nDSMYMxlphsUHaDWqOI9k1MlgrGjJHZ71ZzjPXHEVcAiEFe0/rFDxq83OeFe3UQHbXP1b0Fis=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyAiGYa0/qMin4jiXWzLi5JY8uaZ02vAhq/TWra85zItK5MVhgX
	/wGK5tTJr37a2WA/2agrSV4Jlsq5reAYxIirtVVj4Omhte1BmNbr7sggTgNHMJx61Q==
X-Gm-Gg: ASbGncv0zD/MN/dmtT6ncnqYbwDsfeqsQrnedEimqp7aFioWymrx5rTWZVV9bnug63A
	+cJX7XWCz/eJQ7KRsmsXiY2Vj1hczrWFPH5fHnnCD1PTNOwtk8URAwB/MvWMra/xreRgJR9h/JT
	P9sKPkiXATzi7wmV9lwkPpgIYgr75iRh2mpo5hjwjOfJNrcydkhx4T+/RQWWX4rdSiBy4Lxe2eI
	nYy5UzP743qDyU5p1lDh96y091O+oQ1zQRSKgUoxuDn7ESo9XgxhMuBD5Mp+XSfQia626KYf5rz
	OK551mZdvZq51AnXVb2zWF0YSKoH0bPgRvsegOFZfNrNrbVvvu4I2EAppX4zrwrmr2i77pBLmIo
	pR8sOsP7Faz1ScCKXanQ5VMuxN6TYlF95UNMLpKcle8k/PwvsclGBgpucfOkTWDjILoVrDCFDaQ
	8qJNFw41sic1XHndop32Uc6K7nZZjiUQE=
X-Google-Smtp-Source: AGHT+IFeVuxE1icaRSKASKLMU6rRQiPlwMbk+bzvRcXkY99ADHiB7/SXZvN43aIUiDz68fbRuIo4Lg==
X-Received: by 2002:a05:6000:22c6:b0:3a4:d939:62f8 with SMTP id ffacd0b85a97d-3a55229bc3cmr2320014f8f.32.1749569450315;
        Tue, 10 Jun 2025 08:30:50 -0700 (PDT)
Message-ID: <31ee1063-f377-4ca4-ba58-241a16272e7a@suse.com>
Date: Tue, 10 Jun 2025 17:30:49 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/2] xen: Introduce system suspend config option
To: Mykola Kvach 
Cc: Mykyta Poturai ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini ,
 Mykola Kvach , xen-devel@lists.xenproject.org
References: 
 <412d2b68741182fe0528cb85c0af2a29a2ebec3a.1749204282.git.mykola_kvach@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: <412d2b68741182fe0528cb85c0af2a29a2ebec3a.1749204282.git.mykola_kvach@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.06.2025 12:11, Mykola Kvach wrote:
> From: Mykyta Poturai 
> 
> This option enables the system suspend support. This is the mechanism that
> allows the system to be suspended to RAM and later resumed.
> 
> The patch introduces three options:
> - HAS_SYSTEM_SUSPEND: indicates suspend support is available on the platform.
> - SYSTEM_SUSPEND_ALWAYS_ON: used for architectures where suspend must always
>   be enabled.
> - SYSTEM_SUSPEND: user-facing option to enable/disable suspend if supported.
>   Defaults to enabled if SYSTEM_SUSPEND_ALWAYS_ON is set and depends on
>   HAS_SYSTEM_SUSPEND.
> 
> On x86, both HAS_SYSTEM_SUSPEND and SYSTEM_SUSPEND_ALWAYS_ON are selected by
> default, making suspend support always enabled. The options are designed to
> be easily extensible to other architectures (e.g., PPC, RISC-V) as future
> support is added.
> 
> Signed-off-by: Mykyta Poturai 
> Signed-off-by: Mykola Kvach 

Acked-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 15:46:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 15:46:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011073.1389382 (Exim 4.92)
	(envelope-from )
	id 1uP1Aj-0003UT-D0; Tue, 10 Jun 2025 15:45:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011073.1389382; Tue, 10 Jun 2025 15:45:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uP1Aj-0003UM-93; Tue, 10 Jun 2025 15:45:57 +0000
Received: by outflank-mailman (input) for mailman id 1011073;
 Tue, 10 Jun 2025 15:45: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 1uP1Ai-0003UF-37
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 15:45:56 +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 fde3bfe0-4611-11f0-a307-13f23c93f187;
 Tue, 10 Jun 2025 17:45:53 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a4f72cba73so4605190f8f.1
 for ; Tue, 10 Jun 2025 08:45:53 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a5322aa3c0sm12450902f8f.22.2025.06.10.08.45.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 08:45:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fde3bfe0-4611-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749570353; x=1750175153; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ye4BOMohhlw7Z0BEcrYqBlRvGxBbQ5Cho9rGrm3TBps=;
        b=AfNDJT9OWSq9SAazRRvGHcwGLdwsZJKrcCoUQKkyDzm6MfUwHXbjmb439jif8TWF0q
         gs0sGbrrhCBMVmi3b8N7qVD3CEBLFVSqzUHYPT4bkHWFFMFKPhl3VuSC4/SX6DCYhX8g
         fDHQ2Ygtxcs4/3smushhRQ3v+euGygnC7Lf5HtnGB2/3zz/Y/8s6DOvVjT6m4WHF174W
         YBm6GtjXl5bULYNNEJyKP74hGwuSLt3hRnNyPIVla2VhEEX2C3kkbC9LXMgDqcgtwOX9
         AHFhLMPmvrGdr6Q04PevVvD3ze8ex+BgOZTjm1tX8Ucah4N5MJJYkp+2eH1a47piSF9H
         cwww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749570353; x=1750175153;
        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=ye4BOMohhlw7Z0BEcrYqBlRvGxBbQ5Cho9rGrm3TBps=;
        b=WNsxDuLqhuwjI2x5n0SuIzdaR9g6a7t6QDjKyx3WMqAdMZrfny1IFqllbBUoFBjAI6
         af0L14ziBqC3UdhCuUEf2W+Yhi3lB8YO1Fh2NQkm9FSHainN6415/cM7koa2NjQE3mSG
         WJfXclz0+BtM1McwFHHXO/G4X03JbBqZYEn5ox/xL1y8RzViSXMwgs7J8hCAeyoFBl+V
         n9nI3CKEJyIxNBB37KKuyA3qFAex3gk1IKEMNmaDcKZIXMiBJv/Zw+4DJWSWsGO35sEm
         8wi0g5AxV7ljhUhC4rXGDYa/yWq2atJKH6v+IVvz/mpSk8meu2TvxmbihqNh+KcKz55F
         vkkA==
X-Forwarded-Encrypted: i=1; AJvYcCU0CQskPZYA3Jtt2fL3XVeXhNvUfUsvQoluTCclWGF9rDpiZqcgNNOLfSvNTiYjKLS3SRhdwKgvyno=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz+8JgS7r9AsOkdw5Ty6Z+Oaklu6Y3yTuMgPe5j4on+7DOdru9Y
	Tp2AMrEutkiEiNT8P+As4tv34LgQ4Z2lorXeWelxB8td7n3v2jJrfc+XlJ2JJejPjA==
X-Gm-Gg: ASbGncuCI/vZY0+tE5M2kU07Lq6SmVgipD8ZB7B68KgwenTZp0TNI00SX+NLs9FUyTk
	oKdh6T3hSL+AuM9BUuNehLomN3K0iQJvma+yllHJGJd3/XighrRgbGT3F26zc081jSrEcULja/D
	5wo9Y4TwbGj0tDDRNQ3wCC99aYIFuW/0FBY6+dy4dJCe1f6J44C/qTZ75WmE/3+Ut+KQ86Dui7s
	L/Kaa8oUpjyL0GhTj/Wi1vwDfXFdk9PFX9aHgsMac34H2PQqLc04WS/yJR0r3Ens0A0AErgZQr4
	43x/DrmiPQCU0EtJfGuircjVKdwmaY9h0iJvfhHY43skcuZTNApeygYvHc83y4lPbp1Adz94nIZ
	KZmRlTZFTf3E07tfwyoL4puUfoexNgF7RMMUCN90wNDaJfJXIZJOXRaZX92+94HpXOQdrapePiX
	QBSzb5QHoLK2uLmVRtKv3j
X-Google-Smtp-Source: AGHT+IG5cDHXhvZ5cvr6FJUopTGCDmbmBJ3daL6UNeVDU7jx5AOo1tPKU3HOt3G70SvQV2Y0nbEPJA==
X-Received: by 2002:adf:f08d:0:b0:3a4:f70e:bc25 with SMTP id ffacd0b85a97d-3a5514111d7mr3241750f8f.27.1749570353208;
        Tue, 10 Jun 2025 08:45:53 -0700 (PDT)
Message-ID: 
Date: Tue, 10 Jun 2025 17:45:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] x86/hvmloader: select xenpci MMIO BAR UC or WB MTRR
 cache attribute
To: Roger Pau Monne 
Cc: Anthony PERARD ,
 Andrew Cooper ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , Juergen Gross
 , Anthoine Bourgeois ,
 xen-devel@lists.xenproject.org
References: <20250605161659.18201-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: <20250605161659.18201-1-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 05.06.2025 18:16, Roger Pau Monne wrote:
> @@ -271,6 +279,43 @@ void pci_setup(void)
>              if ( bar_sz == 0 )
>                  continue;
>  
> +            if ( !xenpci_bar_uc &&
> +                 ((bar_data & PCI_BASE_ADDRESS_SPACE) ==
> +                   PCI_BASE_ADDRESS_SPACE_MEMORY) &&
> +                 vendor_id == 0x5853 &&
> +                 (device_id == 0x0001 || device_id == 0x0002) )
> +            {
> +                if ( is_64bar )
> +                {
> +                     printf("xenpci dev %02x:%x unexpected MMIO 64bit BAR%u\n",
> +                            devfn >> 3, devfn & 7, bar);
> +                     continue;
> +                }
> +
> +                if ( bar_sz > pci_mem_end ||
> +                     ((pci_mem_end - bar_sz) & ~(bar_sz - 1)) < pci_mem_start )
> +                {
> +                     printf("xenpci dev %02x:%x BAR%u size %llx overflows low PCI hole\n",
> +                            devfn >> 3, devfn & 7, bar, bar_sz);
> +                     continue;
> +                }

Is "continue" really the right way of handling the problem here? We didn't
skip this BAR prior to your changes just because of either of these being
true.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 15:51:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 15:51:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011084.1389391 (Exim 4.92)
	(envelope-from )
	id 1uP1G5-0005RC-3T; Tue, 10 Jun 2025 15:51:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011084.1389391; Tue, 10 Jun 2025 15:51: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 1uP1G5-0005R5-06; Tue, 10 Jun 2025 15:51:29 +0000
Received: by outflank-mailman (input) for mailman id 1011084;
 Tue, 10 Jun 2025 15:51: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 1uP1G4-0005Qz-3m
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 15:51:28 +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 c39d8c2d-4612-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 17:51:25 +0200 (CEST)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-450cf214200so52416935e9.1
 for ; Tue, 10 Jun 2025 08:51:25 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-4521375a392sm143260235e9.36.2025.06.10.08.51.24
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 10 Jun 2025 08:51:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c39d8c2d-4612-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749570685; x=1750175485; 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=G2r4MTM5pRk3wWbzXUGSI1FwuXdTy/sRwKyqcokCv08=;
        b=qj6fCV7Lbnwa5DqZmQLw+w5TvLv735PTRafrpvHl/CFHhW+or9NXh2w+mNzkzFMaaY
         mZ6oyNCFDKbuVxfFhOA/Jte7BQls0WCOOPlSWSh3VdSv7xYanu3sDE3T7ampyFR6tQlq
         hhMLTXdWeAZ9byugVQ1v7Y7gQ7Oodgz8IzG2w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749570685; x=1750175485;
        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=G2r4MTM5pRk3wWbzXUGSI1FwuXdTy/sRwKyqcokCv08=;
        b=feWPJaSxAfokhjWtM9aE/z4Hq/Hd2pTeMyusZqgROvF4AgL2HCou3+j+kC09iU9Wzu
         0kCJEqVePavv3+AU5TiFSKLEDBLOX609AL0+FKsX6Qo9wExoisO5PzEG14R9i/ZwOW+r
         wZinDdfGH1XEPy/0a1F7KRD4H4IpFIA1JdE7CfZhLGTSqGQRwNxV8PJDtOSBtR7wJfF2
         6mEWD1mbi4DvG+yLMqQj2u+vFVb+bnNzAAGUMNctkq1bChmf/rk0cPoZqvIBGSOzrIcF
         Ww6eVbrOpEOqmSsUSzr7unKpx2K7cNy/Co6vo1EWRMHLu+dI8/QRRj9f5/lhsfrOCn2B
         5Utg==
X-Gm-Message-State: AOJu0Yx99b/d3F2D0mzVOU1y7I9BmGl8FPfUoPRC829NiRFSlyF6hB35
	awI75kbHISaHtLykieIIRGHZrpzndNY3JUkyi8klfv1Y9K5TYCKzDMyCBdHa+Zvy4k0=
X-Gm-Gg: ASbGncuqpDEO7iX5B+Iw0nNjH8+9EJAQ54q4rFgyn9ZBiTz1bWudsclWFbHNL0h5AwF
	kYpjCHjIW0DEHAGF2uAm/P8BJKwmPkRINzHUek6XlaUvDfuT1IxZakxMZ53A7R/HxNSzoyJqCMI
	Y/Psez2Athdpi/e14Xms+6Mc76g7KROfh9wWF7tqfYfr+1PAsSTfln84quyToMPE4i7i9lskYkz
	REVlG/TvIcKHlmBjeMJ79oUXigdPE2OsV2VXkENPNHwf0OBECnS4x5Z9YBk/Tc+oPHnyuM9YN7J
	IdwESGNE7d6+gDh/ugM1WGXCZZHGdsVRgILbu7w96s7J+bef4mvRmsTM/BN1wN//GI7EQfeHpg1
	PysbBz6/rRo1QvuyHkBnGSx3qdjTZWknF4p/RHzWW957j0w==
X-Google-Smtp-Source: AGHT+IEKRGlRhSPlRuLKGklu50cZbQKqbxkqwGvNGoRPr7o3Mkx/QYLUsLDWdIXGKib1o6rfegz7Ug==
X-Received: by 2002:a05:600c:3b0e:b0:43c:f8fe:dd82 with SMTP id 5b1f17b1804b1-4520147f41emr166549335e9.18.1749570684877;
        Tue, 10 Jun 2025 08:51:24 -0700 (PDT)
Date: Tue, 10 Jun 2025 17:51:23 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Stewart Hildebrand 
Cc: xen-devel@lists.xenproject.org,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: Re: [PATCH v2] xen/arm: fix build with HAS_PCI
Message-ID: 
References: <20250610142300.197599-1-stewart.hildebrand@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250610142300.197599-1-stewart.hildebrand@amd.com>

On Tue, Jun 10, 2025 at 10:22:57AM -0400, Stewart Hildebrand wrote:
> In file included from ./include/xen/pci.h:72,
>                  from drivers/pci/pci.c:8:
> ./arch/arm/include/asm/pci.h:131:50: error: ‘struct rangeset’ declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
>   131 | static inline int pci_sanitize_bar_memory(struct rangeset *r)
>       |                                                  ^~~~~~~~
> cc1: all warnings being treated as errors
> 
> Fixes: 4acab25a9300 ("x86/vpci: fix handling of BAR overlaps with non-hole regions")
> Signed-off-by: Stewart Hildebrand 

Sorry, it was my fault.

Would it make sense to introduce a Gitlab build that has HAS_PCI
enabled?  Or it won't build either without extra patches?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 15:55:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 15:55:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011089.1389401 (Exim 4.92)
	(envelope-from )
	id 1uP1JY-00060K-GY; Tue, 10 Jun 2025 15:55:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011089.1389401; Tue, 10 Jun 2025 15: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 1uP1JY-00060D-E4; Tue, 10 Jun 2025 15:55:04 +0000
Received: by outflank-mailman (input) for mailman id 1011089;
 Tue, 10 Jun 2025 15: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 1uP1JW-000606-VC
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 15:55:02 +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 4400e071-4613-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 17:55:00 +0200 (CEST)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-450cf214200so52458055e9.1
 for ; Tue, 10 Jun 2025 08:55:00 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-45306f76ab3sm97444285e9.14.2025.06.10.08.54.59
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 10 Jun 2025 08:54:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4400e071-4613-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749570900; x=1750175700; 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=U8m9YJLg+99E6gsjvnhPs/q0c77TaqWDCxuVDceHeKE=;
        b=BS7ZLxamJYgG0bwk2Y3dweoePcpg7UzpK8YoLNUPiTmQIhF78++y5cin+fuIONCA3k
         On/ZaNNnYWmZ8ijt/f14qLjAAHbMuf0v3mD76oHix/3b+qLrXTDwH9YH5uJhp4PDl7Uz
         8qQXyvD2KCTDbN6gfwOy9QgsaSkD9j7pFsYjE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749570900; x=1750175700;
        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=U8m9YJLg+99E6gsjvnhPs/q0c77TaqWDCxuVDceHeKE=;
        b=icNDnJWHEDwvYxSlO9A6tYWqOzAIkpdOyDBq1xFi7yk+LxLPorAb8oZrncFd4wVN4a
         zcyK+/YUU8Yz3Q/l0KyEgfsKVJeQBWahwxU6ec/qbI65qlF91EHEnmfC/PcnfZmNzhis
         cJZHWYjtMDOrOktu9Z4FC25rX6aqq7v4UoLChYCAcISVpZG3FWOBkz9+Eftw3PNcPP0n
         XFVscE0qp1yMpeGVk9T4KNYCJWcU2A2rStLAa7qveOdAqdVIpZ9qOiyFcT617bmSh3+k
         PDokhTxRIPCa33RZA6u4UiDks2av8QQszt7i/NA2GFiuDXrSZtnAmCb68v95s3uRJ3Vj
         mEIA==
X-Gm-Message-State: AOJu0YzTitBRCGiNITU7q9NJnWbEvvRN4otq9T563DyuZLTk6sEtSBpJ
	9G8Lh5MO5y2Agk1bYtPTmvS6vC8DR06FOELA9fF0prksR6jk1RiqjtizMrWT6j7EsTY=
X-Gm-Gg: ASbGnct0H7KLDrrkLw6qgOllE3RmC9zaLr0pCV4r9ZJrmiFVjm6hVY7sANjHPR2Yab1
	HzU7S7iaSMDEp+GHFS+S3jUdd1VOFlADznzZFD9toWhHQXrpWn/zhgkT+m+bwX4BGaU2Ebngs37
	+8C2+AirDEz1eLj4DNgoKy812C+rv3i7hO3Qq98y8GF+Xs11XKxPj90sd3XT3GXceZEmEubAGDx
	hNgVxv9xXE/ekIPZIO7Lnl2ReSR9TZMjVEi3JIali2QdIGl1jRrevF0xcMoiTsu3TB+JhV9cV0r
	bBnZs+S0BEiwFWo3vydWXkGK10NxpV00bn91+rRoA11JynmzZJh5QS0D3UkvrAwjBuT3Btih7cl
	427W66C/oj7dtOjHpndgyIrTfMqC7PRuZSGs=
X-Google-Smtp-Source: AGHT+IHX3fZh8SXwWc9Rzzj68Tf1HCvap96gRTGbYg+Qk6rPEuVjdfRx5txUzADQwvYxF2QaY/+2wQ==
X-Received: by 2002:a05:600c:528a:b0:453:dbe:7574 with SMTP id 5b1f17b1804b1-4530efe68f4mr89593305e9.12.1749570900294;
        Tue, 10 Jun 2025 08:55:00 -0700 (PDT)
Date: Tue, 10 Jun 2025 17:54:59 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" ,
	Andrew Cooper 
Subject: Re: [PATCH v2] x86/HVM: restrict use of pinned cache attributes as
 well as associated flushing
Message-ID: 
References: <78b3ddeb-4317-4d54-ad52-9eb03bdf7942@suse.com>
 
 <6e9e84eb-f98b-4c06-8952-03aecc82c0ea@suse.com>
 
 <5f8d694f-e712-4869-879f-80b2c4907a45@suse.com>
 
 <3470dcc8-f08a-4a00-8760-b3564d78e638@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <3470dcc8-f08a-4a00-8760-b3564d78e638@suse.com>

On Tue, Jun 10, 2025 at 04:13:40PM +0200, Jan Beulich wrote:
> On 10.06.2025 15:24, Roger Pau Monné wrote:
> > IMO the added complexity here is not worth the performance
> > improvement, not without a clear justification that it's needed.
> 
> Well, okay, I'll simply consider the patch in this shape rejected then.
> I don't see much value in wasting further time on it.

The code is already there, so I think there's value in this patch.
Did you see my suggestion in the email yo uare replying to about not
needing to add the is_iommu_enabled(d) || cache_flush_permitted(d)
checks?

With that dropped (if it's indeed OK), I would be fine with Acking the
patch.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 15:57:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 15:57:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011094.1389411 (Exim 4.92)
	(envelope-from )
	id 1uP1LR-0006Wh-RE; Tue, 10 Jun 2025 15:57:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011094.1389411; Tue, 10 Jun 2025 15:57:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uP1LR-0006Wa-Ob; Tue, 10 Jun 2025 15:57:01 +0000
Received: by outflank-mailman (input) for mailman id 1011094;
 Tue, 10 Jun 2025 15:57: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 1uP1LQ-0006WR-Eq
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 15:57: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 8a9fe920-4613-11f0-a307-13f23c93f187;
 Tue, 10 Jun 2025 17:56:59 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3a4fd1ba177so3836321f8f.0
 for ; Tue, 10 Jun 2025 08:56:59 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b49b:5992:e13c:c106:5fe0?
 (p200300cab734b49b5992e13cc1065fe0.dip0.t-ipconnect.de.
 [2003:ca:b734:b49b:5992:e13c:c106:5fe0])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a5322a9bbdsm12388835f8f.21.2025.06.10.08.56.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 08:56:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8a9fe920-4613-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749571019; x=1750175819; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=sunt5VtzP9ZG9QrTQ/Rhz/Jdoh0/yOk6AR4RhSp052w=;
        b=gaa+Kp4gq0BAggsSr5snBt4UXtpymZBw+5Vra4LdmevQTZfkrLdcbBBIDEeulDi7jj
         MQ4bZB7qHaDxuVPkwT64ull9eqmGGA4bl2VPyicyTJuJbvLhy3qGFVSJn0TV/fFd+JJV
         /DEVaa5DZVJQ8N8wF6CjNKs+27VaaOU9+EPKrN5+/+9jvnBPewnLxSfY7eg5dL1WH28i
         JO9Tb4Of/kkEQx9PJG4paeHJmL4Hbs1r6X4ioJ/uPG1+pMxl+hf/sLEsOsjVXeYL0V6u
         tXiqeu4QSEQEgYNWttZeD7d6g3PFPvi5B0bzWVhdvLDTGzFhIoi6E7eWsUH6KpZxK/A+
         JDIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749571019; x=1750175819;
        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=sunt5VtzP9ZG9QrTQ/Rhz/Jdoh0/yOk6AR4RhSp052w=;
        b=noutFoxEFPPm90XR/i4pIMmUcQXhuZM7aG7NABBXpALT8NTKPfBQfLc7ASvTAh7PP4
         fbNCMyxNNMVMvP6dcKNA5Gx9GVVot0iMpdtjTHP/w/5HOHCT+491NqqCs1BFtUQR7xVo
         EOxv6HkeXN03Deiz1X2qHBLBdEXuv3QTiOjTAcdw4HjOsThNNHWgY+704m3YU8aBywxT
         cMMH37O2gpOoW6NQ6oUq2qphkJQddKjR9o9a0N3f7BYZQVWCSzSx6t+W7wWN4ubv9TxH
         G6p4lDfZtJ/L28WGUwst1DTGryFAWYTt8psYy1qWDTH1FVD9reh5/8dqAXfCgLcn3qmw
         bGYQ==
X-Forwarded-Encrypted: i=1; AJvYcCV1mhm/QraKbcHIcbWf6AOzdfH6UAOnFicu3Mx87MELW8hfLZq3P34Nl+jWqvPjvJBMwERWzwp2r60=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzFW8LX/p6mjsawdGvuubk6qmAFPFgC/Elk114vlV+QV9mqtIJC
	cpl6/zjcA4naOrh0b9IJrYqfL9QeL9EVHDPRf5Q/yyJJJEFiEYLAXjjcJxIBgiYSZw==
X-Gm-Gg: ASbGnct/lMF1v6f9rzCr4HrNGmdqhlYwzMwbm8n6WfIOzieTDkJCwigrPAaBveiL8/S
	w4RaV18m7cZkF/4lytDPYEJOck1xzFBWQmPlRS46b2dcRic+Rt5xnK1Ke1ycsp6rb9KU2v0qHrB
	b9azCCVEfYD/19JUvFzyWraCC9mRKl5brl/kGNsFayT3aUkkVwqmNWAoP43p4NPHAGU2AbokRY9
	EVOSXJ2acuspoef+r6HfvDrS0Ygk5Bcf3rYypyLiMf3sQHYikmPlPFVzd3pHkdo7lOURG1hdRhG
	yp+JpFopBxldvdonEYVLAu35XTetVQMKGjawnarjFORwtt7gn07Pt0J3KqX1GyuPpG5AqMrWmON
	sWMs/4cYbtBormI/X8ETgLP32BKZlPszIwW/+lexg6eRRZyPPT9A8AQ2ndnjYN2oX11qBezv+GE
	ehzYOo68Kk83aNTPchcKgB
X-Google-Smtp-Source: AGHT+IFF4AFjf2wTg25dFaxlfOU/Cx2UNUETw4MLpdnlRy1ZZPecWew8F4xq2+Cv4EhqNQd4v0hb8Q==
X-Received: by 2002:a05:6000:4024:b0:3a4:dc3b:5a3b with SMTP id ffacd0b85a97d-3a5513e84c2mr3508102f8f.10.1749571018790;
        Tue, 10 Jun 2025 08:56:58 -0700 (PDT)
Message-ID: 
Date: Tue, 10 Jun 2025 17:56:58 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/3] Disallow most command-line options when lockdown
 mode is enabled
To: Kevin Lampis 
Cc: Ross Lagerwall , xen-devel@lists.xenproject.org
References: <20250602134656.3836280-1-kevin.lampis@cloud.com>
 <20250602134656.3836280-4-kevin.lampis@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: <20250602134656.3836280-4-kevin.lampis@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 02.06.2025 15:46, Kevin Lampis wrote:
> A subset of command-line parameters that are specifically safe to use when
> lockdown mode is enabled are annotated as such.
> 
> These are commonly used parameters which have been audited to ensure they
> cannot be used to undermine the integrity of the system when booted in
> Secure Boot mode.

It's still being left entirely unclear what the criteria are by which an
option can / cannot be marked "safe". For example ...

> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -47,7 +47,7 @@ integer_param("cpuid_mask_thermal_ecx", opt_cpuid_mask_thermal_ecx);
>  
>  /* 1 = allow, 0 = don't allow guest creation, -1 = don't allow boot */
>  int8_t __read_mostly opt_allow_unsafe;
> -boolean_param("allow_unsafe", opt_allow_unsafe);
> +boolean_secure_param("allow_unsafe", opt_allow_unsafe);

... why's this being marked such, when already by its name its use is going
to render the system unsafe.

> --- a/xen/arch/x86/cpu/mcheck/mce.c
> +++ b/xen/arch/x86/cpu/mcheck/mce.c
> @@ -31,7 +31,7 @@
>  #include "vmce.h"
>  
>  bool __read_mostly opt_mce = true;
> -boolean_param("mce", opt_mce);
> +boolean_secure_param("mce", opt_mce);

Similarly I don't think it's a good idea to allow turning of MCE.

I won't go any further until clarification on the criteria was written
down.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 16:00:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 16:00:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011101.1389422 (Exim 4.92)
	(envelope-from )
	id 1uP1OU-0008RZ-90; Tue, 10 Jun 2025 16:00:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011101.1389422; Tue, 10 Jun 2025 16:00: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 1uP1OU-0008RS-61; Tue, 10 Jun 2025 16:00:10 +0000
Received: by outflank-mailman (input) for mailman id 1011101;
 Tue, 10 Jun 2025 16:00: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 1uP1OT-0008RM-9t
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 16:00:09 +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 fb486e49-4613-11f0-a307-13f23c93f187;
 Tue, 10 Jun 2025 18:00:08 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-452f9735424so14373305e9.3
 for ; Tue, 10 Jun 2025 09:00:08 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-4521375b60fsm148306025e9.40.2025.06.10.09.00.07
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 10 Jun 2025 09:00:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fb486e49-4613-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749571208; x=1750176008; 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=r/upbL8I9kaywVUZVGGfQQ134HOzgX2YGj9tshAPkMM=;
        b=iEy3YVf6GN0A/gwvVXgU/4sG4E2N4NdMdezKkVUwOyw6TSIkINvqus3L3iGPK9ZnrC
         6xueHlHOIydvQX5WsFyNAnJNIkxq0TU52tl3wUIQ5zHWoE+RSwOgq78BHQpIxItRhA7V
         Xt4phTq8kyi6LwXZjADwrUfD2jtP4RYfnZoao=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749571208; x=1750176008;
        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=r/upbL8I9kaywVUZVGGfQQ134HOzgX2YGj9tshAPkMM=;
        b=cx80HyskoPywUzjAHxY9ybNbHXlUqdlhhc/kiEi+IqwGg9xoOxcKVvENR7JHqzXOhX
         ytDyj29G0xEzU0VqBcstPRd3M07QcB8rsY5+qTlM6FLu5ntk7jNBBpjqhoHQliM6E8a+
         uwyNPClilofXFp8+1b5z8Ndv6XoykkXv1hHWYUWhaxoKH3ZVdjPiYFrBYgwPxHvOiBKH
         4bKWKHotS2S0tfsTCqFTfDerQyJXOhvSl126Rmb336uR31UeoenVVo9BDZIGb2oSGekl
         fWZ1buYmapdOeBCoFML0tJolaZdylO/L5u25KW5+1jq5+a/Kb6IxnRqpfHnjrFM/N6R/
         /DCg==
X-Forwarded-Encrypted: i=1; AJvYcCVmlERQ4v9ajodSKwKslTOS2DMlGDSNT3cgZltURlT1cG5MOCV5X3EES53N5VqzRtJ2GLHYdaCeD9k=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxMyCpfzujx3jEDAfTq+Ts9HXRWUypNB7bi762H2nihtbJktYHO
	DrVJ4v5WpiHz80Woj50hJ1UgkL0Apas+RwchkR3f+jnrlW5SNkpVtN60LAAfAoBTj1I=
X-Gm-Gg: ASbGncvNKqGk8gGBdWtTr+XOtvWoYyK9gftPawysWsQKdn43cr0atZwgWnpW2lsqBXQ
	z7AWy1S6MHA+vAmbqNg7Rgg+nNGNtBUNwsoQ+Jwp5G7WRw9qYKl0/FmDNfVN2oCYbWXNkdbqZ7C
	2qktyRuP3YUrydsYW+TrxfbmjoeTDCJ0mAW0Fpb6+6uJNGmekL6EW1ITU+3tjwj0+UiYhdcQy1l
	2t4bIzpBayF/3u/Znw/QcVGojGIjiabVQ6oFwaE3kMAphnkgrtCrXEOjYElYIfz+OZ+K3zBj/Hm
	L/fgk0kCC44Ge2XPqy2tak0GkOwg8t9aYLV9spYLTPvxBiDf9gNAQuTGwlJ7c1HQgJ45xMZKMtH
	uBqVcyr3QolZe5R3f7VRXqh4y2DyG2XqCk8g=
X-Google-Smtp-Source: AGHT+IFCT7nx25u3GatylzHG+WtJc4ELMiGEyXB+198brpmA8tvfI5uBfPCpIM20kiCfi8VTne722g==
X-Received: by 2002:a05:600c:4751:b0:453:c39:d0d0 with SMTP id 5b1f17b1804b1-4530c39d65fmr94588445e9.13.1749571207777;
        Tue, 10 Jun 2025 09:00:07 -0700 (PDT)
Date: Tue, 10 Jun 2025 18:00:06 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Anthony PERARD ,
	Andrew Cooper ,
	Michal Orzel , Julien Grall ,
	Stefano Stabellini ,
	Juergen Gross ,
	Anthoine Bourgeois ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3] x86/hvmloader: select xenpci MMIO BAR UC or WB MTRR
 cache attribute
Message-ID: 
References: <20250605161659.18201-1-roger.pau@citrix.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 

On Tue, Jun 10, 2025 at 05:45:52PM +0200, Jan Beulich wrote:
> On 05.06.2025 18:16, Roger Pau Monne wrote:
> > @@ -271,6 +279,43 @@ void pci_setup(void)
> >              if ( bar_sz == 0 )
> >                  continue;
> >  
> > +            if ( !xenpci_bar_uc &&
> > +                 ((bar_data & PCI_BASE_ADDRESS_SPACE) ==
> > +                   PCI_BASE_ADDRESS_SPACE_MEMORY) &&
> > +                 vendor_id == 0x5853 &&
> > +                 (device_id == 0x0001 || device_id == 0x0002) )
> > +            {
> > +                if ( is_64bar )
> > +                {
> > +                     printf("xenpci dev %02x:%x unexpected MMIO 64bit BAR%u\n",
> > +                            devfn >> 3, devfn & 7, bar);
> > +                     continue;
> > +                }
> > +
> > +                if ( bar_sz > pci_mem_end ||
> > +                     ((pci_mem_end - bar_sz) & ~(bar_sz - 1)) < pci_mem_start )
> > +                {
> > +                     printf("xenpci dev %02x:%x BAR%u size %llx overflows low PCI hole\n",
> > +                            devfn >> 3, devfn & 7, bar, bar_sz);
> > +                     continue;
> > +                }
> 
> Is "continue" really the right way of handling the problem here?

The problem will only appear when using the newly added option.

> We didn't
> skip this BAR prior to your changes just because of either of these being
> true.

I can add a label to keep the previous logic in case the expectations
don't match.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 16:17:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 16:17:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011107.1389432 (Exim 4.92)
	(envelope-from )
	id 1uP1ej-0002dv-KQ; Tue, 10 Jun 2025 16:16:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011107.1389432; Tue, 10 Jun 2025 16:16: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 1uP1ej-0002do-H1; Tue, 10 Jun 2025 16:16:57 +0000
Received: by outflank-mailman (input) for mailman id 1011107;
 Tue, 10 Jun 2025 16:16: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 1uP1eh-0002dg-Ru
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 16:16:55 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on2062a.outbound.protection.outlook.com
 [2a01:111:f403:2414::62a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 51219e36-4616-11f0-a307-13f23c93f187;
 Tue, 10 Jun 2025 18:16:52 +0200 (CEST)
Received: from DM5PR07CA0093.namprd07.prod.outlook.com (2603:10b6:4:ae::22) by
 PH8PR12MB7351.namprd12.prod.outlook.com (2603:10b6:510:215::16) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.30; Tue, 10 Jun
 2025 16:16:48 +0000
Received: from CY4PEPF0000EE3B.namprd03.prod.outlook.com
 (2603:10b6:4:ae:cafe::c) by DM5PR07CA0093.outlook.office365.com
 (2603:10b6:4:ae::22) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.30 via Frontend Transport; Tue,
 10 Jun 2025 16:16:48 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CY4PEPF0000EE3B.mail.protection.outlook.com (10.167.242.14) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Tue, 10 Jun 2025 16:16: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; Tue, 10 Jun
 2025 11:16:46 -0500
Received: from [172.26.5.4] (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 Jun 2025 11:16:45 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 51219e36-4616-11f0-a307-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=w4zb6Gi2kVhMc5DfRyerfLfCiX4704V4WgEu6e3864YNgCUXCrvaSB9oBxDmeUbbt2gAFyeY9gkK8VJGZ9CNJ41NDQRhRI8BytATJfg2XYCzsy/b/96rYPKUTViKd63kN7oRmZsOucM+X0qzLihP7uq7VU7vGJEf2ho9udXXVqh9o6iPvfiPGPBnly7xKhoIy9yr91Djalkzz5EQb3knF0Rr/nRahSlIkF17K83nmNPG1LLSYY7Dc2fnMu5z67wmmgapznCbiQpYYmAuUWZNgdVcv7CfXfmHpz8KERxvkNRX0g5VoCM3pOapahLO2/5m/3dgcc8V9gncC0rPofSgcQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=+HtK1z3nKFtaZip35ISlSHt5D7JyiGZrIhHJlPCdsO4=;
 b=BSkPbLC8aWU8uERp307otEc4V2DFC7vXZsd6Eg04Wc1D02vvtMJEgwy9SliamId6EO6b3W2Ux/qYBflzJgAwp35vCK06/B9SL9YXoTd0GNgyeNJAiOe98wFOoVk4V1MVt+dVc8GVkmWoFI8ABtUaG7BJT5COFyRwXseXrg0gQ5hOJ69NyjRP/mNc1XGm7tYdPo6sHEHevOrAFbwHmpvm7bPOXtGoLXYgZ7Ec/zmI4fIt7zCn550m19n69xfn/xpPOe9/CxeeN24TeG7JxRhJ1MWIzzcmBRPcHRR815ol5p4ilD9588wTcxhtXRDbGBLeqZRo8Qx47AEJB27cuVKLgA==
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=+HtK1z3nKFtaZip35ISlSHt5D7JyiGZrIhHJlPCdsO4=;
 b=WPz5mqoKsquo2Flmj3KtLkdsPcZ6TSzripg5NhkTFl5X3cmpdMTXe8jm4hmlH1lQN1fllLAPSniB2rxQ1xI7jcsGfcwDtooSAwFaTa5xsNCAsjXkuEkmr1ik5+b25nTPfCkm2q6yxTjuuj4g5zife+XTIAsbKtrqYltk0su4vn8=
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 Jun 2025 12:16:42 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen/arm: fix build with HAS_PCI
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
CC: , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" 
References: <20250610142300.197599-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: CY4PEPF0000EE3B:EE_|PH8PR12MB7351:EE_
X-MS-Office365-Filtering-Correlation-Id: 517ec392-58c5-4518-842c-08dda83a332c
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?U0xYTVh1V0ZkTkcxTUQ0K1FRMERzcFJUeVZGTVB5T2lZODRQNXhSYklhL0N3?=
 =?utf-8?B?ZkdkNHJZN2NLYkpWanRTU2dJMmhnQ0pTUlFkazBUai85RUNhVjRzMlhLK2py?=
 =?utf-8?B?YzhqSEF1SldxdmR0djRXYjkxVDNHdWovbmpIMFdZMC96WStRUFBZdTB5R1k5?=
 =?utf-8?B?NmRBVmRzem9KNHlvZXkwbzI0eVg4bDdQRDBrWEJOOFlFbEVLTjErMjRGalpi?=
 =?utf-8?B?Q3BnYktVUldBZE9wRDFqbHFnNjI4WXovaTdZWWdWOFBqWGptaHpPOXJkNjh0?=
 =?utf-8?B?TjNNN3NNRlFBOFdyR2xKWmZXaHBwR2lVLzF5dEkzY1dnMlNIcUQ5cE9rUDhI?=
 =?utf-8?B?anRuTlU4WGNIVFZRQUYwdjVSR0xuYStRY0hrNkI2Y0VOMnh0dVhtaHp0c0p5?=
 =?utf-8?B?TFljZHIyc1dCRGlHOVQ4bmw3S3BYdUx2L1EzNTgxUUpEb0YwMVRCTlBEUGxR?=
 =?utf-8?B?SDVoU3huMDFrQkJRYkl6M3J4bno0VnhncjVuUHZGU2M0NkxnSGxUT2xlOFFZ?=
 =?utf-8?B?R3Y0RjJ1V1VaWWplcWdLYmRZbUFZR1NuNSt4dk1MVDVLaldFUmM3SkhxU0Y3?=
 =?utf-8?B?WVNuMHVVSGNETTk3RURQMFlkTlhhUmdwRVNKWlA3RnVuWjRWSHJoRTRWTXdr?=
 =?utf-8?B?TWhER2l3QzlvS2toQ0xBQ0tXQmZaVG9hN0YzNUduUUplTEdFMXZyNW9WQ3ht?=
 =?utf-8?B?ankzTDNBdVVHajZSdGlIaUdXcndDOTBuRktvTG5obW5Fa1Z3STZwbUtUbVZ2?=
 =?utf-8?B?eU9QbVJDVS94WXhtZVROM0FqUlJvdW0vdjJPcmt2NDBORVYxREwybktacnox?=
 =?utf-8?B?NWZWYm9scTJ0R1RITC9Oc3RBdHRXemxqQ05RZkFxVFdEZFFkcXU4MUl4RzQy?=
 =?utf-8?B?cjdBZlRjWjZGT1E0WnVibUJZWHVwTEMyK1pEZDAzSGY5UFdtbWxNYTlOamZJ?=
 =?utf-8?B?M3crRkJ0eU9DRjlRVXlad1FjZkw5aWkzRys3aTNmWkZlVWNXM1FRNUFQdzUy?=
 =?utf-8?B?a281aFd4Zzd0dmh0Syt1RUR0amxZZjFIOENLQXdVaWpTZDVIZzFzWDZBUEJL?=
 =?utf-8?B?alcxNHBoSTcvb1BKd2h6YnJHSFhWanp1TXlHbEFoS1dlZWxxSVdyWHpYMzg2?=
 =?utf-8?B?WUJkcnpPbGFRK0ZCNWVKcVFpcTVRcUFaVlZFZlVzd1dWZGJLaWhhbHk5RURx?=
 =?utf-8?B?SUEwTFY3aWNkdmRFUXJGWVc1dXluM29lNkNKLzVFN2hrREZGOC9DSmVjbVJS?=
 =?utf-8?B?Syt0TlBPeEFNZzRHQ2IvMW50aHZUTHZVeFFFZkY3MDFSTEc5REUwRWN5bkpo?=
 =?utf-8?B?UW1HY1M4WVlnbEpLcWRVa3R5S1dIREF0VzBya1VCQkVURHZOa0dzb1JkZzda?=
 =?utf-8?B?aFNVLzVmTHgvOFRjb01rNEJhQndtWndMemVjemtJbjFyOXNmZnpuRmxZb3dq?=
 =?utf-8?B?MEJnbTJ4ODF6eXBrdklIUS9GR3JYdlkxenVjMStOMG5ON2F4UDI2LyttT3Vn?=
 =?utf-8?B?ZVBtYTQ5K0QvVUhhTlhlek1TNkVqV21qbFJiM0xSOTBGTVhZcDhvbW9lTGZn?=
 =?utf-8?B?cFZxcFlnZHJYeWxTYnFTbkFNc3hzRGtNK2ZmZkNxZkhKOHFzdUFtbE9BTzBI?=
 =?utf-8?B?WWhtQ3pJYnJrME9RUytMb2lEdHliU0dHdHdzSlhDZkZHNlljWFlTSCtLdVlq?=
 =?utf-8?B?VGhROWVVTUNtajBFenoxT2haaCs4aiszeVdYQXFaZHhuWFRIbFRDbnR6bDBn?=
 =?utf-8?B?L3hCOGVHSmhnUms4djUzRThubXd4eWRONmZ2L2xVNUhRZG5jWVB2cm9aYzdt?=
 =?utf-8?B?ZnB6UjgyNExVYUE4azlLcjFlUFQ4QjFOMTg5Z0JoVlIvZjk4bUVXelJpU0pm?=
 =?utf-8?B?Ulo3VXgzdVZDVU1MTEJobFJiZ0x2eVIxYnBOemREdWtDZGhpTC8vWDBkc2k4?=
 =?utf-8?B?a1gyemZjSDJHbVpDY3VQNjBXYmlKVkFTZUZNL05tUjJmbXhrMTBtOWtGQTlJ?=
 =?utf-8?B?dnhrWnhmTURnNStJTXVXa2hoRkRCakZ4bjJrRnJMdkdsalVVdUI1TWJ5cG9m?=
 =?utf-8?B?OEIvaXhKVHZXTHNmUVFhR0dMTml6ZkdRbGd3dz09?=
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: 10 Jun 2025 16:16:47.5553
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 517ec392-58c5-4518-842c-08dda83a332c
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:
	CY4PEPF0000EE3B.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7351

On 6/10/25 11:51, Roger Pau Monné wrote:
> On Tue, Jun 10, 2025 at 10:22:57AM -0400, Stewart Hildebrand wrote:
>> In file included from ./include/xen/pci.h:72,
>>                  from drivers/pci/pci.c:8:
>> ./arch/arm/include/asm/pci.h:131:50: error: ‘struct rangeset’ declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
>>   131 | static inline int pci_sanitize_bar_memory(struct rangeset *r)
>>       |                                                  ^~~~~~~~
>> cc1: all warnings being treated as errors
>>
>> Fixes: 4acab25a9300 ("x86/vpci: fix handling of BAR overlaps with non-hole regions")
>> Signed-off-by: Stewart Hildebrand 
> 
> Sorry, it was my fault.

No worries, it's pretty hard to catch when it can't be built without
extra patches.

> Would it make sense to introduce a Gitlab build that has HAS_PCI
> enabled?  Or it won't build either without extra patches?

It requires one extra patch ("xen/arm: pci: introduce PCI_PASSTHROUGH
Kconfig option"):

https://lore.kernel.org/xen-devel/20231113222118.825758-1-stewart.hildebrand@amd.com/T/#t

It has an ack, although it needs a rebase and we would probably want to
add HAS_VPCI_GUEST_SUPPORT now that upstream has that config too.


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 16:30:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 16:30:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011116.1389442 (Exim 4.92)
	(envelope-from )
	id 1uP1rZ-0005gR-Tf; Tue, 10 Jun 2025 16:30:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011116.1389442; Tue, 10 Jun 2025 16:30:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uP1rZ-0005gK-QA; Tue, 10 Jun 2025 16:30:13 +0000
Received: by outflank-mailman (input) for mailman id 1011116;
 Tue, 10 Jun 2025 16:30: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 1uP1rY-0005gE-Db
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 16:30:12 +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 2dbb8005-4618-11f0-a307-13f23c93f187;
 Tue, 10 Jun 2025 18:30:11 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a528243636so3468147f8f.3
 for ; Tue, 10 Jun 2025 09:30:11 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-452730b9b27sm142268045e9.23.2025.06.10.09.30.09
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 10 Jun 2025 09:30:09 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2dbb8005-4618-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749573010; x=1750177810; 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=3hRPTR67tycMsLmTQyzN1miY9GK7NujqLa0zAwza2lM=;
        b=FMS9c3/CvTq/xbR6ds1BTrLWzWHD0MiYUt9yTr5Z6lSEB3RsVas8egHb1FyKigUz2i
         sDIf4DgcFeEzGRqvkZbYZ7qLLmK0adV6Aj71emd1YB4+f9ELWUPTV+NqpuHHgOxGH9rY
         MXRl664OSLVbjct7Jz3rY/QyJFgVRUIfJpW6A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749573010; x=1750177810;
        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=3hRPTR67tycMsLmTQyzN1miY9GK7NujqLa0zAwza2lM=;
        b=fSeBSD3DiGwhv2q/pe6AFYqUh5Cx82guYeaDCE6w5wErS6D4ILZM5MxIl4/5FY7Cu+
         wxJiTvye0WalpEx/0PqgcrnGax13bViIRBRDlKW/dqCG2M//MYfepOipxO+iQg3wrZju
         ZOuBSJZ+OvA2rQO4xEJm04mUVcLp50niDxXFWkFCVTg9Z3QGz3fLz44CTlaHv6cWkNU8
         dRRGOXnfcc9xgxbZ/CRPLb+P8d/7X2SkJvxSA7puGtZmIsgI/O5xbCXokRUvz08CjEjn
         WySPHoWlrnu01XDubve6+pu1IZ2Xxdsutf4FdaLuI1oXWm9KltvZMbG03E9ylNX6jdIb
         56rw==
X-Gm-Message-State: AOJu0YxDPvkPrM6cxYjTNP9MiKtSEBG+uyzAmEKcxpQb7wv6X5mW9bQr
	ARGIZZRH9UKiMo1nxhKcSmlEpuXaRnGRB0E3a2l88FP6sRpbm8C/b7/4/Db8IefjgoRbYKLOKyD
	shKo5
X-Gm-Gg: ASbGncuJRyrf3QiXUEG1L6EqFfZCwaYGs2gCGVWshJWa6NJZWbrRghQAn+3VbXzefcV
	2TFTHbb5j5HR8j1t6rWyFxbKvmpqJ0lZm2gHMGk7EfkrfH48FX+aEqoSR512lKMQpmw5iQLt9si
	Vc4TsCEBe4E59ZJ+51cVl9GfjEoB4x84Ez4YV5FaJucUV0c6C63rqDbvA5JAYO/xn7H/7fG+svg
	DFWPsU+MG4fUZ8ejafJ1lC7s0FLVN98fIp8d9zxogTDvqMkYEv/ZYbv6zbMK85102PEASN3XGCP
	ayYD3ZHn2oc/1PHARJb0+jW8aSGDVy1a53EOnsM9661BnDKuzsJDgcFuQ4gQH6jPp5ht7hvRuog
	RjTH+WhQgVWlGRsFjtso8CeaqUvC0SFqMq8A=
X-Google-Smtp-Source: AGHT+IHVaOG9l5Mor7PRoBaZ5HE6MkkQr/zc/Lms0D5IQLLAs8yRa2JHTyWIqbCaCIIHyyQn7fY7Zg==
X-Received: by 2002:a05:6000:2dc5:b0:3a5:2f23:376f with SMTP id ffacd0b85a97d-3a5318823d2mr13622029f8f.13.1749573009946;
        Tue, 10 Jun 2025 09:30:09 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Oleksii Kurochko ,
	Community Manager ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Juergen Gross ,
	Anthoine Bourgeois 
Subject: [PATCH v4] x86/hvmloader: select xenpci MMIO BAR UC or WB MTRR cache attribute
Date: Tue, 10 Jun 2025 18:29:30 +0200
Message-ID: <20250610162930.89055-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The Xen PCI device (vendor ID 0x5853) exposed to x86 HVM guests doesn't
have the functionality of a traditional PCI device.  The exposed MMIO BAR
is used by some guests (including Linux) as a safe place to map foreign
memory, including the grant table itself.

Traditionally BARs from devices have the uncacheable (UC) cache attribute
from the MTRR, to ensure correct functionality of such devices.  hvmloader
mimics this behavior and sets the MTRR attributes of both the low and high
PCI MMIO windows (where BARs of PCI devices reside) as UC in MTRR.

This however causes performance issues for users of the Xen PCI device BAR,
as for the purposes of mapping remote memory there's no need to use the UC
attribute.  On Intel systems this is worked around by using iPAT, that
allows the hypervisor to force the effective cache attribute of a p2m entry
regardless of the guest PAT value.  AMD however doesn't have an equivalent
of iPAT, and guest PAT values are always considered.

Linux commit:

41925b105e34 xen: replace xen_remap() with memremap()

Attempted to mitigate this by forcing mappings of the grant-table to use
the write-back (WB) cache attribute.  However Linux memremap() takes MTRRs
into account to calculate which PAT type to use, and seeing the MTRR cache
attribute for the region being UC the PAT also ends up as UC, regardless of
the caller having requested WB.

As a workaround to allow current Linux to map the grant-table as WB using
memremap() introduce an xl.cfg option (xenpci_bar_uc=0) that can be used to
select whether the Xen PCI device BAR will have the UC attribute in MTRR.
Such workaround in hvmloader should also be paired with a fix for Linux so
it attempts to change the MTRR of the Xen PCI device BAR to WB by itself.

Overall, the long term solution would be to provide the guest with a safe
range in the guest physical address space where mappings to foreign pages
can be created.

Some vif throughput performance figures provided by Anthoine from a 8
vCPUs, 4GB of RAM HVM guest(s) running on AMD hardware:

Without this patch:
vm -> dom0: 1.1Gb/s
vm -> vm:   5.0Gb/s

With the patch:
vm -> dom0: 4.5Gb/s
vm -> vm:   7.0Gb/s

Reported-by: Anthoine Bourgeois 
Signed-off-by: Roger Pau Monné 
Reviewed-by: Oleksii Kurochko
---
Changes since v3:
 - Add changelog.
 - Assign BARs normally for xenpci if special casing fails.

Changes since v2:
 - Add default value in xl.cfg.
 - List xenstore path in the pandoc file.
 - Adjust comment in hvmloader.
 - Fix commit message MIO -> MMIO.

Changes since v1:
 - Leave the xenpci BAR as UC by default.
 - Introduce an option to not set it as UC.
---
 CHANGELOG.md                            |  3 ++
 docs/man/xl.cfg.5.pod.in                |  8 ++++
 docs/misc/xenstore-paths.pandoc         |  5 +++
 tools/firmware/hvmloader/config.h       |  2 +-
 tools/firmware/hvmloader/pci.c          | 50 ++++++++++++++++++++++++-
 tools/firmware/hvmloader/util.c         |  2 +-
 tools/include/libxl.h                   |  9 +++++
 tools/libs/light/libxl_create.c         |  1 +
 tools/libs/light/libxl_dom.c            |  9 +++++
 tools/libs/light/libxl_types.idl        |  1 +
 tools/xl/xl_parse.c                     |  2 +
 xen/include/public/hvm/hvm_xs_strings.h |  2 +
 12 files changed, 90 insertions(+), 4 deletions(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 1ee2f42e7405..23215a8cc1e6 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -15,6 +15,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
  - On x86:
    - Restrict the cache flushing done as a result of guest physical memory map
      manipulations and memory type changes.
+   - Allow controlling the MTRR cache attribute of the Xen PCI device BAR
+     for HVM guests, to improve performance of guests using it to map the grant
+     table or foreign memory.
 
 ### Added
  - On x86:
diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index c388899306c2..ddbff6fffc16 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -2351,6 +2351,14 @@ Windows L.
 Setting B with the default device_model "qemu-xen"
 requires at least QEMU 1.6.
 
+
+=item B
+
+B Select whether the memory BAR of the Xen PCI device should have
+uncacheable (UC) cache attribute set in MTRR.
+
+Default is B.
+
 =item B or B
 
 The groups of Microsoft Hyper-V (AKA viridian) compatible enlightenments
diff --git a/docs/misc/xenstore-paths.pandoc b/docs/misc/xenstore-paths.pandoc
index 01a340fafcbe..073bed91eec1 100644
--- a/docs/misc/xenstore-paths.pandoc
+++ b/docs/misc/xenstore-paths.pandoc
@@ -234,6 +234,11 @@ These xenstore values are used to override some of the default string
 values in the SMBIOS table constructed in hvmloader. See the SMBIOS
 table specification at http://www.dmtf.org/standards/smbios/ 
 
+#### ~/hvmloader/pci/xenpci-bar-uc = ("1"|"0") [HVM,INTERNAL]
+
+Select whether the Xen PCI device MMIO BAR will have the uncacheable cache
+attribute set in the MTRRs by hvmloader.
+
 #### ~/bios-strings/oem-* = STRING [HVM,INTERNAL]
 
 1 to 99 OEM strings can be set in xenstore using values of the form
diff --git a/tools/firmware/hvmloader/config.h b/tools/firmware/hvmloader/config.h
index 6e1da137d779..c159db30eea9 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -58,7 +58,7 @@ extern uint32_t *cpu_to_apicid;
 #define ACPI_TIS_HDR_ADDRESS 0xFED40F00UL
 
 extern uint32_t pci_mem_start;
-extern const uint32_t pci_mem_end;
+extern uint32_t pci_mem_end;
 extern uint64_t pci_hi_mem_start, pci_hi_mem_end;
 
 extern bool acpi_enabled;
diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index cc67b18c0361..cfd39cc37cdc 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -30,7 +30,7 @@
 #include 
 
 uint32_t pci_mem_start = HVM_BELOW_4G_MMIO_START;
-const uint32_t pci_mem_end = RESERVED_MEMBASE;
+uint32_t pci_mem_end = RESERVED_MEMBASE;
 uint64_t pci_hi_mem_start = 0, pci_hi_mem_end = 0;
 
 /*
@@ -116,6 +116,8 @@ void pci_setup(void)
      * experience the memory relocation bug described below.
      */
     bool allow_memory_relocate = 1;
+    /* Select the MTRR cache attribute of the xenpci device BAR. */
+    bool xenpci_bar_uc = false;
 
     BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_IO !=
                  PCI_COMMAND_IO);
@@ -130,6 +132,12 @@ void pci_setup(void)
     printf("Relocating guest memory for lowmem MMIO space %s\n",
            allow_memory_relocate?"enabled":"disabled");
 
+    s = xenstore_read(HVM_XS_XENPCI_BAR_UC, NULL);
+    if ( s )
+        xenpci_bar_uc = strtoll(s, NULL, 0);
+    printf("XenPCI device BAR MTRR cache attribute set to %s\n",
+           xenpci_bar_uc ? "UC" : "WB");
+
     s = xenstore_read("platform/mmio_hole_size", NULL);
     if ( s )
         mmio_hole_size = strtoll(s, NULL, 0);
@@ -271,6 +279,44 @@ void pci_setup(void)
             if ( bar_sz == 0 )
                 continue;
 
+            if ( !xenpci_bar_uc &&
+                 ((bar_data & PCI_BASE_ADDRESS_SPACE) ==
+                   PCI_BASE_ADDRESS_SPACE_MEMORY) &&
+                 vendor_id == 0x5853 &&
+                 (device_id == 0x0001 || device_id == 0x0002) )
+            {
+                if ( is_64bar )
+                {
+                     printf("xenpci dev %02x:%x unexpected MMIO 64bit BAR%u\n",
+                            devfn >> 3, devfn & 7, bar);
+                     goto skip_xenpci;
+                }
+
+                if ( bar_sz > pci_mem_end ||
+                     ((pci_mem_end - bar_sz) & ~(bar_sz - 1)) < pci_mem_start )
+                {
+                     printf("xenpci dev %02x:%x BAR%u size %llx overflows low PCI hole\n",
+                            devfn >> 3, devfn & 7, bar, bar_sz);
+                     goto skip_xenpci;
+                }
+
+                /* Put unconditionally at the end of the low PCI MMIO hole. */
+                pci_mem_end -= bar_sz;
+                pci_mem_end &= ~(bar_sz - 1);
+                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
+                bar_data |= pci_mem_end;
+                pci_writel(devfn, bar_reg, bar_data);
+                pci_devfn_decode_type[devfn] |= PCI_COMMAND_MEMORY;
+
+                /* Prefix BAR address with a 0 to match format used below. */
+                printf("pci dev %02x:%x bar %02x size "PRIllx": 0%08x\n",
+                       devfn >> 3, devfn & 7, bar_reg,
+                       PRIllx_arg(bar_sz), bar_data);
+
+                continue;
+            }
+ skip_xenpci:
+
             for ( i = 0; i < nr_bars; i++ )
                 if ( bars[i].bar_sz < bar_sz )
                     break;
@@ -310,7 +356,7 @@ void pci_setup(void)
         }
 
         /* Enable bus master for this function later */
-        pci_devfn_decode_type[devfn] = PCI_COMMAND_MASTER;
+        pci_devfn_decode_type[devfn] |= PCI_COMMAND_MASTER;
     }
 
     if ( mmio_hole_size )
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 79c0e6bd4ad2..31b4411db7b4 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -867,7 +867,7 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
         config->table_flags |= ACPI_HAS_HPET;
 
     config->pci_start = pci_mem_start;
-    config->pci_len = pci_mem_end - pci_mem_start;
+    config->pci_len = RESERVED_MEMBASE - pci_mem_start;
     if ( pci_hi_mem_end > pci_hi_mem_start )
     {
         config->pci_hi_start = pci_hi_mem_start;
diff --git a/tools/include/libxl.h b/tools/include/libxl.h
index b7ad7735ca4c..7ce7678e6836 100644
--- a/tools/include/libxl.h
+++ b/tools/include/libxl.h
@@ -1503,6 +1503,15 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst, const libxl_mac *src);
  */
 #define LIBXL_HAVE_CREATEINFO_XEND_SUSPEND_EVTCHN_COMPAT
 
+/*
+ * LIBXL_HAVE_XENPCI_BAR_UC
+ *
+ * libxl_domain_build_info contains a boolean 'u.hvm.xenpci_bar_uc' field to
+ * signal whether the XenPCI device BAR should have UC cache attribute set in
+ * MTRR.
+ */
+#define LIBXL_HAVE_XENPCI_BAR_UC
+
 typedef char **libxl_string_list;
 void libxl_string_list_dispose(libxl_string_list *sl);
 int libxl_string_list_length(const libxl_string_list *sl);
diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_create.c
index 8bc768b5156c..962fa820faec 100644
--- a/tools/libs/light/libxl_create.c
+++ b/tools/libs/light/libxl_create.c
@@ -313,6 +313,7 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
         libxl_defbool_setdefault(&b_info->u.hvm.usb,                false);
         libxl_defbool_setdefault(&b_info->u.hvm.vkb_device,         true);
         libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci,   true);
+        libxl_defbool_setdefault(&b_info->u.hvm.xenpci_bar_uc,      true);
         libxl_defbool_setdefault(&b_info->u.hvm.pirq,               false);
 
         libxl_defbool_setdefault(&b_info->u.hvm.spice.enable, false);
diff --git a/tools/libs/light/libxl_dom.c b/tools/libs/light/libxl_dom.c
index 4d67b0d28294..60ec0354d19a 100644
--- a/tools/libs/light/libxl_dom.c
+++ b/tools/libs/light/libxl_dom.c
@@ -819,6 +819,15 @@ static int hvm_build_set_xs_values(libxl__gc *gc,
             goto err;
     }
 
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM &&
+        libxl_defbool_val(info->u.hvm.xenpci_bar_uc)) {
+        path = GCSPRINTF("/local/domain/%d/"HVM_XS_XENPCI_BAR_UC, domid);
+        ret = libxl__xs_printf(gc, XBT_NULL, path, "%d",
+                               libxl_defbool_val(info->u.hvm.xenpci_bar_uc));
+        if (ret)
+            goto err;
+    }
+
     return 0;
 
 err:
diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl
index 198515383012..6054350b83c7 100644
--- a/tools/libs/light/libxl_types.idl
+++ b/tools/libs/light/libxl_types.idl
@@ -691,6 +691,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
                                        ("vkb_device",       libxl_defbool),
                                        ("soundhw",          string),
                                        ("xen_platform_pci", libxl_defbool),
+                                       ("xenpci_bar_uc",    libxl_defbool),
                                        ("usbdevice_list",   libxl_string_list),
                                        ("vendor_device",    libxl_vendor_device),
                                        # See libxl_ms_vm_genid_generate()
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index 219e924779ff..4da3bb9e91ab 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -2917,6 +2917,8 @@ skip_usbdev:
         xlu_cfg_replace_string (config, "soundhw", &b_info->u.hvm.soundhw, 0);
         xlu_cfg_get_defbool(config, "xen_platform_pci",
                             &b_info->u.hvm.xen_platform_pci, 0);
+        xlu_cfg_get_defbool(config, "xenpci_bar_uc",
+                            &b_info->u.hvm.xenpci_bar_uc, 0);
 
         if(b_info->u.hvm.vnc.listen
            && b_info->u.hvm.vnc.display
diff --git a/xen/include/public/hvm/hvm_xs_strings.h b/xen/include/public/hvm/hvm_xs_strings.h
index e1ed078628a0..ebb07b9fba56 100644
--- a/xen/include/public/hvm/hvm_xs_strings.h
+++ b/xen/include/public/hvm/hvm_xs_strings.h
@@ -14,6 +14,8 @@
 #define HVM_XS_BIOS                    "hvmloader/bios"
 #define HVM_XS_GENERATION_ID_ADDRESS   "hvmloader/generation-id-address"
 #define HVM_XS_ALLOW_MEMORY_RELOCATE   "hvmloader/allow-memory-relocate"
+/* Set xenpci device BAR as UC in MTRR */
+#define HVM_XS_XENPCI_BAR_UC           "hvmloader/pci/xenpci-bar-uc"
 
 /* The following values allow additional ACPI tables to be added to the
  * virtual ACPI BIOS that hvmloader constructs. The values specify the guest
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 16:32:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 16:32:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011122.1389452 (Exim 4.92)
	(envelope-from )
	id 1uP1tU-0006XP-6U; Tue, 10 Jun 2025 16:32:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011122.1389452; Tue, 10 Jun 2025 16:32: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 1uP1tU-0006XI-3j; Tue, 10 Jun 2025 16:32:12 +0000
Received: by outflank-mailman (input) for mailman id 1011122;
 Tue, 10 Jun 2025 16:32: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 1uP1tS-0006XB-5V
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 16:32: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 71cc4437-4618-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 18:32:05 +0200 (CEST)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-451d3f72391so73749375e9.3
 for ; Tue, 10 Jun 2025 09:32:05 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-452730d1686sm142476155e9.36.2025.06.10.09.32.04
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 10 Jun 2025 09:32:04 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 71cc4437-4618-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749573124; x=1750177924; 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=LZ5zMImTrGbCacpXytEnWARBBlNEOagkT1kAlaMqFY4=;
        b=nmiF7Ppxld4oba7m+/eUSDGPkSaW7vpTxL0iE9MgJ3GuDZ6Z0HvEYxPMiDg7l0WzKu
         aBvnbB6jNzdSPwfkHMAJki35UeChsnplmPr821BApuqUcgEyeIp4aHCxNpgKsfWCDs7r
         2jCeUkox8kkIYgU2ud4HpufypfH8zryMxyXdI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749573124; x=1750177924;
        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=LZ5zMImTrGbCacpXytEnWARBBlNEOagkT1kAlaMqFY4=;
        b=e+X+F8n3h5ELm/LP/DqnyEz7cTYz90bybzC5h2raOGQKuKHLskf54X3G8W6piyPrTT
         Hsjr2sMALPE6raTtPjYbvG1i+n55efptAZa1QFt6uOqJBQh9Kur0+7ChnwI3eL73B2+/
         prCkz/9ZcsI64MVh/uddFBZXfTS3yyHbnQszc0xaJXBgO9CMI5vjat9nL8zLxcQntuOv
         ViWrFF3nb5ymjIbdDEUU7Z+X2u04WfhNhpG4BUdLr9aMNOFqEfBuRj2mx3nPyCBXPFSf
         5fxIFRN15Q4/1uZdDo7s8eJn+J7lKSf8c2dieJsmUxuQZoU/bi403MOdw+GpHfJMjkAr
         En+w==
X-Gm-Message-State: AOJu0YyHddGCcm2p9krIU9qE8+dHOXnv0sSVR5kSjT95jQTlqkJhbSYa
	BD15xI7MFge690Z8EWMcNit7ZVVYsP3JU7nQM5Or8sEQrF/cYMx/s2fUDrfDVKdHRww=
X-Gm-Gg: ASbGncvEKUhgdXhnhU97fctAV6/bqK6WOs6h/3gnUe+E5MZFmJPYV3p5Cg/ynoh2TI6
	BXeJLQQoxfDVbDzq3MtwCUXCP/SVG3UJrkUJ25W/uA3MN+/93UVgcH3hnky1oZliduTXMwtysXS
	/75pORGOdOYdayWHRt5RpAGguxip198IK7YIqVRjpAVsIIyaRTWy14nF6//qq5qwf8DHPjaqDm6
	5WcyCGca4OERWsSMHMi0/7RUCs1KFUi/rcj5+Dh65znl0AYS2YHhkZk+7HN/YuYvXAwqXN/2fo0
	c8zTdhCzJsny5a8J6UTNpamo/9/gw63RqB/AlHGYmqo8Jkbm1Wmj1gYZ9CubyDOAx9Vkj0bimCU
	gDi+gVIoOAM2dtH9FwSyt0LYOK7ZbXtgXTbY=
X-Google-Smtp-Source: AGHT+IHzijZoYtpN4xT/77jJRmPlAKHqK8yAzDFu43O5hNNdjctWcc7slU7dkIY5QskBrGQ1aRJJnQ==
X-Received: by 2002:a05:600c:6986:b0:453:2066:4a26 with SMTP id 5b1f17b1804b1-45320664b3bmr30446655e9.16.1749573124562;
        Tue, 10 Jun 2025 09:32:04 -0700 (PDT)
Date: Tue, 10 Jun 2025 18:32:03 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Stewart Hildebrand 
Cc: xen-devel@lists.xenproject.org,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: Re: [PATCH v2] xen/arm: fix build with HAS_PCI
Message-ID: 
References: <20250610142300.197599-1-stewart.hildebrand@amd.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Tue, Jun 10, 2025 at 12:16:42PM -0400, Stewart Hildebrand wrote:
> On 6/10/25 11:51, Roger Pau Monné wrote:
> > On Tue, Jun 10, 2025 at 10:22:57AM -0400, Stewart Hildebrand wrote:
> >> In file included from ./include/xen/pci.h:72,
> >>                  from drivers/pci/pci.c:8:
> >> ./arch/arm/include/asm/pci.h:131:50: error: ‘struct rangeset’ declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
> >>   131 | static inline int pci_sanitize_bar_memory(struct rangeset *r)
> >>       |                                                  ^~~~~~~~
> >> cc1: all warnings being treated as errors
> >>
> >> Fixes: 4acab25a9300 ("x86/vpci: fix handling of BAR overlaps with non-hole regions")
> >> Signed-off-by: Stewart Hildebrand 
> > 
> > Sorry, it was my fault.
> 
> No worries, it's pretty hard to catch when it can't be built without
> extra patches.
> 
> > Would it make sense to introduce a Gitlab build that has HAS_PCI
> > enabled?  Or it won't build either without extra patches?
> 
> It requires one extra patch ("xen/arm: pci: introduce PCI_PASSTHROUGH
> Kconfig option"):
> 
> https://lore.kernel.org/xen-devel/20231113222118.825758-1-stewart.hildebrand@amd.com/T/#t
> 
> It has an ack, although it needs a rebase and we would probably want to
> add HAS_VPCI_GUEST_SUPPORT now that upstream has that config too.

I think it would be helpful to be able to do a Gitlab build with
HAS_PCI enabled on ARM, otherwise it's inevitable for build issues to
creep in sadly.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 16:37:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 16:37:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011128.1389462 (Exim 4.92)
	(envelope-from )
	id 1uP1ys-00078T-Q0; Tue, 10 Jun 2025 16:37:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011128.1389462; Tue, 10 Jun 2025 16:37: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 1uP1ys-00078M-M6; Tue, 10 Jun 2025 16:37:46 +0000
Received: by outflank-mailman (input) for mailman id 1011128;
 Tue, 10 Jun 2025 16:37: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 1uP1yq-00078E-KQ
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 16:37:44 +0000
Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com
 [2a00:1450:4864:20::444])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3baaa94a-4619-11f0-a307-13f23c93f187;
 Tue, 10 Jun 2025 18:37:43 +0200 (CEST)
Received: by mail-wr1-x444.google.com with SMTP id
 ffacd0b85a97d-3a536ecbf6fso2453328f8f.2
 for ; Tue, 10 Jun 2025 09:37:43 -0700 (PDT)
Received: from [192.168.86.29] ([90.250.112.104])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a5323b33c3sm12879109f8f.34.2025.06.10.09.37.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 09:37:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3baaa94a-4619-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749573463; x=1750178263; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=IrxesT9NgLHny01wQYS35m4yKvsiIFp0Y0WdDHKomoA=;
        b=jrzyOKJCoh+CuGQJu1TkDFjtfVfBazUYB44ROmKk2UuxpAgYxk6tXMqcKDUhi3saKY
         mhnVwa/Dsfcn3dirrgkk7e5iFeLZEel5ojlZFug3G0/n6GU9uHMkHGlUk+6kpAMIzQWM
         6Q5XiMMX9/X9pQEc82Bbj1nHS2ayM4fk3uQks=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749573463; x=1750178263;
        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=IrxesT9NgLHny01wQYS35m4yKvsiIFp0Y0WdDHKomoA=;
        b=u1D4rC3qzLMcjv2d+93Q+RfwXY9rJkQMO3WX3POk1tk9lv7zdD7UHSfB8xQ1GtbEPd
         +iu00da3sGahZ01M7NEPbK1G/Wd4pBtk8ETUh10z2igm33+cSE0/NYYnY4v4kTvcO0gU
         Ja4XO7iXJGiNFywWQbBcivR0/+97dgMBadd+8Vxx3wMYP6mwYkPDOU1CZYKIijyoU16V
         Nf18/jcC+WaYgiRClf0ic6P//x35+P6E9U16kmM9EVuoSEC08nJFUBibyd+QJwDOUfiB
         iYKNc9kOWgExJI9EUn8giDXNksfJFyuVa1lrg4yMsnSxT0rHc23l2kKDd5kRjMC6Cdoj
         LjcQ==
X-Gm-Message-State: AOJu0Yyejc7uZyGf7XDQFwzkt6Y0tUwqr35+cmDVE4cev602xq+5xRwp
	VMkXZ4WvjWJU41Ab1ZU8n37Tfcv21TW4PbIas37c0c6h+sHtIUoLkk8gYeaHcTHz7aE=
X-Gm-Gg: ASbGncvCoAHxR9BYlGxIBut2n6UIfiyzuibZL+UePPOufUc20uNi8cJisSIbwjMgB3C
	REPAY9IFbESUct9Ck318enL0OrCHY7y/d4ZhMEJFavk9ELezJhRqojAjKKGdA/S7H781/bwnZfO
	0Fvn/HjUorrFEsXdyMXdnjdaGcmh52bWGh2RrlUBOQKQPa3M8DRkBIsXDz8wvlGChJCvdj4t5/b
	KL7v+1XD0syNzaDVDPs0snIF4W6bA3cTE1nn6D+qIwvYRvj22S0h4xEOuKixAsY5bPXU+vhIhDZ
	jUJhoUzA/WUCulnHJXZD1bdH/n9XuyyJtn00On88SOhSTmnjzaS7hMEF7wjzADtXeEZXFOKUaPM
	lkRs1BlLUsw==
X-Google-Smtp-Source: AGHT+IGqIolVPqMnaaGqAOkecEDbYmBUy49Zvn7BWdVSP+nPUHXddL+pTABIH+O9dRPGZ2oT8QwLBA==
X-Received: by 2002:a05:6000:2582:b0:3a3:7ba5:93a5 with SMTP id ffacd0b85a97d-3a5522791d0mr2446056f8f.26.1749573463181;
        Tue, 10 Jun 2025 09:37:43 -0700 (PDT)
Message-ID: <57c9c8b6-eb06-4793-871e-9120982097a3@citrix.com>
Date: Tue, 10 Jun 2025 17:37:41 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen/arm: fix build with HAS_PCI
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stewart Hildebrand 
Cc: xen-devel@lists.xenproject.org,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: <20250610142300.197599-1-stewart.hildebrand@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 10/06/2025 5:32 pm, Roger Pau Monné wrote:
> On Tue, Jun 10, 2025 at 12:16:42PM -0400, Stewart Hildebrand wrote:
>> On 6/10/25 11:51, Roger Pau Monné wrote:
>>> On Tue, Jun 10, 2025 at 10:22:57AM -0400, Stewart Hildebrand wrote:
>>>> In file included from ./include/xen/pci.h:72,
>>>>                  from drivers/pci/pci.c:8:
>>>> ./arch/arm/include/asm/pci.h:131:50: error: ‘struct rangeset’ declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
>>>>   131 | static inline int pci_sanitize_bar_memory(struct rangeset *r)
>>>>       |                                                  ^~~~~~~~
>>>> cc1: all warnings being treated as errors
>>>>
>>>> Fixes: 4acab25a9300 ("x86/vpci: fix handling of BAR overlaps with non-hole regions")
>>>> Signed-off-by: Stewart Hildebrand 
>>> Sorry, it was my fault.
>> No worries, it's pretty hard to catch when it can't be built without
>> extra patches.
>>
>>> Would it make sense to introduce a Gitlab build that has HAS_PCI
>>> enabled?  Or it won't build either without extra patches?
>> It requires one extra patch ("xen/arm: pci: introduce PCI_PASSTHROUGH
>> Kconfig option"):
>>
>> https://lore.kernel.org/xen-devel/20231113222118.825758-1-stewart.hildebrand@amd.com/T/#t
>>
>> It has an ack, although it needs a rebase and we would probably want to
>> add HAS_VPCI_GUEST_SUPPORT now that upstream has that config too.
> I think it would be helpful to be able to do a Gitlab build with
> HAS_PCI enabled on ARM, otherwise it's inevitable for build issues to
> creep in sadly.

This is what randconfig is for, and randconfig is active for arm64.

If something is preventing this configuration from being picked, that
ought to be fixed.

But, ARM already has a lot (too many) unconditional builds of specific
feature combinations, and I don't think we want more.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 17:16:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 17:16:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011138.1389472 (Exim 4.92)
	(envelope-from )
	id 1uP2Zn-0004Pv-Jr; Tue, 10 Jun 2025 17:15:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011138.1389472; Tue, 10 Jun 2025 17:15:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uP2Zn-0004Po-Gv; Tue, 10 Jun 2025 17:15:55 +0000
Received: by outflank-mailman (input) for mailman id 1011138;
 Tue, 10 Jun 2025 17:15: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 1uP2Zm-0004Pi-E9
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 17:15:54 +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 8bb742bb-461e-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 19:15:45 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3a536ecbf6fso2475611f8f.2
 for ; Tue, 10 Jun 2025 10:15:45 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a532463905sm12957824f8f.92.2025.06.10.10.15.44
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 10 Jun 2025 10:15:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8bb742bb-461e-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749575745; x=1750180545; 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=DiiAb7JJp8lJMcfFcA9s7YnFQ7otp3aPVYVYcuqE0oI=;
        b=qSWj6wY9XtCxRl6RqZWEuBxzsT73Cy0EK4jHytDHUEFXF95qZXlp230Jj7yCkLt21q
         iiy9AhHZ8/XPzeS+CAcWCvzv82e7OrNJvGvJamLmKJHs2Opv7PH4aJwYBZpUa7Q0VDZh
         nPcyY6i1oA7mrBsQCtWHbpgeF4Yj2cU//ZtCI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749575745; x=1750180545;
        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=DiiAb7JJp8lJMcfFcA9s7YnFQ7otp3aPVYVYcuqE0oI=;
        b=RMzvlQhEEVuj7d1lCygPAZ1fRJA6eHPmJdDQmZ5ttk3OggTLh/pz8DLCDr1Hs9lyrE
         rTxGimecs2rtSY3/y+v5nIKeXRzBRXP6oJnHtp3I0xBcPLGP1EJ0KSiY+hiuVZ3OytSP
         1g7tEGsrRy1UWZ2rEQE5dSQ4hcjdKL2SHXE1oql1TGuMrdxRJIO2gkDOLI4W1J029Cj0
         x0f65shLM2Czm3aDbH36EloMh0foBGAtTmMS0qPlgP7PRhjvN3UjleedNeNfj78ejBQp
         v/FBAYQp3er/PuhHkYeMwED+4zRz6c0lQCB3ex3R3D+6JletKTKn1u84FGsFTIWkhMa5
         joyQ==
X-Forwarded-Encrypted: i=1; AJvYcCWDxiaMVkl4lIM7aKlGqN68a/SHpJJnkurHoP5lR0qD/qFnIrhv3fGkefxoM7Cuq8Z+2zH2wfSxpUA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwmlmNOqlv2+3maFfAkv0AQJekcnFvB5dOPUoAJGKpi+Mh8fYY6
	UX6FdaxOsU0RIij+oKFysZaj0CskXGinbWdoBVbHXAsYxWJ4zt3+LBtiy5NSABY4ikg=
X-Gm-Gg: ASbGncvsCaHLcgDPjhSFx80f8E5XcrAY0TQR8bcglGU2HFpFQMLR1jPLg4ZjxCPiRTz
	w3MYq26nwaclFAFOboE3lDWsT36KYIiOWKMIFtO+N6kEVJnOa6oxwraM3YIdhRtpU3rIAyvQTjk
	qJeeIYlhegQR/ZX5wqFBvuP5K3kaO8dR81TOMLWa1YfgneBPNX0fkjU14ihzYLRbsqM6wwdUYeJ
	IwmBx79HU425Zrfdpt5cm8LioJeeEnxhrjlGztWytx2TGzSBdIx6ltuA2W0p3obszEAhgMscTmQ
	BLbYruT6wRVuhomXQR8z5t/34qRzLhvZHFJF7uAXhNL1zdXW4fcLHXS7vl5Sy+cZbN/GXmI1T8/
	OVvjoAETVdeJOycmWdpENKikvE9nwCA==
X-Google-Smtp-Source: AGHT+IEOBthVeqZ+mdJjlEM0X9jn9qz7Rdl6+dSpwMqw+H/jXQYt9o72kQ3Yr17J04dI3giItxWC/g==
X-Received: by 2002:a05:6000:2313:b0:3a5:2cf3:d6af with SMTP id ffacd0b85a97d-3a5522bf78amr3303794f8f.45.1749575744969;
        Tue, 10 Jun 2025 10:15:44 -0700 (PDT)
Date: Tue, 10 Jun 2025 19:15:43 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Andrew Cooper 
Cc: Stewart Hildebrand ,
	xen-devel@lists.xenproject.org,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: Re: [PATCH v2] xen/arm: fix build with HAS_PCI
Message-ID: 
References: <20250610142300.197599-1-stewart.hildebrand@amd.com>
 
 
 
 <57c9c8b6-eb06-4793-871e-9120982097a3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <57c9c8b6-eb06-4793-871e-9120982097a3@citrix.com>

On Tue, Jun 10, 2025 at 05:37:41PM +0100, Andrew Cooper wrote:
> On 10/06/2025 5:32 pm, Roger Pau Monné wrote:
> > On Tue, Jun 10, 2025 at 12:16:42PM -0400, Stewart Hildebrand wrote:
> >> On 6/10/25 11:51, Roger Pau Monné wrote:
> >>> On Tue, Jun 10, 2025 at 10:22:57AM -0400, Stewart Hildebrand wrote:
> >>>> In file included from ./include/xen/pci.h:72,
> >>>>                  from drivers/pci/pci.c:8:
> >>>> ./arch/arm/include/asm/pci.h:131:50: error: ‘struct rangeset’ declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
> >>>>   131 | static inline int pci_sanitize_bar_memory(struct rangeset *r)
> >>>>       |                                                  ^~~~~~~~
> >>>> cc1: all warnings being treated as errors
> >>>>
> >>>> Fixes: 4acab25a9300 ("x86/vpci: fix handling of BAR overlaps with non-hole regions")
> >>>> Signed-off-by: Stewart Hildebrand 
> >>> Sorry, it was my fault.
> >> No worries, it's pretty hard to catch when it can't be built without
> >> extra patches.
> >>
> >>> Would it make sense to introduce a Gitlab build that has HAS_PCI
> >>> enabled?  Or it won't build either without extra patches?
> >> It requires one extra patch ("xen/arm: pci: introduce PCI_PASSTHROUGH
> >> Kconfig option"):
> >>
> >> https://lore.kernel.org/xen-devel/20231113222118.825758-1-stewart.hildebrand@amd.com/T/#t
> >>
> >> It has an ack, although it needs a rebase and we would probably want to
> >> add HAS_VPCI_GUEST_SUPPORT now that upstream has that config too.
> > I think it would be helpful to be able to do a Gitlab build with
> > HAS_PCI enabled on ARM, otherwise it's inevitable for build issues to
> > creep in sadly.
> 
> This is what randconfig is for, and randconfig is active for arm64.
> 
> If something is preventing this configuration from being picked, that
> ought to be fixed.

But CONFIG_HAS_PCI is not user-selectable, it's one of those options
that (usually?) gets selected as part of the per-arch Kconfig.

> But, ARM already has a lot (too many) unconditional builds of specific
> feature combinations, and I don't think we want more.

Either it gets added to the default selection of ARM Kconfig options,
or exposed there using a user-selectable option that would then be
picked up by randconfig.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 17:37:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 17:37:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011144.1389483 (Exim 4.92)
	(envelope-from )
	id 1uP2v3-0007JK-BM; Tue, 10 Jun 2025 17:37:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011144.1389483; Tue, 10 Jun 2025 17:37:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uP2v3-0007JD-6x; Tue, 10 Jun 2025 17:37:53 +0000
Received: by outflank-mailman (input) for mailman id 1011144;
 Tue, 10 Jun 2025 17:37: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 1uP2v0-0007J6-Gu
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 17:37:51 +0000
Received: from mail-10630.protonmail.ch (mail-10630.protonmail.ch
 [79.135.106.30]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a025dab3-4621-11f0-a307-13f23c93f187;
 Tue, 10 Jun 2025 19:37:48 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a025dab3-4621-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1749577067; x=1749836267;
	bh=n+8Zp4ThX8bXf2cDbE03SB7SU8GLT8y0/4kovw9ji1M=;
	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=WifSoPaeSwPgA6bC48ngGhQYFA64GJcRnmCP2CUsMAx6gB42goLq1iLS7IKUaxZZH
	 r4+lK7mE3+SLgYMri93Ix5PCwmYnwhOPG72cd+LiF4zQM/BdNeczCF0TSDy/mOnPXl
	 VXPwxgOQPBqC3Jev5Rbs+y9w+okI17K6WH5OZMX0s2oAZxzna+L2h4jCwAzZkAPmkG
	 vK0h5UJTuKvZBpMkj5l612DYQNCJnmOKHKiufzgFyudcVpdh5q2H/oDp8PY3TULY7s
	 4RhEQsGbCLv3NBUim4D2OmgcigJ0+JXefsp3KSq9+y77Y3v0TuAvoI5hNO2itW1oFS
	 wXl296pHgdEgQ==
Date: Tue, 10 Jun 2025 17:37:41 +0000
To: Jan Beulich 
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v1] xen/console: group pbuf under console field
Message-ID: 
In-Reply-To: 
References: <20250606194937.2412579-1-dmukhin@ford.com> 
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: c09e8553de55c506b95d74878083f167b703fb51
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 10, 2025 at 10:10:44AM +0200, Jan Beulich wrote:
> On 06.06.2025 21:49, dmkhn@proton.me wrote:
> > From: Denis Mukhin 
> >
> > Group all pbuf-related data structures under domain's console field.
>=20
> Fine with me in principle, as I was indeed wondering about the lack of
> grouping when the sub-struct was introduced, but ...
>=20
> > @@ -654,6 +648,12 @@ struct domain
> >
> >      /* Console settings. */
> >      struct {
> > +        /* hvm_print_line() and guest_console_write() logging. */
> > +#define DOMAIN_PBUF_SIZE 200
> > +        char *pbuf;
> > +        unsigned int pbuf_idx;
> > +        spinlock_t pbuf_lock;
> > +
> >          /* Permission to take ownership of the physical console input.=
 */
> >          bool input_allowed;
> >      } console;
>=20
> ... since all uses of the fields need touching anyway, can we perhaps
> think of giving the fields better names? I never understood what the
> 'p' in "pbuf" actually stands for, for example. My suggestion would
> be to replace "pbuf" by "glog" (for "guest logging"), but surely there
> are alternatives.

Sounds good to me.
I can do renaming in v2.

>=20
> Jan
>=20



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 17:40:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 17:40:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011148.1389491 (Exim 4.92)
	(envelope-from )
	id 1uP2xU-0000Lr-M1; Tue, 10 Jun 2025 17:40:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011148.1389491; Tue, 10 Jun 2025 17:40: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 1uP2xU-0000Lk-Ie; Tue, 10 Jun 2025 17:40:24 +0000
Received: by outflank-mailman (input) for mailman id 1011148;
 Tue, 10 Jun 2025 17:40: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 1uP2xT-0000Ld-86
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 17:40:23 +0000
Received: from NAM02-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam02on20625.outbound.protection.outlook.com
 [2a01:111:f403:2405::625])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f8157c35-4621-11f0-a307-13f23c93f187;
 Tue, 10 Jun 2025 19:40:17 +0200 (CEST)
Received: from BN9PR03CA0359.namprd03.prod.outlook.com (2603:10b6:408:f6::34)
 by PH0PR12MB8176.namprd12.prod.outlook.com (2603:10b6:510:290::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.35; Tue, 10 Jun
 2025 17:40:13 +0000
Received: from MN1PEPF0000F0E4.namprd04.prod.outlook.com
 (2603:10b6:408:f6:cafe::6b) by BN9PR03CA0359.outlook.office365.com
 (2603:10b6:408:f6::34) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.28 via Frontend Transport; Tue,
 10 Jun 2025 17:40:12 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 MN1PEPF0000F0E4.mail.protection.outlook.com (10.167.242.42) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Tue, 10 Jun 2025 17:40:12 +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; Tue, 10 Jun
 2025 12:40:12 -0500
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; Tue, 10 Jun
 2025 12:40:12 -0500
Received: from [172.27.195.250] (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 Jun 2025 12:40:11 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f8157c35-4621-11f0-a307-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=LG0Nu7vFxr38MyBO2jp5g5savh+zCQM1nwXFDkwi9jMmOcTFtFbL08H7WcyUT3NAXbdo/inYBrai0jNu9HrcfdBqn1sLj1YIsQroEBPcWY1andpGraLGDUOS05DVIYwa1KBsvZJP0BqYXXtmteBAVTcwKNv+LY9q8rwallO5bciq5rdw8lyDjtq3ctMc3lVkXAg+eDtPA8BkT89AndYXvBAIMGok04uFdfnj+MsEU8Kf5MXXTjaE5p+RWDUxD1kvf0X7530HlcbRnronlewFjr87Eh8ugOq9vNRpx2BDjopYwFYLkgoz9eMpCXFK8A009t+n9MfNjfO9i5XrNggwkA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=PksA5C6iw+sZppG3ZXdMEOJitc+OQy9il77T0rpHx80=;
 b=PcFOLQOJSyZnvOvl/nqjXdB3ZVE9X4zrZzv029VFhClygXgOXT4jRaSsOjlEZ3S+JJNjWI0oRsYarHLJn4wLvFBKxz9k7BTlV1nkKnqTO10m5+q1DAqOhTEzNFEcBLAX+EyLOLeiFFH9KzC1ixGghPgG0id1/7zQRPlfvJ1TH/cXi7mb3AiVqY3XF4DBdO8r+deYBCDEEb5CyUrjRvHJnigskbjibap1Qt9c9fA/1VX8F9EZp7mondmPWJkB2J435X6xs/5MiCVwYrsK5BkIWlCSklU3kzuwmD559JZQgV9oDB4ZdrNiMzuT6Zqvm4WVZSUmEo+JuXV1+5gRFZxWPw==
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=PksA5C6iw+sZppG3ZXdMEOJitc+OQy9il77T0rpHx80=;
 b=LSGyv1DxpxM8spmgXwrF5NQC8KsdwhuFOd18HK+AFXQDaSdVLZOBoZcMrhzwVP+2DCDFfg5/pbkKUDuu14eDHRTyio+pGlgKkbM2/rUfl2gCD9KpYeiu7AOOrqHuRFrrYaMutL+5AsKA+vNe9IktejRsik82TFuj+Wl3UwJ3qYI=
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: <03be429c-063d-4467-91e7-7ef2e148a2fb@amd.com>
Date: Tue, 10 Jun 2025 13:39:03 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 06/12] x86/hyperlaunch: obtain cmdline from device tree
To: Jan Beulich 
CC: "Daniel P. Smith" , Andrew Cooper
	, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	, Anthony PERARD , "Michal
 Orzel" , Julien Grall , "Stefano
 Stabellini" , Bertrand Marquis
	, Denis Mukhin , "Alejandro
 Vallejo" , 
References: <20250429123629.20839-1-agarciav@amd.com>
 <20250429123629.20839-7-agarciav@amd.com>
 <59f37fcc-9226-46c5-8dc8-7bd2100d8f59@amd.com>
 <02ffa9cf-b5cd-431a-834a-a11bbf310196@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <02ffa9cf-b5cd-431a-834a-a11bbf310196@suse.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
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: MN1PEPF0000F0E4:EE_|PH0PR12MB8176:EE_
X-MS-Office365-Filtering-Correlation-Id: 1904aaf8-0c6d-46e8-87ba-08dda845da5d
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?NVBkWXdUcEN0MlE5S1pNYWRTMzUwUGpHTW5meVBtNk9pVDVHdUN2Z0dGSHJG?=
 =?utf-8?B?N0JodmV5ODZxODF0Z0tVaXkzMVhYeDNqWUtiRDZtYnd5R0RoL2drUFZJc0tU?=
 =?utf-8?B?TmZZY0l2ZUdEaUI4WHFDeHphTXpld2cvalg1U3NUeFF3eWtFNThydU1mdEdk?=
 =?utf-8?B?cWlKUWpoMEtUazZWVk9mb0RNajM2NlNPUEdHUFdWZnRsV1Zva2Q2Mkx6SmxM?=
 =?utf-8?B?UmtWbnB3REozQVJnQmRjYUNiWFIwY3ppL3ZFRkhWcC9iSENwV3FCZFJKQnEz?=
 =?utf-8?B?RUR3YWpOWU1RdkNid1BhaFk4UFdwd25uQi9tWStod0FyQ3drWU1uUitOVWow?=
 =?utf-8?B?STVCMjd3bnBteXpYN2REM2hmNzlFSkNWZWpXK3lFa3YxSHZKdFM5VFFIMEhB?=
 =?utf-8?B?NmRndlFheWdxZ2dBU1A2R3JNeEE2QmJEczF0RG9RTEVYTkZtcmpobWFQTmVJ?=
 =?utf-8?B?VXJmbnVOS3VLNzlpM1BtWHI2blp6KzBrOHVXSjVmUnBlSDhMdGpuYkdkelhh?=
 =?utf-8?B?N1IvdXM4Rkt5UTgxZDU1TDA4VmsybGowSXVtUDc2ckVuSUxoN2lJMTB1dkxH?=
 =?utf-8?B?WTQ0SVlGN0NFQVA2MWdRTy80MXlrakttUko0YlZJRUNUbDJQMEIvYWhpKzlq?=
 =?utf-8?B?Sk9oY2p4TDNuUXhjWUlQa1I0RmE1alhDQnVyU3pJUEFsQnNNWHlmOGcxdHo2?=
 =?utf-8?B?MUF6ejQza0ZxL0FNWWhtY0JocU9lOWM3TXlpK2NrVy8yN2RSR21zRVppRVZu?=
 =?utf-8?B?a0orb3h2dHdaUGlHZmRVd002aUoxbU84bEV2d2tFbzFYVXVGTmhFNjdyY3gw?=
 =?utf-8?B?cnJoZnVHaW5OWVQzdEUwQ040MVp6aTZaM0VEaW1DNzR5ZXdGV04vdlF4c3Y5?=
 =?utf-8?B?KzhGQmJIQVlKc2htODU4QXN2WDhYZ1NDOU42c1FRQWpRTUlNUjRxUUcybmpF?=
 =?utf-8?B?RjJERk4vWHlmWVIvaDluRU0yaFBPNGlWWmxDcXByMGZjeWtiNEMyUG5GMVdF?=
 =?utf-8?B?eCt0bStJNDFDS0JFd0xCQ3FYcUxOalIzbFQ1TXJTTmdSdDRFRjdSVVJHSm41?=
 =?utf-8?B?czRKeFJWYnYyNjRWbTFlUXNvVWRjZ004Q09wUzJtK0FBTVozZGFyZE9SeDIz?=
 =?utf-8?B?NGZDWThQN1ZKcEJ3QTdPbDc2MWhXanNQaDRRdTIxSjRrc2pwMEdrQk1OOHgw?=
 =?utf-8?B?bXROSkhQVm5LdFJjbERBb3l2akxxVVJZSUhxenEreDRmSW5FcWgrL0JTMzVz?=
 =?utf-8?B?MjY4eEhuMTExeFFSMFR2Y0gyak16TVA0Nlh5aC9kQnJWVVBrR0J1SFFSL3dw?=
 =?utf-8?B?eXVxeVdoUGhESG14OHhzYXptbGF5MVlwSjRvRW5xeStLa3FKaTFNSzk4Uzhz?=
 =?utf-8?B?dUpGTk94K1BCczUyOG9POVZUM1FyaW5jSEZIOEVkaWhWRmhBZmU5K29KKzZU?=
 =?utf-8?B?KzdudDA4Qi8vR3lJNzg4ekdOZDdLR0UxK25DYU42bEtVZ1lUWkdtNG5CUURG?=
 =?utf-8?B?RHNGeFJJK1Fpc2FSaSt3ZEV5aXF3c0hBNWhYWTdBUXV4dURQY01udEx0TWpJ?=
 =?utf-8?B?Um1tdTZiYzNCV2YrQ1NHRGQvMG1GQWUzQnFqUlhCblRGaS9OaXZkNmM3L0NY?=
 =?utf-8?B?S0s3K1c0ZEZoUnRJdXRsY3lkU3ExdVdNQU5tVGtiNDRrQ1R0TEYvUEJ6WmxN?=
 =?utf-8?B?Yk82V0k5SGdPUDMvZHlvcHNEYituZUFKVVUveXRyYlhCL1JqYXFoM0xyTGpW?=
 =?utf-8?B?YWRURkdoK1MyZlJmb0R1NThsVkY0eVVMeHVvN3dDTEM0Y016bW8yUzdwVm9T?=
 =?utf-8?B?Si9qdzdtVHgzZDQ3R0FReDNaL0Rnckd5Z013SU94YTF2cnlhd3Bkc20yOTRN?=
 =?utf-8?B?cCttRlJjcEhFL3M5TzRneVA1UzlkT0h2Q3QyMXNPc0lTdTM2OXR2N0d6T2JU?=
 =?utf-8?B?VWJJQ295VWt3d0xydC8rS2pwVzE1cWFRMTYyaFpyYVlRdURCMFp5S3c2VmEz?=
 =?utf-8?B?MGJONm5ENEtOYnVKNmNjdGllOWpXUmNueXBYaDFOZEYxY20xS2Q0SzM3Lytr?=
 =?utf-8?Q?u0qciG?=
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: 10 Jun 2025 17:40:12.5803
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1904aaf8-0c6d-46e8-87ba-08dda845da5d
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:
	MN1PEPF0000F0E4.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB8176



On 2025-06-10 02:56, Jan Beulich wrote:
> On 09.06.2025 19:07, Jason Andryuk wrote:
>> On 2025-04-29 08:36, Alejandro Vallejo wrote:
>>> From: "Daniel P. Smith" 
>>>
>>> Add support to read the command line from the hyperlaunch device tree.
>>> The device tree command line is located in the "bootargs" property of the
>>> "multiboot,kernel" node.
>>>
>>> A boot loader command line, e.g. a grub module string field, takes
>>> precendence over the device tree one since it is easier to modify.
>>>
>>> Signed-off-by: Daniel P. Smith 
>>> Signed-off-by: Jason Andryuk 
>>> Signed-off-by: Alejandro Vallejo 
>>> Reviewed-by: Denis Mukhin 
>>> ---
>>
>>> diff --git a/xen/common/domain-builder/fdt.c b/xen/common/domain-builder/fdt.c
>>> index cbb0ed30a2..dabe201b04 100644
>>> --- a/xen/common/domain-builder/fdt.c
>>> +++ b/xen/common/domain-builder/fdt.c
>>> @@ -219,6 +219,12 @@ static int __init fdt_process_domain_node(
>>>                printk(XENLOG_INFO "  kernel: multiboot-index=%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] )
>>
>> The logic is incorrect - it should be:
>>
>>              if ( !bd->kernel->cmdline_pa ||
>>                   !((char *)__va(bd->kernel->cmdline_pa))[0] )
>>
>> If there is no cmdline_pa (which happens with the "reg" property) or the if there is a 0-length string, then check the DT for bootargs.
> 
> Even that sounds bogus to me: There's a difference between "no command line"
> and "empty command line".

Yes, you have a point.  The difficulty is grub always provides a NUL 
terminated string, so Xen can't differentiate the two.

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 17:46:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 17:46:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011155.1389502 (Exim 4.92)
	(envelope-from )
	id 1uP33f-000136-9E; Tue, 10 Jun 2025 17:46:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011155.1389502; Tue, 10 Jun 2025 17:46: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 1uP33f-00012z-6U; Tue, 10 Jun 2025 17:46:47 +0000
Received: by outflank-mailman (input) for mailman id 1011155;
 Tue, 10 Jun 2025 17:46: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 1uP33e-00012t-7K
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 17:46:46 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20623.outbound.protection.outlook.com
 [2a01:111:f403:2412::623])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id def93b78-4622-11f0-a307-13f23c93f187;
 Tue, 10 Jun 2025 19:46:44 +0200 (CEST)
Received: from DM6PR08CA0029.namprd08.prod.outlook.com (2603:10b6:5:80::42) by
 IA1PR12MB8588.namprd12.prod.outlook.com (2603:10b6:208:44f::19) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.38; Tue, 10 Jun
 2025 17:46:40 +0000
Received: from DS3PEPF000099D4.namprd04.prod.outlook.com
 (2603:10b6:5:80:cafe::b1) by DM6PR08CA0029.outlook.office365.com
 (2603:10b6:5:80::42) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.19 via Frontend Transport; Tue,
 10 Jun 2025 17:46:40 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 DS3PEPF000099D4.mail.protection.outlook.com (10.167.17.5) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Tue, 10 Jun 2025 17:46:39 +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 Jun
 2025 12:46:39 -0500
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 Jun 2025 12:46:37 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: def93b78-4622-11f0-a307-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=FXepyki7lPQi795Hsr6y6frYhaDCD5C9UNfkovwIRR8rMBihKqLckAlMUf0Ej5fkd/f3MNgvZt5VU/CZSN+F6kgTbfWCrix4cVJvbylbkkCaG6Bq9yzbTFlsHTp09CADGkKaZmR55MNhgerjVKg9tRzW5iDU139t0mWsrCH3GPdR24kd+dJe3EhVZ+VgqrjG7NtVuse95r8Nr5+lBsvcbB47ebdIEOrSNeqBt2jux0XkmkBaYKdgfoRRHwPAVS97edMbSgVZm2IJct/MbVbD7oK/U6KaR0nO1yONoe4LfmSJ6AN/A6W/XCiy1l4HpcNvuwp3TBwEwWrONL5ETue4cg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=2bEb9fNvb2msY5p20GZTzmeXGe1QTu1AvV8qLq/dRag=;
 b=Uh3MTHMZOrcx9YBwAlmv1migvVkr6KGQqDO8S/YyyCgM0mFkB7z17NpQhVYu2YSeWiE2eJK015NpbIfu88xoQtIgL0AJaX/E5fJgcUUte3o3FnNwkl2Pn8nwMFHvD5Ktq4TVa6QbnX+5XF3PyQhX9AD+ZQViSUt/bGWQIhur/b39kkSne/GAZiVIM5Y9SFQXdJ346MxJS43UiHbiETgXwC8pvzHiTFzT8XE9OXM0rMoqRkiLfg7D1+ljpvBrrJm3YW1eImpQ0pzjf5/PQrqXGJgK/gj4BI4TFTi2nJ1F9eqqLPUU0R/QUcpOsFe/AH9Z3FOgBhL7SKTW5RbAq1aF1w==
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=2bEb9fNvb2msY5p20GZTzmeXGe1QTu1AvV8qLq/dRag=;
 b=Fg0hI4emgKvHvideCPrIeXlTXybizUmaEnnXxemaslPHJR9LflBHVWJlpe7VkohwtJPkPKdCYNN+7CNM4VeR0ZVFkEv3lUIjH8tBZvwaTpO0X7AWOsPkkUGbk1zdrMKI1FZ+9wEFtM1aNgtPPVLyGriAEm1fDrNN7bN6ANW9TAo=
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: Stewart Hildebrand 
To: 
CC: Rahul Singh , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Andrew Cooper , "Stefano
 Stabellini" , Stewart Hildebrand
	
Subject: [PATCH v7] xen/arm: pci: introduce PCI_PASSTHROUGH Kconfig option
Date: Tue, 10 Jun 2025 13:46:22 -0400
Message-ID: <20250610174635.203439-1-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB04.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS3PEPF000099D4:EE_|IA1PR12MB8588:EE_
X-MS-Office365-Filtering-Correlation-Id: 6e711a4c-162d-4ba3-d8e7-08dda846c13a
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|36860700013|82310400026|13003099007;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?qhhAYKs0h/6MvD6FKZoJvbGdg2N6XM095gSJnfuPwOtIO5J5ZsDKVkPOQ3jT?=
 =?us-ascii?Q?BVDwByu1j7hNncDDMZi/BUswFvaLSPUoKD19HokSUuXQ3aB2n/DFLdHYY3WN?=
 =?us-ascii?Q?GmKAChvqXhUb+4CYm4J3sL+GTBnea46hsCXnmy8mFguMdi1fRoa/HUhxusTq?=
 =?us-ascii?Q?KHrHOZMm9ggZCFfXEMKRjWgOzFyOwkoL4zsp68zibnj8m1HTbByKHsELUhxs?=
 =?us-ascii?Q?lfQNNNtPwAVK+NFnCZCPxMj53aKKL49VjwjGwjZAR3hvUtE3DporRYQQF4Nd?=
 =?us-ascii?Q?sxRv8ge5juO/UJzZ0LTCTQCpPjVEo3p4OdVpwC1VSs3H+1WKmPOHcr48Jf77?=
 =?us-ascii?Q?J5UBX5LKGZgh6q5yERxXDUer5ZIgvPRVuvKwmCA/mun+KVKDuqsokIqm9PeY?=
 =?us-ascii?Q?q1yao65B2AikirPs/E/84rvy6DzvclOA8gOtNTMPY4fQX1hKwwUiwWhLXS5G?=
 =?us-ascii?Q?sONm6BqgvSmhs0ZAGEwE9m+Yxl3Oa41qN9uaZpVExAcnqBn1UeV5NE/W9VhY?=
 =?us-ascii?Q?O2Z2jQWltnRXMm2Y9WmXSa8PmTa90uFi2NGceQInusa8XYXGvWIK1gRtqAJs?=
 =?us-ascii?Q?z6k7s2W8EGu4a7HWpr0cNxGAa5hLpEAX+3cS5tNTiqdTBCPCRwy6G/HXtwcW?=
 =?us-ascii?Q?V1mQ8iZafpx/d0gTvVKQev7BMW4bIvdW840KOqJ3pJXWbN0KsIscXaKFyaXs?=
 =?us-ascii?Q?8q+Z0fTo1vj09acZLRPQ0krk8pyD4ECw8L7UdIJZMOag3IgFOClR7iSVDiGm?=
 =?us-ascii?Q?SY5WssLWSjPUCEgxuiheDlaBb+EB+7uEClknXkyRlxBVDUtxxuUQWM1+DkY5?=
 =?us-ascii?Q?Xmvr/OmusT8v6+x0CgrZ7KrMMesxcFP08xOL9qiAQJn3h0P9qf1jy/8JIoaR?=
 =?us-ascii?Q?mu3dShq8+Bqw2YXYQPUGk709h/lIlPjhCLjO9kv40SusbJ069wJTTW99jEWh?=
 =?us-ascii?Q?V9kvg7cLEB25tq4O39lAtJJRBzrjfmSy31Evp9r2tXhf6kL+5T5tP7rh+Jwm?=
 =?us-ascii?Q?PIFy8qM1v9BZAz5J6a2woeVKYFKhhWhUAlnxIZ4VJ08k70Kqlemdf9hcNz4f?=
 =?us-ascii?Q?MWljBeEDgqpXrd+Exmo/pwLLT40zufDbgg1UWA3MJv+2r0nELrqJXOWzG/zi?=
 =?us-ascii?Q?xJXuvXk7CBYzswNnqqjeYKxJKBZuex8qxxhQ/+XRgEkcj5iwJoAGg16pKFD9?=
 =?us-ascii?Q?CDpCVEJnLiNjRdzsmequIrUhjrcb6OTTOWTUmLOktcDlyMSq5uNpaiZri49R?=
 =?us-ascii?Q?+3sSU6uHejLkVwXK5VF52TyKx6J8tFyf+o5QAyhBL05v9N/lKC9JE3Cz9v3/?=
 =?us-ascii?Q?Hf+EQ5UEcgsA03wk5VQ/1PNPfMdeS9C+2gLUPRvqnqv6ZBcG7+Sz9ooPYJMF?=
 =?us-ascii?Q?6OE93t6L52fJVUn0+nhWLuhydDY3HN3TNB/Bfx7Bvv/VNSooypmuXBHuDPCk?=
 =?us-ascii?Q?aCRIZNKkFEx0f4bXXIwPHPSS3yzFWu5Xn1dKRV1Z848qVmFbSblC16JIlvT7?=
 =?us-ascii?Q?MhKe4iZ7jwTHBQo=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)(13003099007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jun 2025 17:46:39.8686
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 6e711a4c-162d-4ba3-d8e7-08dda846c13a
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:
	DS3PEPF000099D4.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB8588

From: Rahul Singh 

Setting CONFIG_PCI_PASSTHROUGH=y will enable PCI passthrough on ARM,
even though the feature is not yet complete in the current upstream
codebase. The purpose of this is to make it easier to enable the
necessary configs (HAS_PCI, HAS_VPCI) for testing and development of PCI
passthrough on ARM.

Since PCI passthrough on ARM is still work in progress at this time,
make it depend on EXPERT.

Signed-off-by: Rahul Singh 
Signed-off-by: Stefano Stabellini 
Signed-off-by: Stewart Hildebrand 
---
This requires ("xen/arm: fix build with HAS_PCI") [4] to be merged first

The alpine-3.18-gcc-arm64-randconfig CI job should pick up the new
config option, but if we wanted it to be built more consistently in CI
we could add CONFIG_PCI_PASSTHROUGH=y to one of the arm jobs in
automation/gitlab-ci/build.yaml, e.g. alpine-3.18-gcc-debug-arm64.

v6->v7:
* rebase
* send patch separately from series [3]
* add HAS_VPCI_GUEST_SUPPORT since it's upstream now
* drop Julien's A-b due to changes and was given several releases ago

v5->v6:
* no change

v4->v5:
* no change

v3->v4:
* no change

v2->v3:
* add Julien's A-b

v1->v2:
* drop "ARM" naming since it is already in an ARM category
* depend on EXPERT instead of UNSUPPORTED

Changes from downstream to v1:
* depends on ARM_64 (Stefano)
* Don't select HAS_VPCI_GUEST_SUPPORT since this config option is not currently
  used in the upstream codebase. This will want to be re-added here once the
  vpci series [2] is merged.
* Don't select ARM_SMMU_V3 since this option can already be selected
  independently. While PCI passthrough on ARM depends on an SMMU, it does not
  depend on a particular version or variant of an SMMU.
* Don't select HAS_ITS since this option can already be selected independently.
  HAS_ITS may want to be added here once the MSI series [1] is merged.
* Don't select LATE_HWDOM since this option is unrelated to PCI passthrough.

[1] https://gitlab.com/xen-project/people/bmarquis/xen-arm-poc/-/commits/poc/pci-passthrough
[2] https://lists.xenproject.org/archives/html/xen-devel/2023-10/msg00660.html
[3] https://lore.kernel.org/xen-devel/20231113222118.825758-1-stewart.hildebrand@amd.com/T/#t
[4] https://lore.kernel.org/xen-devel/20250610142300.197599-1-stewart.hildebrand@amd.com/T/#t

(cherry picked from commit 9a08f1f7ce28ec619640ba9ce11018bf443e9a0e from the
 downstream branch [1])
---
 xen/arch/arm/Kconfig | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 3f25da3ca5fd..778feff16a55 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -258,6 +258,16 @@ config PARTIAL_EMULATION
 
 source "arch/arm/firmware/Kconfig"
 
+config PCI_PASSTHROUGH
+	bool "PCI passthrough" if EXPERT
+	depends on ARM_64
+	select HAS_PCI
+	select HAS_VPCI
+	select HAS_VPCI_GUEST_SUPPORT
+	default n
+	help
+	  This option enables PCI device passthrough
+
 endmenu
 
 menu "ARM errata workaround via the alternative framework"

base-commit: 86a12671c5d33063b6f958bdcca7c9d14cd5aac8
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 17:51:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 17:51:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011165.1389512 (Exim 4.92)
	(envelope-from )
	id 1uP386-0002kH-V6; Tue, 10 Jun 2025 17:51:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011165.1389512; Tue, 10 Jun 2025 17:51: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 1uP386-0002k9-S4; Tue, 10 Jun 2025 17:51:22 +0000
Received: by outflank-mailman (input) for mailman id 1011165;
 Tue, 10 Jun 2025 17: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 1uP386-0002jz-0R
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 17:51:22 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20614.outbound.protection.outlook.com
 [2a01:111:f403:2415::614])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8359e14b-4623-11f0-a307-13f23c93f187;
 Tue, 10 Jun 2025 19:51:20 +0200 (CEST)
Received: from BL6PEPF00016411.NAMP222.PROD.OUTLOOK.COM
 (2603:10b6:22e:400:0:1004:0:9) by MW3PR12MB4409.namprd12.prod.outlook.com
 (2603:10b6:303:2d::23) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Tue, 10 Jun
 2025 17:51:16 +0000
Received: from BN1PEPF0000468E.namprd05.prod.outlook.com
 (2a01:111:f403:c803::3) by BL6PEPF00016411.outlook.office365.com
 (2603:1036:903:4::a) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.31 via Frontend Transport; Tue,
 10 Jun 2025 17:51:16 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN1PEPF0000468E.mail.protection.outlook.com (10.167.243.139) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Tue, 10 Jun 2025 17:51:16 +0000
Received: from localhost (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, 10 Jun
 2025 12:51:14 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8359e14b-4623-11f0-a307-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=wWJIwvrKoAwiOlSi+8P8j5SCRB8szyq/qavL3zp5BBZf+cWE2oQk9rIqDyNaHv4digmB5fidl9iKCHrx6vqIgjXUF+I10ZeZDttCuBD8dfYqNmZ0B+ei+fPWrXloMAPqucT/uFVmIfvUPS5q4Q5fqdnHJP3YSQAs3/JuKqd0/zH9rdXT5hGpvGHVtkcsvKeIZUlEEUVjErcF/BJiB1g4WoQ36OU9epljkfi3ghYyeWrOjLQez+clS1/fW8GJef2PU1CmC2vgFXojJqPsUh0VckOf1+IU7j7gvSP5fkoOt0y7niC74fQwTnyuy5wS1mTK+HpFb/xKeRmq982d7FE0Qg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=xOYKum3/hKwNueH2EaNEGHZqmp/D3OcBNiYX/3Aji/Q=;
 b=WT6cH7wFZ/W6MKQ200ooj9ZcbDX7yCQtcN59oTa2exUIFRoxvW0WYkRHGK4aipRhCThOyz7j8MK8Fup60L+0Gw3L6b4El7BiWtQxeQotz+e8ZTxjEnmAgt+Sh2+OzF0TK+EFC2TpWiRyQTKmN/NwDYmkEFMbDd1r2O9Evj+hfMdZxHQwiUBx2wIPT1kOXBXFGK9w8KWc+T1QBTO6oM3Aj3XPKP0ydIZJ0fKPHStc2DLy0tjk/rwoPQuKM7bYyZV2ZlMI+9skd5wX6luhisbDgmC5G7nfQuKq+KxSMLRGx5gbkSftNMPBJyOQsVmh0+gTOf54mPptgcx0ItNeo8veRw==
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=xOYKum3/hKwNueH2EaNEGHZqmp/D3OcBNiYX/3Aji/Q=;
 b=bmk5zEbp/Peou/A3nh5B3SFzFd36Ot4A7R5d2LdCKxa7QEN6YB3RT3nUzpQksE0/yoIfEWtZYLHoMY9/RD99E9tpLwHYaaZq2MhWC3CoL2jAhzbr+v3Kn91wALMJm0D27dRxnB5jFipM/spE5A01K7vQjscj3F9wyyaCF+tQf2o=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 10 Jun 2025 19:51:15 +0200
Message-ID: 
CC: , Bernhard Kaindl
	, Andrew Cooper ,
	Anthony PERARD , Michal Orzel
	, Julien Grall , Stefano Stabellini
	, Xen-devel 
Subject: Re: [PATCH 02/11] xen/page_alloc: Remove `claim` from
 domain_set_outstanding_pages()
From: Alejandro Vallejo 
To: Jan Beulich , =?utf-8?q?Roger_Pau_Monn=C3=A9?=
	, Alejandro Vallejo 
X-Mailer: aerc 0.20.1
References: <20250314172502.53498-1-alejandro.vallejo@cloud.com>
 <20250314172502.53498-3-alejandro.vallejo@cloud.com>
 
 <89d4250e-20aa-4515-8199-7003afb0bcbf@suse.com>
In-Reply-To: <89d4250e-20aa-4515-8199-7003afb0bcbf@suse.com>
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: BN1PEPF0000468E:EE_|MW3PR12MB4409:EE_
X-MS-Office365-Filtering-Correlation-Id: a4f97acb-b4e4-40fd-c902-08dda8476622
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:
	=?utf-8?B?QlJDSExRL2src1Ywbm0wbkMwbi9RbTRyWWJjb1Zaalc2Q2VLcW1zWStkT29G?=
 =?utf-8?B?T2VCdEFjaVVTTGJ2SlpCRG9tQ3A1NnkyNHM2Z0kvK2NIRkx4UENteHYrOVV6?=
 =?utf-8?B?WThaK1FzdkxHNk1iaFJ0MU1uMVkrQ1FQTjF3ZGhEUUhMSHp2SUtyQzRtK0ZU?=
 =?utf-8?B?K1JLSmw1K1RmT09ScFdQS1ZPcjQ5MDRaNkdMTnJaMXhSSmJNNTZSMHZROW1x?=
 =?utf-8?B?QkhESHR2UWU2RTRqdEt2OHM5RXZPcUFJU2tYT21GMlY0UmtGZldEb3dZQ3pG?=
 =?utf-8?B?Z1NDRjA1NzJtdDNibzUzS2JHZGRmOEd0REpoK1NFcWpRdW5iRDRtVTNXU3h0?=
 =?utf-8?B?akdmV01Pcndoc2NNdTRqVGdrWTRuNTZ4MEdsZ2hXOTdkczdmY2o1VHdHUGg2?=
 =?utf-8?B?c0lXdHZzUEZac3dFeFdPSVNwRnRoRlJhMjE2OEpWN1J2b2VUQll5eUJOSWFX?=
 =?utf-8?B?SXd3T25MSUVUVE5PRGJzd1dpeHE5eE96NHV3ei8xZTZIM3NyRG5DZzhpNUJI?=
 =?utf-8?B?UVVQR1BOTHFiV3ZPTXlDUm14azJOU0NnTkNWcEhWYnNzZG55UlZoeUI4NmdG?=
 =?utf-8?B?aXpwZ3lwVnIvcUpCVUdPUEp4TWczdm9icDZ5L2NZanNtOXRyOGRFMytPWU11?=
 =?utf-8?B?aG1ZdXpoR2VMbTJHQnY3MHVSTHFJbmVkRDk2YTFkRkR3WVc5TlZPQmFhVEdp?=
 =?utf-8?B?YlBWcDRZT3ZvOFdER0duai9UTDlHeEdLZ255Z28xdmt2NGJPLzFnSFI1bVFL?=
 =?utf-8?B?QTRYSktiaHVZaWlUbmNYSXpVdE9aSlR2Z0JaQnFiOHI4Q21oWFlqS3NuOUho?=
 =?utf-8?B?M0hQSFFJVmh4TGFoSS9aNnp2ZWRic1FrY2g0QzBWN0Uzb3g5Tm54SFJsdHJL?=
 =?utf-8?B?RXhBWG9BZkRFLzRWMEpORFV1NlU2TWM2RGdjMi9pZTZockFXVkNyUnd1Sk1k?=
 =?utf-8?B?dklSNCtnT1pPRTNJZTA2eFl0VDVQS1dMMCtVaGRMRWFuK3hRcmg3Uy9kNUdH?=
 =?utf-8?B?UUowV3gza0VXNTBOUjRIZ05OUXpQb0dPMDJ3MlkrWDF3VWZQOC9Ra2hBSzBK?=
 =?utf-8?B?NE9WVWZ2SHVVMFcyRjh1SjNRdlYxOFFqODdYblQyYjZjSGkwTVlJNlZBRVRo?=
 =?utf-8?B?UWxKazdOd3lFTjkyVjN4bVgyQTZBTHNuSGR6NERhalo4TndtWlp1aXFacTRu?=
 =?utf-8?B?QU9zNjhMYmFJL2ZFZmd1YUVERDdTT0M2c3kzZ1RpV0NEY050TGo5Z044Zkkw?=
 =?utf-8?B?cThIUXNWSUEwbFpMcGdNdVcvdEtXbXd0eEZUUTVDL2d2dnE4QnNqNmRmcmdM?=
 =?utf-8?B?MXJ6M3pobkZPSEx0KzhvRUFlTXRKSEtqUWpPUzdUR1lTeTZKK2E4WEFjQzh6?=
 =?utf-8?B?cm9FY2J4b28zNEM2b2U3bk5GdFVnenUrVmdlalVuNWR6YXpZNVFPRXpLcVhV?=
 =?utf-8?B?ZWJ3QVJtc2tUR3RhZGZsUUZUcXdMYWcxbTVsQ2VsUGowYXUyVWk3U3NCRjEz?=
 =?utf-8?B?VkZMV0Vsc3RHdEh2VlVHWmtTYW4wQnF6U1BrcHFaYllHZzZiZHUvbUtwS0Uy?=
 =?utf-8?B?aytpMmJ2YjBSaHRFVkhaOFFEVzM0S3pkVDBzRCt5dEtGd21JZmtQYWFkaHpz?=
 =?utf-8?B?ZjlIMmNqam1tSmthS1owR2tJdkpQQmFvaXl3NFRrNXVlT2Z3czQyQklvZ0xz?=
 =?utf-8?B?SStnV0lqWnA0QnplZlhmbmtKQjdzRkk1ME9HL0g0Rmx4TzZoSG5zVzdlTzIw?=
 =?utf-8?B?U2lXOXFya0k2ZjRYU3RUb1hyaEp1b2gvTjhBYjlHcG5TRFJreGJNZmZmZGx4?=
 =?utf-8?B?RHhvcnVzKzNmOEhncUJKMzEwZ0E0Z1lpZkxTREJJNTV4K1pmc2JDVzF4NUNH?=
 =?utf-8?B?eXdUdXJ5MThUeHVNS1ArOEswQTJKQTV3TTMxbVM5bWhlQ3VTOUZQVW1pOFhr?=
 =?utf-8?B?QkpIcWVEbFlYNXNPc0l4bUhwcTQvWG5vOWhIWXl6SlFqS3dzUW1KWnJjNjRy?=
 =?utf-8?B?RXk2WjhhMEQ3cGoxRG52UzM0QTNUUW9DK1g3QnVSMFFzQ1V5TFVaTzNrTDFR?=
 =?utf-8?Q?naZwCK?=
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: 10 Jun 2025 17:51:16.5739
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: a4f97acb-b4e4-40fd-c902-08dda8476622
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:
	BN1PEPF0000468E.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR12MB4409

On Tue Jun 10, 2025 at 2:23 PM CEST, Jan Beulich wrote:
> On 05.06.2025 18:42, Roger Pau Monn=C3=A9 wrote:
>> On Fri, Mar 14, 2025 at 05:24:53PM +0000, Alejandro Vallejo wrote:
>>> With a single global count for the claims it's easy to substract
>>> domain_tot_pages() from the claim so the number given in the hypercall
>>> is the real reservation of the domain. This is the current behaviour.
>>>
>>> However, a later patch introduces exact-node claims and those interact
>>> very poorly with such a scheme. Since accounting domain_tot_pages() in
>>> one case but not the other seems strictly worse than not accounting the=
m
>>> at all (which is at least consistent), this patch stops substracting
>>> tot_pages from the claim and instead checks that claimed memory +
>>> allocated memory don't exceed max_mem.
>>=20
>> Hm, while I don't have any specific interest in keeping the current
>> behavior, XENMEM_claim_pages is part of the stable ABI (it's not a
>> domctl), and hence should be stable.
>
> Is that true? It sits inside a
>
> #if defined(__XEN__) || defined(__XEN_TOOLS__)
>
> which generally de-marks unstable (tools-only) interfaces.
>
>>  Note also the comment above the
>> definition of XENMEM_claim_pages how it states the specific behavior
>> that you are trying to change (and which should have been adjusted as
>> part of this change).
>
> This is the more important part, imo.

Ugh. I missed that. Regardless, the current scheme is highly counterintuiti=
ve
and works only because toolstack colaborates in removing the claim after do=
m
creation.

>
>> I have no idea why this was made a xenmem rather than a domctl
>> hypercall, but if you want to change the semantics I think the only
>> option is introducing a new hypercall.
>
> It _is_ a memory operation, and it re-uses one of the interface structs
> there. (Yes, none of these would technically have prevented it from
> being a domctl.)
>
> Jan

As Jan mentions, my understanding was that __XEN_TOOLS__ effectively meant
unstable. It is quite hard to keep the previous semantics for one hypercall
while introducing a new one that behaves slightly differently.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 18:02:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 18:02:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011173.1389522 (Exim 4.92)
	(envelope-from )
	id 1uP3JB-0004WE-U4; Tue, 10 Jun 2025 18:02:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011173.1389522; Tue, 10 Jun 2025 18: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 1uP3JB-0004W7-R6; Tue, 10 Jun 2025 18:02:49 +0000
Received: by outflank-mailman (input) for mailman id 1011173;
 Tue, 10 Jun 2025 18:02: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 1uP3JA-0004Vu-3R
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 18:02:49 +0000
Received: from mail-24418.protonmail.ch (mail-24418.protonmail.ch
 [109.224.244.18]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1c5d5569-4625-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 20:02:45 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1c5d5569-4625-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1749578564; x=1749837764;
	bh=lP+1boryBoTrLDczj08ya9tFiHtdDJnTdW/1WXfteec=;
	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=aTnuZsMN5DwoevPTDf+oazaturUYG16D3m6M8FhyZWq8x6H73jDbqxya8QMt5sVAE
	 DTypxXz9L09rvMMd2uFKxTgPsYq76I45wbBP9rqIYDxTOfUha64xDK70wjSs1mkVlU
	 jys6RAs0rWkglGGPcHAvh6RxfBFPvzSPhxMSuTSc4DLcSFXAkpYxh2wgsdJDf3JC77
	 Ptjq9/ttyEg+89Dr7178e6GzFew9AFFJGIpGQUMJ7t2yD6HAOc3f5t+pirDD7CGXpQ
	 00Yg1akQMNSbX3NY4srcjxFwgeuybqPUGBqpEZUe2iNZypmZU7hFmKG/ZlQBAmZjag
	 EfTN8lHhL9OBw==
Date: Tue, 10 Jun 2025 18:02:38 +0000
To: Andrew Cooper 
From: dmkhn@proton.me
Cc: Jan Beulich , anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v1] xen/console: group pbuf under console field
Message-ID: 
In-Reply-To: <7f965335-68d9-4da5-8ce3-db68583db9a2@citrix.com>
References: <20250606194937.2412579-1-dmukhin@ford.com>  <7f965335-68d9-4da5-8ce3-db68583db9a2@citrix.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 4cd813df7ea11700607002f6fb653d55a637d142
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 10, 2025 at 12:24:57PM +0100, Andrew Cooper wrote:
> On 10/06/2025 9:10 am, Jan Beulich wrote:
> > On 06.06.2025 21:49, dmkhn@proton.me wrote:
> >> From: Denis Mukhin 
> >>
> >> Group all pbuf-related data structures under domain's console field.
> > Fine with me in principle, as I was indeed wondering about the lack of
> > grouping when the sub-struct was introduced, but ...
> >
> >> @@ -654,6 +648,12 @@ struct domain
> >>
> >>      /* Console settings. */
> >>      struct {
> >> +        /* hvm_print_line() and guest_console_write() logging. */
> >> +#define DOMAIN_PBUF_SIZE 200
> >> +        char *pbuf;
> >> +        unsigned int pbuf_idx;
> >> +        spinlock_t pbuf_lock;
> >> +
> >>          /* Permission to take ownership of the physical console input=
. */
> >>          bool input_allowed;
> >>      } console;
> > ... since all uses of the fields need touching anyway, can we perhaps
> > think of giving the fields better names? I never understood what the
> > 'p' in "pbuf" actually stands for, for example.
>=20
> I always assumed it was Hungarian notation, so pointer.
>=20
> As it's namespaced within .console, plain .buf, .idx and .lock names
> work fine.

Ack.

>=20
> Separately, 200 is a silly and arbitrary number.=C2=A0 Furthermore the
> allocation is unconditional, despite the fact that in !VERSBOSE builds,
> domUs can't use this facility.=C2=A0 Also, where's the input buffer?

Thanks!

I will try to address those under individual changes.

re: arbitrary number: Will bumping the buffer size to the next power of 2 =
=3D=3D
256 work?

re: input buffer: Looks like there's only global serial_rx_ring buffer in
current design. My guess - because the input buffer is shared between domai=
ns
and Xen itself which does not have domain struct associated with it.

>=20
> ~Andrew



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 18:34:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 18:34:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011180.1389532 (Exim 4.92)
	(envelope-from )
	id 1uP3nM-0008Sc-6g; Tue, 10 Jun 2025 18:34:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011180.1389532; Tue, 10 Jun 2025 18: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 1uP3nM-0008SV-3q; Tue, 10 Jun 2025 18:34:00 +0000
Received: by outflank-mailman (input) for mailman id 1011180;
 Tue, 10 Jun 2025 18:33: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 1uP3nL-0008SP-1y
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 18:33:59 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6fd347e9-4629-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 20:33:44 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 7B65843D97;
 Tue, 10 Jun 2025 18:33:42 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id AD7D5C4CEED;
 Tue, 10 Jun 2025 18:33: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: 6fd347e9-4629-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749580422;
	bh=30bUi8BTLYMK6oisVqutcdFvyKwuRF3/QjLiEWd2rOw=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=rbik4ygArXqhsIoUnWJhYl8rsFE5H1Q4eLGBjcUgFMRs3BNrhAq9V693jNOzRNCSm
	 cVK5TQh/ZdArYyxAtFvk6ES9J9Wv0KHc0xnFXg3h0LzsivmUg3DtGbnG3gT+0qFcdP
	 qBycGro4K1cere2bhkxPyV53NC552tuEqaMrfsM4JuWaZh7GJz3OoAQixdIv20yWPQ
	 0mbSC3MOyJtjefgNmdCGf7zUJFVK/NsFMiCA4saaie3lnNQcpbNisau5Zlf4e6iFG5
	 WGpHrh+6A2wgsFHQD3G2My7wCLVsbIs49wrJtzD9iOtuewLk23xjb+ql4Su4zaktr9
	 xddfNWw3B5ajw==
Date: Tue, 10 Jun 2025 11:33:39 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Julien Grall 
cc: dmkhn@proton.me, Jan Beulich , 
    andrew.cooper3@citrix.com, anthony.perard@vates.tech, roger.pau@citrix.com, 
    sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com, 
    xen-devel@lists.xenproject.org, jason.andryuk@amd.com
Subject: Re: [PATCH v9 2/3] xen/domain: adjust domain ID allocation for Arm
In-Reply-To: <61e2ae99-041b-4c8c-81bb-c86b5cee936e@xen.org>
Message-ID: 
References: <20250528225030.2652166-1-dmukhin@ford.com> <20250528225030.2652166-3-dmukhin@ford.com> <63087c42-d709-4e53-a2c3-8b812f13190a@xen.org>  <30c01c78-5a5e-435f-9b1c-faca3af04a76@suse.com> 
 <11ea9475-d963-473d-a85b-d1c461e7b213@suse.com>  <61e2ae99-041b-4c8c-81bb-c86b5cee936e@xen.org>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

+Jason

On Tue, 10 Jun 2025, Julien Grall wrote:
> But even if we are ok to break compatibility, I don't see the value of
> "control_domid". The implication of setting "hardware_domid" is you will
> have a separate control domain. At which point, why would it matter to specify
> the domain ID?
 
I just wanted to say that while we (AMD) are looking for a hardware
domain / control domain separation for safety reasons, I don't think we
have a need to specify the domid for either one.

Jason, is that correct?


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 21:38:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 21:38:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011191.1389542 (Exim 4.92)
	(envelope-from )
	id 1uP6fE-0003Sh-NJ; Tue, 10 Jun 2025 21:37:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011191.1389542; Tue, 10 Jun 2025 21:37:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uP6fE-0003SZ-I6; Tue, 10 Jun 2025 21:37:48 +0000
Received: by outflank-mailman (input) for mailman id 1011191;
 Tue, 10 Jun 2025 21:37: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 1uP6fC-0003SO-LA
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 21:37:46 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on2060f.outbound.protection.outlook.com
 [2a01:111:f403:2407::60f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2189f0f9-4643-11f0-b894-0df219b8e170;
 Tue, 10 Jun 2025 23:37:39 +0200 (CEST)
Received: from SJ0PR13CA0234.namprd13.prod.outlook.com (2603:10b6:a03:2c1::29)
 by CY8PR12MB7338.namprd12.prod.outlook.com (2603:10b6:930:52::8) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.27; Tue, 10 Jun
 2025 21:37:36 +0000
Received: from SJ1PEPF00002322.namprd03.prod.outlook.com
 (2603:10b6:a03:2c1:cafe::3b) by SJ0PR13CA0234.outlook.office365.com
 (2603:10b6:a03:2c1::29) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.17 via Frontend Transport; Tue,
 10 Jun 2025 21:37:36 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ1PEPF00002322.mail.protection.outlook.com (10.167.242.84) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Tue, 10 Jun 2025 21:37:36 +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 Jun
 2025 16:37:35 -0500
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 Jun
 2025 16:37:35 -0500
Received: from [172.27.195.250] (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 Jun 2025 16:37:34 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2189f0f9-4643-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=tb9+zvPpFu5+rycppCogNgojcL6xAF5ZcWkj/oV20wKfBpdr3HJvCEKHs+vS8FApW/YO0Xzv4haGQ9n1NZDA7zphI++KwmNgamRNzV2zl8na/UsrbkwR90hy/A88fOFiSUOg5LQDwFqdVVjkjdIg9SS18Hw/Xj45ld0WoAQY8BlQPPNd+4ok2FS7cj07vdb/vbvb0tRFaT2UTm4L4+Dz9rLdWWIIIRkayZGqSIJrKeCY5Ywrp2E651VqRM4lfdUOb5pi8dZDRWoMfZ/mBSwLXNnZEOIMqXlVebL6cyPyHGcsam2rulhIHhpEv1jLzdWRQvrfK0NpAYL8Xmx7Zbpt7A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=PbxqrnsIriBEvdh9Ma7uJzXr4foBWFsra8GT+/tNARQ=;
 b=vLIpQG5lVLdMO0lhKuS+xa3N7yQ5CHZCQazWJv9+/QTwzTPE3wy+7/t3t1Tg8VkXFZuik0nXaoTXUTH6BRgLIzFV+qtDh1jhoIMEY/g/xGNBdRdG9c1pGBIUN4s/p7QY4r9kDOqnkhAuHwDxWcfKd1qW87EZJQkCB+4uREg5LvI0yqRzBD0Vv76IlFzRNLjqAY51E/+xDCFw0FgDsaHzVyl1dJhIwEL4Ro0VAagtVESNDJU2Qkr3GOziU3R9J4Fw4cyNroNbTzq1C2XECNbqzMhxv5Y4ucpM2XXmWkSMzIhX6pBjuHOule/ohpThR75VRC5R/LD4e1GGXuMwfFmE6A==
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=PbxqrnsIriBEvdh9Ma7uJzXr4foBWFsra8GT+/tNARQ=;
 b=wV4TfZL2dSvxVlBVs5Mz/WGggi4c+VTDqPFx97W979WGC4awM5fXt+j0XJOIuQTSO4BNV/d/BJrdZo2JHthZpZSm/s4tJ48Mc+q7j3eYqtodSuqsiEYFXrpJRypkCiNq6VYBxz1xvBjRjA/kO0Wc9qzSZSq4/ZB9OD/vpkZ1xpk=
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 Jun 2025 17:37:33 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 2/3] xen/domain: adjust domain ID allocation for Arm
To: Stefano Stabellini , Julien Grall 
CC: , Jan Beulich ,
	, ,
	, , ,
	
References: <20250528225030.2652166-1-dmukhin@ford.com>
 <20250528225030.2652166-3-dmukhin@ford.com>
 <63087c42-d709-4e53-a2c3-8b812f13190a@xen.org>
 
 <30c01c78-5a5e-435f-9b1c-faca3af04a76@suse.com> 
 <11ea9475-d963-473d-a85b-d1c461e7b213@suse.com> 
 <61e2ae99-041b-4c8c-81bb-c86b5cee936e@xen.org>
 
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF00002322:EE_|CY8PR12MB7338:EE_
X-MS-Office365-Filtering-Correlation-Id: 791c3f28-4787-4b21-d3a4-08dda8670447
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|7416014|376014|36860700013|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?QW84MWR4R2xFcXlYaWZhSHBmdndKcUxGdWlUS3ZNWkQ4SzRZOVRMMFhsV1Bx?=
 =?utf-8?B?a3hXNWcxVEkrY3piMFB5eU9RVmZQNzlLVmtrN1lOWmZkRVY3enZyeVZBSW40?=
 =?utf-8?B?aXNhSUwvZEtkbXVlaE5vTE5NTmVvNWJRVEJhNkZqN1dQck1xRFZ6RU5NeDZN?=
 =?utf-8?B?NWN4UFdBbC9nUW9iajlLYVZFeVFOWVN4b0FwR2JmL0h3SkpkcXAwNDF1K2pu?=
 =?utf-8?B?WUpqeUd2QlRld2pjSi9keHE4MFFqRHdvcVNXQytWODVyZUpRaWpCMCtSck1j?=
 =?utf-8?B?cWFGcWdlaWZQOFlBMFFPRzVsUmFYRHRiU2JWaFgzeW10NFBoN2dYUHJNTTNu?=
 =?utf-8?B?eVNqUVkzeW4veW9aQ1ZySUdBQUgyR3JGUkp2b1pzdWM3QlRweW8xbVJLTkNi?=
 =?utf-8?B?K2RrSXlmOG9CMEMzM1ZiR1FFVDBJNnduME5HaUN4ckFYSmt2c0xHODZEK3Ur?=
 =?utf-8?B?ZkVBNEdOOVp5MXFQWnhDVTRreTRIMDg2TzNLOFZCOGZmMWpFZS9aYTVzOFFa?=
 =?utf-8?B?ampzZWtqWXdrak5BOXZBNTdaNzhXc3JBMnU2S2cza3c3MktNR3NIV2lGSFM0?=
 =?utf-8?B?WVdPUmYyOUxHeDcxTHBqaWtab2J3VE1seVFxOXljTExndi9PdUJpNVl0KytR?=
 =?utf-8?B?TGZuMFdEU1ZsM3J0cXJjaGw4VGxoakdlaUsxZ2JsNlUyVnF0eEwzb0VNU25y?=
 =?utf-8?B?ZFd6VUtuNGNQdWMvTUp3bFl5SkFMY3JOYVZTTWZJME9NU2JZNTJsOXM4Z0ZX?=
 =?utf-8?B?bk45bnUwNm1uMkhoM1VEVDdodE9XenZ1OTJiUXJteVhibitoNzIyd2FZT2JC?=
 =?utf-8?B?WTJJdjVlT0k1RzZ1cGZZOGsrNnFQb2Nuc0ZxblJHWXZKaUFYSS9JQjNGbUxv?=
 =?utf-8?B?ZExVQWdLOEZ1ajhEL1Bta3Erem5EdFB6UVdKRDlTQURCd2ZPRllxS0U4c1Bh?=
 =?utf-8?B?TDBIV3pYcXRBc0JWZFk1UGlKdU1zalRybjRCeGQxejlFelNJaTl4RUFVaHZI?=
 =?utf-8?B?RGRqMG5qWHhjQVkxMmdwcGtyQjFhbE03blppNVRvbFJ4dFMzUzJOZENXYjNH?=
 =?utf-8?B?aWNncklQOXZkbVNteHR5NG9KUmQyd29xZ20rSlpNenJsVkFFbUR1SDVJOTd0?=
 =?utf-8?B?NDNFRkkvdGFUcVliS1JqSUdkeDZKWU1oa3R6ZXkwL2FFTHp5MTNCcDlNTzBP?=
 =?utf-8?B?Tkc3dGdkaUFtNEVHQUVmaVJhem8vNnNqU1NuYkRqK25qL3BiSlNlQUExMFNO?=
 =?utf-8?B?WlZoeXdnZmpLTWZ1SUo3eUpsUjJXaVF0K05zdmZUNmdna0JlaTBTbmU5T0RH?=
 =?utf-8?B?ZUJwRG9wRGxOcEVTa1dVdWlIWWVnYTBLdHFsZzVQd0dZT1ZDTHMzS2VsZ0xL?=
 =?utf-8?B?aTl2UDF5clRtaTRBYnVRQ2ZuWDErdncrMVI3TFRZM3RXK0cySC9hbTkzai85?=
 =?utf-8?B?VHM5S3VoSFpmK1YwL1BiWjNza1RZVXQzUkFKMXIvN2xISFM3a3Z1TlFURnE2?=
 =?utf-8?B?ZVhQODR3ZnFTTmhQMW1IYW5Ub0FTeFdyM085OG9RSjZoY09nN3ltTUd6TnVC?=
 =?utf-8?B?R0JyNWpZZnRzUWluNDBDRDRwSjFkYzF6dFlGOUtoMXFkVGZxUFFIOUxLeE0x?=
 =?utf-8?B?eHJPc3JNMnJUa3ljcnJKaUhtL20vN3NGRXRaaVVxOWEzZkIzN3RuZTVNVEdX?=
 =?utf-8?B?RTVHMEdjcjJ2b2ZhMXA1Qmw2TVViMzFrTWhsLzQzbjFtSjFSaVdkOFdVVzJE?=
 =?utf-8?B?cmV0dFRYODZ4ZXRnZ2MrTUxMY0llWkxzdWtsZ0JDTkNFVHZvRVVtY05yajNX?=
 =?utf-8?B?dG9nTXViQ283aTVKV0EvVVUwelVyYXlLWlk4dWQ5WnZiQ29jaDVnd3B3R0Nx?=
 =?utf-8?B?WnpybUF4eStxbmdOcHU5NTN4ajI4ZXJlNnh3c3hLVGVCbDk2UngyNTVvY3Uz?=
 =?utf-8?B?WklKZW1TQ1E3Qk9PdzdNYzlBQ0xLNzdpY3ZLU1AwQ1g2dlZHUEc2Tmg2VlJR?=
 =?utf-8?B?V1hQUS9MK1dqTXV1VEhpTk1xSFpGQ2ZqMmR4K2JJanFTWndoVVl2aVpvcGpx?=
 =?utf-8?Q?pTt3oP?=
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)(36860700013)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jun 2025 21:37:36.1979
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 791c3f28-4787-4b21-d3a4-08dda8670447
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:
	SJ1PEPF00002322.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7338

On 2025-06-10 14:33, Stefano Stabellini wrote:
> +Jason
> 
> On Tue, 10 Jun 2025, Julien Grall wrote:
>> But even if we are ok to break compatibility, I don't see the value of
>> "control_domid". The implication of setting "hardware_domid" is you will
>> have a separate control domain. At which point, why would it matter to specify
>> the domain ID?
>   
> I just wanted to say that while we (AMD) are looking for a hardware
> domain / control domain separation for safety reasons, I don't think we
> have a need to specify the domid for either one.

Specifying domids isn't really necessary, but it can be convenience or 
usability improvement with dom0less/Hyperlaunch.  But I don't think 
control_domid is necessary.

hardware_domid is not used for dom0less/Hyperlaunch with split control 
and hardware domains.  The "capabilities" device tree (DT) property 
specifies the role of the domain.

Hyperlaunch lets you specify a domid in the DT - there is some 
auto-allocation logic, but I haven't use it.  dom0less doesn't allow 
specifying a domid today, but it could.  dom0less domains are assigned 
domids sequentially, so you can determine it from the order in the DT.

Knowing the domids can be helpful for configuring userspace, and that 
only really matters for dom0less/Hyperlaunch.  e.g. xenstored wants to 
know which domid is control.

I think it's nice to have a domid property so that you know when 
configuring the system which domain is which.  You can explicitly read 
the domid out of the DT and know what it is.  Since dom0 userspace needs 
to refer to domids, this make it clear which domain is which for, as an 
example, connecting disks.

hardware_domid= is the way of enabling later hardware domain 
functionality.  dom0 boots as dom0.  When it creates domid == 
hardware_domid, that new domain becomes the hardware domain, and dom0 
loses hwdom and becomes just the control domain.  It's a legacy feature 
and was a workaround for when Xen could only create a single domain at boot.

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Tue Jun 10 23:43:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 23:43:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011206.1389551 (Exim 4.92)
	(envelope-from )
	id 1uP8cJ-0001C7-7n; Tue, 10 Jun 2025 23:42:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011206.1389551; Tue, 10 Jun 2025 23:42: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 1uP8cJ-0001C0-4v; Tue, 10 Jun 2025 23:42:55 +0000
Received: by outflank-mailman (input) for mailman id 1011206;
 Tue, 10 Jun 2025 23:42: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 1uP8cG-0001Bu-RC
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 23:42:54 +0000
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9c5ce0f6-4654-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 01:42:46 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9c5ce0f6-4654-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1749598965; x=1749858165;
	bh=FgKuZlenHMnzOx11+ti1TH7kOvkx0Yq6nS3Mop/uTv4=;
	h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
	 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector:
	 List-Unsubscribe:List-Unsubscribe-Post;
	b=IkhpadCpB/3enhogzOOgWd9PPaEBjJ5Tcs16eG5msMUVlRreC/BpwMpkRkcQKZWOd
	 YuhQoX91MAwrNPpczZpiN0KAEAy6frzo4w9JF5IAgGzGxBaW8gwCG2RH0MmSftWy+4
	 wf7PUinJ0YY/8S22uV0tju+jL1Vcj2zRo87JhDaqJpiOnz2ZLsEa5wE8dbXCBThnV2
	 KWr45TGvy3L2g9JcWuq3KnQDoke/m4DNJ5hxlQ0ToJxYg1/ZN584qbyhP/McwpqosK
	 WfHn05IAMtXebi8t7wNaRVGa2zRO+E1sVKTbbgsPzE3o7HclULmg3y/5vAKDlCrdpF
	 EMWyAiAxuAoOQ==
Date: Tue, 10 Jun 2025 23:42:37 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH] xen/domain: fix late hwdom feature
Message-ID: <20250610234105.1082890-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: cb581d934730d99f39136349cdea041bbbc93e00
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Fix get_initial_domain_id() which how returns hardware_domid and breaks lat=
e
hwdom feature [1].

[1] https://lore.kernel.org/xen-devel/a4c860d7-1fa0-43f4-8ae1-af59b7c6506f@=
xen.org/

Fixes: f147ccf2 ("xen/consoled: clean up console handling for PV shim")
Signed-off-by: Denis Mukhin 
---
 xen/common/domain.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 153cd75340..e566a18747 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -2404,7 +2404,7 @@ domid_t get_initial_domain_id(void)
     if ( pv_shim )
         return pv_shim_get_initial_domain_id();
 #endif
-    return hardware_domid;
+    return 0;
 }
=20
 void freeze_domains(void)
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Tue Jun 10 23:47:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 23:47:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011212.1389563 (Exim 4.92)
	(envelope-from )
	id 1uP8gv-0001kw-Ph; Tue, 10 Jun 2025 23:47:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011212.1389563; Tue, 10 Jun 2025 23:47:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uP8gv-0001kp-LG; Tue, 10 Jun 2025 23:47:41 +0000
Received: by outflank-mailman (input) for mailman id 1011212;
 Tue, 10 Jun 2025 23:47: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 1uP8gu-0001kj-TS
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 23:47:40 +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 4a9cba35-4655-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 01:47:38 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4a9cba35-4655-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1749599258; x=1749858458;
	bh=Jnoru+0NdFyzc26qHA6MrPvOFCqa1RKSJbFWI5l/B1k=;
	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=iGPjm2Nu0JeNsZMZBuIQo7WjTn+IxGWCuwQEgfWp4PZM2R+gTVVjJj/A6dMKODSaL
	 VFUam0OwZ1Q1QWDhjK65P0rGnanaROfJpfw4k3wtdIK4F+ijjVEFfhyF/o/H/8mrmW
	 CmJvcTRiFi3rzBHZKEQeadqQpvjyxMQ9zZtzF3LiLhLrWyDyatphGp1X1jZVo2jfhG
	 YbegwJ1EvnUearxJqcwvgbkw2jJmCkapPnLa6oSNk/80/75xmeQb0BgAAadunHIhYv
	 l3/Q/7EjwSwPfQKZYdzGu5FFd+fTkidYXhAJqS4hlMhCl24nwJO1F05pnuuaqE+n/9
	 UHbWjh3y7sBoQ==
Date: Tue, 10 Jun 2025 23:47:33 +0000
To: Julien Grall 
From: dmkhn@proton.me
Cc: Jan Beulich , andrew.cooper3@citrix.com, anthony.perard@vates.tech, roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v9 2/3] xen/domain: adjust domain ID allocation for Arm
Message-ID: 
In-Reply-To: <61e2ae99-041b-4c8c-81bb-c86b5cee936e@xen.org>
References: <20250528225030.2652166-1-dmukhin@ford.com> <20250528225030.2652166-3-dmukhin@ford.com> <63087c42-d709-4e53-a2c3-8b812f13190a@xen.org>  <30c01c78-5a5e-435f-9b1c-faca3af04a76@suse.com>  <11ea9475-d963-473d-a85b-d1c461e7b213@suse.com>  <61e2ae99-041b-4c8c-81bb-c86b5cee936e@xen.org>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 696d34da7c1bd6e31aced50a61f9aadb69ace82b
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 10, 2025 at 10:44:39AM +0100, Julien Grall wrote:
> Hi Denis,
>=20
> On 10/06/2025 10:04, dmkhn@proton.me wrote:
> > On Tue, Jun 10, 2025 at 10:26:22AM +0200, Jan Beulich wrote:
> >> On 10.06.2025 10:02, dmkhn@proton.me wrote:
> >>> On Tue, Jun 10, 2025 at 08:53:12AM +0200, Jan Beulich wrote:
> >>>> On 06.06.2025 23:29, Julien Grall wrote:
> >>>>> Hi Denis,
> >>>>>
> >>>>> On 05/06/2025 23:05, Julien Grall wrote:
> >>>>>> Hi Denis,
> >>>>>>
> >>>>>> On 28/05/2025 23:50, dmkhn@proton.me wrote:
> >>>>>>> From: Denis Mukhin 
> >>>>>>>
> >>>>>>> From: Denis Mukhin 
> >>>>>>>
> >>>>>>> Remove the hardcoded domain ID 0 allocation for hardware domain a=
nd replace it
> >>>>>>> with a call to get_initial_domain_id() (returns the value of hard=
ware_domid on
> >>>>>>> Arm).
> >>>>>>
> >>>>>> I am not entirely why this is done. Are you intending to pass a di=
fferent domain ID? If so...
> >>>>>>
> >>>>>>>
> >>>>>>> Update domid_alloc(DOMID_INVALID) case to ensure that get_initial=
_domain_id()
> >>>>>>> ID is skipped during domain ID allocation to cover domU case in d=
om0less
> >>>>>>> configuration. That also fixes a potential issue with re-using ID=
#0 for domUs
> >>>>>>> when get_initial_domain_id() returns non-zero.
> >>>>>>>
> >>>>>>> Signed-off-by: Denis Mukhin 
> >>>>>>> ---
> >>>>>>> Changes since v8:
> >>>>>>> - rebased
> >>>>>>> ---
> >>>>>>>  =C2=A0 xen/arch/arm/domain_build.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | 4 ++--
> >>>>>>>  =C2=A0 xen/common/device-tree/dom0less-build.c | 9 +++------
> >>>>>>>  =C2=A0 xen/common/domain.c=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 | 4 ++--
> >>>>>>>  =C2=A0 3 files changed, 7 insertions(+), 10 deletions(-)
> >>>>>>>
> >>>>>>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_bu=
ild.c
> >>>>>>> index e9d563c269..0ad80b020a 100644
> >>>>>>> --- a/xen/arch/arm/domain_build.c
> >>>>>>> +++ b/xen/arch/arm/domain_build.c
> >>>>>>> @@ -2035,9 +2035,9 @@ void __init create_dom0(void)
> >>>>>>
> >>>>>> ... naming like create_dom0() probably wants to be renamed.
> >>>>>>
> >>>>>> That said, I am not convinced a domain other than 0 should have fu=
ll privilege by default. So I would argue it should stay as ...
> >>>>>>
> >>>>>>>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if ( !llc_coloring_enabled )
> >>>>>>>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 flags |=
=3D CDF_directmap;
> >>>>>>> -=C2=A0=C2=A0=C2=A0 domid =3D domid_alloc(0);
> >>>>>>> +=C2=A0=C2=A0=C2=A0 domid =3D domid_alloc(get_initial_domain_id()=
);
> >>>>>>
> >>>>>> ... 0.
> >>>>>
> >>>>> Looking at the implementation of get_initial_domain_id(), I noticed=
 the behavior was changed for x86 by [1].
> >>>>>
> >>>>> Before, get_initial_domain_id() was returning 0 except for the PV s=
him.
> >>>>> But now, it would could return the domain ID specified on the comma=
nd line (via hardware_dom).
> >>>>>
> >>>>>  From my understanding, the goal of the command line was to create =
the hardware domain *after* boot. So initially we create dom0 and then init=
ialize the hardware domain. With the patch below, this has changed.
> >>>>>
> >>>>> However, from the commit message, I don't understand why. It seems =
like we broke late hwdom?
> >>>>>
> >>>>> For instance, late_hwdom_init() has the following assert:
> >>>>>
> >>>>>  =C2=A0=C2=A0=C2=A0 dom0 =3D rcu_lock_domain_by_id(0);
> >>>>>  =C2=A0=C2=A0=C2=A0 ASSERT(dom0 !=3D NULL);
> >>>>>
> >>>>> Jan, I saw you were involved in the review of the series. Any idea =
why this was changed?
> >>>>
> >>>> I simply overlooked this aspect when looking at the change. You're r=
ight, things
> >>>> were broken there. Unless a simple and clean fix can be made relativ=
ely soon, I
> >>>> think this simply needs reverting (which may mean to revert any late=
r commits
> >>>> that depend on that). I can't help noting that in this console rewor=
k there were
> >>>> way too many issues, and I fear more than just this one may have sli=
pped
> >>>> through. I therefore wonder whether taken as a whole this was/is wor=
th both the
> >>>> submitter's and all the reviewers' time.
> >>>
> >>> Yes, sorry, I overlooked late_hwdom_init() modification.
> >>>
> >>> IMO, the clean fix would be adding another command line parameter
> >>> `control_domid` (with default value 0), make get_initial_domain_id() =
return it
> >>> instead of current `hardware_domid` and update late_hwdom_init() to u=
se
> >>> `control_domid` insted of open-coded 0.
> >>
> >> No, no new command line option will address this. Original behavior ne=
eds to be
> >> restored (either by correcting the earlier change or, as said, be reve=
rting).
> >
> > Correction of the earlier change:
> >
> >    https://gitlab.com/xen-project/people/dmukhin/xen/-/commit/b7f194650=
307a08a9e6da5aa9fdd1f8a9afd67eb
> >
> > re: command line option: I meant something like this:
> >
> >    https://gitlab.com/xen-project/people/dmukhin/xen/-/commit/51a519de6=
ea73ff3b650fd9bd4f3c5c63f64c069
>=20
> I am with Jan here. This used to work before without "control_domid", so
> we ought to keep the same.

OK, thanks for the feedback!
I will post the correction of the earlier change.

>=20
> But even if we are ok to break compatibility, I don't see the value of
> "control_domid". The implication of setting "hardware_domid" is you will
> have a separate control domain. At which point, why would it matter to
> specify the domain ID?

I thought there's a plan to use symbols in the ongoing hyperlauch reworks, =
but
as later Jason explains, this is not the case.

>=20
> Cheers,
>=20
> --
> Julien Grall
>=20



From xen-devel-bounces@lists.xenproject.org Tue Jun 10 23:48:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jun 2025 23:48:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011218.1389571 (Exim 4.92)
	(envelope-from )
	id 1uP8i2-0002Ft-1L; Tue, 10 Jun 2025 23:48:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011218.1389571; Tue, 10 Jun 2025 23:48:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uP8i1-0002Fm-VA; Tue, 10 Jun 2025 23:48:49 +0000
Received: by outflank-mailman (input) for mailman id 1011218;
 Tue, 10 Jun 2025 23:48: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 1uP8i1-0002Fg-6m
 for xen-devel@lists.xenproject.org; Tue, 10 Jun 2025 23:48:49 +0000
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7403858f-4655-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 01:48:48 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7403858f-4655-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1749599327; x=1749858527;
	bh=YZ+LEwyLbV55jtjFAJs+03TxX67SrG1sxnUP20Rj4Nc=;
	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=X8PSTF3xtiFw3MUGaBtKl6CMmVA4s/EJsaQUYOLe02z5I02qdUIt4RjB/wyjMHDkR
	 ve8cV9VlQWQ3esunaazustV7kvhOH9vd/jnB3ORD8CaqnRdf8pc6E8C/eYb04n+l2T
	 LFSJsIpH8TCC5SwwdEO82i0csn0MHAM3KY43kCogOouLiWpBrLXkNY/lisw4aaq5kf
	 RCfVhBuIHehRgY+omOFTxRggPxChG/xsjYY5O4h9qgWf5f3KNv21kzdZkG2fyxGCIT
	 jmiPRGPWmwIQ9gMe4Jj6UGpPKX+nc6rk2mw6LmB4v/h1bWaYkyMWDszj2kc5alMo3P
	 jViCMwRjQ/6MQ==
Date: Tue, 10 Jun 2025 23:48:42 +0000
To: Jason Andryuk 
From: dmkhn@proton.me
Cc: Stefano Stabellini , Julien Grall , Jan Beulich , andrew.cooper3@citrix.com, anthony.perard@vates.tech, roger.pau@citrix.com, teddy.astie@vates.tech, dmukhin@ford.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v9 2/3] xen/domain: adjust domain ID allocation for Arm
Message-ID: 
In-Reply-To: 
References: <20250528225030.2652166-1-dmukhin@ford.com>  <30c01c78-5a5e-435f-9b1c-faca3af04a76@suse.com>  <11ea9475-d963-473d-a85b-d1c461e7b213@suse.com>  <61e2ae99-041b-4c8c-81bb-c86b5cee936e@xen.org>  
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 9e7bc00ded14564182d99735f9f60a191ecc300f
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 10, 2025 at 05:37:33PM -0400, Jason Andryuk wrote:
> On 2025-06-10 14:33, Stefano Stabellini wrote:
> > +Jason
> >
> > On Tue, 10 Jun 2025, Julien Grall wrote:
> >> But even if we are ok to break compatibility, I don't see the value of
> >> "control_domid". The implication of setting "hardware_domid" is you wi=
ll
> >> have a separate control domain. At which point, why would it matter to=
 specify
> >> the domain ID?
> >
> > I just wanted to say that while we (AMD) are looking for a hardware
> > domain / control domain separation for safety reasons, I don't think we
> > have a need to specify the domid for either one.
>=20
> Specifying domids isn't really necessary, but it can be convenience or
> usability improvement with dom0less/Hyperlaunch.  But I don't think
> control_domid is necessary.
>=20
> hardware_domid is not used for dom0less/Hyperlaunch with split control
> and hardware domains.  The "capabilities" device tree (DT) property
> specifies the role of the domain.
>=20
> Hyperlaunch lets you specify a domid in the DT - there is some
> auto-allocation logic, but I haven't use it.  dom0less doesn't allow
> specifying a domid today, but it could.  dom0less domains are assigned
> domids sequentially, so you can determine it from the order in the DT.
>=20
> Knowing the domids can be helpful for configuring userspace, and that
> only really matters for dom0less/Hyperlaunch.  e.g. xenstored wants to
> know which domid is control.
>=20
> I think it's nice to have a domid property so that you know when
> configuring the system which domain is which.  You can explicitly read
> the domid out of the DT and know what it is.  Since dom0 userspace needs
> to refer to domids, this make it clear which domain is which for, as an
> example, connecting disks.
>=20
> hardware_domid=3D is the way of enabling later hardware domain
> functionality.  dom0 boots as dom0.  When it creates domid =3D=3D
> hardware_domid, that new domain becomes the hardware domain, and dom0
> loses hwdom and becomes just the control domain.  It's a legacy feature
> and was a workaround for when Xen could only create a single domain at bo=
ot.

Thanks for explanation!

>=20
> Regards,
> Jason



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 00:00:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 00:00:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011224.1389582 (Exim 4.92)
	(envelope-from )
	id 1uP8tA-0005GN-Sw; Wed, 11 Jun 2025 00:00:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011224.1389582; Wed, 11 Jun 2025 00:00:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uP8tA-0005GG-Pa; Wed, 11 Jun 2025 00:00:20 +0000
Received: by outflank-mailman (input) for mailman id 1011224;
 Wed, 11 Jun 2025 00:00:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uP8t8-0005GA-S4
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 00:00:18 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on2062c.outbound.protection.outlook.com
 [2a01:111:f403:200a::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 05d0cf2b-4657-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 02:00:02 +0200 (CEST)
Received: from MW4PR03CA0182.namprd03.prod.outlook.com (2603:10b6:303:b8::7)
 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.8792.38; Tue, 10 Jun
 2025 23:59:56 +0000
Received: from SJ5PEPF000001ED.namprd05.prod.outlook.com
 (2603:10b6:303:b8:cafe::f6) by MW4PR03CA0182.outlook.office365.com
 (2603:10b6:303:b8::7) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Tue,
 10 Jun 2025 23:59:56 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SJ5PEPF000001ED.mail.protection.outlook.com (10.167.242.201) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Tue, 10 Jun 2025 23:59:55 +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 Jun
 2025 18:59:54 -0500
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 Jun 2025 18:59:53 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 05d0cf2b-4657-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=svPHFzqk/EIaCkn+0Vbp9RE4aEVkiAtvAdgkJ0RVAri3ApF/ZSi7LEYqt6OLwzvksrvzpM5LooGSC/ofxoGMaeFAdjAi1wkcXfxABGJDkqiGNXQpoGAaMa5oDcIBguKEOEiBsx65NaXW1mIeh/yT39K6JuN63BvAqp+FPWEZ7XR8LAqxzcrV7tssFQj/t1G54+vYsAO+2qh05I3MsOUGu0JBEuItmuiiiQ56Y/NRVb8B3iWC5Tb6sw7qZ1vAkD3Y7ayvpK/HDQoVh8R5jPtPQlfmmueLHL2OM1nfDHsdrsZAIxhKc25dLrryzE88Gik43Z/g+cAcYo6pjyOt0uBufg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=jiRXWsYs9NKbPz74XEwoJp5krkiymSCqlV5vnZ6/m7o=;
 b=uIK/+iv/ZtxRLYSTnMZ2arKZPRTIA8fkw8n82zmfgSTdTbSWGyHfwRo+EeiJrTkR7uCupx9C8Gxi6RThsh5pNSjIhlznF/uT5NjETiC4UyWBdx4tU+itSKM9axvEjvkhYjxgw6+oNLLiod4stbf8+t+Qo9yBopmMb3JuxioJeQkcpUKgN3FLosXRoKvMUQInLG1NgxE8Doe/vjSBtI76vvIbCd2ne52rieLwhCqMN3+VkIkg61v6MnVNsaGBfN0t8bQxz9UEujdqac7I+H7ps54Alpya6uNMNCAlfXuls6ie3nMuBKZ4O9bBUMvBG8AMOpCvwRhz0xMvUIccvdXcHQ==
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=jiRXWsYs9NKbPz74XEwoJp5krkiymSCqlV5vnZ6/m7o=;
 b=WsbBfIhLuvz58K4S9fobXKuqZSJr05XBeWQhYKZ0iFf8SPxvs7nDOmPWYZRsxjbxaXOIMeakE4/mMlpTHuh4HxQib7ybe/xG3oes3JdusPU21a9/enzdNZFBGNOILQk1yqfDAi5927bGrO0RVUEulRkcD/OPKHcoZnlJFEnST/4=
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 , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , Andrew Cooper
	, Anthony PERARD , "Jan
 Beulich" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, "Daniel P. Smith" ,
	Christian Lindig , David Scott 
Subject: [PATCH 0/4] XSM changes for split hardware / control domain
Date: Tue, 10 Jun 2025 18:57:33 -0400
Message-ID: <20250610225737.469690-1-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.49.0
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: SJ5PEPF000001ED:EE_|SA1PR12MB9247:EE_
X-MS-Office365-Filtering-Correlation-Id: 98ccdd92-7c49-4751-6ac2-08dda87ae622
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|7416014|376014|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?UIlqfeVp9thvH/sr+QBmoO+3TSz8SpJ1URwjt4ct9SQMRG1Z1RYD6K9FVVxD?=
 =?us-ascii?Q?qtzsxNmVdlAUBI85QBpK8q5amU+O6mn3q73WJIfW9idQ5vG1RfljY3eb0H2+?=
 =?us-ascii?Q?rXhxhYLoPdWrSFxFdzrhWKEo9uo32BR3DGRQVmQxbV1fa57Pb3Mo9/r8TA1S?=
 =?us-ascii?Q?bv4T86cg6GoWdXgZgauFj52vz/sKCwZPzkBF4EZIihIR8g1o33LUJfvs0mS7?=
 =?us-ascii?Q?4HkDPOhxzeDWp09ZD1+nylxduHP/TZN8srzbBE+x/YSONhhgT0EBo/AGNZjX?=
 =?us-ascii?Q?Elh0m58grOblp5NRrJfS5mq0MlSvnVFX7qwAH+8ltcyPBijkKCpq8ak9Nem0?=
 =?us-ascii?Q?HHdfXBNmmTR9Hjhg5NAiiA/n37tZKus+RInVLh4bR9gSVjgfA4xb7JMKHKSS?=
 =?us-ascii?Q?FnMTIdcrLmVk0Os9aP+pTebJuoGDtdtqFGXva+xlaHhdiCfWsC5Mr417Bsp1?=
 =?us-ascii?Q?EY0Iml5XIF5bzRolU6gq5NdmpLtP36RKFM4xGih38jmgzYB6dgROfDBaGODe?=
 =?us-ascii?Q?p7ORXXnfLOPtlNVT7CZQtWtIyMw3OjPlyNdv3TGQDUESOJ97xncu+4BceOqG?=
 =?us-ascii?Q?OQh2M1yufbLDIKyF4OADfBMJIFrejnWXIqQNCBhOU1LFdB0gocGIeMQo7ZQg?=
 =?us-ascii?Q?yDOrRetNdQX1kIMtmgwB9gfwdnW5Fb21zMy1K15opdeDiVfyg8NB5nAUgMko?=
 =?us-ascii?Q?cgRZAmmiOwuPvgw/wdSDLwchfzJ9ykvKN4EHhToQ0LJrZXnNl22KVAxd9BP5?=
 =?us-ascii?Q?QJ0Zsb0CX+O4a+w7ZlnrAffJTP+FoP/izDKh1v390x8OU8duWIoQtoWcmhlz?=
 =?us-ascii?Q?ZLSB5FKPP0JfipXUVuzxxHMC5YL4tKCZ0jMcowXpzOmzfoJom/n//SVqjAl+?=
 =?us-ascii?Q?69KAiDOBKSkqeksPOUiltSZEESwcGf+8SBQoPOXnimYbJhcwsE2UT7B5mPm0?=
 =?us-ascii?Q?QCvtRyB8xUgRpE2OvuGDrZrBxNIZYibxgQ8sjixHTzc2axxJZxV6DJLXbd99?=
 =?us-ascii?Q?qzPKRnDTbBPKFihFDZVBjJcWEzRYgsfoR36A5CmfgXiM7uYqsbrZ0reR5QKB?=
 =?us-ascii?Q?Vwi6dRa+EDnFFTaqPFoGn2ae0zYbInXc2wPitxuxaDx/godDqq5klDjjF8F0?=
 =?us-ascii?Q?ON6bgVY1Y/l17APONXaJIrbAXIjp6/ffMrAK0vjLB9ZuEVKY7XqprhaJvGAa?=
 =?us-ascii?Q?1t33h8F3XuU4/whHhtAZXz5k90hkPE/mlQ38P2dwb+P9KCNH8RbxR+bKuR5C?=
 =?us-ascii?Q?hcXKEjJLHFGGruUL6B1hpafVNDO9ZhV2yTB/Jj1NOtSul2Y5ImRLQ5Pp5hVd?=
 =?us-ascii?Q?PX2X/Y65KX3uAG5Gj36p08/hgv/Z7vcCBmaUcysBFIqMOzcHfZgpufris5AA?=
 =?us-ascii?Q?trz6TnLhbgwPyRs3HN8Xa9XuozAGZZU5uyUcRraU2FJYqejRUAk1tuutCUlj?=
 =?us-ascii?Q?TM8WtiQsFoLj5N8jqbnTm/X0ih80lVV0NztAydLU83ex6Xy0n9Tl8SJPzNCV?=
 =?us-ascii?Q?INwH+diupkkDkyfxhFtpMQgWBm/yg9MrtPFe?=
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)(82310400026)(7416014)(376014)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jun 2025 23:59:55.5709
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 98ccdd92-7c49-4751-6ac2-08dda87ae622
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:
	SJ5PEPF000001ED.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB9247

Theses are the broad changes needed for a split hardware / control
domain.

An earlier posting gave device_model privileges to hardware domain.  For
this posting, it was split out into a new capability.  This way the
operator can choose where to run the device models without making the
hardware domain have the permissions.

The first patch add XSM_HW_PRIV for the hardware hypercalls.  Unlike the
first posting, the control domain can call these hypercalls even though
it doesn't really make sense.  The idea was to keep the control domain
all powerful from an XSM perspective.

SILO is changed to allow control, hardwware or xenstore to service
domUs.  Xenstore and hardware will use grants for PV interfaces.
Control wouldn't typically provide PV interfaces to domUs, but it is
given the permision to do so.  Again, to keep control all powerful.

xsm/dummy: Allow hwdom SYSCTL_readconsole/physinfo this is not strictly
needed.  xenconsoled could read Xen's dmesg.  If it's in hwdom, then
that permission would be required.  SYSCTL_physinfo is mainly to silence
xl messages, which are mostly cosmetic.

Jason Andryuk (4):
  xen/xsm: Add XSM_HW_PRIV
  xsm/silo: Support hwdom/control domains
  xen: Add DOMAIN_CAPS_DEVICE_MODEL & XEN_DOMCTL_CDF_device_model
  xsm/dummy: Allow hwdom SYSCTL_readconsole/physinfo

 tools/ocaml/libs/xc/xenctrl.ml          |  1 +
 tools/ocaml/libs/xc/xenctrl.mli         |  1 +
 xen/arch/arm/domain.c                   |  3 ++-
 xen/arch/arm/platform_hypercall.c       |  2 +-
 xen/arch/x86/msi.c                      |  2 +-
 xen/arch/x86/physdev.c                  | 12 ++++-----
 xen/arch/x86/platform_hypercall.c       |  2 +-
 xen/common/device-tree/dom0less-build.c |  3 +++
 xen/common/domain.c                     |  3 ++-
 xen/common/sysctl.c                     |  2 +-
 xen/drivers/passthrough/pci.c           |  5 ++--
 xen/drivers/pci/physdev.c               |  2 +-
 xen/include/public/bootfdt.h            | 12 +++++++--
 xen/include/public/domctl.h             |  4 ++-
 xen/include/xen/sched.h                 |  9 +++++++
 xen/include/xsm/dummy.h                 | 36 ++++++++++++++++++-------
 xen/include/xsm/xsm.h                   |  1 +
 xen/xsm/silo.c                          | 10 +++++--
 18 files changed, 80 insertions(+), 30 deletions(-)

-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 00:00:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 00:00:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011226.1389591 (Exim 4.92)
	(envelope-from )
	id 1uP8tN-0005i5-4y; Wed, 11 Jun 2025 00:00:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011226.1389591; Wed, 11 Jun 2025 00:00: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 1uP8tN-0005hy-20; Wed, 11 Jun 2025 00:00:33 +0000
Received: by outflank-mailman (input) for mailman id 1011226;
 Wed, 11 Jun 2025 00:00: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 1uP8tM-0005ZD-CL
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 00:00:32 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20630.outbound.protection.outlook.com
 [2a01:111:f403:2412::630])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1533f5d4-4657-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 02:00:29 +0200 (CEST)
Received: from MW2PR16CA0042.namprd16.prod.outlook.com (2603:10b6:907:1::19)
 by MW4PR12MB7430.namprd12.prod.outlook.com (2603:10b6:303:224::14) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.18; Wed, 11 Jun
 2025 00:00:25 +0000
Received: from SJ5PEPF000001E8.namprd05.prod.outlook.com
 (2603:10b6:907:1:cafe::4f) by MW2PR16CA0042.outlook.office365.com
 (2603:10b6:907:1::19) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.19 via Frontend Transport; Wed,
 11 Jun 2025 00:00:25 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SJ5PEPF000001E8.mail.protection.outlook.com (10.167.242.196) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Wed, 11 Jun 2025 00:00:24 +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; Tue, 10 Jun
 2025 19:00:15 -0500
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; Tue, 10 Jun
 2025 19:00:15 -0500
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 Jun 2025 19:00:14 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1533f5d4-4657-11f0-a307-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=VxW8BtPYNZZBeuxhMJlXMiN2rhdm8J1hS+nxn/Ybnd7QXPmurJzSE4haHEQKYeGT0IjqtYkM0K8R0nAdG93xfwICv/2q5lNL/Nf4tabS30KlpI4SSM+Z8cNj0afwsfdP2mJtxer1j6+z2jcoxNa6C+irPcRxoZLOBmUOurHSwyTsLAbEp/qvrhN/z/3HFEml4asaH5JS3lRMAzzV0NjwnCZKwpGC1G7nR4ODDQIXt9t47guB0GIQ/K1V0cVVF8mFl3c2e5XXAQqTKvZcQBX0kwjfPYaDx05b+EHKi3/qVf3hks3am+GvZUdvRcIIiQ+kHG1mi+d1jbkNP6r49kknaQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=AtLW9DfF81MIMkOe9MoiU7sblleifJc7acw0muGW3+o=;
 b=ycXKq5eEMA8FWIO2QRsllpGhyQzlG8r3JLCyBjPdVNxbGzueNtdDTMU0u9YC3SK0jhx9hxd4nxZITwKTjUQ0nXLxL3hOlgpFXFULOlMqBJJoS9Oqf6jnvXYgHWxvl2OUyK2CymRBleCI08ua8LdDLJQLpXKfFIdjrlvxugSCEQ7v9VEXGARWyVtpGgvyaWrVRRaiJTBR9GmvJu1iyQzuimuWRkJHkf4i8y5QI6Di/Sb7RcB7R6ahQgMk0g4pxC2I/PbtBH34uSzlk/q3Rp4dB3SeJx8iAgK9ToyFpQxdimYtuLnFJfFJDo3zJU0eqP+96ERNT1g70yn6ZlIr3gXGJQ==
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=AtLW9DfF81MIMkOe9MoiU7sblleifJc7acw0muGW3+o=;
 b=DWCYRxJl56KmNL9ARjPdrAMjc157OQ2U00HQbgcieRvw74zpZ1EbRvhIxvNkIIPtwacATUVFAZYw8T6S38LVakj4O8lTSE0TNb8wammV1LP0ReY0hrWZIv1kEgXOJ8uxXldCpOifi1+kGyxWyKrZGO3NtNQyT82bvff5x1euU3g=
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 , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , Andrew Cooper
	, Anthony PERARD , "Jan
 Beulich" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, "Daniel P. Smith" 
Subject: [PATCH 1/4] xen/xsm: Add XSM_HW_PRIV
Date: Tue, 10 Jun 2025 18:57:34 -0400
Message-ID: <20250610225737.469690-2-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250610225737.469690-1-jason.andryuk@amd.com>
References: <20250610225737.469690-1-jason.andryuk@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
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: SJ5PEPF000001E8:EE_|MW4PR12MB7430:EE_
X-MS-Office365-Filtering-Correlation-Id: b027ab8e-e1c2-47de-e602-08dda87af718
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|7416014|1800799024|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?pjRruIJrD93vBuZuEEkvlfSH21C8CBjDotMGlRGK7Uq239WWLSqJkNWHuaSf?=
 =?us-ascii?Q?jHqjgaacK0IAKftyEAAcmJ57QyTHwdeFofF7uRohJrPNtObVU9U1n3aqVZ79?=
 =?us-ascii?Q?fVusq7tx9bN+Eqrz+KbbPx5dCCjy665TMh8/AodDvJhejswtGp32sRwqmS20?=
 =?us-ascii?Q?XD0Dnwu9p4qrNke1qoEO42JTrxXV9SPuoe7t+40uUJwVwq42cB6UI764impy?=
 =?us-ascii?Q?nPNHJ4h26gnZsddQTdmgJB4ZlLvLURuEfGYrlQ9PNlmVL7WLDwis7B1RhayJ?=
 =?us-ascii?Q?UCEmQCCO9spb4BE9bngpTznd0fmZ0i4UkmvUWKpbJAToNkEQsTtmwrbEdaMp?=
 =?us-ascii?Q?B2iJ2JbqXOdGFI1gdkbjDoyh4b+W/RcQXT0Poj9Vy79pSklFxbs+3mQ4nEXY?=
 =?us-ascii?Q?NWqPRwaSW1U2yywJHE0bZbdu9GL6VeqYBOo3+Eix2lCm6zrB5OZLu/7S8JJg?=
 =?us-ascii?Q?YOdYEYYO/B03FKOfP+jUzdgM9CxPCjhUODOtLUjl88EPtdago10+TKn9rkhs?=
 =?us-ascii?Q?tJ//qEbBGOVp9qYSEnIfgBA6KHX1+h2Fx9KYHrt7HDgEOcLU8f+Z0PcTamMZ?=
 =?us-ascii?Q?BfdjRu/ePaeuY48RIJQSwvrWkj8G+0Yp7p1LLuZMlrSKbg8OwnpXA6sc0BA8?=
 =?us-ascii?Q?Sp7cbfiXtN9rR1I6ai5/J7fryQ2a23oalpt2pIBdZHF7cAe8nQv5qKrC4BOH?=
 =?us-ascii?Q?q2V1IlhJ04QumtJLb+7oNqJS0rxshd5n4xvG4wszmxmpuPuyKOmN0GnR6wOw?=
 =?us-ascii?Q?UyhAO4Xxg8OJVx9vVUL40tDQKUQ8Ut/3Alte5DjYKb0mtbnZSxZ/RNJ2O8xR?=
 =?us-ascii?Q?GYKTHFyfKcUxDH/WINFjM3JkaUlvAgvF4H+cZ2xNQBAte2W9kgQNwTp7TZM0?=
 =?us-ascii?Q?Qu8OXDFK5Hv6cO6XIwWZNEGgJy1JVJZZyp+rdMP0IKcrE92i/TUtoMi6CtMz?=
 =?us-ascii?Q?RlOY3VfUoE/f7a0gMS5fb+0hBhmUJOuqv5UKKS1XwE4t9iYY4CJXsnohVRjd?=
 =?us-ascii?Q?Zui2+Mc7O0FEgw3hfPR4+h0uHpNYRAMGC5tbon+38SIocZgUAtb/boJjyNN9?=
 =?us-ascii?Q?N5wt1ChWQnuAV/BOEjp3Ws0IhLbmHtfx2y9nnlAGYHMI7sa+jo7i2qzupeh2?=
 =?us-ascii?Q?JcIjntomPBCDXhbWYXStBSTSEDcg7U9d3V7OVCSS1gve8ZsE0jT9RKEm93Pi?=
 =?us-ascii?Q?MRoPno4kqMVczvb8iO9XdQm7e4peWHWbClBx4e5qn74kzE1EeUeQhOd78df6?=
 =?us-ascii?Q?C30lri+TjL6blpfahOE5uh/VPaylWIhoBvz2tTi2RSFcY9M/1U9SblOGmfdU?=
 =?us-ascii?Q?XkGShJ5xSaPdpoL4KYl2OFs4HcRbC2QGE8+V0x6PZuU2PEHiievRvCSqoON5?=
 =?us-ascii?Q?CCLe6IPwo50ljyP/heHAWy+LJaZqHYrnq5sO8VXNFZB7yDtGzWNvMMzTqj6V?=
 =?us-ascii?Q?nLgD53VGOvWbtwNJFin8EtZMOXPEm0/s0hRcDoEXLRPKCfVk64W9R/5/0IlJ?=
 =?us-ascii?Q?axRPk2+aga0rOLShh2vxFDjbEKLaFaq9hyoc?=
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);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jun 2025 00:00:24.0138
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b027ab8e-e1c2-47de-e602-08dda87af718
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:
	SJ5PEPF000001E8.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB7430

Xen includes disctinct concepts of a control domain (privileged) and a
hardware domain, but there is only a single XSM_PRIV check.  For dom0
this is not an issue as they are one and the same.

With hyperlaunch and its build capabilities, a non-privileged hwdom and a
privileged control domain should be possible.  Today the hwdom fails the
XSM_PRIV checks for hardware-related hooks which it should be allowed
access to.

Introduce XSM_HW_PRIV, and use it to mark many of the physdev_op and
platform_op.  The hwdom is allowed access for XSM_HW_PRIV.

Make XSM_HW_PRIV a new privilege level that is given to the hardware
domain, but is not exclusive.  The control domain can still execute
XSM_HW_PRIV commands.  This is a little questionable since it's unclear
how the control domain can meaningfully execute them.  But this approach
is chosen to maintain the increasing privileges and keep control domain
fully privileged.

Testing was performed with hardware+xenstore capabilities for dom0 and a
control dom3 booted from hyperlaunch.  The additional xenstore
permissions allowed hwdom+xenstore XSM_XS_PRIV which are necesary for
xenstore.

A traditional dom0 will be both privileged and hardware domain, so it
continues to have all accesses.

Why not XSM:Flask?  XSM:Flask is fine grain, and this aims to allow
coarse grain.  domUs are still domUs.  If capabilities are meant to be a
first class citizen, they should be usable by the default XSM policy.

Signed-off-by: Jason Andryuk 
---
 xen/arch/arm/platform_hypercall.c |  2 +-
 xen/arch/x86/msi.c                |  2 +-
 xen/arch/x86/physdev.c            | 12 ++++++------
 xen/arch/x86/platform_hypercall.c |  2 +-
 xen/drivers/passthrough/pci.c     |  5 +++--
 xen/drivers/pci/physdev.c         |  2 +-
 xen/include/xsm/dummy.h           | 20 ++++++++++++--------
 xen/include/xsm/xsm.h             |  1 +
 8 files changed, 26 insertions(+), 20 deletions(-)

diff --git a/xen/arch/arm/platform_hypercall.c b/xen/arch/arm/platform_hypercall.c
index ac55622426..a84596ae3a 100644
--- a/xen/arch/arm/platform_hypercall.c
+++ b/xen/arch/arm/platform_hypercall.c
@@ -35,7 +35,7 @@ long do_platform_op(XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op)
     if ( d == NULL )
         return -ESRCH;
 
-    ret = xsm_platform_op(XSM_PRIV, op->cmd);
+    ret = xsm_platform_op(XSM_HW_PRIV, op->cmd);
     if ( ret )
         return ret;
 
diff --git a/xen/arch/x86/msi.c b/xen/arch/x86/msi.c
index 5389bc0867..30801d980c 100644
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -1360,7 +1360,7 @@ int pci_restore_msi_state(struct pci_dev *pdev)
     if ( !use_msi )
         return -EOPNOTSUPP;
 
-    ret = xsm_resource_setup_pci(XSM_PRIV,
+    ret = xsm_resource_setup_pci(XSM_HW_PRIV,
                                 (pdev->seg << 16) | (pdev->bus << 8) |
                                 pdev->devfn);
     if ( ret )
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index 4dfa1c0191..ce1ba41fa3 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -358,7 +358,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         ret = -EFAULT;
         if ( copy_from_guest(&apic, arg, 1) != 0 )
             break;
-        ret = xsm_apic(XSM_PRIV, currd, cmd);
+        ret = xsm_apic(XSM_HW_PRIV, currd, cmd);
         if ( ret )
             break;
         ret = ioapic_guest_read(apic.apic_physbase, apic.reg, &apic.value);
@@ -372,7 +372,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         ret = -EFAULT;
         if ( copy_from_guest(&apic, arg, 1) != 0 )
             break;
-        ret = xsm_apic(XSM_PRIV, currd, cmd);
+        ret = xsm_apic(XSM_HW_PRIV, currd, cmd);
         if ( ret )
             break;
         ret = ioapic_guest_write(apic.apic_physbase, apic.reg, apic.value);
@@ -388,7 +388,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 
         /* Use the APIC check since this dummy hypercall should still only
          * be called by the domain with access to program the ioapic */
-        ret = xsm_apic(XSM_PRIV, currd, cmd);
+        ret = xsm_apic(XSM_HW_PRIV, currd, cmd);
         if ( ret )
             break;
 
@@ -490,7 +490,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         if ( copy_from_guest(&dev, arg, 1) )
             ret = -EFAULT;
         else
-            ret = xsm_resource_setup_pci(XSM_PRIV,
+            ret = xsm_resource_setup_pci(XSM_HW_PRIV,
                                          (dev.seg << 16) | (dev.bus << 8) |
                                          dev.devfn) ?:
                   pci_prepare_msix(dev.seg, dev.bus, dev.devfn,
@@ -501,7 +501,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
     case PHYSDEVOP_pci_mmcfg_reserved: {
         struct physdev_pci_mmcfg_reserved info;
 
-        ret = xsm_resource_setup_misc(XSM_PRIV);
+        ret = xsm_resource_setup_misc(XSM_HW_PRIV);
         if ( ret )
             break;
 
@@ -567,7 +567,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         if ( setup_gsi.gsi < 0 || setup_gsi.gsi >= nr_irqs_gsi )
             break;
 
-        ret = xsm_resource_setup_gsi(XSM_PRIV, setup_gsi.gsi);
+        ret = xsm_resource_setup_gsi(XSM_HW_PRIV, setup_gsi.gsi);
         if ( ret )
             break;
 
diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c
index 90abd3197f..8efb4ad05f 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -228,7 +228,7 @@ ret_t do_platform_op(
     if ( op->interface_version != XENPF_INTERFACE_VERSION )
         return -EACCES;
 
-    ret = xsm_platform_op(XSM_PRIV, op->cmd);
+    ret = xsm_platform_op(XSM_HW_PRIV, op->cmd);
     if ( ret )
         return ret;
 
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 3edcfa8a04..9de7f0d358 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -672,7 +672,7 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
     else
         type = "device";
 
-    ret = xsm_resource_plug_pci(XSM_PRIV, (seg << 16) | (bus << 8) | devfn);
+    ret = xsm_resource_plug_pci(XSM_HW_PRIV, (seg << 16) | (bus << 8) | devfn);
     if ( ret )
         return ret;
 
@@ -824,7 +824,8 @@ int pci_remove_device(u16 seg, u8 bus, u8 devfn)
     struct pci_dev *pdev;
     int ret;
 
-    ret = xsm_resource_unplug_pci(XSM_PRIV, (seg << 16) | (bus << 8) | devfn);
+    ret = xsm_resource_unplug_pci(XSM_HW_PRIV,
+                                  (seg << 16) | (bus << 8) | devfn);
     if ( ret )
         return ret;
 
diff --git a/xen/drivers/pci/physdev.c b/xen/drivers/pci/physdev.c
index 0161a85e1e..c223611dfb 100644
--- a/xen/drivers/pci/physdev.c
+++ b/xen/drivers/pci/physdev.c
@@ -86,7 +86,7 @@ ret_t pci_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
                         dev_reset.dev.bus,
                         dev_reset.dev.devfn);
 
-        ret = xsm_resource_setup_pci(XSM_PRIV, sbdf.sbdf);
+        ret = xsm_resource_setup_pci(XSM_HW_PRIV, sbdf.sbdf);
         if ( ret )
             break;
 
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 9227205fcd..d8df3f66c4 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -94,6 +94,10 @@ static always_inline int xsm_default_action(
         if ( target && evaluate_nospec(src->target == target) )
             return 0;
         fallthrough;
+    case XSM_HW_PRIV:
+        if ( action == XSM_HW_PRIV && is_hardware_domain(src) )
+            return 0;
+        fallthrough;
     case XSM_PRIV:
         if ( is_control_domain(src) )
             return 0;
@@ -275,7 +279,7 @@ static XSM_INLINE int cf_check xsm_console_io(
     if ( cmd == CONSOLEIO_write )
         return xsm_default_action(XSM_HOOK, d, NULL);
 #endif
-    return xsm_default_action(XSM_PRIV, d, NULL);
+    return xsm_default_action(XSM_HW_PRIV, d, NULL);
 }
 
 static XSM_INLINE int cf_check xsm_profile(
@@ -455,33 +459,33 @@ static XSM_INLINE int cf_check xsm_resource_unplug_core(XSM_DEFAULT_VOID)
 static XSM_INLINE int cf_check xsm_resource_plug_pci(
     XSM_DEFAULT_ARG uint32_t machine_bdf)
 {
-    XSM_ASSERT_ACTION(XSM_PRIV);
+    XSM_ASSERT_ACTION(XSM_HW_PRIV);
     return xsm_default_action(action, current->domain, NULL);
 }
 
 static XSM_INLINE int cf_check xsm_resource_unplug_pci(
     XSM_DEFAULT_ARG uint32_t machine_bdf)
 {
-    XSM_ASSERT_ACTION(XSM_PRIV);
+    XSM_ASSERT_ACTION(XSM_HW_PRIV);
     return xsm_default_action(action, current->domain, NULL);
 }
 
 static XSM_INLINE int cf_check xsm_resource_setup_pci(
     XSM_DEFAULT_ARG uint32_t machine_bdf)
 {
-    XSM_ASSERT_ACTION(XSM_PRIV);
+    XSM_ASSERT_ACTION(XSM_HW_PRIV);
     return xsm_default_action(action, current->domain, NULL);
 }
 
 static XSM_INLINE int cf_check xsm_resource_setup_gsi(XSM_DEFAULT_ARG int gsi)
 {
-    XSM_ASSERT_ACTION(XSM_PRIV);
+    XSM_ASSERT_ACTION(XSM_HW_PRIV);
     return xsm_default_action(action, current->domain, NULL);
 }
 
 static XSM_INLINE int cf_check xsm_resource_setup_misc(XSM_DEFAULT_VOID)
 {
-    XSM_ASSERT_ACTION(XSM_PRIV);
+    XSM_ASSERT_ACTION(XSM_HW_PRIV);
     return xsm_default_action(action, current->domain, NULL);
 }
 
@@ -673,7 +677,7 @@ static XSM_INLINE int cf_check xsm_mem_sharing(XSM_DEFAULT_ARG struct domain *d)
 
 static XSM_INLINE int cf_check xsm_platform_op(XSM_DEFAULT_ARG uint32_t op)
 {
-    XSM_ASSERT_ACTION(XSM_PRIV);
+    XSM_ASSERT_ACTION(XSM_HW_PRIV);
     return xsm_default_action(action, current->domain, NULL);
 }
 
@@ -701,7 +705,7 @@ static XSM_INLINE int cf_check xsm_mem_sharing_op(
 static XSM_INLINE int cf_check xsm_apic(
     XSM_DEFAULT_ARG struct domain *d, int cmd)
 {
-    XSM_ASSERT_ACTION(XSM_PRIV);
+    XSM_ASSERT_ACTION(XSM_HW_PRIV);
     return xsm_default_action(action, d, NULL);
 }
 
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 24acc16125..264db4d8ee 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -36,6 +36,7 @@ enum xsm_default {
     XSM_DM_PRIV,  /* Device model can perform on its target domain */
     XSM_TARGET,   /* Can perform on self or your target domain */
     XSM_PRIV,     /* Privileged - normally restricted to dom0 */
+    XSM_HW_PRIV,  /* Hardware Privileged - normally restricted to dom0/hwdom */
     XSM_XS_PRIV,  /* Xenstore domain - can do some privileged operations */
     XSM_OTHER     /* Something more complex */
 };
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 00:00:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 00:00:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011227.1389602 (Exim 4.92)
	(envelope-from )
	id 1uP8tR-000612-HF; Wed, 11 Jun 2025 00:00:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011227.1389602; Wed, 11 Jun 2025 00:00:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uP8tR-00060q-Cw; Wed, 11 Jun 2025 00:00:37 +0000
Received: by outflank-mailman (input) for mailman id 1011227;
 Wed, 11 Jun 2025 00:00: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 1uP8tP-0005ZD-Lo
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 00:00:35 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20609.outbound.protection.outlook.com
 [2a01:111:f403:2417::609])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 157a6155-4657-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 02:00:29 +0200 (CEST)
Received: from PH3PEPF000040AB.namprd05.prod.outlook.com (2603:10b6:518:1::4d)
 by SN7PR12MB7249.namprd12.prod.outlook.com (2603:10b6:806:2a9::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Wed, 11 Jun
 2025 00:00:23 +0000
Received: from SJ1PEPF000026C8.namprd04.prod.outlook.com
 (2a01:111:f403:c902::15) by PH3PEPF000040AB.outlook.office365.com
 (2603:1036:903:49::3) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.17 via Frontend Transport; Wed,
 11 Jun 2025 00:00:23 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ1PEPF000026C8.mail.protection.outlook.com (10.167.244.105) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Wed, 11 Jun 2025 00:00:22 +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 Jun
 2025 19:00:22 -0500
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 Jun
 2025 19:00:22 -0500
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 Jun 2025 19:00:21 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 157a6155-4657-11f0-a307-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=qzXkmbVAl45AEJBMkdvFzbiFERSXIQid7KmoW7WEahhwrfBu9O6NEmcUdmrC4aCNLSosqJz0EYqgTuSEgkZOqJa3kI5r6daYwir+UExsFctKiHm+3UvGoB69t8hFtzrNuJzKA9klvFbSvnVJG2BzfUY7uara5um5duk1mgAoB1D7lDttbr4MLU+NEu4Tz6qSIFI3WWWiWVIsy3Xtbu1d5sehBCV7EgEZyJqqB7NPrUNe0QrOkX/B1HhsAGv2KyP3ypdsfecCDBHkBESXWQHVEvKYMrT3ylqx32r3BUyWDkHGXJOxopUEX1Noz7GSz28CHfdlGwrn9YYEC6RMoC0Kbw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=zdLqkA4EvLX02tBUyJKyjGQgzohmrtGsAZgJTfe1LLw=;
 b=DZtloHoxG9sT1lfDWr7nw3GyMME/vxm9f17Kk/CpmyHcKHwOel3zR3RbLhAwpiJcRKyv2qmUXlVOmiXO+MUZrR8+52M7SYmbQPMeHY1/hoMicEjxNL2ScEFxKqzIDtZRWtZWBk7SZ/hh/TRbPztt0Uwf9cIUM8J4uUYXq4kXF9wwE4IjGbB3y02ldyecAHDKMFJmk6v8Aj0B4wibhukkpxyejqpXrwVKoWNNGE2kXXfdH86sZuSiIef0IscLt9+JNmjLi5In+SD3dPNZSRXiGzs/I920bPsIcKK9b4IzAoGVb3AXZCqc2cehy2vc+onZytqd3mGWYu0uDWU4tiB5RQ==
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=zdLqkA4EvLX02tBUyJKyjGQgzohmrtGsAZgJTfe1LLw=;
 b=q+fPyQes+m3+HQBY4T698VsdJp26wr1oxnsvvFB+qYElukenyRjz+bC0pnCvqznTv6D8YZ0zCyg4XbnWIeYbbpMJfSebqrFQQY6W6MBT1N1ZEkJRxbUlvstMT0AjVf4xldLd0exjyzdqwarvINLQ8KD6lRZXM8NJAQ3+0Flbpvs=
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 , Christian Lindig
	, David Scott , Anthony PERARD
	, Andrew Cooper ,
	Michal Orzel , Jan Beulich , "Julien
 Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Stefano Stabellini , Bertrand
 Marquis , Volodymyr Babchuk
	, "Daniel P. Smith"
	
Subject: [PATCH 3/4] xen: Add DOMAIN_CAPS_DEVICE_MODEL & XEN_DOMCTL_CDF_device_model
Date: Tue, 10 Jun 2025 18:57:36 -0400
Message-ID: <20250610225737.469690-4-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250610225737.469690-1-jason.andryuk@amd.com>
References: <20250610225737.469690-1-jason.andryuk@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF000026C8:EE_|SN7PR12MB7249:EE_
X-MS-Office365-Filtering-Correlation-Id: b829edcd-9a12-44f3-621c-08dda87af660
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|7416014|376014|1800799024|36860700013|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?7d/lOFBrlRJ7S/hjSF48bWBwuLmsIQ+c03Wgri238ZvUMguOchGFnllEpWqY?=
 =?us-ascii?Q?YfiastXJDukhrq9Y4viXDyPn0fPeVXzlJOdS/LxgiXSvs1ZVbhWaVNLOhsWg?=
 =?us-ascii?Q?xfQJAir+e3493/CGGlHoj8IagtoY7PailaTaodPsq1xXkSAGZ9AKihJveCOu?=
 =?us-ascii?Q?U3JyKZuvRBjCyAF9D8eitRyHJC98Y7D9pg63s7QdUGOOGTNPpl3b3JwSHLoC?=
 =?us-ascii?Q?GZzXH+S9FMcMLbNTHSlTRFIloH/pz9q1PHNNRr0YPMSoFiX5GXPMeOQ32hiE?=
 =?us-ascii?Q?8RpHsPUVyUJHR7Ur5YIUzlhKc7MK/TlVlC8c/9jXLwUH4bUmrA9UkulbOYp9?=
 =?us-ascii?Q?ERCLS+2jK+c0lQdkzdfXjCGjqV2GrOcWfsYVOerJAsDLdiK2r2inbKFr4zkc?=
 =?us-ascii?Q?t+L6Zmb2fmGFkTF7HvhihYJyHq5GFGM3+7/WLeixOPYT6qs1pey9c7Gn2zmC?=
 =?us-ascii?Q?Iz4A1wch6B8BFAUxXEnzzFDcs6zvYmQ5eWOoK90IJkRmLNcPFeH5Nfb3F+/M?=
 =?us-ascii?Q?9i1cQcMWzfKUUXGsq3H/nSxj4HtkN17IhLpD4uP9Y7NOAez8zwAzLq7VIr8K?=
 =?us-ascii?Q?5RN3X0bK5l93x1YQ+3AHQCyC8u1bggMEo8QAJ+bUItuWiQTndVgJGKgq1Ubk?=
 =?us-ascii?Q?mQ6IRaTXMEdsFqq0tl7TskWBprD3vt4uceskpsdGcuKLMr0bOCTEKGUv4/9e?=
 =?us-ascii?Q?uE/VuPs6qwimMcu3DRqunxlTeDkd44qimxEx2T+oeNWA+PfkrRzoeC0SnBbh?=
 =?us-ascii?Q?jiJOxySsa0eqKfO54X9/mzqG7/WN+X2nwo/42kCxPg00MDD+5a3AsrF4Q7Kr?=
 =?us-ascii?Q?hPNzOeVgVyKwACGP79D7MyTmFyNGk9mYliowKSB9QMBtC+lmqawrxx82m91F?=
 =?us-ascii?Q?Zrn2DLLYJlGuYTgFOKXmvsKL6pGGbrXxW8sLPYzmE7Y9RrnqPph0z4C0yw5Z?=
 =?us-ascii?Q?Dxq4HlhMHQ/+UelxUbem7WXOCPQ3TMMpXuvTAY6Lio1mMwjn7Y22nXRLsdXa?=
 =?us-ascii?Q?NpkYcZVGYu3s2C+NwSuXGx9OnSIOTle+EJ8jj/vNLBAluZNcTTIEKTZxQczU?=
 =?us-ascii?Q?fBpgkJyBmw4VPHzT9tjwsE4QWwuvvkKm0pRAmD2GnVru2ix+T0C9en8tTQKP?=
 =?us-ascii?Q?PzU+GDk7Fj1HqQoxBte0kWWvcFI9a/oEF8QNnZLzNvutkpkAQ5Wrpz9k8Xyr?=
 =?us-ascii?Q?UQVWd7FDMv/LRMEQvCv3UKs3+WizZBxZ4L+PBsP+NK9rSSqVHQNvMQM9UqTW?=
 =?us-ascii?Q?Xsy7TA2jXJoFJalq4beD4mwjO5B98ruQplkTqlh6+E7oWyRs6sCHKDy7PWj/?=
 =?us-ascii?Q?YeasOyaL7PzD6quJKY7I8BSvCjls9rTwbdoZFz5MEdvJgAyrQBjIH+qgEb6h?=
 =?us-ascii?Q?V0lYJKmtq35RLaDRpbJtBhNzbYNAYhO8aF7Tf2aCDq6hrTMFCQO5S/FIzMfg?=
 =?us-ascii?Q?8SxHctPxkbmX5lE9R7MOMp1TVbeAqzeJW+X/n7S5JvZkquWf+hWMQBTJLzqV?=
 =?us-ascii?Q?XxGRBgmGcdYhxyXwdjJ3cXAnhs4rR8ZlUUw2?=
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);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jun 2025 00:00:22.8192
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b829edcd-9a12-44f3-621c-08dda87af660
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:
	SJ1PEPF000026C8.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7249

To add more flexibility in system configuration add the new
DOMAIN_CAPS_DEVICE_MODEL flag and XEN_DOMCTL_CDF_device_model.

Thie new flag corresponds to allowing XSM_DM_PRIV for the domain.  This
will enable running device model emulators (QEMU) from the assigne
domain for multiple target domains.

Stubdoms assign target allowing the stubdom to serve as the device
model for a single domain.  This new flag allows the single domain to
provide emulators for multiple guests.

The specific scenario is a disaggregated system with the hardware domain
providing device models for muitple guest domains.

The OCaml code needs the flag added in as well.

Signed-off-by: Jason Andryuk 
---
 tools/ocaml/libs/xc/xenctrl.ml          |  1 +
 tools/ocaml/libs/xc/xenctrl.mli         |  1 +
 xen/arch/arm/domain.c                   |  3 ++-
 xen/common/device-tree/dom0less-build.c |  3 +++
 xen/common/domain.c                     |  3 ++-
 xen/include/public/bootfdt.h            | 12 ++++++++++--
 xen/include/public/domctl.h             |  4 +++-
 xen/include/xen/sched.h                 |  9 +++++++++
 xen/include/xsm/dummy.h                 |  2 ++
 9 files changed, 33 insertions(+), 5 deletions(-)

diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml
index 2690f9a923..ef0c5dca2a 100644
--- a/tools/ocaml/libs/xc/xenctrl.ml
+++ b/tools/ocaml/libs/xc/xenctrl.ml
@@ -70,6 +70,7 @@ type domain_create_flag =
   | CDF_IOMMU
   | CDF_NESTED_VIRT
   | CDF_VPMU
+  | CDF_DEVICE_MODEL
 
 type domain_create_iommu_opts =
   | IOMMU_NO_SHAREPT
diff --git a/tools/ocaml/libs/xc/xenctrl.mli b/tools/ocaml/libs/xc/xenctrl.mli
index febbe1f6ae..c0156fa5c6 100644
--- a/tools/ocaml/libs/xc/xenctrl.mli
+++ b/tools/ocaml/libs/xc/xenctrl.mli
@@ -63,6 +63,7 @@ type domain_create_flag =
   | CDF_IOMMU
   | CDF_NESTED_VIRT
   | CDF_VPMU
+  | CDF_DEVICE_MODEL
 
 type domain_create_iommu_opts =
   | IOMMU_NO_SHAREPT
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 45aeb8bddc..12fda0762f 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -612,7 +612,8 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
     unsigned int max_vcpus;
     unsigned int flags_required = (XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap);
     unsigned int flags_optional = (XEN_DOMCTL_CDF_iommu | XEN_DOMCTL_CDF_vpmu |
-                                   XEN_DOMCTL_CDF_xs_domain );
+                                   XEN_DOMCTL_CDF_xs_domain |
+                                   XEN_DOMCTL_CDF_device_model);
     unsigned int sve_vl_bits = sve_decode_vl(config->arch.sve_vl);
 
     if ( (config->flags & ~flags_optional) != flags_required )
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
index 3d503c6973..993ff32f5e 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -884,6 +884,9 @@ void __init create_domUs(void)
                 d_cfg.flags |= XEN_DOMCTL_CDF_xs_domain;
                 d_cfg.max_evtchn_port = -1;
             }
+
+            if ( val & DOMAIN_CAPS_DEVICE_MODEL )
+                d_cfg.flags |= XEN_DOMCTL_CDF_device_model;
         }
 
         if ( dt_find_property(node, "xen,static-mem", NULL) )
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 153cd75340..ab2c8f864d 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -721,7 +721,8 @@ static int sanitise_domain_config(struct xen_domctl_createdomain *config)
          ~(XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap |
            XEN_DOMCTL_CDF_s3_integrity | XEN_DOMCTL_CDF_oos_off |
            XEN_DOMCTL_CDF_xs_domain | XEN_DOMCTL_CDF_iommu |
-           XEN_DOMCTL_CDF_nested_virt | XEN_DOMCTL_CDF_vpmu) )
+           XEN_DOMCTL_CDF_nested_virt | XEN_DOMCTL_CDF_vpmu |
+           XEN_DOMCTL_CDF_device_model) )
     {
         dprintk(XENLOG_INFO, "Unknown CDF flags %#x\n", config->flags);
         return -EINVAL;
diff --git a/xen/include/public/bootfdt.h b/xen/include/public/bootfdt.h
index 86c46b42a9..c6b5afc76a 100644
--- a/xen/include/public/bootfdt.h
+++ b/xen/include/public/bootfdt.h
@@ -25,7 +25,15 @@
 #define DOMAIN_CAPS_HARDWARE (1U << 1)
 /* Xenstore domain. */
 #define DOMAIN_CAPS_XENSTORE (1U << 2)
-#define DOMAIN_CAPS_MASK     (DOMAIN_CAPS_CONTROL | DOMAIN_CAPS_HARDWARE | \
-                              DOMAIN_CAPS_XENSTORE)
+/*
+ * Device model capability allows the use of the dm_op hypercalls to provide
+ * the device model emulation (run QEMU) for other domains.  This is a
+ * subset of the Control capability which can be granted to the
+ * Hardware domain for running QEMU.
+ */
+#define DOMAIN_CAPS_DEVICE_MODEL (1U << 3)
+
+#define DOMAIN_CAPS_MASK     (DOMAIN_CAPS_CONTROL  | DOMAIN_CAPS_HARDWARE | \
+                              DOMAIN_CAPS_XENSTORE | DOMAIN_CAPS_DEVICE_MODEL )
 
 #endif /* __XEN_PUBLIC_BOOTFDT_H__ */
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 5b2063eed9..2280489be2 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -66,9 +66,11 @@ struct xen_domctl_createdomain {
 #define XEN_DOMCTL_CDF_nested_virt    (1U << _XEN_DOMCTL_CDF_nested_virt)
 /* Should we expose the vPMU to the guest? */
 #define XEN_DOMCTL_CDF_vpmu           (1U << 7)
+/* Allow domain to provide device model for multiple other domains */
+#define XEN_DOMCTL_CDF_device_model   (1U << 8)
 
 /* Max XEN_DOMCTL_CDF_* constant.  Used for ABI checking. */
-#define XEN_DOMCTL_CDF_MAX XEN_DOMCTL_CDF_vpmu
+#define XEN_DOMCTL_CDF_MAX XEN_DOMCTL_CDF_device_model
 
     uint32_t flags;
 
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index fe53d4fab7..9863603d93 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -1148,6 +1148,15 @@ static always_inline bool is_control_domain(const struct domain *d)
     return evaluate_nospec(d->is_privileged);
 }
 
+/* This check is for functionality specific to a device model domain */
+static always_inline bool is_dm_domain(const struct domain *d)
+{
+    if ( IS_ENABLED(CONFIG_PV_SHIM_EXCLUSIVE) )
+        return false;
+
+    return evaluate_nospec(d->options & XEN_DOMCTL_CDF_device_model);
+}
+
 #define VM_ASSIST(d, t) (test_bit(VMASST_TYPE_ ## t, &(d)->vm_assist))
 
 static always_inline bool is_pv_domain(const struct domain *d)
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index d8df3f66c4..477fadaefd 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -91,6 +91,8 @@ static always_inline int xsm_default_action(
             return 0;
         fallthrough;
     case XSM_DM_PRIV:
+        if ( is_dm_domain(src) )
+            return 0;
         if ( target && evaluate_nospec(src->target == target) )
             return 0;
         fallthrough;
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 00:00:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 00:00:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011232.1389612 (Exim 4.92)
	(envelope-from )
	id 1uP8ta-0006UL-P1; Wed, 11 Jun 2025 00:00:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011232.1389612; Wed, 11 Jun 2025 00:00:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uP8ta-0006U9-Lk; Wed, 11 Jun 2025 00:00:46 +0000
Received: by outflank-mailman (input) for mailman id 1011232;
 Wed, 11 Jun 2025 00:00: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 1uP8tZ-0005ZD-Fw
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 00:00:45 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20616.outbound.protection.outlook.com
 [2a01:111:f403:2415::616])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1e73f5f3-4657-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 02:00:44 +0200 (CEST)
Received: from SJ0PR13CA0221.namprd13.prod.outlook.com (2603:10b6:a03:2c1::16)
 by IA1PR12MB9531.namprd12.prod.outlook.com (2603:10b6:208:596::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Wed, 11 Jun
 2025 00:00:39 +0000
Received: from SJ5PEPF000001EE.namprd05.prod.outlook.com
 (2603:10b6:a03:2c1:cafe::ab) by SJ0PR13CA0221.outlook.office365.com
 (2603:10b6:a03:2c1::16) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.19 via Frontend Transport; Wed,
 11 Jun 2025 00:00:39 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SJ5PEPF000001EE.mail.protection.outlook.com (10.167.242.202) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Wed, 11 Jun 2025 00:00:38 +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 Jun
 2025 19:00:18 -0500
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 Jun 2025 19:00:18 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1e73f5f3-4657-11f0-a307-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=JUgn2NKGswK0DwIFzbwxeWx0LRxNBJBigN7jGE+AQ/4+JCwnczdM3MsdZIurnXb0Aik2z7Gp1Nam1A3TcD48792Rewf5l3K0GtQdjjYfmqEdPfyAfF3wpuzknNsgmUwk8Tezwg7CU9NyMIc29+r+TGopVvw/pyrpFxS0h6lhfm6ilheHbZ89+sUWPGe9SvX9mX6wtqJcJRjuS2hOn8TfWMpwSXD2xzJ7h+nBPhOM4tujR0ARRu3BkxTQ3dJ4Gmp6TmXu5ZxEuwOEHwViPUCtDIo6dX4WAi0Tof3J7xm3pDS5m/LPgXZaa++Z1KDSRWBj8bmqsHngyZJ0t3DwWdo05Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ts3RTY6TOei3qYAavMrJU+OXq8P7HWjtk/s03Gzv3uE=;
 b=OdkVbd/KUZAU2i+D8PRHzvoHJjnfvFYBezC8OS8SSo68neJSjSWw25v3CTDE7IGGS6PuO9RFCYUJ4aA4i74KWFqlkdy7WLeMnk2wRZunad4TeR/lVrpgOPhj4A8ihT9h9QjZp0yK0Op9zliawNv61zn0/l12TZPk4gSkElPZ1vXSy/9wDyfh4f+5XmOv3vxQ8Lx9vRdwC/to7RYEfwDcQQw7GON299Vopm3oMfdpJqJGkozwBZ3sJl9eCImASLu/nZFl9EQx6TIncBoNuKj6Vv8vqI0ulClPd/0YMEJh8+tCbpVhlcfFdBE+5vwMr05t4rWAjU5jUJ8Uk6hwdAC85g==
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=ts3RTY6TOei3qYAavMrJU+OXq8P7HWjtk/s03Gzv3uE=;
 b=qbb/I+Ln/dDM0ZY22vvVEVxguSuZHuekGsUfJ7xF4TEzPPbTK7y/XssSELs46alWPzS3pe/SGUtRDfrzMGeh6JJJutz/MTePrHVoRGZK8wrF5FuyJVUQg9FPn0mVfwEq06o1B/Gt3zTGs0HjsuuP5HgPS+RuF7QgzypZftVL2VA=
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 , "Daniel P. Smith"
	
Subject: [PATCH 2/4] xsm/silo: Support hwdom/control domains
Date: Tue, 10 Jun 2025 18:57:35 -0400
Message-ID: <20250610225737.469690-3-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250610225737.469690-1-jason.andryuk@amd.com>
References: <20250610225737.469690-1-jason.andryuk@amd.com>
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: SJ5PEPF000001EE:EE_|IA1PR12MB9531:EE_
X-MS-Office365-Filtering-Correlation-Id: dbf7e91d-6e07-4c88-c748-08dda87affe2
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?uhBRqAIp2Y8z/xynMDZSmGg/FQSCEpqfjMoYyZLywLhidGeqzlVB+1DXKEtS?=
 =?us-ascii?Q?phDRQF5lX/8O6gvQ5ZgPWK/uyQby6b83nCDDFfkXkjTGXvvtI2OY2LeLUq3V?=
 =?us-ascii?Q?vAm6IqvsC8Pdvzu0smXZYAlx1im+WfsdoeEtIDueEBrXonYoot4l2ibmhoPa?=
 =?us-ascii?Q?YcT+yWVwuNdaVkHdFa+FOPrCEfC9tIY0oLofyeLiYOemP0WVpktJy3yKkuba?=
 =?us-ascii?Q?KiI0YpikYUIhr+o6v86G0ijQRPq3cT0CiGoK3wm9RnxG75LAbHGKH8ImAmXo?=
 =?us-ascii?Q?duU2FLsRoHCgN2TomeO0SCEyoGQa4lkuwVBANnw0sSf5S4apXw7t9MIfHLjV?=
 =?us-ascii?Q?/dCUybSEJM/L3FJLuVrSl06tbtN2MtS2YOWx1V0ia/Kx5jFFABEykdmRjSeh?=
 =?us-ascii?Q?bo1pomZ1KGzC4PboQHbvnY5v1WF2gp+0CQV+rVpQJFc4jzTujfsd/h7RoBVR?=
 =?us-ascii?Q?lXhvFjFIkTiqcM/W+j32WTTpIHiV3rWsEtnXNIOFb0HY1wVft95SPj4sE+8n?=
 =?us-ascii?Q?2FOG/rD/ODbaqKBG5qjRBcDoviOwGJGKtWuSz6/RECuvbBeuFz+/HImzNKAM?=
 =?us-ascii?Q?H9nrXl9e36e4uN1AHOA7xP6zPSkS7l+WUOmjFHxe7EJZ67oo6DOBEzpzSTdv?=
 =?us-ascii?Q?PjcW9ez8cxKCaW8g9oro3AmuHW1zvi9FmK7AvsF/GJwyNhFDLc5b2fGhIxAI?=
 =?us-ascii?Q?gBrvrDtoff7d7Lo3RKmK7bwlPXm1e775rnQRKSl2V7V6sQJqQodraTjHsdzD?=
 =?us-ascii?Q?9/cjAtUrB3gvPMQuXxSL7NHO5sWBvJYrDKSi50Y0wX/Nv8pwb/7Rz5hjM8nX?=
 =?us-ascii?Q?IclDAVppc/WCb3F7iz9SMrhNDKq+18EthBQSGUkggMWWopdqsCnKmNq2d/Iw?=
 =?us-ascii?Q?laKydHkwayBhzYoaBHwX8s5i7nEji51latsGLDWk2lOHI0ZcU89id6fA9UUB?=
 =?us-ascii?Q?TV5fI4DTAfoZ3esrL5zY/OGO9AbGgMTCYqGOhUlLyMEDz5HJGsm4egZeu+lZ?=
 =?us-ascii?Q?rK+ZN4TMlHeL/wBCv1UNaSG35sY/fSWeoSl8TV1dBSEUxto2/k3oYZxPHlqD?=
 =?us-ascii?Q?noPkJ3znt80P7JaV5QvIb8OhHpgYJYalmpJSSpl5adyyN7L6KJQmr5+3ZWEf?=
 =?us-ascii?Q?Csm88v8/ld18mJezt5C0Yq4CXr6jXxRotxAMxQ5susRA5w06aQO4qXIDqKpj?=
 =?us-ascii?Q?pIfvTlfhJ35mrBLpULgpVz/C3E/jLoFftben+aAfO2eVEFSyIC6lYDFfuoMS?=
 =?us-ascii?Q?4qbB3/d8ddDfwiE9L4IyGc/C9zPnC1zqCbaiheEohFe0GqplJvivqwfKKhCV?=
 =?us-ascii?Q?ew6VsRGyPnVs1VMFkjhzGwba9XwkNaPUrDdkgkrtMBMO3WesIr+SPwF+raSw?=
 =?us-ascii?Q?/krwklAsHMvjKuntzsMt/5N8B/w3fP9/0kbNsvD092rADqlyv2u1Q4a2ZLrf?=
 =?us-ascii?Q?zxXXZKJUXTJVEnt0h7xWk7olc+vMCbU149CgTFKzS9T33FpkeBCe7yL/0gIm?=
 =?us-ascii?Q?93FURbUsLclKSPFSqKmW6fJuMjPU9g6e245x?=
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: 11 Jun 2025 00:00:38.7944
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: dbf7e91d-6e07-4c88-c748-08dda87affe2
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:
	SJ5PEPF000001EE.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB9531

In a disaggregated environment, dom0 is split into Control, Hardware,
and Xenstore domains, along with domUs.  The is_control_domain() check
is not sufficient to handle all these cases.  Add is_priv_domain() to
support allowing for the various domains.

The purpose of SILO mode is to prevent domUs from interacting with each
other.  But dom0 was allowed to communicate with domUs to provide
services.  As the disaggregation of dom0, Control, Hardware and Xenstore
are all service domains that need to communicate with other domains.

To provide xenstore connections, the Xenstore domain must be allowed to
connect via grants and event channels.  Xenstore domain must also be
allowed to connect to Control and Hardware to provide xenstore to them.

Hardware domain will provide PV devices to domains, so it must be
allowed to connect to domains.

That leaves Control.  Xenstore and Hardware would already allow access
to Control, so it can obtain services that way.  Control should be
"privileged", which would mean it can make the connections.  But with
Xenstore and Hardware providing their services to domUs, there may not
be a reason to allow Control to use grants or event channels with domUs.
Still, Control is privileged, so it should be allowed to do something if
it chooses.  Establishing a grant, or event channel requires action on
both sides, so allow for the possibility.  This does open up an argo
wildcard ring from domUs, FWIW.

This silo check is for grants, event channels and argo.  The dummy
policy handles other calls, so Hardware is prevented from foreign
mapping Control's memory with that.

Signed-off-by: Jason Andryuk 
---
v2:
Add xenstore domain
Expand commit message
Remove always_inline
---
 xen/xsm/silo.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/xen/xsm/silo.c b/xen/xsm/silo.c
index b89b364287..db48705674 100644
--- a/xen/xsm/silo.c
+++ b/xen/xsm/silo.c
@@ -20,6 +20,12 @@
 #define XSM_NO_WRAPPERS
 #include 
 
+static bool is_priv_domain(const struct domain *d)
+{
+    return is_xenstore_domain(d) || is_hardware_domain(d) ||
+           is_control_domain(d);
+}
+
 /*
  * Check if inter-domain communication is allowed.
  * Return true when pass check.
@@ -29,8 +35,8 @@ static bool silo_mode_dom_check(const struct domain *ldom,
 {
     const struct domain *currd = current->domain;
 
-    return (is_control_domain(currd) || is_control_domain(ldom) ||
-            is_control_domain(rdom) || ldom == rdom);
+    return (is_priv_domain(currd) || is_priv_domain(ldom) ||
+            is_priv_domain(rdom) || ldom == rdom);
 }
 
 static int cf_check silo_evtchn_unbound(
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 00:00:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 00:00:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011234.1389622 (Exim 4.92)
	(envelope-from )
	id 1uP8tf-0006oM-0S; Wed, 11 Jun 2025 00:00:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011234.1389622; Wed, 11 Jun 2025 00:00: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 1uP8te-0006oB-SZ; Wed, 11 Jun 2025 00:00:50 +0000
Received: by outflank-mailman (input) for mailman id 1011234;
 Wed, 11 Jun 2025 00:00: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 1uP8td-0005ZD-1k
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 00:00:49 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20621.outbound.protection.outlook.com
 [2a01:111:f403:2416::621])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1fd17c52-4657-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 02:00:48 +0200 (CEST)
Received: from MW2PR16CA0049.namprd16.prod.outlook.com (2603:10b6:907:1::26)
 by IA1PR12MB6187.namprd12.prod.outlook.com (2603:10b6:208:3e5::12) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.38; Wed, 11 Jun
 2025 00:00:41 +0000
Received: from SJ5PEPF000001E8.namprd05.prod.outlook.com
 (2603:10b6:907:1:cafe::e3) by MW2PR16CA0049.outlook.office365.com
 (2603:10b6:907:1::26) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Wed,
 11 Jun 2025 00:00:39 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SJ5PEPF000001E8.mail.protection.outlook.com (10.167.242.196) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Wed, 11 Jun 2025 00:00:39 +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 Jun
 2025 19:00:25 -0500
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 Jun
 2025 19:00:24 -0500
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 Jun 2025 19:00:24 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1fd17c52-4657-11f0-a307-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=K0a8s21PwKTVpvvTscnReOu/9sepoRKx5Br+pK0Nh5f5Y9Wl4jKYdpV2hGC0iePFa1zPQdo4F/6RCc6RrBU0J8SEzkj8J03aPzY+imS0BfAji/66ze7P9WcV2omke9MzBIum3NlfoC+vwt5FoThXBJUAme5GBUog+oBgYo+DIxkp7BPCjJ3VD7j6fVPWOonCzX1gaGc84O92oWhW2w+DnZLHB/TRQSFwCfyn4tD7l4rLpb3vIpuESCWmONK0i4c316dIUbEiX/kUBGV8uoaZmmJz4mR/W4Nw1vquyY8sxnnysqIJpg6Ho4qBT+g8njI9Ipf/Qqcv0Ie65j4hzUziQg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=2iazIvehT3EXJi3bBAC4f/lbNizm3XVxsCKUkoYsOvY=;
 b=Lw4nxIkQRq3S+77ni6pVXuweG5H+FoqpG2GC0LPI/Po0EYLmn7AbORARNvCN9oKS0XeQuFfV3nAP5S/LzEMBvNbBsKZY/tUYniScggdV/LBQ453Sce+n6gRLXrbC7fuLa/t32YHt0uuE31p6eMx9pgg8uz4RqmcCzWJi5B3TQA4a/Om18/klYc/47EHfZSm7dNMGsfhr/fgJKnujKhFr8HbXvKGF46uois4SFZZtFGIVzTJD3/crzRjhx9nhStWdSjdaQdt4rh7D+QARQL7gZQgJFwsU685+nUr7EsT2/of5ho+ZqTdVl+YX76tWdvjXSk7lTx7LXdBycydqVoJkkg==
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=2iazIvehT3EXJi3bBAC4f/lbNizm3XVxsCKUkoYsOvY=;
 b=KyCTKYJEtjyLrZx0OW6JNll8zPFzMm3maViYqIEH7tqHcWfLCwdAPDlO3XKjTCVGcAApBJhUxaaYHckwaWYe5N5kw3Q+/IzR7GE1izZei3SU2LEqm755hmsNzyt5818Efl9nixUu88X3HfCjRJByynw05h1Zu0mD9fT9AJmF2y0=
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 , 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 4/4] xsm/dummy: Allow hwdom SYSCTL_readconsole/physinfo
Date: Tue, 10 Jun 2025 18:57:37 -0400
Message-ID: <20250610225737.469690-5-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250610225737.469690-1-jason.andryuk@amd.com>
References: <20250610225737.469690-1-jason.andryuk@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001E8:EE_|IA1PR12MB6187:EE_
X-MS-Office365-Filtering-Correlation-Id: 30f70a3c-2007-424c-494e-08dda87b003e
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?kPy9SYMKtzxT7GrxfpM/gIiUAnu2S8104ZFi9Whre7HMTCfc/KDawdrpOB9a?=
 =?us-ascii?Q?/kr3lLYNNIxPO/RYNNSOZcP21miksCE81KCPxF+C247tXaT+AfOeXstRfb9h?=
 =?us-ascii?Q?PzMs5OrKyPqUt/ryHVteOgrs4zfDf4+qodLkfYp1EOIi7nV32VvOjx8hNx7P?=
 =?us-ascii?Q?iqQ+jHfO9RABN8QzFaPGb5sRHOcKt7sdLx9HZ8QhSoh7koMUWSMnIdKyWQdP?=
 =?us-ascii?Q?uamOR3g4/+br4PCyjpBiaQ25QoXoIFoEvapdW2CF8euy6g880RGAL1pQ3Aq3?=
 =?us-ascii?Q?Czki/WuN6cJlFfz4PYFBiwIwnptlFL6Y5IxXdohzFjH9UAZ4mX9kk0CRNikE?=
 =?us-ascii?Q?MxglqcMdogc7DuEa5pP76qaRwPnrxAML5jQCGXp4URfl7IhLZrcORq3nDmUx?=
 =?us-ascii?Q?DHx5aVgWQC/vcfrJzkbAOPjf/LRt0puET2Q1s8kmttwQG+mxg8hNYl3VB8HN?=
 =?us-ascii?Q?jxmFzbXZ9Mdih4ilOYSamra5SToFDXZ94F9Xni7oU4Pbd7H+TlgNbQP+pCbN?=
 =?us-ascii?Q?90Gf1CnOe1486BUJEbYdSbjTdaFQLfMrcM2GCRo/vbpsLQwsdzQNmDTONmuw?=
 =?us-ascii?Q?vy092FyojByX6TpnwNbWhW8tAKVXaj4MBNtjIBN5ZKZAz5gVS4n1hTYjWlyR?=
 =?us-ascii?Q?uTR3v81gwoGSCIOusvRvwLzFFS1meFtq1H6iE0DWtuPq1kYL3oiuCzkvlUPL?=
 =?us-ascii?Q?T0yy5bj9mnrA+eKXiDR9L5zDJwINQyw10WA9RMiifYQKkhdfqDzAAJVdfVat?=
 =?us-ascii?Q?X+QXFt9EOkwzKmTjuFOJR6RtRVtndK65kdUThfz0KWPtITClFQe4UkUnJ19U?=
 =?us-ascii?Q?t8eIZkjydz4rouW56vkjNXBnnUmDBVUtQ3IQAGE4lRG+8NHdKq0Y7HUbzkPw?=
 =?us-ascii?Q?E/J5Dp9S4kAo2kCetV7wFnaaQxiWsRpVQwuVhdFWLj2dQDRjCZqVENBGT+yZ?=
 =?us-ascii?Q?em2+/FlDbwTKeNjEpyVXjNnPHf78yN15UbeOBprUdNPGDaLCqGr65aQ3rwny?=
 =?us-ascii?Q?yl2E6WmtRQXIcEFcKzAlISPo8uPSL6EK5MB4AHN8k66vDrHxSxR51ROt/RUD?=
 =?us-ascii?Q?ekeM8WiY64ngEnrsk+kKdxzZsxkkn3dpk+SUD/WMJMqQvuCJNEaVM/uL+UP1?=
 =?us-ascii?Q?3hsbAQtx/vwJg60KK4vDlT+RU2gafXX5wL/YADFRLWB3MQhp8KkhnN9YPok6?=
 =?us-ascii?Q?eygtc78LPVdDqg7icgE1Q/9v7HWQDKrlt0KXpm+AqkyX9JbKfLfAJYYXKPGI?=
 =?us-ascii?Q?I5hW4ob82KC1/1/jPP/hyzFIL5KAInIcBXfciqU9U6pvpoJDppjziasrH11q?=
 =?us-ascii?Q?8twjJaQYGcM8Uc4dG3+BQLRtJh5AYzVk1xYidGc+9ieFFTj6T7sIvmKCBpxI?=
 =?us-ascii?Q?yZthFUgvqhqHZlaO3oUOXqtg9BG14hNaYPYr1+N0hSi7kAuzR5ukksftWzUh?=
 =?us-ascii?Q?di9MhVgnZRB/nUJPONm8TqbdPg8VrJK42k+kHP0ExCXXGIN3KSbkE29SmZKE?=
 =?us-ascii?Q?V+wXEV9H+Qh9KPdfP1f2O+yjEPBHrib15lLS?=
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 Jun 2025 00:00:39.3734
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 30f70a3c-2007-424c-494e-08dda87b003e
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:
	SJ5PEPF000001E8.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB6187

Allow the hwdom to access the console, and to access physical
information about the system.

xenconsoled can read Xen's dmesg.  If it's in hwdom, then that
permission would be required.

SYSCTL_physinfo is mainly to silence xl messages:

$ xl list
libxl: error: libxl_utils.c:818:libxl_cpu_bitmap_alloc: failed to retrieve the maximum number of cpus

Signed-off-by: Jason Andryuk 
---
This is not strictly needed.
---
 xen/common/sysctl.c     |  2 +-
 xen/include/xsm/dummy.h | 14 ++++++++++++--
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index c2d99ae12e..89d5176f4d 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -42,7 +42,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
     if ( op->interface_version != XEN_SYSCTL_INTERFACE_VERSION )
         return -EACCES;
 
-    ret = xsm_sysctl(XSM_PRIV, op->cmd);
+    ret = xsm_sysctl(XSM_OTHER, op->cmd);
     if ( ret )
         return ret;
 
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 477fadaefd..5e806dc241 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -188,8 +188,18 @@ static XSM_INLINE int cf_check xsm_domctl(
 
 static XSM_INLINE int cf_check xsm_sysctl(XSM_DEFAULT_ARG int cmd)
 {
-    XSM_ASSERT_ACTION(XSM_PRIV);
-    return xsm_default_action(action, current->domain, NULL);
+    XSM_ASSERT_ACTION(XSM_OTHER);
+    switch ( cmd )
+    {
+    case XEN_SYSCTL_readconsole:
+        return xsm_default_action(XSM_HW_PRIV, current->domain, NULL);
+    case XEN_SYSCTL_physinfo:
+        if ( is_hardware_domain(current->domain) )
+            return xsm_default_action(XSM_HW_PRIV, current->domain, NULL);
+        fallthrough;
+    default:
+        return xsm_default_action(XSM_PRIV, current->domain, NULL);
+    }
 }
 
 static XSM_INLINE int cf_check xsm_readconsole(XSM_DEFAULT_ARG uint32_t clear)
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 00:07:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 00:07:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011255.1389631 (Exim 4.92)
	(envelope-from )
	id 1uP8zt-0008AT-Pk; Wed, 11 Jun 2025 00:07:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011255.1389631; Wed, 11 Jun 2025 00:07: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 1uP8zt-0008AM-Mo; Wed, 11 Jun 2025 00:07:17 +0000
Received: by outflank-mailman (input) for mailman id 1011255;
 Wed, 11 Jun 2025 00:07: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 1uP8zr-0008AF-Ht
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 00:07:16 +0000
Received: from mail-10630.protonmail.ch (mail-10630.protonmail.ch
 [79.135.106.30]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 04582a3d-4658-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 02:07:09 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 04582a3d-4658-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1749600427; x=1749859627;
	bh=jaLJ79BvQJaBvTtiM9Elp0dvx6sjx1xkBHzCm9ge+Rk=;
	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=ml2nTtQF8sL3Maq/Tt9nI5z1+dvImHHyZmjzZ3llYzw34HdJRxyGq3Kt+TDzEi3my
	 QVvOOV6RszTGfHz59W7d69B/2wAI6HplPKJEHMdyfIhmxLypym2Le6LUlQKC19O5zH
	 Jx1JVdo7CW+xgUAZOuLeSg4imBsd0q4Yjn3wsCS/cTIffhr7EsFmFzuvukCTPpjsNs
	 8zxca0cGBU36+cbMqX/a/SVMN/XdWYdmRpkzzO5DDoYVVD8SoOTk9tpeX0+QteAk6X
	 Gs1SuyEh+cxD9rjoawlT+xkgVtHweMYyNZGG3PmLp92WYrgpEbT4bE/wUDbMwDJQY3
	 4J0PP4HsQrgMA==
Date: Wed, 11 Jun 2025 00:07:00 +0000
To: Jan Beulich 
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 2/2] xen/console: unify printout behavior for UART emulators
Message-ID: 
In-Reply-To: 
References: <20250606201102.2414022-1-dmukhin@ford.com> <20250606201102.2414022-3-dmukhin@ford.com> 
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: b531e9a38685d23f8c2392f03c58e829a1ec2011
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 10, 2025 at 10:21:40AM +0200, Jan Beulich wrote:
> On 06.06.2025 22:11, dmkhn@proton.me wrote:
> > From: Denis Mukhin 
> >
> > If virtual UART from domain X prints on the physical console, the behav=
ior is
> > updated to (see [1]):
> > - console focus in domain X: do not prefix messages;
> > - no console focus in domain X: prefix all messages with "(dX)".
>=20
> While, as indicated (much) earlier, I can see why omitting the prefix
> may make sense for the domain having input focus, ...
>=20
> > --- a/xen/drivers/char/console.c
> > +++ b/xen/drivers/char/console.c
> > @@ -740,7 +740,17 @@ static long guest_console_write(XEN_GUEST_HANDLE_P=
ARAM(char) buffer,
> >          if ( is_hardware_domain(cd) )
> >          {
> >              /* Use direct console output as it could be interactive */
> > +            char prefix[16] =3D "";
> > +            struct domain *consd;
> > +
> > +            consd =3D console_get_domain();
> > +            if ( consd !=3D cd )
> > +                snprintf(prefix, sizeof(prefix), "(d%d) ", cd->domain_=
id);
> > +            console_put_domain(consd);
> > +
> >              nrspin_lock_irq(&console_lock);
> > +            if ( prefix[0] !=3D '\0' )
> > +                console_send(prefix, strlen(prefix), flags);
> >              console_send(kbuf, kcount, flags);
> >              nrspin_unlock_irq(&console_lock);
> >          }
>=20
> ... this, aiui, is a behavioral change for the non-dom0less case, where
> Dom0 output will suddenly also gain the prefix. Which I don't think is
> wanted: Switching focus between Xen and Dom0 should remain unaffected
> in this regard.

This change ensures that dom0 traces aren't mixed with domU traces when dom=
U
has input focus, or with Xen traces when the administrator is in the diagno=
stic
console.

Also, this can be used in the non-interactive tests (e.g. XTF).

>=20
> Jan
>=20



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 00:10:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 00:10:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011261.1389642 (Exim 4.92)
	(envelope-from )
	id 1uP92r-0001Cw-70; Wed, 11 Jun 2025 00:10:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011261.1389642; Wed, 11 Jun 2025 00:10:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uP92r-0001Cp-3p; Wed, 11 Jun 2025 00:10:21 +0000
Received: by outflank-mailman (input) for mailman id 1011261;
 Wed, 11 Jun 2025 00:10: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 1uP92p-0001Cj-Rt
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 00:10:19 +0000
Received: from mail-24417.protonmail.ch (mail-24417.protonmail.ch
 [109.224.244.17]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 749b7ab8-4658-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 02:10:17 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 749b7ab8-4658-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1749600616; x=1749859816;
	bh=4k2/rtVBqWmO8ALzV5sZST8mlZxcVLEGjugepK8Ge4M=;
	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=C06D2xadvXe5qZEzy79s8CIvi/UooHQPllD5H0XEB+aeHESuzTY7XhGqrF6JYw8uk
	 ggWXEvDPCG97QzqcIm75VSm5tuF0Hb9r56+IUY8ydCnZfQlBLpZN1cTzw1FAsHjty4
	 /174Ki2h8tJPSGNV5cfOyWCPF/h3xzKYCnTgw5L5n8mNHp7ExeyfhYN/gMBEVe9QMY
	 ecAVZSg/bisAQpUlmmTRMvg7NojVAXJRfLO0X1K3wA4sKUaKeXmdszOe+cu4WizGtp
	 B5GSaRycYMfz4T5GgLgUQ+y2KarfLYsk6qowWeq96DWpJFOy7zB40gNivlmfjqZftj
	 LSo52c3LofZAQ==
Date: Wed, 11 Jun 2025 00:10:11 +0000
To: Jan Beulich 
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v1 2/2] xen/console: unify printout behavior for UART emulators
Message-ID: 
In-Reply-To: <8585aaa1-65fc-44cf-822b-d69429d81020@suse.com>
References: <20250531000417.81750-1-dmukhin@ford.com> <20250531000417.81750-3-dmukhin@ford.com> <71318dd2-0724-4c2a-9786-40b676411e56@suse.com>  <8585aaa1-65fc-44cf-822b-d69429d81020@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 5f9b343467aaed7604d63be29835ad90f693172f
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 05, 2025 at 08:15:15AM +0200, Jan Beulich wrote:
> On 05.06.2025 02:57, dmkhn@proton.me wrote:
> > On Wed, Jun 04, 2025 at 12:48:05PM +0200, Jan Beulich wrote:
> >> On 31.05.2025 02:04, dmkhn@proton.me wrote:
> >>> --- a/xen/arch/x86/hvm/hvm.c
> >>> +++ b/xen/arch/x86/hvm/hvm.c
> >>> @@ -577,7 +577,7 @@ static int cf_check hvm_print_line(
> >>>      if ( (cd->pbuf_idx =3D=3D (DOMAIN_PBUF_SIZE - 1)) || (c =3D=3D '=
\n') )
> >>>      {
> >>>          cd->pbuf[cd->pbuf_idx] =3D '\0';
> >>> -        guest_printk(cd, XENLOG_G_DEBUG "%s\n", cd->pbuf);
> >>> +        guest_printk(cd, "%s\n", cd->pbuf);
> >>>          cd->pbuf_idx =3D 0;
> >>>      }
> >>
> >> Why this and ...
> >>
> >>> @@ -755,7 +765,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_=
PARAM(char) buffer,
> >>>              else
> >>>              {
> >>>                  cd->pbuf[cd->pbuf_idx] =3D '\0';
> >>> -                guest_printk(cd, XENLOG_G_DEBUG "%s%s\n", cd->pbuf, =
kbuf);
> >>> +                guest_printk(cd, "%s%s\n", cd->pbuf, kbuf);
> >>>                  cd->pbuf_idx =3D 0;
> >>>              }
> >>
> >> ... this change? There's no compensation for it ...
> >>
> >>> @@ -1013,12 +1023,21 @@ void printk(const char *fmt, ...)
> >>>      va_end(args);
> >>>  }
> >>>
> >>> +/*
> >>> + * Print message from the guest on the diagnostic console.
> >>> + * Prefixes all messages w/ "(dX)" if domain X does not own physical=
 console
> >>> + * focus.
> >>> + */
> >>>  void guest_printk(const struct domain *d, const char *fmt, ...)
> >>>  {
> >>>      va_list args;
> >>> -    char prefix[16];
> >>> +    char prefix[16] =3D "";
> >>> +    struct domain *consd;
> >>>
> >>> -    snprintf(prefix, sizeof(prefix), "(d%d) ", d->domain_id);
> >>> +    consd =3D console_get_domain();
> >>> +    if ( consd !=3D d )
> >>> +        snprintf(prefix, sizeof(prefix), "(d%d) ", d->domain_id);
> >>> +    console_put_domain(consd);
> >>>
> >>>      va_start(args, fmt);
> >>>      vprintk_common(fmt, args, prefix);
> >>
> >> ... here afaics, so it looks like you're undermining rate-limiting of
> >> those messages.
> >
> > I droppped behavior change for I/O debug port on x86 and HYPERVISOR_con=
sole_io
> > hypercall.
> >
> > But my understanding is that all guest debugging facilities, if enabled=
, should
> > not be rate-limited.
>=20
> I certainly disagree there. How much rate limiting to apply to guest outp=
ut is a
> matter of the guest_loglvl=3D command line option. Its default settings a=
re the way
> they are for a reason.

Oh, I see!
Thanks for clarification!

>=20
> Jan
>=20



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 05:23:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 05:23:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011289.1389652 (Exim 4.92)
	(envelope-from )
	id 1uPDw9-0002Hy-D3; Wed, 11 Jun 2025 05:23:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011289.1389652; Wed, 11 Jun 2025 05: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 1uPDw9-0002Hg-7P; Wed, 11 Jun 2025 05:23:45 +0000
Received: by outflank-mailman (input) for mailman id 1011289;
 Wed, 11 Jun 2025 05: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 1uPDw8-0002Ha-5o
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 05:23:44 +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 3d278590-4684-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 07:23:42 +0200 (CEST)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-450cb2ddd46so36711025e9.2
 for ; Tue, 10 Jun 2025 22:23:42 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b419:d0bf:1423:db44:9404?
 (p200300cab734b419d0bf1423db449404.dip0.t-ipconnect.de.
 [2003:ca:b734:b419:d0bf:1423:db44:9404])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45326f3cf0fsm1102215e9.8.2025.06.10.22.23.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 22:23:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3d278590-4684-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749619422; x=1750224222; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=6e/6gqfZhP4cRkQrjpT/xeY16qenFE0pb27RUmfH1xU=;
        b=Mludi6J2vpwohRaRbKCKYLLjoYF0+aEqfJC4f3uEWqAKA23g4dlaEzFbg485A7zK8s
         mN3Nz1ZJDHWT15lrU5cinLbnUVmEeRGaQTP8eu9iPXMWRrEyVeL3VFivSYeXE48Kb57p
         8JBNxzYqEwVbEWJMffCZwaET0k4RYvZtBft97k/EYHArU+95XXewFDAjVdguV/588PqH
         aKcJ9FIK/cRwxUNYEhHT09G15UMnRZYYXKQEpLYs2TJjcb5lpGqviqJqctIH8R6JtiTl
         zHvCAtSvd03n4qqRuBwA3Plfo3m/Dy5WObi+QKCfKI+gJI9WOUGCyZk9ED/Ct5rfl8Yq
         cSlw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749619422; x=1750224222;
        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=6e/6gqfZhP4cRkQrjpT/xeY16qenFE0pb27RUmfH1xU=;
        b=S9QgVjdGs+JnO3dNLcftna56dJNde+Bw0WemL/3gXlEhUJSSrCcHkx+zNKC8Tv4EEn
         tjV1T+NlU/igl1Wg2It/zUh06WhicF5763OZnZVdUvBD5MiPcD26F6kZofBT9r6OWl6U
         87XGYy8bLo3h+Vl1uZ67EaWJwmgbb3YkPUUPfmYen+v020EGibU/SuJvtFLe5bThKB1z
         EFfU1v+8Aw+1zF6uqG2kDTHkAbI9r9m6JputbxaELSAQHn5qwn+g3HxBg14m4dO65b6J
         3Vo3YIxsGsOfRS8cc5FEfTeWQfQ7JHfaCgyQjsrig8JfPOGm+lr1xEospe+2CgkqU/nb
         vI/w==
X-Forwarded-Encrypted: i=1; AJvYcCW/HeetTcH+QHsxWxfmfQe+8ciig7G7YlzqtwZcJOAlf44ExAOyAbQur2sGJ7glO0h1j6ro1+VsD/M=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyoLyReq0JBV3rT0l0Zvez+SOLOQToZWmogSYQ6R9nkL6o8teqH
	LNODbcfktA76q6B/2SMnk4goVfeLVghTj3OhFsijxGPU30JuqcgYrCKzr1EnGlwCYg==
X-Gm-Gg: ASbGncuCDNNRuPd0CUf6ZMqkzePzUZV7irRYiolQWc0S67vRQyjCRM+5V7O59eaq7WG
	6AbQsPiNiOfJ+j3TNG/PDWihg5zIchYYfVH3+jbA8grQb25TOkHFw3GVQTXmimDdKLZb5I7UZmp
	GTOwn0emKFQkD8wn/OzuHslKLPEOmjU/qw6esJG5T+5lC5AbBZz6Zzkm91HdIv+pHR64iljDWja
	I4ScWZTDcL4a+VW+rkdsnOzd5Wp0TU4ihwkYQTRstbSgwAh+8lXUBb02eH3smrzCOX5K96J346D
	lAL0pFHgj32OcSjh25pTK1U1fEAHu8+DHSj531YeEcFIGOX3gvSW9y4Wn/xOAUhc2HuVARucNJr
	QYWrNWDFd0W+NAzwYE28cXfQ0Dr60WJ3vivGJkjQQLdibHRaZTuEbNQ/xJBdXneKOG8OtDALkRL
	ejYRrQDh00qUTXLCGmV5eP
X-Google-Smtp-Source: AGHT+IELHaHtO7+uzpOM8NUK0BY2CD9uXomFLsiUZZlqg3wj105p4rfGgJEZMDnU6IP50RSkeqeeRQ==
X-Received: by 2002:a05:600c:474c:b0:453:c39:d0c2 with SMTP id 5b1f17b1804b1-453248ca5c8mr11717425e9.24.1749619422027;
        Tue, 10 Jun 2025 22:23:42 -0700 (PDT)
Message-ID: <6ac8ffbc-5bd3-4bea-9ade-f31710747291@suse.com>
Date: Wed, 11 Jun 2025 07:23:40 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7] xen/arm: pci: introduce PCI_PASSTHROUGH Kconfig option
To: Stewart Hildebrand 
Cc: Rahul Singh ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Andrew Cooper ,
 Stefano Stabellini ,
 xen-devel@lists.xenproject.org
References: <20250610174635.203439-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: <20250610174635.203439-1-stewart.hildebrand@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.06.2025 19:46, Stewart Hildebrand wrote:
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -258,6 +258,16 @@ config PARTIAL_EMULATION
>  
>  source "arch/arm/firmware/Kconfig"
>  
> +config PCI_PASSTHROUGH
> +	bool "PCI passthrough" if EXPERT
> +	depends on ARM_64
> +	select HAS_PCI
> +	select HAS_VPCI
> +	select HAS_VPCI_GUEST_SUPPORT

What about HAS_PASSTHROUGH? Seeing that being selected by MMU, what about
that connection here?

Selecting HAS_VPCI shouldn't really be necessary; HAS_VPCI_GUEST_SUPPORT
does that for you already. (I further wonder whether HAS_VPCI wouldn't
in turn better select HAS_PCI.)

> +	default n

This is unnecessary (redundant) and would hence better be omitted.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 05:26:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 05:26:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011294.1389661 (Exim 4.92)
	(envelope-from )
	id 1uPDzD-0002pt-Nu; Wed, 11 Jun 2025 05:26:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011294.1389661; Wed, 11 Jun 2025 05:26: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 1uPDzD-0002pm-LQ; Wed, 11 Jun 2025 05:26:55 +0000
Received: by outflank-mailman (input) for mailman id 1011294;
 Wed, 11 Jun 2025 05:26: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 1uPDzC-0002pa-OT
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 05:26:54 +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 aeb9cfe7-4684-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 07:26:53 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a536ecbf6fso2753659f8f.2
 for ; Tue, 10 Jun 2025 22:26:53 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b419:d0bf:1423:db44:9404?
 (p200300cab734b419d0bf1423db449404.dip0.t-ipconnect.de.
 [2003:ca:b734:b419:d0bf:1423:db44:9404])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a5323c0819sm13885567f8f.45.2025.06.10.22.26.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 22:26:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: aeb9cfe7-4684-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749619612; x=1750224412; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=9cFIQX1ckg+EPJjekRYxRBF1854Xd4wUJXPfSnoLX1g=;
        b=LXQCNzAarmg32cpEahUWJjDRzQS7yGAtnMjUmCKyhhnaLjTOTClo9xiUxKUllnzw1/
         3/O1e+rL4YrYGfAwQUwUoQf1/gBqDF76ueNumfBv5fWdqt5u4cI13Cna+pu5ab22NBZp
         hqdRKrgNfwhg2b2p1Kahig5j16Wox0wsId6WcnEjiXUgEDLak/8UidthsnjHtlrzEorX
         IRV+Yh8wLYTCbWu+GiBkciHd2rQmfRM2YiJiCtFjVBbLs+Cu2M3MUVGNUCM5cyhclr1q
         IPsdk+ERBtuIQWwv1dYDJ/MZwwK2a66fmkVokbGVP3NMjg/jJ8dMkCSTSjyqj1WSS+An
         grrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749619612; x=1750224412;
        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=9cFIQX1ckg+EPJjekRYxRBF1854Xd4wUJXPfSnoLX1g=;
        b=cQKbtO1NEIhnn+WrFvbuZmocmaq8U/eTdlmelH5UbTaRwdETVsCYikVoNg5mWOfODk
         WIRxCKFA1TF8FwCWahN4dthHElZUl/ZkVaMDU++X1VjKciQOu8CkZC+P4FFMH0DmGc+2
         Q3toyVHlDyr51z3lLsEkJulhz5atBUsIpZCkworBA2fIDC3ih/jPv9Sn5836h+2H6Ljw
         IcGjY2Y/fyPWY7pmoZ/050nGanDZ78+xXcVZSBPK5Vy+b2j/fkRQJ6Y5w946ZkRqtpSs
         sDC5RTKvEBmQmD/rCzvMGlFbzI4e5WacyCuNvoPuJ9gDD6UUQEy16BHkGdFrVBrx16Kf
         t8Tg==
X-Forwarded-Encrypted: i=1; AJvYcCXGIGcxsj6SGQcdTe+OdQF9fMwNOVymXrQ55dO3JsARp/4XTPGG0tlBeDhcRF/ehlzCLJmryO46xNY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwjxvF5a4RcnlUhAQxo+81mhqJja8iG2nJw/2kcKyb490cjWpX3
	Uzj+oUC7C3B+fRa5FFSrd2Tx/7zV0FJml2v3m85J8tNzOzhYfNQNWlkI1JL8LfU8vg==
X-Gm-Gg: ASbGncsHzEhYqz+c//fkVRxUUf6gAMkDwqpl5DHHPzolnwNtD0/bsjlj+67acxyy7Uf
	8HW5PJLyS0bLNcyMejtEm7kEmXhv2cB/wZOt3adOTKeiwFQSLdJis2ohFxiBE53mPBpDLTAyTix
	6UAweGrrtKiXdM3OU67fZYOGpRGUC6A7JJb5SZuD8Xw/4ucOV8BZV9H8KUeX2aN/GbhetukdOdh
	qziSIL4Cu3FbOrGUkgqgMo69jW9w/6SlEyXsAD9TGdKD37WI8OtJH+ccvwGvJb3n5zFf+pWQV9o
	OtYOMI913kbJLlPXT9OTuCNNj1FpjWTcRZyWJdLMYJYccQUm1iy3ev7P2lwwuwfUDtZkUO6WuyU
	+7SycPLfDChnjFCWZkoUrVRkjPEZCm7d7/6NGs5wY0xZFPcqPlW6ARh0fMhOwv6lC1WH0Dtm4Ri
	rTFa0eYAGpwkoUfWe2hUXe
X-Google-Smtp-Source: AGHT+IE100Z1ddsGq9Y2/LPisjm07X57Zptw60MbsV9iM8ORxSZ5r5gmDL3KAZ4VRZ7TZlf+87mNVg==
X-Received: by 2002:a05:6000:400f:b0:3a5:2875:f986 with SMTP id ffacd0b85a97d-3a5586e8d38mr972210f8f.44.1749619612433;
        Tue, 10 Jun 2025 22:26:52 -0700 (PDT)
Message-ID: <31085457-a33d-4bd5-b6d7-edc0c358ee6c@suse.com>
Date: Wed, 11 Jun 2025 07:26:51 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1] xen/console: group pbuf under console field
To: dmkhn@proton.me
Cc: anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com,
 roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com,
 xen-devel@lists.xenproject.org, Andrew Cooper 
References: <20250606194937.2412579-1-dmukhin@ford.com>
 
 <7f965335-68d9-4da5-8ce3-db68583db9a2@citrix.com> 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 10.06.2025 20:02, dmkhn@proton.me wrote:
> On Tue, Jun 10, 2025 at 12:24:57PM +0100, Andrew Cooper wrote:
>> Separately, 200 is a silly and arbitrary number.  Furthermore the
>> allocation is unconditional, despite the fact that in !VERSBOSE builds,
>> domUs can't use this facility.  Also, where's the input buffer?
> 
> Thanks!
> 
> I will try to address those under individual changes.
> 
> re: arbitrary number: Will bumping the buffer size to the next power of 2 ==
> 256 work?

Any other number would work, but would be as arbitrary. Since the buffer is
dynamically allocated, one non-arbitrary aspect of the selection may want to
be to make the number such that including allocation overhead it's an even
multiple of cache line size.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 05:35:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 05:35:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011299.1389671 (Exim 4.92)
	(envelope-from )
	id 1uPE7b-0004Uv-Gl; Wed, 11 Jun 2025 05:35:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011299.1389671; Wed, 11 Jun 2025 05:35: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 1uPE7b-0004Uo-EE; Wed, 11 Jun 2025 05:35:35 +0000
Received: by outflank-mailman (input) for mailman id 1011299;
 Wed, 11 Jun 2025 05:35: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 1uPE7a-0004Ui-EX
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 05:35:34 +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 e250111d-4685-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 07:35:29 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3a365a6804eso3819750f8f.3
 for ; Tue, 10 Jun 2025 22:35:29 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b419:d0bf:1423:db44:9404?
 (p200300cab734b419d0bf1423db449404.dip0.t-ipconnect.de.
 [2003:ca:b734:b419:d0bf:1423:db44:9404])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a5323b653dsm14234262f8f.39.2025.06.10.22.35.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 22:35:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e250111d-4685-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749620128; x=1750224928; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=V3brsPWTEDu0RaHKwOcYmvWaS0b6yWvh3OrKsmioVpY=;
        b=ff85+UXCnsvmRfWuSaT2TWIPup9ECtvfPbTZIMvQU9WVm54YPcmDQSfCvtghjPL8BT
         ksPQKAvaj2do4PjX4QS/qaY2ch9BxXWukEv5D0YNIADpgGV9JdI6Ca6fyBkuBkI0Ov4g
         N60Qt/GABP/f6pMFYHv1kyfLkvsca9DyTx71qEz3BelPbKICeFFXxo625ttyMSyhPRxh
         grCRKtE+dPpUZ0t2go7TzTIOIAX7ANXN0fSWJXDqICo28BUw8j8p/rHYd8qmFcXybMPY
         5eFMrBDAhAHycxl1aOs9iALl7UkJwskwR93ZQ/OuZaFO5dIhGunMuL/XWvJfZIxsZ/eT
         z9Wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749620128; x=1750224928;
        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=V3brsPWTEDu0RaHKwOcYmvWaS0b6yWvh3OrKsmioVpY=;
        b=Lj352Ag2ltmWL/Cr0DlsgXNziEF1tfL2iOaihL7wncq4hSxDIdZNxwlSfRBEBt6l9f
         vX8b4SpmMuyx1l81fWQCz0HFxSMiOuoB3UV+EcvoWaIFqNGy/yMm39RMfV3DF8q0kNO/
         tzrJQm6Q+hPP+sU09K/p6s/r4kzbzi/nfipnOZrsK/tl40eTRFHJ7gotn+hcl7Eq8pLB
         WAaIXbS/WC/Fx8htxeK+MQlbAaSV/3YNPcqqAwRBOPw3cQpfNFS0xglm/gd8cPs2QoWR
         jyRTtUruZenBACvmKA/1oKZzPCm4hqLfETFxm41Fgs0dbeSbQgSR2IKi3J3UIEgBnTBX
         rsjA==
X-Forwarded-Encrypted: i=1; AJvYcCVOZxgYaAMc+CWkBDGu8FblPeTASLrX1mzNwHns7Sz+3OChrr6d1TaPUlXDF1U/97kS0agLEcDSO8A=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxppjYYxb1Rl8OrJZYTo3CgTcaiEEeiR4PnQniNXrflcdxWAC9u
	7sG+rljUVbhzjD+HkW6VmnyaseJcDrwgu90JTbEe6wvofQ6VW9U9eSg+BBo4QAtfCw==
X-Gm-Gg: ASbGncuxKzJO8m27sYB31spJUf9lPgYgkcrBetlRmFSsoSzVczPPjFSi70xmZRpkIzQ
	71qsg4vCIUU0J07FyRyxvdBOMKUkEdckrciGD8MbD5Uu0oO5HWJNnMyg0lYyfVxkvmjWS8bYG5L
	kaDwm4YHow2BKgIQrtC9WshQ4vG0LG3o7FDCNd9v5/oo6Ag5bcI41aVzYh659MY7Di19bQncB1t
	rtR+2cmCVFOFBPZugpd0CHqwdkhufR4sdb+S+hSg3vsc16EBIqb29mTg0Fzx81FpYJ6/xBFAcZc
	8B35GO6XNrN7GQz/qruY6unsuOC92rTknNIf/HxgRupcRyFj1Tz9LeeVRLxJYFFaM8T0usiahta
	cUPNXdkokc5bvGe2THquc/8At2rJXPFaiQqxOx86smoS6pcd26wDmEmN5Izvy1BGSQ8M6WtECoZ
	+BZKOoHW6VfiuVPaxM684+
X-Google-Smtp-Source: AGHT+IG/57VMqqUUIEyILTVi5t+z3CgCv1A2iklfezP2C/9YNIQmiBDFsLUxXqUJl3t35PurUZE09g==
X-Received: by 2002:a05:6000:4313:b0:3a5:2653:7308 with SMTP id ffacd0b85a97d-3a5586f450cmr1166272f8f.57.1749620128539;
        Tue, 10 Jun 2025 22:35:28 -0700 (PDT)
Message-ID: 
Date: Wed, 11 Jun 2025 07:35:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 06/12] x86/hyperlaunch: obtain cmdline from device tree
To: Jason Andryuk 
Cc: "Daniel P. Smith" ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini ,
 Bertrand Marquis , Denis Mukhin
 , Alejandro Vallejo ,
 xen-devel@lists.xenproject.org
References: <20250429123629.20839-1-agarciav@amd.com>
 <20250429123629.20839-7-agarciav@amd.com>
 <59f37fcc-9226-46c5-8dc8-7bd2100d8f59@amd.com>
 <02ffa9cf-b5cd-431a-834a-a11bbf310196@suse.com>
 <03be429c-063d-4467-91e7-7ef2e148a2fb@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: <03be429c-063d-4467-91e7-7ef2e148a2fb@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 10.06.2025 19:39, Jason Andryuk wrote:
> 
> 
> On 2025-06-10 02:56, Jan Beulich wrote:
>> On 09.06.2025 19:07, Jason Andryuk wrote:
>>> On 2025-04-29 08:36, Alejandro Vallejo wrote:
>>>> From: "Daniel P. Smith" 
>>>>
>>>> Add support to read the command line from the hyperlaunch device tree.
>>>> The device tree command line is located in the "bootargs" property of the
>>>> "multiboot,kernel" node.
>>>>
>>>> A boot loader command line, e.g. a grub module string field, takes
>>>> precendence over the device tree one since it is easier to modify.
>>>>
>>>> Signed-off-by: Daniel P. Smith 
>>>> Signed-off-by: Jason Andryuk 
>>>> Signed-off-by: Alejandro Vallejo 
>>>> Reviewed-by: Denis Mukhin 
>>>> ---
>>>
>>>> diff --git a/xen/common/domain-builder/fdt.c b/xen/common/domain-builder/fdt.c
>>>> index cbb0ed30a2..dabe201b04 100644
>>>> --- a/xen/common/domain-builder/fdt.c
>>>> +++ b/xen/common/domain-builder/fdt.c
>>>> @@ -219,6 +219,12 @@ static int __init fdt_process_domain_node(
>>>>                printk(XENLOG_INFO "  kernel: multiboot-index=%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] )
>>>
>>> The logic is incorrect - it should be:
>>>
>>>              if ( !bd->kernel->cmdline_pa ||
>>>                   !((char *)__va(bd->kernel->cmdline_pa))[0] )
>>>
>>> If there is no cmdline_pa (which happens with the "reg" property) or the if there is a 0-length string, then check the DT for bootargs.
>>
>> Even that sounds bogus to me: There's a difference between "no command line"
>> and "empty command line".
> 
> Yes, you have a point.  The difficulty is grub always provides a NUL terminated string, so Xen can't differentiate the two.

Which may call for either special-casing GrUB, or at least calling out that
behavior in the comment. (Ideally we'd still have a way to distinguish
between both cases, but likely we'll need to resort to documenting that some
dummy option will need adding to tell "none" from [intended to be] empty.)

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 05:39:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 05:39:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011310.1389681 (Exim 4.92)
	(envelope-from )
	id 1uPEB3-00056Y-2Q; Wed, 11 Jun 2025 05:39:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011310.1389681; Wed, 11 Jun 2025 05:39:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPEB2-00056R-Vl; Wed, 11 Jun 2025 05:39:08 +0000
Received: by outflank-mailman (input) for mailman id 1011310;
 Wed, 11 Jun 2025 05:39: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 1uPEB1-00056L-AL
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 05:39: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 639e7a2d-4686-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 07:39:06 +0200 (CEST)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-451d6ade159so53290815e9.1
 for ; Tue, 10 Jun 2025 22:39:06 -0700 (PDT)
Received: from ?IPV6:2003:ca:b734:b419:d0bf:1423:db44:9404?
 (p200300cab734b419d0bf1423db449404.dip0.t-ipconnect.de.
 [2003:ca:b734:b419:d0bf:1423:db44:9404])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4531fe8526bsm22513885e9.0.2025.06.10.22.39.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Jun 2025 22:39:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 639e7a2d-4686-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749620345; x=1750225145; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=D6QadpmVbw8/okvhf3T+sWyjH3XDcO5qMgmXqpsDaPc=;
        b=d5GpHuz21KcxUbOj13mPY7VVnKcaCcTVYO3eMheSu6nBlDtwUoXkOHT4pdUQeIe60x
         5ZyWMLOLHe4leUhXtfnZ6zXQ48xyckrE7oH/z1XPlsS6XP/OkZelLjvvsIKR6kbPlPiQ
         6FRAo1V4nDEWxG/cGvmN/YK8cd7w325AAfsFdvUGv0rriNob+Zpathb3ZMT4Vxgoy3ID
         92Jew5in+IjydCeODUmAAY7E+hic/dxcZVytElIUsbIcaf4mP7eiCckzwyx1zVRqUKrk
         5R8crhVuN/p4AeBn4Nib8X0S9nc1vs9r6GthEqXfQUXVutI+HGIT2nrct4Utiz0FJkYB
         AXFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749620345; x=1750225145;
        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=D6QadpmVbw8/okvhf3T+sWyjH3XDcO5qMgmXqpsDaPc=;
        b=FrBZWyVqmetL33e6Cm36hOTMCCA+ZiAmjmdAd0L+LbHeHtuHTpgmhr8fTjV2ydlOmG
         0TbbnJTgEhp4MvBwQe9iTUFexK6JzWgOG1hnmNEnBUtjC6hk1YuUBsOXmtCu339haoaI
         Qz55zznnyqgwUuK8vy1orn4LrGdz1ZyejPrqEuHoRnBLMKrHccar3bCl4XfNKF8FS/uL
         SVz8f2cbP9d7hgt2zt3o8lx4/4Cu1XrDBpoGu6vYdLdfQwNGUZbj2cV/6DiwY4MYX48B
         eaXnBVlD4gNH9r+g4Etd3UMbXdyhmXDOHSfV0HgQRJ00yV8gUXaHmbb4lHuno/AztdjG
         DqUg==
X-Forwarded-Encrypted: i=1; AJvYcCWWpMbcakVtXROf4YIjPDyfRNXHLRMFl3RDg8GsAHeVAIh1FPOb1XYWEK73ZKBNshEZOD43T2xs2cw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzOYtk4T8P+tdJM3D4fvQMoPhVGmwsIMrYpNvLKrh4QRkB1KVHE
	P8vPkf08tvpF6RAPgiopCfJWW5J7VlTu9wdoePaB/tkfmmgRpuEOXYrgUwOIrKDRNw==
X-Gm-Gg: ASbGncu9+NzgqUdLo9JLwvuPWqtx8i0TGZ1ObGoWXMpuWnDKauT4IoNmzdAnlKLxsak
	xNKhGqduBAnHzpi84kFRjoJ+NpD7ir5ojqWdNYZgB1sajXUEu3LGqEQu0NZS8zcZk1fpBmTcLHN
	rXYwqmNvkFna19/rR5WHPiNcMB+K8WkemSqhSchmZlg1oQa9qpsq8S2ME88ayPMxdyhOwnAkT1o
	Nzp9MJuEb9wnhJ5q06sURArlLnShK7akjxcBMs8PTG7ZGpIteYoT9JIJjrFIt5rJznABXzQ/XLg
	SnvP66yPUaquDyNyDZ3Z2vJHxyZ6CooGc4mHO03+uFujpFu7rVardxx9wIMOfmlagXMv4xswF4X
	BnB1BZemMTCruy5wcjKqdaCkilfn/yZa9uZaZZfby2VEwY4DHoQMTL37B7nzDjUj8INi+Ee/IuA
	EultjVsOKl0isXG1lx8nYU
X-Google-Smtp-Source: AGHT+IGz5XwF6KqRmna1XGpf8GEGFBU/QG8Ku7rAdIzhiXWW9sHTDltWgJ/tZnDLAZwWglK5Rj0sRQ==
X-Received: by 2002:a05:600c:a11:b0:43d:77c5:9c1a with SMTP id 5b1f17b1804b1-45324878fc2mr14065445e9.4.1749620345539;
        Tue, 10 Jun 2025 22:39:05 -0700 (PDT)
Message-ID: 
Date: Wed, 11 Jun 2025 07:39:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/2] xen/console: unify printout behavior for UART
 emulators
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org,
 dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250606201102.2414022-1-dmukhin@ford.com>
 <20250606201102.2414022-3-dmukhin@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: 7bit

On 11.06.2025 02:07, dmkhn@proton.me wrote:
> On Tue, Jun 10, 2025 at 10:21:40AM +0200, Jan Beulich wrote:
>> On 06.06.2025 22:11, dmkhn@proton.me wrote:
>>> From: Denis Mukhin 
>>>
>>> If virtual UART from domain X prints on the physical console, the behavior is
>>> updated to (see [1]):
>>> - console focus in domain X: do not prefix messages;
>>> - no console focus in domain X: prefix all messages with "(dX)".
>>
>> While, as indicated (much) earlier, I can see why omitting the prefix
>> may make sense for the domain having input focus, ...
>>
>>> --- a/xen/drivers/char/console.c
>>> +++ b/xen/drivers/char/console.c
>>> @@ -740,7 +740,17 @@ 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 */
>>> +            char prefix[16] = "";
>>> +            struct domain *consd;
>>> +
>>> +            consd = console_get_domain();
>>> +            if ( consd != cd )
>>> +                snprintf(prefix, sizeof(prefix), "(d%d) ", cd->domain_id);
>>> +            console_put_domain(consd);
>>> +
>>>              nrspin_lock_irq(&console_lock);
>>> +            if ( prefix[0] != '\0' )
>>> +                console_send(prefix, strlen(prefix), flags);
>>>              console_send(kbuf, kcount, flags);
>>>              nrspin_unlock_irq(&console_lock);
>>>          }
>>
>> ... this, aiui, is a behavioral change for the non-dom0less case, where
>> Dom0 output will suddenly also gain the prefix. Which I don't think is
>> wanted: Switching focus between Xen and Dom0 should remain unaffected
>> in this regard.
> 
> This change ensures that dom0 traces aren't mixed with domU traces when domU
> has input focus, or with Xen traces when the administrator is in the diagnostic
> console.

That's what the description also tries to describe, yet I still regard it as
a behavioral regression in (at least) the described scenario. The hardware
domain presently not having (d0) prefixed to its output is deliberate imo,
not accidental.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 05:55:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 05:55:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011317.1389692 (Exim 4.92)
	(envelope-from )
	id 1uPER0-0007wo-BH; Wed, 11 Jun 2025 05:55:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011317.1389692; Wed, 11 Jun 2025 05:55: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 1uPER0-0007wh-7b; Wed, 11 Jun 2025 05:55:38 +0000
Received: by outflank-mailman (input) for mailman id 1011317;
 Wed, 11 Jun 2025 05:55: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 1uPEQy-0007wa-AJ
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 05:55:36 +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 b13932be-4688-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 07:55:35 +0200 (CEST)
Received: by mail-lf1-x12d.google.com with SMTP id
 2adb3069b0e04-5535652f42cso6389931e87.2
 for ; Tue, 10 Jun 2025 22:55:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b13932be-4688-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749621335; x=1750226135; 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=VEull6Y2dKdn7HXksCZ+pxPpbHPUoR6qac/gwemfvgY=;
        b=gf6weRgnB+Eia3sioFts/u6ZpzoKySHOI8+eFrrl8KqS1aUiFhlu9uwYRrWERUYIcB
         Mg+Wwew8jCL2qbtI2IjDaKBk4evrtKd08F2rWjhBgPvX+JORBdx969/5sIEGj2XPto3a
         MRFyTYw67+4et3XuEMUj/kCr0WjGla3udqHKXC8BFqVN66e8g3Y3MxRAqqeo7mHAnV/d
         CXisdeCdWo5/l5Lgvh4PsTU3HH5IV30ZlFJpdEXoUEw261Yk6XrYN0U7chL26PQgfG59
         eMnNZwDgGeAZM6Os+FkKW9+Nizb1rawvZ7xZ4G84se7vb54jFjSh+LKjwQUYKkIxjZaj
         tQZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749621335; x=1750226135;
        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=VEull6Y2dKdn7HXksCZ+pxPpbHPUoR6qac/gwemfvgY=;
        b=qVKho82LE8W6XCVclj9kr9ogOLc1Sc8+6m/VshOrXsro2xkCEMSXovSiQu3xeZPJqc
         +TmMk8mySJ3u/ehCnPAhcgi2ldHZJiTm1stwkbiuHuTpi9GPmPKjZcgr9WblFgwESDv4
         I56yfbwoyz6MWKTOKkRIaE5XHAxeFSymR6c8Ju342H6AftnVx/ljvdkbq8iPwk/AEVOz
         PtdlVdXThD7wWZGuIG4Q/AwEE5YORZk1UH2BuRpMkVPUKf6cvx0VkeNui0b34N7wqOyg
         bTFdXtdK5BiIOJqKotwFbeTP4bqyVkpeWORvKOS6MyakrhS5LJoPQbXUmJLtP+6nGa+6
         cs+A==
X-Forwarded-Encrypted: i=1; AJvYcCXY0czXwtEYLO29a19SylrpfV5lTV+GeQf0rH7mPnt8OYovtTGxhjVG9JFvq8cV+4gfhens0CjSGXI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxPYnFNQGpFMoY4aIbey1Nyz1psW1VwnVawaPk+vwMJAJdHy9D3
	yxDGdO6oso6uLVItQlU8R0gQTSBWfgVZr4iu5Vek5FGo2DZHS7wyM0NcjPM/EixKbUtFVUSyTUf
	QIPWN4Gc/TsJvZEgCpwqxKIuvF6O0c6c=
X-Gm-Gg: ASbGncv4yBPqzQVIZXXv2d7cUmc4DRgoACv4JFw+vIIFySEMnW0HWFeWnPkRdiCSONd
	ljQQP0d7BJbwQj57Xz7EqRxJdPaSXrt8bwbLFqY2LgaXhwhIcGf58fRfBOH2t4hhgCE7lIT3lcJ
	3pfrt2jqyS2+EnEsErLzszQkrgGGLL52EMfnPfeUpI8w==
X-Google-Smtp-Source: AGHT+IErScmgyst1hOgqidcJMyBjKM/5nzEwiAgXH2L+nlqO63ErIaFSpju92ErtkSG2sc3XXXL++dfq+bQl766+AOQ=
X-Received: by 2002:a05:6512:3da2:b0:553:1f8e:f27f with SMTP id
 2adb3069b0e04-5539c14a367mr628083e87.30.1749621334267; Tue, 10 Jun 2025
 22:55:34 -0700 (PDT)
MIME-Version: 1.0
References:  
 <4bfe5a9a-6128-4760-9121-46b0d9bd6789@suse.com>
In-Reply-To: <4bfe5a9a-6128-4760-9121-46b0d9bd6789@suse.com>
From: Mykola Kvach 
Date: Wed, 11 Jun 2025 08:55:23 +0300
X-Gm-Features: AX0GCFsA7nHtLNXJdIHn-uO4hMdCRIvzuptexlLYI6Sc4TaBOdW7iUggxtLLmg8
Message-ID: 
Subject: Re: [PATCH v4][PART 2 01/10] xen/x86: Move freeze/thaw_domains to
 common code
To: Jan Beulich 
Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Anthony PERARD , Michal Orzel , 
	Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 2, 2025 at 12:20=E2=80=AFPM Jan Beulich  wro=
te:
>
> On 02.06.2025 11:04, Mykola Kvach wrote:
> > From: Mirela Simonovic 
> >
> > The freeze_domains and thaw_domains functions are currently defined
> > in x86-specific suspend code. These functions are also useful on other
> > architectures, such as ARM, for implementing system-wide suspend and
> > resume functionality.
> >
> > This patch moves these functions to common code so they can be reused
> > across architectures.
> >
> > Signed-off-by: Mirela Simonovic 
> > Signed-off-by: Saeed Nowshadi 
> > Signed-off-by: Mykyta Poturai 
> > Signed-off-by: Mykola Kvach 
>
> On the assumption that the transient Misra violation is okay:

Perhaps wrapping it with CONFIG_SYSTEM_SUSPEND would be sufficient.

> Acked-by: Jan Beulich 
>
> Jan

Mykola


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 07:03:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 07:03:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011329.1389702 (Exim 4.92)
	(envelope-from )
	id 1uPFUi-0007uw-WE; Wed, 11 Jun 2025 07:03:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011329.1389702; Wed, 11 Jun 2025 07:03:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPFUi-0007up-TF; Wed, 11 Jun 2025 07:03:32 +0000
Received: by outflank-mailman (input) for mailman id 1011329;
 Wed, 11 Jun 2025 07: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 1uPFUh-0007uj-Hq
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 07:03:31 +0000
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com
 [2a00:1450:4864:20::133])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2d5b75f2-4692-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 09:03:29 +0200 (CEST)
Received: by mail-lf1-x133.google.com with SMTP id
 2adb3069b0e04-5534edc6493so6858282e87.1
 for ; Wed, 11 Jun 2025 00:03:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2d5b75f2-4692-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749625408; x=1750230208; 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=ujgy7Gbrz/173YmjEEnqBPX/cXzBjjcdnr4b3E4lqJU=;
        b=K+unagJ7vuawfQrtx/ZYs59yRACvCK6uL1hhKkF1FIcplWaN4gpLja/IhvI0bHfwNQ
         DhBGjwXN5OwMtO9M0rFvRri9VzAbj3nGISmC8It08OGe9KN1FskKbDme5XBSc8DO1Cls
         GlOs32XtB/XzTMw7jKDaX5a6BMMdgTyNDV1cjYYHqDpTN3VGNdGYGOKgQ7CXBVPX9Kjo
         /kjPTpNbOg14Gw6PWEeHKH6Gg5Rtl/EM/zpvJEU5TrwsfAJt3sFLQNbjpqNRmwbzGGbt
         ShsHE3hPWzH+iQs/ySQ7oXo8HkycS9e/NKtmdDqMA3PXgp+oJWC5s5O0oJRo/CqDLHob
         OXmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749625408; x=1750230208;
        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=ujgy7Gbrz/173YmjEEnqBPX/cXzBjjcdnr4b3E4lqJU=;
        b=S42xI5AUqthJvkacWWRkww4XNLWGsWpBSSRrK5BJzd/Kt+VwpFKjs7ACaqKYDDGxdZ
         zRBc7lGWei1ISR6AYaYn1ebmyD4R3dWDLRHyLXHziQr6ac3qEBhAGC2I1swb8A0hUkGl
         ow+11KBSiOpcIDC8YuSTX5iPMGjhe/HnhquxTdRb51ibkSViHTUOK2hw43tAY+z+MeW4
         SKOaNK8oUAf/uYowZNX9HArzKuu+CyZvjQHQ9IlnSOshoSmew8/wfwYTm/YVjIxZA99p
         HoqkUdZPIDbT7sGSoVt+NGxMm0zjqPX6qC2LTkIz3TFH4bJKi1AfmmSxXzahbm++YfiE
         JPYw==
X-Gm-Message-State: AOJu0Yz7i5irZebswks2iifdKKxr56mMY2GMj/7HxVgrK4AfLWpl5PMA
	DCsM1G40x5buluKDbzZiKrVSFPUk/4UMFmB+VvTwY34Uoh2y4cCVrkenb/1ystWBipQZXbskvtm
	iHUt/68pLvFgriqkqNni7kX9HKS1/1M8=
X-Gm-Gg: ASbGncuIxe4LyHNeE/SP6yRt/zYup+V0rXg40MTZS7kTQlBCNwrGbkbuqljMz6RHAAW
	aWVQE1KebOHk11fP7oWKSfxC+ezcf0LVfG8nGUgDfcTJkKPKdtQ7Ju6sNWO+qyZ+A3vAzGQr0f4
	vj5GYXJS6v3KRt2zLry5VeURjWqEBzXZ2fmz9I1cTh5g==
X-Google-Smtp-Source: AGHT+IFfS5+uZQ7i5lHVxLbGVswzkR0NapbIvsTF64xkC9Drj/IWt5n9L4TN9tQQ+FIvrABRWV/h93XI2d4tnlMP4SA=
X-Received: by 2002:a05:6512:2397:b0:553:3486:1d9b with SMTP id
 2adb3069b0e04-5539d512569mr384160e87.30.1749625408035; Wed, 11 Jun 2025
 00:03:28 -0700 (PDT)
MIME-Version: 1.0
References: <7364a71d-2604-49ca-bab7-d21544d49b10@gmail.com>
In-Reply-To: <7364a71d-2604-49ca-bab7-d21544d49b10@gmail.com>
From: Mykola Kvach 
Date: Wed, 11 Jun 2025 10:03:17 +0300
X-Gm-Features: AX0GCFs_I1MpbooeAr9L2LPbVGw9PkWi6kUDq20LXnJnijCeg9RkxBB4J5TuxLY
Message-ID: 
Subject: Re: Xen 4.21 Development Update [May]
To: Oleksii Kurochko 
Cc: xen-devel@lists.xenproject.org, 
	Ayan Kumar Halder , Mykyta Poturai , 
	Juergen Gross , Teddy Astie , 
	Bertrand Marquis , Luca Fancellu , 
	Jason Andryuk , Alejandro Vallejo , 
	Sergii Dmytruk , Penny Zheng , 
	=?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= , 
	Roger Pau Monne , Andrew Cooper , dmkhn@proton.me, 
	"Daniel P. Smith" , Grygorii Strashko , 
	Alejandro Vallejo , "committers@xenproject.org" , 
	Community Manager 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Oleksii,

On Mon, Jun 2, 2025 at 7:37=E2=80=AFPM Oleksii Kurochko
 wrote:
>
> Hello everyone,
>
> This email only tracks big items for xen.git tree. Please reply for
> items you
> would like to see in 4.21 so that people have an idea what is going on an=
d
> prioritise accordingly.
>
> You're welcome to provide description and use cases of the feature you're
> working on.
>
> =3D Timeline =3D
>
> As there hasn't been any feedback on the proposed timeline shared here:
> https://lore.kernel.org/xen-devel/666e3f49-2f92-4828-8897-8579832bcaa2@gm=
ail.com/T/#u
>
> We can proceed with the suggested timeline as the release schedule for
> Xen 4.21.
> I've updated the Xen 4.21 Release Notes with this schedule, which can now=
 be
> accessed via the RN link:
>    https://xenbits.xen.org/docs/unstable/support-matrix.html
>
> =3D Updates =3D
>
> The following items ( the links for them could be found int the list belo=
w )
> were moved to completed:
>    [since May 6 - Jun2]:
>      * Hypervisor:
>        - tools: remove qemu-traditional
>      * Arm:
>        - PCI devices passthrough on Arm, part 3
>      * x86:
>        - xen: cache control improvements
>    [since 4.20 relese - May 6]:
>      * Hypervisor:
>        - Move parts of Arm's Dom0less to common code
>        - remove libxenctrl usage from xenstored
>      * Arm:
>        - Enable early bootup of Armv8-R AArch32 systems
>      * x86:
>        - x86/HVM: emulation (MMIO) improvements
>      * RISC-V:
>        - RISC-V some preinit calls.
>        - Fixes for UBSAN & GCOV support for RISC-V.
>
> Some new items added:
>   [since May]
>      * x86:
>       - Allow x86 to unflatten DTs
>       - hyperlaunch: move remaining pvh dom0 construction
>       - x86/hyperlaunch: introduce concept of core domains
>       - Confidential computing and AMD SEV support
>      * Arm:
>       - SMMU handling for PCIe Passthrough on ARM
>       - xen/arm: scmi: introduce SCI SCMI SMC multi-agent support
>       - Add initial Xen Suspend-to-RAM support on ARM64
>      * RISC-V:
>       - introduce p2m functionality
>   [since 4.20 release]
>      * Hypervisor:
>        - tools: remove qemu-traditional
>        - Physical address hypercall ABI ("HVMv2")
>        - xen: Untangle mm.h
>        - xen: introduce CONFIG_SYSCTL
>        - Add support for exact-node memory claims
>        - Several CI cleanups and improvements, plus yet another new runne=
r
>      * x86:
>        - x86/EFI: prevent write-execute sections
>        - x86: Trenchboot Secure Launch DRTM (Xen)
>        - Hyperlaunch device tree for dom0 (v6)
>        - amd-cppc CPU Performance Scaling Driver (v4)
>        - Hyperlaunch domain builder
>        - kexec: add kexec support to Mini-OS
>        - xen: cache control improvements (should be moved to "Hypervisor"=
?)
>        - x86: generate xen.efi image with no write-execute sections
>        - x86/asm: cleanups after toolchain baseline upgrade
>      * Arm:
>        - Add support for R-Car Gen4 PCI host controller (v4)
>        - FF-A VM to VM support (v5)
>        - First chunk for Arm R82 and MPU support (v4)
>        - ARM split hardware and control domains (v5)
>        - MPU mm subsistem skeleton
>      * RISC-V:
>        - introduce basic UART support and interrupts for hypervisor mode
>
> * Full list of items : *
>
> =3D Projects =3D
>
> =3D=3D Hypervisor =3D=3D
>
> * xen/console: cleanup console input switch logic (v1 -> v5)
>    - Denis Mukhin
>    -
> https://lore.kernel.org/xen-devel/20250530231841.73386-1-dmukhin@ford.com=
/
>    - https://patchew.org/Xen/20250530231841.73386-1-dmukhin@ford.com/
>
> * xen: introduce CONFIG_SYSCTL (v3 -> v4)
>    -  Penny Zheng
>    -
> https://lore.kernel.org/xen-devel/20250528091708.390767-1-Penny.Zheng@amd=
.com/
>    - https://patchew.org/Xen/20250528091708.390767-1-Penny.Zheng@amd.com/
>
> * Physical address hypercall ABI ("HVMv2")
>    - Teddy Astie
>    -
> https://lore.kernel.org/xen-devel/cover.1744981654.git.teddy.astie@vates.=
tech/
>
> * xen: Untangle mm.h
>    -  Andrew Cooper
>    -
> https://lore.kernel.org/xen-devel/20250312174513.4075066-1-andrew.cooper3=
@citrix.com/
>    -
> https://patchew.org/Xen/20250312174513.4075066-1-andrew.cooper3@citrix.co=
m/
>
> * Add support for exact-node memory claims
>    -  Alejandro Vallejo
>    -
> https://lore.kernel.org/xen-devel/20250314172502.53498-1-alejandro.vallej=
o@cloud.com/
>    -
> https://patchew.org/Xen/20250314172502.53498-1-alejandro.vallejo@cloud.co=
m/
>
> * Several CI cleanups and improvements, plus yet another new runner
>    - Marek Marczykowski-G=C3=B3recki
>    -
> https://lore.kernel.org/xen-devel/cover.7da1777882774486a13e6f39ff4a2096f=
6b7901e.1744028549.git-series.marmarek@invisiblethingslab.com/
>    -
> https://patchew.org/Xen/cover.7da1777882774486a13e6f39ff4a2096f6b7901e.17=
44028549.git-series.marmarek@invisiblethingslab.com/
>
> *  Remove the directmap (v5)
>    -  Alejandro Vallejo
>    -
> https://lore.kernel.org/xen-devel/20250108151822.16030-1-alejandro.vallej=
o@cloud.com/
>    -
> https://patchew.org/Xen/20250108151822.16030-1-alejandro.vallejo@cloud.co=
m/
>
> *  automation: Refresh the remaining Debian containers (v2)
>    -  Javi Merino
>    -
> https://lore.kernel.org/xen-devel/cover.1730743077.git.javi.merino@cloud.=
com/T/#m5d9acb7cf5db3c2be3d6527de14b69b07812314e
>
> *  GRUB: Supporting Secure Boot of xen.gz (v1)
>    -  Ross Lagerwall
>    -
> https://patchew.org/Xen/20240313150748.791236-1-ross.lagerwall@citrix.com=
/
>
> *  MSI-X support with qemu in stubdomain, and other related changes (v8)
>    -  Marek Marczykowski-G=C3=B3recki
>    -
> https://lore.kernel.org/xen-devel/cover.33fb4385b7dd6c53bda4acf0a9e91748b=
3d7b1f7.1715313192.git-series.marmarek@invisiblethingslab.com/
>    -  Only automation patch left to be reviewed/merged.
>
> *  [RFC] Introduce xenbindgen to autogen hypercall structs (v1)
>    -  Alejandro Vallejo
>    -
> https://patchew.org/Xen/20241115115200.2824-1-alejandro.vallejo@cloud.com=
/
>
> *  Introduce NS8250 UART emulator (v2)
>    -  Denis Mukhin
>    -
> https://patchew.org/Xen/20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com/
>
> =3D=3D=3D x86 =3D=3D=3D
>
> * Allow x86 to unflatten DTs
>    - Alejandro Vallejo
>    -
> https://lore.kernel.org/xen-devel/20250530120242.39398-1-agarciav@amd.com=
/
>    - https://patchew.org/Xen/20250530120242.39398-1-agarciav@amd.com/
>
> * hyperlaunch: move remaining pvh dom0 construction (v2)
>    - Daniel P. Smith
>    -
> https://lore.kernel.org/xen-devel/20250515131912.5019-1-dpsmith@apertusso=
lutions.com/
>
> * x86/hyperlaunch: introduce concept of core domains (v2)
>    - Daniel P. Smith
>    -
> https://lore.kernel.org/xen-devel/20250515131951.5594-1-dpsmith@apertusso=
lutions.com/
>
> * Confidential computing and AMD SEV support
>    - Teddy Astie
>    - https://patchew.org/Xen/cover.1747312394.git.teddy.astie@vates.tech/
>    -
> https://lore.kernel.org/xen-devel/cover.1747312394.git.teddy.astie@vates.=
tech/
>
> * x86/efi: Fix booting when NX is disabled (v1 -> v2)
>    - Andrew Cooper
>    -
> https://patchew.org/Xen/20240722101838.3946983-1-andrew.cooper3@citrix.co=
m/
>    -
> https://lore.kernel.org/xen-devel/20240722101838.3946983-1-andrew.cooper3=
@citrix.com/
>
> * x86/asm: cleanups after toolchain baseline upgrade (v1 -> v2)
>    - Denis Mukhin
>    -
> https://lore.kernel.org/xen-devel/20250403182250.3329498-1-dmukhin@ford.c=
om/
>    - https://patchew.org/Xen/20250403182250.3329498-1-dmukhin@ford.com/
>
> * amd-cppc CPU Performance Scaling Driver (v4 -> v5)
>    - Penny Zheng
>    -
> https://lore.kernel.org/xen-devel/20250527084833.338427-1-Penny.Zheng@amd=
.com/
>    - https://patchew.org/Xen/20250414074056.3696888-1-Penny.Zheng@amd.com=
/
>
> * x86: Trenchboot Secure Launch DRTM (Xen) (v1 -> v3)
>    - Sergii Dmytruk
>    - https://patchew.org/Xen/cover.1745172094.git.sergii.dmytruk@3mdeb.co=
m/
>    -
> https://lore.kernel.org/xen-devel/cover.1748611041.git.sergii.dmytruk@3md=
eb.com/
>
> * x86/EFI: prevent write-execute sections
>    - Roger Pau Monne 
>    -
> https://lore.kernel.org/xen-devel/20250401130840.72119-1-roger.pau@citrix=
.com/
>
> * Hyperlaunch device tree for dom0 (v6)
>    - Alejandro Vallejo
>    - https://patchew.org/Xen/20250429123629.20839-1-agarciav@amd.com/
>    -
> https://lore.kernel.org/xen-devel/20250429123629.20839-1-agarciav@amd.com=
/
>
> * Hyperlaunch domain builder
>    - Daniel P. Smith
>    -
> https://patchew.org/Xen/20250419220820.4234-1-dpsmith@apertussolutions.co=
m/
>
> * kexec: add kexec support to Mini-OS
>    - Juergen Gross 
>    -
> https://lore.kernel.org/xen-devel/20250321092451.17309-1-jgross@suse.com/
>
> * x86: generate xen.efi image with no write-execute sections
>    - Roger Pau Monne
>    -
> https://lore.kernel.org/xen-devel/20250318173547.59475-1-roger.pau@citrix=
.com/
>
> *  Expose consistent topology to guests (v7)
>    -  Alejandro Vallejo
>    -
> https://patchew.org/Xen/20241021154600.11745-1-alejandro.vallejo@cloud.co=
m/
>
> *  Boot modules for Hyperlaunch (v9)
>    -  Daniel P. Smith
>    -
> https://patchew.org/Xen/20241115131204.32135-1-dpsmith@apertussolutions.c=
om/
>
> *  Address Space Isolation FPU preparations (v2->v3)
>    -  Alejandro Vallejo
>    -
> https://patchew.org/Xen/20250110132823.24348-1-alejandro.vallejo@cloud.co=
m/
>
> *  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
>
> *  x86emul: misc additions (v7)
>    -  Jan Beulich
>    - https://patchew.org/Xen/3a25cd59-e1cb-4bfc-b868-fb11599d22f5@suse.co=
m/
>
> *  x86: support AVX10 (v3)
>    -  Jan Beulich
>    - https://patchew.org/Xen/516b7f9a-048e-409d-8a4e-89aeb8ffacc4@suse.co=
m/
>
> *  VT-d: SATC handling; ATS: tidying (v2)
>    -  Jan Beulich
>    - https://patchew.org/Xen/64b028be-2197-4951-ae5b-32f9eabfa84a@suse.co=
m/
>
> *  x86: parallelize AP bring-up during boot (v1)
>    -  Krystian Hebel
>    -
> https://lore.kernel.org/xen-devel/cover.1699982111.git.krystian.hebel@3md=
eb.com/
>
> *  x86/spec-ctrl: IBPB improvements (v4)
>    -  Jan Beulich
>    - https://patchew.org/Xen/06591b64-2f05-a4cc-a2f3-a74c3c4a76d6@suse.co=
m/
>
> *  Move some boot code from assembly to C (v2)
>    -  Frediano Ziglio
>    -
> https://patchew.org/Xen/20241122093358.478774-1-frediano.ziglio@cloud.com=
/
>
> *  x86: memcpy() / memset() (non-)ERMS flavors plus fallout (v4)
>    -  Jan Beulich
>    - https://patchew.org/Xen/14b65231-b83b-43fb-bbcf-dec5c07d285b@suse.co=
m/
>
> *  amd-pstate CPU Performance Scaling Driver (v1)
>    -  Penny Zheng
>    - https://patchew.org/Xen/20241203081111.463400-1-Penny.Zheng@amd.com/
>
> =3D=3D=3D ARM =3D=3D=3D
>
> * SMMU handling for PCIe Passthrough on ARM (v11)
>    - Mykyta Poturai
>    -
> https://lore.kernel.org/xen-devel/cover.1741958647.git.mykyta_poturai@epa=
m.com/
>    -
> https://patchew.org/Xen/cover.1748422217.git.mykyta._5Fpoturai@epam.com/
>
> * xen/arm: scmi: introduce SCI SCMI SMC multi-agent support
>    - Grygorii Strashko
>    -
> https://lore.kernel.org/xen-devel/20250311111618.1850927-1-grygorii_stras=
hko@epam.com/
>
> * Add initial Xen Suspend-to-RAM support on ARM64 (v4)
>    - Mykola Kvach
>    -
> https://lore.kernel.org/xen-devel/cover.1741164138.git.xakep.amatop@gmail=
.com/
>    - https://patchew.org/Xen/cover.1748848482.git.mykola._5Fkvach@epam.co=
m/

I'd like to propose including initial support for Suspend-to-RAM in Xen 4.2=
1.

This feature enables Xen and its guests to enter suspend state via
PSCI SYSTEM_SUSPEND. Xen suspend is triggered from the hardware domain.

Support is currently Experimental.

>
> * Add support for R-Car Gen4 PCI host controller (v4 -> v5)
>    - Mykyta Poturai
>    -
> https://lore.kernel.org/xen-devel/cover.1747820844.git.mykyta_poturai@epa=
m.com/
>    -
> https://patchew.org/Xen/cover.1747820844.git.mykyta._5Fpoturai@epam.com/
>
> * FF-A VM to VM support (v5 -> v6)
>    - Bertrand Marquis 
>    -
> https://lore.kernel.org/xen-devel/cover.1747925287.git.bertrand.marquis@a=
rm.com/
>    - https://patchew.org/Xen/cover.1747925287.git.bertrand.marquis@arm.co=
m/
>
> * First chunk for Arm R82 and MPU support (v4 -> v6)
>    - Luca Fancellu
>    -
> https://lore.kernel.org/xen-devel/20250523065406.3795420-1-luca.fancellu@=
arm.com/
>    - https://patchew.org/Xen/20250523065406.3795420-1-luca.fancellu@arm.c=
om/
>
> * ARM split hardware and control domains (v5)
>    - Jason Andryuk
>    -
> https://lore.kernel.org/xen-devel/20250416212911.410946-1-jason.andryuk@a=
md.com/
>    - https://patchew.org/Xen/20250416212911.410946-1-jason.andryuk@amd.co=
m/
>
> * MPU mm subsistem skeleton
>    - Luca Fancellu
>    -
> https://lore.kernel.org/xen-devel/20250312135258.1815706-1-luca.fancellu@=
arm.com/
>    - https://patchew.org/Xen/20250312135258.1815706-1-luca.fancellu@arm.c=
om/
>
> *  Add Virtio-PCI for dom0less on ARM (v1)
>    -  Edgar E. Iglesias
>    -
> https://lore.kernel.org/xen-devel/20240924162359.1390487-1-edgar.iglesias=
@gmail.com/T/#mfa148991b9408f223a079d4cef610244d5b04c2b
>    -
> https://patchew.org/Xen/20240924162359.1390487-1-edgar.iglesias@gmail.com=
/
>
> *  DOMCTL-based guest magic region allocation for 11 domUs (v4)
>    -  Henry Wang
>    - https://patchew.org/Xen/20240409045357.236802-1-xin.wang2@amd.com/
>
> =3D=3D=3D RISCV =3D=3D=3D
>
> * riscv: introduce basic UART support and interrupts for hypervisor mode
> (v2 -> v3)
>    -  Oleksii Kurochko
>    -
> https://lore.kernel.org/xen-devel/cover.1747843009.git.oleksii.kurochko@g=
mail.com/
>    -
> https://patchew.org/Xen/cover.1747843009.git.oleksii.kurochko@gmail.com/
>
> * xen/riscv: introduce p2m functionality (v1)
>    - Oleksii Kurochko
>    -
> https://lore.kernel.org/xen-devel/cover.1746805907.git.oleksii.kurochko@g=
mail.com/
>    -
> https://patchew.org/Xen/cover.1746805907.git.oleksii.kurochko@gmail.com/
>
> =3D=3D=3D PPC =3D=3D=3D
>
> *  Early Boot Allocation on Power (v5)
>    -  Shawn Anastasio
>    -
> https://lore.kernel.org/xen-devel/cover.1727388925.git.sanastasio@raptore=
ngineering.com/T/#m8cac91a93b56a359fa2d5f08596c4be61dca290d
>    -
> https://patchew.org/Xen/cover.1727388925.git.sanastasio@raptorengineering=
.com/
>
> =3D=3D Completed =3D=3D
>
> =3D=3D=3D Hypervisor =3D=3D=3D
>
> * tools: remove qemu-traditional
>    - Juergen Gross 
>    - https://lore.kernel.org/xen-devel/20250527132035.985-1-jgross@suse.c=
om/
>
> *  remove libxenctrl usage from xenstored (v8)
>    -  Juergen Gross
>    -
> https://lore.kernel.org/xen-devel/20250204113407.16839-1-jgross@suse.com/
>
> * xen/config.h: Move BITS_PER_* definitions from asm/config.h to
> xen/config.h
>    - Oleksii Kurochko
>    -
> https://lore.kernel.org/xen-devel/6b21fb046cf1c8ca760f5ad72fa3cc13b59c406=
9.1743092485.git.oleksii.kurochko@gmail.com/
>
> * Move parts of Arm's Dom0less to common code
>    -  Oleksii Kurochko
>    -
> https://patchew.org/Xen/cover.1746468003.git.oleksii.kurochko@gmail.com/
>    -
> https://lore.kernel.org/xen-devel/cover.1746468003.git.oleksii.kurochko@g=
mail.com/T/#t
>
> =3D=3D=3D x86 =3D=3D=3D
>
> * xen: cache control improvements
>    - Roger Pau Monne
>    -
> https://lore.kernel.org/xen-devel/20250506083148.34963-1-roger.pau@citrix=
.com/
>
> *  x86/HVM: emulation (MMIO) improvements (v3)
>    -  Jan Beulich
>    - https://patchew.org/Xen/729f7896-55b7-4b5b-a7e9-6eb0420e0b14@suse.co=
m/
>
> =3D=3D=3D ARM =3D=3D=3D
> *  PCI devices passthrough on Arm, part 3 (v16->v20->v21)
>    -  Stewart Hildebrand
>    -
> https://patchew.org/Xen/20250508104608.531079-1-stewart.hildebrand@amd.co=
m/
>    -
> https://lore.kernel.org/xen-devel/20250508104608.531079-1-stewart.hildebr=
and@amd.com/
>
> * Enable early bootup of Armv8-R AArch32 systems
>    - Ayan Kumar Halder
>    -
> https://lore.kernel.org/xen-devel/20250414164514.588373-1-ayan.kumar.hald=
er@amd.com/
>    -
> https://patchew.org/Xen/20250414164514.588373-1-ayan.kumar.halder@amd.com=
/
>
> =3D=3D=3D RISC-V =3D=3D=3D
>
> * RISC-V some preinit calls:
>    -  Oleksii Kurochko
>    -
> https://lore.kernel.org/xen-devel/4ddde60347edf6740fbc69b5739d099616f5b5f=
f.1743165791.git.oleksii.kurochko@gmail.com/
>
> * Fixes for UBSAN & GCOV support for RISC-V:
>    -  Oleksii Kurochko
>    -
> https://lore.kernel.org/xen-devel/9fbb5e1389b84bed2e95f99e4c383d0215c7a52=
4.1744889185.git.oleksii.kurochko@gmail.com/
>
> Have a good week!
>
> Best regards,
>   Oleksii
>

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 08:25:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 08:25:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011344.1389711 (Exim 4.92)
	(envelope-from )
	id 1uPGmC-0000oV-Vl; Wed, 11 Jun 2025 08:25:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011344.1389711; Wed, 11 Jun 2025 08:25: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 1uPGmC-0000oO-Sf; Wed, 11 Jun 2025 08:25:40 +0000
Received: by outflank-mailman (input) for mailman id 1011344;
 Wed, 11 Jun 2025 08:25: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 1uPGmB-0000oI-UB
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 08:25:40 +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 a54ff602-469d-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 10:25:34 +0200 (CEST)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-ade76b8356cso390028066b.2
 for ; Wed, 11 Jun 2025 01:25:34 -0700 (PDT)
Received: from smtpclient.apple ([46.149.103.11])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ade1dc37faesm845764366b.111.2025.06.11.01.25.30
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 11 Jun 2025 01:25:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a54ff602-469d-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1749630334; x=1750235134; 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=g3YMoULCZrxX5kCQIZXzNE7LlN8oVvvOPg1jTLfDmZc=;
        b=Sq/vbLHc7cgaKdRriA8U3d9PNRdH0tuQ1ZX+6HZxH4njjJIpwALxtU/wteb1zX2B1t
         sKaz8XG/xMjfH0RrqgyyCnNAu9Amg3TI527ZC1BwgiadXcBXmJfdDWnWvxJ1vlu11JQW
         U5i3iEpxAAwUb2WdahOq5azuxtAafVeW6clSg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749630334; x=1750235134;
        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=g3YMoULCZrxX5kCQIZXzNE7LlN8oVvvOPg1jTLfDmZc=;
        b=Ypf3+2kclsApzdj30/rqUuX0PPKvRo5tm7CesDDpUKLX4Y1q9G6nIK6+S91HtNQlSC
         ljYXtpkd+GlAL+8NquFHYeCAgQW3qKoqNdsvG/U5ZyrJ9pTaiMbwamVKbRNd5z3qJCNm
         wMPRmUDhqo1vkNHV9tvJj1ZrDOZsqf/musZh1RLkjADoA60d1wv5sjGwC8Mo6jdu1syM
         8VnxWwmuxNWiRl4wWHp/IUnhJNVbvGS1PKLpRBjawx0sKp6PMwcADq6n0EiIcFeRA7G5
         020Nt1QnDfuy3d0PejOUR/Wpy48004ykoAZ2jQDkFyZrSDEBpv9c4kdSh3YrLFrteAqd
         ll6g==
X-Gm-Message-State: AOJu0YxUHFbnN2UYeu6mJhbwy1frAnr68pXAComeucZpFmLTqu2/lMsX
	sRgrocFb81qLX1i8p8jM3uEIQw5oFujomZ/oIoHOGLckx3iIQqSPzS3I7xv4OWq/RhE=
X-Gm-Gg: ASbGnctTSDlWEBvzFc3rTDD2fwcZZPvHm+NRgOdpuhDnrIw7KESWO1tnIUJ/cd6EMYA
	Pj0sw9Pf8pGwtD6Foj5Op4oLoSebiRUJYwDtbcQpVeD0y4Up+HH/swsy8t6Aa11Ai0SVbfTE93l
	Kp9SO9zjFSL3L8LY2BjfootRd3235x6O3P65YbTspY8ohT2ov8mtfI9AMsD0uUaMgtrkXfCdVqS
	Ih2N9zTpvhCFYHgOncw0ONfb3jM4Ib8yAo3KAE9MeJGT0VTQmNAXCA7CwoBteXdBF6gzO8OwLXz
	DELkvWxyjA5gC6wQr3EawMxJ5iCj6IYeX/Z0Nj5rveKWDUdxf+ABL7JL+hONxy+bkCJLpAjnWaG
	r33Cg2TWFjdQ=
X-Google-Smtp-Source: AGHT+IH0Ef8L8cVSfGB8WXLJXRKNtVMQIh1jU41qsEgfwliE0qBeyJRh0LAdlovZ4gRbEZf1Ce/Nvw==
X-Received: by 2002:a17:907:1b1e:b0:ad2:3d34:e2ad with SMTP id a640c23a62f3a-ade8c76f194mr171177966b.26.1749630333881;
        Wed, 11 Jun 2025 01:25:33 -0700 (PDT)
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\))
Subject: Re: [PATCH 3/4] xen: Add DOMAIN_CAPS_DEVICE_MODEL &
 XEN_DOMCTL_CDF_device_model
From: Christian Lindig 
In-Reply-To: <20250610225737.469690-4-jason.andryuk@amd.com>
Date: Wed, 11 Jun 2025 09:25:18 +0100
Cc: xen-devel@lists.xenproject.org,
 Christian Lindig ,
 David Scott ,
 Anthony PERARD ,
 Andrew Cooper ,
 Michal Orzel ,
 Jan Beulich ,
 Julien Grall ,
 =?utf-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk ,
 "Daniel P. Smith" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20250610225737.469690-1-jason.andryuk@amd.com>
 <20250610225737.469690-4-jason.andryuk@amd.com>
To: Jason Andryuk 
X-Mailer: Apple Mail (2.3826.500.181.1.5)

Acked-by: Christian Lindig 

> On 10 Jun 2025, at 23:57, Jason Andryuk  wrote:
>=20
> To add more flexibility in system configuration add the new
> DOMAIN_CAPS_DEVICE_MODEL flag and XEN_DOMCTL_CDF_device_model.
>=20
> Thie new flag corresponds to allowing XSM_DM_PRIV for the domain.  =
This
> will enable running device model emulators (QEMU) from the assigne
> domain for multiple target domains.
>=20
> Stubdoms assign target allowing the stubdom to serve as the device
> model for a single domain.  This new flag allows the single domain to
> provide emulators for multiple guests.
>=20
> The specific scenario is a disaggregated system with the hardware =
domain
> providing device models for muitple guest domains.
>=20
> The OCaml code needs the flag added in as well.
>=20
> Signed-off-by: Jason Andryuk 
> ---
> tools/ocaml/libs/xc/xenctrl.ml          |  1 +
> tools/ocaml/libs/xc/xenctrl.mli         |  1 +
> xen/arch/arm/domain.c                   |  3 ++-
> xen/common/device-tree/dom0less-build.c |  3 +++
> xen/common/domain.c                     |  3 ++-
> xen/include/public/bootfdt.h            | 12 ++++++++++--
> xen/include/public/domctl.h             |  4 +++-
> xen/include/xen/sched.h                 |  9 +++++++++
> xen/include/xsm/dummy.h                 |  2 ++
> 9 files changed, 33 insertions(+), 5 deletions(-)
>=20
> diff --git a/tools/ocaml/libs/xc/xenctrl.ml =
b/tools/ocaml/libs/xc/xenctrl.ml
> index 2690f9a923..ef0c5dca2a 100644
> --- a/tools/ocaml/libs/xc/xenctrl.ml
> +++ b/tools/ocaml/libs/xc/xenctrl.ml
> @@ -70,6 +70,7 @@ type domain_create_flag =3D
>   | CDF_IOMMU
>   | CDF_NESTED_VIRT
>   | CDF_VPMU
> +  | CDF_DEVICE_MODEL
>=20
> type domain_create_iommu_opts =3D
>   | IOMMU_NO_SHAREPT
> diff --git a/tools/ocaml/libs/xc/xenctrl.mli =
b/tools/ocaml/libs/xc/xenctrl.mli
> index febbe1f6ae..c0156fa5c6 100644
> --- a/tools/ocaml/libs/xc/xenctrl.mli
> +++ b/tools/ocaml/libs/xc/xenctrl.mli
> @@ -63,6 +63,7 @@ type domain_create_flag =3D
>   | CDF_IOMMU
>   | CDF_NESTED_VIRT
>   | CDF_VPMU
> +  | CDF_DEVICE_MODEL
>=20
> type domain_create_iommu_opts =3D
>   | IOMMU_NO_SHAREPT
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 45aeb8bddc..12fda0762f 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -612,7 +612,8 @@ int arch_sanitise_domain_config(struct =
xen_domctl_createdomain *config)
>     unsigned int max_vcpus;
>     unsigned int flags_required =3D (XEN_DOMCTL_CDF_hvm | =
XEN_DOMCTL_CDF_hap);
>     unsigned int flags_optional =3D (XEN_DOMCTL_CDF_iommu | =
XEN_DOMCTL_CDF_vpmu |
> -                                   XEN_DOMCTL_CDF_xs_domain );
> +                                   XEN_DOMCTL_CDF_xs_domain |
> +                                   XEN_DOMCTL_CDF_device_model);
>     unsigned int sve_vl_bits =3D sve_decode_vl(config->arch.sve_vl);
>=20
>     if ( (config->flags & ~flags_optional) !=3D flags_required )
> diff --git a/xen/common/device-tree/dom0less-build.c =
b/xen/common/device-tree/dom0less-build.c
> index 3d503c6973..993ff32f5e 100644
> --- a/xen/common/device-tree/dom0less-build.c
> +++ b/xen/common/device-tree/dom0less-build.c
> @@ -884,6 +884,9 @@ void __init create_domUs(void)
>                 d_cfg.flags |=3D XEN_DOMCTL_CDF_xs_domain;
>                 d_cfg.max_evtchn_port =3D -1;
>             }
> +
> +            if ( val & DOMAIN_CAPS_DEVICE_MODEL )
> +                d_cfg.flags |=3D XEN_DOMCTL_CDF_device_model;
>         }
>=20
>         if ( dt_find_property(node, "xen,static-mem", NULL) )
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 153cd75340..ab2c8f864d 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -721,7 +721,8 @@ static int sanitise_domain_config(struct =
xen_domctl_createdomain *config)
>          ~(XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap |
>            XEN_DOMCTL_CDF_s3_integrity | XEN_DOMCTL_CDF_oos_off |
>            XEN_DOMCTL_CDF_xs_domain | XEN_DOMCTL_CDF_iommu |
> -           XEN_DOMCTL_CDF_nested_virt | XEN_DOMCTL_CDF_vpmu) )
> +           XEN_DOMCTL_CDF_nested_virt | XEN_DOMCTL_CDF_vpmu |
> +           XEN_DOMCTL_CDF_device_model) )
>     {
>         dprintk(XENLOG_INFO, "Unknown CDF flags %#x\n", =
config->flags);
>         return -EINVAL;
> diff --git a/xen/include/public/bootfdt.h =
b/xen/include/public/bootfdt.h
> index 86c46b42a9..c6b5afc76a 100644
> --- a/xen/include/public/bootfdt.h
> +++ b/xen/include/public/bootfdt.h
> @@ -25,7 +25,15 @@
> #define DOMAIN_CAPS_HARDWARE (1U << 1)
> /* Xenstore domain. */
> #define DOMAIN_CAPS_XENSTORE (1U << 2)
> -#define DOMAIN_CAPS_MASK     (DOMAIN_CAPS_CONTROL | =
DOMAIN_CAPS_HARDWARE | \
> -                              DOMAIN_CAPS_XENSTORE)
> +/*
> + * Device model capability allows the use of the dm_op hypercalls to =
provide
> + * the device model emulation (run QEMU) for other domains.  This is =
a
> + * subset of the Control capability which can be granted to the
> + * Hardware domain for running QEMU.
> + */
> +#define DOMAIN_CAPS_DEVICE_MODEL (1U << 3)
> +
> +#define DOMAIN_CAPS_MASK     (DOMAIN_CAPS_CONTROL  | =
DOMAIN_CAPS_HARDWARE | \
> +                              DOMAIN_CAPS_XENSTORE | =
DOMAIN_CAPS_DEVICE_MODEL )
>=20
> #endif /* __XEN_PUBLIC_BOOTFDT_H__ */
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index 5b2063eed9..2280489be2 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -66,9 +66,11 @@ struct xen_domctl_createdomain {
> #define XEN_DOMCTL_CDF_nested_virt    (1U << =
_XEN_DOMCTL_CDF_nested_virt)
> /* Should we expose the vPMU to the guest? */
> #define XEN_DOMCTL_CDF_vpmu           (1U << 7)
> +/* Allow domain to provide device model for multiple other domains */
> +#define XEN_DOMCTL_CDF_device_model   (1U << 8)
>=20
> /* Max XEN_DOMCTL_CDF_* constant.  Used for ABI checking. */
> -#define XEN_DOMCTL_CDF_MAX XEN_DOMCTL_CDF_vpmu
> +#define XEN_DOMCTL_CDF_MAX XEN_DOMCTL_CDF_device_model
>=20
>     uint32_t flags;
>=20
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index fe53d4fab7..9863603d93 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -1148,6 +1148,15 @@ static always_inline bool =
is_control_domain(const struct domain *d)
>     return evaluate_nospec(d->is_privileged);
> }
>=20
> +/* This check is for functionality specific to a device model domain =
*/
> +static always_inline bool is_dm_domain(const struct domain *d)
> +{
> +    if ( IS_ENABLED(CONFIG_PV_SHIM_EXCLUSIVE) )
> +        return false;
> +
> +    return evaluate_nospec(d->options & XEN_DOMCTL_CDF_device_model);
> +}
> +
> #define VM_ASSIST(d, t) (test_bit(VMASST_TYPE_ ## t, &(d)->vm_assist))
>=20
> static always_inline bool is_pv_domain(const struct domain *d)
> diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
> index d8df3f66c4..477fadaefd 100644
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -91,6 +91,8 @@ static always_inline int xsm_default_action(
>             return 0;
>         fallthrough;
>     case XSM_DM_PRIV:
> +        if ( is_dm_domain(src) )
> +            return 0;
>         if ( target && evaluate_nospec(src->target =3D=3D target) )
>             return 0;
>         fallthrough;
> --=20
> 2.49.0
>=20



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 08:26:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 08:26:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011349.1389723 (Exim 4.92)
	(envelope-from )
	id 1uPGmu-0001Gx-9H; Wed, 11 Jun 2025 08:26:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011349.1389723; Wed, 11 Jun 2025 08:26: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 1uPGmu-0001Gq-4b; Wed, 11 Jun 2025 08:26:24 +0000
Received: by outflank-mailman (input) for mailman id 1011349;
 Wed, 11 Jun 2025 08:26: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 1uPGms-0000oI-Ra
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 08:26:22 +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 c0422bcb-469d-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 10:26:19 +0200 (CEST)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-ad51ba0af48so134247966b.0
 for ; Wed, 11 Jun 2025 01:26:19 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ade1dc78f47sm841183766b.153.2025.06.11.01.26.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 01:26:18 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c0422bcb-469d-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749630379; x=1750235179; 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=D36TET5nPdbKBCA84GHWqEQE3SKs1YEmxDXH5hhaPbo=;
        b=HAXAQ8EASTktb8bHqiyvhqtiCO4u6Qc4rm2OG2MeLukzAfu5D+4a/Bvzj2c6mQ2VUg
         UM10S+km4rRGPOTF5vs8f00RqgeuIna+kCy02MszpMYllU2Lp5zroZJhtVhUVoUx4cRq
         N/+A+sFVumnvDWbIVLIbyeNSrrsvHL9j6+6N59SLt1FPCSU93aPAQ8qlpJV1Rg7gBTqa
         1d/zfwG7XjDZmy8eJc0nGWHXZuOmBMz97g6eoPToY4uA8zM0PURNRTROTNNT5VJOYF00
         OFsdapsKq2NYmdfeFQnMCdbLpA8E9VAMACsDTygCU8RgbkqpfmH5lD4n+KHtm9nZY6Vt
         NmaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749630379; x=1750235179;
        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=D36TET5nPdbKBCA84GHWqEQE3SKs1YEmxDXH5hhaPbo=;
        b=ponN20R914ZCEgBh2/peVdLMgLznKxiqlbJ4m5R7iQaCQ6TGt0ZiaTyVPeEU53yodm
         NQVaZkfCmRz1K2fsgZo4vIDaifduEFKUKsdgka07bcTPl9wXcIx4VgtjAkqM7VHcfaW3
         xKQvOgnFkoC3k9yhxwxdsC12CFZlr/BgQONvFH0PfWpx8DPEXYc/yj+AjmAwDWYp3Zwb
         RyNu7afbK9G9YMhvdd04o+hij9S5FrnlNWmfQbQiQNDzA5wbTpcSTInK1kvVkaAl9QEy
         vf3fwb8lIDj0NYPqxApzSww0mznT21Na6f8rTBhQAY+qCvmM09pa2WMWby+9O8/6+7j0
         r0vQ==
X-Forwarded-Encrypted: i=1; AJvYcCURQR5unEX3yBjjFi9IgEP/RMvk7OhVYjXW51Y5NidEl2FCPLYex0qGrbyMmBIRMGUZ3cdzTUFvMoU=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx6bJ+COQzAgdOcxXpJ3ztNTxeVvJg1bJ48NPhZH9mOBU7UXk/T
	z30d0sdat1AUQU6LP4utEfuGW2rQChqfOuqlXai+z8qxbHFEB0FPn9oo
X-Gm-Gg: ASbGncut/SEPqXu0aBzGkiLqwpPoGoXZjdftSYO3KAMqq3FjjbM27yOLzy3tJI/ux5L
	qc4kniQRI2sCYo0djUm0PtkAaPUODYkwcfSDBU2+wEScGaG3GCtkYOgNZZi/47/JytNFn+h6RMX
	u9oDnUrEDm9zlzGuUEj7ncDrhIBqj+lwmloqb63wfZi3ITrsONpwHVXYDnY7/BDzGeKNG/l0Mlp
	lRbdqdyCvw+dTOiW/q56tgD1xmnzNPpB/GJuU4ZHIk5J5NuZ6nQ5XQIysdHVXajZ5owr9bV8cbp
	57zjd6EAFST/kj2wgv+yNqmvhNCem0Y3rLMSb+0VyNixFt9epTmbMNI1k5Awrcw2wGnoJbn7l13
	sGDQEE5Z8dRlMibHIhjV4n90ajdZWKR503HTuLgeFSbrh+Q==
X-Google-Smtp-Source: AGHT+IFKga2vHrOPl3+FxPh+x6Oxhmj2KX4M9vWFVoSSP7oxagLFB0z2RFGAL1lewI2LpGVgFoC7iA==
X-Received: by 2002:a17:907:70c:b0:ad5:431d:fb32 with SMTP id a640c23a62f3a-ade89a57f32mr209480766b.14.1749630378965;
        Wed, 11 Jun 2025 01:26:18 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------lKCCdFGUmHx3ssi4Y0r0TStv"
Message-ID: 
Date: Wed, 11 Jun 2025 10:26:16 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 1/9] xen/riscv: dt_processor_hartid() implementation
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: 
 <751343d295c0fa6a9a7d8f2265ece3faecd44b64.1749121437.git.oleksii.kurochko@gmail.com>
 <6fe24545-1f76-4f3f-84bb-b0f8e225ac7b@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <6fe24545-1f76-4f3f-84bb-b0f8e225ac7b@suse.com>

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


On 6/10/25 4:08 PM, Jan Beulich wrote:
> On 05.06.2025 17:58, Oleksii Kurochko wrote:
>> @@ -14,3 +17,77 @@ void __init smp_prepare_boot_cpu(void)
>>       cpumask_set_cpu(0, &cpu_possible_map);
>>       cpumask_set_cpu(0, &cpu_online_map);
>>   }
>> +
>> +/**
>> + * dt_get_hartid - Get the hartid from a CPU device node
>> + *
>> + * @cpun: CPU number(logical index) for which device node is required
>> + *
>> + * Return: The hartid for the CPU node or ~0UL if not found.
>> + */
>> +static unsigned long dt_get_hartid(const struct dt_device_node *cpun)
>> +{
>> +    const __be32 *cell;
>> +    unsigned int ac;
>> +    uint32_t len;
>> +    unsigned int max_cells = UINT32_MAX / sizeof(*cell);
>> +
>> +    ac = dt_n_addr_cells(cpun);
>> +    cell = dt_get_property(cpun, "reg", &len);
>> +
>> +    if (ac > max_cells) {
> Besides the (double) style issue, why's this needed? Can't you simply ...
>
>> +        printk("%s: cell count overflow (ac=%u, max=%u)\n", __func__, ac,
>> +               max_cells);
>> +        return ~0UL;
>> +    }
>> +
>> +    if ( !cell || !ac || ((sizeof(*cell) * ac) > len) )
> ... write the last part here in a way that there can't be overflow?
> ac > len / sizeof(*cell) that is? (Remaining question then is what to
> do when len isn't evenly divisible by sizeof(*cell).)

reg property should be always evenly divisible by sizeof(*cell) according to device
tree binding:
   The reg property describes the address of the device’s resources within 
the address space defined by its parent bus. Most commonly this means 
the offsets and lengths of memory-mapped IO register blocks, but may 
have a different meaning on some bus types. Addresses in the address 
space defined by the root node are CPU real addresses.
   
   The value is a , composed of an arbitrary number of 
pairs of address and length, 
    . The number of  cells 
required to specify the address and length are bus-specific and are 
specified by the #address-cells and #size-cells properties in the parent 
of the device node. If the parent node specifies a value of 0 for 
#size-cells, the length field in the value of reg shall be omitted. So 
it is guaranteed by DTC compiler and it would be enough to check 
overflow in suggested by you way: ac > len / sizeof(*cell)
But considering what you noticed below ...

>
>> +        return ~0UL;
>> +
>> +    return dt_read_number(cell, ac);
> What meaning does this have for ac > 2? (As per your checking above
> it can be up to UINT32_MAX / 4.)

... It will be an issue for dt_read_number() which could deal only with uint64_t what means
we can't have ac > 2. (UINT32_MAX / 4 it is a theoretical maximum IIUC)

Thereby we could do in the following way:
@@ -30,19 +30,18 @@ static unsigned long dt_get_hartid(const struct dt_device_node *cpun)
      const __be32 *cell;
      unsigned int ac;
      uint32_t len;
-    unsigned int max_cells = UINT32_MAX / sizeof(*cell);
  
      ac = dt_n_addr_cells(cpun);
      cell = dt_get_property(cpun, "reg", &len);
  
-    if (ac > max_cells) {
-        printk("%s: cell count overflow (ac=%u, max=%u)\n", __func__, ac,
-               max_cells);
+    if ( !cell || !ac || (ac > len / sizeof(*cell)) )
          return ~0UL;
-    }
  
-    if ( !cell || !ac || ((sizeof(*cell) * ac) > len) )
-        return ~0UL;
+    /*
+     * If ac > 2, the result may be truncated or meaningless unless
+     * dt_read_number() supports wider integers.
+     */
+    BUG_ON(ac > 2);
  
      return dt_read_number(cell, ac);
  }

I am not sure that BUG_ON() should be in dt_get_hartid(). Probably it would be better move it
to dt_read_number() as if one day support for RV128 will be needed I assume that it will be
needed to change a prototype of dt_read_number() to work with address-cells = 3.
What do you think? Could I go with the suggested above changes or it would be better to move
BUG_ON() to dt_read_number()?

~ Oleksii


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



  
    
  
  
    

    
    
    
    
    On 6/10/25 4:08 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 05.06.2025 17:58, Oleksii Kurochko wrote:

    
      
    
        
    @@ -14,3 +17,77 @@ void __init smp_prepare_boot_cpu(void)
     cpumask_set_cpu(0, &cpu_possible_map);
     cpumask_set_cpu(0, &cpu_online_map);
 }
+
+/**
+ * dt_get_hartid - Get the hartid from a CPU device node
+ *
+ * @cpun: CPU number(logical index) for which device node is required
+ *
+ * Return: The hartid for the CPU node or ~0UL if not found.
+ */
+static unsigned long dt_get_hartid(const struct dt_device_node *cpun)
+{
+    const __be32 *cell;
+    unsigned int ac;
+    uint32_t len;
+    unsigned int max_cells = UINT32_MAX / sizeof(*cell);
+
+    ac = dt_n_addr_cells(cpun);
+    cell = dt_get_property(cpun, "reg", &len);
+
+    if (ac > max_cells) {

    
      
    
      
    Besides the (double) style issue, why's this needed? Can't you simply ...


    
      
    
        
    +        printk("%s: cell count overflow (ac=%u, max=%u)\n", __func__, ac,
+               max_cells);
+        return ~0UL;
+    }
+
+    if ( !cell || !ac || ((sizeof(*cell) * ac) > len) )

    
      
    
      
    ... write the last part here in a way that there can't be overflow?
ac > len / sizeof(*cell) that is? (Remaining question then is what to
do when len isn't evenly divisible by sizeof(*cell).)
    
    
    
    
    reg property should be always evenly divisible by sizeof(*cell) according to device
tree binding:
  The reg property describes the address of the device’s resources within the address space
  defined by its parent bus. Most commonly this means the offsets and lengths of memory-mapped
  IO register blocks, but may have a different meaning on some bus types. Addresses in the
  address space defined by the root node are CPU real addresses.
  
  The value is a <prop-encoded-array>, composed of an arbitrary number of pairs of address and
  length, <address length>. The number of <u32> cells required to specify the address and length
  are bus-specific and are specified by the #address-cells and #size-cells properties in the parent
  of the device node. If the parent node specifies a value of 0 for #size-cells, the length field
  in the value of reg shall be omitted.
So it is guaranteed by DTC compiler and it would be enough to check overflow in suggested by
you way:
  ac > len / sizeof(*cell)
But considering what you noticed below ...


    
    
    
      
    

    
      
    
        
    +        return ~0UL;
+
+    return dt_read_number(cell, ac);

    
      
    
      
    What meaning does this have for ac > 2? (As per your checking above
it can be up to UINT32_MAX / 4.)
    
    
    
    
    ... It will be an issue for dt_read_number() which could deal only with uint64_t what means
we can't have ac > 2. (UINT32_MAX / 4 it is a theoretical maximum IIUC)

Thereby we could do in the following way:
@@ -30,19 +30,18 @@ static unsigned long dt_get_hartid(const struct dt_device_node *cpun)
     const __be32 *cell;
     unsigned int ac;
     uint32_t len;
-    unsigned int max_cells = UINT32_MAX / sizeof(*cell);
 
     ac = dt_n_addr_cells(cpun);
     cell = dt_get_property(cpun, "reg", &len);
 
-    if (ac > max_cells) {
-        printk("%s: cell count overflow (ac=%u, max=%u)\n", __func__, ac,
-               max_cells);
+    if ( !cell || !ac || (ac > len / sizeof(*cell)) )
         return ~0UL;
-    }
 
-    if ( !cell || !ac || ((sizeof(*cell) * ac) > len) )
-        return ~0UL;
+    /*
+     * If ac > 2, the result may be truncated or meaningless unless
+     * dt_read_number() supports wider integers.
+     */
+    BUG_ON(ac > 2);
 
     return dt_read_number(cell, ac);
 }

I am not sure that BUG_ON() should be in dt_get_hartid(). Probably it would be better move it
to dt_read_number() as if one day support for RV128 will be needed I assume that it will be
needed to change a prototype of dt_read_number() to work with address-cells = 3.
What do you think? Could I go with the suggested above changes or it would be better to move
BUG_ON() to dt_read_number()?

~ Oleksii

    
    
    

    
  


--------------lKCCdFGUmHx3ssi4Y0r0TStv--


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 08:32:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 08:32:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011360.1389732 (Exim 4.92)
	(envelope-from )
	id 1uPGsU-0002w0-RQ; Wed, 11 Jun 2025 08:32:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011360.1389732; Wed, 11 Jun 2025 08:32: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 1uPGsU-0002vt-Od; Wed, 11 Jun 2025 08:32:10 +0000
Received: by outflank-mailman (input) for mailman id 1011360;
 Wed, 11 Jun 2025 08:32: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 1uPGsT-0002vn-6j
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 08:32:09 +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 8eb90bc8-469e-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 10:32:06 +0200 (CEST)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-451ebd3d149so40803825e9.2
 for ; Wed, 11 Jun 2025 01:32:06 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-236032fc7f4sm82694005ad.109.2025.06.11.01.31.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 01:32:04 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8eb90bc8-469e-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749630726; x=1750235526; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Ht4BM9M3IWnU0USmV6YI+sH1g0X0CQNgkr2XSV0+iEU=;
        b=ZXWheuis9GThvJUqShBDGNYp6ZcsbF9MKl0Y88yuMLM8GkEj0kC07+QMfUeCG8tHfs
         egR9QTF62UKVf7L8iQ/zXzmuMjfRVr9bF1pjFwMVUjqLxlvZx5QJKV8sLI5zR0OUmGrW
         W0EKrZD1zHv1lJ2t/KbW6HZpBjDijnuoAwx3839xGbd8vUY1aeHM1+HeSH2sJWPNPqPE
         mO6nThldJQQUIvq8ykZJjrJ2kDhedIz0LnYggx/aUyurgQvOgEXy81BQ/5J+dzDb8YCo
         RlPiX6D0rhICjOz1wW0OaAtcZM5l3bgexVNjM0RLLbbb3BwSxOuH0PN7Z1sZpGpftqr8
         wgbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749630726; x=1750235526;
        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=Ht4BM9M3IWnU0USmV6YI+sH1g0X0CQNgkr2XSV0+iEU=;
        b=pj5cWOcTfRu+n9FjWrGdK7No7Oz5Ea/CqTViUROnLZSuerZeSYZmTvlkFOE0U9MDCL
         QYvYG+hBWGKrg2yy7Cit+5lGsZCLxjc2uNDeRb1Cohcn3uq2siQGu/+n+X33U3bczE4D
         S5nYNrAg2Yup4UlRsr9zT0ObN/H8Mvkn3KjI5ANMKcI90MRr+6J8slDgmNW2hJiTWo73
         hGjnJOuRinEMdAFxjoxDrC/OB6A4pKmXD/C800jjn4j1+aGgd2hJuHua8nrfdcA57dop
         LYguAWMtX+yZs71LzE78f3iNbSzlsJe5BMo+jT0yX/aWj4Ix93fDvcoORsxTrZoTPX0e
         bQBw==
X-Forwarded-Encrypted: i=1; AJvYcCULSUTt418ZC6OLwNSoGtSJhMzwrZQAjN+SWjAT+ZZezwD/ST8kbVNH97dQQnjXx2j+xM9j3lG40Sw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz4iTz/AzNh6/pEqn2h/RvtdDSqzeW9Jw4ECNZlmnY/n8aaI/Kz
	ouKWDCu02i7TQuoep7+WBG3eVAHH8pB/3db8FhuZ6rsrbKA4dtRG6lMzo2hk4DS66g==
X-Gm-Gg: ASbGnctp/WYTGCgU7LYbxBpkubIF1bhUsjQOsmp9aTcNGE6hye3j4L5aXuExmfjrfqt
	NqGSgB7rvoN11vOS36huN6ue2cMrCTXugW3gpVvelappUNeKkAq91+tDtuUcqNwfsgSN+7fjz3+
	BB3pjkRAGDGj0/QCPCU80qWeNBNeFq81pju9p59XRjlRz9VDo2/ij9wGK0tjsKJbsq221FqWlXm
	VliCufUKhkg3Ux0s3gIj0R2hE+wobnYFNLFPHQ11OxYG/GiJVy5dyhKr1dRxIAJQJydOdboi/6H
	HTRsCqfgynnCRdAFyP9Ijjk4YKj797b4Vd+XTASCMx6laahbwQNmiLvMUvwvHSXXkOLGcLOGoid
	r4EV1aZWJr1M9DZkI0155TFqbTYBPIpTU/zYtwDUXwln1cOc=
X-Google-Smtp-Source: AGHT+IHjwyaMDCgOc5iDKXEb2k9bZCHDlAUNHmS5L6diwomhoTrdF4jWyO8zW5mot9sebdvoAVz+DA==
X-Received: by 2002:a05:6000:310d:b0:3a4:f744:e00c with SMTP id ffacd0b85a97d-3a558a325cdmr1483645f8f.29.1749630725616;
        Wed, 11 Jun 2025 01:32:05 -0700 (PDT)
Message-ID: 
Date: Wed, 11 Jun 2025 10:31:58 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 1/9] xen/riscv: dt_processor_hartid() implementation
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: 
 <751343d295c0fa6a9a7d8f2265ece3faecd44b64.1749121437.git.oleksii.kurochko@gmail.com>
 <6fe24545-1f76-4f3f-84bb-b0f8e225ac7b@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.06.2025 10:26, Oleksii Kurochko wrote:
> 
> On 6/10/25 4:08 PM, Jan Beulich wrote:
>> On 05.06.2025 17:58, Oleksii Kurochko wrote:
>>> @@ -14,3 +17,77 @@ void __init smp_prepare_boot_cpu(void)
>>>       cpumask_set_cpu(0, &cpu_possible_map);
>>>       cpumask_set_cpu(0, &cpu_online_map);
>>>   }
>>> +
>>> +/**
>>> + * dt_get_hartid - Get the hartid from a CPU device node
>>> + *
>>> + * @cpun: CPU number(logical index) for which device node is required
>>> + *
>>> + * Return: The hartid for the CPU node or ~0UL if not found.
>>> + */
>>> +static unsigned long dt_get_hartid(const struct dt_device_node *cpun)
>>> +{
>>> +    const __be32 *cell;
>>> +    unsigned int ac;
>>> +    uint32_t len;
>>> +    unsigned int max_cells = UINT32_MAX / sizeof(*cell);
>>> +
>>> +    ac = dt_n_addr_cells(cpun);
>>> +    cell = dt_get_property(cpun, "reg", &len);
>>> +
>>> +    if (ac > max_cells) {
>> Besides the (double) style issue, why's this needed? Can't you simply ...
>>
>>> +        printk("%s: cell count overflow (ac=%u, max=%u)\n", __func__, ac,
>>> +               max_cells);
>>> +        return ~0UL;
>>> +    }
>>> +
>>> +    if ( !cell || !ac || ((sizeof(*cell) * ac) > len) )
>> ... write the last part here in a way that there can't be overflow?
>> ac > len / sizeof(*cell) that is? (Remaining question then is what to
>> do when len isn't evenly divisible by sizeof(*cell).)
> 
> reg property should be always evenly divisible by sizeof(*cell) according to device
> tree binding:
>    The reg property describes the address of the device’s resources within 
> the address space defined by its parent bus. Most commonly this means 
> the offsets and lengths of memory-mapped IO register blocks, but may 
> have a different meaning on some bus types. Addresses in the address 
> space defined by the root node are CPU real addresses.
>    
>    The value is a , composed of an arbitrary number of 
> pairs of address and length, 
    . The number of  cells 
> required to specify the address and length are bus-specific and are 
> specified by the #address-cells and #size-cells properties in the parent 
> of the device node. If the parent node specifies a value of 0 for 
> #size-cells, the length field in the value of reg shall be omitted. So 
> it is guaranteed by DTC compiler and it would be enough to check 
> overflow in suggested by you way: ac > len / sizeof(*cell)
> But considering what you noticed below ...
> 
>>
>>> +        return ~0UL;
>>> +
>>> +    return dt_read_number(cell, ac);
>> What meaning does this have for ac > 2? (As per your checking above
>> it can be up to UINT32_MAX / 4.)
> 
> ... It will be an issue for dt_read_number() which could deal only with uint64_t what means
> we can't have ac > 2. (UINT32_MAX / 4 it is a theoretical maximum IIUC)
> 
> Thereby we could do in the following way:
> @@ -30,19 +30,18 @@ static unsigned long dt_get_hartid(const struct dt_device_node *cpun)
>       const __be32 *cell;
>       unsigned int ac;
>       uint32_t len;
> -    unsigned int max_cells = UINT32_MAX / sizeof(*cell);
>   
>       ac = dt_n_addr_cells(cpun);
>       cell = dt_get_property(cpun, "reg", &len);
>   
> -    if (ac > max_cells) {
> -        printk("%s: cell count overflow (ac=%u, max=%u)\n", __func__, ac,
> -               max_cells);
> +    if ( !cell || !ac || (ac > len / sizeof(*cell)) )
>           return ~0UL;
> -    }
>   
> -    if ( !cell || !ac || ((sizeof(*cell) * ac) > len) )
> -        return ~0UL;
> +    /*
> +     * If ac > 2, the result may be truncated or meaningless unless
> +     * dt_read_number() supports wider integers.
> +     */
> +    BUG_ON(ac > 2);
>   
>       return dt_read_number(cell, ac);
>   }
> 
> I am not sure that BUG_ON() should be in dt_get_hartid(). Probably it would be better move it
> to dt_read_number() as if one day support for RV128 will be needed I assume that it will be
> needed to change a prototype of dt_read_number() to work with address-cells = 3.
> What do you think? Could I go with the suggested above changes or it would be better to move
> BUG_ON() to dt_read_number()?

Don't know; the DT maintainers would have to judge. I don't, however, think it should
be BUG_ON() - as said several times before, that's a check suitable to cover for
possible mistakes in Xen code. Here however you're trying to cover for a flaw in DT.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 08:33:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 08:33:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011369.1389741 (Exim 4.92)
	(envelope-from )
	id 1uPGtp-0003VJ-8J; Wed, 11 Jun 2025 08:33:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011369.1389741; Wed, 11 Jun 2025 08:33: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 1uPGtp-0003VC-5R; Wed, 11 Jun 2025 08:33:33 +0000
Received: by outflank-mailman (input) for mailman id 1011369;
 Wed, 11 Jun 2025 08:33: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 1uPGtn-0003V4-82
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 08:33:31 +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 c030e377-469e-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 10:33:29 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a528243636so3831683f8f.3
 for ; Wed, 11 Jun 2025 01:33:29 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-7482b0ea3cdsm8705075b3a.159.2025.06.11.01.33.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 01:33:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c030e377-469e-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749630809; x=1750235609; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=iCvriiNkBzSZpS5vMPEQuI5NveEm5SIlC9r8udGlOjA=;
        b=JpaQEWD04iMc2Ythgzs+8rHP43AOxCjz/nu2r4LEqo8MLGonA2LGIA4eFEc9U48ii1
         w939ey0tNEYWgYzCPwwkRNu1uw9f3uzT8aVG3of+IXWw2QUZkiAuLjgbz/gUigej4k9Y
         XHz7SmQDuPlA3x3D+RBIrQWfzSQ/UMBGIRqF0AbPycMaRdUxk3sw9RV6luOTrsxEQYTf
         a4GZm2ACCm46jQiUnLK3dRa+yBdusOsVUd6ZHoO+7jFQftVo/EsdMGn00+Keu6/3eZso
         v3NSXUhA0TLz85iZhsMI/mgl6+EfdI9N7pTKc6iZNuJ3DInxwN0U9bjXDOO5o7Emldz+
         AMXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749630809; x=1750235609;
        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=iCvriiNkBzSZpS5vMPEQuI5NveEm5SIlC9r8udGlOjA=;
        b=Nd1S1+kgIgqslocRF4OVNv6dWR0X5wMdodgw+b5Udq2/OWw6fVc/5XerVQHjybic4y
         +xgKLLkLi2cTuxufpvZoDwJIhgwuOfWpLCSangN3ufNeNeWGzYLHH/4vDZ5/lsgzBJhi
         uv2B+zdKJSBXYgeBTcM+xuRnMDG8tkYOTC7tbXceQP2cx9YXWGrCLv+1t6sPjVCH3NDx
         db5+yXNmnxRIsCjf5aKpY36CrMnHHMjAIesxquzSXLaSj7UAmh9wvOx0AN8GA99JMdPF
         98NskrPta9qSkwTtM1/vMY4AWtRq7qGg/kYsLGjU6yn8EAcq//B8pMPydhQTqMidg+Ig
         vB0g==
X-Forwarded-Encrypted: i=1; AJvYcCUSSoMRxa9QQ6/BCAvelXqPGXdPt37asW6mebkDJPrQJRdP4H2NEOSmSEHsK0PJBOXmpODDbsCcE4o=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywn2N/x2ZVmFvmPC9ifhA0m9rH9zsUvNyzbn0MO62K23ZUyUrZS
	CdbPnQzPONNHrvK2S32DLLJInPX+0ef5/D9m96N2x91pJVpxSpl8Tqz1zfPsGaRv4A==
X-Gm-Gg: ASbGnct6/jL4Uqm873s22FPd3sJ9MKkwpYqpWuX+1I0GNqdGzfmKrqAChhwUaRT1D/E
	rqcbPkrnM7oisTJfVzrjBokaFdpZdgrtxDuUtXSLfBbmLIM89ReZEw3MnbSY9CJ5wuYsOp/wEku
	e4enjK/JvbxuHwvqsI+vcC/00mp1UFsSItWUG1ctMo50UnJ2b7LotpFmEiwc1IbH3Jius2lHu1v
	bJP2WBXjVFC8krcJNi7XxYtf9BuJb10703E8EWcr5oiypRcBxDUiyIb8s1g+rqL93x2nxXo7yHW
	LBgpLgqo6NVOFBWy0YiX0SujzjXsRjBpBeU63SliN8Ex4lQ4diKyqsDOqFyog310fH4vSjRmCqu
	CICsS5q++jgMXkusjorEU5gMkI349dtR/HgjH3kWRQVwOmAA=
X-Google-Smtp-Source: AGHT+IFPQzE2Hfm5qxibS6/1ek3HrBN6fGQ90K9DGCWi5psZIXl6X3MUTH4sWI/e7CCV4vw8mCvXyw==
X-Received: by 2002:a05:6000:4027:b0:3a4:c909:ce16 with SMTP id ffacd0b85a97d-3a558ae6570mr1466170f8f.49.1749630808695;
        Wed, 11 Jun 2025 01:33:28 -0700 (PDT)
Message-ID: <7fbadeb6-9b7a-4781-90bb-4f54cfd85612@suse.com>
Date: Wed, 11 Jun 2025 10:33:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4][PART 2 01/10] xen/x86: Move freeze/thaw_domains to
 common code
To: Mykola Kvach 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: 
 
 <4bfe5a9a-6128-4760-9121-46b0d9bd6789@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.06.2025 07:55, Mykola Kvach wrote:
> On Mon, Jun 2, 2025 at 12:20 PM Jan Beulich  wrote:
>>
>> On 02.06.2025 11:04, Mykola Kvach wrote:
>>> From: Mirela Simonovic 
>>>
>>> The freeze_domains and thaw_domains functions are currently defined
>>> in x86-specific suspend code. These functions are also useful on other
>>> architectures, such as ARM, for implementing system-wide suspend and
>>> resume functionality.
>>>
>>> This patch moves these functions to common code so they can be reused
>>> across architectures.
>>>
>>> Signed-off-by: Mirela Simonovic 
>>> Signed-off-by: Saeed Nowshadi 
>>> Signed-off-by: Mykyta Poturai 
>>> Signed-off-by: Mykola Kvach 
>>
>> On the assumption that the transient Misra violation is okay:
> 
> Perhaps wrapping it with CONFIG_SYSTEM_SUSPEND would be sufficient.

Quite likely, unless another use case for the functions would appear.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 08:56:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 08:56:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011378.1389752 (Exim 4.92)
	(envelope-from )
	id 1uPHG1-0006Wi-1Z; Wed, 11 Jun 2025 08:56:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011378.1389752; Wed, 11 Jun 2025 08:56:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPHG0-0006Wb-Td; Wed, 11 Jun 2025 08:56:28 +0000
Received: by outflank-mailman (input) for mailman id 1011378;
 Wed, 11 Jun 2025 08:56: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 1uPHFz-0006WV-FO
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 08:56:27 +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 f4a4951f-46a1-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 10:56:26 +0200 (CEST)
Received: by mail-pj1-x102b.google.com with SMTP id
 98e67ed59e1d1-3135f3511bcso3572795a91.0
 for ; Wed, 11 Jun 2025 01:56:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f4a4951f-46a1-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1749632185; x=1750236985; 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=KpRmrZjm92wzlk1LNU9s2Flj79soB6iBqe6IagrbYkc=;
        b=dsh4NjAjsvITs0qgzHhpH751KDySRo4f+aPmukt45qJzPNOrdi2abr11sbohgITXTe
         KifL6X0+D2cJitoPm0ASZqDIf+O+WkB8SRerIlYL+EGLJTrSYOqysit8q5xp8r6IOMuM
         +Bqjnxx15Hbd9H3wGWnml4G9ikTtuItfHYtr8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749632185; x=1750236985;
        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=KpRmrZjm92wzlk1LNU9s2Flj79soB6iBqe6IagrbYkc=;
        b=u/vBm5BAlrG2JfpW9+D35kvfhIzF2TFAW/Nq7Eb9nlMV2iTgMHzI3n+Ovld+SKy1Ps
         +/+r0iPqNgq8A8f+NlMAZrgQ6lK2kOL2mzVXBP5vaEvxJNdu43TjeNjAzLN52qEa313t
         G9L7nH1U5xYVVtcCC/I3j6elpxJDMXKBT7c2c7FrxgacmUsZ7/GBZ6J1919Rro6esV2K
         KENv1D/Upmp3O5b53mzFX4sV62vDMrr7dBti0YizlL9h8wyO/OHuE/4gBvbdx5yUE5bR
         J/5Xyx09CPqChfGAnAksCuTwqcGqPk/4eQwhGiqz6290WxgnFxdbrXysXYhD7pyTmp8p
         PKrA==
X-Forwarded-Encrypted: i=1; AJvYcCX0S78is7GBHMWDj7GU68NUun+qpyxYgVkELoJzgkpMrRTwHtExj34pX55dZrfzky/XD0UfTjj5704=@lists.xenproject.org
X-Gm-Message-State: AOJu0YygpvuB6Evx2covDsuczALZrGKHTKQn/9mb2IBYRFcr8NEVwPNU
	sjDKJFtKReJesltnoIO7EVVq0PYahexbJb5+pEW/CyGdaD/ImxmcLoF7oNZAOL6jp0NJUOj4FSs
	aMvp2DH6EhACXApl26YjcDc5tYojwK07K2oaPSH+o/w==
X-Gm-Gg: ASbGncvIsgD+7rPmtvlXxQ+UPuAwlO+JOXns0iusfom2TZRfoh0wA+sXA8vkWSjnfkk
	gwnuy1cY+IWpvbUUQQyXJU9nH9AdYBUzqTDSnQjdJyn3MbY6K5RnfXnf2Yxp0R5BXDlLVg1V9PO
	NYyEeZpVgNVMAvrbYiG5UesR06M4LAR+EtIZ+hIV/vEJo=
X-Google-Smtp-Source: AGHT+IGkXgitF8c1f1rqntDGnQf67ykDMpJpwFtPP+fTb2UBVI4KufYDMoCJ7aYKntA6iNLCoF8eJ2SBlYnnFQ3rJWQ=
X-Received: by 2002:a17:90b:1b51:b0:312:1d2d:18df with SMTP id
 98e67ed59e1d1-313b1ff11b2mr2138706a91.23.1749632184927; Wed, 11 Jun 2025
 01:56:24 -0700 (PDT)
MIME-Version: 1.0
References: <20250602134656.3836280-1-kevin.lampis@cloud.com>
 <20250602134656.3836280-4-kevin.lampis@cloud.com> 
In-Reply-To: 
From: Kevin Lampis 
Date: Wed, 11 Jun 2025 09:56:10 +0100
X-Gm-Features: AX0GCFs6ePJBIxx9JFLajcEYXauuzdeEV8tdfxi0BZ6fYSLqHjo6npOqBUgqMyQ
Message-ID: 
Subject: Re: [PATCH v2 3/3] Disallow most command-line options when lockdown
 mode is enabled
To: Jan Beulich 
Cc: Ross Lagerwall , xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 10, 2025 at 4:56=E2=80=AFPM Jan Beulich  wro=
te:
>
>It's still being left entirely unclear what the criteria are by which an
>option can / cannot be marked "safe".

The purpose of lockdown mode is to protect Xen from unauthorized code execu=
tion
in Secure Boot mode. Xen especially needs protection from dom0 userland whi=
ch
I understand has traditionally been considered fully trusted.

>... why's this being marked such, when already by its name its use is goin=
g
>to render the system unsafe.
>Similarly I don't think it's a good idea to allow turning off MCE.

I believe these are both denial of service issues which is out of scope for
lockdown mode / Secure Boot.

>I won't go any further until clarification on the criteria was written
>down.
I understand your feedback. Picking safe comandline options and explaining =
why
they are safe requires more work here.


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 09:20:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 09:20:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011397.1389813 (Exim 4.92)
	(envelope-from )
	id 1uPHdP-0002SY-CT; Wed, 11 Jun 2025 09:20:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011397.1389813; Wed, 11 Jun 2025 09:20: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 1uPHdP-0002SR-9w; Wed, 11 Jun 2025 09:20:39 +0000
Received: by outflank-mailman (input) for mailman id 1011397;
 Wed, 11 Jun 2025 09:20: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 1uPHdO-0002SG-2V
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 09:20:38 +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 54f86aa9-46a5-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 11:20:35 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3a52874d593so6140449f8f.0
 for ; Wed, 11 Jun 2025 02:20:35 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-7482b083abcsm9064790b3a.92.2025.06.11.02.20.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 02:20:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 54f86aa9-46a5-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749633635; x=1750238435; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=RmmAk3ljw2xs7Jfo2z76cXMFwHIrLyQ23gotV90W91A=;
        b=JvcYuFha/8P89JrbpqeyklP/0FOsIE4cRp3boZzO1vbXLlN1gOk/isOVWFVgji4kEX
         I9sY4BeFMuRD548xT0IVxS1uG/bBgGzSfb2/KFn63iX7OFb0gXWZcYJFBko2bvOqXIq9
         i3B7D5OW/0urXIymBhe6B81vihugAAG9bwGOFyI+V7v5jPduQjMhqEvBZjxxb+IYf8SL
         qLM1uOJXPltkD7zpMmiJtz5bDDLCNLz5nKnvgcQgI5jW3hkPbTF49aQsGXovFrLh23Ex
         9m8bodIRb/eDjLDZyBNTP+PLy0AFAjZtelY8NBKk077hMfp1IE2sdMrrlcmENsEWtYzi
         Ok7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749633635; x=1750238435;
        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=RmmAk3ljw2xs7Jfo2z76cXMFwHIrLyQ23gotV90W91A=;
        b=Ou7QMQrX+bVg4TZqfsPnP9ZYv0cMhamSldi8yWFGt0A9FrMtibz17tEFM2sOKPSPFC
         BN42xs/nkxieOFQe7RMLAnc2RrhcOSadreigpayEphiBrDmxZpKrWwYyPnj6WN0BRgZj
         nAG2C7uMrgWNQB/Dr6U3bITvdP6fFESI3opW6cyG3oDz4vlENAX5plZNMkL4dzUI0F7w
         48Mo0RJCC/Z4ERf5Lks/A1oICuzwUy1IycTGXplz3xjZdSwgI3xPinAfigzlpQao8ols
         shaJ5ZLJSUmF0fXDWGV3GSBkVRvRWE/SJHjPFuccBxIX9dxEPsDfJuSJaGKWJmjs64f+
         /KZQ==
X-Forwarded-Encrypted: i=1; AJvYcCWzgO84V59sTQzz1Of6lvYPaPXKN2FIz4E7vXJQxzQrA3UtYx2unIlxgDgvIvKagWgi9OP+Sd0VrqM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzsZ7qjXPhT7DGVB7nQAYOBBbVlhkIshr2wfkYAkUJcQTKFj6W8
	PJXXIFuEWvtC57SOT4RdbS8+iij09aahDPy3pX3ZKqlqHSUSfl3LEhF7A8Y77QEG3w==
X-Gm-Gg: ASbGncuyNqbVazoJotZSDzIy7myW0m77k1iNF0WrlM0fJ4JHm1j7JtQVm2DzD1Lbx0x
	jtmIX+p/RA4zNOFrhNw0Rh1buGi1spc0ZWevOt6MutLR2Cc86XekZDCEF9DMmnNNzPdWA49NLnY
	1YbDJBJ87I2a3FpeD7Xh+ZbWle+dLQzoIKaA/kbCv3QPK4Ws2VNyTTkZUuFxh5k9BkYIPtz6PHX
	lxitsRkiYdUee051nBPHsVHzUka+BVg1mFCOysYGWqJF1t/xMMoN4/R468aSpPOpTJortZHAWyi
	jeYSEs/HrwCXFKD8uuoTXxV31oWCQzAFg6h0zKt/ouU2zqwvoQAu16fjJoGzG3wK5zmINP2CbHR
	SwE0GEN5QvpNv5bVvU2azHhJ70UeOutZ6LCVPx9S3a1lvD86ZRWLucecVFg==
X-Google-Smtp-Source: AGHT+IE0XkmQO2ozOglXdSorlrAS94jRzNH6FQCCpF9eM0+jXZ0teLS0oOv7L84TPhUONxKPGTxDYQ==
X-Received: by 2002:a5d:5888:0:b0:3a4:eb7a:2cda with SMTP id ffacd0b85a97d-3a558ad707fmr1768474f8f.30.1749633635200;
        Wed, 11 Jun 2025 02:20:35 -0700 (PDT)
Message-ID: <6213c0dd-2145-48a2-9e8a-8a949da5e866@suse.com>
Date: Wed, 11 Jun 2025 11:20:29 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/domain: fix late hwdom feature
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org,
 dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250610234105.1082890-1-dmukhin@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: <20250610234105.1082890-1-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.06.2025 01:42, dmkhn@proton.me wrote:
> From: Denis Mukhin 
> 
> Fix get_initial_domain_id() which how returns hardware_domid and breaks late
> hwdom feature [1].
> 
> [1] https://lore.kernel.org/xen-devel/a4c860d7-1fa0-43f4-8ae1-af59b7c6506f@xen.org/
> 

Reported-by: Julien Grall 

> Fixes: f147ccf2 ("xen/consoled: clean up console handling for PV shim")

12 hex digit please (see sending-patches.pandoc), i.e. f147ccf2b3c8 (largely for
my own reference, to make respective adjustments while committing).

> Signed-off-by: Denis Mukhin 

Acked-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 09:35:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 09:35:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011402.1389823 (Exim 4.92)
	(envelope-from )
	id 1uPHrr-0004HF-Df; Wed, 11 Jun 2025 09:35:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011402.1389823; Wed, 11 Jun 2025 09:35: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 1uPHrr-0004H8-B9; Wed, 11 Jun 2025 09:35:35 +0000
Received: by outflank-mailman (input) for mailman id 1011402;
 Wed, 11 Jun 2025 09:35: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 1uPHrq-0004H2-6l
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 09:35:34 +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 6b97c72e-46a7-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 11:35:33 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3a52874d593so6155711f8f.0
 for ; Wed, 11 Jun 2025 02:35:32 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b2f5f66a7c9sm8009130a12.46.2025.06.11.02.35.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 02:35:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6b97c72e-46a7-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749634532; x=1750239332; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=8EHVCwcFEIYICyE4iqiEl06OzG5rQF6TaxMoUmsnhr0=;
        b=U5Vj1N+VDsiogxFMplsqGUJYTUJy9JpRALaL5JIbEWd8AluAE7BWUOELLgXYPUKNuK
         FqyMloWwYYGP6XzS28GZDXbiAP9+UUQA20R9JuLiCrChitHFF6roVlZBq2U4/qrko/ZV
         zgtHlamYIHau5ixZwKvO9FjIusn32YCkCZH1izUZGPmJmsNGE6XtzEEnYd20lq339koC
         8OCT9K/8Ot3yDuoD7hP0HE9islEnZ6xPs+L1V+dq9Je3vg16U+IZWdcZYn+oTDtRhko6
         h4d/OOELTLs0ilUXuMquBkdE+hWSereXKTDTnNgPOv13/Fdj+zo4PEkyKmlobEBV9lCf
         xEfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749634532; x=1750239332;
        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=8EHVCwcFEIYICyE4iqiEl06OzG5rQF6TaxMoUmsnhr0=;
        b=GH0qaISa7YJOciUnSCI+PASSeK4T1kUjxgsuIfwk8AkIvNkyWf5ykhL7ZE11JdeC6d
         OakzlkYu477GAzAVrwxzXd5SI/HhALOqreLb6nzw56/tW/PobLD3/xT1uYdzRySzpM9b
         0ceutSF9/pMpS9kavA3JvRoAjK2U7aDHKeQiXZulP+ztgRdhBLHomGL5IhU20bRRsZ9q
         hX26quuOy7qNBA5C0xvgBgkz8gefcFpZWs6HBtdanEILkPlUTg3vyTSC4xZN80tRngzF
         8XaMKmEZ36pfgih5puBMSFLoFmKJp9apRsEsXH6QLcpmp+9rzwWVUTmqs2W6dmoLwm2z
         MKEA==
X-Forwarded-Encrypted: i=1; AJvYcCV+d+Op66oZEV3sqUZPa9C9TIECfWjXHzm59EZiLPslnPiQoQxXzKgRqTAyF6r752TJYu/UqICR3OQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxY6zTlci5i4T1KBH/pJYFQZR3Lt/n1Whom83fSGfQpLcoPwQSG
	HWHuwcYFxNuamRay5qUhciF5uBUEnPH4jaP+W97FhkEqAV+p0/DDXTv7DXAaAub7JQ==
X-Gm-Gg: ASbGnctU+rCEZeRABxuVS5Y1STHKwMUrtgqnfB7XEJfE85P/yzPMRF7LWJEu/auECfQ
	SK4QixTIocfyjB4jZHb1Np25M+sew5J9w7f2aybweYtxo58iP9MMKG3ING0ScdDnxxdIykRenXx
	i0IWRsa568BVtowvZ30lvSPGW0l2GZ2ONTiLNgk1VMSv1lrAfeQbOBPH7ZsGGK6HY0fXFzVbjdn
	k7FSTa/g8giSCBuXzQtu6QPbkQ4HzowMn8j5D6ZGZlXHjnr9lyivgZzeFLB1UM0VSbjICDUpz6a
	91tJFG3ESb4WdGfHH8qDlUT//45zFVAQAYFfaqDKGrg5VCX0qKKMzHHz8OoCyQr7WzTXuZOnIrH
	VT+9KARGjDiLJIC+e5rISBg0d5Y4CjWRbgJ2KwIqSvHJgN4k=
X-Google-Smtp-Source: AGHT+IGcvbc+EkPoMmmun9GyngQUCI8fLYPSzEVv6eIkazDXBR9mtjOi3D4bwzFimRKDg6FKIlqUTQ==
X-Received: by 2002:a5d:5f91:0:b0:3a4:d4cd:b06 with SMTP id ffacd0b85a97d-3a558ad6ddcmr1698986f8f.34.1749634532282;
        Wed, 11 Jun 2025 02:35:32 -0700 (PDT)
Message-ID: <02162717-25de-4ffb-a9c4-bf6d580c43bc@suse.com>
Date: Wed, 11 Jun 2025 11:35:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen: Strip xen.efi by default
To: Frediano Ziglio 
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: <20250610101228.24460-1-freddy77@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: <20250610101228.24460-1-freddy77@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.06.2025 12:12, Frediano Ziglio wrote:
> For xen.gz file we strip all symbols and have an additional
> xen-syms file version with all symbols.
> Make xen.efi more coherent stripping all symbols too.

And the other difference (compressed vs not) still remains.

> xen.efi.elf can be used for debugging.

Hmm, that's the result of ...

> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -238,6 +238,7 @@ endif
>  		> $@.map
>  ifeq ($(CONFIG_DEBUG_INFO),y)
>  	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) -O elf64-x86-64 $@ $@.elf
> +	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(STRIP) $@
>  endif
>  	rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]*
>  ifeq ($(CONFIG_XEN_IBT),y)

... objcopy. Having looked at the involved code in that utility, I mistrust its
output from such a conversion to really be an exact representation of the input.
IOW I'd much rather use the original file. As a possible compromise, could we
perhaps merely strip debug info, but retain the symbol table, matching the
prior default for $(efi-strip-opt)?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 09:51:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 09:51:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011412.1389833 (Exim 4.92)
	(envelope-from )
	id 1uPI7S-000777-MR; Wed, 11 Jun 2025 09:51:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011412.1389833; Wed, 11 Jun 2025 09:51: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 1uPI7S-000770-Jh; Wed, 11 Jun 2025 09:51:42 +0000
Received: by outflank-mailman (input) for mailman id 1011412;
 Wed, 11 Jun 2025 09:51: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 1uPI7R-00076u-Gn
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 09:51: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 ab83fe3d-46a9-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 11:51:39 +0200 (CEST)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-60768f080d8so9837334a12.1
 for ; Wed, 11 Jun 2025 02:51:39 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-607783de30csm7253660a12.66.2025.06.11.02.51.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 02:51:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ab83fe3d-46a9-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749635498; x=1750240298; 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=zCBTYdU/oI6c9xHLFYr81STp4FAQRFNyFFKGDBUAGd8=;
        b=hNJbI8enuoupj+GIwHoaZG3NnA18lw7WtG9SsSI5KrIirTkSXr1IuuVbY6Td7yMOPb
         EWZcbtRHgwvHzYHJO0CQW39ksgRTkS+/oWuq0OTDo/rtlNR9uMOb696KhDwv7WNhBl8L
         NLRXIJeosdCn/w8wQy2K0/GhFzmq6ylLutvU7sN6443zoGIri+sLT55jxnNegjl9bsFo
         TbTJgkFHgF0XnhMJ4jhTcsuv0IOD7WTUQIAObE/FM+m/EOVcKLyidlBTTH+JiYKjM2Fk
         wpXqh+es9WmHiY2zyjB4+x6JpTcaIEnmIQdEcAK6Qm4y86WbZ6p294Zm/mr7/QhFWl+r
         J0Hg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749635498; x=1750240298;
        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=zCBTYdU/oI6c9xHLFYr81STp4FAQRFNyFFKGDBUAGd8=;
        b=oYfvpkOl2986yDyJjO5W/BbZFpob3dtvRkdQGWYmL6+x8abL3wBhYkdDPXFeAOypqd
         1fLjB+/PuvatLoGM7hCQ744LzSUYBGMDN8v30HGIDLHyHrHggEsu2KjuwoJZuples4c3
         yzh+e9o2qYd/477grpen9P0mazJOYcdJl9HjSZrTnMcJYZnath9VSPM1k5cWBHDXJe1W
         +ik463wjXP9oKI+SVqW3jM7G2Vt0Rz4SZC3bHRubKb7KTfQQ/94P9AnzFP0wPwsKbik9
         SwcYiMVcBG0aXUtLJxD4AC9w3kO2p9YU9lGVyRStqLNg+HFtOS/DluOgUisQhTvUw/XK
         vLCA==
X-Forwarded-Encrypted: i=1; AJvYcCXtZBS156E8Rm1SufoxK5QBLkjpIfhDGwEf9h5DVjcZ5x/KTvvU7TxmWDFU0IFNLpmANGZ51szklhI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyPtl+y/OoZq3E85CpteYJNakFuF3gjUAtEO8mAQ3u6RFK5v8Ga
	WUOopj5diJVDxm5ZSisUAII/JOonB7dXcZc/AbTxBTB/M3uXmJm2r0XM
X-Gm-Gg: ASbGncs1bN11w6SNDHkMS1Jak1lLliZDwe+9ctG6HZMGluEf5XIcsJFHOcy8q5uVyb9
	0vK4Tqua7QoWLPcBKdgab4PsbS1d3nXjwPjwJj6n9kPd/H6lzZW8RmUDY56Ku0vkfApfzalNUNZ
	0bxuAj3O+jgonop6Alj/8HvY3DYgW0AJBpb7KKQlBd+O3iLxVmqZ92W5ZxGK+rnFMLfhKwdg2tq
	vSI7k8ghS0OVYW4piaDLgjQVs6J/6CWdNr3H9IZx1mhay6u99XNGvv7d6z/CQDpWpd9to8f9mmP
	pC7o6Fja4xsGQYNz3EqDeWKh0cTPJEH1GCQunuknKZojJavubDezH3lOLpYTgK5QT845Fbf+/Ah
	GqQayJAnLVnhPEsWMhSWrD3hRHYfS0ElYmQ4=
X-Google-Smtp-Source: AGHT+IGXvlHyny7A3uKJEU0FPoQriQrUXM/zxHNpzw6Cl8D6YDPuN9wVoczDiqivEpFwF6BUyjzN6g==
X-Received: by 2002:a05:6402:2749:b0:607:f61f:cc18 with SMTP id 4fb4d7f45d1cf-6084e2cedb6mr1775614a12.0.1749635498205;
        Wed, 11 Jun 2025 02:51:38 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------0KL4Rntryxg1Xxkrzb0OXOnq"
Message-ID: <36912da6-7790-4c6a-8190-60f87bec09d1@gmail.com>
Date: Wed, 11 Jun 2025 11:51:37 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 3/9] xen/riscv: imsic_init() implementation
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 ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 
 <910ea6a2-2bd1-4499-bdb1-debc4a778502@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <910ea6a2-2bd1-4499-bdb1-debc4a778502@suse.com>

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


On 6/10/25 5:17 PM, Jan Beulich wrote:
> On 05.06.2025 17:58, Oleksii Kurochko wrote:
>> --- /dev/null
>> +++ b/xen/arch/riscv/imsic.c
>> @@ -0,0 +1,358 @@
>> +/* SPDX-License-Identifier: MIT */
>> +
>> +/*
>> + * xen/arch/riscv/imsic.c
>> + *
>> + * RISC-V Incoming MSI Controller support
>> + *
>> + * (c) Microchip Technology Inc.
>> + * (c) Vates
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +
>> +#define IMSIC_HART_SIZE(guest_bits_) (BIT(guest_bits_, U) * IMSIC_MMIO_PAGE_SZ)
> Minor: Any particular reason for the trailing underscore here?

Not really, I will drop it.

>
>> +/*
>> + * Initialize the imsic_cfg structure based on the IMSIC DT node.
>> + *
>> + * Returns 0 if initialization is successful, a negative value on failure,
>> + * or IRQ_M_EXT if the IMSIC node corresponds to a machine-mode IMSIC,
>> + * which should be ignored by the hypervisor.
>> + */
>> +int __init imsic_init(const struct dt_device_node *node)
>> +{
>> +    int rc;
>> +    unsigned long reloff, hartid;
>> +    unsigned int nr_parent_irqs, index, nr_handlers = 0;
>> +    paddr_t base_addr;
>> +    unsigned int nr_mmios;
>> +    struct imsic_mmios *mmios;
>> +    struct imsic_msi *msi = NULL;
>> +
>> +    /* Parse IMSIC node */
>> +    rc = imsic_parse_node(node, &nr_parent_irqs, &nr_mmios);
>> +    /*
>> +     * If machine mode imsic node => ignore it.
>> +     * If rc < 0 => parsing of IMSIC DT node failed.
>> +     */
>> +    if ( (rc == IRQ_M_EXT) || (rc < 0) )
>> +        return rc;
>> +
>> +    /* Allocate MMIO resource array */
>> +    mmios = xvzalloc_array(struct imsic_mmios, nr_mmios);
>> +    if ( !mmios )
>> +    {
>> +        rc = -ENOMEM;
>> +        goto imsic_init_err;
>> +    }
>> +
>> +    msi = xvzalloc_array(struct imsic_msi, nr_parent_irqs);
>> +    if ( !msi )
>> +    {
>> +        rc = -ENOMEM;
>> +        goto imsic_init_err;
>> +    }
>> +
>> +    /* Check MMIO register sets */
>> +    for ( unsigned int i = 0; i < nr_mmios; i++ )
>> +    {
>> +        unsigned int guest_bits = imsic_cfg.guest_index_bits;
>> +        unsigned long expected_mmio_size =
>> +            IMSIC_HART_SIZE(guest_bits) * nr_parent_irqs;
>> +
>> +        rc = dt_device_get_address(node, i, &mmios[i].base_addr,
>> +                                   &mmios[i].size);
>> +        if ( rc )
>> +        {
>> +            printk(XENLOG_ERR "%s: unable to parse MMIO regset %u\n",
>> +                   node->name, i);
>> +            goto imsic_init_err;
>> +        }
>> +
>> +        base_addr = mmios[i].base_addr;
>> +        base_addr &= ~(BIT(guest_bits +
>> +                           imsic_cfg.hart_index_bits +
>> +                           IMSIC_MMIO_PAGE_SHIFT, UL) - 1);
>> +        base_addr &= ~((BIT(imsic_cfg.group_index_bits, UL) - 1) <<
>> +                       imsic_cfg.group_index_shift);
>> +        if ( base_addr != imsic_cfg.base_addr )
>> +        {
>> +            rc = -EINVAL;
>> +            printk(XENLOG_ERR "%s: address mismatch for regset %u\n",
>> +                   node->name, i);
>> +            goto imsic_init_err;
>> +        }
>> +
>> +        if ( mmios[i].size != expected_mmio_size )
>> +        {
>> +            rc = -EINVAL;
>> +            printk(XENLOG_ERR "%s: IMSIC MMIO size is incorrect %ld, "
>> +                   "expeced MMIO size: %ld\n", node->name, mmios[i].size,
> To aid grep-ability, please avoid wrapping format strings across lines.
> (Same at least once more elsewhere.)
>
>> +                   expected_mmio_size);
>> +            goto imsic_init_err;
>> +        }
>> +    }
>> +
>> +    /* Configure handlers for target CPUs */
>> +    for ( unsigned int i = 0; i < nr_parent_irqs; i++ )
>> +    {
>> +        unsigned long cpu;
> Along the lines of questions on earlier versions: Any reason this isn't
> unsigned int?

Failed to do proper cleanup. It should be unsigned int.

>
>> +        rc = imsic_get_parent_hartid(node, i, &hartid);
>> +        if ( rc )
>> +        {
>> +            printk(XENLOG_WARNING "%s: cpu ID for parent irq%u not found\n",
>> +                   node->name, i);
>> +            continue;
>> +        }
>> +
>> +        cpu = hartid_to_cpuid(hartid);
>> +
>> +        if ( cpu >= num_possible_cpus() )
>> +        {
>> +            printk(XENLOG_WARNING "%s: unsupported hart ID=%#lx for parent "
>> +                   "irq%u\n", node->name, hartid, i);
>> +            continue;
>> +        }
>> +
>> +        /* Find MMIO location of MSI page */
>> +        reloff = i * BIT(imsic_cfg.guest_index_bits, UL) * IMSIC_MMIO_PAGE_SZ;
> Any reason to open-code IMSIC_HART_SIZE() here and ...
>
>> +        for ( index = 0; index < nr_mmios; index++ )
>> +        {
>> +            if ( reloff < mmios[index].size )
>> +                break;
>> +
>> +            /*
>> +             * MMIO region size may not be aligned to
>> +             * BIT(global->guest_index_bits) * IMSIC_MMIO_PAGE_SZ
>> +             * if holes are present.
>> +             */
>> +            reloff -= ROUNDUP(mmios[index].size,
>> +                      BIT(imsic_cfg.guest_index_bits, UL) * IMSIC_MMIO_PAGE_SZ);
> ... here?

Thanks, missed that. I'll update such places.

>
>> +        }
>> +
>> +        if ( index == nr_mmios )
>> +        {
>> +            printk(XENLOG_WARNING "%s: MMIO not found for parent irq%u\n",
>> +                   node->name, i);
>> +            continue;
>> +        }
>> +
>> +        if ( !IS_ALIGNED(msi[cpu].base_addr + reloff,
> DYM mmios[index].base_addr here, considering that ...
>
>> +                         IMSIC_MMIO_PAGE_SZ) )
>> +        {
>> +            printk(XENLOG_WARNING "%s: MMIO address %#lx is not aligned on "
>> +                   "a page\n", node->name, msi[cpu].base_addr + reloff);
>> +            msi[cpu].offset = 0;
>> +            msi[cpu].base_addr = 0;
>> +            continue;
>> +        }
>> +
>> +        msi[cpu].base_addr = mmios[index].base_addr;
>> +        msi[cpu].offset = reloff;
> msi[cpu] is set only here?

Yes, mmios[] should be used instead of msi[]...

>
> Also is the setting to zero of both fields on the "continue" path really
> needed, seeing that the array starts out zero-filled? Can the same CPU
> be found twice, making it necessary(?) to invalidate the array slot later?

Normally no, it can't be that the same CPU is found twice.

On other side, I tried to compile by hand DTS which has two the same CPUs
mentioned in IMSIC node and it allows me to do that:
(XEN) Latest ChangeSet:
(XEN) build-id: 2cd98ed5a91bf443a02a9c4e83f05df4c1f7ec61
(XEN) !!! hartid:0
(XEN) imsics: unsupported hart ID=0 for parent irq0
(XEN) !!! hartid:2
(XEN) imsics: unsupported hart ID=0x2 for parent irq1
(XEN) !!! hartid:2
(XEN) imsics: unsupported hart ID=0x2 for parent irq2
(XEN) !!! hartid:3
(XEN) Allocated console ring of 16 KiB.

(unsupported hart ID=... is printed here because I told QEMU that you have 1
cpu, but in DTS I mentioned more then 1)

It seems like it is needed also to check if IMSIC node provides unique cpu in
its interrupts-extended property. And to verify that I think it would be enough
to check if msi[cpu].base_addr isn't 0:
@@ -408,15 +407,19 @@ int __init imsic_init(const struct dt_device_node *node)
  
          cpu = hartid_to_cpuid(hartid);
  
+        if ( msi[cpu].base_addr )
+            panic("%s: cpu%d is found twice in interrupts-extended prop\n",
+                  node->name, cpu);
+
Or probably it would be better just ignore by doing 'continue' instead of
panic() as it is done in other places in imsic_init().

Thanks.

~ Oleksii

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



  
    
  
  
    

    
    
    
    
    On 6/10/25 5:17 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 05.06.2025 17:58, Oleksii Kurochko wrote:

    
      
    
        
    --- /dev/null
+++ b/xen/arch/riscv/imsic.c
@@ -0,0 +1,358 @@
+/* SPDX-License-Identifier: MIT */
+
+/*
+ * xen/arch/riscv/imsic.c
+ *
+ * RISC-V Incoming MSI Controller support
+ *
+ * (c) Microchip Technology Inc.
+ * (c) Vates
+ */
+
+#include <xen/bitops.h>
+#include <xen/const.h>
+#include <xen/cpumask.h>
+#include <xen/device_tree.h>
+#include <xen/errno.h>
+#include <xen/init.h>
+#include <xen/macros.h>
+#include <xen/smp.h>
+#include <xen/spinlock.h>
+#include <xen/xvmalloc.h>
+
+#include <asm/imsic.h>
+
+#define IMSIC_HART_SIZE(guest_bits_) (BIT(guest_bits_, U) * IMSIC_MMIO_PAGE_SZ)

    
      
    
      
    Minor: Any particular reason for the trailing underscore here?
    
    
    
    
    Not really, I will drop it.


    
    
    
      
    

    
      
    
        
    +/*
+ * Initialize the imsic_cfg structure based on the IMSIC DT node.
+ *
+ * Returns 0 if initialization is successful, a negative value on failure,
+ * or IRQ_M_EXT if the IMSIC node corresponds to a machine-mode IMSIC,
+ * which should be ignored by the hypervisor.
+ */
+int __init imsic_init(const struct dt_device_node *node)
+{
+    int rc;
+    unsigned long reloff, hartid;
+    unsigned int nr_parent_irqs, index, nr_handlers = 0;
+    paddr_t base_addr;
+    unsigned int nr_mmios;
+    struct imsic_mmios *mmios;
+    struct imsic_msi *msi = NULL;
+
+    /* Parse IMSIC node */
+    rc = imsic_parse_node(node, &nr_parent_irqs, &nr_mmios);
+    /*
+     * If machine mode imsic node => ignore it.
+     * If rc < 0 => parsing of IMSIC DT node failed.
+     */
+    if ( (rc == IRQ_M_EXT) || (rc < 0) )
+        return rc;
+
+    /* Allocate MMIO resource array */
+    mmios = xvzalloc_array(struct imsic_mmios, nr_mmios);
+    if ( !mmios )
+    {
+        rc = -ENOMEM;
+        goto imsic_init_err;
+    }
+
+    msi = xvzalloc_array(struct imsic_msi, nr_parent_irqs);
+    if ( !msi )
+    {
+        rc = -ENOMEM;
+        goto imsic_init_err;
+    }
+
+    /* Check MMIO register sets */
+    for ( unsigned int i = 0; i < nr_mmios; i++ )
+    {
+        unsigned int guest_bits = imsic_cfg.guest_index_bits;
+        unsigned long expected_mmio_size =
+            IMSIC_HART_SIZE(guest_bits) * nr_parent_irqs;
+
+        rc = dt_device_get_address(node, i, &mmios[i].base_addr,
+                                   &mmios[i].size);
+        if ( rc )
+        {
+            printk(XENLOG_ERR "%s: unable to parse MMIO regset %u\n",
+                   node->name, i);
+            goto imsic_init_err;
+        }
+
+        base_addr = mmios[i].base_addr;
+        base_addr &= ~(BIT(guest_bits +
+                           imsic_cfg.hart_index_bits +
+                           IMSIC_MMIO_PAGE_SHIFT, UL) - 1);
+        base_addr &= ~((BIT(imsic_cfg.group_index_bits, UL) - 1) <<
+                       imsic_cfg.group_index_shift);
+        if ( base_addr != imsic_cfg.base_addr )
+        {
+            rc = -EINVAL;
+            printk(XENLOG_ERR "%s: address mismatch for regset %u\n",
+                   node->name, i);
+            goto imsic_init_err;
+        }
+
+        if ( mmios[i].size != expected_mmio_size )
+        {
+            rc = -EINVAL;
+            printk(XENLOG_ERR "%s: IMSIC MMIO size is incorrect %ld, "
+                   "expeced MMIO size: %ld\n", node->name, mmios[i].size,

    
      
    
      
    To aid grep-ability, please avoid wrapping format strings across lines.
(Same at least once more elsewhere.)


    
      
    
        
    +                   expected_mmio_size);
+            goto imsic_init_err;
+        }
+    }
+
+    /* Configure handlers for target CPUs */
+    for ( unsigned int i = 0; i < nr_parent_irqs; i++ )
+    {
+        unsigned long cpu;

    
      
    
      
    Along the lines of questions on earlier versions: Any reason this isn't
unsigned int?
    
    
    
    
    Failed to do proper cleanup. It should be unsigned int.

    
    
    
      
    

    
      
    
        
    +        rc = imsic_get_parent_hartid(node, i, &hartid);
+        if ( rc )
+        {
+            printk(XENLOG_WARNING "%s: cpu ID for parent irq%u not found\n",
+                   node->name, i);
+            continue;
+        }
+
+        cpu = hartid_to_cpuid(hartid);
+
+        if ( cpu >= num_possible_cpus() )
+        {
+            printk(XENLOG_WARNING "%s: unsupported hart ID=%#lx for parent "
+                   "irq%u\n", node->name, hartid, i);
+            continue;
+        }
+
+        /* Find MMIO location of MSI page */
+        reloff = i * BIT(imsic_cfg.guest_index_bits, UL) * IMSIC_MMIO_PAGE_SZ;

    
      
    
      
    Any reason to open-code IMSIC_HART_SIZE() here and ...


    
      
    
        
    +        for ( index = 0; index < nr_mmios; index++ )
+        {
+            if ( reloff < mmios[index].size )
+                break;
+
+            /*
+             * MMIO region size may not be aligned to
+             * BIT(global->guest_index_bits) * IMSIC_MMIO_PAGE_SZ
+             * if holes are present.
+             */
+            reloff -= ROUNDUP(mmios[index].size,
+                      BIT(imsic_cfg.guest_index_bits, UL) * IMSIC_MMIO_PAGE_SZ);

    
      
    
      
    ... here?
    
    
    
    
    Thanks, missed that. I'll update such places.


    
    
    
      
    

    
      
    
        
    +        }
+
+        if ( index == nr_mmios )
+        {
+            printk(XENLOG_WARNING "%s: MMIO not found for parent irq%u\n",
+                   node->name, i);
+            continue;
+        }
+
+        if ( !IS_ALIGNED(msi[cpu].base_addr + reloff,

    
      
    
      
    DYM mmios[index].base_addr here, considering that ...


    
      
    
        
    +                         IMSIC_MMIO_PAGE_SZ) )
+        {
+            printk(XENLOG_WARNING "%s: MMIO address %#lx is not aligned on "
+                   "a page\n", node->name, msi[cpu].base_addr + reloff);
+            msi[cpu].offset = 0;
+            msi[cpu].base_addr = 0;
+            continue;
+        }
+
+        msi[cpu].base_addr = mmios[index].base_addr;
+        msi[cpu].offset = reloff;

    
      
    
      
    msi[cpu] is set only here?
    
    
    
    
    Yes, mmios[] should be used instead of msi[]...


    
    
    
      
    
Also is the setting to zero of both fields on the "continue" path really
needed, seeing that the array starts out zero-filled? Can the same CPU
be found twice, making it necessary(?) to invalidate the array slot later?
    
    
    
    
    Normally no, it can't be that the same CPU is found twice.

On other side, I tried to compile by hand DTS which has two the same CPUs
mentioned in IMSIC node and it allows me to do that:
(XEN) Latest ChangeSet: 
(XEN) build-id: 2cd98ed5a91bf443a02a9c4e83f05df4c1f7ec61
(XEN) !!! hartid:0
(XEN) imsics: unsupported hart ID=0 for parent irq0
(XEN) !!! hartid:2
(XEN) imsics: unsupported hart ID=0x2 for parent irq1
(XEN) !!! hartid:2
(XEN) imsics: unsupported hart ID=0x2 for parent irq2
(XEN) !!! hartid:3
(XEN) Allocated console ring of 16 KiB.

(unsupported hart ID=... is printed here because I told QEMU that you have 1
cpu, but in DTS I mentioned more then 1)

It seems like it is needed also to check if IMSIC node provides unique cpu in
its interrupts-extended property. And to verify that I think it would be enough
to check if msi[cpu].base_addr isn't 0:
@@ -408,15 +407,19 @@ int __init imsic_init(const struct dt_device_node *node)
 
         cpu = hartid_to_cpuid(hartid);
 
+        if ( msi[cpu].base_addr )
+            panic("%s: cpu%d is found twice in interrupts-extended prop\n",
+                  node->name, cpu);
+
Or probably it would be better just ignore by doing 'continue' instead of
panic() as it is done in other places in imsic_init().

Thanks.

~ Oleksii

    
  


--------------0KL4Rntryxg1Xxkrzb0OXOnq--


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 10:01:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 10:01:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011422.1389844 (Exim 4.92)
	(envelope-from )
	id 1uPIGn-0000cO-L4; Wed, 11 Jun 2025 10:01:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011422.1389844; Wed, 11 Jun 2025 10:01: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 1uPIGn-0000cH-ID; Wed, 11 Jun 2025 10:01:21 +0000
Received: by outflank-mailman (input) for mailman id 1011422;
 Wed, 11 Jun 2025 10:01: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 1uPIGm-0000cB-Hz
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 10:01:20 +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 ff71e741-46aa-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 12:01:09 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a375e72473so3338073f8f.0
 for ; Wed, 11 Jun 2025 03:01:09 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-7482b0c6b31sm8778568b3a.129.2025.06.11.03.01.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 03:01:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ff71e741-46aa-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749636069; x=1750240869; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Cs0AGDBPM7F/Niq6o67dpLWoKZh1nHnc+QG0epoXoa4=;
        b=gNx6Ugqwvp1ohoG4ZZPIABYa8EPgCGQz/055QZMSE1oWPkLRLPNfmPyrucLCA6vrlQ
         Wc4VTi/v16NyZP2W9TVd28ebieYeLKDfyhqO79FIObLHbSNikTKZ2ZkOYeaDuxbcmDCA
         OAt42rEbPX41MPHQQGP3CGI3Z6KeVlQcET+RUokVXHvUjxeALoV1UQX2lxUX42m/WlSi
         TFCGUYA/6J+9rcEkjL9Y0UwHXxM51lQTC3NcmNFz1g+c8dfkm/l+8GdUIKgel7ImeU/G
         OqMzykyIvcAAYMCxHhbUQwqPf+fl7hzg+iLa7UB3WJ1i3qmodaja4CVlOAsw0Z8cQ3Hg
         WVzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749636069; x=1750240869;
        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=Cs0AGDBPM7F/Niq6o67dpLWoKZh1nHnc+QG0epoXoa4=;
        b=A6wCJcwUqSrIyq7vw6vOiBwPK/jKPXbwUhNFIhvrVqRvTt6crDtJz3H+dhN4z065Wa
         yo/pklBEe/0iw9dC7FF1JRLB1QMPGPHrHv/wTy3inxk7L4xovcwUTofbrMkRJO0eHhVS
         QzHxT5A/y20ihOYKtgVVqF9lgWUMPMlu5HSBuLsZSEs5iDU3tPEJqvuAXUXWEYMNSIck
         s3pTtkm9qRKT1+9ewl7fLS5mFilK+07msyCH6F4st6j8dpomcU6dPEmJpPZX3dR7cblg
         7AHPwyvddgfrX0Qi/0hnUIhf4It9O2WmfPQ/kmcrMeGRoITiEOWTTWH/Hp9fm4DLb4NY
         S4Uw==
X-Forwarded-Encrypted: i=1; AJvYcCUtDWkLOTvasFIHEVXSEbDpSnIRD3lfZ8nftjsn4uY9us2WxvbcJar0rU3aEAWucleTl79xgP8jYtU=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz3y1TbyoXpCwXVZypM3FbcW598qC0IEO7O8kYYIa7itnAbKM7k
	70qYG0noBQCcFk3pnz/RwF+FBf8HVThXePNp2sGDYL8HCEm1sf/P2sNYjqfdiB/s2A==
X-Gm-Gg: ASbGncuxl4408EG9P4TQjUUxx/DRmyHHHlYvpGNaWyd88FIvJ9X5g0Ip4BVmvCTwBQb
	z17iZi1zJm8ahbLYIa4rfie5G+x8ygF3NV+7vAt8v2H6/WPsXsuFe90gziZ1OwLbYPd/dOyga9B
	J5kxkvfEpUibrpHkQKmUWCiIXMYJUKN7ZIPN185kKTYYY36WkTf37JnRqzR+wi9yOYalxxFKnpg
	xenwNMeAQ3lVEB16fzOAXAkPqnZHma5eA1IKOeyMHRu2jpQBs3Row28moDDj5OeQQyGzQ72Ht4Z
	CjWrAi85q4J8y3pccAyVPywKd2ilHv76aahCWhVHzdko9pEIlHdnF1It22OgCpSOGLqSBPP/MSh
	eRSiArpfW4k3xtY65FG4HuFOxIoPN5CSzuSlsh8JNN9nisqw=
X-Google-Smtp-Source: AGHT+IHgWevN18aoEVFZhhbuz8BPW2JHxVGYa+cnZcd+jaUy/nqyvSHNBKnYLIKjNmEJxsPrNDluPw==
X-Received: by 2002:a05:6000:4203:b0:3a5:1410:71c0 with SMTP id ffacd0b85a97d-3a5586dcff7mr2006686f8f.38.1749636068763;
        Wed, 11 Jun 2025 03:01:08 -0700 (PDT)
Message-ID: <9f2afc59-e55a-45d8-a521-0ad5aba61cdf@suse.com>
Date: Wed, 11 Jun 2025 12:01:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen: Strip xen.efi by default
To: Frediano Ziglio 
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: <20250610101228.24460-1-freddy77@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: <20250610101228.24460-1-freddy77@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.06.2025 12:12, Frediano Ziglio wrote:
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -238,6 +238,7 @@ endif
>  		> $@.map
>  ifeq ($(CONFIG_DEBUG_INFO),y)
>  	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) -O elf64-x86-64 $@ $@.elf
> +	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(STRIP) $@
>  endif
>  	rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]*
>  ifeq ($(CONFIG_XEN_IBT),y)

Oh, one more thing: It is bad practice to modify the output of a rule multiple
times. An interrupted or otherwise failed make (at the "right" position) may
then leave something in place which a subsequent incremental build would not
know needs updating (again).

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 10:02:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 10:02:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011427.1389854 (Exim 4.92)
	(envelope-from )
	id 1uPIHz-00018p-VO; Wed, 11 Jun 2025 10:02:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011427.1389854; Wed, 11 Jun 2025 10:02: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 1uPIHz-00018i-Ru; Wed, 11 Jun 2025 10:02:35 +0000
Received: by outflank-mailman (input) for mailman id 1011427;
 Wed, 11 Jun 2025 10:02: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 1uPIHy-00018c-4c
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 10:02:34 +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 31693ad7-46ab-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 12:02:33 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a53359dea5so2846755f8f.0
 for ; Wed, 11 Jun 2025 03:02:33 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23603405f30sm83706335ad.177.2025.06.11.03.02.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 03:02:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 31693ad7-46ab-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749636153; x=1750240953; 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=IDFEYH6KPSwND/ipPmubXP/0a9ioXtXTze0H3/30fzE=;
        b=C0Lf+/rEq/xa5g/r09zOq+HIMkNq1+jVNy6mR3ay4hD9hOCtPl+Z8Gi5tPobuqZREV
         atxumR9pWR8ioftPGAQYyF1hucBohES+SpZLDw9ydDfJvTkOgVW+BgPIkdMzQi9alqs6
         YYnlzc7hWJ2z53bl7f3uQwsAFit041s/pdbIegFPk7kHhKq6l0/V/7uHIWakUBIuVMlH
         0cAhQvQkkFg+A76bD0vk6cW+NrACrPxkcRfOuUHAAwBx95Ukp+zi4YYb7bVONG85IDLp
         bZdsl2IUVMrjQbOMS9MHtNTIlLe+osvObQ7KhivzrY7DtjpRA0pcnq4AeKcih1xeCj5D
         2Hbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749636153; x=1750240953;
        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=IDFEYH6KPSwND/ipPmubXP/0a9ioXtXTze0H3/30fzE=;
        b=lkLnJ9NsxApXyQpEYALfP0GnfpqIgS4b7D4x9lcTvfymV9nWCyeilw6HpXCd2A2TiF
         6XTsM+ngkED0V9TAyS1FVyL2KOGWB5kTD4u8wFiqH+Vrkq1PQMKfAe8kOzF7sCTVt08I
         fUL6wZEI2D7iAtL7PBSvQfa8keCHUztFk8ze3WqDOGG6xCu7n5m+3ex+xTD2cHl09D3u
         i4zIRhu08765CzdEA0l5BKSBPrBHOO/5as5TnDp8w5RTDWCh0X5PuSCnpV4qvH/3Ropo
         PzNcVZSgYxgZRe2U9j/nB+4ybkMS6b9mepCcawVw+C/zJTf56N7pr6jnNJ7Bu1LHrhqb
         /kew==
X-Gm-Message-State: AOJu0YzIUgofKQrFZxmOTsFFeNsSIo0821PPYqzDT0dAAQMJfOV24//t
	wdT97nyfDWbQA9QHzkQltN3iNc3DSehJi4z2TtS/xcABQmOnomWooR+N/R3wsn/6rSX5Kv/O1W9
	Ef+s=
X-Gm-Gg: ASbGnctwaBd5blcOngK5OygXmdf1/iouV3ahrdMLmKWRHjsSYj+hRecDZn0DcXWgMFK
	mDHs1BGJASFe3W5UO2ob5YH3F4X5m43JzFGAnBmYhTup/yQWCnGGEXmWPfFS4YIdjJ5fAg04XWG
	/0ux9PfXNG7ZqU4gtANrJzco33o8Sy4dyY9WdoLwFpt9gQK6udc9B6LW1bcmkz9ub2xEuG2si/d
	RNGLDapb0Lcg+XWB4kbXJ7BafmNAahL3nLsabn4mYVK7Xq/eh35EKeYL03M1wy7KIiZaF31+Qwf
	jN0hmgLfI49nfshUz6E+U1POZBi+05weDzU15PoC3K9r4vZWYkBh5rcQqPFxff1vmefMnsgrJnX
	5FzF45wn3qAcxCm3Kop31PsJkGRTb7ZckZDz17AZl5iG4fiA=
X-Google-Smtp-Source: AGHT+IGLgvZw8UxGCfePr5HgPqugyXukm8mXihNcKZj8rm2w5FmECgOHUdwPAX27Bwzo8+I8fQwhNQ==
X-Received: by 2002:a5d:5847:0:b0:3a4:eec5:441c with SMTP id ffacd0b85a97d-3a558a457d7mr1900723f8f.47.1749636152650;
        Wed, 11 Jun 2025 03:02:32 -0700 (PDT)
Message-ID: <1491ce61-6aff-4542-8bc1-d7db1324cce3@suse.com>
Date: Wed, 11 Jun 2025 12:02:30 +0200
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?= 
From: Jan Beulich 
Subject: [PATCH v3] x86: FLUSH_CACHE -> FLUSH_CACHE_EVICT
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This is to make the difference to FLUSH_CACHE_WRITEBACK more explicit.

Requested-by: Andrew Cooper 
Signed-off-by: Jan Beulich 
Acked-by: Roger Pau Monné 
---
Note that this (of course) collides with "x86/HVM: restrict use of
pinned cache attributes as well as associated flushing".
---
v3: Re-base, also over dropped earlier patches.
v2: New.

--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -232,7 +232,7 @@ unsigned int flush_area_local(const void
     if ( flags & FLUSH_HVM_ASID_CORE )
         hvm_flush_guest_tlbs();
 
-    if ( flags & (FLUSH_CACHE | FLUSH_CACHE_WRITEBACK) )
+    if ( flags & (FLUSH_CACHE_EVICT | FLUSH_CACHE_WRITEBACK) )
     {
         const struct cpuinfo_x86 *c = ¤t_cpu_data;
         unsigned long sz = 0;
@@ -245,13 +245,13 @@ unsigned int flush_area_local(const void
              c->x86_clflush_size && c->x86_cache_size && sz &&
              ((sz >> 10) < c->x86_cache_size) )
         {
-            if ( flags & FLUSH_CACHE )
+            if ( flags & FLUSH_CACHE_EVICT )
                 cache_flush(va, sz);
             else
                 cache_writeback(va, sz);
-            flags &= ~(FLUSH_CACHE | FLUSH_CACHE_WRITEBACK);
+            flags &= ~(FLUSH_CACHE_EVICT | FLUSH_CACHE_WRITEBACK);
         }
-        else if ( flags & FLUSH_CACHE )
+        else if ( flags & FLUSH_CACHE_EVICT )
             wbinvd();
         else
             wbnoinvd();
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2277,7 +2277,7 @@ void hvm_shadow_handle_cd(struct vcpu *v
             domain_pause_nosync(v->domain);
 
             /* Flush physical caches. */
-            flush_all(FLUSH_CACHE);
+            flush_all(FLUSH_CACHE_EVICT);
             hvm_set_uc_mode(v, 1);
 
             domain_unpause(v->domain);
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -618,7 +618,7 @@ int hvm_set_mem_pinned_cacheattr(struct
                         break;
                     /* fall through */
                 default:
-                    flush_all(FLUSH_CACHE);
+                    flush_all(FLUSH_CACHE_EVICT);
                     break;
                 }
                 return 0;
@@ -684,7 +684,7 @@ int hvm_set_mem_pinned_cacheattr(struct
 
     p2m_memory_type_changed(d);
     if ( type != X86_MT_WB )
-        flush_all(FLUSH_CACHE);
+        flush_all(FLUSH_CACHE_EVICT);
 
     return rc;
 }
@@ -799,7 +799,7 @@ void memory_type_changed(struct domain *
          (!boot_cpu_has(X86_FEATURE_XEN_SELFSNOOP) ||
           (is_iommu_enabled(d) && !iommu_snoop)) )
     {
-        flush_all(FLUSH_CACHE);
+        flush_all(FLUSH_CACHE_EVICT);
     }
 }
 
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2316,7 +2316,7 @@ static void svm_vmexit_mce_intercept(
 static void cf_check svm_wbinvd_intercept(void)
 {
     if ( cache_flush_permitted(current->domain) )
-        flush_all(FLUSH_CACHE);
+        flush_all(FLUSH_CACHE_EVICT);
 }
 
 static void svm_vmexit_do_invalidate_cache(struct cpu_user_regs *regs,
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -1929,7 +1929,7 @@ void cf_check vmx_do_resume(void)
         {
             int cpu = v->arch.hvm.vmx.active_cpu;
             if ( cpu != -1 )
-                flush_mask(cpumask_of(cpu), FLUSH_CACHE);
+                flush_mask(cpumask_of(cpu), FLUSH_CACHE_EVICT);
         }
 
         vmx_clear_vmcs(v);
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -3844,7 +3844,7 @@ static void cf_check vmx_wbinvd_intercep
         return;
 
     if ( cpu_has_wbinvd_exiting )
-        flush_all(FLUSH_CACHE);
+        flush_all(FLUSH_CACHE_EVICT);
     else
         wbinvd();
 }
--- a/xen/arch/x86/include/asm/flushtlb.h
+++ b/xen/arch/x86/include/asm/flushtlb.h
@@ -113,7 +113,7 @@ void switch_cr3_cr4(unsigned long cr3, u
  /* Flush TLBs (or parts thereof) including global mappings */
 #define FLUSH_TLB_GLOBAL 0x200
  /* Flush data caches */
-#define FLUSH_CACHE      0x400
+#define FLUSH_CACHE_EVICT 0x400
  /* VA for the flush has a valid mapping */
 #define FLUSH_VA_VALID   0x800
  /* Flush CPU state */
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3821,7 +3821,7 @@ long do_mmuext_op(
                     if ( !cpumask_intersects(mask,
                                              per_cpu(cpu_sibling_mask, cpu)) )
                         __cpumask_set_cpu(cpu, mask);
-                flush_mask(mask, FLUSH_CACHE);
+                flush_mask(mask, FLUSH_CACHE_EVICT);
             }
             else
                 rc = -EACCES;
@@ -5395,7 +5395,7 @@ int map_pages_to_xen(
     if ( (flags & _PAGE_PRESENT) &&            \
          (((o_) ^ flags) & PAGE_CACHE_ATTRS) ) \
     {                                          \
-        flush_flags |= FLUSH_CACHE;            \
+        flush_flags |= FLUSH_CACHE_EVICT;      \
         if ( virt >= DIRECTMAP_VIRT_START &&   \
              virt < HYPERVISOR_VIRT_END )      \
             flush_flags |= FLUSH_VA_VALID;     \
--- a/xen/arch/x86/pv/emul-priv-op.c
+++ b/xen/arch/x86/pv/emul-priv-op.c
@@ -1205,7 +1205,7 @@ static int cf_check cache_op(
     else if ( op == x86emul_wbnoinvd /* && cpu_has_wbnoinvd */ )
         flush_all(FLUSH_CACHE_WRITEBACK);
     else
-        flush_all(FLUSH_CACHE);
+        flush_all(FLUSH_CACHE_EVICT);
 
     return X86EMUL_OKAY;
 }


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 10:18:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 10:18:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011434.1389864 (Exim 4.92)
	(envelope-from )
	id 1uPIWx-0003BG-7L; Wed, 11 Jun 2025 10:18:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011434.1389864; Wed, 11 Jun 2025 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 1uPIWx-0003B9-3d; Wed, 11 Jun 2025 10:18:03 +0000
Received: by outflank-mailman (input) for mailman id 1011434;
 Wed, 11 Jun 2025 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 1uPIWv-0003B3-Fd
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 10:18:01 +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 59499273-46ad-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 12:17:59 +0200 (CEST)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3a536ecbf6fso2932653f8f.2
 for ; Wed, 11 Jun 2025 03:17:59 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-7482b08391asm8793097b3a.86.2025.06.11.03.17.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 03:17:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 59499273-46ad-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749637078; x=1750241878; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=UEogMPwpERGiAZiPE7KWk2Kd+BF837mTVmLORzshSFI=;
        b=BgcASIa3jr4zwF3Kq7vLYWMlwfYaoMxyc3RRNj86aRJnExVJbq19KjxRONivwwN/Cp
         jMrLBlI5wlG8qtNYQyH8dpqz2zITkuFnder5ZupYKMYKK+Jt2ZQRUGHq3AEH1YORytef
         BQLikatMA9MNAWT6BEC8Ijzzdg14MY8KfEqFaesk1Su+DF/ReSFHEm6zKIRA3lpjYXQw
         XyiJDtUyyQPNrM//gD38P5XAv0KRnup+tw1pJVBOY5dBb5p3ZD+YaB8ophPR4OpUEskC
         UZxmW7kzwnahkSA1VYNtTS/bxzzN4wPNKmW2cwLwTCuwo5b8vhgzFXQ4wX4UYb7XCz2v
         QhSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749637078; x=1750241878;
        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=UEogMPwpERGiAZiPE7KWk2Kd+BF837mTVmLORzshSFI=;
        b=OdcBMRwubLxz/tZOsqSNeQ09lYyMMSZV97RqHReNv+RgG9+6M6tixtHwgPuqpWeBkP
         YGPQ86tfZCX2xjgNt+hrLvWLPxlMgwBgv3FA6bDXRTBUU9O0JrSW9mcsjoVugrWLn9Tu
         +GikK3xjlM7f2FqiyU99cU6wnvSHTlR/xr1HL+VKK/OQOncP4jyqkGlmRmmpcH0/qY9S
         FPDYlTRzlb8njJU2O+UkImDVzJEP10rkla1a/NLhYsYtE2q7qSD87SBFS8ZsRFiWtsdl
         0dbig4mZ7Rtv4YTfaq3wyPchdtPWFdeykXPbfWVeuBcuYFlIUSKmjRntv/r8trerOw0a
         xz5w==
X-Gm-Message-State: AOJu0Yzuhu5f+Z5l7PKyALU4T9IgWMNU3WhCird3AZ5iVezGtS4Adado
	j27Lpipcs8V3WlbE2TCzBG2HFcqN9iEnG3kdJqn+Ys7w2+crRjgk3LwA611DkMhCkg==
X-Gm-Gg: ASbGncuny5y8oq3cRbT5dNf67CYUi1C3Say2JEZpdfJuPz2dPRRR2Yojg9rItpTjGTr
	6BOGZ2kr+/mxSkyh7kihZl1qA5kv4szrEPXud83kho8mer2bh+42PVGY65QoSnuRn4ZhB32WV87
	k6DTvncFrGE+Gj9R0VICPJ/WPp+vmhm1KMCsYlnVV96jkgen2ocg9ncVq6XzdZ6SmXNOs2fIJXj
	SGKve27yHjOzx7sQq1t4t2d1gI1k5BboW/ov9OD/oDc79jgg0ertm+l9fk4dvN4U6RRqU6uOprb
	eg6eOAM9IA9CSMNB0mCSG7UVZ0NLPwJBSnFNynNwH46/cSk18txQHiPfkFrIgiRPMUHzIgca8Pu
	6ONMwtIXMdBoKvxH0WB/+KeVo9bTwv7wy/mXlsNKdBHVLUqc=
X-Google-Smtp-Source: AGHT+IH9KXz/khCp6/ytJLgv36nIa/8Cp5NKLBNjhtA15GJEfWQcFq/EzwEtfSmmofEQ59m7jiiwuA==
X-Received: by 2002:a05:6000:2409:b0:3a5:2cb5:63fa with SMTP id ffacd0b85a97d-3a558688b57mr2171782f8f.2.1749637078569;
        Wed, 11 Jun 2025 03:17:58 -0700 (PDT)
Message-ID: 
Date: Wed, 11 Jun 2025 12:17:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] x86/HVM: restrict use of pinned cache attributes as
 well as associated flushing
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper 
References: <78b3ddeb-4317-4d54-ad52-9eb03bdf7942@suse.com>
 
 <6e9e84eb-f98b-4c06-8952-03aecc82c0ea@suse.com>
 
 <5f8d694f-e712-4869-879f-80b2c4907a45@suse.com>
 
 <3470dcc8-f08a-4a00-8760-b3564d78e638@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.06.2025 17:54, Roger Pau Monné wrote:
> On Tue, Jun 10, 2025 at 04:13:40PM +0200, Jan Beulich wrote:
>> On 10.06.2025 15:24, Roger Pau Monné wrote:
>>> IMO the added complexity here is not worth the performance
>>> improvement, not without a clear justification that it's needed.
>>
>> Well, okay, I'll simply consider the patch in this shape rejected then.
>> I don't see much value in wasting further time on it.
> 
> The code is already there, so I think there's value in this patch.
> Did you see my suggestion in the email yo uare replying to about not
> needing to add the is_iommu_enabled(d) || cache_flush_permitted(d)
> checks?

I did, but it didn't look like we were able to come to an agreement.

> With that dropped (if it's indeed OK), I would be fine with Acking the
> patch.

I guess I'll make one more try then, removing the instance where the
setting of the "flush" local is made conditional, but retaining the
-EPERM return path as was.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 10:19:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 10:19:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011439.1389874 (Exim 4.92)
	(envelope-from )
	id 1uPIYU-0003ju-GZ; Wed, 11 Jun 2025 10:19:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011439.1389874; Wed, 11 Jun 2025 10:19:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPIYU-0003jn-Dq; Wed, 11 Jun 2025 10:19:38 +0000
Received: by outflank-mailman (input) for mailman id 1011439;
 Wed, 11 Jun 2025 10:19:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uPIYT-0003jf-8u
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 10:19:37 +0000
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com
 [2a00:1450:4864:20::42e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 929766b4-46ad-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 12:19:35 +0200 (CEST)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3a51d552de4so3530345f8f.0
 for ; Wed, 11 Jun 2025 03:19:35 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b2f5f899ceasm6906310a12.73.2025.06.11.03.19.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 03:19:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 929766b4-46ad-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749637175; x=1750241975; 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=aDoIDq6YgdTc5VfakrhU/gJLnYd10GkjT0bAtWU5IDg=;
        b=ScmsTNu90/llf9QvuFvQ0HP57BHI4on8TnjrnigRb3DBT1VJ9rjXtcI5+HibPgFQbD
         n2TQQvlRgX/LrrleStovi5E+1OhYgGFRrukCLqcMEaP6nSKUydz568Z72AFO0KjDTwPp
         /FsLI8CfMrS/JETyf/JrqLhTD7/jNP4xqoicJOjvqoaiNfftiiKV3eJ+lVHz20bO/3O+
         p4MGURx35yacL2UlcNKh/NDbQswxBw0Rt2W94kC1JGOCKROTFxlgxA74jduh8xFXWaML
         MHhGi8g6wh5V6Oja9WGiCvv4m0oSVSmW3Vp/eKzmQdQeQCubtrzehpD7Ln94uCKhpbY6
         Xl5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749637175; x=1750241975;
        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=aDoIDq6YgdTc5VfakrhU/gJLnYd10GkjT0bAtWU5IDg=;
        b=E1XaxvwCDTO/1C27x3WEFtuv2z1E7RZuFe8/JVLDU2Fy3OOvRsaZCNWPgg/euEyqZz
         s6T6qFsNSyavaW+RvKGel2InBQ9Yd6RZwFW0S87NKtxaY7aJOdCAWm7XFg9fSLnd5MMW
         dZH3lnJZapB2L2ZbfsgPYVYSKfWMlmFypJouzKWpXBJV7+TfdGfdJ1a5xmkbUrMxm2Xc
         ccsQKqd0tHsAUtjGgGjHjP7iYvZVPBOGteKsTOBHJ5Vl2JyBnb4jZbUxnOJQSwrmamZy
         F7m3CBoQWYcCjMe0LPUq252IlcDcwwqH08QGkqtdjfSX/EBoEU4TxlZEuVl73H/9sUH9
         QZ9A==
X-Gm-Message-State: AOJu0Ywro0712rHywYjWo/xaMO/nWSG6kVt2TgJhV9mzuqOTM6yvFDAM
	c8jTgQLC1R1uklGRP+ZgFy/Xglf8MM0g7wM8COwgArScyJDIJ+kbGLMJaXtSdDrvctTyhFpqlGn
	yDCA=
X-Gm-Gg: ASbGncsUefO6+VfOxz18EF3Xny7PHrpjCaYdim7ydM+PN2Y1fNqd0regX/TDNzKtkQU
	6faCkhzsDORR04r/Z0BuPNrGhFtTcyHim2Ug459MOcfh02OXPAAttulclfrQQg/M9oQKhEGRASP
	QBQlwFzABUSk06I1sTBBf+eVgz7L6vn/WBA+9yDaC9LEh8oTPPzavk9zbY7Tfku/W9mzdWYJQtf
	CiH26O22ykdDNmxcXxxVfLR8m4e11++IcfSwfFQyehGeTYneKhUq3y1hPM7BYgcFp6n6OJiCs6F
	Ov8JZsoEVNDmqsMy6z8tL3Mwbtb31FWelTds0qafrUX3E1Die65CU811+VYKdUOlvgJEpaC1+aY
	ccPZls4A/yr6OPI/i+lAPK7yoRBzMfoVw/YTEhwLp1Rv0X6A=
X-Google-Smtp-Source: AGHT+IFEBbW0kPSs8I7ptHmP0SIgPB6M8BWEWo/cs5/Qgi2/6p6h8cDZ1GF8OOnDLbSurdAURei9cw==
X-Received: by 2002:a05:6000:24c7:b0:3a3:6991:dcbb with SMTP id ffacd0b85a97d-3a558a92771mr1806341f8f.12.1749637174534;
        Wed, 11 Jun 2025 03:19:34 -0700 (PDT)
Message-ID: <35ba8ca3-ed00-491e-a782-2974597cfdb3@suse.com>
Date: Wed, 11 Jun 2025 12:19:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Jan Beulich 
Subject: [PATCH v3] x86/HVM: restrict use of pinned cache attributes as well
 as associated flushing
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper , Wei Liu ,
 =?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

We don't permit use of uncachable memory types elsewhere unless a domain
meets certain criteria. Enforce this also during registration of pinned
cache attribute ranges.

Furthermore restrict cache flushing to just
- registration of uncachable ranges,
- de-registration of cachable ranges.

While there, also (mainly by calling memory_type_changed())
- take CPU self-snoop as well as IOMMU snoop into account (albeit the
  latter still is a global property rather than a per-domain one),
- avoid flushes when the domain isn't running yet (which ought to be the
  common case).

Reported-by: Andrew Cooper 
Signed-off-by: Jan Beulich 
---
At the expense of yet larger a diff it would be possible to get away
without any "goto", by moving the whole "new entry" handling into the
switch(). Personally I'd prefer that, but the larger diff may be
unwelcome.

I have to admit that I can't spot what part of epte_get_entry_emt() the
comment refers to that is being deleted. The function does use
hvm_get_mem_pinned_cacheattr(), yes, but there's nothing there that talks
about cache flushes (and their avoiding) in any way.

Is it really sensible to add/remove ranges once the guest is already
running? (If it is, limiting the scope of the flush would be nice, but
would require knowing dirtyness for the domain wrt the caches, which
currently we don't track.)

This is kind of amending XSA-428.
---
v3: Drop a conditional and move a comment. Further amend description.
v2: Use memory_type_changed() and conditionalize call to
    p2m_memory_type_changed().

--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -582,6 +582,7 @@ int hvm_set_mem_pinned_cacheattr(struct
 {
     struct hvm_mem_pinned_cacheattr_range *range, *newr;
     unsigned int nr = 0;
+    bool flush = false;
     int rc = 1;
 
     if ( !is_hvm_domain(d) )
@@ -605,31 +606,34 @@ int hvm_set_mem_pinned_cacheattr(struct
 
                 type = range->type;
                 call_rcu(&range->rcu, free_pinned_cacheattr_entry);
-                p2m_memory_type_changed(d);
                 switch ( type )
                 {
-                case X86_MT_UCM:
+                case X86_MT_WB:
+                case X86_MT_WP:
+                case X86_MT_WT:
                     /*
-                     * For EPT we can also avoid the flush in this case;
-                     * see epte_get_entry_emt().
+                     * Flush since we don't know what the cachability is going
+                     * to be.
                      */
-                    if ( hap_enabled(d) && cpu_has_vmx )
-                case X86_MT_UC:
-                        break;
-                    /* fall through */
-                default:
-                    flush_all(FLUSH_CACHE);
+                    flush = true;
                     break;
                 }
-                return 0;
+                rc = 0;
+                goto finish;
             }
         domain_unlock(d);
         return -ENOENT;
 
     case X86_MT_UCM:
     case X86_MT_UC:
-    case X86_MT_WB:
     case X86_MT_WC:
+        if ( !is_iommu_enabled(d) && !cache_flush_permitted(d) )
+            return -EPERM;
+        /* Flush since we don't know what the cachability was. */
+        flush = true;
+        break;
+
+    case X86_MT_WB:
     case X86_MT_WP:
     case X86_MT_WT:
         break;
@@ -682,9 +686,11 @@ int hvm_set_mem_pinned_cacheattr(struct
 
     xfree(newr);
 
-    p2m_memory_type_changed(d);
-    if ( type != X86_MT_WB )
-        flush_all(FLUSH_CACHE);
+ finish:
+    if ( flush )
+        memory_type_changed(d);
+    else if ( d->vcpu && d->vcpu[0] )
+        p2m_memory_type_changed(d);
 
     return rc;
 }


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 10:19:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 10:19:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011441.1389884 (Exim 4.92)
	(envelope-from )
	id 1uPIYZ-00040E-SS; Wed, 11 Jun 2025 10:19:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011441.1389884; Wed, 11 Jun 2025 10:19: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 1uPIYZ-000407-OA; Wed, 11 Jun 2025 10:19:43 +0000
Received: by outflank-mailman (input) for mailman id 1011441;
 Wed, 11 Jun 2025 10:19: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 1uPIYY-0003jf-BD
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 10:19:42 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20620.outbound.protection.outlook.com
 [2a01:111:f403:2416::620])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 94a91711-46ad-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 12:19:40 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by CY5PR12MB6432.namprd12.prod.outlook.com (2603:10b6:930:38::8) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Wed, 11 Jun
 2025 10:19: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.8835.018; Wed, 11 Jun 2025
 10:19: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: 94a91711-46ad-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=y+4lHFb3Uo+AiKOMaMa5bGo9wB9dgrnW/8wiWVpGK3+Ps2Je/olwJFDs4U6GkkkjA4aPrbZ8ZfqJQ5DriQqBcJzIdGSy4oQ9ZP4w5Feja2KCgACBeTqvETG02f5uwEhXLjeH/sRkkcphLEUjyc6C5wWgkrrCZeydbsN8I7st+mXzVcuX6jYTohEUoH1sF0vgALXvYlxJKaNPmx58t025roZrjnuAHsxq31BtFJD88EYBo/pn88x2Q2OMmexcYKP2p4+NXzVp1QhcOEN8xu6yiO2G90nDsOFtC/FUe9KNaKqnEONIwpXrEjL6DP9p2sEj9vgVldhxL463ov5WbjT/4Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=qUApHNUtmZahn7IEFT++4Q19f9uAA00DwxrlyTg1OHk=;
 b=YNb3FlT3lYVpEvTKqpHfnXgsTbuIeNOr6rXQabpObohZF5IjVzCxNaI4r8OWn6i+c3JPEPOhHrpUoESmOxpVwXKl65CbBOvqRB3oznwPJwG1IsHs0kQYn/zBvPmR3+iANezxxiVN2HEQKkgoopQWJi5oAgEApEVIeHCSic9LBMIHw8hXKJ9xuCTOCpIgceRkj/v+czVNzHaFZIowNZM2H/g42noyc8Tf6qkQsTxZPHiF7oEV31MTmT4rAVZLmbmLvaN0Xl6muHm7ujeKSSNjek0OXmKCKMbLxrLDhew/CHjd/Uixaj01yPPBGucbJKqTfIgeEthRgMxO1K225MK7OA==
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=qUApHNUtmZahn7IEFT++4Q19f9uAA00DwxrlyTg1OHk=;
 b=R1mt5ac2hjsK9/d9QLJt4MVkUgWa1W6BLFtNcwaih4R1T1LD2Gk7+r1EWuGRYwp4/nkp4qzdXLyN+/wOtk6S2TJ0qQYPgT64WjP+ITc5xIozrlMOSxJH0ehRIG/Bj/nftfVupLwYqwf55BiIdqrVRb5XT2butY8yK2B3ihdCjeU=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= 
CC: "xen-devel@lists.xenproject.org" , Jan
 Beulich , Andrew Cooper ,
	Anthony PERARD , "Orzel, Michal"
	, Julien Grall , Stefano Stabellini
	, "Huang, Ray" , "Chen, Jiqian"
	
Subject: Re: [PATCH v5 04/10] vpci: Refactor REGISTER_VPCI_INIT
Thread-Topic: [PATCH v5 04/10] vpci: Refactor REGISTER_VPCI_INIT
Thread-Index:
 AQHbziMOHCuaHG697kCTYWoBETQpzrP0lKSAgAGsWwD//4WWAIAAI9IAgAUkMwD//5c1AIAAk1OA//+AeAAANIYcgP//sryAgAJNkYA=
Date: Wed, 11 Jun 2025 10:19:34 +0000
Message-ID:
 
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
 <20250526094559.140423-5-Jiqian.Chen@amd.com>
 
 
 <752cff02-cef6-4a4c-80b9-eba3bbf9b264@suse.com>
 
 
 
 
 
 
 <6a7a1ab8-aabb-465b-bd22-a2bc1597b83b@suse.com>
In-Reply-To: <6a7a1ab8-aabb-465b-bd22-a2bc1597b83b@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.8835.017)
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_|CY5PR12MB6432:EE_
x-ms-office365-filtering-correlation-id: e865ac76-104b-467e-7459-08dda8d17680
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?N09GZGw1YWF5T2VwYW5OQnp4RWxVK0RjdmFhdXFyYTg1ZFM5SEdSMFZpTDVq?=
 =?utf-8?B?ZjFwMHVoT2dDYisxWm1EYWhXdWJmNjNIQXJiUnNxVHptcDErR0d4NXFPQnhB?=
 =?utf-8?B?R2NiVVhwUDZSV2F0YzMyVDdKVk5ySjRxb1ozNG5pQ3FSdjM5c2ZvQjlhN2xa?=
 =?utf-8?B?UVRzcDJCaFo5bE44eXMrNysrK3V6cDBtdFpiYUhyTmF2cHVuK3pZcnNsTXl1?=
 =?utf-8?B?ZXRhTzY1ekFjN0Vwd3NQQ1F3S1JkS2RkcXVwMSs3VG5SeFJOT0JZNHdxWm5W?=
 =?utf-8?B?NWRWeUl4L29IZVhUVnlMS1JUTitaNDJnZFpqaEVsYWswUnR4VHlTVjR0NFdn?=
 =?utf-8?B?ZFIrZU1hdWI2UzhhQVowemhrNnBVVDdGR1EzbWJiR25MRnlMY2FiTTNjcm9P?=
 =?utf-8?B?Q1laQ2tKRUVadVU2d1NwQjNTOUdIaXVubnV6ZW15T21FS0Z1ZVJ6YkRiOTBj?=
 =?utf-8?B?alJ1VFVyTkhZQk1STEppS2hIMjUzUncrTXV2UGYwdDczOVBxYXNNWlVkSVJt?=
 =?utf-8?B?WHdENnRvV0lGanVBRFhIcnRJTmt1SjlHNllnaGV5U1lQQ0g4M3drSWRidTcr?=
 =?utf-8?B?bUhLeGExZE00TzZTQmYwNXl5S3hKd0hsOWx4MWpHbHVqSVF5K1VNWXNaV0U1?=
 =?utf-8?B?YWNMTFlIU0tKcEk1dXVYVnpmem5yZ3RrT2Jra0FsVkt0dUVHR1FmamlteGtw?=
 =?utf-8?B?V09hYzNIZVZ1MHY2NDdoK0d0WW5uTkVxTU9KbEErVmQzWGVoUUh6T3grNXJi?=
 =?utf-8?B?NGU1N09wWkFKSlVkVStjWTRCOTlpS1FoWkFnbXhuc2xNdGY4QXpnWVIzZ3E5?=
 =?utf-8?B?M2VLWFpuWHkwLzBKc3g3bE1QemR5WFRBdXB0UkhFS2pYRkNFN1Q3TmdkVmdw?=
 =?utf-8?B?c2gzWW14SnhXakV2R0JzVmlHZG85UFg3SzlmYVRzYTBjOXNKSDFIWU9ZbWZj?=
 =?utf-8?B?R1ZBNTZqWWVMMHhpdkhoVzVHM1c3K1I3c0o2NlF4c3VtYjl5OUlkK1BOaldD?=
 =?utf-8?B?VWFKWXQ3VlU5MUYrUUFpZEFVMVF2QlYyS1krVlY1TkR1SkpadWdzN3krY3Zv?=
 =?utf-8?B?Y3IxVUFSZzJNM2NoK1Y5b2FJWnN1eHJCWU1BclZqUm9pWHhvUVVrVTBPaWVx?=
 =?utf-8?B?U2N5djdtVlUxbWZsZDI2b0xYRnhDV28zMzVEQkwwU0dkajh6cFdSNm9lWFRW?=
 =?utf-8?B?LzFBd1lSUTcyRGZSN1VTeDlDRVVHWE0zaFZCeTkrclBRKzdYZ083N2RDNlJ5?=
 =?utf-8?B?OWZtRXl5QnB0UzA4NERiM0dCU0NqT3dxQjdMbGNvSmswZmRZNmh2VzFaL1Vm?=
 =?utf-8?B?TmUwUkNKS1JTd2F1ZE92ZSs3RUF2S1NtK08wbGp1MTAxYStTTnFCb1pUajJC?=
 =?utf-8?B?NEhuMElkS24yZW1IUWtHUTJNQ1M1SmdIaXA1M24wNm9Qb09NZks1OUZKbVZ6?=
 =?utf-8?B?TmJuSUl0dTUzWktPa0o3R1dhSzIrTFhpMitzWkxjQm9aRmZtck1oVlpIaEUy?=
 =?utf-8?B?c2FLMlN6UnZKdjdoV2ZiaGNERllTNGdYVmFpeXBBZndiYjFxVitiRHJQWXF4?=
 =?utf-8?B?RDNtUjlWaGs0RVFoOG1LOE5nSHJDK3VhNFE3VVQwRDVYdmhqSitSY0FFNmQw?=
 =?utf-8?B?ZzFkb1kzM2crQnNiRXhrUVFKcEVvemdEZ1RqNVhUdUg1QitLcVNvR01JdVFI?=
 =?utf-8?B?cndhajVuUDJZTUlJSUJFZ3lIck0xTW13YnBaZFNJaWYxaWt1dzZYWDF4SXBR?=
 =?utf-8?B?V0V6aEgvMVhkZllEUGZLRU9XQTRLQ0diR0hsR3IwQ3lkWHNsNEw2d0pUckY2?=
 =?utf-8?B?c3FFcTVYaEl5cTVJNHhrNmJyTW81YnJvOVBkZ3gwL3R1dWlKN1A1YVhQYXVr?=
 =?utf-8?B?RjNJQ3lrWlVJTENxZkVad0xua0J3QTVsd0VvK2NGdlJDZ0RlOWlnYS9DYVNx?=
 =?utf-8?B?UXlCd28zMEVYV1Rkd0dsYXdSOWxSRi84bFVyNzNsK2lQcllEM0JuT1FSdVhR?=
 =?utf-8?B?Z09pQUlFbVNnPT0=?=
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?TVllN2dVUEJaNk5LeGRBN3Q1OGVycjM1bzlUN1hicGJHRktrVnVqclVTSUd5?=
 =?utf-8?B?cEg0eWlON2tHVjZVOHphMEZzNkowWmIwYUkvdUJHZ0tPcXhSTmVjSWZoQlg4?=
 =?utf-8?B?eEJQRTBMZmdjSytnODM1ejRibmZyalJjYVk5VkVkMXdndGRIbXFGRUdCWjRh?=
 =?utf-8?B?aXphaTFmREZ0RVA5TFFNOGxIbVhlVmxQUFgyR21VeWpwUjU1dE1laldOU3pH?=
 =?utf-8?B?WTR5YzZIdEhtdUNWVjlmSER1L2dBMEVETURZejMza3ZSWTJyU2xSdVNYckxu?=
 =?utf-8?B?Q2RIcEJJRW95Y09aZ29Wc2s2MW9YUGdybXlCWk5JTmlvV1JucUNISUdiTjh3?=
 =?utf-8?B?UTAwZzFkdUpnOXRkZzE3UmNrdzlhSTltRitUWjYvaWEzNXQwQ0Y3NGN0a2N3?=
 =?utf-8?B?Z3Jka1FpbWtLdi9WY3dsaEZadENDN0VwRXpLdHlFUVEwZGY2TGpmZEhORTFF?=
 =?utf-8?B?L0hVV1hiQWoza2tYYVEyaC82VlI2b3VEdmJxSmV4KytRR1hjRFgxR0phQzFM?=
 =?utf-8?B?QjRFa29CWjAvWFcyVmJFNlMyZE90SFgrV2VMeHNrSlVUYXJVSlBKVjZmSG1T?=
 =?utf-8?B?VXJ0UGVIeUZmK0thOVZGU29YQ1RTaXI0VThJOVdNZkZHUGJVVkVXaDJFR3Bm?=
 =?utf-8?B?MHo0Y0V2bkpPRTNDbDZDL2Mwa0JkYWFyTDluQ0grcXpDSVZOeXBvQmUvdEhL?=
 =?utf-8?B?V2xTYkt5ZUlOWDV3ZUpXaTE5ZHcrQXMybnFSTVIyKzVpYSt5L0ZiVHdPQVJZ?=
 =?utf-8?B?ZzRHNlA4N0tGYW9UR0xmVkFjMUwzdkRUL3BKbVdsUzBxZWNncGpmN3M0bFdu?=
 =?utf-8?B?R3I3N21MdDVJUzEzWVIrdkVkN21NSHhDcUNmVm9yM3g2MUlhT0VPUlhzRTZu?=
 =?utf-8?B?RHgrbFlTOUM5N2JXU1RyVU1zd05YNmtHM3E4YVpHM3dHK2NxM3F6TG1WN3Zz?=
 =?utf-8?B?czN5WDZIUFk0ODVoc2t1K284RWh5TUZMRWNGRjk1OTRZSmRGN1NKV0pmS2tt?=
 =?utf-8?B?SFBwZU0wRFJMbUJ5cUVCNzVpUVZKRWNyMWpUQlYxd2J0ZTFDNW5Pb0M5dTNr?=
 =?utf-8?B?N2JJRnk4NjBhK1ROMXNHMk9MdUhVK29PMlkxU05aMGZSTC9HZUxtRXM1YUJY?=
 =?utf-8?B?anhmUmFqL2x3bUx2a2VxS3JhUzJ1SFRIcjNVZHNiRVM3WlpFTHAxMThpWmt4?=
 =?utf-8?B?WFhTUS9QQzRzSHQ4ZWI3NkpZQSt0R2tBdXp1WG5nTmZrOTBjVkp6YlRPT1RO?=
 =?utf-8?B?blJWVGxiR2gvM0RXWEF4bVZlYjNnY2RTekJhOUhxeUo3N2t0cVhZQ0JPdUgz?=
 =?utf-8?B?bTVEdmxwYWtwcEdxS3g4dUtVQXVJbEdnYjNSV0FNd205ZFRRQWhiTUpWTWlJ?=
 =?utf-8?B?NDlrcCtaTVRtQTBvZ0o0QjMxbWR5SGF3TmlZSjhmeDRpS0pidG16UktOWmxT?=
 =?utf-8?B?TGpQOExWaXJCRUs3RHBOTWtLSjBaS3o4RGd5UmJzdTE1bHUwbkxqYU4wWCt4?=
 =?utf-8?B?ODZsaTVaQ1dYOUdKaXdJYldQWEJZQnM2ZDFPMFgvbFJzbFFzUm9RaHpVMmRk?=
 =?utf-8?B?SjlBb25GOE1Ma05HbXlGRE05a0hYSXg4RUpqMDM5ODFWdUw3WXhHaGhJU0U5?=
 =?utf-8?B?RkxrSTczRkozeks4WDRGbzRuZWRSQkhkZGxKS0FNeXVyczcrQmkzbWhmRkQ1?=
 =?utf-8?B?R0VsYUo0UklnKzdpYytmZ2svNG1Fa2hVOTQ3Q3dnclJZbDFaVjFGQjFYeGlv?=
 =?utf-8?B?ZWJHelNRZXZLZ1c1MkJmVmxER0J1TkhENFJmN21pYWN3Wm5kWG5HUG5lMnJO?=
 =?utf-8?B?UWdxWDlaY1NGUUd1QlRuamg4V2ZpWVdLTUV6NFdHRGhhak5lYWc2cUNoL0t0?=
 =?utf-8?B?UVdYbU9kTVdUcFloeG9FU3lZRGRUTjd6MTI0cFlPeWtKUk5XQ2ozS20wRnpK?=
 =?utf-8?B?VjgyMVJsMFFGNE9UbUxZckFna2dPWm45c3FFREhZZ09Pamh5Y2N3MVphQUZ2?=
 =?utf-8?B?TVI5c1Frc1RFaUMwby84RnJna2xOOEd5S2RwN2MrMnhWdGpDSGUyMENkazZQ?=
 =?utf-8?B?RjdqZkhJaWJRczNtVExYT3VEU1VNTHNqUmFhWG42dmphNkpCSEordjdCV090?=
 =?utf-8?Q?6b6M=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <644CE52FBE58374DADA3E2F84F2736FD@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: e865ac76-104b-467e-7459-08dda8d17680
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2025 10:19:34.5953
 (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: EbnJo8mJc5uo4YCitpXYh73Mm0WU7bbAldJZKLhuzWSS3NVsz+JDT1Kcg6Iw8Vl8oIU/xSRQumdP8neptX2dJQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR12MB6432

SGkgUm9nZXIsDQoNCk9uIDIwMjUvNi8xMCAxNTowOCwgSmFuIEJldWxpY2ggd3JvdGU6DQo+IE9u
IDEwLjA2LjIwMjUgMDU6NTIsIENoZW4sIEppcWlhbiB3cm90ZToNCj4+IE9uIDIwMjUvNi85IDE4
OjQwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOg0KPj4+IE9uIE1vbiwgSnVuIDA5LCAyMDI1IGF0
IDEwOjE4OjQyQU0gKzAwMDAsIENoZW4sIEppcWlhbiB3cm90ZToNCj4+Pj4gT24gMjAyNS82Lzkg
MTc6MjksIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+Pj4+PiBPbiBNb24sIEp1biAwOSwgMjAy
NSBhdCAwNzo1MDoyMUFNICswMDAwLCBDaGVuLCBKaXFpYW4gd3JvdGU6DQo+Pj4+Pj4gT24gMjAy
NS82LzYgMTc6MTQsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+Pj4+Pj4+IE9uIEZyaSwgSnVu
IDA2LCAyMDI1IGF0IDA5OjA1OjQ4QU0gKzAyMDAsIEphbiBCZXVsaWNoIHdyb3RlOg0KPj4+Pj4+
Pj4gT24gMDYuMDYuMjAyNSAwODoyOSwgQ2hlbiwgSmlxaWFuIHdyb3RlOg0KPj4+Pj4+Pj4+IE9u
IDIwMjUvNi81IDIwOjUwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOg0KPj4+Pj4+Pj4+PiBPbiBN
b24sIE1heSAyNiwgMjAyNSBhdCAwNTo0NTo1M1BNICswODAwLCBKaXFpYW4gQ2hlbiB3cm90ZTog
DQo+Pj4+Pj4+Pj4+PiArICB9OyBcDQo+Pj4+Pj4+Pj4+PiArICBzdGF0aWMgdnBjaV9jYXBhYmls
aXR5X3QgKmNvbnN0IGZpbml0IyNfZW50cnkgIFwNCj4+Pj4+Pj4+Pj4+ICsgICAgICAgICAgICAg
ICBfX3VzZWRfc2VjdGlvbigiLmRhdGEudnBjaSIpID0gJmZpbml0IyNfdA0KPj4+Pj4+Pj4+Pg0K
Pj4+Pj4+Pj4+PiBJTU8gdGhpcyBzaG91bGQgYmV0dGVyIHVzZSAucm9kYXRhIGluc3RlYWQgb2Yg
LmRhdGEuIA0KPj4+Pj4+Pj4+IElzIGJlbG93IGNoYW5nZSBjb3JyZWN0Pw0KPj4+Pj4+Pj4+DQo+
Pj4+Pj4+Pj4gKyAgICBzdGF0aWMgY29uc3QgdnBjaV9jYXBhYmlsaXR5X3QgKmNvbnN0IGZpbml0
IyNfZW50cnkgIFwNCj4+Pj4+Pj4+PiArICAgICAgICBfX3VzZWRfc2VjdGlvbigiLnJvZGF0YSIp
ID0gJmZpbml0IyNfdA0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IE5vLCBzcGVjaWZpY2FsbHkgYmVjYXVz
ZSAuLi4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IE5vdCB0aGF0IGl0IG1hdHRlcnMgbXVjaCBpbiBw
cmFjdGljZSwgYXMgd2UgcGxhY2UgaXQgaW4gLnJvZGF0YSBhbnl3YXkuICBOb3RlDQo+Pj4+Pj4+
Pj4+IGhvd2V2ZXIgeW91IHdpbGwgaGF2ZSB0byBtb3ZlIHRoZSBwbGFjZW1lbnQgb2YgdGhlIFZQ
Q0lfQVJSQVkgaW4gdGhlDQo+Pj4+Pj4+Pj4+IGxpbmtlciBzY3JpcHQgYWhlYWQgb2YgKigucm9k
YXRhLiopLCBvdGhlcndpc2UgdGhhdCBzZWN0aW9uIG1hdGNoIHdpbGwNCj4+Pj4+Pj4+Pj4gY29u
c3VtZSB0aGUgdlBDSSBkYXRhLg0KPj4+Pj4+Pj4+IEkgYW0gc29ycnksIGhvdyB0byBtb3ZlIGl0
IGFoZWFkIG9mICooLnJvZGF0YS4qKSA/DQo+Pj4+Pj4+Pj4gSXMgYmVsb3cgY2hhbmdlIGNvcnJl
Y3Q/DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUveGVuL3hl
bi5sZHMuaCBiL3hlbi9pbmNsdWRlL3hlbi94ZW4ubGRzLmgNCj4+Pj4+Pj4+PiBpbmRleCA3OTNk
MGUxMTQ1MGMuLjM4MTc2NDIxMzVhYSAxMDA2NDQNCj4+Pj4+Pj4+PiAtLS0gYS94ZW4vaW5jbHVk
ZS94ZW4veGVuLmxkcy5oDQo+Pj4+Pj4+Pj4gKysrIGIveGVuL2luY2x1ZGUveGVuL3hlbi5sZHMu
aA0KPj4+Pj4+Pj4+IEBAIC0xODgsNyArMTg4LDcgQEANCj4+Pj4+Pj4+PiAgI2RlZmluZSBWUENJ
X0FSUkFZICAgICAgICAgICAgICAgXA0KPj4+Pj4+Pj4+ICAgICAgICAgLiA9IEFMSUdOKFBPSU5U
RVJfQUxJR04pOyBcDQo+Pj4+Pj4+Pj4gICAgICAgICBfX3N0YXJ0X3ZwY2lfYXJyYXkgPSAuOyAg
IFwNCj4+Pj4+Pj4+PiAtICAgICAgICooU09SVCguZGF0YS52cGNpLiopKSAgICAgXA0KPj4+Pj4+
Pj4+ICsgICAgICAgKigucm9kYXRhKSAgICAgICAgICAgICBcDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4g
Li4uIHRoaXMgaXNuJ3QgLSB5b3UnZCBtb3ZlIF9hbGxfIG9mIC5yb2RhdGEgaW50byBoZXJlLCB3
aGljaCBkZWZpbml0ZWx5DQo+Pj4+Pj4+PiBpc24ndCB3aGF0IHlvdSB3YW50LiBXaGF0IEkgdW5k
ZXJzdGFuZCBSb2dlciBtZWFudCB3YXMgYSAucm9kYXRhLWxpa2UNCj4+Pj4+Pj4+IHNlY3Rpb24s
IGUuZy4gLnJvZGF0YS52cGNpLiogKG11Y2ggbGlrZSBpdCB3YXMgLmRhdGEudnBjaS4qIGJlZm9y
ZSkuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEluZGVlZCwgbXkgc3VnZ2VzdGlvbiB3YXMgbWVyZWx5IHRv
IHVzZSAucm9kYXRhIGluc3RlYWQgb2YgLmRhdGEsIGFzDQo+Pj4+Pj4+IHRoYXQncyBtb3JlIGFj
Y3VyYXRlIElNTy4gIEkgdGhpbmsgaXQgc2hvdWxkIGJlICooLnJvZGF0YS52cGNpKSAoYW5kDQo+
Pj4+Pj4+IHNhbWUgc2VjdGlvbiBjaGFuZ2UgZm9yIHRoZSBfX3VzZWRfc2VjdGlvbigpIGF0dHJp
YnV0ZS4NCj4+Pj4+Pg0KPj4+Pj4+IElmIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHksIHRoZSBuZXh0
IHZlcnNpb24gd2lsbCBiZToNCj4+Pj4+Pg0KPj4+Pj4+ICsgICAgc3RhdGljIGNvbnN0IHZwY2lf
Y2FwYWJpbGl0eV90ICpjb25zdCBmaW5pdCMjX2VudHJ5ICBcDQo+Pj4+Pj4gKyAgICAgICAgX191
c2VkX3NlY3Rpb24oIi5yb2RhdGEudnBjaSIpID0gJmZpbml0IyNfdA0KPj4+Pj4+ICsNCj4+Pj4+
Pg0KPj4+Pj4+IGFuZA0KPj4+Pj4+DQo+Pj4+Pj4gICNkZWZpbmUgVlBDSV9BUlJBWSAgICAgICAg
ICAgICAgIFwNCj4+Pj4+PiAgICAgICAgIC4gPSBBTElHTihQT0lOVEVSX0FMSUdOKTsgXA0KPj4+
Pj4+ICAgICAgICAgX19zdGFydF92cGNpX2FycmF5ID0gLjsgICBcDQo+Pj4+Pj4gLSAgICAgICAq
KFNPUlQoLmRhdGEudnBjaS4qKSkgICAgIFwNCj4+Pj4+PiArICAgICAgICooLnJvZGF0YS52cGNp
KSAgICAgICAgICAgXA0KPj4+Pj4+ICAgICAgICAgX19lbmRfdnBjaV9hcnJheSA9IC47DQo+Pj4+
Pg0KPj4+Pj4gRGlkIHlvdSBhbHNvIG1vdmUgdGhlIGluc3RhbmNlcyBvZiBWUENJX0FSUkFZIGlu
IHRoZSBsaW5rZXIgc2NyaXB0cyBzbw0KPj4+Pj4gaXQncyBiZWZvcmUgdGhlIGNhdGNoLWFsbCAq
KC5yb2RhdGEuKik/DQo+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gQnV0LCB0aGF0IGVuY291bnRlcmVk
IGFuIHdhcm5pbmcgd2hlbiBjb21waWxpbmcuDQo+Pj4+Pj4gIiB7c3RhbmRhcmQgaW5wdXR9OiBB
c3NlbWJsZXIgbWVzc2FnZXM6DQo+Pj4+Pj4ge3N0YW5kYXJkIGlucHV0fToxMTYwOiBXYXJuaW5n
OiBzZXR0aW5nIGluY29ycmVjdCBzZWN0aW9uIGF0dHJpYnV0ZXMgZm9yIC5yb2RhdGEudnBjaQ0K
Pj4+Pj4+IHtzdGFuZGFyZCBpbnB1dH06IEFzc2VtYmxlciBtZXNzYWdlczoNCj4+Pj4+PiB7c3Rh
bmRhcmQgaW5wdXR9OjMwMzQ6IFdhcm5pbmc6IHNldHRpbmcgaW5jb3JyZWN0IHNlY3Rpb24gYXR0
cmlidXRlcyBmb3IgLnJvZGF0YS52cGNpDQo+Pj4+Pj4ge3N0YW5kYXJkIGlucHV0fTogQXNzZW1i
bGVyIG1lc3NhZ2VzOg0KPj4+Pj4+IHtzdGFuZGFyZCBpbnB1dH06NjY4NjogV2FybmluZzogc2V0
dGluZyBpbmNvcnJlY3Qgc2VjdGlvbiBhdHRyaWJ1dGVzIGZvciAucm9kYXRhLnZwY2kgIg0KPj4+
Pj4NCj4+Pj4+IFdoYXQgYXJlIHRoZSBhdHRyaWJ1dGVzIGZvciAucm9kYXRhLnZwY2kgaW4gdGhl
IG9iamVjdCBmaWxlcz8gIFlvdSBjYW4NCj4+Pj4+IGdldCB0aG9zZSB1c2luZyBvYmpkdW1wIG9y
IHJlYWRlbGYsIGZvciBleGFtcGxlOg0KPj4+Pj4NCj4+Pj4+ICQgb2JqZHVtcCAtaCB4ZW4vZHJp
dmVycy92cGNpL21zaS5vDQo+Pj4+PiBbLi4uXQ0KPj4+Pj4gIDE3IC5kYXRhLnZwY2kuOSAgMDAw
MDAwMDggIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwMDAwMDAwMDAwMDAgIDAwMDAwYTUwICAyKioz
DQo+Pj4+PiAgICAgICAgICAgICAgICAgICBDT05URU5UUywgQUxMT0MsIExPQUQsIFJFTE9DLCBE
QVRBDQo+Pj4+Pg0KPj4+Pj4gSXQgc2hvdWxkIGJlIFJFQURPTkxZLCBvdGhlcndpc2UgeW91IHdp
bGwgZ2V0IHRob3NlIG1lc3NhZ2VzLg0KPj4+Pj4NCj4+Pj4+PiBBbmQsIGR1cmluZyBib290aW5n
IFhlbiwgYWxsIHZhbHVlIG9mIF9fc3RhcnRfdnBjaV9hcnJheSBpcyBpbmNvcnJlY3QuDQo+Pj4+
Pj4gRG8gSSBtaXNzIGFueXRoaW5nPw0KPj4+Pj4NCj4+Pj4+IEkgdGhpbmsgdGhhdCdzIGxpa2Vs
eSBiZWNhdXNlIHlvdSBoYXZlbid0IG1vdmVkIHRoZSBpbnN0YW5jZSBvZg0KPj4+Pj4gVlBDSV9B
UlJBWSBpbiB0aGUgbGlua2VyIHNjcmlwdD8NCj4+Pj4gT2gsIHJpZ2h0LiBTb3JyeSwgSSBmb3Jn
b3QgdG8gbW92ZSBpdC4NCj4+Pj4gQWZ0ZXIgY2hhbmdpbmcgdGhpcywgaXQgd29ya3Mgbm93Lg0K
Pj4+Pg0KPj4+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3hlbi5sZHMuUyBiL3hlbi9hcmNo
L3g4Ni94ZW4ubGRzLlMNCj4+Pj4gaW5kZXggYmY5NTZiNmM1ZmMwLi5jODhmZDYyZjRmMGQgMTAw
NjQ0DQo+Pj4+IC0tLSBhL3hlbi9hcmNoL3g4Ni94ZW4ubGRzLlMNCj4+Pj4gKysrIGIveGVuL2Fy
Y2gveDg2L3hlbi5sZHMuUw0KPj4+PiBAQCAtMTM0LDYgKzEzNCw3IEBAIFNFQ1RJT05TDQo+Pj4+
ICAgICAgICAgQlVHRlJBTUVTDQo+Pj4+DQo+Pj4+ICAgICAgICAgKigucm9kYXRhKQ0KPj4+PiAr
ICAgICAgIFZQQ0lfQVJSQVkNCj4+Pj4gICAgICAgICAqKC5yb2RhdGEuKikNCj4+Pj4gICAgICAg
ICAqKC5kYXRhLnJlbC5ybykNCj4+Pj4gICAgICAgICAqKC5kYXRhLnJlbC5yby4qKQ0KPj4+PiBA
QCAtMTQ4LDcgKzE0OSw2IEBAIFNFQ1RJT05TDQo+Pj4+ICAgICAgICAgKigubm90ZS5nbnUuYnVp
bGQtaWQpDQo+Pj4+ICAgICAgICAgX19ub3RlX2dudV9idWlsZF9pZF9lbmQgPSAuOw0KPj4+PiAg
I2VuZGlmDQo+Pj4+IC0gICAgICAgVlBDSV9BUlJBWQ0KPj4+PiAgICB9IFBIRFIodGV4dCkNCj4+
Pg0KPj4+IEZXSVcsIEkgd291bGQgcHV0IGl0IGFoZWFkIG9mICooLnJvZGF0YSkuICBSZW1lbWJl
ciB0byBhbHNvIG1vZGlmeSB0aGUNCj4+PiBsaW5rZXIgc2NyaXB0IGZvciBhbGwgdGhlIG90aGVy
IGFyY2hlcywgbm90IGp1c3QgeDg2Lg0KPj4NCj4+IFdoZXRoZXIgYmVmb3JlICooLnJvZGF0YS4q
KSBvciBiZWZvcmUgKigucm9kYXRhKSwgdGhlcmUgc3RpbGwgaXMgdGhlIHdhcm5pbmcgIiBXYXJu
aW5nOiBzZXR0aW5nIGluY29ycmVjdCBzZWN0aW9uIGF0dHJpYnV0ZXMgZm9yIC5yb2RhdGEudnBj
aSAiDQo+PiBBbmQgdGhlIG9iamR1bXAgc2hvd3MgInJvZGF0YS52cGNpIiBoYXMgbm8gInJlYWRv
bmx5IiB3b3JkLg0KPiANCj4gRGlkIHlvdSBjaGVjayB3aGF0IGdjYyBlbWl0cz8gSXQgbWF5IGJl
IHJlcXVlc3RpbmcgImF3IiBpbnN0ZWFkIG9mIHRoZQ0KPiB3YW50ZWQgImEiIGluIHRoZSBzZWN0
aW9uIGF0dHJpYnV0ZXMuIFNpbmNlIHRoZXJlIGFyZSByZWxvY2F0aW9ucyBoZXJlLA0KPiAiLnJv
ZGF0YS4iIG1heSBub3QgYmUgdGhlIGNvcnJlY3QgcHJlZml4IHRvIHVzZTsgaXQgbWF5IGluc3Rl
YWQgbmVlZCB0bw0KPiBiZSAiLmRhdGEucmVsLnJvLiIuDQoNCldoYXQncyB5b3VyIG9waW5pb24g
YWJvdXQgY2hhbmdpbmcgdG8gIi5kYXRhLnJlbC5yby52cGNpIiA/DQoNCj4gDQo+IEphbg0KDQot
LSANCkJlc3QgcmVnYXJkcywNCkppcWlhbiBDaGVuLg0K


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 10:39:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 10:39:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011462.1389894 (Exim 4.92)
	(envelope-from )
	id 1uPIrJ-0007cW-Ai; Wed, 11 Jun 2025 10:39:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011462.1389894; Wed, 11 Jun 2025 10:39:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPIrJ-0007cP-7p; Wed, 11 Jun 2025 10:39:05 +0000
Received: by outflank-mailman (input) for mailman id 1011462;
 Wed, 11 Jun 2025 10:39:04 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uPIrI-0007cJ-9M
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 10:39:04 +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 4adeff2e-46b0-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 12:39:03 +0200 (CEST)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-604bff84741so12302857a12.2
 for ; Wed, 11 Jun 2025 03:39:03 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ade1dc1c87esm881733266b.107.2025.06.11.03.39.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 03:39:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4adeff2e-46b0-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749638343; x=1750243143; 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=ijH0RIOfhByEJpympgF+ymn1CM6wgXAooij3e84izYA=;
        b=ANb8c793tURNpJsztWWDCrgGFt3Dn5ITOhWEZrqGFvQ7mTsMwVEPJfU5qR6QnKha2I
         QSufANjOVBP7juoAvPh2KJu+ZcFi7hLR9QFS3CpRtU7hMU/syH6cgaHIq8w0cmSlV6gd
         uA1yrI/nZzUdh1c40R1phZV9AiuYydsK04iG/YcuJN8BGHRbG9f2o9i5c3fOh2B+QuEk
         sD/bj1GK9KNY1jF6MSm9uWDju9nAlifk7AycnG+lK/nOINzqasW3OLeEiKD4LuPzwFOV
         Cjl20S/2ZyuZuq+GC+k/Yeh1LsPCuvAIw+I9f6zvVHge3RKpnVw3FxOkm4E6bk3dDJwU
         AP4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749638343; x=1750243143;
        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=ijH0RIOfhByEJpympgF+ymn1CM6wgXAooij3e84izYA=;
        b=nkqhiIF9DoSNjtoY5RR9PKX7rJfviSkfg5efaXnNzZg50YHFJYY3Ja57YvkTn2kKrJ
         zZZNjkwd3PU0dnpUSvrpBa27mq+0F5mJzJleQQ2otyzAqFQw72GpHnKyQ8HSNS8iG6xe
         4sg47HK5h5cLn2Zr0YhpkwV47Gt4/xuZA6keF3ON2DXU5gXEuPYcGwQDhcE5Fto86ybF
         qVGpH4zwuJMVrcAycBFxtF2LPwEowTtgTGs/J/zVFEcEqpwXtPKja2rO+wmMetIxqkQn
         +2Vm8bosZqnj/HrGa0dK2Km4yMl5/hFgg/MEU+fqXOn2SNA4bg06kK2zyXKnN1ZdbS51
         2NiA==
X-Gm-Message-State: AOJu0YxL+9unIO6twRGKukqHO4vjFh568akd2iiCk7Ozqr7rVcdBiSS7
	0g1G5qB7JZapvSjv6fyvj9mh247L7XRzdOaDXv612rHiONChcw42Lge4
X-Gm-Gg: ASbGncst41Sw6M5Smlh3dghbjoLRvcSHobptASD4GWAxtLcSlNqiLPcFAmZAbSqERUe
	JcJaSQPJ6ZxuhZ0eE74g/Dwte0/oBlNDKVcSHtNqgDXA31+V7BnVWQPsK6gpQh0AwUSs1QlMgo0
	EKTnIwR3GXKvNLizNX4y8tD9LQiPPzaxoYF/xBkGtcJ2vDdm4utrMO7D385YvsI9yoCM1KEjoTh
	m54PWbxGrU/3P7fpeRC6vRmpqmXadTCcezVElaf90lqQMj/P6aneqj7vK8Hc8zf9xZoq5i7NltF
	kSe0CzOsYlCQcnqisHDPkrPfsIXk0jnhEF/DlrTVeN69MUgJ+TBoXHKNlcrPc3hXL93X+QHj8KS
	aT8xc1XoDjOn3o5/dEVvHfkdiWrUQ9kjw/zE=
X-Google-Smtp-Source: AGHT+IF03mSQmMrdyOIot75ldt0+oTBbrVCxcnprMbhTaR5lQcAqLeilUUTyUZOm4bo7QWdtZKe4LQ==
X-Received: by 2002:a17:906:c114:b0:ad4:fd7f:a4 with SMTP id a640c23a62f3a-ade8c8c2d36mr206145766b.47.1749638342388;
        Wed, 11 Jun 2025 03:39:02 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------tzJUobWi6u0Z69yXIKNM8kCo"
Message-ID: <4fb007fd-3a87-4a12-ae73-15870d7bae42@gmail.com>
Date: Wed, 11 Jun 2025 12:38:59 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Xen 4.21 Development Update [May]
To: Mykola Kvach 
Cc: xen-devel@lists.xenproject.org,
 Ayan Kumar Halder ,
 Mykyta Poturai , Juergen Gross ,
 Teddy Astie ,
 Bertrand Marquis ,
 Luca Fancellu , Jason Andryuk
 , Alejandro Vallejo ,
 Sergii Dmytruk , Penny Zheng
 ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , Roger Pau Monne ,
 Andrew Cooper , dmkhn@proton.me,
 "Daniel P. Smith" ,
 Grygorii Strashko ,
 Alejandro Vallejo ,
 "committers@xenproject.org" ,
 Community Manager 
References: <7364a71d-2604-49ca-bab7-d21544d49b10@gmail.com>
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

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

Hello Mykola,

On 6/11/25 9:03 AM, Mykola Kvach wrote:
>> === ARM ===
>>
>> * SMMU handling for PCIe Passthrough on ARM (v11)
>>     - Mykyta Poturai
>>     -
>> https://lore.kernel.org/xen-devel/cover.1741958647.git.mykyta_poturai@epam.com/
>>     -
>> https://patchew.org/Xen/cover.1748422217.git.mykyta._5Fpoturai@epam.com/
>>
>> * xen/arm: scmi: introduce SCI SCMI SMC multi-agent support
>>     - Grygorii Strashko
>>     -
>> https://lore.kernel.org/xen-devel/20250311111618.1850927-1-grygorii_strashko@epam.com/
>>
>> * Add initial Xen Suspend-to-RAM support on ARM64 (v4)
>>     - Mykola Kvach
>>     -
>> https://lore.kernel.org/xen-devel/cover.1741164138.git.xakep.amatop@gmail.com/
>>     -https://patchew.org/Xen/cover.1748848482.git.mykola._5Fkvach@epam.com/
> I'd like to propose including initial support for Suspend-to-RAM in Xen 4.21.
>
> This feature enables Xen and its guests to enter suspend state via
> PSCI SYSTEM_SUSPEND. Xen suspend is triggered from the hardware domain.
>
> Support is currently Experimental.

Thanks for your feedback!

I saw that there are two patch series connected to Suspend-to-RAM topic:
-https://lore.kernel.org/xen-devel/cover.1748337249.git.mykola_kvach@epam.com/
-https://lore.kernel.org/xen-devel/cover.1748848482.git.mykola_kvach@epam.com/

So it seems like we should follow a progress for these two patch series in parallel.
Or the difference is that one of patch series is for connect to guest and another
to hardware domains.

Am I missing something?

~ Oleksii

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



  
    
  
  
    
    Hello Mykola,

    
    
    On 6/11/25 9:03 AM, Mykola Kvach wrote:
    
    
    
    
    
      
    
        
    === ARM ===

* SMMU handling for PCIe Passthrough on ARM (v11)
   - Mykyta Poturai
   -
https://lore.kernel.org/xen-devel/cover.1741958647.git.mykyta_poturai@epam.com/
   -
https://patchew.org/Xen/cover.1748422217.git.mykyta._5Fpoturai@epam.com/

* xen/arm: scmi: introduce SCI SCMI SMC multi-agent support
   - Grygorii Strashko
   -
https://lore.kernel.org/xen-devel/20250311111618.1850927-1-grygorii_strashko@epam.com/

* Add initial Xen Suspend-to-RAM support on ARM64 (v4)
   - Mykola Kvach
   -
https://lore.kernel.org/xen-devel/cover.1741164138.git.xakep.amatop@gmail.com/
   - https://patchew.org/Xen/cover.1748848482.git.mykola._5Fkvach@epam.com/

    
      
    
      
    I'd like to propose including initial support for Suspend-to-RAM in Xen 4.21.

This feature enables Xen and its guests to enter suspend state via
PSCI SYSTEM_SUSPEND. Xen suspend is triggered from the hardware domain.

Support is currently Experimental.
    
    
    
    
    Thanks for your feedback!

I saw that there are two patch series connected to Suspend-to-RAM topic:
- https://lore.kernel.org/xen-devel/cover.1748337249.git.mykola_kvach@epam.com/
- https://lore.kernel.org/xen-devel/cover.1748848482.git.mykola_kvach@epam.com/

So it seems like we should follow a progress for these two patch series in parallel.
Or the difference is that one of patch series is for connect to guest and another
to hardware domains.

Am I missing something?

~ Oleksii

    
  


--------------tzJUobWi6u0Z69yXIKNM8kCo--


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 10:41:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 10:41:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011468.1389904 (Exim 4.92)
	(envelope-from )
	id 1uPItQ-0000up-Lq; Wed, 11 Jun 2025 10:41:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011468.1389904; Wed, 11 Jun 2025 10:41: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 1uPItQ-0000uh-JH; Wed, 11 Jun 2025 10:41:16 +0000
Received: by outflank-mailman (input) for mailman id 1011468;
 Wed, 11 Jun 2025 10:41: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 1uPItO-0000ua-VN
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 10:41:14 +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 981a8309-46b0-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 12:41:13 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a503d9ef59so5442042f8f.3
 for ; Wed, 11 Jun 2025 03:41:13 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-313b1ff0fa8sm1121075a91.8.2025.06.11.03.41.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 03:41:11 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 981a8309-46b0-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749638472; x=1750243272; 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=/Zp59246u7VED9/39h653MalXJ1qhbfd3vUTR07xLHE=;
        b=UQF32LQuzsrcQacAjb3idLwwj83rdagYHRsjs5BvmnFcBwdlrkGbMJ902hXzG9iSHf
         sWzqZKUt3wIvGbNWuqPSCMDKmQlxVBUNH9jC1T4yFI8gsooi0dg04ecmsvy/nplJDPxN
         pB4005APb7HcWMWypAiG1bKnNVb1ZVny+7wDoGUwQgEDa8kDSchy0/TUsJzjDNG7k+0w
         5zoYO34Bc3QfKlEthdBKlqh23lgtZQe9i5W3jb+9kDmLIlVzqX+Q+I4RBYyImpYCvqY3
         JLsniRpbE/iBanP46WUSR8HBz+4/jb164kbXa/fQ/1gK0RR0axFSw8oWlM7EQJFZCqLq
         ZZ7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749638472; x=1750243272;
        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=/Zp59246u7VED9/39h653MalXJ1qhbfd3vUTR07xLHE=;
        b=Er+ZdTYeFrfOPs037D7CFgu6jfQusLiMsQ1BgM8N284YTChL0O60VX+k+ZhmCCkbdw
         +i89DCeTAkYFERBJssvGoYhMx73g5BKSUmJFOsfv+nBGQKc/QPZvPUkuAoZ2n/s7bu9e
         AENojHoYskfBEG2Hyk2Myb9T6xScsXd2s6HNs6bNeIpKJkVal4UjV45ramgtNE6ZMM8u
         qtVBk9BDngWQh32fdsCfFg3XriBQkrWVMf4j7EBFXt7kSloxRzd6uf9wemQy/GwnTmhJ
         ufQQ6GzuKkHM/i2UepoERqdetR0JNWkykiZwMvg/Gf5Zkh8cfj7TPylnBVKZCbHUkf7L
         Kqyg==
X-Gm-Message-State: AOJu0Ywknu0eyaDC4+RjAhgnir/cLnbplcGfVlQQ5xifbVu9E78tZTx3
	b7GHl79rw7nNlqz3ab6/aA/ko5g9MZg62Qx5tqbGMv72ITCc5V24tsH9jxUJ0U9rV1zqHKnFlgF
	sFvo=
X-Gm-Gg: ASbGnct0P9lg6egu8e4XG/V38dCxKUakvwmOBbd9Edt5iY/91huEYCWhtCZbrxPePCw
	owW6XW22z1YYT9GfGeZNvwGMqaxoKukJJdQZLaIBsW50yWGc2deJthtWQEiYzgrk6DV+C4/AGvA
	QoCxtEMujdl/EFMBXz3HwE6dJ4sWceDKuafVUVmgqEqJCCW2TNYQ612gmKVqOYO5+Eg9qqjkGuI
	u3Zm8LTkgNejneIYEO2qnLARIgPJKi+7OvNGbC+bZsz+T58gvskrAzBT1D0gKC5MZKpTMI6/VUp
	tVlAsQg57ZH8zeTXPrUKVH8CYOimcqlu6OkBSXyOvsTeJ2T2p5MkgC7p5q3XXnZ68bOHolufbCr
	tsBgDdivt5RGQxS2mte8Q2zETl95DwqX2+xJ5Z8vFbw16TD8=
X-Google-Smtp-Source: AGHT+IGp7woQ7a0DCmWxDOq4u2nr1j0qjfQqXzpExG9MovyDJhi5ynenoiywyOxkyr1976HYXsN8+A==
X-Received: by 2002:a05:6000:288b:b0:3a5:2fb2:35ac with SMTP id ffacd0b85a97d-3a5586dbb1amr2137946f8f.24.1749638472453;
        Wed, 11 Jun 2025 03:41:12 -0700 (PDT)
Message-ID: <44d67587-415e-4ec1-a433-64a12aea80d7@suse.com>
Date: Wed, 11 Jun 2025 12:41:09 +0200
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?= 
From: Jan Beulich 
Subject: [PATCH 0/6] vVMX: VMX insn handling
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Originally, while dealing with some other patch, I merely noticed the
issue addressed by patch 2. That quickly grew then, though.

1: use reg_read()
2: adjust reg_read() for 32-bit guests
3: adjust reg_write() for 32-bit guests
4: prefer hvm_long_mode_active() in decode_vmx_inst()
5: operand size in decode_vmx_inst()
6: address size in decode_vmx_inst()

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 10:42:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 10:42:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011476.1389914 (Exim 4.92)
	(envelope-from )
	id 1uPIuU-0001U2-3G; Wed, 11 Jun 2025 10:42:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011476.1389914; Wed, 11 Jun 2025 10:42:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPIuT-0001Tv-W5; Wed, 11 Jun 2025 10:42:21 +0000
Received: by outflank-mailman (input) for mailman id 1011476;
 Wed, 11 Jun 2025 10:42: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 1uPIuS-0001Tn-Vm
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 10:42:20 +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 bf62e7e5-46b0-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 12:42:18 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3a536ecbf6fso2948639f8f.2
 for ; Wed, 11 Jun 2025 03:42:18 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-7482af7af0csm9171292b3a.62.2025.06.11.03.42.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 03:42:17 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bf62e7e5-46b0-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749638538; x=1750243338; 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=LBRwkWwv0jbgKkcFjXltShuEDP54+5oP6Jd8d3RK15c=;
        b=MsbeRdPILcWZLaWX6caAuStGcEGy526OKGfNrLIiU6sHxsyXX/aVAb8HnM6PjZ/hOJ
         LkfWdZ7b9SoGx4awP72OXV/IKfgl4XvT2XfsQvojlJhJjHHfcNdo06LHmiEk3Yy+LGig
         9BVL88rm9bdRXB1Dnb6a1+bRR/VCX+urStn9nkEAOBs4DdH6Arpj0QUKq1NgPbi/0S88
         6eVozVYK0KgajyzkmqGNTzh9ECY7A1WqcCLkafVsmVPPLvMnxWwTMNtOcjT2VeJbMEHO
         AztVyF1VR7OS1RkzPbhaASHuj84BzUnsbyx6m/3sssiLOxr/Yl6YuJPGsVDES5Dba2bt
         xB9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749638538; x=1750243338;
        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=LBRwkWwv0jbgKkcFjXltShuEDP54+5oP6Jd8d3RK15c=;
        b=JQZYiZR/kdj1qg5UeHdmrH1wjcV4UFykB+7hQbVR+ViPfPQFSs0KqNkbxR6hve1Vq9
         64Z4C0mFQDY7+gxx4kkurmjLvUXj5+LbVU9CUbGgu+q84Lr7yLqbIMKoWQFbM93IF0Yz
         /a0KPXWbZ6b2qW0+aCZZR+Gerxeqtaa1H+BMyE5gXqvWJydvfleuRZCOupbVFWnodh8t
         4wFGsoLkFflDBHWVKELyRm5uSfJvTmZZCMleVB83GmwCZS5dPBrZ2RRCqajwuMjUaU+e
         ItNP+f91zypnnZay8poqAk5N30dkYtYlMeWCeJoGNKj0uIx0sUl4NAundFQ1E/We8qiA
         fzqQ==
X-Gm-Message-State: AOJu0Yzo1dPnRDv1l/tPQfFntG+fVqwul2zp8khrrcji2Eiz2EpKQCXD
	cp5btbrhirHlC3G793/KQCvUb2+8MTjyiCTzJJVEG7ezdPp8mwz3fnZ4pqSTX8h4nKwtMfFO3bY
	kRr8=
X-Gm-Gg: ASbGnctKH9BQAWmn/ho2Dnt0iQkUqnoNCwGMlFzkkI31NDynObJC6xddM2aV7GJdxG5
	979KDyeEqobxDyoEOhpuMO24QZ/LN/rP6aMSE6hAuhJkozqjQlB3wRpSu1h5LcIkcdpIoqqMtrz
	ujNMzI8pSgYmbU7W7/DgB04yPab3pl+uvVtZK9CDNByZTWvrQyr0+rxF8zRzxSKrG+3fIT7Lusa
	xjJgkqhSao1oFCoB4nPBlaW1e1yfQ57gn1uQj5TS2jh/vE60wZlmc7JtmPRB16TWe+UuBud2RAQ
	1qHVR3MJQrmCaS04EGr350GZeCM6pLCmKFWhpqLZAIyc0LuqY6vHZ09c7PRwnyEsB7IbT2XrKv8
	YPnNV5IWH3+FT4VGNGKFa5+cYd4tRw4GPtrs/C5FnuDy6cCM+MHt8TJXBtA==
X-Google-Smtp-Source: AGHT+IEsPGL3kWyZ20U0qudndcxOao26zAFUaeZAsz6mZnG3MsxSrDYLB5j9M4PNPkIBxAutomGKhw==
X-Received: by 2002:a05:6000:18a7:b0:3a4:f7e7:416b with SMTP id ffacd0b85a97d-3a558695570mr2021614f8f.16.1749638538373;
        Wed, 11 Jun 2025 03:42:18 -0700 (PDT)
Message-ID: <5f72b1c7-968f-49c6-831b-cfc4678b5923@suse.com>
Date: Wed, 11 Jun 2025 12:42:15 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH 1/6] vVMX: use reg_read()
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <44d67587-415e-4ec1-a433-64a12aea80d7@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: <44d67587-415e-4ec1-a433-64a12aea80d7@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Let's avoid such open-coding. There's also no need to use
guest_cpu_user_regs(), when the function has a suitable parameter.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -2675,7 +2675,7 @@ int nvmx_n2_vmexit_handler(struct cpu_us
             {
             case VMX_CR_ACCESS_TYPE_MOV_TO_CR:
             {
-                val = *decode_gpr(guest_cpu_user_regs(), qual.gpr);
+                val = reg_read(regs, qual.gpr);
 
                 if ( qual.cr == 0 )
                 {



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 10:42:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 10:42:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011479.1389924 (Exim 4.92)
	(envelope-from )
	id 1uPIur-0001sm-BU; Wed, 11 Jun 2025 10:42:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011479.1389924; Wed, 11 Jun 2025 10:42:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPIur-0001sf-7a; Wed, 11 Jun 2025 10:42:45 +0000
Received: by outflank-mailman (input) for mailman id 1011479;
 Wed, 11 Jun 2025 10:42: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 1uPIuq-0001Tn-1B
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 10:42:44 +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 cd6eeef8-46b0-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 12:42:42 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3a4e742dc97so527423f8f.0
 for ; Wed, 11 Jun 2025 03:42:42 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-313b210f636sm1010151a91.31.2025.06.11.03.42.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 03:42:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cd6eeef8-46b0-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749638562; x=1750243362; 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=8h5N+uMQNA34CSUfT3J3XGOdG1Xu2E+WLId5R3xUSrE=;
        b=SAt8/9T7WpM6b8t730icL5ARxyEEZGKmNBdS950oBdCehr//qofBwXgQWf7lSBuvUg
         8UbiVUFvjZbMoH7sMnB8CswXqJCtIgpUpZ0roEaBaGUmt+ss5+dzCJ0wJmzRqaUdpoZs
         Bd6NIoOa7UfOBpixvesDDaxOpPNbTVFdLQXc/sohyLnAPx8Zd2/eP6Gt294P6tiFxw4e
         /trrXxOgpRXHC7ByBQ6I/37SIyEUrothXqcyvFOCMGsEyV/EdjELXgnY7cFzr0BmF836
         3clhuXcrq/08dR+VfxKksBBvD6OclufjBrJ2qLaD5pvlLEA5ZXr1i+lfueKEvL+p8doc
         V5jA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749638562; x=1750243362;
        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=8h5N+uMQNA34CSUfT3J3XGOdG1Xu2E+WLId5R3xUSrE=;
        b=ubWI9jTd9y2QQxeO181CFNIiHcLNJkVYR8bt5E2KlWS/TPd5ms7tvgK6U9SmDmcpFH
         0AP8M/GG+uk9IMQeY3WT57AaUBhCnH2uucUUhOKATtn6eVDONWWcsN6UD1cpyVlogaDq
         Sf39Jbvw2oIhdVb7E4+psJ9uu1wegyWGPjNm4XsENBIClAv6K9kkLyU1FqwdBA6xBAjG
         CZ8Yj6AGDTHXcKrqwyDIbbBtVs6C9t7Qi9PogBRpl0W0580XWmJK2pjqb1huJy6TARsZ
         Sjy8Hbjpg6UlhTo2pKFuaviYmCWU6mlj7lr4NTJHGRdIB7LLjY8HU2R/smclPBYTvRW0
         pbZQ==
X-Gm-Message-State: AOJu0YyxDOOdsIM8Kw/+Y/yrtos8l3SlyYhGUwxFerzyd3b8cGc+fM35
	7dRHy+tlBBnTNg8XOm5ziQgPZEFJ7IIGT4KfY632CwG4WLh1Zfrxz61dchDy1k0XEOfT604Vkei
	wA28=
X-Gm-Gg: ASbGncuRuLYkReelsqLZ7kgaHbF/S++ne3nG7KzIQMWDyjPoR4b+55BjSlYgBa6gR2k
	1omeP0WCoe7CL6SLChvS53CKOfvi4gWH9qxk0QDF0G/pCX3kGZhMtF+guNzULPbkpxj2jm+ww7m
	sORC0lBehd5ZQ5nM+jjHMwrdSj3hLz1G/f9nKamoPdFZ8/iGmMuf8gmdU9GHW8fIEQvh/64sD5A
	dyIRZ0uM/oMD6Mrp5+YeNydJEhItB9fBwPIynxQFYjgi5pfuG/S/I6DY9zRFAwQ+M4rXe6uvDvO
	OcrET+SPXjb1z7fBzQhT/8DN7DBG8QaDknGAKfrdaO3VhKI1R7AVcJGly2dmZTmDCh4IiaKTY7T
	9w/myqwy/7ldzlot9mHPK1thL5QkWRuO1K0MkIOn/yt5ANzI=
X-Google-Smtp-Source: AGHT+IFNJUhQrOhtP8Em2EWVzkl6m4xvFXh4hl334eIuUaUPpf5BVg+fXZQXRLlf1FF1tmx79sf+HA==
X-Received: by 2002:a05:6000:1acc:b0:3a3:70ab:b274 with SMTP id ffacd0b85a97d-3a5581e1bddmr2370178f8f.12.1749638561833;
        Wed, 11 Jun 2025 03:42:41 -0700 (PDT)
Message-ID: <9384234e-3a07-4ae1-b632-fe007beb4c4f@suse.com>
Date: Wed, 11 Jun 2025 12:42:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH 2/6] vVMX: adjust reg_read() for 32-bit guests
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <44d67587-415e-4ec1-a433-64a12aea80d7@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: <44d67587-415e-4ec1-a433-64a12aea80d7@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Using the full 64-bit register values is wrong in this case; especially
soon after a mode switch from long mode to 32-bit one upper halves of
registers may continue to be non-zero.

Fixes: 09fce8016596 ("Nested VMX: Emulation of guest VMXON/OFF instruction")
Signed-off-by: Jan Beulich 
---
Note that the affected VMX insns are invalid to use from compatibility
mode, and hence the more expensive vmx_guest_x86_mode() doesn't need
using here. (VMCALL and VMFUNC, which are permitted in compatibility
mode, aren't taking this path. In fact both aren't dealt with at all
[explicitly] in vvmx.c.)

--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -360,7 +360,12 @@ enum vmx_insn_errno set_vvmcs_real_safe(
 static unsigned long reg_read(struct cpu_user_regs *regs,
                               unsigned int index)
 {
-    return *decode_gpr(regs, index);
+    unsigned long val = *decode_gpr(regs, index);
+
+    if ( !hvm_long_mode_active(current) )
+        val = (uint32_t)val;
+
+    return val;
 }
 
 static void reg_write(struct cpu_user_regs *regs,



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 10:43:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 10:43:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011486.1389934 (Exim 4.92)
	(envelope-from )
	id 1uPIvN-0002SE-I2; Wed, 11 Jun 2025 10:43:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011486.1389934; Wed, 11 Jun 2025 10: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 1uPIvN-0002S7-FE; Wed, 11 Jun 2025 10:43:17 +0000
Received: by outflank-mailman (input) for mailman id 1011486;
 Wed, 11 Jun 2025 10:43: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 1uPIvM-0002CX-6U
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 10:43:16 +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 e124c395-46b0-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 12:43:15 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3a50fc819f2so5293132f8f.2
 for ; Wed, 11 Jun 2025 03:43:15 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-7482af3835fsm8907951b3a.27.2025.06.11.03.43.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 03:43:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e124c395-46b0-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749638595; x=1750243395; 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=CwZ9JikHD/wnh4WhC0HUOzLh2w/84RfcO+smo2vM6EY=;
        b=ZMG3XHADwY2O76FGNFVJMp69YpxMa6zfF31ugwRdRB0m48OfZfP2PkDTY7B5TxlpA0
         Zp+n3fRDvC8LZzpivPib0gOOwnKAl3aE68m147nJCO/VIlptSaA2u3w1HnU3RDwYa2lV
         89vFT2nT5gkzmZucfoprxBd9W+Uts8ErNQ9zgb9rSRxXOodjCuUjhXc5lAO/Mwhtq7a8
         KFjC/JejMkkt0Ax/EIeaB2aCwsEdpBKNpZYlEHwenQWnQRCOIMU9XP2JAqDVYZCw2UOA
         4Z8GhVnefE6ptn24qY1AX949FMhBkoGHHpI939V6KnOTasQK05VHkWz6E8uroAThvZHc
         8Ssw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749638595; x=1750243395;
        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=CwZ9JikHD/wnh4WhC0HUOzLh2w/84RfcO+smo2vM6EY=;
        b=OrM7TwFv5kjszZ/u0X5v0e1J4b2xIabYI0XwEfZLnwBOR8i9RSkPxMsgMDu6ETpWY2
         0CGxmQv9In5RhlaQfkDdxvHthbIGih58NhCrqjdl4tu0sg1EKXpvaduJrSciGuCz8vB9
         iZsAf+NoZgRLLnmmtMNfunP6KKzLNoA8b2Luzk6TveMAiaVkZNcllotFZcu18k7wsHDp
         aPh+iM8VA48uwMWWSEJGgTCWjAWoJX9D8tFmK1WgNA+t+TUOXNU0AFQC460M9MGtjoYe
         D3Bmiq+DmEMDEo4ot9l6ieBHUxf0nnuD6IykFD2DoB7UzP9eGxP9aMSNGUkMYbdq3x6N
         TSzw==
X-Gm-Message-State: AOJu0Yy6iYgxFWJ0oCln1VVbpui2oRo6igxT9eLSNFDDd4IAWdPl8bGr
	ynxhVamf2dehkfsYO1nFHqQpVBOIym7laL1fMxDMgzU90nde9kxzTOq7Ux0FEQKgW253BhGGQYJ
	gsBU=
X-Gm-Gg: ASbGncvxlVyqEsK6wD33fRHW6YKv+9nuwI2F0ccKXBBSMq3/kq7L0XQN50IEj8kwm+X
	M9X3/J8dBBZQXHabBk2USPW4OjQ0YCO9JpWCmwZtuJ7AaLib1Tz65h/5vZ7rf/yUK8Ule/Fh7Z3
	Ep9McYlqXxiaKRNJLAfhDUf9pNDBAP9Cey3qb/bA1FbudIZGvLQ0x3yoP3MPLIfpZK+ajwUzEpI
	Tl/Xumzf2WV0X8cxp3B3kKMps/FWm69WMvzShCxGk4aInvNMoFxEzUTlCQySxo3QVu/qCDOzdbl
	XTETXsCPKsY+9C3eJdd/pIW5JWgBEwzDDR11c5UepVs5UzZy/1zXbC1skQLcH04dbPMLrp18X5I
	2AB+SJdgabkkOluOrQ0UCrqvnANaYDmHV2tCYUb1Q0B9O9fs=
X-Google-Smtp-Source: AGHT+IEwr4ftsGO5IGXJKnsdPpYNHTLOF4rJQtTbdv1YuuTmp0MoL5SqHcMsQJ82o2O9eBoSMSwSUw==
X-Received: by 2002:adf:9d84:0:b0:3a5:300d:5e17 with SMTP id ffacd0b85a97d-3a558a276f3mr1578553f8f.29.1749638594978;
        Wed, 11 Jun 2025 03:43:14 -0700 (PDT)
Message-ID: <76166ff6-3409-4279-89fa-7ca188b8748a@suse.com>
Date: Wed, 11 Jun 2025 12:43:12 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH 3/6] vVMX: adjust reg_write() for 32-bit guests
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <44d67587-415e-4ec1-a433-64a12aea80d7@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: <44d67587-415e-4ec1-a433-64a12aea80d7@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Using the full 64-bit register values is slightly wrong in this case;
32-bit writes of registers would normally zero-extend the value to 64
bits. The difference may be observable after switching (back) to 64-bit
mode (even if as per the spec upper halves of registers are undefined
after a mode switch, in reality they retain their values).

Fixes: 33a7028fec44 ("Nexted VMX: Emulation of guest VMREAD")
Signed-off-by: Jan Beulich 
---
Note that the sole affected VMX insn (VMREAD) is invalid to use from
compatibility mode, and hence the more expensive vmx_guest_x86_mode()
doesn't need using here.

--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -372,6 +372,8 @@ static void reg_write(struct cpu_user_re
                       unsigned int index,
                       unsigned long value)
 {
+    if ( !hvm_long_mode_active(current) )
+        value = (uint32_t)value;
     *decode_gpr(regs, index) = value;
 }
 



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 10:43:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 10:43:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011492.1389944 (Exim 4.92)
	(envelope-from )
	id 1uPIvn-0002uj-R4; Wed, 11 Jun 2025 10:43:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011492.1389944; Wed, 11 Jun 2025 10:43:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPIvn-0002uc-N6; Wed, 11 Jun 2025 10:43:43 +0000
Received: by outflank-mailman (input) for mailman id 1011492;
 Wed, 11 Jun 2025 10: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 1uPIvm-0001Tn-5i
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 10:43:42 +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 f01e71ad-46b0-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 12:43:40 +0200 (CEST)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-453066fad06so28232555e9.2
 for ; Wed, 11 Jun 2025 03:43:40 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-313b200a0a7sm1123936a91.17.2025.06.11.03.43.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 03:43:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f01e71ad-46b0-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749638620; x=1750243420; 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=dP6hDUe7AN9OWz/Q1nOrRU/+ZWv62kuqoQ0JD4El1IA=;
        b=aGuiUjV3G2skVdBIgCp0v5B0OB5jA2AsbJ3uBZLO8n7ulYVxh0khjzJYHB4Q9/jmb7
         8QW1TLpAps/sH1IOtmY626cHZSW2Wd/G5HLatJmdzi4uCUVyVI2gP2Gb8T2eUK1E0xS+
         u0Bn5rft03bJ+iPOGS5CkVf/t0JeeOdCFvftjnwHdHL4LEZnLFDKt5XwGigxG2bRyYN6
         BSKBQkUCEnv0Rw3L1VmKSvqR4u+h7JeH/LUPsBORENZyhsrtHls7WcUihJ2XT5JzVIW/
         0V90qHu5NrjILvTixn6PitQ7/dv5j9gbfRMKjZt9tNQT3R1cKPWppbFTEhssoIcC5qJu
         pBQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749638620; x=1750243420;
        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=dP6hDUe7AN9OWz/Q1nOrRU/+ZWv62kuqoQ0JD4El1IA=;
        b=tY7lF0IL32k8B7q0hg4kbDVmv2Duf808SVP7NVBXR43G0dLSf68VW64adUoKVcpZJp
         fVQMfNMMnaiN5dv6b9mM2oWgvSNi8YHt6WDeiTr6f185juzF/FrEwcZpR6fGv07D2EY8
         2bFy6fH9VYDfSuPFXjXJWM/c5bA1dPPnG5c2nS48jC01fas52ARUbitIIuPrQkKQWipr
         G18XRyZuXxM32fNvJPSjBdBzJe/mAQEqurAXUBiX66BFB4v5Lgi+HtWPRLkb3K73fvji
         6piylNXV5pqb73V3usoyoaqiMuc+HctOLWCI+y3B06lUhwUqPHJVKBOa7mVDbyATWDEY
         LJFA==
X-Gm-Message-State: AOJu0YwxvzIaQqTZzIbNcSJYfVGyXDemAoah0oHzzXdcmExhn/An39q4
	En3yZ79ONCRrVNHrSaZL4lwk6kh7C7I8vh4peEeq9nmEaeKhDa/Ke+lJe+R48qZBlDgLFtdNygm
	6HHk=
X-Gm-Gg: ASbGnctPQkM5v2EPF0DrM90m8uSGrbVOqfa201AK88vCgbOiqQnWL7LpfrJXaTAyfur
	ssxaO0UVJ8kqD6u+gtg+bRXFq+zdONBP872IlUqxZ1ve0P1AKOBmg4t29gFmopUuUBJal1SkGyt
	Ve8js1uqbaL0+mxh714DepAO7QRPHC1AsR0cPqBA5D8aPpxd/otnO7HGMgeeRqNDjSO4L8vFqIM
	BkXaHFKNTAmOPOlaQmxPL7YMPM4dPxsnW5Miq1SFWLulZhGrrkOw6f+uBvR/LzEDXjcSrwP0/vR
	SBSfGJtZP1IDqa3IPkOP/mjIyGDIrNOKUW2TImGbojZA/F0pKHt3J101NdynkCISTlCSOHKZDXW
	yfRV9HetEK6Zql183HbDIDG4CL74abeasHdG30D7jloOKN+Y=
X-Google-Smtp-Source: AGHT+IG22dD+FwAQwsHyCTwvPjP2pIoGvT0MDRP5r6xUVh7vRiys77Xs/z+s3UuvhnBlKVzRu0peMg==
X-Received: by 2002:a05:6000:2c0f:b0:3a4:e6c6:b8b1 with SMTP id ffacd0b85a97d-3a55869b890mr1864074f8f.17.1749638620086;
        Wed, 11 Jun 2025 03:43:40 -0700 (PDT)
Message-ID: <7676b1fe-9881-4b4f-a7ad-fe811c4449aa@suse.com>
Date: Wed, 11 Jun 2025 12:43:37 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH 4/6] vVMX: prefer hvm_long_mode_active() in decode_vmx_inst()
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <44d67587-415e-4ec1-a433-64a12aea80d7@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: <44d67587-415e-4ec1-a433-64a12aea80d7@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

All affected VMX insns are invalid to use from compatibility mode,
and hence the more expensive vmx_guest_x86_mode() doesn't need
using here.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -418,7 +418,7 @@ static int decode_vmx_inst(struct cpu_us
     }
     else
     {
-        bool mode_64bit = vmx_guest_x86_mode(v) == X86_MODE_64BIT;
+        bool mode_64bit = hvm_long_mode_active(v);
 
         decode->type = VMX_INST_MEMREG_TYPE_MEMORY;
 



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 10:44:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 10:44:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011496.1389954 (Exim 4.92)
	(envelope-from )
	id 1uPIwA-0003N0-2F; Wed, 11 Jun 2025 10:44:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011496.1389954; Wed, 11 Jun 2025 10:44: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 1uPIw9-0003Mt-Uy; Wed, 11 Jun 2025 10:44:05 +0000
Received: by outflank-mailman (input) for mailman id 1011496;
 Wed, 11 Jun 2025 10:44: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 1uPIw8-0002CX-KM
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 10:44:04 +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 fdf916c7-46b0-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 12:44:03 +0200 (CEST)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3a52874d593so6220707f8f.0
 for ; Wed, 11 Jun 2025 03:44:03 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23603b6a5aasm84831165ad.112.2025.06.11.03.44.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 03:44:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fdf916c7-46b0-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749638643; x=1750243443; 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=78s+oTdG4m8V+BkuHjMC+SQ/rabCHl4SaflHSRJvwWk=;
        b=Ihp5lGw0xguKeUn1ASg8awTshC94Ybir7DI4qwPEUIhhzqc1Du/07tDaRdawu87JvF
         WXw0vtUqQAh4AMLHJgv+Zm+NKYjpO1WPxayNsrjboGyX7+/Im99YM9zzF6yrRRnORxVN
         D6mdkpP26e0rcqTle4DB9pMAQMf8MLWfOpoxHZRfU0rEw4EuBqyxK+SBiXCt4atoVMD6
         D2Klx5ckQIZsRVZU0Jka4VwyxclarRWm8oiBtv92y5+ih+ogKSIRWqPFTK1qAljtuXq7
         n1lmEvdBPc749/avGya04iu9z/J6BLGF4Gq+N1xEng1zS/+jZbljkQmTTMi/L1xJ2JVH
         XX6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749638643; x=1750243443;
        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=78s+oTdG4m8V+BkuHjMC+SQ/rabCHl4SaflHSRJvwWk=;
        b=l/jieDi/tt6Tkp0ccMUL4OBaAn7CGjDLMThWVloSjlh7Lqj8RAvpE45Cl/9tGr/Rex
         3bsbd2ZJ0CgfJtb7UmD3/UWLMwNRd0Tq869S+XZb/+tVSJsO1Q4TRKAZDCEOOO7kbb+q
         gM+hH1KAdQSzIuWgoi9EYcsBh7UuMGgujaTgtdXohBDTfqhCN/UvSRSG1oGlv5p3m0LA
         YdqOX6kO5rSiFc30oNkqRahQf3gLsog5A0bmk2klC7iQGiyyxzNjn+oGdMyyk3crnIv7
         m8OlOOpT1biF+yP3aG1QSxplqZ1DsGuFBPxqDpu9u4DoHIiCLNvl3GwclG/xVX/pFdo8
         7PBg==
X-Gm-Message-State: AOJu0Yx6/aQBjDwTwej/Pokb9Qk9JKP3AWDVz2SrwMssQ09yisVusWPp
	A0tNyplx4Bw876zykqv2pGWbw6z4C6eZ/Z23e7fEIU56mZasMyzeOOw/UjARHXPyAHGsQ9lqf0o
	xBl0=
X-Gm-Gg: ASbGncvKZ0ixxSZmcyVQWXhQGvrIX/Julz8b5GuUtuMLxQPnwkU1EhRF3lQ8jR+kTEs
	zVngvye6fV8we0Ho2JtmEopECBNAYfiiUZZnk2fDnR1yEJu8aPYUD3RbxeF99eD2MnJPGGdYNMA
	o80xrOa5k1Meuh8IpP3p6fWRV1YQ9MbMDpmMr7KRKNhcyJKHKJbwsvrp4gM/De9Vwt0Nfr/xF9r
	W95FJ30UigHVwgS8unnsHl9yX62EEpBxQYxF6Ux4CPav4h29FUIrWW/Xh/6wJK8EU0E4AVLmbFD
	C486A/j/DOZjUdWkY7Xb8Mey0T6TkpDhWGgn3cNZplxcCk1uM3bR7QlBNj0Wnfdg7eSfG0msyjQ
	iFW6xsgGMOTFTK/4nedLqjtAwiA8mTwEHPpqhqJgHCKEwjF8=
X-Google-Smtp-Source: AGHT+IFACdp4m3LDG1YkFCFK1VppSwoqF/paJctwk6K1X+i8fFNYhou+1x10i8tCcMGEobd95MqfYA==
X-Received: by 2002:a05:6000:2888:b0:3a4:d8f8:fba7 with SMTP id ffacd0b85a97d-3a558a9a0c7mr1954562f8f.2.1749638643304;
        Wed, 11 Jun 2025 03:44:03 -0700 (PDT)
Message-ID: <14bb65f3-5b6e-4b12-8914-25528efee557@suse.com>
Date: Wed, 11 Jun 2025 12:44:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH 5/6] vVMX: operand size in decode_vmx_inst()
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <44d67587-415e-4ec1-a433-64a12aea80d7@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: <44d67587-415e-4ec1-a433-64a12aea80d7@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Address size is entirely irrelevant to operand size determination; For
VMREAD and VMWRITE outside of 64-bit mode operand size is 32 bits, while
in 64-bit mode it's (naturally) 64 bits. For all other insns it's 64
bits (a physical address) or 128 bits (INVEPT, INVVPID). To limit the
amount of change here, keep the latter at reading only 64 bits from
guest space.

Fixes: 09fce8016596 ("Nested VMX: Emulation of guest VMXON/OFF instruction")
Signed-off-by: Jan Beulich 
---
Beyond the wrong operand handling for INVEPT and INVVPID, the latter
also doesn't even have the part read checked to have bits 16 and above
all clear.

--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -399,13 +399,13 @@ static inline u32 __n2_secondary_exec_co
 
 static int decode_vmx_inst(struct cpu_user_regs *regs,
                            struct vmx_inst_decoded *decode,
-                           unsigned long *poperandS)
+                           unsigned long *poperandS, unsigned int size)
 {
     struct vcpu *v = current;
     union vmx_inst_info info;
     struct segment_register seg;
     unsigned long base, index, seg_base, disp, offset;
-    int scale, size;
+    unsigned int scale;
 
     __vmread(VMX_INSTRUCTION_INFO, &offset);
     info.word = offset;
@@ -437,7 +437,8 @@ static int decode_vmx_inst(struct cpu_us
 
         __vmread(EXIT_QUALIFICATION, &disp);
 
-        size = 1 << (info.fields.addr_size + 1);
+        if ( !size )
+            size = 4 << mode_64bit;
 
         offset = base + index * scale + disp;
         base = !mode_64bit || info.fields.segment >= x86_seg_fs ?
@@ -452,7 +453,9 @@ static int decode_vmx_inst(struct cpu_us
         if ( poperandS != NULL )
         {
             pagefault_info_t pfinfo;
-            int rc = hvm_copy_from_guest_linear(poperandS, base, size,
+            int rc = hvm_copy_from_guest_linear(poperandS, base,
+                                                min_t(unsigned int, size,
+                                                      sizeof(*poperandS)),
                                                 0, &pfinfo);
 
             if ( rc == HVMTRANS_bad_linear_to_gfn )
@@ -1549,7 +1552,7 @@ static int nvmx_handle_vmxon(struct cpu_
     uint32_t nvmcs_revid;
     int rc;
 
-    rc = decode_vmx_inst(regs, &decode, &gpa);
+    rc = decode_vmx_inst(regs, &decode, &gpa, sizeof(gpa));
     if ( rc != X86EMUL_OKAY )
         return rc;
 
@@ -1776,7 +1779,7 @@ static int nvmx_handle_vmptrld(struct cp
     unsigned long gpa = 0;
     int rc;
 
-    rc = decode_vmx_inst(regs, &decode, &gpa);
+    rc = decode_vmx_inst(regs, &decode, &gpa, sizeof(gpa));
     if ( rc != X86EMUL_OKAY )
         return rc;
 
@@ -1853,7 +1856,7 @@ static int nvmx_handle_vmptrst(struct cp
     unsigned long gpa = 0;
     int rc;
 
-    rc = decode_vmx_inst(regs, &decode, &gpa);
+    rc = decode_vmx_inst(regs, &decode, &gpa, sizeof(gpa));
     if ( rc != X86EMUL_OKAY )
         return rc;
 
@@ -1879,7 +1882,7 @@ static int nvmx_handle_vmclear(struct cp
     void *vvmcs;
     int rc;
 
-    rc = decode_vmx_inst(regs, &decode, &gpa);
+    rc = decode_vmx_inst(regs, &decode, &gpa, sizeof(gpa));
     if ( rc != X86EMUL_OKAY )
         return rc;
 
@@ -1941,7 +1944,7 @@ static int nvmx_handle_vmread(struct cpu
     u64 value = 0;
     int rc;
 
-    rc = decode_vmx_inst(regs, &decode, NULL);
+    rc = decode_vmx_inst(regs, &decode, NULL, 0);
     if ( rc != X86EMUL_OKAY )
         return rc;
 
@@ -1984,7 +1987,7 @@ static int nvmx_handle_vmwrite(struct cp
     enum vmx_insn_errno err;
     int rc;
 
-    rc = decode_vmx_inst(regs, &decode, &operand);
+    rc = decode_vmx_inst(regs, &decode, &operand, 0);
     if ( rc != X86EMUL_OKAY )
         return rc;
 
@@ -2026,7 +2029,7 @@ static int nvmx_handle_invept(struct cpu
     unsigned long eptp;
     int ret;
 
-    if ( (ret = decode_vmx_inst(regs, &decode, &eptp)) != X86EMUL_OKAY )
+    if ( (ret = decode_vmx_inst(regs, &decode, &eptp, 16)) != X86EMUL_OKAY )
         return ret;
 
     switch ( reg_read(regs, decode.reg2) )
@@ -2054,7 +2057,7 @@ static int nvmx_handle_invvpid(struct cp
     unsigned long vpid;
     int ret;
 
-    if ( (ret = decode_vmx_inst(regs, &decode, &vpid)) != X86EMUL_OKAY )
+    if ( (ret = decode_vmx_inst(regs, &decode, &vpid, 16)) != X86EMUL_OKAY )
         return ret;
 
     switch ( reg_read(regs, decode.reg2) )



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 10:50:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 10:50:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011516.1389968 (Exim 4.92)
	(envelope-from )
	id 1uPJ1v-0004dW-Oz; Wed, 11 Jun 2025 10:50:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011516.1389968; Wed, 11 Jun 2025 10:50:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPJ1v-0004d0-Ln; Wed, 11 Jun 2025 10:50:03 +0000
Received: by outflank-mailman (input) for mailman id 1011516;
 Wed, 11 Jun 2025 10:50: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 1uPJ1t-0004Fr-Vt
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 10:50:02 +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 d282d6ef-46b1-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 12:50:01 +0200 (CEST)
Received: by mail-ot1-x32c.google.com with SMTP id
 46e09a7af769-72c47631b4cso4355974a34.1
 for ; Wed, 11 Jun 2025 03:50:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d282d6ef-46b1-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1749639000; x=1750243800; 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=GG6aW3XDuEMUCKryLo/fh3k2eKKUNrqXRIEfIyGJ6II=;
        b=gDn0GzJW7NoRLOpep9bGyNV4SXRHC6+F0FHQTFl+Uj15Br3OeujR7AcJbPqI7Cc8Dg
         mVxkegPJUmUKc/+wBlfQQERMUDyYVxS1z1do41DcuP+uVlnfFIz19j01zOCGeuk8PT8i
         SCHchn+9TL+5FGvXhxTRC/6Kt73HnhJ64qkAM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749639000; x=1750243800;
        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=GG6aW3XDuEMUCKryLo/fh3k2eKKUNrqXRIEfIyGJ6II=;
        b=lQLd+blIyE4yaXQ2Nt2eKobEtffzJEuuvUbCGfG+6FlxJoIyinSsxdhUaRR3TzDWK5
         mmrUEib8o5ocxJ9fbyM7dwcCj0ivMha4qrD0orH1vFKvBqJ44QZABdique4hh4+de3W3
         YMcF+uGtpHTNYHL+OI0l2L9RsLCRmfaiDQgPXCZsRRN4JtoWq6OIUMCrZ1lKAuZQARli
         OvWvylWDuOwCPOo6L19pvcTy/4G5kO01TsFfl+rD/VA2KrL35jXWT9lT8l7eNqSsfC0t
         pOvAiNAFLLj+7ziJjF6qyyDW2rERclxmMckEeLmYCgwKaIrC2pMsjm1dRrcBRaipFEeY
         XlWw==
X-Forwarded-Encrypted: i=1; AJvYcCWb+MlKwwYDLHkU/JOb3KuFJrfGVIhUJwll9sl4bRPb3e0msVd8kvnBYF/vljw6iE09dnGEat8lkSA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyWeQ6FZfCB5QEcU02gWQ9O7dAa7ePz2pyLSn6e7qKLWSRhUkz+
	OwhytKgOiDn2XBTSINM7RNffszvMPr8l2IuO1WR9qdAZ87spFeOZIZ+iQPMroYfkF8rb1ybC0qD
	uDhI/LvAPxWvJ/idknBO3jN29t18ySM3IZo2Yldly0g==
X-Gm-Gg: ASbGnctMjVVg+YZal3HdMEnpZzyTZgtPx3kvjHELRaVvCZ4V8iUrQj4+pbAzP0k6VvS
	NdeMzaSmbCAF+hLg0sSpgD18/nW395Moj5+flOnASsbjAn7XD6kvPA0TdgHofDaEEO9qD5Jbw0d
	DVg9xR/cMBVhVP2ZU+IVecbNToKk6rin/luOSV82rDWBA=
X-Google-Smtp-Source: AGHT+IFhWKNulhpb9zOz9n2F0dBdP5Ohpf3TBWv2HIvwUMGzYzjAFvPRNXTZ1J17WszAAVMERRPbLNWJq6gfKXXxEdM=
X-Received: by 2002:a05:6871:9d02:b0:2cc:3523:9cd5 with SMTP id
 586e51a60fabf-2ea96d45dbfmr1566648fac.17.1749638999561; Wed, 11 Jun 2025
 03:49:59 -0700 (PDT)
MIME-Version: 1.0
References: <20250610101228.24460-1-freddy77@gmail.com> <02162717-25de-4ffb-a9c4-bf6d580c43bc@suse.com>
In-Reply-To: <02162717-25de-4ffb-a9c4-bf6d580c43bc@suse.com>
From: Frediano Ziglio 
Date: Wed, 11 Jun 2025 11:49:48 +0100
X-Gm-Features: AX0GCFsWvTYgV-U5XmRdUnFrTzTbnb3Er66SILaFcBxBFv0Zwlq0OdAB8i0wmUk
Message-ID: 
Subject: Re: [PATCH] xen: Strip xen.efi by default
To: Jan Beulich 
Cc: Frediano Ziglio , 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 Wed, Jun 11, 2025 at 10:35=E2=80=AFAM Jan Beulich  wr=
ote:
>
> On 10.06.2025 12:12, Frediano Ziglio wrote:
> > For xen.gz file we strip all symbols and have an additional
> > xen-syms file version with all symbols.
> > Make xen.efi more coherent stripping all symbols too.
>
> And the other difference (compressed vs not) still remains.
>
> > xen.efi.elf can be used for debugging.
>
> Hmm, that's the result of ...
>
> > --- a/xen/arch/x86/Makefile
> > +++ b/xen/arch/x86/Makefile
> > @@ -238,6 +238,7 @@ endif
> >               > $@.map
> >  ifeq ($(CONFIG_DEBUG_INFO),y)
> >       $(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) =
-O elf64-x86-64 $@ $@.elf
> > +     $(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(STRIP) $@
> >  endif
> >       rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]*
> >  ifeq ($(CONFIG_XEN_IBT),y)
>
> ... objcopy. Having looked at the involved code in that utility, I mistru=
st its
> output from such a conversion to really be an exact representation of the=
 input.

>From https://xenbits.xen.org/gitweb/?p=3Dxen.git;a=3Dcommit;f=3Dxen/arch/x8=
6/Makefile;h=3Df514bab30ef8d4ade77a27c926e283c9bbbf9ffd,

    Today it is not possible to analyse crash dumps of a system in
    hypervisor mode when it had been booted via EFI, as the crash utility
    doesn't understand the file format of xen.efi.

    This can easily be solved by creating an ELF file from xen.efi via
    objcopy. Using that file as name list for crash enables the user to
    analyse the dump in hypervisor mode. Note that crash isn't happy with
    a file containing no text and data, so using --only-keep-debug is not
    an option.

Isn't that true anymore?

> IOW I'd much rather use the original file. As a possible compromise, coul=
d we
> perhaps merely strip debug info, but retain the symbol table, matching th=
e
> prior default for $(efi-strip-opt)?

Not clear the compromise you are intending here, the debug file has
all information available, why do you need an intermediate one? We
strip everything for ELF, why not be coherent?

>
> Jan
>

Frediano


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 10:50:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 10:50:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011525.1389977 (Exim 4.92)
	(envelope-from )
	id 1uPJ2e-0005jb-0l; Wed, 11 Jun 2025 10:50:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011525.1389977; Wed, 11 Jun 2025 10:50:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPJ2d-0005jU-UO; Wed, 11 Jun 2025 10:50:47 +0000
Received: by outflank-mailman (input) for mailman id 1011525;
 Wed, 11 Jun 2025 10: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 1uPIwl-0002CX-1h
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 10:44:43 +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 14fb8239-46b1-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 12:44:42 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3a54700a463so532152f8f.1
 for ; Wed, 11 Jun 2025 03:44:42 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-7482b0edb54sm9164076b3a.173.2025.06.11.03.44.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 03:44:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 14fb8239-46b1-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749638682; x=1750243482; 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=qJe2b9Ve9u5yERr1EJ80GBKKaRjXsmkBckErKPpU0kg=;
        b=LNmv7DieUcYF7vRUk+HxXaVBWNcHRYi8jC5MUBtBHICgTowB/jj55c21P9eE8QkeFp
         0Lbm9scgb5lSpvkzaOfJq4yV9+fvhDwaoCMFmKnpY+aYobyr7/x5YQdKf3jpYlWOD2X8
         rlmGGn+mUPuhL1KO8fVMRwWU8otsqcVYXVdGvKLr/08KhoF4BlOshbgpFqGXsMKkbF9f
         TcaPbIQGCtdhUAKgLqcDUkuThyJwpN43TsUzwRx74ew/M7PjONsh96jUZ55+ouTXsd3i
         9dhriES90o6v5khrw4Vtk0LjbdifBeOq51YcAhBIF0WktcYfyFARjn75Fes3ep3n5wfy
         lvJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749638682; x=1750243482;
        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=qJe2b9Ve9u5yERr1EJ80GBKKaRjXsmkBckErKPpU0kg=;
        b=Fg0tdNzkedSQK3RPKvajIBTEa2ZfNaFSjAtU9A/rTw3Iihrw7gQDZryB0+TzY5aR/l
         26eF15wNASIa66LxXxHiWIgPrWXX4cWj2z/egMikRCJOguqelIGygeatLN02DtfOoOtZ
         nSFa5KUqRQzfr959rBI34UnyzQLyOeqVQaWeLmexpqcbFxiITzu7sSspYEDcHP+OVtcH
         EIyPZ5N7dNF7x6ICajXXEqWRXKTU7fxZmxVfZotOsKc6LMM3K9c8XSbEYEVoLkoHYMpU
         E6deBp95dhxu/WWZhwCh9PGWLBYEZKly68cZKbirJoV8PxsHFDqBGpw5YVVPB5Z5hvQq
         Bbsg==
X-Gm-Message-State: AOJu0Yw7iTFRHIuz+QY/Ue3dKtF65evULmePkrdoOuRbcOVhNmjTMFZd
	WCxN0tWesW8KMI+Upqui4qzZGsBRjwadmexKtMimA4S//EBP1tE8bdweKqJwNXLTozs8uVx5Vbr
	/h3Q=
X-Gm-Gg: ASbGncurnHjNGDJMw2Ysuthjrk7MxEinGjeeeBprTEuA7x/rxxHYycfUKSaGlec8Cph
	QeTV7jzRCu3ex2g1zQjuqG90WPx3TJBRXFDPyBy3flT18Yr8mNHXSsZUpwwwLMWho+cFyR1h0FQ
	R6F4EqQ+VkcixCaqeeEz6hXHPs7n7Infjuq4L8emk8DW6We+S+NmcC18klCm0m4fKVcQnkCmuzX
	hAGdbOt2BlsryjzCW6QFawx91HyqTpkLD86AamDnfEt4IlSJ3lTe134XyA8DAOk2SlodVPsPZsw
	kMtJNb2vQkVRN5voPU2qgmHgvugB3aaHJr3gsxXJ8ggZm1jiiLfJevRxhTg8N5lOCE1/kubFDJC
	jBuzpAZsAwok8AISnXzGvAUP2T/DXZ5t67GxyP8Qa290iRFw=
X-Google-Smtp-Source: AGHT+IEThpE825vd6h/mVkbXdfWYgfywPI7WN9IWWju2j1Zh1DSGUJ9hblzZlgDPFzb/2sa9bWeH1g==
X-Received: by 2002:adf:edc1:0:b0:3a5:270e:7d3 with SMTP id ffacd0b85a97d-3a55824dfdcmr1896420f8f.13.1749638681906;
        Wed, 11 Jun 2025 03:44:41 -0700 (PDT)
Message-ID: <9d0696eb-52d9-4501-8aa6-2d5e572d6433@suse.com>
Date: Wed, 11 Jun 2025 12:44:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH 6/6] vVMX: address size in decode_vmx_inst()
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <44d67587-415e-4ec1-a433-64a12aea80d7@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: <44d67587-415e-4ec1-a433-64a12aea80d7@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

While the original use of the address size file in the instruction info
provided was wrong, it still wants using: The offset into the designated
segment still may need truncating accordingly.

Fixes: 09fce8016596 ("Nested VMX: Emulation of guest VMXON/OFF instruction")
Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -441,6 +441,13 @@ static int decode_vmx_inst(struct cpu_us
             size = 4 << mode_64bit;
 
         offset = base + index * scale + disp;
+        switch ( info.fields.addr_size )
+        {
+        case 0: offset = (uint16_t)offset; break;
+        case 1: offset = (uint32_t)offset; break;
+        default:                           break;
+        }
+
         base = !mode_64bit || info.fields.segment >= x86_seg_fs ?
                seg_base + offset : offset;
         if ( offset + size - 1 < offset ||



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 10:50:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 10:50:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011526.1389988 (Exim 4.92)
	(envelope-from )
	id 1uPJ2n-00068K-81; Wed, 11 Jun 2025 10:50:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011526.1389988; Wed, 11 Jun 2025 10:50: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 1uPJ2n-000686-4m; Wed, 11 Jun 2025 10:50:57 +0000
Received: by outflank-mailman (input) for mailman id 1011526;
 Wed, 11 Jun 2025 10:50: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 1uPJ2l-0004Fr-Qb
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 10:50:55 +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 f2ecf7e6-46b1-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 12:50:55 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-43edecbfb46so55089575e9.0
 for ; Wed, 11 Jun 2025 03:50:55 -0700 (PDT)
Received: from [192.168.86.29] ([90.250.112.104])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45325171fe0sm17412485e9.20.2025.06.11.03.50.53
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 03:50:53 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f2ecf7e6-46b1-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749639054; x=1750243854; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=gN+Ok54x7bMrzS/8lQNIrcKC9XEoAHuE6NJFfXL5dVI=;
        b=sQdLVatfaOG65xpX305tsnm9ctbl5nY++fyIzgFM4k8egHGJSJZO1XKBIF2HS2A4ec
         HBgI6JoBEsPkH+7xlCpTnO71gZ5+otINID+1m7SEawp7DNQHeX4jNmhIgsZseUDqNhHm
         qENg7k7CmRFKmHpAxa5V6rHo6tSafz7e5UoDM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749639054; x=1750243854;
        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=gN+Ok54x7bMrzS/8lQNIrcKC9XEoAHuE6NJFfXL5dVI=;
        b=HsG5bsYAey8fptAP+xqr39vtLDmXfWdc6hwGFPsk/7mt7uJCvU28b+uBpzPRSbyMt1
         MaoI+3Ke/kIUf2ECQqpdk7JUq3dnKJBXrBGbHv4gj5+pF92wkkNXvXEzQR9hNuGOpTrY
         jTA2pcQ8Eda6QU+ThzBYjmkofiXX+7CjV8i1pmgPIhM4UOghigEweeTLX0nXpZc6UMnh
         /9Oda0E6Y72cRS1dhE3QhU9uhPFNupZg3eEWfnece93lbQIPag4kobNCkqdKkhTq0xew
         RvPbgFQe3lh9/DVxjTPPQL7pLPYPgK+vllARF+M4sfr5jzODA0zqXFzkRhSf0pKykVGY
         5x6Q==
X-Forwarded-Encrypted: i=1; AJvYcCU6xG9k0EXEXw/FoUFRbYJ0/OwmiXsEJGDHjzM7oaAHAmZIAPu8A68stK/WaT3UpEdrXSCJ7kf7XUQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwhLVic0GVsqTJb7iF2ZeiMPly4pwYRFxytq/TIDKeI6p9DMikj
	RTJG8yBizKnURs+oViyIggkPLig5SHBIaqsUuawz+INi4TKTeYOoool7nrysKydji1Y=
X-Gm-Gg: ASbGncuK8lXGudPbJDwtVT3wcUSFmOHUD73i343wA+f0EeRPWfmnYEIkHnHl5lOPisj
	0dfIihPwGLGmZFgxiACpzQ7nJNZgN5XH8eeMtOaBJgJwWvrmPQ+N6X3Gx8BwAOTsPQNcSc2P4lK
	kNK8wb4/TT+/miGdq6uzwGgSgW3oYWliBJnIOhlHMuA5kXWWgO4krTOCkUc9RSeNmNn5cGiGKYF
	lT2oCZpGY8A0ERB0D/eZWhJW6muHl/24qxazow9NpKgq3lM91YMAhbbwygLCl3iHisTElFV9xCH
	zX8zX2TzjZ3+zUz0JyrsgJycipaiD8GXgOFSfIyDK5heXinOVfTjIYakHTYbDsAueV9HmGjXxeg
	=
X-Google-Smtp-Source: AGHT+IH4TsgtM8qZpR7OhN6reNX9AipuF45ZaoDGtBEWcGPBrM81m45Cw0iUECJpR20zjOzY0BhPyQ==
X-Received: by 2002:a05:600c:3e06:b0:450:d07e:ee14 with SMTP id 5b1f17b1804b1-45324f3729amr24060935e9.17.1749639054253;
        Wed, 11 Jun 2025 03:50:54 -0700 (PDT)
Message-ID: <6a0e5f9a-5b02-48da-b3b7-1874ba43e3c8@citrix.com>
Date: Wed, 11 Jun 2025 11:50:53 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/6] vVMX: use reg_read()
To: Jan Beulich ,
 "xen-devel@lists.xenproject.org" 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <44d67587-415e-4ec1-a433-64a12aea80d7@suse.com>
 <5f72b1c7-968f-49c6-831b-cfc4678b5923@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: <5f72b1c7-968f-49c6-831b-cfc4678b5923@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11/06/2025 11:42 am, Jan Beulich wrote:
> Let's avoid such open-coding. There's also no need to use
> guest_cpu_user_regs(), when the function has a suitable parameter.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 10:57:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 10:57:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011556.1390006 (Exim 4.92)
	(envelope-from )
	id 1uPJ9Q-0007QM-1A; Wed, 11 Jun 2025 10:57:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011556.1390006; Wed, 11 Jun 2025 10:57: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 1uPJ9P-0007QF-UT; Wed, 11 Jun 2025 10:57:47 +0000
Received: by outflank-mailman (input) for mailman id 1011556;
 Wed, 11 Jun 2025 10:57: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 1uPJ9O-0007Ok-CU
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 10:57:46 +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 e7fd04f3-46b2-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 12:57:46 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-451d6ade159so56196125e9.1
 for ; Wed, 11 Jun 2025 03:57:46 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-453251712d8sm17527655e9.15.2025.06.11.03.57.44
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 11 Jun 2025 03:57:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e7fd04f3-46b2-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749639465; x=1750244265; 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=Cl+GhCpfu7nIBWM8Sg9hxFo9G8+cunQFO2sUMxQXoZs=;
        b=HKqCrI0GMOZwtHi1pJZqTHdVsWWwxc96aBgIRiJlbqpysk1aH3GSg2nzsejygJk1Vk
         GltdSQinyPJayyyPTofOLf+fmNpIx3SLuieOtLX7PEo+kHebYzv1YsYjLxLuEHxBFwro
         nnbgDmfuaf90Cygrlesuap6gwNef05hSp2dbY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749639465; x=1750244265;
        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=Cl+GhCpfu7nIBWM8Sg9hxFo9G8+cunQFO2sUMxQXoZs=;
        b=YHaGRyPC+t/1yYmOElRlIL3Pik32WDeW6nnjCDgHVYrPqeCzV0ZSkwRpx2XDq/VFj/
         zdVTiuFZaIbGZwSIEvOJ1H3nb25MWfLzWQytwbcorPiXEkhD8pI0fsuMXobs3jWnm3Ed
         bC3Fn8O2bSjHQGx+p3CGzHe29RY/TpXxOD1giyXGAbO3zwKiPRvZLNqxc0xjGDvBSWJC
         RZZ7KDZRn/1VApUsrJIY/iwbCu3fLNRmm+VUvPCbBQgx73UMcspPLYH3qFhmIB9EV74s
         o8Ykh5rWSohzy+QRgCBZbqCFTy8MaBpFQPA05Ui0dMGuywsclNvSuGi5ud1ytc4DNObY
         JPvA==
X-Gm-Message-State: AOJu0YylD9NwcZSKsDdYqcuPc1ItzEJ5HWYXHVzjdqbJgBUp74uzbz3f
	DBxmwStFsBmYZGpwW8qtgv3KGtH58F6RtEMMjXttpajabEvFf1WQwuEtrSJfia/4XMg4XRljg9E
	ItCle
X-Gm-Gg: ASbGncsB5UNUhs7l4mWOnpID461w+LA8R3DZ5zIykZXMzSBW9QZH1JMHOcz3pozIMec
	Ee/KwwGyZx7bC8iC79+G8pjgK/3C+YaFZtICjEckPGtnPUlZE9iD3KNu5crwenn5HKebONIa7ej
	ZuKb4zwunol/kWLX/iYNK2oSF5p92+SpCMvoxxIzFVmrisfbqB61KXVB9Zx1bgyz6nSKbvCCNOr
	3jMO2BJB87Rp68Ntx/jblsQ1jgtiqNbrV5DHTEEya1rikevex5vJ0BCbunRvPL90sN62V0vDg/S
	lzhBRouppM2xCDW3q/65dEQ1mf/iG9Kzpmm5CQHuz8QexkQeoNRFbW40Zp43apAb1P2ifq3YOaR
	ahevNToEOeHts4cSe2Yf/ENcOO8FZ4jhajED+H7YtSvjZQg==
X-Google-Smtp-Source: AGHT+IGXUC5ZbMOtNPJBzXBB0lnv1I1H7Tc3Hl7X7ASDM4YMb+Gd3GH9sdI01nxMMtqa/uusq9NGVw==
X-Received: by 2002:a05:600c:8b44:b0:453:b1c:442a with SMTP id 5b1f17b1804b1-453248db1a0mr24981415e9.27.1749639465367;
        Wed, 11 Jun 2025 03:57:45 -0700 (PDT)
Date: Wed, 11 Jun 2025 12:57:44 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: "Chen, Jiqian" 
Cc: "xen-devel@lists.xenproject.org" ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	"Orzel, Michal" ,
	Julien Grall ,
	Stefano Stabellini ,
	"Huang, Ray" 
Subject: Re: [PATCH v5 04/10] vpci: Refactor REGISTER_VPCI_INIT
Message-ID: 
References: 
 <752cff02-cef6-4a4c-80b9-eba3bbf9b264@suse.com>
 
 
 
 
 
 
 <6a7a1ab8-aabb-465b-bd22-a2bc1597b83b@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, Jun 11, 2025 at 10:19:34AM +0000, Chen, Jiqian wrote:
> Hi Roger,
> 
> On 2025/6/10 15:08, Jan Beulich wrote:
> > On 10.06.2025 05:52, Chen, Jiqian wrote:
> >> On 2025/6/9 18:40, Roger Pau Monné wrote:
> >>> On Mon, Jun 09, 2025 at 10:18:42AM +0000, Chen, Jiqian wrote:
> >>>> On 2025/6/9 17:29, Roger Pau Monné wrote:
> >>>>> On Mon, Jun 09, 2025 at 07:50:21AM +0000, Chen, Jiqian wrote:
> >>>>>> On 2025/6/6 17:14, Roger Pau Monné wrote:
> >>>>>>> On Fri, Jun 06, 2025 at 09:05:48AM +0200, Jan Beulich wrote:
> >>>>>>>> On 06.06.2025 08:29, Chen, Jiqian wrote:
> >>>>>>>>> On 2025/6/5 20:50, Roger Pau Monné wrote:
> >>>>>>>>>> On Mon, May 26, 2025 at 05:45:53PM +0800, Jiqian Chen wrote: 
> >>>>>>>>>>> +  }; \
> >>>>>>>>>>> +  static vpci_capability_t *const finit##_entry  \
> >>>>>>>>>>> +               __used_section(".data.vpci") = &finit##_t
> >>>>>>>>>>
> >>>>>>>>>> IMO this should better use .rodata instead of .data. 
> >>>>>>>>> Is below change correct?
> >>>>>>>>>
> >>>>>>>>> +    static const vpci_capability_t *const finit##_entry  \
> >>>>>>>>> +        __used_section(".rodata") = &finit##_t
> >>>>>>>>
> >>>>>>>> No, specifically because ...
> >>>>>>>>
> >>>>>>>>>> Not that it matters much in practice, as we place it in .rodata anyway.  Note
> >>>>>>>>>> however you will have to move the placement of the VPCI_ARRAY in the
> >>>>>>>>>> linker script ahead of *(.rodata.*), otherwise that section match will
> >>>>>>>>>> consume the vPCI data.
> >>>>>>>>> I am sorry, how to move it ahead of *(.rodata.*) ?
> >>>>>>>>> Is below change correct?
> >>>>>>>>>
> >>>>>>>>> diff --git a/xen/include/xen/xen.lds.h b/xen/include/xen/xen.lds.h
> >>>>>>>>> index 793d0e11450c..3817642135aa 100644
> >>>>>>>>> --- a/xen/include/xen/xen.lds.h
> >>>>>>>>> +++ b/xen/include/xen/xen.lds.h
> >>>>>>>>> @@ -188,7 +188,7 @@
> >>>>>>>>>  #define VPCI_ARRAY               \
> >>>>>>>>>         . = ALIGN(POINTER_ALIGN); \
> >>>>>>>>>         __start_vpci_array = .;   \
> >>>>>>>>> -       *(SORT(.data.vpci.*))     \
> >>>>>>>>> +       *(.rodata)             \
> >>>>>>>>
> >>>>>>>> ... this isn't - you'd move _all_ of .rodata into here, which definitely
> >>>>>>>> isn't what you want. What I understand Roger meant was a .rodata-like
> >>>>>>>> section, e.g. .rodata.vpci.* (much like it was .data.vpci.* before).
> >>>>>>>
> >>>>>>> Indeed, my suggestion was merely to use .rodata instead of .data, as
> >>>>>>> that's more accurate IMO.  I think it should be *(.rodata.vpci) (and
> >>>>>>> same section change for the __used_section() attribute.
> >>>>>>
> >>>>>> If I understand correctly, the next version will be:
> >>>>>>
> >>>>>> +    static const vpci_capability_t *const finit##_entry  \
> >>>>>> +        __used_section(".rodata.vpci") = &finit##_t
> >>>>>> +
> >>>>>>
> >>>>>> and
> >>>>>>
> >>>>>>  #define VPCI_ARRAY               \
> >>>>>>         . = ALIGN(POINTER_ALIGN); \
> >>>>>>         __start_vpci_array = .;   \
> >>>>>> -       *(SORT(.data.vpci.*))     \
> >>>>>> +       *(.rodata.vpci)           \
> >>>>>>         __end_vpci_array = .;
> >>>>>
> >>>>> Did you also move the instances of VPCI_ARRAY in the linker scripts so
> >>>>> it's before the catch-all *(.rodata.*)?
> >>>>>
> >>>>>>
> >>>>>> But, that encountered an warning when compiling.
> >>>>>> " {standard input}: Assembler messages:
> >>>>>> {standard input}:1160: Warning: setting incorrect section attributes for .rodata.vpci
> >>>>>> {standard input}: Assembler messages:
> >>>>>> {standard input}:3034: Warning: setting incorrect section attributes for .rodata.vpci
> >>>>>> {standard input}: Assembler messages:
> >>>>>> {standard input}:6686: Warning: setting incorrect section attributes for .rodata.vpci "
> >>>>>
> >>>>> What are the attributes for .rodata.vpci in the object files?  You can
> >>>>> get those using objdump or readelf, for example:
> >>>>>
> >>>>> $ objdump -h xen/drivers/vpci/msi.o
> >>>>> [...]
> >>>>>  17 .data.vpci.9  00000008  0000000000000000  0000000000000000  00000a50  2**3
> >>>>>                   CONTENTS, ALLOC, LOAD, RELOC, DATA
> >>>>>
> >>>>> It should be READONLY, otherwise you will get those messages.
> >>>>>
> >>>>>> And, during booting Xen, all value of __start_vpci_array is incorrect.
> >>>>>> Do I miss anything?
> >>>>>
> >>>>> I think that's likely because you haven't moved the instance of
> >>>>> VPCI_ARRAY in the linker script?
> >>>> Oh, right. Sorry, I forgot to move it.
> >>>> After changing this, it works now.
> >>>>
> >>>> diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
> >>>> index bf956b6c5fc0..c88fd62f4f0d 100644
> >>>> --- a/xen/arch/x86/xen.lds.S
> >>>> +++ b/xen/arch/x86/xen.lds.S
> >>>> @@ -134,6 +134,7 @@ SECTIONS
> >>>>         BUGFRAMES
> >>>>
> >>>>         *(.rodata)
> >>>> +       VPCI_ARRAY
> >>>>         *(.rodata.*)
> >>>>         *(.data.rel.ro)
> >>>>         *(.data.rel.ro.*)
> >>>> @@ -148,7 +149,6 @@ SECTIONS
> >>>>         *(.note.gnu.build-id)
> >>>>         __note_gnu_build_id_end = .;
> >>>>  #endif
> >>>> -       VPCI_ARRAY
> >>>>    } PHDR(text)
> >>>
> >>> FWIW, I would put it ahead of *(.rodata).  Remember to also modify the
> >>> linker script for all the other arches, not just x86.
> >>
> >> Whether before *(.rodata.*) or before *(.rodata), there still is the warning " Warning: setting incorrect section attributes for .rodata.vpci "
> >> And the objdump shows "rodata.vpci" has no "readonly" word.
> > 
> > Did you check what gcc emits? It may be requesting "aw" instead of the
> > wanted "a" in the section attributes. Since there are relocations here,
> > ".rodata." may not be the correct prefix to use; it may instead need to
> > be ".data.rel.ro.".
> 
> What's your opinion about changing to ".data.rel.ro.vpci" ?

Yeah, it's longer but it's the correct section prefix to use.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 11:07:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 11:07:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011568.1390016 (Exim 4.92)
	(envelope-from )
	id 1uPJIP-00018h-TE; Wed, 11 Jun 2025 11:07:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011568.1390016; Wed, 11 Jun 2025 11: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 1uPJIP-00018a-Qa; Wed, 11 Jun 2025 11:07:05 +0000
Received: by outflank-mailman (input) for mailman id 1011568;
 Wed, 11 Jun 2025 11:07: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 1uPJIO-00018T-9m
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 11:07: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 33a9b0f7-46b4-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 13:07:02 +0200 (CEST)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-442ea341570so43198125e9.1
 for ; Wed, 11 Jun 2025 04:07:02 -0700 (PDT)
Received: from [192.168.86.29] ([90.250.112.104])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45325228c2esm17790605e9.37.2025.06.11.04.07.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 04:07:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 33a9b0f7-46b4-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749640022; x=1750244822; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=rJf7a7CEriqV9+fqxFzpKUGW4Wrmcm2whxa7AjjrNjY=;
        b=upOk2SekjJjWyXpkxmgmf2RTbcVkTxTnf3P+FStKeY+ZG1hZPuqq6ccw+uz9Yq8UPz
         NuMxlGHG6EXOElS39LaFyK9XlJ7ZafqSDFT+2W0eCznvKS6e5A3d3B06bKuUO+vnjl4F
         pmBFHXCdeESPTTqTEHtqsf2ldS/gxJIo6hrfY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749640022; x=1750244822;
        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=rJf7a7CEriqV9+fqxFzpKUGW4Wrmcm2whxa7AjjrNjY=;
        b=ZNfs4os/yDcKSvHDs5ojWb21FRJ14rbhId7O+W6XQxkFjPp9h/ZgCbVlSE0wpC97gL
         1uStVukB8zbWRylesrVkM4m1K5W1MeipyasA5pa6ueDZulygiWkzgoy9TqdiLHUL/v53
         GNJSWhk1ZERGC88pZVWhMZtS6vz3831DOGJWX1qfoc9HxjOElAUTEgyxC6rDO2rT0her
         eQ3/Vf7MGKtDrM2Ox3Hm4HxnDz0boDtgHE0HmOm3ekz2wbGgBQOsQLyQjE/rhtgNbv3b
         cN2UgAMAPmlMAJBcyXJiH4uC29mfizTtfP10JHKQf/dsjcgbb4/4xpfX3h5MqLZ8e2qz
         RPng==
X-Forwarded-Encrypted: i=1; AJvYcCVrfghuDwLW4fdHSu6U9nOc4P0IOM/AUiftAJPPcVJ2bEldDdYdub6U3uHMg+RGWtes4Ryyqm04I1c=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwSe/g5KKAe7cz8Fv7B7O0jf6KsCChr9Ew3xmLivuyl6KevrdiH
	0H4VNbKjCQ09JUvUZnRFQ2S9TYAFYGwgamjQmOp9RO/OCl04WfJtX1J4kToPYoN8Dic=
X-Gm-Gg: ASbGnctSbAtHhLJl2fKZ1ETu8S9pU4uIfdKantmqGlbD7AUZHkvHgYL0tgihOMLGviU
	6UChIKFxtarcMoYg6V4V4VQDOqSxOPmTqOSuj3QKHJmXmyTiC7z4THZTk0dDRs/jCyBuaYv6gJn
	XvGoV1vDEIdEfwHQ6oiWlCcXUl9sgIynZEZPh0ht1Ygck6cD3VzF/hIaILrKSCFEFGWDZOvnlvU
	q0nd8kkDBTjkv6jlKK4w07FZCtHF/RPLcUqOPCPwtFVthzeAsE6Aq/N2c5HJvbqZmHVuUlZs0Sn
	eeUmYuoGpV0F6JS+1NjbbbrwD8uSDOOOwXVuh2Q4CO6+4bSDGHZOBOHEbYL66+Z6GvWPD20VBBz
	RPy8jacqS9g==
X-Google-Smtp-Source: AGHT+IHp7g4Ya8QktUVqtDDcOR9b0RdGhQuihIwrjwQC7/orz+KkURipHOO5ASfP+iC97pJLYUnsPg==
X-Received: by 2002:a05:600c:c494:b0:450:d012:df85 with SMTP id 5b1f17b1804b1-45324f36ddcmr22720065e9.18.1749640021873;
        Wed, 11 Jun 2025 04:07:01 -0700 (PDT)
Message-ID: 
Date: Wed, 11 Jun 2025 12:07:00 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/6] vVMX: adjust reg_read() for 32-bit guests
To: Jan Beulich ,
 "xen-devel@lists.xenproject.org" 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <44d67587-415e-4ec1-a433-64a12aea80d7@suse.com>
 <9384234e-3a07-4ae1-b632-fe007beb4c4f@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: <9384234e-3a07-4ae1-b632-fe007beb4c4f@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 11/06/2025 11:42 am, Jan Beulich wrote:
> Using the full 64-bit register values is wrong in this case; especially
> soon after a mode switch from long mode to 32-bit one upper halves of
> registers may continue to be non-zero.
>
> Fixes: 09fce8016596 ("Nested VMX: Emulation of guest VMXON/OFF instruction")
> Signed-off-by: Jan Beulich 
> ---
> Note that the affected VMX insns are invalid to use from compatibility
> mode, and hence the more expensive vmx_guest_x86_mode() doesn't need
> using here.

Fine, but you must have a comment to this effect in the code, and what
prevents compatibility mode getting here?

> (VMCALL and VMFUNC, which are permitted in compatibility
> mode, aren't taking this path. In fact both aren't dealt with at all
> [explicitly] in vvmx.c.)

VMCALL has no operands, implicit or otherwise.

VMFUNC does have implicit operands, but post-dates the last time anyone
did any serious nested virt work, hence why it's unhandled.

Personally, I think vVMFUNC emulation can safely be left to whomever
first wants it.  The only potential usecase I'm aware of has ceased to
be for unrelated reasons.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 11:13:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 11:13:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011605.1390039 (Exim 4.92)
	(envelope-from )
	id 1uPJOm-0003Md-NL; Wed, 11 Jun 2025 11:13:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011605.1390039; Wed, 11 Jun 2025 11: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 1uPJOm-0003MW-JD; Wed, 11 Jun 2025 11:13:40 +0000
Received: by outflank-mailman (input) for mailman id 1011605;
 Wed, 11 Jun 2025 11:13: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 1uPJOl-0003MQ-IP
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 11:13:39 +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 1fb8584d-46b5-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 13:13:38 +0200 (CEST)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-442ea341570so43246625e9.1
 for ; Wed, 11 Jun 2025 04:13:38 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-236034050fasm85268415ad.146.2025.06.11.04.13.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 04:13:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1fb8584d-46b5-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749640418; x=1750245218; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=wseSpK5KfbzeQolgYUIbSSWmLkd5z3FwjPuWNFkf9aw=;
        b=M2LmtewmOtNTpVm3sPwXvDLAAbOdlpt/B/LyKwlMGC3QSpwy8qDFfx9YtkwLHuXlQr
         0EMB/I4VFf6H3a9Ra3/44x3UDSGhU0Pvo0QofJhROkkv73OxrxKIfdqW2zhgauDpV2so
         DuhXle7pNIlhQOe5u2L6GMCrImLEm+wGWGyX4h4Myujawxf0kCEqmoRo4JElRHRD0OO1
         Dl4itANJcArIpuz8wwuWOoS98wOLlaGWxQ4bmWXP5neI0aYDV7Qr1TuyuvyYDqv3sELi
         M+g2vg54vh0PqEm/dP4SmKKn8q44l1ybqs7ta80leFTRjiUWV99MDK1KD7FfCNwuphGt
         ZeVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749640418; x=1750245218;
        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=wseSpK5KfbzeQolgYUIbSSWmLkd5z3FwjPuWNFkf9aw=;
        b=ddvXnppHKwM77w8zzRCukoh93OCLoo5a5Mn25Kr0/+zXgr3ofV1O5WrZHZF2+aVpPi
         btuWmWm9RsF2BinTuy+lMW4dmfDpoDs2rurBGyhj0KLLT2sCXFhuHK1xxPEI8nt8ew4U
         rIeIU5Q/tBeeFRNUawD5EDNuSBV9aKDwGajdRj2BpCOrVrmECkq/JAYXnwovCxv3u/3k
         b3hLj0DtG8L7927HYMNFAE8dde0tW5zI8QZrwEtjQPQmUiRr80abxsQtZD+bELvZvNCI
         EHnQwjothERgOJHtyCUbcJ4o8LI6qVTjWC6Xzjy67XQqE827Q5QNm4b9jKwuQtgJRE2b
         949Q==
X-Forwarded-Encrypted: i=1; AJvYcCWEEMNYfmMIkFnsVyf2RkjsLgICDSsppwasqjUED1QSjnS6ATfIQdn8PANhWaotvceCluCRJZSUY0Y=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwCu4j+j8kHXIhdAe5yEZTPuCI5E6ssn9pSgL+hc3npiskEdLjz
	WbrLXhjbInOwoHYwKFYLEamWHl2Zv88b4xWm6hx94xvAowsovHQifF+TCwGijggcNA==
X-Gm-Gg: ASbGncvqM1YMxAl2uYviovObNINjPP3OrJ2kiYeH3DkMnBZMI5kYeKt6LJG7N6Z+bcj
	V9dFeqHrIMRYeQkWLflwalfGeSr0a+tSJRRYKM58lYtnU6/htx6tFhCgU8AEwWBoP+avDswrL5b
	OCpB8wNfLBab+Low4ditKOHB9xApcxI9IPGJ5ZSUdYjOx5j03MTLx/ma2TkiUurWzT5f0PglHFU
	GcUKx+D8Sz8ga5+VO3AtIZ6Cyp6GKybvZM+AAdPz08QwPuu9NZd8S64ijZ/UZxkVoMmGBTLJgOq
	txX2BTUzqryvfQinTg09Uwi4423vPsC6BRjqtaHmcZGPMpbmopJYvCErbqHGxVaf1/3DadZ68HC
	DMKKKDqPiOYhEa0v4f+9xfVa16GLWsbOoZ6/S4377/uaTdZ0=
X-Google-Smtp-Source: AGHT+IFgayhYv4qXtue7iIMlvR3SrL1HZ7vrQGjWH8IexfoEYsBolZOEAMGoXh1K6qMxc0FABpUZyw==
X-Received: by 2002:a5d:588c:0:b0:3a4:eb80:762d with SMTP id ffacd0b85a97d-3a558b09e25mr2278188f8f.56.1749640417775;
        Wed, 11 Jun 2025 04:13:37 -0700 (PDT)
Message-ID: 
Date: Wed, 11 Jun 2025 13:13:32 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen: Strip xen.efi by default
To: Frediano Ziglio 
Cc: Frediano Ziglio ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250610101228.24460-1-freddy77@gmail.com>
 <02162717-25de-4ffb-a9c4-bf6d580c43bc@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.06.2025 12:49, Frediano Ziglio wrote:
> On Wed, Jun 11, 2025 at 10:35 AM Jan Beulich  wrote:
>>
>> On 10.06.2025 12:12, Frediano Ziglio wrote:
>>> For xen.gz file we strip all symbols and have an additional
>>> xen-syms file version with all symbols.
>>> Make xen.efi more coherent stripping all symbols too.
>>
>> And the other difference (compressed vs not) still remains.
>>
>>> xen.efi.elf can be used for debugging.
>>
>> Hmm, that's the result of ...
>>
>>> --- a/xen/arch/x86/Makefile
>>> +++ b/xen/arch/x86/Makefile
>>> @@ -238,6 +238,7 @@ endif
>>>               > $@.map
>>>  ifeq ($(CONFIG_DEBUG_INFO),y)
>>>       $(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) -O elf64-x86-64 $@ $@.elf
>>> +     $(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(STRIP) $@
>>>  endif
>>>       rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]*
>>>  ifeq ($(CONFIG_XEN_IBT),y)
>>
>> ... objcopy. Having looked at the involved code in that utility, I mistrust its
>> output from such a conversion to really be an exact representation of the input.
> 
> From https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;f=xen/arch/x86/Makefile;h=f514bab30ef8d4ade77a27c926e283c9bbbf9ffd,
> 
>     Today it is not possible to analyse crash dumps of a system in
>     hypervisor mode when it had been booted via EFI, as the crash utility
>     doesn't understand the file format of xen.efi.
> 
>     This can easily be solved by creating an ELF file from xen.efi via
>     objcopy. Using that file as name list for crash enables the user to
>     analyse the dump in hypervisor mode. Note that crash isn't happy with
>     a file containing no text and data, so using --only-keep-debug is not
>     an option.
> 
> Isn't that true anymore?

That's likely as true as before - heavily depending on objcopy not screwing up.
I don't think any thorough analysis was done back when that commit was put
together.

>> IOW I'd much rather use the original file. As a possible compromise, could we
>> perhaps merely strip debug info, but retain the symbol table, matching the
>> prior default for $(efi-strip-opt)?
> 
> Not clear the compromise you are intending here, the debug file has
> all information available, why do you need an intermediate one? We
> strip everything for ELF, why not be coherent?

If I want to e.g. see the disassembly of xen.efi, I find it heavily misleading
that I then would have to disassemble xen.efi.elf instead. One can get used to
it, sure. But for xen.gz / xen-syms it just was that way from the very
beginning (plus it's kind of obvious that a *.gz file cannot directly be
disassembled anyway). And for disassembly, the loss of debug info is far less
impactful than the loss of the symbol table. (Hence also why only debug info
was being stripped during installation so far.)

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 11:17:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 11:17:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011611.1390048 (Exim 4.92)
	(envelope-from )
	id 1uPJS4-0003vE-4I; Wed, 11 Jun 2025 11:17:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011611.1390048; Wed, 11 Jun 2025 11: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 1uPJS4-0003v7-1J; Wed, 11 Jun 2025 11:17:04 +0000
Received: by outflank-mailman (input) for mailman id 1011611;
 Wed, 11 Jun 2025 11: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 1uPJS2-0003v0-In
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 11:17:02 +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 98a7b0e7-46b5-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 13:17:01 +0200 (CEST)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3a525eee2e3so4932062f8f.2
 for ; Wed, 11 Jun 2025 04:17:01 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-7482af38353sm9283701b3a.10.2025.06.11.04.16.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 04:17:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 98a7b0e7-46b5-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749640621; x=1750245421; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=lLDSEy6Dp0uSWzx+8NrSl5JOBzfk7xturrz9sIv/fd8=;
        b=VXdyAKeMV770RKqc19L9X771QtKmJdIEjoWVQgY77NfyDuCjmO4NVoDGrB3lEfYUM2
         yjs5QtbqV4yn1VM7nphJGaDDMmCi4f6PSx2Fy1WE8BFEOapIka7C6jYJOT3LKEbbdkKj
         iBLvWWKc2bEVM6bFQfaEWyoWeg50ls8MA/INUjBmwtVNIGcjpr16eLAUHrxDEcLv1Rp3
         Ep2PiGeqEkXvgFzXlLlH+wK4nEYWN2H2Dzdd1XpfeBGV79cEl8E5V2T83JTYyzImKPtA
         D4t4vdkaUuqwrx7BI0oukWKzIf2ESxrgpZbAdkGzKaMfACNPxVxwITJPevt5WplMAhdX
         fyPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749640621; x=1750245421;
        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=lLDSEy6Dp0uSWzx+8NrSl5JOBzfk7xturrz9sIv/fd8=;
        b=exPQx8MSEVeadaOVSA3mD1v2ZHJxplfhIz/cez4pCxTIfpCYG1vZp+oEY83v8lzmT6
         BoeiQTM+RAk/S1emt4IKTBnDYPIY4Er6Vjirtu/7HKhDr54vWdPyAZROv5QngQqWGObQ
         zvJs1kv0CGxSm+Z0pzzpbLhQvQ+7r50ka1NfIIEMgu9YgMxncCKlxskTe+7Fdfc3q1MD
         Sxe+UYIbhXvTHYc45bjXCG9PkidtcIJbAVQCtwQgF7cE5Z+vcNyagJ+QUkI2S02HA+FM
         RRcnWD6RHMjTMRTJOjDwbA0GsgQSECRJEPdXRBf7iM6pDkVRTq00Lbi1U4wDfnKbGW0y
         PnpQ==
X-Forwarded-Encrypted: i=1; AJvYcCWytWlP2McaqyzLo0aMIUmETLqzwIJ4lXePXN+NBubES/wuT03eC2nwCMxqfR4D06xyLoDso6Spmcc=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz1caBIXc9pDqhUj8BQmvM76UiGloiEHQB1Cpw0p/Mj0ock7chK
	y7czdlg0kNeRBMv71FDNkK+3AmvFLZbrFFdPMYvh8eLtmaxosvFsu6jTCV6jKuqxKA==
X-Gm-Gg: ASbGncsA3tYtOk2hqVpRYX6NqAzK3GKShoqsMlPKd6OYEYoid4ZxFucy7yQqsmeiujq
	yCkM8TUh9MjmJI84kCEsxm7I+b96fNcbmMQyfO0dh0OQlXw/FtYmqB6HnnNG6poVS/j91mzH3cp
	LyW6sIL0SeauJrHgQLsxvVdfjDykt3AqV0OlLTcRcnd6jsmltmhkdnJoniBHj6CKG3GxPM5Jz5T
	v6c7Pl30TNFA7OcGGv+fyi5o2mjfgoADQI0TiIOJ2M8IR7ZebBhPR8z2ifkAmr+kocCQMPN/chw
	VZPhOmiBC3wOU5pUR7lqaujvmlRpz9DR0Oq5NE1MA/UVfUwglA40EN8+xshPS4EH+Nd6IvFte0H
	ms9NWmijzT3IenWiY4l6YfnohF6tNLJTnG6KH/O/7ZxSrbvw=
X-Google-Smtp-Source: AGHT+IExIZv8s/w3l0ticjhD8jV+Y4m0io5eSyOAkcaCXYfZmaJoFT+X5NQ5Dcdh1PzIwg1jJ23Rtg==
X-Received: by 2002:a05:6000:1446:b0:3a4:f918:9d4e with SMTP id ffacd0b85a97d-3a558ae2c77mr1947522f8f.41.1749640621026;
        Wed, 11 Jun 2025 04:17:01 -0700 (PDT)
Message-ID: 
Date: Wed, 11 Jun 2025 13:16:58 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/6] vVMX: adjust reg_read() for 32-bit guests
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "xen-devel@lists.xenproject.org" 
References: <44d67587-415e-4ec1-a433-64a12aea80d7@suse.com>
 <9384234e-3a07-4ae1-b632-fe007beb4c4f@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.06.2025 13:07, Andrew Cooper wrote:
> On 11/06/2025 11:42 am, Jan Beulich wrote:
>> Using the full 64-bit register values is wrong in this case; especially
>> soon after a mode switch from long mode to 32-bit one upper halves of
>> registers may continue to be non-zero.
>>
>> Fixes: 09fce8016596 ("Nested VMX: Emulation of guest VMXON/OFF instruction")
>> Signed-off-by: Jan Beulich 
>> ---
>> Note that the affected VMX insns are invalid to use from compatibility
>> mode, and hence the more expensive vmx_guest_x86_mode() doesn't need
>> using here.
> 
> Fine, but you must have a comment to this effect in the code, and what
> prevents compatibility mode getting here?

Sure, I can add a comment there. As to compatibility mode - the insns will
#UD, and hence no (instruction based) VMEXIT will occur.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 11:32:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 11:32:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011616.1390057 (Exim 4.92)
	(envelope-from )
	id 1uPJgt-0007BC-AV; Wed, 11 Jun 2025 11:32:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011616.1390057; Wed, 11 Jun 2025 11:32: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 1uPJgt-0007B5-7x; Wed, 11 Jun 2025 11:32:23 +0000
Received: by outflank-mailman (input) for mailman id 1011616;
 Wed, 11 Jun 2025 11:32: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 1uPJgs-0007Az-1l
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 11:32:22 +0000
Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com
 [2a00:1450:4864:20::444])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bcb74df9-46b7-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 13:32:20 +0200 (CEST)
Received: by mail-wr1-x444.google.com with SMTP id
 ffacd0b85a97d-3a548a73ff2so3139751f8f.0
 for ; Wed, 11 Jun 2025 04:32:20 -0700 (PDT)
Received: from [192.168.86.29] ([90.250.112.104])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4532515cb14sm18444985e9.13.2025.06.11.04.32.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 04:32:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bcb74df9-46b7-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749641540; x=1750246340; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=d0Xh98cVVpc3tNTxfBrKJZEIo+rMIgMk907rUjX78KM=;
        b=wEEP5VhVLEMr67dV7vXVVxT64EyDQv0Y5NUu+dRmW+9VsQzJi6/qY2W1OaPqG/uKJa
         9qb3yExNWebNR3exr97Xa4D91lhnoxMoz9NzHiJk8c9b0ymWjfX5gIk0kXRfzkJHPL8O
         LtzLP6OAo+2MuVoxei6IXSB5nnAMzsXq6FFLo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749641540; x=1750246340;
        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=d0Xh98cVVpc3tNTxfBrKJZEIo+rMIgMk907rUjX78KM=;
        b=elMcyWhYUENIsJ8QqYORw79tP1RBT90nKPHgAaO5BM/h0ia6HE+uIrPZI1wyvLhzxn
         yk8eZiyKxMd2ojmn8aZJyYoUWAG5W82q/TOGBU03CwCAlxGSat13ArrmjLa841Cap+PR
         Mt4Q999KXnRrAz+P1TTe+tyy7WBLmitooF2GVY9IrkWIXNAEhYAtzOT0LSvDxNXYroBx
         Sze3B/LMIjyMnjT/n/ZjRYGhcOrFyIXubaGdufK5UyLiI22Vv6zqUXZ4FkrTTfCxzb73
         Du4GH8TW4hzN+AAvf5a7KnS+LXpgDj3nje8nG27wwRTLy+gJ/SiDEjMKuzcU1pWYdMlA
         QcUw==
X-Forwarded-Encrypted: i=1; AJvYcCWLtbTo2NFm/joz6conljqHzJQLFy8E31R2GvzTxqb9BOKIQGcHC7dsbpMS/ivzgROKJRVCFU514Z0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyquzccolN+h8EqAuvWPk0zM+glYy6osqDTMsfCLEhFnvRSVKqJ
	SjnmnLr5EjGVUxmZ21+MTsNFuSzkXJ4Dy3TwcD87aoo4B8Nyk26CQPLaa3Q3hzpRtY4=
X-Gm-Gg: ASbGncsLjDG1+7oAahm0oTSDtHo9THY5O9uQZcrpDhkK37S5dnvi5dgXiNDaAFHOPIx
	EVA5dc24JB1iL3K73wOsh49sPMJcMK+mrVc5QWQjERCdYBh8hkqBcGWQ2O8kcJm1OpMOKtg1w3U
	cgCADCMoEoDPo8M2QFrFO63yFEmUdSAzzJpDPn+5xCOZt+DkTXMLFjoyaC8ZUyp+ct+49E7RHlb
	vdMkNC5cAF9jt7WZzyS6CMauganfS+RRB4FUE3Rq/JBgMhKuZTLqzHPeAUJphOjQ/zU8OJGVRi5
	c2J2rKR0XzQE0LrWP6fbkoAbWNviZnbQXesg/feUIZa6+RQE3DNqaujuURYylu3ZlH2XNBRcI42
	FQXh63gM3bQ==
X-Google-Smtp-Source: AGHT+IHNFMi3LoOVWczbylqB0/mXXAOI5THuvvLTqs4s/1hQ7OhP3wqF6PEnn2l+LQIQCkBcdiXi8w==
X-Received: by 2002:a05:6000:2c11:b0:3a4:f6d6:2d68 with SMTP id ffacd0b85a97d-3a558a43bdemr2475836f8f.56.1749641540257;
        Wed, 11 Jun 2025 04:32:20 -0700 (PDT)
Message-ID: <8d86577e-9ad4-46c3-b6ef-c59e471031d0@citrix.com>
Date: Wed, 11 Jun 2025 12:32:19 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/6] vVMX: operand size in decode_vmx_inst()
To: Jan Beulich ,
 "xen-devel@lists.xenproject.org" 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <44d67587-415e-4ec1-a433-64a12aea80d7@suse.com>
 <14bb65f3-5b6e-4b12-8914-25528efee557@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: <14bb65f3-5b6e-4b12-8914-25528efee557@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11/06/2025 11:44 am, Jan Beulich wrote:
> Address size is entirely irrelevant to operand size determination; For
> VMREAD and VMWRITE outside of 64-bit mode operand size is 32 bits, while
> in 64-bit mode it's (naturally) 64 bits. For all other insns it's 64
> bits (a physical address) or 128 bits (INVEPT, INVVPID). To limit the
> amount of change here, keep the latter at reading only 64 bits from
> guest space.
>
> Fixes: 09fce8016596 ("Nested VMX: Emulation of guest VMXON/OFF instruction")
> Signed-off-by: Jan Beulich 
> ---
> Beyond the wrong operand handling for INVEPT and INVVPID, the latter
> also doesn't even have the part read checked to have bits 16 and above
> all clear.

There are more bugs than these.

https://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=shortlog;h=refs/heads/x86-next-euan

Judging by the choice of branch name, I think I'd collected those
pending the re-opening of a dev window, and apparently forgotten.

At this point I don't think we want to take the branch as is (especially
as I've forgotten why it wasn't taken before), but I think there is some
salvageable work in there, beyond the changes in this patch.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 11:44:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 11:44:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011625.1390067 (Exim 4.92)
	(envelope-from )
	id 1uPJsW-0000bN-F0; Wed, 11 Jun 2025 11:44:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011625.1390067; Wed, 11 Jun 2025 11:44: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 1uPJsW-0000bG-CS; Wed, 11 Jun 2025 11:44:24 +0000
Received: by outflank-mailman (input) for mailman id 1011625;
 Wed, 11 Jun 2025 11:44: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 1uPJsU-0000Zd-Oa
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 11:44:22 +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 69d67a98-46b9-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 13:44:20 +0200 (CEST)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-60768f080d8so10030430a12.1
 for ; Wed, 11 Jun 2025 04:44:20 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ade1dc78b30sm864222566b.155.2025.06.11.04.44.18
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 11 Jun 2025 04:44:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 69d67a98-46b9-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749642260; x=1750247060; 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=/zrGz7vabRrqhZi8qJuCSsXTE3pK4LKCYUP1zEiLNUE=;
        b=ao3zxjl9JD1Fk/JEMjcOYpzmSnM9cJCbEaY7ohProSWZFSDX7f6xtcb2JuUZ4BM5GW
         8PywZiTGQM4MTppokWhuYP8XJrbzUemGiM7cnwz60Oj75OEOYzDh4G81rQXO8OZM6o4J
         6NKwQ6R3vSm0y5ZQxZ8iN7DN1w3cUOn1fJpQjmJm0WN/qIRzgVnqPIsrpSWpmjTTKnnq
         eGNgV8v2mnTWXtrRVrqX3ZlZB5oSRju1FbNGsQaf9+W3IjvOC8GGmyAl2pFrb3SEfFNn
         vNLNCe7jOzwg/JwtWqz9LNdL3LpcJQInlDGN7L1SdfjGVU9j6b++yvdnUYueybvboMsn
         X2JA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749642260; x=1750247060;
        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=/zrGz7vabRrqhZi8qJuCSsXTE3pK4LKCYUP1zEiLNUE=;
        b=M0Rl+jqOXfm+Ax5anbtHgqoBPWOi8fKbsYLAn4FbIpS9SW2pxi7LsNoeewpz+PKmRu
         4vmGWwfXRxTl7hy5L3uCPxiyRZR9hRhhlK56jrX2D5E1A3X5Qxq95CudbQc4AFO5gZkI
         o2VgjzRYCp/tZJSP23jTrpddPVd2EwZum+9eBP3UTWgegrtmts74BFdLqYJecUNxcY58
         7E4ikJYRxOQlVWdyk1hO7uh69QfX6qmP0vDnxSbJ9qChm1YFJsh81tlJcPEI6er8t+s6
         Z762fCQkR3q8XYZJ3g/mXX8uL6MIQ/utAOK0/Xl0Z+ptuv67jnuaEP1ZFUBw+LRsRrLB
         qTqg==
X-Gm-Message-State: AOJu0Yw3ZR1Lo2Jae554pnmSU/iGL8I0ymQz+EuL8RpuCtiNn7Da+g5J
	5mZOn4gShwZYgyD4Ckvps5PE4wNY0Ay9QyZDNSIYLQtsHlM/ZYQWYLmsvb1zmQ==
X-Gm-Gg: ASbGncsclFNOyCaEPo9fZkrI6XSM1z65f9ORR1uKYUqPNFxBNu4lb68JQswgxhevOon
	3eEZntSucOBCQvZIF/IjXcEYu2XV16SqiYXRCPeAuI2B/pGwySXe8Wz4J3XA7iTPoS1UqkYHIDg
	iwoDlUqgqjxYk48gsklxeZFsfgQ4lI070A2M1o/N4QXoJS8nSGnG7x6t7IzFTF1wLAfcTYwOQTU
	2JycJQAs/8sVLLYVq2Gazy/LSgatJhR2v8LlGnEZjh1Rc4a5T4UqTCP2POT3w/2qKeX0jc1Gh7+
	47hz5fF3x4JBrUOktiFsfV0NT5gPag16oKE6SKaXIT1dvV2fTruqsUwQ962htIHBx1nyfxwXrPy
	tLhRnxdlalPcxDgVhoG7T3m2CFXjv
X-Google-Smtp-Source: AGHT+IG47uhql+aAwV5zCtMf8GbeovXhTBMwIRjf+/h6sBNXAW/mmreWQ8PD33WAIgV8Ip0eQ0pqxw==
X-Received: by 2002:a17:907:3c8d:b0:ad9:db54:ba47 with SMTP id a640c23a62f3a-ade8c9111e1mr243374066b.43.1749642259824;
        Wed, 11 Jun 2025 04:44:19 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH] xen: move declarations of device_tree_get_{reg,u32}() to xen/device_tree.h
Date: Wed, 11 Jun 2025 13:44:15 +0200
Message-ID: <20250611114415.64480-1-oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

There is nothing Arm specific for these functions thereby it makes sense
to move their declarations to common header: xen/device_tree.h.

Signed-off-by: Oleksii Kurochko 
---
 xen/arch/arm/include/asm/setup.h | 6 ------
 xen/include/xen/device_tree.h    | 6 ++++++
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
index 6cf272c160..2b58549c1a 100644
--- a/xen/arch/arm/include/asm/setup.h
+++ b/xen/arch/arm/include/asm/setup.h
@@ -53,12 +53,6 @@ void setup_mm(void);
 extern uint32_t hyp_traps_vector[];
 void init_traps(void);
 
-void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
-                         uint32_t size_cells, paddr_t *start, paddr_t *size);
-
-u32 device_tree_get_u32(const void *fdt, int node,
-                        const char *prop_name, u32 dflt);
-
 int handle_device(struct domain *d, struct dt_device_node *dev, p2m_type_t p2mt,
                   struct rangeset *iomem_ranges, struct rangeset *irq_ranges);
 
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 6dc1fb5159..75017e4266 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -949,6 +949,12 @@ int dt_get_pci_domain_nr(struct dt_device_node *node);
 
 struct dt_device_node *dt_find_node_by_phandle(dt_phandle handle);
 
+void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
+                         uint32_t size_cells, paddr_t *start, paddr_t *size);
+
+u32 device_tree_get_u32(const void *fdt, int node,
+                        const char *prop_name, u32 dflt);
+
 #ifdef CONFIG_DEVICE_TREE_DEBUG
 #define dt_dprintk(fmt, args...)  \
     printk(XENLOG_DEBUG fmt, ## args)
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 11:47:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 11:47:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011631.1390077 (Exim 4.92)
	(envelope-from )
	id 1uPJvg-00017x-SN; Wed, 11 Jun 2025 11:47:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011631.1390077; Wed, 11 Jun 2025 11:47: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 1uPJvg-00017q-Pn; Wed, 11 Jun 2025 11:47:40 +0000
Received: by outflank-mailman (input) for mailman id 1011631;
 Wed, 11 Jun 2025 11:47: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 1uPJvg-00017k-A7
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 11:47:40 +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 e016766f-46b9-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 13:47:39 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3a53359dea5so2924552f8f.0
 for ; Wed, 11 Jun 2025 04:47:39 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23603405fcdsm86149575ad.159.2025.06.11.04.47.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 04:47:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e016766f-46b9-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749642459; x=1750247259; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=2oPiV7xhNtRl/qBq3/r3yErZS0CncZPYNUbUMggOG5g=;
        b=e/VrpFLB6ZgvElAadp3xeTDK+uejBQF+GHOEZ8+PwPP+VtCmLFMVy6lUoU8vOMm5aR
         nlDqrfIG5wxLxEX+m43iIkSkS524bTwH62xTyCPYJSUf5mXUrzbiv6L7o0bvCqPLmnd6
         G6WtacAoclu9Frqkpp6V0M/x/34iM8/oR8xurHNfrUXlxzwDpP8lawfEKWNOq8Yitsc/
         BJXdmWJWv46D5v9ffOuQA9PG2DXL2M3Zl3q2jftAMkGKVS+uqWnLaw/UKxe5L2TvhG7O
         w5Ty1sx0MiA+P5TOycJr5+jiP7EYi1RSpCv1rnM7CJuN5PIJbUZvcwsDppRIZ7eKtrpo
         sZdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749642459; x=1750247259;
        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=2oPiV7xhNtRl/qBq3/r3yErZS0CncZPYNUbUMggOG5g=;
        b=vCBhy9D25YUK0ltmc6CMWVtNzSbLdhq5IxxZ2pks2Ic0NDZk1bzCw4I0rKKZ2uSges
         FXhk4PQu2W0EJDFoVjvmWqLgnPXQW7VKhG3MSL7HfbQ3hhO+wU29vaKO30olwCOiQP09
         iqPjFPcuIwsl7F2a5SU2UfVT3pXmE4mYDAu+drhPGfNe9EH/ElQWrogPDOMt/rrIXpII
         XIkHWtmQXw9VjljHSyzZ+JUeX9Df/2QHT6BiftTVxxxD6+yxIH1UIpzxKj3tvVCvMmW0
         TewuF0MiW19JZTZGgotTRSmU7lKoNZG9pgne54Y8ZxWe8HrrjTjwYAFM3IVot2vSvFnz
         lURg==
X-Forwarded-Encrypted: i=1; AJvYcCUIppCdS3UZ7fVlTHrUX0ViwyQVlYPZ+xX2iVZVS4rIP+x3nkXTDq26r6TGfOdJ6ArZr2PD5+h7Dt0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxKBlkKohqwjSGIzk9t2/9ZbS0NDG6MxqHAAR7s9/QMxihoGFdK
	1DySQBYmMBwb50VK/URbPzbgJWSvoqGB0LcmYY2mb6KPLD45xzCfX/KPGVAzu43NdA==
X-Gm-Gg: ASbGncun8zbJm2QqrdDsIzSQuqlajtJQ9QxkHo019m2hf0fJjpjc155ucwF2p/ZGBMG
	LGMUI2TenQ4u2PwKirY6/CV1GTPcSskcEtd2zd5LQH7J/0TvdFHBwf/B2m+hQzjh+1NfPkKNQlG
	9qnAKNz5XgomQ13r2v/wwWQL32rcMfjhIVBAQNwCizv/KhVyRwwlx3y94/b9Hu9r3aOto3UK2gc
	6wUSm+eZE8DBztWm/YyJgKUXw31kQatt4gWtDmcwq1W0Uzji6nUPQd570ZdPYUuviKr/1urKpQ8
	nQ4D9zinDy9JCvrC0HqBzuPmOS6mDuhS9ugdhyGx9j4qgZgQjFhgXyacVA4QiNjv8WYjH/ZSQBu
	ntWjEOmaG0ayZegX17dWnXXUaClZMOcUPBjSwmOSZg3v5KJk=
X-Google-Smtp-Source: AGHT+IH83YBp6fqv5JecIv7cDC8jHanqvh9DHMJKokYY4hRc6xpazvNjuQaP04IA6Adm9irqsXRo4w==
X-Received: by 2002:a05:6000:2313:b0:3a4:dc93:1e87 with SMTP id ffacd0b85a97d-3a5586f4375mr2278067f8f.1.1749642458561;
        Wed, 11 Jun 2025 04:47:38 -0700 (PDT)
Message-ID: 
Date: Wed, 11 Jun 2025 13:47:35 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 01/20] xen/pmstat: consolidate code into pmstat.c
To: Penny Zheng 
Cc: ray.huang@amd.com, Stefano Stabellini ,
 xen-devel@lists.xenproject.org
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
 <20250528091708.390767-2-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: <20250528091708.390767-2-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 28.05.2025 11:16, Penny Zheng wrote:
> @@ -518,34 +687,3 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
>  
>      return ret;
>  }
> -
> -int acpi_set_pdc_bits(uint32_t acpi_id, XEN_GUEST_HANDLE(uint32) pdc)

You can't change ...

> --- a/xen/drivers/cpufreq/cpufreq.c
> +++ b/xen/drivers/cpufreq/cpufreq.c
> @@ -588,6 +588,37 @@ out:
>      return ret;
>  }
>  
> +int acpi_set_pdc_bits(unsigned int acpi_id, XEN_GUEST_HANDLE(uint32) pdc)

... types like this, without also adjusting the declaration. I'm about to
make a patch to address the resulting Misra regression.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 11:53:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 11:53:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011638.1390088 (Exim 4.92)
	(envelope-from )
	id 1uPK1P-0002r3-Fv; Wed, 11 Jun 2025 11:53:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011638.1390088; Wed, 11 Jun 2025 11:53:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPK1P-0002qw-D3; Wed, 11 Jun 2025 11:53:35 +0000
Received: by outflank-mailman (input) for mailman id 1011638;
 Wed, 11 Jun 2025 11:53: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 1uPK1O-0002qq-1G
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 11:53:34 +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 b2bb4c12-46ba-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 13:53:32 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3a5257748e1so4342309f8f.2
 for ; Wed, 11 Jun 2025 04:53:32 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23603077f2csm85859935ad.36.2025.06.11.04.53.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 04:53:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b2bb4c12-46ba-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749642812; x=1750247612; 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=HUpqnTcS/vMxQB2/qWUtThm4ZhOearteKd0B8fpwgvk=;
        b=Zn/eiV9zZTkq8qWXAZySK1edi1O62r6sySHbW3FPbEZxwHBTb79UXVuoS3z3CP1/qy
         wl8zd9a8oKThaP2Phn324jO2CCahww0Or9slmYPDEMz8uFBfrusQJ/4DcNBEhFwx+aMX
         AOoK+ogD2xKyJjMaD6faNJwkHmRsZJ6pNeKTE0zIF1JnxW65D4nrvWFotkAd6bSNfAjR
         Doc/Bkl0vMS3TR0vMYL+zYxreULo8/7kOOrGf/+NaLNh9RU3P5k+uNOpDL7TekUlxibx
         0t9Dkp/Ghm9HYkptE1e9zd9qfdyT6XrNJuoLuLOPyPGg4imYxpz8OGrICbGOO+UZdS+U
         q60Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749642812; x=1750247612;
        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=HUpqnTcS/vMxQB2/qWUtThm4ZhOearteKd0B8fpwgvk=;
        b=lL2mA+hl6Z8mI577A1Af8Y4d+i1m+p2fDCiBYqk/d0A0wY136WS9YCc6xEEG1FuXSu
         oAf3XbPUwjTefxwAdLeVuZQHkL3pA/b3BwgQcbBoUpmFPpU5sL7tOURG3TyvkjXJVNit
         0voKFVWzfbB838PZMo9kb+nxw0PtAPcmEIQdpi1M/9ap4qXOOn1sRmCRBcAP/PF+bl3l
         Odhu2iq+Pgzq3PnM2iwZUieIp/Z4HntdtedyTNmMEDNrQVqibH5LShqhLtIrHQxA0ogm
         OOmAAyvAi79S26HIoh9Je6QUOM0QfA5dAIG52AqQNC+ea+6K+5GEe607jEFGO0rOEXfm
         /yeA==
X-Gm-Message-State: AOJu0Yz67HVTPtAFu7DeJkqfuFRvHA7gtx6tU7IimpfbVNh2g4eEw7zD
	lBAAI/0HGReY//m8MFcMU8XkPRpplGfbpIgO5c/sYP4cQHYSZp++8wsJTnQCSachS2NJ2syeH1A
	+Tb8=
X-Gm-Gg: ASbGncvNrmUatyOBnl8M6fqw1c9EBZW1hy9ZvD/nYT4pdbKTkpteXqcW5n/XKVxwgWs
	W1YpevGgacx7m6z3mU8H0TSJP9gBbNB8v7Ti5ohw/QfkdVmTXtAEQ6DqD2qY0A/SGf/oztImWi9
	5rBb3g02Ind4Hw4pieGwihdEXhfkOXykMIGZAeUT9AbGsyK9To5yrV0vxn1VNkxHXODn3TJKDND
	hjP83mABA4POsUkVIoOZrA0M8o+42ldz03pYZ1jJ/T9KnfdTWXgAhvbi5MYueN1O7Oa2l7mjF60
	cUffKezpzAfOy+B9Lif6XvIKR0GR8WPDcjT4kiayG8H47yObL4ZEdr1sDCVZ1HrdleBnWBVUpDx
	EHyusQnntdVsdO6NGsU/ZIuOrwR75QIUfinzg45EWNTKB69Y=
X-Google-Smtp-Source: AGHT+IE91FOsJX86bWbyU8AyuQPpicRteiTDvBVkaVvAcVrV+Ib6kPhoWihWc6gKhdcyFaxX/H+rjg==
X-Received: by 2002:a05:6000:4287:b0:3a3:6415:96c8 with SMTP id ffacd0b85a97d-3a558a4465fmr2085576f8f.41.1749642812090;
        Wed, 11 Jun 2025 04:53:32 -0700 (PDT)
Message-ID: 
Date: Wed, 11 Jun 2025 13:53:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini ,
 Anthony PERARD ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Penny Zheng 
From: Jan Beulich 
Subject: [PATCH] ACPI: adjust decl of acpi_set_pdc_bits()
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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

The commit referenced below changed the type of the first parameter.
Misra C:2012 Rule 8.3 requires the declaration to follow suit.

Fixes: bf0cd071db2a ("xen/pmstat: consolidate code into pmstat.c")
Signed-off-by: Jan Beulich 

--- a/xen/include/xen/acpi.h
+++ b/xen/include/xen/acpi.h
@@ -186,7 +186,7 @@ static inline void acpi_set_csubstate_li
 #endif
 
 #ifdef XEN_GUEST_HANDLE
-int acpi_set_pdc_bits(uint32_t acpi_id, XEN_GUEST_HANDLE(uint32));
+int acpi_set_pdc_bits(unsigned int acpi_id, XEN_GUEST_HANDLE(uint32));
 #endif
 int arch_acpi_set_pdc_bits(u32 acpi_id, u32 *, u32 mask);
 


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 11:54:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 11:54:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011642.1390098 (Exim 4.92)
	(envelope-from )
	id 1uPK1x-0003Ik-N7; Wed, 11 Jun 2025 11:54:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011642.1390098; Wed, 11 Jun 2025 11:54:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPK1x-0003Id-KN; Wed, 11 Jun 2025 11:54:09 +0000
Received: by outflank-mailman (input) for mailman id 1011642;
 Wed, 11 Jun 2025 11:54: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 1uPK1w-0003IN-6a
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 11:54:08 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20630.outbound.protection.outlook.com
 [2a01:111:f403:2417::630])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c647b255-46ba-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 13:54:06 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by SN7PR12MB8769.namprd12.prod.outlook.com (2603:10b6:806:34b::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.19; Wed, 11 Jun
 2025 11:54:01 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8792.034; Wed, 11 Jun 2025
 11:54:00 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c647b255-46ba-11f0-a307-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=HkBGB4dgTnj+Bv68mEu+PT0ukwtxYBC4+rATIr2gXn2QlUqhEci0lGA3s6gqpJZKzg+qAh9ezXl2gYXoekdN3AUPiB4y0H2ZLpp2eemLjXrjBRt/o7MdP2+B4WrcJ1U3UMcC/DJGjVVF6AmKDsqpnbGbgLCcu7p3Kdvw7G+TeEpPWYmNrNLHo8Z/lWbl9MfK/ztPZ8Eru53q06M6D9FHR9lIOHD+MrEUkbnSwyZk+iMEiYP//eonR2V2cKsvSILdygbckHnksIjgojoIRtzyxYB7h652nXbZkLS/IXc8aScUq4Eporlm8+VeH94us0bsim0kSihxC6u/7vCGMueNgA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=OrVLsrPx6XW4DEkM6stIzfwimKEjZr3IfOxRKjnMDoQ=;
 b=IIW6dUQHnY/qrkPP6kTFgts3CSjiw0x+muu+QS1PbiJ6kVoiimF1gavYefx9x8VhZf3Lom0weTe/33GV5Dwz1q+DynMLwwhtQNUBdObZrFVhqvK7YkYzo8gxY9Tee+l5YcQkRDOHSlbA4UkXjAlxC6aHcD7snZXAfYR6D46B6nmhPQsADT/XttqDcZysXhfJCq7W1K0XRfyFZ5wE6Eum/2MQ8NTEc1n8WKNrbTe5pv+bNE4dnnJTWI4vHb+9wnirbxMOg1fKAaBT4vJ98ZU6Ye6UHPfoiPMf18948YtiVS9UeZHICx9fqSbPbEpLtODGO3ebbw+zqEn1qIOA1sVPgA==
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=OrVLsrPx6XW4DEkM6stIzfwimKEjZr3IfOxRKjnMDoQ=;
 b=MayRIFOmwE7GG95hTDicUQGScNStYKaGFVIUxSI/CnCVaWdoYdsA0Y38/wv2MQr/lqoB2yaxYz0TyhjjS2iIPFuiJ2mm2AkINnLnB2OrYx8LUacOd8/b/0WchKshyEtAOXKc3a98pvunE00VZxBcAVC6X1m6i/s2p1Z7U1QzWS0=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <97cefe77-d876-489e-bd54-7a79d1209774@amd.com>
Date: Wed, 11 Jun 2025 13:53:57 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen: move declarations of device_tree_get_{reg,u32}() to
 xen/device_tree.h
To: Oleksii Kurochko ,
 xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250611114415.64480-1-oleksii.kurochko@gmail.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250611114415.64480-1-oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: AM0P190CA0024.EURP190.PROD.OUTLOOK.COM
 (2603:10a6:208:190::34) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|SN7PR12MB8769:EE_
X-MS-Office365-Filtering-Correlation-Id: ac96d381-5b31-4a61-2828-08dda8dea788
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?TEdTN1pZMlNpSjF1b1VOdkNySzErUW5HS3FOZVFvcmUyb2xQVTFud3RCekF5?=
 =?utf-8?B?dWd5WVRKdHVHUTZPOGF4b3dsdkJTaEc0bWx0K1kvREt3dWUrNzJYKzhHbEx4?=
 =?utf-8?B?VWQ0YmpKUkJaamV3VjV1NW9MT3luZTJxTjZSbHBCL005Slg2SFF3ODBhUzIx?=
 =?utf-8?B?N1FGem82azY5Ynk2ZFFCQ04vZ1cydExiY1p4c3ZXcXh3eit0cmh4NEZkazRp?=
 =?utf-8?B?dzlNVWZiYTBlOEgrbXFodVl2Vk1IS2JLbjJ1Y2FUdDdGVmF5TExiMkVjL2Vs?=
 =?utf-8?B?bXBGbElxdWw3cmZjZjV5VDc5akNVQXZMUkJ2OU80VkJMZmtLWmNvUlNzZ1Jm?=
 =?utf-8?B?ZzZjYlhjallNd1FNTDd2NkNHZk9OQWJVZUtLS0RBdGQ0MGV1aENGbENMY29V?=
 =?utf-8?B?d25TVE1Bd3dZQlVvYVBQYThYQnNnWE1sT0xtNDlyOHZEWGJ5NWNlcXZhM1BF?=
 =?utf-8?B?SHByYjRka0RwNkhzRHZUa0dWdjRrUGJZMWI0L0pRMWxHUFVablRTSzg5UnU4?=
 =?utf-8?B?TjFUb1MxSEtobDIyQ0JPcFZOTDJCS0tYOW5XbDljZzd5VndQUWhkeHEvRVly?=
 =?utf-8?B?Y0ovR29vNFJWSDZDTSs2UWZrSVRZRWptY3poSlZUSDdrS3pGcnByaVE4VUFl?=
 =?utf-8?B?VE9McGt3eXlkWFMxSGd6MStidHlOMnRWVmFHU0krVHFhb0xaZHAxbldvbGxK?=
 =?utf-8?B?Y3M5R09ZRWt4UDltZ2Z1cUNXaEJUcDMrUjlPdWlNTEFUYXd3anlmU3JUYUNR?=
 =?utf-8?B?SEpFT1A1Y21YSVk2b1dkZUw5aDdtT3BSbTJtQXh0bGdwRGltdVhpWEpJK3Fq?=
 =?utf-8?B?S3RjS1FVYk5PUnRKMmRwaVBBVUdyenhZZ2RiUkZmaEd2NVdzOEx2VGI1TVRp?=
 =?utf-8?B?NXFRZVJwdWJ3Q29Kek1zaWNjTSsyOEk2YlkxYVdnWElEbU9MRkNkbWsyb29i?=
 =?utf-8?B?MnUwYy9tSGswR3g5TEpuS2l4cmlVbWppamlvRW5WOTVQVFNoVE1EK1BhdEFV?=
 =?utf-8?B?K3RReCtkNjRxQXBNcDVJNW50bVdUQmhWTWo1V095VGRXTXJGMGF1VEpSTk5z?=
 =?utf-8?B?bEx5NU9aQ3ZaZ2JzcWs4dmtDazg5amVmcThocjFpSUxiU1RDK0lmUFl3SGt5?=
 =?utf-8?B?RFJUZEIrV3lMM3VMUGc5TVFFa3FaUFlQSFF2T1VwUkZaS3RqNElrQkhyUmFw?=
 =?utf-8?B?SEwyN0tMaWc5a2pyWi9YUnVpdGRLWmJQY3NpOHlDMFgwdU9ReHlpT2xNeUQ0?=
 =?utf-8?B?TG9wR094OGFGakNEOU13WGVDS01mcGd1akVWM0lrQUtsK2hPMUVTRjdsQWJa?=
 =?utf-8?B?bU5GTlUydG42NXZNbjEreS9ma25CVy9jcEs4Tzd4Y1E2N09Cdzd3ZHBaZS8x?=
 =?utf-8?B?UXZCSGNLY21Sa1RscG1rR0UwR2hwTXBEUUErUEdBZ21lM0wwbEl1U3hIb2Vi?=
 =?utf-8?B?L3QwSUhEMzFtU2JqdCtScWxsVm12SUR3RWFNUFl0bHdTVFRtN215R1pKb3JF?=
 =?utf-8?B?aDZXUksrUzNzdnBvU0RjSHF6dlJaQVBGQXhOUU9SM1NWbThwOFFHTmYyYzFy?=
 =?utf-8?B?UkZtQ0VMS0EzS2c2bDNQOGdPcEl6WFhpUDVPZUMyZnZ1MmtGY3Yra0pOeXBZ?=
 =?utf-8?B?UnpnbzFtRk9MTE9TZit5cVNpclJnaVlFSDh4Z2ZTa2hMM3BtN0s5akRSZ0ZO?=
 =?utf-8?B?V1lVL0NjOGNjZ093dGUvdTJZMHhOc1BsZEhrbHdqSGdLU2tPZlhUNisxQlpm?=
 =?utf-8?B?S2pwaWpYNTY1cElZQ1JaWEltVGMyYlZoektxZmVVSkFJblRsNGxrVTZnOGpO?=
 =?utf-8?B?YmVqeXNkLy92VkZIOHdmR3NLb25VYVBoTzhPOXltc3pqT3FvZFM1eW55Rmxo?=
 =?utf-8?B?QmpCRnIvdEUxdnFWblpIZkFzaEVqdGVWMkltUXlUVzlERUpmU2FEb2t5dlRV?=
 =?utf-8?Q?ztLvoWuH9dY=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?T3NKQzlCb05FVXkwRVovYmpUUzAvLzl2NDJOOWw0clFEZ3R2djBKWE12VXBV?=
 =?utf-8?B?dHA0RXNYVkhndmsrUmRqYXJMNU8rZ2ZmbFZoQk0wRDFwU00vOWdPZUJ1b09a?=
 =?utf-8?B?dE1ZT2dyMXB0KzJ4eHh4TGRFWis2VTc1SjJhZUtqUnMzblZtaFFrY3NFaXdC?=
 =?utf-8?B?THFHd3duckI2RTNEMVJDbkRLOHNFQkN1U28ycSsvSGdBSFNZWkRNWElGTXAv?=
 =?utf-8?B?c21CN01lS0lWVFROOEE5OUNSQytsMlcwbFIvNlh3UGNaRkJPeEVkUGFYanU2?=
 =?utf-8?B?bm9GNGtoaG5QUW13eUJ3bXZTNS9vbnMrb3l1TGFTcmZrNDl3eGVnREZhdUxT?=
 =?utf-8?B?QVJPUEZibzhHUGF4d0Fic05seVdTUm9rRkxsMitaNEpyd29sYitWTW91aVdv?=
 =?utf-8?B?L0dTTHg0REYzLzlibUFnUFNMT3dNOC9Mb2FzTFMxYnFCaFpYbys2cC8wcEFi?=
 =?utf-8?B?MXJyZThZSElOTWlmV2NnQmVzR1RlaWhVM2dzb0JoanRXODI1dnVxVVdWbmtZ?=
 =?utf-8?B?bG0wR1RqQ1JPRGw3V2JGZXZ6UVZLV0xHOEs5VmFwSGltd1BIT0t3UWJJRXdG?=
 =?utf-8?B?MEc3QlNqN3RIVFZ3MGFDcWNZc1VCcHpiLzIvcVJ5SHZiTUsxR2pqMkhyajhO?=
 =?utf-8?B?Q2YvM3A5aG9qcG81akhlZUk2VmlpS3ZhS3hHVTlUTlVFMWZqMW5MTERCMkcz?=
 =?utf-8?B?c09mcUE1bVh6Wkh1VmxjRGUvWnV1b2M1ZHpTeE5jeEcxRHh4dm1yVVZkY1FE?=
 =?utf-8?B?MGhSdGZjYXNCU25vMFdJOXY0VCs2Y09KZGc3UUU3eUdoVmFNTkZwZVV6SGkx?=
 =?utf-8?B?QUFkU3liaDJGTlJ6V0RQMU1BSjMyV2lLY1BSamtmS0tKY0RzUXZWMTk5b3Ru?=
 =?utf-8?B?eFBoWkJUaDc4cFZRMy9WWGRhdjJFcnhkS216cEJqaWluV0FNRkI5TFlVaWQz?=
 =?utf-8?B?VlFNR084RytLMVdrN1pCYXBSaGNKRXh4S3BnYWpIK3VpOEZ2WFp2SHlob3hY?=
 =?utf-8?B?WmgvYmlwaWFWMHZ3TThsUVVzN1d3UTFGYmZ1QmdwWldBWjFuK1hDWnR5TWF3?=
 =?utf-8?B?eXE0Nk43NXFkQWJwNU5ZOXlrYlZhbXFFWVdSNTlKdlVRV015Yy9CbVA4L2VE?=
 =?utf-8?B?TnEzWHVQQVNDZjVGa3hOYUF2T1FmTDVLVWFGbjY0dTZoZ21vUU5nWDI2aUJP?=
 =?utf-8?B?U1poQzZHSXJnMG5IWWNuYXphT3VsaE03UnZYU2VrazRUeHlZUFR1RDFpaEta?=
 =?utf-8?B?aG5hZlRTL0MvMTNYNUxhV1VhZC9qMC9pdzlLVFdLRkE1aHRaOWtVOS9TOVcr?=
 =?utf-8?B?OXh3V1JXSkc1RlV3NVZxdnRrOVdqbUN3MytHRVNBNzZyenY2UVZBanIwZE9k?=
 =?utf-8?B?ODloZmhuOGRVV0g3VER2QmZaVXhMUG5NQ1gwZlcvMStHVUxqdUhLTUFkNVlt?=
 =?utf-8?B?ek5XL2RJTk1ZbVp4ejFheW1hTG5rb3dLVmtURnlJbllkdmp4bTRVSFU2Mi9D?=
 =?utf-8?B?UFU1UUlsU25FekFYZURCVThrb0tTMnFiZ1VSYkZ6SUl2Tm5wUXlJU1ZxT2xj?=
 =?utf-8?B?VnZRb09MVlprZWhDZDI3bTZ2MlVJU2huVnhSUmQ5UG5Db05HOXlTdnZiaVFR?=
 =?utf-8?B?c0p3VERsZzl2MTRWZG1SRTdqTC9IdDNaNnVEUUJZY1Zob2lyNVkwUWdKRGRH?=
 =?utf-8?B?eDRnQXB1dkRzelVjVVkxaG0ybnp1RXQzZXhuSUpiOU9jV0FIejg0YXFOLzdP?=
 =?utf-8?B?MFBNSWVIby9HdDhKRGhiVnJFU051SU90eGFuTzg4aHk5c21iTjJDOWovaHRj?=
 =?utf-8?B?MURpcmNlS3huODB2eTErQUNiN0M3RDNZcFJTRE8ybTRZWVZwWnRWNGM2RHJx?=
 =?utf-8?B?QnVDZ1ZySkQrTktQb2FFOHpLb1EvLy9FTHRNYXIwTHZFM0dQV0JYR01tdHJR?=
 =?utf-8?B?R2Rrd0hsalNpYVJ0b1B3ZUpLcExCMGlxYWllQlBjUk9QUGNmdUdxUXJxS2Fr?=
 =?utf-8?B?VFNTRGtYekVUT0N5SHA4V2tRRmZpZ0l0V2ZDOHBRV1hSdGZMR05sRjEySSsw?=
 =?utf-8?B?YTFZMm1NQVpqWmZQMzlEd0dpcXp2VENVTnJxeWh4M05DQWhYanpubldpenh5?=
 =?utf-8?Q?qsdY=3D?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ac96d381-5b31-4a61-2828-08dda8dea788
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jun 2025 11:54:00.5714
 (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: PSq3Fzvr1dikDQR7FzDmXjyG51g4iIDgfWi04VbdKpLs1fRt82gDd5oOX6tzGD6x
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB8769



On 11/06/2025 13:44, Oleksii Kurochko wrote:
> There is nothing Arm specific for these functions thereby it makes sense
> to move their declarations to common header: xen/device_tree.h.
I find it a bit odd that you don't mention that the definitions are already in
common and therefore the prototypes should be too. For me that's the main reason
(in fact the prototypes should have been moved together with definitions).

> 
> Signed-off-by: Oleksii Kurochko 
Reviewed-by: Michal Orzel 

~Michal

> ---
>  xen/arch/arm/include/asm/setup.h | 6 ------
>  xen/include/xen/device_tree.h    | 6 ++++++
>  2 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
> index 6cf272c160..2b58549c1a 100644
> --- a/xen/arch/arm/include/asm/setup.h
> +++ b/xen/arch/arm/include/asm/setup.h
> @@ -53,12 +53,6 @@ void setup_mm(void);
>  extern uint32_t hyp_traps_vector[];
>  void init_traps(void);
>  
> -void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
> -                         uint32_t size_cells, paddr_t *start, paddr_t *size);
> -
> -u32 device_tree_get_u32(const void *fdt, int node,
> -                        const char *prop_name, u32 dflt);
> -
>  int handle_device(struct domain *d, struct dt_device_node *dev, p2m_type_t p2mt,
>                    struct rangeset *iomem_ranges, struct rangeset *irq_ranges);
>  
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> index 6dc1fb5159..75017e4266 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -949,6 +949,12 @@ int dt_get_pci_domain_nr(struct dt_device_node *node);
>  
>  struct dt_device_node *dt_find_node_by_phandle(dt_phandle handle);
>  
> +void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
> +                         uint32_t size_cells, paddr_t *start, paddr_t *size);
> +
> +u32 device_tree_get_u32(const void *fdt, int node,
> +                        const char *prop_name, u32 dflt);
> +
>  #ifdef CONFIG_DEVICE_TREE_DEBUG
>  #define dt_dprintk(fmt, args...)  \
>      printk(XENLOG_DEBUG fmt, ## args)



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 12:05:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 12:05:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011653.1390107 (Exim 4.92)
	(envelope-from )
	id 1uPKCV-0005FV-My; Wed, 11 Jun 2025 12:05:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011653.1390107; Wed, 11 Jun 2025 12:05:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPKCV-0005FO-Ju; Wed, 11 Jun 2025 12:05:03 +0000
Received: by outflank-mailman (input) for mailman id 1011653;
 Wed, 11 Jun 2025 12:05: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 1uPKCU-0005FH-9T
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 12:05:02 +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 4c577902-46bc-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 14:04:59 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a54700a46eso2629574f8f.1
 for ; Wed, 11 Jun 2025 05:04:59 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-236035068ddsm85373455ad.237.2025.06.11.05.04.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 05:04:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4c577902-46bc-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749643499; x=1750248299; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=gG3/wVvXuRIb3Dz1IWYyzbvm/c7Zf2sXEz2pG6TVmS4=;
        b=Uuab6CQQf2n1wJl61BbpboQ30pL6EEUj6/OgdV1/cYKQXRzHiweBfobO9qe42glTUd
         yxZOW6w6B5z3ETjQ155eqGhfjXqsSozY/dmPi7QCgwTCeIr0+6Dt7pBvoyiK3TAS2pvj
         +V9ztDJGXiLbbNy20FAU7Jc3ouJsZanuy/h05iSGzs+YI/Zr41HQpIkdEAPAAwwuuAmh
         qi/NdbsrGGAEmeUy1PdadXao2yvIY8M3jtwnE3DT2B2hAw05Hem6l4oYKaVufNHE9g8a
         HvJc8eFRQmD2PAJP3VRWbItNKg012F1Dl7lk8xx2X83+9e+LMGzpWJjtOXn4YeVgU4SM
         mRkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749643499; x=1750248299;
        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=gG3/wVvXuRIb3Dz1IWYyzbvm/c7Zf2sXEz2pG6TVmS4=;
        b=eaqEZeLm39w3IGkKN5eiH1FA3yVYVvaotGZ5rpmUunOJhxCurbcdVWGNKPPvK+ux4z
         fVK69RfFkfTRN0VG0bphQjQ4/VAyFBp/F9pa/oI3BFWvVYredISJJdAv3aeanLSHqf9I
         WHX41L+d4A8Nd4NLfnFUGzwzrGz0mhDZSHcV/28Q+71hF0Fui3ppyEkaYpbFSuQiG7X2
         4+nvw7Pi4FuMfJOrTxsqpSNYYPpvG3/Cm5skagc0M3oAvY9VmDl9v//1NWPgcuQm9APd
         159iTROGNGY8dbZZbLiSyz3O04sVbmiDxKBRuNX5aZK2pV2vSmhTe+PWCYeW4Koza5NW
         AYMA==
X-Forwarded-Encrypted: i=1; AJvYcCVgHBcC4DYppvnhyQkkyN2W5CskGkrJ/DrO269WysDtrK1qIRYS4qxILMTKP0Wju4BIsBrdlbHsFeQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw+kBgOVjgcydSw2yjVoQtOBz4HmdRMRZypkFbOqZkNTEyUvsUt
	+Q3hS2jzOSolypZhj/8kHljjkelwXYGZQai2qJPU3G6yNDgg54gpTfzsOtESheeqAQ==
X-Gm-Gg: ASbGncvpZgNymJSH4DaavSfIpIdb5+aw2CSzotG9XY1iMPUNkapt2URmrB5lnvXqzzJ
	F7r+abre98+WyRyK3lsZ6g3AknEIU16QeQzoYm1s66+OIuAK6Y9YgcDWnr1EmPHH+GBpyEdgLAF
	0P+Eb2u3Z44WJhq3+/WVIWxcoG3q2KC1DBXsOILbRZiktMxDnA4kdw/mJmLGvKYgGeR9daoUK9w
	xx9MgFzHWBp/A9EbffN2XVCTzIsd/bcGmHAi4duRNpd1RqSDB58tHkEXhnGL25jshVQGtm5iDVf
	OP6i06vMkt/gxDI4GwAlInUQb+ZHSxfHQDmRFWo3nHBLMOBjAOCX/59UUzPLGAqCbnn24EX/yb7
	siaA27CryDJ9t9TlwzuhNaHhezA3IyIXZuOSDge59hImWreQ=
X-Google-Smtp-Source: AGHT+IHQJw46Go1m0PZ6JTmXIF5NLZQx+JQ8ujfMtmaSIm+u5Xn2padnnIgXgE76I+kj8Lx3ni+qsw==
X-Received: by 2002:a5d:64c9:0:b0:3a3:652d:1638 with SMTP id ffacd0b85a97d-3a5586e9619mr2400119f8f.48.1749643499155;
        Wed, 11 Jun 2025 05:04:59 -0700 (PDT)
Message-ID: 
Date: Wed, 11 Jun 2025 14:04:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/6] vVMX: operand size in decode_vmx_inst()
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "xen-devel@lists.xenproject.org" 
References: <44d67587-415e-4ec1-a433-64a12aea80d7@suse.com>
 <14bb65f3-5b6e-4b12-8914-25528efee557@suse.com>
 <8d86577e-9ad4-46c3-b6ef-c59e471031d0@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: <8d86577e-9ad4-46c3-b6ef-c59e471031d0@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.06.2025 13:32, Andrew Cooper wrote:
> On 11/06/2025 11:44 am, Jan Beulich wrote:
>> Address size is entirely irrelevant to operand size determination; For
>> VMREAD and VMWRITE outside of 64-bit mode operand size is 32 bits, while
>> in 64-bit mode it's (naturally) 64 bits. For all other insns it's 64
>> bits (a physical address) or 128 bits (INVEPT, INVVPID). To limit the
>> amount of change here, keep the latter at reading only 64 bits from
>> guest space.
>>
>> Fixes: 09fce8016596 ("Nested VMX: Emulation of guest VMXON/OFF instruction")
>> Signed-off-by: Jan Beulich 
>> ---
>> Beyond the wrong operand handling for INVEPT and INVVPID, the latter
>> also doesn't even have the part read checked to have bits 16 and above
>> all clear.
> 
> There are more bugs than these.
> 
> https://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=shortlog;h=refs/heads/x86-next-euan
> 
> Judging by the choice of branch name, I think I'd collected those
> pending the re-opening of a dev window, and apparently forgotten.
> 
> At this point I don't think we want to take the branch as is (especially
> as I've forgotten why it wasn't taken before), but I think there is some
> salvageable work in there, beyond the changes in this patch.

Interesting. Apparently it has been too long since this was posted, as I
don't recall it at all. However, I'm not convinced everything's right
there. E.g. in "x86/vvmx: Use correct sizes when reading operands" there
is this hunk:

@@ -427,6 +427,7 @@ static int decode_vmx_inst(struct cpu_user_regs *regs,
     struct segment_register seg;
     unsigned long base, index, seg_base, disp, offset;
     int scale, size;
+    unsigned int bytes = vmx_guest_x86_mode(v);
 
     __vmread(VMX_INSTRUCTION_INFO, &offset);
     info.word = offset;

Which is hardly correct for 16-bit protected mode. INVEPT and INVVPID
handling also isn't moving to 128-bit operands, despite what the title
suggests. The commit message wrongly claims the upper halves don't need
to be read.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 12:06:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 12:06:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011659.1390118 (Exim 4.92)
	(envelope-from )
	id 1uPKDo-0005kW-02; Wed, 11 Jun 2025 12:06:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011659.1390118; Wed, 11 Jun 2025 12:06: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 1uPKDn-0005kP-T9; Wed, 11 Jun 2025 12:06:23 +0000
Received: by outflank-mailman (input) for mailman id 1011659;
 Wed, 11 Jun 2025 12:06: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 1uPKDl-0005kH-GE
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 12:06:22 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7c17014b-46bc-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 14:06:20 +0200 (CEST)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 (Authenticated sender: nicola)
 by support.bugseng.com (Postfix) with ESMTPA id EE8414EE8F5D;
 Wed, 11 Jun 2025 14:06:18 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7c17014b-46bc-11f0-a307-13f23c93f187
Authentication-Results: bugseng.com; arc=none smtp.remote-ip=162.55.131.47
ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1749643579;
	b=rriupZzlkurJrbTqhuQHGLxa8zfofIkjg5Oh6G+yuCt/v6Bg1BlbLZg7mAAGIy0GmVj2
	 i+KIcDcDemsOqHahg+BSPJWxj+Lz/PUFoGSFU0NoRKruJwH4HbLnmp0uhR4SUKlpdhsxV
	 eVo2FUNbHBCVPMXIvIRAJRfkDRka7vuF2y3PU0ECQkj3pYSTlwN37iA4+TWXOEeKoKDL9
	 gh7zM2zEHVX6i/0/vZv2f02PEtVck7LQQUCPUpqWQbHGPoXoTzsTCiGjj7AzQGtHmznFm
	 Lyz8SvFNV7PbcBHWEfSEO7Y8izoze6Z8p8SHM00oKZj0P6zwlkHErB6JVPLt/Ven0ZwHI
	 5V+u0OwrH8CphXlxcipnRIxf4UDhH9lqGzF6JIK7+l8PYU7D4UITsgUYk8IxCjhKkSTAr
	 QfaShkz/VEMfzATGKnhzw2mrK9EBmaaYjKWkry4EBumUGqUJCRvM0gWAx5KixYXCeKoL4
	 0oakmFrsL66w+gVq5V43Y5GkwQwLH0+GBRh1IFMC/kQ47/CYj9vubwqC1weNtjt/vM7SQ
	 umRhflr2BPZramcDt+kXxr93hfsyWWEOAVpU5SLHIcCeqlToHB6Tg11x/VjnHbWp7QUrW
	 jOux6gyh0E0kvWSFeaaGVYzZekiRc8m1hdp1oRf7gMU74uL+lKYsgU7k+IjCK2w=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1749643579;
	h=DKIM-Signature:MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:
	 References:Message-ID:X-Sender:Organization:Content-Type:
	 Content-Transfer-Encoding;
	bh=w9w2r+koGR7DMadVKQE4z3ElAhB0YRhm/wj3E/ACduQ=;
	b=oPzYJNH6VwraeuRH56kf93G4gGvq7nQfdGC05oMFZnPni58X/0wYXrqXgaL/NQPnCFie
	 4FjMsFmj/9yR+5uJExt6O2J+mZMArocFdUGbqD+EztMgpZirT/jSBjBQbJalmf7MHuEKf
	 jTNcOBy57kobWkN9GNrnxSyBFZa3TrTic7AbEAL0XjFo1G0mdmmY+eIbUyqkuxE4rCXqt
	 S0K3ONdqXHQkGrqgCGvPtN59zAnlv9IfuuJPVYPQ+GAfMGoySLmEqXqhnRuCvUslglE51
	 MOu23wc81juXTHT8bfm7E/6UJ7XC4u7q91kwsRM1nQpKcYvfS7vu5cgT/vlp5SxV6KTT6
	 iyLFTv/6tEStxTNy0Jb8APGqChnaDF05EaVQKaJ0RxZLRFpN/n+r4ldWECtf+1EaWb6n4
	 vz2NfMxsT+NM6hfKvsVXF97GreGskniMXHkuS7eEmKiDxlDXBvjE0+7Jj7z4uPJCvaKsT
	 hD23eyN36G0N3O4W0vPFTEptrADdDd4K1PmdeADYwWn0RGnxYXO/d8ycu47jTZgzC/P2U
	 Ekqus5l6toj/Kg96jW8BvxIMzgZLKF+EUU0Manfq7w7F202hMYckjDX2Bj2zwnAS7tnl4
	 zD5HCuCr7jZQXB3MyFX5+8xxYMsq58FKHqFhJuMeDAg9gYz+Q6kskxlfObiYMNU=
ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1749643579; bh=xyQlaxaW0pVpATBCqaCUCYcSmWeIT+C4k/1UhJcgDlY=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=shxInLogNvlmUy3NUq4Ph4A0Z7uhvSd4PzB5hTA2kF2t9qPEQHEhHfjyvHYlh3aJ4
	 AAK6gzj+KKdSk1EXauLnkJs9NQL2YaZL/wCGsLgOK1ZF9Ybe/IbAFJo/frkcpPGJWZ
	 Tw9AsqpbXrjHgqr5PPIwL1F7TDvKG+7N5n31mlKLL7KOQiJMNAK0K4k4SQK0BB6QHa
	 NP0e0o21Rhc93Do9H/FV4b0uydN+HW8VHqx2HeLFqFBFJpQtT3iIWs0YC23HqAoNJq
	 G3BkcnixDhZdkRyMP4Xl3aDR3LjbORHtFkcqKmOqI/svR4GN9DVLQRE4QwQFKdTtC6
	 OxLOYbltO9RTQ==
MIME-Version: 1.0
Date: Wed, 11 Jun 2025 14:06:18 +0200
From: Nicola Vetrini 
To: Jan Beulich 
Cc: xen-devel@lists.xenproject.org, Andrew Cooper
 , Julien Grall , Stefano
 Stabellini , Anthony PERARD
 , Michal Orzel ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Penny Zheng
 
Subject: Re: [PATCH] ACPI: adjust decl of acpi_set_pdc_bits()
In-Reply-To: 
References: 
Message-ID: <21a1af12f26a27703689939cf80d1f80@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 2025-06-11 13:53, Jan Beulich wrote:
> The commit referenced below changed the type of the first parameter.
> Misra C:2012 Rule 8.3 requires the declaration to follow suit.
> 
> Fixes: bf0cd071db2a ("xen/pmstat: consolidate code into pmstat.c")
> Signed-off-by: Jan Beulich 
> 

Reviewed-by: Nicola Vetrini 

> --- a/xen/include/xen/acpi.h
> +++ b/xen/include/xen/acpi.h
> @@ -186,7 +186,7 @@ static inline void acpi_set_csubstate_li
>  #endif
> 
>  #ifdef XEN_GUEST_HANDLE
> -int acpi_set_pdc_bits(uint32_t acpi_id, XEN_GUEST_HANDLE(uint32));
> +int acpi_set_pdc_bits(unsigned int acpi_id, XEN_GUEST_HANDLE(uint32));
>  #endif
>  int arch_acpi_set_pdc_bits(u32 acpi_id, u32 *, u32 mask);

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 12:22:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 12:22:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011667.1390128 (Exim 4.92)
	(envelope-from )
	id 1uPKTd-0000G7-8b; Wed, 11 Jun 2025 12:22:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011667.1390128; Wed, 11 Jun 2025 12:22:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPKTd-0000G0-5t; Wed, 11 Jun 2025 12:22:45 +0000
Received: by outflank-mailman (input) for mailman id 1011667;
 Wed, 11 Jun 2025 12:22: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 1uPKTb-0000Fu-6F
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 12:22:43 +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 bfeb8e9c-46be-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 14:22:32 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3a53359dea5so2955820f8f.0
 for ; Wed, 11 Jun 2025 05:22:32 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b2f5f7823c7sm8311543a12.56.2025.06.11.05.22.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 05:22:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bfeb8e9c-46be-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749644552; x=1750249352; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=h2Usbbx70jDuByGmRoimETVcLg8DV/t01fI+LAvTcvw=;
        b=CI85jUCp3n6CeXMieQmqjU7fqIhvDd/sDfazUsGESF/8w91JzCSQUHL93twQYUaY09
         SmC2XgxwjHMX0Y8MDBUDBvx5KnlUtFHYNY7M9ieTI5BPIDeAyjPJsA6+kEL6E9IJwIyw
         S6I/wffiSL1NjPirO4TYt6qmBei0pHaHCx8rQ2P1K/y2DazaC95cHclBi5hNPGQmV49K
         vHdO2kwFbKswhj73IlrMZaGAoGBhTF7K+LwAVGyiqfMKlPrjgRkS6zgkeU/qohbOWrm5
         oc9QO7CoQF7q95U1eqj0Uhc7YVnPD8xjLs/H29TAjH0JVzt3k5ehRe9sRbv9pq9/NiGT
         E2ZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749644552; x=1750249352;
        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=h2Usbbx70jDuByGmRoimETVcLg8DV/t01fI+LAvTcvw=;
        b=OoYwta4lUusCsZvMl+fODhqAR8jHhvQaVV/5haRiT7SIS0RGGQsgLMi7Aq3IsATEMd
         SXBp4WKlc5iUtfKtJLhjuBGqsK7v4kE42/F9QXyVELNWx/nR5eQUh/1ooRaTCCBn2fy9
         64YOq6D0V2aP5+ZVp1kVaQcaNn41mFX1gme87RVEcC+pHFhVKxLPWVfVBynqLR6Sw7bC
         TxWMTRIwqjKIoVwAQ9+uLW2ZpXtsisxJACbGMpstO30Pg0po9gbMnwrZwJG4224KOh7P
         JMNHwIq9uZAeP6x1FjwDodulBm6CnICBHKQb+Jim/HoLAfim++9OSbZ+vIJDVCiWYg/8
         I6aA==
X-Forwarded-Encrypted: i=1; AJvYcCWIFOs43FybAjBgo7PfYwdS19x8QYYXG8e0XP4cWmidv486lEUh8e/B5ehgIt2FTRAN3mIeKmae7Kc=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyxw/LyzzGasrQ133mrQJXFqctcxGSValHgu1S3/0dCQOAf+Z6+
	1CfieCF3cZGGpkqCq0ZQ5Cv9QEeW0tYwje+mJ0D7PUI0o579n9VoBTUYGqgaA6cujg==
X-Gm-Gg: ASbGnctZJNK3+hvCEj/JYHxqF9eE8/vz5b4uSCmFcZvqmEJVpvQi1sgBx4pIkyOeUgk
	cJHtUQOWfjthk0B9FWqrj39dmmji6XB7RvI2FjU4jRkBzZVysqd2lBJcXKSYz+l3GPA3qwXMcdC
	FZpPxgHXD7kYxL3v8hmUepSbdzNxNJQwLoma8idoaksZF1mBf/zdo4rZIIvecDMyKFXDgdjcnVV
	PqYRjIVoXf7N3G1dekivvE7E52ka+2cuSNam4hqX2PoNuP/MHDVaxif4f2+YDk/J0r7OYgEY/+2
	uZreHFX6iW+kdYCOjZwhXUjpSlYO1LAq9DfLQnBtaJ6VjEw5qiwmRoh6u/3Dquwu5hRQ20yH5mW
	C8s+g8H3VcbppPxDe1krpCaU+kKfru/0m6fBO9NiuBMIr3jg=
X-Google-Smtp-Source: AGHT+IH+pVbEMLmnwJE1ZCiyM6J/NGZRtJOI4fc+ZoXrBSWlKk0IxeVndR6MaAkBoIBADY7BRkQjJw==
X-Received: by 2002:a05:6000:2382:b0:3a4:eae1:a79f with SMTP id ffacd0b85a97d-3a558a325e3mr2527626f8f.33.1749644552147;
        Wed, 11 Jun 2025 05:22:32 -0700 (PDT)
Message-ID: <3e5713bc-93ee-45e3-ad45-b79904539284@suse.com>
Date: Wed, 11 Jun 2025 14:22:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4] x86/hvmloader: select xenpci MMIO BAR UC or WB MTRR
 cache attribute
To: Roger Pau Monne 
Cc: Oleksii Kurochko ,
 Community Manager ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , Juergen Gross
 , Anthoine Bourgeois ,
 xen-devel@lists.xenproject.org
References: <20250610162930.89055-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: <20250610162930.89055-1-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 10.06.2025 18:29, Roger Pau Monne wrote:
> The Xen PCI device (vendor ID 0x5853) exposed to x86 HVM guests doesn't
> have the functionality of a traditional PCI device.  The exposed MMIO BAR
> is used by some guests (including Linux) as a safe place to map foreign
> memory, including the grant table itself.
> 
> Traditionally BARs from devices have the uncacheable (UC) cache attribute
> from the MTRR, to ensure correct functionality of such devices.  hvmloader
> mimics this behavior and sets the MTRR attributes of both the low and high
> PCI MMIO windows (where BARs of PCI devices reside) as UC in MTRR.
> 
> This however causes performance issues for users of the Xen PCI device BAR,
> as for the purposes of mapping remote memory there's no need to use the UC
> attribute.  On Intel systems this is worked around by using iPAT, that
> allows the hypervisor to force the effective cache attribute of a p2m entry
> regardless of the guest PAT value.  AMD however doesn't have an equivalent
> of iPAT, and guest PAT values are always considered.
> 
> Linux commit:
> 
> 41925b105e34 xen: replace xen_remap() with memremap()
> 
> Attempted to mitigate this by forcing mappings of the grant-table to use
> the write-back (WB) cache attribute.  However Linux memremap() takes MTRRs
> into account to calculate which PAT type to use, and seeing the MTRR cache
> attribute for the region being UC the PAT also ends up as UC, regardless of
> the caller having requested WB.
> 
> As a workaround to allow current Linux to map the grant-table as WB using
> memremap() introduce an xl.cfg option (xenpci_bar_uc=0) that can be used to
> select whether the Xen PCI device BAR will have the UC attribute in MTRR.
> Such workaround in hvmloader should also be paired with a fix for Linux so
> it attempts to change the MTRR of the Xen PCI device BAR to WB by itself.
> 
> Overall, the long term solution would be to provide the guest with a safe
> range in the guest physical address space where mappings to foreign pages
> can be created.
> 
> Some vif throughput performance figures provided by Anthoine from a 8
> vCPUs, 4GB of RAM HVM guest(s) running on AMD hardware:
> 
> Without this patch:
> vm -> dom0: 1.1Gb/s
> vm -> vm:   5.0Gb/s
> 
> With the patch:
> vm -> dom0: 4.5Gb/s
> vm -> vm:   7.0Gb/s
> 
> Reported-by: Anthoine Bourgeois 
> Signed-off-by: Roger Pau Monné 
> Reviewed-by: Oleksii Kurochko

Acked-by: Jan Beulich  # hvmloader



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 12:58:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 12:58:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011700.1390150 (Exim 4.92)
	(envelope-from )
	id 1uPL2P-0004WB-VS; Wed, 11 Jun 2025 12:58:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011700.1390150; Wed, 11 Jun 2025 12:58:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPL2P-0004W4-SZ; Wed, 11 Jun 2025 12:58:41 +0000
Received: by outflank-mailman (input) for mailman id 1011700;
 Wed, 11 Jun 2025 12:58:41 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uPL2O-0004Vy-Rx
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 12:58:41 +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 cb5dff98-46c3-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 14:58:39 +0200 (CEST)
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 D2ADE211FA;
 Wed, 11 Jun 2025 12:58: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 561A0137FE;
 Wed, 11 Jun 2025 12:58: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 CpxNE359SWieRAAAD6G6ig
 (envelope-from ); Wed, 11 Jun 2025 12:58: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: cb5dff98-46c3-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1749646718; 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=Q9scDhxdSxrhQDSFyJ01DGBn4P9xC44kWau4Ktpczak=;
	b=n7n8zpSvfPFUzxn5mYl/BLvpr5WzpeLvFfLTCMVD7qBDFwsZt/E/tojrfCoYEqv09og4zX
	nIV0gICFiE7Cd5qgYdkf6yTWIzzXVRfej8wRZja2voIMiVCaXhhtf6BrFC+FwYw1qlmYdp
	JVjkVGnik2dlHG+TO3azg22SMnVFUUI=
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=n7n8zpSv
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1749646718; 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=Q9scDhxdSxrhQDSFyJ01DGBn4P9xC44kWau4Ktpczak=;
	b=n7n8zpSvfPFUzxn5mYl/BLvpr5WzpeLvFfLTCMVD7qBDFwsZt/E/tojrfCoYEqv09og4zX
	nIV0gICFiE7Cd5qgYdkf6yTWIzzXVRfej8wRZja2voIMiVCaXhhtf6BrFC+FwYw1qlmYdp
	JVjkVGnik2dlHG+TO3azg22SMnVFUUI=
Message-ID: <8a82946a-6c3e-41d1-b3bd-be164dc6eeba@suse.com>
Date: Wed, 11 Jun 2025 14:58:37 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/6] x86/paravirt: Switch MSR access pv_ops functions to
 instruction interfaces
To: Xin Li , linux-kernel@vger.kernel.org, x86@kernel.org,
 virtualization@lists.linux.dev
Cc: Ajay Kaher ,
 Broadcom internal kernel review list
 , Thomas Gleixner
 , Ingo Molnar ,
 Borislav Petkov , Dave Hansen ,
 "H. Peter Anvin" ,
 Boris Ostrovsky ,
 xen-devel@lists.xenproject.org, Andrew Cooper 
References: <20250506092015.1849-1-jgross@suse.com>
 <20250506092015.1849-6-jgross@suse.com>
 <722f5b30-20e9-4540-98e4-d211d7c44cbe@zytor.com>
 <9f4e33d5-9cb3-4079-b764-87a15265fd52@suse.com>
 <2365af70-d36f-4663-b819-59d886936ef5@zytor.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: <2365af70-d36f-4663-b819-59d886936ef5@zytor.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------oels03X95c0cS93P70Cfnsn7"
X-Spamd-Result: default: False [-6.41 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SIGNED_PGP(-2.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	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_UNKNOWN(0.10)[application/pgp-keys];
	MIME_BASE64_TEXT(0.10)[];
	MX_GOOD(-0.01)[];
	DKIM_TRACE(0.00)[suse.com:+];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[14];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~];
	RCVD_TLS_ALL(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	TO_DN_SOME(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns,suse.com:dkim,suse.com:mid];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	HAS_ATTACHMENT(0.00)[]
X-Spam-Level: 
X-Spam-Flag: NO
X-Rspamd-Queue-Id: D2ADE211FA
X-Rspamd-Action: no action
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Score: -6.41

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------oels03X95c0cS93P70Cfnsn7
Content-Type: multipart/mixed; boundary="------------5m4wyWuZsrcf0JlaWaNuLGP3";
 protected-headers="v1"
From: Juergen Gross 
To: Xin Li , linux-kernel@vger.kernel.org, x86@kernel.org,
 virtualization@lists.linux.dev
Cc: Ajay Kaher ,
 Broadcom internal kernel review list
 , Thomas Gleixner
 , Ingo Molnar ,
 Borislav Petkov , Dave Hansen ,
 "H. Peter Anvin" ,
 Boris Ostrovsky ,
 xen-devel@lists.xenproject.org, Andrew Cooper 
Message-ID: <8a82946a-6c3e-41d1-b3bd-be164dc6eeba@suse.com>
Subject: Re: [PATCH 5/6] x86/paravirt: Switch MSR access pv_ops functions to
 instruction interfaces
References: <20250506092015.1849-1-jgross@suse.com>
 <20250506092015.1849-6-jgross@suse.com>
 <722f5b30-20e9-4540-98e4-d211d7c44cbe@zytor.com>
 <9f4e33d5-9cb3-4079-b764-87a15265fd52@suse.com>
 <2365af70-d36f-4663-b819-59d886936ef5@zytor.com>
In-Reply-To: <2365af70-d36f-4663-b819-59d886936ef5@zytor.com>

--------------5m4wyWuZsrcf0JlaWaNuLGP3
Content-Type: multipart/mixed; boundary="------------pefjOMlVvz4lJIGDtsC3KwYp"

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

T24gMTMuMDUuMjUgMDk6NDQsIFhpbiBMaSB3cm90ZToNCj4gT24gNS8xMi8yMDI1IDQ6MjAg
QU0sIErDvHJnZW4gR3Jvw58gd3JvdGU6DQo+PiBPbiAwOS4wNS4yNSAxMDoxOCwgWGluIExp
IHdyb3RlOg0KPj4+IE9uIDUvNi8yMDI1IDI6MjAgQU0sIEp1ZXJnZW4gR3Jvc3Mgd3JvdGU6
DQo+Pj4gSSdtIHRyeWluZyB0byBldmFsdWF0ZSBob3cgdG8gYWRkIHRoZSBpbW1lZGlhdGUg
Zm9ybSBNU1IgaW5zdHJ1Y3Rpb25zDQo+Pj4gb24gdG9wIG9mIHRoaXMgcGF0Y2ggc2V0LsKg
IEFuZCBJJ20gY2xvc2UgdG8gZ2V0IGl0IGRvbmUuDQo+Pg0KPj4gVGhlcmUgaXMgc29tZXRo
aW5nIHRvIGNvbnNpZGVyIHdoZW4gcnVubmluZyBhcyBhIFhlbiBQViBndWVzdCwgLi4uDQo+
IA0KPiBBbmRyZXcgc2FpZCBoZSBkb2Vucyd0IHBsYW4gdG8gZXhwb3NlIFdSTVNSTlMgdG8g
UFYgZ3Vlc3RzLCBhbmQgZG9lc24ndA0KPiBleHBlY3QgTVNSX0lNTSB0byBiZSB1c2VmdWwg
aW4gYSBQViBndWVzdCBlaXRoZXIsIHdoaWNoIEkgZnVsbHkgYWdyZWUuDQo+Pj4+DQo+Pj4+
IE5vdGUgdGhhdCBpbiB0aGUgWGVuIFBWIGNhc2UgdGhlIFJETVNSL1dSTVNSIHBhdGNoaW5n
IG11c3Qgbm90IGhhcHBlbg0KPj4+PiBldmVuIGFzIGFuIGludGVybWVkaWF0ZSBzdGVwLCBh
cyB0aGlzIHdvdWxkIGNsb2JiZXIgdGhlIGluZGlyZWN0IGNhbGwNCj4+Pj4gaW5mb3JtYXRp
b24gbmVlZGVkIHdoZW4gcGF0Y2hpbmcgaW4gdGhlIGRpcmVjdCBjYWxsIGZvciB0aGUgWGVu
IGNhc2UuDQo+Pj4NCj4+PiBHb29kIHBvaW50IQ0KPj4NCj4+IC4uLiBhcyB0aGlzIHN0aWxs
IG5lZWRzIHRvIGJlIHRydWUuDQo+Pg0KPj4gVGhlcmUgYXJlIDIgZGlmZmVyZW50IHdheXMg
dG8gZGVhbCB3aXRoIHRoaXM6DQo+Pg0KPj4gMS4gV2hlbiBydW5uaW5nIGFzIGEgWGVuIFBW
IGd1ZXN0IGRpc2FibGUgWDg2X0ZFQVRVUkVfV1JNU1JOUyBhbmQNCj4+IMKgwqDCoCBBU01f
V1JNU1JOU19JTU0gKGUuZy4gaW4geGVuX2luaXRfY2FwYWJpbGl0aWVzKCkpLg0KPj4NCj4+
IDIuIEJ1ZmZlciB0aGUgb3JpZ2luYWwgaW5zdHJ1Y3Rpb24gYmVmb3JlIHBhdGNoaW5nIGlu
IGFwcGx5X2FsdGVybmF0aXZlcygpDQo+PiDCoMKgwqAgaW4gb3JkZXIgdG8gYXZvaWQgdGhl
IHNlcXVlbmNlIGxpbWl0YXRpb24gYWJvdmUgKHNlZSBhdHRhY2hlZCBwYXRjaCkuDQo+Pg0K
Pj4+IERlY2lkaW5nIHdoZXRoZXIgdG8gcmV0YWluIHRoZSBwdm9wcyBNU1IgQVBJIGlzIHRo
ZSByZXNwb25zaWJpbGl0eSBvZg0KPj4+IHRoZSB4ODYgbWFpbnRhaW5lcnMsIHdobyBhcmUg
dGhlIG9uZXMgZXhwZXJpZW5jaW5nIHRoZSBjaGFsbGVuZ2VzIG9mIA0KPj4+IG1haW50YWlu
aW5nIHRoZSBjb2RlLg0KPj4NCj4+IFdlbGwsIEknbSB0aGUgUFYgb3BzIG1haW50YWluZXIs
IHNvIGl0IGlzIGJhc2ljYWxseSBtZSB3aG8gbmVlZHMgdG8gZGVhbA0KPj4gd2l0aCB0aGlz
LiBPVE9IIEkgZG8gdW5kZXJzdGFuZCB0aGF0IGRpYWdub3NpcyBvZiBwcm9ibGVtcyB3aXRo
IFBWIG9wcyBpcw0KPj4gbW9yZSBjb21wbGljYXRlZCB0aGFuIHdpdGhvdXQuDQo+IA0KPiBJ
bmRlZWQsIHNpZ25pZmljYW50IGltcHJvdmVtZW50cyBjb250aW51ZSB0byBiZSBpbXBsZW1l
bnRlZC4NCj4gDQo+Pg0KPj4+DQo+Pj4gdGdseCBzYWlkIEBodHRwczovL2xvcmUua2VybmVs
Lm9yZy9sa21sLzg3eTFoODFodDQuZmZzQHRnbHgvOg0KPj4+DQo+Pj4gwqA+IEkgZnVuZGFt
ZW50YWx5IGhhdGUgYWRkaW5nIHRoaXMgdG8gdGhlIFBWIGluZnJhc3RydWN0dXJlLiBXZSBk
b24ndA0KPj4+IMKgPiB3YW50IG1vcmUgUFYgb3BzLCBxdWl0ZSB0aGUgY29udHJhcnkuDQo+
Pj4NCj4+PiBUaGF0IGlzIHRoZSByZWFzb24gSSB0b29rIGEgZGlmZmVyZW50IGRpcmVjdGlv
biwgaS5lLiwgcmVtb3ZpbmcgdGhlDQo+Pj4gcHZvcHMgTVNSIEFQSXMuwqAgQnV0IGlmIHlv
dXIgYXBwcm9hY2ggaXMgY2xlYW5lciwgdGhleSBtYXkgcHJlZmVyIGl0Lg0KPj4NCj4+IElu
IHRoZSBlbmQgaXQgaXNuJ3QgYWRkaW5nIGFkZGl0aW9uYWwgUFYgb3BzIGludGVyZmFjZXMu
IEl0IGlzIG1vZGlmeWluZw0KPj4gZXhpc3Rpbmcgb25lcy4NCj4+DQo+Pj4NCj4+Pj4gZGlm
ZiAtLWdpdCBhL2FyY2gveDg2L2luY2x1ZGUvYXNtL3BhcmF2aXJ0LmggYi9hcmNoL3g4Ni9p
bmNsdWRlL2FzbS8gcGFyYXZpcnQuaA0KPj4+PiBpbmRleCBhNDYzYzc0N2M3ODAuLmRmMTBi
MGU0ZjdiOCAxMDA2NDQNCj4+Pj4gLS0tIGEvYXJjaC94ODYvaW5jbHVkZS9hc20vcGFyYXZp
cnQuaA0KPj4+PiArKysgYi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9wYXJhdmlydC5oDQo+Pj4+
IEBAIC0xNzUsMjQgKzE3NSw3MiBAQCBzdGF0aWMgaW5saW5lIHZvaWQgX193cml0ZV9jcjQo
dW5zaWduZWQgbG9uZyB4KQ0KPj4+PiDCoMKgwqDCoMKgIFBWT1BfVkNBTEwxKGNwdS53cml0
ZV9jcjQsIHgpOw0KPj4+PiDCoCB9DQo+Pj4+IC1zdGF0aWMgaW5saW5lIHU2NCBwYXJhdmly
dF9yZWFkX21zcih1MzIgbXNyKQ0KPj4+PiArc3RhdGljIF9fYWx3YXlzX2lubGluZSB1NjQg
cGFyYXZpcnRfcmVhZF9tc3IodTMyIG1zcikNCj4+Pj4gwqAgew0KPj4+PiAtwqDCoMKgIHJl
dHVybiBQVk9QX0NBTEwxKHU2NCwgY3B1LnJlYWRfbXNyLCBtc3IpOw0KPj4+PiArwqDCoMKg
IEVBWF9FRFhfREVDTEFSRV9BUkdTKHZhbCwgbG93LCBoaWdoKTsNCj4+Pg0KPj4+IFRoaXMg
aXMgdW5kZXIgQ09ORklHX1BBUkFWSVJUX1hYTCwgdGh1cyBDT05GSUdfWEVOX1BWIGFuZCBD
T05GSUdfWDg2XzY0LA0KPj4+IHRoZXJlZm9yZSB3ZSBkb24ndCBuZWVkIHRvIGNvbnNpZGVy
IDMyLWJpdCBhdCBhbGwsIG5vPw0KPj4NCj4+IFJpZ2h0LiBPVE9IIHRoZSBtYWNyb3MgYXJl
IHRoZXJlLCBzbyB3aHkgbm90IHVzZSB0aGVtPw0KPj4NCj4+IEluIHRoZSBlbmQgSSdtIGZp
bmUgdG8gb3BlbiBjb2RlIHRoZSA2NC1iaXQgY2FzZSBoZXJlLg0KPj4NCj4gDQo+IEhlcmUg
aXMgYSBwYXRjaCBJIGNvb2tlZC7CoCBJIGFkZGVkIGFuIEFMVEVSTkFUSVZFKCkgaGFjayBi
ZWNhdXNlIHRoZSBuZXcgDQo+IGluc3RydWN0aW9ucyBjYW4ndCBiZSBtb3JlIHRoYW4gNiBi
eXRlcyBsb25nLsKgIEJ1dCB3aXRoIHRoZSBwYXRjaCB5b3UNCj4ganVzdCBzZW50LCBpdCBz
aG91bGRuJ3QgYmUgbmVlZGVkLg0KDQpJIGhhdmUgbWVhbndoaWxlIGRyb3BwZWQgdGhlIHBh
dGNoIGNvcHlpbmcgdGhlIG9yaWdpbmFsIGluZGlyZWN0IGNhbGwuDQoNClJlYXNvbiBpcyB0
aGF0IEknbSBzZWVpbmcgYSBwb3RlbnRpYWwgcmlzayB3aXRoIGN1cnJlbnQgYWx0ZXJuYXRp
dmUNCnBhdGNoaW5nIHdoZW4gdXNpbmcgQUxURVJOQVRJVkVfWzIzXSgpOiBkZXBlbmRpbmcg
b24gdGhlIHRlc3RlZCBmZWF0dXJlcw0KaXQgbWlnaHQgaGFwcGVuIHRoYXQgYW4gaW5zdHJ1
Y3Rpb24gc2VxdWVuY2Ugbm90IHN1aXRhYmxlIGZvciB0aGUgY3VycmVudA0KcnVudGltZSBl
bnZpcm9ubWVudCBpcyBwYXRjaGVkIGluIGFzIGFuIGludGVybWVkaWF0ZSBzdGVwLiBJbiBj
YXNlIHRoZXJlDQppcyBhbiBpbnRlcnJ1cHQgaGFwcGVuaW5nIGp1c3QgdGhlbiBBTkQgdGhl
IGhhbmRsaW5nIG9mIHRoZSBpbnRlcnJ1cHQgaXMNCnVzaW5nIHRoZSBwYXRjaCBzaXRlLCB0
aGlzIGNvdWxkIHJlc3VsdCBpbiBjcmFzaGVzIG9yIHVuZGVmaW5lZCBiZWhhdmlvci4NCg0K
SSBoYXZlIG1lYW53aGlsZSBhIHNldCBvZiAzIHBhdGNoZXMgZml4aW5nIHRoYXQgcHJvYmxl
bSBieSBtZXJnaW5nIGFsbA0KYWx0ZXJuYXRpdmUgcGF0Y2hpbmcgb2YgYSBwYXRjaCBzaXRl
IGluIHRoZSBsb2NhbCBidWZmZXIgYW5kIG9ubHkgdGhlbg0KcGF0Y2hpbmcgdGhlIGNvZGUg
YXQgdGhlIHRhcmdldCBzaXRlIHdpdGggdGhlIGZpbmFsIHJlc3VsdC4NCg0KVGhlIHNhbWUg
cHJvYmxlbSBhcmlzZXMgd2l0aCB5b3VyIGNvZGUgYmVsb3csIGJ1dCB0aGlzIHRpbWUgaXQg
aXNuJ3QNCmZpeGVkIGJ5IG15IHBhdGNoZXM6IHRoZSB0d28gQUxURVJOQVRJVkUoKSBpbnN0
YW5jZXMgaW4gdGhlIGFzbSgpIGNvbnN0cnVjdA0Kd291bGQgbmVlZCB0byBiZSBwYXRjaGVk
IGluIGEgc2luZ2xlIGF0b21pYyBvcGVyYXRpb24gdG8gYmUgY29uc2lzdGVudC4NCk90aGVy
d2lzZSB5b3UgY291bGQgZW5kIHVwIGUuZy4gb24gYmFyZSBtZXRhbCB3aXRoIHBhcmF2aXJ0
X3JlYWRfbXNyKCkNCmhhdmluZyByZXBsYWNlZCB0aGUgaW5kaXJlY3QgY2FsbCB3aXRoICJy
ZG1zciIsIGJ1dCBub3QgeWV0IGhhdmluZyBhZGRlZA0KdGhlIGNvZGUgdG8gbWVyZ2UgJXJk
eCBpbnRvICVyYXguDQoNCkknbSBqdXN0IGRvaW5nIGEgVjIgb2YgbXkgc2VyaWVzLCBidXQg
dGhpcyB0aW1lIGluY2x1ZGluZyB0aGUgYWRkaXRpb25hbA0Kc3VwcG9ydCBvZiB0aGUgbm9u
LXNlcmlhbGl6aW5nIGFuZCBpbW1lZGlhdGUgZm9ybXMuIExldHMgc2VlIGhvdyB0aGlzIHdp
bGwNCmxvb2sgbGlrZS4gSSB3aWxsIGRyb3AgdXNpbmcgdGhlIEVBWF9FRFhfKiBtYWNyb3Ms
IGJ1dCBkdWUgdG8gdGhlIHJlYXNvbg0KbWVudGlvbmVkIGFib3ZlIEkgd29uJ3Qgc3dpdGNo
IHRvIHlvdXIgdmFyaWFudCBjb21wbGV0ZWx5Lg0KDQo+IA0KPiBkaWZmIC0tZ2l0IGEvYXJj
aC94ODYvaW5jbHVkZS9hc20vcGFyYXZpcnQuaCBiL2FyY2gveDg2L2luY2x1ZGUvYXNtL3Bh
cmF2aXJ0LmgNCj4gaW5kZXggZGYxMGIwZTRmN2I4Li44MmZmYzExZDZmMWYgMTAwNjQ0DQo+
IC0tLSBhL2FyY2gveDg2L2luY2x1ZGUvYXNtL3BhcmF2aXJ0LmgNCj4gKysrIGIvYXJjaC94
ODYvaW5jbHVkZS9hc20vcGFyYXZpcnQuaA0KPiBAQCAtMTc3LDE4ICsxNzcsMjAgQEAgc3Rh
dGljIGlubGluZSB2b2lkIF9fd3JpdGVfY3I0KHVuc2lnbmVkIGxvbmcgeCkNCj4gDQo+ICDC
oHN0YXRpYyBfX2Fsd2F5c19pbmxpbmUgdTY0IHBhcmF2aXJ0X3JlYWRfbXNyKHUzMiBtc3Ip
DQo+ICDCoHsNCj4gLcKgwqDCoCBFQVhfRURYX0RFQ0xBUkVfQVJHUyh2YWwsIGxvdywgaGln
aCk7DQo+ICvCoMKgwqAgdTY0IHZhbDsNCj4gDQo+ICDCoMKgwqDCoCBQVk9QX1RFU1RfTlVM
TChjcHUucmVhZF9tc3IpOw0KPiAgwqDCoMKgwqAgYXNtIHZvbGF0aWxlKCIxOiAiQUxURVJO
QVRJVkVfMihQQVJBVklSVF9DQUxMLA0KPiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoCAicmRtc3IiLCBBTFRfTk9UX1hFTiwNCj4gIMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgQUxUX0NBTExfSU5TVFIsIEFMVF9YRU5QVl9D
QUxMKQ0KPiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIEFMVEVSTkFUSVZFKCIiLCAic2hs
ICQweDIwLCAlJXJkeDsgb3IgJSVyZHgsICUlcmF4IiwgQUxUX05PVF9YRU4pDQo+ICDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAiMjpcbiINCj4gIMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgIF9BU01fRVhUQUJMRV9UWVBFKDFiLCAyYiwgRVhfVFlQRV9SRE1TUikNCj4gLcKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA6IEVBWF9FRFhfUkVUKHZhbCwgbG93LCBoaWdoKSwg
QVNNX0NBTExfQ09OU1RSQUlOVA0KPiAtwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDogcGFy
YXZpcnRfcHRyKGNwdS5yZWFkX21zciksICJjIiAobXNyKSk7DQo+ICvCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqAgOiAiPWEiICh2YWwpLCBBU01fQ0FMTF9DT05TVFJBSU5UDQo+ICvCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqAgOiBwYXJhdmlydF9wdHIoY3B1LnJlYWRfbXNyKSwgImMi
IChtc3IpDQo+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgOiAicmR4Iik7DQo+IA0KPiAt
wqDCoMKgIHJldHVybiBFQVhfRURYX1ZBTCh2YWwsIGxvdywgaGlnaCk7DQo+ICvCoMKgwqAg
cmV0dXJuIHZhbDsNCg0KSnVlcmdlbg0K
--------------pefjOMlVvz4lJIGDtsC3KwYp
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-----

--------------pefjOMlVvz4lJIGDtsC3KwYp--

--------------5m4wyWuZsrcf0JlaWaNuLGP3--

--------------oels03X95c0cS93P70Cfnsn7
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/Ey8FAmhJfX0FAwAAAAAACgkQsN6d1ii/Ey8c
mQf7B36mN9TkpQcJ9dBTl5D4DOiwEOq9zQ3tpGoxheLmNKDbHwW+OwcExi2Seq2FB7V53ANwlzt6
P7k5amwKLMLSgWxamT4khza7F4pjIVST+ELQTFXkCzVNcHEp3705DI9ypOf/k4QAtXPyFSajwvNh
3MOCBq0UDYMAj4juYAbPOg538e0/sKe4HPZ6c6VuJF+QXIAIAUSps9TveX3FRUAxVwcX+WHqumtQ
4WK/t/R/E0FnRINSKMMvbpZ8s8uFkw/GYvog23uKO19nVNQM2BUc8cEzsllbZ1WuUp5MYhTop3ZN
Eiq9RrkVrni2qEbsV/LESJbLGIO4yG8ddomtfeZzIA==
=/WKs
-----END PGP SIGNATURE-----

--------------oels03X95c0cS93P70Cfnsn7--


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 13:02:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 13:02:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011711.1390160 (Exim 4.92)
	(envelope-from )
	id 1uPL62-0006Al-HS; Wed, 11 Jun 2025 13:02:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011711.1390160; Wed, 11 Jun 2025 13:02:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPL62-0006Ae-DE; Wed, 11 Jun 2025 13:02:26 +0000
Received: by outflank-mailman (input) for mailman id 1011711;
 Wed, 11 Jun 2025 13:02: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 1uPL60-0006AY-VA
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 13:02:24 +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 510c7af4-46c4-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 15:02:23 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3a536ecbf6fso3064290f8f.2
 for ; Wed, 11 Jun 2025 06:02:23 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-7482af3841csm9097316b3a.30.2025.06.11.06.02.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 06:02:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 510c7af4-46c4-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749646943; x=1750251743; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=L41nIti+Tlb+IzdTAmRZs4r0kBu6zBB4/SpRm2dg4T8=;
        b=GTWxnPHAFWTndE3Wq4FbEUUTw8MD5pUpnRHmhan7Y4pxZ2TrQncg6ZbJfzp+99nW1N
         wqqKjfHamrU8EUcZxNsQj9/erFlSFj90wHLkulVGcy6BYMBpsUN7Z7wmVzW2B7lIUkVv
         hBAfsaHFoiVDx9zQe4bClhYmOOiczeLCYQwlczq3kawG+GjWxPC95iregOjrksPWeiNs
         J3odFKpE2sBGLGFxGNJIQbmE7vbFkWN7esV02xfTbSRheoY3pTpku0uLsrncuGSsKb4r
         CC7P1w1vMp6sJlrbEiDzR7gs0ZqJ/41UFMGXYWZposvdEBA7cCQsCafHSrS01MHav7cZ
         3tvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749646943; x=1750251743;
        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=L41nIti+Tlb+IzdTAmRZs4r0kBu6zBB4/SpRm2dg4T8=;
        b=SDTYZOA5dQJbuLJGPs3mOutjH4qzd5An1lPpOSk2bl3it7VN1Uhi1XKo9edTfwv97I
         MV8k1YB+tt9scLQaBp7vQNnUddOZBsxwtoC/SwkIOuWVfjo/beLCM56/fvZGzIXT7TEI
         jyYSWucdPgokQhqX6WY1A3XDYe0QyoUBs12YBU5NKJrj03PInMr9f3C4Mlkt2sC7QF1j
         RwFR+leuIMWsNMr5KmIfRqf+svVflbhLM2iRcwBtB+ze5Z42TIoACN92n2mmobMl83jJ
         hoGShScsBqVchLmRrUOlvdtZyMKhpVBefutmPPn7jVmj3zNqy/PtYnYj+ZXb6C5Bk/8h
         uUuA==
X-Forwarded-Encrypted: i=1; AJvYcCVT/s0yYXpb/LO30Vjkhjbz7+8NBMixyu2n5yJPskMTDRxh/+Ab0NbuQXfjKVbsDKqy8xfiq+nI1f8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy0A9eqrPcR5luFmEcjtEs9UAPtc/Ujq1KS2IABKlkrVlh4j3i1
	zd1uQj1yB+IH7kgsSnTaBra0fS6R3euFJg7sGdF/QcHYqlXf92AiHYWhKJjkH0mcZQ==
X-Gm-Gg: ASbGncvTWFzxBIThGWdEaSWXrMgKHz959+w8+G5LdjXNSNTElts7oN86i6hyIhQI9ap
	6oLbtO6i4wycR0puQbee33sq4sMwEJGmE1VRYktLVGExGMKgzxW41B77gk4GPNUa+oNrm6PQ0lV
	UaZMXkhDB14KgO+SWUeOUYMvX7LkNGBB7CfeDREoKuxvMJuMo14bzx2P/SjOqT0Q/wNGWPvCkWM
	1QVsrmx+XbKD7+5f6i1hgKe+SQN2XnJcJ6NkvPx9x6+gjJj/jmI9c51/k8DiI7t4Vo11KVCaS1E
	m0tOXnbkUZhdgUqL0fsrZMhN8gDhBAHTlD63D/Dl2mqVm4v3eY4VVFbjm69shaCLd+sjuoi5dc7
	/HnqvUllEWga5yHnWMx3wKa4HcCHFkk1Ry4SeeMJlghLt048=
X-Google-Smtp-Source: AGHT+IHOnltg6OUBdGGtgOTcV1CKv9AAP19iVNuk+7l1jpKIo07ujaqd4vluGZQLUds8g3s89a0HyQ==
X-Received: by 2002:a5d:6101:0:b0:3a5:58a5:6a83 with SMTP id ffacd0b85a97d-3a558a56a92mr2025020f8f.13.1749646943040;
        Wed, 11 Jun 2025 06:02:23 -0700 (PDT)
Message-ID: <43725e7d-cb4c-44b7-a3e5-59d8d597c805@suse.com>
Date: Wed, 11 Jun 2025 15:02:12 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/4] xen/xsm: Add XSM_HW_PRIV
To: Jason Andryuk 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org
References: <20250610225737.469690-1-jason.andryuk@amd.com>
 <20250610225737.469690-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: <20250610225737.469690-2-jason.andryuk@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.06.2025 00:57, Jason Andryuk wrote:
> Xen includes disctinct concepts of a control domain (privileged) and a
> hardware domain, but there is only a single XSM_PRIV check.  For dom0
> this is not an issue as they are one and the same.
> 
> With hyperlaunch and its build capabilities, a non-privileged hwdom and a
> privileged control domain should be possible.  Today the hwdom fails the
> XSM_PRIV checks for hardware-related hooks which it should be allowed
> access to.
> 
> Introduce XSM_HW_PRIV, and use it to mark many of the physdev_op and
> platform_op.  The hwdom is allowed access for XSM_HW_PRIV.
> 
> Make XSM_HW_PRIV a new privilege level that is given to the hardware
> domain, but is not exclusive.  The control domain can still execute
> XSM_HW_PRIV commands.  This is a little questionable since it's unclear
> how the control domain can meaningfully execute them.  But this approach
> is chosen to maintain the increasing privileges and keep control domain
> fully privileged.

I consider this conceptually wrong. "Control" aiui refers to software
(e.g. VMs or system-wide settings), but there ought to be a (pretty?)
clear boundary between control and hardware domains, imo. As to
"pretty" - should any overlap be necessary (xms_machine_memory_map()
comes to mind), such would need handling specially then, I think. At
the same time: The more of an overlap there is, the less clear it is
why the two want/need separating in the first place.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 13:18:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 13:18:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011721.1390169 (Exim 4.92)
	(envelope-from )
	id 1uPLL7-0007uN-N3; Wed, 11 Jun 2025 13:18:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011721.1390169; Wed, 11 Jun 2025 13: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 1uPLL7-0007uG-KY; Wed, 11 Jun 2025 13:18:01 +0000
Received: by outflank-mailman (input) for mailman id 1011721;
 Wed, 11 Jun 2025 13:18: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 1uPLL6-0007uA-0r
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 13:18:00 +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 7dca2e23-46c6-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 15:17:57 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a54700a463so664030f8f.1
 for ; Wed, 11 Jun 2025 06:17:57 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-7482b083ae1sm9109663b3a.74.2025.06.11.06.17.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 06:17:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7dca2e23-46c6-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749647877; x=1750252677; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=XcFxeSfuko84GH6tSOHY91XfHiENIfUGAW0GnF0KzK4=;
        b=hAfJb+lwP7jOdU2PLu7lBkG32f6ZvUYz8ROR5nChk6a6EVoeC9KDg1z9oueBpE5fgT
         lZHRnW46EdYdLljmuGF9RHwnNfQJkiBkS6oSkeCU7cHYy30TrKHNUoSqsfr2fL91nvWn
         6B0xEjqG95DIDuaI7kdbh5oylb5JElt+8jgpqRnYyOn2UB/wZmTph+h4QlFodMpOLWay
         UB2DlQzCdy/vDXUCkmP3/tNM147FrTE1UNRmF/CTydWx6Jr5D4H/dlDwMxjAB7lD6Khh
         fhA3gSSVihAK2ooV9gP84RcDqbrJVyeQ3IKc7zOQNB4uwDeiGBlJgBn/idUGiVDIqwKk
         qFHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749647877; x=1750252677;
        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=XcFxeSfuko84GH6tSOHY91XfHiENIfUGAW0GnF0KzK4=;
        b=qG7BoSCAgXTfjwlBp6cMIhRgQyB3XkkT/OhrXkLavEFBGVgilYJAM2dBy5SV+bO3Qk
         ZZ6m3sDepEMlBZZ/RVQBI0MgIpH+u7JaDEd4u/yHNR+ssYXMNVIy9q0MY+jFk/aQuRBr
         9lAufWiSGQd+pauBZJQL9r0UDNCFi/0F0R2x4BXzlSR8BMqb4Cr2j2f1K+wOJkShxd+5
         HTpdmEdM95KcttIsDZZqHlXlzQy1Jwfoqu8QvAmWPQsxDFgxyassu6YRoi775KSTz0wN
         xTnba8SzCfEMxmdWbBoHIQ9NMZgsGh3FlDIP7FQI61ks98IjFtZTAh9UxY5vFpDiEkcX
         dwUw==
X-Forwarded-Encrypted: i=1; AJvYcCU9waOQXbBPOMAZx4/XpnNQSSkvnlUGLkRLeQkTHy4JGfdUhQmfvksSMMA39kBVO+kkFRGg8aPAGgU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxzvMDzKFa/cVyNacaz3eVDHeYr9nd5+KHvaGfZXYBNv59h3Q8I
	DeX4H0xglZMZTkasliUE/ZWJxg8XV5Ei/FdckOmGjylPidWcBjkwxE4MDzaXsZorNA==
X-Gm-Gg: ASbGncsU6gvNOf+6VtCpViPYaeepI47+6k8Bp0hZxEfLHbBXHHxr7gozu/uav3hmyLW
	vW6UkqG+uZjvp4Sn17qJAUv3u4e3gt0GFwMz7NA80FzWG1cqTZ35yI0I/Fo3y3ppLhQrJabq/r8
	SMpQzjwvt/UQOA/t/VMoxjCIyOS3nOE+6cE0EUM9fQPjN2y3SzoStHXvgbF42ajVpHhT3M03efT
	TgWoOkVUYtTvPY8SBgmvlRVuUjts4+lBsT5XcPPtZ9SvDDPUiGWT7DWIdKSzRtt3xbD16C/Vtk5
	ehrL37rXiifX9etCzFv/F9QYbGbdHFpmt6eAjY7qMxUyzZp+I9DYvE+VTSB89RXL4Oiq5Rt5PyH
	pN5vJu1J2M6NixsBjuIGEFAj0nmFZAkA7JiUfFhgFL61N3XXmRwqAuJFInQ==
X-Google-Smtp-Source: AGHT+IG5czkLSUgJWGoKUtq1nahTfBbvNSW0GYqM+DsTEw0cF701c8OJdxkpznK6KxKB/f4B7SybmQ==
X-Received: by 2002:a05:6000:430e:b0:3a4:cec5:b59c with SMTP id ffacd0b85a97d-3a55826b355mr3069867f8f.25.1749647877117;
        Wed, 11 Jun 2025 06:17:57 -0700 (PDT)
Message-ID: <0f47268e-0674-46e7-bfd4-8a395ee1ddf6@suse.com>
Date: Wed, 11 Jun 2025 15:17:50 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/4] xsm/silo: Support hwdom/control domains
To: Jason Andryuk 
Cc: "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org
References: <20250610225737.469690-1-jason.andryuk@amd.com>
 <20250610225737.469690-3-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: <20250610225737.469690-3-jason.andryuk@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.06.2025 00:57, Jason Andryuk wrote:
> In a disaggregated environment, dom0 is split into Control, Hardware,
> and Xenstore domains, along with domUs.  The is_control_domain() check
> is not sufficient to handle all these cases.  Add is_priv_domain() to
> support allowing for the various domains.
> 
> The purpose of SILO mode is to prevent domUs from interacting with each
> other.  But dom0 was allowed to communicate with domUs to provide
> services.  As the disaggregation of dom0, Control, Hardware and Xenstore
> are all service domains that need to communicate with other domains.
> 
> To provide xenstore connections, the Xenstore domain must be allowed to
> connect via grants and event channels.  Xenstore domain must also be
> allowed to connect to Control and Hardware to provide xenstore to them.

Are you suggesting that SILO at present is incompatible with a Xenstore
domain? silo_mode_dom_check() in its original form has no special
precautions, after all.

> Hardware domain will provide PV devices to domains, so it must be
> allowed to connect to domains.

As a built-in policy, isn't this already going too far? There could
conceivably be configurations with only pass-through devices in use, in
which case neither grants nor the event channels operations intercepted
by SILO would be required.

> That leaves Control.  Xenstore and Hardware would already allow access
> to Control, so it can obtain services that way.  Control should be
> "privileged", which would mean it can make the connections.  But with
> Xenstore and Hardware providing their services to domUs, there may not
> be a reason to allow Control to use grants or event channels with domUs.
> Still, Control is privileged, so it should be allowed to do something if
> it chooses.  Establishing a grant, or event channel requires action on
> both sides, so allow for the possibility.  This does open up an argo
> wildcard ring from domUs, FWIW.

Along the lines of my reply to patch 1, I think Hardware and Control
need to have a pretty strong boundary between them. It's hard to see,
for example, whether grant map/copy/transfer would indeed make sense
between the two.

Similarly I'm not convinced a strong boundary isn't also needed
between Xenstore and Hardware.

> --- a/xen/xsm/silo.c
> +++ b/xen/xsm/silo.c
> @@ -20,6 +20,12 @@
>  #define XSM_NO_WRAPPERS
>  #include 
>  
> +static bool is_priv_domain(const struct domain *d)
> +{
> +    return is_xenstore_domain(d) || is_hardware_domain(d) ||
> +           is_control_domain(d);
> +}

This construct expands to two evaluate_nospec(), which likely isn't
wanted. Some open-coding may be pretty much unavoidable here. (I'm
surprised it's not three, i.e. I find it odd that is_xenstore_domain()
doesn't also use that guard.)

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 13:24:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 13:24:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011727.1390180 (Exim 4.92)
	(envelope-from )
	id 1uPLRK-00017O-Bm; Wed, 11 Jun 2025 13:24:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011727.1390180; Wed, 11 Jun 2025 13: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 1uPLRK-00017H-9B; Wed, 11 Jun 2025 13:24:26 +0000
Received: by outflank-mailman (input) for mailman id 1011727;
 Wed, 11 Jun 2025 13:24: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 1uPLRI-00017B-NJ
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 13:24:24 +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 6324d1cf-46c7-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 15:24:22 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-43edecbfb94so81173725e9.1
 for ; Wed, 11 Jun 2025 06:24:22 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b2f5ee6f5a0sm7221753a12.21.2025.06.11.06.24.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 06:24:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6324d1cf-46c7-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749648262; x=1750253062; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=KpYhWG9RKSTcTmwrmvAe0Ss2JhdNfWMbAPQxPTkYUbo=;
        b=GwJGBURhvcDCkUuHl2nMp+o3Ra8ac+aW42m8RbxtTsUxkvy47MOOc9FPsibX5BOJHh
         /rb1IpZSrD19alZ1FLp52WkEY/l3rjzobIWTXdgD2M4e6qXXzyKhXGCortSV9vsreDYm
         EscEHWCi5CLuN07lJ2YdtJdl4dFA62De4BXpMxZtvCDBmb2OSxVt9HVQ5RmOr623Gch8
         IhB8qB/x6+nHJlMfUYCjjqcHvsjI58OPrtZjsEH6NklzGAUWodPhtDHKRg5vSm8860sD
         nXqLx+ErBjKCC4NrFFO7H802uR6TWJVDyFxqFzRcuFPmNdPH8GuyDpgg5nB6vICHYm91
         vH1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749648262; x=1750253062;
        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=KpYhWG9RKSTcTmwrmvAe0Ss2JhdNfWMbAPQxPTkYUbo=;
        b=lQcsl53Kpxbly9GLCX/kaHdKZDAdqEktSWQVeCXseL+2fKLpycfOvFnj7vXEKRkEvB
         nxyNilnkG1n8Ot4S3gGoFgkKYGPvKk90A6HltywJpToV/Ad1MxBGx/Cwy7JBSmmTug4i
         gObju9w4zPxd3zY9LYv4npxE9Wm2FgOxZrJu/Aj3A1O6HK5n92JdVw3uHEnXl+97WBR3
         N654XCqtXjYfHuc26TEpduQYxh6WzjmjGfi6cE6acy3jRbNM5BDYHpzTHRuBS7eXQjVw
         0a7vT2J5fTkhTk7ryLtaa1uhiFRg08mYDr30QcPIf7FzvNCmpEMEAP/QNeiXMrABzzno
         ecog==
X-Forwarded-Encrypted: i=1; AJvYcCUUhN61VJZAcGnPHBztrMPpYIiM5LtLDALXx2SGYFQawIqPeKHi8I/+jT9V8ATyw65cm23PXvGqXJ8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwWmVZ5BafujlN9r5hk/97HXxWmOrqxcf03zcxCSOnlIIv/4qKC
	xr/wIis/ks8LOrQaqsUC8HIQ7foIthVH8Qpno0sJwgwrBssGYlWiGGnmPjr6MY+ynw==
X-Gm-Gg: ASbGncv0HXm1u6UEr4paca86eAe0MTscx2efDtNLBHo6W1CBpUSTR5w5OaPwxqDTZ2L
	4TrAsUV47YV6/0UEVz2FFk0MX85w8oNWQIcAUR5dgG0LDaKl7ia/TeXDsJkEPKVNHR+2oOSKqts
	xYLIXYpallxd301HSGEbUKwuaaD1atEwHyPCX5W1dH1t6yBdu1oyiLuoQbLypPt/nU9bk5cT93h
	uHUx2vtU3qXGQJeMNn4ndE6PvPuI0vF0XOESn+V5MUBTXQL4b/Z644PKqGA/EW5NgpgzQJQ2r+9
	4l/mlLNDagPLtPhV/kUFeJ/Qf+t4ajpmGcDcHw9TaQh8MBXPdFfxdlHyk1FzCJuN2Ov2fsjRAJb
	9sO6bqEtWFPuSVsOMRpzMM4zQmbWIM66Ic9uxzUiyQSHkVsQ=
X-Google-Smtp-Source: AGHT+IHBMqSuRimEBzbgvVayZ3bReEEDINyesdmi93NMbjAS7Djwygfh9v0QfhA7E4totVSDOhg0Qw==
X-Received: by 2002:a05:6000:288c:b0:3a5:2fad:17af with SMTP id ffacd0b85a97d-3a558a42896mr2806900f8f.57.1749648261941;
        Wed, 11 Jun 2025 06:24:21 -0700 (PDT)
Message-ID: 
Date: Wed, 11 Jun 2025 15:24:10 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/4] xen: Add DOMAIN_CAPS_DEVICE_MODEL &
 XEN_DOMCTL_CDF_device_model
To: Jason Andryuk 
Cc: Christian Lindig ,
 David Scott , Anthony PERARD ,
 Andrew Cooper ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk ,
 "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org
References: <20250610225737.469690-1-jason.andryuk@amd.com>
 <20250610225737.469690-4-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: <20250610225737.469690-4-jason.andryuk@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.06.2025 00:57, Jason Andryuk wrote:
> To add more flexibility in system configuration add the new
> DOMAIN_CAPS_DEVICE_MODEL flag and XEN_DOMCTL_CDF_device_model.
> 
> Thie new flag corresponds to allowing XSM_DM_PRIV for the domain.  This
> will enable running device model emulators (QEMU) from the assigne
> domain for multiple target domains.
> 
> Stubdoms assign target allowing the stubdom to serve as the device
> model for a single domain.  This new flag allows the single domain to
> provide emulators for multiple guests.
> 
> The specific scenario is a disaggregated system with the hardware domain
> providing device models for muitple guest domains.

Why the hardware domain? Unless a DM also needs access to some of the
physical hardware, it ought to run in a separate domain. Conceivably
such a domain could service multiply guests, so maybe the "single
target" concept presently used for stubdom simply needed extending?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 13:27:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 13:27:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011732.1390189 (Exim 4.92)
	(envelope-from )
	id 1uPLU8-0001dp-Ow; Wed, 11 Jun 2025 13:27:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011732.1390189; Wed, 11 Jun 2025 13: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 1uPLU8-0001di-Lz; Wed, 11 Jun 2025 13:27:20 +0000
Received: by outflank-mailman (input) for mailman id 1011732;
 Wed, 11 Jun 2025 13:27: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 1uPLU6-0001da-Fc
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 13:27:18 +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 cb06ef7d-46c7-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 15:27:16 +0200 (CEST)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3a376ba6f08so3809632f8f.1
 for ; Wed, 11 Jun 2025 06:27:16 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-7482b0eb103sm9076866b3a.166.2025.06.11.06.27.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 06:27:15 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cb06ef7d-46c7-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749648436; x=1750253236; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=TXLxo3XrwtxMwBNolptB8epMRFTAs3vg/bezIDgzMu4=;
        b=IUYhNQvwgtRdYql86uCHLmLZWXzAF/6241TC9JDmoUGjQurXzbTJwh7Wj4XpP4wMXq
         n0gP0+RBtPYCSnnVUMN9dsuVcHAHnSrhhNp3YhtRaKMUE6q6MCXRl2yOBsVOaa941Unr
         PxbHAQPTQV9PVNTAn86QUKnGwrHDwlEkCCyF/6yk6LX+jkD6GtQJ3MSnvzone1Dz3Qsz
         puJl4PBEpTu8a11rl0wxlJuQR/8vRgXPiqOJvieMK2/cxdF4egL8PCIV64jFFVKv9EoZ
         XUrRtUJdFWFLRCIrXiYaFkX8++2L7Fsgy484qEtQCNvsIyTllDeL9xGcU2XsiEfYxvm6
         4ocQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749648436; x=1750253236;
        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=TXLxo3XrwtxMwBNolptB8epMRFTAs3vg/bezIDgzMu4=;
        b=a3vVmrq+a/PaVBybVfroQTt6E7g2BxQL6JpeNDoU8yUm9cDY7e/bH5okSY0a1CClRZ
         +g3ZtwYk4tT3gAGrcGe8rRaJ3fmbgrjk+KSpwzEKKDpWRZ1l4fDfjLBS84MNt9P2lOlP
         sG50LHUEW+z8WD6HRRHOl+SSw/fEhCzoZUedvbFaYnDeNBAixjk6khD0nlz3wAqpRAPD
         CLIHBSAg+tXLBH0alqANCJ0TBriGg/ndYMMbA7e25CBrb04VrFwgDZM7Y7/nfqZfAyk6
         x2JbOUxdEJl6iYA8THjhd3S8bYL2ppigE51YzzwNzsMc9PDx2m16O9N4iBfbZA3KI9bN
         BdRA==
X-Forwarded-Encrypted: i=1; AJvYcCUq/62DoFdPjtJnnL7cPD6TpqQg8oJTwOlzASkan+Qo1WNtIInpTAd4kDhSQ6hLJmSfcTg10Xf2BnY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxoykDog3JZYXGX4G/99cIRq/YAE6DdfaZdcUAcN91fcgS7f/9a
	hE9LsCf4Cxam1lsxczRznXvYs//9thm3RX/HENFvyEtsuYICblbMvzTqideoSyke8w==
X-Gm-Gg: ASbGnctX4dCaVK19VwFHyWvSE7/UqcZf/uu8wbQoSPgXei4AM+9tmeYcl3fCefQ//tU
	AySU+wn55or1CT7dbPwOPOcBtIRCQVmIW0NzsCBqAng0cESqPpvhDquTAyilo2mT+O7bkRvPKch
	6X8jOI4cQCoy0urrR29HLxpJeblffyAYsdLWXZetGJ6gU9mpaY57xFqs+TQi7NpgYxb+57N/ZHL
	2cxjx4w8SvEBwrODKHFpk2JGVxXbKzRFJcGOTEGcOXrEA4loc13KX1eHdtMlHivF4x7+uueDK2r
	NZYsJUQ0LaFGn1GrsZ44jRuYX4XFSC/r+OK7ZDdqZfz0ifnLx5JxGBioNFnoGWcbdN9K23mZS7x
	ZOEXJUMH2dlp2WpcF2ivDCng7y3NDNLu1qNAsCLy4Lmz2f4o=
X-Google-Smtp-Source: AGHT+IEBbrCzC93ctz5/x0wQ90UpACLEdUHNmCWQz4qsP1a3gZ1tmDxizmY1483TmlWPOmEXSXnDdw==
X-Received: by 2002:a05:6000:2506:b0:3a4:f5f6:b4ab with SMTP id ffacd0b85a97d-3a558a3257emr2373135f8f.30.1749648436335;
        Wed, 11 Jun 2025 06:27:16 -0700 (PDT)
Message-ID: <5f6d43da-2600-4c1c-9bcb-f13e8fce921e@suse.com>
Date: Wed, 11 Jun 2025 15:27:06 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 4/4] xsm/dummy: Allow hwdom SYSCTL_readconsole/physinfo
To: Jason Andryuk 
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: <20250610225737.469690-1-jason.andryuk@amd.com>
 <20250610225737.469690-5-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: <20250610225737.469690-5-jason.andryuk@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.06.2025 00:57, Jason Andryuk wrote:
> Allow the hwdom to access the console, and to access physical
> information about the system.
> 
> xenconsoled can read Xen's dmesg.  If it's in hwdom, then that
> permission would be required.

Why would xenconsoled run in the hardware domain? It's purely a software
construct, isn't it? As a daemon, putting it in the control domain may
make sense. Otherwise it probably ought to go in a service domain.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 13:28:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 13:28:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011741.1390200 (Exim 4.92)
	(envelope-from )
	id 1uPLVI-0002Cb-4l; Wed, 11 Jun 2025 13:28:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011741.1390200; Wed, 11 Jun 2025 13:28:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPLVI-0002CU-29; Wed, 11 Jun 2025 13:28:32 +0000
Received: by outflank-mailman (input) for mailman id 1011741;
 Wed, 11 Jun 2025 13: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 1uPLVG-0002CM-Mj
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 13:28:30 +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 f67fa17c-46c7-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 15:28:29 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a361b8a664so5411024f8f.3
 for ; Wed, 11 Jun 2025 06:28:29 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23603092640sm86888965ad.54.2025.06.11.06.28.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 06:28:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f67fa17c-46c7-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749648509; x=1750253309; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ZOHZkRc3ctKyMzq6MqCk9YchYthx0RwS7YGyu+lEHGw=;
        b=MebklG83iwTOX5ltY8YqMNvAsRcjXs3LpUTfz1QSvfFFGv7Tzoj0Bo1XUa78UikW0w
         k81lw3pmaWz9/XMUUDage0ScleIPObXHwuMSurLK4v3P98KjFCEfBrM4Y+0JBMYxdOCD
         wqdsYjnqmDYhfXWemDq81LO3/5/bKaBqQ+N67vZJv/nHN65fzFCafz5CwDV+Nzvqiduh
         IG9zSFO6B/NOpYUkC0Jadj7De+S1xRwZLdqkGfwAWJiTn3Lcxl4xfxHhz7+8ZIGjpFpu
         sPIueHxYEgOCVgEo/n56frolSlXaP/hLF4Qj2CYfVKEygQaHGxQ7moKiIaNuAIqCiQOe
         OFYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749648509; x=1750253309;
        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=ZOHZkRc3ctKyMzq6MqCk9YchYthx0RwS7YGyu+lEHGw=;
        b=KUmsEKmGj96FNvfJ8PIIQk4w0GOW3K6zpYy0qQflKKdcw+kxFzVyyZBVFh7q9/eVjO
         FImBmVZZ0IhOTlIcBxhq8UJbiS/B1purE4ukD/G/8VoexqHnL6CXjrRO9L4XKaw93su/
         t5fhfuMMe5ULZBgj7W9oyDXJfyXritjs0ru5uxDYWaiPzaDYBp+K8GJBUr8Db1OyNifD
         e1rQ1ITeNLKAR+eYZAKef1rst5f8xHWRXqGMW4SeXJhW91vo4iwyIozmSNBY0u4nijWm
         QKDVexjB/k/B6GpoUapqu/hFq+eRRhZfLMMAM6kcOtutmhhtWwq6eWtVLp+kzCqHwsxl
         psOQ==
X-Forwarded-Encrypted: i=1; AJvYcCUeWCe9ny3TRSrgNVwlhn3o5T+F+l6pHkLfKcMmWD5mn7bQvlCqF9jObOHQw78dk8tfwBvz3ZgKYDM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwPUvNbEfG0UfaJDIaoU3ZiY7FbwpiysfASPaGQzgEIr6BSBEB2
	b1Wemkyeo1kZF49TfzfWYNRViWOmIQtpaoLeuQI+I8G/9cUTbc0vu9TLpt5b+KPLzw==
X-Gm-Gg: ASbGncsYOSit824qy7cmVjVY05wpOehrygK8iqSj7JYQFmEVbfXqZrssFa+Tn2rIQTh
	9ULakq9rQe6ErL7LkTxLZn4xXR5qpa1JEASrscyNDWzkmL73oy6bAPnBX5WPqozeSR6Vq2lHLSq
	gweHCupqaqe0cfEy0qLbpsHXsqbfcX8HduQ769dCq7HNxCEZpPtmzNrj/RasVMfi/rvAwz+bYV2
	wuVgFIsfMFFaioJ9JeZux4lc1qB6OFDrgIUmXzl6SxoDlHrvdYi1CrImMmmlIPPml0gGgStkSIM
	/PtRXhSOpzqnHhWIdPREHmMZrCtyjWfIlsdf4g2p96xz0HBwG8ExzlSbYJ/Twzjev7yfij/li99
	wndwHJeGxw5g5AYu/zPXnBaLmkyrOudDXojjgT7tTkZR8vWY=
X-Google-Smtp-Source: AGHT+IG19wenMLI2OnajzGoCcP+u52UE3vvR5JGrjB1w0/KPS8sbeOLGR2AXeBrReiZsgnxuMPYAdg==
X-Received: by 2002:a05:6000:4020:b0:3a4:f513:7f03 with SMTP id ffacd0b85a97d-3a558a3128cmr2940604f8f.44.1749648509242;
        Wed, 11 Jun 2025 06:28:29 -0700 (PDT)
Message-ID: <0defc4e7-382b-4651-8255-652da17a2129@suse.com>
Date: Wed, 11 Jun 2025 15:28:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/4] XSM changes for split hardware / control domain
To: Jason Andryuk 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "Daniel P. Smith" ,
 Christian Lindig , David Scott
 , xen-devel@lists.xenproject.org
References: <20250610225737.469690-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: <20250610225737.469690-1-jason.andryuk@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.06.2025 00:57, Jason Andryuk wrote:
> Theses are the broad changes needed for a split hardware / control
> domain.
> 
> An earlier posting gave device_model privileges to hardware domain.  For
> this posting, it was split out into a new capability.  This way the
> operator can choose where to run the device models without making the
> hardware domain have the permissions.
> 
> The first patch add XSM_HW_PRIV for the hardware hypercalls.  Unlike the
> first posting, the control domain can call these hypercalls even though
> it doesn't really make sense.  The idea was to keep the control domain
> all powerful from an XSM perspective.
> 
> SILO is changed to allow control, hardwware or xenstore to service
> domUs.  Xenstore and hardware will use grants for PV interfaces.
> Control wouldn't typically provide PV interfaces to domUs, but it is
> given the permision to do so.  Again, to keep control all powerful.
> 
> xsm/dummy: Allow hwdom SYSCTL_readconsole/physinfo this is not strictly
> needed.  xenconsoled could read Xen's dmesg.  If it's in hwdom, then
> that permission would be required.  SYSCTL_physinfo is mainly to silence
> xl messages, which are mostly cosmetic.
> 
> Jason Andryuk (4):
>   xen/xsm: Add XSM_HW_PRIV
>   xsm/silo: Support hwdom/control domains
>   xen: Add DOMAIN_CAPS_DEVICE_MODEL & XEN_DOMCTL_CDF_device_model
>   xsm/dummy: Allow hwdom SYSCTL_readconsole/physinfo

Overall I can't help the impression that this level of disaggregation simply
requires the use of Flask.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 13:36:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 13:36:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011747.1390210 (Exim 4.92)
	(envelope-from )
	id 1uPLcg-0003w3-SM; Wed, 11 Jun 2025 13:36:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011747.1390210; Wed, 11 Jun 2025 13: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 1uPLcg-0003vw-OO; Wed, 11 Jun 2025 13:36:10 +0000
Received: by outflank-mailman (input) for mailman id 1011747;
 Wed, 11 Jun 2025 13: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 1uPLcf-0003vq-Dc
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 13:36:09 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 06964363-46c9-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 15:36:06 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-450ce3a2dd5so59555055e9.3
 for ; Wed, 11 Jun 2025 06:36:06 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23603d14206sm87391795ad.34.2025.06.11.06.35.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 06:36:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 06964363-46c9-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749648966; x=1750253766; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Rkuojl8eYF1ouZRGYRiishF0d8bI4Jee9szhrB+GhPw=;
        b=chX6zJOamrqVv9l8LhZFGjNVk9KktWQoH1NL52wlA6sLbS38u+uWp9ZY3UIduF95+i
         4CwzOvAblpHnf1KG5IxSS9wX53zomoyveNcKJXMAVFpYJRv3EpPrEg82lOgWUjyRWUCN
         OvPfDX95JFpXMXVqoEoOlIp19xqcGvzojpZl3yCYw+BQw3IlcTmJKdBxHjhHrxR3T2Zn
         LRO53uZXTFPxhQWUconR6R3RwkOhg+h0s8y1aobQEk5HJQZdpsPLdE2hvkI855p9LfQw
         AMaOLy6j9yE2qGTrxuAPOhmfb7gLMatFpd9EsX21iNUoVKy1RVSeZ1zYcvmUw55UELge
         2SQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749648966; x=1750253766;
        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=Rkuojl8eYF1ouZRGYRiishF0d8bI4Jee9szhrB+GhPw=;
        b=hL5TxDQjugVDLK+zk1NrKJbTrbqgf3FxHr2Iu4M/OMF4m1elZGOjXs/2SejaoQoCZ8
         aUXszc9IIB+KNniVzDA53QG7zVlYE87cyBbt66ZMuVQfaFyTHgGMMf67I/isBN5mAMnS
         Q/8U3mhy/4/apwdxFSHQzjrucMY31kLwuMKDSVwTnCIrr1OwjlcCuPDcMCe9/EH1I+8J
         SzI5sMWFi8O9Y+wAqOZZEJuzZOdLBJ3Bs3ty++f6e3YuD2m46fw5r7KvtI8pa+z7D2yr
         IBI8+7sPG0J/hzXMs0oFces0Qve1mfkL9HeLBj8eh4aO9sDqfid9e/PloiuXdDuaK2a0
         e6EA==
X-Forwarded-Encrypted: i=1; AJvYcCVKwk+IltjfgWrj09RinSraMD2ElAOxgbMUk7hka0f/PFa43Hq99A3SxRSdjb3D2kFQN7qAdS0WGic=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywl8UlPnxC8uBx+UHm0yaKG959QWTBgA1XLazwsVntLSRCB9hU8
	jLCCY3tm98QVF7OelMbeRN7TtBSwpBtCnS1x2UaJiYR0gzvi3xvp9f9pHWGE4K9B3A==
X-Gm-Gg: ASbGnctXIMhENPQoneWn4CggTLkuDFhOs8MbM1KBTr740SBIgE0fsYe3dPeCPSr8R5c
	i/fc3t1c8czqGxHieHd0mz/xGPSY48eJL/TP9RlSdyqC1OxXoh53QIOemSDEXPOoqgi3j5rPbxj
	1pAK2ssEaPzzSC0KkJqP1IxxavgUAcIwtF1QiiSxkYMa9kwobVDSQVY//4ZEMyv9C2bubct0MrZ
	RYDyocOHDthv26OJqYpVbNvZCwPkakCfaSzrP2GJtlUIR9+DmvfWFUsUDd4VnRVqfS6L9dZ3R0A
	Uk3lujFr6Jl1iqjy0hGZRhsXo0eFqeiWaCyNLy/TZD7TOo/xSMh+NgdY0ZOoPMjNsqpTnhJcYNa
	qT6Xg9RI5cdNrW6doIo5DvuRnK9VsNZzlTgH0lZX6gNK1hIY=
X-Google-Smtp-Source: AGHT+IFLELa0I+JYgdF5kXyfkdmIhtJKoNRHLCZa6kcWFGppK0UDY5BFl/+m+b5n8iTIEhvjlcP1Yg==
X-Received: by 2002:a05:6000:430c:b0:3a4:ef00:a78c with SMTP id ffacd0b85a97d-3a558a4296amr2428793f8f.55.1749648965690;
        Wed, 11 Jun 2025 06:36:05 -0700 (PDT)
Message-ID: <4352622c-f33a-405e-98c0-cad8f6b4f4f5@suse.com>
Date: Wed, 11 Jun 2025 15:35:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 03/11] xen/page_alloc: Add static per-node counts of free
 pages
To: Alejandro Vallejo 
Cc: Bernhard Kaindl ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250314172502.53498-1-alejandro.vallejo@cloud.com>
 <20250314172502.53498-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: <20250314172502.53498-4-alejandro.vallejo@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.03.2025 18:24, Alejandro Vallejo wrote:
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -485,6 +485,9 @@ static unsigned long node_need_scrub[MAX_NUMNODES];
>  static unsigned long *avail[MAX_NUMNODES];
>  static long total_avail_pages;
>  
> +/* Per-node counts of free pages */
> +static unsigned long pernode_avail_pages[MAX_NUMNODES];

Performance-wise I find concerning any addition of yet another array like
this one, which - unlike e.g. avail[] - is randomly written from all nodes.
I think we either need to introduce per_node() paralleling per_cpu(), or
(less desirable, but perhaps easier to carry out) data structures need to
be introduced to make sure one particular cache line would only ever be
written from a single node. As it's visible from patch context:
node_need_scrub[] could/should move there, too, for example.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 13:43:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 13:43:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011752.1390219 (Exim 4.92)
	(envelope-from )
	id 1uPLjf-0005iM-Hk; Wed, 11 Jun 2025 13:43:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011752.1390219; Wed, 11 Jun 2025 13: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 1uPLjf-0005iF-FD; Wed, 11 Jun 2025 13:43:23 +0000
Received: by outflank-mailman (input) for mailman id 1011752;
 Wed, 11 Jun 2025 13:43: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 1uPLje-0005i7-5F
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 13:43:22 +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 09ab2243-46ca-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 15:43:20 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3a525eee2e3so5069052f8f.2
 for ; Wed, 11 Jun 2025 06:43:20 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2360340511bsm87632865ad.151.2025.06.11.06.43.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 06:43:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 09ab2243-46ca-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749649400; x=1750254200; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=lIlw7TTTlgpwJKtxaMWIeoHSH2fi1PnxZXuPFmmoc24=;
        b=G4tVtbBjLJhk7p7u4iHipY1iO9iSs+nFPapRw+0V2hyY5gvG2lzoe3MJYf1L48sB9C
         eEcTHPtKG90TKM/9fdjDeNeHgbwZsXl9yllSNxri4SMteqDeoKN9LhnbgsAt9RmsjJcI
         oyu/A5O+mFO+E5DZIKfHFS5WKiQCIjzBkzhavFou6bADnJd4HrcW/Zl/T1m4BhPd0OoV
         4L7wRShDBUtF5HjnnXoiaaFJtAim6+cEPbvvhWvYFntE2gSWWP8VjpYFs41yqCBkB2Ub
         jZod56cNxdgZ40vp371QPqmaJNJN9e9AlIBmNbvpXj3P2MtyA5p5oaBFP1CVjNr+A1jt
         n+2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749649400; x=1750254200;
        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=lIlw7TTTlgpwJKtxaMWIeoHSH2fi1PnxZXuPFmmoc24=;
        b=BkC64sxofJM43q0Ub8WCBBXyVSFoAYqFFJh6i6TOGAzz+OWB6BUtCPDnAEfIiDq9jO
         fKR06dOX8LpW/46Ag+77lU+5cMU2Xz341xagPOjKZq1gpMfJLs2tXFk/3QzvcvdmIC/h
         UbolRwRDWqkwrgziBe4l9jJuxv1O2ZeC5W0R/Ir/9N8628vOK+C545QF6RyBfre+F2qL
         pTau61N04GhzfCqJsgg9XXX/BgrORQgfsev5nHWcLX3+KTdr/x5BQeVrbP8HOkgdzsK7
         7zJsCTYhz2k+7pa+XR2ujo5Pl1E4iLpcQgZ6RHkMC6I/gxMo0B/nTRlPZaLJ4+ZsHq8h
         YVUw==
X-Forwarded-Encrypted: i=1; AJvYcCWvNQCEztH4J8j7tcKIK/vaF6nWLpeuzVPDE55f9lsoiKcTrO+XUcoYoNqONvYWBsz0Y2bS/iwaqUk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyiX56wC84XW7uiw4Lvx6gukTZKC8u65Zf+NVZLD2ac+zgRdkES
	JfY90fwLRvnD15zb/sltXv/HaVL00pxnawIcFUCk+g9Ih2tmfaecVfuPhJ2F3sHTkw==
X-Gm-Gg: ASbGncuo8ATV2PBzXfGFDdY2RCizdp5+HXMMzC3E/h/pDyjfBftTAY1FW0Y0tdblmia
	rxvLrcfgI4Ri1DjrLqa8h5XcaAN/UJvr5VTMWk1W5gC550NuogWMNV8W/+d+akS/oF7VMK8jy8a
	MqcNM4jPaNBCFig4i1D3XTioHxdu/FjabTOAEsVQw/6I/AdtPGZ9dEXglSp8wy+FKLoyfkl6+MT
	itm0Pi8WdRbagys8NSsR67fnalWz2cjhIp7bXR9GQuXSCTsQVb0HfgBQIXDnsOS4z9HI0abANY5
	xto2uvos3EZALK69uVvZibuTRbPxzZcWHQIxCcOuifwl0m93ZgCUVJFQz61ZY3NkAfUyjl+tkPq
	2RGJWK8NcgFNwmdV0pPkdhtyXOy5kbnZDtlB4PV48TIZrCu8=
X-Google-Smtp-Source: AGHT+IE4FqPtkFu5cGDmbTxtODkIQIl1TcfmB7iY/9xlteRJ4SYHkx//3gjbqsEpAQsIpMe6jwrEww==
X-Received: by 2002:a05:6000:1acd:b0:3a4:f63b:4bfc with SMTP id ffacd0b85a97d-3a558acbc72mr2113096f8f.34.1749649400368;
        Wed, 11 Jun 2025 06:43:20 -0700 (PDT)
Message-ID: 
Date: Wed, 11 Jun 2025 15:43:10 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 04/11] xen: Add node argument to
 domain_{adjust_tot_pages,set_outstanding_pages}()
To: Alejandro Vallejo 
Cc: Bernhard Kaindl ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini ,
 Tamas K Lengyel , xen-devel@lists.xenproject.org
References: <20250314172502.53498-1-alejandro.vallejo@cloud.com>
 <20250314172502.53498-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: <20250314172502.53498-5-alejandro.vallejo@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.03.2025 18:24, Alejandro Vallejo wrote:
> domain_adjust_tot_pages() decreases the outstanding claims of a domain
> as pages are allocated, so that'll need to take into account the node in
> which an allocation is done. Deallocations just pass NUMA_NO_NODE.
> 
> domain_set_outstanding_pages() takes the node on which to to stake an
> exact-node claim, or NUMA_NO_NODE if it's a non-exact claim.

This doesn't fit the code, where you make both callers pass NUMA_NO_NODE.
With that it's hard to see why ...

> Not a functional change, as neither function uses the arguments for
> anything yet. It's a prerequisite to simplify for the following patch
> that introduces per-node claim counts.

... this part of the change would simplify further changes: Any actual
use of the parameter would be meaningless as long as no caller passes a
valid node ID. IOW it looks to me as if this part of the change wants
moving elsewhere.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 13:50:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 13:50:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011771.1390285 (Exim 4.92)
	(envelope-from )
	id 1uPLq9-0007g1-On; Wed, 11 Jun 2025 13:50:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011771.1390285; Wed, 11 Jun 2025 13:50: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 1uPLq9-0007fW-M9; Wed, 11 Jun 2025 13:50:05 +0000
Received: by outflank-mailman (input) for mailman id 1011771;
 Wed, 11 Jun 2025 13:50: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 1uPLq8-0007Pv-Lr
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 13:50:04 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20618.outbound.protection.outlook.com
 [2a01:111:f403:200a::618])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f62387f4-46ca-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 15:49:59 +0200 (CEST)
Received: from SN7PR04CA0025.namprd04.prod.outlook.com (2603:10b6:806:f2::30)
 by CY8PR12MB7340.namprd12.prod.outlook.com (2603:10b6:930:50::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.34; Wed, 11 Jun
 2025 13:49:53 +0000
Received: from SN1PEPF0002636D.namprd02.prod.outlook.com
 (2603:10b6:806:f2:cafe::3c) by SN7PR04CA0025.outlook.office365.com
 (2603:10b6:806:f2::30) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.35 via Frontend Transport; Wed,
 11 Jun 2025 13:49:53 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SN1PEPF0002636D.mail.protection.outlook.com (10.167.241.138) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Wed, 11 Jun 2025 13:49:52 +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; Wed, 11 Jun
 2025 08:49:52 -0500
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 Jun
 2025 08:49:51 -0500
Received: from [172.26.5.4] (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 Jun 2025 08:49:51 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f62387f4-46ca-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=UuR8gPZdB0hXgGvmicLylt4tfwIXsTqlkVX9sz8ECUdEMw/sgb14zy5cS2DgmKw3ZqZhSk4LxeLXOIB3laZiE959F77EzFhWANwJX1HnYeHCMwn9FTevvW6/e39314Teh7g3vmvlEB0Iw4ge5loN86q9NTbEukNzcIauPIBkQBRTJC0Z2zCrvflAm9rSIJnLMNdizfNDxNJvVfrJnM7jtPksGFaTONbOZRuijnd6ndI0doHrmZGjyX/a+WZMHXt4mPYys0CzQMSIvZ5IE/+reh5AL541oqskA0s7f8AW9pnhI9HaxQXgVk4Uz5bSwSR6kbh1Nb7PzztoVVje0mZKkQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=t9m6AtpTqgsU8kmX/B/6Qk+1bXS1ntxwE7nqu5cdQGU=;
 b=oT5kIPdGo9wIumE3dEQpVWb/K8BUxYloCTZ8JLpR3pftbzmBTYtTmmFVoorPXZGKHTggQQIxamK/t7pV1+L0bGl6HyQ8Qv4pxiz1frugmEOBDi8aIakKnsACskugKvsgddPWwV8AdeEMNMma2hGTlAi9HNWFMHa2AiIdDj3csBOqwPvLnZ8qS2zbDi/laVcu6DEWUoHkhTCfzFHOcUIlVcgCQCW9EeY+oskFBLxjxHBRD0GWVlWHscIPjHFSsBb13d2yB22pfYkuGVEFAcDr2O65t7yXoBXKxprc8EZOQmmJvlBV55awTJGMaaPMH2nfxucWY4yCFrmpFnWiQ+TrdA==
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=t9m6AtpTqgsU8kmX/B/6Qk+1bXS1ntxwE7nqu5cdQGU=;
 b=Im8DT8h9zo2T2qMMmBhxAKjRgfr9GWjMHPcmDabGcmn268CREa9Hc5oArXiMJCC7wGfRHDzFHHE1K634YKwZ9FTQTRhgF9qVxEuk1sreF4p6oqFe55R40zBwtoNnfY1UYSkzlRN5CNjE67Pk5diFSJLk1+mHW+NRYaLxUNRAqvw=
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: <3ea5fec5-0083-4c83-9430-229550911b6b@amd.com>
Date: Wed, 11 Jun 2025 09:49:50 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 1/2] xen/arm: exclude xen,reg from direct-map domU
 extended regions
To: "Orzel, Michal" , 
CC: Stefano Stabellini , Julien Grall
	, Bertrand Marquis , "Volodymyr
 Babchuk" 
References: <20250609183438.178214-1-stewart.hildebrand@amd.com>
 <20250609183438.178214-2-stewart.hildebrand@amd.com>
 <6a52ad54-cac8-43fc-b396-87b0ac01d1dc@amd.com>
Content-Language: en-US
From: Stewart Hildebrand 
In-Reply-To: <6a52ad54-cac8-43fc-b396-87b0ac01d1dc@amd.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB05.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF0002636D:EE_|CY8PR12MB7340:EE_
X-MS-Office365-Filtering-Correlation-Id: 3e807388-65a9-4db0-b5bc-08dda8eed785
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?R2c5VmZSNWtsMVBPdERLTElyZU5DdGZsZ3VxNjBIdU1rVnloZFRWcUFXaTNU?=
 =?utf-8?B?OWk5Y1FHZFlxRHJ3U2tuTmQxaHFHUnhLOERRQ2loNlFJMXdQb3A1ZGo4K1Ru?=
 =?utf-8?B?WjFHNEI3TDRxdjBLUGQ5WW1xbG1tTHFSTHY3TGdJblJXODBWTk5JUTQxcmhX?=
 =?utf-8?B?SjlINlpWNHN3Ukl5UHlKbnJiM1FNbDlwVUZuVkU5YXNHMks2QWlycHQ4Rzg5?=
 =?utf-8?B?RWM5N1p2VUhpVUR5ZkhTUUtDY0QxYVRkMHAxVkNzRG9jVHd5bHA3aC9oYU91?=
 =?utf-8?B?WHJLN3hwWXYveWdKcVhlVzFLRVRCZk1VOHUxMm1TcS9tYnN4VCtOSGt6Ri9p?=
 =?utf-8?B?NmkwN1FyM21yTTNGb3Q0SW92akNuM0lvSWIzZG9pWW85VUxEcCtBM014TDFM?=
 =?utf-8?B?UFJwdzdQTFZkOG9KZXBmSmcyV1lQc3BqaEdDWUx3bkJwTjU0eVplTlZjK0xW?=
 =?utf-8?B?Mjl3Y0pCaGpsY1JNUTRNbVJJR3RnMTB6bllXWjdBUG5KVloxdjVEMjA1SzBv?=
 =?utf-8?B?OGV2UGtlVTRtQXZnYncwd280c1J2VEJ5VnVCOVVmWnkxSC9OdEtwSExsOVA4?=
 =?utf-8?B?dlZiMFdXczhqRVM3cDJlWHNIMDVwelZHanFPVzg1ekN5NXhkbWJCTGlTUVYx?=
 =?utf-8?B?VW9uSUtBUUlDWG1MbHFIR0N3d2lRTUhVZ1FVeGtsVlNTeWI0Ym9aWjNmV3hs?=
 =?utf-8?B?ZGhMcCtCejg4aStwVnJZR2YxWDNvajVzbzNtWkZKeEpUS0h5WnFlZEJqQ2xY?=
 =?utf-8?B?ZHhYT0p6Q1R6cjJDcWt0SGVkRUh4am54SDFsTldUN3lydG4zTzdvQ0dSeENq?=
 =?utf-8?B?VnpaSkZ0bDdRU2NkeGRLM01NQ1lqaDZmWU1HZXVPUG5vOVFTT2MraVJUeU9K?=
 =?utf-8?B?NEhtNDhybEJwRWF3MWJCTDEzMWJ6TnMzQVdRYWV2UEhQT0dLZnpKOGZ5enNx?=
 =?utf-8?B?SmQ0d2lVZVZIMitYSUs1M0tML3VRVVdCTlp5RWlXWWd3ek16V210UVZ6UXZV?=
 =?utf-8?B?SWUxTFEyNm1iTllDL0hVbDRlR0M0dWpXb1pNOHNrT3ZaUWlybDdQcFQwNHRp?=
 =?utf-8?B?SW82cm9Gb0plZ0ZKam9HSk82NHVyNEJUM0tteWVRRXdnb05Zc09HVnhDMTg4?=
 =?utf-8?B?Q2YyWkpJT3VrU1F4S0xqWmNFVncreGpYZDBhUjNWajRkcTdOallMSTRsWHNX?=
 =?utf-8?B?ZTlNSzlXMGZoa2FiYWpWNDdYSmlLcndmYytRYjZvMHB0ek9CdXdpK2d3c3Np?=
 =?utf-8?B?K1VQTXVMWGNjMkNocUpYNVBlWGNOaVFsZ004Zk1KUHg3cDljd0FpeDRtVWFX?=
 =?utf-8?B?UFMwME90RnVPVlpYUXNmU1RKazI1aHVMazZKTTI1ME4wNG9wbGo0alVrbEdO?=
 =?utf-8?B?OU40VjM2RER5eGNBbDRUZWoxczQyNmZNT0hJb1orZXRINHFaZUR4Sm8vdlRP?=
 =?utf-8?B?ZGN3Y3FJZ3VqUmVySTFtK3dPMVVJRVN3eFNmSlI5NzZBNnVBcGt0YnltR2hu?=
 =?utf-8?B?YUJoUE1MbWI3VE5xTnRFeWpsdEcrOEtVeTB1T2oyQnBvUVhkUVIxOHArV3Vx?=
 =?utf-8?B?cGxNMTg5bnRHQjBwYjJlN050aTN3dkVBbVZTaVp6U3ZlSll0c3F2VGpnTUM1?=
 =?utf-8?B?c1BGdDJGOE0xOUUxM1VHcUFxVjZ5VW5odmIwS0tLVUhTSE1vZzZpd0xST0tn?=
 =?utf-8?B?bS9UbmhMK2xmMVJEZ3d6NDlOYVhiQmhOKzE2ZnJXUFdqNm81cDlieHBRSXNk?=
 =?utf-8?B?NHFoKzhOR0NlOFNpZk1reHFkLzBxN3JXdHp5Z3NUalhFQVJ3VmFQTzJqQzhS?=
 =?utf-8?B?blFXM0lzRVdRcncvRTNvVWswN0pjMkhFWk9VT3BpeVlUOXFDZU5nVGsyZWJ1?=
 =?utf-8?B?SVlZKzRRbEgwSjNrVzZTdFdUbXNldVU1dXFkSXRQWHR1dnFVeUN0dFBVY2Jo?=
 =?utf-8?B?WUc0OVorNXpMbGw0RlZmRmw2dnBBODRPbmo2TzVaSzBMeDB2aG9mY2pnWmZw?=
 =?utf-8?B?SFc1RU1GSFBuSUNpVW1PNmc3aGtmU1QwSnNhWVpKY3dTdkFQcXo2aFdPSGhn?=
 =?utf-8?Q?u+BpYR?=
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: 11 Jun 2025 13:49:52.7302
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3e807388-65a9-4db0-b5bc-08dda8eed785
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:
	SN1PEPF0002636D.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7340

On 6/10/25 03:27, Orzel, Michal wrote:
> On 09/06/2025 20:34, Stewart Hildebrand wrote:
>> Similarly to fba1b0974dd8, when a device is passed through to a
>> direct-map dom0less domU, the xen,reg ranges may overlap with the
>> extended regions. Remove xen,reg from direct-map domU extended regions.
>>
>> Take the opportunity to update the comment ahead of find_memory_holes().
>>
>> Signed-off-by: Stewart Hildebrand 
>> ---
>> v3->v4:
>> * conditionally allocate xen_reg
>> * use rangeset_report_ranges()
>> * make find_unallocated_memory() cope with NULL entry
>>
>> v2->v3:
>> * new patch
>> ---
>>  xen/arch/arm/domain_build.c           | 77 +++++++++++++++++++++++++--
>>  xen/common/device-tree/domain-build.c |  5 ++
>>  2 files changed, 77 insertions(+), 5 deletions(-)
>>
>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> index 590f38e52053..6632191cf602 100644
>> --- a/xen/arch/arm/domain_build.c
>> +++ b/xen/arch/arm/domain_build.c
>> @@ -792,15 +792,17 @@ static int __init handle_pci_range(const struct dt_device_node *dev,
>>  }
>>  
>>  /*
>> - * Find the holes in the Host DT which can be exposed to Dom0 as extended
>> - * regions for the special memory mappings. In order to calculate regions
>> - * we exclude every addressable memory region described by "reg" and "ranges"
>> - * properties from the maximum possible addressable physical memory range:
>> + * Find the holes in the Host DT which can be exposed to Dom0 or a direct-map
>> + * domU as extended regions for the special memory mappings. In order to
>> + * calculate regions we exclude every addressable memory region described by
>> + * "reg" and "ranges" properties from the maximum possible addressable physical
>> + * memory range:
>>   * - MMIO
>>   * - Host RAM
>>   * - PCI aperture
>>   * - Static shared memory regions, which are described by special property
>>   *   "xen,shared-mem"
>> + * - xen,reg mappings
>>   */
>>  static int __init find_memory_holes(const struct kernel_info *kinfo,
>>                                      struct membanks *ext_regions)
>> @@ -882,6 +884,13 @@ static int __init find_memory_holes(const struct kernel_info *kinfo,
>>          }
>>      }
>>  
>> +    if ( kinfo->xen_reg_assigned )
>> +    {
>> +        res = rangeset_subtract(mem_holes, kinfo->xen_reg_assigned);
>> +        if ( res )
>> +            goto out;
>> +    }
>> +
>>      start = 0;
>>      end = (1ULL << p2m_ipa_bits) - 1;
>>      res = rangeset_report_ranges(mem_holes, PFN_DOWN(start), PFN_DOWN(end),
>> @@ -962,11 +971,48 @@ static int __init find_domU_holes(const struct kernel_info *kinfo,
>>      return res;
>>  }
>>  
>> +static int __init count(unsigned long s, unsigned long e, void *data)
>> +{
>> +    unsigned int *cnt = data;
>> +
>> +    (*cnt)++;
>> +
>> +    return 0;
>> +}
>> +
>> +static int __init rangeset_to_membank(unsigned long s_gfn, unsigned long e_gfn,
>> +                                      void *data)
>> +{
>> +    struct membanks *membank = data;
>> +    paddr_t s = pfn_to_paddr(s_gfn);
>> +    paddr_t e = pfn_to_paddr(e_gfn + 1) - 1;
> Why do you subtract 1 here if ...
> 
>> +
>> +    if ( membank->nr_banks >= membank->max_banks )
>> +        return 0;
>> +
>> +    membank->bank[membank->nr_banks].start = s;
>> +    membank->bank[membank->nr_banks].size = e - s + 1;
> you add it again here.

To be consistent with add_ext_regions() and add_hwdom_free_regions(),
but I suppose there's no need for that. I'll drop the extraneous -1 and
+1.

>> +    membank->nr_banks++;
>> +
>> +    return 0;
>> +}
>> +
>>  static int __init find_host_extended_regions(const struct kernel_info *kinfo,
>>                                               struct membanks *ext_regions)
>>  {
>>      int res;
>>      struct membanks *gnttab = membanks_xzalloc(1, MEMORY);
>> +    struct membanks *xen_reg =
>> +        kinfo->xen_reg_assigned
>> +        ? ({
>> +            unsigned int xen_reg_cnt = 0;
>> +
>> +            rangeset_report_ranges(kinfo->xen_reg_assigned, 0,
>> +                                   PFN_DOWN((1ULL << p2m_ipa_bits) - 1), count,
>> +                                   &xen_reg_cnt);
> This does not look really nice with ({. Why can't we create a helper function to
> report the count for xen_reg_assigned and call it here? You could then also open
> code your 'count' function that is not used by anything else and is quite ambiguous.

If I'm reading this right, I think you're suggesting something like this
(in domain_build.c):

static unsigned int __init count_ranges(struct rangeset *r)
{
    unsigned int xen_reg_cnt = 0;

    rangeset_report_ranges(r,
                           0,
                           PFN_DOWN((1ULL << p2m_ipa_bits) - 1),
                           ({
                               int count(unsigned long s, unsigned long e, void *data)
                               {
                                   unsigned int *cnt = data;

                                   (*cnt)++;

                                   return 0;
                               }
                               count;
                           }),
                           &xen_reg_cnt);

    return xen_reg_cnt;
}

...

    struct membanks *xen_reg =
        kinfo->xen_reg_assigned
        ? membanks_xzalloc(count_ranges(kinfo->xen_reg_assigned), MEMORY)
        : NULL;


However, the open-coded/anonymous count function, aside from being a
compiler extension, doesn't seem to play well with __init. As written,
this doesn't link:

Error: size of arch/arm/domain_build.o:.text is 0x00000014

Adding __init leads to:

aarch64-none-linux-gnu-ld: prelink.o: in function `count_ranges':
/home/stew/xen/xen/arch/arm/domain_build.c:978: undefined reference to `count.5'

Making it static leads to:

arch/arm/domain_build.c: In function ‘count_ranges’:
arch/arm/domain_build.c:982:43: error: invalid storage class for function ‘count’
  982 |                                static int count(unsigned long s, unsigned long e, void *data)
      |                                           ^~~~~


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 13:51:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 13:51:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011780.1390296 (Exim 4.92)
	(envelope-from )
	id 1uPLrt-0000EW-6y; Wed, 11 Jun 2025 13:51:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011780.1390296; Wed, 11 Jun 2025 13:51: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 1uPLrt-0000EP-3w; Wed, 11 Jun 2025 13:51:53 +0000
Received: by outflank-mailman (input) for mailman id 1011780;
 Wed, 11 Jun 2025 13:51: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 1uPLrr-0000Dw-U8
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 13:51:51 +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 396c3907-46cb-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 15:51:50 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a4f71831abso6185333f8f.3
 for ; Wed, 11 Jun 2025 06:51:50 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-313b20078bfsm1294986a91.11.2025.06.11.06.51.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 06:51:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 396c3907-46cb-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749649910; x=1750254710; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=QpQFY/pwPoXJF2v7e0ywE6chQR56OqLPU61IAGY8kCU=;
        b=CmzU9ea6i2cBfdavosm8HSJikw3scobyCgYJOxT5Kxxo8JTRP+1sNYdHalV6M32BeT
         QQUId7WK4inZu+9kVjlWdlxwvKT+iHw6h6oWwkD/hLPlwl792lBeT/Hbq94elQ3Yamb0
         eQZpvUES/uvAjd/l9Cq0PNS5R85sKpa5KF1lFtcP864w58zNU2c2CrAItDwTeDCS/5ol
         2h97H07dSqpDnjkOExyefHgi+jyjNwJ1h1jFCDyqEbeklUeepI+vZ17/+UflScTm6Q/g
         NNg8ByHfIILGgGCWY8OE93w0oPYAezoVP/0QV/SdsY7BnJe6Znl1njN1jLAXiTdvyeU2
         yzCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749649910; x=1750254710;
        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=QpQFY/pwPoXJF2v7e0ywE6chQR56OqLPU61IAGY8kCU=;
        b=q0la51BeZHf/8PtTRERSQ1cArFRamOQZeKCmrixItrHDPZH2k0PuS1CPdGY6tOMPgL
         HmkvcoMo4xXN2PZfq1VR0AHU0cYWtjge1i79tDWIIEs67NxkUMoDgC+HsP7cLeopQa3E
         HeVVLuWqepd4kvU+FU82gFJnMpdw+7Y6iyNKAvE4UEM1eJMFhVPzFdXjAfuHyjwHT0tg
         4h8qI8MxjiChGvtFfRVtWBk20xsgVL1s7HpgQCPGa7rS/I9qJrotVyEghRVyydjsrFuV
         1ion7vYdpTGHzCT1Betz8lYmjnEdNkunTeFWmnVuhPELSIloc12ttAbgrMjsLCeWRviq
         4qBw==
X-Forwarded-Encrypted: i=1; AJvYcCVyqNuFUw5BHc7FVtaCHuz2anUaqg5rV7FIWWEDBL5drombKHOpLTWaDXYW/eDCr66OI+rnk4itIqg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyrhZb+sElgaeoSLLV2vjYKIDvNtLQCNCN6SyMk3v9N/46aldat
	Em+2ewlkoRlRUk4i72WeFo+Yh/b8HGkVDcHmVuZ6kNLnZsN1wT4GfYTgw9gtcrzN1w==
X-Gm-Gg: ASbGncsqQ8MXHuzgU9X7AA4yoL3pLCjSgQ0fADDausqZ+O+0DWRNimGktR9tRx0OthT
	TEYv+566ibT0S0ha8BB5Hp9En2WUhE4awZjpbt92ioijhdp9JrYYKDhlSmeTgyDvAImWafRxMb+
	HpFgkhw2TX9TPuMwk+CtmFQRbwbTLWh9mywpmjgq3geheqRmyjakfAm0T+gBNXBGq/S07CPBuqG
	d/knSMq22XOCzrAmp4Mwi49C6rGds5VBMn7WpS/OVeFlm8F7anBzBZpGnbUw1NXPqxAyBDKmR5U
	j95t32q/irJk7SJ6RmYhJBuGiS5A4Mmi4/tjIg5RGF3yfl9z+CjHI6h7jt/AmHLGhKpPQwq4S0k
	V9B0707qGm0boKVavoNXiXtuyBl+DCIri9fwHv8rRbK5zuZQ=
X-Google-Smtp-Source: AGHT+IHE1tVkCkpSQoP4raO7qCpdn1Upb5f2QsFS5rc1qg9rLGBUOKNU7cqGcetpwb5j8+zMbmPNtA==
X-Received: by 2002:a05:6000:2913:b0:3a3:6e85:a529 with SMTP id ffacd0b85a97d-3a558af7c26mr2710871f8f.51.1749649909968;
        Wed, 11 Jun 2025 06:51:49 -0700 (PDT)
Message-ID: <89547519-9c7d-40e1-a5e1-abb9a2612498@suse.com>
Date: Wed, 11 Jun 2025 15:51:40 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 07/11] xen/page_alloc: Set node affinity when claiming
 pages from an exact node
To: Alejandro Vallejo 
Cc: Bernhard Kaindl ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250314172502.53498-1-alejandro.vallejo@cloud.com>
 <20250314172502.53498-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: <20250314172502.53498-8-alejandro.vallejo@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.03.2025 18:24, Alejandro Vallejo wrote:
> Set the domain's node affinity to the claimed node if the claim
> specified an exact node. Do it immediately before making any changes in
> case setting the affinity fails (even though it shouldn't).
> 
> This allows preferentially allocating from the closest NUMA node when
> "exact" is not specified (e.g: p2m tables, etc).
> 
> Signed-off-by: Alejandro Vallejo 
> ---
> Toolstacks can just do it themselves, but it's more error prone. If it
> claimed pages from an exact node (and remember we can only hold a single
> claim at a time) it makes no sense for the domain to be intentionally
> allocating from NUMA nodes other than its home node.

I question this as a global, built-in policy: An admin may intentionally
do things in different ways, for whatever reasons they may have. Even in
the toolstack I'd consider such behavior a valid default, but requiring
a way to override.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 13:53:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 13:53:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011787.1390305 (Exim 4.92)
	(envelope-from )
	id 1uPLtF-0000kd-Gp; Wed, 11 Jun 2025 13:53:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011787.1390305; Wed, 11 Jun 2025 13:53: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 1uPLtF-0000kW-EG; Wed, 11 Jun 2025 13:53:17 +0000
Received: by outflank-mailman (input) for mailman id 1011787;
 Wed, 11 Jun 2025 13:53: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 1uPLtD-0000Tp-EW
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 13:53:15 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on2060a.outbound.protection.outlook.com
 [2a01:111:f403:2414::60a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6a3385f6-46cb-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 15:53:13 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by CH2PR12MB4151.namprd12.prod.outlook.com (2603:10b6:610:78::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.39; Wed, 11 Jun
 2025 13:53:07 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8792.034; Wed, 11 Jun 2025
 13:53: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: 6a3385f6-46cb-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=fgznPjePDqIEe8XD+M6k8Go6yT1GQ++gq2l1KzP1oN9TkzdGWi44dJKCXJG4KYdMNm93oGjqnADro6wtS8SoiZHxLjt8L1QVaVBrpSvE9fQbJtF484Wm5c4qDA/KQeZjA9M00HBNTMpxK8x4fMzLnwvo3cHi8jTqUCHaeUDQAvJvSTpmmjSAmQUVRHhgAJHOv5wTuofwW1pbfci2v7LN6FpJsfeVXjyZmNKnbE+YoOBIPvhtpqAXvLdADUquIK6tk6QRDlhqKm0F53+90elEtUkm+kqGBh1HW/yN0qgfeMT2bRDW5itNbOnasm9RIqYAHHxmFJfI+SA/f6/prwPvSw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=VUEqhfbrTqoFATdGeSIV975frBPi2IJjMsFogOGtq40=;
 b=osHES38iNlP/NrHrgyDcOX9ZZ1E8Re8YCdgJptHH9hIB7BQCOK7Yz81AaJI4XxsL/RXPrszUEB4uLQ05896PMn/+gT4QIC7RLAtcpRwpTQ0xZQ9rWV4gSgEcSxmmdjowM7UX9ubVhJE5znSYUjqwIBbUM9mIkav2h2f4lJYzoEx3k4jLJlRE8yfeZY1PqQpDK/sbYxRzVGZm9svG9kDe7fTM8TogEbF5HUPz3A3A7HQCgptiqEW2bTD8+0wGVMy29H1t7pvCG2C7dux3bfU/7DHgfDBtxccWflh6HQHLhG1xd6/02bOwDDDLw6VdO35KGFvwvgm7NLUGuHWztZr8qg==
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=VUEqhfbrTqoFATdGeSIV975frBPi2IJjMsFogOGtq40=;
 b=ICnlavNzkp5G9CVhdOVHa2HeUYtsF1Eyzlkhu+/M/Nn8knPDY8cAGX6IFqGD4GkeLJHf2JzdTmhiuTj/xye3QWT5bQF0Vz6CIAF9UpyekHYyu8GNcn77XxcvEqPPzo48TNbv9fHoo3EKY6ThWBm2dU+W2tKjZb825ZCb6D0O1OM=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <27fc7c41-3a8a-4bfe-bed9-b05b33c2d73e@amd.com>
Date: Wed, 11 Jun 2025 15:53:04 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 1/2] xen/arm: exclude xen,reg from direct-map domU
 extended regions
To: Stewart Hildebrand ,
 xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250609183438.178214-1-stewart.hildebrand@amd.com>
 <20250609183438.178214-2-stewart.hildebrand@amd.com>
 <6a52ad54-cac8-43fc-b396-87b0ac01d1dc@amd.com>
 <3ea5fec5-0083-4c83-9430-229550911b6b@amd.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <3ea5fec5-0083-4c83-9430-229550911b6b@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR0P281CA0174.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:b4::7) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|CH2PR12MB4151:EE_
X-MS-Office365-Filtering-Correlation-Id: cd387e37-5a65-4c32-cd20-08dda8ef4b67
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?aElXbFRSNGErVjVkUTVhRFRjQm1MSXkwUE1KZmxia1NTWnRVSE9uWVZGVHZr?=
 =?utf-8?B?OXJVamVsRUhTN21CSVg1UnVVOUlPbTR6S3BuMHEybXhrb0xLRGF2WmxYU3g1?=
 =?utf-8?B?T2phNDRKUHlJbUdIeENvREpQNC9SMWhNeFNPRUFlWm9SQkg1SU04ajBhVlJY?=
 =?utf-8?B?YlJkRTNRcUNGbE16KzZ6bFdLS1BlSklTVUE0bnV6NUxVb0txSVNncXFKdmZT?=
 =?utf-8?B?SnRuVFZWMVZRMzRYUzhTV1g3aU8zV05pa1R3SWlZZ2hDN0tQNFAvT2lqQ1BU?=
 =?utf-8?B?K24yUEJ6cUZ5YzVYREhoK2lpSVNkdXdNV1pRTzRwU3NhUHZKVU0wWHd5dnFD?=
 =?utf-8?B?N2g5M2dBcHdLeG9jc1FjQVAvcFJtSXhpUElXdWdYTkJ0STBCeWl6Wmxud1h6?=
 =?utf-8?B?c2N4ZFhBVUpDMWM0bURLc2ZjWHpCVmc4cVVScDk5K05nc3dwQnErd2lQRmlX?=
 =?utf-8?B?ZXA4YTV2T1d4cGVGN0Fvem9PSW0zMm8ybmRzQXllRmtKb3FaWlJVa0ZVTUcz?=
 =?utf-8?B?Ymt6dU1zeVdGM1RucktFbzBuUnRuWWRFK2doNTBCYTk1MHJYTEI4VFhOV05Y?=
 =?utf-8?B?WkpGL2tJVXJxdnM0RHVNV3lRV1N3RWVabzhSSThMZGNUQlFuWkZneVZsbXlp?=
 =?utf-8?B?MVh6TGRiajBEVG9NVERoRGE0RDdhRzl4ckVNOVhPWWFmMEZENE1QLzJzR2tS?=
 =?utf-8?B?UDNWbE9VUWw2M2R4T0NIZTNjelkzb0c4QnVjU3daVkVqSldFY0h1ekIrdERB?=
 =?utf-8?B?OWNNMzk2dWpGKzBUbVRHZGoza0ltVVphSDZOSGJEdG5uUmplamthYTRtYm1j?=
 =?utf-8?B?YmRNTENDc1Z1UGl6T0hEZmNRNXp0RHB4ZmZlWjdONlp4VVJuUTN3ZENVUk4r?=
 =?utf-8?B?WmQzRitEK3ozc2J5bnlkUStpL25ZcGN1U0RZYzVuWjJZUERMMlE3U2g2VGtY?=
 =?utf-8?B?S3ZqeXJWSUJwb2x4SE5sVlppYmxpT2Izb1Awc05kak9JZzlSS0ZSSkhMY0g5?=
 =?utf-8?B?TGpPKzB5bi9uVzVqM1NubTNWd2VQYVcyRS8rS3ErWmJGYlRIK3dDb0x3L0RQ?=
 =?utf-8?B?TnVrVHNvVTF4aG85S1FFQkxjaW9OMWVyVVN3YTkvanVkUUxVN3dZTXp2eWVZ?=
 =?utf-8?B?L2E5WlpEYjBWVHJpd0ZHU3V5VWZxSnFkUEpoV1lyQnZHSEtTSE1UWEdwNmM5?=
 =?utf-8?B?RUF3ZFRIQ1NyT2M5eE5vb3d5MEZGUTROZzY2K0VOLzZpb1QvUUtud3pIR2tW?=
 =?utf-8?B?VzdmRGtrTzFYSm5XWHlMTTlla3JtVnlrYnJaZDhjaGVVd21xV2VlZWhpMVh2?=
 =?utf-8?B?UXMxcHFUZm94eThPSU1NL0E1WWgwc0N6TTUyc1J0dUpVTGJhMkpPcDJIS24y?=
 =?utf-8?B?N2EwY2M2bmJobVZjLzdQUUJPNDhIRDNoSCsrSFFKV2lUVzAvMUp0T2g5ZFdt?=
 =?utf-8?B?VWxuZWJNbUdrbGtSekVqY0tqczhKbXFaL2d0d3pRU0QzV2FscDhRZ0NtMXFs?=
 =?utf-8?B?dlYwdldYeXV3ZnRNWldvNnJmdVNONGNiWjJMbGkrYmFsT2dCK2c4c0ZCbTdQ?=
 =?utf-8?B?QVo4Z1Z4VE9QNU1OT094NU0vWnR4ZG9XckY0Kzc3QXBxNkdUTDZxQld3N2ZQ?=
 =?utf-8?B?MHBPempsc3IwaHJYcnJaNnJwWmZGWUcyd0p4NTl3aTJLN2ZpUjZpTGdZN3Ar?=
 =?utf-8?B?TkNKa3B4bGpXSk9Za1JrRnFDMFVONGZab280OTF5OS9FSEQ0d2xubW9vTHNW?=
 =?utf-8?B?ZmlSWjRnditJV0RDR290U1QwSzluVVROWk93WUNUSTVVMTlITDVSOGo1cnhq?=
 =?utf-8?B?NTNSYk9aN215Q3lhWUkvVUZmOHBVV09YVStJdDVSV2ZwOVpRd3pyc0hiSnhk?=
 =?utf-8?B?aUhLSVdJUVNmYWEwdkFxSzAzQnNscjRoU05BZGFCY3NxNWJqTjF0clhsNTJK?=
 =?utf-8?Q?ggzYH71y6f8=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.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?U1FKNXJreDdFNndmZWFXVWRhbVh1T3JxR2RtSjE3YmV5QUhadE11QnQ5MmN4?=
 =?utf-8?B?aVQ3Zklhak9vd09ld1FwM0NvTjgwQWlvMysxUEdCZkdZZmhFUWRvK1ppdktr?=
 =?utf-8?B?MzRsYUxVYTlVM1E0VXZ2N1N4dERMZjI1UDM5dVB1am4zU044N1pKRVpFSnQ4?=
 =?utf-8?B?eUpKYmxNbmFJNE9tbFVBajBzK25lNUZwOVNCSEcxK1FRQVZGdWY0aWNWc2ty?=
 =?utf-8?B?YzJDZnZDWEJlc2FzZDdtMks1c1Zhbk5aeWNyNVpvcHJBRmZtT2pqVVdZTVVv?=
 =?utf-8?B?cDBiOTBLTnBzVE5kK3NoWjYzeXg2Z0RsaCtleGc1SGUvcGh4czVYdXVsV05q?=
 =?utf-8?B?WFU4SGMzUCszanRFT3UyaHdBNXluTlVjNzRFMXlUQU9wbGRGTjI3RDN2T2xk?=
 =?utf-8?B?U0w2aEt6Q0pFdmgzaVlISmgzK3E5OTVhNlFhVmYweUF4NUVGNmsrZElhdmV4?=
 =?utf-8?B?Y01MRFpMNm0yRG9iYU03UnY5bEFSaUdhU21IR3FlOXE4N3QzTVEzS3MvN2Fx?=
 =?utf-8?B?ZnFNeENxek00UG1tN0tDRGpkUUFnY01ZYngxaCsvMTdhbWx2ekVFdW9iTDdF?=
 =?utf-8?B?d1dpbHZHMVRRb3ZodVdXVDM2ekdCMVZUQk9DWTJzdUExSUFvUURaazJUSElw?=
 =?utf-8?B?c3ZaYjBzM3RJLzMxaitUZVVVTVZ0a1JmY0lWZkZrMndCUDZieXlPUStvUzND?=
 =?utf-8?B?ZnJBcGM5Qis2ek1wT3FrcEVDUlQxVnZJVGFEaUxPOTRQZzQvc1NHVU1pZVla?=
 =?utf-8?B?bzkvWWJUbGZKMkxZRk1EK28zWUhFMEE3VkQ0NnUxZ0dXc3hhQjlDYzZ1T0RS?=
 =?utf-8?B?cE1YcUtMV2Q4WjlaRkpIMlNQZXJuMzNLaTcyN0xsVkNsaGtxdFhoeHJyak1S?=
 =?utf-8?B?UDdianpocU9sdk9WMDAxR2FtOHRSRFdTYVR2cTRrTFBDS2Z0UDVJYlhmYi9B?=
 =?utf-8?B?c0FoQXlJWEhNZ0taSzYza3VnRUpmamFFU0swcTgyZUpMYk80Sys2dU4rZ3g0?=
 =?utf-8?B?UmRJRkpGeWtLYlJkVU1sbkpXTkc3aXJGTTY5aDdTcU1zY0JaODllRG1qeERY?=
 =?utf-8?B?cVVyTTJnWjVHRW0rWUpIa21OYkQyL0dQS2RETjNSd295MGZVUHdIQVFXenBt?=
 =?utf-8?B?aGp5T1RLUitsWTd1TEpwUVprSDJMWVNVZVYycUpmdXZQSzBaV2cvNDIxaURV?=
 =?utf-8?B?RktzTlRmZmVxaE1EYkJOVFRTQkhqUHRTTVYrUU5LZjMzMkxSUW5UMkw2Q0g5?=
 =?utf-8?B?a0dTL1BLMWllamdCUGo1djhrUWVhcUJDWHo2ZS90ZFRqcmw0cGxSNysrWjVa?=
 =?utf-8?B?dHdCT1Bub09HT3VST2VyYXpjT09mbVZIdmtHVEIzV0pkY1J6L3VLdVI4d0RI?=
 =?utf-8?B?bXFtTG81Ni90eTNMbEl1QVRObEVOcEFSdGxuNSs4ZzZrU2hXT3ZrOXBWQVNJ?=
 =?utf-8?B?c09RZ0l6SHJFWGozd2FzZ1cvZGVFQ2pwQ1hEbkJmaUtYbzUvZVFCcmdRVWRP?=
 =?utf-8?B?U1Zpb0ZXVHdYZ3dOZ1BQQ2MwaGtDRnZacWNZY3V5VUYyUFNBaVQ0d0RwSlM2?=
 =?utf-8?B?aXYyOEpLV1NBYVoyRVhLcUVEbm5SbUFNR1YvRzRoUkpyQTY5dUhlczlEQ05n?=
 =?utf-8?B?N0RTaVlxTEcyanVEd3lyZmRsTmVxVVJKUWRLQWxFUmxiT2FPeVN0YXpnNVhO?=
 =?utf-8?B?MWwyMEU1dWxlMGlaRWNXcldiVUFGeWtqQWFLS3gwV0JTZHRhSUJwZThSTnlr?=
 =?utf-8?B?WUNxK3NOMmYvR1FKdHo3VXZtd2R4bXZ0K0JKZDVlYzlpRm5NWVp6QXJhZFc1?=
 =?utf-8?B?RVZNeEtrVXVyWUJ6dEtIUCs0NXRmVlUwUW1YOUlHbnBiOWZJTERSQlA2aUwr?=
 =?utf-8?B?ZkZrbUt0OFJXOFVCSndvVExPZGJYK1R3dnJJOHhWdVhlQ3ZQdjFsanBmOVpN?=
 =?utf-8?B?NGVlalR3Yzh3YU5PNS93V2dNMXcwVDUvNUVmN2ZrWis2YmNvTFZUaUVMcFpP?=
 =?utf-8?B?Vk91U2xQTzNGZjNJZjBBSm9wMCsrYVFiVmFjOW8wK3ZTWUdvQVBOOHZrblF3?=
 =?utf-8?B?RnVEMnlZNDl2cHpicU5lbFY5Z0ZUcWROOTFiZENycDlpeTJQNEZ1aUVmLzlP?=
 =?utf-8?Q?hGp4=3D?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cd387e37-5a65-4c32-cd20-08dda8ef4b67
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jun 2025 13:53:07.4842
 (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: 0AwwTFnAFhsf8qlVEa1OGSCuhTKsuvT46CQoZNh5kjDQQkKK09cjqtdPIXk2HNE1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4151



On 11/06/2025 15:49, Stewart Hildebrand wrote:
> On 6/10/25 03:27, Orzel, Michal wrote:
>> On 09/06/2025 20:34, Stewart Hildebrand wrote:
>>> Similarly to fba1b0974dd8, when a device is passed through to a
>>> direct-map dom0less domU, the xen,reg ranges may overlap with the
>>> extended regions. Remove xen,reg from direct-map domU extended regions.
>>>
>>> Take the opportunity to update the comment ahead of find_memory_holes().
>>>
>>> Signed-off-by: Stewart Hildebrand 
>>> ---
>>> v3->v4:
>>> * conditionally allocate xen_reg
>>> * use rangeset_report_ranges()
>>> * make find_unallocated_memory() cope with NULL entry
>>>
>>> v2->v3:
>>> * new patch
>>> ---
>>>  xen/arch/arm/domain_build.c           | 77 +++++++++++++++++++++++++--
>>>  xen/common/device-tree/domain-build.c |  5 ++
>>>  2 files changed, 77 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>>> index 590f38e52053..6632191cf602 100644
>>> --- a/xen/arch/arm/domain_build.c
>>> +++ b/xen/arch/arm/domain_build.c
>>> @@ -792,15 +792,17 @@ static int __init handle_pci_range(const struct dt_device_node *dev,
>>>  }
>>>  
>>>  /*
>>> - * Find the holes in the Host DT which can be exposed to Dom0 as extended
>>> - * regions for the special memory mappings. In order to calculate regions
>>> - * we exclude every addressable memory region described by "reg" and "ranges"
>>> - * properties from the maximum possible addressable physical memory range:
>>> + * Find the holes in the Host DT which can be exposed to Dom0 or a direct-map
>>> + * domU as extended regions for the special memory mappings. In order to
>>> + * calculate regions we exclude every addressable memory region described by
>>> + * "reg" and "ranges" properties from the maximum possible addressable physical
>>> + * memory range:
>>>   * - MMIO
>>>   * - Host RAM
>>>   * - PCI aperture
>>>   * - Static shared memory regions, which are described by special property
>>>   *   "xen,shared-mem"
>>> + * - xen,reg mappings
>>>   */
>>>  static int __init find_memory_holes(const struct kernel_info *kinfo,
>>>                                      struct membanks *ext_regions)
>>> @@ -882,6 +884,13 @@ static int __init find_memory_holes(const struct kernel_info *kinfo,
>>>          }
>>>      }
>>>  
>>> +    if ( kinfo->xen_reg_assigned )
>>> +    {
>>> +        res = rangeset_subtract(mem_holes, kinfo->xen_reg_assigned);
>>> +        if ( res )
>>> +            goto out;
>>> +    }
>>> +
>>>      start = 0;
>>>      end = (1ULL << p2m_ipa_bits) - 1;
>>>      res = rangeset_report_ranges(mem_holes, PFN_DOWN(start), PFN_DOWN(end),
>>> @@ -962,11 +971,48 @@ static int __init find_domU_holes(const struct kernel_info *kinfo,
>>>      return res;
>>>  }
>>>  
>>> +static int __init count(unsigned long s, unsigned long e, void *data)
>>> +{
>>> +    unsigned int *cnt = data;
>>> +
>>> +    (*cnt)++;
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +static int __init rangeset_to_membank(unsigned long s_gfn, unsigned long e_gfn,
>>> +                                      void *data)
>>> +{
>>> +    struct membanks *membank = data;
>>> +    paddr_t s = pfn_to_paddr(s_gfn);
>>> +    paddr_t e = pfn_to_paddr(e_gfn + 1) - 1;
>> Why do you subtract 1 here if ...
>>
>>> +
>>> +    if ( membank->nr_banks >= membank->max_banks )
>>> +        return 0;
>>> +
>>> +    membank->bank[membank->nr_banks].start = s;
>>> +    membank->bank[membank->nr_banks].size = e - s + 1;
>> you add it again here.
> 
> To be consistent with add_ext_regions() and add_hwdom_free_regions(),
> but I suppose there's no need for that. I'll drop the extraneous -1 and
> +1.
> 
>>> +    membank->nr_banks++;
>>> +
>>> +    return 0;
>>> +}
>>> +
>>>  static int __init find_host_extended_regions(const struct kernel_info *kinfo,
>>>                                               struct membanks *ext_regions)
>>>  {
>>>      int res;
>>>      struct membanks *gnttab = membanks_xzalloc(1, MEMORY);
>>> +    struct membanks *xen_reg =
>>> +        kinfo->xen_reg_assigned
>>> +        ? ({
>>> +            unsigned int xen_reg_cnt = 0;
>>> +
>>> +            rangeset_report_ranges(kinfo->xen_reg_assigned, 0,
>>> +                                   PFN_DOWN((1ULL << p2m_ipa_bits) - 1), count,
>>> +                                   &xen_reg_cnt);
>> This does not look really nice with ({. Why can't we create a helper function to
>> report the count for xen_reg_assigned and call it here? You could then also open
>> code your 'count' function that is not used by anything else and is quite ambiguous.
> 
> If I'm reading this right, I think you're suggesting something like this
> (in domain_build.c):
> 
> static unsigned int __init count_ranges(struct rangeset *r)
> {
>     unsigned int xen_reg_cnt = 0;
> 
>     rangeset_report_ranges(r,
>                            0,
>                            PFN_DOWN((1ULL << p2m_ipa_bits) - 1),
>                            ({
>                                int count(unsigned long s, unsigned long e, void *data)
>                                {
>                                    unsigned int *cnt = data;
> 
>                                    (*cnt)++;
> 
>                                    return 0;
>                                }
>                                count;
>                            }),
>                            &xen_reg_cnt);
> 
>     return xen_reg_cnt;
> }
> 
> ...
> 
>     struct membanks *xen_reg =
>         kinfo->xen_reg_assigned
>         ? membanks_xzalloc(count_ranges(kinfo->xen_reg_assigned), MEMORY)
>         : NULL;
> 
> 
> However, the open-coded/anonymous count function, aside from being a
> compiler extension, doesn't seem to play well with __init. As written,
> this doesn't link:
Sorry, I don't know why I wrote to open code count(). In conclusion my remark
was to place this code in a separate function to avoid ({ in
find_host_extended_regions(). So there will be count() helper and count_ranges().

~Michal



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 14:10:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 14:10:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011794.1390315 (Exim 4.92)
	(envelope-from )
	id 1uPM9h-0003rT-SZ; Wed, 11 Jun 2025 14:10:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011794.1390315; Wed, 11 Jun 2025 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 1uPM9h-0003rM-PX; Wed, 11 Jun 2025 14:10:17 +0000
Received: by outflank-mailman (input) for mailman id 1011794;
 Wed, 11 Jun 2025 14:10:16 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uPM9g-0003rD-2R
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 14:10:16 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uPM9f-00DoSS-0U;
 Wed, 11 Jun 2025 14:10:15 +0000
Received: from lfbn-gre-1-199-136.w90-112.abo.wanadoo.fr ([90.112.161.136]
 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 1uPM9e-002i7t-2l;
 Wed, 11 Jun 2025 14:10: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=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date;
	bh=aRVxHnIoORT4t1BZRJh7GplGMdL05IknANQPk/Da1YI=; b=kTUFQBn/3E03zQL+XEwvKmb/aG
	47/eiiVYUNE0MzX9M9oxuF5xUqJst0SyjKauQMwJUThQ6DddZV0kRecUG0QBoV9bvyRHabWJ6sJVc
	yq+zoMQc/PgeSEFkVUHRODudCjRqWugO9XPp3cPPs79qUjBXsvmePAfFeNsMWVbL1ogQ=;
Date: Wed, 11 Jun 2025 16:10:12 +0200
From: Anthony PERARD 
To: Stewart Hildebrand 
Cc: xen-devel@lists.xenproject.org, Juergen Gross ,
	Stefano Stabellini 
Subject: Re: [PATCH v4 2/2] tools/arm: exclude iomem from domU extended
 regions
Message-ID: 
References: <20250609183438.178214-1-stewart.hildebrand@amd.com>
 <20250609183438.178214-3-stewart.hildebrand@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250609183438.178214-3-stewart.hildebrand@amd.com>

On Mon, Jun 09, 2025 at 02:34:33PM -0400, Stewart Hildebrand wrote:
> When a device is passed through to a xl domU, the iomem ranges may
> overlap with the extended regions. Remove iomem from extended regions.
> 
> Signed-off-by: Stewart Hildebrand 

Reviewed-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 14:36:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 14:36:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011811.1390325 (Exim 4.92)
	(envelope-from )
	id 1uPMYX-0007If-Pa; Wed, 11 Jun 2025 14:35:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011811.1390325; Wed, 11 Jun 2025 14: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 1uPMYX-0007IY-Mi; Wed, 11 Jun 2025 14:35:57 +0000
Received: by outflank-mailman (input) for mailman id 1011811;
 Wed, 11 Jun 2025 14: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 1uPMYW-0007IS-MC
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 14:35:56 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20605.outbound.protection.outlook.com
 [2a01:111:f403:2408::605])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 60cb9e4b-46d1-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 16:35:54 +0200 (CEST)
Received: from MN2PR16CA0038.namprd16.prod.outlook.com (2603:10b6:208:234::7)
 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.8813.33; Wed, 11 Jun 2025 14:35:49 +0000
Received: from BL6PEPF0001AB74.namprd02.prod.outlook.com
 (2603:10b6:208:234:cafe::c3) by MN2PR16CA0038.outlook.office365.com
 (2603:10b6:208:234::7) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Wed,
 11 Jun 2025 14:35:49 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL6PEPF0001AB74.mail.protection.outlook.com (10.167.242.167) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Wed, 11 Jun 2025 14:35:48 +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, 11 Jun
 2025 09:35:48 -0500
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, 11 Jun
 2025 09:35:47 -0500
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, 11 Jun 2025 09:35:47 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 60cb9e4b-46d1-11f0-a307-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=kqBu1HLnp/S6vYQaPCoAsYETHDjlli3q+xGnypcPU6zq4NsZnwlGP9snpH//fsmPTd48Wikwhl4PLcYo8LVQ4Z7D+m5QReGdWYMq6WG8bMDa+NxVp7OL+IUD9U82JTh+///MUiRw2d4omd+NCPdWBzu5rmJ68So9a49Fky5DC8+gLTxEJUfVqmqHRmQQ1I2ppyh+8MUS51LuS8aS9EfC6iuFhr86gcAS1lH9LUW4LTt3K4xa8GE5U/06ZB5NYYxfaQaRTQ/y/xB2iAib4lcg5H2nb7dlD1v0rJkIW6x+/YNgHFpCD0UETgb+xQRsWjdmYP2WtZ9TooTXVSAdNVGFPw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=lZ53+t2/x3mii/RAnIdlbJCsZzMfjwSpIHYR7e9AEDw=;
 b=djGKdsi1SRD2opLjOUEnzymkmuvtIh2zEWM3Okokpl4Y0wcXIq4Ts6hTDftM5UL6jSv4tQ5pKyBuJ1q5WVJQvvdRDpEQkNY5MBozYBWviVSoEfpfa7paqFVKJSvTdw7c7JlnKRmK4sgLjzCPMAmJOV69TjPnH0ueBk3ujqmo5T/BEEEyowvkMSqiz8mdgDy15nc5r4/ffd/Sbhmku49Odd9HxryZah56WYDJhHEN+xOFK4RpR6uwuGs1POmfWRJXg/WJP9/DXbefXNMqbK6kbCajU0AuzFv/LWI/1WOvwFXSTj/wq2pri1KhGBCJ0y3h17sYuVCCTp7DRwjqIxt9kA==
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=lZ53+t2/x3mii/RAnIdlbJCsZzMfjwSpIHYR7e9AEDw=;
 b=wXLCOIyEWctG/T4phNSi70/NUtI8OAVH2fBy9S6Xz8Y0r8rWn1/uZ66qeqX9s2yczXR5rLdkXSbyTrh1m+DEvbulbyE50Jh9m00PczmDHQ8z1KqcnP0mvVOyHXXKgMc9OrB/cjmX4OkK9vcRZzxVPbUMtXDrsU3Z57pSOM+2Euo=
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/6] Enable R52 support for the first chunk of MPU support
Date: Wed, 11 Jun 2025 15:35:38 +0100
Message-ID: <20250611143544.3453532-1-ayan.kumar.halder@amd.com>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL6PEPF0001AB74:EE_|DS7PR12MB9043:EE_
X-MS-Office365-Filtering-Correlation-Id: b6ba3164-22d2-4294-eded-08dda8f54217
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?lj60OroN+MaM0syxNBem06ddpkwaha06KPqFklv7x/pFJ5SL2e/41gInqD0R?=
 =?us-ascii?Q?i/fmBNalDjcqU204eU8UdoFQrqhXdvydtTO6e8Dn4UXPPCB9nbgyf0oWrFDc?=
 =?us-ascii?Q?8nXF9+L4h5wX3//u/l82Pghyc1xWG6dtJth6Pc7jK4BztmZNCqbt2HtYE3BY?=
 =?us-ascii?Q?IFRu3irMbeoF0NDSxmXJgYLEc+WSMHLgDl2Wv4GLpZ+kCMyMEUT8YNonHgqa?=
 =?us-ascii?Q?qwXyh3zRPPCaqTXbkN79ocZ7eHlXH6JSGPTiN83LCpj6bQ/JsPqNXiDip17J?=
 =?us-ascii?Q?kDgS2H6CEKMs83b8HIc2msv05oxvPQPVb/jyDPiVWFVUQNGPYAfEhVXjO6oh?=
 =?us-ascii?Q?bVzvNIF7DIm7pxKVciOrwA/yTj7JJYW5ZUTeQSKCpr5rpiJNPl3ZraWJ/qFg?=
 =?us-ascii?Q?UhzJXYakzck85Yw0Xy65LDRs8WG8hD393yvfsRm9Rgw5flGFadmbZvedzkfP?=
 =?us-ascii?Q?4PExawfgAKKCXFKVFKmnH+6vcIwvZopoYkzcPTJMFZ6K50wfWqPeTYQJ1Ub5?=
 =?us-ascii?Q?ht3x2bl3XfFM1oMy1zZBJl6RAwVfkNK44c0yfTVJMyB24G8cnnnNzCWIcSqr?=
 =?us-ascii?Q?32Cw+aGpGWGDeprIiJWDVIsg4oOTyoe2gjPPuMcsYrLluLcRwdAcgEYY++g5?=
 =?us-ascii?Q?CgYQFdCuxROUYb6hdmJ9UE+dBR0yxuR2e5yEgEwoaVeLlOj8sshsaUzV6K94?=
 =?us-ascii?Q?Hf6udTwi89NP6IPEchlOKdfQnGbpIS55hcqVDIrxIg+RuRw0jfpVVhSKrGOt?=
 =?us-ascii?Q?aoh+JiegwqScfEB656bGGSzO3hQ5X74dtrohnOddTf/vyA+LyNoCz+g0Z8eM?=
 =?us-ascii?Q?OHka0qdyEGUmxx/dUTwvTEp7DVOuWVQ2g54rdglRxlIfw1htXzM/HsnZmjXy?=
 =?us-ascii?Q?w4y3PpsbMuebAQGyQC3UEF3zTt+3+a/nFb5tsTTFX6KyOGooF7gLDGNdapPU?=
 =?us-ascii?Q?WVGDWb2x9pjgePjyRRQn5xvjVc/rJKxUA/pgbjlv+akZdZ0R26bJqyTdKMhM?=
 =?us-ascii?Q?Idf9BlQh0Tr9AeB0/3zguEBqOBjcMbRnDxAO0yaxz4bbWLIySfHa1Z15no6P?=
 =?us-ascii?Q?kCRv7pzHNNFYaC3Y71uaPA42IaqO4SVH2KkygvFEehpFAQu5drWAPrpdCxUT?=
 =?us-ascii?Q?EPdrID3dAsCsKtkteSOT+Ql/4GANzNBX/luI293V4MWS9Wa3KSMqAbO5E1i2?=
 =?us-ascii?Q?xd45u5SCQA58idAC7pC72fWuJ6/mI3SmzQ4vnIa5ekutddAEs6lqR+2PVoYg?=
 =?us-ascii?Q?B+A3+UEkO8pG+LvNSZUyFIm1t+9v5o5JSduDQLA071RKcUQjy5iPVKg5ipaI?=
 =?us-ascii?Q?Awybxrv1kLVfp+U5IvGVTbqBMZkC9AqOtOKdLMjVWDRdVonEU64NY5SxHJqE?=
 =?us-ascii?Q?ktZpRJJ5IaUF/XFl22rgEPp8ys/ulE2xcNKgub4fsZ/oulHaa3YgywlCYSva?=
 =?us-ascii?Q?Y6eGTnUGuborOeGrIse9cs6LRCKXWxTOKJVrckyXl5xz/s6yqorZ/NCt41yr?=
 =?us-ascii?Q?d/EczzR+yRbx7elLP8e7k1QFNiPJp1lhGkmj?=
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: 11 Jun 2025 14:35:48.5360
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b6ba3164-22d2-4294-eded-08dda8f54217
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:
	BL6PEPF0001AB74.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB9043

Hi all,

This patch serie enables R52 support based on Luca's series.
"[PATCH v6 0/6] First chunk for Arm R82 and MPU support".

Changes from :-

v1 .. v2 - Changes mentioned in individual patches

v3 - Split "arm/mpu: Provide access to the MPU region from the C code"
into 4 patches.

Ayan Kumar Halder (6):
  arm/mpu: Introduce MPU memory region map structure
  arm/mpu: Provide and populate MPU C data structures
  arm/mpu: Move domain-page.c to arm32 specific dir
  arm/mpu: Move the functions to arm64 specific files
  arm/mpu: Define arm32 system registers
  arm/mpu: Enable read/write to protection regions for arm32

 xen/arch/arm/arm32/Makefile                |   1 +
 xen/arch/arm/arm32/asm-offsets.c           |   6 +
 xen/arch/arm/arm32/cache.S                 |  43 ++++++
 xen/arch/arm/arm32/mpu/head.S              |  41 ++++-
 xen/arch/arm/include/asm/arm32/mpu.h       |  34 ++++-
 xen/arch/arm/include/asm/mpu.h             |   2 -
 xen/arch/arm/include/asm/mpu/cpregs.h      |  68 ++++++++-
 xen/arch/arm/include/asm/mpu/regions.inc   |   2 +-
 xen/arch/arm/mpu/Makefile                  |   3 +-
 xen/arch/arm/mpu/arm32/Makefile            |   2 +
 xen/arch/arm/mpu/{ => arm32}/domain-page.c |   0
 xen/arch/arm/mpu/arm32/mm.c                | 165 +++++++++++++++++++++
 xen/arch/arm/mpu/arm64/Makefile            |   1 +
 xen/arch/arm/mpu/arm64/mm.c                | 130 ++++++++++++++++
 xen/arch/arm/mpu/mm.c                      | 123 +--------------
 15 files changed, 487 insertions(+), 134 deletions(-)
 create mode 100644 xen/arch/arm/arm32/cache.S
 create mode 100644 xen/arch/arm/mpu/arm32/Makefile
 rename xen/arch/arm/mpu/{ => arm32}/domain-page.c (100%)
 create mode 100644 xen/arch/arm/mpu/arm32/mm.c
 create mode 100644 xen/arch/arm/mpu/arm64/Makefile
 create mode 100644 xen/arch/arm/mpu/arm64/mm.c

-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 14:36:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 14:36:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011812.1390336 (Exim 4.92)
	(envelope-from )
	id 1uPMYq-0007dM-4X; Wed, 11 Jun 2025 14:36:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011812.1390336; Wed, 11 Jun 2025 14: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 1uPMYq-0007dF-1J; Wed, 11 Jun 2025 14:36:16 +0000
Received: by outflank-mailman (input) for mailman id 1011812;
 Wed, 11 Jun 2025 14:36:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uPMYo-0007cf-RC
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 14:36:14 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on2062e.outbound.protection.outlook.com
 [2a01:111:f403:2408::62e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6b99f685-46d1-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 16:36:12 +0200 (CEST)
Received: from CH0PR03CA0009.namprd03.prod.outlook.com (2603:10b6:610:b0::14)
 by SA5PPFD911547FB.namprd12.prod.outlook.com
 (2603:10b6:80f:fc04::8e4) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.23; Wed, 11 Jun
 2025 14:36:07 +0000
Received: from CH1PEPF0000AD75.namprd04.prod.outlook.com
 (2603:10b6:610:b0:cafe::61) 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.8835.19 via Frontend Transport; Wed,
 11 Jun 2025 14:36:07 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CH1PEPF0000AD75.mail.protection.outlook.com (10.167.244.54) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Wed, 11 Jun 2025 14:36:07 +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; Wed, 11 Jun
 2025 09:36:06 -0500
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, 11 Jun
 2025 09:36:06 -0500
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, 11 Jun 2025 09:36:05 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6b99f685-46d1-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ajtENmQs69FG+RotrkpcuoE7PScI/UEDAILFS3tfLSdgpNr1grgkuZsew6PGZ42ASNIb5AH5zwLTfhab4ZNsLu2cTMW/O93XS9XG59VARN5YBjnxsqEK/CUX2jl23C9O8ToKWYi45fNfFjnHEK/XkI+5911F+1+5XXRdJG8606K5Uqa+stk7F0PIjfQAtZ4BfYJpvpwXwgPLE9T4sikTdGHw0KkD0Fo3bj3tlsCUzhVs4G8Leo5sx9oj1ndY5on3NwxOGf3h1RfYVllxVZDxkBWoa9/nl1ci5d6i1OXilVaIzKX+Dw/pjwmZWLF/o/Vkr+ZuWJvAXhKOUWJ5KMpzrg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=nfBXF6h9UdzLnnzbqVw3V7gpYaAlMU83olFhqIogFh8=;
 b=bCBpMmiJ5Zm65WXHVY+oHjxXNtKkc2VyyG6GYXvtnqhypiPK0M0yRIzxeYQon2YGMSUNIMzxAbQcEvXquzLKVDHM+RsupduE+Mb943YOP6xOat8f1JDdJ8QOYOESNbfPMijg/MbcL5nHysnIVvSOmplQSoSSpw0CsxNipjzVCGooONzOCAxbLcfruWmUwJ56Fbirm0pU29jUNkX0DWvq7y93WJHnybCI4LFOvKknFa+7IJvx9l02nsaprw9tsSTTkM19snSsa73zB8Rnjk5ySOEtkCiJeVYr54iFeY73JKumh4jAffqobN+TRNROunoSCDtl3fJJGAW3fVgI//iQ0w==
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=nfBXF6h9UdzLnnzbqVw3V7gpYaAlMU83olFhqIogFh8=;
 b=EaJ0CpSg/E+zMhX62r58F9CDp/Int16JMKa0AGW1fY6TBu88V2ZhXeT1VFSgIjpxh9IrwxaNSYA89AuCGJRPz99wsi/zT4+kE7f1Ltn/nndXTSNkePE7N8x2969ivoNon1cQT8/xY1tnfbFerCcd9PJ/oPad5Wf06iez5zcy/U8=
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: Ayan Kumar Halder , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" 
Subject: [PATCH v3 1/6] arm/mpu: Introduce MPU memory region map structure
Date: Wed, 11 Jun 2025 15:35:39 +0100
Message-ID: <20250611143544.3453532-2-ayan.kumar.halder@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20250611143544.3453532-1-ayan.kumar.halder@amd.com>
References: <20250611143544.3453532-1-ayan.kumar.halder@amd.com>
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: CH1PEPF0000AD75:EE_|SA5PPFD911547FB:EE_
X-MS-Office365-Filtering-Correlation-Id: d3cef43b-3abd-4458-10ae-08dda8f54d46
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?V7vpSqlwlfGogWefS4DAz5vh5mIyBd4BEeC16iZ4xTbTYo9zuQJCY8L6RTOO?=
 =?us-ascii?Q?lJJ6wfqN2OrL2eDKcAXjiKlN8whRzSMpx7LGLm3leQsR3Jt6UBTHeMFoKkpG?=
 =?us-ascii?Q?ibUXQpFuNbzpg4miwTGs0xv7TueWxYbe6I2br5ifbZQUuMNeSUv3Ytmi2M+t?=
 =?us-ascii?Q?qyxJ3pF2QGC/UaVdb5OQj2hvJfg1SJfo+fm+QD92QxrRrX3sVZjxJZiNqP0x?=
 =?us-ascii?Q?882ywIXALsDh1fMksmhM1FRX2cSWPZnj7MwQz4tfSqbCAgOxjNKkvRKfMshQ?=
 =?us-ascii?Q?tVhlf20BN1V4XAhUhV7/NI4wNoMtG/RqLB1K0HumstR17/kVleITLyP7VY8O?=
 =?us-ascii?Q?y+OaYQRaxYoIUj1IrlUDvEFpNVHOvAVd9mdb7D+YqZg0+wbPaFi+SjBOElW+?=
 =?us-ascii?Q?e4voGxQ/9gNMpC8DI5r53kJi5zsUFBF1lZxljNOKHPEN854u+2dztAvns3v/?=
 =?us-ascii?Q?xjAmo0WSEwvi8m3i6/5d7X2BuQ9YPYY7KLjWVPJLrgJSz3wBXgZobUCkCYyP?=
 =?us-ascii?Q?wQ/xu3WmPCTvRgoBZBgQeV/Jk67DV9X22JNndwBrhNFyox7ePU+eLYdi8xCY?=
 =?us-ascii?Q?hiQSIpC+JqKTN6xR9sf5Y0QTjUHE829VV6Vr0bPSsHIWGjKhLvuN0IGMiIR8?=
 =?us-ascii?Q?n3oh1JdWeLV7kw8ePkxMl4xjXIuxZ1zMatpZrM4igcpx1VMV80pyySCXhqa8?=
 =?us-ascii?Q?5PJlKKgLPxGXm/LhuhaAABTXvpRYzEQcyf3uQQNRVyvtOEFIpPvCfU71u3/w?=
 =?us-ascii?Q?QmMzDWNe6GgTOubO345TXkCXra2HaqoH1Gk1xB4NjXm/jPQk85e91Za2Pmes?=
 =?us-ascii?Q?SC9luRKiXm2Y/a/WIZj2BQA/2QBJDmkYjrq64869g0lrB9fiD4nZjXeSvYca?=
 =?us-ascii?Q?vQ4wj+SiexS3CxTX2c7xOApYTMTfuPVBeMGBSZCVRXBeV2trCsW5OsS5Pout?=
 =?us-ascii?Q?IwYAF6MXH7k2gDcH6jDjIeawCM+3z/2wL7gU+gLaB0kt9kpgYpheGR5cF1z1?=
 =?us-ascii?Q?B9n/SjuU/y4hvGi9DZTiVPkgrXvsuSuRdEphsKaYqmjpuQrLHRGWXuwLQ+Is?=
 =?us-ascii?Q?HIcczlwg5c9f5mcUVscPmse+nUwfecSsqMCy0ESNK2r3K5l+wGU9X3++sshG?=
 =?us-ascii?Q?/Ly37S86Szw+FNAHMv7mK51wHaxYSmoiUJx3D4L0sk2x3lPfZNQxtH1LNo83?=
 =?us-ascii?Q?g4Q7IjJc9u6eY1A8eUOAnEEteAVV7e/d+/8sBI75PkJJiaAgsUVfNa7jzY5+?=
 =?us-ascii?Q?ik5RELilTcMnfqTpAI1j1sBdeuTzVXKIsaF5Ez9YzqNrxU8v1wR8uuN7vezG?=
 =?us-ascii?Q?GV5S5OKYfeMWTvZtZJlMGotokTdUzIjrdtJPjoEVb4wk7dCpj/fBrwM854Kv?=
 =?us-ascii?Q?gBaUjdZrPG2jz29rJXUUgBRICbsDMjB85o+Vl04luAGZiUjbttVWTvzDYR4d?=
 =?us-ascii?Q?CKn2EjBh6979qPi8tv/g13rUqXuFWRRUcSC4o989whgvjJpw1RQfOKiWdeuT?=
 =?us-ascii?Q?htqddCKZDK0UxPhSvZGKYN2K+MOc4APjN/g/?=
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: 11 Jun 2025 14:36:07.2817
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d3cef43b-3abd-4458-10ae-08dda8f54d46
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:
	CH1PEPF0000AD75.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA5PPFD911547FB

Introduce pr_t typedef which is a structure having the prbar and prlar members,
each being structured as the registers of the AArch32 Armv8-R architecture.

Also, define MPU_REGION_RES0 to 0 as there are no reserved 0 bits beyond the
BASE or LIMIT bitfields in prbar or prlar respectively.

In pr_of_addr(), enclose prbar and prlar arm64 specific bitfields with
appropriate macros. So, that this function can be later reused for arm32 as
well.

Signed-off-by: Ayan Kumar Halder 
---
Changes from v1 :-

1. Preserve pr_t typedef in arch specific files.

2. Fix typo.

v2 :-

1. Change CONFIG_ARM64 to CONFIG_ARM_64 to enclose arm64 specific bitfields for
prbar and prlar registers in pr_of_addr().

 xen/arch/arm/include/asm/arm32/mpu.h | 34 ++++++++++++++++++++++++++--
 xen/arch/arm/mpu/mm.c                |  4 ++++
 2 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/include/asm/arm32/mpu.h b/xen/arch/arm/include/asm/arm32/mpu.h
index f0d4d4055c..0a6930b3a0 100644
--- a/xen/arch/arm/include/asm/arm32/mpu.h
+++ b/xen/arch/arm/include/asm/arm32/mpu.h
@@ -5,10 +5,40 @@
 
 #ifndef __ASSEMBLY__
 
+/*
+ * Unlike arm64, there are no reserved 0 bits beyond base and limit bitfield in
+ * prbar and prlar registers respectively.
+ */
+#define MPU_REGION_RES0       0x0
+
+/* Hypervisor Protection Region Base Address Register */
+typedef union {
+    struct {
+        unsigned int xn:1;       /* Execute-Never */
+        unsigned int ap_0:1;     /* Access Permission AP[0] */
+        unsigned int ro:1;       /* Access Permission AP[1] */
+        unsigned int sh:2;       /* Shareability */
+        unsigned int res0:1;
+        unsigned int base:26;    /* Base Address */
+    } reg;
+    uint32_t bits;
+} prbar_t;
+
+/* Hypervisor Protection Region Limit Address Register */
+typedef union {
+    struct {
+        unsigned int en:1;     /* Region enable */
+        unsigned int ai:3;     /* Memory Attribute Index */
+        unsigned int res0:2;
+        unsigned int limit:26; /* Limit Address */
+    } reg;
+    uint32_t bits;
+} prlar_t;
+
 /* MPU Protection Region */
 typedef struct {
-    uint32_t prbar;
-    uint32_t prlar;
+    prbar_t prbar;
+    prlar_t prlar;
 } pr_t;
 
 #endif /* __ASSEMBLY__ */
diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
index 86fbe105af..3d37beab57 100644
--- a/xen/arch/arm/mpu/mm.c
+++ b/xen/arch/arm/mpu/mm.c
@@ -167,7 +167,9 @@ pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags)
     /* Build up value for PRBAR_EL2. */
     prbar = (prbar_t) {
         .reg = {
+#ifdef CONFIG_ARM_64
             .xn_0 = 0,
+#endif
             .xn = PAGE_XN_MASK(flags),
             .ap_0 = 0,
             .ro = PAGE_RO_MASK(flags)
@@ -206,7 +208,9 @@ pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags)
     /* Build up value for PRLAR_EL2. */
     prlar = (prlar_t) {
         .reg = {
+#ifdef CONFIG_ARM_64
             .ns = 0,        /* Hyp mode is in secure world */
+#endif
             .ai = attr_idx,
             .en = 1,        /* Region enabled */
         }};
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 14:36:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 14:36:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011824.1390346 (Exim 4.92)
	(envelope-from )
	id 1uPMZI-0008Il-Cf; Wed, 11 Jun 2025 14:36:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011824.1390346; Wed, 11 Jun 2025 14:36: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 1uPMZI-0008Ie-9J; Wed, 11 Jun 2025 14:36:44 +0000
Received: by outflank-mailman (input) for mailman id 1011824;
 Wed, 11 Jun 2025 14:36: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 1uPMZG-0007cf-Kb
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 14:36:42 +0000
Received: from NAM04-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam04on20615.outbound.protection.outlook.com
 [2a01:111:f403:240a::615])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7c0e25cb-46d1-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 16:36:40 +0200 (CEST)
Received: from BLAPR03CA0079.namprd03.prod.outlook.com (2603:10b6:208:329::24)
 by IA0PR12MB8908.namprd12.prod.outlook.com (2603:10b6:208:48a::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.19; Wed, 11 Jun
 2025 14:36:36 +0000
Received: from BL6PEPF0001AB77.namprd02.prod.outlook.com
 (2603:10b6:208:329:cafe::f0) by BLAPR03CA0079.outlook.office365.com
 (2603:10b6:208:329::24) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.19 via Frontend Transport; Wed,
 11 Jun 2025 14:36:36 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL6PEPF0001AB77.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.8835.15 via Frontend Transport; Wed, 11 Jun 2025 14:36:36 +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, 11 Jun
 2025 09:36:35 -0500
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, 11 Jun 2025 09:36:34 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7c0e25cb-46d1-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Ddg+geFncAx4VkotUy2WS/xAC1G6LGTFn44j9FxXVOvCONgPd8i3hDsxzgUQ72fr+lPUQ8yaaK24JrJP8jkxzJDlwetPFAGPuvMEpqPvDEtQMNpEP/aVfKWxwe1+vXolG220Q3KaunJk4uVB6cVToe7rNj88lURuYPFF3gD7B+sTR+9uV/n/glhGJcghyNeudqXpuDazpCSNfOYul6MNlcIGDESD1X9C5W07Qd8F6Bi40tSRUMeggJxBODdkXrr6gKPaUwlqvYsvhz4S9DFDWl+uN/ye12rjRIe55SVmmxmAN+FT2mUndNB7JH61PiXceY8obWqRw2h6CTqOaYCYCg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=R1+LaD2YpdlFLBfipmeizz0Lx6eHS1RvF/RK7uBnEU4=;
 b=JnYGQINnOO3wtUqP7PDbZVtmTKfJMeEGfNzxhOx4VoUKeY2b4KduZj2QV6abd+uzvVSF4SGWWF5sID+relzju08grVZn+kJTDkCElnAOoHSY/sI32ATg13zjQ8WtGZ/8p/x0bRGJmr6wqJm92FqBCs37jQp752kqLgv+LWmCslhQrZWVGwbbv3LLk70Jm/aUTni3kJRyqabo+MIjhZVMX3yo7ZOLXuYbstA6lH/I2l7U/slO6KDZi8vwYyWKDv/Nvg2w0sbkuNiKOej1+Xj0CAgPPtt+ykGyaYnzldV7u6scpuu5/K9A71/skqQUlUyxh0SLis/z7ZI0jeSgREoX+A==
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=R1+LaD2YpdlFLBfipmeizz0Lx6eHS1RvF/RK7uBnEU4=;
 b=MLCgDQH86qoJG3aM+YYBerZ2HHXZ2PbUDEsOQf8lIy5vOzhfmT72jUn9PWbHquuqm1P89nz3yTDJ4Dk/PQMvaCVpdCcpY/YH2n5EhAH911MgDJirR2d0VpLRIlq22QxDuOqujUIho9uoParXsaoedakoz4kNs+maMIf4ANSWsn8=
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 2/6] arm/mpu: Provide and populate MPU C data structures
Date: Wed, 11 Jun 2025 15:35:40 +0100
Message-ID: <20250611143544.3453532-3-ayan.kumar.halder@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20250611143544.3453532-1-ayan.kumar.halder@amd.com>
References: <20250611143544.3453532-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: BL6PEPF0001AB77:EE_|IA0PR12MB8908:EE_
X-MS-Office365-Filtering-Correlation-Id: ecab66e2-4e85-4a51-1311-08dda8f55e6f
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?o9ssgmLi7j0xCwC5MQFgHkcTU4wft/BgJ7rC3rI8HhtJKsiARgv90RSqUeKr?=
 =?us-ascii?Q?7au/J65g1LkVOtn25tsjTzkmUktwYlHxFZ1NDypxnZK7atfAE2Upb+gck/hI?=
 =?us-ascii?Q?USCXYlz1svswv457+tRI5gvygYEqBQahklapVzdVgUQ6huGclOqt+WPia0e9?=
 =?us-ascii?Q?TWT7McmGxDam/U46YkvOEojM5q8FfW4T0/RPqfnCX0HzqqBQpYk1y8EY0Yvm?=
 =?us-ascii?Q?CLUkjmQdDdXwMEuSJKUMEddABha3cFLm95LVJJsnH27CCvut98fsRCBVP75M?=
 =?us-ascii?Q?hT5Lfp4fSqZeoX9mOia+Q612PH3KLUiyH/aU23ci8IiY0i96w60phVyUCG0j?=
 =?us-ascii?Q?0496d1+nQ3DDBnZmiiU9invGhF34MMuzM+Cyr4lY0fpDWh0cGw4p89NSTg7f?=
 =?us-ascii?Q?BNnKfzWSLgfgK0Ny02anVt9hTo6aPkkApkrxnQDeZ0ESGHJfpFZmYmTu7RLi?=
 =?us-ascii?Q?5WT1lhU3f0bY7FFjK369tblPNdf/X15ZdqJafhyBUfLF6nyAetkiquGtjpuG?=
 =?us-ascii?Q?2zyFqq/M4wEXbf6LqIyMWZUJhcfSVc2XAiXhewK/3ubyhqwZE48/vu6p/Nl3?=
 =?us-ascii?Q?9iMRrd1Qn40B3eq4/Rxl/A4yXQpnSa/Xt4hAFKK9gic4CW2x5CT12q0X6T8j?=
 =?us-ascii?Q?gCk9Z9I1VIr9l7+u4rdsZiMOBtls4P4eQ4V2ohFCDrwiJWZ5wD+BFNVMCvxh?=
 =?us-ascii?Q?Rmh9hh9fXbuXiUBrqRQkVham2WBS3IPs9YtcQrm8bAUolHFQC6ZogWGoWBvd?=
 =?us-ascii?Q?frb7stE9QYjhJq8Cw7i4Ae0VcBeAiOzgMvGmPEb8IuZ1gTak0mYB4q0TOAtk?=
 =?us-ascii?Q?LCupIjAWnrGK+T3KtpemPnK3I3/E41MBEhVXyHhfSTaHyDKPDYzjmG5ejj9B?=
 =?us-ascii?Q?yYs7WT0rZKRmWsBgVzcKBuKQk6eNGrAvHhvzJp4rQ7vxDY4IOdSmb26TZ/fg?=
 =?us-ascii?Q?ngboIt4wpElGCGuclwA9Vt45n2okozTK49o99xVkj+bAtyjuF04in3SkOC7X?=
 =?us-ascii?Q?8EC0u3zHmu+Hpn9ic5KqKR/VkZ/ZEcPNB8hb1t/WZQ4vcq2iOAMmM9i1wdXT?=
 =?us-ascii?Q?AeNJJV8T7kffTUY/EoNmNuoBt7+SfXAUWZNRSz3ZtZceFpUJtBKPSCXenwA/?=
 =?us-ascii?Q?FCOyBGnaqxHAprK7EcSkk+bmGW5K62d0ArYfIg6ZyGlxXbPhZXZLfGDovURh?=
 =?us-ascii?Q?CWZ603oKysGozf4eDudMTVb0sNpVfsv3BmZhGyTS1MzK2CYOv09R1cikZSqA?=
 =?us-ascii?Q?dxdXzuD+rKnv87f9FN5bCjIrBW1MNpPaguVhfyGFa+b4wiFW1UXe3rJ7toHy?=
 =?us-ascii?Q?e9hYnN8bGmt/sL1YS7pcn8c6sug31JFwPrJ4JKrCUhZgSqHHDA7qabNBR/Sr?=
 =?us-ascii?Q?lex27fLGfS1JWEBlcuLA6fS1BMPnQ+iy7UJEe487c9MyN9c5eU3uWRQKzTQn?=
 =?us-ascii?Q?UCmj+lFyLmCD0kBYAiAYtWIv1kXL+9D7bYdWKJJ/cg8ntuqMXp7xP/tywU6H?=
 =?us-ascii?Q?RQJkoQ4ULnHTd/uA1p3dmCAjLJ2M4jV+qmG+?=
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: 11 Jun 2025 14:36:36.0839
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ecab66e2-4e85-4a51-1311-08dda8f55e6f
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:
	BL6PEPF0001AB77.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB8908

Modify Arm32 assembly boot code to reset any unused MPU region, initialise
'max_mpu_regions' with the number of supported MPU regions and set/clear the
bitmap 'xen_mpumap_mask' used to track the enabled regions.

Introduce cache.S to hold arm32 cache related functions.

Use the macro definition for "dcache_line_size" from linux.

Change the order of registers in prepare_xen_region() as 'strd' instruction
is used to store {prbar, prlar} in arm32. Thus, 'prbar' has to be a even
numbered register and 'prlar' is the consecutively ordered register.

Signed-off-by: Ayan Kumar Halder 
---
Changes from v1 :-

1. Introduce cache.S to hold arm32 cache initialization instructions.

2. Use dcache_line_size macro definition from linux.

3. Use mov_w instead of ldr.

4. Use a single stm instruction for 'store_pair' macro definition.

v2 :-

1. Use strd instead of stm.

2. Fix some coding style issues.

 xen/arch/arm/arm32/Makefile              |  1 +
 xen/arch/arm/arm32/asm-offsets.c         |  6 ++++
 xen/arch/arm/arm32/cache.S               | 43 ++++++++++++++++++++++++
 xen/arch/arm/arm32/mpu/head.S            | 41 +++++++++++++++++-----
 xen/arch/arm/include/asm/mpu/regions.inc |  2 +-
 5 files changed, 84 insertions(+), 9 deletions(-)
 create mode 100644 xen/arch/arm/arm32/cache.S

diff --git a/xen/arch/arm/arm32/Makefile b/xen/arch/arm/arm32/Makefile
index 537969d753..531168f58a 100644
--- a/xen/arch/arm/arm32/Makefile
+++ b/xen/arch/arm/arm32/Makefile
@@ -2,6 +2,7 @@ obj-y += lib/
 obj-$(CONFIG_MMU) += mmu/
 obj-$(CONFIG_MPU) += mpu/
 
+obj-y += cache.o
 obj-$(CONFIG_EARLY_PRINTK) += debug.o
 obj-y += domctl.o
 obj-y += domain.o
diff --git a/xen/arch/arm/arm32/asm-offsets.c b/xen/arch/arm/arm32/asm-offsets.c
index 8bbb0f938e..c203ce269d 100644
--- a/xen/arch/arm/arm32/asm-offsets.c
+++ b/xen/arch/arm/arm32/asm-offsets.c
@@ -75,6 +75,12 @@ void __dummy__(void)
 
    OFFSET(INITINFO_stack, struct init_info, stack);
    BLANK();
+
+#ifdef CONFIG_MPU
+   DEFINE(XEN_MPUMAP_MASK_sizeof, sizeof(xen_mpumap_mask));
+   DEFINE(XEN_MPUMAP_sizeof, sizeof(xen_mpumap));
+   BLANK();
+#endif
 }
 
 /*
diff --git a/xen/arch/arm/arm32/cache.S b/xen/arch/arm/arm32/cache.S
new file mode 100644
index 0000000000..b21bc66793
--- /dev/null
+++ b/xen/arch/arm/arm32/cache.S
@@ -0,0 +1,43 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/* Cache maintenance */
+
+#include 
+
+/* dcache_line_size - get the minimum D-cache line size from the CTR register */
+    .macro  dcache_line_size, reg, tmp
+    mrc CP32(\tmp, CTR)             /* read ctr */
+    lsr \tmp, \tmp, #16
+    and \tmp, \tmp, #0xf            /* cache line size encoding */
+    mov \reg, #4                    /* bytes per word */
+    mov \reg, \reg, lsl \tmp        /* actual cache line size */
+    .endm
+
+/*
+ * __invalidate_dcache_area(addr, size)
+ *
+ * Ensure that the data held in the cache for the buffer is invalidated.
+ *
+ * - addr - start address of the buffer
+ * - size - size of the buffer
+ *
+ * Clobbers r0 - r3
+ */
+FUNC(__invalidate_dcache_area)
+    dcache_line_size r2, r3
+    add   r1, r0, r1
+    sub   r3, r2, #1
+    bic   r0, r0, r3
+1:  mcr   CP32(r0, DCIMVAC)     /* invalidate D line / unified line */
+    add   r0, r0, r2
+    cmp   r0, r1
+    blo   1b
+    dsb   sy
+    ret
+END(__invalidate_dcache_area)
+
+/*
+ * Local variables:
+ * mode: ASM
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/arm32/mpu/head.S b/xen/arch/arm/arm32/mpu/head.S
index b2c5245e51..6a631626a7 100644
--- a/xen/arch/arm/arm32/mpu/head.S
+++ b/xen/arch/arm/arm32/mpu/head.S
@@ -46,43 +46,68 @@ END(enable_mpu)
  */
 FUNC(enable_boot_cpu_mm)
     /* Get the number of regions specified in MPUIR_EL2 */
-    mrc   CP32(r5, MPUIR_EL2)
-    and   r5, r5, #NUM_MPU_REGIONS_MASK
+    mrc   CP32(r3, MPUIR_EL2)
+    and   r3, r3, #NUM_MPU_REGIONS_MASK
+
+    mov_w   r0, max_mpu_regions
+    str   r3, [r0]
+    mcr   CP32(r0, DCIMVAC) /* Invalidate cache for max_mpu_regions addr */
 
     /* x0: region sel */
     mov   r0, #0
     /* Xen text section. */
     mov_w   r1, _stext
     mov_w   r2, _etext
-    prepare_xen_region r0, r1, r2, r3, r4, r5, attr_prbar=REGION_TEXT_PRBAR
+    prepare_xen_region r0, r1, r2, r4, r5, r3, attr_prbar=REGION_TEXT_PRBAR
 
     /* Xen read-only data section. */
     mov_w   r1, _srodata
     mov_w   r2, _erodata
-    prepare_xen_region r0, r1, r2, r3, r4, r5, attr_prbar=REGION_RO_PRBAR
+    prepare_xen_region r0, r1, r2, r4, r5, r3, attr_prbar=REGION_RO_PRBAR
 
     /* Xen read-only after init and data section. (RW data) */
     mov_w   r1, __ro_after_init_start
     mov_w   r2, __init_begin
-    prepare_xen_region r0, r1, r2, r3, r4, r5
+    prepare_xen_region r0, r1, r2, r4, r5, r3
 
     /* Xen code section. */
     mov_w   r1, __init_begin
     mov_w   r2, __init_data_begin
-    prepare_xen_region r0, r1, r2, r3, r4, r5, attr_prbar=REGION_TEXT_PRBAR
+    prepare_xen_region r0, r1, r2, r4, r5, r3, attr_prbar=REGION_TEXT_PRBAR
 
     /* Xen data and BSS section. */
     mov_w   r1, __init_data_begin
     mov_w   r2, __bss_end
-    prepare_xen_region r0, r1, r2, r3, r4, r5
+    prepare_xen_region r0, r1, r2, r4, r5, r3
 
 #ifdef CONFIG_EARLY_PRINTK
     /* Xen early UART section. */
     mov_w   r1, CONFIG_EARLY_UART_BASE_ADDRESS
     mov_w   r2, (CONFIG_EARLY_UART_BASE_ADDRESS + CONFIG_EARLY_UART_SIZE)
-    prepare_xen_region r0, r1, r2, r3, r4, r5, attr_prbar=REGION_DEVICE_PRBAR, attr_prlar=REGION_DEVICE_PRLAR
+    prepare_xen_region r0, r1, r2, r4, r5, r3, attr_prbar=REGION_DEVICE_PRBAR, attr_prlar=REGION_DEVICE_PRLAR
 #endif
 
+zero_mpu:
+    /* Reset remaining MPU regions */
+    cmp   r0, r3
+    beq   out_zero_mpu
+    mov   r1, #0
+    mov   r2, #1
+    prepare_xen_region r0, r1, r2, r4, r5, r3, attr_prlar=REGION_DISABLED_PRLAR
+    b     zero_mpu
+
+out_zero_mpu:
+    /* Invalidate data cache for MPU data structures */
+    mov r4, lr
+    mov_w r0, xen_mpumap_mask
+    mov r1, #XEN_MPUMAP_MASK_sizeof
+    bl __invalidate_dcache_area
+
+    ldr r0, =xen_mpumap
+    mov r1, #XEN_MPUMAP_sizeof
+    bl __invalidate_dcache_area
+    mov lr, r4
+
     b    enable_mpu
 END(enable_boot_cpu_mm)
 
diff --git a/xen/arch/arm/include/asm/mpu/regions.inc b/xen/arch/arm/include/asm/mpu/regions.inc
index 6b8c233e6c..23fead3b21 100644
--- a/xen/arch/arm/include/asm/mpu/regions.inc
+++ b/xen/arch/arm/include/asm/mpu/regions.inc
@@ -24,7 +24,7 @@
 #define XEN_MPUMAP_ENTRY_SHIFT  0x3     /* 8 byte structure */
 
 .macro store_pair reg1, reg2, dst
-    .word 0xe7f000f0                    /* unimplemented */
+    strd  \reg1, \reg2, [\dst]
 .endm
 
 #endif
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 14:36:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 14:36:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011828.1390357 (Exim 4.92)
	(envelope-from )
	id 1uPMZP-00008u-Ka; Wed, 11 Jun 2025 14:36:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011828.1390357; Wed, 11 Jun 2025 14:36:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPMZP-00008h-FB; Wed, 11 Jun 2025 14:36:51 +0000
Received: by outflank-mailman (input) for mailman id 1011828;
 Wed, 11 Jun 2025 14:36: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 1uPMZO-0007IS-0I
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 14:36:50 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on2061d.outbound.protection.outlook.com
 [2a01:111:f403:2414::61d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 81554b26-46d1-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 16:36:49 +0200 (CEST)
Received: from MN2PR08CA0029.namprd08.prod.outlook.com (2603:10b6:208:239::34)
 by CH1PR12MB9624.namprd12.prod.outlook.com (2603:10b6:610:2b3::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.19; Wed, 11 Jun
 2025 14:36:43 +0000
Received: from BL6PEPF0001AB52.namprd02.prod.outlook.com
 (2603:10b6:208:239:cafe::65) by MN2PR08CA0029.outlook.office365.com
 (2603:10b6:208:239::34) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.35 via Frontend Transport; Wed,
 11 Jun 2025 14:36:43 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BL6PEPF0001AB52.mail.protection.outlook.com (10.167.241.4) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Wed, 11 Jun 2025 14:36:42 +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, 11 Jun
 2025 09:36:42 -0500
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, 11 Jun 2025 09:36:41 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 81554b26-46d1-11f0-a307-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=d9vHTyGKFQ/ndJzA76oLJSGsAugqh0G20DptYAQwivCAM9NddeM2EzKZhQnLWLOVG5TpjE0SVzH/SFLvuhsmaC6u5Isg3Qd6IuzeRxFNOgvYcHUpLARBKHZuomD27lSMwzv7Dae53l83lo0Ta8ZyYuEjCmReH/VrWPoU6gOMNZrQuPCM7EABLXMgWJrfxtN8E7c8+ngb+N/4AVAHUZkvqigsT9bcWqaZpxe6c6z+VCW/X6IcNjcMqXkA056dap+Fkf21+/KY+D5Pk8/NAPbOPv54Rvx8gbpdKKR/bLKAF7v0lb1R5NG2T5Ns5pZaLxRwaxDARqfYn1JPM9OqoTJglw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=x/H9MESwJREpyi29D9fh/4pN64Tv8g3m4E/vnLHEsHQ=;
 b=edegU2FoHfR5WYz0h2PQ79Qrg/I9QJw98peM3VKW4wvbOgqZYkHkvCR820kJUFTpRlo0AS2nZjV5bA9siaNb0IasxsfSUGCtLW7N4VV/CGMStczwSsYRLmO2ZWGes8O9TOrHDFU1qpciVWt1af3jpMojvF1CGlBH/zjxjggEWqlTJunniUjVAQjZHPNF/4sQBcT4SSBeCGD4WD92NkqLNzgQDAmXAEFoixd3eRIKWeMdtqWg0mAhJlwCK0UTf37/JN5QDqj40EQ2TwMqkTzP818NKcq6ngaZS7u6VHGwfGdnL4PBPKTR0ZJBGHwVTWHoJFcCfSwdhaRMvU6l03XcGw==
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=x/H9MESwJREpyi29D9fh/4pN64Tv8g3m4E/vnLHEsHQ=;
 b=ua+o8EdEW2ci0w+w/UCBbOjMMPxAmBcCA8ILpihKWV2Qz4/uDzmR1WlPMBxDT2t7dIzHpMcOO1oe99WAX74nFFqFQJeJDcJEInHnXsdo0GGw7R8JmYkWGYINIJV3z1oB1wQzz7uq/IHu9R/bN77qU27ch+1Q02vugSi700vSTLA=
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: Ayan Kumar Halder , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" 
Subject: [PATCH v3 3/6] arm/mpu: Move domain-page.c to arm32 specific dir
Date: Wed, 11 Jun 2025 15:35:41 +0100
Message-ID: <20250611143544.3453532-4-ayan.kumar.halder@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20250611143544.3453532-1-ayan.kumar.halder@amd.com>
References: <20250611143544.3453532-1-ayan.kumar.halder@amd.com>
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: BL6PEPF0001AB52:EE_|CH1PR12MB9624:EE_
X-MS-Office365-Filtering-Correlation-Id: 1e6445f3-62a3-4b00-6a8f-08dda8f5626a
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?9hZ1Vm6m/AI+AXfI9HjX/nVbY+BsbYySnB+5aVXjCoYh+nujJHOxJIdCF6p7?=
 =?us-ascii?Q?KH/2vMHZ6l5VmWgvmu4D+SEpB+eC0A5qVZ5PYxDHmVEGAzg2FJpHA18rrcbL?=
 =?us-ascii?Q?I1JJh/SwcMaZ7FARGIQq0v+c+0ETZk/xqL8jfdb461g9m2DbgljIEavwWupP?=
 =?us-ascii?Q?/w7q1hUL9vamrt1Y5DDVvUzxomuHMcOLXDfUB7mdR63YvJVQrONdkwjvz7A/?=
 =?us-ascii?Q?B6q1EdS9ql0KndpPRJ4ZqFbWrkdEknDql44bJ0eQtDpSksM1iu193K8KtWCE?=
 =?us-ascii?Q?Hkl1DCCd7XTCSJbMFWDptz2jVsY3ar+WYvWVGG/Z2Tm4bEm6tc5AcyPJWfxn?=
 =?us-ascii?Q?JUv2a3YcRW61Nqibn3aAmTmk4cddISM8/Lfb0wzD9RKtjyIh37L1k2k4mNBv?=
 =?us-ascii?Q?yXAXncAQm0RVxql3u3GHlAJzenW6dHCj0QA6Qh0alr+PSkqXBzcWY4FoVw8R?=
 =?us-ascii?Q?UhY+C5sLVF9QnVb43XRpwvmOUQtgUPiaRBou3z2YdnrvciFJgCR0UO8xofbs?=
 =?us-ascii?Q?ZT4ReBo7mBzvISAF0Vd+sq4oulc5ircRnqx6Asj0s5bNwkFig0kSmpqEecMy?=
 =?us-ascii?Q?ovy2ojoBo/sfJL/VhVux+9hpVPnwkAz7EUTe2ec9/Rj2qujKuWpM6B43nQCV?=
 =?us-ascii?Q?Kk590aBbHKMHntA8+uyL3JyIktqvVuMJ44bzBHq+G/z9uMr5nMh9xTPcavRr?=
 =?us-ascii?Q?eHsIHwZotwPJ026YbEiE68mH+cEL2icvtG9uSvesjAxLE/Jj+eQK4mbzBSw0?=
 =?us-ascii?Q?A2CkeUWVqehlJ0fo6gno9zVGFUmJNN5ZoDD/hwg0uHioSXjdau+zdzrgc8ai?=
 =?us-ascii?Q?yzL1XlTV16XWLyVtk9p1EwTwBBjh14YP48CC/RbqDbCHpw8hV1Pmfe0DSfsZ?=
 =?us-ascii?Q?H00TABXKi6GDyDXQWHfUl/VlhbxprWi/z9e6RsjpLC6ZtdgByioeOdeVzrWi?=
 =?us-ascii?Q?AH7U2t/XgJOswLMyrN/SAnLXpK762dnybPLRhcNWu6iexw2isuwNOb4ejSfS?=
 =?us-ascii?Q?nADV3pPCTb2mb/jZ37NEmH3BTeFow9hhEXD6TGjKKVUoXeNpMUJXnprL3j0x?=
 =?us-ascii?Q?MLpg/GHHYsf0EexENgFKMs8H2CubqMWD8s+pK/fZQIBY/i/6gpCqCFgSledy?=
 =?us-ascii?Q?tAuWXgxAFRHwJgtNgr+ZdPXUWGvVCbrMShQnl5XT2x/ezqtUSjYsyxYqFIC2?=
 =?us-ascii?Q?mBulHOzNM6OgT+Q0DNfWQ3SO+hdlz6S5zU/IsSWU2NVee8j+Nypi7RNFhq4X?=
 =?us-ascii?Q?1Ni5lQADavPwDhWWGorkmlbhlgFBi8xHGMQ+Bm55wpjo4gdo3aeTvb7c5tlS?=
 =?us-ascii?Q?jYVNivFQ6JucYBTOjkwOK0Q1p8rqMgzZtXHQSr7PLJV9eUROO1yruWnxnzKS?=
 =?us-ascii?Q?k7rGdUWnvVfXEF98FAxa7auyijsXFhszNYWjochdVJ+Kg6o9BjcgSiVrJsgJ?=
 =?us-ascii?Q?OoIvKjum+urkRiXdIg7SqHmEkK1YrWlEWGCQQgKvxemDnu6npL+Kx21AlHqN?=
 =?us-ascii?Q?mhYU7jim8tNbA85LKlA8O2iC4pEqiQjVvOlL?=
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: 11 Jun 2025 14:36:42.7635
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1e6445f3-62a3-4b00-6a8f-08dda8f5626a
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:
	BL6PEPF0001AB52.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH1PR12MB9624

Create xen/arch/arm/mpu/arm32 to hold arm32 specific bits.

Signed-off-by: Ayan Kumar Halder 
---
Changes from :-

v1..v2 - New patch in v3.

 xen/arch/arm/mpu/Makefile                  | 2 +-
 xen/arch/arm/mpu/arm32/Makefile            | 1 +
 xen/arch/arm/mpu/{ => arm32}/domain-page.c | 0
 3 files changed, 2 insertions(+), 1 deletion(-)
 create mode 100644 xen/arch/arm/mpu/arm32/Makefile
 rename xen/arch/arm/mpu/{ => arm32}/domain-page.c (100%)

diff --git a/xen/arch/arm/mpu/Makefile b/xen/arch/arm/mpu/Makefile
index 808e3e2cb3..9359d79332 100644
--- a/xen/arch/arm/mpu/Makefile
+++ b/xen/arch/arm/mpu/Makefile
@@ -1,4 +1,4 @@
-obj-$(CONFIG_ARM_32) += domain-page.o
+obj-$(CONFIG_ARM_32) += arm32/
 obj-y += mm.o
 obj-y += p2m.o
 obj-y += setup.init.o
diff --git a/xen/arch/arm/mpu/arm32/Makefile b/xen/arch/arm/mpu/arm32/Makefile
new file mode 100644
index 0000000000..e15ce2f7be
--- /dev/null
+++ b/xen/arch/arm/mpu/arm32/Makefile
@@ -0,0 +1 @@
+obj-y += domain-page.o
diff --git a/xen/arch/arm/mpu/domain-page.c b/xen/arch/arm/mpu/arm32/domain-page.c
similarity index 100%
rename from xen/arch/arm/mpu/domain-page.c
rename to xen/arch/arm/mpu/arm32/domain-page.c
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 14:37:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 14:37:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011840.1390366 (Exim 4.92)
	(envelope-from )
	id 1uPMZy-0000v8-2I; Wed, 11 Jun 2025 14:37:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011840.1390366; Wed, 11 Jun 2025 14:37:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPMZx-0000uz-VO; Wed, 11 Jun 2025 14:37:25 +0000
Received: by outflank-mailman (input) for mailman id 1011840;
 Wed, 11 Jun 2025 14:37: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 1uPMZx-0007IS-6H
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 14:37:25 +0000
Received: from NAM04-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam04on2061a.outbound.protection.outlook.com
 [2a01:111:f403:240a::61a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 95c9c05b-46d1-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 16:37:24 +0200 (CEST)
Received: from BN9PR03CA0480.namprd03.prod.outlook.com (2603:10b6:408:139::35)
 by BL1PR12MB5993.namprd12.prod.outlook.com (2603:10b6:208:399::9)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.36; Wed, 11 Jun
 2025 14:37:20 +0000
Received: from BL6PEPF0001AB73.namprd02.prod.outlook.com
 (2603:10b6:408:139:cafe::8c) by BN9PR03CA0480.outlook.office365.com
 (2603:10b6:408:139::35) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.19 via Frontend Transport; Wed,
 11 Jun 2025 14:37:20 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL6PEPF0001AB73.mail.protection.outlook.com (10.167.242.166) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Wed, 11 Jun 2025 14:37:19 +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, 11 Jun
 2025 09:37:19 -0500
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, 11 Jun 2025 09:37:18 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 95c9c05b-46d1-11f0-a307-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=MMIkrm1mSHr/YHxUNveekXTHzCsECPXjR7lnYKwf+Qu664/j+TFFj/821Qttk4dIbB7x+YwGAfsdcbkeaM9NkcASP43bPdwgo9uH6qO/Tq6pHEiJbQZIvRW3syCiek4kv7h3p9DYYXh0ZR0FXjwRjMVGz5r5ifb9Fd577UwvE4l+BFvkGirhivphgxoZtCRzJQVYM0r7iJU492oaG6xzZTQF6Ng9mmZ0oBS6loTfpXevXjSinzMtoBrDlJ/SLckht+i9WTJGM0mneBpgBFgYFW8PB5W8W+cv2Ax9kJS9r8sGMSXjl2rVg+W6tYFQlUMhutgYhwekJY0MudDGOzHvfQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=EDvGQBOm5SJaxPp+iQKpPd7Mnxt0kUlWkXnfTAWHga4=;
 b=w4AM9evQOjCt9VjujaegSOsla0hRWkuaS3Vz/IcUabR5dJNDzC6MlTQOW3iWlDI+VdO5w5Y/ZTkSiyOu38vS5e5TdayhiQivtvtk+Rj907Ekh8HqYYFOor6isDKUpMGcaYXvIf4y142tX2kwUyXC1lF25XeDyVgj6LYok1kYuTCbsbgxb7Gl2SEgylTT+75B7/6eCDIXplCkq3Xdh4EYQYsSLUh4RAqDzuID70Uxy4nTEHHIzqKFwSnL+iq0WmhIRxzYFm8Zorpc6N9niieOSfELKSZ78hlzqx6T6yjnMJNWrg/UBKwVEb6kpsPrKIYs+fTrIvD+c0q1aGdmpqdGGg==
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=EDvGQBOm5SJaxPp+iQKpPd7Mnxt0kUlWkXnfTAWHga4=;
 b=04OZJ15+j8/VEqE6+LHSHDWEUl2cg+AfIggsDUqROZmIxl2aq+AnsP2qEPyh51BfhYdgjq7WxZ3ICONnAk7v0Z3FxpksaS56M7+ujUVDg4NDcliPMxjFKsRf4B9bnyYPxxZqxmOmoz1sfI2Vby5Nq/jPWC+r1FyrCL6N1fOF3vg=
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 4/6] arm/mpu: Move the functions to arm64 specific files
Date: Wed, 11 Jun 2025 15:35:42 +0100
Message-ID: <20250611143544.3453532-5-ayan.kumar.halder@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20250611143544.3453532-1-ayan.kumar.halder@amd.com>
References: <20250611143544.3453532-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: BL6PEPF0001AB73:EE_|BL1PR12MB5993:EE_
X-MS-Office365-Filtering-Correlation-Id: 7900458d-8c6f-499b-477b-08dda8f5787c
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?ekB2zLJjQ6KFl7MY7dFzTrtv71x+QRvKCXpjWCrVFQ2VZrscRhPLGc9fbUBl?=
 =?us-ascii?Q?HbWG2bBQS8U1/ZousyNe3Jduo4wHoACpvn/uFbcJY4lOltoWTIkqVoI754Se?=
 =?us-ascii?Q?iHzjnIDFSpO1crqN9C6ajfRRB/MxW/wgB8qGghR6t3RpnBL2GVT4XOim+Wx/?=
 =?us-ascii?Q?NH3FiTjra/DgbrQgtsKA+AcxLJswP0ER2A5wNWniB4NhYCmvLZIvN38C8JJV?=
 =?us-ascii?Q?8VQx4F+goj71EW0/sxB6Im5Cc4lkZbe+2g7cx8aCNPWAFCqpkDff3loTLZ86?=
 =?us-ascii?Q?oy4LwOPEKZXgM4sOutCsC2pjMg/d9kkgrLHn8uzLj25ky/8efFclJcL4RziU?=
 =?us-ascii?Q?Hk8kLo/FgxS6Nw6FyIX2G5SLqLLsYtZRr0+h0gDWVSxud0zeVWwy/JhvbAYJ?=
 =?us-ascii?Q?5ttWFc/fZUOuxE28aYcdd/G1qN0JX4+qycw+qIexV++v9qH9TMtWy9Qn8KoL?=
 =?us-ascii?Q?YdMFyJN+EI2P7uZzpUy7KIfFDLB7shHLkssXG/R1whSsOWZloGuhO3fg9Xeo?=
 =?us-ascii?Q?z9pUExUhu+6iSk6tjq91BJPybWl/oAznYcQuOlNbgoC3ll68FdFG1Ecl6RH2?=
 =?us-ascii?Q?LCJVZirJePzxb89ltBqjtlSkAURvjdetE98mkGg9+e29iWKUFrQvii9TuI8k?=
 =?us-ascii?Q?PP2hLxgaTSYpNr6Nad5r200LfVjmAHmOiAcop4YK/8MDEsoqMpqmk5041soF?=
 =?us-ascii?Q?ykyudzT8vUg4jaonnaTdyNZUhoOIZn5hdHNtmOvoFe5X3uyFcfavrKe3bkU6?=
 =?us-ascii?Q?sGDjUM3otB7wCtfyoMwwMfYj4wageraRfvPXFCh77CQhAXIc7+/WtaOKq6Y4?=
 =?us-ascii?Q?QI+4QBpUOwvFLRHS5Zcio+lhgWYS3Qv8qWojiCldMfRCvyzGPAthTpwGxgwF?=
 =?us-ascii?Q?mepVg7+XO4qC1cC3I/epFUQNo6vw4Py/0ea1yiS3lTvJ1kJU3eAIV+LLqg2X?=
 =?us-ascii?Q?xgM5/SCK5Q9pwT3lj99dcRWxTji4jrvQos6fdECY8UNvi/Aiqf0hL3ZrnQ81?=
 =?us-ascii?Q?JRJxjPvqWZmVr+BduNg69JIYRnKAMZ/Bsx1bYWu+d6wCFdvSRjmQw4SFm39H?=
 =?us-ascii?Q?rmXDr4eyL2+ttevjdWhK2RX9+Orv6E99x+SdRoVxnqGqDjBvFsc/e1uPODea?=
 =?us-ascii?Q?W8QIJ4FaeVQva56dr43nFEyYY0LkwyTFgQt2hkdkmJfZVGUIcJafefALxyXa?=
 =?us-ascii?Q?7YpLsVLmyGb+qvNz5Q94aW3KxoI9wMKEN44JPtLmLVCpJvWqCXQUFEwYFxB+?=
 =?us-ascii?Q?gN74Y2VizJ5Gs+QAOtBBC8T0SL9G+bCJIYieoIO9TrhZGPPamJ6brt2s+gbq?=
 =?us-ascii?Q?qRdFVlNtAyO2npXNWsesgiABsVzJ5cLv1q+Bm3A5SnkMVKuqBBUZvf+NUpcV?=
 =?us-ascii?Q?0TYhjV59KYcaMhq2/zZ5TVWlDCbN1x6iNsj9KiWAa2e4UPkHARUDw1eQDo1v?=
 =?us-ascii?Q?iHycJw0OyH1UKDYB4IBlnPfE78sXCnsfc2YtWmDJu4RJIhOiSVvUVJJ5avD/?=
 =?us-ascii?Q?S+04tcP6SOluXYdQebmq3PK5YmW18kz/vom6?=
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: 11 Jun 2025 14:37:19.7900
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7900458d-8c6f-499b-477b-08dda8f5787c
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:
	BL6PEPF0001AB73.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR12MB5993

prepare_selector(), read_protection_region() and write_protection_region()
differ significantly between arm32 and arm64. Thus, move these functions
to their specific folders.

GENERATE_{WRITE/READ}_PR_REG_CASE are duplicated for arm32 and arm64 so
as to improve the code readability.

Signed-off-by: Ayan Kumar Halder 
---
Changes from -

v1..v2 - New patch introduced in v3.

 xen/arch/arm/mpu/Makefile       |   1 +
 xen/arch/arm/mpu/arm64/Makefile |   1 +
 xen/arch/arm/mpu/arm64/mm.c     | 130 ++++++++++++++++++++++++++++++++
 xen/arch/arm/mpu/mm.c           | 117 ----------------------------
 4 files changed, 132 insertions(+), 117 deletions(-)
 create mode 100644 xen/arch/arm/mpu/arm64/Makefile
 create mode 100644 xen/arch/arm/mpu/arm64/mm.c

diff --git a/xen/arch/arm/mpu/Makefile b/xen/arch/arm/mpu/Makefile
index 9359d79332..4963c8b550 100644
--- a/xen/arch/arm/mpu/Makefile
+++ b/xen/arch/arm/mpu/Makefile
@@ -1,4 +1,5 @@
 obj-$(CONFIG_ARM_32) += arm32/
+obj-$(CONFIG_ARM_64) += arm64/
 obj-y += mm.o
 obj-y += p2m.o
 obj-y += setup.init.o
diff --git a/xen/arch/arm/mpu/arm64/Makefile b/xen/arch/arm/mpu/arm64/Makefile
new file mode 100644
index 0000000000..b18cec4836
--- /dev/null
+++ b/xen/arch/arm/mpu/arm64/Makefile
@@ -0,0 +1 @@
+obj-y += mm.o
diff --git a/xen/arch/arm/mpu/arm64/mm.c b/xen/arch/arm/mpu/arm64/mm.c
new file mode 100644
index 0000000000..a978c1fc6e
--- /dev/null
+++ b/xen/arch/arm/mpu/arm64/mm.c
@@ -0,0 +1,130 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * The following are needed for the cases: GENERATE_WRITE_PR_REG_CASE
+ * and GENERATE_READ_PR_REG_CASE with num==0
+ */
+#define PRBAR0_EL2 PRBAR_EL2
+#define PRLAR0_EL2 PRLAR_EL2
+
+#define PRBAR_EL2_(n)   PRBAR##n##_EL2
+#define PRLAR_EL2_(n)   PRLAR##n##_EL2
+
+#define GENERATE_WRITE_PR_REG_CASE(num, pr)                                 \
+    case num:                                                               \
+    {                                                                       \
+        WRITE_SYSREG(pr->prbar.bits & ~MPU_REGION_RES0, PRBAR_EL2_(num));   \
+        WRITE_SYSREG(pr->prlar.bits & ~MPU_REGION_RES0, PRLAR_EL2_(num));   \
+        break;                                                              \
+    }
+
+#define GENERATE_READ_PR_REG_CASE(num, pr)                      \
+    case num:                                                   \
+    {                                                           \
+        pr->prbar.bits = READ_SYSREG(PRBAR_EL2_(num));          \
+        pr->prlar.bits = READ_SYSREG(PRLAR_EL2_(num));          \
+        break;                                                  \
+    }
+
+/*
+ * Armv8-R supports direct access and indirect access to the MPU regions through
+ * registers:
+ *  - indirect access involves changing the MPU region selector, issuing an isb
+ *    barrier and accessing the selected region through specific registers
+ *  - direct access involves accessing specific registers that point to
+ *    specific MPU regions, without changing the selector, avoiding the use of
+ *    a barrier.
+ * For Arm64 the PR{B,L}AR_ELx (for n=0) and PR{B,L}AR_ELx (for n=1..15) are
+ * used for the direct access to the regions selected by
+ * PRSELR_EL2.REGION<7:4>:n, so 16 regions can be directly accessed when the
+ * selector is a multiple of 16, giving access to all the supported memory
+ * regions.
+ */
+static void prepare_selector(uint8_t *sel)
+{
+    uint8_t cur_sel = *sel;
+
+    /*
+     * {read,write}_protection_region works using the direct access to the 0..15
+     * regions, so in order to save the isb() overhead, change the PRSELR_EL2
+     * only when needed, so when the upper 4 bits of the selector will change.
+     */
+    cur_sel &= 0xF0U;
+    if ( READ_SYSREG(PRSELR_EL2) != cur_sel )
+    {
+        WRITE_SYSREG(cur_sel, PRSELR_EL2);
+        isb();
+    }
+    *sel = *sel & 0xFU;
+}
+
+void read_protection_region(pr_t *pr_read, uint8_t sel)
+{
+    prepare_selector(&sel);
+
+    switch ( sel )
+    {
+        GENERATE_READ_PR_REG_CASE(0, pr_read);
+        GENERATE_READ_PR_REG_CASE(1, pr_read);
+        GENERATE_READ_PR_REG_CASE(2, pr_read);
+        GENERATE_READ_PR_REG_CASE(3, pr_read);
+        GENERATE_READ_PR_REG_CASE(4, pr_read);
+        GENERATE_READ_PR_REG_CASE(5, pr_read);
+        GENERATE_READ_PR_REG_CASE(6, pr_read);
+        GENERATE_READ_PR_REG_CASE(7, pr_read);
+        GENERATE_READ_PR_REG_CASE(8, pr_read);
+        GENERATE_READ_PR_REG_CASE(9, pr_read);
+        GENERATE_READ_PR_REG_CASE(10, pr_read);
+        GENERATE_READ_PR_REG_CASE(11, pr_read);
+        GENERATE_READ_PR_REG_CASE(12, pr_read);
+        GENERATE_READ_PR_REG_CASE(13, pr_read);
+        GENERATE_READ_PR_REG_CASE(14, pr_read);
+        GENERATE_READ_PR_REG_CASE(15, pr_read);
+    default:
+        BUG(); /* Can't happen */
+        break;
+    }
+}
+
+void write_protection_region(const pr_t *pr_write, uint8_t sel)
+{
+    prepare_selector(&sel);
+
+    switch ( sel )
+    {
+        GENERATE_WRITE_PR_REG_CASE(0, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(1, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(2, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(3, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(4, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(5, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(6, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(7, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(8, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(9, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(10, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(11, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(12, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(13, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(14, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(15, pr_write);
+    default:
+        BUG(); /* Can't happen */
+        break;
+    }
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
index 3d37beab57..7ab68fc8c7 100644
--- a/xen/arch/arm/mpu/mm.c
+++ b/xen/arch/arm/mpu/mm.c
@@ -29,35 +29,6 @@ DECLARE_BITMAP(xen_mpumap_mask, MAX_MPU_REGION_NR) \
 /* EL2 Xen MPU memory region mapping table. */
 pr_t __cacheline_aligned __section(".data") xen_mpumap[MAX_MPU_REGION_NR];
 
-#ifdef CONFIG_ARM_64
-/*
- * The following are needed for the cases: GENERATE_WRITE_PR_REG_CASE
- * and GENERATE_READ_PR_REG_CASE with num==0
- */
-#define PRBAR0_EL2 PRBAR_EL2
-#define PRLAR0_EL2 PRLAR_EL2
-
-#define PRBAR_EL2_(n)   PRBAR##n##_EL2
-#define PRLAR_EL2_(n)   PRLAR##n##_EL2
-
-#endif /* CONFIG_ARM_64 */
-
-#define GENERATE_WRITE_PR_REG_CASE(num, pr)                                 \
-    case num:                                                               \
-    {                                                                       \
-        WRITE_SYSREG(pr->prbar.bits & ~MPU_REGION_RES0, PRBAR_EL2_(num));   \
-        WRITE_SYSREG(pr->prlar.bits & ~MPU_REGION_RES0, PRLAR_EL2_(num));   \
-        break;                                                              \
-    }
-
-#define GENERATE_READ_PR_REG_CASE(num, pr)                      \
-    case num:                                                   \
-    {                                                           \
-        pr->prbar.bits = READ_SYSREG(PRBAR_EL2_(num));          \
-        pr->prlar.bits = READ_SYSREG(PRLAR_EL2_(num));          \
-        break;                                                  \
-    }
-
 static void __init __maybe_unused build_assertions(void)
 {
     /*
@@ -69,94 +40,6 @@ static void __init __maybe_unused build_assertions(void)
 }
 
 #ifdef CONFIG_ARM_64
-/*
- * Armv8-R supports direct access and indirect access to the MPU regions through
- * registers:
- *  - indirect access involves changing the MPU region selector, issuing an isb
- *    barrier and accessing the selected region through specific registers
- *  - direct access involves accessing specific registers that point to
- *    specific MPU regions, without changing the selector, avoiding the use of
- *    a barrier.
- * For Arm64 the PR{B,L}AR_ELx (for n=0) and PR{B,L}AR_ELx (for n=1..15) are
- * used for the direct access to the regions selected by
- * PRSELR_EL2.REGION<7:4>:n, so 16 regions can be directly accessed when the
- * selector is a multiple of 16, giving access to all the supported memory
- * regions.
- */
-static void prepare_selector(uint8_t *sel)
-{
-    uint8_t cur_sel = *sel;
-
-    /*
-     * {read,write}_protection_region works using the direct access to the 0..15
-     * regions, so in order to save the isb() overhead, change the PRSELR_EL2
-     * only when needed, so when the upper 4 bits of the selector will change.
-     */
-    cur_sel &= 0xF0U;
-    if ( READ_SYSREG(PRSELR_EL2) != cur_sel )
-    {
-        WRITE_SYSREG(cur_sel, PRSELR_EL2);
-        isb();
-    }
-    *sel &= 0xFU;
-}
-
-void read_protection_region(pr_t *pr_read, uint8_t sel)
-{
-    prepare_selector(&sel);
-
-    switch ( sel )
-    {
-        GENERATE_READ_PR_REG_CASE(0, pr_read);
-        GENERATE_READ_PR_REG_CASE(1, pr_read);
-        GENERATE_READ_PR_REG_CASE(2, pr_read);
-        GENERATE_READ_PR_REG_CASE(3, pr_read);
-        GENERATE_READ_PR_REG_CASE(4, pr_read);
-        GENERATE_READ_PR_REG_CASE(5, pr_read);
-        GENERATE_READ_PR_REG_CASE(6, pr_read);
-        GENERATE_READ_PR_REG_CASE(7, pr_read);
-        GENERATE_READ_PR_REG_CASE(8, pr_read);
-        GENERATE_READ_PR_REG_CASE(9, pr_read);
-        GENERATE_READ_PR_REG_CASE(10, pr_read);
-        GENERATE_READ_PR_REG_CASE(11, pr_read);
-        GENERATE_READ_PR_REG_CASE(12, pr_read);
-        GENERATE_READ_PR_REG_CASE(13, pr_read);
-        GENERATE_READ_PR_REG_CASE(14, pr_read);
-        GENERATE_READ_PR_REG_CASE(15, pr_read);
-    default:
-        BUG(); /* Can't happen */
-        break;
-    }
-}
-
-void write_protection_region(const pr_t *pr_write, uint8_t sel)
-{
-    prepare_selector(&sel);
-
-    switch ( sel )
-    {
-        GENERATE_WRITE_PR_REG_CASE(0, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(1, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(2, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(3, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(4, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(5, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(6, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(7, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(8, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(9, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(10, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(11, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(12, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(13, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(14, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(15, pr_write);
-    default:
-        BUG(); /* Can't happen */
-        break;
-    }
-}
-
 pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags)
 {
     unsigned int attr_idx = PAGE_AI_MASK(flags);
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 14:40:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 14:40:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011846.1390375 (Exim 4.92)
	(envelope-from )
	id 1uPMd4-0002cD-GM; Wed, 11 Jun 2025 14:40:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011846.1390375; Wed, 11 Jun 2025 14:40:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPMd4-0002c6-Dg; Wed, 11 Jun 2025 14:40:38 +0000
Received: by outflank-mailman (input) for mailman id 1011846;
 Wed, 11 Jun 2025 14:40:37 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uPMa0-0007IS-MY
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 14:37:28 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20629.outbound.protection.outlook.com
 [2a01:111:f403:2413::629])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 990cc80c-46d1-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 16:37:28 +0200 (CEST)
Received: from LV3P220CA0010.NAMP220.PROD.OUTLOOK.COM (2603:10b6:408:234::30)
 by SJ2PR12MB8925.namprd12.prod.outlook.com (2603:10b6:a03:542::9)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.19; Wed, 11 Jun
 2025 14:37:23 +0000
Received: from BL6PEPF0001AB53.namprd02.prod.outlook.com
 (2603:10b6:408:234:cafe::b) by LV3P220CA0010.outlook.office365.com
 (2603:10b6:408:234::30) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.35 via Frontend Transport; Wed,
 11 Jun 2025 14:37:22 +0000
Received: from SATLEXMB03.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.8835.15 via Frontend Transport; Wed, 11 Jun 2025 14:37: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; Wed, 11 Jun
 2025 09:37:22 -0500
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, 11 Jun
 2025 09:37:21 -0500
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, 11 Jun 2025 09:37:20 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 990cc80c-46d1-11f0-a307-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=B0pIyIegpyqGlzHw/o/CJ49c96BORyP3jOPtrNaHUZlwlYlhc6UWBrCX5g1IrnDpTWHoukmNMnPFGk+8gU7JmxjYvtJRcIZ/NWPLCziJ3jwnvbrR1qFvVB2zJIixsnYrLXu84YQJZ2z+JjvtgPfx3U66ZrSZ4d9/uORMFDBftKf7rca43tbhHA/p0HUqjPPL6o5eWgD7ZMe1llwWD113e23L8qnnNVIEr7w7tK3yxSmhDECI8cMrnGNAgQBxzcIeiGjlgi4V6S9mVH2hNgO8m/UKblCslhCdRTxY7IfvjelUS7J115i/TdByv6q9I5ov5dY5V+wAF3zIi8lP7rbSXw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=FUpmQLoTFyCDjuUjHFpcV7C6yipFkzFMP1YDXzutgCE=;
 b=ImWP7FqJJ0bv48OtdOG8juP38OwYwOIbSZu1tyd1k3n0mKg84YKHGiyb7FLF1v35i36NBvRQOdrV42DtChUN48e74QyjVOd0agnpc4LlvmL3XM5eYyfwj6FsV2MP0TBVBQSgTZMnLMxse6hD7KyQcXBRIjMGvjD4vRUO0POFV8pFc2JndF2eR41wU2FVH/1CCJf9PjqIqOYbu+EFMQ+KCYJsAQwM05Qv2m85KRaPPtQtw2h2ZQhHyslJfUhdUklw1NpWurns1JeeLytz/Uw5HNJCYzYm+uf5HjT75YQMyYiNbSYQB6Ss9qAJdHQst/gY6AQ3tid91Kd00Mxuk5+D9w==
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=FUpmQLoTFyCDjuUjHFpcV7C6yipFkzFMP1YDXzutgCE=;
 b=soAWdLVm3NjwASssPLI5ErOBNUkFVuha9kd167M1f7JOldcJq8TiZuTAVACRFkgZTFeJFnxVKh1EQLrh9AM+KtVQ7LfKpcSaCyf6yAEoBo6btNPYzrA7zvjul9/f04hOhnZOi/vsquG3Y/OCGz7ZybNEPxj5OK31z1/a6vuImpA=
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: Ayan Kumar Halder , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" 
Subject: [PATCH v3 5/6] arm/mpu: Define arm32 system registers
Date: Wed, 11 Jun 2025 15:35:43 +0100
Message-ID: <20250611143544.3453532-6-ayan.kumar.halder@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20250611143544.3453532-1-ayan.kumar.halder@amd.com>
References: <20250611143544.3453532-1-ayan.kumar.halder@amd.com>
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: BL6PEPF0001AB53:EE_|SJ2PR12MB8925:EE_
X-MS-Office365-Filtering-Correlation-Id: b5cbc5cc-9f9a-4045-1d12-08dda8f57a1a
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?P0i73ViDKfL76kQVCIHHVfFM+sf4cxk9NH6dRmfv+xPKDbYNzHg+mox5h16O?=
 =?us-ascii?Q?N5KXC/Vfghsxrt9zviTutFZCOAEav6V8jylb7VW1QJ4PITG4l1rueR6Evvif?=
 =?us-ascii?Q?sKQjYBqUOHakmThpsJqahD1fP6gNC4/QRx0o5LKAu4tBkf1NEvnr49w86zkn?=
 =?us-ascii?Q?nGUdpCHi6mXEvCLGjyCKR+Ev6V60/FE7PHSbAh6WWtRBbtOd2wRQqS6Leb4d?=
 =?us-ascii?Q?YAeTMxnhMiBG/wvIMCgLAerAbdpCqABH5XjiCkbCzDDCLKyK/mfo8vhfa/pa?=
 =?us-ascii?Q?+RL1zmqQYi3md/ORoikweQe8P2zPFestqQvp8M1dhrqtz34SeolwMGyybr79?=
 =?us-ascii?Q?2ZuD6hXl3kgkX7qBEgfhhphCmzEPVWSadkznG71fZ1T9d8Sa657+jWkotwnS?=
 =?us-ascii?Q?y9G7sbb57VTpk0sI+3FExGecXg70ugt35JCz37SZdLVdKo5vsjs7E6LPoEVx?=
 =?us-ascii?Q?83jzu/cDSiJL6+8nu8qpX3hYzOa3O/5u8ik7xHREcY6tm42JBkOUzPQIPyUv?=
 =?us-ascii?Q?WAXaUhyGTXV0ozb70mP9Wp2SLkMI6CwCmyFMJN1XQfOR36ol2fT2Nu4W4aAC?=
 =?us-ascii?Q?dDNJha8CoYvnkb8RXf9gKmUbkUkOOaTq1AzScqlLjEscEE7DVIH/ChS3z4yF?=
 =?us-ascii?Q?E70Oazv8O3q5u2BtxEcfVlrLEoSVssZV29RQ9gnyQIvO2q7FVvEW16K3eq83?=
 =?us-ascii?Q?Ctg3BGCyYwc5yUrIwzOp4vV5rBn86LKe1rIgvv9mtrGqq8y4hzpQdWVO1BwI?=
 =?us-ascii?Q?pDAKNefOqEljlpPaPSaIJjBR1SnHQg3ewV2ZnU5yceXZ9QKbwVcrOx7iuhxj?=
 =?us-ascii?Q?yZZNaknf5pDydXZq733rTtnhRdRhXG4yGLMMhj8gBlA+YNDeRxWRkq+82gxR?=
 =?us-ascii?Q?6h67PWg6nhQTWZTEkt5GZoYtfa4WRhpMHyerHU+29htthmbyF4GO58ZrKc/x?=
 =?us-ascii?Q?PM2L36afI+bQZUC2Z8TthX6iP+IAKpDhG6SMlUp4ouvjn6/YbMuWA07d1QaV?=
 =?us-ascii?Q?GIRZemb0zZxwF4h4o6OY+9+DMYm6pt51UXAgckDavCSFiSZ9mjjsgXuGBx6x?=
 =?us-ascii?Q?uZvdvibGvVyQ9gBiZ01pQFjhvK7z1Hqoo/irsxXITk0GWUC7VoviDkCCBAoy?=
 =?us-ascii?Q?PC0B4QLbaZv1AzXPakRb/im7BnrEGiPS3doolCEL6hQ+fj6qajv8TFHMCpiS?=
 =?us-ascii?Q?9KxERnxD/ZmBbEZlzTihj1oHXyGtJ6FuyYCiIDzM4nsL5vJQgmcoNVq0HYH+?=
 =?us-ascii?Q?EauEjd+dHb7kql/dCUrFMI1bt4ro9te+qY6CtjD2m+rq3+GBqqdsm8W5umyw?=
 =?us-ascii?Q?moWZPMv4ITNY6xrHnVWanTwm7GUHe9R4NKzhEVADNyW3UqPj9pjklB6P6VNE?=
 =?us-ascii?Q?EcLVt/SYhpaDF6BlR02NnDnPKeWnpBJi9mC4fBQPVgOMoYvKTYlFae6aN+8p?=
 =?us-ascii?Q?B49DwfaXlmXbvHZ4S+tZuaA0KIBP+Y0NNeqi97693wcU6rxAb4fVNmDWA6G0?=
 =?us-ascii?Q?8fX5MQfjB7F6+vcwz5EFmqvPk3108xuPdigI?=
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: 11 Jun 2025 14:37:22.5031
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b5cbc5cc-9f9a-4045-1d12-08dda8f57a1a
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:
	BL6PEPF0001AB53.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB8925

Fix the definition for HPRLAR.
Define the base/limit address registers to access the first 32 protection
regions.

Signed-off-by: Ayan Kumar Halder 
---
Changes from :-

v1 - v1 - New patch introduced in v3 (Extracted from 
"arm/mpu: Provide access to the MPU region from the C code").

 xen/arch/arm/include/asm/mpu/cpregs.h | 68 ++++++++++++++++++++++++++-
 1 file changed, 67 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/include/asm/mpu/cpregs.h b/xen/arch/arm/include/asm/mpu/cpregs.h
index d5cd0e04d5..bb15e02df6 100644
--- a/xen/arch/arm/include/asm/mpu/cpregs.h
+++ b/xen/arch/arm/include/asm/mpu/cpregs.h
@@ -9,7 +9,73 @@
 /* CP15 CR6: MPU Protection Region Base/Limit/Select Address Register */
 #define HPRSELR         p15,4,c6,c2,1
 #define HPRBAR          p15,4,c6,c3,0
-#define HPRLAR          p15,4,c6,c8,1
+#define HPRLAR          p15,4,c6,c3,1
+
+/* CP15 CR6: MPU Protection Region Base/Limit Address Register */
+#define HPRBAR0         p15,4,c6,c8,0
+#define HPRLAR0         p15,4,c6,c8,1
+#define HPRBAR1         p15,4,c6,c8,4
+#define HPRLAR1         p15,4,c6,c8,5
+#define HPRBAR2         p15,4,c6,c9,0
+#define HPRLAR2         p15,4,c6,c9,1
+#define HPRBAR3         p15,4,c6,c9,4
+#define HPRLAR3         p15,4,c6,c9,5
+#define HPRBAR4         p15,4,c6,c10,0
+#define HPRLAR4         p15,4,c6,c10,1
+#define HPRBAR5         p15,4,c6,c10,4
+#define HPRLAR5         p15,4,c6,c10,5
+#define HPRBAR6         p15,4,c6,c11,0
+#define HPRLAR6         p15,4,c6,c11,1
+#define HPRBAR7         p15,4,c6,c11,4
+#define HPRLAR7         p15,4,c6,c11,5
+#define HPRBAR8         p15,4,c6,c12,0
+#define HPRLAR8         p15,4,c6,c12,1
+#define HPRBAR9         p15,4,c6,c12,4
+#define HPRLAR9         p15,4,c6,c12,5
+#define HPRBAR10        p15,4,c6,c13,0
+#define HPRLAR10        p15,4,c6,c13,1
+#define HPRBAR11        p15,4,c6,c13,4
+#define HPRLAR11        p15,4,c6,c13,5
+#define HPRBAR12        p15,4,c6,c14,0
+#define HPRLAR12        p15,4,c6,c14,1
+#define HPRBAR13        p15,4,c6,c14,4
+#define HPRLAR13        p15,4,c6,c14,5
+#define HPRBAR14        p15,4,c6,c15,0
+#define HPRLAR14        p15,4,c6,c15,1
+#define HPRBAR15        p15,4,c6,c15,4
+#define HPRLAR15        p15,4,c6,c15,5
+#define HPRBAR16        p15,5,c6,c8,0
+#define HPRLAR16        p15,5,c6,c8,1
+#define HPRBAR17        p15,5,c6,c8,4
+#define HPRLAR17        p15,5,c6,c8,5
+#define HPRBAR18        p15,5,c6,c9,0
+#define HPRLAR18        p15,5,c6,c9,1
+#define HPRBAR19        p15,5,c6,c9,4
+#define HPRLAR19        p15,5,c6,c9,5
+#define HPRBAR20        p15,5,c6,c10,0
+#define HPRLAR20        p15,5,c6,c10,1
+#define HPRBAR21        p15,5,c6,c10,4
+#define HPRLAR21        p15,5,c6,c10,5
+#define HPRBAR22        p15,5,c6,c11,0
+#define HPRLAR22        p15,5,c6,c11,1
+#define HPRBAR23        p15,5,c6,c11,4
+#define HPRLAR23        p15,5,c6,c11,5
+#define HPRBAR24        p15,5,c6,c12,0
+#define HPRLAR24        p15,5,c6,c12,1
+#define HPRBAR25        p15,5,c6,c12,4
+#define HPRLAR25        p15,5,c6,c12,5
+#define HPRBAR26        p15,5,c6,c13,0
+#define HPRLAR26        p15,5,c6,c13,1
+#define HPRBAR27        p15,5,c6,c13,4
+#define HPRLAR27        p15,5,c6,c13,5
+#define HPRBAR28        p15,5,c6,c14,0
+#define HPRLAR28        p15,5,c6,c14,1
+#define HPRBAR29        p15,5,c6,c14,4
+#define HPRLAR29        p15,5,c6,c14,5
+#define HPRBAR30        p15,5,c6,c15,0
+#define HPRLAR30        p15,5,c6,c15,1
+#define HPRBAR31        p15,5,c6,c15,4
+#define HPRLAR31        p15,5,c6,c15,5
 
 /* Aliases of AArch64 names for use in common code */
 #ifdef CONFIG_ARM_32
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 14:40:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 14:40:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011849.1390385 (Exim 4.92)
	(envelope-from )
	id 1uPMdK-0003Eh-RE; Wed, 11 Jun 2025 14:40:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011849.1390385; Wed, 11 Jun 2025 14: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 1uPMdK-0003Ea-Nz; Wed, 11 Jun 2025 14:40:54 +0000
Received: by outflank-mailman (input) for mailman id 1011849;
 Wed, 11 Jun 2025 14:40: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 1uPMaH-0007IS-Er
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 14:37:45 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20619.outbound.protection.outlook.com
 [2a01:111:f403:2418::619])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a2ec5eb0-46d1-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 16:37:44 +0200 (CEST)
Received: from BLAPR03CA0062.namprd03.prod.outlook.com (2603:10b6:208:329::7)
 by SA0PR12MB4448.namprd12.prod.outlook.com (2603:10b6:806:94::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.18; Wed, 11 Jun
 2025 14:37:40 +0000
Received: from BL6PEPF0001AB77.namprd02.prod.outlook.com
 (2603:10b6:208:329:cafe::83) by BLAPR03CA0062.outlook.office365.com
 (2603:10b6:208:329::7) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.35 via Frontend Transport; Wed,
 11 Jun 2025 14:37:40 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL6PEPF0001AB77.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.8835.15 via Frontend Transport; Wed, 11 Jun 2025 14:37:39 +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, 11 Jun
 2025 09:37:39 -0500
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, 11 Jun 2025 09:37:38 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a2ec5eb0-46d1-11f0-a307-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=LSYCkHVA/gsKDulAZT6P7LFdk0Gdq+IFCB11Ec/ehIb4LxlA/ZNXHUqigrGgedWvvm9t9tp3dPHKPey+viaYH11OI8FRvKUR8xmPqRojywEYcVsTgc0C8Szq8ABfrKnb24jmfW16DKM1NfHXEaFBP6U1C+Z8r8ucfRcpix0E9Ptbu/fNRYUAHvC916p1DLJTS/e9tdaPwoXelKzkepzD6o0srdfBmW5E0Lb5Ne0LOLw5cNHGQQm+GECJJDH/5tjy7x/vf6SCuGBW8qTIciYrPgqO0r+MHhH/dDqpBDzELenimG4IrMNsGCYv2JYsxmPslwznA1bUjyCT+Axo2gXtbA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=EkhD6xpo2oK6wFkchaV4WlEipg9dIFDq1WyttTCY6NM=;
 b=v3HJxcY7m4GoNlew+qZ45BB8u3xTJG9M5nlBdhkYYXe+V8PoNvJreZxEWe3rFZd6yQDmLAbELd5VAECvEHx/B/QOlwvjPsUbhIc2D+TRFwctbnZ+lfRmbPSqxb4Ov9Kavb3p2xwddu93hMHwN6ZBH/2B8C7EFKE5+H9HzrjDJUd8Oarbm9HLUnte76ZSE5FH1y/ByuMkC4M71IUDWn6ntGPf/3bKOnnatNU3J/mu4yCL1PmOGVwUsxJ/uMtPprlSo8qjLpHG7Dw3dABv2TMU4HkQEXb79yD8alhy5rUkZfT9ChyclPh8+ADwcMI021sqzrtRRSghFenqGrOQimEUaA==
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=EkhD6xpo2oK6wFkchaV4WlEipg9dIFDq1WyttTCY6NM=;
 b=pL9PaGIuBzwMuU00u5UQyJ+imde5qDK+zPFqbY4S2Ka6NtTGUTFcX+J829iJOJAMDaCfDgfGY6N1RbveSGtw5+uFP1nBtG+F7kzTyYQLDUQZQwHRnYfq5MH09bRx/CAZld7Fbcb+yLXS1G05azrqgJUUwQiT3hOrtlMXWOLajJA=
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 6/6] arm/mpu: Enable read/write to protection regions for arm32
Date: Wed, 11 Jun 2025 15:35:44 +0100
Message-ID: <20250611143544.3453532-7-ayan.kumar.halder@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20250611143544.3453532-1-ayan.kumar.halder@amd.com>
References: <20250611143544.3453532-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: BL6PEPF0001AB77:EE_|SA0PR12MB4448:EE_
X-MS-Office365-Filtering-Correlation-Id: 2e6177f9-7aac-4d43-e6ee-08dda8f5843b
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?6CN7CztbbdlSM2L735S7sTftYhuc4dae9J2Z5I5TvIOYUfbEJick1iA4QJ7R?=
 =?us-ascii?Q?HMxccF3m4zGb9XbxKuIc2//9ENLLYDJb5Pqg9ISKTmfpspc+elM3y2BXJNBv?=
 =?us-ascii?Q?R0oMIu5pg0j+hRcmaZzsoEgdD2WgqVzE8jD4sH0Ex+PQEj6x1QRsi2cL0a7U?=
 =?us-ascii?Q?qzibxl39rd1xOv8rFo8YLNtEhq1y2+hBRH0S6Xa5u67VNE2EQLARqw8l+lLu?=
 =?us-ascii?Q?GeHliWkGqck2asOGuDOkfkDStMMZAi3kMqLH1XaM639L6e7rsp3rt1lH+Iew?=
 =?us-ascii?Q?9fdRjq+xDkke9GZ1Vw++RmaD2GOUQKIitCB1S6wkuWMS4goYl7rNfhWdcDAV?=
 =?us-ascii?Q?73P2wA+B2sMTwnXc/yedVA5l4YZVU/eFJfG0soNl1z7qIPscx8gmU3Fxlzk/?=
 =?us-ascii?Q?i6Yrse4eoT9Vk3K7QAIUwl+iOy91X4oyGVEFKXHMuzT10DPN9nMSLUdgPfIa?=
 =?us-ascii?Q?cy4DsopitmGAzCNA81HYVvYPj+OUzwc/3Qr7g0GfKIkQSE35ik8MTNIbcxg8?=
 =?us-ascii?Q?TnvsGRBgxiLrkPCZlmmJHR4nNO9xRuSYEggX8Ax12nuLe5dp9v0akzIrOCuB?=
 =?us-ascii?Q?LDyBRvOZw8KfboCsqNgeL3txL6lflvqKcC53Xv1bZVGeeFqtsbKLvc2Jf3Cq?=
 =?us-ascii?Q?3oX7IfjAfEPIn1p2vUA5gMFe1l5lI0MY4SlyhChLBQ975O1e+2+LN81Oy8Xr?=
 =?us-ascii?Q?5AIi3wg6Sp85guyu9zyAibyfx0pHG9SADMa9azWzS1U2O0rUlcpYa2DrIzRk?=
 =?us-ascii?Q?2l42ltmLoyZcNvB5Ht3KFtIcyVtWbJH5Ll+2fFWLJJgHAJOqDfjkPWNFZkwU?=
 =?us-ascii?Q?92/rgxq5X2KCOIbFge4dbyn71qTSAXyE6q5MCbvbMBMCciMvqw34IYbz/X1j?=
 =?us-ascii?Q?p4W00EUrzZEETAnL+rIby2oaydHZY+aSPuQAVf1S6NKNesXfqUiheN5WSUxh?=
 =?us-ascii?Q?H5LKpQfmAikFkngJEReR0yaO/zEyBfEdCsE8GyOzmrHD7VaY85fLOjms1XtG?=
 =?us-ascii?Q?3lwpvJ/1vs++F8w+drSiUC7ki5J6hS5jifWD2tSEGff/eeLIW8HU102TXt1S?=
 =?us-ascii?Q?v6Hx6FEl2Yi/r0wC+lIqiT8AfURtkWq81GNHizvmltpsOkxZxtLaXTwoh2f+?=
 =?us-ascii?Q?RWF5oQU0UIv6uTCy2cBoClgF87pEiR/MMOFCNWugb27TWlUwYpGX7dtcjsZf?=
 =?us-ascii?Q?6N0gAHaGypocYR0NysZJDaa3k76zz07vtu1UGRbQhJ5jcOPET9A21GJ9GOWR?=
 =?us-ascii?Q?KwMGKZfpBElVIdtYN5AVZP3m1jyY/TyS2uh4ZO5xwBz1aMGAcEA+siWQrqbK?=
 =?us-ascii?Q?59tVWljFhyXwSiaqr2cAoC+oJYX18sYlNAVNBqvLT+pftz6RwabVwDvxPUSt?=
 =?us-ascii?Q?rgbIcWWrOl0k/Y4NaP4WrPkdIp7NCOw6eoSXWkw7QJ531m0W9UJCjsY9U4oa?=
 =?us-ascii?Q?SckRmugm05n4jjN4Ei87Gvm/2nAUuaNZ44YFsLF+Tse2hrYi5lq0r8Wwi/jm?=
 =?us-ascii?Q?nZBK37nlrYljuCFi92rjiq+EQmL/SztGswtm?=
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: 11 Jun 2025 14:37:39.5012
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 2e6177f9-7aac-4d43-e6ee-08dda8f5843b
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:
	BL6PEPF0001AB77.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR12MB4448

Define prepare_selector(), read_protection_region() and
write_protection_region() for arm32. Also, define
GENERATE_{READ/WRITE}_PR_REG_OTHERS to access MPU regions from 32 to 255.

Enable pr_{get/set}_{base/limit}(), region_is_valid() for arm32.
Enable pr_of_addr() for arm32.

Signed-off-by: Ayan Kumar Halder 
---
Changes from :-

v1 - 1. Enable write_protection_region() for aarch32.

v2 - 1. Enable access to protection regions from 0 - 255.

 xen/arch/arm/include/asm/mpu.h  |   2 -
 xen/arch/arm/mpu/arm32/Makefile |   1 +
 xen/arch/arm/mpu/arm32/mm.c     | 165 ++++++++++++++++++++++++++++++++
 xen/arch/arm/mpu/mm.c           |   2 -
 4 files changed, 166 insertions(+), 4 deletions(-)
 create mode 100644 xen/arch/arm/mpu/arm32/mm.c

diff --git a/xen/arch/arm/include/asm/mpu.h b/xen/arch/arm/include/asm/mpu.h
index 8f06ddac0f..63560c613b 100644
--- a/xen/arch/arm/include/asm/mpu.h
+++ b/xen/arch/arm/include/asm/mpu.h
@@ -25,7 +25,6 @@
 
 #ifndef __ASSEMBLY__
 
-#ifdef CONFIG_ARM_64
 /*
  * Set base address of MPU protection region.
  *
@@ -85,7 +84,6 @@ static inline bool region_is_valid(const pr_t *pr)
 {
     return pr->prlar.reg.en;
 }
-#endif /* CONFIG_ARM_64 */
 
 #endif /* __ASSEMBLY__ */
 
diff --git a/xen/arch/arm/mpu/arm32/Makefile b/xen/arch/arm/mpu/arm32/Makefile
index e15ce2f7be..3da872322e 100644
--- a/xen/arch/arm/mpu/arm32/Makefile
+++ b/xen/arch/arm/mpu/arm32/Makefile
@@ -1 +1,2 @@
 obj-y += domain-page.o
+obj-y += mm.o
diff --git a/xen/arch/arm/mpu/arm32/mm.c b/xen/arch/arm/mpu/arm32/mm.c
new file mode 100644
index 0000000000..5d3cb6dff7
--- /dev/null
+++ b/xen/arch/arm/mpu/arm32/mm.c
@@ -0,0 +1,165 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PRBAR_EL2_(n)   HPRBAR##n
+#define PRLAR_EL2_(n)   HPRLAR##n
+
+#define GENERATE_WRITE_PR_REG_CASE(num, pr)                                 \
+    case num:                                                               \
+    {                                                                       \
+        WRITE_SYSREG(pr->prbar.bits & ~MPU_REGION_RES0, PRBAR_EL2_(num));   \
+        WRITE_SYSREG(pr->prlar.bits & ~MPU_REGION_RES0, PRLAR_EL2_(num));   \
+        break;                                                              \
+    }
+
+#define GENERATE_WRITE_PR_REG_OTHERS(num, pr)                               \
+    case num:                                                               \
+    {                                                                       \
+        WRITE_SYSREG(pr->prbar.bits & ~MPU_REGION_RES0, HPRBAR);            \
+        WRITE_SYSREG(pr->prlar.bits & ~MPU_REGION_RES0, HPRLAR);            \
+        break;                                                              \
+    }
+
+#define GENERATE_READ_PR_REG_CASE(num, pr)                                  \
+    case num:                                                               \
+    {                                                                       \
+        pr->prbar.bits = READ_SYSREG(PRBAR_EL2_(num));                      \
+        pr->prlar.bits = READ_SYSREG(PRLAR_EL2_(num));                      \
+        break;                                                              \
+    }
+
+#define GENERATE_READ_PR_REG_OTHERS(num, pr)                                \
+    case num:                                                               \
+    {                                                                       \
+        pr->prbar.bits = READ_SYSREG(HPRBAR);                               \
+        pr->prlar.bits = READ_SYSREG(HPRLAR);                               \
+        break;                                                              \
+    }
+
+/*
+ * Armv8-R supports direct access and indirect access to the MPU regions through
+ * registers:
+ *  - indirect access involves changing the MPU region selector, issuing an isb
+ *    barrier and accessing the selected region through specific registers
+ *  - direct access involves accessing specific registers that point to
+ *    specific MPU regions, without changing the selector, avoiding the use of
+ *    a barrier.
+ * For Arm32 the PR{B,L}AR_ELx (for n=0..31) are used for direct access to the
+ * first 32 MPU regions.
+ * For MPU region numbered 32..255, one need to set the region number in PRSELR_ELx,
+ * followed by configuring PR{B,L}AR_ELx.
+ */
+inline void prepare_selector(uint8_t *sel)
+{
+    uint8_t cur_sel = *sel;
+
+    if ( cur_sel > 0x1FU )
+    {
+        WRITE_SYSREG(cur_sel, PRSELR_EL2);
+        isb();
+    }
+}
+
+void read_protection_region(pr_t *pr_read, uint8_t sel)
+{
+    prepare_selector(&sel);
+
+    switch ( sel )
+    {
+        GENERATE_READ_PR_REG_CASE(0, pr_read);
+        GENERATE_READ_PR_REG_CASE(1, pr_read);
+        GENERATE_READ_PR_REG_CASE(2, pr_read);
+        GENERATE_READ_PR_REG_CASE(3, pr_read);
+        GENERATE_READ_PR_REG_CASE(4, pr_read);
+        GENERATE_READ_PR_REG_CASE(5, pr_read);
+        GENERATE_READ_PR_REG_CASE(6, pr_read);
+        GENERATE_READ_PR_REG_CASE(7, pr_read);
+        GENERATE_READ_PR_REG_CASE(8, pr_read);
+        GENERATE_READ_PR_REG_CASE(9, pr_read);
+        GENERATE_READ_PR_REG_CASE(10, pr_read);
+        GENERATE_READ_PR_REG_CASE(11, pr_read);
+        GENERATE_READ_PR_REG_CASE(12, pr_read);
+        GENERATE_READ_PR_REG_CASE(13, pr_read);
+        GENERATE_READ_PR_REG_CASE(14, pr_read);
+        GENERATE_READ_PR_REG_CASE(15, pr_read);
+        GENERATE_READ_PR_REG_CASE(16, pr_read);
+        GENERATE_READ_PR_REG_CASE(17, pr_read);
+        GENERATE_READ_PR_REG_CASE(18, pr_read);
+        GENERATE_READ_PR_REG_CASE(19, pr_read);
+        GENERATE_READ_PR_REG_CASE(20, pr_read);
+        GENERATE_READ_PR_REG_CASE(21, pr_read);
+        GENERATE_READ_PR_REG_CASE(22, pr_read);
+        GENERATE_READ_PR_REG_CASE(23, pr_read);
+        GENERATE_READ_PR_REG_CASE(24, pr_read);
+        GENERATE_READ_PR_REG_CASE(25, pr_read);
+        GENERATE_READ_PR_REG_CASE(26, pr_read);
+        GENERATE_READ_PR_REG_CASE(27, pr_read);
+        GENERATE_READ_PR_REG_CASE(28, pr_read);
+        GENERATE_READ_PR_REG_CASE(29, pr_read);
+        GENERATE_READ_PR_REG_CASE(30, pr_read);
+        GENERATE_READ_PR_REG_CASE(31, pr_read);
+        GENERATE_READ_PR_REG_OTHERS(32 ... 255, pr_read);
+    default:
+        BUG(); /* Can't happen */
+        break;
+    }
+}
+
+void write_protection_region(const pr_t *pr_write, uint8_t sel)
+{
+    prepare_selector(&sel);
+
+    switch ( sel )
+    {
+        GENERATE_WRITE_PR_REG_CASE(0, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(1, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(2, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(3, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(4, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(5, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(6, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(7, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(8, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(9, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(10, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(11, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(12, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(13, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(14, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(15, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(16, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(17, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(18, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(19, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(20, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(21, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(22, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(23, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(24, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(25, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(26, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(27, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(28, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(29, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(30, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(31, pr_write);
+        GENERATE_WRITE_PR_REG_OTHERS(32 ... 255, pr_write);
+    default:
+        BUG(); /* Can't happen */
+        break;
+    }
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
index 7ab68fc8c7..ccfb37a67b 100644
--- a/xen/arch/arm/mpu/mm.c
+++ b/xen/arch/arm/mpu/mm.c
@@ -39,7 +39,6 @@ static void __init __maybe_unused build_assertions(void)
     BUILD_BUG_ON(PAGE_SIZE != SZ_4K);
 }
 
-#ifdef CONFIG_ARM_64
 pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags)
 {
     unsigned int attr_idx = PAGE_AI_MASK(flags);
@@ -110,7 +109,6 @@ pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags)
 
     return region;
 }
-#endif /* CONFIG_ARM_64 */
 
 void __init setup_mm(void)
 {
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 15:20:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 15:20:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011874.1390395 (Exim 4.92)
	(envelope-from )
	id 1uPNFC-00087A-J6; Wed, 11 Jun 2025 15:20:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011874.1390395; Wed, 11 Jun 2025 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 1uPNFC-00086Y-FV; Wed, 11 Jun 2025 15:20:02 +0000
Received: by outflank-mailman (input) for mailman id 1011874;
 Wed, 11 Jun 2025 15:20: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 1uPNFB-00081J-6H
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 15:20:01 +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 89aa672b-46d7-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 17:19:59 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3a361b8a664so5535340f8f.3
 for ; Wed, 11 Jun 2025 08:19:59 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-7482b0eb0f1sm9219153b3a.169.2025.06.11.08.19.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 08:19:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 89aa672b-46d7-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749655198; x=1750259998; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=x3403/vazUymk0RGnXWKuHJGeaVp4ALuTSVCw56osog=;
        b=fWGUIokcIrPd7NZv1mg7edrMpN2ByEuS30ptChTT+Nm4d44+KW3GGf1C9baIrf7Rv0
         3vajlcixSq1Y6VGJ4wQX7P7u6Fn5BoxkBRKlpNpwbR+J+V1PqLHIKDuPBvRZi2ZtMBsM
         uAnXjoz2mbuiyTduY50x21AT3b5ifj4CHx5T097M9aAgRPw7pE7B2pgEFC5eMvFH4Us2
         r3SMv3nNY+iDC6NsElmOOSeF/RID0N1U/ViqnnsF+TispfpOfHUSE/p81axvwIKd9YjF
         LO7jE6yVJYIVWr4rGpRFu7/+jzkAxusLjRpDMRdJ431geXGgaMKSP4Kf6tUFvFMXRPrd
         nV+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749655198; x=1750259998;
        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=x3403/vazUymk0RGnXWKuHJGeaVp4ALuTSVCw56osog=;
        b=GTkjvEpOUukarOSu0YebI7mlZum6VP7dzHRNai65Cp2jQM8H1F9bwiOg4+LXBaHXT6
         VKO7bqzfZTv7rGziSO1bZnC/Gg+jHR61BDgu2bSKNdcXSuUWwUdmHYL3cFjIrxiPjadS
         wTWZBqCHPL5lu1L6RaJyClUonlI386z0JnHQ8HtmuVY5VSkJ+gySMRwPJ9/uD9Jn8Uq0
         tPESA/Ysdj+t6kADhsL/+COm4FRg1ru1jTtyet2f55/NnKDCWue6qhoeFzqJFE6Y4p7e
         FU7QxY5GeSK/7uYHMKp2UI6zspQhpHXWca1b1w+pQuE4kyl6l0DbSXoYKy5tVh5/x1jO
         2NIw==
X-Forwarded-Encrypted: i=1; AJvYcCX067G7ja0zHaCbZVnmjTtNjtowrxwJJOzdUGeltvTApEXEcDpQOHlTM4lLFQLCroerIlW9uxKoom8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwMO3N9bIh1fw5o7K4K4Y+Ky0mPSs4eb7bF06L1ZcyuOR9PhOnL
	J72qdKZb0BANMBM/h2aimw/1ruSLbk2qEYZfmhnXKYhyTaqap3j2/X2lCY/xw27qHw==
X-Gm-Gg: ASbGnctYQx/Ru8AVxeUOuv0pLWPV7ygMgCX6uDJzbR3y2RhQPh9VEdrzvsFDqOmEMBe
	EnVQDQJ3pdjQ0/iGZoQ9rqHwToBPYLvuhZ3OA832l6+a30uzYtsDDwBHjN+9sXu/iIY4/WC1M/Z
	YJh668Dk86I2jE4J5aQjB8UaM96Sfj1nLIqn5K8sEOL7xHHZngm9uJ1YR/svkp3PFghBSSnnD4l
	tagI3fcaCyQPvr8yasao1XlKkjjyvIuIrDitBWDjqzE86zVLHfgbE3jVYWxHKY/2YlHa7n8bV6h
	eGUOBvYOqNWv8fn6lAIKHNOpt1oSBPvDHe9BqW5vsUeMBd4CVQcvxesdLZg1WzZvEBZO2tPGuMe
	q8S4z/VXJnLaKp/sIKFhA/5iDDp1Y2cUBXKuQUdkGap7urBA=
X-Google-Smtp-Source: AGHT+IFxnPPwUw3DO4zTIpLr1dx4fs7xrh6LY7bgF7/OXwPxIfS2dgVTHYcQ4xAyE4Ii8CQqbcb4ow==
X-Received: by 2002:a05:6000:288e:b0:3a4:ebc2:d6ec with SMTP id ffacd0b85a97d-3a5586f26bfmr2996346f8f.14.1749655198507;
        Wed, 11 Jun 2025 08:19:58 -0700 (PDT)
Message-ID: <0d60d42f-d844-41b5-a8ca-bdfe7883d15b@suse.com>
Date: Wed, 11 Jun 2025 17:19:51 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 01/18] xen/pmstat: guard perf.states[] access with
 XEN_PX_INIT
To: Penny Zheng 
Cc: ray.huang@amd.com, xen-devel@lists.xenproject.org
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-2-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: <20250527084833.338427-2-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.05.2025 10:48, Penny Zheng wrote:
> Accessing to perf.states[] array shall not be only guarded with user-defined
> hypercall input, so we add XEN_PX_INIT check to gain safety.

What is "guarded with user-defined hypercall input"? And what safety are we
lacking?

> --- a/xen/drivers/acpi/pmstat.c
> +++ b/xen/drivers/acpi/pmstat.c
> @@ -228,10 +228,13 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
>      ret = copy_to_guest(op->u.get_para.affected_cpus,
>                          data, op->u.get_para.cpu_num);
>  
> -    for ( i = 0; i < op->u.get_para.freq_num; i++ )
> -        data[i] = pmpt->perf.states[i].core_frequency * 1000;
> -    ret += copy_to_guest(op->u.get_para.scaling_available_frequencies,
> -                         data, op->u.get_para.freq_num);
> +    if ( pmpt->perf.init & XEN_PX_INIT )
> +    {
> +        for ( i = 0; i < op->u.get_para.freq_num; i++ )
> +            data[i] = pmpt->perf.states[i].core_frequency * 1000;
> +        ret += copy_to_guest(op->u.get_para.scaling_available_frequencies,
> +                             data, op->u.get_para.freq_num);
> +    }

Going from just the code change: You want to avoid copying out frequency
values when none have been reported? But when none have been reported,
isn't pmpt->perf.state_count (against which op->u.get_para.freq_num was
validated) simply going to be 0? If not, how would callers know that no
data was handed back to them?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 15:24:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 15:24:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011879.1390406 (Exim 4.92)
	(envelope-from )
	id 1uPNJC-0001F0-1k; Wed, 11 Jun 2025 15:24:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011879.1390406; Wed, 11 Jun 2025 15:24: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 1uPNJB-0001Et-V4; Wed, 11 Jun 2025 15:24:09 +0000
Received: by outflank-mailman (input) for mailman id 1011879;
 Wed, 11 Jun 2025 15:24: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 1uPNJA-0001En-Rw
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 15:24:08 +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 1c2c78f4-46d8-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 17:24:05 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-451dbe494d6so83333645e9.1
 for ; Wed, 11 Jun 2025 08:24:04 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23603405f5fsm89510815ad.172.2025.06.11.08.24.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 08:24:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1c2c78f4-46d8-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749655444; x=1750260244; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=a72wZ0Yu2OYFZ62cY5VhXbdtPrirEvtb++QiGHx2GNM=;
        b=I792ajLJESCccqGvAFklyXNqwneZpGjjgnHEgQ5RQEOjDJ95zm4pBqpcYMKa7Tu6TZ
         DD7X93yDNfJsuAoQjRki+zHaF/+2XbzVTO5TtWT7WfkR7DWGWyeA8S/uec32SCqmSveG
         wpMEV9/0m49nfCGjXe052ioSv1BmzmrbBIf9Fh9u3LuFSdLvIPG8frsDHRmfO4j7QDFA
         tr9/PBI9XqJVaLbvrvV7e6BK3X3IQ51tGuv8gaS8RUMCDezzX3JN2VNTYOJwhA7mcUBl
         yFzgmpte/18xe0h5py/fZ1Hx5gqcXYpI+0xHe747H1iYsb/uxzN57t6xMMgqB/yXjjvU
         o8QQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749655444; x=1750260244;
        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=a72wZ0Yu2OYFZ62cY5VhXbdtPrirEvtb++QiGHx2GNM=;
        b=wHk2pecxQVgq4HpHZ/oJcx7jvby43xMpgA4DW2Ra5CGe/YX4KGSmIYeAo/ugKmuMQM
         r5fsW5alZsdLcI0XbQ0Y7ddqZk8YZfW6n+Pqab6VwfWKmopSPEmOe2MdRjPf5V4WUqVL
         s73puVGdozFiKy0orga8A7PbA7pt327Q+TJSnDcIkLOvF5rfrHH+vtoueIbt9aJhorBJ
         1cNbs2yyQJU1Aj0gq+Wse0AsWgk4huE2ctG061FVCAMKklKQ6JN0PijcQOzL8lZuH3sV
         z/Ukd5cRJWGOx+pZ9CxTZfBC/xHkTCDoqB1gSv5NbBtfX6xWIYesY4DmpF3/LX6rrJBF
         1UwA==
X-Forwarded-Encrypted: i=1; AJvYcCVrbRNhiXwcAysIgALc6xc30DXZIlT83aXTDhijI6TTMBiEEPOGYtIX+nSq+siF6Sl55i3GOqCwn6A=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy0Kbv4Bfh9V6+YPvsThAG9wy+oJ54fBZNt3MsyC81NtPd83L6/
	44FuxushjafXZ9LZC8/W1wFWW7pNLXS3NmmiJtu7mBAppkcW6p9RWcSXPBGJW3DYTA==
X-Gm-Gg: ASbGncv82HaJGIlozURUtMul4E5bZG1o/CiOKW5tmOFPJ5Wz5p6KZMi+IFAOng5Rzwy
	4n+oSg93Ydsi/q9BA55H3izE+6jSY8Xehj3XQhVcxbJTLQv2Jpy7RFZ57/n0tFIfWeg7fdrnpT/
	gUJzNzsYifyB26xXSMbKE4pa85b1TOVPOb7I11fowokOoTExAFGTPbxvuY94D1TEVCeqaYTtLsL
	ntibaVDX5Iugzi6TKhcCRPKmYd7FnRDB1mi1WU8lRQx1KjH3HbVEFX/e7RwxdIyu1U9FcSoRnkm
	Uhd7ePit43rDmk9w6NfhebfrvLB7qQKQnWSE8ZTPNY+w22MTQrfoH/ffnmis9zkm02JxmKfaoAX
	5uyijmFIG2Qr67eRqqTWTouNtLFxF3IVAV8f3KTNeIfSLlUp0ckkMLf2UfA==
X-Google-Smtp-Source: AGHT+IE6ULbTRxbiui29GjIIHjMEIxwZt+aVtKk9dtRj9ifk7l3Zr2v3ptg/5fN2V4U5Gi3N0Y7rUg==
X-Received: by 2002:a05:6000:2306:b0:3a5:541c:b40f with SMTP id ffacd0b85a97d-3a5586c3b69mr3134942f8f.9.1749655444316;
        Wed, 11 Jun 2025 08:24:04 -0700 (PDT)
Message-ID: <77a441a3-7f98-457f-bc74-4d9db4f75692@suse.com>
Date: Wed, 11 Jun 2025 17:23:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 02/18] xen/cpufreq: move "init" flag into common
 structure
To: Penny Zheng 
Cc: ray.huang@amd.com, xen-devel@lists.xenproject.org
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-3-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: <20250527084833.338427-3-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.05.2025 10:48, Penny Zheng wrote:
> AMD cpufreq cores will be intialized in two modes, legacy P-state mode,
> and CPPC mode. So "init" flag shall be extracted from px-specific
> "struct xen_processor_perf", and placed in the common
> "struct processor_pminfo". Otherwise, later when introducing a new
> sub-hypercall to propagate CPPC data, we need to pass irrelevant px-specific
> "struct xen_processor_perf" to just set init flag.
> 
> Signed-off-by: Penny Zheng 

Acked-by: Jan Beulich 

I'd be happy to put this in right away, but aiui ...

> @@ -228,7 +228,7 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
>      ret = copy_to_guest(op->u.get_para.affected_cpus,
>                          data, op->u.get_para.cpu_num);
>  
> -    if ( pmpt->perf.init & XEN_PX_INIT )
> +    if ( pmpt->init & XEN_PX_INIT )
>      {
>          for ( i = 0; i < op->u.get_para.freq_num; i++ )
>              data[i] = pmpt->perf.states[i].core_frequency * 1000;

... this hunk needs dropping then, as the modified code is only introduced
by patch 1. Which raises the question why you didn't order the patches the
other way around, avoiding to immediately need to touch the same (new) code
again. Please clarify.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 15:28:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 15:28:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011888.1390416 (Exim 4.92)
	(envelope-from )
	id 1uPNN5-0001s2-Je; Wed, 11 Jun 2025 15:28:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011888.1390416; Wed, 11 Jun 2025 15: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 1uPNN5-0001rv-Gs; Wed, 11 Jun 2025 15:28:11 +0000
Received: by outflank-mailman (input) for mailman id 1011888;
 Wed, 11 Jun 2025 15: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 1uPNN4-0001rp-GE
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 15:28:10 +0000
Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com
 [2607:f8b0:4864:20::72c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ad9bf75d-46d8-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 17:28:09 +0200 (CEST)
Received: by mail-qk1-x72c.google.com with SMTP id
 af79cd13be357-7d38cfa9773so428959285a.2
 for ; Wed, 11 Jun 2025 08:28:09 -0700 (PDT)
Received: from [10.138.10.6] ([89.187.178.201])
 by smtp.gmail.com with ESMTPSA id
 af79cd13be357-7d3901b12easm555313385a.67.2025.06.11.08.28.07
 for 
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 08:28:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ad9bf75d-46d8-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749655688; x=1750260488; 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=vF6Eu1t4nl7cgKzHCQTD+/J0Zt6/0RcO48KFHU6gbsA=;
        b=fjg3lxteYbKwKrmfiy1NhTU2hMW7OBgHDEBaFVb2tIzm2Gfg6mvVQDzikJ6E22HN2V
         O+dTXWznt7UqtBPbNQiF+pTLBUPIdKJ+5FN7txi7Mp6UgMRIM/MTcDBOLV7zQja0NHbR
         BpcxawZ8o/nuLkKtoOLBvmXsLwzEJzEozx4O0LEkXwYjXG0TNz0QCt6qFIKvDloDMVOr
         UemLdx8UN3j1/cT9ebKFN8e6ZIidqieeWakoBr6uPKhWR0RS92XHAMBYdZ5KtxMgX0Wi
         zJdFG6Vd9KvTKP/fLIp3NhSPyLZcglWqypxemURbEOg7/vpCGSsjTdSJF5J94qe0Cgaw
         QCuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749655688; x=1750260488;
        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=vF6Eu1t4nl7cgKzHCQTD+/J0Zt6/0RcO48KFHU6gbsA=;
        b=r1Zk3BVRmJ6wcQRD5W5bNQkCZvMlyCe1niXU+OSebCd9/Pbi1Napv30aLGjZGM+1Lc
         1ukG8BF6Iv6m8ybUDwLJOHrx3QP3l0/vsgjKxwk2E0B2n227ZH6ZscdQDt49V1R3Yj+t
         36gXqiwOGaZWABR4MyONHr5+3BwhRPQol5beOP4FYyFzEYN3tjOjOXiR4zhNeat4AiuG
         fOQyfcO7Cf5ycGVtVMliu5DE8XncGGIFGG+c2kwB2jELWA45uC0h1PR45upEVvsPxyf1
         X7Ncskku1uvYCo8ChpybDliowQ3qDMdvmIbHWGy85TMnMpnzhQI8XgPELEd8roq/l1yR
         n0lg==
X-Gm-Message-State: AOJu0Yxe1EfZZIG7tJHeDsgRTHmRmvmGhfhqahYQjAvNEq2Jp2Y14XT4
	/IurWeWkG3tiQWh1QdO57nJegxjPczaH45v/e7FgqVQciUPGtFMnr9SMp/iTcw==
X-Gm-Gg: ASbGncs+CVylwe5i0ac72zBYJ4D6vUlx/O8R/jpTh90ghXODsTaunJYIVdw+l+5yzL6
	6poPecLfkxj44+Sf6tNfYI9jCuxVSU+b2jMYGwXbG28tYz5eeRVWn+pJhA28eIe0VQqPJZpG97K
	HdavmYrn8YLGfDYr8fGHAKO/3b9I3JlnvrwoOWZJnGGA0B/eToLjxgEkDBdl+CA51IPwDsNDWAe
	Gq9ZsoQVDkOOKHhnwYi1dG1+Iphu4iRJU3Ufv4F5glCDJCDeJz5NSVpNCwG5G5hKa/Ivgy++rj4
	1kNlybwRHGQUPXb+xxWleRkuPbrfLVo8fqmoTNBKuVX55IM/4nhY+Udp+GCN7XUgNm4=
X-Google-Smtp-Source: AGHT+IFEE0C7q4UYbVk9Wh8w7hDd3dSYplNi08yYIkg/FlCM+mOW87dz4HapLnx9f9RNtFSZo6X75w==
X-Received: by 2002:a05:620a:2411:b0:7d2:25df:8127 with SMTP id af79cd13be357-7d3a88062famr486025185a.3.1749655688163;
        Wed, 11 Jun 2025 08:28:08 -0700 (PDT)
Message-ID: 
Date: Wed, 11 Jun 2025 11:27:52 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen: Strip xen.efi by default
To: xen-devel@lists.xenproject.org
References: <20250610101228.24460-1-freddy77@gmail.com>
 <02162717-25de-4ffb-a9c4-bf6d580c43bc@suse.com>
Content-Language: en-US
From: Demi Marie Obenour 
Autocrypt: addr=demiobenour@gmail.com; keydata=
 xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49yB+l2nipd
 aq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYfbWpr/si88QKgyGSV
 Z7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/UorR+FaSuVwT7rqzGrTlscnT
 DlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7MMPCJwI8JpPlBedRpe9tfVyfu3euTPLPx
 wcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9Hzx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR
 6h3nBc3eyuZ+q62HS1pJ5EvUT1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl
 5FMWo8TCniHynNXsBtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2
 Bkg1b//r6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nSm9BBff0N
 m0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQABzTxEZW1pIE1hcmll
 IE9iZW5vdXIgKGxvdmVyIG9mIGNvZGluZykgPGRlbWlvYmVub3VyQGdtYWlsLmNvbT7CwXgE
 EwECACIFAlp+A0oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELKItV//nCLBhr8Q
 AK/xrb4wyi71xII2hkFBpT59ObLN+32FQT7R3lbZRjVFjc6yMUjOb1H/hJVxx+yo5gsSj5LS
 9AwggioUSrcUKldfA/PKKai2mzTlUDxTcF3vKx6iMXKA6AqwAw4B57ZEJoMM6egm57TV19kz
 PMc879NV2nc6+elaKl+/kbVeD3qvBuEwsTe2Do3HAAdrfUG/j9erwIk6gha/Hp9yZlCnPTX+
 VK+xifQqt8RtMqS5R/S8z0msJMI/ajNU03kFjOpqrYziv6OZLJ5cuKb3bZU5aoaRQRDzkFIR
 6aqtFLTohTo20QywXwRa39uFaOT/0YMpNyel0kdOszFOykTEGI2u+kja35g9TkH90kkBTG+a
 EWttIht0Hy6YFmwjcAxisSakBuHnHuMSOiyRQLu43ej2+mDWgItLZ48Mu0C3IG1seeQDjEYP
 tqvyZ6bGkf2Vj+L6wLoLLIhRZxQOedqArIk/Sb2SzQYuxN44IDRt+3ZcDqsPppoKcxSyd1Ny
 2tpvjYJXlfKmOYLhTWs8nwlAlSHX/c/jz/ywwf7eSvGknToo1Y0VpRtoxMaKW1nvH0OeCSVJ
 itfRP7YbiRVc2aNqWPCSgtqHAuVraBRbAFLKh9d2rKFB3BmynTUpc1BQLJP8+D5oNyb8Ts4x
 Xd3iV/uD8JLGJfYZIR7oGWFLP4uZ3tkneDfYzsFNBFp+A0oBEAC9ynZI9LU+uJkMeEJeJyQ/
 8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd8xD57ue0eB47bcJv
 VqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPpI4gfUbVEIEQuqdqQyO4GAe+M
 kD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalql1/iSyv1WYeC1OAs+2BLOAT2NEggSiVO
 txEfgewsQtCWi8H1SoirakIfo45Hz0tk/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJ
 riwoaRIS8N2C8/nEM53jb1sH0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcN
 fRAIUrNlatj9TxwivQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6
 dCxN0GNAORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
 rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog2LNtcyCj
 kTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZAgrrnNz0iZG2DVx46
 x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJELKItV//nCLBwNIP/AiIHE8b
 oIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwjjVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGj
 gn0TPtsGzelyQHipaUzEyrsceUGWYoKXYyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8fr
 RHnJdBcjf112PzQSdKC6kqU0Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2
 E0rW4tBtDAn2HkT9uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHM
 OBvy3EhzfAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
 Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVssZ/rYZ9+5
 1yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aWemLLszcYz/u3XnbO
 vUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPthZlDnTnOT+C+OTsh8+m5tos8
 HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E
 +MYSfkEjBz0E8CLOcAw7JIwAaeBT
In-Reply-To: <02162717-25de-4ffb-a9c4-bf6d580c43bc@suse.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------SZh0OtwD2hklaDBkFlJdoMtq"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------SZh0OtwD2hklaDBkFlJdoMtq
Content-Type: multipart/mixed; boundary="------------V3KwT0mpNvkhMqI3MbZH4XUh";
 protected-headers="v1"
From: Demi Marie Obenour 
To: xen-devel@lists.xenproject.org
Message-ID: 
Subject: Re: [PATCH] xen: Strip xen.efi by default
References: <20250610101228.24460-1-freddy77@gmail.com>
 <02162717-25de-4ffb-a9c4-bf6d580c43bc@suse.com>
In-Reply-To: <02162717-25de-4ffb-a9c4-bf6d580c43bc@suse.com>

--------------V3KwT0mpNvkhMqI3MbZH4XUh
Content-Type: multipart/mixed; boundary="------------wWK53dGH2ECQccZtj6osH3oh"

--------------wWK53dGH2ECQccZtj6osH3oh
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 6/11/25 05:35, Jan Beulich wrote:
> On 10.06.2025 12:12, Frediano Ziglio wrote:
>> For xen.gz file we strip all symbols and have an additional
>> xen-syms file version with all symbols.
>> Make xen.efi more coherent stripping all symbols too.
>=20
> And the other difference (compressed vs not) still remains.
>=20
>> xen.efi.elf can be used for debugging.
>=20
> Hmm, that's the result of ...
>=20
>> --- a/xen/arch/x86/Makefile
>> +++ b/xen/arch/x86/Makefile
>> @@ -238,6 +238,7 @@ endif
>>  		> $@.map
>>  ifeq ($(CONFIG_DEBUG_INFO),y)
>>  	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) -O =
elf64-x86-64 $@ $@.elf
>> +	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(STRIP) $@
>>  endif
>>  	rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]*
>>  ifeq ($(CONFIG_XEN_IBT),y)
>=20
> ... objcopy. Having looked at the involved code in that utility, I mist=
rust its
> output from such a conversion to really be an exact representation of t=
he input.
> IOW I'd much rather use the original file. As a possible compromise, co=
uld we
> perhaps merely strip debug info, but retain the symbol table, matching =
the
> prior default for $(efi-strip-opt)?

The string table and all debug symbols need to be stripped.  This means n=
o
sections longer than 8 bytes and no debug information at all.  This is a
requirement of the Portable Executable specification, and I really do not=

want this to be messed with given UEFI Secure Boot requirements.
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
--------------wWK53dGH2ECQccZtj6osH3oh
Content-Type: application/pgp-keys; name="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

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

xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49y
B+l2nipdaq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYf
bWpr/si88QKgyGSVZ7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/
UorR+FaSuVwT7rqzGrTlscnTDlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7M
MPCJwI8JpPlBedRpe9tfVyfu3euTPLPxwcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9H
zx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR6h3nBc3eyuZ+q62HS1pJ5EvU
T1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl5FMWo8TCniHynNXs
BtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2Bkg1b//r
6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nS
m9BBff0Nm0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQAB
zTxEZW1pIE9iZW5vdXIgKElUTCBFbWFpbCBLZXkpIDxhdGhlbmFAaW52aXNpYmxl
dGhpbmdzbGFiLmNvbT7CwY4EEwEIADgWIQR2h02fEza6IlkHHHGyiLVf/5wiwQUC
X6YJvQIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRCyiLVf/5wiwWRhD/0Y
R+YYC5Kduv/2LBgQJIygMsFiRHbR4+tWXuTFqgrxxFSlMktZ6gQrQCWe38WnOXkB
oY6n/5lSJdfnuGd2UagZ/9dkaGMUkqt+5WshLFly4BnP7pSsWReKgMP7etRTwn3S
zk1OwFx2lzY1EnnconPLfPBc6rWG2moA6l0WX+3WNR1B1ndqpl2hPSjT2jUCBWDV
rGOUSX7r5f1WgtBeNYnEXPBCUUM51pFGESmfHIXQrqFDA7nBNiIVFDJTmQzuEqIy
Jl67pKNgooij5mKzRhFKHfjLRAH4mmWZlB9UjDStAfFBAoDFHwd1HL5VQCNQdqEc
/9lZDApqWuCPadZN+pGouqLysesIYsNxUhJ7dtWOWHl0vs7/3qkWmWun/2uOJMQh
ra2u8nA9g91FbOobWqjrDd6x3ZJoGQf4zLqjmn/P514gb697788e573WN/MpQ5XI
Fl7aM2d6/GJiq6LC9T2gSUW4rbPBiqOCeiUx7Kd/sVm41p9TOA7fEG4bYddCfDsN
xaQJH6VRK3NOuBUGeL+iQEVF5Xs6Yp+U+jwvv2M5Lel3EqAYo5xXTx4ls0xaxDCu
fudcAh8CMMqx3fguSb7Mi31WlnZpk0fDuWQVNKyDP7lYpwc4nCCGNKCj622ZSocH
AcQmX28L8pJdLYacv9pU3jPy4fHcQYvmTavTqowGnM08RGVtaSBNYXJpZSBPYmVu
b3VyIChsb3ZlciBvZiBjb2RpbmcpIDxkZW1pb2Jlbm91ckBnbWFpbC5jb20+wsF4
BBMBAgAiBQJafgNKAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCyiLVf
/5wiwYa/EACv8a2+MMou9cSCNoZBQaU+fTmyzft9hUE+0d5W2UY1RY3OsjFIzm9R
/4SVccfsqOYLEo+S0vQMIIIqFEq3FCpXXwPzyimotps05VA8U3Bd7yseojFygOgK
sAMOAee2RCaDDOnoJue01dfZMzzHPO/TVdp3OvnpWipfv5G1Xg96rwbhMLE3tg6N
xwAHa31Bv4/Xq8CJOoIWvx6fcmZQpz01/lSvsYn0KrfEbTKkuUf0vM9JrCTCP2oz
VNN5BYzqaq2M4r+jmSyeXLim922VOWqGkUEQ85BSEemqrRS06IU6NtEMsF8EWt/b
hWjk/9GDKTcnpdJHTrMxTspExBiNrvpI2t+YPU5B/dJJAUxvmhFrbSIbdB8umBZs
I3AMYrEmpAbh5x7jEjoskUC7uN3o9vpg1oCLS2ePDLtAtyBtbHnkA4xGD7ar8mem
xpH9lY/i+sC6CyyIUWcUDnnagKyJP0m9ks0GLsTeOCA0bft2XA6rD6aaCnMUsndT
ctrab42CV5XypjmC4U1rPJ8JQJUh1/3P48/8sMH+3krxpJ06KNWNFaUbaMTGiltZ
7x9DngklSYrX0T+2G4kVXNmjaljwkoLahwLla2gUWwBSyofXdqyhQdwZsp01KXNQ
UCyT/Pg+aDcm/E7OMV3d4lf7g/CSxiX2GSEe6BlhSz+Lmd7ZJ3g32M1ARGVtaSBN
YXJpZSBPYmVub3VyIChJVEwgRW1haWwgS2V5KSA8ZGVtaUBpbnZpc2libGV0aGlu
Z3NsYWIuY29tPsLBjgQTAQgAOBYhBHaHTZ8TNroiWQcccbKItV//nCLBBQJgOEV+
AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJELKItV//nCLBKwoP/1WSnFdv
SAD0g7fD0WlF+oi7ISFT7oqJnchFLOwVHK4Jg0e4hGn1ekWsF3Ha5tFLh4V/7UUu
obYJpTfBAA2CckspYBqLtKGjFxcaqjjpO1I2W/jeNELVtSYuCOZICjdNGw2Hl9yH
KRZiBkqc9u8lQcHDZKq4LIpVJj6ZQV/nxttDX90ax2No1nLLQXFbr5wb465LAPpU
lXwunYDij7xJGye+VUASQh9datye6orZYuJvNo8Tr3mAQxxkfR46LzWgxFCPEAZJ
5P56Nc0IMHdJZj0Uc9+1jxERhOGppp5jlLgYGK7faGB/jTV6LaRQ4Ad+xiqokDWp
mUOZsmA+bMbtPfYjDZBz5mlyHcIRKIFpE1l3Y8F7PhJuzzMUKkJi90CYakCV4x/a
Zs4pzk5E96c2VQx01RIEJ7fzHF7lwFdtfTS4YsLtAbQFsKayqwkGcVv2B1AHeqdo
TMX+cgDvjd1ZganGlWA8Sv9RkNSMchn1hMuTwERTyFTr2dKPnQdA1F480+jUap41
ClXgn227WkCIMrNhQGNyJsnwyzi5wS8rBVRQ3BOTMyvGM07j3axUOYaejEpg7wKi
wTPZGLGH1sz5GljD/916v5+v2xLbOo5606j9dWf5/tAhbPuqrQgWv41wuKDi+dDD
EKkODF7DHes8No+QcHTDyETMn1RYm7t0RKR4zsFNBFp+A0oBEAC9ynZI9LU+uJkM
eEJeJyQ/8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd
8xD57ue0eB47bcJvVqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPp
I4gfUbVEIEQuqdqQyO4GAe+MkD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalq
l1/iSyv1WYeC1OAs+2BLOAT2NEggSiVOtxEfgewsQtCWi8H1SoirakIfo45Hz0tk
/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJriwoaRIS8N2C8/nEM53jb1sH
0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcNfRAIUrNlatj9Txwi
vQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6dCxN0GNA
ORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog
2LNtcyCjkTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZA
grrnNz0iZG2DVx46x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJ
ELKItV//nCLBwNIP/AiIHE8boIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwj
jVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGjgn0TPtsGzelyQHipaUzEyrsceUGWYoKX
YyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8frRHnJdBcjf112PzQSdKC6kqU0
Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2E0rW4tBtDAn2HkT9
uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHMOBvy3Ehz
fAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVss
Z/rYZ9+51yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aW
emLLszcYz/u3XnbOvUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPt
hZlDnTnOT+C+OTsh8+m5tos8HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj
6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E+MYSfkEjBz0E8CLOcAw7JIwAaeBTzsFN
BGbyLVgBEACqClxh50hmBepTSVlan6EBq3OAoxhrAhWZYEwN78k+ENhK68KhqC5R
IsHzlL7QHW1gmfVBQZ63GnWiraM6wOJqFTL4ZWvRslga9u28FJ5XyK860mZLgYhK
9BzoUk4s+dat9jVUbq6LpQ1Ot5I9vrdzo2p1jtQ8h9WCIiFxSYy8s8pZ3hHh5T64
GIj1m/kY7lG3VIdUgoNiREGf/iOMjUFjwwE9ZoJ26j9p7p1U+TkKeF6wgswEB1T3
J8KCAtvmRtqJDq558IU5jhg5fgN+xHB8cgvUWulgK9FIF9oFxcuxtaf/juhHWKMO
RtL0bHfNdXoBdpUDZE+mLBUAxF6KSsRrvx6AQyJs7VjgXJDtQVWvH0PUmTrEswgb
49nNU+dLLZQAZagxqnZ9Dp5l6GqaGZCHERJcLmdY/EmMzSf5YazJ6c0vO8rdW27M
kn73qcWAplQn5mOXaqbfzWkAUPyUXppuRHfrjxTDz3GyJJVOeMmMrTxH4uCaGpOX
Z8tN6829J1roGw4oKDRUQsaBAeEDqizXMPRc+6U9vI5FXzbAsb+8lKW65G7JWHym
YPOGUt2hK4DdTA1PmVo0DxH00eWWeKxqvmGyX+Dhcg+5e191rPsMRGsDlH6KihI6
+3JIuc0y6ngdjcp6aalbuvPIGFrCRx3tnRtNc7He6cBWQoH9RPwluwARAQABwsOs
BBgBCgAgFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmbyLVgCGwICQAkQsoi1X/+c
IsHBdCAEGQEKAB0WIQSilC2pUlbVp66j3+yzNoc6synyUwUCZvItWAAKCRCzNoc6
synyU85gD/0T1QDtPhovkGwoqv4jUbEMMvpeYQf+oWgm/TjWPeLwdjl7AtY0G9Ml
ZoyGniYkoHi37Gnn/ShLT3B5vtyI58ap2+SSa8SnGftdAKRLiWFWCiAEklm9FRk8
N3hwxhmSFF1KR/AIDS4g+HIsZn7YEMubBSgLlZZ9zHl4O4vwuXlREBEW97iL/FSt
VownU2V39t7PtFvGZNk+DJH7eLO3jmNRYB0PL4JOyyda3NH/J92iwrFmjFWWmmWb
/Xz8l9DIs+Z59pRCVTTwbBEZhcUc7rVMCcIYL+q1WxBG2e6lMn15OQJ5WfiE6E0I
sGirAEDnXWx92JNGx5l+mMpdpsWhBZ5iGTtttZesibNkQfd48/eCgFi4cxJUC4PT
UQwfD9AMgzwSTGJrkI5XGy+XqxwOjL8UA0iIrtTpMh49zw46uV6kwFQCgkf32jZM
OLwLTNSzclbnA7GRd8tKwezQ/XqeK3dal2n+cOr+o+Eka7yGmGWNUqFbIe8cjj9T
JeF3mgOCmZOwMI+wIcQYRSf+e5VTMO6TNWH5BI3vqeHSt7HkYuPlHT0pGum88d4a
pWqhulH4rUhEMtirX1hYx8Q4HlUOQqLtxzmwOYWkhl1C+yPObAvUDNiHCLf9w28n
uihgEkzHt9J4VKYulyJM9fe3ENcyU6rpXD7iANQqcr87ogKXFxknZ97uEACvSucc
RbnnAgRqZ7GDzgoBerJ2zrmhLkeREZ08iz1zze1JgyW3HEwdr2UbyAuqvSADCSUU
GN0vtQHsPzWl8onRc7lOPqPDF8OO+UfN9NAfA4wl3QyChD1GXl9rwKQOkbvdlYFV
UFx9u86LNi4ssTmU8p9NtHIGpz1SYMVYNoYy9NU7EVqypGMguDCL7gJt6GUmA0sw
p+YCroXiwL2BJ7RwRqTpgQuFL1gShkA17D5jK4mDPEetq1d8kz9rQYvAR/sTKBsR
ImC3xSfn8zpWoNTTB6lnwyP5Ng1bu6esS7+SpYprFTe7ZqGZF6xhvBPf1Ldi9UAm
U2xPN1/eeWxEa2kusidmFKPmN8lcT4miiAvwGxEnY7Oww9CgZlUB+LP4dl5VPjEt
sFeAhrgxLdpVTjPRRwTd9VQF3/XYl83j5wySIQKIPXgT3sG3ngAhDhC8I8GpM36r
8WJJ3x2yVzyJUbBPO0GBhWE2xPNIfhxVoU4cGGhpFqz7dPKSTRDGq++MrFgKKGpI
ZwT3CPTSSKc7ySndEXWkOYArDIdtyxdE1p5/c3aoz4utzUU7NDHQ+vVIwlnZSMiZ
jek2IJP3SZ+COOIHCVxpUaZ4lnzWT4eDqABhMLpIzw6NmGfg+kLBJhouqz81WITr
EtJuZYM5blWncBOJCoWMnBEcTEo/viU3GgcVRw=3D=3D
=3Dx94R
-----END PGP PUBLIC KEY BLOCK-----

--------------wWK53dGH2ECQccZtj6osH3oh--

--------------V3KwT0mpNvkhMqI3MbZH4XUh--

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

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

iQIzBAEBCAAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmhJoIIACgkQszaHOrMp
8lN+CQ//UYz/TCZeZPLhFHcyHIK8P4/TRFzmBUjrw1+wxv3fcESlejDwxRYzw56r
J6L7isAshBbr0CML/t6nFhwug2PwZDDlQ6zmOw099cIGKINGfUjTH2+BbtlOiLX1
IFEEBu74FFKVf1ouLi9LCXb00uhiZLh37RGUX5gAMGqfuTp4RS0vWJUiqPrzoHmN
JhUj1ec3EATNR070CY7HGDMbM6Odim9a4hxffK940m2lVPwCsLm6m+BnXe6yud/w
oVFeKvXTo/iNwu5v35LV0XgwUp4cCrZ3YifXpzGrhCdc7RyzPNLNkWyzBKWTpph2
hSHUw35PNIs9R8iKsstXLkPIl8fy2eSI6AHF410rnlHJF4RpX3WYoLQRFvTaVDTK
MDVSoVtdGB8vYkq/AGYAwfFJmDGDxVGwrClGxc9CF3NO4XxmcLhIBUMfm0ImNB7j
kK5Ku2qvB4NE4ijepDa1gHY4WfApkN5a+NHLlG3adulPRoVVWOU7FOkz+XiNLsp2
3CO+PJx//4BzLGUBK3pJdhDjpm+qE5h8BWVaOwXCjh8levC94sPFtNfSL+Q6TGy8
Gs8RJ0htxLhkKadEhPuSxI/2KImYZrqHn0uWYwG9pKUadou31Vcn2LAOQrDBmbec
dQbl5tMUw6ewrgnujW4Iw1QMqjyDXx42YVmaefzyb6tzlXO5Aag=
=g8sL
-----END PGP SIGNATURE-----

--------------SZh0OtwD2hklaDBkFlJdoMtq--


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 15:34:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 15:34:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011894.1390425 (Exim 4.92)
	(envelope-from )
	id 1uPNSd-0003ZA-5B; Wed, 11 Jun 2025 15:33:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011894.1390425; Wed, 11 Jun 2025 15:33: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 1uPNSd-0003Z3-2J; Wed, 11 Jun 2025 15:33:55 +0000
Received: by outflank-mailman (input) for mailman id 1011894;
 Wed, 11 Jun 2025 15:33: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 1uPNSb-0003Ye-Mk
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 15:33:53 +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 79a3bca9-46d9-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 17:33:51 +0200 (CEST)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-452f9735424so18946105e9.3
 for ; Wed, 11 Jun 2025 08:33:51 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b2f5ee6f6desm7406427a12.26.2025.06.11.08.33.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 08:33:50 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 79a3bca9-46d9-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749656031; x=1750260831; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=p6IijF46VP9n2iEZKPwXmjPunatZLRSO+wk+fQ8PcOw=;
        b=W7cH9jpOFW4pGDEWulc3CGJrwJHUpPEtDzKCsxKriPIIT1NPtJDgE6eLM9VhTadTpA
         A3LPcvDUGRTsDkg7/BscK6bon4e7cbCMUudSXNSBIxYsouOf//Bp2nmR1E1GdPYoSdEp
         kfFvJAFXKDGTWFpZDFY9M0UxVY6vMzidPolHJU+oXLjIPyLQUKTXpVTft7ZCwVYMBTEy
         xNKHajweOIaAOzOc7+s4vMyBiRjW7dwvVxfWuub8GNORYw0jBQP9LrRnOOIw+TmrncE7
         1aS6Ne12Z49Ej26SZB4kBQ/qh23d7clZinYRpnE+5CkORAyybHowYX0TmOq70XP4PjUC
         lAwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749656031; x=1750260831;
        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=p6IijF46VP9n2iEZKPwXmjPunatZLRSO+wk+fQ8PcOw=;
        b=e4Wy5FwI3KeRTitV9YxrkST27cx8FGBQJ8GSQFvZYFRt45BOO4PrJw99qYlhXYCO0n
         gnY7g9jWpsxAyDS8xbBsOXJ63c0tHpivdS0DHNku6gko2OG08z71HMwOxxLQimvdkQVF
         O74Ev+pSBkJtT9E7wxSxgRuODxHBk91JK0iWAsmXqrP8u8DubFo0zH6msk+SKkWNiP5T
         bRI0sszNCRKQeg4/t627W0KoykCDt270AY1aLrVURZW86K7OOPslfFiw9r/Z3Ar4jNEn
         vX3aiCkvC1ehDSvCCVisnW3IPvFxivL9/6P7ZsSOYvM2HWmJA9UMNGRCGOtLQxeU8/4b
         GLEw==
X-Forwarded-Encrypted: i=1; AJvYcCVHIUoWWjDGO0bgNKtHPNGvUXiQPjg/IvlzB3OeG75+vR93brFLLwxwPZj1bLsAjjaV+uLMwLASA0g=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywx8E9AEYaePEsQJWdVx1Z1+5xuHOFKpLWdY4LY1K659iiRFxxT
	70x6+5Y05Hju7Y8u0Dq5Z0vs9kiibV2uFqN9EXx5nlsuAqdJpAM7GiGP1Ddyu7KBQg==
X-Gm-Gg: ASbGncvWTHKZQHbFKsLQcuRI11lXZlJK8MngZZ3ehVLSJnQgYdO+Kzg0g7NZvp2XvIk
	sFdJ7J3AvXztGxcHI1zjK/Laq4EBhhVFNtwSl7CbBf56n5/ccdq/bZZ1ddH95mXdlQNgZb/Wr51
	8YyQ1V7Un+7sY2OX6QwM8AxiqiPFQPWMv7msMijuTzNFIiOb9LeZ9zZzUf9mCaXGWA6dK+Va5zg
	G2eGy7TT6WZaSWel5j+cAOLwPemv0vYWGAN1uZTyEmixBc40ZiZyYCpY2PmuIVFXqSFSKsIADo9
	tydnPKaUyZMZSrJHFwyQAEmnUcouaF/fY6Zr/cSziDNOyX0Exu9JooViwU21CtqRGT4ijXr7vYh
	T/RYAOjdUpXKkVAekhlMJh/iqFo+gxylEmB61oNNm2GM+ahU=
X-Google-Smtp-Source: AGHT+IGmL/ZgGEyce42QTh7zlT/kgshY0AoyCu32gzSNc2VUX0HtW3EiQpjEIDNNsZJX41qwnWSkyA==
X-Received: by 2002:a05:6000:1a8f:b0:3a5:2182:bd17 with SMTP id ffacd0b85a97d-3a55869b80amr2849847f8f.19.1749656030660;
        Wed, 11 Jun 2025 08:33:50 -0700 (PDT)
Message-ID: <005a0e3a-dc8f-480f-8bb9-fd8eb164eb02@suse.com>
Date: Wed, 11 Jun 2025 17:33:44 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 03/18] xen/cpufreq: extract _PSD info from "struct
 xen_processor_performance"
To: Penny Zheng 
Cc: ray.huang@amd.com, xen-devel@lists.xenproject.org
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-4-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: <20250527084833.338427-4-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.05.2025 10:48, Penny Zheng wrote:
> @@ -201,14 +221,14 @@ int cpufreq_add_cpu(unsigned int cpu)
>      struct cpufreq_dom *cpufreq_dom = NULL;
>      struct cpufreq_policy new_policy;
>      struct cpufreq_policy *policy;
> -    struct processor_performance *perf;
> +    const struct xen_psd_package *domain_info;
> +    const struct xen_psd_package **domain_info_ptr = &domain_info;

Why's this latter variable needed? Can't you simply ...

> +    uint32_t shared_type;
>  
>      /* to protect the case when Px was not controlled by xen */
>      if ( !processor_pminfo[cpu] || !cpu_online(cpu) )
>          return -EINVAL;
>  
> -    perf = &processor_pminfo[cpu]->perf;
> -
>      if ( !(processor_pminfo[cpu]->init & XEN_PX_INIT) )
>          return -EINVAL;
>  
> @@ -218,10 +238,15 @@ int cpufreq_add_cpu(unsigned int cpu)
>      if (per_cpu(cpufreq_cpu_policy, cpu))
>          return 0;
>  
> -    if (perf->shared_type == CPUFREQ_SHARED_TYPE_HW)
> +    ret = get_psd_info(cpu, &shared_type, domain_info_ptr);

... pass &domain_info here, ...

> +    if ( ret )
> +        return ret;
> +    domain_info = *domain_info_ptr;

... also eliminating the need for this assignment? (Same again further down.)

> @@ -464,6 +505,17 @@ static void print_PPC(unsigned int platform_limit)
>      printk("\t_PPC: %d\n", platform_limit);
>  }
>  
> +static int check_psd_pminfo(uint32_t shared_type)
> +{
> +    /* check domain coordination */

Nit: Comment style (wants to start with a capital letter). Yes, there are many
bad examples in this file (some even visible in patch context here), but in new
code style guidelines should be followed.

> +    if ( shared_type != CPUFREQ_SHARED_TYPE_ALL &&
> +         shared_type != CPUFREQ_SHARED_TYPE_ANY &&
> +         shared_type != CPUFREQ_SHARED_TYPE_HW )
> +        return -EINVAL;
> +
> +    return 0;
> +}

Looks as if the function would rather want to return a boolean value.

And anyway - I can't really spot the need for this helper, as I also can't
spot ...

> @@ -545,14 +597,9 @@ int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *perf)
>  
>      if ( perf->flags & XEN_PX_PSD )
>      {
> -        /* check domain coordination */
> -        if ( perf->shared_type != CPUFREQ_SHARED_TYPE_ALL &&
> -             perf->shared_type != CPUFREQ_SHARED_TYPE_ANY &&
> -             perf->shared_type != CPUFREQ_SHARED_TYPE_HW )
> -        {
> -            ret = -EINVAL;
> +        ret = check_psd_pminfo(perf->shared_type);
> +        if ( ret )
>              goto out;
> -        }
>  
>          pxpt->shared_type = perf->shared_type;
>          memcpy(&pxpt->domain_info, &perf->domain_info,

... the need for this change. And even if there is a need, a follow-on
question would be how this relates to the subject of this patch.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 15:52:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 15:52:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011901.1390436 (Exim 4.92)
	(envelope-from )
	id 1uPNkF-0006VP-Kp; Wed, 11 Jun 2025 15:52:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011901.1390436; Wed, 11 Jun 2025 15:52: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 1uPNkF-0006VI-H3; Wed, 11 Jun 2025 15:52:07 +0000
Received: by outflank-mailman (input) for mailman id 1011901;
 Wed, 11 Jun 2025 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 1uPNkE-0006VC-K7
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 15:52:06 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on2062b.outbound.protection.outlook.com
 [2a01:111:f403:2416::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 031655a9-46dc-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 17:52:02 +0200 (CEST)
Received: from CY8PR12CA0003.namprd12.prod.outlook.com (2603:10b6:930:4e::8)
 by SN7PR12MB8148.namprd12.prod.outlook.com (2603:10b6:806:351::17) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.19; Wed, 11 Jun
 2025 15:51:57 +0000
Received: from CY4PEPF0000EE3F.namprd03.prod.outlook.com
 (2603:10b6:930:4e:cafe::54) by CY8PR12CA0003.outlook.office365.com
 (2603:10b6:930:4e::8) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.17 via Frontend Transport; Wed,
 11 Jun 2025 15:51:57 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CY4PEPF0000EE3F.mail.protection.outlook.com (10.167.242.17) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Wed, 11 Jun 2025 15:51:57 +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 Jun
 2025 10:51:56 -0500
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, 11 Jun
 2025 10:51:55 -0500
Received: from [172.27.195.250] (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, 11 Jun 2025 10:51:54 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 031655a9-46dc-11f0-a307-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=KHB6nAhXsv7H8Erj0uCHpEsk1d3tmn7W3el2zR+3aYvZeVf8LWc/taZ4aBxVm2pD0qvFTB5YHXhYJ4VOJtrLddmxNCEcvSMAGv5+6YSCy7thu1xil7XkotCRwOPal+fv7B2BAf6pP+Ex/633v9agaJVU6v0rOpfqNcIM3VIiL72xxfaoo9cjpaCbv9hXGpN/VnQqHnFTi8gCRYwT9ocSsx9p+dJt7nyTqMhUocur7MkR6vVgJXC/mn7InOgbWKqLitiB/4ew9/JLFeC6u/Abs63KNvR2f//+z0plIWjbP0B/SM75uAncY++BGtHNyRBFznEVOTd0+6Gkgy9IkiyThQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=6knYC8fsWowFRgs5B54grYDA2NIIDK6L3C975z9rfC0=;
 b=BHYgw/11TrWLhJqYww9AEINHKiwyfvGyuD4UheAaS+oNiMRUnuFkcTex4qRhQtJyve+RySKc0ADnsEyv1IUrDM7ZR+J6lLdL081JwwKO/FIn2pRq5s9tFmmbymGW3W0DyF8fAECTOqETs9PWYTz95M3MD0rJ2HtqoaQvQaz5vU9a/4WzR7GrrhSJorU5tqF/uDcny355RJc5Py9270lKTWArB64EjCIyrvwjcoM/II2dNFyn1rthN0USosUECnH2g1t72By/MYaBPJPyqJnbW+uXY+1zdG84sLHIHew6YhxLDPHT/6zFPDmtF1TGr1gOTjMj0/kpjyJT3G8/xQSHxQ==
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=6knYC8fsWowFRgs5B54grYDA2NIIDK6L3C975z9rfC0=;
 b=cuAPXshBMFHb1lcDexf1+YA1cj9WwSEYPcz0Eob1pvEal+aw69GK50C0QxcRFX8Xca3q68T8pkdT6hXaAnEZj6C5BMsaRgPgjWH4YMnNIY/4qm0+7yA/cpp6JBnGSj8rzbU6NHmJRy0xVvCDCSw1ii871dQ/nPM9zPOzMj8hcGc=
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: <12700a8a-a969-42ed-aba8-753ff9da9a44@amd.com>
Date: Tue, 10 Jun 2025 23:13:04 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/4] xen/xsm: Add XSM_HW_PRIV
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?=
	, "Daniel P. Smith" ,
	
References: <20250610225737.469690-1-jason.andryuk@amd.com>
 <20250610225737.469690-2-jason.andryuk@amd.com>
 <43725e7d-cb4c-44b7-a3e5-59d8d597c805@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <43725e7d-cb4c-44b7-a3e5-59d8d597c805@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: CY4PEPF0000EE3F:EE_|SN7PR12MB8148:EE_
X-MS-Office365-Filtering-Correlation-Id: fda30669-1b97-42f7-46b6-08dda8ffe561
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|1800799024|36860700013|7416014|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?SlJhdmV4dWE3em1taTlLdVhsdlY4cWV4VTVaSGMxUDJRSkg3bUFhaFYrMVo1?=
 =?utf-8?B?T0k4UURRMlZGM1pKbU9PZGpmeUtZb1IrUDQwZzh1OXZMQmwrN0x6Ri8zZ0pM?=
 =?utf-8?B?bHJCZk1pSVJqZnNmV1Z2ZVhwSEtWdjhXRTZkb3FRWEJpSTBROC84d1BlVC9o?=
 =?utf-8?B?dVF5Z2M3K2E5Yi9PaWZyY1gzQTRYR0s4ekN2NTY1RS9zMWk1cjdaSnZFL2dT?=
 =?utf-8?B?MnZXNElDRDRYNEVNY1VCSEtSYjdEMHNmcXkvRlkwTCt0cll6K0VFSVJRZWIy?=
 =?utf-8?B?VlBnUWYzR1ZDVFlsem1ybDNCUEJNTmozSWhHUmVWUjU1QUFWcS83bHlzUXRw?=
 =?utf-8?B?RjdhZVFmOFR2d1ltejBjR3hhdzYvUERxcHM3UUlJMlhGMVc5QTlwSkU0T25r?=
 =?utf-8?B?dU1DbzBUakdORWNTUklWakx4ZXV1a2JQRU9XR2tDbm4yeitnMkpmQVhYaU9P?=
 =?utf-8?B?d0NFV29iL0dTVXFHcDgzRFhlbk1mOFpWdlh2N1dDZHNKZzZYZnN0RVJRUGND?=
 =?utf-8?B?WkxKZE9kQW1UN1haUG93dTQ4NE1BTUNZcllTNFAwZEovcnpzRGNxOWlJbDNS?=
 =?utf-8?B?Z1ZzazF5Y3JjRktpb3dEM3VXbit5Y0FTYVFhWk1TZEppbVp3M0RjcFpZSjFK?=
 =?utf-8?B?OWRERHZ5WnpLWFg0UlJIT2ZvVldYWTNlVUxpUTUydjRBUGltNFk0cFdGanFp?=
 =?utf-8?B?dzI4Y2NiNVlHejV3bGNrcFF1QUFUcU56bFhudE9SSmNCT3B3THdpSnQyc2Ja?=
 =?utf-8?B?SmhBRFVQelRPNko2YVpLenA2dzR5ZzFZVy93cmVIY1ZtaUg2ZzUxU0RDMmEv?=
 =?utf-8?B?dFhzbnBQaHJMTC8yWFlyczVTZGwrci9pWXlsd09jZWZnaHh6UE1sQVplbjBQ?=
 =?utf-8?B?aGhrWHhYV2F3TmRxbHozd3AxaVJ5aUN5YVFNRVduZ0VDR3JXU3ZDZlBXRFJR?=
 =?utf-8?B?WEpNT2FrS3J2a0trYUZsQUxLcTFYaXEvVGdyKytZWDlPbndvOUpxVGNvWDlZ?=
 =?utf-8?B?NFduVzlHaXNTNmNpd202d25JNGQvMkRxTkNPc3FjQmFuM1BUS2oySjExaHNY?=
 =?utf-8?B?b0NxZHFIemJQRCtSSTV2d3dMdndJbnhHWEJVeHpUalJWVVhvaVJ6czlHa2My?=
 =?utf-8?B?S0lUWmhic2pnRG1BVE5QM3lyT1ZMWCtYcjIyN0hhcEtUTFYzYmJxVTZzZjZW?=
 =?utf-8?B?UU9JTXVZcUYweWRSWDdQeTNaaHZVZG5XT2NjNEZXaUJTV0l2R3dtRUJJV2JS?=
 =?utf-8?B?TkJnZlkzL0dkRnpiajZKMkFETUQwaVZ5aXZvZ0RmSFBURlpITnFSOUVoQnVJ?=
 =?utf-8?B?YW9pbXJxZlIzS0paR1RXanF2aHh0R2ZRKyt4UzFoVmdDOVV5cGU3MkJYL092?=
 =?utf-8?B?RjZPM3A4VWhvRXpPeFlmVHEvVFpieEVJSEFndkhlUVVIM1lKQk1GNVRLOG5I?=
 =?utf-8?B?a3RUVkJlR0lzN2t0YlJlb0prL3ZnWTRaUk9RZmVNTkNXWWg3UHBZZHNnYU5F?=
 =?utf-8?B?cGsyakNVT20vSXJZMVZmQlBzTm9MNnMxaVZrUEFQMURwOHJuMnRYZUVxVU40?=
 =?utf-8?B?UUQrM3gzcWhiRlVTdjVvRzJ5enRzUEJURnQ1MERpWDgrQzNxczdhZXdlS0ln?=
 =?utf-8?B?RzBmUjljN1JkUDhlb1dtYko3Zm8yUTdOOHgzOTFiNEt0bERBbXJuL0dVR0VT?=
 =?utf-8?B?cE5rMGxuWmZncklVWUhBZWFXVkZFVmNtYXp0cC9XZ3R3a3RuNXBKdzZETXVa?=
 =?utf-8?B?ZmtJd1ZuZFZ4dGlRQ3AwSVFSNDIzbms2UkpMSEEvZlhsUFRsdkFRamlDTGRt?=
 =?utf-8?B?NG9WaE1JcFdHN0VXd0FkQ1dLQ1FyTlpOUndBbHRnOVZ4YVBJNHdOdkVLUkFj?=
 =?utf-8?B?Q0xaeUhWbTNzVUhKV2U5TFZRc1pXa211NjhRam4zVDJyVDU3Tmp6dStTdWdz?=
 =?utf-8?B?K3hSQ2tVMWNBZHlQSDhHMncrR0N5c1ZNZlJIYi9oTkhkT1p4Sm5kWXhpb3dz?=
 =?utf-8?B?Vlhlbkh6UTFZN0M3eWQrbVVObW82aEN2Kys5QnI1bHRndVVCMEJLMkFXakt4?=
 =?utf-8?Q?yQMsai?=
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);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jun 2025 15:51:57.3951
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: fda30669-1b97-42f7-46b6-08dda8ffe561
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:
	CY4PEPF0000EE3F.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB8148

On 2025-06-11 09:02, Jan Beulich wrote:
> On 11.06.2025 00:57, Jason Andryuk wrote:
>> Xen includes disctinct concepts of a control domain (privileged) and a
>> hardware domain, but there is only a single XSM_PRIV check.  For dom0
>> this is not an issue as they are one and the same.
>>
>> With hyperlaunch and its build capabilities, a non-privileged hwdom and a
>> privileged control domain should be possible.  Today the hwdom fails the
>> XSM_PRIV checks for hardware-related hooks which it should be allowed
>> access to.
>>
>> Introduce XSM_HW_PRIV, and use it to mark many of the physdev_op and
>> platform_op.  The hwdom is allowed access for XSM_HW_PRIV.
>>
>> Make XSM_HW_PRIV a new privilege level that is given to the hardware
>> domain, but is not exclusive.  The control domain can still execute
>> XSM_HW_PRIV commands.  This is a little questionable since it's unclear
>> how the control domain can meaningfully execute them.  But this approach
>> is chosen to maintain the increasing privileges and keep control domain
>> fully privileged.
> 
> I consider this conceptually wrong. "Control" aiui refers to software
> (e.g. VMs or system-wide settings), but there ought to be a (pretty?)
> clear boundary between control and hardware domains, imo. As to
> "pretty" - should any overlap be necessary (xms_machine_memory_map()
> comes to mind), such would need handling specially then, I think. At
> the same time: The more of an overlap there is, the less clear it is
> why the two want/need separating in the first place.

So you are in favor of splitting control and hardware into distinct 
sets?  I am okay with this.  I implemented that originally, but I 
started doubting it.  Mainly, should control be denied any permission?

We aren't using the toolstack to build domains - dom0less or Hyperlaunch 
handles that.  This avoids issues that might arise from running the 
toolstack.

Thanks for your feedback.

-Jason


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 16:11:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 16:11:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011915.1390446 (Exim 4.92)
	(envelope-from )
	id 1uPO2R-0001aL-7K; Wed, 11 Jun 2025 16:10:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011915.1390446; Wed, 11 Jun 2025 16:10:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPO2R-0001aE-4f; Wed, 11 Jun 2025 16:10:55 +0000
Received: by outflank-mailman (input) for mailman id 1011915;
 Wed, 11 Jun 2025 16:10: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 1uPO2P-0001YX-NB
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 16:10:53 +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 9dfe0cb0-46de-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 18:10:39 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a507e88b0aso69552f8f.1
 for ; Wed, 11 Jun 2025 09:10:39 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-236030780bcsm90039105ad.15.2025.06.11.09.10.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 09:10:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9dfe0cb0-46de-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749658239; x=1750263039; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=CDi9+1roc6QnyLVJtsYDkxHsWwb49iH+ZbTAyzzTfiw=;
        b=aei4/mVpMi9B2atX9PPVxMm8IPQJjbufey+as7WgcB4t7YHTFpLiawN9WJjE+NrUJb
         5l5Az93HQ4kNDa66uX4RPAwlGERWBGA6F+I0TaxyC/mdQpDLP8eXwlG6DLOkUrBZfxKT
         pZLsGNxs6uw5MXBQwdmApR4+bKNaj7+RQDHaR9S19grhutBFNRnqguzGhjP0wu5IHSGn
         QL2Nq7HY25oKEJbMPwe/Bs45k/5OOlWbVyRSUJwzD9aBQ1dYYyOxgmXU/Q8f0+fOo99y
         TwaXS0Jiz8rzM6l2agP6MpNGdtaISYgsnUoZ6rJFKGF1hjHxDDIIwb/ZSPguWGFUesCN
         Ac6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749658239; x=1750263039;
        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=CDi9+1roc6QnyLVJtsYDkxHsWwb49iH+ZbTAyzzTfiw=;
        b=CBWaiBturOIGiat7JMYse7udl0OQJIHGpSG/1YppnekHwcCWoBd5Lh3X2YWEOVZ/yM
         6QMnglF++/bvKQR5LDYJcKNdWvB5XmqEIi1rpEWJeEuo//q9AOMAxHuUz7QVEJC7rgSO
         R+bRLHCrFX3fRmH72oor/MUY4d2dlzhmqFEPySLGmwqPJ39mABUx18D3ZNJQKZW11Nsy
         j9au8BaT3CHXKG4oB70hPE4GwR+Urua0dqJb926ktrqqsO0gkjO/J/rGO6a9QIPYF17S
         02KViwOtcgt5R1ASiXcRzoiBN+en7GWZfHhsHAg1/VQLRXSDMiKAWP3H11cDIPYvUrHG
         xdyA==
X-Forwarded-Encrypted: i=1; AJvYcCVfWsk+M8oHJsoZdjrF8xFBo675SNCe68wjL861gyF16GRMkYFm54zyN0kTGqujarjpGoeMZmk659I=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwnVU3+Aa9cQAS8JUQatHZZRIaM7GjHLYt3JJXk7D9PSYaTKYdO
	WJMNNpFVDUE03xGS9LnRgAn25JcniJwKz5irCzokxuLu49qkSzMqNadjgFSknRDW3g==
X-Gm-Gg: ASbGnctTjZ+RiZsD8L5hdvb+C+g2baLsFLVALIsoJmdfXjtVrwWD1DcZfMnJFy3LIbH
	RiAyvYBtxW2a8b/TyXAJXZOFMbvOUP6NW0xJlUDsCMsiA9QOsZLMPT8Ibra8vn3m9/7fLwUWYsp
	5DKyhOzOL6TscAzI6hQvwOz/fPVuBwCt69V8SbWgjf0GvaDEm9EG7QH8rA5efI/eI1Id+wbP5Gj
	IDKffncWJbPVUG1yO+NO8uT1baFScwu025f8vQfWAVejo4urIv4Axj54bvHlW51/cL3GZzoC6Nd
	zyIvcztiRq9LalTBhjP65NPw4pahNODKmWsK3sAKSwXDpx5jovk6n/8rZmXMxYxsJJH0rEt+Zil
	kG7bvVvsBSxEgPlK1mo+BqXYW72AqtzIXVMzGX6kjvbybRZE=
X-Google-Smtp-Source: AGHT+IHCXJlgj5HPygomuHDBAPEkDw/rMxaKDZv8waEMOSqcLyVnCm0f+xN2+j715GPaIeZJSPSCjA==
X-Received: by 2002:a05:6000:18ac:b0:3a5:28f4:24ad with SMTP id ffacd0b85a97d-3a558aa51admr3300434f8f.21.1749658239073;
        Wed, 11 Jun 2025 09:10:39 -0700 (PDT)
Message-ID: <0de0ea5c-64c9-4ac8-8e76-750cb3036419@suse.com>
Date: Wed, 11 Jun 2025 18:10:29 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 04/18] xen/cpufreq: introduce new sub-hypercall to
 propagate CPPC data
To: Penny Zheng 
Cc: ray.huang@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-5-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: <20250527084833.338427-5-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.05.2025 10:48, Penny Zheng wrote:
> @@ -635,6 +641,124 @@ out:
>      return ret;
>  }
>  
> +static void print_CPPC(const struct xen_processor_cppc *cppc_data)
> +{
> +    printk("\t_CPC: highest_perf=%u, lowest_perf=%u, "
> +           "nominal_perf=%u, lowest_nonlinear_perf=%u, "
> +           "nominal_mhz=%uMHz, lowest_mhz=%uMHz\n",
> +           cppc_data->cpc.highest_perf, cppc_data->cpc.lowest_perf,
> +           cppc_data->cpc.nominal_perf, cppc_data->cpc.lowest_nonlinear_perf,
> +           cppc_data->cpc.nominal_mhz, cppc_data->cpc.lowest_mhz);
> +}
> +
> +int set_cppc_pminfo(unsigned int acpi_id,
> +                    const 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 )

The !cppc_data part isn't really needed, is it?

> +    {
> +        ret = -EINVAL;
> +        goto out;
> +    }
> +
> +    if ( cppc_data->pad[0] || cppc_data->pad[1] || cppc_data->pad[2] )
> +    {
> +        ret = -EINVAL;
> +        goto out;
> +    }
> +
> +    if ( cpufreq_verbose )
> +        printk("Set CPU acpi_id(%u) cpuid(%d) CPPC State info:\n",
> +               acpi_id, cpuid);
> +
> +    pm_info = processor_pminfo[cpuid];
> +    if ( !pm_info )
> +    {
> +        pm_info = xvzalloc(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;
> +    pm_info->cppc_data = *cppc_data;
> +
> +    if ( cppc_data->flags & XEN_CPPC_PSD )
> +    {
> +        ret = check_psd_pminfo(cppc_data->shared_type);
> +        if ( ret )
> +            goto out;
> +    }
> +
> +    if ( cppc_data->flags & XEN_CPPC_CPC )
> +    {
> +        if ( cppc_data->cpc.highest_perf == 0 ||
> +             cppc_data->cpc.highest_perf > UINT8_MAX ||
> +             cppc_data->cpc.nominal_perf == 0 ||
> +             cppc_data->cpc.nominal_perf > UINT8_MAX ||
> +             cppc_data->cpc.lowest_nonlinear_perf == 0 ||
> +             cppc_data->cpc.lowest_nonlinear_perf > UINT8_MAX ||
> +             cppc_data->cpc.lowest_perf == 0 ||
> +             cppc_data->cpc.lowest_perf > UINT8_MAX ||
> +             cppc_data->cpc.lowest_perf >
> +                cppc_data->cpc.nominal_perf ||
> +             cppc_data->cpc.lowest_nonlinear_perf >
> +                cppc_data->cpc.nominal_perf ||
> +             cppc_data->cpc.nominal_perf > cppc_data->cpc.highest_perf )
> +            /*
> +             * Right now, Xen doesn't actually use highest_perf/nominal_perf/
> +             * lowest_nonlinear_perf/lowest_perf values read from ACPI _CPC
> +             * table. Xen reads CPPC capability MSR to get these four values.
> +             * So warning is enough.
> +             */
> +            printk_once(XENLOG_WARNING
> +                        "Broken CPPC perf values: lowest(%u), nonlinear_lowest(%u), nominal(%u), highest(%u)\n",
> +                        cppc_data->cpc.lowest_perf,
> +                        cppc_data->cpc.lowest_nonlinear_perf,
> +                        cppc_data->cpc.nominal_perf,
> +                        cppc_data->cpc.highest_perf);
> +
> +        /* lowest_mhz and nominal_mhz are optional value */
> +        if ( cppc_data->cpc.lowest_mhz > cppc_data->cpc.nominal_mhz )
> +        {
> +            printk_once(XENLOG_WARNING
> +                        "Broken CPPC freq values: lowest(%u), nominal(%u)\n",
> +                        cppc_data->cpc.lowest_mhz,
> +                        cppc_data->cpc.nominal_mhz);
> +            /* Re-set with zero values, instead of keeping invalid values */
> +            pm_info->cppc_data.cpc.nominal_mhz = 0;
> +            pm_info->cppc_data.cpc.lowest_mhz = 0;
> +        }
> +    }
> +
> +    if ( cppc_data->flags == (XEN_CPPC_PSD | XEN_CPPC_CPC) )
> +    {
> +        if ( cpufreq_verbose )
> +        {
> +            print_PSD(&pm_info->cppc_data.domain_info);
> +            print_CPPC(&pm_info->cppc_data);
> +        }
> +
> +        pm_info->init = XEN_CPPC_INIT;
> +        ret = cpufreq_cpu_init(cpuid);
> +#ifndef NDEBUG
> +        if ( ret )
> +            dprintk(XENLOG_WARNING,
> +                    "CPU %u failed to be initialized with amd-cppc mode, and users could only reboot and re-define cmdline with \"cpufreq=xen\"",
> +                    cpuid);
> +#endif

What use if the #ifdef here? The more that NDEBUG controls behavior of ASSERT(),
not that of (debug) logging.

> --- 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
> @@ -370,6 +371,10 @@ DEFINE_XEN_GUEST_HANDLE(xenpf_getidletime_t);
>  #define XEN_PX_PPC   4
>  #define XEN_PX_PSD   8
>  
> +/* CPPC sub info type */
> +#define XEN_CPPC_PSD   1
> +#define XEN_CPPC_CPC   2
> +
>  struct xen_power_register {
>      uint32_t     space_id;
>      uint32_t     bit_width;
> @@ -457,6 +462,30 @@ struct xen_processor_performance {
>  typedef struct xen_processor_performance xen_processor_performance_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_processor_performance_t);
>  
> +struct xen_processor_cppc {
> +    uint8_t flags; /* flag for CPPC sub info type */

A common way of commenting on such would be /* XEN_CPPC_... */.

In any event, here and ...

> +    uint8_t pad[3]; /* padding and must be zero */

... here (and of course anywhere else) - please adhere to designated comment
style.

> +    /*
> +     * Subset _CPC fields useful for CPPC-compatible cpufreq
> +     * driver's initialization
> +     */
> +    struct {
> +        uint32_t highest_perf;
> +        uint32_t nominal_perf;
> +        uint32_t lowest_nonlinear_perf;
> +        uint32_t lowest_perf;
> +        uint32_t lowest_mhz;
> +        uint32_t nominal_mhz;
> +    } cpc;
> +    /* Coordination type of this processor */
> +#define XEN_CPUPERF_SHARED_TYPE_HW   1 /* HW does needed coordination */
> +#define XEN_CPUPERF_SHARED_TYPE_ALL  2 /* All dependent CPUs should set freq */
> +#define XEN_CPUPERF_SHARED_TYPE_ANY  3 /* Freq can be set from any dependent CPU */

What's this? The exact same #define-s already exist in struct
xen_processor_performance, unless I'm missing a hard to notice spelling
difference. You can simply ...

> +    uint32_t shared_type;

... use the comment suggestion from above here as well.

> --- a/xen/include/xen/pmstat.h
> +++ b/xen/include/xen/pmstat.h
> @@ -7,8 +7,13 @@
>  
>  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);
> +int set_cppc_pminfo(unsigned int acpi_id,
> +                    const struct xen_processor_cppc *cppc_data);

Nit: Relative ordering would be nice to be consistent between this group
and ...

>  #ifdef CONFIG_COMPAT
> +struct compat_processor_cppc;
> +int compat_set_cppc_pminfo(unsigned int acpi_id,
> +                           const struct compat_processor_cppc *cppc_data);
>  struct compat_processor_performance;
>  int compat_set_px_pminfo(uint32_t acpi_id, struct compat_processor_performance *perf);
>  struct compat_processor_power;

... this one. (Personally I dislike additions at the top of any group,
as this gives the impression that the new stuff is "more important" than
what has been there already. See also how in a number of places we simply
sort alphabetically, to avoid the common "insert at top" and "insert at
bottom" patterns.)

> --- a/xen/include/xlat.lst
> +++ b/xen/include/xlat.lst
> @@ -168,6 +168,7 @@
>  !	processor_performance		platform.h
>  !	processor_power			platform.h
>  ?	processor_px			platform.h
> +!	processor_cppc			platform.h
>  !	psd_package			platform.h
>  ?	xenpf_enter_acpi_sleep		platform.h
>  ?	xenpf_pcpu_version		platform.h

Please obey to sorting in this file.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 16:59:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 16:59:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011942.1390456 (Exim 4.92)
	(envelope-from )
	id 1uPOnQ-0006jp-OQ; Wed, 11 Jun 2025 16:59:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011942.1390456; Wed, 11 Jun 2025 16:59: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 1uPOnQ-0006ji-Km; Wed, 11 Jun 2025 16:59:28 +0000
Received: by outflank-mailman (input) for mailman id 1011942;
 Wed, 11 Jun 2025 16:59: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 1uPOnO-0006jc-GJ
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 16:59:26 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on2062f.outbound.protection.outlook.com
 [2a01:111:f403:2416::62f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6cb229f8-46e5-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 18:59:23 +0200 (CEST)
Received: from CH5P221CA0012.NAMP221.PROD.OUTLOOK.COM (2603:10b6:610:1f2::16)
 by PH0PR12MB8100.namprd12.prod.outlook.com (2603:10b6:510:29b::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.19; Wed, 11 Jun
 2025 16:59:19 +0000
Received: from CH2PEPF0000009E.namprd02.prod.outlook.com
 (2603:10b6:610:1f2:cafe::79) by CH5P221CA0012.outlook.office365.com
 (2603:10b6:610:1f2::16) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.17 via Frontend Transport; Wed,
 11 Jun 2025 16:59:18 +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.8835.15 via Frontend Transport; Wed, 11 Jun 2025 16:59:18 +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, 11 Jun
 2025 11:59:18 -0500
Received: from [172.27.195.250] (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, 11 Jun 2025 11:59:18 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6cb229f8-46e5-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=bAet4mpyhMv8ZvNaToqj2QQtkgHDPf/5bahJ5TEA/mz4DA7+oYeHmV7ecbomaBnKq8cqCsukWTN/T5tliN0qD4EkqylY78gNMQmCkEXkNgcI3otFEeHO61HEonxDzT6CcWMLIcHj5U5iQeF2I5ec7dFtilSLLmI7Xi1NYW0tfaMwlKvoBKKLVTLEI5PWTcuenaEQsMRhShawEA9/erqgPWhwyTxZuxiD+LU3AN0VhWG9ZhbWckauBsDd+kUsdrmzFstEqH3b5WGAxZ4sptpYeze4wOWEzBtcPXy823No5yAmFJBxAVKKSh6l4R06bdtUvRBXrmWrNfn8bU3s+Hk5VQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=NNAsJZS8YQmk9IWUY3R/H/m7OaIgYl3mYOwfCK6EU4Y=;
 b=EOpNFjYACjWSM8WvMr0ALyHfDfgrAZQ4WqTSOLL0A1mVlO7cOEMjTA7FkpSQWQX5rzHh1ssDo5lzmzPNwc6POxkBqkmkIo5uIFcV+R4jIChuB/Kb257uexEHF/ojWs3oa3EMAjDpcIQldHGNeix83Mc64rBECqiH/uLdQ1HaHioD8071O+vmhE8MA2s5JAySx+GG+3AapMYpf89UvP2ZdeMJVBbNgcptChovoF2feWxnQ/oZeuSNN7g5bFtvFlTYez0wAGUpODBwcynvLgQJPNOcWnyokclyvhbb7IFYHdf7wHBe3XKuPv7frmNWoI7eny4Y2R3n6bPdB8++S59P2g==
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=NNAsJZS8YQmk9IWUY3R/H/m7OaIgYl3mYOwfCK6EU4Y=;
 b=1FlQx0eIAr1cUpGWFZag1hxx9gtLAG2TImlvY35pkqwa3Y1xG8IXXF4qqVNco+nhXBjyW4Ilmeom0IVRW9UBP6PJMOveFC/UI2H4KBtXW0G9nOc5Y1FbKFKVw90EmciI1lpbVLy969vtv/c0gMHXzfnDCK3HnhEmYWAVNWABdeQ=
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: <6cc69b45-7347-4250-ab32-a1e2857b7d23@amd.com>
Date: Wed, 11 Jun 2025 00:20:27 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/4] xsm/silo: Support hwdom/control domains
To: Jan Beulich 
CC: "Daniel P. Smith" ,
	
References: <20250610225737.469690-1-jason.andryuk@amd.com>
 <20250610225737.469690-3-jason.andryuk@amd.com>
 <0f47268e-0674-46e7-bfd4-8a395ee1ddf6@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <0f47268e-0674-46e7-bfd4-8a395ee1ddf6@suse.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: CH2PEPF0000009E:EE_|PH0PR12MB8100:EE_
X-MS-Office365-Filtering-Correlation-Id: dbe967d8-58a8-4916-71cf-08dda9094e45
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?SnlqNlNjZVUzZTFQdSthNmVvb2V6V2NXd1Q1THFyN2R0MzhBelNEZllvNUFT?=
 =?utf-8?B?aW8rSGczK01obmk3OW1tVUkyNjRXZkxLK0pYenFvL21FRFdPUzlCbVlDRnZX?=
 =?utf-8?B?U0cwNnluRHpLS2RyWkRxdHZJbloxRjJub2Y2Q1pPckZoYkM0SkhWWlNiVzBQ?=
 =?utf-8?B?b3FzTWsydFBFbnJ3U1lDZmxMU2g3c1ByWUppdnprQXBsQVJGTTFDYTRJSGFH?=
 =?utf-8?B?VU1LdWVJWGhPVmpNZEJJTXVqUzRFSTF6VEliSjJ2Q2xJc1I5WEJxMkoreUJE?=
 =?utf-8?B?RWZ4dDdPK1duTG9mWlcySEpNMlgrWkp5NDZBV0gxd0g4UnUzWXQ1eERMYVpv?=
 =?utf-8?B?NFBzNlNpSHZrSm8yK0g1VkprTnR5SkpzN2tGNEE5SVVWamxRc0owajQvcUNo?=
 =?utf-8?B?blR5WHFjQXBSNWY2MFZRek9ZQWFJMXpXdCtvL0FXd3hkK3c5Y1J2UnZQRi9l?=
 =?utf-8?B?ZTJTYnVTZFp4VWVlQXBRSU9iVklXK0UrV3NsN3l2UWpPcUk5MnpHOXRmSDdl?=
 =?utf-8?B?U2F2VDgxU0NMcVMxRSs0ZC9SOTk5L3pITEtYanBOZE9UUG5tZEdxam9jYWwz?=
 =?utf-8?B?V3lpaFdnY2wwUjFjV3dCcjZNZkFHVytYMHBmVXgzVElpRVY4dnV3YmRoNXlY?=
 =?utf-8?B?blN0K3FUbmYwR2FJTThzMDlWN0p1NzFNbnc0cGNyR0VqRStMaGhpeUxMTmlO?=
 =?utf-8?B?ekJSaU1lR01HZkk0Mzk0TGN2dHR3TGlzWGZyMW84RFliNmR5YmliVWRwQVV4?=
 =?utf-8?B?dHFOTTQzOGE5b3ZCaU5JYlNRQzRCaTJxaXJzRDFzQzhHNzA2MzVHQWxCbFd0?=
 =?utf-8?B?RTM3MGJJbGd3RlYyVFpIcGgrWE5sT2pWODlabGRwemt4ZElDcnJPUi9XN3N1?=
 =?utf-8?B?WFdDamxnVmUyK0lQcjEwaWUwYk91VkNZK0dWMXM4V1NvNzJPZmR5WmJIczdN?=
 =?utf-8?B?V214dDVzL2ZHYWhsZlNnRlh3S29xWXVTZG1CYWh0bjVxd3E4azBkeUFjQ2pR?=
 =?utf-8?B?aGxaUDNFVUI0d3dtUEdLWmFvSkJvWWY1bzdvK3ZKMlBMM3E2YXBSSjVvcGwr?=
 =?utf-8?B?VUFmS09FbVhjeGpMRzhuN01ST3F0aHVPVnZTQmFwdXg3SVNHUGNiUHkrVHZz?=
 =?utf-8?B?bm9sWXhSWlN3V2VKOVF6WG4zZDkyNndXUXhJRVVQTEpFb3lqa0ZhOWw3RDJx?=
 =?utf-8?B?aEQ0Z0wvc3NkektoaGJ6L2QrcDhscnlUZ1ByK1ZRWXNaSlRHclJBcGNFR0g1?=
 =?utf-8?B?bE5pamZIblBIakFnOW5KM21Tb1liZFUweHQvb3RMbk9DajYxbVdVVmkzRmcz?=
 =?utf-8?B?S1cwcElwL3VQNituc2FRY0hhd2NUMWJtOEQzbkZEWDdXZFY5c3AwdmROd1d4?=
 =?utf-8?B?dCtFbHdoWmNubXFJbW5qclpkRVZ2KzBiRFFOSXdDOEpxaTJNRjk3YytGeUts?=
 =?utf-8?B?SUZPcWZCSW1SUW9BSm5RRjlxMkE4azF3SnV0SWgyenpGcEYyamNGSGRlUUdn?=
 =?utf-8?B?NmNReUUyQkxaQjh0ZDVCSzE5MGIvRk9KZ3V5b0prV3RraGxOMGdOeGNtTVRa?=
 =?utf-8?B?dk9OelVRWkhpclg2UzY0RmxKb253ejRLRXEvNWJBZzc4dTFwUWZVQjZUQ1J2?=
 =?utf-8?B?bk9IZzdudVZqUHoxRVpSbFlRb1doUzU4Sk1LWkJJS1RWa3djMFVWVThuSjN4?=
 =?utf-8?B?MWkvN2FGL0NqbHpSUXdiU3ZPTzBnSTlzS2E5YnhJcGxuMldHMnM3OTBUQUN0?=
 =?utf-8?B?cExlMFBPaUYvdUl2bEE0ejZxZm9JcHNWOXREU2UxdWhIYVBhaUdjOWFjREVp?=
 =?utf-8?B?WnAxMC9zL2pRQVo4ek43KzZ3QlFBWFE0UjluR2p6N0w1bmFyZDlMUFA1dlBM?=
 =?utf-8?B?SnIxS0FVbis1OTdSV3BXdGNNdDRJQ1dpVWtQTm1jT0lma3lEbldhclpML3JD?=
 =?utf-8?B?WGxJallKaVlGRFk3STVTcUdvYkNnM1k5VUlOdjVyaXIxdWduemlrV1VxTUkx?=
 =?utf-8?B?aUtPaTB2QXVMQ0xVWWNpVU5LdGE5SWFXS3hjamswUjRMS2lHU1hqcUlta3pJ?=
 =?utf-8?Q?JZLQly?=
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: 11 Jun 2025 16:59:18.8900
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: dbe967d8-58a8-4916-71cf-08dda9094e45
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: PH0PR12MB8100

On 2025-06-11 09:17, Jan Beulich wrote:
> On 11.06.2025 00:57, Jason Andryuk wrote:
>> In a disaggregated environment, dom0 is split into Control, Hardware,
>> and Xenstore domains, along with domUs.  The is_control_domain() check
>> is not sufficient to handle all these cases.  Add is_priv_domain() to
>> support allowing for the various domains.
>>
>> The purpose of SILO mode is to prevent domUs from interacting with each
>> other.  But dom0 was allowed to communicate with domUs to provide
>> services.  As the disaggregation of dom0, Control, Hardware and Xenstore
>> are all service domains that need to communicate with other domains.
>>
>> To provide xenstore connections, the Xenstore domain must be allowed to
>> connect via grants and event channels.  Xenstore domain must also be
>> allowed to connect to Control and Hardware to provide xenstore to them.
> 
> Are you suggesting that SILO at present is incompatible with a Xenstore
> domain? silo_mode_dom_check() in its original form has no special
> precautions, after all.

Yes, it is incompatible with the current silo_mode_dom_check().  Only 
Control domain is allowed to use grants and event channels with a domU. 
A Xenstore domain would be denied.

Xenstore stubdom only exists for x86 today.  My limited attempts to run 
xenstored in an dedicated Xenstore ARM Linux domain have failed.

>> Hardware domain will provide PV devices to domains, so it must be
>> allowed to connect to domains.
> 
> As a built-in policy, isn't this already going too far? There could
> conceivably be configurations with only pass-through devices in use, in
> which case neither grants nor the event channels operations intercepted
> by SILO would be required.

Such a domain wouldn't have any PV devices configured?  I don't think 
this changes anything compared to today.

Both sides need to be configured and opt-in.  Hardware is a system 
domain, so it should be possible to allow grants and event channels. 
But they won't be used unless configured.

>> That leaves Control.  Xenstore and Hardware would already allow access
>> to Control, so it can obtain services that way.  Control should be
>> "privileged", which would mean it can make the connections.  But with
>> Xenstore and Hardware providing their services to domUs, there may not
>> be a reason to allow Control to use grants or event channels with domUs.
>> Still, Control is privileged, so it should be allowed to do something if
>> it chooses.  Establishing a grant, or event channel requires action on
>> both sides, so allow for the possibility.  This does open up an argo
>> wildcard ring from domUs, FWIW.
> 
> Along the lines of my reply to patch 1, I think Hardware and Control
> need to have a pretty strong boundary between them. It's hard to see,
> for example, whether grant map/copy/transfer would indeed make sense
> between the two.

The Hardware domain might provide a PV device to Control?

I've tested removing control:
static bool is_priv_domain(const struct domain *d)
{
     return is_xenstore_domain(d) || is_hardware_domain(d);
}

And that works in my limited ARM dom0less testing.  The toolstack isn't 
really exercised in that case.  It seems strange that the privileged 
control domain is *not* allowed though.

> Similarly I'm not convinced a strong boundary isn't also needed
> between Xenstore and Hardware.

If hardware is providing PV devices to domains, it will need access to 
Xenstore.  I don't see how you can get around it.

I tried to explain this in the first paragraph.  SILO's purpose was to 
isolate domUs from each other, but allow it to access dom0.  dom0 
embodies the control, hardware, and xenstore capabilities.  So as a 
first approximation, each of Control, Hardware, and Xenstore should be 
allowed to communicate with domUs.

domUs needs to communicate with Xenstore and Hardware for PV devices.

Xenstore provides Xenstore access to Hardware.

Control would want Xenstore access.

I don't know if this helps, but here's a table:

     | CTL | HW  | XS  | domU
----------------------------
CTL |     |  ?  |  y  |  ?
HW  |  ?  |     |  y  |  y
XS  |  y  |  y  |     |  y
domU|  ?  |  y  |  y  |  x

Control and Hardware would be y if we allow PV devices

Control and domUs - I don't have an immediate rational for them.  Except 
that Control is privileged.  I've been running xenconsoled in Hardware. 
If xenconsoled is in Control, then access would be required.

>> --- a/xen/xsm/silo.c
>> +++ b/xen/xsm/silo.c
>> @@ -20,6 +20,12 @@
>>   #define XSM_NO_WRAPPERS
>>   #include 
>>   
>> +static bool is_priv_domain(const struct domain *d)
>> +{
>> +    return is_xenstore_domain(d) || is_hardware_domain(d) ||
>> +           is_control_domain(d);
>> +}
> 
> This construct expands to two evaluate_nospec(), which likely isn't
> wanted. Some open-coding may be pretty much unavoidable here.

Thanks, yes, good point.

> (I'm
> surprised it's not three, i.e. I find it odd that is_xenstore_domain()
> doesn't also use that guard.)

It looks okay to me.  There were only 2 uses until I added a 3rd in the 
dom0less code.  The XSM check has evaluate_nospec() and the other 2 uses 
aren't security critical - Setting a domain info flag, and __init code 
for dom0less.  Maybe moving the evaluate_nospec() would be safer in case 
use grows in the future, but it looks okay to me today.

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 17:14:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 17:14:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011950.1390465 (Exim 4.92)
	(envelope-from )
	id 1uPP2F-0000zG-U6; Wed, 11 Jun 2025 17:14:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011950.1390465; Wed, 11 Jun 2025 17:14:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPP2F-0000z9-RF; Wed, 11 Jun 2025 17:14:47 +0000
Received: by outflank-mailman (input) for mailman id 1011950;
 Wed, 11 Jun 2025 17: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 1uPP2E-0000yl-HC
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 17:14:46 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on2060d.outbound.protection.outlook.com
 [2a01:111:f403:2407::60d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9158f3e0-46e7-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 19:14:44 +0200 (CEST)
Received: from BY3PR04CA0030.namprd04.prod.outlook.com (2603:10b6:a03:217::35)
 by CY5PR12MB6600.namprd12.prod.outlook.com (2603:10b6:930:40::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.19; Wed, 11 Jun
 2025 17:14:40 +0000
Received: from MWH0EPF000971E3.namprd02.prod.outlook.com
 (2603:10b6:a03:217:cafe::24) by BY3PR04CA0030.outlook.office365.com
 (2603:10b6:a03:217::35) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.22 via Frontend Transport; Wed,
 11 Jun 2025 17:14:40 +0000
Received: from SATLEXMB03.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.8835.15 via Frontend Transport; Wed, 11 Jun 2025 17:14:40 +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; Wed, 11 Jun
 2025 12:14:39 -0500
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 Jun
 2025 12:14:39 -0500
Received: from [172.27.195.250] (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 Jun 2025 12:14:37 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9158f3e0-46e7-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=mmMVXrBebK9KgqMvcrI0N2plMO01rwuLhat0IIss5iqfaLl/qvNcCqzEheOsGVNeDdAj2E5yNOdonwI5rrulsZ6/RHhpr+b2GYO0FfUkeCAqSDqamVcID5P9RJ+aRr7JXmA5Bvxy4FabvRlPBzNW6VBvPRM7St7vVs95D6z03+822JIhSlkbEhqsBxvuDIzxVEdpJHC6+OXxq9G2fLsgaoJ3yn/DcYg7j8dqmv+TTODKQgsgiuH2i38BDS9GcNm2B18p0OECMN4r60M9L5VkvB9eQAaU4ISMA7H4rHPqjJnsgvbeN5wGMI0+UEncY0/s8DUyfP97lLXhQ7JF539jjA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Et0YllRS4jurYtI9iva30mNVvtIvpzZkSX2b8rff/Rk=;
 b=kbyqTbwXJiO0joBLqwjgv91/C/r3SI5JSMMJo3KUJUWIEfhQW/oAQlu+C3tkKTuyfDjdlKY77ImnS2m242DizVraociXXTixPMp+igByZv/kL1KNEeCjONgzZNXChrObx7PSDjRxAH6z/JPkTbhi8aM4O8luf35OTvGcmRhwZiqJMz1SaBJiZbaRErt+CydrC/lJUSQBY/zmR7BzPWYflWuyRN9puNY8SVOaNvXCxJF4HOeqQaWUKpf/RGNV1okoUSsBGzTrwvv5I0/eihHf/fofaOzoPpeWhki2A39gin+OwDamHEEsR6FoErbC9bOXpWr8osYnJU3sSVeQnAm+pw==
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=Et0YllRS4jurYtI9iva30mNVvtIvpzZkSX2b8rff/Rk=;
 b=bXVcEGxgVosMjIOexe9yFKcQtPAJu/exKc0XEI3LmFeYrYzYgyLUFaZAQ62ksHTOK4g1HmLKmo7xzXPdYc97qKzNFuAIAebWXrJtb/TlG4FMzshq6eQigrP4v11eAkn8t+/wi4GgqfB5ny9fdjYX+fyas3zaJ/K++bDWd2MlBX8=
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: <9819e041-3b4a-4e5f-b391-149e0900f286@amd.com>
Date: Wed, 11 Jun 2025 00:35:45 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/4] xen: Add DOMAIN_CAPS_DEVICE_MODEL &
 XEN_DOMCTL_CDF_device_model
To: Jan Beulich 
CC: Christian Lindig , David Scott
	, Anthony PERARD , Andrew Cooper
	, Michal Orzel , "Julien
 Grall" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	, Stefano Stabellini , Bertrand
 Marquis , Volodymyr Babchuk
	, "Daniel P. Smith"
	, 
References: <20250610225737.469690-1-jason.andryuk@amd.com>
 <20250610225737.469690-4-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 (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MWH0EPF000971E3:EE_|CY5PR12MB6600:EE_
X-MS-Office365-Filtering-Correlation-Id: 91e6e92b-c828-4ae1-14d4-08dda90b7365
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|7416014|376014|82310400026|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?Q1N2M3dYdWpRdkJveVJ0dmZ0MTBsMHlpYXRjK1VraDNRTTRSWnZTNEt5ajk0?=
 =?utf-8?B?T1ozMmNSbmVsK2RsM2t3Ky9qUXR2ZE1UTFZXSUZ1S0VDeTRQYVVQV0hCcjVr?=
 =?utf-8?B?TGExM2h4QkpwVFlBb3lBemlzMzhsVUEvSC9lUkFkRXF4bVRSaWs1REdmV0ZJ?=
 =?utf-8?B?RzFIV21ZSjlwd3hlUk0reVdsdE5TOVYvZzVIWTN5SW10WHNvalorYVhuQnds?=
 =?utf-8?B?ZmltblhHS3p2MGVPeTdiSnRZSitxWlFGVW5YUDNaR3F0Y1JmODloRm92VXM4?=
 =?utf-8?B?RWV2amFmY09YK0NDWVNOcVA0cGNwamw4c0NXM3NMZXdBcTY3M3BSTitjS2xw?=
 =?utf-8?B?VksxMkd4N1kybkFXc1hDUWExSVI1WTVaMWI3YTBYbXV2RENhNDhTK0pZbUQ5?=
 =?utf-8?B?NGlTQkRieDBrM0J2NVpRNlRKVnRtb1luUDZNVmhFS01vSk9nSGpNWHFXcW1i?=
 =?utf-8?B?Rm80d0FwVG8yUkJNQmgwZDQvTkpwN295NzJaaGxhazFub3I3Um5mTGtOdHUv?=
 =?utf-8?B?dTlFQjBVaFQwVFdrcW5HOU5BbmYwZFRhUW9iT2xYOTFDZkttUnNCcUMzS3Jz?=
 =?utf-8?B?OHh4bXdJWlVlTXJXVTNEVEhka2RJSkYrMmtXUWR1bHRVNDcvMzVvSnJoOWlY?=
 =?utf-8?B?cFRjN2ZwS2RKNThkTG0zb2NBcUdtMk1VN1ZCRWN2bGRUUE9meEoyTXRaZkpZ?=
 =?utf-8?B?bEtWNUhsRWJveTcrTStxcFM1Si9UZjNPQUFzempLdStpa1ZITzkxd3Fjb1I0?=
 =?utf-8?B?ZUoxVEEzT1N1VUZCYnJ3OGRYQ1RoTWlMV2MzMVhEdVFtUWR2NmpLSi8xa3NK?=
 =?utf-8?B?bmdESlA1SzVTL09TYUVUdmhsejViYVlRcUdCb0lQTy9uVEppd2lhMElYZk9k?=
 =?utf-8?B?US9VZGNuYTViTkRRVUc1NkJKTTV1UXM5NUlKKzF0bVVFZWQvTzRlTmx0NWE0?=
 =?utf-8?B?cUp0c3h1cHB4WVZvUFkxSS82cFE4S0RNN3B1NFpSMHNjZjFvbEc1UW1sVytv?=
 =?utf-8?B?R1ZlSis1NThhZWdrZitZaDJMdjVyUERyY1RnVGM5aE9tMVBuL2w4WXlYUzRi?=
 =?utf-8?B?cXB5aHFOQVd6ZmJMZDkzNXo5MHpweUtXMHVSMGJ4STVUbjUyaDVIOUpodmdO?=
 =?utf-8?B?SEhCbDJTTkpCUE1qN2VIYU14RGVNcERNeVVUSHFka0FpbU54TlJSRlZKV1U0?=
 =?utf-8?B?MVVPWVFRNktqR2JTS3hMZklYRnlCZkl1bi9HeGtWSmdsb1RkY1Y1QTBMZmRi?=
 =?utf-8?B?WkFCT3JNTzJNYU9kNG1ycFdaWHdKMjNkNzBCbnZNaDFiU2FlTGF0aGVYaERo?=
 =?utf-8?B?NkdRKzUxTER0cFU3eGNpdk1FUHYvM09HWnRZYUY3bENYRXc5Tzc3eTUzaDZN?=
 =?utf-8?B?cDBTZVlCVGxRSGY1QVVyTGVENlR5aU45SE5Hb2pTQzBNanhsV05wZUFYbk43?=
 =?utf-8?B?dVIwY1RZRHdmY3RIYjlrZllCZGRKalRqQis1UVdVcW1LV0NTV3NQdzlrRG56?=
 =?utf-8?B?NDArZi9ZU2diNzUzb2xzbXlVTHNnMEh4REMyUmlPZ3J6K09NZ0ZOT1QzYzZj?=
 =?utf-8?B?b1hkUDhSblFkMStoUHVHMkJ0TitTcDdpN0RCZ0JsUGV4N3ZBR0phS2FvbURH?=
 =?utf-8?B?UEFJcTBEdFhPVU5JZE52NVkrUzcrVDFkdkgxZi8xWmdtT3JVdHRYc1V6NERh?=
 =?utf-8?B?SmI5clg3UWdpdEZTSEUzWFByS25QMHB2T0RrMkU4SGJpdXF3eUVrQVRGZVFL?=
 =?utf-8?B?SHEzQ2szWVJWUjNEZWFsZmVRY0wxZnhzRXU2OEovbDhENTJNaUdYVjdzeHI3?=
 =?utf-8?B?SGU4ZmJuUUxqMjBXZ29RcGdaQkF6dWw3ZnhsQ1prZTlPTmRKZDhaZEJremp1?=
 =?utf-8?B?a0ZSZUpBSzNucG5lTiswZGdqdk1zUlMrdnQvMVYzS0dPOUhuUFExWXFSRVp5?=
 =?utf-8?B?RU95UU4wZzJVeHhXRCs4RU1rclFQZU0ybncyQ3J6cHBKRjMyTUpFSlFubkN0?=
 =?utf-8?B?eTdrZFlUT2loZC8wNk92bnEvMlk2T3BBT0ZNcG9mMFhsVHZEakJQTjJoQzBx?=
 =?utf-8?Q?c4V0Kd?=
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)(7416014)(376014)(82310400026)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jun 2025 17:14:40.0746
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 91e6e92b-c828-4ae1-14d4-08dda90b7365
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:
	MWH0EPF000971E3.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR12MB6600

On 2025-06-11 09:24, Jan Beulich wrote:
> On 11.06.2025 00:57, Jason Andryuk wrote:
>> To add more flexibility in system configuration add the new
>> DOMAIN_CAPS_DEVICE_MODEL flag and XEN_DOMCTL_CDF_device_model.
>>
>> Thie new flag corresponds to allowing XSM_DM_PRIV for the domain.  This
>> will enable running device model emulators (QEMU) from the assigne
>> domain for multiple target domains.
>>
>> Stubdoms assign target allowing the stubdom to serve as the device
>> model for a single domain.  This new flag allows the single domain to
>> provide emulators for multiple guests.
>>
>> The specific scenario is a disaggregated system with the hardware domain
>> providing device models for muitple guest domains.
> 
> Why the hardware domain? Unless a DM also needs access to some of the
> physical hardware, it ought to run in a separate domain. Conceivably
> such a domain could service multiply guests, so maybe the "single
> target" concept presently used for stubdom simply needed extending?

One configuration is the hardware domain running QEMU for the 
virtio-gpu.  In an earlier iteration, I allowed XSM_DM_PRIV for 
is_hardware_domain().  Rightfully, there was some questioning of that 
hardcoding.  Adding a new flag allows it to be configurable.

Maybe target could be extended.  I was thinking that could be left for 
the stubdom case as it is today.  i.e. a 1-1 device model.  But a 1-N 
case could be handled this way.

Today dom0 XSM_DM_PRIV falls through to is_control_domain().  The idea 
was place a new check directly corresponding to XSM_DM_PRIV.

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 17:22:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 17:22:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011968.1390495 (Exim 4.92)
	(envelope-from )
	id 1uPPA8-00035l-81; Wed, 11 Jun 2025 17:22:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011968.1390495; Wed, 11 Jun 2025 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 1uPPA8-00035e-4w; Wed, 11 Jun 2025 17:22:56 +0000
Received: by outflank-mailman (input) for mailman id 1011968;
 Wed, 11 Jun 2025 17:22: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 1uPPA6-0002dK-BI
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 17:22:54 +0000
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com
 [2a00:1450:4864:20::330])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b563be29-46e8-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 19:22:53 +0200 (CEST)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-451d3f72391so93305e9.3
 for ; Wed, 11 Jun 2025 10:22:53 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-45325217c0bsm27303695e9.33.2025.06.11.10.22.52
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 11 Jun 2025 10:22:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b563be29-46e8-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749662573; x=1750267373; darn=lists.xenproject.org;
        h=content-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=GJdgiHOwfWzJfwlUoTb0DBDPl6XGoOntK+kYSINp4iw=;
        b=AgHhl7dYaSD2ntPPLdXWB6Ok/fNJSc72mjLNoSXXZlIDHCCZ5IKtnO1Mor+2dInnZF
         zWJaaRqVD/xqReIkKLFxAfIYnGswz52P9TZ6dt/5KwlpLsShkfJcg+EhulAh6JoB7EH5
         wXTQA5U/huNUjlAICQBL75ql0lsZUdYCrr/pY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749662573; x=1750267373;
        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=GJdgiHOwfWzJfwlUoTb0DBDPl6XGoOntK+kYSINp4iw=;
        b=DaYrfu0SllpF3qeJIC+78Wiz2UeUodU7Jdqa1M0tT6MlKLZGS6Sn3ZTcUSS4HI3qLb
         6GfdRD+nUwjl7+7ReHZ9gNN/VyKem+u+CAoO0YmQmwEGoZfv9tompZfOftN3p9Td7rMi
         kdbmyfNF3QEbYIK6Ag9Sajwco1G/aex32ETuRjx/FWHCjFIVHajQ9QA+sisYmRqNlTeD
         2UgHu0dbweFSzrJwJC4TYa9r8+LNGKaGKV0lCk+LCVGBTdacQL/yyaGDrU27u6iUQgR4
         ANJR7nf/HXILr1hOrpqRi+J63bMso4ebz7UZRGhzhGh5wrfjxPbwd0fTKGbfZ3ucHI1V
         CKqw==
X-Gm-Message-State: AOJu0YzHD5zSTroLHL6t9OmczOIaUeBglqfQ+Nm+3NO1SgLN6AlftD2o
	LpBTLiMmeFtY12HosnJesv/erJ5/KpG1azcAp8j/XEbfzwIpyyK0r7Y/befcg6pdVF8zb7NfpCe
	VaPsL
X-Gm-Gg: ASbGncsTwVFnAiZc+727wQIffPi6J+i2YO0F7vktWb2YFtthrBkalBlSlfJceyGzbMK
	Q6Ab64kVfXuN1ijY60PlmKkUF5MZCMgyR0zOVb/CMN5mp6Un514QMw3Vc0yJ7Y2UQZabSZHssPf
	/MAoGpZfQ328nRW3al+0Q8CHzEEXeepekyhZhmlNeWWQdnRSmB8hr31pEAdCazxTKEiDLYiyOvt
	sypHI7YTd6Yj1wQWPRXi0IURn4XPKfx2s/lbd7kWTNhctdpgD/J2bg0qwISKAsmipBbM3vlRZ8c
	LsENO+C8vpq3v0ZXJnXJUcUvGc74rQ7AZxK8fXfxMLQ3yjuSxvI2N4E6s8t+Q4i2Z1CgKqFB4GV
	uuxHcRKTkQcr2wSb/rznYwVrq7SqHsEjy8ps=
X-Google-Smtp-Source: AGHT+IEUIPDE6+hbVBrOpvdAglF9TBj3iPOuBLOi+lUVI2lkYz3YeRmcVwLvDsIpM7oCwbJvfIznJQ==
X-Received: by 2002:a05:600c:4ecb:b0:453:9b3:5b67 with SMTP id 5b1f17b1804b1-4532b966b65mr5884535e9.24.1749662572848;
        Wed, 11 Jun 2025 10:22:52 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH 3/8] kconfig: turn PDX compression into a choice
Date: Wed, 11 Jun 2025 19:16:31 +0200
Message-ID: <20250611171636.5674-4-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250611171636.5674-1-roger.pau@citrix.com>
References: <20250611171636.5674-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Rename the current CONFIG_PDX_COMPRESSION to CONFIG_PDX_MASK_COMPRESSION,
and make it part of the PDX compression choice block, in preparation for
adding further PDX compression algorithms.

No functional change intended as the PDX compression defaults should still
be the same for all architectures, however the choice block cannot be
protected under EXPERT and still have a default choice being
unconditionally selected.  As a result, the new "PDX (Page inDeX)
compression" item will be unconditionally visible in Kconfig.

As part of this preparation work to introduce new PDX compressions, adjust
some of the comments on pdx.h to note they apply to a specific PDX
compression.  Also shuffle function prototypes and dummy implementations
around to make it easier to introduce a new PDX compression.  Note all
PDX compression implementations are expected to provide a
pdx_is_region_compressible() that takes the same set of arguments.

Signed-off-by: Roger Pau Monné 
---
 xen/common/Kconfig    | 18 +++++++++++++++---
 xen/common/pdx.c      |  4 ++--
 xen/include/xen/pdx.h | 32 +++++++++++++++++++-------------
 3 files changed, 36 insertions(+), 18 deletions(-)

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index eece1370a3cc..7ffd9d7d9003 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -52,9 +52,10 @@ config EVTCHN_FIFO
 
 	  If unsure, say Y.
 
-config PDX_COMPRESSION
-	bool "PDX (Page inDeX) compression" if EXPERT && !X86 && !RISCV
-	default ARM || PPC
+choice
+	prompt "PDX (Page inDeX) compression"
+	default PDX_MASK_COMPRESSION if !X86 && !RISCV
+	default PDX_NONE
 	help
 	  PDX compression is a technique designed to reduce the memory
 	  overhead of physical memory management on platforms with sparse RAM
@@ -67,6 +68,17 @@ config PDX_COMPRESSION
 	  If your platform does not have sparse RAM banks, do not enable PDX
 	  compression.
 
+config PDX_MASK_COMPRESSION
+	bool "Mask compression"
+	help
+	  Compression relying on all RAM addresses sharing a zeroed bit region.
+
+config PDX_NONE
+	bool "None"
+	help
+	  No compression
+endchoice
+
 config ALTERNATIVE_CALL
 	bool
 
diff --git a/xen/common/pdx.c b/xen/common/pdx.c
index 3004c5f28bdd..4843630bee7f 100644
--- a/xen/common/pdx.c
+++ b/xen/common/pdx.c
@@ -34,7 +34,7 @@ bool __mfn_valid(unsigned long mfn)
 {
     bool invalid = mfn >= max_page;
 
-#ifdef CONFIG_PDX_COMPRESSION
+#ifdef CONFIG_PDX_MASK_COMPRESSION
     invalid |= mfn & pfn_hole_mask;
 #endif
 
@@ -80,7 +80,7 @@ unsigned long get_max_pfn(unsigned long top_pfn)
     return pdx_to_pfn(pdx - 1) + 1;
 }
 
-#ifdef CONFIG_PDX_COMPRESSION
+#ifdef CONFIG_PDX_MASK_COMPRESSION
 
 /*
  * Diagram to make sense of the following variables. The masks and shifts
diff --git a/xen/include/xen/pdx.h b/xen/include/xen/pdx.h
index 0f580853cb2e..ec0827936c2f 100644
--- a/xen/include/xen/pdx.h
+++ b/xen/include/xen/pdx.h
@@ -25,7 +25,7 @@
  * this by keeping a bitmap of the ranges in the frame table containing
  * invalid entries and not allocating backing memory for them.
  *
- * ## PDX compression
+ * ## PDX mask compression
  *
  * This is a technique to avoid wasting memory on machines known to have
  * split their machine address space in several big discontinuous and highly
@@ -108,22 +108,13 @@ unsigned long get_max_pfn(unsigned long top_pfn);
 
 #define paddr_to_pdx(pa) pfn_to_pdx(paddr_to_pfn(pa))
 
-#ifdef CONFIG_PDX_COMPRESSION
+#ifdef CONFIG_PDX_MASK_COMPRESSION
 
 extern unsigned long pfn_pdx_bottom_mask, ma_va_bottom_mask;
 extern unsigned int pfn_pdx_hole_shift;
 extern unsigned long pfn_hole_mask;
 extern unsigned long pfn_top_mask, ma_top_mask;
 
-/**
- * Validate a region's compatibility with the current compression runtime
- *
- * @param base Base address of the region
- * @param npages Number of PAGE_SIZE-sized pages in the region
- * @return True iff the region can be used with the current compression
- */
-bool pdx_is_region_compressible(paddr_t base, unsigned long npages);
-
 /**
  * Calculates a mask covering "moving" bits of all addresses of a region
  *
@@ -216,7 +207,9 @@ static inline paddr_t directmapoff_to_maddr(unsigned long offset)
  */
 void pfn_pdx_hole_setup(unsigned long mask);
 
-#else /* !CONFIG_PDX_COMPRESSION */
+#endif /* CONFIG_PDX_MASK_COMPRESSION */
+
+#ifdef CONFIG_PDX_NONE
 
 /* Without PDX compression we can skip some computations */
 
@@ -248,7 +241,20 @@ static inline void pfn_pdx_hole_setup(unsigned long mask)
 {
 }
 
-#endif /* CONFIG_PDX_COMPRESSION */
+#else /* !CONFIG_PDX_NONE */
+
+/* Shared functions implemented by all PDX compressions. */
+
+/**
+ * Validate a region's compatibility with the current compression runtime
+ *
+ * @param base Base address of the region
+ * @param npages Number of PAGE_SIZE-sized pages in the region
+ * @return True iff the region can be used with the current compression
+ */
+bool pdx_is_region_compressible(paddr_t base, unsigned long npages);
+
+#endif /* !CONFIG_PDX_NONE */
 #endif /* __XEN_PDX_H__ */
 
 /*
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 17:22:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 17:22:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011966.1390476 (Exim 4.92)
	(envelope-from )
	id 1uPPA5-0002dc-Py; Wed, 11 Jun 2025 17:22:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011966.1390476; Wed, 11 Jun 2025 17:22:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPPA5-0002dV-MT; Wed, 11 Jun 2025 17:22:53 +0000
Received: by outflank-mailman (input) for mailman id 1011966;
 Wed, 11 Jun 2025 17:22: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 1uPPA4-0002dK-MD
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 17:22:52 +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 b3e4c28a-46e8-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 19:22:51 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3a4fea34e07so93172f8f.1
 for ; Wed, 11 Jun 2025 10:22:51 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a53229e0dcsm16348173f8f.15.2025.06.11.10.22.50
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 11 Jun 2025 10:22:50 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b3e4c28a-46e8-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749662570; x=1750267370; darn=lists.xenproject.org;
        h=content-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=2T4dUlmbhOvNtyULSsUmaVMdY6R2usDVIaG9wqrny14=;
        b=l6j3fGuBCBsXd86kiZ4rqCkCIlFbHighdDAdVJ4uA9NYgGcaC38n5W3boZrFoaQ17X
         y7gzUuXSTlHmjhl2qzD3f9CCZsYis0LKwuGYfaqFkdOsh1yArBQ9yw25pBwQlp7rp2I2
         GMw1lmdmZtICfUFtg7tzR6q2CYjg+Z/fGsrIY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749662570; x=1750267370;
        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=2T4dUlmbhOvNtyULSsUmaVMdY6R2usDVIaG9wqrny14=;
        b=ZqWyMizS7URjUFqUVcsIuuE0TnXX6u13UKkfmaWS2CXgrq+KfPtzyd1q6c2TODqnVq
         t4jQJURtvYd1r+RBItDTo2iIK+lEGmofocfIGuuPJiK0dWYTkkOheFISeS4XVDYCFlFf
         vE5MEQsgfuS/6FLN5XdOwCwWSWEfl/9SEQzp8aIjFVbkR+qPMv5YbP/Je3AowpA41Fyo
         aJu/5xMPLFEmn0ZmlJ3yxk9/M8k3bnsRMSpl80OSjOlXOiUYX39eU7HBGfv2CppUzknH
         9fL01raRSaxpo1mc3Lk8TK89PD1ITR1CNlYNouetcNntj4tANuUIlGvEur1FcnCBj2Ls
         ZTOw==
X-Gm-Message-State: AOJu0YyvgiFsF5oMo5gkFqEYXM9+V/du/6DJrvLpgri3D/R2a2qSGzEd
	VVxCtiUdd4yHH9V+0lX87jlx9mjqd1XzkD9rnaQqcQ3wrEv30lLNF1Lh0TqsCYDwZDwTcuWd+Dq
	Fvwjy
X-Gm-Gg: ASbGncs62viAvLFgGEa+KPUv9N5RQBU6JkKObrKCSCRbu3uKu7524E2XtXJLQKi6Yu4
	UDXpkzmd+g3kJkCaSHlF6LQrmsgD1U+BszeTGQBIzyyfA26neBiAR337qGZ+KwGflzgz4T8LqCU
	pk4r0hLtA0Ng6EHlR+dZjRozCxSjFOP8PNVmNzyHcRgac9w7xRNN1PlfFzFLprrJwxYf6bBUyLc
	wuIKaZMSmXkhuXlIDjOhus8MfNmZX0LB/KtZ9ZKJokl/+3LgDtTN8dDKhlCohjadYzUamkCTkjf
	Ps9/wOgPD9SjOr3dejTnDenISfMbVq0DrMOVAPClLUCzf+fUTRqqmsABExPGdQS/iK4VBQIcTOC
	EMDl1voJgWZVC3dbxy3DW3Hig92ePkSPX4XY=
X-Google-Smtp-Source: AGHT+IHXlb+f8mvAbVqXjkk+FJrV+4iDXJ2XDjnLmfwZ968nmhBctbQRAM+VY3AZTZ9kxht+7rKilA==
X-Received: by 2002:a05:6000:288e:b0:3a4:dfc2:2a3e with SMTP id ffacd0b85a97d-3a5586f192bmr4021318f8f.39.1749662570563;
        Wed, 11 Jun 2025 10:22:50 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper 
Subject: [PATCH 1/8] x86/pdx: simplify calculation of domain struct allocation boundary
Date: Wed, 11 Jun 2025 19:16:29 +0200
Message-ID: <20250611171636.5674-2-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250611171636.5674-1-roger.pau@citrix.com>
References: <20250611171636.5674-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

When not using CONFIG_BIGMEM there are some restrictions in the address
width for allocations of the domain structure, as it's PDX truncated to
32bits it's stashed into page_info structure for domain allocated pages.

The current logic to calculate this limit is based on the internals of the
PDX compression used, which is not strictly required.  Instead simplify the
logic to rely on the existing PDX to PFN conversion helpers used elsewhere.

This has the added benefit of allowing alternative PDX compression
algorithms to be implemented without requiring to change the calculation of
the domain structure allocation boundary.

Signed-off-by: Roger Pau Monné 
---
 xen/arch/x86/domain.c | 35 ++++++-----------------------------
 1 file changed, 6 insertions(+), 29 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 7536b6c8717e..2f438ce367cf 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -461,30 +461,6 @@ void domain_cpu_policy_changed(struct domain *d)
     }
 }
 
-#if !defined(CONFIG_BIGMEM) && defined(CONFIG_PDX_COMPRESSION)
-/*
- * The hole may be at or above the 44-bit boundary, so we need to determine
- * the total bit count until reaching 32 significant (not squashed out) bits
- * in PFN representations.
- * Note that the way "bits" gets initialized/updated/bounds-checked guarantees
- * that the function will never return zero, and hence will never be called
- * more than once (which is important due to it being deliberately placed in
- * .init.text).
- */
-static unsigned int __init noinline _domain_struct_bits(void)
-{
-    unsigned int bits = 32 + PAGE_SHIFT;
-    unsigned int sig = hweight32(~pfn_hole_mask);
-    unsigned int mask = pfn_hole_mask >> 32;
-
-    for ( ; bits < BITS_PER_LONG && sig < 32; ++bits, mask >>= 1 )
-        if ( !(mask & 1) )
-            ++sig;
-
-    return bits;
-}
-#endif
-
 struct domain *alloc_domain_struct(void)
 {
     struct domain *d;
@@ -498,14 +474,15 @@ struct domain *alloc_domain_struct(void)
      * On systems with CONFIG_BIGMEM there's no packing, and so there's no
      * such restriction.
      */
-#if defined(CONFIG_BIGMEM) || !defined(CONFIG_PDX_COMPRESSION)
-    const unsigned int bits = IS_ENABLED(CONFIG_BIGMEM) ? 0 :
-                                                          32 + PAGE_SHIFT;
+#if defined(CONFIG_BIGMEM)
+    const unsigned int bits = 0;
 #else
-    static unsigned int __read_mostly bits;
+    static unsigned int __ro_after_init bits;
 
     if ( unlikely(!bits) )
-         bits = _domain_struct_bits();
+         bits = flsl(pfn_to_paddr(pdx_to_pfn(
+             1UL << (sizeof(((struct page_info *)NULL)->v.inuse._domain) * 8))))
+             - 1;
 #endif
 
     BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 17:22:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 17:22:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011970.1390512 (Exim 4.92)
	(envelope-from )
	id 1uPPA9-0003RN-VW; Wed, 11 Jun 2025 17:22:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011970.1390512; Wed, 11 Jun 2025 17:22:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPPA9-0003OW-QT; Wed, 11 Jun 2025 17:22:57 +0000
Received: by outflank-mailman (input) for mailman id 1011970;
 Wed, 11 Jun 2025 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 1uPPA8-0002dK-Pt
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 17:22:56 +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 b6e638a8-46e8-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 19:22:56 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-43ea40a6e98so187125e9.1
 for ; Wed, 11 Jun 2025 10:22:56 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-45325140f30sm27011275e9.4.2025.06.11.10.22.54
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 11 Jun 2025 10:22:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b6e638a8-46e8-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749662576; x=1750267376; darn=lists.xenproject.org;
        h=content-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=jkTPtYu2X1Hla12Ld0GVwhz+81hY0W8JQvDMWI2yhDk=;
        b=H1cO+EFHPnUAvJqxaZgqjQXsXP+W7zaO4cxvrpk48TyC79tFX1LAT03qHluFl/9TIi
         gDFiBmnIUlLDV/QJfXvlv416DEgjr/+nO9CJEq8R6Nt8rN8wfj7AU55Hv1i6ibwrCGFz
         RywfFDGMfOUXY7r7hOvfWuVNUOukTPwj1V3GE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749662576; x=1750267376;
        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=jkTPtYu2X1Hla12Ld0GVwhz+81hY0W8JQvDMWI2yhDk=;
        b=tkbVb8KaXi4wRFHT/uGGqqFdTvj1w80JcS+P7wxxK3hLNZBR1Tlg7Oo1sP5u+JdhyM
         RvK4YN0TCKVOBkY7zscuOxUWqMe9Dwh1SDF/5FQuC7/hwNT3Ixj2gQQae4Bb26h4L4yG
         A6rTkTfC4mDWsRDKoJzs9SxWlRGWMjr/ozd4YjkhuCInCkX/kDVAuHhOOhTvM23WI525
         B0fb5ircdYz5mQzBBE/tMsInTwT+J6FYz/mN9WrAtSob9T5nuTku4OybnS9Zxx3yY+uY
         Nk6yfU6v3hsdqDabcJNxVCdnXw94H3WHl3LDp2pJDCMrD7PRMo2hrEr/YOP0Pa8k7ivG
         9mjQ==
X-Gm-Message-State: AOJu0Yx1oCfNYyczvPkcZhkLro6SnWGUBNIU3KHPOldZOQXJM1zsCp/j
	eUN+Dt2kr0WmO6pVybtBoilaDJpYuRjfPSjPoFuONuSa98ZE22lnBkqdbPx+LSsHZFFUczQe0iO
	2up1d
X-Gm-Gg: ASbGncslyyvXda86BjKlVJdPoiqyM9jeKyus40ZhTgh3krC4shNt/83S2tTCSZI//Nh
	Xz9QHZPnCimZ0c3e1od9ibyt9GedfwgxAdCii4QzbtFyXHhvaAIW8nEHS8boz8oOM2/zPe0ueVB
	CdyslVefxltNvMXSdtnFD32zu+mNVgCHEGoadgQMb7xbnXsx0jdiE3QN59YmPhfm0YNdmiWwfOY
	+/5zcPxvwoC2ekyUdHPMbpBGVMsKuaoQAbi9VOS42dL7x9bFA5sn60Z0naR/8AjiNI96s/fJxSo
	BPBUkDZs/woIJBskafBj8piSNJHi0/BCQAKs1ayVIE1hrPOIcEuADHkYOpQw86nSy1gXtTbKc8p
	xojtPLo/p49GxKwie7NAt90Rkkbd54I8FNgo=
X-Google-Smtp-Source: AGHT+IFgWT4jERhURBaaV7IdOzOpS71w3ZR8cxBZ+PefDGAyZ0K/1TK/B1CrOfEVgzsBOCjtRAmCGA==
X-Received: by 2002:a05:600c:4f06:b0:453:608:a18b with SMTP id 5b1f17b1804b1-4532b28d858mr8680555e9.9.1749662575471;
        Wed, 11 Jun 2025 10:22:55 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH 5/8] pdx: allow optimizing PDX conversion helpers
Date: Wed, 11 Jun 2025 19:16:33 +0200
Message-ID: <20250611171636.5674-6-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250611171636.5674-1-roger.pau@citrix.com>
References: <20250611171636.5674-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

There are four performance critical PDX conversion helpers that do the PFN
to/from PDX and the physical addresses to/from directmap offsets
translations.

In the absence of an active PDX compression, those functions would still do
the calculations needed, just to return the same input value as no
translation is in place and hence PFN and PDX spaces are identity mapped.

To reduce the overhead of having to do the pointless calculations allow
architectures to short-circuit the logic by providing a macro.  Implement
such short-circuiting for x86 using asm goto and alternatives.  This
results in the optimized case (when PDX compression is not enabled) doing
an unconditional jump to a label, while the non-optimized case is left
as-is.

Signed-off-by: Roger Pau Monné 
---
 xen/arch/x86/include/asm/cpufeatures.h |  1 +
 xen/arch/x86/srat.c                    |  6 +++-
 xen/common/pdx.c                       |  8 +++--
 xen/include/xen/pdx.h                  | 46 ++++++++++++++++++++------
 4 files changed, 47 insertions(+), 14 deletions(-)

diff --git a/xen/arch/x86/include/asm/cpufeatures.h b/xen/arch/x86/include/asm/cpufeatures.h
index 9e3ed21c026d..85e1a6f0a055 100644
--- a/xen/arch/x86/include/asm/cpufeatures.h
+++ b/xen/arch/x86/include/asm/cpufeatures.h
@@ -43,6 +43,7 @@ XEN_CPUFEATURE(XEN_IBT,           X86_SYNTH(27)) /* Xen uses CET Indirect Branch
 XEN_CPUFEATURE(IBPB_ENTRY_PV,     X86_SYNTH(28)) /* MSR_PRED_CMD used by Xen for PV */
 XEN_CPUFEATURE(IBPB_ENTRY_HVM,    X86_SYNTH(29)) /* MSR_PRED_CMD used by Xen for HVM */
 XEN_CPUFEATURE(USE_VMCALL,        X86_SYNTH(30)) /* Use VMCALL instead of VMMCALL */
+XEN_CPUFEATURE(PDX_COMPRESSION,   X86_SYNTH(31)) /* PDX compression */
 
 /* Bug words follow the synthetic words. */
 #define X86_NR_BUG 1
diff --git a/xen/arch/x86/srat.c b/xen/arch/x86/srat.c
index 7042fd3c3d88..96a87bbce35b 100644
--- a/xen/arch/x86/srat.c
+++ b/xen/arch/x86/srat.c
@@ -298,7 +298,8 @@ void __init srat_parse_regions(paddr_t addr)
 	acpi_table_parse_srat(ACPI_SRAT_TYPE_MEMORY_AFFINITY,
 			      srat_parse_region, 0);
 
-	pfn_pdx_compression_setup(addr);
+	if (!pfn_pdx_compression_setup(addr))
+		return;
 
 	/* Ensure all ranges in the e820 are covered. */
 	for (i = 0; i < e820.nr_map; i++) {
@@ -318,6 +319,9 @@ void __init srat_parse_regions(paddr_t addr)
 			return;
 		}
 	}
+
+	/* If we got this far compression is working as expected. */
+	setup_force_cpu_cap(X86_FEATURE_PDX_COMPRESSION);
 }
 
 unsigned int numa_node_to_arch_nid(nodeid_t n)
diff --git a/xen/common/pdx.c b/xen/common/pdx.c
index 65b337860d52..7d14100224fe 100644
--- a/xen/common/pdx.c
+++ b/xen/common/pdx.c
@@ -230,7 +230,7 @@ static uint64_t __init pdx_init_mask(uint64_t base_addr)
                          (uint64_t)1 << (MAX_ORDER + PAGE_SHIFT)) - 1);
 }
 
-void __init pfn_pdx_compression_setup(paddr_t base)
+bool __init pfn_pdx_compression_setup(paddr_t base)
 {
     unsigned int i, j, bottom_shift = 0, hole_shift = 0;
     unsigned long mask = pdx_init_mask(base);
@@ -240,7 +240,7 @@ void __init pfn_pdx_compression_setup(paddr_t base)
         printk(XENLOG_WARNING
                "Too many PFN ranges (%u), not attempting PFN compression\n",
                nr);
-        return;
+        return false;
     }
 
     for ( i = 0; i < nr; i++ )
@@ -272,7 +272,7 @@ void __init pfn_pdx_compression_setup(paddr_t base)
         }
     }
     if ( !hole_shift )
-        return;
+        return false;
 
     printk(KERN_INFO "PFN compression on bits %u...%u\n",
            bottom_shift, bottom_shift + hole_shift - 1);
@@ -283,6 +283,8 @@ void __init pfn_pdx_compression_setup(paddr_t base)
     pfn_hole_mask       = ((1UL << hole_shift) - 1) << bottom_shift;
     pfn_top_mask        = ~(pfn_pdx_bottom_mask | pfn_hole_mask);
     ma_top_mask         = pfn_top_mask << PAGE_SHIFT;
+
+    return true;
 }
 
 void __init pfn_pdx_compression_reset(void)
diff --git a/xen/include/xen/pdx.h b/xen/include/xen/pdx.h
index 43ce36fcbb56..6cc0f54cff83 100644
--- a/xen/include/xen/pdx.h
+++ b/xen/include/xen/pdx.h
@@ -67,6 +67,26 @@
  * region involved.
  */
 
+/* Macro defined per-arch to skip PDX logic when there's no compression. */
+#ifdef CONFIG_X86
+# include 
+
+# define OPTIMIZE_PDX(transform, raw)                   \
+    asm_inline goto (                                   \
+        ALTERNATIVE(                                    \
+            "",                                         \
+            "jmp %l[skip]",                             \
+            ALT_NOT(X86_FEATURE_PDX_COMPRESSION))       \
+        : : : : skip );                                 \
+    return (transform);                                 \
+                                                        \
+ skip:                                                  \
+    return (raw)
+#else
+# define OPTIMIZE_PDX(transform, raw)                   \
+     return (transform)
+#endif
+
 extern unsigned long max_pdx;
 
 #define PDX_GROUP_COUNT ((1 << PDX_GROUP_SHIFT) / \
@@ -123,8 +143,9 @@ extern unsigned long pfn_top_mask, ma_top_mask;
  */
 static inline unsigned long pfn_to_pdx(unsigned long pfn)
 {
-    return (pfn & pfn_pdx_bottom_mask) |
-           ((pfn & pfn_top_mask) >> pfn_pdx_hole_shift);
+    OPTIMIZE_PDX((pfn & pfn_pdx_bottom_mask) |
+                 ((pfn & pfn_top_mask) >> pfn_pdx_hole_shift),
+                 pfn);
 }
 
 /**
@@ -135,8 +156,9 @@ static inline unsigned long pfn_to_pdx(unsigned long pfn)
  */
 static inline unsigned long pdx_to_pfn(unsigned long pdx)
 {
-    return (pdx & pfn_pdx_bottom_mask) |
-           ((pdx << pfn_pdx_hole_shift) & pfn_top_mask);
+    OPTIMIZE_PDX((pdx & pfn_pdx_bottom_mask) |
+                 ((pdx << pfn_pdx_hole_shift) & pfn_top_mask),
+                 pdx);
 }
 
 /**
@@ -148,8 +170,9 @@ static inline unsigned long pdx_to_pfn(unsigned long pdx)
  */
 static inline unsigned long maddr_to_directmapoff(paddr_t ma)
 {
-    return (((ma & ma_top_mask) >> pfn_pdx_hole_shift) |
-            (ma & ma_va_bottom_mask));
+    OPTIMIZE_PDX(((ma & ma_top_mask) >> pfn_pdx_hole_shift) |
+                  (ma & ma_va_bottom_mask),
+                  ma);
 }
 
 /**
@@ -160,8 +183,9 @@ static inline unsigned long maddr_to_directmapoff(paddr_t ma)
  */
 static inline paddr_t directmapoff_to_maddr(unsigned long offset)
 {
-    return ((((paddr_t)offset << pfn_pdx_hole_shift) & ma_top_mask) |
-            (offset & ma_va_bottom_mask));
+    OPTIMIZE_PDX(((((paddr_t)offset << pfn_pdx_hole_shift) & ma_top_mask) |
+                 (offset & ma_va_bottom_mask)),
+                 offset);
 }
 
 #endif /* CONFIG_PDX_MASK_COMPRESSION */
@@ -188,8 +212,9 @@ static inline void pfn_pdx_add_region(paddr_t base, paddr_t size)
 {
 }
 
-static inline void pfn_pdx_compression_setup(paddr_t base)
+static inline bool pfn_pdx_compression_setup(paddr_t base)
 {
+    return false;
 }
 
 static inline void pfn_pdx_compression_reset(void)
@@ -222,8 +247,9 @@ void pfn_pdx_add_region(paddr_t base, paddr_t size);
  * range of the current memory regions.
  *
  * @param base address to start compression from.
+ * @return True if PDX compression has been enabled.
  */
-void pfn_pdx_compression_setup(paddr_t base);
+bool pfn_pdx_compression_setup(paddr_t base);
 
 /**
  * Reset the global variables to it's default values, thus disabling PFN
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 17:22:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 17:22:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011967.1390486 (Exim 4.92)
	(envelope-from )
	id 1uPPA7-0002rV-16; Wed, 11 Jun 2025 17:22:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011967.1390486; Wed, 11 Jun 2025 17: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 1uPPA6-0002rM-UN; Wed, 11 Jun 2025 17:22:54 +0000
Received: by outflank-mailman (input) for mailman id 1011967;
 Wed, 11 Jun 2025 17:22: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 1uPPA5-0002dK-B6
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 17:22:53 +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 b492516c-46e8-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 19:22:52 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3a54700a46eso133852f8f.1
 for ; Wed, 11 Jun 2025 10:22:52 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a5323ab207sm15780062f8f.29.2025.06.11.10.22.51
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 11 Jun 2025 10:22:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b492516c-46e8-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749662572; x=1750267372; darn=lists.xenproject.org;
        h=content-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=uKrBP871dG4zllrLFjmVYwBp6+ujdNqW4+VWtq3YZgI=;
        b=fMa6ppnhQyo4G8LOz+vHWa1GJ2uhGPXOJYXUr8QXzrPdnbDsIXn/bK30BA0a4B+UUx
         sV8cPKYlvGz8X8FtHXmoZV2qiL/6TP8QPIdIHBeGM37kuRec3/qX8wJ120RT8/3uWQQd
         pGFz8t/nJ33FptRb+aAoPxIcK2AvJX1oVka6U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749662572; x=1750267372;
        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=uKrBP871dG4zllrLFjmVYwBp6+ujdNqW4+VWtq3YZgI=;
        b=oDOPzLVMeV0iKqqwtXTCcZM6dF1FSG3uCafPh157lWGQwbTwXZxf5jGEBuQSlDhLe2
         snVjxWVrurprPb3QGCtzKAjpbJdC5etqN0keJDnWG4LwFhIOag7H5NEIphSwCfejd79Y
         p3vCHyk47w+3GmQ8ZQwtQnTQykDjBzisXEZIle8yPkyn2HcbS1Bno3ySqpmYwOuhqQDR
         lwkEXwJnkwT8k66/OBak1DBhyXuFYOwQxip1Qwp+bWS1BwJHtP0UaaTfjCzF12Vm38Rc
         64pzsH3QZH20zr3U2brbh1vCwhLtuBfn/D771PjIHUQ+z4PWEj+p/cFZRyiA1rY8UVG6
         m3IQ==
X-Gm-Message-State: AOJu0YxNjHnd1UO+ugPJkLz0X788hX42bRrsns00CPepCE7LfCfUWP8u
	KaAAn3D9d8joFR4866QK1urzO3yESwFeVlb6oDmF63llmTqGxgbxtDlXtUwgccP+cie8ZaVSeCK
	dvaLf
X-Gm-Gg: ASbGncvUphL4Furxti2C91MqL5iXR7H5vEb0mZDPNIzFiUhsvLU2CHzMXs4YQxcCqFO
	4FCeXkToXFnoDOJg1JGJRbnRSuj6iRwpZNaUejULFYx+fc1QMJvBZ95uxeksc3O6VaIdYLIijhv
	xxmxD8bpvlr9RmADj8AIliKkkco21pZR9buDAqudpMZdtEzdLlmmE0hPvrMiqMggD/nnVZ9Tida
	tGsyqOEO2yczuskBghI6xjQbSeG45Na0CKTFU20ieSXt5fS9N9XeT0CtLhVQjXkKPeE1RBB2JPb
	N3E8i7HtvJacmc+dqk46UrAmXwSAsoJ5SXBWrxobB8fXisVuA1rEbS9phpszSh0EorLj7iAke+4
	qi5pg1VQgx8EM8or8l60I7hkPiDSUU20qwOw=
X-Google-Smtp-Source: AGHT+IGLtHZs7bMty9epxiuNgjn1rUQmc2r9GZEr5iiKTtkm11d+FqFZAUn80jbqllZXkua5g4YQlw==
X-Received: by 2002:a05:6000:310a:b0:3a4:d53d:be20 with SMTP id ffacd0b85a97d-3a558695d45mr3025445f8f.18.1749662571651;
        Wed, 11 Jun 2025 10:22:51 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH 2/8] pdx: introduce function to calculate max PFN based on PDX compression
Date: Wed, 11 Jun 2025 19:16:30 +0200
Message-ID: <20250611171636.5674-3-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250611171636.5674-1-roger.pau@citrix.com>
References: <20250611171636.5674-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This is the code already present and used by x86 in setup_max_pdx(), which
takes into account the current PDX compression, plus the limitation of the
virtual memory layout to return the maximum usable PFN in the system,
possibly truncating the input PFN provided by the caller.

This helper will be used by upcoming PDX related changes that introduce a
new compression algorithm.

Signed-off-by: Roger Pau Monné 
---
 xen/arch/x86/setup.c  | 19 ++-----------------
 xen/common/pdx.c      | 25 +++++++++++++++++++++++++
 xen/include/xen/pdx.h |  8 ++++++++
 3 files changed, 35 insertions(+), 17 deletions(-)

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 1f5cb67bd0ee..ea670567cbf7 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -721,23 +721,8 @@ static uint64_t __init consider_modules(
 
 static void __init setup_max_pdx(unsigned long top_page)
 {
-    max_pdx = pfn_to_pdx(top_page - 1) + 1;
-
-    if ( max_pdx > (DIRECTMAP_SIZE >> PAGE_SHIFT) )
-        max_pdx = DIRECTMAP_SIZE >> PAGE_SHIFT;
-
-    if ( max_pdx > FRAMETABLE_NR )
-        max_pdx = FRAMETABLE_NR;
-
-    if ( max_pdx > MPT_VIRT_SIZE / sizeof(unsigned long) )
-        max_pdx = MPT_VIRT_SIZE / sizeof(unsigned long);
-
-#ifdef PAGE_LIST_NULL
-    if ( max_pdx >= PAGE_LIST_NULL )
-        max_pdx = PAGE_LIST_NULL - 1;
-#endif
-
-    max_page = pdx_to_pfn(max_pdx - 1) + 1;
+    max_page = get_max_pfn(top_page);
+    max_pdx = pfn_to_pdx(max_page - 1) + 1;
 }
 
 /* A temporary copy of the e820 map that we can mess with during bootstrap. */
diff --git a/xen/common/pdx.c b/xen/common/pdx.c
index b8384e6189df..3004c5f28bdd 100644
--- a/xen/common/pdx.c
+++ b/xen/common/pdx.c
@@ -55,6 +55,31 @@ void set_pdx_range(unsigned long smfn, unsigned long emfn)
         __set_bit(idx, pdx_group_valid);
 }
 
+unsigned long get_max_pfn(unsigned long top_pfn)
+{
+    unsigned long pdx = pfn_to_pdx(top_pfn - 1) + 1;
+
+#ifdef DIRECTMAP_SIZE
+    if ( pdx > (DIRECTMAP_SIZE >> PAGE_SHIFT) )
+        pdx = DIRECTMAP_SIZE >> PAGE_SHIFT;
+#endif
+
+    if ( pdx > FRAMETABLE_NR )
+        pdx = FRAMETABLE_NR;
+
+#ifdef MPT_VIRT_SIZE
+    if ( pdx > MPT_VIRT_SIZE / sizeof(unsigned long) )
+        pdx = MPT_VIRT_SIZE / sizeof(unsigned long);
+#endif
+
+#ifdef PAGE_LIST_NULL
+    if ( pdx >= PAGE_LIST_NULL )
+        pdx = PAGE_LIST_NULL - 1;
+#endif
+
+    return pdx_to_pfn(pdx - 1) + 1;
+}
+
 #ifdef CONFIG_PDX_COMPRESSION
 
 /*
diff --git a/xen/include/xen/pdx.h b/xen/include/xen/pdx.h
index 9faeea3ac9f2..0f580853cb2e 100644
--- a/xen/include/xen/pdx.h
+++ b/xen/include/xen/pdx.h
@@ -92,6 +92,14 @@ void set_pdx_range(unsigned long smfn, unsigned long emfn);
  */
 bool __mfn_valid(unsigned long mfn);
 
+/**
+ * Get maximum usable PFN given the virtual address space restrictions.
+ *
+ * @param pdx Maximum PFN
+ * @return Possibly truncated maximum PFN
+ */
+unsigned long get_max_pfn(unsigned long top_pfn);
+
 #define page_to_pdx(pg)  ((pg) - frame_table)
 #define pdx_to_page(pdx) gcc11_wrap(frame_table + (pdx))
 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 17:22:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 17:22:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011969.1390506 (Exim 4.92)
	(envelope-from )
	id 1uPPA9-0003KK-HC; Wed, 11 Jun 2025 17:22:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011969.1390506; Wed, 11 Jun 2025 17:22:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPPA9-0003K9-DG; Wed, 11 Jun 2025 17:22:57 +0000
Received: by outflank-mailman (input) for mailman id 1011969;
 Wed, 11 Jun 2025 17:22: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 1uPPA7-0002dK-P9
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 17:22:55 +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 b619382b-46e8-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 19:22:55 +0200 (CEST)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3a536ecbf6fso86759f8f.2
 for ; Wed, 11 Jun 2025 10:22:55 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a532435771sm16404330f8f.63.2025.06.11.10.22.53
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 11 Jun 2025 10:22:53 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b619382b-46e8-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749662574; x=1750267374; darn=lists.xenproject.org;
        h=content-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=ttrfu43pRWE6xwPmTOgphlvxFpMyWz3GgrH4WqitZoY=;
        b=ai9YvOzuSaybgXuqFf99uzC7SkG1aW2tFY0j3SzMOqSOhhCPzQ7vNkE7pPAi1rabJa
         lsJeYPDtChdq0HfY9QKA95YdLll9fLB4ewtMvUvfOoA/IehQDIaNKbyiCrln08kP+8Dq
         /1FR1glONtK1zhLqZkROkWFgl8SnkoyANYsTc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749662574; x=1750267374;
        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=ttrfu43pRWE6xwPmTOgphlvxFpMyWz3GgrH4WqitZoY=;
        b=bal0uDxLgxgWIjfKnAlXh7R+TcFNR9YwKv/7E3n+5XCjf5vl92S33cJk9rbPQBHSlv
         fGy2thIo07yKVDC1B+0HYv7qNqvzwVQNzAeOojfsG3K5PuMPWgXvwkRWzq+9iMMiOGk5
         slQnDupefoCjDxW6wTEZd0Kz5dZxvUJBVFoTNhkaVU3wBLVz/WIjhHQnzL1CRIC20e+5
         C69pSC98CpQGs7AXU1QfjTSIen6zqIP0n+7mQtLrUTy0DbYwW26n+qH9uhwtniIVJU14
         E+CcibDA1hdJbLekd6on+b5vO89zU2S8EYsMarK1u4B/yzABvHKXBdjeurWoApQ/wryy
         Kr1g==
X-Gm-Message-State: AOJu0YzV80CAUhN7dAvGk5WCYdGCV9O9pt8+Ft7w5jQHrU5hF4DDv9tg
	2alXeC6bjSJlK+/yjtkJRxwywO4042bSm/WgFa+8mYIMhiytgHyhykj+HlruuVPnkBOTL8y/Kyr
	n62xb
X-Gm-Gg: ASbGncv2vaEJN0z/eW9BJ8FogWgoxUHyS9rIus+wTlrhFe2LdwOrsair0Xzo4dj70jz
	q6VfVAOS3/9xuCFKwuC1dZfQVb9EWA0umZhlvMhg0pobuk475Y/oqSngr+dkMD67Xdmx4EAHfTA
	8Z1zuq3VBAkOqX0f5BNLBNGEyKxfTqK+zf67nXcGgejyCCC2A+yrrpXoqiToCTfwlUy6mrB5hG+
	vblwsUojI+8O9Z/3dmErhylGPMygfkIMOpQ6G/UkAOWRsqWJN2zxex4VfLl/j75nJT3qoUnfl0D
	zGQSqb2AerEQxPIE0Lcaf5qAemz+OXZbpZFyMiIXkvZ8mwerA0hNLHVtHMgUcnf7jMnTa1iIAqo
	XM01QrWo+c1Xpy1f70z7Nh+xPFi7JJtlUjLk=
X-Google-Smtp-Source: AGHT+IGBuv1A6rD03lt3tuGkXIBzFKTXW9t2uvoWqXh1j3YfreQdjr3Ip7zMXU6tXWBGKsF90dyuqw==
X-Received: by 2002:a05:6000:4305:b0:3a5:1266:3e96 with SMTP id ffacd0b85a97d-3a558695737mr3511529f8f.15.1749662574140;
        Wed, 11 Jun 2025 10:22:54 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Andrew Cooper ,
	Anthony PERARD ,
	Jan Beulich 
Subject: [PATCH 4/8] pdx: provide a unified set of unit functions
Date: Wed, 11 Jun 2025 19:16:32 +0200
Message-ID: <20250611171636.5674-5-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250611171636.5674-1-roger.pau@citrix.com>
References: <20250611171636.5674-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The current setup (pdx_init_mask() and pdx_region_mask()) and init
(pfn_pdx_hole_setup()) PDX compression functions are tailored to the
existing PDX compression algorithm.

In preparation for introducing a new compression algorithm convert the
setup and init functions to more generic interfaces that aren't tied to the
compression in-use.  To accomplish this introduce a function that registers
all the PFN RAM ranges, plus an init function.

This has the downside of requiring a static array to store such ranges
ahead of being processed by the setup function, however it's the only way
to pass all the possible information to the different compression setup
functions without using per-compression specific setup functions.
Per-arch compression setup also need to be adjusted to use the new
interface.  There's a slight ordering adjustment, in that after PDX
compression setup the caller will check whether all the RAM regions are
properly covered by the newly setup compression, otherwise compression is
disabled by resetting to the initial values.

No functional change intended in the resulting PDX compression values.

Signed-off-by: Roger Pau Monné 
---
 xen/arch/arm/setup.c  |  34 ++++++-------
 xen/arch/x86/srat.c   |  28 ++++++----
 xen/common/pdx.c      | 116 ++++++++++++++++++++++++++++++++++++------
 xen/include/xen/pdx.h |  73 +++++++++-----------------
 4 files changed, 160 insertions(+), 91 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 734e23da4408..93ebfc29635e 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -255,6 +255,10 @@ void __init init_pdx(void)
 {
     const struct membanks *mem = bootinfo_get_mem();
     paddr_t bank_start, bank_size, bank_end;
+    unsigned int bank;
+
+    for ( bank = 0 ; bank < mem->nr_banks; bank++ )
+        pfn_pdx_add_region(mem->bank[bank].start, mem->bank[bank].size);
 
     /*
      * Arm does not have any restrictions on the bits to compress. Pass 0 to
@@ -263,28 +267,24 @@ void __init init_pdx(void)
      * If the logic changes in pfn_pdx_hole_setup we might have to
      * update this function too.
      */
-    uint64_t mask = pdx_init_mask(0x0);
-    int bank;
+    pfn_pdx_compression_setup(0);
 
     for ( bank = 0 ; bank < mem->nr_banks; bank++ )
     {
-        bank_start = mem->bank[bank].start;
-        bank_size = mem->bank[bank].size;
-
-        mask |= bank_start | pdx_region_mask(bank_start, bank_size);
-    }
-
-    for ( bank = 0 ; bank < mem->nr_banks; bank++ )
-    {
-        bank_start = mem->bank[bank].start;
-        bank_size = mem->bank[bank].size;
-
-        if (~mask & pdx_region_mask(bank_start, bank_size))
-            mask = 0;
+        if ( !pdx_is_region_compressible(mem->bank[bank].start,
+                 PFN_UP(mem->bank[bank].start + mem->bank[bank].size) -
+                 PFN_DOWN(mem->bank[bank].start)) )
+        {
+            pfn_pdx_compression_reset();
+            printk(XENLOG_WARNING
+                   "PFN compression disabled, RAM region [%#" PRIpaddr ", %#"
+                   PRIpaddr "] not covered\n",
+                   mem->bank[bank].start,
+                   mem->bank[bank].start + mem->bank[bank].size - 1);
+            break;
+        }
     }
 
-    pfn_pdx_hole_setup(mask >> PAGE_SHIFT);
-
     for ( bank = 0 ; bank < mem->nr_banks; bank++ )
     {
         bank_start = mem->bank[bank].start;
diff --git a/xen/arch/x86/srat.c b/xen/arch/x86/srat.c
index 688f410287d4..7042fd3c3d88 100644
--- a/xen/arch/x86/srat.c
+++ b/xen/arch/x86/srat.c
@@ -261,8 +261,6 @@ acpi_numa_memory_affinity_init(const struct acpi_srat_mem_affinity *ma)
 
 void __init acpi_numa_arch_fixup(void) {}
 
-static uint64_t __initdata srat_region_mask;
-
 static int __init cf_check srat_parse_region(
     struct acpi_subtable_header *header, const unsigned long end)
 {
@@ -282,15 +280,13 @@ static int __init cf_check srat_parse_region(
 		printk(KERN_INFO "SRAT: %013"PRIx64"-%013"PRIx64"\n",
 		       ma->base_address, ma->base_address + ma->length - 1);
 
-	srat_region_mask |= ma->base_address |
-			    pdx_region_mask(ma->base_address, ma->length);
+	pfn_pdx_add_region(ma->base_address, ma->length);
 
 	return 0;
 }
 
 void __init srat_parse_regions(paddr_t addr)
 {
-	u64 mask;
 	unsigned int i;
 
 	if (acpi_disabled || acpi_numa < 0 ||
@@ -299,19 +295,29 @@ void __init srat_parse_regions(paddr_t addr)
 
 	/* Set "PXM" as early as feasible. */
 	numa_fw_nid_name = "PXM";
-	srat_region_mask = pdx_init_mask(addr);
 	acpi_table_parse_srat(ACPI_SRAT_TYPE_MEMORY_AFFINITY,
 			      srat_parse_region, 0);
 
-	for (mask = srat_region_mask, i = 0; mask && i < e820.nr_map; i++) {
+	pfn_pdx_compression_setup(addr);
+
+	/* Ensure all ranges in the e820 are covered. */
+	for (i = 0; i < e820.nr_map; i++) {
 		if (e820.map[i].type != E820_RAM)
 			continue;
 
-		if (~mask & pdx_region_mask(e820.map[i].addr, e820.map[i].size))
-			mask = 0;
+		if (!pdx_is_region_compressible(e820.map[i].addr,
+		    PFN_UP(e820.map[i].addr + e820.map[i].size) -
+		    PFN_DOWN(e820.map[i].addr)))
+		{
+			pfn_pdx_compression_reset();
+			printk(XENLOG_WARNING
+			       "PFN compression disabled, RAM region [%#" PRIx64
+			       ", %#" PRIx64 "] not covered\n",
+			       e820.map[i].addr,
+			       e820.map[i].addr + e820.map[i].size - 1);
+			return;
+		}
 	}
-
-	pfn_pdx_hole_setup(mask >> PAGE_SHIFT);
 }
 
 unsigned int numa_node_to_arch_nid(nodeid_t n)
diff --git a/xen/common/pdx.c b/xen/common/pdx.c
index 4843630bee7f..65b337860d52 100644
--- a/xen/common/pdx.c
+++ b/xen/common/pdx.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /**
@@ -80,6 +81,39 @@ unsigned long get_max_pfn(unsigned long top_pfn)
     return pdx_to_pfn(pdx - 1) + 1;
 }
 
+#ifndef CONFIG_PDX_NONE
+
+#ifdef CONFIG_X86
+# include 
+# define MAX_PFN_RANGES E820MAX
+#elif defined(CONFIG_HAS_DEVICE_TREE)
+# include 
+# define MAX_PFN_RANGES NR_MEM_BANKS
+#else
+# error "Missing architecture maximum number of RAM ranges"
+#endif
+
+/* Generic PFN compression helpers. */
+static struct pfn_range {
+    unsigned long base, size;
+} ranges[MAX_PFN_RANGES] __initdata;
+static unsigned int __initdata nr;
+
+void __init pfn_pdx_add_region(paddr_t base, paddr_t size)
+{
+    if ( nr >= ARRAY_SIZE(ranges) )
+    {
+        ASSERT((nr + 1) > nr);
+        nr++;
+        return;
+    }
+
+    ranges[nr].base = PFN_DOWN(base);
+    ranges[nr++].size = PFN_UP(base + size) - PFN_DOWN(base);
+}
+
+#endif /* !CONFIG_PDX_NONE */
+
 #ifdef CONFIG_PDX_MASK_COMPRESSION
 
 /*
@@ -140,20 +174,25 @@ static uint64_t fill_mask(uint64_t mask)
     return mask;
 }
 
-bool pdx_is_region_compressible(paddr_t base, unsigned long npages)
-{
-    return !(paddr_to_pfn(base) & pfn_hole_mask) &&
-           !(pdx_region_mask(base, npages * PAGE_SIZE) & ~ma_va_bottom_mask);
-}
-
-/* We don't want to compress the low MAX_ORDER bits of the addresses. */
-uint64_t __init pdx_init_mask(uint64_t base_addr)
-{
-    return fill_mask(max(base_addr,
-                         (uint64_t)1 << (MAX_ORDER + PAGE_SHIFT)) - 1);
-}
-
-uint64_t pdx_region_mask(uint64_t base, uint64_t len)
+/**
+ * Calculates a mask covering "moving" bits of all addresses of a region
+ *
+ * The i-th bit of the mask must be set if there's 2 different addresses
+ * in the region that have different j-th bits. where j >= i.
+ *
+ * e.g:
+ *       base=0x1B00000000
+ *   len+base=0x1B00042000
+ *
+ *   ought to return 0x000007FFFF, which implies that every bit position
+ *   with a zero in the mask remains unchanged in every address of the
+ *   region.
+ *
+ * @param base Base address of the region
+ * @param len  Size in octets of the region
+ * @return Mask of moving bits at the bottom of all the region addresses
+ */
+static uint64_t pdx_region_mask(uint64_t base, uint64_t len)
 {
     /*
      * We say a bit "moves" in a range if there exist 2 addresses in that
@@ -168,9 +207,46 @@ uint64_t pdx_region_mask(uint64_t base, uint64_t len)
     return fill_mask(base ^ (base + len - 1));
 }
 
-void __init pfn_pdx_hole_setup(unsigned long mask)
+bool pdx_is_region_compressible(paddr_t base, unsigned long npages)
+{
+    return !(paddr_to_pfn(base) & pfn_hole_mask) &&
+           !(pdx_region_mask(base, npages * PAGE_SIZE) & ~ma_va_bottom_mask);
+}
+
+/**
+ * Creates the mask to start from when calculating non-compressible bits
+ *
+ * This function is intimately related to pdx_region_mask(), and together
+ * they are meant to calculate the mask of non-compressible bits given the
+ * current memory map.
+ *
+ * @param base_addr Address of the first maddr in the system
+ * @return An integer of the form 2^n - 1
+ */
+static uint64_t __init pdx_init_mask(uint64_t base_addr)
+{
+    return fill_mask(max(base_addr,
+                         /* Don't compress the low MAX_ORDER bits. */
+                         (uint64_t)1 << (MAX_ORDER + PAGE_SHIFT)) - 1);
+}
+
+void __init pfn_pdx_compression_setup(paddr_t base)
 {
     unsigned int i, j, bottom_shift = 0, hole_shift = 0;
+    unsigned long mask = pdx_init_mask(base);
+
+    if ( nr > ARRAY_SIZE(ranges) )
+    {
+        printk(XENLOG_WARNING
+               "Too many PFN ranges (%u), not attempting PFN compression\n",
+               nr);
+        return;
+    }
+
+    for ( i = 0; i < nr; i++ )
+        mask |= pfn_to_paddr(ranges[i].base) |
+                pdx_region_mask(pfn_to_paddr(ranges[i].base),
+                                pfn_to_paddr(ranges[i].size));
 
     /*
      * We skip the first MAX_ORDER bits, as we never want to compress them.
@@ -209,6 +285,16 @@ void __init pfn_pdx_hole_setup(unsigned long mask)
     ma_top_mask         = pfn_top_mask << PAGE_SHIFT;
 }
 
+void __init pfn_pdx_compression_reset(void)
+{
+    pfn_pdx_bottom_mask = ~0UL;
+    ma_va_bottom_mask = ~0UL;
+    pfn_top_mask = 0;
+    ma_top_mask = 0;
+    pfn_hole_mask = 0;
+    pfn_pdx_hole_shift = 0;
+}
+
 #endif /* CONFIG_PDX_COMPRESSION */
 
 /*
diff --git a/xen/include/xen/pdx.h b/xen/include/xen/pdx.h
index ec0827936c2f..43ce36fcbb56 100644
--- a/xen/include/xen/pdx.h
+++ b/xen/include/xen/pdx.h
@@ -115,38 +115,6 @@ extern unsigned int pfn_pdx_hole_shift;
 extern unsigned long pfn_hole_mask;
 extern unsigned long pfn_top_mask, ma_top_mask;
 
-/**
- * Calculates a mask covering "moving" bits of all addresses of a region
- *
- * The i-th bit of the mask must be set if there's 2 different addresses
- * in the region that have different j-th bits. where j >= i.
- *
- * e.g:
- *       base=0x1B00000000
- *   len+base=0x1B00042000
- *
- *   ought to return 0x000007FFFF, which implies that every bit position
- *   with a zero in the mask remains unchanged in every address of the
- *   region.
- *
- * @param base Base address of the region
- * @param len  Size in octets of the region
- * @return Mask of moving bits at the bottom of all the region addresses
- */
-uint64_t pdx_region_mask(uint64_t base, uint64_t len);
-
-/**
- * Creates the mask to start from when calculating non-compressible bits
- *
- * This function is intimately related to pdx_region_mask(), and together
- * they are meant to calculate the mask of non-compressible bits given the
- * current memory map.
- *
- * @param base_addr Address of the first maddr in the system
- * @return An integer of the form 2^n - 1
- */
-uint64_t pdx_init_mask(uint64_t base_addr);
-
 /**
  * Map pfn to its corresponding pdx
  *
@@ -196,17 +164,6 @@ static inline paddr_t directmapoff_to_maddr(unsigned long offset)
             (offset & ma_va_bottom_mask));
 }
 
-/**
- * Initializes global variables with information about the compressible
- * range of the current memory regions.
- *
- * @param mask This mask is the biggest pdx_mask of every region in the
- *             system ORed with all base addresses of every region in the
- *             system. This results in a mask where every zero in a bit
- *             position marks a potentially compressible bit.
- */
-void pfn_pdx_hole_setup(unsigned long mask);
-
 #endif /* CONFIG_PDX_MASK_COMPRESSION */
 
 #ifdef CONFIG_PDX_NONE
@@ -227,17 +184,15 @@ static inline bool pdx_is_region_compressible(paddr_t base,
     return true;
 }
 
-static inline uint64_t pdx_init_mask(uint64_t base_addr)
+static inline void pfn_pdx_add_region(paddr_t base, paddr_t size)
 {
-    return 0;
 }
 
-static inline uint64_t pdx_region_mask(uint64_t base, uint64_t len)
+static inline void pfn_pdx_compression_setup(paddr_t base)
 {
-    return 0;
 }
 
-static inline void pfn_pdx_hole_setup(unsigned long mask)
+static inline void pfn_pdx_compression_reset(void)
 {
 }
 
@@ -254,6 +209,28 @@ static inline void pfn_pdx_hole_setup(unsigned long mask)
  */
 bool pdx_is_region_compressible(paddr_t base, unsigned long npages);
 
+/**
+ * Register a RAM region with the PFN compression logic.
+ *
+ * @param base Start of the region in bytes.
+ * @param size Length of the region in bytes.
+ */
+void pfn_pdx_add_region(paddr_t base, paddr_t size);
+
+/**
+ * Initializes global variables with information about the compressible
+ * range of the current memory regions.
+ *
+ * @param base address to start compression from.
+ */
+void pfn_pdx_compression_setup(paddr_t base);
+
+/**
+ * Reset the global variables to it's default values, thus disabling PFN
+ * compression.
+ */
+void pfn_pdx_compression_reset(void);
+
 #endif /* !CONFIG_PDX_NONE */
 #endif /* __XEN_PDX_H__ */
 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 17:23:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 17:23:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011971.1390526 (Exim 4.92)
	(envelope-from )
	id 1uPPAC-0003qD-6g; Wed, 11 Jun 2025 17:23:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011971.1390526; Wed, 11 Jun 2025 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 1uPPAC-0003q1-2w; Wed, 11 Jun 2025 17:23:00 +0000
Received: by outflank-mailman (input) for mailman id 1011971;
 Wed, 11 Jun 2025 17:22: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 1uPPAA-0002dK-NW
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 17:22:58 +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 b805d6f6-46e8-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 19:22:58 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-442e9c00bf4so66455e9.3
 for ; Wed, 11 Jun 2025 10:22:58 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-45325228c2esm27826355e9.37.2025.06.11.10.22.56
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 11 Jun 2025 10:22:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b805d6f6-46e8-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749662577; x=1750267377; darn=lists.xenproject.org;
        h=content-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=obTz8sNg81B0kZWShjd1UWWyGzjIKb4UunTkiMwCARY=;
        b=oXiDAi/31IbPs52B+ZJe6Pa/db+D4Mrq14kh3g9pI2mnY0f6mq6CoXm1yUpi+f6Jwa
         ZrnH44VRLBx1dNP/S63fIVa03EkGl+JEf1lnE9eF/jx5kDiGVPArkIkFxbkLAs7iKprJ
         6c7h/l1r++1i5UdB7wwq/PULluBo6/R1qOkUQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749662577; x=1750267377;
        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=obTz8sNg81B0kZWShjd1UWWyGzjIKb4UunTkiMwCARY=;
        b=MccZpVk+UrhxYAkoM3jZmcluvb162SF8CCACN2zchDNoUDnCwcITI835u4QjZQVEg5
         WQmo97gRd/JXCYwEbVF13G+7UVQmmtq0bSai1gP2IJRpNMocWYvpbHzxMKnCZhB8rlYM
         peJMZrAYR2KYHB4nscn85iH8VLmHxgvJW7MKdlFHpHOWIA7fufTcvqjlTxEup0BTvGy1
         4pYT3RKaPfRh/x1XRAO+8PAlogYja73n8wuYnmBblHYeXG6AEVHEu4ehIOUzC2ESOjFY
         O6fbzfsvxU+mpc9J8FSh7wcQsCUZEbFaVlhDQeJSplN8EX1eWzH+GuMsdl2uB/vgEjYE
         RniA==
X-Gm-Message-State: AOJu0Yxbe5DSkrOxx4E0EJ2YUpS/h99sG6pXNzPfejDknfBeXpvHrw8l
	kCtCZnkBTxCXpEKKW8JSGSOETWk4tve04eKHBmrWmQq6fDC/FFbktoqIuSE1U7DHf2OtJHy9tUL
	lHmff
X-Gm-Gg: ASbGncuI5bi+v7nx4JphK9qOD1/G4/5JVlNxgf3R/4Zct7+Xs7nyGczjphQcMg+FyJB
	89pYocAxJjNb8TICguclCKG79Jh1JOcs/TaQS0w7EqE1Z2XEVz/34a28/YNEZpJIIgA6kBoPdJ/
	zaGfgJwKIId+USBM8lHsQYugxb30CVXOqap+tm1vdq0fAzBeZn/pcLvlqsOCKTE28zGSVtUF3Lo
	qQ4WK8gUKWweRFYo5kxfd9RWtGVgCXx6YlfnRPVo7ODgd2RKKUEBrFGZRcAFw4KYuyW7w/fUo5r
	GdZr7Ue2WKwflrGI7hj2Lq2nko1Uj2w2/YtP3TJsNnskfVGewILY3w9nKFUhzUp8GTSf1/mEc2h
	UUDfK6LclV4lUoycx4IqHjY6CsCIjN7yD6vA8isDDz77OBw==
X-Google-Smtp-Source: AGHT+IEKUs16PXyfT6xB9xcCuFwTvKq0tDdieJnf5nDjt0WbGz7eLEcC6NTeRzeRL8WjKfPSmY7HqQ==
X-Received: by 2002:a05:600c:8418:b0:43c:fd27:a216 with SMTP id 5b1f17b1804b1-4532b91ee36mr6380175e9.23.1749662577174;
        Wed, 11 Jun 2025 10:22:57 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Anthony PERARD ,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Bertrand Marquis ,
	Volodymyr Babchuk 
Subject: [PATCH 6/8] pdx: introduce a new compression algorithm based on offsets between regions
Date: Wed, 11 Jun 2025 19:16:34 +0200
Message-ID: <20250611171636.5674-7-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250611171636.5674-1-roger.pau@citrix.com>
References: <20250611171636.5674-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

With the appearance of Intel Sierra Forest and Granite Rapids it's not
possible to get a production x86 host wit the following memory map:

SRAT: Node 0 PXM 0 [0000000000000000, 000000007fffffff]
SRAT: Node 0 PXM 0 [0000000100000000, 000000407fffffff]
SRAT: Node 1 PXM 1 [0000061e80000000, 0000065e7fffffff]
SRAT: Node 2 PXM 2 [00000c3e80000000, 00000c7e7fffffff]
SRAT: Node 3 PXM 3 [0000125e80000000, 0000129e7fffffff]

This is from a four socket system, with each node having 256GB of memory.
The total amount of RAM on the system is 1TB, but without enabling
CONFIG_BIGMEM the last range is not accessible, as it's above the 16TB
boundary covered by the frame table.

Note that while the memory map is very sparse, it won't be compressible
using the current algorithm that relies on all ranges having a shared
zeroed region of bits that can be removed.

The memory map presented above has the property of all regions being
similarly spaced between each other, and all having also a similar size.
This allows to compress them using the following formula:

 pdx = (pfn % offset) + ((pfn / offset) * size)

Where offset and size are two static coefficients calculated at
initialization.

Obtaining the optimum offset and size coefficients is the complicated part.
In this patch I introduce two different algorithms, a fast one that works
correctly when the offset and size between ranges is mostly equal.  If such
fast algorithm doesn't work, or the resulting compression is not enough to
avoid truncation of the maximum usable page, it's possible to attempt a
brute force approach for calculating the coefficients.  This is also
implemented in this patch as the slow variant.  I've attempted to restrict
the number of iterations in the slow approach so it can exit early if no
better coefficients can be found due to the input constrains (minimum
region size).

The patch here focuses on introducing the logic to calculate the
compression coefficients, plus adding a unit test to exercise the logic
easily from user-space in order to test different layouts and possibly
improve the generation of the coefficients.  The added unit tests only
covers the newly added compression, but could also be extended to cover the
existing PDX mask compression.

Note the translation functions (pfn to pdx, maddr to direct map offset),
are not implemented as part of this patch, an identity set of macros are
added to satisfy the build requirements.  The patch is already long enough
without those.

Signed-off-by: Roger Pau Monné 
---
We can discuss whether we want both the fast and the slow variants.  The
slow (brute force) was added as a result of me playing with weird region
layouts where the fast one didn't manage to compress, or the resulting
coefficients had a poor compression ratio.  However at this point the
slow variant has only proven helpful in synthetic cases, I haven't (yet?)
seen a real host memory layout that would benefit from it.
---
 tools/tests/Makefile              |   1 +
 tools/tests/pdx/.gitignore        |   3 +
 tools/tests/pdx/Makefile          |  54 ++++++
 tools/tests/pdx/harness.h         |  73 +++++++
 tools/tests/pdx/test-pdx-offset.c | 310 ++++++++++++++++++++++++++++++
 xen/arch/arm/setup.c              |   2 +-
 xen/arch/x86/srat.c               |   2 +-
 xen/common/Kconfig                |   9 +-
 xen/common/pdx.c                  | 232 +++++++++++++++++++++-
 xen/include/xen/pdx.h             |  46 ++++-
 10 files changed, 724 insertions(+), 8 deletions(-)
 create mode 100644 tools/tests/pdx/.gitignore
 create mode 100644 tools/tests/pdx/Makefile
 create mode 100644 tools/tests/pdx/harness.h
 create mode 100644 tools/tests/pdx/test-pdx-offset.c

diff --git a/tools/tests/Makefile b/tools/tests/Makefile
index 36928676a666..97ba2a13894d 100644
--- a/tools/tests/Makefile
+++ b/tools/tests/Makefile
@@ -9,6 +9,7 @@ ifneq ($(clang),y)
 SUBDIRS-$(CONFIG_X86) += x86_emulator
 endif
 SUBDIRS-y += xenstore
+SUBDIRS-y += pdx
 SUBDIRS-y += rangeset
 SUBDIRS-y += vpci
 SUBDIRS-y += paging-mempool
diff --git a/tools/tests/pdx/.gitignore b/tools/tests/pdx/.gitignore
new file mode 100644
index 000000000000..21b60480415a
--- /dev/null
+++ b/tools/tests/pdx/.gitignore
@@ -0,0 +1,3 @@
+/pdx-offset.c
+/pdx.h
+/test-pdx-offset
diff --git a/tools/tests/pdx/Makefile b/tools/tests/pdx/Makefile
new file mode 100644
index 000000000000..141ae6aab56f
--- /dev/null
+++ b/tools/tests/pdx/Makefile
@@ -0,0 +1,54 @@
+XEN_ROOT=$(CURDIR)/../../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+TARGET := test-pdx-offset
+
+.PHONY: all
+all: $(TARGET)
+
+.PHONY: run
+run: $(TARGET)
+ifeq ($(CC),$(HOSTCC))
+	./$<
+else
+	$(warning HOSTCC != CC, will not run test)
+endif
+
+.PHONY: clean
+clean:
+	$(RM) -- *.o $(TARGET) $(DEPS_RM) pdx.c pdx.h
+
+.PHONY: distclean
+distclean: clean
+	$(RM) -- *~
+
+.PHONY: install
+install: all
+	$(INSTALL_DIR) $(DESTDIR)$(LIBEXEC)/tests
+	$(INSTALL_PROG) $(TARGET) $(DESTDIR)$(LIBEXEC)/tests
+
+.PHONY: uninstall
+uninstall:
+	$(RM) -- $(DESTDIR)$(LIBEXEC)/tests/$(TARGET)
+
+pdx.h: $(XEN_ROOT)/xen/include/xen/pdx.h
+	sed -E -e '/^#[[:space:]]?include/d' <$< >$@
+
+pdx-offset.c: $(XEN_ROOT)/xen/common/pdx.c
+	# Remove includes/errors and add the test harness header
+	sed -E -e '/#[[:space:]]?include/d' -e '/^#[[:space:]]?error/d' \
+	       -e '1s/^/#include "harness.h"/' <$< >$@
+
+CFLAGS += -D__XEN_TOOLS__
+CFLAGS += $(APPEND_CFLAGS)
+CFLAGS += $(CFLAGS_xeninclude)
+
+LDFLAGS += $(APPEND_LDFLAGS)
+
+test-pdx-offset.o pdx-offset.o: pdx.h
+test-pdx-offset.o pdx-offset.o: CFLAGS += -DCONFIG_PDX_OFFSET_COMPRESSION
+
+test-pdx-offset: pdx-offset.o test-pdx-offset.o
+	$(CC) $^ -o $@ $(LDFLAGS)
+
+-include $(DEPS_INCLUDE)
diff --git a/tools/tests/pdx/harness.h b/tools/tests/pdx/harness.h
new file mode 100644
index 000000000000..3d31cf488daf
--- /dev/null
+++ b/tools/tests/pdx/harness.h
@@ -0,0 +1,73 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Unit tests for PDX compression.
+ *
+ * Copyright (C) 2025 Cloud Software Group
+ */
+
+#ifndef _TEST_HARNESS_
+#define _TEST_HARNESS_
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+void pdx_reset(void);
+
+#define __init
+#define __initdata
+#define __ro_after_init
+#define cf_check
+
+#define printk printf
+#define dprintk(lvl, ...) printf(__VA_ARGS__)
+#define XENLOG_INFO
+#define XENLOG_DEBUG
+#define XENLOG_WARNING
+
+#define PAGE_SHIFT    12
+/* Some libcs define PAGE_SIZE in limits.h. */
+#undef  PAGE_SIZE
+#define PAGE_SIZE     (1 << PAGE_SHIFT)
+#define MAX_ORDER     18 /* 2 * PAGETABLE_ORDER (9) */
+
+#define PFN_DOWN(x)   ((x) >> PAGE_SHIFT)
+#define PFN_UP(x)     (((x) + PAGE_SIZE-1) >> PAGE_SHIFT)
+
+#define MAX_RANGES 8
+#define MAX_PFN_RANGES MAX_RANGES
+
+#define ASSERT assert
+#define ASSERT_UNREACHABLE() assert(0);
+
+#define STATIC
+typedef uint64_t paddr_t;
+
+bool pfn_offset_calculate_fast(unsigned long base);
+bool pfn_offset_calculate_slow(unsigned long base);
+void pfn_offset_sanitize_ranges(void);
+
+#define sort(elem, nr, size, cmp, swp) {                                \
+    /* Consume swp() so compiler doesn't complain it's unused. */       \
+    swp(&elem[0], &elem[0], size);                                      \
+    qsort(elem, nr, size, cmp);                                         \
+}
+
+#include "pdx.h"
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/tests/pdx/test-pdx-offset.c b/tools/tests/pdx/test-pdx-offset.c
new file mode 100644
index 000000000000..0a561f02d197
--- /dev/null
+++ b/tools/tests/pdx/test-pdx-offset.c
@@ -0,0 +1,310 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Unit tests for PDX offset compression.
+ *
+ * Copyright (C) 2025 Cloud Software Group
+ */
+
+#include "harness.h"
+
+struct range {
+    /* Ranges are defined as [start, end). */
+    unsigned long start, end;
+};
+
+static void print_ranges(const struct range *r)
+{
+    unsigned int i;
+
+    printf("Ranges:\n");
+
+    for ( i = 0; i < MAX_RANGES; i++ )
+    {
+        if ( !r[i].start && !r[i].end )
+            break;
+
+        printf(" %013lx-%013lx\n", r[i].start, r[i].end);
+    }
+}
+
+int main(int argc, char **argv)
+{
+    static const struct {
+        struct range ranges[MAX_RANGES];
+        struct result {
+            bool compress;
+            unsigned long offset, size;
+        } results[2];
+#define FAST_IDX 0
+#define SLOW_IDX 1
+    } tests[] = {
+#ifdef __LP64__
+        /*
+         * Only for targets where unsigned long is 64bits, otherwise compiler
+         * will complain about truncation from 'long long' -> 'long' conversion.
+         *
+         * Real memory map from a 4s Intel GNR.
+         */
+        {
+            .ranges = {
+                { .start =           0,   .end =   0x8080000UL },
+                { .start =  0x63e80000UL, .end =  0x6be80000UL },
+                { .start =  0xc7e80000UL, .end =  0xcfe80000UL },
+                { .start = 0x12be80000UL, .end = 0x133e80000UL },
+            },
+            .results = {
+                /* Same result with both fast and slow algorithms. */
+                [FAST_IDX ... SLOW_IDX] = {
+                    .compress = true,
+                    .offset = 0x63e80000UL,
+                    .size = 0x8300000UL,
+                },
+            },
+        },
+#endif
+        /* 2-node 2GB per-node QEMU layout. */
+        {
+            .ranges = {
+                { .start =        0,   .end =  0x80000UL },
+                { .start = 0x100000UL, .end = 0x180000UL },
+            },
+            .results = {
+                /* Same result with both fast and slow algorithms. */
+                [FAST_IDX ... SLOW_IDX] = {
+                    .compress = true,
+                    .offset = 0x100000UL,
+                    .size = 0x80000UL,
+                },
+            },
+        },
+        /* Not compressible, offset < size. */
+        {
+            .ranges = {
+                { .start = 0, .end =    1   },
+                { .start = 1, .end = 0x10UL },
+            },
+            .results = {
+                /* Same result with both fast and slow algorithms. */
+                [FAST_IDX ... SLOW_IDX] = {
+                    .compress = false,
+                },
+            },
+        },
+        /* Not compressible, offset < (1 << MAX_ORDER). */
+        {
+            .ranges = {
+                { .start =     0,   .end =     1   },
+                { .start = 0x100UL, .end = 0x101UL },
+            },
+            .results = {
+                /* Same result with both fast and slow algorithms. */
+                [FAST_IDX ... SLOW_IDX] = {
+                    .compress = false,
+                },
+            },
+        },
+        /* Compressible, requires adjusting size to (1 << MAX_ORDER). */
+        {
+            .ranges = {
+                { .start =        0,   .end =        1   },
+                { .start = 0x100000UL, .end = 0x100001UL },
+            },
+            .results = {
+                /* Same result with both fast and slow algorithms. */
+                [FAST_IDX ... SLOW_IDX] = {
+                    .compress = true,
+                    .offset = 0x100000UL,
+                    .size = (1UL << MAX_ORDER),
+                },
+            },
+        },
+        /* 2s Intel CLX with contiguous ranges, no compression. */
+        {
+            .ranges = {
+                { .start =        0  , .end =  0x180000UL },
+                { .start = 0x180000UL, .end = 0x3040000UL },
+            },
+            .results = {
+                /* Same result with both fast and slow algorithms. */
+                [FAST_IDX ... SLOW_IDX] = {
+                    .compress = false,
+                },
+            },
+        },
+        /* Middle range is bigger than first and last */
+        {
+            .ranges = {
+                { .start =         0,   .end =         1   },
+                { .start =  0x100000UL, .end =  0x180000UL },
+                { .start = 0x1000000UL, .end = 0x1000001UL },
+            },
+            .results = {
+                [FAST_IDX] = {
+                    .compress = true,
+                    .offset = 0x100000UL,
+                    .size = 0x80000UL,
+                },
+                [SLOW_IDX] = {
+                    .compress = true,
+                    .offset = 0xf00000UL,
+                    .size = 0x180000UL,
+                },
+            },
+        },
+        /* Test divergence between fast and slow algorithms. */
+        {
+            .ranges = {
+                { .start =                    0,
+                  .end   = (1 << MAX_ORDER) * 1 },
+                { .start = (1 << MAX_ORDER) * 11,
+                  .end   = (1 << MAX_ORDER) * 12 },
+                { .start = (1 << MAX_ORDER) * 20,
+                  .end   = (1 << MAX_ORDER) * 21 },
+            },
+            .results = {
+                [FAST_IDX] = { /* 66% */
+                    .compress = true,
+                    .offset = (1 << MAX_ORDER) * 9,
+                    .size = (1 << MAX_ORDER) * 3,
+                },
+                [SLOW_IDX] = { /* 80% */
+                    .compress = true,
+                    .offset = (1 << MAX_ORDER) * 10,
+                    .size = (1 << MAX_ORDER) * 2,
+                },
+            },
+        },
+        /* Test divergence between fast and slow algorithms. */
+        {
+            .ranges = {
+                { .start =                    0,
+                  .end   = (1 << MAX_ORDER) * 1 },
+                { .start = (1 << MAX_ORDER) * 11,
+                  .end   = (1 << MAX_ORDER) * 12 },
+                { .start = (1 << MAX_ORDER) * 30,
+                  .end   = (1 << MAX_ORDER) * 31 },
+            },
+            .results = {
+                [FAST_IDX] = { /* 18% */
+                    .compress = true,
+                    .offset = (1 << MAX_ORDER) * 11,
+                    .size = (1 << MAX_ORDER) * 9,
+                },
+                [SLOW_IDX] = { /* 80% */
+                    .compress = true,
+                    .offset = (1 << MAX_ORDER) * 10,
+                    .size = (1 << MAX_ORDER) * 2,
+                },
+            },
+        },
+        /* Test incompressible using fast vs compressible using slow. */
+        {
+            .ranges = {
+                { .start =                    0,
+                  .end   = (1 << MAX_ORDER) * 1 },
+                { .start = (1 << MAX_ORDER) * 2,
+                  .end   = (1 << MAX_ORDER) * 3 },
+                { .start = (1 << MAX_ORDER) * 20,
+                  .end   = (1 << MAX_ORDER) * 22 },
+            },
+            .results = {
+                [FAST_IDX] = {
+                    .compress = false,
+                },
+                [SLOW_IDX] = {
+                    .compress = true,
+                    .offset = (1 << MAX_ORDER) * 18,
+                    .size = (1 << MAX_ORDER) * 4,
+                },
+            },
+        },
+    };
+    int ret_code = EXIT_SUCCESS;
+
+    for ( unsigned int i = 0 ; i < ARRAY_SIZE(tests); i++ )
+    {
+        for ( unsigned int use_slow = 0;
+              use_slow < ARRAY_SIZE(tests[i].results); use_slow++ )
+        {
+            const struct result *result = &tests[i].results[use_slow];
+            unsigned int j;
+
+            pfn_pdx_compression_reset();
+
+            for ( j = 0; j < ARRAY_SIZE(tests[i].ranges); j++ )
+            {
+                unsigned long size = tests[i].ranges[j].end -
+                                     tests[i].ranges[j].start;
+
+                if ( !tests[i].ranges[j].start && !tests[i].ranges[j].end )
+                    break;
+
+                pfn_pdx_add_region(tests[i].ranges[j].start << PAGE_SHIFT,
+                                   size << PAGE_SHIFT, j);
+            }
+
+            pfn_offset_sanitize_ranges();
+
+            if ( result->compress != (use_slow ? pfn_offset_calculate_slow(0)
+                                               : pfn_offset_calculate_fast(0)) )
+            {
+                printf("PFN %s compression diverge, expected %scompressible\n",
+                       use_slow ? "slow" : "fast",
+                       result->compress ? "" : "un");
+                print_ranges(tests[i].ranges);
+
+                ret_code = EXIT_FAILURE;
+                continue;
+            }
+
+            if ( !result->compress )
+                continue;
+
+            if ( result->offset != pdx_offset || result->size != pdx_size )
+            {
+                printf("PFN %s compression result diverge, expected:\n",
+                       use_slow ? "slow" : "fast");
+                printf(" offset %013lx size %013lx (%lu%%)\n",
+                       result->offset, result->size,
+                       ((result->offset - result->size) * 100) / result->offset);
+                printf("got:\n offset %013lx size %013lx (%lu%%)\n",
+                       pdx_offset, pdx_size,
+                       ((pdx_offset - pdx_size) * 100) / pdx_offset);
+                print_ranges(tests[i].ranges);
+
+                ret_code = EXIT_FAILURE;
+                continue;
+            }
+
+            for ( j = 0; j < ARRAY_SIZE(tests[i].ranges); j++ )
+            {
+                unsigned long start = tests[i].ranges[j].start;
+                unsigned long end = tests[i].ranges[j].end;
+
+                if ( !start && !end )
+                    break;
+
+                if ( !pdx_is_region_compressible(start << PAGE_SHIFT, 1) ||
+                     !pdx_is_region_compressible((end - 1) << PAGE_SHIFT, 1) )
+                {
+                    printf(
+    "PFN %s compression invalid, pages %#lx and %#lx should be compressible\n",
+                           use_slow ? "slow" : "fast", start, end - 1);
+                    print_ranges(tests[i].ranges);
+                    ret_code = EXIT_FAILURE;
+                }
+            }
+        }
+    }
+
+    return ret_code;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 93ebfc29635e..e71908b99c14 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -258,7 +258,7 @@ void __init init_pdx(void)
     unsigned int bank;
 
     for ( bank = 0 ; bank < mem->nr_banks; bank++ )
-        pfn_pdx_add_region(mem->bank[bank].start, mem->bank[bank].size);
+        pfn_pdx_add_region(mem->bank[bank].start, mem->bank[bank].size, bank);
 
     /*
      * Arm does not have any restrictions on the bits to compress. Pass 0 to
diff --git a/xen/arch/x86/srat.c b/xen/arch/x86/srat.c
index 96a87bbce35b..dffe81e067e9 100644
--- a/xen/arch/x86/srat.c
+++ b/xen/arch/x86/srat.c
@@ -280,7 +280,7 @@ static int __init cf_check srat_parse_region(
 		printk(KERN_INFO "SRAT: %013"PRIx64"-%013"PRIx64"\n",
 		       ma->base_address, ma->base_address + ma->length - 1);
 
-	pfn_pdx_add_region(ma->base_address, ma->length);
+	pfn_pdx_add_region(ma->base_address, ma->length, ma->proximity_domain);
 
 	return 0;
 }
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 7ffd9d7d9003..17afa9fe5f5c 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -54,7 +54,8 @@ config EVTCHN_FIFO
 
 choice
 	prompt "PDX (Page inDeX) compression"
-	default PDX_MASK_COMPRESSION if !X86 && !RISCV
+	default PDX_OFFSET_COMPRESSION if X86
+	default PDX_MASK_COMPRESSION if !RISCV
 	default PDX_NONE
 	help
 	  PDX compression is a technique designed to reduce the memory
@@ -73,6 +74,12 @@ config PDX_MASK_COMPRESSION
 	help
 	  Compression relying on all RAM addresses sharing a zeroed bit region.
 
+config PDX_OFFSET_COMPRESSION
+	bool "Offset compression"
+	help
+	  Compression relying on size and distance between RAM regions being
+	  constant.
+
 config PDX_NONE
 	bool "None"
 	help
diff --git a/xen/common/pdx.c b/xen/common/pdx.c
index 7d14100224fe..f2cf60bbc3f8 100644
--- a/xen/common/pdx.c
+++ b/xen/common/pdx.c
@@ -21,6 +21,15 @@
 #include 
 #include 
 #include 
+#include 
+
+#ifdef __XEN__ /* For building the file in user-space. */
+
+/*
+ * Use a define for the static keyword, we want to export some otherwise static
+ * functions for the unit tests.
+ */
+#define STATIC static
 
 /**
  * Maximum (non-inclusive) usable pdx. Must be
@@ -80,6 +89,7 @@ unsigned long get_max_pfn(unsigned long top_pfn)
 
     return pdx_to_pfn(pdx - 1) + 1;
 }
+#endif /* __XEN__ */
 
 #ifndef CONFIG_PDX_NONE
 
@@ -96,10 +106,11 @@ unsigned long get_max_pfn(unsigned long top_pfn)
 /* Generic PFN compression helpers. */
 static struct pfn_range {
     unsigned long base, size;
+    unsigned int id;
 } ranges[MAX_PFN_RANGES] __initdata;
 static unsigned int __initdata nr;
 
-void __init pfn_pdx_add_region(paddr_t base, paddr_t size)
+void __init pfn_pdx_add_region(paddr_t base, paddr_t size, unsigned int id)
 {
     if ( nr >= ARRAY_SIZE(ranges) )
     {
@@ -108,6 +119,7 @@ void __init pfn_pdx_add_region(paddr_t base, paddr_t size)
         return;
     }
 
+    ranges[nr].id = id;
     ranges[nr].base = PFN_DOWN(base);
     ranges[nr++].size = PFN_UP(base + size) - PFN_DOWN(base);
 }
@@ -297,7 +309,223 @@ void __init pfn_pdx_compression_reset(void)
     pfn_pdx_hole_shift = 0;
 }
 
-#endif /* CONFIG_PDX_COMPRESSION */
+#elif defined(CONFIG_PDX_OFFSET_COMPRESSION) /* CONFIG_PDX_MASK_COMPRESSION */
+
+unsigned long __ro_after_init pdx_offset = ~0UL;
+unsigned long __ro_after_init pdx_size = ~0UL;
+
+static unsigned long __initdata top_pfn;
+
+bool pdx_is_region_compressible(paddr_t base, unsigned long npages)
+{
+    return !pdx_size ? true
+                     : (PFN_DOWN(base) % pdx_offset) + npages <= pdx_size;
+}
+
+STATIC bool __init pfn_offset_calculate_fast(unsigned long base)
+{
+    unsigned long size = max((1UL << MAX_ORDER), base);
+    unsigned long offset = ~0UL;
+    unsigned int i;
+
+    if ( nr <= 1 )
+        return false;
+
+    /* Calculate minimal offset between regions. */
+    for ( i = 1; i < nr; i++ )
+        offset = min(offset, ranges[i].base - ranges[i - 1].base);
+
+    /* Return early if offset is smaller than the minimum size. */
+    if ( size >= offset )
+        return false;
+
+    /* Calculate size so it covers all regions based on the minimal offset. */
+    for ( i = 0; i < nr; i++ )
+        size = max(size, ranges[i].base % offset + ranges[i].size);
+
+    if ( size >= offset )
+        return false;
+
+    pdx_offset = offset;
+    pdx_size = size;
+
+    return true;
+}
+
+STATIC bool __init pfn_offset_calculate_slow(unsigned long base)
+{
+    unsigned long min_size = max((1UL << MAX_ORDER), base);
+    unsigned long offset, max_offset = 0;
+    unsigned int i, best_ratio = 0;
+
+    if ( nr <= 1 )
+        return false;
+
+    for ( i = 0; i < nr; i++ )
+    {
+        /* Minimal size required to cover the bigger region in the set. */
+        min_size = max(min_size, ranges[i].size);
+        if ( !i )
+            continue;
+
+        max_offset = max(max_offset, ranges[i].base - ranges[i - 1].base);
+    }
+
+    if ( min_size >= max_offset )
+        return false;
+
+    for ( offset = max_offset; offset > min_size; offset-- )
+    {
+        unsigned long size = min_size;
+        unsigned int ratio;
+
+        /*
+         * Terminate loop if it's impossible to get a better ratio given the
+         * decreasing offset and the minimal required region size.
+         */
+        if ( best_ratio >= ((offset - size) * 100) / offset )
+            break;
+
+        for ( i = 0; i < nr; i++ )
+            size = max(size, (ranges[i].base % offset) + ranges[i].size);
+
+        if ( size >= offset )
+            continue;
+
+        ratio = ((offset - size) * 100) / offset;
+        if ( ratio > best_ratio )
+        {
+            best_ratio = ratio;
+            pdx_offset = offset;
+            pdx_size = size;
+        }
+    }
+
+    return best_ratio;
+}
+
+static int __init cf_check cmp_node(const void *a, const void *b)
+{
+    const struct pfn_range *l = a;
+    const struct pfn_range *r = b;
+
+    if ( l->base > r->base )
+        return 1;
+    if ( l->base < r->base )
+        return -1;
+
+    ASSERT_UNREACHABLE();
+    return 0;
+}
+
+static void __init cf_check swp_node(void *a, void *b, size_t size)
+{
+    struct pfn_range *l = a;
+    struct pfn_range *r = b;
+    struct pfn_range tmp = *l;
+
+    *l = *r;
+    *r = tmp;
+}
+
+STATIC void __init pfn_offset_sanitize_ranges(void)
+{
+    unsigned int i = 0;
+
+    /* Sort nodes by start address. */
+    sort(ranges, nr, sizeof(struct pfn_range), cmp_node, swp_node);
+
+    /* Merge ranges if possible. */
+    while ( i + 1 < nr )
+    {
+        if ( ranges[i].id == ranges[i + 1].id )
+        {
+            /* Merge ranges with the same ID. */
+            ranges[i].size = ranges[i + 1].base + ranges[i + 1].size -
+                             ranges[i].base;
+        }
+        else if ( ranges[i].base + ranges[i].size == ranges[i + 1].base )
+        {
+            /* Merge ranges if contiguous. */
+            ranges[i].size += ranges[i + 1].size;
+        }
+        else
+        {
+            i++;
+            continue;
+        }
+
+        /* Merge ranges. */
+        memmove(&ranges[i + 1], &ranges[i + 2],
+                (nr - (i + 2)) * sizeof(ranges[0]));
+        nr--;
+    }
+}
+
+#ifdef __XEN__
+bool __init pfn_pdx_compression_setup(paddr_t base)
+{
+    bool use_slow = false;
+
+    if ( nr <= 1 )
+        return false;
+
+    if ( nr > ARRAY_SIZE(ranges) )
+    {
+        printk(XENLOG_WARNING
+               "Too many NUMA nodes (%u), not attempting PFN compression\n",
+               nr);
+        return false;
+    }
+
+    pfn_offset_sanitize_ranges();
+
+    if ( nr <= 1 )
+        return false;
+
+    top_pfn = ranges[nr - 1].base + ranges[nr - 1].size;
+
+    for ( ; ; use_slow = true )
+    {
+        if ( use_slow ? pfn_offset_calculate_slow(PFN_DOWN(base))
+                      : pfn_offset_calculate_fast(PFN_DOWN(base)) )
+        {
+            if ( top_pfn != get_max_pfn(top_pfn) )
+                dprintk(XENLOG_DEBUG,
+                        "PFN %s compression coefficients truncate address space\n",
+                        use_slow ? "slow" : "fast");
+            else
+                break;
+        }
+        else
+        {
+            dprintk(XENLOG_DEBUG,
+                    "Find PFN compression coefficients using %s algorithm failed\n",
+                    use_slow ? "slow" : "fast");
+            if ( use_slow )
+                return false;
+        }
+
+        if ( use_slow )
+            break;
+    }
+
+    printk(XENLOG_INFO "PFN compression using offset %#lx size %#lx (%lu%%)\n",
+           pdx_offset, pdx_size, ((pdx_offset - pdx_size) * 100) / pdx_offset);
+
+    return true;
+}
+#endif /* __XEN__ */
+
+void __init pfn_pdx_compression_reset(void)
+{
+    pdx_size = ~0UL;
+    pdx_offset = ~0UL;
+    nr = 0;
+    top_pfn = 0;
+}
+
+#endif /* CONFIG_PDX_OFFSET_COMPRESSION */
 
 /*
  * Local variables:
diff --git a/xen/include/xen/pdx.h b/xen/include/xen/pdx.h
index 6cc0f54cff83..88f446f4ddd9 100644
--- a/xen/include/xen/pdx.h
+++ b/xen/include/xen/pdx.h
@@ -65,6 +65,31 @@
  * This scheme also holds for multiple regions, where HHHHHHH acts as
  * the region identifier and LLLLLL fully contains the span of every
  * region involved.
+ *
+ * ## PDX offset compression
+ *
+ * Alternative compression mechanism that relies on RAM ranges having a similar
+ * size and offset between them:
+ *
+ * ┌────────┬──────────┬────────┬──────────┐   ┌────────┬──────────┐
+ * │ RAM 0  │          │ RAM 1  │          │...│ RAM N  │          │
+ * ├────────┼──────────┼────────┴──────────┘   └────────┴──────────┘
+ * │<------>│          │
+ * │  size             │
+ * │<----------------->│
+ *         offset
+ *
+ * The compression removes the holes between RAM regions:
+ *
+ * ┌────────┬────────┐   ┌────────┐
+ * │ RAM 0  │ RAM 1  │...│ RAM N  │
+ * ├────────┼────────┘   └────────┘
+ * │<------>│
+ *    size
+ *
+ * The compressed index is calculated as:
+ *
+ * index = (pfn % offset) + ((pfn / offset) * size)
  */
 
 /* Macro defined per-arch to skip PDX logic when there's no compression. */
@@ -188,7 +213,20 @@ static inline paddr_t directmapoff_to_maddr(unsigned long offset)
                  offset);
 }
 
-#endif /* CONFIG_PDX_MASK_COMPRESSION */
+#elif defined(CONFIG_PDX_OFFSET_COMPRESSION) /* CONFIG_PDX_MASK_COMPRESSION */
+
+extern unsigned long pdx_offset;
+extern unsigned long pdx_size;
+
+/* pdx<->pfn == identity */
+#define pdx_to_pfn(x) (x)
+#define pfn_to_pdx(x) (x)
+
+/* directmap is indexed by maddr */
+#define maddr_to_directmapoff(x) (x)
+#define directmapoff_to_maddr(x) (x)
+
+#endif /* CONFIG_PDX_OFFSET_COMPRESSION */
 
 #ifdef CONFIG_PDX_NONE
 
@@ -208,7 +246,8 @@ static inline bool pdx_is_region_compressible(paddr_t base,
     return true;
 }
 
-static inline void pfn_pdx_add_region(paddr_t base, paddr_t size)
+static inline void pfn_pdx_add_region(paddr_t base, paddr_t size,
+                                      unsigned int id)
 {
 }
 
@@ -239,8 +278,9 @@ bool pdx_is_region_compressible(paddr_t base, unsigned long npages);
  *
  * @param base Start of the region in bytes.
  * @param size Length of the region in bytes.
+ * @param id Range group identifier (for example NUMA proximity domain ID).
  */
-void pfn_pdx_add_region(paddr_t base, paddr_t size);
+void pfn_pdx_add_region(paddr_t base, paddr_t size, unsigned int id);
 
 /**
  * Initializes global variables with information about the compressible
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 17:23:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 17:23:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011972.1390537 (Exim 4.92)
	(envelope-from )
	id 1uPPAD-000475-Qk; Wed, 11 Jun 2025 17:23:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011972.1390537; Wed, 11 Jun 2025 17:23: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 1uPPAD-00045y-KJ; Wed, 11 Jun 2025 17:23:01 +0000
Received: by outflank-mailman (input) for mailman id 1011972;
 Wed, 11 Jun 2025 17:22: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 1uPPAB-0002dK-Kl
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 17:22:59 +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 b896f9b6-46e8-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 19:22:59 +0200 (CEST)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-450d668c2a1so9006095e9.0
 for ; Wed, 11 Jun 2025 10:22:59 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a53229e014sm15847938f8f.3.2025.06.11.10.22.57
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 11 Jun 2025 10:22:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b896f9b6-46e8-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749662578; x=1750267378; darn=lists.xenproject.org;
        h=content-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=erB+0/PVXEUr1Y3mUBtzWwV6l1V3EbOGOg7XHwfxeDw=;
        b=usWatrAY9T/jVNJI4L1U18ZfEOtP3XTIx6a2dfbWhCXNz5TEXNaR5BvwdJ+oT/J8KS
         DRdFLhMnaXMC0TgTYGWSH1hMj/p5StbpEz6FzCG1ut0dzZkvNUSFA3Vf9VbbXv7b0GYC
         nYgduTmmdqgZTmHA1ci3gfNt7ue2JKCz///tI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749662578; x=1750267378;
        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=erB+0/PVXEUr1Y3mUBtzWwV6l1V3EbOGOg7XHwfxeDw=;
        b=ZyTI1SMr5P/Gw00XXP4GbFjVBsjr3lJTRoRPZx1/sRck377X9uYPJjLTuhanaDngoF
         Bi+ros/RtWkpRpOI0r66ffl/tJJ2UgNT0LzccqSoQlNUuOmuQ94CnbvK1hlZ7wahIyG8
         NnUsi7OYJ49DxuF+Dfdl/fNA6tMhiBYYR7/qtujS45r7TpmOQAS1x851/fP+vWKQPaSE
         pENIqvxy2PNb/jQ2ffzu/iiLOFNmAvA6H5k52KlucLzExElaZn3XGdCgVjAO1Nm+J7gJ
         m3A5A9DWtVc1uBRPoTyM5k42nW3l8RsPd1EJ6iQgRTBtORpzI7oCvQ92e6EV3gGnVYs3
         Cbbw==
X-Gm-Message-State: AOJu0YxH/SEvVRpHN1EcBJCDJeIdWbUNy4vDoHKRo44Zvtt6zWEHIrOU
	BDxg43hxEb4sVBTu7VtKcIxDe6uRPRMuu7sCM6b+cSz8o47Tkx+XVOc4E3yhjExp24y+9/3RF1m
	FuwFW
X-Gm-Gg: ASbGncvO4wVWMwWOmsWOxAcJFn/cWnasHcuMM7KV2TXcGEyqgbbtU3RXa4QBV0fqtKG
	9YYu1xe0qRXTb7eZ2CGe0jF77SYZOn2noSIkqi+tmH7lKaUK16/QRcy3pogN2WMgCT1PPIsTlNe
	GAaBY3k5MF8G14YAnoGI8CRISSkof9r5yRKJRYq8lC4LPxroSAWD799NjtgqTT3TYUtdcS/1g5l
	EYbpLq7EQroLzw4Te5HnEFKGGwAJa3r4aO0n8TDb0OldnGC2nl7RWGUqId8aOXZueS7Lm+pZJ5q
	iU7GJR5KmtSBV32rHZluZyTYj14LuftLf15Jq87vEEhA3Ko8c3L3bc779lWLLt2qZ9p563e0hpY
	IDXwL6ID6eY9Q8JcBfSefQuRD6CNqIivpRpk=
X-Google-Smtp-Source: AGHT+IFOh+vGQIbcfaAJyeyfLZqFKbGVoqo9AOb2DRYEWGmD4FX/+j7PzQL+TQgwZj5BOs8rUzzJWg==
X-Received: by 2002:a05:600c:3484:b0:450:d79d:3b16 with SMTP id 5b1f17b1804b1-4532c2b3123mr2844535e9.14.1749662578442;
        Wed, 11 Jun 2025 10:22:58 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Anthony PERARD ,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH 7/8] pdx: introduce translation helpers for offset compression
Date: Wed, 11 Jun 2025 19:16:35 +0200
Message-ID: <20250611171636.5674-8-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250611171636.5674-1-roger.pau@citrix.com>
References: <20250611171636.5674-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Implement the helpers to translate from pfns or physical addresses into the
offset compressed index space.  Add a further check in the PDX testing to
ensure conversion resulting from the added functions is bi-directional.

Signed-off-by: Roger Pau Monné 
---
 tools/tests/pdx/test-pdx-offset.c | 10 +++++++++
 xen/common/pdx.c                  | 10 +++++++++
 xen/include/xen/pdx.h             | 35 +++++++++++++++++++++++++------
 3 files changed, 49 insertions(+), 6 deletions(-)

diff --git a/tools/tests/pdx/test-pdx-offset.c b/tools/tests/pdx/test-pdx-offset.c
index 0a561f02d197..a3507c36deb7 100644
--- a/tools/tests/pdx/test-pdx-offset.c
+++ b/tools/tests/pdx/test-pdx-offset.c
@@ -293,6 +293,16 @@ int main(int argc, char **argv)
                     print_ranges(tests[i].ranges);
                     ret_code = EXIT_FAILURE;
                 }
+
+                if ( start != pdx_to_pfn(pfn_to_pdx(start)) ||
+                     end - 1 != pdx_to_pfn(pfn_to_pdx(end - 1)) )
+                {
+                    printf(
+    "PDX %s compression invalid, conversion of %#lx or %#lx is not bidirectional\n",
+                           use_slow ? "slow" : "fast", start, end - 1);
+                    print_ranges(tests[i].ranges);
+                    ret_code = EXIT_FAILURE;
+                }
             }
         }
     }
diff --git a/xen/common/pdx.c b/xen/common/pdx.c
index f2cf60bbc3f8..feabdcded804 100644
--- a/xen/common/pdx.c
+++ b/xen/common/pdx.c
@@ -46,6 +46,8 @@ bool __mfn_valid(unsigned long mfn)
 
 #ifdef CONFIG_PDX_MASK_COMPRESSION
     invalid |= mfn & pfn_hole_mask;
+#elif defined(CONFIG_PDX_OFFSET_COMPRESSION)
+    invalid |= (mfn % pdx_offset) >= pdx_size;
 #endif
 
     if ( unlikely(evaluate_nospec(invalid)) )
@@ -314,6 +316,9 @@ void __init pfn_pdx_compression_reset(void)
 unsigned long __ro_after_init pdx_offset = ~0UL;
 unsigned long __ro_after_init pdx_size = ~0UL;
 
+paddr_t __ro_after_init pdx_paddr_offset = ~0UL;
+paddr_t __ro_after_init pdx_paddr_size = ~0UL;
+
 static unsigned long __initdata top_pfn;
 
 bool pdx_is_region_compressible(paddr_t base, unsigned long npages)
@@ -513,6 +518,9 @@ bool __init pfn_pdx_compression_setup(paddr_t base)
     printk(XENLOG_INFO "PFN compression using offset %#lx size %#lx (%lu%%)\n",
            pdx_offset, pdx_size, ((pdx_offset - pdx_size) * 100) / pdx_offset);
 
+    pdx_paddr_offset = (paddr_t)pdx_offset << PAGE_SHIFT;
+    pdx_paddr_size = (paddr_t)pdx_size << PAGE_SHIFT;
+
     return true;
 }
 #endif /* __XEN__ */
@@ -520,7 +528,9 @@ bool __init pfn_pdx_compression_setup(paddr_t base)
 void __init pfn_pdx_compression_reset(void)
 {
     pdx_size = ~0UL;
+    pdx_paddr_size = ~(paddr_t)0;
     pdx_offset = ~0UL;
+    pdx_paddr_offset = ~(paddr_t)0;
     nr = 0;
     top_pfn = 0;
 }
diff --git a/xen/include/xen/pdx.h b/xen/include/xen/pdx.h
index 88f446f4ddd9..5f9e5bc7ab62 100644
--- a/xen/include/xen/pdx.h
+++ b/xen/include/xen/pdx.h
@@ -217,14 +217,37 @@ static inline paddr_t directmapoff_to_maddr(unsigned long offset)
 
 extern unsigned long pdx_offset;
 extern unsigned long pdx_size;
+extern paddr_t pdx_paddr_offset;
+extern paddr_t pdx_paddr_size;
 
-/* pdx<->pfn == identity */
-#define pdx_to_pfn(x) (x)
-#define pfn_to_pdx(x) (x)
+void pdx_region_offset(unsigned long base, unsigned long size);
+bool pfn_pdx_offset_setup(void);
 
-/* directmap is indexed by maddr */
-#define maddr_to_directmapoff(x) (x)
-#define directmapoff_to_maddr(x) (x)
+static inline unsigned long pdx_to_pfn(unsigned long pdx)
+{
+    OPTIMIZE_PDX((pdx % pdx_size) + ((pdx / pdx_size) * pdx_offset),
+                 pdx);
+}
+
+static inline unsigned long pfn_to_pdx(unsigned long pfn)
+{
+    OPTIMIZE_PDX((pfn % pdx_offset) + ((pfn / pdx_offset) * pdx_size),
+                 pfn);
+}
+
+static inline unsigned long maddr_to_directmapoff(paddr_t ma)
+{
+    OPTIMIZE_PDX((ma % pdx_paddr_offset) +
+                 ((ma / pdx_paddr_offset) * pdx_paddr_size),
+                 ma);
+}
+
+static inline paddr_t directmapoff_to_maddr(unsigned long off)
+{
+    OPTIMIZE_PDX((off % pdx_paddr_size) +
+                 ((off / pdx_paddr_size) * pdx_paddr_offset),
+                 off);
+}
 
 #endif /* CONFIG_PDX_OFFSET_COMPRESSION */
 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 17:23:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 17:23:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011974.1390542 (Exim 4.92)
	(envelope-from )
	id 1uPPAE-0004BH-80; Wed, 11 Jun 2025 17:23:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011974.1390542; Wed, 11 Jun 2025 17:23:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPPAD-0004AE-Vh; Wed, 11 Jun 2025 17:23:01 +0000
Received: by outflank-mailman (input) for mailman id 1011974;
 Wed, 11 Jun 2025 17:23: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 1uPPAD-0002dK-Cf
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 17:23:01 +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 b986bea8-46e8-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 19:23:00 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3a53359dea5so110481f8f.0
 for ; Wed, 11 Jun 2025 10:23:00 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a532464f20sm15936533f8f.98.2025.06.11.10.22.59
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 11 Jun 2025 10:22:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b986bea8-46e8-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749662580; x=1750267380; darn=lists.xenproject.org;
        h=content-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=zMkLljSK+j8EobhNDyMcdRH/ZodKoaJMWOo2vFrOTRM=;
        b=oZnV1tEqvqKmVyqlm4To2KRWRRy3SPWSTLk9IZVimu38g53McYSeS+Z7pzGW06Y1dL
         dd5kFFuI3AtyDUYunlR0kvRRpcJrV2SrWmI3Rqr0sgK5DqAUuUZx+CWNbhycdCE9kpx7
         mBVtEsSVIWaLHZfztLt9lUbwxaKIqm2TFxIpA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749662580; x=1750267380;
        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=zMkLljSK+j8EobhNDyMcdRH/ZodKoaJMWOo2vFrOTRM=;
        b=N6zuw2n8MiwN5IYtOJCxuucTVFcGoYvA2o+PMbvHcZwSw2U12eSOVreYAMDaF+P/ix
         uadhV3h2/1KTV/tTQrzvUjZtIC5Y/6eOpgXt9irZS5nDoR3brP+B9drvk3O5ex1PiP/m
         KjPyQEvEAV8v0O2rq1KebHpNsY7fI6kTku1DFPe53vwkvP1/OmpXxCe30rgdp8ucuFBw
         O5/sWH5qNvQ2bQ8Pipj0xVWbMfa8BCYJ65dOITMnuKMxosGBF+AqNWhGFYBVPsylHydt
         8Yc0catJkX7tYwdaQz8KAi9ZPu2N1Tnp3eT4dExh6q+eaY8iJwXPjzlGFVQiRaUK3u7g
         TP8A==
X-Gm-Message-State: AOJu0YxQ6RLFKI4pHzsKkatO8GP6UIDnujdnpUnsxdyMqe7lAxqs9vEN
	aHSszo61jIdW3qUhms+xOtiAauw6vXSpEvAzdeLOV5o13ud+We9PmMtZtZ4fQBTA5ZpuqeWiDnn
	JicmY
X-Gm-Gg: ASbGnctDlHeJ2zL0iAC/TRN6FBT1lrnHVh9aIY0kOuYEx+gULYL1IGsvsqscZV2+bfG
	OgX/H1YoeUgZXILqpZai7l4EzOTjfF6mpyCp55XV4AfTAciq/k5pNAQYFU163z9Cg8cHF21fTR1
	xo4BgZffCI82bTxRp6Wa7CAj9vKZ+uIZ0Ms3bDscE57VObCiQNLtndnL4H/rlQWeipqWFVKO0IT
	cM8ZDedqzq7gGpLcZZgaD0Js8BEOKyRPd+G5vaviJVxpvhCu9zQVekKCWr9Np3yA2ocMCCvUab1
	GjRaPosqmTasLIUro5kdJh5l47Jr3rJQ/c+Vc3s8ytuwrBDS9p9yQ364wnxWVah75qdLtaUwInm
	RqD8O10p1y1626Jgrm533o1qYG+tXltr2ka0=
X-Google-Smtp-Source: AGHT+IFmm8Vnv/fFfhO6OHaQrYoRlOpgApD7blxzSW+d/IiH0RcBar5N6eB71msoXWKCHbg6AhxmIA==
X-Received: by 2002:a05:6000:4383:b0:3a4:f6c4:355a with SMTP id ffacd0b85a97d-3a558a534f7mr3477043f8f.57.1749662579917;
        Wed, 11 Jun 2025 10:22:59 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Oleksii Kurochko ,
	Community Manager ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH 8/8] pdx: introduce a command line option for offset compression
Date: Wed, 11 Jun 2025 19:16:36 +0200
Message-ID: <20250611171636.5674-9-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250611171636.5674-1-roger.pau@citrix.com>
References: <20250611171636.5674-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Allow controlling whether to attempt PDX compression, and which algorithm
to use to calculate the coefficients.  Document the option and also add a
CHANGELOG entry for the newly added feature.

Note the work has been originally done to cope with the new Intel
Sapphire/Granite Rapids, however the compression is not explicitly tied to
Intel or x86, and hence could be helpful on other architectures.

Signed-off-by: Roger Pau Monné 
---
 CHANGELOG.md                      |  3 +++
 docs/misc/xen-command-line.pandoc | 22 ++++++++++++++++++
 xen/common/pdx.c                  | 38 +++++++++++++++++++++++++++----
 3 files changed, 59 insertions(+), 4 deletions(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 23215a8cc1e6..48327f03078f 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -20,6 +20,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
      table or foreign memory.
 
 ### Added
+ - Introduce new PDX compression algorithm to cope with Intel Sapphire and
+   Granite Rapids having sparse memory maps.
+
  - On x86:
    - Option to attempt to fixup p2m page-faults on PVH dom0.
    - Resizable BARs is supported for PVH dom0.
diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index b0eadd2c5d58..06819576a06b 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -2072,6 +2072,28 @@ for all of them (`true`), only for those subject to XPTI (`xpti`) or for
 those not subject to XPTI (`no-xpti`). The feature is used only in case
 INVPCID is supported and not disabled via `invpcid=false`.
 
+### pdx-compress
+> `=  | auto | fast | slow`
+
+> Default: `auto`
+
+Only relevant when hypervisor is build with PFN PDX offset compression
+`CONFIG_PDX_OFFSET_COMPRESSION`.
+
+Controls whether Xen will engage in PFN compression, and which algorithm will
+be used to calculate the compression coefficients:
+
+* `auto`: default choice, attempt fast calculation of compression
+  coefficients, if that's not successful fallback to slow calculation.
+
+* `fast`: only attempt fast calculation of coefficients, if it fails PFN PDX
+  compression will be disabled.
+
+* `slow`: only attempt slow calculation of coefficients, if it fails PFN PDX
+  compression will be disabled.
+
+Note `pdx-compress=true` is equivalent to `pdx-compress=auto`.
+
 ### ple_gap
 > `= `
 
diff --git a/xen/common/pdx.c b/xen/common/pdx.c
index feabdcded804..5fd01305a7be 100644
--- a/xen/common/pdx.c
+++ b/xen/common/pdx.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -468,11 +469,40 @@ STATIC void __init pfn_offset_sanitize_ranges(void)
 }
 
 #ifdef __XEN__
+static enum {
+    PDX_AUTO, /* Fast first, fallback to slow if fast is not successful. */
+    PDX_NO,   /* Do not attempt compression. */
+    PDX_FAST, /* Only attempt fast calculation of compression parameters. */
+    PDX_SLOW, /* Only attempt slow calculation of compression parameters. */
+} compress_mode __initdata;
+
+static int __init cf_check parse_pdx_param(const char *arg)
+{
+    int val;
+
+    if ( !arg )
+        return -EINVAL;
+
+    if ( (val = parse_bool(arg, NULL)) != -1 )
+        compress_mode = val ? PDX_AUTO : PDX_NO;
+    else if ( !strcmp(arg, "auto") )
+        compress_mode = PDX_AUTO;
+    else if ( !strcmp(arg, "fast") )
+        compress_mode = PDX_FAST;
+    else if ( !strcmp(arg, "slow") )
+        compress_mode = PDX_SLOW;
+    else
+        return -EINVAL;
+
+    return 0;
+}
+custom_param("pdx-compress", parse_pdx_param);
+
 bool __init pfn_pdx_compression_setup(paddr_t base)
 {
-    bool use_slow = false;
+    bool use_slow = compress_mode == PDX_SLOW;
 
-    if ( nr <= 1 )
+    if ( nr <= 1 || compress_mode == PDX_NO )
         return false;
 
     if ( nr > ARRAY_SIZE(ranges) )
@@ -507,11 +537,11 @@ bool __init pfn_pdx_compression_setup(paddr_t base)
             dprintk(XENLOG_DEBUG,
                     "Find PFN compression coefficients using %s algorithm failed\n",
                     use_slow ? "slow" : "fast");
-            if ( use_slow )
+            if ( compress_mode == PDX_FAST || use_slow )
                 return false;
         }
 
-        if ( use_slow )
+        if ( compress_mode == PDX_FAST || use_slow )
             break;
     }
 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 17:23:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 17:23:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1011975.1390556 (Exim 4.92)
	(envelope-from )
	id 1uPPAH-0004kT-Fh; Wed, 11 Jun 2025 17:23:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1011975.1390556; Wed, 11 Jun 2025 17:23: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 1uPPAH-0004kD-AU; Wed, 11 Jun 2025 17:23:05 +0000
Received: by outflank-mailman (input) for mailman id 1011975;
 Wed, 11 Jun 2025 17:23: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 1uPPAG-0004ea-40
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 17:23:04 +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 b337446f-46e8-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 19:22:50 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a4fea34e07so93159f8f.1
 for ; Wed, 11 Jun 2025 10:22:50 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a5322ae43fsm15685768f8f.25.2025.06.11.10.22.48
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 11 Jun 2025 10:22:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b337446f-46e8-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749662569; x=1750267369; 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=anfQsa7S+yMQpSfHuxEOD+WPNmDFJ5MQMbijHBl0+0s=;
        b=j2+zYRsjD781j8G3GQeEZJweEAsyfXEU7C7ZsSYmJtD51C3CJkarMWktZBIPJPtp8I
         aPOQlQhcDNHn99Q1vCJerkg1QUXpbUoxswn5uRWuH7qST+gBEqLS8AqLNF8uaXi7uSA2
         JT1r5atnbwkFRHGbFje5EZ6g7FP/qnnRWKjqA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749662569; x=1750267369;
        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=anfQsa7S+yMQpSfHuxEOD+WPNmDFJ5MQMbijHBl0+0s=;
        b=b02U97H2bsTafMXrQ6zC1Cn9QfpO6tmNNeqQZYcgVzG940o/Fs8K2wwFlos/XBCfVf
         Sf20Eo50IdLEmfBuw18h9hEaShtyX987FqeYTgmVVlJfMpfPfm9gxXPBXh/LSGqQjd2N
         nFsm3yOiR1C5oxfCA5Lt2PCugpZAJDXu7xsYLn2cEH/xhF3psUkTZ5n12jTV4E9d5PMj
         7q1T18xIsCTj5XlBwET39GsZRF7BQcEtyZSoYnntICUowX3qDSmPr/A2/qs4dl3xXPW5
         M4GWkny5KMnjXA7Uz5MpHUlJW4Ga/KbzBdcwJpqBgiZ896urDATYw5m/CVEbeiSrwOXU
         d8lA==
X-Gm-Message-State: AOJu0YyROOxvM02dLOWeFNGrgKBhAvYUDegG7WZpzmLK9xoHUaNx7Hff
	eYgyVPMppiNLv3aj/SQTjg20j0dYtj+DgvEjcdGDvHEHc689sVofDluT4JL8mmgBdNNoKQtIYzq
	hNqCF
X-Gm-Gg: ASbGnctGlxW92LCb+SiYMRFKHDglCnZ8QioY1YwU/jm1+Szz8diECM0vZI4cQPt+sLp
	bcshmTGq0L+1CCxsWv47x/Q+UiA+pS7KW/Z6WINytPMZCxk1cdumbQhXquN9id7IHy2cwyV8+u4
	nzWX5nmN65cYlUgcTOOihmY6m3mJtDEE2Hs6CdRC6POPegw7kOFp5+4fsy0Auo86P8VuCpH5XtQ
	pi67vC+JIv5FzKYpKMz0v8hHjkITl4aIGmqCYFrWF0FOqXqLN1HGldQaUcs6kYBdWdJQpml9UQn
	PzS6kc4lJg+r8jGLjnf7Lu/fiMOFsNGE7TPdwif8oRgAIu8PHsfgkNypAJ7V/PlD6cDia2RVUlF
	T+IymQRiWw3+wHxFt5DevhKYkotCG66eLuwc=
X-Google-Smtp-Source: AGHT+IGN+fMnV76KlrqchGBkpcg5Z6KymEIXo7HbqL/iYCuu0b1OCDuVUdfNQk1vt7MBMfV1md9AHg==
X-Received: by 2002:a05:6000:2c0f:b0:3a4:ed10:c14 with SMTP id ffacd0b85a97d-3a55869b2b9mr3406097f8f.14.1749662569421;
        Wed, 11 Jun 2025 10:22:49 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	Stefano Stabellini ,
	Bertrand Marquis ,
	Volodymyr Babchuk ,
	Oleksii Kurochko ,
	Community Manager 
Subject: [PATCH 0/8] pdx: introduce a new compression algorithm
Date: Wed, 11 Jun 2025 19:16:28 +0200
Message-ID: <20250611171636.5674-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hello,

This series implements a new PDX compression algorithm to cope with the
spare memory maps found on the Intel Sapphire/Granite Rapids.

Patches 1 to 5 prepare the existing code to make it easier to introduce
a new PDX compression, including generalizing the initialization and
setup functions so they are both usable by the existing and the new
compression.

Patches 6 to 8 introduce the new compression, with patch 6 adding most
of the code.  Such patch also adds a unit test to exercise the logic
easily in user-space.  The new compression is only enabled by default on
x86, other architectures are left with their previous defaults.

Thanks, Roger.

Roger Pau Monne (8):
  x86/pdx: simplify calculation of domain struct allocation boundary
  pdx: introduce function to calculate max PFN based on PDX compression
  kconfig: turn PDX compression into a choice
  pdx: provide a unified set of unit functions
  pdx: allow optimizing PDX conversion helpers
  pdx: introduce a new compression algorithm based on offsets between
    regions
  pdx: introduce translation helpers for offset compression
  pdx: introduce a command line option for offset compression

 CHANGELOG.md                           |   3 +
 docs/misc/xen-command-line.pandoc      |  22 ++
 tools/tests/Makefile                   |   1 +
 tools/tests/pdx/.gitignore             |   3 +
 tools/tests/pdx/Makefile               |  54 ++++
 tools/tests/pdx/harness.h              |  73 +++++
 tools/tests/pdx/test-pdx-offset.c      | 320 +++++++++++++++++++
 xen/arch/arm/setup.c                   |  34 +-
 xen/arch/x86/domain.c                  |  35 +--
 xen/arch/x86/include/asm/cpufeatures.h |   1 +
 xen/arch/x86/setup.c                   |  19 +-
 xen/arch/x86/srat.c                    |  30 +-
 xen/common/Kconfig                     |  25 +-
 xen/common/pdx.c                       | 419 +++++++++++++++++++++++--
 xen/include/xen/pdx.h                  | 216 +++++++++----
 15 files changed, 1092 insertions(+), 163 deletions(-)
 create mode 100644 tools/tests/pdx/.gitignore
 create mode 100644 tools/tests/pdx/Makefile
 create mode 100644 tools/tests/pdx/harness.h
 create mode 100644 tools/tests/pdx/test-pdx-offset.c

-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 17:26:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 17:26:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012006.1390566 (Exim 4.92)
	(envelope-from )
	id 1uPPDI-0007Ij-Uu; Wed, 11 Jun 2025 17:26:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012006.1390566; Wed, 11 Jun 2025 17: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 1uPPDI-0007Ic-Ru; Wed, 11 Jun 2025 17:26:12 +0000
Received: by outflank-mailman (input) for mailman id 1012006;
 Wed, 11 Jun 2025 17:26:10 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uPPDG-0007IU-R2
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 17:26:10 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uPPDF-00DsgD-23;
 Wed, 11 Jun 2025 17:26:09 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (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 1uPPDF-002vgZ-0s;
 Wed, 11 Jun 2025 17:26: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" 
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=TvY8XJCtLseOyo7AdSpTBjkYvZb5kh/DRwYv1c3FU20=; b=yJMZ7x/1fDot2KpB3G2tXo3sff
	oiFLAuCLktUKTGgZJAglj4XPdQvakri6g9cyFhAR7xDsTv1YYsjVFKaBIPB5J7cZdizdS3M1ygz1M
	rdN0uouWA75s3wkRTBGLWkyuW1O8T2KMlzZ1T60T6WEJ73TbThqnmfkot6336jwTDOrc=;
Date: Wed, 11 Jun 2025 19:26:06 +0200
From: Anthony PERARD 
To: Roger Pau Monne 
Cc: xen-devel@lists.xenproject.org,
	Oleksii Kurochko ,
	Community Manager ,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini ,
	Juergen Gross ,
	Anthoine Bourgeois 
Subject: Re: [PATCH v4] x86/hvmloader: select xenpci MMIO BAR UC or WB MTRR
 cache attribute
Message-ID: 
References: <20250610162930.89055-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250610162930.89055-1-roger.pau@citrix.com>

On Tue, Jun 10, 2025 at 06:29:30PM +0200, Roger Pau Monne wrote:
> diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> index c388899306c2..ddbff6fffc16 100644
> --- a/docs/man/xl.cfg.5.pod.in
> +++ b/docs/man/xl.cfg.5.pod.in
> @@ -2351,6 +2351,14 @@ Windows L.
>  Setting B with the default device_model "qemu-xen"
>  requires at least QEMU 1.6.
>  
> +
> +=item B
> +
> +B Select whether the memory BAR of the Xen PCI device should have
> +uncacheable (UC) cache attribute set in MTRR.

For information, here are different name used for this pci device:

- man xl.cfg:
    xen_platform_pci=
        Xen platform PCI device
- QEMU:
    -device xen-platform
    in comments: XEN platform pci device
    with pci device-id PCI_DEVICE_ID_XEN_PLATFORM
- EDK2 / OVMF:
    XenIoPci
        described virtual Xen PCI device
        But XenIo is a generic protocol in EDK2
    Before XenIo, the pci device would be linked to XenBus, and
    loaded with PCI_DEVICE_ID_XEN_PLATFORM
- Linux:
    Seems to be called "xen-platform-pci"

Overall, this PCI device is mostly referenced as the Xen Platform PCI
device. So "xenpci" or "Xen PCI device" is surprising to me, and I'm not
quite sure what it is.


> +
> +Default is B.
> +
>  =item B or B
>  
>  The groups of Microsoft Hyper-V (AKA viridian) compatible enlightenments
> diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
> index cc67b18c0361..cfd39cc37cdc 100644
> --- a/tools/firmware/hvmloader/pci.c
> +++ b/tools/firmware/hvmloader/pci.c
> @@ -116,6 +116,8 @@ void pci_setup(void)
>       * experience the memory relocation bug described below.
>       */
>      bool allow_memory_relocate = 1;
> +    /* Select the MTRR cache attribute of the xenpci device BAR. */
> +    bool xenpci_bar_uc = false;

This default value for `xenpci_bar_uc` mean that hvmloader changes
behavior compared to previous version, right? Shouldn't we instead have
hvmloader keep the same behavior unless the toolstack want to use the
new behavior? (Like it's done for `allow_memory_relocate`,
"platform/mmio_hole_size")

It would just mean that toolstack other than `xl` won't be surprised by
a change of behavior.

>      BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_IO !=
>                   PCI_COMMAND_IO);
> @@ -130,6 +132,12 @@ void pci_setup(void)
>      printf("Relocating guest memory for lowmem MMIO space %s\n",
>             allow_memory_relocate?"enabled":"disabled");
>  
> +    s = xenstore_read(HVM_XS_XENPCI_BAR_UC, NULL);
> +    if ( s )
> +        xenpci_bar_uc = strtoll(s, NULL, 0);
> +    printf("XenPCI device BAR MTRR cache attribute set to %s\n",
> +           xenpci_bar_uc ? "UC" : "WB");
> +
>      s = xenstore_read("platform/mmio_hole_size", NULL);
>      if ( s )
>          mmio_hole_size = strtoll(s, NULL, 0);
> @@ -271,6 +279,44 @@ void pci_setup(void)
>              if ( bar_sz == 0 )
>                  continue;
>  
> +            if ( !xenpci_bar_uc &&
> +                 ((bar_data & PCI_BASE_ADDRESS_SPACE) ==
> +                   PCI_BASE_ADDRESS_SPACE_MEMORY) &&
> +                 vendor_id == 0x5853 &&
> +                 (device_id == 0x0001 || device_id == 0x0002) )

We don't have defines for 0x5853 in the tree (and those device_id)?
Maybe introduce at least one for the vendor_id:

These two names are use by QEMU, OVMF, Linux, for example.

#define PCI_VENDOR_ID_XEN           0x5853
#define PCI_DEVICE_ID_XEN_PLATFORM  0x0001

There's even PCI_DEVICE_ID_XEN_PLATFORM_XS61 in Linux


> diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
> index 79c0e6bd4ad2..31b4411db7b4 100644
> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -867,7 +867,7 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
>          config->table_flags |= ACPI_HAS_HPET;
>  
>      config->pci_start = pci_mem_start;
> -    config->pci_len = pci_mem_end - pci_mem_start;
> +    config->pci_len = RESERVED_MEMBASE - pci_mem_start;
>      if ( pci_hi_mem_end > pci_hi_mem_start )
>      {
>          config->pci_hi_start = pci_hi_mem_start;
> diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_create.c
> index 8bc768b5156c..962fa820faec 100644
> --- a/tools/libs/light/libxl_create.c
> +++ b/tools/libs/light/libxl_create.c
> @@ -313,6 +313,7 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
>          libxl_defbool_setdefault(&b_info->u.hvm.usb,                false);
>          libxl_defbool_setdefault(&b_info->u.hvm.vkb_device,         true);
>          libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci,   true);
> +        libxl_defbool_setdefault(&b_info->u.hvm.xenpci_bar_uc,      true);
>          libxl_defbool_setdefault(&b_info->u.hvm.pirq,               false);
>  
>          libxl_defbool_setdefault(&b_info->u.hvm.spice.enable, false);
> diff --git a/tools/libs/light/libxl_dom.c b/tools/libs/light/libxl_dom.c
> index 4d67b0d28294..60ec0354d19a 100644
> --- a/tools/libs/light/libxl_dom.c
> +++ b/tools/libs/light/libxl_dom.c
> @@ -819,6 +819,15 @@ static int hvm_build_set_xs_values(libxl__gc *gc,
>              goto err;
>      }
>  
> +    if (info->type == LIBXL_DOMAIN_TYPE_HVM &&
> +        libxl_defbool_val(info->u.hvm.xenpci_bar_uc)) {

I think this condition is wrong. You should always write the value of
xenpci_bar_uc into xenstore, or only write it if a value have been
selected. But I guess we already lost the information here about whether
the value is the default or not, and it's probably not important, so I
think you should always write the value.

> +        path = GCSPRINTF("/local/domain/%d/"HVM_XS_XENPCI_BAR_UC, domid);
> +        ret = libxl__xs_printf(gc, XBT_NULL, path, "%d",
> +                               libxl_defbool_val(info->u.hvm.xenpci_bar_uc));
> +        if (ret)
> +            goto err;
> +    }
> +
>      return 0;
>  
>  err:

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 17:27:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 17:27:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012015.1390576 (Exim 4.92)
	(envelope-from )
	id 1uPPEV-0007sG-AA; Wed, 11 Jun 2025 17:27:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012015.1390576; Wed, 11 Jun 2025 17:27:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPPEV-0007s9-78; Wed, 11 Jun 2025 17:27:27 +0000
Received: by outflank-mailman (input) for mailman id 1012015;
 Wed, 11 Jun 2025 17: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 1uPPEU-0007s3-0C
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 17:27:26 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20615.outbound.protection.outlook.com
 [2a01:111:f403:2412::615])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5536e2a2-46e9-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 19:27:23 +0200 (CEST)
Received: from MW4PR04CA0123.namprd04.prod.outlook.com (2603:10b6:303:84::8)
 by PH7PR12MB8054.namprd12.prod.outlook.com (2603:10b6:510:27f::15) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.40; Wed, 11 Jun
 2025 17:27:17 +0000
Received: from SJ1PEPF00001CEB.namprd03.prod.outlook.com
 (2603:10b6:303:84:cafe::1) by MW4PR04CA0123.outlook.office365.com
 (2603:10b6:303:84::8) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.35 via Frontend Transport; Wed,
 11 Jun 2025 17:27:16 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ1PEPF00001CEB.mail.protection.outlook.com (10.167.242.27) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Wed, 11 Jun 2025 17:27: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; Wed, 11 Jun
 2025 12:27:16 -0500
Received: from [172.27.195.250] (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 Jun 2025 12:27:15 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5536e2a2-46e9-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Q02sexjmPiKE2cBeBXTByrMMhmf4hcvV7OxyH/FX57Xu+zg3T3DUz44ExsDS5vyBbTPTx3ASbAzMLEKrY9rBAfzvDiiEee/L5HxnOIlJET/ioseX3d2GvNrnfL8Hj5ptpIwjIpzchq80CM+FsVp9BVpoBJo3aD1w1xzn2JV73kCRSf7nEwHBFD+XaXcHowp5mjs4OHN9idIO+YOmC0/iMUl7wdFi9895mSre/AKtBUfu2sZwD8m8z+3qKGJr1xkuTb1qyYLEvxZ94qKkKbT7q69IATHK9zTDbh1tqBi8ZKsvWbDEar5I4CbTjLlzSuBzZE5lu3fj7DHi+s8slOyouA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Zt1ezhVNOiPDAuhq6Fd8EDVtLvjnuzgEI1XEGDcz4T4=;
 b=f4QsVQUAtpDWG7MNrz1wHjk7BaC99dYYiwt8qMSk3PFkpH+Ml+uFHjMSyN2f4/+/i9uFelmb7A7QyykbZfIBD+lEI9s7umSz3aW8VwdKmGlDuO3DI4z4UPROJgsYl3ypCBdSjyMMzwbkebkYzSHG+YUzWt4uRT2JNyuLpq4KPR9mdHzGONGvoPBdpy6Eq444UgFd9s0snhFAs7+73+P4Ep9CrV8J+hE3nf04jSy40leNhRKHXcTuvXPWF4UhWP0/8zqn0fpGek3/9K0OzeprXQkD/wyfOT4923Olhp/BpG4D4yPpdG1Z5EIYrvaPwLxhojK0d4SLE5KEsIrXUKWcvw==
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=Zt1ezhVNOiPDAuhq6Fd8EDVtLvjnuzgEI1XEGDcz4T4=;
 b=NQgDzVFME08vuScoUV5l6owQB6CNSZMpstzaHq0jNC/fuVKpInqVwbVLb3XMWFbZ6BsI9JLA8bsjgh54HNbj8PKmYNCsFoH7cbgx/GOccfQFBGbJQD6Qt9axd8wRtatQU2ekjci/JeTnky/FNUZeLJRzGyXQCBJ+VcOOXZ+tj70=
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, 11 Jun 2025 00:48:24 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 4/4] xsm/dummy: Allow hwdom SYSCTL_readconsole/physinfo
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" , 
References: <20250610225737.469690-1-jason.andryuk@amd.com>
 <20250610225737.469690-5-jason.andryuk@amd.com>
 <5f6d43da-2600-4c1c-9bcb-f13e8fce921e@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <5f6d43da-2600-4c1c-9bcb-f13e8fce921e@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: SJ1PEPF00001CEB:EE_|PH7PR12MB8054:EE_
X-MS-Office365-Filtering-Correlation-Id: 2d695dbc-05f0-4ca0-77bd-08dda90d366a
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?YUk1UXJmNUlFSG15TlBGcnZDdVRrWlQrYjZZNzBGdEdYcFFqREdhblE3TG9F?=
 =?utf-8?B?KzZYVkNwZFpBWVRlU25vdmVPdUJvUk9qOTdzY0toTENqTVpVQjlybVVUeGI2?=
 =?utf-8?B?WUQxNUxLVGc4SUdmU2tpNDZ4ZVdvRFU4anQxdW9UVVVLcTBtMmdVWHlZSzZx?=
 =?utf-8?B?U2R6a2EvUU1KWHNKQldTdU8yRDJJUjR5bmxrc0l5WVRFQTB6eFRXU3hoQjdP?=
 =?utf-8?B?Q2Q5VTI5ZkZmbEQ0R1JDbWJ6SzRkSGtlc2pNMk9tZXkvQ2FwOGg5SkhGMWhN?=
 =?utf-8?B?VjcyT3ZueTBGOFlCbTJLVlhnRXVoMytpRFR2RHhhN3Fhc0NxZWs3TFFTK3hp?=
 =?utf-8?B?dnNCQWUwVm00Mi93Skl6TUY2MC9RTGZtTzZ0ZUpkVVpvS1JPKzRHcFFsd1kr?=
 =?utf-8?B?NzhrVWNORWxoOXFFQU9lbUVOMG5oSmdmUENRTE5aT2dFNStmOVA0b2pOQ2hu?=
 =?utf-8?B?dTFrZ21nd2dUMlZwbU0xYzNHWlJhWXFlek5ENHF5R2RLTVMwSW1OSi9CZ29r?=
 =?utf-8?B?a3JIZTl1Q1p3WWloYzRLY2NYd1N3bklhQ2xIa0Z3L1NVUkhITnJGMmNmRGYy?=
 =?utf-8?B?Nk8xRHBzbzlBc0h4S3B2VVNjOE1Pc2U4REtyWllrY2pzb1dkRTZScHRlc0N0?=
 =?utf-8?B?RWtMdWZDY2NXTWV3OG1MRWpDbG85bTh2dHlzQXZ5MUZXK211Y0NESlkvWkhS?=
 =?utf-8?B?SlNBbE9nSytVTFNPdVlLcXpBRVFZK1JDek80NEJESjk2U1hzWStvZUF3ak1C?=
 =?utf-8?B?czlPM2IxNVAybHdYWmZqNTROQzlDNWg0YkE5Umo2OHJLZkplNVViQjBscGlx?=
 =?utf-8?B?RGhzZnp5c0ZKUzBOOE9iN2w4V3Fhb2ppMXM5U0NOYTArK3UrVllOd24vNys5?=
 =?utf-8?B?QnMvOW81RlAxUGpHWHNybFBYWTkwRkp0WmYxQ01qUGxQSTVldWpDWkJoa1Q5?=
 =?utf-8?B?Y2kzMks3QWxxbFpEQnRiSHRvRGRTMGwvZGZucTJNOU8zWUluOWJ4TTlISnZp?=
 =?utf-8?B?cklTa1JoNCtiQUtJZmRHMnh3bS9CSS9CcitkK3VPYW1xbWVMV250MStiTUo4?=
 =?utf-8?B?bVhUb1kvNnRsQmlqb0xGSmNqL0V1MDNTNjMyM0dGcGkyUG1tSUJQNmM3OE9u?=
 =?utf-8?B?OEdRSWhpb2VLWVBXWnJ2OGJzaWg3azdmbTNBQXoyd1N5ZWRWY3dscHNnMldm?=
 =?utf-8?B?RFhCYnJEbGFGUWZrOWVmU1NDMW83SVZPRVI3STJ1eWFtamx0dEwzemp5WmJq?=
 =?utf-8?B?QmF3L0w5Nyt0aUtzY1N1L3Jsd0FZUXF6YVBvUWk3bklMVWM3NTI3TVZEUDZw?=
 =?utf-8?B?R3BHTjdIZWhFWUlybnYxSDUvcm1JVnRIUC92VkFxQXYyZm5hcWc2VHRuRzNH?=
 =?utf-8?B?Y1pGOHA5My9UaFoxbXU0ekROV3h1OUJxNW0wQlJOSWY4aXdOSlBnTXFkVjNN?=
 =?utf-8?B?UUpMRE9qb1NVN2lmM2FlbFVyOWV2NUtMMUlWdmZadmlEeUlVSUtzeTZOTnJr?=
 =?utf-8?B?c01oRXFlNE9qRFc2TVZ0eUxyOTU3UEhXRDVDLzVQbXF2T09kMHFKRnVrU0JV?=
 =?utf-8?B?ZXhub09rYU80VVhkTms1VG5sWXZVdUhkdThuOHVXTkwzam9xMVltRnZ6c1Mx?=
 =?utf-8?B?VUV6cE5VaFVBQ2pKTUJxZlU0a0treTFjZDJkYjdFRGRnSytZTmlETW5BYk12?=
 =?utf-8?B?OEhzVU5laTdwYUQyNEYva3Q2L3pOWExvV08rN1FtcnRVdnUzM0Rac1FuRDhr?=
 =?utf-8?B?Y3NhenFYazNGRmJoUjdFRjFKclo4djBzZGpyaVczeDR3Wm9zU2htc2NOaGZ5?=
 =?utf-8?B?dU5ISnhWazdCT0NFQXM0L3BHWkN3S2VtbkZua2JaUWZnQVZjMU1UK09YbGpF?=
 =?utf-8?B?OGpKcUp1ak9reHpTYnJpTTBVdTRlLzRJWlpHOEZCYmVIWDVSSERaNXNydEdw?=
 =?utf-8?B?THBmMzZqcUtYT3lRcUlEMWh6aUtiM0ZnVHhHREhDUjhJSVd2TlA3Mm1KbHZv?=
 =?utf-8?B?S2RDSklhVzIrT3VGcnVWTFZ3VlJ4aExNYzByanUxd0oxeDROOXNzSXZjdHI1?=
 =?utf-8?Q?bqxTlu?=
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)(82310400026)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jun 2025 17:27:16.7813
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 2d695dbc-05f0-4ca0-77bd-08dda90d366a
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:
	SJ1PEPF00001CEB.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB8054

On 2025-06-11 09:27, Jan Beulich wrote:
> On 11.06.2025 00:57, Jason Andryuk wrote:
>> Allow the hwdom to access the console, and to access physical
>> information about the system.
>>
>> xenconsoled can read Xen's dmesg.  If it's in hwdom, then that
>> permission would be required.
> 
> Why would xenconsoled run in the hardware domain? It's purely a software
> construct, isn't it? As a daemon, putting it in the control domain may
> make sense. Otherwise it probably ought to go in a service domain.

My approach has been to transform dom0 into the hardware domain and add 
a new control domain.  xenconsoled was left running in the hardware domain.

I suppose it could move.  Maybe that would be fine?  I haven't tried. 
The Hyperlaunch code populates the console grants to point at the 
hardware domain, and I just followed that.

One aspect of why I left most things running in the Hardware domain was 
to not run things in the Control domain.  If Control is the highest 
privileged entity, we'd rather run software in lower privileged places. 
Especially something like xenconsoled which is receiving data from the 
domUs.

Running in a service domain is a good suggestion, but we haven't made it 
that far.

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 17:47:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 17:47:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012043.1390586 (Exim 4.92)
	(envelope-from )
	id 1uPPXw-0002rF-Tx; Wed, 11 Jun 2025 17:47:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012043.1390586; Wed, 11 Jun 2025 17: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 1uPPXw-0002r8-QN; Wed, 11 Jun 2025 17:47:32 +0000
Received: by outflank-mailman (input) for mailman id 1012043;
 Wed, 11 Jun 2025 17:47: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 1uPPXv-0002r2-9E
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 17:47:31 +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 1b8700ec-46ec-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 19:47:14 +0200 (CEST)
Received: from DS7PR03CA0094.namprd03.prod.outlook.com (2603:10b6:5:3b7::9) by
 IA0PPF95ABFC125.namprd12.prod.outlook.com (2603:10b6:20f:fc04::bdb)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8678.31; Wed, 11 Jun
 2025 17:47:09 +0000
Received: from CH3PEPF00000018.namprd21.prod.outlook.com
 (2603:10b6:5:3b7:cafe::21) by DS7PR03CA0094.outlook.office365.com
 (2603:10b6:5:3b7::9) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.21 via Frontend Transport; Wed,
 11 Jun 2025 17:47:09 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CH3PEPF00000018.mail.protection.outlook.com (10.167.244.123) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.2 via Frontend Transport; Wed, 11 Jun 2025 17:47:08 +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; Wed, 11 Jun
 2025 12:47:07 -0500
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, 11 Jun
 2025 12:47:07 -0500
Received: from [172.27.195.250] (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, 11 Jun 2025 12:47:06 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1b8700ec-46ec-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=gWhkfNJHlY2wm+bvjR6U0NIZXPYINTwj5/c8YpPy9Wz4XzpdYMjlqTAuQWj1PucIWMfEFT6EiUgI5itGF7VyrpQZ/NmtBNQcdfUT4ha4QHIOUNDm0oBhkGB9/dQoR9XQTQl9k0tjJ9j3w73vLkEYxY3NOqqS/+VIf641vHeIp1y8j7VVqU5xGkwBRcys+O33E0PETP8Xyk5QKY+TXUDT6Lq2pqJLCLYkfMYILuNyrar3QE2P1RTSezhwQHuTXs+tFDqzy+/pJGN3ofiDHk3i7W3Zj19kQBPhFcAc8ERMNOs1k1uGSirXMiOpjjjurmUfCH7KXA6VrxRzXuvDLF1jtw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=+hyWWQPC6eAmVxESsZ5Fjyitqm8UWy7uYu+kgaAlnGc=;
 b=jtYtIIZ+MAs/tJVVSxKuUk5/v5tf/ytM6Nv1FJGWvHh+ULyN57+n6uxiPpyR1C/QZKBTAAYoc0unABtmr2rol1zBDJf6RPB1ChCM9nN8mdUthy2a90+zbtrFv31SFRdhbOiowFniKLBFSEztIVqQGkEnfLcdyhfCYV0k3RPGPftHwlSAQU0AOy+aItdNkTPOnpQQ8aqdzyF3b7tro14MW5OcMBviJ7byr4ioiUqZfJjLQOeT4JoiGxBV8UeiminbT/mgQ8iubl3krsTqZk9cTQK61bh3lU8aIUngmbTMQ54Vz/akXOyqPlM42DdlSb4dtIsozzEGSfCHFtnpHTZ/ng==
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=+hyWWQPC6eAmVxESsZ5Fjyitqm8UWy7uYu+kgaAlnGc=;
 b=HHNDduHww0mK7MZRJAVXn1+cnxj/OsKUBnEn9ZIOMnpmwQ8NlNbh6ng+BDmQUNLT00mJe4tdP0mBXuiUNhOW/jBeY1O0pxqbBJVyJfbEBApD9J+mOyD8s3SyvAoOmhZvatSrIxuLbSJxDmznIvRhpnRYgj4bm5S3es6UuLtzJco=
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: <4b0b7554-e22f-4ef2-9236-bcc2079842d2@amd.com>
Date: Wed, 11 Jun 2025 01:08:10 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/4] XSM changes for split hardware / control domain
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?=
	, "Daniel P. Smith" ,
	Christian Lindig , David Scott
	, 
References: <20250610225737.469690-1-jason.andryuk@amd.com>
 <0defc4e7-382b-4651-8255-652da17a2129@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <0defc4e7-382b-4651-8255-652da17a2129@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: CH3PEPF00000018:EE_|IA0PPF95ABFC125:EE_
X-MS-Office365-Filtering-Correlation-Id: 6829eb76-e937-4d77-010f-08dda90ffcfa
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|7416014|36860700013|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?ZnY1VGJtNXBzM2xadEszY3hCUnViNXd2T0JkcTA0WnpCQ3RQaUM2VC8zdWcy?=
 =?utf-8?B?QjNocHpsUk44K0FrWnFkc2o1dlNGNFpkYlVBRXczTlZuSjJkRmhqUjEvZWhs?=
 =?utf-8?B?R1p3VXFWS0JqODZSaFAvUWN4dktFWThCZWZkZWxudW1CLzhVd1lGUVJsdVh1?=
 =?utf-8?B?NlNHRFIvNDhlQXpnMDdkU00xUFIzQ245NktCblVLZVBoOHVJaGtZMG9UaGNP?=
 =?utf-8?B?THhNK1NpaHloQmRteFd5aWg0dEVJYjlIYUxGMDhmMDByem5mNGsyTlZCclFS?=
 =?utf-8?B?UVErZ3VHSTI4Slp0WURvQVpmbStnRW9vbnh2L2drK3MwZEk3Wm9hYVRqMUh4?=
 =?utf-8?B?YWpSdzJrSjc4cXV6R2ZtaXBVejBBc0NmL25oMDJJTTN3ODNNYld4SVhNMThG?=
 =?utf-8?B?YTZBaGEwMUlzaFFaZWVva2hNdTRrN1UvYXFheFJCSE44NkQwSEdXaERtSHkv?=
 =?utf-8?B?NzI4TmtaRVhCWGtFbzBaUmZLbnFVYUZYWWJXcTAya3RmaS9sL0pOb1FsT2Ro?=
 =?utf-8?B?ZW1kTXZhL2pNZHFsMkRMWFhFa29ERDZCSUdYZUI5bzRMd0RUdm9ORUhNcG9H?=
 =?utf-8?B?blVaM1ZDbzY3L3VtR2p1bFpseHVCTVcxQi9GYks5Qkx1ay8rdm9tbVVNZDJ3?=
 =?utf-8?B?SzQ0eFpHYU9CbGwybVE1eFYrb0dLQmgvMG1IM3AwSlNMZ3pUY3dTYW0zbHFx?=
 =?utf-8?B?c2VMSTZHanlCSHY0OTlKNytVUTVWbUJ5NE95NFBUc0Fpb0dpa0VhMk5nWnlu?=
 =?utf-8?B?b1BCUHIyM1V5YWwvcjMweW01NFNWSFI0QXpWall2ZnYwZGR6TmUveHMxT00z?=
 =?utf-8?B?MTJVSHpxTFg4SE1UKzFCVS9YUytvWFZCaDcxQWVJYk5XVGVpR1NmSDJWc2gr?=
 =?utf-8?B?T0xTUE9hUk9qNnVLSVUzLys4Z3VtQWk3R09CYjY1bW5tamthakZHMVU0QWpR?=
 =?utf-8?B?dmE5VW9pN1RMZEZqYjJMSHhVVE5scmlKbU9aSThEcGpCME9FZG9GOUU4dXdG?=
 =?utf-8?B?VEYyRWFZWEtvbnQzbEdiTU9EWGlxZ3NQZ2xBL0JpdHVVSGVYZmFHMWxGemxO?=
 =?utf-8?B?MU01RVNJd0ZmOXJ3elN1M1V6ZUxya3dkY0xCUnBpbmw3R1A0ZkVQMWJXa3Qx?=
 =?utf-8?B?T1c3azhVZHlzLzRsWTRLQXdzMmVPVlVzbkZpSmFCUVlEclc5eURCamtsL0k3?=
 =?utf-8?B?a3lSREJEcWUyb1UvdmpIazFDc3A0aEJkUGp0YjZncmFpdldFZmZ4eTgyY2tQ?=
 =?utf-8?B?ckdTQjlXWlJPVlZFU2dyU0NIQnpPM2laSjltU3B3S0JsWEJaNU9wc0ZHbEpm?=
 =?utf-8?B?WVdMWkhaT0pydmlIRUhYMEQ2bUljT2lRRHJFeEpCREhOaHl2MkdWd1hsOHVO?=
 =?utf-8?B?MmNJSHFwZkdWV1RMZUVwMmFJZytMUGRiZkFaZEJPK3pQRW1pV1VZaE9xb01q?=
 =?utf-8?B?NEJxMDRtZ2dWeEhoMTdyN2t1bkFPcUJScENUWUZiaEwyaXF1d2MrR245OGtu?=
 =?utf-8?B?ZUVPOE1oRGxDL0xQR25pRTFiR3hUS1p0Zm95T0FONFBldDM1bDZOV0ZXNXgv?=
 =?utf-8?B?REFJais4OVh4dDloZ0t2bDEwSk4wZnU2dHpGZDVRdXd1eUU1NlBBRDEwNjRN?=
 =?utf-8?B?UkRrZHBtSW9mTVc0YXpCMFR2SmFNWFcvc2ZvbVBCdVpnVVlqTnFlaSsvemM5?=
 =?utf-8?B?UW9RNXZsM0RXTFBOSDBXSmMxYkdNcEF6ejNZSnJUZVR2c1VCR3RnRTgvUEZC?=
 =?utf-8?B?bFBISjdtUjBqTFFWTkpKOEV0ci9TMWJSaThzcjZWVGRnYzNiMkl5Z2dHZUJX?=
 =?utf-8?B?M3JodGxzNkQ0NW5VZ3dwZ3V6OEx2TVU5Y3doSHJmcEx0TzhyRkROaFVzeUkr?=
 =?utf-8?B?M3VmZVo1NEJnREtTSXAzYmppOGNGK2E1QkwyZE1LV1ltZThzT1VpaVJvS3Jj?=
 =?utf-8?B?Nkg4Nlc5YlRCaVFJaGxoMVI2eEtIZGN3cHRrY2I5S3Vkay9obDJmZDYwREtB?=
 =?utf-8?B?UFUrQzFjWk9NUTNKNXZYUmdqL1Bmamh4b3plL01JUWJyQURTR2dQSVpySUY4?=
 =?utf-8?Q?67+G+T?=
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)(82310400026)(7416014)(36860700013)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jun 2025 17:47:08.9767
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 6829eb76-e937-4d77-010f-08dda90ffcfa
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:
	CH3PEPF00000018.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PPF95ABFC125

On 2025-06-11 09:28, Jan Beulich wrote:
> On 11.06.2025 00:57, Jason Andryuk wrote:
>> Theses are the broad changes needed for a split hardware / control
>> domain.
>>
>> An earlier posting gave device_model privileges to hardware domain.  For
>> this posting, it was split out into a new capability.  This way the
>> operator can choose where to run the device models without making the
>> hardware domain have the permissions.
>>
>> The first patch add XSM_HW_PRIV for the hardware hypercalls.  Unlike the
>> first posting, the control domain can call these hypercalls even though
>> it doesn't really make sense.  The idea was to keep the control domain
>> all powerful from an XSM perspective.
>>
>> SILO is changed to allow control, hardwware or xenstore to service
>> domUs.  Xenstore and hardware will use grants for PV interfaces.
>> Control wouldn't typically provide PV interfaces to domUs, but it is
>> given the permision to do so.  Again, to keep control all powerful.
>>
>> xsm/dummy: Allow hwdom SYSCTL_readconsole/physinfo this is not strictly
>> needed.  xenconsoled could read Xen's dmesg.  If it's in hwdom, then
>> that permission would be required.  SYSCTL_physinfo is mainly to silence
>> xl messages, which are mostly cosmetic.
>>
>> Jason Andryuk (4):
>>    xen/xsm: Add XSM_HW_PRIV
>>    xsm/silo: Support hwdom/control domains
>>    xen: Add DOMAIN_CAPS_DEVICE_MODEL & XEN_DOMCTL_CDF_device_model
>>    xsm/dummy: Allow hwdom SYSCTL_readconsole/physinfo
> 
> Overall I can't help the impression that this level of disaggregation simply
> requires the use of Flask.

I have thought about that.  The problem with Flask is the complexity of 
the security server.  We don't want to have to deal with all that code. 
A fixed policy is easier for our coverage testing.

Exposing separate control, hardware and xenstore capabilities, it makes 
sense for the default policy to function with them.  This would be a 
coarse level of functionality, and Flask would remain for fine-grain and 
MAC enforcement.

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 17:51:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 17:51:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012050.1390595 (Exim 4.92)
	(envelope-from )
	id 1uPPbc-0004b9-D1; Wed, 11 Jun 2025 17:51:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012050.1390595; Wed, 11 Jun 2025 17:51:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPPbc-0004b2-AC; Wed, 11 Jun 2025 17:51:20 +0000
Received: by outflank-mailman (input) for mailman id 1012050;
 Wed, 11 Jun 2025 17:51: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 1uPPba-0004au-MH
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 17:51:18 +0000
Received: from NAM02-SN1-obe.outbound.protection.outlook.com
 (mail-sn1nam02on2062c.outbound.protection.outlook.com
 [2a01:111:f403:2406::62c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id aba2976b-46ec-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 19:51:16 +0200 (CEST)
Received: from CH5PR05CA0003.namprd05.prod.outlook.com (2603:10b6:610:1f0::16)
 by CH3PR12MB8233.namprd12.prod.outlook.com (2603:10b6:610:129::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8813.31; Wed, 11 Jun
 2025 17:51:12 +0000
Received: from CH3PEPF00000018.namprd21.prod.outlook.com
 (2603:10b6:610:1f0:cafe::77) by CH5PR05CA0003.outlook.office365.com
 (2603:10b6:610:1f0::16) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.18 via Frontend Transport; Wed,
 11 Jun 2025 17:51:12 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CH3PEPF00000018.mail.protection.outlook.com (10.167.244.123) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.2 via Frontend Transport; Wed, 11 Jun 2025 17:51:11 +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 Jun
 2025 12:51:10 -0500
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; Wed, 11 Jun 2025 12:51:09 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: aba2976b-46ec-11f0-a307-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lS9+tL6o5AM6Bgm8ZOld/wkJKAa1hdLqURA3Dkdo9fZ/T0KCPIMbniMgtpNlgmEDNqNHSi7UdOkbn1W4gz/BAIi2lJN6awRo0Gj5HGzxino9GtOGaIEGNs0KfVuPrFiX7h+Rnmtl1fBAcTRUn+s+HmOvb4uai3PUCHPtLXrzKsGhss3XuYq+GFekjISLakotg7ODn9EaMzmHudpeJCNcKLXMC4wovxWne+YTBv2+eRi+xDBztB7tPcaIGJsKkoPBVWh3j9eABA37bKSNu7vLQx5VhMVVmw1PRXXAo4jFGVjx4jdmArMqunRE1rS/ryHzkiV4FZSdGxLw6sPCRbBw7Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=mwZGykq6VxPHFaXBhi0sOypRkWWF/eMi3Eh2+ERV1zI=;
 b=R4s2ATpXzrHCBBWq/x3mBiTzE6TB0Nld5lepMAzSUKTprEZ1Tt2AV4PRvoEDJHYMe/qlxNGWRV/5PEq0LNcI33Xb5sgHMkgmRpMI/JNCNRxvzmu2+m4JWg8Zaerm2zHJWdSbceTy1O/0KuZ+EQQ//Zf7df+s+YK2jSbA/QEUiBaTZs+MYRXCe9ZGDkEvtUaXbSmqaNg28mIJoycsJEw80NocNz6vw0q/bVmtxMYIIJJbEW4LaoJWjciVyp8Dc7Z8l+syE55U6xCMNMRXJ06US50IyISKJpDcvZKeoJT1qfbj7DEFVn1F/iU2+L3C5vpv4i8WBk0kpaY71KxvVQUieg==
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=mwZGykq6VxPHFaXBhi0sOypRkWWF/eMi3Eh2+ERV1zI=;
 b=K2t+FwA+zqfpiUAvp93nLd3EEz+TVn8T/XUnRMEn/kpz6bCXp+f0nUFO6ij/OUBFJMaNB5VPNSQJL2kOrTsR+FECZeQWo+L0Wt4b2f6buFROwpsqYCPKX/rJxvOQFq/kO0yncoYbL+d99mSWgtGUeyW0DQkJBLRZj8oL4LnaRp8=
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 , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , Anthony PERARD
	, Juergen Gross 
Subject: [PATCH v5 0/2] arm: extended regions fixes
Date: Wed, 11 Jun 2025 13:51:02 -0400
Message-ID: <20250611175106.269829-1-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.49.0
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: CH3PEPF00000018:EE_|CH3PR12MB8233:EE_
X-MS-Office365-Filtering-Correlation-Id: 42ffa8dc-3b45-4d20-7827-08dda9108d4d
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?3U4al701o4hms/Ks1TGe5ddnMWvtFBAzsSNkXoLrYHmAjgZt5cdA4SHCx3WH?=
 =?us-ascii?Q?4OTpO2xEIJQP3GZpAeAh9xiDbW92sM4fD2K/oJ8QnjhApa8yzJ6EXo9XupSb?=
 =?us-ascii?Q?v1GUhgXf8w8RazouX3IORNjJAqYUakPzZBrJ85sznKrfFw8kR3K4E07qOGxa?=
 =?us-ascii?Q?SoVXbjeKict3Py9gZjmoNrqvnemfS1D6Dg/qX4RZAjLob4g6L+t+a7dDO6lt?=
 =?us-ascii?Q?urmTOvy+VQ6ACV0oJS+gxJGZ7qFkhw9QDG4oZZB8FD1ylIewVkWluG10VbpX?=
 =?us-ascii?Q?yU43KC1cHbQNYSUMroEZkK4uVOiQNW0DMONFDkPkG5XcsFG+xudvknUy1D5N?=
 =?us-ascii?Q?XECenL9liJvBMEFL2uU5LW4mfYz8zewPGcit3NGgIZHWA8v9kyiFGnj8NZbU?=
 =?us-ascii?Q?2SBLIEuCXI4TBVhxqu+W9NDvndle6oqCqkuPnGcUWpPdGH37SY/Rv2fjtAgU?=
 =?us-ascii?Q?2mW73JuJf678S8TVAnR6tfC7ExpKTPiWlksoScsUYaggOvPb5xnepwgnjYTO?=
 =?us-ascii?Q?PAbkd/sxXpBD472ffxzqnLEYf/xHQHB3RlZZC3/ufMxuQGCS5mOGQYCEot26?=
 =?us-ascii?Q?VXySaDT2PxzyDPHiupDS85F3hgLhWjE4CUPLXhS+JiZ2ifYj3gco2TlIe3HJ?=
 =?us-ascii?Q?wqPDFyaLP725LXPJPKllVRF75WlqB9hMXdECggU81eGcOBInfXIUmIwNicUD?=
 =?us-ascii?Q?M8nu34KM/jsxlO1LXjsK6BykZEtyvJZldyOG0IRFVzablujxN+pjNXSMWZ09?=
 =?us-ascii?Q?IJ0dJx+vN3sgkAoVrPi7ZtgVbAvdKRabuvqMIfKTk15TpDP2+aRX+WT64VgU?=
 =?us-ascii?Q?WRKopXePmj/6Jfwtip5huwsfTBG8cTEUZGORmx8JIwcApt2wqZ9Ju05v7vXS?=
 =?us-ascii?Q?bXM6U0xNj/4deQqIY1MtqkAuZ2XXS8calWbU/24+YqNacEThU9mu/3qpSJtp?=
 =?us-ascii?Q?o+h4SMQyNM4iRawpdml8Y2rZSr+zUO+QAM8JtGPlm1JE0A+5Z1ccbaBhDZSK?=
 =?us-ascii?Q?b08DARL1dn+UPE9i599VTHwNXsrhLVomIRBFth4DFGv6ntf6vL5wf2y7On/r?=
 =?us-ascii?Q?cokRbY4VnFXBWKtryrfJ5/D4AkNwmSqWkFZ0Ph0bnPthQjAMf03L8J1PY2Oh?=
 =?us-ascii?Q?Lsa/I9VolDJ08IPToXGiFU+p3NfB5qla6WJHA4tMBz6OIReYzoDollbUP7Ev?=
 =?us-ascii?Q?uuoRZQuBxokiZ0TQJKlvfaMeJgEjn91DnbNKssFN32DDEj/73w/Z8OYNgZM1?=
 =?us-ascii?Q?njDgo5jaiqUknjVVm4M8jVnQ1GjfQ0UbDjU9EHxVDjV6ELDIA30Xu1gaIVGP?=
 =?us-ascii?Q?/vPr4ilsvc3V37VISMsEv+LuKDIFqLW6QNPEd4xvW1MNKK7Xfgw4opessjOP?=
 =?us-ascii?Q?wJrUBw9dwQ21OoEvr/GaaXSIYoSGS9JyumGA1AXSaaNsM/lbYAXBRlCiqGht?=
 =?us-ascii?Q?OTfTBoDSE94ij7aQwaqNDpxxtlE7uAL5G9+wj41EW6gra14+N1CoI7bv3Rje?=
 =?us-ascii?Q?zQDNoojX2YwxvL+6Rt2ysJ5ohVAZBQLlDqDE?=
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);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jun 2025 17:51:11.1165
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 42ffa8dc-3b45-4d20-7827-08dda9108d4d
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:
	CH3PEPF00000018.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8233

v4->v5:
* see individual patches

v3->v4:
* see individual patches

v2->v3:
* drop committed patches
* add ("xen/arm: exclude xen,reg from direct-map domU extended regions")

v1->v2:
* rebase
* address feedback

Stewart Hildebrand (2):
  xen/arm: exclude xen,reg from direct-map domU extended regions
  tools/arm: exclude iomem from domU extended regions

 tools/libs/light/libxl_arm.c          | 110 +++++++++++++++++++++-----
 xen/arch/arm/domain_build.c           |  80 +++++++++++++++++--
 xen/common/device-tree/domain-build.c |   5 ++
 3 files changed, 171 insertions(+), 24 deletions(-)


base-commit: 657a95a2baed48dc2ed6f2fc7ef6161ad7ba010b
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 17:51:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 17:51:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012051.1390606 (Exim 4.92)
	(envelope-from )
	id 1uPPbi-0004uc-Qa; Wed, 11 Jun 2025 17:51:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012051.1390606; Wed, 11 Jun 2025 17: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 1uPPbi-0004uT-Nr; Wed, 11 Jun 2025 17:51:26 +0000
Received: by outflank-mailman (input) for mailman id 1012051;
 Wed, 11 Jun 2025 17:51: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 1uPPbg-0004au-TJ
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 17:51:24 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20628.outbound.protection.outlook.com
 [2a01:111:f403:2418::628])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b02e8e19-46ec-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 19:51:24 +0200 (CEST)
Received: from CH2PR18CA0056.namprd18.prod.outlook.com (2603:10b6:610:55::36)
 by DS7PR12MB5742.namprd12.prod.outlook.com (2603:10b6:8:71::16) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.18; Wed, 11 Jun
 2025 17:51:18 +0000
Received: from CH3PEPF0000000F.namprd04.prod.outlook.com
 (2603:10b6:610:55:cafe::fd) by CH2PR18CA0056.outlook.office365.com
 (2603:10b6:610:55::36) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.21 via Frontend Transport; Wed,
 11 Jun 2025 17:51:17 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH3PEPF0000000F.mail.protection.outlook.com (10.167.244.40) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Wed, 11 Jun 2025 17:51:17 +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 Jun
 2025 12:51:16 -0500
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 Jun
 2025 12:51:16 -0500
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; Wed, 11 Jun 2025 12:51:15 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b02e8e19-46ec-11f0-a307-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=yMFqcERwWDoSUDEoD/hYDKZcSOCFqPOuOJrUmsc8sbH9qCTcuPJOqbx28FBI/MZW3P0wM1XsqWZsYicGQMJWJhB31c5gmd2hGlcWiWo4bYE2K5QQPATXveh363inF231DBLo3Oz1b8/cTsaGyAeF3QkJqmakK+ogLAjqlBbJlHNxN+h8udUrOc2lYd/829spsxmQVLqiXJAcoaX9UGqXaZyjpiWvvIIDdxm1xvUQv1rJseOVnRP42EEPg8JIOHTeOvIxDyyeQiNpkLp6jVmPiDUUkQmdYI+jWZABp/+1bC9pqXvxk/FEgH1kcE9zOADNxsZVZUQI7zyVoRq/Gm1c/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=iGmqazHG8KK3KvSeo0zM4HF7mf0mYqw7CBlFxC1daAE=;
 b=rBONs30pi728r7QrsrZ5pMfTAC+I7Ff81Xiy0Q/EEjI6hjQn9sDb4A9yxuootq8gKLuBvfDP0W8Pt3YqvtjLF80jTV3MsUL1y+WAP9YRGF5OHdIOFV6bGu9AMVL6pg5yjPeCFaHesNheNv+bJJbIRRf7q4HD4QxxsyGo2Afb/xCRjmcdU3hQiGeTKE05a/COA6fjFkny6Y7h0pgJKQmiMOkBZcwu9PRiM/kl19CB7wqOfAXOlYjpZlsavh2hod8GI/NcgAAosulXhsLVQJguzcW/oXw+oMJncCh4rPIIvS7CYXJWIrFg8H75IqglYJNAFb7aAI9u6JvST7wJeKyexw==
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=iGmqazHG8KK3KvSeo0zM4HF7mf0mYqw7CBlFxC1daAE=;
 b=J9kvqau/dc2iQPfhvnpLHi71GHQhxMWxaa0oclSmFMsQIDkKhBHaL4ALnxoqAEvmb2Lh8U4+uTt7rGJ0MrPnSm50Q+9+u6rGJj0IQ5cKUBhm5krVtqphKz5S+v95szdSXpD7zs4m6MmdPCjpURNFiBsqeFXE+aco6JtzAdS7qP8=
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: Stewart Hildebrand 
To: 
CC: Stewart Hildebrand , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" 
Subject: [PATCH v5 1/2] xen/arm: exclude xen,reg from direct-map domU extended regions
Date: Wed, 11 Jun 2025 13:51:03 -0400
Message-ID: <20250611175106.269829-2-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250611175106.269829-1-stewart.hildebrand@amd.com>
References: <20250611175106.269829-1-stewart.hildebrand@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB05.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH3PEPF0000000F:EE_|DS7PR12MB5742:EE_
X-MS-Office365-Filtering-Correlation-Id: 79dc2d44-ed21-47de-f0c2-08dda9109143
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?nMtf5re1GBEoaUrL8XfurncGXQYHbJWUqMdFY/Y9atPq27P3/kJk4n2HJfFd?=
 =?us-ascii?Q?/EpadufYrWWFkRlgHVNe7n9njniGrKL2/4SVxjYWNR29iOiUIAYnLrCoVCws?=
 =?us-ascii?Q?/6PevyIaAUxZUqiKYrC/eYlAjC7aid2oCOYehAeqyJelM3DH5/H2z0gDabYS?=
 =?us-ascii?Q?WHIjAwC+2DqWlzGpvp3O3+4s9wSS8hpTexTmfYiJm1tOf8K8lr44JR7byUdC?=
 =?us-ascii?Q?cRjoq5xk3SbIbbl4OVkz1FoIE9+yClBwHcJXz3n8HonKSm04e81zpqHtILHU?=
 =?us-ascii?Q?poxVMjB4GoW9f4k7n63cRhJtON0ahXpz1OLnK5MerI+cmpw7GXEU88g8JG9Y?=
 =?us-ascii?Q?NC3ahARTMlFDGkF5g/p9WOG0mdKiW/ccjVjWpgnnnjs4pBRejV1MwVzfed39?=
 =?us-ascii?Q?cCa4O+xdtkot6iT61jqZ0NUv/tLnavcanGaiXtKzm8ieQ41yADKbP98/iEdB?=
 =?us-ascii?Q?2W+OH2T4Vk76G+wEVG37RZ2w6xDdPMtlM//Zp62YPqv2BKZNF8nBv6JSqzkk?=
 =?us-ascii?Q?FKR5XQkeb111BuVCJBuWu0hznGh8JjkZJHQCh4X1Sc6UTUD6r6io5xusB9iP?=
 =?us-ascii?Q?MZDtIt/luWx8xdVmRwafIx3Tvh76+qYaA7HXbHwTjMi+xz++HlMQ4gEj1Ufk?=
 =?us-ascii?Q?J6Ca8kFehQkAHk4kweI3pLGfB+QoYvu9VkPigFqfozI24LM9W2gdGuIpDar9?=
 =?us-ascii?Q?KKsQXr6/sSgyGVpu88bP/KOhQZBj2RcuM84JujWYJ6Eac84Oau+ScvDP0cJW?=
 =?us-ascii?Q?eyDC8o26WZIRrlvqSKLDy1g72Zwi4fzGSPFVNmG+EyCSweR4vb2nfLiPHptt?=
 =?us-ascii?Q?CXKdNDOqXbUOFZYWZiMSle9w/Xn+/OEoaUSntXU27WYzwYezKaAgUYwGRkvf?=
 =?us-ascii?Q?xV2S1OHPWuWXQmrN/9OOC3U/KdAH15Bl1VYyLCru7+YHPgHuxRD8T9GoBCm2?=
 =?us-ascii?Q?5mIF2o8pTCkDTNd/h1n9THTk4m1f8h4nsKYHRR+0svNtyB2DHz1xi8KLBio5?=
 =?us-ascii?Q?Ki7G6F/7Uvc5/tPCjGH5kC9xCMZRDFcjJX5no9bknh91e4AQhcsS4gnPiS5Y?=
 =?us-ascii?Q?UfTKGuRI8M2EmClqkvoni1RhVFRvCGskBB82wiIdlQGVLcqWm4VtUL1LT8o9?=
 =?us-ascii?Q?o+TixcjUOGIEYtnsijVvUIuYhCclJf7G3YyiV57nubwb51JdvSzy+5ue/95E?=
 =?us-ascii?Q?02cupB3RVFiMkvRjOth1ID88KRwqkEzhMWJ7/P2FsOSnuSBBVX9IrxbL6TGa?=
 =?us-ascii?Q?eS6NhKZgqcKZEO5JwU6Nqq8UfshzykVP2p4/8iTV73g2fyRHuB7HdVDyuf0n?=
 =?us-ascii?Q?Bt7b04NhXawv1QIF2vG/D51ZYLjXyInJmYDH5UtHYvjxuTf0t2BrLXtfZpcx?=
 =?us-ascii?Q?yg1rLCZ94qyJo/CL74hRv4ASe0iz1Y9T5uWXPL6tNtBJsCkmVO+AcAQZrCPm?=
 =?us-ascii?Q?ejI1+e2rkQU3gQzSBvvJbkl04NHUs7DpFISN+LfiSJ3DyN+Xvc3GpwGJE0bs?=
 =?us-ascii?Q?aKXYRjWiCbfSAdtq6Budbdr6jm9emJDvSL92?=
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: 11 Jun 2025 17:51:17.7665
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 79dc2d44-ed21-47de-f0c2-08dda9109143
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:
	CH3PEPF0000000F.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB5742

Similarly to fba1b0974dd8, when a device is passed through to a
direct-map dom0less domU, the xen,reg ranges may overlap with the
extended regions. Remove xen,reg from direct-map domU extended regions.

Take the opportunity to update the comment ahead of find_memory_holes().

Signed-off-by: Stewart Hildebrand 
---
v4->v5:
* remove extranous -1 and +1
* create local helper function to count ranges

v3->v4:
* conditionally allocate xen_reg
* use rangeset_report_ranges()
* make find_unallocated_memory() cope with NULL entry

v2->v3:
* new patch
---
 xen/arch/arm/domain_build.c           | 80 +++++++++++++++++++++++++--
 xen/common/device-tree/domain-build.c |  5 ++
 2 files changed, 80 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 590f38e52053..cef6c85e22ec 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -792,15 +792,17 @@ static int __init handle_pci_range(const struct dt_device_node *dev,
 }
 
 /*
- * Find the holes in the Host DT which can be exposed to Dom0 as extended
- * regions for the special memory mappings. In order to calculate regions
- * we exclude every addressable memory region described by "reg" and "ranges"
- * properties from the maximum possible addressable physical memory range:
+ * Find the holes in the Host DT which can be exposed to Dom0 or a direct-map
+ * domU as extended regions for the special memory mappings. In order to
+ * calculate regions we exclude every addressable memory region described by
+ * "reg" and "ranges" properties from the maximum possible addressable physical
+ * memory range:
  * - MMIO
  * - Host RAM
  * - PCI aperture
  * - Static shared memory regions, which are described by special property
  *   "xen,shared-mem"
+ * - xen,reg mappings
  */
 static int __init find_memory_holes(const struct kernel_info *kinfo,
                                     struct membanks *ext_regions)
@@ -882,6 +884,13 @@ static int __init find_memory_holes(const struct kernel_info *kinfo,
         }
     }
 
+    if ( kinfo->xen_reg_assigned )
+    {
+        res = rangeset_subtract(mem_holes, kinfo->xen_reg_assigned);
+        if ( res )
+            goto out;
+    }
+
     start = 0;
     end = (1ULL << p2m_ipa_bits) - 1;
     res = rangeset_report_ranges(mem_holes, PFN_DOWN(start), PFN_DOWN(end),
@@ -962,11 +971,51 @@ static int __init find_domU_holes(const struct kernel_info *kinfo,
     return res;
 }
 
+static int __init count(unsigned long s, unsigned long e, void *data)
+{
+    unsigned int *cnt = data;
+
+    (*cnt)++;
+
+    return 0;
+}
+
+static unsigned int __init count_ranges(struct rangeset *r)
+{
+    unsigned int cnt = 0;
+
+    rangeset_report_ranges(r, 0, PFN_DOWN((1ULL << p2m_ipa_bits) - 1), count,
+                           &cnt);
+
+    return cnt;
+}
+
+static int __init rangeset_to_membank(unsigned long s_gfn, unsigned long e_gfn,
+                                      void *data)
+{
+    struct membanks *membank = data;
+    paddr_t s = pfn_to_paddr(s_gfn);
+    paddr_t e = pfn_to_paddr(e_gfn + 1);
+
+    if ( membank->nr_banks >= membank->max_banks )
+        return 0;
+
+    membank->bank[membank->nr_banks].start = s;
+    membank->bank[membank->nr_banks].size = e - s;
+    membank->nr_banks++;
+
+    return 0;
+}
+
 static int __init find_host_extended_regions(const struct kernel_info *kinfo,
                                              struct membanks *ext_regions)
 {
     int res;
     struct membanks *gnttab = membanks_xzalloc(1, MEMORY);
+    struct membanks *xen_reg =
+        kinfo->xen_reg_assigned
+        ? membanks_xzalloc(count_ranges(kinfo->xen_reg_assigned), MEMORY)
+        : NULL;
 
     /*
      * Exclude the following regions:
@@ -974,6 +1023,7 @@ static int __init find_host_extended_regions(const struct kernel_info *kinfo,
      * 2) Remove reserved memory
      * 3) Grant table assigned to domain
      * 4) Remove static shared memory (when the feature is enabled)
+     * 5) Remove xen,reg
      */
     const struct membanks *mem_banks[] = {
         kernel_info_get_mem_const(kinfo),
@@ -982,12 +1032,29 @@ static int __init find_host_extended_regions(const struct kernel_info *kinfo,
 #ifdef CONFIG_STATIC_SHM
         bootinfo_get_shmem(),
 #endif
+        xen_reg,
     };
 
     dt_dprintk("Find unallocated memory for extended regions\n");
 
     if ( !gnttab )
-        return -ENOMEM;
+    {
+        res = -ENOMEM;
+        goto out;
+    }
+
+    if ( kinfo->xen_reg_assigned )
+    {
+        if ( !xen_reg )
+        {
+            res = -ENOMEM;
+            goto out;
+        }
+
+        rangeset_report_ranges(kinfo->xen_reg_assigned, 0,
+                               PFN_DOWN((1ULL << p2m_ipa_bits) - 1),
+                               rangeset_to_membank, xen_reg);
+    }
 
     gnttab->nr_banks = 1;
     gnttab->bank[0].start = kinfo->gnttab_start;
@@ -995,6 +1062,9 @@ static int __init find_host_extended_regions(const struct kernel_info *kinfo,
 
     res = find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_banks),
                                   ext_regions, add_ext_regions);
+
+ out:
+    xfree(xen_reg);
     xfree(gnttab);
 
     return res;
diff --git a/xen/common/device-tree/domain-build.c b/xen/common/device-tree/domain-build.c
index 6b8b8d7cacb6..99ea81198a76 100644
--- a/xen/common/device-tree/domain-build.c
+++ b/xen/common/device-tree/domain-build.c
@@ -193,6 +193,10 @@ int __init find_unallocated_memory(const struct kernel_info *kinfo,
 
     /* Remove all regions listed in mem_banks */
     for ( i = 0; i < nr_mem_banks; i++ )
+    {
+        if ( !mem_banks[i] )
+            continue;
+
         for ( j = 0; j < mem_banks[i]->nr_banks; j++ )
         {
             start = mem_banks[i]->bank[j].start;
@@ -212,6 +216,7 @@ int __init find_unallocated_memory(const struct kernel_info *kinfo,
                 goto out;
             }
         }
+    }
 
     start = 0;
     end = (1ULL << p2m_ipa_bits) - 1;
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 17:51:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 17:51:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012053.1390616 (Exim 4.92)
	(envelope-from )
	id 1uPPbp-0005GC-4H; Wed, 11 Jun 2025 17:51:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012053.1390616; Wed, 11 Jun 2025 17:51: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 1uPPbp-0005Fz-19; Wed, 11 Jun 2025 17:51:33 +0000
Received: by outflank-mailman (input) for mailman id 1012053;
 Wed, 11 Jun 2025 17:51: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 1uPPbn-0005Bu-U8
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 17:51:32 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on2060c.outbound.protection.outlook.com
 [2a01:111:f403:200a::60c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b33a52c0-46ec-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 19:51:29 +0200 (CEST)
Received: from DS7PR03CA0082.namprd03.prod.outlook.com (2603:10b6:5:3bb::27)
 by DS0PR12MB8019.namprd12.prod.outlook.com (2603:10b6:8:14e::9) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.38; Wed, 11 Jun
 2025 17:51:25 +0000
Received: from CH3PEPF00000016.namprd21.prod.outlook.com
 (2603:10b6:5:3bb:cafe::86) by DS7PR03CA0082.outlook.office365.com
 (2603:10b6:5:3bb::27) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Wed,
 11 Jun 2025 17:51:24 +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.8835.2 via Frontend Transport; Wed, 11 Jun 2025 17:51:24 +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; Wed, 11 Jun
 2025 12:51:22 -0500
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 Jun
 2025 12:51:22 -0500
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; Wed, 11 Jun 2025 12:51:21 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b33a52c0-46ec-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=SDh/NYOK76VAUfe3NsGqu1T3/MPqr8CCvZI3gmkQOWiYtvucNaor135smGAN7awzZfA5zqq4FAH/vw1mz2FTuF6I6WiJ4x+ezkVlgCtHxZY74DaXvhYGjPhDHhwcS0z3WVxYjpZYhFdXEIcvy1MnVWjjTBFa33yT1jBDuUF70+JonvVVXPS6yZqZcJOgL9LE9/GdKVvjHUGbwlgAuRt8AmCkCCPXO8XDqkxyBH/woChVBn3M1lEU8OS/BZNO/5mXyoPIVsypqLZFiD03yQMl53i/phJCLTKcn7gKNd8UMYt6UUGywiIXYDk49B8mIDu0uicsN15vBw5H0b4HDh6RKQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=OGLNAcHMQN3tEn5Sq+wi+jklFsofF17Ha4Z5ZK5ekUI=;
 b=m6VnlhnL6Sj9R+naMbZgq1d6M+CSZqCPsCa5AJ3HCYByS6VaM6y29CCatt+oWQ6lUHdt150OD1FoiFrM6hCEFtA0p2HnZpf/qpwPUVwF40VWzlnG9TZWL2mFW5K7IJyIw22jRsaLeH0XmuEaZN669kGqjUq+zGEZdVLhwtQwfsMqESRXOpiHKUj+3fFvwvdmWK+v/Q9U9gKSvD7I/+S66b0Jy1UFmAulw766PrGVfbVWT6RpeNsC2/HG9zuvzkpA3KEuImWTJI2pASE0rVddDbWuGUm8CcfdqMy5A2NjdafMWZ0CfKdYORQ76KLgToFE/npdaecfcESxpK06Gn20/A==
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=OGLNAcHMQN3tEn5Sq+wi+jklFsofF17Ha4Z5ZK5ekUI=;
 b=YTmAHGjgvQZ35G+xnQckZU0RMs2aZcbm+dlTZv/lxCsyrHy+wRZiOm/xocHOqD1/whsf00d5S8nWG0OhNJSwtcYiw2ZcQu7Ce70j1wNfnR2Cj3VuLxKLIEHxKKcxFGyLAar9esWbWFbIihm1Z1XaN0HQqfJfP0tcJnvkDJ8Djvk=
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 , Anthony PERARD
	, Juergen Gross , "Stefano
 Stabellini" 
Subject: [PATCH v5 2/2] tools/arm: exclude iomem from domU extended regions
Date: Wed, 11 Jun 2025 13:51:04 -0400
Message-ID: <20250611175106.269829-3-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250611175106.269829-1-stewart.hildebrand@amd.com>
References: <20250611175106.269829-1-stewart.hildebrand@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB05.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH3PEPF00000016:EE_|DS0PR12MB8019:EE_
X-MS-Office365-Filtering-Correlation-Id: 369f911f-cf31-4ca9-d5e8-08dda9109558
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?7iqFYPSaJBweMpj9Ldb35LKxV6mXE1vQapHUx06ySHGTXMGKJh7RD5M8Poxr?=
 =?us-ascii?Q?6SjE4Ew9dQTfU0Nld4VzTUyXWN85pQ3dTDj/0k2F3bRBSFeacnQ2w6Pd1ZRR?=
 =?us-ascii?Q?HaPobUQgLFSqWyr0emPQQDAzysoMrrRD823DtBcQ5crk2huheJbaXKPKE+DH?=
 =?us-ascii?Q?SaSOLbU/ZKrwJ4gl1h5463jZSOAv/hKu/vQb0prOH+/pUZX6+d1y5PjtoIKa?=
 =?us-ascii?Q?hefl3+F0UiToxzqp2L1cgYUaEkfZVP6DQCaIihS629ggLMICrbqRqDw+wXml?=
 =?us-ascii?Q?kTXSZhU8yGJ0/LDdjlc/ta4Ta7qo6NWxivIyiUMYRcUovwNotTd1neg2LCU5?=
 =?us-ascii?Q?QYiO124W+qhJDdFDFVHzs34Wkgyv+sSOyvo/4NkYhwLMEYgYmmikqE8yhAEE?=
 =?us-ascii?Q?1obXLoWfaRL6HzQmwA0+JPHRwKMzDIvCcFt6n73sEiz+W89U9y8pLGqn2wT9?=
 =?us-ascii?Q?gLkgWVBErE2KNIFKh+ReBsTL5v62jwAM2lwzwOJZa4HjMrK7kGX/dfqB1Tzz?=
 =?us-ascii?Q?yIL0nq56HINGXfily0bNL/dcjNM0EQgn7QcAJuOWN5htFJblb8xkZYVoLEvb?=
 =?us-ascii?Q?olXEUQ6p1CSOBaaP4qLsQDm0fKcWd/ig9pU08NgT7WY82563VdaHU0RM0LF0?=
 =?us-ascii?Q?oXb0T+F6Faya6YaAGpJWV+c9n1a1to1kiUMVkohJEj5JfUapbMpNsMwXdwpf?=
 =?us-ascii?Q?/loTrai9wSXkkW0Pci/4K4fERYGgjtgNdvSprBCq6eV/kGaCvM1Nt8pw1XZM?=
 =?us-ascii?Q?tRe0/udPDcMr31Xfrchu9MUKT1xnuBNOTVRyf1n91GfC88cR16lRzOLudoMB?=
 =?us-ascii?Q?45//6CkAYKebLKOvrz9zuKYNwODU7W3emw32cA0T/BNRk1r0Ef8UJtwAS0Ux?=
 =?us-ascii?Q?4PQoqiqFHNhlopcUOCi8rf+OL6b8SNJJPRZE0o692UI/h/OuDHVAbmBy3qqd?=
 =?us-ascii?Q?ru9mHAmZBXtpwQ/zd08NP2vXJCRRNxxdCUQLnSqETtm+mCHJwnAUK4pF4Bfy?=
 =?us-ascii?Q?aXpmIf2pqdofIqIH5IyBFXrjisEqwLfKYs3LAA5ZlcBZHjaYAoVqEIlY7usc?=
 =?us-ascii?Q?8Ot11FzTfubiuPStSOuzCzr34cn1ArCeccAXedBclaf0cp2hGcwWzm4h8Oec?=
 =?us-ascii?Q?LPxGMTyx/aA28NjTkLe99oBr+YLRTZ/MaLESsCY0RZkzj4qOaWynXflwY13t?=
 =?us-ascii?Q?nygsHS7rSGJ3m8GuEXp4UnjR884jt7v2u0S6nQs5TBKBFcnVRSDwwcUVv+FE?=
 =?us-ascii?Q?T3OkDLQd3dN/UeiFSlb4Nrc3utItYghp6ebUfin7UcQ5+/xoI7UuXix5H81r?=
 =?us-ascii?Q?r298kCeE+gWnt8NZagrHX5LJVcf4TlQcNwnjXjOdJYXHXMCeTK6vaeH4ATCW?=
 =?us-ascii?Q?Kl4WlEu2MlY4Yjx3Jo3RuHHKOXNBgsYVcf4aPHWunGuDl6CCd8lIJkQLuzz/?=
 =?us-ascii?Q?KQebHvjqufmftvnVNUGT+5wlLgavQFXddXBmbbdaAkiHt7W6VENrs7tC05ep?=
 =?us-ascii?Q?YF2W4VQaVgFL5uE=3D?=
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)(36860700013)(82310400026)(376014)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jun 2025 17:51:24.6125
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 369f911f-cf31-4ca9-d5e8-08dda9109558
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: DS0PR12MB8019

When a device is passed through to a xl domU, the iomem ranges may
overlap with the extended regions. Remove iomem from extended regions.

Signed-off-by: Stewart Hildebrand 
Reviewed-by: Anthony PERARD 
---
Not sure if we need a Fixes: tag, but if we do:
Fixes: 57f87857dc2d ("libxl/arm: Add handling of extended regions for DomU")

v4->v5:
* add Anthony's R-b

v3->v4:
* use "else" instead of continue + another if statement
* remove assert
* s/iomem.end >=/unallocated.start >/ in two conditions
* new variable to distinguish unallocated size from region size
* print base + size - 1

v2->v3:
* no change

v1->v2:
* no change
---
 tools/libs/light/libxl_arm.c | 110 +++++++++++++++++++++++++++++------
 1 file changed, 91 insertions(+), 19 deletions(-)

diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 75c811053c7c..3086c52acf83 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -798,6 +798,8 @@ static int make_timer_node(libxl__gc *gc, void *fdt,
     return 0;
 }
 
+#define MAX_NR_EXT_REGIONS   256
+
 static int make_hypervisor_node(libxl__gc *gc, void *fdt,
                                 const libxl_version_info *vers)
 {
@@ -821,7 +823,7 @@ static int make_hypervisor_node(libxl__gc *gc, void *fdt,
      */
     res = fdt_property_reg_placeholder(gc, fdt, GUEST_ROOT_ADDRESS_CELLS,
                                        GUEST_ROOT_SIZE_CELLS,
-                                       GUEST_RAM_BANKS + 1);
+                                       MAX_NR_EXT_REGIONS + 1);
     if (res) return res;
 
     /*
@@ -1517,17 +1519,29 @@ static void finalise_one_node(libxl__gc *gc, void *fdt, const char *uname,
 
 #define EXT_REGION_MIN_SIZE   xen_mk_ullong(0x0004000000) /* 64MB */
 
-static int finalize_hypervisor_node(libxl__gc *gc, struct xc_dom_image *dom)
+static int compare_iomem(const void *a, const void *b)
+{
+    const libxl_iomem_range *x = a, *y = b;
+
+    if (x->gfn < y->gfn)
+        return -1;
+    if (x->gfn > y->gfn)
+        return 1;
+    return 0;
+}
+
+static int finalize_hypervisor_node(libxl__gc *gc,
+                                    libxl_domain_build_info *b_info,
+                                    struct xc_dom_image *dom)
 {
     void *fdt = dom->devicetree_blob;
-    uint64_t region_size[GUEST_RAM_BANKS] = {0}, region_base[GUEST_RAM_BANKS],
-        bankend[GUEST_RAM_BANKS];
+    uint64_t region_base[MAX_NR_EXT_REGIONS], region_size[MAX_NR_EXT_REGIONS];
     uint32_t regs[(GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS) *
-                  (GUEST_RAM_BANKS + 1)];
+                  (MAX_NR_EXT_REGIONS + 1)];
     be32 *cells = ®s[0];
     const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
     const uint64_t banksize[] = GUEST_RAM_BANK_SIZES;
-    unsigned int i, len, nr_regions = 0;
+    unsigned int i, j, len, nr_regions = 0;
     libxl_dominfo info;
     int offset, rc;
 
@@ -1542,20 +1556,82 @@ static int finalize_hypervisor_node(libxl__gc *gc, struct xc_dom_image *dom)
     if (info.gpaddr_bits > 64)
         return ERROR_INVAL;
 
+    qsort(b_info->iomem, b_info->num_iomem, sizeof(libxl_iomem_range),
+          compare_iomem);
+
     /*
      * Try to allocate separate 2MB-aligned extended regions from the first
      * and second RAM banks taking into the account the maximum supported
      * guest physical address space size and the amount of memory assigned
      * to the guest.
      */
-    for (i = 0; i < GUEST_RAM_BANKS; i++) {
-        region_base[i] = bankbase[i] +
+    for (i = 0; i < GUEST_RAM_BANKS && nr_regions < MAX_NR_EXT_REGIONS; i++) {
+        struct {
+            uint64_t start;
+            uint64_t end; /* inclusive */
+        } unallocated;
+        uint64_t unallocated_size = 0;
+
+        unallocated.start = bankbase[i] +
             ALIGN_UP_TO_2MB((uint64_t)dom->rambank_size[i] << XC_PAGE_SHIFT);
 
-        bankend[i] = ~0ULL >> (64 - info.gpaddr_bits);
-        bankend[i] = min(bankend[i], bankbase[i] + banksize[i] - 1);
-        if (bankend[i] > region_base[i])
-            region_size[i] = bankend[i] - region_base[i] + 1;
+        unallocated.end = ~0ULL >> (64 - info.gpaddr_bits);
+        unallocated.end = min(unallocated.end, bankbase[i] + banksize[i] - 1);
+
+        if (unallocated.end >= unallocated.start)
+            unallocated_size = unallocated.end - unallocated.start + 1;
+
+        if (unallocated_size < EXT_REGION_MIN_SIZE)
+            continue;
+
+        /* Exclude iomem */
+        for (j = 0; j < b_info->num_iomem && nr_regions < MAX_NR_EXT_REGIONS;
+             j++) {
+            struct {
+                uint64_t start;
+                uint64_t end; /* inclusive */
+            } iomem;
+
+            iomem.start = b_info->iomem[j].gfn << XC_PAGE_SHIFT;
+            iomem.end = ((b_info->iomem[j].gfn + b_info->iomem[j].number)
+                         << XC_PAGE_SHIFT) - 1;
+
+            if (iomem.end >= unallocated.start
+                && iomem.start <= unallocated.end) {
+
+                if (iomem.start <= unallocated.start) {
+                    unallocated.start = iomem.end + 1;
+
+                    if (unallocated.start > unallocated.end)
+                        break;
+                } else {
+                    uint64_t size = iomem.start - unallocated.start;
+
+                    if (size >= EXT_REGION_MIN_SIZE) {
+                        region_base[nr_regions] = unallocated.start;
+                        region_size[nr_regions] = size;
+                        nr_regions++;
+                    }
+
+                    unallocated.start = iomem.end + 1;
+
+                    if (unallocated.start > unallocated.end)
+                        break;
+                }
+            }
+        }
+
+        if (unallocated.end >= unallocated.start
+            && nr_regions < MAX_NR_EXT_REGIONS)
+        {
+            uint64_t size = unallocated.end - unallocated.start + 1;
+
+            if (size >= EXT_REGION_MIN_SIZE) {
+                region_base[nr_regions] = unallocated.start;
+                region_size[nr_regions] = size;
+                nr_regions++;
+            }
+        }
     }
 
     /*
@@ -1565,16 +1641,12 @@ static int finalize_hypervisor_node(libxl__gc *gc, struct xc_dom_image *dom)
     set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
               GUEST_GNTTAB_BASE, GUEST_GNTTAB_SIZE);
 
-    for (i = 0; i < GUEST_RAM_BANKS; i++) {
-        if (region_size[i] < EXT_REGION_MIN_SIZE)
-            continue;
-
+    for (i = 0; i < nr_regions; i++) {
         LOG(DEBUG, "Extended region %u: %#"PRIx64"->%#"PRIx64"",
-            nr_regions, region_base[i], region_base[i] + region_size[i]);
+            i, region_base[i], region_base[i] + region_size[i] - 1);
 
         set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
                   region_base[i], region_size[i]);
-        nr_regions++;
     }
 
     if (!nr_regions)
@@ -1626,7 +1698,7 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc *gc,
 
     }
 
-    res = finalize_hypervisor_node(gc, dom);
+    res = finalize_hypervisor_node(gc, &d_config->b_info, dom);
     if (res)
         return res;
 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 17:58:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 17:58:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012073.1390626 (Exim 4.92)
	(envelope-from )
	id 1uPPi4-0006Mh-Up; Wed, 11 Jun 2025 17:58:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012073.1390626; Wed, 11 Jun 2025 17: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 1uPPi4-0006Ma-S0; Wed, 11 Jun 2025 17:58:00 +0000
Received: by outflank-mailman (input) for mailman id 1012073;
 Wed, 11 Jun 2025 17: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 1uPPi3-0006MU-JY
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 17:57:59 +0000
Received: from NAM04-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam04on20615.outbound.protection.outlook.com
 [2a01:111:f403:240a::615])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9ab32b98-46ed-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 19:57:58 +0200 (CEST)
Received: from SA9PR13CA0122.namprd13.prod.outlook.com (2603:10b6:806:27::7)
 by CY1PR12MB9557.namprd12.prod.outlook.com (2603:10b6:930:fe::12) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.34; Wed, 11 Jun
 2025 17:57:54 +0000
Received: from SA2PEPF00003F63.namprd04.prod.outlook.com
 (2603:10b6:806:27:cafe::be) by SA9PR13CA0122.outlook.office365.com
 (2603:10b6:806:27::7) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.14 via Frontend Transport; Wed,
 11 Jun 2025 17:57:54 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SA2PEPF00003F63.mail.protection.outlook.com (10.167.248.38) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Wed, 11 Jun 2025 17:57: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, 11 Jun
 2025 12:57:53 -0500
Received: from [172.27.195.250] (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, 11 Jun 2025 12:57:52 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9ab32b98-46ed-11f0-a307-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=A7Pn6sYUFu+pCIiInod76uhnaRa8DSRWvE5Hol2eeFUgS8qzkl7cp3QcPDQOTWxS3fMCOrzjVcT8ju40ki+HqsLLHz/4tws1TFRKnRnil2U3Q6doRyBXRTzu+4f15EWFvIP5StH5NwZsH6QNSLMKCAM/IXuPsI9JbyyFwFWkkwurKf7c+BDN71gFnwocRtZB+JkvSQjEnyZiX0A5ILLD/cyTSDoEtJ+kAU7qq4BAlibBORe9zAWkDELU6Y8IMn/TDZHwN2pj4HD41sS6tvPRcqFmiG2TSHkdMeuZyvyqw0H+eRCp/kcYy/zUymzW4zZb1Kgik7wApmqaqmky4s0TGA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=rDDE3QKO9PxUdocv8Y5SLU29UOji/MivnMZSKCYRwEA=;
 b=H9Ry7MEaidJaNsritpK3wa3Ca9aaPD9PhZ2WH7fYX6lAqi6oFRI5atwtm0aQ2t83zTVkwgdwKqUKtqlUfYRhFYHRQGQQtzdiXPKW1eiff3bezV/yMsOLjUF0gaQdSLRdmfXQq6glUdtpVLf3JYMx/x99yZ7b2PWPpnAcwgYJV9aRUldx5L/Du1cT/qk7WJeRFdIsAJp5luhu6+ExhO98sn/Ds5ixABTOuoPMpa4bTQ2nQsRZSX3Q/53Z8LBP3//1Oe2RoH/ZNHIMnHlJBqFI989GJiJF+k6ogEkZ8MESVtJ/jblFIZTl3Xv3snPPDUXDAmD0BO22UN4wHeODiDev+g==
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=rDDE3QKO9PxUdocv8Y5SLU29UOji/MivnMZSKCYRwEA=;
 b=lmEZNH0hmMKeaHDYbuUtQk9nzxpP1bCLn5T0PjQMiUhjXCZMJvItiT7z64MXbVdZvw3nePzmg3r7HukAy10D37RzWjsF7CzLCDF4rN6BahxfrKTzEesUCzXoyU0b+2slaDtprMEbqobg41I/I1nbDl6mOaxLcFCPwYYeMhkfun4=
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: <07ef8905-c7c2-4745-9e8d-a8e1e3430195@amd.com>
Date: Wed, 11 Jun 2025 01:18:56 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] x86: FLUSH_CACHE -> FLUSH_CACHE_EVICT
To: Jan Beulich , "xen-devel@lists.xenproject.org"
	
CC: Andrew Cooper ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <1491ce61-6aff-4542-8bc1-d7db1324cce3@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <1491ce61-6aff-4542-8bc1-d7db1324cce3@suse.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
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: SA2PEPF00003F63:EE_|CY1PR12MB9557:EE_
X-MS-Office365-Filtering-Correlation-Id: b5479a85-843c-44e0-7132-08dda9117d3d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|36860700013|82310400026|1800799024|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?dTdIUjZ2ZnNXb3RHWnRwYWU0aFlucFFEQXZBVUZ2SWhtV1drREt4V2U0ek5q?=
 =?utf-8?B?ZlZaTzRVb2RVWjdqOUI4cjlCVzk0RkVmUW90dFg3RCtpOFpIcnpIZGVpaFZ4?=
 =?utf-8?B?RlQySVM5UkxJdFRPU3JYNWhCZ0hNTjZvRGU2YmlDblV6cC9CUlVKRXhQb0xr?=
 =?utf-8?B?RWZDQXlURnpUdFdpYUZEWUp6OHJpSTBpbmhZV0kxbXRYMWwzOVROTEUxQXZh?=
 =?utf-8?B?cE0yZDZUTHpMRmpzbUhpZng4ZmlRM2pKdnMzd1NSejdOdE5MK2laU1d4Mm1M?=
 =?utf-8?B?V2UweE5IMDdqMy8vMGZ0RWdPSkl0cGNKS2FEN1BDa2lHNStHamh0bC9WV2dh?=
 =?utf-8?B?YlZINXZQb1ZKMzNYZUtxQlJacnRZOThYUGQ4WUdiaXVJWkp2cDNHZ1lNd0ov?=
 =?utf-8?B?UEoveUdzdTdJRzZpL09ISFlIckQ2bWhRZHY0L2xXRnVDRnhjNDlodk9tL0xG?=
 =?utf-8?B?RnJyVzBMd3R5eFQvUnhDQWp4UGRQQU5qTUlrNjE5aFNJcDNNamNSc3RqcW02?=
 =?utf-8?B?OUY3OGNMUG9kRHdRU1pyaVRTTklvOGNkZEJiNjlwZ1psZGF3ZktDMTBuWDZQ?=
 =?utf-8?B?R2x2WnFldXhGYjBid3pOQ3VicHZVaDBURkV5UnRkSHJKdTVzdU9PRDFDc3BX?=
 =?utf-8?B?bmY0ZmJJTEdndFNDdC84QUJoMk9vZXYwdDl4YXdQZ3FZZFRhYjY0WW5jWGdh?=
 =?utf-8?B?SHZBRkR0NXYvVkVpUTRJZytJZkxzZDU4anpHdlNVcW9INzEwd3ROdnljanM0?=
 =?utf-8?B?eEZzcXo3b2ZMakNtOXhiWmd1RjhKUnI2cEhXcjRzcTdEQXlsN2hxalZWcE1s?=
 =?utf-8?B?YzVMUm1SQncyUFQvTzJ2cllDelhsSHNZSE5RNlJMRlpsUHZsdmVVUER6b2g0?=
 =?utf-8?B?V1N0ejQ5WnRBbytLUlUvZnV6WUduK3hyL0V5WFJlMThKU2hxQno2dTkzbDF5?=
 =?utf-8?B?QTdtUUN0YytjdVN4ekhqZk14dlBSTEZhbmpvT2dUd2VMWVlyeUYzYnV3Znpu?=
 =?utf-8?B?WWVsdE9rR3FjQXhlbWtlVjF6MCtLeWVQMVR1QUdoK2ZmY0l4THZMMUJLSE9r?=
 =?utf-8?B?cFhnRktkK1lHSUpjL1ZTTWMyWXZxZklsS1Znem9DbWVvM0xKQ0paSzI1bW9v?=
 =?utf-8?B?Z3pWQk16ZW8ySkgwSHpLWXV6ZG5wU1QrSEcza3VaS1FvS09UNWpSRittTjRt?=
 =?utf-8?B?a2RlU1Iva0gramlpeUpBdmJEUlc1VlRXM0ZsQjZReHEyWjJxc29JTjBWUmtD?=
 =?utf-8?B?SzdiUDBtcmVFdUtCeXpzeXN6cWswSENyeUdIVm5xMFdGWG9GbDRValpSeTgr?=
 =?utf-8?B?U0NPTzg0Q1ZyWG5MK1ZORXkxVCt3S0lSK1VTMkVrM1E1MG9yWmpyRllpbVVV?=
 =?utf-8?B?ZVFXcGJ0NTl5L3FlMDhTTXdvZVczVHJVTUFsTTZuQ2JyTFJkZEFhQldpS2JY?=
 =?utf-8?B?djlpZ2psaDNEZWc3UDhGM3FYbHRDWDZCY1A1a0hIRWFKam1aTjE1SnFoR2o1?=
 =?utf-8?B?RWxtRjRCYXFMVys4Uk9rdFRPdThQalpxVDc3aTZxcW1vOFpOQ2w2TTdDcWRE?=
 =?utf-8?B?Y3gybCtqT2toQW5nK0VhcFduMFhnbEJLY1RUb0pod0kySXYzRUs2SlFkL3pa?=
 =?utf-8?B?SHR4SzNSbDF1U3pHNS95S3hRNG5jK3dKWGlRUlVCN1F3Y2FOVGx1OHpXRVhO?=
 =?utf-8?B?QXpRQVl1TVNXdzFRVVZ4TUdZNW1kTDMzeDFSb25OS2UyVHJhbnVRSlJIUDZR?=
 =?utf-8?B?NW90NXBUb21MRnZOd2pxbHpnc2ZXU01FaFNlTm02ZytMV3RrRHBvQ1c4MXR6?=
 =?utf-8?B?Z2gwR1JkbWZ1RExGMlBPUHJZNWI1V2UzNlMxSHRqRC8waXRvRkxGZyt4eG5Q?=
 =?utf-8?B?TkxWcjhqemkrQnBWNHNudXdDdWZacE9PZm1pbmErc3JpcTc1OE9Wa2gxMEZU?=
 =?utf-8?B?Q29QUDJxN1EzQktvNXMxQVNEWjFsczNBbTZWckFxc2dzOTFCd1FBYit4Zmt4?=
 =?utf-8?B?bVVwUUgrYU9KelBnRWZuS3dEVCtlZzRBb010eElqaVNXMG1pazZWK1orZGR2?=
 =?utf-8?Q?XEkg2I?=
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)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jun 2025 17:57:53.6468
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b5479a85-843c-44e0-7132-08dda9117d3d
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:
	SA2PEPF00003F63.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR12MB9557

On 2025-06-11 06:02, Jan Beulich wrote:
> This is to make the difference to FLUSH_CACHE_WRITEBACK more explicit.
> 
> Requested-by: Andrew Cooper 
> Signed-off-by: Jan Beulich 
> Acked-by: Roger Pau Monné 

Reviewed-by: Jason Andryuk 


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 17:58:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 17:58:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012078.1390635 (Exim 4.92)
	(envelope-from )
	id 1uPPid-0006qO-6j; Wed, 11 Jun 2025 17:58:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012078.1390635; Wed, 11 Jun 2025 17:58: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 1uPPid-0006qH-4A; Wed, 11 Jun 2025 17:58:35 +0000
Received: by outflank-mailman (input) for mailman id 1012078;
 Wed, 11 Jun 2025 17:58: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 1uPPib-0006MU-Qx
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 17:58:33 +0000
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com
 [2a00:1450:4864:20::432])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b099147d-46ed-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 19:58:33 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3a361b8a664so139692f8f.3
 for ; Wed, 11 Jun 2025 10:58:33 -0700 (PDT)
Received: from [192.168.86.29] ([90.250.112.104])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-453252056bbsm27705295e9.26.2025.06.11.10.58.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 10:58:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b099147d-46ed-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749664713; x=1750269513; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=5gvOP0mKW1ypaQEOCG9IA46hEWtP+5hlN0TIFMVv5fg=;
        b=Png1jZbOtbmHQJbbEA8XcQp2VvglQvGJo+GsfSEClyW0yYeN0+hYPuKpo2mK4KGynv
         5NbuCRNnyc1baPWXHsirvY7U0qa5DAfV9+pM3Jn0vZo0OwKL1MAZOE9wRA+3XTjmSgBV
         K7QSZk3NNgS8h88xWYZmMV3qqyY4XwKvw7M8o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749664713; x=1750269513;
        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=5gvOP0mKW1ypaQEOCG9IA46hEWtP+5hlN0TIFMVv5fg=;
        b=TT18GnYujHyMZ/K97YrlZvWqcpWmni1dGr9ssFSf4a9KUGoXwzTdUdG2hJDPlIjJsL
         jv8i5IjCdV63WGMecbNKefjPmi3gzIt5Xe99aMVFZL6FTAZoRB4Uz+7N4fxZdVmjwo+m
         SfZRDq7u26UUJJtAY4EW8Me+Y2UAWf58avttv/cRjZMO/tax7Y6xTyvlzApTQMJBoi3Y
         f81tF/YkU8MyYRdDsbL7Ko/h7KRJRDI8owjrLRQloZd2gcH2x1zlNgRBrEBxRnrqSId3
         77hN9J6zi9L8tZGA8RgAnNygw8u10atMNgmDLotcoqPjZLv4rmuFUn6/8EgPs6MuyUAe
         3O+Q==
X-Forwarded-Encrypted: i=1; AJvYcCXXy5of86HOpJ3oxZ7gPZo/izbPljtyO3/Aubbn+hxTsO7s1rglEiS+yAyXpudy0mxfox16F2/5T6I=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyTm8i0qtWDrqfX1zvvMh9p80jq0mkRm6JDoizk+2ft2Gh9o+KO
	hLwXqlgYFISjNiN3bk9sxAhI8Zj7LEftVAYBCr+YqlGUYnttNynRqILExb3bV66L5jQ=
X-Gm-Gg: ASbGncvYQRVknZLj3x4/7prGowmh6qVcGK6izjKtXanJs5LDrw5CXdFQeXnr3fNS8eU
	DvbIuorvLJ0tbv6YkGpyzNvShJ0Ffo/TRpAvi4X5fZIChDmdxt1od80w/bYxaXA1bM6KFhkFpaf
	u6a69m0olE1LU9fIiu/KIm+lgp3O+XFPen6Mql23mPsHmuJoDzK/zLWg9Uxp8F7O13990Si6+CO
	Yp4JjERLLvofbTk65ArtOPrIqsjqeBQxz8erQOqOBjUl1joPS0n2GxPdneL7jwPcXAfRPdezemu
	oOv240rfxRin2zea9r45Uv15T+/e4tHJHWuZ821ZPFvUIy4Md7znYPckn4vpnrgQ5m/Lgwqo7yQ
	=
X-Google-Smtp-Source: AGHT+IFvAN/pIaBjnFe/+kc7F/hrDgz8XCXW6XBgbJqqNWMAc7NJmHMu+KFOYZH2rZktaKmSXWwjxA==
X-Received: by 2002:a5d:584e:0:b0:3a5:52cc:5e29 with SMTP id ffacd0b85a97d-3a5586dcd10mr3712431f8f.7.1749664712725;
        Wed, 11 Jun 2025 10:58:32 -0700 (PDT)
Message-ID: 
Date: Wed, 11 Jun 2025 18:58:31 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/8] x86/pdx: simplify calculation of domain struct
 allocation boundary
To: Roger Pau Monne , xen-devel@lists.xenproject.org
Cc: Jan Beulich 
References: <20250611171636.5674-1-roger.pau@citrix.com>
 <20250611171636.5674-2-roger.pau@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: <20250611171636.5674-2-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 11/06/2025 6:16 pm, Roger Pau Monne wrote:
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index 7536b6c8717e..2f438ce367cf 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -461,30 +461,6 @@ void domain_cpu_policy_changed(struct domain *d)
>      }
>  }
>  
> -#if !defined(CONFIG_BIGMEM) && defined(CONFIG_PDX_COMPRESSION)
> -/*
> - * The hole may be at or above the 44-bit boundary, so we need to determine
> - * the total bit count until reaching 32 significant (not squashed out) bits
> - * in PFN representations.
> - * Note that the way "bits" gets initialized/updated/bounds-checked guarantees
> - * that the function will never return zero, and hence will never be called
> - * more than once (which is important due to it being deliberately placed in
> - * .init.text).
> - */
> -static unsigned int __init noinline _domain_struct_bits(void)
> -{
> -    unsigned int bits = 32 + PAGE_SHIFT;
> -    unsigned int sig = hweight32(~pfn_hole_mask);
> -    unsigned int mask = pfn_hole_mask >> 32;
> -
> -    for ( ; bits < BITS_PER_LONG && sig < 32; ++bits, mask >>= 1 )
> -        if ( !(mask & 1) )
> -            ++sig;
> -
> -    return bits;
> -}
> -#endif
> -

I'm very happy to see this disappear.  Both because of a non-__init
function calling an __init function, and because this internal is just
horrible.

>  struct domain *alloc_domain_struct(void)
>  {
>      struct domain *d;
> @@ -498,14 +474,15 @@ struct domain *alloc_domain_struct(void)
>       * On systems with CONFIG_BIGMEM there's no packing, and so there's no
>       * such restriction.
>       */
> -#if defined(CONFIG_BIGMEM) || !defined(CONFIG_PDX_COMPRESSION)
> -    const unsigned int bits = IS_ENABLED(CONFIG_BIGMEM) ? 0 :
> -                                                          32 + PAGE_SHIFT;
> +#if defined(CONFIG_BIGMEM)
> +    const unsigned int bits = 0;
>  #else
> -    static unsigned int __read_mostly bits;
> +    static unsigned int __ro_after_init bits;
>  
>      if ( unlikely(!bits) )
> -         bits = _domain_struct_bits();
> +         bits = flsl(pfn_to_paddr(pdx_to_pfn(
> +             1UL << (sizeof(((struct page_info *)NULL)->v.inuse._domain) * 8))))
> +             - 1;

I think this would benefit greatly by not being a oneliner.  There's
sizeof_field() which helps a little.

But, isn't this UB with CONFIG_BIGMEM?  You're shifting 1UL by 64.

When __pdx_t is unsigned long, there's no bits restriction necessary. 
Therefore, don't you want !bits && sizeof_field(...) < BYTES_PER_LONG as
the entry criteria?

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 19:07:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 19:07:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012107.1390646 (Exim 4.92)
	(envelope-from )
	id 1uPQnI-0008Ro-0y; Wed, 11 Jun 2025 19:07:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012107.1390646; Wed, 11 Jun 2025 19:07:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPQnH-0008Rh-U3; Wed, 11 Jun 2025 19:07:27 +0000
Received: by outflank-mailman (input) for mailman id 1012107;
 Wed, 11 Jun 2025 19:07: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 1uPQnG-0008Rb-8g
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 19:07:26 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4ea0680a-46f7-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 21:07:24 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 1E13B61135;
 Wed, 11 Jun 2025 19:07:23 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 49803C4CEE3;
 Wed, 11 Jun 2025 19:07: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: 4ea0680a-46f7-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749668842;
	bh=6yHTpYOcEol2NbXpW5vDO9FVprK/DBV2h95QTI00LAQ=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=t/beb0Ti4+bYvgV+mctZIG63i5eRA4EoBGsw8FWY5aJlgVmNbDtcomLo18GEd/n/Y
	 B9rdMFD41WCLcoHS6vgxeEjmQuDX0OYwno6isoZH2XC2l5+3tC0CJct8Y5hCkvjvOb
	 HLXqm24EMkQfY7yrUs/RoBf235jGUQGJ9ADK3orETu1B2D//CD24reaXoYRkvCqdaE
	 vvdpcK0pKk9rGXS1bNFV3IKo/oZggbFrCQfgs6oapwwcHdD7e61IaUs6P5PiI5puJn
	 1ayUA9Pnuho/94wv4ZG8jJgkwqM64ibge97F+kBszLZc+HnsvUgF2J/xut2VDdgVMy
	 2Or4AdjzBWIBg==
Date: Wed, 11 Jun 2025 12:07:17 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: dmkhn@proton.me, andrew.cooper3@citrix.com, anthony.perard@vates.tech, 
    julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, 
    sstabellini@kernel.org, dmukhin@ford.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 2/2] xen/console: unify printout behavior for UART
 emulators
In-Reply-To: 
Message-ID: 
References: <20250606201102.2414022-1-dmukhin@ford.com> <20250606201102.2414022-3-dmukhin@ford.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 Jun 2025, Jan Beulich wrote:
> On 11.06.2025 02:07, dmkhn@proton.me wrote:
> > On Tue, Jun 10, 2025 at 10:21:40AM +0200, Jan Beulich wrote:
> >> On 06.06.2025 22:11, dmkhn@proton.me wrote:
> >>> From: Denis Mukhin 
> >>>
> >>> If virtual UART from domain X prints on the physical console, the behavior is
> >>> updated to (see [1]):
> >>> - console focus in domain X: do not prefix messages;
> >>> - no console focus in domain X: prefix all messages with "(dX)".
> >>
> >> While, as indicated (much) earlier, I can see why omitting the prefix
> >> may make sense for the domain having input focus, ...
> >>
> >>> --- a/xen/drivers/char/console.c
> >>> +++ b/xen/drivers/char/console.c
> >>> @@ -740,7 +740,17 @@ 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 */
> >>> +            char prefix[16] = "";
> >>> +            struct domain *consd;
> >>> +
> >>> +            consd = console_get_domain();
> >>> +            if ( consd != cd )
> >>> +                snprintf(prefix, sizeof(prefix), "(d%d) ", cd->domain_id);
> >>> +            console_put_domain(consd);
> >>> +
> >>>              nrspin_lock_irq(&console_lock);
> >>> +            if ( prefix[0] != '\0' )
> >>> +                console_send(prefix, strlen(prefix), flags);
> >>>              console_send(kbuf, kcount, flags);
> >>>              nrspin_unlock_irq(&console_lock);
> >>>          }
> >>
> >> ... this, aiui, is a behavioral change for the non-dom0less case, where
> >> Dom0 output will suddenly also gain the prefix. Which I don't think is
> >> wanted: Switching focus between Xen and Dom0 should remain unaffected
> >> in this regard.
> > 
> > This change ensures that dom0 traces aren't mixed with domU traces when domU
> > has input focus, or with Xen traces when the administrator is in the diagnostic
> > console.
> 
> That's what the description also tries to describe, yet I still regard it as
> a behavioral regression in (at least) the described scenario. The hardware
> domain presently not having (d0) prefixed to its output is deliberate imo,
> not accidental.

If we only consider the classic dom0 and dom0less usage models, then
what you wrote makes perfect sense. In the classic dom0 case, it is best
for dom0 to have no prefix, which is the current behavior.

However, things become more complex with dom0less. As we have discussed
previously, it has already become desirable on both ARM and x86 to align
on the same behavior. During our last discussion, the preference was to
add a '(d0)' prefix to clearly differentiate output from dom0 and other
domains.

Up to now, we could easily detect the two different cases depending on
the boot configuration. The problem arises with Denis' patches, which
add the ability for dynamically created guests via `xl` to access an
emulated NS16550 UART that prints to the console. Because these guests
are created dynamically, it is not clear how we are going to handle
this case.

If we follow the dom0less preference, then we would need a '(d0)' prefix
for dom0. If we follow the classic dom0 model, then dom0 would remain
without a prefix, and the new domUs would have a prefix. This would
cause an inconsistency. However, this is what we have today on ARM with
dom0less.

If Jan feels strongly that we should retain no prefix for the classic
dom0 case, which is understandable, then I believe the best course of
action would be to change our stance on dom0less on both ARM and x86 and
also use no prefix for dom0 in the dom0less case (which is the current
state on ARM).


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 19:29:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 19:29:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012121.1390656 (Exim 4.92)
	(envelope-from )
	id 1uPR88-0002kt-LL; Wed, 11 Jun 2025 19:29:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012121.1390656; Wed, 11 Jun 2025 19: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 1uPR88-0002km-Io; Wed, 11 Jun 2025 19:29:00 +0000
Received: by outflank-mailman (input) for mailman id 1012121;
 Wed, 11 Jun 2025 19:29: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 1uPR88-0002kg-5d
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 19:29:00 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20614.outbound.protection.outlook.com
 [2a01:111:f403:2408::614])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5094a5a8-46fa-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 21:28:56 +0200 (CEST)
Received: from BN9PR03CA0233.namprd03.prod.outlook.com (2603:10b6:408:f8::28)
 by CY8PR12MB8300.namprd12.prod.outlook.com (2603:10b6:930:7d::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.35; Wed, 11 Jun
 2025 19:28:50 +0000
Received: from BL6PEPF00022572.namprd02.prod.outlook.com
 (2603:10b6:408:f8:cafe::c7) by BN9PR03CA0233.outlook.office365.com
 (2603:10b6:408:f8::28) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Wed,
 11 Jun 2025 19:28:49 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL6PEPF00022572.mail.protection.outlook.com (10.167.249.40) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Wed, 11 Jun 2025 19:28: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, 11 Jun
 2025 14:28:48 -0500
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 Jun
 2025 14:28:48 -0500
Received: from [172.26.5.4] (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 Jun 2025 14:28:48 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5094a5a8-46fa-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=wBcoXqJ30zFgG2/6fjC8ss1VQTV38mpa9z8bXH+xuuWd4R/4t7laOvEkFxRFda8Cr3atIfDZE7eDeJUrYPkBW9SQ2CyjdlIJd7LVcNHIjsgPanQiBi4385fNt5+Ejvh+h4ZXh09OjPuRQledZQ2A+p5ztniTyC/jqu4CHrXh3fOZW08YR7Fc+dWckHOsIOS7Muq4cy0VIVfEziJVDkpuBdgFsKGB9NxP2HH19w5fryeGO4Q+SI3tPC9KhSJWmh/FBVrGkyLOnrg+64kcMeEgQoFICrDW9VufK9YDO/86dyybF/VJwflco9VaDk5QQH/95Hup5iaKw1gTZkmaKnqMxw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=hDN2m2wAUJcxcCZPJV6Hk6mHX4TefQKJ96kjWgv17JM=;
 b=ptHymneCSPic6a4laK2tG06blo/wKYirMnaXiNIS+sJIEX2Z5UFKsuiKwU6MvU/iueGtVtkdRxo22S4tgeUt6aw0grQI0JtoYiLfWCFG5Piotew8GbcVtxGv+bDzQe8gYSoO3MfxPnLm/xL7B13GXulXXkFZmn+SPe1t942yRo10g/HPdl91Uc/pdgYogAgDdxRDAGlGmWF5y/KGIO332O/82TtKZ5LON0Ax8eCLAk+Kp2J0ytLphXgApIuzHXu8sMenGI7XwlOzqp+7y4LWc9RzGLXIw9EYioaqBHp+VEs1WbwGycyY/6G+uxE5Ev/CoiYZr9z80MV+2N04UvOXEQ==
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=hDN2m2wAUJcxcCZPJV6Hk6mHX4TefQKJ96kjWgv17JM=;
 b=YgBynW1IEOIZZULqB62GNf8kpn1tM+6vdoB1zfRPL/NhlPd/6N33Fd9f7cC5xpRRY2Ask5/5iNFiUAlIQ1Q1ypZO+jJkIDS0bT0AjshMuFJpehfSHdWe+M3mklOZgdM75K9609B77cOGNb53uuUCu9gcy78n9o/Hcy4bIkeYn70=
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, 11 Jun 2025 15:28:47 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/5] vpci: const-ify some pdev instances
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
CC: 
References: <20250531125405.268984-1-stewart.hildebrand@amd.com>
 <20250531125405.268984-2-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 (SATLEXMB05.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL6PEPF00022572:EE_|CY8PR12MB8300:EE_
X-MS-Office365-Filtering-Correlation-Id: 54a9b369-c4bf-4108-9be1-08dda91e3123
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?bVp4NFcwczJObUtEUWc1MTBTQUtVVkllL0FRYzRTbGJLYWo5K3NXTWF6M21z?=
 =?utf-8?B?US9ieW9lN0FIcXI4WDJjS2JnVU1xaDM0Y1pTUWVybDN5WlhrOFVKdThBSWlU?=
 =?utf-8?B?ZGdUTHM0ZGZTck50MEtTVkZHK2ZubG9Dd1ViQmlSUk43MGIvN2VvOGhCNWUw?=
 =?utf-8?B?MjJUbzZGUWVDRjgwQ3pVSmNkbXRTVW1hZVBMZUVYS0Y3cnplQ2xnTnJFK1Bn?=
 =?utf-8?B?RUZBaVh0ZzBOaXJmQkpnVHZiTFdKWjRLMGluSElaa0xWaytLcGdRbUQ5R2Za?=
 =?utf-8?B?YUg4Z2NCeXEzZE9VUmx4b2VSVUE5dDQzOFk3d0JOWGxidEZaczlhdWw3b3pM?=
 =?utf-8?B?aGZuU1h2NUFXRUQwdDgxa1l5bUUxaEh3dTFHTHhlMXRoR1R2U3Fwek1MYld2?=
 =?utf-8?B?cmlMeWpLRmFXRkdiQ21VeEJva0Nmbk9EQkpxQzA2aVNUcEx2WjN4UzNMMHZj?=
 =?utf-8?B?NHp4YXVwME0wN1hwY0ppcW9peVY1S1lQS3hxN3o2dmtDS0lFYnZ5aXhTWFh2?=
 =?utf-8?B?WGxVRTVhZ3lFMTRick9nN1lFS2lja0t3azhZUzNKWkhCQkVPQUwvb3VtWmpm?=
 =?utf-8?B?YkdTcndJRTR0YWMwaFB2M0tXVUIyeFVjSjFnaVhuREh0QVlZRnF0TVIyRTJZ?=
 =?utf-8?B?amZPbno1ajYxdThwOXJGSVlSUktMK1o0RDlreXN1Vzd0aFpDaUt2L2RMdnha?=
 =?utf-8?B?cmVhcXBzVGJsZUdwbzlUSkwybEdLLzVVYWF3SHBhTkpXK1kreVdnZFEzWHRN?=
 =?utf-8?B?TUZEczlqZmNWbFdjS0dMYTBjMXkvMWM0UUo3TkhMLzE5RTFLNUF0N005UkMz?=
 =?utf-8?B?OEg2dlJCSW5VN2ttRy8yZmp2ZnUyMW4rRGJZM0YxU0dmT01mb1pJeHdJUmJJ?=
 =?utf-8?B?TlNLV2xOWFhHQ1FiOVNldnkxblJXTmxHSXF1WDNqNXd5bGwzRTdSRjhLQjQ3?=
 =?utf-8?B?cnhqZXNvS0EyMkkwNXplVi91d2pQd242SThwcUU2WU9NeUtpUGR4bjdtVis4?=
 =?utf-8?B?OGI1cnRkVWN3TzBSRDd1cWFBYzdScER6REZxeHkwUlZrc1lneis4VUtoc0N5?=
 =?utf-8?B?Kzc2Y1EySmZaOFFRTlIyL2dVcnMzaCthN0VIZ21VamZVZ2hhZ1VibG1zc1Yr?=
 =?utf-8?B?dVJLa3JhZFkzaGxZTXdDODlrenBxMy9sMjd6ZEhLclFaWEpQNk1OWU5BMDZs?=
 =?utf-8?B?YlFtL1hYbzJ5QTFvN2grSTQrQmFJNlQ0WGxPZEs3OExzd0pYVTF5Zmw3T1Jv?=
 =?utf-8?B?Z3Y3SFVZcEQ1b2hoZGxvNGRkM0MzQ1hMRmxqNXVaYlUxMVdFbE5lK1ArSkhj?=
 =?utf-8?B?eXN6emVUYnIvNVVFVFpzRTN0QlNSd0JlWDdSQXlpYjdTdG9kbXc1NERoTlky?=
 =?utf-8?B?Zk5oemE2aUxZL3pxM2crODhlcy9xRWRtSFFyallVbEdwQmVjR2w2ZlVKQ0Mr?=
 =?utf-8?B?b3dSV2NSS0xQS00zd2k3a0hxN2syNHZBblkvNzhnTWp0ZFJlZlc2MHBkSVhE?=
 =?utf-8?B?M2phRDNKSDg0bnM2VjRVYTRDdE5keEN5RjQ0V0tOdmxRbkFxNTZ6dnowRGNo?=
 =?utf-8?B?SUNVK1AzckRPTDhzV096UldEbVVBeHp6S284RVFObWlYZDFObjlqejdzUmp2?=
 =?utf-8?B?ZXlZbWFVa21ZaUxFa2M2MktaNVpib2FWcjdGSFBjQlBXSXc1VmllVlY1Wkk0?=
 =?utf-8?B?dytHejRkbVlGdEpjd2FIUEhLTzBXY1FFZmVYVlJBMHc0QTFMTnowbURLeEZD?=
 =?utf-8?B?bkxiZThlWWlLUURtRHpjUkFvUysrcHBPT0lPcmlLOExzNFNQcVo0YmthNXcz?=
 =?utf-8?B?Q0ZzMklzN2ZuRCtOalNmYnZLS3AzbC9ROElOYktyZE5idXF1RFY0K3ZqaWVn?=
 =?utf-8?B?aWZHWlc1dUVRNFh0eFJqVjZZUTZCeWhrNHg2Z2UvME1NNjg5dFp5QzZJMHhE?=
 =?utf-8?B?QnFhZXRsY3JEaUJ6bE1oeTFlUTFrZkd3aWxsUmxPbWZrZW1jZHMxNTZqT3pv?=
 =?utf-8?B?blBsWkpDMlZNcHZMclN0Y3lZNG1pRWIxVE00a3l4ZDV4TFRrUVdqaE5GNlFh?=
 =?utf-8?Q?CVbKjY?=
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)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jun 2025 19:28:49.4400
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 54a9b369-c4bf-4108-9be1-08dda91e3123
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:
	BL6PEPF00022572.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB8300

On 6/5/25 05:47, Roger Pau Monné wrote:
> On Sat, May 31, 2025 at 08:53:59AM -0400, Stewart Hildebrand wrote:
>> Since 622bdd962822 ("vpci/header: handle p2m range sets per BAR"), a
>> non-const pdev is no longer needed for error handling in
>> vpci_process_pending(). Const-ify pdev in vpci_process_pending(),
>> defer_map(), and struct vpci_vcpu.
>>
>> Get rid of const-removal workaround in modify_bars().
>>
>> Take the opportunity to remove an unused parameter in defer_map().
>>
>> Signed-off-by: Stewart Hildebrand 
> 
> Reviewed-by: Roger Pau Monné 

Thanks!

> One further simplification below.
> 
>> ---
>> This is prerequisite for ("vpci: use separate rangeset for BAR
>> unmapping") in order to call defer_map() with a const pdev.
>> ---
>>  xen/drivers/vpci/header.c | 16 ++++------------
>>  xen/include/xen/vpci.h    |  2 +-
>>  2 files changed, 5 insertions(+), 13 deletions(-)
>>
>> diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
>> index 1f48f2aac64e..e42c8efa2302 100644
>> --- a/xen/drivers/vpci/header.c
>> +++ b/xen/drivers/vpci/header.c
>> @@ -175,7 +175,7 @@ static void modify_decoding(const struct pci_dev *pdev, uint16_t cmd,
>>  
>>  bool vpci_process_pending(struct vcpu *v)
>>  {
>> -    struct pci_dev *pdev = v->vpci.pdev;
>> +    const struct pci_dev *pdev = v->vpci.pdev;
>>      struct vpci_header *header = NULL;
>>      unsigned int i;
>>  
>> @@ -283,8 +283,7 @@ static int __init apply_map(struct domain *d, const struct pci_dev *pdev,
>>      return rc;
>>  }
>>  
>> -static void defer_map(struct domain *d, struct pci_dev *pdev,
>> -                      uint16_t cmd, bool rom_only)
>> +static void defer_map(const struct pci_dev *pdev, uint16_t cmd, bool rom_only)
>>  {
>>      struct vcpu *curr = current;
>>  
>> @@ -308,7 +307,7 @@ static void defer_map(struct domain *d, struct pci_dev *pdev,
>>  static int modify_bars(const struct pci_dev *pdev, uint16_t cmd, bool rom_only)
>>  {
>>      struct vpci_header *header = &pdev->vpci->header;
>> -    struct pci_dev *tmp, *dev = NULL;
>> +    struct pci_dev *tmp;
>>      const struct domain *d;
>>      const struct vpci_msix *msix = pdev->vpci->msix;
>>      unsigned int i, j;
>> @@ -450,11 +449,6 @@ static int modify_bars(const struct pci_dev *pdev, uint16_t cmd, bool rom_only)
>>  
>>              if ( tmp == pdev )
>>              {
>> -                /*
>> -                 * Need to store the device so it's not constified and defer_map
>> -                 * can modify it in case of error.
>> -                 */
>> -                dev = tmp;
>>                  if ( !rom_only )
> 
> You can now join this with the previous if, and reduce one level of
> indentation:
> 
> if ( tmp == pdev && !rom_only )
>     /* comment text */
>     continue;

Will do. I'll plan to keep your R-b tag for v2 since this is a trivial
change.


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 19:34:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 19:34:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012131.1390666 (Exim 4.92)
	(envelope-from )
	id 1uPRCx-0004Np-B8; Wed, 11 Jun 2025 19:33:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012131.1390666; Wed, 11 Jun 2025 19:33:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPRCx-0004Ni-7I; Wed, 11 Jun 2025 19:33:59 +0000
Received: by outflank-mailman (input) for mailman id 1012131;
 Wed, 11 Jun 2025 19:33: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 1uPRCw-0004Nc-HV
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 19:33:58 +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 044c273d-46fb-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 21:33:57 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3a4f72cba73so977706f8f.1
 for ; Wed, 11 Jun 2025 12:33:57 -0700 (PDT)
Received: from [192.168.86.29] ([90.250.112.104])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a53244df34sm16459878f8f.71.2025.06.11.12.33.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 12:33:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 044c273d-46fb-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749670437; x=1750275237; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=5JsoGL62RQJ9r2fyOteGK+drFZ6jycFYnsWD2toOcmc=;
        b=COC73TujK+w5zp3KtTb96QoQ9FnGQM4wAwIwCB43YfWyPeqc/AzXEQTscPb60NvoDF
         2237yoDvzyMSoGTFCxDt0tBCSPG6VonEZYfaClvql12kNgFDA4TZQ69d6j4BBilsUDAA
         gRGtC/OaV4Z5Sn+JLzUQt0jVK7yuJ3ZgE37es=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749670437; x=1750275237;
        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=5JsoGL62RQJ9r2fyOteGK+drFZ6jycFYnsWD2toOcmc=;
        b=FLHpqDP7JNhSSG1YlYViMfHRIsKywQvr1PkSH3WEw1AlNfG8Buqg6YoohKprofZiSr
         alDEyYlxHSncRpwx+2zMmjZYYKkwGRKCI7r7nDXH9CM3y+h8wzcX0RXMg7BBR1SBIRb8
         LxL49tTlGwarXbRVH5eGngCnKczSVg+OL/i8TMG9GKo/bSSR0nMpNMAkD7jrxH4kAMjn
         AbiSVzYA/Z3tVptOiO2RxHf4727XWTf7o8VZw9TFv3lAzSABp+N4ALWMKm7RTgXB/MQ+
         SK8cacX5QmbZY0ymBLfGKHvBewHrZpa5Kz+n1gLIf8rjGVXSQi0wrTXJLMtiKsVhqPBy
         NEug==
X-Forwarded-Encrypted: i=1; AJvYcCVJRCk4wFXFkV1r4F8MCGsUrsLMww+wpXpYsvyrCPGSxdPjnxqh1Wn/B1B3yTrrAsUYZEui2m5iMxU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxmC7NiX3IhEr/aSQg1RBxDFNa/agL+u4LReBMvXWwsb+O/K6rk
	V+voN4gJggYDiqD2ajsz81cm9G2WlRhuz54tnj6L/A+l9v46W4yAQJy4ElLMWPDUomQ=
X-Gm-Gg: ASbGncv/6DiQYg23eLW/N3c/dGcMj5XOcs+hZGcNukzTp8CVNH0kb4Cm2tCSSYcLt3u
	UCx1XEfiVlTLXkEWWyDBh/PMwp4xHyyCKA9DIzu0qfMDtVXRYWCR7gL93txV0WCQXAiX0CrzbkE
	TXYV2HRakhC3cCLh/9aPBsa6DLzIrcdfv4TLOzY9VUOau9GhsjhPywjYXjKJSdNyXWkjyYE2oUo
	X7vHh+glFBQMmVvDQ9XsBBhMjQ8erlNyJclzq4z7BL11q48uVtXM6Tf3a04e981bsGOVL4eShsF
	gtuEW7xnQJnS0bF+tNzoj8/39binzrJ4F58XVbAIuHvspAgqevaqy4jPMFZyoriN9UcVHsN/yDY
	=
X-Google-Smtp-Source: AGHT+IHttYsJIehol+ehwjyF1O6UWf9/PtbB2L86L8sJLX+8NO9ZJk9ZM5jYrAPlidmv+Rb3qRHTJQ==
X-Received: by 2002:a05:6000:178d:b0:3a4:da0e:517a with SMTP id ffacd0b85a97d-3a5608135aemr524805f8f.23.1749670436553;
        Wed, 11 Jun 2025 12:33:56 -0700 (PDT)
Message-ID: <8e34ac22-d05b-4ef3-9e31-6e5663cc1dc5@citrix.com>
Date: Wed, 11 Jun 2025 20:33:55 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 6/8] pdx: introduce a new compression algorithm based on
 offsets between regions
To: Roger Pau Monne , xen-devel@lists.xenproject.org
Cc: Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250611171636.5674-1-roger.pau@citrix.com>
 <20250611171636.5674-7-roger.pau@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: <20250611171636.5674-7-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 11/06/2025 6:16 pm, Roger Pau Monne wrote:
> With the appearance of Intel Sierra Forest and Granite Rapids it's not

s/not/now ?

The problem here is that it's very possible to get such a system.

It might be worth nothing that SRF and GNR are socket compatible, in
Birch Stream platforms, which is relevant to why they're similar in this
regard.

> possible to get a production x86 host wit the following memory map:
>
> SRAT: Node 0 PXM 0 [0000000000000000, 000000007fffffff]
> SRAT: Node 0 PXM 0 [0000000100000000, 000000407fffffff]
> SRAT: Node 1 PXM 1 [0000061e80000000, 0000065e7fffffff]
> SRAT: Node 2 PXM 2 [00000c3e80000000, 00000c7e7fffffff]
> SRAT: Node 3 PXM 3 [0000125e80000000, 0000129e7fffffff]
>
> This is from a four socket system, with each node having 256GB of memory.
> The total amount of RAM on the system is 1TB, but without enabling
> CONFIG_BIGMEM the last range is not accessible, as it's above the 16TB
> boundary covered by the frame table.
>
> Note that while the memory map is very sparse, it won't be compressible
> using the current algorithm that relies on all ranges having a shared
> zeroed region of bits that can be removed.

", it couldn't be compressed using the current PDX_MASK compression
algorithm, which relies ..."


>
> The memory map presented above has the property of all regions being
> similarly spaced between each other, and all having also a similar size.
> This allows to compress them using the following formula:
>
>  pdx = (pfn % offset) + ((pfn / offset) * size)
>
> Where offset and size are two static coefficients calculated at
> initialization.
>
> Obtaining the optimum offset and size coefficients is the complicated part.
> In this patch I introduce two different algorithms, a fast one that works
> correctly when the offset and size between ranges is mostly equal.  If such
> fast algorithm doesn't work, or the resulting compression is not enough to
> avoid truncation of the maximum usable page, it's possible to attempt a
> brute force approach for calculating the coefficients.  This is also
> implemented in this patch as the slow variant.  I've attempted to restrict
> the number of iterations in the slow approach so it can exit early if no
> better coefficients can be found due to the input constrains (minimum
> region size).
>
> The patch here focuses on introducing the logic to calculate the
> compression coefficients, plus adding a unit test to exercise the logic
> easily from user-space in order to test different layouts and possibly
> improve the generation of the coefficients.  The added unit tests only
> covers the newly added compression, but could also be extended to cover the
> existing PDX mask compression.

Is it possible to split out the userspace harness into an earlier patch,
and e.g. do some token testing of PDX_MASK ?

That halves the size of this patch.

>
> Note the translation functions (pfn to pdx, maddr to direct map offset),
> are not implemented as part of this patch, an identity set of macros are
> added to satisfy the build requirements.  The patch is already long enough
> without those.
>
> Signed-off-by: Roger Pau Monné 
> ---
> We can discuss whether we want both the fast and the slow variants.  The
> slow (brute force) was added as a result of me playing with weird region
> layouts where the fast one didn't manage to compress, or the resulting
> coefficients had a poor compression ratio.  However at this point the
> slow variant has only proven helpful in synthetic cases, I haven't (yet?)
> seen a real host memory layout that would benefit from it.

I'm going to hold off on opinions until I've read the rest of the series.

One question through.  Can we round offset up to the next power of two,
so we can replace the divide with a shift?

size is not a nice power of two, but I guarantee you that hardware is
not doing this routing with a divide.

It would result in some holes in PDX space, but it is almost certainly
faster.

> diff --git a/tools/tests/pdx/harness.h b/tools/tests/pdx/harness.h
> new file mode 100644
> index 000000000000..3d31cf488daf
> --- /dev/null
> +++ b/tools/tests/pdx/harness.h
> @@ -0,0 +1,73 @@
> ...
> +#define sort(elem, nr, size, cmp, swp) {                                \
> +    /* Consume swp() so compiler doesn't complain it's unused. */       \
> +    swp(&elem[0], &elem[0], size);                                      \

(void)swp;   ?

> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 93ebfc29635e..e71908b99c14 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -258,7 +258,7 @@ void __init init_pdx(void)
>      unsigned int bank;
>  
>      for ( bank = 0 ; bank < mem->nr_banks; bank++ )
> -        pfn_pdx_add_region(mem->bank[bank].start, mem->bank[bank].size);
> +        pfn_pdx_add_region(mem->bank[bank].start, mem->bank[bank].size, bank);
>  

I'd suggest plumbing bank down in a previous patch.

> diff --git a/xen/common/pdx.c b/xen/common/pdx.c
> index 7d14100224fe..f2cf60bbc3f8 100644
> --- a/xen/common/pdx.c
> +++ b/xen/common/pdx.c
> @@ -21,6 +21,15 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +
> +#ifdef __XEN__ /* For building the file in user-space. */
> +
> +/*
> + * Use a define for the static keyword, we want to export some otherwise static
> + * functions for the unit tests.
> + */
> +#define STATIC static

Most unit testing gets around this problem with the test harness itself
doing

#include "path/to/pdx.c"

If you do this right, the only thing needed is some #ifndef
_TEST_HARNESS around the includes at a the top.

> +static int __init cf_check cmp_node(const void *a, const void *b)
> +{
> +    const struct pfn_range *l = a;
> +    const struct pfn_range *r = b;
> +
> +    if ( l->base > r->base )
> +        return 1;
> +    if ( l->base < r->base )
> +        return -1;
> +
> +    ASSERT_UNREACHABLE();

I'm not sure if this is appropriate.  It's perfectly reachable if both
->base's are the same, and it may interfere with the inlining heuristics
for sort().

What you mean is "there shouldn't be two nodes that look like this", and
I'm not sure that the middle of sort() is the place to check this properly.

AFAICT, The real property you want is "len[i] && base[i] + len[i] <=
base[i+1]".

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 19:46:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 19:46:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012137.1390676 (Exim 4.92)
	(envelope-from )
	id 1uPRPK-00066q-Cx; Wed, 11 Jun 2025 19:46:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012137.1390676; Wed, 11 Jun 2025 19:46: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 1uPRPK-00066j-9k; Wed, 11 Jun 2025 19:46:46 +0000
Received: by outflank-mailman (input) for mailman id 1012137;
 Wed, 11 Jun 2025 19:46: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 1uPRPJ-00066d-3Y
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 19:46:45 +0000
Received: from DUZPR83CU001.outbound.protection.outlook.com
 (mail-northeuropeazlp170120005.outbound.protection.outlook.com
 [2a01:111:f403:c200::5])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cc8a9831-46fc-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 21:46:42 +0200 (CEST)
Received: from AS4P189CA0046.EURP189.PROD.OUTLOOK.COM (2603:10a6:20b:659::11)
 by AS4PR08MB7604.eurprd08.prod.outlook.com (2603:10a6:20b:4ce::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.19; Wed, 11 Jun
 2025 19:46:39 +0000
Received: from AM3PEPF0000A797.eurprd04.prod.outlook.com
 (2603:10a6:20b:659:cafe::2d) by AS4P189CA0046.outlook.office365.com
 (2603:10a6:20b:659::11) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.19 via Frontend Transport; Wed,
 11 Jun 2025 19:46:39 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 AM3PEPF0000A797.mail.protection.outlook.com (10.167.16.102) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.15
 via Frontend Transport; Wed, 11 Jun 2025 19:46:37 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com (2603:10a6:5:1c::25) by
 AM8PR08MB5554.eurprd08.prod.outlook.com (2603:10a6:20b:1c5::24) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.18; Wed, 11 Jun
 2025 19:46:06 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668]) by DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668%2]) with mapi id 15.20.8813.024; Wed, 11 Jun 2025
 19:46: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: cc8a9831-46fc-11f0-b894-0df219b8e170
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=ZXqLA9wYLzo/reL6IeHI0AiBwsJycliBgHgcBz2UXL0y5Sandx21Ljxe82XSr4QrHTG7kVoNC2QHSl5/sbs9IiJhijqWQh8ENNl+0UK6bQqKPFvfo5nO7iFD2vDTRYSuhWZudlcrMxOiVleJnyWDrt+MJa/FvIIVpYyAU/OpCawm6FUwmAHbRCmBbJ08rm4+exvhoVytr7M4FX0VHJ7wtAfE5Ot6zfeZ3CjNgSyY0QEDgqWpKyZfhc4qAFHP9ZcdEUpzY1IE8wYTLoyChUU5WkYa7ZJQH0z4d5isjfWQ2kqS1qzeZ56gw+j6o/VUNKUkF+FywyfFvHF2Id9Ak1cJcA==
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=nWX0B3lXcheQh3GEV+XThXx5FUm+EHnK9SaHRi2SvT0=;
 b=Jpy2I9g+XpbxhvgDRAXDI+6DIfn0JJUZ4BMiKsEnyR7l8Gc0pX6KqzaAAaIttEbkMBoljotuHAihJTkXXPsuvbztF1j7jOXr3FNnOpsFGh9QZRvN27PNFltubFaeAUZT87aG7G8J1UH3TYXPfL+o5uqLWd26rmtWpKQe+PpKLQXK6U3y79vs+8+F441UNNEM5Te9ut1wG+l3Uh9YwlRcPzPioa5Z9C3p2WYMiD4gjhiFIX6ItiBmqBQUWy6NJ4WTbkBPDfa5AlpIBs91ogCXHzcxqHQ+EbSHprQAClqpAdgpQn7+7f23LJ/Zt73QJD8PQ1Fj2w60QqXOh/w6xCY+Hw==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=amd.com smtp.mailfrom=arm.com; dmarc=pass
 (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
 (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=nWX0B3lXcheQh3GEV+XThXx5FUm+EHnK9SaHRi2SvT0=;
 b=cG1UcZD4YPjiDq+XRzH2lYUhaXTIsXJq3j8q/9wOv7MXn6uzXXa9cHnoxWDHCGbRNiVqYOwMcTiFvaIlS9R2FhkUE65H2Klv0OuMUdy3D8SRdQszLSYVRefNGmv9xhEu3jItSPMD0J6hvP9p3Bvl6ICSYeTK2nAiWJhe5Ccw0TE=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ywZXHFs9ooPSkiGii+rwXnghUCQXnh2D4cybb8WSHVZum/hilnHEtgVVG2KlT3fC9oxcAqcvq2HthWd63IE7SjMcH+MfIgVD19jRH5ILUt9ASj37mLh9sNDuZhoI6FmB2NL/I0udBqGj2nxRFkfHwmHq0q459WZc09mzMHo0mnDOihd6+LnppRSrsAfJtF6pqfAY5B/3w8eeJmrvT4cguix+A2SG8l9aDly0UGzqjRNKvGVV/t/CiQMASqCPUKFWXJiGVeyyllJkZjwxR/y8hQbDn/UUtp2e12huVhamy5Xle0iz/1Oa1+icfc9oPUtUBDwza84PvgaqLxedlkT7Fg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=nWX0B3lXcheQh3GEV+XThXx5FUm+EHnK9SaHRi2SvT0=;
 b=gGYQvTkXFic1rqslZVlgFoy79ac4ue33gOtFEvQ6T+shA5W1If3hmN6DJFnbvmuiu4SykK1XpMk0y+liUbFkYkn8PzKKlK3RBVH5bg93t+yhVQxy7NteWN1xab+tkoZqUTb0xRt8oOBSSXnqEPzlCt9+fow9FOcyseYa0lgyPTvATIc63Fa6y2BjP4AiADaEHCUkuUT09a3k/A4Hxbtv+3gN6A2sfRbqwkK2bkmqoWvHtkh+EtrGqzDuVYL5ICdnW5/vdAUzexVeGy4ixD9JjINJ2Rc1jk7K+odKarV7YBzRsmlnBdsgg2IfrbweWXKym5NStFsMch7SwG5Z9q/Dwg==
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=nWX0B3lXcheQh3GEV+XThXx5FUm+EHnK9SaHRi2SvT0=;
 b=cG1UcZD4YPjiDq+XRzH2lYUhaXTIsXJq3j8q/9wOv7MXn6uzXXa9cHnoxWDHCGbRNiVqYOwMcTiFvaIlS9R2FhkUE65H2Klv0OuMUdy3D8SRdQszLSYVRefNGmv9xhEu3jItSPMD0J6hvP9p3Bvl6ICSYeTK2nAiWJhe5Ccw0TE=
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 v3 3/6] arm/mpu: Move domain-page.c to arm32 specific dir
Thread-Topic: [PATCH v3 3/6] arm/mpu: Move domain-page.c to arm32 specific dir
Thread-Index: AQHb2t5UdjEFY0/YQEOuciLTdcs6S7P+XQ+A
Date: Wed, 11 Jun 2025 19:46:05 +0000
Message-ID: 
References: <20250611143544.3453532-1-ayan.kumar.halder@amd.com>
 <20250611143544.3453532-4-ayan.kumar.halder@amd.com>
In-Reply-To: <20250611143544.3453532-4-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.600.51.1.1)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB7PR08MB2987:EE_|AM8PR08MB5554:EE_|AM3PEPF0000A797:EE_|AS4PR08MB7604:EE_
X-MS-Office365-Filtering-Correlation-Id: beb33a54-d166-4055-1d1a-08dda920adf9
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?w65eArWTHkHjiDSDc35MHtmrF2an4IKImlvh3yVDSdFnnOrm3c+uqWp5b0ER?=
 =?us-ascii?Q?Fazg4d2dUmTaC3AcMq3ciZi0GpSPY2okMumhAU4nqiVn7poPu9x7Xm7eMUgC?=
 =?us-ascii?Q?mtV3B7739uOuWf2/Dle1+Henxc9iYzbY0Q6jmIKKdXiJcrGunvIeEIxDX6OZ?=
 =?us-ascii?Q?u/s26w7GQHC2S/t9Doj+Z3AI0a40qQ/2PEOh3hxJ3uv4xUoQv4WpnvPOdumx?=
 =?us-ascii?Q?D5YrSHkURlHBfa1MC0CSKHYHGx6r5+A45JbxrnigLeCEH8wCzQDZNPgYLDjc?=
 =?us-ascii?Q?FZ8Udw0S1T63qFQH8RXwniDnc6jyB5phsgNSn29kPyJ0t4k62wGqCJHddYn1?=
 =?us-ascii?Q?XhNciGqshDaQkEiIsIfkIj8wSoRmfgOq6QTVUDyL4PblpcwVeA1GxdHnctEJ?=
 =?us-ascii?Q?5DgyuBB0OyQ5Vu595TTslHIGLPD4dlY+1t0N+7VNwcvZYcU59mzj2UWTSyjK?=
 =?us-ascii?Q?/Ovu2fYsHbipB+UCujfkqxmbF/RgBRoqmG8sBem3NAbjphHodyqkc3epogeR?=
 =?us-ascii?Q?SkBkEU6sEptEdA5RxC6Tlg1Ot4+jHIPzeP3tphHkzoMedhC9hoeNQAAcT4T8?=
 =?us-ascii?Q?3N//PDAH3FdJN7rLxK5eBX/2Ax+xBEhD3F5CNPHJbFTfjPixdcP7PHSpHdQG?=
 =?us-ascii?Q?NgTSCAu+blVcD7/3PHMOT/Qb7mBpNmcXSjZlJls84h7lr4q8jSsTWKlGsN2u?=
 =?us-ascii?Q?ioK1V9d30StFs85YB4GhoMj/TX7i1O5TytBHdx2RwTgkbcWGE3RNMqLhoOA2?=
 =?us-ascii?Q?/tZpmc9NT5imzsFFc46rjsARl2d11xdDm9AoWsxD7N1XqyCk3WHTg8WbhRJd?=
 =?us-ascii?Q?L/znwYiilAC0FUCwx7myqSIlzBcgfxBc1YBj07NQpZKwfmLq+12Z4e5rUZEC?=
 =?us-ascii?Q?FD3a3F/o8YFJh9/3NsxTjveElpB+daIMxbV+xWDjzIya3RBgHbKj6Wy6rLVt?=
 =?us-ascii?Q?niVlXPEMtSBCv+sMAJ9VVg528JZGo0xMCNDv6Ooji0PkKYls4o6jAHoBfNwa?=
 =?us-ascii?Q?yxpLfJEmxBoL1z6HYXk9KfyBpLfhApaWFxL9DWPmq2BYViUnkMwIHCtGWjmz?=
 =?us-ascii?Q?tfHs+ShIqRoxoY7Qtv3h2v43YhKwdVerDB0ckRVawqPiJOXJUjwWFdNA2UCi?=
 =?us-ascii?Q?m+n3J8n9xxzRcsTGRjaqCESb9hyanDD9K7IEx3uPohW2lEZZC2Bl0OiwEaa8?=
 =?us-ascii?Q?DDYE8/FWEBLZeYcYQilZLgZUAJqs6eVvTRQJGxaIapA71cwOcKbT6ncxK7r+?=
 =?us-ascii?Q?9uGPepRKDkWETiakbP5Wi1YmHlt5jiXxtydIbB6KSZTKcH2LUd47PG+EZDcy?=
 =?us-ascii?Q?QtNs/Js3VeOjViEPGAXQviDDrIwRLbyKmCcTyNJcdA5Gs7vUNNXqP29fYcex?=
 =?us-ascii?Q?Hil0o5DxLz8a6LBICJBjg7Ny8OVwqZJq1+ouFDreHc6DwLGQC/qB8SrNmBFh?=
 =?us-ascii?Q?mdSvMrK1fmE=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB7PR08MB2987.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: <55479781A4D6FE44A0AEE4467776B921@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR08MB5554
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AM3PEPF0000A797.eurprd04.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	cb09b3f0-6a4e-4dec-c93d-08dda9209add
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|35042699022|14060799003|36860700013|1800799024|376014|13003099007|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?oh2nGsqR6lQnOkQE8b0k0a2dwIIQV3X0jQUoJhMOJBelF0Zjrx+sduZ2suiV?=
 =?us-ascii?Q?RbG9wzlODldCW/tH9tF2yEGlPUVoczjvREGaulCQv3AA35OnG8hEepy/VWJe?=
 =?us-ascii?Q?zlxs5AyWXYv41WuL5PtbQOBPhV/4LWOXAxCDSaQ0kBoc/Af47WUbOwTIi0b/?=
 =?us-ascii?Q?6KbZA8NHLp9I7yLzvKrN+kpKArnFt8oyDA4Vs98YnX4g1+gmytqbmca27jbM?=
 =?us-ascii?Q?+NlGo3EoK9j6Fe3bB/27SWoSMhqAww7uSyuTTiMNGmwudWXt/gXmk5vwbFdi?=
 =?us-ascii?Q?N/oz9vgRTs0GnXTlUQSreXBJexOOIwKiqg+mZi2DP9eK6w9Kro+zVStFQFMA?=
 =?us-ascii?Q?rJLXCO4lFIEFv/+/VfGQxDVdnkVsCSBvMn9uPgW4vIUUko6K1uWhDCsaRjtc?=
 =?us-ascii?Q?j6wKtI/q5vpHuUyNO7mhbn1yvhpTfLbwWMAHWVRC/5LFDRy+tv86JCdvBnvw?=
 =?us-ascii?Q?zZZPw7ogxrQNT1jPZihoeskTUIMHUKO5LP5w50Qvcw0A+oH38UqJMKlOOOfM?=
 =?us-ascii?Q?iGSrDyGz8rMJoEIV6HCceg4/ZleaIK5vxSNvWtOKdEhd6DFsa1uMPFrix73/?=
 =?us-ascii?Q?MNrTHDM/HoM/GY65TXcCrnci+R66oAYpaFTDro1ZFS9zaw3inGME15qlB/70?=
 =?us-ascii?Q?Q26VYitk6wRTIKYSqzKocEiIrZOJUwuHSEk1g0sUx2y8QDK3xAp5TDr5K87u?=
 =?us-ascii?Q?B08itJQmGylOv8WQR2kKeyu/hDNH8tDR0gkx4ZyilHnNXV7e/N0lbVqQJIL4?=
 =?us-ascii?Q?hkycU2xTBk+IcDunm7z2E29aSc4Y7RnaNSv/gmp8bWYWda0lufd/07+irBIt?=
 =?us-ascii?Q?BiLpTBdKBLK/y6HejDTTtFce3bW4FA80fjk7tLeSht1qVwvegRaLIduDYC/7?=
 =?us-ascii?Q?XI5WYofxqtX0hJzhcnvYslDqBDtTwO5X2aCrNySzS45Uj8y92rmMR5hFnKCP?=
 =?us-ascii?Q?f4xJsqhSL5gaHUCo3/OkKoExOiJw4K+T13GAeao2BqaEKXzGxle2Mo9YKkBq?=
 =?us-ascii?Q?jVzH7YHHewIgOwbOvTcGBivlTryd5vG7pp3cc2l8qP5ww9lgLmq8vdVXDe6D?=
 =?us-ascii?Q?HrTcIh/RJOs2N5LwhxHTHYKPn+gPVaCIgfCWG70oE6O9WxR0SuOG4DJfEVCV?=
 =?us-ascii?Q?wm3Uc8X9zfdPn0HqbMOrFBpCsQo2J3E+wtuRG6uyIQhBrNZxyHsqtypjl7NZ?=
 =?us-ascii?Q?r7G+7HgoDRREzPvbINykAZW5KzPjMoAf4o4JjudXkXDDx3vO2ftnTiFXf/wQ?=
 =?us-ascii?Q?7qAfS7eIy1yypc3rv9MtWzYNfcmsxyrLEuDXDYLRqSGFpWYrBgOoSnSuhXDT?=
 =?us-ascii?Q?BuY/m6mhUIiV5FaWLRzmkgCDnqT45oUXDJqabM04Z9QzVHgDo0iVyaCsswIx?=
 =?us-ascii?Q?i3T26RYuOdIl7wNBXpYNSqZcb7LTJMrZoSLQ36I8gxTMY9SnZ/kWFA0ibAzv?=
 =?us-ascii?Q?+l2ECMHVRmc7k787zs99ZzSJ+ZgXh6Exfm5Q2KQ2grja97KJH2XwyQ=3D=3D?=
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(35042699022)(14060799003)(36860700013)(1800799024)(376014)(13003099007)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jun 2025 19:46:37.8288
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: beb33a54-d166-4055-1d1a-08dda920adf9
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com]
X-MS-Exchange-CrossTenant-AuthSource:
	AM3PEPF0000A797.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR08MB7604

Hi Ayan,

> On 11 Jun 2025, at 15:35, Ayan Kumar Halder  w=
rote:
>=20
> Create xen/arch/arm/mpu/arm32 to hold arm32 specific bits.
>=20
> Signed-off-by: Ayan Kumar Halder 
> ---
> Changes from :-
>=20
> v1..v2 - New patch in v3.
>=20
> xen/arch/arm/mpu/Makefile                  | 2 +-
> xen/arch/arm/mpu/arm32/Makefile            | 1 +
> xen/arch/arm/mpu/{ =3D> arm32}/domain-page.c | 0
> 3 files changed, 2 insertions(+), 1 deletion(-)
> create mode 100644 xen/arch/arm/mpu/arm32/Makefile
> rename xen/arch/arm/mpu/{ =3D> arm32}/domain-page.c (100%)

Uhm, why?

Arm64 is using domain-page.c:
https://gitlab.com/xen-project/people/lucafancellu/xen/-/commit/b28198d0007=
8991d4a6502e94c8779d84fec0120

Did I miss something?

Cheers,
Luca=


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 19:55:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 19:55:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012143.1390687 (Exim 4.92)
	(envelope-from )
	id 1uPRXr-0007oh-7R; Wed, 11 Jun 2025 19:55:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012143.1390687; Wed, 11 Jun 2025 19: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 1uPRXr-0007oa-3b; Wed, 11 Jun 2025 19:55:35 +0000
Received: by outflank-mailman (input) for mailman id 1012143;
 Wed, 11 Jun 2025 19:55: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 1uPRXp-0007oU-HM
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 19:55:33 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20629.outbound.protection.outlook.com
 [2a01:111:f403:2413::629])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 06ce5a29-46fe-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 21:55:31 +0200 (CEST)
Received: from BN1PR12CA0006.namprd12.prod.outlook.com (2603:10b6:408:e1::11)
 by CH3PR12MB9028.namprd12.prod.outlook.com (2603:10b6:610:123::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.35; Wed, 11 Jun
 2025 19:55:26 +0000
Received: from BL02EPF0002992A.namprd02.prod.outlook.com
 (2603:10b6:408:e1:cafe::29) by BN1PR12CA0006.outlook.office365.com
 (2603:10b6:408:e1::11) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.35 via Frontend Transport; Wed,
 11 Jun 2025 19:55:26 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL02EPF0002992A.mail.protection.outlook.com (10.167.249.55) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Wed, 11 Jun 2025 19:55:26 +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, 11 Jun
 2025 14:55:25 -0500
Received: from [172.26.5.4] (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 Jun 2025 14:55:25 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 06ce5a29-46fe-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lCdjCgi37SzLkFZTZpDxilUvp01UX2+HCp0GX73hoIpqV+8np7f5KxFBuOX67R6J3gEAUukTNP52fs/sekNCZroYVsUsakWOKKGoKClAWbMvXDvcesvu9dI8t6doh31Gl0Xvi5An41JFsVXNL1uifCaPra8d+1nPVo0lltPec82z/iXG04OcczyikQKwwx0Of8078WwSrirID1pkmbM9EQtS2epU0SAyLZqqtfcqCWkvpap78S5HQBBZe6BRym+SXwzPYvms24dObXb9rBUf2HX36Yv6DpGdvUmu1JP1rQVDCDfPRWOhgbXTBFE5MjpFwqz1iOd+FUMtGtEc8UpSzA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=lqDqO7m2gZiOVJMSEy0MJAlh7VWIlSB5xMSayXQlDBo=;
 b=mUyMTG75P9bZ13TGUl6GZK4LuO74EaZUreAhDrN4ojdBunMR9RPdX082DvB+dkqjNmYE51AYrI0E/UBQ9sPG8QWlMqi2Ru07C0q2KQ+UtXtC2GS6+x6Gi/ih3hLMUUnSfvg7MOzlhUTC61fROuVXCzpndTfp14Y+7qII3tL1IzG8DroGYqkiTVKsPzKe9FceKXMufvSmx8eFEMzKQfLdlO1wrVU17SSS45nItDaLk7gmsRTbKqmghtblC9H8cTVhmpFV3TQEDEtRmcCNjrOUbbFD7asL+wElZw4bAN+W5Y/2sLnlpnABupgz6JQzZrIVwKTaiQN4/wrz836GZl3qDg==
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=lqDqO7m2gZiOVJMSEy0MJAlh7VWIlSB5xMSayXQlDBo=;
 b=EIaUp+zqKMM9myk94UuXOEswC28/t8gdqhpYn1uu2ViP7x80MgmjBvr+K73VMyda3+uQe7mo8QFVC1n0iUT9njldMWC2EJA6qFkWYEfuPmL4qreef+GJFVYhhZ/kpJstmZj7Z2LiNSeL0nB4sjuxqu5jN2bRNAhP+P4zr2HbPZA=
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, 11 Jun 2025 15:55:24 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 3/5] vpci: introduce map_bars()
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
CC: 
References: <20250531125405.268984-1-stewart.hildebrand@amd.com>
 <20250531125405.268984-4-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 (SATLEXMB04.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL02EPF0002992A:EE_|CH3PR12MB9028:EE_
X-MS-Office365-Filtering-Correlation-Id: 0c17ee2c-2243-4372-596e-08dda921e8ca
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?bTdGMHphbXd5Y0xnYWc5azdwZURvM3N0TGdEamdoanZvVVRTVUtwNkM3SG5t?=
 =?utf-8?B?b3l5cUtHeFVYYW1uRExoSWRnRTNKcjZtVlJuWHBubzJwUXc1QTNEcjZBWFFo?=
 =?utf-8?B?SFpFQWQ1eDhHQXRRdDgyb0xrNjFLb0VQT3c1RjVDeTNIRU51bjJPVHdUOVJO?=
 =?utf-8?B?cTQwOXhYRFAwcVBuZkEzU1BFK0RMSjRJWkRDWWd1VUJmM3REVkNHTlpOQ3BZ?=
 =?utf-8?B?YmNnTGRtMkJFcDB1OWFyNFRVOFhzdDZGVko0MjFpaVlZY0JaRlJWMkNpWVhS?=
 =?utf-8?B?UGk2TWJ1S21zQVljOUtoRWRDaEQ1QWMxMG5rN2Rtekl5dzMxa0xyNG1TalVC?=
 =?utf-8?B?ZTFwS0liTHZnaU04b25uRXdEQ2lDSUkzK2ZoR1ZEZFk1VVA0TEl5Qmx1c0E3?=
 =?utf-8?B?SFVOMlFKSWo3R0hmdE5ydkVqck1yY0VESlFOWFEzNHgrTkIxSGV3SHZ1RmQ2?=
 =?utf-8?B?K1VhbXNMTXI1UGdmZ2NDVDBlVlE1ZnRPcGFBbXRMMnVtTXQrUDN2UDdlenlW?=
 =?utf-8?B?emNDSnBvYVRoQkk5Zm04UXExbnFvQnRGR29NcElYL2NOU3UyM0VNd0RYTllE?=
 =?utf-8?B?QkFyRWJnME15MDlsSHR4ZU84a3NYN3R4OWFRS3RqbVJLampUYzVsK0tFSkZL?=
 =?utf-8?B?VGJET2dwem5FOVFPTG01a1RGYXc4dVcvcE52ZTNFWXNYOTdCMTlhc2VoazVV?=
 =?utf-8?B?ZmxadWxkYWw1MFFxV0Z0ZWVRWndSaWRrZjU3WUNvdDRYVnN6SkJYM0tPYzc5?=
 =?utf-8?B?UXlvWThnRURKaVhLZnN2NXRxUUY5TEd2R2lGQ3JOSEoxZkNwazJVazNKcTRR?=
 =?utf-8?B?TlhrSncvdk5aMnRQMDJraThsMjZnSm5ETVdEc1czYzNKU3ZZdE0yWUJ2RG0w?=
 =?utf-8?B?cXhsbm9DYkFPckp0VnNRangzU3phY3lZWXdWMyt6ZU1kczhhS1VqUlFFMnhG?=
 =?utf-8?B?SzlkRHhVUkhvL1piU0hHZjVKbzMwcjVqV1NaNUlsTElOdTdGcE9KT3crSWE5?=
 =?utf-8?B?ektHQzNIVW83YlVTM3JKcUgrSzBUNjA5VDRnUXpZeWl0SFJhVzMvNTZsZEZQ?=
 =?utf-8?B?OWRicysxcTlvZFRFQ1NobHljekpCcTRnYW1ZOWZUV3VZdWw2YXQ3ODNMcnU1?=
 =?utf-8?B?NDQ5Ti9OZ25kcE5pdURTTktXa3hDbDMvRnM0RzhIK0E5SmtKWWFRUUt3MXBV?=
 =?utf-8?B?K0N1R2MyQVBnNG01bmdNTU9MTkRDRWl3dUNDenJGRmRRN2JPcE5rbng1Z29W?=
 =?utf-8?B?L1N0ZStKOGV4MnViM1h3TXgrMW8rVHFXTmRvbkFNN1Nrdzdha0p1SE11elJq?=
 =?utf-8?B?bUM1bmt5RDJLVHZOcEVDZC9sT0x6czZIcDFqb0JiZzBhUStDa25GbFhlODRj?=
 =?utf-8?B?aVo3clcrRDBoRE5ZUEZBVVl2K0RKTC9GRWFzNWpvbEZTUVBSdWZmallNSFNQ?=
 =?utf-8?B?MWxjMndwMWhLeVpxa2p1TFBFd0w1RzM4bG5GU0QrR2p0S1RsS3FhUUpvM0Y0?=
 =?utf-8?B?VG9pSEprT2JvaVFVcFlSR2J6K2pGeHd5WDNXOFY2TkYvSittdmxXUjBGbENU?=
 =?utf-8?B?UHRadVJqOHVEUEhsWS9ZQ2prTEF1SUo3YW9vWk54NTBEL1JvVG01b3N3Y0hV?=
 =?utf-8?B?U09UVlJSVWVLQWc0T0NocDJ6eUJacXBhOU5JRi9tQ3lPbWg0TG5tQUZrSDVY?=
 =?utf-8?B?ckdsSGFtNWJpU0llN3dvaU1VaXhnd1BBZUNGMXVJaGl0T2R6NlZPdmdnUHdP?=
 =?utf-8?B?Nm4ya0RmajlkbGViNmpEYzA0YWl3alBFUk1WQzFVVlJkVFJEWmVYNFB4ZjJw?=
 =?utf-8?B?dUl1ZkFYWEwxb1dUZ2ZoMXJGdXVmN2ZPNFBTT0dGek11U1RsMU5mQ2Uyb3Z6?=
 =?utf-8?B?UWlRaU1ySmtqVU1ia1U3cnVNUW92Y2RmT3FSQTBjRkgrNkl2aU9iUmdjQWl4?=
 =?utf-8?B?MTdhMHU3OGo0VFdsSVIzYVgrdTZieDdPU0JiblgySXRNNHhHVWliWHNhV0cr?=
 =?utf-8?B?a0UzL1dSa0RTbnJRN0NSUnhwSmhtNUY2OGpTNVo1eVIwaStKeGVsb1VPbHFk?=
 =?utf-8?Q?A5pch5?=
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 Jun 2025 19:55:26.0632
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 0c17ee2c-2243-4372-596e-08dda921e8ca
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:
	BL02EPF0002992A.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB9028

On 6/5/25 06:16, Roger Pau Monné wrote:
> On Sat, May 31, 2025 at 08:54:01AM -0400, Stewart Hildebrand wrote:
>> Move some logic to a new function to enable code reuse.
> 
> Like with the previous changes, it's helpful if you explicitly note
> that no functional change is intended in the commit message (which I
> think it's the case here).

OK, will do.

>>
>> Signed-off-by: Stewart Hildebrand 
>> ---
>>  xen/drivers/vpci/header.c | 56 ++++++++++++++++++++++++---------------
>>  1 file changed, 35 insertions(+), 21 deletions(-)
>>
>> diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
>> index c1463d2ce076..b09ccc5e6be6 100644
>> --- a/xen/drivers/vpci/header.c
>> +++ b/xen/drivers/vpci/header.c
>> @@ -173,11 +173,38 @@ static void modify_decoding(const struct pci_dev *pdev, uint16_t cmd,
>>          ASSERT_UNREACHABLE();
>>  }
>>  
>> +static int map_bars(struct vpci_header *header, struct domain *d, bool map)
>> +{
>> +    unsigned int i;
>> +
>> +    for ( i = 0; i < ARRAY_SIZE(header->bars); i++ )
>> +    {
>> +        struct vpci_bar *bar = &header->bars[i];
>> +        struct map_data data = {
>> +            .d = d,
>> +            .map = map,
>> +            .bar = bar,
>> +        };
>> +        int rc;
>> +
>> +        if ( rangeset_is_empty(bar->mem) )
>> +            continue;
>> +
>> +        rc = rangeset_consume_ranges(bar->mem, map_range, &data);
>> +
>> +        if ( rc )
>> +            return rc;
>> +    }
>> +
>> +    return 0;
>> +}
>> +
>>  bool vpci_process_pending(struct vcpu *v)
>>  {
>>      const struct pci_dev *pdev = v->vpci.pdev;
>>      struct vpci_header *header = NULL;
>>      unsigned int i;
> 
> Maybe I'm missing something, but don't you get complains from the
> compiler here about i being unused after this change?

No, i is still used in the error path.


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 20:22:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 20:22:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012156.1390696 (Exim 4.92)
	(envelope-from )
	id 1uPRxy-0003Zq-94; Wed, 11 Jun 2025 20:22:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012156.1390696; Wed, 11 Jun 2025 20: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 1uPRxy-0003Zj-6F; Wed, 11 Jun 2025 20:22:34 +0000
Received: by outflank-mailman (input) for mailman id 1012156;
 Wed, 11 Jun 2025 20:22: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 1uPRxw-0003Zb-HD
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 20:22:32 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on20618.outbound.protection.outlook.com
 [2a01:111:f403:2407::618])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cbe24f1b-4701-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 22:22:30 +0200 (CEST)
Received: from MW4P223CA0022.NAMP223.PROD.OUTLOOK.COM (2603:10b6:303:80::27)
 by DM4PR12MB7576.namprd12.prod.outlook.com (2603:10b6:8:10c::17) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.37; Wed, 11 Jun
 2025 20:22:25 +0000
Received: from SJ5PEPF00000207.namprd05.prod.outlook.com
 (2603:10b6:303:80:cafe::e8) by MW4P223CA0022.outlook.office365.com
 (2603:10b6:303:80::27) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.22 via Frontend Transport; Wed,
 11 Jun 2025 20:22:23 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ5PEPF00000207.mail.protection.outlook.com (10.167.244.40) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Wed, 11 Jun 2025 20:22:23 +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, 11 Jun
 2025 15:22:22 -0500
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 Jun
 2025 15:22:22 -0500
Received: from [172.26.5.4] (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 Jun 2025 15:22:22 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cbe24f1b-4701-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=IsTGn6PF2vs35LhqbQvkrQHuCC60o35NmnhwFaC0nHmzeqjmz4s78AHnUwugDjyVwrHbsZQjiIkGUHHIPP8AZb3pFkOgU38eN6ujYe4bMC4iF8N7LtbLjybJjALEHsaN0rdCENljOkIg89rEVsUft/V2RUeHOyJwD3Tr+P5pWmWa+5OfXa7aNfiSL3PN0axx3QexmSU7cpyb+cBvUF+fuypaVmyRnUsdBY342ec77jEg1Q2j0RdyWxdCTlDBKE2e2gqSGKTAyl3LBb/ia6GqqWbQWbTXN+KuB5tuCMkX7kSjuLby35blARlQDj0JLsb/EMR9/uBbEGXWkUwO5+QzOg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=x6goV5ciT4iqY09inpQbk3d2BuCrQk7keUKwVFCw0Gw=;
 b=L0MVjxfFnjblEg3mR621lq2i7W+URi2mGKxnSL1Fd3FBtWimNKagkRqtgoMju+XSM5mcVXJIJMMBZk1LWeBcWSV3X7mBCjveRsIkmjDdZvZ7XbIPdKKA+Zw/894D292B1y9ufq0B2pGXwx7j6IZ4U7f/n+BM23W9EcKcBE0Dudnddov4pN57TAhVsqdp2pvH32WrfW0XcDoY6C7zXbNU/zAybFhNhhPiW6ENs7YJh+ZdskQ4WkeMVQS77XINsMnE0P7h7m9Eq4uh70VuTUXTKo6Af0hepQMQXGush0lzLByHyAoHxMVle+6vgw7LSdIbP2q4HjVimnqrYw/ea1hqvA==
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=x6goV5ciT4iqY09inpQbk3d2BuCrQk7keUKwVFCw0Gw=;
 b=hBD498d32Vur+8uIRW9U1zrAEK9veWDXOLPCsroiqcJ2ScQDcvslI3zQQXcPBUC9BtzLYxivJgHlDYks10PzAEdZSCKp1OxlFQZ4tlwA0R/Hcus1FVZcNRYTkL+hdmvaTCn3vC3jSbD5sfexcExxFGLKs1A1eyAIENsCcMAbdWY=
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, 11 Jun 2025 16:22:16 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 5/5] vpci: allow 32-bit BAR writes with memory decoding
 enabled
To: Jan Beulich 
CC: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
	
References: <20250531125405.268984-1-stewart.hildebrand@amd.com>
 <20250531125405.268984-6-stewart.hildebrand@amd.com>
 <9ec5079f-9bc1-4843-a266-d74bf0556619@suse.com>
Content-Language: en-US
From: Stewart Hildebrand 
In-Reply-To: <9ec5079f-9bc1-4843-a266-d74bf0556619@suse.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF00000207:EE_|DM4PR12MB7576:EE_
X-MS-Office365-Filtering-Correlation-Id: 3232d222-0ec4-4f62-8385-08dda925acd9
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|36860700013|82310400026|13003099007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?Q1ZpMGhpWGx4ajVQL01yMXVPMlFiemdhUlBDN1JycVVDMGxuSzg4YWxnU2Jl?=
 =?utf-8?B?elV0QXlqNHBzb2Q1bFB0NjRleXg3aXlGdTJzNWVpTTY1ZzJrRTZobmxUajNH?=
 =?utf-8?B?KzEzL3lBRFdUUmVUY3ZFNGU0SmhJcWM3KzJiMEFEdE1oYVZRZ2ZIUXBmYTZi?=
 =?utf-8?B?TXRtYWpsU2pHUkVhSjJIazM2TXorQTRtTkVLT3JadXg5cmtac1FhTk1wRVRJ?=
 =?utf-8?B?NW5GSUFEWHBLdXNKcVczdFA4akdHZnFNVE45VUhMZVBzbWYyZjF5YUY5dzFT?=
 =?utf-8?B?RXFnNEZrVTI1R3Z2T0hRZmpGekRJWXU4aEQyVnJxNmREaTBGZ2ZoUER4NlJ3?=
 =?utf-8?B?RHZieGpHN2haaG9QeFNLL0MraUdTYWt5dHhVSG91cjEzb3dLUnVENmRoK3lY?=
 =?utf-8?B?enNLcFN1Q3NydmpHSzZkSTNiTmxaaEUxVUdycThZRWYyNEhGeDRaeXJScEVY?=
 =?utf-8?B?azl3eE9SNlYxZ0ZRVTFFY0hBSStydXQ4Rjh3dDNNZDI4bkEwUGZ5aGhqUmRi?=
 =?utf-8?B?RVpBNGFSWmU2bHhCWm42cHF4WjBETnkvSXlDSHQwbWZMQ205cEM2RkFFQTNa?=
 =?utf-8?B?aGFWc1VoS0VHbnplYnpmS1dNTmNCL0FYVUNkWnl2RlF0RVpHdHkwaXJnVGcx?=
 =?utf-8?B?cE1oNWpBZzQxeWUySm1rMk1SRUlrSnVPdlA5YWtVaXUrbWh6YlJES0EybElT?=
 =?utf-8?B?azFjdlFieFdMaHRWeFJLNmdDWVpHSDFGdnBLZU44QXRFYzFxaEdBdkE3VU5O?=
 =?utf-8?B?dkhFeXhjbHo4WHVDKzNVVnA4dVF2cXZJa3JyUkVNZlFGaW0yejczUTdYdkNM?=
 =?utf-8?B?a08rQVFCS0paWXp1NjVLS2ZXUkc5WUxZMEp2ZlBkeHI3TVlaZVkwdndMR1NH?=
 =?utf-8?B?TjNuZFRFNzhhVFFlYUJQT0doWUZTSkIwcCs2MUV6Ti9NUit0b1Fzb3lSZkxT?=
 =?utf-8?B?anIwL1BlaWlWVWlZTUZpNWU5SkhBaVJIdWhkemxYQkJwQlNDTUxwQTl5SXIx?=
 =?utf-8?B?bkxMK1BpNDYvaklFaGlFLzFseWxWYXhjS1p2cXE1djB0QWZsQURrNmNaeVJs?=
 =?utf-8?B?MG4xOERETURRVmZONlkxV2FWQ21PQzFRc2ZJK1JtU1J0Y3FnSUFRRUFEdDZO?=
 =?utf-8?B?RExqalZ6Q0tuejAwOFVESzdTa0w5QVlOL0tlME1MZFZhTHN2K3BNTFg4eEZS?=
 =?utf-8?B?aENIZ2RwSlZIR3hPd09rR2EvMkZUUVovVHRHQVRCa0VFZmtMWXFQRlBHYytm?=
 =?utf-8?B?THhvN2xyVUdlWktCVHlHek5pb0tQbGdxR0tpU3l2MmlRSDdMRHlCSnhPMEhp?=
 =?utf-8?B?SWo3QVpTMGZkdmpoVUJJVFh1WmNXQ3NibnNoZGVPUlJxTUJzd2FnWFlHZ1hO?=
 =?utf-8?B?blorOWVVSE5DdnNOY1o0Z2I5cG44R1BWb0tBcTdBUjVLcUhUVktCVjUyajZ5?=
 =?utf-8?B?L1RENFB3Uk9IRXFJQ3pwTEhNVkF6bTF0LzNxS3JPRlJzeXI5eXF6TFFBY3Jr?=
 =?utf-8?B?d2R2S1dUYy8vSHZHczNwWWhWcnJLakdlNzhZeVpXVUJ5V3NWWGFDN2VJemtH?=
 =?utf-8?B?ZlgwaVNXTzFONVVYdUdLZFFOV2RvTnBXN204eXlQMDlnZElIcUUrRUhJV29y?=
 =?utf-8?B?UlZTSGdVYmZTZHp6cUd4cmx3dzRIRkZNQi94VWI4S0VoQTJJS1E5Z0RCVzAw?=
 =?utf-8?B?SkhwMXlGeDNlQ2MzN3JoNWErbFlORlI3QVpPZXE0SHFhQjh2bnNhSm4rdmJV?=
 =?utf-8?B?VmNrMzNaNmJQYk1DelVaTnd1TElCRWFyL0p6bXlLSVNCZjFWYjlwa0o2MStG?=
 =?utf-8?B?a2JPcndNdTBsSkw0TVU5RVE5UXVHenJZdk5Oei92OUdobHZyOTZQbWFZL3JE?=
 =?utf-8?B?UkVmcEZvN1Jiemw0ZVBobHBJcEh5c3Jnalp1dlRFL3VLWnRMdkt1TEZya2pF?=
 =?utf-8?B?WENkZmh0UGhZREV6cDNpWlI3eUFrZTFoUDBHMUtqOUVsM2hadEVaWm1aNkVT?=
 =?utf-8?B?Q2VITXRTUGpBPT0=?=
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)(13003099007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jun 2025 20:22:23.4013
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3232d222-0ec4-4f62-8385-08dda925acd9
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:
	SJ5PEPF00000207.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB7576

On 6/5/25 06:41, Jan Beulich wrote:
> On 31.05.2025 14:54, Stewart Hildebrand wrote:
>> Currently, Xen vPCI refuses BAR writes if the BAR is mapped in p2m. If
>> firmware initializes a 32-bit BAR to a bad address, Linux may try to
>> write a new address to the BAR without disabling memory decoding. Since
>> Xen refuses such writes, the BAR (and thus PCI device) will be
>> non-functional.
> 
> Doing this for 32-bit BARs only, with not even an outline what to do about
> the same issue with 64-bit ones, seems like it won't buy us very much.

It buys us quite a lot: it means the difference between booting vs.
booting with degraded functionality or not booting at all with PVH dom0
on some platforms with certain PCI devices plugged in.

The plan for 64-bit BARs for now is to continue to refuse the write(s)
when the 64-bit BAR is mapped to avoid mapping half-updated BARs in p2m.

I'll add something to this effect to the commit message.

Also see https://gitlab.com/xen-project/xen/-/issues/197


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 20:42:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 20:42:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012169.1390705 (Exim 4.92)
	(envelope-from )
	id 1uPSGl-0006Qs-O6; Wed, 11 Jun 2025 20:41:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012169.1390705; Wed, 11 Jun 2025 20: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 1uPSGl-0006Ql-LW; Wed, 11 Jun 2025 20:41:59 +0000
Received: by outflank-mailman (input) for mailman id 1012169;
 Wed, 11 Jun 2025 20:41: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 1uPSGk-0006Pm-Na
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 20:41:58 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on2060c.outbound.protection.outlook.com
 [2a01:111:f403:2413::60c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8457f5c4-4704-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 22:41:57 +0200 (CEST)
Received: from MN2PR10CA0003.namprd10.prod.outlook.com (2603:10b6:208:120::16)
 by MN0PR12MB6055.namprd12.prod.outlook.com (2603:10b6:208:3cd::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.18; Wed, 11 Jun
 2025 20:41:51 +0000
Received: from CH2PEPF0000013E.namprd02.prod.outlook.com
 (2603:10b6:208:120:cafe::a7) by MN2PR10CA0003.outlook.office365.com
 (2603:10b6:208:120::16) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.32 via Frontend Transport; Wed,
 11 Jun 2025 20:41:50 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CH2PEPF0000013E.mail.protection.outlook.com (10.167.244.70) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Wed, 11 Jun 2025 20:41:50 +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 Jun
 2025 15:41:49 -0500
Received: from [172.27.195.250] (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 Jun 2025 15:41:49 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8457f5c4-4704-11f0-a307-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=SgEDVXdkh4EuvdcXFy2dY2FlYFRf/eMi0QoAbLr6Yjj6JJszGdCh0rPGqTVDFtHuO2Kp8f0fbjkWfGeXcxZKuC7xTJWZvaY+Lxw6jDQWtoecuGK4FxrHtxgmqyPj9LO8/xaDa8S+FNuB8EYByF0KO3+FhJpS1pnIsZ12TgYfWcTDpl9DceB8CJnFmAEQOljb2vP746tOJbqPfCiaafs2cFR9ebMttqPZhmkIBGv9vP4tx/+skNgA1UijuC0Z7VHaom3OA7+91kBsdUeyictCfNz6hN5AZxKpw3D5M4NN7n28cQdmYCFWkXP9X65hJTUH1w5qPVFOw/TkH9UPDCZlgw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=hSoUs/q3sJbHxSpapxW5i35H3PX490J21YMC+giLGeM=;
 b=lu8ro5mwzhQGJ5gCOJ3/vjgJvJuHAx2iAsBaXjjzw25hzEundopz1v913YebmXJWmgJIPlSlm2lmbcOgrWb45Pkw2yg6g1piRmMGRYOlvskEeZQoyIQ7C61US2MazwyjKllInLuTpCqxpYRoMbh/lB6qGuU+93J3F0kjMW2i16NEh+FqTJWgCyPzoHZy615McTysYz44Ykge3GAknB3xH3RSn8HZA3biqqtgOqbIkVNOKEdIs01I8PjUa6rb/vkod3Uqysuj7t+KJU0+QvAq3z4GnlPQ67R7syuIsiewST2Tzvh76Nm8obFuNalw8PKHvTHOVTI8C7Gs/QFuPkwjBA==
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=hSoUs/q3sJbHxSpapxW5i35H3PX490J21YMC+giLGeM=;
 b=s/MqmB3Fm275Izq7fPyKRZFn/AGpjmsXk5+AgAclr2YuqKDtSOEcENEmr4rXjh0qeDL1Mpu9SIpXAk9WfGwErJIJ+CXiCuRAQ8q7aVy7PHj0HGar2rSUDus3RRdZY6PUwV4E8qipzgQ0MxOGkagRu3MBWLpFldKxHgXnfZlcB4E=
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: <4d6a72fc-5e7d-4817-8b52-b6b24fca9d25@amd.com>
Date: Wed, 11 Jun 2025 04:02:58 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 05/18] xen/cpufreq: refactor cmdline "cpufreq=xxx"
To: Penny Zheng , 
CC: , Jan Beulich 
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-6-Penny.Zheng@amd.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <20250527084833.338427-6-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: CH2PEPF0000013E:EE_|MN0PR12MB6055:EE_
X-MS-Office365-Filtering-Correlation-Id: e1a0d3b8-48e2-47b7-2ac7-08dda928644e
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?RHpjWVVVSTBHT3FBTWJCalpUSGd3aXlnMlErbGYxR2JJSDZDQWIrczlKOVgx?=
 =?utf-8?B?YmY4cmNxbGNiVGVqK2N1SFdRMDhOV0VveS9FaDBHaExDQXlZUU5yaHdDUDdL?=
 =?utf-8?B?ZmVhWWRrcCt4d3grQ042dUgzbjExaUxDcXdwMlZQZjR1MHVVYW0yOUR5MjhI?=
 =?utf-8?B?WjI0WmZLRkd1V29uUkNYWjRwVEo2Sk5kR2UvaVdRejZ4d3k4UE03YmUzTXN5?=
 =?utf-8?B?RDdZK3ZqMGJpMnhyQ0lrZUNYVXovbUdGVG9sYTF3eGdHQzJGME5LaUpSNjJW?=
 =?utf-8?B?eEV6ajRxMnRjRlpSbUhNU09WeENySXg5eFRkQkhSUm1VOWcwSGV0OHZqb3hu?=
 =?utf-8?B?YjkxMEpHeGVBWmFlV1IrbFlhZ0ZVNjhFK2Zvay9BcXBYeTJZSFRCbGVxUjRU?=
 =?utf-8?B?c1NOUG1xU240UFBrVXVYRERRYkdGeTNJR0RxR1BQK2xHWUUxN0lBMmxNZzgw?=
 =?utf-8?B?L1dhMnhPZVJPU3V4S0I4d2hJeGlJeEJueWwwems0YW1RM0lpbnJSNTFWQjhH?=
 =?utf-8?B?S0JML250c3FFZkhYZk1YNXl4OUY2THdIcE1Rdkc4TWR4N01HejUra2dqWlhO?=
 =?utf-8?B?WkorNS9BaUJteFVkMHNXK0NxclV4TEc0NG5zYWtpOXVET2RURUN5YnZoV2kx?=
 =?utf-8?B?KytzOC9UK2FjNjdVNXZMSWUyMGYxci9GTmZuNHFxRWNqRnN2YWdad29rdTFO?=
 =?utf-8?B?QkVicTcrYlZOOXIxdmhVZHZ3VWpNMnMwTG5yZ3Y1d3F3U2VGREJycU9IWjJ4?=
 =?utf-8?B?dng2Qyt6R0NlUVJZTUhMVllzY2NLQTI3WkNOVk9FNnU4SElIejNsQVF4ZmFC?=
 =?utf-8?B?Z1Q2aFZEMmdQQVhPQ2FxRVNSa2lMMGgzVCs0d1BuZ2pBVDJ4amxuQm5JNFhj?=
 =?utf-8?B?aWdieVMzWFhjdSttQzNzOENjRUt3MFMxYkk3cVhxMVRZZHpSTGFXSXBPUjFl?=
 =?utf-8?B?T3dwL3V5T05rUm1qZkNUaWoxYTBEY0I3RGs4Sm9iTEE4czE1bCtUMWUremlv?=
 =?utf-8?B?UkNEeUdSY2Z2YTdoZU5nZXJDVGd0c3hwalppWDZ5QitsWjgvSzF2NWd2TktY?=
 =?utf-8?B?UzEyRlU0bHdyZzhMZC90VWdJcWVJSE81eGRDdlRSdjhWMndsc3Byd2RHREp1?=
 =?utf-8?B?dmRmWXBJVG9WMzZxZXg1ekc2bVRRbktEWTZDUWZLYVY4M2M4MU0vWXVOZHIw?=
 =?utf-8?B?QTdaNlVoVDJ4QVkxNzNzR0RiUmt4a2RUeWRUQ0NxYlhHdldHZlZDdG5YbTdJ?=
 =?utf-8?B?OFlUYW10WDdjVHdldmFJMjJmVWIyRmVnK2RLRHB2TGpaUXIreFVPRU1tU2hB?=
 =?utf-8?B?ck9vR3ZYaHhVU1N6WG9NTnptRjNjZTF1SVhMVERWcnRSU01WYWpRanJiaUk4?=
 =?utf-8?B?RHZ1QVVKWjFZUm8wY0VSZUZuVEZEemJXT1JJTldkWDVJZnJLSmlXajJuZjJT?=
 =?utf-8?B?UnIxNXJzSFFlSG1KR0lmeVNrZVZESzlsbDVab3hwRlpRYzQ4MkR5Vm1zUU1D?=
 =?utf-8?B?TXU2cm1BVVZJbU5hdElTSmNmY0FiZUZCUE5VZ1A1OE8wVVVka011VGZKeVNa?=
 =?utf-8?B?Si9Hc0l0U3pKOHNLbFltZE5hNFZGY3BDTG5VZDRVRnZ2QWhjN2NZUGVPanFT?=
 =?utf-8?B?MStkUU1sNU9pU0R3Ny9IVUtKcmRYc0hjREUzL0NVWGhiNXFzWXFtQWhpVkFa?=
 =?utf-8?B?ak5JSkpUSXozWEF6cEFzeUhEa1NkRVhDL0VlRFFkLzRoTnBzdjBaVktRQkk2?=
 =?utf-8?B?THdQYzErSVdsNTZmRmd6MjNsdFdoS1JGdXEwdHhVR3FVQVJGWWM0NUg4RG0y?=
 =?utf-8?B?eWlxc3hBS3l5MXBWTnFGdmxHMkF0ZnR2SzlUYm9SSVBJN0p4K3VTaEsvbDZi?=
 =?utf-8?B?bzVTSklSem5zWWxIYlBlbDdUeXM3T3gzRmptMmdwMjB5blNPQzVyT3R4dGgy?=
 =?utf-8?B?WHpjcG1nb1pCTTdEZXZUb0JldnZmdUZuM2xXOGtRdFVYQ3BFb1IvSjVhbXQv?=
 =?utf-8?B?MEszQ0VzZEh1UXNZQ2xLWThjQUd0dDREbUF3Vnh6Q1IvNlIycWl6YlJEY0la?=
 =?utf-8?Q?xoQqh3?=
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: 11 Jun 2025 20:41:50.2516
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e1a0d3b8-48e2-47b7-2ac7-08dda928644e
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:
	CH2PEPF0000013E.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6055

Hi Penny,

On 2025-05-27 04:48, Penny Zheng wrote:
> A helper function handle_cpufreq_cmdline() is introduced to tidy different
> handling pathes.
> We also add a new helper cpufreq_opts_contain() to ignore and warn user
> redundant setting, like "cpufreq=hwp;hwp;xen"
> 
> Signed-off-by: Penny Zheng 

> @@ -114,20 +161,14 @@ static int __init cf_check setup_cpufreq_option(const char *str)
>   
>           if ( choice > 0 || !cmdline_strcmp(str, "xen") )
>           {
> -            xen_processor_pmbits |= XEN_PROCESSOR_PM_PX;
> -            cpufreq_controller = FREQCTL_xen;
> -            cpufreq_xen_opts[cpufreq_xen_cnt++] = CPUFREQ_xen;
> -            ret = 0;
> +            ret = handle_cpufreq_cmdline(CPUFREQ_xen);

Do we need to check ret and error out?  (and below)

Thanks,
Jason

>               if ( arg[0] && arg[1] )
>                   ret = cpufreq_cmdline_parse(arg + 1, end);
>           }
>           else if ( IS_ENABLED(CONFIG_INTEL) && choice < 0 &&
>                     !cmdline_strcmp(str, "hwp") )
>           {
> -            xen_processor_pmbits |= XEN_PROCESSOR_PM_PX;
> -            cpufreq_controller = FREQCTL_xen;
> -            cpufreq_xen_opts[cpufreq_xen_cnt++] = CPUFREQ_hwp;
> -            ret = 0;
> +            ret = handle_cpufreq_cmdline(CPUFREQ_hwp);
>               if ( arg[0] && arg[1] )
>                   ret = hwp_cmdline_parse(arg + 1, end);
>           }



From xen-devel-bounces@lists.xenproject.org Wed Jun 11 20:44:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 20:44:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012177.1390716 (Exim 4.92)
	(envelope-from )
	id 1uPSIy-0006wp-3n; Wed, 11 Jun 2025 20:44:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012177.1390716; Wed, 11 Jun 2025 20:44: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 1uPSIx-0006wi-WD; Wed, 11 Jun 2025 20:44:16 +0000
Received: by outflank-mailman (input) for mailman id 1012177;
 Wed, 11 Jun 2025 20:44: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 1uPSIw-0006wc-OQ
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 20:44:14 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on2060e.outbound.protection.outlook.com
 [2a01:111:f403:2414::60e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d53c66b6-4704-11f0-a307-13f23c93f187;
 Wed, 11 Jun 2025 22:44:13 +0200 (CEST)
Received: from BL1PR13CA0271.namprd13.prod.outlook.com (2603:10b6:208:2bc::6)
 by MW4PR12MB7381.namprd12.prod.outlook.com (2603:10b6:303:223::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.38; Wed, 11 Jun
 2025 20:44:06 +0000
Received: from BL02EPF0001A0FA.namprd03.prod.outlook.com
 (2603:10b6:208:2bc:cafe::1d) by BL1PR13CA0271.outlook.office365.com
 (2603:10b6:208:2bc::6) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.22 via Frontend Transport; Wed,
 11 Jun 2025 20:44:06 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BL02EPF0001A0FA.mail.protection.outlook.com (10.167.242.101) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Wed, 11 Jun 2025 20:44:06 +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; Wed, 11 Jun
 2025 15:44:04 -0500
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, 11 Jun
 2025 15:44:04 -0500
Received: from [172.26.5.4] (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, 11 Jun 2025 15:44:03 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d53c66b6-4704-11f0-a307-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=W8UiAIB1gZZi9KJ4nATn4O8YBLEHPN2/kbxFErjIYnhAu4zQsx5csRM7/9tmSI6xbTbBMegPpjMPhAKIHq/kCbAvPPuGjGVvTdWLLBoaH7v/E8AZnu2jGT9EDjdKUG8AQjx7M8aq91iRpPLoVPEkd5AQ8+6e0M3ZJ5HaOrUTz2/SS9tOhqUU/SbtawkLhLO2mLXpSdbpCAfAefgKS2u6CL7IlxU4aHvpLM6aEl+4UkxWOwgG4eew0YSlFyfDLoyLLogktv1nRyx76QKve+hjjaEyEpTHGY+w6ffNpD5Aey/D3U8akMeaWELdpqNgE3eKq2i2q3lO7UcdMpmuAsot3w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=4u9KL/l+My+LzkoAWbGrbAc3Uv1NOv5SYpmfJKk8X9E=;
 b=YyL8hD4OjTzfo6v/2IewLUnDaTJfpOqGQo7rZKu6KMNzftSsd6lF9l8Fah5cpZ+QKEx7yIuofjl5ncMtoqYueF/7ZGO6kBuHq2COGOTIDX74PnPYCKXy20grBcsOnNYAJMHfqiT6mVjyKJCBtToKtoqkPUSbfe9gNkgM33PeZxyKMcvW7QDnRjJ/4IeYfPQl7kNnD5SN2AHVMFcwk3KB7cFXgr+M48LiDeGW6+O94cAVgftNENM1sy3/zh+l1iOP4MzmXVHPhelppneE6QroE61clm/e9E4N9pz5FVzvUmXrjxdA9CvOceLgiMCOLxYiPhzi/iKn/TQ2EGdxg19jFg==
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=4u9KL/l+My+LzkoAWbGrbAc3Uv1NOv5SYpmfJKk8X9E=;
 b=0LUjeglwSOO0CuTMPbcNBTHs8e7UymsNHvpaJD+qIEMSwIKopAmBXwxfVQD+nM156dU4gfda9d1bAH9r2EtYghsNZ+XIAgA/A1sxMdepYeqFFhk5FFOemoi5sFX1b2IMXTBSXunihMBoU4chr3c917i6cpzGAOus6OPinavke5w=
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: <6b1a780b-4454-4001-ac36-26eac5e383a5@amd.com>
Date: Wed, 11 Jun 2025 16:44:03 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/5] vpci: rework error path in vpci_process_pending()
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
CC: 
References: <20250531125405.268984-1-stewart.hildebrand@amd.com>
 <20250531125405.268984-3-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 (SATLEXMB05.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL02EPF0001A0FA:EE_|MW4PR12MB7381:EE_
X-MS-Office365-Filtering-Correlation-Id: 8d98bb03-34bf-4586-5394-08dda928b565
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|1800799024|36860700013|376014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?Nm9mZE82cVYzcFlpVndKZ3k4Y0w1bEhEQjNGMGR0Z0FoaDVrV2MzNnNCS0JN?=
 =?utf-8?B?UXllcnRQL2duN2NsYWFnR1FDbEpucDBBa0hNeTBrRWQvZnN1QkprZ0c5T0lF?=
 =?utf-8?B?TTZyaXhWdlRjcXBPU2t6RDNkYTRWVGczcDUwN2F2NittOTVHS05SdWJ4NGFI?=
 =?utf-8?B?SHdVYyt3WXRzYVRROENFLzg2Y3VBMzIybXFacVZvYy9IK2owTEZ6MThENFkx?=
 =?utf-8?B?QlBPdTRaN1puZkhiWFVKUS9JZEJGYVArQjBURDlYSkdCT0xDcCtTTCtzTkJN?=
 =?utf-8?B?RW5hRHRDNlRKanNUWk53bDFnRmFoUC9JSmxSS3BqMVNZUEJFSmY5ZU9rbnZQ?=
 =?utf-8?B?V2pJMVJJNzA5dStLNE9RcGhDVlNFd2JCbHEydnlGRXBpcnZ3dG1JT0xyQ255?=
 =?utf-8?B?bHRKSmVRYkxtUWI2Q2cwU2sxM2lNWEYra2VwV2FsR1ZEbWFJK2ZTcG94Wmh6?=
 =?utf-8?B?TElRVGh0akk1Z3padExreDUvZjBZcThrK2ZmRkJnWm9EaVBNRnNHbjVxcHZr?=
 =?utf-8?B?UTlBNnJEc20zeU9NRlQrVHZYYUV3UGV4SDNUcVhmc2IxUzVmU1dzZHdyQmsr?=
 =?utf-8?B?dHNXRHFwWi9PbXVFU3JxTkJxN3FuamdvblhkZzdCZmwwNHV3UVhDeTFVK2Fu?=
 =?utf-8?B?bGIwVU1ETGNQRGtQOTd1dURkRUxCWjJaOFFJaTcrZHJmTjdQREZSanpLZWxN?=
 =?utf-8?B?YTNMM3VrM3JYU0FpYlBpa0FJSUM5ZzdYT1l2TGN1c1ZIWm5tWWZDckZNZVRj?=
 =?utf-8?B?WWJLdmhrZVQ2RmhsTkJmRVFUVXFyVk8zd2s3a1U0ZEJJS3lxUWtzUzZycE5P?=
 =?utf-8?B?WE9TZUcxZnZSbmFJV1Axa3oxVVNCU0FUMDI2cjJJRlJtMis5UmNESmZQWFNJ?=
 =?utf-8?B?Syt3c21UaTcrMzdFTzU4V0MzbkM2ek1ab2lsSEZqWjdtRDRKaG1zdGdkUnpL?=
 =?utf-8?B?R2lRQVBuV1UyVm9TMVZOV2x0MjJUeEl4V2JiR1BpbnNxSDdaOEdwQTFxQ0Y2?=
 =?utf-8?B?RTEyYm9YU2FKdTNqeEYwa0RrTStTVGt1R3JSSjJyZlZUdkVyK08wdEdDTWNB?=
 =?utf-8?B?Ni9VR0JKQmtwNHg2aHlaNksyV2JMNm9ieWwrU3hwRXQrUUtGcFdHY2h0YmVY?=
 =?utf-8?B?SHhEakx6eDlsekZCNnpHL0hhTk91NzUyRXBYU3owdWFJYXNKdTc3d283Y2Q2?=
 =?utf-8?B?OU1KZDltbXlMQVhhbVdVMGFsZWloYlVtRjJUdkw5UGJVbHBveWJFc3lwQ2l1?=
 =?utf-8?B?Q0FsUEdEZndLVmxPaHJTMUYvYk5RZ1JsR1FPRGxaMHliTThMZVhpRlJIVWEw?=
 =?utf-8?B?ZHVBUnpjWHRJaHUrVWJ4aVc5eWhYRlhEMnZvcEF2NFNMaEkzY0JidEhXUHFQ?=
 =?utf-8?B?UGtaZUM0RFhZWXg4ZVNmalkwaU1PblhDWkNFKzc2QzNpU09RWk1jeE1pWjZZ?=
 =?utf-8?B?QlVwcmwrODFmcHR6Sk1UUHpkdGpzRWdhYkg1NWRsWS9kaktNSExOcDQ3R3c5?=
 =?utf-8?B?cEViWWJtQ2dYTm9Jbk5IY3UweTJXMnpzZWQ0TlUyQTB3S3dHWkluUkVKTFoz?=
 =?utf-8?B?TEZ4elNjL203blJiREo4TFNtOHJuZmlENm9XeWYvUU9vV0RWTEE5U2VmMTBz?=
 =?utf-8?B?MGFMVnI3alNiUWpxOXg0a1ltanQzNldZZ0U3eU52T3MyUEgxQXUyRERtbFRD?=
 =?utf-8?B?ZnZxaTFjdGZobldOQ25ERHF0ZXhLYVZzcHl2SmM1ZHlZem9VVFlBS09Ib0JM?=
 =?utf-8?B?bGZkRWthOXBVSzhjRFQ5UlNxdTNpcGhGZUY3MWpRZmVqaFF2ZStSVlBZa3ov?=
 =?utf-8?B?RTNBdFB6UWV1YUNNSzJQSFNHRWNVMER2MVUrS1RuSlkzcHBERGN4MmNLL3NN?=
 =?utf-8?B?d21TSmpFQmlXc0F6SXRFSGRTRFNmQWg0bW1PekVGSzMyQTJFVnhGdVJ0MERv?=
 =?utf-8?B?ZHlvMVlyaldFaHVYODh6NklxODlMRUdubkd4ZkdPc25maWI2UFhOVnNBcGxj?=
 =?utf-8?B?U0F0eXpDSkFUZFNwZnMwL0FFTXdqWG5jRXRheTYrejhtQjJ0WWNBeGZZZWZM?=
 =?utf-8?Q?DLtqQV?=
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)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jun 2025 20:44:06.3146
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 8d98bb03-34bf-4586-5394-08dda928b565
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:
	BL02EPF0001A0FA.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB7381

On 6/5/25 05:53, Roger Pau Monné wrote:
> On Sat, May 31, 2025 at 08:54:00AM -0400, Stewart Hildebrand wrote:
>> This will make further refactoring simpler.
> 
> I think you want to add:
> 
> No functional change intended.
> 
> To the commit message.

Yep, will do.

> 
>> Signed-off-by: Stewart Hildebrand 
> 
> Acked-by: Roger Pau Monné 

Thanks!

> The success and error paths have some shared code, that might be good
> to unify, but that requires further rework.
> 
> Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 21:34:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 21:34:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012191.1390727 (Exim 4.92)
	(envelope-from )
	id 1uPT5M-0004i9-SV; Wed, 11 Jun 2025 21:34:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012191.1390727; Wed, 11 Jun 2025 21:34: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 1uPT5M-0004i2-O1; Wed, 11 Jun 2025 21:34:16 +0000
Received: by outflank-mailman (input) for mailman id 1012191;
 Wed, 11 Jun 2025 21:34: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 1uPT5L-0004hu-3b
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 21:34:15 +0000
Received: from sonic303-25.consmr.mail.gq1.yahoo.com
 (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cf7287f4-470b-11f0-b894-0df219b8e170;
 Wed, 11 Jun 2025 23:34:12 +0200 (CEST)
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic303.consmr.mail.gq1.yahoo.com with HTTP; Wed, 11 Jun 2025 21:34:09 +0000
Received: by hermes--production-bf1-689c4795f-jdp75 (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID e03b77c830db9585637eaa713f2d4c56; 
 Wed, 11 Jun 2025 21:34: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: cf7287f4-470b-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netscape.net; s=a2048; t=1749677649; bh=wWH7KPjcVhgpUMexTZNPLdNB6wSybQPzcHjpjkYzRaM=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=i0tXk9QJ3cqYT2NL89KZK86yUMQVGAXc9b3W55iOZxnpN6DvuhI3G+TzCfwn1VstXzm8VtS2pFxFwwlp+4xb5pf17LMUxOwHkXZ9Ap2oXq/okTDGSJdJQsWxOYYtHjGaZ/nG1LsJ1buZXFom0NaVSWGKB46u6ykdhwx8X0EZl3I9z8gtvGg3CgrdS3qgwtW692aDVJuaa0z5Ueo0URgTuTUMCs2WgQvytIos2NFqPAcL1Ps/qC4ZKkk8ddG/rrp9SgXsxwCB1DgmlceenEkyWm6cZYgWhRU7z8ikTl5EQW+sglqaMJkAH1r+5NrlALE1i2LmtORWY8OZ5IMH96MPMg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1749677649; bh=kfWJ5z2j5M+tdghUhpWueu2RKWmdznTovMpniCMylDU=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=a/v38PB10wJwJz5ctznAgX6983n4C7lm6psnYKAAPn92Us5zz2I6DIFvGDoEG5xqZu1l7b7paJqUBZyxQuHmGN5PKGQvotxtBDqdvAMKwMCqJjwjhyNPLxYss0qtd4Vjdixny7XUDCzt7Lc7eELu7WG9cHMwmOQyD3Sd54zKJnt4mJ0KX6/fOhbBW1s7zEcQWGZaCyM4AfpsJ7xrt5U+6jNSihTwPjWUx0B+9cwQOlsyxoUJ3fPosQFadg0zldJKaPfuL05maatJVBsbWy4vI0TjKp8ehfAy9AUu7aylJoJy+KaXkQ0H2WlDpGgIie8zvR3D6XB3//qYP3P15ecxpQ==
X-YMail-OSG: FBZ6b1sVM1nyyR46kNL_Xyjcyvrmyq6y3qf31DsLQekhOLNJa9frx8er6L5zYHd
 TvkFOaAE5IJpz6k6NSe7j1w1tgJE0_gMoYoNC.tfPS7IIQwPEmro.p2AzgDkBKjd21mvv4Vg63_Q
 sCJ1FX5KkYV6bF1CpRfUwH48ATbJblSQ0XOQfw16osxs9FObgCFwdZJI6fHo9nqhydBNGoyIQSZz
 LDJRRx.VYsJVIZo_b5zU70Do_nBemYXSA6v8l8GQJ3pAxhPQ3vTGIx7_3cI3iVip5nGKnrbJmBhk
 DkTqKFAlCg3hXtwXIsa81FCA8tVqu7O5FgdfQYO2ogaIqqcL4GWQRpZpusLa2Gsx7397_1HAeSGj
 Fk6IioIXWJUiqVH_1jzWGrvMVk.6C2t3GHggphsQbrP0q22JMOpbLiQ00qXvi6H9ShNQCudoOGA9
 Skk3gTuuigcvbc027DsEfF5P5HYgnFtNUIyY5gnyzFtmpKeruqT8g6Qg2DInuirQk0FCcOFT0jMW
 DAed4dhI3fY8OcfH8KHxZCYm2wrsng.TmGMYadiP8PvfU9BC_g3p8.yONrkq9tUet68gksuHkcBW
 s3LBa30x90I2PunUiyQl2ux5nBXHzhmAI0hp6GIEYOhseq2P9GPr0ddAWQdBrSH4xntjY5uKuFMn
 HKAiRQfo_snqJbL4i1rZ2_DkSmGsqPMgnfQoKQA9HzvKw_0vqiyJxPSHrBm0PehnsbGXMaiOcydU
 yWB0eDuWYMiqrHmRL2fQqGTyY6N7gO4e3m6Xh1GWqx2YgqcZpgxVBl.xI3rpBMp.DK97OnDC62pT
 BVacOszhoGnaimJt_BILrqROnY5BI3lkyzMbG35mIjlmzqm.VbJ4eqvuw9yHbUvSVzHKQyOSNM2n
 w4EClczuvQIboHKGRhUHXXWYh6YXHiCRTG8z.KPijav4UJaA4o4xh5JUT8BdJUIVCbQSPQ4__GFt
 6V38RC.3_EZ.fnCW0hdAilCaTzNoQ8SRwO0eLi8AqHWPFAQ08TcCgeI6dp_.4XtDULt2bFrvRncD
 stapdRv2lNmAGpWuraJc2cl3EPWJr1bkHc5SJXeQGJohNlfh9FuxOQ6h0gesi_yiPnGnmGwxWl1x
 4rxCNVkw0wTBpSMzy3yAHiVqkD_SL3LDhrP0pkeplw89DU7hQKBrrZiV5zpiZgyUaep1VYZnyAXY
 kA2_XIQNjXEv9IR1DhqzJJ17BBo.OHA9hhlm9gRukbMLb2Xjfodm9Fw38ZppZWzBgcdthXY_bm4J
 ITjXbFah_ZrzRpemRuDFvyJmgn31ibi.Mr_NHg6BV90PwxzPsW_u5iiWImRqU5vyLhUPdrKs6qzK
 JxcQMzFvzfRo7ZnHsJL2mKlZFFcWUiS6710cJA0QiDvCVOnatDVtZIUhaAGBLJrG1LOj.mm810tc
 .EpOLcIZ8E2wEa1pu8oMitpAHTrIh6jPJ3VnSkGMwrzfCYb9iRtRUEJpkc1QDO_IkVGpCff7X1n_
 xs5xTkenGJXIMxgC266cxo5iRA4mEiZODZl9osyvOWpKPsJU_isB8.s9IMMB6f.IUPg3Qk5J2ftb
 x_wN8l9OymgjF8ydTIM92Q.p0g3lQbMCU1eSBOplsK8WUBNSIPNR.IrsRx.Ha8MooGkDXqOrzPvb
 C50TJnDaXPm9gg8saRGlLQDxu5fFBSs1PWOreMs_88MvMq0vTDww1.860faWgxZUYvlyM7A4vG8M
 nweJ7J2cuaYOtW2d.wZWpcRXIJdijV34hdd0sgMZ.ZvJzIy2Ioo6nlTr5sNk3Qhq9.LbyKsseD_.
 dQzIijHFkv1FjDK_bgzn4dCEtukMoXG0Kg2B.oP.VDk9Rferj5rrLwrW7En1GK7pmTSOYmrHFb4y
 Un6qaGQlJ_4ehym6wFOqVmMrwxvtpamijl.mKOE5OXKVL.z3iVZzRBO2ZurMXPfbF7oEYhh3yesN
 D8e45CGOHETBuzpG7.F.7GZ1ZQj7ROeacTTYpu43O0idypFgJICtjIkJqY9fwCQBTRSQfjluHouL
 OL0vYckQwvUxMZ_OMEuEy5aRvztAF9O_.AlG39YY7NPZKoQZb3O3dLwbEyFyb28QDHflTLXTvRj6
 j8o8qoX0yv15hPXtleOSc0b.00vcVfB4ivum02tfx3e8hv_SM7LRPhN9jm7J4LLoMVADxiYGnlpG
 puS5W2vFExO8Z4Rj2bo_DAbLgHJRyUtC1b5aSTf7Esc9J.u9TO7c-
X-Sonic-MF: 
X-Sonic-ID: fcf916ff-d536-430b-8478-a9f085b6798a
Message-ID: <5a962cae-b65d-4a27-9189-20027344567e@netscape.net>
Date: Wed, 11 Jun 2025 17:34:04 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [REGRESSION] Linux 6.15.1 xen/dom0 domain_crash_sync called from
 entry.S
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , stable@vger.kernel.org
Cc: regressions@lists.linux.dev, xen-devel ,
 Boris Ostrovsky 
References: <8ed96ec9-7c84-4bb4-90ec-5b753be9fd40.ref@netscape.net>
 <8ed96ec9-7c84-4bb4-90ec-5b753be9fd40@netscape.net>
 <8ad4304d-43bc-4584-bc69-822eb0661e7b@suse.com>
Content-Language: en-US
From: Chuck Zmudzinski 
In-Reply-To: <8ad4304d-43bc-4584-bc69-822eb0661e7b@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Mailer: WebService/1.1.23956 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Content-Length: 4215

On 6/10/25 12:22 AM, Jürgen Groß wrote:
> On 10.06.25 00:43, Chuck Zmudzinski wrote:
>> Hi,
>> 
>> I am seeing the following regression between Linux 6.14.8 and 6.15.1.
>> 
>> Kernel version 6.14.8 boots fine but version 6.15.1 crashes and
>> reboots on Xen. I don't know if 6.14.9 or 6.14.10 is affected, or
>> if 6.15 or the 6.15 release candidates are affected because I did
>> not test them.
>> 
>> Also, Linux 6.15.1 boots fine on bare metal without Xen.
>> 
>> Hardware: Intel i5-14500 Raptor Lake CPU, and ASRock B760M PG motherboard and 32 GB RAM.
>> 
>> Xen version: 4.19.2 (mockbuild@dynavirt.com) (gcc (GCC) 13.3.1 20240611 (Red Hat 13.3.1-2)) debug=n Sun Apr 13 15:24:29 PDT 2025
>> 
>> Xen Command line: placeholder dom0_mem=2G,max:2G conring_size=32k com1=9600,8n1,0x40c0,16,1:0.0 console=com1
>> 
>> Linux version 6.15.1-1.el9.elrepo.x86_64 (mockbuild@5b7a5dab3b71429898b4f8474fab8fa0) (gcc (GCC) 11.5.0 20240719 (Red Hat 11.5.0-5), GNU ld version 2.35.2-63.el9) #1 SMP PREEMPT_DYNAMIC Wed Jun  4 16:42:58 EDT 2025
>> 
>> Linux Kernel Command line: placeholder root=/dev/mapper/systems-rootalma ro crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M resume=UUID=2ddc2e3b-8f7b-498b-a4e8-bb4d33a1e5a7 console=hvc0
>> 
>> The Linux 6.15.1 dom0 kernel causes Xen to crash and reboot, here are
>> the last messages on the serial console (includes messages from both
>> dom0 and Xen) before crash:
>> 
>> [    0.301573] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl
>> 
>> [    0.301577] Register File Data Sampling: Vulnerable: No microcode
>> 
>> [    0.301581] ITS: Mitigation: Aligned branch/return thunks
>> 
>> [    0.301594] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
>> 
>> [    0.301598] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
>> 
>> [    0.301602] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
>> 
>> [    0.301605] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
>> 
>> [    0.301609] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'compacted' format.
>> 
>> (XEN) Pagetable walk from ffffc9003ffffff8:
>> (XEN)  L4[0x192] = 0000000855bee067 0000000000060e56
>> (XEN)  L3[0x000] = 0000000855bed067 0000000000060e55
>> (XEN)  L2[0x1ff] = 0000000855bf0067 0000000000060e58
>> (XEN)  L1[0x1ff] = 8010000855bf2025 0000000000060e5a
>> (XEN) domain_crash_sync called from entry.S: fault at ffff82d04036e5b0 x86_64/entry.S#domain_crash_page_fault_6x8+0/0x4
>> (XEN) Domain 0 (vcpu#0) crashed on cpu#11:
>> (XEN) ----[ Xen-4.19.2  x86_64  debug=n  Not tainted ]----
>> (XEN) CPU:    11
>> (XEN) RIP:    e033:[]
>> (XEN) RFLAGS: 0000000000010206   EM: 1   CONTEXT: pv guest (d0v0)
>> (XEN) rax: ffffffff81fb12d0   rbx: 000000000000029a   rcx: 000000000000000c
>> (XEN) rdx: 000000000000029a   rsi: ffffffff81000b99   rdi: ffffc900400000f0
>> (XEN) rbp: 000000000000014d   rsp: ffffc90040000000   r8:  0000000000000f9c
>> (XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
>> (XEN) r12: 000000000000000c   r13: ffffffff82771530   r14: ffffffff827724cc
>> (XEN) r15: ffffc900400000f0   cr0: 0000000080050033   cr4: 0000000000b526e0
>> (XEN) cr3: 000000086ae24000   cr2: ffffc9003ffffff8
>> (XEN) fsb: 0000000000000000   gsb: ffff88819ac55000   gss: 0000000000000000
>> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
>> (XEN) Guest stack trace from rsp=ffffc90040000000:
>> (XEN)   Stack empty.
>> (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds.
>> (XEN) Resetting with ACPI MEMORY or I/O RESET_REG.
>> 
>> I searched mailing lists but could not find a report similar to what I am
>> seeing here.
>> 
>> I don't know what to try except to git bisect, but I have not done that yet.
> 
> This is a known issue.
> 
> A patch series to fix that has been posted:
> 
> https://lore.kernel.org/lkml/20250603111446.2609381-1-rppt@kernel.org/
> 
> 
> Juergen

Yes, that patch set (the original 5 patches) fixes this issue (I
tested it on top of 6.15.2 released yesterday).

There is a suggested sixth patch in the thread, and I tried that
also but it caused a kernel panic in Xen PV dom0.

Thanks,

Chuck Zmudzinski


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 22:15:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 22:15:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012208.1390736 (Exim 4.92)
	(envelope-from )
	id 1uPTjD-0001I0-RI; Wed, 11 Jun 2025 22:15:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012208.1390736; Wed, 11 Jun 2025 22:15:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPTjD-0001Ht-OU; Wed, 11 Jun 2025 22:15:27 +0000
Received: by outflank-mailman (input) for mailman id 1012208;
 Wed, 11 Jun 2025 22:15: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 1uPTjB-0001Hn-Fz
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 22:15:26 +0000
Received: from 2.mo550.mail-out.ovh.net (2.mo550.mail-out.ovh.net
 [178.32.119.250]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 915b16e1-4711-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 00:15:23 +0200 (CEST)
Received: from director9.ghost.mail-out.ovh.net (unknown [10.109.148.164])
 by mo550.mail-out.ovh.net (Postfix) with ESMTP id 4bHg2f29XQz1SWB
 for ; Wed, 11 Jun 2025 22:15:22 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-fmjvw (unknown [10.110.168.167])
 by director9.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 33AAE841F3;
 Wed, 11 Jun 2025 22:15:21 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.114])
 by ghost-submission-5b5ff79f4f-fmjvw with ESMTPSA
 id YYnCN/j/SWgc+wQA2bOk2Q
 (envelope-from ); Wed, 11 Jun 2025 22:15:21 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 915b16e1-4711-11f0-b894-0df219b8e170
Authentication-Results:garm.ovh; auth=pass (GARM-114S008e51bf213-26b3-4121-af28-2028cbb1de8f,
                    CF5C07F8BFC6FE4C0252D8DD6CF7CA7F095CBCB3) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
Date: Thu, 12 Jun 2025 01:14:53 +0300
From: Sergii Dmytruk 
To: ross.philipson@oracle.com
Cc: xen-devel@lists.xenproject.org, Jan Beulich ,
	Andrew Cooper ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	"Daniel P. Smith" ,
	trenchboot-devel@googlegroups.com
Subject: Re: [PATCH v3 04/22] x86/boot/slaunch-early: implement early
 initialization
Message-ID: 
References: 
 <16a544876163afece619d50f80869aaacc9c797c.1748611041.git.sergii.dmytruk@3mdeb.com>
 <5792bec7-cd2f-4d27-aa3b-f417b07c8ea8@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5792bec7-cd2f-4d27-aa3b-f417b07c8ea8@oracle.com>
X-Ovh-Tracer-Id: 18445055224532677788
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugddufeefiecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhepvdfgveegtdffhfdugeevieehkeetudevfeefgedtleejledvfeeutdetudeiveelnecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukeegrddvvddupdefjedrheelrddugedvrdduudegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheehtdgmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=PF45JHkS6yxBtHKhK/5xeoDWZAtphBhKMQ4IkDbNJbw=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1749680122; v=1;
 b=JN9zRCvOdlXYI0SwwSnbP4MBm7Am2Q5QYi+VXwPOppiupGHNuN43y/pm/UO4rK1IYmxepgi4
 5UnTNDVOUEWJAOb8E0H02fP92WXIGm42F13lNNJTvIuMxaO7BpHHRR+GaVSywplzENyDRuect3I
 TFZRgH//S+s1ycDhagz6WJVLypnpsn/CPLK00dxRPPjG+ktEpgwxsA1GXu1xeLc1bqQy/Y15qCL
 G7OB4su+INggzfhCMRe7KEz2k6bXYEjcUkSFBMMk1mDQLPmQo+PGH7h3XqnIboAZIHJd1PlRe/G
 PebFYSuWK78ENuzx4nsY2X6KWnFT9tpgcbGFox8o/jOxQ==

On Tue, Jun 03, 2025 at 09:17:29AM -0700, ross.philipson@oracle.com wrote:
> > +void asmlinkage slaunch_early_init(uint32_t load_base_addr,
> > +                                   uint32_t tgt_base_addr,
> > +                                   uint32_t tgt_end_addr,
> > +                                   struct early_init_results *result)
> > +{
> > +    void *txt_heap;
> > +    const struct txt_os_mle_data *os_mle;
> > +    const struct slr_table *slrt;
> > +    const struct slr_entry_intel_info *intel_info;
> > +
> > +    txt_heap = txt_init();
> > +    os_mle = txt_os_mle_data_start(txt_heap);
> > +
> > +    result->slrt_pa = os_mle->slrt;
> > +    result->mbi_pa = 0;
> > +
> > +    slrt = (const struct slr_table *)(uintptr_t)os_mle->slrt;
> > +
> > +    intel_info = (const struct slr_entry_intel_info *)
> > +        slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_INTEL_INFO);
> > +    if ( intel_info == NULL || intel_info->hdr.size != sizeof(*intel_info) )
> > +        return;
>
> Since these are the x86/TXT bits, it seems at this point, not finding the
> TXT info structure would be fatal, no?

It is fatal, but early code doesn't have means for reporting errors
nicely, so it just continues.  You think it's better to reboot right
away?

> > +static inline void *txt_init(void)
> > +{
> > +    void *txt_heap;
> > +
> > +    /* Clear the TXT error register for a clean start of the day. */
> > +    txt_write(TXTCR_ERRORCODE, 0);
> > +
> > +    txt_heap = _p(txt_read(TXTCR_HEAP_BASE));
> > +
> > +    if ( txt_os_mle_data_size(txt_heap) < sizeof(struct txt_os_mle_data) ||
> > +         txt_os_sinit_data_size(txt_heap) < sizeof(struct txt_os_sinit_data) )
> > +        txt_reset(SLAUNCH_ERROR_GENERIC);
>
> I know the list of error codes pulled in are from the patches for Linux
> Secure Launch which seems right. The Xen work is free to add more specific
> error codes e.g. somewhere like here. We could even consider using regions
> in the vendor error code space for different things like generic errors vs
> architecture specific ones vs etc.
>
> Thanks
> Ross

I think some codes were already added and this is the only place where
SLAUNCH_ERROR_GENERIC is used, not really sure why, will add a couple
more.  By the way, the new errors were inserted in the middle making
about half of the errors out of sync with Linux, should Xen and Linux be
in sync?

Not sure about usefulness of error regions, the errors codes are only
for TXT and major/minor errors in TXT.ERRORCODE weren't helpful in
debugging.

Regards


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 22:37:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 22:37:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012221.1390746 (Exim 4.92)
	(envelope-from )
	id 1uPU4J-00043J-Ig; Wed, 11 Jun 2025 22:37:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012221.1390746; Wed, 11 Jun 2025 22:37: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 1uPU4J-00043C-FH; Wed, 11 Jun 2025 22:37:15 +0000
Received: by outflank-mailman (input) for mailman id 1012221;
 Wed, 11 Jun 2025 22:37: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 1uPU4I-000436-W3
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 22:37:14 +0000
Received: from 1.mo575.mail-out.ovh.net (1.mo575.mail-out.ovh.net
 [46.105.41.146]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9e551084-4714-11f0-a307-13f23c93f187;
 Thu, 12 Jun 2025 00:37:13 +0200 (CEST)
Received: from director7.ghost.mail-out.ovh.net (unknown [10.109.140.75])
 by mo575.mail-out.ovh.net (Postfix) with ESMTP id 4bHgWr51RNz1fsH
 for ; Wed, 11 Jun 2025 22:37:12 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-fmjvw (unknown [10.110.118.5])
 by director7.ghost.mail-out.ovh.net (Postfix) with ESMTPS id BE370C01C6;
 Wed, 11 Jun 2025 22:37:11 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.97])
 by ghost-submission-5b5ff79f4f-fmjvw with ESMTPSA
 id U/H1IhcFSmiJBgUA2bOk2Q
 (envelope-from ); Wed, 11 Jun 2025 22:37: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: 9e551084-4714-11f0-a307-13f23c93f187
Authentication-Results:garm.ovh; auth=pass (GARM-97G002b78441d9-2dcf-4999-814f-59a31c23654c,
                    CF5C07F8BFC6FE4C0252D8DD6CF7CA7F095CBCB3) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
Date: Thu, 12 Jun 2025 01:36:44 +0300
From: Sergii Dmytruk 
To: ross.philipson@oracle.com
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" ,
	Jan Beulich ,
	Andrew Cooper ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	trenchboot-devel@googlegroups.com
Subject: Re: [PATCH v3 05/22] x86/boot/slaunch-early: early TXT checks and
 boot data retrieval
Message-ID: 
References: 
 
 <4ff41a13-1af9-4c87-ad6b-cd616b4d1840@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4ff41a13-1af9-4c87-ad6b-cd616b4d1840@oracle.com>
X-Ovh-Tracer-Id: 367043369900553372
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugddufeegudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhepvdfgveegtdffhfdugeevieehkeetudevfeefgedtleejledvfeeutdetudeiveelnecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukeegrddvvddupdefjedrheelrddugedvrdeljeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmpdhnsggprhgtphhtthhopedupdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdfovfetjfhoshhtpehmohehjeehmgdpmhhouggvpehsmhhtphhouhht
DKIM-Signature: a=rsa-sha256; bh=DKe/D5YYsQYWAntL4tHuj+vmsZ7qez3okCa6WA9eJE8=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1749681432; v=1;
 b=Ux3HnNp2snZUneMJikNUoQMosJhQhGyReZJK/uT5Gp2uO8Z90yYuZbjCIHkFG4P3DRSwPN9i
 0EPhJE8Faj4BmbawdPSl1tmXkzHOupiMW3WiorL8Fa5niVixaLmXsWMRix0HeTa59AgviOvg8Py
 He/p/xUR1YWF4xEGNr7tNljpg3M17mXinNdVs9UVX87QlyHM0VQDf+Fp7s4Co/KwTHhpZTrlzMo
 BQ1KuHPa86P+mhT3NfTB2Q12kujL763+34HQn/NkjNL7rhUbg6/oibDGY6mKDotrRoLynekSRvS
 1tj45ExoM50LF21PWCeFV135/6eQ0TLOFoFHQD9bt4kFw==

On Tue, Jun 03, 2025 at 10:03:31AM -0700, ross.philipson@oracle.com wrote:
> > From: Krystian Hebel 
> > 
> > The tests validate that important parts of memory are protected against
> > DMA attacks, including Xen and MBI. Modules can be tested later, when it
> > is possible to report issues to a user before invoking TXT reset.
> > 
> > TPM event log validation is temporarily disabled due to an issue with
> > its allocation by bootloader (GRUB) which will need to be modified to
> > address this. Ultimately event log will also have to be validated early
> > as it is used immediately after these tests to hold MBI measurements.
> > See larger comment in txt_verify_pmr_ranges().
> > 
> > Signed-off-by: Krystian Hebel 
> > Signed-off-by: Sergii Dmytruk 
> > ---

> > +static inline int is_in_pmr(const struct txt_os_sinit_data *os_sinit,
> > +                            uint64_t base, uint32_t size, int check_high)
>
> bool return val?

Will change.

> > +    /*
> > +     * ACM checks that TXT heap and MLE memory is protected against DMA. We have
> > +     * to check if MBI and whole Xen memory is protected. The latter is done in
> > +     * case bootloader failed to set whole image as MLE and to make sure that
> > +     * both pre- and post-relocation code is protected.
> > +     */
> > +
>
> Is this the full list of entities that should be covered by PMRs? I am
> thinking of entries in the SLR policy that should be covered. E.g. with
> Linux we ensure setup_data entry blobs are covered before measuring.

Xen's equivalent of setup_data is MBI which is checked below. Command-lines
of Xen and modules are part of MBI as well.

> > +    /* Check if all of Xen before relocation is covered by PMR. */
> > +    if ( !is_in_pmr(os_sinit, load_base_addr, xen_size, check_high_pmr) )
> > +        txt_reset(SLAUNCH_ERROR_LO_PMR_MLE);
> > +
> > +    /* Check if all of Xen after relocation is covered by PMR. */
> > +    if ( load_base_addr != tgt_base_addr &&
> > +         !is_in_pmr(os_sinit, tgt_base_addr, xen_size, check_high_pmr) )
> > +        txt_reset(SLAUNCH_ERROR_LO_PMR_MLE);
> > +
> > +    /*
> > +     * If present, check that MBI is covered by PMR. MBI starts with 'uint32_t
> > +     * total_size'.
> > +     */
> > +    if ( info->boot_params_base != 0 &&
> > +         !is_in_pmr(os_sinit, info->boot_params_base,
> > +                    *(uint32_t *)(uintptr_t)info->boot_params_base,
> > +                    check_high_pmr) )
> > +        txt_reset(SLAUNCH_ERROR_BUFFER_BEYOND_PMR);

> > +    /* Check if TPM event log (if present) is covered by PMR. */
> > +    /*
> > +     * FIXME: currently commented out as GRUB allocates it in a hole between
> > +     * PMR and reserved RAM, due to 2MB resolution of PMR. There are no other
> > +     * easy-to-use DMA protection mechanisms that would allow to protect that
> > +     * part of memory. TPR (TXT DMA Protection Range) gives 1MB resolution, but
> > +     * it still wouldn't be enough.
> > +     *
> > +     * One possible solution would be for GRUB to allocate log at lower address,
> > +     * but this would further increase memory space fragmentation. Another
> > +     * option is to align PMR up instead of down, making PMR cover part of
> > +     * reserved region, but it is unclear what the consequences may be.
>
> The consequences depend on the firmware. The failure mode we used to see was
> on some systems if the PMR covered certain areas marked as reserved, the
> system will hang at boot. In this particular case, firmware was trying to
> use an xHCI controller to get to the kb attached to use it at boot time.
> When DMA to the host controller was blocked, the firmware was unhappy. We
> have not seen this issue in a while and the current logic in the prologue
> code just sets the upper bound to the highest RAM area below 4Gb which is
> optimal.
>
> The most correct solution for PMRs is to read the VTd RMRR structures. These
> can tell you what reserved regions should not be blocked like this (if any).
> This will give more control over the best configuration for the PMRs and
> what to avoid. This needs to be done in the prologue code and validated in
> the DLME.
>
> And yea, TPR support too where available.
>
> Thanks
> Ross

I guess this needs checking whether it's still an issue.

Regards


From xen-devel-bounces@lists.xenproject.org Wed Jun 11 23:59:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jun 2025 23:59:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012240.1390755 (Exim 4.92)
	(envelope-from )
	id 1uPVLU-00058j-5z; Wed, 11 Jun 2025 23:59:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012240.1390755; Wed, 11 Jun 2025 23:59: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 1uPVLU-00058c-2o; Wed, 11 Jun 2025 23:59:04 +0000
Received: by outflank-mailman (input) for mailman id 1012240;
 Wed, 11 Jun 2025 23:59: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 1uPVLS-00058W-Pp
 for xen-devel@lists.xenproject.org; Wed, 11 Jun 2025 23:59:02 +0000
Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com
 [2a00:1450:4864:20::342])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 09060573-4720-11f0-a307-13f23c93f187;
 Thu, 12 Jun 2025 01:58:56 +0200 (CEST)
Received: by mail-wm1-x342.google.com with SMTP id
 5b1f17b1804b1-4531e146a24so2080645e9.0
 for ; Wed, 11 Jun 2025 16:58:56 -0700 (PDT)
Received: from localhost.localdomain ([90.250.112.104])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4532e184724sm3566455e9.39.2025.06.11.16.58.54
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 11 Jun 2025 16:58:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 09060573-4720-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749686336; x=1750291136; 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=h6MWbAKcuk3fHPEz4Zkywxz3C8dCusIunQU56r3S87Q=;
        b=hIMCFokR6XhjjAW1C/5Z9qeG7A+XNyknFNVezULULgK6iVcbNKN54w6ICj4U80SbKX
         aoh3TahK726BK/V5pOrdSA992bqsbnI4iaDFLa7rKD60ehmDfigYh4kXvfgtxHJiSGGD
         8svIxrNle3pzzeVqVUwHeEvLvbuPqbt7dZx9I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749686336; x=1750291136;
        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=h6MWbAKcuk3fHPEz4Zkywxz3C8dCusIunQU56r3S87Q=;
        b=WCkCAVi6QWgny7L9cyc5s6BllSLQ6WIG5kY8NjUpoDpuubXInvOwBDAMH26Z+aODzH
         OpylcN7r0PLSTqZatNWax6bdLMcJ4IYMOJWuGDkBIvkGgodyBpd24bEC59PLjhH7G1uT
         Mgk/7hMChJaIYZCUEi1Pb46YnXjmXbCgIU4RMCwwFzU2CdKtKzG/zagBR4D++PB7qiRg
         2h0dmwRUvD8eMvcFuLQFjVT5msRPY3UZPTqA9+zMoV8Ot5dKEwM9QkwpVd5wn242gSEI
         0s4Pgg6710QKtGF87Z8Byv5R4esoj+DBVc2rHu/Zg1DhIvczHN22ubSO02gEknNd+3pw
         49/g==
X-Gm-Message-State: AOJu0YzGgfRKJ+EiiVGjXqFpqMFTxv1Vc3GBfkyU+8clmg4zuKV5wO53
	EAXXRQgJxd5wPK42PSzvHP2KKX3vBPWeRRFenQMqviEjq8AGO4diLqN/Zo9i5KRZwS51P7R7AXa
	D4xkcYqPmpNWM
X-Gm-Gg: ASbGncuBq5EkFmbI9pNstp+SYRfIUST4k5wvjktX85WXKSVMxSU62+V30VIIS5WiIxt
	W4TbJZ7aaNuV1Qlm5sTK/X3HqFSyHVm8ergY87YAT5gItdKSsHbfBOUshKdKwP5VMzFXpa55PIa
	MPDLuE9SE958AH1VOMlGmOn0sxMmyTHClSQ+ohLfh5WExJ9ZA1EWl5AN3cb2x2/L/oINIch88MC
	Zq0PiNMXvldTG/qIUbWtDRglUsMLZ7udnZ0OqOSixOBABmNfSuMkLVqz1+cLSuGKqeehHcN4tsi
	ZT70LDIu2sZbR5txzDbw8h7o4epwrVcqLLUOhTbVts7icdjaNXrUyVegnAe2y83BqjoZJaCxttI
	5de4Aqso=
X-Google-Smtp-Source: AGHT+IHGSsasnW3ayYfKHZVjqaJI0vtLfeRe1eWojD+3nXo40OV8Njzni2DEnjyp2Qvg01fCdmNbeg==
X-Received: by 2002:a05:600c:6612:b0:44a:ac77:26d5 with SMTP id 5b1f17b1804b1-4532487b346mr54028405e9.14.1749686335749;
        Wed, 11 Jun 2025 16:58:55 -0700 (PDT)
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 ,
	security@xen.org,
	Juergen Gross ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Trammell Hudson ,
	Ross Lagerwall ,
	Frediano Ziglio ,
	Gerald Elder-Vass ,
	Kevin Lampis 
Subject: [PATCH] docs: UEFI Secure Boot security policy
Date: Thu, 12 Jun 2025 00:58:51 +0100
Message-Id: <20250611235851.167385-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

Written to be solution and deployment neutral in order to focus on the
technology itself.  This policy is intended to work as well for UKI as for the
"classic server setup" approach.

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: security@xen.org
CC: Juergen Gross 
CC: Marek Marczykowski-Górecki 
CC: Trammell Hudson 
CC: Ross Lagerwall 
CC: Frediano Ziglio 
CC: Gerald Elder-Vass 
CC: Kevin Lampis 

A rendered version is available at:
  https://andrewcoop-xen.readthedocs.io/en/docs-secureboot/admin-guide/uefi-secure-boot.html

Obviously RFC at this point.  It's worth saying that XenServer is intending to
use Shim and get a signature from Microsoft, retaining all exiting features
such as Livepatching and Kexec crash reporting.

This trails off into more TODOs towards the end.  Individual tasks should
expand on the start made and resulting conversation from this thread.  As a
reminder, the target audience for this doc is an administrator running a Xen
deployment, but who is not necesserily a developer.

Several things are hard to express and want further discussion.  Suggestions
welcome:

1) Content of CONFIG_CMDLINE and the various CONFIG_*_DEFAULT options.  Xen is
not going to be issuing XSAs for "downstream chose an unsafe configuration,
then signed and deployed the result", yet Xen probably should be on the hook
for bad "default ..." settings in Kconfig.

2) Pre-boot DMA Protection.  Microsoft consider this a platform feature
requiring OEM enablement, and do not consider its absence to be a Secure Boot
vulnerability.  But, it is less clear what the policy ought to be for Xen
booting on a capable system and failing to do a correct live-handover of the
IOMMU across ExitBootServices().

3) The AMD microcode signature vulnerability.  While it's not Xen's bug per
say, it's clearly a Secure Boot bypass because we do offer microcode loading
capabilties to userspace, and malicious userspace can load an unauthorised
microcode which allows them to read/write physical memory and bypass further
signature checks.

4) Userspace Hypercalls.  To anyone who isn't already aware, /dev/xen/privcmd
in the various Unicies is a giant priv-esc hole, as root userspace can
e.g. issue direct memory hypercalls behind the back of an (intentionally)
oblivious kernel, and cannot be handwaved away as "it's fine because it's
root" under Secure Boot.  It's not a Xen vuln (Xen *does* audit pointers in
guest hypercalls), but it is a guest kernel vuln because of failing to
correctly audit hypercall parameters.  However, it does require substantial
changes in Xen in order to allow guest kernels to do something half-way safe.
---
 docs/admin-guide/index.rst            |   1 +
 docs/admin-guide/uefi-secure-boot.rst | 134 ++++++++++++++++++++++++++
 2 files changed, 135 insertions(+)
 create mode 100644 docs/admin-guide/uefi-secure-boot.rst

diff --git a/docs/admin-guide/index.rst b/docs/admin-guide/index.rst
index 54e6f65de347..e7895ee95001 100644
--- a/docs/admin-guide/index.rst
+++ b/docs/admin-guide/index.rst
@@ -5,4 +5,5 @@ Admin Guide
 
 .. toctree::
    introduction
+   uefi-secure-boot
    microcode-loading
diff --git a/docs/admin-guide/uefi-secure-boot.rst b/docs/admin-guide/uefi-secure-boot.rst
new file mode 100644
index 000000000000..0e0f50143892
--- /dev/null
+++ b/docs/admin-guide/uefi-secure-boot.rst
@@ -0,0 +1,134 @@
+.. SPDX-License-Identifier: CC-BY-4.0
+
+UEFI Secure Boot
+================
+
+UEFI Secure Boot is a verification mechanism, intended to ensure that only
+code trusted by the platform can run.  This is to prevent malicious code from
+hijacking the system.  Secure Boot requires that all privileged code be
+signed, and that there is a trust relationship with the platform; i.e. code
+which is not signed by a key enrolled in platform must not run privileged.
+
+Within the Xen architecture, Xen, the :term:`control domain` and
+:term:`hardware domain` share responsibility for running and administering the
+platform.  This makes their kernels privileged as far as Secure Boot is
+concerned.
+
+When Secure Boot is active in the platform, privileged code is required to not
+run any untrusted code (i.e. not run any code for which there is not a good
+signature), and is required not to allow this restriction to be bypassed
+(e.g. by command line request).
+
+
+Support in Xen
+--------------
+
+There are multiple ways to achieve this security goal, with differing
+tradeoffs for the eventual system.
+
+On one end of the spectrum is the Unified Kernel Image.  e.g. Xen is bundled
+with the dom0 kernel and init-ramdisk, with an embedded command line, and with
+livepatching and kexec compiled out, and suitably signed.  The signature is
+checked by the bootloader and, as this covers all the privileged code, Xen
+doesn't need to perform further checks itself.
+
+On the other end of the spectrum is maintaining the features of existing
+deployments.  e.g. Xen needs signature checking capabilities for the dom0
+kernel, livepatches and kexec kernels, and needs to allow the use of safe
+command line options while disallowing unsafe ones.
+
+It is important to remember that Xen is one piece of the larger platform,
+where every piece depends on the correct functioning of all earlier pieces.  A
+product supporting Secure Boot requires a holistic approach involving all
+components in the system.  It is not sufficient to consider Xen in isolation.
+
+.. TODO: Move "In Progress" tasks here as they become ready
+
+Security Scope
+--------------
+
+Vulnerabilities impacting Secure Boot require a fixed component to be produced
+and distributed, the vulnerable component to be revoked, and the revocation
+distributed to platforms.
+
+The following principles and guidelines indicate where Secure Boot differs
+from more traditional security models, and the situations in which extra
+remediation may be necessary.
+
+Principles
+^^^^^^^^^^
+
+ * Privileged code shall include Xen and the kernel(s) of the control and
+   hardware domain (both, if they're split).  While there is a privilege split
+   here in Xen's regular security model, they are equal from Secure Boot's
+   point of view.
+
+ * Root or ADMIN in userspace is unprivileged from Secure Boot's point of
+   view, and must not be able to alter the enforcement policy or load unsigned
+   code even by e.g. editing a configuration file and rebooting.
+
+Within Scope
+^^^^^^^^^^^^
+
+The following types of issue require remediation and revocation of vulnerable
+binaries.
+
+ * Any failure to apply enforcements even against traditionally-privileged
+   userspace, including failure to authenticate new code to run and failure to
+   handle revocations properly.
+
+ * Any Out-of-Bounds write capable of altering the enforcement policy, or
+   capable of bypassing enforcement, e.g. by corrupting the running code.
+
+Out of Scope
+^^^^^^^^^^^^
+
+While typically a security issue in their own rights, these issues do not
+constitute a Secure Boot vulnerability, and do not require special
+remediation.
+
+ * Denial of Service vulnerabilities.
+
+ * Out-of-Bounds reads.
+
+The Xen Security Team will endeavour to produce XSAs for all violations of
+this security policy, including identifying them specifically as requiring
+further remediation by downstreams.
+
+
+In Progress
+-----------
+
+.. warning::
+
+   The following work is still in progress.  It is provisional, and not
+   security supported yet.
+
+
+Secure Boot Advanced Targeting
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+SBAT is a recovation scheme for Secure Boot enabled components, using a
+generation based scheme.  See `Shim SBAT.md
+`_ for full details.
+
+Upstream Xen provides the infrastructure to embed SBAT metadata in
+``xen.efi``, but does not maintain a generation number itself.  Downstreams
+are expected to maintain their own generation numbers.
+
+
+Lockdown Mode
+^^^^^^^^^^^^^
+
+A mode which causes the enforcement of the properties necessary to conform to
+the Secure Boot specification.  Lockdown Mode is forced active when Secure
+Boot is active in the platform, but may be activated independently too for
+development purposes with the ``lockdown`` command line option.
+
+TODO
+^^^^
+
+ * Command Line
+ * Livepatching
+ * Kexec
+ * Userspace hypercalls
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu Jun 12 00:02:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 00:02:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012250.1390766 (Exim 4.92)
	(envelope-from )
	id 1uPVOW-0007La-5X; Thu, 12 Jun 2025 00:02:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012250.1390766; Thu, 12 Jun 2025 00: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 1uPVOW-0007LT-1S; Thu, 12 Jun 2025 00:02:12 +0000
Received: by outflank-mailman (input) for mailman id 1012250;
 Thu, 12 Jun 2025 00: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 1uPVOU-0007LN-Ia
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 00:02:10 +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 7b835d81-4720-11f0-a307-13f23c93f187;
 Thu, 12 Jun 2025 02:02:09 +0200 (CEST)
Received: by mail-qt1-x832.google.com with SMTP id
 d75a77b69052e-4a58e0b26c4so6344791cf.3
 for ; Wed, 11 Jun 2025 17:02:09 -0700 (PDT)
Received: from [10.138.10.6] ([89.187.178.201])
 by smtp.gmail.com with ESMTPSA id
 d75a77b69052e-4a72475b774sm3258331cf.32.2025.06.11.17.02.06
 for 
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 17:02:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7b835d81-4720-11f0-a307-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749686528; x=1750291328; 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=IirsFKR2KGHzCVoiPPxC4rjmPNxAn0Z1MtiZz0+qkyM=;
        b=gYFiRnOxpsA0HSYAyMKeYmBUFNCn9BevfXRrTguk1wNW9w39sxFTHFKD+ziyiOW8rJ
         JaZ2b42FFNATcQa4EsrC5B1z5ORL0bhcbNjtkHtafBX4A7ziK9y3/XhlgTTUyluUJrCQ
         UwK34UJNaG4LdXBh/ZowOv7DDivnJDIkhChUBEVQh9pnFJDAIot53MWupMhtmBzqQOZP
         iX79odRvze+QqJ3wLEtO4XAUm88tzHZQZINyXZaLk7x3DNdyR6bKSo+gLgYrRfHkiK4L
         NOmkMNylmt+3qpmPHlo9gH6UXtSgMM4hsBnLiV0JaulzMUGPQijSreQZDg4J58cGQZJl
         Dl6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749686528; x=1750291328;
        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=IirsFKR2KGHzCVoiPPxC4rjmPNxAn0Z1MtiZz0+qkyM=;
        b=hCby2kLQLi11YuBLK6WL5Nib5wtfQk3hqP4mfEyF3RmaDTZ44ft/tGbgUHGUQKGwyN
         5hV6kaVhnM2RCv6hqevpTN6gaQC1f8+TVmqpSYZqnaqwuyWKxu8za/FjvPaKOcVomeU7
         Keg7nguA7u3N5WqIAF/9gTMEApXf6nJsxvt0BS3Ku70acrvImhNL1IKoRk6+JB4q3gH8
         FS9uFoBYZf9gy7YC0jP9JsWzGuoxCPBz4x2O/JkM8XmbPLKQHLO65/My0otyggc2Em8k
         yhcVdS3AO/ku9IttP3VBXLvAemAvHg15TI+KtswD5ijp8JlIEbLBUUvjKhME7ZU0dAnr
         CHHw==
X-Gm-Message-State: AOJu0YxIQg3zo9gmKPBuMtJfPpNaOcFLNmHWY/pgFYkvwBaPZT8zbtEy
	PKgWC9ptwAZY5+ySsvnLCN2TFdqJSRvHN4bDha/OVu3u0Hsd5p2qTtoqxlTGbw==
X-Gm-Gg: ASbGncuUES9mnejtZlIjSxEfAa4AylaFxPMrg1xWy4vIMoiOWo6l5hvp0BgBk68RGuj
	GKreg9HGZ4Y3usU6wXDRsOcnKYcgO8cTsV/p7bNWGqKLP+zOyOZoVohs2y2OFvV1R0X7WMdZPmn
	6jE3fEtJBvFMsv9D83h5Ky4jsOWSYKfuowa7Aj3tg60ZbHFfpKSccVDPkLjh9aF/LdES+pKCZEj
	X0i7K/dnBzwN6QDgFuopr1n0DhaxUKf9Qj29gaxHJFx8uet2tfBV61cvk+UMhFuZlJe0idtLfFg
	g0+IP7/lmsSDkenCY6rcQY4EW8aGuUs0MoHVA4rr7zUZnVf8sTWzfYJPjOJNYKdkRihY3xzJf5b
	fBw==
X-Google-Smtp-Source: AGHT+IF4xobj1VWQ1mt/pBPifGEnielR+WiaIhYDoaAYE/uFDByZnN6gsDGVmw2b7gyOfbmllrTOzQ==
X-Received: by 2002:ac8:6f0c:0:b0:4a2:719b:1238 with SMTP id d75a77b69052e-4a7228eccc1mr27066111cf.12.1749686527610;
        Wed, 11 Jun 2025 17:02:07 -0700 (PDT)
Message-ID: <70bb6971-2e61-4788-a44c-635b2070255d@gmail.com>
Date: Wed, 11 Jun 2025 20:02:00 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] docs: UEFI Secure Boot security policy
To: xen-devel@lists.xenproject.org
References: <20250611235851.167385-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Demi Marie Obenour 
Autocrypt: addr=demiobenour@gmail.com; keydata=
 xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49yB+l2nipd
 aq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYfbWpr/si88QKgyGSV
 Z7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/UorR+FaSuVwT7rqzGrTlscnT
 DlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7MMPCJwI8JpPlBedRpe9tfVyfu3euTPLPx
 wcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9Hzx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR
 6h3nBc3eyuZ+q62HS1pJ5EvUT1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl
 5FMWo8TCniHynNXsBtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2
 Bkg1b//r6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nSm9BBff0N
 m0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQABzTxEZW1pIE1hcmll
 IE9iZW5vdXIgKGxvdmVyIG9mIGNvZGluZykgPGRlbWlvYmVub3VyQGdtYWlsLmNvbT7CwXgE
 EwECACIFAlp+A0oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELKItV//nCLBhr8Q
 AK/xrb4wyi71xII2hkFBpT59ObLN+32FQT7R3lbZRjVFjc6yMUjOb1H/hJVxx+yo5gsSj5LS
 9AwggioUSrcUKldfA/PKKai2mzTlUDxTcF3vKx6iMXKA6AqwAw4B57ZEJoMM6egm57TV19kz
 PMc879NV2nc6+elaKl+/kbVeD3qvBuEwsTe2Do3HAAdrfUG/j9erwIk6gha/Hp9yZlCnPTX+
 VK+xifQqt8RtMqS5R/S8z0msJMI/ajNU03kFjOpqrYziv6OZLJ5cuKb3bZU5aoaRQRDzkFIR
 6aqtFLTohTo20QywXwRa39uFaOT/0YMpNyel0kdOszFOykTEGI2u+kja35g9TkH90kkBTG+a
 EWttIht0Hy6YFmwjcAxisSakBuHnHuMSOiyRQLu43ej2+mDWgItLZ48Mu0C3IG1seeQDjEYP
 tqvyZ6bGkf2Vj+L6wLoLLIhRZxQOedqArIk/Sb2SzQYuxN44IDRt+3ZcDqsPppoKcxSyd1Ny
 2tpvjYJXlfKmOYLhTWs8nwlAlSHX/c/jz/ywwf7eSvGknToo1Y0VpRtoxMaKW1nvH0OeCSVJ
 itfRP7YbiRVc2aNqWPCSgtqHAuVraBRbAFLKh9d2rKFB3BmynTUpc1BQLJP8+D5oNyb8Ts4x
 Xd3iV/uD8JLGJfYZIR7oGWFLP4uZ3tkneDfYzsFNBFp+A0oBEAC9ynZI9LU+uJkMeEJeJyQ/
 8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd8xD57ue0eB47bcJv
 VqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPpI4gfUbVEIEQuqdqQyO4GAe+M
 kD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalql1/iSyv1WYeC1OAs+2BLOAT2NEggSiVO
 txEfgewsQtCWi8H1SoirakIfo45Hz0tk/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJ
 riwoaRIS8N2C8/nEM53jb1sH0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcN
 fRAIUrNlatj9TxwivQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6
 dCxN0GNAORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
 rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog2LNtcyCj
 kTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZAgrrnNz0iZG2DVx46
 x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJELKItV//nCLBwNIP/AiIHE8b
 oIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwjjVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGj
 gn0TPtsGzelyQHipaUzEyrsceUGWYoKXYyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8fr
 RHnJdBcjf112PzQSdKC6kqU0Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2
 E0rW4tBtDAn2HkT9uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHM
 OBvy3EhzfAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
 Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVssZ/rYZ9+5
 1yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aWemLLszcYz/u3XnbO
 vUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPthZlDnTnOT+C+OTsh8+m5tos8
 HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E
 +MYSfkEjBz0E8CLOcAw7JIwAaeBT
In-Reply-To: <20250611235851.167385-1-andrew.cooper3@citrix.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------OimbzeVUm0WiME0J0ubnZ5tN"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------OimbzeVUm0WiME0J0ubnZ5tN
Content-Type: multipart/mixed; boundary="------------hxwS10Iz5cdlVgj6EKb6kEDa";
 protected-headers="v1"
From: Demi Marie Obenour 
To: xen-devel@lists.xenproject.org
Message-ID: <70bb6971-2e61-4788-a44c-635b2070255d@gmail.com>
Subject: Re: [PATCH] docs: UEFI Secure Boot security policy
References: <20250611235851.167385-1-andrew.cooper3@citrix.com>
In-Reply-To: <20250611235851.167385-1-andrew.cooper3@citrix.com>

--------------hxwS10Iz5cdlVgj6EKb6kEDa
Content-Type: multipart/mixed; boundary="------------Vcj05XZj5Uy2HAspGQMVG8ok"

--------------Vcj05XZj5Uy2HAspGQMVG8ok
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 6/11/25 19:58, Andrew Cooper wrote:
> Written to be solution and deployment neutral in order to focus on the
> technology itself.  This policy is intended to work as well for UKI as =
for the
> "classic server setup" approach.
>=20
> Signed-off-by: Andrew Cooper 
> ---
> CC: Anthony PERARD 
> CC: Michal Orzel 
> CC: Jan Beulich 
> CC: Julien Grall 
> CC: Roger Pau Monn=C3=A9 
> CC: Stefano Stabellini 
> CC: security@xen.org
> CC: Juergen Gross 
> CC: Marek Marczykowski-G=C3=B3recki 
> CC: Trammell Hudson 
> CC: Ross Lagerwall 
> CC: Frediano Ziglio 
> CC: Gerald Elder-Vass 
> CC: Kevin Lampis 
>=20
> A rendered version is available at:
>   https://andrewcoop-xen.readthedocs.io/en/docs-secureboot/admin-guide/=
uefi-secure-boot.html
>=20
> Obviously RFC at this point.  It's worth saying that XenServer is inten=
ding to
> use Shim and get a signature from Microsoft, retaining all exiting feat=
ures
> such as Livepatching and Kexec crash reporting.
>=20
> This trails off into more TODOs towards the end.  Individual tasks shou=
ld
> expand on the start made and resulting conversation from this thread.  =
As a
> reminder, the target audience for this doc is an administrator running =
a Xen
> deployment, but who is not necesserily a developer.
>=20
> Several things are hard to express and want further discussion.  Sugges=
tions
> welcome:
>=20
> 1) Content of CONFIG_CMDLINE and the various CONFIG_*_DEFAULT options. =
 Xen is
> not going to be issuing XSAs for "downstream chose an unsafe configurat=
ion,
> then signed and deployed the result", yet Xen probably should be on the=
 hook
> for bad "default ..." settings in Kconfig.
>=20
> 2) Pre-boot DMA Protection.  Microsoft consider this a platform feature=

> requiring OEM enablement, and do not consider its absence to be a Secur=
e Boot
> vulnerability.  But, it is less clear what the policy ought to be for X=
en
> booting on a capable system and failing to do a correct live-handover o=
f the
> IOMMU across ExitBootServices().
>=20
> 3) The AMD microcode signature vulnerability.  While it's not Xen's bug=
 per
> say, it's clearly a Secure Boot bypass because we do offer microcode lo=
ading
> capabilties to userspace, and malicious userspace can load an unauthori=
sed
> microcode which allows them to read/write physical memory and bypass fu=
rther
> signature checks.
>=20
> 4) Userspace Hypercalls.  To anyone who isn't already aware, /dev/xen/p=
rivcmd
> in the various Unicies is a giant priv-esc hole, as root userspace can
> e.g. issue direct memory hypercalls behind the back of an (intentionall=
y)
> oblivious kernel, and cannot be handwaved away as "it's fine because it=
's
> root" under Secure Boot.  It's not a Xen vuln (Xen *does* audit pointer=
s in
> guest hypercalls), but it is a guest kernel vuln because of failing to
> correctly audit hypercall parameters.  However, it does require substan=
tial
> changes in Xen in order to allow guest kernels to do something half-way=
 safe.
> ---
>  docs/admin-guide/index.rst            |   1 +
>  docs/admin-guide/uefi-secure-boot.rst | 134 ++++++++++++++++++++++++++=

>  2 files changed, 135 insertions(+)
>  create mode 100644 docs/admin-guide/uefi-secure-boot.rst
>=20
> diff --git a/docs/admin-guide/index.rst b/docs/admin-guide/index.rst
> index 54e6f65de347..e7895ee95001 100644
> --- a/docs/admin-guide/index.rst
> +++ b/docs/admin-guide/index.rst
> @@ -5,4 +5,5 @@ Admin Guide
> =20
>  .. toctree::
>     introduction
> +   uefi-secure-boot
>     microcode-loading
> diff --git a/docs/admin-guide/uefi-secure-boot.rst b/docs/admin-guide/u=
efi-secure-boot.rst
> new file mode 100644
> index 000000000000..0e0f50143892
> --- /dev/null
> +++ b/docs/admin-guide/uefi-secure-boot.rst
> @@ -0,0 +1,134 @@
> +.. SPDX-License-Identifier: CC-BY-4.0
> +
> +UEFI Secure Boot
> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> +
> +UEFI Secure Boot is a verification mechanism, intended to ensure that =
only
> +code trusted by the platform can run.  This is to prevent malicious co=
de from
> +hijacking the system.  Secure Boot requires that all privileged code b=
e
> +signed, and that there is a trust relationship with the platform; i.e.=
 code
> +which is not signed by a key enrolled in platform must not run privile=
ged.
> +
> +Within the Xen architecture, Xen, the :term:`control domain` and
> +:term:`hardware domain` share responsibility for running and administe=
ring the
> +platform.  This makes their kernels privileged as far as Secure Boot i=
s
> +concerned.
> +
> +When Secure Boot is active in the platform, privileged code is require=
d to not
> +run any untrusted code (i.e. not run any code for which there is not a=
 good
> +signature), and is required not to allow this restriction to be bypass=
ed
> +(e.g. by command line request).
> +
> +
> +Support in Xen
> +--------------
> +
> +There are multiple ways to achieve this security goal, with differing
> +tradeoffs for the eventual system.
> +
> +On one end of the spectrum is the Unified Kernel Image.  e.g. Xen is b=
undled
> +with the dom0 kernel and init-ramdisk, with an embedded command line, =
and with
> +livepatching and kexec compiled out, and suitably signed.  The signatu=
re is
> +checked by the bootloader and, as this covers all the privileged code,=
 Xen
> +doesn't need to perform further checks itself.
> +
> +On the other end of the spectrum is maintaining the features of existi=
ng
> +deployments.  e.g. Xen needs signature checking capabilities for the d=
om0
> +kernel, livepatches and kexec kernels, and needs to allow the use of s=
afe
> +command line options while disallowing unsafe ones.
> +
> +It is important to remember that Xen is one piece of the larger platfo=
rm,
> +where every piece depends on the correct functioning of all earlier pi=
eces.  A
> +product supporting Secure Boot requires a holistic approach involving =
all
> +components in the system.  It is not sufficient to consider Xen in iso=
lation.
> +
> +.. TODO: Move "In Progress" tasks here as they become ready
> +
> +Security Scope
> +--------------
> +
> +Vulnerabilities impacting Secure Boot require a fixed component to be =
produced
> +and distributed, the vulnerable component to be revoked, and the revoc=
ation
> +distributed to platforms.
> +
> +The following principles and guidelines indicate where Secure Boot dif=
fers
> +from more traditional security models, and the situations in which ext=
ra
> +remediation may be necessary.
> +
> +Principles
> +^^^^^^^^^^
> +
> + * Privileged code shall include Xen and the kernel(s) of the control =
and
> +   hardware domain (both, if they're split).  While there is a privile=
ge split
> +   here in Xen's regular security model, they are equal from Secure Bo=
ot's
> +   point of view.
> +
> + * Root or ADMIN in userspace is unprivileged from Secure Boot's point=
 of
> +   view, and must not be able to alter the enforcement policy or load =
unsigned
> +   code even by e.g. editing a configuration file and rebooting.
> +
> +Within Scope
> +^^^^^^^^^^^^
> +
> +The following types of issue require remediation and revocation of vul=
nerable
> +binaries.
> +
> + * Any failure to apply enforcements even against traditionally-privil=
eged
> +   userspace, including failure to authenticate new code to run and fa=
ilure to
> +   handle revocations properly.
> +
> + * Any Out-of-Bounds write capable of altering the enforcement policy,=
 or
> +   capable of bypassing enforcement, e.g. by corrupting the running co=
de.
> +
> +Out of Scope
> +^^^^^^^^^^^^
> +
> +While typically a security issue in their own rights, these issues do =
not
> +constitute a Secure Boot vulnerability, and do not require special
> +remediation.
> +
> + * Denial of Service vulnerabilities.
> +
> + * Out-of-Bounds reads.
> +
> +The Xen Security Team will endeavour to produce XSAs for all violation=
s of
> +this security policy, including identifying them specifically as requi=
ring
> +further remediation by downstreams.
> +
> +
> +In Progress
> +-----------
> +
> +.. warning::
> +
> +   The following work is still in progress.  It is provisional, and no=
t
> +   security supported yet.
> +
> +
> +Secure Boot Advanced Targeting
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +SBAT is a recovation scheme for Secure Boot enabled components, using =
a
> +generation based scheme.  See `Shim SBAT.md
> +`_ for full details.=

> +
> +Upstream Xen provides the infrastructure to embed SBAT metadata in
> +``xen.efi``, but does not maintain a generation number itself.  Downst=
reams
> +are expected to maintain their own generation numbers.
> +
> +
> +Lockdown Mode
> +^^^^^^^^^^^^^
> +
> +A mode which causes the enforcement of the properties necessary to con=
form to
> +the Secure Boot specification.  Lockdown Mode is forced active when Se=
cure
> +Boot is active in the platform, but may be activated independently too=
 for
> +development purposes with the ``lockdown`` command line option.
> +
> +TODO
> +^^^^
> +
> + * Command Line
> + * Livepatching
> + * Kexec
> + * Userspace hypercalls

This is so much more reasonable than Linux's policy.  I wonder how often =
Linux
would need to revoke if it followed a policy like this.
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
--------------Vcj05XZj5Uy2HAspGQMVG8ok
Content-Type: application/pgp-keys; name="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

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

xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49y
B+l2nipdaq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYf
bWpr/si88QKgyGSVZ7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/
UorR+FaSuVwT7rqzGrTlscnTDlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7M
MPCJwI8JpPlBedRpe9tfVyfu3euTPLPxwcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9H
zx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR6h3nBc3eyuZ+q62HS1pJ5EvU
T1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl5FMWo8TCniHynNXs
BtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2Bkg1b//r
6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nS
m9BBff0Nm0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQAB
zTxEZW1pIE9iZW5vdXIgKElUTCBFbWFpbCBLZXkpIDxhdGhlbmFAaW52aXNpYmxl
dGhpbmdzbGFiLmNvbT7CwY4EEwEIADgWIQR2h02fEza6IlkHHHGyiLVf/5wiwQUC
X6YJvQIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRCyiLVf/5wiwWRhD/0Y
R+YYC5Kduv/2LBgQJIygMsFiRHbR4+tWXuTFqgrxxFSlMktZ6gQrQCWe38WnOXkB
oY6n/5lSJdfnuGd2UagZ/9dkaGMUkqt+5WshLFly4BnP7pSsWReKgMP7etRTwn3S
zk1OwFx2lzY1EnnconPLfPBc6rWG2moA6l0WX+3WNR1B1ndqpl2hPSjT2jUCBWDV
rGOUSX7r5f1WgtBeNYnEXPBCUUM51pFGESmfHIXQrqFDA7nBNiIVFDJTmQzuEqIy
Jl67pKNgooij5mKzRhFKHfjLRAH4mmWZlB9UjDStAfFBAoDFHwd1HL5VQCNQdqEc
/9lZDApqWuCPadZN+pGouqLysesIYsNxUhJ7dtWOWHl0vs7/3qkWmWun/2uOJMQh
ra2u8nA9g91FbOobWqjrDd6x3ZJoGQf4zLqjmn/P514gb697788e573WN/MpQ5XI
Fl7aM2d6/GJiq6LC9T2gSUW4rbPBiqOCeiUx7Kd/sVm41p9TOA7fEG4bYddCfDsN
xaQJH6VRK3NOuBUGeL+iQEVF5Xs6Yp+U+jwvv2M5Lel3EqAYo5xXTx4ls0xaxDCu
fudcAh8CMMqx3fguSb7Mi31WlnZpk0fDuWQVNKyDP7lYpwc4nCCGNKCj622ZSocH
AcQmX28L8pJdLYacv9pU3jPy4fHcQYvmTavTqowGnM08RGVtaSBNYXJpZSBPYmVu
b3VyIChsb3ZlciBvZiBjb2RpbmcpIDxkZW1pb2Jlbm91ckBnbWFpbC5jb20+wsF4
BBMBAgAiBQJafgNKAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCyiLVf
/5wiwYa/EACv8a2+MMou9cSCNoZBQaU+fTmyzft9hUE+0d5W2UY1RY3OsjFIzm9R
/4SVccfsqOYLEo+S0vQMIIIqFEq3FCpXXwPzyimotps05VA8U3Bd7yseojFygOgK
sAMOAee2RCaDDOnoJue01dfZMzzHPO/TVdp3OvnpWipfv5G1Xg96rwbhMLE3tg6N
xwAHa31Bv4/Xq8CJOoIWvx6fcmZQpz01/lSvsYn0KrfEbTKkuUf0vM9JrCTCP2oz
VNN5BYzqaq2M4r+jmSyeXLim922VOWqGkUEQ85BSEemqrRS06IU6NtEMsF8EWt/b
hWjk/9GDKTcnpdJHTrMxTspExBiNrvpI2t+YPU5B/dJJAUxvmhFrbSIbdB8umBZs
I3AMYrEmpAbh5x7jEjoskUC7uN3o9vpg1oCLS2ePDLtAtyBtbHnkA4xGD7ar8mem
xpH9lY/i+sC6CyyIUWcUDnnagKyJP0m9ks0GLsTeOCA0bft2XA6rD6aaCnMUsndT
ctrab42CV5XypjmC4U1rPJ8JQJUh1/3P48/8sMH+3krxpJ06KNWNFaUbaMTGiltZ
7x9DngklSYrX0T+2G4kVXNmjaljwkoLahwLla2gUWwBSyofXdqyhQdwZsp01KXNQ
UCyT/Pg+aDcm/E7OMV3d4lf7g/CSxiX2GSEe6BlhSz+Lmd7ZJ3g32M1ARGVtaSBN
YXJpZSBPYmVub3VyIChJVEwgRW1haWwgS2V5KSA8ZGVtaUBpbnZpc2libGV0aGlu
Z3NsYWIuY29tPsLBjgQTAQgAOBYhBHaHTZ8TNroiWQcccbKItV//nCLBBQJgOEV+
AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJELKItV//nCLBKwoP/1WSnFdv
SAD0g7fD0WlF+oi7ISFT7oqJnchFLOwVHK4Jg0e4hGn1ekWsF3Ha5tFLh4V/7UUu
obYJpTfBAA2CckspYBqLtKGjFxcaqjjpO1I2W/jeNELVtSYuCOZICjdNGw2Hl9yH
KRZiBkqc9u8lQcHDZKq4LIpVJj6ZQV/nxttDX90ax2No1nLLQXFbr5wb465LAPpU
lXwunYDij7xJGye+VUASQh9datye6orZYuJvNo8Tr3mAQxxkfR46LzWgxFCPEAZJ
5P56Nc0IMHdJZj0Uc9+1jxERhOGppp5jlLgYGK7faGB/jTV6LaRQ4Ad+xiqokDWp
mUOZsmA+bMbtPfYjDZBz5mlyHcIRKIFpE1l3Y8F7PhJuzzMUKkJi90CYakCV4x/a
Zs4pzk5E96c2VQx01RIEJ7fzHF7lwFdtfTS4YsLtAbQFsKayqwkGcVv2B1AHeqdo
TMX+cgDvjd1ZganGlWA8Sv9RkNSMchn1hMuTwERTyFTr2dKPnQdA1F480+jUap41
ClXgn227WkCIMrNhQGNyJsnwyzi5wS8rBVRQ3BOTMyvGM07j3axUOYaejEpg7wKi
wTPZGLGH1sz5GljD/916v5+v2xLbOo5606j9dWf5/tAhbPuqrQgWv41wuKDi+dDD
EKkODF7DHes8No+QcHTDyETMn1RYm7t0RKR4zsFNBFp+A0oBEAC9ynZI9LU+uJkM
eEJeJyQ/8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd
8xD57ue0eB47bcJvVqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPp
I4gfUbVEIEQuqdqQyO4GAe+MkD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalq
l1/iSyv1WYeC1OAs+2BLOAT2NEggSiVOtxEfgewsQtCWi8H1SoirakIfo45Hz0tk
/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJriwoaRIS8N2C8/nEM53jb1sH
0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcNfRAIUrNlatj9Txwi
vQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6dCxN0GNA
ORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog
2LNtcyCjkTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZA
grrnNz0iZG2DVx46x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJ
ELKItV//nCLBwNIP/AiIHE8boIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwj
jVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGjgn0TPtsGzelyQHipaUzEyrsceUGWYoKX
YyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8frRHnJdBcjf112PzQSdKC6kqU0
Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2E0rW4tBtDAn2HkT9
uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHMOBvy3Ehz
fAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVss
Z/rYZ9+51yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aW
emLLszcYz/u3XnbOvUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPt
hZlDnTnOT+C+OTsh8+m5tos8HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj
6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E+MYSfkEjBz0E8CLOcAw7JIwAaeBTzsFN
BGbyLVgBEACqClxh50hmBepTSVlan6EBq3OAoxhrAhWZYEwN78k+ENhK68KhqC5R
IsHzlL7QHW1gmfVBQZ63GnWiraM6wOJqFTL4ZWvRslga9u28FJ5XyK860mZLgYhK
9BzoUk4s+dat9jVUbq6LpQ1Ot5I9vrdzo2p1jtQ8h9WCIiFxSYy8s8pZ3hHh5T64
GIj1m/kY7lG3VIdUgoNiREGf/iOMjUFjwwE9ZoJ26j9p7p1U+TkKeF6wgswEB1T3
J8KCAtvmRtqJDq558IU5jhg5fgN+xHB8cgvUWulgK9FIF9oFxcuxtaf/juhHWKMO
RtL0bHfNdXoBdpUDZE+mLBUAxF6KSsRrvx6AQyJs7VjgXJDtQVWvH0PUmTrEswgb
49nNU+dLLZQAZagxqnZ9Dp5l6GqaGZCHERJcLmdY/EmMzSf5YazJ6c0vO8rdW27M
kn73qcWAplQn5mOXaqbfzWkAUPyUXppuRHfrjxTDz3GyJJVOeMmMrTxH4uCaGpOX
Z8tN6829J1roGw4oKDRUQsaBAeEDqizXMPRc+6U9vI5FXzbAsb+8lKW65G7JWHym
YPOGUt2hK4DdTA1PmVo0DxH00eWWeKxqvmGyX+Dhcg+5e191rPsMRGsDlH6KihI6
+3JIuc0y6ngdjcp6aalbuvPIGFrCRx3tnRtNc7He6cBWQoH9RPwluwARAQABwsOs
BBgBCgAgFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmbyLVgCGwICQAkQsoi1X/+c
IsHBdCAEGQEKAB0WIQSilC2pUlbVp66j3+yzNoc6synyUwUCZvItWAAKCRCzNoc6
synyU85gD/0T1QDtPhovkGwoqv4jUbEMMvpeYQf+oWgm/TjWPeLwdjl7AtY0G9Ml
ZoyGniYkoHi37Gnn/ShLT3B5vtyI58ap2+SSa8SnGftdAKRLiWFWCiAEklm9FRk8
N3hwxhmSFF1KR/AIDS4g+HIsZn7YEMubBSgLlZZ9zHl4O4vwuXlREBEW97iL/FSt
VownU2V39t7PtFvGZNk+DJH7eLO3jmNRYB0PL4JOyyda3NH/J92iwrFmjFWWmmWb
/Xz8l9DIs+Z59pRCVTTwbBEZhcUc7rVMCcIYL+q1WxBG2e6lMn15OQJ5WfiE6E0I
sGirAEDnXWx92JNGx5l+mMpdpsWhBZ5iGTtttZesibNkQfd48/eCgFi4cxJUC4PT
UQwfD9AMgzwSTGJrkI5XGy+XqxwOjL8UA0iIrtTpMh49zw46uV6kwFQCgkf32jZM
OLwLTNSzclbnA7GRd8tKwezQ/XqeK3dal2n+cOr+o+Eka7yGmGWNUqFbIe8cjj9T
JeF3mgOCmZOwMI+wIcQYRSf+e5VTMO6TNWH5BI3vqeHSt7HkYuPlHT0pGum88d4a
pWqhulH4rUhEMtirX1hYx8Q4HlUOQqLtxzmwOYWkhl1C+yPObAvUDNiHCLf9w28n
uihgEkzHt9J4VKYulyJM9fe3ENcyU6rpXD7iANQqcr87ogKXFxknZ97uEACvSucc
RbnnAgRqZ7GDzgoBerJ2zrmhLkeREZ08iz1zze1JgyW3HEwdr2UbyAuqvSADCSUU
GN0vtQHsPzWl8onRc7lOPqPDF8OO+UfN9NAfA4wl3QyChD1GXl9rwKQOkbvdlYFV
UFx9u86LNi4ssTmU8p9NtHIGpz1SYMVYNoYy9NU7EVqypGMguDCL7gJt6GUmA0sw
p+YCroXiwL2BJ7RwRqTpgQuFL1gShkA17D5jK4mDPEetq1d8kz9rQYvAR/sTKBsR
ImC3xSfn8zpWoNTTB6lnwyP5Ng1bu6esS7+SpYprFTe7ZqGZF6xhvBPf1Ldi9UAm
U2xPN1/eeWxEa2kusidmFKPmN8lcT4miiAvwGxEnY7Oww9CgZlUB+LP4dl5VPjEt
sFeAhrgxLdpVTjPRRwTd9VQF3/XYl83j5wySIQKIPXgT3sG3ngAhDhC8I8GpM36r
8WJJ3x2yVzyJUbBPO0GBhWE2xPNIfhxVoU4cGGhpFqz7dPKSTRDGq++MrFgKKGpI
ZwT3CPTSSKc7ySndEXWkOYArDIdtyxdE1p5/c3aoz4utzUU7NDHQ+vVIwlnZSMiZ
jek2IJP3SZ+COOIHCVxpUaZ4lnzWT4eDqABhMLpIzw6NmGfg+kLBJhouqz81WITr
EtJuZYM5blWncBOJCoWMnBEcTEo/viU3GgcVRw=3D=3D
=3Dx94R
-----END PGP PUBLIC KEY BLOCK-----

--------------Vcj05XZj5Uy2HAspGQMVG8ok--

--------------hxwS10Iz5cdlVgj6EKb6kEDa--

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

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

iQIzBAEBCAAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmhKGPkACgkQszaHOrMp
8lO+7A/9FgDcFJUlaCE9Pah/GDgkCdjheoh3tlRfsVM/rCMYKMVzw5jWLprc7Ct6
5/gpHuui+WO3RtNoBJm/3K+WekD2zcSh+tBQMzfPAwl+dQegIe4drwrUJbA1lJJX
s9Liw17XHu51WbSB5VFEJUSjTQMd73cuZIU/jW/cFYQY8iG02It//IxexOui+vp+
qoKdUGhOFUrNoHWdYdMjHU+EFuAWvGXdB3pbvRyu69asEv7TxF99/TwkERXyxa6V
xSBdp3TvUDr3wsWLI1C290sG8Ir0U8OZ9U/3j/nzlFkHqQ2UIPXvygcKxsojwxBR
bonTUhqQFvnmboSLVHcE4zYqrcG/HwBJtLwp84gstiqZ53MFj47Gnna7izD2dqVc
Cv7TEHpAVtUIg8EIpkDL7I2g/4HzWhJsqKjJtQ290/Kt8YKtvHkkGy9C3NS5qEwO
Zi7xP1OXm3IP2RiS8alQDFB4LZdBImjCFij4nFKY9WRxNNS7ReZwrhvUOEiuvuaP
GRpF+9BXQJZk0FDndUZjdSfqQSI2On7hsFJ6bPU+pWCKvaZV0iXJ9MOw6SBuK4Tv
gRq9SZGU9GgyFV3A6dy2o95EKSZ/rDlhi1gINJ0G5YoNWzIpQqu0NAD/MZW3Ja4B
15pUHu01Ksme9Masiqif17bdMsESbL9IM58lst8c29AmWDdyCKw=
=40Yu
-----END PGP SIGNATURE-----

--------------OimbzeVUm0WiME0J0ubnZ5tN--


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 04:09:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 04:09:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012317.1390776 (Exim 4.92)
	(envelope-from )
	id 1uPZFb-00008U-0m; Thu, 12 Jun 2025 04:09:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012317.1390776; Thu, 12 Jun 2025 04: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 1uPZFa-00008G-Rh; Thu, 12 Jun 2025 04:09:14 +0000
Received: by outflank-mailman (input) for mailman id 1012317;
 Thu, 12 Jun 2025 04: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 1uPZFZ-000086-CV
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 04:09:13 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20628.outbound.protection.outlook.com
 [2a01:111:f403:2417::628])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fd65c18e-4742-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 06:09:10 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 IA0PR12MB8974.namprd12.prod.outlook.com (2603:10b6:208:488::21) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.18; Thu, 12 Jun
 2025 04:09:04 +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.8835.018; Thu, 12 Jun 2025
 04:09: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: fd65c18e-4742-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Lsya7VyTF7qJKzQsjyuLtz1yNEZRNPdPtKsZX5gWebgLuMvjfU6DkEH0RlSgyvMTbwsZV4zUZy5KmGr3q79/A2dil1S7Ew6kAWfsjm+9fzaKpk9mw2o46UM1mYIkeipk600gYGqlkvHIqtUXOLDyZuuD4ZawKSfJFX+gtAD1ih2jPCss34IEUNT/wLueETUhT4VnhZY8oiazFMFFIqAPtzr30P/VfkNwDg62EGAhZHOZujo5jdQ/1bXqb5gcFFmYCiFdVdSJ6BU6xpoojxVFfVXHomkIDmAbtkHRgcgv4lAIE1PapPCQaIuaAIWU32rtNgMXh5h3U0oMhiuNUI9kCg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=1xD/LBP05JNzOUDMtF/vZBuY7B/raNdEAGzEK1q6nbI=;
 b=nM6bYL7/6jTXQexrFbLDb8IWamrAgkCGt34GiFetLok8b4VM6oH0pFryRfBAQ3+Rh2obaxTQKNPW63tnt9PDBvYsDeeGonqhCGhdmsd3JzOIwlz9Qlo6vvElvQHnuHN+NrDK3ZNGsnZQu0ZMVSbUYadXVmJp60VuM8sFooTMNKviUdox5dcHCIbc5fcsiF+jIrF09tN1LQNxnnZRQVJ9RCWDtgEPkcY+qyWBs+VnTgxCk+HgP4/VlhCa7MjRSvT70h+wmjP0EeN26eKibf9FKZqXOUcwS5kIzkgjonXZkn6qkh3gJQJdF5ZyV8u7ISj3vwKomqXztXtwrDyMmOH7AQ==
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=1xD/LBP05JNzOUDMtF/vZBuY7B/raNdEAGzEK1q6nbI=;
 b=MKcgIRMDnY29qiXkRmxNjgeCFFrQuZ3cmzSjNtZPPtEkYqHFB1XB3e0W7/gTmVC4oWJjoMmD3CAVey7pG3Jx0QKqy8W941oVhzxP+A4Xh//2hYPQG+HlnQ2qfssnFW4jMWukC/cnir3/UpyCjKaoYxpgPYIsRAvmFEEwpVuS/FY=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Andrew Cooper
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Anthony PERARD , "Orzel,
 Michal" , Julien Grall , Stefano
 Stabellini , "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v4 03/20] xen/x86: remove "depends on !PV_SHIM_EXCLUSIVE"
Thread-Topic: [PATCH v4 03/20] xen/x86: remove "depends on !PV_SHIM_EXCLUSIVE"
Thread-Index: AQHbz7Fj+78Jf3bO30Wr1Bk6dRI84bP8b/QAgAJ/5nA=
Date: Thu, 12 Jun 2025 04:09:04 +0000
Message-ID:
 
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
 <20250528091708.390767-4-Penny.Zheng@amd.com>
 <1a73c720-012a-4795-9f47-f9c23b643de1@suse.com>
In-Reply-To: <1a73c720-012a-4795-9f47-f9c23b643de1@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=True;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-06-12T04:08:57.0000000Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=3;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged
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_|IA0PR12MB8974:EE_
x-ms-office365-filtering-correlation-id: 1081a8a3-3bad-4c97-3149-08dda966ded4
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?bndXYVpSdTZOdmgwemJBT1Z4SzY3eFpPWDZTWmc0M2Z3a0c1cUVUeDlhMVdW?=
 =?utf-8?B?ajAvcWZaWTdqVEtOcndpN1NsRFJjUmlXeU1hZGcxV29RQWk1ZUd1bVFMSzNa?=
 =?utf-8?B?Q0lUZkF6ajM5QVJvU01IQnozcFErNG5Kck1Na0VyWnI2S3FQUHNCUHpqZjhP?=
 =?utf-8?B?aHVqNWx0T1RCTy9KWDY4UWpCTmJhSHRnTER4WktMcWFidFNhaXc4UlNYM3E4?=
 =?utf-8?B?RVBSWjJraWZrbFVqaWtOZHFSMFQ4SFRvNDdGSFV2dHFWWG5Dd2RmOVlHUjJY?=
 =?utf-8?B?b1dxcHZHei9EZURST3BRTmJ1U09sZlJlZURyTTF4YkpKYnBQbTJsZUI3ZUFB?=
 =?utf-8?B?MlQrZk5raVRwZzF6SFRFQkd1NDhacjVzVEF0bEljZWdDWGRsb0M4TmthZDIw?=
 =?utf-8?B?MmhDRCtIVlV2NFNQV1JsQ1dyNUI3QXI4WWwzQk5wMUVyREpLdlpqRk84cjhT?=
 =?utf-8?B?ODZIVEFLSTlPVmlPWkF1cU51VERPOXVPZ1kyYW5nU0VLSUZwV3h4NHZqbmlC?=
 =?utf-8?B?c1Rrb1JvRFFMQ2xIQUZXSHFUcU1VS3lpd2tmS05YYkVPS2J4MWxJMk5IZ1Rn?=
 =?utf-8?B?cDErSWg4Z0JDRGc5WDZVajc3eVUwQW9SM3pWSkJwTDlTN2FZbzNRazN5MlRM?=
 =?utf-8?B?elNGWHFocHJrMHV1dFpGSHNua0t6Rk1MYjF1eUM2Wkg2YUozcjc4V3RxRVhi?=
 =?utf-8?B?WkNJVjhnblo1dlAxUWJ3dkhjcmVBNlR5KzVzWXRGR3Fmb2Z6Z1M4aEhiZVV3?=
 =?utf-8?B?V3VaSlVaK1EvSW9RaUdITUNucFRaang3ZEc5aUswR1dlTzIrWTY5dzZ6M0hz?=
 =?utf-8?B?b1dXb2piTnRiMVdtTTJuTGJubytHTGczQm5GSTZQWFJEYy9EWFpTWkNtQ0ph?=
 =?utf-8?B?azRNbXpITzY0K29uejBPWXRSSEdGUkM0Y3h5ajllV09mT3AyQmN4T0R3eTZ2?=
 =?utf-8?B?Uy9ZN2U4cERLRk9xVWNpSUZ2MkVwYXFJSXRXeUtmNjFaOWxFa29qbUpONE9B?=
 =?utf-8?B?cjAvcEhweERaMENwRnZHOFRIMFhsSjNWZXBoNmJLOURHRFhibGhzSXhqZUpW?=
 =?utf-8?B?U2UyazNBeTRNckdPSWdENklFZXFrbmlJa2s3QUQzZUxTRlMzZnRyYWdpNko1?=
 =?utf-8?B?TnFEYkNrTzIveXIrb1liTXhPY09hSUZkaUJhSWlBSXYzNnZmOWR6MlNpQ2RI?=
 =?utf-8?B?UUNNaGhpVU1Xcm9WZGtSQ3FsT3pWczdibkdUWGMya3ZZZEZQc1k5TmtIZWQ2?=
 =?utf-8?B?ckNIdCt5Zjg0a0pna0VwME9lUFo0bGNBMkZJREJjaFpSSGorTUZ6MGpiYUxW?=
 =?utf-8?B?Z2hndFU0NGpXMlhsMzBud3U4L21YTzlvMzBNbllubDFtK1A3eit6UXRoeFBP?=
 =?utf-8?B?Q2V4by8zdUdaVzR3TmxNK1RMYytPM004QVF5TDRGY1A1OEdrcElZUmxPZmQw?=
 =?utf-8?B?VkR6dUh3V0RqU05HcW9Da1Fja0ZaT1BqMUVrb0RwcEJrb082K283NU5KR1Er?=
 =?utf-8?B?emlNQ2s0TDNvSkdQSnNKOFkwM2Y3ampzUno4dGllN0pZUERhZUFXK0RLWHA4?=
 =?utf-8?B?SXNjcWQ3QjJmbDFDR0V0biszQ1dCTUx6RUlXUFJ2SXJKa3ZLaGd0Tms2ZFBy?=
 =?utf-8?B?bUtpVStmSTJBRC9jVUxDUEVyWUcyVk40YkFaK0VkMlhQSnkrVmduaDNvajM0?=
 =?utf-8?B?VTVGdTdPak4rcG1Sc2EwcEhtcUxmcGxJOTRoUWVqaWIxeGVWc09hYlY0cGc3?=
 =?utf-8?B?NG8zMTVQYkJUVkxLTHhrdmpoTWR2MW5sN05NQTJUdVdyN0ozZGxEYVBiTGgy?=
 =?utf-8?B?NGdMVTR6YnZUdmUrbHc3MTZhRy9DYkdvSENxaEtPek1HalFXZG05V2s3ejdR?=
 =?utf-8?B?QXhYUndXNzdSbXI5bEhSWmJTNlFFRUpJMERFUURKcCtDbW5WbG1WUjJrREFs?=
 =?utf-8?B?Vkl5eWxwazhtU20rTVV5Z2loaDE0WHIyWVBhS200cHlQaUJaL0tmMGk5Vm53?=
 =?utf-8?Q?2m65iK02SHlN2V0WNlpNRzCv95mN6Y=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?RTkwWFRyRm5DMW9PMUFWaGdTbFJzWklHdkh4cm9Fd3FhQnZHMC9Bb2J5VHFI?=
 =?utf-8?B?RDNFcG50bXlXalpveDJlNTU0ZllXR0lsY3N0dGUyQThTdDdUQXFpWmgwVk1M?=
 =?utf-8?B?K2NqcXd2OG10Sm9lblUzVGd5TGE4Vi9Uamlac0xLT1poMDhOZUM1SE9wVFkw?=
 =?utf-8?B?eXBydkd6VFVVRENwNW1EcWl4amdPVnJ2OGRyYVBzWHFLWnFsNnlBS1dXZzJp?=
 =?utf-8?B?UnJiemtzWUtNMU5GNkJFUFk3d2xuU3g2azFMdlF4ZUxuUVorQjBxbFlmTGw0?=
 =?utf-8?B?T0wzTGQzQ2tNSVVSbU5TNFF5U2loOWgxTEpaaXkrL2RrMk00YUliWWVPbXdH?=
 =?utf-8?B?SGtadXZ6K2ZPYkJET2lxM1NaZVJlVkJpZVJtYVUySXNoWHB4dFA4bitjNmFl?=
 =?utf-8?B?L3VyUjE0a0E3WW1ZY0liQmpPU3JEbkN1aG9XcGJGU0l4TG1pOUNQNUh1aEtr?=
 =?utf-8?B?OFA4SGRZbytBa0NiNk5WQ3BnV2tRci8rODlhUnluNUNKMW0rT1ZaYUV6eU5F?=
 =?utf-8?B?YnVsYlp5akFhVlMrZktpbUdScUdiV1R3SFI4aHNwNUhlMXFoY1YvQlZCbHBv?=
 =?utf-8?B?WlFuWUE4bjgwOElsM2FjMXUyOVFFSWpOVzRvTzQxY1JSanVOeDRyR1BvaDNz?=
 =?utf-8?B?aUlSQmtmUHF6MTFOK1ZGU3B6RWp4bjRvSWN5TER1VWwycTlYSW12MHhtRzhN?=
 =?utf-8?B?NnIwblZzZlUydE5hNHYxMFlVVGw1VWVvVERBSFFreExhTFBIMDZUNnpLMkhV?=
 =?utf-8?B?U2VQQVZxTkozNEU3T1F6TWxFT2grNnpLWm5Qa0tCNENneVVjY0pzUXBiN0NT?=
 =?utf-8?B?eTdWMmZSMzZGRVBRYnp3dlluMzNkVlBwMXBQdzJjcjVaYm9lallLTUhkRThE?=
 =?utf-8?B?OGw3VnQ3ZGlPNGNOem9PVGE5a2dvOEdSQmJweVRhMHFQVjBmM3d1Y05FTVdX?=
 =?utf-8?B?eTB3ZnprN0xYclJBV0greVVhVitUWDRjSWdaYng1c0JucGZyM3VEeUI3N24z?=
 =?utf-8?B?bGFTM3FiTS9kYjE2UUdQT1liMTdLSWlWdGtIZUNWdVIvMXVPUkdkS0RCTHlM?=
 =?utf-8?B?QkNlQkw0MjJLK09ieElTclZ6eENMaFkxNjVpTHJEYWNxVW9FTitXaUJDeDQ3?=
 =?utf-8?B?N2VUd3BWWG5GUk8yeThna3p6YWM3ZW5oQnpXTTcwVkVMVUZJL2srbEYvZzhJ?=
 =?utf-8?B?VUVJb0w3aWNvRFVva2dRSGZDYXo1Z3l3ZmtsVU1pUWhKYXFwSkJKY29yRTRR?=
 =?utf-8?B?WlcrbDRVQTh6LzZiUUtzVGZQQVhLZmxWTFl3ZUxaNVNPb0FDNS8zQVhqdmZr?=
 =?utf-8?B?TmFWUTQ2NlBUU0tQMmR5NDRETDNKbnNQYnZyZENUOVUxM2pXSnY3QVNxT2ky?=
 =?utf-8?B?cko4SzRjamVLeFFWTXU4WE85WmdDRzVSZFJTeERob1BHUUErd0F1ZGZNNVZj?=
 =?utf-8?B?NW9PZWllVmhsZ0RKWWRPc1VUaXp2ZVc4U1lWcEppbWtRdlRYZWdvUDEwemQ1?=
 =?utf-8?B?eWYzbkhreTZHZjhNaDMvb3dUTnVmZWgvVzVKL0wvL0tORUUxN0VMMDJZWGNk?=
 =?utf-8?B?WnNGZkhPMnYrRXJtenNCbVJWamZJZ1JFdFRvQ0pJWHpCWXNsRy9remZZVUFM?=
 =?utf-8?B?NDRRRmNSWTZGWksvYzhHbWxRaVIrSXhpc2NqR3orUllCQ1VDUmYwQnE5SUxv?=
 =?utf-8?B?SzExdHdydTV4UUhmbWtPOGdQdU4wZlNrUmFucEd4QVhzVzQwRWgxL0lzVURr?=
 =?utf-8?B?aDZLSldzcWJvNVdpcVpvdFFRaEVIYjB1MHZqQnNvUkdmOHFkVHdnNGphU1Av?=
 =?utf-8?B?MHFWaTJYY2JPdWtPRFpEcWRmSDJzQ0JQUWpKTkxXaTJJVkwvRm9UaURCNVNK?=
 =?utf-8?B?aW02dmRINkJVL0s0d25yRXo4ampDOE5MbTJVRi8yQ1B5RG10UFM1TGl6NVR6?=
 =?utf-8?B?MThBUE52cE1JaGFKOG5tTDJ3VlVLVUxrY2NXSWliTitpZjhjaERESUswWE9j?=
 =?utf-8?B?YUJLNXNlM3BseXplSjRKZGRxRVJoblBsTHpMcUtqSzJrM0JLcit1Wm1Gb1I2?=
 =?utf-8?B?cEhjSzJkMWltdFdUcGI2YjVjWDZzUVlvRnVhUnovTWo4Q3o0L3pJeHVXMkx1?=
 =?utf-8?Q?Zri8=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: 1081a8a3-3bad-4c97-3149-08dda966ded4
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2025 04:09:04.6641
 (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: W3GBII1SllnTWEmECqSXAZEaq2e0sgEXS0w9ZladykZMdMduEx5LFcbQixwvb+JdM+3uSnYNS1b8OQRCQPhaUA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB8974

W1B1YmxpY10NCg0KSGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog
SmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KPiBTZW50OiBUdWVzZGF5LCBKdW5lIDEw
LCAyMDI1IDk6MDEgUE0NCj4gVG86IFBlbm55LCBaaGVuZyA8cGVubnkuemhlbmdAYW1kLmNvbT4N
Cj4gQ2M6IEh1YW5nLCBSYXkgPFJheS5IdWFuZ0BhbWQuY29tPjsgQW5kcmV3IENvb3Blcg0KPiA8
YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT47IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBj
aXRyaXguY29tPjsNCj4gQW50aG9ueSBQRVJBUkQgPGFudGhvbnkucGVyYXJkQHZhdGVzLnRlY2g+
OyBPcnplbCwgTWljaGFsDQo+IDxNaWNoYWwuT3J6ZWxAYW1kLmNvbT47IEp1bGllbiBHcmFsbCA8
anVsaWVuQHhlbi5vcmc+OyBTdGVmYW5vIFN0YWJlbGxpbmkNCj4gPHNzdGFiZWxsaW5pQGtlcm5l
bC5vcmc+OyB4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcNCj4gU3ViamVjdDogUmU6IFtQ
QVRDSCB2NCAwMy8yMF0geGVuL3g4NjogcmVtb3ZlICJkZXBlbmRzDQo+IG9uICFQVl9TSElNX0VY
Q0xVU0lWRSINCj4NCj4gT24gMjguMDUuMjAyNSAxMToxNiwgUGVubnkgWmhlbmcgd3JvdGU6DQo+
ID4gUmVtb3ZlIGFsbCAiZGVwZW5kcyBvbiAhUFZfU0hJTV9FWENMVVNJVkUiIChhbHNvIHRoZSBm
dW5jdGlvbmFsbHkNCj4gPiBlcXVpdmFsZW50ICJpZiAhLi4uIikgaW4gS2NvbmZpZyBmaWxlLCBz
aW5jZSBuZWdhdGl2ZSBkZXBlbmRhbmN5IHdpbGwNCj4gPiBiYWRseSBhZmZlY3QgYWxseWVzY29u
ZmlnLiBUbyBtYWtlIHN1cmUgdW5jaGFuZ2luZyBwcm9kdWNlZCBjb25maWcNCj4gPiBmaWxlIGJh
c2VkIG9uICJwdnNoaW1fZGVmY29uZmlnIiwgd2Ugc2hhbGwgZXhwbGljaXRseSBzdGF0ZSBhY2Nv
cmRpbmcNCj4gPiBLY29uZmlnIGlzIG5vdCBzZXQNCj4gPg0KPiA+IEFkZCAiZGVmYXVsdCB5IiBm
b3IgU0hBRE9XX1BBR0lORyBhbmQgVEJPT1QsIG90aGVyd2lzZSB3ZSB3aWxsIGhhdmUNCj4gPiB1
bnNldCB2YWx1ZXMgd2hlbiBydW5uaW5nIG1ha2UgZGVmY29uZmlnIGJhc2VkIG9uICJ4ODZfNjRf
ZGVmY29uZmlnIi4NCj4NCj4gSSBmZWFyIEkgZG9uJ3QgdW5kZXJzdGFuZCB0aGlzLCBwZXJoYXBz
IHJlbGF0ZWQgdG8gbWUgYWxzbyBub3Qgc2VlaW5nIGhvdyAuLi4NCj4NCg0KSWYgd2UganVzdCBy
ZW1vdmVkICJkZWZhdWx0ICFQVl9TSElNX0VYQ0xVU0lWRSIsIC5jb25maWcgZmlsZSBnZW5lcmF0
ZWQgYnkgIm1ha2UgZGVmY29uZmlnIg0Kd2lsbCBjaGFuZ2UsIGhhdmluZyB1bnNldHRpbmcgdmFs
dWVzIGZvciBTSEFET1dfUEFHSU5HICgjIENPTkZJR19TSEFET1dfUEFHSU5HIGlzIG5vdCBzZXQp
DQpJZiBjaGFuZ2luZyBpdCB0byAiZGVmYXVsdCB5IiBpcyB0b28gY2FzdWFsLCBtYXliZSB3ZSBz
aGFsbCBhZGQgIkNPTkZJR18gU0hBRE9XX1BBR0lORz15IiBpbiB4ODZfNjRfZGVmY29uZmlnLA0K
dG8gYXQgbGVhc3QgcmV0YWluIGNvbnNpc3RlbnQgLmNvbmZpZyBmaWxlLg0KTXkgZmF1bHQsIE9u
bHkgY29uc2lkZXJpbmcgIlNIQURPV19QQUdJTkciIGlzIGVub3VnaCwgYXMgVEJPT1QgZGVwZW5k
cyBvbiBVTlNVUFBPUlRFRCBmaXJzdGx5DQoNCj4gPiAtLS0gYS94ZW4vYXJjaC94ODYvS2NvbmZp
Zw0KPiA+ICsrKyBiL3hlbi9hcmNoL3g4Ni9LY29uZmlnDQo+ID4gQEAgLTE0Myw3ICsxNDMsNyBA
QCBjb25maWcgWEVOX0lCVA0KPiA+DQo+ID4gIGNvbmZpZyBTSEFET1dfUEFHSU5HDQo+ID4gICAg
IGJvb2wgIlNoYWRvdyBQYWdpbmciDQo+ID4gLSAgIGRlZmF1bHQgIVBWX1NISU1fRVhDTFVTSVZF
DQo+ID4gKyAgIGRlZmF1bHQgeQ0KPiA+ICAgICBkZXBlbmRzIG9uIFBWIHx8IEhWTQ0KPiA+ICAg
ICBoZWxwDQo+ID4NCj4gPiBAQCAtMTc1LDcgKzE3NSw3IEBAIGNvbmZpZyBCSUdNRU0NCj4gPiAg
Y29uZmlnIFRCT09UDQo+ID4gICAgIGJvb2wgIlhlbiB0Ym9vdCBzdXBwb3J0IChVTlNVUFBPUlRF
RCkiDQo+ID4gICAgIGRlcGVuZHMgb24gSU5URUwgJiYgVU5TVVBQT1JURUQNCj4gPiAtICAgZGVm
YXVsdCAhUFZfU0hJTV9FWENMVVNJVkUNCj4gPiArICAgZGVmYXVsdCB5DQo+ID4gICAgIHNlbGVj
dCBDUllQVE8NCj4gPiAgICAgaGVscA0KPiA+ICAgICAgIEFsbG93cyBzdXBwb3J0IGZvciBUcnVz
dGVkIEJvb3QgdXNpbmcgdGhlIEludGVsKFIpIFRydXN0ZWQNCj4gPiBFeGVjdXRpb24NCj4NCj4g
Li4uIHRoZXNlIHR3byBmaXQgd2l0aCB0aXRsZSBhbmQgZGVzY3JpcHRpb24uIFRoZSBqdXN0aWZp
Y2F0aW9uIGZvciByZW1vdmluZw0KPiB0aGUgIVBWX1NISU1fRVhDTFVTSVZFIGhlcmUgaXMgbm90
ICJicmVha3MgYWxseWVzY29uZmlnIi4NCj4NCg0KSG1tbSwgaXQgaXMgdGhlIGNvbnNlcXVlbmNl
IG9mICJyZW1vdmluZyB0aGUgIVBWX1NISU1fRVhDTFVTSVZFIg0KTWF5YmUgSSBzaGFsbCBhZGQg
bW9yZSBleHBsYW5hdGlvbiBpbiBjb21taXQgbWVzc2FnZT8NCg0KDQo+ID4gQEAgLTI4OCw3ICsy
ODgsNiBAQCBjb25maWcgUFZfU0hJTV9FWENMVVNJVkUNCj4gPg0KPiA+ICAgICAgIElmIHVuc3Vy
ZSwgc2F5IE4uDQo+ID4NCj4gPiAtaWYgIVBWX1NISU1fRVhDTFVTSVZFDQo+ID4NCj4gPiAgY29u
ZmlnIEhZUEVSVl9HVUVTVA0KPiA+ICAgICBib29sICJIeXBlci1WIEd1ZXN0Ig0KPiA+IEBAIC0y
OTgsNyArMjk3LDYgQEAgY29uZmlnIEhZUEVSVl9HVUVTVA0KPiA+DQo+ID4gICAgICAgSWYgdW5z
dXJlLCBzYXkgTi4NCj4gPg0KPiA+IC1lbmRpZg0KPiA+DQo+ID4gIGNvbmZpZyBSRVFVSVJFX05Y
DQo+ID4gICAgIGJvb2wgIlJlcXVpcmUgTlggKE5vIGVYZWN1dGUpIHN1cHBvcnQiDQo+DQo+IFBs
ZWFzZSBkb24ndCBsZWF2ZSBkb3VibGUgYmxhbmsgbGluZXMuDQo+DQo+ID4gLS0tIGEveGVuL2Fy
Y2gveDg2L2NvbmZpZ3MvcHZzaGltX2RlZmNvbmZpZw0KPiA+ICsrKyBiL3hlbi9hcmNoL3g4Ni9j
b25maWdzL3B2c2hpbV9kZWZjb25maWcNCj4gPiBAQCAtMjYsMyArMjYsOCBAQCBDT05GSUdfRVhQ
RVJUPXkNCj4gPiAgIyBDT05GSUdfSU5URUxfSU9NTVUgaXMgbm90IHNldA0KPiA+ICAjIENPTkZJ
R19ERUJVRyBpcyBub3Qgc2V0DQo+ID4gICMgQ09ORklHX0dEQlNYIGlzIG5vdCBzZXQNCj4gPiAr
IyBDT05GSUdfU0hBRE9XX1BBR0lORyBpcyBub3Qgc2V0DQo+ID4gKyMgQ09ORklHX1RCT09UIGlz
IG5vdCBzZXQNCj4gPiArIyBIWVBFUlZfSFlQRVJWX0dVRVNUIGlzIG5vdCBzZXQNCj4NCj4gVGhp
cyBvbmUgZG9lc24ndCBsb29rIHJpZ2h0LCBzaW1wbHkgYnkgaXRzIG5hbWUuDQo+DQo+ID4gKyMg
Q09ORklHX0hWTSBpcyBub3Qgc2V0DQo+ID4gKyMgQ09ORklHX1ZHQSBpcyBub3Qgc2V0DQo+DQo+
IEp1c3QgdG8gbWVudGlvbiBpdCAtIEknbSB1bnN1cmUgd2hldGhlciBhZGRpbmcgc3VjaCBhdCB0
aGUgZW5kIGlzbid0IGdvaW5nIHRvIGNhdXNlDQo+IGlzc3Vlcy4gQnV0IG1heWJlIEknbSBwYXJh
bm9pZCAuLi4NCj4NCg0KSXQgY291bGQgYmUgdG9vIGNhc3VhbC4uDQpJIHdpbGwgb25seSBsZWF2
ZSBWR0EgaGVyZSwgYXMgd2UncmUgc3VyZSB0aGF0IHdpdGggcmVtb3ZpbmcgIiFQVl9TSElNX0VY
Q0xVU0lWRSIsDQpDT05GSUdfVkdBIGlzIHNldHRpbmcgYXMgeSBpbiBwdnNoaW1fZGVmY29uZmln
DQoNCj4gPiAtLS0gYS94ZW4vZHJpdmVycy92aWRlby9LY29uZmlnDQo+ID4gKysrIGIveGVuL2Ry
aXZlcnMvdmlkZW8vS2NvbmZpZw0KPiA+IEBAIC0zLDEwICszLDEwIEBAIGNvbmZpZyBWSURFTw0K
PiA+ICAgICBib29sDQo+ID4NCj4gPiAgY29uZmlnIFZHQQ0KPiA+IC0gICBib29sICJWR0Egc3Vw
cG9ydCIgaWYgIVBWX1NISU1fRVhDTFVTSVZFDQo+ID4gKyAgIGJvb2wgIlZHQSBzdXBwb3J0Ig0K
PiA+ICAgICBzZWxlY3QgVklERU8NCj4gPiAgICAgZGVwZW5kcyBvbiBYODYNCj4gPiAtICAgZGVm
YXVsdCB5IGlmICFQVl9TSElNX0VYQ0xVU0lWRQ0KPiA+ICsgICBkZWZhdWx0IHkNCj4gPiAgICAg
aGVscA0KPiA+ICAgICAgIEVuYWJsZSBWR0Egb3V0cHV0IGZvciB0aGUgWGVuIGh5cGVydmlzb3Iu
DQo+DQo+IExpa2UgYWJvdmUsIHRoaXMgY2hhbmdlIGFsc28gZG9lc24ndCByZWFsbHkgZml0IHdp
dGggdGl0bGUgYW5kIGRlc2NyaXB0aW9uLg0KDQpJIGhhdmUgYWRkZWQgIiAoYWxzbyB0aGUgZnVu
Y3Rpb25hbGx5IGVxdWl2YWxlbnQgImlmICEuLi4iKSAiIGluIGNvbW1pdCBtZXNzYWdlIHRvIGFs
c28NCmNvdmVyIGFib3ZlIGNoYW5nZQ0KDQo+DQo+IEphbg0K


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 04:35:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 04:35:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012329.1390786 (Exim 4.92)
	(envelope-from )
	id 1uPZfB-0003ye-2r; Thu, 12 Jun 2025 04:35:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012329.1390786; Thu, 12 Jun 2025 04:35: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 1uPZfA-0003yX-Vz; Thu, 12 Jun 2025 04:35:40 +0000
Received: by outflank-mailman (input) for mailman id 1012329;
 Thu, 12 Jun 2025 04:35: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 1uPZf9-0003yR-AI
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 04:35:39 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on2061a.outbound.protection.outlook.com
 [2a01:111:f403:2414::61a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ae5d541d-4746-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 06:35:34 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) 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.8835.19; Thu, 12 Jun 2025 04:35:24 +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.8835.018; Thu, 12 Jun 2025
 04:35: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: ae5d541d-4746-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=C8D/1o7eBGXlb25LSg2f1wHeDd7J/b/+Iyfzu9jyuIrEkYpSYCnLqpypWyK5qe1iQnzkuRYnC+mGIkHcDLNkaiaFrPD3ugEvdwaCLO2WjRzTIo/ZubdB3pWlnh+x6ZQbgB7F/FAnYB5drN1NwvHUPC+HWZWMflxRYaAlerb+BzLPSQsuTqdb0YGI3flRBmf8bCGEWsBiN3Sli8j7taCLcjXnsxwzbIgCYFUO7rbV8cl50eDTTybcMPWtBg55L5AUd4dfB0vYqU1ff5HDxlxExs24epPCsYfeaDl2R6LBFOfgwp7tOZ7/UNs+QcNy/7x4XRvXtDb6hCMX7NWEZTposg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=fxbX+SoLoQCjzgydUxWRdLWIxdR320fOfMNtNbN7zms=;
 b=QRkQahJSC60RnYnsxS8VKXDGur6bjjwdecnH/R7f1ISuXMNR/xUYmWkry97DPFM0Fpm77rxLyv9OVUE5koG9y8PZaEQV57OROZWIl9MFtKAJ4ByCYHKVlOn4t9vjxxNy+xsQKmw6J7tQ+VZRh/XG6noNZrnr6tPkEwTxTvqMpZj5+0R5yvVH73OWX9qW0rt9mO6JHH24iJos3dwCM9O5n50dvaFcJyO2X3yslXWNmwDzDKAS/SjpR6pEfc68J0R1bcQ0gU/RL4JvOY397GL7abTzpXpO7I2sOj5mJFXW82aOeVVA6hqVjqCFEhXrgd+m8znIvXA43//lzAhF3xNrHw==
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=fxbX+SoLoQCjzgydUxWRdLWIxdR320fOfMNtNbN7zms=;
 b=LqvOt/f3hxeuQFkgeH7qteoo8Ik6COhT2o8zk9eQLeyBTmQ/bsMB0N3ty3s3nVFAXK2yn14LPpZMlqA4eAmUGLm2kfd8b3LR5SAqltHjqJKA3KHv3d6//p7gmk90DQNS5T5q3cyeRQYRjpCka2c/baTgHi0j+lkuJ/eAKYK+YI4=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , "Stabellini, Stefano"
	, Andrew Cooper ,
	Anthony PERARD , "Orzel, Michal"
	, Julien Grall ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano
 Stabellini , Sergiy Kibrik ,
	"xen-devel@lists.xenproject.org" 
Subject: RE: [PATCH v4 04/20] xen: introduce CONFIG_SYSCTL
Thread-Topic: [PATCH v4 04/20] xen: introduce CONFIG_SYSCTL
Thread-Index: AQHbz7FloXiAMULpdEeddWt/MAojzbP8cUqAgAKQbAA=
Date: Thu, 12 Jun 2025 04:35:24 +0000
Message-ID:
 
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
 <20250528091708.390767-5-Penny.Zheng@amd.com>
 <51fde0e2-abca-43c8-9cfa-734219431970@suse.com>
In-Reply-To: <51fde0e2-abca-43c8-9cfa-734219431970@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=True;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-06-12T04:35:17.0000000Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=3;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged
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_|CY5PR12MB6345:EE_
x-ms-office365-filtering-correlation-id: a120e2fe-778b-4803-f210-08dda96a8ca3
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?WFRhcTdZYjJIbUFTZE45eWRxMGljTWZlb0FmdzhBOG5VOU4vb2s0c1hNQVJQ?=
 =?utf-8?B?YTVGVVlTcmFDRzFvWWg2TSs2dTZPS3NnVzJkWE45M3dBT2d5Kys2S1g5V3M4?=
 =?utf-8?B?dVRIU1pPc2w4ZWRMQTBQcFBJVGpyK1lRdFhrQlV1bmFucENrQkFkZ3Axd0lu?=
 =?utf-8?B?anZ2OE5qM3dMdkMvZDRlb0F6N0lBZ1VqeXZ1Z1Q3aUJxSzVaR25Veml5ekdG?=
 =?utf-8?B?TmI5UXl4LytPVWs3Q3gwcE5QYmxJZjB3d3lFVEIrUEFWTjY3RHR0emRUMmZw?=
 =?utf-8?B?cUthOE9JWG10cTUvZXB2czAvVTRqRGpQeVBFL2d6ZXJvOUdvQXdWYWRpN3lJ?=
 =?utf-8?B?UFprU3ZLdFoxYmxVY0JPSzM2YTlnTkk0NzBlQTNPNUh0M2ZqUUtJaGZFVVQy?=
 =?utf-8?B?eUZET0NjckhJWStPSWtxN0NhL2RxRjhpRSt1bnMwd3VaYU80S2JjWEpGNWxJ?=
 =?utf-8?B?R3ZZV3hxNmcyeTBWZkFxVHRYUngxTnU0a2dIOENXUTQxa2lQV3hLdzArZ2g2?=
 =?utf-8?B?M3h6ZVZpWENzTk5HZkJaZUIyY1ZYODkrWWxCaXF1aHpwUjlmNmpoVVF1dm1I?=
 =?utf-8?B?Ukhqa3lneW1pRUVqU3dDaTJOM1hXREF1UFU2K2VGUVUxNnpDY3pOZnpRbWln?=
 =?utf-8?B?SmdtTWZ3aGZ0bG1ubGpaT0hIcitxamppY3V2eDdNNWRnTnNYMFJCNXhyWmJG?=
 =?utf-8?B?NGJUR21pWkdDQzRXOUczWTY1SUNza2FKaE9jaHp3WE1Db3VOc3l1SGZCcktY?=
 =?utf-8?B?QTZ4NjNDYS8wSGxuQ2psMG5pbGsxTVh3Wm5HK0ZrTGYyeU9udFJabVNiQTRj?=
 =?utf-8?B?RGhMdm56TjVrYmVDWTlkd1U3dkowcVNsWXoyTjlqaDR2Z2xWU2MySEVMLzhI?=
 =?utf-8?B?bmYrVnlBM2swWHhkODRqbW0vSURFZTlrd3dydlVsK1E5ZmxCay9wVDJFTHhz?=
 =?utf-8?B?ZHVSbVZGTHJkYmdWMitiL2lxVkMxT3pFVEdKTUVacEZhUkFkTG9oZHhjbDlK?=
 =?utf-8?B?V05ldXlBZlEyb3VUdThEazdhd2VMZHFydUg5WHVQZGtyRXlpTFBRcVcwUkxh?=
 =?utf-8?B?d0VtZWNPTmZZWU5YbE1Zd0VsOU9BaFAwRGZlWUxOZnhueVcvc2VKTlE5YWhj?=
 =?utf-8?B?RElwMnExc1dNNUg2R3YxZkJQcEtqQmQ0OVRIOXNONEhQVEFDZXhaclJPMTZE?=
 =?utf-8?B?Q21ESzVhT3JKZVo4RWxJVUErUDhhNFVkSnhDaktuT0pnY2R0T3Y4eDdZQjk3?=
 =?utf-8?B?VWFNZzZGYmlzSzQ0QmRjdUFlWWkyQ1E3QW14VkE0Y2dudWRRSCtCZmNKdGF5?=
 =?utf-8?B?cW5yck9pbW93QzRYMFBWTWpsaEhjTU94RkwyTFpYa0lTZWt5cHlFV2lIMXAv?=
 =?utf-8?B?S1BsYi9qNzgwYmZWNzluTjNVbGk1TDhIcG5mL3RXdHN2VUEvSktnWWxkekxs?=
 =?utf-8?B?L21ncEt6SW9NMjJhSngzUU9vZzFQcmdZRngzbThvR2s4ZDh2dlNNdTUxVi8w?=
 =?utf-8?B?ekIvT0RTZXhTTmEzRlZIaW1SaGlSSHFDTm91Mk9ydzZUZmZ4TUw3OGJWSVVF?=
 =?utf-8?B?ZFB4Y250OTF1aHh3UXFyaHhOU2hhUThVSUZXREJNK0U1N2NtaHBiQUY1VGM5?=
 =?utf-8?B?Vkl3RWlEcHJocENpS1FUcTZ1YlRHY00rSitSVjRWekV3N2JQcFVDcjJLMmtx?=
 =?utf-8?B?azMxUFVsTXhYVk5CTG8ySmNVcC9oMWJENVZzbElFRmU5R0luc0VVclpjZjl1?=
 =?utf-8?B?WXJPbGgrL1BrYXlwVkpGc3ZibTZQTWtnSE5WVUw0WVVTK0w5MW40ZStvbTNy?=
 =?utf-8?B?ZC9hM1FJUkpVQWlMV2x4SVNzWUM0MWxxN2E3M2NFUURGUkJVZ3ZnVklialFR?=
 =?utf-8?B?cUZtMjBRc3lqWGFSRlFrWlBzMk51cnJwaW8vWCtPazEyazYrWXhxSk5QTnFE?=
 =?utf-8?B?d3hvWWdlNU9qS0txTlBhdUt3YUVZQ1NHbkxiRmN2TGg2bm1vVzVtMWhxN1hN?=
 =?utf-8?Q?FzQSenzPIEcY8sweFroTcjlpfydhio=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)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?R0kvaGxUeFUxL2ZsZUgxNnMwMXJUK0FhcUhxSFhNS1p1dENTeEhheWdpNHda?=
 =?utf-8?B?M2Z4dyt3Njc1aEhnbnZVOCswMTJpOFVWdHlOMWczYkdRQXF4eDZlS3hmTW9u?=
 =?utf-8?B?Y0pvdFZwck5FTlo1dHlwOFkwOGVDdmx0VlNsSS9uSHM3cFdSTHNyYmp1b2Q3?=
 =?utf-8?B?SmlrNTc1QVZRMUJzb0tCQ3ZQVzIxZGpZQXdaeFF6QlM3WmsyL2tnQkRnOXpa?=
 =?utf-8?B?a0VKU0x5VkorcjlOU1dVYzc4ZkFBdVdjV3o4SWdJbUFPK0g2cmlvMTN5MEhq?=
 =?utf-8?B?RlZnWDFEREx4eUQzeEdrVHUxaWpDNWZiUlpDRFBwam9oU2Vmai9XLyt0aGhO?=
 =?utf-8?B?d2pzQXVVSGRzNm9MWWVwcnBCaStuZWpzcDByeE4wczE3ZDZ1blhwMDY1bk1a?=
 =?utf-8?B?S05Rc0dhSXFVWndtQ0hHK0d6UmFOa0ZDL2dtNXBTWGRyWTNjOGRHd0tCbFJS?=
 =?utf-8?B?OFpMTmJoVzdWUmkydk1mbTQxeEpITnpJSmdhMThsT0NCS0NGUFE0M1dUTG9O?=
 =?utf-8?B?SjBRa2lGNGNVbnhQSUdvQmZXa1B0VUZva1VXTnVGNW9iRENWb1JzNmYyZ3ZI?=
 =?utf-8?B?OWxxd1g5QXYwYTdzOEFjS2xYWkM2TTRsUmVteDdkTUduT055MTNxcFQvcnpJ?=
 =?utf-8?B?aXN3WDNEQjN4L2tBSWptRG4wTzJyTWdpMGhCOXdHZ2hCZlVZRHljS1EzNVZu?=
 =?utf-8?B?eU5ZejJnTVNGdGFwdTBHeVhYZE9IZDV1VXNOYUN6OGJ3MExoV2hkU1RHMDg5?=
 =?utf-8?B?Q2JZV1F5bTZYemxsaitlZnMzb3dVNi83enpMS3ZieGlXTHJjdHNWbk9EdG5M?=
 =?utf-8?B?eXkxQ291WE5jZVFyT3FLQWU4eGIxQTFwZ3VjN2JrbXJybUhHajNGYVdXTVpO?=
 =?utf-8?B?VFNhdkQrK0RNVDRvS1Y4OXJ6OHo2M2x6WVl2MWxDK0tGSnN5ODE0VzBJZG1i?=
 =?utf-8?B?dmZGQjN4TWMvaGpkbjVmeE5mTVdldE1lVHkybXZxZGVpMXprUHA3SVZQZ2FQ?=
 =?utf-8?B?TzJDMWl1S1dPR3NCb1FWMWlwTXZBdStXNnJ1RUNjTmRBbExKNjhQUWh1eDNL?=
 =?utf-8?B?citiOGRwaHB2cHhvVHJNVzZoSTFYYjlXb21Mdk4wMHN5cyt3c21VMHdYOFJl?=
 =?utf-8?B?ZmFYUUZkODhvMmViaUtJcHBPWjRNc1VXbzY5Sk9tYlhGZWE5bjNxMmNKRTM4?=
 =?utf-8?B?ZkJXRzJZZzhTSFlQczhwamhDS1hUZzFIblBFdVQwU0V0V0dpMGkwMDZ1cXNp?=
 =?utf-8?B?SVlURlU4K0huNU9xbVhQU2dqT1JLTnNOUGJkMkpWengvaUpVdVpBejV2YVNk?=
 =?utf-8?B?MkJpUThWYXhXZkRhQTJkT0JHNE5rN2ZidWxWS1NJU1YxOFJLMUlBc3B3bFRG?=
 =?utf-8?B?YzZna0JiSXFIalNEbjdOMm43OW9iQmk0S0ttY0o1ZFk1cnZJaWtQNFVVQjJk?=
 =?utf-8?B?U0NIQ3E2Vys5UWVwdUtUZTVwVjdoSUp0NHViK2YxNTNxSW9qSkF1V3dlRHRH?=
 =?utf-8?B?T3REL0R1MGdZdDdVU29OcnJ3TXE2SnAxQk5QeDVFcWRYa1lLd0JoNUlQNHVx?=
 =?utf-8?B?VVAwNEVXd2JpUm56Y05KUG1YR29xOGhiTTRjdVJFSVNxRmQ4SlZYZWlZK3lq?=
 =?utf-8?B?cGY2VEVjdnVhY3FCcTZOQ0hRWm5LYSsvblJwY1ZFeG1lQ3U0UXpiRG9vK0Mx?=
 =?utf-8?B?aWt5bGtlbkN6SHFGdlhHTnJUWmt2WmFqVTR1eUxaTzAvZHZ1enRYUkZuUFZq?=
 =?utf-8?B?UTU4aVJXaDVRZjdVMDA4RVNjWTU3MERCcGI3eWlwZ09xTEVOY25nV1h4T0dM?=
 =?utf-8?B?bHp1M2t6U2JRbnNxYUlCeUQvUVR1S2VES1B4Z1o3NmU4Q1phSWNONXZ6ZU82?=
 =?utf-8?B?VmVSM1Z0VTAvWk5WZE9GWXp1WGErZG14RVJoQTNkZ1N3K3dMbkdUbmdwV29C?=
 =?utf-8?B?TjZDM21WcGZFcUdHNzM5amNRVTRVM0V1bVNOY3h0akxJNW9RWW00TDJ1SzYw?=
 =?utf-8?B?ZGpSNlVxWEIzTDlwalV3cmYzeTVDNWRvTGdDalUxWkJyd0ZZcE42OWRTeUt4?=
 =?utf-8?B?QTZUSkN2bUtRdXBrWmxZai84Q1FJeTN3NWwwMWxtVEw0YVRITDlJS3BPV2Jy?=
 =?utf-8?Q?LhkY=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: a120e2fe-778b-4803-f210-08dda96a8ca3
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2025 04:35:24.7485
 (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: yaKCbl2/GnQeEnOtFaSq8iCKVVIHhXvGm1kAoODTMDJPYFptbbcs906a28qreGdqj4LFL6XKDHM+KKVFgUTv8A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR12MB6345

W1B1YmxpY10NCg0KSGkNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBK
YW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFR1ZXNkYXksIEp1bmUgMTAs
IDIwMjUgOTowNSBQTQ0KPiBUbzogUGVubnksIFpoZW5nIDxwZW5ueS56aGVuZ0BhbWQuY29tPg0K
PiBDYzogSHVhbmcsIFJheSA8UmF5Lkh1YW5nQGFtZC5jb20+OyBTdGFiZWxsaW5pLCBTdGVmYW5v
DQo+IDxzdGVmYW5vLnN0YWJlbGxpbmlAYW1kLmNvbT47IEFuZHJldyBDb29wZXIgPGFuZHJldy5j
b29wZXIzQGNpdHJpeC5jb20+Ow0KPiBBbnRob255IFBFUkFSRCA8YW50aG9ueS5wZXJhcmRAdmF0
ZXMudGVjaD47IE9yemVsLCBNaWNoYWwNCj4gPE1pY2hhbC5PcnplbEBhbWQuY29tPjsgSnVsaWVu
IEdyYWxsIDxqdWxpZW5AeGVuLm9yZz47IFJvZ2VyIFBhdSBNb25uw6kNCj4gPHJvZ2VyLnBhdUBj
aXRyaXguY29tPjsgU3RlZmFubyBTdGFiZWxsaW5pIDxzc3RhYmVsbGluaUBrZXJuZWwub3JnPjsg
U2VyZ2l5IEtpYnJpaw0KPiA8U2VyZ2l5X0tpYnJpa0BlcGFtLmNvbT47IHhlbi1kZXZlbEBsaXN0
cy54ZW5wcm9qZWN0Lm9yZw0KPiBTdWJqZWN0OiBSZTogW1BBVENIIHY0IDA0LzIwXSB4ZW46IGlu
dHJvZHVjZSBDT05GSUdfU1lTQ1RMDQo+DQo+IE9uIDI4LjA1LjIwMjUgMTE6MTYsIFBlbm55IFpo
ZW5nIHdyb3RlOg0KPiA+IEZyb206IFN0ZWZhbm8gU3RhYmVsbGluaSA8c3RlZmFuby5zdGFiZWxs
aW5pQGFtZC5jb20+DQo+ID4NCj4gPiBXZSBpbnRyb2R1Y2UgYSBuZXcgS2NvbmZpZyBDT05GSUdf
U1lTQ1RMLCB3aGljaCBzaGFsbCBvbmx5IGJlIGRpc2FibGVkDQo+ID4gb24gc29tZSBkb20wbGVz
cyBzeXN0ZW1zIG9yIFBWIHNoaW0gb24geDg2LCB0byByZWR1Y2UgWGVuIGZvb3RwcmludC4NCj4g
Pg0KPiA+IE1ha2luZyBTWVNDVEwgd2l0aG91dCBwcm9tcHQgaXMgdHJhbnNpZW50IGFuZCBpdCB3
aWxsIGJlIGZpeGVkIGluIHRoZQ0KPiA+IGZpbmFsDQo+DQo+IE5pdDogcy9maXhlZC9hZGp1c3Rl
ZC8gPyBJdCdzIG5vdCBhIGJ1ZywgYWZ0ZXIgYWxsLg0KPg0KDQpVbmRlcnN0b29kLg0KDQo+ID4g
cGF0Y2guIEFsc28sIHdlIHdpbGwgYWxzbyBzdGF0ZSB1bnNldHRpbmcgU1lTQ1RMIGluIHB2c2hp
bV9kZWZjb25maWcNCj4gPiB0byBleHBsaWNpdGx5IG1ha2UgaXQgdW5hdmFpbGFibGUgZm9yIFBW
IHNoaW0gaW4gdGhlIGZpbmFsIHBhdGNoLg0KPg0KPiBFdmVuIHdpdGhvdXQgdGhlIGRvdWJsZSAi
YWxzbyIgdGhpcyByZWFkcyBvZGQuIEJ1dCBpdCdzIGFsc28gdW5jbGVhciB3aGF0IGl0IGhhcyB0
byBkbw0KPiBoZXJlLCBub3Igd2hldGhlciB3aGF0IGlzIGJlaW5nIHNhaWQgaXMgYWN0dWFsbHkg
Y29ycmVjdC4NCj4NCg0KSG1tbSwgSG93IGFib3V0ICAiDQpUaGUgY29uc2VxdWVuY2VzIG9mIGlu
dHJvZHVjaW5nICJDT05GSUdfU1lTQ1RMPXkiIGluIC5jb25maWcgZmlsZSBnZW5lcmF0ZWQgZnJv
bSBwdnNoaW1fZGVmY29uZmlnDQppcyB0cmFuc2llbnQgYW5kIHdpbGwgYmUgYWxzbyBmaXhlZCBp
biB0aGUgZmluYWwuIg0KDQo+ID4gLS0tIGEveGVuL2NvbW1vbi9LY29uZmlnDQo+ID4gKysrIGIv
eGVuL2NvbW1vbi9LY29uZmlnDQo+ID4gQEAgLTU3OSw0ICs1NzksMTUgQEAgY29uZmlnIEJVRERZ
X0FMTE9DQVRPUl9TSVpFDQo+ID4gICAgICAgQW1vdW50IG9mIG1lbW9yeSByZXNlcnZlZCBmb3Ig
dGhlIGJ1ZGR5IGFsbG9jYXRvciB0byBzZXJ2ZSBYZW4gaGVhcCwNCj4gPiAgICAgICB3b3JraW5n
IGFsb25nc2lkZSB0aGUgY29sb3JlZCBvbmUuDQo+ID4NCj4gPiArbWVudSAiU3VwcG9ydGVkIGh5
cGVyY2FsbCBpbnRlcmZhY2VzIg0KPiA+ICsgICB2aXNpYmxlIGlmIEVYUEVSVA0KPiA+ICsNCj4g
PiArY29uZmlnIFNZU0NUTA0KPiA+ICsgICBib29sICJFbmFibGUgc3lzY3RsIGh5cGVyY2FsbCIN
Cj4gPiArICAgZGVmX2Jvb2wgeQ0KPg0KPiBXaHkgZGVmX2Jvb2wgd2hlbiB5b3UgYWxyZWFkeSBo
YXZlIGJvb2wgb24gdGhlIGVhcmxpZXIgbGluZT8NCj4NCg0KQWNrLCB0aGVuIGhlcmUgbWF5YmUg
YSBzaW1wbGUNCiINCmNvbmZpZyBTWVNDVEwNCiAgICAgICAgZGVmX2Jvb2wgeQ0KIg0KIGlzIGVu
b3VnaC4NCg0KPiA+ICsgICBoZWxwDQo+ID4gKyAgICAgVGhpcyBvcHRpb24gc2hhbGwgb25seSBi
ZSBkaXNhYmxlZCBvbiBzb21lIGRvbTBsZXNzIHN5c3RlbXMsDQo+ID4gKyAgICAgdG8gcmVkdWNl
IFhlbiBmb290cHJpbnQuDQo+DQo+IFRoaXMgaXNuJ3Qgb3Zlcmx5IHVzZWZ1bCAoYnV0IHBvc3Np
Ymx5IG1pc2xlYWRpbmcpIGFzIGxvbmcgYXMgdGhlIHByb21wdCBpc24jdCBnb2luZw0KPiB0byBi
ZSB2aXNpYmxlLCB5ZXQuDQo+DQoNClVuZGVyc3Rvb2QsIEknbGwgcmVtb3ZlIHRoZSBkZXNjcmlw
dGlvbiBoZXJlIGFuZCBhZGQgaXQgaW4gdGhlIGZpbmFsIHdoZW4gcHJvbXB0IGlzIHZpc2libGUN
Cg0KPiA+ICtlbmRtZW51DQo+DQo+IEJsYW5rIGxpbmUgcGxlYXNlIGFoZWFkIG9mIHRoaXMgb25l
Lg0KPg0KDQpBY2sNCg0KPiBKYW4NCg==


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 06:51:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 06:51:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012371.1390796 (Exim 4.92)
	(envelope-from )
	id 1uPbmn-0003Fv-Dp; Thu, 12 Jun 2025 06:51:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012371.1390796; Thu, 12 Jun 2025 06: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 1uPbmn-0003Fo-9a; Thu, 12 Jun 2025 06:51:41 +0000
Received: by outflank-mailman (input) for mailman id 1012371;
 Thu, 12 Jun 2025 06:51: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 1uPbmm-0003Fi-Hj
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 06:51:40 +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 a9d7a0d6-4759-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 08:51:27 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a361b8a664so533179f8f.3
 for ; Wed, 11 Jun 2025 23:51:27 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-748808964eesm701275b3a.46.2025.06.11.23.51.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Jun 2025 23:51:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a9d7a0d6-4759-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749711087; x=1750315887; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ShrYksDKkyCJfTLNCZKiloLLKzjKcP5cPvKqfsiGPyE=;
        b=EpqcBV+htpJCqoXzMbUrMm07wr8TW4CzhaBju9O4QTm52AXxGLgrjMLnouj8h2VNrb
         9QQJas3jtKYy+zIXSVoEnCve09fyZgeftljnsQrl3RXMQwYuL3ye/ww+ay/GqOzraQPR
         6gVTZ8/CfkovWhtq19+9D2Yqf8eKmIIAS42EqjPB3EPjQgPiaLFtYKg4sMi4dbXz5+wX
         Y/y9SZ6dt8xO9Xe6mXZYmcRbMNBqfoUWYDG0FEnUXTcQaMKxrjVyBe+Cx04V9fZb72su
         9hQz1dAZspDV2ApAaJvp7AyZYURuKRuO7FG/2AWXCSn9AEfS8BeG/30uXZ4bwvb3FySZ
         jvxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749711087; x=1750315887;
        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=ShrYksDKkyCJfTLNCZKiloLLKzjKcP5cPvKqfsiGPyE=;
        b=ClvdEijRNmEKLBHI6dzMej4XYoMRbdRGv1WfZEVBmwIf2sZm3l1blfQlxFuiODrTrb
         BKb02yD2fjvi4jObviZi+kP/icwG3tTK76WTEc2KY6cHGwE+0hrrEq2uKS0KZk6qHjAl
         6T1u2J1j3qfkSCW0cv5PvZ3kNBpE51px2Dk/LKnEu5ucoQMzddMoC6u59k2k6a/HKahj
         e1arec0Zq6V01/hrGxuaT6LXdYO58D8P+G9DXU9pQRECXDQSvB1p9uKGzK7tEpNJWEr1
         XbWXKGTsYnYp1Hm4Adlg4Fy/GmhxFJdo1igg5ycetD6pRvqGf/o1wXwxnBGkAPrR0sPs
         gPJg==
X-Forwarded-Encrypted: i=1; AJvYcCXHOgRSWftNFh1vp0YD/ANE0kw/TAClyVWdYgMkk/oPWkoGA294FuOzzJV7p2r42UPyHHzWnVLgids=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxW6ZF74ageOXMO3iLX+07+EeTB3jHDVeIm0h6qnbrhaOYVGXul
	t8yZhOF8L9EtRhsFKJbYmMNdqv6rJ6bhdXXSpcF9E5+b9XvMFr+PU+hHFYTNIrTpUw==
X-Gm-Gg: ASbGncvTpUy9qkBGou2PujEnyqF7Oy1rg8PQ/fz1wUvAcnEWxf8tqpodHcUs27ocuez
	02HlKUE/VnNCLq0Sd7rG/S6Vcn4FKcPWGmg3LYf4AldjwiPdCU/d8Q43kHI9hKstzVdQm02q6Cm
	EUfg+1XitO87ppHqDGwtkNnfuAHSmCTPBaBCngLnlvKfEd2Jp8wiemTqHpu6rI+ZtulTSUL3z3m
	gcz3Hy/bMJXS0p01k6gTDjLYVh+A/aG88NXgVwZAd3TsTpui2NuhutSh+wsdk+Ri1vZPABHgVYh
	kzY/eCdvOmrb06uJNsEItaVkKTPIXKU5ajQsBp/JowHwe9VXJ4/JaiZsb6SEy/+lr/pGOjI+Dcr
	VgSn1kzeYvox/xNyi+DiGksndVGvEZIjMoo+ntsDlYo7ueRU=
X-Google-Smtp-Source: AGHT+IGikqYbarbpbCx77Ih9WX/ib4+mLbtsWlJuiBqJAtkhgROgJHq3WZuQmXrcSQr9wYvJSZiGGg==
X-Received: by 2002:a05:6000:2508:b0:3a5:2ef8:3505 with SMTP id ffacd0b85a97d-3a558a27684mr4402957f8f.37.1749711087028;
        Wed, 11 Jun 2025 23:51:27 -0700 (PDT)
Message-ID: 
Date: Thu, 12 Jun 2025 08:51:16 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/2] xen/console: unify printout behavior for UART
 emulators
To: Stefano Stabellini 
Cc: dmkhn@proton.me, andrew.cooper3@citrix.com, anthony.perard@vates.tech,
 julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com,
 dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250606201102.2414022-1-dmukhin@ford.com>
 <20250606201102.2414022-3-dmukhin@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: 7bit

On 11.06.2025 21:07, Stefano Stabellini wrote:
> On Wed, 11 Jun 2025, Jan Beulich wrote:
>> On 11.06.2025 02:07, dmkhn@proton.me wrote:
>>> On Tue, Jun 10, 2025 at 10:21:40AM +0200, Jan Beulich wrote:
>>>> On 06.06.2025 22:11, dmkhn@proton.me wrote:
>>>>> From: Denis Mukhin 
>>>>>
>>>>> If virtual UART from domain X prints on the physical console, the behavior is
>>>>> updated to (see [1]):
>>>>> - console focus in domain X: do not prefix messages;
>>>>> - no console focus in domain X: prefix all messages with "(dX)".
>>>>
>>>> While, as indicated (much) earlier, I can see why omitting the prefix
>>>> may make sense for the domain having input focus, ...
>>>>
>>>>> --- a/xen/drivers/char/console.c
>>>>> +++ b/xen/drivers/char/console.c
>>>>> @@ -740,7 +740,17 @@ 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 */
>>>>> +            char prefix[16] = "";
>>>>> +            struct domain *consd;
>>>>> +
>>>>> +            consd = console_get_domain();
>>>>> +            if ( consd != cd )
>>>>> +                snprintf(prefix, sizeof(prefix), "(d%d) ", cd->domain_id);
>>>>> +            console_put_domain(consd);
>>>>> +
>>>>>              nrspin_lock_irq(&console_lock);
>>>>> +            if ( prefix[0] != '\0' )
>>>>> +                console_send(prefix, strlen(prefix), flags);
>>>>>              console_send(kbuf, kcount, flags);
>>>>>              nrspin_unlock_irq(&console_lock);
>>>>>          }
>>>>
>>>> ... this, aiui, is a behavioral change for the non-dom0less case, where
>>>> Dom0 output will suddenly also gain the prefix. Which I don't think is
>>>> wanted: Switching focus between Xen and Dom0 should remain unaffected
>>>> in this regard.
>>>
>>> This change ensures that dom0 traces aren't mixed with domU traces when domU
>>> has input focus, or with Xen traces when the administrator is in the diagnostic
>>> console.
>>
>> That's what the description also tries to describe, yet I still regard it as
>> a behavioral regression in (at least) the described scenario. The hardware
>> domain presently not having (d0) prefixed to its output is deliberate imo,
>> not accidental.
> 
> If we only consider the classic dom0 and dom0less usage models, then
> what you wrote makes perfect sense. In the classic dom0 case, it is best
> for dom0 to have no prefix, which is the current behavior.
> 
> However, things become more complex with dom0less. As we have discussed
> previously, it has already become desirable on both ARM and x86 to align
> on the same behavior. During our last discussion, the preference was to
> add a '(d0)' prefix to clearly differentiate output from dom0 and other
> domains.
> 
> Up to now, we could easily detect the two different cases depending on
> the boot configuration. The problem arises with Denis' patches, which
> add the ability for dynamically created guests via `xl` to access an
> emulated NS16550 UART that prints to the console. Because these guests
> are created dynamically, it is not clear how we are going to handle
> this case.

Why would this be not clear? We already prefix their output with "(d)"
when going the traditional way. The same would then apply to output
coming through the emulated UART.

> If we follow the dom0less preference, then we would need a '(d0)' prefix
> for dom0. If we follow the classic dom0 model, then dom0 would remain
> without a prefix, and the new domUs would have a prefix. This would
> cause an inconsistency. However, this is what we have today on ARM with
> dom0less.
> 
> If Jan feels strongly that we should retain no prefix for the classic
> dom0 case, which is understandable, then I believe the best course of
> action would be to change our stance on dom0less on both ARM and x86 and
> also use no prefix for dom0 in the dom0less case (which is the current
> state on ARM).

Leaving aside that "dom0 in the dom0less" ought to really be not-a-thing,
I disagree. Present behavior of not prefixing the domain's output which
has input focus continues to make sense. That requires Dom0 to have a
prefix whenever it doesn't have input focus.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 06:57:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 06:57:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012377.1390806 (Exim 4.92)
	(envelope-from )
	id 1uPbsJ-0003r3-09; Thu, 12 Jun 2025 06:57:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012377.1390806; Thu, 12 Jun 2025 06: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 1uPbsI-0003qw-T8; Thu, 12 Jun 2025 06:57:22 +0000
Received: by outflank-mailman (input) for mailman id 1012377;
 Thu, 12 Jun 2025 06:57: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 1uPbsH-0003qq-HJ
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 06:57: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 7c30ff73-475a-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 08:57:20 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3a54700a463so318130f8f.1
 for ; Wed, 11 Jun 2025 23:57:20 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-4532e172b03sm10812955e9.36.2025.06.11.23.57.19
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 11 Jun 2025 23:57:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7c30ff73-475a-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749711440; x=1750316240; 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=55o822H8e2PldMgk8POtsqloOM8M58Ext2aqbafU+dE=;
        b=LbQ+Z7Nqv7k0DfgMgmu8rKnjSahmQtwQCkiTodGGDXgTYjBNPj7fWJuK8IgdQmqvdt
         DMdBa5E6nUDMs3O2Bn3LzmNMP1j7JddRyBUufSgz+QX8XTTZEuJvfXfhbsvosUE1UEa+
         x761f3ykhMMS4RrQcksEmc/Aidrn2pymZP7X8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749711440; x=1750316240;
        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=55o822H8e2PldMgk8POtsqloOM8M58Ext2aqbafU+dE=;
        b=jU89ETceyEs/2FzSs1X/bgsMXZgocGO1Ns53TsBB4mo+8/Tc6Rv1njrm1/o7DMV2/n
         GJGRhiT5Z/GUxa83ooy7RKyKfhqdlJ3fDK6kIG0RrzN/sZNV29NRDBVu5QdehlIq9OWf
         J+ocOEKWY0nvWV6fSd/2vqikVrtLvZ60qPoj2W6smEalyaaV4vis+EZFfxCQVooBQN2N
         QFH9LJRtl0RzdrFeJn5REJrxIc2mFiaHmZuhfgzwp7lyXF09/LQ7erva4QMABBbwAQwX
         QNuCdwlsp5ASyFoil7MUbCrp6IWlu7A8jASKR/lWECnZSvnCDNXHqQIRIZCnDfNOVulj
         uiZQ==
X-Gm-Message-State: AOJu0Yz9srNZhOGPaIOx4XpisFkkW3HNp8ec9iH4zKHr9aJgxOjZ0Os1
	VlKKUVWYPr3ARzsL+baBnv3QmDT64T2MDDLOKckedKKz4Pw4mE828sTc4qR3mrmffRA=
X-Gm-Gg: ASbGncsnnWz3bX0QAXeJiitl30u7LSAENfBteovt3pkm8bLGa5o45CJeWADpnWdZk0f
	PIcIPj3NwBlBv+fDITYkWaGJOoA6onjB0/F3SqSiMxJ0RunJMeJ74Rt5Ug8svLW7DVa/ubADq5x
	AeaDC1czYLde6l4SclLhJTSlwfezJDx4j0xEGMX+nEr4KJnghNqBjcyGUvq9GL5L8WufxhgzunN
	dd/2G4zG73AVkM9HoVsvHDhqwbjtulxMw0Rx2ZNP7t3O9g+9iWm5y2Sx/96KlzRvA+9rVbI0mL6
	5tQ/zQMMArpKb0AwyHngZ1jUYXUmg56TVI3XZns9BnQTjyjrj6Pse/8Z/X2Gfa5U5zygTxWtfab
	U4K46pfXg/yVgMKrWrPaK1WFofFNMG4bMX70=
X-Google-Smtp-Source: AGHT+IH6KxSbGu7iPPUZlR8DT419YjztuQPT/Aznzs+FBEBKbb3cKfsD41jtpatF8nrJpwifpnwxMg==
X-Received: by 2002:a5d:64e3:0:b0:3a5:1220:36d4 with SMTP id ffacd0b85a97d-3a560814c09mr1799097f8f.22.1749711439872;
        Wed, 11 Jun 2025 23:57:19 -0700 (PDT)
Date: Thu, 12 Jun 2025 08:57:18 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Andrew Cooper 
Cc: xen-devel@lists.xenproject.org, Jan Beulich 
Subject: Re: [PATCH 1/8] x86/pdx: simplify calculation of domain struct
 allocation boundary
Message-ID: 
References: <20250611171636.5674-1-roger.pau@citrix.com>
 <20250611171636.5674-2-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 Wed, Jun 11, 2025 at 06:58:31PM +0100, Andrew Cooper wrote:
> On 11/06/2025 6:16 pm, Roger Pau Monne wrote:
> > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> > index 7536b6c8717e..2f438ce367cf 100644
> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -461,30 +461,6 @@ void domain_cpu_policy_changed(struct domain *d)
> >      }
> >  }
> >  
> > -#if !defined(CONFIG_BIGMEM) && defined(CONFIG_PDX_COMPRESSION)
> > -/*
> > - * The hole may be at or above the 44-bit boundary, so we need to determine
> > - * the total bit count until reaching 32 significant (not squashed out) bits
> > - * in PFN representations.
> > - * Note that the way "bits" gets initialized/updated/bounds-checked guarantees
> > - * that the function will never return zero, and hence will never be called
> > - * more than once (which is important due to it being deliberately placed in
> > - * .init.text).
> > - */
> > -static unsigned int __init noinline _domain_struct_bits(void)
> > -{
> > -    unsigned int bits = 32 + PAGE_SHIFT;
> > -    unsigned int sig = hweight32(~pfn_hole_mask);
> > -    unsigned int mask = pfn_hole_mask >> 32;
> > -
> > -    for ( ; bits < BITS_PER_LONG && sig < 32; ++bits, mask >>= 1 )
> > -        if ( !(mask & 1) )
> > -            ++sig;
> > -
> > -    return bits;
> > -}
> > -#endif
> > -
> 
> I'm very happy to see this disappear.  Both because of a non-__init
> function calling an __init function, and because this internal is just
> horrible.
> 
> >  struct domain *alloc_domain_struct(void)
> >  {
> >      struct domain *d;
> > @@ -498,14 +474,15 @@ struct domain *alloc_domain_struct(void)
> >       * On systems with CONFIG_BIGMEM there's no packing, and so there's no
> >       * such restriction.
> >       */
> > -#if defined(CONFIG_BIGMEM) || !defined(CONFIG_PDX_COMPRESSION)
> > -    const unsigned int bits = IS_ENABLED(CONFIG_BIGMEM) ? 0 :
> > -                                                          32 + PAGE_SHIFT;
> > +#if defined(CONFIG_BIGMEM)
> > +    const unsigned int bits = 0;
> >  #else
> > -    static unsigned int __read_mostly bits;
> > +    static unsigned int __ro_after_init bits;
> >  
> >      if ( unlikely(!bits) )
> > -         bits = _domain_struct_bits();
> > +         bits = flsl(pfn_to_paddr(pdx_to_pfn(
> > +             1UL << (sizeof(((struct page_info *)NULL)->v.inuse._domain) * 8))))
> > +             - 1;
> 
> I think this would benefit greatly by not being a oneliner.  There's
> sizeof_field() which helps a little.

Oh, I missed that.  I was expecting to find something like
member_size() or similar.

> But, isn't this UB with CONFIG_BIGMEM?  You're shifting 1UL by 64.

CONFIG_BIGMEM doesn't get here (see the #fidef above).

> When __pdx_t is unsigned long, there's no bits restriction necessary. 
> Therefore, don't you want !bits && sizeof_field(...) < BYTES_PER_LONG as
> the entry criteria?

__pdx_t being unsigned long can only happen for CONFIG_BIGMEM, and
that's still handled separately using a #if defined(CONFIG_BIGMEM) ...
(which I should have converted to #ifdef instead).

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 07:00:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 07:00:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012387.1390816 (Exim 4.92)
	(envelope-from )
	id 1uPbvU-0005RP-Hc; Thu, 12 Jun 2025 07:00:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012387.1390816; Thu, 12 Jun 2025 07:00:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPbvU-0005RI-EK; Thu, 12 Jun 2025 07:00:40 +0000
Received: by outflank-mailman (input) for mailman id 1012387;
 Thu, 12 Jun 2025 07:00: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 1uPbvS-0005RB-Kt
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 07:00:38 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on2061e.outbound.protection.outlook.com
 [2a01:111:f403:2413::61e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id eb8299e9-475a-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 09:00:28 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 CH3PR12MB7739.namprd12.prod.outlook.com (2603:10b6:610:151::22) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.35; Thu, 12 Jun
 2025 07:00:23 +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.8835.018; Thu, 12 Jun 2025
 07:00: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: eb8299e9-475a-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=biNiFToTtcvyDEzV6Df1kh+bgcYXxa58KeyDpSTamUefLFuuld/FHGJJZNOmX7uLjrgYPBzhV9eYe1WR9DRjXff86u56AU3kWBaoNx4Qq113VSFC9ZUprsB2jKAhP2HcKQ3Q+RdbGMxfYHUA43QjE6aXYZ7iYFY9kQ6c1amQ9IenrY3IIgfVQwiFx2vBGWeOSW7EbfZYWXw/CaMRPxIsCm/Fx7XpXhfLUQ2+WVsu1wwlkh8OJGL0ot+l4UcH2Jg4TXQIaV2CY6Jg9LKdsVXnbuglpZEQV8f2YYlW7s5bbQBHlw9oa+wveANrxiLD6mNgea1sIOPuVntvaOVDwBLllA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=MwJfmSiizxG16M3p9NxbNFxkoWlYAftQWJ274DMNj0Q=;
 b=P3K+32b2xO1+1U2bcc4UubstgQXvnlST2mCgLrBGBzjQ59oZFOGdbmeyHTfh5by/1mG2JUaQvo9osD+E7PjKJLnRR3wCX3y7jwrKeK0qBZtLHT3Hunn53B+GPVQYJzcJnWp8SgYygjJe9O9LPXAwIraAuOa2+k1C7xBdrHagbZeBnr3Y9mmL4MthamxufDTmvmSnGhAi5XcJfeawZxm/HD7Yic/aiCjF9mlGCdM0YH8/QlgZi2V/JjZBKbQ0nX+V4saTMkLgr3juqDe/L8t73fgZ/wGSvVbzhCDt5jFM/rD41Ibqbiss5jfeXR3Dzf6+OdfKf8Hz+FRRSBrwZPPTmA==
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=MwJfmSiizxG16M3p9NxbNFxkoWlYAftQWJ274DMNj0Q=;
 b=0In32TfFzqfxLuWpxG0+izM3XzvS5tlnInUbtoyF4fdZsb+Vax+CSxxgFSYVz7f5zwxHYXnGkIvmYGyaf+sB1rgrlkrl6VfMd5sveEhT5PBlXJB3k+WXkayulwICWHtxOAxtLZNavDxeGAVhZ0EtDO7Xdzn5Fni0h+XXVtWygfQ=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Andrew Cooper
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Anthony PERARD , "Orzel,
 Michal" , Julien Grall , Stefano
 Stabellini , "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v4 11/20] xen/pmstat: introduce CONFIG_PM_OP
Thread-Topic: [PATCH v4 11/20] xen/pmstat: introduce CONFIG_PM_OP
Thread-Index: AQHbz7FxOQ3KP08ui0ayy8qSOpLdm7P8ezaAgAKyKdA=
Date: Thu, 12 Jun 2025 07:00:23 +0000
Message-ID:
 
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
 <20250528091708.390767-12-Penny.Zheng@amd.com>
 <1a660f83-5d9a-402b-af28-ea82311b37ce@suse.com>
In-Reply-To: <1a660f83-5d9a-402b-af28-ea82311b37ce@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=True;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-06-12T07:00:07.0000000Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=3;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged
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_|CH3PR12MB7739:EE_
x-ms-office365-filtering-correlation-id: 434091b9-46cf-431d-b539-08dda97ecd98
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?WEpVUWorTlI2SURaNDc5ZXh5c3R2R3ZaZ3V1TEpiN095TUVUajVVendiUmZK?=
 =?utf-8?B?Nkg4OXdwbUdndDZYUUNlRGFHaGxxVXFzQkhZVEtMSnVPUnJoUXQ4bmxXWWxj?=
 =?utf-8?B?NGs4QkR5NjVtOU9UdC9tWEZFamFiTUFsclgyZTNxVmdJTzZhMmZhbVNaNGVW?=
 =?utf-8?B?aW8vaHpZaVpWMDQ1UEp5aWp2bHRQd2dZRG1MWWpNWlhqTjhlVFEzb2d5Ujlz?=
 =?utf-8?B?VEJlMzB5anZhcGhCZHhia25BbERwQ1FBVThkaDhtZmtqbHhRL25hazAwT0RN?=
 =?utf-8?B?cGpocW1zRDN1UVdMenI3WUNmTUR6V3JtYzRsKzRuVnlpdEtvOC9CLzF1cnpE?=
 =?utf-8?B?SjMxQzA4eWd2b3VhbHZIT1FGbVR5bG05bFhnOXUyQnZ1VDNSRmlrdm1QWFRl?=
 =?utf-8?B?NnBBVkM3V2FyMFNVdFYwS05Iejh3Yzg1b05uM1Rqb3BlWEZLQkV5YzhTYWh6?=
 =?utf-8?B?ai9EMXRUbldwT0F5Umx4em9pcVdsRmdveDgwWkZwNkI2MXJiRDJqd3N3dUtK?=
 =?utf-8?B?bHhIcHdGN2xneURkdXVudloyd3VSRER1TTFEUnVmZzBxNVZNSTV5dFhvYUFT?=
 =?utf-8?B?b3VkRTg1a29jOU9Hd2FROE9ITnJjUVBZbENmZGRUd0dieGtTWGlpNFRrUjBI?=
 =?utf-8?B?SkJ6VExqRnVrc0kzejRXMEVNL05GLy8xejhJYVZ2UEptUHhyU1hCQVlLRVdo?=
 =?utf-8?B?VFREU1o1SzRrdTFyTTFDbjRPYlRHakpydVJ0VFlWRDgvcTUrdjdvUnZYT042?=
 =?utf-8?B?VlhpM29KSnQwbVpJRHNWemRSMFFzTFhnWjJpc25iYzVTNEVYQm9TdTZpR0M3?=
 =?utf-8?B?cDU5b3pWL1NseDU5clVVeHRrYzZUL0luQjZHZS9oNEdHS2tKYmJlVStjemt6?=
 =?utf-8?B?VTlqOEgxdHkzZGwwQnM1eHVkSEROSXFRUUhVa2l4N2NTY0tIQzR5UXVXSnZr?=
 =?utf-8?B?UUxReVpienFkZlpYK3dOSWZVUDdiMXJMTGxrZXJxWmhKZmg5aEVVdlhRQTV5?=
 =?utf-8?B?VEpHYUt4bFYxR09yaTF4QlJSR3VZWC84dTI3MStvSUxYTVBmQlp4Qm14VElS?=
 =?utf-8?B?a3NFQ3dwSUVUa0RGUWpwMElyNjh1VWQ5cCsyR0lUanhISHdWTHlLRTRycnph?=
 =?utf-8?B?cEVvbHQ5RzEvN1c5QXF1blRaNWhzVXdyaGVKNUl5cEZwSjdXZzhNSndVdUZu?=
 =?utf-8?B?SHM3MnpVQ2lMaW56SDAxdWpFem5uWE9BNk5Kd1Z4cjEwMnFscmpsczZ5OFln?=
 =?utf-8?B?WVhKWklMaGtLQ3VEa2wyblB3UzJHTEVlYXZOL0dGcWcyVElVdVV6MVVxbG1n?=
 =?utf-8?B?RkE4QkdTYWFzUXo2QS9YOEY5T0h1bTc1TCtWa3lWNXBJSVVzRjljY0svaDJs?=
 =?utf-8?B?MDl5dUp4dlZzcVJKandkQ1R2U0hTR2R0eE9SalpMRFEyamNCVkt6NG93anBV?=
 =?utf-8?B?U0hHbS85cThWVzQ2dzd6QXA4SXZtMVB5UHBvMHNMeDNMVHhlKzJJcUp4SGky?=
 =?utf-8?B?NGFtWlk5MlNDZHQ0OTRRMklHVWplZ0R3ZWVYdFJPSWdHZVBwMVV1VGR5UzZV?=
 =?utf-8?B?WmFVVHRXdFMzYzhCWEZPWGpJTnRROUU5REhuMmVhMzRIc1JMSGNZYjh1MU9X?=
 =?utf-8?B?RW5wWVhoYW50NmhIWTBrdFd0Sm03ZXlyd0grSUdpYmpGLzVpN01hc1FudERD?=
 =?utf-8?B?MTVBa2RvUWxIZDh2enRaYXpnVmtyamdoOERLczNnOHZkQlN1ZUJtRVBiMHlx?=
 =?utf-8?B?Si9NQm1MejhualBLNG90QnFnbWZ4dU4vS2NqQnRjRWFqVkJqb3h5eDAybmQ4?=
 =?utf-8?B?VkxSbDVGaHBFRit3dWJqY3VxNkc1NGNaOWtweU9kK0hXS1NnMXhaSmtxTkhq?=
 =?utf-8?B?NE04YytQOFRqYnJNWlNZZ1B6SmsveVJ4L09tY2FkRm9qZmdTaUJEbVRqaWNx?=
 =?utf-8?B?RnNnWks0VGswNVgrMitVb0xMK0ovMEI5QXAwazhtZzNRQUpUUys2amZMdXV6?=
 =?utf-8?Q?hew7sap4RWDcHSmNPaKx5/jTLzaB/k=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)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?eVZnKzdvWllld1NuOHdYaENCaXIxWmlQSnFBLzFIeWpVN0NROUZWSllqU1pU?=
 =?utf-8?B?dks4QkwzVC9jZGRsVFdqc0FqQ2FnSGhsajdzYTBGTUhZNmVLSnkzSm1teDNT?=
 =?utf-8?B?YkwzY1d3SXJFUHVISll6a3BPbWs0VysxZGxlMitIRVFFa2dNRjRtRGUxaUtO?=
 =?utf-8?B?NHZubHNxZW42QkM5aU1EUjNiYXRmaGkrSG45b0dWQnU5WDgyNmRwUHBvZEFH?=
 =?utf-8?B?S0tlZnpja1g3SFNWZFRYcXplbU8yTGlOT25pWkl1SWkvcEJSa3NqemMyLzJ1?=
 =?utf-8?B?Kys0MVIzcXR0a0tOV3JoODljcWw5bVZueXRTd29Pbk9PeGQzL05RZFNXVnNp?=
 =?utf-8?B?bzBSUXF6T3NGeTNmbXdxUUdiak5kYU5YY1liNTJ1UElvc3EzeXRXQVI4UEVV?=
 =?utf-8?B?N29HekpPcWRwc0pCME13Zys4VlFqTUhIeDlIRG40NDI4aUdycGRtdDdibldX?=
 =?utf-8?B?T1JFbU9TSGtPRGtqOUpoZnhaeERZRXAwVkVHMVpaWllDQStHbjA1KzBoZmxn?=
 =?utf-8?B?RmRGcWxDR2dKRW9tamE2bnVEcjROT1lsSWdBREhjRUZKc1JrNVJoRmRTRlY1?=
 =?utf-8?B?L3JIa216UkxPMHdnS040SGg5Z0xoQzVyQmdobW1KVDdnemtyV3BUaDRabFpn?=
 =?utf-8?B?ZEN4Wm54NndLNmptaWhCT0d5WStlQ0dGK1BXSGdoblVOR2QvRHdaT1VmOUVn?=
 =?utf-8?B?RmQ3d2pyd3FqVlhpamdSVjEwTnN1b2o5M0RvelVLZmwyRVhnaVhHOWE2TlBE?=
 =?utf-8?B?N21BaEQ2bWFLbDMzb3UrcDRrbHdvMnRPSThvOEFDMnNCaktaUFkxV2FjRXZ4?=
 =?utf-8?B?MExSSG9WZkdUV29WNXdRNHQzbks4Rk4rdG52bFVPRXRQdWxWQ1JwTkxHTmo5?=
 =?utf-8?B?TmhxVkhQaHl2T0VKeWZMbThOcitsSWp3QVluTTRyR1FNSGI0OGMwRDU2aENq?=
 =?utf-8?B?ay9rWXkxQ0RzbVhpdjI2eEd6Wm1XVWd2ZnFITkZNVUhHanJPNk9PbUNiVnMr?=
 =?utf-8?B?UkhSWFNnemFoZWZ5SkRGVVNIV1J6RmFIaVlyejMwYzk3WDRUMlh3ak90K3BQ?=
 =?utf-8?B?QzV5aWI4WnJWa0RJQUtqb3pZSTVYTmk5eVl2UDFKU1hqQjkwdnZGdHpCYXor?=
 =?utf-8?B?dmo1c08xK203TzNscVgwRytFTmtMc0JZOTFtdkhEOVhGcTdGVUloKzRvT1Yv?=
 =?utf-8?B?cy9Td2krVHJ6bmlKTnVjQVhhNUkveGoyckl3UldlWmsxZjNYYVR5NVkwVnpt?=
 =?utf-8?B?UVpaSk1paG1qckRwWUZ5d3ZpNmhrbm5XaUUwQ3FYaVFTZ1l4YTQvWFJYN1Ba?=
 =?utf-8?B?bk5PQ1FsNytCdXA5Sk9seFpCbHJ0cUlEbUVFTUNGVmRmZXJnWVpualVxcW5F?=
 =?utf-8?B?TWQ3ODZubUVYQzFWWUdzdHg1TjJwWjMvVnBNNXRsKzFkZ3BrdGc3U2RPOEtN?=
 =?utf-8?B?VG8zQnV0bzVaeHhVdEo4MjMrZ3FtcWFQZTQwK1YzYUdGWGVTQlVqbUVHNG5u?=
 =?utf-8?B?RHRWeUxYUjdlR1VEZDAwdUNtUWFxWHorWS9kYitYZk45NnRwTEZZQ2ZDb1Vl?=
 =?utf-8?B?T29CQWs2QkNiZ3BsWDZGcU51NHh1elJ6N25ucGdEeTRZenZwQVcrdVZxOFM3?=
 =?utf-8?B?T01TNndPeVVIMVFVWHp1YmR2WU9xMEJ5N1FzSXpIaW5IQUNHa2drMmVkZnh0?=
 =?utf-8?B?bTBqT0YyNmh4SjhxanQyUWd1RUFUZzBQbmFhbVJELzI5SlFub0NXbTNJdjEv?=
 =?utf-8?B?QnA0dXhaOHAwRnNpM0tyRzZjczM0TVoyRnhZb3RJZ1d0MmJoemVHV240WC9P?=
 =?utf-8?B?eFkrcFExZE9DY05MMG9wcktFenZpWTQ3T05kQkZuUFF1L3NMNmtQb3BDOW5Z?=
 =?utf-8?B?TGh2YkNINDFWUHBER090SEptWTZGYnhkODhzL3FuN3RSWGNyaFREWWRvSVpz?=
 =?utf-8?B?ZW5XSDRPczZCaDNZZHpLQUFvUnl0TDI0eVdONEE2ZGQxb2FreC82QmJLN2o2?=
 =?utf-8?B?Q2JJbVRLdG8xd3orNmx4VU9PTDY0TWZLNEFNeUR3dU1mbDNKUmQwZjRGdnFh?=
 =?utf-8?B?NmxQV3hoM2pXTVMxcUJKVTdXVWlUUlpBSGU3cnpmQzY3aXpEaWN5dkg3c1RS?=
 =?utf-8?Q?fThI=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: 434091b9-46cf-431d-b539-08dda97ecd98
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2025 07:00:23.6580
 (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: JtRzNtZshk6+7a5znbuVKf0ZAH2r/AkE4lxFww30U5jwbqzMRR+65JB4QlJIN4MxAUMEIr7QLz6kO3r6c61iAw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB7739

W1B1YmxpY10NCg0KSGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog
SmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KPiBTZW50OiBUdWVzZGF5LCBKdW5lIDEw
LCAyMDI1IDk6NDEgUE0NCj4gVG86IFBlbm55LCBaaGVuZyA8cGVubnkuemhlbmdAYW1kLmNvbT4N
Cj4gQ2M6IEh1YW5nLCBSYXkgPFJheS5IdWFuZ0BhbWQuY29tPjsgQW5kcmV3IENvb3Blcg0KPiA8
YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT47IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBj
aXRyaXguY29tPjsNCj4gQW50aG9ueSBQRVJBUkQgPGFudGhvbnkucGVyYXJkQHZhdGVzLnRlY2g+
OyBPcnplbCwgTWljaGFsDQo+IDxNaWNoYWwuT3J6ZWxAYW1kLmNvbT47IEp1bGllbiBHcmFsbCA8
anVsaWVuQHhlbi5vcmc+OyBTdGVmYW5vIFN0YWJlbGxpbmkNCj4gPHNzdGFiZWxsaW5pQGtlcm5l
bC5vcmc+OyB4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcNCj4gU3ViamVjdDogUmU6IFtQ
QVRDSCB2NCAxMS8yMF0geGVuL3Btc3RhdDogaW50cm9kdWNlIENPTkZJR19QTV9PUA0KPg0KPiBP
biAyOC4wNS4yMDI1IDExOjE2LCBQZW5ueSBaaGVuZyB3cm90ZToNCj4gPiAtLS0gYS94ZW4vY29t
bW9uL0tjb25maWcNCj4gPiArKysgYi94ZW4vY29tbW9uL0tjb25maWcNCj4gPiBAQCAtNTkxLDQg
KzU5MSwxMSBAQCBjb25maWcgU1lTQ1RMDQo+ID4gICAgICAgdG8gcmVkdWNlIFhlbiBmb290cHJp
bnQuDQo+ID4gIGVuZG1lbnUNCj4gPg0KPiA+ICtjb25maWcgUE1fT1ANCj4gPiArICAgYm9vbCAi
RW5hYmxlIFBlcmZvcm1hbmNlIE1hbmFnZW1lbnQgT3BlcmF0aW9uIg0KPiA+ICsgICBkZXBlbmRz
IG9uIEFDUEkgJiYgSEFTX0NQVUZSRVEgJiYgU1lTQ1RMDQo+ID4gKyAgIGRlZmF1bHQgeQ0KPiA+
ICsgICBoZWxwDQo+ID4gKyAgICAgVGhpcyBvcHRpb24gc2hhbGwgZW5hYmxlIHVzZXJzcGFjZSBw
ZXJmb3JtYW5jZSBtYW5hZ2VtZW50IGNvbnRyb2wNCj4gPiArICAgICB0byBkbyBwb3dlci9wZXJm
b3JtYW5jZSBhbmFseXppbmcgYW5kIHR1bmluZy4NCj4gPiAgZW5kbWVudQ0KPg0KPiBXaHkgaXMg
dGhpcyBiZWluZyBhZGRlZCBvdXRzaWRlIG9mIHRoZSAiU3VwcG9ydGVkIGh5cGVyY2FsbCBpbnRl
cmZhY2VzIg0KPiBtZW51PyAoTm8gbWF0dGVyIHdoZXJlIGl0J3MgYWRkZWQsIHBsZWFzZSBtYWtl
IHN1cmUgdGhlcmUncyBhIHNlcGFyYXRpbmcgYmxhbmsNCj4gbGluZSBhaGRlYWQgb2YgdGhlIHN1
YnNlcXVlbnQgImVuZG1lbnUiLikNCg0KQmVjYXVzZSwgSSBpbnRlbmRlZCB0byBoYXZlIHRoZSBv
bmx5IGZpdmUgY2F0b2dvcnkgdW5kZXIgIlN1cHBvcnRlZCBoeXBlcmNhbGwgaW50ZXJmYWNlcyI6
DQogICAgICAgIC0gc3lzY3RsDQogICAgICAgIC0gZG9tY3RsDQogICAgICAgIC0gaHZtDQogICAg
ICAgIC0gcGh5c2Rldg0KICAgICAgICAtIHBsYXRmb3JtDQpXaGljaCB3aWxsIGJlIGludHJvZHVj
ZWQgaW4gYSBwYXRjaCBzZXJpZSBhbmQgbWF5IGNvbnRhaW4gbXVsdGlwbGUgZGlmZmVyZW50IGZl
YXR1cmVzLg0KUE1fT1AgaXMgbW9yZSBvciBsZXNzIGEgZmVhdHVyZSB0byBtZS4gQW5kIGl0IGlz
IG9ubHkgZGVwZW5kZW50IG9uIFNZU0NUTCwgbGlrZSBMSVZFUEFUQ0gsIGV0Yw0KDQo+DQo+IEph
bg0K


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 07:01:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 07:01:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012393.1390827 (Exim 4.92)
	(envelope-from )
	id 1uPbwY-00060X-Sk; Thu, 12 Jun 2025 07:01:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012393.1390827; Thu, 12 Jun 2025 07: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 1uPbwY-00060Q-Nm; Thu, 12 Jun 2025 07:01:46 +0000
Received: by outflank-mailman (input) for mailman id 1012393;
 Thu, 12 Jun 2025 07:01: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 1uPbwX-0005RB-5m
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 07:01:45 +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 18b2a918-475b-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 09:01:43 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3a503d9ef59so546638f8f.3
 for ; Thu, 12 Jun 2025 00:01:43 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2364e71a2c7sm6881165ad.238.2025.06.12.00.01.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 00:01:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 18b2a918-475b-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749711702; x=1750316502; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=3SzzgRwG19cOL5AnREHIrYN7mthTv93pvaXrzSKkzXU=;
        b=dQxSQqyCvJCO2asnaRrSKbpnZuPrqqv2WPWbr4BwWoRwI2bZKoWQOjowbRDpkL54dh
         ju5ick5DRd3wJqJo+Jb4Y07qTPHTe5XDpJPSMVuZ0p4qPVeMTtU1QTk15cGhX4SG/7FO
         F9d83ubF++Kw55XKgMXoNk3AYpg2evP6ArR8gUbOZvWi0AnIeWh6ZM5ahieayCd6rKM7
         Kc/pS2BrqOUtJkA0tnpLVfwXMBa17HHKLnarB3xxVMiK/UvFNSUGRlU5UYvH2YiapzRJ
         nod2Y4SJPx/bSucACCUcSxGhxuPdM8VVyLC4TwIO0ipEMPaSSfvDSJjw9rAEgee3JWAc
         7ktA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749711702; x=1750316502;
        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=3SzzgRwG19cOL5AnREHIrYN7mthTv93pvaXrzSKkzXU=;
        b=qaRQNQp8n0kspqtTihGg2mjxvOfTLwZke5Aqx/xA97Cs2fvc3XQjUkzG2knfmoZwAm
         nJ5NfGiNlW1kasPUZ1Z+xmazfHx/RMsYqJN3s/USK7ZuXoEDWn/eFbm9LwMzcA2ichjA
         5ZWwCWTOIyxJ5g3lERy0pMbkBn1dBwkFO9/ugawk+LiHwnqHTZEfD4RcQd60B7T5fljd
         nBydXaVBK8YD4EIgF6KRsg5YOR4fJ08Q52bbsyTmzL1teyrDkAXzx0knQoN58TatkI3F
         LcXpR0Qxy/nhwxbDVp2X0Ik9evRC7vqDEpLhEBvIBdO0vbMMqMLODhmEw9iowjPGwKEn
         Mv8A==
X-Forwarded-Encrypted: i=1; AJvYcCUYdyjTxWPK5HeehTx/XD+hUe5THgNIPT6niJUybITH8IpMLTPlsSvD5DHFgW2rISCc4T/tBr8aCqw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxMzvxw4mTnGdu/uxEWCrQi7UiAowy6e+0iD9tn4EjLKvw6Xnn6
	+muZU2h/GAymmHMu4EO2t5HDJjXYeEH5JPOkfCw+PJ0HjqfLtD5JGktorFu4G7yt6Q==
X-Gm-Gg: ASbGncs7qUVFGDV0C8ho4WKaQeklf3G9DOhMOXHyg+OYcdU9Fs3PDrAXB5GFmQGma7G
	CLiFlnUXB823zcjuJQCydCANN27f0+G2Dyp10tnHCC3mTFCJkDvPM4vr8QLWL3H86X/HS3iCNA0
	NUgJZQS58kiUg/ULgfXH7A5LDJtfnilGY4mcbqh6jXeoILrCRtpaB0m04kWPa+/s2aMM9lFl5GK
	D2EZ7Imv7cwFf7PW4670maTzZwbjXLKqtesr6FmD8Ch0/F0Hl3SfPO+6O8tmc52KIiZxHhBkynu
	7nMuXzkfnTCllF24Ss3/AjSbZ81hi+JkMTMun9I39xWiPq1hE1A4g4VfLrIvGqIXFCpTEorsYrV
	4+U4syDwLXNYgWjPzqWzm1iMYB1rblAbqEtWlU8NORY37EnA=
X-Google-Smtp-Source: AGHT+IFe3iP75njw67ihFIhTDnUtvlZTuG/xmJQXBANevKtMkHsaqli3IV6JYTVzxHGmD/Lj/HGlFg==
X-Received: by 2002:a05:6000:2889:b0:3a5:2670:e220 with SMTP id ffacd0b85a97d-3a5612db2a2mr1208226f8f.32.1749711701967;
        Thu, 12 Jun 2025 00:01:41 -0700 (PDT)
Message-ID: 
Date: Thu, 12 Jun 2025 09:01:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 03/20] xen/x86: remove "depends on !PV_SHIM_EXCLUSIVE"
To: "Penny, Zheng" 
Cc: "Huang, Ray" ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 "Orzel, Michal" , Julien Grall ,
 Stefano Stabellini ,
 "xen-devel@lists.xenproject.org" 
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
 <20250528091708.390767-4-Penny.Zheng@amd.com>
 <1a73c720-012a-4795-9f47-f9c23b643de1@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 12.06.2025 06:09, Penny, Zheng wrote:
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Tuesday, June 10, 2025 9:01 PM
>>
>> On 28.05.2025 11:16, Penny Zheng wrote:
>>> Remove all "depends on !PV_SHIM_EXCLUSIVE" (also the functionally
>>> equivalent "if !...") in Kconfig file, since negative dependancy will
>>> badly affect allyesconfig. To make sure unchanging produced config
>>> file based on "pvshim_defconfig", we shall explicitly state according
>>> Kconfig is not set
>>>
>>> Add "default y" for SHADOW_PAGING and TBOOT, otherwise we will have
>>> unset values when running make defconfig based on "x86_64_defconfig".
>>
>> I fear I don't understand this, perhaps related to me also not seeing how ...
> 
> If we just removed "default !PV_SHIM_EXCLUSIVE", .config file generated by "make defconfig"
> will change, having unsetting values for SHADOW_PAGING (# CONFIG_SHADOW_PAGING is not set)
> If changing it to "default y" is too casual, maybe we shall add "CONFIG_ SHADOW_PAGING=y" in x86_64_defconfig,
> to at least retain consistent .config file.
> My fault, Only considering "SHADOW_PAGING" is enough, as TBOOT depends on UNSUPPORTED firstly
> 
>>> --- a/xen/arch/x86/Kconfig
>>> +++ b/xen/arch/x86/Kconfig
>>> @@ -143,7 +143,7 @@ config XEN_IBT
>>>
>>>  config SHADOW_PAGING
>>>     bool "Shadow Paging"
>>> -   default !PV_SHIM_EXCLUSIVE
>>> +   default y
>>>     depends on PV || HVM
>>>     help
>>>
>>> @@ -175,7 +175,7 @@ config BIGMEM
>>>  config TBOOT
>>>     bool "Xen tboot support (UNSUPPORTED)"
>>>     depends on INTEL && UNSUPPORTED
>>> -   default !PV_SHIM_EXCLUSIVE
>>> +   default y
>>>     select CRYPTO
>>>     help
>>>       Allows support for Trusted Boot using the Intel(R) Trusted
>>> Execution
>>
>> ... these two fit with title and description. The justification for removing
>> the !PV_SHIM_EXCLUSIVE here is not "breaks allyesconfig".
> 
> Hmmm, it is the consequence of "removing the !PV_SHIM_EXCLUSIVE"
> Maybe I shall add more explanation in commit message?

Just to clarify - my questions here were about the changes altogether, i.e.:
Why are these two change - as a whole - needed, given the subject? And just
to try to avoid any misunderstanding: My point is that "depends on ..." and
"default ..." are different things, when the commit message discusses only
the former. So yes, extending the commit message may be one way to address
my remarks. But really I think changes to defaults (if needed at all) would
better be separate from changes to "depends on ...".

>>> --- a/xen/arch/x86/configs/pvshim_defconfig
>>> +++ b/xen/arch/x86/configs/pvshim_defconfig
>>> @@ -26,3 +26,8 @@ CONFIG_EXPERT=y
>>>  # CONFIG_INTEL_IOMMU is not set
>>>  # CONFIG_DEBUG is not set
>>>  # CONFIG_GDBSX is not set
>>> +# CONFIG_SHADOW_PAGING is not set
>>> +# CONFIG_TBOOT is not set
>>> +# HYPERV_HYPERV_GUEST is not set
>>
>> This one doesn't look right, simply by its name.
>>
>>> +# CONFIG_HVM is not set
>>> +# CONFIG_VGA is not set
>>
>> Just to mention it - I'm unsure whether adding such at the end isn't going to cause
>> issues. But maybe I'm paranoid ...
>>
> 
> It could be too casual..
> I will only leave VGA here, as we're sure that with removing "!PV_SHIM_EXCLUSIVE",
> CONFIG_VGA is setting as y in pvshim_defconfig

I don't follow: Why would a shim need VGA support compiled in?

>>> --- a/xen/drivers/video/Kconfig
>>> +++ b/xen/drivers/video/Kconfig
>>> @@ -3,10 +3,10 @@ config VIDEO
>>>     bool
>>>
>>>  config VGA
>>> -   bool "VGA support" if !PV_SHIM_EXCLUSIVE
>>> +   bool "VGA support"
>>>     select VIDEO
>>>     depends on X86
>>> -   default y if !PV_SHIM_EXCLUSIVE
>>> +   default y
>>>     help
>>>       Enable VGA output for the Xen hypervisor.
>>
>> Like above, this change also doesn't really fit with title and description.
> 
> I have added " (also the functionally equivalent "if !...") " in commit message to also
> cover above change

Well. There are multiple uses of "if ...". The one matching "depends on ..." is
covered in the description, yes. But the two uses here don't fall in this same
group. One is a prompt visibility change, and the other is a change to yet
another default. See above for my recommendation (to split things properly).

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 07:13:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 07:13:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012408.1390836 (Exim 4.92)
	(envelope-from )
	id 1uPc87-0007sH-PJ; Thu, 12 Jun 2025 07:13:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012408.1390836; Thu, 12 Jun 2025 07:13: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 1uPc87-0007sA-MY; Thu, 12 Jun 2025 07:13:43 +0000
Received: by outflank-mailman (input) for mailman id 1012408;
 Thu, 12 Jun 2025 07:13: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 1uPc86-0007s4-5u
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 07:13:42 +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 c40f6990-475c-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 09:13:40 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-450ce3a2dd5so4981095e9.3
 for ; Thu, 12 Jun 2025 00:13:40 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2364e6d9badsm7131205ad.93.2025.06.12.00.13.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 00:13:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c40f6990-475c-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749712419; x=1750317219; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=SThEqv3QD+IFOrdp1AvLe2umZa8d7tLuCqdV+qefQDE=;
        b=CiVUk+ONPXTEXvXcgIzpir4g0rGtflUb1L5RZGM2owfkNAsvho3i5Fe4JT2MXNs2xo
         jKKs7mQyrHwxsXBBnav3MUuMLT0MqvZUyoAGsyjIy4YKLx0ZGZ8JC4nYZYXQ/Cl8C+tI
         /GwA8fhTYEP4wY/R0jheLsXHYVZjdFR26S3Z4k1mBnVN1iV7X6qnsnDsLLWg1csW+IfW
         PXj5unvmIReJtJBdvqNRz/TdsRY6PxZaMe+sjfyeojksx6O5Y1cNJgGJBK0oyCJLObOV
         0g3QW3mBJcaWS8UKpPr0ImFeWIT21rXC62qf7bCpZsPPv8HunS4SGojs25hGGgoB09uP
         FYFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749712419; x=1750317219;
        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=SThEqv3QD+IFOrdp1AvLe2umZa8d7tLuCqdV+qefQDE=;
        b=bo3kYHB7TrVnzC5FlAZWgMJoIF8YXkp6A92NaSfJMemAzXDAAcaoyUKm+km/J+1BP3
         wP0pCXuY27lLCySNcIff9UbyAb7pIqgW/VdF1Wh1OApemCHqRlGWroyB7ZOu+TMRZVRy
         X2f1ppDFt22S1Lq0G1XyWKJDcxwTw9k1Mhv6Rim2jOyLwsdWmf//QrCIUM+6biSJRuzL
         /zqdkBUMNHWx+ffguGR/eBwce8DelW4ICW/8lG1hbXFGl5PPSuAhFu3fdtVc7+uJQOHZ
         hyAfjgoSI9Vtvqkxl3FaUNnRuRY7V61AMr+2eV7hrjlb7Iu7lbN7nHZ3hZWvJB4QhqTt
         agew==
X-Forwarded-Encrypted: i=1; AJvYcCUvIQAmVBKpUOWx9cCviv2g/wxw2A0GjQIppvbIb6Xy7iRwsP0y9UTrE0oo7TrPymp1LRz1KeAu/k4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxAR7L2GC+77xJ50k/5eZ4MHtw84gvX9pKBiqPNzHegpNZNLHcx
	QGi/GoWr8FVs7Ar9MsRmva5RwwcBKOQV9E241O1uqkmD+J5BEGI1fAcVsJjgcVbeHQ==
X-Gm-Gg: ASbGncuA/Bm6gYXREIW89/8p96dazQfL1NcxrkJAxoTpoXpwxn/ViTMjDX1gkVKM1qN
	sJAIbunhwAFuIM15aK+8fE18G46G+QgbSDPY2k7/U9ie8IuzdA92JHQWtl9ISEwNZyT1UFN9T9S
	jsBDtp0aboDlWJuoTcX97R7gpQ2GK1j2DdYNHK9oGb+aaLoZip3TM+o2W3L+bpitm5p0HSr2nJg
	hP3n+k8txyScRUdC05w41U8dk+ibbRh+YLofB7jdhpB2roN26q4XLeV6YOn8TPaz8IYhhgCxZog
	nWQpSpyxbDb/QGxhT+kWRE/YgIC3x3m1zqVElnSt0x4hT8HG7gfUxgmpc+BPU1kspZoknhaOTyg
	x12GvyTeE5o1/2Jx5EUw3LGn8/acs+GWVfQvx11HeGUiX2AQ=
X-Google-Smtp-Source: AGHT+IGBPUs6Gb116GWWXvqzA6d6C9Q0NMUiJIbo5NDUQ+z1VF4jfvWGRs/Zj5Mx/jWe/FJ/tdf8TA==
X-Received: by 2002:a05:6000:25c3:b0:3a4:f2ed:217e with SMTP id ffacd0b85a97d-3a5614c2053mr1366978f8f.42.1749712416378;
        Thu, 12 Jun 2025 00:13:36 -0700 (PDT)
Message-ID: <94442a1e-48e9-4236-b5e4-e192cf2a8261@suse.com>
Date: Thu, 12 Jun 2025 09:13:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 04/20] xen: introduce CONFIG_SYSCTL
To: "Penny, Zheng" 
Cc: "Huang, Ray" ,
 "Stabellini, Stefano" ,
 Andrew Cooper ,
 Anthony PERARD ,
 "Orzel, Michal" , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Sergiy Kibrik ,
 "xen-devel@lists.xenproject.org" 
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
 <20250528091708.390767-5-Penny.Zheng@amd.com>
 <51fde0e2-abca-43c8-9cfa-734219431970@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 12.06.2025 06:35, Penny, Zheng wrote:
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Tuesday, June 10, 2025 9:05 PM
>>
>> On 28.05.2025 11:16, Penny Zheng wrote:
>>> From: Stefano Stabellini 
>>>
>>> We introduce a new Kconfig CONFIG_SYSCTL, which shall only be disabled
>>> on some dom0less systems or PV shim on x86, to reduce Xen footprint.
>>>
>>> Making SYSCTL without prompt is transient and it will be fixed in the
>>> final
>>
>> Nit: s/fixed/adjusted/ ? It's not a bug, after all.
> 
> Understood.

At the risk of being overly blunt - did you really? You use ...

>>> patch. Also, we will also state unsetting SYSCTL in pvshim_defconfig
>>> to explicitly make it unavailable for PV shim in the final patch.
>>
>> Even without the double "also" this reads odd. But it's also unclear what it has to do
>> here, nor whether what is being said is actually correct.
> 
> Hmmm, How about  "
> The consequences of introducing "CONFIG_SYSCTL=y" in .config file generated from pvshim_defconfig
> is transient and will be also fixed in the final."

... "fixed" again right away, in the same misleading way. Apart from
this - yes, this wording is quite a bit better.

>>> --- a/xen/common/Kconfig
>>> +++ b/xen/common/Kconfig
>>> @@ -579,4 +579,15 @@ config BUDDY_ALLOCATOR_SIZE
>>>       Amount of memory reserved for the buddy allocator to serve Xen heap,
>>>       working alongside the colored one.
>>>
>>> +menu "Supported hypercall interfaces"
>>> +   visible if EXPERT
>>> +
>>> +config SYSCTL
>>> +   bool "Enable sysctl hypercall"
>>> +   def_bool y
>>
>> Why def_bool when you already have bool on the earlier line?
>>
> 
> Ack, then here maybe a simple
> "
> config SYSCTL
>         def_bool y
> "
>  is enough.

Indeed; see my later reply on this same topic.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 07:22:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 07:22:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012418.1390846 (Exim 4.92)
	(envelope-from )
	id 1uPcGX-0001FQ-N5; Thu, 12 Jun 2025 07:22:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012418.1390846; Thu, 12 Jun 2025 07: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 1uPcGX-0001FJ-KH; Thu, 12 Jun 2025 07:22:25 +0000
Received: by outflank-mailman (input) for mailman id 1012418;
 Thu, 12 Jun 2025 07:22: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 1uPcGX-0001FD-1V
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 07:22: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 fbc549f7-475d-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 09:22:23 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3a361b8a664so556132f8f.3
 for ; Thu, 12 Jun 2025 00:22:23 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-7488089624asm780018b3a.62.2025.06.12.00.22.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 00:22:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fbc549f7-475d-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749712942; x=1750317742; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=GT0tJ9tHfDEsYoVJraQMtWrpW/Am4c/YStdv2WWbkoA=;
        b=F5HOBu5JuiQ3gmagSAFM1mPjFLR0sWFKrJnUByxA9cltTyB9MoGIOwMHROTrUQrvFV
         /DZ9gRxamuNyzk8N+nWXhkVasHNbroQyOxHuk1JYxegbfH5K3zCNb4/Gr/3DHPjrjiur
         WvjgtwYx/vD3VjrU5cVZWD74evqtlCQMuMiXSVzn8pWOPYAXBrVwbsFV9IiUTjWjY51i
         r00u6Kma5zI0s1tfQ8eT+nDUv17KOnPzm1Hay+rFYoIMCuFTmSY9Qu3tWZ8SKvqOsZWK
         hElB10X1WJWiUWQsq+ra5pAWQaqTq0pqkCoGw76BiB1DyMVutLyq6iGetddDJckrv3RG
         aQxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749712942; x=1750317742;
        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=GT0tJ9tHfDEsYoVJraQMtWrpW/Am4c/YStdv2WWbkoA=;
        b=bE8p+mMbPAeTnhSzM+RZK+qW+bN9OmuhhfEdeHA5uksoXpuJQk+5ZWRRqVnycRdPiO
         9Sn3UVDltpT0/rGGuxl7lGqgqUbp2LHSdGZX68EkGmcvIbINMHeu6y2PiBX3AK6lIfYk
         G6obNnX9g8Nk5soHXY/XB7+D1V6Hqypy6IQ9R7u8hiy80dWiuxVF5x88zlN9XGbkT6o0
         5V8ZRrA/GxrTkc9RYmr0eeyLrR5cIpw25YX/q1gSk0lwg4cS+tkmY/laNPhE/3Aa8VPA
         CWMq9w8oa8RFDWvhD1RTWCbw3HONvmZAdJExohGBk0vX0sGFmh5ZtP5LNdqKSWBEKgk8
         D0mg==
X-Forwarded-Encrypted: i=1; AJvYcCUnx19qD1OPUN5Ti1vpmCgBbz83sqaff5cd85cCVOUuzPzshXzLqTFsk2IbzaP7U52dWGFAJ17mDgs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzoBeF3poznwX5V7gPX6lzVKoli/AuYPwZgN2RDQ2pZqFB99lDM
	gLGbZummXW9yXaCU6+tGvjEeTeEg/w6pUlLOP6+9Dy1gdIajwuHfjoPK03Lh84AelQ==
X-Gm-Gg: ASbGncv7mNPQRoKUn8JuM8aPDw38GpY8vkb9HPsPWsK7coUhUEWYFQhb55eBnEkNEn2
	PBIvM8o94RyuKyfHhSk9qtCcW8zFAk+nOGeHBi2nAn2l8uRSBhmMgxMeZzuzfNkdV+2ewQmpoLm
	9aE1AtCnr3eaSHagadvHmKvGeu6BnpSmBZB97U/NPRxEl580cxtf27I1seRyCe1azOG1SbB5Jyf
	t3tu0w/37f8u3x6hQdMdhKYH5oFE/v/lNQKnIRGnZPb5iIKTX3X/Efc/FTzU1v6s4s7pqt0vBHl
	J54kHWHUi7muqxwl2MG+XMGzZfND47SVXE98jUHmfs61JMOuxj4PspsARiQBQFrqll1JBZmTmA/
	PFX5wun4rC8APW0p0Nnk2EIGsKe3NpYGIlacG5DwfLdLt1vw=
X-Google-Smtp-Source: AGHT+IE7Mk5fsAkeCPyTzi1ufdf3GtX1vMNMd8kG6cpcnfbR9ghLJ/5wMnc5zV/Jmf0Q+Mjq3wlE9Q==
X-Received: by 2002:a5d:588a:0:b0:3a4:ffec:ee8e with SMTP id ffacd0b85a97d-3a558a2766emr5251389f8f.36.1749712942363;
        Thu, 12 Jun 2025 00:22:22 -0700 (PDT)
Message-ID: 
Date: Thu, 12 Jun 2025 09:22:12 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 11/20] xen/pmstat: introduce CONFIG_PM_OP
To: "Penny, Zheng" 
Cc: "Huang, Ray" ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 "Orzel, Michal" , Julien Grall ,
 Stefano Stabellini ,
 "xen-devel@lists.xenproject.org" 
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
 <20250528091708.390767-12-Penny.Zheng@amd.com>
 <1a660f83-5d9a-402b-af28-ea82311b37ce@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.06.2025 09:00, Penny, Zheng wrote:
> [Public]
> 
> Hi,
> 
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Tuesday, June 10, 2025 9:41 PM
>> To: Penny, Zheng 
>> Cc: Huang, Ray ; Andrew Cooper
>> ; Roger Pau Monné ;
>> Anthony PERARD ; Orzel, Michal
>> ; Julien Grall ; Stefano Stabellini
>> ; xen-devel@lists.xenproject.org
>> Subject: Re: [PATCH v4 11/20] xen/pmstat: introduce CONFIG_PM_OP
>>
>> On 28.05.2025 11:16, Penny Zheng wrote:
>>> --- a/xen/common/Kconfig
>>> +++ b/xen/common/Kconfig
>>> @@ -591,4 +591,11 @@ config SYSCTL
>>>       to reduce Xen footprint.
>>>  endmenu
>>>
>>> +config PM_OP
>>> +   bool "Enable Performance Management Operation"
>>> +   depends on ACPI && HAS_CPUFREQ && SYSCTL
>>> +   default y
>>> +   help
>>> +     This option shall enable userspace performance management control
>>> +     to do power/performance analyzing and tuning.
>>>  endmenu
>>
>> Why is this being added outside of the "Supported hypercall interfaces"
>> menu? (No matter where it's added, please make sure there's a separating blank
>> line ahdead of the subsequent "endmenu".)
> 
> Because, I intended to have the only five catogory under "Supported hypercall interfaces":
>         - sysctl
>         - domctl
>         - hvm
>         - physdev
>         - platform
> Which will be introduced in a patch serie and may contain multiple different features.
> PM_OP is more or less a feature to me. And it is only dependent on SYSCTL, like LIVEPATCH, etc

Hmm, well, okay. Especially your reference to LIVEPATCH here suggests to me that
some re-ordering would then be quite desirable in the file. It is generally
pretty desirable for "depends on " to appear later than "". While
for the graphical UI interfaces of kconfig the difference may be marginal, for
the command line one you otherwise get to select the setting for the dependent
feature first, just for that setting potentially being undone by the later
selection for .

Then again the entire file could do with some rearrangements. Yet I guess to
avoid interfering with your work, I'd better postpone any tidying work there.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 07:26:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 07:26:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012424.1390856 (Exim 4.92)
	(envelope-from )
	id 1uPcKV-0001r2-7m; Thu, 12 Jun 2025 07:26:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012424.1390856; Thu, 12 Jun 2025 07:26: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 1uPcKV-0001qv-4l; Thu, 12 Jun 2025 07:26:31 +0000
Received: by outflank-mailman (input) for mailman id 1012424;
 Thu, 12 Jun 2025 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 1uPcKU-0001qp-B8
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 07:26:30 +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 8dbe0ae8-475e-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 09:26:28 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-43ea40a6e98so6804825e9.1
 for ; Thu, 12 Jun 2025 00:26:28 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-4532e25fd3asm11175935e9.36.2025.06.12.00.26.26
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Jun 2025 00:26:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8dbe0ae8-475e-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749713187; x=1750317987; 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=vBtTCutt4E4HmflxkY6wA3WXJFyxhZ3IS3pg2CYsXnY=;
        b=W8LDgLDy4EIXQpjCHEnIajWKq4yPW6AhdYVuOGOyAKWwsryl6N4nlC2Ro3unnC1ejS
         tdvkmIw5M4oa2XAbqVXy5wtPX1DB+vkQHvE4XCmWhj7WcvDcNx3LXSP8d4ah5w/xJ+sU
         BDfnxd1PSeArrHvPPyov/RsURg5/5GJzpTwOM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749713187; x=1750317987;
        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=vBtTCutt4E4HmflxkY6wA3WXJFyxhZ3IS3pg2CYsXnY=;
        b=cEEvz5HzP7ZoIV60WiuhtfHm2f6opuv2UZnmMFIJqXDqHi/iPEY8ggoi5CSsoPncCu
         51DHrLDn5j7CmTLk4xNt1bnepvnuLsuZYYGKoaGlwa4NekwDpd8zQPivrZvNa7QmdWd7
         sL3wjGHKOKToqs9yE2E6h1DuwsJWwwICk5RUUs9IjiC8lLFGPqBn3XxBS1RgEmqky8Kb
         Htb3P53/LZe42368Yq2gNO63MJly55b6LWmxU10aP5ZEVzPHhh7J5D0q56aCyYr5Bc8A
         jSt0GnHjMi1TR1JojhTqq35Uls2ElaUic5yobOZnknEa8jsW/aRYCepACr/wOpd2RdkU
         yc/Q==
X-Gm-Message-State: AOJu0YznN3f6Tdj2NKuh4Hllub3KDrjTOhoXFghm8TIRYV+I4MC99tx3
	6Uxp7M6Qfo8R251s2ucBookYLNCcr8JZsflvbl8a0qTdZfYY7GNB0rCORswKFAzI2FA=
X-Gm-Gg: ASbGncutO76FT1wsf27YfwPza1upzpHUlX4mCAoi4fyzf/tDGOHS48xl4tcvWzZeMLm
	cAZQwJSIyEeKtHM/Zv/TSqPgbsQOlHag2X1m/3RmjGdZf0SHLazYlPA3pq3B8/qB6vFr9Nb9iI1
	ixRPMibbKvUwVCbJWyuRgZ/5uCe3Ix1Y1F0aRjbyZHWET+97MWN5Y0/tyCcUToWous0JIlkGEWp
	OFa25SXdasjUnMjDdx8ncJB3NrLqMSn2aws4t5SAlFPG5rAkQnH/arxIADk5RhvoALgL9mQkCfI
	ti/R1OtqOdhH90kHWGwDaimHiBrVX9x5pvBE8ACZGDwP7CVpJ4vvgA2QH2wqT788WSg+AgMwHTM
	O266ty6qa1cNxrke4vyXtFpqcwTWcQg==
X-Google-Smtp-Source: AGHT+IHYl8ZOvFgzF2jO+mlLuhxGAgDDORvc6Oxw6qhJjKXdSzu9rGi7CKAwicbANSRXI5vkHXDf5g==
X-Received: by 2002:a05:600c:3b1a:b0:450:d012:df7a with SMTP id 5b1f17b1804b1-453248cfda0mr51048425e9.28.1749713187233;
        Thu, 12 Jun 2025 00:26:27 -0700 (PDT)
Date: Thu, 12 Jun 2025 09:26:25 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Andrew Cooper 
Cc: xen-devel@lists.xenproject.org,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini ,
	Bertrand Marquis ,
	Volodymyr Babchuk 
Subject: Re: [PATCH 6/8] pdx: introduce a new compression algorithm based on
 offsets between regions
Message-ID: 
References: <20250611171636.5674-1-roger.pau@citrix.com>
 <20250611171636.5674-7-roger.pau@citrix.com>
 <8e34ac22-d05b-4ef3-9e31-6e5663cc1dc5@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <8e34ac22-d05b-4ef3-9e31-6e5663cc1dc5@citrix.com>

On Wed, Jun 11, 2025 at 08:33:55PM +0100, Andrew Cooper wrote:
> On 11/06/2025 6:16 pm, Roger Pau Monne wrote:
> > With the appearance of Intel Sierra Forest and Granite Rapids it's not
> 
> s/not/now ?
> 
> The problem here is that it's very possible to get such a system.
> 
> It might be worth nothing that SRF and GNR are socket compatible, in
> Birch Stream platforms, which is relevant to why they're similar in this
> regard.
> 
> > possible to get a production x86 host wit the following memory map:
> >
> > SRAT: Node 0 PXM 0 [0000000000000000, 000000007fffffff]
> > SRAT: Node 0 PXM 0 [0000000100000000, 000000407fffffff]
> > SRAT: Node 1 PXM 1 [0000061e80000000, 0000065e7fffffff]
> > SRAT: Node 2 PXM 2 [00000c3e80000000, 00000c7e7fffffff]
> > SRAT: Node 3 PXM 3 [0000125e80000000, 0000129e7fffffff]
> >
> > This is from a four socket system, with each node having 256GB of memory.
> > The total amount of RAM on the system is 1TB, but without enabling
> > CONFIG_BIGMEM the last range is not accessible, as it's above the 16TB
> > boundary covered by the frame table.
> >
> > Note that while the memory map is very sparse, it won't be compressible
> > using the current algorithm that relies on all ranges having a shared
> > zeroed region of bits that can be removed.
> 
> ", it couldn't be compressed using the current PDX_MASK compression
> algorithm, which relies ..."
> 
> 
> >
> > The memory map presented above has the property of all regions being
> > similarly spaced between each other, and all having also a similar size.
> > This allows to compress them using the following formula:
> >
> >  pdx = (pfn % offset) + ((pfn / offset) * size)
> >
> > Where offset and size are two static coefficients calculated at
> > initialization.
> >
> > Obtaining the optimum offset and size coefficients is the complicated part.
> > In this patch I introduce two different algorithms, a fast one that works
> > correctly when the offset and size between ranges is mostly equal.  If such
> > fast algorithm doesn't work, or the resulting compression is not enough to
> > avoid truncation of the maximum usable page, it's possible to attempt a
> > brute force approach for calculating the coefficients.  This is also
> > implemented in this patch as the slow variant.  I've attempted to restrict
> > the number of iterations in the slow approach so it can exit early if no
> > better coefficients can be found due to the input constrains (minimum
> > region size).
> >
> > The patch here focuses on introducing the logic to calculate the
> > compression coefficients, plus adding a unit test to exercise the logic
> > easily from user-space in order to test different layouts and possibly
> > improve the generation of the coefficients.  The added unit tests only
> > covers the newly added compression, but could also be extended to cover the
> > existing PDX mask compression.
> 
> Is it possible to split out the userspace harness into an earlier patch,
> and e.g. do some token testing of PDX_MASK ?

It would need a different testing harness IMO, as the current testing
harness is tied to the offset implementation internals (as it wants to
compare the results of both the fast and slow coefficient
calculations).  I could add a test harness for the mask compression,
but it would be a different file, with slightly different logic, and
hence I don't think it would reduce much the size of this patch.

> That halves the size of this patch.
> 
> >
> > Note the translation functions (pfn to pdx, maddr to direct map offset),
> > are not implemented as part of this patch, an identity set of macros are
> > added to satisfy the build requirements.  The patch is already long enough
> > without those.
> >
> > Signed-off-by: Roger Pau Monné 
> > ---
> > We can discuss whether we want both the fast and the slow variants.  The
> > slow (brute force) was added as a result of me playing with weird region
> > layouts where the fast one didn't manage to compress, or the resulting
> > coefficients had a poor compression ratio.  However at this point the
> > slow variant has only proven helpful in synthetic cases, I haven't (yet?)
> > seen a real host memory layout that would benefit from it.
> 
> I'm going to hold off on opinions until I've read the rest of the series.
> 
> One question through.  Can we round offset up to the next power of two,
> so we can replace the divide with a shift?

I've tried to round up both offset and size, but that resulted in no
compression in some cases.  I can try to maybe round just one of
those?

Note that the divide is done once with offset and once with size,
depending on the direction of the translation.  I can explore this a
bit.

> size is not a nice power of two, but I guarantee you that hardware is
> not doing this routing with a divide.
> 
> It would result in some holes in PDX space, but it is almost certainly
> faster.

On my TGL NUC the cost of the conversion in pfn_to_pdx() measured in
TSC cycles is:

    N           Min           Max        Median           Avg        Stddev
x 2811            26           271            29     39.224831     33.516395

It's from the user-space harness, so might not be fully accurate.  I
the average time for the operation is ~14ns on my specific system
(2800Mhz nominal frequency).

> > diff --git a/tools/tests/pdx/harness.h b/tools/tests/pdx/harness.h
> > new file mode 100644
> > index 000000000000..3d31cf488daf
> > --- /dev/null
> > +++ b/tools/tests/pdx/harness.h
> > @@ -0,0 +1,73 @@
> > ...
> > +#define sort(elem, nr, size, cmp, swp) {                                \
> > +    /* Consume swp() so compiler doesn't complain it's unused. */       \
> > +    swp(&elem[0], &elem[0], size);                                      \
> 
> (void)swp;   ?

Hm, yes, that might be enough to make the compiler happy about swp()
being unused, I will try it.

> 
> > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> > index 93ebfc29635e..e71908b99c14 100644
> > --- a/xen/arch/arm/setup.c
> > +++ b/xen/arch/arm/setup.c
> > @@ -258,7 +258,7 @@ void __init init_pdx(void)
> >      unsigned int bank;
> >  
> >      for ( bank = 0 ; bank < mem->nr_banks; bank++ )
> > -        pfn_pdx_add_region(mem->bank[bank].start, mem->bank[bank].size);
> > +        pfn_pdx_add_region(mem->bank[bank].start, mem->bank[bank].size, bank);
> >  
> 
> I'd suggest plumbing bank down in a previous patch.
> 
> > diff --git a/xen/common/pdx.c b/xen/common/pdx.c
> > index 7d14100224fe..f2cf60bbc3f8 100644
> > --- a/xen/common/pdx.c
> > +++ b/xen/common/pdx.c
> > @@ -21,6 +21,15 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +
> > +#ifdef __XEN__ /* For building the file in user-space. */
> > +
> > +/*
> > + * Use a define for the static keyword, we want to export some otherwise static
> > + * functions for the unit tests.
> > + */
> > +#define STATIC static
> 
> Most unit testing gets around this problem with the test harness itself
> doing
> 
> #include "path/to/pdx.c"

I see.  I've been kind of doing that with __XEN__, but it might be
clearer to instead use _TEST_HARNESS_, I could avoid the sed with
that.  I need to see how it looks.

My original idea was that the pdx object could be used by the PDX mask
testing also, but given the algorithm is selected at build time we
would need to generate two different object files from pdx.c anyway.

> If you do this right, the only thing needed is some #ifndef
> _TEST_HARNESS around the includes at a the top.
> 
> > +static int __init cf_check cmp_node(const void *a, const void *b)
> > +{
> > +    const struct pfn_range *l = a;
> > +    const struct pfn_range *r = b;
> > +
> > +    if ( l->base > r->base )
> > +        return 1;
> > +    if ( l->base < r->base )
> > +        return -1;
> > +
> > +    ASSERT_UNREACHABLE();
> 
> I'm not sure if this is appropriate.  It's perfectly reachable if both
> ->base's are the same, and it may interfere with the inlining heuristics
> for sort().
> 
> What you mean is "there shouldn't be two nodes that look like this", and
> I'm not sure that the middle of sort() is the place to check this properly.
> 
> AFAICT, The real property you want is "len[i] && base[i] + len[i] <=
> base[i+1]".

I could possibly do the filtering from the sanitize function.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 07:28:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 07:28:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012430.1390865 (Exim 4.92)
	(envelope-from )
	id 1uPcM1-0002NM-Ge; Thu, 12 Jun 2025 07:28:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012430.1390865; Thu, 12 Jun 2025 07: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 1uPcM1-0002NF-Dx; Thu, 12 Jun 2025 07:28:05 +0000
Received: by outflank-mailman (input) for mailman id 1012430;
 Thu, 12 Jun 2025 07: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 1uPcM0-0002N7-E3
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 07:28:04 +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 c6a58592-475e-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 09:28:03 +0200 (CEST)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-3a531fcaa05so344402f8f.3
 for ; Thu, 12 Jun 2025 00:28:03 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b2fd62d19d9sm726367a12.51.2025.06.12.00.27.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 00:28:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c6a58592-475e-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749713283; x=1750318083; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=2sNmT0citRf2K+fYNL2kahnq8yRRwGmnyfVBQeTZBzQ=;
        b=JFsDFoD4O901q4P1QoLcCFzxC3zPMC+c545CIMVplcUfVMHosl5CH3UGd/m5zcTkiu
         /hfOXb12EV8xFW/hED+zv/D5swE/w0xc7e3+CnEe0AyU8vurAVfm3uxrC9DTy23BqInv
         GCFuArUxUVZWbCQJe43CSKwyMC9AxFdM07X8H0bCzxZlUJAwSwQhVpEucbyC08pAe0uQ
         adELkC/Lvr1YKQ6pNd3resSLBrmhxxboZbI5bxiRBytyAKsVaLaGTWTZ7vmTz7VwE8cE
         Y0Y/z6dczXk1T0zF6CHQUEGZRF2afm64gc+b/bWVMOLakpK2DG35xHjJXckQV6mMVAPx
         +FvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749713283; x=1750318083;
        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=2sNmT0citRf2K+fYNL2kahnq8yRRwGmnyfVBQeTZBzQ=;
        b=nb4QXzj0SL7N0RJ+14XXpxZ6hzLJKdVcxlv3AcWOs4LJZhTJjZzsIHzRjL3f1/ZaKk
         EvUwsKMvRn0BhEioAmgWnzpwyLBTKo4pLcl9curQ24jNyCjMPIHIJ7Q3EjbfH5wie0dw
         LTTvKzDbdXGyy5q7j2opiaoLbcviz0EZKKZitY/5JQlCYpezqRP78F25auoMt3Q5BJa1
         qMXht7g0Sthc90euz5rcDgyTMGXG0/qYOhpf9Xxp4xJcaOrpB52hw5NE1qOdU6SRFp2K
         x2ZscIvB6WMUyhymUEICQi1n9fjWvMb9NbAkmfjZPhfIe9PcbNLxTJdZq9iQRopWMqmH
         1ssA==
X-Forwarded-Encrypted: i=1; AJvYcCV4nKopeaVCJpGL1HP2QWrpgGgiu7+dEQ3FSEjKkVy81+vK7ePUxKVaZsnrbI6LOk5DB/klNIL9Il0=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyn4UyDgeCpfaApllsKii0R5cqGPkt0bOVwf2xj5sLJL6xynV0p
	Z8pHZnJm3NizXA89TjWflF18eKrcKBPfErx2dVX2P2RuwXONcA4/wg/C4oWuPaaWiQ==
X-Gm-Gg: ASbGncsKzoM6Sapy7ZhBIWiWZvFFqFAh7gsVKIR4yalOpERDSA8un4pCPE6zBYxFKQt
	yzItKOHf/VRT7xOycsmt5xFPsXoTSmFeZ2qeG23SOK3dao/VVUemEc1l4JLCmUPC9IKUL5O9wEy
	VXem6TgQrSwQeJLZaJLTfa2oov4f0jv/P2IOkk1jl68ra/+06/OJHM5SmP0Pqsd9Av6Hpo/LH+W
	QXXvb3guxDlm8cWiaiyiwrzaUG9Y15WqCFsjLgqj4uh7wPIFyXTrv9JOMnkAHJMqLdRJh7NQ1RI
	naFK/JtwnPUzbTCREGbRwE+myOsxtjCpjyi6KFRW3WgVMuhr79KHVhodcW75YDaTW6AM9Zyloy4
	QGpxQPwfAh7DHnstw9yU7NPFIkQBGnvtzoWhTyTNpKF8roz0=
X-Google-Smtp-Source: AGHT+IHiVz/7mUHIqZjfoiZPk/yWQx9A5o/NnRnW4vwoH7eVnWYk758M0LuGVU5O+uP937981D9vVg==
X-Received: by 2002:a05:6000:2008:b0:3a4:d6ed:8df7 with SMTP id ffacd0b85a97d-3a56076cb79mr1665914f8f.59.1749713282941;
        Thu, 12 Jun 2025 00:28:02 -0700 (PDT)
Message-ID: 
Date: Thu, 12 Jun 2025 09:27:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 5/5] vpci: allow 32-bit BAR writes with memory decoding
 enabled
To: Stewart Hildebrand 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20250531125405.268984-1-stewart.hildebrand@amd.com>
 <20250531125405.268984-6-stewart.hildebrand@amd.com>
 <9ec5079f-9bc1-4843-a266-d74bf0556619@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.06.2025 22:22, Stewart Hildebrand wrote:
> On 6/5/25 06:41, Jan Beulich wrote:
>> On 31.05.2025 14:54, Stewart Hildebrand wrote:
>>> Currently, Xen vPCI refuses BAR writes if the BAR is mapped in p2m. If
>>> firmware initializes a 32-bit BAR to a bad address, Linux may try to
>>> write a new address to the BAR without disabling memory decoding. Since
>>> Xen refuses such writes, the BAR (and thus PCI device) will be
>>> non-functional.
>>
>> Doing this for 32-bit BARs only, with not even an outline what to do about
>> the same issue with 64-bit ones, seems like it won't buy us very much.
> 
> It buys us quite a lot: it means the difference between booting vs.
> booting with degraded functionality or not booting at all with PVH dom0
> on some platforms with certain PCI devices plugged in.
> 
> The plan for 64-bit BARs for now is to continue to refuse the write(s)
> when the 64-bit BAR is mapped to avoid mapping half-updated BARs in p2m.
> 
> I'll add something to this effect to the commit message.

Yes please, in particular ...

> Also see https://gitlab.com/xen-project/xen/-/issues/197

... to make clear that Linux indeed aims at disabling memory decode when
fiddling with 64-bit BARs. That reduces the set of remaining cases quite a
bit.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 07:32:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 07:32:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012436.1390875 (Exim 4.92)
	(envelope-from )
	id 1uPcQV-00047b-2P; Thu, 12 Jun 2025 07:32:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012436.1390875; Thu, 12 Jun 2025 07:32:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPcQU-00047U-VD; Thu, 12 Jun 2025 07:32:42 +0000
Received: by outflank-mailman (input) for mailman id 1012436;
 Thu, 12 Jun 2025 07:32: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 1uPcQT-00047O-QH
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 07:32:41 +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 6af48e3c-475f-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 09:32:39 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-43edecbfb94so6942165e9.1
 for ; Thu, 12 Jun 2025 00:32:39 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-4532e24155bsm11400615e9.17.2025.06.12.00.32.35
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Jun 2025 00:32:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6af48e3c-475f-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749713558; x=1750318358; 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=4gAWW7lVm7WQQuR9+ND31YNRD8GoyHuETasTztULC8s=;
        b=lYIcOB0KHK11ncanm7v7P0Hbofy9CG07tavpsrJ94xOpm7Wex9sOA/tzoNK57iC0HS
         uw77yu9+abOrS2lLHp5kAOtSFruGETHbbBKq4a6pdg9QDdme0MxU73VlaP8Xa1WmXSwj
         QmTYzxyuP9uLWRY/sKeblD/yfDIIq2O15ZfF0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749713558; x=1750318358;
        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=4gAWW7lVm7WQQuR9+ND31YNRD8GoyHuETasTztULC8s=;
        b=j8MK9H9Lgb4JYKVkp5BrXRhZASae+0ARucyIm3Wb+2PUFxkD1dxisVRqRQVaVbcRVd
         EpbrHwNxL2a5yOb7BMvdlHFLyjMijDwGwTlyvd12CVsA7dduTVmm07G0PJEs3lV35Z+s
         9M2iom9DnV8Y61ZUipNbDvhlRX6dZQZ4HrNoZkWrVWAuzhFXpvzZPW//CRDshma6pDo7
         cgS3/Z2hc5vSrnvzZCGNrMT2PxOVm5tfwyOOX0i4GBretU/RhZ0nxkEC47Pb5+VtjfIu
         69xeszfkKk0ViUX7mduXtc3gmi6Cpa7wqCqIbnILQ8TRdQNXwVWkfINJmL/a1ZCZNOPV
         IQYQ==
X-Forwarded-Encrypted: i=1; AJvYcCXP4C8uH4Sb+Ei+CPbx/RZiPJpgLEGPiNfvC1VKhThqYvDZB2DFbl6Wo5ZeK6oIgTzZfnFb3NFNux0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxxA1KKsEzM5WhP8SfJmDS1No/VkeZv9Ib7e1oOdYpBeFGR0ec9
	c31NfXmVJUVHHTIEj3zF2um/cozXiWc5bfVyKc80aV0W2bSe26XR/2/4zBAyoyQ8XHA=
X-Gm-Gg: ASbGnctINOsxV4Z/N4U4koeuP67+FI8nlZoOrhO9gN8X5mSHRFqUyPzzX7jor6QN68c
	uYI5E7Ynh978BC+pTm2psKeFKbeqDI2RNs0Voyi6CZwz5IGmbXXZSPhDVyCrIvgwLZpKZ9TosNB
	QQjKgYF1wkDrUpYUQfd8KstEJb3hB0KWM53wooCv6lZBQrlMaUrOXwD1Gfh9djOzTCcOOGjQAOI
	n38oCjwVLdrjejHcc0ets+6cvNkf7T+bHKG0lTziiWGmklWb8n9B9C4QyzpJ7C0G0jN8YRHTOCd
	3x368vkVZ0Q3+slYihGhN9S0y7kPEY1YZ/90awBZevBcUGPB2zb5PgK5knhgvVCa5bL/iVk62+F
	YDXd2XG6oiGQARssb4nQdMmwsu47C1w==
X-Google-Smtp-Source: AGHT+IGIDmpe/vpgG2F89wY0phShV8ZgXmKnmN499GI0gkWUeVkx7U6geXhTpUnzjdYW8T2K585Uaw==
X-Received: by 2002:a05:600c:138e:b0:442:e147:bea7 with SMTP id 5b1f17b1804b1-4532d368101mr17510785e9.29.1749713555860;
        Thu, 12 Jun 2025 00:32:35 -0700 (PDT)
Date: Thu, 12 Jun 2025 09:32:34 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Stewart Hildebrand ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v1 5/5] vpci: allow 32-bit BAR writes with memory
 decoding enabled
Message-ID: 
References: <20250531125405.268984-1-stewart.hildebrand@amd.com>
 <20250531125405.268984-6-stewart.hildebrand@amd.com>
 <9ec5079f-9bc1-4843-a266-d74bf0556619@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <9ec5079f-9bc1-4843-a266-d74bf0556619@suse.com>

On Thu, Jun 05, 2025 at 12:41:06PM +0200, Jan Beulich wrote:
> On 31.05.2025 14:54, Stewart Hildebrand wrote:
> > Currently, Xen vPCI refuses BAR writes if the BAR is mapped in p2m. If
> > firmware initializes a 32-bit BAR to a bad address, Linux may try to
> > write a new address to the BAR without disabling memory decoding. Since
> > Xen refuses such writes, the BAR (and thus PCI device) will be
> > non-functional.
> 
> Doing this for 32-bit BARs only, with not even an outline what to do about
> the same issue with 64-bit ones, seems like it won't buy us very much.

IIRC Linux will disable decoding in the common case when updating the
position of a 64bit BAR.  However it won't disable decoding for 32bit
BARs.  I think that's why Stewart cares more about the 32bit case than
the 64bit one.

Regards, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 07:37:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 07:37:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012445.1390886 (Exim 4.92)
	(envelope-from )
	id 1uPcUj-0004k9-Le; Thu, 12 Jun 2025 07:37:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012445.1390886; Thu, 12 Jun 2025 07:37:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPcUj-0004k2-In; Thu, 12 Jun 2025 07:37:05 +0000
Received: by outflank-mailman (input) for mailman id 1012445;
 Thu, 12 Jun 2025 07:37: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 1uPcUi-0004jw-IW
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 07:37:04 +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 07c7d0da-4760-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 09:37:02 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3a4ef2c2ef3so584861f8f.2
 for ; Thu, 12 Jun 2025 00:37:02 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2364e6fe4ffsm7522275ad.147.2025.06.12.00.36.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 00:37:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 07c7d0da-4760-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749713822; x=1750318622; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=tKDXjh3y1KHATX2Lze2A5b6PHBxoCfqOzkkQrLCFP0k=;
        b=dRUBm9drLJ4mCjyTuPip/extZzMuwNtChERVoUOPxS9rydpCPIm843BLNvWiGHNqIk
         SHGwNY4smeJnOSxD8KZlThMOT6/QT9lXdyqsq1cZ/eFCymLk5bnlwYJCawms3bC5O+pE
         Im3cH6uAjL1IFl1+ThOPaNXtPQsB+HKOIOaalqqzrJ0B1LDbN7GYhA+BIDVaLNsPwwll
         axX41tv2mltxrWwsKUnuaqXsMtMqT9OoIk8LvLmXpSwx+iLv3u2QOxCvEepfXuE/u7/d
         +cUwfvxBoJeOUqNI/e1R6Pw1n3fLu5BXAKpq3fiEogt5AM3OU1IkdS6RKnPfmuY1iatd
         HdGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749713822; x=1750318622;
        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=tKDXjh3y1KHATX2Lze2A5b6PHBxoCfqOzkkQrLCFP0k=;
        b=ZGs5xRojkVVbrJbjRBihKj8MRsVaaThmmkcoatybJQe9NVHIVdTOxJqr05iliFVhuc
         /xLmMUHDQI2NzLAGIwjS0ttNIYMJ/CVQhnCu+vJpAbRjRE8/3bGt40GWY3hcptCn0QPV
         e+92U3/NlF3JS5Jp9QKsHuZ2SqI5Rl9DRZvxGSSDOMYsYvtPOcmlEq+vndlPPKS+wTTp
         zEpsf13NoIANKtDzqe0JOS0DAU/bRUnMjfLteB0iOqotcwuFSCHQXQYBtmbYORoktDob
         Mx/j2aiGKX/gEfrIwro+ofk1WKZ/Te97JsA94v6dVL4hYHGgk1gLxsEVe1m1H2OoRR3I
         1bAQ==
X-Forwarded-Encrypted: i=1; AJvYcCVABCtL8GR7UTBtdQKCwFgBuGTZE1Vd3veN77rFyWSIl/VfyvfZVp/jBAYHKa69lt2L/efIZHF5JL0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzABSA7e1ZDFX0Bgy3p3h2Tna1I3G1wpKn2bqRKFTTJrdMpppkx
	CCMrt1Pw+wzIfrP5akey+qXKgiFQfk5dh/fTiJ4KJzqfK8dtvApmJhNd2y4JffGF+Q==
X-Gm-Gg: ASbGncvZ91KrvQ9eKAILCilt5+z6Gmnhzm42is5eGvpg1vi8OJdOumsx7VF1NzovQkd
	Ja56T/cHLQPiVGDN4rbNEKjxUcSRygKTMiWz8jBvIAqsGgXPppdbQ9OKLqn4XGoj749onXMmmRi
	PWmlW5RlK6YpTcQkvtKPkTd7ii3l04+lQuI2GeAjSCMSknPgkF/c6GJ1fo4gZXn2lr1gpP1aNZP
	hYTWP7FZDCV5p+4Z2q7hGBWk+8TevpBStVN8gpS5B+/VFv39WQbibvg2E+BnNwa5P8COOPSwrVn
	J+W1OD9zmv6hmoh1rGL5z0f3awF/BcBFI4NfJyvc6zxH3O9wdg7oRgdrtozplNzUa8O4RNx6dkt
	MuuerwzJzhUqreAsBJt5jT6izPRvjzCGW4DLdKrryoSTWRVw0AKYRNquZrA==
X-Google-Smtp-Source: AGHT+IFvtstEMZJvbyw4DpqNTirNHefkClEQ6PkVI+oc/Nxh+GipWw7XVCdfSZe7+tSvc0epoTrqBg==
X-Received: by 2002:a05:6000:2909:b0:3a5:287b:da02 with SMTP id ffacd0b85a97d-3a5614c1aacmr1440024f8f.40.1749713821588;
        Thu, 12 Jun 2025 00:37:01 -0700 (PDT)
Message-ID: <789e1d1d-bfd0-434f-b697-678ab5e6f912@suse.com>
Date: Thu, 12 Jun 2025 09:36:50 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/4] xen/xsm: Add XSM_HW_PRIV
To: Jason Andryuk 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org
References: <20250610225737.469690-1-jason.andryuk@amd.com>
 <20250610225737.469690-2-jason.andryuk@amd.com>
 <43725e7d-cb4c-44b7-a3e5-59d8d597c805@suse.com>
 <12700a8a-a969-42ed-aba8-753ff9da9a44@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: <12700a8a-a969-42ed-aba8-753ff9da9a44@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.06.2025 05:13, Jason Andryuk wrote:
> On 2025-06-11 09:02, Jan Beulich wrote:
>> On 11.06.2025 00:57, Jason Andryuk wrote:
>>> Xen includes disctinct concepts of a control domain (privileged) and a
>>> hardware domain, but there is only a single XSM_PRIV check.  For dom0
>>> this is not an issue as they are one and the same.
>>>
>>> With hyperlaunch and its build capabilities, a non-privileged hwdom and a
>>> privileged control domain should be possible.  Today the hwdom fails the
>>> XSM_PRIV checks for hardware-related hooks which it should be allowed
>>> access to.
>>>
>>> Introduce XSM_HW_PRIV, and use it to mark many of the physdev_op and
>>> platform_op.  The hwdom is allowed access for XSM_HW_PRIV.
>>>
>>> Make XSM_HW_PRIV a new privilege level that is given to the hardware
>>> domain, but is not exclusive.  The control domain can still execute
>>> XSM_HW_PRIV commands.  This is a little questionable since it's unclear
>>> how the control domain can meaningfully execute them.  But this approach
>>> is chosen to maintain the increasing privileges and keep control domain
>>> fully privileged.
>>
>> I consider this conceptually wrong. "Control" aiui refers to software
>> (e.g. VMs or system-wide settings), but there ought to be a (pretty?)
>> clear boundary between control and hardware domains, imo. As to
>> "pretty" - should any overlap be necessary (xms_machine_memory_map()
>> comes to mind), such would need handling specially then, I think. At
>> the same time: The more of an overlap there is, the less clear it is
>> why the two want/need separating in the first place.
> 
> So you are in favor of splitting control and hardware into distinct 
> sets?  I am okay with this.  I implemented that originally, but I 
> started doubting it.  Mainly, should control be denied any permission?

Yes, imo: Fundamentally for anything the hardware domain is supposed to
be doing. Yet as indicated in other replies to this series - boundaries
aren't always as clear as they ought to be for a clean separation.

> We aren't using the toolstack to build domains - dom0less or Hyperlaunch 
> handles that.  This avoids issues that might arise from running the 
> toolstack.

IOW you don't have a control domain there in the first place?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 07:39:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 07:39:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012451.1390896 (Exim 4.92)
	(envelope-from )
	id 1uPcWj-0005GP-03; Thu, 12 Jun 2025 07:39:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012451.1390896; Thu, 12 Jun 2025 07:39: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 1uPcWi-0005GI-Tj; Thu, 12 Jun 2025 07:39:08 +0000
Received: by outflank-mailman (input) for mailman id 1012451;
 Thu, 12 Jun 2025 07:39: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 1uPcWi-0005GC-EF
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 07:39:08 +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 51ba1bad-4760-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 09:39:06 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a4ef2c2ef3so586845f8f.2
 for ; Thu, 12 Jun 2025 00:39:06 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-313c1bf63afsm784840a91.22.2025.06.12.00.33.53
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 00:34:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 51ba1bad-4760-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749713946; x=1750318746; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Kk1EuVWguEFFQAsK4ZoZZZZmGwMo+W72seNJuPLyBOQ=;
        b=Kg0gpzoyVNjbcJRk8byPSMtF5/RyrMBqkehwqUpf7bbwzav8P6Ze1hKxNsp2AtvFxp
         wRTmEBFxDBEyMj4saEX/RcLO4aE3m0GT2HnI63wGjvHy/cUmUaYxTGTFleJGYgLw3KnT
         Zq8UuQ84ViSdl7V7KtXrg4I5tQkYiOHwqyIXAeDs+aA7uluOfoJcFrD2bVQHDoSMKbLu
         VLojdI4CIuNY5gA17YhK+/ESvNGeoutQgLpTr/yjV3f9OdTDKs1GhwZfNHIJEHtQpM3z
         AtJzshfbloVrv6EdEMZVRMSWOhrhUkiNdo5eRd8LgPU943Ajd7V90MhFCnWznDw5D2zs
         sHXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749713946; x=1750318746;
        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=Kk1EuVWguEFFQAsK4ZoZZZZmGwMo+W72seNJuPLyBOQ=;
        b=h9W1OCxz9EVfLXhjaAexpuIbgqJP6tpjavU2ZgL7gVWR8qMXyGDEu9jUvX0RqNfLGK
         31QLY0mvwkl2f4SY79gtYwTbdZyVYCpe77zttSl8wkHFVfVqanRUxWOg65Zu7XGKGApg
         ylR0Fw+j8jxWLgSd8whHcNmBt+/ICbI3wPPu/QE31mlASuefBgEHb7ybIBEVtvNYbIWc
         noK1StBNLXQ2HSy4bVGMRnmAE4WLgm2dZAHzmsJVFqqXII7jmwpHEbDDdFtydDl0IrFG
         zJb0IM2Xb5zrKyzDnOAZyq8AVmYWNrCwP+7ewKUEs8065MBdS8lxV77KVyabMek+OC6U
         4Fpw==
X-Forwarded-Encrypted: i=1; AJvYcCXYbd6IDClgQ+HLyBhOfdhx3uB7/QQdzt7colcAWsiDPs61iXyJ/L8RZn2KZ7QgAOMv/Qg+Js/3XF0=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz8Q+skdQgfVSMK16gW764KEXmCzYd6Tdx1Yhf1EFFnEafGJ5Vs
	t6+gGZhmArviRMB3ioTysp+N2ZDB+481LjzpXzXaQIiYBJLi1b1qJXlzYJu78eZ1sgAm25fPqCy
	UZLg=
X-Gm-Gg: ASbGnct8oVK/OXdsHRgUT6eZS/qdCh5Bw6oJGCNw9eQ+m5KOcKkzFWDZCKzMs1DgdCJ
	eznHcqoFF4W2WHtCa8IlLv2HlZxsCQ3vptmLMwDV3bkI+fM0K1XGscMsmG+x6Q+9CJx/bj2FrK7
	UIKI8LdzBm26ntAMYFRydyuUi2Xst/7819QpuAsCRFb2sBHPttzxqzIcPpYp/wR/Zw5HvJ63w9L
	PxM4rAQ2xJd5rhd4PRf9uP3kzgVQWHRdSPXeFR7oksKcOkqJN+Y5YLyCMXgDzcLDiKBhsc8Diu5
	XLDzs5c8ZR8YMsiKgPO0AsKCl3CGIKZA5X/DYEyl50NEOyq6nLQMYYJCay1FfH4UPQlOW823Per
	C/7FUbd+3LnB/FA+VxDT18o+qmMgoGmfMQsHEuluqBokZNpI=
X-Google-Smtp-Source: AGHT+IFBaq0RwwbcIip8Izuk0nLO04nvkeMufnFU77a6smivEi3KEwmTGQazt8N/nLRhfvEkQ9zt9g==
X-Received: by 2002:a05:6000:2886:b0:3a5:1471:d89b with SMTP id ffacd0b85a97d-3a5614dcdd8mr1604868f8f.53.1749713641500;
        Thu, 12 Jun 2025 00:34:01 -0700 (PDT)
Message-ID: 
Date: Thu, 12 Jun 2025 09:33:49 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/4] XSM changes for split hardware / control domain
To: Jason Andryuk 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "Daniel P. Smith" ,
 Christian Lindig , David Scott
 , xen-devel@lists.xenproject.org
References: <20250610225737.469690-1-jason.andryuk@amd.com>
 <0defc4e7-382b-4651-8255-652da17a2129@suse.com>
 <4b0b7554-e22f-4ef2-9236-bcc2079842d2@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: <4b0b7554-e22f-4ef2-9236-bcc2079842d2@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.06.2025 07:08, Jason Andryuk wrote:
> On 2025-06-11 09:28, Jan Beulich wrote:
>> On 11.06.2025 00:57, Jason Andryuk wrote:
>>> Theses are the broad changes needed for a split hardware / control
>>> domain.
>>>
>>> An earlier posting gave device_model privileges to hardware domain.  For
>>> this posting, it was split out into a new capability.  This way the
>>> operator can choose where to run the device models without making the
>>> hardware domain have the permissions.
>>>
>>> The first patch add XSM_HW_PRIV for the hardware hypercalls.  Unlike the
>>> first posting, the control domain can call these hypercalls even though
>>> it doesn't really make sense.  The idea was to keep the control domain
>>> all powerful from an XSM perspective.
>>>
>>> SILO is changed to allow control, hardwware or xenstore to service
>>> domUs.  Xenstore and hardware will use grants for PV interfaces.
>>> Control wouldn't typically provide PV interfaces to domUs, but it is
>>> given the permision to do so.  Again, to keep control all powerful.
>>>
>>> xsm/dummy: Allow hwdom SYSCTL_readconsole/physinfo this is not strictly
>>> needed.  xenconsoled could read Xen's dmesg.  If it's in hwdom, then
>>> that permission would be required.  SYSCTL_physinfo is mainly to silence
>>> xl messages, which are mostly cosmetic.
>>>
>>> Jason Andryuk (4):
>>>    xen/xsm: Add XSM_HW_PRIV
>>>    xsm/silo: Support hwdom/control domains
>>>    xen: Add DOMAIN_CAPS_DEVICE_MODEL & XEN_DOMCTL_CDF_device_model
>>>    xsm/dummy: Allow hwdom SYSCTL_readconsole/physinfo
>>
>> Overall I can't help the impression that this level of disaggregation simply
>> requires the use of Flask.
> 
> I have thought about that.  The problem with Flask is the complexity of 
> the security server.  We don't want to have to deal with all that code. 
> A fixed policy is easier for our coverage testing.
> 
> Exposing separate control, hardware and xenstore capabilities, it makes 
> sense for the default policy to function with them.

Yet as indicated in replies to individual patches - the boundaries between
the three aren't clear, which imo goes (to some degree at least) against the
purpose of "disaggregation".

Jan

>  This would be a 
> coarse level of functionality, and Flask would remain for fine-grain and 
> MAC enforcement.
> 
> Regards,
> Jason



From xen-devel-bounces@lists.xenproject.org Thu Jun 12 07:41:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 07:41:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012457.1390907 (Exim 4.92)
	(envelope-from )
	id 1uPcYv-000711-Dy; Thu, 12 Jun 2025 07:41:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012457.1390907; Thu, 12 Jun 2025 07: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 1uPcYv-00070u-9j; Thu, 12 Jun 2025 07:41:25 +0000
Received: by outflank-mailman (input) for mailman id 1012457;
 Thu, 12 Jun 2025 07: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 1uPcYu-00070o-2e
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 07:41:24 +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 a36aca20-4760-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 09:41:23 +0200 (CEST)
Received: by mail-lf1-x136.google.com with SMTP id
 2adb3069b0e04-5532a30ac45so626708e87.0
 for ; Thu, 12 Jun 2025 00:41:23 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a36aca20-4760-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749714083; x=1750318883; 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=6R/5DpBaQMcdoJ68yNaTLXbkCFIgDATb9sFKj2xxMbY=;
        b=iFvGG/faa+rxpbOiLFdDvQK3uqko5w0EKPS8kLnuf7t66IMrz0cNX4PHZ7lDa10Tcy
         Fk5w0ITxZXRK0kGJ6iffVRorUWJcG1MvftIItiT6CMOPffXyBmmS+Ze0KzPSRISKC1lh
         lToGsXZnrwYD7yKwH3TmnrdSJ2tj2Yefw7SlwGHzjW3PXx43Aql7h33AWMjw18tPV7mU
         rDkef71PBuRdvAELytt5cHY+ikl9c72gW/J2htX0+5mhSTHyDk0OWWlZhHAkF+41YGh/
         UWBbXRksGF9LsSv0ry4vMODd6Y1eIWWTmMZpUmOqnP23CCL1cp/6Ooud1FKZHya1FQne
         uBuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749714083; x=1750318883;
        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=6R/5DpBaQMcdoJ68yNaTLXbkCFIgDATb9sFKj2xxMbY=;
        b=BuH2/AHDiU+QzMBKqj4EzfTjqEmEblXTXv7YGqjlaDJFZjQ+T62A5T19Cl8wiFbJ3k
         jZrOe0nJL3EEulTti+lQNzUnGK717L92m4nAKX7ZgLg6F/dIXXcQSBWmjYvmRTjIUa2s
         bV1LpTIj06eUhpXUGpOC//qem+n+uc0NqgNuDpd8EiUb5olI736gtSQLv2TVEGDeqc79
         aGqBqLXIV7odooDTA2zGlk7Qot8k4TWAr6r62t53hKUxnLzfYkpdg0AyTS/VURONK/96
         zXbVwW92700SjlIeVuLckb4Gu0U0mk3B1UvE+hzZtXTRWoPkxWRv4jO8GA6EIPFF+upR
         C7VQ==
X-Gm-Message-State: AOJu0YxmtxMIe3/u3LSwI1LVw1QfhWYtW/x/O4PMvF9QzPDkXfGY5Usz
	cW3us/1D9o+g5Dwg1pGp5XCLOaUn6Db9ROVpkjitUgnYjmgrRUolLxIHBWjAsGvogz1//diSpaK
	GMS2or/R5mPc/LHpVXNodYxqXSi9Nm4Y=
X-Gm-Gg: ASbGncuUnokgOvV6gxFKWF1uz3v5P0RQccV0+0N/D/KtRhhjee+QKNW8nTYD9tEahIU
	Yi5nAOP5ebBgX7QzcamU6dBGc1fnxDs70htF/eudSipFyQAgrFlz+c9AXDM7BD18yTCFTaReWRx
	7X6rmrBAd2QcJEw6rudxZLBt8piqVx1tB4Uq2ZT1Nb5w==
X-Google-Smtp-Source: AGHT+IE15WhpiWIZmuPM2+cIqV3ecsrPGs4nxGV+owduKXkpqNJap8losnoOi4wtBOdaaU6L5qffSNEN+oEiWrjB144=
X-Received: by 2002:a05:6512:b8d:b0:54e:8135:33dc with SMTP id
 2adb3069b0e04-553a545233dmr677127e87.14.1749714082397; Thu, 12 Jun 2025
 00:41:22 -0700 (PDT)
MIME-Version: 1.0
References: <7364a71d-2604-49ca-bab7-d21544d49b10@gmail.com>
  <4fb007fd-3a87-4a12-ae73-15870d7bae42@gmail.com>
In-Reply-To: <4fb007fd-3a87-4a12-ae73-15870d7bae42@gmail.com>
From: Mykola Kvach 
Date: Thu, 12 Jun 2025 10:41:11 +0300
X-Gm-Features: AX0GCFuGHe-4RoSUFMXLFT2iRXLI8xNAtqy7F1aDW8eGWuHmBYdtpmDAm9J0_lY
Message-ID: 
Subject: Re: Xen 4.21 Development Update [May]
To: Oleksii Kurochko 
Cc: xen-devel@lists.xenproject.org, 
	Ayan Kumar Halder , Mykyta Poturai , 
	Juergen Gross , Teddy Astie , 
	Bertrand Marquis , Luca Fancellu , 
	Jason Andryuk , Alejandro Vallejo , 
	Sergii Dmytruk , Penny Zheng , 
	=?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= , 
	Roger Pau Monne , Andrew Cooper , dmkhn@proton.me, 
	"Daniel P. Smith" , Grygorii Strashko , 
	Alejandro Vallejo , "committers@xenproject.org" , 
	Community Manager 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 11, 2025 at 1:39=E2=80=AFPM Oleksii Kurochko
 wrote:
>
> Hello Mykola,
>
> On 6/11/25 9:03 AM, Mykola Kvach wrote:
>
> =3D=3D=3D ARM =3D=3D=3D
>
> * SMMU handling for PCIe Passthrough on ARM (v11)
>    - Mykyta Poturai
>    -
> https://lore.kernel.org/xen-devel/cover.1741958647.git.mykyta_poturai@epa=
m.com/
>    -
> https://patchew.org/Xen/cover.1748422217.git.mykyta._5Fpoturai@epam.com/
>
> * xen/arm: scmi: introduce SCI SCMI SMC multi-agent support
>    - Grygorii Strashko
>    -
> https://lore.kernel.org/xen-devel/20250311111618.1850927-1-grygorii_stras=
hko@epam.com/
>
> * Add initial Xen Suspend-to-RAM support on ARM64 (v4)
>    - Mykola Kvach
>    -
> https://lore.kernel.org/xen-devel/cover.1741164138.git.xakep.amatop@gmail=
.com/
>    - https://patchew.org/Xen/cover.1748848482.git.mykola._5Fkvach@epam.co=
m/
>
> I'd like to propose including initial support for Suspend-to-RAM in Xen 4=
.21.
>
> This feature enables Xen and its guests to enter suspend state via
> PSCI SYSTEM_SUSPEND. Xen suspend is triggered from the hardware domain.
>
> Support is currently Experimental.
>
> Thanks for your feedback!
>
> I saw that there are two patch series connected to Suspend-to-RAM topic:
> - https://lore.kernel.org/xen-devel/cover.1748337249.git.mykola_kvach@epa=
m.com/
> - https://lore.kernel.org/xen-devel/cover.1748848482.git.mykola_kvach@epa=
m.com/
>
> So it seems like we should follow a progress for these two patch series i=
n parallel
> Or the difference is that one of patch series is for connect to guest and=
 another
> to hardware domains.
>
> Am I missing something?

Yes, you're right, but the second patch series (part 2) depends on the
first one (part 1).
It was split out to help speed up the review process, as suggested
during the review of v3,
in order to separate guest (vPSCI) and host (PSCI) suspend functionality.

It's expected that part 1 will be merged first. However, since
CONFIG_SYSTEM_SUSPEND
has already been merged, most of the patches from part 2 can also be
applied independently,
except for a few at the end of the series that still rely on part 1.

>
> ~ Oleksii

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 07:48:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 07:48:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012463.1390917 (Exim 4.92)
	(envelope-from )
	id 1uPcfi-0007b7-49; Thu, 12 Jun 2025 07:48:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012463.1390917; Thu, 12 Jun 2025 07: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 1uPcfi-0007b0-06; Thu, 12 Jun 2025 07:48:26 +0000
Received: by outflank-mailman (input) for mailman id 1012463;
 Thu, 12 Jun 2025 07:48: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 1uPcfg-0007au-9x
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 07:48:24 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on2062a.outbound.protection.outlook.com
 [2a01:111:f403:2009::62a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9c14752f-4761-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 09:48:21 +0200 (CEST)
Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
 by MN0PR12MB6055.namprd12.prod.outlook.com (2603:10b6:208:3cd::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.18; Thu, 12 Jun
 2025 07:48:16 +0000
Received: from PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264]) by PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264%2]) with mapi id 15.20.8835.018; Thu, 12 Jun 2025
 07:48: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: 9c14752f-4761-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=a/T9if9LoovEIZSpsXWuFHELM9Aoi+XzdcsLEb6brFmKyhIM6SvUk+HuQis1r2zyIa0Wp9MmvPM9GItj25gvHpxUTWimgatvEAMavjHhrzkRCStwFy270ZqDNKBrT+TpSyZmfRcOhhjKUzXJolBmcjmIXG0IWho1Q22y7Ae9WKkBYY1840Y+lorwNqTMSOQ4aj2J3OuPSBuxYw7+gd4laOTShvQOK5JiHK4tk3GjvJyWWN7j+tfCYi30DokvcC4QMyKjxQ4fEfPAImT86JHRTnpIK2RussN0J3rraZ3LDX1JqmfjE8Qy4+CyGVQWwJURRGpoazmb3SXBny6AEuft+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=xRAfrnQaH0ueHVkW+B+X1iPuzeIYFft5fE4xMcX0vzk=;
 b=GmKz5XUfXsl6gBH9Gz5SrfhhBWEZW3iQCaqKyZKo/RxAvXds3U1WayzD80pIIPNZ5XLCmCrGRsKHwGOy/+syoQa6rPotggVAZKoycO/Z7TBo+3POLVHatzsK5rUfim8wiW36Hcuf9boXpUPHCj9O65PivUZ+3KANYKXpPt4GRp4fK47/vCwBSjn9ZNA2XFixz+MGWx26+CHxVW1LaLyQRS7yfhzUHXvf39O6QjGRXFOSIyUmaJasPwE+z9FQVUXvYKl+QheAW+Awm5WngCtU9O73zsA9BjJ6HPrVlcqbdG5bF41osKmotI1gS5bkyYzxXi1t7YunVZxpd/iBOgT1TQ==
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=xRAfrnQaH0ueHVkW+B+X1iPuzeIYFft5fE4xMcX0vzk=;
 b=3r9BJ12rDRxKKu6yUA24V+PIlr6IRzCG6/F0nUScLwhyzY7I7hwfsJ9ZtThKAxxuKzsiizv9+Rp24C8TEY7+LEkjQg4bmUKho10wIFq/jFpIESdo+TJprAs6qEU2dfxEp8oMFnInSlE+XxXvtT2n1814BvxHNqWZmoMU29gvaH0=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <998d479b-dab1-411b-8cdd-31d0c7da8208@amd.com>
Date: Thu, 12 Jun 2025 08:48:11 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 3/6] arm/mpu: Move domain-page.c to arm32 specific dir
To: Luca Fancellu ,
 Ayan Kumar Halder 
Cc: "xen-devel@lists.xenproject.org" ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: <20250611143544.3453532-1-ayan.kumar.halder@amd.com>
 <20250611143544.3453532-4-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: DB3PR08CA0018.eurprd08.prod.outlook.com (2603:10a6:8::31)
 To PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|MN0PR12MB6055:EE_
X-MS-Office365-Filtering-Correlation-Id: 09a555f8-c5bc-4965-b75f-08dda9857d16
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?RFFyVEFFcStxQ0dOOGgxY0Q1TnFKNzFxajhWY0Z1UTd6N1NUNEwzQUhXSmZO?=
 =?utf-8?B?ZFdRL2I3WjJiNG1DWUhrdTJQMnRoUGhuc0gvemVlalFsUVJ2M3pIN1JXVThQ?=
 =?utf-8?B?ZFppOW5scmR2Vm5CbzEwOW0wMzhTNUQzWEdDU3lFeFhlWkZhcURuR2ttSGM4?=
 =?utf-8?B?ejVxNnFXTjJkQnpOTnhJS3g1S3kvZU1DaisyaUxDNFVON3BhdUN6NklmWEZ5?=
 =?utf-8?B?TXRGZDBUU0h3a210bytVNFpacFo1dFlpTnV3emxjVVlFcENyWmJIdVNlZEtK?=
 =?utf-8?B?VUpSdG9RbWRMcDJjZlVmYzhyR3VtbnJjNUQ4WFFyaS9tU3ZQTDBrblZGZWlJ?=
 =?utf-8?B?UFZ0WTA2czBvdk14b0tDOEc3VFM3c2R1L3dWOEZJVk82QjliaXV5cjFKQ3E2?=
 =?utf-8?B?UEdGME9ocEpDcFVWQUtIMzRWTzRNL2V6dU9CbTE2aDFLN1d3YTM1SU4yejZX?=
 =?utf-8?B?K0RYdHkwN1Yxc09NYjRZSGpPWU5KbHRUZVVQdkYzaDg3RFhCeWRia003ZXlh?=
 =?utf-8?B?M2ZBczlxWjVuQXplR1BjbEZBQVk4VFpnZDd1TGxVc0x5bWJtM2hQSjVkUW9H?=
 =?utf-8?B?c0tKMVdiYWlmNmhNU3ZqTGlHeEhDVUdCZUdFa0M2aUdXbXROQk9ycU9VUlZZ?=
 =?utf-8?B?elA3UHJ0aEJ2VG1YdVk3Qy9PeU1KdlFqRkY3dkxjTUxjQzZTb0JtQlFmNkRv?=
 =?utf-8?B?WnNjRWJYY2ZWWVNEMldPUWRlMXpvL2dpZk9Qd0ZvbVFVVUFvU2xWUEJnK1Bw?=
 =?utf-8?B?U2xsUUsyYXZIYm9XbEVLMVRCR2FST3VUcVBNV2Z5TVJNby9GVFI2b0Rhbkgz?=
 =?utf-8?B?SjIwODI4RmhsT3gxdy85VEVRRmxHZG5hMDlGTXdFbXRoOVJ1M2VDWmx1TFEv?=
 =?utf-8?B?emx2Z25NRzZaaGZUdjFzbmFTODhyUGJ2Z2FIWm5WMzRwSitCTFF3dVJqZ1Fl?=
 =?utf-8?B?b3RUdDB4VEM1Vk11Q1hseDNRa284SmdIMll6MkV1clIwVGJpcmd3TUVUNU0y?=
 =?utf-8?B?b1V0MFVsMHBqTUZaNHgwRWpuOFFrZG1UZ0dVR1QxR1loNStVMFd4am5wOXF0?=
 =?utf-8?B?L01OR0hOdzBtSWxKWm9ETno2WWVIMGpsUmxPb043QUtFeEhyRlBzckU2RU1l?=
 =?utf-8?B?Uk1MZnh1NmtNa3cwWm83STNycVNNU0RnZVN1OHZ5bm9zNXBqN0hEWU5IZm9Y?=
 =?utf-8?B?ZElhT2NXOHppczZxK2J2WU8xbWtxeDcxTzRTYnd5eXVUbHV1Vk9FK2M0b3Ew?=
 =?utf-8?B?anlaRWErSEh4M3ZMQWlmbUU4YytkSDZ1T2ZHZzlVb2t4cTZweU5CK0gxelpV?=
 =?utf-8?B?TnkyUDBwSk9NVytLakJDYk1Ed1Y3MVVlZTJhWVU0OGpoMVpaaFlJanByeTlz?=
 =?utf-8?B?YkFuMjM1dERJOE5jWmxETTNiSWo4RVEvYzJ3SnBoRkhwZ1RtQjdXUlVQVStP?=
 =?utf-8?B?WTE1RGM4MFVGU3FnMVA0WVpuK01VaXBYUHNwSDJGSklHQWFlT2h4L1hlK2Qx?=
 =?utf-8?B?WDFJRlpQUFd1M0Ivdnk0QkdrRUkyNmlBeFZsWnZwQ0lHSThycEVZVk1PREpO?=
 =?utf-8?B?U01HYURHNTFrYkRRVXQ1bW8ySlRpYlVEdzRtWTNsZTBlenI3T1Z1UjE1Qmpi?=
 =?utf-8?B?akxMamsxSmsrV2NONExXNmgwWDlGT1JlNmY2QjBJck8xWXV2YW5jYnZKSmFy?=
 =?utf-8?B?UlZFM2NtWXgxVGx5VEpQZzJ3aGRNVHN0TWFGcDY2UnU0MklkV0NFeWsvMEl2?=
 =?utf-8?B?RUI0VHFYdE1CdkJpR1ZPbmFPeGJVbGc1MnJGaDJSTkNYQVNOYkdPNHFkeEV4?=
 =?utf-8?B?K09RT3hEOGlua1hYbVFDcTVMeHNJOFF4bGhqNGttdWJOMXpTOVZ2K2RUQk0r?=
 =?utf-8?B?eTM1NGN5dUM5UGMvZ3hXWCtLemZNU2NaYkE4Z2hzd0czZm5MY2dyaGpZc2U2?=
 =?utf-8?Q?BytBv6xrcig=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)(376014)(1800799024)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?Rkhta0xDMFh4U3VwUnhjTTJPd2F1K2xwMWJxSGUyVmNOaXcrRU9ocnVwY2xM?=
 =?utf-8?B?WVZWdE53dlNCd1VtWHdDblU4N1ZnUlRNNG1ncWJpSWc4bjM0Q1pUK1dsRXNi?=
 =?utf-8?B?LzdEYU1ZSDFPOXlOaXZkRDJLeXQybk1SZStZNHRZY3Yra29JcWJnckJ1OGJ6?=
 =?utf-8?B?N3JkUk4xSUJvdmJmRUNVZlFwRkpybm5ZTk5wSXN2WnVLaFRsTWVQNS9SS0RG?=
 =?utf-8?B?WVo2VkJ6Nlc5U0ZERGtNUVlEWXNKUmw1dnBzNVpnZlJqS0FWQlZFaEZZc2Y3?=
 =?utf-8?B?UFBsL05SNFd0MjBXMVVQUzQzN3dWWWs3NkNoSUNjVFU0NjN3VGZneW5ua1JK?=
 =?utf-8?B?V21OZTVLN2xUdlBOd3dzODhwTG02YW92Y0d3Rkdob2kzeW5pTkhacnpGcFYz?=
 =?utf-8?B?MmhsVVF0WEcwMDJDVkY2WnUrT1BzODJQd3hWRUYvTWJudmR5OEgwMk9hT05i?=
 =?utf-8?B?V3Y2ZWhYR3lkT3N1OHhzZ1pabndRUGRpc2hPaUxwbDZ3VDF0WjdwRzBkTTFo?=
 =?utf-8?B?SnNlbVdoZ0VqN3RiRSt4ZzRaT282WXdXUWRtcXlVOElHR01xM3BucldLb2RX?=
 =?utf-8?B?Y1pheUtONWRLUnVKcWRXanZ4dk5CdEJNMSttdGVlY2lyNlRLYXJ2RXJ5bHZK?=
 =?utf-8?B?Zk1STzdubnJFOTNkMnhSam94QjdHT0lTY1NqSzk3THRRaWtHZlJTZTVROE1r?=
 =?utf-8?B?Z3NDRzNQdGhpbk91OCt1ZHc4N2lPTS9ueWRXMzAvUFJIZFlnbHNCYU9iRU1l?=
 =?utf-8?B?UnkwbklLL1kwNFZOT2EzS1pUVmpjODFTOXY1YzlJcVpBeWVKVFA4aHljUXl3?=
 =?utf-8?B?cERpMUN5aFBOTUl0VmJCSlN6Um9TY0w0TWQ2SjRnSjRDUmRKS3pkWHRqVmhU?=
 =?utf-8?B?SEFTVVQxRDNjdlVkcGZ1cUFobGpnMlFBQnlHdjMxQ2o5WU02VlN2S1Q3S1ND?=
 =?utf-8?B?L0gybnBjcDgxNlZnWDREd1lPYWovdHhTZlNJMGNRV3Bzb0MyZkVGVkkvZ0dS?=
 =?utf-8?B?UFhWbkFpb21DQmlrY040WDhsbG1IaDQ1Wnp3MGdvQlhLWTJZc2FENWZoc05K?=
 =?utf-8?B?MzhNQUFSakpWbm1kMHpNOEZHeTBHRlhQdTIyYTloQ3lyWlZYK2dMeXV4ZFh4?=
 =?utf-8?B?ZUs5Y0xhaE9zYnYrMDBnWlJIQlk2V2xoWEtGdHRIdk5SQnZVa2JXWGwwUWFz?=
 =?utf-8?B?ditvVVZxcVluK0duRUk1TTZtZEQ3WVY5UDh0TUlxNUhPRy9DZWI2RzNtdFRn?=
 =?utf-8?B?aFVZeGsweHhleWh1NFNDZjVVS0NpcklQVGFUNUptYjUzL3hhZm9MckMzMmZh?=
 =?utf-8?B?eEZubkNRdStYNitiWG1NRUZtMC9pMXlPTHpHTDB4QlBKRm5OOUpqVGZwWXlW?=
 =?utf-8?B?aVlVVHNqMkRMcUE2WTh1c0dNRlM5Z3JJZU9GeXZKZkFtOG1ZWUpld1B5UnNK?=
 =?utf-8?B?WVAyL25qU3IxMGIxb0V6QnNCdFI0SWVTajI0MktPZkdERE56d3NpeXo5QUtF?=
 =?utf-8?B?R1VXSDFuUTlBZ2JhalNVT3BuMExOSk5KZG1tOUV3M1JoaEpxc2o4bXlzL29o?=
 =?utf-8?B?ZmtrWHA0SEw5L05BYWt1emw2Y25nOTdlUkhhcTJMK0lvNGJBUE9wZVQ4OEFs?=
 =?utf-8?B?NGNaT1VhRVpVNXA3OXBuWHFNaTRUT0t0ekIrTmRLQzdidXV0VFJnR09pNEFT?=
 =?utf-8?B?QWJJSUYyZ1hiRUlGNGtDV2RNNTczL0wybnNma0ZrdHpTZ2dvK0d6UnZHTGFT?=
 =?utf-8?B?VHlRN0ZFaWxxZHVXV2ptOTcrL3ZJbFMveEJ0b2VtV1RqK1pwRy9Gb0tMM3Ft?=
 =?utf-8?B?OHF1RDlGdk8zUlA4UHU4dXdJWk1lNFFDZWZaNk9uZ1NpWEpMYUNQK2QyMFEv?=
 =?utf-8?B?WE1DOGN4Umx0d0N4QWlETkVFQnd3NjhrYzhIaDNLTnZvT3h0ZkFBZDNsbnNY?=
 =?utf-8?B?c1JIRTNmUTlpTzViZ3hvNHVNS3VWN3BwcGkybDZmVHFvelU1M0Z2Z1lxOHZI?=
 =?utf-8?B?aSs3Ymhlc1I1Z0VRYVFNeFpFN1ZadEpDalFMc1dyaWttd3JyTnlkZFBYWDZn?=
 =?utf-8?B?clBQbTJWbUtPSHlUWGxmTzFqUTF6TEtDTWlWem1STGNuU1gyR1lrTTA4dnoy?=
 =?utf-8?Q?6sPRj5Txb9ZnLP+UaDBWdsXVf?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 09a555f8-c5bc-4965-b75f-08dda9857d16
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2025 07:48:15.3629
 (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: J/ysf+gOEMWg8yiBwHmQ/1q9+95bu47QcfpppEpyHiL9eg0K7gGDmoyxgRRyaWM3MOjtYw2OXLRUjb60fks94Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6055


On 11/06/2025 20:46, Luca Fancellu wrote:
> Hi Ayan,
Hi Luca,
>
>> On 11 Jun 2025, at 15:35, Ayan Kumar Halder  wrote:
>>
>> Create xen/arch/arm/mpu/arm32 to hold arm32 specific bits.
>>
>> Signed-off-by: Ayan Kumar Halder 
>> ---
>> Changes from :-
>>
>> v1..v2 - New patch in v3.
>>
>> xen/arch/arm/mpu/Makefile                  | 2 +-
>> xen/arch/arm/mpu/arm32/Makefile            | 1 +
>> xen/arch/arm/mpu/{ => arm32}/domain-page.c | 0
>> 3 files changed, 2 insertions(+), 1 deletion(-)
>> create mode 100644 xen/arch/arm/mpu/arm32/Makefile
>> rename xen/arch/arm/mpu/{ => arm32}/domain-page.c (100%)
> Uhm, why?
>
> Arm64 is using domain-page.c:
> https://gitlab.com/xen-project/people/lucafancellu/xen/-/commit/b28198d00078991d4a6502e94c8779d84fec0120
>
> Did I miss something?

Oh, I did not look at the future patches. I can drop this patch in my 
next series once you and Michal/Julien reviews the other patches.

I feel it is cleaner to have separate implementations for 
prepare_selector(), read_protection_region(), write_protection_region() 
between arm32 and arm64. (Refer patch 4 and 6)

Let me know how it looks like.

- Ayan

>
> Cheers,
> Luca


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 07:50:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 07:50:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012473.1390926 (Exim 4.92)
	(envelope-from )
	id 1uPci4-0000wk-IC; Thu, 12 Jun 2025 07:50:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012473.1390926; Thu, 12 Jun 2025 07:50:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPci4-0000wd-EY; Thu, 12 Jun 2025 07:50:52 +0000
Received: by outflank-mailman (input) for mailman id 1012473;
 Thu, 12 Jun 2025 07:50: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 1uPci2-0000u3-8E
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 07:50:50 +0000
Received: from fout-b3-smtp.messagingengine.com
 (fout-b3-smtp.messagingengine.com [202.12.124.146])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f3565c97-4761-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 09:50:48 +0200 (CEST)
Received: from phl-compute-01.internal (phl-compute-01.phl.internal
 [10.202.2.41])
 by mailfout.stl.internal (Postfix) with ESMTP id ED6D111401FF;
 Thu, 12 Jun 2025 03:50:45 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-01.internal (MEProxy); Thu, 12 Jun 2025 03:50:46 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 12 Jun 2025 03:50:41 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f3565c97-4761-11f0-a309-13f23c93f187
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=1749714645;
	 x=1749801045; bh=3lxvYPHUDqNyMMaaO4nBx8a2VCjVkFHriDdvmhxDgQs=; b=
	QqgoUSidtbgX4DPDrnommgwH6jTfgHbNT6guBbQitbEhN9IlnnVXkf+KDWA63U66
	sZIgvLCGQfwGqXuGstgel9vldV0TGlaQRQnynpL7Thhh/KLMRKmmxQq0WKsPfpLv
	y7MH0GBCkk/o7PiX13ISpr8DoSUylV39p2W8P5XDtI2rmNuCoX+9G1a2h7sF/QiK
	RqXPNIJZAO7EVpaeEuUGgfzexnRqUH+6/7IjUy+DG6/Zys+CZ6At9Lb+lwKUsBNY
	MzrXzbyXYAewVyEBtyw8lEoe6SbZ7B0E5COSoRnJ+pW0GAi3LVDnw2IIYleQHDlX
	9kB8YrhuEfdTzhtzLYez+w==
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=
	1749714645; x=1749801045; bh=3lxvYPHUDqNyMMaaO4nBx8a2VCjVkFHriDd
	vmhxDgQs=; b=glLnqqCLnSF8AhYpnMCSmVQJK2ij0idHRVIgx8TnpMWZjQTjjpw
	FW0SugIJLcms+KeG5CO5lcT2xb/uYuZR2PbMbnBYIjlsJQFUTX9z9humlUGrNny+
	ffWfUliG8O5TM8E6NnW8lHgkphQOitvmP4lMbHAMuMFCFUIw6Bz4mkjtVPT80Ci/
	jjQQfkaof9YbmMZCqNfoB2Sstfbh6+rG+krvA26xVceNBRyPf3l5MmD96SEJzAFu
	YeatmnsRokr1fAU5JXblE+6FwpC31LEeeUKminvJagiE/HZHzyEK4Yqm014wwzAd
	tVoaGQGP/27xxjFN0b4tkDFvhv28GGrf+4g==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugddugeehudcutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp
    uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg
    hnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehgtderredttdej
    necuhfhrohhmpeforghrvghkucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoe
    hmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucgg
    tffrrghtthgvrhhnpeekgeeiteefgeevjeeiuddulefgvdevgfdvgfejkeejffffgfejle
    fffedvvefhkeenucffohhmrghinheprhgvrgguthhhvgguohgtshdrihhopdhgihhthhhu
    sgdrtghomhdpshgsrghtrdhmugenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh
    epmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhl
    rggsrdgtohhmpdhnsggprhgtphhtthhopeduhedpmhhouggvpehsmhhtphhouhhtpdhrtg
    hpthhtoheprghnughrvgifrdgtohhophgvrhefsegtihhtrhhigidrtghomhdprhgtphht
    thhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdprh
    gtphhtthhopegrnhhthhhonhihrdhpvghrrghrugesvhgrthgvshdrthgvtghhpdhrtghp
    thhtohepmhhitghhrghlrdhorhiivghlsegrmhgurdgtohhmpdhrtghpthhtohepjhgsvg
    hulhhitghhsehsuhhsvgdrtghomhdprhgtphhtthhopehjuhhlihgvnhesgigvnhdrohhr
    ghdprhgtphhtthhopehrohhgvghrrdhprghusegtihhtrhhigidrtghomhdprhgtphhtth
    hopehsshhtrggsvghllhhinhhisehkvghrnhgvlhdrohhrghdprhgtphhtthhopehsvggt
    uhhrihhthiesgigvnhdrohhrgh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Thu, 12 Jun 2025 09:50:38 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Andrew Cooper 
Cc: Xen-devel ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Stefano Stabellini , security@xen.org,
	Juergen Gross , Trammell Hudson ,
	Ross Lagerwall ,
	Frediano Ziglio ,
	Gerald Elder-Vass ,
	Kevin Lampis 
Subject: Re: [PATCH] docs: UEFI Secure Boot security policy
Message-ID: 
References: <20250611235851.167385-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="xqmz7RRHR2+q0XuL"
Content-Disposition: inline
In-Reply-To: <20250611235851.167385-1-andrew.cooper3@citrix.com>


--xqmz7RRHR2+q0XuL
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 12 Jun 2025 09:50:38 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Andrew Cooper 
Cc: Xen-devel ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Stefano Stabellini , security@xen.org,
	Juergen Gross , Trammell Hudson ,
	Ross Lagerwall ,
	Frediano Ziglio ,
	Gerald Elder-Vass ,
	Kevin Lampis 
Subject: Re: [PATCH] docs: UEFI Secure Boot security policy

On Thu, Jun 12, 2025 at 12:58:51AM +0100, Andrew Cooper wrote:
> Written to be solution and deployment neutral in order to focus on the
> technology itself.  This policy is intended to work as well for UKI as fo=
r the
> "classic server setup" approach.
>=20
> Signed-off-by: Andrew Cooper 
> ---
> CC: Anthony PERARD 
> CC: Michal Orzel 
> CC: Jan Beulich 
> CC: Julien Grall 
> CC: Roger Pau Monn=C3=A9 
> CC: Stefano Stabellini 
> CC: security@xen.org
> CC: Juergen Gross 
> CC: Marek Marczykowski-G=C3=B3recki 
> CC: Trammell Hudson 
> CC: Ross Lagerwall 
> CC: Frediano Ziglio 
> CC: Gerald Elder-Vass 
> CC: Kevin Lampis 
>=20
> A rendered version is available at:
>   https://andrewcoop-xen.readthedocs.io/en/docs-secureboot/admin-guide/ue=
fi-secure-boot.html
>=20
> Obviously RFC at this point.  It's worth saying that XenServer is intendi=
ng to
> use Shim and get a signature from Microsoft, retaining all exiting featur=
es
> such as Livepatching and Kexec crash reporting.
>=20
> This trails off into more TODOs towards the end.  Individual tasks should
> expand on the start made and resulting conversation from this thread.  As=
 a
> reminder, the target audience for this doc is an administrator running a =
Xen
> deployment, but who is not necesserily a developer.
>=20
> Several things are hard to express and want further discussion.  Suggesti=
ons
> welcome:
>=20
> 1) Content of CONFIG_CMDLINE and the various CONFIG_*_DEFAULT options.  X=
en is
> not going to be issuing XSAs for "downstream chose an unsafe configuratio=
n,
> then signed and deployed the result", yet Xen probably should be on the h=
ook
> for bad "default ..." settings in Kconfig.

Should there be some guidelines what values are/aren't safe for UEFI SB?
I don't think there can be a simple list, for example some things may
depend on other settings and/or whether UKI is involved. But some
comment about relation to UEFI SB (in Kconfig help?) would be useful.
As for CONFIG_CMDLINE, IIUC the current implementation does cover it too
(as in, lockdown mode will filter built-in cmdline too).

> 2) Pre-boot DMA Protection.  Microsoft consider this a platform feature
> requiring OEM enablement, and do not consider its absence to be a Secure =
Boot
> vulnerability.  But, it is less clear what the policy ought to be for Xen
> booting on a capable system and failing to do a correct live-handover of =
the
> IOMMU across ExitBootServices().

That's a very good question. Do you know if disabling pre-boot DMA
protection is allowed if UEFI SB is enabled? If so, I'd assume it
doesn't need to be covered.

> 3) The AMD microcode signature vulnerability.  While it's not Xen's bug p=
er
> say, it's clearly a Secure Boot bypass because we do offer microcode load=
ing
> capabilties to userspace, and malicious userspace can load an unauthorised
> microcode which allows them to read/write physical memory and bypass furt=
her
> signature checks.
>=20
> 4) Userspace Hypercalls.  To anyone who isn't already aware, /dev/xen/pri=
vcmd
> in the various Unicies is a giant priv-esc hole, as root userspace can
> e.g. issue direct memory hypercalls behind the back of an (intentionally)
> oblivious kernel, and cannot be handwaved away as "it's fine because it's
> root" under Secure Boot.  It's not a Xen vuln (Xen *does* audit pointers =
in
> guest hypercalls), but it is a guest kernel vuln because of failing to
> correctly audit hypercall parameters.  However, it does require substanti=
al
> changes in Xen in order to allow guest kernels to do something half-way s=
afe.
> ---
>  docs/admin-guide/index.rst            |   1 +
>  docs/admin-guide/uefi-secure-boot.rst | 134 ++++++++++++++++++++++++++
>  2 files changed, 135 insertions(+)
>  create mode 100644 docs/admin-guide/uefi-secure-boot.rst
>=20
> diff --git a/docs/admin-guide/index.rst b/docs/admin-guide/index.rst
> index 54e6f65de347..e7895ee95001 100644
> --- a/docs/admin-guide/index.rst
> +++ b/docs/admin-guide/index.rst
> @@ -5,4 +5,5 @@ Admin Guide
> =20
>  .. toctree::
>     introduction
> +   uefi-secure-boot
>     microcode-loading
> diff --git a/docs/admin-guide/uefi-secure-boot.rst b/docs/admin-guide/uef=
i-secure-boot.rst
> new file mode 100644
> index 000000000000..0e0f50143892
> --- /dev/null
> +++ b/docs/admin-guide/uefi-secure-boot.rst
> @@ -0,0 +1,134 @@
> +.. SPDX-License-Identifier: CC-BY-4.0
> +
> +UEFI Secure Boot
> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> +
> +UEFI Secure Boot is a verification mechanism, intended to ensure that on=
ly
> +code trusted by the platform can run.  This is to prevent malicious code=
 from
> +hijacking the system.  Secure Boot requires that all privileged code be
> +signed, and that there is a trust relationship with the platform; i.e. c=
ode
> +which is not signed by a key enrolled in platform must not run privilege=
d.
> +
> +Within the Xen architecture, Xen, the :term:`control domain` and
> +:term:`hardware domain` share responsibility for running and administeri=
ng the
> +platform.  This makes their kernels privileged as far as Secure Boot is
> +concerned.
> +
> +When Secure Boot is active in the platform, privileged code is required =
to not
> +run any untrusted code (i.e. not run any code for which there is not a g=
ood
> +signature), and is required not to allow this restriction to be bypassed
> +(e.g. by command line request).
> +
> +
> +Support in Xen
> +--------------
> +
> +There are multiple ways to achieve this security goal, with differing
> +tradeoffs for the eventual system.
> +
> +On one end of the spectrum is the Unified Kernel Image.  e.g. Xen is bun=
dled
> +with the dom0 kernel and init-ramdisk, with an embedded command line, an=
d with
> +livepatching and kexec compiled out, and suitably signed.  The signature=
 is
> +checked by the bootloader and, as this covers all the privileged code, X=
en
> +doesn't need to perform further checks itself.
> +
> +On the other end of the spectrum is maintaining the features of existing
> +deployments.  e.g. Xen needs signature checking capabilities for the dom0
> +kernel, livepatches and kexec kernels, and needs to allow the use of safe
> +command line options while disallowing unsafe ones.
> +
> +It is important to remember that Xen is one piece of the larger platform,
> +where every piece depends on the correct functioning of all earlier piec=
es.  A
> +product supporting Secure Boot requires a holistic approach involving all
> +components in the system.  It is not sufficient to consider Xen in isola=
tion.

This paragraph is a bit vague. Maybe include (repeat) that it includes
any privileged domain's kernel, but also bootloader(s)? Or simply remove
it as it doesn't add much give the introduction section explaining this
already.

> +
> +.. TODO: Move "In Progress" tasks here as they become ready
> +
> +Security Scope
> +--------------
> +
> +Vulnerabilities impacting Secure Boot require a fixed component to be pr=
oduced
> +and distributed, the vulnerable component to be revoked, and the revocat=
ion
> +distributed to platforms.
> +
> +The following principles and guidelines indicate where Secure Boot diffe=
rs
> +from more traditional security models, and the situations in which extra
> +remediation may be necessary.
> +
> +Principles
> +^^^^^^^^^^
> +
> + * Privileged code shall include Xen and the kernel(s) of the control and
> +   hardware domain (both, if they're split).  While there is a privilege=
 split
> +   here in Xen's regular security model, they are equal from Secure Boot=
's
> +   point of view.
> +
> + * Root or ADMIN in userspace is unprivileged from Secure Boot's point of
> +   view, and must not be able to alter the enforcement policy or load un=
signed
> +   code even by e.g. editing a configuration file and rebooting.
> +
> +Within Scope
> +^^^^^^^^^^^^
> +
> +The following types of issue require remediation and revocation of vulne=
rable
> +binaries.
> +
> + * Any failure to apply enforcements even against traditionally-privileg=
ed
> +   userspace, including failure to authenticate new code to run and fail=
ure to
> +   handle revocations properly.
> +
> + * Any Out-of-Bounds write capable of altering the enforcement policy, or
> +   capable of bypassing enforcement, e.g. by corrupting the running code.
> +
> +Out of Scope
> +^^^^^^^^^^^^
> +
> +While typically a security issue in their own rights, these issues do not
> +constitute a Secure Boot vulnerability, and do not require special
> +remediation.
> +
> + * Denial of Service vulnerabilities.
> +
> + * Out-of-Bounds reads.

Maybe more generic "Information disclosure" or "Information leak"?

> +
> +The Xen Security Team will endeavour to produce XSAs for all violations =
of
> +this security policy, including identifying them specifically as requiri=
ng
> +further remediation by downstreams.
> +
> +
> +In Progress
> +-----------
> +
> +.. warning::
> +
> +   The following work is still in progress.  It is provisional, and not
> +   security supported yet.
> +
> +
> +Secure Boot Advanced Targeting
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +SBAT is a recovation scheme for Secure Boot enabled components, using a
> +generation based scheme.  See `Shim SBAT.md
> +`_ for full details.
> +
> +Upstream Xen provides the infrastructure to embed SBAT metadata in
> +``xen.efi``, but does not maintain a generation number itself.  Downstre=
ams
> +are expected to maintain their own generation numbers.
> +
> +
> +Lockdown Mode
> +^^^^^^^^^^^^^
> +
> +A mode which causes the enforcement of the properties necessary to confo=
rm to
> +the Secure Boot specification.  Lockdown Mode is forced active when Secu=
re
> +Boot is active in the platform, but may be activated independently too f=
or
> +development purposes with the ``lockdown`` command line option.
> +
> +TODO
> +^^^^
> +
> + * Command Line
> + * Livepatching
> + * Kexec
> + * Userspace hypercalls
> --=20
> 2.39.5
>=20

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

--xqmz7RRHR2+q0XuL
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmhKhs4ACgkQ24/THMrX
1ywxDwf9HAYoVwQ+eCCjrIv575CkCXg5kYq9FiJHNc7Fe3nQZLvX1dl6TbjQPcb4
JF00j1Ldh2hNZnQBxfu4dnJ+ItyKSCAXlVq7JhI04l23XB0Kn8pUhoVvz43jOI0D
wUnnhx6LEryp57FYd0uvnN8ypunWz9A3h+HaCBbRxuGJSpqS6hduYOYmGTfGs0kN
l4xhGHCrNpEqUW8iTU2XFnJr4TVhmWDso0yBKkk0wNpJpqRlNXoFgAxmtLoVsXjq
0SiCTtkhghcw2xDAQCB2yAfBFpovVuRhFfgiDL5FBVEg2RgDxRuCHqRBDJ9svT2+
BrWLpV7Ig6XKp5kZZpyITtRGRh3pww==
=LQgl
-----END PGP SIGNATURE-----

--xqmz7RRHR2+q0XuL--


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 07:52:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 07:52:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012479.1390935 (Exim 4.92)
	(envelope-from )
	id 1uPcjt-0001SJ-S7; Thu, 12 Jun 2025 07:52:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012479.1390935; Thu, 12 Jun 2025 07:52:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPcjt-0001SC-PV; Thu, 12 Jun 2025 07:52:45 +0000
Received: by outflank-mailman (input) for mailman id 1012479;
 Thu, 12 Jun 2025 07:52: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 1uPcjt-0001S6-2R
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 07:52:45 +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 379b7706-4762-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 09:52:41 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3a4f379662cso561396f8f.0
 for ; Thu, 12 Jun 2025 00:52:41 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-313c1b5efa2sm829233a91.41.2025.06.12.00.52.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 00:52:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 379b7706-4762-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749714761; x=1750319561; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=9NCPsqwJKJYtAS51CI1sh85u3p3RB5+6ZXXom88mXuA=;
        b=Ra0QR/uhQ39JJ2VzjokEMV0yGCMqk9PigKno03EJhKP6/35jDxS74PWmNv0YqNHH98
         aNuQ4QUKM02ILTHi3xTGYTKaod0A0t/8ZZCAupVKxd9pDXqFpwYkdRaUNgSNnQzKXvzt
         l5eTQutcFaWsLkQBwpbU0bMgW0KIFmF1/Bs8zgyVnZyXTio0Gnc07mo6ySh5+ii9IiN7
         MmNUVyfo4Ew6f5A8fLywBrn60uMwNNV0MzYf/NYjRVPNLhQfLVpI+jDE13/oXhoiqxK0
         t9ZoRFglTKZoY8owIceZWH5ZurgawvofyxwtmTsfgdSqD6QpbfsShGmcdKe0Yji5WbOK
         4PEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749714761; x=1750319561;
        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=9NCPsqwJKJYtAS51CI1sh85u3p3RB5+6ZXXom88mXuA=;
        b=fZ8uWNbTz2qkqFNdtH69KlJj5JJWjQ0XwAMslIG2vm+DgyXi+l9sloqUNY2mbQKVK5
         ORMQuJ4K4DaZwtDxJEro0kzCo3q6FlNUrVhPq4Fai7MBnc0TuvdBoQl5DdYoz6Z2sEIn
         FaO6qiGC3N/lt609XgSCR5DBbPtjX+cQUh8NdbEhGoQiNiqWGmeRvrl7IYSU/+n45RqI
         B61vy266Js/HFuV6ryL/FKjYyM6eSaLos0OuI0CIMroaACEyt1IrgrfyOWZtAwQ4EBlz
         Bi4Pcw8yEugRImLUT2xEe63Y7nfivMXUUy3K9dxOddpcyqI97N0t496ZhIE0eigvqRw2
         EP9Q==
X-Forwarded-Encrypted: i=1; AJvYcCXqS2YT/jcFR4kcd7HiE3wkEngOX3jCWaH2Apyy+0NRsYYPFt+ibkQjKtHR3dUMl13afN4dYsUJQ9s=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzIjcV8PNnikDGdJxhP0Vql6ZzwtLV9ERjUJNI4By0BmqjWqp+y
	iZsoSQxy3jnec67PZX6/0XgTM5slm1NKCxRtNTvv+djE+HjKSx97f2HAyaGbYfa1Mg==
X-Gm-Gg: ASbGncvg5HlAWzHMxOT2pRgxBN+0h+iyWRqg/LrqVcxDG3rhWSZtOw72q2iiwmZlKHz
	FQ8h+4E/c5tfbv01bz2CaheFdLTNkSzr+7iOavkYVyOy7nwT46HFXbMEaeiync4Ze20gZBWKCp3
	POjExl8H3wz9kX+29yAztx0huT0UO7Ytsvhf6DRDzQpU/yXrGwfSF0xLMg0TOUEsrbHDuv6Byoe
	S2mvgWugoLMX5yJuHgtLpRFDFgeRUddonV3TbQH6DMeEPAdB4GjT7ErqfgNG4NSmJahJh0kJ0u7
	9AmT8MhBYPd3SezVq8ANpEKqNQmls0WPUbtDtYo2EfXUAvdb3KnsMT0hUc6YWwFc5k3QG7Qarmv
	HVe7lZ1WbCWzlvmcTbq5NvUdvvdCXIQ0EoCu/7y+kSGK5H2I=
X-Google-Smtp-Source: AGHT+IFIv9SxT9/QQGvFoYRUwswy5n0Y7fat8/JkNB8D4Bi3XYAiIjjJPJd02wBVWgZ4BR51dEbz5Q==
X-Received: by 2002:a05:6000:40df:b0:3a4:dd8e:e16d with SMTP id ffacd0b85a97d-3a56133d9afmr1516515f8f.15.1749714760812;
        Thu, 12 Jun 2025 00:52:40 -0700 (PDT)
Message-ID: <805abeee-0cad-4cc9-88ae-77e4c1e23fac@suse.com>
Date: Thu, 12 Jun 2025 09:52:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/4] xsm/silo: Support hwdom/control domains
To: Jason Andryuk 
Cc: "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org
References: <20250610225737.469690-1-jason.andryuk@amd.com>
 <20250610225737.469690-3-jason.andryuk@amd.com>
 <0f47268e-0674-46e7-bfd4-8a395ee1ddf6@suse.com>
 <6cc69b45-7347-4250-ab32-a1e2857b7d23@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: <6cc69b45-7347-4250-ab32-a1e2857b7d23@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.06.2025 06:20, Jason Andryuk wrote:
> On 2025-06-11 09:17, Jan Beulich wrote:
>> On 11.06.2025 00:57, Jason Andryuk wrote:
>>> In a disaggregated environment, dom0 is split into Control, Hardware,
>>> and Xenstore domains, along with domUs.  The is_control_domain() check
>>> is not sufficient to handle all these cases.  Add is_priv_domain() to
>>> support allowing for the various domains.
>>>
>>> The purpose of SILO mode is to prevent domUs from interacting with each
>>> other.  But dom0 was allowed to communicate with domUs to provide
>>> services.  As the disaggregation of dom0, Control, Hardware and Xenstore
>>> are all service domains that need to communicate with other domains.
>>>
>>> To provide xenstore connections, the Xenstore domain must be allowed to
>>> connect via grants and event channels.  Xenstore domain must also be
>>> allowed to connect to Control and Hardware to provide xenstore to them.
>>
>> Are you suggesting that SILO at present is incompatible with a Xenstore
>> domain? silo_mode_dom_check() in its original form has no special
>> precautions, after all.
> 
> Yes, it is incompatible with the current silo_mode_dom_check().  Only 
> Control domain is allowed to use grants and event channels with a domU. 
> A Xenstore domain would be denied.
> 
> Xenstore stubdom only exists for x86 today.  My limited attempts to run 
> xenstored in an dedicated Xenstore ARM Linux domain have failed.

This may want sorting independently first. Once sorted, the requirements
here may become more clear.

>>> Hardware domain will provide PV devices to domains, so it must be
>>> allowed to connect to domains.
>>
>> As a built-in policy, isn't this already going too far? There could
>> conceivably be configurations with only pass-through devices in use, in
>> which case neither grants nor the event channels operations intercepted
>> by SILO would be required.
> 
> Such a domain wouldn't have any PV devices configured?

Indeed, that's my point: Why would Hardware then have a need to be
allowed to connect to domains.

>  I don't think this changes anything compared to today.

I don't think I see what you mean to tell me with this. What we're
discussing here is the effect of the separation you're suggesting,
which necessarily is different from what we have today.

> Both sides need to be configured and opt-in.  Hardware is a system 
> domain, so it should be possible to allow grants and event channels. 
> But they won't be used unless configured.

"Won't be used" isn't enough, imo. Isn't disaggregation about proper
isolation, i.e. to guarantee that unwanted interactions can't occur?

>>> That leaves Control.  Xenstore and Hardware would already allow access
>>> to Control, so it can obtain services that way.  Control should be
>>> "privileged", which would mean it can make the connections.  But with
>>> Xenstore and Hardware providing their services to domUs, there may not
>>> be a reason to allow Control to use grants or event channels with domUs.
>>> Still, Control is privileged, so it should be allowed to do something if
>>> it chooses.  Establishing a grant, or event channel requires action on
>>> both sides, so allow for the possibility.  This does open up an argo
>>> wildcard ring from domUs, FWIW.
>>
>> Along the lines of my reply to patch 1, I think Hardware and Control
>> need to have a pretty strong boundary between them. It's hard to see,
>> for example, whether grant map/copy/transfer would indeed make sense
>> between the two.
> 
> The Hardware domain might provide a PV device to Control?
> 
> I've tested removing control:
> static bool is_priv_domain(const struct domain *d)
> {
>      return is_xenstore_domain(d) || is_hardware_domain(d);
> }
> 
> And that works in my limited ARM dom0less testing.  The toolstack isn't 
> really exercised in that case.  It seems strange that the privileged 
> control domain is *not* allowed though.

With the intended separation, there's (imo) not going to be any
all-mighty domain anymore. Neither Hardware nor Control.

>> Similarly I'm not convinced a strong boundary isn't also needed
>> between Xenstore and Hardware.
> 
> If hardware is providing PV devices to domains, it will need access to 
> Xenstore.  I don't see how you can get around it.
> 
> I tried to explain this in the first paragraph.  SILO's purpose was to 
> isolate domUs from each other, but allow it to access dom0.  dom0 
> embodies the control, hardware, and xenstore capabilities.  So as a 
> first approximation, each of Control, Hardware, and Xenstore should be 
> allowed to communicate with domUs.

Yes. Yet what to permit between the three special entities is far less
clear. Hence why I'm unconvinced this can be expressed by SILO, and
would rather require Flask.

> domUs needs to communicate with Xenstore and Hardware for PV devices.
> 
> Xenstore provides Xenstore access to Hardware.
> 
> Control would want Xenstore access.
> 
> I don't know if this helps, but here's a table:
> 
>      | CTL | HW  | XS  | domU
> ----------------------------
> CTL |     |  ?  |  y  |  ?
> HW  |  ?  |     |  y  |  y
> XS  |  y  |  y  |     |  y
> domU|  ?  |  y  |  y  |  x
> 
> Control and Hardware would be y if we allow PV devices
> 
> Control and domUs - I don't have an immediate rational for them.  Except 
> that Control is privileged.  I've been running xenconsoled in Hardware. 
> If xenconsoled is in Control, then access would be required.

Perhaps some clarification is first need about what Control really is
(and is not). It is sole the domain to create other domains. But beyond
that things become unclear. E.g. xenconsoled may not belong into either
Hardware or Control.

>>> --- a/xen/xsm/silo.c
>>> +++ b/xen/xsm/silo.c
>>> @@ -20,6 +20,12 @@
>>>   #define XSM_NO_WRAPPERS
>>>   #include 
>>>   
>>> +static bool is_priv_domain(const struct domain *d)
>>> +{
>>> +    return is_xenstore_domain(d) || is_hardware_domain(d) ||
>>> +           is_control_domain(d);
>>> +}
>>
>> This construct expands to two evaluate_nospec(), which likely isn't
>> wanted. Some open-coding may be pretty much unavoidable here.
> 
> Thanks, yes, good point.
> 
>> (I'm
>> surprised it's not three, i.e. I find it odd that is_xenstore_domain()
>> doesn't also use that guard.)
> 
> It looks okay to me.  There were only 2 uses until I added a 3rd in the 
> dom0less code.  The XSM check has evaluate_nospec() and the other 2 uses 
> aren't security critical - Setting a domain info flag, and __init code 
> for dom0less.  Maybe moving the evaluate_nospec() would be safer in case 
> use grows in the future, but it looks okay to me today.

When some of the hardening was first introduced, actual use sites were
indeed taken into account. That wasn't quite right though, I think. Any
such construct ought to be safe to use anywhere. For uses with clearly
no concerns towards speculative abuse, a 2nd lightweight form of such
constructs should then exist, imo. As to your use of "security critical":
I'm not convinced you what mean is covering the potential of speculative
abuse of involved code paths.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 07:59:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 07:59:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012489.1390945 (Exim 4.92)
	(envelope-from )
	id 1uPcqY-000281-JN; Thu, 12 Jun 2025 07:59:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012489.1390945; Thu, 12 Jun 2025 07: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 1uPcqY-00027u-Gd; Thu, 12 Jun 2025 07:59:38 +0000
Received: by outflank-mailman (input) for mailman id 1012489;
 Thu, 12 Jun 2025 07: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 1uPcqX-00027o-8K
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 07:59:37 +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 2e066cbb-4763-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 09:59:34 +0200 (CEST)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-4533027c0ceso1354835e9.1
 for ; Thu, 12 Jun 2025 00:59:34 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-4532e259108sm12050725e9.32.2025.06.12.00.59.33
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Jun 2025 00:59:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2e066cbb-4763-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749715174; x=1750319974; 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=jqvGP8rNd88wpvPsifGD3kzZ7I5KmxLD3eJ7N11OFpU=;
        b=dqmhTDY0DBDZJXeDg27YOCDqHKs4bhQffseTGNnv68SmK8QLgVGqDRUHIkfedaSqG7
         ShsKYRww3nLMjyZ1C8zlzrthfOdMCnF4q/QdW0yGY0ZzgB5Udf1XT1DixiSQnR4zwFXD
         k3/+2gAIqmltj7XUSjWpQo6ZGln2WNc2At1bY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749715174; x=1750319974;
        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=jqvGP8rNd88wpvPsifGD3kzZ7I5KmxLD3eJ7N11OFpU=;
        b=B1ITKfL0NIEpSQCR3EhBA06K3j5vj6tzlrnQdSdG3V8l8wRfx5RO03O283gOCAGcqm
         nmpCsoMSZkQp4g2DTv8GEHfOOicYWv7E6GNcVLOByQ7a+yum2qC2HVYrT6B7wYs/l/g0
         8oiZz9BscMMtj0/IhjIuJNhYnyiaK56SeTAtaWCwWP+VjPQpqMwAFrXIzKPa6FJytlBC
         +uHO/NQvokGXHYK3eRyYmMrTOGy1FfD4aBBDrPqGOsaBuGXt/qDWPtJIoOjDYG2ibpPZ
         fOCXbHKzm4zB30IHe92iCa6xX9uVFoRizF21azylqobAhEZ4pLM697Mc2c4ufttfg30F
         wDdw==
X-Gm-Message-State: AOJu0Yyua97hlpL7qRe0QmU13ggsTjKq/7Zwig9SPekH5oJXFwMG6RaA
	EvxMcUptMkLxjCswbZyLWEYVdUXk6asXBBYzQTAXtLga49w/v3QTWcOvIXy2HqGLlj4=
X-Gm-Gg: ASbGnctBv/oc0oFI9mESeN5PMSPvZfNkuedRoGmzfv4l7zbDunwl/csvk+2WLr5A+IX
	2AChHmkd4Q+JIt2e0BDa564txJq9AjHcdsWCnvMlwREdq7LSchS/jGxtuNvdMkLVIvIBvOfQ90U
	LnRHJgbzXItNC8lpJktOAs5eppXSQjmubh7lXPPW8Otf/12dDjp00KzVIDCvYkFl7jwRsq8yOSr
	xi4XSWHvmpfxI64RMldjnYcbM5tx3k2Wu1ydDrm9vHCKkE/IT5+LpApU0JFBMzwyQt8a0KQ1zof
	jmU97yOM3Lcie/nG460obn3XobG7Dj8KzQbYxBZ7kdKvu0ZATsMUsDH1dmREaHUw92Ly3R0KCTl
	bno0Uk9X8YTiKFPUgrMxMPT7Lq5gFrA==
X-Google-Smtp-Source: AGHT+IEz/TEyCY9kR2iaMcP0xS59EssyzTn/amKVRTSONqmA/O11pcAPf/mXChYgLD5Cspi4XUoo8g==
X-Received: by 2002:a05:600c:1d0a:b0:450:d3b9:4b96 with SMTP id 5b1f17b1804b1-4532b8c65e2mr28703185e9.13.1749715174267;
        Thu, 12 Jun 2025 00:59:34 -0700 (PDT)
Date: Thu, 12 Jun 2025 09:59:32 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Andrew Cooper 
Cc: xen-devel@lists.xenproject.org,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini ,
	Bertrand Marquis ,
	Volodymyr Babchuk 
Subject: Re: [PATCH 6/8] pdx: introduce a new compression algorithm based on
 offsets between regions
Message-ID: 
References: <20250611171636.5674-1-roger.pau@citrix.com>
 <20250611171636.5674-7-roger.pau@citrix.com>
 <8e34ac22-d05b-4ef3-9e31-6e5663cc1dc5@citrix.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Thu, Jun 12, 2025 at 09:26:25AM +0200, Roger Pau Monné wrote:
> On Wed, Jun 11, 2025 at 08:33:55PM +0100, Andrew Cooper wrote:
> > On 11/06/2025 6:16 pm, Roger Pau Monne wrote:
> > > We can discuss whether we want both the fast and the slow variants.  The
> > > slow (brute force) was added as a result of me playing with weird region
> > > layouts where the fast one didn't manage to compress, or the resulting
> > > coefficients had a poor compression ratio.  However at this point the
> > > slow variant has only proven helpful in synthetic cases, I haven't (yet?)
> > > seen a real host memory layout that would benefit from it.
> > 
> > I'm going to hold off on opinions until I've read the rest of the series.
> > 
> > One question through.  Can we round offset up to the next power of two,
> > so we can replace the divide with a shift?
> 
> I've tried to round up both offset and size, but that resulted in no
> compression in some cases.  I can try to maybe round just one of
> those?
> 
> Note that the divide is done once with offset and once with size,
> depending on the direction of the translation.  I can explore this a
> bit.

So for the 4s GNR example, rounding the offset to the nearest (lower)
power of two will result in:

PFN fast compression result diverge, expected:
 offset 0000063e80000 size 0000008300000 (91%)
got:
 offset 0000040000000 size 0000033e80000 (18%)
Ranges:
 0000000000000-0000008080000
 0000063e80000-000006be80000
 00000c7e80000-00000cfe80000
 000012be80000-0000133e80000

And that's just rounding the offset, if we then also round the size
there's no compression possible, as size would become 0x40000000 and
thus offset == size.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 08:02:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 08:02:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012495.1390955 (Exim 4.92)
	(envelope-from )
	id 1uPctZ-0004VE-2b; Thu, 12 Jun 2025 08:02:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012495.1390955; Thu, 12 Jun 2025 08: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 1uPctY-0004V7-W8; Thu, 12 Jun 2025 08:02:44 +0000
Received: by outflank-mailman (input) for mailman id 1012495;
 Thu, 12 Jun 2025 08: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 1uPctX-0004V1-QY
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 08:02:43 +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 9dea9663-4763-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 10:02:42 +0200 (CEST)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-453066fad06so4295465e9.2
 for ; Thu, 12 Jun 2025 01:02:42 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-313c1b6d4desm958345a91.47.2025.06.12.01.02.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 01:02:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9dea9663-4763-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749715362; x=1750320162; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=IGigL6h22F5ISr34Cwwks41W1bOFtfBfoLyRQxUOzbM=;
        b=LlnX8Ar1SSKVVaydC0Y878xaKmF9RoT9bu8pTReAPAALzuw4xH+OmqG3z+4esNKzSt
         X1OZG0wD+8L0SndQFXQL4NHmE4M2UKB9GmCniVlGT4H6kwiVJUe915xA5hNmZIXUieNS
         GFnujJQ6od4qlOPuBOjtPfN3OP1xL7D3wnZrWozTmXXr3xHgoFDwh4NutMifv/imgUA5
         dvhnm136hfRsVOUS7lVYVAt62AruB3u3o1xXWhUDKTLWRW33hP39WAg6BTrpq2DF1hyo
         RwModjjMINV+1o+QcunqWM3qYObeA9NpeW4dugbmy8da539G+N/2E0dZb5D+YjISwA65
         KQiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749715362; x=1750320162;
        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=IGigL6h22F5ISr34Cwwks41W1bOFtfBfoLyRQxUOzbM=;
        b=rTuGzlz0uNZifI2z32n69plNohzg7YxWkcNEBz8JRVqtS8DGij0QxL5pKU1LOHDyrK
         GRzwtPn6IluA2LGYRrO3cQvXbWXbsNPlGWOepMfodFfH+KXWcaHpEtAOZp5GxTAjNXYy
         Gc2AFRNq6sCYjm14kbofFm2rgEjVP1E/f4yYl1H1bhzdKNiHVLMdMpZB231mwHXZuL+j
         cINaI1MHNjSE28WLiELBMAknuYMkPCRB4spqjv1nNfIG5Ayq4hMlrvglI6wMX7VE/8dm
         bp9ryCTBhOw7841tBhzL7mudgYeXvP1fCu9Uqoy6dO9z6cTg0e/4ZEfH/uX+4e9KeHHK
         R7Fg==
X-Gm-Message-State: AOJu0YxCGZEUcLk4CG6J99fbrr/mYGNpaEy7No4ew9Rj1OTuG1Sv0AiZ
	87g2ld1l6zAVinxlqO3Agb7v1yrtyq1CvQM/ZPIhXnVf2hYxaOBP2T0BKHBTVBK1Pg==
X-Gm-Gg: ASbGnctQeUYCbJ+EPtbrFzwv08HyVr3UnEUHgiy9PAMvmc83mID0NCUwZw+gQAJRZ1x
	vPh+wLewLl3XEUlsyLYmdxHYSh03JBPvhPcuj+IA8mnSE0m6TuthYSgfnntyJqrB9VOaTFRgMwy
	sJ8EHy+LX0zlf3oJXmAXF6mxbRy7T5SO2bFYcFZVb531DiIQs6AGsr5LkrEMKVZQ/BTWuStOb4R
	Ae/XJfnHLkSkdt3knQaZ60JU/aRs3yqzlNiUGcRQk0OalbgB9PeQFozysLr9Aokmh4QDmhsqQsi
	/BFCuOqTvl3E78rOi8u/9lJHivazKoDD1NLzrbB5ZFdYRa+np1dFtrwxLjuz/RWMZlYuRPDg8T2
	ql90IdOzTdtGW3m1zh7jnchp47evpC2HDK8irXb73Hs59ZCv7acjF1slczw==
X-Google-Smtp-Source: AGHT+IEHhlaRmU89cM/aXPpZoPGfqzlxfbFsHVaLaRUTdiWtCrUFyJLQPhqgz1P+acUOZjX10Ao1uw==
X-Received: by 2002:a05:6000:2dc9:b0:3a5:3af1:e21b with SMTP id ffacd0b85a97d-3a5586f3433mr4961781f8f.47.1749715362089;
        Thu, 12 Jun 2025 01:02:42 -0700 (PDT)
Message-ID: <031338df-8f6b-4c6f-86b9-aa0b7c808bfc@suse.com>
Date: Thu, 12 Jun 2025 10:02:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 04/22] x86/boot/slaunch-early: implement early
 initialization
To: Sergii Dmytruk 
Cc: xen-devel@lists.xenproject.org, Andrew Cooper
 , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , "Daniel P. Smith" ,
 trenchboot-devel@googlegroups.com, ross.philipson@oracle.com
References: 
 <16a544876163afece619d50f80869aaacc9c797c.1748611041.git.sergii.dmytruk@3mdeb.com>
 <5792bec7-cd2f-4d27-aa3b-f417b07c8ea8@oracle.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.06.2025 00:14, Sergii Dmytruk wrote:
> On Tue, Jun 03, 2025 at 09:17:29AM -0700, ross.philipson@oracle.com wrote:
>>> +static inline void *txt_init(void)
>>> +{
>>> +    void *txt_heap;
>>> +
>>> +    /* Clear the TXT error register for a clean start of the day. */
>>> +    txt_write(TXTCR_ERRORCODE, 0);
>>> +
>>> +    txt_heap = _p(txt_read(TXTCR_HEAP_BASE));
>>> +
>>> +    if ( txt_os_mle_data_size(txt_heap) < sizeof(struct txt_os_mle_data) ||
>>> +         txt_os_sinit_data_size(txt_heap) < sizeof(struct txt_os_sinit_data) )
>>> +        txt_reset(SLAUNCH_ERROR_GENERIC);
>>
>> I know the list of error codes pulled in are from the patches for Linux
>> Secure Launch which seems right. The Xen work is free to add more specific
>> error codes e.g. somewhere like here. We could even consider using regions
>> in the vendor error code space for different things like generic errors vs
>> architecture specific ones vs etc.
> 
> I think some codes were already added and this is the only place where
> SLAUNCH_ERROR_GENERIC is used, not really sure why, will add a couple
> more.  By the way, the new errors were inserted in the middle making
> about half of the errors out of sync with Linux, should Xen and Linux be
> in sync?

As the uses isolated to Xen and Linux respectively, or are the values
propagated between the two in some way? In the former case there's no
need for them to stay in sync, I think. Whereas in the latter case them
staying in sync would want enforcing somehow, if at all possible.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 08:12:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 08:12:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012500.1390966 (Exim 4.92)
	(envelope-from )
	id 1uPd2c-0006S9-UN; Thu, 12 Jun 2025 08:12:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012500.1390966; Thu, 12 Jun 2025 08: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 1uPd2c-0006S2-RP; Thu, 12 Jun 2025 08:12:06 +0000
Received: by outflank-mailman (input) for mailman id 1012500;
 Thu, 12 Jun 2025 08: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 1uPd2b-0006Rv-Fo
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 08:12:05 +0000
Received: from perceval.ideasonboard.com (perceval.ideasonboard.com
 [213.167.242.64]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ec1a7ca0-4764-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 10:12:03 +0200 (CEST)
Received: from [192.168.88.20] (91-158-153-178.elisa-laajakaista.fi
 [91.158.153.178])
 by perceval.ideasonboard.com (Postfix) with ESMTPSA id 868E8D6;
 Thu, 12 Jun 2025 10:11:52 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ec1a7ca0-4764-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;
	s=mail; t=1749715913;
	bh=8WwmhFtL9eosA22O6PZS8QonHwy8kOwjvtU9HLAd/Mk=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=s1CohyRjx44OEVAmWk98stT2zZMSlbEy73AVELxdX2h5KRmV+rS1QwaBu+QfSA1qN
	 OhCbnI7kO8KcLMT7lrLn06Uhsf9CiF7Vs4jlCz3vlMPk6QDjNsDY5H17EEyIiwIUrs
	 /1X9kTXxoJNFavlSTwvk0QOIm9p0Cnp4fXSH0SQ4=
Message-ID: 
Date: Thu, 12 Jun 2025 11:11:57 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 01/25] drm/dumb-buffers: Sanitize output on errors
To: Thomas Zimmermann 
Cc: dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org,
 freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
 imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org,
 nouveau@lists.freedesktop.org, virtualization@lists.linux.dev,
 spice-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org,
 linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
 intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org,
 simona@ffwll.ch, airlied@gmail.com, mripard@kernel.org,
 maarten.lankhorst@linux.intel.com, geert@linux-m68k.org
References: <20250311155120.442633-1-tzimmermann@suse.de>
 <20250311155120.442633-2-tzimmermann@suse.de>
Content-Language: en-US
From: Tomi Valkeinen 
Autocrypt: addr=tomi.valkeinen@ideasonboard.com; keydata=
 xsFNBE6ms0cBEACyizowecZqXfMZtnBniOieTuFdErHAUyxVgtmr0f5ZfIi9Z4l+uUN4Zdw2
 wCEZjx3o0Z34diXBaMRJ3rAk9yB90UJAnLtb8A97Oq64DskLF81GCYB2P1i0qrG7UjpASgCA
 Ru0lVvxsWyIwSfoYoLrazbT1wkWRs8YBkkXQFfL7Mn3ZMoGPcpfwYH9O7bV1NslbmyJzRCMO
 eYV258gjCcwYlrkyIratlHCek4GrwV8Z9NQcjD5iLzrONjfafrWPwj6yn2RlL0mQEwt1lOvn
 LnI7QRtB3zxA3yB+FLsT1hx0va6xCHpX3QO2gBsyHCyVafFMrg3c/7IIWkDLngJxFgz6DLiA
 G4ld1QK/jsYqfP2GIMH1mFdjY+iagG4DqOsjip479HCWAptpNxSOCL6z3qxCU8MCz8iNOtZk
 DYXQWVscM5qgYSn+fmMM2qN+eoWlnCGVURZZLDjg387S2E1jT/dNTOsM/IqQj+ZROUZuRcF7
 0RTtuU5q1HnbRNwy+23xeoSGuwmLQ2UsUk7Q5CnrjYfiPo3wHze8avK95JBoSd+WIRmV3uoO
 rXCoYOIRlDhg9XJTrbnQ3Ot5zOa0Y9c4IpyAlut6mDtxtKXr4+8OzjSVFww7tIwadTK3wDQv
 Bus4jxHjS6dz1g2ypT65qnHen6mUUH63lhzewqO9peAHJ0SLrQARAQABzTBUb21pIFZhbGtl
 aW5lbiA8dG9taS52YWxrZWluZW5AaWRlYXNvbmJvYXJkLmNvbT7CwY4EEwEIADgWIQTEOAw+
 ll79gQef86f6PaqMvJYe9QUCX/HruAIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRD6
 PaqMvJYe9WmFD/99NGoD5lBJhlFDHMZvO+Op8vCwnIRZdTsyrtGl72rVh9xRfcSgYPZUvBuT
 VDxE53mY9HaZyu1eGMccYRBaTLJSfCXl/g317CrMNdY0k40b9YeIX10feiRYEWoDIPQ3tMmA
 0nHDygzcnuPiPT68JYZ6tUOvAt7r6OX/litM+m2/E9mtp8xCoWOo/kYO4mOAIoMNvLB8vufi
 uBB4e/AvAjtny4ScuNV5c5q8MkfNIiOyag9QCiQ/JfoAqzXRjVb4VZG72AKaElwipiKCWEcU
 R4+Bu5Qbaxj7Cd36M/bI54OrbWWETJkVVSV1i0tghCd6HHyquTdFl7wYcz6cL1hn/6byVnD+
 sR3BLvSBHYp8WSwv0TCuf6tLiNgHAO1hWiQ1pOoXyMEsxZlgPXT+wb4dbNVunckwqFjGxRbl
 Rz7apFT/ZRwbazEzEzNyrBOfB55xdipG/2+SmFn0oMFqFOBEszXLQVslh64lI0CMJm2OYYe3
 PxHqYaztyeXsx13Bfnq9+bUynAQ4uW1P5DJ3OIRZWKmbQd/Me3Fq6TU57LsvwRgE0Le9PFQs
 dcP2071rMTpqTUteEgODJS4VDf4lXJfY91u32BJkiqM7/62Cqatcz5UWWHq5xeF03MIUTqdE
 qHWk3RJEoWHWQRzQfcx6Fn2fDAUKhAddvoopfcjAHfpAWJ+ENc7BTQROprNHARAAx0aat8GU
 hsusCLc4MIxOQwidecCTRc9Dz/7U2goUwhw2O5j9TPqLtp57VITmHILnvZf6q3QAho2QMQyE
 DDvHubrdtEoqaaSKxKkFie1uhWNNvXPhwkKLYieyL9m2JdU+b88HaDnpzdyTTR4uH7wk0bBa
 KbTSgIFDDe5lXInypewPO30TmYNkFSexnnM3n1PBCqiJXsJahE4ZQ+WnV5FbPUj8T2zXS2xk
 0LZ0+DwKmZ0ZDovvdEWRWrz3UzJ8DLHb7blPpGhmqj3ANXQXC7mb9qJ6J/VSl61GbxIO2Dwb
 xPNkHk8fwnxlUBCOyBti/uD2uSTgKHNdabhVm2dgFNVuS1y3bBHbI/qjC3J7rWE0WiaHWEqy
 UVPk8rsph4rqITsj2RiY70vEW0SKePrChvET7D8P1UPqmveBNNtSS7In+DdZ5kUqLV7rJnM9
 /4cwy+uZUt8cuCZlcA5u8IsBCNJudxEqBG10GHg1B6h1RZIz9Q9XfiBdaqa5+CjyFs8ua01c
 9HmyfkuhXG2OLjfQuK+Ygd56mV3lq0aFdwbaX16DG22c6flkkBSjyWXYepFtHz9KsBS0DaZb
 4IkLmZwEXpZcIOQjQ71fqlpiXkXSIaQ6YMEs8WjBbpP81h7QxWIfWtp+VnwNGc6nq5IQDESH
 mvQcsFS7d3eGVI6eyjCFdcAO8eMAEQEAAcLBXwQYAQIACQUCTqazRwIbDAAKCRD6PaqMvJYe
 9fA7EACS6exUedsBKmt4pT7nqXBcRsqm6YzT6DeCM8PWMTeaVGHiR4TnNFiT3otD5UpYQI7S
 suYxoTdHrrrBzdlKe5rUWpzoZkVK6p0s9OIvGzLT0lrb0HC9iNDWT3JgpYDnk4Z2mFi6tTbq
 xKMtpVFRA6FjviGDRsfkfoURZI51nf2RSAk/A8BEDDZ7lgJHskYoklSpwyrXhkp9FHGMaYII
 m9EKuUTX9JPDG2FTthCBrdsgWYPdJQvM+zscq09vFMQ9Fykbx5N8z/oFEUy3ACyPqW2oyfvU
 CH5WDpWBG0s5BALp1gBJPytIAd/pY/5ZdNoi0Cx3+Z7jaBFEyYJdWy1hGddpkgnMjyOfLI7B
 CFrdecTZbR5upjNSDvQ7RG85SnpYJTIin+SAUazAeA2nS6gTZzumgtdw8XmVXZwdBfF+ICof
 92UkbYcYNbzWO/GHgsNT1WnM4sa9lwCSWH8Fw1o/3bX1VVPEsnESOfxkNdu+gAF5S6+I6n3a
 ueeIlwJl5CpT5l8RpoZXEOVtXYn8zzOJ7oGZYINRV9Pf8qKGLf3Dft7zKBP832I3PQjeok7F
 yjt+9S+KgSFSHP3Pa4E7lsSdWhSlHYNdG/czhoUkSCN09C0rEK93wxACx3vtxPLjXu6RptBw
 3dRq7n+mQChEB1am0BueV1JZaBboIL0AGlSJkm23kw==
In-Reply-To: <20250311155120.442633-2-tzimmermann@suse.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi,

On 11/03/2025 17:47, Thomas Zimmermann wrote:
> The ioctls MODE_CREATE_DUMB and MODE_MAP_DUMB return results into a
> memory buffer supplied by user space. On errors, it is possible that
> intermediate values are being returned. The exact semantics depends
> on the DRM driver's implementation of these ioctls. Although this is
> most-likely not a security problem in practice, avoid any uncertainty
> by clearing the memory to 0 on errors.
> 
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/drm_dumb_buffers.c | 40 ++++++++++++++++++++++--------
>  1 file changed, 29 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dumb_buffers.c b/drivers/gpu/drm/drm_dumb_buffers.c
> index 70032bba1c97..9916aaf5b3f2 100644
> --- a/drivers/gpu/drm/drm_dumb_buffers.c
> +++ b/drivers/gpu/drm/drm_dumb_buffers.c
> @@ -99,7 +99,30 @@ int drm_mode_create_dumb(struct drm_device *dev,
>  int drm_mode_create_dumb_ioctl(struct drm_device *dev,
>  			       void *data, struct drm_file *file_priv)
>  {
> -	return drm_mode_create_dumb(dev, data, file_priv);
> +	struct drm_mode_create_dumb *args = data;
> +	int err;
> +
> +	err = drm_mode_create_dumb(dev, args, file_priv);
> +	if (err) {
> +		args->handle = 0;
> +		args->pitch = 0;
> +		args->size = 0;
> +	}
> +	return err;
> +}
> +
> +static int drm_mode_mmap_dumb(struct drm_device *dev, struct drm_mode_map_dumb *args,
> +			      struct drm_file *file_priv)
> +{
> +	if (!dev->driver->dumb_create)
> +		return -ENOSYS;
> +
> +	if (dev->driver->dumb_map_offset)
> +		return dev->driver->dumb_map_offset(file_priv, dev, args->handle,
> +						    &args->offset);
> +	else
> +		return drm_gem_dumb_map_offset(file_priv, dev, args->handle,
> +					       &args->offset);
>  }
>  
>  /**
> @@ -120,17 +143,12 @@ int drm_mode_mmap_dumb_ioctl(struct drm_device *dev,
>  			     void *data, struct drm_file *file_priv)
>  {
>  	struct drm_mode_map_dumb *args = data;
> +	int err;
>  
> -	if (!dev->driver->dumb_create)
> -		return -ENOSYS;
> -
> -	if (dev->driver->dumb_map_offset)
> -		return dev->driver->dumb_map_offset(file_priv, dev,
> -						    args->handle,
> -						    &args->offset);
> -	else
> -		return drm_gem_dumb_map_offset(file_priv, dev, args->handle,
> -					       &args->offset);
> +	err = drm_mode_mmap_dumb(dev, args, file_priv);
> +	if (err)
> +		args->offset = 0;
> +	return err;
>  }
>  
>  int drm_mode_destroy_dumb(struct drm_device *dev, u32 handle,

Reviewed-by: Tomi Valkeinen 

 Tomi



From xen-devel-bounces@lists.xenproject.org Thu Jun 12 08:21:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 08:21:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012508.1390976 (Exim 4.92)
	(envelope-from )
	id 1uPdBS-0008Hk-OM; Thu, 12 Jun 2025 08:21:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012508.1390976; Thu, 12 Jun 2025 08:21:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPdBS-0008Hd-LE; Thu, 12 Jun 2025 08:21:14 +0000
Received: by outflank-mailman (input) for mailman id 1012508;
 Thu, 12 Jun 2025 08:21: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 1uPdBR-0008GK-DY
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 08:21:13 +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 2c79d626-4766-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 10:21:02 +0200 (CEST)
Received: from BN9PR03CA0488.namprd03.prod.outlook.com (2603:10b6:408:130::13)
 by MN6PR12MB8591.namprd12.prod.outlook.com (2603:10b6:208:471::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.19; Thu, 12 Jun
 2025 08:20:56 +0000
Received: from MN1PEPF0000F0E3.namprd04.prod.outlook.com
 (2603:10b6:408:130:cafe::2d) by BN9PR03CA0488.outlook.office365.com
 (2603:10b6:408:130::13) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.35 via Frontend Transport; Thu,
 12 Jun 2025 08:20:55 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 MN1PEPF0000F0E3.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.8835.15 via Frontend Transport; Thu, 12 Jun 2025 08:20:55 +0000
Received: from localhost (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 Jun
 2025 03:20:53 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2c79d626-4766-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=JG9kry2B2NJCcuz1n+CeetTfRr26abpoK80IscCi/b8ehPGCvWCzx+GlDN+/jkSVmbIhSuggb/jGVv+3j3PpGn4dv8PjB+6xbDVj5+lbG0o/Q7VDcvZxXiZOWuLFmG3YM3+Jd4W6gb5gAXAGtY/H2C4nRv5FOBdBd9y7Fda5qIy7FrljSXNaM7M0MaPOf8TAU22w4v7GZTGVa+NijS7rZe77E3yq/O04wmGMla1o8+AXM+hbHWqfwOiwqrq3wOweDN+hIahEoTgJQzuTFk9O8YmMyB9sKEOMvsq+/XemSUUA80okwgMOmTgCPQM3ulFvmbNDw9258AEFt53cyhYXig==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=jewQKCz7Z4tAbpLWHCuGD1C9deOuDBXm7aNlPx1tB8U=;
 b=yQNpF2B3ir/WkiY5al1fzxU4HwB6Q8HWYlDIK+i6cMHEUasmO58mLWTSpnROgbhZU96OCni7XkANGRmrS5AuXA2RVtnhNQD3m8MuAtQ4QeHvw3m7JzoNuSgRNEelz8HIKZ+LGK2SAoSi9pMyv7OhX+eaOsqwxXBw0bMbV+kIl0FFeFtbqcoCZH1/Ru3C+DuuzfCAYb5SnIqAQowkMMIY1n0TB4i3e6DppLVVkrBUpyaoVcpAaQg3GEjHLVEXbIkThhYt57S+XQPcmn/qYAXoRH3yfEZoWm2GosregItlI5fkd0dAk7WXoFcbKe4/4ibGB4LYQJxF26JvL3dMIIFFSA==
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=jewQKCz7Z4tAbpLWHCuGD1C9deOuDBXm7aNlPx1tB8U=;
 b=nQIEQkoj9uCWA3AAFcM0C4bNnRB5sXzr/isEqqwyfndHKIAr9s7eSfV+vUNXIJC4IND71LK2v3Bl+VxjjPf43WLNtleJ9sDuDanPJNkzDtiE2ZYq67KvUVGtC9D4eYNjdxrYEJ2jXwhsodWX3QuBZSIejWtfPd7gWmjCRn6GDzU=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 12 Jun 2025 10:20:51 +0200
Message-ID: 
CC: "Daniel P. Smith" , Andrew Cooper
	, =?utf-8?q?Roger_Pau_Monn=C3=A9?=
	, Anthony PERARD , "Michal
 Orzel" , Julien Grall , "Stefano
 Stabellini" , Bertrand Marquis
	, Denis Mukhin ,
	
Subject: Re: [PATCH v6 06/12] x86/hyperlaunch: obtain cmdline from device
 tree
From: Alejandro Vallejo 
To: Jan Beulich , Jason Andryuk 
X-Mailer: aerc 0.20.1
References: <20250429123629.20839-1-agarciav@amd.com>
 <20250429123629.20839-7-agarciav@amd.com>
 <59f37fcc-9226-46c5-8dc8-7bd2100d8f59@amd.com>
 <02ffa9cf-b5cd-431a-834a-a11bbf310196@suse.com>
 <03be429c-063d-4467-91e7-7ef2e148a2fb@amd.com>
 
In-Reply-To: 
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: MN1PEPF0000F0E3:EE_|MN6PR12MB8591:EE_
X-MS-Office365-Filtering-Correlation-Id: 64193f2f-c25d-4ffa-8dfd-08dda98a0ddf
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|7416014|376014|82310400026|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?aVJFcjIxbWZXNmUwWm80T3Z2bCtqN2Jnb29JTktkaVVWSE1mYnQzUWlKK1Ni?=
 =?utf-8?B?MDRDK1FSaWcrNGVOTDJ0ZEZsZFhudnE4MjBtMkZjSWRWOUZtYU4raVZrNGxI?=
 =?utf-8?B?QkpTY0Y3ejQreG1pd0ppWTdiYktCU2xGbUNzZEViNFdvMHIrZ2pWTE9NcEdF?=
 =?utf-8?B?ekt3Vk1sM2wxYXd5QmdyemUyUHhsY0ZsUVgxcC9OZnJiQXVoSVd2WDFzVU5T?=
 =?utf-8?B?bkF5RGhCN1ZFV3FzZW0wcUQxQXc3YjdaRFBRNUtVMUlRNUVnWk9jYWowRFBO?=
 =?utf-8?B?VWtnb2Qydys1bHVTeWhyN2Vjd0s1cWViRkNteDNuZjkzb2JrOTFOUW9TQ0Ux?=
 =?utf-8?B?emVna2Z3b1hHODdqZWsrWkVjVkVSdWY5TGUwK1ZVNDdjSFFBOTRaeGtiZ3lk?=
 =?utf-8?B?SHhNT3J0UGZjd04wQk9ta0dKQk5jN1B2WFdEd2pFM2JJbmdPRmxxTXVGOTA4?=
 =?utf-8?B?WmU2d1VROEVlalBxTGxFQ3pPeTJ2c1lVV2craWxrMllvdUtnWklkVlNvSDJ6?=
 =?utf-8?B?aVBXRnZYRFVBUWQxdXZCMTE5N29sK1M2aHZjRktMb0NGbG9IenNHbVoxRWFX?=
 =?utf-8?B?ZWpFWk1lbVJRQ095eVkyL000dW55ZlFjVnlMczZiYTR2cmJ4TngwTzBPM05E?=
 =?utf-8?B?Vjc4OTVHQlhHNk0zcEYxRVlWSE1nTE5heXVCb1RVOTRGUjdMY1E1SHh5VWR5?=
 =?utf-8?B?bXhTcVVzcEVQOWRDM1hOY3ZRRlZ5U1B1ZHVSRi9rK3pYU2FzVmhYTWdPU3RX?=
 =?utf-8?B?SUxmVDVYUTlVenVjaTl0WDN1bHllSVphQ0dINTdqTGI3bmpjTUpRTkxNbmpU?=
 =?utf-8?B?TVJoV05OSzFHTlBnSzQwL2Q0M0JMVnhDV253eW1WalE5emxibWNUU04zUVdN?=
 =?utf-8?B?Z2JNYk01NnpMN29FMDJ5UUQ4ekltak5ZOXk3Ny9waTdTb3A5ZVpwZkF3RTY1?=
 =?utf-8?B?UXBsUXhidTN1dkE2R05HVXFmWHRzOVVKNnpnL2cyc0piTFJDWWt4MjV5SGFY?=
 =?utf-8?B?MVFFUk9tZjkyZUFJS3FSWithNStmWXNSY041d0tyS09Yb0M1MExrWExqQTVs?=
 =?utf-8?B?U3VqWXlHaCtoTUx0UmQyYXh2Slc3VHg5bnhBM0sweFgrNW9pQ2I0NFBCQkFY?=
 =?utf-8?B?UFRhdkRzWXJHRnRlZDNRdWh3a2IvWDd6ZjJ1NkZJbkRHSzFwdVNXeHR3TitN?=
 =?utf-8?B?R1dqamtTSHN0UFNWVUhEYVMvQkFzOEFkUHdXZlBQZGhkc25RbG92TU5nYTEy?=
 =?utf-8?B?ajBWWURHYTROenhFRHFrcmJsQmVpOVA2VDZxR2kzZk9rL0dxeW82MVFUWjd2?=
 =?utf-8?B?clhQaVRsZldLSDJTZHRvWjl4YjNlV2xkSWRMNklQTmF1bjZSemc5VS9lQ2lC?=
 =?utf-8?B?ODVZRUFvU2ZOTkliVkxqMXQ5UnhZNTV4YlF3eDdzS2hSNWhncEdwMW82SmtG?=
 =?utf-8?B?Vko1ZXgyaW53Q3VQUmw1QXhjSlgvTHk4a25XZldHZnVrMllUUXNrNVF4bVUz?=
 =?utf-8?B?MGtWbSs4ZEtEMnk3WTliTDdQUS8rNjFwSm5lTzZoVTZwOEZjR1ExSTIraGYv?=
 =?utf-8?B?eW9ORDdhZjZsaHZNU1FYQ0hsNlcxem5xa0lvVGNZY0pVT040YUFwdGFnWmY0?=
 =?utf-8?B?RTAwVGJqSHh5UnBTekJjeUJXaks1NWxoOXJibzBQd0VyczdhdjY5alloeVVC?=
 =?utf-8?B?YXZTL1gzYlF0R3pTalM5L3gwa1NHWG9zQmlPSGhwcHpVNTU1SExiY1hSUTh4?=
 =?utf-8?B?UGoyY2FJYVg3OXo5VS9WN2hnRVo1SWVmd3A5T0VwSzhwaUIrQTJWNndZMTdi?=
 =?utf-8?B?S0V2bzlydC9qNTU2dDdRQU9tT1BobGJ3cFBqT1ExNVJpVTFYN0RoaGVHODVy?=
 =?utf-8?B?WkIzKzU5dXdKSGVOZmMxUnUvVm9SR0pnOWIxTzFEOUttaW9laHlRZGFsY1JZ?=
 =?utf-8?B?WE1uRUtVUjRtMjhjd2tBN1c5cU1WTzBIS0RzNW9LZmJ0UUxtQ0JlMTBkOEJu?=
 =?utf-8?B?eDFCM2VxT2EyR2JHTXU4SkMyT3N0dldTV2M0SDloa1hDUld6ZElnTzJMZVdl?=
 =?utf-8?Q?I4fAg6?=
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);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2025 08:20:55.9379
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 64193f2f-c25d-4ffa-8dfd-08dda98a0ddf
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:
	MN1PEPF0000F0E3.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN6PR12MB8591

On Wed Jun 11, 2025 at 7:35 AM CEST, Jan Beulich wrote:
> On 10.06.2025 19:39, Jason Andryuk wrote:
>>=20
>>=20
>> On 2025-06-10 02:56, Jan Beulich wrote:
>>> On 09.06.2025 19:07, Jason Andryuk wrote:
>>>> On 2025-04-29 08:36, Alejandro Vallejo wrote:
>>>>> From: "Daniel P. Smith" 
>>>>>
>>>>> Add support to read the command line from the hyperlaunch device tree=
.
>>>>> The device tree command line is located in the "bootargs" property of=
 the
>>>>> "multiboot,kernel" node.
>>>>>
>>>>> A boot loader command line, e.g. a grub module string field, takes
>>>>> precendence over the device tree one since it is easier to modify.
>>>>>
>>>>> Signed-off-by: Daniel P. Smith 
>>>>> Signed-off-by: Jason Andryuk 
>>>>> Signed-off-by: Alejandro Vallejo 
>>>>> Reviewed-by: Denis Mukhin 
>>>>> ---
>>>>
>>>>> diff --git a/xen/common/domain-builder/fdt.c b/xen/common/domain-buil=
der/fdt.c
>>>>> index cbb0ed30a2..dabe201b04 100644
>>>>> --- a/xen/common/domain-builder/fdt.c
>>>>> +++ b/xen/common/domain-builder/fdt.c
>>>>> @@ -219,6 +219,12 @@ static int __init fdt_process_domain_node(
>>>>> =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 printk(XENLOG_INFO "=C2=A0 kernel: multiboot-index=3D%d\n",=
 idx);
>>>>> =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 bi->mods[idx].type =3D BOOTMOD_KERNEL;
>>>>> =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 bd->kernel =3D &bi->mods[idx];
>>>>> +
>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /=
* If bootloader didn't set cmdline, see if FDT provides one. */
>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 i=
f ( bd->kernel->cmdline_pa &&
>>>>> +=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 !((char *)__va(bd->kernel->cmdline_pa))[0] )
>>>>
>>>> The logic is incorrect - it should be:
>>>>
>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 if ( !bd->kernel->cmdline_pa ||
>>>> =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 !((char *)__va(bd->kernel->cmdline_pa))[0=
] )
>>>>
>>>> If there is no cmdline_pa (which happens with the "reg" property) or t=
he if there is a 0-length string, then check the DT for bootargs.
>>>
>>> Even that sounds bogus to me: There's a difference between "no command =
line"
>>> and "empty command line".
>>=20
>> Yes, you have a point.=C2=A0 The difficulty is grub always provides a NU=
L terminated string, so Xen can't differentiate the two.
>
> Which may call for either special-casing GrUB, or at least calling out th=
at
> behavior in the comment. (Ideally we'd still have a way to distinguish
> between both cases, but likely we'll need to resort to documenting that s=
ome
> dummy option will need adding to tell "none" from [intended to be] empty.=
)
>
> Jan

We can add suitable comments where required, sure.

About the dummy option, note that even if we have an option for Xen, that d=
oes
nothing for the kernel cmdlines. If there's such dummy option there I don't=
 know
of it.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 08:27:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 08:27:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012518.1390985 (Exim 4.92)
	(envelope-from )
	id 1uPdHI-0000Wt-Gf; Thu, 12 Jun 2025 08:27:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012518.1390985; Thu, 12 Jun 2025 08:27:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPdHI-0000Wm-DQ; Thu, 12 Jun 2025 08:27:16 +0000
Received: by outflank-mailman (input) for mailman id 1012518;
 Thu, 12 Jun 2025 08:27: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 1uPdHH-0000Wg-Nr
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 08:27:15 +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 0b0a89a8-4767-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 10:27:14 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a4fd1ba177so415011f8f.0
 for ; Thu, 12 Jun 2025 01:27:14 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b2fd6388307sm820027a12.65.2025.06.12.01.27.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 01:27:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0b0a89a8-4767-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749716834; x=1750321634; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Wh542Foqzy9CXMj7KWhI4Fot+RPodj2Dclo5YjnMjdM=;
        b=ZGWs9TattTDt28IT4yVDKYtiI6Hsl2BwYLHEQPKI+ZqYX4pT4eHOWBekqwmfJkRSQo
         sqLG4kS2im+fKPlfpHrh1aDeeNa/bx5MyW2CbtlYQvoi2ZrVakqMAbsIJ7jgCO2D3zAW
         tJHRWgUHyJt2Jd3UW7UAysxxYQADARHs+1a5xY+XzVs26xtqFFxbvEXDvG+ldG23QUhk
         DwqGW/vccJnIkKWRJlofw4Ok7y5M+ENFVwfFDwXCc3Qbcp+9mSV4YGHCZ9bvPDpRoaqA
         mFHPhKH/a7HNTYC7h+paYa86ecyqR0rHi++pQRpwDA+RISMKh1sihSqhrlHLduXCvU6L
         xcaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749716834; x=1750321634;
        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=Wh542Foqzy9CXMj7KWhI4Fot+RPodj2Dclo5YjnMjdM=;
        b=F/o6TQXeV2n5/clsK52bxn7QZ+Fzm3kEJG4HSa/pAr6UXPPIsZRg1c4bzm//4PzrBi
         FHDXg/1IhWQYD9T2FO6cKTLkXA7BBlEPvLOKnHr3vx4MC+65klVR5xxU3N/nBwyQYj9C
         2h0dz9c0NVlqSzQhAy/zKn65h3QIRUbJDCXp8s68O++O4QeH24zvxCnY+nuqKVBodLVC
         0BOxX2k+Vkpg2NC7MGY4o6xJknfa126bn7/agurl8Jti3XEGvgmktA8+5sP4sR8JZ9KL
         toNpSwzgh/EpBM81Ak6VC4CNTFbpJb7w4f058rYqZKXbfYNFdq8brQYTdgDkCE22otQg
         4PKg==
X-Forwarded-Encrypted: i=1; AJvYcCX/P7AJt4NBIRfb1s9X157m6iA52MJVoujOgSnkuwmaF2NYu/z/VP0ItGMRcYPKofLCWfesxxsLKH0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwHhFl5k+YfxqmapAy8utQQRjqnZdHehA7dlJ0gpxiDP1BaekwT
	mBFPFPeZda7glCIFc01+Ogycez5h0wmPM4XffWI0sNevJkxQmfKuIzcPkM1P9LtpMw==
X-Gm-Gg: ASbGncumhwZnjU2M66fNbfEgT4jpwCfpztNyVWl31eCqWp18Fd1XWTbNwr1YXAeFo1P
	ad+Nqj212zCY7xfiUjNk/PJpM6WIUKQAfMCyDPGe8Nk/nNEzEnNenXTQsU0DGkFwIEXvNmnMXGg
	TKhV3eo/2VOAv6xFmtlRPS8YNLyQD38/qUKtXumboA4MRhG/sugdCQI7o+ryuTAVymwEsYwOwfZ
	X/fcW+I7ZOXRtqkdHbfCCuotnqjMvHORZcZwual3qkQQugUHXJbbXnwanJunewP9rEMypKnwe4N
	q7G8BPX/ZJSzwF/W6nW1SI46fILeRMoYKVXR2jp+oGwUNbN205+RW/u7yxRAwHwd5dbY5bynjLp
	m+PuAIZQZ4hREqfjzYHqkQK8GkFsKoN3zYtm/CRC3uST7p3I=
X-Google-Smtp-Source: AGHT+IEXqjhujpgMlu2VeVGD8ZFYVxDMMrLLcL+5iz0zT/11Ws/WiROR6ZQqKhPx6U3Ikqi7M0chPA==
X-Received: by 2002:a05:6000:4283:b0:3a5:24cc:6d5e with SMTP id ffacd0b85a97d-3a560763290mr1894171f8f.3.1749716833649;
        Thu, 12 Jun 2025 01:27:13 -0700 (PDT)
Message-ID: 
Date: Thu, 12 Jun 2025 10:27:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 6/8] pdx: introduce a new compression algorithm based on
 offsets between regions
To: Roger Pau Monne 
Cc: Anthony PERARD ,
 Andrew Cooper ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk ,
 xen-devel@lists.xenproject.org
References: <20250611171636.5674-1-roger.pau@citrix.com>
 <20250611171636.5674-7-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: <20250611171636.5674-7-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.06.2025 19:16, Roger Pau Monne wrote:
> With the appearance of Intel Sierra Forest and Granite Rapids it's not
> possible to get a production x86 host wit the following memory map:
> 
> SRAT: Node 0 PXM 0 [0000000000000000, 000000007fffffff]
> SRAT: Node 0 PXM 0 [0000000100000000, 000000407fffffff]
> SRAT: Node 1 PXM 1 [0000061e80000000, 0000065e7fffffff]
> SRAT: Node 2 PXM 2 [00000c3e80000000, 00000c7e7fffffff]
> SRAT: Node 3 PXM 3 [0000125e80000000, 0000129e7fffffff]
> 
> This is from a four socket system, with each node having 256GB of memory.
> The total amount of RAM on the system is 1TB, but without enabling
> CONFIG_BIGMEM the last range is not accessible, as it's above the 16TB
> boundary covered by the frame table.
> 
> Note that while the memory map is very sparse, it won't be compressible
> using the current algorithm that relies on all ranges having a shared
> zeroed region of bits that can be removed.
> 
> The memory map presented above has the property of all regions being
> similarly spaced between each other, and all having also a similar size.
> This allows to compress them using the following formula:
> 
>  pdx = (pfn % offset) + ((pfn / offset) * size)
> 
> Where offset and size are two static coefficients calculated at
> initialization.

What I would find useful here in addition would be offset and size values
resulting from the example memory map above. In particular, without looking
at the code in detail, it doesn't become quite clear how the two ranges on
node 0 are being dealt with. For what follows I'll assume they'd be folded
into a single range covering all of node 0.

Along the lines of Andrew's concern regarding the division (and modulo)
involved, I wonder whether there might be an alternative with a lookup
array, holding bias values (e.g.) for each node. Main question there would
be how to quickly determine the array index to use, both from an incoming
MFN and an incoming PDX. If such an array wouldn't have too many entries,
such a lookup may end up being faster (on average) than a division.

Taking the example above, such an array could be:

[0x00] = 0,
[0x06] = 0x061e80000 - 1 * 0x5000000,
[0x0c] = 0x0c3e80000 - 2 * 0x5000000,
[0x12] = 0x125e80000 - 3 * 0x5000000,

indexed by the top-so-many bits of the MFN. For the reverse array some
gap would need to be left between ranges (i.e. the 0x5000000 above would
perhaps need doubling; maybe a little less than that would suffice), such
that the array slot to use could be determined easily there as well.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 08:29:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 08:29:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012530.1390996 (Exim 4.92)
	(envelope-from )
	id 1uPdJA-00012m-Qj; Thu, 12 Jun 2025 08:29:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012530.1390996; Thu, 12 Jun 2025 08:29: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 1uPdJA-00012f-OF; Thu, 12 Jun 2025 08:29:12 +0000
Received: by outflank-mailman (input) for mailman id 1012530;
 Thu, 12 Jun 2025 08:29: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 1uPdJ9-00012Z-Cl
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 08:29:11 +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 4dea4b90-4767-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 10:29:06 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3a5257748e1so508464f8f.2
 for ; Thu, 12 Jun 2025 01:29:06 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2364e6f9947sm8477765ad.165.2025.06.12.01.29.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 01:29:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4dea4b90-4767-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749716946; x=1750321746; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=tfYnUlMdjfkjCy+wffoMiBlnRhmb8dVbSvb5s3dGTwc=;
        b=efNDeojhv+Nf9eS35HFjJQEROtyrJtI/MeYmXVLRv6UmygCLotgNF1DsixRJrhff4v
         0DY7Uaf5FVK1wRb5nJ+b80Uw6WXiNgSEGyn7gCI1Vt7WJIkxeSBtSJ08ZJEnUpupBi2Q
         ib6BqX01yXHk5Rfe4796R2nFbyCI2FNElpg/m8wHFofZ+LdlusqIOYp9wnwCapKCIWXl
         hBVtbqK9FGe0Scxv/GR5Gw3QC5ZlZbq9oCfvj/28CEljtEVCOrRCE1RSdjYDYthyfcuN
         ub+3F0Tt96dKfuATjHui+55rk4mkKaxxvPXwPHtGYGz4Ywjl1lyEq82wvOlnPdOyqhop
         JwuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749716946; x=1750321746;
        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=tfYnUlMdjfkjCy+wffoMiBlnRhmb8dVbSvb5s3dGTwc=;
        b=MqXnorhmZY+RInP/++9RSO/pLnDx61AT143dKD0+wsYZiihvOIIgO5x9B/a51ysIXW
         UTlhGjzCJEovevbmEph+11WbcvnsZ2qBKYIIsfqRqxqry1V0AVU23jSZMjH/aJVq0geY
         w67S/NfPLJcYkPEphcPQIl/tYaT0ixSIfOEFSwV9j1vSTWsKJIl7zjScaU98Cp1D9uCu
         Bi/dDntMZw9vBDtMysyYeE+80ptFhPCj913rVNx+38/2v0A8fOxcYUD3zn/C4IEmSwEi
         DosCH3B+Cxp0/H5wnZG8A5I9jtQbbvS3z9RcugYXAi/N1yXW7h9b6xaxhqFpiKQGZWLM
         lpzQ==
X-Forwarded-Encrypted: i=1; AJvYcCUDJ7tDhDtZwIR8puZHuCSZy0TKwF8PPGC4j6kHziY9C2xk1xhUBjZpZ+MN2Y3iruy9YSQuOxyWrD4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyEL6HRrnSFJSD1tbI2+kW0waRDXjOiNThWGh63rcAHbnKNOudu
	Flr3xRdHyDG7g4oprD/Td5Afs7dOmuW4JRo/J7Y13R4vF2Zv4XoD9srV+fQSBVUwYQ==
X-Gm-Gg: ASbGncsuX1+uFsrX+xoUyv8bSu9y5jIhZ0OwzxD2FXvxdkHqTv3lwpKPL9ariG2fy4+
	1mkBmQJGF2uZctV/K6Sla+2Q6hj4h+AlBvEjHz6Hf68VMSD+taLf7OGCzvsqRuTw6KXbrvjF4gj
	u8rD9o23o9lh43PhzMKtBq8viabubrLg9iYrwzB95Hb9Z8AFLuEW11e2wv47Xx3qeQrcu8geOoJ
	Fe7HHD8XE3oj8T6oQnYvEQsruEisYR9BpJVXNmb0eXddOnGmPAuJx3ut811gjkf40LKNd+Ta+YE
	j2F3YeoxY5UONpQehYGe4Df48Hc3VYCS0dyaWwtUTdxj1OVPgZY+KfB/YV1GE31VN5xPhgOXLVf
	M7R5CAH49/R8vjRKpUr+Gu91KG41PtsmHKieYUyQAUsuAmaI=
X-Google-Smtp-Source: AGHT+IENprURkM4AtEC+0GB35h7UXDu9b2J8WguGdmFd3MmgFbgTXqHqsciMUCh3imOXuHrDb4p/kA==
X-Received: by 2002:a05:6000:2893:b0:3a4:eed9:755d with SMTP id ffacd0b85a97d-3a5612f1629mr1390844f8f.3.1749716945844;
        Thu, 12 Jun 2025 01:29:05 -0700 (PDT)
Message-ID: 
Date: Thu, 12 Jun 2025 10:28:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/8] kconfig: turn PDX compression into a choice
To: Roger Pau Monne 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250611171636.5674-1-roger.pau@citrix.com>
 <20250611171636.5674-4-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: <20250611171636.5674-4-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 11.06.2025 19:16, Roger Pau Monne wrote:
> Rename the current CONFIG_PDX_COMPRESSION to CONFIG_PDX_MASK_COMPRESSION,
> and make it part of the PDX compression choice block, in preparation for
> adding further PDX compression algorithms.
> 
> No functional change intended as the PDX compression defaults should still
> be the same for all architectures, however the choice block cannot be
> protected under EXPERT and still have a default choice being
> unconditionally selected.  As a result, the new "PDX (Page inDeX)
> compression" item will be unconditionally visible in Kconfig.
> 
> As part of this preparation work to introduce new PDX compressions, adjust
> some of the comments on pdx.h to note they apply to a specific PDX
> compression.  Also shuffle function prototypes and dummy implementations
> around to make it easier to introduce a new PDX compression.  Note all
> PDX compression implementations are expected to provide a
> pdx_is_region_compressible() that takes the same set of arguments.
> 
> Signed-off-by: Roger Pau Monné 

Acked-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Thu Jun 12 08:32:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 08:32:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012536.1391006 (Exim 4.92)
	(envelope-from )
	id 1uPdMN-0002uw-7P; Thu, 12 Jun 2025 08:32:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012536.1391006; Thu, 12 Jun 2025 08: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 1uPdMN-0002up-4G; Thu, 12 Jun 2025 08:32:31 +0000
Received: by outflank-mailman (input) for mailman id 1012536;
 Thu, 12 Jun 2025 08:32: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 1uPdML-0002uj-M9
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 08:32:29 +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 c5e4b39a-4767-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 10:32:27 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a4f71831abso630769f8f.3
 for ; Thu, 12 Jun 2025 01:32:27 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-748809eb837sm867210b3a.128.2025.06.12.01.32.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 01:32:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c5e4b39a-4767-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749717147; x=1750321947; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=l2mHZJuEE1wmvVkO6qbI7hShGYcVVTeDYg2AMdpUpMs=;
        b=hGSveTmFWszKvM+dNF882GB4+kqcDdUqgLqVk/fRwiww6vAyORTVF4s3ZGTFIuAnHq
         LQdpMiJnRfgHKKptXQ/1AQPNWLJaltXKulHkTfcessTxwjNFnJvK6HzWrHsEEJrFoSTM
         FG3xYin3WC8gMlRVHiSIVDfAGldeTOIGT4Wstj3hdJO0K+fnU21s49HlXdy/zsQ8ynfJ
         Sc4e7hN5MQTTFocVYDl8h4QzQZ6MWJCSrtsmi1MyN6IqSY+FBqFg5NdRe8dWDS3T2rv6
         2HGQmd2t2IpDcCpS3oBn63CEp6QD4qQWuFssq+BOYdSjv5E31R2qVqYZ9tYO1eEDo9gi
         yCTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749717147; x=1750321947;
        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=l2mHZJuEE1wmvVkO6qbI7hShGYcVVTeDYg2AMdpUpMs=;
        b=Bv4dMy+vEyyUQr/Ce9zPHbFOuFJK13jOwzkM/jlE1eWCC6ZgRFyLtmSE2EAPXuhQgK
         VOL9jR1gRNC+iSElo/Y6s7s8LJ/0CZ6H/+NCNYt0ww57Ci6mJTEcdpbsRkE6pGKYj3nl
         JyJh9DBrCzH4bvVjuHBUizAFsE/kove2K3M0i51EKlEiKvBdbqBMEoYFT56eZxjRwOgP
         iAhrAju4ma5hYm4w/l/1ecYQvI2lcZnR/FofGG3boRuH0gOacSsQD0Xy9w9tSgflYixI
         8p5EXSjwrrwJlwTkzbx1x9/gcm5SnYm+dmeZKeET8xybi5C3fFIPmSJum52bPZWkOKzN
         JSjg==
X-Forwarded-Encrypted: i=1; AJvYcCUeoRFd/PtNr6F8vCDD0x8ziqQrppaTBao0ube5PgGn7kCst+dmI17q4ro5XyTr6Vupo1/l/J0qUG8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyZ22/ZNrcNl6QgpFQuuXgOv4jQGF2hu6Uk6G33Q2spcvLM3qmO
	Cfy5ql6Vu57xF6EfVxVy41odgpjXudGQCGw+k+GpVQZcFyvCsB3c2/TAo3iBjqgtNA==
X-Gm-Gg: ASbGnctEGcMgtKbUhyhiv28ZiJQ2BSbbDqLOYRw9rA0tkrMWmlEC0bkd288xs938+cv
	YGqqLer9R2ji6l2ZpHCtx+17t37z72gXKnOE7pkyT1wkwHZvn2K3B/oEfiGPlA36ZyY/9qadBEu
	37J+8l+8f6s8Mla7mW9G8pgdGFrVKRDwPVIjhFlEmqMCXEyV/29EkIcb/oA7oE5ROaJoICrBPfN
	nPBXc6dyufXhOQEPMHQkhdcSAY81CqCYEF/T9xCpzz+f/LyeWYkNicSo6xiI65vyph7wj3fH0FW
	yTDqGdrP94dCfqxmKVnOGmMY8AE+RVMEoGl+wH2pEKNDa6/HLsRdiNReRZHNIBsq6OnFFiVb69E
	v0dc9jUGv+gPLohUEOEe6DxCoQSOMIoqWvb5Kk1JJ8qrrakU=
X-Google-Smtp-Source: AGHT+IHcx6Sfp7s4YRaxHyeCZ83Y5gRE2pxdptszmBL9EKvXHgN2I2kvMiQGA0XU831uK3/AAdho9A==
X-Received: by 2002:a5d:5f85:0:b0:3a5:2ef8:34f0 with SMTP id ffacd0b85a97d-3a560760623mr1961652f8f.22.1749717147130;
        Thu, 12 Jun 2025 01:32:27 -0700 (PDT)
Message-ID: <46fb8be4-2562-45b5-a2da-0c7c741f227f@suse.com>
Date: Thu, 12 Jun 2025 10:32:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 4/8] pdx: provide a unified set of unit functions
To: Roger Pau Monne 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD , xen-devel@lists.xenproject.org
References: <20250611171636.5674-1-roger.pau@citrix.com>
 <20250611171636.5674-5-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: <20250611171636.5674-5-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.06.2025 19:16, Roger Pau Monne wrote:
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -255,6 +255,10 @@ void __init init_pdx(void)
>  {
>      const struct membanks *mem = bootinfo_get_mem();
>      paddr_t bank_start, bank_size, bank_end;
> +    unsigned int bank;
> +
> +    for ( bank = 0 ; bank < mem->nr_banks; bank++ )
> +        pfn_pdx_add_region(mem->bank[bank].start, mem->bank[bank].size);

In patch 6 you touch all these call sites again - why not add the 3rd
parameter / argument in this patch right away?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 08:36:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 08:36:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012541.1391016 (Exim 4.92)
	(envelope-from )
	id 1uPdQP-0003TQ-MP; Thu, 12 Jun 2025 08:36:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012541.1391016; Thu, 12 Jun 2025 08:36: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 1uPdQP-0003TJ-JM; Thu, 12 Jun 2025 08:36:41 +0000
Received: by outflank-mailman (input) for mailman id 1012541;
 Thu, 12 Jun 2025 08:36: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 1uPdQO-0003TD-G4
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 08:36:40 +0000
Received: from perceval.ideasonboard.com (perceval.ideasonboard.com
 [2001:4b98:dc2:55:216:3eff:fef7:d647])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 58ed39ba-4768-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 10:36:34 +0200 (CEST)
Received: from [192.168.88.20] (91-158-153-178.elisa-laajakaista.fi
 [91.158.153.178])
 by perceval.ideasonboard.com (Postfix) with ESMTPSA id 11261D6;
 Thu, 12 Jun 2025 10:36:24 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 58ed39ba-4768-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;
	s=mail; t=1749717385;
	bh=E53Iev0SGLzeW/a7DteuShKZBtYGyift8mXfiu1vDtI=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=QwVsPb6jF1V2tkBZRKjn38YpurCT5Z3TmPGNt3trSE+m474O/LtVvfXM7navf4kUb
	 QeVoyUKACIUmqlvX1iLqNq0h9UG3a97+zxKMaXZUkWglp4jPmqKqCPniX76PybLYbJ
	 /T1WYsJZkNSG4X9yanIOHTKpCmQ0mQPhU97ryPbE=
Message-ID: 
Date: Thu, 12 Jun 2025 11:36:29 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 02/25] drm/dumb-buffers: Provide helper to set pitch
 and size
To: Thomas Zimmermann 
Cc: dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org,
 freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
 imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org,
 nouveau@lists.freedesktop.org, virtualization@lists.linux.dev,
 spice-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org,
 linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
 intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org,
 simona@ffwll.ch, airlied@gmail.com, mripard@kernel.org,
 maarten.lankhorst@linux.intel.com, geert@linux-m68k.org
References: <20250311155120.442633-1-tzimmermann@suse.de>
 <20250311155120.442633-3-tzimmermann@suse.de>
Content-Language: en-US
From: Tomi Valkeinen 
Autocrypt: addr=tomi.valkeinen@ideasonboard.com; keydata=
 xsFNBE6ms0cBEACyizowecZqXfMZtnBniOieTuFdErHAUyxVgtmr0f5ZfIi9Z4l+uUN4Zdw2
 wCEZjx3o0Z34diXBaMRJ3rAk9yB90UJAnLtb8A97Oq64DskLF81GCYB2P1i0qrG7UjpASgCA
 Ru0lVvxsWyIwSfoYoLrazbT1wkWRs8YBkkXQFfL7Mn3ZMoGPcpfwYH9O7bV1NslbmyJzRCMO
 eYV258gjCcwYlrkyIratlHCek4GrwV8Z9NQcjD5iLzrONjfafrWPwj6yn2RlL0mQEwt1lOvn
 LnI7QRtB3zxA3yB+FLsT1hx0va6xCHpX3QO2gBsyHCyVafFMrg3c/7IIWkDLngJxFgz6DLiA
 G4ld1QK/jsYqfP2GIMH1mFdjY+iagG4DqOsjip479HCWAptpNxSOCL6z3qxCU8MCz8iNOtZk
 DYXQWVscM5qgYSn+fmMM2qN+eoWlnCGVURZZLDjg387S2E1jT/dNTOsM/IqQj+ZROUZuRcF7
 0RTtuU5q1HnbRNwy+23xeoSGuwmLQ2UsUk7Q5CnrjYfiPo3wHze8avK95JBoSd+WIRmV3uoO
 rXCoYOIRlDhg9XJTrbnQ3Ot5zOa0Y9c4IpyAlut6mDtxtKXr4+8OzjSVFww7tIwadTK3wDQv
 Bus4jxHjS6dz1g2ypT65qnHen6mUUH63lhzewqO9peAHJ0SLrQARAQABzTBUb21pIFZhbGtl
 aW5lbiA8dG9taS52YWxrZWluZW5AaWRlYXNvbmJvYXJkLmNvbT7CwY4EEwEIADgWIQTEOAw+
 ll79gQef86f6PaqMvJYe9QUCX/HruAIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRD6
 PaqMvJYe9WmFD/99NGoD5lBJhlFDHMZvO+Op8vCwnIRZdTsyrtGl72rVh9xRfcSgYPZUvBuT
 VDxE53mY9HaZyu1eGMccYRBaTLJSfCXl/g317CrMNdY0k40b9YeIX10feiRYEWoDIPQ3tMmA
 0nHDygzcnuPiPT68JYZ6tUOvAt7r6OX/litM+m2/E9mtp8xCoWOo/kYO4mOAIoMNvLB8vufi
 uBB4e/AvAjtny4ScuNV5c5q8MkfNIiOyag9QCiQ/JfoAqzXRjVb4VZG72AKaElwipiKCWEcU
 R4+Bu5Qbaxj7Cd36M/bI54OrbWWETJkVVSV1i0tghCd6HHyquTdFl7wYcz6cL1hn/6byVnD+
 sR3BLvSBHYp8WSwv0TCuf6tLiNgHAO1hWiQ1pOoXyMEsxZlgPXT+wb4dbNVunckwqFjGxRbl
 Rz7apFT/ZRwbazEzEzNyrBOfB55xdipG/2+SmFn0oMFqFOBEszXLQVslh64lI0CMJm2OYYe3
 PxHqYaztyeXsx13Bfnq9+bUynAQ4uW1P5DJ3OIRZWKmbQd/Me3Fq6TU57LsvwRgE0Le9PFQs
 dcP2071rMTpqTUteEgODJS4VDf4lXJfY91u32BJkiqM7/62Cqatcz5UWWHq5xeF03MIUTqdE
 qHWk3RJEoWHWQRzQfcx6Fn2fDAUKhAddvoopfcjAHfpAWJ+ENc7BTQROprNHARAAx0aat8GU
 hsusCLc4MIxOQwidecCTRc9Dz/7U2goUwhw2O5j9TPqLtp57VITmHILnvZf6q3QAho2QMQyE
 DDvHubrdtEoqaaSKxKkFie1uhWNNvXPhwkKLYieyL9m2JdU+b88HaDnpzdyTTR4uH7wk0bBa
 KbTSgIFDDe5lXInypewPO30TmYNkFSexnnM3n1PBCqiJXsJahE4ZQ+WnV5FbPUj8T2zXS2xk
 0LZ0+DwKmZ0ZDovvdEWRWrz3UzJ8DLHb7blPpGhmqj3ANXQXC7mb9qJ6J/VSl61GbxIO2Dwb
 xPNkHk8fwnxlUBCOyBti/uD2uSTgKHNdabhVm2dgFNVuS1y3bBHbI/qjC3J7rWE0WiaHWEqy
 UVPk8rsph4rqITsj2RiY70vEW0SKePrChvET7D8P1UPqmveBNNtSS7In+DdZ5kUqLV7rJnM9
 /4cwy+uZUt8cuCZlcA5u8IsBCNJudxEqBG10GHg1B6h1RZIz9Q9XfiBdaqa5+CjyFs8ua01c
 9HmyfkuhXG2OLjfQuK+Ygd56mV3lq0aFdwbaX16DG22c6flkkBSjyWXYepFtHz9KsBS0DaZb
 4IkLmZwEXpZcIOQjQ71fqlpiXkXSIaQ6YMEs8WjBbpP81h7QxWIfWtp+VnwNGc6nq5IQDESH
 mvQcsFS7d3eGVI6eyjCFdcAO8eMAEQEAAcLBXwQYAQIACQUCTqazRwIbDAAKCRD6PaqMvJYe
 9fA7EACS6exUedsBKmt4pT7nqXBcRsqm6YzT6DeCM8PWMTeaVGHiR4TnNFiT3otD5UpYQI7S
 suYxoTdHrrrBzdlKe5rUWpzoZkVK6p0s9OIvGzLT0lrb0HC9iNDWT3JgpYDnk4Z2mFi6tTbq
 xKMtpVFRA6FjviGDRsfkfoURZI51nf2RSAk/A8BEDDZ7lgJHskYoklSpwyrXhkp9FHGMaYII
 m9EKuUTX9JPDG2FTthCBrdsgWYPdJQvM+zscq09vFMQ9Fykbx5N8z/oFEUy3ACyPqW2oyfvU
 CH5WDpWBG0s5BALp1gBJPytIAd/pY/5ZdNoi0Cx3+Z7jaBFEyYJdWy1hGddpkgnMjyOfLI7B
 CFrdecTZbR5upjNSDvQ7RG85SnpYJTIin+SAUazAeA2nS6gTZzumgtdw8XmVXZwdBfF+ICof
 92UkbYcYNbzWO/GHgsNT1WnM4sa9lwCSWH8Fw1o/3bX1VVPEsnESOfxkNdu+gAF5S6+I6n3a
 ueeIlwJl5CpT5l8RpoZXEOVtXYn8zzOJ7oGZYINRV9Pf8qKGLf3Dft7zKBP832I3PQjeok7F
 yjt+9S+KgSFSHP3Pa4E7lsSdWhSlHYNdG/czhoUkSCN09C0rEK93wxACx3vtxPLjXu6RptBw
 3dRq7n+mQChEB1am0BueV1JZaBboIL0AGlSJkm23kw==
In-Reply-To: <20250311155120.442633-3-tzimmermann@suse.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi,

On 11/03/2025 17:47, Thomas Zimmermann wrote:
> Add drm_modes_size_dumb(), a helper to calculate the dumb-buffer
> scanline pitch and allocation size. Implementations of struct
> drm_driver.dumb_create can call the new helper for their size
> computations.
> 
> There is currently quite a bit of code duplication among DRM's
> memory managers. Each calculates scanline pitch and buffer size
> from the given arguments, but the implementations are inconsistent
> in how they treat alignment and format support. Later patches will
> unify this code on top of drm_mode_size_dumb() as much as possible.
> 
> drm_mode_size_dumb() uses existing 4CC format helpers to interpret
> the given color mode. This makes the dumb-buffer interface behave
> similar the kernel's video= parameter. Current per-driver implementations
> again likely have subtle differences or bugs in how they support color
> modes.
> 
> The dumb-buffer UAPI is only specified for known color modes. These
> values describe linear, single-plane RGB color formats or legacy index
> formats. Other values should not be specified. But some user space
> still does. So for unknown color modes, there are a number of known
> exceptions for which drm_mode_size_dumb() calculates the pitch from
> the bpp value, as before. All other values work the same but print
> an error.
> 
> v4:
> - use %u conversion specifier (Geert)
> - list DRM_FORMAT_Dn in UAPI docs (Geert)
> - avoid dmesg spamming with drm_warn_once() (Sima)
> - add more information about bpp special case (Sima)
> - clarify parameters for hardware alignment
> - add a TODO item for DUMB_CREATE2
> v3:
> - document the UAPI semantics
> - compute scanline pitch from for unknown color modes (Andy, Tomi)
> 
> Signed-off-by: Thomas Zimmermann 
> ---
>  Documentation/gpu/todo.rst         |  28 ++++++
>  drivers/gpu/drm/drm_dumb_buffers.c | 132 +++++++++++++++++++++++++++++
>  include/drm/drm_dumb_buffers.h     |  14 +++
>  include/uapi/drm/drm_mode.h        |  50 ++++++++++-
>  4 files changed, 223 insertions(+), 1 deletion(-)
>  create mode 100644 include/drm/drm_dumb_buffers.h
> 
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index c57777a24e03..f1bd741b06dc 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -515,6 +515,34 @@ Contact: Douglas Anderson 
>  
>  Level: Starter
>  
> +Implement a new DUMB_CREATE2 ioctl
> +----------------------------------
> +
> +The current DUMB_CREATE ioctl is not well defined. Instead of a pixel and
> +framebuffer format, it only accepts a color mode of vague semantics. Assuming
> +a linear framebuffer, the color mode gives and idea of the supported pixel
> +format. But userspace effectively has to guess the correct values. It really
> +only works reliable with framebuffers in XRGB8888. Userspace has begun to
> +workaround these limitations by computing arbitrary format's buffer sizes and
> +calculating their sizes in terms of XRGB8888 pixels.
> +
> +One possible solution is a new ioctl DUMB_CREATE2. It should accept a DRM
> +format and a format modifier to resolve the color mode's ambiguity. As
> +framebuffers can be multi-planar, the new ioctl has to return the buffer size,
> +pitch and GEM handle for each individual color plane.
> +
> +In the first step, the new ioctl can be limited to the current features of
> +the existing DUMB_CREATE. Individual drivers can then be extended to support
> +multi-planar formats. Rockchip might require this and would be a good candidate.
> +
> +In addition to the kernel implementation, there must be user-space support
> +for the new ioctl. There's code in Mesa that might be able to use the new
> +call.
> +
> +Contact: Thomas Zimmermann 
> +
> +Level: Advanced
> +
>  
>  Core refactorings
>  =================
> diff --git a/drivers/gpu/drm/drm_dumb_buffers.c b/drivers/gpu/drm/drm_dumb_buffers.c
> index 9916aaf5b3f2..97cd3dcb79f1 100644
> --- a/drivers/gpu/drm/drm_dumb_buffers.c
> +++ b/drivers/gpu/drm/drm_dumb_buffers.c
> @@ -25,6 +25,8 @@
>  
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  
> @@ -57,6 +59,136 @@
>   * a hardware-specific ioctl to allocate suitable buffer objects.
>   */
>  
> +static int drm_mode_align_dumb(struct drm_mode_create_dumb *args,
> +			       unsigned long hw_pitch_align,
> +			       unsigned long hw_size_align)
> +{
> +	u32 pitch = args->pitch;
> +	u32 size;
> +
> +	if (!pitch)
> +		return -EINVAL;
> +
> +	if (hw_pitch_align)
> +		pitch = roundup(pitch, hw_pitch_align);
> +
> +	/* overflow checks for 32bit size calculations */
> +	if (args->height > U32_MAX / pitch)
> +		return -EINVAL;
> +

check_mul_overflow(args->height, pitch, &size)?

> +	if (!hw_size_align)
> +		hw_size_align = PAGE_SIZE;
> +	else if (!IS_ALIGNED(hw_size_align, PAGE_SIZE))
> +		return -EINVAL; /* TODO: handle this if necessary */
> +
> +	size = ALIGN(args->height * pitch, hw_size_align);
> +	if (!size)
> +		return -EINVAL;
> +
> +	args->pitch = pitch;
> +	args->size = size;
> +
> +	return 0;
> +}
> +
> +/**
> + * drm_mode_size_dumb - Calculates the scanline and buffer sizes for dumb buffers
> + * @dev: DRM device
> + * @args: Parameters for the dumb buffer
> + * @hw_pitch_align: Hardware scanline alignment in bytes
> + * @hw_size_align: Hardware buffer-size alignment in bytes
> + *
> + * The helper drm_mode_size_dumb() calculates the size of the buffer
> + * allocation and the scanline size for a dumb buffer. Callers have to
> + * set the buffers width, height and color mode in the argument @arg.
> + * The helper validates the correctness of the input and tests for
> + * possible overflows. If successful, it returns the dumb buffer's
> + * required scanline pitch and size in &args.
> + *
> + * The parameter @hw_pitch_align allows the driver to specifies an
> + * alignment for the scanline pitch, if the hardware requires any. The
> + * calculated pitch will be a multiple of the alignment. The parameter
> + * @hw_size_align allows to specify an alignment for buffer sizes. The
> + * provided alignment should represent requirements of the graphics
> + * hardware. drm_mode_size_dumb() handles GEM-related constraints
> + * automatically across all drivers and hardware. For example, the
> + * returned buffer size is always a multiple of PAGE_SIZE, which is
> + * required by mmap().
> + *
> + * Returns:
> + * Zero on success, or a negative error code otherwise.
> + */
> +int drm_mode_size_dumb(struct drm_device *dev,
> +		       struct drm_mode_create_dumb *args,
> +		       unsigned long hw_pitch_align,
> +		       unsigned long hw_size_align)
> +{
> +	u64 pitch = 0;
> +	u32 fourcc;
> +
> +	/*
> +	 * The scanline pitch depends on the buffer width and the color
> +	 * format. The latter is specified as a color-mode constant for
> +	 * which we first have to find the corresponding color format.
> +	 *
> +	 * Different color formats can have the same color-mode constant.
> +	 * For example XRGB8888 and BGRX8888 both have a color mode of 32.
> +	 * It is possible to use different formats for dumb-buffer allocation
> +	 * and rendering as long as all involved formats share the same
> +	 * color-mode constant.
> +	 */
> +	fourcc = drm_driver_color_mode_format(dev, args->bpp);
> +	if (fourcc != DRM_FORMAT_INVALID) {
> +		const struct drm_format_info *info = drm_format_info(fourcc);
> +
> +		if (!info)
> +			return -EINVAL;
> +		pitch = drm_format_info_min_pitch(info, 0, args->width);
> +	} else if (args->bpp) {
> +		/*
> +		 * Some userspace throws in arbitrary values for bpp and
> +		 * relies on the kernel to figure it out. In this case we
> +		 * fall back to the old method of using bpp directly. The
> +		 * over-commitment of memory from the rounding is acceptable
> +		 * for compatibility with legacy userspace. We have a number
> +		 * of deprecated legacy values that are explicitly supported.
> +		 */
> +		switch (args->bpp) {
> +		default:
> +			drm_warn_once(dev,
> +				      "Unknown color mode %u; guessing buffer size.\n",
> +				      args->bpp);
> +			fallthrough;
> +		/*
> +		 * These constants represent various YUV formats supported by
> +		 * drm_gem_afbc_get_bpp().
> +		 */
> +		case 12: // DRM_FORMAT_YUV420_8BIT
> +		case 15: // DRM_FORMAT_YUV420_10BIT
> +		case 30: // DRM_FORMAT_VUY101010
> +			fallthrough;
> +		/*
> +		 * Used by Mesa and Gstreamer to allocate NV formats and others
> +		 * as RGB buffers. Technically, XRGB16161616F formats are RGB,
> +		 * but the dumb buffers are not supposed to be used for anything
> +		 * beyond 32 bits per pixels.
> +		 */
> +		case 10: // DRM_FORMAT_NV{15,20,30}, DRM_FORMAT_P010
> +		case 64: // DRM_FORMAT_{XRGB,XBGR,ARGB,ABGR}16161616F
> +			pitch = args->width * DIV_ROUND_UP(args->bpp, SZ_8);
> +			break;
> +		}
> +	}
> +
> +	if (!pitch || pitch > U32_MAX)
> +		return -EINVAL;
> +
> +	args->pitch = pitch;
> +
> +	return drm_mode_align_dumb(args, hw_pitch_align, hw_size_align);
> +}
> +EXPORT_SYMBOL(drm_mode_size_dumb);
> +
>  int drm_mode_create_dumb(struct drm_device *dev,
>  			 struct drm_mode_create_dumb *args,
>  			 struct drm_file *file_priv)
> diff --git a/include/drm/drm_dumb_buffers.h b/include/drm/drm_dumb_buffers.h
> new file mode 100644
> index 000000000000..1f3a8236fb3d
> --- /dev/null
> +++ b/include/drm/drm_dumb_buffers.h
> @@ -0,0 +1,14 @@
> +/* SPDX-License-Identifier: MIT */
> +
> +#ifndef __DRM_DUMB_BUFFERS_H__
> +#define __DRM_DUMB_BUFFERS_H__
> +
> +struct drm_device;
> +struct drm_mode_create_dumb;
> +
> +int drm_mode_size_dumb(struct drm_device *dev,
> +		       struct drm_mode_create_dumb *args,
> +		       unsigned long hw_pitch_align,
> +		       unsigned long hw_size_align);
> +
> +#endif
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index c082810c08a8..efe8f5ad35ee 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -1058,7 +1058,7 @@ struct drm_mode_crtc_page_flip_target {
>   * struct drm_mode_create_dumb - Create a KMS dumb buffer for scanout.
>   * @height: buffer height in pixels
>   * @width: buffer width in pixels
> - * @bpp: bits per pixel
> + * @bpp: color mode
>   * @flags: must be zero
>   * @handle: buffer object handle
>   * @pitch: number of bytes between two consecutive lines
> @@ -1066,6 +1066,54 @@ struct drm_mode_crtc_page_flip_target {
>   *
>   * User-space fills @height, @width, @bpp and @flags. If the IOCTL succeeds,
>   * the kernel fills @handle, @pitch and @size.
> + *
> + * The value of @bpp is a color-mode number describing a specific format
> + * or a variant thereof. The value often corresponds to the number of bits
> + * per pixel for most modes, although there are exceptions. Each color mode
> + * maps to a DRM format plus a number of modes with similar pixel layout.
> + * Framebuffer layout is always linear.
> + *
> + * Support for all modes and formats is optional. Even if dumb-buffer
> + * creation with a certain color mode succeeds, it is not guaranteed that
> + * the DRM driver supports any of the related formats. Most drivers support
> + * a color mode of 32 with a format of DRM_FORMAT_XRGB8888 on their primary
> + * plane.
> + *
> + * +------------+------------------------+------------------------+
> + * | Color mode | Framebuffer format     | Compatible formats     |
> + * +============+========================+========================+
> + * |     32     |  * DRM_FORMAT_XRGB8888 |  * DRM_FORMAT_BGRX8888 |
> + * |            |                        |  * DRM_FORMAT_RGBX8888 |
> + * |            |                        |  * DRM_FORMAT_XBGR8888 |
> + * +------------+------------------------+------------------------+
> + * |     24     |  * DRM_FORMAT_RGB888   |  * DRM_FORMAT_BGR888   |
> + * +------------+------------------------+------------------------+
> + * |     16     |  * DRM_FORMAT_RGB565   |  * DRM_FORMAT_BGR565   |
> + * +------------+------------------------+------------------------+
> + * |     15     |  * DRM_FORMAT_XRGB1555 |  * DRM_FORMAT_BGRX1555 |
> + * |            |                        |  * DRM_FORMAT_RGBX1555 |
> + * |            |                        |  * DRM_FORMAT_XBGR1555 |
> + * +------------+------------------------+------------------------+
> + * |      8     |  * DRM_FORMAT_C8       |  * DRM_FORMAT_D8       |
> + * |            |                        |  * DRM_FORMAT_R8       |
> + * +------------+------------------------+------------------------+
> + * |      4     |  * DRM_FORMAT_C4       |  * DRM_FORMAT_D4       |
> + * |            |                        |  * DRM_FORMAT_R4       |
> + * +------------+------------------------+------------------------+
> + * |      2     |  * DRM_FORMAT_C2       |  * DRM_FORMAT_D2       |
> + * |            |                        |  * DRM_FORMAT_R2       |
> + * +------------+------------------------+------------------------+
> + * |      1     |  * DRM_FORMAT_C1       |  * DRM_FORMAT_D1       |
> + * |            |                        |  * DRM_FORMAT_R1       |
> + * +------------+------------------------+------------------------+
> + *
> + * Color modes of 10, 12, 15, 30 and 64 are only supported for use by
> + * legacy user space. Please don't use them in new code. Other modes
> + * are not support.
> + *
> + * Do not attempt to allocate anything but linear framebuffer memory
> + * with single-plane RGB data. Allocation of other framebuffer
> + * layouts requires dedicated ioctls in the respective DRM driver.
>   */
>  struct drm_mode_create_dumb {
>  	__u32 height;

Reviewed-by: Tomi Valkeinen 

 Tomi



From xen-devel-bounces@lists.xenproject.org Thu Jun 12 08:36:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 08:36:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012542.1391026 (Exim 4.92)
	(envelope-from )
	id 1uPdQX-0003kU-Vv; Thu, 12 Jun 2025 08:36:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012542.1391026; Thu, 12 Jun 2025 08:36:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPdQX-0003kN-T1; Thu, 12 Jun 2025 08:36:49 +0000
Received: by outflank-mailman (input) for mailman id 1012542;
 Thu, 12 Jun 2025 08:36:48 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uPdQW-0003TD-1A
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 08:36:48 +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 60188bba-4768-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 10:36:46 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3a536ecbf6fso413200f8f.2
 for ; Thu, 12 Jun 2025 01:36:46 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-313c19b8102sm929743a91.10.2025.06.12.01.36.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 01:36:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 60188bba-4768-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749717406; x=1750322206; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=grYE1xGi9+XESSqACPod+6pa8Fv/O2qWhjpwug7vf/U=;
        b=IrsTmx98f9Mwu+/4Rh5IPrb42X21d5Ud45DdyF6YTCof3sm4pYY4TSAh7Uxv1Hd1Uc
         HQkTYyA/FJ3CyeTgUl0xu0IBHmTNz5idRza79uqwXhAjpcUmtLyEeH2DpAlIPxDvTT0Y
         RoG7EUF87be8nrYDxCHRmuTu/uM0b/OUqCMBrT7QdBacMgfLfywwdPW5M7E8ZwcCvhMN
         IyBGofTu01KTrgvSFO7zYjEYyZFphR0GOQWq59FsY5CDq2TG3mYpKD8UaQ6JcC7Sdjhz
         4w8oD7fTrgRFGCm52Nx3s6esHvbPDEqLmRJvQG6uM/IaQN7PNLhhiXC6yBow0kNixMSf
         GaKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749717406; x=1750322206;
        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=grYE1xGi9+XESSqACPod+6pa8Fv/O2qWhjpwug7vf/U=;
        b=F/1ET5N5HjJt8jK2QAU2iby7dsaLGGKudoVDwjVHGSM5SFJeejSfxEueJQRRxTIUF2
         tKxyCTaxCP6gYO/4cgu2FjmnneO+dbmni4kAiqWRIKQn3NB3UP57rdxXn3s/BRmz2aTX
         Jyw7A/2puOhZFyoLgrPgW/47bUZMA+t+P/veCMvMetL151gpOzMcugn5i8wWs6uvOvn3
         CH9blYSpmDJrkAMj/Jqi7YCJiJIhUE3n41kMyqfLCyqZxBQ4Rf2SiZt1P2q+/rA3HK3A
         wylxIA64N1cxox9lAfh1DFM3lsBYEp2iRSfzRIDaGcJbhdsy4TmGpVyIFKD/pfP3nvFy
         GIuQ==
X-Forwarded-Encrypted: i=1; AJvYcCW5nce4VjVVhzMnbjuQggqLTkctHVSRxK7LwBvRGin/1nhYSG3d9jU4UTMkREHEMh1arT/CIz4cE9I=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw9tlWMuzam7dZN4cboB9KA2oafeTMzEL30PSrx4tNsjmQoBKna
	LjS9+i6g9egLG9RxSz/ET8Ot0ztQ27rXnP06FxgDojyWyBhyAsHog9UmYnc+j37QEA==
X-Gm-Gg: ASbGncsqnew6IkcUtN8NeILKDxNhU92XmldDrTSIyFUE/MFpl7jCn/QjP4pFFqR4IHb
	/9ASGbg1Lst5AcjGGeahpqkfNTVomUXhUqru5TFHI9sieBFlePx0FGrz0PD4FwhBCVAEKwGhA4h
	0coac2KJ8nzqXUPut/NASZzVcnaWpt8UFSP5T+ukaq/Le0UaMufDBk7txiSkXFBwiUPYb/j3F6n
	L1nM2S0r7ZYxmmSloESx1D5kpHnphZ6YNs/1V2nmTffvH20tRUuKy3b5CRURaSy1crKK20yvDXE
	8cojfrY+IqhOdC34T2PrGHfQs8UTfR/U4vhVyLJEBhf9Bt+r5g22VdAkGDMylX1xwVHwQ4LCwf/
	/4xOGzYLbh9Svv3zimkv41mxkbdRuLDv10+rcqCJDuMf60ghxuAX50ZRDsA==
X-Google-Smtp-Source: AGHT+IHR4zrJXOvfDBz06WOUXoWgInC9gURrORWRUb1TOKs+7p7cBnn8ePnrZontMjlo5T/V17P8fA==
X-Received: by 2002:a05:6000:22ca:b0:3a5:2b75:56b3 with SMTP id ffacd0b85a97d-3a558695e5amr5342166f8f.24.1749717405762;
        Thu, 12 Jun 2025 01:36:45 -0700 (PDT)
Message-ID: <84080c88-b68f-4ab3-8b69-a3e45e9c74d9@suse.com>
Date: Thu, 12 Jun 2025 10:36:36 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 4/8] pdx: provide a unified set of unit functions
To: Roger Pau Monne 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD , xen-devel@lists.xenproject.org
References: <20250611171636.5674-1-roger.pau@citrix.com>
 <20250611171636.5674-5-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: <20250611171636.5674-5-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.06.2025 19:16, Roger Pau Monne wrote:
> @@ -80,6 +81,39 @@ unsigned long get_max_pfn(unsigned long top_pfn)
>      return pdx_to_pfn(pdx - 1) + 1;
>  }
>  
> +#ifndef CONFIG_PDX_NONE
> +
> +#ifdef CONFIG_X86
> +# include 
> +# define MAX_PFN_RANGES E820MAX
> +#elif defined(CONFIG_HAS_DEVICE_TREE)
> +# include 
> +# define MAX_PFN_RANGES NR_MEM_BANKS
> +#else
> +# error "Missing architecture maximum number of RAM ranges"
> +#endif
> +
> +/* Generic PFN compression helpers. */
> +static struct pfn_range {
> +    unsigned long base, size;
> +} ranges[MAX_PFN_RANGES] __initdata;
> +static unsigned int __initdata nr;

One other remark / nit: For my taste, "nr" isn't a suitable name for a static.
It's too short, and hence the risk is too high that some function would add a
local aliasing this one.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 08:43:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 08:43:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012556.1391035 (Exim 4.92)
	(envelope-from )
	id 1uPdWm-0005vv-Kh; Thu, 12 Jun 2025 08:43:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012556.1391035; Thu, 12 Jun 2025 08:43: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 1uPdWm-0005vo-HZ; Thu, 12 Jun 2025 08:43:16 +0000
Received: by outflank-mailman (input) for mailman id 1012556;
 Thu, 12 Jun 2025 08:43: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 1uPdWl-0005vi-FM
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 08:43:15 +0000
Received: from perceval.ideasonboard.com (perceval.ideasonboard.com
 [213.167.242.64]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 473f4130-4769-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 10:43:14 +0200 (CEST)
Received: from [192.168.88.20] (91-158-153-178.elisa-laajakaista.fi
 [91.158.153.178])
 by perceval.ideasonboard.com (Postfix) with ESMTPSA id 55F0C250;
 Thu, 12 Jun 2025 10:43:03 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 473f4130-4769-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;
	s=mail; t=1749717784;
	bh=DFZAKZf8wHZi/y9r247ZL0ZUXvFSN1yMyupDQcqZ3+0=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=P97DiLsEsf/6i8aVwoi/8/jCDHmL9CIaqVE6F1kh5oZibLMLuYmgz4R5sZGO7dayi
	 A9sBXgz1SuZs74C1VD4Xp16/e+PXSodQRenE1+LjsblMSGLXpOt87yMih54vtsY4Sp
	 87w8fmpZjBB9PIYbdL6yYmzS28ULBjvl9UmrLU2M=
Message-ID: 
Date: Thu, 12 Jun 2025 11:43:08 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 03/25] drm/gem-dma: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
To: Thomas Zimmermann 
Cc: dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org,
 freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
 imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org,
 nouveau@lists.freedesktop.org, virtualization@lists.linux.dev,
 spice-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org,
 linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
 intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org,
 simona@ffwll.ch, airlied@gmail.com, mripard@kernel.org,
 maarten.lankhorst@linux.intel.com, geert@linux-m68k.org
References: <20250311155120.442633-1-tzimmermann@suse.de>
 <20250311155120.442633-4-tzimmermann@suse.de>
Content-Language: en-US
From: Tomi Valkeinen 
Autocrypt: addr=tomi.valkeinen@ideasonboard.com; keydata=
 xsFNBE6ms0cBEACyizowecZqXfMZtnBniOieTuFdErHAUyxVgtmr0f5ZfIi9Z4l+uUN4Zdw2
 wCEZjx3o0Z34diXBaMRJ3rAk9yB90UJAnLtb8A97Oq64DskLF81GCYB2P1i0qrG7UjpASgCA
 Ru0lVvxsWyIwSfoYoLrazbT1wkWRs8YBkkXQFfL7Mn3ZMoGPcpfwYH9O7bV1NslbmyJzRCMO
 eYV258gjCcwYlrkyIratlHCek4GrwV8Z9NQcjD5iLzrONjfafrWPwj6yn2RlL0mQEwt1lOvn
 LnI7QRtB3zxA3yB+FLsT1hx0va6xCHpX3QO2gBsyHCyVafFMrg3c/7IIWkDLngJxFgz6DLiA
 G4ld1QK/jsYqfP2GIMH1mFdjY+iagG4DqOsjip479HCWAptpNxSOCL6z3qxCU8MCz8iNOtZk
 DYXQWVscM5qgYSn+fmMM2qN+eoWlnCGVURZZLDjg387S2E1jT/dNTOsM/IqQj+ZROUZuRcF7
 0RTtuU5q1HnbRNwy+23xeoSGuwmLQ2UsUk7Q5CnrjYfiPo3wHze8avK95JBoSd+WIRmV3uoO
 rXCoYOIRlDhg9XJTrbnQ3Ot5zOa0Y9c4IpyAlut6mDtxtKXr4+8OzjSVFww7tIwadTK3wDQv
 Bus4jxHjS6dz1g2ypT65qnHen6mUUH63lhzewqO9peAHJ0SLrQARAQABzTBUb21pIFZhbGtl
 aW5lbiA8dG9taS52YWxrZWluZW5AaWRlYXNvbmJvYXJkLmNvbT7CwY4EEwEIADgWIQTEOAw+
 ll79gQef86f6PaqMvJYe9QUCX/HruAIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRD6
 PaqMvJYe9WmFD/99NGoD5lBJhlFDHMZvO+Op8vCwnIRZdTsyrtGl72rVh9xRfcSgYPZUvBuT
 VDxE53mY9HaZyu1eGMccYRBaTLJSfCXl/g317CrMNdY0k40b9YeIX10feiRYEWoDIPQ3tMmA
 0nHDygzcnuPiPT68JYZ6tUOvAt7r6OX/litM+m2/E9mtp8xCoWOo/kYO4mOAIoMNvLB8vufi
 uBB4e/AvAjtny4ScuNV5c5q8MkfNIiOyag9QCiQ/JfoAqzXRjVb4VZG72AKaElwipiKCWEcU
 R4+Bu5Qbaxj7Cd36M/bI54OrbWWETJkVVSV1i0tghCd6HHyquTdFl7wYcz6cL1hn/6byVnD+
 sR3BLvSBHYp8WSwv0TCuf6tLiNgHAO1hWiQ1pOoXyMEsxZlgPXT+wb4dbNVunckwqFjGxRbl
 Rz7apFT/ZRwbazEzEzNyrBOfB55xdipG/2+SmFn0oMFqFOBEszXLQVslh64lI0CMJm2OYYe3
 PxHqYaztyeXsx13Bfnq9+bUynAQ4uW1P5DJ3OIRZWKmbQd/Me3Fq6TU57LsvwRgE0Le9PFQs
 dcP2071rMTpqTUteEgODJS4VDf4lXJfY91u32BJkiqM7/62Cqatcz5UWWHq5xeF03MIUTqdE
 qHWk3RJEoWHWQRzQfcx6Fn2fDAUKhAddvoopfcjAHfpAWJ+ENc7BTQROprNHARAAx0aat8GU
 hsusCLc4MIxOQwidecCTRc9Dz/7U2goUwhw2O5j9TPqLtp57VITmHILnvZf6q3QAho2QMQyE
 DDvHubrdtEoqaaSKxKkFie1uhWNNvXPhwkKLYieyL9m2JdU+b88HaDnpzdyTTR4uH7wk0bBa
 KbTSgIFDDe5lXInypewPO30TmYNkFSexnnM3n1PBCqiJXsJahE4ZQ+WnV5FbPUj8T2zXS2xk
 0LZ0+DwKmZ0ZDovvdEWRWrz3UzJ8DLHb7blPpGhmqj3ANXQXC7mb9qJ6J/VSl61GbxIO2Dwb
 xPNkHk8fwnxlUBCOyBti/uD2uSTgKHNdabhVm2dgFNVuS1y3bBHbI/qjC3J7rWE0WiaHWEqy
 UVPk8rsph4rqITsj2RiY70vEW0SKePrChvET7D8P1UPqmveBNNtSS7In+DdZ5kUqLV7rJnM9
 /4cwy+uZUt8cuCZlcA5u8IsBCNJudxEqBG10GHg1B6h1RZIz9Q9XfiBdaqa5+CjyFs8ua01c
 9HmyfkuhXG2OLjfQuK+Ygd56mV3lq0aFdwbaX16DG22c6flkkBSjyWXYepFtHz9KsBS0DaZb
 4IkLmZwEXpZcIOQjQ71fqlpiXkXSIaQ6YMEs8WjBbpP81h7QxWIfWtp+VnwNGc6nq5IQDESH
 mvQcsFS7d3eGVI6eyjCFdcAO8eMAEQEAAcLBXwQYAQIACQUCTqazRwIbDAAKCRD6PaqMvJYe
 9fA7EACS6exUedsBKmt4pT7nqXBcRsqm6YzT6DeCM8PWMTeaVGHiR4TnNFiT3otD5UpYQI7S
 suYxoTdHrrrBzdlKe5rUWpzoZkVK6p0s9OIvGzLT0lrb0HC9iNDWT3JgpYDnk4Z2mFi6tTbq
 xKMtpVFRA6FjviGDRsfkfoURZI51nf2RSAk/A8BEDDZ7lgJHskYoklSpwyrXhkp9FHGMaYII
 m9EKuUTX9JPDG2FTthCBrdsgWYPdJQvM+zscq09vFMQ9Fykbx5N8z/oFEUy3ACyPqW2oyfvU
 CH5WDpWBG0s5BALp1gBJPytIAd/pY/5ZdNoi0Cx3+Z7jaBFEyYJdWy1hGddpkgnMjyOfLI7B
 CFrdecTZbR5upjNSDvQ7RG85SnpYJTIin+SAUazAeA2nS6gTZzumgtdw8XmVXZwdBfF+ICof
 92UkbYcYNbzWO/GHgsNT1WnM4sa9lwCSWH8Fw1o/3bX1VVPEsnESOfxkNdu+gAF5S6+I6n3a
 ueeIlwJl5CpT5l8RpoZXEOVtXYn8zzOJ7oGZYINRV9Pf8qKGLf3Dft7zKBP832I3PQjeok7F
 yjt+9S+KgSFSHP3Pa4E7lsSdWhSlHYNdG/czhoUkSCN09C0rEK93wxACx3vtxPLjXu6RptBw
 3dRq7n+mQChEB1am0BueV1JZaBboIL0AGlSJkm23kw==
In-Reply-To: <20250311155120.442633-4-tzimmermann@suse.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi,

On 11/03/2025 17:47, Thomas Zimmermann wrote:
> Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
> buffer size. Align the pitch to a multiple of 8.
> 
> Push the current calculation into the only direct caller imx. Imx's
> hardware requires the framebuffer width to be aligned to 8. The
> driver's current approach is actually incorrect, as it only guarantees
> this implicitly and requires bpp to be a multiple of 8 already. A
> later commit will fix this problem by aligning the scanline pitch
> such that an aligned width still fits into each scanline's memory.
> 
> A number of other drivers are build on top of gem-dma helpers and
> implement their own dumb-buffer allocation. These drivers invoke
> drm_gem_dma_dumb_create_internal(), which is not affected by this
> commit.
> 
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/drm_gem_dma_helper.c     | 7 +++++--
>  drivers/gpu/drm/imx/ipuv3/imx-drm-core.c | 2 ++
>  2 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem_dma_helper.c b/drivers/gpu/drm/drm_gem_dma_helper.c
> index b7f033d4352a..49be9b033610 100644
> --- a/drivers/gpu/drm/drm_gem_dma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_dma_helper.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -304,9 +305,11 @@ int drm_gem_dma_dumb_create(struct drm_file *file_priv,
>  			    struct drm_mode_create_dumb *args)
>  {
>  	struct drm_gem_dma_object *dma_obj;
> +	int ret;
>  
> -	args->pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
> -	args->size = args->pitch * args->height;
> +	ret = drm_mode_size_dumb(drm, args, SZ_8, 0);
> +	if (ret)
> +		return ret;
>  
>  	dma_obj = drm_gem_dma_create_with_handle(file_priv, drm, args->size,
>  						 &args->handle);
> diff --git a/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c b/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
> index ec5fd9a01f1e..e7025df7b978 100644
> --- a/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
> +++ b/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
> @@ -145,6 +145,8 @@ static int imx_drm_dumb_create(struct drm_file *file_priv,
>  	int ret;
>  
>  	args->width = ALIGN(width, 8);
> +	args->pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
> +	args->size = args->pitch * args->height;
>  
>  	ret = drm_gem_dma_dumb_create(file_priv, drm, args);
>  	if (ret)

Won't the pitch and size just be overwritten by the
drm_gem_dma_dumb_create() call?

 Tomi



From xen-devel-bounces@lists.xenproject.org Thu Jun 12 08:44:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 08:44:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012562.1391046 (Exim 4.92)
	(envelope-from )
	id 1uPdYE-0006Ru-Tt; Thu, 12 Jun 2025 08:44:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012562.1391046; Thu, 12 Jun 2025 08:44: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 1uPdYE-0006Rn-Qo; Thu, 12 Jun 2025 08:44:46 +0000
Received: by outflank-mailman (input) for mailman id 1012562;
 Thu, 12 Jun 2025 08:44: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 1uPdYD-0006Rh-DD
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 08:44:45 +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 7c4adf44-4769-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 10:44:43 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3a528243636so423552f8f.3
 for ; Thu, 12 Jun 2025 01:44:43 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2364e61b557sm8906275ad.2.2025.06.12.01.44.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 01:44:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7c4adf44-4769-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749717882; x=1750322682; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=lauzLp4/BtyBk+0Qg2N8B8scQ9CseikuBjgHC7SlwKs=;
        b=Oi0bFUStnusOoEvO176C0QfDe+cekK6ZWdf1+8z6VHpYr8L+ZkAt3hyi8k7yhES9l+
         bnyj9hasf1DY5uK6DxNZM/X+V6PwTtuKKV/NzGy2iZ+to62ggG2Pz3R+OG9VmkUB6H4k
         4bpqYC1J6eLXf7ElDTyNmoQg9bQSFJm/Fo0hdFnS6GGzrVHb8nRXBZM9xA5/spE1PPrw
         rLEfCFxVs3x79Q4qzKVwOm8ZG5uK9Rmd98HsDSJfqC70+a3BzHcPwZ4tIBWO7xKEBiUI
         Etd+lH0qe2iVnsU8i/U50fPbtBQQEYUTL3hgxwoG0nAAQ0b9UCWspQOnlblUyB6UL+iv
         cziA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749717882; x=1750322682;
        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=lauzLp4/BtyBk+0Qg2N8B8scQ9CseikuBjgHC7SlwKs=;
        b=NbCSIX7qCnRKHCj3wSRKYDCoy1Y4Zjj15too870tz9FPTDP76t3zCTcAsle10xKKKd
         eTQ3wzeNxZgk8GkYi8zm6upXWhNvJHWOeJZZf8CUVM9xZk7FyCptiXivkcEOGhYSjRgL
         eoo3PTMqz0lEGkADnKz6dC15BKBF8e5OAb3tr9ATdwhzDSvTb1TmHzaOoX/0Qc43sKlL
         Lvbvw1u9p76TZj4mHn8IpDN6PF4f2Qj5/lEVdzatXg/iSeohdRo4ytAQ6FguE8egCvSs
         N1ultF8svAbkjIc73qUhMMcK9HU8ApgYbzAZ81DXutkd4GwQbR09/bC9HZG9kxadFCHt
         aNeQ==
X-Forwarded-Encrypted: i=1; AJvYcCWo73ezeTvqRcqqxJqmXJH3OA2oc3WSXfPY3JSSqD3yk9OpxwOQYu2LLqgyU0iKk0Mv5E8zigv1zkI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxBdU7vM2psHd/gMDoyyCquEcgWAfUvmwXBfKty63zrJOoGw14D
	UqP7rsQdpk5brXOjxpDFldwGRVfn2IXfHGMh1AiaXG9rxhLBOIGjCmNEDBM14YgxfQ==
X-Gm-Gg: ASbGncvPYlREdqAW4OtYp2e2eZqePzRg+fwYB678F8phb8fnfcGGhtL/Qyvgq67c3kc
	0r6qagjkb1KstamPhbMrW/NvxQkO/Y3MBvCDj06WV9inHCL6duxDQNTk3Vew4Rw2P2MFUkXGC7w
	EKN2NMqkBp+Hw+8RYrPPVY917vVTCSFdeAG6vNW/U+epXdxFnaqELxTkxoTeYvP5f7p/bTqHmMS
	D/EqCtlNbeQ0SzzIB8CFJq0HzEz6kuRNJcM/XlrvdffcLzSilOmnfDCeeu4vFDeJ2e8BYfF0gEA
	UPvBZIcP/VLZnc4EIDGiOddBhq7uNCCLgmCwocDLe3uXeudkYVZTWaR9HqyISiRLvWvcuHXkIhh
	nnuX/1WDTLAaeuuBlOKHt7vd5luOM96iVEKmyxT/iD85/qo0=
X-Google-Smtp-Source: AGHT+IH5acxiR+LiqzrlaqbDD78/RRFeItz3s6x8W6APCnK6Q3D/1CxtdS6BzGpofqrDr3NlAS7GRA==
X-Received: by 2002:a05:6000:3106:b0:3a4:d975:7d6f with SMTP id ffacd0b85a97d-3a56076b241mr2124525f8f.39.1749717882576;
        Thu, 12 Jun 2025 01:44:42 -0700 (PDT)
Message-ID: <51b5ddd4-6abc-4228-a2d6-fec349a16bfb@suse.com>
Date: Thu, 12 Jun 2025 10:44:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 06/12] x86/hyperlaunch: obtain cmdline from device tree
To: Alejandro Vallejo 
Cc: "Daniel P. Smith" ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini ,
 Bertrand Marquis , Denis Mukhin
 , xen-devel@lists.xenproject.org,
 Jason Andryuk 
References: <20250429123629.20839-1-agarciav@amd.com>
 <20250429123629.20839-7-agarciav@amd.com>
 <59f37fcc-9226-46c5-8dc8-7bd2100d8f59@amd.com>
 <02ffa9cf-b5cd-431a-834a-a11bbf310196@suse.com>
 <03be429c-063d-4467-91e7-7ef2e148a2fb@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 12.06.2025 10:20, Alejandro Vallejo wrote:
> On Wed Jun 11, 2025 at 7:35 AM CEST, Jan Beulich wrote:
>> On 10.06.2025 19:39, Jason Andryuk wrote:
>>>
>>>
>>> On 2025-06-10 02:56, Jan Beulich wrote:
>>>> On 09.06.2025 19:07, Jason Andryuk wrote:
>>>>> On 2025-04-29 08:36, Alejandro Vallejo wrote:
>>>>>> From: "Daniel P. Smith" 
>>>>>>
>>>>>> Add support to read the command line from the hyperlaunch device tree.
>>>>>> The device tree command line is located in the "bootargs" property of the
>>>>>> "multiboot,kernel" node.
>>>>>>
>>>>>> A boot loader command line, e.g. a grub module string field, takes
>>>>>> precendence over the device tree one since it is easier to modify.
>>>>>>
>>>>>> Signed-off-by: Daniel P. Smith 
>>>>>> Signed-off-by: Jason Andryuk 
>>>>>> Signed-off-by: Alejandro Vallejo 
>>>>>> Reviewed-by: Denis Mukhin 
>>>>>> ---
>>>>>
>>>>>> diff --git a/xen/common/domain-builder/fdt.c b/xen/common/domain-builder/fdt.c
>>>>>> index cbb0ed30a2..dabe201b04 100644
>>>>>> --- a/xen/common/domain-builder/fdt.c
>>>>>> +++ b/xen/common/domain-builder/fdt.c
>>>>>> @@ -219,6 +219,12 @@ static int __init fdt_process_domain_node(
>>>>>>                printk(XENLOG_INFO "  kernel: multiboot-index=%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] )
>>>>>
>>>>> The logic is incorrect - it should be:
>>>>>
>>>>>              if ( !bd->kernel->cmdline_pa ||
>>>>>                   !((char *)__va(bd->kernel->cmdline_pa))[0] )
>>>>>
>>>>> If there is no cmdline_pa (which happens with the "reg" property) or the if there is a 0-length string, then check the DT for bootargs.
>>>>
>>>> Even that sounds bogus to me: There's a difference between "no command line"
>>>> and "empty command line".
>>>
>>> Yes, you have a point.  The difficulty is grub always provides a NUL terminated string, so Xen can't differentiate the two.
>>
>> Which may call for either special-casing GrUB, or at least calling out that
>> behavior in the comment. (Ideally we'd still have a way to distinguish
>> between both cases, but likely we'll need to resort to documenting that some
>> dummy option will need adding to tell "none" from [intended to be] empty.)
> 
> We can add suitable comments where required, sure.
> 
> About the dummy option, note that even if we have an option for Xen, that does
> nothing for the kernel cmdlines. If there's such dummy option there I don't know
> of it.

Indeed I meant we may need to introduce something.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 08:52:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 08:52:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012572.1391056 (Exim 4.92)
	(envelope-from )
	id 1uPdfu-0008MZ-IP; Thu, 12 Jun 2025 08:52:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012572.1391056; Thu, 12 Jun 2025 08:52: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 1uPdfu-0008MS-FO; Thu, 12 Jun 2025 08:52:42 +0000
Received: by outflank-mailman (input) for mailman id 1012572;
 Thu, 12 Jun 2025 08:52: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 1uPdft-0008MM-JT
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 08:52:41 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20618.outbound.protection.outlook.com
 [2a01:111:f403:2413::618])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 97a4fefc-476a-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 10:52:39 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 DM4PR12MB7765.namprd12.prod.outlook.com (2603:10b6:8:113::5) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8835.18; Thu, 12 Jun 2025 08:52:34 +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.8835.018; Thu, 12 Jun 2025
 08:52: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: 97a4fefc-476a-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=A5Y1P4utXOv0SQyZMcdJcrEXgMIOc+ALbb7QaSSu40P2xV0xTAMFr8JpFX/6nv/DoT/3qaofz5N4veZC0RdVgsq129E3gGlfRLDttAhQEBHCX4kQ4zMZ3rGmVOYuZRBYGu5bxTIndlI7T42x+lsAAqs4ht6j/RzLZ3KrFz2eJMfqh7DSP4nLk6ePkOFPjYm17Nz4jdQ47uSYEAP16whyQlvrlTjHZcqhPaOfPeIQq3r4DL4vlNPCYenotTZaEwloj4ZLoLRieQzC7B9MFQzxkczLyqlDarFjMK6Ju0xStC+QIVbY79/RfIBP/09vFTEglAitEQBo8RpOeOVuh4asRQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=F/4jvNZPuWm3c3d4IO3W2lqiZnh5sZ6CklXP0yytoWI=;
 b=KllRd+gssFMgizH3OuUdUHESs7cr9Rx0AqczFVdz8kWLZ80tzTZUeT61qYIuHlRtSGe5WXVcW5JspMrp5T4DzgvgP9CuyA62IYs9HrRgSO+CoRba5ptRDikWJPNJNFBWsqyuhAuHcNcb12UzHsQl8lyCfn7LlThpapcPyRhW4iDj7DYzCviSDsdP5w50B5XE78gngBcpKd8miI6elRyLqE9iZHVJ0F1CIOmotHxv+ypLutg7LygGdSwlwJixTA8rTb5AZDFyc0s4hq9tbD3pkk0udVbPPMw5/zQq0WipTZMrJWN+QRY1UShHTLp3xCEfriNFy4CorNHhHzxnpbDPdg==
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=F/4jvNZPuWm3c3d4IO3W2lqiZnh5sZ6CklXP0yytoWI=;
 b=N+hjqRXDKNWUJeafSwhdhWHYraY79o9OEXhC+vWvoW6b6OEdIODkFRboHbDem0OiQw1E6agZvdoixhUKAqRJQZqeHgKmmFT3o4Ha2Tr0s++h0/8aNa659w4fAKApjQhVViChhDIKtx4HbBW5xT6Y/UPdT/Zdz5653syE1ZB3+vE=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Andrew Cooper
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Anthony PERARD , "Orzel,
 Michal" , Julien Grall , Stefano
 Stabellini , "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v4 03/20] xen/x86: remove "depends on !PV_SHIM_EXCLUSIVE"
Thread-Topic: [PATCH v4 03/20] xen/x86: remove "depends on !PV_SHIM_EXCLUSIVE"
Thread-Index: AQHbz7Fj+78Jf3bO30Wr1Bk6dRI84bP8b/QAgAJ/5nCAAEBpgIAAEbfA
Date: Thu, 12 Jun 2025 08:52:33 +0000
Message-ID:
 
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
 <20250528091708.390767-4-Penny.Zheng@amd.com>
 <1a73c720-012a-4795-9f47-f9c23b643de1@suse.com>
 
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=True;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-06-12T08:51:54.0000000Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=3;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged
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_|DM4PR12MB7765:EE_
x-ms-office365-filtering-correlation-id: daf98ac8-9062-404a-c178-08dda98e790c
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?eWhBWEdFcjBKS0p0dkY0bi9rakI1SVhabjFhUFN1OHJFWDFDUXZZZE1mWVB1?=
 =?utf-8?B?NzNCWHd3UDREK1B6cVFGV2ZuUHZLWXRVY1FvUUZiL1hyV2F5c0c2cmNvOTNu?=
 =?utf-8?B?aVkyaVNYdnozYjFZalI2TytvQWpBQ0RBVGRjSlNZRGlnTFhUK3ZZVHdNbEVh?=
 =?utf-8?B?Q0xZVUQ4UER2d3l4bUh2ZzgvUzNHSHNlMTU5dW1GUVFMV3Q2U1VqUkE0bENx?=
 =?utf-8?B?dkRQZVZpMk13cisvQVpXYWpaNExhTFN1UENaQThBMkgxMWEwckEyY1p1RFhn?=
 =?utf-8?B?b0NJSlFkaU5ZTmZ4SGloUVYydmtRbVFENFhTLzJxWXZXUDE1QWRyVXNQWmJY?=
 =?utf-8?B?R1UxbEVMUEwwa3oyT0tVR2trZjhZWXNNS0U1RFl1MlJIM25oODR3WU55bUI5?=
 =?utf-8?B?cTJ5dXZiSCswOFkydlQ4alJWWGxzdWc3ZHo2c2NzSzdRZlZHV0FCRm8vTGo5?=
 =?utf-8?B?MGpHczc2UlJuY3czTVNraXpBbXB6YU1jTEFKaEt1UGhPL2NJQk1mWmdpQjJ0?=
 =?utf-8?B?UVREN1pTQ01vSlp5TmQ0OU82NWlnRWQ5dGQ3RTBIQVRsRjdhWDFBMWcwU2Uw?=
 =?utf-8?B?YSs2bUFWVmJ4L0krNkJQMVJsSEFnU3QvRzBqNlV4bDJpeUNYRFI5b0ZqVFFE?=
 =?utf-8?B?MFIzQjJjK2wydnR5SUNaaDVpZUZxOFRaMUJUQ0p3L1hIWS83OS91Slduc3Za?=
 =?utf-8?B?Y3k5algzM2RhdTNmRGdKOTI3bHE0VUR2KzRJVnRJU1o5RFdXODFlUlV2ckU3?=
 =?utf-8?B?WU4xYWE0MXdRZ2lmRDUwV0JiOE5uYldPR0NucTBkU0dxZjlkTWdTbXhiZFUx?=
 =?utf-8?B?VTVuQm51c1U1ZDRZSmdOVlBMM3M3UEdlampJcnpIcHRYTDdkRFl2ZFhzeHhw?=
 =?utf-8?B?WHdIVGJySzFqOHl5VG9pcERjWU9zeDdYZU5FeWZqT2VSaUI5L05sZTRtMkdi?=
 =?utf-8?B?Nk9oVWpZTHBqMWxSUEJlZlRFTGRMUjczZnd4VytHZzAvNS94cmRYRFA2empr?=
 =?utf-8?B?SmpuRGFwSVhkY2dYU05OTnNuRVdqeERVTjYzd0EwSW9VZDk0dkh1L3cySmp1?=
 =?utf-8?B?MUt2bzRWKzY1V3N3R0lWSzZjaFlUOUcrOG9weHVnNWo1VTB0ZU0xWUw0ZldR?=
 =?utf-8?B?V01LbWsxOGc2V2g4UEkxWEdpUWZaWkdSb2c5WHl4aDJwejdKTTJwN3hoei9W?=
 =?utf-8?B?WGFkOTcxcCtQbEVFenpBNU1LSFNVbThQcHZsbk44c0dkMmVMTWgxMStFWTNh?=
 =?utf-8?B?S3dyRlNGaE1lSFBhaDQ2WjlUa1l4RHdRRWoxb29DMXpCQjRXdnhGdWF6Ulh2?=
 =?utf-8?B?KzhqTkh6WHJqMURzWk12d3l1MWhNZEZ5aFpzUDZYSXlEQUdZbjcyTHNiY3g1?=
 =?utf-8?B?T3dKM0lvckQ4aEJRMEpKZTZWT1MvZnQ1eTVsRUlsSGxhVHVBdVh3N0g1bDlT?=
 =?utf-8?B?UnZxaXY3aEZsbWVxUHdZWjVsL1VCRTlPRTVqQmV1K0prYlNYbGFmQVVMWEMr?=
 =?utf-8?B?ZkkvNzFVWDBTTzZwTitLQS8rM2JoeHNvdm1JYjZPKzdkanY0UUlQcE5sQlJw?=
 =?utf-8?B?MUtmZ0Q5cDVFaXg4UDVEd2FJM3NBY0FZZElLWkNIN29sZGxPQXo2S1VMTiti?=
 =?utf-8?B?MjB0QUZuZFIrZXI5d1E3RE1jenJDeXRkRTdCdk9USTUvUS9KWldEZmdZNGto?=
 =?utf-8?B?OUlMOVd6ZWlFazVMSGx4ZjhsM3dWUSthRTVIeW9xN2RxSDFETUFGWjUyZjhH?=
 =?utf-8?B?ZFhtejNpMUV6K2crTzdWbGJZdDV3eTF0WGJQcGFzZjVjelhFc0hlV3M5aHRV?=
 =?utf-8?B?ZUhjTExWa3JFTlcwRUdRM0tweDhoUGhHMHZCaEc0a3FzcW81L2l2T3ByaS9Z?=
 =?utf-8?B?Yy92ZEVZU0orWDl4VUpZNi9ySnhMQW0vZ2ZEanJHQ1A3WW5SaUVsV3FZdnd6?=
 =?utf-8?B?VWRlY25LbkdRYjdtRWduNGFra0JqdVJaano5a2l2QmQ2SWk1blVPUXM5enZX?=
 =?utf-8?Q?nJZHPJ6LSMz6PLQBBvuRp0CnQsKnhA=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)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?M3Y5RWdTNkRkZDk5N3BncFY3dVRkYWN2U1B6VVRUTVhjUzFVTW41Y3Z1aXlM?=
 =?utf-8?B?cjNCNFM3N1dFMTlrOFlPcVNCWHpZek1kNHd4WlBURTVuekVwWkluUEJXTEFL?=
 =?utf-8?B?d2syZGRtNXJod2NUcTV3U2w0amsrSGZoRWlUaVVNT0NYVWErVFFsNjFPazJP?=
 =?utf-8?B?azFWV0ZNUTRsSnVZTmd4d25yM0lZZ2RuNnNmR290YytTSmRJSVlleVNaeHI3?=
 =?utf-8?B?TFE3QXFsY2MzUkZ2N3FjMHRIZ3U0Mi9GdmdzdlpBdndyVXQ2L3RFK2xTTU40?=
 =?utf-8?B?UkRFaElHbXhwb080VkQvL01IOVJybVBscFd1YnZWeE1pbHV2aERXY1BHNXJM?=
 =?utf-8?B?VU42Q1lkc2Y4a1p1M2lnYXprUi9CRkpQRCtzdFNPUTF0Q1pQdVNaQnNHOXYy?=
 =?utf-8?B?R3hiL0hqMklSV1ZhWXBabU9ZbWVXWXEzMEpHRW1TWmI3VFpBVDYwb1FkMi9p?=
 =?utf-8?B?bHlRajRPa2dqYXF2bDN2ZzVKTGFrNkpVNG42OWs2aEs1NGFIbjEyck9xWkhZ?=
 =?utf-8?B?SWNqNG1XSDZCcnlJclJtTGJTTGYzNTU2ZFdBQjJBL0xCckp3akR3dkpiei9J?=
 =?utf-8?B?U2p3T1ZORi9EYVp2V284a2hxOVdXS2ttZ1ZFMC8vb3pwUk0wUGRtT3plWDM1?=
 =?utf-8?B?ZUlxUmlJa0JwMWNFdzUyeGhUSlRIdTA5Y3hPSjQ0Q3hsUkFQRm9xMmY0ajEr?=
 =?utf-8?B?RFJQMWNFZlBJWnNVNmdoaGFXWGFXU2gzY2EyQjh5RGJiUFBnSFRMUWQ5WmRF?=
 =?utf-8?B?bm5JYnF0YS8rSDNoS0NpWWxUMTdhalR6VjF4bWpXajB6U29uN0JJeUR0dXps?=
 =?utf-8?B?OFlkYUxKaXBSbUlqOGhQRGFRSWw2bGRwRDM1Yzlqamk5SmkzbUJkaWRiVWQw?=
 =?utf-8?B?NHhUMHk0QXhzUlNhNDZuODJ5Wm1tenVJc3hwYzhvdWNUcStaUkNjcDNWRm42?=
 =?utf-8?B?K1FPNkhiazc3ZFhvN28xOXpSNGN0VVZGRXNqQjE5TGd5RDJlTm91bU8zbVd4?=
 =?utf-8?B?bndzRDFRYU9zRkxESWZ1b08yaU1BaXNwR2RZZ1NzaTEzaWR0Y3JiMkY3cnYw?=
 =?utf-8?B?bzZkWWcrbmRYYXI4cXllcnFVVHd4NVprVGJ1bzN6MEwxZXd3V3k5WFZqcGxG?=
 =?utf-8?B?ZXBaNk5GR1Bpc1h3ZTREZTlLQ1ZzNVU2ajhOUS91Y3pKQm5rUzRCMG9pNXB1?=
 =?utf-8?B?b0lLWjY3dURLMG1KM2hvK3NsY2d1TkFacmFsc2Y1aGRHZ3U0TVlRMFl6Rmpo?=
 =?utf-8?B?Y2xRSnNERjhHVWY1TTZuZk1uTHZaTjd4RWV1UjRZeXNvME9sS1hybEdWcThG?=
 =?utf-8?B?aEd5TE0zWXRZUjV3bVhhVVFNdGZLdHhrc09jdWpuR3Z2MkRWM0VTc3diZ0w4?=
 =?utf-8?B?aFMwNm9XY1dJS2VVcDdSbTk2ZzV5ejJZQk1mMDBwV044L0JCWnZkRnRsTVNN?=
 =?utf-8?B?UVNMWWtKNEJxRkFET2NiVkJkZm9FQXJwRWpIMVNoM1hTdWpHcmlySVEzdHFq?=
 =?utf-8?B?WldUQ1JvWi9TZDVhcllJeVhSWGlTNkhka3dVWVpqNEFCTzNKdDBDTU03NXl4?=
 =?utf-8?B?cmZwamRTeUNkcTU3SzE2Tmg4djg1cG9zUmUzOEIzNUJMSjlTd04vcExFdmZI?=
 =?utf-8?B?RWFwd2prd2Vna1Q2b0NWdlZjUkM2SmUvTkZzRGJFbEpRUHpKS3FiWWZDZmNN?=
 =?utf-8?B?UEhXTkwrWmhhZllUQjFxUjN0M0lOS0pBUjRXWkV6djJzWktVM1dJOVU5MWNj?=
 =?utf-8?B?ZnhoSllPR0IrUHk5bjBuUkJCblVob0U2ZkxVYU5OSEVsREpVK0ZKUWkwYzJz?=
 =?utf-8?B?VHZDLzRzYUc5VGw1MXlENmF0aW01NWIwZ21veWNIRkZyRkxBVWlocGZqOFda?=
 =?utf-8?B?Q1gzMHh1S0hLc2xUUGFUT0tLWEhLLzI0emVBMWpDclA3QTd0V1hJSUFsc3Iz?=
 =?utf-8?B?R0N0MXNOS1BIZlc4NDdtcXkzN1JER2hlZmxkbTZYZWxZTVdDN0ltdjZxQmVa?=
 =?utf-8?B?WFlaNDhRaVJWMk03VTc5MllaclBCM1V3Njl0bE03aloxUHdhamdtcTI0eFVl?=
 =?utf-8?B?RDVjdFNQcGRqUjV6Unl4cVgyUlJBVnZ6aUZHK1RaV3lwWW5aODFSYXI5enUy?=
 =?utf-8?Q?TCbo=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: daf98ac8-9062-404a-c178-08dda98e790c
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2025 08:52:33.7762
 (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: 9iFVGGk/W4aj3zEyLvN5rcxLk19DNSuh6sVDxPgacZrxbToNltTH/R7kr+yGSHqPc/lRQNVdW5ySkKxXBBXOlg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB7765

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDEyLCAyMDI1
IDM6MDIgUE0NCj4gVG86IFBlbm55LCBaaGVuZyA8cGVubnkuemhlbmdAYW1kLmNvbT4NCj4gQ2M6
IEh1YW5nLCBSYXkgPFJheS5IdWFuZ0BhbWQuY29tPjsgQW5kcmV3IENvb3Blcg0KPiA8YW5kcmV3
LmNvb3BlcjNAY2l0cml4LmNvbT47IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXgu
Y29tPjsNCj4gQW50aG9ueSBQRVJBUkQgPGFudGhvbnkucGVyYXJkQHZhdGVzLnRlY2g+OyBPcnpl
bCwgTWljaGFsDQo+IDxNaWNoYWwuT3J6ZWxAYW1kLmNvbT47IEp1bGllbiBHcmFsbCA8anVsaWVu
QHhlbi5vcmc+OyBTdGVmYW5vIFN0YWJlbGxpbmkNCj4gPHNzdGFiZWxsaW5pQGtlcm5lbC5vcmc+
OyB4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSCB2
NCAwMy8yMF0geGVuL3g4NjogcmVtb3ZlICJkZXBlbmRzDQo+IG9uICFQVl9TSElNX0VYQ0xVU0lW
RSINCj4NCj4gT24gMTIuMDYuMjAyNSAwNjowOSwgUGVubnksIFpoZW5nIHdyb3RlOg0KPiA+PiAt
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBKYW4gQmV1bGljaCA8amJldWxp
Y2hAc3VzZS5jb20+DQo+ID4+IFNlbnQ6IFR1ZXNkYXksIEp1bmUgMTAsIDIwMjUgOTowMSBQTQ0K
PiA+Pg0KPiA+PiBPbiAyOC4wNS4yMDI1IDExOjE2LCBQZW5ueSBaaGVuZyB3cm90ZToNCj4gPj4+
IFJlbW92ZSBhbGwgImRlcGVuZHMgb24gIVBWX1NISU1fRVhDTFVTSVZFIiAoYWxzbyB0aGUgZnVu
Y3Rpb25hbGx5DQo+ID4+PiBlcXVpdmFsZW50ICJpZiAhLi4uIikgaW4gS2NvbmZpZyBmaWxlLCBz
aW5jZSBuZWdhdGl2ZSBkZXBlbmRhbmN5DQo+ID4+PiB3aWxsIGJhZGx5IGFmZmVjdCBhbGx5ZXNj
b25maWcuIFRvIG1ha2Ugc3VyZSB1bmNoYW5naW5nIHByb2R1Y2VkDQo+ID4+PiBjb25maWcgZmls
ZSBiYXNlZCBvbiAicHZzaGltX2RlZmNvbmZpZyIsIHdlIHNoYWxsIGV4cGxpY2l0bHkgc3RhdGUN
Cj4gPj4+IGFjY29yZGluZyBLY29uZmlnIGlzIG5vdCBzZXQNCj4gPj4+DQo+ID4+PiBBZGQgImRl
ZmF1bHQgeSIgZm9yIFNIQURPV19QQUdJTkcgYW5kIFRCT09ULCBvdGhlcndpc2Ugd2Ugd2lsbCBo
YXZlDQo+ID4+PiB1bnNldCB2YWx1ZXMgd2hlbiBydW5uaW5nIG1ha2UgZGVmY29uZmlnIGJhc2Vk
IG9uICJ4ODZfNjRfZGVmY29uZmlnIi4NCj4gPj4NCj4gPj4gSSBmZWFyIEkgZG9uJ3QgdW5kZXJz
dGFuZCB0aGlzLCBwZXJoYXBzIHJlbGF0ZWQgdG8gbWUgYWxzbyBub3Qgc2VlaW5nIGhvdyAuLi4N
Cj4gPg0KPiA+IElmIHdlIGp1c3QgcmVtb3ZlZCAiZGVmYXVsdCAhUFZfU0hJTV9FWENMVVNJVkUi
LCAuY29uZmlnIGZpbGUgZ2VuZXJhdGVkIGJ5DQo+ICJtYWtlIGRlZmNvbmZpZyINCj4gPiB3aWxs
IGNoYW5nZSwgaGF2aW5nIHVuc2V0dGluZyB2YWx1ZXMgZm9yIFNIQURPV19QQUdJTkcgKCMNCj4g
PiBDT05GSUdfU0hBRE9XX1BBR0lORyBpcyBub3Qgc2V0KSBJZiBjaGFuZ2luZyBpdCB0byAiZGVm
YXVsdCB5IiBpcyB0b28NCj4gPiBjYXN1YWwsIG1heWJlIHdlIHNoYWxsIGFkZCAiQ09ORklHXyBT
SEFET1dfUEFHSU5HPXkiIGluDQo+IHg4Nl82NF9kZWZjb25maWcsIHRvIGF0IGxlYXN0IHJldGFp
biBjb25zaXN0ZW50IC5jb25maWcgZmlsZS4NCj4gPiBNeSBmYXVsdCwgT25seSBjb25zaWRlcmlu
ZyAiU0hBRE9XX1BBR0lORyIgaXMgZW5vdWdoLCBhcyBUQk9PVCBkZXBlbmRzDQo+ID4gb24gVU5T
VVBQT1JURUQgZmlyc3RseQ0KPiA+DQo+ID4+PiAtLS0gYS94ZW4vYXJjaC94ODYvS2NvbmZpZw0K
PiA+Pj4gKysrIGIveGVuL2FyY2gveDg2L0tjb25maWcNCj4gPj4+IEBAIC0xNDMsNyArMTQzLDcg
QEAgY29uZmlnIFhFTl9JQlQNCj4gPj4+DQo+ID4+PiAgY29uZmlnIFNIQURPV19QQUdJTkcNCj4g
Pj4+ICAgICBib29sICJTaGFkb3cgUGFnaW5nIg0KPiA+Pj4gLSAgIGRlZmF1bHQgIVBWX1NISU1f
RVhDTFVTSVZFDQo+ID4+PiArICAgZGVmYXVsdCB5DQo+ID4+PiAgICAgZGVwZW5kcyBvbiBQViB8
fCBIVk0NCj4gPj4+ICAgICBoZWxwDQo+ID4+Pg0KPiA+Pj4gQEAgLTE3NSw3ICsxNzUsNyBAQCBj
b25maWcgQklHTUVNDQo+ID4+PiAgY29uZmlnIFRCT09UDQo+ID4+PiAgICAgYm9vbCAiWGVuIHRi
b290IHN1cHBvcnQgKFVOU1VQUE9SVEVEKSINCj4gPj4+ICAgICBkZXBlbmRzIG9uIElOVEVMICYm
IFVOU1VQUE9SVEVEDQo+ID4+PiAtICAgZGVmYXVsdCAhUFZfU0hJTV9FWENMVVNJVkUNCj4gPj4+
ICsgICBkZWZhdWx0IHkNCj4gPj4+ICAgICBzZWxlY3QgQ1JZUFRPDQo+ID4+PiAgICAgaGVscA0K
PiA+Pj4gICAgICAgQWxsb3dzIHN1cHBvcnQgZm9yIFRydXN0ZWQgQm9vdCB1c2luZyB0aGUgSW50
ZWwoUikgVHJ1c3RlZA0KPiA+Pj4gRXhlY3V0aW9uDQo+ID4+DQo+ID4+IC4uLiB0aGVzZSB0d28g
Zml0IHdpdGggdGl0bGUgYW5kIGRlc2NyaXB0aW9uLiBUaGUganVzdGlmaWNhdGlvbiBmb3INCj4g
Pj4gcmVtb3ZpbmcgdGhlICFQVl9TSElNX0VYQ0xVU0lWRSBoZXJlIGlzIG5vdCAiYnJlYWtzIGFs
bHllc2NvbmZpZyIuDQo+ID4NCj4gPiBIbW1tLCBpdCBpcyB0aGUgY29uc2VxdWVuY2Ugb2YgInJl
bW92aW5nIHRoZSAhUFZfU0hJTV9FWENMVVNJVkUiDQo+ID4gTWF5YmUgSSBzaGFsbCBhZGQgbW9y
ZSBleHBsYW5hdGlvbiBpbiBjb21taXQgbWVzc2FnZT8NCj4NCj4gSnVzdCB0byBjbGFyaWZ5IC0g
bXkgcXVlc3Rpb25zIGhlcmUgd2VyZSBhYm91dCB0aGUgY2hhbmdlcyBhbHRvZ2V0aGVyLCBpLmUu
Og0KPiBXaHkgYXJlIHRoZXNlIHR3byBjaGFuZ2UgLSBhcyBhIHdob2xlIC0gbmVlZGVkLCBnaXZl
biB0aGUgc3ViamVjdD8gQW5kIGp1c3QgdG8gdHJ5DQo+IHRvIGF2b2lkIGFueSBtaXN1bmRlcnN0
YW5kaW5nOiBNeSBwb2ludCBpcyB0aGF0ICJkZXBlbmRzIG9uIC4uLiIgYW5kICJkZWZhdWx0IC4u
LiIgYXJlDQo+IGRpZmZlcmVudCB0aGluZ3MsIHdoZW4gdGhlIGNvbW1pdCBtZXNzYWdlIGRpc2N1
c3NlcyBvbmx5IHRoZSBmb3JtZXIuIFNvIHllcywNCj4gZXh0ZW5kaW5nIHRoZSBjb21taXQgbWVz
c2FnZSBtYXkgYmUgb25lIHdheSB0byBhZGRyZXNzIG15IHJlbWFya3MuIEJ1dCByZWFsbHkNCj4g
SSB0aGluayBjaGFuZ2VzIHRvIGRlZmF1bHRzIChpZiBuZWVkZWQgYXQgYWxsKSB3b3VsZCBiZXR0
ZXIgYmUgc2VwYXJhdGUgZnJvbSBjaGFuZ2VzDQo+IHRvICJkZXBlbmRzIG9uIC4uLiIuDQo+DQoN
ClRoZSByZWFzb24gd2h5IEkgYWRkZWQgYW4gZXh0cmEgZGVmYXVsdCB5IGZvciBDT05GSUdfU0hB
RE9XX1BBR0lORyBpcyB0aGF0DQp0aGUgLmNvbmZpZyBmaWxlIGdlbmVyYXRlZCBmcm9tIHg4Nl82
NF9kZWZjb25maWcgaGFzIGNoYW5nZWQgYWZ0ZXIgcmVtb3ZpbmcgdGhlICJkZWZhdWx0ICFQVl9T
SElNX0VYQ0xVU0lWRSIsIGZyb20gIkNPTkZJR19TSEFET1dfUEFHSU5HPXkiIHRvICIgQ09ORklH
X1NIQURPV19QQUdJTkcgaXMgbm90IHNldCAiLiBUbyBmaXggaXQsIEkgY2FzdWFsbHkgYWRkZWQg
YSAiZGVmYXVsdCB5IiBoZXJlLg0KSSB1bmRlcnN0YW5kIHRoYXQgbGlrZSB5b3Ugc2FpZCwgaXQg
ZG9lc24ndCBmaXQgd2l0aCB0aGUgdGl0bGUgYW5kIGRlc2NyaXB0aW9uLi4uIEknbGwgY3JlYXRl
IGEgbmV3IGNvbW1pdCBmb3IgaXQuIEFuZCBpbnN0ZWFkIG9mIGFkZGluZyAiZGVmYXVsdCB5Iiwg
bWF5YmUganVzdCBhZGRpbmcgIiBDT05GSUdfU0hBRE9XX1BBR0lORz15IiBpbiB4ODZfNjRfZGVm
Y29uZmlnIGlzIGVub3VnaC4NCg0KPiA+Pj4gLS0tIGEveGVuL2FyY2gveDg2L2NvbmZpZ3MvcHZz
aGltX2RlZmNvbmZpZw0KPiA+Pj4gKysrIGIveGVuL2FyY2gveDg2L2NvbmZpZ3MvcHZzaGltX2Rl
ZmNvbmZpZw0KPiA+Pj4gQEAgLTI2LDMgKzI2LDggQEAgQ09ORklHX0VYUEVSVD15DQo+ID4+PiAg
IyBDT05GSUdfSU5URUxfSU9NTVUgaXMgbm90IHNldA0KPiA+Pj4gICMgQ09ORklHX0RFQlVHIGlz
IG5vdCBzZXQNCj4gPj4+ICAjIENPTkZJR19HREJTWCBpcyBub3Qgc2V0DQo+ID4+PiArIyBDT05G
SUdfU0hBRE9XX1BBR0lORyBpcyBub3Qgc2V0DQo+ID4+PiArIyBDT05GSUdfVEJPT1QgaXMgbm90
IHNldA0KPiA+Pj4gKyMgSFlQRVJWX0hZUEVSVl9HVUVTVCBpcyBub3Qgc2V0DQo+ID4+DQo+ID4+
IFRoaXMgb25lIGRvZXNuJ3QgbG9vayByaWdodCwgc2ltcGx5IGJ5IGl0cyBuYW1lLg0KPiA+Pg0K
PiA+Pj4gKyMgQ09ORklHX0hWTSBpcyBub3Qgc2V0DQo+ID4+PiArIyBDT05GSUdfVkdBIGlzIG5v
dCBzZXQNCj4gPj4NCj4gPj4gSnVzdCB0byBtZW50aW9uIGl0IC0gSSdtIHVuc3VyZSB3aGV0aGVy
IGFkZGluZyBzdWNoIGF0IHRoZSBlbmQgaXNuJ3QNCj4gPj4gZ29pbmcgdG8gY2F1c2UgaXNzdWVz
LiBCdXQgbWF5YmUgSSdtIHBhcmFub2lkIC4uLg0KPiA+Pg0KPiA+DQo+ID4gSXQgY291bGQgYmUg
dG9vIGNhc3VhbC4uDQo+ID4gSSB3aWxsIG9ubHkgbGVhdmUgVkdBIGhlcmUsIGFzIHdlJ3JlIHN1
cmUgdGhhdCB3aXRoIHJlbW92aW5nDQo+ID4gIiFQVl9TSElNX0VYQ0xVU0lWRSIsIENPTkZJR19W
R0EgaXMgc2V0dGluZyBhcyB5IGluIHB2c2hpbV9kZWZjb25maWcNCj4NCj4gSSBkb24ndCBmb2xs
b3c6IFdoeSB3b3VsZCBhIHNoaW0gbmVlZCBWR0Egc3VwcG9ydCBjb21waWxlZCBpbj8NCj4NCg0K
WWVzLCBWR0Egc2hhbGwgbm90IGJlIGNvbXBpbGVkIGZvciBhIHNoaW0uIEFuZCBpdCBpcyB0aGUg
cmVhc29uIHdoeSBJIGFkZGVkICIjIENPTkZJR19WR0EgaXMgbm90IHNldCIgaW4gcHZzaGltX2Rl
ZmNvbmZpZy4gV2l0aG91dCBpdCwgdGhlIGNvbnNlcXVlbmNlIG9mIHJlbW92aW5nICIgaWYgIVBW
X1NISU1fRVhDTFVTSVZFICIgZm9yIFZHQSBpcyB0aGF0IHdoZW4gd2UgcnVuICJtYWtlIGRlZmNv
bmZpZyBwdnNoaW1fZGVmY29uZmlnIiwgd2Ugd2lsbCBnZXQgQ09ORklHX1ZHQT15IGluIC5jb25m
aWcNCkxpa2UgeW91IHNhaWQsIHRoaXMgY2hhbmdlIGJlbG9uZ3MgdG8gdGhlIGdyb3VwIG9mIGNo
YW5naW5nIGtjb25maWcgZGVmYXVsdCB2YWx1ZXMsIGFuZCB3aWxsIGxhdGVyIGJlIGluY2x1ZGVk
IGluIGEgbmV3IGNvbW1pdA0KDQo+ID4+PiAtLS0gYS94ZW4vZHJpdmVycy92aWRlby9LY29uZmln
DQo+ID4+PiArKysgYi94ZW4vZHJpdmVycy92aWRlby9LY29uZmlnDQo+ID4+PiBAQCAtMywxMCAr
MywxMCBAQCBjb25maWcgVklERU8NCj4gPj4+ICAgICBib29sDQo+ID4+Pg0KPiA+Pj4gIGNvbmZp
ZyBWR0ENCj4gPj4+IC0gICBib29sICJWR0Egc3VwcG9ydCIgaWYgIVBWX1NISU1fRVhDTFVTSVZF
DQo+ID4+PiArICAgYm9vbCAiVkdBIHN1cHBvcnQiDQo+ID4+PiAgICAgc2VsZWN0IFZJREVPDQo+
ID4+PiAgICAgZGVwZW5kcyBvbiBYODYNCj4gPj4+IC0gICBkZWZhdWx0IHkgaWYgIVBWX1NISU1f
RVhDTFVTSVZFDQo+ID4+PiArICAgZGVmYXVsdCB5DQo+ID4+PiAgICAgaGVscA0KPiA+Pj4gICAg
ICAgRW5hYmxlIFZHQSBvdXRwdXQgZm9yIHRoZSBYZW4gaHlwZXJ2aXNvci4NCj4gPj4NCj4gPj4g
TGlrZSBhYm92ZSwgdGhpcyBjaGFuZ2UgYWxzbyBkb2Vzbid0IHJlYWxseSBmaXQgd2l0aCB0aXRs
ZSBhbmQgZGVzY3JpcHRpb24uDQo+ID4NCj4gPiBJIGhhdmUgYWRkZWQgIiAoYWxzbyB0aGUgZnVu
Y3Rpb25hbGx5IGVxdWl2YWxlbnQgImlmICEuLi4iKSAiIGluDQo+ID4gY29tbWl0IG1lc3NhZ2Ug
dG8gYWxzbyBjb3ZlciBhYm92ZSBjaGFuZ2UNCj4NCj4gV2VsbC4gVGhlcmUgYXJlIG11bHRpcGxl
IHVzZXMgb2YgImlmIC4uLiIuIFRoZSBvbmUgbWF0Y2hpbmcgImRlcGVuZHMgb24gLi4uIiBpcyBj
b3ZlcmVkDQo+IGluIHRoZSBkZXNjcmlwdGlvbiwgeWVzLiBCdXQgdGhlIHR3byB1c2VzIGhlcmUg
ZG9uJ3QgZmFsbCBpbiB0aGlzIHNhbWUgZ3JvdXAuIE9uZSBpcyBhDQo+IHByb21wdCB2aXNpYmls
aXR5IGNoYW5nZSwgYW5kIHRoZSBvdGhlciBpcyBhIGNoYW5nZSB0byB5ZXQgYW5vdGhlciBkZWZh
dWx0LiBTZWUgYWJvdmUNCj4gZm9yIG15IHJlY29tbWVuZGF0aW9uICh0byBzcGxpdCB0aGluZ3Mg
cHJvcGVybHkpLg0KPg0KDQpDb3JyZWN0IG1lIGlmIEkgdW5kZXJzdGFuZCB3cm9uZ2x5Og0KImlm
IC4uLiIgZm9yIEhZUEVSVl9HVUVTVCBpcyBmYWxsaW5nIHRoZSBncm91cCB3aGVyZSBwcm9tcHQg
dmlzaWJpbGl0eSBjaGFuZ2VzLCBhbmQgZml0cyB3aXRoIHRoZSB0aXRsZSBhbmQgZGVzY3JpcHRp
b24NCiJpZiAuLi4uIiBmb3IgVkdBIGlzIGEgY2hhbmdlIHJlZ2FyZGluZyBrY29uZmlnIGRlZmF1
bHQgdmFsdWUsIGFuZCBzaGFsbCBiZSBjb3ZlcmVkIGluIGEgbmV3IGNvbW1pdC4NCllldCBteSBj
aGFuZ2VzIG9uICBwdnNoaW1fZGVmY29uZmlnIGFuZCB4ODZfNjRfZGVmY29uZmlnIHNoYWxsIGFs
c28gYmUgaW5jbHVkZWQgaW4gdGhlIG5ldyBjb21taXQuIEFzIHRoZXkgYXJlIGFsbA0KdGFsa2lu
ZyBhYm91dCBjaGFuZ2luZyBrY29uZmlnIGRlZmF1bHQgdmFsdWUuDQoNCj4gSmFuDQo=


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 09:03:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 09:03:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012585.1391067 (Exim 4.92)
	(envelope-from )
	id 1uPdqO-0001u4-NQ; Thu, 12 Jun 2025 09:03:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012585.1391067; Thu, 12 Jun 2025 09:03:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPdqO-0001tx-Ie; Thu, 12 Jun 2025 09:03:32 +0000
Received: by outflank-mailman (input) for mailman id 1012585;
 Thu, 12 Jun 2025 09: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 1uPdqN-0001tr-9u
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 09:03: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 1b62fe1b-476c-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 11:03:29 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a53359dea5so481372f8f.0
 for ; Thu, 12 Jun 2025 02:03:29 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2364e719323sm9106885ad.219.2025.06.12.02.03.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 02:03:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1b62fe1b-476c-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749719008; x=1750323808; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=KR9Vrwds8wqx443tsEdqDm3tlo3F6+f47zGUKClGImA=;
        b=B/aW38/Q22daunD42W3pYqmFO+LLV2NCVaS+1POE/mjesIuvHO9z5u63nAU72xEXtP
         N4vjW9I8P/IgaZyo7GupZXcg3qfZ0V+WZOonrMv6ZJnlV8vcC6p9iUafu9DTbjtDEAUZ
         SVT586EswxF9RTytPd0am9Dg33OkTuIv4zFo+GY7ga6HgRFTugwkRHZWC7UfEkfNcTiU
         8MTyzsM7+hUHGKPmeG+dXUkU8E7QXOnb2QuAiQOjDpEz8KpeRh0WZXvkZsMU5ppq6ZTV
         ffh3WctXbT2UHcTQtQCQ1LACXFRGlMCRkDd2+f1cSHh5rzXKx6hd5tqonOYgY8VCQnS6
         oxqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749719008; x=1750323808;
        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=KR9Vrwds8wqx443tsEdqDm3tlo3F6+f47zGUKClGImA=;
        b=LKtiWx89fpbcxu4oqmzQKppS27ewpi0s2i7BS4PGHfGJ0/ATq0a28lEslhRFK//Vh5
         VXpI01EaUQtNWoFc6MTtGCtKfyn2wKrVwh4HJ1K/dhXe9CbzWHkATglcQVQtX3s3fX43
         pooZXz/qR5HN4UkPnRc38+Cma6CbLu6fC1WTNfR+15IX1i9l2fzXH9P8YF/3sBhMQLud
         fxF5N8zTctc/0et3BqUCn1czjFgIcSukw7PabaFyoURnLS/5dBN7El07J2jqTnEel1Gu
         hqAjwuPUiMcxEpZjzrGIiN0X9FogsV4RrVfhpYOxCxy0NxANNEmG0aHNkLy8myxU8XYH
         IgjA==
X-Forwarded-Encrypted: i=1; AJvYcCVFniFt87QOYf7eHdilZ5Wi/Yk5UEvP1JeFa2ekERKfkzKNBh094IJhrn5O4HrVg3Af/7l/LgNWzTI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzHLy0yVPC9w72xmu9hWPZTBxS4DdvYySuBRB3i6L/ULIiGT0DQ
	zUB9B7y0XzTnwFib1XBf6vYg3As5OW86hfsckW2vAN/8bDjC9Ec4B28Swf+hpgkOTw==
X-Gm-Gg: ASbGnctAx9pMZQ7l3kaUhoQtugT2eaWJ+gb4evh0Bk+lBkC/U3anocAQZp7M/g21haD
	fFY+JroHMaCfh+Esb2BNCODWzVZvIXMgyOARH3QMPLxvd5DcAyQ922Bw4tIFcW9a5vIuPxBZFxz
	J2aftBhTqY51Wt8aPzFKZjhblHkpE1bb03+el8cIdR9+DkpL+EyxDbakZimA38hxo8tYsyZai2X
	5raSlGGyxBRBIN9Wsx2xF1Lmeutlu6MM3QOvr9GsxTuR8RPCZr2wH6wt5wwyu+42iVlL6z51n1R
	36lL3i2ZpUf9WIsxi1xiG8EvvsuxHvv4jzEoloJQZGhdJJ79OTdLG6bLKZIbhuy3HGaELpRwyGO
	Z5nNssW4H+dNP/MLEiif2exhCpyFSN0QksywDN63mpsXhUss=
X-Google-Smtp-Source: AGHT+IFkUrdgAc6D3Sl72RtrPoez0M1gblEq+QRM+WOlVmTtduuTsK4YoUJfYVuo3scX6sLiAexeTw==
X-Received: by 2002:a05:6000:2381:b0:3a3:7cbd:39b1 with SMTP id ffacd0b85a97d-3a561314e9amr1768595f8f.24.1749719008549;
        Thu, 12 Jun 2025 02:03:28 -0700 (PDT)
Message-ID: <6abadf32-836f-45fb-bb3a-3afdf97e157b@suse.com>
Date: Thu, 12 Jun 2025 11:03:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/8] x86/pdx: simplify calculation of domain struct
 allocation boundary
To: Roger Pau Monne 
Cc: Andrew Cooper , xen-devel@lists.xenproject.org
References: <20250611171636.5674-1-roger.pau@citrix.com>
 <20250611171636.5674-2-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: <20250611171636.5674-2-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.06.2025 19:16, Roger Pau Monne wrote:
> @@ -498,14 +474,15 @@ struct domain *alloc_domain_struct(void)
>       * On systems with CONFIG_BIGMEM there's no packing, and so there's no
>       * such restriction.
>       */
> -#if defined(CONFIG_BIGMEM) || !defined(CONFIG_PDX_COMPRESSION)
> -    const unsigned int bits = IS_ENABLED(CONFIG_BIGMEM) ? 0 :
> -                                                          32 + PAGE_SHIFT;
> +#if defined(CONFIG_BIGMEM)
> +    const unsigned int bits = 0;
>  #else
> -    static unsigned int __read_mostly bits;
> +    static unsigned int __ro_after_init bits;
>  
>      if ( unlikely(!bits) )
> -         bits = _domain_struct_bits();
> +         bits = flsl(pfn_to_paddr(pdx_to_pfn(
> +             1UL << (sizeof(((struct page_info *)NULL)->v.inuse._domain) * 8))))
> +             - 1;

While Andrew did point you at sizeof_field(), we can have this even less verbose
by utilizing that frame_table is of the right type and (almost) globally in scope.

Further, why use pfn_to_paddr()?

         bits = flsl(pdx_to_pfn(1UL << 
                                (sizeof(frame_table->v.inuse._domain) * 8))) +
                PAGE_SHIFT - 1;

However, it further feels like this was off by one; we had similar issues over
time in several places. There potentially being a gap between one less than
the PDX used here and that very PDX, don't we need to calculate based on the
"one less" value here? Hmm, there being a gap means no allocation would
succeed for the precise value of "bits" (in the mask-compression scheme), so
functionally all would be fine. Yet just to avoid setting a bad precedent I
think we'd still be better off using

         bits = flsl(pdx_to_pfn((1UL << 
                                 (sizeof(frame_table->v.inuse._domain) * 8)) -
                                1)) + PAGE_SHIFT;

If one would log the value of bits, the result would then also be less
confusing in (at least) the mask-compression scheme.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 09:06:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 09:06:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012591.1391075 (Exim 4.92)
	(envelope-from )
	id 1uPdtS-0002S8-3C; Thu, 12 Jun 2025 09:06:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012591.1391075; Thu, 12 Jun 2025 09:06:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPdtS-0002S1-0J; Thu, 12 Jun 2025 09:06:42 +0000
Received: by outflank-mailman (input) for mailman id 1012591;
 Thu, 12 Jun 2025 09:06: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 1uPdtQ-0002Rv-7b
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 09:06:40 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on2060e.outbound.protection.outlook.com
 [2a01:111:f403:2414::60e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8adbacb1-476c-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 11:06:37 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by PH7PR12MB5949.namprd12.prod.outlook.com (2603:10b6:510:1d8::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.42; Thu, 12 Jun
 2025 09:06:32 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8792.034; Thu, 12 Jun 2025
 09:06: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: 8adbacb1-476c-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=GJx5EnO4YbaK5EIXyUFo+yu5FbFPS1B+CMVmZW59MAZWQdX9zWSSTouFzt9yv1rlVV5yIcreJRT5FGOYtRlzMb5bvd+nuo18Lo9jIUnwib1sQW+Ew27yltR9qmwbH1+VZtNpWO7qLUsrvd4yl0LSXOKKy1ebDn5zeUgbtsimjk/iKWELvn9D8WH/dEx6daUZE/RGdoq/3OKVoFWJ4veEoyLAO0MGU8CNdlVoQbwlzCErCY/zK3FbUfLFfI69pvHBzeMrNsutpk8H6/Q49Cfc4tc+L45uCiHplPKLGrsUiKrOAVsair6xOGes9OQPci0XsjR23XfTe+9SpPnIKJgYQw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=8TGS4lHhpEc/BMtLxVoXgH3Z68i7cjs4rWlWSQT5DT8=;
 b=jsWk+LG/ulz8Y/Slo8K7iJFf8pjt0iRF6TQq6I3ulk52bSMETdVKHOLigfJJ3PQko0ys7zmMIhdNDSNa2kvhZL5W07Wo4qD7aWhCL/wel/JrqmtVQL4ntCa06rV4No95ZHDOV8/Of7NZrZYgQgWPhuYTtUbrw5zGHhsSl2E/3YtuP7Qc8TIff877/dcBPyaKdeUnodYyZueIblgixZjzlTDNRGxU4W8x4JAbVC5EApfmEYldZCcd3f5xR0ttgQDGl6FtE0WClj1yVV6sonbDsXR5oFNGnLmrq3Ep/66JLFLVXBe5l/X83lEKo6ndylxWLh41q/5coSztIwJXBNJLWQ==
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=8TGS4lHhpEc/BMtLxVoXgH3Z68i7cjs4rWlWSQT5DT8=;
 b=oOu/2PbxSI56OOZ1CQlkL4xMOPBzHlI2HliFI234OjF2931psmD1WKu9v83LGjUcN2lwdcMm71zw3hwoBa+yq751jgQMPZckcZXorq3IuPJAJtcglCiWe8LIZh3PEcNu8obps2AHYMiyc4NaQkZ+N9jatNeSo+lg1meou4MeruY=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Thu, 12 Jun 2025 11:06:29 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 1/2] xen/arm: exclude xen,reg from direct-map domU
 extended regions
To: Stewart Hildebrand ,
 xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250611175106.269829-1-stewart.hildebrand@amd.com>
 <20250611175106.269829-2-stewart.hildebrand@amd.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250611175106.269829-2-stewart.hildebrand@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR2P281CA0148.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:98::6) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|PH7PR12MB5949:EE_
X-MS-Office365-Filtering-Correlation-Id: 5ba3ec2e-126e-4b09-33a3-08dda9906ccb
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?dC9aeFVFRHR5QTQ1a1NpUFpWUVl0MG1MbEV4cHY5SW1oaE9qeHZheFYvalhj?=
 =?utf-8?B?Sk5MblZNN3lrcGhMcnF6WTc4NjVLQkFSM1VhYXFYdWJQQm12SUphUjhNejZ5?=
 =?utf-8?B?akp6eHl4eGFvalhKMVhkYitYRkRsb2VxN3ExWU8zeDZMaldQcFBiUUswUVdU?=
 =?utf-8?B?WWpSYWxsak9IOTIxbEhCbjIvTElVZTg1bW44SndDNFM0OGlGMGRJeEtxVVpR?=
 =?utf-8?B?TFFBbTh2VDE2bjI1ZmVWTXJmK0FSdnFZV2RiY0ZobGplSWVkcnVqZEViWGxu?=
 =?utf-8?B?eWRpd2hTTHNldm1SNm5scmJjN1dpcjBWSitCRUlLd0hmMnAzVUQrR2htbWpU?=
 =?utf-8?B?dDFVN3ozTHF6TTJtN2s1NnJSdTZoZXROOU82R1M5ZGdHbGJMMDNLVWdGbDR6?=
 =?utf-8?B?WFlSaE9xZXdSaE4zcmdVT3M0UklVZktWRTBqNHYwVGNEQiswbFB2bjYwZStu?=
 =?utf-8?B?enhXZWt3UU81eVJ1SXBlQ3YrY3VkMi8rVDk3cldkTlhma25ualF6UWpqdVhH?=
 =?utf-8?B?OVZUaGdSVGMxN3owdGsrKzRLNk16Mm0rNVV0WTFBbzJJQmFFZlFSNlROWDZ2?=
 =?utf-8?B?TXo2VkhnaThyY0ZDaHBqZTJUdFNhS3IrZWdKNU1hU1pUUmRnem9iVlVKTVVp?=
 =?utf-8?B?b0FSSVNDci9zOWY2dUdEeFRka3dKRGhaZzlNWTlLWWM5SmVESnAzREJwUURC?=
 =?utf-8?B?SlY5WXo1czJESnRCdXVmQ1hRNXhzcUhadDR5UlRLNXhoYVBjeXdEQXJMVHBL?=
 =?utf-8?B?UjAzTXFiUzFPUjNkakRUb2l1MWIvLzVzbHozMVhyZnFKUWlWR0RZVGJaQWtq?=
 =?utf-8?B?dVdlUEJ5Q1ZGdmRSUUJnaUdZWDhlempiSTY5UWo1S0VrNzV4bG91MzI2RHda?=
 =?utf-8?B?aUd4eDBRZE5vZ0tnaTBvVHJCUHR2NFB1dkE3dmYwNXIzNmZ3TjBqdkhxVURh?=
 =?utf-8?B?VGZFQmhRUVd4U0xldkhyUVVtY21MZFlkVmRlcHNjNWxKQU9PNTdKM1cvYkpX?=
 =?utf-8?B?ZEdxSzBaRU1mZ3U1VWFDSUZlU0htSVArT25RcWNRdE1JUGhmM28zU3Bma1Q5?=
 =?utf-8?B?YkxLR0NiTGdRL0liN0tYU1RZMnM3QzFXUFRrVG5vbEpmL3NSTkM4L2l5WERy?=
 =?utf-8?B?UGUrcHlLTmR3ZndFQnovcXlYaGo4MzlUWFR5aGRrWjJuQTNNSWtiL2RaTG5X?=
 =?utf-8?B?b0lkbTdUSnl4NythSHZBczYwN2JkbUlBejFNQW5yMlVJYURiS3pPajBMR096?=
 =?utf-8?B?YmZJa2VuMzZGTkhWVElNeWFteWxCV2dxME1oZzJCRVpTSnR1MWJMVU9kamdx?=
 =?utf-8?B?T2REV3JoWUtBSi91Q1VzTW5jWHFLUzBsUXdsKzE1a1AybDNLbE9XQkF6V09W?=
 =?utf-8?B?RTI0NXRxRGFZMnl2b25qUjRIcnJJQ2I5ZkJUa0FyNDRqOFBobkRwYkM4RFE1?=
 =?utf-8?B?ZUhIYjVYOXFrQnZ0LzAyQkJ6QmtkdHozYUdzaWZjNEJkTC9TRFpRTWEvbWNV?=
 =?utf-8?B?TmNnek9Kd1pFV1FYLytyOVRJV2tPRENVU3g3ZlJvbXB4TjNYZml1bktEbGZm?=
 =?utf-8?B?MDF6RlNoQm5CZmg0MlNPaUFYL0habHpCVFpsTHk1SlBKR0VXdWJYVUZDUnpI?=
 =?utf-8?B?SGtvNGo2eVEzRGdaT2JPOGpBdC9NMk9HNnVvRE5HM2Q4RTFTWFBaMEZrOVNh?=
 =?utf-8?B?dFhyR1hXMGhxdmM4U3NIMzJHeXZnRHBMYWtaYkd4alUyTlVqVlRMRVdDTExM?=
 =?utf-8?B?dEwyYmZlRXV0WDJCUXlQcVYxOUlVditKU2p1MERoMXdDQ2hKYnhRQzQ0SUV4?=
 =?utf-8?B?V21HMHBYeFZjR3dmK3lOd29vYlR4UXpydm51aFNLNFBRaUtpSk11N255Ymtl?=
 =?utf-8?B?T0h2Z0NSWXJ3TTVQWkUvaDh4SnhVZktndnZtalZIditLNlY2VU90c1YrRGtZ?=
 =?utf-8?Q?oN8uRpC+5ug=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.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?dEMwajdqQWtiSzFuNWtNZVlZUWxqMDhMVml2WW56VnpJa1NrZmNuM2hTQWM3?=
 =?utf-8?B?bDh0c3F0MTZGNEEzcDVFKzVQaExvek5jSWVsdHBjWkRxdUNrdk1BeEZiTEtS?=
 =?utf-8?B?SGorZnFlNEhISi9JVDdZeHhjbWQ5SnJyeEYzWlFxb25OZmhPTmRsRE9TcTBt?=
 =?utf-8?B?WDRxR0dkbk9vYVZ0bEdSRlJJb3A5ZzdSeEhmSUdBYVV4aDZkejFSU1JPR01v?=
 =?utf-8?B?eDdoVU1YZWFWeXlaSmJkTEorL3BBTTQxYThScnVGZXVCLzRKY3g0UEhabE5J?=
 =?utf-8?B?ZWRkY0YwWE0yaFZpdGNIdzdnN1h3dHcyTm1Gb0Q2NWpmb0VqK0lpUjNtSzdP?=
 =?utf-8?B?YjMwOFUrU0NIV0pCUzMxc1F2Q1RwQXpPRlR5NU13NUtNRnQ5NkV0eGN1RWNU?=
 =?utf-8?B?YWtpYmc5bFdZWUtEL3hyajVRSll2aU1hTUErU1VoVlVsNTErbnlUZzNhS2dT?=
 =?utf-8?B?cmd6WGovcGp3S3VkV1lxR3J6ZWt4WkpZbVJhQ0NFVitVSkRxUW1ldk5ZUERk?=
 =?utf-8?B?TVpNVmRnQTJDSzRLNGxvckFTN3VGakh0ZkQ0S0lpbjNrSkhML0ZkQmx5b1A3?=
 =?utf-8?B?MUFsekg3MmVTTGFFektzQ2RLWHhtNW90TGtTRDVPdVJhbjBvajN3aEh5Rlds?=
 =?utf-8?B?ZVVlVzVKdmxOdGhkdU0wQU5FSGhsR3RWM21SRm82b3hudlB2R1JjdlRlSUZW?=
 =?utf-8?B?U2l4TUp5b2FvZnJnb094VkJ6cTV0MXBSZG80aVNySjMxM2xCaE9SM0JUTk5p?=
 =?utf-8?B?Skl4Yi9wNWtENU4waGdXVmk1bEZEOEZEaHl5MXhTSjVrN3daY2p5YktqQURa?=
 =?utf-8?B?NENZemtoRUxGVXhVWWZLdm1razdFSmxJUmFFeVQ4cmpIdTZJcHhQNDNjeGJX?=
 =?utf-8?B?d1UvWVJZTk5Sb05xSW9GMEF5ejNScUpmcWM4U0U4MDFkakFRMHV1Znd2ZlhM?=
 =?utf-8?B?WU1xNTlYbmpJZVl0Y2F3cU9XU0NDeWtXcXNhZ2FYbG5STmdHS2c5Tm9EZlNl?=
 =?utf-8?B?MXl1WmZsYk93SXNhZEFhTnk0eDFrQVpLTjhuQjBMZjVyYndtZmpVSWRRVEhJ?=
 =?utf-8?B?ZjNXM3lBQ2s3VWVYZ2F5YVFQNnBiTEtnRktnUStlV0tsdHFlaG1tWmIxTW9r?=
 =?utf-8?B?WVlvUW5lMVd5cWhEemEyK3kyeTRKdWVVU3ArZzFFWGd1V1FpVzN1cU4zRTVK?=
 =?utf-8?B?SzMrNGdnYktraVJUbndmemFqKzJqMXRFT2ZkbC9VM0FIZTBxOUtPcHgxaU9j?=
 =?utf-8?B?cHZBczA5QU5paFY4djlwVExvZzJya3dXRlZnTEorckl6RjlOWkpscklPTS8v?=
 =?utf-8?B?aUtQSmRXZjNQbHJGNnlwL1VMaVd5NEthS21JMitLQnJFOTBHUCt4Nkl3aXhi?=
 =?utf-8?B?VXBRMUhuRWZTNmpCQXNYd09CVkZvTllON08vRFBkYVg1TmRObkltZ0t5SGJv?=
 =?utf-8?B?OGI2bFpjZDY4K1NMbVFFQy9RUlI0VWFMQ2Y0aE51R3ZMV2RtNEQ4dlNDb2k2?=
 =?utf-8?B?WmNHcklvV2liNkxFNnZDaU5uMCtaZTZTWXlvMVh6c3BKbDQ1bnlIZ2pWU3Ru?=
 =?utf-8?B?bkJVTTg1VUJzbmZ6ZE10VVREaXNIbWN5SnNwQWlTVllMWFloUXIxYnh5QUo0?=
 =?utf-8?B?NmZncWU0VE9LN3YwaE9kU0luMGs2b2R1WXNETUF2aHpvV3IwUzdlRDlxWm4r?=
 =?utf-8?B?VnZoR0xqTVMwOHhWUEFFZDc2enNJaml1KytXNVhIR0hYbm4xSGpUaDFFNm5k?=
 =?utf-8?B?Q3ViaE93Vy8yQ0JuSjVLOEtPSlRnRTZVd0dBQUptRkp5NmxmcG1RZWkzRENu?=
 =?utf-8?B?c1hTSSsxWE1ad2R6NXVhMU1nMDIzM3NWdUpSMDFnRWFtZ2JkbWN0dnZmU01u?=
 =?utf-8?B?cWVQSWhpYWhlQWhwSFk5ZHdZbCtBOTlxMXkvV3RseUJOVnlGZ1l3RDZibGs1?=
 =?utf-8?B?dUovZXQ1aEVQTGpvS2VEQ0pzYlFlaGhQWGhBb2NkMkxNcEFsc1VPUlQ4S2Fn?=
 =?utf-8?B?V0FLaTZRY1FhSnpnN0VGQTFxZTdBcmZVK2RnZkNHOXFNazByV09hRFRvb0xi?=
 =?utf-8?B?K2psVzBGTWlQNzFpM21EU0x4cXVzRkFwWlFrQktXNS9MaFR6cm8rNE56MDRy?=
 =?utf-8?Q?tPIg=3D?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5ba3ec2e-126e-4b09-33a3-08dda9906ccb
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2025 09:06:32.4528
 (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: 23S2OmJA7jZ2PsWTxeyqvq9zecSYL8iQZEIGr5J0rLXfMr/ObTZ+WZD1sqtoUwFt
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB5949



On 11/06/2025 19:51, Stewart Hildebrand wrote:
> Similarly to fba1b0974dd8, when a device is passed through to a
> direct-map dom0less domU, the xen,reg ranges may overlap with the
> extended regions. Remove xen,reg from direct-map domU extended regions.
> 
> Take the opportunity to update the comment ahead of find_memory_holes().
> 
> Signed-off-by: Stewart Hildebrand 
> ---
> v4->v5:
> * remove extranous -1 and +1
> * create local helper function to count ranges
> 
> v3->v4:
> * conditionally allocate xen_reg
> * use rangeset_report_ranges()
> * make find_unallocated_memory() cope with NULL entry
> 
> v2->v3:
> * new patch
> ---
>  xen/arch/arm/domain_build.c           | 80 +++++++++++++++++++++++++--
>  xen/common/device-tree/domain-build.c |  5 ++
>  2 files changed, 80 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 590f38e52053..cef6c85e22ec 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -792,15 +792,17 @@ static int __init handle_pci_range(const struct dt_device_node *dev,
>  }
>  
>  /*
> - * Find the holes in the Host DT which can be exposed to Dom0 as extended
> - * regions for the special memory mappings. In order to calculate regions
> - * we exclude every addressable memory region described by "reg" and "ranges"
> - * properties from the maximum possible addressable physical memory range:
> + * Find the holes in the Host DT which can be exposed to Dom0 or a direct-map
If you took occasion to improve this comment, then I would replace Dom0 with hwdom.

> + * domU as extended regions for the special memory mappings. In order to
> + * calculate regions we exclude every addressable memory region described by
> + * "reg" and "ranges" properties from the maximum possible addressable physical
> + * memory range:
>   * - MMIO
>   * - Host RAM
>   * - PCI aperture
>   * - Static shared memory regions, which are described by special property
>   *   "xen,shared-mem"
> + * - xen,reg mappings
>   */
>  static int __init find_memory_holes(const struct kernel_info *kinfo,
>                                      struct membanks *ext_regions)
> @@ -882,6 +884,13 @@ static int __init find_memory_holes(const struct kernel_info *kinfo,
>          }
>      }
>  
> +    if ( kinfo->xen_reg_assigned )
> +    {
> +        res = rangeset_subtract(mem_holes, kinfo->xen_reg_assigned);
> +        if ( res )
> +            goto out;
> +    }
> +
>      start = 0;
>      end = (1ULL << p2m_ipa_bits) - 1;
>      res = rangeset_report_ranges(mem_holes, PFN_DOWN(start), PFN_DOWN(end),
> @@ -962,11 +971,51 @@ static int __init find_domU_holes(const struct kernel_info *kinfo,
>      return res;
>  }
>  
> +static int __init count(unsigned long s, unsigned long e, void *data)
> +{
> +    unsigned int *cnt = data;
> +
> +    (*cnt)++;
> +
> +    return 0;
> +}
> +
> +static unsigned int __init count_ranges(struct rangeset *r)
> +{
> +    unsigned int cnt = 0;
> +
> +    rangeset_report_ranges(r, 0, PFN_DOWN((1ULL << p2m_ipa_bits) - 1), count,
I don't think it's ok with MISRA C to not check the return code, even though in
this case it's always 0. Either we should check or have (void).

> +                           &cnt);
> +
> +    return cnt;
> +}
> +
> +static int __init rangeset_to_membank(unsigned long s_gfn, unsigned long e_gfn,
Here you use s_gfn, e_gfn but for count() you used s,e. Even if unused, I would
prefer consistency.

> +                                      void *data)
> +{
> +    struct membanks *membank = data;
> +    paddr_t s = pfn_to_paddr(s_gfn);
> +    paddr_t e = pfn_to_paddr(e_gfn + 1);
> +
> +    if ( membank->nr_banks >= membank->max_banks )
> +        return 0;
> +
> +    membank->bank[membank->nr_banks].start = s;
> +    membank->bank[membank->nr_banks].size = e - s;
> +    membank->nr_banks++;
> +
> +    return 0;
> +}
> +
>  static int __init find_host_extended_regions(const struct kernel_info *kinfo,
>                                               struct membanks *ext_regions)
>  {
>      int res;
>      struct membanks *gnttab = membanks_xzalloc(1, MEMORY);
> +    struct membanks *xen_reg =
> +        kinfo->xen_reg_assigned
> +        ? membanks_xzalloc(count_ranges(kinfo->xen_reg_assigned), MEMORY)
> +        : NULL;
>  
>      /*
>       * Exclude the following regions:
> @@ -974,6 +1023,7 @@ static int __init find_host_extended_regions(const struct kernel_info *kinfo,
>       * 2) Remove reserved memory
>       * 3) Grant table assigned to domain
>       * 4) Remove static shared memory (when the feature is enabled)
> +     * 5) Remove xen,reg
>       */
>      const struct membanks *mem_banks[] = {
>          kernel_info_get_mem_const(kinfo),
> @@ -982,12 +1032,29 @@ static int __init find_host_extended_regions(const struct kernel_info *kinfo,
>  #ifdef CONFIG_STATIC_SHM
>          bootinfo_get_shmem(),
>  #endif
> +        xen_reg,
>      };
>  
>      dt_dprintk("Find unallocated memory for extended regions\n");
>  
>      if ( !gnttab )
> -        return -ENOMEM;
> +    {
> +        res = -ENOMEM;
> +        goto out;
> +    }
> +
> +    if ( kinfo->xen_reg_assigned )
> +    {
> +        if ( !xen_reg )
> +        {
> +            res = -ENOMEM;
> +            goto out;
> +        }
> +
> +        rangeset_report_ranges(kinfo->xen_reg_assigned, 0,
> +                               PFN_DOWN((1ULL << p2m_ipa_bits) - 1),
> +                               rangeset_to_membank, xen_reg);
> +    }
>  
>      gnttab->nr_banks = 1;
>      gnttab->bank[0].start = kinfo->gnttab_start;
> @@ -995,6 +1062,9 @@ static int __init find_host_extended_regions(const struct kernel_info *kinfo,
>  
>      res = find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_banks),
>                                    ext_regions, add_ext_regions);
> +
> + out:
> +    xfree(xen_reg);
>      xfree(gnttab);
>  
>      return res;
> diff --git a/xen/common/device-tree/domain-build.c b/xen/common/device-tree/domain-build.c
> index 6b8b8d7cacb6..99ea81198a76 100644
> --- a/xen/common/device-tree/domain-build.c
> +++ b/xen/common/device-tree/domain-build.c
> @@ -193,6 +193,10 @@ int __init find_unallocated_memory(const struct kernel_info *kinfo,
>  
>      /* Remove all regions listed in mem_banks */
>      for ( i = 0; i < nr_mem_banks; i++ )
> +    {
> +        if ( !mem_banks[i] )
> +            continue;
> +
>          for ( j = 0; j < mem_banks[i]->nr_banks; j++ )
>          {
>              start = mem_banks[i]->bank[j].start;
> @@ -212,6 +216,7 @@ int __init find_unallocated_memory(const struct kernel_info *kinfo,
>                  goto out;
>              }
>          }
> +    }
>  
>      start = 0;
>      end = (1ULL << p2m_ipa_bits) - 1;

Other than that, LGTM:
Reviewed-by: Michal Orzel 

~Michal



From xen-devel-bounces@lists.xenproject.org Thu Jun 12 09:11:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 09:11:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012616.1391094 (Exim 4.92)
	(envelope-from )
	id 1uPdy2-0004OU-NO; Thu, 12 Jun 2025 09:11:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012616.1391094; Thu, 12 Jun 2025 09:11: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 1uPdy2-0004ON-JF; Thu, 12 Jun 2025 09:11:26 +0000
Received: by outflank-mailman (input) for mailman id 1012616;
 Thu, 12 Jun 2025 09:11: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 1uPdy1-0004OH-LI
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 09:11:25 +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 36a5c92c-476d-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 11:11:24 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3a507e88b0aso769793f8f.1
 for ; Thu, 12 Jun 2025 02:11:24 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-313c19cd5a6sm989222a91.12.2025.06.12.02.11.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 02:11:23 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 36a5c92c-476d-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749719484; x=1750324284; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=cDo1BlM0RzNvp++24metczxxzGHEiglnNNeFZVof03U=;
        b=fF8S1cXocXbrGnEzsKg8x9SEdpdBbj54hAzfSDyX4Crj2wGuVPV1Uo8y+0kiXKJ72B
         RQSq1NdcP6BMbWmqI0fYz+GHjYss4sxIV/lUIJdqn3t8qGSpei50YYmvI0gN4vRNMuLO
         00vLhN8uoQgwHnX5hH2ZoequS8GcMRT9jmi8JbMWTbxl5GKi6/vA9LymY7WQz05iVoJZ
         D+5QVXVQnfcnw+ii2DriTjj2Ghl1udJfoVqu1VWR89Ph0NDImUuwuW9CRVzXD5OZ4aMq
         /SFBZuD9DRddjnNQBJ8sJVmOhRgt20wpTE3UNBrk7WWYSpMUdFe912KAYZS8WzJSHd1o
         4r3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749719484; x=1750324284;
        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=cDo1BlM0RzNvp++24metczxxzGHEiglnNNeFZVof03U=;
        b=QKQk3eUcgsgJlvVm+Irmu+L+L3N+SEu3z7JTEECdfAE4eSU3n+SoQskutylT398gXK
         EGVXw5dXiZ+K2+mZE+ejvp2yMwzJfY7XY6f6klZG3fpRkduwsyhvc4TJ5EzaFaS1dpJF
         DHukNHrl54Z8kAcQXo1/dg6JJkSJ5njGbtvYh0996wteLf9Z84Gb7jcAW56pz5sNXVdN
         BotNStaOsYahx90USAUsjE3YYoAVXCYuA9/N6KI0jX8AAaKxh68b/YpfeoK4DPP1ivYv
         xql2wFWvEPGtyZ4f7lim9WDculkdB9O6iA16spHYncN5vXfb+kIiqsUVlo9ul0aKjLJP
         5Mkg==
X-Forwarded-Encrypted: i=1; AJvYcCXP19BCxqAw9NMiNe7fqVhNzTH7T44mpQ6J2DSsfiXoFiXrELXr+W2guVeMAG/KxNfRWiuA/lLVVl4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyKO6duAGs0kjb7POYbKEfuQh+oxLCkbhTs6XLQA21dITORUxw+
	KmDVckwLoUhbjgpga/z8u2XCCxErqXG6qLBsa+IeT0+dFLcktrp/fe5eti4tv84Fv/orcW0PXh0
	BflA=
X-Gm-Gg: ASbGncsV42t4ePSAtBy8iYl7uv8ZJfwDRsaOVxVxa2DZgs7EePRztK5Rs46fOCoPsZu
	FveK3aaaHOg1TJ6MF146oBz7Wy2/CLCy309fZK1wRbxL1JWl3xuQk7i/0GDeD0PcIx2BHK6/YAm
	m+PlLWPm4FkNl116ZYT6LCLP57dpW6pv+T6qdPpmz4kSGtTUF4D9P3VCynoeTnoID2ouW0G0WKq
	WRmCNgyjiFeNTiTRmQzmp7ncteVOguuv67sE3X8tzsISna8sLTs1T/0v+BJrDtcUzS9jN36KwqG
	s5dlikFkZWXQpB8rP6awow32mt04H1Urez07nt3fYb3BlstabeqQwoePT77beV+jdmfcyUL3ShB
	Ic7aE0x3Ll/CgKpgePDw9hdz7VAumwt/qwidL9P3kJ5GI8iI=
X-Google-Smtp-Source: AGHT+IE/4oylP0h+5B2xCyXE+noN/ul9jshwhNwmViWNVgnpBKJsxA/LpcqFjEJkLr4VA5HHHzcYOA==
X-Received: by 2002:a05:6000:2211:b0:3a4:d994:be4b with SMTP id ffacd0b85a97d-3a5607485c1mr2268374f8f.1.1749719483747;
        Thu, 12 Jun 2025 02:11:23 -0700 (PDT)
Message-ID: <9e7925c4-3695-4320-8552-4ee0e39350e4@suse.com>
Date: Thu, 12 Jun 2025 11:11:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/8] pdx: introduce function to calculate max PFN based on
 PDX compression
To: Roger Pau Monne 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250611171636.5674-1-roger.pau@citrix.com>
 <20250611171636.5674-3-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: <20250611171636.5674-3-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 11.06.2025 19:16, Roger Pau Monne wrote:
> This is the code already present and used by x86 in setup_max_pdx(), which
> takes into account the current PDX compression, plus the limitation of the
> virtual memory layout to return the maximum usable PFN in the system,
> possibly truncating the input PFN provided by the caller.
> 
> This helper will be used by upcoming PDX related changes that introduce a
> new compression algorithm.
> 
> Signed-off-by: Roger Pau Monné 
> ---
>  xen/arch/x86/setup.c  | 19 ++-----------------
>  xen/common/pdx.c      | 25 +++++++++++++++++++++++++
>  xen/include/xen/pdx.h |  8 ++++++++
>  3 files changed, 35 insertions(+), 17 deletions(-)

This is all fine for x86, but on Arm you introduce unreachable code, which
Misra dislikes. Yet then it feels like it's wrong anyway that the function
isn't used there.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 09:27:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 09:27:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012630.1391104 (Exim 4.92)
	(envelope-from )
	id 1uPeDT-0006Xe-2C; Thu, 12 Jun 2025 09:27:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012630.1391104; Thu, 12 Jun 2025 09:27: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 1uPeDS-0006XX-VU; Thu, 12 Jun 2025 09:27:22 +0000
Received: by outflank-mailman (input) for mailman id 1012630;
 Thu, 12 Jun 2025 09:27: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 1uPeDR-0006XR-Ha
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 09:27:21 +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 6a8b6cc5-476f-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 11:27:10 +0200 (CEST)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-4533027c0ceso2187905e9.1
 for ; Thu, 12 Jun 2025 02:27:19 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2364e71951dsm9477815ad.220.2025.06.12.02.27.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 02:27:17 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6a8b6cc5-476f-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749720438; x=1750325238; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=cZApT+XQfkEfc+EvMaQtY7Y9mohLcsC+SvTkdAMk9fQ=;
        b=ErJHEyhHFccwVNCYJUvRAWNHaNd2DDTOMWjdOVQCgLDPa8xORn5TGnbxYAFlgfN51n
         rv35EZD4s+v2upZoLpktaU67CYXpGj24Mez9ILotUdlRU18CYdyxXEotIMYA3NW3BGA9
         M9kXlxA06sSywyG8ElpaxEyLyFQaPlPfkKifzwU9ysx6ERh76RNBUjLjFItvqWZCLAH/
         6qNLtBk7Tm6DnUZ3+T+tQkelKNzAh2uXAXxck/RRMj8PDzZ2vK278NaxBudmP/bx4Squ
         tUfdrplnI8sbTIqPk1huTcnBjr/ck2kY1CTru55LPZDrBrBnUDR0fpGBNHzDl4gHXgfs
         3/mA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749720438; x=1750325238;
        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=cZApT+XQfkEfc+EvMaQtY7Y9mohLcsC+SvTkdAMk9fQ=;
        b=uvp+4xHcuKlf3clP6ltcNWp9I3b50qn6ph0YUfr2MhapdLWp7PYdll6PbeOoDCByps
         zIJeIVY78TCybCuYkA4eW9VgNcdsR8QNxjNhSRSTJCxIIzIKJPLFb7Lac87CKbBb3ge2
         wRnRJmD6z/Sej1MLj9qLa95lI9a/U7lX/zgeWM2YrAmaZLoUN1gFdiJfU34AVq4cvh7p
         AGsGDC301OqQoZGEV53QIAKgQybe/RyFfVSQM14DxuwJMa9W4Z6syTru4SgvEjuaWAAa
         jCpBBnd5ZitAUXKBsjnxPC1/fkuiOOsycGI9+ztlWqajx9A5AyoZPPrA0iY/HpbkwA3N
         rw/Q==
X-Forwarded-Encrypted: i=1; AJvYcCVnwOXaT4l5bFscVzmYIzwqfBvBkzIXq1KeFbFUsP8ttoB4K4jyr7Dm39KOeiXo1kGy+kdFC71qTVw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxelcaWAmadk91YVMW48XQqAnN3n/OaTCBOdnxuyUrCNJAen08N
	zpVXzoPTn2SOLFwSs3qOLfU0dgldhWehG5T/FHNCGKFIV56QGjxt0ahhXS07wHScrg==
X-Gm-Gg: ASbGncsQ0M1FSEQfB7RZ3a50xdnFypl4WCzYkDsKSS780P+y/WEQOZrEBqwrk/0ea0L
	1kdmq3G0h5duA6AY7HeFThKVzHuVGllOcAuAH2jMwZKuQvIt5VJVEzf+Ez9SoEqCFPITTl7n54J
	j+OCw+RdGAsrrcBYuQxD0ZChN0AdsW15LC+foRuI7UMT8QsvwwPPukUeQXMPFPMgh+780193YA7
	0Oba7zyxgEg39BGFUHWnigpVWgpv5nt3nIvGyItUAi51gn6mz7S9GjCVA2jnw+svsT3EqaQnKZd
	r+CoKvhCzajq7NeJBd3orY/LWFC7mKoibSgiezPl52WSjmSRIwGEXttLHgISCLeVZ4xH0ogdQQq
	szgprWjS/nR1yHQJeJU76ok1O4M5KDGfBBOwctoDu+8FjCQQ=
X-Google-Smtp-Source: AGHT+IFQFQt0vRFbM02Ea0B2dzxpfXFN910fZ6mjq2baEZEeF0amH4aqQU8raqsz+tO4NU7bl4ygaQ==
X-Received: by 2002:a5d:5c84:0:b0:3a4:eb80:762d with SMTP id ffacd0b85a97d-3a560769194mr2144127f8f.56.1749720438263;
        Thu, 12 Jun 2025 02:27:18 -0700 (PDT)
Message-ID: <8fbc7416-39ed-4e09-9a6f-6d84cd5747ee@suse.com>
Date: Thu, 12 Jun 2025 11:27:08 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 03/20] xen/x86: remove "depends on !PV_SHIM_EXCLUSIVE"
To: "Penny, Zheng" 
Cc: "Huang, Ray" ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 "Orzel, Michal" , Julien Grall ,
 Stefano Stabellini ,
 "xen-devel@lists.xenproject.org" 
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
 <20250528091708.390767-4-Penny.Zheng@amd.com>
 <1a73c720-012a-4795-9f47-f9c23b643de1@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 12.06.2025 10:52, Penny, Zheng wrote:
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Thursday, June 12, 2025 3:02 PM
>>
>> On 12.06.2025 06:09, Penny, Zheng wrote:
>>>> -----Original Message-----
>>>> From: Jan Beulich 
>>>> Sent: Tuesday, June 10, 2025 9:01 PM
>>>>
>>>> On 28.05.2025 11:16, Penny Zheng wrote:
>>>>> --- a/xen/arch/x86/Kconfig
>>>>> +++ b/xen/arch/x86/Kconfig
>>>>> @@ -143,7 +143,7 @@ config XEN_IBT
>>>>>
>>>>>  config SHADOW_PAGING
>>>>>     bool "Shadow Paging"
>>>>> -   default !PV_SHIM_EXCLUSIVE
>>>>> +   default y
>>>>>     depends on PV || HVM
>>>>>     help
>>>>>
>>>>> @@ -175,7 +175,7 @@ config BIGMEM
>>>>>  config TBOOT
>>>>>     bool "Xen tboot support (UNSUPPORTED)"
>>>>>     depends on INTEL && UNSUPPORTED
>>>>> -   default !PV_SHIM_EXCLUSIVE
>>>>> +   default y
>>>>>     select CRYPTO
>>>>>     help
>>>>>       Allows support for Trusted Boot using the Intel(R) Trusted
>>>>> Execution
>>>>
>>>> ... these two fit with title and description. The justification for
>>>> removing the !PV_SHIM_EXCLUSIVE here is not "breaks allyesconfig".
>>>
>>> Hmmm, it is the consequence of "removing the !PV_SHIM_EXCLUSIVE"
>>> Maybe I shall add more explanation in commit message?
>>
>> Just to clarify - my questions here were about the changes altogether, i.e.:
>> Why are these two change - as a whole - needed, given the subject? And just to try
>> to avoid any misunderstanding: My point is that "depends on ..." and "default ..." are
>> different things, when the commit message discusses only the former. So yes,
>> extending the commit message may be one way to address my remarks. But really
>> I think changes to defaults (if needed at all) would better be separate from changes
>> to "depends on ...".
>>
> 
> The reason why I added an extra default y for CONFIG_SHADOW_PAGING is that
> the .config file generated from x86_64_defconfig has changed after removing the "default !PV_SHIM_EXCLUSIVE", from "CONFIG_SHADOW_PAGING=y" to " CONFIG_SHADOW_PAGING is not set ". To fix it, I casually added a "default y" here.
> I understand that like you said, it doesn't fit with the title and description... I'll create a new commit for it. And instead of adding "default y", maybe just adding " CONFIG_SHADOW_PAGING=y" in x86_64_defconfig is enough.

No, the change (if it is really wanted / needed, which I question at least
for the time being) would need to be done to the default (unless there are
other reasons to alter the default presently used).

>>>>> --- a/xen/arch/x86/configs/pvshim_defconfig
>>>>> +++ b/xen/arch/x86/configs/pvshim_defconfig
>>>>> @@ -26,3 +26,8 @@ CONFIG_EXPERT=y
>>>>>  # CONFIG_INTEL_IOMMU is not set
>>>>>  # CONFIG_DEBUG is not set
>>>>>  # CONFIG_GDBSX is not set
>>>>> +# CONFIG_SHADOW_PAGING is not set
>>>>> +# CONFIG_TBOOT is not set
>>>>> +# HYPERV_HYPERV_GUEST is not set
>>>>
>>>> This one doesn't look right, simply by its name.
>>>>
>>>>> +# CONFIG_HVM is not set
>>>>> +# CONFIG_VGA is not set
>>>>
>>>> Just to mention it - I'm unsure whether adding such at the end isn't
>>>> going to cause issues. But maybe I'm paranoid ...
>>>>
>>>
>>> It could be too casual..
>>> I will only leave VGA here, as we're sure that with removing
>>> "!PV_SHIM_EXCLUSIVE", CONFIG_VGA is setting as y in pvshim_defconfig
>>
>> I don't follow: Why would a shim need VGA support compiled in?
> 
> Yes, VGA shall not be compiled for a shim. And it is the reason why I added "# CONFIG_VGA is not set" in pvshim_defconfig. Without it, the consequence of removing " if !PV_SHIM_EXCLUSIVE " for VGA is that when we run "make defconfig pvshim_defconfig", we will get CONFIG_VGA=y in .config
> Like you said, this change belongs to the group of changing kconfig default values, and will later be included in a new commit

I keep being confused by what you say; will need to see how v5 is going to
look like.

>>>>> --- a/xen/drivers/video/Kconfig
>>>>> +++ b/xen/drivers/video/Kconfig
>>>>> @@ -3,10 +3,10 @@ config VIDEO
>>>>>     bool
>>>>>
>>>>>  config VGA
>>>>> -   bool "VGA support" if !PV_SHIM_EXCLUSIVE
>>>>> +   bool "VGA support"
>>>>>     select VIDEO
>>>>>     depends on X86
>>>>> -   default y if !PV_SHIM_EXCLUSIVE
>>>>> +   default y
>>>>>     help
>>>>>       Enable VGA output for the Xen hypervisor.
>>>>
>>>> Like above, this change also doesn't really fit with title and description.
>>>
>>> I have added " (also the functionally equivalent "if !...") " in
>>> commit message to also cover above change
>>
>> Well. There are multiple uses of "if ...". The one matching "depends on ..." is covered
>> in the description, yes. But the two uses here don't fall in this same group. One is a
>> prompt visibility change, and the other is a change to yet another default. See above
>> for my recommendation (to split things properly).
>>
> 
> Correct me if I understand wrongly:
> "if ..." for HYPERV_GUEST is falling the group where prompt visibility changes, and fits with the title and description

No and yes. A file scope "if" acts like a "depends on" on every enclosed option.
Hence it fits with the title here, but _not_ because prompt visibility changes.
What you may be mixing up is the fact that a prompt of course _also_ becomes
invisible when an option's dependencies aren't met. Yet normally when talking
about prompt visibility, at least I would always mean the prompt for an active
option (i.e. where by hiding the prompt we just take away the user's ability
to control the value).

> "if ...." for VGA is a change regarding kconfig default value, and shall be covered in a new commit.
> Yet my changes on  pvshim_defconfig and x86_64_defconfig shall also be included in the new commit. As they are all
> talking about changing kconfig default value.

I'm not sure. When you remove a "depends on" yet at the same time you want to
retain the "off" setting for the default shim configuration, pvshim_defconfig
may still need adding to. So edits may be necessary there in more than one of
the split patches.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 09:30:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 09:30:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012636.1391113 (Exim 4.92)
	(envelope-from )
	id 1uPeGF-00081P-Et; Thu, 12 Jun 2025 09:30:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012636.1391113; Thu, 12 Jun 2025 09:30:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPeGF-00081I-CJ; Thu, 12 Jun 2025 09:30:15 +0000
Received: by outflank-mailman (input) for mailman id 1012636;
 Thu, 12 Jun 2025 09:30:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uPeGE-00081C-0C
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 09:30:14 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20612.outbound.protection.outlook.com
 [2a01:111:f403:2418::612])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d0c12da3-476f-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 11:30:02 +0200 (CEST)
Received: from SJ0PR03CA0023.namprd03.prod.outlook.com (2603:10b6:a03:33a::28)
 by CYXPR12MB9426.namprd12.prod.outlook.com (2603:10b6:930:e3::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.23; Thu, 12 Jun
 2025 09:30:07 +0000
Received: from SJ1PEPF00001CDE.namprd05.prod.outlook.com
 (2603:10b6:a03:33a:cafe::3a) by SJ0PR03CA0023.outlook.office365.com
 (2603:10b6:a03:33a::28) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.29 via Frontend Transport; Thu,
 12 Jun 2025 09:30:07 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ1PEPF00001CDE.mail.protection.outlook.com (10.167.242.6) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Thu, 12 Jun 2025 09:30:06 +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 Jun
 2025 04:29:59 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d0c12da3-476f-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=uj6v3r9rsIcrQmWe7oj28hHMHcdDL1NQLdV8hWPTzVT8hRux9sFtJEKQNpE+fBHwPPbYxH1Hm3BW4YJ50I7kU0vy9wTPVbBTSH6TP/AprsfuOXtj6QJhtYctDd2niSxQMKqHhn0jrGdHel6BhyaRieXuAGU+vLwiY6AjQGkklCRLMSwQcZG18kFGTFB+fkqgd1UoXpnGv1SmjG3rLFeC/XSLR9EL1BbuyF842YQ77n7qtXXyWfw1B2bfm5yLvA7rNqKFg/HbDLj6Muohn8xYh1Ltt4ANgraa7R2sD9DiTfn8HggaTsWvc/SK+WfMcyZGKAHn4p6Ftolxtz1uBa5OWw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Pkqn70ZAbRTvqLOKlzkzMDMievy0UdcX/JDLxlqXjys=;
 b=LAZcOxMezxc8PoCTSpgJoglOcpP3qaByiqp5JprEI5kh6qFo4WNFtSfb44ZWv4JbyIPaaw4kK7pxywHVMmJ2CpegJWpJWlHbYBeAn8ldkOe7xzr3+2+MJvAT+rZXnG1qxS7/kkFdjONUmHLBr4WeYds5CrIi4fwqVx/jbkEjGj8zuEOVLj3PTQvyaljFnVOAFuomXMC2u1Po9pqf0SP3Iv2J02xRnDw7Rw7NhtLkrOB/qqYCOkwuznBOv3sOn2indwPJyGMA53+IvIVC/UcxWBCRmV63/QFeAjv3sk19OrfKcNR3z3ZOl4JpTV+wnodxQym6aHbnAm1tihaOeMO/Xw==
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=Pkqn70ZAbRTvqLOKlzkzMDMievy0UdcX/JDLxlqXjys=;
 b=XiQmyTuZcplnj1/I1JT4jDNT7znYfouO6J+UtNmjxwvL20CoIeUFReVysK/SVL6XFaNaf+nE5/x0MR/4OBXFSEHC9aHw4PjN2gNpLl+EEbYhH10ghecq+M+5FevmzfdzkpXw+oFMiP0CbYo88kAvSjvLKHZoUREf8KRwWxhXudA=
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: Huang Rui , Jiqian Chen , "Andrew
 Cooper" , Anthony PERARD
	, Michal Orzel , Jan Beulich
	, Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Stefano
 Stabellini" 
Subject: [PATCH v6 00/8] Support hiding capability when its initialization fails
Date: Thu, 12 Jun 2025 17:29:34 +0800
Message-ID: <20250612092942.1450344-1-Jiqian.Chen@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: 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: SJ1PEPF00001CDE:EE_|CYXPR12MB9426:EE_
X-MS-Office365-Filtering-Correlation-Id: 57349c21-c286-4f1a-8989-08dda993b7d6
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?bUFlMUhBVlk2NjFEVDBrVkRLbVlCYjlTVFk4eE1RQUlnTGxlc3lBejVRV3Ft?=
 =?utf-8?B?UnhVYkU5OHoxSHF5ekZMU3Y1eGJDdEdrN0E4RXlyTlErK1dvdXdaalN2Qjdy?=
 =?utf-8?B?VVk1TzlkRDJoR3Bvb2Jna2xYRE1MR3lhSTVRR20xaVloZS8yY3ZqbHpyUmdi?=
 =?utf-8?B?VE9qUG5CQTdxSUp2ZHlrWG0wUTVGUTBWdUIzM2xLakhrRTI3cU9ReHYyU1ZK?=
 =?utf-8?B?UjFWbjZUOHUrT2FSVlVDTWxtVnhKcG8yN1pLaDYreC9LbFBqQWYvUm9yaEJM?=
 =?utf-8?B?cjNETlZjR0hzYWI4K3g5RCswSHZGY09qbk5FYlpoMThPV0QyS2Q3dmNybEo5?=
 =?utf-8?B?aXlvcWVJeG5vNnRLbElpVllsbHI0R0lhTkMwTGxxL0F6N3kwUVZTV2hCQUV3?=
 =?utf-8?B?VVJyNmFJVE1Zb2tTSnVRSmhuVWVzZ0J4NEoxM21UcmQ2ZkNzUXdMcTdUMEEr?=
 =?utf-8?B?ZDNvZG0wcTd5UGtjd1Q3d0hyVjNCTjJDWWhjbWdjS3V1elhvVUF0K3JvYi9I?=
 =?utf-8?B?MDBybml1ZHBMMExFM214aHdiRVNCay95RXQ3eDJ3VkFlb3lBYkdKYkZWMmpo?=
 =?utf-8?B?VTYyRWxxSUh5UmZrOWl6WmtzdTQ0dVl4aUIwN2tTOTlSTjNJL1l6TTV3d1RE?=
 =?utf-8?B?aE54TGJhaStONTdOeWlKaDZpanlwYW80Wkc1NWtXdzRqUy9DcHllajZvYWRS?=
 =?utf-8?B?bkRWRmdxdDJCaVBKcHAreWJZOUNuaFU5MlcyWDIzQmQzaDFwZ0xXWm1RbzRt?=
 =?utf-8?B?VjhXQkE3bGJkREtXRGg4NkVIa21sVWRLRzk5ZE1KOEphOEMvSzdMbUY2aWRT?=
 =?utf-8?B?ckZXTU9iTGxXRkVkbWFtbHBuL0Jucy93YnRUejIwZkpjVEJoTzMvWGJrMWJt?=
 =?utf-8?B?bVo2OUVRcHg5WkFsaVRYVWFHVjltVFdhazloZ2VLTmFwOUdLRTBlZTRuVTY3?=
 =?utf-8?B?Zm4ram9aeDFDSWtQNVpvWVFUNTJCSFBKeVRQaXpaTVB2aUF2MXlTSFdxUWJh?=
 =?utf-8?B?MTJBS2JuaFJtVDFZa05JWHJQOFU5RzluanAwcmRrbUdmeHIxbUlIbzBZNmNo?=
 =?utf-8?B?M2djY0JKdVBaZklmbWVuYjVYN0VDL2VKMlBwT1hOSTlLZ0F4aDZqaE8xdXU0?=
 =?utf-8?B?cVlmbnlIS3BFS2FEaDlGL2RqMGsvdnpaeitIS0t3eFhFQmhPTCtkSzZId2o2?=
 =?utf-8?B?blU1RHJySk93eEdVZ2NVMks0eTJWcWhpRWxYOTNtQ29lR0tyeSthUXdPUHRn?=
 =?utf-8?B?WFE4QnBhVlYyRVl0REt4SmFTVmU0ZGpFb05Cb000azRqc2dQSDNFb01kYlc1?=
 =?utf-8?B?SnNvamFRcE83SlE2S05MZ1NlUTd1WmI1U2MxOWhVZVNwVWVtM2hzdVBwNUNj?=
 =?utf-8?B?OHJKTDlPVUtTWTVCc0FJY0V4VHFuc1N4T0U4Yk95bUVLZnR4aXF5NGhITkg4?=
 =?utf-8?B?NG5XQW55aG9ialdCK1h4Sm5qWm1YOHUxenVzSGJoNTRUdjg4VnQ5MkNEWlpH?=
 =?utf-8?B?aDZ6eEk3NUUwL1VlazY0L1JXNXZyRUlyYk00WDF5bER1U0xhZDROK1BuQ3BE?=
 =?utf-8?B?TDRqQmhEY21FaFJrSitXY1BkVGpYdWladlFzMklDYmJyQ2JMZjR3OHJKMnEx?=
 =?utf-8?B?SWNqdVpTUmVtZTZndnZGbUh0OXBRcDVkTFA4L2szQk93dlcwNTBOTVE0T3VF?=
 =?utf-8?B?VE41cEVIMnVWMGdGQ1ljN1JlK2NPWlZUM0drcWJwSWRVWEpVcVVHUlgrMW1a?=
 =?utf-8?B?dkFVc2FseEYxNEFBbmhMMExma055S2hNSGtCWThlWW5mY1cyZlhPYVJrS3Z2?=
 =?utf-8?B?YW9qQXNqck5wNnpkZEkrd29iem03UjdZaEk0K0JZL0FKMGJqaTJNTlNKOCsr?=
 =?utf-8?B?aHVUS0NhS3NvNy9yR1paQjhaTmNja0syMjFidVRHeE84T1ZMbU1UVEMzRSta?=
 =?utf-8?B?L0U2c0dOdVZtL3YzQ1FvUHNOeXhhL0pBUzcwNEI2eVY1bVV4dnFoMmkvaG45?=
 =?utf-8?B?djdYRlZFeVZYNWZvWGoxYWVkY0tTS0ZTT3FhdldJa1NObHFDVTJkMmtMSzBk?=
 =?utf-8?Q?sqb+Hw?=
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: 12 Jun 2025 09:30:06.4774
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 57349c21-c286-4f1a-8989-08dda993b7d6
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:
	SJ1PEPF00001CDE.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYXPR12MB9426

Hi,

This series is to
emulate extended capability list for dom0, including patch #1.
hide legacy and extended capability when its initialization fails, including patch #2, #3, #4.
remove all related registers and other resources when initializing capability fails, including patch #5, #6, #7, #8.

Best regards,
Jiqian Chen.
---
cc: Andrew Cooper 
cc: Anthony PERARD 
cc: Michal Orzel 
cc: Jan Beulich 
cc: Julien Grall 
cc: "Roger Pau Monné" 
cc: Stefano Stabellini 
---
Jiqian Chen (8):
  vpci/header: Emulate extended capability list for dom0
  vpci: Refactor REGISTER_VPCI_INIT
  vpci: Hide legacy capability when it fails to initialize
  vpci: Hide extended capability when it fails to initialize
  vpci: Refactor vpci_remove_register to remove matched registers
  vpci/rebar: Free Rebar resources when init_rebar() fails
  vpci/msi: Free MSI resources when init_msi() fails
  vpci/msix: Free MSIX resources when init_msix() fails

 tools/tests/vpci/main.c    |   4 +-
 xen/arch/arm/xen.lds.S     |   3 +-
 xen/arch/ppc/xen.lds.S     |   3 +-
 xen/arch/riscv/xen.lds.S   |   3 +-
 xen/arch/x86/xen.lds.S     |   2 +-
 xen/drivers/vpci/header.c  |  50 +++++--
 xen/drivers/vpci/msi.c     |  29 +++-
 xen/drivers/vpci/msix.c    |  35 ++++-
 xen/drivers/vpci/rebar.c   |  35 +++--
 xen/drivers/vpci/vpci.c    | 278 +++++++++++++++++++++++++++++++++----
 xen/include/xen/pci_regs.h |   5 +-
 xen/include/xen/vpci.h     |  36 +++--
 xen/include/xen/xen.lds.h  |   2 +-
 13 files changed, 414 insertions(+), 71 deletions(-)

-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Jun 12 09:30:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 09:30:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012637.1391123 (Exim 4.92)
	(envelope-from )
	id 1uPeGI-0008GG-LQ; Thu, 12 Jun 2025 09:30:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012637.1391123; Thu, 12 Jun 2025 09: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 1uPeGI-0008G7-Ia; Thu, 12 Jun 2025 09:30:18 +0000
Received: by outflank-mailman (input) for mailman id 1012637;
 Thu, 12 Jun 2025 09:30: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 1uPeGH-0008FN-65
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 09:30:17 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20611.outbound.protection.outlook.com
 [2a01:111:f403:2408::611])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d8a56ae8-476f-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 11:30:16 +0200 (CEST)
Received: from MW2PR16CA0045.namprd16.prod.outlook.com (2603:10b6:907:1::22)
 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.8792.36; Thu, 12 Jun
 2025 09:30:10 +0000
Received: from SJ1PEPF00001CDF.namprd05.prod.outlook.com
 (2603:10b6:907:1:cafe::af) by MW2PR16CA0045.outlook.office365.com
 (2603:10b6:907:1::22) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Thu,
 12 Jun 2025 09:30:09 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ1PEPF00001CDF.mail.protection.outlook.com (10.167.242.7) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Thu, 12 Jun 2025 09:30:09 +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 Jun
 2025 04:30:02 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d8a56ae8-476f-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=utp2VkDVAqRDWNzBZV+Orml5b+ckQt5yHBXLsr1/aDanGxqvQ5a5Oi2b6Gw0Ke6qlzdqqGjkcBRhutvwwOWQMLAKEwikIbuJ1bpOKFcrrbRrjsZ0ppHJoCnFlfcLFaSDJSNeTbu84OyvVEj/m9HCG/DhYwET0TusRCnS5vrOI17dfStV2Z/NrgUrMZkGEOViUXcblhfKEJIF9RR67MHbOf7Lii34Z2ZpeheOE/YokI4o3AF5sOMNjP7qN+mrhErZ7m7husEpwSUaiop6LoklPUzVZwH1V5Y4FU+8abBdeIzGM4xD9NRLLGbylreDlbH0J4SesfsUrvA2KC9bZ/mcNw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=zgDixd54mOE3mQCwb7xqikH2Dl7IXnpGG7hTpXW5Ftk=;
 b=HVWsGPB5stJXIqRdaEHWcED6eUc9g8V5DjPjROR8OJALGAelDvlAKrXrgYovSyiBXvT78UXMsIwRG6TzoNWS69yo9AYodGMY3MFhr2q9RAkc3Hx5vvvcGofY0sPAnU2cVHIFe0N+LuWPoQGsLOdkN2D0098FI/Gqz+sTFbKBeOgeYMZFFkp9j0vovReh31aD+dD8w6csnMAOHu7qgi3maVM+xXX1Q+SPnSphxrTFr3GN/gxPzrdu4QJaMAqGEjlx30R1Aubb9XCh5/gd1/tT9d3ufEtUx1M5qMPDWafkoZ2nTGA5tObWuAB871AyIGofXmWr3F0ZwLpOWowG5xRgfg==
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=zgDixd54mOE3mQCwb7xqikH2Dl7IXnpGG7hTpXW5Ftk=;
 b=TZ9RviRZ59lS7J5xKYoXaIu78Xy+k4wEvwclzG9HviPG8O3hf7Cpnuk+L5r/gsgfZ2yD8lyaeYhsMIvB0eexuaVvfwobJ928UWAKRCRXI57Bo9fngy/Ix/kjzn9Tui8RIdKj32pAEyQ0K3xKnRLIVfG+Feq+MLqE1fBunvTa054=
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: Huang Rui , Jiqian Chen ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v6 1/8] vpci/header: Emulate extended capability list for dom0
Date: Thu, 12 Jun 2025 17:29:35 +0800
Message-ID: <20250612092942.1450344-2-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
References: <20250612092942.1450344-1-Jiqian.Chen@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: 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: SJ1PEPF00001CDF:EE_|SA1PR12MB7409:EE_
X-MS-Office365-Filtering-Correlation-Id: 18bc03e4-17b6-43be-3355-08dda993b959
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?ZVlRazFpSStPdGpCUUFLajEwMWhSR1p6OTdUUFduVkVlNUF6eHhsOE80cHdU?=
 =?utf-8?B?cE5MOGg0VTZVbEVWbkVmekZVdEs2UXNjZ0w2SXZhVWZPUUMxQUFrbG5JbW9S?=
 =?utf-8?B?QTIyaEN2bGlPSUl4bmNjYjRVMzIwQ3EzMHpXalV5SzVCL21sUFRkOG1aSU84?=
 =?utf-8?B?UDMvTUhhZXBYME1pbys0cUZzdWVGN2Nmbkw4SzRSQjZwZkwyQ0ZQcmFJNkJx?=
 =?utf-8?B?UXEzcTVjZDhCWjJxWmFmQnBkcHRlbVVjcFlOZ09KWDhocVVCZHdUcGN1ZC9T?=
 =?utf-8?B?L08vVndSRzBvSVdYQ1RERVJtVmtiRVU1eVVGU1JWbGlTZWpJaTM2U2JLU2Jx?=
 =?utf-8?B?d2F1WjBiSEE4MC8vRDRiOVhHV0VtVEtCRjVYeUVrSUhjOWVvSjFFdUhDTGg3?=
 =?utf-8?B?cityamRyaExFVjVWRzU5VnQ3bEt0cWNQVUR5c2VCcnJ5clNwemJMT0hYUUZ2?=
 =?utf-8?B?NmFaSW5JNi9ONCtqeHdiNVJXYVhwQzgzU1VXdkVQRGVIWkhGTHFXNGo4cm9k?=
 =?utf-8?B?eEZQTmhIWnd6OFJ2bisxWG53M2o3MEVjTitxdU5MWE5qZzJUQkQrMVNtcmZE?=
 =?utf-8?B?a09HLzBoWjVZTzhzeE5QdU5aREJ4UitCN0xVTU85Mnh2VTEyRFkvSnpjemlL?=
 =?utf-8?B?V0xCekpPMWw1SzZBaDI3VjE1R055KyttVEJUY1FzVXYyS2xSdmhSS1hCM2Rw?=
 =?utf-8?B?YXgvYWJLQlJTL0pnRFFlZURRUXpqSXovZzRXV0F5NS9yTE1HeEdMYmhsc1Nz?=
 =?utf-8?B?ajg3QXQ0TTBWSVZENEhGRHhWeHpVSC9jK3kxNUJ3czd3cExiOUd5RjB1ZGwv?=
 =?utf-8?B?VzVUUFYzWnVqZmZnZEhxRkw1MnZrVFJRcUtlbDdmTEFOMnQwdkJ1TnFua0h6?=
 =?utf-8?B?V3BlWW5pVEdhNWpkaUdHSURLaGh4bFBnTlFxZTFsRnVqMnZzRlJRVTZCaFpw?=
 =?utf-8?B?ckdSb2FKNllqOU1NbTdTeUI5R3VCNzlIZFM2U0JQaWZtYWp0N1VuSTNKSnhC?=
 =?utf-8?B?Mys1Tzk0ZUJlU3Njb1BXTmNkdktLd1RKVGw3eEl0OGVvOWplWXd1MExhZGV3?=
 =?utf-8?B?ZmFJRDBoMVBWRWdENTlwZCtxdHgwYzhPL0pSYTF3ODdmNlM2cHdUeGYvQkpS?=
 =?utf-8?B?SVJvMXlQN1hJT2ZkdVJWcEtsUkdCSTk1ajJqVk9GZFlBK0hzTVZEMXJoSXd5?=
 =?utf-8?B?dXYxOUZpVUFqaWZRQjRVZUxJK0lnUkVBakdBVXZVc1REcytKY0tDbHNzYmMw?=
 =?utf-8?B?WTgwWUs4dUpNdXVZb09iRG5OMlM5VFZoQ29hYmZ4bHJUUzBoZ2ZNUUFFQVNJ?=
 =?utf-8?B?aVY0TCs2cHZuOFFvc3VWN0prbTkyUlBEVUErd3VtNytQWkkzV0tBZ1ZGUFVL?=
 =?utf-8?B?Mk1ibTBxS2thR0N1MDJSWHg0Tk9xOGsxTExtNk1hVzYxRS9uNzlHa3ZqSGlk?=
 =?utf-8?B?dm5XUU9wUXZLaHBaYStYRjdBdWdXalRWRUFhMjAzS1RibkJyV1BwZ2hPcEZt?=
 =?utf-8?B?T2w5TGZaRWRjUnZ3cWliNzlIUWs0UEwxcURvMW5ib1JnNWZyUnN6ZUlHQ05i?=
 =?utf-8?B?OEtaODUwRjBaaGNRclhJYTBFQktPOTVWajlLMEZRd0ErMzNtQ0NLcE1YVFNX?=
 =?utf-8?B?WnhVNGlkMlo0ODVjMy82M3JkZlg4NnpFa09aOGdSZ2YxUlNzZ3hNd2svSktS?=
 =?utf-8?B?VmYwN05IZnMzTm1yYmVOZ3RjdEdCRVFKRytOd0hLOXJYQXZjVzg3NmZhOHpj?=
 =?utf-8?B?QTZuaFRZMkNNU3BEOGdiZlpWRFZ6UGVwV2JjYnIzVFhPcGFsbE5UOEMyS2Nr?=
 =?utf-8?B?cG44Z0hKMU1DMEVMRkQ3aFB6cGpxaS8xUU8vRWh5anRQRHZCTTdFWFNYekdv?=
 =?utf-8?B?SjQvSHJRWU5ja0p0M3lBSmJjTlFBTDF6bXk2VnJlbDJUcnVGdzBlcmlwWk5R?=
 =?utf-8?B?WFFuYWFKWmZMN085Wk9yYkpsMDdVRC9WZ2xSSU54WXJrZmk1b3RqQTZ0bmc2?=
 =?utf-8?B?VUlzVnRVMWdyaytOd0hPWk5udTI1Nmlja3F2WmdEUlQ5aFZwR3BkM1lJcUJv?=
 =?utf-8?Q?JAGUVM?=
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: 12 Jun 2025 09:30:09.0108
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 18bc03e4-17b6-43be-3355-08dda993b959
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:
	SJ1PEPF00001CDF.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB7409

Add a new function to emulate extended capability list for dom0,
and call it in init_header(). So that it will be easy to hide a
extended capability whose initialization fails.

As for the extended capability list of domU, just move the logic
into above function and keep hiding it for domU.

Signed-off-by: Jiqian Chen 
---
cc: "Roger Pau Monné" 
---
v5->v6 changes:
* Delete unnecessary parameter "ttl" in vpci_init_ext_capability_list()
  since vpci_add_register() can already detect the overlaps.

v4->v5 changes:
* Add check: if capability list of hardware has a overlap, print warning and return 0.

v3->v4 changes:
* Add check "if ( !header )   return 0;" to avoid adding handler for
  device that has no extended capabilities.

v2->v3 changes:
* In vpci_init_ext_capability_list(), when domain is domU, directly return after adding a handler(hiding all extended capability for domU).
* In vpci_init_ext_capability_list(), change condition to be "while ( pos >= 0x100U && ttl-- )" instead of "while ( pos && ttl-- )".
* Add new function vpci_hw_write32, and pass it to extended capability handler for dom0.

v1->v2 changes:
new patch

Best regards,
Jiqian Chen.
---
 xen/drivers/vpci/header.c | 47 ++++++++++++++++++++++++++++++++-------
 xen/drivers/vpci/vpci.c   |  6 +++++
 xen/include/xen/vpci.h    |  2 ++
 3 files changed, 47 insertions(+), 8 deletions(-)

diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
index d26cbba08ee1..a39bf2b12585 100644
--- a/xen/drivers/vpci/header.c
+++ b/xen/drivers/vpci/header.c
@@ -836,6 +836,42 @@ static int vpci_init_capability_list(struct pci_dev *pdev)
                                   PCI_STATUS_RSVDZ_MASK);
 }
 
+static int vpci_init_ext_capability_list(struct pci_dev *pdev)
+{
+    unsigned int pos = PCI_CFG_SPACE_SIZE;
+
+    if ( !is_hardware_domain(pdev->domain) )
+        /* Extended capabilities read as zero, write ignore for guest */
+        return vpci_add_register(pdev->vpci, vpci_read_val, NULL,
+                                 pos, 4, (void *)0);
+
+    while ( pos >= PCI_CFG_SPACE_SIZE )
+    {
+        uint32_t header = pci_conf_read32(pdev->sbdf, pos);
+        int rc;
+
+        if ( !header )
+            return 0;
+
+        rc = vpci_add_register(pdev->vpci, vpci_read_val, vpci_hw_write32,
+                               pos, 4, (void *)(uintptr_t)header);
+        if ( rc == -EEXIST )
+        {
+            printk(XENLOG_WARNING
+                   "%pd %pp: overlap in extended cap list, offset %#x\n",
+                   pdev->domain, &pdev->sbdf, pos);
+            return 0;
+        }
+
+        if ( rc )
+            return rc;
+
+        pos = PCI_EXT_CAP_NEXT(header);
+    }
+
+    return 0;
+}
+
 static int cf_check init_header(struct pci_dev *pdev)
 {
     uint16_t cmd;
@@ -888,14 +924,9 @@ static int cf_check init_header(struct pci_dev *pdev)
     if ( rc )
         return rc;
 
-    if ( !is_hwdom )
-    {
-        /* Extended capabilities read as zero, write ignore */
-        rc = vpci_add_register(pdev->vpci, vpci_read_val, NULL, 0x100, 4,
-                               (void *)0);
-        if ( rc )
-            return rc;
-    }
+    rc = vpci_init_ext_capability_list(pdev);
+    if ( rc )
+        return rc;
 
     if ( pdev->ignore_bars )
         return 0;
diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
index 09988f04c27c..8474c0e3b995 100644
--- a/xen/drivers/vpci/vpci.c
+++ b/xen/drivers/vpci/vpci.c
@@ -267,6 +267,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/vpci.h b/xen/include/xen/vpci.h
index fc8d5b470b0b..61d16cc8b897 100644
--- a/xen/include/xen/vpci.h
+++ b/xen/include/xen/vpci.h
@@ -80,6 +80,8 @@ void cf_check vpci_hw_write8(
     const struct pci_dev *pdev, unsigned int reg, uint32_t val, 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 Thu Jun 12 09:30:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 09:30:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012638.1391134 (Exim 4.92)
	(envelope-from )
	id 1uPeGK-0008VK-3L; Thu, 12 Jun 2025 09:30:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012638.1391134; Thu, 12 Jun 2025 09:30: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 1uPeGJ-0008VA-VE; Thu, 12 Jun 2025 09:30:19 +0000
Received: by outflank-mailman (input) for mailman id 1012638;
 Thu, 12 Jun 2025 09: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 1uPeGI-0008FN-RC
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 09:30:18 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20609.outbound.protection.outlook.com
 [2a01:111:f403:2412::609])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d930e516-476f-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 11:30:17 +0200 (CEST)
Received: from MW2PR16CA0063.namprd16.prod.outlook.com (2603:10b6:907:1::40)
 by IA0PPF12042BF6F.namprd12.prod.outlook.com (2603:10b6:20f:fc04::bc8) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8655.33; Thu, 12 Jun
 2025 09:30:11 +0000
Received: from SJ1PEPF00001CDF.namprd05.prod.outlook.com
 (2603:10b6:907:1:cafe::df) by MW2PR16CA0063.outlook.office365.com
 (2603:10b6:907:1::40) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.22 via Frontend Transport; Thu,
 12 Jun 2025 09:30:10 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ1PEPF00001CDF.mail.protection.outlook.com (10.167.242.7) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Thu, 12 Jun 2025 09:30:10 +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 Jun
 2025 04:30:04 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d930e516-476f-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=p1vUpOtgG5qpLGUmNM4lJrxqVXYobpNmFxrFBdl6ZRkYKbKrBwZ9KlnAzZ5Dj3RGSqoifA9p8r085W1XfsxeTYmj/a2HZjBKcUoew1rfTUKNtgv4Wpmnk1PMNqrMaMpoUZhlthkpNrauvp0IzaxkuqS6cu2BDrrF0Xf+uHypSXUEzPO5bQHZKOBKqKJPDWX+OJZw+zQzTgrh/WWSWaSq9pYGUNTnp0O1JxT9jnBi4KwPjP55Kmt0Ndb8yPbCzcfNUjtUfqwu6NhLR7uUQ3VBEfXEFPBApeWjt5/xMapViav04G3CDBzxiM57cq1h5ASHifxSzmWmGZk6IFt7VNLsvw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=U/ChNhMBnlTEwj3H/64jYRfXdSgIPOdNNIOVJgRyNH8=;
 b=X0+BK0S0WLDZz7ce8/vVtL53HRQBALBiBwuhu7IZ6yGu+Lhk8pft9rC56xp96tGjnPeTDiliV0VdRvoGmxZF+vXDdYPSRlUq1eFn0tE3b0xNOz8ZgoInurWsNASLGFPIM2A/JIylVjkV9eZL9OMzJN12fz980upcWhOQv03Bb3zawfLt5Jjp+eVC4TYmyg8sAev99jZbHdLIi9sZtsLi5LfwQX0NuspbwKlWALNvk0w/3Ez9nEhBqO1+jBWk4bn+FO7eZRc8wZ9AhAEo8rFAx1a5QuJXJl8yuFsebYYAab33lm6Q/QvckXOWvHyus+y2/qFOOAv7lGlcs4Cw3DeQXg==
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=U/ChNhMBnlTEwj3H/64jYRfXdSgIPOdNNIOVJgRyNH8=;
 b=oOvnggYOJ5aXTkN+A1q/BLiQMZXAGdEK69iRpWionH8A1hHrnFrJvmjTuwW++mz354eefKfqun4VPOKo6uv1H1wbMmiHyBHZaHeXgvrIqvhFiodB9iErnDmJyztUBOaUaI8buMzwjtlhgg+uZ8G/yC2n0FZAL0NzNl3Ek/jIXXI=
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: Huang Rui , Jiqian Chen ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , "Julien
 Grall" , Stefano Stabellini 
Subject: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
Date: Thu, 12 Jun 2025 17:29:36 +0800
Message-ID: <20250612092942.1450344-3-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
References: <20250612092942.1450344-1-Jiqian.Chen@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: 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: SJ1PEPF00001CDF:EE_|IA0PPF12042BF6F:EE_
X-MS-Office365-Filtering-Correlation-Id: 90c97f06-4a4f-4520-8e4a-08dda993ba4e
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?NVQ5emhwcVJPTVNObGdTVkhTc2w4N0pudmt3SU01Z2FES3R3c1h1dGNCMU5W?=
 =?utf-8?B?WVJFWm54N2tpd2sxZXZxR0tHSXFlZm9IbFUwMnZFOW1RaEE5TzhBMGpyaDlx?=
 =?utf-8?B?WS9BWnY1Ly9WNWtydlV6a1dRYWlhcGJKeTVJUDJTcE5MU0ZTWDBZUmV1YTdu?=
 =?utf-8?B?M0xicytpRmZCbVY3UkpCN0RhTXBLbElwT3hHODdWVHhHSitKYlFxSUN6eTE4?=
 =?utf-8?B?Sk5Sbk83bWJ6QzNTWThkRkZ3aitMRWlCdVk3MTZmc05Ua2JHV2UxV2lLWDdi?=
 =?utf-8?B?VDY3Ui9Gd0tibVE5Y0ZHa0pOT1NBeVJqR1JqWnpTMmptU0ZuNkEzdFJsWHB1?=
 =?utf-8?B?bTV1ak05SkpPRE9EbEI5S3IyWGRoL3Vjbm4yTEtNcjVDMVJGV3VFT0FMTFdR?=
 =?utf-8?B?eWtaMnBqQ3JSUmJmVVVESG1VY3YwRnczNXBzMDhDQ3FWNE1CQTVwVWt6TWcv?=
 =?utf-8?B?Lzg4SWtvUVUvRjNMZDg0TFBnRE1PRjRFTmM1bloyRTlyelJubHFqTGNoNW9D?=
 =?utf-8?B?bnVYNmJ1eDRId21Nb3FsQU5JSk9MRGNDbVNEU3NjNGlpRmJSNlV1NEd1Wi8y?=
 =?utf-8?B?THgxRExKNDhNUWJmT205NUtFNVh3V2tTRGhxMlg0S0JNY0hReU0rYzRENXlH?=
 =?utf-8?B?WmZJUDBTd0owOE8vOFNDSk1OUzZUTE1GazFjc3orcUdJK1lWdWZlRzh3bnp6?=
 =?utf-8?B?OStsYkdZQ0FobGNYMjNEZEc5U3AwY1NrTGhkS2VjY1lrVEFZMWVSVW1ZaHd2?=
 =?utf-8?B?NXpmMUplMkhuQktSeUtNRlVUWlNqU3VaT0x0Vm1FcFlWZ2tRS3BrZTZnN2lF?=
 =?utf-8?B?Z0FZeFdCUHNBNk9wNnQ4M2tjSWZsQ2xpSjU4WlhIc0syRkpVeHMwc3BORjFu?=
 =?utf-8?B?K01DVmhYZVpUbGE0SUdvekNGbzg4Yjh2a25OT0hGNDcyODNJeWYwOFZKRHhU?=
 =?utf-8?B?eVFlL1NKRFZVN2lJd2ZacGtXN1lxano0MUIyV2FIUmEzcG9lUjFoa1VzVUlj?=
 =?utf-8?B?cUtvRkdBdmxwUkxWaVB3Q1ZFSVlNWVpqU0hTMWhhNkc4R2NpSnJDdTBDV1dG?=
 =?utf-8?B?NjEyU1FOV09VYXlBWXo5Z0lONndLb21pcGozRlNlS3BLUFVxMTBNU0RRNnJ3?=
 =?utf-8?B?VTNyRlFGYTQ1QUkweGsrK202cGg4b1ZtVFpoUGFCeEhGdkVhRm14am84UWd1?=
 =?utf-8?B?cWpUMEUwaVphbzYzYm1pdGE0dENLbVF5NEJoWnZTTWMzM3B0SjNGcFkzcVdN?=
 =?utf-8?B?dHd0eVZ5blhOUjlMcmJNR09pTnBjM29wd0wwdXVTTGRYSUM4R3E2ZjNmYlo0?=
 =?utf-8?B?N1BCRFdCY3BCbVRVclZrY1lsa2Q2Z2xkZmxpa2dpeEZEVWVRb2gzYU5QZ3lP?=
 =?utf-8?B?VnF1QjAvamFXVkxFUGdHTWhEVVBhM3g0TUdmVW0rakgxVmErTlVrR2tycGtE?=
 =?utf-8?B?Umkxek12SHpXTUorN3prQ2dFYXMxK0V6OWZ0WVZnQWdNS2ZzNEJma01rQXBU?=
 =?utf-8?B?U0xOUFdsVDd0TnRyTVdLd2VucmxhdWduUkE3WVV6dndvMHhkdnZ2b0JYTHdR?=
 =?utf-8?B?TG5MU1hoeU51Q28vSGJQNCtteTA0ZHlRclY4VlFUa2ErVlRmOFBLWGg2ZzIz?=
 =?utf-8?B?b1dCUmozUkJLZ05lZzdiOXRYODBBSnUzSFI0Q3RaQUhCZFlEdkRUaFpxQlE0?=
 =?utf-8?B?b0s2MnVKa3NFU3A4M0NYekN6K1ozdUJGNllXSEtRZGUwQ0VFWEFJVHhTdTJD?=
 =?utf-8?B?Y2g0RGFSTWpZaDFXSG1lNFNPZW9LTy8weTJzZ1huSGltSVoxRkdZSlZRaGEx?=
 =?utf-8?B?dWExYkxxWXhlYVRZajhJMEpkWUtSQm9ZZHkvWnl1R2FRdE1iYzdEK3FRdklT?=
 =?utf-8?B?Z3JSbEREcDR3R1ZuWURES0xLbzNGSGZncVh5SmdnSTI5MWY2K09kRDZqcWdI?=
 =?utf-8?B?Y1ZnZkZibUlIaHZkRThqR3lhbURGRjUzaVZRd0w2SkZ5RmdPNkw3NDJkbjAr?=
 =?utf-8?B?c2J0VGhaQk0rWEZkUHJ3Q2JXbW41RzJMM0NaMStpZSszb2lPUmhkdENsdG9H?=
 =?utf-8?Q?eMs5ef?=
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: 12 Jun 2025 09:30:10.6201
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 90c97f06-4a4f-4520-8e4a-08dda993ba4e
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:
	SJ1PEPF00001CDF.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PPF12042BF6F

Refactor REGISTER_VPCI_INIT to contain more capability specific
information, this will benefit further follow-on changes to hide
capability when initialization fails.

What's more, change the definition of init_header() since it is
not a capability and it is needed for all devices' PCI config space.

After refactor, the "priority" of initializing capabilities isn't
needed anymore, so delete its related codes.

Note:
Call vpci_make_msix_hole() in the end of init_msix() since the change
of sequence of init_header() and init_msix().

The cleanup hook is also added in this change, even if it's still
unused. Further changes will make use of it.

Signed-off-by: Jiqian Chen 
---
cc: "Roger Pau Monné" 
cc: Andrew Cooper 
cc: Anthony PERARD 
cc: Michal Orzel 
cc: Jan Beulich 
cc: Julien Grall 
cc: Stefano Stabellini 
---
v5->v6 changes:
* Rename REGISTER_PCI_CAPABILITY to REGISTER_VPCI_CAPABILITY.
* Move vpci_capability_t entry from ".data.vpci" to ".data.rel.ro.vpci" and
  move the instances of VPCI_ARRAY in the linker scripts before *(.data.rel.ro).
* Change _start/end_vpci_array[] to be const pointer array.

v4->v5 changes:
* Rename REGISTER_VPCI_CAP to REGISTER_PCI_CAPABILITY, rename REGISTER_VPCI_LEGACY_CAP to
  REGISTER_VPCI_CAP, rename REGISTER_VPCI_EXTENDED_CAP to REGISTER_VPCI_EXTCAP.
* Change cleanup hook of vpci_capability_t from void to int.

v3->v4 changes
* Delete the useless trailing dot of section ".data.vpci".
* Add description about priority since this patch removes the initializing priority of
  capabilities and priority is not needed anymore.
* Change the hook name from fini to cleanup.
* Change the name x and y to be finit and fclean.
* Remove the unnecessary check "!capability->init"

v2->v3 changes:
* This is separated from patch "vpci: Hide capability when it fails to initialize" of v2.
* Delete __maybe_unused attribute of "out" in function vpci_assign_devic().
* Rename REGISTER_VPCI_EXTEND_CAP to REGISTER_VPCI_EXTENDED_CAP.

v1->v2 changes:
* Removed the "priorities" of initializing capabilities since it isn't used anymore.
* Added new function vpci_capability_mask() and vpci_ext_capability_mask() to remove
  failed capability from list.
* Called vpci_make_msix_hole() in the end of init_msix().

Best regards,
Jiqian Chen.

xen debug
---
 xen/arch/arm/xen.lds.S    |  3 +--
 xen/arch/ppc/xen.lds.S    |  3 +--
 xen/arch/riscv/xen.lds.S  |  3 +--
 xen/arch/x86/xen.lds.S    |  2 +-
 xen/drivers/vpci/header.c |  3 +--
 xen/drivers/vpci/msi.c    |  2 +-
 xen/drivers/vpci/msix.c   |  8 +++++--
 xen/drivers/vpci/rebar.c  |  2 +-
 xen/drivers/vpci/vpci.c   | 44 ++++++++++++++++++++++++++++++---------
 xen/include/xen/vpci.h    | 30 +++++++++++++++++++-------
 xen/include/xen/xen.lds.h |  2 +-
 11 files changed, 70 insertions(+), 32 deletions(-)

diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 5bfbe1e92c1e..9f30c3a13ed1 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -57,6 +57,7 @@ SECTIONS
 
        *(.rodata)
        *(.rodata.*)
+       VPCI_ARRAY
        *(.data.rel.ro)
        *(.data.rel.ro.*)
 
@@ -64,8 +65,6 @@ SECTIONS
        __proc_info_start = .;
        *(.proc.info)
        __proc_info_end = .;
-
-       VPCI_ARRAY
   } :text
 
 #if defined(BUILD_ID)
diff --git a/xen/arch/ppc/xen.lds.S b/xen/arch/ppc/xen.lds.S
index 1366e2819eed..1de0b77fc6b9 100644
--- a/xen/arch/ppc/xen.lds.S
+++ b/xen/arch/ppc/xen.lds.S
@@ -51,11 +51,10 @@ SECTIONS
 
         *(.rodata)
         *(.rodata.*)
+        VPCI_ARRAY
         *(.data.rel.ro)
         *(.data.rel.ro.*)
 
-        VPCI_ARRAY
-
         . = ALIGN(POINTER_ALIGN);
     } :text
 
diff --git a/xen/arch/riscv/xen.lds.S b/xen/arch/riscv/xen.lds.S
index 8c3c06de01f6..edcadff90bfe 100644
--- a/xen/arch/riscv/xen.lds.S
+++ b/xen/arch/riscv/xen.lds.S
@@ -46,11 +46,10 @@ SECTIONS
 
         *(.rodata)
         *(.rodata.*)
+        VPCI_ARRAY
         *(.data.rel.ro)
         *(.data.rel.ro.*)
 
-        VPCI_ARRAY
-
         . = ALIGN(POINTER_ALIGN);
     } :text
 
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index bf956b6c5fc0..b1c77b2b48d5 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -135,6 +135,7 @@ SECTIONS
 
        *(.rodata)
        *(.rodata.*)
+       VPCI_ARRAY
        *(.data.rel.ro)
        *(.data.rel.ro.*)
 
@@ -148,7 +149,6 @@ SECTIONS
        *(.note.gnu.build-id)
        __note_gnu_build_id_end = .;
 #endif
-       VPCI_ARRAY
   } PHDR(text)
 
 #if defined(CONFIG_PVH_GUEST) && !defined(EFI)
diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
index a39bf2b12585..2cf54ce60297 100644
--- a/xen/drivers/vpci/header.c
+++ b/xen/drivers/vpci/header.c
@@ -872,7 +872,7 @@ static int vpci_init_ext_capability_list(struct pci_dev *pdev)
     return 0;
 }
 
-static int cf_check init_header(struct pci_dev *pdev)
+int vpci_init_header(struct pci_dev *pdev)
 {
     uint16_t cmd;
     uint64_t addr, size;
@@ -1068,7 +1068,6 @@ static int cf_check init_header(struct pci_dev *pdev)
     pci_conf_write16(pdev->sbdf, PCI_COMMAND, cmd);
     return rc;
 }
-REGISTER_VPCI_INIT(init_header, VPCI_PRIORITY_MIDDLE);
 
 /*
  * Local variables:
diff --git a/xen/drivers/vpci/msi.c b/xen/drivers/vpci/msi.c
index 66e5a8a116be..2d45c7867de7 100644
--- a/xen/drivers/vpci/msi.c
+++ b/xen/drivers/vpci/msi.c
@@ -270,7 +270,7 @@ static int cf_check init_msi(struct pci_dev *pdev)
 
     return 0;
 }
-REGISTER_VPCI_INIT(init_msi, VPCI_PRIORITY_LOW);
+REGISTER_VPCI_CAP(PCI_CAP_ID_MSI, init_msi, NULL);
 
 void vpci_dump_msi(void)
 {
diff --git a/xen/drivers/vpci/msix.c b/xen/drivers/vpci/msix.c
index 74211301ba10..674815ead025 100644
--- a/xen/drivers/vpci/msix.c
+++ b/xen/drivers/vpci/msix.c
@@ -703,9 +703,13 @@ static int cf_check init_msix(struct pci_dev *pdev)
     pdev->vpci->msix = msix;
     list_add(&msix->next, &d->arch.hvm.msix_tables);
 
-    return 0;
+    spin_lock(&pdev->vpci->lock);
+    rc = vpci_make_msix_hole(pdev);
+    spin_unlock(&pdev->vpci->lock);
+
+    return rc;
 }
-REGISTER_VPCI_INIT(init_msix, VPCI_PRIORITY_HIGH);
+REGISTER_VPCI_CAP(PCI_CAP_ID_MSIX, init_msix, NULL);
 
 /*
  * Local variables:
diff --git a/xen/drivers/vpci/rebar.c b/xen/drivers/vpci/rebar.c
index 793937449af7..9cafd80ca2c9 100644
--- a/xen/drivers/vpci/rebar.c
+++ b/xen/drivers/vpci/rebar.c
@@ -118,7 +118,7 @@ static int cf_check init_rebar(struct pci_dev *pdev)
 
     return 0;
 }
-REGISTER_VPCI_INIT(init_rebar, VPCI_PRIORITY_LOW);
+REGISTER_VPCI_EXTCAP(PCI_EXT_CAP_ID_REBAR, init_rebar, NULL);
 
 /*
  * Local variables:
diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
index 8474c0e3b995..6e768bb32447 100644
--- a/xen/drivers/vpci/vpci.c
+++ b/xen/drivers/vpci/vpci.c
@@ -36,8 +36,8 @@ struct vpci_register {
 };
 
 #ifdef __XEN__
-extern vpci_register_init_t *const __start_vpci_array[];
-extern vpci_register_init_t *const __end_vpci_array[];
+extern const vpci_capability_t *const __start_vpci_array[];
+extern const vpci_capability_t *const __end_vpci_array[];
 #define NUM_VPCI_INIT (__end_vpci_array - __start_vpci_array)
 
 #ifdef CONFIG_HAS_VPCI_GUEST_SUPPORT
@@ -83,6 +83,32 @@ static int assign_virtual_sbdf(struct pci_dev *pdev)
 
 #endif /* CONFIG_HAS_VPCI_GUEST_SUPPORT */
 
+static int vpci_init_capabilities(struct pci_dev *pdev)
+{
+    for ( unsigned int i = 0; i < NUM_VPCI_INIT; i++ )
+    {
+        const vpci_capability_t *capability = __start_vpci_array[i];
+        const unsigned int cap = capability->id;
+        const bool is_ext = capability->is_ext;
+        int rc;
+        unsigned int pos = 0;
+
+        if ( !is_ext )
+            pos = pci_find_cap_offset(pdev->sbdf, cap);
+        else if ( is_hardware_domain(pdev->domain) )
+            pos = pci_find_ext_capability(pdev->sbdf, cap);
+
+        if ( !pos )
+            continue;
+
+        rc = capability->init(pdev);
+        if ( rc )
+            return rc;
+    }
+
+    return 0;
+}
+
 void vpci_deassign_device(struct pci_dev *pdev)
 {
     unsigned int i;
@@ -128,7 +154,6 @@ void vpci_deassign_device(struct pci_dev *pdev)
 
 int vpci_assign_device(struct pci_dev *pdev)
 {
-    unsigned int i;
     const unsigned long *ro_map;
     int rc = 0;
 
@@ -159,14 +184,13 @@ int vpci_assign_device(struct pci_dev *pdev)
         goto out;
 #endif
 
-    for ( i = 0; i < NUM_VPCI_INIT; i++ )
-    {
-        rc = __start_vpci_array[i](pdev);
-        if ( rc )
-            break;
-    }
+    rc = vpci_init_header(pdev);
+    if ( rc )
+        goto out;
+
+    rc = vpci_init_capabilities(pdev);
 
- out: __maybe_unused;
+ out:
     if ( rc )
         vpci_deassign_device(pdev);
 
diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
index 61d16cc8b897..5da2cec9464a 100644
--- a/xen/include/xen/vpci.h
+++ b/xen/include/xen/vpci.h
@@ -13,11 +13,12 @@ typedef uint32_t vpci_read_t(const struct pci_dev *pdev, unsigned int reg,
 typedef void vpci_write_t(const struct pci_dev *pdev, unsigned int reg,
                           uint32_t val, void *data);
 
-typedef int vpci_register_init_t(struct pci_dev *dev);
-
-#define VPCI_PRIORITY_HIGH      "1"
-#define VPCI_PRIORITY_MIDDLE    "5"
-#define VPCI_PRIORITY_LOW       "9"
+typedef struct {
+    unsigned int id;
+    bool is_ext;
+    int (*init)(struct pci_dev *pdev);
+    int (*cleanup)(struct pci_dev *pdev);
+} vpci_capability_t;
 
 #define VPCI_ECAM_BDF(addr)     (((addr) & 0x0ffff000) >> 12)
 
@@ -29,9 +30,22 @@ typedef int vpci_register_init_t(struct pci_dev *dev);
  */
 #define VPCI_MAX_VIRT_DEV       (PCI_SLOT(~0) + 1)
 
-#define REGISTER_VPCI_INIT(x, p)                \
-  static vpci_register_init_t *const x##_entry  \
-               __used_section(".data.vpci." p) = (x)
+#define REGISTER_VPCI_CAPABILITY(cap, finit, fclean, ext) \
+    static const vpci_capability_t finit##_t = { \
+        .id = (cap), \
+        .init = (finit), \
+        .cleanup = (fclean), \
+        .is_ext = (ext), \
+    }; \
+    static const vpci_capability_t *const finit##_entry  \
+        __used_section(".data.rel.ro.vpci") = &finit##_t
+
+#define REGISTER_VPCI_CAP(cap, finit, fclean) \
+    REGISTER_VPCI_CAPABILITY(cap, finit, fclean, false)
+#define REGISTER_VPCI_EXTCAP(cap, finit, fclean) \
+    REGISTER_VPCI_CAPABILITY(cap, finit, fclean, true)
+
+int __must_check vpci_init_header(struct pci_dev *pdev);
 
 /* Assign vPCI to device by adding handlers. */
 int __must_check vpci_assign_device(struct pci_dev *pdev);
diff --git a/xen/include/xen/xen.lds.h b/xen/include/xen/xen.lds.h
index 793d0e11450c..eb86305c11c7 100644
--- a/xen/include/xen/xen.lds.h
+++ b/xen/include/xen/xen.lds.h
@@ -188,7 +188,7 @@
 #define VPCI_ARRAY               \
        . = ALIGN(POINTER_ALIGN); \
        __start_vpci_array = .;   \
-       *(SORT(.data.vpci.*))     \
+       *(.data.rel.ro.vpci)           \
        __end_vpci_array = .;
 #else
 #define VPCI_ARRAY
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Jun 12 09:30:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 09:30:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012639.1391139 (Exim 4.92)
	(envelope-from )
	id 1uPeGK-00006i-CH; Thu, 12 Jun 2025 09:30:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012639.1391139; Thu, 12 Jun 2025 09:30: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 1uPeGK-00005y-6i; Thu, 12 Jun 2025 09:30:20 +0000
Received: by outflank-mailman (input) for mailman id 1012639;
 Thu, 12 Jun 2025 09: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 1uPeGJ-0008FN-5b
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 09:30:19 +0000
Received: from NAM02-SN1-obe.outbound.protection.outlook.com
 (mail-sn1nam02on20622.outbound.protection.outlook.com
 [2a01:111:f403:2406::622])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d9eb4d42-476f-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 11:30:18 +0200 (CEST)
Received: from MN2PR01CA0030.prod.exchangelabs.com (2603:10b6:208:10c::43) by
 DM4PR12MB7576.namprd12.prod.outlook.com (2603:10b6:8:10c::17) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8792.37; Thu, 12 Jun 2025 09:30:13 +0000
Received: from BL02EPF0001A102.namprd05.prod.outlook.com
 (2603:10b6:208:10c:cafe::7f) by MN2PR01CA0030.outlook.office365.com
 (2603:10b6:208:10c::43) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.31 via Frontend Transport; Thu,
 12 Jun 2025 09:30:43 +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.8835.15 via Frontend Transport; Thu, 12 Jun 2025 09:30:11 +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 Jun
 2025 04:30:08 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d9eb4d42-476f-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=UD6IhvCDbAW9ZNUpYZC4cKen3GwnXkWpDb08N7wmyl5jA7emsbsXCZaXyWCzc4ISHZvB3T0emherFR2v0YMXPoQtRYlPa0/C3Dp0lZQRxlXpuTKmb8fVmDeoExU0ErjJxCHwfo0EC68HJUGuRAa28x37uUL3AcrTQH+ESxl5JHUKKfmlDU4n9yZqjpGR3m4AyFDNBRhbuPgE813GcpPy220juulHK9XMmloSshqbM0nziycMjAO/asK4AfLPTvczSrF/7Y9bL7eAoBQH84ZwXR79vZUWBkAsNxbgBQwf/54o4GMMygIcJ5jMtwfZtPRqMfHVcgWlKp5FBZlJttgjxA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=7auHwpyxpytntHe/oRuau3bRRq71BOpI+30rPcbIvdw=;
 b=BM/ad6MEsM/Sa/6vUtsBT43+rYWlXGpZirs34CVOXWTBVc9CKx6kYHgV7SohfEiM5KXzi9mPFAsG4oqFzTbjfFRk+rZL2TKb2Z5I8AEwVwVBLYNPb/rnCl5Qp+o6zP8Su3swSKVKQisqZgUVNXNg0OBebsamz/1Ll4oDDVwad7Rcw7bkevV6VF+7MemhphQEc5aEuFb7fjGlW8cQuY97VG2hsfinCwsgwNV9tqIc2ha+tOzL7AZdcR+T3IMGtn4m7RHBE2y/JQ4T3PWPTbWTNphwZlYOOmp6HIQ8d3YXapDaQKYe9JY1BeIwR0HSCvk6nKPL16UOu2nuY1BxifDvaA==
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=7auHwpyxpytntHe/oRuau3bRRq71BOpI+30rPcbIvdw=;
 b=zfkaDcZApYlIHQzLIl2I2DHGTj3pD48Tc034Xdf1rNb9jNVfk3y7gfVT5spyUOG66G8ea1Y5j+jVIf91bKG6Ie8Pij3kekWMHyCSakwzqH2Lb3be5tRMh3oYBBzUZEXuZyKYIWOb3CkAsVwz7adwgw9S9ECwOZ9GZKsFPkLBhp4=
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: Huang Rui , Jiqian Chen ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , "Julien
 Grall" , Stefano Stabellini 
Subject: [PATCH v6 4/8] vpci: Hide extended capability when it fails to initialize
Date: Thu, 12 Jun 2025 17:29:38 +0800
Message-ID: <20250612092942.1450344-5-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
References: <20250612092942.1450344-1-Jiqian.Chen@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: 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: BL02EPF0001A102:EE_|DM4PR12MB7576:EE_
X-MS-Office365-Filtering-Correlation-Id: fc2f39df-4a9f-4264-0e20-08dda993bb11
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?bnZSWjZobnRnTW84R3FQeFdNVmRiQU9qN01EQlZ4cXBETGpaUllnakYzRTEr?=
 =?utf-8?B?VmZSUCtzK0tDNG1jNHd2cmxYSjFZamtUalVpV1FDdUJiNzdKRjVOUG96ME1M?=
 =?utf-8?B?eHNrczBNMWp5V0hQZ1l6azRSK2NQd3FOQzQvaWg0L2lhb1pJTWk5Tk9ISEZD?=
 =?utf-8?B?MTRwcDNZNW05SkM0YUhLcm40cXZUWmxDaUxJMGJOTTV4SGFXM2lERGtXMVZ1?=
 =?utf-8?B?V29ibkkyRGgycFFhaGJzTDZTc2h5WWhEZTJFZmpQemNraFNiNTNKaEVFYzBJ?=
 =?utf-8?B?eThDeVZxS2lxWGtwUWttamhqSWVGN2pNZ1R2SUdNZ3QxeUlUY0VxZ0lySWkw?=
 =?utf-8?B?V1dibWN2S3BYRitsZklxa0Rpb25mNnJDdDJkSCt6d1V6SkF5VnRjQkRhSzAz?=
 =?utf-8?B?aU5Rcms2UmkwUG1wb3ZQZVNFWDJZRXIzNE9GSEtjcW9mL1JpazZYWlB6dmk4?=
 =?utf-8?B?OGZSaS8rbU1tWmh0TVpXTUF0U2E0aEpORS9MVzgxMW91NXFxbUpjU05MTGlD?=
 =?utf-8?B?emVmN3E0LzluNFlSOG4xSjhMQkVlV1lLR0p1ejUrSVdQQUdndyt4dUFxRTgx?=
 =?utf-8?B?RGw2eWI4MGJKZlhZMzFMczhDVWxjNi9OM2o1eUhtUkI4VDE4bElMUkZFQ0F5?=
 =?utf-8?B?bzg0ODZLTW1WTFZ3S3RRaDl2N1dFUWdMQXNBM0tOTUZGaUxxa2ZXczVPQ25N?=
 =?utf-8?B?TDhXZ2R3eFdEbWloS21PTjBFQzJtcUJ6ckc5bTdHZlFEbDhxSXJhdHlSUzFl?=
 =?utf-8?B?TWxINjljS2QwQ1F0dWJQRlF2UUw3ZEw4bzgyU2xoZFJKS3JpRzcxazBIZG84?=
 =?utf-8?B?aUdhK0phdVpLUzB3d3FkZWQ4Mkx4RG1mMnlKT0NKeTJzNThkN0hzMHBDY0Rj?=
 =?utf-8?B?YldSUUdmRGkxcVkwRFdxcUhJemo1ZVo1ZEZ0aTN0a21aZXEvYmpCQlRZSjU5?=
 =?utf-8?B?RUlERHE3MGFYRnhUdGlOUGJRQW9RSUZ4aWYvZkV0N0gwRG11bFNHQmxRSHli?=
 =?utf-8?B?eUFIaUhNNFpOTi9SQUJSYmsrYWhrZTczN1loeUlYUllWaTdKUUUxc0ltOExP?=
 =?utf-8?B?eGNId3UrSVRyb1AxdENlL2xrbHZkaXFRQlIycm5oVXpiVWE5OEtVMG9YRVN2?=
 =?utf-8?B?UEoyb0hHT1QxNGdVbXRrSWVLaFJwM1dsWW8vSGJwalNvTDkvTTJ5eFYxelhR?=
 =?utf-8?B?bkpjUHRxS0JSbFZBcmI5d2JSVmY1bzZnQVpLVktWTmtnTU5YRTRQdnJQK1hZ?=
 =?utf-8?B?RVNTYzk1TVRjTlNrb2hjTnVCeEhRMUVuKyt5YVJLMEVQM2gzdi9XbUxZZDVB?=
 =?utf-8?B?ejZxeGh5YjUxSm0raWYzMUVuS2g5UEQySTdIN0NqbkIzKzdrR0JjL1NqTjll?=
 =?utf-8?B?ekY4UFN5Z2lIRG80MGFFR2NJSWp3Zm1GR1AzVThYanhsaWN6TStKd0wrdFkr?=
 =?utf-8?B?RWxUTzlyNEtqUW14Ty8ydWp1RTVLdy9ENTBVeSsrazhCMWgwd3JOZGZwMzVN?=
 =?utf-8?B?VDhsY2E3UEpmZDhOZUY1UUFsYzRPS1M0bmYzRDE1QXdXNCtRcHNNdTc0SUx4?=
 =?utf-8?B?YWx6NG1OSUp5UjJUemRzUEJhU2JhYmhLWVNDd1NndDRJWFh2MWYyRFQrVHNS?=
 =?utf-8?B?TzBjYUNGa3FaMERIUGJsTW1rcCtzK3JSQWhpZ2QxN0pQb0ovQ2NlajBxMTA0?=
 =?utf-8?B?dkxsc0pmNWNFTmkyelNTcUxlZU1sc2ErbzAvTjk5SG9BbUpnZm1SVEdCTkx1?=
 =?utf-8?B?bzJDR3NxM2Y0YVB3WkhkdFNndzZBRjRlNDBVcXMvaHI3ZFFIeUVySlBwMDMw?=
 =?utf-8?B?WStjbkNaeWJGWndZbk9RcXN0ZUlZMHFVYllNY2NaT3RWLys4ZExGZjcwZzJB?=
 =?utf-8?B?NGV2bDVMMkQ2U2FiT1hDdUNUV2huam1vQVlJcjdIRDFXTkdyRXRMckVMUW1R?=
 =?utf-8?B?cGZUaWE5ejRyZUFYOG1HSFkzTXVUd0YwSUw5YkRPQmkxUzBpMDBKOFlKUnFn?=
 =?utf-8?B?SUR0SmV4dTZrOC9DUUtNaHVTeFcrU24xc0pKa1VaYXNJLzlzM1Jrb3dybDNk?=
 =?utf-8?Q?1LB/DI?=
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: 12 Jun 2025 09:30:11.9783
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: fc2f39df-4a9f-4264-0e20-08dda993bb11
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: DM4PR12MB7576

When vpci fails to initialize a extended capability of device, it
just returns an error and vPCI gets disabled for the whole device.

So, add function to hide extended capability when initialization
fails. And remove the failed extended capability handler from vpci
extended capability list.

Signed-off-by: Jiqian Chen 
---
cc: "Roger Pau Monné" 
cc: Andrew Cooper 
cc: Anthony PERARD 
cc: Michal Orzel 
cc: Jan Beulich 
cc: Julien Grall 
cc: Stefano Stabellini 
---
v5->v6 changes:
* Change to use for loop to compact code of vpci_get_previous_ext_cap_register().
* Rename parameter rm to r in vpci_ext_capability_hide().
* Change comment to describ the case that hide capability of position
  0x100U.

v4->v5 changes:
* Modify the hex digits of PCI_EXT_CAP_NEXT_MASK and PCI_EXT_CAP_NEXT to be low case.
* Rename vpci_ext_capability_mask to vpci_ext_capability_hide.

v3->v4 changes:
* Change definition of PCI_EXT_CAP_NEXT to be "#define PCI_EXT_CAP_NEXT(header)
  (MASK_EXTR(header, PCI_EXT_CAP_NEXT_MASK) & 0xFFCU)" to avoid redundancy.
* Modify the commit message.
* Change vpci_ext_capability_mask() to return error instead of using ASSERT.
* Set the capability ID part to be zero when we need to hide the capability of position 0x100U.
* Add check "if ( !offset )" in vpci_ext_capability_mask().

v2->v3 changes:
* Separated from the last version patch "vpci: Hide capability when it fails to initialize".
* Whole implementation changed because last version is wrong.
  This version gets target handler and previous handler from vpci->handlers, then remove the target.
* Note: a case in function vpci_ext_capability_mask() needs to be discussed,
  because it may change the offset of next capability when the offset of target
  capability is 0x100U(the first extended capability), my implementation is just to
  ignore and let hardware to handle the target capability.

v1->v2 changes:
* Removed the "priorities" of initializing capabilities since it isn't used anymore.
* Added new function vpci_capability_mask() and vpci_ext_capability_mask() to
  remove failed capability from list.
* Called vpci_make_msix_hole() in the end of init_msix().

Best regards,
Jiqian Chen.
---
 xen/drivers/vpci/vpci.c    | 87 ++++++++++++++++++++++++++++++++++++++
 xen/include/xen/pci_regs.h |  5 ++-
 2 files changed, 91 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
index f61dcf9e8131..0c266dd6a265 100644
--- a/xen/drivers/vpci/vpci.c
+++ b/xen/drivers/vpci/vpci.c
@@ -165,6 +165,91 @@ static int vpci_capability_hide(struct pci_dev *pdev, unsigned int cap)
     return 0;
 }
 
+static struct vpci_register *vpci_get_previous_ext_cap_register(
+    struct vpci *vpci, unsigned int offset)
+{
+    unsigned int pos = PCI_CFG_SPACE_SIZE;
+    struct vpci_register *r;
+
+    if ( offset <= PCI_CFG_SPACE_SIZE )
+    {
+        ASSERT_UNREACHABLE();
+        return NULL;
+    }
+
+    for ( r = vpci_get_register(vpci, pos, 4); r;
+          r = pos > PCI_CFG_SPACE_SIZE ? vpci_get_register(vpci, pos, 4)
+                                       : NULL )
+    {
+        uint32_t header = (uint32_t)(uintptr_t)r->private;
+
+        ASSERT(header == (uintptr_t)r->private);
+
+        pos = PCI_EXT_CAP_NEXT(header);
+        if ( pos == offset )
+            break;
+    }
+
+    return r;
+}
+
+static int vpci_ext_capability_hide(struct pci_dev *pdev, unsigned int cap)
+{
+    const unsigned int offset = pci_find_ext_capability(pdev->sbdf, cap);
+    struct vpci_register *r, *prev_r;
+    struct vpci *vpci = pdev->vpci;
+    uint32_t header, pre_header;
+
+    if ( offset < PCI_CFG_SPACE_SIZE )
+    {
+        ASSERT_UNREACHABLE();
+        return 0;
+    }
+
+    spin_lock(&vpci->lock);
+    r = vpci_get_register(vpci, offset, 4);
+    if ( !r )
+    {
+        spin_unlock(&vpci->lock);
+        return -ENODEV;
+    }
+
+    header = (uint32_t)(uintptr_t)r->private;
+    if ( offset == PCI_CFG_SPACE_SIZE )
+    {
+        if ( PCI_EXT_CAP_NEXT(header) <= PCI_CFG_SPACE_SIZE )
+            r->private = (void *)(uintptr_t)0;
+        else
+            /*
+             * The first extended capability (0x100) can not be removed from
+             * the linked list, so instead mask its capability ID to return 0
+             * and force OSes to skip it.
+             */
+            r->private = (void *)(uintptr_t)(header & ~PCI_EXT_CAP_ID(header));
+
+        spin_unlock(&vpci->lock);
+        return 0;
+    }
+
+    prev_r = vpci_get_previous_ext_cap_register(vpci, offset);
+    if ( !prev_r )
+    {
+        spin_unlock(&vpci->lock);
+        return -ENODEV;
+    }
+
+    pre_header = (uint32_t)(uintptr_t)prev_r->private;
+    pre_header &= ~PCI_EXT_CAP_NEXT_MASK;
+    pre_header |= header & PCI_EXT_CAP_NEXT_MASK;
+    prev_r->private = (void *)(uintptr_t)pre_header;
+
+    list_del(&r->node);
+    spin_unlock(&vpci->lock);
+    xfree(r);
+
+    return 0;
+}
+
 static int vpci_init_capabilities(struct pci_dev *pdev)
 {
     for ( unsigned int i = 0; i < NUM_VPCI_INIT; i++ )
@@ -204,6 +289,8 @@ static int vpci_init_capabilities(struct pci_dev *pdev)
 
             if ( !is_ext )
                 rc = vpci_capability_hide(pdev, cap);
+            else
+                rc = vpci_ext_capability_hide(pdev, cap);
             if ( rc )
             {
                 printk(XENLOG_ERR "%pd %pp: hide %s cap %u fail rc=%d\n",
diff --git a/xen/include/xen/pci_regs.h b/xen/include/xen/pci_regs.h
index 27b4f44eedf3..3b6963133dbd 100644
--- a/xen/include/xen/pci_regs.h
+++ b/xen/include/xen/pci_regs.h
@@ -448,7 +448,10 @@
 /* Extended Capabilities (PCI-X 2.0 and Express) */
 #define PCI_EXT_CAP_ID(header)		((header) & 0x0000ffff)
 #define PCI_EXT_CAP_VER(header)		(((header) >> 16) & 0xf)
-#define PCI_EXT_CAP_NEXT(header)	(((header) >> 20) & 0xffc)
+#define PCI_EXT_CAP_NEXT_MASK		0xfff00000U
+/* Bottom two bits of next capability position are reserved. */
+#define PCI_EXT_CAP_NEXT(header) \
+    (MASK_EXTR(header, PCI_EXT_CAP_NEXT_MASK) & 0xffcU)
 
 #define PCI_EXT_CAP_ID_ERR	1
 #define PCI_EXT_CAP_ID_VC	2
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Jun 12 09:30:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 09:30:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012640.1391154 (Exim 4.92)
	(envelope-from )
	id 1uPeGL-0000Xm-MD; Thu, 12 Jun 2025 09:30:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012640.1391154; Thu, 12 Jun 2025 09: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 1uPeGL-0000Wf-H6; Thu, 12 Jun 2025 09:30:21 +0000
Received: by outflank-mailman (input) for mailman id 1012640;
 Thu, 12 Jun 2025 09:30: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 1uPeGJ-00081C-SC
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 09:30:19 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on2062a.outbound.protection.outlook.com
 [2a01:111:f403:200a::62a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d50557f4-476f-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 11:30:09 +0200 (CEST)
Received: from SJ0PR03CA0022.namprd03.prod.outlook.com (2603:10b6:a03:33a::27)
 by DM3PR12MB9288.namprd12.prod.outlook.com (2603:10b6:0:4a::18) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.18; Thu, 12 Jun
 2025 09:30:11 +0000
Received: from SJ1PEPF00001CDE.namprd05.prod.outlook.com
 (2603:10b6:a03:33a:cafe::5a) by SJ0PR03CA0022.outlook.office365.com
 (2603:10b6:a03:33a::27) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.32 via Frontend Transport; Thu,
 12 Jun 2025 09:30:10 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ1PEPF00001CDE.mail.protection.outlook.com (10.167.242.6) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Thu, 12 Jun 2025 09:30:10 +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 Jun
 2025 04:30:07 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d50557f4-476f-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=XLZM0ebFaTYV/xX+esO7FhUt71lwxMuU63WRBAEYzUAhpNVWxwHOk0XqfDdlqkGaq1ZtMMw8mHInE9xwElh/zXwsEf81Hxmo4yP41Oiv2UXYTBb7MKLS2XzZAhEirVdvCTFpjYv4xxaeQPx3XslDm+wsgzSlkvBgVn339ddW1XN6cbu+7JY+1XCpqGZweX/I1xGywuIDV4U+RlRIIiMM/HeLalM33DC0KJyCUZYjdgpso5Xzwjf1Em3aLLDyrPu9oM0hc0coD6kD9TdZyMeP2lpBN9uzp91SrUAye/aXGZSceC1mOfvegMP/n5qv57x8fCfydNnHeGRLaXzqwgPP6w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=x9KdbEQaARbJLgJn///XgZA+tXdZ97Q/sZfZD9UHRes=;
 b=wb/2fq4G8KiHAwnbTVt3NyN9boBS//p5tskLfStgvQVPyNshre/YWgBELVtSqs5ffBlCw2BQEEIXrFWhbrDEJE7FyYfkXzAs7t1SJpOH2lGK52uo8IH9w0J4eMR44t1rA/MBhJBIYqK0pyqEk/5HCHOQBe3TkjOBr0BVi0X7lRkqDQTooq5Do3K02BUCW1dw87W6iG2OZwiAg+BsRmhfi4VLFcIQSlkcr6+KRiuPGu4A5p5RBR+8mEIj5GPaAqi/osDiD1m2xLyhadqIUE1jsDCVxtLCtiz85cZHJh1q+yiKlPEv843HFQa1QE8L2hwihBjY/BXffq+k2gaPTIAEaQ==
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=x9KdbEQaARbJLgJn///XgZA+tXdZ97Q/sZfZD9UHRes=;
 b=2dFrnc6b6n8ZsehgUBXwlAP1AgEgjZ1kNFddFIRQxi2U2CIEfO7Gl7wgBLwOdHSdGGCAgLRfH92wzQOW8UeZ0Zs7xy/cgdWtk1b981BjzqX/VoFwxKKnLbZDicR+0ubTtxvR5dm9d77fGbMRLtJcMJpW2tCATeWb3hrKrLRz0nQ=
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: Huang Rui , Jiqian Chen ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v6 3/8] vpci: Hide legacy capability when it fails to initialize
Date: Thu, 12 Jun 2025 17:29:37 +0800
Message-ID: <20250612092942.1450344-4-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
References: <20250612092942.1450344-1-Jiqian.Chen@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: 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: SJ1PEPF00001CDE:EE_|DM3PR12MB9288:EE_
X-MS-Office365-Filtering-Correlation-Id: e56b6d90-2baf-4cf9-5181-08dda993ba4c
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?OFFCUVhKNHI5YjZCMDBrUnFoeG53WTBKbzBvNkU5d0dUdkVFK1BVT1VrOUlV?=
 =?utf-8?B?NlV1cEpKNlFkZ21QS0ZiTWtSUldOcjd3UW1TNmY3ZnU5Q0ZlK1JWcmNsZkZn?=
 =?utf-8?B?Yk1LTWhLdE54NjByUkU0RCtyUkpKa3pMUk54Yys4ZDgrVFBNT29GekliMTk3?=
 =?utf-8?B?U21ZRzNudGlJYy9GRWxmQXV5eGhOUmxyU2xNOWZ3cmorOWd6RTkzZlI3c1F6?=
 =?utf-8?B?WERELzYrbFROYzhFSjBKMi93MGNFMnRKbGVkMFZaLzlERXNwL05WcXFTOCt1?=
 =?utf-8?B?aHlZZ1BKeDFlVFkyK3M0VXl3QnR6MGVRV0xCdjhwZXBHVlRFbWlyMFBaYWs5?=
 =?utf-8?B?V2V5UnJtMmVtV0E2VTJ3MTZjeHhHZE5la2REOTEzVVFOb1RwOFh3MGsyeW1o?=
 =?utf-8?B?cjJpZjhoZG1NQm1PdVJlZ1laUWtrU0YvM1lnY0xCQ2ticG05YjdtUHBoVmk2?=
 =?utf-8?B?UkJiOFZsTzFiSi9MQytBQmh0R1d2TU9WSjBJelgrZEhPYlNtalY4OENscnk5?=
 =?utf-8?B?b0Y3c3gvK0p1amZEdlZiN1ZJVVo3S2JpbG9uWUZicEgwTC9tVjFlMnp1SE4x?=
 =?utf-8?B?U3JjNEIwUndCNzhHN3VQdnFXWFl1ZHByU2RyL0RiR3FDMkRxcnpSOGtHVElo?=
 =?utf-8?B?K0hoS2hjRVQ1TEhybU56NVNFTkpsT2UzaGcreGVweXVOYUNCUC90NThqY3V5?=
 =?utf-8?B?SVdMOEl6d0IydDRIYllSdjUrVVBuajlkQkNIeFVlWVFHZlJYR2xrKzUzM0V6?=
 =?utf-8?B?ekhVNlZVdTBCUXFtT0JxbWYrN1hYMGhCWm5icFUwL2lGTmo2cGQ3bzhLdUd6?=
 =?utf-8?B?cjBRbEdDSU5CVVJsd3FBelc0bkprWWNWbllHSEx0elhqTFNiWWFrZjNaZ2lo?=
 =?utf-8?B?S1JkblMvaS9obmdMdHJ6Y244MGg2a1AxbUE3TDI3UjcwL2gvWVliSUhHUUFu?=
 =?utf-8?B?S3Q4ZFM0UWZCd0Z1SU5Vd0NTNVMvVmpFNkJhQ3JvTTJQSlQvUTVJZ0dIV2Z0?=
 =?utf-8?B?SHFYSERheWJpM1IxNEZ6QXVtb0ZNTjJwSnJyelZBeG85cGNUNmdGNEZPSDRG?=
 =?utf-8?B?VE5naFQxdklxZ21CR3ZhMzZNUGhtc0ZwenN0aHJyYVRCRlZySENxS1RRaUIv?=
 =?utf-8?B?ckNKNkk1MlVxZXhTZUVvZGVEZ1VUb1F5VUg0SkFqSFNzdk1zNTUzaXhrNVFU?=
 =?utf-8?B?RThyQTZqYnJsWGtDc285MThOUk1ZTnZsZUluTUwrZ0NPTHFYamJSOVVKSnkz?=
 =?utf-8?B?em1wUWRNRWR2UjZSdC9Qa0xVUzhEYWNpS1VCSjk1QTNpV1ZkT1NvTWt5Zitx?=
 =?utf-8?B?ZVB5VFR1WFM2VDgwU0lWbGpUc0MyRHRMYjJuVmV6akpXWGFmbGpISVluWXZN?=
 =?utf-8?B?TzJTZ2lqRnI1SlZZbHd5bTE4MGg0SGl1bnhBaWg2aHNpWmJxSWFtZnIxNVI0?=
 =?utf-8?B?MHhROGJWNTVvTHVkcDQvamcwRFFjZE1zOHVJMG43S2p4OFR5TFdvNFlJaExZ?=
 =?utf-8?B?R1dsYy9kTnY4Vmg5dGFoeWtOZThPZkl5MmJHaVBTUVdTTUY3SzNnaEFVUjlo?=
 =?utf-8?B?dUhYek9hdUNpakVscWhBMk1seUxuaE9CeFV5enpFbkxKcWdDdGpjRThQYUF5?=
 =?utf-8?B?MVhjMFlPL2ViaThldm1Sei9NSEFYOG1NdnQ4TlBUMkI5M0tlWGowYmc3WEk3?=
 =?utf-8?B?M0pBdE5zTXJUU3V1Mjk0am5KeE1LV3ZwWTExRnBCRzc2bnJRMWZKdmRXOEVa?=
 =?utf-8?B?aGJVcWNmZE54azFVTjRQajZXMTY3OWViTU5iL0lPT3FVZE1vZDVBZGV6MFZD?=
 =?utf-8?B?aCtxYlRJQk0wOVk2QkF1dE1CRVNNdWNXbHNkWFZudlBlWTZzekFNRGMwVm1j?=
 =?utf-8?B?SG5KT0RGMDIrUk5yRi95cU9uL1ZxVTlPN08wTVhCZElQUnZzQzlIVURiLy80?=
 =?utf-8?B?MzBBWnZkQlNjZUR6TUpXT2dCVTJWT3RTVzVnUWw0bTZLREdFM0dmY1dNRXFl?=
 =?utf-8?B?dU1qMHJtSHhIa2ttNFg2TGFOVXVsQ01QelVERmZmeFZTa2RCTEpCbVFNYW1q?=
 =?utf-8?Q?2Kr/EI?=
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: 12 Jun 2025 09:30:10.6049
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e56b6d90-2baf-4cf9-5181-08dda993ba4c
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:
	SJ1PEPF00001CDE.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3PR12MB9288

When vpci fails to initialize a legacy capability of device, it just
returns an error and vPCI gets disabled for the whole device.  That
most likely renders the device unusable, plus possibly causing issues
to Xen itself if guest attempts to program the native MSI or MSI-X
capabilities if present.

So, add new function to hide legacy capability when initialization
fails. And remove the failed legacy capability from the vpci emulated
legacy capability list.

Signed-off-by: Jiqian Chen 
---
cc: "Roger Pau Monné" 
---
v5->v6 changes:
* Rename parameter rm to r in vpci_get_register().
* Use for loop to compact the code of vpci_get_previous_cap_register().
* Rename prev_next_r to prev_r in vpci_capability_hide(().
* Add printing when cap init, cleanup and hide fail.

v4->v5 changes:
* Modify vpci_get_register() to delete some unnecessary check, so that I don't need to move function vpci_register_cmp().
* Rename vpci_capability_mask() to vpci_capability_hide().

v3->v4 changes:
* Modify the commit message.
* In function vpci_get_previous_cap_register(), add an ASSERT_UNREACHABLE() if offset below 0x40.
* Modify vpci_capability_mask() to return error instead of using ASSERT.
* Use vpci_remove_register to remove PCI_CAP_LIST_ID register instead of open code.
* Add check "if ( !offset )" in vpci_capability_mask().

v2->v3 changes:
* Separated from the last version patch "vpci: Hide capability when it fails to initialize"
* Whole implementation changed because last version is wrong.
  This version adds a new helper function vpci_get_register() and uses it to get
  target handler and previous handler from vpci->handlers, then remove the target.

v1->v2 changes:
* Removed the "priorities" of initializing capabilities since it isn't used anymore.
* Added new function vpci_capability_mask() and vpci_ext_capability_mask() to
  remove failed capability from list.
* Called vpci_make_msix_hole() in the end of init_msix().

Best regards,
Jiqian Chen.
---
 xen/drivers/vpci/vpci.c | 109 +++++++++++++++++++++++++++++++++++++++-
 1 file changed, 108 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
index 6e768bb32447..f61dcf9e8131 100644
--- a/xen/drivers/vpci/vpci.c
+++ b/xen/drivers/vpci/vpci.c
@@ -83,6 +83,88 @@ static int assign_virtual_sbdf(struct pci_dev *pdev)
 
 #endif /* CONFIG_HAS_VPCI_GUEST_SUPPORT */
 
+static struct vpci_register *vpci_get_register(struct vpci *vpci,
+                                               unsigned int offset,
+                                               unsigned int size)
+{
+    struct vpci_register *r;
+
+    ASSERT(spin_is_locked(&vpci->lock));
+
+    list_for_each_entry ( r, &vpci->handlers, node )
+    {
+        if ( r->offset == offset && r->size == size )
+            return r;
+
+        if ( offset <= r->offset )
+            break;
+    }
+
+    return NULL;
+}
+
+static struct vpci_register *vpci_get_previous_cap_register(
+    struct vpci *vpci, unsigned int offset)
+{
+    uint32_t next;
+    struct vpci_register *r;
+
+    if ( offset < 0x40 )
+    {
+        ASSERT_UNREACHABLE();
+        return NULL;
+    }
+
+    for ( r = vpci_get_register(vpci, PCI_CAPABILITY_LIST, 1); r;
+          r = next >= 0x40 ? vpci_get_register(vpci,
+                                               next + PCI_CAP_LIST_NEXT, 1)
+                           : NULL )
+    {
+        next = (uint32_t)(uintptr_t)r->private;
+        ASSERT(next == (uintptr_t)r->private);
+        if ( next == offset )
+            break;
+    }
+
+    return r;
+}
+
+static int vpci_capability_hide(struct pci_dev *pdev, unsigned int cap)
+{
+    const unsigned int offset = pci_find_cap_offset(pdev->sbdf, cap);
+    struct vpci_register *prev_r, *next_r;
+    struct vpci *vpci = pdev->vpci;
+
+    if ( !offset )
+    {
+        ASSERT_UNREACHABLE();
+        return 0;
+    }
+
+    spin_lock(&vpci->lock);
+    prev_r = vpci_get_previous_cap_register(vpci, offset);
+    next_r = vpci_get_register(vpci, offset + PCI_CAP_LIST_NEXT, 1);
+    if ( !prev_r || !next_r )
+    {
+        spin_unlock(&vpci->lock);
+        return -ENODEV;
+    }
+
+    prev_r->private = next_r->private;
+    /*
+     * Not calling vpci_remove_register() here is to avoid redoing
+     * the register search
+     */
+    list_del(&next_r->node);
+    spin_unlock(&vpci->lock);
+    xfree(next_r);
+
+    if ( !is_hardware_domain(pdev->domain) )
+        return vpci_remove_register(vpci, offset + PCI_CAP_LIST_ID, 1);
+
+    return 0;
+}
+
 static int vpci_init_capabilities(struct pci_dev *pdev)
 {
     for ( unsigned int i = 0; i < NUM_VPCI_INIT; i++ )
@@ -103,7 +185,32 @@ static int vpci_init_capabilities(struct pci_dev *pdev)
 
         rc = capability->init(pdev);
         if ( rc )
-            return rc;
+        {
+            const char *type = is_ext ? "extended" : "legacy";
+
+            printk(XENLOG_WARNING "%pd %pp: init %s cap %u fail rc=%d, mask it\n",
+                   pdev->domain, &pdev->sbdf, type, cap, rc);
+
+            if ( capability->cleanup )
+            {
+                rc = capability->cleanup(pdev);
+                if ( rc )
+                {
+                    printk(XENLOG_ERR "%pd %pp: clean %s cap %u fail rc=%d\n",
+                           pdev->domain, &pdev->sbdf, type, cap, rc);
+                    return rc;
+                }
+            }
+
+            if ( !is_ext )
+                rc = vpci_capability_hide(pdev, cap);
+            if ( rc )
+            {
+                printk(XENLOG_ERR "%pd %pp: hide %s cap %u fail rc=%d\n",
+                       pdev->domain, &pdev->sbdf, type, cap, rc);
+                return rc;
+            }
+        }
     }
 
     return 0;
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Jun 12 09:30:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 09:30:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012641.1391164 (Exim 4.92)
	(envelope-from )
	id 1uPeGO-0000rv-Uh; Thu, 12 Jun 2025 09:30:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012641.1391164; Thu, 12 Jun 2025 09: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 1uPeGO-0000ro-Qf; Thu, 12 Jun 2025 09:30:24 +0000
Received: by outflank-mailman (input) for mailman id 1012641;
 Thu, 12 Jun 2025 09:30: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 1uPeGN-00081C-Av
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 09:30:23 +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 d6bf5618-476f-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 11:30:13 +0200 (CEST)
Received: from SJ0PR03CA0021.namprd03.prod.outlook.com (2603:10b6:a03:33a::26)
 by CY8PR12MB8300.namprd12.prod.outlook.com (2603:10b6:930:7d::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.35; Thu, 12 Jun
 2025 09:30:16 +0000
Received: from SJ1PEPF00001CDE.namprd05.prod.outlook.com
 (2603:10b6:a03:33a:cafe::fc) by SJ0PR03CA0021.outlook.office365.com
 (2603:10b6:a03:33a::26) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.34 via Frontend Transport; Thu,
 12 Jun 2025 09:30:16 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ1PEPF00001CDE.mail.protection.outlook.com (10.167.242.6) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Thu, 12 Jun 2025 09:30:16 +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 Jun
 2025 04:30:14 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d6bf5618-476f-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=jd/vv5RRop1XO7UZ935/xi0DelOUWyjLztjNvDsi9Y3KxGbjalouUZXmFtuHatxqvaProZOb2DJPfqok+MyMtk56V9vuEWuZ8YjaK4gRLzb03hPzLeUrIN5Ewa/vcTGj1EyBJvxUCJAT90kHw2LK80NKqriPMJWWZRQscqR9z/Vwhfh9rqtZZyhTlb93a+9DiAfzFCs2VlE+vSCNOsbk2b46W8PG/m2FHVOXWR2vnPZqDkuAInIAfPOBlvOepCHgeyY9uQQulwZvQ164B/yA6Uv/neLnHbeMS6pJx1RUM0od9GwGIjxgjLaHnJaVUl4SgSLDETasVzcIh5uaJXGgMw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=59MmMTpM4utVui9VClobGLCu61L2IzOwfewPcUNRBbw=;
 b=DVytAvnyWahKFXXk9/uTuWWuNIARbvO+I79gGQ+wl1ywSux09WS67ozOku4u2RM/qiIREaKpCpl4kQAynnFO5S7lECYoK8NZbMMrJ509BadQolx6+ry1QnhpuPOwBL9UxRnstNSk2RQ+CX/eIa+dB3ihvEiOM7g1rNAEaMAtioGX0TpwpqVWPk2wH/kqhgeYitBLtxbn/07cVv+9TTOqluY5iebARPJBoOfER+DSYLoLO64qaqIK23lN/ipN0/wpqp4xS3vQVTsmHu6+hCqiOfBDnvVRU2RmHaUx7dmf3H72kbB3/muZXlmRjagDGZ0GP3ToFaDY6TJKv5GQd2VXKQ==
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=59MmMTpM4utVui9VClobGLCu61L2IzOwfewPcUNRBbw=;
 b=Y3U5gLgbeHePLPw3lJOtb5cN2BFXFvftTw+Vawa8TCfokJrd/aJlD92usvT2n7UDbbEK3R7s/B9AKYKzEfn0oUtEbKxD0nI41iABQrd9+1ELINZGSiTk8iLcB43QCyKG7fU3jtEq9NGYcLBQ7gkmMLv8nmw+de0imwbN/ccXKyU=
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: Huang Rui , Jiqian Chen ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v6 7/8] vpci/msi: Free MSI resources when init_msi() fails
Date: Thu, 12 Jun 2025 17:29:41 +0800
Message-ID: <20250612092942.1450344-8-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
References: <20250612092942.1450344-1-Jiqian.Chen@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: 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: SJ1PEPF00001CDE:EE_|CY8PR12MB8300:EE_
X-MS-Office365-Filtering-Correlation-Id: 122a25a3-41a0-4e0f-d6fc-08dda993bddd
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?S2wrQmFTalJERmJVWmtLSzJTdmsxaHM4anI0V0JJOUsxSFJTeVpnbFNuRHUw?=
 =?utf-8?B?Z3pEbzFYMnR6YmxtWElzWkcrSllrYUJOcENGN3V2N3U1V3VVTjdxc2Z3VHhy?=
 =?utf-8?B?MlMyUlRpNEd5eVRqK1ZCZnFqUFd5NXo4U1ovTkdtenEvSDZkS1JPWW5FdEpV?=
 =?utf-8?B?RHBNWjlUWlE5S2VwdTlmUkVqL0ZBbmxwNEZvbVlIbjBBNVZjdU5oVFZTWmIx?=
 =?utf-8?B?YUEvckxYdytoeGhBSnJzZDltS1lQa1V0b2VXQUNrejlYTkNiQlNKdmw5Tk9y?=
 =?utf-8?B?WW45TlhnakR5VndNVWs0ZmZ1MU5SbnlzRGFxR0oyK3JaYW5PaCtJU0pOUUlq?=
 =?utf-8?B?LzF2RmdPR3hNak5TMGIybU9aelh0b050M1d1VDdNT2JZaFdrMEJJYUhCRFpG?=
 =?utf-8?B?b3dweFN2TWsyVW5GVE10Y2J4R0RWa2pwOUoyb2wyRC8rM0RBLzJJem92b2pN?=
 =?utf-8?B?QjcwWVZ3Mm9OTjBXKzJvNFlyYTNHaExMYnZ4bHVmRjJZS05ERjdvNEd1SElT?=
 =?utf-8?B?dnFkOC9TalFJOVczelUySDl0dmhTSTZ3MjUvdENPekRlbHZweWRaZzMySHI4?=
 =?utf-8?B?cEpHUTJxT1I0d1N1bklseE5EWG81dnBPZ3cxeld4VUVMTTdJZ29TMDF1SURX?=
 =?utf-8?B?MWlBd3ZrclJnc1N5YVdxbk9DTFc0bTk0QnQ0MWFsNHRmLzRHekJxZnh6eTFa?=
 =?utf-8?B?Y053QlMzWWNVczFiNjM1UXZTdWpERm1UckxiT0l3aWVCNnM2VTBrVEEwTzhJ?=
 =?utf-8?B?SnhISXNwVGxCdmI3NHY1MHlYTFFlbTZZTmI2dHRQdnpKSjNGK3JHMVQ3RnZn?=
 =?utf-8?B?RDlsTHhnOE83cHhlSVRrVGd6VEhjV3NtZTIxMnpwNnQ3WUgyNnpjN3Bwdmxm?=
 =?utf-8?B?OHFuRE5RZGJVRUxXekU3Mys3YVZZZHk5QkFyd3c5Q2lYZ0pMYU1FMmJGK2FQ?=
 =?utf-8?B?cG5HeUE5WlhmclpPc1drUlNORmtMSkJkendKRGdVcFdKdWxzcE5iczRJdkFw?=
 =?utf-8?B?QkQ3WldCemt3bVBubzR0NXVCLzVqRzRMKy91a0ZNaDg0M01Xa00zMVdKS2I2?=
 =?utf-8?B?aHQ0Wk1GQXJiSkpQN3d6M2M0RjhWNXZJV0xCYTFkZmoxRmdyaU4yV29EQmVa?=
 =?utf-8?B?QUZQUjh3eHROa3dJUXJMZGNEZkpOekcyekNKUDV5WlVBQ3hyWDlWVkJMbkVB?=
 =?utf-8?B?NjVua1pQTFNUOUt5ZVl0VllpS3Ftc1FqbUI3VC9wYTg4b3o4MVZGU3lrSHpo?=
 =?utf-8?B?MVdPaTg0YzExbjNnZFIrVE9aT1JzNVV6dm9nMFY2d3UxK0JxaWJaVi9UT3dr?=
 =?utf-8?B?aVZ0SGw5akpscUdUSE1NaDRSZUdwcCtWSG9tNXF5clhjZG9CTWhPV3lOeVVC?=
 =?utf-8?B?YlZ6TUYvUDltcHYwVll1V0ZwR1Nkak5tbXRWcnlxV21zNUVtOTFYMWFHUnRy?=
 =?utf-8?B?d1dWd3J0SmM4dnFRdzhON0pibjhqRDVDMkowdmVtTFk1c25TcmNJaWNNUW1W?=
 =?utf-8?B?Qi9OL1UyajBIMmhQaTNwT1E5Mkp6ZTh4UDEvSStRRGtVR2VpaXovVnBHUjN3?=
 =?utf-8?B?VmFEREdmbkRCcVRtWUJCbVJyRlBKZDhZZ0ZhUDE4TnZ3QlRWdTQyRiszV0ZD?=
 =?utf-8?B?aS9VWHVmQ0t1SlNFNHZBU1VLNjNGb3JtdXBraGg2ckNZMnVDQ0k1QUN4Zm9Z?=
 =?utf-8?B?bGFnOUpwWXQ0cjNGU2tMVkxmNXRxdHVFVVpTNFg0VGE2VkNyRXdRcUNQdUFl?=
 =?utf-8?B?aDB0RVJkc3R6OFpOK0tFdFBGQmxoRVVvcXR5VCtHZ0NMQ1VnOWZob1BEd0hP?=
 =?utf-8?B?eXEwZFVVdXZJLzdyS3NPeWZjdkpwNjhZYU5DWkdQOFc4NEQ2cENhQ0xQbkwv?=
 =?utf-8?B?bVRFZFg3Mi96RnhCcmJEVC83ZFRBOHk0cEhsdDAza054aHlyRGpFalp2QVdY?=
 =?utf-8?B?d0g0MmJEb2w4cUtKL3BkTWpzbmxrTjVibEVGaGRhKzZZYUZHaDZlOUFsTkJ0?=
 =?utf-8?B?di9FaVNZcVVXNnlXMWYxTXpIYjNHc3hMQ2FOc0FNZzYzNFNobjNnMHcrZ0Vm?=
 =?utf-8?Q?14P77k?=
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)(82310400026)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2025 09:30:16.5934
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 122a25a3-41a0-4e0f-d6fc-08dda993bddd
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:
	SJ1PEPF00001CDE.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB8300

When init_msi() fails, current logic return fail and free MSI-related
resources in vpci_deassign_device(). But the previous new changes will
hide MSI capability and return success, it can't reach
vpci_deassign_device() to remove resources if hiding success, so those
resources must be removed in cleanup function of MSI.

To do that, implement cleanup function for MSI.

Signed-off-by: Jiqian Chen 
---
cc: "Roger Pau Monné" 
---
v5->v6 changes:
No.

v4->v5 changes:
* Change definition "static void cleanup_msi" to "static int cf_check cleanup_msi" since cleanup hook is changed to be int.
* Add a read-only register for MSI Control Register in the end of cleanup_msi.

v3->v4 changes:
* Change function name from fini_msi() to cleanup_msi().
* Remove unnecessary comment.
* Change to use XFREE to free vpci->msi.

v2->v3 changes:
* Remove all fail path, and use fini_msi() hook instead.
* Change the method to calculating the size of msi registers.

v1->v2 changes:
* Added a new function fini_msi to free all MSI resources instead of using an array to record registered registers.

Best regards,
Jiqian Chen.
---
 xen/drivers/vpci/msi.c | 29 ++++++++++++++++++++++++++++-
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/vpci/msi.c b/xen/drivers/vpci/msi.c
index 2d45c7867de7..4e106c39efae 100644
--- a/xen/drivers/vpci/msi.c
+++ b/xen/drivers/vpci/msi.c
@@ -193,6 +193,33 @@ static void cf_check mask_write(
     msi->mask = val;
 }
 
+static int cf_check cleanup_msi(struct pci_dev *pdev)
+{
+    int rc;
+    unsigned int end, size;
+    struct vpci *vpci = pdev->vpci;
+    const unsigned int msi_pos = pdev->msi_pos;
+    const unsigned int ctrl = msi_control_reg(msi_pos);
+
+    if ( !msi_pos || !vpci->msi )
+        return 0;
+
+    if ( vpci->msi->masking )
+        end = msi_pending_bits_reg(msi_pos, vpci->msi->address64);
+    else
+        end = msi_mask_bits_reg(msi_pos, vpci->msi->address64) - 2;
+
+    size = end - ctrl;
+
+    rc = vpci_remove_registers(vpci, ctrl, size);
+    if ( rc )
+        return rc;
+
+    XFREE(vpci->msi);
+
+    return vpci_add_register(pdev->vpci, vpci_hw_read16, NULL, ctrl, 2, NULL);
+}
+
 static int cf_check init_msi(struct pci_dev *pdev)
 {
     unsigned int pos = pdev->msi_pos;
@@ -270,7 +297,7 @@ static int cf_check init_msi(struct pci_dev *pdev)
 
     return 0;
 }
-REGISTER_VPCI_CAP(PCI_CAP_ID_MSI, init_msi, NULL);
+REGISTER_VPCI_CAP(PCI_CAP_ID_MSI, init_msi, cleanup_msi);
 
 void vpci_dump_msi(void)
 {
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Jun 12 09:30:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 09:30:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012642.1391169 (Exim 4.92)
	(envelope-from )
	id 1uPeGP-0000uh-9h; Thu, 12 Jun 2025 09:30:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012642.1391169; Thu, 12 Jun 2025 09: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 1uPeGP-0000u2-3J; Thu, 12 Jun 2025 09:30:25 +0000
Received: by outflank-mailman (input) for mailman id 1012642;
 Thu, 12 Jun 2025 09: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 1uPeGN-0008FN-Jn
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 09:30:23 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on20624.outbound.protection.outlook.com
 [2a01:111:f403:2407::624])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dcbe0f62-476f-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 11:30:22 +0200 (CEST)
Received: from SJ0PR03CA0019.namprd03.prod.outlook.com (2603:10b6:a03:33a::24)
 by MN2PR12MB4334.namprd12.prod.outlook.com (2603:10b6:208:1d1::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.19; Thu, 12 Jun
 2025 09:30:15 +0000
Received: from SJ1PEPF00001CDE.namprd05.prod.outlook.com
 (2603:10b6:a03:33a:cafe::2b) by SJ0PR03CA0019.outlook.office365.com
 (2603:10b6:a03:33a::24) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.35 via Frontend Transport; Thu,
 12 Jun 2025 09:30:15 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ1PEPF00001CDE.mail.protection.outlook.com (10.167.242.6) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Thu, 12 Jun 2025 09:30:15 +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 Jun
 2025 04:30:13 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: dcbe0f62-476f-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=GnngxCUfLqA+isdHJ7e7vhFXijn9uHM/ewIG8ZFNFJg1t/NI5nyMCmNkF8RyiigDu28vaDKpdtzZF6QTF7aWPHQu6XLlxsDSw2Lg40CAAcqJdJCVRjjHZneNwdttYK4FTOaJDb7Yr90tXIN4yt2EAF3Cm7xLUNXTii1uGPB8JoRSSDGLitjIxSy7AUTIiNlf2ERvRYs5YvuBCPdOQBj14gwEvTF/o++/E2DoOvMvq3C6kxtkqi/zkl2wEqVNNOCuB1V/Dods/9yc9Miiuq7i5f7+XffLzNSfuwac/Ze0spkyxJTg/BX2BtgCSikggLXztlpjYZE1/SbgbjKafwpcmg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=dba9OwLmQ/7Y1y07VvO2y1cWEQ1y3hVwbBKPQbrsKrQ=;
 b=hwP/w9/oCeKGN2vmcDc3VtEd/PMFI7vpWfu6QPouAq4XobMnQff8KmZrqaJqQYUES19rXlT4G5IGrFAgBNyvYAbTGc/FqtGwnu5w2NoZDonIqYdreI8e5w1OSVmNwDfi+UZZGT49EqI49osQf//PRVatLFoZ9v+NCbSXm66yS7NX902IxOWZ1h0qd1jvdZ/JdWBOiK/iWsgIicWXXr/Bnl/rCaQ/q/gamQVfDuq10SAlk54ivdMYbwu1Ltsv9zvC1WX2CGMlVenKHSPdVoHhWi9FDc0lCJ7hCWrxdZEaijm+3upGCs0bR8vLZ0Lwm/iT4Mu7wyOcGamOqZoKonT1aA==
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=dba9OwLmQ/7Y1y07VvO2y1cWEQ1y3hVwbBKPQbrsKrQ=;
 b=bHNjwPa/Y1rXXCtDkWYfEmkFTCBZu7ruPb2LKcwg4hQkhB71XgPmKh741KwYG7RQDSpkoc5A6sM4d/yuB9N8m7nheaqvNqWwK9lwMbt/yUWy+C2l2YJ+bgw5Gxy74jK/IqCK3c1MuCCyXK++cYHStcQW68YdPQG4tfcQz9IsOv4=
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: Huang Rui , Jiqian Chen ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v6 6/8] vpci/rebar: Free Rebar resources when init_rebar() fails
Date: Thu, 12 Jun 2025 17:29:40 +0800
Message-ID: <20250612092942.1450344-7-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
References: <20250612092942.1450344-1-Jiqian.Chen@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: 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: SJ1PEPF00001CDE:EE_|MN2PR12MB4334:EE_
X-MS-Office365-Filtering-Correlation-Id: 7128e0aa-fca3-41a5-1aac-08dda993bcf7
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?SzJ6QWg1elpCOFRUVWFlRHBIWmlaRUg1Y1JQNThkeTAxUTl4NDh6NkR4aGxV?=
 =?utf-8?B?SzlLeURNU3RyWjI1WTlYQUgweGtMSWUxVU5RdnJQcldJaWR3L21xMEFVV0Nh?=
 =?utf-8?B?bVFMNDZNelNlOFRyZWo5S3RHNVNpMG5NNVVPZE9CQnhUVGVuamZobXlhQWx1?=
 =?utf-8?B?UUxLaXdhWW1UK1gxcHRWbDQ2c1FZK1dmVXExQ2ZOK1dhemp5eVVPcFpKcVdZ?=
 =?utf-8?B?bHJHQlJYK0hmTFIyT0FmbGwwbXBad3RHU1oweUdHNVMwRnpzaWVvRmZPeEVm?=
 =?utf-8?B?c0tEVTN4Rlk5bUREbFhnd3dvamNSUmRGZUtlcU9nWHVhV0N0bVdYV2E1ZjNs?=
 =?utf-8?B?OFRBUHcvMmc5WFhLbXlnNmpyZjV6TzdyVFBHWmpRUjFKc3BTQ0lKVWRHQVhE?=
 =?utf-8?B?Ujlrek5laTRGYUhXNXhzc0Jwcy9jTzhTL0lsR1dGTDhSbHk5c3laTGtLRUF4?=
 =?utf-8?B?d09XYUtSa2Z2OFNtN2Jiem5YSnJsZm1nNXlyUTk2dlNxbTRnNTVXNTdwN2dn?=
 =?utf-8?B?Yk11cC9KZVZsMnU3QnRWd3RiK29taGl5Tm1aQ1IyT001OTBHWFpaYlpqdW5I?=
 =?utf-8?B?anF2RlJtRHhSS0NHS28vcDBRV2lYRVJxd3NyZEJCUDVudEU5NkpTUSswb3Np?=
 =?utf-8?B?d3BNRmJOaUU5dzFSanFWSmdHVFB6THF1cmcwTEcrUzRjR053WnZVVGlEUDVC?=
 =?utf-8?B?c0R6WmdrWEtiTlFzcVlLZkVrZ0tKenM0blNENHJCdldNckcvdlp4T1RqOFQx?=
 =?utf-8?B?SDJOcWZFT0hZV0JXT0dibWZtVGRpeDY1b0J1Ymw0QkFZSW1JK0d2RTJCaVpP?=
 =?utf-8?B?eXN3NzU0bFViLytaMWdVNUF2NDZ2MGFEeEhEdVZnRU54dmFCdTlpUFM4Vjc0?=
 =?utf-8?B?ZVlHTGUzK2YrOGhuWjNocjU1WWNFQ3VPSVdxbm5pdFZ0VWc3bXEwL0RiSGRq?=
 =?utf-8?B?RmY3djRMWVNibnErM1Y3NC9jakIxbDdtaVF4WldxN1hpVVFxQzNXN2ltd2tU?=
 =?utf-8?B?QjdyTlFrazd5dk51d0dhSDhwTUg0RnUvb3B3T1Q5d1pFdmxiNmNDUzdmdzk0?=
 =?utf-8?B?Uy9ublQ2SVIwd01kZXJhaE5INkZVVHNMTnVEQStrZTBOMXNEZGhQY1hmQ2ta?=
 =?utf-8?B?S3FIdE4zbHRtMTRuV3RqeUJaL2NXbE1PQVVmK2tqOFJ5ZGZCcTlRSU53d2l6?=
 =?utf-8?B?dFprenR0WERlb3FZdTJlVzdrZmJBdGtyUXdCY2Q2a2J5OVFvaDdkZkpwSEVy?=
 =?utf-8?B?TGFJZlU4NFFBMDhqWW5IOVVxczJyTk9PTXBYYW0vajVRbUlKRkthZkhNdTUr?=
 =?utf-8?B?WXZSL3NzN1BjYk9wRlN2TUYrOUw2M1huYlpEdE8zRHdXeUNWSTMzdnRkTC9S?=
 =?utf-8?B?enFodng3VW9zTnB0Q3RjcU5vTVZaS2FUMUZJaUFWeE42cDcrenFZV1AvTnRU?=
 =?utf-8?B?SlU3akRSWi9Kd241bG5kV0o5MTIrL0djYW5ZSkwvRnRxMzN1YVdoOEZ0OVkw?=
 =?utf-8?B?NVBGT2tyMml5MU9jYzZyRzFOSTU2NEdvcW1DOHpPZU9wUUxYbVUyZ0NZQXVx?=
 =?utf-8?B?SE5sRWtDQk1kT0hQY2lUWUJzVmdKQWw4WVlSUjF5cjhkbTBFLy8zUEFYYjJo?=
 =?utf-8?B?Yjk3aWN0bWVxWENFd3BTVS9CT1poVGlFOWtZUEM1QldRdGlnWFA0SjdYR2w2?=
 =?utf-8?B?ODd2cXFOdXhzY01uRW43S0RhRHRPTTQ4ZENnUFd4REV4NTZrOUNWQ1hXVHlz?=
 =?utf-8?B?dWNYMW5WOUpqc0RBMTN6OVFUd0NJazQ0UWI4YnQ2d09CMG1qZ2tQR0tVc1lw?=
 =?utf-8?B?UDV0RlU2RmZqbFJGd0tCQWk4SU9OZWhWWGN5NVB5Q2dXclVOaG5oU0pYSXlX?=
 =?utf-8?B?U1lxRHlQT2ErenlBSlhkU0NsbWlRcEhMK3NycGFTcEtWVklRV1A2NDBBM0dt?=
 =?utf-8?B?VEwzMUFaOEhJS0xmRk52eTk3RlpJb0hwdm5OdXcyQ1Vldzc1UGcvNDlwYXFR?=
 =?utf-8?B?U1F0U0hpcS9VeUNDbVk1WlZLSGxJdG1aWU94QVdRUHhhMjFUbXNYUXV5a2l6?=
 =?utf-8?Q?zW+gp6?=
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: 12 Jun 2025 09:30:15.0804
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7128e0aa-fca3-41a5-1aac-08dda993bcf7
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:
	SJ1PEPF00001CDE.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4334

When init_rebar() fails, current logic return fail and free Rebar-related
resources in vpci_deassign_device(). But the previous new changes will
hide Rebar capability and return success, it can't reach
vpci_deassign_device() to remove resources if hiding success, so those
resources must be removed in cleanup function of Rebar.

To do that, implement cleanup function for Rebar.

Signed-off-by: Jiqian Chen 
---
cc: "Roger Pau Monné" 
---
v5->v6 changes:
No.

v4->v5 changes:
* Change definition "static void cleanup_rebar" to "static int cf_check cleanup_rebar" since cleanup hook is changed to be int.

v3->v4 changes:
* Change function name from fini_rebar() to cleanup_rebar().
* Change the error number to be E2BIG and ENXIO in init_rebar().

v2->v3 changes:
* Use fini_rebar() to remove all register instead of in the failure path of init_rebar();

v1->v2 changes:
* Called vpci_remove_registers() to remove all possible registered registers instead of using a array to record all registered register.

Best regards,
Jiqian Chen.
---
 xen/drivers/vpci/rebar.c | 35 ++++++++++++++++++++++++-----------
 1 file changed, 24 insertions(+), 11 deletions(-)

diff --git a/xen/drivers/vpci/rebar.c b/xen/drivers/vpci/rebar.c
index 9cafd80ca2c9..4b1892fab3d6 100644
--- a/xen/drivers/vpci/rebar.c
+++ b/xen/drivers/vpci/rebar.c
@@ -49,6 +49,26 @@ static void cf_check rebar_ctrl_write(const struct pci_dev *pdev,
     bar->guest_addr = bar->addr;
 }
 
+static int cf_check cleanup_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 || !is_hardware_domain(pdev->domain) )
+    {
+        ASSERT_UNREACHABLE();
+        return 0;
+    }
+
+    ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(0));
+    nbars = MASK_EXTR(ctrl, PCI_REBAR_CTRL_NBAR_MASK);
+
+    return vpci_remove_registers(pdev->vpci, rebar_offset + PCI_REBAR_CAP(0),
+                                 PCI_REBAR_CTRL(nbars - 1));
+}
+
 static int cf_check init_rebar(struct pci_dev *pdev)
 {
     uint32_t ctrl;
@@ -80,7 +100,7 @@ static int cf_check init_rebar(struct pci_dev *pdev)
         {
             printk(XENLOG_ERR "%pd %pp: too big BAR number %u in REBAR_CTRL\n",
                    pdev->domain, &pdev->sbdf, index);
-            continue;
+            return -E2BIG;
         }
 
         bar = &pdev->vpci->header.bars[index];
@@ -88,7 +108,7 @@ static int cf_check init_rebar(struct pci_dev *pdev)
         {
             printk(XENLOG_ERR "%pd %pp: BAR%u is not in memory space\n",
                    pdev->domain, &pdev->sbdf, index);
-            continue;
+            return -ENXIO;
         }
 
         rc = vpci_add_register(pdev->vpci, vpci_hw_read32, rebar_ctrl_write,
@@ -97,14 +117,7 @@ static int cf_check init_rebar(struct pci_dev *pdev)
         {
             printk(XENLOG_ERR "%pd %pp: BAR%u fail to add reg of REBAR_CTRL rc=%d\n",
                    pdev->domain, &pdev->sbdf, index, rc);
-            /*
-             * Ideally we would hide the ReBar capability on error, but code
-             * for doing so still needs to be written. Use continue instead
-             * to keep any already setup register hooks, as returning an
-             * error will cause the hardware domain to get unmediated access
-             * to all device registers.
-             */
-            continue;
+            return rc;
         }
 
         bar->resizable_sizes =
@@ -118,7 +131,7 @@ static int cf_check init_rebar(struct pci_dev *pdev)
 
     return 0;
 }
-REGISTER_VPCI_EXTCAP(PCI_EXT_CAP_ID_REBAR, init_rebar, NULL);
+REGISTER_VPCI_EXTCAP(PCI_EXT_CAP_ID_REBAR, init_rebar, cleanup_rebar);
 
 /*
  * Local variables:
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Jun 12 09:30:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 09:30:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012643.1391176 (Exim 4.92)
	(envelope-from )
	id 1uPeGQ-00017P-1P; Thu, 12 Jun 2025 09:30:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012643.1391176; Thu, 12 Jun 2025 09: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 1uPeGP-00015T-RG; Thu, 12 Jun 2025 09:30:25 +0000
Received: by outflank-mailman (input) for mailman id 1012643;
 Thu, 12 Jun 2025 09: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 1uPeGO-00081C-FK
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 09:30:24 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20606.outbound.protection.outlook.com
 [2a01:111:f403:200a::606])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d78598aa-476f-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 11:30:13 +0200 (CEST)
Received: from SJ0PR03CA0021.namprd03.prod.outlook.com (2603:10b6:a03:33a::26)
 by BL1PR12MB5825.namprd12.prod.outlook.com (2603:10b6:208:394::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8813.31; Thu, 12 Jun
 2025 09:30:13 +0000
Received: from SJ1PEPF00001CDE.namprd05.prod.outlook.com
 (2603:10b6:a03:33a:cafe::2a) by SJ0PR03CA0021.outlook.office365.com
 (2603:10b6:a03:33a::26) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.34 via Frontend Transport; Thu,
 12 Jun 2025 09:30:13 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ1PEPF00001CDE.mail.protection.outlook.com (10.167.242.6) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Thu, 12 Jun 2025 09:30:13 +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 Jun
 2025 04:30:11 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d78598aa-476f-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=g8nZuXC1MrfPA+ag+xrdjsccI48z2SFM/nWhpsLN5sAxJE2xWo90Fb8fC1XkTn4vs4ebhgBMjKJl1pNb4If1hl6x4JO4XZPYo6ancZr00CCwD9Rlk0WdA/e5fQargCPiEnuYI02JmDtpoVNjgZ6Sm5GQUSUTGmM/q5A7Yh70FN7hESNWWWnjYfkxOoPa7iIJade15gT75IqLJ45XE+6YtRtQXy2UZA+IcjcGO31ZidL5ExeyvBaVe86Gb9MNuldxOBPoC3TqbCUSRim5v4yV8+RCp8fCUta874jU2PLFCjyZiwNDRsvi9HU2336QwtffN5h3m+EY8e6Okd1Pb5AJUA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=b8Y3OSeAvLikxw9k7aYsrBhFILH2KIFALF4PKBRqUC0=;
 b=fAjrn0sPxdqLn+1FyH+DWq0muW6gHyXZ60lCB74PVOFHIf0CPK7zdwBtk+Q1+RceP51q7uUl5aiMX8ynaKXKkuR0BmHf83Uf94zHDHWUh4cMom2RNtDA6eIpysZbI0r10rPk6XP0Dzk9KzjxlEmnr80MSa5WhK0T/MsuoddX8A7btXO+ob2GcQ88Z5bvhk6DIVBWyNqQbfzIrpe1actzOUuLwm3totM6PXUSQVr8UMaBafM9L3WnYTZM8N5HcuiX7H18jzMnArtboX4NYeIHI3xNjkB2u3O/oJxzu9XBseRhC8V/N1IwUiSvRdYr2Qd4G9TzgWvyzZeYAnAbmaZUxg==
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=b8Y3OSeAvLikxw9k7aYsrBhFILH2KIFALF4PKBRqUC0=;
 b=zVslfNQyeWmW3Xc0OqhGGxSx2TGfDWUlwQ624abZnPnqpd1cxt8DnlmPc7eLhlJE2jiXP6Dd6dMkN6cPRFjhkbIYLn/OAPDfLL1VudsEVDlmF54fzpw4RUkBCTvMcJi5FpA8WjLldtAyrpmkatCzCDKWzqoJN2TGc8fGEzsbcHM=
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: Huang Rui , Jiqian Chen ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Anthony PERARD
	
Subject: [PATCH v6 5/8] vpci: Refactor vpci_remove_register to remove matched registers
Date: Thu, 12 Jun 2025 17:29:39 +0800
Message-ID: <20250612092942.1450344-6-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
References: <20250612092942.1450344-1-Jiqian.Chen@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: 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: SJ1PEPF00001CDE:EE_|BL1PR12MB5825:EE_
X-MS-Office365-Filtering-Correlation-Id: a348788f-8091-4d22-3fae-08dda993bc07
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?MWY3K1FCZVplQUE4QTA4STduZ1pNV0VqL3g3Z1NiUFhOVUp6ajEyV01VRHZr?=
 =?utf-8?B?T1VUd3pEUm1NbHgrcWNsc0hOVjMyVS9YRDN6WjNqZkk4QnFFTmtZcXAzMzRE?=
 =?utf-8?B?UUNCL0RDbXcxS3hXZVpHYnQzS1hLSkVpOGV4MS90TStOWGRaUWZLaFdWZTlL?=
 =?utf-8?B?TkdNanZibHBvcUtYMG9NeVJYbkdRNXRXVWoxaURuSXNxeDdjMHkvR1p4RzMx?=
 =?utf-8?B?d1p0dnhMOElBMUlTMVF3NkYvVkRuc2NzeHMvZEI4U1VUOGIzYkdaYWZET0pq?=
 =?utf-8?B?U1F1aGwyamowbVZBUHFZdnZick5qZXNpamZKLzFDTFM3dS94NG9waXFPWndP?=
 =?utf-8?B?YWQ2QkNWR3lxSFE3ek90aFdWT1AyZndRcWVycWowYWp5bmpwMEp2T3dQTWVx?=
 =?utf-8?B?L1NNSHcyVjBkd0tvWUhuRWhuekpickNaNXVnUWZ1cnlyWHZaTEQ0cW9lWmpv?=
 =?utf-8?B?dGNTVTNHMytVVFFpM0JqME9NaXFVeTRYbFlobXQvL0hTejEwMVArSUt6ck9t?=
 =?utf-8?B?NkEyemJPQ1R4L2V1TGwyczAxanJ5MndvZi8ybGFyd0ZBUkhUZEJ1czBzaEVC?=
 =?utf-8?B?Y3ZaaWJvNW5FWGhkejF1dzNNQks3WU15U1I4T1Nla1N3d3JCQkx2VlEyU0tL?=
 =?utf-8?B?UGZ1TGxpNTc4OG5POVg2c2pxQUdXazF1QW5DOWsxVnVxTVdmMnhJU3M4YmZP?=
 =?utf-8?B?OVJQNnRmampZNVlOU1BMdG5NSnRrbTlzWEVpZXh6UmVRc1hoZGFQSGthMWVq?=
 =?utf-8?B?bEdtdzJQNDA4QkFqSHVrRkk5WTNDMEliUjdLbGZ1bHgzV2ZuaXhGL1B4Y3pW?=
 =?utf-8?B?UHFGOGhSUEJ6bldCTE0yK1U3SFhZSmhwdmRMSFZPUVlRT0NtVmROWGc2KzVH?=
 =?utf-8?B?SElwZEEwOTVUZ0lOZWRpS2k5eEdCRU94YW5qRnRZMmh1dDlSeUFNQWlMVFZ4?=
 =?utf-8?B?NTNGYUZaMEpGUy9ERWErMU93MVpqaWhvWk5MTWNxNmMydk9FWjhLMDlDOVE0?=
 =?utf-8?B?d0I4OXQyU0ZuUUxPQWFWOHV4MU42ck1lNTVTYVkwM0F2ZmhsZHc5Nkg1RTNp?=
 =?utf-8?B?ZDliL05hdG5EVXg2YkhZelhoNFZJaDR0MURxb3VYV21nKzhtc1VTTnFlN1N5?=
 =?utf-8?B?bWJ4eU5WNmM2Z0FmcHRVMVIyYzFYaDJsa0E3Nk1QMmlsRi9QbXhRVjdxVnpq?=
 =?utf-8?B?bklRYnYyVVdmVjg5QjhJQ2lQMW8vODFPSGQ1MHc3UTNHVkNBU01EcEFTbnJr?=
 =?utf-8?B?dGVLZ050eG1JRmtua25OUE94Z0hZdy82QWhoUEpndDZaYmhackovS2lhaGNQ?=
 =?utf-8?B?eFB5TmZ4VklnZ1RySWgxSkxUdm5UZ3JJSXhvYVd0SlVzR3lBZTZwc1BBVWtC?=
 =?utf-8?B?S3R4MG9sZTV6SFZHSHphU3NrQnlselFFaGF0RVlJMjFGNXMzMXNFbTdkRlBR?=
 =?utf-8?B?Y3F6S0lVZTFkckIxajZhOERsM0htbis0ZmhBaVhsRnhPbnRXbnM5eXpVYkV6?=
 =?utf-8?B?K0Y1c3NhZFhIc0Z6UFJaL2YwRnp5MnY4Y2MwQmNLWXpPUTZVWlBVSmc0d005?=
 =?utf-8?B?dkdPcU9WaklCVW1TaHdyVVRSZUJDcDJFMXJxL2xEa2JGWk5LRTMrS1dFbGxH?=
 =?utf-8?B?MGlhZjFXTlhzc0p6MUFuT3I4b2dFUEJhTlFCM0srRUZicW9hNEgzdldDWUdi?=
 =?utf-8?B?ZlFWMzBEOUJMQkJnTmFIbVJlZUhwTFJyTS9IekVoSTI1ZWJERWg2R2podjhy?=
 =?utf-8?B?M053YytlaDhWNzNsaVNmVUlQTlZYREdYSGl4WStmdklyazdPZXJhSnp4cmwv?=
 =?utf-8?B?TGtPejFPcGpRV1pCYjFWQm8veGxjWjA4QktBS1lTZVZiWmpTWUM0RDcwbzVH?=
 =?utf-8?B?YWtlMHNUcGNydXdtZ252eTBxMWFuYmFhYUNtRzNLYnMwWUxzNUdsaUlyNkZv?=
 =?utf-8?B?ZzhwRDR3TDRjSlp6RzB6WXdQaVB5amhQcjFMamhtd2s5UjVLYkRCTHA1amc3?=
 =?utf-8?B?bFZrNzFuZ1RudnE4cmFEMGRHODNPUHJIYThFTUNLSzZndmtXbHZTOHNXajZr?=
 =?utf-8?Q?e10S+f?=
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: 12 Jun 2025 09:30:13.5094
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: a348788f-8091-4d22-3fae-08dda993bc07
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:
	SJ1PEPF00001CDE.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR12MB5825

vpci_remove_register() only supports removing a register in a time,
but the follow-on changes need to remove all registers within a range.
So, refactor it to support removing all registers in a given region.

And it is no issue to remove a non exist register, so remove the
__must_check prefix.

Signed-off-by: Jiqian Chen 
Reviewed-by: Roger Pau Monné 
---
cc: "Roger Pau Monné" 
cc: Anthony PERARD 
---
v5->v6 changes:
* Modify commit message.
* Add Roger's Reviewed-by.

v4->v5 changes:
No.

v3->v4 changes:
* Use list_for_each_entry_safe instead of list_for_each_entry.
* Return ERANGE if overlap.

v2->v3 changes:
* Add new check to return error if registers overlap but not inside range.

v1->v2 changes:
new patch

Best regards,
Jiqian Chen.
---
 tools/tests/vpci/main.c |  4 ++--
 xen/drivers/vpci/vpci.c | 38 ++++++++++++++++++++------------------
 xen/include/xen/vpci.h  |  4 ++--
 3 files changed, 24 insertions(+), 22 deletions(-)

diff --git a/tools/tests/vpci/main.c b/tools/tests/vpci/main.c
index 33223db3eb77..ca72877d60cd 100644
--- a/tools/tests/vpci/main.c
+++ b/tools/tests/vpci/main.c
@@ -132,10 +132,10 @@ static void vpci_write32_mask(const struct pci_dev *pdev, unsigned int reg,
                                   rsvdz_mask))
 
 #define VPCI_REMOVE_REG(off, size)                                          \
-    assert(!vpci_remove_register(test_pdev.vpci, off, size))
+    assert(!vpci_remove_registers(test_pdev.vpci, off, size))
 
 #define VPCI_REMOVE_INVALID_REG(off, size)                                  \
-    assert(vpci_remove_register(test_pdev.vpci, off, size))
+    assert(vpci_remove_registers(test_pdev.vpci, off, size))
 
 /* Read a 32b register using all possible sizes. */
 void multiread4_check(unsigned int reg, uint32_t val)
diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
index 0c266dd6a265..cb5c03a82cf2 100644
--- a/xen/drivers/vpci/vpci.c
+++ b/xen/drivers/vpci/vpci.c
@@ -152,7 +152,7 @@ static int vpci_capability_hide(struct pci_dev *pdev, unsigned int cap)
 
     prev_r->private = next_r->private;
     /*
-     * Not calling vpci_remove_register() here is to avoid redoing
+     * Not calling vpci_remove_registers() here is to avoid redoing
      * the register search
      */
     list_del(&next_r->node);
@@ -160,7 +160,7 @@ static int vpci_capability_hide(struct pci_dev *pdev, unsigned int cap)
     xfree(next_r);
 
     if ( !is_hardware_domain(pdev->domain) )
-        return vpci_remove_register(vpci, offset + PCI_CAP_LIST_ID, 1);
+        return vpci_remove_registers(vpci, offset + PCI_CAP_LIST_ID, 1);
 
     return 0;
 }
@@ -552,34 +552,36 @@ int vpci_add_register_mask(struct vpci *vpci, vpci_read_t *read_handler,
     return 0;
 }
 
-int vpci_remove_register(struct vpci *vpci, unsigned int offset,
-                         unsigned int size)
+int vpci_remove_registers(struct vpci *vpci, unsigned int start,
+                          unsigned int size)
 {
-    const struct vpci_register r = { .offset = offset, .size = size };
-    struct vpci_register *rm;
+    struct vpci_register *rm, *tmp;
+    unsigned int end = start + size;
 
     spin_lock(&vpci->lock);
-    list_for_each_entry ( rm, &vpci->handlers, node )
+    list_for_each_entry_safe ( rm, tmp, &vpci->handlers, node )
     {
-        int cmp = vpci_register_cmp(&r, rm);
-
-        /*
-         * NB: do not use a switch so that we can use break to
-         * get out of the list loop earlier if required.
-         */
-        if ( !cmp && rm->offset == offset && rm->size == size )
+        /* Remove rm if rm is inside the range. */
+        if ( rm->offset >= start && rm->offset + rm->size <= end )
         {
             list_del(&rm->node);
-            spin_unlock(&vpci->lock);
             xfree(rm);
-            return 0;
+            continue;
         }
-        if ( cmp <= 0 )
+
+        /* Return error if registers overlap but not inside. */
+        if ( rm->offset + rm->size > start && rm->offset < end )
+        {
+            spin_unlock(&vpci->lock);
+            return -ERANGE;
+        }
+
+        if ( start < rm->offset )
             break;
     }
     spin_unlock(&vpci->lock);
 
-    return -ENOENT;
+    return 0;
 }
 
 /* Wrappers for performing reads/writes to the underlying hardware. */
diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
index 5da2cec9464a..1475019075c6 100644
--- a/xen/include/xen/vpci.h
+++ b/xen/include/xen/vpci.h
@@ -71,8 +71,8 @@ static inline int __must_check vpci_add_register(struct vpci *vpci,
                                   size, data, 0, 0, 0, 0);
 }
 
-int __must_check vpci_remove_register(struct vpci *vpci, unsigned int offset,
-                                      unsigned int size);
+int vpci_remove_registers(struct vpci *vpci, unsigned int start,
+                          unsigned int size);
 
 /* Generic read/write handlers for the PCI config space. */
 uint32_t vpci_read(pci_sbdf_t sbdf, unsigned int reg, unsigned int size);
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Jun 12 09:30:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 09:30:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012644.1391182 (Exim 4.92)
	(envelope-from )
	id 1uPeGQ-0001Dm-HA; Thu, 12 Jun 2025 09:30:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012644.1391182; Thu, 12 Jun 2025 09: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 1uPeGQ-0001DB-7F; Thu, 12 Jun 2025 09:30:26 +0000
Received: by outflank-mailman (input) for mailman id 1012644;
 Thu, 12 Jun 2025 09: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 1uPeGO-0008FN-K2
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 09:30:24 +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 dce9f171-476f-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 11:30:23 +0200 (CEST)
Received: from MW2PR16CA0060.namprd16.prod.outlook.com (2603:10b6:907:1::37)
 by PH7PR12MB6561.namprd12.prod.outlook.com (2603:10b6:510:213::12) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.35; Thu, 12 Jun
 2025 09:30:18 +0000
Received: from SJ1PEPF00001CDF.namprd05.prod.outlook.com
 (2603:10b6:907:1:cafe::8) by MW2PR16CA0060.outlook.office365.com
 (2603:10b6:907:1::37) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Thu,
 12 Jun 2025 09:30:18 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ1PEPF00001CDF.mail.protection.outlook.com (10.167.242.7) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Thu, 12 Jun 2025 09:30:18 +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 Jun
 2025 04:30:16 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: dce9f171-476f-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=gduMruJjmwDbdrjQRBeqsBfhLf0VnLMTzkD9LqDq0Xx4BJC4+MdZvIe4h65RmVLweUOTCwVbUA0lCTaCPgqeIzbHHNu0fL8rhkeY6w90HBD2bQerSSL1Xl5oyGN5C/tqSBpkNxCyyr4dm3XOBlybru6uyQKjq5g30a7ybkPoXX0feDEmCGCTY1SSakG4QLoMPwo/vlTE4ktsfpLNKUBHR9ZPo0Jsux3Lm357OGGwQkTmXeXmZYPckwgVBEFxmQ59DoGOVESYwg8QpWrGIUTanu8KQVAfRm/EYoqctVNcqHPEbNH/szRPs1tI8fGye9TNuDZu/atqZKzmAernhuoPEA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=XF1q4U46xvoiaeVV4plSO6XloONzJt5pNCKauR4m3Ug=;
 b=HM4RMtoZCNZy1eKB3dldXQB4jikkKFhdbm7V9X3vBcbqJ+8LaRNRdVeH0FoKVyAMWG5rdg4/xdzN3Yy8G9ZOJCAAYL31v03IxyMqsHkel2H5JPCpeTRwrfwjbdKsjHBEgf1gsq+ghe7tJp8T15/Ry5Lb43gVEy3Ap6gpjXv2cGzyl2wuPKnbVcOA37Ye1dfwJmHj9cQO8lMU9Vy9bpiu7n7SLW/cq2I9FQtnFoDml5pEx5pZ7VffqA3B/366emGAc2PpM4h11OVnnshAEL7GmuyOqUjxJjnbF7aYCS/43/Q0b9VLbKcVbIRtt1dKPTaybCyib3SPUvRmhnOxQ801bg==
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=XF1q4U46xvoiaeVV4plSO6XloONzJt5pNCKauR4m3Ug=;
 b=1x5AAT2Jc8vYzmfmP8jn4sfKoZq8Sw8cfAGq0xYq+gLIODhb6SHMyAmnsCrhvky4eqQHviv87ZPE1OlfatGBNT21P2JyRVKiUsLi2IFfImGvQrrTC9cofThxiU9nR26Gkc4e6WKzWfxtqTn4Pai37Sgeh09ISe+wd2TsMykKg4M=
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: Huang Rui , Jiqian Chen ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v6 8/8] vpci/msix: Free MSIX resources when init_msix() fails
Date: Thu, 12 Jun 2025 17:29:42 +0800
Message-ID: <20250612092942.1450344-9-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
References: <20250612092942.1450344-1-Jiqian.Chen@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: 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: SJ1PEPF00001CDF:EE_|PH7PR12MB6561:EE_
X-MS-Office365-Filtering-Correlation-Id: 429b3bdb-6d49-4a33-2796-08dda993bee7
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?aVkzN3M5bEF4NUNFRjBFL09Ja1k1Q3ZQcnY0L3VqYjFEVDQ5bUNzeU1peEw3?=
 =?utf-8?B?VjZyUGhnY2I4L0R2TUVXbHVyQmxhalBqMW1Fc2VSL1IyNEZZbHdSRitJTEkr?=
 =?utf-8?B?RkhYZ04ySnEwd1B2MURDY3Zqd1R2Ty9zQVVoYllTMXVKWk5Kd0NQaXlHdnk1?=
 =?utf-8?B?ZHVId3g3b1FsTjRlUzFhTUtNbzJtbXdPWmFFWGE4dWVqSXg4US9TWUxLdVNO?=
 =?utf-8?B?RHp5UGp6dzBGVU1CNmNaK2lncU1oNzY3U0dUaW9PeEE3Qkx0aHdJdFV6eEtM?=
 =?utf-8?B?Z1kvQWk5YjN2cG42eUN0Z1hrWWgzd0FKc1g0dUtOd3pQR1ZVMGxOS21YaDNq?=
 =?utf-8?B?aVBRSGRoS2FWZGtMMSs4ckcwS0N6ZVhuSFppZVg2WU16a3MxTzBVTTRSOHg1?=
 =?utf-8?B?NlIwWTJWcFd2UlUxZnk5ckJmV2o4eE5OY3p2dWltQ0ZiVTF6Kzh5RUcrZ3h1?=
 =?utf-8?B?MzQ0UE9lbjRZSldhZm44REFmQjdRUnpnRUQ3ZCtDVjgzSGphWW16Z1VrTWV0?=
 =?utf-8?B?VlNwWlRuQTcrWHFvdVFhQ1RtM3BIUWR6c2JaZzF4aHBBSk5ETmZnTkg5YTdz?=
 =?utf-8?B?MFEyU2FaWERxZUlXSTVxN0NiMVhnVHRlOTI1ckZlZUkvLytKc0s4WHgxOS9h?=
 =?utf-8?B?SW1mT1AxdW1GWGRxRld4YTZKbzdyd1hkdEJEY2JnR1I5WXBzcWJIMDdpYWJH?=
 =?utf-8?B?THRUMGJRRzZtYjFGMkQ5VGFGQUJ0bHVsa3NWSVBiaE03bml1dGl2VnFIMktq?=
 =?utf-8?B?N2N4aDgzTUJXTStCeGh6ZUUyVlcvN01QSXU4WC93MTFtWEtzdWdZYXZyVHIw?=
 =?utf-8?B?TVN5U3ZrVXpFSjRyVlJ6Z0ZPQXZOOUtHbWF2bFl1aXJJNFRDRnZ6dXVYVzlP?=
 =?utf-8?B?SENZODNkOGFYSXkxVHZBM1EydnVMd3NOZVBHbFFzSUd2TXhJOHJyU2NQK1o0?=
 =?utf-8?B?c1lmRG1FY25qVlRhVGZXc0djMjZ5RExCVk15VFhkZndXVGlJaFczTFpDL1hU?=
 =?utf-8?B?RkxuUmxQSkpmdTExOTNpbWFzRkxmVFlFb1FQeEp4MFBwekozRUNaVmkwTitU?=
 =?utf-8?B?dlFVV2xVaGhYZWN5R3ArQStLQ1FCOXQvQW8ydGFKVG5DUzZLdG9LamhnOUVK?=
 =?utf-8?B?ZEtadzJxVmRyZ2ROUlFJcjNkQzA2Nkk5RXB0dUFTLzRjUDlKOENBQjYrOU51?=
 =?utf-8?B?NzlKSkN3ckNwRkNsWVRjVnhUYi9FSTBhdGNLdU15RitWa1lNdDhnamN5UWR3?=
 =?utf-8?B?cGlGN0pGcmlzR2VlMitmVG5SdGROMnYrRWxsYTRCc0NpN3QyYXZ5ZG9HWmpK?=
 =?utf-8?B?WklFUW5McGkwVXpEMzVoUnAwQW9GR2hPZjdPYzROeEZ5dW5JUE5OR2NzRWxC?=
 =?utf-8?B?ZFlmTWJZaHlhT2w5Z1poYmhMRFN0cGhISGZnZGswc2dEM2lLQmVBN2xBSTNy?=
 =?utf-8?B?Y1pFT24wVFJ3dXRIUG5xQUhqMDk0cjVINndOTlBtUktqUVVQM0Zqa1d3TkNT?=
 =?utf-8?B?MnQ5VmJQWUFLcVQ1L2NPa1lXNXRueHZIK2JLQ3BBa1d6cDhwYUtzSkdFelJl?=
 =?utf-8?B?bHpRanJNTUlINjNReWVOQ2xRYmxpNC9tb1ZCZmYwUDRTbFJyZkRidDk2ODZm?=
 =?utf-8?B?VVc3WVVKQ0JsdHNmVStSVmc0MzZ0OXZmc3FNMWw4ckJXak16aFVDbWIvc2hy?=
 =?utf-8?B?U3pnSTBRWnVxUzVjaHd0dmNiNnpaYWtQTEdVRXZ1TmNEanVrcW95dUhBeXk2?=
 =?utf-8?B?SlRoaVRDdXJCd1o2TGpSUkZPMkRYTDVPanNMVHh1RnpjRTVkQVMzUERHRzQ1?=
 =?utf-8?B?Wld2TkI4REZmOXlUYkU2NVVrWVRGakIxSEZBaEx4b0NOZHdNM090aXpVQWxn?=
 =?utf-8?B?VDhkbDkxcCsvTjNOM1FMaHRPUUpNV0FmcGFlekJveW45Y3l3cnZXUTJFNjdm?=
 =?utf-8?B?V0xPUmtHN2lpYldhQUtJZzFjUStnSm83K0NkRU8xa2Z3d20zWFBBVFpqMlI1?=
 =?utf-8?B?MEtqcDc3eWwzZytNTkR2R3dNeEVhSVhPVE81bmlWTVdHZEJkeHNuc2N3Wkh3?=
 =?utf-8?Q?nYNKBz?=
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: 12 Jun 2025 09:30:18.3233
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 429b3bdb-6d49-4a33-2796-08dda993bee7
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:
	SJ1PEPF00001CDF.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6561

When init_msix() fails, current logic return fail and free MSIX-related
resources in vpci_deassign_device(). But the previous new changes will
hide MSIX capability and return success, it can't reach
vpci_deassign_device() to remove resources if hiding success, so those
resources must be removed in cleanup function of MSIX.

To do that, implement cleanup function for MSIX.

Signed-off-by: Jiqian Chen 
---
cc: "Roger Pau Monné" 
---
v5->v6 changes:
* Change the logic to add dummy handler when !vpci->msix in cleanup_msix().

v4->v5 changes:
* Change definition "static void cleanup_msix" to "static int cf_check cleanup_msix" since cleanup hook is changed to be int.
* Add a read-only register for MSIX Control Register in the end of cleanup_msix().

v3->v4 changes:
* Change function name from fini_msix() to cleanup_msix().
* Change to use XFREE to free vpci->msix.
* In cleanup function, change the sequence of check and remove action according to init_msix().

v2->v3 changes:
* Remove unnecessary clean operations in fini_msix().

v1->v2 changes:
new patch.

Best regards,
Jiqian Chen.
---
 xen/drivers/vpci/msix.c | 29 ++++++++++++++++++++++++++++-
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/vpci/msix.c b/xen/drivers/vpci/msix.c
index 674815ead025..da293e7494fd 100644
--- a/xen/drivers/vpci/msix.c
+++ b/xen/drivers/vpci/msix.c
@@ -655,6 +655,33 @@ int vpci_make_msix_hole(const struct pci_dev *pdev)
     return 0;
 }
 
+static int cf_check cleanup_msix(struct pci_dev *pdev)
+{
+    int rc;
+    struct vpci *vpci = pdev->vpci;
+    const unsigned int msix_pos = pdev->msix_pos;
+
+    if ( !msix_pos )
+        return 0;
+
+    rc = vpci_remove_registers(vpci, msix_control_reg(msix_pos), 2);
+    if ( rc )
+        return rc;
+
+    if ( vpci->msix )
+    {
+        for ( unsigned int i = 0; i < ARRAY_SIZE(vpci->msix->table); i++ )
+            if ( vpci->msix->table[i] )
+                iounmap(vpci->msix->table[i]);
+
+        list_del(&vpci->msix->next);
+        XFREE(vpci->msix);
+    }
+
+    return vpci_add_register(pdev->vpci, vpci_hw_read16, NULL,
+                             msix_control_reg(msix_pos), 2, NULL);
+}
+
 static int cf_check init_msix(struct pci_dev *pdev)
 {
     struct domain *d = pdev->domain;
@@ -709,7 +736,7 @@ static int cf_check init_msix(struct pci_dev *pdev)
 
     return rc;
 }
-REGISTER_VPCI_CAP(PCI_CAP_ID_MSIX, init_msix, NULL);
+REGISTER_VPCI_CAP(PCI_CAP_ID_MSIX, init_msix, cleanup_msix);
 
 /*
  * Local variables:
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Jun 12 09:36:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 09:36:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012682.1391204 (Exim 4.92)
	(envelope-from )
	id 1uPeM2-000528-2F; Thu, 12 Jun 2025 09:36:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012682.1391204; Thu, 12 Jun 2025 09: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 1uPeM1-000521-Vj; Thu, 12 Jun 2025 09:36:13 +0000
Received: by outflank-mailman (input) for mailman id 1012682;
 Thu, 12 Jun 2025 09: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 1uPeM0-00051v-B4
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 09:36:12 +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 ac39690d-4770-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 11:36:10 +0200 (CEST)
Received: from DU2P250CA0018.EURP250.PROD.OUTLOOK.COM (2603:10a6:10:231::23)
 by AS8PR08MB7369.eurprd08.prod.outlook.com (2603:10a6:20b:445::9) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.19; Thu, 12 Jun
 2025 09:36:06 +0000
Received: from DB5PEPF00014B92.eurprd02.prod.outlook.com
 (2603:10a6:10:231:cafe::10) by DU2P250CA0018.outlook.office365.com
 (2603:10a6:10:231::23) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.23 via Frontend Transport; Thu,
 12 Jun 2025 09:36:06 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 DB5PEPF00014B92.mail.protection.outlook.com (10.167.8.230) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.15
 via Frontend Transport; Thu, 12 Jun 2025 09:36:05 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com (2603:10a6:5:1c::25) by
 DU0PR08MB7947.eurprd08.prod.outlook.com (2603:10a6:10:3cb::20) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8835.19; Thu, 12 Jun 2025 09:35:31 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668]) by DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668%2]) with mapi id 15.20.8813.024; Thu, 12 Jun 2025
 09:35: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: ac39690d-4770-11f0-a309-13f23c93f187
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=sE74iQKNFmKp4QeCIHHkaKumBPffEBtGe+cq4BIuisITOsgIdeNy0Y+qQD8dzLUYH1bsnnTpQBrvhyuzpN8b9vDY8sk7ZP4KGqyj0kQhz5deV4fqvDCkI1DNnjF5EsOfRs3sWq3iGGc5QXcqHsNz6Qn9Tw/eVdd0vulenLOw4W2UI0H94W5TvnTQ6+/S+8y0PN2gOj4q8XCL0A5egJeHbR8ula4GThG1c1YieK7jb/EmmWCoST3/dMeo6LTlV7m0cJf4bNYPhUOw58ixfs/nwpc2d2l9IwTw0U8LkClZfdrZIrQOU8Daqur79Did1z/YO5WRBMgHGKIfV9/8PrDhvQ==
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=hlbuVXEhrs9MyyeX4BvQmIBKEboRfF+W/4hIcY4UHXw=;
 b=BhmhD3hzx+xHA3FXTmmdgwBaSgPuUaZgfwER2+x7duqLBnMQpEtQu1pmeN0/FS0zg5ipdunXqyYaNWgEAMq8YBluVRSbqlBNC+985QOjCoRy4QSOb9Nm7uoTpjsi9aDIVsTZKe7b38tH9mR9mLYlJFFnCvzsE30DyETWCLeL7FH1sQoARVGiCFatPDAK9UpYRCK0zfiAE7WVZW8QMSsF0MkAiojghCe5ZdUudD+EQTFujUM7r1hJMRwrIorqJ/XlTzavQDIaIpIx1m49hHtDFQ37xOqMssE0MQPcjg+nsQiA9eLWSTl0QHs83NUSQkAvPPrsuKSxaHQ8B+r0mBOjww==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=amd.com smtp.mailfrom=arm.com; dmarc=pass
 (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
 (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=hlbuVXEhrs9MyyeX4BvQmIBKEboRfF+W/4hIcY4UHXw=;
 b=Kf4Q7l4KXMVtrSrVXDDN9qneSHM4kVprqXfXzVcwSsHHbcR94/jIi3sZNhl/oVhghnb1JnKIrp1c96kzemvQhgBq7EHH2QxOiSEF5NoaSDW1Ci7WpTPyyY2b0YTqEQASdtbLtdMyWGw2QSpeBkrGQT3v4qaW0Y4XoTSfDAErkUw=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lFBR/iTdK1iKa6xB76Wdy3WajzQgrkI093r7JFYNwE4k7d/59YeqklaD89ggL8CcTeIYp4Jp6sagVt2DApk6yICZQhdCFcvKAMzxqV3qfs3ZbBfc7qm3X6KsjAZitrHzU8lGG4JKhBq3GfO6ZiaZ2HZkVBhLhafjfx9qU1MbMj5yckbf4seqWCPqxCyKd+W87I6mxH6MFFf0626H682HzP2dcmvGkuk9yT1w5zuKiVn/1K7lK9447rnb0yF6XRQlSvXaGyzRMRgs1ZN3ctOKy0H5oLckNjA+5hC/U4dLXX8mkaRNW03A818AbRdkt920n85r0Dqsk8Lz5PxiEJq00w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=hlbuVXEhrs9MyyeX4BvQmIBKEboRfF+W/4hIcY4UHXw=;
 b=UC6J5Ik+L+hhhoLXhFVaw4lsy1BKvVcHzIISGGCJEWYAIVSapDyXngT0Eyyk+2Z6ElCR/mpP4a5A3tTKQIBVB9Oadhi8EgruoctKtou+lqNM8Oac5V5jtXb0XGfVSLXkXHLvYfRv2e3p9//4ATdhaFHPf5ZoAnQqzth2zL+MsPM3nzWb1WtuIyV8q6Tjtyhwf4DYURD1suJ1fEVhHc/mkQNJjlONDqJe2d0dvantBKy2/VwHQdOmGQuB5HeY1SMrZE1FYC38cD3IvbAXSSSWxzy58h/4ohJfYdcwVBdVzochbiUZkXK1YLf9IjhbhAuErrX6SqOPDhH4c1GDXgJurg==
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=hlbuVXEhrs9MyyeX4BvQmIBKEboRfF+W/4hIcY4UHXw=;
 b=Kf4Q7l4KXMVtrSrVXDDN9qneSHM4kVprqXfXzVcwSsHHbcR94/jIi3sZNhl/oVhghnb1JnKIrp1c96kzemvQhgBq7EHH2QxOiSEF5NoaSDW1Ci7WpTPyyY2b0YTqEQASdtbLtdMyWGw2QSpeBkrGQT3v4qaW0Y4XoTSfDAErkUw=
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 v3 6/6] arm/mpu: Enable read/write to protection regions
 for arm32
Thread-Topic: [PATCH v3 6/6] arm/mpu: Enable read/write to protection regions
 for arm32
Thread-Index: AQHb2t7jddptbtJu60em4gEBgB1jlLP/RMoA
Date: Thu, 12 Jun 2025 09:35:30 +0000
Message-ID: <43768317-3409-46EA-B545-C78937EF42DC@arm.com>
References: <20250611143544.3453532-1-ayan.kumar.halder@amd.com>
 <20250611143544.3453532-7-ayan.kumar.halder@amd.com>
In-Reply-To: <20250611143544.3453532-7-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.600.51.1.1)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB7PR08MB2987:EE_|DU0PR08MB7947:EE_|DB5PEPF00014B92:EE_|AS8PR08MB7369:EE_
X-MS-Office365-Filtering-Correlation-Id: 04a3aac7-52c7-4a1b-4e4c-08dda9948d89
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|7053199007;
X-Microsoft-Antispam-Message-Info-Original:
 =?us-ascii?Q?rf29tfwWGL50eRg46BhfZ1Ba8Y0EJ8+9mGDAh0ookB88t4y8K/rgQ9gbIVGG?=
 =?us-ascii?Q?FT/0ia18Bgy8Q17z8SOPckPKPU5yUlrspDTIGJJR1cALxhOpY5hus0Dapzx+?=
 =?us-ascii?Q?79EtvB4Nlkfvr9azOSDE6fKzbaysQHLaFw+b3SLGJ+ECHdsae5h2xfJ11NfN?=
 =?us-ascii?Q?+RctAI5jLUUvXpPSN/3whCaaVePHWiTRWMCaHx+8jdIIImPw1nhUPMqx2yJA?=
 =?us-ascii?Q?73/qBDv52CTY69oGpb1bQvnoJaNlFVo7MnteIsZEUAeJjHgxWWBNKgnCkPXf?=
 =?us-ascii?Q?wrbfyoax3m3mxSMAJvHiRBIYO1d81s9pskLsI7nLIpcNVMTPNJbLs0EW3gA9?=
 =?us-ascii?Q?C3luVi7TdqMzMS1QAcQ5llVdT6aztJp2kx5wamSQVYvGwpj8Qy5MbJCeDC5K?=
 =?us-ascii?Q?3j78xlu8px1F35bjGju4GD+zfJv5GWEJiJwO1VmTaZRdxO0n0JxPMUhP6Fyx?=
 =?us-ascii?Q?GLHJDK7oWi5+aXwpBWuzhU7Qhgjs7rmcE6v7Vz7NVhfrHHLxB+pkH1F8vX7Z?=
 =?us-ascii?Q?CmbVliDPHnvwRGyJEFjnvtstAKlYW6umykuFGH6ne4kihHlQv5HoTTe7yFZL?=
 =?us-ascii?Q?+gBMyWbdCU2lcZEKTZqVbg5Ztl5ue2tpzqELCiKi9FoBdLoSBPJNw+O7STxH?=
 =?us-ascii?Q?Xt49BSHRLet7sGPsSa9EOEI561ptPtz1XCCM3iw5uxozjpl4snuju+W0mL8D?=
 =?us-ascii?Q?ZnzXbGDxaMvJGn4D4sEI5JolqsqeEb1ofe/6FX0byV2B3v4VapBWZcIEnWU3?=
 =?us-ascii?Q?yo1j+KyofGsTAp+/lRQbxb7FH/6xhE6+6BMWPG4Gx1AzTWCzzo6U7z3eEszW?=
 =?us-ascii?Q?u2nWO4QKSmeL2HmYT3OAHe3kgcovV+X6LgmBcbalAesPKjfANYA19SEAi/dO?=
 =?us-ascii?Q?PIZjOZz6vRnL279x7oZgwfQiNzp4m83WZupbVm8ZD9V29+OhubH5a8CnbqGZ?=
 =?us-ascii?Q?yn/ad6Np8MOFQHWrdCL20uq3tSoV9mELbXjGKfZc3bzSEomOlxIogiw9WqKr?=
 =?us-ascii?Q?cZofGGPD049fJ/fGp2cyQZHDpiMncfdAH9ZDpGyaZ08a3PQKBjgVBVOOX6MH?=
 =?us-ascii?Q?WALVoBAPw5dnU4TvbWSLXIz1KQB7qYA0MPgUKLrXzxPhYTFWetg9r5dDHXQ/?=
 =?us-ascii?Q?TmxPOXvhTDg8h6gQkeoJkpcPdTwyl0yLS5b2VCf6mLlDMZvsr28ou6vRbgyU?=
 =?us-ascii?Q?i9cKt3q8DtSUL5hg+anE9wjhu3URL+ZryckbPfE41nasBw0sYjfUewu7iBce?=
 =?us-ascii?Q?2F1F6b7gUj8XsnxmSmQupYyYULTDgGXSu4Y8e4mStVCWMAni2k2v+kCd9isy?=
 =?us-ascii?Q?P1wES98TSSiFVDyYpsD8iAbhWahKOVPWP7RtWqOAAhB8rbxwGqJ1J58asfsX?=
 =?us-ascii?Q?PQkm0KQjUqT/JbDFWTy+Pzw17zkzFuyz3Awp+8wAalfmZ776+MaMp5I1Swaq?=
 =?us-ascii?Q?c8EJw/HPTPSP05GoCG8eu6QaK8wdIsl0fGjDfQSJSGMPsZBJ6arX9idTVaxN?=
 =?us-ascii?Q?5X9scOLpFlbumZE=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB7PR08MB2987.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018)(7053199007);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8E34933B553EF7419FF8F8B1D5E879AC@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB7947
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DB5PEPF00014B92.eurprd02.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	e6fc931a-7135-40e2-66b4-08dda9947924
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|14060799003|82310400026|1800799024|35042699022|376014|36860700013|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?vzVaNv1k5y2jY0zNTJAfxxiYJwNzkbpNaxPeSsiUqBFmvCRnUSMbKApzgA9V?=
 =?us-ascii?Q?51ZODo5Nr6APO0KLIapLtiPdIzMSzE9CrMNd6hNg8ajpGUsEzF1caLWwQKLY?=
 =?us-ascii?Q?rP1VDMMwBVkTeDDWwjpzqMDs+q+UVFLKo+UbLdhuNdsAVhH8xpofcamQFx+n?=
 =?us-ascii?Q?yDPwoQaUK48CWQ2Zg/yEfrNmDWO9G1c313IE6kt0Ak/IFt2HVnyBSe6fXYKq?=
 =?us-ascii?Q?59mRM0ogBF32bmglaDq2X+S12ZpVFPc1Lw5PjDT/k4L9pnMaozxh8VSTFww8?=
 =?us-ascii?Q?e1FcRJtQFPQxYf+kGWR5nTEZ7Olx+Hp3zxmrXm07AXruA8ieBRAW2qH56ObI?=
 =?us-ascii?Q?thiBFA5jgpRVaeqLQXMES/L52Afm5a49tlx0xVo+NT3Tullwnys+21laJv8m?=
 =?us-ascii?Q?kIwglrJS8JoKqe+zUg+NA2CzG11Z/SFLkLQY/aaMsSZSGWEd2yPzKJRWepFL?=
 =?us-ascii?Q?IzIf1xhU+JoIel00zTwz1EJ4EkK04JrlvfxMTdksfdsQT0Eg0WhDu/4yQKCV?=
 =?us-ascii?Q?fW3FeNMbZYoK6GIcyVIVzRUgFJ3mDAWTfmSISljw4mEKQ3mvP7s4xl65nCOH?=
 =?us-ascii?Q?bPguYIcWNNzkrxoVu10AOEpq12TVkGYR+s9HB2UqNJHYjt1XA1e51ZQlBjJk?=
 =?us-ascii?Q?RvX9VeQkN8Lpelv5yQ8fmLL0VrNdNLIWaRR71h7QRycOTNEvRLI0SQVn2Zwz?=
 =?us-ascii?Q?Bl9/xoZocN2/D9P6GUc5PVtYfOHVNr5oG3XGltX7PTL82nhgtAbBJp0111xk?=
 =?us-ascii?Q?Q31vGlrmHLLM1iktu/Q5EpHC3KRwwc+mNl2OwduXvezZsPbUbO8rJkdKM2Gy?=
 =?us-ascii?Q?mzEhZ01RXuI2/p/rQVXE/LkW5mij9JBe9mVHtlOmJRdnqGrajU8SFhMjNGV+?=
 =?us-ascii?Q?DErYIwQAvs5IAzJa/1P03t+3w8rl7PiPXixBh7Z3ZlsbFiIHSbbJmzJ/BsM/?=
 =?us-ascii?Q?9OlMKkiJ1JTaCQWxWoVHZB6YRiXsjCFd3pg+wXuRXVcMDGxu4tMP6YkqXbPK?=
 =?us-ascii?Q?/NKqWpQzahrhTiYb0FjVBcGxgkOq5y2ddq7CKvO/N2XXhv4hg/FUXJLRFpkb?=
 =?us-ascii?Q?viCBt0+4xKs5O4Yytu7F+L8uHY0fF/S7A/7LqJf0l2r224obm5yMFVUa3lcN?=
 =?us-ascii?Q?uPgyfTPkIA+DCS3RYCcJdwFosgqvTMFtFNL+mz1PlsofHNfjKLqXvixiW2Vs?=
 =?us-ascii?Q?du98OEsZK3ed/UzCGKW/pa/j6lkXs738maXRScQBXkRMXwvrYcTr/9QYn2an?=
 =?us-ascii?Q?uLTTgk+HrkUUfjkdY65w6EsqAi8twufaTALg6w/EakFk8f0TaaBjRYl+t1dR?=
 =?us-ascii?Q?nlPxD7pViTdz3ryQklprmiZ0/CHl+ECWOQkhWU570A5jgKySL5YRJ9Q6szxn?=
 =?us-ascii?Q?Y7dD27I+l3eUKz0U57wVuvlWi/y180WnJZxnzEUbV5dMhshlUq30E1QiQbT3?=
 =?us-ascii?Q?0HdDw/kQjmWbA4LEvZ8APP4AxsHqJxs6VIo0ApSfUYZcxWTrwaqzslcP9YPk?=
 =?us-ascii?Q?dgpKkB5GeBbDjnNMi2vjNBrHPP1y282RPW1ya6grme6Doz+6eim+2mokmA?=
 =?us-ascii?Q?=3D=3D?=
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(14060799003)(82310400026)(1800799024)(35042699022)(376014)(36860700013)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2025 09:36:05.0337
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 04a3aac7-52c7-4a1b-4e4c-08dda9948d89
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DB5PEPF00014B92.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB7369

Hi Ayan,

> On 11 Jun 2025, at 15:35, Ayan Kumar Halder  w=
rote:
>=20
> Define prepare_selector(), read_protection_region() and
> write_protection_region() for arm32. Also, define
> GENERATE_{READ/WRITE}_PR_REG_OTHERS to access MPU regions from 32 to 255.
>=20
> Enable pr_{get/set}_{base/limit}(), region_is_valid() for arm32.
> Enable pr_of_addr() for arm32.
>=20
> Signed-off-by: Ayan Kumar Halder 
> ---

Based on your v2 (https://patchwork.kernel.org/project/xen-devel/patch/2025=
0606164854.1551148-4-ayan.kumar.halder@amd.com/) I was imaging something li=
ke this:

diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
index 74e96ca57137..5d324b2d4ca5 100644
--- a/xen/arch/arm/mpu/mm.c
+++ b/xen/arch/arm/mpu/mm.c
@@ -87,20 +87,28 @@ static void __init __maybe_unused build_assertions(void=
)
  */
 static void prepare_selector(uint8_t *sel)
 {
-#ifdef CONFIG_ARM_64
     uint8_t cur_sel =3D *sel;
=20
+#ifdef CONFIG_ARM_64
     /*
-     * {read,write}_protection_region works using the direct access to the=
 0..15
-     * regions, so in order to save the isb() overhead, change the PRSELR_=
EL2
-     * only when needed, so when the upper 4 bits of the selector will cha=
nge.
+     * {read,write}_protection_region works using the Arm64 direct access =
to the
+     * 0..15 regions, so in order to save the isb() overhead, change the
+     * PRSELR_EL2 only when needed, so when the upper 4 bits of the select=
or
+     * will change.
      */
     cur_sel &=3D 0xF0U;
+#else
+    /* Arm32 MPU can use direct access for 0-31 */
+    if ( cur_sel > 31 )
+        cur_sel =3D 0;
+#endif
     if ( READ_SYSREG(PRSELR_EL2) !=3D cur_sel )
     {
         WRITE_SYSREG(cur_sel, PRSELR_EL2);
         isb();
     }
+
+#ifdef CONFIG_ARM_64
     *sel =3D *sel & 0xFU;
 #endif
 }
@@ -144,6 +152,12 @@ void read_protection_region(pr_t *pr_read, uint8_t sel=
)
         GENERATE_READ_PR_REG_CASE(29, pr_read);
         GENERATE_READ_PR_REG_CASE(30, pr_read);
         GENERATE_READ_PR_REG_CASE(31, pr_read);
+        case 32 ... 255:
+        {
+            pr->prbar.bits =3D READ_SYSREG(PRBAR_EL2);
+            pr->prlar.bits =3D READ_SYSREG(PRLAR_EL2);
+            break;
+        }
 #endif
     default:
         BUG(); /* Can't happen */
@@ -190,6 +204,12 @@ void write_protection_region(const pr_t *pr_write, uin=
t8_t sel)
         GENERATE_WRITE_PR_REG_CASE(29, pr_write);
         GENERATE_WRITE_PR_REG_CASE(30, pr_write);
         GENERATE_WRITE_PR_REG_CASE(31, pr_write);
+        case 32 ... 255:
+        {
+            WRITE_SYSREG(pr->prbar.bits & ~MPU_REGION_RES0, PRBAR_EL2);
+            WRITE_SYSREG(pr->prlar.bits & ~MPU_REGION_RES0, PRLAR_EL2);
+            break;
+        }
 #endif
     default:
         BUG(); /* Can't happen */


Is it using too ifdefs in your opinion that would benefit the split you do =
in v3?




From xen-devel-bounces@lists.xenproject.org Thu Jun 12 09:43:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 09:43:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012714.1391213 (Exim 4.92)
	(envelope-from )
	id 1uPeTP-0007KP-SW; Thu, 12 Jun 2025 09:43:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012714.1391213; Thu, 12 Jun 2025 09:43: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 1uPeTP-0007KI-Pr; Thu, 12 Jun 2025 09:43:51 +0000
Received: by outflank-mailman (input) for mailman id 1012714;
 Thu, 12 Jun 2025 09:43: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 1uPeTO-0007KC-Sa
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 09:43:50 +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 be139a1c-4771-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 11:43:49 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3a3798794d3so829474f8f.1
 for ; Thu, 12 Jun 2025 02:43:49 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2364e706d7csm9791305ad.190.2025.06.12.02.43.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 02:43:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: be139a1c-4771-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749721429; x=1750326229; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=r82Bc6hEDA4FmTQLSbP9SNcLWdrlNLy3fOXKt2SKpXM=;
        b=aFyveRTjuizmPD+cE1uLuc75KTf+VCl8ndiDAGWaC4y83shKezuYzpjMP2Eqj0YDqE
         Q9fbmeVdlBmHaLtuQJc1Ydp2o4FhUjJtinjf4XFPegPQO5yPmQTc+U7NOVJCw24wvoz2
         RTCiFfpKGG6KVjvE+cdfXaTXIvDs6Ra6J0NMPm6typMqBP2zL+GjgssZgiPavWdNO29g
         d1/PNDqnOKwyseH6EUvqNQON8kc4WsX/GgOhTwfIFsGVlnKENsV/HI//GLP7Iz08B4GA
         /KUO3/KSd5EvoMOeP6PwFiN7guKuQQ8+y/zBNqrUI+JISDmitf2mqWT0/LLC/qGagvKL
         LY4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749721429; x=1750326229;
        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=r82Bc6hEDA4FmTQLSbP9SNcLWdrlNLy3fOXKt2SKpXM=;
        b=YbXaXWqFfEoF6cqSLnfOO9EsYt1rOzVKUPXlLOt9UdR2Yrl1TFBcQlHtjV30c6QGv0
         FzbUJof06Pl5c5Kp05JYBCthL8PMJzMmW+D7EJfrj3GDfwPo1p8mAmCN/peFY2OcGAHx
         9kchK162X5cGXNcLvz4TpHi1769+Er7+0A4+ILSgeac0rx1IrQOcL/I3rq4I+M+WVDkV
         VEXOts7ABOEIr8DDdwe32Iz4Ipdqq2e/uOyNr6h1CK/ousC5fBBPpnQ+L8txNKkQv7ci
         DPzkH9nnFql9sYrHJKSYeM9tPv11ZUZ8oPzC9yMgXVkKNn3+kI9xY6l+JE5Ap47bWU19
         MMRA==
X-Gm-Message-State: AOJu0YzVe2LFL+UjKr/N7dt8iCPsjshsCDQeFeEwZexBlGDH1tfndY+l
	awxg59LYQkd0tJWXdHanQ/Eq+ycQdcQLP4/cuGvwgVRae6Vme+EBRFhP3AYXe3RQyw==
X-Gm-Gg: ASbGncsxMAgiP2CfmD3+F/ADi53PwqRRn6907e2N2kcYcY+/QNnRmhmZLrbRVFMJYHm
	P2NqyNHVCWvbg1Sw8H81FjNrVz3Ev4GEaRNIoaD7+X/Bm9Tf9K4sghiY36Xhqp/hNJnRAwYX/NV
	UFUtsitBl2Wt6i9xcC+wMhB96w/dp4orVn7yDrEM/BDJLAxZOtLDNyd8LKHPmJq2zrQCJMh2eT7
	Q2RRldi7P1D8kC5vzFbtZVJ8RXVVx+IfgcXQB7Tx1N3j0I+UZ2vtrkE2PYHROfX9f70kvSipJ7r
	ccdoTjX3F/IYXHpF2+RAo4ZVT/d+xXEqCKSm2KDdX0TJBsIP6i9FqCt1ckt3nZO1MA2bbb9Zgoq
	Fm5w1NDEr4WA/msRfmgsFtb3SOBdhnixevpapzSmqesEDspg=
X-Google-Smtp-Source: AGHT+IGpJP0QUJbAJInA4NkGyw10yOd3Hd1icqD86ckGaBr10nycu5otnF51IqKPcxRjPp/d9E9g8Q==
X-Received: by 2002:a05:6000:1a8e:b0:3a4:f8e9:cef2 with SMTP id ffacd0b85a97d-3a5612db2admr2021951f8f.36.1749721428932;
        Thu, 12 Jun 2025 02:43:48 -0700 (PDT)
Message-ID: 
Date: Thu, 12 Jun 2025 11:43:36 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] docs: UEFI Secure Boot security policy
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 
Cc: Xen-devel ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , Juergen Gross
 , Trammell Hudson ,
 Ross Lagerwall ,
 Frediano Ziglio ,
 Gerald Elder-Vass ,
 Kevin Lampis ,
 Andrew Cooper 
References: <20250611235851.167385-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: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 12.06.2025 09:50, Marek Marczykowski-Górecki wrote:
> On Thu, Jun 12, 2025 at 12:58:51AM +0100, Andrew Cooper wrote:
>> Several things are hard to express and want further discussion.  Suggestions
>> welcome:
>>
>> 1) Content of CONFIG_CMDLINE and the various CONFIG_*_DEFAULT options.  Xen is
>> not going to be issuing XSAs for "downstream chose an unsafe configuration,
>> then signed and deployed the result", yet Xen probably should be on the hook
>> for bad "default ..." settings in Kconfig.
> 
> Should there be some guidelines what values are/aren't safe for UEFI SB?
> I don't think there can be a simple list, for example some things may
> depend on other settings and/or whether UKI is involved. But some
> comment about relation to UEFI SB (in Kconfig help?) would be useful.
> As for CONFIG_CMDLINE, IIUC the current implementation does cover it too
> (as in, lockdown mode will filter built-in cmdline too).

For command line options I think the doc ought to include some form of
annotation, at least in one direction (permitted or not permitted).

For Kconfig it's less clear to me what an "insecure default" could be.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 09:47:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 09:47:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012680.1391224 (Exim 4.92)
	(envelope-from )
	id 1uPeWa-0007tC-B8; Thu, 12 Jun 2025 09:47:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012680.1391224; Thu, 12 Jun 2025 09:47: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 1uPeWa-0007t5-7V; Thu, 12 Jun 2025 09:47:08 +0000
Received: by outflank-mailman (input) for mailman id 1012680;
 Thu, 12 Jun 2025 09:34:21 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uPeKC-0004ys-N0
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 09:34:21 +0000
Received: from smtpbgsg1.qq.com (smtpbgsg1.qq.com [54.254.200.92])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 66a75a74-4770-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 11:34:15 +0200 (CEST)
Received: from localhost.localdomain ( [localhost])
 by bizesmtp.qq.com (ESMTP) with 
 id ; Thu, 12 Jun 2025 17:32:32 +0800 (CST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 66a75a74-4770-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uniontech.com;
	s=onoh2408; t=1749720778;
	bh=2Zy4bFoBVzl6nVTabnVpris3XyN2VolT0oRORLqhxgY=;
	h=From:To:Subject:Date:Message-Id:MIME-Version;
	b=hIzHodQbcutpm2gNcg+OcD71g3rhgImRKTAYFbJzRwuC75kwBl/U4L5LMsxpUS8rx
	 aqV/FunUOxodAngcNEd0WeZauEEY376hcyA98y/1jsS20MZ6JGavlP5qNpc6jTLl6j
	 5mbyy/ZmmWfmHk3s1sq/Cp5uF0RJCEVe7CCuLxc4=
X-QQ-mid: zesmtpip3t1749720757t70730e88
X-QQ-Originating-IP: HKvLJGbgaUuK8EBFAWDgINtA/L8m3E0FzmVzL9pf2I0=
X-QQ-SSF: 0000000000000000000000000000000
X-QQ-GoodBg: 1
X-BIZMAIL-ID: 5791858325326469031
EX-QQ-RecipientCnt: 61
From: Zhenghan Cheng 
To: tglx@linutronix.de,
	mingo@redhat.com,
	bp@alien8.de,
	dave.hansen@linux.intel.com,
	x86@kernel.org,
	mario.limonciello@amd.com,
	yazen.ghannam@amd.com,
	jpoimboe@kernel.org,
	tony.luck@intel.com,
	jarkko@kernel.org,
	bhelgaas@google.com,
	pbonzini@redhat.com,
	oleg@redhat.com,
	jbaron@akamai.com,
	ning.sun@intel.com,
	seanjc@google.com,
	luto@kernel.org,
	andy@kernel.org,
	jim.cromie@gmail.com,
	kirill.shutemov@linux.intel.com
Cc: hpa@zytor.com,
	pawan.kumar.gupta@linux.intel.com,
	vkuznets@redhat.com,
	rostedt@goodmis.org,
	ardb@kernel.org,
	thomas.lendacky@amd.com,
	nikunj@amd.com,
	ashish.kalra@amd.com,
	kees@kernel.org,
	alexandre.chartre@oracle.com,
	rppt@kernel.org,
	chengzhenghan@uniontech.com,
	steve.wahl@hpe.com,
	jirislaby@kernel.org,
	apatel@ventanamicro.com,
	bvanassche@acm.org,
	ptsm@linux.microsoft.com,
	Jonathan.Cameron@huawei.com,
	beata.michalska@arm.com,
	xin@zytor.com,
	davydov-max@yandex-team.ru,
	ravi.bangoria@amd.com,
	joel.granados@kernel.org,
	ffmancera@riseup.net,
	kprateek.nayak@amd.com,
	akpm@linux-foundation.org,
	bhe@redhat.com,
	brgerst@gmail.com,
	coxu@redhat.com,
	dmaluka@chromium.org,
	linux-kernel@vger.kernel.org,
	linux-edac@vger.kernel.org,
	linux-sgx@vger.kernel.org,
	kvm@vger.kernel.org,
	virtualization@lists.linux.dev,
	tboot-devel@lists.sourceforge.net,
	nouveau@lists.freedesktop.org,
	linux-coco@lists.linux.dev,
	xen-devel@lists.xenproject.org,
	"Huacai Chen" ,
	Zhenghan Cheng 
Subject: [PATCH] x86: Fix build warnings about export.h
Date: Thu, 12 Jun 2025 17:32:28 +0800
Message-Id: <20250612093228.7655-1-chengzhenghan@uniontech.com>
X-Mailer: git-send-email 2.20.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-QQ-SENDSIZE: 520
Feedback-ID: zesmtpip:uniontech.com:qybglogicsvrgz:qybglogicsvrgz5a-1
X-QQ-XMAILINFO: ObQrVgrIW6qRQylutgWhCbGz8MqchjkXTG2rAC/C9B4GSBviv0m8bPNV
	EiIZJglbY6TnfbQoQvsofzKdybILucYU+iU6KeAJFZ1mkKSNpqNSKNiIizonjRuRfkWZ5pj
	D1uXTzHV8h6LdU/e7iqIevPFOOXWXhbGCgLKGWUuBU8imHV4Ji/Opk3BjJMIyw+QXm+//XD
	543syZeJ1GdAM/X6mYrQcYiif8N73OpsaULMx8Bd8/30qExOHxYKzpV6JH7ahNOeO1PngmI
	K9Db5f95mBfru4X1xCPieTy2oIhs1FVeGq07yvmueK4L2crF8u4gEyQqN3w3d28DxX+6Fyk
	7aHNC2SyJ3I2yz91q705ZXyYUYQsfxeWOkEM96EUxstu2F4SHGGUPfUs+b4TSS+plPjDkWw
	qwtwZjWBtA0xNJFZaNoxDqN9HKMNZ3KFAigDR/8oAWlJ35RS1JrtpY47rMCWwgpP4MgM7UB
	O+hfoOmHWJCni2p2yMi9JgkRacuTe07HUp504126RLY/7MmjHGW/92Rb4omivVa/mlvywU3
	mwSz7Wi/kWjTSVIf7peim0qaBbs55473hUymP0J3NLI1a8sB6J1/JEBAjxzujCyIslc4KZC
	aP3Bea6vkaK3mhQMXe5JVHZjY0mnZhcThdmphs1/xOFhWzquDdizpoImWxaaJ49F1WJbXah
	f5Y/mVGT/t7C3KXs8wkHF3QX6L7khIYKWGRJUmGfYBR/KhYkTm0lf7nYnCsKJ7xstswgMd4
	0JuqCAWyuD1KX43gVdRj6CD/qOX834GTrOynCu1Iq6JvBsVrvr2L1OUn97S/ZKQprCZgtKl
	ZTLrOXWxeghdth7MPxPs47MYOSIBErRYOBKHSbD5KwqUgGbgyMFvgvrEK/UpEWbmx2EsIqI
	vNOTN7Uwahj7lAC30t5YxWqGOvM+hWgeopZ44rn0foLm2PwE1nKrHj5pfsFxKn+bnI00BOO
	9BWwwywFcS5YWVPsTYwFTitdMreDwIYkgIVQYr6cMBKgIdwXaXBUg3b7cuda9l/lh8yH5gM
	1n/Krim1xaOTQHiISswogY/oZclpHl4X5Ah1jG13INIggg6nVm7xaSBtbvFfsKqCXaQ+rUt
	9ML199yNFbo
X-QQ-XMRINFO: NS+P29fieYNw95Bth2bWPxk=
X-QQ-RECHKSPAM: 0

After commit a934a57a42f64a4 ("scripts/misc-check:
check missing #include  when W=1")
and commit 7d95680d64ac8e836c ("scripts/misc-check:
check unnecessary #include  when W=1"),
we get some build warnings with W=1,such as:

arch/x86/coco/sev/core.c: warning: EXPORT_SYMBOL() is used, but #include  is missing
arch/x86/crypto/aria_aesni_avx2_glue.c: warning: EXPORT_SYMBOL() is used, but #include  is missing
arch/x86/kernel/unwind_orc.c: warning: EXPORT_SYMBOL() is used, but #include  is missing
arch/x86/kvm/hyperv.c: warning: EXPORT_SYMBOL() is used, but #include  is missing
arch/x86/events/intel/core.c: warning: EXPORT_SYMBOL() is not used, but #include  is present
arch/x86/events/zhaoxin/core.c: warning: EXPORT_SYMBOL() is not used, but #include  is present
arch/x86/kernel/crash.c: warning: EXPORT_SYMBOL() is not used, but #include  is present
arch/x86/kernel/devicetree.c: warning: EXPORT_SYMBOL() is not used, but #include  is present

so fix these build warnings for x86.

Signed-off-by: "Zhenghan Cheng" 
Suggested-by: "Huacai Chen" 

diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
index b6db4e0b936b..773b24859037 100644
--- a/arch/x86/coco/sev/core.c
+++ b/arch/x86/coco/sev/core.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 

diff --git a/arch/x86/crypto/aria_aesni_avx2_glue.c b/arch/x86/crypto/aria_aesni_avx2_glue.c
index b4bddcd58457..007b250f774c 100644
--- a/arch/x86/crypto/aria_aesni_avx2_glue.c
+++ b/arch/x86/crypto/aria_aesni_avx2_glue.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 

diff --git a/arch/x86/crypto/aria_aesni_avx_glue.c b/arch/x86/crypto/aria_aesni_avx_glue.c
index ab9b38d05332..4c88ef4eba82 100644
--- a/arch/x86/crypto/aria_aesni_avx_glue.c
+++ b/arch/x86/crypto/aria_aesni_avx_glue.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 

diff --git a/arch/x86/crypto/camellia_aesni_avx_glue.c b/arch/x86/crypto/camellia_aesni_avx_glue.c
index a7d162388142..5c321f255eb7 100644
--- a/arch/x86/crypto/camellia_aesni_avx_glue.c
+++ b/arch/x86/crypto/camellia_aesni_avx_glue.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 

diff --git a/arch/x86/crypto/camellia_glue.c b/arch/x86/crypto/camellia_glue.c
index 3bd37d664121..cbede120e5f2 100644
--- a/arch/x86/crypto/camellia_glue.c
+++ b/arch/x86/crypto/camellia_glue.c
@@ -10,6 +10,7 @@

 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/crypto/curve25519-x86_64.c b/arch/x86/crypto/curve25519-x86_64.c
index dcfc0de333de..86d4c4d85487 100644
--- a/arch/x86/crypto/curve25519-x86_64.c
+++ b/arch/x86/crypto/curve25519-x86_64.c
@@ -8,6 +8,7 @@
 #include 

 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/crypto/serpent_avx_glue.c b/arch/x86/crypto/serpent_avx_glue.c
index e640abc1cb8a..9c8b3a335d5c 100644
--- a/arch/x86/crypto/serpent_avx_glue.c
+++ b/arch/x86/crypto/serpent_avx_glue.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 

diff --git a/arch/x86/crypto/sm4_aesni_avx_glue.c b/arch/x86/crypto/sm4_aesni_avx_glue.c
index 72867fc49ce8..88caf418a06f 100644
--- a/arch/x86/crypto/sm4_aesni_avx_glue.c
+++ b/arch/x86/crypto/sm4_aesni_avx_glue.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/crypto/twofish_glue.c b/arch/x86/crypto/twofish_glue.c
index 4c67184dc573..8e9906d36902 100644
--- a/arch/x86/crypto/twofish_glue.c
+++ b/arch/x86/crypto/twofish_glue.c
@@ -40,6 +40,7 @@

 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/crypto/twofish_glue_3way.c b/arch/x86/crypto/twofish_glue_3way.c
index 1a1ecfa7f72a..8ad77725bf60 100644
--- a/arch/x86/crypto/twofish_glue_3way.c
+++ b/arch/x86/crypto/twofish_glue_3way.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 741b229f0718..04cf3d1019d9 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -12,7 +12,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 

diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c
index 7aa59966e7c3..10619c767602 100644
--- a/arch/x86/events/intel/lbr.c
+++ b/arch/x86/events/intel/lbr.c
@@ -1,5 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 #include 
+#include 
 #include 

 #include 
diff --git a/arch/x86/events/intel/pt.c b/arch/x86/events/intel/pt.c
index e8cf29d2b10c..9c772c89b623 100644
--- a/arch/x86/events/intel/pt.c
+++ b/arch/x86/events/intel/pt.c
@@ -17,6 +17,8 @@
 #include 
 #include 
 #include 
+#include 
+

 #include 
 #include 
diff --git a/arch/x86/events/zhaoxin/core.c b/arch/x86/events/zhaoxin/core.c
index 4bdfcf091200..67fa000cf372 100644
--- a/arch/x86/events/zhaoxin/core.c
+++ b/arch/x86/events/zhaoxin/core.c
@@ -9,7 +9,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 

 #include 
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 3d1d3547095a..3bd18521cd46 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/hyperv/irqdomain.c b/arch/x86/hyperv/irqdomain.c
index 31f0d29cbc5e..f7627bc8fe49 100644
--- a/arch/x86/hyperv/irqdomain.c
+++ b/arch/x86/hyperv/irqdomain.c
@@ -10,6 +10,7 @@

 #include 
 #include 
+#include 
 #include 

 static int hv_map_interrupt(union hv_device_id device_id, bool level,
diff --git a/arch/x86/hyperv/ivm.c b/arch/x86/hyperv/ivm.c
index e93a2f488ff7..d9c0b3064222 100644
--- a/arch/x86/hyperv/ivm.c
+++ b/arch/x86/hyperv/ivm.c
@@ -7,6 +7,7 @@
  */

 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/hyperv/nested.c b/arch/x86/hyperv/nested.c
index 1083dc8646f9..1413bfe40ea9 100644
--- a/arch/x86/hyperv/nested.c
+++ b/arch/x86/hyperv/nested.c
@@ -9,7 +9,7 @@
  */
 #define pr_fmt(fmt)  "Hyper-V: " fmt

-
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/acpi/cppc.c b/arch/x86/kernel/acpi/cppc.c
index 7047124490f6..e943947ccb3d 100644
--- a/arch/x86/kernel/acpi/cppc.c
+++ b/arch/x86/kernel/acpi/cppc.c
@@ -5,6 +5,7 @@
  */

 #include 
+#include 

 #include 
 #include 
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index ecfe7b497cad..882d99b1f4fb 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
diff --git a/arch/x86/kernel/amd_node.c b/arch/x86/kernel/amd_node.c
index a40176b62eb5..55118dd87116 100644
--- a/arch/x86/kernel/amd_node.c
+++ b/arch/x86/kernel/amd_node.c
@@ -9,6 +9,7 @@
  */

 #include 
+#include 
 #include 

 /*
diff --git a/arch/x86/kernel/apic/apic_common.c b/arch/x86/kernel/apic/apic_common.c
index 9ef3be866832..f7e1cbb70029 100644
--- a/arch/x86/kernel/apic/apic_common.c
+++ b/arch/x86/kernel/apic/apic_common.c
@@ -3,6 +3,7 @@
  *
  * SPDX-License-Identifier: GPL-2.0
  */
+#include 
 #include 
 #include 

diff --git a/arch/x86/kernel/apic/msi.c b/arch/x86/kernel/apic/msi.c
index 66bc5d3e79db..3f133e24a38e 100644
--- a/arch/x86/kernel/apic/msi.c
+++ b/arch/x86/kernel/apic/msi.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
index 93069b13d3af..f35c9184ac30 100644
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/cpu/acrn.c b/arch/x86/kernel/cpu/acrn.c
index 2c5b51aad91a..8f181da43b20 100644
--- a/arch/x86/kernel/cpu/acrn.c
+++ b/arch/x86/kernel/cpu/acrn.c
@@ -10,6 +10,7 @@
  */

 #include 
+#include 

 #include 
 #include 
diff --git a/arch/x86/kernel/cpu/aperfmperf.c b/arch/x86/kernel/cpu/aperfmperf.c
index a315b0627dfb..e441400106f8 100644
--- a/arch/x86/kernel/cpu/aperfmperf.c
+++ b/arch/x86/kernel/cpu/aperfmperf.c
@@ -8,6 +8,7 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 7f94e6a5497d..fd136016ff8f 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
diff --git a/arch/x86/kernel/cpu/bus_lock.c b/arch/x86/kernel/cpu/bus_lock.c
index 981f8b1f0792..68105db4dc66 100644
--- a/arch/x86/kernel/cpu/bus_lock.c
+++ b/arch/x86/kernel/cpu/bus_lock.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/cpu/mce/amd.c b/arch/x86/kernel/cpu/mce/amd.c
index 9d852c3b2cb5..9b335a939576 100644
--- a/arch/x86/kernel/cpu/mce/amd.c
+++ b/arch/x86/kernel/cpu/mce/amd.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/cpu/mce/dev-mcelog.c b/arch/x86/kernel/cpu/mce/dev-mcelog.c
index 8d023239ce18..4657fdb4810e 100644
--- a/arch/x86/kernel/cpu/mce/dev-mcelog.c
+++ b/arch/x86/kernel/cpu/mce/dev-mcelog.c
@@ -10,6 +10,7 @@
  */

 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/cpu/microcode/intel.c b/arch/x86/kernel/cpu/microcode/intel.c
index 371ca6eac00e..50b17579ca97 100644
--- a/arch/x86/kernel/cpu/microcode/intel.c
+++ b/arch/x86/kernel/cpu/microcode/intel.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/cpu/sgx/main.c b/arch/x86/kernel/cpu/sgx/main.c
index 2de01b379aa3..cb9eade755ee 100644
--- a/arch/x86/kernel/cpu/sgx/main.c
+++ b/arch/x86/kernel/cpu/sgx/main.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 /*  Copyright(c) 2016-20 Intel Corporation. */

+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/cpu/sgx/virt.c b/arch/x86/kernel/cpu/sgx/virt.c
index 7aaa3652e31d..15ce2a05c260 100644
--- a/arch/x86/kernel/cpu/sgx/virt.c
+++ b/arch/x86/kernel/cpu/sgx/virt.c
@@ -5,6 +5,7 @@
  * Copyright(c) 2021 Intel Corporation.
  */

+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/cpu/topology.c b/arch/x86/kernel/cpu/topology.c
index e35ccdc84910..30df9f9c4b0d 100644
--- a/arch/x86/kernel/cpu/topology.c
+++ b/arch/x86/kernel/cpu/topology.c
@@ -23,6 +23,7 @@
  */
 #define pr_fmt(fmt) "CPU topo: " fmt
 #include 
+#include 

 #include 

diff --git a/arch/x86/kernel/cpu/topology_common.c b/arch/x86/kernel/cpu/topology_common.c
index b5a5e1411469..fa841c8b70df 100644
--- a/arch/x86/kernel/cpu/topology_common.c
+++ b/arch/x86/kernel/cpu/topology_common.c
@@ -1,5 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 #include 
+#include 

 #include 

diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index bcb534688dfe..3dbabdfe9649 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -21,7 +21,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/devicetree.c b/arch/x86/kernel/devicetree.c
index dd8748c45529..2b72ca27eaac 100644
--- a/arch/x86/kernel/devicetree.c
+++ b/arch/x86/kernel/devicetree.c
@@ -3,7 +3,6 @@
  * Architecture specific OF callbacks.
  */
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/dumpstack_32.c b/arch/x86/kernel/dumpstack_32.c
index 722fd712e1cf..16f5a7984a46 100644
--- a/arch/x86/kernel/dumpstack_32.c
+++ b/arch/x86/kernel/dumpstack_32.c
@@ -9,7 +9,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/dumpstack_64.c b/arch/x86/kernel/dumpstack_64.c
index 6c5defd6569a..4975c5546ba9 100644
--- a/arch/x86/kernel/dumpstack_64.c
+++ b/arch/x86/kernel/dumpstack_64.c
@@ -9,7 +9,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index c3acbd26408b..9edbb4ebac31 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index 6b6f32f40cbe..097721a95a8d 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c
index ea138583dd92..2e4e37bf9d8f 100644
--- a/arch/x86/kernel/fpu/core.c
+++ b/arch/x86/kernel/fpu/core.c
@@ -17,6 +17,7 @@

 #include 

+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index 9aa9ac8399ae..6e1dcafc457d 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 533fcf5636fc..b58c6128554f 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
diff --git a/arch/x86/kernel/i8259.c b/arch/x86/kernel/i8259.c
index 2bade73f49e3..212f5e9959e1 100644
--- a/arch/x86/kernel/i8259.c
+++ b/arch/x86/kernel/i8259.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 921c1c783bc1..37a94e2a2d46 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/paravirt-spinlocks.c b/arch/x86/kernel/paravirt-spinlocks.c
index 9e1ea99ad9df..7f131a15ac9e 100644
--- a/arch/x86/kernel/paravirt-spinlocks.c
+++ b/arch/x86/kernel/paravirt-spinlocks.c
@@ -4,7 +4,6 @@
  * compiled in a FTRACE-compatible way.
  */
 #include 
-#include 
 #include 

 #include 
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index 095f04bdabdc..dfc8ebc8b0f8 100644
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 

diff --git a/arch/x86/kernel/pvclock.c b/arch/x86/kernel/pvclock.c
index b3f81379c2fc..96d944e26dbe 100644
--- a/arch/x86/kernel/pvclock.c
+++ b/arch/x86/kernel/pvclock.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
index a92f18db9610..221014f3d306 100644
--- a/arch/x86/kernel/quirks.c
+++ b/arch/x86/kernel/quirks.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index fb27be697128..ea43a022f9a8 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/stacktrace.c b/arch/x86/kernel/stacktrace.c
index ee117fcf46ed..ddce014f29b2 100644
--- a/arch/x86/kernel/stacktrace.c
+++ b/arch/x86/kernel/stacktrace.c
@@ -7,7 +7,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_call.c
index 378c388d1b31..3ab922966ab4 100644
--- a/arch/x86/kernel/static_call.c
+++ b/arch/x86/kernel/static_call.c
@@ -1,5 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/tboot.c b/arch/x86/kernel/tboot.c
index 46b8f1f16676..b6a1bb741ebd 100644
--- a/arch/x86/kernel/tboot.c
+++ b/arch/x86/kernel/tboot.c
@@ -8,7 +8,6 @@

 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index c5c897a86418..5a038f66271b 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/unwind_frame.c b/arch/x86/kernel/unwind_frame.c
index d8ba93778ae3..f3b893c0e5e7 100644
--- a/arch/x86/kernel/unwind_frame.c
+++ b/arch/x86/kernel/unwind_frame.c
@@ -3,6 +3,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/unwind_guess.c b/arch/x86/kernel/unwind_guess.c
index 884d68a6e714..86813ae9d57c 100644
--- a/arch/x86/kernel/unwind_guess.c
+++ b/arch/x86/kernel/unwind_guess.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0-only
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/unwind_orc.c b/arch/x86/kernel/unwind_orc.c
index 977ee75e047c..ec0cd3c54616 100644
--- a/arch/x86/kernel/unwind_orc.c
+++ b/arch/x86/kernel/unwind_orc.c
@@ -1,5 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0-only
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
index 24f0318c50d7..09f9de4555dd 100644
--- a/arch/x86/kvm/hyperv.c
+++ b/arch/x86/kvm/hyperv.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
diff --git a/arch/x86/kvm/ioapic.c b/arch/x86/kvm/ioapic.c
index 45dae2d5d2f1..bfa87e74fe18 100644
--- a/arch/x86/kvm/ioapic.c
+++ b/arch/x86/kvm/ioapic.c
@@ -36,7 +36,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kvm/kvm_onhyperv.c b/arch/x86/kvm/kvm_onhyperv.c
index ded0bd688c65..73a97e1dcdbd 100644
--- a/arch/x86/kvm/kvm_onhyperv.c
+++ b/arch/x86/kvm/kvm_onhyperv.c
@@ -4,6 +4,7 @@
  */
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

+#include 
 #include 
 #include 

diff --git a/arch/x86/kvm/mmu/page_track.c b/arch/x86/kvm/mmu/page_track.c
index 1b17b12393a8..2c407d7edd09 100644
--- a/arch/x86/kvm/mmu/page_track.c
+++ b/arch/x86/kvm/mmu/page_track.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "mmu.h"
 #include "mmu_internal.h"
diff --git a/arch/x86/kvm/mmu/spte.c b/arch/x86/kvm/mmu/spte.c
index cfce03d8f123..217a802e86f9 100644
--- a/arch/x86/kvm/mmu/spte.c
+++ b/arch/x86/kvm/mmu/spte.c
@@ -9,6 +9,7 @@
  */
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

+#include 
 #include 
 #include "mmu.h"
 #include "mmu_internal.h"
diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c
index 7f3d7229b2c1..1df1726f506c 100644
--- a/arch/x86/kvm/mmu/tdp_mmu.c
+++ b/arch/x86/kvm/mmu/tdp_mmu.c
@@ -8,6 +8,7 @@
 #include "tdp_mmu.h"
 #include "spte.h"

+#include 
 #include 
 #include 

diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
index 75e9cfc689f8..308a6ae502e3 100644
--- a/arch/x86/kvm/pmu.c
+++ b/arch/x86/kvm/pmu.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "x86.h"
diff --git a/arch/x86/kvm/smm.c b/arch/x86/kvm/smm.c
index 9864c057187d..4b13a6346f06 100644
--- a/arch/x86/kvm/smm.c
+++ b/arch/x86/kvm/smm.c
@@ -2,6 +2,7 @@
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

 #include 
+#include 
 #include "x86.h"
 #include "kvm_cache_regs.h"
 #include "kvm_emulate.h"
diff --git a/arch/x86/lib/atomic64_32.c b/arch/x86/lib/atomic64_32.c
index a0b4a350daa7..04a6901a8969 100644
--- a/arch/x86/lib/atomic64_32.c
+++ b/arch/x86/lib/atomic64_32.c
@@ -1,4 +1,3 @@
 #define ATOMIC64_EXPORT EXPORT_SYMBOL

-#include 
 #include 
diff --git a/arch/x86/lib/crc-t10dif.c b/arch/x86/lib/crc-t10dif.c
index db7ce59c31ac..c8c2108675cd 100644
--- a/arch/x86/lib/crc-t10dif.c
+++ b/arch/x86/lib/crc-t10dif.c
@@ -6,6 +6,7 @@
  */

 #include 
+#include 
 #include 
 #include "crc-pclmul-template.h"

diff --git a/arch/x86/lib/crc32.c b/arch/x86/lib/crc32.c
index d09343e2cea9..21e84e3c94eb 100644
--- a/arch/x86/lib/crc32.c
+++ b/arch/x86/lib/crc32.c
@@ -8,6 +8,7 @@
  */

 #include 
+#include 
 #include 
 #include "crc-pclmul-template.h"

diff --git a/arch/x86/lib/crc64.c b/arch/x86/lib/crc64.c
index 351a09f5813e..6c1a1beb5c97 100644
--- a/arch/x86/lib/crc64.c
+++ b/arch/x86/lib/crc64.c
@@ -6,6 +6,7 @@
  */

 #include 
+#include 
 #include 
 #include "crc-pclmul-template.h"

diff --git a/arch/x86/lib/crypto/blake2s-glue.c b/arch/x86/lib/crypto/blake2s-glue.c
index adc296cd17c9..e65cebbdc043 100644
--- a/arch/x86/lib/crypto/blake2s-glue.c
+++ b/arch/x86/lib/crypto/blake2s-glue.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/lib/crypto/chacha_glue.c b/arch/x86/lib/crypto/chacha_glue.c
index 10b2c945f541..7e3bf4b091f1 100644
--- a/arch/x86/lib/crypto/chacha_glue.c
+++ b/arch/x86/lib/crypto/chacha_glue.c
@@ -7,6 +7,7 @@

 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/lib/crypto/poly1305_glue.c b/arch/x86/lib/crypto/poly1305_glue.c
index b7e78a583e07..c2bc5b831551 100644
--- a/arch/x86/lib/crypto/poly1305_glue.c
+++ b/arch/x86/lib/crypto/poly1305_glue.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/lib/crypto/sha256.c b/arch/x86/lib/crypto/sha256.c
index 80380f8fdcee..46d5d174e821 100644
--- a/arch/x86/lib/crypto/sha256.c
+++ b/arch/x86/lib/crypto/sha256.c
@@ -6,6 +6,7 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/lib/iomem.c b/arch/x86/lib/iomem.c
index c20e04764edc..20f90c60e34e 100644
--- a/arch/x86/lib/iomem.c
+++ b/arch/x86/lib/iomem.c
@@ -1,5 +1,6 @@
 #include 
 #include 
+#include 
 #include 
 #include 

diff --git a/arch/x86/mm/cpu_entry_area.c b/arch/x86/mm/cpu_entry_area.c
index 575f863f3c75..2ffd4628643b 100644
--- a/arch/x86/mm/cpu_entry_area.c
+++ b/arch/x86/mm/cpu_entry_area.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index a4700ef6eb64..90df00f4ef88 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -9,6 +9,7 @@
  */

 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 7456df985d96..00c7088c5835 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index 607d6a2e66e2..633887c582af 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index ee66fae9ebcc..e3bd8adea411 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 12c8180ca1ba..4e2101e637ba 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 

diff --git a/arch/x86/mm/mem_encrypt_amd.c b/arch/x86/mm/mem_encrypt_amd.c
index faf3a13fb6ba..cb069276f756 100644
--- a/arch/x86/mm/mem_encrypt_amd.c
+++ b/arch/x86/mm/mem_encrypt_amd.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
diff --git a/arch/x86/mm/mmio-mod.c b/arch/x86/mm/mmio-mod.c
index c3317f0650d8..7555c0ef2cf3 100644
--- a/arch/x86/mm/mmio-mod.c
+++ b/arch/x86/mm/mmio-mod.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "pf_in.h"

diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index c24890c40138..5e3ac16ceea5 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
diff --git a/arch/x86/mm/pat/memtype.c b/arch/x86/mm/pat/memtype.c
index 2e7923844afe..3eeee5b2384a 100644
--- a/arch/x86/mm/pat/memtype.c
+++ b/arch/x86/mm/pat/memtype.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
index 46edc11726b7..89973d5e4327 100644
--- a/arch/x86/mm/pat/set_memory.c
+++ b/arch/x86/mm/pat/set_memory.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
index ddf248c3ee7d..92ee7b5cd93b 100644
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/mm/pgtable_32.c b/arch/x86/mm/pgtable_32.c
index c234634e26ba..2acb05736cf1 100644
--- a/arch/x86/mm/pgtable_32.c
+++ b/arch/x86/mm/pgtable_32.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
diff --git a/arch/x86/pci/pcbios.c b/arch/x86/pci/pcbios.c
index 244c643bb0b5..1956cb58e281 100644
--- a/arch/x86/pci/pcbios.c
+++ b/arch/x86/pci/pcbios.c
@@ -5,6 +5,7 @@

 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 463b784499a8..6288436d8ec3 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -35,7 +35,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index e7e8f77f77f8..627d084c344d 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -27,7 +27,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
index 553f330198f2..4119b2f693bc 100644
--- a/arch/x86/platform/efi/quirks.c
+++ b/arch/x86/platform/efi/quirks.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/platform/intel-mid/intel-mid.c b/arch/x86/platform/intel-mid/intel-mid.c
index a8e75f8c14fd..a877e52cb38e 100644
--- a/arch/x86/platform/intel-mid/intel-mid.c
+++ b/arch/x86/platform/intel-mid/intel-mid.c
@@ -15,7 +15,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 

 #include 
diff --git a/arch/x86/platform/intel-mid/pwr.c b/arch/x86/platform/intel-mid/pwr.c
index cd7e0c71adde..77c0ff63ee28 100644
--- a/arch/x86/platform/intel-mid/pwr.c
+++ b/arch/x86/platform/intel-mid/pwr.c
@@ -20,7 +20,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 

diff --git a/arch/x86/platform/intel-quark/imr.c b/arch/x86/platform/intel-quark/imr.c
index ee25b032c0b3..f97c11d3c1d2 100644
--- a/arch/x86/platform/intel-quark/imr.c
+++ b/arch/x86/platform/intel-quark/imr.c
@@ -32,6 +32,7 @@
 #include 

 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/platform/intel/iosf_mbi.c b/arch/x86/platform/intel/iosf_mbi.c
index 40ae94db20d8..49af88f1deda 100644
--- a/arch/x86/platform/intel/iosf_mbi.c
+++ b/arch/x86/platform/intel/iosf_mbi.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 

diff --git a/arch/x86/platform/scx200/scx200_32.c b/arch/x86/platform/scx200/scx200_32.c
index 80662b72035d..97386353b0f5 100644
--- a/arch/x86/platform/scx200/scx200_32.c
+++ b/arch/x86/platform/scx200/scx200_32.c
@@ -7,6 +7,7 @@

 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/video/video-common.c b/arch/x86/video/video-common.c
index 81fc97a2a837..57070d9e1a56 100644
--- a/arch/x86/video/video-common.c
+++ b/arch/x86/video/video-common.c
@@ -7,6 +7,7 @@
  *
  */

+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c
index 942372e69b4d..7cd06bb3aa9f 100644
--- a/arch/x86/virt/svm/sev.c
+++ b/arch/x86/virt/svm/sev.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c
index 2457d13c3f9e..e5bb81dc8497 100644
--- a/arch/x86/virt/vmx/tdx/tdx.c
+++ b/arch/x86/virt/vmx/tdx/tdx.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 53282dc7d5ac..4b2b038a1ec8 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -2,6 +2,7 @@

 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index fe57ff85d004..4399a1796861 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -2,6 +2,7 @@

 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index c4c479373249..da38470e6131 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0

 #include 
+#include 
 #include 
 #include 
 #include 

Signed-off-by: Zhenghan Cheng 
---
 arch/x86/coco/sev/core.c                  | 1 +
 arch/x86/crypto/aria_aesni_avx2_glue.c    | 1 +
 arch/x86/crypto/aria_aesni_avx_glue.c     | 1 +
 arch/x86/crypto/camellia_aesni_avx_glue.c | 1 +
 arch/x86/crypto/camellia_glue.c           | 1 +
 arch/x86/crypto/curve25519-x86_64.c       | 1 +
 arch/x86/crypto/serpent_avx_glue.c        | 1 +
 arch/x86/crypto/sm4_aesni_avx_glue.c      | 1 +
 arch/x86/crypto/twofish_glue.c            | 1 +
 arch/x86/crypto/twofish_glue_3way.c       | 1 +
 arch/x86/events/intel/core.c              | 1 -
 arch/x86/events/intel/lbr.c               | 1 +
 arch/x86/events/intel/pt.c                | 2 ++
 arch/x86/events/zhaoxin/core.c            | 1 -
 arch/x86/hyperv/hv_init.c                 | 1 +
 arch/x86/hyperv/irqdomain.c               | 1 +
 arch/x86/hyperv/ivm.c                     | 1 +
 arch/x86/hyperv/nested.c                  | 2 +-
 arch/x86/kernel/acpi/cppc.c               | 1 +
 arch/x86/kernel/alternative.c             | 1 +
 arch/x86/kernel/amd_node.c                | 1 +
 arch/x86/kernel/apic/apic_common.c        | 1 +
 arch/x86/kernel/apic/msi.c                | 1 +
 arch/x86/kernel/apic/vector.c             | 1 +
 arch/x86/kernel/cpu/acrn.c                | 1 +
 arch/x86/kernel/cpu/aperfmperf.c          | 1 +
 arch/x86/kernel/cpu/bugs.c                | 1 +
 arch/x86/kernel/cpu/bus_lock.c            | 1 +
 arch/x86/kernel/cpu/mce/amd.c             | 1 +
 arch/x86/kernel/cpu/mce/dev-mcelog.c      | 1 +
 arch/x86/kernel/cpu/microcode/intel.c     | 1 +
 arch/x86/kernel/cpu/sgx/main.c            | 1 +
 arch/x86/kernel/cpu/sgx/virt.c            | 1 +
 arch/x86/kernel/cpu/topology.c            | 1 +
 arch/x86/kernel/cpu/topology_common.c     | 1 +
 arch/x86/kernel/crash.c                   | 1 -
 arch/x86/kernel/devicetree.c              | 1 -
 arch/x86/kernel/dumpstack_32.c            | 1 -
 arch/x86/kernel/dumpstack_64.c            | 1 -
 arch/x86/kernel/e820.c                    | 1 +
 arch/x86/kernel/early-quirks.c            | 1 +
 arch/x86/kernel/fpu/core.c                | 1 +
 arch/x86/kernel/fpu/xstate.c              | 1 +
 arch/x86/kernel/head64.c                  | 1 +
 arch/x86/kernel/i8259.c                   | 1 +
 arch/x86/kernel/kvm.c                     | 1 +
 arch/x86/kernel/paravirt-spinlocks.c      | 1 -
 arch/x86/kernel/ptrace.c                  | 1 -
 arch/x86/kernel/pvclock.c                 | 1 +
 arch/x86/kernel/quirks.c                  | 1 +
 arch/x86/kernel/setup.c                   | 1 +
 arch/x86/kernel/stacktrace.c              | 1 -
 arch/x86/kernel/static_call.c             | 1 +
 arch/x86/kernel/tboot.c                   | 1 -
 arch/x86/kernel/traps.c                   | 1 -
 arch/x86/kernel/unwind_frame.c            | 1 +
 arch/x86/kernel/unwind_guess.c            | 1 +
 arch/x86/kernel/unwind_orc.c              | 1 +
 arch/x86/kvm/hyperv.c                     | 1 +
 arch/x86/kvm/ioapic.c                     | 1 -
 arch/x86/kvm/kvm_onhyperv.c               | 1 +
 arch/x86/kvm/mmu/page_track.c             | 1 +
 arch/x86/kvm/mmu/spte.c                   | 1 +
 arch/x86/kvm/mmu/tdp_mmu.c                | 1 +
 arch/x86/kvm/pmu.c                        | 1 +
 arch/x86/kvm/smm.c                        | 1 +
 arch/x86/lib/atomic64_32.c                | 1 -
 arch/x86/lib/crc-t10dif.c                 | 1 +
 arch/x86/lib/crc32.c                      | 1 +
 arch/x86/lib/crc64.c                      | 1 +
 arch/x86/lib/crypto/blake2s-glue.c        | 1 +
 arch/x86/lib/crypto/chacha_glue.c         | 1 +
 arch/x86/lib/crypto/poly1305_glue.c       | 1 +
 arch/x86/lib/crypto/sha256.c              | 1 +
 arch/x86/lib/iomem.c                      | 1 +
 arch/x86/mm/cpu_entry_area.c              | 1 +
 arch/x86/mm/dump_pagetables.c             | 1 +
 arch/x86/mm/init.c                        | 1 +
 arch/x86/mm/init_32.c                     | 1 +
 arch/x86/mm/init_64.c                     | 1 +
 arch/x86/mm/ioremap.c                     | 1 +
 arch/x86/mm/mem_encrypt_amd.c             | 1 +
 arch/x86/mm/mmio-mod.c                    | 1 +
 arch/x86/mm/numa.c                        | 1 +
 arch/x86/mm/pat/memtype.c                 | 1 +
 arch/x86/mm/pat/set_memory.c              | 1 +
 arch/x86/mm/pgtable.c                     | 1 +
 arch/x86/mm/pgtable_32.c                  | 1 +
 arch/x86/pci/pcbios.c                     | 1 +
 arch/x86/platform/efi/efi.c               | 1 -
 arch/x86/platform/efi/efi_64.c            | 1 -
 arch/x86/platform/efi/quirks.c            | 1 +
 arch/x86/platform/intel-mid/intel-mid.c   | 1 -
 arch/x86/platform/intel-mid/pwr.c         | 1 -
 arch/x86/platform/intel-quark/imr.c       | 1 +
 arch/x86/platform/intel/iosf_mbi.c        | 1 +
 arch/x86/platform/scx200/scx200_32.c      | 1 +
 arch/x86/video/video-common.c             | 1 +
 arch/x86/virt/svm/sev.c                   | 1 +
 arch/x86/virt/vmx/tdx/tdx.c               | 1 +
 arch/x86/xen/enlighten.c                  | 1 +
 arch/x86/xen/enlighten_hvm.c              | 1 +
 arch/x86/xen/mmu.c                        | 1 +
 103 files changed, 87 insertions(+), 18 deletions(-)

diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
index b6db4e0b936b..773b24859037 100644
--- a/arch/x86/coco/sev/core.c
+++ b/arch/x86/coco/sev/core.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/arch/x86/crypto/aria_aesni_avx2_glue.c b/arch/x86/crypto/aria_aesni_avx2_glue.c
index b4bddcd58457..007b250f774c 100644
--- a/arch/x86/crypto/aria_aesni_avx2_glue.c
+++ b/arch/x86/crypto/aria_aesni_avx2_glue.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/arch/x86/crypto/aria_aesni_avx_glue.c b/arch/x86/crypto/aria_aesni_avx_glue.c
index ab9b38d05332..4c88ef4eba82 100644
--- a/arch/x86/crypto/aria_aesni_avx_glue.c
+++ b/arch/x86/crypto/aria_aesni_avx_glue.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/arch/x86/crypto/camellia_aesni_avx_glue.c b/arch/x86/crypto/camellia_aesni_avx_glue.c
index a7d162388142..5c321f255eb7 100644
--- a/arch/x86/crypto/camellia_aesni_avx_glue.c
+++ b/arch/x86/crypto/camellia_aesni_avx_glue.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/arch/x86/crypto/camellia_glue.c b/arch/x86/crypto/camellia_glue.c
index 3bd37d664121..cbede120e5f2 100644
--- a/arch/x86/crypto/camellia_glue.c
+++ b/arch/x86/crypto/camellia_glue.c
@@ -10,6 +10,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/crypto/curve25519-x86_64.c b/arch/x86/crypto/curve25519-x86_64.c
index dcfc0de333de..86d4c4d85487 100644
--- a/arch/x86/crypto/curve25519-x86_64.c
+++ b/arch/x86/crypto/curve25519-x86_64.c
@@ -8,6 +8,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/crypto/serpent_avx_glue.c b/arch/x86/crypto/serpent_avx_glue.c
index e640abc1cb8a..9c8b3a335d5c 100644
--- a/arch/x86/crypto/serpent_avx_glue.c
+++ b/arch/x86/crypto/serpent_avx_glue.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/arch/x86/crypto/sm4_aesni_avx_glue.c b/arch/x86/crypto/sm4_aesni_avx_glue.c
index 72867fc49ce8..88caf418a06f 100644
--- a/arch/x86/crypto/sm4_aesni_avx_glue.c
+++ b/arch/x86/crypto/sm4_aesni_avx_glue.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/crypto/twofish_glue.c b/arch/x86/crypto/twofish_glue.c
index 4c67184dc573..8e9906d36902 100644
--- a/arch/x86/crypto/twofish_glue.c
+++ b/arch/x86/crypto/twofish_glue.c
@@ -40,6 +40,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/crypto/twofish_glue_3way.c b/arch/x86/crypto/twofish_glue_3way.c
index 1a1ecfa7f72a..8ad77725bf60 100644
--- a/arch/x86/crypto/twofish_glue_3way.c
+++ b/arch/x86/crypto/twofish_glue_3way.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 741b229f0718..04cf3d1019d9 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -12,7 +12,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c
index 7aa59966e7c3..10619c767602 100644
--- a/arch/x86/events/intel/lbr.c
+++ b/arch/x86/events/intel/lbr.c
@@ -1,5 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 #include 
+#include 
 #include 
 
 #include 
diff --git a/arch/x86/events/intel/pt.c b/arch/x86/events/intel/pt.c
index e8cf29d2b10c..9c772c89b623 100644
--- a/arch/x86/events/intel/pt.c
+++ b/arch/x86/events/intel/pt.c
@@ -17,6 +17,8 @@
 #include 
 #include 
 #include 
+#include 
+
 
 #include 
 #include 
diff --git a/arch/x86/events/zhaoxin/core.c b/arch/x86/events/zhaoxin/core.c
index 4bdfcf091200..67fa000cf372 100644
--- a/arch/x86/events/zhaoxin/core.c
+++ b/arch/x86/events/zhaoxin/core.c
@@ -9,7 +9,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 3d1d3547095a..3bd18521cd46 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/hyperv/irqdomain.c b/arch/x86/hyperv/irqdomain.c
index 31f0d29cbc5e..f7627bc8fe49 100644
--- a/arch/x86/hyperv/irqdomain.c
+++ b/arch/x86/hyperv/irqdomain.c
@@ -10,6 +10,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 static int hv_map_interrupt(union hv_device_id device_id, bool level,
diff --git a/arch/x86/hyperv/ivm.c b/arch/x86/hyperv/ivm.c
index e93a2f488ff7..d9c0b3064222 100644
--- a/arch/x86/hyperv/ivm.c
+++ b/arch/x86/hyperv/ivm.c
@@ -7,6 +7,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/hyperv/nested.c b/arch/x86/hyperv/nested.c
index 1083dc8646f9..1413bfe40ea9 100644
--- a/arch/x86/hyperv/nested.c
+++ b/arch/x86/hyperv/nested.c
@@ -9,7 +9,7 @@
  */
 #define pr_fmt(fmt)  "Hyper-V: " fmt
 
-
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/acpi/cppc.c b/arch/x86/kernel/acpi/cppc.c
index 7047124490f6..e943947ccb3d 100644
--- a/arch/x86/kernel/acpi/cppc.c
+++ b/arch/x86/kernel/acpi/cppc.c
@@ -5,6 +5,7 @@
  */
 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index ecfe7b497cad..882d99b1f4fb 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/arch/x86/kernel/amd_node.c b/arch/x86/kernel/amd_node.c
index a40176b62eb5..55118dd87116 100644
--- a/arch/x86/kernel/amd_node.c
+++ b/arch/x86/kernel/amd_node.c
@@ -9,6 +9,7 @@
  */
 
 #include 
+#include 
 #include 
 
 /*
diff --git a/arch/x86/kernel/apic/apic_common.c b/arch/x86/kernel/apic/apic_common.c
index 9ef3be866832..f7e1cbb70029 100644
--- a/arch/x86/kernel/apic/apic_common.c
+++ b/arch/x86/kernel/apic/apic_common.c
@@ -3,6 +3,7 @@
  *
  * SPDX-License-Identifier: GPL-2.0
  */
+#include 
 #include 
 #include 
 
diff --git a/arch/x86/kernel/apic/msi.c b/arch/x86/kernel/apic/msi.c
index 66bc5d3e79db..3f133e24a38e 100644
--- a/arch/x86/kernel/apic/msi.c
+++ b/arch/x86/kernel/apic/msi.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
index 93069b13d3af..f35c9184ac30 100644
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/cpu/acrn.c b/arch/x86/kernel/cpu/acrn.c
index 2c5b51aad91a..8f181da43b20 100644
--- a/arch/x86/kernel/cpu/acrn.c
+++ b/arch/x86/kernel/cpu/acrn.c
@@ -10,6 +10,7 @@
  */
 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/arch/x86/kernel/cpu/aperfmperf.c b/arch/x86/kernel/cpu/aperfmperf.c
index a315b0627dfb..e441400106f8 100644
--- a/arch/x86/kernel/cpu/aperfmperf.c
+++ b/arch/x86/kernel/cpu/aperfmperf.c
@@ -8,6 +8,7 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 7f94e6a5497d..fd136016ff8f 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/arch/x86/kernel/cpu/bus_lock.c b/arch/x86/kernel/cpu/bus_lock.c
index 981f8b1f0792..68105db4dc66 100644
--- a/arch/x86/kernel/cpu/bus_lock.c
+++ b/arch/x86/kernel/cpu/bus_lock.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/cpu/mce/amd.c b/arch/x86/kernel/cpu/mce/amd.c
index 9d852c3b2cb5..9b335a939576 100644
--- a/arch/x86/kernel/cpu/mce/amd.c
+++ b/arch/x86/kernel/cpu/mce/amd.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/cpu/mce/dev-mcelog.c b/arch/x86/kernel/cpu/mce/dev-mcelog.c
index 8d023239ce18..4657fdb4810e 100644
--- a/arch/x86/kernel/cpu/mce/dev-mcelog.c
+++ b/arch/x86/kernel/cpu/mce/dev-mcelog.c
@@ -10,6 +10,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/cpu/microcode/intel.c b/arch/x86/kernel/cpu/microcode/intel.c
index 371ca6eac00e..50b17579ca97 100644
--- a/arch/x86/kernel/cpu/microcode/intel.c
+++ b/arch/x86/kernel/cpu/microcode/intel.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/cpu/sgx/main.c b/arch/x86/kernel/cpu/sgx/main.c
index 2de01b379aa3..cb9eade755ee 100644
--- a/arch/x86/kernel/cpu/sgx/main.c
+++ b/arch/x86/kernel/cpu/sgx/main.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 /*  Copyright(c) 2016-20 Intel Corporation. */
 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/cpu/sgx/virt.c b/arch/x86/kernel/cpu/sgx/virt.c
index 7aaa3652e31d..15ce2a05c260 100644
--- a/arch/x86/kernel/cpu/sgx/virt.c
+++ b/arch/x86/kernel/cpu/sgx/virt.c
@@ -5,6 +5,7 @@
  * Copyright(c) 2021 Intel Corporation.
  */
 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/cpu/topology.c b/arch/x86/kernel/cpu/topology.c
index e35ccdc84910..30df9f9c4b0d 100644
--- a/arch/x86/kernel/cpu/topology.c
+++ b/arch/x86/kernel/cpu/topology.c
@@ -23,6 +23,7 @@
  */
 #define pr_fmt(fmt) "CPU topo: " fmt
 #include 
+#include 
 
 #include 
 
diff --git a/arch/x86/kernel/cpu/topology_common.c b/arch/x86/kernel/cpu/topology_common.c
index b5a5e1411469..fa841c8b70df 100644
--- a/arch/x86/kernel/cpu/topology_common.c
+++ b/arch/x86/kernel/cpu/topology_common.c
@@ -1,5 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 #include 
+#include 
 
 #include 
 
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index bcb534688dfe..3dbabdfe9649 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -21,7 +21,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/devicetree.c b/arch/x86/kernel/devicetree.c
index dd8748c45529..2b72ca27eaac 100644
--- a/arch/x86/kernel/devicetree.c
+++ b/arch/x86/kernel/devicetree.c
@@ -3,7 +3,6 @@
  * Architecture specific OF callbacks.
  */
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/dumpstack_32.c b/arch/x86/kernel/dumpstack_32.c
index 722fd712e1cf..16f5a7984a46 100644
--- a/arch/x86/kernel/dumpstack_32.c
+++ b/arch/x86/kernel/dumpstack_32.c
@@ -9,7 +9,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/dumpstack_64.c b/arch/x86/kernel/dumpstack_64.c
index 6c5defd6569a..4975c5546ba9 100644
--- a/arch/x86/kernel/dumpstack_64.c
+++ b/arch/x86/kernel/dumpstack_64.c
@@ -9,7 +9,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index c3acbd26408b..9edbb4ebac31 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index 6b6f32f40cbe..097721a95a8d 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c
index ea138583dd92..2e4e37bf9d8f 100644
--- a/arch/x86/kernel/fpu/core.c
+++ b/arch/x86/kernel/fpu/core.c
@@ -17,6 +17,7 @@
 
 #include 
 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index 9aa9ac8399ae..6e1dcafc457d 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 533fcf5636fc..b58c6128554f 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/arch/x86/kernel/i8259.c b/arch/x86/kernel/i8259.c
index 2bade73f49e3..212f5e9959e1 100644
--- a/arch/x86/kernel/i8259.c
+++ b/arch/x86/kernel/i8259.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 921c1c783bc1..37a94e2a2d46 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/paravirt-spinlocks.c b/arch/x86/kernel/paravirt-spinlocks.c
index 9e1ea99ad9df..7f131a15ac9e 100644
--- a/arch/x86/kernel/paravirt-spinlocks.c
+++ b/arch/x86/kernel/paravirt-spinlocks.c
@@ -4,7 +4,6 @@
  * compiled in a FTRACE-compatible way.
  */
 #include 
-#include 
 #include 
 
 #include 
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index 095f04bdabdc..dfc8ebc8b0f8 100644
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/arch/x86/kernel/pvclock.c b/arch/x86/kernel/pvclock.c
index b3f81379c2fc..96d944e26dbe 100644
--- a/arch/x86/kernel/pvclock.c
+++ b/arch/x86/kernel/pvclock.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
index a92f18db9610..221014f3d306 100644
--- a/arch/x86/kernel/quirks.c
+++ b/arch/x86/kernel/quirks.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index fb27be697128..ea43a022f9a8 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/stacktrace.c b/arch/x86/kernel/stacktrace.c
index ee117fcf46ed..ddce014f29b2 100644
--- a/arch/x86/kernel/stacktrace.c
+++ b/arch/x86/kernel/stacktrace.c
@@ -7,7 +7,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_call.c
index 378c388d1b31..3ab922966ab4 100644
--- a/arch/x86/kernel/static_call.c
+++ b/arch/x86/kernel/static_call.c
@@ -1,5 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/tboot.c b/arch/x86/kernel/tboot.c
index 46b8f1f16676..b6a1bb741ebd 100644
--- a/arch/x86/kernel/tboot.c
+++ b/arch/x86/kernel/tboot.c
@@ -8,7 +8,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index c5c897a86418..5a038f66271b 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/unwind_frame.c b/arch/x86/kernel/unwind_frame.c
index d8ba93778ae3..f3b893c0e5e7 100644
--- a/arch/x86/kernel/unwind_frame.c
+++ b/arch/x86/kernel/unwind_frame.c
@@ -3,6 +3,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/unwind_guess.c b/arch/x86/kernel/unwind_guess.c
index 884d68a6e714..86813ae9d57c 100644
--- a/arch/x86/kernel/unwind_guess.c
+++ b/arch/x86/kernel/unwind_guess.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0-only
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kernel/unwind_orc.c b/arch/x86/kernel/unwind_orc.c
index 977ee75e047c..ec0cd3c54616 100644
--- a/arch/x86/kernel/unwind_orc.c
+++ b/arch/x86/kernel/unwind_orc.c
@@ -1,5 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0-only
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
index 24f0318c50d7..09f9de4555dd 100644
--- a/arch/x86/kvm/hyperv.c
+++ b/arch/x86/kvm/hyperv.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/arch/x86/kvm/ioapic.c b/arch/x86/kvm/ioapic.c
index 45dae2d5d2f1..bfa87e74fe18 100644
--- a/arch/x86/kvm/ioapic.c
+++ b/arch/x86/kvm/ioapic.c
@@ -36,7 +36,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/kvm/kvm_onhyperv.c b/arch/x86/kvm/kvm_onhyperv.c
index ded0bd688c65..73a97e1dcdbd 100644
--- a/arch/x86/kvm/kvm_onhyperv.c
+++ b/arch/x86/kvm/kvm_onhyperv.c
@@ -4,6 +4,7 @@
  */
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
+#include 
 #include 
 #include 
 
diff --git a/arch/x86/kvm/mmu/page_track.c b/arch/x86/kvm/mmu/page_track.c
index 1b17b12393a8..2c407d7edd09 100644
--- a/arch/x86/kvm/mmu/page_track.c
+++ b/arch/x86/kvm/mmu/page_track.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "mmu.h"
 #include "mmu_internal.h"
diff --git a/arch/x86/kvm/mmu/spte.c b/arch/x86/kvm/mmu/spte.c
index cfce03d8f123..217a802e86f9 100644
--- a/arch/x86/kvm/mmu/spte.c
+++ b/arch/x86/kvm/mmu/spte.c
@@ -9,6 +9,7 @@
  */
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
+#include 
 #include 
 #include "mmu.h"
 #include "mmu_internal.h"
diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c
index 7f3d7229b2c1..1df1726f506c 100644
--- a/arch/x86/kvm/mmu/tdp_mmu.c
+++ b/arch/x86/kvm/mmu/tdp_mmu.c
@@ -8,6 +8,7 @@
 #include "tdp_mmu.h"
 #include "spte.h"
 
+#include 
 #include 
 #include 
 
diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
index 75e9cfc689f8..308a6ae502e3 100644
--- a/arch/x86/kvm/pmu.c
+++ b/arch/x86/kvm/pmu.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "x86.h"
diff --git a/arch/x86/kvm/smm.c b/arch/x86/kvm/smm.c
index 9864c057187d..4b13a6346f06 100644
--- a/arch/x86/kvm/smm.c
+++ b/arch/x86/kvm/smm.c
@@ -2,6 +2,7 @@
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
 #include 
+#include 
 #include "x86.h"
 #include "kvm_cache_regs.h"
 #include "kvm_emulate.h"
diff --git a/arch/x86/lib/atomic64_32.c b/arch/x86/lib/atomic64_32.c
index a0b4a350daa7..04a6901a8969 100644
--- a/arch/x86/lib/atomic64_32.c
+++ b/arch/x86/lib/atomic64_32.c
@@ -1,4 +1,3 @@
 #define ATOMIC64_EXPORT EXPORT_SYMBOL
 
-#include 
 #include 
diff --git a/arch/x86/lib/crc-t10dif.c b/arch/x86/lib/crc-t10dif.c
index db7ce59c31ac..c8c2108675cd 100644
--- a/arch/x86/lib/crc-t10dif.c
+++ b/arch/x86/lib/crc-t10dif.c
@@ -6,6 +6,7 @@
  */
 
 #include 
+#include 
 #include 
 #include "crc-pclmul-template.h"
 
diff --git a/arch/x86/lib/crc32.c b/arch/x86/lib/crc32.c
index d09343e2cea9..21e84e3c94eb 100644
--- a/arch/x86/lib/crc32.c
+++ b/arch/x86/lib/crc32.c
@@ -8,6 +8,7 @@
  */
 
 #include 
+#include 
 #include 
 #include "crc-pclmul-template.h"
 
diff --git a/arch/x86/lib/crc64.c b/arch/x86/lib/crc64.c
index 351a09f5813e..6c1a1beb5c97 100644
--- a/arch/x86/lib/crc64.c
+++ b/arch/x86/lib/crc64.c
@@ -6,6 +6,7 @@
  */
 
 #include 
+#include 
 #include 
 #include "crc-pclmul-template.h"
 
diff --git a/arch/x86/lib/crypto/blake2s-glue.c b/arch/x86/lib/crypto/blake2s-glue.c
index adc296cd17c9..e65cebbdc043 100644
--- a/arch/x86/lib/crypto/blake2s-glue.c
+++ b/arch/x86/lib/crypto/blake2s-glue.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/lib/crypto/chacha_glue.c b/arch/x86/lib/crypto/chacha_glue.c
index 10b2c945f541..7e3bf4b091f1 100644
--- a/arch/x86/lib/crypto/chacha_glue.c
+++ b/arch/x86/lib/crypto/chacha_glue.c
@@ -7,6 +7,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/lib/crypto/poly1305_glue.c b/arch/x86/lib/crypto/poly1305_glue.c
index b7e78a583e07..c2bc5b831551 100644
--- a/arch/x86/lib/crypto/poly1305_glue.c
+++ b/arch/x86/lib/crypto/poly1305_glue.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/lib/crypto/sha256.c b/arch/x86/lib/crypto/sha256.c
index 80380f8fdcee..46d5d174e821 100644
--- a/arch/x86/lib/crypto/sha256.c
+++ b/arch/x86/lib/crypto/sha256.c
@@ -6,6 +6,7 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/lib/iomem.c b/arch/x86/lib/iomem.c
index c20e04764edc..20f90c60e34e 100644
--- a/arch/x86/lib/iomem.c
+++ b/arch/x86/lib/iomem.c
@@ -1,5 +1,6 @@
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/arch/x86/mm/cpu_entry_area.c b/arch/x86/mm/cpu_entry_area.c
index 575f863f3c75..2ffd4628643b 100644
--- a/arch/x86/mm/cpu_entry_area.c
+++ b/arch/x86/mm/cpu_entry_area.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index a4700ef6eb64..90df00f4ef88 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -9,6 +9,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 7456df985d96..00c7088c5835 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index 607d6a2e66e2..633887c582af 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index ee66fae9ebcc..e3bd8adea411 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 12c8180ca1ba..4e2101e637ba 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/arch/x86/mm/mem_encrypt_amd.c b/arch/x86/mm/mem_encrypt_amd.c
index faf3a13fb6ba..cb069276f756 100644
--- a/arch/x86/mm/mem_encrypt_amd.c
+++ b/arch/x86/mm/mem_encrypt_amd.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/arch/x86/mm/mmio-mod.c b/arch/x86/mm/mmio-mod.c
index c3317f0650d8..7555c0ef2cf3 100644
--- a/arch/x86/mm/mmio-mod.c
+++ b/arch/x86/mm/mmio-mod.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "pf_in.h"
 
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index c24890c40138..5e3ac16ceea5 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/arch/x86/mm/pat/memtype.c b/arch/x86/mm/pat/memtype.c
index 2e7923844afe..3eeee5b2384a 100644
--- a/arch/x86/mm/pat/memtype.c
+++ b/arch/x86/mm/pat/memtype.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
index 46edc11726b7..89973d5e4327 100644
--- a/arch/x86/mm/pat/set_memory.c
+++ b/arch/x86/mm/pat/set_memory.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
index ddf248c3ee7d..92ee7b5cd93b 100644
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/mm/pgtable_32.c b/arch/x86/mm/pgtable_32.c
index c234634e26ba..2acb05736cf1 100644
--- a/arch/x86/mm/pgtable_32.c
+++ b/arch/x86/mm/pgtable_32.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/arch/x86/pci/pcbios.c b/arch/x86/pci/pcbios.c
index 244c643bb0b5..1956cb58e281 100644
--- a/arch/x86/pci/pcbios.c
+++ b/arch/x86/pci/pcbios.c
@@ -5,6 +5,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 463b784499a8..6288436d8ec3 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -35,7 +35,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index e7e8f77f77f8..627d084c344d 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -27,7 +27,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
index 553f330198f2..4119b2f693bc 100644
--- a/arch/x86/platform/efi/quirks.c
+++ b/arch/x86/platform/efi/quirks.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/platform/intel-mid/intel-mid.c b/arch/x86/platform/intel-mid/intel-mid.c
index a8e75f8c14fd..a877e52cb38e 100644
--- a/arch/x86/platform/intel-mid/intel-mid.c
+++ b/arch/x86/platform/intel-mid/intel-mid.c
@@ -15,7 +15,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
diff --git a/arch/x86/platform/intel-mid/pwr.c b/arch/x86/platform/intel-mid/pwr.c
index cd7e0c71adde..77c0ff63ee28 100644
--- a/arch/x86/platform/intel-mid/pwr.c
+++ b/arch/x86/platform/intel-mid/pwr.c
@@ -20,7 +20,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/arch/x86/platform/intel-quark/imr.c b/arch/x86/platform/intel-quark/imr.c
index ee25b032c0b3..f97c11d3c1d2 100644
--- a/arch/x86/platform/intel-quark/imr.c
+++ b/arch/x86/platform/intel-quark/imr.c
@@ -32,6 +32,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/platform/intel/iosf_mbi.c b/arch/x86/platform/intel/iosf_mbi.c
index 40ae94db20d8..49af88f1deda 100644
--- a/arch/x86/platform/intel/iosf_mbi.c
+++ b/arch/x86/platform/intel/iosf_mbi.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
diff --git a/arch/x86/platform/scx200/scx200_32.c b/arch/x86/platform/scx200/scx200_32.c
index 80662b72035d..97386353b0f5 100644
--- a/arch/x86/platform/scx200/scx200_32.c
+++ b/arch/x86/platform/scx200/scx200_32.c
@@ -7,6 +7,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/video/video-common.c b/arch/x86/video/video-common.c
index 81fc97a2a837..57070d9e1a56 100644
--- a/arch/x86/video/video-common.c
+++ b/arch/x86/video/video-common.c
@@ -7,6 +7,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c
index 942372e69b4d..7cd06bb3aa9f 100644
--- a/arch/x86/virt/svm/sev.c
+++ b/arch/x86/virt/svm/sev.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c
index 2457d13c3f9e..e5bb81dc8497 100644
--- a/arch/x86/virt/vmx/tdx/tdx.c
+++ b/arch/x86/virt/vmx/tdx/tdx.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 53282dc7d5ac..4b2b038a1ec8 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -2,6 +2,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index fe57ff85d004..4399a1796861 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -2,6 +2,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index c4c479373249..da38470e6131 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
2.20.1



From xen-devel-bounces@lists.xenproject.org Thu Jun 12 09:59:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 09:59:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012735.1391234 (Exim 4.92)
	(envelope-from )
	id 1uPeiB-0001j3-Gr; Thu, 12 Jun 2025 09:59:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012735.1391234; Thu, 12 Jun 2025 09: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 1uPeiB-0001iw-Dj; Thu, 12 Jun 2025 09:59:07 +0000
Received: by outflank-mailman (input) for mailman id 1012735;
 Thu, 12 Jun 2025 09:59: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 1uPeiA-0001iq-Rx
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 09:59:06 +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 e044f82c-4773-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 11:59:05 +0200 (CEST)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-607ea238c37so1742923a12.2
 for ; Thu, 12 Jun 2025 02:59:05 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6086b282444sm926267a12.79.2025.06.12.02.59.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 02:59:04 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e044f82c-4773-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749722345; x=1750327145; 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=pE7thbfTf4JDBTGcvLHnMOhVzJhWpgg9OYEAZW1xxok=;
        b=aZZPlzMFOTLIBndyBTaYi/SkyYeD6J0kD++NbWkslhf0wixpycaZs/cVJAG9DTSssi
         XNWgftvzI3Ri2adfMHf6Oz9JZIIvO42k+O3ZTAeggn4FUZuVOmZnWWOcKGBaTkhXVU2G
         a97FCp1Lw5qnBgI4qbqXyeVsUCG2q+VKKeuIaT4+YOg30y2Ox1JGfFZifCeNLCS/kiPC
         C7INnX4Q4+ngtaYLr9k9/esB6FA3hkYnSdUTRPtqATZKdrpZ/w5sNsB6MDr2ym8qxbXD
         ZoKR8IqZNTl/lukjiKvBG5w/ksMn43KFXpDUXE63nOuY/89vqoSxxiQhQNWvMzfnSXAL
         JOvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749722345; x=1750327145;
        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=pE7thbfTf4JDBTGcvLHnMOhVzJhWpgg9OYEAZW1xxok=;
        b=sFApCWKdM76JjirePM89yHEgeMya1/UynFbC44BoTHiLuQpKG5ytQ0Qv1y3Un/oKRU
         US6eEiRkTcDH2GJxGyn2SGTMrVIL1650ZkJn5J0wtZd8pZwOAhDl6gM3FrYwehEz8Ndw
         o0qH1w/oENyK8t0Kzz8/y8bKhau3X+wyqHrhTma7gJiPvuSe9CHYk5Y66fyp4zgF/rMz
         IbhR0T4v4iw8jo4Rg3BjkC9GyAxaQLcWMxYqxh/54N7nWKmL8c4+dxvXKjFClBzbgOET
         DY1hpng5MQmIdOhcO/QtSam16nJL4YWlKRfzuaLH0HVWZS2htATtaofy6rb3w04uvGeb
         OsPg==
X-Forwarded-Encrypted: i=1; AJvYcCXHsAv/WD1r/3d6ZqwD7gzSEgcy3JXLPUkCRhjILo16KS/TTvDibd2MBcATLEt9VmACQWHRSn8ukU8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxoMApeTtFeK/BOG/LL9rJwx5adiRBox0GaYniRMzbb8mZth+Mv
	79U5wt2Jq7zpe6ctjOQXhePKo8UHBEKsxLTwzK+/4jrKRgRI38yTR1POQ7nK/A==
X-Gm-Gg: ASbGncu2j2aETTEPY6yk3iv/YGu+WL2rtTZPCJ4sW5PzIpIsxtI3XZwYQUQcejU1cao
	r3E96n4rB057zexG2eL35VnH8BZsnlQMM/s6weMLlruFG05iRmuZS1OKr0yLrmNdXqlhZI7i24A
	IbGUta6T6AKIpVmcGzRIPX1eC9uGjZFdGMt5ITc12X3AgzYK1ZBAdAKrXhZ1OIiyQTGoImM+rTd
	P5NAbSyYenmyO30SSKA7q1GEI2dxD10Tfa6r8bay5f81pBOZV1rOHM611n+bsDOHnylRU0xeMEO
	ksINxpRrp9QEYf1l8w/h+2fonlSvtg8LpUU7CvT2N3X3uOFfFpnE6ic/unNmMUPuy8lfWsddGJp
	p0STQP7elxN30iNK5qk7k8PnA/Ha2pUE2CN4=
X-Google-Smtp-Source: AGHT+IHTrX0lC8T3PLaxz1sbkEaRBvG84qtG/QZ7wzGJNR4jLVc5anW3ulXgaYkfJsv+SqCJghr4/Q==
X-Received: by 2002:a05:6402:d09:b0:601:89d4:968e with SMTP id 4fb4d7f45d1cf-60846cafdefmr5653377a12.27.1749722344970;
        Thu, 12 Jun 2025 02:59:04 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------lc6NHlp8uUnShWRqjpJ1FlAl"
Message-ID: <087c943f-a65e-4ccb-9e3f-cd2a260a2d1b@gmail.com>
Date: Thu, 12 Jun 2025 11:59:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen: move declarations of device_tree_get_{reg,u32}() to
 xen/device_tree.h
To: "Orzel, Michal" , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250611114415.64480-1-oleksii.kurochko@gmail.com>
 <97cefe77-d876-489e-bd54-7a79d1209774@amd.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <97cefe77-d876-489e-bd54-7a79d1209774@amd.com>

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


On 6/11/25 1:53 PM, Orzel, Michal wrote:
>
> On 11/06/2025 13:44, Oleksii Kurochko wrote:
>> There is nothing Arm specific for these functions thereby it makes sense
>> to move their declarations to common header: xen/device_tree.h.
> I find it a bit odd that you don't mention that the definitions are already in
> common and therefore the prototypes should be too. For me that's the main reason
> (in fact the prototypes should have been moved together with definitions).

Initially I mentioned that they are used in common code:https://gitlab.com/xen-project/people/olkur/xen/-/commit/db46a683342421375c01a71317deb5a8840ae624
and by that I also mean that they are defined. But then decicded to re-write a commit
message.

I will send a v2 with updated commit message:
  The definitions of|device_tree_get_reg()| and|device_tree_get_u32()| are already in
  common code, so move their prototypes there as well.

>> Signed-off-by: Oleksii Kurochko
> Reviewed-by: Michal Orzel

Thanks.

~ Oleksii

>> ---
>>   xen/arch/arm/include/asm/setup.h | 6 ------
>>   xen/include/xen/device_tree.h    | 6 ++++++
>>   2 files changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
>> index 6cf272c160..2b58549c1a 100644
>> --- a/xen/arch/arm/include/asm/setup.h
>> +++ b/xen/arch/arm/include/asm/setup.h
>> @@ -53,12 +53,6 @@ void setup_mm(void);
>>   extern uint32_t hyp_traps_vector[];
>>   void init_traps(void);
>>   
>> -void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
>> -                         uint32_t size_cells, paddr_t *start, paddr_t *size);
>> -
>> -u32 device_tree_get_u32(const void *fdt, int node,
>> -                        const char *prop_name, u32 dflt);
>> -
>>   int handle_device(struct domain *d, struct dt_device_node *dev, p2m_type_t p2mt,
>>                     struct rangeset *iomem_ranges, struct rangeset *irq_ranges);
>>   
>> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
>> index 6dc1fb5159..75017e4266 100644
>> --- a/xen/include/xen/device_tree.h
>> +++ b/xen/include/xen/device_tree.h
>> @@ -949,6 +949,12 @@ int dt_get_pci_domain_nr(struct dt_device_node *node);
>>   
>>   struct dt_device_node *dt_find_node_by_phandle(dt_phandle handle);
>>   
>> +void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
>> +                         uint32_t size_cells, paddr_t *start, paddr_t *size);
>> +
>> +u32 device_tree_get_u32(const void *fdt, int node,
>> +                        const char *prop_name, u32 dflt);
>> +
>>   #ifdef CONFIG_DEVICE_TREE_DEBUG
>>   #define dt_dprintk(fmt, args...)  \
>>       printk(XENLOG_DEBUG fmt, ## args)
--------------lc6NHlp8uUnShWRqjpJ1FlAl
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    

    
    
    
    
    On 6/11/25 1:53 PM, Orzel, Michal
      wrote:
    
    
    
    
    
      
    
On 11/06/2025 13:44, Oleksii Kurochko wrote:

    
      
    
        
    There is nothing Arm specific for these functions thereby it makes sense
to move their declarations to common header: xen/device_tree.h.

    
      
    
      
    I find it a bit odd that you don't mention that the definitions are already in
common and therefore the prototypes should be too. For me that's the main reason
(in fact the prototypes should have been moved together with definitions).
    
    
    
    
    Initially I mentioned that they are used in common code: https://gitlab.com/xen-project/people/olkur/xen/-/commit/db46a683342421375c01a71317deb5a8840ae624
and by that I also mean that they are defined. But then decicded to re-write a commit
message.

I will send a v2 with updated commit message:
 The definitions of device_tree_get_reg() and device_tree_get_u32() are already in
 common code, so move their prototypes there as well.


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

    
      
    
      
    Reviewed-by: Michal Orzel <michal.orzel@amd.com>
    
    
    
    
    Thanks.

~ Oleksii

    
    
    
      
    
        
    ---
 xen/arch/arm/include/asm/setup.h | 6 ------
 xen/include/xen/device_tree.h    | 6 ++++++
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
index 6cf272c160..2b58549c1a 100644
--- a/xen/arch/arm/include/asm/setup.h
+++ b/xen/arch/arm/include/asm/setup.h
@@ -53,12 +53,6 @@ void setup_mm(void);
 extern uint32_t hyp_traps_vector[];
 void init_traps(void);
 
-void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
-                         uint32_t size_cells, paddr_t *start, paddr_t *size);
-
-u32 device_tree_get_u32(const void *fdt, int node,
-                        const char *prop_name, u32 dflt);
-
 int handle_device(struct domain *d, struct dt_device_node *dev, p2m_type_t p2mt,
                   struct rangeset *iomem_ranges, struct rangeset *irq_ranges);
 
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 6dc1fb5159..75017e4266 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -949,6 +949,12 @@ int dt_get_pci_domain_nr(struct dt_device_node *node);
 
 struct dt_device_node *dt_find_node_by_phandle(dt_phandle handle);
 
+void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
+                         uint32_t size_cells, paddr_t *start, paddr_t *size);
+
+u32 device_tree_get_u32(const void *fdt, int node,
+                        const char *prop_name, u32 dflt);
+
 #ifdef CONFIG_DEVICE_TREE_DEBUG
 #define dt_dprintk(fmt, args...)  \
     printk(XENLOG_DEBUG fmt, ## args)

    
      
    
      
    
    
    
  


--------------lc6NHlp8uUnShWRqjpJ1FlAl--


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 10:06:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 10:06:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012744.1391243 (Exim 4.92)
	(envelope-from )
	id 1uPep8-0003of-6j; Thu, 12 Jun 2025 10:06:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012744.1391243; Thu, 12 Jun 2025 10:06: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 1uPep8-0003oY-3z; Thu, 12 Jun 2025 10:06:18 +0000
Received: by outflank-mailman (input) for mailman id 1012744;
 Thu, 12 Jun 2025 10:06: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 1uPep6-0003oS-VP
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 10:06:16 +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 da8d255c-4774-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 12:06:05 +0200 (CEST)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-441ab63a415so7748955e9.3
 for ; Thu, 12 Jun 2025 03:06:14 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-313c1c5fd7esm1050475a91.37.2025.06.12.03.06.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 03:06:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: da8d255c-4774-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749722774; x=1750327574; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=4DyTLW2TAd5MFMWJ1jXtSh6zGkLFxgctzrhtPNP6aOw=;
        b=TSiEFrN/wXm0OaMp3qPrDyuLl6R2KUJI59kZOr4WBpvKNEV7PPopNHw4a9QPmb+X7d
         rA69JBJvPzidNv+kjHzI5ytRZoxAbYajoJ0IU05Xj/wdKYWS9PT2F+8yvzhg8tLpZmgP
         2C4hf7pmGt0/QbIas+YLU6hYtCFN5ZZX+MNVERxeI+Yczqnk63YWfdvBgtrIWzJjgXEm
         ADKV2EDqOAm037d4Zcoc0JRTcCVM+x21mCOGQ27nPp+ZmwDfg+ovQf2npEOxuD6KkGta
         RmEvlH5SBBXX05i51tcQVXVUNLxRVTBLSdH+qxsZI7RROLLeTj6Nhclml9DjX9Uom30h
         1fQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749722774; x=1750327574;
        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=4DyTLW2TAd5MFMWJ1jXtSh6zGkLFxgctzrhtPNP6aOw=;
        b=r/SMApwZLCJdcZVwq5f5SvfRKUq3FOTPAp49wc38xhBOfuP5S6vHueVa+lXKR5Ph5P
         yhFdUte+/i6bhu6MUAPwjQzClqQM9KdNcjdj7ESGl1QhFbNNVmiNxhLV3uExRms8xT5c
         zjqBS4Ef+cEX+iT99d0MDZKBOnA/mCjIokyoNrrODbRHu1n3RWQlzRos/6d7ToTLCRRw
         g7wp1lmroERVOk2WL+Gy7vPHrm6QMkMr4RzeBdPjwhKbFShANC9gMWsqxmoIuU2ZgSBe
         jbnu+H/XcgIrmFC3GQ52pk6UpE8b2sM2uOsEPZae2X1C5aOSpZA7mgKH/pblgnNpxCxT
         du9g==
X-Forwarded-Encrypted: i=1; AJvYcCWSdWVd5I36iwdiHdxW9mr/8DbAVZyET2jzn+H18YCQiZdlsOlCN9pDxl7sOuYzH8vfBlJuz4VtnKU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwRJpr3zAp9Js7fZvF+zPXb/oPVq1+7ryTspGM7l+y9y0pLX2N5
	dLkJs8XUg2qPhV7j3/9Ak0uEPM92vg7OQCij/L60TJFifQe9bsqSA72Eklulsbmuqw==
X-Gm-Gg: ASbGncsKOm+omqndIPceE7hkkW1t78y5QNmV65jM/d8MPPtDE+yjDmYAg6hWCOaix9R
	+Ata394catABO+3grcbb3FImpnC/99vQgXpgdG7fBdvogSr8kO9KRy8DAPMx5RYj/4bIQv14Lgx
	s9Kv95/jR+wUL+SChIdn0YmkUG831Tu5UL5KHTe8v6TozHQtTmEZsmDDWJ62StHqCLzhwdegvLV
	BYSI6czbixifkhFnyGKF8QKshkaXiqgArKRIGiXro9pur0KlbV+vvjiocq71qxYOvW42WInaSLl
	1D32IcD8r4M+lDM6kE0WqPgrcmWoB91XZB+C8QoP4gHUfkoyAJN1Uc2GzUgX0BlM7vU67q3HQl4
	HqFkkB/hSFaJrXLNFx7GW1Kjve9OV1nxTExUe58atM13H27g=
X-Google-Smtp-Source: AGHT+IGpodWvKnVXUDs0/XXkjLihdGLd8F2E7N+fA6LekM59CPgXhB/fEvPtQllGPCpWM7YcwsvlRg==
X-Received: by 2002:a05:6000:2313:b0:3a4:ee51:8144 with SMTP id ffacd0b85a97d-3a5586f21d8mr5934651f8f.13.1749722773690;
        Thu, 12 Jun 2025 03:06:13 -0700 (PDT)
Message-ID: <5aad2d39-31e1-44c6-b167-a3275dc6b747@suse.com>
Date: Thu, 12 Jun 2025 12:06:01 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] docs: UEFI Secure Boot security policy
To: Andrew Cooper 
Cc: Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , Juergen Gross
 ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , Trammell Hudson ,
 Ross Lagerwall ,
 Frediano Ziglio ,
 Gerald Elder-Vass ,
 Kevin Lampis ,
 Xen-devel 
References: <20250611235851.167385-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: <20250611235851.167385-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12.06.2025 01:58, Andrew Cooper wrote:
> Obviously RFC at this point.  It's worth saying that XenServer is intending to
> use Shim and get a signature from Microsoft, retaining all exiting features
> such as Livepatching and Kexec crash reporting.
> 
> This trails off into more TODOs towards the end.  Individual tasks should
> expand on the start made and resulting conversation from this thread.  As a
> reminder, the target audience for this doc is an administrator running a Xen
> deployment, but who is not necesserily a developer.
> 
> Several things are hard to express and want further discussion.  Suggestions
> welcome:
> 
> 1) Content of CONFIG_CMDLINE and the various CONFIG_*_DEFAULT options.  Xen is
> not going to be issuing XSAs for "downstream chose an unsafe configuration,
> then signed and deployed the result", yet Xen probably should be on the hook
> for bad "default ..." settings in Kconfig.

Imo it simply needs stating largely like this. As indicated by Marek, some
annotations are going to be needed to help people realize what is or is not
safe to use. If we wrongly marked a command line option (or Kconfig setting,
if applicable there) as safe to use, I think we'd be on the hook to issue an
XSN or XSA.

> 2) Pre-boot DMA Protection.  Microsoft consider this a platform feature
> requiring OEM enablement, and do not consider its absence to be a Secure Boot
> vulnerability.  But, it is less clear what the policy ought to be for Xen
> booting on a capable system and failing to do a correct live-handover of the
> IOMMU across ExitBootServices().

Shouldn't this be another TODO item at the bottom? We don't support yet taking
over when the IOMMUs are already enabled, do we?

> 3) The AMD microcode signature vulnerability.  While it's not Xen's bug per
> say, it's clearly a Secure Boot bypass because we do offer microcode loading
> capabilties to userspace, and malicious userspace can load an unauthorised
> microcode which allows them to read/write physical memory and bypass further
> signature checks.

While in general I continue to think that people ought to be paying attention
to advisories from HW vendors, we can certainly continue to issue at least
XSNs in such events.

> 4) Userspace Hypercalls.  To anyone who isn't already aware, /dev/xen/privcmd
> in the various Unicies is a giant priv-esc hole, as root userspace can
> e.g. issue direct memory hypercalls behind the back of an (intentionally)
> oblivious kernel, and cannot be handwaved away as "it's fine because it's
> root" under Secure Boot.  It's not a Xen vuln (Xen *does* audit pointers in
> guest hypercalls), but it is a guest kernel vuln because of failing to
> correctly audit hypercall parameters.  However, it does require substantial
> changes in Xen in order to allow guest kernels to do something half-way safe.

I'm having trouble seeing what's "hard to express" here. Auditing needs to be
added in kernels wanting to act as hwdom or ctldom. Flaws there would
require advisories (and revocation) by respective parties; for Linux that
would still be the Xen Security Team.

IOW imo this wording could just move down to the respective sub-item of the
TODO section.

> +Principles
> +^^^^^^^^^^
> +
> + * Privileged code shall include Xen and the kernel(s) of the control and
> +   hardware domain (both, if they're split).  While there is a privilege split
> +   here in Xen's regular security model, they are equal from Secure Boot's
> +   point of view.

In this context, may I direct your attention to Jason's plans for Xenstore
domain? It, in the SILO model, being permitted interaction with the other
two special types might end up being a problem here.

See https://lists.xen.org/archives/html/xen-devel/2025-06/msg00703.html.

> +In Progress
> +-----------
> +
> +.. warning::
> +
> +   The following work is still in progress.  It is provisional, and not
> +   security supported yet.

Isn't this an overstatement? None of the below had even parts thereof go
in so far.

> +Secure Boot Advanced Targeting
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +SBAT is a recovation scheme for Secure Boot enabled components, using a
> +generation based scheme.  See `Shim SBAT.md
> +`_ for full details.
> +
> +Upstream Xen provides the infrastructure to embed SBAT metadata in
> +``xen.efi``, but does not maintain a generation number itself.  Downstreams
> +are expected to maintain their own generation numbers.
> +
> +
> +Lockdown Mode
> +^^^^^^^^^^^^^
> +
> +A mode which causes the enforcement of the properties necessary to conform to
> +the Secure Boot specification.  Lockdown Mode is forced active when Secure
> +Boot is active in the platform, but may be activated independently too for
> +development purposes with the ``lockdown`` command line option.
> +
> +TODO
> +^^^^
> +
> + * Command Line
> + * Livepatching
> + * Kexec
> + * Userspace hypercalls

What about Dom0 being able to access almost(?) all memory, including all MMIO?
In this context, isn't iommu=dom0-strict a requirement for SB (while that's
still not the default mode of operation for PV Dom0, despite me keeping to
suggest that we ought to change that default)?

As a general remark (no good place to put it): In the eventual final patch I
expect a reference to this new doc is going to be inserted in the respective
section in SUPPORT.md.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 10:07:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 10:07:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012750.1391254 (Exim 4.92)
	(envelope-from )
	id 1uPeq3-0004Ha-Fi; Thu, 12 Jun 2025 10:07:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012750.1391254; Thu, 12 Jun 2025 10:07:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPeq3-0004HT-CG; Thu, 12 Jun 2025 10:07:15 +0000
Received: by outflank-mailman (input) for mailman id 1012750;
 Thu, 12 Jun 2025 10:07: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 1uPeq2-0004EN-ET
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 10:07:14 +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 0338948b-4775-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 12:07:14 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-450ce3a2dd5so6622725e9.3
 for ; Thu, 12 Jun 2025 03:07:14 -0700 (PDT)
Received: from localhost.localdomain (188.226.6.51.dyn.plus.net.
 [51.6.226.188]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4532e2354fbsm15346475e9.15.2025.06.12.03.07.12
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Jun 2025 03:07:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0338948b-4775-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1749722833; x=1750327633; 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=bUko4TzvIlHQks/LPst4s4YFTFwvXxHrUO/t6ns3ywA=;
        b=Fu5lkdhoeNGWv0BJ44XQUr+AWKRirliCHxKrrguKSho607KL+p82t7deUN1pIS2o2d
         6RtYeQ3LifhmqBkxNOovhxj7OmFMnP3NANHOpId3GtEu/cQpQGkPfYSvj9QtGhnEKirz
         vm3SlbvB9Y5Tzrfj7aiHzBkKM8IN+8CJlf8U0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749722833; x=1750327633;
        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=bUko4TzvIlHQks/LPst4s4YFTFwvXxHrUO/t6ns3ywA=;
        b=wRq0hRWO+z8FI07ZH5XGHRYpboDBJFN7Px9nrsMtL7tqnPs2AWVTIQCCJ0xFsv+BTp
         6Mg9+gSSeczE+EpmRFFvUVUekGeXoLsoWU8eu7CsWiUrrhs0CXtjp++T1z5qhp3cl7Oc
         zyH4uNHivFCQsq3BpDjy45SZCna6oi17PvotslS+4RdXWFp9APM803MJR8Aeko8Wn88J
         2Uxnn1A4YzxKYBsugxEBeMy59wbhzYxOz2z8rtdToJ04Ts5dXHkd5ZT+stnq5E/+lR3S
         hfGO4FbrgumqlPGOxwoG5HtNt2VGjzHPSP3qFdo/C7jlgxrCv2HvkdSlL3pXMc21ToVd
         dwpA==
X-Gm-Message-State: AOJu0Yx6mrCktyPJiYDuhe7bhqeVtVklrtx89TxJuFLHEK+HIersK11H
	u0kE6mNlkPD6xTW/R23YXcjp9dale7SdQciDMMpGHWg09nptlLmvJjxWs1iHOluvzLGb0sQIaUy
	BSeEJ10I=
X-Gm-Gg: ASbGnct16mgXvi2iG/XCGcHfCZExuuxxf1xNOwiFLpC1RSEZuhlGnbu6yvUmVbp5sXR
	itN9hjP89oa1Qyy+SrN8rH89cl3zX3OmQRWChaVUPRBou7HfW9QRT8jU3Pm0dQQGEp23IHKYguq
	zKOyXWu4nQ/o+wWve/RnUBhL0LG1oWhOn/9bk7Uc7lw4rXGetiVjA/QD4d4Nvhf0dgWND+WzCzA
	ijpET2Os28qGLDID6se7nqkSUzqPZpscpxwxuDNsxn6yW6iSsqEs3IvJeULC3LPVk8+gMmZOEVx
	31XlqNxZROnMbUil8S3wgHL+R6bg19/x8sOROdtVlc9/2Iq7HozeMjCxQIuDGlhiLAYnfM0JIQI
	h53/+YP6NwcZdTbK6OEEWDIOxCXznCw==
X-Google-Smtp-Source: AGHT+IGNe8PRN8RpZpUO8SDjWIaT9c4E5wW6Vm1JyH4OneUxjJ8Tc1IakSSjhXpqj66KcXSnKZlxng==
X-Received: by 2002:a05:600c:6385:b0:450:cea0:1781 with SMTP id 5b1f17b1804b1-4532d33de4bmr25336035e9.16.1749722833094;
        Thu, 12 Jun 2025 03:07:13 -0700 (PDT)
From: Frediano Ziglio 
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v2] xen: Strip xen.efi by default
Date: Thu, 12 Jun 2025 11:07:03 +0100
Message-ID: <20250612100705.21988-1-frediano.ziglio@cloud.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

For xen.gz file we strip all symbols and have an additional
xen-syms file version with all symbols.
Make xen.efi more coherent stripping all symbols too.
xen.efi.elf can be used for debugging.

Signed-off-by: Frediano Ziglio 
---
Changes since v1:
- avoid leaving target if some command fails
---
 docs/misc/efi.pandoc  |  8 +-------
 xen/Kconfig.debug     |  9 ++-------
 xen/Makefile          | 19 -------------------
 xen/arch/x86/Makefile |  8 +++++---
 4 files changed, 8 insertions(+), 36 deletions(-)

diff --git a/docs/misc/efi.pandoc b/docs/misc/efi.pandoc
index 11c1ac3346..c66b18a66b 100644
--- a/docs/misc/efi.pandoc
+++ b/docs/misc/efi.pandoc
@@ -20,13 +20,7 @@ Xen to load the configuration file even if multiboot modules are found.
 Once built, `make install-xen` will place the resulting binary directly into
 the EFI boot partition, provided `EFI_VENDOR` is set in the environment (and
 `EFI_MOUNTPOINT` is overridden as needed, should the default of `/boot/efi` not
-match your system). When built with debug info, the binary can be quite large.
-Setting `INSTALL_EFI_STRIP=1` in the environment will cause it to be stripped
-of debug info in the process of installing. `INSTALL_EFI_STRIP` can also be set
-to any combination of options suitable to pass to `strip`, in case the default
-ones don't do. The xen.efi binary will also be installed in `/usr/lib64/efi/`,
-unless `EFI_DIR` is set in the environment to override this default. This
-binary will not be stripped in the process.
+match your system).
 
 The binary itself will require a configuration file (names with the `.efi`
 extension of the binary's name replaced by `.cfg`, and - until an existing
diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index d14093017e..cafbb1236c 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -147,12 +147,7 @@ config DEBUG_INFO
 	  Say Y here if you want to build Xen with debug information. This
 	  information is needed e.g. for doing crash dump analysis of the
 	  hypervisor via the "crash" tool.
-	  Saying Y will increase the size of the xen-syms and xen.efi
-	  binaries. In case the space on the EFI boot partition is rather
-	  limited, you may want to install a stripped variant of xen.efi in
-	  the EFI boot partition (look for "INSTALL_EFI_STRIP" in
-	  docs/misc/efi.pandoc for more information - when not using
-	  "make install-xen" for installing xen.efi, stripping needs to be
-	  done outside the Xen build environment).
+	  Saying Y will increase the size of the xen-syms and xen.efi.elf
+	  binaries.
 
 endmenu
diff --git a/xen/Makefile b/xen/Makefile
index 8fc4e042ff..664c4ea7b8 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -488,22 +488,6 @@ endif
 .PHONY: _build
 _build: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
 
-# Strip
-#
-# INSTALL_EFI_STRIP, if defined, will cause xen.efi to be stripped before it
-# is installed. If INSTALL_EFI_STRIP is '1', then the default option(s) below
-# will be used. Otherwise, INSTALL_EFI_STRIP value will be used as the
-# option(s) to the strip command.
-ifdef INSTALL_EFI_STRIP
-
-ifeq ($(INSTALL_EFI_STRIP),1)
-efi-strip-opt := --strip-debug --keep-file-symbols
-else
-efi-strip-opt := $(INSTALL_EFI_STRIP)
-endif
-
-endif
-
 .PHONY: _install
 _install: D=$(DESTDIR)
 _install: T=$(notdir $(TARGET))
@@ -530,9 +514,6 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
 		ln -sf $(T)-$(XEN_FULLVERSION).efi $(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).efi; \
 		ln -sf $(T)-$(XEN_FULLVERSION).efi $(D)$(EFI_DIR)/$(T).efi; \
 		if [ -n '$(EFI_MOUNTPOINT)' -a -n '$(EFI_VENDOR)' ]; then \
-			$(if $(efi-strip-opt), \
-			     $(STRIP) $(efi-strip-opt) -p -o $(TARGET).efi.stripped $(TARGET).efi && \
-			     $(INSTALL_DATA) $(TARGET).efi.stripped $(D)$(EFI_MOUNTPOINT)/efi/$(EFI_VENDOR)/$(T)-$(XEN_FULLVERSION).efi ||) \
 			$(INSTALL_DATA) $(TARGET).efi $(D)$(EFI_MOUNTPOINT)/efi/$(EFI_VENDOR)/$(T)-$(XEN_FULLVERSION).efi; \
 		elif [ "$(D)" = "$(patsubst $(shell cd $(XEN_ROOT) && pwd)/%,%,$(D))" ]; then \
 			echo 'EFI installation only partially done (EFI_VENDOR not set)' >&2; \
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index ce724a9daa..e0ebc8c73e 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -232,14 +232,16 @@ endif
 	$(MAKE) $(build)=$(@D) .$(@F).1r.o .$(@F).1s.o
 	$(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T $(obj)/efi.lds $< \
 	      $(dot-target).1r.o $(dot-target).1s.o $(orphan-handling-y) \
-	      $(note_file_option) -o $@
-	$(NM) -pa --format=sysv $@ \
+	      $(note_file_option) -o $@.tmp
+	$(NM) -pa --format=sysv $@.tmp \
 		| $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \
 		> $@.map
 ifeq ($(CONFIG_DEBUG_INFO),y)
-	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) -O elf64-x86-64 $@ $@.elf
+	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) -O elf64-x86-64 $@.tmp $@.elf
+	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(STRIP) $@.tmp
 endif
 	rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]*
+	mv -f $@.tmp $@
 ifeq ($(CONFIG_XEN_IBT),y)
 	$(SHELL) $(srctree)/tools/check-endbr.sh $@
 endif
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 12 10:13:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 10:13:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012767.1391264 (Exim 4.92)
	(envelope-from )
	id 1uPevs-0006I4-6b; Thu, 12 Jun 2025 10:13:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012767.1391264; Thu, 12 Jun 2025 10: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 1uPevs-0006Hx-3j; Thu, 12 Jun 2025 10:13:16 +0000
Received: by outflank-mailman (input) for mailman id 1012767;
 Thu, 12 Jun 2025 10: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 1uPevq-0006Hr-9Q
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 10:13:14 +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 d947b63b-4775-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 12:13:13 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3a4fea34e07so489151f8f.1
 for ; Thu, 12 Jun 2025 03:13:13 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-7488089669asm1102802b3a.52.2025.06.12.03.13.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 03:13:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d947b63b-4775-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749723192; x=1750327992; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=bAaUGNrB3gisYCVSsO6qM9UyrwByeIh4rLQB2sgV4Ig=;
        b=X58T1HoE8+/VDd7w+HORaaaeWubGCiLYgd144wxHLyfPyNOisqxJVVn+2Bhf3hAWnd
         /IQBbEFi+VW4Hugx+EyZO2lHEuME5sLg7u+712VDy+XqLpEh+bAvw+/cmPPgjZ6/62yd
         pViMybLQa/ENneWVVg7mx6O0NC+Shm85xi3gIXQTyofi7RZgTVvr6EwFV59gpor+qRLq
         I+IzrL1AyfNNym2RoK00R8EHo9SnNb3Kp41HlNLrv3zZCD+n9OJM79b1n6G6br/TgXr4
         haNLouMesYAoUKFA585pMccUsBMFyzI130UFkZtnyNYS5cQaKPZHAzz3ErQbqDYyXpDf
         Kg3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749723192; x=1750327992;
        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=bAaUGNrB3gisYCVSsO6qM9UyrwByeIh4rLQB2sgV4Ig=;
        b=lrVeLYVXibG0J3MuqmNs3Au7PA9LS0G3N7Jq+Wq15XJfyDH+zgTjO2MZ6R6u4vPCWs
         e665LW8E96+mW70vCBkykKOOjlmS1iYnwonRYo7YgwyqVKnQIN/1b8c6bAW59SWzVDFH
         kJW6Ynk89d1QRxXb+IvX2QLjTamKGAB4IwRuVYbD0wevz0jgWwt/TwPCa5ycZOq3jFrq
         tGXlIjWWbWPjg/6cD0/+7Qsd8LyKey5EYXq9nYqj3LXizvE72HLtgOaQ/2jA/FoMo6h8
         CKo+vVVZA0HXH5huCRyv6HvLmhltV6eRTd3HydMbrbt5AvNbpK/4RmyYh8PDHXq50aCs
         cWKg==
X-Forwarded-Encrypted: i=1; AJvYcCVSsY/Q/AylrpwNnbA2Gpijpcj53dRkD9d1ghg2JgByM8S6wY8D2qHz+9xPZVkwAZPQu22up4EP1Dk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YypBT04jCsD0BuqQ4BxXrWyoCGqKnSPtQgEQXbxzmSu3XhhUt1w
	L0O8+X3hQap/DAF0bp4FGrvxRd/4URRJuy/WeY4ERGtk7xQYLhjYrPvAT+OKQeRGtg==
X-Gm-Gg: ASbGncucZq9jwazlBdoytBl7W+uzoIokcW4bti56/ur6g6YQNGHiH1SuSN36vCy37Fo
	7UsqdDvNCyIhu3cvu1GyvxGc8BjZbH8uHKeKePHkycIYt6I2ipoI3KqyMhOqEODzQxdABgrewSE
	CukL/h8FFKgrizNPsn6qmB1bgmdKeAMkTTlWFEb5YiveU4CHsOVYEh7dtr87qWA0qn2um+E4pcs
	HFvpZFAlHxuqlAaD9fYBBK9Om9C6x8xGtbeFtMa95SMHnPHlQo04TuZTrLNK/lykYwpR11aUGjO
	EEwpDN68mytbLIj9X6ZzS6ukVaGYhQ2tICOexcOYxdRR+qYvWjsS9ZucffaeeHWJ9PpKXde+Jwg
	vi23TRagKzDhW+9+xeN2jcYAbysrzMfvDr3X67RXV+kP3fYI=
X-Google-Smtp-Source: AGHT+IE5UMV7jxpa0yOd1PWPmt1tR5Ts0WQojQVJMylT3dKwSrgnuV35VasKhBmDqxtnqLYyq2CxIQ==
X-Received: by 2002:a05:6000:4304:b0:3a4:f7ae:77e8 with SMTP id ffacd0b85a97d-3a55869b507mr5621712f8f.15.1749723192609;
        Thu, 12 Jun 2025 03:13:12 -0700 (PDT)
Message-ID: 
Date: Thu, 12 Jun 2025 12:13:05 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 05/18] xen/cpufreq: refactor cmdline "cpufreq=xxx"
To: Penny Zheng 
Cc: ray.huang@amd.com, xen-devel@lists.xenproject.org
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-6-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: <20250527084833.338427-6-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.05.2025 10:48, Penny Zheng wrote:
> --- a/xen/drivers/cpufreq/cpufreq.c
> +++ b/xen/drivers/cpufreq/cpufreq.c
> @@ -69,8 +69,55 @@ enum cpufreq_xen_opt __initdata cpufreq_xen_opts[2] = { CPUFREQ_xen,
>                                                          CPUFREQ_none };
>  unsigned int __initdata cpufreq_xen_cnt = 1;
>  
> +static const char __initconst cpufreq_opts_str[][5] = {
> +    [CPUFREQ_none] = "none",
> +    [CPUFREQ_xen] = "xen",
> +    [CPUFREQ_hwp] = "hwp",
> +};
> +
>  static int __init cpufreq_cmdline_parse(const char *s, const char *e);
>  
> +static bool __init cpufreq_opts_contain(enum cpufreq_xen_opt option)
> +{
> +    unsigned int count = cpufreq_xen_cnt;
> +
> +    while ( count )
> +    {
> +        if ( cpufreq_xen_opts[--count] == option )

Instead of this, "while ( count-- )" would likely be slightly better;
less risk of an edit to the loop body (however unlikely that may seem
right now) then bypassing the decrement.

> +            return true;
> +    }
> +
> +    return false;
> +}
> +
> +static int __init handle_cpufreq_cmdline(enum cpufreq_xen_opt option)
> +{
> +    int ret = 0;
> +
> +    if ( cpufreq_opts_contain(option) )
> +    {
> +        printk(XENLOG_WARNING "Duplicate cpufreq driver option: %s\n",
> +               cpufreq_opts_str[option]);

Do we really need such a warning?

> +        return 0;
> +    }
> +
> +    cpufreq_controller = FREQCTL_xen;
> +    cpufreq_xen_opts[cpufreq_xen_cnt++] = option;

This could do with (at least) an assertion that we indeed don't overrun the
array.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 10:19:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 10:19:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012773.1391275 (Exim 4.92)
	(envelope-from )
	id 1uPf1h-0006rM-Rd; Thu, 12 Jun 2025 10:19:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012773.1391275; Thu, 12 Jun 2025 10:19:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPf1h-0006rF-Mp; Thu, 12 Jun 2025 10:19:17 +0000
Received: by outflank-mailman (input) for mailman id 1012773;
 Thu, 12 Jun 2025 10:19: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 1uPf1g-0006r9-5A
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 10:19:16 +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 aadbdce1-4776-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 12:19:05 +0200 (CEST)
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 AF127218E7;
 Thu, 12 Jun 2025 10:19:11 +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 E1D23132D8;
 Thu, 12 Jun 2025 10:19:09 +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 qsicNZ2pSmglUAAAD6G6ig
 (envelope-from ); Thu, 12 Jun 2025 10:19: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: aadbdce1-4776-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1749723551; 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=mdhllsYptJzWpWRaCohWre8At5dUtUcWHkcMPixG5dA=;
	b=oj14FmZwawggQFz/mpwdPbpGxwCSq2yPj3hGSfoo0OU/wstTt5Fn2/rZHE96f+GGsfXZNz
	ExJsQpevYaVkROYm3SA5qZq8slxwMNs6Ubm+g7AedPOk6tq42b2faUsAZONoDMO7D7SwIf
	2igyxskJsSksCKMTFbKdg8mOB2yntgw=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1749723551; 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=mdhllsYptJzWpWRaCohWre8At5dUtUcWHkcMPixG5dA=;
	b=oj14FmZwawggQFz/mpwdPbpGxwCSq2yPj3hGSfoo0OU/wstTt5Fn2/rZHE96f+GGsfXZNz
	ExJsQpevYaVkROYm3SA5qZq8slxwMNs6Ubm+g7AedPOk6tq42b2faUsAZONoDMO7D7SwIf
	2igyxskJsSksCKMTFbKdg8mOB2yntgw=
Message-ID: <84b14425-03e4-42be-8bd5-9bc010ebecda@suse.com>
Date: Thu, 12 Jun 2025 12:19:09 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86: Fix build warnings about export.h
To: Zhenghan Cheng , tglx@linutronix.de,
 mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
 mario.limonciello@amd.com, yazen.ghannam@amd.com, jpoimboe@kernel.org,
 tony.luck@intel.com, jarkko@kernel.org, bhelgaas@google.com,
 pbonzini@redhat.com, oleg@redhat.com, jbaron@akamai.com, ning.sun@intel.com,
 seanjc@google.com, luto@kernel.org, andy@kernel.org, jim.cromie@gmail.com,
 kirill.shutemov@linux.intel.com
Cc: hpa@zytor.com, pawan.kumar.gupta@linux.intel.com, vkuznets@redhat.com,
 rostedt@goodmis.org, ardb@kernel.org, thomas.lendacky@amd.com,
 nikunj@amd.com, ashish.kalra@amd.com, kees@kernel.org,
 alexandre.chartre@oracle.com, rppt@kernel.org, steve.wahl@hpe.com,
 jirislaby@kernel.org, apatel@ventanamicro.com, bvanassche@acm.org,
 ptsm@linux.microsoft.com, Jonathan.Cameron@huawei.com,
 beata.michalska@arm.com, xin@zytor.com, davydov-max@yandex-team.ru,
 ravi.bangoria@amd.com, joel.granados@kernel.org, ffmancera@riseup.net,
 kprateek.nayak@amd.com, akpm@linux-foundation.org, bhe@redhat.com,
 brgerst@gmail.com, coxu@redhat.com, dmaluka@chromium.org,
 linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org,
 linux-sgx@vger.kernel.org, kvm@vger.kernel.org,
 virtualization@lists.linux.dev, tboot-devel@lists.sourceforge.net,
 nouveau@lists.freedesktop.org, linux-coco@lists.linux.dev,
 xen-devel@lists.xenproject.org, Huacai Chen ,
 Zhenghan Cheng 
References: <20250612093228.7655-1-chengzhenghan@uniontech.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: <20250612093228.7655-1-chengzhenghan@uniontech.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------r5mQdgOt4Whh0CrWNE4SR5Wo"
X-Spam-Flag: NO
X-Spam-Score: -3.69
X-Spamd-Result: default: False [-3.69 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SIGNED_PGP(-2.00)[];
	SUSPICIOUS_RECIPS(1.50)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	MIME_BASE64_TEXT_BOGUS(1.00)[];
	MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];
	NEURAL_HAM_SHORT(-0.19)[-0.964];
	MIME_BASE64_TEXT(0.10)[];
	MIME_UNKNOWN(0.10)[application/pgp-keys];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FREEMAIL_ENVRCPT(0.00)[gmail.com];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~];
	FREEMAIL_CC(0.00)[zytor.com,linux.intel.com,redhat.com,goodmis.org,kernel.org,amd.com,oracle.com,hpe.com,ventanamicro.com,acm.org,linux.microsoft.com,huawei.com,arm.com,yandex-team.ru,riseup.net,linux-foundation.org,gmail.com,chromium.org,vger.kernel.org,lists.linux.dev,lists.sourceforge.net,lists.freedesktop.org,lists.xenproject.org,loongson.cn,example.com];
	ARC_NA(0.00)[];
	FREEMAIL_TO(0.00)[uniontech.com,linutronix.de,redhat.com,alien8.de,linux.intel.com,kernel.org,amd.com,intel.com,google.com,akamai.com,gmail.com];
	RCVD_TLS_ALL(0.00)[];
	R_RATELIMIT(0.00)[to_ip_from(RLf5ioe8sym7mk9p7n1hwm4mac)];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	HAS_ATTACHMENT(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCPT_COUNT_GT_50(0.00)[61];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TAGGED_RCPT(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.com:mid,suse.com:email]
X-Spam-Level: 

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------r5mQdgOt4Whh0CrWNE4SR5Wo
Content-Type: multipart/mixed; boundary="------------K0XYKHlxFzsICF9SMBfAUlSE";
 protected-headers="v1"
From: Juergen Gross 
To: Zhenghan Cheng , tglx@linutronix.de,
 mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
 mario.limonciello@amd.com, yazen.ghannam@amd.com, jpoimboe@kernel.org,
 tony.luck@intel.com, jarkko@kernel.org, bhelgaas@google.com,
 pbonzini@redhat.com, oleg@redhat.com, jbaron@akamai.com, ning.sun@intel.com,
 seanjc@google.com, luto@kernel.org, andy@kernel.org, jim.cromie@gmail.com,
 kirill.shutemov@linux.intel.com
Cc: hpa@zytor.com, pawan.kumar.gupta@linux.intel.com, vkuznets@redhat.com,
 rostedt@goodmis.org, ardb@kernel.org, thomas.lendacky@amd.com,
 nikunj@amd.com, ashish.kalra@amd.com, kees@kernel.org,
 alexandre.chartre@oracle.com, rppt@kernel.org, steve.wahl@hpe.com,
 jirislaby@kernel.org, apatel@ventanamicro.com, bvanassche@acm.org,
 ptsm@linux.microsoft.com, Jonathan.Cameron@huawei.com,
 beata.michalska@arm.com, xin@zytor.com, davydov-max@yandex-team.ru,
 ravi.bangoria@amd.com, joel.granados@kernel.org, ffmancera@riseup.net,
 kprateek.nayak@amd.com, akpm@linux-foundation.org, bhe@redhat.com,
 brgerst@gmail.com, coxu@redhat.com, dmaluka@chromium.org,
 linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org,
 linux-sgx@vger.kernel.org, kvm@vger.kernel.org,
 virtualization@lists.linux.dev, tboot-devel@lists.sourceforge.net,
 nouveau@lists.freedesktop.org, linux-coco@lists.linux.dev,
 xen-devel@lists.xenproject.org, Huacai Chen ,
 Zhenghan Cheng 
Message-ID: <84b14425-03e4-42be-8bd5-9bc010ebecda@suse.com>
Subject: Re: [PATCH] x86: Fix build warnings about export.h
References: <20250612093228.7655-1-chengzhenghan@uniontech.com>
In-Reply-To: <20250612093228.7655-1-chengzhenghan@uniontech.com>

--------------K0XYKHlxFzsICF9SMBfAUlSE
Content-Type: multipart/mixed; boundary="------------nwabp6M47v7PnA12GBXmtNk0"

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

T24gMTIuMDYuMjUgMTE6MzIsIFpoZW5naGFuIENoZW5nIHdyb3RlOg0KPiBBZnRlciBjb21t
aXQgYTkzNGE1N2E0MmY2NGE0ICgic2NyaXB0cy9taXNjLWNoZWNrOg0KPiBjaGVjayBtaXNz
aW5nICNpbmNsdWRlIDxsaW51eC9leHBvcnQuaD4gd2hlbiBXPTEiKQ0KPiBhbmQgY29tbWl0
IDdkOTU2ODBkNjRhYzhlODM2YyAoInNjcmlwdHMvbWlzYy1jaGVjazoNCj4gY2hlY2sgdW5u
ZWNlc3NhcnkgI2luY2x1ZGUgPGxpbnV4L2V4cG9ydC5oPiB3aGVuIFc9MSIpLA0KPiB3ZSBn
ZXQgc29tZSBidWlsZCB3YXJuaW5ncyB3aXRoIFc9MSxzdWNoIGFzOg0KPiANCj4gYXJjaC94
ODYvY29jby9zZXYvY29yZS5jOiB3YXJuaW5nOiBFWFBPUlRfU1lNQk9MKCkgaXMgdXNlZCwg
YnV0ICNpbmNsdWRlIDxsaW51eC9leHBvcnQuaD4gaXMgbWlzc2luZw0KPiBhcmNoL3g4Ni9j
cnlwdG8vYXJpYV9hZXNuaV9hdngyX2dsdWUuYzogd2FybmluZzogRVhQT1JUX1NZTUJPTCgp
IGlzIHVzZWQsIGJ1dCAjaW5jbHVkZSA8bGludXgvZXhwb3J0Lmg+IGlzIG1pc3NpbmcNCj4g
YXJjaC94ODYva2VybmVsL3Vud2luZF9vcmMuYzogd2FybmluZzogRVhQT1JUX1NZTUJPTCgp
IGlzIHVzZWQsIGJ1dCAjaW5jbHVkZSA8bGludXgvZXhwb3J0Lmg+IGlzIG1pc3NpbmcNCj4g
YXJjaC94ODYva3ZtL2h5cGVydi5jOiB3YXJuaW5nOiBFWFBPUlRfU1lNQk9MKCkgaXMgdXNl
ZCwgYnV0ICNpbmNsdWRlIDxsaW51eC9leHBvcnQuaD4gaXMgbWlzc2luZw0KPiBhcmNoL3g4
Ni9ldmVudHMvaW50ZWwvY29yZS5jOiB3YXJuaW5nOiBFWFBPUlRfU1lNQk9MKCkgaXMgbm90
IHVzZWQsIGJ1dCAjaW5jbHVkZSA8bGludXgvZXhwb3J0Lmg+IGlzIHByZXNlbnQNCj4gYXJj
aC94ODYvZXZlbnRzL3poYW94aW4vY29yZS5jOiB3YXJuaW5nOiBFWFBPUlRfU1lNQk9MKCkg
aXMgbm90IHVzZWQsIGJ1dCAjaW5jbHVkZSA8bGludXgvZXhwb3J0Lmg+IGlzIHByZXNlbnQN
Cj4gYXJjaC94ODYva2VybmVsL2NyYXNoLmM6IHdhcm5pbmc6IEVYUE9SVF9TWU1CT0woKSBp
cyBub3QgdXNlZCwgYnV0ICNpbmNsdWRlIDxsaW51eC9leHBvcnQuaD4gaXMgcHJlc2VudA0K
PiBhcmNoL3g4Ni9rZXJuZWwvZGV2aWNldHJlZS5jOiB3YXJuaW5nOiBFWFBPUlRfU1lNQk9M
KCkgaXMgbm90IHVzZWQsIGJ1dCAjaW5jbHVkZSA8bGludXgvZXhwb3J0Lmg+IGlzIHByZXNl
bnQNCj4gDQo+IHNvIGZpeCB0aGVzZSBidWlsZCB3YXJuaW5ncyBmb3IgeDg2Lg0KPiANCj4g
U2lnbmVkLW9mZi1ieTogIlpoZW5naGFuIENoZW5nIiA8Y2hlbmd6aGVuZ2hhbkB1bmlvbnRl
Y2guY29tPg0KPiBTdWdnZXN0ZWQtYnk6ICJIdWFjYWkgQ2hlbiIgPGNoZW5odWFjYWlAbG9v
bmdzb24uY24+DQoNCkZvciBYZW4gYW5kIHBhcmF2aXJ0Og0KDQpBY2tlZC1ieTogSnVlcmdl
biBHcm9zcyA8amdyb3NzQHN1c2UuY29tPg0KDQpZb3VyIHBhdGNoIGlzIGxvb2tpbmcgYSBs
aXR0bGUgYml0IHN0cmFuZ2UsIGFzIHRoZSBsaXN0IG9mIG1vZGlmaWVkIGZpbGVzDQppcyBs
b2NhdGVkIGJldHdlZW4gdGhlIHBhdGNoIGh1bmtzLCBmb2xsb3dlZCBieSBhbm90aGVyICJT
aWduZWQtb2ZmLWJ5OiIuDQoNCg0KSnVlcmdlbg0K
--------------nwabp6M47v7PnA12GBXmtNk0
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-----

--------------nwabp6M47v7PnA12GBXmtNk0--

--------------K0XYKHlxFzsICF9SMBfAUlSE--

--------------r5mQdgOt4Whh0CrWNE4SR5Wo
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/Ey8FAmhKqZ0FAwAAAAAACgkQsN6d1ii/Ey9X
VQf/R7PwyvgEHQL+aCN+trwA+f6BOxwLSPkJMa068wO/uqFIQUIrHnSm8vuItp8K4TbRoujnCAmD
qc6aLD0w2pHhHkmvJEUFNDGKVeqlukRm3AyTCVbqN1RMw7Nd+hcM8yJv1P6hxJznNVTeuamYww6n
jrWmU9VBqFABUMVuH42in3ngALypAG9sx3Sm05R0vn6DAV+GI3mrnpKCTF1ONoMcXQBPJEohtgLC
f0LvToJeeeHnNhc6c20AIKOrxbdMXjosMfS2hDhX3tTDPm9LELql34Z7n1nGuloLqgbq2/590hw6
4PZuTMy6Qxf5Pw92YW24Jc6NEWR5myQo2FWARFNaMw==
=FXNZ
-----END PGP SIGNATURE-----

--------------r5mQdgOt4Whh0CrWNE4SR5Wo--


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 10:24:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 10:24:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012782.1391284 (Exim 4.92)
	(envelope-from )
	id 1uPf6e-0000AX-AV; Thu, 12 Jun 2025 10:24:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012782.1391284; Thu, 12 Jun 2025 10: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 1uPf6e-0000AI-7g; Thu, 12 Jun 2025 10:24:24 +0000
Received: by outflank-mailman (input) for mailman id 1012782;
 Thu, 12 Jun 2025 10: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 1uPf6c-00008a-4s
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 10:24:22 +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 66caeb9f-4777-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 12:24:20 +0200 (CEST)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-ade5b8aab41so170956366b.0
 for ; Thu, 12 Jun 2025 03:24:20 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6086a58f08csm977967a12.21.2025.06.12.03.24.18
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Jun 2025 03:24:18 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 66caeb9f-4777-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749723859; x=1750328659; 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=9UdVJFrxjHJKFfacS1TeLALqEa8kEbmNvmZtmUfINTM=;
        b=UbzXpjNW0NcWoazJd0tDA0M2nX63qsmC3JOVgj2aWxT1MbPJQPfpclVXfr0J/EKRN8
         WjUzVYMnHUw9p/FAS5GF3T0U7OQt7wdrXLx8UxTyed68AQ76zxXvj8bSKBLAlLjuShsS
         mMAZtyCHvwdZOUKwLvHjlrV0JHR3PPA0O/d4ZsMV72eECIbuDTogx5bYMzqV8rDn8jad
         l5txB2FG0KLrwb7WMh3fG8qci2Pji7e0yapqcgP1bYRXBKDgsEkhWkLyONf0+vXjeecV
         I3dseNBMi3D0PTq6UQKC11tVsjUFoECHqOYWvqt5XL/kfKsRCAoaeHskC0nigkGAPcR/
         UICw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749723859; x=1750328659;
        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=9UdVJFrxjHJKFfacS1TeLALqEa8kEbmNvmZtmUfINTM=;
        b=dgZG3w+omlLmqGv6vAtOP8wdhGPQlERZFZvmK3Mhq3dIkoKuw+GULEHxlONj8qw45A
         0J40WL79AgjPVQUvJvfzsiY6ixhn15G3W3S2WKSP77MyTvw/x8traaeF6ASjuGcjEztp
         V0B+dHILkyCNuuL8BMRz3u2N30L7y1BszxX0K3GUOc5zazh1tnb1OXHfFvcBUUkhdmzC
         pg++aPQYf3SD7zgvxIvc9kCPTmiYloEJezKj+WX6Ee2DywnGJMB/E6+pt1ebVh6PHcQM
         sHV5xY1ea86occ/rcmb40reSkxW1gpq7KoXpxk1vryd/a60qtmEPmbzevXF6wv98vP6C
         aHzA==
X-Gm-Message-State: AOJu0Ywrltzb5lRPxRwR3ZSS1q+mbVkYR5aAkhCr+7vemfE0SUzNcbwF
	Aj5BGTV0u2/uO4WTksZ0Vl+Gez7KNM+x/nlZVZVG2xNs0bKojNxuDt3GKN4eTA==
X-Gm-Gg: ASbGncsGZBT2LVL+2G4R5gahZKqZs1YaOn9j14zVt37ycVCYWIwzol3L/RCtz453zTu
	bX8UXxM9FauEPK/iK+ex4uCfn/2RZYf2SwMqfGKFUBUnd0Ppf1yPyfNOVphi6V447uDYJJf4pEX
	tqromGp1yCeEzPNnHQ4WkF6y0QVWOnbI0us/j/GL6tDcXgRZzjTb3gG3CFYEPDX+hNaq39IR9xX
	PMfhQ9FKApr7TUh3+ap9vBbVHj6bv8ROKk56+d56wA4ovWKgvPbKCPC7PJoOa90W/oBW0DPzIRd
	jSlTgX9aQ0rlQFoBb5dpShbROALI1e/6DS6SYbFWwaGVFgSVa0nPJ/YkM5ClVDjWV8xQ/IHTGV4
	ApAMhOS+Ige7m800FSvG3aNy9YPOB
X-Google-Smtp-Source: AGHT+IH0JchigwQ8+ZY0LMinpF7PXANOo5GP/CgCmtRn6+c+7SJtcPipORpXfagUFAV4CmvPbF5SkA==
X-Received: by 2002:a17:907:9728:b0:ad2:4fa0:88cd with SMTP id a640c23a62f3a-adea927a0ecmr194139566b.9.1749723859090;
        Thu, 12 Jun 2025 03:24:19 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH v2] xen: move declarations of device_tree_get_{reg,u32}() to xen/device_tree.h
Date: Thu, 12 Jun 2025 12:24:12 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The definitions of device_tree_get_reg() and device_tree_get_u32() are already
in common code, so move their prototypes there as well.

Signed-off-by: Oleksii Kurochko 
Reviewed-by: Michal Orzel 
---
Changes in v2:
 - Update the commit message.
 - Add Reviewed-by: Michal Orzel .
---
 xen/arch/arm/include/asm/setup.h | 6 ------
 xen/include/xen/device_tree.h    | 6 ++++++
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
index 6cf272c160..2b58549c1a 100644
--- a/xen/arch/arm/include/asm/setup.h
+++ b/xen/arch/arm/include/asm/setup.h
@@ -53,12 +53,6 @@ void setup_mm(void);
 extern uint32_t hyp_traps_vector[];
 void init_traps(void);
 
-void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
-                         uint32_t size_cells, paddr_t *start, paddr_t *size);
-
-u32 device_tree_get_u32(const void *fdt, int node,
-                        const char *prop_name, u32 dflt);
-
 int handle_device(struct domain *d, struct dt_device_node *dev, p2m_type_t p2mt,
                   struct rangeset *iomem_ranges, struct rangeset *irq_ranges);
 
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 6dc1fb5159..75017e4266 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -949,6 +949,12 @@ int dt_get_pci_domain_nr(struct dt_device_node *node);
 
 struct dt_device_node *dt_find_node_by_phandle(dt_phandle handle);
 
+void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
+                         uint32_t size_cells, paddr_t *start, paddr_t *size);
+
+u32 device_tree_get_u32(const void *fdt, int node,
+                        const char *prop_name, u32 dflt);
+
 #ifdef CONFIG_DEVICE_TREE_DEBUG
 #define dt_dprintk(fmt, args...)  \
     printk(XENLOG_DEBUG fmt, ## args)
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 12 10:38:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 10:38:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012792.1391294 (Exim 4.92)
	(envelope-from )
	id 1uPfJl-00020h-HF; Thu, 12 Jun 2025 10:37:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012792.1391294; Thu, 12 Jun 2025 10:37: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 1uPfJl-00020a-Dq; Thu, 12 Jun 2025 10:37:57 +0000
Received: by outflank-mailman (input) for mailman id 1012792;
 Thu, 12 Jun 2025 10:37: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 1uPfJk-00020U-PW
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 10:37:56 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20629.outbound.protection.outlook.com
 [2a01:111:f403:2009::629])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4bab28b9-4779-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 12:37:54 +0200 (CEST)
Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
 by BY5PR12MB4306.namprd12.prod.outlook.com (2603:10b6:a03:206::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.19; Thu, 12 Jun
 2025 10:37: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%2]) with mapi id 15.20.8835.018; Thu, 12 Jun 2025
 10:37: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: 4bab28b9-4779-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=xk9qSUh9utTIlMZ4a0NE95gf4ma2eZkfuyVzWSKhfQ1zPCzN/fGO3Cheg9IVA01XDDl0OrUxp+JBOYXjAn4Tlv4EDmY2oiOjhP6KkV8pEc3S9szDwuUdBE4fiJ/qi8oHVDlGg02itedZYSJwY0K9H3ee57IL+xFkKEDY0QKhxAZWzD4gbmdXOEn4ag3PwQL5EUevF4wvHOtz9ZIPPkpAZNtPsPO0p1JSRTQxXp17CHwzyfkqmdXf5Y5LBa2ijE/oQ05zEBpxq5iMe8XPmT+ISGMGm4VAaL2aoS49pmyVbH1lSOBzFfbwXmy++olKEPJ4I50GmxoAUimSFEmn4mimew==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=rfgt0faCwlqfNukCYZw3rOVHqafZfoASff2CONnzUiw=;
 b=viziyE1cea1yiKdsUB821jaNK8wJMtGMjfj/xM3B29WLEgnidA31daNjkpuHlzxIc2MuaKvQL7mehhiKKWDTzMo+hzFIXeRIDFo9JGlb66MUBc0FJomOHKMZ0tRmrqLJGJq2TKYQa+hOsYtLh9H6Z5wiYpqmJINOymqfywlxH0eDxsZkIToS+n1NSmxUzpS3awWZnsS1wRLOc65iZqt2rKcPdyr3Ok7EHYnbTnGbqhoDCBXSx8cFe5vJht8GdKRLQExKEarOF9HZ0CucOhRlWDKszjW7i3+ujos7YdPl03rFk8BDAZLTMvAgYO10xPxqhIG5BD6+ma3e1pmTgdwpKg==
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=rfgt0faCwlqfNukCYZw3rOVHqafZfoASff2CONnzUiw=;
 b=nQiqHiAhIriUDItk2eHuI3LK2y2yJ2M6Gwsz0ECqGvFvgQjIiVztzre/fMsSqfEOzO3kgobYVpJHa229/yc8Ozu8N3IzFAUDkVsQC9tZ6lnyLDcGWpx3SMp8PXypBbVpEsk9taznMiSM/tIsFjTnO/U7jtFbou4OIA5HIncNNtU=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <9105e7c1-da96-4bf9-9de8-d397712b68f2@amd.com>
Date: Thu, 12 Jun 2025 11:37:45 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 6/6] arm/mpu: Enable read/write to protection regions
 for arm32
Content-Language: en-GB
To: Luca Fancellu ,
 Ayan Kumar Halder 
Cc: "xen-devel@lists.xenproject.org" ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: <20250611143544.3453532-1-ayan.kumar.halder@amd.com>
 <20250611143544.3453532-7-ayan.kumar.halder@amd.com>
 <43768317-3409-46EA-B545-C78937EF42DC@arm.com>
From: Ayan Kumar Halder 
In-Reply-To: <43768317-3409-46EA-B545-C78937EF42DC@arm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LO4P265CA0205.GBRP265.PROD.OUTLOOK.COM
 (2603:10a6:600:318::19) To PH8PR12MB7326.namprd12.prod.outlook.com
 (2603:10b6:510:216::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|BY5PR12MB4306:EE_
X-MS-Office365-Filtering-Correlation-Id: 9484b461-9ad7-4315-cef8-08dda99d2dac
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?N0JpcjhPVlZmQk93dkNBbE9DdlhkY0NBV2lCNVBHK2kzaVdIRzlrV1RaVkl0?=
 =?utf-8?B?MTgva1JDQ0NFcUptQU83TjJOd3dCS1krVDQ2bGlTWjVLN2d2ZUgrUk9DcXhn?=
 =?utf-8?B?Zm55TXpOa1dvVStlR01oeHBoYTBPNjFkRXp5TURsTnptQU1ONzJPalYyOGUw?=
 =?utf-8?B?Q2t2RWN4bm1jb21raGhNL3FJYmxLSUZTZFp3WVZSRWFNSHBxVTN4L1lBSEl1?=
 =?utf-8?B?b09DbUdQSmNLRTlOcXJSVjZlTXZtYW4vVEVPY2o5RkJmTnRCN2ZuVVUrRVlN?=
 =?utf-8?B?dFg0QkxERHdzTjdMZXkycEZwOFZRZTJ0aTRLVXFwYlpxR0kxSVZJZlJucTlB?=
 =?utf-8?B?WnNFYkZodDV3cHZjNEdpZUkvcTVPc1plbFBtVzNWek4xMDV3ZDV4d1NERm52?=
 =?utf-8?B?bE1yTHRSSXRRSzE0czkwNGZWa0tvWlBsVDI3cVBaUEtmN0g1VFFGdTN1YU1B?=
 =?utf-8?B?VFNuTy81aVJnUWllcUw0QmErTUxlelFneC8xUS91UEFvcG5IVU1KeGN3V0lQ?=
 =?utf-8?B?cXFkUGxNbWpGeHVKSXhNaXRxUm11Rm9wN0V3SmFucHpXWEpwcUVNZFQ4ZXVs?=
 =?utf-8?B?NGlUSlFxRXUwV2Q3RjVJcHFLeFFBZnJpemErS0IrTDZ2QlM3SWVvWk5FcElB?=
 =?utf-8?B?elVLbTFTV0pmT1JVQ3BtOE96cmxSMlJuTFV5eVdGQzNUcDlpb1ByUkdGbE1M?=
 =?utf-8?B?ZHo1dmNpb0dLRFhzc251L21EaTd6bU9GdVdVVDFMVWFkNWJmNFIwM0Q3N1Nv?=
 =?utf-8?B?aVQ2b2Z1RW9PUklqS3ZjSlUrZVc4MVBNSjlvR05FUnMxQ09DcVhsTGFKbzBX?=
 =?utf-8?B?b0pZREs0SHE3ajNncW5WYzVFN2s5K2NkRnllZ1ZiUXhNMUdJV0xDY2xqcnBM?=
 =?utf-8?B?cHNYWUlsMW5LS2RYTHBjRnNtYjZiM3RRWG9KNXpjbklXT1dyTGQ4RUVENTdE?=
 =?utf-8?B?aFBFYVg0M1N4QWRqOWNweG1jei8ycTN0MXhsc2txU09FRXF1d2kzNGVVWEty?=
 =?utf-8?B?SVRiVjgyeE1CZWNkeTVCeThXaG4xMFQxYmdaNThqWmFYMFRvelRUSm1DNWE0?=
 =?utf-8?B?L2RWZDRuOTRqUkczU3FSL21DZmhUUm00QUNtTEpTanY2RWNURnd0TS8zajdB?=
 =?utf-8?B?em0zd1QrTExQcUl3ZlBLZjhJUElGVnpvTG5yR2U0VzVucUFXQUtMcFNHMGM4?=
 =?utf-8?B?anlyTmo4L2FKdVJWeVZHWVZveDVVUDUyZFhUWDgzdC9UZXJGRk9Cdjk2TUo2?=
 =?utf-8?B?bzBwazcrRFNvQWV0VXNlWk40ck1ZTVlpeWkxcVkxeURzRkpmTU01VHQrK1NQ?=
 =?utf-8?B?ZiswYmVuK3NWQmdIRlcraHR1NEMyOEo3bGo0a0x6bGdEZ0p3TVp3NVdyTzc1?=
 =?utf-8?B?ayt4ODF6UEdtRVBEQ3NhbStkVFVXTTh5dFlFaEhLa21yanBNMlJYRTFXbWY0?=
 =?utf-8?B?TGZEZndtVG9oaXk0OUlKOUp2czFUa1ZQQ1RrTE1seWY3L0IrVmVRc3hLMkNC?=
 =?utf-8?B?eHFVSCs3ZkdKTXZvVnZiYlFGL2Q2OTZTcW53Z3QxNStsbjFtam5rQVZKSEVx?=
 =?utf-8?B?ZCtCbGtEOHgzcVl1MU1JalBkc2FUVG9NbGsyaXM5Z3FSbmhoNjJvRXIzYS8y?=
 =?utf-8?B?YjlhalVTWS9qSVZFUHBiajhvdXArUTA3STZtMEU4dHk0Z2k2T2x2QWp3Q1JC?=
 =?utf-8?B?QUVUOHNHdExxendsUGY5YUJ5YlFzaFhEK20ySWY3dEZQRVo4YkNNSE04eFo0?=
 =?utf-8?B?NW4vajJtTzBmbkFFVDVRS0ZWYitFYnlJb1J4ejlJR1VRUnhMdFQ0c2xGUU56?=
 =?utf-8?B?dlgwUFZGR21FbGxxcFRobVpabnZkSkZVSEFkdmNiMFd0Y29HTVQ4WG9CRkRj?=
 =?utf-8?B?aUR2ZFM0aCs0YitSTHM2SlhtRFZkd3pPendIMVB4Z0tuSUowaVgwRW9HeWRL?=
 =?utf-8?Q?j8Pv5xh4OfU=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?YURRem1TQ3gyWkdtRFN1QStWK2NOeUhZV3dKT3ZQU3NZYnh3SGI1N1dPdzMx?=
 =?utf-8?B?eGlrSDhBYlZhc3g0OVVISFl1cUVYTFFvVVE1b0ZDRUlVSHh0QURSbkpkb2dw?=
 =?utf-8?B?TG1VR2FKazJxalExd25SbUg0OU1tOElBNEpiMTVFYmdjZEd4dk00VzBBS1BG?=
 =?utf-8?B?M0l1Y0k0VElaSnRrRHRuYXVVSW8wUm9SOE1LMjBuWXFzanRTY1JKM2ZlQ2FL?=
 =?utf-8?B?VnhxS29LQUZFbmRiOFBjT3J4Ty9ISCtnV2lBL2ZjTVg2OEVkemI1RDRzVWxX?=
 =?utf-8?B?ZEtBYk9JdW9UYlJPOTRrdHpoOFg1OStNVjJKVG91VjYwbTJlR0hyVmtmY1dJ?=
 =?utf-8?B?aFFFWkhwOWZ3QUIrR2VUMW1aSjBmUUxyaXV4dlJQNWpZOGd0dmZydTZncnV6?=
 =?utf-8?B?R0xyK2kwR3JLRFVsc0lDbnI4YVh1MURwNU9xTUJSSGJocHIwdGo4K2dmaEs3?=
 =?utf-8?B?ZFJJa0xPckNrdDhvWThGTitZMnZ3emdST1RqZUhNa2loV0ZlZUdsRWNwVnlk?=
 =?utf-8?B?bEtnTXdlT042aUd6aWp1Y2lXQ3pPR0pMQlVnS3UvVElSbGdoUGwzSlZYTktx?=
 =?utf-8?B?YjRJczlpdEYxVVkxTk5FcnAwWE13Q3hLVEhUbWtNMjh2MURCL2JrSjJaVTFX?=
 =?utf-8?B?NWRybnVudDY0bzlxeTQwekxyYVY0WitBcUNBcWhJaG9iV08vdFZDWEp4RDNV?=
 =?utf-8?B?TXlMMDdwdWhraFFSZ3VqRVduM003VEpkd1hleldUUnlTdXkyb3phVkJvWGNI?=
 =?utf-8?B?MUNVZjk0STdMSlZLWG8zNWk3YjVIaE5hb0FHdkVSV1hNRmtLYlcycXJ1Z3dk?=
 =?utf-8?B?a2RueXc4RWZzbHhNcklTVGZsbXhYSFlTZHhMdWlXRjY2WVUxUHFCV3YyLzI5?=
 =?utf-8?B?NmIvQ2RROVBUcVM2K2N1NEdwMTdGcW9uMEdxcllwaTBZcElYbXhBcmJLYWtT?=
 =?utf-8?B?VkRZb3VQOXJ1ZUVsclg1UWcrUkplMmJpUWFSSWdBTFhnOXBSd3oxcnR6Z0VH?=
 =?utf-8?B?RU90MTRDelpOY0laSnhvNkRMVkhCQzlHcmYwYmRrcVQ3QTc1L2k1ejJxclVo?=
 =?utf-8?B?VUNxYlFMYkN0ekFWNU5tNk9SZE1tS29JYVpLRFV5VGtQSmVMNys3ODQ0MklZ?=
 =?utf-8?B?cjFzL1llYU5RMDc0czdudEVQQSsvUytTd0dBL1JPcFdEbmxzR0lJc2dwZEhU?=
 =?utf-8?B?MFBzWU11TkUzOXRvZzRiNnNhaDcrbnhxSkFINVRqeE5LQUo2WE8yM3creVhR?=
 =?utf-8?B?U0R3RUJSZlJyOEh6K0V0Y0gyRmovOTl4TGREYkZEc1VRS0dyc2RjWVdRSzRY?=
 =?utf-8?B?SnhSelVFQWhpVlBjYlJFd0VOYUxGc3VXeGxUZy95ODBKN1ptRFk3U08rS2Fs?=
 =?utf-8?B?SG55dFNQdEYrR1BUQU1Oc0hBQkZHTW8wbmhIeDZOZDNRczhSNS8ySFBRMnYv?=
 =?utf-8?B?alhzMm50NmZVejF4aG9UOVR3SUlNR3M2UllqU1NKcjNEcS9aMWhCK1FmL0Jw?=
 =?utf-8?B?OFdkVFN6YkNDOStTZjRrL2J2eGx0dkZURHNlVHFUVzVVY1BPemVUV3c2eG12?=
 =?utf-8?B?Z3pJVExRNkx2c1M2TmhieHd6ekdQWXJ0VDB0NHN2Mkx2U3dKajNWeTlmaGFs?=
 =?utf-8?B?VWxOMkN5b1c4T2ZCamlJbWxpREswTTAydStMYUdXVXkxTElQV280K25wM3Zs?=
 =?utf-8?B?MHM3ODl2WUFtL2FzVGdzNDJWa05YVUdXTVJUOWtTZVlHMlRYY05VNXNSRThE?=
 =?utf-8?B?Uy9QUk1MMVBhWnlUeDArbGhwUm1jU0dDUUtHUFMzOExIeitQUWFNaW00V3kx?=
 =?utf-8?B?TDFrc1BMY1ZKbmtpY3pDOEU4Rkh1NlJpY2J0ajY0RlhudnJPbmF0TE0yVURq?=
 =?utf-8?B?Z2xmUXRxTVVwT091bUozd24yZ2VZRnpDazdmeC9peGlreHk1aWFndW9rZmd0?=
 =?utf-8?B?M1FqOHF5MmMyWlREdFZnak0rck1vc2VBLzY5TW14SFZYeCtqajFnb1hxeU54?=
 =?utf-8?B?a3lTNXRWa0tLYk5hNjUxLys4cGoraGtscnlFdXBUa3E2NHFjS1NZV1NNcmlP?=
 =?utf-8?B?UnJlZEtaaGhYendvOXZOa2dLeVdGWlRHR1BFcEZWMFhaZUJhTWhMbDc2VE9N?=
 =?utf-8?Q?4Dl6wDb08fvy7tyBP1u2v0lvT?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9484b461-9ad7-4315-cef8-08dda99d2dac
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2025 10:37:50.0958
 (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: 2NCFxF13U18j/2uTtEFdWdf5Q0fMTRH+FSxqhlKXKL0ZJ+hspDXRyJj+1O8qH7N0PMRmfx+XvH0CUY8gvpxmFA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4306


On 12/06/2025 10:35, Luca Fancellu wrote:
> Hi Ayan,
Hi Luca,
>
>> On 11 Jun 2025, at 15:35, Ayan Kumar Halder  wrote:
>>
>> Define prepare_selector(), read_protection_region() and
>> write_protection_region() for arm32. Also, define
>> GENERATE_{READ/WRITE}_PR_REG_OTHERS to access MPU regions from 32 to 255.
>>
>> Enable pr_{get/set}_{base/limit}(), region_is_valid() for arm32.
>> Enable pr_of_addr() for arm32.
>>
>> Signed-off-by: Ayan Kumar Halder 
>> ---
> Based on your v2 (https://patchwork.kernel.org/project/xen-devel/patch/20250606164854.1551148-4-ayan.kumar.halder@amd.com/) I was imaging something like this:
>
> diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
> index 74e96ca57137..5d324b2d4ca5 100644
> --- a/xen/arch/arm/mpu/mm.c
> +++ b/xen/arch/arm/mpu/mm.c
> @@ -87,20 +87,28 @@ static void __init __maybe_unused build_assertions(void)
>    */
>   static void prepare_selector(uint8_t *sel)
>   {
> -#ifdef CONFIG_ARM_64
>       uint8_t cur_sel = *sel;
>   
> +#ifdef CONFIG_ARM_64
>       /*
> -     * {read,write}_protection_region works using the direct access to the 0..15
> -     * regions, so in order to save the isb() overhead, change the PRSELR_EL2
> -     * only when needed, so when the upper 4 bits of the selector will change.
> +     * {read,write}_protection_region works using the Arm64 direct access to the
> +     * 0..15 regions, so in order to save the isb() overhead, change the
> +     * PRSELR_EL2 only when needed, so when the upper 4 bits of the selector
> +     * will change.
>        */
>       cur_sel &= 0xF0U;
> +#else
> +    /* Arm32 MPU can use direct access for 0-31 */
> +    if ( cur_sel > 31 )
> +        cur_sel = 0;
> +#endif
>       if ( READ_SYSREG(PRSELR_EL2) != cur_sel )
>       {
>           WRITE_SYSREG(cur_sel, PRSELR_EL2);
>           isb();
>       }
> +
> +#ifdef CONFIG_ARM_64
>       *sel = *sel & 0xFU;
>   #endif
>   }
> @@ -144,6 +152,12 @@ void read_protection_region(pr_t *pr_read, uint8_t sel)
>           GENERATE_READ_PR_REG_CASE(29, pr_read);
>           GENERATE_READ_PR_REG_CASE(30, pr_read);
>           GENERATE_READ_PR_REG_CASE(31, pr_read);
> +        case 32 ... 255:
> +        {
> +            pr->prbar.bits = READ_SYSREG(PRBAR_EL2);
> +            pr->prlar.bits = READ_SYSREG(PRLAR_EL2);
> +            break;
> +        }
>   #endif
>       default:
>           BUG(); /* Can't happen */
> @@ -190,6 +204,12 @@ void write_protection_region(const pr_t *pr_write, uint8_t sel)
>           GENERATE_WRITE_PR_REG_CASE(29, pr_write);
>           GENERATE_WRITE_PR_REG_CASE(30, pr_write);
>           GENERATE_WRITE_PR_REG_CASE(31, pr_write);
> +        case 32 ... 255:
> +        {
> +            WRITE_SYSREG(pr->prbar.bits & ~MPU_REGION_RES0, PRBAR_EL2);
> +            WRITE_SYSREG(pr->prlar.bits & ~MPU_REGION_RES0, PRLAR_EL2);
> +            break;
> +        }
>   #endif
>       default:
>           BUG(); /* Can't happen */
>
>
> Is it using too ifdefs in your opinion that would benefit the split you do in v3?

Yes. However, I understand that this is subjective. I need your and 
Michal/Julien to have an opinion here whether to go with the split 
(which means some amount of code duplication) or introduce if-defs. I 
will be happy to proceed as per your opinions.

- Ayan

>
>


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 10:42:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 10:42:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012798.1391303 (Exim 4.92)
	(envelope-from )
	id 1uPfOH-0003zP-0O; Thu, 12 Jun 2025 10:42:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012798.1391303; Thu, 12 Jun 2025 10:42:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPfOG-0003zI-U7; Thu, 12 Jun 2025 10:42:36 +0000
Received: by outflank-mailman (input) for mailman id 1012798;
 Thu, 12 Jun 2025 10:42: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 1uPfOF-0003zC-Qy
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 10:42:35 +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 f30807d1-4779-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 12:42:34 +0200 (CEST)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-450d668c2a1so13791955e9.0
 for ; Thu, 12 Jun 2025 03:42:34 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-74880896268sm1122372b3a.44.2025.06.12.03.42.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 03:42:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f30807d1-4779-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749724954; x=1750329754; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=RuAhpSmRJLYAMPFosLKtVzELzW8u013hIskDY5yVKfI=;
        b=AYg8dDkThDj6De3Gi5VkqFp9OHi0kuwSWW2nEYKIkTbeIfhGQNW5QrocLUNt9+sRyl
         Kfo0GwNUkWrt4PZsMhGD6T59swqJHec7Luv4G9f++N6URjF6xL5AYLCc0yDegIrNCnh/
         4sET17BgZirUrmAm93rWmMF+ATB1osZMAu69FRw5AOcMnLb/1eulLe8WoIKpI59nmfXy
         NyuUy79kDd+YO6p+bo1XVoAsiXxYWgpa+oqA080nU9lllarCPPxlIyetQzAi55bE2/dz
         8pMHyl0OuSdDnAsB51tRt7gBksWEVCZCiIH3R/dyT4M0XxvJF/bMqZWa9d+uG6LoXWHe
         eVlw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749724954; x=1750329754;
        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=RuAhpSmRJLYAMPFosLKtVzELzW8u013hIskDY5yVKfI=;
        b=MAEKmBy+pVLM/dcQjQlm2pyczPu/QaC1hcwcdgcoCScFmy8Ze6mInAf/+PTOZzXMZ9
         0Cwh2pHN2IyWUaH3fq/FTwMowZIyBiY2QSKJATFOIhjkqk7JT3YUDDgqjGP4xmMXZMT+
         o5hPSJmmPKuRumWTwzjpDvphfu7qqnhgD2MhpujmAtos/RCQDVX+EbDdagZkWJC7PSxY
         vDvw4PpsU5m+5h4J3RlnVEH2LItEn1GWGhIJv1Jzb1NS0PFiXA0Lmu2LW93h9FaCNZFs
         aA4fNTQBPZH616ZYkUr9K+n5K0eM12RkQgQMynUZed/tc7IZxxmtGG1ovQVsVpG+JlVw
         648A==
X-Forwarded-Encrypted: i=1; AJvYcCU7QwuYRCJkDgtkeEpEtb2wfF+qM79tU898JfWBAtwimp06+hOVgCV66FCbjkZJCfHo/Mt6f9aOJuk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxagIUUJ0uGTOP83HGH/0QD/OcG2RvocFF1q4ma5wslVBWMeL0n
	EY+cWYcR+a9RV/o4DvSLimh32etKiQAG7jIFAvHFlT0hsqkxIq56kkFtSnRJPLTjKw==
X-Gm-Gg: ASbGncvQHgnTq3mTq3/YEpSDqCIwJ1PIWSmyXiyH2BRywpLbYa7iReVA+B9+dTQt1Gm
	GM0WwNzKiDpNBC0QHN2N8BnB+DjjYIQyZ8xa9ZreqZRK1XdMi8QfHKi/C4Jn0QcyH4XEY3kL6cK
	H+B/9A8gm2osQnkJftw8ocDVDPM9MeEuPZGmQ/ti92OH67D1KIaVpBdSrLIELpbCyFNBPzzlKXI
	z3UA1phP2AzV7sGa99ZID6hmvVBhxoqwPKsqTymuqpH5uPHQDCFxYLy2ZkbaR/ea0e1tPnzkSAp
	dO4xW+LmPEAnrxzbhfjpCN90gbYQh47jXXrOnh1rklOwczE8dnahFzFRq0qosTMGLXga9ZbFgI+
	FYVqJX/9m0ANbXX8l7sVNMBdLCikpZ4exQBwLsJ0fIV1pQ0g=
X-Google-Smtp-Source: AGHT+IEz9ctytOLQjBLYvZ1MCImrzf3LXJMbBUzA47qo9HV5oCOfar0qzj1JnkDlFZIEaEyKY83EnQ==
X-Received: by 2002:a05:6000:40cf:b0:3a4:e1f5:41f4 with SMTP id ffacd0b85a97d-3a5607faa09mr2196242f8f.17.1749724953102;
        Thu, 12 Jun 2025 03:42:33 -0700 (PDT)
Message-ID: <3edeeff2-5728-46cc-9436-01e5e3cf2bd3@suse.com>
Date: Thu, 12 Jun 2025 12:42:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 06/18] xen/x86: introduce "cpufreq=amd-cppc" xen
 cmdline
To: Penny Zheng 
Cc: ray.huang@amd.com, Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-7-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: <20250527084833.338427-7-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.05.2025 10:48, Penny Zheng wrote:
> Users need to set "cpufreq=amd-cppc" in xen cmdline to enable
> amd-cppc 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-cppc", a new amd-cppc driver
> shall be registered and used. All hooks for amd-cppc driver are transiently
> missing and will be implemented in the ongoing commits.
> 
> New xen-pm internal flag XEN_PROCESSOR_PM_CPPC is introduced, to be
> differentiated with legacy XEN_PROCESSOR_PM_PX. We define
> XEN_PROCESSOR_PM_CPPC 0x100, as it is the next value to use after 8-bits wide
> public xen-pm options. All xen-pm flag checking involving XEN_PROCESSOR_PM_PX
> shall also be updated to consider XEN_PROCESSOR_PM_CPPC now.
> 
> Xen is not expected to support both or mixed mode (CPPC & legacy PSS, _PCT,
> _PPC) operations, so only one cpufreq driver gets registerd, either amd-cppc
> or legacy P-states driver, which is reflected and asserted by the incompatible
> flags XEN_PROCESSOR_PM_PX and XEN_PROCESSOR_PM_CPPC.
> 
> Signed-off-by: Penny Zheng 
> ---
> v1 -> v2:
> - Obey to alphabetic sorting and also strict it with CONFIG_AMD
> - Remove unnecessary empty comment line
> - Use __initconst_cf_clobber for pre-filled structure cpufreq_driver
> - Make new switch-case code apply to Hygon CPUs too
> - Change ENOSYS with EOPNOTSUPP
> - Blanks around binary operator
> - Change all amd_/-pstate defined values to amd_/-cppc
> ---
> v2 -> v3
> - refactor too long lines
> - Make sure XEN_PROCESSOR_PM_PX and XEN_PROCESSOR_PM_CPPC incompatible flags
> after cpufreq register registrantion
> ---
> v3 -> v4:
> - introduce XEN_PROCESSOR_PM_CPPC in xen internal header
> - complement "Hygon" in log message
> - remove unnecessary if()
> - grow cpufreq_xen_opts[] array
> ---
> v4 -> v5:
> - remove XEN_PROCESSOR_PM_xxx flag sanitization from individual driver
> - prefer ! over "== 0" in purely boolean contexts
> - Blank line between non-fall-through case blocks
> - add build-time checking between internal and public XEN_PROCESSOR_PM_*
> values
> - define XEN_PROCESSOR_PM_CPPC with 0x100, as it is the next value to use
> after public interface, and public mask SIF_PM_MASK is 8 bits wide.
> - as Dom0 will send the CPPC/Px data whenever it could, the return value shall
> be 0 instead of -ENOSYS/EOPNOTSUP when platform doesn't require these data.
> ---
>  docs/misc/xen-command-line.pandoc         |  7 ++-
>  xen/arch/x86/acpi/cpufreq/Makefile        |  1 +
>  xen/arch/x86/acpi/cpufreq/amd-cppc.c      | 68 +++++++++++++++++++++++
>  xen/arch/x86/acpi/cpufreq/cpufreq.c       | 63 ++++++++++++++++++++-
>  xen/arch/x86/platform_hypercall.c         | 13 ++++-
>  xen/drivers/acpi/pmstat.c                 |  3 +-
>  xen/drivers/cpufreq/cpufreq.c             | 18 +++++-
>  xen/include/acpi/cpufreq/cpufreq.h        |  6 +-
>  xen/include/acpi/cpufreq/processor_perf.h |  3 +
>  xen/include/public/sysctl.h               |  1 +
>  10 files changed, 175 insertions(+), 8 deletions(-)
>  create mode 100644 xen/arch/x86/acpi/cpufreq/amd-cppc.c

This patch does quite a bit more than what the subject suggests it means to
do; please consider adjusting.

> +int __init amd_cppc_register_driver(void)
> +{
> +    if ( !cpu_has_cppc )
> +    {
> +        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_CPPC;
> +        return -ENODEV;
> +    }
> +
> +    return cpufreq_register_driver(&amd_cppc_cpufreq_driver);

Isn't this premature? I fear in particular that some of the hooks, which
are still all NULL, might have a way of getting invoked.

> @@ -157,7 +162,63 @@ static int __init cf_check cpufreq_driver_init(void)
>  
>          case X86_VENDOR_AMD:
>          case X86_VENDOR_HYGON:
> -            ret = IS_ENABLED(CONFIG_AMD) ? powernow_register_driver() : -ENODEV;
> +            unsigned int i;
> +
> +            if ( !IS_ENABLED(CONFIG_AMD) )
> +            {
> +                ret = -ENODEV;
> +                break;
> +            }
> +            ret = -ENOENT;
> +
> +            for ( i = 0; i < cpufreq_xen_cnt; i++ )
> +            {
> +                switch ( cpufreq_xen_opts[i] )
> +                {
> +                case CPUFREQ_xen:
> +                    ret = powernow_register_driver();
> +                    break;
> +
> +                case CPUFREQ_amd_cppc:
> +                    ret = amd_cppc_register_driver();
> +                    break;
> +
> +                case CPUFREQ_none:
> +                    ret = 0;
> +                    break;
> +
> +                default:
> +                    printk(XENLOG_WARNING
> +                           "Unsupported cpufreq driver for vendor AMD or Hygon\n");
> +                    break;
> +                }
> +
> +                if ( ret != -ENODEV )
> +                    break;

This, I think, needs some commenting. It's not quite clear why we shouldn't
try the next option if registration failed with other than -ENODEV.

> +            }
> +
> +            /*
> +             * After cpufreq driver registeration, XEN_PROCESSOR_PM_CPPC
> +             * and XEN_PROCESSOR_PM_PX shall become exclusive flags.
> +             */
> +            if ( !ret && i < cpufreq_xen_cnt )
> +            {
> +                switch ( cpufreq_xen_opts[i] )
> +                {
> +                case CPUFREQ_amd_cppc:
> +                    xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
> +                    break;
> +
> +                case CPUFREQ_xen:
> +                    xen_processor_pmbits &= ~XEN_PROCESSOR_PM_CPPC;
> +                    break;
> +
> +                case CPUFREQ_none:
> +                default:

What's the point of the separate "case" label here?

> +                    break;
> +                }
> +            }

Why does this pruning of xen_processor_pmbits sit in the AMD-only code path?
Iirc earlier on you had it in the *_register_driver() themselves, and my
request was to put it in a central, generic place. It's central now, but not
generic (and this way it could as well have remained in *_register_driver()).

> --- a/xen/arch/x86/platform_hypercall.c
> +++ b/xen/arch/x86/platform_hypercall.c
> @@ -539,9 +539,12 @@ ret_t do_platform_op(
>          case XEN_PM_PX:
>              if ( !(xen_processor_pmbits & XEN_PROCESSOR_PM_PX) )
>              {
> -                ret = -ENOSYS;
> +                ret = 0;
>                  break;
>              }
> +            /* Xen doesn't support mixed mode */
> +            ASSERT(!(xen_processor_pmbits & XEN_PROCESSOR_PM_CPPC));
> +
>              ret = set_px_pminfo(op->u.set_pminfo.id, &op->u.set_pminfo.u.perf);
>              break;

I don't see how this change relates to the purpose of the patch. From the
description (and in the absence of a code comment) it also doesn't become
clear at all why that change of return value would be needed (and would be
correct to do). From comments I gave on earlier versions of this series, I
think I can guess what this is about, but such shouldn't be slipped in
silently.

> @@ -573,6 +576,14 @@ ret_t do_platform_op(
>          }
>  
>          case XEN_PM_CPPC:
> +            if ( !(xen_processor_pmbits & XEN_PROCESSOR_PM_CPPC) )
> +            {
> +                ret = 0;
> +                break;
> +            }

As per above, this yielding success needs justifying.

> @@ -94,6 +95,8 @@ static int __init handle_cpufreq_cmdline(enum cpufreq_xen_opt option)
>  {
>      int ret = 0;
>  
> +    /* Do not occupy bits reserved for public xen-pm */
> +    BUILD_BUG_ON(MASK_INSR(XEN_PROCESSOR_PM_CPPC, SIF_PM_MASK));

This looks like an abuse of MASK_INSR(). Why not simply

    BUILD_BUG_ON(XEN_PROCESSOR_PM_CPPC & SIF_PM_MASK);

?

Also please separate this by a blank line from what follows, or perhaps
even better ...

> @@ -105,6 +108,10 @@ static int __init handle_cpufreq_cmdline(enum cpufreq_xen_opt option)
>      cpufreq_xen_opts[cpufreq_xen_cnt++] = option;
>      switch ( option )
>      {
> +    case CPUFREQ_amd_cppc:
> +        xen_processor_pmbits |= XEN_PROCESSOR_PM_CPPC;
> +        break;

... move it here.

> @@ -172,6 +179,13 @@ 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 ( IS_ENABLED(CONFIG_AMD) && choice < 0 &&
> +                  !cmdline_strcmp(str, "amd-cppc") )
> +        {
> +            ret = handle_cpufreq_cmdline(CPUFREQ_amd_cppc);
> +            if ( arg[0] && arg[1] )
> +                ret = amd_cppc_cmdline_parse(arg + 1, end);
> +        }

See Jason's comment on the earlier patch.

> --- a/xen/include/acpi/cpufreq/processor_perf.h
> +++ b/xen/include/acpi/cpufreq/processor_perf.h
> @@ -5,6 +5,9 @@
>  #include 
>  #include 
>  
> +/* Internal ability bits */
> +#define XEN_PROCESSOR_PM_CPPC   0x100

The comment wants extending, to have a reference to the other XEN_PROCESSOR_PM_*
bits and perhaps also to SIF_PM_MASK. In fact the BUILD_BUG_ON() that I commented
on above could be replaced by

#if XEN_PROCESSOR_PM_CPPC & SIF_PM_MASK
# error "..."
#endif

right here.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 10:46:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 10:46:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012804.1391314 (Exim 4.92)
	(envelope-from )
	id 1uPfSE-0004ik-F2; Thu, 12 Jun 2025 10:46:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012804.1391314; Thu, 12 Jun 2025 10:46: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 1uPfSE-0004id-CD; Thu, 12 Jun 2025 10:46:42 +0000
Received: by outflank-mailman (input) for mailman id 1012804;
 Thu, 12 Jun 2025 10:46: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 1uPfSD-0004iX-H1
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 10:46:41 +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 850b54c1-477a-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 12:46:39 +0200 (CEST)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-450cea01b9cso3735285e9.0
 for ; Thu, 12 Jun 2025 03:46:39 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-4532e241b70sm16394115e9.18.2025.06.12.03.46.38
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Jun 2025 03:46:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 850b54c1-477a-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749725199; x=1750329999; 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=sy0YOumkYq3+7URylCUGUpdoND9CFrD93Btzp8FuStE=;
        b=cedCOZmknPIY9EpPhLpB4zJnKSpPPVxZ6EK03yO9l++gbiPkdYyjapA2tYALTriwSQ
         rYBp0lyDKZOWVPkc+nAaOHK/pF57VEyEaodCmmRxtWcstvphDT1t2MYDDcgeV6gplPh/
         PoKd4RcvVYhbHIJoMyamekX4M/b41veWd4ce8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749725199; x=1750329999;
        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=sy0YOumkYq3+7URylCUGUpdoND9CFrD93Btzp8FuStE=;
        b=VYhcf5udWxCLlgqKrzGEjxTdAPkOd3BKLc6rrEFWpi50OT/umWT6W8is6vUTIetzuL
         3N4nD9QgW+28VK/3+/uyZbpJuTIJ/h0FzP4yVU91Lu6onK9xcC8pjjHmRmgFjKXVzrKL
         wGZXt2uaGCJ9W3Qgx4ElgJu4gmquuPxp0nn4hwkEA4aNH8PxCFq7SjSGdWN6gsJzuPMW
         Un2vA/pyw85FhB116GClkzfS7PKbHLAiA4ocDt2h9zCEwe6hsdGWu9uL/Imt7vQ1myXP
         omK+NdyxVrQamhxUIjimT81J6utJLdHlMTd/CB5i//aJvQpw823Fykf9W8fOY1OZoLTt
         YaKw==
X-Forwarded-Encrypted: i=1; AJvYcCV19wbJ5lkyxxR5RslYZaX3kA/PCssyi5gWMXNBYlACifu4vAUdYH58kfZx8wnI+Sxc3x8gVpZRBiI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyAjIycf5ppuH8CdFvF3W61Pcrv+LDS8LLpOWq31KkuXwlufM9l
	SIMOXLBJcCk3lXmYdztYhpGJdesls2TKuVFnhle1YFU6XXh5EJoXZOS/CtI1MtAbUQA=
X-Gm-Gg: ASbGncvJ3npc4I/EIEt56ZdWB6xLhE1aJ/WI4AZKNGBoiu1D1rmpr0tVqWxnPxtwkyu
	AY1Y3ysm6ayE1vG8ZGvwCMNAeDR/T19h5Y2V0PSYlQdqXi9oz7xdoDckYLGK/HcupvgMpkkCrQq
	b+WztzCY9Yw3c2O+UUR5l0U1padDvPch+WV4fUp1MY+h9DZInPFZeARkpu7yCkXctG2O3YgN1ri
	t1JT4coDXhK55uMnAiDcRAHc+htmNdb2mZ5BYcV/Xhkyd5LUQLgi65Pku5WbbAVmYBV2iK0FEg4
	p+euWIFWAg4zwQRsD1uKXMUkHKfsDG33nzHfF2HmNROfScbA/jrZu7qVFzA6GWoGq4Bh56f5jsV
	Mp+FUpG3mAMvse48nsIkXN0Nh36Z41Q==
X-Google-Smtp-Source: AGHT+IEfPIBSnzzhzGh6QQjw7WzC1343Pnn7hF1G2RxoncUJcV6wDw0KsDtDbPLjLXBmh4wcDSHFAA==
X-Received: by 2002:a05:600c:3487:b0:442:cd03:3e2 with SMTP id 5b1f17b1804b1-4532b8c566fmr32105185e9.2.1749725198674;
        Thu, 12 Jun 2025 03:46:38 -0700 (PDT)
Date: Thu, 12 Jun 2025 12:46:37 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Andrew Cooper ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 1/8] x86/pdx: simplify calculation of domain struct
 allocation boundary
Message-ID: 
References: <20250611171636.5674-1-roger.pau@citrix.com>
 <20250611171636.5674-2-roger.pau@citrix.com>
 <6abadf32-836f-45fb-bb3a-3afdf97e157b@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <6abadf32-836f-45fb-bb3a-3afdf97e157b@suse.com>

On Thu, Jun 12, 2025 at 11:03:21AM +0200, Jan Beulich wrote:
> On 11.06.2025 19:16, Roger Pau Monne wrote:
> > @@ -498,14 +474,15 @@ struct domain *alloc_domain_struct(void)
> >       * On systems with CONFIG_BIGMEM there's no packing, and so there's no
> >       * such restriction.
> >       */
> > -#if defined(CONFIG_BIGMEM) || !defined(CONFIG_PDX_COMPRESSION)
> > -    const unsigned int bits = IS_ENABLED(CONFIG_BIGMEM) ? 0 :
> > -                                                          32 + PAGE_SHIFT;
> > +#if defined(CONFIG_BIGMEM)
> > +    const unsigned int bits = 0;
> >  #else
> > -    static unsigned int __read_mostly bits;
> > +    static unsigned int __ro_after_init bits;
> >  
> >      if ( unlikely(!bits) )
> > -         bits = _domain_struct_bits();
> > +         bits = flsl(pfn_to_paddr(pdx_to_pfn(
> > +             1UL << (sizeof(((struct page_info *)NULL)->v.inuse._domain) * 8))))
> > +             - 1;
> 
> While Andrew did point you at sizeof_field(), we can have this even less verbose
> by utilizing that frame_table is of the right type and (almost) globally in scope.
> 
> Further, why use pfn_to_paddr()?
> 
>          bits = flsl(pdx_to_pfn(1UL << 
>                                 (sizeof(frame_table->v.inuse._domain) * 8))) +
>                 PAGE_SHIFT - 1;

I've introduced and used pdx_to_paddr(), which I think it's more
natural.  We already had a paddr_to_pdx() which was missing it's
bidirectional equivalent.  It's now:

         bits = flsl(pdx_to_paddr(1UL << (sizeof_field(struct page_info,
                                                       v.inuse._domain) * 8)))
                - 1;

> However, it further feels like this was off by one; we had similar issues over
> time in several places. There potentially being a gap between one less than
> the PDX used here and that very PDX, don't we need to calculate based on the
> "one less" value here? Hmm, there being a gap means no allocation would
> succeed for the precise value of "bits" (in the mask-compression scheme), so
> functionally all would be fine. Yet just to avoid setting a bad precedent I
> think we'd still be better off using
> 
>          bits = flsl(pdx_to_pfn((1UL << 
>                                  (sizeof(frame_table->v.inuse._domain) * 8)) -
>                                 1)) + PAGE_SHIFT;
> 
> If one would log the value of bits, the result would then also be less
> confusing in (at least) the mask-compression scheme.


Is the above correct tough?

Take for example the hypothetical case where pdx_to_pfn() returns
0x10.  Then flsl() will return 5 (let's leave the PAGE_SHIFT
adjustment out for the example here).  The allocation bit width would
be off-by-one, because allocating using a bit width of 5 would also
allow 0x11 to be allocated, and that won't be correct.

I think we need to get the bit width of the next pdx (so the
non-inclusive end of the range), and then subtract 1 from it,
otherwise the allocation bit width is possibly off-by-one.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 10:48:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 10:48:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012823.1391324 (Exim 4.92)
	(envelope-from )
	id 1uPfTu-0005JG-SW; Thu, 12 Jun 2025 10:48:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012823.1391324; Thu, 12 Jun 2025 10: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 1uPfTu-0005J9-P9; Thu, 12 Jun 2025 10:48:26 +0000
Received: by outflank-mailman (input) for mailman id 1012823;
 Thu, 12 Jun 2025 10:48: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 1uPfTs-0005Iy-Qp
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 10:48:24 +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 c2eba838-477a-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 12:48:23 +0200 (CEST)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-3a4f379662cso710998f8f.0
 for ; Thu, 12 Jun 2025 03:48:23 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a561b65cbfsm1608565f8f.97.2025.06.12.03.48.21
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Jun 2025 03:48:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c2eba838-477a-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749725302; x=1750330102; 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=Hpv4aUJj4Q2E90rTp3mzKxtHiHmPWX/m8DncdVkjZo4=;
        b=cuRIsS8YtqZE2tEXOOz3fBGGmGDjOGYt6q+LYar+2c4ieYm7qPKPQ2aOXkD1q6maWq
         +WQznVx6/GVaRtFaJZ9DaNaeU1MpCRQsv1bhH7bdn4nhAokGaZWR89340enuNPRqwMsb
         1OJDr82jgu5vdlkuLGatWrly+Ci5C1HA8foEM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749725302; x=1750330102;
        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=Hpv4aUJj4Q2E90rTp3mzKxtHiHmPWX/m8DncdVkjZo4=;
        b=pHYGJa9RlNybhqaQruaiqiACbewlo3ApAk8RuPnE2HgKbgjkkAEEuTow7yhaMD1WdY
         ddBwWSOnPvjmYfuEDJ1pift1uqX/8OEQGyV0g17NG13MEtssMGyHqHcwOzN2i753LauY
         7f+zGooGi/9K/qJ5Pq+0VSPJPJYD0HLKXlon6F52W/OCJ3EE8Fwz4RPjZNsOWonQ06Or
         s7gELouBrDuw+e0JbClK9v7CDiA2TZcY62fs2EjVGN6dEP3ORuyPBL8b11byyKVCLMtj
         fPBooubv1bY3pAM8nttNphLyk6XKrmPQH9RNDPGO6fx6J7bMbUaVH4VQFfiSM8L+SWu0
         0H9A==
X-Forwarded-Encrypted: i=1; AJvYcCXV0pFnOBcuhiitUUOj0gtvOAD9SOVU/mVoHuoSqfGuxhQJzNO9YzaJudt2rjXzKiXRfkk9+061PiM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyRcVgyjHPQvvdjyuKSVmPSN5BdfcHFaTMX93kmLZF7U2UtEqGh
	6OlfeTL7Mx+rb61OYBwguSSHPHSEY3x0t5S3uXOdoSTap6usmz8p7yfd09jc2SoC5C8=
X-Gm-Gg: ASbGncv8B1HtsdMGUibvTIDJ1qHO+jN/h2InYwaKS3LeW0UmUvfpOgmreN6V2WwWf1d
	R3jqK/6xbTJx82VuwrGltrMD+809BHNvYl1tjgss1L3twxx/pSGl3AZBkkFkyUt1pLfqLK8ik2l
	gdba++USIMYENLgQ3m2JMG6PIhyjJmoABTyWQCT1Zikd/uqzFeVK/YnG4hswwiMBRzsfsK8NiYS
	8YSiTarYCiaLWkHXEmsvp8vI84nSHxvFb/v5L1f0PO6DeaIZs+/0ejbTf60j6T7f/W6F1hamjBa
	Eo8mDPfpNCaOQLybwZLv29S6SdnPRw6QwIstEKheC15XctnorZKHurYzli97AHTmeLsAT/x8uyz
	wUem6FSS1Tcy7NFlC016n/hTx7DNegg==
X-Google-Smtp-Source: AGHT+IE9aJisEAyERP6M5GBY8SaASbcQDPSGYQnG/ch9mTGl6LCaeSva/uj//Cofzw4hJAQhgQxokQ==
X-Received: by 2002:a05:6000:25c3:b0:3a4:f2ed:217e with SMTP id ffacd0b85a97d-3a5614c2053mr2060199f8f.42.1749725302494;
        Thu, 12 Jun 2025 03:48:22 -0700 (PDT)
Date: Thu, 12 Jun 2025 12:48:20 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 2/8] pdx: introduce function to calculate max PFN based
 on PDX compression
Message-ID: 
References: <20250611171636.5674-1-roger.pau@citrix.com>
 <20250611171636.5674-3-roger.pau@citrix.com>
 <9e7925c4-3695-4320-8552-4ee0e39350e4@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <9e7925c4-3695-4320-8552-4ee0e39350e4@suse.com>

On Thu, Jun 12, 2025 at 11:11:14AM +0200, Jan Beulich wrote:
> On 11.06.2025 19:16, Roger Pau Monne wrote:
> > This is the code already present and used by x86 in setup_max_pdx(), which
> > takes into account the current PDX compression, plus the limitation of the
> > virtual memory layout to return the maximum usable PFN in the system,
> > possibly truncating the input PFN provided by the caller.
> > 
> > This helper will be used by upcoming PDX related changes that introduce a
> > new compression algorithm.
> > 
> > Signed-off-by: Roger Pau Monné 
> > ---
> >  xen/arch/x86/setup.c  | 19 ++-----------------
> >  xen/common/pdx.c      | 25 +++++++++++++++++++++++++
> >  xen/include/xen/pdx.h |  8 ++++++++
> >  3 files changed, 35 insertions(+), 17 deletions(-)
> 
> This is all fine for x86, but on Arm you introduce unreachable code, which
> Misra dislikes. Yet then it feels like it's wrong anyway that the function
> isn't used there.

I was also concerned regarding why ARM doesn't have an equivalent
function.  Is the frametable there supposed to cover up to the maximum
physical address?  In which case there's likely no need for any PDX
compression in the first place?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 10:50:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 10:50:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012829.1391334 (Exim 4.92)
	(envelope-from )
	id 1uPfVY-0006ma-5d; Thu, 12 Jun 2025 10:50:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012829.1391334; Thu, 12 Jun 2025 10:50: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 1uPfVY-0006mT-2r; Thu, 12 Jun 2025 10:50:08 +0000
Received: by outflank-mailman (input) for mailman id 1012829;
 Thu, 12 Jun 2025 10:50: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 1uPfVW-0006gJ-DQ
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 10:50:06 +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 fef90128-477a-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 12:50:03 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3a54700a463so487744f8f.1
 for ; Thu, 12 Jun 2025 03:50:03 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a56199b23bsm1637219f8f.39.2025.06.12.03.50.02
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Jun 2025 03:50:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fef90128-477a-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749725403; x=1750330203; 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=Dn/4vU6e0a7VCrORAuqi9+VNzy6T/ohj4+QcDrDzcSc=;
        b=v25W3dP4SCljlIk/UicnvgmaUA+hvk6cIkqYu0c/K/tKWQ/PaaF3zIIq9b2exShtBO
         mwIDpTKEheUp3gneTi7iOQMTG9L5wgMPULlvGcXUJ72Zliqp6QW0CtpcFV1nF/e0GqEG
         +UOB7L4oq2hKLB8/yUmgkeNi0C4nFf/GtZvtI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749725403; x=1750330203;
        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=Dn/4vU6e0a7VCrORAuqi9+VNzy6T/ohj4+QcDrDzcSc=;
        b=aFoYP+S5v9FBcm112aKCXrsZbxlXlB3N/Zh6yFEnoc1EoCSN19JWb5eL++VHBoJP2H
         ys2yBLmI0saxERJzX77/WLT8fjokGpY7NY6MDvFi5NNbXkAvpTNjkfet2ug7G3ro5Ndm
         PzlvsVCDPDGBa97HlzP6lt5mFztTnQYqO3Ubmq30nDqIItlLHQdcDxNh2jB/XqrSIxUw
         5JsxGUFuud/5OX73k5Vi/r3jgvxN0Vx6kinG1cDMwHaVs9/X4zqGK/SHey6SpTlwmyT0
         vBVVoT3PGdIeSJEtIGIbzPIZFMUc9RuaIDXSDJt3NtoH8YWmFEMCBbu7HcG5xUKc1If2
         86ww==
X-Forwarded-Encrypted: i=1; AJvYcCV3v8vK22BL0xb3pgs/g9Lwk8+g4RNk/usOBXrgaXS1xPxt+xxu+QFGIQvqU0uSDAgf6bZT7PNxVow=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwGHJNFtF2kmdjrkA1mqDJ/a2EwMLrmUYELvz3BKdrWDUHxRUfD
	E6P3RX4slRMHIqV28IISCHYbBMd1FLP7lZRnpfJ0JBgUML18wJ50sxcq+1mgLWiSRZg=
X-Gm-Gg: ASbGncvQPb1Rb6oIWBr94prmLOwp706ZxS6Z3a8cIg7CFVawL2oEX9eXr3BxU+l8Rij
	O9AUzAfOzchPb90UAx8hO25oVq/EV7midE4oS7mY4eYdJV0a7iNhV4OW0C0ikp9rWPQf0tTeM/D
	iNZoMlnp/G8//g81D7X767GWav+jS8AbizuvTm0ZGY8F2tRESvjOGgVJ5PzKNSH6epXHd9fpwjK
	iAfxjMv/sc3kl/F7dkwn0IoI+bH5S6Pc18SKNxTOwft+xI4UAqe/OY7ZMHBF9ycKlNUxqePzkgz
	yCYovVYQUIkUTtwW1kGAxa78XfZMF2lG1jJQyq83h5+HG8kjZSQf0WJKzQpFd8AiRwPEgDq5wI+
	0NsEOmSp6/u9dWnvl5JIMAkdIe4Cq2A==
X-Google-Smtp-Source: AGHT+IE52o78Y2Irnx5FuPYQjfxDTExsSKUTRK0j6o83vJaYMQxm73xWIejQSXahvtxhkiWfos8QMA==
X-Received: by 2002:a05:6000:290e:b0:3a3:7117:1bba with SMTP id ffacd0b85a97d-3a5608ca301mr2695082f8f.24.1749725403299;
        Thu, 12 Jun 2025 03:50:03 -0700 (PDT)
Date: Thu, 12 Jun 2025 12:50:02 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Andrew Cooper ,
	Anthony PERARD ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 4/8] pdx: provide a unified set of unit functions
Message-ID: 
References: <20250611171636.5674-1-roger.pau@citrix.com>
 <20250611171636.5674-5-roger.pau@citrix.com>
 <46fb8be4-2562-45b5-a2da-0c7c741f227f@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <46fb8be4-2562-45b5-a2da-0c7c741f227f@suse.com>

On Thu, Jun 12, 2025 at 10:32:17AM +0200, Jan Beulich wrote:
> On 11.06.2025 19:16, Roger Pau Monne wrote:
> > --- a/xen/arch/arm/setup.c
> > +++ b/xen/arch/arm/setup.c
> > @@ -255,6 +255,10 @@ void __init init_pdx(void)
> >  {
> >      const struct membanks *mem = bootinfo_get_mem();
> >      paddr_t bank_start, bank_size, bank_end;
> > +    unsigned int bank;
> > +
> > +    for ( bank = 0 ; bank < mem->nr_banks; bank++ )
> > +        pfn_pdx_add_region(mem->bank[bank].start, mem->bank[bank].size);
> 
> In patch 6 you touch all these call sites again - why not add the 3rd
> parameter / argument in this patch right away?

It's not consumed for the PDX mask compression, but I can indeed add
the extra parameter here.


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 10:51:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 10:51:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012835.1391344 (Exim 4.92)
	(envelope-from )
	id 1uPfX3-0007j7-FM; Thu, 12 Jun 2025 10:51:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012835.1391344; Thu, 12 Jun 2025 10: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 1uPfX3-0007j0-CV; Thu, 12 Jun 2025 10:51:41 +0000
Received: by outflank-mailman (input) for mailman id 1012835;
 Thu, 12 Jun 2025 10: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 1uPfX2-0007iu-Hj
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 10:51:40 +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 3829f894-477b-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 12:51:39 +0200 (CEST)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-450ce671a08so4510745e9.3
 for ; Thu, 12 Jun 2025 03:51:39 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a561b4bac4sm1606998f8f.74.2025.06.12.03.51.38
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Jun 2025 03:51:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3829f894-477b-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749725499; x=1750330299; 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=zm4D+RVcWaiwl1TrPi8KZVeHXJ8qL9r8IMWFbqSI1bI=;
        b=F68oZiN24UVlgh2XX+CMEXt1JOS4pLr9IBwhAUnR6JNaYnVkb/Yp/To58s0URU7UU3
         FqA7JYUFp6xh+kytrYpOWin4ks7Elnw5dJeYHp/c8a+csJmMBeRW90ar/iNEeSEnExXk
         Oa5w2b4rVLkBNZdbWUeCLFBJozo1836nA2Svc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749725499; x=1750330299;
        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=zm4D+RVcWaiwl1TrPi8KZVeHXJ8qL9r8IMWFbqSI1bI=;
        b=FZBnVH52jzWg51DdhHvOndqqzEcnG7XV9aGyifpC9ks/e+/9742awx2chVAdoKjnWl
         aQZy3vyX6w4iYzVFSz6UaHl80xm0ocLMlfPNXUnZ4YSB53kfCUZm527KTM3IzGNYCeb3
         uaE/V2zdSPF+PCs5v5emQNXADsjJk8lXlIOEcaPvwVBLR/UDTYeV+7kTzJ5kqIgREU9a
         D4raj3KTO7h3lmiRhcugDTV5mp8CsjXVx/4e0jqmR7joLqeKA/lmNoXEkPdsYm4Gqmtf
         D/Et5eOE6L03MWmTY63zdyT6txGB7N4UOD6lYfjY4Gnt1MC0WKO2c0WtQqEyWguisbcF
         nY6g==
X-Forwarded-Encrypted: i=1; AJvYcCUUQEk2hOs4G5fOD4/f0iUoFzEDJwf1lygBRWY76I0OQcIgDRnNbLSw11oLfE/MdnexM0vC/+yKB/o=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzf7GUydRqySaoaDnic9A5dJ9IP6HKTgU1uQC5dyoE6bShT+oo8
	yC1wL8DwkFd0+KPvuZOJviyMLThiz8+UrJ5Bkrnykv7+D1P8ntKCT1l6kZNxN8Apqnw=
X-Gm-Gg: ASbGncueRGfX1Q38xJcqhoINmzO8eP+5ukJY5cc/osan7fqY838rJnd/2yhdlTuS+sw
	QgTuWdssNjDB5GCEDfETxpaA7xuX0sXVCgrKpuTKR5/s1xpYW9dC7q8yZpoPV0IbreJbB+Bte6+
	k5ZXO/1pkBoBsgD5IJ/tH9CAQJG/4+WzsCODYx7DZ2jf/NVMuaEonkmz/LVyH3K1ausEYsjZa4U
	e+F/YfrWirw1xzE+9H1aLj5e/AvUubr/W8sAEIwOVnkFdoMl5+gp0/x4CbkFlk2gybX2+p0udAg
	YzgOhUBa6YqI5bNuoYxwduY33GeJ4Cr9lVf7OIl88wm3VOesVoGGsFuAzzujezljF0sLBT9Ybl0
	xtskQNIIWmWBtvZjwhb6KHfH66kGiFg==
X-Google-Smtp-Source: AGHT+IEzmb7KffDjEFlFz+b4Gz4b90xImAp4nWPoykROPuCzwuscM+aaxSvb5V2B+aGdEBd1ovQ/UA==
X-Received: by 2002:a05:600c:c490:b0:453:b1c:442a with SMTP id 5b1f17b1804b1-4532d317892mr20499515e9.27.1749725499297;
        Thu, 12 Jun 2025 03:51:39 -0700 (PDT)
Date: Thu, 12 Jun 2025 12:51:38 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Andrew Cooper ,
	Anthony PERARD ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 4/8] pdx: provide a unified set of unit functions
Message-ID: 
References: <20250611171636.5674-1-roger.pau@citrix.com>
 <20250611171636.5674-5-roger.pau@citrix.com>
 <84080c88-b68f-4ab3-8b69-a3e45e9c74d9@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <84080c88-b68f-4ab3-8b69-a3e45e9c74d9@suse.com>

On Thu, Jun 12, 2025 at 10:36:36AM +0200, Jan Beulich wrote:
> On 11.06.2025 19:16, Roger Pau Monne wrote:
> > @@ -80,6 +81,39 @@ unsigned long get_max_pfn(unsigned long top_pfn)
> >      return pdx_to_pfn(pdx - 1) + 1;
> >  }
> >  
> > +#ifndef CONFIG_PDX_NONE
> > +
> > +#ifdef CONFIG_X86
> > +# include 
> > +# define MAX_PFN_RANGES E820MAX
> > +#elif defined(CONFIG_HAS_DEVICE_TREE)
> > +# include 
> > +# define MAX_PFN_RANGES NR_MEM_BANKS
> > +#else
> > +# error "Missing architecture maximum number of RAM ranges"
> > +#endif
> > +
> > +/* Generic PFN compression helpers. */
> > +static struct pfn_range {
> > +    unsigned long base, size;
> > +} ranges[MAX_PFN_RANGES] __initdata;
> > +static unsigned int __initdata nr;
> 
> One other remark / nit: For my taste, "nr" isn't a suitable name for a static.
> It's too short, and hence the risk is too high that some function would add a
> local aliasing this one.

Is nr_ranges enough to avoid aliasing?  Otherwise I could rename
ranges to pfn_ranges, and nr to nr_pfn_ranges.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 11:11:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 11:11:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012868.1391361 (Exim 4.92)
	(envelope-from )
	id 1uPfph-0002aq-1i; Thu, 12 Jun 2025 11:10:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012868.1391361; Thu, 12 Jun 2025 11:10:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPfpg-0002aj-VC; Thu, 12 Jun 2025 11:10:56 +0000
Received: by outflank-mailman (input) for mailman id 1012868;
 Thu, 12 Jun 2025 11:10: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 1uPfpf-0002ad-F9
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 11:10:55 +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 e7452c4d-477d-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 13:10:53 +0200 (CEST)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-ad56cbc7b07so132280066b.0
 for ; Thu, 12 Jun 2025 04:10:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e7452c4d-477d-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749726652; x=1750331452; 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=9nBrpMK9zZeZHFNOhk7Yg3FOCL/mJbGGTtA0TEp4ISs=;
        b=kRCeEXcxL7MBg+hY/9JszHsWJUfWhRVQQdjPh3hgdn1eViGPuvLqq8lJeaKqIKLQA5
         ASkPQnKNtF1V7XOKQK4izHqyiKC0ka191/uq9iYSgk3ox58r4mG3ttcSEOXvYY1XNL09
         wVvXD/OjF4laUDlB88k2OZQ4Fa49pd08Zfa9ODqn/G75REnMx7SYyL/VSSe9mJZMNrU0
         d8gJ0fD7Kj2NhXgJQs3LqeIadnp9sgEwd+rxOAwbx82XeUmQOa6GD06U7QQc6ZxrQHQO
         fZtzaOxngVlKOmYlgoNCGFqzHE111n/DJowM1mfiSHMSq8qsqRmsDzva2hzgpKvOWoY2
         UraQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749726652; x=1750331452;
        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=9nBrpMK9zZeZHFNOhk7Yg3FOCL/mJbGGTtA0TEp4ISs=;
        b=Ybm5wQfmB7c82A4G9AjlcKoTtBwgVbPjHQtWRAneAc68Yo+nl6JAHMw1NamFaeOSzy
         g0QUb3Hk4fFr1daC5Xz9su6lcd6/joDrXVmGnR2I2I8znG6i4tQ6AYevGuuNQUjoxYi0
         c2i5T71BvvCXhwMdGvWGwnUlZjD56mM9aSXFPTv4fE0iBexT6d8YknJK53RUlA8qpKQm
         eoHv5L2JPjKfreP3LKkBvwl3hn18p608TrmhpQKKJT7xpM+l+HErG0DN4A5xk7jkzsHu
         lZ/oRyRD8GMTevdzJMPu7xbm7l9/1lCRZciyaH2OCRvEwgPjBP8e3XPMwvHjvY7xf0gI
         qs5Q==
X-Forwarded-Encrypted: i=1; AJvYcCUKs4uaj3G2LIN1JSwsry3TApBIs8JlhyNPXQye5DoQ/Qp5VwFoR558GLTgWlzGAa8alSrhTrFZHQ0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwfKZmEjml+vwVpbbDgALmEb19+JGzqsNXl16IMrIa4cLDj3fWM
	iK5oO5aYMcjMKuKKFByOvL1erx5q8bs2qlPGGmQKWHT+zzpiuW5JXCsCqwqhuVDG9M7nRHH5Dtp
	Y8kEM19+paFc3DVMcH96USJpLBGrgUvU=
X-Gm-Gg: ASbGncuQP1CbohDbeYhzAMFq0UmUxLIdo+rMoX7+GpzlnzqxlDluLqU2Hiko7xb9Ims
	Bu6hyB3MRb2WlPrlNuffBcCigbenr6hJEosggukLOJd4/17ICiLr46ZOYWQuBAzRufV9hpsL4wf
	Hse0yyrJXeTRhvuMN0TkduF8rnoZiGh1xcxCJREST6Xe8=
X-Google-Smtp-Source: AGHT+IFrX17XfYVkjVnepz8BihCrbdN9elHb1a1FwyoMbX0yLjH2EltV5lWsECJ7oLshTrIE21PMDORFUypei4zXNLs=
X-Received: by 2002:a17:907:980f:b0:ad8:a515:767f with SMTP id
 a640c23a62f3a-adea9464061mr258576566b.51.1749726651742; Thu, 12 Jun 2025
 04:10:51 -0700 (PDT)
MIME-Version: 1.0
References: <20250612093228.7655-1-chengzhenghan@uniontech.com> <84b14425-03e4-42be-8bd5-9bc010ebecda@suse.com>
In-Reply-To: <84b14425-03e4-42be-8bd5-9bc010ebecda@suse.com>
From: Andy Shevchenko 
Date: Thu, 12 Jun 2025 14:10:15 +0300
X-Gm-Features: AX0GCFubP_i495cQIkoSGfjK4G9pwjz7TYfQyvgZfj4JA8pwuaopIL7tecp4u7I
Message-ID: 
Subject: Re: [PATCH] x86: Fix build warnings about export.h
To: Juergen Gross 
Cc: Zhenghan Cheng , tglx@linutronix.de, mingo@redhat.com, 
	bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, 
	mario.limonciello@amd.com, yazen.ghannam@amd.com, jpoimboe@kernel.org, 
	tony.luck@intel.com, jarkko@kernel.org, bhelgaas@google.com, 
	pbonzini@redhat.com, oleg@redhat.com, jbaron@akamai.com, ning.sun@intel.com, 
	seanjc@google.com, luto@kernel.org, andy@kernel.org, jim.cromie@gmail.com, 
	kirill.shutemov@linux.intel.com, hpa@zytor.com, 
	pawan.kumar.gupta@linux.intel.com, vkuznets@redhat.com, rostedt@goodmis.org, 
	ardb@kernel.org, thomas.lendacky@amd.com, nikunj@amd.com, 
	ashish.kalra@amd.com, kees@kernel.org, alexandre.chartre@oracle.com, 
	rppt@kernel.org, steve.wahl@hpe.com, jirislaby@kernel.org, 
	apatel@ventanamicro.com, bvanassche@acm.org, ptsm@linux.microsoft.com, 
	Jonathan.Cameron@huawei.com, beata.michalska@arm.com, xin@zytor.com, 
	davydov-max@yandex-team.ru, ravi.bangoria@amd.com, joel.granados@kernel.org, 
	ffmancera@riseup.net, kprateek.nayak@amd.com, akpm@linux-foundation.org, 
	bhe@redhat.com, brgerst@gmail.com, coxu@redhat.com, dmaluka@chromium.org, 
	linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, 
	linux-sgx@vger.kernel.org, kvm@vger.kernel.org, 
	virtualization@lists.linux.dev, tboot-devel@lists.sourceforge.net, 
	nouveau@lists.freedesktop.org, linux-coco@lists.linux.dev, 
	xen-devel@lists.xenproject.org, Huacai Chen , 
	Zhenghan Cheng 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 12, 2025 at 1:19=E2=80=AFPM Juergen Gross  wro=
te:
>
> On 12.06.25 11:32, Zhenghan Cheng wrote:
> > After commit a934a57a42f64a4 ("scripts/misc-check:
> > check missing #include  when W=3D1")
> > and commit 7d95680d64ac8e836c ("scripts/misc-check:
> > check unnecessary #include  when W=3D1"),
> > we get some build warnings with W=3D1,such as:
> >
> > arch/x86/coco/sev/core.c: warning: EXPORT_SYMBOL() is used, but #includ=
e  is missing
> > arch/x86/crypto/aria_aesni_avx2_glue.c: warning: EXPORT_SYMBOL() is use=
d, but #include  is missing
> > arch/x86/kernel/unwind_orc.c: warning: EXPORT_SYMBOL() is used, but #in=
clude  is missing
> > arch/x86/kvm/hyperv.c: warning: EXPORT_SYMBOL() is used, but #include <=
linux/export.h> is missing
> > arch/x86/events/intel/core.c: warning: EXPORT_SYMBOL() is not used, but=
 #include  is present
> > arch/x86/events/zhaoxin/core.c: warning: EXPORT_SYMBOL() is not used, b=
ut #include  is present
> > arch/x86/kernel/crash.c: warning: EXPORT_SYMBOL() is not used, but #inc=
lude  is present
> > arch/x86/kernel/devicetree.c: warning: EXPORT_SYMBOL() is not used, but=
 #include  is present
> >
> > so fix these build warnings for x86.
> >
> > Signed-off-by: "Zhenghan Cheng" 
> > Suggested-by: "Huacai Chen" 
>
> For Xen and paravirt:
>
> Acked-by: Juergen Gross 
>
> Your patch is looking a little bit strange, as the list of modified files
> is located between the patch hunks, followed by another "Signed-off-by:".

Indeed.
And at bare minimum please split at least to two:
1) adding export.h;
2) removing export.h.


--=20
With Best Regards,
Andy Shevchenko


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 11:16:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 11:16:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012879.1391404 (Exim 4.92)
	(envelope-from )
	id 1uPfvC-0003lF-AS; Thu, 12 Jun 2025 11:16:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012879.1391404; Thu, 12 Jun 2025 11:16: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 1uPfvC-0003l8-7f; Thu, 12 Jun 2025 11:16:38 +0000
Received: by outflank-mailman (input) for mailman id 1012879;
 Thu, 12 Jun 2025 11:16: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 1uPfvB-0003Ie-6E
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 11:16:37 +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 b3ba77fe-477e-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 13:16:35 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by VI0PR03MB10784.eurprd03.prod.outlook.com
 (2603:10a6:800:262::7) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8813.27; Thu, 12 Jun
 2025 11:16:21 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971%6]) with mapi id 15.20.8835.018; Thu, 12 Jun 2025
 11:16: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: b3ba77fe-477e-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=igio+9fAb3iEvClhG9Sv/AVXdTXF2m5BESwEPXzUkXxyzCxU8g8vccbxGY+njG5VHat9JUAZCaVJoVXmMzIXkaAoJBWJ1QE7hKypDp7NQu4bDwuveII/qxtXPaxvTrb7Cp/tBLY3q41ENC4nx7HdoKLofEeOIjkkc8CNiVplpGh0K/MpURh//hvQkquSSNDVYQCLUnyFzgWb+/mBf8TFApJfxmre0inXYnO38XfCq0GEwNHRz2AaUa5JkJCognmBBQOEor4w5fUml//15ZDlFW3RmNyV93Lffu+zGB4uwGa8RlIjSPRZZa9dUSZQbvkzC5h8eaYjSG8WKKsgAlTSqA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=nScYt7GmoMzS1LXbq902oz4FID+2oMIzcHIRz6jw5Cg=;
 b=j9eIPGOeDGqET4ddUayRfYXaq/X3WERzeAffzDrR2x/354RNorfRKD4mAsEz9Bsuu540TCZ/yjP6EYgoFNt73gcVqhp8brJ09FHZvgldIU9RvDJtEVWyk/7UCshYBZupgRMctubXVs6+1ugREj9mFBq9sv/jLsUYmQ7xR32jK/DdvqkGK0JMzQvdAKwX9XR5rveD73A6TkbSSwLPrH9noo9Nb+l4uhPD/SVG6yWnBCCR7f0Ok8BqnVPAjfDk4jxpCm7zhIV05Ak+w2cMfZNE+VJ+a9/Sdzqhw70bJ602CPmtZY8TXwnI5o7dl5QpISYtPyD6QIBsPN9VG2L0YiD/FQ==
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=nScYt7GmoMzS1LXbq902oz4FID+2oMIzcHIRz6jw5Cg=;
 b=MJ80UwwAe4VP54nKCZiPaDYYH1kca9jxUILhxwSrKw3Sg4tzJrOb0XC2YvLqnm3vaBnCAKsBgNivUPDuSRNw3Ue2CjnzMsMrGfi00RqFnXpcg5yh1qjKQRYoaxb9etRFT1nFDJIrkgzBAOD/9xgyqnuMLMxZCKGrbHWOs1kO826i8siH1TLUS5e6WpZrdT68Ld2dxDf8wysY30xTK9SKnGiuQEnsn0AisSyRdcxwi+hRzNwmJZIvmAiS1TQwCx5v8PFs2NNO3CkDdCcHp2GItFDZou16TXgrOsRcsYT07eEPWAhDuFa+fJm4c/cYxm7j7NOlUlNJbADK5eAftjurZQ==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Oleksandr Andrushchenko , Stefano
 Stabellini , Julien Grall , Bertrand
 Marquis , Michal Orzel ,
	Volodymyr Babchuk , Mykyta Poturai
	
Subject: [PATCH v6 2/4] xen/arm: make pci_host_common_probe return the bridge
Thread-Topic: [PATCH v6 2/4] xen/arm: make pci_host_common_probe return the
 bridge
Thread-Index: AQHb24ts21/zmTrEckWar9vhEnDhBg==
Date: Thu, 12 Jun 2025 11:16:21 +0000
Message-ID:
 <89b6866f789ce19908f16031272ed490aa9e136a.1749720912.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_|VI0PR03MB10784:EE_
x-ms-office365-filtering-correlation-id: 953e37f4-7855-4e91-0d7f-08dda9a28f80
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?0IxKtvjB5+uxR9Mod9ReiP9nOsoeSy27/fGmnEhKEpkByddlmJ8IOvo1TE?=
 =?iso-8859-1?Q?MPIEcbjyd8F/Q6qluS86ocIdtycf66atcmkF03GKy3YBpvLfXYxkXh2S42?=
 =?iso-8859-1?Q?vHUJYYfGKajz7njA9w23OVU6Y8Aw0Nhxa1L+AMTYWnJ69rqm8+keZL8Xqi?=
 =?iso-8859-1?Q?egkLY8vLqfIue27u0zbB1WRpWjRQ0+V8WFvziEr7ra7QBxL7oS0wUwgKcV?=
 =?iso-8859-1?Q?f7hZrIGMA2JE848+7GYqn1GAL6tQ5aJgpIPqxCVGf/1YttcRQb0CHLTJDS?=
 =?iso-8859-1?Q?JIvjpAAiGtrHhbWtVIVQ7/RukRnLW0A4p40WHu+AtWC72AeTLm5SVhy0N2?=
 =?iso-8859-1?Q?W6s7AxIyV41T35bUsF3FPzvhHZZeLVFqW6v7PJX7QDEarFXuF19cFHhyUf?=
 =?iso-8859-1?Q?xu1ls8zxRjGlNL4swjEkFS3KHLUSlAnkL4bZMA3mHcwNxm7FmsFmGejLgv?=
 =?iso-8859-1?Q?hBZDGmnPYHnttZNkJwOImKUh9ughso0CjlTzOUZK2DPgpBxyH2X+GFminA?=
 =?iso-8859-1?Q?ds1hI/T+aLoM//UgX2MeYAYPgTkeWhTpuILHoVmAlseY25t0O0W1a2rG+2?=
 =?iso-8859-1?Q?KrcU72wCqmR3tWN735s7vPZHgYOEMNHMtXdfRX6pAw7j6++3Gl3VWk2Pn/?=
 =?iso-8859-1?Q?VGnn4TptagMR7E9m6fjpNZa6O+at8tgw5CfqQsNtoq/Sb8cLb1ASRXCRJZ?=
 =?iso-8859-1?Q?q/bCUYs6Wt9dOTB1B75QbFr0en5E6s5qDP3U3HpBGGwl+QZ6xMG3gEFMw7?=
 =?iso-8859-1?Q?LjXcJDaMnE5ltnIBG+fnKeMniZ1aMGmIB99qS+r8LMfsNsm3x+yXmHmGRD?=
 =?iso-8859-1?Q?H0fWaOpOvyR9opGYUFnQYQmEwhr94gj19baw3TWCHFsoSCm6YVggKkukiB?=
 =?iso-8859-1?Q?xIW5FS4HQtxboglDhv1jp0u7KxRlapC6pnk3H78uZ+rDYe1ISGi5OAFi/w?=
 =?iso-8859-1?Q?HvSEbcPMRf8TD1s7rRmDS10DCb4guWZtAn3LUfXLhux8OB2f7xlonOzvEQ?=
 =?iso-8859-1?Q?FetWyaWznkZjXPHs+QNCMFADj8aJ5xG9W4x4mprD0DCwdONf24iZflF4kw?=
 =?iso-8859-1?Q?RTtOKVvGR3ywidwELrPzGY/LJeFpTLnc8ZnOPruZcjKJY3IU5B920Oes72?=
 =?iso-8859-1?Q?RhsTVxQeUK4M7lWhCuznDUoveY/2qr0U9d6u7RTvLXCW8QFAAafDTxVkur?=
 =?iso-8859-1?Q?2U0QYK6EPlDH7DIypSkrOTt2vnQt6Aw8pF7afGK+c/pAIRKXHetgYFCu/S?=
 =?iso-8859-1?Q?3QvGdZ1pb8IPbIG/CGwnuEDpfFk3STOvusYiBuTXzz/63GiE5Y/t8NcukQ?=
 =?iso-8859-1?Q?eMwElnvdQ8bMBDOA3BSh0P+3mzu56wVsH1SR/AfapauSo66fSiMx4CFUBS?=
 =?iso-8859-1?Q?bLMRYcaM6bpFYFZZHnVyuHxlKAibt1PgdA7Y7UFGxsIuaMz9ITaFz1XInK?=
 =?iso-8859-1?Q?+DaDAM+wrVD1dv5LS7FLP4OJnx6pHYnxnfH7aYTskMmGqxSXZZRuQ+rjTL?=
 =?iso-8859-1?Q?SNBstWNsKWKtvsJ5qOrHHN60aA1bMz+9Dq+UEa3XTK9fLBcXYxYzVoSsxG?=
 =?iso-8859-1?Q?Bl18rZI=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)(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?h06h44ZQnHnLC6AMOAxsm1E03/JHSutnZHTKnQjqB7pZLXTIOAG4cg3Zc8?=
 =?iso-8859-1?Q?GCc3z01mb9hzmfHvos+GdK4nXiOw8iWVhTeJfHaHd88etZt4vF32tqovXQ?=
 =?iso-8859-1?Q?QalhYTX0PQVX8ArGjcpxYeTyMFbfbAOxqFLvgFYv6TIriC86oEhJYT+hKz?=
 =?iso-8859-1?Q?c1EZ3RTkphrLI0A8fCA58JB1tlSadYSImPq2fuv7ZyR6o5hAjbgid3QmLy?=
 =?iso-8859-1?Q?cOdfsHSiVnN4FtBWO9RSPFWfsw0OyUajHYvEqRZfZBxr96z/4/VNpUfb+7?=
 =?iso-8859-1?Q?4afIPyVJqIfhDoFvvR/cVRknIuDC+txZfmexoXlnuhGHpS06YtxL7uEmZk?=
 =?iso-8859-1?Q?hiE6k+YmlbCZ9JZteoCHIsAepsl8vo0PJvy/VLwvu7Fd2TUiNnsiNe00hd?=
 =?iso-8859-1?Q?Ho0wEakmLApEXYn/n4tD351M94w/fnvi964xwaxbIsA2rpCDzyJ2dvtihW?=
 =?iso-8859-1?Q?SP8YXQi66YHhP1hx09j2MHNl0VITb7GgG/ILvv6Y+gJKxq9mSc5QOLvtvw?=
 =?iso-8859-1?Q?sVlsYfh8TM+htlY9f0CSBh6VFEOCflb6UTWL9xV92EUn+NAxuRHZ650XSe?=
 =?iso-8859-1?Q?a7QhKRNATn8YmaUxvahYNAq9d3XilrZ+okluLXlZT7BjyE4aYgnWahzHcb?=
 =?iso-8859-1?Q?ze2husrtYs/hXHK3U7XEknsy6ZQypKb8qT11eBQasW3QALOZIhCiiQ91b0?=
 =?iso-8859-1?Q?CAMtaaHixy8rl9CLVBDiAd2TPHNVjUXO9GQE7jqWQlK61USVLUyYw7xi13?=
 =?iso-8859-1?Q?9TNOilnEVc/NOCyfI2JBEF8r8iDxHm5moNiT8AthEXvo7env9TXaOtM8Vl?=
 =?iso-8859-1?Q?vmbCBHJOiXCmNOa1HlqUyNwWpd7mjeLrgonyGjOdducCKkEJtQyvGp16Vf?=
 =?iso-8859-1?Q?KmTGZ2ujRUrvi2dMnEUt2F+dwM6Tp9Q4O1C7NgDWgXyenT96tlYLqwI9Us?=
 =?iso-8859-1?Q?lX898v6k14wHKoWekCNpxUUneLf5HgLhmGstysdy5l1Y1PFedn1vQ5Q7Hz?=
 =?iso-8859-1?Q?5RoDUHzvQf1H0KCypU0UZqjHf0XWMy8KAHPr9s+tA7RlA9ayRT2ccFmu0R?=
 =?iso-8859-1?Q?99QrAEiCF2+eO+5xBQe46TlkYTYAFWTn+8ApTt/FGObK0FKLXU0kalho09?=
 =?iso-8859-1?Q?MjUz+x/mHnb1HVJDqj2u6QF6SFMJGzzVXt3ae5BbLieaXpJChXmHSbm1w4?=
 =?iso-8859-1?Q?EvnrKNd96u5kGQ/o8uYXoWOMXJHbU7lJlFVyCeoTODrhpG+3pE7jCJ94As?=
 =?iso-8859-1?Q?M3o2FS+8wq1MA0VHa9lIChec5WOWAm7aToNnBG096gN/YurMA6kXAgzmf9?=
 =?iso-8859-1?Q?/qaI/QshF/kKO0lcbWei8UMcO23hP2ViKoZYhsabgPrmBxMqPz8yd64TmY?=
 =?iso-8859-1?Q?B1hL1/xEHG0y8Vh41xafCjgTvpLNIznOfzm3MtYaVHq6wbmm1scSpXPBpp?=
 =?iso-8859-1?Q?D7455xA12xR6dqWNdH0YFCt59rkqn0rBYoDzmjEAslykwX8+9ruysLR3vS?=
 =?iso-8859-1?Q?eyVwwwrN86GXfw+lgpEBRGACIk2B82uM8lkyrWnI6Tosn4r9qW72J4UtVH?=
 =?iso-8859-1?Q?igCfWJHXEexDgf5WBugjNKcNv6E3wsxX99ujwVgxJnPF13jReAZu8aKhz3?=
 =?iso-8859-1?Q?Um4sSWf+dPjxzn0VzVeuPPZpUG68738ou4J/zkYtYhGaF6a9OuarsW5Q?=
 =?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: 953e37f4-7855-4e91-0d7f-08dda9a28f80
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2025 11:16:21.0778
 (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: Zegq6GTRH65NjqJOTyQIymeYC9Oz6+DLel9SN0TUnOlMJlJyk9StophwECEQwUiz9tCPMaIGAFy8Pb3IrqdrQw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR03MB10784

From: Oleksandr Andrushchenko 

Some of the PCI host bridges require additional processing during the
probe phase. For that they need to access struct bridge of the probed
host, so return pointer to the new bridge from pci_host_common_probe.

Signed-off-by: Oleksandr Andrushchenko 
Signed-off-by: Mykyta Poturai 
Reviewed-by: Stefano Stabellini 

---
v5->v6:
* no change

v4->v5:
* added Stefano's RB

v3->v4:
* change return 0 to return NULL

v2->v3:
* no change

v1->v2:
* no change
---
 xen/arch/arm/include/asm/pci.h      |  5 +++--
 xen/arch/arm/pci/pci-host-common.c  | 12 ++++++------
 xen/arch/arm/pci/pci-host-generic.c |  2 +-
 xen/arch/arm/pci/pci-host-zynqmp.c  |  2 +-
 4 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/include/asm/pci.h b/xen/arch/arm/include/asm/pci.=
h
index b7b2dc7832..061d9810af 100644
--- a/xen/arch/arm/include/asm/pci.h
+++ b/xen/arch/arm/include/asm/pci.h
@@ -18,6 +18,7 @@
 #ifdef CONFIG_HAS_PCI
=20
 #include 
+#include 
=20
 #define pci_to_dev(pcidev) (&(pcidev)->arch.dev)
=20
@@ -95,8 +96,8 @@ struct pci_ecam_ops {
 /* Default ECAM ops */
 extern const struct pci_ecam_ops pci_generic_ecam_ops;
=20
-int pci_host_common_probe(struct dt_device_node *dev,
-                          const struct pci_ecam_ops *ops);
+struct pci_host_bridge *pci_host_common_probe(struct dt_device_node *dev,
+                                              const struct pci_ecam_ops *o=
ps);
 int pci_generic_config_read(struct pci_host_bridge *bridge, pci_sbdf_t sbd=
f,
                             uint32_t reg, uint32_t len, uint32_t *value);
 int pci_generic_config_write(struct pci_host_bridge *bridge, pci_sbdf_t sb=
df,
diff --git a/xen/arch/arm/pci/pci-host-common.c b/xen/arch/arm/pci/pci-host=
-common.c
index c0faf0f436..53953d4895 100644
--- a/xen/arch/arm/pci/pci-host-common.c
+++ b/xen/arch/arm/pci/pci-host-common.c
@@ -208,8 +208,8 @@ static int pci_bus_find_domain_nr(struct dt_device_node=
 *dev)
     return domain;
 }
=20
-int pci_host_common_probe(struct dt_device_node *dev,
-                          const struct pci_ecam_ops *ops)
+struct pci_host_bridge *pci_host_common_probe(struct dt_device_node *dev,
+                                              const struct pci_ecam_ops *o=
ps)
 {
     struct pci_host_bridge *bridge;
     struct pci_config_window *cfg;
@@ -217,11 +217,11 @@ int pci_host_common_probe(struct dt_device_node *dev,
     int domain;
=20
     if ( dt_device_for_passthrough(dev) )
-        return 0;
+        return NULL;
=20
     bridge =3D pci_alloc_host_bridge();
     if ( !bridge )
-        return -ENOMEM;
+        return ERR_PTR(-ENOMEM);
=20
     /* Parse and map our Configuration Space windows */
     cfg =3D gen_pci_init(dev, ops);
@@ -244,12 +244,12 @@ int pci_host_common_probe(struct dt_device_node *dev,
     bridge->segment =3D domain;
     pci_add_host_bridge(bridge);
=20
-    return 0;
+    return bridge;
=20
 err_exit:
     xfree(bridge);
=20
-    return err;
+    return ERR_PTR(err);
 }
=20
 /*
diff --git a/xen/arch/arm/pci/pci-host-generic.c b/xen/arch/arm/pci/pci-hos=
t-generic.c
index 46de6e43cc..a6ffbda174 100644
--- a/xen/arch/arm/pci/pci-host-generic.c
+++ b/xen/arch/arm/pci/pci-host-generic.c
@@ -29,7 +29,7 @@ static const struct dt_device_match __initconstrel gen_pc=
i_dt_match[] =3D
 static int __init pci_host_generic_probe(struct dt_device_node *dev,
                                          const void *data)
 {
-    return pci_host_common_probe(dev, &pci_generic_ecam_ops);
+    return PTR_RET(pci_host_common_probe(dev, &pci_generic_ecam_ops));
 }
=20
 DT_DEVICE_START(pci_gen, "PCI HOST GENERIC", DEVICE_PCI_HOSTBRIDGE)
diff --git a/xen/arch/arm/pci/pci-host-zynqmp.c b/xen/arch/arm/pci/pci-host=
-zynqmp.c
index 101edb8593..a38f2e019e 100644
--- a/xen/arch/arm/pci/pci-host-zynqmp.c
+++ b/xen/arch/arm/pci/pci-host-zynqmp.c
@@ -47,7 +47,7 @@ static const struct dt_device_match __initconstrel nwl_pc=
ie_dt_match[] =3D
 static int __init pci_host_generic_probe(struct dt_device_node *dev,
                                          const void *data)
 {
-    return pci_host_common_probe(dev, &nwl_pcie_ops);
+    return PTR_RET(pci_host_common_probe(dev, &nwl_pcie_ops));
 }
=20
 DT_DEVICE_START(pci_gen, "PCI HOST ZYNQMP", DEVICE_PCI_HOSTBRIDGE)
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 11:16:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 11:16:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012878.1391394 (Exim 4.92)
	(envelope-from )
	id 1uPfvB-0003Wq-3U; Thu, 12 Jun 2025 11:16:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012878.1391394; Thu, 12 Jun 2025 11:16: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 1uPfvB-0003Wj-0M; Thu, 12 Jun 2025 11:16:37 +0000
Received: by outflank-mailman (input) for mailman id 1012878;
 Thu, 12 Jun 2025 11:16: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 1uPfv9-0003Ie-Kg
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 11:16:35 +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 b2d16bd5-477e-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 13:16:34 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by VI0PR03MB10784.eurprd03.prod.outlook.com
 (2603:10a6:800:262::7) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8813.27; Thu, 12 Jun
 2025 11:16:21 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971%6]) with mapi id 15.20.8835.018; Thu, 12 Jun 2025
 11:16: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: b2d16bd5-477e-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ADAuQgNA5rxQJyf6nz96YsB7UH2GLqcCiYOM/0PaXWsE3xoKe5otAbeynLz548HCVximD0dUKkiA5pdsq74bcNtF+vtCb2UUYwmM5W2QehEjGqUmJWpYTzV8052bEQ3ed59mRF4q9is+MGxns17w/dICS/UFbxogj9JaiGbXTMV0PKSaZVaewYvZAsxF6RD5WMtj+DhSBt+6RAuQNutb9x9q11uUvL8mnPAj2h3RYyu3FP4agUaO71YWwfnMXyGyBn991WzKUlbipeB9IEGtGWBR+YKBZ+VbTCQs9PRkiW5RRvneFDjWBRobNw57zbHB/hjc8dkLsZy+YepAdLhMGQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=TzXvj2JuD24fqznd8IDEh0oZUbY/zpRj9p3MFbrJ02s=;
 b=SHHxg3E8WDfmtPOVbwwRU4D5mXsFRuad6d/lCNVNQkd7yZOfRsfTy6dGgNfHeOqzN+q3kcTW753Fdf1IZevwmJsAqmgNG929C9X3kzagtpfsTWs/62TIgoxzWCqZ1jmw99I2S1GkfJ1rwjc4bFS7+TEZfo0HPCVrVg7kJXoLyepu+Ng1yjZ1Xw7HVwJH6s6gUbYF76YHqqD5lIWT6WP5aSnY6dYatwgKbIFMF6H+H4TUXMoo3sgi2G6avAacXIOQQN5hULfGlBHw0I2M/gDjdtlLYVkpDIPmIDJKvuLb4QdaAXrmB7+aI8MWQWiypigda352OR+ooBQBNuJp0VpIVg==
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=TzXvj2JuD24fqznd8IDEh0oZUbY/zpRj9p3MFbrJ02s=;
 b=gKZmoa1NRv/rolPJpUE7iUji+2fiHSXw6e2ac/TorY5yVSjDCIuOS49dI4PvwcgzhTDQcMr83b8HUDpLIsP4+qqEPf/I92r6Yfu4W0A+gvWZzArF0GxNoIhTas7v49DNLxhQz5K55PbhLs3gH/l/xC40f6H+eHJ02Py08M0XOgHW9JQIOdVNn1Kc026l5Uxlc1mlnz6UNdmSU/aXDqhaDkgFBHfdTvF7zYaSUlT/buvUP4v7+I8LJOkBs5eNgu8kCJWUSxBzf+brgYcOhDbcKzzGl6/EmSbT+vHOmbfC2Yw/NaP5AAGKSUzuqOlIpRsg7xTvEV1gIuO0UATqFvE5hA==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Oleksandr Andrushchenko , Stefano
 Stabellini , Julien Grall , Bertrand
 Marquis , Michal Orzel ,
	Volodymyr Babchuk , Mykyta Poturai
	
Subject: [PATCH v6 1/4] xen/arm: allow PCI host bridge to have private data
Thread-Topic: [PATCH v6 1/4] xen/arm: allow PCI host bridge to have private
 data
Thread-Index: AQHb24ts9Pkj/p3l80mPyHDDabUuhA==
Date: Thu, 12 Jun 2025 11:16:20 +0000
Message-ID:
 <5c499d459f8d426a395e973f429d542040e16db3.1749720912.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_|VI0PR03MB10784:EE_
x-ms-office365-filtering-correlation-id: 9353f9d0-a90f-423c-c47b-08dda9a28f48
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?x/HZeJlaisJo8rpQH1XKqdnZ33bHS2ukRDBMlinyVeM7l1naSUiHXH/GGD?=
 =?iso-8859-1?Q?2heb6JQiYuYuAcT1DmHKCLwcFJKvGx0drM2WN5gaFAYW9SSFFjj2cWWl3w?=
 =?iso-8859-1?Q?9MPN1m0Se5EtRdxkmLdjRArqMOn22Nw0ZmDVziB8iXazhZHsRAMxRtodSw?=
 =?iso-8859-1?Q?7Xwrh2Uluhngelz7d67+qaJ5v36tbzZ4lNtpNhEiGrB9LsxP85x211ZYe6?=
 =?iso-8859-1?Q?QFqQPB1i7BYo4d5yQCRjJhSHSqtCb4il7Hp8FQd6oBAEXzjKXcrmii68Lf?=
 =?iso-8859-1?Q?/I0KA0a7Bjf6R4vOcko5OqR1PlxkAJy7OwiV9VA/5lFOLBoi0M1PDxqZNF?=
 =?iso-8859-1?Q?MC9anjiH8WHKI5DgyszOQX0Vh8Kq87Qwdt8qMU1LRS6iTQ7slafKJLg/oM?=
 =?iso-8859-1?Q?nYKL7SSXCZnE2X4LlelcEAgoadDfNUL2h9OGv6i+H+Bkx2rMgR7NjRephw?=
 =?iso-8859-1?Q?YLxpxH08fh89TUb2oU11qMIRhMFTmJ4knmVXpU8t/KNhfxV9NF8iTI9d8A?=
 =?iso-8859-1?Q?CTV1Eeq2A3OZmi3ma8PxX0GP+zhU3y2VrO+B0ZlMC2Ml8s2ID2QIK/aiI7?=
 =?iso-8859-1?Q?wKY/zza8/ryqwmlQfwOdCMfnNC0Psz7L7f2ibNobvJENVnYRQU6zIAt+cI?=
 =?iso-8859-1?Q?0PHDl5pWa2Amdgulbn6pYpY94cOtLWg8vKX3b3fg+dNZWDye4TtahsDwnp?=
 =?iso-8859-1?Q?QBq2eyjDAvYx/nEwxI0Euf1pqW9ifSVksO6OwIyFRItbRzD+8V7QtQxLjd?=
 =?iso-8859-1?Q?OM9B11/vCjinOlybUE3C3M4NU3ugUUV/4/akf7cxtwBIO64cUCvKzdL8um?=
 =?iso-8859-1?Q?C32gO2ksFho+zIkUKwsxvNxmlBWOiAc8TNlQ6snOy5IA174gATC9pE2RLt?=
 =?iso-8859-1?Q?aOFmjp7YqBFYSHW3zD1QuOYbY8PmAbnAKii3T9QvNJXmRcoTlVjmz/lpHa?=
 =?iso-8859-1?Q?6xa4xrGgsta/BJS3qBzKB/14KzrmzV/hITLghzSilwOl1BOi6Jh/QVIIU3?=
 =?iso-8859-1?Q?Nl1t2E9mkA81hvG36SYAAVVaZWuSPPNBL+g68IsGOUNCe203SHRWnOnuFm?=
 =?iso-8859-1?Q?4mDVCCham5r/H0YgLQcO1rhUrmJyzKSR69WEHlepXWcB7mq7cAuoxKGCr/?=
 =?iso-8859-1?Q?tSf0oG/YvgoUM6RwK4siCOHQmwyDoofF15eZ+xwtWaPBJiCrtA78RPEImQ?=
 =?iso-8859-1?Q?DpzSCJFcOMcBeUXkQ3Wnz8ByT34nhz0VGoiD+OxJJosmxLwPgMLS+xlk9x?=
 =?iso-8859-1?Q?GKlmrbmMoPvHll5XB37+uoJfcr/8EAA4ZwTHPu4/JCcghqJf5r0438kjQ7?=
 =?iso-8859-1?Q?2cUXAgY5QJ8xMpX6fk7CljdTvEJdNTjIwR/BujyDYvt0DQPllDewhbY5DT?=
 =?iso-8859-1?Q?avBEklEOg2GlAvBSHbfxlGIqXsIoym049eX2D//lalpVBNu6EyzIUxXePM?=
 =?iso-8859-1?Q?pQtOpM345YT2yeoKfU6pZjYOlD4FGgja27LRbaI494AD4YS0ykPfIYZTok?=
 =?iso-8859-1?Q?sq6DfeLrWOtXeAnUsFJE4Y8k++sqtSIWCaapw/XieEDu4NbvYlrWGZ4POD?=
 =?iso-8859-1?Q?tB8KDhU=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)(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?mKlQjHtIEkpIr5lxWek5ROHRNTwC+JlydlCFCFEu+8vxi2H0DwfD9/zobx?=
 =?iso-8859-1?Q?dKXrwFTdDBUIqgSwi9dhT7/4so7nrK8fXWnXg+X0oxOfWG2UwuM91VvmKp?=
 =?iso-8859-1?Q?Rp53sxaXteMPBPOPcUAUdY3RFY0M9DFdNPgkuXAC7yG6d8Zg6hP1lbro/g?=
 =?iso-8859-1?Q?WrLX/aHlMjQ+lCRep4pQ1xZ/b2BpmcDdPB3UOtbLMBpvNGS3ALSAwn6WPu?=
 =?iso-8859-1?Q?1jX7rGj9Dss1XsWJ/sKKqH8gucCTySHNEn5JXFB/xpIJn+GBosve5bLmT/?=
 =?iso-8859-1?Q?JVauAgY2x0FXndkTzRrUyTCM0v67DPvykO1dbBRfPYDWmtoFAdokdIFT4f?=
 =?iso-8859-1?Q?El8O6CoQIuvflS6GpXnIuxKacndbZduqShY/h9zhEa8TCJKs+P/+1ih+Xh?=
 =?iso-8859-1?Q?w1Xqq2ud+fEPBdFbOx1h/5tHA4UWCXL77ROI6SI6aNiWd5R31WX5KcDI6n?=
 =?iso-8859-1?Q?iwdybw9W/HU9vR19BGq7ewHJRF9ZYrt74zrIy1NBs5zhE9989KQ8ky+iW4?=
 =?iso-8859-1?Q?UAk9CO+8oi1UIXGMpZB2lg5CMpcf7KjnFxGBDag4mPBVnKlFLoAqp/OvoB?=
 =?iso-8859-1?Q?QOukpg2lQKUUonSWM0Vok3i6HUfz1YoXd471QSZdRQrbdRaMidGL6GRgoE?=
 =?iso-8859-1?Q?+lQuyAD31Mb6tsGD6mM//ZUVZC5AV8B+nFa/WyITibAKu4THHRu36MCU+W?=
 =?iso-8859-1?Q?fma8NP4pyg8ZSO2pP/H9w59XGm0kjQdMZE5XpNwxiXA/Kn7Q6LEBR23ymU?=
 =?iso-8859-1?Q?vmUhOdkfKjIZ/QsJTQCtDkeGjXEYq09M5hyh8O7AABf7kzBlhCudDdjwlC?=
 =?iso-8859-1?Q?vHSVgBm44dNZdYkSH9S0SpM2Gy8iqBN96hB+47tLlAyVj2r9qsv6VswqzP?=
 =?iso-8859-1?Q?8++pdVNVtjn5Lp6jR9uSNA057R3baQArJQUMq5FcGc55jVjCE9SeiBKMh+?=
 =?iso-8859-1?Q?FNLW+pZiFS36XK//dxfOKzdOa6EcQ3TCcIGphNfm2QKTbhby4uzrDDBlpa?=
 =?iso-8859-1?Q?6psMpkbT24t8uytyOkmG8c262hS0HUTQfvDq6UeFij+I4M7zqaBsW21Wtg?=
 =?iso-8859-1?Q?JdogRpIKZzrvNUxkuB+iFiHKSkuvH+Ou5ZGNWYYVMk4f9wdrFvQkM6CXWs?=
 =?iso-8859-1?Q?w4dTgyAMMDB6etjpRW6t+ajxVBqsdbmA/H5+e4YmvkjHZnoOog1rg9KB+2?=
 =?iso-8859-1?Q?y8SuXFTEVzfQTTU/ua+8Hq/BmqtP57lfNm4uoBCbaOc9S4Mxa0U9TvP55v?=
 =?iso-8859-1?Q?5yIbL7cyE7rLLvm3ZG4Yi28Cvw38cVN3SjR+EORAleSCkd9zBIfNlMv8uJ?=
 =?iso-8859-1?Q?/3xiW2sy9KUKfnuGHL6P73aq5L42Q3FQAAtdlqVewIF+R/Y/wzwqxkkbkC?=
 =?iso-8859-1?Q?hRVq+AQ0gZP9/6XPBmC73Y2mR87LJ1cNGcMkuNWyTDqY7G7wb+Gw2ToBqD?=
 =?iso-8859-1?Q?uHwpTuPeHeRXfpk2t+P2NXQqP54YH5nhnjREsSAxCGwmd/8G1uEtoUVAn3?=
 =?iso-8859-1?Q?7M8b2z/m1acLYYvAF/l4hXj7v4enAl8H69qvHgPJlRRyZiALlB5KIawE0H?=
 =?iso-8859-1?Q?ycR+5KPnVDwdW16+cQpi5/P1/M1HAcHV6qRluR2pfUbAHMgrLxNHH684ru?=
 =?iso-8859-1?Q?K7mF26Q4NyaS9c6MASteOqbSPMHBPHfNKUs+hoZkyWGbfZDUS/p9YzIA?=
 =?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: 9353f9d0-a90f-423c-c47b-08dda9a28f48
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2025 11:16:20.7140
 (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: njgq4xkq5ytRcNXSdbAgxOlt2XssmzTeL0PQblTcBhGOuoFhUJOka+1P9Gsq4gJnqcnIg3yYPUepuDcrfjZgHA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR03MB10784

From: Oleksandr Andrushchenko 

Some of the PCI host bridges require private data. Add priv field
to struct pci_host_bridge, so such bridges may populate it with
their private data.

Signed-off-by: Oleksandr Andrushchenko 
Signed-off-by: Mykyta Poturai 
Reviewed-by: Stefano Stabellini 
---
v5->v6:
* no change

v4->v5:
* no change

v3->v4:
* Added Stefano's RB

v2->v3:
* removed priv allocation from common code

v1->v2:
* no change
---
 xen/arch/arm/include/asm/pci.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/arm/include/asm/pci.h b/xen/arch/arm/include/asm/pci.=
h
index 1605ec660d..b7b2dc7832 100644
--- a/xen/arch/arm/include/asm/pci.h
+++ b/xen/arch/arm/include/asm/pci.h
@@ -66,6 +66,7 @@ struct pci_host_bridge {
     uint16_t segment;                /* Segment number */
     struct pci_config_window* cfg;   /* Pointer to the bridge config windo=
w */
     const struct pci_ops *ops;
+    void *priv;                      /* Private data of the bridge. */
 };
=20
 struct pci_ops {
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 11:16:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 11:16:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012877.1391384 (Exim 4.92)
	(envelope-from )
	id 1uPfv9-0003Iv-QJ; Thu, 12 Jun 2025 11:16:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012877.1391384; Thu, 12 Jun 2025 11:16: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 1uPfv9-0003Ik-Kz; Thu, 12 Jun 2025 11:16:35 +0000
Received: by outflank-mailman (input) for mailman id 1012877;
 Thu, 12 Jun 2025 11:16: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 1uPfv8-0003Ie-Ea
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 11:16:34 +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 ac1f19ea-477e-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 13:16:23 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by VI0PR03MB10784.eurprd03.prod.outlook.com
 (2603:10a6:800:262::7) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8813.27; Thu, 12 Jun
 2025 11:16:20 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971%6]) with mapi id 15.20.8835.018; Thu, 12 Jun 2025
 11: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: ac1f19ea-477e-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=y6R9bGXuAcSYR+ltGiSq5YroriVaP5jBmIMBt9+sV8w49bVILwsFnTm2OXMTXPQMeGu5GTIfPzeM6J8tUx3CNHC+Puj4yAGE8/fJjmfHPdvP2PIZV7TbwWiZSOLl9hMLeuRdu5yBuHI+VhKF3k3dOThelHnr07pcQtuU6RaGZWXItr1LcTlu80x2RXWHy1IoBZijGmmHxkmyWCaDftTogMQbnu0zLtQnqvZULQlkvOgh5NA8+YA7Y2ALK+Z53fIxyt1Cm5cOPARg1Bi+pxWNRronN697a48CJgtOWvZv+msmcJU8WKLIZv2zrcZjnGheO+qy9IsZpt/8PWHGvSryeQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=MkAcd66F7DOx8TKotTZNkzPXmPC0pC0/r8Ftv3gdFsQ=;
 b=KUkzblBp2RSXuVg/iveXQcByP9Ze+bR7gunn7wCj7L53wF7kPNdEX419bx8tLX3Gc8UYsOtTuocG4XhMmVz0TjdwkzQWKRXr3dOX/yoTLBpwG1T173Qn02j3sh/02utf/4QJyyOrFiJri2u7EErlkUMDlhDINEb2c8s2xDdBqNdvkheIdqda2Q9by+/WEuxAxZKArw2KSIJUarlGgAO6D+n/76c9bmTXAkeJ3Jvrts9VJaD/5yaqlNhVrXKtfHBb6XMChwZmHa5DORXAkh2f9egnFsd3EXr/2qGBewrwgMj74yucyfKvF+/OvxKgRlUKjwIMKsQAz5jB50SGjEfANw==
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=MkAcd66F7DOx8TKotTZNkzPXmPC0pC0/r8Ftv3gdFsQ=;
 b=kOM59G0rAKFynLN9faIblGXuPxR+yjeUkJCCSb+Oo5WM8WxDBOZxyFdKt2lU9JURL1y5oLrYlFT/0jVZSBVt5WQozIuMnBbpqg9cUJWJWHa8rHfFqRTI2+HetAPaRhj0jedqwqfSciN6g1sf4odOfPSYXY0Uv2pqCJrUoCdfolT4yAKImR5D+UWKNkomt54PyHITvt14T5AWQcYzmYo3uJyXg/JxXxoAZjVRi68ZdACuqpOBYlVixeJC2+pJqijt5565/zSLDL1GhGi5E7zRUeiFetaVqjX53xsGn6cDn+U9yomkd8TVlPVWcROnaXUB8cLINh1Fhiat9CcH8Pwl8g==
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 v6 0/4] Add support for R-Car Gen4 PCI host controller
Thread-Topic: [PATCH v6 0/4] Add support for R-Car Gen4 PCI host controller
Thread-Index: AQHb24tsXsw/PPDp202VmuYARImAdQ==
Date: Thu, 12 Jun 2025 11:16:20 +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_|VI0PR03MB10784:EE_
x-ms-office365-filtering-correlation-id: 95e81a22-72ef-4c32-5443-08dda9a28edd
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?xtSWrYONxcfljyI3NWyoja+LozLwndS930SDZCsM+EH5kc81Y3l3Y6V7I0?=
 =?iso-8859-1?Q?QEWHiMHWk1zx+wMcPh2011D72a4IUw6vvMzcChz5mqMvkBlOvVsYaT0jMx?=
 =?iso-8859-1?Q?9QShXkfyoLHD4FUq2oMgN1kbC4PU6pcTKRAXWL7AacnC2U/VuIseuFsJZh?=
 =?iso-8859-1?Q?WL++31otxFWsA5mNWADYO8Q7QNuClf40GxEVriJ338rx5UGIUvQKMMToVo?=
 =?iso-8859-1?Q?/jrp83XlbTZYiURCmIX4eDCFf64TQGAcSmu7NQAudWfOFVYFGIgj0SkBfn?=
 =?iso-8859-1?Q?IDLJ71XDYOO25sYk7RNU67xd6x87+TV9wAuTx4fknI2xhqJUyxuDG2ncn2?=
 =?iso-8859-1?Q?lLqX5aFKDI/XurH6hqY/Kvl5RN6PJVAaP8vwPKwvBJsGOINX6PYjcujIbc?=
 =?iso-8859-1?Q?kCMNcEistjYE4lSatoiiWWVHICgNyvOkwZb8hXq5AjwuVSVnKp9nWizWEa?=
 =?iso-8859-1?Q?ncpDdDIkxgf4ZkfSyJX3IVQxaMN3X0EjfuePEo5+kXQTTMRJVKcZciZL4x?=
 =?iso-8859-1?Q?l+V0ImkZJvsae7uff6JNGd83o4tvbnjwuynmEnwJxmfpDBpAiHafSdLv2T?=
 =?iso-8859-1?Q?AI+G+rherC6+Gln9qVGHLK/7IhfroycHd/j2HxMMZDV7bY1/pFAuUlbs1N?=
 =?iso-8859-1?Q?sDn3MKUIiRe4VLMkFOBTxKZMWF5ei9QVlLoGVRylOq3srhLZE9BZph2oI9?=
 =?iso-8859-1?Q?Fgwmp8fQ1spi83tYEDsoPYLhyiiMlddhvu6pAkr4LDv3bJWVV/xfYdLhCJ?=
 =?iso-8859-1?Q?CBHiMF5LYKAUmWDKVpEuof5ydI1J8QoLuRYTIxCmGrUi5JpEIuTJeXN333?=
 =?iso-8859-1?Q?9u8+csi8bYWHhmSV9dDGzXW9MRd10JEPTcA1i/hzxLuj4mPN8HnW5s0ZLs?=
 =?iso-8859-1?Q?TddmLQuQacoo9FvSOOr02oFHL+oBijCurFuSKA8LnuRp6QXpmlXUgMGGwN?=
 =?iso-8859-1?Q?Q3XgUecyOpLD6p9x7XvIQS4Uxq0eIzeLmg7QxtH87jGoGVuGIyttLuWQ0C?=
 =?iso-8859-1?Q?5JnuYgj+bq7OH+k4k/acA/G9aK2s6jgBUMqCJcQhvl/EmJhUMsk5W3Deqx?=
 =?iso-8859-1?Q?Pd0rGiP4sGht2B3lHVyQy5QFkl9yRDbZjWWOFPyUKHGQIPiQQBttaoI1fc?=
 =?iso-8859-1?Q?leK05WK/MdH3eym0ymvp3ROYHc6b/e2oiejJAsbzuzZhvFIw7ZddIf0pDx?=
 =?iso-8859-1?Q?5G9GB5FqF3RWXsFfrGipaEpERC57Heww0oyrZnmkeZskGc522oM7ERlk/s?=
 =?iso-8859-1?Q?WmcOqju+0afqHWb6osN2ylleDf65JtOFknTqvWjQFV9gxGnXxR3P/RLF33?=
 =?iso-8859-1?Q?Zov+bKX3Fq11PU9UOoDixJJaTww3XvlsJTmbkv7DrMolP6ZdF86Xf6FKPW?=
 =?iso-8859-1?Q?bYgJ5ZFEkMv4c2Dp1i2zKpsIaTfzafDljjcsWPhiFkpc+U+PELH/9ZDl/7?=
 =?iso-8859-1?Q?E9Vilisevjyt1fJin829kzS0KIKBMJBMaJF+qmosB3ed2DHGdJG6dyLL7g?=
 =?iso-8859-1?Q?T67N6HG9OOz+KHWwT8u4LPXqfcuj94xxNuc+aiusUbZhsnTH6zE1W9bMk5?=
 =?iso-8859-1?Q?6AQClrQ=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)(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?RyKuZtQOVtxM89/D1vkmWzOAJA42H8ZJBnvGlT4gMhhLKPnDqpJAVtHRDH?=
 =?iso-8859-1?Q?X8MqGjzWJs05RmvAaDAKJzyLKh53U7m6l/T8xV5GpQkWBfQ2CR8srG2tzY?=
 =?iso-8859-1?Q?am3gWlJFg4p9Acqz0Z39jCFiCYcWRsG2visUAPrgvgmkjLRc04PGTd+ShK?=
 =?iso-8859-1?Q?MuMKU6zGY88UtsUDV9L/1YcKu1AQdSbfyDu08EZ41Y9MRSz0OaFj2eIjlR?=
 =?iso-8859-1?Q?uEKYiixHIT/S3iAyWbfQ0GRes+QOQpirC/sFnpg786cNpdFyY8yOAe50mO?=
 =?iso-8859-1?Q?38VWsVeP7KthGTb4yv4ZTtGl2HPag5dxdlgx7/i8y1WHn2yp6G75xi0yPV?=
 =?iso-8859-1?Q?JmH9I9kOGskznz03/N+ba8ZJQeHCr9XaCjFDjI8uy5ciDaPbevGUIKu4bu?=
 =?iso-8859-1?Q?NawWwQlxy+V572LjUjsDUbYgMIzG1g7JNWdfylAMTshZeEIapoccv5NhJU?=
 =?iso-8859-1?Q?4e269nRlVEx5ac7gd4MkX6sbPL6ne5LNwZ0U//AwD2PQcyzp8rSZivwxpm?=
 =?iso-8859-1?Q?PFpGS6gcAQ4rW2kM9eLreqYXOlp9rWE5BvuMM101DakaDe4P/J3j1zqlLv?=
 =?iso-8859-1?Q?SGRuOvNjPgZkDxwl0dq5pm01p5S9za73Uiif153+6cbR7tmLV+3cFOYePp?=
 =?iso-8859-1?Q?+KHSsjinXg7wq8FbApke0hePnt5/lmT45YkXkDNKPLG7JkkJgIFbJf5We2?=
 =?iso-8859-1?Q?vtvu6SCe8ny13MwxPch6Ldve6/ZmqP1Y/sRMqTyb3wkqwU2NBjkYElakxb?=
 =?iso-8859-1?Q?GesN49bkOCr8RLfmFe5jdR+QBq8gSplV8zsgdvRzPgczGaDZvRQiFGbBAP?=
 =?iso-8859-1?Q?b7by3Bq9EVLM103L2epdhOS2t77kUHUIFDGNjyaQn+QKTWqI1HssO8ov7a?=
 =?iso-8859-1?Q?RbRHGpd/gIxPADXzncLaGMIqDxABlwozz7AB/hobE0yoNzRlNm9hP9wB/4?=
 =?iso-8859-1?Q?gx8LqnW/zUkXzuiqB1Amc1ps4bHaF0p8C1tBCis3TLI93tqct0AYCLzyBA?=
 =?iso-8859-1?Q?K5CErusl6UlvLH7omsiRof55C8mUwXz1SutkWOGNUIgsz3XCSPtrLhvkmP?=
 =?iso-8859-1?Q?72QoygpYC/RIXJjuE9D1aQYk/LgZtT9dMYR++rsUdZY5ppqtJ5qSyFRnsM?=
 =?iso-8859-1?Q?KYb3oUNqh/EHKxMXB1bmLSgeczFDJvCGNHwblO7yzc0XbnCefce5z6NbRn?=
 =?iso-8859-1?Q?FqEnBMEpsKctX7Yzhw2GlGXtKKwF/aIjT3WuYRgkPRmM0f+J7ruOQ0qVWB?=
 =?iso-8859-1?Q?cS0YjiZjdnfNLotZyUnnyVDYJpx6X+Xn1dfZx83icDJD+1zHFv3jxFqXVg?=
 =?iso-8859-1?Q?I2+5zVwUqUpG3MVNLhDftFUGLgElwNwFhY2DIl58EC+CmLh7sI/Wt4INyU?=
 =?iso-8859-1?Q?w0Y+lmmRTHcgst1u1uZ6oET2JI9TNJnayc05MjgBh4eIC0ySSoPXljhMnn?=
 =?iso-8859-1?Q?/3IFa9Jm7ri7e6gw17Y68uhfCV+SCUrnmtPdH6HhQwz/TqasrPHBMNHPit?=
 =?iso-8859-1?Q?8bgZM5EHacnBkdXiSam3DdHy8mHNc9evhvE5WC09qk7G6nWTYagB0mCuow?=
 =?iso-8859-1?Q?Ijup749aTudKiJUDnjr92SYgJ4U6Kc5DOXCT67ZWoL2RNSoAZdddkiQuxP?=
 =?iso-8859-1?Q?fkI/YgrzDxFxKY9EmYvHMcyPMmypS69MkaTUXqKdsXBkpm6sBHnTIkEg?=
 =?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: 95e81a22-72ef-4c32-5443-08dda9a28edd
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2025 11:16:20.2945
 (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: ZKYm+AO8eRr3lhomFpvgGWJBiZWyl989GyaYuD23WkF284bM/DV2wYqJHzOo1BZI+PQGSkdKRQHTWrUOdsrJSQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR03MB10784

This series adds support for R-Car Gen4 PCI host controller.

To fully support the controller, the following changes were made:
- Generic mechanism to support PCI child buses is added.
- Private data for PCI host bridge and means to access it are added.

The series was tested as a part of the pci-passthrough patches[1] and
build-tested standalone with enabled HAS_PCI and HAS_VPCI.
CI pipeline results: [2]

[1]: https://github.com/Deedone/xen/tree/pci_passthrough_wip
[2]: https://gitlab.com/xen-project/people/mpoturai/xen/-/pipelines/1828720=
661

v5->v6:
* see individual patches

v4->v5:
* see individual patches

v3->v4:
* rebase
* see individual patches

v2->v3:
* dropped patches related to ATU programming delay
* improved formatting

v1->v2:
* see individual patches

Oleksandr Andrushchenko (4):
  xen/arm: allow PCI host bridge to have private data
  xen/arm: make pci_host_common_probe return the bridge
  xen/arm: add support for PCI child bus
  xen/arm: add support for R-Car Gen4 PCI host controller

 MAINTAINERS                         |   5 +
 xen/arch/arm/include/asm/pci.h      |  22 +-
 xen/arch/arm/pci/Makefile           |   2 +
 xen/arch/arm/pci/ecam.c             |   1 +
 xen/arch/arm/pci/pci-access.c       |  37 ++-
 xen/arch/arm/pci/pci-designware.c   | 405 ++++++++++++++++++++++++++++
 xen/arch/arm/pci/pci-designware.h   |  90 +++++++
 xen/arch/arm/pci/pci-host-common.c  |  92 +++++--
 xen/arch/arm/pci/pci-host-generic.c |   2 +-
 xen/arch/arm/pci/pci-host-rcar4.c   |  94 +++++++
 xen/arch/arm/pci/pci-host-zynqmp.c  |   3 +-
 xen/arch/arm/vpci.c                 |  91 +++++--
 12 files changed, 796 insertions(+), 48 deletions(-)
 create mode 100644 xen/arch/arm/pci/pci-designware.c
 create mode 100644 xen/arch/arm/pci/pci-designware.h
 create mode 100644 xen/arch/arm/pci/pci-host-rcar4.c

--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 11:16:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 11:16:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012880.1391414 (Exim 4.92)
	(envelope-from )
	id 1uPfvE-00041C-JX; Thu, 12 Jun 2025 11:16:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012880.1391414; Thu, 12 Jun 2025 11:16: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 1uPfvE-000414-GK; Thu, 12 Jun 2025 11:16:40 +0000
Received: by outflank-mailman (input) for mailman id 1012880;
 Thu, 12 Jun 2025 11:16: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 1uPfvD-0003Ie-5G
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 11:16:39 +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 b4a650c9-477e-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 13:16:37 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by VI0PR03MB10784.eurprd03.prod.outlook.com
 (2603:10a6:800:262::7) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8813.27; Thu, 12 Jun
 2025 11:16:21 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971%6]) with mapi id 15.20.8835.018; Thu, 12 Jun 2025
 11:16: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: b4a650c9-477e-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=F5eKVB6cMa0yiwizwtlxyXYfrsqJNfU9KFTz9hNduuD7obh9kXu1rZfG4yke2jbOEcvRmSuBtCe3BSRg//9IUSD3ljfMx3+26LDBubBpEWG/Gl648hBtmJMWms/wG/ZSyTLgN9dCXaSf5t1Fz7wdXEoVLIZl0kIgcmzaV/QF7OTfojICbYX6nqwrBAgeEZotYwpeV1ZwzshKZXsfGw2GPuAKvLKn+OmnwEOIL+xTgWlTNesWNnlgt41Lj9Dx8lP1iCllG/gw1rX9BLyis9bPRU0ISGK3uZ7DrMASDSzCsWMKyE85nYtqK8w4hRIYwguvYsQJut6e8UeJVXCszIYltQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=NGxZrYExnUTLUTU0BX+8dVladrci2YqFWzX3+Z3Tp0k=;
 b=tQns+Aqkwk50MFxTgrJ5gOQ7gOBMFTE+o8d7nSo4qMetty4droW3AUMJVSYBcU99FPSAiLKfzMn87fOONkNTg4EJ8TbR4MMiP9nNb/r7uV5ct+/z09L5LU6u+1UOWd6VloY9fkaBcJyvkhI5ITUMuTlQYSQfBIlzI0CmNySxOJ9qSkJ7OTzeybonFrkLtBp/AIQ+DN8VjORWLt3EXJkR05F5pgcU/CcMLqXE7SW/hfXKcZyebvSdv0LRmQ9RBaGQVU5nUZT6aDYy11L+ymGemErHPX1cMZuQPQnrqrwXB+jv2nOAHP/laSSEwz04Vn2ny0CI/wjAspIkv057Loi1hw==
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=NGxZrYExnUTLUTU0BX+8dVladrci2YqFWzX3+Z3Tp0k=;
 b=k1i56hM4WV+ctx04RKOZaRPHHS/AGqzEWWcTlDyjUSnfVLqcldkg0Qtyh/pHoDB4cY9J400dXOVfbE4Q5kYGplvF+TzYx/xIh+FgysAjIVTVIYcVfm5wiu6OE4cfzyBKunnv/QUy7HOnNAOa1HVym2iAy+x9XD7LZq252O1ArKXvsg8isv1SLq2TPbZjsSu4cBX0VsC9uiJDSuwmehFU3waDMDfxyPMk+hClEZvx3N7u8IADaaP+KZXtcIFc6ykTzddAgYqtBoSKYOoC5BTbC0lTTNhT4x1qcBeqlPn648Q4xVDDsiF5YgB943iwiIUJSoy5JKu9NcbEQN/JPKOrNA==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Oleksandr Andrushchenko , Stefano
 Stabellini , Julien Grall , Bertrand
 Marquis , Michal Orzel ,
	Volodymyr Babchuk , Mykyta Poturai
	
Subject: [PATCH v6 3/4] xen/arm: add support for PCI child bus
Thread-Topic: [PATCH v6 3/4] xen/arm: add support for PCI child bus
Thread-Index: AQHb24ttVkZxL8stp0eAfUdym5ZRRg==
Date: Thu, 12 Jun 2025 11:16:21 +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_|VI0PR03MB10784:EE_
x-ms-office365-filtering-correlation-id: 3216da05-ff99-40d5-5acd-08dda9a28fbd
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?S77sEz/cIp/uGOMkwzeMfc0clpjH+nuDCyFabFSmGGzqwg+EF/Jtusg4kx?=
 =?iso-8859-1?Q?XzziZnZmX96siocV1ZI14yPw4LmkPDsOoydpADoML1iOG3tReirrYvWXMS?=
 =?iso-8859-1?Q?phQPZwogNKPQJwBq5Vf+PpJ3W2efniMM14MUjsQ+JuqzE7M7bvuSPTz0Mp?=
 =?iso-8859-1?Q?c23CeU2CpHf6GWgbpBqXufGaZ8ye3KvosaVVmKb/BTPNB7p6BbGvP5AU5n?=
 =?iso-8859-1?Q?vvPojpfXwkw6SLBvtTTAU0cXY9Tmr/hDD/qko9BJbqPYIEFFjxad0NWH16?=
 =?iso-8859-1?Q?93oAF/FPoEo0N+JXvov1xnCGOwHIL4adGgSnsr9ehnh1lwBbAmH3dWrAJK?=
 =?iso-8859-1?Q?eymbVW17uiFxdI7utS79qUZpgHmdGQ2XWMFvOPn9IPMpCYqEaDD/CcIVch?=
 =?iso-8859-1?Q?JF1dDw9UlNxvAwCf/WKaI7A+Hzn2wSthLEkuMVCsf9nK0mlrhEg9NFu8x6?=
 =?iso-8859-1?Q?uKPH1uuNApXExCarYjwt9XG/jXbEWXd1jI8KsHIya1V3b6NzOngyXfdbwO?=
 =?iso-8859-1?Q?7rSuKT1TwtFhzRZLJtMuzoTFKM/rscATwjRJ87XZIe9ATWRmUlYHizDsiH?=
 =?iso-8859-1?Q?Eof6F4z3/MU0MvBNWETA8hoHYiGBY+lcY2ZA4D7vEFzVyo8sDWLTkRPZ5/?=
 =?iso-8859-1?Q?yEq2TyrPjIv4ZwAwoVHMBoLqC1EQpYlVS1l3xPpqOtx7qU4cXHKCs+FXoI?=
 =?iso-8859-1?Q?Hh4yZm1kWTixVkXnubkgkXnZ7I9+LsIIuIZfFmFtGDCb3mhIGpYZ2sP6VY?=
 =?iso-8859-1?Q?IgshzG+eaHgwuYADebGhF/QG9AsLtaZRRXTtR+5j1hyAbt4qUyatsXAP07?=
 =?iso-8859-1?Q?YDxAiwfk6ppJcmJ8wHHSZsiLLjOCMLOK3wQ50DvwEIAdvDMYxlsddb0v8k?=
 =?iso-8859-1?Q?M7JhY/Nfm/hYMyRiQE7BY5tRK+f1rUgauzXYYYitCvj+aK6JxnbSeksP3w?=
 =?iso-8859-1?Q?yUhVixGElN0LJ4bjO7cvS2ihetUI9j0NF1IdezG1rn/Z/3k2adkNxjVaka?=
 =?iso-8859-1?Q?/DeYHI2WtP16f2u4PAp0UKa2NE9jVY+/yCGmBBp64XtP0a6Y/LeOg/B7BO?=
 =?iso-8859-1?Q?nd5Aih4NH21Eyh9bPvQh3/+0sNtqtnwNdQMoww3xXkHuYgprucM4jFQHkR?=
 =?iso-8859-1?Q?lVEVBWz64PHmFLenjABfXf22uV2CqkcmUlrA/Epn/8L1ewDlYbQX933PdU?=
 =?iso-8859-1?Q?LTbNwlM+AuwXl2DLd90AjYpeojtUPtXIA6BQSK9jSBcqasrk5ZRRWdR4/u?=
 =?iso-8859-1?Q?tkw0KFfnrPuD81HrRZoyUqjPNTptPeqsX1nQ43xCUWqjzyevgixSJaA/Zl?=
 =?iso-8859-1?Q?MQ6sLdAfaoAggkMBaleLiNUWdpDEUvy1KR4x1YgQBjvfe6CNMGelpxIDJN?=
 =?iso-8859-1?Q?6egnOhCEkDZLfjbO+OTNLpR7uTdjS3K3CG8x6V1TdqFpijQy3Rw6KuW5x7?=
 =?iso-8859-1?Q?Ufa+vQxCRtVBBWPjXH4i05KjD4hcSVuch47wKkkCMh2IiVM5T0+y0UekMM?=
 =?iso-8859-1?Q?A=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)(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?+iLcXJtkHoZWKRSRKx/+XZOQ1hAYat+ETW/0SFqgPGJToM/uPdfaxRewXy?=
 =?iso-8859-1?Q?GqWqSN5saGJfVFDNT/LImlPyyDEYMJAgGmpeG+zRp9OoPuh9CXYNPUxFHi?=
 =?iso-8859-1?Q?YuidmdZ8gcWilYvwIAk+b/a/jCSZUwsrFKrG864cR3NDPUroDakeEu0IYq?=
 =?iso-8859-1?Q?uwcFVpN/AloN6kHpG1CQiWRcqTCOftAXLnuUaxKYUQ8V4uybhCSvzi7K0n?=
 =?iso-8859-1?Q?p6mN9bunj1s4aa+duJ0UoBNVedLO5xzWaLMOGncPPp1gTBgJZVlGqvX3HH?=
 =?iso-8859-1?Q?+EGp6Qs+cGZ8gNGJ4mIGyOOGVy5POC6bj1f0HR/YmK2PujCmAFxwXwZmFm?=
 =?iso-8859-1?Q?iTkzKQbBPjYgLbNjtbZzrR20g/JmanlfSeJCYAYjUjvFwrnW1k5iuNnPVy?=
 =?iso-8859-1?Q?TBwlwJp+IMfE5yo8sc4aW+rOkT5FDdiICJHc+v9H+yrpvD74n1Y9lz3r/8?=
 =?iso-8859-1?Q?/iqRqESjzT+N9Mo9xOZ54mmOmRRWjUruzGMirjo69XY0DlgWstRTO9wbDh?=
 =?iso-8859-1?Q?PTW+1D7lkIkcXWIqiogNA+JcbfDRqrbTK1aIFdr+tG3R6T7i2AYUnG27OM?=
 =?iso-8859-1?Q?/McFyRgjF7bIC6Z2inW8rDx1GE6jSTDV75fbwBFu1u7zvzvbxaHxgo2tf6?=
 =?iso-8859-1?Q?g65OG608FXdT796T0FI16DLSIJH1B0+vwxSSwAXmuJSgmqfyvNPzeNyyga?=
 =?iso-8859-1?Q?I1R7Fkt5a48eKwOvzRPEfogxzJ2uiHSLPsMueFBAN9AIN72Hp6ONSPEw6o?=
 =?iso-8859-1?Q?5Tir8rKhrLorO4yC5BvBjWKHK/wOwVQyGKT+ajY4eYOP5urms3jqfhpR6F?=
 =?iso-8859-1?Q?IarDCmF4YVrCtAO/X9vIUuZBYDk7sI+rJa0Z3z6p8ROTxlB/K6xA0kxhw4?=
 =?iso-8859-1?Q?A5RMOeLtwjSJZ8QDI2pRXsqgqR7kw0Yd2s7ldtpHRrvCECoHanzPBFTwQR?=
 =?iso-8859-1?Q?5dDs6MFtHRnGjDNk8NoOBMAAuA0cNQV/MaanKBrausbsGTNnRJL5nLSGV4?=
 =?iso-8859-1?Q?iMddZ20NMj63PMzv6/1LbJBLNB7vjR+DC8HJ1AKybeFkvbayaZpBBr7h55?=
 =?iso-8859-1?Q?x0wvnIhkge7Cfn2OPCAlcoO/i8RcbKmx1dAqSe0pu9umCc/1hfGdHRddTK?=
 =?iso-8859-1?Q?k8YQUCDzeHrvmEOw2HlROWNIZnzmxj3GmqX4aREAO+R4BnpWCaZpVUI6IW?=
 =?iso-8859-1?Q?5JiZqdaGAlvjCZfbcoNbARyqWMwILudmBX9pXNOG7wTWB19Nme1vjnGcjz?=
 =?iso-8859-1?Q?RypLdUKixjPdQuRfGKrWRYLgT+A54Co2Ci2jzeOnSr6ybbC20wMDRoURZn?=
 =?iso-8859-1?Q?9U0mnLMJeUYIBkVcNTX7rPzSjwE0/BhLBvYq+9GmUO8wjHfmijVfZ6T221?=
 =?iso-8859-1?Q?o82/pFr4zy0AEHV06YuJsj08PFiHAuDHPdCDBPA3OUjuS3sF032dVcm210?=
 =?iso-8859-1?Q?2iLvq74Y+0O/KST7D0abE5OqK/6SaOOaMrwjrohod+DLw5o1LzL9qqA2Gz?=
 =?iso-8859-1?Q?e7HdzQ7jPg+yWywP+vkVeJ7tAbBJ9NKgYnlh+xK8zrRVF9HzXI3T3bwu8x?=
 =?iso-8859-1?Q?6WcgfWSJigmWIXkZaU6gb+gS4txrOyJm2rEGDMegjJBa6Ad13uWo8gsFL1?=
 =?iso-8859-1?Q?YvumlLJKl59aKdSnJChj4kIxfFANqowXc+DKN4NMvcriyOrw/X+tRQhg?=
 =?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: 3216da05-ff99-40d5-5acd-08dda9a28fbd
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2025 11:16:21.5421
 (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: pc8RF9CMjxfOq7eS7eZCLTMVO6koDyhji0NkDFXfELDj6LD2PXOHEEPdIv1y6MilARRoVfTXRn0LZ7CLxqPv2Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR03MB10784

From: Oleksandr Andrushchenko 

PCI host bridges often have different ways to access the root and child
bus configuration spaces. One of the examples is Designware's host bridge
and its multiple clones [1].

Linux kernel implements this by instantiating a child bus when device
drivers provide not only the usual pci_ops to access ECAM space (this is
the case for the generic host bridge), but also means to access the child
bus which has a dedicated configuration space and own implementation for
accessing the bus, e.g. child_ops.

For Xen it is not feasible to fully implement PCI bus infrastructure as
Linux kernel does, but still child bus can be supported.

Add support for the PCI child bus which includes the following changes:
- introduce bus mapping functions depending on SBDF
- assign bus start and end for the child bus and re-configure the same for
  the parent (root) bus
- make pci_find_host_bridge be aware of multiple busses behind the same bri=
dge
- update pci_host_bridge_mappings, so it also doesn't map to guest the memo=
ry
  spaces belonging to the child bus
- make pci_host_common_probe accept one more pci_ops structure for the chil=
d bus
- install MMIO handlers for the child bus for hardware domain
- re-work vpci_mmio_{write|read} with parent and child approach in mind

[1] https://elixir.bootlin.com/linux/v5.15/source/drivers/pci/controller/dw=
c

Signed-off-by: Oleksandr Andrushchenko 
Signed-off-by: Mykyta Poturai 
---
v5->v6:
* no change

v4->v5:
* fix formatting
* move init_bus_range inside pci_ops
* fix logic error in pci_host_bridge_mappings again

v3->v4:
* remove changes to pci_ecam_map_bus
* make map_bus inline
* fix logic error in pci_host_bridge_mappings

v2->v3:
* no change

v1->v2:
* fixed compilation issues
---
 xen/arch/arm/include/asm/pci.h      | 20 ++++++-
 xen/arch/arm/pci/ecam.c             |  1 +
 xen/arch/arm/pci/pci-access.c       | 37 ++++++++++--
 xen/arch/arm/pci/pci-host-common.c  | 84 +++++++++++++++++++++-----
 xen/arch/arm/pci/pci-host-generic.c |  2 +-
 xen/arch/arm/pci/pci-host-zynqmp.c  |  3 +-
 xen/arch/arm/vpci.c                 | 91 +++++++++++++++++++++++------
 7 files changed, 194 insertions(+), 44 deletions(-)

diff --git a/xen/arch/arm/include/asm/pci.h b/xen/arch/arm/include/asm/pci.=
h
index 061d9810af..3772d7c7d2 100644
--- a/xen/arch/arm/include/asm/pci.h
+++ b/xen/arch/arm/include/asm/pci.h
@@ -67,6 +67,9 @@ struct pci_host_bridge {
     uint16_t segment;                /* Segment number */
     struct pci_config_window* cfg;   /* Pointer to the bridge config windo=
w */
     const struct pci_ops *ops;
+    /* Child bus */
+    struct pci_config_window *child_cfg;
+    const struct pci_ops *child_ops;
     void *priv;                      /* Private data of the bridge. */
 };
=20
@@ -80,6 +83,9 @@ struct pci_ops {
     bool (*need_p2m_hwdom_mapping)(struct domain *d,
                                    struct pci_host_bridge *bridge,
                                    uint64_t addr);
+    void (*init_bus_range)(struct dt_device_node *dev,
+                           struct pci_host_bridge *bridge,
+                           struct pci_config_window *cfg);
 };
=20
 /*
@@ -96,8 +102,10 @@ struct pci_ecam_ops {
 /* Default ECAM ops */
 extern const struct pci_ecam_ops pci_generic_ecam_ops;
=20
-struct pci_host_bridge *pci_host_common_probe(struct dt_device_node *dev,
-                                              const struct pci_ecam_ops *o=
ps);
+struct pci_host_bridge *
+pci_host_common_probe(struct dt_device_node *dev,
+                      const struct pci_ecam_ops *ops,
+                      const struct pci_ecam_ops *child_ops);
 int pci_generic_config_read(struct pci_host_bridge *bridge, pci_sbdf_t sbd=
f,
                             uint32_t reg, uint32_t len, uint32_t *value);
 int pci_generic_config_write(struct pci_host_bridge *bridge, pci_sbdf_t sb=
df,
@@ -133,6 +141,14 @@ bool pci_check_bar(const struct pci_dev *pdev, mfn_t s=
tart, mfn_t end);
 static inline int pci_sanitize_bar_memory(struct rangeset *r)
 { return 0; }
=20
+void pci_generic_init_bus_range(struct dt_device_node *dev,
+                                struct pci_host_bridge *bridge,
+                                struct pci_config_window *cfg);
+
+void pci_generic_init_bus_range_child(struct dt_device_node *dev,
+                                      struct pci_host_bridge *bridge,
+                                      struct pci_config_window *cfg);
+
 #else   /*!CONFIG_HAS_PCI*/
=20
 struct pci_dev;
diff --git a/xen/arch/arm/pci/ecam.c b/xen/arch/arm/pci/ecam.c
index 3987f96b01..c979af7302 100644
--- a/xen/arch/arm/pci/ecam.c
+++ b/xen/arch/arm/pci/ecam.c
@@ -60,6 +60,7 @@ const struct pci_ecam_ops pci_generic_ecam_ops =3D {
         .read                   =3D pci_generic_config_read,
         .write                  =3D pci_generic_config_write,
         .need_p2m_hwdom_mapping =3D pci_ecam_need_p2m_hwdom_mapping,
+        .init_bus_range         =3D pci_generic_init_bus_range,
     }
 };
=20
diff --git a/xen/arch/arm/pci/pci-access.c b/xen/arch/arm/pci/pci-access.c
index 9f9aac43d7..4a94867501 100644
--- a/xen/arch/arm/pci/pci-access.c
+++ b/xen/arch/arm/pci/pci-access.c
@@ -18,10 +18,31 @@
 #define INVALID_VALUE (~0U)
 #define PCI_ERR_VALUE(len) GENMASK(0, len * 8)
=20
+static const struct pci_ops *get_ops(struct pci_host_bridge *bridge,
+                                     pci_sbdf_t sbdf)
+{
+    if ( bridge->child_ops )
+    {
+        struct pci_config_window *cfg =3D bridge->child_cfg;
+
+        if ( (sbdf.bus >=3D cfg->busn_start) && (sbdf.bus <=3D cfg->busn_e=
nd) )
+            return bridge->child_ops;
+    }
+    return bridge->ops;
+}
+
+static inline void __iomem *map_bus(struct pci_host_bridge *bridge,
+                                    pci_sbdf_t sbdf, uint32_t reg)
+{
+    const struct pci_ops *ops =3D get_ops(bridge, sbdf);
+
+    return ops->map_bus(bridge, sbdf, reg);
+}
+
 int pci_generic_config_read(struct pci_host_bridge *bridge, pci_sbdf_t sbd=
f,
                             uint32_t reg, uint32_t len, uint32_t *value)
 {
-    void __iomem *addr =3D bridge->ops->map_bus(bridge, sbdf, reg);
+    void __iomem *addr =3D map_bus(bridge, sbdf, reg);
=20
     if ( !addr )
     {
@@ -50,7 +71,7 @@ int pci_generic_config_read(struct pci_host_bridge *bridg=
e, pci_sbdf_t sbdf,
 int pci_generic_config_write(struct pci_host_bridge *bridge, pci_sbdf_t sb=
df,
                              uint32_t reg, uint32_t len, uint32_t value)
 {
-    void __iomem *addr =3D bridge->ops->map_bus(bridge, sbdf, reg);
+    void __iomem *addr =3D map_bus(bridge, sbdf, reg);
=20
     if ( !addr )
         return -ENODEV;
@@ -78,14 +99,16 @@ static uint32_t pci_config_read(pci_sbdf_t sbdf, unsign=
ed int reg,
 {
     uint32_t val =3D PCI_ERR_VALUE(len);
     struct pci_host_bridge *bridge =3D pci_find_host_bridge(sbdf.seg, sbdf=
.bus);
+    const struct pci_ops *ops;
=20
     if ( unlikely(!bridge) )
         return val;
=20
-    if ( unlikely(!bridge->ops->read) )
+    ops =3D get_ops(bridge, sbdf);
+    if ( unlikely(!ops->read) )
         return val;
=20
-    bridge->ops->read(bridge, sbdf, reg, len, &val);
+    ops->read(bridge, sbdf, reg, len, &val);
=20
     return val;
 }
@@ -94,14 +117,16 @@ static void pci_config_write(pci_sbdf_t sbdf, unsigned=
 int reg,
                              unsigned int len, uint32_t val)
 {
     struct pci_host_bridge *bridge =3D pci_find_host_bridge(sbdf.seg, sbdf=
.bus);
+    const struct pci_ops *ops;
=20
     if ( unlikely(!bridge) )
         return;
=20
-    if ( unlikely(!bridge->ops->write) )
+    ops =3D get_ops(bridge, sbdf);
+    if ( unlikely(!ops->write) )
         return;
=20
-    bridge->ops->write(bridge, sbdf, reg, len, val);
+    ops->write(bridge, sbdf, reg, len, val);
 }
=20
 /*
diff --git a/xen/arch/arm/pci/pci-host-common.c b/xen/arch/arm/pci/pci-host=
-common.c
index 53953d4895..487c545f3a 100644
--- a/xen/arch/arm/pci/pci-host-common.c
+++ b/xen/arch/arm/pci/pci-host-common.c
@@ -57,17 +57,12 @@ static void pci_ecam_free(struct pci_config_window *cfg=
)
     xfree(cfg);
 }
=20
-static struct pci_config_window * __init
-gen_pci_init(struct dt_device_node *dev, const struct pci_ecam_ops *ops)
+void __init pci_generic_init_bus_range(struct dt_device_node *dev,
+                                       struct pci_host_bridge *bridge,
+                                       struct pci_config_window *cfg)
 {
-    int err, cfg_reg_idx;
     u32 bus_range[2];
-    paddr_t addr, size;
-    struct pci_config_window *cfg;
-
-    cfg =3D xzalloc(struct pci_config_window);
-    if ( !cfg )
-        return NULL;
+    int err;
=20
     err =3D dt_property_read_u32_array(dev, "bus-range", bus_range,
                                      ARRAY_SIZE(bus_range));
@@ -82,6 +77,35 @@ gen_pci_init(struct dt_device_node *dev, const struct pc=
i_ecam_ops *ops)
         if ( cfg->busn_end > cfg->busn_start + 0xff )
             cfg->busn_end =3D cfg->busn_start + 0xff;
     }
+}
+
+void __init pci_generic_init_bus_range_child(struct dt_device_node *dev,
+                                             struct pci_host_bridge *bridg=
e,
+                                             struct pci_config_window *cfg=
)
+{
+    cfg->busn_start =3D bridge->cfg->busn_start + 1;
+    cfg->busn_end =3D bridge->cfg->busn_end;
+    bridge->cfg->busn_end =3D bridge->cfg->busn_start;
+
+    printk(XENLOG_INFO "Root bus end updated: [bus %x-%x]\n",
+           bridge->cfg->busn_start, bridge->cfg->busn_end);
+}
+
+static struct pci_config_window *__init
+gen_pci_init(struct dt_device_node *dev, struct pci_host_bridge *bridge,
+             const struct pci_ecam_ops *ops)
+{
+    int err, cfg_reg_idx;
+    paddr_t addr, size;
+    struct pci_config_window *cfg;
+
+    cfg =3D xzalloc(struct pci_config_window);
+    if ( !cfg )
+        return NULL;
+    if ( !ops || !ops->pci_ops.init_bus_range )
+        goto err_exit;
+
+    ops->pci_ops.init_bus_range(dev, bridge, cfg);
=20
     if ( ops->cfg_reg_index )
     {
@@ -208,8 +232,10 @@ static int pci_bus_find_domain_nr(struct dt_device_nod=
e *dev)
     return domain;
 }
=20
-struct pci_host_bridge *pci_host_common_probe(struct dt_device_node *dev,
-                                              const struct pci_ecam_ops *o=
ps)
+struct pci_host_bridge *
+pci_host_common_probe(struct dt_device_node *dev,
+                      const struct pci_ecam_ops *ops,
+                      const struct pci_ecam_ops *child_ops)
 {
     struct pci_host_bridge *bridge;
     struct pci_config_window *cfg;
@@ -224,7 +250,7 @@ struct pci_host_bridge *pci_host_common_probe(struct dt=
_device_node *dev,
         return ERR_PTR(-ENOMEM);
=20
     /* Parse and map our Configuration Space windows */
-    cfg =3D gen_pci_init(dev, ops);
+    cfg =3D gen_pci_init(dev, bridge, ops);
     if ( !cfg )
     {
         err =3D -ENOMEM;
@@ -242,10 +268,28 @@ struct pci_host_bridge *pci_host_common_probe(struct =
dt_device_node *dev,
         BUG();
     }
     bridge->segment =3D domain;
+
+    if ( child_ops )
+    {
+        /* Parse and map child's Configuration Space windows */
+        cfg =3D gen_pci_init(dev, bridge, child_ops);
+        if ( !cfg )
+        {
+            err =3D -ENOMEM;
+            goto err_child;
+        }
+
+        bridge->child_cfg =3D cfg;
+        bridge->child_ops =3D &child_ops->pci_ops;
+    }
+
     pci_add_host_bridge(bridge);
=20
     return bridge;
=20
+err_child:
+    xfree(bridge->cfg);
+
 err_exit:
     xfree(bridge);
=20
@@ -280,9 +324,12 @@ struct pci_host_bridge *pci_find_host_bridge(uint16_t =
segment, uint8_t bus)
     {
         if ( bridge->segment !=3D segment )
             continue;
-        if ( (bus < bridge->cfg->busn_start) || (bus > bridge->cfg->busn_e=
nd) )
-            continue;
-        return bridge;
+        if ( bridge->child_cfg && (bus >=3D bridge->child_cfg->busn_start)=
 &&
+             (bus <=3D bridge->child_cfg->busn_end) )
+            return bridge;
+        if ( (bus >=3D bridge->cfg->busn_start) &&
+             (bus <=3D bridge->cfg->busn_end) )
+            return bridge;
     }
=20
     return NULL;
@@ -348,6 +395,7 @@ int __init pci_host_bridge_mappings(struct domain *d)
     {
         const struct dt_device_node *dev =3D bridge->dt_node;
         unsigned int i;
+        bool need_mapping;
=20
         for ( i =3D 0; i < dt_number_of_address(dev); i++ )
         {
@@ -363,7 +411,11 @@ int __init pci_host_bridge_mappings(struct domain *d)
                 return err;
             }
=20
-            if ( bridge->ops->need_p2m_hwdom_mapping(d, bridge, addr) )
+            need_mapping =3D bridge->ops->need_p2m_hwdom_mapping(d, bridge=
, addr);
+            if ( !need_mapping && bridge->child_ops )
+                need_mapping =3D
+                    bridge->child_ops->need_p2m_hwdom_mapping(d, bridge, a=
ddr);
+            if ( need_mapping )
             {
                 err =3D map_range_to_domain(dev, addr, size, &mr_data);
                 if ( err )
diff --git a/xen/arch/arm/pci/pci-host-generic.c b/xen/arch/arm/pci/pci-hos=
t-generic.c
index a6ffbda174..47cf144831 100644
--- a/xen/arch/arm/pci/pci-host-generic.c
+++ b/xen/arch/arm/pci/pci-host-generic.c
@@ -29,7 +29,7 @@ static const struct dt_device_match __initconstrel gen_pc=
i_dt_match[] =3D
 static int __init pci_host_generic_probe(struct dt_device_node *dev,
                                          const void *data)
 {
-    return PTR_RET(pci_host_common_probe(dev, &pci_generic_ecam_ops));
+    return PTR_RET(pci_host_common_probe(dev, &pci_generic_ecam_ops, NULL)=
);
 }
=20
 DT_DEVICE_START(pci_gen, "PCI HOST GENERIC", DEVICE_PCI_HOSTBRIDGE)
diff --git a/xen/arch/arm/pci/pci-host-zynqmp.c b/xen/arch/arm/pci/pci-host=
-zynqmp.c
index a38f2e019e..2c4afa7a19 100644
--- a/xen/arch/arm/pci/pci-host-zynqmp.c
+++ b/xen/arch/arm/pci/pci-host-zynqmp.c
@@ -35,6 +35,7 @@ const struct pci_ecam_ops nwl_pcie_ops =3D {
         .read                   =3D pci_generic_config_read,
         .write                  =3D pci_generic_config_write,
         .need_p2m_hwdom_mapping =3D pci_ecam_need_p2m_hwdom_mapping,
+        .init_bus_range         =3D pci_generic_init_bus_range,
     }
 };
=20
@@ -47,7 +48,7 @@ static const struct dt_device_match __initconstrel nwl_pc=
ie_dt_match[] =3D
 static int __init pci_host_generic_probe(struct dt_device_node *dev,
                                          const void *data)
 {
-    return PTR_RET(pci_host_common_probe(dev, &nwl_pcie_ops));
+    return PTR_RET(pci_host_common_probe(dev, &nwl_pcie_ops, NULL));
 }
=20
 DT_DEVICE_START(pci_gen, "PCI HOST ZYNQMP", DEVICE_PCI_HOSTBRIDGE)
diff --git a/xen/arch/arm/vpci.c b/xen/arch/arm/vpci.c
index 0ce11ffcc5..d41aa383a8 100644
--- a/xen/arch/arm/vpci.c
+++ b/xen/arch/arm/vpci.c
@@ -8,15 +8,17 @@
 #include 
=20
 static pci_sbdf_t vpci_sbdf_from_gpa(const struct pci_host_bridge *bridge,
-                                     paddr_t gpa)
+                                     paddr_t gpa, bool use_root)
 {
     pci_sbdf_t sbdf;
=20
     if ( bridge )
     {
-        sbdf.sbdf =3D VPCI_ECAM_BDF(gpa - bridge->cfg->phys_addr);
+        const struct pci_config_window *cfg =3D use_root ? bridge->cfg
+                                                       : bridge->child_cfg=
;
+        sbdf.sbdf =3D VPCI_ECAM_BDF(gpa - cfg->phys_addr);
         sbdf.seg =3D bridge->segment;
-        sbdf.bus +=3D bridge->cfg->busn_start;
+        sbdf.bus +=3D cfg->busn_start;
     }
     else
         sbdf.sbdf =3D VPCI_ECAM_BDF(gpa - GUEST_VPCI_ECAM_BASE);
@@ -24,18 +26,14 @@ static pci_sbdf_t vpci_sbdf_from_gpa(const struct pci_h=
ost_bridge *bridge,
     return sbdf;
 }
=20
-static int vpci_mmio_read(struct vcpu *v, mmio_info_t *info,
-                          register_t *r, void *p)
+static int vpci_mmio_read(struct vcpu *v, mmio_info_t *info, register_t *r=
,
+                          pci_sbdf_t sbdf)
 {
-    struct pci_host_bridge *bridge =3D p;
-    pci_sbdf_t sbdf =3D vpci_sbdf_from_gpa(bridge, info->gpa);
     const unsigned int access_size =3D (1U << info->dabt.size) * 8;
     const register_t invalid =3D GENMASK_ULL(access_size - 1, 0);
     /* data is needed to prevent a pointer cast on 32bit */
     unsigned long data;
=20
-    ASSERT(!bridge =3D=3D !is_hardware_domain(v->domain));
-
     if ( vpci_ecam_read(sbdf, ECAM_REG_OFFSET(info->gpa),
                         1U << info->dabt.size, &data) )
     {
@@ -48,33 +46,86 @@ static int vpci_mmio_read(struct vcpu *v, mmio_info_t *=
info,
     return 0;
 }
=20
-static int vpci_mmio_write(struct vcpu *v, mmio_info_t *info,
-                           register_t r, void *p)
+static int vpci_mmio_read_root(struct vcpu *v, mmio_info_t *info, register=
_t *r,
+                               void *p)
+{
+    struct pci_host_bridge *bridge =3D p;
+    pci_sbdf_t sbdf =3D vpci_sbdf_from_gpa(bridge, info->gpa, true);
+
+    ASSERT(!bridge =3D=3D !is_hardware_domain(v->domain));
+
+    return vpci_mmio_read(v, info, r, sbdf);
+}
+
+static int vpci_mmio_read_child(struct vcpu *v, mmio_info_t *info,
+                                register_t *r, void *p)
 {
     struct pci_host_bridge *bridge =3D p;
-    pci_sbdf_t sbdf =3D vpci_sbdf_from_gpa(bridge, info->gpa);
+    pci_sbdf_t sbdf =3D vpci_sbdf_from_gpa(bridge, info->gpa, false);
=20
     ASSERT(!bridge =3D=3D !is_hardware_domain(v->domain));
=20
+    return vpci_mmio_read(v, info, r, sbdf);
+}
+
+static int vpci_mmio_write(struct vcpu *v, mmio_info_t *info, register_t r=
,
+                           pci_sbdf_t sbdf)
+{
     return vpci_ecam_write(sbdf, ECAM_REG_OFFSET(info->gpa),
                            1U << info->dabt.size, r);
 }
=20
+static int vpci_mmio_write_root(struct vcpu *v, mmio_info_t *info, registe=
r_t r,
+                                void *p)
+{
+    struct pci_host_bridge *bridge =3D p;
+    pci_sbdf_t sbdf =3D vpci_sbdf_from_gpa(bridge, info->gpa, true);
+
+    ASSERT(!bridge =3D=3D !is_hardware_domain(v->domain));
+
+    return vpci_mmio_write(v, info, r, sbdf);
+}
+
+static int vpci_mmio_write_child(struct vcpu *v, mmio_info_t *info,
+                                 register_t r, void *p)
+{
+    struct pci_host_bridge *bridge =3D p;
+    pci_sbdf_t sbdf =3D vpci_sbdf_from_gpa(bridge, info->gpa, false);
+
+    ASSERT(!bridge =3D=3D !is_hardware_domain(v->domain));
+
+    return vpci_mmio_write(v, info, r, sbdf);
+}
+
 static const struct mmio_handler_ops vpci_mmio_handler =3D {
-    .read  =3D vpci_mmio_read,
-    .write =3D vpci_mmio_write,
+    .read =3D vpci_mmio_read_root,
+    .write =3D vpci_mmio_write_root,
+};
+
+static const struct mmio_handler_ops vpci_mmio_handler_child =3D {
+    .read =3D vpci_mmio_read_child,
+    .write =3D vpci_mmio_write_child,
 };
=20
 static int vpci_setup_mmio_handler_cb(struct domain *d,
                                       struct pci_host_bridge *bridge)
 {
     struct pci_config_window *cfg =3D bridge->cfg;
+    int count =3D 1;
=20
     register_mmio_handler(d, &vpci_mmio_handler,
                           cfg->phys_addr, cfg->size, bridge);
=20
-    /* We have registered a single MMIO handler. */
-    return 1;
+    if ( bridge->child_ops )
+    {
+        struct pci_config_window *child_cfg =3D bridge->child_cfg;
+
+        register_mmio_handler(d, &vpci_mmio_handler_child, child_cfg->phys=
_addr,
+                              child_cfg->size, bridge);
+        count++;
+    }
+
+    return count;
 }
=20
 int domain_vpci_init(struct domain *d)
@@ -105,8 +156,12 @@ int domain_vpci_init(struct domain *d)
 static int vpci_get_num_handlers_cb(struct domain *d,
                                     struct pci_host_bridge *bridge)
 {
-    /* Each bridge has a single MMIO handler for the configuration space. =
*/
-    return 1;
+    int count =3D 1;
+
+    if ( bridge->child_cfg )
+        count++;
+
+    return count;
 }
=20
 unsigned int domain_vpci_get_num_mmio_handlers(struct domain *d)
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 11:16:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 11:16:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012881.1391425 (Exim 4.92)
	(envelope-from )
	id 1uPfvH-0004IT-5k; Thu, 12 Jun 2025 11:16:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012881.1391425; Thu, 12 Jun 2025 11:16: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 1uPfvH-0004IM-0W; Thu, 12 Jun 2025 11:16:43 +0000
Received: by outflank-mailman (input) for mailman id 1012881;
 Thu, 12 Jun 2025 11:16: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 1uPfvF-0003Ie-8H
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 11:16:41 +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 b5d328fe-477e-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 13:16:39 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by VI0PR03MB10784.eurprd03.prod.outlook.com
 (2603:10a6:800:262::7) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8813.27; Thu, 12 Jun
 2025 11:16:22 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971%6]) with mapi id 15.20.8835.018; Thu, 12 Jun 2025
 11:16: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: b5d328fe-477e-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=cez47yuZN4SkSK+xNo9IUFo/GiVASWRRCHFTugM9qaz4f86UyRo+7MHY12S3fG0p20rA8HWR4AjnQGlEh+zpuq1ItVOFEqxOwCXcM/FVpZqL/vEC0s96y5Lc4yZkKaEiw3u3UV+zqRoV8ym47C6v5wvK2t9UhGF5NoB5SbOZ2MrgZnZ6CoNUji/IBZlz4xo+OwQ0JeUBdG/ydO7t1C3dQh4aAxiswJki8u4sdUjCSs25tM0dxQyXiaa648xMKIV6QEzNQNIi5Cg57zoL8h6HPZQ75B/oVP9IkF6GcskV3hB6SXRn43HOSD3kWdvDhLFt9qBb4XpQ1FnCDKpfjovmZA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ZW3oPhbwyqpb63jaqZI/LnZpDkladiBWg8aHPYHwT78=;
 b=XQGXIwI8/zYht0CO7dyZciVyV80Y81C6PmryUAK7745DD8d2YEFOsNP3EcRkaYKDR6dEEfu57ambFL40ufebJNQTf2rde9IRjbMGfxOywDjeEtvkQEe1qzesczA6Qv6iANgiJkZbksDhqTOACOctfUmVE25Ma8T3Y/GYHxeTHlLgqTssSwDWRAH2mP3fCfZ9NuoCslsrF7XG0Xsk4hmmSBUWwUqhnyiITQEoVkVQquD2Z3qyIeG6u/t86HwP//rASAiP9ZOcHEqFFlsAPt6H+WbW7NSYbjzyKAzFE04aG4S4E2PTIePIIpn/QGrTsK6nc8/tDXShempt+WDrm4irTQ==
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=ZW3oPhbwyqpb63jaqZI/LnZpDkladiBWg8aHPYHwT78=;
 b=B1U/z5CcBlYPY/Djavx0lfW0FBCZlNdlvHPHKG6zIQ9Q7uVm6HAUbphNobSo7fcxl5R3HpWai08veXLoiELzojRE48mcMmgWxPMrTeIU9Rhce/Ye4UO2zsIVYchBcBw9yh8aOkVaH+DTV3pU4KqN68JpWUGH7JUFVoAtONM5SpWtuvLY+a/xt7GCzzICtps6XBSsEzhS8R/5E/alDTW7lK4IRYxlXXUKpDqdJVEMr8MVVlOCugU2seyY8FVlGRDKbX/KDl4LL4A0ogyNd2y5mV52uQnEbZGmnnDOWqNUCeLqUp7hADYT82McbW5Gdrw5I0UcOk+WSYZ41KUet/OINw==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Oleksandr Andrushchenko , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , Julien
 Grall , =?iso-8859-1?Q?Roger_Pau_Monn=E9?=
	, Stefano Stabellini , Bertrand
 Marquis , Volodymyr Babchuk
	, Mykyta Poturai 
Subject: [PATCH v6 4/4] xen/arm: add support for R-Car Gen4 PCI host
 controller
Thread-Topic: [PATCH v6 4/4] xen/arm: add support for R-Car Gen4 PCI host
 controller
Thread-Index: AQHb24ttPnKPJSHDUk21z2ePAbfy0w==
Date: Thu, 12 Jun 2025 11:16:22 +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_|VI0PR03MB10784:EE_
x-ms-office365-filtering-correlation-id: d37af90b-f4b1-4330-c948-08dda9a28fed
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?Q9jjTBoz8mWAulFc0JJY7Cj49drX6O1w+gIdBOQ2D79UTpi2DAPV1X5JJl?=
 =?iso-8859-1?Q?LSqF1nkOixGts4ON1WBP5d7I3z5p0FcPFY6X/azaQEcAAFVEEtpApuGL0c?=
 =?iso-8859-1?Q?x4XC1SGBVzZkISQK61GS2+pwOAhW3gO6+OnyQGRb0ydgDjg6WElPRRy+wS?=
 =?iso-8859-1?Q?rskZlIlGjqj0M6m0VRrAenI+mEzOORirG9+pjmkHay0zR5Nz1aLlC+l2N1?=
 =?iso-8859-1?Q?8VPhFc98OL2CUG63hBkh+L+BIVGkbHZR9VAlIcvRyPwB2nR7C1L8k4P/3U?=
 =?iso-8859-1?Q?b3ES8EBwEUOv4QS+Dct0WgxlZ+nIvZ2FgnEBqQQXEDImVbeSuub9S6t+wZ?=
 =?iso-8859-1?Q?Hx4hCqZ1hQCjXaV3MA7Nhdz9SAvjJSRXwGVAs/k7RZIcIPgfqpitSy0qRY?=
 =?iso-8859-1?Q?nFPVmsJ6n1RQoBWcYsqx1NL943XbmtAL8jNlZRVP9JafccepORQqgFB1Pj?=
 =?iso-8859-1?Q?Jllq5GzJVxoPIz33Zg02xyv3qos6X24aPPlPGKxqjZQvH1kYyAqFDxqS1z?=
 =?iso-8859-1?Q?d1TFZ6z/yuY7a/dT3/LzQul5Z5mqSfcCsFu5ErQ59nM5NxudQkZYU06G0C?=
 =?iso-8859-1?Q?F1AGbT22rEg8AnwcOwr1P/TN2xmNnCz+VhlKGtyqI4mL/wh1h7p7SSfwH3?=
 =?iso-8859-1?Q?8cI3v2zFXGNAhtaVBsAHVz9FperwLrYRsr7C89Qt6KDaY4tYD3tLVrLX4I?=
 =?iso-8859-1?Q?TJS4U8qUubQ29mzGtfApe/VHLAP1o3xlMTen+RTwJkJv1qLZytezzUhPo+?=
 =?iso-8859-1?Q?9cGG8mltM2Y4PzEW44PpVo0adr8iAp9H+wTNrsRy6MKVhj4xj39gFqTkwy?=
 =?iso-8859-1?Q?4myS/v3fIcU7I/+whKwh03/HRuCXxR9XAPGeAkjmGbcrxgEPS4/0bKgXq5?=
 =?iso-8859-1?Q?6MG0KYgDbLodo5uEbTFLomC1X3wr2F7JG477pHq52Xr+XCUjcPnRGWWPiT?=
 =?iso-8859-1?Q?9lbQFZeI0ifRLt0ZDqV9U7clc/z25/+h1ICBzkQ3Wg5rG700KmQ7aBHl3M?=
 =?iso-8859-1?Q?noNuJZhLa5+EI6ZdIwMMMNtze2Kn2m0G/fRd/bzkGouY5ORKJWtBVBfO0e?=
 =?iso-8859-1?Q?ag2j0ky4E2V/Mh92ncpBrSCY6QoTfyEwARzE3K6ekXsbDCuNmnMLV8Ftvi?=
 =?iso-8859-1?Q?UBnCFdkN+LLtnL2jAXRnf8TVQNC/BJk5aFWMlWXoPHPNMGVQCKqdfRZSdn?=
 =?iso-8859-1?Q?nEA8Sm8m8qb7XkT8zeBg94u0pydoY/61zzqoAhZvGfLImzoOQBUTHWxpAH?=
 =?iso-8859-1?Q?KNdfdkZZiCpg/XFaa6Y0T8PU6L9Ly96JaBD4B7t4rOoZXdY+qIjzOryXib?=
 =?iso-8859-1?Q?k2uQKENkPSWqDyyciCFjuTCj3OLx0ZMqWJp40owsf6oh+L+K4pOXAmkIs+?=
 =?iso-8859-1?Q?M9YyLCqgiz/mBcdBdBGUqZOTBmNWPClP6Ks0WVZYlR5j8MeTwz+4XcTTxL?=
 =?iso-8859-1?Q?oG12SzbL21sf1F5YU85qmDH6kAk9AfUwv7Nqrp/bqafXNDab05aDzmacnr?=
 =?iso-8859-1?Q?U=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)(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?4MVHq0SBCQbY4gc1FfHWOWfxCGrsbH1i3B/U536UfmFtjvAn0Z0Mq2/qOz?=
 =?iso-8859-1?Q?jCqXToo8kHBl3oUS+nMiWPy3/gr03wQNFPIabxjhhuN2XvrJ/ziuWdOQA+?=
 =?iso-8859-1?Q?UCFPUoebSAgZk4QHnUozEGrIe47moKBEGHqTg36doJcX//3UMOSAUGfj7V?=
 =?iso-8859-1?Q?nDDYtHCGb9AYD6Zehmq9+vcgGb3Ngq6UNybRQlORwomlzNGrH+jNh1Vm1m?=
 =?iso-8859-1?Q?b7I24x8iRvA/WZo5w63qxV1Jt1jbQl8vfBfVqOBosfTGJ/KbVnZFGMFKYh?=
 =?iso-8859-1?Q?wm4YKb5JJPsKsalGUFBRFCYtKf1a8qE74hCB62+IPQ/v+H19UakJH4y9BL?=
 =?iso-8859-1?Q?PWdhszo2BcD5508gngIDLGDBD70MDkm9+ZlQsu1Kt81TbxKsHEjRRoT98E?=
 =?iso-8859-1?Q?MJ062nnDlDoVzDOkrx9ZhDw6kGl9qkDfjtoiS5B97y+BjRWnMwhJL9lgwy?=
 =?iso-8859-1?Q?1kJr+w1H7jvzK6HhS0odlAGsmBdtUZtlQAYMD1kOyVNsPjAMArMi0CYpF1?=
 =?iso-8859-1?Q?HAE//h0ArAB3uefk79mTbSvv8xi11KzyyfGJjyLHvPcgQaiGSGu+Ivik6S?=
 =?iso-8859-1?Q?aKsOVvG4/qUh5XQbYMcb++Hn5pt5gL4wHCdfHsw3kB5GtHQuUBmJy/Iah3?=
 =?iso-8859-1?Q?RHpS/jgyuxclICuOox7iZXli0HX5it6yvk4W7V8jgTUEsnBiFXHqcZsYIK?=
 =?iso-8859-1?Q?nVYkw80gydIDkW1XlTelLUzbd/4Q2z77oryNF+nQnijlenT2W49sgjGWEA?=
 =?iso-8859-1?Q?b08IZaDzXi8SGZwzXELn+kt8wdWJNB1+3l+nqtxfQ6O5MWT6UYczDkSPim?=
 =?iso-8859-1?Q?FI/urEgxMLn75RDRdn/xXGOZhB813ArFXKIW4bwDhChbX9jWsKWSU9zHvj?=
 =?iso-8859-1?Q?tqExtQPHh6kzUapQeFj92VyZ3jZ2MdSIyGOsuHPSRQShJNJ7CXmx8HthZw?=
 =?iso-8859-1?Q?A76JHcIO9vBP7UEvXOrao31FEgjFlmIrbkS3xSCPrv4h0G7E3PtmW24TCg?=
 =?iso-8859-1?Q?oPGsRivfPxjIYbEo+lWbUcaU6Juna7fa4rkp4kpFi4T13Nvp8Gu2pBQ1pj?=
 =?iso-8859-1?Q?p9PCcnOrx5eDknCrXMgcJg2BgR1yM2wPKwgS7bIo7XsUoisCEn9azvhFGf?=
 =?iso-8859-1?Q?3a8J6w7H0gLD1T7bdVK2ehkqS1rnkzJ5LgZKfKOlDx9TjfyEwEzDbKiUxc?=
 =?iso-8859-1?Q?YflFXUw3FEODA4wnOBzHJdKy64Wi5WJJV9lwo4rHvYcNjqf2AuIGVThs2D?=
 =?iso-8859-1?Q?OWg5HoEXsEEagOJnXH2BEwcUmCTzkh11jHFl8avBSgqzN4GHOEbGOilK1k?=
 =?iso-8859-1?Q?hvKrWC4JZtZXz/PWJZjsRnNlHzHQewkq7pbsZr4XRcooZp+poxsH5i1qMD?=
 =?iso-8859-1?Q?NSv1tyCvU03CLPqMWE8x8r5dmQ3Ysd7Epvc6WmCsvKqw4m3cvszsubOMsv?=
 =?iso-8859-1?Q?Uf8X0g/5CQLGVWpkN02u99JA21SfbJLj0cTdYUPePhw5xgYJU0V7WOF1M8?=
 =?iso-8859-1?Q?PqfXhPP0rKeQR7s1JnO1och2GmtoA82NVFASWG0sP/KKk9boHER45/9bIP?=
 =?iso-8859-1?Q?8B3eH+Im9JypgUk35rDFu1jcTkISQlgL3oFZw6o0IskLK5qr1mwzrQJrnV?=
 =?iso-8859-1?Q?xbKeNwAtsbWsxqRl4Gh84ZjfWkSjIBN1scwTWc0dnwv5M+p7qXqURDZA?=
 =?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: d37af90b-f4b1-4330-c948-08dda9a28fed
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2025 11:16:22.0491
 (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: 6ggL5iwIo59yq0hmJEyLnbtQDAH2VqLbsEPFv8IAljciULWApxpQmQN3igqkvZ2EN4ZgudN6b4yFn/Tripm6QQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR03MB10784

From: Oleksandr Andrushchenko 

Add support for Renesas R-Car Gen4 PCI host controller, specifically
targeting the S4 and V4H SoCs. The implementation includes configuration
read/write operations for both root and child buses. For accessing the
child bus, iATU is used for address translation.

The host controller needs to be initialized by Dom0 first to be properly
handled by Xen. Xen itself only handles the runtime configuration of
the iATU for accessing different child devices.

iATU programming is done similarly to Linux, where only window 0 is used
for dynamic configuration, and it is reconfigured for every config space
read/write.

Code common to all DesignWare PCI host controllers is located in a
separate file to allow for easy reuse in other DesignWare-based PCI
host controllers.

Signed-off-by: Oleksandr Andrushchenko 
Signed-off-by: Mykyta Poturai 
Acked-by: Stefano Stabellini 
---
v5->v6:
* add Stefano's AB
* rename LINK_WAIT_IATU to LINK_WAIT_IATU_DELAY_MS
* remove unimplemented dw_pcie_enable_ecrc
* improve error messages
* use unsigned types for len
* Remove xen/arch/arm/pci/pci-designware* maintainer entry to leave it
  to ARM section

v4->v5:
* update license identifiers
* improve error checking
* use XENLOG_G_* where needed
* make macro defs more robust and minor style fixes
* add MAINTANERS entry

v3->v4:
* no changes

v2->v3:
* move priv allocation to dw_pcie_host_probe

v1->v2:
* move designware code in a separate file
---
 MAINTAINERS                       |   5 +
 xen/arch/arm/pci/Makefile         |   2 +
 xen/arch/arm/pci/pci-designware.c | 405 ++++++++++++++++++++++++++++++
 xen/arch/arm/pci/pci-designware.h |  90 +++++++
 xen/arch/arm/pci/pci-host-rcar4.c |  94 +++++++
 5 files changed, 596 insertions(+)
 create mode 100644 xen/arch/arm/pci/pci-designware.c
 create mode 100644 xen/arch/arm/pci/pci-designware.h
 create mode 100644 xen/arch/arm/pci/pci-host-rcar4.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 13f31b0c1b..470e895c7c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -473,6 +473,11 @@ M:	Anthony Perard 
 S:	Supported
 T:	git https://xenbits.xenproject.org/git-http/qemu-xen.git
=20
+RCAR PCI
+M:	Mykyta Poturai 
+S:	Supported
+F:	xen/arch/arm/pci/pci-host-rcar4.c
+
 REMUS
 S:	Orphan
 F:	docs/README.remus
diff --git a/xen/arch/arm/pci/Makefile b/xen/arch/arm/pci/Makefile
index 1d045ade01..ca6135e282 100644
--- a/xen/arch/arm/pci/Makefile
+++ b/xen/arch/arm/pci/Makefile
@@ -4,3 +4,5 @@ obj-y +=3D pci-host-generic.o
 obj-y +=3D pci-host-common.o
 obj-y +=3D ecam.o
 obj-y +=3D pci-host-zynqmp.o
+obj-y +=3D pci-designware.o
+obj-y +=3D pci-host-rcar4.o
diff --git a/xen/arch/arm/pci/pci-designware.c b/xen/arch/arm/pci/pci-desig=
nware.c
new file mode 100644
index 0000000000..47dd2dd4c0
--- /dev/null
+++ b/xen/arch/arm/pci/pci-designware.c
@@ -0,0 +1,405 @@
+/* SPDX-License-Identifier: GPL-2.0-only
+ *
+ * Based on Linux drivers/pci/controller/pci-host-common.c
+ * Based on Linux drivers/pci/controller/pci-host-generic.c
+ * Based on Linux drivers/pci/controller/dwc/pcie-designware.c
+ * Based on xen/arch/arm/pci/pci-host-generic.c
+ *
+ */
+
+#include 
+#include 
+
+#include "pci-designware.h"
+/**
+ * upper_32_bits - return bits 32-63 of a number
+ * @n: the number we're accessing
+ *
+ * A basic shift-right of a 64- or 32-bit quantity.  Use this to suppress
+ * the "right shift count >=3D width of type" warning when that quantity i=
s
+ * 32-bits.
+ */
+#define upper_32_bits(n) ((uint32_t)(((n) >> 16) >> 16))
+
+/**
+ * lower_32_bits - return bits 0-31 of a number
+ * @n: the number we're accessing
+ */
+#define lower_32_bits(n) ((uint32_t)((n) & 0xffffffffU))
+
+static int dw_pcie_read(void __iomem *addr, unsigned int len, uint32_t *va=
l)
+{
+    if ( !IS_ALIGNED((uintptr_t)addr, len) )
+    {
+        *val =3D 0;
+        return -EFAULT;
+    }
+
+    switch ( len )
+    {
+    case 1:
+        *val =3D readb(addr);
+        break;
+    case 2:
+        *val =3D readw(addr);
+        break;
+    case 4:
+        *val =3D readl(addr);
+        break;
+    default:
+        ASSERT_UNREACHABLE();
+    }
+
+    return 0;
+}
+
+static int dw_pcie_write(void __iomem *addr, unsigned int len, uint32_t va=
l)
+{
+    if ( !IS_ALIGNED((uintptr_t)addr, len) )
+        return -EFAULT;
+
+    switch ( len )
+    {
+    case 1:
+        writeb(val, addr);
+        break;
+    case 2:
+        writew(val, addr);
+        break;
+    case 4:
+        writel(val, addr);
+        break;
+    default:
+        ASSERT_UNREACHABLE();
+    }
+
+    return 0;
+}
+
+static uint32_t dw_pcie_read_dbi(struct pci_host_bridge *bridge, uint32_t =
reg,
+                                 size_t size)
+{
+    void __iomem *addr =3D bridge->cfg->win + reg;
+    uint32_t val;
+    int ret;
+
+    ret =3D dw_pcie_read(addr, size, &val);
+    if ( ret )
+        printk(XENLOG_G_ERR "Read DBI address failed\n");
+
+    return val;
+}
+
+static void dw_pcie_write_dbi(struct pci_host_bridge *bridge, uint32_t reg=
,
+                              size_t size, uint32_t val)
+{
+    void __iomem *addr =3D bridge->cfg->win + reg;
+    int ret;
+
+    ret =3D dw_pcie_write(addr, size, val);
+    if ( ret )
+        printk(XENLOG_G_ERR "Write DBI address failed\n");
+}
+
+static uint32_t dw_pcie_readl_dbi(struct pci_host_bridge *bridge, uint32_t=
 reg)
+{
+    return dw_pcie_read_dbi(bridge, reg, sizeof(uint32_t));
+}
+
+static void dw_pcie_writel_dbi(struct pci_host_bridge *pci, uint32_t reg,
+                               uint32_t val)
+{
+    dw_pcie_write_dbi(pci, reg, sizeof(uint32_t), val);
+}
+
+static void dw_pcie_read_iatu_unroll_enabled(struct pci_host_bridge *bridg=
e)
+{
+    struct dw_pcie_priv *priv =3D bridge->priv;
+    uint32_t val;
+
+    val =3D dw_pcie_readl_dbi(bridge, PCIE_ATU_VIEWPORT);
+    if ( val =3D=3D 0xffffffffU )
+        priv->iatu_unroll_enabled =3D true;
+
+    printk(XENLOG_G_DEBUG "%s iATU unroll: %sabled\n",
+           dt_node_full_name(bridge->dt_node),
+           priv->iatu_unroll_enabled ? "en" : "dis");
+}
+
+static uint32_t dw_pcie_readl_atu(struct pci_host_bridge *pci, uint32_t re=
g)
+{
+    struct dw_pcie_priv *priv =3D pci->priv;
+    int ret;
+    uint32_t val;
+
+    ret =3D dw_pcie_read(priv->atu_base + reg, 4, &val);
+    if ( ret )
+        printk(XENLOG_G_ERR "Read ATU address %x failed\n", reg);
+
+    return val;
+}
+
+static void dw_pcie_writel_atu(struct pci_host_bridge *pci, uint32_t reg,
+                               uint32_t val)
+{
+    struct dw_pcie_priv *priv =3D pci->priv;
+    int ret;
+
+    ret =3D dw_pcie_write(priv->atu_base + reg, 4, val);
+    if ( ret )
+        printk(XENLOG_G_ERR "Write ATU address %x failed\n", reg);
+}
+
+static uint32_t dw_pcie_readl_ob_unroll(struct pci_host_bridge *pci,
+                                        uint32_t index, uint32_t reg)
+{
+    uint32_t offset =3D PCIE_GET_ATU_OUTB_UNR_REG_OFFSET(index);
+
+    return dw_pcie_readl_atu(pci, offset + reg);
+}
+
+static void dw_pcie_writel_ob_unroll(struct pci_host_bridge *pci,
+                                     uint32_t index, uint32_t reg, uint32_=
t val)
+{
+    uint32_t offset =3D PCIE_GET_ATU_OUTB_UNR_REG_OFFSET(index);
+
+    dw_pcie_writel_atu(pci, offset + reg, val);
+}
+
+static int dw_pcie_prog_outbound_atu_unroll(struct pci_host_bridge *pci,
+                                            uint8_t func_no, int index,
+                                            int type, uint64_t cpu_addr,
+                                            uint64_t pci_addr, uint64_t si=
ze)
+{
+    uint32_t retries, val;
+    uint64_t limit_addr =3D cpu_addr + size - 1;
+
+    dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_LOWER_BASE,
+                             lower_32_bits(cpu_addr));
+    dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_UPPER_BASE,
+                             upper_32_bits(cpu_addr));
+    dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_LOWER_LIMIT,
+                             lower_32_bits(limit_addr));
+    dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_UPPER_LIMIT,
+                             upper_32_bits(limit_addr));
+    dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_LOWER_TARGET,
+                             lower_32_bits(pci_addr));
+    dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_UPPER_TARGET,
+                             upper_32_bits(pci_addr));
+    val =3D type | PCIE_ATU_FUNC_NUM(func_no);
+    val =3D upper_32_bits(size - 1) ? val | PCIE_ATU_INCREASE_REGION_SIZE =
: val;
+    dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL1, val);
+    dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL2,
+                             PCIE_ATU_ENABLE);
+
+    /*
+     * Make sure ATU enable takes effect before any subsequent config
+     * and I/O accesses.
+     */
+    for ( retries =3D 0; retries < LINK_WAIT_MAX_IATU_RETRIES; retries++ )
+    {
+        val =3D dw_pcie_readl_ob_unroll(pci, index, PCIE_ATU_UNR_REGION_CT=
RL2);
+        if ( val & PCIE_ATU_ENABLE )
+            return 0;
+
+        mdelay(LINK_WAIT_IATU_DELAY_MS);
+    }
+    printk(XENLOG_G_ERR "Outbound iATU is not being enabled\n");
+
+    return -ENXIO;
+}
+
+static int __dw_pcie_prog_outbound_atu(struct pci_host_bridge *pci,
+                                       uint8_t func_no, int index, int typ=
e,
+                                       uint64_t cpu_addr, uint64_t pci_add=
r,
+                                       uint64_t size)
+{
+    struct dw_pcie_priv *priv =3D pci->priv;
+    uint32_t retries, val;
+
+    if ( priv->iatu_unroll_enabled )
+        return dw_pcie_prog_outbound_atu_unroll(pci, func_no, index, type,
+                                                cpu_addr, pci_addr, size);
+
+    dw_pcie_writel_dbi(pci, PCIE_ATU_VIEWPORT,
+                       PCIE_ATU_REGION_OUTBOUND | index);
+    dw_pcie_writel_dbi(pci, PCIE_ATU_LOWER_BASE, lower_32_bits(cpu_addr));
+    dw_pcie_writel_dbi(pci, PCIE_ATU_UPPER_BASE, upper_32_bits(cpu_addr));
+    dw_pcie_writel_dbi(pci, PCIE_ATU_LIMIT, lower_32_bits(cpu_addr + size =
- 1));
+    if ( priv->version >=3D 0x460A )
+        dw_pcie_writel_dbi(pci, PCIE_ATU_UPPER_LIMIT,
+                           upper_32_bits(cpu_addr + size - 1));
+    dw_pcie_writel_dbi(pci, PCIE_ATU_LOWER_TARGET, lower_32_bits(pci_addr)=
);
+    dw_pcie_writel_dbi(pci, PCIE_ATU_UPPER_TARGET, upper_32_bits(pci_addr)=
);
+    val =3D type | PCIE_ATU_FUNC_NUM(func_no);
+    val =3D ((upper_32_bits(size - 1)) && (priv->version >=3D 0x460A))
+              ? val | PCIE_ATU_INCREASE_REGION_SIZE
+              : val;
+    dw_pcie_writel_dbi(pci, PCIE_ATU_CR1, val);
+    dw_pcie_writel_dbi(pci, PCIE_ATU_CR2, PCIE_ATU_ENABLE);
+
+    /*
+     * Make sure ATU enable takes effect before any subsequent config
+     * and I/O accesses.
+     */
+    for ( retries =3D 0; retries < LINK_WAIT_MAX_IATU_RETRIES; retries++ )
+    {
+        val =3D dw_pcie_readl_dbi(pci, PCIE_ATU_CR2);
+        if ( val & PCIE_ATU_ENABLE )
+            return 0;
+
+        mdelay(LINK_WAIT_IATU_DELAY_MS);
+    }
+    printk(XENLOG_G_ERR "Outbound iATU is not being enabled\n");
+
+    return -ENXIO;
+}
+
+static int dw_pcie_prog_outbound_atu(struct pci_host_bridge *pci, int inde=
x,
+                                     int type, uint64_t cpu_addr,
+                                     uint64_t pci_addr, uint64_t size)
+{
+    return __dw_pcie_prog_outbound_atu(pci, 0, index, type, cpu_addr, pci_=
addr,
+                                       size);
+}
+
+void dw_pcie_set_version(struct pci_host_bridge *bridge, unsigned int vers=
ion)
+{
+    struct dw_pcie_priv *priv =3D bridge->priv;
+
+    priv->version =3D version;
+}
+
+void __iomem *dw_pcie_child_map_bus(struct pci_host_bridge *bridge,
+                                    pci_sbdf_t sbdf, uint32_t where)
+{
+    uint32_t busdev;
+    int ret;
+
+    busdev =3D PCIE_ATU_BUS(sbdf.bus) | PCIE_ATU_DEV(PCI_SLOT(sbdf.devfn))=
 |
+             PCIE_ATU_FUNC(PCI_FUNC(sbdf.devfn));
+
+    /* FIXME: Parent is the root bus, so use PCIE_ATU_TYPE_CFG0. */
+    ret =3D dw_pcie_prog_outbound_atu(bridge, PCIE_ATU_REGION_INDEX1,
+                                    PCIE_ATU_TYPE_CFG0,
+                                    bridge->child_cfg->phys_addr, busdev,
+                                    bridge->child_cfg->size);
+    if ( ret )
+        return 0;
+
+    return bridge->child_cfg->win + where;
+}
+
+int dw_pcie_child_config_read(struct pci_host_bridge *bridge, pci_sbdf_t s=
bdf,
+                              uint32_t reg, uint32_t len, uint32_t *value)
+{
+    struct dw_pcie_priv *priv =3D bridge->priv;
+    int ret;
+
+    /*
+     * FIXME: we cannot read iATU settings at the early initialization
+     * (probe) as the host's HW is not yet initialized at that phase.
+     * This read operation is the very first thing Domain-0 will do
+     * during its initialization, so take this opportunity and read
+     * iATU setting now.
+     */
+    if ( unlikely(!priv->iatu_unroll_initilized) )
+    {
+        dw_pcie_read_iatu_unroll_enabled(bridge);
+        priv->iatu_unroll_initilized =3D true;
+    }
+
+    ret =3D pci_generic_config_read(bridge, sbdf, reg, len, value);
+    if ( !ret && (priv->num_viewport <=3D 2) )
+        ret =3D dw_pcie_prog_outbound_atu(bridge, PCIE_ATU_REGION_INDEX1,
+                                        PCIE_ATU_TYPE_IO,
+                                        bridge->child_cfg->phys_addr, 0,
+                                        bridge->child_cfg->size);
+
+    return ret;
+}
+
+int dw_pcie_child_config_write(struct pci_host_bridge *bridge, pci_sbdf_t =
sbdf,
+                               uint32_t reg, uint32_t len, uint32_t value)
+{
+    struct dw_pcie_priv *priv =3D bridge->priv;
+    int ret;
+
+    ret =3D pci_generic_config_write(bridge, sbdf, reg, len, value);
+    if ( !ret && (priv->num_viewport <=3D 2) )
+        ret =3D dw_pcie_prog_outbound_atu(bridge, PCIE_ATU_REGION_INDEX1,
+                                        PCIE_ATU_TYPE_IO,
+                                        bridge->child_cfg->phys_addr, 0,
+                                        bridge->child_cfg->size);
+    return ret;
+}
+
+bool __init dw_pcie_child_need_p2m_hwdom_mapping(struct domain *d,
+                                                 struct pci_host_bridge *b=
ridge,
+                                                 uint64_t addr)
+{
+    struct pci_config_window *cfg =3D bridge->child_cfg;
+
+    /*
+     * We do not want ECAM address space to be mapped in Domain-0's p2m,
+     * so we can trap access to it.
+     */
+    return cfg->phys_addr !=3D addr;
+}
+
+struct pci_host_bridge *__init
+dw_pcie_host_probe(struct dt_device_node *dev, const void *data,
+                   const struct pci_ecam_ops *ops,
+                   const struct pci_ecam_ops *child_ops)
+{
+    struct pci_host_bridge *bridge;
+    struct dw_pcie_priv *priv;
+
+    paddr_t atu_phys_addr;
+    paddr_t atu_size;
+    int atu_idx, ret;
+
+    bridge =3D pci_host_common_probe(dev, ops, child_ops);
+    if ( IS_ERR(bridge) )
+        return bridge;
+
+    priv =3D xzalloc(struct dw_pcie_priv);
+    if ( !priv )
+        return ERR_PTR(-ENOMEM);
+
+    bridge->priv =3D priv;
+
+    atu_idx =3D dt_property_match_string(dev, "reg-names", "atu");
+    if ( atu_idx < 0 )
+    {
+        printk(XENLOG_ERR "Cannot find \"atu\" range index in device tree\=
n");
+        return ERR_PTR(atu_idx);
+    }
+    ret =3D dt_device_get_address(dev, atu_idx, &atu_phys_addr, &atu_size)=
;
+    if ( ret )
+    {
+        printk(XENLOG_ERR "Cannot find \"atu\" range in device tree\n");
+        return ERR_PTR(ret);
+    }
+    printk("iATU at [mem 0x%" PRIpaddr "-0x%" PRIpaddr "]\n", atu_phys_add=
r,
+           atu_phys_addr + atu_size - 1);
+    priv->atu_base =3D ioremap_nocache(atu_phys_addr, atu_size);
+    if ( !priv->atu_base )
+    {
+        printk(XENLOG_ERR "iATU ioremap failed\n");
+        return ERR_PTR(ENXIO);
+    }
+
+    if ( !dt_property_read_u32(dev, "num-viewport", &priv->num_viewport) )
+        priv->num_viewport =3D 2;
+
+    /*
+     * FIXME: we cannot read iATU unroll enable now as the host bridge's
+     * HW is not yet initialized by Domain-0: leave it for later.
+     */
+
+    printk(XENLOG_INFO "%s number of view ports: %d\n", dt_node_full_name(=
dev),
+           priv->num_viewport);
+
+    return bridge;
+}
diff --git a/xen/arch/arm/pci/pci-designware.h b/xen/arch/arm/pci/pci-desig=
nware.h
new file mode 100644
index 0000000000..7efb1dc9a2
--- /dev/null
+++ b/xen/arch/arm/pci/pci-designware.h
@@ -0,0 +1,90 @@
+/* SPDX-License-Identifier: GPL-2.0-only
+ *
+ * Based on Linux drivers/pci/controller/pci-host-common.c
+ * Based on Linux drivers/pci/controller/pci-host-generic.c
+ * Based on Linux drivers/pci/controller/dwc/pcie-designware.c
+ * Based on xen/arch/arm/pci/pci-host-generic.c
+ */
+
+#include 
+#include 
+
+#ifndef __PCI_DESIGNWARE_H__
+#define __PCI_DESIGNWARE_H__
+
+
+#define PCIE_ATU_VIEWPORT               0x900
+#define PCIE_ATU_REGION_OUTBOUND        0
+#define PCIE_ATU_CR1                    0x904
+#define PCIE_ATU_INCREASE_REGION_SIZE   BIT(13, UL)
+#define PCIE_ATU_CR2                    0x908
+#define PCIE_ATU_ENABLE                 BIT(31, UL)
+#define PCIE_ATU_LOWER_BASE             0x90C
+#define PCIE_ATU_UPPER_BASE             0x910
+#define PCIE_ATU_LIMIT                  0x914
+#define PCIE_ATU_LOWER_TARGET           0x918
+#define PCIE_ATU_UPPER_TARGET           0x91C
+#define PCIE_ATU_UPPER_LIMIT            0x924
+
+#define PCIE_ATU_REGION_INDEX1  0x1
+#define PCIE_ATU_TYPE_IO        0x2
+#define PCIE_ATU_TYPE_CFG0      0x4
+
+#define FIELD_PREP(_mask, _val) \
+    (((typeof(_mask))(_val) << (ffs64(_mask) - 1)) & (_mask))
+
+#define PCIE_ATU_BUS(x)         FIELD_PREP(GENMASK(31, 24), (x))
+#define PCIE_ATU_DEV(x)         FIELD_PREP(GENMASK(23, 19), (x))
+#define PCIE_ATU_FUNC(x)        FIELD_PREP(GENMASK(18, 16), (x))
+
+/* Register address builder */
+#define PCIE_GET_ATU_OUTB_UNR_REG_OFFSET(region) \
+    ((region) << 9)
+
+/*
+ * iATU Unroll-specific register definitions
+ * From 4.80 core version the address translation will be made by unroll
+ */
+#define PCIE_ATU_UNR_REGION_CTRL1       0x00
+#define PCIE_ATU_UNR_REGION_CTRL2       0x04
+#define PCIE_ATU_UNR_LOWER_BASE         0x08
+#define PCIE_ATU_UNR_UPPER_BASE         0x0C
+#define PCIE_ATU_UNR_LOWER_LIMIT        0x10
+#define PCIE_ATU_UNR_LOWER_TARGET       0x14
+#define PCIE_ATU_UNR_UPPER_TARGET       0x18
+#define PCIE_ATU_UNR_UPPER_LIMIT        0x20
+
+#define PCIE_ATU_FUNC_NUM(pf)           ((pf) << 20)
+
+/* Parameters for the waiting for iATU enabled routine */
+#define LINK_WAIT_MAX_IATU_RETRIES      5
+#define LINK_WAIT_IATU_DELAY_MS         10
+
+struct dw_pcie_priv {
+    uint32_t num_viewport;
+    bool iatu_unroll_initilized;
+    bool iatu_unroll_enabled;
+    void __iomem *atu_base;
+    unsigned int version;
+};
+
+void dw_pcie_set_version(struct pci_host_bridge *bridge, unsigned int vers=
ion);
+
+void __iomem *dw_pcie_child_map_bus(struct pci_host_bridge *bridge,
+                                    pci_sbdf_t sbdf, uint32_t where);
+
+int dw_pcie_child_config_read(struct pci_host_bridge *bridge, pci_sbdf_t s=
bdf,
+                              uint32_t reg, uint32_t len, uint32_t *value)=
;
+
+int dw_pcie_child_config_write(struct pci_host_bridge *bridge, pci_sbdf_t =
sbdf,
+                               uint32_t reg, uint32_t len, uint32_t value)=
;
+
+bool __init dw_pcie_child_need_p2m_hwdom_mapping(struct domain *d,
+                                                 struct pci_host_bridge *b=
ridge,
+                                                 uint64_t addr);
+
+struct pci_host_bridge *__init
+dw_pcie_host_probe(struct dt_device_node *dev, const void *data,
+                   const struct pci_ecam_ops *ops,
+                   const struct pci_ecam_ops *child_ops);
+#endif /* __PCI_DESIGNWARE_H__ */
diff --git a/xen/arch/arm/pci/pci-host-rcar4.c b/xen/arch/arm/pci/pci-host-=
rcar4.c
new file mode 100644
index 0000000000..62d2130a63
--- /dev/null
+++ b/xen/arch/arm/pci/pci-host-rcar4.c
@@ -0,0 +1,94 @@
+/* SPDX-License-Identifier: GPL-2.0-only
+ *
+ * Based on Linux drivers/pci/controller/pci-host-common.c
+ * Based on Linux drivers/pci/controller/pci-host-generic.c
+ * Based on xen/arch/arm/pci/pci-host-generic.c
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "pci-designware.h"
+
+#define RCAR4_DWC_VERSION       0x520A
+
+/*
+ * PCI host bridges often have different ways to access the root and child
+ * bus config spaces:
+ *   "dbi"   : the aperture where root port's own configuration registers
+ *             are available.
+ *   "config": child's configuration space
+ *   "atu"   : iATU registers for DWC version 4.80 or later
+ */
+static int __init rcar4_cfg_reg_index(struct dt_device_node *np)
+{
+    return dt_property_match_string(np, "reg-names", "dbi");
+}
+
+static int __init rcar4_child_cfg_reg_index(struct dt_device_node *np)
+{
+    return dt_property_match_string(np, "reg-names", "config");
+}
+
+/* ECAM ops */
+const struct pci_ecam_ops rcar4_pcie_ops =3D {
+    .bus_shift  =3D 20,
+    .cfg_reg_index =3D rcar4_cfg_reg_index,
+    .pci_ops    =3D {
+        .map_bus                =3D pci_ecam_map_bus,
+        .read                   =3D pci_generic_config_read,
+        .write                  =3D pci_generic_config_write,
+        .need_p2m_hwdom_mapping =3D pci_ecam_need_p2m_hwdom_mapping,
+        .init_bus_range         =3D pci_generic_init_bus_range,
+    }
+};
+
+const struct pci_ecam_ops rcar4_pcie_child_ops =3D {
+    .bus_shift  =3D 20,
+    .cfg_reg_index =3D rcar4_child_cfg_reg_index,
+    .pci_ops    =3D {
+        .map_bus                =3D dw_pcie_child_map_bus,
+        .read                   =3D dw_pcie_child_config_read,
+        .write                  =3D dw_pcie_child_config_write,
+        .need_p2m_hwdom_mapping =3D dw_pcie_child_need_p2m_hwdom_mapping,
+        .init_bus_range         =3D pci_generic_init_bus_range_child,
+    }
+};
+
+static const struct dt_device_match __initconstrel rcar4_pcie_dt_match[] =
=3D {
+    { .compatible =3D "renesas,r8a779f0-pcie" },
+    { .compatible =3D "renesas,r8a779g0-pcie" },
+    {},
+};
+
+static int __init pci_host_rcar4_probe(struct dt_device_node *dev,
+                                       const void *data)
+{
+    struct pci_host_bridge *bridge;
+
+    bridge =3D dw_pcie_host_probe(dev, data, &rcar4_pcie_ops,
+                                &rcar4_pcie_child_ops);
+
+    dw_pcie_set_version(bridge, RCAR4_DWC_VERSION);
+
+    return 0;
+}
+
+DT_DEVICE_START(pci_gen, "PCI HOST R-CAR GEN4", DEVICE_PCI_HOSTBRIDGE)
+.dt_match =3D rcar4_pcie_dt_match,
+.init =3D pci_host_rcar4_probe,
+DT_DEVICE_END
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 11:43:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 11:43:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012919.1391433 (Exim 4.92)
	(envelope-from )
	id 1uPgKi-0001Tj-96; Thu, 12 Jun 2025 11:43:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012919.1391433; Thu, 12 Jun 2025 11:43:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPgKi-0001Tc-6P; Thu, 12 Jun 2025 11:43:00 +0000
Received: by outflank-mailman (input) for mailman id 1012919;
 Thu, 12 Jun 2025 11:42: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 1uPgKg-0001TW-Pf
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 11:42:58 +0000
Received: from DU2PR03CU002.outbound.protection.outlook.com
 (mail-northeuropeazlp170110003.outbound.protection.outlook.com
 [2a01:111:f403:c200::3])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 61ca279c-4782-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 13:42:56 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by PA4PR03MB6782.eurprd03.prod.outlook.com (2603:10a6:102:e3::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.19; Thu, 12 Jun
 2025 11:42:53 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%4]) with mapi id 15.20.8769.029; Thu, 12 Jun 2025
 11:42: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: 61ca279c-4782-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Qcc/WVLTRmIRoI3J+keXCTrK6p3PSbsadxsdiaSwm5VgGmr73EjxLBIxzRATJbw1n2y3eTj4mh4kyum32hRaqVpJt/uq0rXFq/uyvRDTzx7fJW9HbqpFUG2Am2wklyZoLIch/uIuM1O3+IiMD7frjUqfAsFYmsEmGHLn5HD3EnsSGOI2fOYS8FcpDqbxeGaxAkbC/ykFabOkgfrpjUkbByQ+IsgGOZtro+U3YwD6B01Hy6USP6KsbCpuhvorG2Qos1LV2PPTkpfxiz0bZxUj/Id1aYznCX6eWO9Q+wUneE3SLyruzzuh86dA2/pqSdUVKrF3zleqxZDDmnWdeXbLVw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=C5dN+acdxu27UzJpoL6aQgdzI0RmcSCOjp/y2Xc2ybY=;
 b=Qa/aqtQHzzNfwfgG0TQD6swZkB3aV9nJfE3kNhdL/K5ipYKimqqP5m9ed7fmZWC6hAQSpHqQhJS/Pwd8M5HlzxpmuMMGuX6vv0SusL8PyVxuCSo6j4p6kuBAMcVyX94qlig6JL+qozyGLHra9OWCPHgPGJIWDHrvFK8LgKOhQZrKhwRfjMUKplprcAbt6tSIeuEu28nrTxvZ48vmWZ1OF5pMFgGOnDx3ytQ/16NL+cZctCegidjWJVebaVHrrmo9aoS4jIBxZLVzzMtyrZwfx2iedRvCeZM94AWywB9JcJT4mNn3Og18qBXKHEgCVkW3t6WQ/W8XeiDFNPeqWC+TXg==
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=C5dN+acdxu27UzJpoL6aQgdzI0RmcSCOjp/y2Xc2ybY=;
 b=I4FAKjd9K64iCIu1ocUl1GxZujOF5g9HWrWj0j0wLQTTyhHcUtGgePRvIZ6G2hwZGr6udJ1QhStTXpNUyKOA18Zw4KeucXxZP0kdCgJgDbA3aS10eXTBs7/i25t3+JLxyxTuVrnK+stF+txT2o7MjhZJPV31HiE9a9aN2jUo+jSWxDBHwKS2lNrjXtKW/3VAHv9FIyzqgu9VE+OsMcTrR3XFK8BxuaAelBafZ6D/K3ztzlsXft7iz5+bLcQs8xmCZmKN57t4Sy29yS6tJdH8JZZHVPo6JWD5UtIsa/kPacL6ZiNnTKr6ah1ZgMsW3eJ8vat8eg0Y8OXJnS/cNY0j8Q==
From: Oleksii Moisieiev 
To: Stefano Stabellini 
CC: "xen-devel@lists.xenproject.org" , Andrew
 Cooper , Anthony PERARD
	, Bertrand Marquis , Jan
 Beulich , Juergen Gross , Julien Grall
	, Michal Orzel ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Volodymyr
 Babchuk , Grygorii Strashko
	
Subject: Re: [RFC PATCH v4 5/8] xen/domctl: extend XEN_DOMCTL_assign_device to
 handle not only iommu
Thread-Topic: [RFC PATCH v4 5/8] xen/domctl: extend XEN_DOMCTL_assign_device
 to handle not only iommu
Thread-Index: AQHbyNXPDXt2FT3RV02cltfdm/Dd7rPdzmiAgCG+LgA=
Date: Thu, 12 Jun 2025 11:42:53 +0000
Message-ID: 
References: 
 <4f58bf9c47c40413ee9250c4cd21458382aac857.1747669845.git.oleksii_moisieiev@epam.com>
 
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: PAVPR03MB8946:EE_|PA4PR03MB6782:EE_
x-ms-office365-filtering-correlation-id: 31423307-7b6c-4bfc-e0c5-08dda9a64468
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|376014|366016|1800799024|7416014|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?VU14cEx5OTVUek1wRlVlcDNMM2FRRlA0KzBOYzdoN2N5dUdvVVhXZTRyYjQ4?=
 =?utf-8?B?dStLWXc3NnNRNzNhL0d6SDZ6REVZdUZZVG1Ud0FhSzN3bW1KSEl3c2Z0dGZB?=
 =?utf-8?B?Y0wvWUd3L3RTOVlmMkFzcGpCTmU4aFVWaEl1SXlGVk13cW94anhQS0dTTGJp?=
 =?utf-8?B?V2I2ZlJrRmwwR1Zla2dxYXJvSDZkWmZvVmI4VDB1dlpYSSt4ZEtKTjhFMnh0?=
 =?utf-8?B?VGIrcEltZG9UOGRWQ0lLRWNnYlFSZmNVN0ZvZXcvc1NnbUpZcS9aUGJLWTR5?=
 =?utf-8?B?cnVlWXhVdnhUdS9IWGNzWW1RYkN4VmRHYmdXUjVFRDA3dkNJRXdFRzhIVjFJ?=
 =?utf-8?B?d1ZKQWtQckp5T0N2bEVMV0ZMV1NWOEFLSU1keHJDcVR3SXdacHFXOW9oYkNa?=
 =?utf-8?B?S3paMXh5TEFaa055WjFNZWhJTDJIbGRLVTFhQS9OM0ZYY3cvdHpUZVJMNHln?=
 =?utf-8?B?eE5GZDRCR0NSUkpLd1plYTFvZE1xeVliczRYTWQ2c2tQT0lCZzdYeWN6V2RS?=
 =?utf-8?B?UktPWTUxWEdDemJ3SCtLeldQT2RuUkR1UTZVRjI5SVhwdzNrMDN6dFROOTNI?=
 =?utf-8?B?VjlDbDBJd1NNUXhsSURMUitoSSs3RHQ3Y0NhVjVEcVIrQUtnRk1zNHZrTk50?=
 =?utf-8?B?MGoxbTRtZzdKNnBvU1lUdGcvM1R2TG5mcXo1YUhMSEhCb09Tb0Q4WExuaEtK?=
 =?utf-8?B?S2luUm1UVUdxTkhXajJ3UkgzU0J3Um96UlVzWDQ5YkdEZFYyT0Z4ZGJseVR1?=
 =?utf-8?B?SnBBNTZWZlhkRE5oU0tKNnRvOG9qZGhrY2tqRUlDWGw1R0VlVFoza1kwdnhz?=
 =?utf-8?B?d1FXemdRV3J1aWdkdWpFVmJHYXI3TVBMbzRiL0pTR2F3TUo1MTNiYWsyYXgw?=
 =?utf-8?B?TnFjYjVsbjg1aXRXTE1HS1FQN3J0RlB0OGJvODVvNURZZFlMZnQ0SmJxMU45?=
 =?utf-8?B?dFgvY3Q1TGtzczJPaWZxc3pYVk5JbVVPdDY3ZVBuSTJzOU91ckI3UXkrczln?=
 =?utf-8?B?VnVqekdDbUhCZFZyRDVZNmtXbVVKQVNyYzBwSE5ONjEzZ0QxWUNNUjdYZncr?=
 =?utf-8?B?eTNpemVQRjg4N3JKcnpXT1VXaWNSNGNzemw5aVlISy91TklOMHZiNE1pL3lB?=
 =?utf-8?B?ejlrRFpLa3ZpaXc2UUxrRk1oRFJmaDhWaEl4dXhNc0s4U2JOOTdGaDVmc2t3?=
 =?utf-8?B?bTd2OWptcjRpKzBNdmN3allQOFJoeHN2NGZPdjRzVytBQzFpb2hQRW5TQnBm?=
 =?utf-8?B?SFFoRGtMamVieHYxMFAyc3cwQzNZQVhLcVJRVjM4Y2xsMklGVG96TmFtQUxQ?=
 =?utf-8?B?TVVpdjY1V0lRSEQrbXVmSVJaaDFKeEdyNktOMHgzRzBYZXc3M0lpVnRPQnNt?=
 =?utf-8?B?TjFibE5IamNpK1p2WVl6aUxxc2VBM1RuMDVlMXMwSHFLT3lEUDMvSld6dEFo?=
 =?utf-8?B?NjErV0ZrYU1ZVjNkOXRqcDlaaXRwOG0xaEgyL29EUEV6TkxWbE83TkRXQVZH?=
 =?utf-8?B?cTdTdVRiQWhUdDloY0VwRVA5U1U4bmFjcVlpeGdJYUdFQ0p6SWZoSTllVmpY?=
 =?utf-8?B?VlZ5eGlmNEpITW1ucWplNExTbEgxWjJaUldWZmdMQnQxaCtKQk9VbmdYR3RB?=
 =?utf-8?B?R3RPT0xSVFlkOG5lTmx4dERsSXE5WWUxUVRWZ2FFdXh2QmFvYjZMUXF0eHJR?=
 =?utf-8?B?UjMwQTNrYmJGV1prYnZxOTBBWW05endMSG5qMVBFMHp3MTZvWHhhajByZDlj?=
 =?utf-8?B?K0MyWGtTMTZXc25ZQWlnVUpRSHlPM3ZWY1c0ZVQ1a2Q1MW9ydVNSY2lTcHBu?=
 =?utf-8?B?cmVXbkV3YjFWK0taN1oyNHdZeERqa3dOUnVqb2QvTlE2c2cvdVJzT0s4Z2Ji?=
 =?utf-8?B?L3NzcW9heGFSMWJjMGdiK2xON3gzSU4veHhlM3E4ODllT29jVGJ0cTBsSDU5?=
 =?utf-8?B?SUFIM200REttclVLV3AzVklFSE9GaWhWVHdGbXB4V0t3YnMzYzU5UjRURk4z?=
 =?utf-8?B?OVVxaVVESG13PT0=?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(7416014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?TXhhQnlBODRBV1h1U1pNbTJmc2k3cVFEeDhISlVKckYxN0h2WFRxMTZEaG1J?=
 =?utf-8?B?Q1kzS042aVJnckY0a21RUy8xNnZNRGkvU3EvRUVlMVhXMzJTMDUzRzZJODFa?=
 =?utf-8?B?TGZTd09hOHBhWDVGWGhwMi9EaTg1V1lXVmNadlBlWlZiQXkvMi8vOG93SHNC?=
 =?utf-8?B?aFZ0ZkllTzNnMHMrcHljVWU1ODVNbUxjaWNhNnlUZUhnbGR1Smw4VGcyMTZx?=
 =?utf-8?B?UkR2aEtKR3ZlVEFMWXEyakQreFF0NTJDalYxanZzcEl1TUJ2N0pkVnFCZTYw?=
 =?utf-8?B?eGFKWlV4RVhPWVk4dVpJTlNiQUxNUFFGWU44MDRhY3NHdWZzMk5hUmlhRG1w?=
 =?utf-8?B?d2FQbGlsL0R2cVA2QS9FWWhFdnl5QWxoUTQ3eEppUUlmYUhtYjRKcXEwNjM2?=
 =?utf-8?B?TkVFbFZ5UndpZ3NIb0g4dUswN2MxVzhkcFlLNVg0UjBET2xCbyt6b2hVd1Bs?=
 =?utf-8?B?SEtWZkVnQm5LbzY3VmhKR01lZUNkMHcrMldPUG81TWhIZTV3ZEZTS2llNWxO?=
 =?utf-8?B?Y2VjWmFiMGVSYmlNb29JQzU0WUcxQVVHTDdiV21xWitTNmMvWU1RMzEyY1Js?=
 =?utf-8?B?OEh6SUlaMmhUczlUa1FoUHZXeHJ2UDB3UDUwTUt2R0E1YXdZZXNPeG5QbGl0?=
 =?utf-8?B?MnBrQlY4Vk9QUTNTV3QwN0ZkTXVvVy96Q1NkQ29BQ25NcnVwWGVDL0Y1bTEw?=
 =?utf-8?B?VGVjMERFbHhtanlNdmdiMVQzZFJTbVpOZkVqeGpBUThEeldKQWxFckMvUmk3?=
 =?utf-8?B?ZzhZdjB5SWxqbUpuM3Ftam9HN2M5eVpRdlU2RmJhMUxybTNXMExxMHVBNWNl?=
 =?utf-8?B?Sjg4L2FBZHhoT0xJRnZSYzdkWUIrdDJlSmd6amNOZk9xUWFPSW55clY3NTUw?=
 =?utf-8?B?SzRhTGxYZy85RlZYTG9DWDV3Y2wvNVUzeSt1ajNOM0lqYnZlcGQ3N2g4dTcx?=
 =?utf-8?B?NkFPTVlDOUFObUFTeVZkT1NJbU41Rjc4aHNCeGdmUnhqS1FVbkQ5QW9CeFZp?=
 =?utf-8?B?aHVWT3pycTRoclo0WklkbXd5azVqQWFKTUk2S3pEVUJZL2ZCVFFKQng1YlFO?=
 =?utf-8?B?NUsxT1hHSWpMWEFyZW9LeExpdk5MWUJ5RUFpOExhYVhseUtmWjJhaGw4bjZu?=
 =?utf-8?B?dnorYnJmRnZTSlhoL1F4eGJPUzkyaTVaTmlwekhOWDFZaWpWSjhiRS9BQWQz?=
 =?utf-8?B?bkJiSkxFc1ZGNkdTNlBjcitnNmFnazlVcm4yU0d2dUY2czZFb09xN3NiYlhk?=
 =?utf-8?B?YjBOOEk2ZWh1RGttcjQ4OVZDVXdhZGEwQVh1YlBSWld3L3kvek9maXcvTkZl?=
 =?utf-8?B?VlEySEFkWVk0VmhnMU5xM1hsNnBlK3FUdlVUV1BpcHRIRGxqeDQrTHVZNmx1?=
 =?utf-8?B?THpmaU9tSHQ4QjN1eEtiTlRvTlBCZDc3VllMbHozendKVWk1cGNqTUEvUWFi?=
 =?utf-8?B?dTRIMDk0MWtNYlQrREdBcEU2RlRCS0p1UUhYUllIYWVWaFZqejJ2YXF4Vno0?=
 =?utf-8?B?ZG1QTlZUL1JxZDM2M0U0eUVxZ25PT2xrbVBUTnk0OVRIdnFYb0JnYmtCUWlt?=
 =?utf-8?B?TndwaGNwQTRlSDJmM21DYXpINGFhTVdkellEaTZUTVV0ZUVFZnRhY21PejNh?=
 =?utf-8?B?WGRTbHo2RDd6TGIrNFRSMGUxdVpsVjRIVVJXb2dxRTJqMFhIOTVmcXdmUkVp?=
 =?utf-8?B?TmxrR2ZuVG04ai9CdS9aMGlJS2VjSVVmUG9xK3VTeUZPaDhUT25DQUk2WFJ1?=
 =?utf-8?B?QWpQeTllYi9namphNDQ0YmM1U2NFbEZFdDJBa0w5VnUrdHZHWUVEYXE2cUlS?=
 =?utf-8?B?dmdnNEZiakRxUEV0TG42ano4WHBuVUlRUmdsS3ZpZmx1dzJiUWlVK0tOR3l5?=
 =?utf-8?B?OVRSSDlCUnVCSDVwdWtlRjhsYkw3NlpNRXlHcGJvTXQzY3dDUHVIMjhRZmFJ?=
 =?utf-8?B?NXg5ejcvc3hMRWd4SnFZbzN3UmU1MkVvU1E5RFl4cUZnb1ljZXZnd2dhdU5x?=
 =?utf-8?B?UjBnV3VZQkZLR0gwNDMvN0hMN0FiMjdTcU9EK1BzMDhtdkI5V3hqaFhrMkYy?=
 =?utf-8?B?dU1FVDJ0RHJIcEc1Misrd3RzWDk2Q21YN09MUURyR3J3OHUwc2lLOXVJalZS?=
 =?utf-8?B?MWE1dFhPSWZjM2hmSVkvZ0pab0FvVFozYkVZWGlpbUhGTFgzY3d2S1EwaU81?=
 =?utf-8?B?TXc9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 31423307-7b6c-4bfc-e0c5-08dda9a64468
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2025 11:42:53.3439
 (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: vMCQvjAYoRkBdIWNfsODT29xPIIXYzYCwlSCRADwSsaHvxGpJMcMUfbg5l15K3Fo2NHkvX1yI99yY/VIzKWV0zo1Tqbm0ggXcOBOv1VOstk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR03MB6782

SGkgU3RlZmFubywNCg0KSSdtIHZlcnkgc29ycnkgZm9yIGEgbG9uZyBzaWxlbmNlLiBQbGVhc2Ug
c2VlIG15IGFuc3dlcnMgYmVsb3c6DQoNCk9uIDIyLzA1LzIwMjUgMDM6MjUsIFN0ZWZhbm8gU3Rh
YmVsbGluaSB3cm90ZToNCj4gT24gTW9uLCAxOSBNYXkgMjAyNSwgT2xla3NpaSBNb2lzaWVpZXYg
d3JvdGU6DQo+PiBGcm9tOiBHcnlnb3JpaSBTdHJhc2hrbzxncnlnb3JpaV9zdHJhc2hrb0BlcGFt
LmNvbT4NCj4+DQo+PiBBZGQgY2hhaW5lZCBoYW5kbGluZyBvZiBhc3NpZ25lZCBEVCBkZXZpY2Vz
IHRvIHN1cHBvcnQgYWNjZXNzLWNvbnRyb2xsZXINCj4+IGZ1bmN0aW9uYWxpdHkgdGhyb3VnaCBT
Q0kgZnJhbWV3b3JrLCBzbyBEVCBkZXZpY2UgYXNzaWduIHJlcXVlc3QgY2FuIGJlDQo+PiBwYXNz
ZWQgdG8gRlcgZm9yIHByb2Nlc3NpbmcgYW5kIGVuYWJsaW5nIFZNIGFjY2VzcyB0byByZXF1ZXN0
ZWQgZGV2aWNlDQo+PiAoZm9yIGV4YW1wbGUsIGRldmljZSBwb3dlciBtYW5hZ2VtZW50IHRocm91
Z2ggRlcgaW50ZXJmYWNlIGxpa2UgU0NNSSkuDQo+Pg0KPj4gVGhlIFNDSSBhY2Nlc3MtY29udHJv
bGxlciBEVCBkZXZpY2UgcHJvY2Vzc2luZyBpcyBjaGFpbmVkIGFmdGVyIElPTU1VDQo+PiBwcm9j
ZXNzaW5nIGFuZCBleHBlY3RlZCB0byBiZSBleGVjdXRlZCBmb3IgYW55IERUIGRldmljZSByZWdh
cmRsZXNzIG9mIGl0cw0KPj4gcHJvdGVjdGlvbiBieSBJT01NVSAob3IgaWYgSU9NTVUgaXMgZGlz
YWJsZWQpLg0KPj4NCj4+IFRoaXMgYWxsb3dzIHRvIHBhc3Mgbm90IG9ubHkgSU9NTVUgcHJvdGVj
dGVkIERUIGRldmljZSB0aHJvdWdoDQo+PiB4bC5jZmc6ImR0ZGV2IiBwcm9wZXJ0eSBmb3IgcHJv
Y2Vzc2luZzoNCj4+DQo+PiBkdGRldiA9IFsNCj4+ICAgICAgIi9zb2MvdmlkZW9AZTZlZjAwMDAi
LCA8LSBJT01NVSBwcm90ZWN0ZWQgZGV2aWNlDQo+PiAgICAgICIvc29jL2kyY0BlNjUwODAwMCIs
IDwtIG5vdCBJT01NVSBwcm90ZWN0ZWQgZGV2aWNlDQo+PiBdDQo+Pg0KPj4gVGhlIGNoYW5nZSBp
cyBkb25lIGluIHR3byBwYXJ0czoNCj4+IDEpIHVwZGF0ZSBpb21tdV9kb19kdF9kb21jdGwoKSB0
byBjaGVjayBmb3IgZHRfZGV2aWNlX2lzX3Byb3RlY3RlZCgpIGFuZA0KPj4gbm90IGZhaWwgaWYg
RFQgZGV2aWNlIGlzIG5vdCBwcm90ZWN0ZWQgYnkgSU9NTVUNCj4+IDIpIGFkZCBjaGFpbmVkIGNh
bGwgdG8gc2NpX2RvX2RvbWN0bCgpIGluIGRvX2RvbWN0bCgpDQo+Pg0KPj4gU2lnbmVkLW9mZi1i
eTogR3J5Z29yaWkgU3RyYXNoa288Z3J5Z29yaWlfc3RyYXNoa29AZXBhbS5jb20+DQo+PiBTaWdu
ZWQtb2ZmLWJ5OiBPbGVrc2lpIE1vaXNpZWlldjxvbGVrc2lpX21vaXNpZWlldkBlcGFtLmNvbT4N
Cj4+IC0tLQ0KPj4NCj4+DQo+Pg0KPj4gICB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NpLmMgICAg
ICAgICAgICAgfCAzNyArKysrKysrKysrKysrKysrKysrKysrKysrDQo+PiAgIHhlbi9hcmNoL2Fy
bS9pbmNsdWRlL2FzbS9maXJtd2FyZS9zY2kuaCB8IDE0ICsrKysrKysrKysNCj4+ICAgeGVuL2Nv
bW1vbi9kb21jdGwuYyAgICAgICAgICAgICAgICAgICAgIHwgMTkgKysrKysrKysrKysrKw0KPj4g
ICB4ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9kZXZpY2VfdHJlZS5jICAgfCAgNiArKysrDQo+PiAg
IDQgZmlsZXMgY2hhbmdlZCwgNzYgaW5zZXJ0aW9ucygrKQ0KPj4NCj4+IGRpZmYgLS1naXQgYS94
ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NpLmMgYi94ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NpLmMN
Cj4+IGluZGV4IGUxNTIyZTEwZTIuLjhlZmQ1NDFjNGYgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vYXJj
aC9hcm0vZmlybXdhcmUvc2NpLmMNCj4+ICsrKyBiL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY2ku
Yw0KPj4gQEAgLTEyNiw2ICsxMjYsNDMgQEAgaW50IHNjaV9hc3NpZ25fZHRfZGV2aWNlKHN0cnVj
dCBkb21haW4gKmQsIHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqZGV2KQ0KPj4gICAgICAgcmV0dXJu
IDA7DQo+PiAgIH0NCj4+ICAgDQo+PiAraW50IHNjaV9kb19kb21jdGwoc3RydWN0IHhlbl9kb21j
dGwgKmRvbWN0bCwgc3RydWN0IGRvbWFpbiAqZCwNCj4+ICsgICAgICAgICAgICAgICAgICBYRU5f
R1VFU1RfSEFORExFX1BBUkFNKHhlbl9kb21jdGxfdCkgdV9kb21jdGwpDQo+PiArew0KPj4gKyAg
ICBzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKmRldjsNCj4+ICsgICAgaW50IHJldCA9IDA7DQo+PiAr
DQo+PiArICAgIHN3aXRjaCAoIGRvbWN0bC0+Y21kICkNCj4+ICsgICAgew0KPj4gKyAgICBjYXNl
IFhFTl9ET01DVExfYXNzaWduX2RldmljZToNCj4+ICsgICAgICAgIHJldCA9IC1FT1BOT1RTVVBQ
Ow0KPiBBcmUgeW91IHN1cmUgLUVPUE5PVFNVUFAgaXMgdGhlIHJpZ2h0IGVycm9yIGNvZGUgZm9y
IHRoZSAzIGNoZWNrcyBiZWxvdz8NCg0KVGhlIC1FT1BOT1RTVVBQIGNvZGUgaXMgdXNlZCBiZWNh
dXNlIHRoaXMgaXMgcGFydCBvZiBhIGNoYWluZWQgY2FsbCBhZnRlcg0KaW9tbXVfZG9fZG9tY3Rs
LCBhcyBzdGF0ZWQgaW4geGVuL2NvbW1vbi9kb21jdGwuYzo4NTkuIFRoZSANClhFTl9ET01DVExf
YXNzaWduX2RldmljZQ0KY2FsbCBpcyBleHBlY3RlZCB0byBoYW5kbGUgYW55IERUIGRldmljZSwg
cmVnYXJkbGVzcyBvZiB3aGV0aGVyIHRoZSBEVCANCmRldmljZSBpcw0KcHJvdGVjdGVkIGJ5IGFu
IElPTU1VIG9yIGlmIHRoZSBJT01NVSBpcyBkaXNhYmxlZC4NClRoZSBmb2xsb3dpbmcgY2FzZXMg
YXJlIGNvbnNpZGVyZWQ6DQoNCjEuIElPTU1VIFByb3RlY3RlZCBEZXZpY2UgKFN1Y2Nlc3MpDQoN
CklmIHRoZSBkZXZpY2UgaXMgcHJvdGVjdGVkIGJ5IHRoZSBJT01NVSBhbmQgaW9tbXVfZG9fZG9t
Y3RsIHJldHVybnMgMCwgDQp3ZSBjb250aW51ZQ0KcHJvY2Vzc2luZyB0aGUgRFQgZGV2aWNlIGJ5
IGNhbGxpbmcgc2NpX2RvX2RvbWN0bC4NCg0KMi4gSU9NTVUgRGlzYWJsZWQgKC1FT1BOT1RTVVBQ
IGZyb20gaW9tbXVfZG9fZG9tY3RsKQ0KDQpJZiBpb21tdV9kb19kb21jdGwgcmV0dXJucyAtRU9Q
Tk9UU1VQUCwgaW5kaWNhdGluZyB0aGF0IHRoZSBJT01NVSBpcyANCmRpc2FibGVkLA0Kd2Ugc3Rp
bGwgcHJvY2VlZCB0byBjYWxsIHNjaV9kb19kb21jdGwuDQoNCjMuIEVycm9yIGZyb20gaW9tbXVf
ZG9fZG9tY3RsIChGYWlsIFN0YXRlKQ0KDQpJZiBpb21tdV9kb19kb21jdGwgcmV0dXJucyBhbnkg
ZXJyb3IsIHRoZSBzeXN0ZW0gZW50ZXJzIGEgZmFpbCBzdGF0ZSwgYW5kDQpzY2lfZG9fZG9tY3Rs
IGlzIG5vdCBjYWxsZWQuDQoNCjQuIC1FT1BOT1RTVVBQIGZyb20gc2NpX2RvX2RvbWN0bA0KDQpJ
ZiBzY2lfZG9fZG9tY3RsIHJldHVybnMgLUVPUE5PVFNVUFAsIHRoaXMgaW5kaWNhdGVzIG9uZSBv
ZiB0aGUgZm9sbG93aW5nOg0KLSBUaGUgcHJvdmlkZWQgZGV2aWNlIGlzIG5vdCBhIERUIGRldmlj
ZS4NCi0gVGhlcmUgaXMgbm8gY3VyX21lZGlhdG9yIGF2YWlsYWJsZSAoaW5kaWNhdGluZyB0aGF0
IHRoZSBTQ0kgc3Vic3lzdGVtIA0KaXMgZW5hYmxlZA0KaW4gdGhlIGNvbmZpZ3VyYXRpb24sIGJ1
dCBubyBtZWRpYXRvciB3YXMgcHJvdmlkZWQpLg0KLSBUaGUgY3VycmVudCBtZWRpYXRvciBkb2Vz
IG5vdCBzdXBwb3J0IGFzc2lnbl9kdF9kZXZpY2UgKHRoaXMgaXMgDQpleHBlY3RlZCB0byBiZSBj
aGFuZ2VkOw0Kc2VlIGJlbG93IGZvciBkZXRhaWxzKS4NCkluIHRoaXMgY2FzZSwgLUVPUE5PVFNV
UFAgaXMgcmV0dXJuZWQgYnV0IHdpbGwgYmUgaWdub3JlZCwgYW5kIHRoZSANCm9yaWdpbmFsIHJl
dHVybiB2YWx1ZSBmcm9tIGlvbW11X2RvX2RvbWN0bCB3aWxsIGJlIHVzZWQgYXMgdGhlIGZpbmFs
IHJlc3VsdC4NCg0KNS4gUmV0dXJuIENvZGUgZnJvbSBzY2lfZG9fZG9tY3RsDQoNCklmIHNjaV9k
b19kb21jdGwgcmV0dXJucyAwIChzdWNjZXNzKSBvciBhbiBlcnJvciBjb2RlIChmYWlsdXJlKSwN
CnRoZSByZXR1cm4gdmFsdWUgZnJvbSBpb21tdV9kb19kb21jdGwgaXMgb3ZlcnJpZGRlbiwgYW5k
IHRoZSByZXN1bHQgZnJvbSANCnNjaV9kb19kb21jdGwgaXMgcmV0dXJuZWQuDQpOb3RlOiAtRU9Q
Tk9UU1VQUCBmcm9tIGlvbW11X2RvX2RvbWN0bCB3aWxsIGFsc28gYmUgb3ZlcnJpZGRlbiBzaW5j
ZQ0Kc3RlcCAyIHdhcyBzdWNjZXNzZnVsbHkgY29tcGxldGVkIChvciBmYWlsZWQpLg0KPj4gKyAg
ICAgICAgaWYgKCBkb21jdGwtPnUuYXNzaWduX2RldmljZS5kZXYgIT0gWEVOX0RPTUNUTF9ERVZf
RFQgKQ0KPj4gKyAgICAgICAgICAgIGJyZWFrOw0KPiB0aGlzIG9uZQ0KPg0KPj4gKyAgICAgICAg
aWYgKCAhY3VyX21lZGlhdG9yICkNCj4+ICsgICAgICAgICAgICBicmVhazsNCj4gdGhpcyBvbmUN
Cj4NCj4+ICsgICAgICAgIGlmICggIWN1cl9tZWRpYXRvci0+YXNzaWduX2R0X2RldmljZSApDQo+
PiArICAgICAgICAgICAgYnJlYWs7DQo+IGFuZCBhbHNvIHRoaXMgb25lPyBJdCBzZWVtcyBtb3Jl
IGxpa2UgYW4gLUVJTlZBTCBhcyB0aGUgY2FsbGVyIHVzZWQgYQ0KPiB3cm9uZyBwYXJhbWV0ZXI/
DQoNCkkgdGhpbmsgeW91IGFyZSByaWdodCB0aGF0IHRoaXMgY2FzZSBzaG91bGQgcmV0dXJuIC1F
SU5WQUwgYmVjYXVzZSB3ZSANCnNob3VsZCBmYWlsIGlmIG1lZGlhdG9yDQoNCndpdGhvdXQgaW1w
bGVtZW50ZWQgbWFuZGF0b3J5IGZlYXR1cmVzIHdhcyBwcm92aWRlZC4gV2lsbCBiZSBmaXhlZC4N
Cg0KPj4gKyAgICAgICAgcmV0ID0gZHRfZmluZF9ub2RlX2J5X2dwYXRoKGRvbWN0bC0+dS5hc3Np
Z25fZGV2aWNlLnUuZHQucGF0aCwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBkb21jdGwtPnUuYXNzaWduX2RldmljZS51LmR0LnNpemUsICZkZXYpOw0KPj4gKyAgICAg
ICAgaWYgKCByZXQgKQ0KPj4gKyAgICAgICAgICAgIHJldHVybiByZXQ7DQo+PiArDQo+PiArICAg
ICAgICByZXQgPSBzY2lfYXNzaWduX2R0X2RldmljZShkLCBkZXYpOw0KPj4gKyAgICAgICAgaWYg
KCByZXQgKQ0KPj4gKyAgICAgICAgICAgIGJyZWFrOw0KPj4gKw0KPj4gKyAgICAgICAgYnJlYWs7
DQo+PiArICAgIGRlZmF1bHQ6DQo+PiArICAgICAgICAvKiBkbyBub3QgZmFpbCBoZXJlIGFzIGNh
bGwgaXMgY2hhaW5lZCB3aXRoIGlvbW11IGhhbmRsaW5nICovDQo+IEl0IGxvb2tzIGxpa2UgdGhp
cyBzaG91bGQgYmUgYW4gZXJyb3INCj4NCj4NCj4+ICsgICAgICAgIGJyZWFrOw0KPj4gKyAgICB9
DQo+PiArDQo+PiArICAgIHJldHVybiByZXQ7DQo+PiArfQ0KPj4gKw0KPj4gICBzdGF0aWMgaW50
IF9faW5pdCBzY2lfaW5pdCh2b2lkKQ0KPj4gICB7DQo+PiAgICAgICBzdHJ1Y3QgZHRfZGV2aWNl
X25vZGUgKm5wOw0KPj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9maXJt
d2FyZS9zY2kuaCBiL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9maXJtd2FyZS9zY2kuaA0KPj4g
aW5kZXggNzFmYjU0ODUyZS4uYjhkMWJjOGE2MiAxMDA2NDQNCj4+IC0tLSBhL3hlbi9hcmNoL2Fy
bS9pbmNsdWRlL2FzbS9maXJtd2FyZS9zY2kuaA0KPj4gKysrIGIveGVuL2FyY2gvYXJtL2luY2x1
ZGUvYXNtL2Zpcm13YXJlL3NjaS5oDQo+PiBAQCAtMTQ2LDYgKzE0NiwxNCBAQCBpbnQgc2NpX2R0
X2ZpbmFsaXplKHN0cnVjdCBkb21haW4gKmQsIHZvaWQgKmZkdCk7DQo+PiAgICAqIGNvbnRyb2wi
IGZ1bmN0aW9uYWxpdHkuDQo+PiAgICAqLw0KPj4gICBpbnQgc2NpX2Fzc2lnbl9kdF9kZXZpY2Uo
c3RydWN0IGRvbWFpbiAqZCwgc3RydWN0IGR0X2RldmljZV9ub2RlICpkZXYpOw0KPj4gKw0KPj4g
Ky8qDQo+PiArICogU0NJIGRvbWN0bCBoYW5kbGVyDQo+PiArICoNCj4+ICsgKiBPbmx5IFhFTl9E
T01DVExfYXNzaWduX2RldmljZSBpcyBoYW5kbGVkIGZvciBub3cuDQo+PiArICovDQo+PiAraW50
IHNjaV9kb19kb21jdGwoc3RydWN0IHhlbl9kb21jdGwgKmRvbWN0bCwgc3RydWN0IGRvbWFpbiAq
ZCwNCj4+ICsgICAgICAgICAgICAgICAgICBYRU5fR1VFU1RfSEFORExFX1BBUkFNKHhlbl9kb21j
dGxfdCkgdV9kb21jdGwpOw0KPj4gICAjZWxzZQ0KPj4gICANCj4+ICAgc3RhdGljIGlubGluZSBi
b29sIHNjaV9kb21haW5faXNfZW5hYmxlZChzdHJ1Y3QgZG9tYWluICpkKQ0KPj4gQEAgLTE5NSw2
ICsyMDMsMTIgQEAgc3RhdGljIGlubGluZSBpbnQgc2NpX2Fzc2lnbl9kdF9kZXZpY2Uoc3RydWN0
IGRvbWFpbiAqZCwNCj4+ICAgICAgIHJldHVybiAwOw0KPj4gICB9DQo+PiAgIA0KPj4gK3N0YXRp
YyBpbmxpbmUgaW50IHNjaV9kb19kb21jdGwoc3RydWN0IHhlbl9kb21jdGwgKmRvbWN0bCwgc3Ry
dWN0IGRvbWFpbiAqZCwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFhFTl9H
VUVTVF9IQU5ETEVfUEFSQU0oeGVuX2RvbWN0bF90KSB1X2RvbWN0bCkNCj4+ICt7DQo+PiArICAg
IHJldHVybiAwOw0KPj4gK30NCj4+ICsNCj4+ICAgI2VuZGlmIC8qIENPTkZJR19BUk1fU0NJICov
DQo+PiAgIA0KPj4gICAjZW5kaWYgLyogX19BU01fQVJNX1NDSV9IICovDQo+PiBkaWZmIC0tZ2l0
IGEveGVuL2NvbW1vbi9kb21jdGwuYyBiL3hlbi9jb21tb24vZG9tY3RsLmMNCj4+IGluZGV4IDA1
YWJiNTgxYTAuLmE3NGVlOTIwNjcgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vY29tbW9uL2RvbWN0bC5j
DQo+PiArKysgYi94ZW4vY29tbW9uL2RvbWN0bC5jDQo+PiBAQCAtMjcsNiArMjcsNyBAQA0KPj4g
ICAjaW5jbHVkZSA8eGVuL3ZtX2V2ZW50Lmg+DQo+PiAgICNpbmNsdWRlIDx4ZW4vbW9uaXRvci5o
Pg0KPj4gICAjaW5jbHVkZSA8YXNtL2N1cnJlbnQuaD4NCj4+ICsjaW5jbHVkZSA8YXNtL2Zpcm13
YXJlL3NjaS5oPg0KPj4gICAjaW5jbHVkZSA8YXNtL2lycS5oPg0KPj4gICAjaW5jbHVkZSA8YXNt
L3BhZ2UuaD4NCj4+ICAgI2luY2x1ZGUgPGFzbS9wMm0uaD4NCj4+IEBAIC04NTEsNiArODUyLDI0
IEBAIGxvbmcgZG9fZG9tY3RsKFhFTl9HVUVTVF9IQU5ETEVfUEFSQU0oeGVuX2RvbWN0bF90KSB1
X2RvbWN0bCkNCj4+ICAgICAgIGNhc2UgWEVOX0RPTUNUTF9kZWFzc2lnbl9kZXZpY2U6DQo+PiAg
ICAgICBjYXNlIFhFTl9ET01DVExfZ2V0X2RldmljZV9ncm91cDoNCj4+ICAgICAgICAgICByZXQg
PSBpb21tdV9kb19kb21jdGwob3AsIGQsIHVfZG9tY3RsKTsNCj4+ICsNCj4+ICsgICAgICAgIGlm
ICggIXJldCB8fCByZXQgPT0gLUVPUE5PVFNVUFAgKQ0KPiBJdCBpcyBiZXR0ZXIgdG8gaW52ZXJ0
IHRoZSBjaGVjazoNCj4NCj4gaWYgKCByZXQgPCAwICYmIHJldCAhPSAtRU9QTk9UU1VQUCApDQo+
ICAgICAgcmV0dXJuIHJldDsNCisNCj4+ICsgICAgICAgIHsNCj4+ICsgICAgICAgICAgICBpbnQg
cmV0MTsNCj4+ICsgICAgICAgICAgICAvKg0KPj4gKyAgICAgICAgICAgICAqIEFkZCBjaGFpbmVk
IGhhbmRsaW5nIG9mIGFzc2lnbmVkIERUIGRldmljZXMgdG8gc3VwcG9ydA0KPj4gKyAgICAgICAg
ICAgICAqIGFjY2Vzcy1jb250cm9sbGVyIGZ1bmN0aW9uYWxpdHkgdGhyb3VnaCBTQ0kgZnJhbWV3
b3JrLCBzbw0KPj4gKyAgICAgICAgICAgICAqIERUIGRldmljZSBhc3NpZ24gcmVxdWVzdCBjYW4g
YmUgcGFzc2VkIHRvIEZXIGZvciBwcm9jZXNzaW5nIGFuZA0KPj4gKyAgICAgICAgICAgICAqIGVu
YWJsaW5nIFZNIGFjY2VzcyB0byByZXF1ZXN0ZWQgZGV2aWNlLg0KPj4gKyAgICAgICAgICAgICAq
IFRoZSBhY2Nlc3MtY29udHJvbGxlciBEVCBkZXZpY2UgcHJvY2Vzc2luZyBpcyBjaGFpbmVkIGFm
dGVyIElPTU1VDQo+PiArICAgICAgICAgICAgICogcHJvY2Vzc2luZyBhbmQgZXhwZWN0ZWQgdG8g
YmUgZXhlY3V0ZWQgZm9yIGFueSBEVCBkZXZpY2UNCj4+ICsgICAgICAgICAgICAgKiByZWdhcmRs
ZXNzIGlmIERUIGRldmljZSBpcyBwcm90ZWN0ZWQgYnkgSU9NTVUgb3Igbm90IChvciBJT01NVQ0K
Pj4gKyAgICAgICAgICAgICAqIGlzIGRpc2FibGVkKS4NCj4+ICsgICAgICAgICAgICAgKi8NCj4+
ICsgICAgICAgICAgICByZXQxID0gc2NpX2RvX2RvbWN0bChvcCwgZCwgdV9kb21jdGwpOw0KPj4g
KyAgICAgICAgICAgIGlmICggcmV0MSAhPSAtRU9QTk9UU1VQUCApDQo+PiArICAgICAgICAgICAg
ICAgIHJldCA9IHJldDE7DQo+PiArICAgICAgICB9DQo+PiAgICAgICAgICAgYnJlYWs7DQo+PiAg
IA0KPj4gICAgICAgY2FzZSBYRU5fRE9NQ1RMX2dldF9wYWdpbmdfbWVtcG9vbF9zaXplOg0KPj4g
ZGlmZiAtLWdpdCBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2RldmljZV90cmVlLmMgYi94ZW4v
ZHJpdmVycy9wYXNzdGhyb3VnaC9kZXZpY2VfdHJlZS5jDQo+PiBpbmRleCAwNzVmYjI1YTM3Li4y
NjI0NzY3ZTUxIDEwMDY0NA0KPj4gLS0tIGEveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvZGV2aWNl
X3RyZWUuYw0KPj4gKysrIGIveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvZGV2aWNlX3RyZWUuYw0K
Pj4gQEAgLTMxOCw2ICszMTgsMTIgQEAgaW50IGlvbW11X2RvX2R0X2RvbWN0bChzdHJ1Y3QgeGVu
X2RvbWN0bCAqZG9tY3RsLCBzdHJ1Y3QgZG9tYWluICpkLA0KPj4gICAgICAgICAgICAgICBicmVh
azsNCj4+ICAgICAgICAgICB9DQo+PiAgIA0KPj4gKyAgICAgICAgaWYgKCAhZHRfZGV2aWNlX2lz
X3Byb3RlY3RlZChkZXYpICkNCj4+ICsgICAgICAgIHsNCj4+ICsgICAgICAgICAgICByZXQgPSAw
Ow0KPj4gKyAgICAgICAgICAgIGJyZWFrOw0KPj4gKyAgICAgICAgfQ0KPiBJIGFtIGNvbmNlcm5l
ZCBhYm91dCB0aGlzOiBwcmV2aW91c2x5IHdlIHdvdWxkIGNhbGwNCj4gaW9tbXVfYXNzaWduX2R0
X2RldmljZSBhbmQgdGhlIHNhbWUgY2hlY2sgYXQgdGhlIGJlZ2lubmluZyBvZg0KPiBpb21tdV9h
c3NpZ25fZHRfZGV2aWNlIHdvdWxkIHJldHVybiAtRUlOVkFMLiBOb3cgaXQgaXMgYSBzdWNjZXNz
Lg0KPg0KPiBJIGFtIG5vdCBzdXJlIHRoaXMgaXMgYXBwcm9wcmlhdGUuIEkgd29uZGVyIGlmIGlu
c3RlYWQgd2Ugc2hvdWxkOg0KPg0KPiAtIHJlbW92ZSB0aGlzIGNodW5rIGZyb20gdGhlIHBhdGNo
DQo+IC0gY2hhbmdlIHRoZSByZXR1cm4gZXJyb3IgZm9yICFkdF9kZXZpY2VfaXNfcHJvdGVjdGVk
IGF0IHRoZSB0b3Agb2YNCj4gICAgaW9tbXVfYXNzaWduX2R0X2RldmljZSBmcm9tIC1FSU5WQUwg
dG8gLUVPUE5PVFNVUFANCj4gLSB0aGlzIHdvdWxkIGZhbGwgaW50byB0aGUgc2FtZSByZXQgIT0g
LUVPUE5PVFNVUFAgY2hlY2sgYWZ0ZXINCj4gICAgaW9tbXVfZG9fZG9tY3RsDQoNClRoYXQncyBh
IGdvb2QgcG9pbnQuIEkgdGhpbmsgd2Ugc2hvdWxkIGRvIHRoZSBzYW1lIGZvcg0KDQogPiBpZiAo
ICFpc19pb21tdV9lbmFibGVkKGQpICkNCg0KID7CoCByZXR1cm4gLUVJTlZBTDsNCg0KYmVjYXVz
ZSBpbiB0aGlzIGNhc2Ugd2Ugc2hvdWxkIHByb2Nlc3Mgc2NpIGFzIHdlbGwuIEkgd2lsbCBkbyB0
aGUgY2hhbmdlDQoNCj4+ICAgICAgICAgICByZXQgPSBpb21tdV9hc3NpZ25fZHRfZGV2aWNlKGQs
IGRldik7DQo+PiAgIA0KPj4gICAgICAgICAgIGlmICggcmV0ICkNCj4+IC0tIA0KPj4gMi4zNC4x
DQo+Pg==


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 11:45:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 11:45:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012925.1391444 (Exim 4.92)
	(envelope-from )
	id 1uPgMy-00022I-Kd; Thu, 12 Jun 2025 11:45:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012925.1391444; Thu, 12 Jun 2025 11:45: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 1uPgMy-00022B-Hs; Thu, 12 Jun 2025 11:45:20 +0000
Received: by outflank-mailman (input) for mailman id 1012925;
 Thu, 12 Jun 2025 11:45: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 1uPgMx-000222-6C
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 11:45:19 +0000
Received: from mail36.us4.mandrillapp.com (mail36.us4.mandrillapp.com
 [205.201.136.36]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b55df9ed-4782-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 13:45:17 +0200 (CEST)
Received: from pmta15.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail36.us4.mandrillapp.com (Mailchimp) with ESMTP id 4bJ1173Yy9zS62Gxc
 for ; Thu, 12 Jun 2025 11:45:15 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 8d8ce76ea9094f4393af6d5f0659fcb0; Thu, 12 Jun 2025 11:45: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: b55df9ed-4782-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1749728715; x=1749998715;
	bh=7cDHf1g3XpDeCPvM0pPKcTSosiJNoQW7LvEECDF8XZs=;
	h=From:Subject:Message-Id:To:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=pSSyYii3XHTeNWC08NikLcoUe+0csC78ihdYgosK2TTh2U+ijqYjKj/0rj2VPFQeG
	 bouA7SN+6X+wy8MU38XWiZz8M1hDPVjN6LcwBIL3HhLwZphISfV8ysfon4gDtNHhwt
	 aKzWflh1/2OqTdQ/B6pIaagUhEWant4w/k9AbeNhcCjWGus4luF9fB42V2ZjgOGJmc
	 KYzvS5Cf2ArrJ4f4iXjggMuc0JQjhmlPMh+b8UI38s4nUDb/hS+HW5RYfRUEVtcb/E
	 IUwzxVTLtTv3BOhDqfr2/V76HR+k7MO+iCnV+IxnLfUhzpV3NEod0iH3De3D8KhK5U
	 1XHoQ9uteq5Gw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1749728715; x=1749989215; i=teddy.astie@vates.tech;
	bh=7cDHf1g3XpDeCPvM0pPKcTSosiJNoQW7LvEECDF8XZs=;
	h=From:Subject:Message-Id:To:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=DDKBXRb3dcMeSPQckefvbFlqZ1VZc1e9oiUhNInNRzwpzYogT2iXE1nxqkRsE9CUL
	 +43kb9bHuFnCGTYx5yFaDHf6YTg/2l/ZZyHxEtxXLjHDSY7j3buPs69qEi+Es8tquv
	 MphH4+b5BbBOShw1mct7q4PXfA3vd3GRSHcnkqwGlihUwOn7RJuUanbDc9SebNqmFc
	 VOHA3fXoI1HE+Ow8nSuLL4VtwJnCU9i/8V+NIMofakpMrM7tlW4fgdAsyy62ZblwOQ
	 5Bb6uYQFn5VDUj1tuOyaO68wqwGpaq4We1c3Sbsp4ySHg6LK5wxQ3oOREJGt97UkQO
	 pkrrB+4W/pVHg==
From: "Teddy Astie" 
Subject: =?utf-8?Q?[RFC]=20Proposed=20x86=20shadow=20paging=20changes?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1749728714870
Message-Id: 
To: Xen-devel 
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.8d8ce76ea9094f4393af6d5f0659fcb0?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250612:md
Date: Thu, 12 Jun 2025 11:45:15 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Hello,

In Xen x86, there is the shadow paging that could be used in some cases 
(notably with HVM), and is used when HAP is not available. It may also 
be used in very specific cases for PV guests.

With the vast majority of hardware supporting HAP (through EPT or NPT), 
it's rarely used in practice for HVM, with most downstream projects 
(XenServer, XCP-ng, QubesOS) are compiling-out its support by default. 
It also performs very significantly worse than HAP.

Therefore, it's not very used in production, and unsurprisingly isn't 
actively being worked on (most projects being around HAP).

One of the issues of Shadow Paging is that it relies on a heavy set of 
optimizations, with some of them being effectively obselete 
(optimisations based on heuristics designed for more than 20 years old 
kernels) or eventually problematic (e.g with modern CPU mitigations e.g 
L1TF mitigations).
Most of these optimizations are hard to reason regarding reliability and 
security and difficult to debug. Some of these optimizations causes very 
subtle issues with TLB refactoring for ASID management rework [1].
Moreover, it's fair to say performance is no longer the priority for 
shadow paging.

My proposal would be to :
- significantly reduce the complexity of shadow paging by dropping most 
of the complex optimizations
- consider Shadow Paging as Deprecated
 > Functional completeness: Yes
 > Functional stability: Quirky
 > Interface stability: No (as in, may disappear the next release)
 > Security supported: Yes

Teddy

[1] 
https://lore.kernel.org/xen-devel/9cdb3e67abd01390bcc4cd103ca539d6bf7adbc0.1747312394.git.teddy.astie@vates.tech/


 | Vates

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Thu Jun 12 12:01:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 12:01:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012937.1391465 (Exim 4.92)
	(envelope-from )
	id 1uPgcG-0005YP-6Q; Thu, 12 Jun 2025 12:01:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012937.1391465; Thu, 12 Jun 2025 12: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 1uPgcG-0005YI-3a; Thu, 12 Jun 2025 12:01:08 +0000
Received: by outflank-mailman (input) for mailman id 1012937;
 Thu, 12 Jun 2025 12: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 1uPgcE-0005R6-Iq
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 12:01:06 +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 e9cc937e-4784-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 14:01:03 +0200 (CEST)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-3a4f72cba73so1442610f8f.1
 for ; Thu, 12 Jun 2025 05:01:03 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-748809eb8e5sm1242714b3a.121.2025.06.12.05.00.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 05:01:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e9cc937e-4784-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749729663; x=1750334463; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=/xI/LcuXIWsfINO5aYj3SqHmoStg174fswcrGzC6qzM=;
        b=ACF9QGp+EyVl8ntVG52nAnDkSDM6Bsl6i1jPlj+hszirIXmrpNymQhISyzEqwiWPRg
         MnDkBam6qzPvfyZCStaRDjVBli1LXUWKQcYaaO/pJSg64lPFsugjRZDPEp59u9VN4iPo
         6/OBg1UzIu3ziqyIipVdKgvSgAYcLgIME55yohm6RsjEg/t2AFO3yuVtzbggfR+xZPs+
         VuKFJnLYHI10mAIJkc7YQvyjImu6KdztlxRdLaceixWR5LAvXOh8NsR+HZjxIQPqvdCB
         v0Cilyt1sDsNq6pHBrtdnhgp7Vp9XSAb7gqMpH2dFOuIklFaUmJpsY70O2flcJR1syRI
         w/ew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749729663; x=1750334463;
        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=/xI/LcuXIWsfINO5aYj3SqHmoStg174fswcrGzC6qzM=;
        b=LHRKOI8JpnN6p1UIp7I206NDKROxl86TDbX6L5Fz2DZfL/ZEDJQIfUSCaV84mJhiMr
         v/Uhek2B6CoX5PYL75CPr+y8no0fr3X+beUSkY/fU+ggQfZYNN2ajcTpbfOd8BCBYnwH
         nX78ZLPGBsr28CkOJ4QO0jI5+7HIt/99T7mvMzm/yRykbObrbUrIPKUu8o2Q22f3KTwh
         U8qPyZmIGyC36awXvzzrlG1s4lnVtLg3y58rcuBarqUpqCQYH0CLwTXo++1MzAc4N21M
         e7bzZ4I+g2rLe8mD3F5XUjwKZpa5vjX3jRqGLyRiJ1GpD18fLuUvTXR3BFdqSkRy+cfy
         LGEA==
X-Forwarded-Encrypted: i=1; AJvYcCWaDXkJEJb9LAo3yFx1t+pCCkEhFCYFTghg/s5z2aVd48byWihak0OYMMLrraCwA0oJb/KdvQrPTNs=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy1t3T1Ym7s0Db/wfsHDQ+J35bxx79F8zxj6JVvlM1nkER5jInN
	Q5vBihQYWLJE5/NblCNr/5a0OCh7SgC5J8th67OuJBOdUYqhA4cUPR7VmBHDrTcRdYVpClPe4QQ
	z8f8=
X-Gm-Gg: ASbGnctLomAdN+U+p2M0PyjCdJTGVfOUP30CDZGET98kdFyHlizM2tvXT3vgG3w8YLj
	WEfcUcNkAIQQY0QitSP3LiLg97Nt9VbfaN3Myo7ajThtiA/gtj/wmfmB17PBlJk5g+rt7zBB8fT
	xf2BLddH8tJjHIZQ2mlwrpIMb0AXIxvzxOeT8HFc3TH3RSEfRkwa1Exver4BIt2dN3ZWed6Zl1p
	QIY/C9kLivOVomQ9TLigcKckvMagus1NyJKZDgX/3aowAEf6wNm0V+4X7/v1ncrixnNWKwAriIa
	Yye3rMDCvlfb1y7LIMmZXq+LV8A7/G9xixb99PJdlewy5Gh1i65HywnybrMjTFLOxwrhOj8xQi0
	YWTf1FTEX7LMoLi7cxNrdzMZlgv2qLrF/YSrEhsdqtuUJ1N0=
X-Google-Smtp-Source: AGHT+IFqG0iVhbLcWL+H0zd176P5nf7tr+Wy+8XVQ061661wZeGpyChVWQi2TfpkB6urTr3JiboS/g==
X-Received: by 2002:a05:6000:400d:b0:3a4:edf5:8a41 with SMTP id ffacd0b85a97d-3a5607630ccmr2679237f8f.4.1749729662339;
        Thu, 12 Jun 2025 05:01:02 -0700 (PDT)
Message-ID: <70ab97d7-8352-4252-be77-659582e1ca35@suse.com>
Date: Thu, 12 Jun 2025 14:00:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/8] x86/pdx: simplify calculation of domain struct
 allocation boundary
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Andrew Cooper , xen-devel@lists.xenproject.org
References: <20250611171636.5674-1-roger.pau@citrix.com>
 <20250611171636.5674-2-roger.pau@citrix.com>
 <6abadf32-836f-45fb-bb3a-3afdf97e157b@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.06.2025 12:46, Roger Pau Monné wrote:
> On Thu, Jun 12, 2025 at 11:03:21AM +0200, Jan Beulich wrote:
>> On 11.06.2025 19:16, Roger Pau Monne wrote:
>>> @@ -498,14 +474,15 @@ struct domain *alloc_domain_struct(void)
>>>       * On systems with CONFIG_BIGMEM there's no packing, and so there's no
>>>       * such restriction.
>>>       */
>>> -#if defined(CONFIG_BIGMEM) || !defined(CONFIG_PDX_COMPRESSION)
>>> -    const unsigned int bits = IS_ENABLED(CONFIG_BIGMEM) ? 0 :
>>> -                                                          32 + PAGE_SHIFT;
>>> +#if defined(CONFIG_BIGMEM)
>>> +    const unsigned int bits = 0;
>>>  #else
>>> -    static unsigned int __read_mostly bits;
>>> +    static unsigned int __ro_after_init bits;
>>>  
>>>      if ( unlikely(!bits) )
>>> -         bits = _domain_struct_bits();
>>> +         bits = flsl(pfn_to_paddr(pdx_to_pfn(
>>> +             1UL << (sizeof(((struct page_info *)NULL)->v.inuse._domain) * 8))))
>>> +             - 1;
>>
>> While Andrew did point you at sizeof_field(), we can have this even less verbose
>> by utilizing that frame_table is of the right type and (almost) globally in scope.
>>
>> Further, why use pfn_to_paddr()?
>>
>>          bits = flsl(pdx_to_pfn(1UL << 
>>                                 (sizeof(frame_table->v.inuse._domain) * 8))) +
>>                 PAGE_SHIFT - 1;
> 
> I've introduced and used pdx_to_paddr(), which I think it's more
> natural.  We already had a paddr_to_pdx() which was missing it's
> bidirectional equivalent.  It's now:
> 
>          bits = flsl(pdx_to_paddr(1UL << (sizeof_field(struct page_info,
>                                                        v.inuse._domain) * 8)))
>                 - 1;

Textually this is better, yes. I won't insist on the other variant, while
still noting that your way there's an extra shift whereas my way there's
merely an extra add.

>> However, it further feels like this was off by one; we had similar issues over
>> time in several places. There potentially being a gap between one less than
>> the PDX used here and that very PDX, don't we need to calculate based on the
>> "one less" value here? Hmm, there being a gap means no allocation would
>> succeed for the precise value of "bits" (in the mask-compression scheme), so
>> functionally all would be fine. Yet just to avoid setting a bad precedent I
>> think we'd still be better off using
>>
>>          bits = flsl(pdx_to_pfn((1UL << 
>>                                  (sizeof(frame_table->v.inuse._domain) * 8)) -
>>                                 1)) + PAGE_SHIFT;
>>
>> If one would log the value of bits, the result would then also be less
>> confusing in (at least) the mask-compression scheme.
> 
> 
> Is the above correct tough?
> 
> Take for example the hypothetical case where pdx_to_pfn() returns
> 0x10.

Hmm, yes - while impossible in the mask-compression scheme, it is in
principle possible with other schemes (like the offset one).

>  Then flsl() will return 5 (let's leave the PAGE_SHIFT
> adjustment out for the example here).  The allocation bit width would
> be off-by-one, because allocating using a bit width of 5 would also
> allow 0x11 to be allocated, and that won't be correct.
> 
> I think we need to get the bit width of the next pdx (so the
> non-inclusive end of the range), and then subtract 1 from it,
> otherwise the allocation bit width is possibly off-by-one.

I think you're right, and I can't really see how to (easily) get the more
precise value for the mask-compression scheme then. I would therefore
like to ask that you attach a comment clarifying the slight oddity.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 12:02:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 12:02:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012944.1391476 (Exim 4.92)
	(envelope-from )
	id 1uPgdV-0006BA-Fh; Thu, 12 Jun 2025 12:02:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012944.1391476; Thu, 12 Jun 2025 12: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 1uPgdV-0006B3-Cj; Thu, 12 Jun 2025 12:02:25 +0000
Received: by outflank-mailman (input) for mailman id 1012944;
 Thu, 12 Jun 2025 12:02: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 1uPgdT-0006As-SZ
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 12:02: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 19108feb-4785-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 14:02:22 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3a54700a463so538642f8f.1
 for ; Thu, 12 Jun 2025 05:02:22 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2364e6d99b1sm12124005ad.116.2025.06.12.05.02.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 05:02:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 19108feb-4785-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749729742; x=1750334542; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=jz1D4NLhV0Y5c5KxrDkXzqtjgWF7HMWo307y7/2+RrQ=;
        b=RmW3cX8cbpSvNm71Ds3ftj+6QR1dFNs75M+sDLWSLIc541kPxxuC+B1oHbOH/bfjpf
         WVM6FCjcM+rLqFo4C87ZR4EGYZKUglAVwWX+kz2hdBjrZ5UqW5KcIarlTKIKKMhE51qW
         WgpaVu4M9Mz6TZXQIeTTUDzAQGUbYwqvbGEuNZCzwSzj9cj5g/V9qAqkXHPV6uaxbK7P
         SK7xNrWk1qMQ9rbeLNwu+LuwLF3SEnkDuG4c+by69Vpsn3yvmCWmdFBKie3r1B9YIOYS
         9HUQkrety0f06DneIgGg9uTYHX/4QqoJJIAVeA+j+7n3qgM0hz1FtDlalSkdDzZxiJyk
         OpZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749729742; x=1750334542;
        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=jz1D4NLhV0Y5c5KxrDkXzqtjgWF7HMWo307y7/2+RrQ=;
        b=uDNufAh+ZEmagYdB/vQnb+fTob12DU2jp3vu4D6y8CtEr2yo3rm1v7RHb/FrQbTYTj
         7oVeFog9ita5N2Z4R2cDgGKGJrHP6q/8CDVSyyFfuPjAnuupA+da6idNa1ZWjSQ73ayA
         GQdyH5M8dCHyx51yQjJebTsWpqfdLFjHzj+7lOx/5F0IS1L7DqZiJQZY6VGSdzcLZrZt
         oAxR4ZZOhHhVHwRUqSm4o7KLH9AyjkFIt8tbjMCvdLgom7zZ3Yfw6YhoGWdu0P1UopOD
         /rIZTSoCBPDK3VCpdQFHEIjuQ57i7J1MrIubIBijTKnj4991GatDZiSF9y1dkKhEaqrb
         aM7A==
X-Forwarded-Encrypted: i=1; AJvYcCWbeRw86fROlmHEZdk7692vmRuMje1/jIqnDjBgzOqiHJeOe/+BbZxqOIqLHGaIB8Mm7YEJUukxc8I=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx4T9TCTzdTFc2Am68mOnI63DYXaBM1YybG+mFmCPJ59FLOyQTy
	QJpM9LE44WwlnUnqXZHiS1grgOomRMZG3L5PqOa1IRqcFOsMeiLm6oJzyh92y/WfIA==
X-Gm-Gg: ASbGncsEmyz9E5GBRXc1hZdgsXUVR93QzqDocXfA/0LPxSAdp1+IWgCcY0uvT6JL7yp
	04BbARkCzdGMEpW9LHo+YFqhDmpQJTveBKeVX3sPc1/lv0sL4JNQycpN6HHDaX0jqlKhX422ems
	vf6pFvwpDBy50q5wATMxP0OZDFsPWuaGgWI4+nMEtO8T+eXuqpN3lx49E65jo0uqjrj22e9ifMR
	c4jFG9N68eQNvy5rfbIiIW6kvIQi9EzP2KLxy94l+4f51noHyKsADHMOFKNYxoEny2zdq0A8tdH
	/bxoWqbm+vaMQv8uc9BS8AgzU3SphYAjWGUEF6HymS7F3VhYL6zhwzEpfnbUDDUqN5K67fwgtYE
	wPs/Vud4S3+j0uMs7t3JwRpEuD6xHAGN8mx/iv58nBOLvALA=
X-Google-Smtp-Source: AGHT+IF84x8rjTtpG3ogTw4fedIa2jSnt/AOCR8gnICiC60itGzx/aRwt+xLQHNkb4rwOEWI04ZTEw==
X-Received: by 2002:a05:6000:2086:b0:3a3:70ab:b274 with SMTP id ffacd0b85a97d-3a56078f39cmr2569776f8f.12.1749729741866;
        Thu, 12 Jun 2025 05:02:21 -0700 (PDT)
Message-ID: <9074f1a6-a605-43f4-97f3-d0a626252d3f@suse.com>
Date: Thu, 12 Jun 2025 14:02:13 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/8] pdx: introduce function to calculate max PFN based on
 PDX compression
To: Julien Grall , Stefano Stabellini
 , Michal Orzel 
Cc: Andrew Cooper ,
 Anthony PERARD , xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20250611171636.5674-1-roger.pau@citrix.com>
 <20250611171636.5674-3-roger.pau@citrix.com>
 <9e7925c4-3695-4320-8552-4ee0e39350e4@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.06.2025 12:48, Roger Pau Monné wrote:
> On Thu, Jun 12, 2025 at 11:11:14AM +0200, Jan Beulich wrote:
>> On 11.06.2025 19:16, Roger Pau Monne wrote:
>>> This is the code already present and used by x86 in setup_max_pdx(), which
>>> takes into account the current PDX compression, plus the limitation of the
>>> virtual memory layout to return the maximum usable PFN in the system,
>>> possibly truncating the input PFN provided by the caller.
>>>
>>> This helper will be used by upcoming PDX related changes that introduce a
>>> new compression algorithm.
>>>
>>> Signed-off-by: Roger Pau Monné 
>>> ---
>>>  xen/arch/x86/setup.c  | 19 ++-----------------
>>>  xen/common/pdx.c      | 25 +++++++++++++++++++++++++
>>>  xen/include/xen/pdx.h |  8 ++++++++
>>>  3 files changed, 35 insertions(+), 17 deletions(-)
>>
>> This is all fine for x86, but on Arm you introduce unreachable code, which
>> Misra dislikes. Yet then it feels like it's wrong anyway that the function
>> isn't used there.
> 
> I was also concerned regarding why ARM doesn't have an equivalent
> function.  Is the frametable there supposed to cover up to the maximum
> physical address?  In which case there's likely no need for any PDX
> compression in the first place?

Question goes to Arm folks.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 12:03:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 12:03:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012950.1391486 (Exim 4.92)
	(envelope-from )
	id 1uPgeN-0006fw-Np; Thu, 12 Jun 2025 12:03:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012950.1391486; Thu, 12 Jun 2025 12:03: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 1uPgeN-0006fp-Kt; Thu, 12 Jun 2025 12:03:19 +0000
Received: by outflank-mailman (input) for mailman id 1012950;
 Thu, 12 Jun 2025 12:03: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 1uPgeM-0006fe-Jl
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 12:03: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 3923b8f6-4785-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 14:03:16 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3a51481a598so544028f8f.3
 for ; Thu, 12 Jun 2025 05:03:16 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2364e71d0e0sm12092495ad.241.2025.06.12.05.03.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 05:03:15 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3923b8f6-4785-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749729796; x=1750334596; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=/HPRT47sa0BC/JSNfhp1oo02hX3npktkJyUI/nd+AMs=;
        b=cXLEZ3VGC65y39nJaotgVbf/AxhGvgqMGVULK5bCAbKysDorBGfu2w7gIeBFg07ibi
         Gdc5/5EMCOFPOtDJQulDQO8cn9uLJCCFefzw6sAKJ+rgKKsbjO90/xEHdWy72YaYOgOK
         BaId/04mYlNa2/kdy0R4f+QD38utvLqRN9+SYfSDxyXLJolMU0lBDn3Rf0WZCpGaLWqM
         BgHGpgt/CbXCiRhcRmp1jhL0vncIFnnPwR+iHl6zp2SvVluToDu/d37DL/KxAj2DjxCR
         ifffv9vxsYvBRhgBsukTBuK0852l1a9fALVIQIp/8Efh68+zA6z5hFrwfLqGSlBQ2wOH
         Igyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749729796; x=1750334596;
        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=/HPRT47sa0BC/JSNfhp1oo02hX3npktkJyUI/nd+AMs=;
        b=F2Mi8bdkk43fZLHuUMjgF1mHDDv+sNOgwVhDHK2zWbRGmOF2L+BSNhSPMlafWAP3+h
         YR558BKZZW/yuMypmj4Gb03aehjJNLsxRApDucuCTPPR2DcbibTUD5YkQJTSev+qPsDF
         rOdEuw/ngLDFKqClPYg1cE9Uw9worEvAQRUilBcd45NA07pj5vAfyi8Yk6sEl/zjJPnC
         P2WvfxEl3exqImoYLD/zwCN5RFz+2v5yKH01sTvWCHSHxyZ3lSFtoC9vfnTWWIdeZ5kW
         BfTaoFwZvr1FWMrNx0RI5whYseNMOqrDTWmoHruPrHDJ2YobKzkHVnR3IAovLkw6sKwZ
         KH5w==
X-Forwarded-Encrypted: i=1; AJvYcCXO36bIS1ixrXEFFsIWljyHG29z+RY2Dx+JrV7dq6j3+ekdQPQ+bWIy9ww47PmIB8Uv4BEFwvaWD+8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzz4+/UHa+qVtVuUyVFZiX6iVhSBtIj7px1azS2hYd20H45nmGv
	1VrVGFbNvl2VzfLXCo6wn//VLN097DWlU1ZvJkDcUL6Kzn8xEfJZUt7Qarf5KnqfIA==
X-Gm-Gg: ASbGncuIO+ZoP62Jy1DWFkRwS/Eo3NXuxLtFrPMlPna4xX5W9Rq76Wxe3wNFxw2zF/S
	oDtQyiIrPZc54CrNRjZ5/n/sX0+D5Ae2XATfA0UwFexKrvXdg2+IEvKYVvx50sHTAnCtz7akoZm
	Dw3PbCoA7Z3fxQq48zwTBeS8zuEFM8wBb0dPyv0LgxWSrnDSS4oTNURwv62g6SqOUpaux60h8gD
	2kV+YwGTSWmJIgV2mxYicuCMR32CJPmBYymRF61vrvstuTfOb7/fsQCw3+qLb9FnsoeruJW/l4Y
	WYSa2epsWJw1Gy8FOtd8xW8HHX4Rs9zheK/GZGdxjq68MU4T2MilIsn1WmsarPPPY32HHFSEQMS
	29tL1LabPbVnnWH8IlPzVo7mjEzLCsu1YvbYbGR5Hmz2Bt2M=
X-Google-Smtp-Source: AGHT+IF6Y0PsbuJ37jhEenRuoacjKhySlnxuigS+87dKehiQLPVNZZrAz+QI9D/YbcMla/qMe4LApg==
X-Received: by 2002:a5d:64c3:0:b0:3a4:d994:be7d with SMTP id ffacd0b85a97d-3a56130a6a1mr2105412f8f.23.1749729795839;
        Thu, 12 Jun 2025 05:03:15 -0700 (PDT)
Message-ID: <62236850-5c20-429c-befb-6cb12692598e@suse.com>
Date: Thu, 12 Jun 2025 14:03:06 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 4/8] pdx: provide a unified set of unit functions
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD , xen-devel@lists.xenproject.org
References: <20250611171636.5674-1-roger.pau@citrix.com>
 <20250611171636.5674-5-roger.pau@citrix.com>
 <84080c88-b68f-4ab3-8b69-a3e45e9c74d9@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.06.2025 12:51, Roger Pau Monné wrote:
> On Thu, Jun 12, 2025 at 10:36:36AM +0200, Jan Beulich wrote:
>> On 11.06.2025 19:16, Roger Pau Monne wrote:
>>> @@ -80,6 +81,39 @@ unsigned long get_max_pfn(unsigned long top_pfn)
>>>      return pdx_to_pfn(pdx - 1) + 1;
>>>  }
>>>  
>>> +#ifndef CONFIG_PDX_NONE
>>> +
>>> +#ifdef CONFIG_X86
>>> +# include 
>>> +# define MAX_PFN_RANGES E820MAX
>>> +#elif defined(CONFIG_HAS_DEVICE_TREE)
>>> +# include 
>>> +# define MAX_PFN_RANGES NR_MEM_BANKS
>>> +#else
>>> +# error "Missing architecture maximum number of RAM ranges"
>>> +#endif
>>> +
>>> +/* Generic PFN compression helpers. */
>>> +static struct pfn_range {
>>> +    unsigned long base, size;
>>> +} ranges[MAX_PFN_RANGES] __initdata;
>>> +static unsigned int __initdata nr;
>>
>> One other remark / nit: For my taste, "nr" isn't a suitable name for a static.
>> It's too short, and hence the risk is too high that some function would add a
>> local aliasing this one.
> 
> Is nr_ranges enough to avoid aliasing?

Yes, at least as far as I'm concerned.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 12:03:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 12:03:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012952.1391495 (Exim 4.92)
	(envelope-from )
	id 1uPgei-00076a-Vf; Thu, 12 Jun 2025 12:03:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012952.1391495; Thu, 12 Jun 2025 12:03: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 1uPgei-00076T-Su; Thu, 12 Jun 2025 12:03:40 +0000
Received: by outflank-mailman (input) for mailman id 1012952;
 Thu, 12 Jun 2025 12:03: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 1uPgeh-0006fe-6d
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 12:03:39 +0000
Received: from AS8PR03CU001.outbound.protection.outlook.com
 (mail-westeuropeazlp170120005.outbound.protection.outlook.com
 [2a01:111:f403:c201::5])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 44d49454-4785-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 14:03:36 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by AM9PR03MB7489.eurprd03.prod.outlook.com (2603:10a6:20b:272::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.19; Thu, 12 Jun
 2025 12:03:33 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%4]) with mapi id 15.20.8769.029; Thu, 12 Jun 2025
 12:03: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: 44d49454-4785-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=VNkWARBg/t7M2GXXmZqPBdmiCbdsOqcjMNSvp6l8ypUdu273N1VdXMRnXZ4yDARqmoCsPF9AgN+Vbdz8USs5p4r5X43+dQuhTwR3LCfGfWTJpRJICxzmd7hlxOojrrU0PeYpYQuMu6D6JjoAOJ2EkXCwgGmL48DFQJ/LlCxJtRLUV/Phtiwra85GOl88mwvgLCV96ItJFcpoupg1bzRg3xUROEaSPXTdVIa1dwuSQ3LfHDXkTvYfg/0EW/Kh1ylbaOoVqui6WXgisGn5vgt1vgOi9nEQaVhu990lg6tumeLYyxE70gAzr7M3Hxe8/kMW1oh9yt0IrSPrjh5cnzQNYg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=tqj7cBELGmJEtuaO6rAUAr8/XSzJseXqbAqHVX/DlUo=;
 b=IxMGmtuRkq2HUbQFrVzXaVxC1Tuscs7QjzjxfoNnjAoCkqjuEq7q4/6qyIImwpmpPsR6t04BCvxA1u8ARuRJSwV+sL9eVMZomoL+iz3WOc8CyjvR0W7IZSXgWShOdbQcLs5/vmjm23M8VE6Cdv02xWooPGhuJcfPyXGhRaIrybFGLJhFa8MCMf8OfvpAOa7GUUn/2Ot3gik/C25H06AZRI+BEvLGQjnnc75PlismxJVZvdlXXh73A+wiwPRha4dArOFcepxdjJ/nncHNtFVR/wBIAnmhxl4MMsWrvEDtonu/s5+PEIC8y4ld6ApD9GVAdwAQQCnc8UiPXgcDF6PrRQ==
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=tqj7cBELGmJEtuaO6rAUAr8/XSzJseXqbAqHVX/DlUo=;
 b=bGl9ne4HlFw5GU/4GcIBX5Qol/edXCuv+NX+9HCWSo+uRrBc7t9+/sD4AwI25Q/w9FBOc5GyHYYqkUgMpbTmvpBncaV9L09oRwTpGW4q++jFfSzzBjhrKrUT+ypqcnyfpMchM/LOkeIWMgDIR1/TSyVTTTyGMUkTIFNdiAIXCSMZGsmUKU3a2mJL3uO2lWJ5AYLu5+GgmFk0FJpeuPgBru2+op+G/tpm13xGUCy2Xavexk3nJawtBOOfKU2839Lk3KvilbEMyusl7zcdcv2+cyBnGpt2N8t5ww5ecZ6XG77EB2oE6Uo4lBUw/vbSMZqLP4bzRChKOAmprkb2za5oaQ==
From: Oleksii Moisieiev 
To: Stefano Stabellini 
CC: "xen-devel@lists.xenproject.org" , Andrew
 Cooper , Anthony PERARD
	, Bertrand Marquis , Jan
 Beulich , Juergen Gross , Julien Grall
	, Michal Orzel ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Volodymyr
 Babchuk , Grygorii Strashko
	
Subject: Re: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC
 multi-agent driver
Thread-Topic: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC
 multi-agent driver
Thread-Index: AQHbyNXPHUV4T01ZEEC9Uxm0LaLKHbPgqpIAgB7nygA=
Date: Thu, 12 Jun 2025 12:03:33 +0000
Message-ID: <6080ff71-2634-4269-8a63-fdafdf03f01b@epam.com>
References: 
 <318044ae12f13b6b297b3f5fda577a1a6cd143da.1747669845.git.oleksii_moisieiev@epam.com>
 
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: PAVPR03MB8946:EE_|AM9PR03MB7489:EE_
x-ms-office365-filtering-correlation-id: a2ac08c3-ff9e-4d88-6922-08dda9a92759
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?WTJuaGU0VzJ4RkZPY1dPVE5waGZsZ3dWYWxyNnUwWS9mRWhDTlRvaHVub2M4?=
 =?utf-8?B?VVpQTm5JTEY1R2RnSjdEMU1MQkk1L1hIVjhUYy9jSzBzV2YzdHdmVlFHRFVH?=
 =?utf-8?B?Ky9Qdm42QkFDYktRdnJ2S3ZCbnZ3NjNLOUVZN0p0RFBoNHcxRlFyU0VucE0r?=
 =?utf-8?B?ZWVIMGR6aDlqVzVXc1hNcUtVdkZmdFlKQXVDNTVsKzRJNkNOdnZOTEhGOWZO?=
 =?utf-8?B?RUI4cEJoc2JEY3dlNEFmeFEvNnp6c0lqdTJYZkxPMWplckxCRGYwclY4YitN?=
 =?utf-8?B?cGI0ZGVUajAyTkhmMk9BcjJYbEZ2TVZ0NVhtMkZvMHU2d0xzem9yY2FDUC81?=
 =?utf-8?B?djZYOWwyOXFQY05kRzgrMzh5ZjUxRklwTDl2bVBUNTNROWlEdHBzaU5SUW1n?=
 =?utf-8?B?TUdoS2djb0h6azhoeVNVVzdraHljNDB5QWVpK0hSd2tTaEJ0T3R2ckltMWt5?=
 =?utf-8?B?QUJQMlZRYVNXeUJ5c3UzWHZSVnUyaEQ0VEdkSHU2WHliSnFKQVNoYm9XZGd0?=
 =?utf-8?B?Vkp6RndyKzY4MHB5YmsrT3I5OUQyS09yK1I4VWhHOCt0YllYU01oeFowY2NW?=
 =?utf-8?B?R3VNMURIY2JMSE1wR21MY2VMSDFwemJ4eThET29RVWJqR2RQcG12bmNuaGsr?=
 =?utf-8?B?bHhmVTVXVGIwZWpKQTFLRGJ0b1NWbXhta21YUHF0cytFQ1U5MFZsU1orNXRj?=
 =?utf-8?B?Z3VzMWREN3hUeFEzVG1DNXhoTVdrbjhPWW5ibEc1N3R0STJtMXVkZXdxU3Vl?=
 =?utf-8?B?M0lScWh1Sm1OVGIzUHI5TUx6L1pDNHZodVJGeDluZGlHdlIvZU1yRTFrUTdQ?=
 =?utf-8?B?NlE5TDdOREZLV2FUdGJ4QUd1U0NmN09LWHl5RVNaSVN1WHV3d3RSTWFSL0Fw?=
 =?utf-8?B?Y2g2VVE0eHVRdjJQeUdUUVZwQ0M2UDB6K09TSmJFNnh0U2QzM09CUUtXMWRh?=
 =?utf-8?B?bGpqdHJWZEVaQjRoUDZDOXJYRnBEa1FBdGkrNEZtNlY3d2tMZmNUY3V3Y29H?=
 =?utf-8?B?WDNjdEZrT1hGeWxkc3VkNXlubjkyUVZ2MUNuUXRGenFaNlVQM0J3eE93amVM?=
 =?utf-8?B?cTdjNklQOW9naHljVlcyblFmdUV6Smdzbk1wVnc5cjB4S29sa21CL21RZG16?=
 =?utf-8?B?UkpNTU1YT3piRW82VHVWVWdUbnJiODJzY2c2RmxlK0RUamJuUmdnOElyTnhG?=
 =?utf-8?B?TXU4R3I0S1p6bXJOQ1VaWW1Kb0hIRjBseE1RWUVHcW9memUvV01ZYzNRdVJp?=
 =?utf-8?B?SGxTcVBhUXNNcUpZSk1yYXlOTjBhMEU0Q003WHBCamtmaS82ZUhTQkh3Ulpu?=
 =?utf-8?B?WSsrUUg2d2s2Wlh2VldjM0l3N2E4VW9TN0RMWTBLN1hRY2dDQllvMm5HWndk?=
 =?utf-8?B?c2pzV256Qkc0RmtycmFpdy8zNEVoSjlZRkZHTklqZzRXVXVScXFOQnRZcCtG?=
 =?utf-8?B?OEVQWXdNOTJobXI3U3VsQlk3MmplaTlqU2EwelN2TkNGWEp6RVpQSjZqWkgv?=
 =?utf-8?B?OXMwOTk5RFZZZmtOcDdJcksxS3owRmc5TnExWDJqNU8vRUwyb2hDdGJ4bHZu?=
 =?utf-8?B?WDROam1LT2hxU3lsQnpxYU01QUxlSlEzRnRHWldzRWJXN2RKQzVIUTR4cmpu?=
 =?utf-8?B?MEVtOHJZZ2tJSTE2UGFkNEZOL2Vpcm5FKytDZ0hOdll4VFNiRWJpKzZXV3JG?=
 =?utf-8?B?UkhsRVBkM0s1VzcvS0EydjBiVUNoeXYvMXdtQk5DeVZxOWhMb3BtNU9GUXhN?=
 =?utf-8?B?WFV6TzkvN1lWZUZCaUhNR2lUWmVpVWl4Q1JSclExWHlsUFVWR0RHY3Q1V0U0?=
 =?utf-8?B?cXRsbnNkVStkdHNoMjQrYnZLcU44Nno3cDJXbXgvK2ZlR3FXU1B5ZENDTTNl?=
 =?utf-8?B?d1dUSDQwdUFNN2p1RExHMlNHUkJxZWx4Q1BIbitFWVVLVXhLWHI2UlhSV2ZQ?=
 =?utf-8?Q?dOQCaGc2CjU=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.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?VDlvajlqZVgxMWtXc2hUc1psVG1UdE9JYjh5VnhmMmwvZ1l5VzF6RVluWjJJ?=
 =?utf-8?B?WDlsYmI3SktDMi9lN3pkSHVzYTlmOHpHQjh0RkxOU1REL1VHdWJ3WE1tL2dM?=
 =?utf-8?B?aFlkbjMrRnAzNUNBZm9UbnZFaUIvL0hnWFBXdUNVVkZ4UGJzOGJweEhLM2dp?=
 =?utf-8?B?UjJZS0lEVkZjVUNsYVdjTWF4L09pQkNHUkF0dFhxcDRoaXlqdmkwWWp1dG1n?=
 =?utf-8?B?SlhZSzFPN05vREVBNFpTTXpFbUtBSjRubFQ0SDcxM1c4MlhWOFBFUHI0NE1B?=
 =?utf-8?B?YUEvVzNackl2cWs3T2NFUnh5dDdHbFVBbHhLTzJxZnBHdE4vS1VQYmR3MUFJ?=
 =?utf-8?B?TUJtZHZYYWo2VmJucWhuT0gyckhaekxJeFJZVzQ2aTEwWlB3UkVjSEFkQnVz?=
 =?utf-8?B?YVJaRDVmOEJOamJ5QjVnaUFhRUZFWFZjZGgvTUhObnk5WSt0cmVIS2d3b0tz?=
 =?utf-8?B?SlJCUXdEUFk5V1BNOE5DblpJWWtkL1lURXliL3cwd29CcFEvYTNSamhkNFNj?=
 =?utf-8?B?NFVtSE1aa3hZdlBiMnM3Z1dzSTU1NnJMSFFXdVM4dDdMaVE0T25VQ3RzK3l2?=
 =?utf-8?B?Ui9aS2xHRDFnNmZCY25nUGxMcUNPdnFOcmZwbURXZ25MKzkxeHZKSzVKOGRw?=
 =?utf-8?B?YTJlbUtIWmdCMG80QnllRnJkK0k0T3hDYk44bWFJaEdaeDIrbTQ0WE9LM2Fa?=
 =?utf-8?B?cWRiS1RKdmYvcXZLSTRnRC9wSnpDbUEvbzloMllieUdwaXR5K3ZGWTIvdUdp?=
 =?utf-8?B?ZXlZZ1oxTlFWRVBtR1dpUUVRcDg1aFRDNDhMV2hXVG9BcXkxT3J5VytOTnZy?=
 =?utf-8?B?Y0xkQmgxSGdQaXlpeXYzdjN3U1Ezd2Uwckg3ZUJaWDdEN09uNUI4a3J3dytM?=
 =?utf-8?B?YVVmRDJDNW1md1E5bjcyQ21pc3FpUnpxNWFMYjNqZ0NpOW1Zcmw2c20zdCs0?=
 =?utf-8?B?cXhMNDlOeHRPazFXdGk0SHdCZjNpV2wvRDgvWHZyNmNDOEV4aWFzOEhxaThm?=
 =?utf-8?B?RVlOaHQxU0ZIMFBIZkdMc0NJR0FWODRjWmt5N1ZHNlppbW1KbmNXN3RRU05q?=
 =?utf-8?B?WFpLQTJQdkovMmFzS2Q2c2E4dkpSVjhWbWpuOWhjMSt6cVJaeU8wVS8rWlBZ?=
 =?utf-8?B?T3dtb0ZYTXN6dFQvamg4NEFUWVpWMDVkdjJHdGx5cXNyU1c5UDVoNitsdnVi?=
 =?utf-8?B?Ylp4S3BvR0ZobURZeGV4ZU0rTWJwWFJSRXlzOW5rQTFERklGS3Rrdlh6b3V3?=
 =?utf-8?B?aGh1bmpHZGFrQUlKek9DY0t6c3NNSGVmYzlLSGVFbkx1YktZaWRVTVc2QnZt?=
 =?utf-8?B?TGFiZzRoVVlwUC9iQWJNTXQvOW5iSWpUdk8rYnFESHBiVHp6ZGhBaVJWM0lI?=
 =?utf-8?B?b1lnWVo3b25uVG94NU1nZTdPWm1LQVVtY3JyOGVEMHJQYU5FZC9od09xR0cw?=
 =?utf-8?B?NWJjcnJSdXVpVXpPOHlyNTFQaEl0ZEczd0VQejlYaVZZSFlXN1BvVm5UT2FM?=
 =?utf-8?B?WHhzREVUbVY2eGxYYkRlTklMdmpJZCs4V2ZMVTFtQ0gvcmZrUGNaZUpaZGdz?=
 =?utf-8?B?TVFvdzU2S3grdm93eUNhcWxnMkRkaWEyaW5zZzVJTkk4YVAwYjZyQkdBck0z?=
 =?utf-8?B?U0NCa1hZaDViL0IzKzkxelJselZtQWtYa3RpZnlydWczWEkrNWNyWWR1bkY0?=
 =?utf-8?B?WXV4Wlh5aVUvZXZjUTZvR3hPNmw1bDUrR01mblI3YW84eWJmSElJOE9NNE01?=
 =?utf-8?B?MTB5UldFTEZDcEt1UHFBMTg5RXdOR3hVQ3JDdUxnZURldWVHUmFVN2pDdGk2?=
 =?utf-8?B?VithV2pSM3NiSGdqT0dmRXZrOU1WVkJTOUhHL1g5VDlXNU5NM0VrK2drMnpl?=
 =?utf-8?B?eDFMVVV3WEdEYUxZaE9WTFJiUERYWW54c2ozbiszTVF0VytzMGNsWGZnYlda?=
 =?utf-8?B?SCtDK3B0ODRxdWg1elcrVVpVWTBwTGJYOUMrVVQzMFEvRmFtbDBoNFhMRmJZ?=
 =?utf-8?B?emdYbFVRNDlRdCszcUpiNXB4RFFWUGlIdUxUU2FvbDZyM0FqbWVQQU5uMFhV?=
 =?utf-8?B?dFdHYytVdHBidGRQSjFueVk5eXprMTJZR2ltYkp5a08xMVI5b2d5R05STVZm?=
 =?utf-8?B?R2J0VkdqeHhyd1d2cE9JdjFVaGRXUVZUUFJPdHNhNGRFUUVlcko3WjB4dDJr?=
 =?utf-8?B?dFE9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <314C559258CA9947BE993E57C4ACD24D@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: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a2ac08c3-ff9e-4d88-6922-08dda9a92759
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2025 12:03:33.0617
 (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: awbPxrtT97qhSL7jj72RqYXXFZwrleXMMusGR3NYwzhYXVu0um7YKkwbWSsHqAQH8+fULD6LpWRmac6Hre60T7ky/kUdj9lwukX3ZGAqYbs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR03MB7489

SGkgU3RlZmFubywNCg0KSSdtIHZlcnkgc29ycnkgZm9yIGEgbG9uZyBzaWxlbmNlLiBQbGVhc2Ug
c2VlIG15IGFuc3dlcnMgYmVsb3c6DQoNCg0KT24gMjMvMDUvMjAyNSAyMzowNiwgU3RlZmFubyBT
dGFiZWxsaW5pIHdyb3RlOg0KPiBPbmUgcXVlc3Rpb24gZm9yIEJlcnRyYW5kIGJlbG93DQo+DQo+
DQo+IE9uIE1vbiwgMTkgTWF5IDIwMjUsIE9sZWtzaWkgTW9pc2llaWV2IHdyb3RlOg0KPj4gVGhp
cyBwYXRjaCBpbnRyb2R1Y2VzIFNDSSBkcml2ZXIgdG8gc3VwcG9ydCBmb3IgQVJNIEVMMyBUcnVz
dGVkIEZpcm13YXJlLUENCj4+IChURi1BKSB3aGljaCBwcm92aWRlcyBTQ01JIGludGVyZmFjZSB3
aXRoIG11bHRpLWFnbmV0IHN1cHBvcnQsIGFzIHNob3duDQo+PiBiZWxvdy4NCj4+DQo+PiAgICAr
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+PiAgICB8ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+PiAgICB8IEVMMyBURi1BIFND
TUkgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+PiAgICArLS0tLS0tLSstLSstLS0tLS0t
Ky0tKy0tLS0tLS0rLS0rLS0tLS0tLSsrDQo+PiAgICB8c2htZW0wIHwgIHxzaG1lbTEgfCAgfHNo
bWVtMiB8ICB8c2htZW1YIHwNCj4+ICAgICstLS0tLSstKyAgKy0tLSstLS0rICArLS0rLS0tLSsg
ICstLS0rLS0tKw0KPj4gc21jLWlkMCB8ICAgICAgICB8ICAgICAgICAgfCAgICAgICAgICAgfA0K
Pj4gYWdlbnQwICB8ICAgICAgICB8ICAgICAgICAgfCAgICAgICAgICAgfA0KPj4gICAgKy0tLS0t
di0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tKw0KPj4gICAgfCAgICAgICAgICAg
ICAgfCAgICAgICAgIHwgICAgICAgICAgIHwgICAgfA0KPj4gICAgfCAgICAgICAgICAgICAgfCAg
ICAgICAgIHwgICAgICAgICAgIHwgICAgfA0KPj4gICAgKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t
LSstLS0tLS0tLS0tLSstLS0tKw0KPj4gICAgICAgICAgIHNtYy1pZDEgfCAgc21jLWlkMnwgICAg
c21jLWlkWHwNCj4+ICAgICAgICAgICBhZ2VudDEgIHwgIGFnZW50MiB8ICAgIGFnZW50WCB8DQo+
PiAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgfCAgICAgICAgICAgfA0KPj4gICAgICAgICAg
ICAgICstLS0tdi0tLSsgICstLXYtLS0tLSsgICstLXYtLS0tLSsNCj4+ICAgICAgICAgICAgICB8
ICAgICAgICB8ICB8ICAgICAgICB8ICB8ICAgICAgICB8DQo+PiAgICAgICAgICAgICAgfCBEb20w
ICAgfCAgfCBEb20xICAgfCAgfCBEb21YICAgfA0KPj4gICAgICAgICAgICAgIHwgICAgICAgIHwg
IHwgICAgICAgIHwgIHwgICAgICAgIHwNCj4+ICAgICAgICAgICAgICB8ICAgICAgICB8ICB8ICAg
ICAgICB8ICB8ICAgICAgICB8DQo+PiAgICAgICAgICAgICAgKy0tLS0tLS0tKyAgKy0tLS0tLS0t
KyAgKy0tLS0tLS0tKw0KPj4NCj4+IFRoZSBFTDMgU0NNSSBtdWx0aS1hZ2VudCBmaXJtd2FyZSBl
eHBlY3RlZCB0byBwcm92aWRlIFNDTUkgU01DL0hWQyBzaGFyZWQNCj4+IG1lbW9yeSB0cmFuc3Bv
cnQgZm9yIGV2ZXJ5IEFnZW50IGluIHRoZSBzeXN0ZW0uDQo+Pg0KPj4gVGhlIFNDTUkgQWdlbnQg
dHJhbnNwb3J0IGNoYW5uZWwgZGVmaW5lZCBieSBwYWlyOg0KPj4gICAtIHNtYy1pZDogU01DL0hW
QyBpZCB1c2VkIGZvciBEb29yYmVsbA0KPj4gICAtIHNobWVtOiBzaGFyZWQgbWVtb3J5IGZvciBt
ZXNzYWdlcyB0cmFuc2ZlciwgWGVuIHBhZ2UgYWxpZ25lZCwNCj4+ICAgcDJtX21taW9fZGlyZWN0
X25jLg0KPj4NCj4+IFRoZSBmb2xsd29pbmcgU0NNSSBBZ2VudHMgZXhwZWN0ZWQgdG8gYmUgZGVm
aW5lZCBieSBTQ01JIEZXIHRvIGVuYWJsZSBTQ01JDQo+PiBtdWx0aS1hZ2VudCBmdW5jdGlvbmFs
aXR5IHVuZGVyIFhlbjoNCj4+IC0gWGVuIG1hbmVnZW1lbnQgYWdlbnQ6IHRydXN0ZWQgYWdlbnRz
IHRoYXQgYWNjZXNzZXMgdG8gdGhlIEJhc2UgUHJvdG9jb2wNCj4+IGNvbW1hbmRzIHRvIGNvbmZp
Z3VyZSBhZ2VudCBzcGVjaWZpYyBwZXJtaXNzaW9ucw0KPj4gLSBPU1BNIFZNIGFnZW50czogbm9u
LXRydXN0ZWQgYWdlbnQsIG9uZSBmb3IgZWFjaCBHdWVzdCBkb21haW4gd2hpY2ggaXMNCj4+ICAg
IGFsbG93ZWQgZGlyZWN0IEhXIGFjY2Vzcy4gQXQgbGVhc3Qgb25lIE9TUE0gVk0gYWdlbnQgaGFz
IHRvIGJlIHByb3ZpZGVkDQo+PiAgICBieSBGVyBpZiBIVyBpcyBoYW5kbGVkIG9ubHkgYnkgRG9t
MCBvciBEcml2ZXIgRG9tYWluLg0KPj4NCj4+IFRoZSBFTDMgU0NNSSBGVyBleHBlY3RlZCB0byBp
bXBsZW1lbnQgZm9sbG93aW5nIEJhc2UgcHJvdG9jb2wgbWVzc2FnZXM6DQo+PiAtIEJBU0VfRElT
Q09WRVJfQUdFTlQNCj4+IC0gQkFTRV9SRVNFVF9BR0VOVF9DT05GSUdVUkFUSU9OIChvcHRpb25h
bCkNCj4+IC0gQkFTRV9TRVRfREVWSUNFX1BFUk1JU1NJT05TIChvcHRpb25hbCkNCj4+DQo+PiBU
aGUgU0NJIFNDTUkgU01DIG11bHRpLWFnZW50IGRyaXZlciBpbXBsZW1lbnRzIGZvbGxvd2luZyBm
dW5jdGlvbmFsaXR5Og0KPj4gLSBJdCdzIGluaXRpYWxpemVkIGJhc2VkIG9uIHRoZSBIb3N0IERU
IFNDTUkgbm9kZSAob25seSBvbmUgU0NNSSBpbnRlcmZhY2UNCj4+IGlzIHN1cHBvcnRlZCkgd2hp
Y2ggZGVzY3JpYmVzIFhlbiBtYW5hZ2VtZW50IGFnZW50IFNDTUkgaW50ZXJmYWNlLg0KPj4NCj4+
IHNjbWlfc2htXzAgOiBzcmFtQDQ3ZmYwMDAwIHsNCj4+ICAgICAgY29tcGF0aWJsZSA9ICJhcm0s
c2NtaS1zaG1lbSI7DQo+PiAgICAgIHJlZyA9IDwweDAgMHg0N2ZmMDAwMCAweDAgMHgxMDAwPjsN
Cj4+IH07DQo+PiBmaXJtd2FyZSB7DQo+PiAgICAgIHNjbWk6IHNjbWkgew0KPj4gICAgICAgICAg
Y29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zbWMiOw0KPj4gICAgICAgICAgYXJtLCBzbWMgLSBpZCA9
IDwweDgyMDAwMDAyPjsgLy8gWGVuIG1hbmVnZW1lbnQgYWdlbnQgc21jLWlkDQo+IHNvbWUgZXh0
cmEgc3BhY2VzLCBpdCBtaWdodCBiZSBhIGNvcHkvcGFzdGUgZXJyb3INCisNCj4+ICAgICAgICAg
IFwjYWRkcmVzcy1jZWxscyA9IDwgMT47DQo+PiAgICAgICAgICBcI3NpemUtY2VsbHMgPSA8IDA+
Ow0KPj4gICAgICAgICAgXCNhY2Nlc3MtY29udHJvbGxlciAtIGNlbGxzID0gPCAxPjsNCj4+ICAg
ICAgICAgIHNobWVtID0gPCZzY21pX3NobV8wPjsgLy8gWGVuIG1hbmVnZW1lbnQgYWdlbnQgc2ht
ZW0NCj4+DQo+PiAgICAgICAgICBwcm90b2NvbEBYew0KPj4gICAgICAgICAgfTsNCj4+ICAgICAg
fTsNCj4+IH07DQo+Pg0KPj4gLSBJdCBvYnRhaW5zIFhlbiBzcGVjaWZpYyBTQ01JIEFnZW50J3Mg
Y29uZmlndXJhdGlvbiBmcm9tIHRoZSBIb3N0IERULA0KPj4gcHJvYmVzIEFnZW50cyBhbmQgYnVp
bGQgU0NNSSBBZ2VudHMgbGlzdDsgVGhlIEFnZW50cyBjb25maWd1cmF0aW9uIGlzIHRha2VuIGZy
b206DQo+Pg0KPj4gY2hvc2VuIHsNCj4+ICAgIHhlbixzY21pLXNlY29uZGFyeS1hZ2VudHMgPSA8
DQo+PiAgICAgICAgICAgICAgMSAweDgyMDAwMDAzICZzY21pX3NobV8xDQo+PiAgICAgICAgICAg
ICAgMiAweDgyMDAwMDA0ICZzY21pX3NobV8yDQo+PiAgICAgICAgICAgICAgMyAweDgyMDAwMDA1
ICZzY21pX3NobV8zDQo+PiAgICAgICAgICAgICAgNCAweDgyMDAwMDA2ICZzY21pX3NobV80PjsN
Cj4+IH0NCj4+DQo+PiAvew0KPj4gICAgICBzY21pX3NobV8xOiBzcmFtQDQ3ZmYxMDAwIHsNCj4+
ICAgICAgICAgICAgICBjb21wYXRpYmxlID0gImFybSxzY21pLXNobWVtIjsNCj4+ICAgICAgICAg
ICAgICByZWcgPSA8MHgwIDB4NDdmZjEwMDAgMHgwIDB4MTAwMD47DQo+PiAgICAgIH07DQo+PiAg
ICAgIHNjbWlfc2htXzI6IHNyYW1ANDdmZjIwMDAgew0KPj4gICAgICAgICAgICAgIGNvbXBhdGli
bGUgPSAiYXJtLHNjbWktc2htZW0iOw0KPj4gICAgICAgICAgICAgIHJlZyA9IDwweDAgMHg0N2Zm
MjAwMCAweDAgMHgxMDAwPjsNCj4+ICAgICAgfTsNCj4+ICAgICAgc2NtaV9zaG1fMzogc3JhbUA0
N2ZmMzAwMCB7DQo+PiAgICAgICAgICAgICAgY29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zaG1lbSI7
DQo+PiAgICAgICAgICAgICAgcmVnID0gPDB4MCAweDQ3ZmYzMDAwIDB4MCAweDEwMDA+Ow0KPj4g
ICAgICB9Ow0KPj4gfQ0KPj4gICAgd2hlcmUgZmlyc3QgaXRlbSBpcyAiYWdlbnRfaWQiLCBzZWNv
bmQgLSAiYXJtLHNtYy1pZCIsIGFuZCB0aGlyZCAtICJhcm0sc2NtaS1zaG1lbSIgZm9yDQo+PiAg
ICB0aGlzIGFnZW50X2lkLg0KPj4NCj4+ICAgIE5vdGUgdGhhdCBYZW4gaXMgdGhlIG9ubHkgb25l
IGVudHJ5IGluIHRoZSBzeXN0ZW0gd2hpY2ggbmVlZCB0byBrbm93DQo+PiAgICBhYm91dCBTQ01J
IG11bHRpLWFnZW50IHN1cHBvcnQuDQo+Pg0KPj4gLSBJdCBpbXBsZW1lbnRzIHRoZSBTQ0kgc3Vi
c3lzdGVtIGludGVyZmFjZSByZXF1aXJlZCBmb3IgY29uZmlndXJpbmcgYW5kDQo+PiBlbmFibGlu
ZyBTQ01JIGZ1bmN0aW9uYWxpdHkgZm9yIERvbTAvaHdkb20gYW5kIEd1ZXN0IGRvbWFpbnMuIFRv
IGVuYWJsZQ0KPj4gU0NNSSBmdW5jdGlvbmFsaXR5IGZvciBkb21haW4gaXQgaGFzIHRvIGJlIGNv
bmZpZ3VyZWQgd2l0aCB1bmlxdWUgc3VwcG9ydGVkDQo+PiBTQ01JIEFnZW50X2lkIGFuZCB1c2Ug
Y29ycmVzcG9uZGluZyBTQ01JIFNNQy9IVkMgc2hhcmVkIG1lbW9yeSB0cmFuc3BvcnQNCj4+IFtz
bWMtaWQsIHNobWVtXSBkZWZpbmVkIGZvciB0aGlzIFNDTUkgQWdlbnRfaWQuDQo+PiAtIE9uY2Ug
WGVuIGRvbWFpbiBpcyBjb25maWd1cmVkIGl0IGNhbiBjb21tdW5pY2F0ZSB3aXRoIEVMMyBTQ01J
IEZXOg0KPj4gICAgLS0gemVyby1jb3B5LCB0aGUgZ3Vlc3QgZG9tYWluIHB1dHMgU0NNSSBtZXNz
YWdlIGluIHNobWVtOw0KPj4gICAgLS0gdGhlIGd1ZXN0IHRyaWdnZXJzIFNNQy9IVkMgZXhjZXB0
aW9uIHdpdGggc21jLWlkIChkb29yYmVsbCk7DQo+PiAgICAtLSB0aGUgWGVuIGRyaXZlciBjYXRj
aGVzIGV4Y2VwdGlvbiwgZG8gY2hlY2tzIGFuZCBzeW5jaHJvbm91c2x5IGZvcndhcmRzDQo+PiAg
ICBpdCB0byBFTDMgRlcuDQo+PiAtIHRoZSBYZW4gZHJpdmVyIHNlbmRzIEJBU0VfUkVTRVRfQUdF
TlRfQ09ORklHVVJBVElPTiBtZXNzYWdlIHRvIFhlbg0KPj4gICAgbWFuYWdlbWVudCBhZ2VudCBj
aGFubmVsIG9uIGRvbWFpbiBkZXN0cm95IGV2ZW50LiBUaGlzIGFsbG93cyB0byByZXNldA0KPj4g
ICAgcmVzb3VyY2VzIHVzZWQgYnkgZG9tYWluIGFuZCBzbyBpbXBsZW1lbnQgdXNlLWNhc2UgbGlr
ZSBkb21haW4gcmVib290Lg0KPj4NCj4+IERvbTAgRW5hYmxlIFNDTUkgU01DOg0KPj4gICAtIHBh
c3MgZG9tMF9zY21pX2FnZW50X2lkPTxhZ2VudF9pZD4gaW4gWGVuIGNvbW1hbmQgbGluZS4gaWYg
bm90IHByb3ZpZGVkDQo+PiAgICAgU0NNSSB3aWxsIGJlIGRpc2FibGVkIGZvciBEb20wIGFuZCBh
bGwgU0NNSSBub2RlcyByZW1vdmVkIGZyb20gRG9tMCBEVC4NCj4+ICAgICBUaGUgZHJpdmVyIHVw
ZGF0ZXMgRG9tMCBEVCBTQ01JIG5vZGUgImFybSxzbWMtaWQiIHZhbHVlIGFuZCBmaXggdXAgc2ht
ZW0NCj4+ICAgICBub2RlIGFjY29yZGluZyB0byBhc3NpZ25lZCBhZ2VudF9pZC4NCj4+DQo+PiBH
dWVzdCBkb21haW5zIGVuYWJsZSBTQ01JIFNNQzoNCj4+ICAgLSB4bC5jZmc6IGFkZCBjb25maWd1
cmF0aW9uIG9wdGlvbiBhcyBiZWxvdw0KPj4NCj4+ICAgICBhcm1fc2NpID0gInR5cGU9c2NtaV9z
bWNfbXVsdGlhZ2VudCxhZ2VudF9pZD0yIg0KPj4NCj4+ICAgLSB4bC5jZmc6IGVuYWJsZSBhY2Nl
c3MgdG8gdGhlICJhcm0sc2NtaS1zaG1lbSIgd2hpY2ggc2hvdWxkIGNvcnJlc3BvbmQgYXNzaWdu
ZWQgYWdlbnRfaWQgZm9yDQo+PiAgICAgdGhlIGRvbWFpbiwgZm9yIGV4YW1wbGU6DQo+Pg0KPj4g
aW9tZW0gPSBbDQo+PiAgICAgICI0N2ZmMiwxQDIyMDAxIiwNCj4+IF0NCj4gTG9va2luZyBhdCB0
aGUgY29kZSBhbmQgdGhlIGNvbmZpZ3VyYXRpb24gb3B0aW9ucywgaXQgbG9va3MgbGlrZSBpdCBp
cw0KPiBwb3NzaWJsZSB0byBtYXAgYSBzY21pLXNobWVtIGNoYW5uZWwgYXQgYSBkaWZmZXJlbnQg
YWRkcmVzcyBmb3IgdGhlDQo+IGd1ZXN0LiBJdCBzZWVtcyBsaWtlIGl0IHdvdWxkIHdvcmsuIElz
IHRoYXQgY29ycmVjdD8NCj4NClllcyBpdCB3aWxsLiBpbiBvdXIgY2FzZSBhZGRyZXNzIDIyMDAx
MDAwIHNob3VsZCBiZSB0aGUgc2F2ZSBhcw0Kc3JhbUAyMjAwMTAwMCBpbiB0aGUgZG9tYWluIGRl
dmljZS10cmVlLg0KPj4gICAtIERUOiBhZGQgU0NNSSBub2RlcyB0byB0aGUgRHJpdmVyIGRvbWFp
biBwYXJ0aWFsIGRldmljZSB0cmVlIGFzIGluIHRoZQ0KPj4gICBiZWxvdyBleGFtcGxlLiBUaGUg
ImFybSxzbWMtaWQiIHNob3VsZCBjb3JyZXNwb25kIGFzc2lnbmVkIGFnZW50X2lkIGZvciB0aGUg
ZG9tYWluOg0KPj4NCj4+IHBhc3N0aHJvdWdoIHsNCj4+ICAgICBzY21pX3NobV8wOiBzcmFtQDIy
MDAxMDAwIHsNCj4+ICAgICAgICAgY29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zaG1lbSI7DQo+PiAg
ICAgICAgIHJlZyA9IDwweDAgMHgyMjAwMTAwMCAweDAgMHgxMDAwPjsNCj4+ICAgICB9Ow0KPj4N
Cj4+ICAgICBmaXJtd2FyZSB7DQo+PiAgICAgICAgICBjb21wYXRpYmxlID0gInNpbXBsZS1idXMi
Ow0KPj4gICAgICAgICAgICAgIHNjbWk6IHNjbWkgew0KPj4gICAgICAgICAgICAgICAgICBjb21w
YXRpYmxlID0gImFybSxzY21pLXNtYyI7DQo+PiAgICAgICAgICAgICAgICAgIGFybSxzbWMtaWQg
PSA8MHg4MjAwMDAwND47DQo+PiAgICAgICAgICAgICAgICAgIHNobWVtID0gPCZzY21pX3NobV8w
PjsNCj4+ICAgICAgICAgICAgICAgICAgLi4uDQo+PiAgICAgICAgICAgICAgfQ0KPj4gICAgICB9
DQo+PiB9DQo+Pg0KPj4gU0NNSSAiNC4yLjEuMSBEZXZpY2Ugc3BlY2lmaWMgYWNjZXNzIGNvbnRy
b2wiDQo+Pg0KPj4gVGhlIFhFTiBTQ0kgU0NNSSBTTUMgbXVsdGktYWdlbnQgZHJpdmVyIHBlcmZv
cm1zICJhY2Nlc3MtY29udHJvbGxlciIgcHJvdmlkZXIgZnVuY3Rpb24NCj4+IGluIGNhc2UgRUwz
IFNDTUkgRlcgaW1wbGVtZW50cyBTQ01JICI0LjIuMS4xIERldmljZSBzcGVjaWZpYyBhY2Nlc3Mg
Y29udHJvbCIgYW5kIHByb3ZpZGVzIHRoZQ0KPj4gQkFTRV9TRVRfREVWSUNFX1BFUk1JU1NJT05T
IGNvbW1hbmQgdG8gY29uZmlndXJlIHRoZSBkZXZpY2VzIHRoYXQgYW4gYWdlbnRzIGhhdmUgYWNj
ZXNzIHRvLg0KPj4gVGhlIERUIFNDTUkgbm9kZSBzaG91bGQgIiNhY2Nlc3MtY29udHJvbGxlci1j
ZWxscz08MT4iIHByb3BlcnR5IGFuZCBEVCBkZXZpY2VzIHNob3VsZCBiZSBib3VuZA0KPj4gdG8g
dGhlIFhlbiBTQ01JLg0KPj4NCj4+ICZpMmMxIHsNCj4+ICAgICAgYWNjZXNzLWNvbnRyb2xsZXJz
ID0gPCZzY21pIDA+Ow0KPj4gfTsNCj4+DQo+PiBUaGUgRG9tMCBhbmQgZG9tMGxlc3MgZG9tYWlu
cyBEVCBkZXZpY2VzIHdpbGwgYmUgcHJvY2Vzc2VkIGF1dG9tYXRpY2FsbHkgdGhyb3VnaA0KPj4g
c2NpX2Fzc2lnbl9kdF9kZXZpY2UoKSBjYWxsLCBidXQgdG8gYXNzaWduIFNDTUkgZGV2aWNlcyBm
cm9tIHRvb2xzdGFjayB0aGUgeGwuY2ZnOiJkdGRldiIgcHJvcGVydHkNCj4+IHNoZWxsIGJlIHVz
ZWQ6DQo+Pg0KPj4gZHRkZXYgPSBbDQo+PiAgICAgICIvc29jL2kyY0BlNjUwODAwMCIsDQo+PiBd
DQo+Pg0KPj4geGwuY2ZnOmR0ZGV2IHdpbGwgY29udGFpbiBhbGwgbm9kZXMgd2hpY2ggYXJlIHVu
ZGVyIFNDTUkgbWFuYWdlbWVudCAobm90IG9ubHkgdGhvc2Ugd2hpY2ggYXJlIGJlaGluZCBJT01N
VSkuDQo+Pg0KPj4gWzFdaHR0cHM6Ly93ZWIuZ2l0Lmtlcm5lbC5vcmcvcHViL3NjbS9saW51eC9r
ZXJuZWwvZ2l0L3RvcnZhbGRzL2xpbnV4LmdpdC90cmVlL0RvY3VtZW50YXRpb24vZGV2aWNldHJl
ZS9iaW5kaW5ncy9maXJtd2FyZS9hcm0sc2NtaS55YW1sDQo+PiBbMl1odHRwczovL3dlYi5naXQu
a2VybmVsLm9yZy9wdWIvc2NtL2xpbnV4L2tlcm5lbC9naXQvdG9ydmFsZHMvbGludXguZ2l0L3Ry
ZWUvRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL2FjY2Vzcy1jb250cm9sbGVycy9h
Y2Nlc3MtY29udHJvbGxlcnMueWFtbA0KPj4gU2lnbmVkLW9mZi1ieTogT2xla3NpaSBNb2lzaWVp
ZXY8b2xla3NpaV9tb2lzaWVpZXZAZXBhbS5jb20+DQo+PiBTaWduZWQtb2ZmLWJ5OiBHcnlnb3Jp
aSBTdHJhc2hrbzxncnlnb3JpaV9zdHJhc2hrb0BlcGFtLmNvbT4NCj4gVGhhbmtzIGZvciB0aGUg
bG9uZyBleHBsYW5hdGlvbiwgZ3JlYXQgd29yayEgSSBhbSByZWFsbHkgbG9va2luZyBmb3J3YXJk
DQo+IHRvIGhhdmUgdGhpcyBmZWF0dXJlIGluIHRoZSB0cmVlIHNvb24uDQo+DQo+DQo+PiAtLS0N
Cj4+DQo+PiBDaGFuZ2VzIGluIHY0Og0KPj4gLSB0b29sc3RhY2sgY29tbWVudHMgZnJvbSBBbnRo
b255IFBFUkFSRA0KPj4gLSBhZGRlZCBkb20wbGVzcyBzdXBwb3J0DQo+PiAtIGFkZGVkIGRvYyBm
b3IgInhlbixzY21pLXNlY29uZGFyeS1hZ2VudHMiDQo+Pg0KPj4gICBkb2NzL21hbi94bC5jZmcu
NS5wb2QuaW4gICAgICAgICAgICAgICAgICAgIHwgIDEzICsNCj4+ICAgZG9jcy9taXNjL2FybS9k
ZXZpY2UtdHJlZS9ib290aW5nLnR4dCAgICAgICB8ICA2MCArKw0KPj4gICBkb2NzL21pc2MveGVu
LWNvbW1hbmQtbGluZS5wYW5kb2MgICAgICAgICAgIHwgICA5ICsNCj4+ICAgdG9vbHMvbGlicy9s
aWdodC9saWJ4bF9hcm0uYyAgICAgICAgICAgICAgICB8ICAgNCArDQo+PiAgIHRvb2xzL2xpYnMv
bGlnaHQvbGlieGxfdHlwZXMuaWRsICAgICAgICAgICAgfCAgIDQgKy0NCj4+ICAgdG9vbHMveGwv
eGxfcGFyc2UuYyAgICAgICAgICAgICAgICAgICAgICAgICB8ICAxMiArDQo+PiAgIHhlbi9hcmNo
L2FybS9kb20wbGVzcy1idWlsZC5jICAgICAgICAgICAgICAgfCAgMTEgKw0KPj4gICB4ZW4vYXJj
aC9hcm0vZG9tYWluX2J1aWxkLmMgICAgICAgICAgICAgICAgIHwgICAzICstDQo+PiAgIHhlbi9h
cmNoL2FybS9maXJtd2FyZS9LY29uZmlnICAgICAgICAgICAgICAgfCAgMTEgKw0KPj4gICB4ZW4v
YXJjaC9hcm0vZmlybXdhcmUvTWFrZWZpbGUgICAgICAgICAgICAgIHwgICAxICsNCj4+ICAgeGVu
L2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktcHJvdG8uaCAgICAgICAgICB8IDE2NCArKysrDQo+PiAg
IHhlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNobWVtLmMgICAgICAgICAgfCAxNzMgKysrKw0K
Pj4gICB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1zaG1lbS5oICAgICAgICAgIHwgIDQ1ICsN
Cj4+ICAgeGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktc21jLW11bHRpYWdlbnQuYyB8IDg2MCAr
KysrKysrKysrKysrKysrKysrKw0KPj4gICB4ZW4vaW5jbHVkZS9wdWJsaWMvYXJjaC1hcm0uaCAg
ICAgICAgICAgICAgIHwgICAzICsNCj4+ICAgMTUgZmlsZXMgY2hhbmdlZCwgMTM3MSBpbnNlcnRp
b25zKCspLCAyIGRlbGV0aW9ucygtKQ0KPj4gICBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2FyY2gv
YXJtL2Zpcm13YXJlL3NjbWktcHJvdG8uaA0KPj4gICBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2Fy
Y2gvYXJtL2Zpcm13YXJlL3NjbWktc2htZW0uYw0KPj4gICBjcmVhdGUgbW9kZSAxMDA2NDQgeGVu
L2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktc2htZW0uaA0KPj4gICBjcmVhdGUgbW9kZSAxMDA2NDQg
eGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktc21jLW11bHRpYWdlbnQuYw0KPj4NCj4+IGRpZmYg
LS1naXQgYS9kb2NzL21hbi94bC5jZmcuNS5wb2QuaW4gYi9kb2NzL21hbi94bC5jZmcuNS5wb2Qu
aW4NCj4+IGluZGV4IDFjY2Y1MGI4ZWEuLjMwMmM0NmQ4YmMgMTAwNjQ0DQo+PiAtLS0gYS9kb2Nz
L21hbi94bC5jZmcuNS5wb2QuaW4NCj4+ICsrKyBiL2RvY3MvbWFuL3hsLmNmZy41LnBvZC5pbg0K
Pj4gQEAgLTMxMjIsOCArMzEyMiwyMSBAQCBzaW5nbGUgU0NNSSBPU1BNIGFnZW50IHN1cHBvcnQu
DQo+PiAgIFNob3VsZCBiZSB1c2VkIHRvZ2V0aGVyIHdpdGggQjxkb20wX3NjbWlfc21jX3Bhc3N0
aHJvdWdoPiBYZW4gY29tbWFuZCBsaW5lDQo+PiAgIG9wdGlvbi4NCj4+DQo+PiArPWl0ZW0gQjxz
Y21pX3NtY19tdWx0aWFnZW50Pg0KPj4gKw0KPj4gK0VuYWJsZXMgQVJNIFNDTUkgU01DIG11bHRp
LWFnZW50IHN1cHBvcnQgZm9yIHRoZSBndWVzdCBieSBlbmFibGluZyBTQ01JIG92ZXINCj4+ICtT
TUMgY2FsbHMgZm9yd2FyZGluZyBmcm9tIGRvbWFpbiB0byB0aGUgRUwzIGZpcm13YXJlIChsaWtl
IFRydXN0ZWQgRmlybXdhcmUtQSkNCj4+ICt3aXRoIGEgbXVsdGkgU0NNSSBPU1BNIGFnZW50IHN1
cHBvcnQuIFRoZSBTQ01JIEI8YWdlbnRfaWQ+IHNob3VsZCBiZQ0KPj4gK3NwZWNpZmllZCBmb3Ig
dGhlIGd1ZXN0Lg0KPj4gKw0KPj4gICA9YmFjaw0KPj4NCj4+ICs9aXRlbSBCPGFnZW50X2lkPU5V
TUJFUj4NCj4+ICsNCj4+ICtTcGVjaWZpZXMgYSBub24temVybyBBUk0gU0NJIGFnZW50IGlkIGZv
ciB0aGUgZ3Vlc3QuIFRoaXMgb3B0aW9uIGlzIG1hbmRhdG9yeQ0KPj4gK2lmIHRoZSBTQ01JIFNN
QyBzdXBwb3J0IGlzIGVuYWJsZWQgZm9yIHRoZSBndWVzdC4gVGhlIGFnZW50IGlkcyBvZiBkb21h
aW5zDQo+PiArZXhpc3Rpbmcgb24gYSBzaW5nbGUgaG9zdCBtdXN0IGJlIHVuaXF1ZSBhbmQgaW4g
dGhlIHJhbmdlIFsxLi4yNTVdLg0KPj4gKw0KPj4gICA9YmFjaw0KPj4NCj4+ICAgPWJhY2sNCj4+
IGRpZmYgLS1naXQgYS9kb2NzL21pc2MvYXJtL2RldmljZS10cmVlL2Jvb3RpbmcudHh0IGIvZG9j
cy9taXNjL2FybS9kZXZpY2UtdHJlZS9ib290aW5nLnR4dA0KPj4gaW5kZXggODk0M2MwNDE3My4u
Yzg5MjNhYjhiMiAxMDA2NDQNCj4+IC0tLSBhL2RvY3MvbWlzYy9hcm0vZGV2aWNlLXRyZWUvYm9v
dGluZy50eHQNCj4+ICsrKyBiL2RvY3MvbWlzYy9hcm0vZGV2aWNlLXRyZWUvYm9vdGluZy50eHQN
Cj4+IEBAIC0yOTYsNiArMjk2LDIwIEBAIHdpdGggdGhlIGZvbGxvd2luZyBwcm9wZXJ0aWVzOg0K
Pj4gICAgICAgU2hvdWxkIGJlIHVzZWQgdG9nZXRoZXIgd2l0aCBkb20wX3NjbWlfc21jX3Bhc3N0
aHJvdWdoIFhlbiBjb21tYW5kIGxpbmUNCj4+ICAgICAgIG9wdGlvbi4NCj4+DQo+PiArICAgIC0g
InNjbWlfc21jX211bHRpYWdlbnQiDQo+PiArDQo+PiArICAgIEVuYWJsZXMgQVJNIFNDTUkgU01D
IG11bHRpLWFnZW50IHN1cHBvcnQgZm9yIHRoZSBndWVzdCBieSBlbmFibGluZyBTQ01JIG92ZXIN
Cj4+ICsgICAgU01DIGNhbGxzIGZvcndhcmRpbmcgZnJvbSBkb21haW4gdG8gdGhlIEVMMyBmaXJt
d2FyZSAobGlrZSBBUk0NCj4+ICsgICAgVHJ1c3RlZCBGaXJtd2FyZS1BKSB3aXRoIGEgbXVsdGkg
U0NNSSBPU1BNIGFnZW50IHN1cHBvcnQuDQo+PiArICAgIFRoZSBTQ01JIGFnZW50X2lkIHNob3Vs
ZCBiZSBzcGVjaWZpZWQgZm9yIHRoZSBndWVzdCB3aXRoICJ4ZW4sc2NpX2FnZW50X2lkIg0KPj4g
KyAgICBwcm9wZXJ0eS4NCj4+ICsNCj4+ICstICJ4ZW4sc2NpX2FnZW50X2lkIg0KPj4gKw0KPj4g
KyAgICBTcGVjaWZpZXMgYSBub24temVybyBBUk0gU0NJIGFnZW50IGlkIGZvciB0aGUgZ3Vlc3Qu
IFRoaXMgb3B0aW9uIGlzDQo+PiArICAgIG1hbmRhdG9yeSBpZiB0aGUgU0NNSSBTTUMgInNjbWlf
c21jX211bHRpYWdlbnQiIHN1cHBvcnQgaXMgZW5hYmxlZCBmb3INCj4+ICsgICAgdGhlIGd1ZXN0
LiBUaGUgYWdlbnQgaWRzIG9mIGd1ZXN0IG11c3QgYmUgdW5pcXVlIGFuZCBpbiB0aGUgcmFuZ2Ug
WzEuLjI1NV0uDQo+PiArDQo+PiAgIFVuZGVyIHRoZSAieGVuLGRvbWFpbiIgY29tcGF0aWJsZSBu
b2RlLCBvbmUgb3IgbW9yZSBzdWItbm9kZXMgYXJlIHByZXNlbnQNCj4+ICAgZm9yIHRoZSBEb21V
IGtlcm5lbCBhbmQgcmFtZGlzay4NCj4+DQo+PiBAQCAtNzY0LDMgKzc3OCw0OSBAQCBUaGUgYXV0
b21hdGljYWxseSBhbGxvY2F0ZWQgc3RhdGljIHNoYXJlZCBtZW1vcnkgd2lsbCBnZXQgbWFwcGVk
IGF0DQo+PiAgIDB4ODAwMDAwMDAgaW4gRG9tVTEgZ3Vlc3QgcGh5c2ljYWwgYWRkcmVzcyBzcGFj
ZSwgYW5kIGF0IDB4OTAwMDAwMDAgaW4gRG9tVTINCj4+ICAgZ3Vlc3QgcGh5c2ljYWwgYWRkcmVz
cyBzcGFjZS4gRG9tVTEgaXMgZXhwbGljaXRseSBkZWZpbmVkIGFzIHRoZSBvd25lciBkb21haW4s
DQo+PiAgIGFuZCBEb21VMiBpcyB0aGUgYm9ycm93ZXIgZG9tYWluLg0KPj4gKw0KPj4gK1NDTUkg
U01DIG11bHRpLWFnZW50IHN1cHBvcnQNCj4+ICs9PT09PT09PT09PT09PT09PT09PT09PT09PT09
DQo+PiArDQo+PiArRm9yIGVuYWJsaW5nIHRoZSBBUk0gU0NNSSBTTUMgbXVsdGktYWdlbnQgc3Vw
cG9ydCAoZW5hYmxlZCBieSBDT05GSUdfU0NNSV9TTUNfTUEpDQo+PiArdGhlIFhlbiBzcGVjaWZp
YyBTQ01JIEFnZW50J3MgY29uZmlndXJhdGlvbiBzaGVsbCBiZSBwcm92aWRlZCBpbiB0aGUgSG9z
dCBEVA0KPj4gK2FjY29yZGluZyB0byB0aGUgU0NNSSBjb21wbGlhbnQgRUwzIEZpcm13YXJlIHNw
ZWNpZmljYXRpb24gd2l0aA0KPj4gK0FSTSBTTUMvSFZDIHRyYW5zcG9ydCB1c2luZyBwcm9wZXJ0
eSAieGVuLHNjbWktc2Vjb25kYXJ5LWFnZW50cyIgdW5kZXINCj4+ICt0aGUgdG9wLWxldmVsICJj
aG9zZW4iIG5vZGU6DQo+PiArDQo+PiArLSB4ZW4sc2NtaS1zZWNvbmRhcnktYWdlbnRzDQo+PiAr
DQo+PiArICAgIERlZmluZXMgYSBzZXQgb2YgU0NNSSBhZ2VudHMgY29uZmlndXJhdGlvbiBzdXBw
b3J0ZWQgYnkgU0NNSSBFTDMgRlcgYW5kDQo+PiArICAgIGF2YWlsYWJsZSBmb3IgWGVuLiBFYWNo
IEFnZW50IGRlZmluZWQgYXMgdHJpcGxlIGNvbnNpc3Rpbmcgb2Y6DQo+PiArICAgIFNDTUkgYWdl
bnRfaWQsDQo+PiArICAgIFNNQy9IVkMgZnVuY3Rpb25faWQgYXNzaWduZWQgZm9yIHRoZSBhZ2Vu
dCB0cmFuc3BvcnQgKCJhcm0sc21jLWlkIiksDQo+PiArICAgIHBoYW5kbGUgdG8gU0NNSSBTSE0g
YXNzaWduZWQgZm9yIHRoZSBhZ2VudCB0cmFuc3BvcnQgKCJhcm0sc2NtaS1zaG1lbSIpLg0KPj4g
Kw0KPj4gK0FzIGFuIGV4YW1wbGU6DQo+PiArDQo+PiArY2hvc2VuIHsNCj4+ICsgICAgeGVuLHNj
bWktc2Vjb25kYXJ5LWFnZW50cyA9IDwNCj4+ICsgICAgICAgIDEgMHg4MjAwMDAwMyAmc2NtaV9z
aG1fMQ0KPj4gKyAgICAgICAgMiAweDgyMDAwMDA0ICZzY21pX3NobV8yDQo+PiArICAgICAgICAz
IDB4ODIwMDAwMDUgJnNjbWlfc2htXzMNCj4+ICsgICAgICAgIDQgMHg4MjAwMDAwNiAmc2NtaV9z
aG1fND47DQo+PiArfQ0KPiBOSVQ6IGl0IHNob3VsZCBiZSB9Ow0KKw0KPiBMb29raW5nIGF0IHNj
bWlfcHJvYmUsIGNvbGxlY3RfYWdlbnRzLCBhbmQgdGhlIGZvbGxvd2luZyBTQ01JDQo+IFNDTUlf
QkFTRV9ESVNDT1ZFUl9BR0VOVCByZXF1ZXN0LCBJIHdvbmRlcjogZG8gd2UgYWN0dWFsbHkgbmVl
ZCB0aGlzDQo+IGluZm9ybWF0aW9uPw0KPg0KPiBJdCBsb29rcyBsaWtlIHdlIGNhbiBkaXNjb3Zl
ciB0aGUgYWdlbmRfaWRzIGZvciBldmVyeSBjaGFubmVsLCBJIGd1ZXNzDQo+IHdoYXQgd2UgbmVl
ZCB0byBrbm93IGlzIHRoZSBzaG1lbSBsb2NhdGlvbiBmb3IgZXZlcnkgY2hhbm5lbD8gQnV0IHRo
ZQ0KPiBmdWxsIGxpc3Qgb2Ygc2htZW0gY2hhbm5lbCBpcyBhdmFpbGFibGUgYmVsb3cgdGhhbmtz
IHRvIHRoZSBzY21pLXNobWVtDQo+IG5vZGVzLg0KPg0KPiBTbywgd2UgaGF2ZSB0aGUgbGlzdCBv
ZiBzY21pLXNobWVtIGFueXdheSwgYW5kIHdlIGNhbiBwcm9iZSB0aGUNCj4gYWdlbnRfaWQuIFRo
ZSBvbmx5IHBhcmFtZXRlciBsZWZ0IGlzIHRoZSBzbWNfaWQvZnVuY19pZC4NCj4NCj4gT3IgbWF5
YmUgc21jX2lkL2Z1bmNfaWQgY2FuIGJlIGNhbGN1bGF0ZWQgZnJvbSBhZ2VudF9pZD8NCj4NCj4g
SSBhbSBhc2tpbmcgbW9zdGx5IGJlY2F1c2UgaWYgYSB1c2VyIGlzIHN1cHBvc2VkIHRvIGFkZCB0
aGlzDQo+IHhlbixzY21pLXNlY29uZGFyeS1hZ2VudHMgcHJvcGVydHksIHdoZXJlIGFyZSB0aGV5
IHN1cHBvc2VkIHRvIGZpbmQgdGhlDQo+IHNtY19pZC9mdW5jX2lkIGluZm9ybWF0aW9uPw0KPg0K
PiBJdCBpcyBpbXBvcnRhbnQgdGhhdCB3ZSB3cml0ZSBkb3duIGluIHRoaXMgZG9jdW1lbnQgaG93
IHRoZSB1c2VyIGlzDQo+IGV4cGVjdGVkIHRvIGZpbmQgb3V0IHdoYXQgMSBpcyAweDgyMDAwMDAz
IHdoaWNoIGlzIHNjbWlfc2htXzEuDQoNClRoYXQncyBhIHZlcnkgZ29vZCBxdWVzdGlvbiEgVGhl
IGlzc3VlIGhlcmUgaXMgdGhhdCB0aGVyZSBhcmUgbm8NCg0KZXhwbGljaXQgcmVxdWlyZW1lbnRz
IGRlZmluaW5nIHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBhZ2VudF9pZCBhbmQNCmZ1bmNfaWQu
DQoNCg0KRm9yIGV4YW1wbGUsIGluIEFSTS1URiwgZGlmZmVyZW50IGltcGxlbWVudGF0aW9ucyBj
YW4gdXNlIGRpZmZlcmVudA0KZnVuY19pZHMuDQoNClRvIHByb3ZpZGUgYmV0dGVyIGZsZXhpYmls
aXR5LCB3ZSBkZWNpZGVkIHRvIHNlcGFyYXRlIGFnZW50X2lkIGZyb20gZnVuY19pZC4NCg0KDQpD
dXJyZW50bHksIHRoZSBTQ01JX0JBU0VfRElTQ09WRVJfQUdFTlQgY2FsbHMgZnJvbSB0aGUgcHJv
YmUgYXJlIGludGVuZGVkIHRvDQoNCnZlcmlmeSB0aGF0IGFsbCByZWdpc3RlcmVkIGFnZW50cyBh
cmUgcHJlc2VudCBhbmQgdGhhdCB0aGUgY29uZmlndXJhdGlvbg0KaXMgY29ycmVjdC4NCg0KSG93
ZXZlciwgSSB1bmRlcnN0YW5kIHRoYXQgdGhpcyBhZGRpdGlvbmFsIHZhbGlkYXRpb24gY291bGQg
YmUgb3B0aW9uYWwNCnRvIHNhdmUgdHJhZmZpYy4NCg0KDQpUbyBhZGRyZXNzIHRoaXMsIEnigJlt
IGNvbnNpZGVyaW5nIGFkZGluZyBhIGNvbmZpZ3VyYXRpb24gb3B0aW9uLCBzdWNoIGFzDQoNCkNP
TkZJR19TQ01JX0FHRU5UX1ZBTElEQVRJT04sIHdoaWNoIGNhbiBiZSBkaXNhYmxlZCB0byByZWR1
Y2UgYm9vdCB0aW1lDQppZiB0aGlzDQoNCnZhbGlkYXRpb24gaXMgbm90IG5lY2Vzc2FyeSBmb3Ig
Y2VydGFpbiB1c2UgY2FzZXMuDQoNCg0KTGFzdGx5LCBJ4oCZbGwgYmUgdXBkYXRpbmcgdGhlIGRv
Y3VtZW50IHRvIGluY2x1ZGUgY2xlYXJlciBpbmZvcm1hdGlvbg0KYWJvdXQgdGhlDQoNCnJlbGF0
aW9uc2hpcCBiZXR3ZWVuIGZ1bmNfaWQgYW5kIGFnZW50X2lkIGluIHRoZSB1cGNvbWluZyB2NS4N
Cg0KDQoNCj4+ICsvew0KPj4gKyAgICAgICAgc2NtaV9zaG1fMTogc3JhbUA0N2ZmMTAwMCB7DQo+
PiArICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0KPj4gKyAg
ICAgICAgICAgICAgICByZWcgPSA8MHgwIDB4NDdmZjEwMDAgMHgwIDB4MTAwMD47DQo+PiArICAg
ICAgICB9Ow0KPj4gKyAgICAgICAgc2NtaV9zaG1fMjogc3JhbUA0N2ZmMjAwMCB7DQo+PiArICAg
ICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0KPj4gKyAgICAgICAg
ICAgICAgICByZWcgPSA8MHgwIDB4NDdmZjIwMDAgMHgwIDB4MTAwMD47DQo+PiArICAgICAgICB9
Ow0KPj4gKyAgICAgICAgc2NtaV9zaG1fMzogc3JhbUA0N2ZmMzAwMCB7DQo+PiArICAgICAgICAg
ICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0KPj4gKyAgICAgICAgICAgICAg
ICByZWcgPSA8MHgwIDB4NDdmZjMwMDAgMHgwIDB4MTAwMD47DQo+PiArICAgICAgICB9Ow0KPj4g
KyAgICAgICAgc2NtaV9zaG1fMzogc3JhbUA0N2ZmNDAwMCB7DQo+PiArICAgICAgICAgICAgICAg
IGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0KPj4gKyAgICAgICAgICAgICAgICByZWcg
PSA8MHgwIDB4NDdmZjQwMDAgMHgwIDB4MTAwMD47DQo+PiArICAgICAgICB9Ow0KPiBBcmUgdGhl
c2Ugc2NtaV9zaG1fMSAtIHNjbWlfc2htXzMgdW5kZXIgdGhlIHRvcCBsZXZlbCBkZXZpY2UgdHJl
ZSBub2RlPw0KPiBPciBhcmUgdW5kZXIgL2Zpcm13YXJlPyBPciBhcmUgdGhleSB1bmRlciAvY2hv
c2VuPw0KPg0KPiBJIHRha2UgdGhleSBhcmUgdW5kZXIgdGhlIHRvcCBsZXZlbCBub2RlIHRvZ2V0
aGVyIHdpdGggc2NtaV9zaG1fMD8NCj4NCj4gQ2FuIHlvdSBwbGVhc2UgYWxzbyBjbGFyaWZ5IGlu
IHRoZSBkb2N1bWVudCBhcyB3ZWxsPw0KPg0KPg0KYWxsIHRoZXNlIG5vZGVzIGFyZSBvbiB0aGUg
dG9wIGxldmVsIG9mIHRoZSBkZXZpY2UtdHJlZS4gQnV0IHRoZXJlIGlzIG5vDQpzcGVjaWZpYyBw
bGFjZSBmb3IgdGhlbS4NCg0KVGhleSBjb3VsZCBiZSBzdWJub2RlcyB0byBzb21lIG1lbW9yeS1y
ZWdpb24gZm9yIGV4YW1wbGUuIEkgd2lsbCBjbGFyaWZ5DQp0aGlzLg0KDQo+PiArfQ0KPj4gZGlm
ZiAtLWdpdCBhL2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLnBhbmRvYyBiL2RvY3MvbWlzYy94
ZW4tY29tbWFuZC1saW5lLnBhbmRvYw0KPj4gaW5kZXggOGU1MGY2YjdjNy4uYmMzYzY0ZDZlYyAx
MDA2NDQNCj4+IC0tLSBhL2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLnBhbmRvYw0KPj4gKysr
IGIvZG9jcy9taXNjL3hlbi1jb21tYW5kLWxpbmUucGFuZG9jDQo+PiBAQCAtMTA5MSw2ICsxMDkx
LDE1IEBAIHdoaWNoIHNlcnZlcyBhcyBEcml2ZXIgZG9tYWluLiBUaGUgU0NNSSB3aWxsIGJlIGRp
c2FibGVkIGZvciBEb20wL2h3ZG9tIGFuZA0KPj4gICBTQ01JIG5vZGVzIHJlbW92ZWQgZnJvbSBE
b20wL2h3ZG9tIGRldmljZSB0cmVlLg0KPj4gICAoZm9yIGV4YW1wbGUsIHRoaW4gRG9tMCB3aXRo
IERyaXZlciBkb21haW4gdXNlLWNhc2UpLg0KPj4NCj4+ICsjIyMgZG9tMF9zY21pX2FnZW50X2lk
IChBUk0pDQo+PiArPiBgPSA8aW50ZWdlcj5gDQo+PiArDQo+PiArVGhlIG9wdGlvbiBpcyBhdmFp
bGFibGUgd2hlbiBgQ09ORklHX1NDTUlfU01DX01BYCBpcyBjb21waWxlZCBpbiwgYW5kIGFsbG93
cyB0bw0KPj4gK2VuYWJsZSBTQ01JIGZ1bmN0aW9uYWxpdHkgZm9yIERvbTAgYnkgc3BlY2lmeWlu
ZyBhIG5vbi16ZXJvIEFSTSBTQ01JIGFnZW50IGlkLg0KPj4gK1RoZSBTQ01JIHdpbGwgYmUgZGlz
YWJsZWQgZm9yIERvbTAgaWYgdGhpcyBvcHRpb24gaXMgbm90IHNwZWNpZmllZA0KPj4gKyhmb3Ig
ZXhhbXBsZSwgdGhpbiBEb20wIG9yIGRvbTBsZXNzIHVzZS1jYXNlcykuDQo+PiArVGhlIGFnZW50
IGlkcyBvZiBkb21haW5zIGV4aXN0aW5nIG9uIGEgc2luZ2xlIGhvc3QgbXVzdCBiZSB1bmlxdWUu
DQo+PiArDQo+PiAgICMjIyBkdHVhcnQgKEFSTSkNCj4+ICAgPiBgPSBwYXRoIFs6b3B0aW9uc11g
DQo+Pg0KPj4gZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnMvbGlnaHQvbGlieGxfYXJtLmMgYi90b29s
cy9saWJzL2xpZ2h0L2xpYnhsX2FybS5jDQo+PiBpbmRleCAyOGJhOWViNzg3Li43NzEyZjUzY2Q0
IDEwMDY0NA0KPj4gLS0tIGEvdG9vbHMvbGlicy9saWdodC9saWJ4bF9hcm0uYw0KPj4gKysrIGIv
dG9vbHMvbGlicy9saWdodC9saWJ4bF9hcm0uYw0KPj4gQEAgLTIyOSw2ICsyMjksMTAgQEAgaW50
IGxpYnhsX19hcmNoX2RvbWFpbl9wcmVwYXJlX2NvbmZpZyhsaWJ4bF9fZ2MgKmdjLA0KPj4gICAg
ICAgY2FzZSBMSUJYTF9BUk1fU0NJX1RZUEVfU0NNSV9TTUM6DQo+PiAgICAgICAgICAgY29uZmln
LT5hcmNoLmFybV9zY2lfdHlwZSA9IFhFTl9ET01DVExfQ09ORklHX0FSTV9TQ0lfU0NNSV9TTUM7
DQo+PiAgICAgICAgICAgYnJlYWs7DQo+PiArICAgIGNhc2UgTElCWExfQVJNX1NDSV9UWVBFX1ND
TUlfU01DX01VTFRJQUdFTlQ6DQo+PiArICAgICAgICBjb25maWctPmFyY2guYXJtX3NjaV90eXBl
ID0gWEVOX0RPTUNUTF9DT05GSUdfQVJNX1NDSV9TQ01JX1NNQ19NQTsNCj4+ICsgICAgICAgIGNv
bmZpZy0+YXJjaC5hcm1fc2NpX2FnZW50X2lkID0gZF9jb25maWctPmJfaW5mby5hcmNoX2FybS5h
cm1fc2NpLmFnZW50X2lkOw0KPj4gKyAgICAgICAgYnJlYWs7DQo+PiAgICAgICBkZWZhdWx0Og0K
Pj4gICAgICAgICAgIExPRyhFUlJPUiwgIlVua25vd24gQVJNX1NDSSB0eXBlICVkIiwNCj4+ICAg
ICAgICAgICAgICAgZF9jb25maWctPmJfaW5mby5hcmNoX2FybS5hcm1fc2NpLnR5cGUpOw0KPj4g
ZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnMvbGlnaHQvbGlieGxfdHlwZXMuaWRsIGIvdG9vbHMvbGli
cy9saWdodC9saWJ4bF90eXBlcy5pZGwNCj4+IGluZGV4IGFhMjE5MGFiNWIuLjExZTMxY2U3ODYg
MTAwNjQ0DQo+PiAtLS0gYS90b29scy9saWJzL2xpZ2h0L2xpYnhsX3R5cGVzLmlkbA0KPj4gKysr
IGIvdG9vbHMvbGlicy9saWdodC9saWJ4bF90eXBlcy5pZGwNCj4+IEBAIC01NTMsMTEgKzU1Mywx
MyBAQCBsaWJ4bF9zdmVfdHlwZSA9IEVudW1lcmF0aW9uKCJzdmVfdHlwZSIsIFsNCj4+DQo+PiAg
IGxpYnhsX2FybV9zY2lfdHlwZSA9IEVudW1lcmF0aW9uKCJhcm1fc2NpX3R5cGUiLCBbDQo+PiAg
ICAgICAoMCwgIm5vbmUiKSwNCj4+IC0gICAgKDEsICJzY21pX3NtYyIpDQo+PiArICAgICgxLCAi
c2NtaV9zbWMiKSwNCj4+ICsgICAgKDIsICJzY21pX3NtY19tdWx0aWFnZW50IikNCj4+ICAgICAg
IF0sIGluaXRfdmFsID0gIkxJQlhMX0FSTV9TQ0lfVFlQRV9OT05FIikNCj4+DQo+PiAgIGxpYnhs
X2FybV9zY2kgPSBTdHJ1Y3QoImFybV9zY2kiLCBbDQo+PiAgICAgICAoInR5cGUiLCBsaWJ4bF9h
cm1fc2NpX3R5cGUpLA0KPj4gKyAgICAoImFnZW50X2lkIiwgdWludDgpDQo+PiAgICAgICBdKQ0K
Pj4NCj4+ICAgbGlieGxfcmRtX3Jlc2VydmUgPSBTdHJ1Y3QoInJkbV9yZXNlcnZlIiwgWw0KPj4g
ZGlmZiAtLWdpdCBhL3Rvb2xzL3hsL3hsX3BhcnNlLmMgYi90b29scy94bC94bF9wYXJzZS5jDQo+
PiBpbmRleCBiZDIyYmU5ZDMzLi44MWFhMzc5N2UzIDEwMDY0NA0KPj4gLS0tIGEvdG9vbHMveGwv
eGxfcGFyc2UuYw0KPj4gKysrIGIvdG9vbHMveGwveGxfcGFyc2UuYw0KPj4gQEAgLTEzMDYsNiAr
MTMwNiwxOCBAQCBzdGF0aWMgaW50IHBhcnNlX2FybV9zY2lfY29uZmlnKFhMVV9Db25maWcgKmNm
ZywgbGlieGxfYXJtX3NjaSAqYXJtX3NjaSwNCj4+ICAgICAgICAgICAgICAgfQ0KPj4gICAgICAg
ICAgIH0NCj4+DQo+PiArICAgICAgICBpZiAoTUFUQ0hfT1BUSU9OKCJhZ2VudF9pZCIsIHB0ciwg
b3BhcmcpKSB7DQo+PiArICAgICAgICAgICAgdW5zaWduZWQgbG9uZyB2YWwgPSBwYXJzZV91bG9u
ZyhvcGFyZyk7DQo+PiArDQo+PiArICAgICAgICAgICAgaWYgKCF2YWwgfHwgdmFsID4gMjU1KSB7
DQo+PiArICAgICAgICAgICAgICAgIGZwcmludGYoc3RkZXJyLCAiQW4gaW52YWxpZCBBUk1fU0NJ
IGFnZW50X2lkIHNwZWNpZmllZCAoJWx1KS4gVmFsaWQgcmFuZ2UgWzEuLjI1NV1cbiIsDQo+PiAr
ICAgICAgICAgICAgICAgICAgICAgICAgdmFsKTsNCj4+ICsgICAgICAgICAgICAgICAgcmV0ID0g
RVJST1JfSU5WQUw7DQo+PiArICAgICAgICAgICAgICAgIGdvdG8gcGFyc2VfZXJyb3I7DQo+PiAr
ICAgICAgICAgICAgfQ0KPj4gKyAgICAgICAgICAgIGFybV9zY2ktPmFnZW50X2lkID0gdmFsOw0K
Pj4gKyAgICAgICAgfQ0KPj4gKw0KPj4gICAgICAgICAgIHB0ciA9IHN0cnRvayhOVUxMLCAiLCIp
Ow0KPj4gICAgICAgfQ0KPj4NCj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vZG9tMGxlc3Mt
YnVpbGQuYyBiL3hlbi9hcmNoL2FybS9kb20wbGVzcy1idWlsZC5jDQo+PiBpbmRleCAwYTAwZjAz
YTI1Li40M2QyMWViODg5IDEwMDY0NA0KPj4gLS0tIGEveGVuL2FyY2gvYXJtL2RvbTBsZXNzLWJ1
aWxkLmMNCj4+ICsrKyBiL3hlbi9hcmNoL2FybS9kb20wbGVzcy1idWlsZC5jDQo+PiBAQCAtODM1
LDYgKzgzNSwxNyBAQCBpbnQgX19pbml0IGRvbXVfZHRfc2NpX3BhcnNlKHN0cnVjdCBkdF9kZXZp
Y2Vfbm9kZSAqbm9kZSwNCj4+ICAgICAgICAgICBkX2NmZy0+YXJjaC5hcm1fc2NpX3R5cGUgPSBY
RU5fRE9NQ1RMX0NPTkZJR19BUk1fU0NJX05PTkU7DQo+PiAgICAgICBlbHNlIGlmICggIXN0cmNt
cChzY2lfdHlwZSwgInNjbWlfc21jIikgKQ0KPj4gICAgICAgICAgIGRfY2ZnLT5hcmNoLmFybV9z
Y2lfdHlwZSA9IFhFTl9ET01DVExfQ09ORklHX0FSTV9TQ0lfU0NNSV9TTUM7DQo+PiArICAgIGVs
c2UgaWYgKCAhc3RyY21wKHNjaV90eXBlLCAic2NtaV9zbWNfbXVsdGlhZ2VudCIpICkNCj4+ICsg
ICAgew0KPj4gKyAgICAgICAgdWludDMyX3QgYWdlbnRfaWQgPSAwOw0KPj4gKw0KPj4gKyAgICAg
ICAgaWYgKCAhZHRfcHJvcGVydHlfcmVhZF91MzIobm9kZSwgInhlbixzY2lfYWdlbnRfaWQiLCAm
YWdlbnRfaWQpIHx8DQo+PiArICAgICAgICAgICAgICFhZ2VudF9pZCApDQo+IHNob3VsZG4ndCB3
ZSBjaGVjayB0aGF0IGFnZW50X2lkIDw9IDI1NSA/DQoNCkkgc2VlIG5vIGxpbWl0YXRpb24gYWJv
dXQgbWF4IGFnZW50X2lkIGluIERFTjAwNTZFIGRvY3VtZW50LCBpdCdzIHVpbnQzMl90Lg0KDQo+
PiArICAgICAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+PiArDQo+PiArICAgICAgICBkX2NmZy0+
YXJjaC5hcm1fc2NpX3R5cGUgPSBYRU5fRE9NQ1RMX0NPTkZJR19BUk1fU0NJX1NDTUlfU01DX01B
Ow0KPj4gKyAgICAgICAgZF9jZmctPmFyY2guYXJtX3NjaV9hZ2VudF9pZCA9IGFnZW50X2lkOw0K
Pj4gKyAgICB9DQo+PiAgICAgICBlbHNlDQo+PiAgICAgICB7DQo+PiAgICAgICAgICAgcHJpbnRr
KFhFTkxPR19FUlIgInhlbixzY2lfdHlwZSBpbiBub3QgdmFsaWQgKCVzKSBmb3IgZG9tYWluICVz
XG4iLA0KPj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9kb21haW5fYnVpbGQuYyBiL3hlbi9h
cmNoL2FybS9kb21haW5fYnVpbGQuYw0KPj4gaW5kZXggMzZkMjhiNTJhNC4uMGM5Mjc0YTJiMyAx
MDA2NDQNCj4+IC0tLSBhL3hlbi9hcmNoL2FybS9kb21haW5fYnVpbGQuYw0KPj4gKysrIGIveGVu
L2FyY2gvYXJtL2RvbWFpbl9idWlsZC5jDQo+PiBAQCAtNjE2LDcgKzYxNiw4IEBAIHN0YXRpYyBp
bnQgX19pbml0IHdyaXRlX3Byb3BlcnRpZXMoc3RydWN0IGRvbWFpbiAqZCwgc3RydWN0IGtlcm5l
bF9pbmZvICpraW5mbywNCj4+ICAgICAgICAgICAgICAgICAgICBkdF9wcm9wZXJ0eV9uYW1lX2lz
X2VxdWFsKHByb3AsICJsaW51eCx1ZWZpLW1tYXAtc3RhcnQiKSB8fA0KPj4gICAgICAgICAgICAg
ICAgICAgIGR0X3Byb3BlcnR5X25hbWVfaXNfZXF1YWwocHJvcCwgImxpbnV4LHVlZmktbW1hcC1z
aXplIikgfHwNCj4+ICAgICAgICAgICAgICAgICAgICBkdF9wcm9wZXJ0eV9uYW1lX2lzX2VxdWFs
KHByb3AsICJsaW51eCx1ZWZpLW1tYXAtZGVzYy1zaXplIikgfHwNCj4+IC0gICAgICAgICAgICAg
ICAgIGR0X3Byb3BlcnR5X25hbWVfaXNfZXF1YWwocHJvcCwgImxpbnV4LHVlZmktbW1hcC1kZXNj
LXZlciIpKQ0KPj4gKyAgICAgICAgICAgICAgICAgZHRfcHJvcGVydHlfbmFtZV9pc19lcXVhbChw
cm9wLCAibGludXgsdWVmaS1tbWFwLWRlc2MtdmVyIikgfHwNCj4+ICsgICAgICAgICAgICAgICAg
IGR0X3Byb3BlcnR5X25hbWVfaXNfZXF1YWwocHJvcCwgInhlbixzY21pLXNlY29uZGFyeS1hZ2Vu
dHMiKSApDQo+PiAgICAgICAgICAgICAgICAgICBjb250aW51ZTsNCj4+DQo+PiAgICAgICAgICAg
ICAgIGlmICggZHRfcHJvcGVydHlfbmFtZV9pc19lcXVhbChwcm9wLCAieGVuLGRvbTAtYm9vdGFy
Z3MiKSApIGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vZmlybXdhcmUvS2NvbmZpZw0KPj4gYi94
ZW4vYXJjaC9hcm0vZmlybXdhcmUvS2NvbmZpZyBpbmRleCA1YzVmMDg4MGM0Li42YjA1MWM4YWRh
IDEwMDY0NA0KPj4gLS0tIGEveGVuL2FyY2gvYXJtL2Zpcm13YXJlL0tjb25maWcgKysrDQo+PiBi
L3hlbi9hcmNoL2FybS9maXJtd2FyZS9LY29uZmlnIEBAIC0yOSw2ICsyOSwxNyBAQCBjb25maWcg
U0NNSV9TTUMNCj4+IGRyaXZlciBkb21haW4uIFVzZSB3aXRoIEVMMyBmaXJtd2FyZSB3aGljaCBz
dXBwb3J0cyBvbmx5IHNpbmdsZSBTQ01JDQo+PiBPU1BNIGFnZW50LiArY29uZmlnIFNDTUlfU01D
X01BICsgYm9vbCAiRW5hYmxlIEFSTSBTQ01JIFNNQyBtdWx0aS1hZ2VudCBkcml2ZXIiDQo+PiAr
ICAgIHNlbGVjdCBBUk1fU0NJDQo+PiArICAgIGhlbHANCj4+ICsgICAgICBFbmFibGVzIFNDTUkg
U01DL0hWQyBtdWx0aS1hZ2VudCBpbiBYRU4gdG8gcGFzcyBTQ01JIHJlcXVlc3RzIGZyb20gRG9t
YWlucw0KPj4gKyAgICAgIHRvIEVMMyBmaXJtd2FyZSAoVEYtQSkgd2hpY2ggc3VwcG9ydHMgbXVs
dGktYWdlbnQgZmVhdHVyZS4NCj4+ICsgICAgICBUaGlzIGZlYXR1cmUgYWxsb3dzIHRvIGVuYWJs
ZSBTQ01JIHBlciBEb21haW4gdXNpbmcgdW5pcXVlIFNDTUkgYWdlbnRfaWQsDQo+PiArICAgICAg
c28gRG9tYWluIGlzIGlkZW50aWZpZWQgYnkgRUwzIGZpcm13YXJlIGFzIGFuIFNDTUkgQWdlbnQg
YW5kIGNhbiBhY2Nlc3MNCj4+ICsgICAgICBhbGxvd2VkIHBsYXRmb3JtIHJlc291cmNlcyB0aHJv
dWdoIGRlZGljYXRlZCBTTUMvSFZDIFNoYXJlZCBtZW1vcnkgYmFzZWQNCj4+ICsgICAgICB0cmFu
c3BvcnQuDQo+PiArDQo+PiAgIGVuZGNob2ljZQ0KPj4NCj4+ICAgZW5kbWVudQ0KPj4gZGlmZiAt
LWdpdCBhL3hlbi9hcmNoL2FybS9maXJtd2FyZS9NYWtlZmlsZSBiL3hlbi9hcmNoL2FybS9maXJt
d2FyZS9NYWtlZmlsZQ0KPj4gaW5kZXggNzFiZGVmYzI0YS4uMzc5MjdlNjkwZSAxMDA2NDQNCj4+
IC0tLSBhL3hlbi9hcmNoL2FybS9maXJtd2FyZS9NYWtlZmlsZQ0KPj4gKysrIGIveGVuL2FyY2gv
YXJtL2Zpcm13YXJlL01ha2VmaWxlDQo+PiBAQCAtMSwyICsxLDMgQEANCj4+ICAgb2JqLSQoQ09O
RklHX0FSTV9TQ0kpICs9IHNjaS5vDQo+PiAgIG9iai0kKENPTkZJR19TQ01JX1NNQykgKz0gc2Nt
aS1zbWMubw0KPj4gK29iai0kKENPTkZJR19TQ01JX1NNQ19NQSkgKz0gc2NtaS1zaG1lbS5vIHNj
bWktc21jLW11bHRpYWdlbnQubw0KPj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9maXJtd2Fy
ZS9zY21pLXByb3RvLmggYi94ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1wcm90by5oDQo+PiBu
ZXcgZmlsZSBtb2RlIDEwMDY0NA0KPj4gaW5kZXggMDAwMDAwMDAwMC4uM2Y0YjljNWQ2Yg0KPj4g
LS0tIC9kZXYvbnVsbA0KPj4gKysrIGIveGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktcHJvdG8u
aA0KPj4gQEAgLTAsMCArMSwxNjQgQEANCj4+ICsvKiBTUERYLUxpY2Vuc2UtSWRlbnRpZmllcjog
R1BMLTIuMC1vbmx5ICovDQo+PiArLyoNCj4+ICsgKiBBcm0gU3lzdGVtIENvbnRyb2wgYW5kIE1h
bmFnZW1lbnQgSW50ZXJmYWNlIGRlZmluaXRpb25zDQo+PiArICogVmVyc2lvbiAzLjAgKERFTjAw
NTZDKQ0KPj4gKyAqDQo+PiArICogQ29weXJpZ2h0IChjKSAyMDI0IEVQQU0gU3lzdGVtcw0KPj4g
KyAqLw0KPj4gKw0KPj4gKyNpZm5kZWYgWEVOX0FSQ0hfQVJNX1NDSV9TQ01JX1BST1RPX0hfDQo+
PiArI2RlZmluZSBYRU5fQVJDSF9BUk1fU0NJX1NDTUlfUFJPVE9fSF8NCj4gTklUOiBBUk1fRklS
TVdBUkVfU0NNSV9QUk9UT19IDQorDQo+PiArI2luY2x1ZGUgPHhlbi9zdGRpbnQuaD4NCj4+ICsN
Cj4+ICsjZGVmaW5lIFNDTUlfU0hPUlRfTkFNRV9NQVhfU0laRSAxNg0KPj4gKw0KPj4gKy8qIFND
TUkgc3RhdHVzIGNvZGVzLiBTZWUgc2VjdGlvbiA0LjEuNCAqLw0KPj4gKyNkZWZpbmUgU0NNSV9T
VUNDRVNTICAgICAgICAgICAgICAwDQo+PiArI2RlZmluZSBTQ01JX05PVF9TVVBQT1JURUQgICAg
ICAoLTEpDQo+PiArI2RlZmluZSBTQ01JX0lOVkFMSURfUEFSQU1FVEVSUyAoLTIpDQo+PiArI2Rl
ZmluZSBTQ01JX0RFTklFRCAgICAgICAgICAgICAoLTMpDQo+PiArI2RlZmluZSBTQ01JX05PVF9G
T1VORCAgICAgICAgICAoLTQpDQo+PiArI2RlZmluZSBTQ01JX09VVF9PRl9SQU5HRSAgICAgICAo
LTUpDQo+PiArI2RlZmluZSBTQ01JX0JVU1kgICAgICAgICAgICAgICAoLTYpDQo+PiArI2RlZmlu
ZSBTQ01JX0NPTU1TX0VSUk9SICAgICAgICAoLTcpDQo+PiArI2RlZmluZSBTQ01JX0dFTkVSSUNf
RVJST1IgICAgICAoLTgpDQo+PiArI2RlZmluZSBTQ01JX0hBUkRXQVJFX0VSUk9SICAgICAoLTkp
DQo+PiArI2RlZmluZSBTQ01JX1BST1RPQ09MX0VSUk9SICAgICAoLTEwKQ0KPj4gKw0KPj4gKy8q
IFByb3RvY29sIElEcyAqLw0KPj4gKyNkZWZpbmUgU0NNSV9CQVNFX1BST1RPQ09MIDB4MTANCj4+
ICsNCj4+ICsvKiBCYXNlIHByb3RvY29sIG1lc3NhZ2UgSURzICovDQo+PiArI2RlZmluZSBTQ01J
X0JBU0VfUFJPVE9DT0xfVkVSU0lPTiAgICAgICAgICAgIDB4MA0KPj4gKyNkZWZpbmUgU0NNSV9C
QVNFX1BST1RPQ09MX0FUVElCVVRFUyAgICAgICAgICAweDENCj4+ICsjZGVmaW5lIFNDTUlfQkFT
RV9QUk9UT0NPTF9NRVNTQUdFX0FUVFJJQlVURVMgMHgyDQo+PiArI2RlZmluZSBTQ01JX0JBU0Vf
RElTQ09WRVJfQUdFTlQgICAgICAgICAgICAgIDB4Nw0KPj4gKyNkZWZpbmUgU0NNSV9CQVNFX1NF
VF9ERVZJQ0VfUEVSTUlTU0lPTlMgICAgICAweDkNCj4+ICsjZGVmaW5lIFNDTUlfQkFTRV9SRVNF
VF9BR0VOVF9DT05GSUdVUkFUSU9OICAgMHhCDQo+PiArDQo+PiArdHlwZWRlZiBzdHJ1Y3Qgc2Nt
aV9tc2dfaGVhZGVyIHsNCj4+ICsgICAgdWludDhfdCBpZDsNCj4+ICsgICAgdWludDhfdCB0eXBl
Ow0KPj4gKyAgICB1aW50OF90IHByb3RvY29sOw0KPj4gKyAgICB1aW50MzJfdCBzdGF0dXM7DQo+
PiArfSBzY21pX21zZ19oZWFkZXJfdDsNCj4+ICsNCj4+ICsvKiBUYWJsZSAyIE1lc3NhZ2UgaGVh
ZGVyIGZvcm1hdCAqLw0KPj4gKyNkZWZpbmUgU0NNSV9IRFJfSUQgICAgR0VOTUFTSyg3LCAwKQ0K
Pj4gKyNkZWZpbmUgU0NNSV9IRFJfVFlQRSAgR0VOTUFTSyg5LCA4KQ0KPj4gKyNkZWZpbmUgU0NN
SV9IRFJfUFJPVE8gR0VOTUFTSygxNywgMTApDQo+PiArDQo+PiArI2RlZmluZSBTQ01JX0ZJRUxE
X0dFVChfbWFzaywgX3JlZykgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwNCj4+ICsgICAgKCh0eXBlb2YoX21hc2spKSgoKF9yZWcpICYgKF9tYXNrKSkgPj4gKGZm
czY0KF9tYXNrKSAtIDEpKSkNCj4+ICsjZGVmaW5lIFNDTUlfRklFTERfUFJFUChfbWFzaywgX3Zh
bCkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXA0KPj4gKyAgICAo
KCh0eXBlb2YoX21hc2spKShfdmFsKSA8PCAoZmZzNjQoX21hc2spIC0gMSkpICYgKF9tYXNrKSkN
Cj4+ICsNCj4+ICtzdGF0aWMgaW5saW5lIHVpbnQzMl90IHBhY2tfc2NtaV9oZWFkZXIoc2NtaV9t
c2dfaGVhZGVyX3QgKmhkcikNCj4+ICt7DQo+PiArICAgIHJldHVybiBTQ01JX0ZJRUxEX1BSRVAo
U0NNSV9IRFJfSUQsIGhkci0+aWQpIHwNCj4+ICsgICAgICAgICAgIFNDTUlfRklFTERfUFJFUChT
Q01JX0hEUl9UWVBFLCBoZHItPnR5cGUpIHwNCj4+ICsgICAgICAgICAgIFNDTUlfRklFTERfUFJF
UChTQ01JX0hEUl9QUk9UTywgaGRyLT5wcm90b2NvbCk7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRp
YyBpbmxpbmUgdm9pZCB1bnBhY2tfc2NtaV9oZWFkZXIodWludDMyX3QgbXNnX2hkciwgc2NtaV9t
c2dfaGVhZGVyX3QgKmhkcikNCj4+ICt7DQo+PiArICAgIGhkci0+aWQgPSBTQ01JX0ZJRUxEX0dF
VChTQ01JX0hEUl9JRCwgbXNnX2hkcik7DQo+PiArICAgIGhkci0+dHlwZSA9IFNDTUlfRklFTERf
R0VUKFNDTUlfSERSX1RZUEUsIG1zZ19oZHIpOw0KPj4gKyAgICBoZHItPnByb3RvY29sID0gU0NN
SV9GSUVMRF9HRVQoU0NNSV9IRFJfUFJPVE8sIG1zZ19oZHIpOw0KPj4gK30NCj4+ICsNCj4+ICtz
dGF0aWMgaW5saW5lIGludCBzY21pX3RvX3hlbl9lcnJubyhpbnQgc2NtaV9zdGF0dXMpDQo+PiAr
ew0KPj4gKyAgICBpZiAoIHNjbWlfc3RhdHVzID09IFNDTUlfU1VDQ0VTUyApDQo+PiArICAgICAg
ICByZXR1cm4gMDsNCj4+ICsNCj4+ICsgICAgc3dpdGNoICggc2NtaV9zdGF0dXMgKQ0KPj4gKyAg
ICB7DQo+PiArICAgIGNhc2UgU0NNSV9OT1RfU1VQUE9SVEVEOg0KPj4gKyAgICAgICAgcmV0dXJu
IC1FT1BOT1RTVVBQOw0KPj4gKyAgICBjYXNlIFNDTUlfSU5WQUxJRF9QQVJBTUVURVJTOg0KPj4g
KyAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+PiArICAgIGNhc2UgU0NNSV9ERU5JRUQ6DQo+PiAr
ICAgICAgICByZXR1cm4gLUVBQ0NFUzsNCj4+ICsgICAgY2FzZSBTQ01JX05PVF9GT1VORDoNCj4+
ICsgICAgICAgIHJldHVybiAtRU5PRU5UOw0KPj4gKyAgICBjYXNlIFNDTUlfT1VUX09GX1JBTkdF
Og0KPj4gKyAgICAgICAgcmV0dXJuIC1FUkFOR0U7DQo+PiArICAgIGNhc2UgU0NNSV9CVVNZOg0K
Pj4gKyAgICAgICAgcmV0dXJuIC1FQlVTWTsNCj4+ICsgICAgY2FzZSBTQ01JX0NPTU1TX0VSUk9S
Og0KPj4gKyAgICAgICAgcmV0dXJuIC1FTk9UQ09OTjsNCj4+ICsgICAgY2FzZSBTQ01JX0dFTkVS
SUNfRVJST1I6DQo+PiArICAgICAgICByZXR1cm4gLUVJTzsNCj4+ICsgICAgY2FzZSBTQ01JX0hB
UkRXQVJFX0VSUk9SOg0KPj4gKyAgICAgICAgcmV0dXJuIC1FTlhJTzsNCj4+ICsgICAgY2FzZSBT
Q01JX1BST1RPQ09MX0VSUk9SOg0KPj4gKyAgICAgICAgcmV0dXJuIC1FQkFETVNHOw0KPj4gKyAg
ICBkZWZhdWx0Og0KPj4gKyAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+PiArICAgIH0NCj4+ICt9
DQo+PiArDQo+PiArLyogUFJPVE9DT0xfVkVSU0lPTiAqLw0KPj4gKyNkZWZpbmUgU0NNSV9WRVJT
SU9OX01JTk9SIEdFTk1BU0soMTUsIDApDQo+PiArI2RlZmluZSBTQ01JX1ZFUlNJT05fTUFKT1Ig
R0VOTUFTSygzMSwgMTYpDQo+PiArDQo+PiArc3RydWN0IHNjbWlfbXNnX3Byb3RfdmVyc2lvbl9w
MmEgew0KPj4gKyAgICB1aW50MzJfdCB2ZXJzaW9uOw0KPj4gK30gX19wYWNrZWQ7DQo+PiArDQo+
PiArLyogQkFTRSBQUk9UT0NPTF9BVFRSSUJVVEVTICovDQo+PiArI2RlZmluZSBTQ01JX0JBU0Vf
QVRUUl9OVU1fUFJPVE8gR0VOTUFTSyg3LCAwKQ0KPj4gKyNkZWZpbmUgU0NNSV9CQVNFX0FUVFJf
TlVNX0FHRU5UIEdFTk1BU0soMTUsIDgpDQo+PiArDQo+PiArc3RydWN0IHNjbWlfbXNnX2Jhc2Vf
YXR0cmlidXRlc19wMmEgew0KPj4gKyAgICB1aW50MzJfdCBhdHRyaWJ1dGVzOw0KPj4gK30gX19w
YWNrZWQ7DQo+PiArDQo+PiArLyoNCj4+ICsgKiBCQVNFX0RJU0NPVkVSX0FHRU5UDQo+PiArICov
DQo+PiArI2RlZmluZSBTQ01JX0JBU0VfQUdFTlRfSURfT1dOIDB4RkZGRkZGRkYNCj4+ICsNCj4+
ICtzdHJ1Y3Qgc2NtaV9tc2dfYmFzZV9kaXNjb3Zlcl9hZ2VudF9hMnAgew0KPj4gKyAgICB1aW50
MzJfdCBhZ2VudF9pZDsNCj4+ICt9IF9fcGFja2VkOw0KPj4gKw0KPj4gK3N0cnVjdCBzY21pX21z
Z19iYXNlX2Rpc2NvdmVyX2FnZW50X3AyYSB7DQo+PiArICAgIHVpbnQzMl90IGFnZW50X2lkOw0K
Pj4gKyAgICBjaGFyIG5hbWVbU0NNSV9TSE9SVF9OQU1FX01BWF9TSVpFXTsNCj4+ICt9IF9fcGFj
a2VkOw0KPj4gKw0KPj4gKy8qDQo+PiArICogQkFTRV9TRVRfREVWSUNFX1BFUk1JU1NJT05TDQo+
PiArICovDQo+PiArI2RlZmluZSBTQ01JX0JBU0VfREVWSUNFX0FDQ0VTU19BTExPVyAgICAgICAg
ICAgQklUKDAsIFVMKQ0KPj4gKw0KPj4gK3N0cnVjdCBzY21pX21zZ19iYXNlX3NldF9kZXZpY2Vf
cGVybWlzc2lvbnNfYTJwIHsNCj4+ICsgICAgdWludDMyX3QgYWdlbnRfaWQ7DQo+PiArICAgIHVp
bnQzMl90IGRldmljZV9pZDsNCj4+ICsgICAgdWludDMyX3QgZmxhZ3M7DQo+PiArfSBfX3BhY2tl
ZDsNCj4+ICsNCj4+ICsvKg0KPj4gKyAqIEJBU0VfUkVTRVRfQUdFTlRfQ09ORklHVVJBVElPTg0K
Pj4gKyAqLw0KPj4gKyNkZWZpbmUgU0NNSV9CQVNFX0FHRU5UX1BFUk1JU1NJT05TX1JFU0VUICAg
ICAgIEJJVCgwLCBVTCkNCj4+ICsNCj4+ICtzdHJ1Y3Qgc2NtaV9tc2dfYmFzZV9yZXNldF9hZ2Vu
dF9jZmdfYTJwIHsNCj4+ICsgICAgdWludDMyX3QgYWdlbnRfaWQ7DQo+PiArICAgIHVpbnQzMl90
IGZsYWdzOw0KPj4gK30gX19wYWNrZWQ7DQo+PiArDQo+PiArI2VuZGlmIC8qIFhFTl9BUkNIX0FS
TV9TQ0lfU0NNSV9QUk9UT19IXyAqLw0KPj4gKw0KPj4gKy8qDQo+PiArICogTG9jYWwgdmFyaWFi
bGVzOg0KPj4gKyAqIG1vZGU6IEMNCj4+ICsgKiBjLWZpbGUtc3R5bGU6ICJCU0QiDQo+PiArICog
Yy1iYXNpYy1vZmZzZXQ6IDQNCj4+ICsgKiB0YWItd2lkdGg6IDQNCj4+ICsgKiBpbmRlbnQtdGFi
cy1tb2RlOiBuaWwNCj4+ICsgKiBFbmQ6DQo+PiArICovDQo+PiBkaWZmIC0tZ2l0IGEveGVuL2Fy
Y2gvYXJtL2Zpcm13YXJlL3NjbWktc2htZW0uYyBiL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY21p
LXNobWVtLmMNCj4+IG5ldyBmaWxlIG1vZGUgMTAwNjQ0DQo+PiBpbmRleCAwMDAwMDAwMDAwLi5k
ZDYxM2VlMGI1DQo+PiAtLS0gL2Rldi9udWxsDQo+PiArKysgYi94ZW4vYXJjaC9hcm0vZmlybXdh
cmUvc2NtaS1zaG1lbS5jDQo+PiBAQCAtMCwwICsxLDE3MyBAQA0KPj4gKy8qIFNQRFgtTGljZW5z
ZS1JZGVudGlmaWVyOiBHUEwtMi4wLW9ubHkgKi8NCj4+ICsvKg0KPj4gKyAqIFNDSSBTQ01JIG11
bHRpLWFnZW50IGRyaXZlciwgdXNpbmcgU01DL0hWQyBzaG1lbSBhcyB0cmFuc3BvcnQuDQo+PiAr
ICoNCj4+ICsgKiBPbGVrc2lpIE1vaXNpZWlldjxvbGVrc2lpX21vaXNpZWlldkBlcGFtLmNvbT4N
Cj4+ICsgKiBDb3B5cmlnaHQgKGMpIDIwMjUgRVBBTSBTeXN0ZW1zDQo+PiArICovDQo+PiArLyog
U1BEWC1MaWNlbnNlLUlkZW50aWZpZXI6IEdQTC0yLjAtb25seSAqLw0KPj4gKw0KPj4gKyNpbmNs
dWRlIDxhc20vaW8uaD4NCj4+ICsjaW5jbHVkZSA8eGVuL2Vyci5oPg0KPj4gKw0KPj4gKyNpbmNs
dWRlICJzY21pLXByb3RvLmgiDQo+PiArI2luY2x1ZGUgInNjbWktc2htZW0uaCINCj4gVGhpcyBj
b2RlIGlzIHdyaXR0ZW4gbW9yZSBnZW5lcmljYWxseSB0aGFuIHRoZSBkZXNjcmlwdGlvbiBpbXBs
aWVzLiBJZg0KPiB3ZSBvbmx5IHdhbnQgdG8gbWFrZSBTTUMgY2FsbHMgdG8gVEYtQSBvbiBFTDMg
YW5kIGV4Y2hhbmdlIGRhdGEgd2l0aCBpdA0KPiBvdmVyIHNoYXJlZCBtZW1vcnksIHRoZW4gSSB0
aGluazoNCj4gLSB3ZSBkb24ndCBuZWVkIHRoZSBfX2lvbWVtIHRhZywgYXMgdGhlcmUgaXMgbm8g
TU1JTw0KPiAtIHdlIG9ubHkgbmVlZCBhIERNQiwgbm90IGEgRFNCIChyZWFkbCBhbmQgd3JpdGVs
IGltcGx5IERTQiwgdXNlIG9ubHkNCj4gICAgcmVhZGxfcmVsYXhlZCBhbmQgd3JpdGVsX3JlbGF4
ZWQpDQo+DQo+IE9uIHRoZSBvdGhlciBoYW5kLCBpZiB3ZSBhbHNvIHdhbnQgdG8gaGFuZGxlIHRo
ZSBjYXNlIHdoZXJlIHRoZSBTQ01JDQo+IHNlcnZlciBjb3VsZCBiZSBvbiBhIHNlcGFyYXRlIGNv
LXByb2Nlc3NvciwgdGhlbiB3aGF0IHRoaXMgY29kZSBpcyBkb2luZw0KPiBpcyBub3Qgc3VmZmlj
aWVudCBiZWNhdXNlIHdlIGFsc28gbmVlZCBhIGRjYWNoZSBmbHVzaCwgaW4gYWRkaXRpb24gdG8N
Cj4gdGhlIERTQi4NCj4NCj4gQmVydHJhbmQsIGNhbiB5b3UgZG91YmxlLWNoZWNrPw0KPg0KPg0K
Pj4gKy8qDQo+PiArICogQ29weSBkYXRhIGZyb20gSU8gbWVtb3J5IHNwYWNlIHRvICJyZWFsIiBt
ZW1vcnkgc3BhY2UuDQo+PiArICovDQo+PiArc3RhdGljIHZvaWQgX19tZW1jcHlfZnJvbWlvKHZv
aWQgKnRvLCBjb25zdCB2b2xhdGlsZSB2b2lkIF9faW9tZW0gKmZyb20sDQo+PiArICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHNpemVfdCBjb3VudCkNCj4+ICt7DQo+PiArICAgIHdoaWxlICgg
Y291bnQgJiYgIUlTX0FMSUdORUQoKHVuc2lnbmVkIGxvbmcpZnJvbSwgNCkgKQ0KPj4gKyAgICB7
DQo+PiArICAgICAgICAqKHU4ICopdG8gPSByZWFkYl9yZWxheGVkKGZyb20pOw0KPj4gKyAgICAg
ICAgZnJvbSsrOw0KPj4gKyAgICAgICAgdG8rKzsNCj4+ICsgICAgICAgIGNvdW50LS07DQo+PiAr
ICAgIH0NCj4+ICsNCj4+ICsgICAgd2hpbGUgKCBjb3VudCA+PSA0ICkNCj4+ICsgICAgew0KPj4g
KyAgICAgICAgKih1MzIgKil0byA9IHJlYWRsX3JlbGF4ZWQoZnJvbSk7DQo+PiArICAgICAgICBm
cm9tICs9IDQ7DQo+PiArICAgICAgICB0byArPSA0Ow0KPj4gKyAgICAgICAgY291bnQgLT0gNDsN
Cj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICB3aGlsZSAoIGNvdW50ICkNCj4+ICsgICAgew0KPj4g
KyAgICAgICAgKih1OCAqKXRvID0gcmVhZGJfcmVsYXhlZChmcm9tKTsNCj4+ICsgICAgICAgIGZy
b20rKzsNCj4+ICsgICAgICAgIHRvKys7DQo+PiArICAgICAgICBjb3VudC0tOw0KPj4gKyAgICB9
DQo+PiArfQ0KPj4gKw0KPj4gKy8qDQo+PiArICogQ29weSBkYXRhIGZyb20gInJlYWwiIG1lbW9y
eSBzcGFjZSB0byBJTyBtZW1vcnkgc3BhY2UuDQo+PiArICovDQo+PiArc3RhdGljIHZvaWQgX19t
ZW1jcHlfdG9pbyh2b2xhdGlsZSB2b2lkIF9faW9tZW0gKnRvLCBjb25zdCB2b2lkICpmcm9tLA0K
Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgc2l6ZV90IGNvdW50KQ0KPj4gK3sNCj4+ICsg
ICAgd2hpbGUgKCBjb3VudCAmJiAhSVNfQUxJR05FRCgodW5zaWduZWQgbG9uZyl0bywgNCkgKQ0K
Pj4gKyAgICB7DQo+PiArICAgICAgICB3cml0ZWJfcmVsYXhlZCgqKHU4ICopZnJvbSwgdG8pOw0K
Pj4gKyAgICAgICAgZnJvbSsrOw0KPj4gKyAgICAgICAgdG8rKzsNCj4+ICsgICAgICAgIGNvdW50
LS07DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgd2hpbGUgKCBjb3VudCA+PSA0ICkNCj4+ICsg
ICAgew0KPj4gKyAgICAgICAgd3JpdGVsX3JlbGF4ZWQoKih1MzIgKilmcm9tLCB0byk7DQo+PiAr
ICAgICAgICBmcm9tICs9IDQ7DQo+PiArICAgICAgICB0byArPSA0Ow0KPj4gKyAgICAgICAgY291
bnQgLT0gNDsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICB3aGlsZSAoIGNvdW50ICkNCj4+ICsg
ICAgew0KPj4gKyAgICAgICAgd3JpdGViX3JlbGF4ZWQoKih1OCAqKWZyb20sIHRvKTsNCj4+ICsg
ICAgICAgIGZyb20rKzsNCj4+ICsgICAgICAgIHRvKys7DQo+PiArICAgICAgICBjb3VudC0tOw0K
Pj4gKyAgICB9DQo+PiArfQ0KPiBJIGRvbid0IHVuZGVyc3RhbmQgd2h5IHdlIG5lZWQgX19tZW1j
cHlfZnJvbWlvIGFuZCBfX21lbWNweV90b2lvOiBjYW4ndA0KPiB3ZSB1c2UgYSBzaW1wbGUgbWVt
Y3B5Pw0KDQpUaGlzIGFwcHJvYWNoIHdhcyB1c2VkIGJlY2F1c2Ugd2UncmUgdHJ5aW5nIHRvIGFj
Y2VzcyBzaGFyZWQgbWVtb3J5DQpiZXR3ZWVuIHR3byBpbmRlcGVuZGVudCBzeXN0ZW1zOg0KDQpB
cm0tVEYgYW5kIFhlbiBpbiBvdXIgY2FzZSB3aGljaCBwbGFjZXMgc29tZSBjaHVua3Mgb2YgZGF0
YSB0byB0aGUgc2FtZQ0KbWVtb3J5LiBBbmQsIGFjY29yZGluZyB0byB0aGUgWzBdDQoNCmBgYA0K
DQpTb21lIGRldmljZXMgKHN1Y2ggYXMgZnJhbWVidWZmZXJzKSB3b3VsZCBsaWtlIHRvIHVzZSBs
YXJnZXIgdHJhbnNmZXJzIHRoYW4NCjggYnl0ZXMgYXQgYSB0aW1lLiBGb3IgdGhlc2UgZGV2aWNl
cywgdGhlIG1lbWNweV90b2lvKCksDQptZW1jcHlfZnJvbWlvKCkgYW5kIG1lbXNldF9pbygpIGZ1
bmN0aW9ucyBhcmUNCnByb3ZpZGVkLiBEbyBub3QgdXNlIG1lbXNldCBvciBtZW1jcHkgb24gSU8g
YWRkcmVzc2VzOyB0aGV5IGFyZSBub3QNCmd1YXJhbnRlZWQgdG8gY29weSBkYXRhIGluIG9yZGVy
Lg0KDQpgYGANCg0KQWxzbywgdGhlIHNhbWUgYXBwcm9hY2ggd2FzIHVzZWQgYnkgQXJtIHRlYW0g
d2hlbiBpbnRyb2R1Y2luZyBzY21pDQpkcml2ZXIgdG8gdGhlIExpbnV4IGtlcm5lbCBbMV0NCg0K
DQpbMF06IGh0dHBzOi8vd3d3Lmtlcm5lbC5vcmcvZG9jL0RvY3VtZW50YXRpb24vZHJpdmVyLWFw
aS9kZXZpY2UtaW8ucnN0DQoNClsxXTpodHRwczovL2dpdC5pbGlhbmEuZnlpL2xpbnV4L3BhdGNo
Lz9pZD1kNTE0MWYzN2M0MmUwYjgzMzg2M2YxNTdhYzRjZWUyMDNiMmJhM2QyDQoNCj4+ICtzdGF0
aWMgaW5saW5lIGludA0KPj4gK3NobWVtX2NoYW5uZWxfaXNfZnJlZShjb25zdCB2b2xhdGlsZSBz
dHJ1Y3Qgc2NtaV9zaGFyZWRfbWVtIF9faW9tZW0gKnNobWVtKQ0KPj4gK3sNCj4+ICsgICAgcmV0
dXJuIChyZWFkbCgmc2htZW0tPmNoYW5uZWxfc3RhdHVzKSAmDQo+PiArICAgICAgICAgICAgU0NN
SV9TSE1FTV9DSEFOX1NUQVRfQ0hBTk5FTF9GUkVFKSA/IDAgOiAtRUJVU1k7DQo+PiArfQ0KPj4g
Kw0KPj4gK2ludCBzaG1lbV9wdXRfbWVzc2FnZSh2b2xhdGlsZSBzdHJ1Y3Qgc2NtaV9zaGFyZWRf
bWVtIF9faW9tZW0gKnNobWVtLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICBzY21pX21zZ19o
ZWFkZXJfdCAqaGRyLCB2b2lkICpkYXRhLCBpbnQgbGVuKQ0KPj4gK3sNCj4+ICsgICAgaW50IHJl
dDsNCj4+ICsNCj4+ICsgICAgaWYgKCAobGVuICsgc2l6ZW9mKHNobWVtLT5tc2dfaGVhZGVyKSkg
PiBTQ01JX1NITUVNX01BUFBFRF9TSVpFICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgcHJpbnRr
KFhFTkxPR19FUlIgInNjbWk6IFdyb25nIHNpemUgb2Ygc21jIG1lc3NhZ2UuIERhdGEgaXMgaW52
YWxpZFxuIik7DQo+PiArICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ICsgICAgfQ0KPj4gKw0K
Pj4gKyAgICByZXQgPSBzaG1lbV9jaGFubmVsX2lzX2ZyZWUoc2htZW0pOw0KPj4gKyAgICBpZiAo
IHJldCApDQo+PiArICAgICAgICByZXR1cm4gcmV0Ow0KPj4gKw0KPj4gKyAgICB3cml0ZWxfcmVs
YXhlZCgweDAsICZzaG1lbS0+Y2hhbm5lbF9zdGF0dXMpOw0KPj4gKyAgICAvKiBXcml0aW5nIDB4
MCByaWdodCBub3csIGJ1dCAic2htZW0iX0ZMQUdfSU5UUl9FTkFCTEVEIGNhbiBiZSBzZXQgKi8N
Cj4+ICsgICAgd3JpdGVsX3JlbGF4ZWQoMHgwLCAmc2htZW0tPmZsYWdzKTsNCj4+ICsgICAgd3Jp
dGVsX3JlbGF4ZWQoc2l6ZW9mKHNobWVtLT5tc2dfaGVhZGVyKSArIGxlbiwgJnNobWVtLT5sZW5n
dGgpOw0KPj4gKyAgICB3cml0ZWwocGFja19zY21pX2hlYWRlcihoZHIpLCAmc2htZW0tPm1zZ19o
ZWFkZXIpOw0KPj4gKw0KPj4gKyAgICBpZiAoIGxlbiA+IDAgJiYgZGF0YSApDQo+PiArICAgICAg
ICBfX21lbWNweV90b2lvKHNobWVtLT5tc2dfcGF5bG9hZCwgZGF0YSwgbGVuKTsNCj4+ICsNCj4+
ICsgICAgcmV0dXJuIDA7DQo+PiArfQ0KPj4gKw0KPj4gK2ludCBzaG1lbV9nZXRfcmVzcG9uc2Uo
Y29uc3Qgdm9sYXRpbGUgc3RydWN0IHNjbWlfc2hhcmVkX21lbSBfX2lvbWVtICpzaG1lbSwNCj4+
ICsgICAgICAgICAgICAgICAgICAgICAgIHNjbWlfbXNnX2hlYWRlcl90ICpoZHIsIHZvaWQgKmRh
dGEsIGludCBsZW4pDQo+PiArew0KPj4gKyAgICBpbnQgcmVjdl9sZW47DQo+PiArICAgIGludCBy
ZXQ7DQo+PiArICAgIGludCBwYWQgPSBzaXplb2YoaGRyLT5zdGF0dXMpOw0KPj4gKw0KPj4gKyAg
ICBpZiAoIGxlbiA+PSBTQ01JX1NITUVNX01BUFBFRF9TSVpFIC0gc2l6ZW9mKHNobWVtKSApDQo+
PiArICAgIHsNCj4+ICsgICAgICAgIHByaW50ayhYRU5MT0dfRVJSDQo+PiArICAgICAgICAgICAg
ICAgInNjbWk6IFdyb25nIHNpemUgb2YgaW5wdXQgc21jIG1lc3NhZ2UuIERhdGEgbWF5IGJlIGlu
dmFsaWRcbiIpOw0KPj4gKyAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+PiArICAgIH0NCj4+ICsN
Cj4+ICsgICAgcmV0ID0gc2htZW1fY2hhbm5lbF9pc19mcmVlKHNobWVtKTsNCj4+ICsgICAgaWYg
KCByZXQgKQ0KPj4gKyAgICAgICAgcmV0dXJuIHJldDsNCj4+ICsNCj4+ICsgICAgcmVjdl9sZW4g
PSByZWFkbCgmc2htZW0tPmxlbmd0aCkgLSBzaXplb2Yoc2htZW0tPm1zZ19oZWFkZXIpOw0KPj4g
Kw0KPj4gKyAgICBpZiAoIHJlY3ZfbGVuIDwgMCApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIHBy
aW50ayhYRU5MT0dfRVJSDQo+PiArICAgICAgICAgICAgICAgInNjbWk6IFdyb25nIHNpemUgb2Yg
c21jIG1lc3NhZ2UuIERhdGEgbWF5IGJlIGludmFsaWRcbiIpOw0KPj4gKyAgICAgICAgcmV0dXJu
IC1FSU5WQUw7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgdW5wYWNrX3NjbWlfaGVhZGVyKHJl
YWRsKCZzaG1lbS0+bXNnX2hlYWRlciksIGhkcik7DQo+PiArDQo+PiArICAgIGhkci0+c3RhdHVz
ID0gcmVhZGwoJnNobWVtLT5tc2dfcGF5bG9hZCk7DQo+PiArICAgIHJlY3ZfbGVuID0gcmVjdl9s
ZW4gPiBwYWQgPyByZWN2X2xlbiAtIHBhZCA6IDA7DQo+PiArDQo+PiArICAgIHJldCA9IHNjbWlf
dG9feGVuX2Vycm5vKGhkci0+c3RhdHVzKTsNCj4+ICsgICAgaWYgKCByZXQgKQ0KPj4gKyAgICB7
DQo+PiArICAgICAgICBwcmludGsoWEVOTE9HX0RFQlVHICJzY21pOiBFcnJvciByZWNlaXZlZDog
JWRcbiIsIHJldCk7DQo+PiArICAgICAgICByZXR1cm4gcmV0Ow0KPj4gKyAgICB9DQo+PiArDQo+
PiArICAgIGlmICggcmVjdl9sZW4gPiBsZW4gKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBwcmlu
dGsoWEVOTE9HX0VSUg0KPj4gKyAgICAgICAgICAgICAgICJzY21pOiBOb3QgZW5vdWdoIGJ1ZmZl
ciBmb3IgbWVzc2FnZSAlZCwgZXhwZWN0aW5nICVkXG4iLA0KPj4gKyAgICAgICAgICAgICAgIHJl
Y3ZfbGVuLCBsZW4pOw0KPj4gKyAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+PiArICAgIH0NCj4+
ICsNCj4+ICsgICAgaWYgKCByZWN2X2xlbiA+IDAgKQ0KPj4gKyAgICAgICAgX19tZW1jcHlfZnJv
bWlvKGRhdGEsIHNobWVtLT5tc2dfcGF5bG9hZCArIHBhZCwgcmVjdl9sZW4pOw0KPj4gKw0KPj4g
KyAgICByZXR1cm4gMDsNCj4+ICt9DQo+PiArDQo+PiArLyoNCj4+ICsgKiBMb2NhbCB2YXJpYWJs
ZXM6DQo+PiArICogbW9kZTogQw0KPj4gKyAqIGMtZmlsZS1zdHlsZTogIkJTRCINCj4+ICsgKiBj
LWJhc2ljLW9mZnNldDogNA0KPj4gKyAqIHRhYi13aWR0aDogNA0KPj4gKyAqIGluZGVudC10YWJz
LW1vZGU6IG5pbA0KPj4gKyAqIEVuZDoNCj4+ICsgKi8NCj4+IGRpZmYgLS1naXQgYS94ZW4vYXJj
aC9hcm0vZmlybXdhcmUvc2NtaS1zaG1lbS5oIGIveGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWkt
c2htZW0uaA0KPj4gbmV3IGZpbGUgbW9kZSAxMDA2NDQNCj4+IGluZGV4IDAwMDAwMDAwMDAuLjJm
OGUyM2ZmNzYNCj4+IC0tLSAvZGV2L251bGwNCj4+ICsrKyBiL3hlbi9hcmNoL2FybS9maXJtd2Fy
ZS9zY21pLXNobWVtLmgNCj4+IEBAIC0wLDAgKzEsNDUgQEANCj4+ICsvKiBTUERYLUxpY2Vuc2Ut
SWRlbnRpZmllcjogR1BMLTIuMC1vbmx5ICovDQo+PiArLyoNCj4+ICsgKiBBcm0gU3lzdGVtIENv
bnRyb2wgYW5kIE1hbmFnZW1lbnQgSW50ZXJmYWNlIGRlZmluaXRpb25zDQo+PiArICogVmVyc2lv
biAzLjAgKERFTjAwNTZDKQ0KPj4gKyAqIFNoYXJlZCBNZW1vcnkgYmFzZWQgVHJhbnNwb3J0DQo+
PiArICoNCj4+ICsgKiBDb3B5cmlnaHQgKGMpIDIwMjQgRVBBTSBTeXN0ZW1zDQo+PiArICovDQo+
PiArDQo+PiArI2lmbmRlZiBYRU5fQVJDSF9BUk1fU0NJX1NDTUlfU0hNRU1fSF8NCj4+ICsjZGVm
aW5lIFhFTl9BUkNIX0FSTV9TQ0lfU0NNSV9TSE1FTV9IXw0KPiBOSVQ6IEFSTV9GSVJNV0FSRV9T
Q01JX1NITUVNX0gNCj4NCisNCj4+ICsjaW5jbHVkZSA8eGVuL3N0ZGludC5oPg0KPj4gKw0KPj4g
KyNkZWZpbmUgU0NNSV9TSE1FTV9DSEFOX1NUQVRfQ0hBTk5FTF9GUkVFICBCSVQoMCwgVUwpDQo+
PiArI2RlZmluZSBTQ01JX1NITUVNX0NIQU5fU1RBVF9DSEFOTkVMX0VSUk9SIEJJVCgxLCBVTCkN
Cj4+ICsNCj4+ICtzdHJ1Y3Qgc2NtaV9zaGFyZWRfbWVtIHsNCj4+ICsgICAgdWludDMyX3QgcmVz
ZXJ2ZWQ7DQo+PiArICAgIHVpbnQzMl90IGNoYW5uZWxfc3RhdHVzOw0KPj4gKyAgICB1aW50MzJf
dCByZXNlcnZlZDFbMl07DQo+PiArICAgIHVpbnQzMl90IGZsYWdzOw0KPj4gKyAgICB1aW50MzJf
dCBsZW5ndGg7DQo+PiArICAgIHVpbnQzMl90IG1zZ19oZWFkZXI7DQo+PiArICAgIHVpbnQ4X3Qg
bXNnX3BheWxvYWRbXTsNCj4+ICt9Ow0KPj4gKw0KPj4gKyNkZWZpbmUgU0NNSV9TSE1FTV9NQVBQ
RURfU0laRSBQQUdFX1NJWkUNCj4+ICsNCj4+ICtpbnQgc2htZW1fcHV0X21lc3NhZ2Uodm9sYXRp
bGUgc3RydWN0IHNjbWlfc2hhcmVkX21lbSBfX2lvbWVtICpzaG1lbSwNCj4+ICsgICAgICAgICAg
ICAgICAgICAgICAgc2NtaV9tc2dfaGVhZGVyX3QgKmhkciwgdm9pZCAqZGF0YSwgaW50IGxlbik7
DQo+PiArDQo+PiAraW50IHNobWVtX2dldF9yZXNwb25zZShjb25zdCB2b2xhdGlsZSBzdHJ1Y3Qg
c2NtaV9zaGFyZWRfbWVtIF9faW9tZW0gKnNobWVtLA0KPj4gKyAgICAgICAgICAgICAgICAgICAg
ICAgc2NtaV9tc2dfaGVhZGVyX3QgKmhkciwgdm9pZCAqZGF0YSwgaW50IGxlbik7DQo+PiArI2Vu
ZGlmIC8qIFhFTl9BUkNIX0FSTV9TQ0lfU0NNSV9TSE1FTV9IXyAqLw0KPj4gKw0KPj4gKy8qDQo+
PiArICogTG9jYWwgdmFyaWFibGVzOg0KPj4gKyAqIG1vZGU6IEMNCj4+ICsgKiBjLWZpbGUtc3R5
bGU6ICJCU0QiDQo+PiArICogYy1iYXNpYy1vZmZzZXQ6IDQNCj4+ICsgKiB0YWItd2lkdGg6IDQN
Cj4+ICsgKiBpbmRlbnQtdGFicy1tb2RlOiBuaWwNCj4+ICsgKiBFbmQ6DQo+PiArICovDQo+PiBk
aWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktc21jLW11bHRpYWdlbnQuYyBi
L3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNtYy1tdWx0aWFnZW50LmMNCj4+IG5ldyBmaWxl
IG1vZGUgMTAwNjQ0DQo+PiBpbmRleCAwMDAwMDAwMDAwLi5lMDIzYmNhM2ExDQo+PiAtLS0gL2Rl
di9udWxsDQo+PiArKysgYi94ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1zbWMtbXVsdGlhZ2Vu
dC5jDQo+PiBAQCAtMCwwICsxLDg2MCBAQA0KPj4gKy8qIFNQRFgtTGljZW5zZS1JZGVudGlmaWVy
OiBHUEwtMi4wLW9ubHkgKi8NCj4+ICsvKg0KPj4gKyAqIFNDSSBTQ01JIG11bHRpLWFnZW50IGRy
aXZlciwgdXNpbmcgU01DL0hWQyBzaG1lbSBhcyB0cmFuc3BvcnQuDQo+PiArICoNCj4+ICsgKiBP
bGVrc2lpIE1vaXNpZWlldjxvbGVrc2lpX21vaXNpZWlldkBlcGFtLmNvbT4NCj4+ICsgKiBDb3B5
cmlnaHQgKGMpIDIwMjUgRVBBTSBTeXN0ZW1zDQo+PiArICovDQo+PiArDQo+PiArI2luY2x1ZGUg
PHhlbi9hY3BpLmg+DQo+PiArDQo+PiArI2luY2x1ZGUgPHhlbi9kZXZpY2VfdHJlZS5oPg0KPj4g
KyNpbmNsdWRlIDx4ZW4vaW5pdC5oPg0KPj4gKyNpbmNsdWRlIDx4ZW4vaW9jYXAuaD4NCj4+ICsj
aW5jbHVkZSA8eGVuL2Vyci5oPg0KPj4gKyNpbmNsdWRlIDx4ZW4vbGliZmR0L2xpYmZkdC5oPg0K
Pj4gKyNpbmNsdWRlIDx4ZW4vcGFyYW0uaD4NCj4+ICsjaW5jbHVkZSA8eGVuL3NjaGVkLmg+DQo+
PiArI2luY2x1ZGUgPHhlbi92bWFwLmg+DQo+PiArDQo+PiArI2luY2x1ZGUgPGFzbS9maXJtd2Fy
ZS9zY2kuaD4NCj4+ICsjaW5jbHVkZSA8YXNtL3NtY2NjLmg+DQo+PiArDQo+PiArI2luY2x1ZGUg
InNjbWktcHJvdG8uaCINCj4+ICsjaW5jbHVkZSAic2NtaS1zaG1lbS5oIg0KPj4gKw0KPj4gKyNk
ZWZpbmUgU0NNSV9BR0VOVF9JRF9JTlZBTElEIDB4RkYNCj4+ICsNCj4+ICtzdGF0aWMgdWludDhf
dCBfX2luaXRkYXRhIG9wdF9kb20wX3NjbWlfYWdlbnRfaWQgPSBTQ01JX0FHRU5UX0lEX0lOVkFM
SUQ7DQo+PiAraW50ZWdlcl9wYXJhbSgiZG9tMF9zY21pX2FnZW50X2lkIiwgb3B0X2RvbTBfc2Nt
aV9hZ2VudF9pZCk7DQo+PiArDQo+PiArI2RlZmluZSBTQ01JX1NFQ09OREFSWV9BR0VOVFMgInhl
bixzY21pLXNlY29uZGFyeS1hZ2VudHMiDQo+PiArDQo+PiArI2RlZmluZSBIWVBfQ0hBTk5FTCAw
eDANCj4+ICsNCj4+ICtzdHJ1Y3Qgc2NtaV9jaGFubmVsIHsNCj4+ICsgICAgdWludDMyX3QgYWdl
bnRfaWQ7DQo+PiArICAgIHVpbnQzMl90IGZ1bmNfaWQ7DQo+PiArICAgIGRvbWlkX3QgZG9tYWlu
X2lkOw0KPj4gKyAgICB1aW50NjRfdCBwYWRkcjsNCj4+ICsgICAgdWludDY0X3QgbGVuOw0KPj4g
KyAgICBzdHJ1Y3Qgc2NtaV9zaGFyZWRfbWVtIF9faW9tZW0gKnNobWVtOw0KPj4gKyAgICBzcGlu
bG9ja190IGxvY2s7DQo+PiArICAgIHN0cnVjdCBsaXN0X2hlYWQgbGlzdDsNCj4+ICt9Ow0KPj4g
Kw0KPj4gK3N0cnVjdCBzY21pX2RhdGEgew0KPj4gKyAgICBzdHJ1Y3QgbGlzdF9oZWFkIGNoYW5u
ZWxfbGlzdDsNCj4+ICsgICAgc3BpbmxvY2tfdCBjaGFubmVsX2xpc3RfbG9jazsNCj4+ICsgICAg
dWludDMyX3QgZnVuY19pZDsNCj4+ICsgICAgYm9vbCBpbml0aWFsaXplZDsNCj4+ICsgICAgdWlu
dDMyX3Qgc2htZW1fcGhhbmRsZTsNCj4+ICsgICAgc3RydWN0IGR0X2RldmljZV9ub2RlICpkdF9k
ZXY7DQo+PiArfTsNCj4+ICsNCj4+ICtzdGF0aWMgc3RydWN0IHNjbWlfZGF0YSBzY21pX2RhdGE7
DQo+PiArDQo+PiArc3RhdGljIGludCBzZW5kX3NtY19tZXNzYWdlKHN0cnVjdCBzY21pX2NoYW5u
ZWwgKmNoYW5faW5mbywNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2NtaV9tc2df
aGVhZGVyX3QgKmhkciwgdm9pZCAqZGF0YSwgaW50IGxlbikNCj4+ICt7DQo+PiArICAgIHN0cnVj
dCBhcm1fc21jY2NfcmVzIHJlc3A7DQo+PiArICAgIGludCByZXQ7DQo+PiArDQo+PiArICAgIHJl
dCA9IHNobWVtX3B1dF9tZXNzYWdlKGNoYW5faW5mby0+c2htZW0sIGhkciwgZGF0YSwgbGVuKTsN
Cj4+ICsgICAgaWYgKCByZXQgKQ0KPj4gKyAgICAgICAgcmV0dXJuIHJldDsNCj4+ICsNCj4+ICsg
ICAgYXJtX3NtY2NjXzFfMV9zbWMoY2hhbl9pbmZvLT5mdW5jX2lkLCAwLCAwLCAwLCAwLCAwLCAw
LCAwLCAmcmVzcCk7DQo+PiArDQo+PiArICAgIGlmICggcmVzcC5hMCApDQo+PiArICAgICAgICBy
ZXR1cm4gLUVPUE5PVFNVUFA7DQo+IFdoeSBpZiByZXBvLmEwICE9IDAgdGhlbiB3ZSBhc3N1bWUg
LUVPUE5PVFNVUFA/IElzIHRoaXMgcGFydCBvZiB0aGUgU0NNSQ0KPiBzcGVjaWZpY2F0aW9uPw0K
DQpQbGVhc2Ugc2VlIDcuMSBvZiBbMV0uIFRoZSBmb2xsb3dpbmcgY29kZXMgYXJlIHN1cHBvcnRl
ZCA6DQoNCjAgZm9yIHN1Y2Nlc3MNCg0KLTEgYXMgbm90X3N1cHBvcnRlZA0KDQotMiBhcyBub3Rf
cmVxdWlyZWQNCg0KLTMgYXMgaW52YWxpZF9wYXJhbWV0ZXIuDQoNCkZvciBhbGwgbm9uLXplcm8g
cmVzdWx0cyB3ZSBhc3N1bWUgdGhhdCB0aGlzIGNhbGwgaXMgbm90IHN1cHBvcnRlZCBieQ0Kc3lz
dGVtIG9yIGhhcyBkaWZmZXJlbnQgcmV2aXNpb24NCg0Kd2hpY2ggd2UgYWxzbyBkb2Vzbid0IHN1
cHBvcnQuDQoNClsxXSBERU4wMDI4DQpodHRwczovL2RvY3VtZW50YXRpb24tc2VydmljZS5hcm0u
Y29tL3N0YXRpYy81ZjhlZGFlZmY4NmUxNjUxNWNkYmU0YzYNCj4+ICsgICAgcmV0dXJuIDA7DQo+
PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyBpbnQgZG9fc21jX3hmZXIoc3RydWN0IHNjbWlfY2hhbm5l
bCAqY2hhbl9pbmZvLCBzY21pX21zZ19oZWFkZXJfdCAqaGRyLA0KPj4gKyAgICAgICAgICAgICAg
ICAgICAgICAgdm9pZCAqdHhfZGF0YSwgaW50IHR4X3NpemUsIHZvaWQgKnJ4X2RhdGEsIGludCBy
eF9zaXplKQ0KPj4gK3sNCj4+ICsgICAgaW50IHJldCA9IDA7DQo+PiArDQo+PiArICAgIEFTU0VS
VChjaGFuX2luZm8gJiYgY2hhbl9pbmZvLT5zaG1lbSk7DQo+PiArDQo+PiArICAgIGlmICggIWhk
ciApDQo+PiArICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ICsNCj4+ICsgICAgc3Bpbl9sb2Nr
KCZjaGFuX2luZm8tPmxvY2spOw0KPj4gKw0KPj4gKyAgICBwcmludGsoWEVOTE9HX0RFQlVHDQo+
PiArICAgICAgICAgICAic2NtaTogYWdlbnRfaWQgPSAlZCBtc2dfaWQgPSAleCB0eXBlID0gJWQs
IHByb3RvID0gJXhcbiIsDQo+PiArICAgICAgICAgICBjaGFuX2luZm8tPmFnZW50X2lkLCBoZHIt
PmlkLCBoZHItPnR5cGUsIGhkci0+cHJvdG9jb2wpOw0KPj4gKw0KPj4gKyAgICByZXQgPSBzZW5k
X3NtY19tZXNzYWdlKGNoYW5faW5mbywgaGRyLCB0eF9kYXRhLCB0eF9zaXplKTsNCj4+ICsgICAg
aWYgKCByZXQgKQ0KPj4gKyAgICAgICAgZ290byBjbGVhbjsNCj4+ICsNCj4+ICsgICAgcmV0ID0g
c2htZW1fZ2V0X3Jlc3BvbnNlKGNoYW5faW5mby0+c2htZW0sIGhkciwgcnhfZGF0YSwgcnhfc2l6
ZSk7DQo+PiArDQo+PiArY2xlYW46DQo+PiArICAgIHByaW50ayhYRU5MT0dfREVCVUcNCj4+ICsg
ICAgICAgICAgICJzY21pOiBnZXQgc21jIHJlc3BvbnNlIGFnZW50X2lkID0gJWQgbXNnX2lkID0g
JXggcHJvdG8gPSAleCByZXM9JWRcbiIsDQo+PiArICAgICAgICAgICBjaGFuX2luZm8tPmFnZW50
X2lkLCBoZHItPmlkLCBoZHItPnByb3RvY29sLCByZXQpOw0KPj4gKw0KPj4gKyAgICBzcGluX3Vu
bG9jaygmY2hhbl9pbmZvLT5sb2NrKTsNCj4+ICsNCj4+ICsgICAgcmV0dXJuIHJldDsNCj4+ICt9
DQo+PiArDQo+PiArc3RhdGljIHN0cnVjdCBzY21pX2NoYW5uZWwgKmdldF9jaGFubmVsX2J5X2lk
KHVpbnQzMl90IGFnZW50X2lkKQ0KPj4gK3sNCj4+ICsgICAgc3RydWN0IHNjbWlfY2hhbm5lbCAq
Y3VycjsNCj4+ICsgICAgYm9vbCBmb3VuZCA9IGZhbHNlOw0KPj4gKw0KPj4gKyAgICBzcGluX2xv
Y2soJnNjbWlfZGF0YS5jaGFubmVsX2xpc3RfbG9jayk7DQo+PiArICAgIGxpc3RfZm9yX2VhY2hf
ZW50cnkoY3VyciwgJnNjbWlfZGF0YS5jaGFubmVsX2xpc3QsIGxpc3QpDQo+PiArICAgIHsNCj4+
ICsgICAgICAgIGlmICggY3Vyci0+YWdlbnRfaWQgPT0gYWdlbnRfaWQgKQ0KPj4gKyAgICAgICAg
ew0KPj4gKyAgICAgICAgICAgIGZvdW5kID0gdHJ1ZTsNCj4+ICsgICAgICAgICAgICBicmVhazsN
Cj4+ICsgICAgICAgIH0NCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICBzcGluX3VubG9jaygmc2Nt
aV9kYXRhLmNoYW5uZWxfbGlzdF9sb2NrKTsNCj4+ICsgICAgaWYgKCBmb3VuZCApDQo+PiArICAg
ICAgICByZXR1cm4gY3VycjsNCj4+ICsNCj4+ICsgICAgcmV0dXJuIE5VTEw7DQo+PiArfQ0KPj4g
Kw0KPj4gK3N0YXRpYyBzdHJ1Y3Qgc2NtaV9jaGFubmVsICphY3F1aXJlX3NjbWlfY2hhbm5lbChz
dHJ1Y3QgZG9tYWluICpkLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICB1aW50MzJfdCBhZ2VudF9pZCkNCj4+ICt7DQo+PiArICAgIHN0cnVjdCBz
Y21pX2NoYW5uZWwgKmN1cnI7DQo+PiArICAgIHN0cnVjdCBzY21pX2NoYW5uZWwgKnJldCA9IEVS
Ul9QVFIoLUVOT0VOVCk7DQo+PiArDQo+PiArICAgIHNwaW5fbG9jaygmc2NtaV9kYXRhLmNoYW5u
ZWxfbGlzdF9sb2NrKTsNCj4+ICsgICAgbGlzdF9mb3JfZWFjaF9lbnRyeShjdXJyLCAmc2NtaV9k
YXRhLmNoYW5uZWxfbGlzdCwgbGlzdCkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgaWYgKCBjdXJy
LT5hZ2VudF9pZCA9PSBhZ2VudF9pZCApDQo+PiArICAgICAgICB7DQo+PiArICAgICAgICAgICAg
aWYgKCBjdXJyLT5kb21haW5faWQgIT0gRE9NSURfSU5WQUxJRCApDQo+PiArICAgICAgICAgICAg
ew0KPj4gKyAgICAgICAgICAgICAgICByZXQgPSBFUlJfUFRSKC1FRVhJU1QpOw0KPj4gKyAgICAg
ICAgICAgICAgICBicmVhazsNCj4+ICsgICAgICAgICAgICB9DQo+PiArDQo+PiArICAgICAgICAg
ICAgY3Vyci0+ZG9tYWluX2lkID0gZC0+ZG9tYWluX2lkOw0KPj4gKyAgICAgICAgICAgIHJldCA9
IGN1cnI7DQo+PiArICAgICAgICAgICAgYnJlYWs7DQo+PiArICAgICAgICB9DQo+PiArICAgIH0N
Cj4+ICsNCj4+ICsgICAgc3Bpbl91bmxvY2soJnNjbWlfZGF0YS5jaGFubmVsX2xpc3RfbG9jayk7
DQo+PiArDQo+PiArICAgIHJldHVybiByZXQ7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyB2b2lk
IHJlbGlucXVpc2hfc2NtaV9jaGFubmVsKHN0cnVjdCBzY21pX2NoYW5uZWwgKmNoYW5uZWwpDQo+
PiArew0KPj4gKyAgICBBU1NFUlQoY2hhbm5lbCAhPSBOVUxMKTsNCj4+ICsNCj4+ICsgICAgc3Bp
bl9sb2NrKCZzY21pX2RhdGEuY2hhbm5lbF9saXN0X2xvY2spOw0KPj4gKyAgICBjaGFubmVsLT5k
b21haW5faWQgPSBET01JRF9JTlZBTElEOw0KPj4gKyAgICBzcGluX3VubG9jaygmc2NtaV9kYXRh
LmNoYW5uZWxfbGlzdF9sb2NrKTsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIGludCBtYXBfY2hh
bm5lbF9tZW1vcnkoc3RydWN0IHNjbWlfY2hhbm5lbCAqY2hhbm5lbCkNCj4+ICt7DQo+PiArICAg
IEFTU0VSVChjaGFubmVsICYmIGNoYW5uZWwtPnBhZGRyKTsNCj4+ICsgICAgY2hhbm5lbC0+c2ht
ZW0gPSBpb3JlbWFwX25vY2FjaGUoY2hhbm5lbC0+cGFkZHIsIFNDTUlfU0hNRU1fTUFQUEVEX1NJ
WkUpOw0KPiBpb3JlbWFwIGlzIGZvciBNTUlPLCBpZiB0aGVzZSBzaGFyZWQgbWVtb3J5IGNoYW5u
ZWxzIGFyZSBvbiBERFIsIHRoZW4gaXQNCj4gd291bGQgbm90IGJlIHRoZSByaWdodCBjYWxsLiBB
cmUgdGhlICJhcm0sc2NtaS1zaG1lbSIgYWRkcmVzcyByYW5nZXMNCj4gcGFydCBvZiB0aGUgbWVt
b3J5IG5vZGUgcmFuZ2VzPyBPciBhcmUgdGhleSBjb21wbGV0ZWx5IHNlcGFyYXRlPw0KPg0KPiBB
bHNvLCB3aHkgbm9jYWNoZT8gV291bGRuJ3Qgd2Ugd2FudCBpb3JlbWFwX2NhY2hlPw0KPg0KQ3Vy
cmVudGx5LCB0aGV5IGFyZSBzZXBhcmF0ZSBub2RlcyBidXQgY291bGQgcG90ZW50aWFsbHkgYmUg
cGFydCBvZiB0aGUNCiJtZW1vcnktcmVnaW9uIi4NCg0KIEZyb20gd2hhdCBJIHNlZSBpbiB0aGUg
TGludXgga2VybmVsLCBkZXZtX2lvcmVtYXAgaXMgYmVpbmcgdXNlZCB0byBtYXANCnRoZSBtZW1v
cnkuDQoNCkNvdWxkIHRoZXJlIGJlIHNvbWV0aGluZyBtb3JlIHRvIHRoaXMgYXBwcm9hY2g/DQoN
ClswXTpodHRwczovL2dpdC5pbGlhbmEuZnlpL2xpbnV4L3BhdGNoLz9pZD0xZGM2NTU4MDYyZGFk
ZmFiZDJmYjNiZDg4NWZhNmU5MmVjNzE5NmYyDQoNCj4+ICsgICAgaWYgKCAhY2hhbm5lbC0+c2ht
ZW0gKQ0KPj4gKyAgICAgICAgcmV0dXJuIC1FTk9NRU07DQo+PiArDQo+PiArICAgIGNoYW5uZWwt
PnNobWVtLT5jaGFubmVsX3N0YXR1cyA9IFNDTUlfU0hNRU1fQ0hBTl9TVEFUX0NIQU5ORUxfRlJF
RTsNCj4+ICsgICAgcHJpbnRrKFhFTkxPR19ERUJVRyAic2NtaTogR290IHNobWVtICVseCBhZnRl
ciB2bWFwICVwXG4iLCBjaGFubmVsLT5wYWRkciwNCj4+ICsgICAgICAgICAgIGNoYW5uZWwtPnNo
bWVtKTsNCj4+ICsNCj4+ICsgICAgcmV0dXJuIDA7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyB2
b2lkIHVubWFwX2NoYW5uZWxfbWVtb3J5KHN0cnVjdCBzY21pX2NoYW5uZWwgKmNoYW5uZWwpDQo+
PiArew0KPj4gKyAgICBBU1NFUlQoY2hhbm5lbCAmJiBjaGFubmVsLT5zaG1lbSk7DQo+PiArICAg
IGlvdW5tYXAoY2hhbm5lbC0+c2htZW0pOw0KPj4gKyAgICBjaGFubmVsLT5zaG1lbSA9IE5VTEw7
DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyBzdHJ1Y3Qgc2NtaV9jaGFubmVsICpzbWNfY3JlYXRl
X2NoYW5uZWwodWludDMyX3QgYWdlbnRfaWQsDQo+PiArICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCBmdW5jX2lkLCB1aW50NjRfdCBhZGRyKQ0K
Pj4gK3sNCj4+ICsgICAgc3RydWN0IHNjbWlfY2hhbm5lbCAqY2hhbm5lbDsNCj4+ICsNCj4+ICsg
ICAgY2hhbm5lbCA9IGdldF9jaGFubmVsX2J5X2lkKGFnZW50X2lkKTsNCj4+ICsgICAgaWYgKCBj
aGFubmVsICkNCj4+ICsgICAgICAgIHJldHVybiBFUlJfUFRSKEVFWElTVCk7DQo+PiArDQo+PiAr
ICAgIGNoYW5uZWwgPSB4bWFsbG9jKHN0cnVjdCBzY21pX2NoYW5uZWwpOw0KPj4gKyAgICBpZiAo
ICFjaGFubmVsICkNCj4+ICsgICAgICAgIHJldHVybiBFUlJfUFRSKEVOT01FTSk7DQo+PiArDQo+
PiArICAgIHNwaW5fbG9ja19pbml0KCZjaGFubmVsLT5sb2NrKTsNCj4+ICsgICAgY2hhbm5lbC0+
YWdlbnRfaWQgPSBhZ2VudF9pZDsNCj4+ICsgICAgY2hhbm5lbC0+ZnVuY19pZCA9IGZ1bmNfaWQ7
DQo+PiArICAgIGNoYW5uZWwtPmRvbWFpbl9pZCA9IERPTUlEX0lOVkFMSUQ7DQo+PiArICAgIGNo
YW5uZWwtPnNobWVtID0gTlVMTDsNCj4+ICsgICAgY2hhbm5lbC0+cGFkZHIgPSBhZGRyOw0KPj4g
KyAgICBsaXN0X2FkZF90YWlsKCZjaGFubmVsLT5saXN0LCAmc2NtaV9kYXRhLmNoYW5uZWxfbGlz
dCk7DQo+PiArICAgIHJldHVybiBjaGFubmVsOw0KPj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgdm9p
ZCBmcmVlX2NoYW5uZWxfbGlzdCh2b2lkKQ0KPj4gK3sNCj4+ICsgICAgc3RydWN0IHNjbWlfY2hh
bm5lbCAqY3VyciwgKl9jdXJyOw0KPj4gKw0KPj4gKyAgICBsaXN0X2Zvcl9lYWNoX2VudHJ5X3Nh
ZmUoY3VyciwgX2N1cnIsICZzY21pX2RhdGEuY2hhbm5lbF9saXN0LCBsaXN0KQ0KPj4gKyAgICB7
DQo+PiArICAgICAgICBsaXN0X2RlbCgmY3Vyci0+bGlzdCk7DQo+PiArICAgICAgICB4ZnJlZShj
dXJyKTsNCj4+ICsgICAgfQ0KPj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgaW50IF9faW5pdA0KPj4g
K3NjbWlfZHRfcmVhZF9oeXBfY2hhbm5lbF9hZGRyKHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqc2Nt
aV9ub2RlLCB1NjQgKmFkZHIsDQo+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdTY0
ICpzaXplKQ0KPj4gK3sNCj4+ICsgICAgc3RydWN0IGR0X2RldmljZV9ub2RlICpzaG1lbV9ub2Rl
Ow0KPj4gKyAgICBjb25zdCBfX2JlMzIgKnByb3A7DQo+PiArDQo+PiArICAgIHByb3AgPSBkdF9n
ZXRfcHJvcGVydHkoc2NtaV9ub2RlLCAic2htZW0iLCBOVUxMKTsNCj4+ICsgICAgaWYgKCAhcHJv
cCApDQo+PiArICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ICsNCj4+ICsgICAgc2htZW1fbm9k
ZSA9IGR0X2ZpbmRfbm9kZV9ieV9waGFuZGxlKGJlMzJfdG9fY3B1cChwcm9wKSk7DQo+PiArICAg
IGlmICggSVNfRVJSX09SX05VTEwoc2htZW1fbm9kZSkgKQ0KPj4gKyAgICB7DQo+PiArICAgICAg
ICBwcmludGsoWEVOTE9HX0VSUg0KPj4gKyAgICAgICAgICAgICAgICJzY21pOiBEZXZpY2UgdHJl
ZSBlcnJvciwgY2FuJ3QgcGFyc2UgcmVzZXJ2ZWQgbWVtb3J5ICVsZFxuIiwNCj4+ICsgICAgICAg
ICAgICAgICBQVFJfRVJSKHNobWVtX25vZGUpKTsNCj4+ICsgICAgICAgIHJldHVybiBQVFJfRVJS
KHNobWVtX25vZGUpOw0KPj4gKyAgICB9DQo+PiArDQo+PiArICAgIHJldHVybiBkdF9kZXZpY2Vf
Z2V0X2FkZHJlc3Moc2htZW1fbm9kZSwgMCwgYWRkciwgc2l6ZSk7DQo+PiArfQ0KPj4gKw0KPj4g
Ky8qDQo+PiArICogSGFuZGxlIERvbTAgU0NNSSBzcGVjaWZpYyBEVCBub2Rlcw0KPj4gKyAqDQo+
PiArICogTWFrZSBhIGRlY2lzaW9uIG9uIGNvcHlpbmcgU0NNSSBzcGVjaWZpYyBub2RlcyBpbnRv
IERvbTAgZGV2aWNlIHRyZWUuDQo+PiArICogRm9yIFNDTUkgbXVsdGktYWdlbnQgY2FzZToNCj4+
ICsgKiAtIHNobWVtIG5vZGVzIHdpbGwgbm90IGJlIGNvcGllZCBhbmQgZ2VuZXJhdGVkIGluc3Rl
YWQgaWYgU0NNSQ0KPj4gKyAqICAgaXMgZW5hYmxlZCBmb3IgRG9tMA0KPj4gKyAqIC0gc2NtaSBu
b2RlIHdpbGwgYmUgY29waWVkIGlmIFNDTUkgaXMgZW5hYmxlZCBmb3IgRG9tMA0KPj4gKyAqLw0K
Pj4gK3N0YXRpYyBib29sIHNjbWlfZHRfaGFuZGxlX25vZGUoc3RydWN0IGRvbWFpbiAqZCwgc3Ry
dWN0IGR0X2RldmljZV9ub2RlICpub2RlKQ0KPj4gK3sNCj4+ICsgICAgc3RhdGljIGNvbnN0IHN0
cnVjdCBkdF9kZXZpY2VfbWF0Y2ggc2tpcF9tYXRjaGVzW10gX19pbml0Y29uc3QgPSB7DQo+PiAr
ICAgICAgICBEVF9NQVRDSF9DT01QQVRJQkxFKCJhcm0sc2NtaS1zaG1lbSIpLA0KPj4gKyAgICAg
ICAgeyAvKiBzZW50aW5lbCAqLyB9LA0KPj4gKyAgICB9Ow0KPj4gKyAgICBzdGF0aWMgY29uc3Qg
c3RydWN0IGR0X2RldmljZV9tYXRjaCBzY21pX21hdGNoZXNbXSBfX2luaXRjb25zdCA9IHsNCj4+
ICsgICAgICAgIERUX01BVENIX1BBVEgoIi9maXJtd2FyZS9zY21pIiksDQo+PiArICAgICAgICB7
IC8qIHNlbnRpbmVsICovIH0sDQo+PiArICAgIH07DQo+PiArDQo+PiArICAgIGlmICggIXNjbWlf
ZGF0YS5pbml0aWFsaXplZCApDQo+PiArICAgICAgICByZXR1cm4gZmFsc2U7DQo+PiArDQo+PiAr
ICAgIC8qIGFsd2F5cyBkcm9wIHNobWVtICovDQo+PiArICAgIGlmICggZHRfbWF0Y2hfbm9kZShz
a2lwX21hdGNoZXMsIG5vZGUpICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgZHRfZHByaW50aygi
ICBTa2lwIHNjbWkgc2htZW1cbiIpOw0KPj4gKyAgICAgICAgcmV0dXJuIHRydWU7DQo+PiArICAg
IH0NCj4+ICsNCj4+ICsgICAgLyogZHJvcCBzY21pIGlmIG5vdCBlbmFibGVkICovDQo+PiArICAg
IGlmICggZHRfbWF0Y2hfbm9kZShzY21pX21hdGNoZXMsIG5vZGUpICYmICFzY2lfZG9tYWluX2lz
X2VuYWJsZWQoZCkgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBkdF9kcHJpbnRrKCIgIFNraXAg
c2NtaSBub2RlXG4iKTsNCj4+ICsgICAgICAgIHJldHVybiB0cnVlOw0KPj4gKyAgICB9DQo+PiAr
DQo+PiArICAgIHJldHVybiBmYWxzZTsNCj4+ICt9DQo+PiArDQo+PiArLyoNCj4+ICsgKiBGaW5h
bGl6ZSBEb20wIFNDTUkgc3BlY2lmaWMgRFQgbm9kZXMNCj4+ICsgKg0KPj4gKyAqIGlmIFNDTUkg
aXMgZW5hYmxlZCBmb3IgRG9tMDoNCj4+ICsgKiAtIGdlbmVyYXRlIHNobWVtIG5vZGUNCj4+ICsg
KiAtIG1hcCBTQ01JIHNobWVtIE1NSU8gaW50byBEb20wDQo+PiArICovDQo+PiArc3RhdGljIGlu
dCBzY21pX2R0X2ZpbmFsaXplKHN0cnVjdCBkb21haW4gKmQsIHZvaWQgKmZkdCkNCj4+ICt7DQo+
PiArICAgIF9fYmUzMiByZWdbR1VFU1RfUk9PVF9BRERSRVNTX0NFTExTICsgR1VFU1RfUk9PVF9T
SVpFX0NFTExTXTsNCj4+ICsgICAgc3RydWN0IHNjbWlfY2hhbm5lbCAqY2hhbm5lbDsNCj4+ICsg
ICAgaW50IG5vZGVvZmZzZXQ7DQo+PiArICAgIF9fYmUzMiAqY2VsbHM7DQo+PiArICAgIF9fYmUz
MiB2YWw7DQo+PiArICAgIGNoYXIgYnVmWzY0XTsNCj4+ICsgICAgaW50IHJlcywgcmM7DQo+PiAr
DQo+PiArICAgIGlmICggIXNjaV9kb21haW5faXNfZW5hYmxlZChkKSApDQo+PiArICAgICAgICBy
ZXR1cm4gMDsNCj4+ICsNCj4+ICsgICAgY2hhbm5lbCA9IGQtPmFyY2guc2NpX2RhdGE7DQo+PiAr
DQo+PiArICAgIC8qDQo+PiArICAgICAqIFJlcGxhY2UgImFybSxzbWMtaWQiIHdpdGggcHJvcGVy
IHZhbHVlIGFzc2lnbmVkIGZvciBEb20wIFNDTUkgY2hhbm5lbA0KPj4gKyAgICAgKi8NCj4+ICsg
ICAgbm9kZW9mZnNldCA9IGZkdF9ub2RlX29mZnNldF9ieV9jb21wYXRpYmxlKGZkdCwgLTEsICJh
cm0sc2NtaS1zbWMiKTsNCj4+ICsgICAgaWYgKCBub2Rlb2Zmc2V0IDwgMCApDQo+PiArICAgICAg
ICByZXR1cm4gLUVOT0RFVjsNCj4+ICsNCj4+ICsgICAgY2VsbHMgPSAoX19iZTMyICopJnZhbDsN
Cj4+ICsgICAgZHRfc2V0X2NlbGwoJmNlbGxzLCAxLCBjaGFubmVsLT5mdW5jX2lkKTsNCj4+ICsg
ICAgcmVzID0gZmR0X3NldHByb3BfaW5wbGFjZShmZHQsIG5vZGVvZmZzZXQsICJhcm0sc21jLWlk
IiwgJnZhbCwgc2l6ZW9mKHZhbCkpOw0KPj4gKyAgICBpZiAoIHJlcyApDQo+PiArICAgICAgICBy
ZXR1cm4gLUVJTlZBTDsNCj4+ICsNCj4gQXJlIHlvdSBzdXJlIGl0IGlzIHdvcnRoIHRvIGdvIHRo
cm91Z2ggYWxsIHRoaXMgdHJvdWJsZSB0byBtb2RpZnkgRkRUIGluDQo+IHBsYWNlIHdoZW4gd2Ug
Y291bGQgc2ltcGx5IGdlbmVyYXRlIHRoZSBEVCBub2RlIGZyb20gc2NyYXRjaCBsaWtlIHdlIGRv
DQo+IGZvciBleGFtcGxlIGZvciB0aGUgR0lDPyBUaGlzIHNlZW1zIHRvIGJlIG1vcmUgZXJyb3Ig
cHJvbmUgYXMgd2VsbC4gSXMNCj4gZ2VuZXJhdGluZyBpdCBmcm9tIHNjcmF0Y2ggaXMgcmVhbGx5
IGRpZmZpY3VsdD8gSWYgaXQgaXMgZGlmZmljdWx0IHRoZW4gT0suDQo+DQpJbiB0aGUgbGFzdCBw
YXRjaCBbMF0gb2YgdGhlIHNlcmllcywgdGhlcmUgaXMgYSBwcm9wb3NhbCB0byBzZXBhcmF0ZQ0K
DQogIHRoZSBYZW4gcHJpdmlsZWdlZCBhZ2VudCBmcm9tIHRoZSBEb20wIGFnZW50LiBUaGlzIGVs
aW1pbmF0ZXMgdGhlDQoNCm5lZWQgdG8gbW9kaWZ5IHRoZSBYZW4gRGV2aWNlIFRyZWUgQmxvYiAo
RFRCKSwgd2hpY2ggaXMgYSBwb3NpdGl2ZQ0KaW1wcm92ZW1lbnQNCg0Kc2luY2UgdGhlIERvbTAg
YWdlbnQgbm9kZSBpcyBhbHJlYWR5IHByZXNlbnQgaW4gdGhlIGRldmljZSB0cmVlLg0KDQpIb3dl
dmVyLCB0aGUgaXNzdWUgd2l0aCBTQ01JIG5vZGUgZ2VuZXJhdGlvbiBsaWVzIGluIHRoZSBuZWVk
IHRvIGhhbmRsZQ0KDQp0aGUgbGlzdCBvZiBwcm90b2NvbHMgdGhhdCBhcmUgc3VwcG9ydGVkIGFj
cm9zcyB0aGUgc3lzdGVtLg0KDQpJZiB3ZSB3YW50IHRvIGdlbmVyYXRlIHRoZSBTQ01JIG5vZGUg
Zm9yIERvbTAsIHdlIG5lZWQgdG86DQoNCkNvcHkgdGhlc2UgcHJvdG9jb2xzIGZyb20gYSBjZW50
cmFsaXplZCBvciBwcmVkZWZpbmVkIHNvdXJjZS4NClNldCB0aGUgY29ycmVjdCBwaGFuZGxlIGZv
ciBlYWNoIHN1Ym5vZGUgd2l0aGluIHRoZSBTQ01JIG5vZGUsIGVuc3VyaW5nDQoNCmFjY3VyYXRl
IHJlcHJlc2VudGF0aW9uIGFuZCBmdW5jdGlvbmFsaXR5Lg0KVGhpcyBleHRyYSBzdGVwIG9mIG1h
bmFnaW5nIHRoZSBwcm90b2NvbHMgYW5kIHBoYW5kbGVzIGFkZHMNCg0KY29tcGxleGl0eSBidXQg
aXMgbmVjZXNzYXJ5IGZvciBlbnN1cmluZyBwcm9wZXIgc3VwcG9ydCBmb3IgRG9tMC4NCg0KWzBd
DQpodHRwczovL2xpc3RzLnhlbnByb2plY3Qub3JnL2FyY2hpdmVzL2h0bWwveGVuLWRldmVsLzIw
MjUtMDUvbXNnMDEwNDEuaHRtbA0KDQo+PiArICAgIC8qDQo+PiArICAgICAqIEFsbCBTQ01JIHNo
bWVtIG5vZGVzIHNob3VsZCBiZSByZW1vdmVkIGZyb20gRG9tMCBEVCBhdCB0aGlzIHBvaW50LCBz
bw0KPj4gKyAgICAgKiB0aGUgc2htZW0gbm9kZSBmb3IgRG9tMCBuZWVkIHRvIGJlIGdlbmVyYXRl
ZCBmcm9tIFNDTUkgY2hhbm5lbCBhc3NpZ25lZA0KPj4gKyAgICAgKiB0byBEb20wLg0KPj4gKyAg
ICAgKiBUaGUgb3JpZ2luYWwgU0NNSSBzaG1lbSBub2RlIGZyb20gcGxhdGZvcm0gRFQgaXMgdXNl
ZCBieSBYZW4gU0NNSSBkcml2ZXINCj4+ICsgICAgICogaXRzZWxmIGFzIHByaXZpbGVnZWQgY2hh
bm5lbCAoYWdlbnRfaWQ9MCkgdG8gbWFuYWdlIG90aGVyIFNDTUkNCj4+ICsgICAgICogYWdlbnRz
IChkb21haW5zKS4NCj4+ICsgICAgICovDQo+PiArICAgIHNucHJpbnRmKGJ1Ziwgc2l6ZW9mKGJ1
ZiksICJzY21pLXNobWVtQCVseCIsIGNoYW5uZWwtPnBhZGRyKTsNCj4+ICsNCj4+ICsgICAgcmVz
ID0gZmR0X2JlZ2luX25vZGUoZmR0LCBidWYpOw0KPj4gKyAgICBpZiAoIHJlcyApDQo+PiArICAg
ICAgICByZXR1cm4gcmVzOw0KPj4gKw0KPj4gKyAgICByZXMgPSBmZHRfcHJvcGVydHlfc3RyaW5n
KGZkdCwgImNvbXBhdGlibGUiLCAiYXJtLHNjbWktc2htZW0iKTsNCj4+ICsgICAgaWYgKCByZXMg
KQ0KPj4gKyAgICAgICAgcmV0dXJuIHJlczsNCj4+ICsNCj4+ICsgICAgY2VsbHMgPSAmcmVnWzBd
Ow0KPj4gKw0KPj4gKyAgICBkdF9jaGlsZF9zZXRfcmFuZ2UoJmNlbGxzLCBHVUVTVF9ST09UX0FE
RFJFU1NfQ0VMTFMsIEdVRVNUX1JPT1RfU0laRV9DRUxMUywNCj4+ICsgICAgICAgICAgICAgICAg
ICAgICAgIGNoYW5uZWwtPnBhZGRyLCBTQ01JX1NITUVNX01BUFBFRF9TSVpFKTsNCj4+ICsNCj4+
ICsgICAgcmVzID0gZmR0X3Byb3BlcnR5KGZkdCwgInJlZyIsIHJlZywgc2l6ZW9mKHJlZykpOw0K
Pj4gKyAgICBpZiAoIHJlcyApDQo+PiArICAgICAgICByZXR1cm4gcmVzOw0KPj4gKw0KPj4gKyAg
ICByZXMgPSBmZHRfcHJvcGVydHlfY2VsbChmZHQsICJwaGFuZGxlIiwgc2NtaV9kYXRhLnNobWVt
X3BoYW5kbGUpOw0KPj4gKyAgICBpZiAoIHJlcyApDQo+PiArICAgICAgICByZXR1cm4gcmVzOw0K
Pj4gKw0KPj4gKyAgICByZXMgPSBmZHRfZW5kX25vZGUoZmR0KTsNCj4+ICsgICAgaWYgKCByZXMg
KQ0KPj4gKyAgICAgICAgcmV0dXJuIHJlczsNCj4+ICsNCj4+ICsgICAgLyoNCj4+ICsgICAgICog
TWFwIFNDTUkgc2htZW0gaW50byBEb20wIGhlcmUgYXMgc2htZW0gbm9kZXMgYXJlIGV4Y2x1ZGVk
IGZyb20NCj4+ICsgICAgICogZ2VuZXJpYyBEb20wIERUIHByb2Nlc3NpbmcNCj4+ICsgICAgICov
DQo+PiArICAgIHJlcyA9IGlvbWVtX3Blcm1pdF9hY2Nlc3MoZCwgcGFkZHJfdG9fcGZuKGNoYW5u
ZWwtPnBhZGRyKSwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwYWRkcl90b19w
Zm4oY2hhbm5lbC0+cGFkZHIgKw0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBTQ01JX1NITUVNX01BUFBFRF9TSVpFIC0gMSkpOw0KPj4gKyAgICBpZiAoIHJl
cyApDQo+PiArICAgICAgICByZXR1cm4gcmVzOw0KPj4gKw0KPj4gKyAgICByZXMgPSBtYXBfcmVn
aW9uc19wMm10KGQsIGdhZGRyX3RvX2dmbihjaGFubmVsLT5wYWRkciksDQo+PiArICAgICAgICAg
ICAgICAgICAgICAgICAgICAgUEZOX1VQKFNDTUlfU0hNRU1fTUFQUEVEX1NJWkUpLA0KPj4gKyAg
ICAgICAgICAgICAgICAgICAgICAgICAgIG1hZGRyX3RvX21mbihjaGFubmVsLT5wYWRkciksIHAy
bV9tbWlvX2RpcmVjdF9uYyk7DQo+PiArICAgIGlmICggcmVzICkNCj4+ICsgICAgew0KPj4gKyAg
ICAgICAgcmMgPSBpb21lbV9kZW55X2FjY2VzcyhkLCBwYWRkcl90b19wZm4oY2hhbm5lbC0+cGFk
ZHIpLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwYWRkcl90b19wZm4oY2hh
bm5lbC0+cGFkZHIgKw0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgU0NNSV9TSE1FTV9NQVBQRURfU0laRSAtIDEpKTsNCj4+ICsgICAgICAgIGlmICggcmMg
KQ0KPj4gKyAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJzY21pOiBVbmFibGUgdG8gZGVu
eSBpb21lbSBhY2Nlc3MgLCBlcnIgPSAlZFxuIiwNCj4+ICsgICAgICAgICAgICAgICAgICAgcmMp
Ow0KPj4gKyAgICB9DQo+PiArDQo+PiArICAgIHJldHVybiByZXM7DQo+PiArfQ0KPj4gKw0KPj4g
K3N0YXRpYyBpbnQgc2NtaV9hc3NpZ25fZGV2aWNlKHVpbnQzMl90IGFnZW50X2lkLCB1aW50MzJf
dCBkZXZpY2VfaWQsDQo+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3Qg
ZmxhZ3MpDQo+PiArew0KPj4gKyAgICBzdHJ1Y3Qgc2NtaV9tc2dfYmFzZV9zZXRfZGV2aWNlX3Bl
cm1pc3Npb25zX2EycCB0eDsNCj4+ICsgICAgc3RydWN0IHNjbWlfY2hhbm5lbCAqY2hhbm5lbDsN
Cj4+ICsgICAgc2NtaV9tc2dfaGVhZGVyX3QgaGRyOw0KPj4gKyAgICBpbnQgcmV0Ow0KPj4gKw0K
Pj4gKyAgICBjaGFubmVsID0gZ2V0X2NoYW5uZWxfYnlfaWQoSFlQX0NIQU5ORUwpOw0KPj4gKyAg
ICBpZiAoICFjaGFubmVsICkNCj4+ICsgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4gKw0KPj4g
KyAgICBoZHIuaWQgPSBTQ01JX0JBU0VfU0VUX0RFVklDRV9QRVJNSVNTSU9OUzsNCj4+ICsgICAg
aGRyLnR5cGUgPSAwOw0KPj4gKyAgICBoZHIucHJvdG9jb2wgPSBTQ01JX0JBU0VfUFJPVE9DT0w7
DQo+PiArDQo+PiArICAgIHR4LmFnZW50X2lkID0gYWdlbnRfaWQ7DQo+PiArICAgIHR4LmRldmlj
ZV9pZCA9IGRldmljZV9pZDsNCj4+ICsgICAgdHguZmxhZ3MgPSBmbGFnczsNCj4+ICsNCj4+ICsg
ICAgcmV0ID0gZG9fc21jX3hmZXIoY2hhbm5lbCwgJmhkciwgJnR4LCBzaXplb2YodHgpLCBOVUxM
LCAwKTsNCj4+ICsgICAgaWYgKCByZXQgPT0gLUVPUE5PVFNVUFAgKQ0KPj4gKyAgICAgICAgcmV0
dXJuIDA7DQo+IElzIGl0IGFjdHVhbGx5IE9LIHRvIHByZXRlbmQgdGhhdCBldmVyeXRoaW5nIHdv
cmtlZCBpZiB0aGUgcmV0dXJuIGlzDQo+IC1FT1BOT1RTVVBQPyBJIG1lYW4gdGhhdCBpbiB0aGlz
IGNhc2UgY2FuIHdlIGFzc3VtZSB0aGF0IHRoZSBkZXZpY2UgaXMNCj4gYWN0dWFsbHkgYXNzaWdu
ZWQgYW55d2F5PyBXb3VsZG4ndCBmb2xsb3cgdXAgU0NNSSBvcGVyYXRpb25zIG9uIHRoaXMNCj4g
ZGV2aWNlIGZhaWw/DQo+DQpJIHRoaW5rIHlvdSByaWdodC4gV2lsbCBmaXggaW4gdjUNCj4+ICsg
ICAgcmV0dXJuIHJldDsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIGludCBzY21pX2R0X2Fzc2ln
bl9kZXZpY2Uoc3RydWN0IGRvbWFpbiAqZCwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBzdHJ1Y3QgZHRfcGhhbmRsZV9hcmdzICphY19zcGVjKQ0KPj4gK3sNCj4+ICsgICAg
c3RydWN0IHNjbWlfY2hhbm5lbCAqYWdlbnRfY2hhbm5lbDsNCj4+ICsgICAgdWludDMyX3Qgc2Nt
aV9kZXZpY2VfaWQgPSBhY19zcGVjLT5hcmdzWzBdOw0KPj4gKyAgICBpbnQgcmV0Ow0KPj4gKw0K
Pj4gKyAgICBpZiAoICFkLT5hcmNoLnNjaV9kYXRhICkNCj4+ICsgICAgICAgIHJldHVybiAwOw0K
Pj4gKw0KPj4gKyAgICAvKiBUaGUgYWNjZXNzLWNvbnRyb2xsZXJzIGlzIHNwZWNpZmllZCBmb3Ig
RFQgZGV2LCBidXQgaXQncyBub3QgYSBTQ01JICovDQo+PiArICAgIGlmICggYWNfc3BlYy0+bnAg
IT0gc2NtaV9kYXRhLmR0X2RldiApDQo+PiArICAgICAgICByZXR1cm4gMDsNCj4gSSB3b25kZXIg
aWYgdGhpcyBzaG91bGQgYmUgYW4gZXJyb3INCj4NCldlIGRvbuKAmXQgZXhwZWN0IHRoZSBEVCBu
b2RlIGFjY2Vzcy1jb250cm9sbGVyIHRvIHJlbHkgc29sZWx5IG9uIFNDTUkuDQpUaGVyZWZvcmUs
DQoNCmlmIGEgRFQgbm9kZSBoYXMgYW4gYWNjZXNzLWNvbnRyb2xsZXIgYnV0IGl04oCZcyBub3Qg
YXNzb2NpYXRlZCB3aXRoIFNDTUksDQp3ZSBzaG91bGQgc2ltcGx5DQoNCmlnbm9yZSB0aGF0IG5v
ZGUgd2l0aG91dCByYWlzaW5nIGFuIGVycm9yLg0KDQoNClRoYXTigJlzIG15IHVuZGVyc3RhbmRp
bmcgb2YgdGhlIHNpdHVhdGlvbi4NCg0KDQo+PiArICAgIGFnZW50X2NoYW5uZWwgPSBkLT5hcmNo
LnNjaV9kYXRhOw0KPj4gKw0KPj4gKyAgICBzcGluX2xvY2soJmFnZW50X2NoYW5uZWwtPmxvY2sp
Ow0KPj4gKw0KPj4gKyAgICByZXQgPSBzY21pX2Fzc2lnbl9kZXZpY2UoYWdlbnRfY2hhbm5lbC0+
YWdlbnRfaWQsIHNjbWlfZGV2aWNlX2lkLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgU0NNSV9CQVNFX0RFVklDRV9BQ0NFU1NfQUxMT1cpOw0KPj4gKyAgICBpZiAoIHJldCApDQo+
PiArICAgIHsNCj4+ICsgICAgICAgIHByaW50ayhYRU5MT0dfRVJSDQo+PiArICAgICAgICAgICAg
ICAgInNjbWk6IGNvdWxkIG5vdCBhc3NpZ24gZGV2IGZvciAlcGQgYWdlbnQ6JWQgZGV2X2lkOiV1
ICglZCkiLA0KPj4gKyAgICAgICAgICAgICAgIGQsIGFnZW50X2NoYW5uZWwtPmFnZW50X2lkLCBz
Y21pX2RldmljZV9pZCwgcmV0KTsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICBzcGluX3VubG9j
aygmYWdlbnRfY2hhbm5lbC0+bG9jayk7DQo+PiArICAgIHJldHVybiByZXQ7DQo+PiArfQ0KPj4g
Kw0KPj4gK3N0YXRpYyBfX2luaXQgaW50IGNvbGxlY3RfYWdlbnRzKHN0cnVjdCBkdF9kZXZpY2Vf
bm9kZSAqc2NtaV9ub2RlKQ0KPj4gK3sNCj4+ICsgICAgY29uc3Qgc3RydWN0IGR0X2RldmljZV9u
b2RlICpjaG9zZW5fbm9kZTsNCj4+ICsgICAgY29uc3QgX19iZTMyICpwcm9wOw0KPj4gKyAgICB1
aW50MzJfdCBsZW4sIGk7DQo+PiArDQo+PiArICAgIGNob3Nlbl9ub2RlID0gZHRfZmluZF9ub2Rl
X2J5X3BhdGgoIi9jaG9zZW4iKTsNCj4+ICsgICAgaWYgKCAhY2hvc2VuX25vZGUgKQ0KPj4gKyAg
ICB7DQo+PiArICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAic2NtaTogY2hvc2VuIG5vZGUgbm90
IGZvdW5kXG4iKTsNCj4+ICsgICAgICAgIHJldHVybiAtRU5PRU5UOw0KPj4gKyAgICB9DQo+PiAr
DQo+PiArICAgIHByb3AgPSBkdF9nZXRfcHJvcGVydHkoY2hvc2VuX25vZGUsIFNDTUlfU0VDT05E
QVJZX0FHRU5UUywgJmxlbik7DQo+PiArICAgIGlmICggIXByb3AgKQ0KPj4gKyAgICB7DQo+PiAr
ICAgICAgICBwcmludGsoWEVOTE9HX1dBUk5JTkcgInNjbWk6IE5vICVzIHByb3BlcnR5IGZvdW5k
XG4iLA0KPj4gKyAgICAgICAgICAgICAgIFNDTUlfU0VDT05EQVJZX0FHRU5UUyk7DQo+PiArICAg
ICAgICByZXR1cm4gLUVOT0RFVjsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICBpZiAoIGxlbiAl
ICgzICogc2l6ZW9mKHVpbnQzMl90KSkgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBwcmludGso
WEVOTE9HX0VSUiAic2NtaTogSW52YWxpZCBsZW5ndGggb2YgJXMgcHJvcGVydHk6ICVkXG4iLA0K
Pj4gKyAgICAgICAgICAgICAgIFNDTUlfU0VDT05EQVJZX0FHRU5UUywgbGVuKTsNCj4+ICsgICAg
ICAgIHJldHVybiAtRUlOVkFMOw0KPj4gKyAgICB9DQo+PiArDQo+PiArICAgIGZvciAoIGkgPSAw
OyBpIDwgbGVuIC8gKDMgKiBzaXplb2YodWludDMyX3QpKTsgaSsrICkNCj4+ICsgICAgew0KPj4g
KyAgICAgICAgdWludDMyX3QgYWdlbnRfaWQgPSBiZTMyX3RvX2NwdSgqcHJvcCsrKTsNCj4+ICsg
ICAgICAgIHVpbnQzMl90IHNtY19pZCA9IGJlMzJfdG9fY3B1KCpwcm9wKyspOw0KPj4gKyAgICAg
ICAgdWludDMyX3Qgc2htZW1fcGhhbmRsZSA9IGJlMzJfdG9fY3B1KCpwcm9wKyspOw0KPj4gKyAg
ICAgICAgc3RydWN0IGR0X2RldmljZV9ub2RlICpub2RlID0gZHRfZmluZF9ub2RlX2J5X3BoYW5k
bGUoc2htZW1fcGhhbmRsZSk7DQo+PiArICAgICAgICB1NjQgYWRkciwgc2l6ZTsNCj4+ICsgICAg
ICAgIGludCByZXQ7DQo+PiArDQo+PiArICAgICAgICBpZiAoICFub2RlICkNCj4+ICsgICAgICAg
IHsNCj4+ICsgICAgICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAic2NtaTogQ291bGQgbm90IGZp
bmQgc2htZW0gbm9kZSBmb3IgYWdlbnQgJWRcbiIsDQo+PiArICAgICAgICAgICAgICAgICAgIGFn
ZW50X2lkKTsNCj4+ICsgICAgICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ICsgICAgICAgIH0N
Cj4+ICsNCj4+ICsgICAgICAgIHJldCA9IGR0X2RldmljZV9nZXRfYWRkcmVzcyhub2RlLCAwLCAm
YWRkciwgJnNpemUpOw0KPj4gKyAgICAgICAgaWYgKCByZXQgKQ0KPj4gKyAgICAgICAgew0KPj4g
KyAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSDQo+PiArICAgICAgICAgICAgICAgICAgICJz
Y21pOiBDb3VsZCBub3QgcmVhZCBzaG1lbSBhZGRyZXNzIGZvciBhZ2VudCAlZDogJWQiLA0KPj4g
KyAgICAgICAgICAgICAgICAgICBhZ2VudF9pZCwgcmV0KTsNCj4+ICsgICAgICAgICAgICByZXR1
cm4gcmV0Ow0KPj4gKyAgICAgICAgfQ0KPj4gKw0KPj4gKyAgICAgICAgaWYgKCAhSVNfQUxJR05F
RChzaXplLCBTQ01JX1NITUVNX01BUFBFRF9TSVpFKSApDQo+PiArICAgICAgICB7DQo+PiArICAg
ICAgICAgICAgcHJpbnRrKFhFTkxPR19FUlIgInNjbWk6IHNobWVtIG1lbW9yeSBpcyBub3QgYWxp
Z25lZFxuIik7DQo+PiArICAgICAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+PiArICAgICAgICB9
DQo+PiArDQo+PiArICAgICAgICByZXQgPSBQVFJfUkVUKHNtY19jcmVhdGVfY2hhbm5lbChhZ2Vu
dF9pZCwgc21jX2lkLCBhZGRyKSk7DQo+PiArICAgICAgICBpZiAoIHJldCApDQo+PiArICAgICAg
ICB7DQo+PiArICAgICAgICAgICAgcHJpbnRrKFhFTkxPR19FUlIgInNjbWk6IENvdWxkIG5vdCBj
cmVhdGUgY2hhbm5lbCBmb3IgYWdlbnQgJWQ6ICVkIiwNCj4+ICsgICAgICAgICAgICAgICAgICAg
YWdlbnRfaWQsIHJldCk7DQo+PiArICAgICAgICAgICAgcmV0dXJuIHJldDsNCj4+ICsgICAgICAg
IH0NCj4+ICsNCj4+ICsgICAgICAgIHByaW50ayhYRU5MT0dfREVCVUcgInNjbWk6IEFnZW50ICVk
IFNNQyAlWCBhZGRyICVseFxuIiwgYWdlbnRfaWQsDQo+PiArICAgICAgICAgICAgICAgc21jX2lk
LCBhZGRyKTsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICByZXR1cm4gMDsNCj4+ICt9DQo+PiAr
DQo+PiArc3RhdGljIGludCBzY21pX2RvbWFpbl9pbml0KHN0cnVjdCBkb21haW4gKmQsDQo+PiAr
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdCB4ZW5fZG9tY3RsX2NyZWF0ZWRvbWFp
biAqY29uZmlnKQ0KPj4gK3sNCj4+ICsgICAgc3RydWN0IHNjbWlfY2hhbm5lbCAqY2hhbm5lbDsN
Cj4+ICsgICAgaW50IHJldDsNCj4+ICsNCj4+ICsgICAgaWYgKCAhc2NtaV9kYXRhLmluaXRpYWxp
emVkICkNCj4+ICsgICAgICAgIHJldHVybiAwOw0KPj4gKw0KPj4gKyAgICAvKg0KPj4gKyAgICAg
KiBTcGVjaWFsIGNhc2UgZm9yIERvbTAgLSB0aGUgU0NNSSBzdXBwb3J0IGlzIGVuYWJsZWQgYmFz
aW5nIG9uDQo+PiArICAgICAqICJkb20wX3NjaV9hZ2VudF9pZCIgWGVuIGNvbW1hbmQgbGluZSBw
YXJhbWV0ZXINCj4+ICsgICAgICovDQo+PiArICAgIGlmICggaXNfaGFyZHdhcmVfZG9tYWluKGQp
ICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgaWYgKCBvcHRfZG9tMF9zY21pX2FnZW50X2lkICE9
IFNDTUlfQUdFTlRfSURfSU5WQUxJRCApDQo+PiArICAgICAgICB7DQo+PiArICAgICAgICAgICAg
Y29uZmlnLT5hcmNoLmFybV9zY2lfdHlwZSA9IFhFTl9ET01DVExfQ09ORklHX0FSTV9TQ0lfU0NN
SV9TTUNfTUE7DQo+PiArICAgICAgICAgICAgY29uZmlnLT5hcmNoLmFybV9zY2lfYWdlbnRfaWQg
PSBvcHRfZG9tMF9zY21pX2FnZW50X2lkOw0KPj4gKyAgICAgICAgfQ0KPj4gKyAgICAgICAgZWxz
ZQ0KPj4gKyAgICAgICAgICAgIGNvbmZpZy0+YXJjaC5hcm1fc2NpX3R5cGUgPSBYRU5fRE9NQ1RM
X0NPTkZJR19BUk1fU0NJX05PTkU7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgaWYgKCBjb25m
aWctPmFyY2guYXJtX3NjaV90eXBlID09IFhFTl9ET01DVExfQ09ORklHX0FSTV9TQ0lfTk9ORSAp
DQo+PiArICAgICAgICByZXR1cm4gMDsNCj4+ICsNCj4+ICsgICAgY2hhbm5lbCA9IGFjcXVpcmVf
c2NtaV9jaGFubmVsKGQsIGNvbmZpZy0+YXJjaC5hcm1fc2NpX2FnZW50X2lkKTsNCj4+ICsgICAg
aWYgKCBJU19FUlIoY2hhbm5lbCkgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBwcmludGsoWEVO
TE9HX0VSUg0KPj4gKyAgICAgICAgICAgICAgICJzY21pOiBGYWlsZWQgdG8gYWNxdWlyZSBTQ01J
IGNoYW5uZWwgZm9yIGFnZW50X2lkICV1OiAlbGRcbiIsDQo+PiArICAgICAgICAgICAgICAgY29u
ZmlnLT5hcmNoLmFybV9zY2lfYWdlbnRfaWQsIFBUUl9FUlIoY2hhbm5lbCkpOw0KPj4gKyAgICAg
ICAgcmV0dXJuIFBUUl9FUlIoY2hhbm5lbCk7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgcHJp
bnRrKFhFTkxPR19JTkZPDQo+PiArICAgICAgICAgICAic2NtaTogQWNxdWlyZSBjaGFubmVsIGlk
ID0gMHgleCwgZG9tYWluX2lkID0gJWQgcGFkZHIgPSAweCVseFxuIiwNCj4+ICsgICAgICAgICAg
IGNoYW5uZWwtPmFnZW50X2lkLCBjaGFubmVsLT5kb21haW5faWQsIGNoYW5uZWwtPnBhZGRyKTsN
Cj4+ICsNCj4+ICsgICAgLyoNCj4+ICsgICAgICogRG9tMCAoaWYgcHJlc2VudCkgbmVlZHMgdG8g
aGF2ZSBhbiBhY2Nlc3MgdG8gdGhlIGd1ZXN0IG1lbW9yeSByYW5nZQ0KPj4gKyAgICAgKiB0byBz
YXRpc2Z5IGlvbWVtX2FjY2Vzc19wZXJtaXR0ZWQoKSBjaGVjayBpbiBYRU5fRE9NQ1RMX2lvbWVt
X3Blcm1pc3Npb24NCj4+ICsgICAgICogZG9tY3RsLg0KPiBJZGVhbGx5IHRoaXMgc2hvdWxkIG5v
dCBiZSBuZWVkZWQgYnV0IEkgdW5kZXJzdGFuZCB3ZSBkb24ndCBoYXZlIGFuDQo+IGVhc3kgc29s
dXRpb24sIEkgdGhpbmsgd2UgY2FuIGdvIGFoZWFkIHdpdGggdGhpcyBmb3Igbm93Lg0KPg0KPj4g
KyAgICAgKi8NCj4+ICsgICAgaWYgKCBoYXJkd2FyZV9kb21haW4gJiYgIWlzX2hhcmR3YXJlX2Rv
bWFpbihkKSApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIHJldCA9IGlvbWVtX3Blcm1pdF9hY2Nl
c3MoaGFyZHdhcmVfZG9tYWluLCBwYWRkcl90b19wZm4oY2hhbm5lbC0+cGFkZHIpLA0KPj4gKyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwYWRkcl90b19wZm4oY2hhbm5lbC0+cGFk
ZHIgKyBQQUdFX1NJWkUgLSAxKSk7DQo+PiArICAgICAgICBpZiAoIHJldCApDQo+PiArICAgICAg
ICAgICAgZ290byBlcnJvcjsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICBkLT5hcmNoLnNjaV9k
YXRhID0gY2hhbm5lbDsNCj4+ICsgICAgZC0+YXJjaC5zY2lfZW5hYmxlZCA9IHRydWU7DQo+PiAr
DQo+PiArICAgIHJldHVybiAwOw0KPj4gKw0KPj4gK2Vycm9yOg0KPj4gKyAgICByZWxpbnF1aXNo
X3NjbWlfY2hhbm5lbChjaGFubmVsKTsNCj4+ICsgICAgcmV0dXJuIHJldDsNCj4+ICt9DQo+PiAr
DQo+PiAraW50IHNjbWlfZG9tYWluX3Nhbml0aXNlX2NvbmZpZyhzdHJ1Y3QgeGVuX2RvbWN0bF9j
cmVhdGVkb21haW4gKmNvbmZpZykNCj4+ICt7DQo+PiArICAgIGlmICggY29uZmlnLT5hcmNoLmFy
bV9zY2lfdHlwZSAhPSBYRU5fRE9NQ1RMX0NPTkZJR19BUk1fU0NJX05PTkUgJiYNCj4+ICsgICAg
ICAgICBjb25maWctPmFyY2guYXJtX3NjaV90eXBlICE9IFhFTl9ET01DVExfQ09ORklHX0FSTV9T
Q0lfU0NNSV9TTUNfTUEgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBkcHJpbnRrKFhFTkxPR19J
TkZPLCAic2NtaTogVW5zdXBwb3J0ZWQgQVJNX1NDSSB0eXBlXG4iKTsNCj4+ICsgICAgICAgIHJl
dHVybiAtRUlOVkFMOw0KPj4gKyAgICB9DQo+PiArICAgIGVsc2UgaWYgKCBjb25maWctPmFyY2gu
YXJtX3NjaV90eXBlID09DQo+PiArICAgICAgICAgICAgICBYRU5fRE9NQ1RMX0NPTkZJR19BUk1f
U0NJX1NDTUlfU01DX01BICYmDQo+PiArICAgICAgICAgICAgICBjb25maWctPmFyY2guYXJtX3Nj
aV9hZ2VudF9pZCA9PSAwICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgZHByaW50ayhYRU5MT0df
SU5GTywNCj4+ICsgICAgICAgICAgICAgICAgInNjbWk6IEEgemVybyBBUk0gU0NNSSBhZ2VudF9p
ZCBpcyBub3Qgc3VwcG9ydGVkXG4iKTsNCj4+ICsgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4g
KyAgICB9DQo+PiArDQo+PiArICAgIHJldHVybiAwOw0KPj4gK30NCj4+ICsNCj4+ICtzdGF0aWMg
aW50IHNjbWlfcmVsaW5xdWlzaF9yZXNvdXJjZXMoc3RydWN0IGRvbWFpbiAqZCkNCj4+ICt7DQo+
PiArICAgIGludCByZXQ7DQo+PiArICAgIHN0cnVjdCBzY21pX2NoYW5uZWwgKmNoYW5uZWwsICph
Z2VudF9jaGFubmVsOw0KPj4gKyAgICBzY21pX21zZ19oZWFkZXJfdCBoZHI7DQo+PiArICAgIHN0
cnVjdCBzY21pX21zZ19iYXNlX3Jlc2V0X2FnZW50X2NmZ19hMnAgdHg7DQo+PiArDQo+PiArICAg
IGlmICggIWQtPmFyY2guc2NpX2RhdGEgKQ0KPj4gKyAgICAgICAgcmV0dXJuIDA7DQo+PiArDQo+
PiArICAgIGFnZW50X2NoYW5uZWwgPSBkLT5hcmNoLnNjaV9kYXRhOw0KPj4gKw0KPj4gKyAgICBz
cGluX2xvY2soJmFnZW50X2NoYW5uZWwtPmxvY2spOw0KPj4gKyAgICB0eC5hZ2VudF9pZCA9IGFn
ZW50X2NoYW5uZWwtPmFnZW50X2lkOw0KPj4gKyAgICBzcGluX3VubG9jaygmYWdlbnRfY2hhbm5l
bC0+bG9jayk7DQo+PiArDQo+PiArICAgIGNoYW5uZWwgPSBnZXRfY2hhbm5lbF9ieV9pZChIWVBf
Q0hBTk5FTCk7DQo+PiArICAgIGlmICggIWNoYW5uZWwgKQ0KPj4gKyAgICB7DQo+PiArICAgICAg
ICBwcmludGsoWEVOTE9HX0VSUg0KPj4gKyAgICAgICAgICAgICAgICJzY21pOiBVbmFibGUgdG8g
Z2V0IEh5cGVydmlzb3Igc2NtaSBjaGFubmVsIGZvciBkb21haW4gJWRcbiIsDQo+PiArICAgICAg
ICAgICAgICAgZC0+ZG9tYWluX2lkKTsNCj4+ICsgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4g
KyAgICB9DQo+PiArDQo+PiArICAgIGhkci5pZCA9IFNDTUlfQkFTRV9SRVNFVF9BR0VOVF9DT05G
SUdVUkFUSU9OOw0KPj4gKyAgICBoZHIudHlwZSA9IDA7DQo+PiArICAgIGhkci5wcm90b2NvbCA9
IFNDTUlfQkFTRV9QUk9UT0NPTDsNCj4+ICsNCj4+ICsgICAgdHguZmxhZ3MgPSAwOw0KPj4gKw0K
Pj4gKyAgICByZXQgPSBkb19zbWNfeGZlcihjaGFubmVsLCAmaGRyLCAmdHgsIHNpemVvZih0eCks
IE5VTEwsIDApOw0KPj4gKyAgICBpZiAoIHJldCA9PSAtRU9QTk9UU1VQUCApDQo+PiArICAgICAg
ICByZXR1cm4gMDsNCj4+ICsNCj4+ICsgICAgcmV0dXJuIHJldDsNCj4+ICt9DQo+PiArDQo+PiAr
c3RhdGljIHZvaWQgc2NtaV9kb21haW5fZGVzdHJveShzdHJ1Y3QgZG9tYWluICpkKQ0KPj4gK3sN
Cj4+ICsgICAgc3RydWN0IHNjbWlfY2hhbm5lbCAqY2hhbm5lbDsNCj4+ICsNCj4+ICsgICAgaWYg
KCAhZC0+YXJjaC5zY2lfZGF0YSApDQo+PiArICAgICAgICByZXR1cm47DQo+PiArDQo+PiArICAg
IGNoYW5uZWwgPSBkLT5hcmNoLnNjaV9kYXRhOw0KPj4gKyAgICBzcGluX2xvY2soJmNoYW5uZWwt
PmxvY2spOw0KPj4gKw0KPj4gKyAgICByZWxpbnF1aXNoX3NjbWlfY2hhbm5lbChjaGFubmVsKTsN
Cj4+ICsgICAgcHJpbnRrKFhFTkxPR19ERUJVRyAic2NtaTogRnJlZSBkb21haW4gJWRcbiIsIGQt
PmRvbWFpbl9pZCk7DQo+PiArDQo+PiArICAgIGQtPmFyY2guc2NpX2RhdGEgPSBOVUxMOw0KPj4g
KyAgICBkLT5hcmNoLnNjaV9lbmFibGVkID0gdHJ1ZTsNCj4+ICsNCj4+ICsgICAgc3Bpbl91bmxv
Y2soJmNoYW5uZWwtPmxvY2spOw0KPj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgYm9vbCBzY21pX2hh
bmRsZV9jYWxsKHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKQ0KPj4gK3sNCj4+ICsgICAgdWlu
dDMyX3QgZmlkID0gKHVpbnQzMl90KWdldF91c2VyX3JlZyhyZWdzLCAwKTsNCj4+ICsgICAgc3Ry
dWN0IHNjbWlfY2hhbm5lbCAqYWdlbnRfY2hhbm5lbDsNCj4+ICsgICAgc3RydWN0IGRvbWFpbiAq
ZCA9IGN1cnJlbnQtPmRvbWFpbjsNCj4+ICsgICAgc3RydWN0IGFybV9zbWNjY19yZXMgcmVzcDsN
Cj4+ICsgICAgYm9vbCByZXMgPSBmYWxzZTsNCj4+ICsNCj4+ICsgICAgaWYgKCAhc2NpX2RvbWFp
bl9pc19lbmFibGVkKGQpICkNCj4+ICsgICAgICAgIHJldHVybiBmYWxzZTsNCj4+ICsNCj4+ICsg
ICAgYWdlbnRfY2hhbm5lbCA9IGQtPmFyY2guc2NpX2RhdGE7DQo+PiArICAgIHNwaW5fbG9jaygm
YWdlbnRfY2hhbm5lbC0+bG9jayk7DQo+PiArDQo+PiArICAgIGlmICggYWdlbnRfY2hhbm5lbC0+
ZnVuY19pZCAhPSBmaWQgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICByZXMgPSBmYWxzZTsNCj4+
ICsgICAgICAgIGdvdG8gdW5sb2NrOw0KPj4gKyAgICB9DQo+PiArDQo+PiArICAgIGFybV9zbWNj
Y18xXzFfc21jKGZpZCwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgZ2V0X3VzZXJfcmVnKHJl
Z3MsIDEpLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICBnZXRfdXNlcl9yZWcocmVncywgMiks
DQo+PiArICAgICAgICAgICAgICAgICAgICAgIGdldF91c2VyX3JlZyhyZWdzLCAzKSwNCj4+ICsg
ICAgICAgICAgICAgICAgICAgICAgZ2V0X3VzZXJfcmVnKHJlZ3MsIDQpLA0KPj4gKyAgICAgICAg
ICAgICAgICAgICAgICBnZXRfdXNlcl9yZWcocmVncywgNSksDQo+PiArICAgICAgICAgICAgICAg
ICAgICAgIGdldF91c2VyX3JlZyhyZWdzLCA2KSwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAg
Z2V0X3VzZXJfcmVnKHJlZ3MsIDcpLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAmcmVzcCk7
DQo+PiArDQo+PiArICAgIHNldF91c2VyX3JlZyhyZWdzLCAwLCByZXNwLmEwKTsNCj4+ICsgICAg
c2V0X3VzZXJfcmVnKHJlZ3MsIDEsIHJlc3AuYTEpOw0KPj4gKyAgICBzZXRfdXNlcl9yZWcocmVn
cywgMiwgcmVzcC5hMik7DQo+PiArICAgIHNldF91c2VyX3JlZyhyZWdzLCAzLCByZXNwLmEzKTsN
Cj4+ICsgICAgcmVzID0gdHJ1ZTsNCj4+ICt1bmxvY2s6DQo+PiArICAgIHNwaW5fdW5sb2NrKCZh
Z2VudF9jaGFubmVsLT5sb2NrKTsNCj4+ICsNCj4+ICsgICAgcmV0dXJuIHJlczsNCj4+ICt9DQo+
PiArDQo+PiArc3RhdGljIGNvbnN0IHN0cnVjdCBzY2lfbWVkaWF0b3Jfb3BzIHNjbWlfb3BzID0g
ew0KPj4gKyAgICAuZG9tYWluX2luaXQgPSBzY21pX2RvbWFpbl9pbml0LA0KPj4gKyAgICAuZG9t
YWluX2Rlc3Ryb3kgPSBzY21pX2RvbWFpbl9kZXN0cm95LA0KPj4gKyAgICAucmVsaW5xdWlzaF9y
ZXNvdXJjZXMgPSBzY21pX3JlbGlucXVpc2hfcmVzb3VyY2VzLA0KPj4gKyAgICAuaGFuZGxlX2Nh
bGwgPSBzY21pX2hhbmRsZV9jYWxsLA0KPj4gKyAgICAuZG9tMF9kdF9oYW5kbGVfbm9kZSA9IHNj
bWlfZHRfaGFuZGxlX25vZGUsDQo+PiArICAgIC5kb20wX2R0X2ZpbmFsaXplID0gc2NtaV9kdF9m
aW5hbGl6ZSwNCj4+ICsgICAgLmRvbWFpbl9zYW5pdGlzZV9jb25maWcgPSBzY21pX2RvbWFpbl9z
YW5pdGlzZV9jb25maWcsDQo+PiArICAgIC5hc3NpZ25fZHRfZGV2aWNlID0gc2NtaV9kdF9hc3Np
Z25fZGV2aWNlLA0KPj4gK307DQo+PiArDQo+PiArc3RhdGljIGludCBfX2luaXQgc2NtaV9jaGVj
a19zbWNjY192ZXIodm9pZCkNCj4+ICt7DQo+PiArICAgIGlmICggc21jY2NfdmVyIDwgQVJNX1NN
Q0NDX1ZFUlNJT05fMV8xICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19X
QVJOSU5HDQo+PiArICAgICAgICAgICAgICAgInNjbWk6IE5vIFNNQ0NDIDEuMSBzdXBwb3J0LCBT
Q01JIGNhbGxzIGZvcndhcmRpbmcgZGlzYWJsZWRcbiIpOw0KPj4gKyAgICAgICAgcmV0dXJuIC1F
Tk9TWVM7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgcmV0dXJuIDA7DQo+PiArfQ0KPj4gKw0K
Pj4gK3N0YXRpYyBfX2luaXQgaW50IHNjbWlfcHJvYmUoc3RydWN0IGR0X2RldmljZV9ub2RlICpz
Y21pX25vZGUsIGNvbnN0IHZvaWQgKmRhdGEpDQo+PiArew0KPj4gKyAgICB1NjQgYWRkciwgc2l6
ZTsNCj4+ICsgICAgaW50IHJldCwgaTsNCj4+ICsgICAgc3RydWN0IHNjbWlfY2hhbm5lbCAqY2hh
bm5lbCwgKmFnZW50X2NoYW5uZWw7DQo+PiArICAgIGludCBuX2FnZW50czsNCj4+ICsgICAgc2Nt
aV9tc2dfaGVhZGVyX3QgaGRyOw0KPj4gKyAgICBzdHJ1Y3Qgc2NtaV9tc2dfYmFzZV9hdHRyaWJ1
dGVzX3AyYSByeDsNCj4+ICsNCj4+ICsgICAgQVNTRVJUKHNjbWlfbm9kZSAhPSBOVUxMKTsNCj4+
ICsNCj4+ICsgICAgSU5JVF9MSVNUX0hFQUQoJnNjbWlfZGF0YS5jaGFubmVsX2xpc3QpOw0KPj4g
KyAgICBzcGluX2xvY2tfaW5pdCgmc2NtaV9kYXRhLmNoYW5uZWxfbGlzdF9sb2NrKTsNCj4+ICsN
Cj4+ICsgICAgaWYgKCAhYWNwaV9kaXNhYmxlZCApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIHBy
aW50ayhYRU5MT0dfV0FSTklORyAic2NtaTogaXMgbm90IHN1cHBvcnRlZCB3aGVuIHVzaW5nIEFD
UElcbiIpOw0KPj4gKyAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+PiArICAgIH0NCj4+ICsNCj4+
ICsgICAgcmV0ID0gc2NtaV9jaGVja19zbWNjY192ZXIoKTsNCj4+ICsgICAgaWYgKCByZXQgKQ0K
Pj4gKyAgICAgICAgcmV0dXJuIHJldDsNCj4+ICsNCj4+ICsgICAgaWYgKCAhZHRfcHJvcGVydHlf
cmVhZF91MzIoc2NtaV9ub2RlLCAiYXJtLHNtYy1pZCIsICZzY21pX2RhdGEuZnVuY19pZCkgKQ0K
Pj4gKyAgICB7DQo+PiArICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAic2NtaTogdW5hYmxlIHRv
IHJlYWQgc21jLWlkIGZyb20gRFRcbiIpOw0KPj4gKyAgICAgICAgcmV0dXJuIC1FTk9FTlQ7DQo+
PiArICAgIH0NCj4+ICsNCj4+ICsgICAgLyogc2F2ZSBzaG1lbSBwaGFuZGxlIGFuZCByZS11c2Ug
aXQgZnJvIERvbTAgRFQgc2htZW0gbm9kZSAqLw0KPj4gKyAgICBpZiAoICFkdF9wcm9wZXJ0eV9y
ZWFkX3UzMihzY21pX25vZGUsICJzaG1lbSIsICZzY21pX2RhdGEuc2htZW1fcGhhbmRsZSkgKQ0K
Pj4gKyAgICB7DQo+PiArICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAic2NtaTogdW5hYmxlIHRv
IHJlYWQgc2htZW0gcGhhbmRsZSBmcm9tIERUXG4iKTsNCj4+ICsgICAgICAgIHJldHVybiAtRU5P
RU5UOw0KPj4gKyAgICB9DQo+PiArDQo+PiArICAgIHJldCA9IHNjbWlfZHRfcmVhZF9oeXBfY2hh
bm5lbF9hZGRyKHNjbWlfbm9kZSwgJmFkZHIsICZzaXplKTsNCj4+ICsgICAgaWYgKCBJU19FUlJf
VkFMVUUocmV0KSApDQo+PiArICAgICAgICByZXR1cm4gLUVOT0VOVDsNCj4+ICsNCj4+ICsgICAg
aWYgKCAhSVNfQUxJR05FRChzaXplLCBTQ01JX1NITUVNX01BUFBFRF9TSVpFKSApDQo+PiArICAg
IHsNCj4+ICsgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJzY21pOiBzaG1lbSBtZW1vcnkgaXMg
bm90IGFsaWduZWRcbiIpOw0KPj4gKyAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+PiArICAgIH0N
Cj4+ICsNCj4+ICsgICAgc2NtaV9kYXRhLmR0X2RldiA9IHNjbWlfbm9kZTsNCj4+ICsNCj4+ICsg
ICAgY2hhbm5lbCA9IHNtY19jcmVhdGVfY2hhbm5lbChIWVBfQ0hBTk5FTCwgc2NtaV9kYXRhLmZ1
bmNfaWQsIGFkZHIpOw0KPj4gKyAgICBpZiAoIElTX0VSUihjaGFubmVsKSApDQo+PiArICAgICAg
ICBnb3RvIG91dDsNCj4+ICsNCj4+ICsgICAgcmV0ID0gbWFwX2NoYW5uZWxfbWVtb3J5KGNoYW5u
ZWwpOw0KPj4gKyAgICBpZiAoIHJldCApDQo+PiArICAgICAgICBnb3RvIG91dDsNCj4+ICsNCj4+
ICsgICAgY2hhbm5lbC0+ZG9tYWluX2lkID0gRE9NSURfWEVOOw0KPj4gKw0KPj4gKyAgICBoZHIu
aWQgPSBTQ01JX0JBU0VfUFJPVE9DT0xfQVRUSUJVVEVTOw0KPj4gKyAgICBoZHIudHlwZSA9IDA7
DQo+PiArICAgIGhkci5wcm90b2NvbCA9IFNDTUlfQkFTRV9QUk9UT0NPTDsNCj4+ICsNCj4+ICsg
ICAgcmV0ID0gZG9fc21jX3hmZXIoY2hhbm5lbCwgJmhkciwgTlVMTCwgMCwgJnJ4LCBzaXplb2Yo
cngpKTsNCj4+ICsgICAgaWYgKCByZXQgKQ0KPj4gKyAgICAgICAgZ290byBlcnJvcjsNCj4+ICsN
Cj4+ICsgICAgbl9hZ2VudHMgPSBTQ01JX0ZJRUxEX0dFVChTQ01JX0JBU0VfQVRUUl9OVU1fQUdF
TlQsIHJ4LmF0dHJpYnV0ZXMpOw0KPj4gKyAgICBwcmludGsoWEVOTE9HX0RFQlVHICJzY21pOiBH
b3QgYWdlbnQgY291bnQgJWRcbiIsIG5fYWdlbnRzKTsNCj4+ICsNCj4+ICsgICAgcmV0ID0gY29s
bGVjdF9hZ2VudHMoc2NtaV9ub2RlKTsNCj4+ICsgICAgaWYgKCByZXQgKQ0KPj4gKyAgICAgICAg
Z290byBlcnJvcjsNCj4+ICsNCj4+ICsgICAgaSA9IDE7DQo+PiArDQo+PiArICAgIGxpc3RfZm9y
X2VhY2hfZW50cnkoYWdlbnRfY2hhbm5lbCwgJnNjbWlfZGF0YS5jaGFubmVsX2xpc3QsIGxpc3Qp
DQo+PiArICAgIHsNCj4+ICsgICAgICAgIHN0cnVjdCBzY21pX21zZ19iYXNlX2Rpc2NvdmVyX2Fn
ZW50X3AyYSBkYV9yeDsNCj4+ICsgICAgICAgIHN0cnVjdCBzY21pX21zZ19iYXNlX2Rpc2NvdmVy
X2FnZW50X2EycCBkYV90eDsNCj4+ICsNCj4+ICsgICAgICAgIHJldCA9IG1hcF9jaGFubmVsX21l
bW9yeShhZ2VudF9jaGFubmVsKTsNCj4+ICsgICAgICAgIGlmICggcmV0ICkNCj4+ICsgICAgICAg
ICAgICBnb3RvIGVycm9yOw0KPj4gKw0KPj4gKyAgICAgICAgaGRyLmlkID0gU0NNSV9CQVNFX0RJ
U0NPVkVSX0FHRU5UOw0KPj4gKyAgICAgICAgaGRyLnR5cGUgPSAwOw0KPj4gKyAgICAgICAgaGRy
LnByb3RvY29sID0gU0NNSV9CQVNFX1BST1RPQ09MOw0KPj4gKw0KPj4gKyAgICAgICAgZGFfdHgu
YWdlbnRfaWQgPSBhZ2VudF9jaGFubmVsLT5hZ2VudF9pZDsNCj4+ICsNCj4+ICsgICAgICAgIHJl
dCA9IGRvX3NtY194ZmVyKGFnZW50X2NoYW5uZWwsICZoZHIsICZkYV90eCwgc2l6ZW9mKGRhX3R4
KSwgJmRhX3J4LA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgc2l6ZW9mKGRhX3J4KSk7
DQo+PiArICAgICAgICBpZiAoIGFnZW50X2NoYW5uZWwtPmRvbWFpbl9pZCAhPSBET01JRF9YRU4g
KQ0KPj4gKyAgICAgICAgICAgIHVubWFwX2NoYW5uZWxfbWVtb3J5KGFnZW50X2NoYW5uZWwpOw0K
Pj4gKyAgICAgICAgaWYgKCByZXQgKQ0KPj4gKyAgICAgICAgICAgIGdvdG8gZXJyb3I7DQo+PiAr
DQo+PiArICAgICAgICBwcmludGsoWEVOTE9HX0RFQlVHICJpZD0weCV4IG5hbWU9JXNcbiIsIGRh
X3J4LmFnZW50X2lkLCBkYV9yeC5uYW1lKTsNCj4+ICsNCj4+ICsgICAgICAgIGFnZW50X2NoYW5u
ZWwtPmFnZW50X2lkID0gZGFfcnguYWdlbnRfaWQ7DQo+IEl0IGlzIE9LIHRvIHNldCBhZ2VudF9j
aGFubmVsLT5hZ2VudF9pZCB0byB0aGUgdmFsdWUgcHJvdmlkZWQgYnkgdGhlDQo+IFNDTUkgc2Vy
dmVyLCBidXQgaWYgd2UgYXJlIGFsc28gdGFraW5nIHRoZSBhZ2VudF9jaGFubmVsLT5hZ2VudF9p
ZCB2YWx1ZQ0KPiBmcm9tIHRoZSB1c2VyIHZpYSBkZXZpY2UgdHJlZSwgc2hvdWxkbid0IHdlIHRo
cm93IGFuIGVycm9yIGlmIHRoZXJlIGlzIGENCj4gbWlzbWF0Y2g/DQo+DQo+IE9yIGV2ZW4gYmV0
dGVyOiBjYW4gd2UgYXZvaWQgdGFraW5nIHRoZSB2YWx1ZSB2aWEgZGV2aWNlIHRyZWUgdG8gbWFr
ZSBpdA0KPiBlYXNpZXIgdG8gY29uZmlndXJlPw0KPg0KSSBwbGFuIHRvIGRyb3AgdGhlIGxhc3Qg
bGluZSwgYXMgdGhlcmXigJlzIG5vIG5lZWQgdG8gb3ZlcndyaXRlIGFnZW50X2lkLg0KDQpIb3dl
dmVyLCB3ZSBjYW5ub3QgYXZvaWQgb2J0YWluaW5nIGFnZW50X2lkIGZyb20gdGhlIGRldmljZSB0
cmVlIGJlY2F1c2UsDQoNCmFjY29yZGluZyB0byBzZWN0aW9uIDQuMi4yLjkgWzBdLCBhbiBhZ2Vu
dCBjYW4gb25seSBiZSBkaXNjb3ZlcmVkIGJ5IGl0cw0KYWdlbnRfaWQgaW4NCg0KYSBwcml2aWxl
Z2VkIGRvbWFpbi4gQWx0ZXJuYXRpdmVseSwgZWFjaCBhZ2VudCBjYW4gb2J0YWluIGl0cyBvd24g
SUQgYnkNCnByb3ZpZGluZw0KDQoweEZGRkZGRkZGIGFzIGFnZW50X2lkIGFuZCB1c2luZyBpdHMg
b3duIGNoYW5uZWwuDQoNClswXSBERU4wMDU2RSBieSBBUk0NCg0KPj4gKyAgICAgICAgaWYgKCBp
ID4gbl9hZ2VudHMgKQ0KPj4gKyAgICAgICAgICAgIGJyZWFrOw0KPj4gKw0KPj4gKyAgICAgICAg
aSsrOw0KPj4gKyAgICB9DQo+PiArDQo+PiArICAgIHJldCA9IHNjaV9yZWdpc3Rlcigmc2NtaV9v
cHMpOw0KPj4gKyAgICBpZiAoIHJldCApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIHByaW50ayhY
RU5MT0dfRVJSICJTQ01JOiBtZWRpYXRvciBhbHJlYWR5IHJlZ2lzdGVyZWQgKHJldCA9ICVkKVxu
IiwNCj4+ICsgICAgICAgICAgICAgICByZXQpOw0KPj4gKyAgICAgICAgcmV0dXJuIHJldDsNCj4+
ICsgICAgfQ0KPj4gKw0KPj4gKyAgICBzY21pX2RhdGEuaW5pdGlhbGl6ZWQgPSB0cnVlOw0KPj4g
KyAgICBnb3RvIG91dDsNCj4+ICsNCj4+ICtlcnJvcjoNCj4+ICsgICAgdW5tYXBfY2hhbm5lbF9t
ZW1vcnkoY2hhbm5lbCk7DQo+PiArICAgIGZyZWVfY2hhbm5lbF9saXN0KCk7DQo+PiArb3V0Og0K
Pj4gKyAgICByZXR1cm4gcmV0Ow0KPj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgY29uc3Qgc3RydWN0
IGR0X2RldmljZV9tYXRjaCBzY21pX3NtY19tYXRjaFtdIF9faW5pdGNvbnN0ID0gew0KPj4gKyAg
ICBEVF9NQVRDSF9DT01QQVRJQkxFKCJhcm0sc2NtaS1zbWMiKSwNCj4+ICsgICAgeyAvKiBzZW50
aW5lbCAqLyB9LA0KPj4gK307DQo+PiArDQo+PiArRFRfREVWSUNFX1NUQVJUKHNjbWlfc21jX21h
LCAiU0NNSSBTTUMgTUVESUFUT1IiLCBERVZJQ0VfRklSTVdBUkUpDQo+PiArICAgICAgICAuZHRf
bWF0Y2ggPSBzY21pX3NtY19tYXRjaCwNCj4+ICsgICAgICAgIC5pbml0ID0gc2NtaV9wcm9iZSwN
Cj4+ICtEVF9ERVZJQ0VfRU5EDQo+PiArDQo+PiArLyoNCj4+ICsgKiBMb2NhbCB2YXJpYWJsZXM6
DQo+PiArICogbW9kZTogQw0KPj4gKyAqIGMtZmlsZS1zdHlsZTogIkJTRCINCj4+ICsgKiBjLWJh
c2ljLW9mZnNldDogNA0KPj4gKyAqIHRhYi13aWR0aDogNA0KPj4gKyAqIGluZGVudC10YWJzLW1v
ZGU6IG5pbA0KPj4gKyAqIEVuZDoNCj4+ICsgKi8NCj4+IGRpZmYgLS1naXQgYS94ZW4vaW5jbHVk
ZS9wdWJsaWMvYXJjaC1hcm0uaCBiL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLWFybS5oDQo+PiBp
bmRleCAwOTViMWEyM2UzLi4zMGU0NmRlNmQ3IDEwMDY0NA0KPj4gLS0tIGEveGVuL2luY2x1ZGUv
cHVibGljL2FyY2gtYXJtLmgNCj4+ICsrKyBiL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLWFybS5o
DQo+PiBAQCAtMzI5LDYgKzMyOSw3IEBAIERFRklORV9YRU5fR1VFU1RfSEFORExFKHZjcHVfZ3Vl
c3RfY29udGV4dF90KTsNCj4+DQo+PiAgICNkZWZpbmUgWEVOX0RPTUNUTF9DT05GSUdfQVJNX1ND
SV9OT05FICAgICAgMA0KPj4gICAjZGVmaW5lIFhFTl9ET01DVExfQ09ORklHX0FSTV9TQ0lfU0NN
SV9TTUMgIDENCj4+ICsjZGVmaW5lIFhFTl9ET01DVExfQ09ORklHX0FSTV9TQ0lfU0NNSV9TTUNf
TUEgIDINCj4+DQo+PiAgIHN0cnVjdCB4ZW5fYXJjaF9kb21haW5jb25maWcgew0KPj4gICAgICAg
LyogSU4vT1VUICovDQo+PiBAQCAtMzU1LDYgKzM1Niw4IEBAIHN0cnVjdCB4ZW5fYXJjaF9kb21h
aW5jb25maWcgew0KPj4gICAgICAgdWludDMyX3QgY2xvY2tfZnJlcXVlbmN5Ow0KPj4gICAgICAg
LyogSU4gKi8NCj4+ICAgICAgIHVpbnQ4X3QgYXJtX3NjaV90eXBlOw0KPj4gKyAgICAvKiBJTiAq
Lw0KPj4gKyAgICB1aW50OF90IGFybV9zY2lfYWdlbnRfaWQ7DQo+PiAgIH07DQo+PiAgICNlbmRp
ZiAvKiBfX1hFTl9fIHx8IF9fWEVOX1RPT0xTX18gKi8NCj4+DQo+PiAtLQ0KPj4gMi4zNC4xDQo+
Pg0K


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 12:03:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 12:03:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012957.1391506 (Exim 4.92)
	(envelope-from )
	id 1uPgez-0007V3-Eh; Thu, 12 Jun 2025 12:03:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012957.1391506; Thu, 12 Jun 2025 12: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 1uPgez-0007Uw-By; Thu, 12 Jun 2025 12:03:57 +0000
Received: by outflank-mailman (input) for mailman id 1012957;
 Thu, 12 Jun 2025 12: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 1uPgex-0006fe-Fs
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 12:03:55 +0000
Received: from PA4PR04CU001.outbound.protection.outlook.com
 (mail-francecentralazlp170130007.outbound.protection.outlook.com
 [2a01:111:f403:c20a::7])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4e939802-4785-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 14:03:53 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by DU2PR03MB8075.eurprd03.prod.outlook.com (2603:10a6:10:2e6::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.22; Thu, 12 Jun
 2025 12:03:48 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%4]) with mapi id 15.20.8769.029; Thu, 12 Jun 2025
 12:03: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: 4e939802-4785-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=UreY6g9cbYiZ/HbDd8jSXxV1/B7DPMLguMMgGAzPQh4Br0kXXlgGJl7L7HE0YZouzUNiSnBHeI9Eo2dA9XLMD+Yd+kLWtOEIqnpTAxrImwTnQ4I+51Omztk0ZGHsjNZWbS5s+LLvFXWHnshW4lP0MK5DDhC+oZUkBmk1ACKegcthkEnI77nfmmtICHhbFxZRakdoTYcNmQEtEW+piba3RCP+6mzVU4dAwuKYIh3j0QntBjpkwNvHZNCrpCaHz8i+pMc47F8cgkS6K/0IbazYLTte0rwX7s4db0IZSvxnzxaFtqGVrCGVQhArCI7baW1Urmj/4Ky7/BW07wgeaJj9GA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=vChl+Fkj5sH8zrOCA4/8CS7k5EYxz1lYSBTgDqOFJZ0=;
 b=vE2jjTkGex7gCIxgCUc8UekkrNeJczVLM/dDBadI+I/QoQoNQoRb7A38kQzKid6dv5jW1a5IbvLLVXk+Ytqnc11KtsVZUu6tdzEeb5J6STjr4ioVevXLEG4C2ZuK/0JBO0tzDTyo/yBk8rjujQn1mYVEZ8dOOdiece2JAJQp0iLr0VhS1Mx0WKRxjQWk7deFsmr2KV6to8ngfjRhYwq8OxNl9lzPYOaWNr7J57zKmVj89pr6y30VEIQkHEj2kS8+Tmc/Wd7J16kvUR1cmob3l1NoPC2JZp8L6td+Y81b8gFPU6sb59Kg6Pfm9Z2DOO1djOVL9qAH+hhq0NpbaUjrcg==
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=vChl+Fkj5sH8zrOCA4/8CS7k5EYxz1lYSBTgDqOFJZ0=;
 b=eH6C6U6kA3dyBK/1hR2Q5srAxHST0EAmpZej4YUFTv/1BYXyl3efJQRDrq+6AqZNSUgt9Rpp8kSUbV9BbZMwy9hAy5jTxoz2FAdjucmzuoVV1C2sAOawgu6qiGg7vug+BZl5z/ccYUtMEgvKAx/kQZn8Z34bZEV1zb2LAw5Gpon6RIJHB3cSsMfrSgDTYe5B4dOECR+EefPGDMOZGXsMvOfM1+hd7DzOomNIayiqlP0OEGGX04dDqb55QajIcG0hLgBOrOLK05/X0F4+LqRRVDMD9eYzzhUOV+NocyizGZW6znF+7+pFRWUwadx0+K/5sofSbeAKkNa/FrGEV4Fm1A==
From: Oleksii Moisieiev 
To: Stefano Stabellini 
CC: "xen-devel@lists.xenproject.org" , Andrew
 Cooper , Anthony PERARD
	, Bertrand Marquis , Jan
 Beulich , Juergen Gross , Julien Grall
	, Michal Orzel ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Volodymyr
 Babchuk , Grygorii Strashko
	
Subject: Re: [RFC PATCH v4 8/8] docs: arm: proposal to add separate SCMI node
 for Xen agent
Thread-Topic: [RFC PATCH v4 8/8] docs: arm: proposal to add separate SCMI node
 for Xen agent
Thread-Index: AQHbyNXQTZOEYVEinUiuxBk1KdhKoLPgrlAAgB7kHoA=
Date: Thu, 12 Jun 2025 12:03:47 +0000
Message-ID: 
References: 
 <3f7e1e99f5d1018064f3c4825aff16bd487cf558.1747669845.git.oleksii_moisieiev@epam.com>
 
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: PAVPR03MB8946:EE_|DU2PR03MB8075:EE_
x-ms-office365-filtering-correlation-id: 1d4abf68-31cc-4bb5-4c84-08dda9a93036
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|366016|1800799024|7416014|376014|3613699012|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?NndnSmZrWkVWOHRQMy9RMFV5ak0waGVjYXJ4Yi9HQ1JPN3pobE8rU0p4NTBT?=
 =?utf-8?B?M21rd09EanZPUjE2SFFZSmxQQ09FV0RFVjF5T3JtK0RQcWc3eEc1WUlqbTZK?=
 =?utf-8?B?Ym5Md2xQLzhsZGRGUm5ETTdBaUxNbEZWcWl5cDNVY3lQSWJsNnVMRXM2em1P?=
 =?utf-8?B?YXBnMGxSenMzQmtqV0ZOeExISnVYdStLSjQ4aS80M21oY1hIRk9rV3o5Y2FL?=
 =?utf-8?B?d1Yydi9DN1hpSHVFMStiQTNHV21EWW1uYzQ4Q1Fkb0xMUFBNNmcrK0M5TDE1?=
 =?utf-8?B?TG40UFFnaEFBaFVreWZJQkhPTFNpQnV3U2Z1QlJ1QXczbi91bHdubzJIMGJn?=
 =?utf-8?B?ck5KUDA4YzVISk5HSDF0R3loL0hIZmFkWUpoOEE0TmJkKzBNZWRRdDVjV0Er?=
 =?utf-8?B?MUh3UUphcHR3Z3FSR2RmSHF2c3dtWEJYNEdtK2kwcHprUGlNRlpmQ25wbUJq?=
 =?utf-8?B?Zi9oQ09md0FBUUk1NGNVd0F6R3BicHAyYWx2RDNrQzE1ZlhOMlJVdzVFbFU3?=
 =?utf-8?B?aGpwcllEWnJyUjd2Umo1UUJlUWw0cW5kOERsQzBpYnJYOUU3VUhZRnZOZkhT?=
 =?utf-8?B?Nm9zNzI4eVRoZjJSU3FwdVFwVUNKMXlIR0lxejFrMEkvc09YYnFLd0JOZnVW?=
 =?utf-8?B?c0YyTFJERHpZUXdoRkh1UjNOcW55bEVzNG90UCtEN0laUURidU5NZ2VqUXkx?=
 =?utf-8?B?eHJ5cGUzbktJSnBURjVtZWQycWNpVDhGZmZlM0dPTERtc2NkYW5mR09vdmlU?=
 =?utf-8?B?ODdGdmF2dk5qcWxyVno2bWZWVnFlWUJkaDN1R0hoQkptWjAyWDh6Y21INkJ0?=
 =?utf-8?B?azZJb2RvNkRTaU9qZ1FNWFBJem1FeGdjV2lJbEFVeFlReVQrYy91ZGsyMzFa?=
 =?utf-8?B?aXdrWjJLTFluSkhFcUZTQ3V3Zi8vUktERElpTFRwcHQ4Q3ljU2V0eGMxdHVD?=
 =?utf-8?B?alNjU1JCMDhPSE1EcXJ6QmpONWxnWVNuclkvYXpSWklBK1lXOUZOT0pNRUhj?=
 =?utf-8?B?dmF1K1l3UU5ZcjNxa25YZjg3cXU2WEpwUDN4eGhYN0dQekw0MmYzbUp3c0tQ?=
 =?utf-8?B?MVFJUE5KUkRPem9qZjZFcWxSeWpRUDFKTFRodkpKSEhwbHlaTjlxYTd4OGxG?=
 =?utf-8?B?elF0dUdaNzdkY2tSVmFFdUUyZ3hUN2VuMnBPN1BzdFAyZlpxZENNWXpjSm0x?=
 =?utf-8?B?NndGREJEK3VSUnJkWlNBcFpQUkp5UDNXSkRHd2M3Q01UOHkvS1U1U3hIeUYz?=
 =?utf-8?B?YkFvcTlNNEJiSEV2aFNGOVFYdUh2endIMkVKcS9FVnZDN2VlS3NvQ0kzUDJ6?=
 =?utf-8?B?OUdkQXArd2prZmo3Qisra2tmT3c0Q2swNERTMElDR2xIM05PMG50SjVNakxo?=
 =?utf-8?B?cVJvNWNPS2drbTZKcmlGTEl4aW5IOXY3TVZycnNtUjJaUm5uNHNHd2pSWk9N?=
 =?utf-8?B?WDVoWGNaTEpLOVpSV3o5UzUzRjJqVjh4R25RUGpHSWdOa29qbXROeDBvOHpP?=
 =?utf-8?B?MXZSTlZjOXIxUGQ1WldjcWYvaHFtVlFVdk52Q0U4bEtOMk8vNUZpSjFkQ1hF?=
 =?utf-8?B?WjEyOWllSm96alZwM2xSdk1qOTI4Y2o4bG1SMmFyajJZTXBaa081Q01rc2xF?=
 =?utf-8?B?TFFPOFNIaXJrSmR1eittU1psOVlnMkluQ0Z2VFFMTXBLNVZvVmxxTmlkelYz?=
 =?utf-8?B?ZVpCRlNLcEFKMFJXSmFJQVA4d0h4R3poMDM5bHd2b1RmakRiVzB0cjJyaCtD?=
 =?utf-8?B?b0kwWE9YQU9JZElDL0hYRzJEdnlUT00wbVlBUWwwTnBMZGoxWmJlZXJDQzYv?=
 =?utf-8?B?ckZlaDE2VHY3cjFaemFDb0d2VXlLSmRuTW4xNnFaMHRkdXc4RWNmNm9zdG9U?=
 =?utf-8?B?SVYxT3NJcUZCWVNaQXJxTGRrd2dJK1hoTlpWQml4dEY0cVdKOTdvdlZwYjgy?=
 =?utf-8?B?ZTVTV1RqMHZEY1drQk54OC9uaVZtYkY2TW83RklicndqT1JHZ3dvam1hdGsy?=
 =?utf-8?B?RjBMUHdsMlVQNS9xUkI5M0NTVTJTWmtQUFNiMzJxL3FBQUYyeHZCeGJpSXBC?=
 =?utf-8?Q?aV0fdb?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(7416014)(376014)(3613699012)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?eVB0emUxSVU2L1grVTErRzR2ek1IWVkxaGZGZCtqSDRuY2hUeTVhS0N3aHd2?=
 =?utf-8?B?OURWL2RKcmxYRzAvRDBGWmcwdjdQbUt3RGhINHRjQy9rak9aZjhoc1ZIV3BV?=
 =?utf-8?B?MVpham9jUFF1Yms2RVJuMXFrQ3VQT0RXMGgzUkdoOEtVd3IwRHNlQ2E4eXcw?=
 =?utf-8?B?TXNJR0NSeklpN0lDTTFRMG1qRHNKdlJjeTVxbGg3d3o1WitvUUxHSGNGRUhC?=
 =?utf-8?B?ODdIbjFnWmF6Q0JGdGI4L3BkV210R0wzVllRQUlPTnZxWjlPRFEwMVp5dUcr?=
 =?utf-8?B?RWJnSmloaGtVcGQ1NTZra056T2RSUXlDWnpEWngrUVNmSHJLMGlqQ3BOdlVK?=
 =?utf-8?B?SVI2clZzWXBWczdPcnkzU3k1dDNzWGxpRi9aY1VmYnE5NU92eFJCRVNHOTlt?=
 =?utf-8?B?Vy8zWE0wOGdVMnpMSVNBVHltdm1EUUM4SlBkRW5SeEp6OERKZm9tVmVpSXB4?=
 =?utf-8?B?OHJHVXhvR0drOTFkdFFPUm5XZDJJd3BVZFlVSDFCK1dNaitYdmQ5L3VjOWJm?=
 =?utf-8?B?RU5IKzZLMnpDWVVyUVZKR0JIdy9lRmxtRS9JMWpwRE5WbWRCeUQ5TElhb3dp?=
 =?utf-8?B?bUNJTEo4OVhQY3F1RlZKaE9rWlo2MWhDbW1MNzBLWGxFcHFVMmlhZzJjeVE5?=
 =?utf-8?B?TnhKTTZoSC9FVGNFSjN1Z3JsVnNFaWJrbGtLMVNSZXFMRVVGQjVWRmlqQlFk?=
 =?utf-8?B?UGFWRFY5RjM1eHhKcEpnaHBtcm9sNy9KK29zeXFteTliNFNCeDZUemhQMjlx?=
 =?utf-8?B?OHROZVZwVWg0OTlFc1p4WVE2MWlZSWlzb3FDUjZsclV4NVdIcGpwb3BKRGY2?=
 =?utf-8?B?TEtVZ3ovVE1vVFB5S3J3ckt2RFRRUlB6eHpsdmk4K1k4M0xQTWdJYXgxay8y?=
 =?utf-8?B?cFBLYTJ4eXpIUHdCMzlSU1VVRnp6TnNUa21FaDJLR25ZVER3MzExbzR3VHYy?=
 =?utf-8?B?ai8xSllQZDVoeGJRdVpTVVJFUktCaDRaKzNsT0hraEcvcUE2czR2UW5reWRM?=
 =?utf-8?B?K3IxNWJhTUwxWVd0c21zeitTSnFWTDdxRFBGMXlaczh1MkxaMmtHRDhZNTdS?=
 =?utf-8?B?bFJiS3JiMm5INWxReWJLbWNvRFpDWE1XVklrVlk3cEFJWTIvSEY5a2s2WHpW?=
 =?utf-8?B?NmQ4Ujc3aDRpLzlZMitWdmQzUTlvWDlicmd2ZmR2R3FBTGg3TW5PM2FQbVJM?=
 =?utf-8?B?UDJ2SjVDbjFERitxUVpsM2R1SGtCY0VvQ1ZNRjFvTXAzaWZhUS8zNkZtcVB6?=
 =?utf-8?B?SFZ1N2x6MDR3VngvYlB4RnhXMStQREhBSkYyZkhJQ1Rxd25pZDgzVXd5dHFy?=
 =?utf-8?B?RzNyd1VLR1NMeTFpMFFUSVIzMUdwNG50NWpsRjJ2NEN4Rlp3d0ZKaS8wUm5p?=
 =?utf-8?B?czR3Q2pBTGdpdXRyRVpGa2IrY1huaCtoWkQwSC9hcThlQUY4WGUzT1A3MWdI?=
 =?utf-8?B?NDhWMllPUHJjbXVqbmxHa05BUTV1L0JoaFpja2Q5VWJSaFpmUVNaei9qdk1v?=
 =?utf-8?B?WkJVMThlRmE2TXNBdEVRSlUvdXpqR1hWanVLWlhZY0ZEam1KWDlGMU02bGtW?=
 =?utf-8?B?YWhHaEJSS1NMdGgwYmpiclJZVU9TVm9NZ2hXcmcydlJLQmphZUJ4THA3VWo1?=
 =?utf-8?B?Z1RPa0tjWnNBRFYvbVh5eHFtdFVhaTBFYU5aV3QvL3hpYUszeE1EYm5oVGp2?=
 =?utf-8?B?cklhTGp6dGxYNDBQcFVJK2RBMU5BSmVCMk81OTZsSEo1R24yeHZaWEhENU1i?=
 =?utf-8?B?VDFPNnlzM3VBaEZvUThmL05PbkMyRFdEK0d2cFhHbTBlOW5HRUsyNUJrZVZu?=
 =?utf-8?B?VXZIekFMUFFsUXlHTlJ2cHVsN0FjbFRCejEzQTFSNVR3V2NYMlRGUi9WNHhm?=
 =?utf-8?B?dUF1Q3JNVmREL2xzTVNHQm15bVIwM1BOdlJRQWJTckx1OUZXNWgwOVd6MCtL?=
 =?utf-8?B?TGlxQ2NRb2YydlhaWHlTRE5sL0RNT1E2M1Joa0V4NHVQNUkvWGdmRHY0b0Er?=
 =?utf-8?B?U3JOOC9YWks3U1NqUWhORXRNS3JkUWs4Y09EaElZc2pyYXZKeWl6VlRzTkNi?=
 =?utf-8?B?STlWSENJWmVaMU5rUjcrU2s1TmNFR3VvUC9nWCt4SVlpQmU0czBXTWd3UU5z?=
 =?utf-8?B?QXlZeks0a0FXdjN6VHpPZjcwaXNST3lSS0dyU09meitRTW1ObDlMTUVyWFB6?=
 =?utf-8?B?OFE9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <42E0EAE1DB21DC41981B2146415B6012@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: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1d4abf68-31cc-4bb5-4c84-08dda9a93036
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2025 12:03:47.9343
 (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: WkhUbxEwNC1d3JkMtQLloR8yi7JAEHac11k5GOzv1SU5y/N9VTjlNYvcQKEPnCD2uGSzb4Qv2QHxPXL7aQCkYdRQpFW2eZvRaKUDdceKKv8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU2PR03MB8075

DQpPbiAyMy8wNS8yMDI1IDIzOjE5LCBTdGVmYW5vIFN0YWJlbGxpbmkgd3JvdGU6DQo+IE9uIE1v
biwgMTkgTWF5IDIwMjUsIE9sZWtzaWkgTW9pc2llaWV2IHdyb3RlOg0KPj4gRnJvbTogR3J5Z29y
aWkgU3RyYXNoa288Z3J5Z29yaWlfc3RyYXNoa29AZXBhbS5jb20+DQo+Pg0KPj4gUHJvcG9zYWwg
ZGVzY3JpcHRpb24gdG8gYWRkIHNlcGFyYXRlIFNDTUkgRFQgbm9kZSBmb3IgWGVuIG1hbmFnZW1l
bnQgYWdlbnQNCj4+IHVuZGVyICJjaG9zZW4iIG9yIHhlbi1jb25maWcgbm9kZSwgbGlrZSBIeXBl
cmxhdW5jaCAieGVuLGNvbmZpZyIuDQo+IEkgdGhpbmsgaXQgaXMgT0sgdG8gcGxhY2UgYSBsYXJn
ZXIgInhlbixjb25maWciIG5vZGUgdW5kZXIgL2Nob3NlbiB3aXRoDQo+IG1vcmUgaW5mb3JtYXRp
b24gZm9yIFhlbiB0byBzZXR1cCBTQ01JIG1vcmUgZWFzaWx5Lg0KPg0KPg0KPj4gVGhpcyBwcm9w
b3NhbCBpbnRyb2R1Y2VzIGEgbmV3IGFwcHJvYWNoIHRvIHRoZSBYZW4gbXVsdGktZG9tYWluDQo+
PiBjb25maWd1cmF0aW9uLCB3aGVyZSBhbGwgWGVuLXNwZWNpZmljIGNvbmZpZ3VyYXRpb24gaGFz
IGJlZW4gbW92ZWQNCj4+IHVuZGVyIHRoZSAiL2Nob3NlbiIgbm9kZS4gVGhpcyByZXF1aXJlcyBs
ZXNzIERvbTAgZGV2aWNlIHRyZWUNCj4+IG1hbmlwdWxhdGlvbiBhbmQgaXNvbGF0ZXMgWGVuIGNv
bmZpZ3VyYXRpb24gZnJvbSBkb21haW4gY29uZmlndXJhdGlvbi4NCj4+DQo+PiBUaGlzIGFwcHJv
YWNoIHByb3ZpZGVzIHRoZSBmb2xsb3dpbmcgZGV2aWNlIHRyZWUgKERUKSBwYXJhbWV0ZXJzOg0K
Pj4NCj4+IC0gInhlbixzY21pLXNlY29uZGFyeS1hZ2VudHMiOiBBIFhlbi1zcGVjaWZpYyBwYXJh
bWV0ZXIgdW5kZXIgdGhlDQo+PiAiL2Nob3NlbiIgbm9kZSwgd2hpY2ggZGVzY3JpYmVzIHRoZSBT
Q01JIGFnZW50IGNvbmZpZ3VyYXRpb24gZm9yDQo+PiB0aGUgZG9tYWlucy4NCj4+IC0gdGhlIFND
TUkgY29uZmlndXJhdGlvbiBmb3IgWGVuIChwcml2aWxlZ2VkIGFnZW50KSBhbmQgdGhlIHNoYXJl
ZA0KPj4gbWVtb3J5IGNvbmZpZ3VyYXRpb24gZm9yIGFsbCBhZ2VudHMgYXJlIHByb3ZpZGVkIHVu
ZGVyIHRoZSAiL2Nob3NlbiINCj4+IG5vZGUgYW5kIGFyZSB1c2VkIHN0cmljdGx5IGJ5IFhlbiBm
b3IgaXRzIGluaXRpYWwgY29uZmlndXJhdGlvbi4NCj4+IC0gdGhlIHNjbWlfc2htIGFuZCBTQ01J
IGNvbmZpZ3VyYXRpb24gZm9yIERvbTAgYXJlIHBsYWNlZCBpbiB0aGUNCj4+ICIvZmlybXdhcmUv
c2NtaSIgbm9kZSBzbyB0aGF0IHRoZXkgY2FuIGJlIG1vdmVkIHRvIERvbTAgd2l0aG91dA0KPj4g
YW55IGNoYW5nZXMuDQo+IElzbid0IHRoZSBTQ01JIGNvbmZpZ3VyYXRpb24gcHJlc2VudCBpbiAv
ZmlybXdhcmUvc2NtaSByZWZlcnJpbmcgdG8gdGhlDQo+IHByaXZpbGVnZWQgYWdlbnQ9MCBtZWFu
dCB0byBiZSB1c2VkIGJ5IFhlbj8NCj4NCj4gSSBjZXJ0YWlubHkgc2VlIGJlbmVmaXRzIGluIHNp
bXBsaWZ5aW5nIHRoZSBjb25maWd1cmF0aW9uIGFuZCBlc3BlY2lhbGx5DQo+IHJlZHVjaW5nIHRo
ZSBhbW91bnQgb2YgY2hhbmdlcyBhIHVzZXIgbWlnaHQgaGF2ZSB0byBtYWtlIG9uIHRoZQ0KPiB1
bmRlcmx5aW5nIGRldmljZSB0cmVlLCBidXQgaWYgdGhlIHVzZXIgbmVlZHMgdG8gY2hhbmdlIC9m
aXJtd2FyZS9zY21pDQo+IHdpdGggdGhlIERvbTAgaW5mb3JtYXRpb24sIGl0IHNlZW1zIG1vcmUg
ZGFuZ2Vyb3VzIGFuZCBlcnJvciBwcm9uZSB0aGFuDQo+IHRoZSBwcmV2aW91cyBhcHByb2FjaC4N
Cj4NClRoZSBpZGVhIGlzIHRvIG1vdmUgdGhlIHByaXZpbGVnZWQgYWdlbnQ9MCBjb25maWd1cmF0
aW9uIHRvIHRoZSAvY2hvc2VuIA0Kbm9kZSBhbmQNCg0KYXNzaWduIGFnZW50PTEgdG8gdGhlIERv
bTAgbm9kZSB1bmRlciAvZmlybXdhcmUvc2NtaS4NCg0KQmVuZWZpdHMgb2YgVGhpcyBBcHByb2Fj
aDoNCi0gTm8gTW9kaWZpY2F0aW9uIG9mIHRoZSBYZW4gRFQgTm9kZSBSZXF1aXJlZA0KDQogwqDC
oMKgIFRoaXMgZWxpbWluYXRlcyB0aGUgbmVlZCB0byBtb2RpZnkgdGhlIFhlbiBEZXZpY2UgVHJl
ZSAoRFQpIG5vZGUgDQpiZWZvcmUgY3JlYXRpbmcgRG9tMCBpbg0KDQogwqDCoMKgIG9yZGVyIHRv
IHNldCB0aGUgY29ycmVjdCBzaGFyZWQgbWVtb3J5IChzaG1lbSkuDQoNCi1Db25zaXN0ZW50IFND
TUkgQ29uZmlndXJhdGlvbiBGb3JtYXQNCg0KIMKgIFRoZSBEb20wIERUIHdpbGwgaGF2ZSB0aGUg
c2FtZSBTQ01JIGNvbmZpZ3VyYXRpb24gZm9ybWF0IGFzIG90aGVyIA0KZG9tYWlucywgc2ltcGxp
ZnlpbmcgdGhlDQoNCiDCoCBvdmVyYWxsIGNvbmZpZ3VyYXRpb24gcHJvY2Vzcy4NCg0KLSBVbmlm
aWVkIFNDTUkgQ29uZmlndXJhdGlvbiBNZXRob2QNCg0KIMKgwqAgVGhlcmUgd2lsbCBubyBsb25n
ZXIgYmUgYSBuZWVkIHRvIHVzZSBhIGRpZmZlcmVudCBhcHByb2FjaCBmb3IgU0NNSSANCmNvbmZp
Z3VyYXRpb24gaW4gRG9tMA0KDQogwqAgY29tcGFyZWQgdG8gb3RoZXIgZG9tYWlucy4NCg0KLSBT
ZXBhcmF0aW9uIEJldHdlZW4gRG9tMCBhbmQgUHJpdmlsZWdlZCBOb2RlDQoNCiDCoMKgwqDCoMKg
IFRoaXMgcHJvdmlkZXMgYSBjbGVhciBzZXBhcmF0aW9uIGJldHdlZW4gdGhlIERvbTAgbm9kZSBh
bmQgdGhlIA0KcHJpdmlsZWdlZCBub2RlLg0KDQogwqDCoMKgwqDCoCBGb3IgZXhhbXBsZToNCiDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgIElmIERvbTAgb25seSByZXF1aXJlcyB0aGUgY2xvY2sgcHJv
dG9jb2wsIGJ1dCB0aGUgWGVuIFNDTUkgDQpjb25maWd1cmF0aW9uIHJlcXVpcmVzIGFkZGl0aW9u
YWwgcHJvdG9jb2xzLA0KDQogwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB0aGlzIGFwcHJvYWNoIGFs
bG93cyBEb20wIHRvIHJlY2VpdmUgb25seSB0aGUgbmVjZXNzYXJ5IA0KcHJvdG9jb2wgY29uZmln
dXJhdGlvbi4NCg0KPj4gVGhpcyBjb25maWd1cmF0aW9uIGFsbG93cyB0aGUgdXNlIG9mIFhlbi1z
cGVjaWZpYyBub2RlcyB0byBwcm92aWRlDQo+PiBpbmZvcm1hdGlvbiBzdHJpY3RseSBuZWVkZWQg
YnkgWGVuIHdoaWxlIHVzaW5nIHRoZSBkZWZhdWx0IFNDTUkNCj4+IGNvbmZpZ3VyYXRpb24gZm9y
IERvbTAgYW5kIG90aGVyIGRvbWFpbnMuIEFzIGEgcmVzdWx0LCBubyBhZGRpdGlvbmFsDQo+PiBi
aW5kaW5ncyBuZWVkIHRvIGJlIGludHJvZHVjZWQgdG8gdGhlIGRldmljZSB0cmVlLg0KPiBUaGlz
IGlzIG5vdCBhY3R1YWxseSBpbXBsZW1lbnRlZCBieSB0aGlzIHBhdGNoIHNlcmllcywgcmlnaHQ/
DQpJdCBpcyBub3QuIEp1c3QgcG9zdGVkIHRoaXMgZG9jdW1lbnQgYXMgYSBwcm9wb3NhbC4NCj4+
IFNpZ25lZC1vZmYtYnk6IEdyeWdvcmlpIFN0cmFzaGtvPGdyeWdvcmlpX3N0cmFzaGtvQGVwYW0u
Y29tPg0KPj4gU2lnbmVkLW9mZi1ieTogT2xla3NpaSBNb2lzaWVpZXY8b2xla3NpaV9tb2lzaWVp
ZXZAZXBhbS5jb20+DQo+PiAtLS0NCj4+DQo+Pg0KPj4NCj4+ICAgLi4uL2FybS9maXJtd2FyZS9h
cm0tc2NtaS1wcm9wb3NhbC5yc3QgICAgICAgIHwgMjI0ICsrKysrKysrKysrKysrKysrKw0KPj4g
ICAxIGZpbGUgY2hhbmdlZCwgMjI0IGluc2VydGlvbnMoKykNCj4+ICAgY3JlYXRlIG1vZGUgMTAw
NjQ0IGRvY3MvaHlwZXJ2aXNvci1ndWlkZS9hcm0vZmlybXdhcmUvYXJtLXNjbWktcHJvcG9zYWwu
cnN0DQo+Pg0KPj4gZGlmZiAtLWdpdCBhL2RvY3MvaHlwZXJ2aXNvci1ndWlkZS9hcm0vZmlybXdh
cmUvYXJtLXNjbWktcHJvcG9zYWwucnN0IGIvZG9jcy9oeXBlcnZpc29yLWd1aWRlL2FybS9maXJt
d2FyZS9hcm0tc2NtaS1wcm9wb3NhbC5yc3QNCj4+IG5ldyBmaWxlIG1vZGUgMTAwNjQ0DQo+PiBp
bmRleCAwMDAwMDAwMDAwLi5mY2MyZWQyYjY1DQo+PiAtLS0gL2Rldi9udWxsDQo+PiArKysgYi9k
b2NzL2h5cGVydmlzb3ItZ3VpZGUvYXJtL2Zpcm13YXJlL2FybS1zY21pLXByb3Bvc2FsLnJzdA0K
Pj4gQEAgLTAsMCArMSwyMjQgQEANCj4+ICsNCj4+ICtQcm9wb3NhbCBmb3IgU0NNSSBtdWx0aS1h
Z2VudCBkcml2ZXIgYmluZGluZ3MNCj4+ICs9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT0NCj4+ICsNCj4+ICtOb3cgdGhlIFhlbiBjb25maWd1cmF0aW9uIGZvciBT
Q01JIG11bHRpLWFnZW50IHN1cHBvcnQgaXMgZG9uZSBpbiBhIGJpdCBjb21wbGljYXRlZCB3YXks
IGVzcGVjaWFsbHkNCj4+ICtmcm9tIFNDTUkgbXVsdGktYWdlbnQgZHJpdmVyIGluaXRpYWxpemF0
aW9uIGFuZCBEb20wIERUIG1hbmlwdWxhdGlvbiBwb2ludCBvZiB2aWV3Lg0KPj4gK0Fsc28gaXQg
ZG9lcyBub3QgdGFrZSBpbnRvIGFjY291bnQgZnV0dXJlIHJlcXVpcmVtZW50cyB0byBzdXBwb3J0
IFNDUCBTQ01JIEZXLg0KPj4gKw0KPj4gK1RvIGVuYWJsZSBTQ01JIG11bHRpLWFnZW50IHVzZXIg
bmVlZDoNCj4+ICsNCj4+ICsqIHRha2UgaG9zdCBEVCB3aXRoIGJhc2ljIFNDTUkgZW5hYmxlZA0K
Pj4gKyogYWRkIFNDTUkgc2hhcmVkLW1lbW9yeSBub2RlcyBmb3IgYWxsIGFnZW50cw0KPj4gKyog
dXBkYXRlIFNDTUkgbm9kZSB0byBwb2ludCBvbiBTQ01JIFhlbiBtYW5hZ2VtZW50IGNoYW5uZWwg
KGBgW3NtYy1pZCwgc2htZW1dYGApDQo+PiArKiBhZGQgInhlbixzY21pLXNlY29uZGFyeS1hZ2Vu
dHMiIHByb3BlcnR5IHRvIHRoZSAiXGNob3NlbiIgbm9kZQ0KPj4gKw0KPj4gKy4uIGNvZGU6Og0K
Pj4gKw0KPj4gKyAgIGNob3NlbiB7DQo+PiArICAgICAgeGVuLHNjbWktc2Vjb25kYXJ5LWFnZW50
cyA9IDwNCj4+ICsgICAgICAgICAgICAgICAgICAgIDEgMHg4MjAwMDAwMyAmc2NtaV9zaG1fMQ0K
Pj4gKyAgICAgICAgICAgICAgICAgICAgMiAweDgyMDAwMDA0ICZzY21pX3NobV8yDQo+PiArICAg
ICAgICAgICAgICAgICAgICAzIDB4ODIwMDAwMDUgJnNjbWlfc2htXzMNCj4+ICsgICAgICAgICAg
ICAgICAgICAgIDQgMHg4MjAwMDAwNiAmc2NtaV9zaG1fND47DQo+PiArICAgIH0NCj4+ICsNCj4+
ICsgICAgL3sNCj4+ICsgICAgICAgICAgICAvLyBTQ01JIHNoYXJlZC1tZW1vcnkgbm9kZXMgZm9y
IGFsbCBhZ2VudHMNCj4+ICsgICAgICAgICAgICBzY21pX3NobV8wIDogc3JhbUA0N2ZmMDAwMCB7
DQo+PiArICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0KPj4g
KyAgICAgICAgICAgICAgICByZWcgPSA8MHgwIDB4NDdmZjAwMDAgMHgwIDB4MTAwMD47DQo+PiAr
ICAgICAgICAgICAgfTsNCj4+ICsgICAgICAgICAgICBzY21pX3NobV8xOiBzcmFtQDQ3ZmYxMDAw
IHsNCj4+ICsgICAgICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0i
Ow0KPj4gKyAgICAgICAgICAgICAgICAgICAgcmVnID0gPDB4MCAweDQ3ZmYxMDAwIDB4MCAweDEw
MDA+Ow0KPj4gKyAgICAgICAgICAgIH07DQo+PiArICAgICAgICAgICAgc2NtaV9zaG1fMjogc3Jh
bUA0N2ZmMjAwMCB7DQo+PiArICAgICAgICAgICAgICAgICAgICBjb21wYXRpYmxlID0gImFybSxz
Y21pLXNobWVtIjsNCj4+ICsgICAgICAgICAgICAgICAgICAgIHJlZyA9IDwweDAgMHg0N2ZmMjAw
MCAweDAgMHgxMDAwPjsNCj4+ICsgICAgICAgICAgICB9Ow0KPj4gKyAgICAgICAgICAgIHNjbWlf
c2htXzM6IHNyYW1ANDdmZjMwMDAgew0KPj4gKyAgICAgICAgICAgICAgICAgICAgY29tcGF0aWJs
ZSA9ICJhcm0sc2NtaS1zaG1lbSI7DQo+PiArICAgICAgICAgICAgICAgICAgICByZWcgPSA8MHgw
IDB4NDdmZjMwMDAgMHgwIDB4MTAwMD47DQo+PiArICAgICAgICAgICAgfTsNCj4+ICsgICAgICAg
ICAgICBzY21pX3NobV80OiBzcmFtQDQ3ZmY0MDAwIHsNCj4+ICsgICAgICAgICAgICAgICAgICAg
IGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0KPj4gKyAgICAgICAgICAgICAgICAgICAg
cmVnID0gPDB4MCAweDQ3ZmY0MDAwIDB4MCAweDEwMDA+Ow0KPj4gKyAgICAgICAgICAgIH07DQo+
PiArDQo+PiArICAgICAgICAgICAgZmlybXdhcmUgew0KPj4gKyAgICAgICAgICAgICAgICBzY21p
OiBzY21pIHsNCj4+ICsgICAgICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWkt
c21jIjsNCj4+ICsgICAgICAgICAgICAgICAgICAgIGFybSwgc21jIC0gaWQgPSA8MHg4MjAwMDAw
Mj47IDwtLS0gWGVuIG1hbmFnZW1lbnQgYWdlbnQgY2hhbm5lbCAic21jLWlkIg0KPj4gKyAgICAg
ICAgICAgICAgICAgICAgI2FkZHJlc3MtY2VsbHMgPSA8IDE+Ow0KPj4gKyAgICAgICAgICAgICAg
ICAgICAgI3NpemUtY2VsbHMgPSA8IDA+Ow0KPj4gKyAgICAgICAgICAgICAgICAgICAgI2FjY2Vz
cy1jb250cm9sbGVyLWNlbGxzID0gPCAxPjsNCj4+ICsgICAgICAgICAgICAgICAgICAgIHNobWVt
ID0gPCZzY21pX3NobV8wPjsgPC0tLSBYZW4gbWFuYWdlbWVudCBhZ2VudCBjaGFubmVsICJzaG1l
bSINCj4+ICsNCj4+ICsgICAgICAgICAgICAgICAgICAgIHByb3RvY29sQFh7DQo+PiArICAgICAg
ICAgICAgICAgICAgICB9Ow0KPj4gKyAgICAgICAgICAgICAgICB9Ow0KPj4gKyAgICAgICAgICAg
IH07DQo+PiArICAgIH0NCj4+ICsNCj4+ICtJbXBvcnRhbnQgdGhpbmcgdG8gbm90ZSBpcyB0aGF0
IGFsbCBpbmZvcm1hdGlvbiBhYm91dCBtdWx0aS1jaGFubmVsIHN1cHBvcnQgaXMgc3RyaWN0bHkg
WGVuIHNwZWNpZmljLg0KPj4gKw0KPj4gK0R1cmluZyBpbml0aWFsaXphdGlvbiB0aGUgU0NNSSBt
dWx0aS1hZ2VudCBkcml2ZXIgdXNlcyBIb3N0IERUIFNDTUkgbm9kZSBhbmQNCj4+ICsieGVuLHNj
bWktc2Vjb25kYXJ5LWFnZW50cyIgcHJvcGVydHkgdG8gaW5pdCBpdHNlbGYgYW5kIHRoZW4sIGR1
cmluZyBEb20wIGNyZWF0aW9uLCBtYW5pcHVsYXRlcw0KPj4gK0RvbTAgRFQgdG8gcmVtb3ZlIFhl
biBzcGVjaWZpYyBTQ01JIGluZm8gYW5kIHVwZGF0ZSBkb20wIFNDTUkgbm9kZXMgd2l0aCBEb20w
IFNDTUkgYWdlbnQgc3BlY2lmaWMNCj4+ICtpbmZvcm1hdGlvbi4NCj4+ICsNCj4+ICtUaGVyZSBh
cmUgdHdvIG5lZ2F0aXZlIHBvaW50czoNCj4+ICsNCj4+ICsxKSBEb3VibGUgRFQgbW9kaWZpY2F0
aW9uIC0gb25lIGlzIHVzZXIgdG8gc2V0IHVwIFNDTUkgWGVuIHN1cHBvcnQgaW4gSG9zdCBEVCwg
c2Vjb25kIC0NCj4+ICsgICBEb20wIERUIG1hbmlwdWxhdGlvbi4NCj4+ICsyKSBJbiBjYXNlIG9m
IGZ1dHVyZSBzdXBwb3J0IG9mIG1haWxib3ggc2hhcmVkLW1lbW9yeSB0cmFuc3BvcnQgdGhlcmUg
Y291bGQgYmUgdXAgdG8gNCBtYWlsYm94ZXMgYW5kDQo+PiArICAgdXAgdG8gMiBzaGFyZWQtbWVt
b3JpZXMgcGVyIFNDTUkgYWdlbnQgY2hhbm5lbC4NCj4+ICsNCj4+ICtIZW5jZSBTQ01JIG11bHRp
LWFnZW50IHN1cHBvcnQgaXMgWGVuIHNwZWNpZmljIGtub3dsZWRnZSB0aGVyZSBpcyBhIHByb3Bv
c2FsIHRvIGFkZCBpdCBhcyBYZW4NCj4+ICtzcGVjaWZpYyBEVCBkZWZpbml0aW9ucyBhbmQgc28g
bWluaW1pemUgSG9zdCBhbmQgRG9tMCBEVCBtYW5pcHVsYXRpb25zLg0KPj4gK1Rob3NlIGRlZmlu
aXRpb25zIGNhbiBiZSBhZGRlZCBpbiAiL2Nob3NlbiIgb3IsIGlkZWFsbHksIGluICJ4ZW4sY29u
ZmlnIiBub2RlIChsaWtlIGluIEh5cGVybGF1bmNoIGRlc2lnbikuDQo+PiArDQo+PiArVGhlIFND
TUkgYmluZGluZyBzdGF5cyBnZW5lcmljLCBqdXN0IHR3byBTQ01JIG5vZGVzIGRlZmluZWQgLSBv
bmUgZm9yIFhlbiBtYW5hZ2VtZW50IGNoYW5uZWwgYW5kDQo+PiArb25lIGZvciBIb3N0IERvbTAg
T1NQTS4NCj4+ICsNCj4+ICtFeGFtcGxlIG9mIHVzaW5nICJjaG9zZW4iIGZvciBjb25maWd1cmF0
aW9uOg0KPj4gKw0KPj4gKy4uIGNvZGU6Og0KPj4gKw0KPj4gKyAgICAvew0KPj4gKw0KPj4gKyAg
ICAgICAgY2hvc2VuIHsNCj4+ICsgICAgICAgICAgICAuLi4NCj4+ICsNCj4+ICsgICAgICAgICAg
ICAvLyBYZW4gU0NNSSBtYW5hZ2VtZW50IGNoYW5uZWwNCj4+ICsgICAgICAgICAgICBzY21pX3No
bV8wIDogc3JhbUA0N2ZmMDAwMCB7DQo+PiArICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAi
YXJtLHNjbWktc2htZW0iOw0KPj4gKyAgICAgICAgICAgICAgICByZWcgPSA8MHgwIDB4NDdmZjAw
MDAgMHgwIDB4MTAwMD47DQo+PiArICAgICAgICAgICAgfTsNCj4+ICsgICAgICAgICAgICBzY21p
X3hlbjogc2NtaSB7DQo+PiArICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWkt
c21jIjsNCj4+ICsgICAgICAgICAgICAgICAgYXJtLHNtYy1pZCA9IDwweDgyMDAwMDAyPjsgPC0t
LSBYZW4gbWFuZWdlbWVudCBhZ2VudCBzbWMtaWQNCj4+ICsgICAgICAgICAgICAgICAgI2FkZHJl
c3MtY2VsbHMgPSA8IDE+Ow0KPj4gKyAgICAgICAgICAgICAgICAjc2l6ZS1jZWxscyA9IDwgMD47
DQo+PiArICAgICAgICAgICAgICAgICNhY2Nlc3MtY29udHJvbGxlci1jZWxscyA9IDwgMT47DQo+
PiArICAgICAgICAgICAgICAgIHNobWVtID0gPCZzY21pX3NobV8wPjsgPC0tLSBYZW4gbWFuZWdl
bWVudCBhZ2VudCBzaG1lbQ0KPj4gKyAgICAgICAgICAgIH07DQo+PiArDQo+PiArICAgICAgICAg
ICAgLy8gU0NNSSBtdWx0aS1hZ2VudCBjb25maWd1cmF0aW9uDQo+PiArICAgICAgICAgICAgc2Nt
aV9zaG1fMjogc3JhbUA0N2ZmMjAwMCB7DQo+PiArICAgICAgICAgICAgICAgICAgICBjb21wYXRp
YmxlID0gImFybSxzY21pLXNobWVtIjsNCj4+ICsgICAgICAgICAgICAgICAgICAgIHJlZyA9IDww
eDAgMHg0N2ZmMjAwMCAweDAgMHgxMDAwPjsNCj4+ICsgICAgICAgICAgICB9Ow0KPj4gKyAgICAg
ICAgICAgIHNjbWlfc2htXzM6IHNyYW1ANDdmZjMwMDAgew0KPj4gKyAgICAgICAgICAgICAgICAg
ICAgY29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zaG1lbSI7DQo+PiArICAgICAgICAgICAgICAgICAg
ICByZWcgPSA8MHgwIDB4NDdmZjMwMDAgMHgwIDB4MTAwMD47DQo+PiArICAgICAgICAgICAgfTsN
Cj4+ICsgICAgICAgICAgICBzY21pX3NobV80OiBzcmFtQDQ3ZmY0MDAwIHsNCj4+ICsgICAgICAg
ICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0KPj4gKyAgICAgICAg
ICAgICAgICAgICAgcmVnID0gPDB4MCAweDQ3ZmY0MDAwIDB4MCAweDEwMDA+Ow0KPj4gKyAgICAg
ICAgICAgIH07DQo+PiArICAgICAgICAgICAgeGVuLHNjbWktc2Vjb25kYXJ5LWFnZW50cyA9IDwN
Cj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAxIDB4ODIwMDAwMDMgJnNjbWlfc2htDQo+PiAr
ICAgICAgICAgICAgICAgICAgICAgICAgMiAweDgyMDAwMDA0ICZzY21pX3NobV8yDQo+PiArICAg
ICAgICAgICAgICAgICAgICAgICAgMyAweDgyMDAwMDA1ICZzY21pX3NobV8zDQo+PiArICAgICAg
ICAgICAgICAgICAgICAgICAgNCAweDgyMDAwMDA2ICZzY21pX3NobV80PjsNCj4+ICsgICAgICAg
IH07DQo+PiArDQo+PiArICAgICAgICAvLyBIb3N0IFNDTUkgT1NQTSBjaGFubmVsIC0gcHJvdmlk
ZWQgdG8gdGhlIERvbTAgYXMgaXMgaWYgU0NNSSBlbmFibGVkIGZvciBpdA0KPj4gKyAgICAgICAg
c2NtaV9zaG06IHNyYW1ANDdmZjEwMDAgew0KPj4gKyAgICAgICAgICAgICAgICBjb21wYXRpYmxl
ID0gImFybSxzY21pLXNobWVtIjsNCj4+ICsgICAgICAgICAgICAgICAgcmVnID0gPDB4MCAweDQ3
ZmYxMDAwIDB4MCAweDEwMDA+Ow0KPj4gKyAgICAgICAgfTsNCj4+ICsNCj4+ICsgICAgICAgIGZp
cm13YXJlIHsNCj4+ICsgICAgICAgICAgICBzY21pOiBzY21pIHsNCj4+ICsgICAgICAgICAgICAg
ICAgY29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zbWMiOw0KPj4gKyAgICAgICAgICAgICAgICBhcm0s
c21jLWlkID0gPDB4ODIwMDAwMDM+OyA8LS0tIEhvc3QgT1NQTSBhZ2VudCBzbWMtaWQNCj4+ICsg
ICAgICAgICAgICAgICAgI2FkZHJlc3MtY2VsbHMgPSA8IDE+Ow0KPj4gKyAgICAgICAgICAgICAg
ICAjc2l6ZS1jZWxscyA9IDwgMD47DQo+PiArICAgICAgICAgICAgICAgIHNobWVtID0gPCZzY21p
X3NobT47IDwtLS0gSG9zdCBPU1BNIGFnZW50IHNobWVtDQo+IEJ5IE9TUE0geW91IG1lYW4gRG9t
MCBhbmQgbm90IFhlbj8gU28gdGhpcyBpcyBhIGNoYW5nZSBjb21wYXJlZCB0byBhDQo+IGRldmlj
ZSB0cmVlIGZvciBiYXJlbWV0YWwgTGludXggd2l0aG91dCBYZW4/DQo+DQo+IExldCBtZSBhc2sg
dGhlIHNhbWUgcXVlc3Rpb24gZGlmZmVyZW50bHkuIEluIHRoZSBjYXNlIG9mIGJhcmVtYXRhbCBM
aW51eA0KPiB3aXRob3V0IFhlbiAobm8gS1ZNKSwgd2hhdCB3b3VsZCBMaW51eCBzZWUgdW5kZXIg
L2Zpcm13YXJlL3NjbWkgYXMNCj4gc21jLWlkIGFuZCBzaG1lbT8gVGhlIHNhbWUgYXMgdGhlIG9u
ZSB0aGF0IFhlbiB3b3VsZCB1c2UgZm9yIGl0c2VsZj8gT3INCj4gdGhlIHNhbWUgYXMgdGhlIG9u
ZXMgdGhhdCBEb20wIHdvdWxkIHVzZSB3aGVuIFhlbiBpcyBwcmVzZW50Pw0KDQpJZiB0aGlzIERU
IGlzIHVzZWQgd2l0aCB0aGUgYmFyZW1ldGFsIExpbnV4IC0gdGhlbiB0aGUgTGludXggS2VybmVs
IHdpbGwNCg0Kc2VlIERvbTAgInNtYy1pZCIgYW5kICJzaG1lbiIgdW5kZXIgL2Zpcm13YXJlL3Nj
bWkuDQoNCj4+ICsgICAgICAgICAgICAgICAgcHJvdG9jb2xAWHsNCj4+ICsgICAgICAgICAgICAg
ICAgfTsNCj4+ICsgICAgICAgICAgICB9Ow0KPj4gKyAgICAgICAgfTsNCj4+ICsgICAgfQ0KPj4g
Kw0KPj4gKw0KPj4gK0luIHRoZSBhYm92ZSBjYXNlOg0KPj4gKw0KPj4gKzEpIFhlbiBTQ01JIG11
bHRpLWFnZW50IGNhbiBiZSBwcm9iZWQgd2l0aCBEVCBjb25maWd1cmF0aW9uIGZyb20gImNob3Nl
biIgKG9yIHNwZWNpYWwgInhlbixjb25maWciKQ0KPj4gKyAgIG5vZGUgYW5kIGFsbCBYZW4gcmVs
YXRlZCBub2RlcyBjYW4gYmUgZWFzaWx5IGRyb3BwZWQgZnJvbSBEb20wIERULg0KPj4gKzIpIEhv
c3QgU0NNSSBPU1BNIGNoYW5uZWwgRFQgbm9kZXMgY2FuIGJlIGNvcGllZCB0byBEb20wIERUIHdp
dGhvdXQgY2hhbmdlcyBpZiBTQ01JIGVuYWJsZWQgZm9yIGl0Lg0KPj4gKzMpIEZ1dHVyZSBzdXBw
b3J0IGZvciBtYWlsYm94IHNoYXJlZC1tZW1vcnkgdHJhbnNwb3J0IChTQ1AgU0NNSSBGVykgY2Fu
IGJlIHNpbXBsaWZpZWQgYXMgbm8gbW9yZQ0KPj4gKyAgIG1hbmlwdWxhdGlvbiByZXF1aXJlZCB3
aXRoIERvbTAgU0NNSSAiYXJtLHNtYy1pZCIgYW5kICJzaG1lbSIgRFQgcHJvcGVydGllcy4NCj4g
WWVzLCBJIGNhbiBzZWUgdGhlIGJlbmVmaXQgaWYgd2UgY2FuIGFycmFuZ2UgaXQgc28gdGhhdCB0
aGUgdW5kZXJseWluZw0KPiBob3N0IGRldmljZSB0cmVlIGlzIHRoZSBzYW1lIHRoYXQgTGludXgg
d291bGQgdXNlIGJhcmVtZXRhbC4gQW5kIGFsbCB0aGUNCj4gZXh0cmEgY29uZmlndXJhdGlvbiBp
cyBwbGFjZWQgdW5kZXIgL2Nob3NlbiBpbiAieGVuLGNvbmZpZyIgbm9kZSBvcg0KPiBzaW1pbGFy
LiBJIHdvdWxkIHByb2JhYmx5IGNhbGwgaXQgInhlbixzY21pIi4NCg0KUGVyc29uYWxseSwgSSB3
b3VsZCBrZWVwICJ4ZW4sY29uZmlnIiBhcyBpdCBsZWF2ZXMgcm9vbSB0byBhZGQgYWRkaXRpb25h
bA0KDQpjb25maWd1cmF0aW9uIG5vZGVzIGluIHRoZSBmdXR1cmUuDQoNCj4+ICtFeGFtcGxlIG9m
IHVzaW5nICJ4ZW4sY29uZmlnIiBmb3IgY29uZmlndXJhdGlvbjoNCj4+ICsNCj4+ICsuLiBjb2Rl
OjoNCj4+ICsNCj4+ICsgICAgaHlwZXJ2aXNvciB7DQo+PiArICAgICAgICBjb21wYXRpYmxlID0g
4oCcaHlwZXJ2aXNvcix4ZW7igJ0NCj4+ICsNCj4+ICsgICAgICAgIC8vIENvbmZpZ3VyYXRpb24g
Y29udGFpbmVyDQo+PiArICAgICAgICBjb25maWcgew0KPj4gKyAgICAgICAgICAgIGNvbXBhdGli
bGUgPSAieGVuLGNvbmZpZyI7DQo+PiArICAgICAgICAgICAgLi4uDQo+PiArDQo+PiArICAgICAg
ICAgICAgLy8gWGVuIFNDTUkgbWFuYWdlbWVudCBjaGFubmVsDQo+PiArICAgICAgICAgICAgc2Nt
aV9zaG1fMCA6IHNyYW1ANDdmZjAwMDAgew0KPj4gKyAgICAgICAgICAgICAgICBjb21wYXRpYmxl
ID0gImFybSxzY21pLXNobWVtIjsNCj4+ICsgICAgICAgICAgICAgICAgcmVnID0gPDB4MCAweDQ3
ZmYwMDAwIDB4MCAweDEwMDA+Ow0KPj4gKyAgICAgICAgICAgIH07DQo+PiArICAgICAgICAgICAg
c2NtaV94ZW46IHNjbWkgew0KPj4gKyAgICAgICAgICAgICAgICBjb21wYXRpYmxlID0gImFybSxz
Y21pLXNtYyI7DQo+PiArICAgICAgICAgICAgICAgIGFybSxzbWMtaWQgPSA8MHg4MjAwMDAwMj47
IDwtLS0gWGVuIG1hbmVnZW1lbnQgYWdlbnQgc21jLWlkDQo+PiArICAgICAgICAgICAgICAgICNh
ZGRyZXNzLWNlbGxzID0gPCAxPjsNCj4+ICsgICAgICAgICAgICAgICAgI3NpemUtY2VsbHMgPSA8
IDA+Ow0KPj4gKyAgICAgICAgICAgICAgICAjYWNjZXNzLWNvbnRyb2xsZXItY2VsbHMgPSA8IDE+
Ow0KPj4gKyAgICAgICAgICAgICAgICBzaG1lbSA9IDwmc2NtaV9zaG1fMD47IDwtLS0gWGVuIG1h
bmVnZW1lbnQgYWdlbnQgc2htZW0NCj4+ICsgICAgICAgICAgICB9Ow0KPj4gKw0KPj4gKyAgICAg
ICAgICAgIC8vIFNDTUkgbXVsdGktYWdlbnQgY29uZmlndXJhdGlvbg0KPj4gKyAgICAgICAgICAg
IHNjbWlfc2htXzI6IHNyYW1ANDdmZjIwMDAgew0KPj4gKyAgICAgICAgICAgICAgICAgICAgY29t
cGF0aWJsZSA9ICJhcm0sc2NtaS1zaG1lbSI7DQo+PiArICAgICAgICAgICAgICAgICAgICByZWcg
PSA8MHgwIDB4NDdmZjIwMDAgMHgwIDB4MTAwMD47DQo+PiArICAgICAgICAgICAgfTsNCj4+ICsg
ICAgICAgICAgICBzY21pX3NobV8zOiBzcmFtQDQ3ZmYzMDAwIHsNCj4+ICsgICAgICAgICAgICAg
ICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0KPj4gKyAgICAgICAgICAgICAg
ICAgICAgcmVnID0gPDB4MCAweDQ3ZmYzMDAwIDB4MCAweDEwMDA+Ow0KPj4gKyAgICAgICAgICAg
IH07DQo+PiArICAgICAgICAgICAgc2NtaV9zaG1fNDogc3JhbUA0N2ZmNDAwMCB7DQo+PiArICAg
ICAgICAgICAgICAgICAgICBjb21wYXRpYmxlID0gImFybSxzY21pLXNobWVtIjsNCj4+ICsgICAg
ICAgICAgICAgICAgICAgIHJlZyA9IDwweDAgMHg0N2ZmNDAwMCAweDAgMHgxMDAwPjsNCj4+ICsg
ICAgICAgICAgICB9Ow0KPj4gKyAgICAgICAgICAgIHhlbixzY21pLXNlY29uZGFyeS1hZ2VudHMg
PSA8DQo+PiArICAgICAgICAgICAgICAgICAgICAgICAgMSAweDgyMDAwMDAzICZzY21pX3NobQ0K
Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgIDIgMHg4MjAwMDAwNCAmc2NtaV9zaG1fMg0KPj4g
KyAgICAgICAgICAgICAgICAgICAgICAgIDMgMHg4MjAwMDAwNSAmc2NtaV9zaG1fMw0KPj4gKyAg
ICAgICAgICAgICAgICAgICAgICAgIDQgMHg4MjAwMDAwNiAmc2NtaV9zaG1fND47DQo+PiArICAg
ICAgICB9Ow0KPj4gKyAgICB9Ow0KPj4gKw0KPj4gKyAgICAvew0KPj4gKyAgICAgICAgLy8gSG9z
dCBTQ01JIE9TUE0gY2hhbm5lbCAtIHByb3ZpZGVkIHRvIHRoZSBEb20wIGFzIGlzIGlmIFNDTUkg
ZW5hYmxlZCBmb3IgaXQNCj4+ICsgICAgICAgIHNjbWlfc2htOiBzcmFtQDQ3ZmYxMDAwIHsNCj4+
ICsgICAgICAgICAgICAgICAgY29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zaG1lbSI7DQo+PiArICAg
ICAgICAgICAgICAgIHJlZyA9IDwweDAgMHg0N2ZmMTAwMCAweDAgMHgxMDAwPjsNCj4+ICsgICAg
ICAgIH07DQo+PiArDQo+PiArICAgICAgICBmaXJtd2FyZSB7DQo+PiArICAgICAgICAgICAgc2Nt
aTogc2NtaSB7DQo+PiArICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc21j
IjsNCj4+ICsgICAgICAgICAgICAgICAgYXJtLHNtYy1pZCA9IDwweDgyMDAwMDAzPjsgPC0tLSBI
b3N0IE9TUE0gYWdlbnQgc21jLWlkDQo+PiArICAgICAgICAgICAgICAgICNhZGRyZXNzLWNlbGxz
ID0gPCAxPjsNCj4+ICsgICAgICAgICAgICAgICAgI3NpemUtY2VsbHMgPSA8IDA+Ow0KPj4gKyAg
ICAgICAgICAgICAgICBzaG1lbSA9IDwmc2NtaV9zaG0+OyA8LS0tIEhvc3QgT1NQTSBhZ2VudCBz
aG1lbQ0KPj4gKw0KPj4gKyAgICAgICAgICAgICAgICBwcm90b2NvbEBYew0KPj4gKyAgICAgICAg
ICAgICAgICB9Ow0KPj4gKyAgICAgICAgICAgIH07DQo+PiArICAgICAgICB9Ow0KPj4gKyAgICB9
DQo+PiAtLSANCj4+IDIuMzQuMQ==


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 12:04:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 12:04:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012959.1391516 (Exim 4.92)
	(envelope-from )
	id 1uPgf6-0007rd-Qy; Thu, 12 Jun 2025 12:04:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012959.1391516; Thu, 12 Jun 2025 12:04: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 1uPgf6-0007rT-NQ; Thu, 12 Jun 2025 12:04:04 +0000
Received: by outflank-mailman (input) for mailman id 1012959;
 Thu, 12 Jun 2025 12:04: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 1uPgf4-0006ef-JZ
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 12:04:03 +0000
Received: from DUZPR83CU001.outbound.protection.outlook.com
 (mail-northeuropeazlp170120005.outbound.protection.outlook.com
 [2a01:111:f403:c200::5])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 53073680-4785-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 14:04:00 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by DU2PR03MB8075.eurprd03.prod.outlook.com (2603:10a6:10:2e6::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.22; Thu, 12 Jun
 2025 12:03:57 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%4]) with mapi id 15.20.8769.029; Thu, 12 Jun 2025
 12:03: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: 53073680-4785-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=usYJBigQiKJaGuqwg1DJKEvKjWPAi2IQ/lKfNUN2POuwHvJYvcGqcpRW3N0856K+dl2Sr2xIdvd0e8OTVKTfgAkpIUDwx5wHT52u/zl5nNGwJ2XkGlgNl1Ugjy0ghsN7CBtvtlSHqs1L5OaStrR+V8TGRX7aDuhTbExkQInNCDJoPLuTwxtpJ1ouXXCl3d5x+AwOpiwgxVZKquobo6rYk7yO56DOSI9+d6sNbuNl3vbXD9TTS8bOzdzSiqdB/QvtWCSS5mh1x4sZTuwhGwRiqgTvzG8nvLoSJDTRbz5cqOuPTDD9SjsM96ELzYOBOH+abOTUphFyMF6xX6MVwcEloQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=iHzgydcgPFzt0RGrBjW7P3EkZBtkHcp3ZmhfJXEJZLI=;
 b=mUuGzzBclD402B2+rGfNQDfSNVEvjiFwXok8xKw7iX2gmtIw9hX+1oOxlWDu2VWCoCefurNGzWVOeWqLMCT6SGFkuMXP1IOTszY1k1mZR9Tj1BGL0XFc/8yVKHuxQtp3bBZYeQeXOQSzsFfVs2HcFjNHX8B5VJqVzKQbHPP+lVxrV7ayJfzjs0LVg2iSe7nWEFjsp24PQFVcuh6UIa0VLyP+BAUOm74dToDWkpk3EdP7VN3x2mZIPgHKpVW098tRr3p3ZVB4hrG4y0U1p7u3ZjuUaJqTLd4Aa7T2JfW8Ccm4zLk1K00abWOuAMpCsyzZtG+xfCvukZGm4NOT/Bt+dQ==
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=iHzgydcgPFzt0RGrBjW7P3EkZBtkHcp3ZmhfJXEJZLI=;
 b=LRbQq6DC15qVrJwJrtkFe3st5ErkQF+p12m5xos1lFMz37Sgh0iCXz2+PDam/WBlbV2FI6W47saPJvezcb4HnZWviK3BuOmPfZTVfQ2MIJ5/GLfooE1hgi1+bN6TQrp5vnk1Tn1ikcsxx39pXDgQJEqs6rxVALJ4L7pJuY1ZTFgX2GObWHqiBH0kj0ABSLSenVOGZK0BURxgqtLVqsISsFESE3M7QNbudzHPZPB1iK/RL5WS5zbxFhCz1sYtDEuY+2i31xtJ6marZJiwGgX2krlRtOR7c7/MFAi8cnSEVJUYvGxSk6BKBEuZaNQypvyOBL1+EjTXgJfVjI59lu6UTw==
From: Oleksii Moisieiev 
To: Bertrand Marquis , Stefano Stabellini
	
CC: "xen-devel@lists.xenproject.org" , Andrew
 Cooper , Anthony PERARD
	, Jan Beulich , Juergen Gross
	, Julien Grall , Michal Orzel
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Volodymyr Babchuk ,
	Grygorii Strashko 
Subject: Re: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC
 multi-agent driver
Thread-Topic: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC
 multi-agent driver
Thread-Index: AQHbyNXPHUV4T01ZEEC9Uxm0LaLKHbPgqpIAgA7gjoCAEAdZAA==
Date: Thu, 12 Jun 2025 12:03:57 +0000
Message-ID: <2609f679-2835-4247-8eb1-279c1a216d7c@epam.com>
References: 
 <318044ae12f13b6b297b3f5fda577a1a6cd143da.1747669845.git.oleksii_moisieiev@epam.com>
 
 <04B1F737-5E6B-47C0-B2B9-74288C68E68A@arm.com>
In-Reply-To: <04B1F737-5E6B-47C0-B2B9-74288C68E68A@arm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB8946:EE_|DU2PR03MB8075:EE_
x-ms-office365-filtering-correlation-id: b8c122e0-e93f-4d9a-c13e-08dda9a935b1
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|366016|1800799024|7416014|376014|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?YnprRjVHaGh6cUdOV3lmWDhmdnR1SlJObFVYMDFJUm9MMmFaYldPWHk1cnpF?=
 =?utf-8?B?aVFkWVJMR3doSjBqM200ODJnVmNpWE0wcExBYlFtMDVlMm5GYTZveGphYXFO?=
 =?utf-8?B?N1gvalF2L2xUQXZmUGx2dGhOL3BjWkVHbTdYbnhyZzhJK09Qc1R1ME5nRlRK?=
 =?utf-8?B?TlNVcmRLUUdhSWQ3VmZxckRzNkd6cDIxa2RKV1dqNmFGVWlQVGlnQ0J5RnpR?=
 =?utf-8?B?anQ5bEE5eUhoL3V3Y1dtcklUZ0FQcTV2bXpicmhOaU04RFBBa0RPVkZyV2tK?=
 =?utf-8?B?TjhYUmxKWFVveExGWG9qNWpiMndZV3B6YUZ5WHlWaFR0OUV3dHUzL0tnN1ho?=
 =?utf-8?B?amNZMFcxZW4wdC9WdTJLKzdtTXhUSVlUTll1THJ0OWRTcnQrMkdZSDBXSDE2?=
 =?utf-8?B?V1d0MHpOZnQxRjZGdGRSY3Nyd2g2N1dQMzFmUXMxSDExMzNiN1c0VXNib1lI?=
 =?utf-8?B?RzNFZjBIZ3Q2MUg1VFIzT2E1dndSWStKeVZqOGIzOUpvVXpraWxRaC8xSmtH?=
 =?utf-8?B?aWQrazdKZlh0YmZIT0xmTEQwbit2OHRNc0tPclphNnRLVUdaaS9FRkt3cnlo?=
 =?utf-8?B?d2FrbkJJNGlJaGFQbDNRUFZqckxVMTVIQ0ZGTkg4TjNLYjZQeW44YVROdlFE?=
 =?utf-8?B?NUE5THdybGhBa1JmbERVWjAxdFlrcW0xQUxUVndhOU9vNm1OZjRjQWdNSGpI?=
 =?utf-8?B?a2IxbnJFb3NTdmNsYy8vSjFrOTRvTzJ3WDRJRWFmeEFzSk9YUnpGa2phRWow?=
 =?utf-8?B?VFZqdkF3bHo2MkVHNEhpdUJZSmk3VG43dVg4OWJURVNJVlNmTE4yQzdEa1Uz?=
 =?utf-8?B?aFN4L1JnSDc2RCtpcFlWM2ZYNUJqQWgyN3c0RTJlejBWbTZjajlQZG4waVBo?=
 =?utf-8?B?UGNXV1NkMWsyZjExb0JYMlZyZSsvNHFnSThKNjBBbkx5K1VYbGx2TXZIWnFi?=
 =?utf-8?B?WXdKd1NvZjFiRWgxZG9KdUY5K2pRM0lnTXJObUljYVorNDFoUElDS1Y5TG9X?=
 =?utf-8?B?MGcyaFJ6WW5heERCU0RvSUlyOGlkT2JZam5xakZUd2NTR1Y2MGhaZEQwamQ0?=
 =?utf-8?B?Y1ZpNExOZkNacGExMkxMaVhhUDExYVRVZno4TjEwL0FGUlBJVWRSVTlFekdj?=
 =?utf-8?B?VEVOVXA5UlpTY2V2ejg3Q0xWNUJ0RVdYN1FSdldBRkV4SlE4QmRrZUxyclVa?=
 =?utf-8?B?QWlzaW9FU2JuUlY2bTRXTThTRExFUnlxR0VMcWdWa3pmTDI1czBKTUs5anFM?=
 =?utf-8?B?UWw4RVFUcmw4aExvQ2FtcWZEWnpOa1VjWlhhRW5EQ25ITWdadVp6UnJGOEVp?=
 =?utf-8?B?cG9jd1hrYjd1NlRHN3VGaWpHSkF5V0wrNjlwWFhoYkpaT1dJMlloc0grOFd2?=
 =?utf-8?B?YWxVN2V6bU1ZSjdZTVZjUkc0WXdHVXZoMlV5VmpjMzI3cldNTW1aajNQb1Er?=
 =?utf-8?B?SnJiRjRCTy9SZVdmZGloRnBpOXNoMnIxSEM1bDNLS0pzS0hNQjRyQTZWRVZC?=
 =?utf-8?B?OEliakg0cXVXbWR2cWVCM2c5aGRJS2d0OHBIOHZtb1JPV3RmYzNyWEJBejd2?=
 =?utf-8?B?YXYyeW1iV3k3SkRXYXgzTWpFL1pEd3daR25QaWJGS04yTVdNamVjSENPdjRk?=
 =?utf-8?B?KzNRYnhNMmlKZDVUbTUwZ1dqQnJ4WXRxK255UnZpNmE5emlUNnpnSWlUc1pM?=
 =?utf-8?B?QkEyRnBGMDNWVzNaL1QvdVlVbGIzQXUxUDIvd0tMMHJxYzFMMW1Xc3RRdm5X?=
 =?utf-8?B?aGZ6NlQrNnFxQm0xZ2Iza0M1M1JwUUMwZGIzODJYcUdYdy9vRTlsN21mZjd5?=
 =?utf-8?B?cFBHTnRlaFhLNmNwN0xDZ1RLRlpNUVV1Z3VYRDFQWTlSa0l3eUlJVUlXQ1Iv?=
 =?utf-8?B?YlU3cFBHTWRMQmxOZlYwT2Fpai9pMkEvVytNRFhkRGdEa0E0bEsrcys0Sk4w?=
 =?utf-8?B?MDJzbkREMi9xcUZ5YlNNbms3eDFaeEFWazhFdFhMK1I4VDlnblVDQkxYWVIz?=
 =?utf-8?B?TFUxbWFxaDVnPT0=?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(7416014)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?MDdIQlM1bDZ5OVpGQlZ5MVZjSkJUL1FFMVoyVmh6bTB3WFlaMEIwcW1pN0xK?=
 =?utf-8?B?VkZ6d0EwMFJMQTdXVzZQMjZibVd5RTdWczYycjRNMlpQd2FQTTBEQnB2dGVz?=
 =?utf-8?B?WG4ydndZWGRNc2pIZUplb25TdWo4dkxmV1ZFc1VyWkZ3NFhSSExlWXRYTUd2?=
 =?utf-8?B?bDRnbUs0RHFCQUFaVURqTFlJN2t3TzZMSS9zUTA3dXZZZGx5TVJtUkJ1RHFn?=
 =?utf-8?B?d2UrQWhBQzZpa3RzR2l2cEV6YnRheXkwampraENYL0wybzFJWnQ0YzI1SGtG?=
 =?utf-8?B?K2FNdDFxRHdreFhQTm9ZQWc2Ulh4dU1GQTRLdGhGZkN1ZTZnK05QZnIrTElK?=
 =?utf-8?B?MUlMV3JHY3dBQkUwRHFXd2dJOWQzOWkxeGVzM2xNaWRRZEhKZmZ1SFAzN0VF?=
 =?utf-8?B?NEt4QlpKQW5MckJLUkNIcFdqcUJadEpEL2hWYlBYUnd6UnpVRHRLR1hjSXdx?=
 =?utf-8?B?d1B4QlozZWxRQW14RkxxWWwveHRwK0lJd1BDa0VVeG45TDU5VmI1bnhRbENr?=
 =?utf-8?B?Q0RNc2RqOHNaQW9FenlOc2xuZGJ6Y0RrM3hiV3ZlRjVUSjFKbFlaN1djbGV6?=
 =?utf-8?B?ZmZ1SE16cW1LZStxeldlZ1Rnb0gxNmkvc1V1WFhRNzRPeUZyWStxdjAwb09W?=
 =?utf-8?B?dGRXV3VvcFVNRmZyTlIxRTVSTXI0dW5IeEE4VDZPV2ZRcUcvZnUvcWNSQTAw?=
 =?utf-8?B?djZRdEtPWkREK3lMSHFVMm95eWRMMkptZnlrUG93ZVJYNnFKcWs2Y3NNNXY0?=
 =?utf-8?B?Wko1K0pNTW51M3ltengzQnpDZkpseXZpaVlRdmIzVWJRdGtGdm5abjNRenNB?=
 =?utf-8?B?cjJ6ZkwrNXdWbjQyZ2lmOHFZUFZmZElxc3dYNHB0Z0lOb2pXRS9lbUZqb3VO?=
 =?utf-8?B?a2Y4RTdxVndGQW5jVkdqdlJVME15UVNJeVA0WHFkNkg0ZzNtRXduZnZ0b0E4?=
 =?utf-8?B?NE9xeDQvZm5UNmh5aXg5b1MzK0VkeFE1SmNCNjBuNUZZYlRmV0xhVHhtOHVG?=
 =?utf-8?B?RkxUR2lkMlRvTE9NdEUyZGovVFA4Q1Y4VSszaW5Na0VvZTlIMFhLaUoyZ3h2?=
 =?utf-8?B?eE43QmZKSER5MmkwSzU5eFRrejRVV3BwV0JtWWdmR2pjbXhnd21tMG05MjNN?=
 =?utf-8?B?a1ZRRHJ1QldKb0RqYTMvZzNqM1IyNUQ5Rng0WHp4c0Z3WVIxc2F3cTBSYk83?=
 =?utf-8?B?bEpjU1oxalY0aDliU3hGVkk2MzlqVkpWSFpwQW9IUXZjR3BGNm0rN2ora3Ju?=
 =?utf-8?B?dnZ0R0NicmJNTmFEbHd3SzV2dUZ4T1kyRVVqcXhiakhrZFJmZktmbFFVdy8w?=
 =?utf-8?B?ZlEyZVg4MzlmZUJLRkorUWZRckRqVlQza0tmVWVOV0plSzI3K1A2d0oyODdB?=
 =?utf-8?B?Yko3eDZzbVp4RXlyRXNrQi9CUnAvNkFHQW1GQSt0ei9qQmlsVUtodnp6L1hP?=
 =?utf-8?B?My85bE9kd25DZTN6OWRqUjN3TmlzQjg2NUlsNWkvQUFpSk9pR3Q0U2lnSHpB?=
 =?utf-8?B?TzU1S2V2a0hkZEFTYUlmYXRWMEdadzQrQXBDY1c4d0FZTjUzb3pWVnlOM2lW?=
 =?utf-8?B?elhCeGgxcXJrbmd0UDhEMG1nZE1CbFI5MlBkSThsY3BIU1BIV0xlVTdyUk1j?=
 =?utf-8?B?SnV4cDNyb0RrT0R4SVFrT2hPRnhCbXJ4Q2g4MC8zV0pJWjJGSzA2T1ZSM0Jj?=
 =?utf-8?B?anRySVE5Tnp3c2xSQXRyTko5QkRMZkRUTVlXNHI5cXMrM2EwRWxWdlpQcUov?=
 =?utf-8?B?bE9KUGUzUzk0OEI0S1ZHRHUwV2VXWUVZS3M1UE1pWVllRCtqdUM2STJ0bStZ?=
 =?utf-8?B?QStxbHdwUUxiZUFBcWVpazJtMkVObGdOS2FXSmM5VzBnWWF0Rm5QZTczejI1?=
 =?utf-8?B?TjBXU21YRjhrR1ZIV3FnNE9QOTJGVTlTeDJibHVzdzJHV2ZjN3Ztbld5UDVT?=
 =?utf-8?B?SUVSRVVZc1B1b1JubDJheHFhcTV6YXFjalFOS2s2ckNDMUNhdkl6Ris0WVFX?=
 =?utf-8?B?cFN6S05IazNvY1FuRmtNQy9zbFZ1NUJMWkdEYUxWTzBwNzB6cml2NDlvUGY0?=
 =?utf-8?B?eEh1VXczcUI4dXArU2VXdE1xNEYwZFQxVTd1RThwNHZUU0JMK0FtblRZZ1pn?=
 =?utf-8?B?elNrd1lkUWdLMkhCQjlKcTBsaDVFaHl5cXNST1NrOVplRmNSK1l0VDhsdTFo?=
 =?utf-8?B?Z3c9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <1AD38BBD051D1649BFD54DA549B957C8@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: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b8c122e0-e93f-4d9a-c13e-08dda9a935b1
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2025 12:03:57.1555
 (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: MhWQxHYydf0GV2uKeh4Ffpva3OixcV5fNEp4l1Jt2/aoHzfUg3Yxuslgz+ZmGst0J2tykTY3yQTWKXKCLDabyEN0aY9KvXDTD3X/XYtvO/o=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU2PR03MB8075

DQpPbiAwMi8wNi8yMDI1IDEwOjE3LCBCZXJ0cmFuZCBNYXJxdWlzIHdyb3RlOg0KPiBIaSBTdGVm
YW5vIGFuZCBPbGVrc2lpLA0KPg0KPj4gT24gMjMgTWF5IDIwMjUsIGF0IDIyOjA2LCBTdGVmYW5v
IFN0YWJlbGxpbmk8c3N0YWJlbGxpbmlAa2VybmVsLm9yZz4gIHdyb3RlOg0KPj4NCj4+IE9uZSBx
dWVzdGlvbiBmb3IgQmVydHJhbmQgYmVsb3cNCj4+DQo+Pg0KPj4gT24gTW9uLCAxOSBNYXkgMjAy
NSwgT2xla3NpaSBNb2lzaWVpZXYgd3JvdGU6DQo+Pj4gVGhpcyBwYXRjaCBpbnRyb2R1Y2VzIFND
SSBkcml2ZXIgdG8gc3VwcG9ydCBmb3IgQVJNIEVMMyBUcnVzdGVkIEZpcm13YXJlLUENCj4+PiAo
VEYtQSkgd2hpY2ggcHJvdmlkZXMgU0NNSSBpbnRlcmZhY2Ugd2l0aCBtdWx0aS1hZ25ldCBzdXBw
b3J0LCBhcyBzaG93bg0KPj4+IGJlbG93Lg0KPj4+DQo+Pj4gICArLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+Pj4gICB8ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICB8DQo+Pj4gICB8IEVMMyBURi1BIFNDTUkgICAgICAgICAgICAgICAg
ICAgICAgICAgICB8DQo+Pj4gICArLS0tLS0tLSstLSstLS0tLS0tKy0tKy0tLS0tLS0rLS0rLS0t
LS0tLSsrDQo+Pj4gICB8c2htZW0wIHwgIHxzaG1lbTEgfCAgfHNobWVtMiB8ICB8c2htZW1YIHwN
Cj4+PiAgICstLS0tLSstKyAgKy0tLSstLS0rICArLS0rLS0tLSsgICstLS0rLS0tKw0KPj4+IHNt
Yy1pZDAgfCAgICAgICAgfCAgICAgICAgIHwgICAgICAgICAgIHwNCj4+PiBhZ2VudDAgIHwgICAg
ICAgIHwgICAgICAgICB8ICAgICAgICAgICB8DQo+Pj4gICArLS0tLS12LS0tLS0tLS0rLS0tLS0t
LS0tKy0tLS0tLS0tLS0tKy0tLS0rDQo+Pj4gICB8ICAgICAgICAgICAgICB8ICAgICAgICAgfCAg
ICAgICAgICAgfCAgICB8DQo+Pj4gICB8ICAgICAgICAgICAgICB8ICAgICAgICAgfCAgICAgICAg
ICAgfCAgICB8DQo+Pj4gICArLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0t
LS0rDQo+Pj4gICAgICAgICAgc21jLWlkMSB8ICBzbWMtaWQyfCAgICBzbWMtaWRYfA0KPj4+ICAg
ICAgICAgIGFnZW50MSAgfCAgYWdlbnQyIHwgICAgYWdlbnRYIHwNCj4+PiAgICAgICAgICAgICAg
ICAgIHwgICAgICAgICB8ICAgICAgICAgICB8DQo+Pj4gICAgICAgICAgICAgKy0tLS12LS0tKyAg
Ky0tdi0tLS0tKyAgKy0tdi0tLS0tKw0KPj4+ICAgICAgICAgICAgIHwgICAgICAgIHwgIHwgICAg
ICAgIHwgIHwgICAgICAgIHwNCj4+PiAgICAgICAgICAgICB8IERvbTAgICB8ICB8IERvbTEgICB8
ICB8IERvbVggICB8DQo+Pj4gICAgICAgICAgICAgfCAgICAgICAgfCAgfCAgICAgICAgfCAgfCAg
ICAgICAgfA0KPj4+ICAgICAgICAgICAgIHwgICAgICAgIHwgIHwgICAgICAgIHwgIHwgICAgICAg
IHwNCj4+PiAgICAgICAgICAgICArLS0tLS0tLS0rICArLS0tLS0tLS0rICArLS0tLS0tLS0rDQo+
Pj4NCj4+PiBUaGUgRUwzIFNDTUkgbXVsdGktYWdlbnQgZmlybXdhcmUgZXhwZWN0ZWQgdG8gcHJv
dmlkZSBTQ01JIFNNQy9IVkMgc2hhcmVkDQo+Pj4gbWVtb3J5IHRyYW5zcG9ydCBmb3IgZXZlcnkg
QWdlbnQgaW4gdGhlIHN5c3RlbS4NCj4+Pg0KPj4+IFRoZSBTQ01JIEFnZW50IHRyYW5zcG9ydCBj
aGFubmVsIGRlZmluZWQgYnkgcGFpcjoNCj4+PiAtIHNtYy1pZDogU01DL0hWQyBpZCB1c2VkIGZv
ciBEb29yYmVsbA0KPj4+IC0gc2htZW06IHNoYXJlZCBtZW1vcnkgZm9yIG1lc3NhZ2VzIHRyYW5z
ZmVyLCBYZW4gcGFnZSBhbGlnbmVkLA0KPj4+IHAybV9tbWlvX2RpcmVjdF9uYy4NCj4+Pg0KPj4+
IFRoZSBmb2xsd29pbmcgU0NNSSBBZ2VudHMgZXhwZWN0ZWQgdG8gYmUgZGVmaW5lZCBieSBTQ01J
IEZXIHRvIGVuYWJsZSBTQ01JDQo+Pj4gbXVsdGktYWdlbnQgZnVuY3Rpb25hbGl0eSB1bmRlciBY
ZW46DQo+Pj4gLSBYZW4gbWFuZWdlbWVudCBhZ2VudDogdHJ1c3RlZCBhZ2VudHMgdGhhdCBhY2Nl
c3NlcyB0byB0aGUgQmFzZSBQcm90b2NvbA0KPj4+IGNvbW1hbmRzIHRvIGNvbmZpZ3VyZSBhZ2Vu
dCBzcGVjaWZpYyBwZXJtaXNzaW9ucw0KPj4+IC0gT1NQTSBWTSBhZ2VudHM6IG5vbi10cnVzdGVk
IGFnZW50LCBvbmUgZm9yIGVhY2ggR3Vlc3QgZG9tYWluIHdoaWNoIGlzDQo+Pj4gICBhbGxvd2Vk
IGRpcmVjdCBIVyBhY2Nlc3MuIEF0IGxlYXN0IG9uZSBPU1BNIFZNIGFnZW50IGhhcyB0byBiZSBw
cm92aWRlZA0KPj4+ICAgYnkgRlcgaWYgSFcgaXMgaGFuZGxlZCBvbmx5IGJ5IERvbTAgb3IgRHJp
dmVyIERvbWFpbi4NCj4+Pg0KPj4+IFRoZSBFTDMgU0NNSSBGVyBleHBlY3RlZCB0byBpbXBsZW1l
bnQgZm9sbG93aW5nIEJhc2UgcHJvdG9jb2wgbWVzc2FnZXM6DQo+Pj4gLSBCQVNFX0RJU0NPVkVS
X0FHRU5UDQo+Pj4gLSBCQVNFX1JFU0VUX0FHRU5UX0NPTkZJR1VSQVRJT04gKG9wdGlvbmFsKQ0K
Pj4+IC0gQkFTRV9TRVRfREVWSUNFX1BFUk1JU1NJT05TIChvcHRpb25hbCkNCj4+Pg0KPj4+IFRo
ZSBTQ0kgU0NNSSBTTUMgbXVsdGktYWdlbnQgZHJpdmVyIGltcGxlbWVudHMgZm9sbG93aW5nIGZ1
bmN0aW9uYWxpdHk6DQo+Pj4gLSBJdCdzIGluaXRpYWxpemVkIGJhc2VkIG9uIHRoZSBIb3N0IERU
IFNDTUkgbm9kZSAob25seSBvbmUgU0NNSSBpbnRlcmZhY2UNCj4+PiBpcyBzdXBwb3J0ZWQpIHdo
aWNoIGRlc2NyaWJlcyBYZW4gbWFuYWdlbWVudCBhZ2VudCBTQ01JIGludGVyZmFjZS4NCj4+Pg0K
Pj4+IHNjbWlfc2htXzAgOiBzcmFtQDQ3ZmYwMDAwIHsNCj4+PiAgICAgY29tcGF0aWJsZSA9ICJh
cm0sc2NtaS1zaG1lbSI7DQo+Pj4gICAgIHJlZyA9IDwweDAgMHg0N2ZmMDAwMCAweDAgMHgxMDAw
PjsNCj4+PiB9Ow0KPj4+IGZpcm13YXJlIHsNCj4+PiAgICAgc2NtaTogc2NtaSB7DQo+Pj4gICAg
ICAgICBjb21wYXRpYmxlID0gImFybSxzY21pLXNtYyI7DQo+Pj4gICAgICAgICBhcm0sIHNtYyAt
IGlkID0gPDB4ODIwMDAwMDI+OyAvLyBYZW4gbWFuZWdlbWVudCBhZ2VudCBzbWMtaWQNCj4+IHNv
bWUgZXh0cmEgc3BhY2VzLCBpdCBtaWdodCBiZSBhIGNvcHkvcGFzdGUgZXJyb3INCj4+DQo+Pg0K
Pj4+ICAgICAgICAgXCNhZGRyZXNzLWNlbGxzID0gPCAxPjsNCj4+PiAgICAgICAgIFwjc2l6ZS1j
ZWxscyA9IDwgMD47DQo+Pj4gICAgICAgICBcI2FjY2Vzcy1jb250cm9sbGVyIC0gY2VsbHMgPSA8
IDE+Ow0KPj4+ICAgICAgICAgc2htZW0gPSA8JnNjbWlfc2htXzA+OyAvLyBYZW4gbWFuZWdlbWVu
dCBhZ2VudCBzaG1lbQ0KPj4+DQo+Pj4gICAgICAgICBwcm90b2NvbEBYew0KPj4+ICAgICAgICAg
fTsNCj4+PiAgICAgfTsNCj4+PiB9Ow0KPj4+DQo+Pj4gLSBJdCBvYnRhaW5zIFhlbiBzcGVjaWZp
YyBTQ01JIEFnZW50J3MgY29uZmlndXJhdGlvbiBmcm9tIHRoZSBIb3N0IERULA0KPj4+IHByb2Jl
cyBBZ2VudHMgYW5kIGJ1aWxkIFNDTUkgQWdlbnRzIGxpc3Q7IFRoZSBBZ2VudHMgY29uZmlndXJh
dGlvbiBpcyB0YWtlbiBmcm9tOg0KPj4+DQo+Pj4gY2hvc2VuIHsNCj4+PiAgIHhlbixzY21pLXNl
Y29uZGFyeS1hZ2VudHMgPSA8DQo+Pj4gMSAweDgyMDAwMDAzICZzY21pX3NobV8xDQo+Pj4gMiAw
eDgyMDAwMDA0ICZzY21pX3NobV8yDQo+Pj4gMyAweDgyMDAwMDA1ICZzY21pX3NobV8zDQo+Pj4g
NCAweDgyMDAwMDA2ICZzY21pX3NobV80PjsNCj4+PiB9DQo+Pj4NCj4+PiAvew0KPj4+IHNjbWlf
c2htXzE6IHNyYW1ANDdmZjEwMDAgew0KPj4+IGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0i
Ow0KPj4+IHJlZyA9IDwweDAgMHg0N2ZmMTAwMCAweDAgMHgxMDAwPjsNCj4+PiB9Ow0KPj4+IHNj
bWlfc2htXzI6IHNyYW1ANDdmZjIwMDAgew0KPj4+IGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2ht
ZW0iOw0KPj4+IHJlZyA9IDwweDAgMHg0N2ZmMjAwMCAweDAgMHgxMDAwPjsNCj4+PiB9Ow0KPj4+
IHNjbWlfc2htXzM6IHNyYW1ANDdmZjMwMDAgew0KPj4+IGNvbXBhdGlibGUgPSAiYXJtLHNjbWkt
c2htZW0iOw0KPj4+IHJlZyA9IDwweDAgMHg0N2ZmMzAwMCAweDAgMHgxMDAwPjsNCj4+PiB9Ow0K
Pj4+IH0NCj4+PiAgIHdoZXJlIGZpcnN0IGl0ZW0gaXMgImFnZW50X2lkIiwgc2Vjb25kIC0gImFy
bSxzbWMtaWQiLCBhbmQgdGhpcmQgLSAiYXJtLHNjbWktc2htZW0iIGZvcg0KPj4+ICAgdGhpcyBh
Z2VudF9pZC4NCj4+Pg0KPj4+ICAgTm90ZSB0aGF0IFhlbiBpcyB0aGUgb25seSBvbmUgZW50cnkg
aW4gdGhlIHN5c3RlbSB3aGljaCBuZWVkIHRvIGtub3cNCj4+PiAgIGFib3V0IFNDTUkgbXVsdGkt
YWdlbnQgc3VwcG9ydC4NCj4+Pg0KPj4+IC0gSXQgaW1wbGVtZW50cyB0aGUgU0NJIHN1YnN5c3Rl
bSBpbnRlcmZhY2UgcmVxdWlyZWQgZm9yIGNvbmZpZ3VyaW5nIGFuZA0KPj4+IGVuYWJsaW5nIFND
TUkgZnVuY3Rpb25hbGl0eSBmb3IgRG9tMC9od2RvbSBhbmQgR3Vlc3QgZG9tYWlucy4gVG8gZW5h
YmxlDQo+Pj4gU0NNSSBmdW5jdGlvbmFsaXR5IGZvciBkb21haW4gaXQgaGFzIHRvIGJlIGNvbmZp
Z3VyZWQgd2l0aCB1bmlxdWUgc3VwcG9ydGVkDQo+Pj4gU0NNSSBBZ2VudF9pZCBhbmQgdXNlIGNv
cnJlc3BvbmRpbmcgU0NNSSBTTUMvSFZDIHNoYXJlZCBtZW1vcnkgdHJhbnNwb3J0DQo+Pj4gW3Nt
Yy1pZCwgc2htZW1dIGRlZmluZWQgZm9yIHRoaXMgU0NNSSBBZ2VudF9pZC4NCj4+PiAtIE9uY2Ug
WGVuIGRvbWFpbiBpcyBjb25maWd1cmVkIGl0IGNhbiBjb21tdW5pY2F0ZSB3aXRoIEVMMyBTQ01J
IEZXOg0KPj4+ICAgLS0gemVyby1jb3B5LCB0aGUgZ3Vlc3QgZG9tYWluIHB1dHMgU0NNSSBtZXNz
YWdlIGluIHNobWVtOw0KPj4+ICAgLS0gdGhlIGd1ZXN0IHRyaWdnZXJzIFNNQy9IVkMgZXhjZXB0
aW9uIHdpdGggc21jLWlkIChkb29yYmVsbCk7DQo+Pj4gICAtLSB0aGUgWGVuIGRyaXZlciBjYXRj
aGVzIGV4Y2VwdGlvbiwgZG8gY2hlY2tzIGFuZCBzeW5jaHJvbm91c2x5IGZvcndhcmRzDQo+Pj4g
ICBpdCB0byBFTDMgRlcuDQo+Pj4gLSB0aGUgWGVuIGRyaXZlciBzZW5kcyBCQVNFX1JFU0VUX0FH
RU5UX0NPTkZJR1VSQVRJT04gbWVzc2FnZSB0byBYZW4NCj4+PiAgIG1hbmFnZW1lbnQgYWdlbnQg
Y2hhbm5lbCBvbiBkb21haW4gZGVzdHJveSBldmVudC4gVGhpcyBhbGxvd3MgdG8gcmVzZXQNCj4+
PiAgIHJlc291cmNlcyB1c2VkIGJ5IGRvbWFpbiBhbmQgc28gaW1wbGVtZW50IHVzZS1jYXNlIGxp
a2UgZG9tYWluIHJlYm9vdC4NCj4+Pg0KPj4+IERvbTAgRW5hYmxlIFNDTUkgU01DOg0KPj4+IC0g
cGFzcyBkb20wX3NjbWlfYWdlbnRfaWQ9PGFnZW50X2lkPiBpbiBYZW4gY29tbWFuZCBsaW5lLiBp
ZiBub3QgcHJvdmlkZWQNCj4+PiAgICBTQ01JIHdpbGwgYmUgZGlzYWJsZWQgZm9yIERvbTAgYW5k
IGFsbCBTQ01JIG5vZGVzIHJlbW92ZWQgZnJvbSBEb20wIERULg0KPj4+ICAgIFRoZSBkcml2ZXIg
dXBkYXRlcyBEb20wIERUIFNDTUkgbm9kZSAiYXJtLHNtYy1pZCIgdmFsdWUgYW5kIGZpeCB1cCBz
aG1lbQ0KPj4+ICAgIG5vZGUgYWNjb3JkaW5nIHRvIGFzc2lnbmVkIGFnZW50X2lkLg0KPj4+DQo+
Pj4gR3Vlc3QgZG9tYWlucyBlbmFibGUgU0NNSSBTTUM6DQo+Pj4gLSB4bC5jZmc6IGFkZCBjb25m
aWd1cmF0aW9uIG9wdGlvbiBhcyBiZWxvdw0KPj4+DQo+Pj4gICAgYXJtX3NjaSA9ICJ0eXBlPXNj
bWlfc21jX211bHRpYWdlbnQsYWdlbnRfaWQ9MiINCj4+Pg0KPj4+IC0geGwuY2ZnOiBlbmFibGUg
YWNjZXNzIHRvIHRoZSAiYXJtLHNjbWktc2htZW0iIHdoaWNoIHNob3VsZCBjb3JyZXNwb25kIGFz
c2lnbmVkIGFnZW50X2lkIGZvcg0KPj4+ICAgIHRoZSBkb21haW4sIGZvciBleGFtcGxlOg0KPj4+
DQo+Pj4gaW9tZW0gPSBbDQo+Pj4gICAgICI0N2ZmMiwxQDIyMDAxIiwNCj4+PiBdDQo+PiBMb29r
aW5nIGF0IHRoZSBjb2RlIGFuZCB0aGUgY29uZmlndXJhdGlvbiBvcHRpb25zLCBpdCBsb29rcyBs
aWtlIGl0IGlzDQo+PiBwb3NzaWJsZSB0byBtYXAgYSBzY21pLXNobWVtIGNoYW5uZWwgYXQgYSBk
aWZmZXJlbnQgYWRkcmVzcyBmb3IgdGhlDQo+PiBndWVzdC4gSXQgc2VlbXMgbGlrZSBpdCB3b3Vs
ZCB3b3JrLiBJcyB0aGF0IGNvcnJlY3Q/DQo+Pg0KPj4NCj4+PiAtIERUOiBhZGQgU0NNSSBub2Rl
cyB0byB0aGUgRHJpdmVyIGRvbWFpbiBwYXJ0aWFsIGRldmljZSB0cmVlIGFzIGluIHRoZQ0KPj4+
IGJlbG93IGV4YW1wbGUuIFRoZSAiYXJtLHNtYy1pZCIgc2hvdWxkIGNvcnJlc3BvbmQgYXNzaWdu
ZWQgYWdlbnRfaWQgZm9yIHRoZSBkb21haW46DQo+Pj4NCj4+PiBwYXNzdGhyb3VnaCB7DQo+Pj4g
ICAgc2NtaV9zaG1fMDogc3JhbUAyMjAwMTAwMCB7DQo+Pj4gICAgICAgIGNvbXBhdGlibGUgPSAi
YXJtLHNjbWktc2htZW0iOw0KPj4+ICAgICAgICByZWcgPSA8MHgwIDB4MjIwMDEwMDAgMHgwIDB4
MTAwMD47DQo+Pj4gICAgfTsNCj4+Pg0KPj4+ICAgIGZpcm13YXJlIHsNCj4+PiAgICAgICAgIGNv
bXBhdGlibGUgPSAic2ltcGxlLWJ1cyI7DQo+Pj4gICAgICAgICAgICAgc2NtaTogc2NtaSB7DQo+
Pj4gICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc21jIjsNCj4+PiAgICAg
ICAgICAgICAgICAgYXJtLHNtYy1pZCA9IDwweDgyMDAwMDA0PjsNCj4+PiAgICAgICAgICAgICAg
ICAgc2htZW0gPSA8JnNjbWlfc2htXzA+Ow0KPj4+ICAgICAgICAgICAgICAgICAuLi4NCj4+PiAg
ICAgICAgICAgICB9DQo+Pj4gICAgIH0NCj4+PiB9DQo+Pj4NCj4+PiBTQ01JICI0LjIuMS4xIERl
dmljZSBzcGVjaWZpYyBhY2Nlc3MgY29udHJvbCINCj4+Pg0KPj4+IFRoZSBYRU4gU0NJIFNDTUkg
U01DIG11bHRpLWFnZW50IGRyaXZlciBwZXJmb3JtcyAiYWNjZXNzLWNvbnRyb2xsZXIiIHByb3Zp
ZGVyIGZ1bmN0aW9uDQo+Pj4gaW4gY2FzZSBFTDMgU0NNSSBGVyBpbXBsZW1lbnRzIFNDTUkgIjQu
Mi4xLjEgRGV2aWNlIHNwZWNpZmljIGFjY2VzcyBjb250cm9sIiBhbmQgcHJvdmlkZXMgdGhlDQo+
Pj4gQkFTRV9TRVRfREVWSUNFX1BFUk1JU1NJT05TIGNvbW1hbmQgdG8gY29uZmlndXJlIHRoZSBk
ZXZpY2VzIHRoYXQgYW4gYWdlbnRzIGhhdmUgYWNjZXNzIHRvLg0KPj4+IFRoZSBEVCBTQ01JIG5v
ZGUgc2hvdWxkICIjYWNjZXNzLWNvbnRyb2xsZXItY2VsbHM9PDE+IiBwcm9wZXJ0eSBhbmQgRFQg
ZGV2aWNlcyBzaG91bGQgYmUgYm91bmQNCj4+PiB0byB0aGUgWGVuIFNDTUkuDQo+Pj4NCj4+PiAm
aTJjMSB7DQo+Pj4gYWNjZXNzLWNvbnRyb2xsZXJzID0gPCZzY21pIDA+Ow0KPj4+IH07DQo+Pj4N
Cj4+PiBUaGUgRG9tMCBhbmQgZG9tMGxlc3MgZG9tYWlucyBEVCBkZXZpY2VzIHdpbGwgYmUgcHJv
Y2Vzc2VkIGF1dG9tYXRpY2FsbHkgdGhyb3VnaA0KPj4+IHNjaV9hc3NpZ25fZHRfZGV2aWNlKCkg
Y2FsbCwgYnV0IHRvIGFzc2lnbiBTQ01JIGRldmljZXMgZnJvbSB0b29sc3RhY2sgdGhlIHhsLmNm
ZzoiZHRkZXYiIHByb3BlcnR5DQo+Pj4gc2hlbGwgYmUgdXNlZDoNCj4+Pg0KPj4+IGR0ZGV2ID0g
Ww0KPj4+ICAgICAiL3NvYy9pMmNAZTY1MDgwMDAiLA0KPj4+IF0NCj4+Pg0KPj4+IHhsLmNmZzpk
dGRldiB3aWxsIGNvbnRhaW4gYWxsIG5vZGVzIHdoaWNoIGFyZSB1bmRlciBTQ01JIG1hbmFnZW1l
bnQgKG5vdCBvbmx5IHRob3NlIHdoaWNoIGFyZSBiZWhpbmQgSU9NTVUpLg0KPj4+DQo+Pj4gWzFd
aHR0cHM6Ly93ZWIuZ2l0Lmtlcm5lbC5vcmcvcHViL3NjbS9saW51eC9rZXJuZWwvZ2l0L3RvcnZh
bGRzL2xpbnV4LmdpdC90cmVlL0RvY3VtZW50YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncy9maXJt
d2FyZS9hcm0sc2NtaS55YW1sDQo+Pj4gWzJdaHR0cHM6Ly93ZWIuZ2l0Lmtlcm5lbC5vcmcvcHVi
L3NjbS9saW51eC9rZXJuZWwvZ2l0L3RvcnZhbGRzL2xpbnV4LmdpdC90cmVlL0RvY3VtZW50YXRp
b24vZGV2aWNldHJlZS9iaW5kaW5ncy9hY2Nlc3MtY29udHJvbGxlcnMvYWNjZXNzLWNvbnRyb2xs
ZXJzLnlhbWwNCj4+PiBTaWduZWQtb2ZmLWJ5OiBPbGVrc2lpIE1vaXNpZWlldjxvbGVrc2lpX21v
aXNpZWlldkBlcGFtLmNvbT4NCj4+PiBTaWduZWQtb2ZmLWJ5OiBHcnlnb3JpaSBTdHJhc2hrbzxn
cnlnb3JpaV9zdHJhc2hrb0BlcGFtLmNvbT4NCj4+IFRoYW5rcyBmb3IgdGhlIGxvbmcgZXhwbGFu
YXRpb24sIGdyZWF0IHdvcmshIEkgYW0gcmVhbGx5IGxvb2tpbmcgZm9yd2FyZA0KPj4gdG8gaGF2
ZSB0aGlzIGZlYXR1cmUgaW4gdGhlIHRyZWUgc29vbi4NCj4+DQo+Pg0KPj4+IC0tLQ0KPj4+DQo+
Pj4gQ2hhbmdlcyBpbiB2NDoNCj4+PiAtIHRvb2xzdGFjayBjb21tZW50cyBmcm9tIEFudGhvbnkg
UEVSQVJEDQo+Pj4gLSBhZGRlZCBkb20wbGVzcyBzdXBwb3J0DQo+Pj4gLSBhZGRlZCBkb2MgZm9y
ICJ4ZW4sc2NtaS1zZWNvbmRhcnktYWdlbnRzIg0KPj4+DQo+Pj4gZG9jcy9tYW4veGwuY2ZnLjUu
cG9kLmluICAgICAgICAgICAgICAgICAgICB8ICAxMyArDQo+Pj4gZG9jcy9taXNjL2FybS9kZXZp
Y2UtdHJlZS9ib290aW5nLnR4dCAgICAgICB8ICA2MCArKw0KPj4+IGRvY3MvbWlzYy94ZW4tY29t
bWFuZC1saW5lLnBhbmRvYyAgICAgICAgICAgfCAgIDkgKw0KPj4+IHRvb2xzL2xpYnMvbGlnaHQv
bGlieGxfYXJtLmMgICAgICAgICAgICAgICAgfCAgIDQgKw0KPj4+IHRvb2xzL2xpYnMvbGlnaHQv
bGlieGxfdHlwZXMuaWRsICAgICAgICAgICAgfCAgIDQgKy0NCj4+PiB0b29scy94bC94bF9wYXJz
ZS5jICAgICAgICAgICAgICAgICAgICAgICAgIHwgIDEyICsNCj4+PiB4ZW4vYXJjaC9hcm0vZG9t
MGxlc3MtYnVpbGQuYyAgICAgICAgICAgICAgIHwgIDExICsNCj4+PiB4ZW4vYXJjaC9hcm0vZG9t
YWluX2J1aWxkLmMgICAgICAgICAgICAgICAgIHwgICAzICstDQo+Pj4geGVuL2FyY2gvYXJtL2Zp
cm13YXJlL0tjb25maWcgICAgICAgICAgICAgICB8ICAxMSArDQo+Pj4geGVuL2FyY2gvYXJtL2Zp
cm13YXJlL01ha2VmaWxlICAgICAgICAgICAgICB8ICAgMSArDQo+Pj4geGVuL2FyY2gvYXJtL2Zp
cm13YXJlL3NjbWktcHJvdG8uaCAgICAgICAgICB8IDE2NCArKysrDQo+Pj4geGVuL2FyY2gvYXJt
L2Zpcm13YXJlL3NjbWktc2htZW0uYyAgICAgICAgICB8IDE3MyArKysrDQo+Pj4geGVuL2FyY2gv
YXJtL2Zpcm13YXJlL3NjbWktc2htZW0uaCAgICAgICAgICB8ICA0NSArDQo+Pj4geGVuL2FyY2gv
YXJtL2Zpcm13YXJlL3NjbWktc21jLW11bHRpYWdlbnQuYyB8IDg2MCArKysrKysrKysrKysrKysr
KysrKw0KPj4+IHhlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLWFybS5oICAgICAgICAgICAgICAgfCAg
IDMgKw0KPj4+IDE1IGZpbGVzIGNoYW5nZWQsIDEzNzEgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlv
bnMoLSkNCj4+PiBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWkt
cHJvdG8uaA0KPj4+IGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2Nt
aS1zaG1lbS5jDQo+Pj4gY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9hcmNoL2FybS9maXJtd2FyZS9z
Y21pLXNobWVtLmgNCj4+PiBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2FyY2gvYXJtL2Zpcm13YXJl
L3NjbWktc21jLW11bHRpYWdlbnQuYw0KPj4+DQo+Pj4gZGlmZiAtLWdpdCBhL2RvY3MvbWFuL3hs
LmNmZy41LnBvZC5pbiBiL2RvY3MvbWFuL3hsLmNmZy41LnBvZC5pbg0KPj4+IGluZGV4IDFjY2Y1
MGI4ZWEuLjMwMmM0NmQ4YmMgMTAwNjQ0DQo+Pj4gLS0tIGEvZG9jcy9tYW4veGwuY2ZnLjUucG9k
LmluDQo+Pj4gKysrIGIvZG9jcy9tYW4veGwuY2ZnLjUucG9kLmluDQo+Pj4gQEAgLTMxMjIsOCAr
MzEyMiwyMSBAQCBzaW5nbGUgU0NNSSBPU1BNIGFnZW50IHN1cHBvcnQuDQo+Pj4gU2hvdWxkIGJl
IHVzZWQgdG9nZXRoZXIgd2l0aCBCPGRvbTBfc2NtaV9zbWNfcGFzc3Rocm91Z2g+IFhlbiBjb21t
YW5kIGxpbmUNCj4+PiBvcHRpb24uDQo+Pj4NCj4+PiArPWl0ZW0gQjxzY21pX3NtY19tdWx0aWFn
ZW50Pg0KPj4+ICsNCj4+PiArRW5hYmxlcyBBUk0gU0NNSSBTTUMgbXVsdGktYWdlbnQgc3VwcG9y
dCBmb3IgdGhlIGd1ZXN0IGJ5IGVuYWJsaW5nIFNDTUkgb3Zlcg0KPj4+ICtTTUMgY2FsbHMgZm9y
d2FyZGluZyBmcm9tIGRvbWFpbiB0byB0aGUgRUwzIGZpcm13YXJlIChsaWtlIFRydXN0ZWQgRmly
bXdhcmUtQSkNCj4+PiArd2l0aCBhIG11bHRpIFNDTUkgT1NQTSBhZ2VudCBzdXBwb3J0LiBUaGUg
U0NNSSBCPGFnZW50X2lkPiBzaG91bGQgYmUNCj4+PiArc3BlY2lmaWVkIGZvciB0aGUgZ3Vlc3Qu
DQo+Pj4gKw0KPj4+ID1iYWNrDQo+Pj4NCj4+PiArPWl0ZW0gQjxhZ2VudF9pZD1OVU1CRVI+DQo+
Pj4gKw0KPj4+ICtTcGVjaWZpZXMgYSBub24temVybyBBUk0gU0NJIGFnZW50IGlkIGZvciB0aGUg
Z3Vlc3QuIFRoaXMgb3B0aW9uIGlzIG1hbmRhdG9yeQ0KPj4+ICtpZiB0aGUgU0NNSSBTTUMgc3Vw
cG9ydCBpcyBlbmFibGVkIGZvciB0aGUgZ3Vlc3QuIFRoZSBhZ2VudCBpZHMgb2YgZG9tYWlucw0K
Pj4+ICtleGlzdGluZyBvbiBhIHNpbmdsZSBob3N0IG11c3QgYmUgdW5pcXVlIGFuZCBpbiB0aGUg
cmFuZ2UgWzEuLjI1NV0uDQo+Pj4gKw0KPj4+ID1iYWNrDQo+Pj4NCj4+PiA9YmFjaw0KPj4+IGRp
ZmYgLS1naXQgYS9kb2NzL21pc2MvYXJtL2RldmljZS10cmVlL2Jvb3RpbmcudHh0IGIvZG9jcy9t
aXNjL2FybS9kZXZpY2UtdHJlZS9ib290aW5nLnR4dA0KPj4+IGluZGV4IDg5NDNjMDQxNzMuLmM4
OTIzYWI4YjIgMTAwNjQ0DQo+Pj4gLS0tIGEvZG9jcy9taXNjL2FybS9kZXZpY2UtdHJlZS9ib290
aW5nLnR4dA0KPj4+ICsrKyBiL2RvY3MvbWlzYy9hcm0vZGV2aWNlLXRyZWUvYm9vdGluZy50eHQN
Cj4+PiBAQCAtMjk2LDYgKzI5NiwyMCBAQCB3aXRoIHRoZSBmb2xsb3dpbmcgcHJvcGVydGllczoN
Cj4+PiAgICAgIFNob3VsZCBiZSB1c2VkIHRvZ2V0aGVyIHdpdGggZG9tMF9zY21pX3NtY19wYXNz
dGhyb3VnaCBYZW4gY29tbWFuZCBsaW5lDQo+Pj4gICAgICBvcHRpb24uDQo+Pj4NCj4+PiArICAg
IC0gInNjbWlfc21jX211bHRpYWdlbnQiDQo+Pj4gKw0KPj4+ICsgICAgRW5hYmxlcyBBUk0gU0NN
SSBTTUMgbXVsdGktYWdlbnQgc3VwcG9ydCBmb3IgdGhlIGd1ZXN0IGJ5IGVuYWJsaW5nIFNDTUkg
b3Zlcg0KPj4+ICsgICAgU01DIGNhbGxzIGZvcndhcmRpbmcgZnJvbSBkb21haW4gdG8gdGhlIEVM
MyBmaXJtd2FyZSAobGlrZSBBUk0NCj4+PiArICAgIFRydXN0ZWQgRmlybXdhcmUtQSkgd2l0aCBh
IG11bHRpIFNDTUkgT1NQTSBhZ2VudCBzdXBwb3J0Lg0KPj4+ICsgICAgVGhlIFNDTUkgYWdlbnRf
aWQgc2hvdWxkIGJlIHNwZWNpZmllZCBmb3IgdGhlIGd1ZXN0IHdpdGggInhlbixzY2lfYWdlbnRf
aWQiDQo+Pj4gKyAgICBwcm9wZXJ0eS4NCj4+PiArDQo+Pj4gKy0gInhlbixzY2lfYWdlbnRfaWQi
DQo+Pj4gKw0KPj4+ICsgICAgU3BlY2lmaWVzIGEgbm9uLXplcm8gQVJNIFNDSSBhZ2VudCBpZCBm
b3IgdGhlIGd1ZXN0LiBUaGlzIG9wdGlvbiBpcw0KPj4+ICsgICAgbWFuZGF0b3J5IGlmIHRoZSBT
Q01JIFNNQyAic2NtaV9zbWNfbXVsdGlhZ2VudCIgc3VwcG9ydCBpcyBlbmFibGVkIGZvcg0KPj4+
ICsgICAgdGhlIGd1ZXN0LiBUaGUgYWdlbnQgaWRzIG9mIGd1ZXN0IG11c3QgYmUgdW5pcXVlIGFu
ZCBpbiB0aGUgcmFuZ2UgWzEuLjI1NV0uDQo+Pj4gKw0KPj4+IFVuZGVyIHRoZSAieGVuLGRvbWFp
biIgY29tcGF0aWJsZSBub2RlLCBvbmUgb3IgbW9yZSBzdWItbm9kZXMgYXJlIHByZXNlbnQgZm9y
IHRoZSBEb21VDQo+Pj4ga2VybmVsIGFuZCByYW1kaXNrLiBAQCAtNzY0LDMgKzc3OCw0OSBAQCBU
aGUgYXV0b21hdGljYWxseSBhbGxvY2F0ZWQNCj4+PiBzdGF0aWMgc2hhcmVkIG1lbW9yeSB3aWxs
IGdldCBtYXBwZWQgYXQgMHg4MDAwMDAwMCBpbiBEb21VMSBndWVzdA0KPj4+IHBoeXNpY2FsIGFk
ZHJlc3Mgc3BhY2UsIGFuZCBhdCAweDkwMDAwMDAwIGluIERvbVUyIGd1ZXN0IHBoeXNpY2FsDQo+
Pj4gYWRkcmVzcyBzcGFjZS4gRG9tVTEgaXMgZXhwbGljaXRseSBkZWZpbmVkIGFzIHRoZSBvd25l
ciBkb21haW4sIGFuZA0KPj4+IERvbVUyIGlzIHRoZSBib3Jyb3dlciBkb21haW4uICsgK1NDTUkg
U01DIG11bHRpLWFnZW50IHN1cHBvcnQNCj4+PiArPT09PT09PT09PT09PT09PT09PT09PT09PT09
PSArICtGb3IgZW5hYmxpbmcgdGhlIEFSTSBTQ01JIFNNQw0KPj4+IG11bHRpLWFnZW50IHN1cHBv
cnQgKGVuYWJsZWQgYnkgQ09ORklHX1NDTUlfU01DX01BKSArdGhlIFhlbg0KPj4+IHNwZWNpZmlj
IFNDTUkgQWdlbnQncyBjb25maWd1cmF0aW9uIHNoZWxsIGJlIHByb3ZpZGVkIGluIHRoZSBIb3N0
IERUDQo+Pj4gK2FjY29yZGluZyB0byB0aGUgU0NNSSBjb21wbGlhbnQgRUwzIEZpcm13YXJlIHNw
ZWNpZmljYXRpb24gd2l0aA0KPj4+ICtBUk0gU01DL0hWQyB0cmFuc3BvcnQgdXNpbmcgcHJvcGVy
dHkgInhlbixzY21pLXNlY29uZGFyeS1hZ2VudHMiIHVuZGVyDQo+Pj4gK3RoZSB0b3AtbGV2ZWwg
ImNob3NlbiIgbm9kZToNCj4+PiArDQo+Pj4gKy0geGVuLHNjbWktc2Vjb25kYXJ5LWFnZW50cw0K
Pj4+ICsNCj4+PiArICAgIERlZmluZXMgYSBzZXQgb2YgU0NNSSBhZ2VudHMgY29uZmlndXJhdGlv
biBzdXBwb3J0ZWQgYnkgU0NNSSBFTDMgRlcgYW5kDQo+Pj4gKyAgICBhdmFpbGFibGUgZm9yIFhl
bi4gRWFjaCBBZ2VudCBkZWZpbmVkIGFzIHRyaXBsZSBjb25zaXN0aW5nIG9mOg0KPj4+ICsgICAg
U0NNSSBhZ2VudF9pZCwNCj4+PiArICAgIFNNQy9IVkMgZnVuY3Rpb25faWQgYXNzaWduZWQgZm9y
IHRoZSBhZ2VudCB0cmFuc3BvcnQgKCJhcm0sc21jLWlkIiksDQo+Pj4gKyAgICBwaGFuZGxlIHRv
IFNDTUkgU0hNIGFzc2lnbmVkIGZvciB0aGUgYWdlbnQgdHJhbnNwb3J0ICgiYXJtLHNjbWktc2ht
ZW0iKS4NCj4+PiArDQo+Pj4gK0FzIGFuIGV4YW1wbGU6DQo+Pj4gKw0KPj4+ICtjaG9zZW4gew0K
Pj4+ICsgICAgeGVuLHNjbWktc2Vjb25kYXJ5LWFnZW50cyA9IDwNCj4+PiArICAgICAgICAxIDB4
ODIwMDAwMDMgJnNjbWlfc2htXzENCj4+PiArICAgICAgICAyIDB4ODIwMDAwMDQgJnNjbWlfc2ht
XzINCj4+PiArICAgICAgICAzIDB4ODIwMDAwMDUgJnNjbWlfc2htXzMNCj4+PiArICAgICAgICA0
IDB4ODIwMDAwMDYgJnNjbWlfc2htXzQ+Ow0KPj4+ICt9DQo+PiBOSVQ6IGl0IHNob3VsZCBiZSB9
Ow0KPj4NCj4+IExvb2tpbmcgYXQgc2NtaV9wcm9iZSwgY29sbGVjdF9hZ2VudHMsIGFuZCB0aGUg
Zm9sbG93aW5nIFNDTUkNCj4+IFNDTUlfQkFTRV9ESVNDT1ZFUl9BR0VOVCByZXF1ZXN0LCBJIHdv
bmRlcjogZG8gd2UgYWN0dWFsbHkgbmVlZCB0aGlzDQo+PiBpbmZvcm1hdGlvbj8NCj4+DQo+PiBJ
dCBsb29rcyBsaWtlIHdlIGNhbiBkaXNjb3ZlciB0aGUgYWdlbmRfaWRzIGZvciBldmVyeSBjaGFu
bmVsLCBJIGd1ZXNzDQo+PiB3aGF0IHdlIG5lZWQgdG8ga25vdyBpcyB0aGUgc2htZW0gbG9jYXRp
b24gZm9yIGV2ZXJ5IGNoYW5uZWw/IEJ1dCB0aGUNCj4+IGZ1bGwgbGlzdCBvZiBzaG1lbSBjaGFu
bmVsIGlzIGF2YWlsYWJsZSBiZWxvdyB0aGFua3MgdG8gdGhlIHNjbWktc2htZW0NCj4+IG5vZGVz
Lg0KPj4NCj4+IFNvLCB3ZSBoYXZlIHRoZSBsaXN0IG9mIHNjbWktc2htZW0gYW55d2F5LCBhbmQg
d2UgY2FuIHByb2JlIHRoZQ0KPj4gYWdlbnRfaWQuIFRoZSBvbmx5IHBhcmFtZXRlciBsZWZ0IGlz
IHRoZSBzbWNfaWQvZnVuY19pZC4NCj4+DQo+PiBPciBtYXliZSBzbWNfaWQvZnVuY19pZCBjYW4g
YmUgY2FsY3VsYXRlZCBmcm9tIGFnZW50X2lkPw0KPj4NCj4+IEkgYW0gYXNraW5nIG1vc3RseSBi
ZWNhdXNlIGlmIGEgdXNlciBpcyBzdXBwb3NlZCB0byBhZGQgdGhpcw0KPj4geGVuLHNjbWktc2Vj
b25kYXJ5LWFnZW50cyBwcm9wZXJ0eSwgd2hlcmUgYXJlIHRoZXkgc3VwcG9zZWQgdG8gZmluZCB0
aGUNCj4+IHNtY19pZC9mdW5jX2lkIGluZm9ybWF0aW9uPw0KPj4NCj4+IEl0IGlzIGltcG9ydGFu
dCB0aGF0IHdlIHdyaXRlIGRvd24gaW4gdGhpcyBkb2N1bWVudCBob3cgdGhlIHVzZXIgaXMNCj4+
IGV4cGVjdGVkIHRvIGZpbmQgb3V0IHdoYXQgMSBpcyAweDgyMDAwMDAzIHdoaWNoIGlzIHNjbWlf
c2htXzEuDQo+Pg0KPj4NCj4+PiArL3sNCj4+PiArICAgICAgICBzY21pX3NobV8xOiBzcmFtQDQ3
ZmYxMDAwIHsNCj4+PiArICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2ht
ZW0iOw0KPj4+ICsgICAgICAgICAgICAgICAgcmVnID0gPDB4MCAweDQ3ZmYxMDAwIDB4MCAweDEw
MDA+Ow0KPj4+ICsgICAgICAgIH07DQo+Pj4gKyAgICAgICAgc2NtaV9zaG1fMjogc3JhbUA0N2Zm
MjAwMCB7DQo+Pj4gKyAgICAgICAgICAgICAgICBjb21wYXRpYmxlID0gImFybSxzY21pLXNobWVt
IjsNCj4+PiArICAgICAgICAgICAgICAgIHJlZyA9IDwweDAgMHg0N2ZmMjAwMCAweDAgMHgxMDAw
PjsNCj4+PiArICAgICAgICB9Ow0KPj4+ICsgICAgICAgIHNjbWlfc2htXzM6IHNyYW1ANDdmZjMw
MDAgew0KPj4+ICsgICAgICAgICAgICAgICAgY29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zaG1lbSI7
DQo+Pj4gKyAgICAgICAgICAgICAgICByZWcgPSA8MHgwIDB4NDdmZjMwMDAgMHgwIDB4MTAwMD47
DQo+Pj4gKyAgICAgICAgfTsNCj4+PiArICAgICAgICBzY21pX3NobV8zOiBzcmFtQDQ3ZmY0MDAw
IHsNCj4+PiArICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0K
Pj4+ICsgICAgICAgICAgICAgICAgcmVnID0gPDB4MCAweDQ3ZmY0MDAwIDB4MCAweDEwMDA+Ow0K
Pj4+ICsgICAgICAgIH07DQo+PiBBcmUgdGhlc2Ugc2NtaV9zaG1fMSAtIHNjbWlfc2htXzMgdW5k
ZXIgdGhlIHRvcCBsZXZlbCBkZXZpY2UgdHJlZSBub2RlPw0KPj4gT3IgYXJlIHVuZGVyIC9maXJt
d2FyZT8gT3IgYXJlIHRoZXkgdW5kZXIgL2Nob3Nlbj8NCj4+DQo+PiBJIHRha2UgdGhleSBhcmUg
dW5kZXIgdGhlIHRvcCBsZXZlbCBub2RlIHRvZ2V0aGVyIHdpdGggc2NtaV9zaG1fMD8NCj4+DQo+
PiBDYW4geW91IHBsZWFzZSBhbHNvIGNsYXJpZnkgaW4gdGhlIGRvY3VtZW50IGFzIHdlbGw/DQo+
Pg0KPj4NCj4+PiArfQ0KPj4+IGRpZmYgLS1naXQgYS9kb2NzL21pc2MveGVuLWNvbW1hbmQtbGlu
ZS5wYW5kb2MgYi9kb2NzL21pc2MveGVuLWNvbW1hbmQtbGluZS5wYW5kb2MNCj4+PiBpbmRleCA4
ZTUwZjZiN2M3Li5iYzNjNjRkNmVjIDEwMDY0NA0KPj4+IC0tLSBhL2RvY3MvbWlzYy94ZW4tY29t
bWFuZC1saW5lLnBhbmRvYw0KPj4+ICsrKyBiL2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLnBh
bmRvYw0KPj4+IEBAIC0xMDkxLDYgKzEwOTEsMTUgQEAgd2hpY2ggc2VydmVzIGFzIERyaXZlciBk
b21haW4uIFRoZSBTQ01JIHdpbGwgYmUgZGlzYWJsZWQgZm9yIERvbTAvaHdkb20gYW5kDQo+Pj4g
U0NNSSBub2RlcyByZW1vdmVkIGZyb20gRG9tMC9od2RvbSBkZXZpY2UgdHJlZS4NCj4+PiAoZm9y
IGV4YW1wbGUsIHRoaW4gRG9tMCB3aXRoIERyaXZlciBkb21haW4gdXNlLWNhc2UpLg0KPj4+DQo+
Pj4gKyMjIyBkb20wX3NjbWlfYWdlbnRfaWQgKEFSTSkNCj4+PiArPiBgPSA8aW50ZWdlcj5gDQo+
Pj4gKw0KPj4+ICtUaGUgb3B0aW9uIGlzIGF2YWlsYWJsZSB3aGVuIGBDT05GSUdfU0NNSV9TTUNf
TUFgIGlzIGNvbXBpbGVkIGluLCBhbmQgYWxsb3dzIHRvDQo+Pj4gK2VuYWJsZSBTQ01JIGZ1bmN0
aW9uYWxpdHkgZm9yIERvbTAgYnkgc3BlY2lmeWluZyBhIG5vbi16ZXJvIEFSTSBTQ01JIGFnZW50
IGlkLg0KPj4+ICtUaGUgU0NNSSB3aWxsIGJlIGRpc2FibGVkIGZvciBEb20wIGlmIHRoaXMgb3B0
aW9uIGlzIG5vdCBzcGVjaWZpZWQNCj4+PiArKGZvciBleGFtcGxlLCB0aGluIERvbTAgb3IgZG9t
MGxlc3MgdXNlLWNhc2VzKS4NCj4+PiArVGhlIGFnZW50IGlkcyBvZiBkb21haW5zIGV4aXN0aW5n
IG9uIGEgc2luZ2xlIGhvc3QgbXVzdCBiZSB1bmlxdWUuDQo+Pj4gKw0KPj4+ICMjIyBkdHVhcnQg
KEFSTSkNCj4+Pj4gYD0gcGF0aCBbOm9wdGlvbnNdYA0KPj4+IGRpZmYgLS1naXQgYS90b29scy9s
aWJzL2xpZ2h0L2xpYnhsX2FybS5jIGIvdG9vbHMvbGlicy9saWdodC9saWJ4bF9hcm0uYw0KPj4+
IGluZGV4IDI4YmE5ZWI3ODcuLjc3MTJmNTNjZDQgMTAwNjQ0DQo+Pj4gLS0tIGEvdG9vbHMvbGli
cy9saWdodC9saWJ4bF9hcm0uYw0KPj4+ICsrKyBiL3Rvb2xzL2xpYnMvbGlnaHQvbGlieGxfYXJt
LmMNCj4+PiBAQCAtMjI5LDYgKzIyOSwxMCBAQCBpbnQgbGlieGxfX2FyY2hfZG9tYWluX3ByZXBh
cmVfY29uZmlnKGxpYnhsX19nYyAqZ2MsDQo+Pj4gICAgICBjYXNlIExJQlhMX0FSTV9TQ0lfVFlQ
RV9TQ01JX1NNQzoNCj4+PiAgICAgICAgICBjb25maWctPmFyY2guYXJtX3NjaV90eXBlID0gWEVO
X0RPTUNUTF9DT05GSUdfQVJNX1NDSV9TQ01JX1NNQzsNCj4+PiAgICAgICAgICBicmVhazsNCj4+
PiArICAgIGNhc2UgTElCWExfQVJNX1NDSV9UWVBFX1NDTUlfU01DX01VTFRJQUdFTlQ6DQo+Pj4g
KyAgICAgICAgY29uZmlnLT5hcmNoLmFybV9zY2lfdHlwZSA9IFhFTl9ET01DVExfQ09ORklHX0FS
TV9TQ0lfU0NNSV9TTUNfTUE7DQo+Pj4gKyAgICAgICAgY29uZmlnLT5hcmNoLmFybV9zY2lfYWdl
bnRfaWQgPSBkX2NvbmZpZy0+Yl9pbmZvLmFyY2hfYXJtLmFybV9zY2kuYWdlbnRfaWQ7DQo+Pj4g
KyAgICAgICAgYnJlYWs7DQo+Pj4gICAgICBkZWZhdWx0Og0KPj4+ICAgICAgICAgIExPRyhFUlJP
UiwgIlVua25vd24gQVJNX1NDSSB0eXBlICVkIiwNCj4+PiAgICAgICAgICAgICAgZF9jb25maWct
PmJfaW5mby5hcmNoX2FybS5hcm1fc2NpLnR5cGUpOw0KPj4+IGRpZmYgLS1naXQgYS90b29scy9s
aWJzL2xpZ2h0L2xpYnhsX3R5cGVzLmlkbCBiL3Rvb2xzL2xpYnMvbGlnaHQvbGlieGxfdHlwZXMu
aWRsDQo+Pj4gaW5kZXggYWEyMTkwYWI1Yi4uMTFlMzFjZTc4NiAxMDA2NDQNCj4+PiAtLS0gYS90
b29scy9saWJzL2xpZ2h0L2xpYnhsX3R5cGVzLmlkbA0KPj4+ICsrKyBiL3Rvb2xzL2xpYnMvbGln
aHQvbGlieGxfdHlwZXMuaWRsDQo+Pj4gQEAgLTU1MywxMSArNTUzLDEzIEBAIGxpYnhsX3N2ZV90
eXBlID0gRW51bWVyYXRpb24oInN2ZV90eXBlIiwgWw0KPj4+DQo+Pj4gbGlieGxfYXJtX3NjaV90
eXBlID0gRW51bWVyYXRpb24oImFybV9zY2lfdHlwZSIsIFsNCj4+PiAgICAgICgwLCAibm9uZSIp
LA0KPj4+IC0gICAgKDEsICJzY21pX3NtYyIpDQo+Pj4gKyAgICAoMSwgInNjbWlfc21jIiksDQo+
Pj4gKyAgICAoMiwgInNjbWlfc21jX211bHRpYWdlbnQiKQ0KPj4+ICAgICAgXSwgaW5pdF92YWwg
PSAiTElCWExfQVJNX1NDSV9UWVBFX05PTkUiKQ0KPj4+DQo+Pj4gbGlieGxfYXJtX3NjaSA9IFN0
cnVjdCgiYXJtX3NjaSIsIFsNCj4+PiAgICAgICgidHlwZSIsIGxpYnhsX2FybV9zY2lfdHlwZSks
DQo+Pj4gKyAgICAoImFnZW50X2lkIiwgdWludDgpDQo+Pj4gICAgICBdKQ0KPj4+DQo+Pj4gbGli
eGxfcmRtX3Jlc2VydmUgPSBTdHJ1Y3QoInJkbV9yZXNlcnZlIiwgWw0KPj4+IGRpZmYgLS1naXQg
YS90b29scy94bC94bF9wYXJzZS5jIGIvdG9vbHMveGwveGxfcGFyc2UuYw0KPj4+IGluZGV4IGJk
MjJiZTlkMzMuLjgxYWEzNzk3ZTMgMTAwNjQ0DQo+Pj4gLS0tIGEvdG9vbHMveGwveGxfcGFyc2Uu
Yw0KPj4+ICsrKyBiL3Rvb2xzL3hsL3hsX3BhcnNlLmMNCj4+PiBAQCAtMTMwNiw2ICsxMzA2LDE4
IEBAIHN0YXRpYyBpbnQgcGFyc2VfYXJtX3NjaV9jb25maWcoWExVX0NvbmZpZyAqY2ZnLCBsaWJ4
bF9hcm1fc2NpICphcm1fc2NpLA0KPj4+ICAgICAgICAgICAgICB9DQo+Pj4gICAgICAgICAgfQ0K
Pj4+DQo+Pj4gKyAgICAgICAgaWYgKE1BVENIX09QVElPTigiYWdlbnRfaWQiLCBwdHIsIG9wYXJn
KSkgew0KPj4+ICsgICAgICAgICAgICB1bnNpZ25lZCBsb25nIHZhbCA9IHBhcnNlX3Vsb25nKG9w
YXJnKTsNCj4+PiArDQo+Pj4gKyAgICAgICAgICAgIGlmICghdmFsIHx8IHZhbCA+IDI1NSkgew0K
Pj4+ICsgICAgICAgICAgICAgICAgZnByaW50ZihzdGRlcnIsICJBbiBpbnZhbGlkIEFSTV9TQ0kg
YWdlbnRfaWQgc3BlY2lmaWVkICglbHUpLiBWYWxpZCByYW5nZSBbMS4uMjU1XVxuIiwNCj4+PiAr
ICAgICAgICAgICAgICAgICAgICAgICAgdmFsKTsNCj4+PiArICAgICAgICAgICAgICAgIHJldCA9
IEVSUk9SX0lOVkFMOw0KPj4+ICsgICAgICAgICAgICAgICAgZ290byBwYXJzZV9lcnJvcjsNCj4+
PiArICAgICAgICAgICAgfQ0KPj4+ICsgICAgICAgICAgICBhcm1fc2NpLT5hZ2VudF9pZCA9IHZh
bDsNCj4+PiArICAgICAgICB9DQo+Pj4gKw0KPj4+ICAgICAgICAgIHB0ciA9IHN0cnRvayhOVUxM
LCAiLCIpOw0KPj4+ICAgICAgfQ0KPj4+DQo+Pj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9k
b20wbGVzcy1idWlsZC5jIGIveGVuL2FyY2gvYXJtL2RvbTBsZXNzLWJ1aWxkLmMNCj4+PiBpbmRl
eCAwYTAwZjAzYTI1Li40M2QyMWViODg5IDEwMDY0NA0KPj4+IC0tLSBhL3hlbi9hcmNoL2FybS9k
b20wbGVzcy1idWlsZC5jDQo+Pj4gKysrIGIveGVuL2FyY2gvYXJtL2RvbTBsZXNzLWJ1aWxkLmMN
Cj4+PiBAQCAtODM1LDYgKzgzNSwxNyBAQCBpbnQgX19pbml0IGRvbXVfZHRfc2NpX3BhcnNlKHN0
cnVjdCBkdF9kZXZpY2Vfbm9kZSAqbm9kZSwNCj4+PiAgICAgICAgICBkX2NmZy0+YXJjaC5hcm1f
c2NpX3R5cGUgPSBYRU5fRE9NQ1RMX0NPTkZJR19BUk1fU0NJX05PTkU7DQo+Pj4gICAgICBlbHNl
IGlmICggIXN0cmNtcChzY2lfdHlwZSwgInNjbWlfc21jIikgKQ0KPj4+ICAgICAgICAgIGRfY2Zn
LT5hcmNoLmFybV9zY2lfdHlwZSA9IFhFTl9ET01DVExfQ09ORklHX0FSTV9TQ0lfU0NNSV9TTUM7
DQo+Pj4gKyAgICBlbHNlIGlmICggIXN0cmNtcChzY2lfdHlwZSwgInNjbWlfc21jX211bHRpYWdl
bnQiKSApDQo+Pj4gKyAgICB7DQo+Pj4gKyAgICAgICAgdWludDMyX3QgYWdlbnRfaWQgPSAwOw0K
Pj4+ICsNCj4+PiArICAgICAgICBpZiAoICFkdF9wcm9wZXJ0eV9yZWFkX3UzMihub2RlLCAieGVu
LHNjaV9hZ2VudF9pZCIsICZhZ2VudF9pZCkgfHwNCj4+PiArICAgICAgICAgICAgICFhZ2VudF9p
ZCApDQo+PiBzaG91bGRuJ3Qgd2UgY2hlY2sgdGhhdCBhZ2VudF9pZCA8PSAyNTUgPw0KPj4NCj4+
DQo+Pj4gKyAgICAgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4+ICsNCj4+PiArICAgICAgICBk
X2NmZy0+YXJjaC5hcm1fc2NpX3R5cGUgPSBYRU5fRE9NQ1RMX0NPTkZJR19BUk1fU0NJX1NDTUlf
U01DX01BOw0KPj4+ICsgICAgICAgIGRfY2ZnLT5hcmNoLmFybV9zY2lfYWdlbnRfaWQgPSBhZ2Vu
dF9pZDsNCj4+PiArICAgIH0NCj4+PiAgICAgIGVsc2UNCj4+PiAgICAgIHsNCj4+PiAgICAgICAg
ICBwcmludGsoWEVOTE9HX0VSUiAieGVuLHNjaV90eXBlIGluIG5vdCB2YWxpZCAoJXMpIGZvciBk
b21haW4gJXNcbiIsDQo+Pj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9kb21haW5fYnVpbGQu
YyBiL3hlbi9hcmNoL2FybS9kb21haW5fYnVpbGQuYw0KPj4+IGluZGV4IDM2ZDI4YjUyYTQuLjBj
OTI3NGEyYjMgMTAwNjQ0DQo+Pj4gLS0tIGEveGVuL2FyY2gvYXJtL2RvbWFpbl9idWlsZC5jDQo+
Pj4gKysrIGIveGVuL2FyY2gvYXJtL2RvbWFpbl9idWlsZC5jDQo+Pj4gQEAgLTYxNiw3ICs2MTYs
OCBAQCBzdGF0aWMgaW50IF9faW5pdCB3cml0ZV9wcm9wZXJ0aWVzKHN0cnVjdCBkb21haW4gKmQs
IHN0cnVjdCBrZXJuZWxfaW5mbyAqa2luZm8sDQo+Pj4gICAgICAgICAgICAgICAgICAgZHRfcHJv
cGVydHlfbmFtZV9pc19lcXVhbChwcm9wLCAibGludXgsdWVmaS1tbWFwLXN0YXJ0IikgfHwNCj4+
PiAgICAgICAgICAgICAgICAgICBkdF9wcm9wZXJ0eV9uYW1lX2lzX2VxdWFsKHByb3AsICJsaW51
eCx1ZWZpLW1tYXAtc2l6ZSIpIHx8DQo+Pj4gICAgICAgICAgICAgICAgICAgZHRfcHJvcGVydHlf
bmFtZV9pc19lcXVhbChwcm9wLCAibGludXgsdWVmaS1tbWFwLWRlc2Mtc2l6ZSIpIHx8DQo+Pj4g
LSAgICAgICAgICAgICAgICAgZHRfcHJvcGVydHlfbmFtZV9pc19lcXVhbChwcm9wLCAibGludXgs
dWVmaS1tbWFwLWRlc2MtdmVyIikpDQo+Pj4gKyAgICAgICAgICAgICAgICAgZHRfcHJvcGVydHlf
bmFtZV9pc19lcXVhbChwcm9wLCAibGludXgsdWVmaS1tbWFwLWRlc2MtdmVyIikgfHwNCj4+PiAr
ICAgICAgICAgICAgICAgICBkdF9wcm9wZXJ0eV9uYW1lX2lzX2VxdWFsKHByb3AsICJ4ZW4sc2Nt
aS1zZWNvbmRhcnktYWdlbnRzIikgKQ0KPj4+ICAgICAgICAgICAgICAgICAgY29udGludWU7DQo+
Pj4NCj4+PiAgICAgICAgICAgICAgaWYgKCBkdF9wcm9wZXJ0eV9uYW1lX2lzX2VxdWFsKHByb3As
ICJ4ZW4sZG9tMC1ib290YXJncyIpICkgZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9maXJtd2Fy
ZS9LY29uZmlnDQo+Pj4gYi94ZW4vYXJjaC9hcm0vZmlybXdhcmUvS2NvbmZpZyBpbmRleCA1YzVm
MDg4MGM0Li42YjA1MWM4YWRhIDEwMDY0NA0KPj4+IC0tLSBhL3hlbi9hcmNoL2FybS9maXJtd2Fy
ZS9LY29uZmlnICsrKw0KPj4+IGIveGVuL2FyY2gvYXJtL2Zpcm13YXJlL0tjb25maWcgQEAgLTI5
LDYgKzI5LDE3IEBAIGNvbmZpZyBTQ01JX1NNQw0KPj4+IGRyaXZlciBkb21haW4uIFVzZSB3aXRo
IEVMMyBmaXJtd2FyZSB3aGljaCBzdXBwb3J0cyBvbmx5IHNpbmdsZSBTQ01JDQo+Pj4gT1NQTSBh
Z2VudC4gK2NvbmZpZyBTQ01JX1NNQ19NQSArIGJvb2wgIkVuYWJsZSBBUk0gU0NNSSBTTUMgbXVs
dGktYWdlbnQgZHJpdmVyIg0KPj4+ICsgc2VsZWN0IEFSTV9TQ0kNCj4+PiArIGhlbHANCj4+PiAr
ICAgRW5hYmxlcyBTQ01JIFNNQy9IVkMgbXVsdGktYWdlbnQgaW4gWEVOIHRvIHBhc3MgU0NNSSBy
ZXF1ZXN0cyBmcm9tIERvbWFpbnMNCj4+PiArICAgdG8gRUwzIGZpcm13YXJlIChURi1BKSB3aGlj
aCBzdXBwb3J0cyBtdWx0aS1hZ2VudCBmZWF0dXJlLg0KPj4+ICsgICBUaGlzIGZlYXR1cmUgYWxs
b3dzIHRvIGVuYWJsZSBTQ01JIHBlciBEb21haW4gdXNpbmcgdW5pcXVlIFNDTUkgYWdlbnRfaWQs
DQo+Pj4gKyAgIHNvIERvbWFpbiBpcyBpZGVudGlmaWVkIGJ5IEVMMyBmaXJtd2FyZSBhcyBhbiBT
Q01JIEFnZW50IGFuZCBjYW4gYWNjZXNzDQo+Pj4gKyAgIGFsbG93ZWQgcGxhdGZvcm0gcmVzb3Vy
Y2VzIHRocm91Z2ggZGVkaWNhdGVkIFNNQy9IVkMgU2hhcmVkIG1lbW9yeSBiYXNlZA0KPj4+ICsg
ICB0cmFuc3BvcnQuDQo+Pj4gKw0KPj4+IGVuZGNob2ljZQ0KPj4+DQo+Pj4gZW5kbWVudQ0KPj4+
IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vZmlybXdhcmUvTWFrZWZpbGUgYi94ZW4vYXJjaC9h
cm0vZmlybXdhcmUvTWFrZWZpbGUNCj4+PiBpbmRleCA3MWJkZWZjMjRhLi4zNzkyN2U2OTBlIDEw
MDY0NA0KPj4+IC0tLSBhL3hlbi9hcmNoL2FybS9maXJtd2FyZS9NYWtlZmlsZQ0KPj4+ICsrKyBi
L3hlbi9hcmNoL2FybS9maXJtd2FyZS9NYWtlZmlsZQ0KPj4+IEBAIC0xLDIgKzEsMyBAQA0KPj4+
IG9iai0kKENPTkZJR19BUk1fU0NJKSArPSBzY2kubw0KPj4+IG9iai0kKENPTkZJR19TQ01JX1NN
QykgKz0gc2NtaS1zbWMubw0KPj4+ICtvYmotJChDT05GSUdfU0NNSV9TTUNfTUEpICs9IHNjbWkt
c2htZW0ubyBzY21pLXNtYy1tdWx0aWFnZW50Lm8NCj4+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gv
YXJtL2Zpcm13YXJlL3NjbWktcHJvdG8uaCBiL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXBy
b3RvLmgNCj4+PiBuZXcgZmlsZSBtb2RlIDEwMDY0NA0KPj4+IGluZGV4IDAwMDAwMDAwMDAuLjNm
NGI5YzVkNmINCj4+PiAtLS0gL2Rldi9udWxsDQo+Pj4gKysrIGIveGVuL2FyY2gvYXJtL2Zpcm13
YXJlL3NjbWktcHJvdG8uaA0KPj4+IEBAIC0wLDAgKzEsMTY0IEBADQo+Pj4gKy8qIFNQRFgtTGlj
ZW5zZS1JZGVudGlmaWVyOiBHUEwtMi4wLW9ubHkgKi8NCj4+PiArLyoNCj4+PiArICogQXJtIFN5
c3RlbSBDb250cm9sIGFuZCBNYW5hZ2VtZW50IEludGVyZmFjZSBkZWZpbml0aW9ucw0KPj4+ICsg
KiBWZXJzaW9uIDMuMCAoREVOMDA1NkMpDQo+Pj4gKyAqDQo+Pj4gKyAqIENvcHlyaWdodCAoYykg
MjAyNCBFUEFNIFN5c3RlbXMNCj4+PiArICovDQo+Pj4gKw0KPj4+ICsjaWZuZGVmIFhFTl9BUkNI
X0FSTV9TQ0lfU0NNSV9QUk9UT19IXw0KPj4+ICsjZGVmaW5lIFhFTl9BUkNIX0FSTV9TQ0lfU0NN
SV9QUk9UT19IXw0KPj4gTklUOiBBUk1fRklSTVdBUkVfU0NNSV9QUk9UT19IDQo+Pg0KPj4NCj4+
PiArI2luY2x1ZGUgPHhlbi9zdGRpbnQuaD4NCj4+PiArDQo+Pj4gKyNkZWZpbmUgU0NNSV9TSE9S
VF9OQU1FX01BWF9TSVpFIDE2DQo+Pj4gKw0KPj4+ICsvKiBTQ01JIHN0YXR1cyBjb2Rlcy4gU2Vl
IHNlY3Rpb24gNC4xLjQgKi8NCj4+PiArI2RlZmluZSBTQ01JX1NVQ0NFU1MgICAgICAgICAgICAg
IDANCj4+PiArI2RlZmluZSBTQ01JX05PVF9TVVBQT1JURUQgICAgICAoLTEpDQo+Pj4gKyNkZWZp
bmUgU0NNSV9JTlZBTElEX1BBUkFNRVRFUlMgKC0yKQ0KPj4+ICsjZGVmaW5lIFNDTUlfREVOSUVE
ICAgICAgICAgICAgICgtMykNCj4+PiArI2RlZmluZSBTQ01JX05PVF9GT1VORCAgICAgICAgICAo
LTQpDQo+Pj4gKyNkZWZpbmUgU0NNSV9PVVRfT0ZfUkFOR0UgICAgICAgKC01KQ0KPj4+ICsjZGVm
aW5lIFNDTUlfQlVTWSAgICAgICAgICAgICAgICgtNikNCj4+PiArI2RlZmluZSBTQ01JX0NPTU1T
X0VSUk9SICAgICAgICAoLTcpDQo+Pj4gKyNkZWZpbmUgU0NNSV9HRU5FUklDX0VSUk9SICAgICAg
KC04KQ0KPj4+ICsjZGVmaW5lIFNDTUlfSEFSRFdBUkVfRVJST1IgICAgICgtOSkNCj4+PiArI2Rl
ZmluZSBTQ01JX1BST1RPQ09MX0VSUk9SICAgICAoLTEwKQ0KPj4+ICsNCj4+PiArLyogUHJvdG9j
b2wgSURzICovDQo+Pj4gKyNkZWZpbmUgU0NNSV9CQVNFX1BST1RPQ09MIDB4MTANCj4+PiArDQo+
Pj4gKy8qIEJhc2UgcHJvdG9jb2wgbWVzc2FnZSBJRHMgKi8NCj4+PiArI2RlZmluZSBTQ01JX0JB
U0VfUFJPVE9DT0xfVkVSU0lPTiAgICAgICAgICAgIDB4MA0KPj4+ICsjZGVmaW5lIFNDTUlfQkFT
RV9QUk9UT0NPTF9BVFRJQlVURVMgICAgICAgICAgMHgxDQo+Pj4gKyNkZWZpbmUgU0NNSV9CQVNF
X1BST1RPQ09MX01FU1NBR0VfQVRUUklCVVRFUyAweDINCj4+PiArI2RlZmluZSBTQ01JX0JBU0Vf
RElTQ09WRVJfQUdFTlQgICAgICAgICAgICAgIDB4Nw0KPj4+ICsjZGVmaW5lIFNDTUlfQkFTRV9T
RVRfREVWSUNFX1BFUk1JU1NJT05TICAgICAgMHg5DQo+Pj4gKyNkZWZpbmUgU0NNSV9CQVNFX1JF
U0VUX0FHRU5UX0NPTkZJR1VSQVRJT04gICAweEINCj4+PiArDQo+Pj4gK3R5cGVkZWYgc3RydWN0
IHNjbWlfbXNnX2hlYWRlciB7DQo+Pj4gKyAgICB1aW50OF90IGlkOw0KPj4+ICsgICAgdWludDhf
dCB0eXBlOw0KPj4+ICsgICAgdWludDhfdCBwcm90b2NvbDsNCj4+PiArICAgIHVpbnQzMl90IHN0
YXR1czsNCj4+PiArfSBzY21pX21zZ19oZWFkZXJfdDsNCj4+PiArDQo+Pj4gKy8qIFRhYmxlIDIg
TWVzc2FnZSBoZWFkZXIgZm9ybWF0ICovDQo+Pj4gKyNkZWZpbmUgU0NNSV9IRFJfSUQgICAgR0VO
TUFTSyg3LCAwKQ0KPj4+ICsjZGVmaW5lIFNDTUlfSERSX1RZUEUgIEdFTk1BU0soOSwgOCkNCj4+
PiArI2RlZmluZSBTQ01JX0hEUl9QUk9UTyBHRU5NQVNLKDE3LCAxMCkNCj4+PiArDQo+Pj4gKyNk
ZWZpbmUgU0NNSV9GSUVMRF9HRVQoX21hc2ssIF9yZWcpICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBcDQo+Pj4gKyAgICAoKHR5cGVvZihfbWFzaykpKCgoX3JlZykg
JiAoX21hc2spKSA+PiAoZmZzNjQoX21hc2spIC0gMSkpKQ0KPj4+ICsjZGVmaW5lIFNDTUlfRklF
TERfUFJFUChfbWFzaywgX3ZhbCkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgXA0KPj4+ICsgICAgKCgodHlwZW9mKF9tYXNrKSkoX3ZhbCkgPDwgKGZmczY0KF9tYXNr
KSAtIDEpKSAmIChfbWFzaykpDQo+Pj4gKw0KPj4+ICtzdGF0aWMgaW5saW5lIHVpbnQzMl90IHBh
Y2tfc2NtaV9oZWFkZXIoc2NtaV9tc2dfaGVhZGVyX3QgKmhkcikNCj4+PiArew0KPj4+ICsgICAg
cmV0dXJuIFNDTUlfRklFTERfUFJFUChTQ01JX0hEUl9JRCwgaGRyLT5pZCkgfA0KPj4+ICsgICAg
ICAgICAgIFNDTUlfRklFTERfUFJFUChTQ01JX0hEUl9UWVBFLCBoZHItPnR5cGUpIHwNCj4+PiAr
ICAgICAgICAgICBTQ01JX0ZJRUxEX1BSRVAoU0NNSV9IRFJfUFJPVE8sIGhkci0+cHJvdG9jb2wp
Ow0KPj4+ICt9DQo+Pj4gKw0KPj4+ICtzdGF0aWMgaW5saW5lIHZvaWQgdW5wYWNrX3NjbWlfaGVh
ZGVyKHVpbnQzMl90IG1zZ19oZHIsIHNjbWlfbXNnX2hlYWRlcl90ICpoZHIpDQo+Pj4gK3sNCj4+
PiArICAgIGhkci0+aWQgPSBTQ01JX0ZJRUxEX0dFVChTQ01JX0hEUl9JRCwgbXNnX2hkcik7DQo+
Pj4gKyAgICBoZHItPnR5cGUgPSBTQ01JX0ZJRUxEX0dFVChTQ01JX0hEUl9UWVBFLCBtc2dfaGRy
KTsNCj4+PiArICAgIGhkci0+cHJvdG9jb2wgPSBTQ01JX0ZJRUxEX0dFVChTQ01JX0hEUl9QUk9U
TywgbXNnX2hkcik7DQo+Pj4gK30NCj4+PiArDQo+Pj4gK3N0YXRpYyBpbmxpbmUgaW50IHNjbWlf
dG9feGVuX2Vycm5vKGludCBzY21pX3N0YXR1cykNCj4+PiArew0KPj4+ICsgICAgaWYgKCBzY21p
X3N0YXR1cyA9PSBTQ01JX1NVQ0NFU1MgKQ0KPj4+ICsgICAgICAgIHJldHVybiAwOw0KPj4+ICsN
Cj4+PiArICAgIHN3aXRjaCAoIHNjbWlfc3RhdHVzICkNCj4+PiArICAgIHsNCj4+PiArICAgIGNh
c2UgU0NNSV9OT1RfU1VQUE9SVEVEOg0KPj4+ICsgICAgICAgIHJldHVybiAtRU9QTk9UU1VQUDsN
Cj4+PiArICAgIGNhc2UgU0NNSV9JTlZBTElEX1BBUkFNRVRFUlM6DQo+Pj4gKyAgICAgICAgcmV0
dXJuIC1FSU5WQUw7DQo+Pj4gKyAgICBjYXNlIFNDTUlfREVOSUVEOg0KPj4+ICsgICAgICAgIHJl
dHVybiAtRUFDQ0VTOw0KPj4+ICsgICAgY2FzZSBTQ01JX05PVF9GT1VORDoNCj4+PiArICAgICAg
ICByZXR1cm4gLUVOT0VOVDsNCj4+PiArICAgIGNhc2UgU0NNSV9PVVRfT0ZfUkFOR0U6DQo+Pj4g
KyAgICAgICAgcmV0dXJuIC1FUkFOR0U7DQo+Pj4gKyAgICBjYXNlIFNDTUlfQlVTWToNCj4+PiAr
ICAgICAgICByZXR1cm4gLUVCVVNZOw0KPj4+ICsgICAgY2FzZSBTQ01JX0NPTU1TX0VSUk9SOg0K
Pj4+ICsgICAgICAgIHJldHVybiAtRU5PVENPTk47DQo+Pj4gKyAgICBjYXNlIFNDTUlfR0VORVJJ
Q19FUlJPUjoNCj4+PiArICAgICAgICByZXR1cm4gLUVJTzsNCj4+PiArICAgIGNhc2UgU0NNSV9I
QVJEV0FSRV9FUlJPUjoNCj4+PiArICAgICAgICByZXR1cm4gLUVOWElPOw0KPj4+ICsgICAgY2Fz
ZSBTQ01JX1BST1RPQ09MX0VSUk9SOg0KPj4+ICsgICAgICAgIHJldHVybiAtRUJBRE1TRzsNCj4+
PiArICAgIGRlZmF1bHQ6DQo+Pj4gKyAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+Pj4gKyAgICB9
DQo+Pj4gK30NCj4+PiArDQo+Pj4gKy8qIFBST1RPQ09MX1ZFUlNJT04gKi8NCj4+PiArI2RlZmlu
ZSBTQ01JX1ZFUlNJT05fTUlOT1IgR0VOTUFTSygxNSwgMCkNCj4+PiArI2RlZmluZSBTQ01JX1ZF
UlNJT05fTUFKT1IgR0VOTUFTSygzMSwgMTYpDQo+Pj4gKw0KPj4+ICtzdHJ1Y3Qgc2NtaV9tc2df
cHJvdF92ZXJzaW9uX3AyYSB7DQo+Pj4gKyAgICB1aW50MzJfdCB2ZXJzaW9uOw0KPj4+ICt9IF9f
cGFja2VkOw0KPj4+ICsNCj4+PiArLyogQkFTRSBQUk9UT0NPTF9BVFRSSUJVVEVTICovDQo+Pj4g
KyNkZWZpbmUgU0NNSV9CQVNFX0FUVFJfTlVNX1BST1RPIEdFTk1BU0soNywgMCkNCj4+PiArI2Rl
ZmluZSBTQ01JX0JBU0VfQVRUUl9OVU1fQUdFTlQgR0VOTUFTSygxNSwgOCkNCj4+PiArDQo+Pj4g
K3N0cnVjdCBzY21pX21zZ19iYXNlX2F0dHJpYnV0ZXNfcDJhIHsNCj4+PiArICAgIHVpbnQzMl90
IGF0dHJpYnV0ZXM7DQo+Pj4gK30gX19wYWNrZWQ7DQo+Pj4gKw0KPj4+ICsvKg0KPj4+ICsgKiBC
QVNFX0RJU0NPVkVSX0FHRU5UDQo+Pj4gKyAqLw0KPj4+ICsjZGVmaW5lIFNDTUlfQkFTRV9BR0VO
VF9JRF9PV04gMHhGRkZGRkZGRg0KPj4+ICsNCj4+PiArc3RydWN0IHNjbWlfbXNnX2Jhc2VfZGlz
Y292ZXJfYWdlbnRfYTJwIHsNCj4+PiArICAgIHVpbnQzMl90IGFnZW50X2lkOw0KPj4+ICt9IF9f
cGFja2VkOw0KPj4+ICsNCj4+PiArc3RydWN0IHNjbWlfbXNnX2Jhc2VfZGlzY292ZXJfYWdlbnRf
cDJhIHsNCj4+PiArICAgIHVpbnQzMl90IGFnZW50X2lkOw0KPj4+ICsgICAgY2hhciBuYW1lW1ND
TUlfU0hPUlRfTkFNRV9NQVhfU0laRV07DQo+Pj4gK30gX19wYWNrZWQ7DQo+Pj4gKw0KPj4+ICsv
Kg0KPj4+ICsgKiBCQVNFX1NFVF9ERVZJQ0VfUEVSTUlTU0lPTlMNCj4+PiArICovDQo+Pj4gKyNk
ZWZpbmUgU0NNSV9CQVNFX0RFVklDRV9BQ0NFU1NfQUxMT1cgICAgICAgICAgIEJJVCgwLCBVTCkN
Cj4+PiArDQo+Pj4gK3N0cnVjdCBzY21pX21zZ19iYXNlX3NldF9kZXZpY2VfcGVybWlzc2lvbnNf
YTJwIHsNCj4+PiArICAgIHVpbnQzMl90IGFnZW50X2lkOw0KPj4+ICsgICAgdWludDMyX3QgZGV2
aWNlX2lkOw0KPj4+ICsgICAgdWludDMyX3QgZmxhZ3M7DQo+Pj4gK30gX19wYWNrZWQ7DQo+Pj4g
Kw0KPj4+ICsvKg0KPj4+ICsgKiBCQVNFX1JFU0VUX0FHRU5UX0NPTkZJR1VSQVRJT04NCj4+PiAr
ICovDQo+Pj4gKyNkZWZpbmUgU0NNSV9CQVNFX0FHRU5UX1BFUk1JU1NJT05TX1JFU0VUICAgICAg
IEJJVCgwLCBVTCkNCj4+PiArDQo+Pj4gK3N0cnVjdCBzY21pX21zZ19iYXNlX3Jlc2V0X2FnZW50
X2NmZ19hMnAgew0KPj4+ICsgICAgdWludDMyX3QgYWdlbnRfaWQ7DQo+Pj4gKyAgICB1aW50MzJf
dCBmbGFnczsNCj4+PiArfSBfX3BhY2tlZDsNCj4+PiArDQo+Pj4gKyNlbmRpZiAvKiBYRU5fQVJD
SF9BUk1fU0NJX1NDTUlfUFJPVE9fSF8gKi8NCj4+PiArDQo+Pj4gKy8qDQo+Pj4gKyAqIExvY2Fs
IHZhcmlhYmxlczoNCj4+PiArICogbW9kZTogQw0KPj4+ICsgKiBjLWZpbGUtc3R5bGU6ICJCU0Qi
DQo+Pj4gKyAqIGMtYmFzaWMtb2Zmc2V0OiA0DQo+Pj4gKyAqIHRhYi13aWR0aDogNA0KPj4+ICsg
KiBpbmRlbnQtdGFicy1tb2RlOiBuaWwNCj4+PiArICogRW5kOg0KPj4+ICsgKi8NCj4+PiBkaWZm
IC0tZ2l0IGEveGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktc2htZW0uYyBiL3hlbi9hcmNoL2Fy
bS9maXJtd2FyZS9zY21pLXNobWVtLmMNCj4+PiBuZXcgZmlsZSBtb2RlIDEwMDY0NA0KPj4+IGlu
ZGV4IDAwMDAwMDAwMDAuLmRkNjEzZWUwYjUNCj4+PiAtLS0gL2Rldi9udWxsDQo+Pj4gKysrIGIv
eGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktc2htZW0uYw0KPj4+IEBAIC0wLDAgKzEsMTczIEBA
DQo+Pj4gKy8qIFNQRFgtTGljZW5zZS1JZGVudGlmaWVyOiBHUEwtMi4wLW9ubHkgKi8NCj4+PiAr
LyoNCj4+PiArICogU0NJIFNDTUkgbXVsdGktYWdlbnQgZHJpdmVyLCB1c2luZyBTTUMvSFZDIHNo
bWVtIGFzIHRyYW5zcG9ydC4NCj4+PiArICoNCj4+PiArICogT2xla3NpaSBNb2lzaWVpZXY8b2xl
a3NpaV9tb2lzaWVpZXZAZXBhbS5jb20+DQo+Pj4gKyAqIENvcHlyaWdodCAoYykgMjAyNSBFUEFN
IFN5c3RlbXMNCj4+PiArICovDQo+Pj4gKy8qIFNQRFgtTGljZW5zZS1JZGVudGlmaWVyOiBHUEwt
Mi4wLW9ubHkgKi8NCj4+PiArDQo+Pj4gKyNpbmNsdWRlIDxhc20vaW8uaD4NCj4+PiArI2luY2x1
ZGUgPHhlbi9lcnIuaD4NCj4+PiArDQo+Pj4gKyNpbmNsdWRlICJzY21pLXByb3RvLmgiDQo+Pj4g
KyNpbmNsdWRlICJzY21pLXNobWVtLmgiDQo+PiBUaGlzIGNvZGUgaXMgd3JpdHRlbiBtb3JlIGdl
bmVyaWNhbGx5IHRoYW4gdGhlIGRlc2NyaXB0aW9uIGltcGxpZXMuIElmDQo+PiB3ZSBvbmx5IHdh
bnQgdG8gbWFrZSBTTUMgY2FsbHMgdG8gVEYtQSBvbiBFTDMgYW5kIGV4Y2hhbmdlIGRhdGEgd2l0
aCBpdA0KPj4gb3ZlciBzaGFyZWQgbWVtb3J5LCB0aGVuIEkgdGhpbms6DQo+PiAtIHdlIGRvbid0
IG5lZWQgdGhlIF9faW9tZW0gdGFnLCBhcyB0aGVyZSBpcyBubyBNTUlPDQo+IGFncmVlDQo+DQo+
PiAtIHdlIG9ubHkgbmVlZCBhIERNQiwgbm90IGEgRFNCIChyZWFkbCBhbmQgd3JpdGVsIGltcGx5
IERTQiwgdXNlIG9ubHkNCj4+ICAgcmVhZGxfcmVsYXhlZCBhbmQgd3JpdGVsX3JlbGF4ZWQpDQo+
IGFncmVlDQo+DQo+PiBPbiB0aGUgb3RoZXIgaGFuZCwgaWYgd2UgYWxzbyB3YW50IHRvIGhhbmRs
ZSB0aGUgY2FzZSB3aGVyZSB0aGUgU0NNSQ0KPj4gc2VydmVyIGNvdWxkIGJlIG9uIGEgc2VwYXJh
dGUgY28tcHJvY2Vzc29yLCB0aGVuIHdoYXQgdGhpcyBjb2RlIGlzIGRvaW5nDQo+PiBpcyBub3Qg
c3VmZmljaWVudCBiZWNhdXNlIHdlIGFsc28gbmVlZCBhIGRjYWNoZSBmbHVzaCwgaW4gYWRkaXRp
b24gdG8NCj4+IHRoZSBEU0IuDQo+Pg0KPj4gQmVydHJhbmQsIGNhbiB5b3UgZG91YmxlLWNoZWNr
Pw0KPiBJZiB3ZSB3YW50IHRvIGhhbmRsZSBhIGNhc2Ugd2hlcmUgdGhlIG1lbW9yeSBpcyBhY2Nl
c3NpYmxlIHRvIGEgY29wcm9jZXNzb3INCj4gYnV0IHRoZXJlIGlzIG5vIGNhY2hlIGNvaGVyZW5j
eSwgd2UgbmVlZCB0byBmbHVzaCB0aGUgZGNhY2hlIGRlZmluaXRlbHkuDQo+DQo+IFNlZWluZyB0
aGUgYW1vdW50IG9mIGRhdGEgaGVyZSwgSSBkbyBhZ3JlZSB3aXRoIFN0ZWZhbm8gdGhhdCBpdCB3
b3VsZCBiZSBhIGdvb2QNCj4gaWRlYSB0byBtYWtlIHRoZSBwcm92aXNpb24gdG8gZmx1c2ggdGhl
IGRhdGEgY2FjaGUgaW4gYWxsIGNhc2VzLiBFdmVuIGlmIHRoZSBkYXRhDQo+IGlzIGFjY2Vzc2Vk
IGJ5IGEgc2VjdXJlIHBhcnRpdGlvbiBvciB0aGUgZmlybXdhcmUgY29oZXJlbnRseSwgZmx1c2hp
bmcgaW4gYWxsIGNhc2VzDQo+IHdvdWxkIGhhdmUgdmVyeSBsaW1pdGVkIHBlcmZvcm1hbmNlIGlt
cGFjdCBoZXJlLg0KPg0KPiBUaGVyZSBpcyB0aGUgb3RoZXIgc29sdXRpb24gdG8gaGF2ZSBzb21l
IGtpbmQgb2YgcGFyYW1ldGVyIHRvIHNheSBpZiB0aGUgYWNjZXNzb3INCj4gaGFzIGNvaGVyZW50
IGNhY2hlIGFjY2VzcyBidXQgSSBkbyBub3QgdGhpbmsgdGhlIHBlcmZvcm1hbmNlIGltcGFjdCBo
ZXJlIHdvdWxkDQo+IGp1c3RpZnkgc3VjaCBhIGNvbXBsZXhpdHkuDQo+DQo+IENoZWVycw0KPiBC
ZXJ0cmFuZA0KPg0KSG1tLCBJIHRoaW5rIHdlIG5lZWQgbW9yZSBpbnB1dCByZWdhcmRpbmcgbWVt
b3J5IGFjY2VzcyBzaW5jZSBBUk0gdXNlcw0KbWVtY3B5X3tmcm9tL3RvfWlvIGluIHRoZSBMaW51
eCBrZXJuZWwgZHJpdmVyLg0KDQpJdCBtaWdodCBiZSB3b3J0aCBpbnZvbHZpbmcgQ3Jpc3RpYW4g
TWFydXNzaSBpbiB0aGUgZGlzY3Vzc2lvbiwgYXMgaGUgaXMNCnRoZSBhdXRob3Igb2YgdGhlIExp
bnV4IGRyaXZlci4gV2hhdCBkbyB5b3UgdGhpbms/DQoNCg0KPj4+ICsvKg0KPj4+IFRPRE8gcmVt
b3ZlOiBmaXhlZCsgKiBDb3B5IGRhdGEgZnJvbSBJTyBtZW1vcnkgc3BhY2UgdG8gInJlYWwiIG1l
bW9yeSBzcGFjZS4NCj4+PiArICovDQo+Pj4gK3N0YXRpYyB2b2lkIF9fbWVtY3B5X2Zyb21pbyh2
b2lkICp0bywgY29uc3Qgdm9sYXRpbGUgdm9pZCBfX2lvbWVtICpmcm9tLA0KPj4+ICsgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgc2l6ZV90IGNvdW50KQ0KPj4+ICt7DQo+Pj4gKyAgICB3aGls
ZSAoIGNvdW50ICYmICFJU19BTElHTkVEKCh1bnNpZ25lZCBsb25nKWZyb20sIDQpICkNCj4+PiAr
ICAgIHsNCj4+PiArICAgICAgICAqKHU4ICopdG8gPSByZWFkYl9yZWxheGVkKGZyb20pOw0KPj4+
ICsgICAgICAgIGZyb20rKzsNCj4+PiArICAgICAgICB0bysrOw0KPj4+ICsgICAgICAgIGNvdW50
LS07DQo+Pj4gKyAgICB9DQo+Pj4gKw0KPj4+ICsgICAgd2hpbGUgKCBjb3VudCA+PSA0ICkNCj4+
PiArICAgIHsNCj4+PiArICAgICAgICAqKHUzMiAqKXRvID0gcmVhZGxfcmVsYXhlZChmcm9tKTsN
Cj4+PiArICAgICAgICBmcm9tICs9IDQ7DQo+Pj4gKyAgICAgICAgdG8gKz0gNDsNCj4+PiArICAg
ICAgICBjb3VudCAtPSA0Ow0KPj4+ICsgICAgfQ0KPj4+ICsNCj4+PiArICAgIHdoaWxlICggY291
bnQgKQ0KPj4+ICsgICAgew0KPj4+ICsgICAgICAgICoodTggKil0byA9IHJlYWRiX3JlbGF4ZWQo
ZnJvbSk7DQo+Pj4gKyAgICAgICAgZnJvbSsrOw0KPj4+ICsgICAgICAgIHRvKys7DQo+Pj4gKyAg
ICAgICAgY291bnQtLTsNCj4+PiArICAgIH0NCj4+PiArfQ0KPj4+ICsNCj4+PiArLyoNCj4+PiAr
ICogQ29weSBkYXRhIGZyb20gInJlYWwiIG1lbW9yeSBzcGFjZSB0byBJTyBtZW1vcnkgc3BhY2Uu
DQo+Pj4gKyAqLw0KPj4+ICtzdGF0aWMgdm9pZCBfX21lbWNweV90b2lvKHZvbGF0aWxlIHZvaWQg
X19pb21lbSAqdG8sIGNvbnN0IHZvaWQgKmZyb20sDQo+Pj4gKyAgICAgICAgICAgICAgICAgICAg
ICAgICAgc2l6ZV90IGNvdW50KQ0KPj4+ICt7DQo+Pj4gKyAgICB3aGlsZSAoIGNvdW50ICYmICFJ
U19BTElHTkVEKCh1bnNpZ25lZCBsb25nKXRvLCA0KSApDQo+Pj4gKyAgICB7DQo+Pj4gKyAgICAg
ICAgd3JpdGViX3JlbGF4ZWQoKih1OCAqKWZyb20sIHRvKTsNCj4+PiArICAgICAgICBmcm9tKys7
DQo+Pj4gKyAgICAgICAgdG8rKzsNCj4+PiArICAgICAgICBjb3VudC0tOw0KPj4+ICsgICAgfQ0K
Pj4+ICsNCj4+PiArICAgIHdoaWxlICggY291bnQgPj0gNCApDQo+Pj4gKyAgICB7DQo+Pj4gKyAg
ICAgICAgd3JpdGVsX3JlbGF4ZWQoKih1MzIgKilmcm9tLCB0byk7DQo+Pj4gKyAgICAgICAgZnJv
bSArPSA0Ow0KPj4+ICsgICAgICAgIHRvICs9IDQ7DQo+Pj4gKyAgICAgICAgY291bnQgLT0gNDsN
Cj4+PiArICAgIH0NCj4+PiArDQo+Pj4gKyAgICB3aGlsZSAoIGNvdW50ICkNCj4+PiArICAgIHsN
Cj4+PiArICAgICAgICB3cml0ZWJfcmVsYXhlZCgqKHU4ICopZnJvbSwgdG8pOw0KPj4+ICsgICAg
ICAgIGZyb20rKzsNCj4+PiArICAgICAgICB0bysrOw0KPj4+ICsgICAgICAgIGNvdW50LS07DQo+
Pj4gKyAgICB9DQo+Pj4gK30NCj4+IEkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgd2UgbmVlZCBfX21l
bWNweV9mcm9taW8gYW5kIF9fbWVtY3B5X3RvaW86IGNhbid0DQo+PiB3ZSB1c2UgYSBzaW1wbGUg
bWVtY3B5Pw0KPj4NCj4+DQo+Pj4gK3N0YXRpYyBpbmxpbmUgaW50DQo+Pj4gK3NobWVtX2NoYW5u
ZWxfaXNfZnJlZShjb25zdCB2b2xhdGlsZSBzdHJ1Y3Qgc2NtaV9zaGFyZWRfbWVtIF9faW9tZW0g
KnNobWVtKQ0KPj4+ICt7DQo+Pj4gKyAgICByZXR1cm4gKHJlYWRsKCZzaG1lbS0+Y2hhbm5lbF9z
dGF0dXMpICYNCj4+PiArICAgICAgICAgICAgU0NNSV9TSE1FTV9DSEFOX1NUQVRfQ0hBTk5FTF9G
UkVFKSA/IDAgOiAtRUJVU1k7DQo+Pj4gK30NCj4+PiArDQo+Pj4gK2ludCBzaG1lbV9wdXRfbWVz
c2FnZSh2b2xhdGlsZSBzdHJ1Y3Qgc2NtaV9zaGFyZWRfbWVtIF9faW9tZW0gKnNobWVtLA0KPj4+
ICsgICAgICAgICAgICAgICAgICAgICAgc2NtaV9tc2dfaGVhZGVyX3QgKmhkciwgdm9pZCAqZGF0
YSwgaW50IGxlbikNCj4+PiArew0KPj4+ICsgICAgaW50IHJldDsNCj4+PiArDQo+Pj4gKyAgICBp
ZiAoIChsZW4gKyBzaXplb2Yoc2htZW0tPm1zZ19oZWFkZXIpKSA+IFNDTUlfU0hNRU1fTUFQUEVE
X1NJWkUgKQ0KPj4+ICsgICAgew0KPj4+ICsgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJzY21p
OiBXcm9uZyBzaXplIG9mIHNtYyBtZXNzYWdlLiBEYXRhIGlzIGludmFsaWRcbiIpOw0KPj4+ICsg
ICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4+ICsgICAgfQ0KPj4+ICsNCj4+PiArICAgIHJldCA9
IHNobWVtX2NoYW5uZWxfaXNfZnJlZShzaG1lbSk7DQo+Pj4gKyAgICBpZiAoIHJldCApDQo+Pj4g
KyAgICAgICAgcmV0dXJuIHJldDsNCj4+PiArDQo+Pj4gKyAgICB3cml0ZWxfcmVsYXhlZCgweDAs
ICZzaG1lbS0+Y2hhbm5lbF9zdGF0dXMpOw0KPj4+ICsgICAgLyogV3JpdGluZyAweDAgcmlnaHQg
bm93LCBidXQgInNobWVtIl9GTEFHX0lOVFJfRU5BQkxFRCBjYW4gYmUgc2V0ICovDQo+Pj4gKyAg
ICB3cml0ZWxfcmVsYXhlZCgweDAsICZzaG1lbS0+ZmxhZ3MpOw0KPj4+ICsgICAgd3JpdGVsX3Jl
bGF4ZWQoc2l6ZW9mKHNobWVtLT5tc2dfaGVhZGVyKSArIGxlbiwgJnNobWVtLT5sZW5ndGgpOw0K
Pj4+ICsgICAgd3JpdGVsKHBhY2tfc2NtaV9oZWFkZXIoaGRyKSwgJnNobWVtLT5tc2dfaGVhZGVy
KTsNCj4+PiArDQo+Pj4gKyAgICBpZiAoIGxlbiA+IDAgJiYgZGF0YSApDQo+Pj4gKyAgICAgICAg
X19tZW1jcHlfdG9pbyhzaG1lbS0+bXNnX3BheWxvYWQsIGRhdGEsIGxlbik7DQo+Pj4gKw0KPj4+
ICsgICAgcmV0dXJuIDA7DQo+Pj4gK30NCj4+PiArDQo+Pj4gK2ludCBzaG1lbV9nZXRfcmVzcG9u
c2UoY29uc3Qgdm9sYXRpbGUgc3RydWN0IHNjbWlfc2hhcmVkX21lbSBfX2lvbWVtICpzaG1lbSwN
Cj4+PiArICAgICAgICAgICAgICAgICAgICAgICBzY21pX21zZ19oZWFkZXJfdCAqaGRyLCB2b2lk
ICpkYXRhLCBpbnQgbGVuKQ0KPj4+ICt7DQo+Pj4gKyAgICBpbnQgcmVjdl9sZW47DQo+Pj4gKyAg
ICBpbnQgcmV0Ow0KPj4+ICsgICAgaW50IHBhZCA9IHNpemVvZihoZHItPnN0YXR1cyk7DQo+Pj4g
Kw0KPj4+ICsgICAgaWYgKCBsZW4gPj0gU0NNSV9TSE1FTV9NQVBQRURfU0laRSAtIHNpemVvZihz
aG1lbSkgKQ0KPj4+ICsgICAgew0KPj4+ICsgICAgICAgIHByaW50ayhYRU5MT0dfRVJSDQo+Pj4g
KyAgICAgICAgICAgICAgICJzY21pOiBXcm9uZyBzaXplIG9mIGlucHV0IHNtYyBtZXNzYWdlLiBE
YXRhIG1heSBiZSBpbnZhbGlkXG4iKTsNCj4+PiArICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+
PiArICAgIH0NCj4+PiArDQo+Pj4gKyAgICByZXQgPSBzaG1lbV9jaGFubmVsX2lzX2ZyZWUoc2ht
ZW0pOw0KPj4+ICsgICAgaWYgKCByZXQgKQ0KPj4+ICsgICAgICAgIHJldHVybiByZXQ7DQo+Pj4g
Kw0KPj4+ICsgICAgcmVjdl9sZW4gPSByZWFkbCgmc2htZW0tPmxlbmd0aCkgLSBzaXplb2Yoc2ht
ZW0tPm1zZ19oZWFkZXIpOw0KPj4+ICsNCj4+PiArICAgIGlmICggcmVjdl9sZW4gPCAwICkNCj4+
PiArICAgIHsNCj4+PiArICAgICAgICBwcmludGsoWEVOTE9HX0VSUg0KPj4+ICsgICAgICAgICAg
ICAgICAic2NtaTogV3Jvbmcgc2l6ZSBvZiBzbWMgbWVzc2FnZS4gRGF0YSBtYXkgYmUgaW52YWxp
ZFxuIik7DQo+Pj4gKyAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+Pj4gKyAgICB9DQo+Pj4gKw0K
Pj4+ICsgICAgdW5wYWNrX3NjbWlfaGVhZGVyKHJlYWRsKCZzaG1lbS0+bXNnX2hlYWRlciksIGhk
cik7DQo+Pj4gKw0KPj4+ICsgICAgaGRyLT5zdGF0dXMgPSByZWFkbCgmc2htZW0tPm1zZ19wYXls
b2FkKTsNCj4+PiArICAgIHJlY3ZfbGVuID0gcmVjdl9sZW4gPiBwYWQgPyByZWN2X2xlbiAtIHBh
ZCA6IDA7DQo+Pj4gKw0KPj4+ICsgICAgcmV0ID0gc2NtaV90b194ZW5fZXJybm8oaGRyLT5zdGF0
dXMpOw0KPj4+ICsgICAgaWYgKCByZXQgKQ0KPj4+ICsgICAgew0KPj4+ICsgICAgICAgIHByaW50
ayhYRU5MT0dfREVCVUcgInNjbWk6IEVycm9yIHJlY2VpdmVkOiAlZFxuIiwgcmV0KTsNCj4+PiAr
ICAgICAgICByZXR1cm4gcmV0Ow0KPj4+ICsgICAgfQ0KPj4+ICsNCj4+PiArICAgIGlmICggcmVj
dl9sZW4gPiBsZW4gKQ0KPj4+ICsgICAgew0KPj4+ICsgICAgICAgIHByaW50ayhYRU5MT0dfRVJS
DQo+Pj4gKyAgICAgICAgICAgICAgICJzY21pOiBOb3QgZW5vdWdoIGJ1ZmZlciBmb3IgbWVzc2Fn
ZSAlZCwgZXhwZWN0aW5nICVkXG4iLA0KPj4+ICsgICAgICAgICAgICAgICByZWN2X2xlbiwgbGVu
KTsNCj4+PiArICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+PiArICAgIH0NCj4+PiArDQo+Pj4g
KyAgICBpZiAoIHJlY3ZfbGVuID4gMCApDQo+Pj4gKyAgICAgICAgX19tZW1jcHlfZnJvbWlvKGRh
dGEsIHNobWVtLT5tc2dfcGF5bG9hZCArIHBhZCwgcmVjdl9sZW4pOw0KPj4+ICsNCj4+PiArICAg
IHJldHVybiAwOw0KPj4+ICt9DQo+Pj4gKw0KPj4+ICsvKg0KPj4+ICsgKiBMb2NhbCB2YXJpYWJs
ZXM6DQo+Pj4gKyAqIG1vZGU6IEMNCj4+PiArICogYy1maWxlLXN0eWxlOiAiQlNEIg0KPj4+ICsg
KiBjLWJhc2ljLW9mZnNldDogNA0KPj4+ICsgKiB0YWItd2lkdGg6IDQNCj4+PiArICogaW5kZW50
LXRhYnMtbW9kZTogbmlsDQo+Pj4gKyAqIEVuZDoNCj4+PiArICovDQo+Pj4gZGlmZiAtLWdpdCBh
L3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNobWVtLmggYi94ZW4vYXJjaC9hcm0vZmlybXdh
cmUvc2NtaS1zaG1lbS5oDQo+Pj4gbmV3IGZpbGUgbW9kZSAxMDA2NDQNCj4+PiBpbmRleCAwMDAw
MDAwMDAwLi4yZjhlMjNmZjc2DQo+Pj4gLS0tIC9kZXYvbnVsbA0KPj4+ICsrKyBiL3hlbi9hcmNo
L2FybS9maXJtd2FyZS9zY21pLXNobWVtLmgNCj4+PiBAQCAtMCwwICsxLDQ1IEBADQo+Pj4gKy8q
IFNQRFgtTGljZW5zZS1JZGVudGlmaWVyOiBHUEwtMi4wLW9ubHkgKi8NCj4+PiArLyoNCj4+PiAr
ICogQXJtIFN5c3RlbSBDb250cm9sIGFuZCBNYW5hZ2VtZW50IEludGVyZmFjZSBkZWZpbml0aW9u
cw0KPj4+ICsgKiBWZXJzaW9uIDMuMCAoREVOMDA1NkMpDQo+Pj4gKyAqIFNoYXJlZCBNZW1vcnkg
YmFzZWQgVHJhbnNwb3J0DQo+Pj4gKyAqDQo+Pj4gKyAqIENvcHlyaWdodCAoYykgMjAyNCBFUEFN
IFN5c3RlbXMNCj4+PiArICovDQo+Pj4gKw0KPj4+ICsjaWZuZGVmIFhFTl9BUkNIX0FSTV9TQ0lf
U0NNSV9TSE1FTV9IXw0KPj4+ICsjZGVmaW5lIFhFTl9BUkNIX0FSTV9TQ0lfU0NNSV9TSE1FTV9I
Xw0KPj4gTklUOiBBUk1fRklSTVdBUkVfU0NNSV9TSE1FTV9IDQo+Pg0KPj4NCj4+PiArI2luY2x1
ZGUgPHhlbi9zdGRpbnQuaD4NCj4+PiArDQo+Pj4gKyNkZWZpbmUgU0NNSV9TSE1FTV9DSEFOX1NU
QVRfQ0hBTk5FTF9GUkVFICBCSVQoMCwgVUwpDQo+Pj4gKyNkZWZpbmUgU0NNSV9TSE1FTV9DSEFO
X1NUQVRfQ0hBTk5FTF9FUlJPUiBCSVQoMSwgVUwpDQo+Pj4gKw0KPj4+ICtzdHJ1Y3Qgc2NtaV9z
aGFyZWRfbWVtIHsNCj4+PiArICAgIHVpbnQzMl90IHJlc2VydmVkOw0KPj4+ICsgICAgdWludDMy
X3QgY2hhbm5lbF9zdGF0dXM7DQo+Pj4gKyAgICB1aW50MzJfdCByZXNlcnZlZDFbMl07DQo+Pj4g
KyAgICB1aW50MzJfdCBmbGFnczsNCj4+PiArICAgIHVpbnQzMl90IGxlbmd0aDsNCj4+PiArICAg
IHVpbnQzMl90IG1zZ19oZWFkZXI7DQo+Pj4gKyAgICB1aW50OF90IG1zZ19wYXlsb2FkW107DQo+
Pj4gK307DQo+Pj4gKw0KPj4+ICsjZGVmaW5lIFNDTUlfU0hNRU1fTUFQUEVEX1NJWkUgUEFHRV9T
SVpFDQo+Pj4gKw0KPj4+ICtpbnQgc2htZW1fcHV0X21lc3NhZ2Uodm9sYXRpbGUgc3RydWN0IHNj
bWlfc2hhcmVkX21lbSBfX2lvbWVtICpzaG1lbSwNCj4+PiArICAgICAgICAgICAgICAgICAgICAg
IHNjbWlfbXNnX2hlYWRlcl90ICpoZHIsIHZvaWQgKmRhdGEsIGludCBsZW4pOw0KPj4+ICsNCj4+
PiAraW50IHNobWVtX2dldF9yZXNwb25zZShjb25zdCB2b2xhdGlsZSBzdHJ1Y3Qgc2NtaV9zaGFy
ZWRfbWVtIF9faW9tZW0gKnNobWVtLA0KPj4+ICsgICAgICAgICAgICAgICAgICAgICAgIHNjbWlf
bXNnX2hlYWRlcl90ICpoZHIsIHZvaWQgKmRhdGEsIGludCBsZW4pOw0KPj4+ICsjZW5kaWYgLyog
WEVOX0FSQ0hfQVJNX1NDSV9TQ01JX1NITUVNX0hfICovDQo+Pj4gKw0KPj4+ICsvKg0KPj4+ICsg
KiBMb2NhbCB2YXJpYWJsZXM6DQo+Pj4gKyAqIG1vZGU6IEMNCj4+PiArICogYy1maWxlLXN0eWxl
OiAiQlNEIg0KPj4+ICsgKiBjLWJhc2ljLW9mZnNldDogNA0KPj4+ICsgKiB0YWItd2lkdGg6IDQN
Cj4+PiArICogaW5kZW50LXRhYnMtbW9kZTogbmlsDQo+Pj4gKyAqIEVuZDoNCj4+PiArICovDQo+
Pj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNtYy1tdWx0aWFnZW50
LmMgYi94ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1zbWMtbXVsdGlhZ2VudC5jDQo+Pj4gbmV3
IGZpbGUgbW9kZSAxMDA2NDQNCj4+PiBpbmRleCAwMDAwMDAwMDAwLi5lMDIzYmNhM2ExDQo+Pj4g
LS0tIC9kZXYvbnVsbA0KPj4+ICsrKyBiL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNtYy1t
dWx0aWFnZW50LmMNCj4+PiBAQCAtMCwwICsxLDg2MCBAQA0KPj4+ICsvKiBTUERYLUxpY2Vuc2Ut
SWRlbnRpZmllcjogR1BMLTIuMC1vbmx5ICovDQo+Pj4gKy8qDQo+Pj4gKyAqIFNDSSBTQ01JIG11
bHRpLWFnZW50IGRyaXZlciwgdXNpbmcgU01DL0hWQyBzaG1lbSBhcyB0cmFuc3BvcnQuDQo+Pj4g
KyAqDQo+Pj4gKyAqIE9sZWtzaWkgTW9pc2llaWV2PG9sZWtzaWlfbW9pc2llaWV2QGVwYW0uY29t
Pg0KPj4+ICsgKiBDb3B5cmlnaHQgKGMpIDIwMjUgRVBBTSBTeXN0ZW1zDQo+Pj4gKyAqLw0KPj4+
ICsNCj4+PiArI2luY2x1ZGUgPHhlbi9hY3BpLmg+DQo+Pj4gKw0KPj4+ICsjaW5jbHVkZSA8eGVu
L2RldmljZV90cmVlLmg+DQo+Pj4gKyNpbmNsdWRlIDx4ZW4vaW5pdC5oPg0KPj4+ICsjaW5jbHVk
ZSA8eGVuL2lvY2FwLmg+DQo+Pj4gKyNpbmNsdWRlIDx4ZW4vZXJyLmg+DQo+Pj4gKyNpbmNsdWRl
IDx4ZW4vbGliZmR0L2xpYmZkdC5oPg0KPj4+ICsjaW5jbHVkZSA8eGVuL3BhcmFtLmg+DQo+Pj4g
KyNpbmNsdWRlIDx4ZW4vc2NoZWQuaD4NCj4+PiArI2luY2x1ZGUgPHhlbi92bWFwLmg+DQo+Pj4g
Kw0KPj4+ICsjaW5jbHVkZSA8YXNtL2Zpcm13YXJlL3NjaS5oPg0KPj4+ICsjaW5jbHVkZSA8YXNt
L3NtY2NjLmg+DQo+Pj4gKw0KPj4+ICsjaW5jbHVkZSAic2NtaS1wcm90by5oIg0KPj4+ICsjaW5j
bHVkZSAic2NtaS1zaG1lbS5oIg0KPj4+ICsNCj4+PiArI2RlZmluZSBTQ01JX0FHRU5UX0lEX0lO
VkFMSUQgMHhGRg0KPj4+ICsNCj4+PiArc3RhdGljIHVpbnQ4X3QgX19pbml0ZGF0YSBvcHRfZG9t
MF9zY21pX2FnZW50X2lkID0gU0NNSV9BR0VOVF9JRF9JTlZBTElEOw0KPj4+ICtpbnRlZ2VyX3Bh
cmFtKCJkb20wX3NjbWlfYWdlbnRfaWQiLCBvcHRfZG9tMF9zY21pX2FnZW50X2lkKTsNCj4+PiAr
DQo+Pj4gKyNkZWZpbmUgU0NNSV9TRUNPTkRBUllfQUdFTlRTICJ4ZW4sc2NtaS1zZWNvbmRhcnkt
YWdlbnRzIg0KPj4+ICsNCj4+PiArI2RlZmluZSBIWVBfQ0hBTk5FTCAweDANCj4+PiArDQo+Pj4g
K3N0cnVjdCBzY21pX2NoYW5uZWwgew0KPj4+ICsgICAgdWludDMyX3QgYWdlbnRfaWQ7DQo+Pj4g
KyAgICB1aW50MzJfdCBmdW5jX2lkOw0KPj4+ICsgICAgZG9taWRfdCBkb21haW5faWQ7DQo+Pj4g
KyAgICB1aW50NjRfdCBwYWRkcjsNCj4+PiArICAgIHVpbnQ2NF90IGxlbjsNCj4+PiArICAgIHN0
cnVjdCBzY21pX3NoYXJlZF9tZW0gX19pb21lbSAqc2htZW07DQo+Pj4gKyAgICBzcGlubG9ja190
IGxvY2s7DQo+Pj4gKyAgICBzdHJ1Y3QgbGlzdF9oZWFkIGxpc3Q7DQo+Pj4gK307DQo+Pj4gKw0K
Pj4+ICtzdHJ1Y3Qgc2NtaV9kYXRhIHsNCj4+PiArICAgIHN0cnVjdCBsaXN0X2hlYWQgY2hhbm5l
bF9saXN0Ow0KPj4+ICsgICAgc3BpbmxvY2tfdCBjaGFubmVsX2xpc3RfbG9jazsNCj4+PiArICAg
IHVpbnQzMl90IGZ1bmNfaWQ7DQo+Pj4gKyAgICBib29sIGluaXRpYWxpemVkOw0KPj4+ICsgICAg
dWludDMyX3Qgc2htZW1fcGhhbmRsZTsNCj4+PiArICAgIHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAq
ZHRfZGV2Ow0KPj4+ICt9Ow0KPj4+ICsNCj4+PiArc3RhdGljIHN0cnVjdCBzY21pX2RhdGEgc2Nt
aV9kYXRhOw0KPj4+ICsNCj4+PiArc3RhdGljIGludCBzZW5kX3NtY19tZXNzYWdlKHN0cnVjdCBz
Y21pX2NoYW5uZWwgKmNoYW5faW5mbywNCj4+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHNjbWlfbXNnX2hlYWRlcl90ICpoZHIsIHZvaWQgKmRhdGEsIGludCBsZW4pDQo+Pj4gK3sNCj4+
PiArICAgIHN0cnVjdCBhcm1fc21jY2NfcmVzIHJlc3A7DQo+Pj4gKyAgICBpbnQgcmV0Ow0KPj4+
ICsNCj4+PiArICAgIHJldCA9IHNobWVtX3B1dF9tZXNzYWdlKGNoYW5faW5mby0+c2htZW0sIGhk
ciwgZGF0YSwgbGVuKTsNCj4+PiArICAgIGlmICggcmV0ICkNCj4+PiArICAgICAgICByZXR1cm4g
cmV0Ow0KPj4+ICsNCj4+PiArICAgIGFybV9zbWNjY18xXzFfc21jKGNoYW5faW5mby0+ZnVuY19p
ZCwgMCwgMCwgMCwgMCwgMCwgMCwgMCwgJnJlc3ApOw0KPj4+ICsNCj4+PiArICAgIGlmICggcmVz
cC5hMCApDQo+Pj4gKyAgICAgICAgcmV0dXJuIC1FT1BOT1RTVVBQOw0KPj4gV2h5IGlmIHJlcG8u
YTAgIT0gMCB0aGVuIHdlIGFzc3VtZSAtRU9QTk9UU1VQUD8gSXMgdGhpcyBwYXJ0IG9mIHRoZSBT
Q01JDQo+PiBzcGVjaWZpY2F0aW9uPw0KPj4NCj4+DQo+Pj4gKyAgICByZXR1cm4gMDsNCj4+PiAr
fQ0KPj4+ICsNCj4+PiArc3RhdGljIGludCBkb19zbWNfeGZlcihzdHJ1Y3Qgc2NtaV9jaGFubmVs
ICpjaGFuX2luZm8sIHNjbWlfbXNnX2hlYWRlcl90ICpoZHIsDQo+Pj4gKyAgICAgICAgICAgICAg
ICAgICAgICAgdm9pZCAqdHhfZGF0YSwgaW50IHR4X3NpemUsIHZvaWQgKnJ4X2RhdGEsIGludCBy
eF9zaXplKQ0KPj4+ICt7DQo+Pj4gKyAgICBpbnQgcmV0ID0gMDsNCj4+PiArDQo+Pj4gKyAgICBB
U1NFUlQoY2hhbl9pbmZvICYmIGNoYW5faW5mby0+c2htZW0pOw0KPj4+ICsNCj4+PiArICAgIGlm
ICggIWhkciApDQo+Pj4gKyAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+Pj4gKw0KPj4+ICsgICAg
c3Bpbl9sb2NrKCZjaGFuX2luZm8tPmxvY2spOw0KPj4+ICsNCj4+PiArICAgIHByaW50ayhYRU5M
T0dfREVCVUcNCj4+PiArICAgICAgICAgICAic2NtaTogYWdlbnRfaWQgPSAlZCBtc2dfaWQgPSAl
eCB0eXBlID0gJWQsIHByb3RvID0gJXhcbiIsDQo+Pj4gKyAgICAgICAgICAgY2hhbl9pbmZvLT5h
Z2VudF9pZCwgaGRyLT5pZCwgaGRyLT50eXBlLCBoZHItPnByb3RvY29sKTsNCj4+PiArDQo+Pj4g
KyAgICByZXQgPSBzZW5kX3NtY19tZXNzYWdlKGNoYW5faW5mbywgaGRyLCB0eF9kYXRhLCB0eF9z
aXplKTsNCj4+PiArICAgIGlmICggcmV0ICkNCj4+PiArICAgICAgICBnb3RvIGNsZWFuOw0KPj4+
ICsNCj4+PiArICAgIHJldCA9IHNobWVtX2dldF9yZXNwb25zZShjaGFuX2luZm8tPnNobWVtLCBo
ZHIsIHJ4X2RhdGEsIHJ4X3NpemUpOw0KPj4+ICsNCj4+PiArY2xlYW46DQo+Pj4gKyAgICBwcmlu
dGsoWEVOTE9HX0RFQlVHDQo+Pj4gKyAgICAgICAgICAgInNjbWk6IGdldCBzbWMgcmVzcG9uc2Ug
YWdlbnRfaWQgPSAlZCBtc2dfaWQgPSAleCBwcm90byA9ICV4IHJlcz0lZFxuIiwNCj4+PiArICAg
ICAgICAgICBjaGFuX2luZm8tPmFnZW50X2lkLCBoZHItPmlkLCBoZHItPnByb3RvY29sLCByZXQp
Ow0KPj4+ICsNCj4+PiArICAgIHNwaW5fdW5sb2NrKCZjaGFuX2luZm8tPmxvY2spOw0KPj4+ICsN
Cj4+PiArICAgIHJldHVybiByZXQ7DQo+Pj4gK30NCj4+PiArDQo+Pj4gK3N0YXRpYyBzdHJ1Y3Qg
c2NtaV9jaGFubmVsICpnZXRfY2hhbm5lbF9ieV9pZCh1aW50MzJfdCBhZ2VudF9pZCkNCj4+PiAr
ew0KPj4+ICsgICAgc3RydWN0IHNjbWlfY2hhbm5lbCAqY3VycjsNCj4+PiArICAgIGJvb2wgZm91
bmQgPSBmYWxzZTsNCj4+PiArDQo+Pj4gKyAgICBzcGluX2xvY2soJnNjbWlfZGF0YS5jaGFubmVs
X2xpc3RfbG9jayk7DQo+Pj4gKyAgICBsaXN0X2Zvcl9lYWNoX2VudHJ5KGN1cnIsICZzY21pX2Rh
dGEuY2hhbm5lbF9saXN0LCBsaXN0KQ0KPj4+ICsgICAgew0KPj4+ICsgICAgICAgIGlmICggY3Vy
ci0+YWdlbnRfaWQgPT0gYWdlbnRfaWQgKQ0KPj4+ICsgICAgICAgIHsNCj4+PiArICAgICAgICAg
ICAgZm91bmQgPSB0cnVlOw0KPj4+ICsgICAgICAgICAgICBicmVhazsNCj4+PiArICAgICAgICB9
DQo+Pj4gKyAgICB9DQo+Pj4gKw0KPj4+ICsgICAgc3Bpbl91bmxvY2soJnNjbWlfZGF0YS5jaGFu
bmVsX2xpc3RfbG9jayk7DQo+Pj4gKyAgICBpZiAoIGZvdW5kICkNCj4+PiArICAgICAgICByZXR1
cm4gY3VycjsNCj4+PiArDQo+Pj4gKyAgICByZXR1cm4gTlVMTDsNCj4+PiArfQ0KPj4+ICsNCj4+
PiArc3RhdGljIHN0cnVjdCBzY21pX2NoYW5uZWwgKmFjcXVpcmVfc2NtaV9jaGFubmVsKHN0cnVj
dCBkb21haW4gKmQsDQo+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICB1aW50MzJfdCBhZ2VudF9pZCkNCj4+PiArew0KPj4+ICsgICAgc3RydWN0IHNj
bWlfY2hhbm5lbCAqY3VycjsNCj4+PiArICAgIHN0cnVjdCBzY21pX2NoYW5uZWwgKnJldCA9IEVS
Ul9QVFIoLUVOT0VOVCk7DQo+Pj4gKw0KPj4+ICsgICAgc3Bpbl9sb2NrKCZzY21pX2RhdGEuY2hh
bm5lbF9saXN0X2xvY2spOw0KPj4+ICsgICAgbGlzdF9mb3JfZWFjaF9lbnRyeShjdXJyLCAmc2Nt
aV9kYXRhLmNoYW5uZWxfbGlzdCwgbGlzdCkNCj4+PiArICAgIHsNCj4+PiArICAgICAgICBpZiAo
IGN1cnItPmFnZW50X2lkID09IGFnZW50X2lkICkNCj4+PiArICAgICAgICB7DQo+Pj4gKyAgICAg
ICAgICAgIGlmICggY3Vyci0+ZG9tYWluX2lkICE9IERPTUlEX0lOVkFMSUQgKQ0KPj4+ICsgICAg
ICAgICAgICB7DQo+Pj4gKyAgICAgICAgICAgICAgICByZXQgPSBFUlJfUFRSKC1FRVhJU1QpOw0K
Pj4+ICsgICAgICAgICAgICAgICAgYnJlYWs7DQo+Pj4gKyAgICAgICAgICAgIH0NCj4+PiArDQo+
Pj4gKyAgICAgICAgICAgIGN1cnItPmRvbWFpbl9pZCA9IGQtPmRvbWFpbl9pZDsNCj4+PiArICAg
ICAgICAgICAgcmV0ID0gY3VycjsNCj4+PiArICAgICAgICAgICAgYnJlYWs7DQo+Pj4gKyAgICAg
ICAgfQ0KPj4+ICsgICAgfQ0KPj4+ICsNCj4+PiArICAgIHNwaW5fdW5sb2NrKCZzY21pX2RhdGEu
Y2hhbm5lbF9saXN0X2xvY2spOw0KPj4+ICsNCj4+PiArICAgIHJldHVybiByZXQ7DQo+Pj4gK30N
Cj4+PiArDQo+Pj4gK3N0YXRpYyB2b2lkIHJlbGlucXVpc2hfc2NtaV9jaGFubmVsKHN0cnVjdCBz
Y21pX2NoYW5uZWwgKmNoYW5uZWwpDQo+Pj4gK3sNCj4+PiArICAgIEFTU0VSVChjaGFubmVsICE9
IE5VTEwpOw0KPj4+ICsNCj4+PiArICAgIHNwaW5fbG9jaygmc2NtaV9kYXRhLmNoYW5uZWxfbGlz
dF9sb2NrKTsNCj4+PiArICAgIGNoYW5uZWwtPmRvbWFpbl9pZCA9IERPTUlEX0lOVkFMSUQ7DQo+
Pj4gKyAgICBzcGluX3VubG9jaygmc2NtaV9kYXRhLmNoYW5uZWxfbGlzdF9sb2NrKTsNCj4+PiAr
fQ0KPj4+ICsNCj4+PiArc3RhdGljIGludCBtYXBfY2hhbm5lbF9tZW1vcnkoc3RydWN0IHNjbWlf
Y2hhbm5lbCAqY2hhbm5lbCkNCj4+PiArew0KPj4+ICsgICAgQVNTRVJUKGNoYW5uZWwgJiYgY2hh
bm5lbC0+cGFkZHIpOw0KPj4+ICsgICAgY2hhbm5lbC0+c2htZW0gPSBpb3JlbWFwX25vY2FjaGUo
Y2hhbm5lbC0+cGFkZHIsIFNDTUlfU0hNRU1fTUFQUEVEX1NJWkUpOw0KPj4gaW9yZW1hcCBpcyBm
b3IgTU1JTywgaWYgdGhlc2Ugc2hhcmVkIG1lbW9yeSBjaGFubmVscyBhcmUgb24gRERSLCB0aGVu
IGl0DQo+PiB3b3VsZCBub3QgYmUgdGhlIHJpZ2h0IGNhbGwuIEFyZSB0aGUgImFybSxzY21pLXNo
bWVtIiBhZGRyZXNzIHJhbmdlcw0KPj4gcGFydCBvZiB0aGUgbWVtb3J5IG5vZGUgcmFuZ2VzPyBP
ciBhcmUgdGhleSBjb21wbGV0ZWx5IHNlcGFyYXRlPw0KPj4NCj4+IEFsc28sIHdoeSBub2NhY2hl
PyBXb3VsZG4ndCB3ZSB3YW50IGlvcmVtYXBfY2FjaGU/DQo+Pg0KPj4NCj4+PiArICAgIGlmICgg
IWNoYW5uZWwtPnNobWVtICkNCj4+PiArICAgICAgICByZXR1cm4gLUVOT01FTTsNCj4+PiArDQo+
Pj4gKyAgICBjaGFubmVsLT5zaG1lbS0+Y2hhbm5lbF9zdGF0dXMgPSBTQ01JX1NITUVNX0NIQU5f
U1RBVF9DSEFOTkVMX0ZSRUU7DQo+Pj4gKyAgICBwcmludGsoWEVOTE9HX0RFQlVHICJzY21pOiBH
b3Qgc2htZW0gJWx4IGFmdGVyIHZtYXAgJXBcbiIsIGNoYW5uZWwtPnBhZGRyLA0KPj4+ICsgICAg
ICAgICAgIGNoYW5uZWwtPnNobWVtKTsNCj4+PiArDQo+Pj4gKyAgICByZXR1cm4gMDsNCj4+PiAr
fQ0KPj4+ICsNCj4+PiArc3RhdGljIHZvaWQgdW5tYXBfY2hhbm5lbF9tZW1vcnkoc3RydWN0IHNj
bWlfY2hhbm5lbCAqY2hhbm5lbCkNCj4+PiArew0KPj4+ICsgICAgQVNTRVJUKGNoYW5uZWwgJiYg
Y2hhbm5lbC0+c2htZW0pOw0KPj4+ICsgICAgaW91bm1hcChjaGFubmVsLT5zaG1lbSk7DQo+Pj4g
KyAgICBjaGFubmVsLT5zaG1lbSA9IE5VTEw7DQo+Pj4gK30NCj4+PiArDQo+Pj4gK3N0YXRpYyBz
dHJ1Y3Qgc2NtaV9jaGFubmVsICpzbWNfY3JlYXRlX2NoYW5uZWwodWludDMyX3QgYWdlbnRfaWQs
DQo+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWlu
dDMyX3QgZnVuY19pZCwgdWludDY0X3QgYWRkcikNCj4+PiArew0KPj4+ICsgICAgc3RydWN0IHNj
bWlfY2hhbm5lbCAqY2hhbm5lbDsNCj4+PiArDQo+Pj4gKyAgICBjaGFubmVsID0gZ2V0X2NoYW5u
ZWxfYnlfaWQoYWdlbnRfaWQpOw0KPj4+ICsgICAgaWYgKCBjaGFubmVsICkNCj4+PiArICAgICAg
ICByZXR1cm4gRVJSX1BUUihFRVhJU1QpOw0KPj4+ICsNCj4+PiArICAgIGNoYW5uZWwgPSB4bWFs
bG9jKHN0cnVjdCBzY21pX2NoYW5uZWwpOw0KPj4+ICsgICAgaWYgKCAhY2hhbm5lbCApDQo+Pj4g
KyAgICAgICAgcmV0dXJuIEVSUl9QVFIoRU5PTUVNKTsNCj4+PiArDQo+Pj4gKyAgICBzcGluX2xv
Y2tfaW5pdCgmY2hhbm5lbC0+bG9jayk7DQo+Pj4gKyAgICBjaGFubmVsLT5hZ2VudF9pZCA9IGFn
ZW50X2lkOw0KPj4+ICsgICAgY2hhbm5lbC0+ZnVuY19pZCA9IGZ1bmNfaWQ7DQo+Pj4gKyAgICBj
aGFubmVsLT5kb21haW5faWQgPSBET01JRF9JTlZBTElEOw0KPj4+ICsgICAgY2hhbm5lbC0+c2ht
ZW0gPSBOVUxMOw0KPj4+ICsgICAgY2hhbm5lbC0+cGFkZHIgPSBhZGRyOw0KPj4+ICsgICAgbGlz
dF9hZGRfdGFpbCgmY2hhbm5lbC0+bGlzdCwgJnNjbWlfZGF0YS5jaGFubmVsX2xpc3QpOw0KPj4+
ICsgICAgcmV0dXJuIGNoYW5uZWw7DQo+Pj4gK30NCj4+PiArDQo+Pj4gK3N0YXRpYyB2b2lkIGZy
ZWVfY2hhbm5lbF9saXN0KHZvaWQpDQo+Pj4gK3sNCj4+PiArICAgIHN0cnVjdCBzY21pX2NoYW5u
ZWwgKmN1cnIsICpfY3VycjsNCj4+PiArDQo+Pj4gKyAgICBsaXN0X2Zvcl9lYWNoX2VudHJ5X3Nh
ZmUoY3VyciwgX2N1cnIsICZzY21pX2RhdGEuY2hhbm5lbF9saXN0LCBsaXN0KQ0KPj4+ICsgICAg
ew0KPj4+ICsgICAgICAgIGxpc3RfZGVsKCZjdXJyLT5saXN0KTsNCj4+PiArICAgICAgICB4ZnJl
ZShjdXJyKTsNCj4+PiArICAgIH0NCj4+PiArfQ0KPj4+ICsNCj4+PiArc3RhdGljIGludCBfX2lu
aXQNCj4+PiArc2NtaV9kdF9yZWFkX2h5cF9jaGFubmVsX2FkZHIoc3RydWN0IGR0X2RldmljZV9u
b2RlICpzY21pX25vZGUsIHU2NCAqYWRkciwNCj4+PiArICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgdTY0ICpzaXplKQ0KPj4+ICt7DQo+Pj4gKyAgICBzdHJ1Y3QgZHRfZGV2aWNlX25vZGUg
KnNobWVtX25vZGU7DQo+Pj4gKyAgICBjb25zdCBfX2JlMzIgKnByb3A7DQo+Pj4gKw0KPj4+ICsg
ICAgcHJvcCA9IGR0X2dldF9wcm9wZXJ0eShzY21pX25vZGUsICJzaG1lbSIsIE5VTEwpOw0KPj4+
ICsgICAgaWYgKCAhcHJvcCApDQo+Pj4gKyAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+Pj4gKw0K
Pj4+ICsgICAgc2htZW1fbm9kZSA9IGR0X2ZpbmRfbm9kZV9ieV9waGFuZGxlKGJlMzJfdG9fY3B1
cChwcm9wKSk7DQo+Pj4gKyAgICBpZiAoIElTX0VSUl9PUl9OVUxMKHNobWVtX25vZGUpICkNCj4+
PiArICAgIHsNCj4+PiArICAgICAgICBwcmludGsoWEVOTE9HX0VSUg0KPj4+ICsgICAgICAgICAg
ICAgICAic2NtaTogRGV2aWNlIHRyZWUgZXJyb3IsIGNhbid0IHBhcnNlIHJlc2VydmVkIG1lbW9y
eSAlbGRcbiIsDQo+Pj4gKyAgICAgICAgICAgICAgIFBUUl9FUlIoc2htZW1fbm9kZSkpOw0KPj4+
ICsgICAgICAgIHJldHVybiBQVFJfRVJSKHNobWVtX25vZGUpOw0KPj4+ICsgICAgfQ0KPj4+ICsN
Cj4+PiArICAgIHJldHVybiBkdF9kZXZpY2VfZ2V0X2FkZHJlc3Moc2htZW1fbm9kZSwgMCwgYWRk
ciwgc2l6ZSk7DQo+Pj4gK30NCj4+PiArDQo+Pj4gKy8qDQo+Pj4gKyAqIEhhbmRsZSBEb20wIFND
TUkgc3BlY2lmaWMgRFQgbm9kZXMNCj4+PiArICoNCj4+PiArICogTWFrZSBhIGRlY2lzaW9uIG9u
IGNvcHlpbmcgU0NNSSBzcGVjaWZpYyBub2RlcyBpbnRvIERvbTAgZGV2aWNlIHRyZWUuDQo+Pj4g
KyAqIEZvciBTQ01JIG11bHRpLWFnZW50IGNhc2U6DQo+Pj4gKyAqIC0gc2htZW0gbm9kZXMgd2ls
bCBub3QgYmUgY29waWVkIGFuZCBnZW5lcmF0ZWQgaW5zdGVhZCBpZiBTQ01JDQo+Pj4gKyAqICAg
aXMgZW5hYmxlZCBmb3IgRG9tMA0KPj4+ICsgKiAtIHNjbWkgbm9kZSB3aWxsIGJlIGNvcGllZCBp
ZiBTQ01JIGlzIGVuYWJsZWQgZm9yIERvbTANCj4+PiArICovDQo+Pj4gK3N0YXRpYyBib29sIHNj
bWlfZHRfaGFuZGxlX25vZGUoc3RydWN0IGRvbWFpbiAqZCwgc3RydWN0IGR0X2RldmljZV9ub2Rl
ICpub2RlKQ0KPj4+ICt7DQo+Pj4gKyAgICBzdGF0aWMgY29uc3Qgc3RydWN0IGR0X2RldmljZV9t
YXRjaCBza2lwX21hdGNoZXNbXSBfX2luaXRjb25zdCA9IHsNCj4+PiArICAgICAgICBEVF9NQVRD
SF9DT01QQVRJQkxFKCJhcm0sc2NtaS1zaG1lbSIpLA0KPj4+ICsgICAgICAgIHsgLyogc2VudGlu
ZWwgKi8gfSwNCj4+PiArICAgIH07DQo+Pj4gKyAgICBzdGF0aWMgY29uc3Qgc3RydWN0IGR0X2Rl
dmljZV9tYXRjaCBzY21pX21hdGNoZXNbXSBfX2luaXRjb25zdCA9IHsNCj4+PiArICAgICAgICBE
VF9NQVRDSF9QQVRIKCIvZmlybXdhcmUvc2NtaSIpLA0KPj4+ICsgICAgICAgIHsgLyogc2VudGlu
ZWwgKi8gfSwNCj4+PiArICAgIH07DQo+Pj4gKw0KPj4+ICsgICAgaWYgKCAhc2NtaV9kYXRhLmlu
aXRpYWxpemVkICkNCj4+PiArICAgICAgICByZXR1cm4gZmFsc2U7DQo+Pj4gKw0KPj4+ICsgICAg
LyogYWx3YXlzIGRyb3Agc2htZW0gKi8NCj4+PiArICAgIGlmICggZHRfbWF0Y2hfbm9kZShza2lw
X21hdGNoZXMsIG5vZGUpICkNCj4+PiArICAgIHsNCj4+PiArICAgICAgICBkdF9kcHJpbnRrKCIg
IFNraXAgc2NtaSBzaG1lbVxuIik7DQo+Pj4gKyAgICAgICAgcmV0dXJuIHRydWU7DQo+Pj4gKyAg
ICB9DQo+Pj4gKw0KPj4+ICsgICAgLyogZHJvcCBzY21pIGlmIG5vdCBlbmFibGVkICovDQo+Pj4g
KyAgICBpZiAoIGR0X21hdGNoX25vZGUoc2NtaV9tYXRjaGVzLCBub2RlKSAmJiAhc2NpX2RvbWFp
bl9pc19lbmFibGVkKGQpICkNCj4+PiArICAgIHsNCj4+PiArICAgICAgICBkdF9kcHJpbnRrKCIg
IFNraXAgc2NtaSBub2RlXG4iKTsNCj4+PiArICAgICAgICByZXR1cm4gdHJ1ZTsNCj4+PiArICAg
IH0NCj4+PiArDQo+Pj4gKyAgICByZXR1cm4gZmFsc2U7DQo+Pj4gK30NCj4+PiArDQo+Pj4gKy8q
DQo+Pj4gKyAqIEZpbmFsaXplIERvbTAgU0NNSSBzcGVjaWZpYyBEVCBub2Rlcw0KPj4+ICsgKg0K
Pj4+ICsgKiBpZiBTQ01JIGlzIGVuYWJsZWQgZm9yIERvbTA6DQo+Pj4gKyAqIC0gZ2VuZXJhdGUg
c2htZW0gbm9kZQ0KPj4+ICsgKiAtIG1hcCBTQ01JIHNobWVtIE1NSU8gaW50byBEb20wDQo+Pj4g
KyAqLw0KPj4+ICtzdGF0aWMgaW50IHNjbWlfZHRfZmluYWxpemUoc3RydWN0IGRvbWFpbiAqZCwg
dm9pZCAqZmR0KQ0KPj4+ICt7DQo+Pj4gKyAgICBfX2JlMzIgcmVnW0dVRVNUX1JPT1RfQUREUkVT
U19DRUxMUyArIEdVRVNUX1JPT1RfU0laRV9DRUxMU107DQo+Pj4gKyAgICBzdHJ1Y3Qgc2NtaV9j
aGFubmVsICpjaGFubmVsOw0KPj4+ICsgICAgaW50IG5vZGVvZmZzZXQ7DQo+Pj4gKyAgICBfX2Jl
MzIgKmNlbGxzOw0KPj4+ICsgICAgX19iZTMyIHZhbDsNCj4+PiArICAgIGNoYXIgYnVmWzY0XTsN
Cj4+PiArICAgIGludCByZXMsIHJjOw0KPj4+ICsNCj4+PiArICAgIGlmICggIXNjaV9kb21haW5f
aXNfZW5hYmxlZChkKSApDQo+Pj4gKyAgICAgICAgcmV0dXJuIDA7DQo+Pj4gKw0KPj4+ICsgICAg
Y2hhbm5lbCA9IGQtPmFyY2guc2NpX2RhdGE7DQo+Pj4gKw0KPj4+ICsgICAgLyoNCj4+PiArICAg
ICAqIFJlcGxhY2UgImFybSxzbWMtaWQiIHdpdGggcHJvcGVyIHZhbHVlIGFzc2lnbmVkIGZvciBE
b20wIFNDTUkgY2hhbm5lbA0KPj4+ICsgICAgICovDQo+Pj4gKyAgICBub2Rlb2Zmc2V0ID0gZmR0
X25vZGVfb2Zmc2V0X2J5X2NvbXBhdGlibGUoZmR0LCAtMSwgImFybSxzY21pLXNtYyIpOw0KPj4+
ICsgICAgaWYgKCBub2Rlb2Zmc2V0IDwgMCApDQo+Pj4gKyAgICAgICAgcmV0dXJuIC1FTk9ERVY7
DQo+Pj4gKw0KPj4+ICsgICAgY2VsbHMgPSAoX19iZTMyICopJnZhbDsNCj4+PiArICAgIGR0X3Nl
dF9jZWxsKCZjZWxscywgMSwgY2hhbm5lbC0+ZnVuY19pZCk7DQo+Pj4gKyAgICByZXMgPSBmZHRf
c2V0cHJvcF9pbnBsYWNlKGZkdCwgbm9kZW9mZnNldCwgImFybSxzbWMtaWQiLCAmdmFsLCBzaXpl
b2YodmFsKSk7DQo+Pj4gKyAgICBpZiAoIHJlcyApDQo+Pj4gKyAgICAgICAgcmV0dXJuIC1FSU5W
QUw7DQo+Pj4gKw0KPj4gQXJlIHlvdSBzdXJlIGl0IGlzIHdvcnRoIHRvIGdvIHRocm91Z2ggYWxs
IHRoaXMgdHJvdWJsZSB0byBtb2RpZnkgRkRUIGluDQo+PiBwbGFjZSB3aGVuIHdlIGNvdWxkIHNp
bXBseSBnZW5lcmF0ZSB0aGUgRFQgbm9kZSBmcm9tIHNjcmF0Y2ggbGlrZSB3ZSBkbw0KPj4gZm9y
IGV4YW1wbGUgZm9yIHRoZSBHSUM/IFRoaXMgc2VlbXMgdG8gYmUgbW9yZSBlcnJvciBwcm9uZSBh
cyB3ZWxsLiBJcw0KPj4gZ2VuZXJhdGluZyBpdCBmcm9tIHNjcmF0Y2ggaXMgcmVhbGx5IGRpZmZp
Y3VsdD8gSWYgaXQgaXMgZGlmZmljdWx0IHRoZW4gT0suDQo+Pg0KPj4NCj4+PiArICAgIC8qDQo+
Pj4gKyAgICAgKiBBbGwgU0NNSSBzaG1lbSBub2RlcyBzaG91bGQgYmUgcmVtb3ZlZCBmcm9tIERv
bTAgRFQgYXQgdGhpcyBwb2ludCwgc28NCj4+PiArICAgICAqIHRoZSBzaG1lbSBub2RlIGZvciBE
b20wIG5lZWQgdG8gYmUgZ2VuZXJhdGVkIGZyb20gU0NNSSBjaGFubmVsIGFzc2lnbmVkDQo+Pj4g
KyAgICAgKiB0byBEb20wLg0KPj4+ICsgICAgICogVGhlIG9yaWdpbmFsIFNDTUkgc2htZW0gbm9k
ZSBmcm9tIHBsYXRmb3JtIERUIGlzIHVzZWQgYnkgWGVuIFNDTUkgZHJpdmVyDQo+Pj4gKyAgICAg
KiBpdHNlbGYgYXMgcHJpdmlsZWdlZCBjaGFubmVsIChhZ2VudF9pZD0wKSB0byBtYW5hZ2Ugb3Ro
ZXIgU0NNSQ0KPj4+ICsgICAgICogYWdlbnRzIChkb21haW5zKS4NCj4+PiArICAgICAqLw0KPj4+
ICsgICAgc25wcmludGYoYnVmLCBzaXplb2YoYnVmKSwgInNjbWktc2htZW1AJWx4IiwgY2hhbm5l
bC0+cGFkZHIpOw0KPj4+ICsNCj4+PiArICAgIHJlcyA9IGZkdF9iZWdpbl9ub2RlKGZkdCwgYnVm
KTsNCj4+PiArICAgIGlmICggcmVzICkNCj4+PiArICAgICAgICByZXR1cm4gcmVzOw0KPj4+ICsN
Cj4+PiArICAgIHJlcyA9IGZkdF9wcm9wZXJ0eV9zdHJpbmcoZmR0LCAiY29tcGF0aWJsZSIsICJh
cm0sc2NtaS1zaG1lbSIpOw0KPj4+ICsgICAgaWYgKCByZXMgKQ0KPj4+ICsgICAgICAgIHJldHVy
biByZXM7DQo+Pj4gKw0KPj4+ICsgICAgY2VsbHMgPSAmcmVnWzBdOw0KPj4+ICsNCj4+PiArICAg
IGR0X2NoaWxkX3NldF9yYW5nZSgmY2VsbHMsIEdVRVNUX1JPT1RfQUREUkVTU19DRUxMUywgR1VF
U1RfUk9PVF9TSVpFX0NFTExTLA0KPj4+ICsgICAgICAgICAgICAgICAgICAgICAgIGNoYW5uZWwt
PnBhZGRyLCBTQ01JX1NITUVNX01BUFBFRF9TSVpFKTsNCj4+PiArDQo+Pj4gKyAgICByZXMgPSBm
ZHRfcHJvcGVydHkoZmR0LCAicmVnIiwgcmVnLCBzaXplb2YocmVnKSk7DQo+Pj4gKyAgICBpZiAo
IHJlcyApDQo+Pj4gKyAgICAgICAgcmV0dXJuIHJlczsNCj4+PiArDQo+Pj4gKyAgICByZXMgPSBm
ZHRfcHJvcGVydHlfY2VsbChmZHQsICJwaGFuZGxlIiwgc2NtaV9kYXRhLnNobWVtX3BoYW5kbGUp
Ow0KPj4+ICsgICAgaWYgKCByZXMgKQ0KPj4+ICsgICAgICAgIHJldHVybiByZXM7DQo+Pj4gKw0K
Pj4+ICsgICAgcmVzID0gZmR0X2VuZF9ub2RlKGZkdCk7DQo+Pj4gKyAgICBpZiAoIHJlcyApDQo+
Pj4gKyAgICAgICAgcmV0dXJuIHJlczsNCj4+PiArDQo+Pj4gKyAgICAvKg0KPj4+ICsgICAgICog
TWFwIFNDTUkgc2htZW0gaW50byBEb20wIGhlcmUgYXMgc2htZW0gbm9kZXMgYXJlIGV4Y2x1ZGVk
IGZyb20NCj4+PiArICAgICAqIGdlbmVyaWMgRG9tMCBEVCBwcm9jZXNzaW5nDQo+Pj4gKyAgICAg
Ki8NCj4+PiArICAgIHJlcyA9IGlvbWVtX3Blcm1pdF9hY2Nlc3MoZCwgcGFkZHJfdG9fcGZuKGNo
YW5uZWwtPnBhZGRyKSwNCj4+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGFkZHJf
dG9fcGZuKGNoYW5uZWwtPnBhZGRyICsNCj4+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIFNDTUlfU0hNRU1fTUFQUEVEX1NJWkUgLSAxKSk7DQo+Pj4gKyAgICBp
ZiAoIHJlcyApDQo+Pj4gKyAgICAgICAgcmV0dXJuIHJlczsNCj4+PiArDQo+Pj4gKyAgICByZXMg
PSBtYXBfcmVnaW9uc19wMm10KGQsIGdhZGRyX3RvX2dmbihjaGFubmVsLT5wYWRkciksDQo+Pj4g
KyAgICAgICAgICAgICAgICAgICAgICAgICAgIFBGTl9VUChTQ01JX1NITUVNX01BUFBFRF9TSVpF
KSwNCj4+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgbWFkZHJfdG9fbWZuKGNoYW5uZWwt
PnBhZGRyKSwgcDJtX21taW9fZGlyZWN0X25jKTsNCj4+PiArICAgIGlmICggcmVzICkNCj4+PiAr
ICAgIHsNCj4+PiArICAgICAgICByYyA9IGlvbWVtX2RlbnlfYWNjZXNzKGQsIHBhZGRyX3RvX3Bm
bihjaGFubmVsLT5wYWRkciksDQo+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBw
YWRkcl90b19wZm4oY2hhbm5lbC0+cGFkZHIgKw0KPj4+ICsgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFNDTUlfU0hNRU1fTUFQUEVEX1NJWkUgLSAxKSk7DQo+Pj4g
KyAgICAgICAgaWYgKCByYyApDQo+Pj4gKyAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJz
Y21pOiBVbmFibGUgdG8gZGVueSBpb21lbSBhY2Nlc3MgLCBlcnIgPSAlZFxuIiwNCj4+PiArICAg
ICAgICAgICAgICAgICAgIHJjKTsNCj4+PiArICAgIH0NCj4+PiArDQo+Pj4gKyAgICByZXR1cm4g
cmVzOw0KPj4+ICt9DQo+Pj4gKw0KPj4+ICtzdGF0aWMgaW50IHNjbWlfYXNzaWduX2RldmljZSh1
aW50MzJfdCBhZ2VudF9pZCwgdWludDMyX3QgZGV2aWNlX2lkLA0KPj4+ICsgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICB1aW50MzJfdCBmbGFncykNCj4+PiArew0KPj4+ICsgICAgc3RydWN0
IHNjbWlfbXNnX2Jhc2Vfc2V0X2RldmljZV9wZXJtaXNzaW9uc19hMnAgdHg7DQo+Pj4gKyAgICBz
dHJ1Y3Qgc2NtaV9jaGFubmVsICpjaGFubmVsOw0KPj4+ICsgICAgc2NtaV9tc2dfaGVhZGVyX3Qg
aGRyOw0KPj4+ICsgICAgaW50IHJldDsNCj4+PiArDQo+Pj4gKyAgICBjaGFubmVsID0gZ2V0X2No
YW5uZWxfYnlfaWQoSFlQX0NIQU5ORUwpOw0KPj4+ICsgICAgaWYgKCAhY2hhbm5lbCApDQo+Pj4g
KyAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+Pj4gKw0KPj4+ICsgICAgaGRyLmlkID0gU0NNSV9C
QVNFX1NFVF9ERVZJQ0VfUEVSTUlTU0lPTlM7DQo+Pj4gKyAgICBoZHIudHlwZSA9IDA7DQo+Pj4g
KyAgICBoZHIucHJvdG9jb2wgPSBTQ01JX0JBU0VfUFJPVE9DT0w7DQo+Pj4gKw0KPj4+ICsgICAg
dHguYWdlbnRfaWQgPSBhZ2VudF9pZDsNCj4+PiArICAgIHR4LmRldmljZV9pZCA9IGRldmljZV9p
ZDsNCj4+PiArICAgIHR4LmZsYWdzID0gZmxhZ3M7DQo+Pj4gKw0KPj4+ICsgICAgcmV0ID0gZG9f
c21jX3hmZXIoY2hhbm5lbCwgJmhkciwgJnR4LCBzaXplb2YodHgpLCBOVUxMLCAwKTsNCj4+PiAr
ICAgIGlmICggcmV0ID09IC1FT1BOT1RTVVBQICkNCj4+PiArICAgICAgICByZXR1cm4gMDsNCj4+
IElzIGl0IGFjdHVhbGx5IE9LIHRvIHByZXRlbmQgdGhhdCBldmVyeXRoaW5nIHdvcmtlZCBpZiB0
aGUgcmV0dXJuIGlzDQo+PiAtRU9QTk9UU1VQUD8gSSBtZWFuIHRoYXQgaW4gdGhpcyBjYXNlIGNh
biB3ZSBhc3N1bWUgdGhhdCB0aGUgZGV2aWNlIGlzDQo+PiBhY3R1YWxseSBhc3NpZ25lZCBhbnl3
YXk/IFdvdWxkbid0IGZvbGxvdyB1cCBTQ01JIG9wZXJhdGlvbnMgb24gdGhpcw0KPj4gZGV2aWNl
IGZhaWw/DQo+Pg0KPj4NCj4+PiArICAgIHJldHVybiByZXQ7DQo+Pj4gK30NCj4+PiArDQo+Pj4g
K3N0YXRpYyBpbnQgc2NtaV9kdF9hc3NpZ25fZGV2aWNlKHN0cnVjdCBkb21haW4gKmQsDQo+Pj4g
KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdCBkdF9waGFuZGxlX2FyZ3Mg
KmFjX3NwZWMpDQo+Pj4gK3sNCj4+PiArICAgIHN0cnVjdCBzY21pX2NoYW5uZWwgKmFnZW50X2No
YW5uZWw7DQo+Pj4gKyAgICB1aW50MzJfdCBzY21pX2RldmljZV9pZCA9IGFjX3NwZWMtPmFyZ3Nb
MF07DQo+Pj4gKyAgICBpbnQgcmV0Ow0KPj4+ICsNCj4+PiArICAgIGlmICggIWQtPmFyY2guc2Np
X2RhdGEgKQ0KPj4+ICsgICAgICAgIHJldHVybiAwOw0KPj4+ICsNCj4+PiArICAgIC8qIFRoZSBh
Y2Nlc3MtY29udHJvbGxlcnMgaXMgc3BlY2lmaWVkIGZvciBEVCBkZXYsIGJ1dCBpdCdzIG5vdCBh
IFNDTUkgKi8NCj4+PiArICAgIGlmICggYWNfc3BlYy0+bnAgIT0gc2NtaV9kYXRhLmR0X2RldiAp
DQo+Pj4gKyAgICAgICAgcmV0dXJuIDA7DQo+PiBJIHdvbmRlciBpZiB0aGlzIHNob3VsZCBiZSBh
biBlcnJvcg0KPj4NCj4+DQo+Pj4gKyAgICBhZ2VudF9jaGFubmVsID0gZC0+YXJjaC5zY2lfZGF0
YTsNCj4+PiArDQo+Pj4gKyAgICBzcGluX2xvY2soJmFnZW50X2NoYW5uZWwtPmxvY2spOw0KPj4+
ICsNCj4+PiArICAgIHJldCA9IHNjbWlfYXNzaWduX2RldmljZShhZ2VudF9jaGFubmVsLT5hZ2Vu
dF9pZCwgc2NtaV9kZXZpY2VfaWQsDQo+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
U0NNSV9CQVNFX0RFVklDRV9BQ0NFU1NfQUxMT1cpOw0KPj4+ICsgICAgaWYgKCByZXQgKQ0KPj4+
ICsgICAgew0KPj4+ICsgICAgICAgIHByaW50ayhYRU5MT0dfRVJSDQo+Pj4gKyAgICAgICAgICAg
ICAgICJzY21pOiBjb3VsZCBub3QgYXNzaWduIGRldiBmb3IgJXBkIGFnZW50OiVkIGRldl9pZDol
dSAoJWQpIiwNCj4+PiArICAgICAgICAgICAgICAgZCwgYWdlbnRfY2hhbm5lbC0+YWdlbnRfaWQs
IHNjbWlfZGV2aWNlX2lkLCByZXQpOw0KPj4+ICsgICAgfQ0KPj4+ICsNCj4+PiArICAgIHNwaW5f
dW5sb2NrKCZhZ2VudF9jaGFubmVsLT5sb2NrKTsNCj4+PiArICAgIHJldHVybiByZXQ7DQo+Pj4g
K30NCj4+PiArDQo+Pj4gK3N0YXRpYyBfX2luaXQgaW50IGNvbGxlY3RfYWdlbnRzKHN0cnVjdCBk
dF9kZXZpY2Vfbm9kZSAqc2NtaV9ub2RlKQ0KPj4+ICt7DQo+Pj4gKyAgICBjb25zdCBzdHJ1Y3Qg
ZHRfZGV2aWNlX25vZGUgKmNob3Nlbl9ub2RlOw0KPj4+ICsgICAgY29uc3QgX19iZTMyICpwcm9w
Ow0KPj4+ICsgICAgdWludDMyX3QgbGVuLCBpOw0KPj4+ICsNCj4+PiArICAgIGNob3Nlbl9ub2Rl
ID0gZHRfZmluZF9ub2RlX2J5X3BhdGgoIi9jaG9zZW4iKTsNCj4+PiArICAgIGlmICggIWNob3Nl
bl9ub2RlICkNCj4+PiArICAgIHsNCj4+PiArICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAic2Nt
aTogY2hvc2VuIG5vZGUgbm90IGZvdW5kXG4iKTsNCj4+PiArICAgICAgICByZXR1cm4gLUVOT0VO
VDsNCj4+PiArICAgIH0NCj4+PiArDQo+Pj4gKyAgICBwcm9wID0gZHRfZ2V0X3Byb3BlcnR5KGNo
b3Nlbl9ub2RlLCBTQ01JX1NFQ09OREFSWV9BR0VOVFMsICZsZW4pOw0KPj4+ICsgICAgaWYgKCAh
cHJvcCApDQo+Pj4gKyAgICB7DQo+Pj4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19XQVJOSU5HICJz
Y21pOiBObyAlcyBwcm9wZXJ0eSBmb3VuZFxuIiwNCj4+PiArICAgICAgICAgICAgICAgU0NNSV9T
RUNPTkRBUllfQUdFTlRTKTsNCj4+PiArICAgICAgICByZXR1cm4gLUVOT0RFVjsNCj4+PiArICAg
IH0NCj4+PiArDQo+Pj4gKyAgICBpZiAoIGxlbiAlICgzICogc2l6ZW9mKHVpbnQzMl90KSkgKQ0K
Pj4+ICsgICAgew0KPj4+ICsgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJzY21pOiBJbnZhbGlk
IGxlbmd0aCBvZiAlcyBwcm9wZXJ0eTogJWRcbiIsDQo+Pj4gKyAgICAgICAgICAgICAgIFNDTUlf
U0VDT05EQVJZX0FHRU5UUywgbGVuKTsNCj4+PiArICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+
PiArICAgIH0NCj4+PiArDQo+Pj4gKyAgICBmb3IgKCBpID0gMDsgaSA8IGxlbiAvICgzICogc2l6
ZW9mKHVpbnQzMl90KSk7IGkrKyApDQo+Pj4gKyAgICB7DQo+Pj4gKyAgICAgICAgdWludDMyX3Qg
YWdlbnRfaWQgPSBiZTMyX3RvX2NwdSgqcHJvcCsrKTsNCj4+PiArICAgICAgICB1aW50MzJfdCBz
bWNfaWQgPSBiZTMyX3RvX2NwdSgqcHJvcCsrKTsNCj4+PiArICAgICAgICB1aW50MzJfdCBzaG1l
bV9waGFuZGxlID0gYmUzMl90b19jcHUoKnByb3ArKyk7DQo+Pj4gKyAgICAgICAgc3RydWN0IGR0
X2RldmljZV9ub2RlICpub2RlID0gZHRfZmluZF9ub2RlX2J5X3BoYW5kbGUoc2htZW1fcGhhbmRs
ZSk7DQo+Pj4gKyAgICAgICAgdTY0IGFkZHIsIHNpemU7DQo+Pj4gKyAgICAgICAgaW50IHJldDsN
Cj4+PiArDQo+Pj4gKyAgICAgICAgaWYgKCAhbm9kZSApDQo+Pj4gKyAgICAgICAgew0KPj4+ICsg
ICAgICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAic2NtaTogQ291bGQgbm90IGZpbmQgc2htZW0g
bm9kZSBmb3IgYWdlbnQgJWRcbiIsDQo+Pj4gKyAgICAgICAgICAgICAgICAgICBhZ2VudF9pZCk7
DQo+Pj4gKyAgICAgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4+ICsgICAgICAgIH0NCj4+PiAr
DQo+Pj4gKyAgICAgICAgcmV0ID0gZHRfZGV2aWNlX2dldF9hZGRyZXNzKG5vZGUsIDAsICZhZGRy
LCAmc2l6ZSk7DQo+Pj4gKyAgICAgICAgaWYgKCByZXQgKQ0KPj4+ICsgICAgICAgIHsNCj4+PiAr
ICAgICAgICAgICAgcHJpbnRrKFhFTkxPR19FUlINCj4+PiArICAgICAgICAgICAgICAgICAgICJz
Y21pOiBDb3VsZCBub3QgcmVhZCBzaG1lbSBhZGRyZXNzIGZvciBhZ2VudCAlZDogJWQiLA0KPj4+
ICsgICAgICAgICAgICAgICAgICAgYWdlbnRfaWQsIHJldCk7DQo+Pj4gKyAgICAgICAgICAgIHJl
dHVybiByZXQ7DQo+Pj4gKyAgICAgICAgfQ0KPj4+ICsNCj4+PiArICAgICAgICBpZiAoICFJU19B
TElHTkVEKHNpemUsIFNDTUlfU0hNRU1fTUFQUEVEX1NJWkUpICkNCj4+PiArICAgICAgICB7DQo+
Pj4gKyAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJzY21pOiBzaG1lbSBtZW1vcnkgaXMg
bm90IGFsaWduZWRcbiIpOw0KPj4+ICsgICAgICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+PiAr
ICAgICAgICB9DQo+Pj4gKw0KPj4+ICsgICAgICAgIHJldCA9IFBUUl9SRVQoc21jX2NyZWF0ZV9j
aGFubmVsKGFnZW50X2lkLCBzbWNfaWQsIGFkZHIpKTsNCj4+PiArICAgICAgICBpZiAoIHJldCAp
DQo+Pj4gKyAgICAgICAgew0KPj4+ICsgICAgICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAic2Nt
aTogQ291bGQgbm90IGNyZWF0ZSBjaGFubmVsIGZvciBhZ2VudCAlZDogJWQiLA0KPj4+ICsgICAg
ICAgICAgICAgICAgICAgYWdlbnRfaWQsIHJldCk7DQo+Pj4gKyAgICAgICAgICAgIHJldHVybiBy
ZXQ7DQo+Pj4gKyAgICAgICAgfQ0KPj4+ICsNCj4+PiArICAgICAgICBwcmludGsoWEVOTE9HX0RF
QlVHICJzY21pOiBBZ2VudCAlZCBTTUMgJVggYWRkciAlbHhcbiIsIGFnZW50X2lkLA0KPj4+ICsg
ICAgICAgICAgICAgICBzbWNfaWQsIGFkZHIpOw0KPj4+ICsgICAgfQ0KPj4+ICsNCj4+PiArICAg
IHJldHVybiAwOw0KPj4+ICt9DQo+Pj4gKw0KPj4+ICtzdGF0aWMgaW50IHNjbWlfZG9tYWluX2lu
aXQoc3RydWN0IGRvbWFpbiAqZCwNCj4+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0
cnVjdCB4ZW5fZG9tY3RsX2NyZWF0ZWRvbWFpbiAqY29uZmlnKQ0KPj4+ICt7DQo+Pj4gKyAgICBz
dHJ1Y3Qgc2NtaV9jaGFubmVsICpjaGFubmVsOw0KPj4+ICsgICAgaW50IHJldDsNCj4+PiArDQo+
Pj4gKyAgICBpZiAoICFzY21pX2RhdGEuaW5pdGlhbGl6ZWQgKQ0KPj4+ICsgICAgICAgIHJldHVy
biAwOw0KPj4+ICsNCj4+PiArICAgIC8qDQo+Pj4gKyAgICAgKiBTcGVjaWFsIGNhc2UgZm9yIERv
bTAgLSB0aGUgU0NNSSBzdXBwb3J0IGlzIGVuYWJsZWQgYmFzaW5nIG9uDQo+Pj4gKyAgICAgKiAi
ZG9tMF9zY2lfYWdlbnRfaWQiIFhlbiBjb21tYW5kIGxpbmUgcGFyYW1ldGVyDQo+Pj4gKyAgICAg
Ki8NCj4+PiArICAgIGlmICggaXNfaGFyZHdhcmVfZG9tYWluKGQpICkNCj4+PiArICAgIHsNCj4+
PiArICAgICAgICBpZiAoIG9wdF9kb20wX3NjbWlfYWdlbnRfaWQgIT0gU0NNSV9BR0VOVF9JRF9J
TlZBTElEICkNCj4+PiArICAgICAgICB7DQo+Pj4gKyAgICAgICAgICAgIGNvbmZpZy0+YXJjaC5h
cm1fc2NpX3R5cGUgPSBYRU5fRE9NQ1RMX0NPTkZJR19BUk1fU0NJX1NDTUlfU01DX01BOw0KPj4+
ICsgICAgICAgICAgICBjb25maWctPmFyY2guYXJtX3NjaV9hZ2VudF9pZCA9IG9wdF9kb20wX3Nj
bWlfYWdlbnRfaWQ7DQo+Pj4gKyAgICAgICAgfQ0KPj4+ICsgICAgICAgIGVsc2UNCj4+PiArICAg
ICAgICAgICAgY29uZmlnLT5hcmNoLmFybV9zY2lfdHlwZSA9IFhFTl9ET01DVExfQ09ORklHX0FS
TV9TQ0lfTk9ORTsNCj4+PiArICAgIH0NCj4+PiArDQo+Pj4gKyAgICBpZiAoIGNvbmZpZy0+YXJj
aC5hcm1fc2NpX3R5cGUgPT0gWEVOX0RPTUNUTF9DT05GSUdfQVJNX1NDSV9OT05FICkNCj4+PiAr
ICAgICAgICByZXR1cm4gMDsNCj4+PiArDQo+Pj4gKyAgICBjaGFubmVsID0gYWNxdWlyZV9zY21p
X2NoYW5uZWwoZCwgY29uZmlnLT5hcmNoLmFybV9zY2lfYWdlbnRfaWQpOw0KPj4+ICsgICAgaWYg
KCBJU19FUlIoY2hhbm5lbCkgKQ0KPj4+ICsgICAgew0KPj4+ICsgICAgICAgIHByaW50ayhYRU5M
T0dfRVJSDQo+Pj4gKyAgICAgICAgICAgICAgICJzY21pOiBGYWlsZWQgdG8gYWNxdWlyZSBTQ01J
IGNoYW5uZWwgZm9yIGFnZW50X2lkICV1OiAlbGRcbiIsDQo+Pj4gKyAgICAgICAgICAgICAgIGNv
bmZpZy0+YXJjaC5hcm1fc2NpX2FnZW50X2lkLCBQVFJfRVJSKGNoYW5uZWwpKTsNCj4+PiArICAg
ICAgICByZXR1cm4gUFRSX0VSUihjaGFubmVsKTsNCj4+PiArICAgIH0NCj4+PiArDQo+Pj4gKyAg
ICBwcmludGsoWEVOTE9HX0lORk8NCj4+PiArICAgICAgICAgICAic2NtaTogQWNxdWlyZSBjaGFu
bmVsIGlkID0gMHgleCwgZG9tYWluX2lkID0gJWQgcGFkZHIgPSAweCVseFxuIiwNCj4+PiArICAg
ICAgICAgICBjaGFubmVsLT5hZ2VudF9pZCwgY2hhbm5lbC0+ZG9tYWluX2lkLCBjaGFubmVsLT5w
YWRkcik7DQo+Pj4gKw0KPj4+ICsgICAgLyoNCj4+PiArICAgICAqIERvbTAgKGlmIHByZXNlbnQp
IG5lZWRzIHRvIGhhdmUgYW4gYWNjZXNzIHRvIHRoZSBndWVzdCBtZW1vcnkgcmFuZ2UNCj4+PiAr
ICAgICAqIHRvIHNhdGlzZnkgaW9tZW1fYWNjZXNzX3Blcm1pdHRlZCgpIGNoZWNrIGluIFhFTl9E
T01DVExfaW9tZW1fcGVybWlzc2lvbg0KPj4+ICsgICAgICogZG9tY3RsLg0KPj4gSWRlYWxseSB0
aGlzIHNob3VsZCBub3QgYmUgbmVlZGVkIGJ1dCBJIHVuZGVyc3RhbmQgd2UgZG9uJ3QgaGF2ZSBh
bg0KPj4gZWFzeSBzb2x1dGlvbiwgSSB0aGluayB3ZSBjYW4gZ28gYWhlYWQgd2l0aCB0aGlzIGZv
ciBub3cuDQo+Pg0KPj4NCj4+PiArICAgICAqLw0KPj4+ICsgICAgaWYgKCBoYXJkd2FyZV9kb21h
aW4gJiYgIWlzX2hhcmR3YXJlX2RvbWFpbihkKSApDQo+Pj4gKyAgICB7DQo+Pj4gKyAgICAgICAg
cmV0ID0gaW9tZW1fcGVybWl0X2FjY2VzcyhoYXJkd2FyZV9kb21haW4sIHBhZGRyX3RvX3Bmbihj
aGFubmVsLT5wYWRkciksDQo+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBw
YWRkcl90b19wZm4oY2hhbm5lbC0+cGFkZHIgKyBQQUdFX1NJWkUgLSAxKSk7DQo+Pj4gKyAgICAg
ICAgaWYgKCByZXQgKQ0KPj4+ICsgICAgICAgICAgICBnb3RvIGVycm9yOw0KPj4+ICsgICAgfQ0K
Pj4+ICsNCj4+PiArICAgIGQtPmFyY2guc2NpX2RhdGEgPSBjaGFubmVsOw0KPj4+ICsgICAgZC0+
YXJjaC5zY2lfZW5hYmxlZCA9IHRydWU7DQo+Pj4gKw0KPj4+ICsgICAgcmV0dXJuIDA7DQo+Pj4g
Kw0KPj4+ICtlcnJvcjoNCj4+PiArICAgIHJlbGlucXVpc2hfc2NtaV9jaGFubmVsKGNoYW5uZWwp
Ow0KPj4+ICsgICAgcmV0dXJuIHJldDsNCj4+PiArfQ0KPj4+ICsNCj4+PiAraW50IHNjbWlfZG9t
YWluX3Nhbml0aXNlX2NvbmZpZyhzdHJ1Y3QgeGVuX2RvbWN0bF9jcmVhdGVkb21haW4gKmNvbmZp
ZykNCj4+PiArew0KPj4+ICsgICAgaWYgKCBjb25maWctPmFyY2guYXJtX3NjaV90eXBlICE9IFhF
Tl9ET01DVExfQ09ORklHX0FSTV9TQ0lfTk9ORSAmJg0KPj4+ICsgICAgICAgICBjb25maWctPmFy
Y2guYXJtX3NjaV90eXBlICE9IFhFTl9ET01DVExfQ09ORklHX0FSTV9TQ0lfU0NNSV9TTUNfTUEg
KQ0KPj4+ICsgICAgew0KPj4+ICsgICAgICAgIGRwcmludGsoWEVOTE9HX0lORk8sICJzY21pOiBV
bnN1cHBvcnRlZCBBUk1fU0NJIHR5cGVcbiIpOw0KPj4+ICsgICAgICAgIHJldHVybiAtRUlOVkFM
Ow0KPj4+ICsgICAgfQ0KPj4+ICsgICAgZWxzZSBpZiAoIGNvbmZpZy0+YXJjaC5hcm1fc2NpX3R5
cGUgPT0NCj4+PiArICAgICAgICAgICAgICBYRU5fRE9NQ1RMX0NPTkZJR19BUk1fU0NJX1NDTUlf
U01DX01BICYmDQo+Pj4gKyAgICAgICAgICAgICAgY29uZmlnLT5hcmNoLmFybV9zY2lfYWdlbnRf
aWQgPT0gMCApDQo+Pj4gKyAgICB7DQo+Pj4gKyAgICAgICAgZHByaW50ayhYRU5MT0dfSU5GTywN
Cj4+PiArICAgICAgICAgICAgICAgICJzY21pOiBBIHplcm8gQVJNIFNDTUkgYWdlbnRfaWQgaXMg
bm90IHN1cHBvcnRlZFxuIik7DQo+Pj4gKyAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+Pj4gKyAg
ICB9DQo+Pj4gKw0KPj4+ICsgICAgcmV0dXJuIDA7DQo+Pj4gK30NCj4+PiArDQo+Pj4gK3N0YXRp
YyBpbnQgc2NtaV9yZWxpbnF1aXNoX3Jlc291cmNlcyhzdHJ1Y3QgZG9tYWluICpkKQ0KPj4+ICt7
DQo+Pj4gKyAgICBpbnQgcmV0Ow0KPj4+ICsgICAgc3RydWN0IHNjbWlfY2hhbm5lbCAqY2hhbm5l
bCwgKmFnZW50X2NoYW5uZWw7DQo+Pj4gKyAgICBzY21pX21zZ19oZWFkZXJfdCBoZHI7DQo+Pj4g
KyAgICBzdHJ1Y3Qgc2NtaV9tc2dfYmFzZV9yZXNldF9hZ2VudF9jZmdfYTJwIHR4Ow0KPj4+ICsN
Cj4+PiArICAgIGlmICggIWQtPmFyY2guc2NpX2RhdGEgKQ0KPj4+ICsgICAgICAgIHJldHVybiAw
Ow0KPj4+ICsNCj4+PiArICAgIGFnZW50X2NoYW5uZWwgPSBkLT5hcmNoLnNjaV9kYXRhOw0KPj4+
ICsNCj4+PiArICAgIHNwaW5fbG9jaygmYWdlbnRfY2hhbm5lbC0+bG9jayk7DQo+Pj4gKyAgICB0
eC5hZ2VudF9pZCA9IGFnZW50X2NoYW5uZWwtPmFnZW50X2lkOw0KPj4+ICsgICAgc3Bpbl91bmxv
Y2soJmFnZW50X2NoYW5uZWwtPmxvY2spOw0KPj4+ICsNCj4+PiArICAgIGNoYW5uZWwgPSBnZXRf
Y2hhbm5lbF9ieV9pZChIWVBfQ0hBTk5FTCk7DQo+Pj4gKyAgICBpZiAoICFjaGFubmVsICkNCj4+
PiArICAgIHsNCj4+PiArICAgICAgICBwcmludGsoWEVOTE9HX0VSUg0KPj4+ICsgICAgICAgICAg
ICAgICAic2NtaTogVW5hYmxlIHRvIGdldCBIeXBlcnZpc29yIHNjbWkgY2hhbm5lbCBmb3IgZG9t
YWluICVkXG4iLA0KPj4+ICsgICAgICAgICAgICAgICBkLT5kb21haW5faWQpOw0KPj4+ICsgICAg
ICAgIHJldHVybiAtRUlOVkFMOw0KPj4+ICsgICAgfQ0KPj4+ICsNCj4+PiArICAgIGhkci5pZCA9
IFNDTUlfQkFTRV9SRVNFVF9BR0VOVF9DT05GSUdVUkFUSU9OOw0KPj4+ICsgICAgaGRyLnR5cGUg
PSAwOw0KPj4+ICsgICAgaGRyLnByb3RvY29sID0gU0NNSV9CQVNFX1BST1RPQ09MOw0KPj4+ICsN
Cj4+PiArICAgIHR4LmZsYWdzID0gMDsNCj4+PiArDQo+Pj4gKyAgICByZXQgPSBkb19zbWNfeGZl
cihjaGFubmVsLCAmaGRyLCAmdHgsIHNpemVvZih0eCksIE5VTEwsIDApOw0KPj4+ICsgICAgaWYg
KCByZXQgPT0gLUVPUE5PVFNVUFAgKQ0KPj4+ICsgICAgICAgIHJldHVybiAwOw0KPj4+ICsNCj4+
PiArICAgIHJldHVybiByZXQ7DQo+Pj4gK30NCj4+PiArDQo+Pj4gK3N0YXRpYyB2b2lkIHNjbWlf
ZG9tYWluX2Rlc3Ryb3koc3RydWN0IGRvbWFpbiAqZCkNCj4+PiArew0KPj4+ICsgICAgc3RydWN0
IHNjbWlfY2hhbm5lbCAqY2hhbm5lbDsNCj4+PiArDQo+Pj4gKyAgICBpZiAoICFkLT5hcmNoLnNj
aV9kYXRhICkNCj4+PiArICAgICAgICByZXR1cm47DQo+Pj4gKw0KPj4+ICsgICAgY2hhbm5lbCA9
IGQtPmFyY2guc2NpX2RhdGE7DQo+Pj4gKyAgICBzcGluX2xvY2soJmNoYW5uZWwtPmxvY2spOw0K
Pj4+ICsNCj4+PiArICAgIHJlbGlucXVpc2hfc2NtaV9jaGFubmVsKGNoYW5uZWwpOw0KPj4+ICsg
ICAgcHJpbnRrKFhFTkxPR19ERUJVRyAic2NtaTogRnJlZSBkb21haW4gJWRcbiIsIGQtPmRvbWFp
bl9pZCk7DQo+Pj4gKw0KPj4+ICsgICAgZC0+YXJjaC5zY2lfZGF0YSA9IE5VTEw7DQo+Pj4gKyAg
ICBkLT5hcmNoLnNjaV9lbmFibGVkID0gdHJ1ZTsNCj4+PiArDQo+Pj4gKyAgICBzcGluX3VubG9j
aygmY2hhbm5lbC0+bG9jayk7DQo+Pj4gK30NCj4+PiArDQo+Pj4gK3N0YXRpYyBib29sIHNjbWlf
aGFuZGxlX2NhbGwoc3RydWN0IGNwdV91c2VyX3JlZ3MgKnJlZ3MpDQo+Pj4gK3sNCj4+PiArICAg
IHVpbnQzMl90IGZpZCA9ICh1aW50MzJfdClnZXRfdXNlcl9yZWcocmVncywgMCk7DQo+Pj4gKyAg
ICBzdHJ1Y3Qgc2NtaV9jaGFubmVsICphZ2VudF9jaGFubmVsOw0KPj4+ICsgICAgc3RydWN0IGRv
bWFpbiAqZCA9IGN1cnJlbnQtPmRvbWFpbjsNCj4+PiArICAgIHN0cnVjdCBhcm1fc21jY2NfcmVz
IHJlc3A7DQo+Pj4gKyAgICBib29sIHJlcyA9IGZhbHNlOw0KPj4+ICsNCj4+PiArICAgIGlmICgg
IXNjaV9kb21haW5faXNfZW5hYmxlZChkKSApDQo+Pj4gKyAgICAgICAgcmV0dXJuIGZhbHNlOw0K
Pj4+ICsNCj4+PiArICAgIGFnZW50X2NoYW5uZWwgPSBkLT5hcmNoLnNjaV9kYXRhOw0KPj4+ICsg
ICAgc3Bpbl9sb2NrKCZhZ2VudF9jaGFubmVsLT5sb2NrKTsNCj4+PiArDQo+Pj4gKyAgICBpZiAo
IGFnZW50X2NoYW5uZWwtPmZ1bmNfaWQgIT0gZmlkICkNCj4+PiArICAgIHsNCj4+PiArICAgICAg
ICByZXMgPSBmYWxzZTsNCj4+PiArICAgICAgICBnb3RvIHVubG9jazsNCj4+PiArICAgIH0NCj4+
PiArDQo+Pj4gKyAgICBhcm1fc21jY2NfMV8xX3NtYyhmaWQsDQo+Pj4gKyAgICAgICAgICAgICAg
ICAgICAgICBnZXRfdXNlcl9yZWcocmVncywgMSksDQo+Pj4gKyAgICAgICAgICAgICAgICAgICAg
ICBnZXRfdXNlcl9yZWcocmVncywgMiksDQo+Pj4gKyAgICAgICAgICAgICAgICAgICAgICBnZXRf
dXNlcl9yZWcocmVncywgMyksDQo+Pj4gKyAgICAgICAgICAgICAgICAgICAgICBnZXRfdXNlcl9y
ZWcocmVncywgNCksDQo+Pj4gKyAgICAgICAgICAgICAgICAgICAgICBnZXRfdXNlcl9yZWcocmVn
cywgNSksDQo+Pj4gKyAgICAgICAgICAgICAgICAgICAgICBnZXRfdXNlcl9yZWcocmVncywgNiks
DQo+Pj4gKyAgICAgICAgICAgICAgICAgICAgICBnZXRfdXNlcl9yZWcocmVncywgNyksDQo+Pj4g
KyAgICAgICAgICAgICAgICAgICAgICAmcmVzcCk7DQo+Pj4gKw0KPj4+ICsgICAgc2V0X3VzZXJf
cmVnKHJlZ3MsIDAsIHJlc3AuYTApOw0KPj4+ICsgICAgc2V0X3VzZXJfcmVnKHJlZ3MsIDEsIHJl
c3AuYTEpOw0KPj4+ICsgICAgc2V0X3VzZXJfcmVnKHJlZ3MsIDIsIHJlc3AuYTIpOw0KPj4+ICsg
ICAgc2V0X3VzZXJfcmVnKHJlZ3MsIDMsIHJlc3AuYTMpOw0KPj4+ICsgICAgcmVzID0gdHJ1ZTsN
Cj4+PiArdW5sb2NrOg0KPj4+ICsgICAgc3Bpbl91bmxvY2soJmFnZW50X2NoYW5uZWwtPmxvY2sp
Ow0KPj4+ICsNCj4+PiArICAgIHJldHVybiByZXM7DQo+Pj4gK30NCj4+PiArDQo+Pj4gK3N0YXRp
YyBjb25zdCBzdHJ1Y3Qgc2NpX21lZGlhdG9yX29wcyBzY21pX29wcyA9IHsNCj4+PiArICAgIC5k
b21haW5faW5pdCA9IHNjbWlfZG9tYWluX2luaXQsDQo+Pj4gKyAgICAuZG9tYWluX2Rlc3Ryb3kg
PSBzY21pX2RvbWFpbl9kZXN0cm95LA0KPj4+ICsgICAgLnJlbGlucXVpc2hfcmVzb3VyY2VzID0g
c2NtaV9yZWxpbnF1aXNoX3Jlc291cmNlcywNCj4+PiArICAgIC5oYW5kbGVfY2FsbCA9IHNjbWlf
aGFuZGxlX2NhbGwsDQo+Pj4gKyAgICAuZG9tMF9kdF9oYW5kbGVfbm9kZSA9IHNjbWlfZHRfaGFu
ZGxlX25vZGUsDQo+Pj4gKyAgICAuZG9tMF9kdF9maW5hbGl6ZSA9IHNjbWlfZHRfZmluYWxpemUs
DQo+Pj4gKyAgICAuZG9tYWluX3Nhbml0aXNlX2NvbmZpZyA9IHNjbWlfZG9tYWluX3Nhbml0aXNl
X2NvbmZpZywNCj4+PiArICAgIC5hc3NpZ25fZHRfZGV2aWNlID0gc2NtaV9kdF9hc3NpZ25fZGV2
aWNlLA0KPj4+ICt9Ow0KPj4+ICsNCj4+PiArc3RhdGljIGludCBfX2luaXQgc2NtaV9jaGVja19z
bWNjY192ZXIodm9pZCkNCj4+PiArew0KPj4+ICsgICAgaWYgKCBzbWNjY192ZXIgPCBBUk1fU01D
Q0NfVkVSU0lPTl8xXzEgKQ0KPj4+ICsgICAgew0KPj4+ICsgICAgICAgIHByaW50ayhYRU5MT0df
V0FSTklORw0KPj4+ICsgICAgICAgICAgICAgICAic2NtaTogTm8gU01DQ0MgMS4xIHN1cHBvcnQs
IFNDTUkgY2FsbHMgZm9yd2FyZGluZyBkaXNhYmxlZFxuIik7DQo+Pj4gKyAgICAgICAgcmV0dXJu
IC1FTk9TWVM7DQo+Pj4gKyAgICB9DQo+Pj4gKw0KPj4+ICsgICAgcmV0dXJuIDA7DQo+Pj4gK30N
Cj4+PiArDQo+Pj4gK3N0YXRpYyBfX2luaXQgaW50IHNjbWlfcHJvYmUoc3RydWN0IGR0X2Rldmlj
ZV9ub2RlICpzY21pX25vZGUsIGNvbnN0IHZvaWQgKmRhdGEpDQo+Pj4gK3sNCj4+PiArICAgIHU2
NCBhZGRyLCBzaXplOw0KPj4+ICsgICAgaW50IHJldCwgaTsNCj4+PiArICAgIHN0cnVjdCBzY21p
X2NoYW5uZWwgKmNoYW5uZWwsICphZ2VudF9jaGFubmVsOw0KPj4+ICsgICAgaW50IG5fYWdlbnRz
Ow0KPj4+ICsgICAgc2NtaV9tc2dfaGVhZGVyX3QgaGRyOw0KPj4+ICsgICAgc3RydWN0IHNjbWlf
bXNnX2Jhc2VfYXR0cmlidXRlc19wMmEgcng7DQo+Pj4gKw0KPj4+ICsgICAgQVNTRVJUKHNjbWlf
bm9kZSAhPSBOVUxMKTsNCj4+PiArDQo+Pj4gKyAgICBJTklUX0xJU1RfSEVBRCgmc2NtaV9kYXRh
LmNoYW5uZWxfbGlzdCk7DQo+Pj4gKyAgICBzcGluX2xvY2tfaW5pdCgmc2NtaV9kYXRhLmNoYW5u
ZWxfbGlzdF9sb2NrKTsNCj4+PiArDQo+Pj4gKyAgICBpZiAoICFhY3BpX2Rpc2FibGVkICkNCj4+
PiArICAgIHsNCj4+PiArICAgICAgICBwcmludGsoWEVOTE9HX1dBUk5JTkcgInNjbWk6IGlzIG5v
dCBzdXBwb3J0ZWQgd2hlbiB1c2luZyBBQ1BJXG4iKTsNCj4+PiArICAgICAgICByZXR1cm4gLUVJ
TlZBTDsNCj4+PiArICAgIH0NCj4+PiArDQo+Pj4gKyAgICByZXQgPSBzY21pX2NoZWNrX3NtY2Nj
X3ZlcigpOw0KPj4+ICsgICAgaWYgKCByZXQgKQ0KPj4+ICsgICAgICAgIHJldHVybiByZXQ7DQo+
Pj4gKw0KPj4+ICsgICAgaWYgKCAhZHRfcHJvcGVydHlfcmVhZF91MzIoc2NtaV9ub2RlLCAiYXJt
LHNtYy1pZCIsICZzY21pX2RhdGEuZnVuY19pZCkgKQ0KPj4+ICsgICAgew0KPj4+ICsgICAgICAg
IHByaW50ayhYRU5MT0dfRVJSICJzY21pOiB1bmFibGUgdG8gcmVhZCBzbWMtaWQgZnJvbSBEVFxu
Iik7DQo+Pj4gKyAgICAgICAgcmV0dXJuIC1FTk9FTlQ7DQo+Pj4gKyAgICB9DQo+Pj4gKw0KPj4+
ICsgICAgLyogc2F2ZSBzaG1lbSBwaGFuZGxlIGFuZCByZS11c2UgaXQgZnJvIERvbTAgRFQgc2ht
ZW0gbm9kZSAqLw0KPj4+ICsgICAgaWYgKCAhZHRfcHJvcGVydHlfcmVhZF91MzIoc2NtaV9ub2Rl
LCAic2htZW0iLCAmc2NtaV9kYXRhLnNobWVtX3BoYW5kbGUpICkNCj4+PiArICAgIHsNCj4+PiAr
ICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAic2NtaTogdW5hYmxlIHRvIHJlYWQgc2htZW0gcGhh
bmRsZSBmcm9tIERUXG4iKTsNCj4+PiArICAgICAgICByZXR1cm4gLUVOT0VOVDsNCj4+PiArICAg
IH0NCj4+PiArDQo+Pj4gKyAgICByZXQgPSBzY21pX2R0X3JlYWRfaHlwX2NoYW5uZWxfYWRkcihz
Y21pX25vZGUsICZhZGRyLCAmc2l6ZSk7DQo+Pj4gKyAgICBpZiAoIElTX0VSUl9WQUxVRShyZXQp
ICkNCj4+PiArICAgICAgICByZXR1cm4gLUVOT0VOVDsNCj4+PiArDQo+Pj4gKyAgICBpZiAoICFJ
U19BTElHTkVEKHNpemUsIFNDTUlfU0hNRU1fTUFQUEVEX1NJWkUpICkNCj4+PiArICAgIHsNCj4+
PiArICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAic2NtaTogc2htZW0gbWVtb3J5IGlzIG5vdCBh
bGlnbmVkXG4iKTsNCj4+PiArICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+PiArICAgIH0NCj4+
PiArDQo+Pj4gKyAgICBzY21pX2RhdGEuZHRfZGV2ID0gc2NtaV9ub2RlOw0KPj4+ICsNCj4+PiAr
ICAgIGNoYW5uZWwgPSBzbWNfY3JlYXRlX2NoYW5uZWwoSFlQX0NIQU5ORUwsIHNjbWlfZGF0YS5m
dW5jX2lkLCBhZGRyKTsNCj4+PiArICAgIGlmICggSVNfRVJSKGNoYW5uZWwpICkNCj4+PiArICAg
ICAgICBnb3RvIG91dDsNCj4+PiArDQo+Pj4gKyAgICByZXQgPSBtYXBfY2hhbm5lbF9tZW1vcnko
Y2hhbm5lbCk7DQo+Pj4gKyAgICBpZiAoIHJldCApDQo+Pj4gKyAgICAgICAgZ290byBvdXQ7DQo+
Pj4gKw0KPj4+ICsgICAgY2hhbm5lbC0+ZG9tYWluX2lkID0gRE9NSURfWEVOOw0KPj4+ICsNCj4+
PiArICAgIGhkci5pZCA9IFNDTUlfQkFTRV9QUk9UT0NPTF9BVFRJQlVURVM7DQo+Pj4gKyAgICBo
ZHIudHlwZSA9IDA7DQo+Pj4gKyAgICBoZHIucHJvdG9jb2wgPSBTQ01JX0JBU0VfUFJPVE9DT0w7
DQo+Pj4gKw0KPj4+ICsgICAgcmV0ID0gZG9fc21jX3hmZXIoY2hhbm5lbCwgJmhkciwgTlVMTCwg
MCwgJnJ4LCBzaXplb2YocngpKTsNCj4+PiArICAgIGlmICggcmV0ICkNCj4+PiArICAgICAgICBn
b3RvIGVycm9yOw0KPj4+ICsNCj4+PiArICAgIG5fYWdlbnRzID0gU0NNSV9GSUVMRF9HRVQoU0NN
SV9CQVNFX0FUVFJfTlVNX0FHRU5ULCByeC5hdHRyaWJ1dGVzKTsNCj4+PiArICAgIHByaW50ayhY
RU5MT0dfREVCVUcgInNjbWk6IEdvdCBhZ2VudCBjb3VudCAlZFxuIiwgbl9hZ2VudHMpOw0KPj4+
ICsNCj4+PiArICAgIHJldCA9IGNvbGxlY3RfYWdlbnRzKHNjbWlfbm9kZSk7DQo+Pj4gKyAgICBp
ZiAoIHJldCApDQo+Pj4gKyAgICAgICAgZ290byBlcnJvcjsNCj4+PiArDQo+Pj4gKyAgICBpID0g
MTsNCj4+PiArDQo+Pj4gKyAgICBsaXN0X2Zvcl9lYWNoX2VudHJ5KGFnZW50X2NoYW5uZWwsICZz
Y21pX2RhdGEuY2hhbm5lbF9saXN0LCBsaXN0KQ0KPj4+ICsgICAgew0KPj4+ICsgICAgICAgIHN0
cnVjdCBzY21pX21zZ19iYXNlX2Rpc2NvdmVyX2FnZW50X3AyYSBkYV9yeDsNCj4+PiArICAgICAg
ICBzdHJ1Y3Qgc2NtaV9tc2dfYmFzZV9kaXNjb3Zlcl9hZ2VudF9hMnAgZGFfdHg7DQo+Pj4gKw0K
Pj4+ICsgICAgICAgIHJldCA9IG1hcF9jaGFubmVsX21lbW9yeShhZ2VudF9jaGFubmVsKTsNCj4+
PiArICAgICAgICBpZiAoIHJldCApDQo+Pj4gKyAgICAgICAgICAgIGdvdG8gZXJyb3I7DQo+Pj4g
Kw0KPj4+ICsgICAgICAgIGhkci5pZCA9IFNDTUlfQkFTRV9ESVNDT1ZFUl9BR0VOVDsNCj4+PiAr
ICAgICAgICBoZHIudHlwZSA9IDA7DQo+Pj4gKyAgICAgICAgaGRyLnByb3RvY29sID0gU0NNSV9C
QVNFX1BST1RPQ09MOw0KPj4+ICsNCj4+PiArICAgICAgICBkYV90eC5hZ2VudF9pZCA9IGFnZW50
X2NoYW5uZWwtPmFnZW50X2lkOw0KPj4+ICsNCj4+PiArICAgICAgICByZXQgPSBkb19zbWNfeGZl
cihhZ2VudF9jaGFubmVsLCAmaGRyLCAmZGFfdHgsIHNpemVvZihkYV90eCksICZkYV9yeCwNCj4+
PiArICAgICAgICAgICAgICAgICAgICAgICAgICBzaXplb2YoZGFfcngpKTsNCj4+PiArICAgICAg
ICBpZiAoIGFnZW50X2NoYW5uZWwtPmRvbWFpbl9pZCAhPSBET01JRF9YRU4gKQ0KPj4+ICsgICAg
ICAgICAgICB1bm1hcF9jaGFubmVsX21lbW9yeShhZ2VudF9jaGFubmVsKTsNCj4+PiArICAgICAg
ICBpZiAoIHJldCApDQo+Pj4gKyAgICAgICAgICAgIGdvdG8gZXJyb3I7DQo+Pj4gKw0KPj4+ICsg
ICAgICAgIHByaW50ayhYRU5MT0dfREVCVUcgImlkPTB4JXggbmFtZT0lc1xuIiwgZGFfcnguYWdl
bnRfaWQsIGRhX3J4Lm5hbWUpOw0KPj4+ICsNCj4+PiArICAgICAgICBhZ2VudF9jaGFubmVsLT5h
Z2VudF9pZCA9IGRhX3J4LmFnZW50X2lkOw0KPj4gSXQgaXMgT0sgdG8gc2V0IGFnZW50X2NoYW5u
ZWwtPmFnZW50X2lkIHRvIHRoZSB2YWx1ZSBwcm92aWRlZCBieSB0aGUNCj4+IFNDTUkgc2VydmVy
LCBidXQgaWYgd2UgYXJlIGFsc28gdGFraW5nIHRoZSBhZ2VudF9jaGFubmVsLT5hZ2VudF9pZCB2
YWx1ZQ0KPj4gZnJvbSB0aGUgdXNlciB2aWEgZGV2aWNlIHRyZWUsIHNob3VsZG4ndCB3ZSB0aHJv
dyBhbiBlcnJvciBpZiB0aGVyZSBpcyBhDQo+PiBtaXNtYXRjaD8NCj4+DQo+PiBPciBldmVuIGJl
dHRlcjogY2FuIHdlIGF2b2lkIHRha2luZyB0aGUgdmFsdWUgdmlhIGRldmljZSB0cmVlIHRvIG1h
a2UgaXQNCj4+IGVhc2llciB0byBjb25maWd1cmU/DQo+Pg0KPj4NCj4+PiArICAgICAgICBpZiAo
IGkgPiBuX2FnZW50cyApDQo+Pj4gKyAgICAgICAgICAgIGJyZWFrOw0KPj4+ICsNCj4+PiArICAg
ICAgICBpKys7DQo+Pj4gKyAgICB9DQo+Pj4gKw0KPj4+ICsgICAgcmV0ID0gc2NpX3JlZ2lzdGVy
KCZzY21pX29wcyk7DQo+Pj4gKyAgICBpZiAoIHJldCApDQo+Pj4gKyAgICB7DQo+Pj4gKyAgICAg
ICAgcHJpbnRrKFhFTkxPR19FUlIgIlNDTUk6IG1lZGlhdG9yIGFscmVhZHkgcmVnaXN0ZXJlZCAo
cmV0ID0gJWQpXG4iLA0KPj4+ICsgICAgICAgICAgICAgICByZXQpOw0KPj4+ICsgICAgICAgIHJl
dHVybiByZXQ7DQo+Pj4gKyAgICB9DQo+Pj4gKw0KPj4+ICsgICAgc2NtaV9kYXRhLmluaXRpYWxp
emVkID0gdHJ1ZTsNCj4+PiArICAgIGdvdG8gb3V0Ow0KPj4+ICsNCj4+PiArZXJyb3I6DQo+Pj4g
KyAgICB1bm1hcF9jaGFubmVsX21lbW9yeShjaGFubmVsKTsNCj4+PiArICAgIGZyZWVfY2hhbm5l
bF9saXN0KCk7DQo+Pj4gK291dDoNCj4+PiArICAgIHJldHVybiByZXQ7DQo+Pj4gK30NCj4+PiAr
DQo+Pj4gK3N0YXRpYyBjb25zdCBzdHJ1Y3QgZHRfZGV2aWNlX21hdGNoIHNjbWlfc21jX21hdGNo
W10gX19pbml0Y29uc3QgPSB7DQo+Pj4gKyAgICBEVF9NQVRDSF9DT01QQVRJQkxFKCJhcm0sc2Nt
aS1zbWMiKSwNCj4+PiArICAgIHsgLyogc2VudGluZWwgKi8gfSwNCj4+PiArfTsNCj4+PiArDQo+
Pj4gK0RUX0RFVklDRV9TVEFSVChzY21pX3NtY19tYSwgIlNDTUkgU01DIE1FRElBVE9SIiwgREVW
SUNFX0ZJUk1XQVJFKQ0KPj4+ICsgICAgICAgIC5kdF9tYXRjaCA9IHNjbWlfc21jX21hdGNoLA0K
Pj4+ICsgICAgICAgIC5pbml0ID0gc2NtaV9wcm9iZSwNCj4+PiArRFRfREVWSUNFX0VORA0KPj4+
ICsNCj4+PiArLyoNCj4+PiArICogTG9jYWwgdmFyaWFibGVzOg0KPj4+ICsgKiBtb2RlOiBDDQo+
Pj4gKyAqIGMtZmlsZS1zdHlsZTogIkJTRCINCj4+PiArICogYy1iYXNpYy1vZmZzZXQ6IDQNCj4+
PiArICogdGFiLXdpZHRoOiA0DQo+Pj4gKyAqIGluZGVudC10YWJzLW1vZGU6IG5pbA0KPj4+ICsg
KiBFbmQ6DQo+Pj4gKyAqLw0KPj4+IGRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS9wdWJsaWMvYXJj
aC1hcm0uaCBiL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLWFybS5oDQo+Pj4gaW5kZXggMDk1YjFh
MjNlMy4uMzBlNDZkZTZkNyAxMDA2NDQNCj4+PiAtLS0gYS94ZW4vaW5jbHVkZS9wdWJsaWMvYXJj
aC1hcm0uaA0KPj4+ICsrKyBiL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLWFybS5oDQo+Pj4gQEAg
LTMyOSw2ICszMjksNyBAQCBERUZJTkVfWEVOX0dVRVNUX0hBTkRMRSh2Y3B1X2d1ZXN0X2NvbnRl
eHRfdCk7DQo+Pj4NCj4+PiAjZGVmaW5lIFhFTl9ET01DVExfQ09ORklHX0FSTV9TQ0lfTk9ORSAg
ICAgIDANCj4+PiAjZGVmaW5lIFhFTl9ET01DVExfQ09ORklHX0FSTV9TQ0lfU0NNSV9TTUMgIDEN
Cj4+PiArI2RlZmluZSBYRU5fRE9NQ1RMX0NPTkZJR19BUk1fU0NJX1NDTUlfU01DX01BICAyDQo+
Pj4NCj4+PiBzdHJ1Y3QgeGVuX2FyY2hfZG9tYWluY29uZmlnIHsNCj4+PiAgICAgIC8qIElOL09V
VCAqLw0KPj4+IEBAIC0zNTUsNiArMzU2LDggQEAgc3RydWN0IHhlbl9hcmNoX2RvbWFpbmNvbmZp
ZyB7DQo+Pj4gICAgICB1aW50MzJfdCBjbG9ja19mcmVxdWVuY3k7DQo+Pj4gICAgICAvKiBJTiAq
Lw0KPj4+ICAgICAgdWludDhfdCBhcm1fc2NpX3R5cGU7DQo+Pj4gKyAgICAvKiBJTiAqLw0KPj4+
ICsgICAgdWludDhfdCBhcm1fc2NpX2FnZW50X2lkOw0KPj4+IH07DQo+Pj4gI2VuZGlmIC8qIF9f
WEVOX18gfHwgX19YRU5fVE9PTFNfXyAqLw0KPj4+DQo+Pj4gLS0NCj4+PiAyLjM0LjENCg==


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 12:10:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 12:10:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012980.1391526 (Exim 4.92)
	(envelope-from )
	id 1uPgl8-0001Yr-K5; Thu, 12 Jun 2025 12:10:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012980.1391526; Thu, 12 Jun 2025 12:10:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPgl8-0001Yk-HP; Thu, 12 Jun 2025 12:10:18 +0000
Received: by outflank-mailman (input) for mailman id 1012980;
 Thu, 12 Jun 2025 12:10: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 1uPgl7-0001Ye-I1
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 12:10:17 +0000
Received: from AS8PR03CU001.outbound.protection.outlook.com
 (mail-westeuropeazlp170120005.outbound.protection.outlook.com
 [2a01:111:f403:c201::5])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 32585ec0-4786-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 14:10:14 +0200 (CEST)
Received: from DB3PR0302MB8919.eurprd03.prod.outlook.com
 (2603:10a6:10:435::21) by DU4PR03MB10862.eurprd03.prod.outlook.com
 (2603:10a6:10:582::10) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.22; Thu, 12 Jun
 2025 12:10:12 +0000
Received: from DB3PR0302MB8919.eurprd03.prod.outlook.com
 ([fe80::ce88:43f9:c971:9584]) by DB3PR0302MB8919.eurprd03.prod.outlook.com
 ([fe80::ce88:43f9:c971:9584%5]) with mapi id 15.20.8813.024; Thu, 12 Jun 2025
 12:10: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: 32585ec0-4786-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Rnvoo1gWn1Nj0GCf3tQhaNoFsYcamMfFbNy7e5Yn5X4VmwF7RfngnxMuCy5a/tFEwR0hIm1pALhcH3ow+NzCrATkANTiLM7Lvcge8eMhNGZRUb6hR59AGFAyzYr3EQyJDiIBV6RfXfShAJZF0ZaQN2yqQWRvcDwkzclVt3eeeQtdchOVNnsvwGEjlMGmHBTfppprFy7WOQEY5QCVViLujIdWC3aEr5+KCF9YWeG4d9U0kqux1O/WCbQSi7lbbutYepV0doxc67NnuHChSE5nKurOiuu9LwYL3ZT8rRGE+Q4HF2X8zqICjwpW5eCnUJTiu0Uf9nzlk63apL9MRC2eLQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=c/idnLsDTrc+eSsdgjJwys+qc5uQ9+j6mVeD75DiODM=;
 b=sm25YjWS/Z1BMpnbWEQHAPek7vLsYwzk9KTFpO2W6fSS4vLgXoleXzXndr5h38lTjoer+836gyyUk/2Mm2Lx3GJXcJlnXegWMxBbBRAaIdxYSyj5+fiRYv7CMK49b1Om9H2KoBfqCciLBXtHuT3EL4yfSDxHta5EYUEWaI/K8SPCCOSuc3XmliNVJlDrzoN7bG8nJoNfVZb8OFRBoVCPspNuL8DUJmnZqz0bns7fHk5zRkOsZvtf/5n8MvhEPR+n1NrUjr4joNKhTxw68e0EpCv1Wd09yaQ/7UNEYI08F65d3aoK5lYTRSRkEpPMDV2CY8sHtUkGez4jAvpaN3JCOw==
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=c/idnLsDTrc+eSsdgjJwys+qc5uQ9+j6mVeD75DiODM=;
 b=fLtKfNvpMiFpNBQ/3ybwMtN/nmpT7q+VpQJV1bDiMyagwF8csSi70zZHDo4SMDf74n8llb4yFee4Gm1vyafTFWJxxW1LzqmLIbtsue/oj/PVP8xYEG8w9CTcq+Sx8BZuR4Cg18Am9mVPGNwWpZ7ivugI/CXIdaAVZ4PGjgrI4O8lIqc8hoUG7GH2qfThwEQVm8Bm91cZy18401HmUXGTlYez6P4hKzxvYdeBTK02OAR5b91eare9Fv/mL7hIwkpHzqG2epBWIHgNBqY6m79ylNUksHaRBXZ3sacYEwZSirhLTvF8zhYoiWhHwdhquNcQD6MXOGqiPk+IvXdI04rr/A==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: <50ff5d2b-bd17-4833-b497-0dda6f75964a@epam.com>
Date: Thu, 12 Jun 2025 15:10:09 +0300
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC
 multi-agent driver
To: Bertrand Marquis ,
 Stefano Stabellini 
Cc: Oleksii Moisieiev ,
 "xen-devel@lists.xenproject.org" ,
 Andrew Cooper ,
 Anthony PERARD , Jan Beulich ,
 Juergen Gross , Julien Grall ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Volodymyr Babchuk 
References: 
 <318044ae12f13b6b297b3f5fda577a1a6cd143da.1747669845.git.oleksii_moisieiev@epam.com>
 
 <04B1F737-5E6B-47C0-B2B9-74288C68E68A@arm.com>
Content-Language: en-US
From: Grygorii Strashko 
In-Reply-To: <04B1F737-5E6B-47C0-B2B9-74288C68E68A@arm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
X-ClientProxiedBy: FR4P281CA0314.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:f6::10) To DB3PR0302MB8919.eurprd03.prod.outlook.com
 (2603:10a6:10:435::21)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DB3PR0302MB8919:EE_|DU4PR03MB10862:EE_
X-MS-Office365-Filtering-Correlation-Id: a8fb91b9-ff6b-4436-7964-08dda9aa1536
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|376014|366016|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?Y3o0dzRSRjhiMGd5aHNNV2YxWFJ1NjNHN3dXNjVSR1NyQnBwUU1XakQ2MEVt?=
 =?utf-8?B?SEFsL0QyckxBd1k4dTJNTHpvN0VZaVJ3d1k0dlhxMXo3Q2lneTFmTU4zZGk5?=
 =?utf-8?B?b2daWWpLQmNaeGdvSFQyNFpYbWJ0T2dGOE9BUnNjOTJHVWI3dDRSZ0hZcWRW?=
 =?utf-8?B?UVJNNG1jVTJrRzFoTGtMaWlTNXV2dnI2Qkd5N2FobnJrNmNzd2FQNGZnV1VT?=
 =?utf-8?B?SVlLK1l2TWFNdDZTRDErWDU5RWQ0djdMVmo5S1lRaFB4cFVnYXQ3L0cvMllF?=
 =?utf-8?B?bkZPZHBXQndra3BQUjFSVDFoVTE0Um8rcUtTYnM2dk81d25uQUYwUXhuQk95?=
 =?utf-8?B?YUNna01OZS8wVnA5R1ZURzZ0ZmRLN3RSQitlRHpMNHFCUURLU2tzVGl3YVdF?=
 =?utf-8?B?L3VIZ3h6aDNLbGlTMjB1a1Fqb1J4clZ4MTJ4Snh0Ry9BWDFIQ0hSMGxzYk9Q?=
 =?utf-8?B?Mzc4c3dOTEM2MVlNeEFyaGZJblcyWkVoQmljbk5MNFJZTlU0elpkQ2g1TGlI?=
 =?utf-8?B?KzdHelcraWJaS1hVUFVSaVNyNk9CL0t4UUswMVh6ZHBnSWtLK0VHOXV6eWh5?=
 =?utf-8?B?UmpxR2xBYzVYZTRpYldkRWtNUzhqNHNjQlU0SDFuV0FhbytqNEl0MSswZTlE?=
 =?utf-8?B?NnNnRy93WHhMM1FCY3BOMUU3RThPOHdCaDQ2clJpRzZoRWxENUZYVS9SS3My?=
 =?utf-8?B?ZUMvbWZvU3FZeS84NlY4cXMwai9uUi9Rd0pjYk5GRmZxL0xzREttTS9qQ3E1?=
 =?utf-8?B?QWkvRGRiWlhvR1hwTjBLNEtBQmVpMDdPUlIvYkw2bG9haHkyUDF0NzVDSENE?=
 =?utf-8?B?NkxXMDhiYTlCQWJJUXViMFBOMEZWRm1IRy9tVHl3YTNUSUxEdnhUeXVGanBF?=
 =?utf-8?B?M3EycjFqZzBvOTRTUWpwbUpBcElLcGRwWjRaL085VC9NZUVKTFh2V2d2Nmpn?=
 =?utf-8?B?WUFFV0VGTGkvcWpXZDVLaW1TbVptdWJMa0gybCtUMEFXd3E2Nnl4TFpUblVP?=
 =?utf-8?B?eEhqemFpdnE3WHVKRTVXVmt0ZGZxT1hxaGhtemQ3LzdLUVRBbDFSd3VTZmlp?=
 =?utf-8?B?MzZ5clNERFhQcEhnMG55Wk1DbTFRaG9DbWZ3UDg1d2JlRHdiTVpqd1ZNVTAr?=
 =?utf-8?B?QVlUc3R4ZjlMUU9wVGxZZndHeWRGY28rdm80Z2w4VGYwTEpNUjltTGVObVJX?=
 =?utf-8?B?aUIzV1NWOGc3ZlZsMTUwYithZy9PclI2dzNtMWgxRWFrZzd1V3oza0phbWk2?=
 =?utf-8?B?MXo1aGtJbVhCVmFrckRBN1NEOGJrb2xHV1RGaC8zNnU1RWVETVpzbkpZaER2?=
 =?utf-8?B?OUVhcC9hLzZzS1pwZWpMRnoxbkRRVEoxV1V3TWNFZ09CVEZrb1pVTEN2Qi8w?=
 =?utf-8?B?bGZJT21TNGpwU2tJSFBaUS9PVWEzRGJNTmhreHN5NHM4cmIvb0FyVzAyUk9p?=
 =?utf-8?B?cmxKZ1gxcmdZUmJPc0c3VVQyTHR2YVloUENRLzNmNE1WZXJtajhUbEZxRHlv?=
 =?utf-8?B?NDNveDVDY3ZZZ2JmTm5tb01LSXJlVmdVbkUzZVVtbXc2MFlYVC9Od3A5cGp1?=
 =?utf-8?B?TmVhSDc2STBSV00rS1h1MmM0SXpYRUFLWHQ4KytYRXp3YlFRSlZ6cXFKQTZl?=
 =?utf-8?B?MFU0K3lUZlpsWVRKSk5Odk1ybUVVcStmbWEyYStJTSs4SDdjQ3hmT2h1b0cz?=
 =?utf-8?B?MDh1QXpNSzlYWlRGc3RzYTRGM2VEZXpycGRobTRuOHdjeU80cWg4Mmhmc2tF?=
 =?utf-8?B?NW5PNUxBNlV6ZTNPV0kxMllFZnB5MHpmc3dKS2ZMSGgvOWdkZ3NBbnh6T25I?=
 =?utf-8?B?Rm1kYnBpcDBiaXk2S2huNmdWd3J6MWk5a2pwdEJPcDROWkJnb3phV3lqUjA3?=
 =?utf-8?B?d2JzWDBsRTM5OUtUWW9kenFBUzBYS1h2Y2JqUmtSRCtuVXJtRmJmam1hMnQ5?=
 =?utf-8?Q?OY4VQx9KozE=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB3PR0302MB8919.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(366016)(1800799024);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?WUorNjZzQ0NYQXE3MGFZN3RFN1F4OE9PTmI4NHhlb0dlN3V1RDJqOFR5RXAv?=
 =?utf-8?B?Z2ErcyszMld3OUFWbFpTcU1GbEFnUmk1bWNOZmh3SHNlRlZLbzlnRW1DbHox?=
 =?utf-8?B?Z2FSQTZDOHVrZzArWS9rUWU2MnlONUN2bE1uU0dOL3czNG5mUFE5aE1FZXlJ?=
 =?utf-8?B?cWFtNUFoVnl6OTdHMWVRN1pGNmZHUVA1SkpRVHBOcE9abTZHRjYzNHhSUXhL?=
 =?utf-8?B?bVhER2s1RHVMS01kWmhtTS9za2Z1TjlDOFREUHRTTEVUVDBiQ0ttVHV4ZW93?=
 =?utf-8?B?REs2a2tBb0orQlpFNUR6bmVTZjNSYUNHSEY1MFNkUy9oOVN0QTlWak1pN2NW?=
 =?utf-8?B?MkNuSnR6RGpUVzZLT2RXbVhNK3crSTJhektrTGJUaHpiMFRkdFNkTG52SERa?=
 =?utf-8?B?VFM5Ykc0UWtXMVZuWHdZMHpLcWZLSkpWcFRHaFY1Y2dXSnUwdElhd24xWWdX?=
 =?utf-8?B?c2lFWm5oVGRNaDQ1V3dzTlNwNGc2WXRSbGdMREtSemIwbXNUemVwdU5UMUxI?=
 =?utf-8?B?YStKdlpLa0JVWlBIdTZWWG9QcmMxb2FvWkZrbWxsOHEwa3ZUdTdmQy9LVERx?=
 =?utf-8?B?ZzVkMS9nTVFJdGJWNHJxdHMyN2dYZmNOOXNFNXRKOEZTb1JmNTJ3Yzc3MWFH?=
 =?utf-8?B?ODI0UnRtRWEzWXlaUHFTajloSDZERWl5YzVPRXJubWpPWnVIeFhSN2V5OWxu?=
 =?utf-8?B?M2JyOHlzQWR0QXBqV2UzRjlNZkh2VktEK0JOMnhWODNLRGswb29xcWZ4Tmxr?=
 =?utf-8?B?YmFuSlJRRzd2U1NxV0hpVkt5bjliWWtSdFdmLzNXclJZL0J6QWlIZ2ZkZkFl?=
 =?utf-8?B?dlVNUDZ1eVI3MHA1RkF6MUk5aENJeDJlMmdNSmJUTjFvMUo5dHI4MGlRVDdI?=
 =?utf-8?B?NWxWOFp5QzlUQzhLeS9rVGVnNVVTVGZLVHhJU2ZmdFVDQVRaUTlTQnJRSjJX?=
 =?utf-8?B?QkRpUnBubWVoSGdadXFPRW80Mm9SZlFkcXNYU2RFOFByS1hLaEJvU0owU3B2?=
 =?utf-8?B?WjBGNUxDNGcrNlNWOTVFeUJ3UU44TUEzWTc5bjhHYlRzOUJwdERKMzdoYVZP?=
 =?utf-8?B?RmJOamoxSXM4NGErbWFzUHo5eTUzemtEd0ppUmtFQ0VHTTBkZ2Y5MFEweUxi?=
 =?utf-8?B?UDNHKzFid3BKODBDS1ZrVUUzTjJBVXlpakx6VG1Jd0lPd3VIK1VxMEFBUkI5?=
 =?utf-8?B?RmR3VEFUVU9xMU1IaG0wK3hCUFpoS3VuVGZza01xN0tJTDl5S0pxcW5VTmJF?=
 =?utf-8?B?emZWYjc2SjZ6bXNhbTg1bi9CTkZlcGtRZXc3dGkvN05yMXFIMzRPbFZ5SEhN?=
 =?utf-8?B?dkJ1c2ZxT1JoTW0vbEp3N1d4UG9MVDU3d1dmYXlQZzU5TTU1NG1tZEk3TW5Z?=
 =?utf-8?B?OGdDV0d0MzR1NVlONmRQNEJTSkZXNEtwb3JWa2x6R0Q3b21OcDZ4cjg1RURC?=
 =?utf-8?B?UlRicEIyNUNRWVJWWFhHVDAvUGNCalIrMjZRbjRyU2pjNWNtRlFGeWozSEhZ?=
 =?utf-8?B?Uzh5K25XUVhvMmczY2FxZVEydm9kQm9RQ0hMTm85TmFvOEIwK0RTSmx3Vis1?=
 =?utf-8?B?UUZIdWxKOXZQK2h4QTdwWmZyR3JnVHB0VlpHRFFCclppeFIxSENWTlNFWWhI?=
 =?utf-8?B?b1hPT050SjZIYUE5QUg2YTVQZkdUdmVzeHUyK2l1ZU95VGJUT1VERHVBVFVh?=
 =?utf-8?B?SVluNGc5cUFFMjc4UENqYXB2eFJqdnUwZ2luNEJDVEFoa1VTTmt0ZlNidkVj?=
 =?utf-8?B?T2paNkR5N1RWaVZ6QnlReCtTNzQ4YjlSenZiWmJHcEtyQm1uUFFuQ0lqTVEx?=
 =?utf-8?B?d0lnWW1lOHp3ZTRiOUdtMGp5cHA1QWlUMGd2dmM5VXhhc2g2VHFyOGF1aXBh?=
 =?utf-8?B?WHJSYmg5cEU5bTY0Q0hvbi8yd1NBTVJZWHVLL1NIMmh1Nmk2bWF5SXcySEts?=
 =?utf-8?B?N1IxNWFQRWNiUXJGZW9vdDc4blpkMFRCOVVlc3R6MEd0N29JQzArQjdFdnpV?=
 =?utf-8?B?VkZHSFhvU05rbUVzajIvclBFaisvV2pqRFlvZHNJcFpvcnVJYzVXeko5NzVu?=
 =?utf-8?B?a2xvaDQ4WWhLaVJJWEgwcjZPWkllekF3VktpRlBQdXl2WkE3Y05zTXk1L1dj?=
 =?utf-8?B?QkRtN1JhYWNmUEdQMGt0NzV2bEt1eno2SUE1S2l5TDU1Mk9SMStYTW96M1BS?=
 =?utf-8?B?a2c9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a8fb91b9-ff6b-4436-7964-08dda9aa1536
X-MS-Exchange-CrossTenant-AuthSource: DB3PR0302MB8919.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2025 12:10:12.3454
 (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: 8Wp5BHPqwrhA3Bb1q0YVZdO+QkfrvsJ9xI85GvHnLqgrAVgf9pXuSL4l0FcdRY5/O+mGvgAsvgaJRgUKg1/FBdJzpWhCIOV5dgR5kJgc4WU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU4PR03MB10862



On 02.06.25 10:17, Bertrand Marquis wrote:
> Hi Stefano and Oleksii,
> 
>> On 23 May 2025, at 22:06, Stefano Stabellini  wrote:
>>
>> One question for Bertrand below
>>
>>
>> On Mon, 19 May 2025, Oleksii Moisieiev wrote:
>>> This patch introduces SCI driver to support for ARM EL3 Trusted Firmware-A
>>> (TF-A) which provides SCMI interface with multi-agnet support, as shown
>>> below.
>>>
>>>   +-----------------------------------------+
>>>   |                                         |
>>>   | EL3 TF-A SCMI                           |
>>>   +-------+--+-------+--+-------+--+-------++
>>>   |shmem0 |  |shmem1 |  |shmem2 |  |shmemX |
>>>   +-----+-+  +---+---+  +--+----+  +---+---+
>>> smc-id0 |        |         |           |
>>> agent0  |        |         |           |
>>>   +-----v--------+---------+-----------+----+
>>>   |              |         |           |    |
>>>   |              |         |           |    |
>>>   +--------------+---------+-----------+----+
>>>          smc-id1 |  smc-id2|    smc-idX|
>>>          agent1  |  agent2 |    agentX |
>>>                  |         |           |
>>>             +----v---+  +--v-----+  +--v-----+
>>>             |        |  |        |  |        |
>>>             | Dom0   |  | Dom1   |  | DomX   |
>>>             |        |  |        |  |        |
>>>             |        |  |        |  |        |
>>>             +--------+  +--------+  +--------+
>>>
>>> The EL3 SCMI multi-agent firmware expected to provide SCMI SMC/HVC shared
>>> memory transport for every Agent in the system.
>>>
>>> The SCMI Agent transport channel defined by pair:
>>> - smc-id: SMC/HVC id used for Doorbell
>>> - shmem: shared memory for messages transfer, Xen page aligned,
>>> p2m_mmio_direct_nc.
>>>
>>> The follwoing SCMI Agents expected to be defined by SCMI FW to enable SCMI
>>> multi-agent functionality under Xen:
>>> - Xen manegement agent: trusted agents that accesses to the Base Protocol
>>> commands to configure agent specific permissions
>>> - OSPM VM agents: non-trusted agent, one for each Guest domain which is
>>>   allowed direct HW access. At least one OSPM VM agent has to be provided
>>>   by FW if HW is handled only by Dom0 or Driver Domain.
>>>
>>> The EL3 SCMI FW expected to implement following Base protocol messages:
>>> - BASE_DISCOVER_AGENT
>>> - BASE_RESET_AGENT_CONFIGURATION (optional)
>>> - BASE_SET_DEVICE_PERMISSIONS (optional)
>>>
>>> The SCI SCMI SMC multi-agent driver implements following functionality:
>>> - It's initialized based on the Host DT SCMI node (only one SCMI interface
>>> is supported) which describes Xen management agent SCMI interface.
>>>
>>> scmi_shm_0 : sram@47ff0000 {
>>>     compatible = "arm,scmi-shmem";
>>>     reg = <0x0 0x47ff0000 0x0 0x1000>;
>>> };
>>> firmware {
>>>     scmi: scmi {
>>>         compatible = "arm,scmi-smc";
>>>         arm, smc - id = <0x82000002>; // Xen manegement agent smc-id
>>
>> some extra spaces, it might be a copy/paste error
>>
>>
>>>         \#address-cells = < 1>;
>>>         \#size-cells = < 0>;
>>>         \#access-controller - cells = < 1>;
>>>         shmem = <&scmi_shm_0>; // Xen manegement agent shmem
>>>
>>>         protocol@X{
>>>         };
>>>     };
>>> };
>>>
>>> - It obtains Xen specific SCMI Agent's configuration from the Host DT,
>>> probes Agents and build SCMI Agents list; The Agents configuration is taken from:
>>>
>>> chosen {
>>>   xen,scmi-secondary-agents = <
>>> 1 0x82000003 &scmi_shm_1
>>> 2 0x82000004 &scmi_shm_2
>>> 3 0x82000005 &scmi_shm_3
>>> 4 0x82000006 &scmi_shm_4>;
>>> }
>>>
>>> /{
>>> scmi_shm_1: sram@47ff1000 {
>>> compatible = "arm,scmi-shmem";
>>> reg = <0x0 0x47ff1000 0x0 0x1000>;
>>> };
>>> scmi_shm_2: sram@47ff2000 {
>>> compatible = "arm,scmi-shmem";
>>> reg = <0x0 0x47ff2000 0x0 0x1000>;
>>> };
>>> scmi_shm_3: sram@47ff3000 {
>>> compatible = "arm,scmi-shmem";
>>> reg = <0x0 0x47ff3000 0x0 0x1000>;
>>> };
>>> }
>>>   where first item is "agent_id", second - "arm,smc-id", and third - "arm,scmi-shmem" for
>>>   this agent_id.
>>>
>>>   Note that Xen is the only one entry in the system which need to know
>>>   about SCMI multi-agent support.
>>>
>>> - It implements the SCI subsystem interface required for configuring and
>>> enabling SCMI functionality for Dom0/hwdom and Guest domains. To enable
>>> SCMI functionality for domain it has to be configured with unique supported
>>> SCMI Agent_id and use corresponding SCMI SMC/HVC shared memory transport
>>> [smc-id, shmem] defined for this SCMI Agent_id.
>>> - Once Xen domain is configured it can communicate with EL3 SCMI FW:
>>>   -- zero-copy, the guest domain puts SCMI message in shmem;
>>>   -- the guest triggers SMC/HVC exception with smc-id (doorbell);
>>>   -- the Xen driver catches exception, do checks and synchronously forwards
>>>   it to EL3 FW.
>>> - the Xen driver sends BASE_RESET_AGENT_CONFIGURATION message to Xen
>>>   management agent channel on domain destroy event. This allows to reset
>>>   resources used by domain and so implement use-case like domain reboot.
>>>
>>> Dom0 Enable SCMI SMC:
>>> - pass dom0_scmi_agent_id= in Xen command line. if not provided
>>>    SCMI will be disabled for Dom0 and all SCMI nodes removed from Dom0 DT.
>>>    The driver updates Dom0 DT SCMI node "arm,smc-id" value and fix up shmem
>>>    node according to assigned agent_id.
>>>
>>> Guest domains enable SCMI SMC:
>>> - xl.cfg: add configuration option as below
>>>
>>>    arm_sci = "type=scmi_smc_multiagent,agent_id=2"
>>>
>>> - xl.cfg: enable access to the "arm,scmi-shmem" which should correspond assigned agent_id for
>>>    the domain, for example:
>>>
>>> iomem = [
>>>     "47ff2,1@22001",
>>> ]
>>
>> Looking at the code and the configuration options, it looks like it is
>> possible to map a scmi-shmem channel at a different address for the
>> guest. It seems like it would work. Is that correct?
>>
>>
>>> - DT: add SCMI nodes to the Driver domain partial device tree as in the
>>> below example. The "arm,smc-id" should correspond assigned agent_id for the domain:
>>>
>>> passthrough {
>>>    scmi_shm_0: sram@22001000 {
>>>        compatible = "arm,scmi-shmem";
>>>        reg = <0x0 0x22001000 0x0 0x1000>;
>>>    };
>>>
>>>    firmware {
>>>         compatible = "simple-bus";
>>>             scmi: scmi {
>>>                 compatible = "arm,scmi-smc";
>>>                 arm,smc-id = <0x82000004>;
>>>                 shmem = <&scmi_shm_0>;
>>>                 ...
>>>             }
>>>     }
>>> }
>>>
>>> SCMI "4.2.1.1 Device specific access control"
>>>
>>> The XEN SCI SCMI SMC multi-agent driver performs "access-controller" provider function
>>> in case EL3 SCMI FW implements SCMI "4.2.1.1 Device specific access control" and provides the
>>> BASE_SET_DEVICE_PERMISSIONS command to configure the devices that an agents have access to.
>>> The DT SCMI node should "#access-controller-cells=<1>" property and DT devices should be bound
>>> to the Xen SCMI.
>>>
>>> &i2c1 {
>>> access-controllers = <&scmi 0>;
>>> };
>>>
>>> The Dom0 and dom0less domains DT devices will be processed automatically through
>>> sci_assign_dt_device() call, but to assign SCMI devices from toolstack the xl.cfg:"dtdev" property
>>> shell be used:
>>>
>>> dtdev = [
>>>     "/soc/i2c@e6508000",
>>> ]
>>>
>>> xl.cfg:dtdev will contain all nodes which are under SCMI management (not only those which are behind IOMMU).
>>>
>>> [1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
>>> [2] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/access-controllers/access-controllers.yaml
>>> Signed-off-by: Oleksii Moisieiev 
>>> Signed-off-by: Grygorii Strashko 
>>
>> Thanks for the long explanation, great work! I am really looking forward
>> to have this feature in the tree soon.
>>
>>
>>> ---
>>>
>>> Changes in v4:
>>> - toolstack comments from Anthony PERARD
>>> - added dom0less support
>>> - added doc for "xen,scmi-secondary-agents"
>>>
>>> docs/man/xl.cfg.5.pod.in                    |  13 +
>>> docs/misc/arm/device-tree/booting.txt       |  60 ++
>>> docs/misc/xen-command-line.pandoc           |   9 +
>>> tools/libs/light/libxl_arm.c                |   4 +
>>> tools/libs/light/libxl_types.idl            |   4 +-
>>> tools/xl/xl_parse.c                         |  12 +
>>> xen/arch/arm/dom0less-build.c               |  11 +
>>> xen/arch/arm/domain_build.c                 |   3 +-
>>> xen/arch/arm/firmware/Kconfig               |  11 +
>>> xen/arch/arm/firmware/Makefile              |   1 +
>>> xen/arch/arm/firmware/scmi-proto.h          | 164 ++++
>>> xen/arch/arm/firmware/scmi-shmem.c          | 173 ++++
>>> xen/arch/arm/firmware/scmi-shmem.h          |  45 +
>>> xen/arch/arm/firmware/scmi-smc-multiagent.c | 860 ++++++++++++++++++++
>>> xen/include/public/arch-arm.h               |   3 +
>>> 15 files changed, 1371 insertions(+), 2 deletions(-)
>>> create mode 100644 xen/arch/arm/firmware/scmi-proto.h
>>> create mode 100644 xen/arch/arm/firmware/scmi-shmem.c
>>> create mode 100644 xen/arch/arm/firmware/scmi-shmem.h
>>> create mode 100644 xen/arch/arm/firmware/scmi-smc-multiagent.c
>>>
>>> diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
>>> index 1ccf50b8ea..302c46d8bc 100644
>>> --- a/docs/man/xl.cfg.5.pod.in
>>> +++ b/docs/man/xl.cfg.5.pod.in
>>> @@ -3122,8 +3122,21 @@ single SCMI OSPM agent support.
>>> Should be used together with B Xen command line
>>> option.
>>>
>>> +=item B
>>> +
>>> +Enables ARM SCMI SMC multi-agent support for the guest by enabling SCMI over
>>> +SMC calls forwarding from domain to the EL3 firmware (like Trusted Firmware-A)
>>> +with a multi SCMI OSPM agent support. The SCMI B should be
>>> +specified for the guest.
>>> +
>>> =back
>>>
>>> +=item B
>>> +
>>> +Specifies a non-zero ARM SCI agent id for the guest. This option is mandatory
>>> +if the SCMI SMC support is enabled for the guest. The agent ids of domains
>>> +existing on a single host must be unique and in the range [1..255].
>>> +
>>> =back
>>>
>>> =back
>>> diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
>>> index 8943c04173..c8923ab8b2 100644
>>> --- a/docs/misc/arm/device-tree/booting.txt
>>> +++ b/docs/misc/arm/device-tree/booting.txt
>>> @@ -296,6 +296,20 @@ with the following properties:
>>>      Should be used together with dom0_scmi_smc_passthrough Xen command line
>>>      option.
>>>
>>> +    - "scmi_smc_multiagent"
>>> +
>>> +    Enables ARM SCMI SMC multi-agent support for the guest by enabling SCMI over
>>> +    SMC calls forwarding from domain to the EL3 firmware (like ARM
>>> +    Trusted Firmware-A) with a multi SCMI OSPM agent support.
>>> +    The SCMI agent_id should be specified for the guest with "xen,sci_agent_id"
>>> +    property.
>>> +
>>> +- "xen,sci_agent_id"
>>> +
>>> +    Specifies a non-zero ARM SCI agent id for the guest. This option is
>>> +    mandatory if the SCMI SMC "scmi_smc_multiagent" support is enabled for
>>> +    the guest. The agent ids of guest must be unique and in the range [1..255].
>>> +
>>> Under the "xen,domain" compatible node, one or more sub-nodes are present
>>> for the DomU kernel and ramdisk.
>>>
>>> @@ -764,3 +778,49 @@ The automatically allocated static shared memory will get mapped at
>>> 0x80000000 in DomU1 guest physical address space, and at 0x90000000 in DomU2
>>> guest physical address space. DomU1 is explicitly defined as the owner domain,
>>> and DomU2 is the borrower domain.
>>> +
>>> +SCMI SMC multi-agent support
>>> +============================
>>> +
>>> +For enabling the ARM SCMI SMC multi-agent support (enabled by CONFIG_SCMI_SMC_MA)
>>> +the Xen specific SCMI Agent's configuration shell be provided in the Host DT
>>> +according to the SCMI compliant EL3 Firmware specification with
>>> +ARM SMC/HVC transport using property "xen,scmi-secondary-agents" under
>>> +the top-level "chosen" node:
>>> +
>>> +- xen,scmi-secondary-agents
>>> +
>>> +    Defines a set of SCMI agents configuration supported by SCMI EL3 FW and
>>> +    available for Xen. Each Agent defined as triple consisting of:
>>> +    SCMI agent_id,
>>> +    SMC/HVC function_id assigned for the agent transport ("arm,smc-id"),
>>> +    phandle to SCMI SHM assigned for the agent transport ("arm,scmi-shmem").
>>> +
>>> +As an example:
>>> +
>>> +chosen {
>>> +    xen,scmi-secondary-agents = <
>>> +        1 0x82000003 &scmi_shm_1
>>> +        2 0x82000004 &scmi_shm_2
>>> +        3 0x82000005 &scmi_shm_3
>>> +        4 0x82000006 &scmi_shm_4>;
>>> +}
>>
>> NIT: it should be };
>>
>> Looking at scmi_probe, collect_agents, and the following SCMI
>> SCMI_BASE_DISCOVER_AGENT request, I wonder: do we actually need this
>> information?
>>
>> It looks like we can discover the agend_ids for every channel, I guess
>> what we need to know is the shmem location for every channel? But the
>> full list of shmem channel is available below thanks to the scmi-shmem
>> nodes.
>>
>> So, we have the list of scmi-shmem anyway, and we can probe the
>> agent_id. The only parameter left is the smc_id/func_id.
>>
>> Or maybe smc_id/func_id can be calculated from agent_id?
>>
>> I am asking mostly because if a user is supposed to add this
>> xen,scmi-secondary-agents property, where are they supposed to find the
>> smc_id/func_id information?
>>
>> It is important that we write down in this document how the user is
>> expected to find out what 1 is 0x82000003 which is scmi_shm_1.
>>
>>
>>> +/{
>>> +        scmi_shm_1: sram@47ff1000 {
>>> +                compatible = "arm,scmi-shmem";
>>> +                reg = <0x0 0x47ff1000 0x0 0x1000>;
>>> +        };
>>> +        scmi_shm_2: sram@47ff2000 {
>>> +                compatible = "arm,scmi-shmem";
>>> +                reg = <0x0 0x47ff2000 0x0 0x1000>;
>>> +        };
>>> +        scmi_shm_3: sram@47ff3000 {
>>> +                compatible = "arm,scmi-shmem";
>>> +                reg = <0x0 0x47ff3000 0x0 0x1000>;
>>> +        };
>>> +        scmi_shm_3: sram@47ff4000 {
>>> +                compatible = "arm,scmi-shmem";
>>> +                reg = <0x0 0x47ff4000 0x0 0x1000>;
>>> +        };
>>
>> Are these scmi_shm_1 - scmi_shm_3 under the top level device tree node?
>> Or are under /firmware? Or are they under /chosen?
>>
>> I take they are under the top level node together with scmi_shm_0?
>>
>> Can you please also clarify in the document as well?
>>
>>
>>> +}
>>> diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
>>> index 8e50f6b7c7..bc3c64d6ec 100644
>>> --- a/docs/misc/xen-command-line.pandoc
>>> +++ b/docs/misc/xen-command-line.pandoc
>>> @@ -1091,6 +1091,15 @@ which serves as Driver domain. The SCMI will be disabled for Dom0/hwdom and
>>> SCMI nodes removed from Dom0/hwdom device tree.
>>> (for example, thin Dom0 with Driver domain use-case).
>>>
>>> +### dom0_scmi_agent_id (ARM)
>>> +> `= `
>>> +
>>> +The option is available when `CONFIG_SCMI_SMC_MA` is compiled in, and allows to
>>> +enable SCMI functionality for Dom0 by specifying a non-zero ARM SCMI agent id.
>>> +The SCMI will be disabled for Dom0 if this option is not specified
>>> +(for example, thin Dom0 or dom0less use-cases).
>>> +The agent ids of domains existing on a single host must be unique.
>>> +
>>> ### dtuart (ARM)
>>>> `= path [:options]`
>>>
>>> diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
>>> index 28ba9eb787..7712f53cd4 100644
>>> --- a/tools/libs/light/libxl_arm.c
>>> +++ b/tools/libs/light/libxl_arm.c
>>> @@ -229,6 +229,10 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
>>>      case LIBXL_ARM_SCI_TYPE_SCMI_SMC:
>>>          config->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC;
>>>          break;
>>> +    case LIBXL_ARM_SCI_TYPE_SCMI_SMC_MULTIAGENT:
>>> +        config->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA;
>>> +        config->arch.arm_sci_agent_id = d_config->b_info.arch_arm.arm_sci.agent_id;
>>> +        break;
>>>      default:
>>>          LOG(ERROR, "Unknown ARM_SCI type %d",
>>>              d_config->b_info.arch_arm.arm_sci.type);
>>> diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl
>>> index aa2190ab5b..11e31ce786 100644
>>> --- a/tools/libs/light/libxl_types.idl
>>> +++ b/tools/libs/light/libxl_types.idl
>>> @@ -553,11 +553,13 @@ libxl_sve_type = Enumeration("sve_type", [
>>>
>>> libxl_arm_sci_type = Enumeration("arm_sci_type", [
>>>      (0, "none"),
>>> -    (1, "scmi_smc")
>>> +    (1, "scmi_smc"),
>>> +    (2, "scmi_smc_multiagent")
>>>      ], init_val = "LIBXL_ARM_SCI_TYPE_NONE")
>>>
>>> libxl_arm_sci = Struct("arm_sci", [
>>>      ("type", libxl_arm_sci_type),
>>> +    ("agent_id", uint8)
>>>      ])
>>>
>>> libxl_rdm_reserve = Struct("rdm_reserve", [
>>> diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
>>> index bd22be9d33..81aa3797e3 100644
>>> --- a/tools/xl/xl_parse.c
>>> +++ b/tools/xl/xl_parse.c
>>> @@ -1306,6 +1306,18 @@ static int parse_arm_sci_config(XLU_Config *cfg, libxl_arm_sci *arm_sci,
>>>              }
>>>          }
>>>
>>> +        if (MATCH_OPTION("agent_id", ptr, oparg)) {
>>> +            unsigned long val = parse_ulong(oparg);
>>> +
>>> +            if (!val || val > 255) {
>>> +                fprintf(stderr, "An invalid ARM_SCI agent_id specified (%lu). Valid range [1..255]\n",
>>> +                        val);
>>> +                ret = ERROR_INVAL;
>>> +                goto parse_error;
>>> +            }
>>> +            arm_sci->agent_id = val;
>>> +        }
>>> +
>>>          ptr = strtok(NULL, ",");
>>>      }
>>>
>>> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
>>> index 0a00f03a25..43d21eb889 100644
>>> --- a/xen/arch/arm/dom0less-build.c
>>> +++ b/xen/arch/arm/dom0less-build.c
>>> @@ -835,6 +835,17 @@ int __init domu_dt_sci_parse(struct dt_device_node *node,
>>>          d_cfg->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_NONE;
>>>      else if ( !strcmp(sci_type, "scmi_smc") )
>>>          d_cfg->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC;
>>> +    else if ( !strcmp(sci_type, "scmi_smc_multiagent") )
>>> +    {
>>> +        uint32_t agent_id = 0;
>>> +
>>> +        if ( !dt_property_read_u32(node, "xen,sci_agent_id", &agent_id) ||
>>> +             !agent_id )
>>
>> shouldn't we check that agent_id <= 255 ?
>>
>>
>>> +            return -EINVAL;
>>> +
>>> +        d_cfg->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA;
>>> +        d_cfg->arch.arm_sci_agent_id = agent_id;
>>> +    }
>>>      else
>>>      {
>>>          printk(XENLOG_ERR "xen,sci_type in not valid (%s) for domain %s\n",
>>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>>> index 36d28b52a4..0c9274a2b3 100644
>>> --- a/xen/arch/arm/domain_build.c
>>> +++ b/xen/arch/arm/domain_build.c
>>> @@ -616,7 +616,8 @@ static int __init write_properties(struct domain *d, struct kernel_info *kinfo,
>>>                   dt_property_name_is_equal(prop, "linux,uefi-mmap-start") ||
>>>                   dt_property_name_is_equal(prop, "linux,uefi-mmap-size") ||
>>>                   dt_property_name_is_equal(prop, "linux,uefi-mmap-desc-size") ||
>>> -                 dt_property_name_is_equal(prop, "linux,uefi-mmap-desc-ver"))
>>> +                 dt_property_name_is_equal(prop, "linux,uefi-mmap-desc-ver") ||
>>> +                 dt_property_name_is_equal(prop, "xen,scmi-secondary-agents") )
>>>                  continue;
>>>
>>>              if ( dt_property_name_is_equal(prop, "xen,dom0-bootargs") )
>>> diff --git a/xen/arch/arm/firmware/Kconfig b/xen/arch/arm/firmware/Kconfig
>>> index 5c5f0880c4..6b051c8ada 100644
>>> --- a/xen/arch/arm/firmware/Kconfig
>>> +++ b/xen/arch/arm/firmware/Kconfig
>>> @@ -29,6 +29,17 @@ config SCMI_SMC
>>>    driver domain.
>>>    Use with EL3 firmware which supports only single SCMI OSPM agent.
>>>
>>> +config SCMI_SMC_MA
>>> + bool "Enable ARM SCMI SMC multi-agent driver"
>>> + select ARM_SCI
>>> + help
>>> +   Enables SCMI SMC/HVC multi-agent in XEN to pass SCMI requests from Domains
>>> +   to EL3 firmware (TF-A) which supports multi-agent feature.
>>> +   This feature allows to enable SCMI per Domain using unique SCMI agent_id,
>>> +   so Domain is identified by EL3 firmware as an SCMI Agent and can access
>>> +   allowed platform resources through dedicated SMC/HVC Shared memory based
>>> +   transport.
>>> +
>>> endchoice
>>>
>>> endmenu
>>> diff --git a/xen/arch/arm/firmware/Makefile b/xen/arch/arm/firmware/Makefile
>>> index 71bdefc24a..37927e690e 100644
>>> --- a/xen/arch/arm/firmware/Makefile
>>> +++ b/xen/arch/arm/firmware/Makefile
>>> @@ -1,2 +1,3 @@
>>> obj-$(CONFIG_ARM_SCI) += sci.o
>>> obj-$(CONFIG_SCMI_SMC) += scmi-smc.o
>>> +obj-$(CONFIG_SCMI_SMC_MA) += scmi-shmem.o scmi-smc-multiagent.o
>>> diff --git a/xen/arch/arm/firmware/scmi-proto.h b/xen/arch/arm/firmware/scmi-proto.h
>>> new file mode 100644
>>> index 0000000000..3f4b9c5d6b
>>> --- /dev/null
>>> +++ b/xen/arch/arm/firmware/scmi-proto.h
>>> @@ -0,0 +1,164 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>> +/*
>>> + * Arm System Control and Management Interface definitions
>>> + * Version 3.0 (DEN0056C)
>>> + *
>>> + * Copyright (c) 2024 EPAM Systems
>>> + */
>>> +
>>> +#ifndef XEN_ARCH_ARM_SCI_SCMI_PROTO_H_
>>> +#define XEN_ARCH_ARM_SCI_SCMI_PROTO_H_
>>
>> NIT: ARM_FIRMWARE_SCMI_PROTO_H
>>
>>
>>> +#include 
>>> +
>>> +#define SCMI_SHORT_NAME_MAX_SIZE 16
>>> +
>>> +/* SCMI status codes. See section 4.1.4 */
>>> +#define SCMI_SUCCESS              0
>>> +#define SCMI_NOT_SUPPORTED      (-1)
>>> +#define SCMI_INVALID_PARAMETERS (-2)
>>> +#define SCMI_DENIED             (-3)
>>> +#define SCMI_NOT_FOUND          (-4)
>>> +#define SCMI_OUT_OF_RANGE       (-5)
>>> +#define SCMI_BUSY               (-6)
>>> +#define SCMI_COMMS_ERROR        (-7)
>>> +#define SCMI_GENERIC_ERROR      (-8)
>>> +#define SCMI_HARDWARE_ERROR     (-9)
>>> +#define SCMI_PROTOCOL_ERROR     (-10)
>>> +
>>> +/* Protocol IDs */
>>> +#define SCMI_BASE_PROTOCOL 0x10
>>> +
>>> +/* Base protocol message IDs */
>>> +#define SCMI_BASE_PROTOCOL_VERSION            0x0
>>> +#define SCMI_BASE_PROTOCOL_ATTIBUTES          0x1
>>> +#define SCMI_BASE_PROTOCOL_MESSAGE_ATTRIBUTES 0x2
>>> +#define SCMI_BASE_DISCOVER_AGENT              0x7
>>> +#define SCMI_BASE_SET_DEVICE_PERMISSIONS      0x9
>>> +#define SCMI_BASE_RESET_AGENT_CONFIGURATION   0xB
>>> +
>>> +typedef struct scmi_msg_header {
>>> +    uint8_t id;
>>> +    uint8_t type;
>>> +    uint8_t protocol;
>>> +    uint32_t status;
>>> +} scmi_msg_header_t;
>>> +
>>> +/* Table 2 Message header format */
>>> +#define SCMI_HDR_ID    GENMASK(7, 0)
>>> +#define SCMI_HDR_TYPE  GENMASK(9, 8)
>>> +#define SCMI_HDR_PROTO GENMASK(17, 10)
>>> +
>>> +#define SCMI_FIELD_GET(_mask, _reg)                                            \
>>> +    ((typeof(_mask))(((_reg) & (_mask)) >> (ffs64(_mask) - 1)))
>>> +#define SCMI_FIELD_PREP(_mask, _val)                                           \
>>> +    (((typeof(_mask))(_val) << (ffs64(_mask) - 1)) & (_mask))
>>> +
>>> +static inline uint32_t pack_scmi_header(scmi_msg_header_t *hdr)
>>> +{
>>> +    return SCMI_FIELD_PREP(SCMI_HDR_ID, hdr->id) |
>>> +           SCMI_FIELD_PREP(SCMI_HDR_TYPE, hdr->type) |
>>> +           SCMI_FIELD_PREP(SCMI_HDR_PROTO, hdr->protocol);
>>> +}
>>> +
>>> +static inline void unpack_scmi_header(uint32_t msg_hdr, scmi_msg_header_t *hdr)
>>> +{
>>> +    hdr->id = SCMI_FIELD_GET(SCMI_HDR_ID, msg_hdr);
>>> +    hdr->type = SCMI_FIELD_GET(SCMI_HDR_TYPE, msg_hdr);
>>> +    hdr->protocol = SCMI_FIELD_GET(SCMI_HDR_PROTO, msg_hdr);
>>> +}
>>> +
>>> +static inline int scmi_to_xen_errno(int scmi_status)
>>> +{
>>> +    if ( scmi_status == SCMI_SUCCESS )
>>> +        return 0;
>>> +
>>> +    switch ( scmi_status )
>>> +    {
>>> +    case SCMI_NOT_SUPPORTED:
>>> +        return -EOPNOTSUPP;
>>> +    case SCMI_INVALID_PARAMETERS:
>>> +        return -EINVAL;
>>> +    case SCMI_DENIED:
>>> +        return -EACCES;
>>> +    case SCMI_NOT_FOUND:
>>> +        return -ENOENT;
>>> +    case SCMI_OUT_OF_RANGE:
>>> +        return -ERANGE;
>>> +    case SCMI_BUSY:
>>> +        return -EBUSY;
>>> +    case SCMI_COMMS_ERROR:
>>> +        return -ENOTCONN;
>>> +    case SCMI_GENERIC_ERROR:
>>> +        return -EIO;
>>> +    case SCMI_HARDWARE_ERROR:
>>> +        return -ENXIO;
>>> +    case SCMI_PROTOCOL_ERROR:
>>> +        return -EBADMSG;
>>> +    default:
>>> +        return -EINVAL;
>>> +    }
>>> +}
>>> +
>>> +/* PROTOCOL_VERSION */
>>> +#define SCMI_VERSION_MINOR GENMASK(15, 0)
>>> +#define SCMI_VERSION_MAJOR GENMASK(31, 16)
>>> +
>>> +struct scmi_msg_prot_version_p2a {
>>> +    uint32_t version;
>>> +} __packed;
>>> +
>>> +/* BASE PROTOCOL_ATTRIBUTES */
>>> +#define SCMI_BASE_ATTR_NUM_PROTO GENMASK(7, 0)
>>> +#define SCMI_BASE_ATTR_NUM_AGENT GENMASK(15, 8)
>>> +
>>> +struct scmi_msg_base_attributes_p2a {
>>> +    uint32_t attributes;
>>> +} __packed;
>>> +
>>> +/*
>>> + * BASE_DISCOVER_AGENT
>>> + */
>>> +#define SCMI_BASE_AGENT_ID_OWN 0xFFFFFFFF
>>> +
>>> +struct scmi_msg_base_discover_agent_a2p {
>>> +    uint32_t agent_id;
>>> +} __packed;
>>> +
>>> +struct scmi_msg_base_discover_agent_p2a {
>>> +    uint32_t agent_id;
>>> +    char name[SCMI_SHORT_NAME_MAX_SIZE];
>>> +} __packed;
>>> +
>>> +/*
>>> + * BASE_SET_DEVICE_PERMISSIONS
>>> + */
>>> +#define SCMI_BASE_DEVICE_ACCESS_ALLOW           BIT(0, UL)
>>> +
>>> +struct scmi_msg_base_set_device_permissions_a2p {
>>> +    uint32_t agent_id;
>>> +    uint32_t device_id;
>>> +    uint32_t flags;
>>> +} __packed;
>>> +
>>> +/*
>>> + * BASE_RESET_AGENT_CONFIGURATION
>>> + */
>>> +#define SCMI_BASE_AGENT_PERMISSIONS_RESET       BIT(0, UL)
>>> +
>>> +struct scmi_msg_base_reset_agent_cfg_a2p {
>>> +    uint32_t agent_id;
>>> +    uint32_t flags;
>>> +} __packed;
>>> +
>>> +#endif /* XEN_ARCH_ARM_SCI_SCMI_PROTO_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/arch/arm/firmware/scmi-shmem.c b/xen/arch/arm/firmware/scmi-shmem.c
>>> new file mode 100644
>>> index 0000000000..dd613ee0b5
>>> --- /dev/null
>>> +++ b/xen/arch/arm/firmware/scmi-shmem.c
>>> @@ -0,0 +1,173 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>> +/*
>>> + * SCI SCMI multi-agent driver, using SMC/HVC shmem as transport.
>>> + *
>>> + * Oleksii Moisieiev 
>>> + * Copyright (c) 2025 EPAM Systems
>>> + */
>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>> +
>>> +#include 
>>> +#include 
>>> +
>>> +#include "scmi-proto.h"
>>> +#include "scmi-shmem.h"
>>
>> This code is written more generically than the description implies. If
>> we only want to make SMC calls to TF-A on EL3 and exchange data with it
>> over shared memory, then I think:
>> - we don't need the __iomem tag, as there is no MMIO
> 
> agree
> 
>> - we only need a DMB, not a DSB (readl and writel imply DSB, use only
>>   readl_relaxed and writel_relaxed)
> 
> agree
> 
>>
>> On the other hand, if we also want to handle the case where the SCMI
>> server could be on a separate co-processor, then what this code is doing
>> is not sufficient because we also need a dcache flush, in addition to
>> the DSB.
>>
>> Bertrand, can you double-check?
> 
> If we want to handle a case where the memory is accessible to a coprocessor
> but there is no cache coherency, we need to flush the dcache definitely.
> 
> Seeing the amount of data here, I do agree with Stefano that it would be a good
> idea to make the provision to flush the data cache in all cases. Even if the data
> is accessed by a secure partition or the firmware coherently, flushing in all cases
> would have very limited performance impact here.
> 
> There is the other solution to have some kind of parameter to say if the accessor
> has coherent cache access but I do not think the performance impact here would
> justify such a complexity.
> 
The SCMI shmem expected to be mapped as MT_NON_CACHEABLE in all cases.
The Linux does devm_ioremap() -> ioremap() ->
(ARM64)  __ioremap((addr), (size), __pgprot(PROT_DEVICE_nGnRE))

There is also note in docs:
"+- shmem: shared memory for messages transfer, **Xen page aligned** with mapping``p2m_mmio_direct_nc``."

In the case of SCP - the SCMI shmem can be actually be in SRAM.

So, are you sure cache manipulations are required here?

-- 
Best regards,
-grygorii


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 12:12:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 12:12:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1012997.1391536 (Exim 4.92)
	(envelope-from )
	id 1uPgnJ-0002FC-3b; Thu, 12 Jun 2025 12:12:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1012997.1391536; Thu, 12 Jun 2025 12:12: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 1uPgnJ-0002F5-0K; Thu, 12 Jun 2025 12:12:33 +0000
Received: by outflank-mailman (input) for mailman id 1012997;
 Thu, 12 Jun 2025 12: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 1uPgnH-0002D3-Bs
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 12:12:31 +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 82c9c7e1-4786-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 14:12:29 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a50956e5d3so757224f8f.1
 for ; Thu, 12 Jun 2025 05:12:29 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-313c1bdb39bsm1277762a91.20.2025.06.12.05.12.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 05:12:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 82c9c7e1-4786-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749730349; x=1750335149; 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=8xyyN5XT47vJwSfKZrQEK0pCc85k8aSdstWdB8Lz9I4=;
        b=LyfVbT87ItV76ITTVu393j3v9k2Urk0J2Qx80+wD/8USPikU0wysVSDgd7YtjN/Wyp
         qm2ze3b9sNRiGtPVFsbWEpnqnRbQGYlpjko/O7+akUPgcc7nlmvPpWF2vVWY8YtsqvUY
         vQrcz3NIh0fLw7zuFBBm7I/IhS4BMbh/IVEgdDL/C6P9UFeLzwa7GgV6Pn3NgGYJt4FX
         xiyFT8Lf5UVS0Qf00eTdNTv7jw1UzojaH+3/P32afGePUb59dbm+GUua7OiB3ZArlNSq
         0EP9H5HWa5w8idLA21dx24ujvjG+XuKUylptRSbJ3VQk0R62nmsQswXMATdRGt6MSIYV
         p93g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749730349; x=1750335149;
        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=8xyyN5XT47vJwSfKZrQEK0pCc85k8aSdstWdB8Lz9I4=;
        b=u/t1MjnLGGdMZdHJA5k2m8YP5rZEZO0Zs/69uYpC1gsQ3tpDPETQ39IAEe82/Ar4Vp
         VtKQHCaJFTyAGgWF5x6bYCHVd0JMuNO43zzsKcakaOiRVBLYNG3m3PPRiZlxcpGgpZnm
         t0ytnSJxHLsp4hgyFYlacnkdpv+dOXa/rfVr16rA7e9NmJ2vgHxq7W+7n3QEm1OkX2qI
         Q01vo4MS4Qu4d6gFRtELdAKfqEUjZjlIXIk09NFNb09lnByWYz3n+NlIQinjn//EV2x8
         JXReiL/9g8C+uw2M7td6vUxXsVI0tFJ+xRQemhYSH8NIrfSkjzPNdPZLQ37DpfldOla4
         PGkA==
X-Gm-Message-State: AOJu0YzhfuMYL4v/noszEbAGscJgU8Dx7LBHXnuz7gQKBwldK9eUubaJ
	7T5NnLr5dL4KSffzJ+yUlpDyklLh3CtZIYikzfnBq1RyHVYYV3SCPxSEyFBi/Pjswl7kB+bcIJh
	Fj+U=
X-Gm-Gg: ASbGnculhTrM2l7E0/zrhibGjl7iCNSXW6HLKNnh5L1UJWb+zERooqcxG4JeB8v9f37
	idLsLtzll3bBOV7Do7JxaNJ3JXwXk4BPdEY3JRWm1m3BC4xRgTX/x3qawK4Z7MPpEUGaUYBAeOL
	NwR2Cyz7gm+fMz4Pt35G6TvVQ5ZL5MUFaj0uiV7RqG07hcBJXm1mohb70+nbHe+75bRIkwAogau
	T/5eEObE+2zuJdux7LOxOSe5cGm3P21h0m8EqB477jLnE7v9XhReSotDde0vq87MMTq/2vtTh6y
	urnRmWmPWT5Oob7u1xWF/d+3Ca5VEKqY6R3tuE1CwG/otejy18PCpJhar+Sa3kiy7FY7eXSLIV8
	Z7540yHNO+yr7+yXQwx8skZNejnILT2/h+5gSlAJJFgDBaOA=
X-Google-Smtp-Source: AGHT+IHw+Oy4TN3BUHRfz+XqPgIyQ3Zyv4M9E/jhUMwksT9oCqfr3LsUz9dft4p2kgGe6CtOy3PLmw==
X-Received: by 2002:a05:6000:40cc:b0:3a5:52d4:5b39 with SMTP id ffacd0b85a97d-3a5586dcc0cmr5617067f8f.8.1749730348850;
        Thu, 12 Jun 2025 05:12:28 -0700 (PDT)
Message-ID: <2274612e-d6cd-402e-9f2c-cefb72422cd7@suse.com>
Date: Thu, 12 Jun 2025 14:12:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC] Proposed x86 shadow paging changes
To: Teddy Astie 
References: 
Content-Language: en-US
Cc: Xen-devel 
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/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.06.2025 13:45, Teddy Astie wrote:
> In Xen x86, there is the shadow paging that could be used in some cases 
> (notably with HVM), and is used when HAP is not available. It may also 
> be used in very specific cases for PV guests.
> 
> With the vast majority of hardware supporting HAP (through EPT or NPT), 
> it's rarely used in practice for HVM, with most downstream projects 
> (XenServer, XCP-ng, QubesOS) are compiling-out its support by default. 
> It also performs very significantly worse than HAP.

Whenever this argument was made, iirc it was in particular George (who
was involved in the original work aiui) who kept pointing that such a
statement is not generally true, for numbers being workload dependent.

> Therefore, it's not very used in production, and unsurprisingly isn't 
> actively being worked on (most projects being around HAP).

Is it not? Feel free to review this 2 year old series
(https://lists.xen.org/archives/html/xen-devel/2023-05/msg01140.html),
to allow it to finally go in. I'm simply reluctant to do any other work
in that area until such earlier work was properly settled. In fact I may
have added one or two patches on top in the meantime, but I saw no good
reason to even post them, given the state of the series.

> One of the issues of Shadow Paging is that it relies on a heavy set of 
> optimizations, with some of them being effectively obselete 
> (optimisations based on heuristics designed for more than 20 years old 
> kernels) or eventually problematic (e.g with modern CPU mitigations e.g 
> L1TF mitigations).
> Most of these optimizations are hard to reason regarding reliability and 
> security and difficult to debug. Some of these optimizations causes very 
> subtle issues with TLB refactoring for ASID management rework [1].
> Moreover, it's fair to say performance is no longer the priority for 
> shadow paging.
> 
> My proposal would be to :
> - significantly reduce the complexity of shadow paging by dropping most 
> of the complex optimizations

If such can be proven to have no dramatic effect on performance, maybe.

> - consider Shadow Paging as Deprecated

I consider this impossible as long as it's still used for PV migration
and PV L1TF fallback. In particular ...

>  > Functional completeness: Yes
>  > Functional stability: Quirky
>  > Interface stability: No (as in, may disappear the next release)

... I don't see this as being possible to happen any time soon.

Jan

>  > Security supported: Yes
> 
> Teddy
> 
> [1] 
> https://lore.kernel.org/xen-devel/9cdb3e67abd01390bcc4cd103ca539d6bf7adbc0.1747312394.git.teddy.astie@vates.tech/
> 
> 
>  | Vates
> 
> XCP-ng & Xen Orchestra - Vates solutions
> 
> web: https://vates.tech
> 
> 



From xen-devel-bounces@lists.xenproject.org Thu Jun 12 12:21:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 12:21:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013015.1391545 (Exim 4.92)
	(envelope-from )
	id 1uPgw7-0004aL-TC; Thu, 12 Jun 2025 12:21:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013015.1391545; Thu, 12 Jun 2025 12:21: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 1uPgw7-0004aE-Pw; Thu, 12 Jun 2025 12:21:39 +0000
Received: by outflank-mailman (input) for mailman id 1013015;
 Thu, 12 Jun 2025 12:21: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 1uPgw6-0004a8-At
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 12:21:38 +0000
Received: from mail132-4.atl131.mandrillapp.com
 (mail132-4.atl131.mandrillapp.com [198.2.132.4])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c8be276b-4787-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 14:21:37 +0200 (CEST)
Received: from pmta09.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail132-4.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4bJ1q34ljhzlfkpx
 for ; Thu, 12 Jun 2025 12:21:35 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 4e83af7ff17e4e6db7624276829d52af; Thu, 12 Jun 2025 12:21: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: c8be276b-4787-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1749730895; x=1750000895;
	bh=HwexYdTNS3S6mzkG6V9I7/VYYo1D50L4FigEzg1yUPU=;
	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=M6LJK8UvjW8H4woLlThva69Ir++uxIqPiQJG106oUVBO+yJg7kp4cNbffH86oFJs7
	 eLyhnEotiuYGXT0UkFP2y7TIA9lzOsNT8qf6xQ+iX5PulmCp2cmh6PrW55adWBDpTq
	 meP6507aY7fRuyw7J3pA1H6lNsijqIBPTKzShwpTKCctj7itbkHqjeimpTvHLlNIr6
	 OKa13zdqRsBzBxjRJhqPD2IWf6/VU3OBkeNQO8t2nCrOAUC9be99V+yrkqzOHIpJx9
	 DcslkWIrT1p4oxnpe9dMg60oiCN7VsGgCQTcEa9jHB7WCaDHuzG0VOwXqw1+vxEhFt
	 pwYiKf4XxsOIA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1749730895; x=1749991395; i=teddy.astie@vates.tech;
	bh=HwexYdTNS3S6mzkG6V9I7/VYYo1D50L4FigEzg1yUPU=;
	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=EoH3f19nhFg/QcLsBsc+4Tu5PC+pGWFx53n+czMa18qi24jqhhP96/GV+8ybUi7Vs
	 jCkD5YiIiQ2mi3TdjCIaTDCAQs8dY0JGgfoYYI3RImPFJwaXESg3sSeb2WWHDpMgLn
	 dKRtGkl+u+3p4QupXGsbPEzeyKQKBW1ilTM3tY6AuzR80mi6BbWMjYS2KJvETpc0TT
	 hlSoDxHJO3mVIvS9ZYtgubkU4UvubGmHk0phtKp3wl86zo5RVPgElBJKUjUfl+mMOP
	 bABIpOVZJah4dvGfECsr4Pm+oAhy3bC0p9L+SMyV2u/YRvf02F45HIhf7cegVXYnuK
	 3qez5g+Jls+Hw==
From: "Teddy Astie" 
Subject: =?utf-8?Q?Re:=20[PATCH]=20docs:=20UEFI=20Secure=20Boot=20security=20policy?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1749730893647
Message-Id: 
To: "Jan Beulich" , "Andrew Cooper" 
Cc: "Anthony PERARD" , "Michal Orzel" , "Julien Grall" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Stefano Stabellini" , "Juergen Gross" , "=?utf-8?Q?Marek=20Marczykowski-G=C3=B3recki?=" , "Trammell Hudson" , "Ross Lagerwall" , "Frediano Ziglio" , "Gerald Elder-Vass" , "Kevin Lampis" , Xen-devel , "Samuel Verschelde" 
References: <20250611235851.167385-1-andrew.cooper3@citrix.com> <5aad2d39-31e1-44c6-b167-a3275dc6b747@suse.com>
In-Reply-To: <5aad2d39-31e1-44c6-b167-a3275dc6b747@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.4e83af7ff17e4e6db7624276829d52af?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250612:md
Date: Thu, 12 Jun 2025 12:21:35 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Le 12/06/2025 =C3=A0 12:08, Jan Beulich a =C3=A9crit=C2=A0:
> On 12.06.2025 01:58, Andrew Cooper wrote:
>> +
>> +Lockdown Mode
>> +^^^^^^^^^^^^^
>> +
>> +A mode which causes the enforcement of the properties necessary to conf=
orm to
>> +the Secure Boot specification.  Lockdown Mode is forced active when Sec=
ure
>> +Boot is active in the platform, but may be activated independently too =
for
>> +development purposes with the ``lockdown`` command line option.
>> +
>> +TODO
>> +^^^^
>> +
>> + * Command Line
>> + * Livepatching
>> + * Kexec
>> + * Userspace hypercalls
> 
> What about Dom0 being able to access almost(?) all memory, including all =
MMIO?
> In this context, isn't iommu=3Ddom0-strict a requirement for SB (while th=
at's
> still not the default mode of operation for PV Dom0, despite me keeping t=
o
> suggest that we ought to change that default)?
> 

Unless I missed something, the kernel is not a part of the TCB in this 
Secure Boot model. But at some point, we definitely want to reduce the 
TCB to just Xen, and put a more limited trust on the control domains.

Yet, the current plan of hardening the privcmd device is going to be 
very hard for sure.

dom0-iommu=3Dstrict is a good mitigations in case untrusted parties of the 
dom0 get direct access to a devices. However, as it is now, it implies a 
IOTLB flush for each grant mapping done, which severely impede PV 
performance (PV-IOMMU patches can help solving this performance problem 
though).

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 Jun 12 13:03:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 13:03:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013043.1391568 (Exim 4.92)
	(envelope-from )
	id 1uPha8-00024K-VE; Thu, 12 Jun 2025 13:03:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013043.1391568; Thu, 12 Jun 2025 13:03: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 1uPha8-00024D-Rd; Thu, 12 Jun 2025 13:03:00 +0000
Received: by outflank-mailman (input) for mailman id 1013043;
 Thu, 12 Jun 2025 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 1uPha8-000247-56
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 13:03:00 +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 8f254185-478d-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 15:02:56 +0200 (CEST)
Received: by mail-lf1-x129.google.com with SMTP id
 2adb3069b0e04-5534f3722caso1013773e87.0
 for ; Thu, 12 Jun 2025 06:02:56 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-7488087e769sm1419408b3a.11.2025.06.12.06.02.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 06:02:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8f254185-478d-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749733376; x=1750338176; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=niArqT7V6tzGmiUGru0YJoC/Q3HSp+fFuua2zUzXqTQ=;
        b=MssvEvJYbQfn6073i7Jn9a7KV1RT00aVzWbpYCejIrhhlSfIGvy0KRgHlz5LB9hl/Z
         I9fEoglCq463jsMJM5gL539lgKe/ntuUNMpo1zBHicuQZWcGmhbDeeQNTBl6uiLLcK0M
         bFhXZYvyz0fGcDARdITAq6DKLB7F7mBc2w3/USHcApRPDlxntVXzk2+l7uF2R2KJYSS4
         Skqh2CJ+hnlyG2cbdWnT/QGW1/d5TLrAM6GCd+Wz9uP8QMxU5e1DmdN8mJ9nnTx7d4au
         EZYxJz9NJExH2q6RBVAQmplAWsfMFwLXJR1li4z1BawI0LpWFdyvdhSFHvTDyxJVgdM0
         99Wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749733376; x=1750338176;
        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=niArqT7V6tzGmiUGru0YJoC/Q3HSp+fFuua2zUzXqTQ=;
        b=T7Gy2ZOVfivym5pn+YymoddFaLSNqliNbDp+uU3ZSYtauivvzdEERhUM0epOsT5nQM
         g1rhvnPfPUNRPkJLUZ52eSEWSFpMH8ztpV/7lz7k1zdh45iEtQbJiwb3Isp2RBSbHVsd
         EuZQMphyvlqNm4D8uFSjKfCvJvttCQvTYJ4ASrY1urUU6LxYv0JSyQevfs9QaGw81OMR
         YwMEUsAw7FYOhkZBtl9P7ZqRpfuBFh9xY745cJVE64Sp7mJg/njD5P0o5nPuxyQp/ldB
         MZCYfcNvBsy0vIn8kT/NQf3++RFNGhnq1Ade8cZl9HdeYsooCdpnMlrfFf7ygFg1T9c2
         caGA==
X-Forwarded-Encrypted: i=1; AJvYcCWv8v/JK2pTemMRI/ZcIMFnwsgDv/wSn4F4CkT3bBC0aM4O9kMZCQ0C5S9t+Nkai79gGX4JUmLau7g=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy+G5MfI55nxQCzf1ZQqWCyaMiCfchhMz3t8ilp94rTw10Nn+BZ
	1fOng3bMAidJBd8DoDemyzNCmAC1ImcJQrdrg4uTzw7sHiyzd5X7pxrS6GEic+sG4w==
X-Gm-Gg: ASbGnct0zS+IS/14m5LjY2j1eUCigm8L1Iyc1F575JP7M1gGjpUOOZCEZwUyGwY/NoE
	XiYR7/J2PmHRWBWF38ep0Ciex3gIEHYPpbwnXUehWj6sEIBqzXOtS28zmdSvgikSEonJXStw1++
	9sLILFH/av5+WgRHVd+l3y2EBgU7MrqVnMdASaa0WWnaCGECK7etm1bxNjJ/uNoIla98ESS7Brw
	E0Byv2GbeWAA4Rc7YpRZcNrJKrWw2qzkPVK/YriF/p+Fvv/riasRu1/yyqI8KJ5PTSj4ESCcfwg
	JIDZ/j4X40Nchwwf9SE9wXtO4Cq4xqU716D3ndZn6SWiR3/alPwEJlmX8h+Z/HZ9RUftx2Vm+Gj
	MODYmP0yu/ivECrsYw5HMY9DI0qo/zwsQMqqjp3vj5sqA0+A=
X-Google-Smtp-Source: AGHT+IGy5cp0OjzybkdEJmP57uw4j2n7b1ezM6HadPUhx/dohvoavhxgyAMDrfvn+eGSgWU21a0YcQ==
X-Received: by 2002:a05:6512:31c3:b0:553:642f:b037 with SMTP id 2adb3069b0e04-553a646804dmr716292e87.13.1749733375830;
        Thu, 12 Jun 2025 06:02:55 -0700 (PDT)
Message-ID: <95f78e64-77b0-4d27-b43a-268d1791233e@suse.com>
Date: Thu, 12 Jun 2025 15:02:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 07/18] xen/cpufreq: disable px statistic info in
 amd-cppc mode
To: Penny Zheng 
Cc: ray.huang@amd.com, xen-devel@lists.xenproject.org
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-8-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: <20250527084833.338427-8-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.05.2025 10:48, Penny Zheng wrote:
> We want to bypass construction of px statistic info, while not bypassing
> cpufreq_statistic_lock initialization for a good reason, in
> cpufreq_statistic_init() for amd-cppc mode, as P-states is not necessary there.
> 
> Signed-off-by: Penny Zheng 
> Acked-by: Jan Beulich 

I was considering to put this in together with patch 02 (if and when you confirmed
that it can go in with the one hunk dropped), but then noticed that ...

> --- a/xen/drivers/cpufreq/utility.c
> +++ b/xen/drivers/cpufreq/utility.c
> @@ -98,6 +98,9 @@ int cpufreq_statistic_init(unsigned int cpu)
>      if ( !pmpt )
>          return -EINVAL;
>  
> +    if ( !(pmpt->init & XEN_PX_INIT) )
> +        return 0;

... this check is pointless with how things are right now (the same check living at
the top of the sole caller). Hence I think this change should be folded into patch
04. Perhaps to be accompanied by a sentence why cpufreq_statistic_exit() doesn't
need a similar guard.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 13:08:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 13:08:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013048.1391577 (Exim 4.92)
	(envelope-from )
	id 1uPhf6-0002eR-Fk; Thu, 12 Jun 2025 13:08:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013048.1391577; Thu, 12 Jun 2025 13:08:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPhf6-0002eK-D4; Thu, 12 Jun 2025 13:08:08 +0000
Received: by outflank-mailman (input) for mailman id 1013048;
 Thu, 12 Jun 2025 13:08: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 1uPhf5-0002eD-U2
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 13:08:07 +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 477fe48e-478e-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 15:08:06 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a4fea34e07so599705f8f.1
 for ; Thu, 12 Jun 2025 06:08:06 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-313c19cd3cbsm1397220a91.11.2025.06.12.06.08.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 06:08:04 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 477fe48e-478e-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749733685; x=1750338485; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Cm+TVXQBkZ0iVl3W+nqNHlYed0rm5BC+82GjMjw6EOc=;
        b=c3H0L42dYSISVUCB3x2rtrOGwbo478beaXvvnphRbhFAQ8NClYEM7k7teRuhzktHaS
         3l5snnkk1WdgFXU0qVPVPbEXqEXIOz/ASFDo9tA10jRdfjr1r2yFPSpIem1xPg7fGyDm
         ItHhXTqQV9O7TLKFZjbwLxKIgacfssdFm1Vqz0LW5Yy4qp/q4buYmR1hrmN553N4UaG1
         fqFkZcGgz2PMe0+2eKYEE9SPKmySLRHWxurhPdJ8pWpVVxpQId53Gf1pvn7ITEwY3759
         ePsv/di0eRonPvuaDmH83U7N5wt0Oh8YC7+f58OTh6E65kY4H2s8XQcWyhN6MZOUu+ze
         +cqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749733685; x=1750338485;
        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=Cm+TVXQBkZ0iVl3W+nqNHlYed0rm5BC+82GjMjw6EOc=;
        b=KG28/t+HRXwx0NZ2SysMaKTrBbK44SV/zkQejIHKuF4M9ZjpE9/6S4UfANdT//2ti5
         1cW05M/sUM0qpHboINhEOChcVUqnlKc2sx4ZTCst0M8/rQMYX/TvdAMnHUNGxPoVSZ2Z
         E3ryyqR6eaLL4VJwK12h1UTxbLbV1LcRYLGx2mPqQC+ILM9waibnicuedYfgohokNXll
         qqFPc/acLWxlTk1AE0YCqIHDcJWBwIigkl9Djn75ICpeDIooIC+SSEwvgWVU5ZLW5k5G
         HbqMMQ+F3YQ+uZlRyaSJzyw8JHxWJglVKr1g6N/M7uuEGERGh6HfeiDmHorNoI9IxFp6
         2ICA==
X-Forwarded-Encrypted: i=1; AJvYcCUbxNkpgPZWYp7Kj9SaNlPtHsuQ5FMwULIPuE2oTrossOr6gTCweZd3qIUHidUn8bEL9NJgAqugVus=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwYnWF8l06juOcsw38W41jDJmjvdXA0+HsdjQLjGJ0J3FQfNonY
	0NS/WtbYOQ6eN0tyOmACHDWgS2ixEiR22TzmGVtGGyN3wrZZ0FWw1A9/eUuoNzG9nA==
X-Gm-Gg: ASbGnctx4q0+UtKNUqa6yHBKpadQ8osY/NxqeMdw7QPXNMKHNwVkUuLOOVFXtjnPs7p
	VXi4QggKykEpVuH4aoDHDwbz0X5KYrBHyIYZSYyHukNVMYltCJY7rVYvf/ZYCbR71C9Z9xs7780
	/EI6vkvKNy4K9Ji/MdlBJ1IW7BRJB39SxwDMBKudvam5YbwLziIaMaZ+N00XXVAYz3+dXMeaVZb
	kV++Nj73Xr7Ul+DEZ8B2uzoKbwePsU7HaPTxrCYR0ylrwYS6z4pNh+jz+7U919tDPSpKlVKgfL4
	9po1aJujxfMZrtp5Dpo+jY47w/wKeD9iK8J+TeSYfTxdDVbLB41sS9xCf526Y7mKfHaJrVLBBfE
	5tgSt29BLjpo8LzMg8UoPoHYqZVlgzvtvHukQqINK0rzkWMSqIT9lLMBWxg==
X-Google-Smtp-Source: AGHT+IGXcCLac/OMZatQjiWsfWcrB7qGPSq9g3iP5bYqB5+Iii+kvRXvuDxnh6EpqV2E5MNjkxg87Q==
X-Received: by 2002:a05:6000:2309:b0:3a4:e2f4:a86b with SMTP id ffacd0b85a97d-3a5586dc41emr5217458f8f.37.1749733685369;
        Thu, 12 Jun 2025 06:08:05 -0700 (PDT)
Message-ID: <711ac855-78e9-41bf-b057-4ed809b89c9c@suse.com>
Date: Thu, 12 Jun 2025 15:07:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 08/18] xen/cpu: Expand core frequency calculation for
 AMD Family 1Ah CPUs
To: Penny Zheng 
Cc: ray.huang@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-9-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: <20250527084833.338427-9-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.05.2025 10:48, Penny Zheng wrote:
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -583,12 +583,40 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
>                                                            : c->cpu_core_id);
>  }
>  
> +static unsigned int attr_const amd_parse_freq(unsigned int family,
> +					      unsigned int value)
> +{
> +	unsigned int freq = 0;
> +
> +	switch (family) {
> +	case 0x10 ... 0x16:
> +		freq = (((value & 0x3f) + 0x10) * 100) >> ((value >> 6) & 7);
> +		break;
> +
> +	case 0x17 ... 0x19:
> +		freq = ((value & 0xff) * 25 * 8) / ((value >> 8) & 0x3f);
> +		break;
> +
> +	case 0x1A:
> +		freq = (value & 0xfff) * 5;
> +		break;
> +
> +	default:
> +		printk(XENLOG_ERR
> +		       "Unsupported cpu family 0x%x on cpufreq parsing",
> +		       family);

I think I requested before (elsewhere) to prefer %#x over 0x%x.

However, why the log message? With ...

> +		break;
> +	}
> +
> +	return freq;
> +}
> +
>  void amd_log_freq(const struct cpuinfo_x86 *c)
>  {
>  	unsigned int idx = 0, h;
>  	uint64_t hi, lo, val;
>  
> -	if (c->x86 < 0x10 || c->x86 > 0x19 ||
> +	if (c->x86 < 0x10 || c->x86 > 0x1A ||

... this condition, there simply could be ASSERT_UNREACHABLE() there? Happy to
adjust while committing, so long as you agree. With the adjustment:
Reviewed-by: Jan Beulich 

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 13:10:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 13:10:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013061.1391588 (Exim 4.92)
	(envelope-from )
	id 1uPhhK-0004Bs-VO; Thu, 12 Jun 2025 13:10:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013061.1391588; Thu, 12 Jun 2025 13:10:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPhhK-0004Bl-SY; Thu, 12 Jun 2025 13:10:26 +0000
Received: by outflank-mailman (input) for mailman id 1013061;
 Thu, 12 Jun 2025 13: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 1uPhhJ-0003FU-Dv
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 13:10:25 +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 9a06e064-478e-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 15:10:24 +0200 (CEST)
Received: from DB3PR0302MB8919.eurprd03.prod.outlook.com
 (2603:10a6:10:435::21) by AS8PR03MB8120.eurprd03.prod.outlook.com
 (2603:10a6:20b:447::5) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.18; Thu, 12 Jun
 2025 13:10:21 +0000
Received: from DB3PR0302MB8919.eurprd03.prod.outlook.com
 ([fe80::ce88:43f9:c971:9584]) by DB3PR0302MB8919.eurprd03.prod.outlook.com
 ([fe80::ce88:43f9:c971:9584%5]) with mapi id 15.20.8813.024; Thu, 12 Jun 2025
 13:10: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: 9a06e064-478e-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=UdaUYvMslMjs2JLoLr6pX3/+HOzLKLma9tP5QQYmaAFSFyUPxsnFFFFEOaLKRQ/p+4wldiYy48OX7KNhRTE9UhwSSzVRXmGRtdGtTf3d3MCl23/YKqo68u9VijDYklwYjgbRgbjVLzrwi8Fa6qznj5xQ+n/LDrBqu9x0R/EoquswGPkgRJIlwL/x1p1f+9jwoXCMs1+arMpadX2qpP/nbYB5HNsXxkhqSu9/5Co5o91ATzrUuH0aor0G+wH1H6hSMc8bo38o0UWYz7c0MWLb1FnZiJXbxuYRsbHxSRfoy491k8N5WHmORtpj4T7vgdmGGajkwbXPfB5OYbkbWOPzQQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=n3H4brutdVrCgt9gPdRVj6jPm80PJ5bj+qF37qrJkLo=;
 b=jLcqgc2CzbdpuFR1nF9jO2m//nK9zQwAqYSrvS1Wr/xOH/thcvDbPu6omyuZnkAM38LUNlorijkHa8UGuY3VV+D3saUHPgK9PP/MXmKOn4+r9s8hLb4nsh07F6Cz1dHVaRGyjh0/X4gYiWiIPLWQryM5NiGH0uiH9EDlRh/Vq+coR3P9KCPXN/LclS+swT65maHQTdu73asLVUaKgZKwvnhTCp1Tbk0quxL3Q4wO1Orw1xdQDJ3FaVbmHW5LrVhf0+GygIRUIdZGbAb9gM8ixkSDBAc1Y5eTCw/os3LjzHtPS2ow4DRBrguww9mdjuAwlReauN1L5sZfdA1jTCfayw==
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=n3H4brutdVrCgt9gPdRVj6jPm80PJ5bj+qF37qrJkLo=;
 b=dRO4AILzk+2ILMeRMu/PqY/3IX3Zt2wvEOUMS+sCeYR1y4PwCpMXGQZO6PThKkE2+3ROXbEgg0TbYrYCb8KKsB0ouvVtSc9SUmNczr5TB+RswSQhkrap3Y2dciEfBnfSEEzzIQjKKHLDIuuEudreTs2iKIIb0lJt/YqEkFadEBBDkgIfRPOtNqZiVSSFu49E4Ja6nyP6Svrybw2taGMYTefGl17Fyna3s9kovbN97H+W+Jj+XCu4zfrMY0tAcWBIv6Yq3UUpM1gC6CFOWPrVhnpJuWB3YqKD8fgMAwwtDNvkEDnkn/eDIThRHuMISr8SIN14YDKciNDeGPff0zyB4A==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: <584cc496-fb59-4de6-b8fb-32e095e6d5cd@epam.com>
Date: Thu, 12 Jun 2025 16:10:19 +0300
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v4 5/8] xen/domctl: extend XEN_DOMCTL_assign_device to
 handle not only iommu
To: Oleksii Moisieiev ,
 Stefano Stabellini 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper ,
 Anthony PERARD ,
 Bertrand Marquis , Jan Beulich
 , Juergen Gross ,
 Julien Grall , Michal Orzel ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Volodymyr Babchuk 
References: 
 <4f58bf9c47c40413ee9250c4cd21458382aac857.1747669845.git.oleksii_moisieiev@epam.com>
 
 
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: FR2P281CA0144.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:98::18) To DB3PR0302MB8919.eurprd03.prod.outlook.com
 (2603:10a6:10:435::21)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DB3PR0302MB8919:EE_|AS8PR03MB8120:EE_
X-MS-Office365-Filtering-Correlation-Id: 753afd24-5422-4ab1-e599-08dda9b27c42
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?VE1zeFNJN1AxbTg5TkYxV1lPOXVpSVBlclFuTVNlSFNIQTd5TEVSbllmOVdz?=
 =?utf-8?B?MTJNemJIckZOaWNDWVE2VjIvbnU2TCt0dElHc3pSdHJHK0VKUmVFWkFPQk1a?=
 =?utf-8?B?ZVJqN01KS1hhSFBpZmNmRlZ0bzVqZzRXQXpvYWhtWVdIaXJjaFVmWmphYWls?=
 =?utf-8?B?KzVROEtwckE0eGRzSlRNZ2M1Sy9ENVN4K2dhRWxaSS82ZGttNk1SUThwd3Bi?=
 =?utf-8?B?aDJyek9SWk9iTzRNVWZucExuQjlLbWVERE9iUEVtT3FNWEI2OXhBZlNoVTVz?=
 =?utf-8?B?M0NRNmtSZWtTWVhNK2FjTDhOTjljRmw5aTZzemxLRDJQNWsvdmtYdU54ZXIr?=
 =?utf-8?B?NjVMYVEwWUJONXM2VjJyZ2wzQVVPdUtDc0dQaXBBRzQ1Vjc3c2lOdUJrdWVl?=
 =?utf-8?B?S3Flb0s5K1FIKyt0cHhVVDVNeFFTWWFSeEQ2OGllUjNLeWt2LzB1UVFWTHFV?=
 =?utf-8?B?MUVXdDJtcEpIVm5iRHMzUkhFbGtrNWtvdG5zYUtYc3Z5K0VEMzBGMUd5S3B0?=
 =?utf-8?B?RFg0L3k1OVVKK1Y1TFlUeUFIYWFVb0FVMkJ2SDNxTFY2Nk1Xd0ZOQUpvUTBW?=
 =?utf-8?B?cS9QaElnaW1Yc2xjL1MvUlNkNEdyaWJxZDNVVnJyZjdkT3JBTWV3aUhwYncx?=
 =?utf-8?B?U0E3USttYnZhYm40UGo5TFVBY3ZOTUU1aFRrd1FLdjdQWVRiMVB1aEx6TENF?=
 =?utf-8?B?RXB2eS9GYlpVK00ybVcxcVh4SmovaTU0VWtXTjlmdkpBWUVHbm1MNXFucHZl?=
 =?utf-8?B?ZUxlVmREZ1prUmJGY1pvY0hxVU9zTEFqK0VpVlF4V016ZmZya3N6TysrajZj?=
 =?utf-8?B?aGY2cEFjcTNhZjhEeHczVlhtVG12ZVJOS0FXNEx3cWJheVJldnpZaHJnNksx?=
 =?utf-8?B?TFlQYjRNbkVXL2l4anhRNDg3NElwZENXTjU2NjJEeXpsRlVaeUVrVlBiaUJN?=
 =?utf-8?B?b08ybndQMVlocWY4bEVXL2dyV0JnRWJaZ1ZTb0gyaVZBTWNPSVZYa250Lzkv?=
 =?utf-8?B?bWxUdVRpeWpNTXNaL0xRRmp2ZnJpVTdCRVowRUtYT2t5SUxvWjlqTzAzcUJK?=
 =?utf-8?B?aXJ6YlY2dElGcjZ0YThiRG82OU9pcmt6RkRaSm9EVVVDTUNNcmdydXZWUEdm?=
 =?utf-8?B?OWIyT3dpR05RbGZUNEhtOVErM2tCUFVKaTN6NjRCUitjSVRwV2UyOWtmdytq?=
 =?utf-8?B?dFFpRjFSV016SnJNbGJjSWdnKzhBQ1VzTkxlMkZuYTAvTWxvRlYwd3B1d3Z1?=
 =?utf-8?B?K0pQNmV6YktPb3hXSEFWYUdWdktVcExtL2l5SDRKcUVDQzZ4TlJPZDFSV2lp?=
 =?utf-8?B?YTg1Z0hxd2JuSTBwSitJODRFdDhyT0IvSUdBbFE0TnhwanQreTlsUUZ0M1ZF?=
 =?utf-8?B?cHdTNm12OHNXRTBwOGV2VUZpOVZ2KzM2YW9GN1Y0YUxtZzJhU2IrckpVbHVm?=
 =?utf-8?B?Z3lGenU3TFhrTWo2NUpaN2VWc1hNeEpSQ3hsdlg5bkMxc2p3QmFwNDMvbzh0?=
 =?utf-8?B?YitqM0xVZDdkSWRUM0wzVlhnSWQzQ1R5cFhnOWtQVXExWEJGaWVqK3VDVDA2?=
 =?utf-8?B?QjJUZ3FuMHRGMXNxOVpTanR5bmovK0s3c3FCQldBVElybjJOV01iVWVZMjBY?=
 =?utf-8?B?dzBrUTlnSVVFQk9JNkx1ZG5mZlJPMEd6NisvdkE1eHhUYkFOZDk3MFl2Mzgz?=
 =?utf-8?B?RTcyQ1M5VDhINkNEaHZieERxTldnWXhPL3BpQjhzbzRCc3FNQ0hmRGhyY003?=
 =?utf-8?B?N1l6SVU2Q2Fna0lOd1gvWllIY2hvc0ZONjZ5cXM1U01FRHdvWk5kWHF6NXhS?=
 =?utf-8?Q?4lEMWmxE13LW9JV5rZKCvS5FibgJ3MXXfSUGw=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB3PR0302MB8919.eurprd03.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?cmdRQmI0eERkMW1yZTY0SEttVmNtMHkxTTBmQS9zTVlRWVFsbGN5cEJqQ1lL?=
 =?utf-8?B?blZxOUU4U3lsa0NZVy9TQXdMWTgrZnFzUnRkdG9FZE41b2QwNGpnQlpQbDhR?=
 =?utf-8?B?TEZVK1Z4QTQyeTFwamlrYkxKZjE1UGZwSE5TNFZ5TEMzN201Q0lMaXdYMDhJ?=
 =?utf-8?B?T3prR1VsREdOUzBEVEI1WjYxdW0wVXoxTzNyT0ZEWWZLd0RVRHQ4R0xlWmxY?=
 =?utf-8?B?L0R0VTUvZUt6eGRKaWZBbUo0V2JxMHVkLy9hUFNWQ0RpdDI2Q2VpbmhLazJI?=
 =?utf-8?B?d3B3WVVxZC9oUzc4TXlHTVJQTmRSTi96dS85OTdDcUNCQTMzcEs3TzZPM0pE?=
 =?utf-8?B?RERMeDZJNkhOK28xQ0JKeEZoVGlxWGhyTUt6blZ6UG5uRzdRcm9YcEk2YU1o?=
 =?utf-8?B?eFFYNFJVbVc0elJtckZiZHdmREZDQkdJU0MzYlZucC9ZNFd1WFdIb0VWRlkv?=
 =?utf-8?B?OE8xeDlBS2JZMFAwYVJYRDlUc2o5K0xvMkFLcDkxS2dGRVQ4eGhDMzVXaFNZ?=
 =?utf-8?B?WjBzekE4Y2c3QlFGbTdCN0JQNnNhZWFyN1NaTWRJdk9VbS9Xd2VvZ2NnZE53?=
 =?utf-8?B?V0tLMjdhZzd2UisydVMraTFPc0I3Z1RrYS9OWUZzUUU5aWw4RDFyRERyNU5j?=
 =?utf-8?B?L21LdjMxcERYa2sycWNWZFRRZWp0N1lGU3RuMzJnWWpyVlY3RWlZTC9meXpP?=
 =?utf-8?B?ZjJRWlF6d2pXUVRrZGx3SG9xUWNxZ0poM3hvQVdLOFZHdUJrV0ZWdjhXOUV3?=
 =?utf-8?B?MjBVWjZOUzFBdWlwU3J1VHFEV1J3VE9rNmx6b1FkdnFnOGxpemM1RlVENFpt?=
 =?utf-8?B?ZWVTVXdrN2NpczlCTWpHNmc1RlA5cmwvZmtvaGJyZEFBcVExaEhxMG1hQ1Ns?=
 =?utf-8?B?NG5VTytuU0FFOFBZM1FiaGsxQmRsSUw1MFlnNTU3Tng5NWpyQk5FQUd4MU5U?=
 =?utf-8?B?YUVWa2MxblUrdE5TZTdCcFI1RVFNbXV3a1V5MGt6Sm1wY2IyVjFRWTVYMzJr?=
 =?utf-8?B?WmxjejBRU2grK200N3RBR1dSRDU2ZXRHcUNjTVZIYjFadnBZYkEwdElXSE9K?=
 =?utf-8?B?cVJma2xIMXVDR0kyUjBLbzR5VzR1VU9lV2xmZ2FWYnhQTGtnRWgxTzlQd3d1?=
 =?utf-8?B?YTYvTWNQNXlwV25nS282Wk1WVGhiaVEzczloZ1o3NGp4RUpQejFkVzVpbGRm?=
 =?utf-8?B?ZDJSYUNOektUa3ZzK0JTdlU5d1czR2JMQnMzNklkRCt0bDhhNHlpdnp0aUtW?=
 =?utf-8?B?azN5L0QvRGwxcVZoV1FjSlIxR0pibDNFUEF6a0ZqL1NZWDgyQVYyZjRIU3Vy?=
 =?utf-8?B?MW5Nc3FzM1cvRXgyNTBXV1JnbUV2b2JBRHpXUmVCcXRqMlNCTUNmanhtcks0?=
 =?utf-8?B?WWc2QXBFaHVlb09NNThQbmtEL3BmdFl2ZWVzNHVOZlJEYTM1WW5FNXZJazZT?=
 =?utf-8?B?ajhnMVgzekFFdFlObTJOSnJMZGZ6OXhldHhhQzNmeFN3cXlUbUtaSUhRK1Zk?=
 =?utf-8?B?Wm5memNPcjN2U1lCdmEvZ1gxRHlkTm9rdGZEK3Vlc1ZJSitXUWRVajVVTEUy?=
 =?utf-8?B?Y2JSaVl5SjZoS2t1aEtmV09lS1h6aEtJL2IyOFcyQ09OcFc3YXZtTlRVR1Jx?=
 =?utf-8?B?L3VtVjFtOVpHUTFxVU1HcXIwellRcmYwK2h3TVZrQlZyMk1iT2Vsb2JRdTBr?=
 =?utf-8?B?Vkk2V1JTaCtyRjVIZG45bmpma25lMEN2Z0QveXBXZlBTQ1BRL1hmRGMrTEdj?=
 =?utf-8?B?aXMyb0dvSFdZOU1DUGh0cjlJcmNrTEVxQnlRMkRLZnpZYlNoc3Y3U053dTNn?=
 =?utf-8?B?NFZNNmFtVnlzbzVONVVPVCtpUHlaKzJyUW1tbWxLSmY1TFM2bTI3aUNGVmtL?=
 =?utf-8?B?VDVXNmZsNnozMTJtOGFXTVh1bUFhbHpHbTRNTlRjNWF1UVlVWFlYUURpMmMw?=
 =?utf-8?B?ckszczFqbjIvRlhwRDNCY2R3aVlvWkEvYWhQY3V1aXM0SkZtUzU3UkUzZ1FI?=
 =?utf-8?B?UmhpYjVxRWdvM3JHS3BubDFGSFQyM0UxMmllMDNtOGJZeXUwMHM0WE1yQ0Uz?=
 =?utf-8?B?bTVEZHlUdXBvWHZsdU5lZVY4U1BDMGEweDBSMXJtTDdmVVRUUTlCK3JKclRY?=
 =?utf-8?B?em1Ed1hyUDFWYnBwdHNOdXhNb3NZamtoV2t5c3kzdEN6eXh5dCt2SHpiOXpv?=
 =?utf-8?B?N2c9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 753afd24-5422-4ab1-e599-08dda9b27c42
X-MS-Exchange-CrossTenant-AuthSource: DB3PR0302MB8919.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2025 13:10:21.1798
 (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: YN42/9jLC92v3XQiZKaC5PRggnk6eMQAa1a9DFOFZwbk3m2KRteCihDfpiRdpwGHNRklpxMrYg+rVSk/Xh1kGsx7LWdmvOS9cymrWA9OLyw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB8120



On 12.06.25 14:42, Oleksii Moisieiev wrote:
> Hi Stefano,
> 
> I'm very sorry for a long silence. Please see my answers below:
> 
> On 22/05/2025 03:25, Stefano Stabellini wrote:
>> On Mon, 19 May 2025, Oleksii Moisieiev wrote:
>>> From: Grygorii Strashko
>>>
>>> Add chained handling of assigned DT devices to support access-controller
>>> functionality through SCI framework, so DT device assign request can be
>>> passed to FW for processing and enabling VM access to requested device
>>> (for example, device power management through FW interface like SCMI).
>>>
>>> The SCI access-controller DT device processing is chained after IOMMU
>>> processing and expected to be executed for any DT device regardless of its
>>> protection by IOMMU (or if IOMMU is disabled).
>>>
>>> This allows to pass not only IOMMU protected DT device through
>>> xl.cfg:"dtdev" property for processing:
>>>
>>> dtdev = [
>>>       "/soc/video@e6ef0000", <- IOMMU protected device
>>>       "/soc/i2c@e6508000", <- not IOMMU protected device
>>> ]
>>>
>>> The change is done in two parts:
>>> 1) update iommu_do_dt_domctl() to check for dt_device_is_protected() and
>>> not fail if DT device is not protected by IOMMU
>>> 2) add chained call to sci_do_domctl() in do_domctl()
>>>
>>> Signed-off-by: Grygorii Strashko
>>> Signed-off-by: Oleksii Moisieiev
>>> ---
>>>
>>>
>>>
>>>    xen/arch/arm/firmware/sci.c             | 37 +++++++++++++++++++++++++
>>>    xen/arch/arm/include/asm/firmware/sci.h | 14 ++++++++++
>>>    xen/common/domctl.c                     | 19 +++++++++++++
>>>    xen/drivers/passthrough/device_tree.c   |  6 ++++
>>>    4 files changed, 76 insertions(+)
>>>
>>> diff --git a/xen/arch/arm/firmware/sci.c b/xen/arch/arm/firmware/sci.c
>>> index e1522e10e2..8efd541c4f 100644
>>> --- a/xen/arch/arm/firmware/sci.c
>>> +++ b/xen/arch/arm/firmware/sci.c
>>> @@ -126,6 +126,43 @@ int sci_assign_dt_device(struct domain *d, struct dt_device_node *dev)
>>>        return 0;
>>>    }
>>>    
>>> +int sci_do_domctl(struct xen_domctl *domctl, struct domain *d,
>>> +                  XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
>>> +{
>>> +    struct dt_device_node *dev;
>>> +    int ret = 0;
>>> +
>>> +    switch ( domctl->cmd )
>>> +    {
>>> +    case XEN_DOMCTL_assign_device:
>>> +        ret = -EOPNOTSUPP;
>> Are you sure -EOPNOTSUPP is the right error code for the 3 checks below?
> 
> The -EOPNOTSUPP code is used because this is part of a chained call after
> iommu_do_domctl, as stated in xen/common/domctl.c:859. The
> XEN_DOMCTL_assign_device
> call is expected to handle any DT device, regardless of whether the DT
> device is
> protected by an IOMMU or if the IOMMU is disabled.
> The following cases are considered:
> 
> 1. IOMMU Protected Device (Success)
> 
> If the device is protected by the IOMMU and iommu_do_domctl returns 0,
> we continue
> processing the DT device by calling sci_do_domctl.
> 
> 2. IOMMU Disabled (-EOPNOTSUPP from iommu_do_domctl)
> 
> If iommu_do_domctl returns -EOPNOTSUPP, indicating that the IOMMU is
> disabled,
> we still proceed to call sci_do_domctl.
> 
> 3. Error from iommu_do_domctl (Fail State)
> 
> If iommu_do_domctl returns any error, the system enters a fail state, and
> sci_do_domctl is not called.
> 
> 4. -EOPNOTSUPP from sci_do_domctl
> 
> If sci_do_domctl returns -EOPNOTSUPP, this indicates one of the following:
> - The provided device is not a DT device.
> - There is no cur_mediator available (indicating that the SCI subsystem
> is enabled
> in the configuration, but no mediator was provided).
> - The current mediator does not support assign_dt_device (this is
> expected to be changed;
> see below for details).
> In this case, -EOPNOTSUPP is returned but will be ignored, and the
> original return value from iommu_do_domctl will be used as the final result.
> 
> 5. Return Code from sci_do_domctl
> 
> If sci_do_domctl returns 0 (success) or an error code (failure),
> the return value from iommu_do_domctl is overridden, and the result from
> sci_do_domctl is returned.
> Note: -EOPNOTSUPP from iommu_do_domctl will also be overridden since
> step 2 was successfully completed (or failed).
>>> +        if ( domctl->u.assign_device.dev != XEN_DOMCTL_DEV_DT )
>>> +            break;
>> this one
>>
>>> +        if ( !cur_mediator )
>>> +            break;
>> this one
>>
>>> +        if ( !cur_mediator->assign_dt_device )
>>> +            break;
>> and also this one? It seems more like an -EINVAL as the caller used a
>> wrong parameter?
> 
> I think you are right that this case should return -EINVAL because we
> should fail if mediator
> 
> without implemented mandatory features was provided. Will be fixed.
> 
>>> +        ret = dt_find_node_by_gpath(domctl->u.assign_device.u.dt.path,
>>> +                                    domctl->u.assign_device.u.dt.size, &dev);
>>> +        if ( ret )
>>> +            return ret;
>>> +
>>> +        ret = sci_assign_dt_device(d, dev);
>>> +        if ( ret )
>>> +            break;
>>> +
>>> +        break;
>>> +    default:
>>> +        /* do not fail here as call is chained with iommu handling */
>> It looks like this should be an error
>>
>>
>>> +        break;
>>> +    }
>>> +
>>> +    return ret;
>>> +}
>>> +
>>>    static int __init sci_init(void)
>>>    {
>>>        struct dt_device_node *np;
>>> diff --git a/xen/arch/arm/include/asm/firmware/sci.h b/xen/arch/arm/include/asm/firmware/sci.h
>>> index 71fb54852e..b8d1bc8a62 100644
>>> --- a/xen/arch/arm/include/asm/firmware/sci.h
>>> +++ b/xen/arch/arm/include/asm/firmware/sci.h
>>> @@ -146,6 +146,14 @@ int sci_dt_finalize(struct domain *d, void *fdt);
>>>     * control" functionality.
>>>     */
>>>    int sci_assign_dt_device(struct domain *d, struct dt_device_node *dev);
>>> +
>>> +/*
>>> + * SCI domctl handler
>>> + *
>>> + * Only XEN_DOMCTL_assign_device is handled for now.
>>> + */
>>> +int sci_do_domctl(struct xen_domctl *domctl, struct domain *d,
>>> +                  XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl);
>>>    #else
>>>    
>>>    static inline bool sci_domain_is_enabled(struct domain *d)
>>> @@ -195,6 +203,12 @@ static inline int sci_assign_dt_device(struct domain *d,
>>>        return 0;
>>>    }
>>>    
>>> +static inline int sci_do_domctl(struct xen_domctl *domctl, struct domain *d,
>>> +                                XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
>>> +{
>>> +    return 0;
>>> +}
>>> +
>>>    #endif /* CONFIG_ARM_SCI */
>>>    
>>>    #endif /* __ASM_ARM_SCI_H */
>>> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
>>> index 05abb581a0..a74ee92067 100644
>>> --- a/xen/common/domctl.c
>>> +++ b/xen/common/domctl.c
>>> @@ -27,6 +27,7 @@
>>>    #include 
>>>    #include 
>>>    #include 
>>> +#include 
>>>    #include 
>>>    #include 
>>>    #include 
>>> @@ -851,6 +852,24 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
>>>        case XEN_DOMCTL_deassign_device:
>>>        case XEN_DOMCTL_get_device_group:
>>>            ret = iommu_do_domctl(op, d, u_domctl);
>>> +
>>> +        if ( !ret || ret == -EOPNOTSUPP )
>> It is better to invert the check:
>>
>> if ( ret < 0 && ret != -EOPNOTSUPP )
>>       return ret;
> +
>>> +        {
>>> +            int ret1;
>>> +            /*
>>> +             * Add chained handling of assigned DT devices to support
>>> +             * access-controller functionality through SCI framework, so
>>> +             * DT device assign request can be passed to FW for processing and
>>> +             * enabling VM access to requested device.
>>> +             * The access-controller DT device processing is chained after IOMMU
>>> +             * processing and expected to be executed for any DT device
>>> +             * regardless if DT device is protected by IOMMU or not (or IOMMU
>>> +             * is disabled).
>>> +             */
>>> +            ret1 = sci_do_domctl(op, d, u_domctl);
>>> +            if ( ret1 != -EOPNOTSUPP )
>>> +                ret = ret1;
>>> +        }
>>>            break;
>>>    
>>>        case XEN_DOMCTL_get_paging_mempool_size:
>>> diff --git a/xen/drivers/passthrough/device_tree.c b/xen/drivers/passthrough/device_tree.c
>>> index 075fb25a37..2624767e51 100644
>>> --- a/xen/drivers/passthrough/device_tree.c
>>> +++ b/xen/drivers/passthrough/device_tree.c
>>> @@ -318,6 +318,12 @@ int iommu_do_dt_domctl(struct xen_domctl *domctl, struct domain *d,
>>>                break;
>>>            }
>>>    
>>> +        if ( !dt_device_is_protected(dev) )
>>> +        {
>>> +            ret = 0;
>>> +            break;
>>> +        }
>> I am concerned about this: previously we would call
>> iommu_assign_dt_device and the same check at the beginning of
>> iommu_assign_dt_device would return -EINVAL. Now it is a success.
>>
>> I am not sure this is appropriate. I wonder if instead we should:
>>
>> - remove this chunk from the patch
>> - change the return error for !dt_device_is_protected at the top of
>>     iommu_assign_dt_device from -EINVAL to -EOPNOTSUPP
>> - this would fall into the same ret != -EOPNOTSUPP check after
>>     iommu_do_domctl

We need to be careful here :(

The reason for this change, in it's current form is to make this part of
the code to work the same way as other parts [1] and [2] where IOMMU is configured (yep, and get what we need):

[1] xen/arch/arm/device.c handle_device()
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/arm/device.c;h=5e1c1cc326ac04d30e7158905fead9b41c719fc0;hb=HEAD#l287

which is used to create hwdom(dom0) or apply overlays and called for every "own" node (!"xen,passthrough").
The "own" node may not be IOMMU protected.


[2] xen/common/device-tree/dom0less-build.c handle_passthrough_prop()
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/common/device-tree/dom0less-build.c;h=3d503c697337a4cc6df35403b9a2595b40089dae;hb=HEAD#l224

which is used for "dom0less" devices pass-through (arm/ppc) and called for every node with "xen,path" property,
but this path is intended to perform not only IOMMU, but also IRQs configuration.
The DT node, pointed by "xen,path", may not be IOMMU protected.

In both above cases call pattern is:

     res = iommu_add_dt_device(node);
     if ( res < 0 )
	return res;

     if ( !dt_device_is_protected(node) )
          return 0; //no failure

     res =  iommu_assign_dt_device(domain, node);
     if ( res )
	return res;

And only when XEN_DOMCTL_assign_device (iommu_do_dt_domctl()) is handled the call pattern is
different and there is no check for dt_device_is_protected().

> 
> That's a good point. I think we should do the same for
> 
>   > if ( !is_iommu_enabled(d) )
> 
>   >  return -EINVAL;
> 
> because in this case we should process sci as well. I will do the change

-- 
Best regards,
-grygorii


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 13:15:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 13:15:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013069.1391598 (Exim 4.92)
	(envelope-from )
	id 1uPhm6-0004pQ-HY; Thu, 12 Jun 2025 13:15:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013069.1391598; Thu, 12 Jun 2025 13:15: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 1uPhm6-0004pJ-Dj; Thu, 12 Jun 2025 13:15:22 +0000
Received: by outflank-mailman (input) for mailman id 1013069;
 Thu, 12 Jun 2025 13:15: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 1uPhm4-0004pC-Dg
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 13:15:20 +0000
Received: from mail187-14.suw11.mandrillapp.com
 (mail187-14.suw11.mandrillapp.com [198.2.187.14])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 48531097-478f-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 15:15:17 +0200 (CEST)
Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail187-14.suw11.mandrillapp.com (Mailchimp) with ESMTP id
 4bJ3100Wjzz8XS0sm
 for ; Thu, 12 Jun 2025 13:15:16 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 1357c5a2135143eda47e3443c19241c0; Thu, 12 Jun 2025 13:15: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: 48531097-478f-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1749734116; x=1750004116;
	bh=XhBW5+34ZHlZU2Gf5ZCw5PdSvV9dL4CCEo630zBvK5I=;
	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=e44HPHv49jMWBZxxGAx09z5XC9EhzrxuKf0lVeX/rvGQmrOhK8bjUpwMZw7Ywk8JE
	 VxCQFUwnjztAGcwc8EOOzFT0LwnVQBnWwZX4mTERqfpYgF3NFKY1hJyN6hv8AMKEZI
	 4hMmZv+3DWddtRwU7XcMyUVAm7gyHFY59JXZaZghwGLRLsepGUA9tvAZoRwaHPtAcH
	 Gbdj53KWIWVKNvn1K0Et2ovoDVycndojMiBj8GFXggS/NdAKHup2pm7P8x4ZNdIhs7
	 bjFpGOCAWVq26Cv0aqh6GRaM+2u/TlP6N6rhlovcreMH7tmCPg/xYosLYQjNC7m3oC
	 cOgHPQHNZz7RQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1749734116; x=1749994616; i=ngoc-tu.dinh@vates.tech;
	bh=XhBW5+34ZHlZU2Gf5ZCw5PdSvV9dL4CCEo630zBvK5I=;
	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=srFByjPT/QleJdEDuiCB9kCvyE4ngAdcyFSaN3VuVx1FKeisvCOlAqQlYZr0qTJoU
	 YkJPGMAmm5gpNTTEdG1jcWwt+3c9a+ELqN0EbsCyM/C8soRPaaay2GM07pU7NC9mUU
	 gvV3KXhFPuBkIt8VgRqLB82qyCG/V9FGJeV40pkl1AeOmQhOazwTnwIBrFslummiM8
	 eNlSZ0o/wxZGweDL13j6I+D0EEJB1KQWLqkpVyqskjDPezwf7OvqypOPlAjZEHPfdD
	 05LXJRcvr2frTO/f0vpCoOJ0fve/EYQNjc8RYIXoPAZP61pYC843xDT6ySipglZhUW
	 F2rNN+nD5p4lA==
From: "Tu Dinh" 
Subject: =?utf-8?Q?Re:=20[PATCH]=20docs:=20UEFI=20Secure=20Boot=20security=20policy?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1749734113337
Message-Id: <4226d6ef-a1eb-4210-8cae-2b9b2d906d1c@vates.tech>
To: "Andrew Cooper" , Xen-devel 
Cc: "Anthony PERARD" , "Michal Orzel" , "Jan Beulich" , "Julien Grall" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Stefano Stabellini" , security@xen.org, "Juergen Gross" , "=?utf-8?Q?Marek=20Marczykowski-G=C3=B3recki?=" , "Trammell Hudson" , "Ross Lagerwall" , "Frediano Ziglio" , "Gerald Elder-Vass" , "Kevin Lampis" 
References: <20250611235851.167385-1-andrew.cooper3@citrix.com>
In-Reply-To: <20250611235851.167385-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.1357c5a2135143eda47e3443c19241c0?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250612:md
Date: Thu, 12 Jun 2025 13:15:16 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 12/06/2025 02:03, Andrew Cooper wrote:
> Written to be solution and deployment neutral in order to focus on the
> technology itself.  This policy is intended to work as well for UKI as fo=
r the
> "classic server setup" approach.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Anthony PERARD 
> CC: Michal Orzel 
> CC: Jan Beulich 
> CC: Julien Grall 
> CC: Roger Pau Monn=C3=A9 
> CC: Stefano Stabellini 
> CC: security@xen.org
> CC: Juergen Gross 
> CC: Marek Marczykowski-G=C3=B3recki 
> CC: Trammell Hudson 
> CC: Ross Lagerwall 
> CC: Frediano Ziglio 
> CC: Gerald Elder-Vass 
> CC: Kevin Lampis 
> 
> A rendered version is available at:
>    https://andrewcoop-xen.readthedocs.io/en/docs-secureboot/admin-guide/u=
efi-secure-boot.html
> 
> Obviously RFC at this point.  It's worth saying that XenServer is intendi=
ng to
> use Shim and get a signature from Microsoft, retaining all exiting featur=
es
> such as Livepatching and Kexec crash reporting.
> 
> This trails off into more TODOs towards the end.  Individual tasks should
> expand on the start made and resulting conversation from this thread.  As=
 a
> reminder, the target audience for this doc is an administrator running a =
Xen
> deployment, but who is not necesserily a developer.
> 
> Several things are hard to express and want further discussion.  Suggesti=
ons
> welcome:
> 
> 1) Content of CONFIG_CMDLINE and the various CONFIG_*_DEFAULT options.  X=
en is
> not going to be issuing XSAs for "downstream chose an unsafe configuratio=
n,
> then signed and deployed the result", yet Xen probably should be on the h=
ook
> for bad "default ..." settings in Kconfig.
> 
> 2) Pre-boot DMA Protection.  Microsoft consider this a platform feature
> requiring OEM enablement, and do not consider its absence to be a Secure =
Boot
> vulnerability.  But, it is less clear what the policy ought to be for Xen
> booting on a capable system and failing to do a correct live-handover of =
the
> IOMMU across ExitBootServices().
> 

As I understand it, hardware attacks currently don't count in the Secure 
Boot security model, and it would only depend on whether userspace code 
can use the vulnerability to run privileged code right?

> 3) The AMD microcode signature vulnerability.  While it's not Xen's bug p=
er
> say, it's clearly a Secure Boot bypass because we do offer microcode load=
ing
> capabilties to userspace, and malicious userspace can load an unauthorise=
d
> microcode which allows them to read/write physical memory and bypass furt=
her
> signature checks.
> 
> 4) Userspace Hypercalls.  To anyone who isn't already aware, /dev/xen/pri=
vcmd
> in the various Unicies is a giant priv-esc hole, as root userspace can
> e.g. issue direct memory hypercalls behind the back of an (intentionally)
> oblivious kernel, and cannot be handwaved away as "it's fine because it's
> root" under Secure Boot.  It's not a Xen vuln (Xen *does* audit pointers =
in
> guest hypercalls), but it is a guest kernel vuln because of failing to
> correctly audit hypercall parameters.  However, it does require substanti=
al
> changes in Xen in order to allow guest kernels to do something half-way s=
afe.
> ---
>   docs/admin-guide/index.rst            |   1 +
>   docs/admin-guide/uefi-secure-boot.rst | 134 ++++++++++++++++++++++++++
>   2 files changed, 135 insertions(+)
>   create mode 100644 docs/admin-guide/uefi-secure-boot.rst
> 
> diff --git a/docs/admin-guide/index.rst b/docs/admin-guide/index.rst
> index 54e6f65de347..e7895ee95001 100644
> --- a/docs/admin-guide/index.rst
> +++ b/docs/admin-guide/index.rst
> @@ -5,4 +5,5 @@ Admin Guide
>   
>   .. toctree::
>      introduction
> +   uefi-secure-boot
>      microcode-loading
> diff --git a/docs/admin-guide/uefi-secure-boot.rst b/docs/admin-guide/uef=
i-secure-boot.rst
> new file mode 100644
> index 000000000000..0e0f50143892
> --- /dev/null
> +++ b/docs/admin-guide/uefi-secure-boot.rst
> @@ -0,0 +1,134 @@
> +.. SPDX-License-Identifier: CC-BY-4.0
> +
> +UEFI Secure Boot
> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> +
> +UEFI Secure Boot is a verification mechanism, intended to ensure that on=
ly
> +code trusted by the platform can run.  This is to prevent malicious code=
 from
> +hijacking the system.  Secure Boot requires that all privileged code be
> +signed, and that there is a trust relationship with the platform; i.e. c=
ode
> +which is not signed by a key enrolled in platform must not run privilege=
d.
> +
> +Within the Xen architecture, Xen, the :term:`control domain` and
> +:term:`hardware domain` share responsibility for running and administeri=
ng the
> +platform.  This makes their kernels privileged as far as Secure Boot is
> +concerned.
> +
> +When Secure Boot is active in the platform, privileged code is required =
to not
> +run any untrusted code (i.e. not run any code for which there is not a g=
ood
> +signature), and is required not to allow this restriction to be bypassed
> +(e.g. by command line request).
> +
> +
> +Support in Xen
> +--------------
> +
> +There are multiple ways to achieve this security goal, with differing
> +tradeoffs for the eventual system.
> +
> +On one end of the spectrum is the Unified Kernel Image.  e.g. Xen is bun=
dled
> +with the dom0 kernel and init-ramdisk, with an embedded command line, an=
d with
> +livepatching and kexec compiled out, and suitably signed.  The signature=
 is
> +checked by the bootloader and, as this covers all the privileged code, X=
en
> +doesn't need to perform further checks itself.
> +
> +On the other end of the spectrum is maintaining the features of existing
> +deployments.  e.g. Xen needs signature checking capabilities for the dom=
0
> +kernel, livepatches and kexec kernels, and needs to allow the use of saf=
e
> +command line options while disallowing unsafe ones.
> +
> +It is important to remember that Xen is one piece of the larger platform=
,
> +where every piece depends on the correct functioning of all earlier piec=
es.  A
> +product supporting Secure Boot requires a holistic approach involving al=
l
> +components in the system.  It is not sufficient to consider Xen in isola=
tion.
> +
> +.. TODO: Move "In Progress" tasks here as they become ready
> +
> +Security Scope
> +--------------
> +
> +Vulnerabilities impacting Secure Boot require a fixed component to be pr=
oduced
> +and distributed, the vulnerable component to be revoked, and the revocat=
ion
> +distributed to platforms.
> +
> +The following principles and guidelines indicate where Secure Boot diffe=
rs
> +from more traditional security models, and the situations in which extra
> +remediation may be necessary.
> +
> +Principles
> +^^^^^^^^^^
> +
> + * Privileged code shall include Xen and the kernel(s) of the control an=
d
> +   hardware domain (both, if they're split).  While there is a privilege=
 split
> +   here in Xen's regular security model, they are equal from Secure Boot=
's
> +   point of view.
> +
> + * Root or ADMIN in userspace is unprivileged from Secure Boot's point o=
f
> +   view, and must not be able to alter the enforcement policy or load un=
signed
> +   code even by e.g. editing a configuration file and rebooting.
> +
> +Within Scope
> +^^^^^^^^^^^^
> +
> +The following types of issue require remediation and revocation of vulne=
rable
> +binaries.
> +
> + * Any failure to apply enforcements even against traditionally-privileg=
ed
> +   userspace, including failure to authenticate new code to run and fail=
ure to
> +   handle revocations properly.
> +
> + * Any Out-of-Bounds write capable of altering the enforcement policy, o=
r
> +   capable of bypassing enforcement, e.g. by corrupting the running code=
.
> +
> +Out of Scope
> +^^^^^^^^^^^^
> +
> +While typically a security issue in their own rights, these issues do no=
t
> +constitute a Secure Boot vulnerability, and do not require special
> +remediation.
> +
> + * Denial of Service vulnerabilities.
> +
> + * Out-of-Bounds reads.
> +
> +The Xen Security Team will endeavour to produce XSAs for all violations =
of
> +this security policy, including identifying them specifically as requiri=
ng
> +further remediation by downstreams.
> +
> +
> +In Progress
> +-----------
> +
> +.. warning::
> +
> +   The following work is still in progress.  It is provisional, and not
> +   security supported yet.
> +
> +
> +Secure Boot Advanced Targeting
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +SBAT is a recovation scheme for Secure Boot enabled components, using a
> +generation based scheme.  See `Shim SBAT.md
> +`_ for full details.
> +
> +Upstream Xen provides the infrastructure to embed SBAT metadata in
> +``xen.efi``, but does not maintain a generation number itself.  Downstre=
ams
> +are expected to maintain their own generation numbers.
> +

Why would Xen not maintain its own SBAT generation? An upstream SBAT 
incremented for every Secure Boot bypass XSA would make it far easier to 
block vulnerable variants and help downstreams coordinate fixes.

> +
> +Lockdown Mode
> +^^^^^^^^^^^^^
> +
> +A mode which causes the enforcement of the properties necessary to confo=
rm to
> +the Secure Boot specification.  Lockdown Mode is forced active when Secu=
re
> +Boot is active in the platform, but may be activated independently too f=
or
> +development purposes with the ``lockdown`` command line option.
> +
> +TODO
> +^^^^
> +
> + * Command Line
> + * Livepatching
> + * Kexec
> + * Userspace hypercalls

IMO key management, signing and revocation should be another topic for a 
TODO element.

Best regards,



Ngoc Tu Dinh | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech




From xen-devel-bounces@lists.xenproject.org Thu Jun 12 13:16:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 13:16:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013076.1391608 (Exim 4.92)
	(envelope-from )
	id 1uPhms-0005K4-Um; Thu, 12 Jun 2025 13:16:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013076.1391608; Thu, 12 Jun 2025 13:16: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 1uPhms-0005Jx-Rl; Thu, 12 Jun 2025 13:16:10 +0000
Received: by outflank-mailman (input) for mailman id 1013076;
 Thu, 12 Jun 2025 13: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 1uPhms-0004pC-9c
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 13:16:10 +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 671337ee-478f-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 15:16:08 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a51481a598so595959f8f.3
 for ; Thu, 12 Jun 2025 06:16:08 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-748809d308fsm1371179b3a.72.2025.06.12.06.16.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 06:16:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 671337ee-478f-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749734168; x=1750338968; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=35U+F60uK7YOaJDMYu0EyRE5z0hyPIp9rPmS9rZMj30=;
        b=PWFu2n+wFa0X7SAGZWUKbIoIFV3GdCelL35BZ6sAyKLygcGnI9uAOlO7w8NLGnVhPm
         h1Y6lsvhtXiZqKDgddDz9L6Mzjw9KNdlpS4+c3olY2cnCRa+ShfRtX9pyEHqS+O7P/Vj
         0ei92fW0e4iKlTcMsPE5iZ+LHtaX0zUCPfR/axhKWyM/zd6jGfT/jYP0XLZFZ6KAXcic
         PYKiw0kRDZPlQKN0oLBn/wzw5ZdKCRpAN+mq69Z2SQLzvUMpvRc2WG5xBFd9UjV3Jmqb
         7nbSacCRpovF5irRD4wzBJVv+ic0AR0M+INRQseQSqt7As9AIHSgGemYyrq27HvvxCzR
         FNaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749734168; x=1750338968;
        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=35U+F60uK7YOaJDMYu0EyRE5z0hyPIp9rPmS9rZMj30=;
        b=CY1KY0AYuZhYcpIBCVJ8dTb5TBJdh7bBeuh62dFJMuCQgu3X8tnt4JWutplifjT5dz
         R7jxRZd7Lw3DzEBZbE29raeSWFXTePoIkHWuK2QymLJsaXAK09R53fnXNxjuKyzGBUfN
         AcIXTpZEuFKgX+c5QRGoXJ+riFwosa1WASCTBTxSHXT4NcPndAzE8Pn5hUJ+jbicO8SA
         pcMMq/D6NOSIq0mbCKGRMh3zndkJZ0pXMXGhb1yS0gf8XOfEN0uDD4O5jQioIeQ9nmxV
         gBXwIhrGL6ib3+TKFV9RqVFU2F+Nd0OJbxvKqF5xcVFaREIrV5inr967jHnp+CF6hxOJ
         VAww==
X-Forwarded-Encrypted: i=1; AJvYcCX7xjc9OVdYc1NAkTpxnbtw361ujQBWT6uIg6kIifDEfKpwGEUdd60yZHheC/44wfId06DB+wmYCxM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzSCT1tj892rGct4NS0TTBl+PnRz40RneWyVemwOSgM0jCVOBIP
	muPL8GvHqyaj+OL9fVIAhs4W0GU1yzGWuI5qR3IBSNZvXINGIXQGH0DZToVLt1yJNw==
X-Gm-Gg: ASbGncue7RIDh2EDwe6JdKOjfY3z/DVDQ294k7iB3RAekGWlpXeNIq/G7SyPh9jIASx
	jgvgveZ2/34S0Kkun/cozYB8VgOD0Y8cDsgiZqBYBTj2kQZudDcmgT73Wd0DMfm5c3ejsqqRcaU
	t00VzI0GssKFMhPe1b/DnGueE6CMjzgUnrhEnoNUfWYdcy50f6hIgoz68uEpDqYtrHslMpCe404
	KZZc49mfyuhg7UgybdtvK+MfTWPwAO16S6xBfaYw/jKYC8DpQ6zvmGr5BVmsHndAQa7TE6l44BC
	pR1cLxfBsUMBn9DpoCil08jz1OFs83Sw2rbOrYlpedqCHNfFRKVnKAeRJTK7G/js0VPkM5D53y/
	GVJt208W3GTI5GMgpyNUAuD/bXV/UiOIu4GRjZA+eNzXta/5VuZcPIrBV+g==
X-Google-Smtp-Source: AGHT+IE3+Jk4YsqtoeyABIQV7PELxHOzIF5uU++RSNuNABcKNqIBz9tHHx4ZSUOLBZZi+JZRy6OP5g==
X-Received: by 2002:a05:6000:40c7:b0:3a5:2e9c:edc with SMTP id ffacd0b85a97d-3a56134958dmr2629906f8f.34.1749734167570;
        Thu, 12 Jun 2025 06:16:07 -0700 (PDT)
Message-ID: <8993b948-24e3-4e3e-bf17-22aa77ba4f25@suse.com>
Date: Thu, 12 Jun 2025 15:15:59 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 09/18] xen/amd: introduce amd_process_freq() to get
 processor frequency
To: Penny Zheng 
Cc: ray.huang@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-10-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: <20250527084833.338427-10-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.05.2025 10:48, Penny Zheng wrote:
> When _CPC table could not provide processor frequency range
> values for Xen governor, we need to read processor max frequency
> as anchor point.
> So we extract amd cpu core frequency calculation logic from amd_log_freq(),
> and wrap it as a new helper amd_process_freq().
> 
> Signed-off-by: Penny Zheng 
> ---
> v1 -> v2:
> - new commit
> ---
> v3 -> v4
> - introduce amd_process_freq()
> ---
> v4 -> v5:
> - make amd_process_freq() static to statisfy Misra demand
> - change "low_mhz", "nom_mhz" and "hi_mhz" parameter to unsigned int
> - fix order of logged frequencies
> ---
>  xen/arch/x86/cpu/amd.c | 58 +++++++++++++++++++++++++++++-------------
>  1 file changed, 40 insertions(+), 18 deletions(-)
> 
> diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
> index 3770d75150..8c985466fa 100644
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -611,14 +611,15 @@ static unsigned int attr_const amd_parse_freq(unsigned int family,
>  	return freq;
>  }
>  
> -void amd_log_freq(const struct cpuinfo_x86 *c)
> +static void amd_process_freq(const struct cpuinfo_x86 *c,
> +			     unsigned int *low_mhz,
> +			     unsigned int *nom_mhz,
> +			     unsigned int *hi_mhz)
>  {
>  	unsigned int idx = 0, h;
>  	uint64_t hi, lo, val;
>  
> -	if (c->x86 < 0x10 || c->x86 > 0x1A ||
> -	    (c != &boot_cpu_data &&
> -	     (!opt_cpu_info || (c->apicid & (c->x86_num_siblings - 1)))))
> +	if (c->x86 < 0x10 || c->x86 > 0x1A)
>  		return;
>  
>  	if (c->x86 < 0x17) {
> @@ -699,20 +700,20 @@ void amd_log_freq(const struct cpuinfo_x86 *c)
>  
>  	if (idx && idx < h &&
>  	    !rdmsr_safe(0xC0010064 + idx, val) && (val >> 63) &&
> -	    !rdmsr_safe(0xC0010064, hi) && (hi >> 63))
> -		printk("CPU%u: %u (%u ... %u) MHz\n",
> -		       smp_processor_id(),
> -		       amd_parse_freq(c->x86, val),
> -		       amd_parse_freq(c->x86, lo),
> -		       amd_parse_freq(c->x86, hi));
> -	else if (h && !rdmsr_safe(0xC0010064, hi) && (hi >> 63))
> -		printk("CPU%u: %u ... %u MHz\n",
> -		       smp_processor_id(),
> -		       amd_parse_freq(c->x86, lo),
> -		       amd_parse_freq(c->x86, hi));
> -	else
> -		printk("CPU%u: %u MHz\n", smp_processor_id(),
> -		       amd_parse_freq(c->x86, lo));
> +	    !rdmsr_safe(0xC0010064, hi) && (hi >> 63)) {
> +		if (nom_mhz)
> +			*nom_mhz = amd_parse_freq(c->x86, val);
> +		if (low_mhz)
> +			*low_mhz = amd_parse_freq(c->x86, lo);
> +		if (hi_mhz)
> +			*hi_mhz = amd_parse_freq(c->x86, hi);
> +	} else if (h && !rdmsr_safe(0xC0010064, hi) && (hi >> 63)) {
> +		if (low_mhz)
> +			*low_mhz = amd_parse_freq(c->x86, lo);
> +		if (hi_mhz)
> +			*hi_mhz = amd_parse_freq(c->x86, hi);
> +	} else if (low_mhz)
> +		*low_mhz = amd_parse_freq(c->x86, lo);
>  }
>  
>  void cf_check early_init_amd(struct cpuinfo_x86 *c)
> @@ -723,6 +724,27 @@ void cf_check early_init_amd(struct cpuinfo_x86 *c)
>  	ctxt_switch_levelling(NULL);
>  }
>  
> +void amd_log_freq(const struct cpuinfo_x86 *c)
> +{
> +	unsigned int low_mhz = 0, nom_mhz = 0, hi_mhz = 0;
> +
> +	if (c != &boot_cpu_data &&
> +	    (!opt_cpu_info || (c->apicid & (c->x86_num_siblings - 1))))
> +		return;
> +
> +	amd_process_freq(c, &low_mhz, &nom_mhz, &hi_mhz);
> +
> +	if (!low_mhz && !nom_mhz && !hi_mhz)

With this ...

> +		printk("CPU%u: %u (%u ... %u) MHz\n",
> +		       smp_processor_id(),
> +		       nom_mhz, low_mhz, hi_mhz);

.. aren't you logging three zeroes here? Considering the earlier mistake
of the order of logged frequencies, did you not think of looking at the
resulting output in the hypervisor boot log?

Same issue again below then.

With all instances corrected:
Reviewed-by: Jan Beulich 

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 13:22:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 13:22:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013085.1391617 (Exim 4.92)
	(envelope-from )
	id 1uPhso-0007PD-IW; Thu, 12 Jun 2025 13:22:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013085.1391617; Thu, 12 Jun 2025 13: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 1uPhso-0007P6-FC; Thu, 12 Jun 2025 13:22:18 +0000
Received: by outflank-mailman (input) for mailman id 1013085;
 Thu, 12 Jun 2025 13: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 1uPhsn-0007Oy-Ft
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 13:22:17 +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 41bc7563-4790-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 15:22:15 +0200 (CEST)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3a4f78ebec8so721743f8f.0
 for ; Thu, 12 Jun 2025 06:22:15 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2364e6d99d2sm13377755ad.130.2025.06.12.06.22.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 06:22:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 41bc7563-4790-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749734535; x=1750339335; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=kqT5/LLk930IJEsFDdlPEKdhXsX/vrLGpTstZqfZ4cw=;
        b=ec+cuIyczGtRc3GVcxoqUV+MIF5R80ZwvefOVIrHBSupHgW/f3p0pSUcx2dd8dIQdK
         UJcnavGZNHyL5kdy7aDixKof2BKIRTH5dejWv2RZjKYfk38oqwvh+XRoHgWCMmGu7J69
         lfeoe2o1X/FqlrqNSFtFd6HhH1SS1mrSU0nkyfVSkVZ6QGnCbKU4JnWsayYv3tNuXIsY
         OkgswiIsxIbOp+GBLuS5bjfJhee4Quw9ErOAwKz9z49KP6PQnVrvnFgsKd2CQzQ2vOxH
         5TyomQxyP8VOoUiDCp6F6Vlp5a4jbgJXBt6FLh768o+raZxGZzY6NEl+RVx9zp0czKFx
         UK2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749734535; x=1750339335;
        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=kqT5/LLk930IJEsFDdlPEKdhXsX/vrLGpTstZqfZ4cw=;
        b=vEY8Z/5Y0Xm1mBkDbjBXZ6ZGICQQeVp1Kr28oZ8hNY6K/b2Pc4vnuCSi16dxgDTZsK
         jj52Rk4wew/xu610NRkiIv0l3Y7scKcbQHDF3Xp9diUjfAtPPynT18hm8x1tOib9J6pM
         BA5Qy09G0TGA4s+yFgDozkgD+72yHt+nwfjR201akM3gUZchXLkDYZSJvgqQDxrj10HB
         7KNjXX1J2F2SKvzDrD1H8yhAhmDD2UPsuqYyJKib54fFmK7Gry/+OvB+AqcC4S72rIMT
         FAUYnQbNa6wA26RaP9PrdhcM+Ku00/eiwZuGoC4TDS6LHXh/F7ITuCFPwq77LaXCpGVZ
         5jgw==
X-Forwarded-Encrypted: i=1; AJvYcCWB8UwBsPPAChliS/5ABrvuGXSAjanfR7FuAgKmL/MTHJoCGmTfZ87Zi/u0zC3jtm7fxe3MbjjYAoo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzMtLEDjtTeM1MVujp5897URug2m8P5FCHiphOfAwiSbiROsWRO
	RBjt8eqji6ricbeIyco5JRf65/kLIRZMsaGOXeEdy33uw0ksLV8urJX2H2wqXRGRbA==
X-Gm-Gg: ASbGncuoQzxppSS4sImUTRvffWcVjjMP6AWVDWvgyoMI5w9xWlShGawacYmrLw4q0Q0
	u6i8+qkSt7/hvmcgE+R2y3EZOpYfqrw8BdAG/dMBYiQ0IOhOARU2CXZDENyOlHuD4VkROwDTDCI
	oEST6YAAfkJOCZi7KgruK6rWm1O4irdC0yJArM4SUSUlFczkwO1Mi2gLc6AnMlXe/vRojXeS1Hc
	is/a+Qjh412bczK5wU2mHcspRcCJUSV7JXTSbsDas95mPSv+fLqjcG8u9NKCP/Oja4nqJhxZYU0
	4MeIm2KzdFLUncRDm4ZaYp1EsZX5oAcmmbSIAKQXCU00QfmLZN7trM0u4hEd5zpiRx3gAe6Mdct
	epzM/9B4H9yBVr6d6K6ac9p+sdalEgz4bsqmqGXnSievvQgE=
X-Google-Smtp-Source: AGHT+IHLyXGMPFj3xjDuT5iKPffAPIr21r4xBqfCo5jDkqom6JJNreu37j3/tpv+8pmIbysaPT32Kw==
X-Received: by 2002:a05:6000:2481:b0:3a4:e8bc:594 with SMTP id ffacd0b85a97d-3a56069467dmr2702440f8f.8.1749734534639;
        Thu, 12 Jun 2025 06:22:14 -0700 (PDT)
Message-ID: <53e8cacd-e035-47ca-906e-35f748559328@suse.com>
Date: Thu, 12 Jun 2025 15:22:01 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] docs: UEFI Secure Boot security policy
To: Tu Dinh 
Cc: Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , Juergen Gross
 ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , Trammell Hudson ,
 Ross Lagerwall ,
 Frediano Ziglio ,
 Gerald Elder-Vass ,
 Kevin Lampis ,
 Xen-devel ,
 Andrew Cooper 
References: <20250611235851.167385-1-andrew.cooper3@citrix.com>
 <4226d6ef-a1eb-4210-8cae-2b9b2d906d1c@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: <4226d6ef-a1eb-4210-8cae-2b9b2d906d1c@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12.06.2025 15:15, Tu Dinh wrote:
> On 12/06/2025 02:03, Andrew Cooper wrote:
>> +Secure Boot Advanced Targeting
>> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> +
>> +SBAT is a recovation scheme for Secure Boot enabled components, using a
>> +generation based scheme.  See `Shim SBAT.md
>> +`_ for full details.
>> +
>> +Upstream Xen provides the infrastructure to embed SBAT metadata in
>> +``xen.efi``, but does not maintain a generation number itself.  Downstreams
>> +are expected to maintain their own generation numbers.
>> +
> 
> Why would Xen not maintain its own SBAT generation? An upstream SBAT 
> incremented for every Secure Boot bypass XSA would make it far easier to 
> block vulnerable variants and help downstreams coordinate fixes.

Quoting from the SBAT patch that was submitted a little while ago:

"The SBAT section provides a way for the binary to declare a generation
 id for its upstream source and any vendor changes applied."

That is, the generation ID is per-vendor. Upstream incrementing whatever
ID would be meaningless to downstreams then. Hence we can as well not do
so in the first place.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 13:27:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 13:27:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013090.1391628 (Exim 4.92)
	(envelope-from )
	id 1uPhyD-0007z8-4W; Thu, 12 Jun 2025 13:27:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013090.1391628; Thu, 12 Jun 2025 13:27: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 1uPhyD-0007z1-1Q; Thu, 12 Jun 2025 13:27:53 +0000
Received: by outflank-mailman (input) for mailman id 1013090;
 Thu, 12 Jun 2025 13:27: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 1uPhyB-0007yv-Ic
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 13:27:51 +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 095c8589-4791-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 15:27:50 +0200 (CEST)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-43cfe63c592so11026405e9.2
 for ; Thu, 12 Jun 2025 06:27:50 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b2fd62c2d65sm1108433a12.52.2025.06.12.06.27.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 06:27:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 095c8589-4791-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749734870; x=1750339670; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Fxnfw+jwQYw5NuVhxc0jjRyWOMGtOF6GJ0xpu9TzAvQ=;
        b=Sks2tKri9V0fwqzOoX3/Oy7n2RZHAcHMlgZFQv6D18m6Ww3bEd1+6he4ws/5Nx+Z/i
         3piKm/m3+sJMC7sSrch18hFyDgNFLa6lDpxe0hGGVXwRdeMxZn9HnGkTr0iOdEBx5Xcs
         Nshf1C6WDB8hl+ZWTB1dsjwMvmY2V8YTNvRsZeX0lwSpftL/O2QWc45YNv1IOrAGg507
         /DnikYnwhPrLh7TB8s5y5zs2OLQDNPhy5tQuYE7GpE2ltDAtEtgZN7YOQYEttPyqBLEu
         Jc7gxUOr7q+1jKJFdGmZBpfudLKHgf4uA9Q47neacZ1VvuWLrLpuyXVCBhSODBJAIwZn
         otmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749734870; x=1750339670;
        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=Fxnfw+jwQYw5NuVhxc0jjRyWOMGtOF6GJ0xpu9TzAvQ=;
        b=HiO1I654M1H3mZf3InAqf1EcHlwya1AE5OSnYqpc4C8e4FAakT13Ch8OOkwIdR8lAm
         IG2afqs+770C4sXm78h53peJojgt8BTvJw7M6WtK9gJhAJ+2pIIvTPNPCPYVzwA/H6Kd
         +TDUIdzdeZ5BOyalO+JXckUTkkGr2hqddTmSMlesGTGOrFTzZIPs6ReQDgj6M18wQcLB
         75pX4CmKSLkCkBH/kW5AVqKz77zCWOLldOTAJVvqG2KPQEEncn1uq88fy7hUkyh6Kp5x
         77icv4YxZwoRsyKVHx6sc43e0zF9LBMtoVOHksmwykyKjUfJKZdQlZB+AizwP3bxLJ/n
         Khlw==
X-Forwarded-Encrypted: i=1; AJvYcCUxn2TCzucuQqUP4ErezlZyhCC0TPHljS3kF/g8SwVrbP45vx8GbOv0gnLagebrI1at/9oeKeBV7oA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyE55lvNxWZ4PXQbdUQYXq8DOnoNv7ngF/Oo6a4B1o5SxMSMb2t
	s+1gpyC+iFybwGAxjfohzPzPRS71DdnKE4Kp/GwkWcMYC0R9iJ6U1cTl2RU1tZjpmg==
X-Gm-Gg: ASbGncuCrlXoeXfXtDVbC/StkO/rfKHXT5+ynITRkwpnXw5F7GVLo90vFcbKcyS/M8Y
	yzip0fwZkWl3EtM0Rf3OHfp4Q/9nIDwv7sfWo3V+19tioBVjy0D0hrHULm3cOcWb4mvL4hyFzel
	zE5LVAOr55SP/HC5/QvPO6oCAHWi3gMl1MbfwW4MZiahFGzzQQEtxV4WqUSthnEr6rNhYHEtAzE
	+TpmoyZAZszRSyUbZ1Rn1rWraej1FY+zPS2TFYCDUic642pBGm7imUJgNpZu1+MUQRrwGR/7RA0
	0Ze5MoGnT/pSva9QqWtDwxinV9jaWPwg5pVP+BQ9/h/dR8bA7QPMMPln8IP6XfK7B7/irKMhGth
	8vSfiWv/+oXqwsgx3ZuypaiTKJ6MzlvTRQBuqUooMCEe0XX8=
X-Google-Smtp-Source: AGHT+IH3iUPlYVXlklur4seHf5ZUvRv/WrRApQz9xyWpA867rJrMtly69CFMzHp2u+lMMjJ7Hxtziw==
X-Received: by 2002:a05:6000:188d:b0:3a4:d0dc:184f with SMTP id ffacd0b85a97d-3a5612f42a1mr2811521f8f.39.1749734869550;
        Thu, 12 Jun 2025 06:27:49 -0700 (PDT)
Message-ID: <26da6299-4000-46f3-835e-ad926a4f91a7@suse.com>
Date: Thu, 12 Jun 2025 15:27:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 16/18] tools: drop "has_num" condition check for cppc
 mode
To: Penny Zheng 
Cc: ray.huang@amd.com, Anthony PERARD ,
 Juergen Gross , xen-devel@lists.xenproject.org
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-17-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: <20250527084833.338427-17-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.05.2025 10:48, Penny Zheng wrote:
> In `xenpm get-cpufreq-para `, ->freq_num and ->cpu_num checking are
> tied together via variable "has_num", while ->freq_num only has non-zero value
> when cpufreq driver in legacy P-states mode.
> 
> So we drop the "has_num" condition check, and mirror the ->gov_num check for
> both ->freq_num and ->cpu_num in xc_get_cpufreq_para().
> 
> Signed-off-by: Penny Zheng 
> ---
> v3 -> v4:
> - drop the "has_num" condition check
> ---
> v4 -> v5:
> - refactor title and commit
> - make all three pieces (xc_hypercall_bounce_pre()) be as similar as possible
> ---
>  tools/libs/ctrl/xc_pm.c | 43 +++++++++++++++++++++++------------------
>  1 file changed, 24 insertions(+), 19 deletions(-)
> 
> diff --git a/tools/libs/ctrl/xc_pm.c b/tools/libs/ctrl/xc_pm.c
> index 3c9e272aee..cdc072e757 100644
> --- a/tools/libs/ctrl/xc_pm.c
> +++ b/tools/libs/ctrl/xc_pm.c
> @@ -212,34 +212,41 @@ int xc_get_cpufreq_para(xc_interface *xch, int cpuid,
>      DECLARE_NAMED_HYPERCALL_BOUNCE(scaling_available_governors,
>  			 user_para->scaling_available_governors,
>  			 user_para->gov_num * CPUFREQ_NAME_LEN * sizeof(char), XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
> -    bool has_num = user_para->cpu_num && user_para->freq_num;
>  
> -    if ( has_num )
> +    if ( (user_para->cpu_num && !user_para->affected_cpus) ||
> +         (user_para->freq_num && !user_para->scaling_available_frequencies) ||
> +         (user_para->gov_num && !user_para->scaling_available_governors) )
> +    {
> +        errno = EINVAL;
> +        return -1;
> +    }
> +    if ( user_para->cpu_num )
>      {
> -        if ( (!user_para->affected_cpus)                    ||
> -             (!user_para->scaling_available_frequencies)    ||
> -             (user_para->gov_num && !user_para->scaling_available_governors) )
> -        {
> -            errno = EINVAL;
> -            return -1;
> -        }
>          ret = xc_hypercall_bounce_pre(xch, affected_cpus);
>          if ( ret )
>              return ret;
> +    }
> +    if ( user_para->freq_num )
> +    {
>          ret = xc_hypercall_bounce_pre(xch, scaling_available_frequencies);
>          if ( ret )
>              goto unlock_2;
> -        if ( user_para->gov_num )
> -            ret = xc_hypercall_bounce_pre(xch, scaling_available_governors);
> +    }
> +    if ( user_para->gov_num )
> +    {
> +        ret = xc_hypercall_bounce_pre(xch, scaling_available_governors);
>          if ( ret )
>              goto unlock_3;
> +    }
>  
> +    if ( user_para->cpu_num )
>          set_xen_guest_handle(sys_para->affected_cpus, affected_cpus);

Any reason this can't simply move up to the bottom of the identical conditional
above?

> -        set_xen_guest_handle(sys_para->scaling_available_frequencies, scaling_available_frequencies);
> -        if ( user_para->gov_num )
> -            set_xen_guest_handle(sys_para->scaling_available_governors,
> -                                 scaling_available_governors);
> -    }
> +    if ( user_para->freq_num )
> +        set_xen_guest_handle(sys_para->scaling_available_frequencies,
> +                             scaling_available_frequencies);
> +    if ( user_para->gov_num )
> +        set_xen_guest_handle(sys_para->scaling_available_governors,
> +                             scaling_available_governors);

Same for these two then.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 13:29:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 13:29:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013096.1391638 (Exim 4.92)
	(envelope-from )
	id 1uPhzR-0008U6-Dv; Thu, 12 Jun 2025 13:29:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013096.1391638; Thu, 12 Jun 2025 13:29:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPhzR-0008Tz-Al; Thu, 12 Jun 2025 13:29:09 +0000
Received: by outflank-mailman (input) for mailman id 1013096;
 Thu, 12 Jun 2025 13:29: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 1uPhzQ-0008Tr-4z
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 13:29:08 +0000
Received: from mail187-14.suw11.mandrillapp.com
 (mail187-14.suw11.mandrillapp.com [198.2.187.14])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 354e1fea-4791-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 15:29:04 +0200 (CEST)
Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail187-14.suw11.mandrillapp.com (Mailchimp) with ESMTP id
 4bJ3Jv3lQDz8XRql9
 for ; Thu, 12 Jun 2025 13:29:03 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 12da2aeb48284cfca2696e3222faaa34; Thu, 12 Jun 2025 13:29: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: 354e1fea-4791-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1749734943; x=1750004943;
	bh=HCCC2WMnOuHQR2vZ/NmiQkkCDP/l5lJNiSzzhcJK0mc=;
	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=mq2S1xMKoJEObOqop8FXMH7LCUXI6tW7mo7uJGM0BOzLW01amdO9whrGLjhVYFdyw
	 NIIcz6MCv+NWSVq7zxzo4zkG5NaXVJ6As/1yAJ0jM//y8hBabs2hTqnsdMYQUr5o8P
	 bcSU/o1FZNLfNMjJ6s/aFawRlNlKiqhsXqCaAZyPd4DJyD0dfNH9mhKSJG8LUyjA/m
	 oX7L2ciTzlqNOG5Y4Juec58zUgUeV8pH0NBDoDPrQ40IOOsG4FvSCoZvxYIeRLwozm
	 zeIMjpHroJdqTmgJvxO8jiD5SkKZklbLj06+ty8KcfjxvBAoVvXK5LHwwkeEUSwHXa
	 unqQgtB0mS8pg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1749734943; x=1749995443; i=ngoc-tu.dinh@vates.tech;
	bh=HCCC2WMnOuHQR2vZ/NmiQkkCDP/l5lJNiSzzhcJK0mc=;
	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=fElo6skgI7iic7d4XIg6H2UuwzcNHOubJHXenKv+QoY5YEUL2JTyJbxB6xK9bKlBD
	 sIUKu+4TtfETYRy8MC0wHhxgTWNk6LHxPFk/V1U/qLQW51ksj5X/m5qalz4Txr5HlW
	 VatsSkk7sEYYOXvYonMl3jY+VR3OG3VqCMRL4SbVvlw4sCKkoj47u75TqKcgz79iKS
	 TyDH8TVNV8a6thBUt+8ttQyCOjLIEi57vG/N1NHr79IC+xCoN0xvBJvd01nA+JfZfF
	 7MGHg7xQ8rn/wxoKQPcbQD95Y6E7PpsSH/lmL/2vtzIBfVteyPXc3Rs1eaBDxPJ6be
	 cB7jCOZV5oGbQ==
From: "Tu Dinh" 
Subject: =?utf-8?Q?Re:=20[PATCH]=20docs:=20UEFI=20Secure=20Boot=20security=20policy?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1749734941416
Message-Id: 
To: "Jan Beulich" 
Cc: "Anthony PERARD" , "Michal Orzel" , "Julien Grall" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Stefano Stabellini" , "Juergen Gross" , "=?utf-8?Q?Marek=20Marczykowski-G=C3=B3recki?=" , "Trammell Hudson" , "Ross Lagerwall" , "Frediano Ziglio" , "Gerald Elder-Vass" , "Kevin Lampis" , Xen-devel , "Andrew Cooper" 
References: <20250611235851.167385-1-andrew.cooper3@citrix.com> <4226d6ef-a1eb-4210-8cae-2b9b2d906d1c@vates.tech> <53e8cacd-e035-47ca-906e-35f748559328@suse.com>
In-Reply-To: <53e8cacd-e035-47ca-906e-35f748559328@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.12da2aeb48284cfca2696e3222faaa34?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250612:md
Date: Thu, 12 Jun 2025 13:29:03 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 12/06/2025 15:22, Jan Beulich wrote:
> On 12.06.2025 15:15, Tu Dinh wrote:
>> On 12/06/2025 02:03, Andrew Cooper wrote:
>>> +Secure Boot Advanced Targeting
>>> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> +
>>> +SBAT is a recovation scheme for Secure Boot enabled components, using a
>>> +generation based scheme.  See `Shim SBAT.md
>>> +`_ for full details.
>>> +
>>> +Upstream Xen provides the infrastructure to embed SBAT metadata in
>>> +``xen.efi``, but does not maintain a generation number itself.  Downstreams
>>> +are expected to maintain their own generation numbers.
>>> +
>>
>> Why would Xen not maintain its own SBAT generation? An upstream SBAT
>> incremented for every Secure Boot bypass XSA would make it far easier to
>> block vulnerable variants and help downstreams coordinate fixes.
> 
> Quoting from the SBAT patch that was submitted a little while ago:
> 
> "The SBAT section provides a way for the binary to declare a generation
>   id for its upstream source and any vendor changes applied."
> 
> That is, the generation ID is per-vendor. Upstream incrementing whatever
> ID would be meaningless to downstreams then. Hence we can as well not do
> so in the first place.
> 
> Jan

Don't Shim, Grub and Linux all have their own upstream SBAT generation? 
The Shim SBAT documentation explicitly pointed this out:

 > Each component is assigned a minimum global generation number. 
Vendors signing component binary artifacts with a specific global 
generation number are required to include fixes for any public or 
pre-disclosed issue required for that generation. Additionally, in the 
event that a bypass only manifests in a specific product's component, 
vendors may ask for a product-specific generation number to be published 
for one of their product's components. This avoids triggering an 
industry wide re-publishing of otherwise safe components.

IOW Xen should have its own upstream generation ID for any vulnerability 
that leads to a Secure Boot bypass. Any vendor that patches such a 
vulnerability can simply increase the upstream generation ID it carries 
in its SBAT to that of the latest Xen. Then any inferior upstream 
generation can simply be revoked to cover all vendors at once.

Best regards,


Ngoc Tu Dinh | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Thu Jun 12 13:31:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 13:31:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013106.1391648 (Exim 4.92)
	(envelope-from )
	id 1uPi1q-0001kj-Rj; Thu, 12 Jun 2025 13:31:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013106.1391648; Thu, 12 Jun 2025 13:31: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 1uPi1q-0001kc-P0; Thu, 12 Jun 2025 13:31:38 +0000
Received: by outflank-mailman (input) for mailman id 1013106;
 Thu, 12 Jun 2025 13:31: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 1uPi1o-0001kU-UE
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 13:31:36 +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 8f4e618b-4791-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 15:31:35 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3a536ecbf6fso617501f8f.2
 for ; Thu, 12 Jun 2025 06:31:35 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-748809eb13asm1391814b3a.112.2025.06.12.06.31.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 06:31:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8f4e618b-4791-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749735094; x=1750339894; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=qq6S9h5T01twzjul/UWz2fdAc+3LMZDieCEV+WCtWhw=;
        b=KWkJnZQBN14DBMW9rwQlX27zrvvjNc2pO9inLKd6y2puddJm2G5ZT3ZMXMMweqTqyr
         PjXbnqgRC4oS1A84WD+m+aCwvshLd4lBgfv2jSLq4bNim8nMskomY+eRjm/sb8DB/gNm
         rHXH2MNP00fFzyuVicLKR+VpLvrAClaHaNc6LgD+nQWJpxCKMUClchEbAQ4YVrAVvV9A
         0eCBZiRiVpouDv4NNcuZKp+YsVbGqSJp3czhbOeA7pl7uBSYPljBVHGRajeyX6EdGopH
         Ebj3PnR27q2xHL7RDWdUnJGSukFCLjy8CAXdhPsv28N3I1MJrwp2DVT4es9d3qe/OYMt
         YRDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749735094; x=1750339894;
        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=qq6S9h5T01twzjul/UWz2fdAc+3LMZDieCEV+WCtWhw=;
        b=o0ItM4ujzhbVkO2M2pilo5U6kK0YpWygeuBCBtnrvWXD/hGoGNo7Qz6mLThbdrRVkZ
         GyDA/5AzLzOICTUWiOhgtteUa/98qc6CoHBX7tkT/IORRPi9r5Ut99X925uZuVEf2DJE
         oU0xvfWzd27KK/Z6OWE9FCb2GqTjKo95MsHejGT+UmTfkXrCmr6rMDP5fTi0L3yn1OaB
         yK+wIz7oJW3Y8wG4EGqBiK9c60/F70wG1DHzrCCuxn+FiCRrzoWWpGTQxfoRZvI+ZR9z
         kyV974UbdGEN4EWIi+P8l4JoJGPIZJF3FVGMmKbZCjyhGqDkmgroVVF8HIt0tr7RaR/6
         0bRw==
X-Forwarded-Encrypted: i=1; AJvYcCUQ0X4NMLhgl7wc8rnuDgxFsAWnVcdE6ZqYEEI3yROIOis4I5Lpb/tglZKX2k5bd+Gy8srFBcP6K2I=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzmJGhipD1flvMTwCZNIN165olvLFuoERkKSToDS8v4A8soECrG
	wZpBHNedbVjtPJMpYrCdh0qmCBSlk3YEJ8tQ5fuXntjpxeE/EOQrcuNkyxJrrZOkctIu1iBQgXK
	pJJE=
X-Gm-Gg: ASbGnctlEtXWHbuyjQNhNNh44WNIruYFrYPeBEWvBikzkp4G6gOQK0mgnpaABKgVDM9
	/n+xQLGO73DIdxu1FqLY+3NA5iNMOZLGKp293sQ1Xjtb5MGFByMN294vBa1EkAbEe1jFUCqDfeH
	90TjkfYxiU0BvwBfym9fQlh9Y9mkGuEDPXxj6puyVDIlJP8OKwvWy8FJpzp5RN1Rh5fh6IcHG5F
	X3VvC0G2TF4fcB3vk0uO0PbzQ7+8/CC1C2ZisYQxMznsN5/OKOCVf3IXZWjywcFfbu5o1hV4ZPr
	BEZE7tD7WElDtaB9I+vCuMJ7FoWNKIXogMVA+SXfLfRw22hMSJ6sKv02DQZxEmfWj6F4GuGIXxq
	JsD6ltfs08SpmlH1NQTvKyTYZgIKQMfW0JxhUDF3I0uiUzEo=
X-Google-Smtp-Source: AGHT+IFSMS3Cq6un6OZsp1HxW61vpEVJPvOld8jyRaiXrcd+//TfB36ljkxJudN+8GEkNA/p/KPXsw==
X-Received: by 2002:a05:6000:250a:b0:3a3:621a:d3c5 with SMTP id ffacd0b85a97d-3a558695c54mr5658629f8f.19.1749735094426;
        Thu, 12 Jun 2025 06:31:34 -0700 (PDT)
Message-ID: <8100bb94-2461-4a03-ae06-3e395036d4e7@suse.com>
Date: Thu, 12 Jun 2025 15:31:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 17/18] tools: optimize cpufreq average freq print
To: Penny Zheng 
Cc: ray.huang@amd.com, Anthony PERARD ,
 xen-devel@lists.xenproject.org
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-18-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: <20250527084833.338427-18-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.05.2025 10:48, Penny Zheng wrote:
> Unlike Cx/Px states, for which we need an extra loop to summerize residency (
> sum_cx[]/sum_px[]), we could call get_avgfreq_by_cpuid() right before printing.
> Also, with introduction of CPPC mode, average frequency print shall
> not depend on the existence of legacy P-states, so we remove "px_cap"
> dependancy check.
> 
> Fixes: add6160d7 (Add cpufreq actual average freq information to xenpm tools)

Unlike in earlier instances, here you have a fixes tag when the title merely
says "optimize". I also can't spot any bug that would be fixed here; what you
address is indeed an inefficiency.

As and aside: The Fixes: tag wants 12 digits of the hash quoted, and the
canonical form also has the title in quotes. You'll find numerous good
examples in patches being submitted.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 13:39:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 13:39:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013111.1391658 (Exim 4.92)
	(envelope-from )
	id 1uPi9M-0002Qm-KC; Thu, 12 Jun 2025 13:39:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013111.1391658; Thu, 12 Jun 2025 13:39: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 1uPi9M-0002Qf-GV; Thu, 12 Jun 2025 13:39:24 +0000
Received: by outflank-mailman (input) for mailman id 1013111;
 Thu, 12 Jun 2025 13:39: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 1uPi9K-0002P2-8z
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 13:39:22 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on2062a.outbound.protection.outlook.com
 [2a01:111:f403:2418::62a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a4469b7a-4792-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 15:39:20 +0200 (CEST)
Received: from MN2PR05CA0017.namprd05.prod.outlook.com (2603:10b6:208:c0::30)
 by CH1PPF5A8F51299.namprd12.prod.outlook.com
 (2603:10b6:61f:fc00::60f) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.23; Thu, 12 Jun
 2025 13:39:16 +0000
Received: from BN1PEPF00006001.namprd05.prod.outlook.com
 (2603:10b6:208:c0:cafe::b0) by MN2PR05CA0017.outlook.office365.com
 (2603:10b6:208:c0::30) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.19 via Frontend Transport; Thu,
 12 Jun 2025 13:39:16 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BN1PEPF00006001.mail.protection.outlook.com (10.167.243.233) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Thu, 12 Jun 2025 13:39:16 +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, 12 Jun
 2025 08:39:15 -0500
Received: from [172.26.5.4] (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 Jun 2025 08:39:14 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a4469b7a-4792-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=f/zNeGFgIV6OdyjTp+NOMZMZIHrbbbJC1PS1rfF7TECqnPzDpCBoeu/SyLuZTa8dLSjqZ1GHm0fhX22GkBysYTghgG29CxhtMTBLl2PyGDsGZdi/AhNdQbETp4GR2VPWsbYFvqhuWhKeKgr88vrauSHwWUi4te4snSYfyaqZVIDsFUbX9M76plFwElV+Rr2skGCsy22LXp2MphlR3N8ERDXXfs6ZfKlRgZ9PlyYxVOK65Tr/xkNb0TMbthue9Qn3Jat8S36AOf+AWszaS0zU6SbsnWEHCwK3+JQAWGJUewaKWluBJ29/LF0qSWisROLZ8o/wN1fuFj0bzCPKksgJDw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=XvAT/c0VKDKjk7ZT131qrDxyqcca2fj89igx5iZZwJw=;
 b=DG+VBMchVmE5JnNWovaW4RY/cS7msplRkOCGTbq/FSVhDyIjVK79R7+NZteFsDCoKJoakTTiAsC/stSW7Sgc4dZN6gDf1kO+OxvvwQshqw+aZ++dBKL8re5U3HeYkVQjRgOrd58eyBefFRI872vodhFnHzW7VyhOrDVzIAGoWf2s0+HcN97vNVd3ywNL+UK2qdlbvc4PvEk3OCNdyoo+u0SyxxeGvYhKFP07yd/PUQEyMOq5bkYJpychumsJISkUmg6zhZRnNMzTKzXZhwcrt+BgDEzzxnM+q+zoUSxjTdeoFhs1KIs2OBt+tnafMEU8K34GVqkE3Po/0kAWej3LVA==
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=XvAT/c0VKDKjk7ZT131qrDxyqcca2fj89igx5iZZwJw=;
 b=OoFXcDOYaAFc32yPF08WthCnqSA3eddCnwBmTnO5GHLlz2qdufCIV0C2i7G/GvCykjDjhzGvHl1MU6sj+ZvcVGe/8c2RzL0VDsXOJim5KyREVGXBEuWDvhndVuWm6dapXB5eDEDhB9jiHjXSOtJPkm8tqSU47X2nVnridCm92xM=
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: <3a203b96-94e3-47c3-92b6-b68141ea3794@amd.com>
Date: Thu, 12 Jun 2025 09:39:13 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7] xen/arm: pci: introduce PCI_PASSTHROUGH Kconfig option
To: Jan Beulich 
CC: Rahul Singh , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	, Andrew Cooper , "Stefano
 Stabellini" , 
References: <20250610174635.203439-1-stewart.hildebrand@amd.com>
 <6ac8ffbc-5bd3-4bea-9ade-f31710747291@suse.com>
Content-Language: en-US
From: Stewart Hildebrand 
In-Reply-To: <6ac8ffbc-5bd3-4bea-9ade-f31710747291@suse.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
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: BN1PEPF00006001:EE_|CH1PPF5A8F51299:EE_
X-MS-Office365-Filtering-Correlation-Id: 475aebdc-d242-4e45-3173-08dda9b6866d
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?UW02T1dnQW52TlNKN1Z1dSswajVRZFFhVnR6MHFMeTdLLzd1NVJCOW0rV3hl?=
 =?utf-8?B?WFl1MVNQVDBXZ3JhYTVPdCtkc1RxL2VyeU5STHprZERlY0J3b0JpV2wwaFpT?=
 =?utf-8?B?SkZBY0ZTUE92YllFMy9kMzJ6am9PcS8yYlVwSU5kc000TkRNdzd6TjNwbGlY?=
 =?utf-8?B?dkxNL1pETFFSMFM2OFdCeG1xK1N1dHJtUlE2VXZzbTVDTEs4T2thUkxTb0JN?=
 =?utf-8?B?a2pGdTdYWFIvenpKNDhhYjY3ZG45dGRCQ0xoS0RLeGFRNDdpditTRmFRb1Jn?=
 =?utf-8?B?YjV0dHlmNVpUdlJKQUVHQytGVTdOYWhhSHgrQWN5WmQ4bkFEM2tKR0k3MUNz?=
 =?utf-8?B?dmE3WHFFbVM1eVQxQndYbjJPQ3I1TlVWU2VON1o1MGx0YnVmU0xFTDNySGZi?=
 =?utf-8?B?WjQ2azhlRTJCLytUbXlXK1V5dmVDamtNanhvM0tJQjAzaUdQbHVmUUoydEJq?=
 =?utf-8?B?clVXSkdPUFM2d2pzaTVzV2NwWVlESDNpQWFycVlST2xObHNFYVlLeE90OW5K?=
 =?utf-8?B?clorcmNZQU42NUFZSXMyREpWeFNDL2ROQnNRNWVjSE9KTUpjK1VaZkVrTHRn?=
 =?utf-8?B?QjF6L2VWOSs3eTAvMjBZSHZ6Tkdoc0hCN2J0YnVmdnpqeTIwdENEcitkRlNy?=
 =?utf-8?B?UjhlWTA2RE5PVlBBUzRtMFhEM0RiMkR5czZsbEtoUmN6YXJmSUVBcVRUTVFw?=
 =?utf-8?B?MENBdkdXMzBkWllweG9wVnhpTUFNRzVKWGwzK3JWeVJiTTlQK3lXQ09KTHVC?=
 =?utf-8?B?dW9vZlFVVkNSbGJIU3JUS20xOEZsTHozdmVvT1dhZDF5WEFYSjNnVmpVd3Iy?=
 =?utf-8?B?S3B3bXl1c1Z2U1g5RExnY0krZVltTnNRQ29WRUptUGIzVDZadzQzWnhTelhS?=
 =?utf-8?B?UDdnU3FodEtlQ1g1VGVsQ3c0R1BaUmMyYU5sUTlRTHdPNVNqeXM2MXArNTNa?=
 =?utf-8?B?bS9TVk11Z0hUZTF2ZkFtVE1WN210dnRnMFBJK21XalJ6Wkk2SzdJL1diQlRM?=
 =?utf-8?B?NjFBeDhMRGlWUEZhNWU1bUFtMWNZeTVpUGk0U1hac2k5OStrWVcvS3FETVBk?=
 =?utf-8?B?SzdVWmxnU2lxaHR6Ums2Y0lFVUlVU0RqaXE3NUorcFVwU3RIUXBpaG14MXM0?=
 =?utf-8?B?b1JOUk1xd3g3WHhwTjhTajFzRk43eVFlUjlsT0x6RHF5am1tKzJCNGhwOFhN?=
 =?utf-8?B?Zi9tbmhhWjczNkJLa3RibmN1MktlZmVSNUsrb0lrbXMxTDQyZTBiNGJNME9r?=
 =?utf-8?B?OUszTkhjei9zelNRbm8rcGx3M3E0QUFuSzRDY0Uwd3lHT0RHWFRlUkRMYTdB?=
 =?utf-8?B?K2hHMFdvZDZsMlgxSjBNOWlETUNudHVvajFnaUU4ak5UTk9YTTJsRFpreDZG?=
 =?utf-8?B?V1M3UEtSMWpDNHF1bjE5K21leWVodGNMVVJ4dEVkSm5QZGlRTG8xSzNxYVY0?=
 =?utf-8?B?TnA3emVqb1lINmVpWlNhVm85YlpIWjk5WnpXZS9ieEQ1WTdDMG9qVUV0NDlY?=
 =?utf-8?B?cFlKYXMvQlQyTWxQTDBNVzBScXN6a2c0SWRqM0VGeTFSY2x4K2JiVk5Ub1pS?=
 =?utf-8?B?VTJnL0NXbkVXN3pkOUV2NTdsaHkvbFVwQSt3YkRCT2MzekFaZzJVWXd2bC9a?=
 =?utf-8?B?MjNBM0J6QTQydUhCTk0yeDdsaGZEaGNIQjd6WFBaY05jR1FzK0d3eE4xT1hP?=
 =?utf-8?B?ZlpPNy95M1ZSdEZ3LzhhMkY0clo3cGdFQmdldUpHQnhlUGY3U1dWMXQzbmU4?=
 =?utf-8?B?enNmWnJyQkZQWmtZeVJHRTJaS2lIVERkR21ZWU5kcm5ObXVnNE5nMzR5Wk9a?=
 =?utf-8?B?bVY5Zk5RNTZuc25vbVVqUXBRNHB3YnFjY2hNSkpOY1owUXJ4UlFnNitwa3RX?=
 =?utf-8?B?K21UaUwyTXZMZVY5bXJPSGUwMTRlaksxOGhBc3lGTERTaXk0MGRIOUYyYTcx?=
 =?utf-8?B?Z3FNYlgyUkxSNllPN0RmQzE3ZTloNnkwdlRwY3VIOXdHUU0vT1BmTjI0cVZZ?=
 =?utf-8?B?Nk5FeGd3bHdOWGxkRlhwdHB2MDNOanlkQnE3OVRUUzY2NFZxcDBPT3pQeC9t?=
 =?utf-8?Q?6nu7Xn?=
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: 12 Jun 2025 13:39:16.0390
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 475aebdc-d242-4e45-3173-08dda9b6866d
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:
	BN1PEPF00006001.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH1PPF5A8F51299

On 6/11/25 01:23, Jan Beulich wrote:
> On 10.06.2025 19:46, Stewart Hildebrand wrote:
>> --- a/xen/arch/arm/Kconfig
>> +++ b/xen/arch/arm/Kconfig
>> @@ -258,6 +258,16 @@ config PARTIAL_EMULATION
>>  
>>  source "arch/arm/firmware/Kconfig"
>>  
>> +config PCI_PASSTHROUGH
>> +	bool "PCI passthrough" if EXPERT
>> +	depends on ARM_64
>> +	select HAS_PCI
>> +	select HAS_VPCI
>> +	select HAS_VPCI_GUEST_SUPPORT
> 
> What about HAS_PASSTHROUGH? Seeing that being selected by MMU, what about
> that connection here?

Hm, yes. I'm not sure if depends or select would be better?

	depends on ARM_64 && HAS_PASSTHROUGH

or

	select HAS_PASSTHROUGH

> Selecting HAS_VPCI shouldn't really be necessary; HAS_VPCI_GUEST_SUPPORT
> does that for you already. (I further wonder whether HAS_VPCI wouldn't
> in turn better select HAS_PCI.)

I'd be happy to make these changes.

>> +	default n
> 
> This is unnecessary (redundant) and would hence better be omitted.

OK, I'll remove it.


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 14:04:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 14:04:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013119.1391667 (Exim 4.92)
	(envelope-from )
	id 1uPiX8-00073D-E1; Thu, 12 Jun 2025 14:03:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013119.1391667; Thu, 12 Jun 2025 14: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 1uPiX8-000736-BS; Thu, 12 Jun 2025 14:03:58 +0000
Received: by outflank-mailman (input) for mailman id 1013119;
 Thu, 12 Jun 2025 14:03: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 1uPiX7-000730-3n
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 14:03:57 +0000
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com
 [2a00:1450:4864:20::332])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 111e141b-4796-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 16:03:50 +0200 (CEST)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-450cfb790f7so7564675e9.0
 for ; Thu, 12 Jun 2025 07:03:50 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-4532dea1cc5sm22582545e9.16.2025.06.12.07.03.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Jun 2025 07:03:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 111e141b-4796-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749737030; x=1750341830; 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=RCVDXFdGDko2BotlFIEfY7jNVsR9BhRUMi+viB5wR3I=;
        b=eKlchSa7UFLwcFd9GO82X02yb4CDcuq/9xOxuis6lA7NkF7cyF1eRFmVlgNU8toS4O
         uGZY4iv+drcGmTd5YovrSRuVTQFGVXKN52hu6uiRVE7rGPSQxNOBj3S3ofix9/gjJQjG
         UKja6N6vgIX/nxB9tokHU95RZjYA57Etj1Rek=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749737030; x=1750341830;
        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=RCVDXFdGDko2BotlFIEfY7jNVsR9BhRUMi+viB5wR3I=;
        b=mftOw3lMXSDDiNaL23LxdF3nNAgd4xL/WbIiOC7hgEgM4s8mYoCKngNjrxnAEo+ZdB
         6TmT3S8/HtqKBTGHIwJnQwKZ2E+x+5iLngv0Ydthu1j9YdsjWOVnJQt5qnmymjiOEUGu
         zmRaxAmBMd9kmH3cc7A4brGA5rOfW2rF9pG5TvOiJc5n9Ja9BnSfkeYhN+lbvYiBvQEm
         8Hs9SPcm3I4JE0GKHAPd377KyRn0h/AAldNs2fZhD376IHffMReHAoLT6VgskxGHfpA6
         X4v4sf4lCeeI08Ct7mqkEPwypCVDYHdZIiDA7VKbR0OZ3tcraJzlUBwh6MVeM/ze8dgY
         rUTQ==
X-Forwarded-Encrypted: i=1; AJvYcCVIUHrtzpUHVi8n2w0dGBfdTOYFWVeE3OEdNEApM4/ne9X9Nvu4/Bmtjk1KtwPl0nFxWYPFbFDOGUU=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw83prb/bEEudDsMF0kDwl2D59P2If0sB0q7TfgYh+Ak5k+/PaG
	sZk3AMt0VX0UPz5W3aiUUAqiFLmTvNrYIaRXQO8ujRHCMhmhCrNjW77z6yjh/KmQ+L4=
X-Gm-Gg: ASbGncuEjFSC9BWeXly6yklcEBrjLuBPFRJJfY9LyZDtVmmq9oK4cIru7U+4pLyBJKi
	H7PfVJgVYoPImNKp8PzHtUOJmZKB1K2SaYQrBf2A1i1RVzDhmWq4EpOs3QKF18KD/9nlV4AgEuD
	NUUBaDaNcXcnHavVNY92F61onDWlt8WXrg+hBtXlTvb0dFj1ddjN+HIGA1MbizvfABrcir/wX5e
	2rVvMq4u/lGk7SHqmXBeRWGTeXy20nITV5R2wph/Ex4xQHr1LuvB0G2jKaFGGy1U6XeqN3Gd9Y9
	ITdgwv1khJV1i5YODfnlFqpremc4V4H0kggaWoZQ8cB5DO5vpxjG0h0sMn476058qAXZwNo4KNh
	1sIhNn3QdRgUAKJ1wAF8gacQtFSEmOFz2mwdhhh4zfYvi2Q==
X-Google-Smtp-Source: AGHT+IGHhI+JyytbDaqgc2ZvvPAo9DqkYI+Y0QFnBPZA3TEsAOXt8ICiZS+X4yo3W2JNNAgJGgIKRA==
X-Received: by 2002:a05:600c:314b:b0:442:e9eb:cba2 with SMTP id 5b1f17b1804b1-453247d6b1dmr81629585e9.0.1749737028408;
        Thu, 12 Jun 2025 07:03:48 -0700 (PDT)
Date: Thu, 12 Jun 2025 16:03:46 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Anthony PERARD ,
	Andrew Cooper ,
	Michal Orzel , Julien Grall ,
	Stefano Stabellini ,
	Bertrand Marquis ,
	Volodymyr Babchuk ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 6/8] pdx: introduce a new compression algorithm based on
 offsets between regions
Message-ID: 
References: <20250611171636.5674-1-roger.pau@citrix.com>
 <20250611171636.5674-7-roger.pau@citrix.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 

On Thu, Jun 12, 2025 at 10:27:03AM +0200, Jan Beulich wrote:
> On 11.06.2025 19:16, Roger Pau Monne wrote:
> > With the appearance of Intel Sierra Forest and Granite Rapids it's not
> > possible to get a production x86 host wit the following memory map:
> > 
> > SRAT: Node 0 PXM 0 [0000000000000000, 000000007fffffff]
> > SRAT: Node 0 PXM 0 [0000000100000000, 000000407fffffff]
> > SRAT: Node 1 PXM 1 [0000061e80000000, 0000065e7fffffff]
> > SRAT: Node 2 PXM 2 [00000c3e80000000, 00000c7e7fffffff]
> > SRAT: Node 3 PXM 3 [0000125e80000000, 0000129e7fffffff]
> > 
> > This is from a four socket system, with each node having 256GB of memory.
> > The total amount of RAM on the system is 1TB, but without enabling
> > CONFIG_BIGMEM the last range is not accessible, as it's above the 16TB
> > boundary covered by the frame table.
> > 
> > Note that while the memory map is very sparse, it won't be compressible
> > using the current algorithm that relies on all ranges having a shared
> > zeroed region of bits that can be removed.
> > 
> > The memory map presented above has the property of all regions being
> > similarly spaced between each other, and all having also a similar size.
> > This allows to compress them using the following formula:
> > 
> >  pdx = (pfn % offset) + ((pfn / offset) * size)
> > 
> > Where offset and size are two static coefficients calculated at
> > initialization.
> 
> What I would find useful here in addition would be offset and size values
> resulting from the example memory map above. In particular, without looking
> at the code in detail, it doesn't become quite clear how the two ranges on
> node 0 are being dealt with. For what follows I'll assume they'd be folded
> into a single range covering all of node 0.

Indeed, they are folded into a single range, that's why the function
to register ranges takes an ID, so that for this algorithm ranges with
the same ID are folded together.

For the above example the offset (pfn based) is 0x63e80000 and the
size 0x8300000.  You can see those (and for all the other examples) on
the test-pdx-offset.c file.

> Along the lines of Andrew's concern regarding the division (and modulo)
> involved, I wonder whether there might be an alternative with a lookup
> array, holding bias values (e.g.) for each node. Main question there would
> be how to quickly determine the array index to use, both from an incoming
> MFN and an incoming PDX. If such an array wouldn't have too many entries,
> such a lookup may end up being faster (on average) than a division.
> 
> Taking the example above, such an array could be:
> 
> [0x00] = 0,
> [0x06] = 0x061e80000 - 1 * 0x5000000,
> [0x0c] = 0x0c3e80000 - 2 * 0x5000000,
> [0x12] = 0x125e80000 - 3 * 0x5000000,
> 
> indexed by the top-so-many bits of the MFN. For the reverse array some
> gap would need to be left between ranges (i.e. the 0x5000000 above would
> perhaps need doubling; maybe a little less than that would suffice), such
> that the array slot to use could be determined easily there as well.

I've assumed that any kind of lookups like this would end up being
slower than arithmetic transformations.  I had the (maybe wrong)
impression that having to fetch the adjustment from an array based on
a calculated index would result in slower code that using constant
coefficients.

I was also worried about the extra memory consumption of this
approach, but overall we can use a full page for the lookup table,
which would allow up to 512 entries and that should be more than
enough.

I can try to code this suggestion.  However it's hard to benchmark
those algorithms, as the cost of rdtsc shadows the cost of the
operation.  Then running the translation in a tight loop and averaging
the result also doesn't seem very realistic, as the cache is hot in
that case.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 14:56:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 14:56:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013191.1391706 (Exim 4.92)
	(envelope-from )
	id 1uPjLp-00069R-JV; Thu, 12 Jun 2025 14:56:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013191.1391706; Thu, 12 Jun 2025 14: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 1uPjLp-00069K-Fd; Thu, 12 Jun 2025 14:56:21 +0000
Received: by outflank-mailman (input) for mailman id 1013191;
 Thu, 12 Jun 2025 14:56: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 1uPjLn-00069E-V3
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 14:56:19 +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 658afb1a-479d-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 16:56:18 +0200 (CEST)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-4530921461aso9573565e9.0
 for ; Thu, 12 Jun 2025 07:56:18 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-4532de8c50esm23272785e9.4.2025.06.12.07.56.17
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Jun 2025 07:56:17 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 658afb1a-479d-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749740178; x=1750344978; 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=RzAxw4g7I4dYiT8/iJYFidK4yM4v8KtCoZu0xbs4GfI=;
        b=rFXga8T5goTgjjtNlB+91rmnfOkiOko3jVTJMPpJPX09oLYdW7pq9Kqcs4a8z1/1cS
         MXygWEDruLpTq/MPwgecjDFo2N2tPFMY9PnsHhfDw3x+GhBVJjNf+RGKvJxgrAiOdbHE
         irbw3GNhxQhFU2pGmMRt10hi26sBJfn/zDFhw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749740178; x=1750344978;
        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=RzAxw4g7I4dYiT8/iJYFidK4yM4v8KtCoZu0xbs4GfI=;
        b=R3plwN/N0oC/QUJdg62eDzRo73GPVzVgKvETi6EvRdEX6M3UAPZOFSs+6c5YGDLsbr
         yHXh9jHzaiKvx7ipTIYB+d2qfxhTG0YOYH8xaDvrVaE+h8NXpu9NcBvnXM/LLNncq3Rh
         G+3/kDIAtHVZyLfg5j2vPKe4VsHT02wwfr+q4YXH7J4e8n/fXKQ9XBbgdf1uK7EHXcHj
         F4yyRPhPrnlBWvEcGcrtWPsuLbIRiScspoD9BG58I4HcNUVNlvfpta0Vkg7jvayujtxr
         584ru3KTxThR2jmlMuluYf4LDeb0cy8cjJfIYD3tN18/Sq/FF8IssUfIsPQaefIFwclH
         kQcA==
X-Gm-Message-State: AOJu0YwqKRRziWvZ3opawvnTl4/S4B2fghej506A2/l4UEk3k3b9Bkwo
	73nvPINI+HzG/oAmWfnPzu0mhqlvZpnYj3hSqMwa3CZPrl/kUbVWmSXWsDfuuVrrHFE=
X-Gm-Gg: ASbGncuOAzn7FkjLt+L7h5496nhUJ+3qQNTEa2ItEjon7n1vrVq5DqNdA1+ZD+pqs/g
	AMGnvZqf7LoIkLDKXq0poXUEhWvtF3I05IcPzmV6eqIlFzTpP6hxTqRrtayDn+Fc6jvUrBIwwma
	o0NPSPkGJSAHqv+zI5uEay6rRWVIeb2bqvelVSra/IqADfr0y1O9QNBxt24LCMbVbCL+cqDU8tF
	TRSMrcJGOKfLahyEHReKoGLQmy5Th95vuc9rUJ2b4O3kZ2PRiaX1R2N7kOmstZphBzfx5Srx+qP
	GSgSLaX6cAAS/rywRlZOHTg83AqGv/4wY/CbZBHSfoSCc06adjPrVpBYsSRO9gjxmznfN5e/DrT
	Dg//4u0bTGhKECcAUnPWRe9P9TIKteL119MM=
X-Google-Smtp-Source: AGHT+IGnToZ44MVthPVSE7NpRGPmQKCl0CMCdOn5DcQwfzy3zXlGLAERhGMcKm8e7vyZepR+WeJrVg==
X-Received: by 2002:a05:6000:22ca:b0:3a3:648e:1b74 with SMTP id ffacd0b85a97d-3a558691a65mr6125896f8f.6.1749740178104;
        Thu, 12 Jun 2025 07:56:18 -0700 (PDT)
Date: Thu, 12 Jun 2025 16:56:17 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Anthony PERARD 
Cc: xen-devel@lists.xenproject.org,
	Oleksii Kurochko ,
	Community Manager ,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini ,
	Juergen Gross ,
	Anthoine Bourgeois 
Subject: Re: [PATCH v4] x86/hvmloader: select xenpci MMIO BAR UC or WB MTRR
 cache attribute
Message-ID: 
References: <20250610162930.89055-1-roger.pau@citrix.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 

On Wed, Jun 11, 2025 at 07:26:06PM +0200, Anthony PERARD wrote:
> On Tue, Jun 10, 2025 at 06:29:30PM +0200, Roger Pau Monne wrote:
> > diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> > index c388899306c2..ddbff6fffc16 100644
> > --- a/docs/man/xl.cfg.5.pod.in
> > +++ b/docs/man/xl.cfg.5.pod.in
> > @@ -2351,6 +2351,14 @@ Windows L.
> >  Setting B with the default device_model "qemu-xen"
> >  requires at least QEMU 1.6.
> >  
> > +
> > +=item B
> > +
> > +B Select whether the memory BAR of the Xen PCI device should have
> > +uncacheable (UC) cache attribute set in MTRR.
> 
> For information, here are different name used for this pci device:
> 
> - man xl.cfg:
>     xen_platform_pci=
>         Xen platform PCI device
> - QEMU:
>     -device xen-platform
>     in comments: XEN platform pci device
>     with pci device-id PCI_DEVICE_ID_XEN_PLATFORM
> - EDK2 / OVMF:
>     XenIoPci
>         described virtual Xen PCI device
>         But XenIo is a generic protocol in EDK2
>     Before XenIo, the pci device would be linked to XenBus, and
>     loaded with PCI_DEVICE_ID_XEN_PLATFORM
> - Linux:
>     Seems to be called "xen-platform-pci"
> 
> Overall, this PCI device is mostly referenced as the Xen Platform PCI
> device. So "xenpci" or "Xen PCI device" is surprising to me, and I'm not
> quite sure what it is.

I can do xen_platform_pci_bar_uc, but it seems a bit long.

> 
> > +
> > +Default is B.
> > +
> >  =item B or B
> >  
> >  The groups of Microsoft Hyper-V (AKA viridian) compatible enlightenments
> > diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
> > index cc67b18c0361..cfd39cc37cdc 100644
> > --- a/tools/firmware/hvmloader/pci.c
> > +++ b/tools/firmware/hvmloader/pci.c
> > @@ -116,6 +116,8 @@ void pci_setup(void)
> >       * experience the memory relocation bug described below.
> >       */
> >      bool allow_memory_relocate = 1;
> > +    /* Select the MTRR cache attribute of the xenpci device BAR. */
> > +    bool xenpci_bar_uc = false;
> 
> This default value for `xenpci_bar_uc` mean that hvmloader changes
> behavior compared to previous version, right? Shouldn't we instead have
> hvmloader keep the same behavior unless the toolstack want to use the
> new behavior? (Like it's done for `allow_memory_relocate`,
> "platform/mmio_hole_size")
> 
> It would just mean that toolstack other than `xl` won't be surprised by
> a change of behavior.

My plan was that we didn't need changes to XAPI to implement this new
mode, but given the comment I will change to keep the previous
behavior in absence of a xenstore node.

> 
> >      BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_IO !=
> >                   PCI_COMMAND_IO);
> > @@ -130,6 +132,12 @@ void pci_setup(void)
> >      printf("Relocating guest memory for lowmem MMIO space %s\n",
> >             allow_memory_relocate?"enabled":"disabled");
> >  
> > +    s = xenstore_read(HVM_XS_XENPCI_BAR_UC, NULL);
> > +    if ( s )
> > +        xenpci_bar_uc = strtoll(s, NULL, 0);
> > +    printf("XenPCI device BAR MTRR cache attribute set to %s\n",
> > +           xenpci_bar_uc ? "UC" : "WB");
> > +
> >      s = xenstore_read("platform/mmio_hole_size", NULL);
> >      if ( s )
> >          mmio_hole_size = strtoll(s, NULL, 0);
> > @@ -271,6 +279,44 @@ void pci_setup(void)
> >              if ( bar_sz == 0 )
> >                  continue;
> >  
> > +            if ( !xenpci_bar_uc &&
> > +                 ((bar_data & PCI_BASE_ADDRESS_SPACE) ==
> > +                   PCI_BASE_ADDRESS_SPACE_MEMORY) &&
> > +                 vendor_id == 0x5853 &&
> > +                 (device_id == 0x0001 || device_id == 0x0002) )
> 
> We don't have defines for 0x5853 in the tree (and those device_id)?
> Maybe introduce at least one for the vendor_id:
> 
> These two names are use by QEMU, OVMF, Linux, for example.
> 
> #define PCI_VENDOR_ID_XEN           0x5853
> #define PCI_DEVICE_ID_XEN_PLATFORM  0x0001
> 
> There's even PCI_DEVICE_ID_XEN_PLATFORM_XS61 in Linux

You mean in the public headers?

For Device IDs we have ranges allocated to downstream vendors, I'm not
sure we want to keep track of whatever IDs they use for their devices.
OTOH, not tracking those IDs here means OSes are likely to miss
additions of new Xen platform PCI devices?

I could introduce public/pci.h to contain those IDs, but I would like
consensus on what should be there, otherwise this patch will get
stuck.

> 
> > diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
> > index 79c0e6bd4ad2..31b4411db7b4 100644
> > --- a/tools/firmware/hvmloader/util.c
> > +++ b/tools/firmware/hvmloader/util.c
> > @@ -867,7 +867,7 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
> >          config->table_flags |= ACPI_HAS_HPET;
> >  
> >      config->pci_start = pci_mem_start;
> > -    config->pci_len = pci_mem_end - pci_mem_start;
> > +    config->pci_len = RESERVED_MEMBASE - pci_mem_start;
> >      if ( pci_hi_mem_end > pci_hi_mem_start )
> >      {
> >          config->pci_hi_start = pci_hi_mem_start;
> > diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_create.c
> > index 8bc768b5156c..962fa820faec 100644
> > --- a/tools/libs/light/libxl_create.c
> > +++ b/tools/libs/light/libxl_create.c
> > @@ -313,6 +313,7 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
> >          libxl_defbool_setdefault(&b_info->u.hvm.usb,                false);
> >          libxl_defbool_setdefault(&b_info->u.hvm.vkb_device,         true);
> >          libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci,   true);
> > +        libxl_defbool_setdefault(&b_info->u.hvm.xenpci_bar_uc,      true);
> >          libxl_defbool_setdefault(&b_info->u.hvm.pirq,               false);
> >  
> >          libxl_defbool_setdefault(&b_info->u.hvm.spice.enable, false);
> > diff --git a/tools/libs/light/libxl_dom.c b/tools/libs/light/libxl_dom.c
> > index 4d67b0d28294..60ec0354d19a 100644
> > --- a/tools/libs/light/libxl_dom.c
> > +++ b/tools/libs/light/libxl_dom.c
> > @@ -819,6 +819,15 @@ static int hvm_build_set_xs_values(libxl__gc *gc,
> >              goto err;
> >      }
> >  
> > +    if (info->type == LIBXL_DOMAIN_TYPE_HVM &&
> > +        libxl_defbool_val(info->u.hvm.xenpci_bar_uc)) {
> 
> I think this condition is wrong. You should always write the value of
> xenpci_bar_uc into xenstore, or only write it if a value have been
> selected. But I guess we already lost the information here about whether
> the value is the default or not, and it's probably not important, so I
> think you should always write the value.

Indeed, whether the value is the default or the user-selected one is
lost by the time we get here.

I would adjust according to the above comments, but I would suggest we
leave out the addition of the Xen platform PCI device IDs to a
separate patch, as I fear it will block the patch otherwise.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 14:58:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 14:58:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013205.1391715 (Exim 4.92)
	(envelope-from )
	id 1uPjOF-0006kL-3Z; Thu, 12 Jun 2025 14:58:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013205.1391715; Thu, 12 Jun 2025 14:58: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 1uPjOF-0006kE-0w; Thu, 12 Jun 2025 14:58:51 +0000
Received: by outflank-mailman (input) for mailman id 1013205;
 Thu, 12 Jun 2025 14:58: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 1uPjOE-0006k8-IK
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 14:58:50 +0000
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com
 [2a00:1450:4864:20::32e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id be202eb1-479d-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 16:58:47 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-451d6ade159so9392315e9.1
 for ; Thu, 12 Jun 2025 07:58:47 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-748809eb68fsm1586007b3a.134.2025.06.12.07.58.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 07:58:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: be202eb1-479d-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749740327; x=1750345127; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=HE6XiRpYb7iMAsr7wnjlHDRlYHG+UfPUNERBvtqTOW4=;
        b=IcDggSQ5hiFKmI11jmkyshEydlldn8pKjVNtzmFMSLcIbOsTeWxrP04Bvni5W/yJ5M
         DTsBFo/YrvJec4OF8NAeg9jNN4GYOvsImMlgmEfZJZzV3k9H2bN1b5mwe4VyLAcQbT1z
         lemBjnSRcdXPf4cfKRizlCToXGcgGJZsI0muKvS6gUaQhJKhu8iU76+i0lamt3ZxLNvR
         mRPFNDN5BGbc1iTmgL2CLk5xYiele/rgwABt59yFoKe8cR+FsAkPDI0ungySJVVyDD99
         ps+ARelHSYFwOOHOSJ51lTwHrwOaBTsgT2mwdQ7PHcl0SfWepdFDkfWXp6pRdK9hOB7A
         jZUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749740327; x=1750345127;
        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=HE6XiRpYb7iMAsr7wnjlHDRlYHG+UfPUNERBvtqTOW4=;
        b=KoQye+BGcDDcCvbrkwv4VIE2tYo0Qwf7VxwXlC26vIfoVJi9BLYZgVMjCcAgJDrf+b
         J0NDTz4cc7C3vynFmtlw4MY+X7hElsvWDyh/pACaj+5YYD6xMnkS/gSFf0S9hSk2xgT8
         EZ+v5OC2KG+iz9hUjVQBGPGborqyfycqj6qGA01N9NCAk0ee5xIL8/drjw6NaOcTjtwk
         8EkFvjkMEQ4DTFvLs+6oTeUoR8NnUUDDJv8b0j3SRNa3h6BUcvSv7uLU4jm6Zighfxjn
         EWBS0ComsoS4ZomOoaan4MpIMYjVINRKu0eZ/pqOilysmAxqHb3rL6stLMkj+3KEjW2r
         C4oA==
X-Forwarded-Encrypted: i=1; AJvYcCXV8x07e4W65zQPChpIZiTqYIloxZgx7q1uKBKgn6QKmtUa/nA8FMqkgiUWpeewpl/sFIQnnT223fY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw/FgS/3QA/nWqVIgwkE/RTU0IeoSUcCFaqFstG4O4Buz5zqJqE
	PYntLtE95CZQjirKeDaIX+UVIZOywrQ+jwzc1BgfUwCE1iELtK6NK5rrawPPHg+wkw==
X-Gm-Gg: ASbGncsoSCkQ9tic+7SVebYc94Q79700I3O+xdaLQ3RhRktj655UkXRf6N4QhGu39ds
	dYnLuYxaCT+NpI0zvZ15id6fkWNS9pVIIBkV/Bwz3JRnxfTnqlwZX2V7yfcq+llNYnBMbfzox2E
	JB7Pl6rKezsXpTlOMAAVqW7/6OyFhM3SdOeez7Fnf5iZZ+sKBcTf7hXIEUuJSuiYsgjjbfhnDc3
	CjfYj0iOYnmcQrxXrSt3ghkv99n+PDMzXMfOFdWFM2I7iwP+R+w7lSlhFirGRSOXI4+XnMmA65z
	9uSp6e7orc8Y8rKfVRZEOd0iU3gzmSwjcISkc9gxz4T9DRLO3mamv9UsZr6tQn/c/Z//9BMi6S8
	Wvoi1tjYlFqEx2WKQc8TG0XccPCRLhqLf9cRgWCaktZSASuO0YCmyn/DXMw==
X-Google-Smtp-Source: AGHT+IHOuqA1bqHsLIjsdjHpS64jMKxaYhdEsWyH+Ihe2fB+OvkUJJ1hYx0z/Rz1L+RiuRyAu6LxSA==
X-Received: by 2002:a05:6000:65a:b0:3a4:ed1e:405b with SMTP id ffacd0b85a97d-3a5679f75d8mr182324f8f.46.1749740326962;
        Thu, 12 Jun 2025 07:58:46 -0700 (PDT)
Message-ID: 
Date: Thu, 12 Jun 2025 16:58:36 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7] xen/arm: pci: introduce PCI_PASSTHROUGH Kconfig option
To: Stewart Hildebrand 
Cc: Rahul Singh ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Andrew Cooper ,
 Stefano Stabellini ,
 xen-devel@lists.xenproject.org
References: <20250610174635.203439-1-stewart.hildebrand@amd.com>
 <6ac8ffbc-5bd3-4bea-9ade-f31710747291@suse.com>
 <3a203b96-94e3-47c3-92b6-b68141ea3794@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: <3a203b96-94e3-47c3-92b6-b68141ea3794@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12.06.2025 15:39, Stewart Hildebrand wrote:
> On 6/11/25 01:23, Jan Beulich wrote:
>> On 10.06.2025 19:46, Stewart Hildebrand wrote:
>>> --- a/xen/arch/arm/Kconfig
>>> +++ b/xen/arch/arm/Kconfig
>>> @@ -258,6 +258,16 @@ config PARTIAL_EMULATION
>>>  
>>>  source "arch/arm/firmware/Kconfig"
>>>  
>>> +config PCI_PASSTHROUGH
>>> +	bool "PCI passthrough" if EXPERT
>>> +	depends on ARM_64
>>> +	select HAS_PCI
>>> +	select HAS_VPCI
>>> +	select HAS_VPCI_GUEST_SUPPORT
>>
>> What about HAS_PASSTHROUGH? Seeing that being selected by MMU, what about
>> that connection here?
> 
> Hm, yes. I'm not sure if depends or select would be better?
> 
> 	depends on ARM_64 && HAS_PASSTHROUGH
> 
> or
> 
> 	select HAS_PASSTHROUGH

Actually, thinking of it: HAS_* shouldn't be selected based on user choices,
imo. Perhaps unless the HAS_* is a sub-feature of the dependent (as in e.g.
"select HAS_VPCI if HVM" as we have it for x86). In which case all the
select-s here might be wrong to use.

Jan

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 15:12:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 15:12:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013219.1391726 (Exim 4.92)
	(envelope-from )
	id 1uPjb8-0001Mn-5W; Thu, 12 Jun 2025 15:12:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013219.1391726; Thu, 12 Jun 2025 15:12: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 1uPjb8-0001Mg-2o; Thu, 12 Jun 2025 15:12:10 +0000
Received: by outflank-mailman (input) for mailman id 1013219;
 Thu, 12 Jun 2025 15:12: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 1uPjb7-0001MH-2m
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 15:12:09 +0000
Received: from mail145-24.atl61.mandrillapp.com
 (mail145-24.atl61.mandrillapp.com [198.2.145.24])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 994268d9-479f-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 17:12:05 +0200 (CEST)
Received: from pmta06.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail145-24.atl61.mandrillapp.com (Mailchimp) with ESMTP id
 4bJ5bl4kHdzGlspPt
 for ; Thu, 12 Jun 2025 15:12:03 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 3dc01c07460f42b1af093b4f015f6dbe; Thu, 12 Jun 2025 15:12: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: 994268d9-479f-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1749741123; x=1750011123;
	bh=coH9VYj8t+cm8lyP6/1kT4a2yF9O9ZN1zz2YvmgHxes=;
	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=b7+cKclpRzdo678MH7N7S2huMmM1PFmKjwQH9+19yW0HDuzgTUJ732HtnfGuhR3Ln
	 Vl1DxrP2QfubTbLCyI6ZrXVZXXo2Vp0H7v+mQ34B1JvHHHhIkQYE8scADrstF4gujq
	 gVHtq9yZ3WxvyP1lwU3UvFBOkVEtTrOuHKOBw7eQSKzIZG70UsVtwcZQW0eKoQHCPK
	 Z98bbLxZenaj2TCqGNgfK5g/TySxXg11/nKc+JNpjowpV5Gzd03SEl+wxAVYVdg578
	 6H5wp00/8M9v0Yq3ShPpSaDC2bhde5rE+3eFQdCQx/1PBzsgN8nq8i5XYJxvRG9qM+
	 RAsaNZqY5tfnQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1749741123; x=1750001623; i=ngoc-tu.dinh@vates.tech;
	bh=coH9VYj8t+cm8lyP6/1kT4a2yF9O9ZN1zz2YvmgHxes=;
	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=F6x0uYkpMKM6+ZpK9N7hPJN1rKSWY/PFIX3LAW3dBxb6hxypKdQSlwXKoon2XsmVy
	 J53a/L4rPEbYjRRk+KN1hZiYAxvft9x/19fEBHb01jLHjY7yd7dC6FtE5Abya6/F/Y
	 FHXgJAlmcFsJrEw+tZJQoO7LaRE41h01zJPzQgKC0wrQ4iuFG/hAM95X/A5G4n0AYs
	 rcRv6OL/j9yFszbHzvZ/p1dthuC7OLYe/j35P61k5FE6N3W5S2Wu8dCve02LMwQDWG
	 nNS0WWTqsvze5UADfxa/ZacaP+l0J/W0/wG+ezggiGYjzNsLWdFtIhO4odmkc/4UN4
	 8/X2CHYCaI9ZQ==
From: "Tu Dinh" 
Subject: =?utf-8?Q?Re:=20[PATCH=20v4]=20x86/hvmloader:=20select=20xenpci=20MMIO=20BAR=20UC=20or=20WB=20MTRR=20cache=20attribute?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1749741122123
Message-Id: <60a346b7-82f5-46ba-84f7-82c449bc0506@vates.tech>
To: "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Anthony PERARD" 
Cc: xen-devel@lists.xenproject.org, "Oleksii Kurochko" , "Community Manager" , "Andrew Cooper" , "Michal Orzel" , "Jan Beulich" , "Julien Grall" , "Stefano Stabellini" , "Juergen Gross" , "Anthoine Bourgeois" 
References: <20250610162930.89055-1-roger.pau@citrix.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.3dc01c07460f42b1af093b4f015f6dbe?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250612:md
Date: Thu, 12 Jun 2025 15:12:03 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 12/06/2025 16:57, Roger Pau Monn=C3=A9 wrote:
> On Wed, Jun 11, 2025 at 07:26:06PM +0200, Anthony PERARD wrote:
>> On Tue, Jun 10, 2025 at 06:29:30PM +0200, Roger Pau Monne wrote:
>>> diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
>>> index c388899306c2..ddbff6fffc16 100644
>>> --- a/docs/man/xl.cfg.5.pod.in
>>> +++ b/docs/man/xl.cfg.5.pod.in
>>> @@ -2351,6 +2351,14 @@ Windows L.
>>>   Setting B with the default device_model "qemu-x=
en"
>>>   requires at least QEMU 1.6.
>>>   
>>> +
>>> +=3Ditem B
>>> +
>>> +B Select whether the memory BAR of the Xen PCI device shoul=
d have
>>> +uncacheable (UC) cache attribute set in MTRR.
>>
>> For information, here are different name used for this pci device:
>>
>> - man xl.cfg:
>>      xen_platform_pci=3D
>>          Xen platform PCI device
>> - QEMU:
>>      -device xen-platform
>>      in comments: XEN platform pci device
>>      with pci device-id PCI_DEVICE_ID_XEN_PLATFORM
>> - EDK2 / OVMF:
>>      XenIoPci
>>          described virtual Xen PCI device
>>          But XenIo is a generic protocol in EDK2
>>      Before XenIo, the pci device would be linked to XenBus, and
>>      loaded with PCI_DEVICE_ID_XEN_PLATFORM
>> - Linux:
>>      Seems to be called "xen-platform-pci"
>>
>> Overall, this PCI device is mostly referenced as the Xen Platform PCI
>> device. So "xenpci" or "Xen PCI device" is surprising to me, and I'm not
>> quite sure what it is.
> 
> I can do xen_platform_pci_bar_uc, but it seems a bit long.
> 
>>
>>> +
>>> +Default is B.
>>> +
>>>   =3Ditem B or B
>>>   
>>>   The groups of Microsoft Hyper-V (AKA viridian) compatible enlightenme=
nts
>>> diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/=
pci.c
>>> index cc67b18c0361..cfd39cc37cdc 100644
>>> --- a/tools/firmware/hvmloader/pci.c
>>> +++ b/tools/firmware/hvmloader/pci.c
>>> @@ -116,6 +116,8 @@ void pci_setup(void)
>>>        * experience the memory relocation bug described below.
>>>        */
>>>       bool allow_memory_relocate =3D 1;
>>> +    /* Select the MTRR cache attribute of the xenpci device BAR. */
>>> +    bool xenpci_bar_uc =3D false;
>>
>> This default value for `xenpci_bar_uc` mean that hvmloader changes
>> behavior compared to previous version, right? Shouldn't we instead have
>> hvmloader keep the same behavior unless the toolstack want to use the
>> new behavior? (Like it's done for `allow_memory_relocate`,
>> "platform/mmio_hole_size")
>>
>> It would just mean that toolstack other than `xl` won't be surprised by
>> a change of behavior.
> 
> My plan was that we didn't need changes to XAPI to implement this new
> mode, but given the comment I will change to keep the previous
> behavior in absence of a xenstore node.
> 
>>
>>>       BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_IO !=3D
>>>                    PCI_COMMAND_IO);
>>> @@ -130,6 +132,12 @@ void pci_setup(void)
>>>       printf("Relocating guest memory for lowmem MMIO space %s\n",
>>>              allow_memory_relocate?"enabled":"disabled");
>>>   
>>> +    s =3D xenstore_read(HVM_XS_XENPCI_BAR_UC, NULL);
>>> +    if ( s )
>>> +        xenpci_bar_uc =3D strtoll(s, NULL, 0);
>>> +    printf("XenPCI device BAR MTRR cache attribute set to %s\n",
>>> +           xenpci_bar_uc ? "UC" : "WB");
>>> +
>>>       s =3D xenstore_read("platform/mmio_hole_size", NULL);
>>>       if ( s )
>>>           mmio_hole_size =3D strtoll(s, NULL, 0);
>>> @@ -271,6 +279,44 @@ void pci_setup(void)
>>>               if ( bar_sz =3D=3D 0 )
>>>                   continue;
>>>   
>>> +            if ( !xenpci_bar_uc &&
>>> +                 ((bar_data & PCI_BASE_ADDRESS_SPACE) =3D=3D
>>> +                   PCI_BASE_ADDRESS_SPACE_MEMORY) &&
>>> +                 vendor_id =3D=3D 0x5853 &&
>>> +                 (device_id =3D=3D 0x0001 || device_id =3D=3D 0x0002) =
)
>>
>> We don't have defines for 0x5853 in the tree (and those device_id)?
>> Maybe introduce at least one for the vendor_id:
>>
>> These two names are use by QEMU, OVMF, Linux, for example.
>>
>> #define PCI_VENDOR_ID_XEN           0x5853
>> #define PCI_DEVICE_ID_XEN_PLATFORM  0x0001
>>
>> There's even PCI_DEVICE_ID_XEN_PLATFORM_XS61 in Linux
> 
> You mean in the public headers?
> 
> For Device IDs we have ranges allocated to downstream vendors, I'm not
> sure we want to keep track of whatever IDs they use for their devices.
> OTOH, not tracking those IDs here means OSes are likely to miss
> additions of new Xen platform PCI devices?
> 

The devices starting from ID c000 are supposed to be xen_pvdevice, which 
are separate device types that work differently from Xen platform PCI 
devices. So I think you only need to check for 
PCI_DEVICE_ID_XEN_PLATFORM{,_XS61} unless another platform PCI ID gets 
defined some day.

> I could introduce public/pci.h to contain those IDs, but I would like
> consensus on what should be there, otherwise this patch will get
> stuck.
> 
>>
>>> diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader=
/util.c
>>> index 79c0e6bd4ad2..31b4411db7b4 100644
>>> --- a/tools/firmware/hvmloader/util.c
>>> +++ b/tools/firmware/hvmloader/util.c
>>> @@ -867,7 +867,7 @@ void hvmloader_acpi_build_tables(struct acpi_config=
 *config,
>>>           config->table_flags |=3D ACPI_HAS_HPET;
>>>   
>>>       config->pci_start =3D pci_mem_start;
>>> -    config->pci_len =3D pci_mem_end - pci_mem_start;
>>> +    config->pci_len =3D RESERVED_MEMBASE - pci_mem_start;
>>>       if ( pci_hi_mem_end > pci_hi_mem_start )
>>>       {
>>>           config->pci_hi_start =3D pci_hi_mem_start;
>>> diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_c=
reate.c
>>> index 8bc768b5156c..962fa820faec 100644
>>> --- a/tools/libs/light/libxl_create.c
>>> +++ b/tools/libs/light/libxl_create.c
>>> @@ -313,6 +313,7 @@ int libxl__domain_build_info_setdefault(libxl__gc *=
gc,
>>>           libxl_defbool_setdefault(&b_info->u.hvm.usb,                f=
alse);
>>>           libxl_defbool_setdefault(&b_info->u.hvm.vkb_device,         t=
rue);
>>>           libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci,   t=
rue);
>>> +        libxl_defbool_setdefault(&b_info->u.hvm.xenpci_bar_uc,      tr=
ue);
>>>           libxl_defbool_setdefault(&b_info->u.hvm.pirq,               f=
alse);
>>>   
>>>           libxl_defbool_setdefault(&b_info->u.hvm.spice.enable, false);
>>> diff --git a/tools/libs/light/libxl_dom.c b/tools/libs/light/libxl_dom.=
c
>>> index 4d67b0d28294..60ec0354d19a 100644
>>> --- a/tools/libs/light/libxl_dom.c
>>> +++ b/tools/libs/light/libxl_dom.c
>>> @@ -819,6 +819,15 @@ static int hvm_build_set_xs_values(libxl__gc *gc,
>>>               goto err;
>>>       }
>>>   
>>> +    if (info->type =3D=3D LIBXL_DOMAIN_TYPE_HVM &&
>>> +        libxl_defbool_val(info->u.hvm.xenpci_bar_uc)) {
>>
>> I think this condition is wrong. You should always write the value of
>> xenpci_bar_uc into xenstore, or only write it if a value have been
>> selected. But I guess we already lost the information here about whether
>> the value is the default or not, and it's probably not important, so I
>> think you should always write the value.
> 
> Indeed, whether the value is the default or the user-selected one is
> lost by the time we get here.
> 
> I would adjust according to the above comments, but I would suggest we
> leave out the addition of the Xen platform PCI device IDs to a
> separate patch, as I fear it will block the patch otherwise.
> 
> Thanks, Roger.
> 

Best regards,


Ngoc Tu Dinh | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech




From xen-devel-bounces@lists.xenproject.org Thu Jun 12 15:18:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 15:18:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013232.1391736 (Exim 4.92)
	(envelope-from )
	id 1uPjhC-0001xd-PT; Thu, 12 Jun 2025 15:18:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013232.1391736; Thu, 12 Jun 2025 15: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 1uPjhC-0001xW-Mk; Thu, 12 Jun 2025 15:18:26 +0000
Received: by outflank-mailman (input) for mailman id 1013232;
 Thu, 12 Jun 2025 15:18: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 1uPjhB-0001xQ-JT
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 15:18:25 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on2060f.outbound.protection.outlook.com
 [2a01:111:f403:2415::60f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7ab9b42d-47a0-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 17:18:24 +0200 (CEST)
Received: from MW4PR03CA0093.namprd03.prod.outlook.com (2603:10b6:303:b7::8)
 by MW6PR12MB8959.namprd12.prod.outlook.com (2603:10b6:303:23c::18) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.18; Thu, 12 Jun
 2025 15:18:20 +0000
Received: from SJ1PEPF000023CB.namprd02.prod.outlook.com
 (2603:10b6:303:b7:cafe::45) by MW4PR03CA0093.outlook.office365.com
 (2603:10b6:303:b7::8) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.23 via Frontend Transport; Thu,
 12 Jun 2025 15:18:20 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SJ1PEPF000023CB.mail.protection.outlook.com (10.167.244.5) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Thu, 12 Jun 2025 15:18:19 +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, 12 Jun
 2025 10:18:09 -0500
Received: from [172.26.5.4] (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 Jun 2025 10:18:08 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7ab9b42d-47a0-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Nx2yWgqeEZX7HyFQbtvxhcNDeqfhPyVPu56EQGkSBr50zxW6/0cyaoz64TD4ENA0MrVFu6CllLaiVymkNr+I87dB61D17CoaOtTGYMkcHctczA03t4WtUCj5I843flvTVg+0sT0MHFkonqYQaKsg5n+DuVJ0QzXfUEf/w+gQPwVBX3TsccEKuaJK6xDyxEeAPuTfqc797pNaZ62ei0bIQIT4K+6fxVVzxAEFXgk1vhxUmpt2EpaxbrKOIieEdP4BHp8YD9dAHG4RdzLoa2DaQw2Hx6VCEhuOCDAt3oXSga6ppYnSpV+NH7Tmq0dz4BcKSVn5GBCTjwlxkeRm913uVg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=PpmyO498KurqBMzpZ40/Dzk/cJ1/+tNzBSoGHX+GDcg=;
 b=y09Z1/v5PXySqBQcjL/48kpKW6Za4d5M1eaK/gUxnoCcNd4noHVhLGz37cNHQiQZJkGF6zkUCUZWKCKEF6z4fSBU6Z0LgXppIeX2Uh7J+nNQnADdBVGaPUoy9bugRG1ZMWoRw8zWeQcFLP2H/WQO1XBfxGctveusIJG1PBJ9RJrY3yUQpCDiZyhI/HtGTa02fX95E4m1Ib+zCi8OheU/v5Z4tNbGbPNPS9wPowhixS0WGucpFdHzTeZw637T4OmwIaLe3DaaFze25/NfeCD56cHuHeiFkwvEUBaQcWcNPIc/JImd44azd2S2u0mDxjCpRn6gc0ZwUUNnHNKvW4heAA==
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=PpmyO498KurqBMzpZ40/Dzk/cJ1/+tNzBSoGHX+GDcg=;
 b=BUYI5j3ksetgdBqYPscBk3clNp5YZblq7FIChuR34L9EzVSlSIPLxpTnLzJjr2ovfC1nVN8BCtsecjuLsJ4SOQ2sWVRfNKw8RYrJSUTiVlIVYttN0AaMH3t9s9luA19X8zeEX88VuNvdgpek06/jD/UKss6a9E4HnU9ILKF4oJ4=
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: <2150be73-e23a-4caa-91a7-8f7c139e4e87@amd.com>
Date: Thu, 12 Jun 2025 11:18:07 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7] xen/arm: pci: introduce PCI_PASSTHROUGH Kconfig option
To: Jan Beulich 
CC: Rahul Singh , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	, Andrew Cooper , "Stefano
 Stabellini" , 
References: <20250610174635.203439-1-stewart.hildebrand@amd.com>
 <6ac8ffbc-5bd3-4bea-9ade-f31710747291@suse.com>
 <3a203b96-94e3-47c3-92b6-b68141ea3794@amd.com>
 
Content-Language: en-US
From: Stewart Hildebrand 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
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: SJ1PEPF000023CB:EE_|MW6PR12MB8959:EE_
X-MS-Office365-Filtering-Correlation-Id: af897f24-6c34-4a33-5b85-08dda9c45d3c
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:
	=?utf-8?B?RGFZMlZkV3FTcC9vUi9saU9xWVRsWVZCeUZvdmJvaHhWbFQ4bnptSFJDNkhP?=
 =?utf-8?B?dHcybENmSUZjaFdSMmI4Nit3Tnp5bjE5VFBQbzhuQWsxMjMyWlNtYTVJTWp1?=
 =?utf-8?B?SG84eTRGd1QxblcycVJab2toZ2NuUm9BTjVXY2xhZ0VnbzZmbzVhN3JBKzdP?=
 =?utf-8?B?SFJ4V1lBSkUwV21jalEvY2hBSEI4OElqY0FLdDcxRHljTE43T2greE1jM29n?=
 =?utf-8?B?WGFDd0NRT3FNdktYcFRFNHErZnJ2aW5wN1k1L2ZaQkhjWlpuVHpqdkpWVUsx?=
 =?utf-8?B?WERNbjBaZ1dPcXg2WVo4bjdiWUZaSWNOVU91cVpqbTI3ZXVjQlpYeW1NN3U0?=
 =?utf-8?B?KzdBZnBHSTJ2d3BTaGV1WWVQanZSbGJmbGFrY2wrOGxic3RYU0J2OTZYODNy?=
 =?utf-8?B?bllrL2NmK29BeDlKeXJTYm9Id3J0YkwyMDR0K0U2ajFGd0pEREFET0RyOGV5?=
 =?utf-8?B?RGQ0MUFhdUJhQnZabldpN1FnVHdCNkp3SXVBUmhKa3ZvY0hjNWV5NGQza0lq?=
 =?utf-8?B?Z3grd2l2NEJKQURMNnlIT0lkd1ptcXU5N3NEQzY0NVVHTmRpNXFwUnVVemJI?=
 =?utf-8?B?N1pqL0FiSy9TRURYL25OdmtXZ09ZbDA0Y2JPVDQyVzZwVDcxVWFWV2k3aG9V?=
 =?utf-8?B?Y09DVDBBZE1SVlBwK1dXWm8ySHgyYVRMYjJjelYwUXorRnB0UGpLM09EOTgy?=
 =?utf-8?B?UEhVb3R3M08yZC9xTzdSSWJqUEFKTk1ScW1hY1Ixems5TXJvSzNKNHN2d3U2?=
 =?utf-8?B?Tml0RlYxd0VyN0tXVXB2VEsxdEErK1RvWmlNMng5cGhGRSs3Tytyd2drbkZI?=
 =?utf-8?B?QnRpV2paLzBzOHpCTWxSdXFMd2U2OFFQeWs0YTd1bVFxd2xMbU1iaDFSL2tz?=
 =?utf-8?B?R1N0R3VrQUp0NE9zVXRSVlpOdnYvN2ZMYWwwRjlsOGwxZEVHSU1lRUhkOHJk?=
 =?utf-8?B?a1NHNkRVNDhacW1kNHovN3p2UjBBUEZIK0tpT3d3UmdPd3pZZ1c1WDhSalhm?=
 =?utf-8?B?Ym5zMFBxN09wTjVaUkNJbVRvbnFHdGtFTTNVVGlvMnJ1Zlg1a2lmbTJORHlW?=
 =?utf-8?B?dENYcEpRdUJ4ZXErTGQ1SFNMWmFGbXhsbWhoUERjZ0RpZkxNUWNRbDZXRmt5?=
 =?utf-8?B?TnRmRjkrVmpLYjdrRUJOUzlzbXNxNmNYejVFY09zTG0xbjcvY1dTQUUzNXlu?=
 =?utf-8?B?cTd4OHZLUi91QkphZWhPTnZDZXlVL1U0MFl3OHl2eHlUZWZXblhKRHc2c1Nx?=
 =?utf-8?B?dEgxWkFXSFREalVyTWNnK1htUEdENXVqZkdNSkthQ1k5U1VudGk0OUY1SEZs?=
 =?utf-8?B?Vlh0ZFhGNkUxNmxEcjExbnlob3VXekV4Ums3RlYvNDFncFppOCtCc3RYemxa?=
 =?utf-8?B?eXZhY2ZORHM0MGIzcENzcWxiVUhpV01qaFJzOXZiWjlscFlqL3ByRDdDVjNN?=
 =?utf-8?B?ODhaWmNTNnl3VVdsdmt4ZlZwRGV4eEFHOU1RZDN6Y1NJSkNtWjNOd3ZZNExi?=
 =?utf-8?B?T0Q0RDdiMnFXVjQvclVjRXdKRXFyTXY3M241UERjT3RUcHllaUhqZWtxRGhX?=
 =?utf-8?B?NDYrSlg4NzZXVTEwdjdyRnNxczRPejRpY0YwbGpFN3FLQjZsL2p3c1QyZnJj?=
 =?utf-8?B?T2ZDcWhoMU4vekcwTlBzbWtSRk9DcVRNOSttRmFFYXpQTldUY3BXYmU1SFdw?=
 =?utf-8?B?bmNRVVRLWDlNQmFuQW5meVJDSnpRTnhlQ0htaDFIL0dNSHdETmJ0bkVMYTVx?=
 =?utf-8?B?RnFabzhKMUgyNitPYkxMNlVLWS92RllVT3U1MVM4MkxWZXliRGVoT2pPN0la?=
 =?utf-8?B?NVBYaXByVmtxaC9IT1dlQ3g0OVpsbCs3NUFreVR3TXFqRkhxWnRjNklmbXUy?=
 =?utf-8?B?cllwOG9DUWtONktOWWF4bVJtaEdnc2lNVzEvQkVlSWJyZlhpRFVRQXdTeFhK?=
 =?utf-8?B?YUF2SkE4Yi9GWi9lT0oxSTZZL1hLcWx3MHZJRm8wR0hPZlZHYTg0YTdvalNX?=
 =?utf-8?B?eWNTWHdqVnpHcWRoQTN1V0NYUllnRFNDRitsWFhpbUtwVHl5TjhDdFNNc0Ux?=
 =?utf-8?Q?+SmTv4?=
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);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2025 15:18:19.8132
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: af897f24-6c34-4a33-5b85-08dda9c45d3c
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:
	SJ1PEPF000023CB.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW6PR12MB8959

On 6/12/25 10:58, Jan Beulich wrote:
> On 12.06.2025 15:39, Stewart Hildebrand wrote:
>> On 6/11/25 01:23, Jan Beulich wrote:
>>> On 10.06.2025 19:46, Stewart Hildebrand wrote:
>>>> --- a/xen/arch/arm/Kconfig
>>>> +++ b/xen/arch/arm/Kconfig
>>>> @@ -258,6 +258,16 @@ config PARTIAL_EMULATION
>>>>  
>>>>  source "arch/arm/firmware/Kconfig"
>>>>  
>>>> +config PCI_PASSTHROUGH
>>>> +	bool "PCI passthrough" if EXPERT
>>>> +	depends on ARM_64
>>>> +	select HAS_PCI
>>>> +	select HAS_VPCI
>>>> +	select HAS_VPCI_GUEST_SUPPORT
>>>
>>> What about HAS_PASSTHROUGH? Seeing that being selected by MMU, what about
>>> that connection here?
>>
>> Hm, yes. I'm not sure if depends or select would be better?
>>
>> 	depends on ARM_64 && HAS_PASSTHROUGH
>>
>> or
>>
>> 	select HAS_PASSTHROUGH
> 
> Actually, thinking of it: HAS_* shouldn't be selected based on user choices,
> imo. Perhaps unless the HAS_* is a sub-feature of the dependent (as in e.g.
> "select HAS_VPCI if HVM" as we have it for x86). In which case all the
> select-s here might be wrong to use.

How about something like this:

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 3f25da3ca5fd..95a2cd3d006d 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -8,6 +8,8 @@ config ARM_64
 	depends on !ARM_32
 	select 64BIT
 	select HAS_FAST_MULTIPLY
+	select HAS_VPCI_GUEST_SUPPORT if PCI_PASSTHROUGH
+	select HAS_PASSTHROUGH if PCI_PASSTHROUGH
 
 config ARM
 	def_bool y
@@ -258,6 +260,12 @@ config PARTIAL_EMULATION
 
 source "arch/arm/firmware/Kconfig"
 
+config PCI_PASSTHROUGH
+	bool "PCI passthrough" if EXPERT
+	depends on ARM_64
+	help
+	  This option enables PCI device passthrough
+
 endmenu
 
 menu "ARM errata workaround via the alternative framework"
diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig
index 20050e9bb8b3..0c376704ddc9 100644
--- a/xen/drivers/Kconfig
+++ b/xen/drivers/Kconfig
@@ -13,6 +13,7 @@ source "drivers/pci/Kconfig"
 source "drivers/video/Kconfig"
 
 config HAS_VPCI
+	select HAS_PCI
 	bool
 
 config HAS_VPCI_GUEST_SUPPORT


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 15:23:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 15:23:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013241.1391746 (Exim 4.92)
	(envelope-from )
	id 1uPjlc-0003k3-EF; Thu, 12 Jun 2025 15:23:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013241.1391746; Thu, 12 Jun 2025 15: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 1uPjlc-0003jw-AX; Thu, 12 Jun 2025 15:23:00 +0000
Received: by outflank-mailman (input) for mailman id 1013241;
 Thu, 12 Jun 2025 15:22: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 1uPjla-0003jq-GI
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 15:22:58 +0000
Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com
 [2607:f8b0:4864:20::729])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1d77731c-47a1-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 17:22:56 +0200 (CEST)
Received: by mail-qk1-x729.google.com with SMTP id
 af79cd13be357-7d094d1fd7cso139708585a.3
 for ; Thu, 12 Jun 2025 08:22:56 -0700 (PDT)
Received: from [10.138.10.6] ([89.187.178.201])
 by smtp.gmail.com with ESMTPSA id
 af79cd13be357-7d3b8dc92c3sm52760985a.22.2025.06.12.08.22.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 08:22:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1d77731c-47a1-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749741775; x=1750346575; 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=mUsBhFWy36x6Vn4SHsP5OuEL3fuIZymSm2+gVVVvs00=;
        b=Vj3jhrvGL6KGIIHJYNJroHmrfOVjcGzY6PJRw1bSLauDqjSAqc5REf1rG+F6GPCLcj
         QNOne7b1ppBJHD7U6Qd+zNlExRfPO60+wzipCFb9i0nUyD0nAGoLqp/QHnqKMuBZGCXY
         ojcAZ7er+YSjQzQ/fzs4nrIta9vBHtLRxnFHN4XuQ8N3qfT3ypuugiAeZSR8LegXzceM
         cdMu31vMjgtrPwBIrf/FCDMuMWwo+Cuq17opbLr6O8oKQO6cKteIFrOIfxPsNShnB/ga
         4adChszaZT0WImoY8Am9AlXXjQkD9g35QfpMhjJHUFPi4y4vYvKCeCJ3J2JSGNucyVbH
         Gv3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749741775; x=1750346575;
        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=mUsBhFWy36x6Vn4SHsP5OuEL3fuIZymSm2+gVVVvs00=;
        b=gVaFHPGqvDqhMncWMltZnUt3/tAJxBLvY+be/d6K6K7Qs5cgtKOk8Ttbt9GuFfy3NT
         kz78ZQ+ucNZnqGcElBzr261hcffYsPEdQB/nyujoK454JuKVbw7AAA4qOQFpeIZ6RStx
         Y+Gk7RYqK1IE2cQwF8Xsn6aTM7V3TkxTFp8sS+GvpvboR+2tE34t6QJe6lGyQ/ARxc0K
         5qX5idHzrPvliiZ94FoV1zAvX2TIq9kyaD32S7ohbCoS4Rbvqtw2r2TuRezwkBRs5ebb
         t1Ew2M8n7IrlqXX/NoFaU2BRvUEu4AkrNI7uRj4n/Z83GgpgksUQxXW/HpNijV355CFK
         NNGQ==
X-Forwarded-Encrypted: i=1; AJvYcCXAwq9JzkJbrpqGh2Ho0pY6JQq6Tn0zkkOTxd9VwoBHVfs0RNc52+valu0nwtHiZbPK3QEdns1u+zg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxPawFUrcGZ9zIcWZN2bAiFQD9StOmi554YQwpqnWCJOrBE9ebc
	DiyQ9IIBfjQtnII3eRoeVlkgfsYrQaA8J3BMK8g9GM6zO8ss7KGpRhN5
X-Gm-Gg: ASbGncvuX/5M2ZgjU9aZiSQJflacZlektUHmgAZmFXmaTwZndVd5pDp+XL6HMDF+cfZ
	WA8O5zGRpcZQXPMSlLpLdFsXg9JXbCxUnU0aWbUnGEslNMrA7QbGrhcWwYnjDXdolU4tyzwIiK3
	k76Std9avJWh9ovuYBps7Y9MdovS/JZo1vNyihj/gWGPdrCAUtEYbdB3/8t1LKc0KlqA2gQZSSQ
	st0oGY+RBo4XjxejWnL8U+F5gw5MtnOghcsF9Eio5jwEPHA3nUkZ6i83rBuexXE7ytx6rv0p1Dn
	ysGQ6K3kOGDgS2Ei/4Pkr4n24Zw+QocPwa9xCabXzeTPzYb71yU46/M1sCW88AX/ACcTiwkvghG
	cEg==
X-Google-Smtp-Source: AGHT+IHGj2W0Y9dgpQZ5nQgC7Ridrl4+EIfLPnyRaO3LogVm36MCIe+AQ+JhWa00i4iW9zj+fo+rLw==
X-Received: by 2002:a05:620a:25d3:b0:7c5:3d60:7f91 with SMTP id af79cd13be357-7d3b29f099bmr555679885a.15.1749741774952;
        Thu, 12 Jun 2025 08:22:54 -0700 (PDT)
Message-ID: <842eb63e-cd20-4c0f-9f25-9d9c2a5457b1@gmail.com>
Date: Thu, 12 Jun 2025 11:22:39 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] docs: UEFI Secure Boot security policy
To: Jan Beulich , Andrew Cooper 
Cc: Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , Juergen Gross
 ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , Trammell Hudson ,
 Ross Lagerwall ,
 Frediano Ziglio ,
 Gerald Elder-Vass ,
 Kevin Lampis ,
 Xen-devel 
References: <20250611235851.167385-1-andrew.cooper3@citrix.com>
 <5aad2d39-31e1-44c6-b167-a3275dc6b747@suse.com>
Content-Language: en-US
From: Demi Marie Obenour 
Autocrypt: addr=demiobenour@gmail.com; keydata=
 xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49yB+l2nipd
 aq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYfbWpr/si88QKgyGSV
 Z7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/UorR+FaSuVwT7rqzGrTlscnT
 DlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7MMPCJwI8JpPlBedRpe9tfVyfu3euTPLPx
 wcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9Hzx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR
 6h3nBc3eyuZ+q62HS1pJ5EvUT1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl
 5FMWo8TCniHynNXsBtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2
 Bkg1b//r6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nSm9BBff0N
 m0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQABzTxEZW1pIE1hcmll
 IE9iZW5vdXIgKGxvdmVyIG9mIGNvZGluZykgPGRlbWlvYmVub3VyQGdtYWlsLmNvbT7CwXgE
 EwECACIFAlp+A0oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELKItV//nCLBhr8Q
 AK/xrb4wyi71xII2hkFBpT59ObLN+32FQT7R3lbZRjVFjc6yMUjOb1H/hJVxx+yo5gsSj5LS
 9AwggioUSrcUKldfA/PKKai2mzTlUDxTcF3vKx6iMXKA6AqwAw4B57ZEJoMM6egm57TV19kz
 PMc879NV2nc6+elaKl+/kbVeD3qvBuEwsTe2Do3HAAdrfUG/j9erwIk6gha/Hp9yZlCnPTX+
 VK+xifQqt8RtMqS5R/S8z0msJMI/ajNU03kFjOpqrYziv6OZLJ5cuKb3bZU5aoaRQRDzkFIR
 6aqtFLTohTo20QywXwRa39uFaOT/0YMpNyel0kdOszFOykTEGI2u+kja35g9TkH90kkBTG+a
 EWttIht0Hy6YFmwjcAxisSakBuHnHuMSOiyRQLu43ej2+mDWgItLZ48Mu0C3IG1seeQDjEYP
 tqvyZ6bGkf2Vj+L6wLoLLIhRZxQOedqArIk/Sb2SzQYuxN44IDRt+3ZcDqsPppoKcxSyd1Ny
 2tpvjYJXlfKmOYLhTWs8nwlAlSHX/c/jz/ywwf7eSvGknToo1Y0VpRtoxMaKW1nvH0OeCSVJ
 itfRP7YbiRVc2aNqWPCSgtqHAuVraBRbAFLKh9d2rKFB3BmynTUpc1BQLJP8+D5oNyb8Ts4x
 Xd3iV/uD8JLGJfYZIR7oGWFLP4uZ3tkneDfYzsFNBFp+A0oBEAC9ynZI9LU+uJkMeEJeJyQ/
 8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd8xD57ue0eB47bcJv
 VqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPpI4gfUbVEIEQuqdqQyO4GAe+M
 kD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalql1/iSyv1WYeC1OAs+2BLOAT2NEggSiVO
 txEfgewsQtCWi8H1SoirakIfo45Hz0tk/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJ
 riwoaRIS8N2C8/nEM53jb1sH0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcN
 fRAIUrNlatj9TxwivQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6
 dCxN0GNAORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
 rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog2LNtcyCj
 kTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZAgrrnNz0iZG2DVx46
 x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJELKItV//nCLBwNIP/AiIHE8b
 oIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwjjVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGj
 gn0TPtsGzelyQHipaUzEyrsceUGWYoKXYyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8fr
 RHnJdBcjf112PzQSdKC6kqU0Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2
 E0rW4tBtDAn2HkT9uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHM
 OBvy3EhzfAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
 Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVssZ/rYZ9+5
 1yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aWemLLszcYz/u3XnbO
 vUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPthZlDnTnOT+C+OTsh8+m5tos8
 HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E
 +MYSfkEjBz0E8CLOcAw7JIwAaeBT
In-Reply-To: <5aad2d39-31e1-44c6-b167-a3275dc6b747@suse.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------Z18kng6eo8ZvktkXYjDuEZMl"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------Z18kng6eo8ZvktkXYjDuEZMl
Content-Type: multipart/mixed; boundary="------------D9ZKRkWnidZC6bnnEe9nSMHd";
 protected-headers="v1"
From: Demi Marie Obenour 
To: Jan Beulich , Andrew Cooper 
Cc: Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , Juergen Gross
 ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , Trammell Hudson ,
 Ross Lagerwall ,
 Frediano Ziglio ,
 Gerald Elder-Vass ,
 Kevin Lampis ,
 Xen-devel 
Message-ID: <842eb63e-cd20-4c0f-9f25-9d9c2a5457b1@gmail.com>
Subject: Re: [PATCH] docs: UEFI Secure Boot security policy
References: <20250611235851.167385-1-andrew.cooper3@citrix.com>
 <5aad2d39-31e1-44c6-b167-a3275dc6b747@suse.com>
In-Reply-To: <5aad2d39-31e1-44c6-b167-a3275dc6b747@suse.com>
Autocrypt-Gossip: 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==
Autocrypt-Gossip: addr=marmarek@invisiblethingslab.com; keydata=
 xsBNBE5j9EwBCACbYHjxDrxFAY3n1x9KBFvjzkG1qFSTVBnH4vpD/5Na4sZq4uDDMUCjivrm
 MzbWYaivYj96BygdOiw7PWxYrhuW0b2WYOeGudZyApgFz42g458s78EciuhgfuWBlxr8dOEN
 /9ueVFHcvtZmDbHhMVPcQ0O7gwh0JmwkOsf7P7WAfYXsQlhO/EBRrNXR0Je+GEpYADhRktxX
 h1d3Iz+oKYuwHioLX8ovoAT4+peOuecWUSpUWebpDbTR5i7NRP3PIblB4KzWJa2kh/f3mx4v
 SRGnHn+BfX42xSe0X7Ktl4Xf+KNq9Wkcjk2CZP57hV2v4pO0ZUOXD7IhlZtnfNj67WjdABEB
 AAHNPU1hcmVrIE1hcmN6eWtvd3NraS1Hw7NyZWNraSA8bWFybWFyZWtAaW52aXNpYmxldGhp
 bmdzbGFiLmNvbT7CwHoEEwEIACQCGwMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AFAll+l7cC
 GQEACgkQ24/THMrX1yw6kAgAiKiUhzAPXZj5ndqiQDl8u8PUK34SupLzYNMJOCBw5Wh+CPHe
 XYlQUwfULWxmzjiWCzzWDx2X/ONsYdRGKDKMqG5srOSWe1IYXv00MEutGsK+m/hmC5mqi/97
 DVNZ1VtKj5WW79IsI0/7ueHsQYNNrXyOfZvKsRE8VIUJ0tNfLFDFlNpq9jONuF+GviMWxrA5
 FoVaGmjh63xC0fOQYqhP2v8dbYS4B6bO5NZKI2cTHb9Li2iY0e7wIoNgvqgtR3Iv2U2Ry0yL
 D3mNQhwyxcWChexlymjfqLEZwKqaIOo57HOpt7OA+bMg6MvkdUTjNWf2GE6fqCcALjcToJ3L
 NDc1KM7ATQROY/RMAQgAtRWgUZ5mOy+c/qzmiVnxqDkiOJjmnIh3Pn+OqCtjcrTyPI9eVc06
 uH30Jkco0soLiG/UgwVw4XwBlm95j9n6TSUms4mPBh1YiR1hBjsjYwn8zp/Ue9xWk1N6E14H
 aj55GxmS2H3YIlOXfQLr0X3RHsmKixTOKyisrYlJu71FmettDFV7CgMXy1Bc1LbAE08asvAS
 ShHFdRiRRtkuVHvY/Ebq9L54kOxtlI6ahrflMcT0YCMON5oe4GgQRh3p2uy+d/LS2bgRcQST
 IebErj8x0lM271f97GvxV/ypHo7XVIDI5FX1u31Agzx3HQr035GHt4HV4/GVCz+V4xt4BonB
 tQARAQABwsBfBBgBAgAJBQJOY/RMAhsMAAoJENuP0xzK19cs5MgH/jWLXil2Ud4TdtWnBxc+
 2/QZZk2JCssc1PgWNzvH5wH7U+8lGSlUK8ZMOqrrF8C5rX0+xEn7deSrsZChIOnUFo8rhCZK
 y/mBV+FhkMj24FZZ0n8w3eF4KF2t68Pt+AvMjxQHwxAMdf3QftgQhD0qYkt/28eedUQ+jwz6
 kipc4qUQmqTEViQRPa3WAnKgNDQUDUwNruzthfGvHUjllf7zbPI8gkbARM0KlTkLikc9u+Ni
 VMbJTiGPB7YHyw2MIPq1n+mhSPAyXE6CVBnYkonQ7P3SLZssxC3PIarV+DTU68umQB3pfrfF
 7hMcAY5csWrK9/x/Zz4RUfgN6Q3HLrSp9UQ=

--------------D9ZKRkWnidZC6bnnEe9nSMHd
Content-Type: multipart/mixed; boundary="------------hDr5RUQi30MQZh0ETQ5E4wWV"

--------------hDr5RUQi30MQZh0ETQ5E4wWV
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 6/12/25 06:06, Jan Beulich wrote:
> On 12.06.2025 01:58, Andrew Cooper wrote:
>> 2) Pre-boot DMA Protection.  Microsoft consider this a platform featur=
e
>> requiring OEM enablement, and do not consider its absence to be a Secu=
re Boot
>> vulnerability.  But, it is less clear what the policy ought to be for =
Xen
>> booting on a capable system and failing to do a correct live-handover =
of the
>> IOMMU across ExitBootServices().
>=20
> Shouldn't this be another TODO item at the bottom? We don't support yet=
 taking
> over when the IOMMUs are already enabled, do we?

Dasharo supports leaving the IOMMU enabled when transferring to the OS, a=
nd
this message was sent from a Qubes OS box booted in this configuration.
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
--------------hDr5RUQi30MQZh0ETQ5E4wWV
Content-Type: application/pgp-keys; name="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

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

xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49y
B+l2nipdaq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYf
bWpr/si88QKgyGSVZ7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/
UorR+FaSuVwT7rqzGrTlscnTDlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7M
MPCJwI8JpPlBedRpe9tfVyfu3euTPLPxwcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9H
zx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR6h3nBc3eyuZ+q62HS1pJ5EvU
T1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl5FMWo8TCniHynNXs
BtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2Bkg1b//r
6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nS
m9BBff0Nm0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQAB
zTxEZW1pIE9iZW5vdXIgKElUTCBFbWFpbCBLZXkpIDxhdGhlbmFAaW52aXNpYmxl
dGhpbmdzbGFiLmNvbT7CwY4EEwEIADgWIQR2h02fEza6IlkHHHGyiLVf/5wiwQUC
X6YJvQIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRCyiLVf/5wiwWRhD/0Y
R+YYC5Kduv/2LBgQJIygMsFiRHbR4+tWXuTFqgrxxFSlMktZ6gQrQCWe38WnOXkB
oY6n/5lSJdfnuGd2UagZ/9dkaGMUkqt+5WshLFly4BnP7pSsWReKgMP7etRTwn3S
zk1OwFx2lzY1EnnconPLfPBc6rWG2moA6l0WX+3WNR1B1ndqpl2hPSjT2jUCBWDV
rGOUSX7r5f1WgtBeNYnEXPBCUUM51pFGESmfHIXQrqFDA7nBNiIVFDJTmQzuEqIy
Jl67pKNgooij5mKzRhFKHfjLRAH4mmWZlB9UjDStAfFBAoDFHwd1HL5VQCNQdqEc
/9lZDApqWuCPadZN+pGouqLysesIYsNxUhJ7dtWOWHl0vs7/3qkWmWun/2uOJMQh
ra2u8nA9g91FbOobWqjrDd6x3ZJoGQf4zLqjmn/P514gb697788e573WN/MpQ5XI
Fl7aM2d6/GJiq6LC9T2gSUW4rbPBiqOCeiUx7Kd/sVm41p9TOA7fEG4bYddCfDsN
xaQJH6VRK3NOuBUGeL+iQEVF5Xs6Yp+U+jwvv2M5Lel3EqAYo5xXTx4ls0xaxDCu
fudcAh8CMMqx3fguSb7Mi31WlnZpk0fDuWQVNKyDP7lYpwc4nCCGNKCj622ZSocH
AcQmX28L8pJdLYacv9pU3jPy4fHcQYvmTavTqowGnM08RGVtaSBNYXJpZSBPYmVu
b3VyIChsb3ZlciBvZiBjb2RpbmcpIDxkZW1pb2Jlbm91ckBnbWFpbC5jb20+wsF4
BBMBAgAiBQJafgNKAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCyiLVf
/5wiwYa/EACv8a2+MMou9cSCNoZBQaU+fTmyzft9hUE+0d5W2UY1RY3OsjFIzm9R
/4SVccfsqOYLEo+S0vQMIIIqFEq3FCpXXwPzyimotps05VA8U3Bd7yseojFygOgK
sAMOAee2RCaDDOnoJue01dfZMzzHPO/TVdp3OvnpWipfv5G1Xg96rwbhMLE3tg6N
xwAHa31Bv4/Xq8CJOoIWvx6fcmZQpz01/lSvsYn0KrfEbTKkuUf0vM9JrCTCP2oz
VNN5BYzqaq2M4r+jmSyeXLim922VOWqGkUEQ85BSEemqrRS06IU6NtEMsF8EWt/b
hWjk/9GDKTcnpdJHTrMxTspExBiNrvpI2t+YPU5B/dJJAUxvmhFrbSIbdB8umBZs
I3AMYrEmpAbh5x7jEjoskUC7uN3o9vpg1oCLS2ePDLtAtyBtbHnkA4xGD7ar8mem
xpH9lY/i+sC6CyyIUWcUDnnagKyJP0m9ks0GLsTeOCA0bft2XA6rD6aaCnMUsndT
ctrab42CV5XypjmC4U1rPJ8JQJUh1/3P48/8sMH+3krxpJ06KNWNFaUbaMTGiltZ
7x9DngklSYrX0T+2G4kVXNmjaljwkoLahwLla2gUWwBSyofXdqyhQdwZsp01KXNQ
UCyT/Pg+aDcm/E7OMV3d4lf7g/CSxiX2GSEe6BlhSz+Lmd7ZJ3g32M1ARGVtaSBN
YXJpZSBPYmVub3VyIChJVEwgRW1haWwgS2V5KSA8ZGVtaUBpbnZpc2libGV0aGlu
Z3NsYWIuY29tPsLBjgQTAQgAOBYhBHaHTZ8TNroiWQcccbKItV//nCLBBQJgOEV+
AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJELKItV//nCLBKwoP/1WSnFdv
SAD0g7fD0WlF+oi7ISFT7oqJnchFLOwVHK4Jg0e4hGn1ekWsF3Ha5tFLh4V/7UUu
obYJpTfBAA2CckspYBqLtKGjFxcaqjjpO1I2W/jeNELVtSYuCOZICjdNGw2Hl9yH
KRZiBkqc9u8lQcHDZKq4LIpVJj6ZQV/nxttDX90ax2No1nLLQXFbr5wb465LAPpU
lXwunYDij7xJGye+VUASQh9datye6orZYuJvNo8Tr3mAQxxkfR46LzWgxFCPEAZJ
5P56Nc0IMHdJZj0Uc9+1jxERhOGppp5jlLgYGK7faGB/jTV6LaRQ4Ad+xiqokDWp
mUOZsmA+bMbtPfYjDZBz5mlyHcIRKIFpE1l3Y8F7PhJuzzMUKkJi90CYakCV4x/a
Zs4pzk5E96c2VQx01RIEJ7fzHF7lwFdtfTS4YsLtAbQFsKayqwkGcVv2B1AHeqdo
TMX+cgDvjd1ZganGlWA8Sv9RkNSMchn1hMuTwERTyFTr2dKPnQdA1F480+jUap41
ClXgn227WkCIMrNhQGNyJsnwyzi5wS8rBVRQ3BOTMyvGM07j3axUOYaejEpg7wKi
wTPZGLGH1sz5GljD/916v5+v2xLbOo5606j9dWf5/tAhbPuqrQgWv41wuKDi+dDD
EKkODF7DHes8No+QcHTDyETMn1RYm7t0RKR4zsFNBFp+A0oBEAC9ynZI9LU+uJkM
eEJeJyQ/8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd
8xD57ue0eB47bcJvVqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPp
I4gfUbVEIEQuqdqQyO4GAe+MkD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalq
l1/iSyv1WYeC1OAs+2BLOAT2NEggSiVOtxEfgewsQtCWi8H1SoirakIfo45Hz0tk
/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJriwoaRIS8N2C8/nEM53jb1sH
0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcNfRAIUrNlatj9Txwi
vQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6dCxN0GNA
ORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog
2LNtcyCjkTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZA
grrnNz0iZG2DVx46x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJ
ELKItV//nCLBwNIP/AiIHE8boIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwj
jVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGjgn0TPtsGzelyQHipaUzEyrsceUGWYoKX
YyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8frRHnJdBcjf112PzQSdKC6kqU0
Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2E0rW4tBtDAn2HkT9
uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHMOBvy3Ehz
fAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVss
Z/rYZ9+51yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aW
emLLszcYz/u3XnbOvUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPt
hZlDnTnOT+C+OTsh8+m5tos8HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj
6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E+MYSfkEjBz0E8CLOcAw7JIwAaeBTzsFN
BGbyLVgBEACqClxh50hmBepTSVlan6EBq3OAoxhrAhWZYEwN78k+ENhK68KhqC5R
IsHzlL7QHW1gmfVBQZ63GnWiraM6wOJqFTL4ZWvRslga9u28FJ5XyK860mZLgYhK
9BzoUk4s+dat9jVUbq6LpQ1Ot5I9vrdzo2p1jtQ8h9WCIiFxSYy8s8pZ3hHh5T64
GIj1m/kY7lG3VIdUgoNiREGf/iOMjUFjwwE9ZoJ26j9p7p1U+TkKeF6wgswEB1T3
J8KCAtvmRtqJDq558IU5jhg5fgN+xHB8cgvUWulgK9FIF9oFxcuxtaf/juhHWKMO
RtL0bHfNdXoBdpUDZE+mLBUAxF6KSsRrvx6AQyJs7VjgXJDtQVWvH0PUmTrEswgb
49nNU+dLLZQAZagxqnZ9Dp5l6GqaGZCHERJcLmdY/EmMzSf5YazJ6c0vO8rdW27M
kn73qcWAplQn5mOXaqbfzWkAUPyUXppuRHfrjxTDz3GyJJVOeMmMrTxH4uCaGpOX
Z8tN6829J1roGw4oKDRUQsaBAeEDqizXMPRc+6U9vI5FXzbAsb+8lKW65G7JWHym
YPOGUt2hK4DdTA1PmVo0DxH00eWWeKxqvmGyX+Dhcg+5e191rPsMRGsDlH6KihI6
+3JIuc0y6ngdjcp6aalbuvPIGFrCRx3tnRtNc7He6cBWQoH9RPwluwARAQABwsOs
BBgBCgAgFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmbyLVgCGwICQAkQsoi1X/+c
IsHBdCAEGQEKAB0WIQSilC2pUlbVp66j3+yzNoc6synyUwUCZvItWAAKCRCzNoc6
synyU85gD/0T1QDtPhovkGwoqv4jUbEMMvpeYQf+oWgm/TjWPeLwdjl7AtY0G9Ml
ZoyGniYkoHi37Gnn/ShLT3B5vtyI58ap2+SSa8SnGftdAKRLiWFWCiAEklm9FRk8
N3hwxhmSFF1KR/AIDS4g+HIsZn7YEMubBSgLlZZ9zHl4O4vwuXlREBEW97iL/FSt
VownU2V39t7PtFvGZNk+DJH7eLO3jmNRYB0PL4JOyyda3NH/J92iwrFmjFWWmmWb
/Xz8l9DIs+Z59pRCVTTwbBEZhcUc7rVMCcIYL+q1WxBG2e6lMn15OQJ5WfiE6E0I
sGirAEDnXWx92JNGx5l+mMpdpsWhBZ5iGTtttZesibNkQfd48/eCgFi4cxJUC4PT
UQwfD9AMgzwSTGJrkI5XGy+XqxwOjL8UA0iIrtTpMh49zw46uV6kwFQCgkf32jZM
OLwLTNSzclbnA7GRd8tKwezQ/XqeK3dal2n+cOr+o+Eka7yGmGWNUqFbIe8cjj9T
JeF3mgOCmZOwMI+wIcQYRSf+e5VTMO6TNWH5BI3vqeHSt7HkYuPlHT0pGum88d4a
pWqhulH4rUhEMtirX1hYx8Q4HlUOQqLtxzmwOYWkhl1C+yPObAvUDNiHCLf9w28n
uihgEkzHt9J4VKYulyJM9fe3ENcyU6rpXD7iANQqcr87ogKXFxknZ97uEACvSucc
RbnnAgRqZ7GDzgoBerJ2zrmhLkeREZ08iz1zze1JgyW3HEwdr2UbyAuqvSADCSUU
GN0vtQHsPzWl8onRc7lOPqPDF8OO+UfN9NAfA4wl3QyChD1GXl9rwKQOkbvdlYFV
UFx9u86LNi4ssTmU8p9NtHIGpz1SYMVYNoYy9NU7EVqypGMguDCL7gJt6GUmA0sw
p+YCroXiwL2BJ7RwRqTpgQuFL1gShkA17D5jK4mDPEetq1d8kz9rQYvAR/sTKBsR
ImC3xSfn8zpWoNTTB6lnwyP5Ng1bu6esS7+SpYprFTe7ZqGZF6xhvBPf1Ldi9UAm
U2xPN1/eeWxEa2kusidmFKPmN8lcT4miiAvwGxEnY7Oww9CgZlUB+LP4dl5VPjEt
sFeAhrgxLdpVTjPRRwTd9VQF3/XYl83j5wySIQKIPXgT3sG3ngAhDhC8I8GpM36r
8WJJ3x2yVzyJUbBPO0GBhWE2xPNIfhxVoU4cGGhpFqz7dPKSTRDGq++MrFgKKGpI
ZwT3CPTSSKc7ySndEXWkOYArDIdtyxdE1p5/c3aoz4utzUU7NDHQ+vVIwlnZSMiZ
jek2IJP3SZ+COOIHCVxpUaZ4lnzWT4eDqABhMLpIzw6NmGfg+kLBJhouqz81WITr
EtJuZYM5blWncBOJCoWMnBEcTEo/viU3GgcVRw=3D=3D
=3Dx94R
-----END PGP PUBLIC KEY BLOCK-----

--------------hDr5RUQi30MQZh0ETQ5E4wWV--

--------------D9ZKRkWnidZC6bnnEe9nSMHd--

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

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

iQIzBAEBCAAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmhK8McACgkQszaHOrMp
8lOa0g//S9KXBVIRR5G5TJm0bUihSW5kpXvB7QZ86PSCXg4t7s69iNiTqXjzbxYd
Oplfo1hU12eR57ZiiOe1W009giWBFaB0gCp6bNP/a2JUxcs0AFCQF58aMR/9RL38
oUfbR708RRAL91apxmDgnktdRviFNMKQ5IAq/D2RaIaBXQlDoc1RR0pixIh4XGpq
2Rps0J+YmOvKvlpgSFkzsn6tZbpboY9iPoLPq8/jNNLZTWrHwMcXV2zq53NefZ5K
F5d4phw+QjHX/fNS5zlyG1KsgAZjG2vupi78rtvpoIoew5yryx87Do3ma8elTjgz
7y4YuamrFpbwwhDgXM9lcH0ax5pwqb80M5ToY0Tw8XyZ1De41CQUjET3Dir1Qci5
fxEFf2/iYW1wBOZ+mjmD/Z6rdJ8uzFE1GkuY0LnIidc2/Xz7Yc2Rzrcc8wgs7XFF
aIy2wj2ayRnn6nyS+NE3+JGwiX0W9EX1JNrrGmXPw8rkSAZcO1nah9abiAFhetdg
9Jzz7zcFYi7+TCzib8LbeK6HEgSnr9yjcssJ0V/392claGqtCvGR09XrgrZPoqSN
+BkpGDYo4uxYEpNoEb3uz7YWihkMzRYR7kBum2xPa0lG/bAbK0ZZ3enfi13Z0jFU
BHE3VdzxbcxPaxun00l34mqsKNHJPVpfpVZa4+TA2+UPnI7Jbpw=
=rgLd
-----END PGP SIGNATURE-----

--------------Z18kng6eo8ZvktkXYjDuEZMl--


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 15:24:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 15:24:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013248.1391755 (Exim 4.92)
	(envelope-from )
	id 1uPjn0-0004Jd-Np; Thu, 12 Jun 2025 15:24:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013248.1391755; Thu, 12 Jun 2025 15: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 1uPjn0-0004JW-LB; Thu, 12 Jun 2025 15:24:26 +0000
Received: by outflank-mailman (input) for mailman id 1013248;
 Thu, 12 Jun 2025 15:24: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 1uPjmz-0004JO-HS
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 15:24:25 +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 5220231c-47a1-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 17:24:24 +0200 (CEST)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3a4f71831abso1025302f8f.3
 for ; Thu, 12 Jun 2025 08:24:24 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-748809ebb34sm1570589b3a.123.2025.06.12.08.24.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 08:24:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5220231c-47a1-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749741864; x=1750346664; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=R+7+5fXQw914bqzYhIjU1RBPjs056c2PsR4iTnYCuhw=;
        b=frSvESWdLIP405h0XhfsnE8Hz1WnKyXc0ISLBtpqF/9DnpplrjbxpBbY58NZDgON4E
         7195QPbl4JmDcb8rCiU2lUW+8nMfcwW3abER0soz8QZN51vIrh2WIqNOyVa5Bo5Ajqis
         jZXviEQWaVjjWrC2SMs+4Wl+72Xe5yqpiyfhGidFiETkp8JBRpZ/VQPnnoRCW0PbnqGU
         631MjZDfReVmaQCYuRp5SCgnBAY9zI3PqmgE6mo6PJzuntbXG8hqR420pW3GLWhSxzfg
         Fi51sfA8xbtK8vrT1Q/re4ytOJFqmjA+YyqYwrPw0AIgX+YetcMdVpZGH4FUeFRNJ8BF
         MzkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749741864; x=1750346664;
        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=R+7+5fXQw914bqzYhIjU1RBPjs056c2PsR4iTnYCuhw=;
        b=K+ha8JWvN4pHTR0yjU8Zt/LnmtTTSzjCl7bBFgyUgqbg9RT2hcX0edM0IkY8qbANqP
         un/f0kbEVaqKH0fdEFlEu1SFfLNjjijDCRRldhHDY+mwrXV+4cJ2+ss/+TIQBA9b7Bbr
         0NT68e3zYnoIvg88kY1cQBkcGh+gUCqO3kWjGZSqIHIYCLtnIdhGdHJjfD9a7Xeb3eoz
         sEWoNjwcH9ENO5egHDyQ3crLd1SzHz/Me41DomWGX4lRczT/r0t1Vvr5hedAAuFDF5TE
         RQLK/awQ7OTamCQaDQwCZg8risu2c0veQmk1Qk59lrh+B1C0oD/f3VGE1Ao7vk86SDEa
         /3bg==
X-Forwarded-Encrypted: i=1; AJvYcCV0KOCeV8fcU+0RvSwu4ym6lw5NS1lcSksR3FFINQODRI7R1FBeEdZx+Ld+EU1W40yY78kP8uTRmPM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyEKW035/4JUTYaWd+6cC6RU+ueawZ2bgAzH9rBicgcIHzSaHUY
	RW0+MFtJe/kkTBrCJkUo/7dnb8IEHHA4Waf/Jr4qS1+WilRHiyk7aHgDJjfPmFG5tg==
X-Gm-Gg: ASbGnctfPdLaZN+pjBAd5BcJuuWYMl2W8SsPqIZ/iuoX7knMrAxFKMAduZb3Zim0cU3
	5oCsuP3YbBSmesNCC4EuwZpw9IHgwwod8h4mUIjFEqwancpYQp0kbB1LTnGPu5Ai2nOSiU5uL95
	Jmx5B40/rci6zGXOpv2wWYR1GK8fNvdouZIqldoX2Sclm2b4ToCKsaxdh59lt5gqfxjsvVHZle0
	jng6cSUUEuADT1RQ6AuKV3/Xl3m4WYir0cp9UUs1IQybjOGu9DvfnrZXNG686ybzKKVMTsuA5CF
	JabPwniz7NwX5aePbmS7muoCSJQkPbiy7x9NNatT/naxOjdqyiCDdG6RMpAubW8iNv1OiSsw2Zf
	awqt/KbsyE+ySj3E8YSxmnwmCHL6ZdnUz6p8nmJhRJbGjZ+8=
X-Google-Smtp-Source: AGHT+IE0giuHl921aCiPBemprpP1I4LgU5oYSBi0zRhAHq2HOn3jZ2uQ8B/x9t+DvfvZEG1kporWUA==
X-Received: by 2002:a5d:588d:0:b0:3a4:e1e1:7779 with SMTP id ffacd0b85a97d-3a5607c9b78mr3446793f8f.32.1749741863621;
        Thu, 12 Jun 2025 08:24:23 -0700 (PDT)
Message-ID: 
Date: Thu, 12 Jun 2025 17:24:12 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7] xen/arm: pci: introduce PCI_PASSTHROUGH Kconfig option
To: Stewart Hildebrand 
Cc: Rahul Singh ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Andrew Cooper ,
 Stefano Stabellini ,
 xen-devel@lists.xenproject.org
References: <20250610174635.203439-1-stewart.hildebrand@amd.com>
 <6ac8ffbc-5bd3-4bea-9ade-f31710747291@suse.com>
 <3a203b96-94e3-47c3-92b6-b68141ea3794@amd.com>
 
 <2150be73-e23a-4caa-91a7-8f7c139e4e87@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: <2150be73-e23a-4caa-91a7-8f7c139e4e87@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12.06.2025 17:18, Stewart Hildebrand wrote:
> On 6/12/25 10:58, Jan Beulich wrote:
>> On 12.06.2025 15:39, Stewart Hildebrand wrote:
>>> On 6/11/25 01:23, Jan Beulich wrote:
>>>> On 10.06.2025 19:46, Stewart Hildebrand wrote:
>>>>> --- a/xen/arch/arm/Kconfig
>>>>> +++ b/xen/arch/arm/Kconfig
>>>>> @@ -258,6 +258,16 @@ config PARTIAL_EMULATION
>>>>>  
>>>>>  source "arch/arm/firmware/Kconfig"
>>>>>  
>>>>> +config PCI_PASSTHROUGH
>>>>> +	bool "PCI passthrough" if EXPERT
>>>>> +	depends on ARM_64
>>>>> +	select HAS_PCI
>>>>> +	select HAS_VPCI
>>>>> +	select HAS_VPCI_GUEST_SUPPORT
>>>>
>>>> What about HAS_PASSTHROUGH? Seeing that being selected by MMU, what about
>>>> that connection here?
>>>
>>> Hm, yes. I'm not sure if depends or select would be better?
>>>
>>> 	depends on ARM_64 && HAS_PASSTHROUGH
>>>
>>> or
>>>
>>> 	select HAS_PASSTHROUGH
>>
>> Actually, thinking of it: HAS_* shouldn't be selected based on user choices,
>> imo. Perhaps unless the HAS_* is a sub-feature of the dependent (as in e.g.
>> "select HAS_VPCI if HVM" as we have it for x86). In which case all the
>> select-s here might be wrong to use.
> 
> How about something like this:
> 
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index 3f25da3ca5fd..95a2cd3d006d 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -8,6 +8,8 @@ config ARM_64
>  	depends on !ARM_32
>  	select 64BIT
>  	select HAS_FAST_MULTIPLY
> +	select HAS_VPCI_GUEST_SUPPORT if PCI_PASSTHROUGH

This one may be okay, subject to the Arm maintainers' views.

> +	select HAS_PASSTHROUGH if PCI_PASSTHROUGH

At the first glance this one instead should be ...

> @@ -258,6 +260,12 @@ config PARTIAL_EMULATION
>  
>  source "arch/arm/firmware/Kconfig"
>  
> +config PCI_PASSTHROUGH
> +	bool "PCI passthrough" if EXPERT
> +	depends on ARM_64
> +	help
> +	  This option enables PCI device passthrough

... a "depends on" here, imo. Yet that would go against your intentions,
I think, so doing it the way you have it may be okay, subject to how you
justify it.

> --- a/xen/drivers/Kconfig
> +++ b/xen/drivers/Kconfig
> @@ -13,6 +13,7 @@ source "drivers/pci/Kconfig"
>  source "drivers/video/Kconfig"
>  
>  config HAS_VPCI
> +	select HAS_PCI
>  	bool

Please can the "bool" remain first?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 15:25:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 15:25:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013258.1391765 (Exim 4.92)
	(envelope-from )
	id 1uPjo3-0004tG-5R; Thu, 12 Jun 2025 15:25:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013258.1391765; Thu, 12 Jun 2025 15: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 1uPjo3-0004t9-2b; Thu, 12 Jun 2025 15:25:31 +0000
Received: by outflank-mailman (input) for mailman id 1013258;
 Thu, 12 Jun 2025 15:25: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 1uPjo2-0004t1-Aa
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 15:25:30 +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 76075314-47a1-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 17:25:24 +0200 (CEST)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-442e9c00bf4so9743865e9.3
 for ; Thu, 12 Jun 2025 08:25:24 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a561976805sm2233588f8f.2.2025.06.12.08.25.23
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Jun 2025 08:25:23 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 76075314-47a1-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749741924; x=1750346724; 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=8VlIzjthV+Ge1TJil/PnkbXbdBpQRIbWyK7zS4IxRQk=;
        b=Uemne5UjuvzggsAHjZFnqz9ccx9MIZo4z9Lxe5ChtLqyYVwXij0Yh5br7VrqwOE3vo
         xWTh9XDSFINEgZLhpUPwczk6ys8MZ5TOvgWqocPMzhZFKqQoUys9jacTqd1Cp1iVgDca
         6LFLMUlJeMCBs9PYYxoTUG6AJPN71LhLHGDRE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749741924; x=1750346724;
        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=8VlIzjthV+Ge1TJil/PnkbXbdBpQRIbWyK7zS4IxRQk=;
        b=uPBid0aouw24hpwd4Y7kONwEka3OdDixnMI/fODDAXZkApeQXCcxy7Y3yIveE2AI8h
         cS/0ox36kFlleCEM7ShhY6EnbsKFTXy0YGe0RxxhVx4Q5vpM7y/iWEoZQyEfmu0zUFi+
         nwIvnkLhwIN9i6D597nmjsngMVh8AcjBQwLi1JNrH/NR6q9kKwY01DGyXL7SlV/6togV
         NT5YVHMTNRKzCO4LUAW+TgFo+Ywd8ocFfdtPLUr+/63YSv5J080GW0uT/37VOa9/F0Cv
         Hjwv3tRP4XH/Bd9+/XnQJWH+qHODjr1Nd+HXoihgsXFSh4tNXsXEiRX+9rZ0k460O4AL
         dO7Q==
X-Forwarded-Encrypted: i=1; AJvYcCWzZojmQJZCVNP+lSIGcMz6ApmFXahAOVZLda7bOwnYAB02FEOVh+ufle1QSeCd7r5a8s2XYgc8s18=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz8gD3tT7F/PK12EVCpwm0nF4mTkAMQDwsr8fzccivCwDFPYGPX
	I4YmeZR1adsViSd6rvX1QUKamoduZOT0rBSvfmbqSrNknnP9E/jtn7eE6wG763x5BVE=
X-Gm-Gg: ASbGncsn1dAaEfjiQSATB93mNXt2W2eeouR/pg7ZI7zcjbe5/KOfFn4Bx1Hat4vQ6MW
	LxHfuxYUslh7zrRpGBM1rJfDSlPe+tZzcDqQGXWUq7cYymcVjaRnwPR35oCevmsyKDGx/LOgyn0
	Q6zIAqfG9LGVOuLpcaP90SPwuvY03ObzCuHJDzs6sQZY6Q6fT09bdboqQn85EVkbIMfzJXu9pHw
	ElV9Ieho51MEOGQnAqkLpphTeSJxXI6pNdAajJZkbkmuxosycj7MkqFcH5xCeAoIjEtz7hwQdWz
	Qf4i5XxImiW9HnNI9QLOe/eKElEBHD7dSL1LYMtgRfqz6V8Oi+FrWFLEqbfLi1TEvBmC+m/A8Nu
	rzOpnA6qb76xdNFp1KSdL9MOn/7k1On86tOPwPmFGcXkfgg==
X-Google-Smtp-Source: AGHT+IEqkYP20Fn3x+Ul3bUYLqw1KrSdGqN+6znNGLUcqpftiwDL4jq4kMA2VZncCN+h6LzsZoA2Lg==
X-Received: by 2002:a05:600c:3b9f:b0:441:b3f0:e5f6 with SMTP id 5b1f17b1804b1-4533027be8amr22221675e9.25.1749741923782;
        Thu, 12 Jun 2025 08:25:23 -0700 (PDT)
Date: Thu, 12 Jun 2025 17:25:22 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Tu Dinh 
Cc: Anthony PERARD , xen-devel@lists.xenproject.org,
	Oleksii Kurochko ,
	Community Manager ,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini ,
	Juergen Gross ,
	Anthoine Bourgeois 
Subject: Re: [PATCH v4] x86/hvmloader: select xenpci MMIO BAR UC or WB MTRR
 cache attribute
Message-ID: 
References: <20250610162930.89055-1-roger.pau@citrix.com>
 
 
 <60a346b7-82f5-46ba-84f7-82c449bc0506@vates.tech>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <60a346b7-82f5-46ba-84f7-82c449bc0506@vates.tech>

On Thu, Jun 12, 2025 at 03:12:03PM +0000, Tu Dinh wrote:
> On 12/06/2025 16:57, Roger Pau Monné wrote:
> > On Wed, Jun 11, 2025 at 07:26:06PM +0200, Anthony PERARD wrote:
> >> On Tue, Jun 10, 2025 at 06:29:30PM +0200, Roger Pau Monne wrote:
> >>> @@ -271,6 +279,44 @@ void pci_setup(void)
> >>>               if ( bar_sz == 0 )
> >>>                   continue;
> >>>
> >>> +            if ( !xenpci_bar_uc &&
> >>> +                 ((bar_data & PCI_BASE_ADDRESS_SPACE) ==
> >>> +                   PCI_BASE_ADDRESS_SPACE_MEMORY) &&
> >>> +                 vendor_id == 0x5853 &&
> >>> +                 (device_id == 0x0001 || device_id == 0x0002) )
> >>
> >> We don't have defines for 0x5853 in the tree (and those device_id)?
> >> Maybe introduce at least one for the vendor_id:
> >>
> >> These two names are use by QEMU, OVMF, Linux, for example.
> >>
> >> #define PCI_VENDOR_ID_XEN           0x5853
> >> #define PCI_DEVICE_ID_XEN_PLATFORM  0x0001
> >>
> >> There's even PCI_DEVICE_ID_XEN_PLATFORM_XS61 in Linux
> >
> > You mean in the public headers?
> >
> > For Device IDs we have ranges allocated to downstream vendors, I'm not
> > sure we want to keep track of whatever IDs they use for their devices.
> > OTOH, not tracking those IDs here means OSes are likely to miss
> > additions of new Xen platform PCI devices?
> >
> 
> The devices starting from ID c000 are supposed to be xen_pvdevice, which
> are separate device types that work differently from Xen platform PCI
> devices. So I think you only need to check for
> PCI_DEVICE_ID_XEN_PLATFORM{,_XS61} unless another platform PCI ID gets
> defined some day.

It's not the check here, but rather what would be defined in the newly
added header what I don't know.

Even if not used here, should the other PCI device IDs be listed
together with the platform PCI device ones?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 16:14:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 16:14:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013269.1391776 (Exim 4.92)
	(envelope-from )
	id 1uPkYs-0003n4-JE; Thu, 12 Jun 2025 16:13:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013269.1391776; Thu, 12 Jun 2025 16:13:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPkYs-0003mx-Gc; Thu, 12 Jun 2025 16:13:54 +0000
Received: by outflank-mailman (input) for mailman id 1013269;
 Thu, 12 Jun 2025 16:13:53 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uPkYq-0003mr-Un
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 16:13:52 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uPkYp-00FWFX-27;
 Thu, 12 Jun 2025 16:13:51 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (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 1uPkYp-003geS-06;
 Thu, 12 Jun 2025 16:13: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=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding:
	Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date;
	bh=pkwJg1Z7WP8ceKiFmJPtTot2/IJTJqUJPo/zaZ1Avlg=; b=b9Y6QPnDqIdCQN1/qrvFCsgUI+
	UI7b/kBmdLZ8VLNIjqFO5/9gIFBLMMXRyjJsE+jfE2YQCoKyPOqq3L8fcQZqHvVNcWnURtfjT+Rk3
	EytdmY9yC73mQ2p58uz6kFUxi/klGbsFfx4zlGYBOZQolJ1feM9hxy3hJHyvGfSILg+w=;
Date: Thu, 12 Jun 2025 18:13:48 +0200
From: Anthony PERARD 
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= 
Cc: xen-devel@lists.xenproject.org,
	Oleksii Kurochko ,
	Community Manager ,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini ,
	Juergen Gross ,
	Anthoine Bourgeois 
Subject: Re: [PATCH v4] x86/hvmloader: select xenpci MMIO BAR UC or WB MTRR
 cache attribute
Message-ID: 
References: <20250610162930.89055-1-roger.pau@citrix.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Thu, Jun 12, 2025 at 04:56:17PM +0200, Roger Pau Monn wrote:
> On Wed, Jun 11, 2025 at 07:26:06PM +0200, Anthony PERARD wrote:
> > On Tue, Jun 10, 2025 at 06:29:30PM +0200, Roger Pau Monne wrote:
> > > diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> > > index c388899306c2..ddbff6fffc16 100644
> > > --- a/docs/man/xl.cfg.5.pod.in
> > > +++ b/docs/man/xl.cfg.5.pod.in
> > > @@ -2351,6 +2351,14 @@ Windows L.
> > >  Setting B with the default device_model "qemu-xen"
> > >  requires at least QEMU 1.6.
> > >  
> > > +
> > > +=item B
> > > +
> > > +B Select whether the memory BAR of the Xen PCI device should have
> > > +uncacheable (UC) cache attribute set in MTRR.
> > 
> > For information, here are different name used for this pci device:
> > 
> > - man xl.cfg:
> >     xen_platform_pci=
> >         Xen platform PCI device
> > - QEMU:
> >     -device xen-platform
> >     in comments: XEN platform pci device
> >     with pci device-id PCI_DEVICE_ID_XEN_PLATFORM
> > - EDK2 / OVMF:
> >     XenIoPci
> >         described virtual Xen PCI device
> >         But XenIo is a generic protocol in EDK2
> >     Before XenIo, the pci device would be linked to XenBus, and
> >     loaded with PCI_DEVICE_ID_XEN_PLATFORM
> > - Linux:
> >     Seems to be called "xen-platform-pci"
> > 
> > Overall, this PCI device is mostly referenced as the Xen Platform PCI
> > device. So "xenpci" or "Xen PCI device" is surprising to me, and I'm not
> > quite sure what it is.
> 
> I can do xen_platform_pci_bar_uc, but it seems a bit long.

I don't think it matter much how long it is, it is just a word that is
surly copy-past from the man page. What I think matter more is that it's
descriptive enough and match the existing option name for the same
device, which is "xen_platform_pci".

> > > +    /* Select the MTRR cache attribute of the xenpci device BAR. */
> > > +    bool xenpci_bar_uc = false;
> > 
> > This default value for `xenpci_bar_uc` mean that hvmloader changes
> > behavior compared to previous version, right? Shouldn't we instead have
> > hvmloader keep the same behavior unless the toolstack want to use the
> > new behavior? (Like it's done for `allow_memory_relocate`,
> > "platform/mmio_hole_size")
> > 
> > It would just mean that toolstack other than `xl` won't be surprised by
> > a change of behavior.
> 
> My plan was that we didn't need changes to XAPI to implement this new
> mode, but given the comment I will change to keep the previous
> behavior in absence of a xenstore node.

Why would guests created with XAPI get the new behavior, but guest
created with libxl have to stick with the old one?

I do like that there's an option for libxl to choose between the old and
new behavior, and allow to revert in case someone got an issue for a
particular guest, but otherwise, it is probably better to have the same
default for both XAPI and libxl.

> > > @@ -271,6 +279,44 @@ void pci_setup(void)
> > >              if ( bar_sz == 0 )
> > >                  continue;
> > >  
> > > +            if ( !xenpci_bar_uc &&
> > > +                 ((bar_data & PCI_BASE_ADDRESS_SPACE) ==
> > > +                   PCI_BASE_ADDRESS_SPACE_MEMORY) &&
> > > +                 vendor_id == 0x5853 &&
> > > +                 (device_id == 0x0001 || device_id == 0x0002) )
> > 
> > We don't have defines for 0x5853 in the tree (and those device_id)?
> > Maybe introduce at least one for the vendor_id:
> > 
> > These two names are use by QEMU, OVMF, Linux, for example.
> > 
> > #define PCI_VENDOR_ID_XEN           0x5853
> > #define PCI_DEVICE_ID_XEN_PLATFORM  0x0001
> > 
> > There's even PCI_DEVICE_ID_XEN_PLATFORM_XS61 in Linux
> 
> You mean in the public headers?
> 
> For Device IDs we have ranges allocated to downstream vendors, I'm not
> sure we want to keep track of whatever IDs they use for their devices.
> OTOH, not tracking those IDs here means OSes are likely to miss
> additions of new Xen platform PCI devices?
> 
> I could introduce public/pci.h to contain those IDs, but I would like
> consensus on what should be there, otherwise this patch will get
> stuck.

I guess, just start with adding the vendor_id define in this same file
(pci.c), that would be a good start, it would give a name to an
otherwise magic number.
Reading `vendor_id == PCI_VENDOR_ID_XEN` is better than reading
`vendor_id == 0x5853`.

If for some reason, we want to use the value in a different part of the
repo, we could introduce or edit a common header and move the define
there.

For the device ids, using a define is less of a need, we would at least
know we have a condition on Xen specific PCI device.

This patch is only about a single device, isn't speaking about ID of
other device a bit out of scope? And anyway, there's already a document
about those, that is "xen-pci-device-reservations.7.pod".

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 16:28:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 16:28:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013295.1391786 (Exim 4.92)
	(envelope-from )
	id 1uPkmh-0005Xs-OF; Thu, 12 Jun 2025 16:28:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013295.1391786; Thu, 12 Jun 2025 16: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 1uPkmh-0005Xl-Kp; Thu, 12 Jun 2025 16:28:11 +0000
Received: by outflank-mailman (input) for mailman id 1013295;
 Thu, 12 Jun 2025 16: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 1uPkmg-0005XG-K1
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 16:28:10 +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 39e85d12-47aa-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 18:28:09 +0200 (CEST)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-451d41e1ad1so10054065e9.1
 for ; Thu, 12 Jun 2025 09:28:09 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-4532e24b0c8sm24824605e9.24.2025.06.12.09.28.07
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Jun 2025 09:28:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 39e85d12-47aa-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749745688; x=1750350488; 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=yX+HGYhEj8oE3ckInotNgfcoJU6/NrmkhoSfnpgbDYw=;
        b=UfG9IzbfgJUaxBFOxpxlS0zbYjBMat6SQecA5GUx+90vszbS9UeoQyxYd+j/UK8JLg
         r5wSfO5Tkb3FPlteMXDS6SEDgvPxRyOCGf/2F1Jv46qEOgcfAMpU9VAp7l3Aaa9Iu07N
         P9ctQIIITb1vbEpH0/apzYp+5eEc0PBugpUYM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749745688; x=1750350488;
        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=yX+HGYhEj8oE3ckInotNgfcoJU6/NrmkhoSfnpgbDYw=;
        b=Ci9+tbzCC1ZTblAv4OUFbl8/gxVL+4MCLclfTF7yzHxvW4WJx28mWbzmebeH8ysj/d
         HIXiIpqV7pCa9HoyhlQBo42irxthm0E8TrlJUN+XWrXzuDZXew5Ek47MGF/SI4lChXbz
         yuineu2FV6K4620CJWPnK4r8Sbe5QpU98/geU+yLldNShX78mBjfwYwFymyf7BUJEQHh
         gt3fWC6wuaytPDum5ty+npKhoLq/VEN2HLJ7OsWKFtOVo2cBTyvWRJ7uIbPDW4wq8/oh
         NlsMAAlU14zKW74mezwTc+gecwWGuU/kuUicawfIc+jsaye8B6UVeM03qv/kDcqsn6oN
         u3Mw==
X-Gm-Message-State: AOJu0Ywwu+37eRfdGDOj7Ej7ypcm0Rf2DLAKoNu2NftCri0upsd/YvTd
	eDQVnerTedqFilc1Wzu4hkQN5sfE6P1dEa/5+Xc9P7hiRfwVJL9v32/8jy7aZDH7Xqw=
X-Gm-Gg: ASbGnct60mbUzuavij6KJoowQfZeESkFAZRZ1410S8rysP0cAo/g5xUXzSkWl/blXYZ
	G2fetDv1aNGgil7r+REGuIIr1L42xj7JQwAoqmunqZa+h15hcHX60h8c5x1jHHxINtokIBjXEnW
	mFGoYYXC1GZ7VK/lnpTi0QFDywCL6gXtQ3g4x/2NC0tbcfaDenjUwwwMZKRo/JgFCMdERS9b6lB
	Hb2l8b6liQW67EFFxdhCbUwm6QZy3g4L0HR1GBuzwVkUnzdHm6JGHjHYihJwl7t+sg2ITQuX1xs
	fQOlQ0LGpTXg94cXLsYsB6cakiv6bDIRi0XVqxdmWlplQErRWHV7Wa6XbdaQ5yk1KqvNM9PkxNj
	xSr5c1sFVjCRbxzgV4M/DZI/YTMQtrGjiBSs=
X-Google-Smtp-Source: AGHT+IHpsNkYetHTJNkoIyB2/3PbxcHS2hV+aDm+Fg0rnryfcSh8IFBRhMciAuh2W7NsGy5wIvzoug==
X-Received: by 2002:a05:600c:1c8c:b0:43c:fe90:1282 with SMTP id 5b1f17b1804b1-453248a1871mr71475375e9.7.1749745688426;
        Thu, 12 Jun 2025 09:28:08 -0700 (PDT)
Date: Thu, 12 Jun 2025 18:28:07 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Anthony PERARD 
Cc: xen-devel@lists.xenproject.org,
	Oleksii Kurochko ,
	Community Manager ,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini ,
	Juergen Gross ,
	Anthoine Bourgeois 
Subject: Re: [PATCH v4] x86/hvmloader: select xenpci MMIO BAR UC or WB MTRR
 cache attribute
Message-ID: 
References: <20250610162930.89055-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 Thu, Jun 12, 2025 at 06:13:48PM +0200, Anthony PERARD wrote:
> On Thu, Jun 12, 2025 at 04:56:17PM +0200, Roger Pau Monné wrote:
> > On Wed, Jun 11, 2025 at 07:26:06PM +0200, Anthony PERARD wrote:
> > > On Tue, Jun 10, 2025 at 06:29:30PM +0200, Roger Pau Monne wrote:
> > > > diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> > > > index c388899306c2..ddbff6fffc16 100644
> > > > --- a/docs/man/xl.cfg.5.pod.in
> > > > +++ b/docs/man/xl.cfg.5.pod.in
> > > > @@ -2351,6 +2351,14 @@ Windows L.
> > > >  Setting B with the default device_model "qemu-xen"
> > > >  requires at least QEMU 1.6.
> > > >  
> > > > +
> > > > +=item B
> > > > +
> > > > +B Select whether the memory BAR of the Xen PCI device should have
> > > > +uncacheable (UC) cache attribute set in MTRR.
> > > 
> > > For information, here are different name used for this pci device:
> > > 
> > > - man xl.cfg:
> > >     xen_platform_pci=
> > >         Xen platform PCI device
> > > - QEMU:
> > >     -device xen-platform
> > >     in comments: XEN platform pci device
> > >     with pci device-id PCI_DEVICE_ID_XEN_PLATFORM
> > > - EDK2 / OVMF:
> > >     XenIoPci
> > >         described virtual Xen PCI device
> > >         But XenIo is a generic protocol in EDK2
> > >     Before XenIo, the pci device would be linked to XenBus, and
> > >     loaded with PCI_DEVICE_ID_XEN_PLATFORM
> > > - Linux:
> > >     Seems to be called "xen-platform-pci"
> > > 
> > > Overall, this PCI device is mostly referenced as the Xen Platform PCI
> > > device. So "xenpci" or "Xen PCI device" is surprising to me, and I'm not
> > > quite sure what it is.
> > 
> > I can do xen_platform_pci_bar_uc, but it seems a bit long.
> 
> I don't think it matter much how long it is, it is just a word that is
> surly copy-past from the man page. What I think matter more is that it's
> descriptive enough and match the existing option name for the same
> device, which is "xen_platform_pci".

I've already adjusted everything to xen_platform_pci_bar_uc, plus the
text to s/Xen PCI/Xen platform PCI/.

> > > > +    /* Select the MTRR cache attribute of the xenpci device BAR. */
> > > > +    bool xenpci_bar_uc = false;
> > > 
> > > This default value for `xenpci_bar_uc` mean that hvmloader changes
> > > behavior compared to previous version, right? Shouldn't we instead have
> > > hvmloader keep the same behavior unless the toolstack want to use the
> > > new behavior? (Like it's done for `allow_memory_relocate`,
> > > "platform/mmio_hole_size")
> > > 
> > > It would just mean that toolstack other than `xl` won't be surprised by
> > > a change of behavior.
> > 
> > My plan was that we didn't need changes to XAPI to implement this new
> > mode, but given the comment I will change to keep the previous
> > behavior in absence of a xenstore node.
> 
> Why would guests created with XAPI get the new behavior, but guest
> created with libxl have to stick with the old one?
> 
> I do like that there's an option for libxl to choose between the old and
> new behavior, and allow to revert in case someone got an issue for a
> particular guest, but otherwise, it is probably better to have the same
> default for both XAPI and libxl.
> 
> > > > @@ -271,6 +279,44 @@ void pci_setup(void)
> > > >              if ( bar_sz == 0 )
> > > >                  continue;
> > > >  
> > > > +            if ( !xenpci_bar_uc &&
> > > > +                 ((bar_data & PCI_BASE_ADDRESS_SPACE) ==
> > > > +                   PCI_BASE_ADDRESS_SPACE_MEMORY) &&
> > > > +                 vendor_id == 0x5853 &&
> > > > +                 (device_id == 0x0001 || device_id == 0x0002) )
> > > 
> > > We don't have defines for 0x5853 in the tree (and those device_id)?
> > > Maybe introduce at least one for the vendor_id:
> > > 
> > > These two names are use by QEMU, OVMF, Linux, for example.
> > > 
> > > #define PCI_VENDOR_ID_XEN           0x5853
> > > #define PCI_DEVICE_ID_XEN_PLATFORM  0x0001
> > > 
> > > There's even PCI_DEVICE_ID_XEN_PLATFORM_XS61 in Linux
> > 
> > You mean in the public headers?
> > 
> > For Device IDs we have ranges allocated to downstream vendors, I'm not
> > sure we want to keep track of whatever IDs they use for their devices.
> > OTOH, not tracking those IDs here means OSes are likely to miss
> > additions of new Xen platform PCI devices?
> > 
> > I could introduce public/pci.h to contain those IDs, but I would like
> > consensus on what should be there, otherwise this patch will get
> > stuck.
> 
> I guess, just start with adding the vendor_id define in this same file
> (pci.c), that would be a good start, it would give a name to an
> otherwise magic number.

OK, I think I've misunderstood from your previous reply that you
wanted me to introduce a public pci.h header to contain those values.

> Reading `vendor_id == PCI_VENDOR_ID_XEN` is better than reading
> `vendor_id == 0x5853`.
> 
> If for some reason, we want to use the value in a different part of the
> repo, we could introduce or edit a common header and move the define
> there.
> 
> For the device ids, using a define is less of a need, we would at least
> know we have a condition on Xen specific PCI device.
> 
> This patch is only about a single device, isn't speaking about ID of
> other device a bit out of scope? And anyway, there's already a document
> about those, that is "xen-pci-device-reservations.7.pod".

Yes, but if I had to add a new header I got the feeling I would get
questions about which device IDs should be listed there.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 16:31:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 16:31:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013301.1391796 (Exim 4.92)
	(envelope-from )
	id 1uPkpk-00078P-5Q; Thu, 12 Jun 2025 16:31:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013301.1391796; Thu, 12 Jun 2025 16:31: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 1uPkpk-00078I-1R; Thu, 12 Jun 2025 16:31:20 +0000
Received: by outflank-mailman (input) for mailman id 1013301;
 Thu, 12 Jun 2025 16:31: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 1uPkpi-00078C-7E
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 16:31:18 +0000
Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com
 [205.220.165.32]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a8d3bc87-47aa-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 18:31:16 +0200 (CEST)
Received: from pps.filterd (m0246627.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 55CEtcCZ003369;
 Thu, 12 Jun 2025 16:31:03 GMT
Received: from iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta03.appoci.oracle.com [130.35.103.27])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 474c14j3v1-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Thu, 12 Jun 2025 16:31:03 +0000 (GMT)
Received: from pps.filterd
 (iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2)
 with ESMTP id 55CFJPiE037808; Thu, 12 Jun 2025 16:31:01 GMT
Received: from cy7pr03cu001.outbound.protection.outlook.com
 (mail-westcentralusazon11012025.outbound.protection.outlook.com
 [40.93.200.25])
 by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id
 474bvj27uy-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Thu, 12 Jun 2025 16:31:01 +0000
Received: from DS0PR10MB7224.namprd10.prod.outlook.com (2603:10b6:8:f5::14) by
 MW4PR10MB5882.namprd10.prod.outlook.com (2603:10b6:303:18f::8) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8813.20; Thu, 12 Jun 2025 16:30:58 +0000
Received: from DS0PR10MB7224.namprd10.prod.outlook.com
 ([fe80::c57:383f:cfb2:47f8]) by DS0PR10MB7224.namprd10.prod.outlook.com
 ([fe80::c57:383f:cfb2:47f8%5]) with mapi id 15.20.8835.023; Thu, 12 Jun 2025
 16:30: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: a8d3bc87-47aa-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=
	corp-2025-04-25; bh=8/efdxVOKCXMCVQeo5Pd9gMMFxo4WfeXPv0wYf5eTsA=; b=
	IcTmg0QNRhqAvGriwOmSwHhPqVjs/r94x/+OmGnkTrlrZRmZXXLC+2+6zJ1LsmSZ
	5jDHjiwgIH+vx7S+EwtTG3jRvTxdmPNXDJ9/wRfN+LDu+2bv8UQiWg8gnU3hTR7v
	VRaRng+SAbotjnno6BCM+/iR5K+wN9p4WtErJhKhLwJK/pEViCjMHVdcaCSseGh9
	OJqLXUWjN+oHZsH6tm0iBOBLjJwVO1vx2mtqcggEoen3riGdbl9i3cHDmRmokeou
	2lFWQ5LldRZ8AyeBJeb5JEaFlilioB3waHdDAEFK6CEWplXWIhPC0ATAgkhDoHk0
	OPVhKEzt8NjYJ9K/Ki6D2Q==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=KRKeP6UYQ9PiF1sIHie5HqNxQe8lljblKWFsP+/PxaJuBWbmXotEb0uqbSbz0nZ6edW2DHH1//OXVPGLlBgaCt8/l4W11g3FP8V+u21TokPeCIyJTuYAmavlPyqa3JBe11bLvmkaTWgN/OSr7bOko/1zsy+TX22EBz3BI7AYj8H0P8/Lm6SXTywJfTtCa7kmxtAVw86hdR+mIKnX3WDQM/lTgDU9rFlpa2lVJ9WONWvURP4U50w5QInof1EVsd9W5KCKaEag0jrX0yGSrFx9iI9QcIdIadZlJPgWnGPdOQTipt6PxiVSp9D0L/hF/+kIbNiKY4R6E26wwhLnpF6E8g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=8/efdxVOKCXMCVQeo5Pd9gMMFxo4WfeXPv0wYf5eTsA=;
 b=oXiPHB4NEA89/N93uWuCcOtPnsxgRxuSMICzatm0zuQgzjqRONL664y0zAyeHTHX+DWi64NThH+AYMWY2SlXOIvdfeGZ9CYB+kFfwbpZwkkgsLiLHG/ecvezTPJAzDaP2/BbjvWz1+9vxt3r+qTKqHaT3ojRqtTi7NUHD1XYYdLWpMOk4ynu0DhJrJemFzBTjZ0sAMSRLKE1EHRwLxoHk9tAVsh3vdaYf1bYnkkyj+OzXoo4+5BRe2gfCG5d5spuy1PPg1I9mu8Q1UvKLbcDzqm1Rlv6sBQnWZ4X5jd5pbpj01usLbtkynLFRVrFiamBh8gyoyTcd53ZnNU80uLc6g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=8/efdxVOKCXMCVQeo5Pd9gMMFxo4WfeXPv0wYf5eTsA=;
 b=D2TVXGOqREqPTb3/mm8DXoCg/zd84URUNhOXzLz808MLNk0Wvui9957G7hHD9u33Rdl7WImklNBEMr6DtLCaUeOkpd+s0Wrqj1oXjixMJdQRMk1FFuMgCyDwZYlWrYWpGysJ32YRslPKd20VSYMTVra4rJzbg4YwMq9xKaf7GCI=
Message-ID: <81a3551d-a60c-4aa9-8376-fc5e5550abb1@oracle.com>
Date: Thu, 12 Jun 2025 09:30:55 -0700
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 04/22] x86/boot/slaunch-early: implement early
 initialization
To: Sergii Dmytruk 
Cc: xen-devel@lists.xenproject.org, Jan Beulich ,
        Andrew Cooper ,
        =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
        "Daniel P. Smith" ,
        trenchboot-devel@googlegroups.com
References: 
 <16a544876163afece619d50f80869aaacc9c797c.1748611041.git.sergii.dmytruk@3mdeb.com>
 <5792bec7-cd2f-4d27-aa3b-f417b07c8ea8@oracle.com> 
Content-Language: en-US
From: ross.philipson@oracle.com
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: PH0PR07CA0090.namprd07.prod.outlook.com
 (2603:10b6:510:f::35) To DS0PR10MB7224.namprd10.prod.outlook.com
 (2603:10b6:8:f5::14)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS0PR10MB7224:EE_|MW4PR10MB5882:EE_
X-MS-Office365-Filtering-Correlation-Id: 50bac053-24e0-4e7c-83a9-08dda9ce829d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?QVNBRFJEcDBlNWZNbHRKb0RJUC90WlVGeHMycFlSNUxKZUZwSCttYzlGN3hv?=
 =?utf-8?B?emhWYkVxMm5yU3dQREV2WklrcUVjMStzS2pDZEhWZ2VYZXc4T2lwQ2VFMUpY?=
 =?utf-8?B?K1VTVmR6SVYwbE1FSVg0bVRTQ1VnN2FyU2hkUk93QUZSc0F6TkpEWWgybjZE?=
 =?utf-8?B?dmpiZ0FMRndiK0pWMFJ0YmxSajVJbnBzSWYwTk1xTCtQRzh2WUVhYXM2SUFS?=
 =?utf-8?B?NENpWUVxWHhRVit1Y01IVmlPV0xMeDV3OCtrRGozSTlEUWx3STdzajkvRXU2?=
 =?utf-8?B?SFZFMEg2VE5RdGRvQnNtMjVyb3ZINnBSNWZaSEVaeWl4ZW03cG4xM1BFTGtj?=
 =?utf-8?B?VU1kNjgxOFh5QVRMMkhuTkRWc2ZmWTFtN3ZzdmpGM1QxT3c1dkRxNjIxcFV2?=
 =?utf-8?B?aTJJMTIyUWdjWEdKdll0Zi9kZUhGNGpMOUVYVFRuMnlEdy9CRjkvS2VFTjJU?=
 =?utf-8?B?U2N1RC9VbjYxK1JqOFNoQTZZYmEyTkl5Z010ZkhPRXM4WmJwZDNGTmN3QlRO?=
 =?utf-8?B?RmpRZko5aStpN3NsWHRrZ1UvbEJFMTNjbTQvUmNhQzc0b3dJYmNxUGxCQzNo?=
 =?utf-8?B?TmZTR2RoWklMUFpwTWNwYjdtK0g5Sm9vRlNxN2FQT014enIyeVE0d0tjSUdn?=
 =?utf-8?B?eXBFWjdPWEtXclhFRDVFaUU3MEl6VWFYdU1CQlF5Q3RUN2RydHhnUkZtZW9J?=
 =?utf-8?B?Wlg3d00vZ0FyQ1Frd1M5WkM0K3hsS29oUGdiaE9pMXVoQ1pVUzMzcUgvVHdw?=
 =?utf-8?B?dXVpK3c3STRnNVMydXhMd1hvRnRHRThsTEg2aEJSbVRzSnZoR1pGQVFjSGZh?=
 =?utf-8?B?ZzMrbHNkQlBRRkxaRkpGdzk1RTh2WEVPVEp3SEVXSEszb2VyUWd1YmQzbGtF?=
 =?utf-8?B?cHIxWWxBQmNDRXU1WEJIQUpWT2x1bksxUk5XUVF0TVBrNkF4NXNQY3R5WUJK?=
 =?utf-8?B?d3paQjRKWGFpdGlLOS9SS1VNN1RRd1ZOUmtYYm1yREszN2l3UkF6dmJDaTlP?=
 =?utf-8?B?VlVnRUhwZ1dqWExMOHVaZ1oxdzZmOUsvL09UTHd2Z3lPcFo2Z0RrNnJHYW9a?=
 =?utf-8?B?S0FJMktOZjAxdElDNVNKeHMwdlQ5Yjg1RGxHcjVTRDlqcWdTaWxibVVOdGI2?=
 =?utf-8?B?TG5ldlhodmlySklmS0IxeXZTY0I1WkZuZUNKNEJuZndNZHVvVklnd3VHZmhD?=
 =?utf-8?B?LzEyQVRSL1A5cjVKN1k0MDRhbWpXeTJGQjR5a2VuVllMcENQL0VURzZhYmhE?=
 =?utf-8?B?SFBJanBYYi9nb2c4ZmhvM3ZqOHpmclNwSnF5U3I5ODZVM0VRbTZreVg2QU1y?=
 =?utf-8?B?N3JTZDI4NCtUREFEdTFPL2k2TnFjaVNtOXZmeXllVWJ2d0lBREpKNE5aOWha?=
 =?utf-8?B?SW96RGV0Y2JmMEpLTStBaUc0OXZPMVhmY25CZGhnb05uSTYySDU5NVlKVDgy?=
 =?utf-8?B?NEhIMUMzd3A1VFpTOW9PR3BWRTdjT29sUk1STVl5SW85V1VYYkhnbmRheDdD?=
 =?utf-8?B?Wk1wclZ3L3B4b0E5QzFIWFl6T2E3M1VJd0xDSjhXK2dOd0FJczFUbkY4RGZP?=
 =?utf-8?B?ZnNOT0c1VlF6K1NWcmorUm9JSWRqM3N3V3JwVWt6TFVncnBaYlBjbUdTZDVX?=
 =?utf-8?B?Y3doVlhqUGlpTk5IUXVUZHU4c1JWSTNRb3B0akY5ZmpncUxUTGg1UXRROHlz?=
 =?utf-8?B?TU9nSndoaFhnaEdicVB2TndGYWg5YWFkV3RydWNhV3ZqSldXcHg4Q1BvVlIy?=
 =?utf-8?B?ZzRyNHhiSUlGbVQzazRvdmhJSTMrY1h5dUlld0NwMThhRHdDYWxrU1ZmSmQ2?=
 =?utf-8?B?ejJZZkliVWMvUEN2bHVCLy8yT1YxZjIvazcxNGgyYnVLOUxBeU0xMnMzdmEv?=
 =?utf-8?B?YmtZdzdKUDY2UjdRaGN5dVRNeWxTczdqd2poM1NWVWhzTmREZlJzUVhrL2h5?=
 =?utf-8?Q?EcZgXgN4tWM=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS0PR10MB7224.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?bDhHblI1KzA5M1hHdTZuRUFjSXQrQnVhNzh0OHJKNDN6V2kxK01ZVFJRR1Vk?=
 =?utf-8?B?RFZpaHZ1R0JxcCtwbjkxUDdrRXNMa3RyUjUrQlpVUUJEdGJ6MjhobnBmdThx?=
 =?utf-8?B?MXdlcnBRNko5MndGdFBqMXBvMllUek5BenpodFVwaFNsUDBxNCtRMFFjN1Bs?=
 =?utf-8?B?TWFpb2c5UlVMMm43N01TNU1OZHMxZEFSYzNDaU9adGxPbTliam5BV3g2Vmoy?=
 =?utf-8?B?d3dOUC9wTnhQRFdHdGRTdDA0VGJVNEpYZlNNS2FoT0w2VXd1WTNSNkRZRWU0?=
 =?utf-8?B?NTJWcUVkYzVjZ01pU3hFVjVJRGFTZWhIaTYzS0x3U0hndGEwTE1KNDRWd3JZ?=
 =?utf-8?B?TmFUZXNiT01Mb3JtZHM0MVpudGRjZEdhWmZzWjk1TUZHUkZhN3phWm9TeXpD?=
 =?utf-8?B?Qkc3SUR1Tm0yQXQzTnUyeWhvWFVPdm92WWluQTIyT2xwWm1hVmhYZHBhWEgy?=
 =?utf-8?B?VCtmSHVrYzJqWk5OSWVIcXJ2RmdDbVVuK0RPNHRMVkl1cWxvL0NYK0k3cWRI?=
 =?utf-8?B?TTlNQ00wT053QWtTdHFIa0ZnZy9qaFJyN3BET3Jndi9yblYrTWp5R2tEd3hR?=
 =?utf-8?B?QXlDQ0pHcWRuVlQ5dnU4QlVNU1F3WGNDSkJadUYzellOSGlDZEo4SWZPdkFM?=
 =?utf-8?B?OTR4Z3RUSUFaS3dBaTVuYkZKckRseW5ac3VBMTN2Qlk3RVg5K3dCVGN5aEUr?=
 =?utf-8?B?dVU2ZWlObk9tRURSUmgvYU5RanhxNkJxMytIV2xkamNUYkNpNkVBaDhNWUJr?=
 =?utf-8?B?RXRQaHVweDhiekR1UGVBSUp2WnJpK25ST0dZVjREb3haQm1yODVUM3hhaElH?=
 =?utf-8?B?Q3U1bTAvSTcwZVpUVGJGTE5JelpJQVlTVnZrVExZaWlRbmlmck1QM3pQdjhy?=
 =?utf-8?B?aEpwZXRFUUdBVDhDRXA4OHI1M09yRHdBcUFhQVg4MkpyRW9VNTJiSlBmaU4y?=
 =?utf-8?B?UFB1NHRIVG1acDF0em5qRDQ4a1Vpc2xybUF0ZXBKTHN6Uld3eHR1YVVmQXR0?=
 =?utf-8?B?YXFzY3JKeWlEWWVobm54bjd2cmw3NTBKekhHTkxMRjNZZDQ4T1J3bnNmTUFm?=
 =?utf-8?B?cnFFejNsdmZOd2hzYk50NHJSWnNvZS8rakNCTWg0VHVTUEFYak8wUVkwSU1O?=
 =?utf-8?B?dGFybWNSZ28yVUR1TDFIb3pRYWxmVlZpbSsxempYQ1BLRWpNOUxYZDAvOVg5?=
 =?utf-8?B?WmtqNU85cmVwL2VXUXk1bU5uOFpyYmE2VEJhSTFScHFxVDRnSFdHcWxJdnNO?=
 =?utf-8?B?N2V2UUdZajhJbS9IRkdQTGdremxKMFRXK3ppbkd3T3JNTlFYbEwvUTNycm5m?=
 =?utf-8?B?QzBDWkRXdnFrUTFFUWk2VmhQQ01DSHFCYjV1V2Y4YnN6UW9oTjdTVENaM25C?=
 =?utf-8?B?TDA3K0d3WC9hcWdLUUpEaFpMT2NpYzZMTGFXUG44YXNDZmVXdmxpTzNIWVl4?=
 =?utf-8?B?aTNUeFZ0aXRwUkFRb1JCNE1uSTYxNHNhcjBIZzZIUjdtSXB5Y3VYdnArQkJq?=
 =?utf-8?B?ZW1rUEcxRkkrdVR6bnd4dm5RS2pmM2NaTHVkYmE3eXlsblpPWjBTcXk1WjVT?=
 =?utf-8?B?dzRsWklRdy9HdmR5bGRiNUN1UmlOOGwrTG0rUmxzWkRwaVFaY1d0c1FzRWJ2?=
 =?utf-8?B?dFNqUmdrZ3cvZHVORXRqR2lWeGIyNjJROVhiZnYvZUJZK1UyampYTEhOZGoz?=
 =?utf-8?B?Nmk4NE5XZ2w1VFZucC9FL2xrRG9Qc2lIRHdyVlhqZExjWERydFZhcGxmcSt1?=
 =?utf-8?B?alMrNUxwS0VYclIzR1lhLzN6eDIvdElYcVRPY3BRVlN2NVB4REFzaDZRSUNB?=
 =?utf-8?B?V2w5ZDBmMVduUXRJOE12dVJCalE5YlRWcnVtQ1FtZEc2YW13UHlIR21ScTNE?=
 =?utf-8?B?RkZjVERFbDF3OXRYQ3pUU21DbmhHdWR0U282NXhIRWNpdnArcHRKRG53bHFy?=
 =?utf-8?B?ZDRpNXZUay9SUU1KRWljN3hjRm1uN0dlSzFWSzlOZGNmTHd0elQzR3NDUmZs?=
 =?utf-8?B?L2xUa3ZtVFZ4dEpiRWw4bVQzYzAweXltcGMrdkJYcmxEREM3cmdUc3hUVmZB?=
 =?utf-8?B?MmllNy82bUZPQ0p6aERtUHRkRU9oeWwvUXBaZDg3ajIxb1haVi8vcEIwU2dl?=
 =?utf-8?B?WDZmb3MzbllyditOek1ZQlF6amg0S0g4SExVRHloZkk2aUgvY1FYR0NoZXhn?=
 =?utf-8?B?eFE9PQ==?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	4Bvo9ZJHcPrSvyamj0CrOXBHj6susR7oXIsvzRjGsw+9gdfhoF2c60mPB2vBs8YrupfXAhNgxMRirpvJ0vcCJJYW49R5a/Jpvfa/tUM1T4Zvxt4AD92UZu6qPx0uUgNlYcu8H3P9TiUnKIQXw6M95o4MYpDxfYCKRd64/jjQvlesR0ttBIFk8npgP5ocQTrirJgsxn+LFrOfc9LmsQYUn4mD4cnXpDsqPlo958gV916a/EcyUwFaYyoqyBl/W7SDTc4onXrDQ+HNGVVS7D3IZzN7z0wQf+bu2BlDlqG1f9byghuaGcSMTW3pCwPz9kUg3KjEZX7Lo4k2vwjey4tYBb0Na5zx0vq1Z+O7p7/PxrNNedFvbWhLqqfHLlQQlGNNxOJHC5VT5ENJofXeOq301R7KWT3WqOPnKvWjukKNZG6Hd0zzcSgjjhnNv1crtBGkVx/ZTkGEjV2aNsifsVX0K9z0377qRmZrMidFl+ue/AB98MmKfv+OXO8KWgCCWv2e1Cf9pCm1JiwjJ/eotPGVQHhCCWtYDxNR2J4m5O8ICTitAtlXtSmJEoi1+qbyAYnatE9XTYA4j+BY8oIciBME8NroHao+t4VKzeIG2uIEGA8=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 50bac053-24e0-4e7c-83a9-08dda9ce829d
X-MS-Exchange-CrossTenant-AuthSource: DS0PR10MB7224.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2025 16:30:58.0855
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 7UyCZr0d0QsVT2H4z7gIz1Khb54hUPPh6lc6Ak0jqWUR+j+YWI4uqdL3wdc1FyIfRSFOi9TE0LMk0iFRO1+WqR+DDM7Rv8iQWDZs7Y63IFs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR10MB5882
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40
 definitions=2025-06-12_09,2025-06-12_02,2025-03-28_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxscore=0 mlxlogscore=999
 bulkscore=0 adultscore=0 suspectscore=0 malwarescore=0 phishscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2505160000
 definitions=main-2506120126
X-Proofpoint-GUID: fz5jgSGcJWczYTUEqBEHA8sDYdmw4ofU
X-Authority-Analysis: v=2.4 cv=GcEXnRXL c=1 sm=1 tr=0 ts=684b00c7 b=1 cx=c_pps a=qoll8+KPOyaMroiJ2sR5sw==:117 a=qoll8+KPOyaMroiJ2sR5sw==:17 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19
 a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=6IFa9wvqVegA:10 a=GoEa3M9JfhUA:10 a=yPCof4ZbAAAA:8 a=6sjuNymXX6gQSoEFov8A:9 a=QEXdDO2ut3YA:10 cc=ntf awl=host:13207
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjEyMDEyNiBTYWx0ZWRfX9gvxpBQLN9Sg rZ996TvUHFmXGjGbwQFaP4KGrblM9rYSyHJ1rL1RSwj1H4YB4TWNm+BcI25NXEQ+jhbnApAvK0K MInjtJMS3zZZQwFZVST07pfJupKGwwnlqG9FBck3pFCtsDpBEbuyFQ3Z6XD1+1Apsts33cHa0xE
 rNnlw7Zr9fawxg1t2oE7mc6yR14aK/24fSNdsBKcDkkvH2VAWyAPASpoi0D1Hg4/+t9Mlpt7x+J JYvsOLLKBeWG/TV9dp9BBzLIsmUvI3+8L0RhF57lK2hOGeqbQlavFJMz5Ncd7pp2sEkl2dP0rNl 41cVkkw7VO+bAde9ZLZ2zA+pqWNv0A9ehYWcQg96AFv8ddvdV/1dNf+c7wF0uEefizA5e2vOVOQ
 p6Nw1yYnfi+2mGGA9jUfgxmDtTo9km1tVk7jLi7ZfrrAtIE9cGg6pCGUbtq04kxmFOY+AEGT
X-Proofpoint-ORIG-GUID: fz5jgSGcJWczYTUEqBEHA8sDYdmw4ofU

On 6/11/25 3:14 PM, Sergii Dmytruk wrote:
> On Tue, Jun 03, 2025 at 09:17:29AM -0700, ross.philipson@oracle.com wrote:
>>> +void asmlinkage slaunch_early_init(uint32_t load_base_addr,
>>> +                                   uint32_t tgt_base_addr,
>>> +                                   uint32_t tgt_end_addr,
>>> +                                   struct early_init_results *result)
>>> +{
>>> +    void *txt_heap;
>>> +    const struct txt_os_mle_data *os_mle;
>>> +    const struct slr_table *slrt;
>>> +    const struct slr_entry_intel_info *intel_info;
>>> +
>>> +    txt_heap = txt_init();
>>> +    os_mle = txt_os_mle_data_start(txt_heap);
>>> +
>>> +    result->slrt_pa = os_mle->slrt;
>>> +    result->mbi_pa = 0;
>>> +
>>> +    slrt = (const struct slr_table *)(uintptr_t)os_mle->slrt;
>>> +
>>> +    intel_info = (const struct slr_entry_intel_info *)
>>> +        slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_INTEL_INFO);
>>> +    if ( intel_info == NULL || intel_info->hdr.size != sizeof(*intel_info) )
>>> +        return;
>>
>> Since these are the x86/TXT bits, it seems at this point, not finding the
>> TXT info structure would be fatal, no?
> 
> It is fatal, but early code doesn't have means for reporting errors
> nicely, so it just continues.  You think it's better to reboot right
> away?

I was trying to track down where you make the first determination that a 
TXT secure launch is supposed to be done. I think it is before this 
point so if that is the case, I think this should be fatal here.

> 
>>> +static inline void *txt_init(void)
>>> +{
>>> +    void *txt_heap;
>>> +
>>> +    /* Clear the TXT error register for a clean start of the day. */
>>> +    txt_write(TXTCR_ERRORCODE, 0);
>>> +
>>> +    txt_heap = _p(txt_read(TXTCR_HEAP_BASE));
>>> +
>>> +    if ( txt_os_mle_data_size(txt_heap) < sizeof(struct txt_os_mle_data) ||
>>> +         txt_os_sinit_data_size(txt_heap) < sizeof(struct txt_os_sinit_data) )
>>> +        txt_reset(SLAUNCH_ERROR_GENERIC);
>>
>> I know the list of error codes pulled in are from the patches for Linux
>> Secure Launch which seems right. The Xen work is free to add more specific
>> error codes e.g. somewhere like here. We could even consider using regions
>> in the vendor error code space for different things like generic errors vs
>> architecture specific ones vs etc.
>>
>> Thanks
>> Ross
> 
> I think some codes were already added and this is the only place where
> SLAUNCH_ERROR_GENERIC is used, not really sure why, will add a couple
> more.  By the way, the new errors were inserted in the middle making
> about half of the errors out of sync with Linux, should Xen and Linux be
> in sync?
> 
> Not sure about usefulness of error regions, the errors codes are only
> for TXT and major/minor errors in TXT.ERRORCODE weren't helpful in
> debugging.

Yea all I really meant was that the area in the error code < 0x400 is 
ours to chop up how we want.

Thanks
Ross

> 
> Regards
> 



From xen-devel-bounces@lists.xenproject.org Thu Jun 12 16:46:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 16:46:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013311.1391806 (Exim 4.92)
	(envelope-from )
	id 1uPl40-0000UR-F3; Thu, 12 Jun 2025 16:46:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013311.1391806; Thu, 12 Jun 2025 16:46:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPl40-0000UK-BI; Thu, 12 Jun 2025 16:46:04 +0000
Received: by outflank-mailman (input) for mailman id 1013311;
 Thu, 12 Jun 2025 16:46: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 1uPl3y-0000UE-FM
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 16:46:02 +0000
Received: from mail187-14.suw11.mandrillapp.com
 (mail187-14.suw11.mandrillapp.com [198.2.187.14])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b7b81c40-47ac-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 18:45:59 +0200 (CEST)
Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail187-14.suw11.mandrillapp.com (Mailchimp) with ESMTP id
 4bJ7h63wmPz8XS2rq
 for ; Thu, 12 Jun 2025 16:45:58 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 59d1d471516a4b15a87c356eb56a6148; Thu, 12 Jun 2025 16:45: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: b7b81c40-47ac-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1749746758; x=1750016758;
	bh=3sutpI42EtEi4mz0u2ZBCtTxbQRpGFiDM9I9bELbKHk=;
	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=ZPpRHWeFWxXdfjYt/4AcXv6FWc722slVVY9hibI7pOT5C1w/XmyeqQIavs5iBHb6z
	 +cgvGV4dRXKekzo+GIVwwy8HsgrNAO1Ut+duC9SSMuYExmXjase0Fy0vpgwBx8uced
	 Taf9/9AQvSDaeJL7XiEIWzy73HzfSfTLhjFW6UVFzAHsHgAPtQ0zkLE/KKpjSGA1Ek
	 +PMeHKDnikoNIhhH/RzvySW/F0ScYzYZQkK3+GL6WdH07viF3tNPbUlFSNXkxJsfYZ
	 OryuD16fF318HqqVNb50Jkdg6WxZX1GnDCngzZnXmUVqeuUmoybEVzyxT2za2GekoR
	 1Eeq7BjWgookQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1749746758; x=1750007258; i=teddy.astie@vates.tech;
	bh=3sutpI42EtEi4mz0u2ZBCtTxbQRpGFiDM9I9bELbKHk=;
	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=u6W7vrbsDySPrOGhmPkVRhqF5aMDuKynuXPTdPgg8d0lM84XF4Cr1QTluS5kfrNG2
	 6fZ+5v95HadIc/UYe7XBufiAxp218OrrtsAMSd4k70w1YZAh03tYbxK0/CBG2qPSbM
	 1q7jgcXdIjEl+scmSkZXCwRcm+GpihsvM5folBRW/FDwuvd/7n+1ghyrHZwk8cURjJ
	 Rs89zRchqAYP61+ioSfFmqkW9bkAYHucHZBX2c3FQHXEFPrMl9P5YUNpbisbHcK22m
	 R4dHJrNy/xwOgNKHbUlUfXdoeMN3dl0p6jLNZYxNH425jZRB0XbfVRLDBDw6GuRApz
	 Y0qz4RzszGrYQ==
From: "Teddy Astie" 
Subject: =?utf-8?Q?Re:=20[RFC]=20Proposed=20x86=20shadow=20paging=20changes?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1749746757835
Message-Id: 
To: "Jan Beulich" 
Cc: Xen-devel 
References:  <2274612e-d6cd-402e-9f2c-cefb72422cd7@suse.com>
In-Reply-To: <2274612e-d6cd-402e-9f2c-cefb72422cd7@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.59d1d471516a4b15a87c356eb56a6148?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250612:md
Date: Thu, 12 Jun 2025 16:45:58 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Le 12/06/2025 =C3=A0 14:12, Jan Beulich a =C3=A9crit=C2=A0:
> On 12.06.2025 13:45, Teddy Astie wrote:
>> In Xen x86, there is the shadow paging that could be used in some cases
>> (notably with HVM), and is used when HAP is not available. It may also
>> be used in very specific cases for PV guests.
>>
>> With the vast majority of hardware supporting HAP (through EPT or NPT),
>> it's rarely used in practice for HVM, with most downstream projects
>> (XenServer, XCP-ng, QubesOS) are compiling-out its support by default.
>> It also performs very significantly worse than HAP.
> 
> Whenever this argument was made, iirc it was in particular George (who
> was involved in the original work aiui) who kept pointing that such a
> statement is not generally true, for numbers being workload dependent.
> 

I am a bit curious on specific workloads where shadow paging performs 
better than hap. Especially considering that shadow paging doesn't 
support PCID and the existence of ASIDs.

>> Therefore, it's not very used in production, and unsurprisingly isn't
>> actively being worked on (most projects being around HAP).
> 
> Is it not? Feel free to review this 2 year old series
> (https://lists.xen.org/archives/html/xen-devel/2023-05/msg01140.html),
> to allow it to finally go in. I'm simply reluctant to do any other work
> in that area until such earlier work was properly settled. In fact I may
> have added one or two patches on top in the meantime, but I saw no good
> reason to even post them, given the state of the series.
> 
>> One of the issues of Shadow Paging is that it relies on a heavy set of
>> optimizations, with some of them being effectively obselete
>> (optimisations based on heuristics designed for more than 20 years old
>> kernels) or eventually problematic (e.g with modern CPU mitigations e.g
>> L1TF mitigations).
>> Most of these optimizations are hard to reason regarding reliability and
>> security and difficult to debug. Some of these optimizations causes very
>> subtle issues with TLB refactoring for ASID management rework [1].
>> Moreover, it's fair to say performance is no longer the priority for
>> shadow paging.
>>
>> My proposal would be to :
>> - significantly reduce the complexity of shadow paging by dropping most
>> of the complex optimizations
> 
> If such can be proven to have no dramatic effect on performance, maybe.
> 
>> - consider Shadow Paging as Deprecated
> 
> I consider this impossible as long as it's still used for PV migration
> and PV L1TF fallback. In particular ...
> 

What about deprecated only for HVM ?

>>   > Functional completeness: Yes
>>   > Functional stability: Quirky
>>   > Interface stability: No (as in, may disappear the next release)
> 
> ... I don't see this as being possible to happen any time soon.
> 
> Jan
> 
>>   > Security supported: Yes
>>
>> Teddy
>>
>> [1]
>> https://lore.kernel.org/xen-devel/9cdb3e67abd01390bcc4cd103ca539d6bf7adb=
c0.1747312394.git.teddy.astie@vates.tech/
>>
>>
>>   | Vates
>>
>> XCP-ng & Xen Orchestra - Vates solutions
>>
>> web: https://vates.tech
>>
>>
> 


Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech




From xen-devel-bounces@lists.xenproject.org Thu Jun 12 16:52:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 16:52:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013317.1391815 (Exim 4.92)
	(envelope-from )
	id 1uPlAG-00027b-2V; Thu, 12 Jun 2025 16:52:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013317.1391815; Thu, 12 Jun 2025 16: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 1uPlAF-00027U-Vo; Thu, 12 Jun 2025 16:52:31 +0000
Received: by outflank-mailman (input) for mailman id 1013317;
 Thu, 12 Jun 2025 16:52: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 1uPlAF-00027O-0b
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 16:52:31 +0000
Received: from mail145-24.atl61.mandrillapp.com
 (mail145-24.atl61.mandrillapp.com [198.2.145.24])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9fb01046-47ad-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 18:52:28 +0200 (CEST)
Received: from pmta06.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail145-24.atl61.mandrillapp.com (Mailchimp) with ESMTP id
 4bJ7qb3dd7zGlswCp
 for ; Thu, 12 Jun 2025 16:52:27 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 8eae9d8b778e4ead968277f3eba27475; Thu, 12 Jun 2025 16:52: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: 9fb01046-47ad-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1749747147; x=1750017147;
	bh=oNoDnr693/2fsyY5RAw3rqrVvn9+vSNI7S1Ms4L3gHg=;
	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=qhSiBuO1rOXqT2CWro2JTr7sVueG7CWK07kvTfxA2U/5lDUqy1OrEbGe/vEKXuB8r
	 OcMLxGA2A6v5P0rwqqvqu7GJP5nCITLrmAq9gMVJhwXS5wIwr7/2TfQlsrTkImDHUa
	 q/40Fs+ksS6E/POT5Q+S57+rFOu4R6phhSdoW46I+JxIUqpnmqiu3zUGRxVXWnzquB
	 ejNrWqdRlH7QPHuuMAWafBOuFJ7pTHA5A3qgqaHfzY+33sOq0FTtLEuscXvhB3QF8D
	 OmJObcNHDadGd2X0s2nk3qH7sSy7O4IBSkHkfdxFTt87PE7l60U2IEjJPwnXjzyAPp
	 yqb7wrdrlcmVQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1749747147; x=1750007647; i=ngoc-tu.dinh@vates.tech;
	bh=oNoDnr693/2fsyY5RAw3rqrVvn9+vSNI7S1Ms4L3gHg=;
	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=ciFDm5KMS6L3T0ERASODxo5r2HaeL8XdGw6U2tcZUXw5fzg+lU8jMe/BDhNPV2APc
	 WTYFrOoJGrQWVzFMUfrx6DAq2ADG9vjRykkj7M+uh9VBLfVK/TlvY2eBi18wJqDRcI
	 P6H79wcFz5RDfvgNNFiVsbRPXfzDXC1SJorLdNHHkZZaI6D0D/e3FnWITYjgIV9s2p
	 PfRsGwouGYR79p6hUH1ZaPUd55VSNnUu2/034eTZUttWoOIrRArZ0CH2DXFZGL5hre
	 XsakQK5C0pEasIt4Upky+VYAb2KpZKuBVStlDo9EEXCx8+q/oaNhjgnbY5bhnl/C2+
	 82UZKR9VeSo9w==
From: "Tu Dinh" 
Subject: =?utf-8?Q?Re:=20[RFC]=20Proposed=20x86=20shadow=20paging=20changes?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1749747147011
Message-Id: 
To: "Teddy Astie" , "Jan Beulich" 
Cc: Xen-devel 
References:  <2274612e-d6cd-402e-9f2c-cefb72422cd7@suse.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.8eae9d8b778e4ead968277f3eba27475?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250612:md
Date: Thu, 12 Jun 2025 16:52:27 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 12/06/2025 18:48, Teddy Astie wrote:
> Le 12/06/2025 =C3=A0 14:12, Jan Beulich a =C3=A9crit=C2=A0:
>> On 12.06.2025 13:45, Teddy Astie wrote:
>>> In Xen x86, there is the shadow paging that could be used in some cases
>>> (notably with HVM), and is used when HAP is not available. It may also
>>> be used in very specific cases for PV guests.
>>>
>>> With the vast majority of hardware supporting HAP (through EPT or NPT),
>>> it's rarely used in practice for HVM, with most downstream projects
>>> (XenServer, XCP-ng, QubesOS) are compiling-out its support by default.
>>> It also performs very significantly worse than HAP.
>>
>> Whenever this argument was made, iirc it was in particular George (who
>> was involved in the original work aiui) who kept pointing that such a
>> statement is not generally true, for numbers being workload dependent.
>>
> 
> I am a bit curious on specific workloads where shadow paging performs
> better than hap. Especially considering that shadow paging doesn't
> support PCID and the existence of ASIDs.
> 

This is quite common in big-memory workloads where you don't touch the 
memory mappings much. With HAP you can lose 5-7% perf due to the impact 
on TLB misses.


Ngoc Tu Dinh | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech




From xen-devel-bounces@lists.xenproject.org Thu Jun 12 16:56:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 16:56:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013334.1391826 (Exim 4.92)
	(envelope-from )
	id 1uPlE7-0002hv-IU; Thu, 12 Jun 2025 16:56:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013334.1391826; Thu, 12 Jun 2025 16:56: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 1uPlE7-0002ho-FY; Thu, 12 Jun 2025 16:56:31 +0000
Received: by outflank-mailman (input) for mailman id 1013334;
 Thu, 12 Jun 2025 16:56: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 1uPlE6-0002hi-GV
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 16:56:30 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on2061a.outbound.protection.outlook.com
 [2a01:111:f403:200a::61a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2dc05c39-47ae-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 18:56:28 +0200 (CEST)
Received: from SN7PR04CA0212.namprd04.prod.outlook.com (2603:10b6:806:127::7)
 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.8792.39; Thu, 12 Jun
 2025 16:56:24 +0000
Received: from SN1PEPF00036F40.namprd05.prod.outlook.com
 (2603:10b6:806:127:cafe::8c) by SN7PR04CA0212.outlook.office365.com
 (2603:10b6:806:127::7) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.35 via Frontend Transport; Thu,
 12 Jun 2025 16:56:23 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SN1PEPF00036F40.mail.protection.outlook.com (10.167.248.24) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Thu, 12 Jun 2025 16:56:23 +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 Jun
 2025 11:56:23 -0500
Received: from [172.27.195.250] (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 Jun 2025 11:56:22 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2dc05c39-47ae-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=rnTMNTZIyN8QQxayumQHvzsyuijqU5aJ/NaldaWjzN1+FQ5dHJsy3M7UxjNrecZ9m764xkdJtWbOpyAJf9xdxfYEnDfDYEK2wCioCi4CW4pq+X681rJk7WIUpXIHhSyci9NyyusrtTC4jOufA0m2zuLJJrX/4NtdYgfSsozz55o1CM1kEnrMWKI5nMbzm5R3t28sZh03cM9oselItO6v87c46RjXjgK9Brv8xWcmkCLeoVpMSfj/UJG12TcMKVuIkVsP4wiUgVXwuyYhw28mb55FiC/RBH1S6yV6t8wfkNb74DfywMFxHy3DQsjEteq66joYFNpbS+F+AArudR9GjQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=leRWLVjzsKU2O6tCXhkjvpo/hHO6YRZ4WxaHMexTVHc=;
 b=v+EN6DVLj79rRHd0E3GAvHrC07+pObX8TwQjd8P8kStPmOmAqICXWEv+5uiv8j4sx37+hLuo89df9gpJhVVbe40D2VvDAhkvBp+TAt1dfgQ9V7GhSpmBLrBVs5MmFr6tvsYI0hCGcbfBuQpu8GHgYeDHYdNkXMGwdOUeMmNnT3kseCuOP2KHnmveZ7ZhllcuECGQEJ3EohSAo5Rt+deW5SbaOXCqRNJashbW2Am9UvOSyjSc0rrtKKdCiSfaWK1er5G8tvlcfmCsgtWPEGLe4aZMk/19HYybfZlaiamWy68l6kWBTs/1oYt3ZAweKONCc8zIhsWFwbj2dbMTqaS70Q==
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=leRWLVjzsKU2O6tCXhkjvpo/hHO6YRZ4WxaHMexTVHc=;
 b=A32fCPcH84tB5uHpgmbEkZIah+Lh2lsDvhCfRWGbzr71eTMkI0RKE13YtY17vm7FiyXeX3Z85QiTusWjjPZojhkLdL8zeX13sPm3wN6L75RWGN1upmlP2yDoN2lTMb4O82c+ydbVR145APXDMIn53RORUy44Fxzh29NO4K7zwEU=
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 Jun 2025 12:56:19 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/4] xsm/silo: Support hwdom/control domains
To: Jan Beulich 
CC: "Daniel P. Smith" ,
	
References: <20250610225737.469690-1-jason.andryuk@amd.com>
 <20250610225737.469690-3-jason.andryuk@amd.com>
 <0f47268e-0674-46e7-bfd4-8a395ee1ddf6@suse.com>
 <6cc69b45-7347-4250-ab32-a1e2857b7d23@amd.com>
 <805abeee-0cad-4cc9-88ae-77e4c1e23fac@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <805abeee-0cad-4cc9-88ae-77e4c1e23fac@suse.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: SN1PEPF00036F40:EE_|CH2PR12MB4247:EE_
X-MS-Office365-Filtering-Correlation-Id: 76656a4f-f72d-499e-d158-08dda9d21062
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?dUhKNFE2SEV6SDcwMXNBNmF0WTNJSFo2b0gxSTdhRE1xeG9ydmdoNlJGLytL?=
 =?utf-8?B?SHd2L29FYzRBTU1VNDltdDVlSUVLYW9KMFI2VjlVR1lPcXBCQURnWUpubkg4?=
 =?utf-8?B?VjhTZ2F5K3ZabDUzTkE2VGg3TTk0RGlJNWQ4OW0raVUwNXp3Yko5blRRQVBM?=
 =?utf-8?B?N2c3WnYza0VWZ0pNajhFR1huYjJiUHl0dGNyZUtueDMxRnF5ekhMM3YvNTgx?=
 =?utf-8?B?a2hrWXkrTWE1NmhzNi9UaTFMaDVyM0JaWFVLN01VbEgwR1EyY1QxU1BYRXU5?=
 =?utf-8?B?VjZNMWNpaHlXaDg3Ty8zeXlQU0gwV1RUSDU3VmxSVTkxakYzZ3I4ZlA0VU1V?=
 =?utf-8?B?MnZhcGZROUZyaEpOWXNZck1UcWQxMUdrNUh3S3VKNVZ4dHRhOG44cThKMXlv?=
 =?utf-8?B?dDVWVHI1TUVwQlFoV3FmMmtxSTJNTFdGcy82amJLaDdnY09uakhaQmY0dmxY?=
 =?utf-8?B?TXJhd09lbU1DbmNJOEVsdWZ1c3Jjc2VJSlJub1pGc2haRzVsRGJyR2JJc0c2?=
 =?utf-8?B?djRXeXZZdUNFc2V1NHF0UzlkdWYwOW9rc2hMSE5vMFlFRjF6V01pY2ZzK3dR?=
 =?utf-8?B?dm5TWGcrelJjNG1kS1NOMzV4R3ZzcTV1Y3dsSUFZSlUxdXJTMUV5WjJwQ3Zk?=
 =?utf-8?B?SVo4cDFybVFQUlpZcS9TV05oUmViQ2pSejV2ejVWZ3Y4YW1Ta3ZtWEhraEVI?=
 =?utf-8?B?MnBIN0dHVFdzcTFZamJ5RVZwRVhkSmNrTkVpOTlQazRyV2VIMEZKSUQ1OUkw?=
 =?utf-8?B?TXdwcXp0SXIzLzhBa2lIczNLNFlJOGVGd0ZwMWsyNlkrbngyWFN0cUdGQWtL?=
 =?utf-8?B?Qi93LzIwaFBiTmlsNnZDRFc4QXFKd2RwNTVsR3BwYnhPNmk1NlZoNm84Y2NX?=
 =?utf-8?B?N2VpWmI5ZklBcG9aby9odFFKVGtIeU1mZjNQT1Z0b3F1MXZTSGVBZ3FLOWh5?=
 =?utf-8?B?dDFKbmZkbm8zQW54ejREUmsxVXZRcjdaSTVURlg0WmVhYmRUditCeDN0NGFr?=
 =?utf-8?B?T3FLUjk0NmxXNmo5UWhFcEN1TUFwRmRIRkVCWTVQcnozRTJTQmtpem9Udjkz?=
 =?utf-8?B?aG1uRUhtUWluQU1TSGNrWWZnZjlRb3RQdFljMzY1bVZWcmo5di9NZG5UYWNn?=
 =?utf-8?B?MzBLSWxNdTA1dEQ4MjVrY3BJTzRFRmRYTFErUDdqV2p3aWNKVHVYY2xjMjNq?=
 =?utf-8?B?eWg5czRDYUpvclhCenc5akJOb0hnYlpTd0UyMWRaNUs4cVU4S09vQXM0b0Fr?=
 =?utf-8?B?SDlnYkYwa2d5ZzN1dDJESnpESU95ZHdUK05aOWk2YkdSa2dsVHBaWXZtVEVB?=
 =?utf-8?B?WUVtVnBPbEJyTy9QSXFBWEphK2g5V0xwbHFCTExvR1gxVDBHTFdhbFpnZXlX?=
 =?utf-8?B?NVk2VzluMXg3TSsvVHIvRHJTVzlRMmhab2dpMjVzZ1AvWG9uQk1QbzBUZU5n?=
 =?utf-8?B?LzJJU25aL2s3cm94WEF1Z0lTcUVMMmF6aXNZN0xQVW0vd2JILzhSNmhEbE8v?=
 =?utf-8?B?ZFpUeFl6WlU1T2ZLVkVObGxTVEI0eVBvd0xqUmtqaC85VGw0NlBvdFVyWktC?=
 =?utf-8?B?UjJmMDZxckcyazFFTUhMSFYyYWVxVjhablhoNU1saHdJYUF2N3ltS21EaGZD?=
 =?utf-8?B?NFAwajBpbU1McE1Vck9rY0R1b1dkQ2c1MmljaEhiUzBaK3VScGxYUUpOSWt6?=
 =?utf-8?B?T2JHTEtSQVdvOUtGd1FzcmVjZmRDMlAzdWJpZSthVWw4SzdSSjYzTTdZWXpl?=
 =?utf-8?B?bit2aHBMZEhEbG8zWTdmVXJWRU5Nd0lnYzJva3NCV0hVWncxN29iTGUwNEY4?=
 =?utf-8?B?THA4QjdZQys2MVE4bi83YTJTTnFqZjFrUFkyRm9uZlBvdUxHR3ZSYUlDVTRl?=
 =?utf-8?B?UEt2WWw0cHBpT0cxdW1BSnhvMHVXUXQ4MUk4SXJsWmFjZUpVMUEwS0d0V1du?=
 =?utf-8?B?UHBWWnFlWDVsdzZoV1dTZEtGcGVRMU5jaXQyMzFML2k4NnViZGZHZWM5Qzlv?=
 =?utf-8?B?aVFNWDdOZ0I5MXlBL2RKdngzWGtBbVFvSlN1ejNIMXFQZXJHd1FBdHl4VWsr?=
 =?utf-8?Q?HlyZqv?=
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: 12 Jun 2025 16:56:23.8946
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 76656a4f-f72d-499e-d158-08dda9d21062
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:
	SN1PEPF00036F40.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4247

On 2025-06-12 03:52, Jan Beulich wrote:
> On 11.06.2025 06:20, Jason Andryuk wrote:
>> On 2025-06-11 09:17, Jan Beulich wrote:
>>> On 11.06.2025 00:57, Jason Andryuk wrote:
>>>> In a disaggregated environment, dom0 is split into Control, Hardware,
>>>> and Xenstore domains, along with domUs.  The is_control_domain() check
>>>> is not sufficient to handle all these cases.  Add is_priv_domain() to
>>>> support allowing for the various domains.
>>>>
>>>> The purpose of SILO mode is to prevent domUs from interacting with each
>>>> other.  But dom0 was allowed to communicate with domUs to provide
>>>> services.  As the disaggregation of dom0, Control, Hardware and Xenstore
>>>> are all service domains that need to communicate with other domains.
>>>>
>>>> To provide xenstore connections, the Xenstore domain must be allowed to
>>>> connect via grants and event channels.  Xenstore domain must also be
>>>> allowed to connect to Control and Hardware to provide xenstore to them.
>>>
>>> Are you suggesting that SILO at present is incompatible with a Xenstore
>>> domain? silo_mode_dom_check() in its original form has no special
>>> precautions, after all.
>>
>> Yes, it is incompatible with the current silo_mode_dom_check().  Only
>> Control domain is allowed to use grants and event channels with a domU.
>> A Xenstore domain would be denied.
>>
>> Xenstore stubdom only exists for x86 today.  My limited attempts to run
>> xenstored in an dedicated Xenstore ARM Linux domain have failed.
> 
> This may want sorting independently first. Once sorted, the requirements
> here may become more clear.

HW+XS-> xenstore works
CTL+XS or XS -> the domain's console just stops.  vCPUs are in Linux cpu 
idle.  I haven't figured out more.  This required some Linux changes to 
query the capabilities since XS isn't exposed and ARM assumes initial 
domain implies HW + CTL.  It's orthogonal to my goals, so I haven't 
looked too hard.

>>>> Hardware domain will provide PV devices to domains, so it must be
>>>> allowed to connect to domains.
>>>
>>> As a built-in policy, isn't this already going too far? There could
>>> conceivably be configurations with only pass-through devices in use, in
>>> which case neither grants nor the event channels operations intercepted
>>> by SILO would be required.
>>
>> Such a domain wouldn't have any PV devices configured?
> 
> Indeed, that's my point: Why would Hardware then have a need to be
> allowed to connect to domains.
> 
>>   I don't think this changes anything compared to today.
> 
> I don't think I see what you mean to tell me with this. What we're
> discussing here is the effect of the separation you're suggesting,
> which necessarily is different from what we have today.
>
>> Both sides need to be configured and opt-in.  Hardware is a system
>> domain, so it should be possible to allow grants and event channels.
>> But they won't be used unless configured.
> 
> "Won't be used" isn't enough, imo. Isn't disaggregation about proper
> isolation, i.e. to guarantee that unwanted interactions can't occur?

Disaggregation is the separation of components.  The security policy 
applied is related but distinct.

"Won't be used" is how dummy and SILO (with respect to dom0) devices 
work today

dummy -> cooperating domUs can communicate
SILO  -> domUs cannot communicate
Flask -> configurable, but typically strict limits to explicit 
communication channels

SILO today doesn't deny communication between a domU without PV devices 
and dom0 - they just aren't configured.  I'm saying that would be the 
same with a split hardware domain.  PV devices just aren't configured, 
but there is no mandatory denial.  SILO only enforces mandatory denial 
between domUs today.

If you want mandatory enforcement, Flask is the correct choice. 
Everything would be explicitly configured.  Some domains could 
communicate with hwdom and others could not.

For SILO, a split hardware domain would be allowed communication with a 
domU if configured by the administrator.  I see this as comparable to 
configuring a domU to access dom0 PV backends today.

>>>> That leaves Control.  Xenstore and Hardware would already allow access
>>>> to Control, so it can obtain services that way.  Control should be
>>>> "privileged", which would mean it can make the connections.  But with
>>>> Xenstore and Hardware providing their services to domUs, there may not
>>>> be a reason to allow Control to use grants or event channels with domUs.
>>>> Still, Control is privileged, so it should be allowed to do something if
>>>> it chooses.  Establishing a grant, or event channel requires action on
>>>> both sides, so allow for the possibility.  This does open up an argo
>>>> wildcard ring from domUs, FWIW.
>>>
>>> Along the lines of my reply to patch 1, I think Hardware and Control
>>> need to have a pretty strong boundary between them. It's hard to see,
>>> for example, whether grant map/copy/transfer would indeed make sense
>>> between the two.
>>
>> The Hardware domain might provide a PV device to Control?
>>
>> I've tested removing control:
>> static bool is_priv_domain(const struct domain *d)
>> {
>>       return is_xenstore_domain(d) || is_hardware_domain(d);
>> }
>>
>> And that works in my limited ARM dom0less testing.  The toolstack isn't
>> really exercised in that case.  It seems strange that the privileged
>> control domain is *not* allowed though.
> 
> With the intended separation, there's (imo) not going to be any
> all-mighty domain anymore. Neither Hardware nor Control.
> 
>>> Similarly I'm not convinced a strong boundary isn't also needed
>>> between Xenstore and Hardware.
>>
>> If hardware is providing PV devices to domains, it will need access to
>> Xenstore.  I don't see how you can get around it.
>>
>> I tried to explain this in the first paragraph.  SILO's purpose was to
>> isolate domUs from each other, but allow it to access dom0.  dom0
>> embodies the control, hardware, and xenstore capabilities.  So as a
>> first approximation, each of Control, Hardware, and Xenstore should be
>> allowed to communicate with domUs.
> 
> Yes. Yet what to permit between the three special entities is far less
> clear. Hence why I'm unconvinced this can be expressed by SILO, and
> would rather require Flask.
> 
>> domUs needs to communicate with Xenstore and Hardware for PV devices.
>>
>> Xenstore provides Xenstore access to Hardware.
>>
>> Control would want Xenstore access.
>>
>> I don't know if this helps, but here's a table:
>>
>>       | CTL | HW  | XS  | domU
>> ----------------------------
>> CTL |     |  ?  |  y  |  ?
>> HW  |  ?  |     |  y  |  y
>> XS  |  y  |  y  |     |  y
>> domU|  ?  |  y  |  y  |  x
>>
>> Control and Hardware would be y if we allow PV devices
>>
>> Control and domUs - I don't have an immediate rational for them.  Except
>> that Control is privileged.  I've been running xenconsoled in Hardware.
>> If xenconsoled is in Control, then access would be required.
> 
> Perhaps some clarification is first need about what Control really is
> (and is not). It is sole the domain to create other domains. But beyond
> that things become unclear. E.g. xenconsoled may not belong into either
> Hardware or Control.
> 
>>>> --- a/xen/xsm/silo.c
>>>> +++ b/xen/xsm/silo.c
>>>> @@ -20,6 +20,12 @@
>>>>    #define XSM_NO_WRAPPERS
>>>>    #include 
>>>>    
>>>> +static bool is_priv_domain(const struct domain *d)
>>>> +{
>>>> +    return is_xenstore_domain(d) || is_hardware_domain(d) ||
>>>> +           is_control_domain(d);
>>>> +}
>>>
>>> This construct expands to two evaluate_nospec(), which likely isn't
>>> wanted. Some open-coding may be pretty much unavoidable here.
>>
>> Thanks, yes, good point.
>>
>>> (I'm
>>> surprised it's not three, i.e. I find it odd that is_xenstore_domain()
>>> doesn't also use that guard.)
>>
>> It looks okay to me.  There were only 2 uses until I added a 3rd in the
>> dom0less code.  The XSM check has evaluate_nospec() and the other 2 uses
>> aren't security critical - Setting a domain info flag, and __init code
>> for dom0less.  Maybe moving the evaluate_nospec() would be safer in case
>> use grows in the future, but it looks okay to me today.
> 
> When some of the hardening was first introduced, actual use sites were
> indeed taken into account. That wasn't quite right though, I think. Any
> such construct ought to be safe to use anywhere. For uses with clearly
> no concerns towards speculative abuse, a 2nd lightweight form of such
> constructs should then exist, imo. As to your use of "security critical":
> I'm not convinced you what mean is covering the potential of speculative
> abuse of involved code paths.

I can't parse this last sentence, and I think it's your main point.

XSM -> don't speculate around permission checks.  That's what I meant by 
"security critical".

The __init code is inaccessible to users, so it doesn't matter.

         if ( is_xenstore_domain(d) )
             continue;

getdomaininfo sets a flag, so I don't see this making a security 
difference.  It's not controlling loads or code paths.

(is_xenstore_domain(d)          ? XEN_DOMINF_xs_domain : 0) |

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 17:31:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 17:31:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013354.1391836 (Exim 4.92)
	(envelope-from )
	id 1uPllq-0007zi-88; Thu, 12 Jun 2025 17:31:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013354.1391836; Thu, 12 Jun 2025 17:31: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 1uPllq-0007zb-55; Thu, 12 Jun 2025 17:31:22 +0000
Received: by outflank-mailman (input) for mailman id 1013354;
 Thu, 12 Jun 2025 17:31: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 1uPllo-0007zV-JC
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 17:31:20 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20602.outbound.protection.outlook.com
 [2a01:111:f403:2413::602])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0ba1d15f-47b3-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 19:31:18 +0200 (CEST)
Received: from CH0PR07CA0006.namprd07.prod.outlook.com (2603:10b6:610:32::11)
 by SJ0PR12MB6685.namprd12.prod.outlook.com (2603:10b6:a03:478::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.25; Thu, 12 Jun
 2025 17:31:11 +0000
Received: from DS2PEPF00003444.namprd04.prod.outlook.com
 (2603:10b6:610:32:cafe::d2) by CH0PR07CA0006.outlook.office365.com
 (2603:10b6:610:32::11) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.21 via Frontend Transport; Thu,
 12 Jun 2025 17:31:11 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 DS2PEPF00003444.mail.protection.outlook.com (10.167.17.71) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Thu, 12 Jun 2025 17:31:11 +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 Jun
 2025 12:31:10 -0500
Received: from [172.27.195.250] (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 Jun 2025 12:31:09 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0ba1d15f-47b3-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=rvA9xOjHSD4Ln8q6xd1dWX1yrTL+e+kPTVEs4hpZqZvXr9+PpIH9zcbYLgEKOMODEbaZzJgzCLsHqchQlHxJwCQCRMykdKKlSfwVI5qiO809nRXNqjB4EJHde+eaM3tLLzNe95Cchu7s7cHLwQBWpp86NBInC+SC2mvE8GEjeNRyI/H/FzQpd0be9R6KdG3ZDjTViA+B2LuIBgT/rhHLI9KJAGu7Or12BRik/2sTku2HIM1ksPfXad0w345wR+2WlAjOblP7kw+LPUl+8Y8jnhJKnxRWraA+CNTEEkFiMmvMd5TwnICNu1yf+gpjK8BbZx4PEJnE8mhOZVEFsMSgLg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=oPrLHnvatmBdPewhuh0Ilah1Jx05z6rtCk5m6G1mJTk=;
 b=GWIZq1A1jzVplh/8wkgXpLayRQ9wRDcSvPfIqvnhrVT/llUX7TexIJv3Pct/oVDWuxwvsjSWFIC5KksqTfkLc9OxG3jipUkNDxjKy776s6vojUFGUSklU3KDdww4JkWqpiwsFy+jFjEipaBqjpUDsuTRa11o1+YOfYyO2/oyfYZASk+OCNvXWTaWwNbsCs6+FE9d5dTHub2LyPNCko1+lX5T83PJTwz5G3OQaW+0RwjDl593qTA96gA1y/K2is0RANn2aRjbQtVwVU8ZDGKIdyTUt926IpLOoGHmRFgGV14WfRdyjiIcpxS8zDqUxIvr45q6OaBg9mxeHDLLdbWMbQ==
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=oPrLHnvatmBdPewhuh0Ilah1Jx05z6rtCk5m6G1mJTk=;
 b=auaeiqxlJ3T40pLLeMQwXrtA7z97oe7O7cy2dgtWJXSTn/m6W95A2XDq9TDawv5fhiMFj6CTTIZAouEO8CUq+f3kiPNBz/8JbwoBTyUtw3o8DLMIxdcb8pGvXJxFkNGziaXYCnyV/28NISf8GnaXQlmtA34Z/kRUIZ4Ot3dXAFs=
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: <1681221f-bc78-4c70-bc1a-708766ba896c@amd.com>
Date: Thu, 12 Jun 2025 13:31:06 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/4] xen/xsm: Add XSM_HW_PRIV
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?=
	, "Daniel P. Smith" ,
	
References: <20250610225737.469690-1-jason.andryuk@amd.com>
 <20250610225737.469690-2-jason.andryuk@amd.com>
 <43725e7d-cb4c-44b7-a3e5-59d8d597c805@suse.com>
 <12700a8a-a969-42ed-aba8-753ff9da9a44@amd.com>
 <789e1d1d-bfd0-434f-b697-678ab5e6f912@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <789e1d1d-bfd0-434f-b697-678ab5e6f912@suse.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: DS2PEPF00003444:EE_|SJ0PR12MB6685:EE_
X-MS-Office365-Filtering-Correlation-Id: 781f910d-c326-466f-b32f-08dda9d6ec91
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|7416014|376014|1800799024|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?aGowdVhPREJwdXFZcDFpWWFmSkJxY3l5U2ZQQWQwTjZFNGp1azczQkV1VUFy?=
 =?utf-8?B?K0RBeUhPMUxiVmt5N21hRWUyL3VMdEpYY2RCRi9nMDBKNjdONHd5Q3psNGhL?=
 =?utf-8?B?dE5mSHhEQjVUTnlWMkhtVy9zMllSaWRZblJVdkpuT0tPb0RxMWtQdHZySThH?=
 =?utf-8?B?aDRHbDM1SHd1MFRWYjNKT1hYQmNHUHduKzhXdXV4elJESzNOSUZ5ZWxlcFNx?=
 =?utf-8?B?RDNkckZjR2JXK1FiT212QzlUZmFrcEN6MitsN2FyallCbyt3dnhLeVhxelpi?=
 =?utf-8?B?Q3NydjZnb0kwandtUDZsYi9pZndqN21rbmFSSHpkb24rSW9TWGZSVDFpMXNO?=
 =?utf-8?B?aG5BcXAxbFdLNWtoQ21rR2hST1Q1cVpUWXVwRVhZeU1kWjdlQmRTVVdWbWwz?=
 =?utf-8?B?bHFSakhrenRlZGV4anZYRW9JRTZORU5BbEwrc3F2RUlFMXZiQUVpQU5VT0No?=
 =?utf-8?B?UjBUNXJDSVg4ZEFxUG9pcDdOek5YQmc0cnFKanloWG9YblY1NWoweG5yOHdp?=
 =?utf-8?B?SXVjTThMUHhCMnluMHZVTXZ1YWcvRHJPb3BtNVVSYnZPMXViZ2pWRmdBOHZz?=
 =?utf-8?B?dUxqa1R1VDFyMkt2VFd4ZXZ5MkJpYXAwdFRCYWoreTJIMG53cXdiNWFuRzBu?=
 =?utf-8?B?VnRyQUJnQjdQSUN1dzUvVzBlRGkrODhIUkhjTGM0bi8vMHI2Z1liY0VtbGQx?=
 =?utf-8?B?SDBQSUpLTzA2a2FydWsxYjdQL0dmRGJvWVorVDlQWXRSV1VUODFXaTdvRi9D?=
 =?utf-8?B?T0k3VHcxeG45MFI3YzJseWZlaEY4ajVrWmRmbk8rd3NLMk50QUdvUnI5SHJF?=
 =?utf-8?B?Y2hFSkppSzU5cmxrM29uUnorMTRBSzY1eEZMUUUxaDdtRnJVRGtURkc3Zk51?=
 =?utf-8?B?eDRSNHd5bXZSRU5wRzBYWEJLeUpHUUVPRG1LU0JVekZUdCtpbGQ5dndjazEx?=
 =?utf-8?B?RmtNZGpYRHUrQ3ptaGVIcE9ja3BiWThSM2Y0ZGl4b011RWxSM1NJeEFEWGtF?=
 =?utf-8?B?N2lseFIyZkJ4em83NDJRSy9oN2Z5ZDdPeE5POHI2eWI5RXB5ZUtTRXN1cGR2?=
 =?utf-8?B?VXU1Um1MZ3RYNTRiOS90Q3pVTmdlYlQrNE1BOE40UHNXL1BxTmZBYkhQQzNP?=
 =?utf-8?B?aU1zM2dDT3dQVXNaZnhTNFlaR0NiTVdXU3pTSmJPTVFoMzNoUXBqaXdrMm1u?=
 =?utf-8?B?ZW9VNHE1Y0lCNlZONUZBZ3p1bURnV2pCc1pPaitzay8xbGJQVU4xR1N3OHp6?=
 =?utf-8?B?UmlwT3JNZXQ5T2t1QmhZMG1rWEprVE9GUytXZmEybVZHUnNsR09GQk5KRHRl?=
 =?utf-8?B?dG14VDUzS0dqQVBuOGNFWHpSOGxzL2x3R3Q1Vi83eFlIcE9oWG1hSTVndlZv?=
 =?utf-8?B?WTVBNXVCUGZUck43Um01ckRhTFByMzc3Y0g2OHdVeXRVL2JkcEhrN3ZzVUk2?=
 =?utf-8?B?RWRtWVdlWXhPc3c3WTRGWjhMaU9TYVo3K3MwWGFIQzZVQVFtd2ozdXk0ek1T?=
 =?utf-8?B?OXZ6WXc0NytzUkNGOXpJbHlDSmQ1eC9VbXRuVHEyYzVQZVhibC9odVRVOFNl?=
 =?utf-8?B?d1IyRStPMjhITEFPRU5DY25DMStSWEt0Vk9nN2NzdjJHWnFMbFZKOHRodlNy?=
 =?utf-8?B?djRwcHdybmFGM1E5MTBxQmVSTzVhY2tLcjE1YUJjRk10ZnRQcGI1L00vUzcy?=
 =?utf-8?B?V00xbzFxMzVBclMzbHpIYXJtN2s0ZG82dTVDczNoTkhJcVFXZHk3cUlLc0tT?=
 =?utf-8?B?djVsL1AvNjM5T3VWd0lINTN5MUFrK1VQc2FxZTBBaHFKYXgyMWtPRCsvOFZG?=
 =?utf-8?B?ME0zNHF5dUdCRnE3WFRkL2FXNnI4bmdnYjVqODNtRzBaR09rMm1CcXBlL0Yx?=
 =?utf-8?B?dkhORFhRWHZmaDFTckNkR1REcUJBUHVZM2hBdlQ2ck05V2x1TnpvRVgrRnh0?=
 =?utf-8?B?Q0hqcjN5TUhqVFBqZU5JR1ZoSkI0TFdteG1hMGxxVjZKVUkveXIzTkZZQmF1?=
 =?utf-8?B?SFJsYS9HMitVL3BDd1R0SjZUT2Q0ZjY5Q2hiV21NTU5PSWF1Sk1NZ0EzWW5v?=
 =?utf-8?Q?7nWSrs?=
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)(7416014)(376014)(1800799024)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2025 17:31:11.2734
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 781f910d-c326-466f-b32f-08dda9d6ec91
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:
	DS2PEPF00003444.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB6685

On 2025-06-12 03:36, Jan Beulich wrote:
> On 11.06.2025 05:13, Jason Andryuk wrote:
>> On 2025-06-11 09:02, Jan Beulich wrote:
>>> On 11.06.2025 00:57, Jason Andryuk wrote:
>>>> Xen includes disctinct concepts of a control domain (privileged) and a
>>>> hardware domain, but there is only a single XSM_PRIV check.  For dom0
>>>> this is not an issue as they are one and the same.
>>>>
>>>> With hyperlaunch and its build capabilities, a non-privileged hwdom and a
>>>> privileged control domain should be possible.  Today the hwdom fails the
>>>> XSM_PRIV checks for hardware-related hooks which it should be allowed
>>>> access to.
>>>>
>>>> Introduce XSM_HW_PRIV, and use it to mark many of the physdev_op and
>>>> platform_op.  The hwdom is allowed access for XSM_HW_PRIV.
>>>>
>>>> Make XSM_HW_PRIV a new privilege level that is given to the hardware
>>>> domain, but is not exclusive.  The control domain can still execute
>>>> XSM_HW_PRIV commands.  This is a little questionable since it's unclear
>>>> how the control domain can meaningfully execute them.  But this approach
>>>> is chosen to maintain the increasing privileges and keep control domain
>>>> fully privileged.
>>>
>>> I consider this conceptually wrong. "Control" aiui refers to software
>>> (e.g. VMs or system-wide settings), but there ought to be a (pretty?)
>>> clear boundary between control and hardware domains, imo. As to
>>> "pretty" - should any overlap be necessary (xms_machine_memory_map()
>>> comes to mind), such would need handling specially then, I think. At
>>> the same time: The more of an overlap there is, the less clear it is
>>> why the two want/need separating in the first place.
>>
>> So you are in favor of splitting control and hardware into distinct
>> sets?  I am okay with this.  I implemented that originally, but I
>> started doubting it.  Mainly, should control be denied any permission?
> 
> Yes, imo: Fundamentally for anything the hardware domain is supposed to
> be doing. 

Ok.

> Yet as indicated in other replies to this series - boundaries
> aren't always as clear as they ought to be for a clean separation.

Agreed.

>> We aren't using the toolstack to build domains - dom0less or Hyperlaunch
>> handles that.  This avoids issues that might arise from running the
>> toolstack.
> 
> IOW you don't have a control domain there in the first place?

I have a domain with d->is_privileged == true.  We don't create more 
domains with it though, which was your other email's definition of the 
control domain.  But it can pause and unpause domains.

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 17:36:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 17:36:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013365.1391887 (Exim 4.92)
	(envelope-from )
	id 1uPlqw-0000xf-CK; Thu, 12 Jun 2025 17:36:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013365.1391887; Thu, 12 Jun 2025 17: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 1uPlqw-0000wM-6R; Thu, 12 Jun 2025 17:36:38 +0000
Received: by outflank-mailman (input) for mailman id 1013365;
 Thu, 12 Jun 2025 17:36: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 1uPlqu-00008H-Ln
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 17:36:36 +0000
Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com
 [148.163.156.1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c8e2c479-47b3-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 19:36:35 +0200 (CEST)
Received: from pps.filterd (m0353729.ppops.net [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 55CBGWVP017713;
 Thu, 12 Jun 2025 17:36:19 GMT
Received: from pps.reinject (localhost [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 474dv7v8mc-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Thu, 12 Jun 2025 17:36:18 +0000 (GMT)
Received: from m0353729.ppops.net (m0353729.ppops.net [127.0.0.1])
 by pps.reinject (8.18.0.8/8.18.0.8) with ESMTP id 55CHUNNC007629;
 Thu, 12 Jun 2025 17:36:17 GMT
Received: from ppma23.wdc07v.mail.ibm.com
 (5d.69.3da9.ip4.static.sl-reverse.com [169.61.105.93])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 474dv7v8m4-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Thu, 12 Jun 2025 17:36:17 +0000 (GMT)
Received: from pps.filterd (ppma23.wdc07v.mail.ibm.com [127.0.0.1])
 by ppma23.wdc07v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 55CENRRG027927;
 Thu, 12 Jun 2025 17:36:16 GMT
Received: from smtprelay06.fra02v.mail.ibm.com ([9.218.2.230])
 by ppma23.wdc07v.mail.ibm.com (PPS) with ESMTPS id 47518mnu86-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Thu, 12 Jun 2025 17:36:16 +0000
Received: from smtpav03.fra02v.mail.ibm.com (smtpav03.fra02v.mail.ibm.com
 [10.20.54.102])
 by smtprelay06.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id
 55CHaE0J13173194
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Thu, 12 Jun 2025 17:36:14 GMT
Received: from smtpav03.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id F41CA20043;
 Thu, 12 Jun 2025 17:36:13 +0000 (GMT)
Received: from smtpav03.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id E0ED420040;
 Thu, 12 Jun 2025 17:36:13 +0000 (GMT)
Received: from tuxmaker.boeblingen.de.ibm.com (unknown [9.152.85.9])
 by smtpav03.fra02v.mail.ibm.com (Postfix) with ESMTPS;
 Thu, 12 Jun 2025 17:36:13 +0000 (GMT)
Received: by tuxmaker.boeblingen.de.ibm.com (Postfix, from userid 55669)
 id A255BE19B9; Thu, 12 Jun 2025 19:36:13 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c8e2c479-47b3-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc
	:content-transfer-encoding:date:from:in-reply-to:message-id
	:mime-version:references:subject:to; s=pp1; bh=QpzxDfFD94KWII9K+
	6HadLtwTM81QAZAX1ucAb3kQ9o=; b=qzApvk7S2hlxQl1Bn2Btpu10ZAllpo5Ln
	KoZtJ5Dc5ebsGHYL7NJYxYDOAJV+QiKhNPjGUzyi5/p4smraFWFFpufSpMGzAkSs
	ijMES3tEQCL80ZymilIYQDcLGmaNEIE8zYtWSd1n3DnwRCmSMWFFrnWXVIMOvcU4
	3FTlbLfkovMjrogcNOJQy/OWjWG8T3XeFB0lZLwFpm4+bdXr+w/UwmyypaAsne2r
	gAzSFTJPL3eValXHYUhK4dMMnMvOe2n9ysA28sfKgF+EgtHkCd2WJoBbECxNmdyG
	yGLdYwa2Z/ZiCy8108YXetwWubfWr/782ZiXt2qPAO1hZCRLEMGhQ==
From: Alexander Gordeev 
To: Andrew Morton 
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
        sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org,
        linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org,
        Hugh Dickins , Nicholas Piggin ,
        Guenter Roeck , Juergen Gross ,
        Jeremy Fitzhardinge ,
        Ryan Roberts 
Subject: [PATCH 3/6] mm/debug: Detect wrong arch_enter_lazy_mmu_mode() contexts
Date: Thu, 12 Jun 2025 19:36:10 +0200
Message-ID: <2d516308df177f169e3e158687852bf91c95c427.1749747752.git.agordeev@linux.ibm.com>
X-Mailer: git-send-email 2.48.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-TM-AS-GCONF: 00
X-Proofpoint-ORIG-GUID: 9voeh4bv5cl5bR8-1UbklMpr0vy5aE9k
X-Proofpoint-GUID: 9Au_5T7dJBReJY8qjL4lDoqAoOEk9nHN
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjEyMDEzMiBTYWx0ZWRfXwvHzXkw1Ghwo VTWHN+cE0QcyT8/988a5Oy+uAOazKG7OlmsNXf6ZvKU2OyjqEb00Sa9h8VlU6IHLn1MggoDaL63 J4VspSDKrq2+1hsiPGGebKrNx1EbL+82psEcU80PFvDCmekkqaZ0vPpe50F3A5EaUR4LmuwQ/0/
 5epCz7Ptq9XMUYKeq1zKwhT+tfKcNQIo5OBB6gHBUbG+j6+i6nLPuvYTfHveUXDpsZodJnk3zhE dYIyrVXtl4+cv0sSN2VcggnidQvKiNBmeIRb1oZr2g8ApheWzI/LFgHDf9f1hikiirl+WDTTu2o hrO0CgP9O7GbjWJ1Qv5gnL+YaCYVb0XAW2qQksVnQpXkvM1+8blus9YJd/GZULoBxkCwuh7NK+D
 rogA/0jqvGwDi1VvpGA1UI8O2sBoSl5dajC9s32rmbJOY1rQ4pEeWsPUoLCQb5SieKUycFW4
X-Authority-Analysis: v=2.4 cv=CfMI5Krl c=1 sm=1 tr=0 ts=684b1013 cx=c_pps a=3Bg1Hr4SwmMryq2xdFQyZA==:117 a=3Bg1Hr4SwmMryq2xdFQyZA==:17 a=6IFa9wvqVegA:10 a=pGLkceISAAAA:8 a=VnNF1IyMAAAA:8 a=RJXGA7rP2o630YCXQOwA:9
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40
 definitions=2025-06-12_10,2025-06-12_02,2025-03-28_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 spamscore=0
 phishscore=0 priorityscore=1501 clxscore=1011 impostorscore=0 mlxscore=0
 suspectscore=0 mlxlogscore=914 adultscore=0 malwarescore=0
 lowpriorityscore=0 classifier=spam authscore=0 authtc=n/a authcc=
 route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2505280000
 definitions=main-2506120132

Make default arch_enter|leave|flush_lazy_mmu_mode() callbacks
complain on enabled preemption to detect wrong contexts. That
could help to prevent the complicated lazy MMU mode semantics
misuse, such like one that was solved with commit b9ef323ea168
("powerpc/64s: Disable preemption in hash lazy mmu mode").

Skip fully preemptible kernels, since in such case taking the
page table lock does not disable preemption, so the described
check would be wrong.

Most platforms do not implement the lazy MMU mode callbacks,
so to aovid a performance impact allow the complaint when
CONFIG_DEBUG_VM option is enabled only.

Reviewed-by: Nicholas Piggin 
Signed-off-by: Alexander Gordeev 
---
 include/linux/pgtable.h | 20 +++++++++++++++++---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index 33bf2b13c219..0cb8abdc58a8 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -232,9 +232,23 @@ static inline int pmd_dirty(pmd_t pmd)
  * Nesting is not permitted and the mode cannot be used in interrupt context.
  */
 #ifndef __HAVE_ARCH_ENTER_LAZY_MMU_MODE
-#define arch_enter_lazy_mmu_mode()	do {} while (0)
-#define arch_leave_lazy_mmu_mode()	do {} while (0)
-#define arch_flush_lazy_mmu_mode()	do {} while (0)
+static inline void arch_enter_lazy_mmu_mode(void)
+{
+	if (!IS_ENABLED(CONFIG_PREEMPT_RT))
+		VM_WARN_ON_ONCE(preemptible());
+}
+
+static inline void arch_leave_lazy_mmu_mode(void)
+{
+	if (!IS_ENABLED(CONFIG_PREEMPT_RT))
+		VM_WARN_ON_ONCE(preemptible());
+}
+
+static inline void arch_flush_lazy_mmu_mode(void)
+{
+	if (!IS_ENABLED(CONFIG_PREEMPT_RT))
+		VM_WARN_ON_ONCE(preemptible());
+}
 #endif
 
 #ifndef pte_batch_hint
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Thu Jun 12 17:36:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 17:36:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013362.1391857 (Exim 4.92)
	(envelope-from )
	id 1uPlqu-0000FM-A4; Thu, 12 Jun 2025 17:36:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013362.1391857; Thu, 12 Jun 2025 17:36:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPlqu-0000DO-2n; Thu, 12 Jun 2025 17:36:36 +0000
Received: by outflank-mailman (input) for mailman id 1013362;
 Thu, 12 Jun 2025 17:36: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 1uPlqt-00008H-1L
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 17:36:35 +0000
Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com
 [148.163.156.1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c787acf8-47b3-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 19:36:33 +0200 (CEST)
Received: from pps.filterd (m0360083.ppops.net [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 55CDVPIr012486;
 Thu, 12 Jun 2025 17:36:18 GMT
Received: from pps.reinject (localhost [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 474cxjmf0u-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Thu, 12 Jun 2025 17:36:17 +0000 (GMT)
Received: from m0360083.ppops.net (m0360083.ppops.net [127.0.0.1])
 by pps.reinject (8.18.0.8/8.18.0.8) with ESMTP id 55CHaHOc028261;
 Thu, 12 Jun 2025 17:36:17 GMT
Received: from ppma21.wdc07v.mail.ibm.com
 (5b.69.3da9.ip4.static.sl-reverse.com [169.61.105.91])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 474cxjmf0m-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Thu, 12 Jun 2025 17:36:17 +0000 (GMT)
Received: from pps.filterd (ppma21.wdc07v.mail.ibm.com [127.0.0.1])
 by ppma21.wdc07v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 55CE2lWZ014912;
 Thu, 12 Jun 2025 17:36:16 GMT
Received: from smtprelay04.fra02v.mail.ibm.com ([9.218.2.228])
 by ppma21.wdc07v.mail.ibm.com (PPS) with ESMTPS id 4750rpdxe4-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Thu, 12 Jun 2025 17:36:15 +0000
Received: from smtpav06.fra02v.mail.ibm.com (smtpav06.fra02v.mail.ibm.com
 [10.20.54.105])
 by smtprelay04.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id
 55CHaEm611338160
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Thu, 12 Jun 2025 17:36:14 GMT
Received: from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 00E3020040;
 Thu, 12 Jun 2025 17:36:14 +0000 (GMT)
Received: from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id E100A2004B;
 Thu, 12 Jun 2025 17:36:13 +0000 (GMT)
Received: from tuxmaker.boeblingen.de.ibm.com (unknown [9.152.85.9])
 by smtpav06.fra02v.mail.ibm.com (Postfix) with ESMTPS;
 Thu, 12 Jun 2025 17:36:13 +0000 (GMT)
Received: by tuxmaker.boeblingen.de.ibm.com (Postfix, from userid 55669)
 id 9DA9BE198F; Thu, 12 Jun 2025 19:36:13 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c787acf8-47b3-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc
	:content-transfer-encoding:date:from:in-reply-to:message-id
	:mime-version:references:subject:to; s=pp1; bh=Bzq6L693jOZBbQpnk
	olPJGXvQrWYd1fA+nYNAUkTJK4=; b=ESDJHNKEE5xuMiyIFUW6rYf02Me5a5lyb
	sWhbyWwUtgNFGu8PZLKdUv0/9qZAokrkZRb85d5PqBmzMqJaTlf6PYCK7ooXS42h
	Sq9hPT9J3MS2Gveds7bG8V2afGAi1+Bp71tEdFw4AjRsQPRDr1Umq+yV+i/+HxRz
	n29nAJUsXyZsJzo6atbehh0gZuHskVtQ+fWRjZb2/pbovS94Rs2p0L6Km7uhekrU
	1t3NzEXRsgT+51JGwOIO1WeLGZ6quB0XBM0mrJpvTTYoJ7Z5pR4AoRk4/Ge4a+HQ
	k5s7CGGTEeBuimVvxzeF5PeRGYrxNKHgZgbVs7HstYNamBwuMdVew==
From: Alexander Gordeev 
To: Andrew Morton 
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
        sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org,
        linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org,
        Hugh Dickins , Nicholas Piggin ,
        Guenter Roeck , Juergen Gross ,
        Jeremy Fitzhardinge ,
        Ryan Roberts 
Subject: [PATCH 1/6] mm: Cleanup apply_to_pte_range() routine
Date: Thu, 12 Jun 2025 19:36:08 +0200
Message-ID: 
X-Mailer: git-send-email 2.48.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-TM-AS-GCONF: 00
X-Proofpoint-ORIG-GUID: GFSzaItUyEu6yP3gS3meeLbrZ9VQTNp2
X-Proofpoint-GUID: sqmBLLFPSau8kX6gstpm2ABJeaMXDzrY
X-Authority-Analysis: v=2.4 cv=fZWty1QF c=1 sm=1 tr=0 ts=684b1012 cx=c_pps a=GFwsV6G8L6GxiO2Y/PsHdQ==:117 a=GFwsV6G8L6GxiO2Y/PsHdQ==:17 a=6IFa9wvqVegA:10 a=pGLkceISAAAA:8 a=VnNF1IyMAAAA:8 a=cw6LjJxz1Y3IMotYGxwA:9
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjEyMDEzMiBTYWx0ZWRfX/1bjcnG+oHBr pQDvf9bYzabUNkDtJTPjUxbszAUvnuseyUY6yPMmqPawboY3JQdlIMe1zE8qPlqEMiTmIRm5hS1 dZl7AQt+DbprJCkJokCTDYCd0VMJnUOxqaxW//MoOIuKhE3bFMliw0UK15vBUQ0lRDM+mrJj2zC
 yUpjswXJHT+h6+EpfvFovs4dCh6L5u4Ykn2tCFCfD453NQH13H8nIpNRXk+HHxhvDrVWycEacW4 /2czHIQffp42M7ictd08dwUcFf3euUuwxOXSbJ5WuxC/Hv/Vzb/9Vv1wFBVJU+FMSP1gFiqJsd0 VvDwZoAVDaHgmVW6Mu34ZDZJ8Cw6qnhtSzv7T/Boq9y8bX+AMp7SzKTkfdMd9g5rnuiIrxSQFrI
 0E24jrpYAI52CuduE9GnxB2obbmRbpdrR9rNV8uM47GqJ34ZsBxm2r2PUC1QUcejP/SHofJr
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40
 definitions=2025-06-12_10,2025-06-12_02,2025-03-28_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1011 impostorscore=0
 priorityscore=1501 spamscore=0 bulkscore=0 phishscore=0 suspectscore=0
 adultscore=0 mlxscore=0 malwarescore=0 lowpriorityscore=0 mlxlogscore=780
 classifier=spam authscore=0 authtc=n/a authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.19.0-2505280000
 definitions=main-2506120132

Reverse 'create' vs 'mm == &init_mm' conditions and move
page table mask modification out of the atomic context.
This is a prerequisite for locking kernel page tables.

Reviewed-by: Nicholas Piggin 
Signed-off-by: Alexander Gordeev 
---
 mm/memory.c | 28 +++++++++++++++++-----------
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/mm/memory.c b/mm/memory.c
index 8eba595056fe..71b3d3f98999 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3006,24 +3006,28 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
 				     pte_fn_t fn, void *data, bool create,
 				     pgtbl_mod_mask *mask)
 {
+	int err = create ? -ENOMEM : -EINVAL;
 	pte_t *pte, *mapped_pte;
-	int err = 0;
 	spinlock_t *ptl;
 
-	if (create) {
-		mapped_pte = pte = (mm == &init_mm) ?
-			pte_alloc_kernel_track(pmd, addr, mask) :
-			pte_alloc_map_lock(mm, pmd, addr, &ptl);
+	if (mm == &init_mm) {
+		if (create)
+			pte = pte_alloc_kernel_track(pmd, addr, mask);
+		else
+			pte = pte_offset_kernel(pmd, addr);
 		if (!pte)
-			return -ENOMEM;
+			return err;
 	} else {
-		mapped_pte = pte = (mm == &init_mm) ?
-			pte_offset_kernel(pmd, addr) :
-			pte_offset_map_lock(mm, pmd, addr, &ptl);
+		if (create)
+			pte = pte_alloc_map_lock(mm, pmd, addr, &ptl);
+		else
+			pte = pte_offset_map_lock(mm, pmd, addr, &ptl);
 		if (!pte)
-			return -EINVAL;
+			return err;
+		mapped_pte = pte;
 	}
 
+	err = 0;
 	arch_enter_lazy_mmu_mode();
 
 	if (fn) {
@@ -3035,12 +3039,14 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
 			}
 		} while (pte++, addr += PAGE_SIZE, addr != end);
 	}
-	*mask |= PGTBL_PTE_MODIFIED;
 
 	arch_leave_lazy_mmu_mode();
 
 	if (mm != &init_mm)
 		pte_unmap_unlock(mapped_pte, ptl);
+
+	*mask |= PGTBL_PTE_MODIFIED;
+
 	return err;
 }
 
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Thu Jun 12 17:36:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 17:36:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013363.1391882 (Exim 4.92)
	(envelope-from )
	id 1uPlqw-0000rt-38; Thu, 12 Jun 2025 17:36:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013363.1391882; Thu, 12 Jun 2025 17: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 1uPlqv-0000qH-R1; Thu, 12 Jun 2025 17:36:37 +0000
Received: by outflank-mailman (input) for mailman id 1013363;
 Thu, 12 Jun 2025 17:36: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 1uPlqu-00008H-3M
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 17:36:36 +0000
Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com
 [148.163.156.1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c8b3d150-47b3-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 19:36:35 +0200 (CEST)
Received: from pps.filterd (m0360083.ppops.net [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 55CDJP2V021059;
 Thu, 12 Jun 2025 17:36:17 GMT
Received: from pps.reinject (localhost [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 474cxjmf0n-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Thu, 12 Jun 2025 17:36:17 +0000 (GMT)
Received: from m0360083.ppops.net (m0360083.ppops.net [127.0.0.1])
 by pps.reinject (8.18.0.8/8.18.0.8) with ESMTP id 55CHZKKa027345;
 Thu, 12 Jun 2025 17:36:16 GMT
Received: from ppma13.dal12v.mail.ibm.com
 (dd.9e.1632.ip4.static.sl-reverse.com [50.22.158.221])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 474cxjmf0g-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Thu, 12 Jun 2025 17:36:16 +0000 (GMT)
Received: from pps.filterd (ppma13.dal12v.mail.ibm.com [127.0.0.1])
 by ppma13.dal12v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 55CF2fhL003405;
 Thu, 12 Jun 2025 17:36:15 GMT
Received: from smtprelay06.fra02v.mail.ibm.com ([9.218.2.230])
 by ppma13.dal12v.mail.ibm.com (PPS) with ESMTPS id 4751ykwr2m-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Thu, 12 Jun 2025 17:36:15 +0000
Received: from smtpav05.fra02v.mail.ibm.com (smtpav05.fra02v.mail.ibm.com
 [10.20.54.104])
 by smtprelay06.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id
 55CHaE2d23134776
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Thu, 12 Jun 2025 17:36:14 GMT
Received: from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 01F1220040;
 Thu, 12 Jun 2025 17:36:14 +0000 (GMT)
Received: from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id DF1282004B;
 Thu, 12 Jun 2025 17:36:13 +0000 (GMT)
Received: from tuxmaker.boeblingen.de.ibm.com (unknown [9.152.85.9])
 by smtpav05.fra02v.mail.ibm.com (Postfix) with ESMTPS;
 Thu, 12 Jun 2025 17:36:13 +0000 (GMT)
Received: by tuxmaker.boeblingen.de.ibm.com (Postfix, from userid 55669)
 id A01ECE1994; Thu, 12 Jun 2025 19:36:13 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c8b3d150-47b3-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc
	:content-transfer-encoding:date:from:in-reply-to:message-id
	:mime-version:references:subject:to; s=pp1; bh=lzDJpUIXBz/mvS0mb
	FYxHi8XUevGZ8hUcNGEGhasovg=; b=jqMrmg9P9k4as1yQGOTnccjGWG4WF7DEd
	kBXZ1I/97XSYVJbQ+zJBG+JgVx32TNUOqAFmET9+GHhIolrdsQYgYJ2idUI/YD4s
	/xUki5YiOsCOWB0+AVe6rTijtZk1rs6M50nDxRavBOMoS4SGnhy/c7sgJNTotjGi
	6sHMEPK/4npj5FfsZvDdx7jicu1aU5DQMLUhDTl2TpSTAMuwTZfKAnXRxT3UkPF3
	ZIbIMaHnARDwFnGT4yVd8DLscyKbq+WfXuWGn4G+cz7HIOzlYlL6g2UMRNBBQL+M
	8Zy82y8ly2Bvl1bgxesKbgKejydEi6fT68K8HNFyFta7GIJKlnKig==
From: Alexander Gordeev 
To: Andrew Morton 
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
        sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org,
        linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org,
        Hugh Dickins , Nicholas Piggin ,
        Guenter Roeck , Juergen Gross ,
        Jeremy Fitzhardinge ,
        Ryan Roberts 
Subject: [PATCH 2/6] mm: Lock kernel page tables before entering lazy MMU mode
Date: Thu, 12 Jun 2025 19:36:09 +0200
Message-ID: <7bd3a45dbc375dc2c15cebae09cb2bb972d6039f.1749747752.git.agordeev@linux.ibm.com>
X-Mailer: git-send-email 2.48.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-TM-AS-GCONF: 00
X-Proofpoint-ORIG-GUID: Tb8VA6zUpjW5k1WLGI1WWxPCHUixj1UW
X-Proofpoint-GUID: EYQIsAXzx8ssoXkn44spur2V7kFJyFNc
X-Authority-Analysis: v=2.4 cv=fZWty1QF c=1 sm=1 tr=0 ts=684b1011 cx=c_pps a=AfN7/Ok6k8XGzOShvHwTGQ==:117 a=AfN7/Ok6k8XGzOShvHwTGQ==:17 a=6IFa9wvqVegA:10 a=VnNF1IyMAAAA:8 a=nMoVGufP4iL6dWhmM1oA:9
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjEyMDEzMiBTYWx0ZWRfX7wfxBioE0ali sfc9SNNLuo/uwJWDA3c2xkqqH6rfdv8VXDTQiKWPjoWwN5+YNEn8jTxawLHSc7kSvcbTRzlAEEL 6pE4EG7uVAXP0cTCdUVctrhAA4dPIy9K280bl6EZsHWeiac5dQkU3M23hors8FvuTbzgDf1h9Fp
 4/5hS9LAZnskUMvo6VVxjD1ejeCUnSJ9GDLuknHP+02KFBqLWFqJX4Uj1GH9ITY9ehAeYHg8CPo +NXj5bCNfgunV/T0oR4Y7LXv81qmzH4CP/fN90LYdPGDzAKY9KoFLxiARID9WfB4E8JGYFRMR8X KU0u1kTIIScAeHrSUf7iG+tUJ+YeiYm2VyY0+i/fL8MGK6FCaPHEVVMgFI0JFtKLssBxImKqXFF
 +8XQ7Gu5M/Tz5OkRu7P75cBzlchWZR0cnEVFWg54GBSdDJyxQ+nNXw3MOOvDg1EdtYnL8aNA
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40
 definitions=2025-06-12_10,2025-06-12_02,2025-03-28_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1011 impostorscore=0
 priorityscore=1501 spamscore=0 bulkscore=0 phishscore=0 suspectscore=0
 adultscore=0 mlxscore=0 malwarescore=0 lowpriorityscore=0 mlxlogscore=965
 classifier=spam authscore=0 authtc=n/a authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.19.0-2505280000
 definitions=main-2506120132

As a follow-up to commit 691ee97e1a9d ("mm: fix lazy mmu docs and
usage") take a step forward and protect with a lock not only user,
but also kernel mappings before entering the lazy MMU mode. With
that the semantics of arch_enter|leave_lazy_mmu_mode() callbacks
is consolidated, which allows further simplifications.

The effect of this consolidation is not fully preemptible (Real-Time)
kernels can not enter the context switch while the lazy MMU mode is
active - which is easier to comprehend.

Signed-off-by: Alexander Gordeev 
---
 include/linux/pgtable.h | 12 ++++++------
 mm/kasan/shadow.c       |  5 -----
 mm/memory.c             |  5 ++++-
 mm/vmalloc.c            |  6 ++++++
 4 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index 0b6e1f781d86..33bf2b13c219 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -224,12 +224,12 @@ static inline int pmd_dirty(pmd_t pmd)
  * a raw PTE pointer after it has been modified are not guaranteed to be
  * up to date.
  *
- * In the general case, no lock is guaranteed to be held between entry and exit
- * of the lazy mode. So the implementation must assume preemption may be enabled
- * and cpu migration is possible; it must take steps to be robust against this.
- * (In practice, for user PTE updates, the appropriate page table lock(s) are
- * held, but for kernel PTE updates, no lock is held). Nesting is not permitted
- * and the mode cannot be used in interrupt context.
+ * For PREEMPT_RT kernels implementation must assume that preemption may
+ * be enabled and cpu migration is possible between entry and exit of the
+ * lazy MMU mode; it must take steps to be robust against this. There is
+ * no such assumption for non-PREEMPT_RT kernels, since both kernel and
+ * user page tables are protected with a spinlock while in lazy MMU mode.
+ * Nesting is not permitted and the mode cannot be used in interrupt context.
  */
 #ifndef __HAVE_ARCH_ENTER_LAZY_MMU_MODE
 #define arch_enter_lazy_mmu_mode()	do {} while (0)
diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c
index d2c70cd2afb1..45115bd770a9 100644
--- a/mm/kasan/shadow.c
+++ b/mm/kasan/shadow.c
@@ -313,12 +313,10 @@ static int kasan_populate_vmalloc_pte(pte_t *ptep, unsigned long addr,
 	__memset(page_to_virt(page), KASAN_VMALLOC_INVALID, PAGE_SIZE);
 	pte = pfn_pte(page_to_pfn(page), PAGE_KERNEL);
 
-	spin_lock(&init_mm.page_table_lock);
 	if (likely(pte_none(ptep_get(ptep)))) {
 		set_pte_at(&init_mm, addr, ptep, pte);
 		data->pages[index] = NULL;
 	}
-	spin_unlock(&init_mm.page_table_lock);
 
 	return 0;
 }
@@ -465,13 +463,10 @@ static int kasan_depopulate_vmalloc_pte(pte_t *ptep, unsigned long addr,
 
 	page = (unsigned long)__va(pte_pfn(ptep_get(ptep)) << PAGE_SHIFT);
 
-	spin_lock(&init_mm.page_table_lock);
-
 	if (likely(!pte_none(ptep_get(ptep)))) {
 		pte_clear(&init_mm, addr, ptep);
 		free_page(page);
 	}
-	spin_unlock(&init_mm.page_table_lock);
 
 	return 0;
 }
diff --git a/mm/memory.c b/mm/memory.c
index 71b3d3f98999..1ddc532b1f13 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3017,6 +3017,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
 			pte = pte_offset_kernel(pmd, addr);
 		if (!pte)
 			return err;
+		spin_lock(&init_mm.page_table_lock);
 	} else {
 		if (create)
 			pte = pte_alloc_map_lock(mm, pmd, addr, &ptl);
@@ -3042,7 +3043,9 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
 
 	arch_leave_lazy_mmu_mode();
 
-	if (mm != &init_mm)
+	if (mm == &init_mm)
+		spin_unlock(&init_mm.page_table_lock);
+	else
 		pte_unmap_unlock(mapped_pte, ptl);
 
 	*mask |= PGTBL_PTE_MODIFIED;
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index ab986dd09b6a..57b11000ae36 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -105,6 +105,7 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
 	if (!pte)
 		return -ENOMEM;
 
+	spin_lock(&init_mm.page_table_lock);
 	arch_enter_lazy_mmu_mode();
 
 	do {
@@ -132,6 +133,7 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
 	} while (pte += PFN_DOWN(size), addr += size, addr != end);
 
 	arch_leave_lazy_mmu_mode();
+	spin_unlock(&init_mm.page_table_lock);
 	*mask |= PGTBL_PTE_MODIFIED;
 	return 0;
 }
@@ -359,6 +361,7 @@ static void vunmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
 	unsigned long size = PAGE_SIZE;
 
 	pte = pte_offset_kernel(pmd, addr);
+	spin_lock(&init_mm.page_table_lock);
 	arch_enter_lazy_mmu_mode();
 
 	do {
@@ -379,6 +382,7 @@ static void vunmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
 	} while (pte += (size >> PAGE_SHIFT), addr += size, addr != end);
 
 	arch_leave_lazy_mmu_mode();
+	spin_unlock(&init_mm.page_table_lock);
 	*mask |= PGTBL_PTE_MODIFIED;
 }
 
@@ -525,6 +529,7 @@ static int vmap_pages_pte_range(pmd_t *pmd, unsigned long addr,
 	if (!pte)
 		return -ENOMEM;
 
+	spin_lock(&init_mm.page_table_lock);
 	arch_enter_lazy_mmu_mode();
 
 	do {
@@ -542,6 +547,7 @@ static int vmap_pages_pte_range(pmd_t *pmd, unsigned long addr,
 	} while (pte++, addr += PAGE_SIZE, addr != end);
 
 	arch_leave_lazy_mmu_mode();
+	spin_unlock(&init_mm.page_table_lock);
 	*mask |= PGTBL_PTE_MODIFIED;
 	return 0;
 }
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Thu Jun 12 17:36:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 17:36:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013361.1391851 (Exim 4.92)
	(envelope-from )
	id 1uPlqu-0000Ag-1B; Thu, 12 Jun 2025 17:36:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013361.1391851; Thu, 12 Jun 2025 17:36:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPlqt-00009b-Sy; Thu, 12 Jun 2025 17:36:35 +0000
Received: by outflank-mailman (input) for mailman id 1013361;
 Thu, 12 Jun 2025 17:36: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 1uPlqs-000083-DO
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 17:36:34 +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 c6ba90a3-47b3-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 19:36:31 +0200 (CEST)
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 55C9xpHh005022;
 Thu, 12 Jun 2025 17:36:17 GMT
Received: from pps.reinject (localhost [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 474x4mhdbs-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Thu, 12 Jun 2025 17:36:16 +0000 (GMT)
Received: from m0360072.ppops.net (m0360072.ppops.net [127.0.0.1])
 by pps.reinject (8.18.0.8/8.18.0.8) with ESMTP id 55CHaGIg029272;
 Thu, 12 Jun 2025 17:36:16 GMT
Received: from ppma12.dal12v.mail.ibm.com
 (dc.9e.1632.ip4.static.sl-reverse.com [50.22.158.220])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 474x4mhdbp-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Thu, 12 Jun 2025 17:36:16 +0000 (GMT)
Received: from pps.filterd (ppma12.dal12v.mail.ibm.com [127.0.0.1])
 by ppma12.dal12v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 55CGbdNq015205;
 Thu, 12 Jun 2025 17:36:15 GMT
Received: from smtprelay07.fra02v.mail.ibm.com ([9.218.2.229])
 by ppma12.dal12v.mail.ibm.com (PPS) with ESMTPS id 474yrtp6b1-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Thu, 12 Jun 2025 17:36:15 +0000
Received: from smtpav07.fra02v.mail.ibm.com (smtpav07.fra02v.mail.ibm.com
 [10.20.54.106])
 by smtprelay07.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id
 55CHaE2S46072192
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Thu, 12 Jun 2025 17:36:14 GMT
Received: from smtpav07.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id F201B20043;
 Thu, 12 Jun 2025 17:36:13 +0000 (GMT)
Received: from smtpav07.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id DE45420040;
 Thu, 12 Jun 2025 17:36:13 +0000 (GMT)
Received: from tuxmaker.boeblingen.de.ibm.com (unknown [9.152.85.9])
 by smtpav07.fra02v.mail.ibm.com (Postfix) with ESMTPS;
 Thu, 12 Jun 2025 17:36:13 +0000 (GMT)
Received: by tuxmaker.boeblingen.de.ibm.com (Postfix, from userid 55669)
 id 9B577E0157; Thu, 12 Jun 2025 19:36:13 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c6ba90a3-47b3-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc
	:content-transfer-encoding:date:from:message-id:mime-version
	:subject:to; s=pp1; bh=ANjAB/i+3wqbtm/fqKC9pjVNNGYd+LvuX5UmSeokV
	jQ=; b=gPjOJz2DlLLAahuxLsMvga8P96e5QtjjssuX3WnL7wfNwU9S7odZ1iF9n
	AHXZaL0QgY2Yvv6+PISmVU8AGURt3TkfFKWYn1x50taMSKAa7h1Py0L08hzBockn
	sQx28XfA83iutCkSgewhPkGk2hg9n0qPC6L8fNJUmDuqW9yEPkMry4L+GC9tTYO0
	SD4Ldvr2NfjhdTYVv7Rn944LtNQhipOioR+F7fsnJ9kdle/XbEcv+ONZ2kYaVUYJ
	/VTaRAakSqlZ1oK9rnq/4HmKpkaucRMwQY60+eLDS+xgc8bSOsXNrs+da1Mm5Jx9
	DxiiZIL4w7ZQHN8ei7UjgxYir2X1w==
From: Alexander Gordeev 
To: Andrew Morton 
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
        sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org,
        linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org,
        Hugh Dickins , Nicholas Piggin ,
        Guenter Roeck , Juergen Gross ,
        Jeremy Fitzhardinge ,
        Ryan Roberts 
Subject: [PATCH 0/6] mm: Consolidate lazy MMU mode context
Date: Thu, 12 Jun 2025 19:36:07 +0200
Message-ID: 
X-Mailer: git-send-email 2.48.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-TM-AS-GCONF: 00
X-Authority-Analysis: v=2.4 cv=Y4X4sgeN c=1 sm=1 tr=0 ts=684b1011 cx=c_pps a=bLidbwmWQ0KltjZqbj+ezA==:117 a=bLidbwmWQ0KltjZqbj+ezA==:17 a=6IFa9wvqVegA:10 a=VwQbUJbxAAAA:8 a=VnNF1IyMAAAA:8 a=_adeEUt4WAeD9YfioJwA:9
X-Proofpoint-GUID: qr5W2YIzc2A8ZYU2dsRpP1AphHqeKos2
X-Proofpoint-ORIG-GUID: y6xW9IJSAE1JE6kcXuiy_mrCImk2ZWSK
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjEyMDEzMiBTYWx0ZWRfXwOXjIkbbpepd OoV77Zxzv1DOdGZHdC1rjgNBCs+WzETf7mIinKv8drROUhS3PC4S3Ul3Eq1Rd7PKATmFyM+TDvL kAnBooerznbgDsNZ+/ZPaU+KOsEBXC93w8q9w6KmW11m/vgE/aUeMTSFQFutpSKrQJxT61mMBuv
 KSDxU4i8iMDqRaETa8beoNjTewS286bfktL7BQreW7c9kRIZcei0lJ9aqGyaWPDFPjwcafICCtq M+2fDqSlBJ149EKa1BJjaYXJjRiLvX/CmWd9wRa81Sdbs49mWKwGJKFbJ7AczMoR5fjZJzIohlx h7ggGzYUtbK6qCOXcSYaA1viUBK2oMNNt7ackAbJO+mupvs+X1Tc6Jccl69/IVghIosL27dXHPA
 isXNAQ9475tlf5eWUprb3n3jaqwe+zULK27nDf9N0r4ezafy+XnKcezzdAsVHSGEj7SQHlPp
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40
 definitions=2025-06-12_10,2025-06-12_02,2025-03-28_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=994 spamscore=0
 clxscore=1011 lowpriorityscore=0 malwarescore=0 bulkscore=0 adultscore=0
 impostorscore=0 suspectscore=0 phishscore=0 mlxscore=0 priorityscore=1501
 classifier=spam authscore=0 authtc=n/a authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.19.0-2505280000
 definitions=main-2506120132

Hi All,

Consolidate arch_enter|leave|flush_lazy_mmu_mode() context and protect
with a lock not only user, but also kernel mappings before entering
the lazy MMU mode.

For not fully preemptible (Real-Time) kernels that simplifies semantics -
while the mode is active the code should assume it is executing in atomic
context. That paves the way for cleanups, such as suggested for sparc and
powerpc and hopefully brings a bit more clarity in what labeled in commit
691ee97e1a9d ("mm: fix lazy mmu docs and usage") as "a bit of a mess (to
put it politely)".

The fully preemptible (Real-Time) kernels could probably also be brought
into the fold, but I am not sure about implications (to say at least).

This series is continuation of [1] and [2], with commit b6ea95a34cbd
("kasan: avoid sleepable page allocation from atomic context") already
upstream.

I dared to keep Nicholas Piggin R-b on patch 3, but dropped it from
patch 2 due to new bits.

Except the optional sparc (untested) and powerpc (complile-tested)
updates this series is a prerequisite for implementation of lazy MMU
mode on s390.

1. https://lore.kernel.org/linux-mm/cover.1744037648.git.agordeev@linux.ibm.com/#r
2. https://lore.kernel.org/linux-mm/cover.1744128123.git.agordeev@linux.ibm.com/#r

Thanks!

Alexander Gordeev (6):
  mm: Cleanup apply_to_pte_range() routine
  mm: Lock kernel page tables before entering lazy MMU mode
  mm/debug: Detect wrong arch_enter_lazy_mmu_mode() contexts
  sparc/mm: Do not disable preemption in lazy MMU mode
  powerpc/64s: Do not disable preemption in lazy MMU mode
  powerpc/64s: Do not re-activate batched TLB flush

 .../include/asm/book3s/64/tlbflush-hash.h     | 13 ++++----
 arch/powerpc/include/asm/thread_info.h        |  2 --
 arch/powerpc/kernel/process.c                 | 25 --------------
 arch/sparc/include/asm/tlbflush_64.h          |  2 +-
 arch/sparc/mm/tlb.c                           | 12 ++++---
 include/linux/pgtable.h                       | 32 +++++++++++++-----
 mm/kasan/shadow.c                             |  5 ---
 mm/memory.c                                   | 33 ++++++++++++-------
 mm/vmalloc.c                                  |  6 ++++
 9 files changed, 65 insertions(+), 65 deletions(-)

-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Thu Jun 12 17:36:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 17:36:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013360.1391846 (Exim 4.92)
	(envelope-from )
	id 1uPlqt-00008V-QU; Thu, 12 Jun 2025 17:36:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013360.1391846; Thu, 12 Jun 2025 17:36:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPlqt-00008N-NO; Thu, 12 Jun 2025 17:36:35 +0000
Received: by outflank-mailman (input) for mailman id 1013360;
 Thu, 12 Jun 2025 17:36: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 1uPlqr-000083-P8
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 17:36:33 +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 c69d462d-47b3-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 19:36:31 +0200 (CEST)
Received: from pps.filterd (m0356516.ppops.net [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 55CCr3E5027868;
 Thu, 12 Jun 2025 17:36:17 GMT
Received: from pps.reinject (localhost [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 474hguue6g-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Thu, 12 Jun 2025 17:36:17 +0000 (GMT)
Received: from m0356516.ppops.net (m0356516.ppops.net [127.0.0.1])
 by pps.reinject (8.18.0.8/8.18.0.8) with ESMTP id 55CHXi2p029325;
 Thu, 12 Jun 2025 17:36:16 GMT
Received: from ppma12.dal12v.mail.ibm.com
 (dc.9e.1632.ip4.static.sl-reverse.com [50.22.158.220])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 474hguue6f-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Thu, 12 Jun 2025 17:36:16 +0000 (GMT)
Received: from pps.filterd (ppma12.dal12v.mail.ibm.com [127.0.0.1])
 by ppma12.dal12v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 55CGdbAS015184;
 Thu, 12 Jun 2025 17:36:16 GMT
Received: from smtprelay06.fra02v.mail.ibm.com ([9.218.2.230])
 by ppma12.dal12v.mail.ibm.com (PPS) with ESMTPS id 474yrtp6b4-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Thu, 12 Jun 2025 17:36:16 +0000
Received: from smtpav05.fra02v.mail.ibm.com (smtpav05.fra02v.mail.ibm.com
 [10.20.54.104])
 by smtprelay06.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id
 55CHaEtZ33358432
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Thu, 12 Jun 2025 17:36:14 GMT
Received: from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 45F9520043;
 Thu, 12 Jun 2025 17:36:14 +0000 (GMT)
Received: from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 31BD320040;
 Thu, 12 Jun 2025 17:36:14 +0000 (GMT)
Received: from tuxmaker.boeblingen.de.ibm.com (unknown [9.152.85.9])
 by smtpav05.fra02v.mail.ibm.com (Postfix) with ESMTPS;
 Thu, 12 Jun 2025 17:36:14 +0000 (GMT)
Received: by tuxmaker.boeblingen.de.ibm.com (Postfix, from userid 55669)
 id A6F65E19CF; Thu, 12 Jun 2025 19:36:13 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c69d462d-47b3-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc
	:content-transfer-encoding:date:from:in-reply-to:message-id
	:mime-version:references:subject:to; s=pp1; bh=4hV4IXUZ8LEPGuSQG
	01CQzmpidG+/SLdlI31Go35JsY=; b=s1GKeiAiMdnysT0X4IxcglrScCDxHGupI
	zA15vl63KE6Seni7PWOENpJ/Gv59FM2b1Ca6r2wUSawQqzznf++bc8pp+JrLepvD
	11bMaHktb6H3M6gxH1wWrRWImCuQvvEnNAl5zja2tALWGEHRiMhzoaVOi8QGHYaw
	aZz6TyrWN7R8ZtTMfSaiN5+qPDW6ofgwqKI4u93tJjADKNFDM9eGeeyxox6+z/Tg
	/YvxI01+Nyzw+6LR0Ko1q4QdNC8AvCEPF/VQKQe07zyBatxjhnu2th41Vj34ykJb
	VJ7AFrQxxkj8nBsjbedXmLfZ9S4sPBvTCF878vtwezm8Z8t+8f7XQ==
From: Alexander Gordeev 
To: Andrew Morton 
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
        sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org,
        linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org,
        Hugh Dickins , Nicholas Piggin ,
        Guenter Roeck , Juergen Gross ,
        Jeremy Fitzhardinge ,
        Ryan Roberts 
Subject: [PATCH 5/6] powerpc/64s: Do not disable preemption in lazy MMU mode
Date: Thu, 12 Jun 2025 19:36:12 +0200
Message-ID: <448f6e26a9d72fb2c873245ea948807491f6b798.1749747752.git.agordeev@linux.ibm.com>
X-Mailer: git-send-email 2.48.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-TM-AS-GCONF: 00
X-Authority-Analysis: v=2.4 cv=Pfr/hjhd c=1 sm=1 tr=0 ts=684b1011 cx=c_pps a=bLidbwmWQ0KltjZqbj+ezA==:117 a=bLidbwmWQ0KltjZqbj+ezA==:17 a=6IFa9wvqVegA:10 a=VnNF1IyMAAAA:8 a=Nsn6zn2YLSyj-wdhBosA:9
X-Proofpoint-GUID: Y7JL08S83tcOGpHgHyKOLNsFJBfulgi4
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjEyMDEzMiBTYWx0ZWRfXxvLPCGltFBs6 pER1hH7Vt06TbX8owkaLIhYurkg/bfiZiDeVHa0PPT4UG5RzmpaRyaYzy4ZzCd+x8pHRBQxHNsW LlMM92svD1VKZhMAfFH8HhjxN6kzFIktURb71PQI+3H4WVjFhd6e0GNz+MKZ65cpAblc41X74IX
 VWf/EXsyOP+k9EtZQhTtCLK0y9XnX1bfZybbHwQJ+iYyzR+cu2qDSo2vTQjKBcaqzXtO6QCws/G ahxfH8pkJ/OernQEEfBz8Qu/RAndqb3+4jUDYJorjlTofk/Ag29ituHGNj7JG2D1/13Yq1Xceww QO2NYvvcSi2BXvJvwSvBOgqw+ea0ndyQmYpre/Tbc4lnWu8mCsCWILjWTkHUy9oPg7cQuigdRwF
 pFY0gzFF6leNeCu5EA1j0z0C62x0JAJFBWJjNW0G83T1t2FdFvdOnFeb4KXHaR+HM9fW5qE1
X-Proofpoint-ORIG-GUID: ES5ST5n3tkdVQkhjd27yAL3iJS4bjEER
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40
 definitions=2025-06-12_10,2025-06-12_02,2025-03-28_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0
 priorityscore=1501 impostorscore=0 suspectscore=0 adultscore=0
 clxscore=1015 phishscore=0 bulkscore=0 malwarescore=0 mlxlogscore=654
 mlxscore=0 lowpriorityscore=0 classifier=spam authscore=0 authtc=n/a
 authcc= route=outbound adjust=0 reason=mlx scancount=1
 engine=8.19.0-2505280000 definitions=main-2506120132

Commit b9ef323ea168 ("powerpc/64s: Disable preemption in hash lazy
mmu mode") is not necessary anymore, since the lazy MMU mode is
entered with a spinlock held and powerpc does not support Real-Time.
Thus, upon entering the lazy mode the preemption is already disabled.

Signed-off-by: Alexander Gordeev 
---
 arch/powerpc/include/asm/book3s/64/tlbflush-hash.h | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h b/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
index 146287d9580f..aeac22b576c8 100644
--- a/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
+++ b/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
@@ -30,13 +30,9 @@ static inline void arch_enter_lazy_mmu_mode(void)
 {
 	struct ppc64_tlb_batch *batch;
 
+	VM_WARN_ON_ONCE(preemptible());
 	if (radix_enabled())
 		return;
-	/*
-	 * apply_to_page_range can call us this preempt enabled when
-	 * operating on kernel page tables.
-	 */
-	preempt_disable();
 	batch = this_cpu_ptr(&ppc64_tlb_batch);
 	batch->active = 1;
 }
@@ -45,6 +41,7 @@ static inline void arch_leave_lazy_mmu_mode(void)
 {
 	struct ppc64_tlb_batch *batch;
 
+	VM_WARN_ON_ONCE(preemptible());
 	if (radix_enabled())
 		return;
 	batch = this_cpu_ptr(&ppc64_tlb_batch);
@@ -52,10 +49,12 @@ static inline void arch_leave_lazy_mmu_mode(void)
 	if (batch->index)
 		__flush_tlb_pending(batch);
 	batch->active = 0;
-	preempt_enable();
 }
 
-#define arch_flush_lazy_mmu_mode()      do {} while (0)
+static inline void arch_flush_lazy_mmu_mode(void)
+{
+	VM_WARN_ON_ONCE(preemptible());
+}
 
 extern void hash__tlbiel_all(unsigned int action);
 
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Thu Jun 12 17:36:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 17:36:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013364.1391876 (Exim 4.92)
	(envelope-from )
	id 1uPlqv-0000na-MU; Thu, 12 Jun 2025 17:36:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013364.1391876; Thu, 12 Jun 2025 17:36:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPlqv-0000mq-Hw; Thu, 12 Jun 2025 17:36:37 +0000
Received: by outflank-mailman (input) for mailman id 1013364;
 Thu, 12 Jun 2025 17:36: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 1uPlqu-000083-5E
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 17:36:36 +0000
Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com
 [148.163.156.1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c80b2ae2-47b3-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 19:36:34 +0200 (CEST)
Received: from pps.filterd (m0353729.ppops.net [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 55CCjL9N021397;
 Thu, 12 Jun 2025 17:36:18 GMT
Received: from pps.reinject (localhost [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 474dv7v8ma-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Thu, 12 Jun 2025 17:36:18 +0000 (GMT)
Received: from m0353729.ppops.net (m0353729.ppops.net [127.0.0.1])
 by pps.reinject (8.18.0.8/8.18.0.8) with ESMTP id 55CHS242001227;
 Thu, 12 Jun 2025 17:36:17 GMT
Received: from ppma22.wdc07v.mail.ibm.com
 (5c.69.3da9.ip4.static.sl-reverse.com [169.61.105.92])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 474dv7v8m6-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Thu, 12 Jun 2025 17:36:17 +0000 (GMT)
Received: from pps.filterd (ppma22.wdc07v.mail.ibm.com [127.0.0.1])
 by ppma22.wdc07v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 55CE5jqi021839;
 Thu, 12 Jun 2025 17:36:16 GMT
Received: from smtprelay07.fra02v.mail.ibm.com ([9.218.2.229])
 by ppma22.wdc07v.mail.ibm.com (PPS) with ESMTPS id 47505061m6-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Thu, 12 Jun 2025 17:36:16 +0000
Received: from smtpav07.fra02v.mail.ibm.com (smtpav07.fra02v.mail.ibm.com
 [10.20.54.106])
 by smtprelay07.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id
 55CHaEt946072194
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Thu, 12 Jun 2025 17:36:14 GMT
Received: from smtpav07.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 4C36F20043;
 Thu, 12 Jun 2025 17:36:14 +0000 (GMT)
Received: from smtpav07.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 3887420040;
 Thu, 12 Jun 2025 17:36:14 +0000 (GMT)
Received: from tuxmaker.boeblingen.de.ibm.com (unknown [9.152.85.9])
 by smtpav07.fra02v.mail.ibm.com (Postfix) with ESMTPS;
 Thu, 12 Jun 2025 17:36:14 +0000 (GMT)
Received: by tuxmaker.boeblingen.de.ibm.com (Postfix, from userid 55669)
 id A94ADE19DB; Thu, 12 Jun 2025 19:36:13 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c80b2ae2-47b3-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc
	:content-transfer-encoding:date:from:in-reply-to:message-id
	:mime-version:references:subject:to; s=pp1; bh=weooV9zJodYcbtNTa
	8+KZfA3fL5XKJwaSF2bq6quK9Y=; b=LSN9nTMcDnJIjCX8Bg00mrd05eT7hUuHF
	uuKWNUc6sZR4AMlWU7xhYoVouX1sOoYyy6PIWthmqDdNebOXQZ7B41+bNf6vlaYH
	kkZ9bo4u+cH8+LVq9514oaCRyYHVL3VX37G3J0MqL6bBW+HGsyoy6GcAyDwrNH7Y
	FHGNjuCGPCXoPxoeibvgpcrGVyOu6+gwMO3RZhdYa505EA7IhjOphEFvmjoWTlxF
	JuxiwH51mVpt3qrC3vANlOIGYgYjcGaqpg2tN/eUvq0QNMuQXODNnqQI+bRZkOXJ
	VjrIfiMKNWZyely7vz79FXHdVa4C2/7aycYSQQKthFaESJC+He5Eg==
From: Alexander Gordeev 
To: Andrew Morton 
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
        sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org,
        linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org,
        Hugh Dickins , Nicholas Piggin ,
        Guenter Roeck , Juergen Gross ,
        Jeremy Fitzhardinge ,
        Ryan Roberts 
Subject: [PATCH 6/6] powerpc/64s: Do not re-activate batched TLB flush
Date: Thu, 12 Jun 2025 19:36:13 +0200
Message-ID: <8625a1d97dcf4ae499b4bb341e27346f768a7248.1749747752.git.agordeev@linux.ibm.com>
X-Mailer: git-send-email 2.48.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-TM-AS-GCONF: 00
X-Proofpoint-ORIG-GUID: vQTY3M8ZzSt0cV8-T9uSmi-uBIYEQ6jo
X-Proofpoint-GUID: ilIcPrMxf5Pvcy-DGizNo5pQfOED9ogK
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjEyMDEzMiBTYWx0ZWRfX4hJe95qNcCfd ZiGA4V6bFSTahSxOdWra2ve+MTIch6VbUpSLy9/ie7s8Ie297H4KM++vXLqMaovxILSX/VEH7Wd kL8MyHFoqx96u5mOCGyBdQBufIfHdynh/CGelm35zApCFLN5oxqqgVJ1arMbCxOEKkamxhCcQye
 T4p0jaYnpDgiPAOCiq39P+LTkqDP2vbt+LMS1z2CvkzZGQexAIAmpDiNPfHVf+G1uXLcXOE6U5i OsZ7V6mTRdR0DBm/QtbuD0iTOQBU5jFIaSMQMFqtSBv6tG54QRa2g6Dp1oUK3GV/GQFz/SGEskt ZXn/w51Xb8tzMBLP0YYYHDaeDFEkaV4fsqRoFnw2dboBfFVZA1+J+xjRcI4OfWbgbBcpVESfnm6
 /7oQbflnv5Pj4LYSf4VrIQyml0ZufqpOCdiLtdZRi1M7LkYKIRyWGlH1NBkJIEu9ljeGJpAm
X-Authority-Analysis: v=2.4 cv=CfMI5Krl c=1 sm=1 tr=0 ts=684b1012 cx=c_pps a=5BHTudwdYE3Te8bg5FgnPg==:117 a=5BHTudwdYE3Te8bg5FgnPg==:17 a=6IFa9wvqVegA:10 a=VnNF1IyMAAAA:8 a=OhCMzGPqdLFamtb4m9QA:9
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40
 definitions=2025-06-12_10,2025-06-12_02,2025-03-28_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 spamscore=0
 phishscore=0 priorityscore=1501 clxscore=1015 impostorscore=0 mlxscore=0
 suspectscore=0 mlxlogscore=477 adultscore=0 malwarescore=0
 lowpriorityscore=0 classifier=spam authscore=0 authtc=n/a authcc=
 route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2505280000
 definitions=main-2506120132

Since commit b9ef323ea168 ("powerpc/64s: Disable preemption in hash
lazy mmu mode") a task can not be preempted while in lazy MMU mode.
Therefore, the batch re-activation code is never called, so remove it.

Signed-off-by: Alexander Gordeev 
---
 arch/powerpc/include/asm/thread_info.h |  2 --
 arch/powerpc/kernel/process.c          | 25 -------------------------
 2 files changed, 27 deletions(-)

diff --git a/arch/powerpc/include/asm/thread_info.h b/arch/powerpc/include/asm/thread_info.h
index 2785c7462ebf..092118a68862 100644
--- a/arch/powerpc/include/asm/thread_info.h
+++ b/arch/powerpc/include/asm/thread_info.h
@@ -154,12 +154,10 @@ void arch_setup_new_exec(void);
 /* Don't move TLF_NAPPING without adjusting the code in entry_32.S */
 #define TLF_NAPPING		0	/* idle thread enabled NAP mode */
 #define TLF_SLEEPING		1	/* suspend code enabled SLEEP mode */
-#define TLF_LAZY_MMU		3	/* tlb_batch is active */
 #define TLF_RUNLATCH		4	/* Is the runlatch enabled? */
 
 #define _TLF_NAPPING		(1 << TLF_NAPPING)
 #define _TLF_SLEEPING		(1 << TLF_SLEEPING)
-#define _TLF_LAZY_MMU		(1 << TLF_LAZY_MMU)
 #define _TLF_RUNLATCH		(1 << TLF_RUNLATCH)
 
 #ifndef __ASSEMBLY__
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 855e09886503..edb59a447149 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1281,9 +1281,6 @@ struct task_struct *__switch_to(struct task_struct *prev,
 {
 	struct thread_struct *new_thread, *old_thread;
 	struct task_struct *last;
-#ifdef CONFIG_PPC_64S_HASH_MMU
-	struct ppc64_tlb_batch *batch;
-#endif
 
 	new_thread = &new->thread;
 	old_thread = ¤t->thread;
@@ -1291,14 +1288,6 @@ struct task_struct *__switch_to(struct task_struct *prev,
 	WARN_ON(!irqs_disabled());
 
 #ifdef CONFIG_PPC_64S_HASH_MMU
-	batch = this_cpu_ptr(&ppc64_tlb_batch);
-	if (batch->active) {
-		current_thread_info()->local_flags |= _TLF_LAZY_MMU;
-		if (batch->index)
-			__flush_tlb_pending(batch);
-		batch->active = 0;
-	}
-
 	/*
 	 * On POWER9 the copy-paste buffer can only paste into
 	 * foreign real addresses, so unprivileged processes can not
@@ -1369,20 +1358,6 @@ struct task_struct *__switch_to(struct task_struct *prev,
 	 */
 
 #ifdef CONFIG_PPC_BOOK3S_64
-#ifdef CONFIG_PPC_64S_HASH_MMU
-	/*
-	 * This applies to a process that was context switched while inside
-	 * arch_enter_lazy_mmu_mode(), to re-activate the batch that was
-	 * deactivated above, before _switch(). This will never be the case
-	 * for new tasks.
-	 */
-	if (current_thread_info()->local_flags & _TLF_LAZY_MMU) {
-		current_thread_info()->local_flags &= ~_TLF_LAZY_MMU;
-		batch = this_cpu_ptr(&ppc64_tlb_batch);
-		batch->active = 1;
-	}
-#endif
-
 	/*
 	 * Math facilities are masked out of the child MSR in copy_thread.
 	 * A new task does not need to restore_math because it will
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Thu Jun 12 17:36:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 17:36:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013366.1391906 (Exim 4.92)
	(envelope-from )
	id 1uPlqy-0001Z9-KX; Thu, 12 Jun 2025 17:36:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013366.1391906; Thu, 12 Jun 2025 17:36:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPlqy-0001Yw-GN; Thu, 12 Jun 2025 17:36:40 +0000
Received: by outflank-mailman (input) for mailman id 1013366;
 Thu, 12 Jun 2025 17:36: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 1uPlqx-000083-5I
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 17:36:39 +0000
Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com
 [148.163.156.1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c7eaf474-47b3-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 19:36:34 +0200 (CEST)
Received: from pps.filterd (m0356517.ppops.net [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 55CF7v0W022393;
 Thu, 12 Jun 2025 17:36:18 GMT
Received: from pps.reinject (localhost [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4769x01288-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Thu, 12 Jun 2025 17:36:17 +0000 (GMT)
Received: from m0356517.ppops.net (m0356517.ppops.net [127.0.0.1])
 by pps.reinject (8.18.0.8/8.18.0.8) with ESMTP id 55CHWVMp030657;
 Thu, 12 Jun 2025 17:36:17 GMT
Received: from ppma21.wdc07v.mail.ibm.com
 (5b.69.3da9.ip4.static.sl-reverse.com [169.61.105.91])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4769x01286-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Thu, 12 Jun 2025 17:36:17 +0000 (GMT)
Received: from pps.filterd (ppma21.wdc07v.mail.ibm.com [127.0.0.1])
 by ppma21.wdc07v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 55CE2lWa014912;
 Thu, 12 Jun 2025 17:36:16 GMT
Received: from smtprelay06.fra02v.mail.ibm.com ([9.218.2.230])
 by ppma21.wdc07v.mail.ibm.com (PPS) with ESMTPS id 4750rpdxe5-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Thu, 12 Jun 2025 17:36:16 +0000
Received: from smtpav02.fra02v.mail.ibm.com (smtpav02.fra02v.mail.ibm.com
 [10.20.54.101])
 by smtprelay06.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id
 55CHaEqc33358430
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Thu, 12 Jun 2025 17:36:14 GMT
Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 0C91920043;
 Thu, 12 Jun 2025 17:36:14 +0000 (GMT)
Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id EC12E20040;
 Thu, 12 Jun 2025 17:36:13 +0000 (GMT)
Received: from tuxmaker.boeblingen.de.ibm.com (unknown [9.152.85.9])
 by smtpav02.fra02v.mail.ibm.com (Postfix) with ESMTPS;
 Thu, 12 Jun 2025 17:36:13 +0000 (GMT)
Received: by tuxmaker.boeblingen.de.ibm.com (Postfix, from userid 55669)
 id A4B20E19BA; Thu, 12 Jun 2025 19:36:13 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c7eaf474-47b3-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc
	:content-transfer-encoding:date:from:in-reply-to:message-id
	:mime-version:references:subject:to; s=pp1; bh=l+Et7RDVrkrD3xSj+
	ZT9JbsfA8TCXL5kawo+d542qxg=; b=CGSHKJxpAeqSz5W/a/AkSHYJFZv8lW+nh
	uxHC7vWPjJm4OsnwR6v4hz9f8/GcPwgLyA3qutjEahhsvj2zIAXR15Q620+T14It
	FHaWO/C+YYyqkGfyKNLYoZRGLnqRlAVl5LmSlHByDnbjBGpbKCvRtLprRYaEd7oh
	5J9ogX1eJllyxwgYyjA/mR4IpcpPyUjA36BA3prpqLL3/+jvrBlrXfiW9iVZJm+I
	zDSfTi4nXZF1qPYg3iaKGABx6nExrmBcci8O63LJ77BZRUe9YeZEYxl2gkpYGfKS
	I6Y6vUvsUHq1Oogn+ejN/LQkS369JvfdVqa5J6qY7W5de0VsVHpPw==
From: Alexander Gordeev 
To: Andrew Morton 
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
        sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org,
        linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org,
        Hugh Dickins , Nicholas Piggin ,
        Guenter Roeck , Juergen Gross ,
        Jeremy Fitzhardinge ,
        Ryan Roberts 
Subject: [PATCH 4/6] sparc/mm: Do not disable preemption in lazy MMU mode
Date: Thu, 12 Jun 2025 19:36:11 +0200
Message-ID: 
X-Mailer: git-send-email 2.48.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-TM-AS-GCONF: 00
X-Proofpoint-ORIG-GUID: 5A073cfWFciuN2b1brPTe_Vnj2ABgNor
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjEyMDEzMiBTYWx0ZWRfX3cw7ceB7JmZU d6VxfkA70ad39bsJhjQOMACDU7dhR+379Mps/nEMF5/Xm61VZKQveRqbfzXh/DVjMZ0MwShjckH OtM5ElN6pHeKhDxIDWUCD/pMglKXSvoq8imTovo//BpZ6RwUVH9+vjpOGhCFRVt8y8A/4Bl3ZF+
 v6CF8HwtyU4JDL9lKBw8F0GK0vxxj4t9XvR5rgBIuku+iqnJzzsphSBS/GReDoCb+rZTnHKWlnq RPWDwzbp3QorzE155Z++H0jAHLpMAaYFuoXsnenF/bqmgRHT1lUWRW1zbgilJ+Wn6BAjRAxFWe0 pbzA/SYKln6jnYz2VhQume3b18VSQ7InP15yZ+oOnDWlKT3nsaNQ+eIJZzYp3cBxB4kIuXOZQH0
 iVXVtP4unDNnzh/4Kk90d/VKBbvj+DoHFSQSGh/QOa32UKZrgdVGPB3bpZbuiTPpWKB+gRy+
X-Authority-Analysis: v=2.4 cv=YKGfyQGx c=1 sm=1 tr=0 ts=684b1012 cx=c_pps a=GFwsV6G8L6GxiO2Y/PsHdQ==:117 a=GFwsV6G8L6GxiO2Y/PsHdQ==:17 a=6IFa9wvqVegA:10 a=VnNF1IyMAAAA:8 a=Nsn6zn2YLSyj-wdhBosA:9
X-Proofpoint-GUID: El7oGGFj-H4_3nAMfB3G6kQ4auHJ7oeL
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40
 definitions=2025-06-12_10,2025-06-12_02,2025-03-28_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 clxscore=1015
 malwarescore=0 bulkscore=0 priorityscore=1501 phishscore=0 mlxscore=0
 lowpriorityscore=0 impostorscore=0 adultscore=0 mlxlogscore=711
 suspectscore=0 classifier=spam authscore=0 authtc=n/a authcc=
 route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2505280000
 definitions=main-2506120132

Commit a1d416bf9faf ("sparc/mm: disable preemption in lazy mmu mode")
is not necessary anymore, since the lazy MMU mode is entered with a
spinlock held and sparc does not support Real-Time. Thus, upon entering
the lazy mode the preemption is already disabled.

Signed-off-by: Alexander Gordeev 
---
 arch/sparc/include/asm/tlbflush_64.h |  2 +-
 arch/sparc/mm/tlb.c                  | 12 ++++++++----
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/arch/sparc/include/asm/tlbflush_64.h b/arch/sparc/include/asm/tlbflush_64.h
index 8b8cdaa69272..a6d8068fb211 100644
--- a/arch/sparc/include/asm/tlbflush_64.h
+++ b/arch/sparc/include/asm/tlbflush_64.h
@@ -44,7 +44,7 @@ void flush_tlb_kernel_range(unsigned long start, unsigned long end);
 void flush_tlb_pending(void);
 void arch_enter_lazy_mmu_mode(void);
 void arch_leave_lazy_mmu_mode(void);
-#define arch_flush_lazy_mmu_mode()      do {} while (0)
+void arch_flush_lazy_mmu_mode(void);
 
 /* Local cpu only.  */
 void __flush_tlb_all(void);
diff --git a/arch/sparc/mm/tlb.c b/arch/sparc/mm/tlb.c
index a35ddcca5e76..e46dfd5f2583 100644
--- a/arch/sparc/mm/tlb.c
+++ b/arch/sparc/mm/tlb.c
@@ -52,10 +52,9 @@ void flush_tlb_pending(void)
 
 void arch_enter_lazy_mmu_mode(void)
 {
-	struct tlb_batch *tb;
+	struct tlb_batch *tb = this_cpu_ptr(&tlb_batch);
 
-	preempt_disable();
-	tb = this_cpu_ptr(&tlb_batch);
+	VM_WARN_ON_ONCE(preemptible());
 	tb->active = 1;
 }
 
@@ -63,10 +62,15 @@ void arch_leave_lazy_mmu_mode(void)
 {
 	struct tlb_batch *tb = this_cpu_ptr(&tlb_batch);
 
+	VM_WARN_ON_ONCE(preemptible());
 	if (tb->tlb_nr)
 		flush_tlb_pending();
 	tb->active = 0;
-	preempt_enable();
+}
+
+void arch_flush_lazy_mmu_mode(void)
+{
+	VM_WARN_ON_ONCE(preemptible());
 }
 
 static void tlb_batch_add_one(struct mm_struct *mm, unsigned long vaddr,
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Thu Jun 12 19:04:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 19:04:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013516.1391931 (Exim 4.92)
	(envelope-from )
	id 1uPnDn-0005a4-38; Thu, 12 Jun 2025 19:04:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013516.1391931; Thu, 12 Jun 2025 19:04:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPnDm-0005Zx-WF; Thu, 12 Jun 2025 19:04:19 +0000
Received: by outflank-mailman (input) for mailman id 1013516;
 Thu, 12 Jun 2025 19:04: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 1uPnDm-0005Zq-M7
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 19:04:18 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 095a7d3c-47c0-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 21:04:17 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id D085A6116E;
 Thu, 12 Jun 2025 19:04:15 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9CDC4C4CEEA;
 Thu, 12 Jun 2025 19:04: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: 095a7d3c-47c0-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749755055;
	bh=6D6BxuzqFc6289gWzxr9MD9k6SduwODZ6NYAWgJEVvE=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=TVg3k6+1fIFCDCqzj07OpTxgI7rzCORKFJbnqm8GeR9/Oss7I+h/K8zjYgLY7WVC2
	 w1+q2edN6g8e8Croaj+1DDwH6LAQMtjnSMyvSJZQSZsUuTEvp0KAXFESX8PacCrgJs
	 aM3hbncXgquVHDukx3NmSg6cOb/FLcRQHUlhHwyvNG0pHb532yUDsKwlX0RWY/oQZ3
	 Ov6H5FMMYGTeK/p+HkjAExQ3JC4gemnACMbtpztskO8CiI5c/QKFz9RrAEpIYHWD2y
	 ISKKCAodFRejkVVX257Qga1XEswstCcv2G8CP5fuaoGIjydsqYgaxXwTvC2YTs8QDZ
	 b/EskwBtyvQrA==
Date: Thu, 12 Jun 2025 12:03:47 -0700
From: Eric Biggers 
To: Zhenghan Cheng 
Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
	dave.hansen@linux.intel.com, x86@kernel.org,
	mario.limonciello@amd.com, yazen.ghannam@amd.com,
	jpoimboe@kernel.org, tony.luck@intel.com, jarkko@kernel.org,
	bhelgaas@google.com, pbonzini@redhat.com, oleg@redhat.com,
	jbaron@akamai.com, ning.sun@intel.com, seanjc@google.com,
	luto@kernel.org, andy@kernel.org, jim.cromie@gmail.com,
	kirill.shutemov@linux.intel.com, hpa@zytor.com,
	pawan.kumar.gupta@linux.intel.com, vkuznets@redhat.com,
	rostedt@goodmis.org, ardb@kernel.org, thomas.lendacky@amd.com,
	nikunj@amd.com, ashish.kalra@amd.com, kees@kernel.org,
	alexandre.chartre@oracle.com, rppt@kernel.org, steve.wahl@hpe.com,
	jirislaby@kernel.org, apatel@ventanamicro.com, bvanassche@acm.org,
	ptsm@linux.microsoft.com, Jonathan.Cameron@huawei.com,
	beata.michalska@arm.com, xin@zytor.com, davydov-max@yandex-team.ru,
	ravi.bangoria@amd.com, joel.granados@kernel.org,
	ffmancera@riseup.net, kprateek.nayak@amd.com,
	akpm@linux-foundation.org, bhe@redhat.com, brgerst@gmail.com,
	coxu@redhat.com, dmaluka@chromium.org, linux-kernel@vger.kernel.org,
	linux-edac@vger.kernel.org, linux-sgx@vger.kernel.org,
	kvm@vger.kernel.org, virtualization@lists.linux.dev,
	tboot-devel@lists.sourceforge.net, nouveau@lists.freedesktop.org,
	linux-coco@lists.linux.dev, xen-devel@lists.xenproject.org,
	Huacai Chen ,
	Zhenghan Cheng 
Subject: Re: [PATCH] x86: Fix build warnings about export.h
Message-ID: <20250612190347.GB1283@sol>
References: <20250612093228.7655-1-chengzhenghan@uniontech.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250612093228.7655-1-chengzhenghan@uniontech.com>

On Thu, Jun 12, 2025 at 05:32:28PM +0800, Zhenghan Cheng wrote:
> After commit a934a57a42f64a4 ("scripts/misc-check:
> check missing #include  when W=1")
> and commit 7d95680d64ac8e836c ("scripts/misc-check:
> check unnecessary #include  when W=1"),
> we get some build warnings with W=1,such as:
> 
> arch/x86/coco/sev/core.c: warning: EXPORT_SYMBOL() is used, but #include  is missing
> arch/x86/crypto/aria_aesni_avx2_glue.c: warning: EXPORT_SYMBOL() is used, but #include  is missing
> arch/x86/kernel/unwind_orc.c: warning: EXPORT_SYMBOL() is used, but #include  is missing
> arch/x86/kvm/hyperv.c: warning: EXPORT_SYMBOL() is used, but #include  is missing
> arch/x86/events/intel/core.c: warning: EXPORT_SYMBOL() is not used, but #include  is present
> arch/x86/events/zhaoxin/core.c: warning: EXPORT_SYMBOL() is not used, but #include  is present
> arch/x86/kernel/crash.c: warning: EXPORT_SYMBOL() is not used, but #include  is present
> arch/x86/kernel/devicetree.c: warning: EXPORT_SYMBOL() is not used, but #include  is present
> 
> so fix these build warnings for x86.
> 
> Signed-off-by: "Zhenghan Cheng" 
> Suggested-by: "Huacai Chen" 

FYI, I'm planning to handle arch/x86/lib/crc*.c and arch/x86/lib/crypto/.

(Specifically, I'm migrating them to lib/crc/ and lib/crypto/ respectively, and
one of the effects of that is the EXPORT_SYMBOL in arch-specific crc and crypto
library files go away.  The lib/crc/ change is already in linux-next, and
https://lore.kernel.org/r/20250612183852.114878-1-ebiggers@kernel.org adds
 to all files with EXPORT_SYMBOL in lib/crc/.)

- Eric


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 20:29:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 20:29:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013552.1391945 (Exim 4.92)
	(envelope-from )
	id 1uPoY9-0002bN-Oq; Thu, 12 Jun 2025 20:29:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013552.1391945; Thu, 12 Jun 2025 20:29: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 1uPoY9-0002bG-Ll; Thu, 12 Jun 2025 20:29:25 +0000
Received: by outflank-mailman (input) for mailman id 1013552;
 Thu, 12 Jun 2025 20:29: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 1uPoY7-0002Z5-NT
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 20:29:23 +0000
Received: from fhigh-a8-smtp.messagingengine.com
 (fhigh-a8-smtp.messagingengine.com [103.168.172.159])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ebc10ea1-47cb-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 22:29:21 +0200 (CEST)
Received: from phl-compute-12.internal (phl-compute-12.phl.internal
 [10.202.2.52])
 by mailfhigh.phl.internal (Postfix) with ESMTP id 3D058114023C;
 Thu, 12 Jun 2025 16:29:20 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-12.internal (MEProxy); Thu, 12 Jun 2025 16:29:20 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 12 Jun 2025 16:29:15 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ebc10ea1-47cb-11f0-b894-0df219b8e170
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=1749760160;
	 x=1749846560; bh=nTRp4plZtids7Yw2Omf8/NwrGln5GzTJtS9oOKTYnvM=; b=
	dRLQ45XkQ8F/xojIkHMWzrUs1t7Hg9F90yPcJGFpdwM2kcW9XpxtbreaFOB7icOw
	awWyA1Z2WjYeIGE/jaxfwBufNu/Nit76MtWSPHk4Xn1t+0HDcKsYtjjdyxxQr0rW
	KupB/DqJxPF9lvY3tTlwIDQEQFB2DIVKmFTg8KzmsU4uhq3PxtJfVQF/5AUzduE8
	dtu7CoxYyu6FjYOXAmGRm2HuHcTboATZBEcVJ8S117qAyS0hSyLkBrP2Gkz5wYHl
	19mhvV1jv5HT8yKHs6WEZPhQkSaVJ8HS5L+00D+E5SjER/ILeXNn9SZiyn2XwLkq
	CI//nw7mRvBJ1ySp0o+fPA==
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=
	1749760160; x=1749846560; bh=nTRp4plZtids7Yw2Omf8/NwrGln5GzTJtS9
	oOKTYnvM=; b=oiO+cABIwgI8PSHyrm4cQ69fITRBUIoQjyK4s+OiFeDZ4sAcKyy
	apcHxUPOTlm5Eq/H/VGx2Q9GV1EQU/1d3TrDB7iADVuHffOf/0yhNOmrg9YV9luV
	9jfhgoXIk/0Sw+YdGCSmhI+0kEYT9OG7zwDRg9I14PRmDSZymn0m5u12SUXYEQ+G
	5GaBjNhZOo2z+t6Vb3pGMB0bXURX0T9PTcNIYjwDlVRGJESncMjgv7qMGgbXO8VL
	L2UCZlRsZMz/Lw+077S/NocUuNYfTSD8UFCfdTJ//oZQue1datFj9hlV2OtOUESw
	pIzqmuj5C+U6PEybiaPeZG5KkwY7yz4aJoA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugdduiedtfecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp
    uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg
    hnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehgtderredttdej
    necuhfhrohhmpeforghrvghkucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoe
    hmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucgg
    tffrrghtthgvrhhnpefgudelteefvefhfeehieetleeihfejhfeludevteetkeevtedtvd
    egueetfeejudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr
    ohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpd
    hnsggprhgtphhtthhopeduhedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepuggv
    mhhiohgsvghnohhurhesghhmrghilhdrtghomhdprhgtphhtthhopehjsggvuhhlihgthh
    esshhushgvrdgtohhmpdhrtghpthhtoheprghnughrvgifrdgtohhophgvrhefsegtihht
    rhhigidrtghomhdprhgtphhtthhopegrnhhthhhonhihrdhpvghrrghrugesvhgrthgvsh
    drthgvtghhpdhrtghpthhtohepmhhitghhrghlrdhorhiivghlsegrmhgurdgtohhmpdhr
    tghpthhtohepjhhulhhivghnseigvghnrdhorhhgpdhrtghpthhtoheprhhoghgvrhdrph
    gruhestghithhrihigrdgtohhmpdhrtghpthhtohepshhsthgrsggvlhhlihhniheskhgv
    rhhnvghlrdhorhhgpdhrtghpthhtohepjhhgrhhoshhssehsuhhsvgdrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Thu, 12 Jun 2025 22:29:12 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Demi Marie Obenour 
Cc: Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Stefano Stabellini ,
	Juergen Gross , Trammell Hudson ,
	Ross Lagerwall ,
	Frediano Ziglio ,
	Gerald Elder-Vass ,
	Kevin Lampis ,
	Xen-devel 
Subject: Re: [PATCH] docs: UEFI Secure Boot security policy
Message-ID: 
References: <20250611235851.167385-1-andrew.cooper3@citrix.com>
 <5aad2d39-31e1-44c6-b167-a3275dc6b747@suse.com>
 <842eb63e-cd20-4c0f-9f25-9d9c2a5457b1@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="9oYUqGuFLUmhVa6l"
Content-Disposition: inline
In-Reply-To: <842eb63e-cd20-4c0f-9f25-9d9c2a5457b1@gmail.com>


--9oYUqGuFLUmhVa6l
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 12 Jun 2025 22:29:12 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Demi Marie Obenour 
Cc: Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Stefano Stabellini ,
	Juergen Gross , Trammell Hudson ,
	Ross Lagerwall ,
	Frediano Ziglio ,
	Gerald Elder-Vass ,
	Kevin Lampis ,
	Xen-devel 
Subject: Re: [PATCH] docs: UEFI Secure Boot security policy

On Thu, Jun 12, 2025 at 11:22:39AM -0400, Demi Marie Obenour wrote:
> On 6/12/25 06:06, Jan Beulich wrote:
> > On 12.06.2025 01:58, Andrew Cooper wrote:
> >> 2) Pre-boot DMA Protection.  Microsoft consider this a platform feature
> >> requiring OEM enablement, and do not consider its absence to be a Secu=
re Boot
> >> vulnerability.  But, it is less clear what the policy ought to be for =
Xen
> >> booting on a capable system and failing to do a correct live-handover =
of the
> >> IOMMU across ExitBootServices().
> >=20
> > Shouldn't this be another TODO item at the bottom? We don't support yet=
 taking
> > over when the IOMMUs are already enabled, do we?
>=20
> Dasharo supports leaving the IOMMU enabled when transferring to the OS, a=
nd
> this message was sent from a Qubes OS box booted in this configuration.

"Not explode" doesn't mean it "works" or is "supported". For example
there is no guarantee that IOMMU don't get disabled in the process
opening a window for an attack. (and I do know this issue is the case)

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

--9oYUqGuFLUmhVa6l
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmhLOJgACgkQ24/THMrX
1yzDCgf+J/CoFuqYOLxNsIko9wNzJ0zrtnB6TWRR8czGW7xfRy9596hLpaYhozRA
PDbQgHUykRtE3D8gB0WWUs4/HGNY2ncftYE7EaB7jm5jhgi9qTfKBRSArc7kO2US
s0vnD4Yl+76fBqd8TmWIW09ZJBOV6WidBd8h7+aIgEIWAgB8LjX1N3k37Y9HOF3h
SwGk90/CxBhW5Y4cO4vT9y8fzJfz29l+BX7Fnjg6nTF+bJpf9G76iSlqrQ/mT1T1
kMB7kS62Oz6n12dbGUpIaruHs9/EgcHhibsKjbE6a6/QRgqTpUMIzNpVDND6eN+F
CcXfie189e2uTsW2ZMLwvIukbNAUiQ==
=pfan
-----END PGP SIGNATURE-----

--9oYUqGuFLUmhVa6l--


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 20:30:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 20:30:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013560.1391954 (Exim 4.92)
	(envelope-from )
	id 1uPoZF-00040y-0e; Thu, 12 Jun 2025 20:30:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013560.1391954; Thu, 12 Jun 2025 20:30: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 1uPoZE-00040r-UL; Thu, 12 Jun 2025 20:30:32 +0000
Received: by outflank-mailman (input) for mailman id 1013560;
 Thu, 12 Jun 2025 20:30: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 1uPoZD-00040j-SH
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 20:30:32 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20626.outbound.protection.outlook.com
 [2a01:111:f403:2415::626])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 13c04a9d-47cc-11f0-b894-0df219b8e170;
 Thu, 12 Jun 2025 22:30:29 +0200 (CEST)
Received: from MN0P222CA0013.NAMP222.PROD.OUTLOOK.COM (2603:10b6:208:531::18)
 by IA1PR12MB6529.namprd12.prod.outlook.com (2603:10b6:208:3a6::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.19; Thu, 12 Jun
 2025 20:30:22 +0000
Received: from BL02EPF0002992C.namprd02.prod.outlook.com
 (2603:10b6:208:531:cafe::ae) by MN0P222CA0013.outlook.office365.com
 (2603:10b6:208:531::18) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.23 via Frontend Transport; Thu,
 12 Jun 2025 20:30:22 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL02EPF0002992C.mail.protection.outlook.com (10.167.249.57) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Thu, 12 Jun 2025 20:30: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, 12 Jun
 2025 15:30:21 -0500
Received: from [172.27.195.250] (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 Jun 2025 15:30:21 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 13c04a9d-47cc-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=U+QsvYCorc1/MC9isUesy19/+9uexLk065goQ29tTW8iIh6pasJITzyer3W2nOsSVdtDD/4F+6tkY3wvIhQnLtRgC59tFMQYmM5NIs8Cpm1AVjpeGAYi0PhCPuyad4pMvBFRNUfQvyZrBKRxi/+SWpDKWiQv7J4TudcAP0dFUoym/Mll/wxlxIBx8edqv9rnW+zKQkAs5Zx1BDA5ZkuOiAg8EtUN5T8FtSCP9HfGK9fMr4lef4xyJnPVRRj9PFeZdSygTrH8gBAhzQdsmBvw/7550VWHXduiZUja0/fr3ShGMCODmC0frE9Ox0ugH18O4Zq5Oct4BLmN3JWZkU4l9A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=wbhSiqFxCJg3UTzzQSjLFfT2DQEtNEKTY6C9eF2ty6g=;
 b=whB3akfdlc3XHVr3rYHiDZcywR+98OrUd/Yz0I+IFDRnDTCteHYJZGZ5sa7YSXBQqKYaLOoxSKSQXVJERQgW4qAePnkfFzMhlKVxVY1wOqY2JKtMsxUazWrowimKNp2uocUvpqIF1WzAZNTYrM956XWvJ3iPEVZ/OIjKGscUPV8jxrPEKMaRkMq1Nduo9g7V6WXqfQM69jAdLZ/YSmBu40oh8VNfOzICJ7ovH+CG8jMdTqAfPXBg2fDkEIKf2zKhJvcaFPJ9N0byOEKq2Hr3poSTc+vKwIZeJOnrYYRawgL+S9ZhMxUgCNMtm8uDtVszJ+B8dDbvNHxb2smHdjpSxQ==
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=wbhSiqFxCJg3UTzzQSjLFfT2DQEtNEKTY6C9eF2ty6g=;
 b=yyOX/s52mVyBiN5zV6d2SUDbQBjwZ8AO/3fCKmMbXbgJfdAOPirUhURPlds0/9CoY5yADfspxXPgnPfBrFcYtpXoJvO2eqHecdgY+BL58wTumTlqt4cm8EscqbABdfNb2RCa8pkYzxVDs8uc7ve7m7clKT+JU9wUJnpj3mhzCuE=
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, 12 Jun 2025 16:30:17 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/4] xsm/silo: Support hwdom/control domains
From: Jason Andryuk 
To: Jan Beulich 
CC: "Daniel P. Smith" ,
	
References: <20250610225737.469690-1-jason.andryuk@amd.com>
 <20250610225737.469690-3-jason.andryuk@amd.com>
 <0f47268e-0674-46e7-bfd4-8a395ee1ddf6@suse.com>
 <6cc69b45-7347-4250-ab32-a1e2857b7d23@amd.com>
 <805abeee-0cad-4cc9-88ae-77e4c1e23fac@suse.com>
 
Content-Language: en-US
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
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: BL02EPF0002992C:EE_|IA1PR12MB6529:EE_
X-MS-Office365-Filtering-Correlation-Id: 8f7e4d77-b1f5-4c69-337f-08dda9eff4ec
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?TWVaK3Naek9qYm9ZR1BiazJ6RVpmUVdPcUdoMGp2WUxOVzBmaW45bFFuSFhN?=
 =?utf-8?B?K2p6WGY3dy9aa29ZSXVGQUV3SzVCNExsRDZqRDRaNndKUlptRXJiMTU3SVNz?=
 =?utf-8?B?MTAvOUpvTjFhZEczSXowNktObExxZU9XczFEMVEvVjk0dCtDdkpicWVWS2tI?=
 =?utf-8?B?dW11ZitPbzR3eUppU0JUSmxRRVoxd3QxdE1VVjFvNEorTE9WQjdiYVdnWHcy?=
 =?utf-8?B?VkZLSW5tdVQ5ME9OR0h3K3lOZnZpZGhpVDhHTEV4UkpJQUYycTNhOGxxdHV4?=
 =?utf-8?B?Zk4vbmRKVDdGbUpFNjQ2Mjk1NkQyaG1pWHJmRm11Y1FUUVVBZnJnUG1XRDNq?=
 =?utf-8?B?WE8ra05JRkZtWUIvM2doNHdTVFhjS1NnYWVsT0MrSHlUekRiOFpadDZJWk0y?=
 =?utf-8?B?aTdLendoN0JBVS9ydkxLOW05OVVoOE1nZERndENrZDRsWmNuc3RRY3RGVHh3?=
 =?utf-8?B?dUpjTWthWEJTbXh1dS9ReXloK0NsT0hHS2h5MjBGd1E1YVRlYnlXTldiZWRC?=
 =?utf-8?B?NjhIc3g0enpnRUlKdEVaUG5wbW9TUm5aZ1U2TkVsOE4wa2g4UjFUY1NmUWZO?=
 =?utf-8?B?VTdyUWhjWXBLWHNTOG54K1hDTS9IOEdzai9Cb0RyL0k4TzdUQ0ZtUWRsUDhI?=
 =?utf-8?B?V2RJaytJOUFJZVdrTCtkS0VZbllnVmh4Ymx4eksxOWJuaXp4UlBYN2FTejBR?=
 =?utf-8?B?RjhnekpsRVNhbGJuNEtFdHcrelF5RGV3bTluOEJyWUJMaXp1VWJhRStiZzFx?=
 =?utf-8?B?d24wSW5NdUtIZGpXRVpZL0N1Nnp3eTVuUDRpaXkydjFibU44bVZjc2UxODdi?=
 =?utf-8?B?NllHYjRIOElhUnM0azF0YUFrTGJGT2tocS9mRW5HQ3VubFNRS2VLLzJuRlVH?=
 =?utf-8?B?dVh3Q0xxYy8vRURVYTlSL2lncDRaOGhWc3Uxcm5mZ1pIdDA3Ym9jK0JmeCs2?=
 =?utf-8?B?UVZQY3A2S0pJQXNSWGhzWmFkMUhRNnFoVEJOZUtYdnlVbytSOXBweklURUg3?=
 =?utf-8?B?VmphNm5TS3NBM0FKRmdsVGdJdEVSZDIwTjVpVE51cmVJYVhkdmFMcVF0ZjdL?=
 =?utf-8?B?aDVBaUpxc1dBMVlXQ3h6dzk5U01EMW91eW5ndVZQT1JqYzIrbTJjUEh4V3Yz?=
 =?utf-8?B?YTZjNnllWUl6eGp2aVJqZldDMlIwUHR5VWxIOGJzVGxqUTBOZG12TFMyUURs?=
 =?utf-8?B?NWZCb3piU2tKR2xINEIxR01iZnlxM09mc2RmTXNUM0hERURPRktQSWlGblJt?=
 =?utf-8?B?dWJqMnZmMUFqQzcxTHZHN1FzVUZXNjR0d0xQWkpvRVl1R1pmY0J3Z2psalR2?=
 =?utf-8?B?TFJnWVljTS96K1IxTWdTZ0NyZlh6TWM4cGRSc2lROVpJUG1WcXppNHRGdndW?=
 =?utf-8?B?cmhicGtpY3E0cE9pbkNjeUhNc1hLa2lBaVBqb1FjY1pBekhQMVhxUmliNWhi?=
 =?utf-8?B?TlhiZUNtcHZtSjhzMmdZSFJPMGw0MU9xaGtLZTRMTmZSNEZIMXFSUWVEL3Bn?=
 =?utf-8?B?MmlPQ2dLR0taMm9MRWtRZ0Jobkg5MTdyNUhHK2tpanczamRkNXFFZ2hzemw4?=
 =?utf-8?B?YmNjVCtnRU94OFQ0QVB6dXZDckRGckRVY0NVS21FMkhlZktBa2FMWm5nZHAw?=
 =?utf-8?B?dytadWpxQm9qQ0tIVURjOHhGR1YwRmQ3STJoNWhORVN4MVgyaEwzZWtwd1VT?=
 =?utf-8?B?REx0elhyODhmalRGTmowV1RqWllkSmJSTmxheC90b0JjWTZTSFJDL3dkOWxn?=
 =?utf-8?B?NEYyL0JQMGZSZk1XaDF2ZEdCQTA0M3dBRGFVd1hZamx5bm9TVFBQRXNMT0hD?=
 =?utf-8?B?RWFWa1I0Mityb3BDZlhhV2VyNTBSZUQwYmRPdXpwWWxYMDJyNEhHVVI0Sk4w?=
 =?utf-8?B?VXR1NlVYOUpLaEc5NkM3V1YyK1NMWFV1dWNncmJwVkVDcVdqTzkzRXZ6OHNX?=
 =?utf-8?B?Y2xKdkRYNjhZS3pEMGMzcmZlcHl3bkRabTFWNGFvQW5IMWhqSzNPdEc5WVBi?=
 =?utf-8?B?dnh6bDcrZk83em8wdjRkSitXdjVwOGlYK2FQSEt0SG41SDY1Z3BmVEpGRVdY?=
 =?utf-8?Q?d0P+gK?=
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: 12 Jun 2025 20:30:22.7450
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 8f7e4d77-b1f5-4c69-337f-08dda9eff4ec
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:
	BL02EPF0002992C.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB6529



On 2025-06-12 12:56, Jason Andryuk wrote:
> On 2025-06-12 03:52, Jan Beulich wrote:
>> On 11.06.2025 06:20, Jason Andryuk wrote:
>>> On 2025-06-11 09:17, Jan Beulich wrote:
>>>> On 11.06.2025 00:57, Jason Andryuk wrote:
>>>>> In a disaggregated environment, dom0 is split into Control, Hardware,
>>>>> and Xenstore domains, along with domUs.  The is_control_domain() check
>>>>> is not sufficient to handle all these cases.  Add is_priv_domain() to
>>>>> support allowing for the various domains.
>>>>>
>>>>> The purpose of SILO mode is to prevent domUs from interacting with 
>>>>> each
>>>>> other.  But dom0 was allowed to communicate with domUs to provide
>>>>> services.  As the disaggregation of dom0, Control, Hardware and 
>>>>> Xenstore
>>>>> are all service domains that need to communicate with other domains.
>>>>>
>>>>> To provide xenstore connections, the Xenstore domain must be 
>>>>> allowed to
>>>>> connect via grants and event channels.  Xenstore domain must also be
>>>>> allowed to connect to Control and Hardware to provide xenstore to 
>>>>> them.
>>>>
>>>> Are you suggesting that SILO at present is incompatible with a Xenstore
>>>> domain? silo_mode_dom_check() in its original form has no special
>>>> precautions, after all.
>>>
>>> Yes, it is incompatible with the current silo_mode_dom_check().  Only
>>> Control domain is allowed to use grants and event channels with a domU.
>>> A Xenstore domain would be denied.
>>>
>>> Xenstore stubdom only exists for x86 today.  My limited attempts to run
>>> xenstored in an dedicated Xenstore ARM Linux domain have failed.
>>
>> This may want sorting independently first. Once sorted, the requirements
>> here may become more clear.
> 
> HW+XS-> xenstore works
> CTL+XS or XS -> the domain's console just stops.  vCPUs are in Linux cpu 
> idle.  I haven't figured out more.  This required some Linux changes to 
> query the capabilities since XS isn't exposed and ARM assumes initial 
> domain implies HW + CTL.  It's orthogonal to my goals, so I haven't 
> looked too hard.

I got standalone Xenstore working on ARM.  Linux was blocking in 
xs_reset_watches() - the Xenstore domain needs to skip that function 
like xen_initial_domain().

This is with SILO's check as:
static bool is_priv_domain(const struct domain *d)
{
     return evaluate_nospec((d->options & XEN_DOMCTL_CDF_xs_domain) ||
                            d == hardware_domain);
}

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 21:32:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 21:32:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013594.1391965 (Exim 4.92)
	(envelope-from )
	id 1uPpX8-0005I1-8l; Thu, 12 Jun 2025 21:32:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013594.1391965; Thu, 12 Jun 2025 21: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 1uPpX8-0005Hu-5s; Thu, 12 Jun 2025 21:32:26 +0000
Received: by outflank-mailman (input) for mailman id 1013594;
 Thu, 12 Jun 2025 21:32: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 1uPpX6-0005Ho-TU
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 21:32:24 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b8b45efd-47d4-11f0-a309-13f23c93f187;
 Thu, 12 Jun 2025 23:32:21 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id AD395629DD;
 Thu, 12 Jun 2025 21:32:19 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 24CD5C4CEEA;
 Thu, 12 Jun 2025 21:32: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: b8b45efd-47d4-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749763939;
	bh=kByoiT9i27+DTvNqzTv5Xwx4LR398i6qsIvDKcvL724=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=DSaP7C1rPdGYTMCdlWrqG3yUs5EGSBJEszr7LC7sbuCprAMQciFfDmfPO5eDl4tcG
	 BSVeyczIN/sL8jPnl24OoQprUIzKvUSMdtQndKfFgxdJ4lvndDD/DxFqnk/kviuqtZ
	 0DPc0TstB9AiQasRyPXBZx6V+QFA40A5uYD9nP6x+7a+tR5Q33NZUVlTsh1noFZPS8
	 8CLw6vGDnPNlsUzv7vUzLsReHQK6XNxnuyNP8kBS1K+fCks7K9JR71G76VjV65/09o
	 o4TwsChsMDD3eXDPCpyO1AumlXIENYHGRssRXmDuNaPAOuV4/p8VPZ1C0upDCC1xBo
	 mL1kwIevMjyVg==
Date: Thu, 12 Jun 2025 14:32:15 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Andrew Cooper 
cc: Xen-devel , 
    Anthony PERARD , 
    Michal Orzel , Jan Beulich , 
    Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini , security@xen.org, 
    Juergen Gross , 
    =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , 
    Trammell Hudson , 
    Ross Lagerwall , 
    Frediano Ziglio , 
    Gerald Elder-Vass , 
    Kevin Lampis 
Subject: Re: [PATCH] docs: UEFI Secure Boot security policy
In-Reply-To: <20250611235851.167385-1-andrew.cooper3@citrix.com>
Message-ID: 
References: <20250611235851.167385-1-andrew.cooper3@citrix.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-788649695-1749763939=:8480"

  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-788649695-1749763939=:8480
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Thu, 12 Jun 2025, Andrew Cooper wrote:
> Written to be solution and deployment neutral in order to focus on the
> technology itself.  This policy is intended to work as well for UKI as for the
> "classic server setup" approach.
> 
> 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: security@xen.org
> CC: Juergen Gross 
> CC: Marek Marczykowski-Górecki 
> CC: Trammell Hudson 
> CC: Ross Lagerwall 
> CC: Frediano Ziglio 
> CC: Gerald Elder-Vass 
> CC: Kevin Lampis 
> 
> A rendered version is available at:
>   https://andrewcoop-xen.readthedocs.io/en/docs-secureboot/admin-guide/uefi-secure-boot.html
> 
> Obviously RFC at this point.  It's worth saying that XenServer is intending to
> use Shim and get a signature from Microsoft, retaining all exiting features
> such as Livepatching and Kexec crash reporting.
> 
> This trails off into more TODOs towards the end.  Individual tasks should
> expand on the start made and resulting conversation from this thread.  As a
> reminder, the target audience for this doc is an administrator running a Xen
> deployment, but who is not necesserily a developer.
> 
> Several things are hard to express and want further discussion.  Suggestions
> welcome:
> 
> 1) Content of CONFIG_CMDLINE and the various CONFIG_*_DEFAULT options.  Xen is
> not going to be issuing XSAs for "downstream chose an unsafe configuration,
> then signed and deployed the result", yet Xen probably should be on the hook
> for bad "default ..." settings in Kconfig.
> 
> 2) Pre-boot DMA Protection.  Microsoft consider this a platform feature
> requiring OEM enablement, and do not consider its absence to be a Secure Boot
> vulnerability.  But, it is less clear what the policy ought to be for Xen
> booting on a capable system and failing to do a correct live-handover of the
> IOMMU across ExitBootServices().
> 
> 3) The AMD microcode signature vulnerability.  While it's not Xen's bug per
> say, it's clearly a Secure Boot bypass because we do offer microcode loading
> capabilties to userspace, and malicious userspace can load an unauthorised
> microcode which allows them to read/write physical memory and bypass further
> signature checks.
> 
> 4) Userspace Hypercalls.  To anyone who isn't already aware, /dev/xen/privcmd
> in the various Unicies is a giant priv-esc hole, as root userspace can
> e.g. issue direct memory hypercalls behind the back of an (intentionally)
> oblivious kernel, and cannot be handwaved away as "it's fine because it's
> root" under Secure Boot.  It's not a Xen vuln (Xen *does* audit pointers in
> guest hypercalls), but it is a guest kernel vuln because of failing to
> correctly audit hypercall parameters.  However, it does require substantial
> changes in Xen in order to allow guest kernels to do something half-way safe.

One small suggestion for improvement is that Secure Boot is not an
x86-specific specification so we should keep the document arch-neutral.


> ---
>  docs/admin-guide/index.rst            |   1 +
>  docs/admin-guide/uefi-secure-boot.rst | 134 ++++++++++++++++++++++++++
>  2 files changed, 135 insertions(+)
>  create mode 100644 docs/admin-guide/uefi-secure-boot.rst
> 
> diff --git a/docs/admin-guide/index.rst b/docs/admin-guide/index.rst
> index 54e6f65de347..e7895ee95001 100644
> --- a/docs/admin-guide/index.rst
> +++ b/docs/admin-guide/index.rst
> @@ -5,4 +5,5 @@ Admin Guide
>  
>  .. toctree::
>     introduction
> +   uefi-secure-boot
>     microcode-loading
> diff --git a/docs/admin-guide/uefi-secure-boot.rst b/docs/admin-guide/uefi-secure-boot.rst
> new file mode 100644
> index 000000000000..0e0f50143892
> --- /dev/null
> +++ b/docs/admin-guide/uefi-secure-boot.rst
> @@ -0,0 +1,134 @@
> +.. SPDX-License-Identifier: CC-BY-4.0
> +
> +UEFI Secure Boot
> +================
> +
> +UEFI Secure Boot is a verification mechanism, intended to ensure that only
> +code trusted by the platform can run.  This is to prevent malicious code from
> +hijacking the system.  Secure Boot requires that all privileged code be
> +signed, and that there is a trust relationship with the platform; i.e. code
> +which is not signed by a key enrolled in platform must not run privileged.
> +
> +Within the Xen architecture, Xen, the :term:`control domain` and
> +:term:`hardware domain` share responsibility for running and administering the
> +platform.  This makes their kernels privileged as far as Secure Boot is
> +concerned.
> +
> +When Secure Boot is active in the platform, privileged code is required to not
> +run any untrusted code (i.e. not run any code for which there is not a good
> +signature), and is required not to allow this restriction to be bypassed
> +(e.g. by command line request).
> +
> +
> +Support in Xen
> +--------------
> +
> +There are multiple ways to achieve this security goal, with differing
> +tradeoffs for the eventual system.
> +
> +On one end of the spectrum is the Unified Kernel Image.  e.g. Xen is bundled
> +with the dom0 kernel and init-ramdisk, with an embedded command line, and with
> +livepatching and kexec compiled out, and suitably signed.  The signature is
> +checked by the bootloader and, as this covers all the privileged code, Xen
> +doesn't need to perform further checks itself.
> +
> +On the other end of the spectrum is maintaining the features of existing
> +deployments.  e.g. Xen needs signature checking capabilities for the dom0
> +kernel, livepatches and kexec kernels, and needs to allow the use of safe
> +command line options while disallowing unsafe ones.

I just wanted to mention that there is one more option which I used in
the past: the firmware/bootloader loads Xen, the Dom0 kernel, and other
binaries, check their signatures, then boot Xen.

This is similar to the "Unified Kernel Image" approach in the sense that
Xen doesn't need to do any signature checking for the dom0 kernel, but
it doesn't require all the binaries to be glued together.

Assuming that the firmware/bootloader is capable of loading multiple
binaries and checking the signature of multiple binaries before booting
the next element, it works fine.



> +It is important to remember that Xen is one piece of the larger platform,
> +where every piece depends on the correct functioning of all earlier pieces.  A
> +product supporting Secure Boot requires a holistic approach involving all
> +components in the system.  It is not sufficient to consider Xen in isolation.
> +
> +.. TODO: Move "In Progress" tasks here as they become ready
> +
> +Security Scope
> +--------------
> +
> +Vulnerabilities impacting Secure Boot require a fixed component to be produced
> +and distributed, the vulnerable component to be revoked, and the revocation
> +distributed to platforms.
> +
> +The following principles and guidelines indicate where Secure Boot differs
> +from more traditional security models, and the situations in which extra
> +remediation may be necessary.
> +
> +Principles
> +^^^^^^^^^^
> +
> + * Privileged code shall include Xen and the kernel(s) of the control and
> +   hardware domain (both, if they're split).  While there is a privilege split
> +   here in Xen's regular security model, they are equal from Secure Boot's
> +   point of view.
> +
> + * Root or ADMIN in userspace is unprivileged from Secure Boot's point of
> +   view, and must not be able to alter the enforcement policy or load unsigned
> +   code even by e.g. editing a configuration file and rebooting.
> +
> +Within Scope
> +^^^^^^^^^^^^
> +
> +The following types of issue require remediation and revocation of vulnerable
> +binaries.
> +
> + * Any failure to apply enforcements even against traditionally-privileged
> +   userspace, including failure to authenticate new code to run and failure to
> +   handle revocations properly.
> +
> + * Any Out-of-Bounds write capable of altering the enforcement policy, or
> +   capable of bypassing enforcement, e.g. by corrupting the running code.
> +
> +Out of Scope
> +^^^^^^^^^^^^
> +
> +While typically a security issue in their own rights, these issues do not
> +constitute a Secure Boot vulnerability, and do not require special
> +remediation.
> +
> + * Denial of Service vulnerabilities.
> +
> + * Out-of-Bounds reads.
> +
> +The Xen Security Team will endeavour to produce XSAs for all violations of
> +this security policy, including identifying them specifically as requiring
> +further remediation by downstreams.
> +
> +
> +In Progress
> +-----------
> +
> +.. warning::
> +
> +   The following work is still in progress.  It is provisional, and not
> +   security supported yet.
> +
> +
> +Secure Boot Advanced Targeting
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +SBAT is a recovation scheme for Secure Boot enabled components, using a
> +generation based scheme.  See `Shim SBAT.md
> +`_ for full details.
> +
> +Upstream Xen provides the infrastructure to embed SBAT metadata in
> +``xen.efi``, but does not maintain a generation number itself.  Downstreams
> +are expected to maintain their own generation numbers.
> +
> +
> +Lockdown Mode
> +^^^^^^^^^^^^^
> +
> +A mode which causes the enforcement of the properties necessary to conform to
> +the Secure Boot specification.  Lockdown Mode is forced active when Secure
> +Boot is active in the platform, but may be activated independently too for
> +development purposes with the ``lockdown`` command line option.
> +
> +TODO
> +^^^^
> +
> + * Command Line
> + * Livepatching
> + * Kexec
> + * Userspace hypercalls
> -- 
> 2.39.5
> 
--8323329-788649695-1749763939=:8480--


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 22:08:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 22:08:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013604.1391975 (Exim 4.92)
	(envelope-from )
	id 1uPq6M-00016e-1b; Thu, 12 Jun 2025 22:08:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013604.1391975; Thu, 12 Jun 2025 22:08:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPq6L-00016X-Ui; Thu, 12 Jun 2025 22:08:49 +0000
Received: by outflank-mailman (input) for mailman id 1013604;
 Thu, 12 Jun 2025 22:08: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 1uPq6J-00016R-FD
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 22:08:48 +0000
Received: from 11.mo561.mail-out.ovh.net (11.mo561.mail-out.ovh.net
 [87.98.184.158]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ce80b410-47d9-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 00:08:45 +0200 (CEST)
Received: from director6.ghost.mail-out.ovh.net (unknown [10.108.17.43])
 by mo561.mail-out.ovh.net (Postfix) with ESMTP id 4bJGrX2zmfz1VJG
 for ; Thu, 12 Jun 2025 22:08:44 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-s646q (unknown [10.110.178.131])
 by director6.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 587FC802AD;
 Thu, 12 Jun 2025 22:08:43 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.104])
 by ghost-submission-5b5ff79f4f-s646q with ESMTPSA
 id /81xCOtPS2iSJyoALs7SAA
 (envelope-from ); Thu, 12 Jun 2025 22:08: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: ce80b410-47d9-11f0-a309-13f23c93f187
Authentication-Results:garm.ovh; auth=pass (GARM-104R00552f3c3cb-35ac-4ffc-9653-035e0927df60,
                    8533DEE15F76005A048BC18D4BF0E94304C9A0EA) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
Date: Fri, 13 Jun 2025 01:08:14 +0300
From: Sergii Dmytruk 
To: ross.philipson@oracle.com
Cc: xen-devel@lists.xenproject.org, Jan Beulich ,
	Andrew Cooper ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	"Daniel P. Smith" ,
	trenchboot-devel@googlegroups.com
Subject: Re: [PATCH v3 04/22] x86/boot/slaunch-early: implement early
 initialization
Message-ID: 
References: 
 <16a544876163afece619d50f80869aaacc9c797c.1748611041.git.sergii.dmytruk@3mdeb.com>
 <5792bec7-cd2f-4d27-aa3b-f417b07c8ea8@oracle.com>
 
 <81a3551d-a60c-4aa9-8376-fc5e5550abb1@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <81a3551d-a60c-4aa9-8376-fc5e5550abb1@oracle.com>
X-Ovh-Tracer-Id: 5758978023538406556
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugdduiedvfecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhepvdfgveegtdffhfdugeevieehkeetudevfeefgedtleejledvfeeutdetudeiveelnecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukeegrddvvddupdefjedrheelrddugedvrddutdegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheeiudgmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=wLjn3sax+7ZcrxL8dA07HSKCFrPL7pofictmKqSLwDI=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1749766124; v=1;
 b=YzhY8GiD4r/9qknnfwlFqEltxUJmniqV42rztV7TAa6R+LlHlrdyjUcCpxWDQJPPIVJ4yQuf
 fdx7ntWvVBh9u1Acq5pf7aZ5SJcxjWWhuPOBczHVF5fg72PlRhXqLkZVQ0ziVsoLNZ0m0pCdznG
 O2M+88SJyPGlj3maEfYkTkaKMMgRZYqpnmdqy/yIjPjPMo0hUZDG7QOxvRCBz08e/Zyoq/gkqyK
 N43PMBwyFkw9O/yILXYGiSYB4gHodGpivabZhvIhKucZPwtMWYDtaBVn2Llhbl584ZECKOBvz9g
 7RKzlcLnTlTNuo34x8N6s+cLH8wLiM9zEWJ+48seKnb4Q==

On Thu, Jun 12, 2025 at 09:30:55AM -0700, ross.philipson@oracle.com wrote:
> On 6/11/25 3:14 PM, Sergii Dmytruk wrote:
> > On Tue, Jun 03, 2025 at 09:17:29AM -0700, ross.philipson@oracle.com wrote:
> > > > +void asmlinkage slaunch_early_init(uint32_t load_base_addr,
> > > > +                                   uint32_t tgt_base_addr,
> > > > +                                   uint32_t tgt_end_addr,
> > > > +                                   struct early_init_results *result)
> > > > +{
> > > > +    void *txt_heap;
> > > > +    const struct txt_os_mle_data *os_mle;
> > > > +    const struct slr_table *slrt;
> > > > +    const struct slr_entry_intel_info *intel_info;
> > > > +
> > > > +    txt_heap = txt_init();
> > > > +    os_mle = txt_os_mle_data_start(txt_heap);
> > > > +
> > > > +    result->slrt_pa = os_mle->slrt;
> > > > +    result->mbi_pa = 0;
> > > > +
> > > > +    slrt = (const struct slr_table *)(uintptr_t)os_mle->slrt;
> > > > +
> > > > +    intel_info = (const struct slr_entry_intel_info *)
> > > > +        slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_INTEL_INFO);
> > > > +    if ( intel_info == NULL || intel_info->hdr.size != sizeof(*intel_info) )
> > > > +        return;
> > > 
> > > Since these are the x86/TXT bits, it seems at this point, not finding the
> > > TXT info structure would be fatal, no?
> > 
> > It is fatal, but early code doesn't have means for reporting errors
> > nicely, so it just continues.  You think it's better to reboot right
> > away?
> 
> I was trying to track down where you make the first determination that a TXT
> secure launch is supposed to be done. I think it is before this point so if
> that is the case, I think this should be fatal here.

Yes, this code is invoked only if Slaunch is in progress (Xen was
invoked through Slaunch-specific entry point).  Will add rebooting.

Regards


From xen-devel-bounces@lists.xenproject.org Thu Jun 12 22:12:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jun 2025 22:12:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013610.1391984 (Exim 4.92)
	(envelope-from )
	id 1uPq9S-0002kw-Es; Thu, 12 Jun 2025 22:12:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013610.1391984; Thu, 12 Jun 2025 22:12:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPq9S-0002kp-Bp; Thu, 12 Jun 2025 22:12:02 +0000
Received: by outflank-mailman (input) for mailman id 1013610;
 Thu, 12 Jun 2025 22:12: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 1uPq9R-0002ki-1v
 for xen-devel@lists.xenproject.org; Thu, 12 Jun 2025 22:12:01 +0000
Received: from 16.mo550.mail-out.ovh.net (16.mo550.mail-out.ovh.net
 [178.33.104.224]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4118bb2a-47da-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 00:11:57 +0200 (CEST)
Received: from director8.ghost.mail-out.ovh.net (unknown [10.108.17.189])
 by mo550.mail-out.ovh.net (Postfix) with ESMTP id 4bJGwD5VjQz1VMt
 for ; Thu, 12 Jun 2025 22:11:56 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-7wmqs (unknown [10.108.54.10])
 by director8.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 15419C0240;
 Thu, 12 Jun 2025 22:11:54 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.99])
 by ghost-submission-5b5ff79f4f-7wmqs with ESMTPSA
 id bYetLqpQS2gewwQA6EkgDQ
 (envelope-from ); Thu, 12 Jun 2025 22:11: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: 4118bb2a-47da-11f0-b894-0df219b8e170
Authentication-Results:garm.ovh; auth=pass (GARM-99G003dc92a0d6-1ece-43c2-8554-779af2054e88,
                    8533DEE15F76005A048BC18D4BF0E94304C9A0EA) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
Date: Fri, 13 Jun 2025 01:11:30 +0300
From: Sergii Dmytruk 
To: Jan Beulich 
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	"Daniel P. Smith" ,
	trenchboot-devel@googlegroups.com, ross.philipson@oracle.com
Subject: Re: [PATCH v3 04/22] x86/boot/slaunch-early: implement early
 initialization
Message-ID: 
References: 
 <16a544876163afece619d50f80869aaacc9c797c.1748611041.git.sergii.dmytruk@3mdeb.com>
 <5792bec7-cd2f-4d27-aa3b-f417b07c8ea8@oracle.com>
 
 <031338df-8f6b-4c6f-86b9-aa0b7c808bfc@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <031338df-8f6b-4c6f-86b9-aa0b7c808bfc@suse.com>
X-Ovh-Tracer-Id: 5813021220693914839
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugdduiedvgecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhepvdfgveegtdffhfdugeevieehkeetudevfeefgedtleejledvfeeutdetudeiveelnecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukeegrddvvddupdefjedrheelrddugedvrdelleenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmpdhnsggprhgtphhtthhopedupdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdfovfetjfhoshhtpehmohehhedtmgdpmhhouggvpehsmhhtphhouhht
DKIM-Signature: a=rsa-sha256; bh=zrzcCC97woji16ezpz8QjrgMhuztpT+CBf4oVh4wvkc=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1749766316; v=1;
 b=HeMSb2O18I+C8b1Cluqh/ZK+TKXlhE7IMHhXCS1g6Xd6kaBDVqAPo5L3qkH+gHbw9e9RBAlw
 htcmzTtMKbFgq3lQiEzv7nW79qVBDmxmRryN4LbW7Ydz0MNBcyIkxKPcPiM4/PfQ31uw4Jaji87
 bOF9pe8fYqnEmkF+9K+PDQt53lbPiHReYIPcliRqLCCEBrwJRA/3Y4jC2ZB2aujy88ID/GS8FZs
 CVvLKcMLe4moAJCe0MduKhxAbTtHyRQsiLtyzkGpmfc74YOqBpn9KRrLh4r3+0hs3l7Esp3kWZP
 x75eB4tfmUD456pqL6vC6p0mn8uQSwwecEIdjNUeQ00+w==

On Thu, Jun 12, 2025 at 10:02:33AM +0200, Jan Beulich wrote:
> On 12.06.2025 00:14, Sergii Dmytruk wrote:
> > On Tue, Jun 03, 2025 at 09:17:29AM -0700, ross.philipson@oracle.com wrote:
> >>> +static inline void *txt_init(void)
> >>> +{
> >>> +    void *txt_heap;
> >>> +
> >>> +    /* Clear the TXT error register for a clean start of the day. */
> >>> +    txt_write(TXTCR_ERRORCODE, 0);
> >>> +
> >>> +    txt_heap = _p(txt_read(TXTCR_HEAP_BASE));
> >>> +
> >>> +    if ( txt_os_mle_data_size(txt_heap) < sizeof(struct txt_os_mle_data) ||
> >>> +         txt_os_sinit_data_size(txt_heap) < sizeof(struct txt_os_sinit_data) )
> >>> +        txt_reset(SLAUNCH_ERROR_GENERIC);
> >>
> >> I know the list of error codes pulled in are from the patches for Linux
> >> Secure Launch which seems right. The Xen work is free to add more specific
> >> error codes e.g. somewhere like here. We could even consider using regions
> >> in the vendor error code space for different things like generic errors vs
> >> architecture specific ones vs etc.
> >
> > I think some codes were already added and this is the only place where
> > SLAUNCH_ERROR_GENERIC is used, not really sure why, will add a couple
> > more.  By the way, the new errors were inserted in the middle making
> > about half of the errors out of sync with Linux, should Xen and Linux be
> > in sync?
>
> As the uses isolated to Xen and Linux respectively, or are the values
> propagated between the two in some way? In the former case there's no
> need for them to stay in sync, I think. Whereas in the latter case them
> staying in sync would want enforcing somehow, if at all possible.
>
> Jan

The uses are independent, the error list was copied probably because
error conditions are similar.  I'll remove errors unused in Xen.

Regards


From xen-devel-bounces@lists.xenproject.org Fri Jun 13 01:08:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 01:08:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013697.1391995 (Exim 4.92)
	(envelope-from )
	id 1uPsuB-0005Uk-Q5; Fri, 13 Jun 2025 01:08:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013697.1391995; Fri, 13 Jun 2025 01:08: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 1uPsuB-0005Uc-LI; Fri, 13 Jun 2025 01:08:27 +0000
Received: by outflank-mailman (input) for mailman id 1013697;
 Fri, 13 Jun 2025 01: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 1uPsu9-0005UW-7Z
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 01:08:26 +0000
Received: from mail-10628.protonmail.ch (mail-10628.protonmail.ch
 [79.135.106.28]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e745d171-47f2-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 03:08:23 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e745d171-47f2-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=ubjm4rozczgc5ku2bofcw4q4p4.protonmail; t=1749776901; x=1750036101;
	bh=LhYglOLXFVHP8caU1InXkSVSo2a16iuJKn5Qeo6hK8s=;
	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=RJ0VYmf9Z62976XWmj/lj8eZOOY2mHxs+5su88lKtEsKXv1/YkBWzEKV/uXDpUJvh
	 A2t55L0QW0/Z0XBwQF/aQ8atGL2Z7FZENJ339p8gU0vbDD9/3bPEE2mzjXsXlRX48q
	 uQoRVm0jM4LwJ6mWrNotPb8yyHGWVdfxxxIpQB+x5OkIPKSw/7iIa5WsKzoG683hHH
	 gD0E7T994FJnRPfYprr+e6Fkdy6Ocw3x89T5lrNM8LW9JYj6HihtOf3GoL521O+if5
	 b3LxdTbu/bIcJHKupsgGODeW4AMdjc0ICA4zGKxmOZx1jc62Q1+uEBIS0+UI+3b7PR
	 vSCYrxqdwItjQ==
Date: Fri, 13 Jun 2025 01:08:15 +0000
To: Jan Beulich 
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH] xen/domain: fix late hwdom feature
Message-ID: 
In-Reply-To: <6213c0dd-2145-48a2-9e8a-8a949da5e866@suse.com>
References: <20250610234105.1082890-1-dmukhin@ford.com> <6213c0dd-2145-48a2-9e8a-8a949da5e866@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 55a5a9122dbe5e5c2994db7423118f415a6121c1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 11, 2025 at 11:20:29AM +0200, Jan Beulich wrote:
> On 11.06.2025 01:42, dmkhn@proton.me wrote:
> > From: Denis Mukhin 
> >
> > Fix get_initial_domain_id() which how returns hardware_domid and breaks=
 late
> > hwdom feature [1].
> >
> > [1] https://lore.kernel.org/xen-devel/a4c860d7-1fa0-43f4-8ae1-af59b7c65=
06f@xen.org/
> >
>=20
> Reported-by: Julien Grall 
>=20
> > Fixes: f147ccf2 ("xen/consoled: clean up console handling for PV shim")
>=20
> 12 hex digit please (see sending-patches.pandoc), i.e. f147ccf2b3c8 (larg=
ely for
> my own reference, to make respective adjustments while committing).

Thanks; my .gitcofig did not have core.abbrev configured.

>=20
> > Signed-off-by: Denis Mukhin 
>=20
> Acked-by: Jan Beulich 

Thank you

>=20



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 06:21:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 06:21:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013794.1392005 (Exim 4.92)
	(envelope-from )
	id 1uPxme-0008N3-FX; Fri, 13 Jun 2025 06:21:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013794.1392005; Fri, 13 Jun 2025 06: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 1uPxme-0008Mw-CT; Fri, 13 Jun 2025 06:21:00 +0000
Received: by outflank-mailman (input) for mailman id 1013794;
 Fri, 13 Jun 2025 06: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 1uPxmc-0008Mp-Od
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 06:20:58 +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 90207c10-481e-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 08:20:55 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a54700a46eso1357763f8f.1
 for ; Thu, 12 Jun 2025 23:20:55 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2365de78169sm7145115ad.123.2025.06.12.23.20.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 23:20:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 90207c10-481e-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749795655; x=1750400455; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=GuhmqzkGgYKtcPNMkVVUgIyrlCfhaxVJeTKzU0mfgaM=;
        b=bhibq4UeMIWN4DZ3YGvrAvBVN3f6fdL4sjm42/OSjj74F3T9xz+GvG8TP1VJ2yzzVx
         EQJ2fAWDnSdVWCGfbzj1HvWKYRWNtVKofojxLKITje/8KsCoM2SlYJPseVExbPtTYKBn
         XKJlH3HnXXm9+hBar6FnQm/VWsC3aqTaRlwaFg96upplscQZZXVM49aRYhJuX2E76cYt
         sksxfsHJUacwD6IZABrih1/zMQ4XNzle0O4c7DQTLnxc0lLFcuWjVkAOI4Gmylk4ZHYh
         GivN7KEnPsoeVmRy46EyRMbE1mMUN5kG6o1krsT+OzIa2oMDSCek6bOi4Ej8KU3IVyTY
         99nA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749795655; x=1750400455;
        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=GuhmqzkGgYKtcPNMkVVUgIyrlCfhaxVJeTKzU0mfgaM=;
        b=ArvTHD28U2Qj9UEFi3/+TEa9VfvV0LpQa8jje0riwM3u9dFO8truQ+ZILDgfLB3fU1
         q+w63nYvbAtHJpRSvOn7s6w2cW60joevsbe8xOG1dX02RBUGisGM5GG2kmKUR9XPSwq+
         pOE9qhXgetWvjyVyYhzBGLHrvpaMya5sswvik68qh6GI4CeKD9jdprCYIc2z3GRIp3St
         2BBmmQ2CzRRRC9h7KiETiv2rASg7xRDk/B+7Q8dMasoXj9OMc+k0vKP1mu4W7aeF9fIO
         jy+tedwcdWR8QWVKieMpcjdtsxxTVva/xGxCnpsiInnWbMQAjeLDnCPaJlnxTNdDbv2h
         MWCA==
X-Forwarded-Encrypted: i=1; AJvYcCUGy6ct8UowgzRskt6/66R2uZ2zXAREO5hA7cpF/wLMDcOPebqHDLG75um7RAaA4Z4+x0EtLAleuQE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwRGksb9AG1PsU3nHY8gswDDgpmiCqO3WULTKLbmBWNrzghrjn7
	pRSFfDKZCIDLGJsqA60Gh7EtS4NCk1eIUtlGiHIGSZRtqHzPIFFsedVpfYnkpGsgbw==
X-Gm-Gg: ASbGncspL0wbUHLVTENnZvMwXPa1N/5kzZxMBtNG8/85HctBXUhatNeRdkVscMkIoV1
	ngHiNb4YfVDZI/5s3gPAhIbTiocJcxTAHlZyZ0zokmaGpgX1KpAjzYL31DPX+bP3Ji1BON7lBo2
	W4hUh2wEHrrltdbWlUEoRKxwntQ9p6/qQA+etZ633o47s/ZmuXsBq/RFX/nLOW3kKFUhlL4Y7nL
	og3Cv8syb1naevDKW2u5Yo/8v8xisXb0oKD1b4/Jxw9n96StcMhg5l6M0p4DaX0nRIVKM7o7vyx
	FsZziUiKH8myC08lkMgLGfEM3OLsmErTpfKGMY6vGa1ObFMsBg4e4u8jl2paj1NuTGUxedGgoiq
	p8LzTgZp+tIE0A+JYtnQ1eab65GwNasEdWLKNamM/RIiUUOc=
X-Google-Smtp-Source: AGHT+IHvgWd++SMkJ8DbupvE+BAw7rTlgJued/UIvKksWby3Obp6hSRg3JvhbW1KRCA/HFiOQnQTbQ==
X-Received: by 2002:a5d:64c2:0:b0:3a4:fc52:f5d4 with SMTP id ffacd0b85a97d-3a5687176d4mr1190627f8f.47.1749795654819;
        Thu, 12 Jun 2025 23:20:54 -0700 (PDT)
Message-ID: 
Date: Fri, 13 Jun 2025 08:20:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/4] xsm/silo: Support hwdom/control domains
To: Jason Andryuk 
Cc: "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org
References: <20250610225737.469690-1-jason.andryuk@amd.com>
 <20250610225737.469690-3-jason.andryuk@amd.com>
 <0f47268e-0674-46e7-bfd4-8a395ee1ddf6@suse.com>
 <6cc69b45-7347-4250-ab32-a1e2857b7d23@amd.com>
 <805abeee-0cad-4cc9-88ae-77e4c1e23fac@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 12.06.2025 18:56, Jason Andryuk wrote:
> On 2025-06-12 03:52, Jan Beulich wrote:
>> On 11.06.2025 06:20, Jason Andryuk wrote:
>>> On 2025-06-11 09:17, Jan Beulich wrote:
>>>> On 11.06.2025 00:57, Jason Andryuk wrote:
>>>>> --- a/xen/xsm/silo.c
>>>>> +++ b/xen/xsm/silo.c
>>>>> @@ -20,6 +20,12 @@
>>>>>    #define XSM_NO_WRAPPERS
>>>>>    #include 
>>>>>    
>>>>> +static bool is_priv_domain(const struct domain *d)
>>>>> +{
>>>>> +    return is_xenstore_domain(d) || is_hardware_domain(d) ||
>>>>> +           is_control_domain(d);
>>>>> +}
>>>>
>>>> This construct expands to two evaluate_nospec(), which likely isn't
>>>> wanted. Some open-coding may be pretty much unavoidable here.
>>>
>>> Thanks, yes, good point.
>>>
>>>> (I'm
>>>> surprised it's not three, i.e. I find it odd that is_xenstore_domain()
>>>> doesn't also use that guard.)
>>>
>>> It looks okay to me.  There were only 2 uses until I added a 3rd in the
>>> dom0less code.  The XSM check has evaluate_nospec() and the other 2 uses
>>> aren't security critical - Setting a domain info flag, and __init code
>>> for dom0less.  Maybe moving the evaluate_nospec() would be safer in case
>>> use grows in the future, but it looks okay to me today.
>>
>> When some of the hardening was first introduced, actual use sites were
>> indeed taken into account. That wasn't quite right though, I think. Any
>> such construct ought to be safe to use anywhere. For uses with clearly
>> no concerns towards speculative abuse, a 2nd lightweight form of such
>> constructs should then exist, imo. As to your use of "security critical":
>> I'm not convinced you what mean is covering the potential of speculative
>> abuse of involved code paths.
> 
> I can't parse this last sentence, and I think it's your main point.

Oh, sorry - the "you" and "what" ought to have swapped places.

> XSM -> don't speculate around permission checks.  That's what I meant by 
> "security critical".
> 
> The __init code is inaccessible to users, so it doesn't matter.
> 
>          if ( is_xenstore_domain(d) )
>              continue;
> 
> getdomaininfo sets a flag, so I don't see this making a security 
> difference.  It's not controlling loads or code paths.

Right, but this is what I said should imo not have been done: Make a
predicate speculation-safe (or not) based on its present uses. It's
imo more likely than not that a new use being added won't result in
the predicate being looked at, re-considering its safety for the new
use.

And indeed there's a 3rd use, in xsm_default_action():

    case XSM_XS_PRIV:
        if ( action == XSM_XS_PRIV &&
             evaluate_nospec(is_xenstore_domain(src)) )
            return 0;
        fallthrough;

It should not have been necessary to open-code the speculation safety
here, just like such isn't required a few lines later:

    case XSM_PRIV:
        if ( is_control_domain(src) )
            return 0;
        return -EPERM;

I am, btw, also not convinced the uses of evaluate_nospec() are fully
correct here, in that they apply to only part of the if() conditions.
For "action == XSM_XS_PRIV" it's okay as long as
- the function is indeed inlined, and
- the function argument is compile-time constant.
For "target" the same applies, but there is more room there for the
latter of the constraints to not be met. The argument in favor of
the present arrangements likely was that our main concern here is
with the "success" paths. Yet such argumentation would again be
dependent upon all call sites fitting the assumption that on the
"failure" paths there would be nothing critical that follows.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jun 13 06:35:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 06:35:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013802.1392014 (Exim 4.92)
	(envelope-from )
	id 1uPy0r-0001dn-Me; Fri, 13 Jun 2025 06:35:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013802.1392014; Fri, 13 Jun 2025 06:35: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 1uPy0r-0001dg-Jm; Fri, 13 Jun 2025 06:35:41 +0000
Received: by outflank-mailman (input) for mailman id 1013802;
 Fri, 13 Jun 2025 06:35:40 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uPy0q-0001d7-BL
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 06:35:40 +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 9eec0830-4820-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 08:35:39 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3a53ee6fcd5so1077326f8f.1
 for ; Thu, 12 Jun 2025 23:35:39 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b2fe1639eb8sm765934a12.10.2025.06.12.23.35.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Jun 2025 23:35:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9eec0830-4820-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749796539; x=1750401339; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=dPaGl0o6GFxHjlt3ivrAUOcIHgHk3c4C9Wvx1GOpAac=;
        b=fIy4VE9bUEugQQp97Sm1idZgyiwqLjspjIdaWCT3p0Hp+HNioiejeo7b2u1uTsCyj/
         MAnlRUsj+UCwDCZs/z8h3OabiC6hOGzGleoZeUA1zzaTuOM0NC0wJOCApp1B8z6V2MV5
         u1eqqd/ebU8IZvELbyS5YYvfG+b1rYDOM04WXN5t7CUPr5EbnFKhH7fOrURa2alINCKr
         YhdlNLmbPglPrG2Zwli07bhuWBTvobw8OdN1oA+Nzvp3yr0sv29e05MULbvhmA5pgybr
         FtQbBJ8mLc23gnc7eDyFHzOw92Sk2AKkjAeq7QfL1A3AI+Hrs/Aj3n8FdGr60jGMGNJ6
         o+iw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749796539; x=1750401339;
        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=dPaGl0o6GFxHjlt3ivrAUOcIHgHk3c4C9Wvx1GOpAac=;
        b=mOUzxQ8knie9o6cZe5La4aIXAhf+9lIPEfhLc2Mwd5IjpVPTuBbLaGpWyVYlDa01cr
         0lr/ANeA2WeUiwOCFY602Pig2UpRNsGkNN+oWxlwMF33UbviJlFm2rUKUAUS1bMQvpf5
         O+RDLC2RBKC2c2po7CXWvRmNiHY0y7pgFD/auWxNyKHam3tuj42R7Txv7BGy2Yv4H2Iv
         +0j7K8TYXdajx0OCrrXwmPjKP3wqrMPH6jP0DhN8+o6IE8SP5jiolaSnb7Cr76UqqXNR
         2Ge5ZF4h90K7Pyz/Oo9QtSB2d88IO4tntI2AbwTAqvg6uwnqCfw9k28qtVLA5FT849j3
         lCRw==
X-Gm-Message-State: AOJu0YzZCDVaCpQZVkbRwXUwSAjsljOlBzkYc6fq9BjT+hFy0M87ewMD
	Ha5L+nf9AzUm8s2HH6cUUP/9++nZFeFvyElHAbDbY3/UxByEaFqXl5zEH/ENwDwDqA==
X-Gm-Gg: ASbGnctW5Ttsuxb5DjZIsr1xygMMaahQ5wrq6P+huDn93sd2agBsMLYKRwkgTA1UrqI
	sLhlZ28ZBd335wV4B7ijOQD9CAJkVjVZlnF15TkeLXhJWv5JsJFR6FeSdlD00cZXSi8l0P8aWHf
	qFwIx+hp/OVdW3AikaUiO9+DJslewhqPZ18ZfeUQ518aYrgZ+t3JPHSMmCJEBf/+sJErWVkx2Re
	yzR7Cy5F2SZAlXDx/U2rOW/OlaZXKJzc7H1B8XI/CTSKW1PTsxjLUVCznANE3Jumkuy9iJuJZe1
	wXB2svePIhmL8TaXHcATEzIWpR1gqU1nAa7dIvulw4yD9Y07pZGdkl9ZYo5d2xEODzkhjBt17BL
	EXR6RvTeJCLZlnzeTOPtuchdeU0ttXjLZ3W0WBZC8AUtvsyA=
X-Google-Smtp-Source: AGHT+IFyAXzz5ZatrtlxoApbJHHSnRXU9LxEowrLSY75TbXu9vg/y8NWQJPwPLEW74FHNmEcs4O4rw==
X-Received: by 2002:a05:6000:4021:b0:3a5:2d42:aa17 with SMTP id ffacd0b85a97d-3a5686f1438mr1640661f8f.31.1749796539023;
        Thu, 12 Jun 2025 23:35:39 -0700 (PDT)
Message-ID: <608cf9c5-f057-4d3b-8833-8ef040064fec@suse.com>
Date: Fri, 13 Jun 2025 08:35:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] docs: UEFI Secure Boot security policy
To: Stefano Stabellini 
Cc: Xen-devel ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Juergen Gross ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , Trammell Hudson ,
 Ross Lagerwall ,
 Frediano Ziglio ,
 Gerald Elder-Vass ,
 Kevin Lampis ,
 Andrew Cooper 
References: <20250611235851.167385-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: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12.06.2025 23:32, Stefano Stabellini wrote:
> On Thu, 12 Jun 2025, Andrew Cooper wrote:
>> +Support in Xen
>> +--------------
>> +
>> +There are multiple ways to achieve this security goal, with differing
>> +tradeoffs for the eventual system.
>> +
>> +On one end of the spectrum is the Unified Kernel Image.  e.g. Xen is bundled
>> +with the dom0 kernel and init-ramdisk, with an embedded command line, and with
>> +livepatching and kexec compiled out, and suitably signed.  The signature is
>> +checked by the bootloader and, as this covers all the privileged code, Xen
>> +doesn't need to perform further checks itself.
>> +
>> +On the other end of the spectrum is maintaining the features of existing
>> +deployments.  e.g. Xen needs signature checking capabilities for the dom0
>> +kernel, livepatches and kexec kernels, and needs to allow the use of safe
>> +command line options while disallowing unsafe ones.
> 
> I just wanted to mention that there is one more option which I used in
> the past: the firmware/bootloader loads Xen, the Dom0 kernel, and other
> binaries, check their signatures, then boot Xen.
> 
> This is similar to the "Unified Kernel Image" approach in the sense that
> Xen doesn't need to do any signature checking for the dom0 kernel, but
> it doesn't require all the binaries to be glued together.
> 
> Assuming that the firmware/bootloader is capable of loading multiple
> binaries and checking the signature of multiple binaries before booting
> the next element, it works fine.

How would an initrd, a ucode blob, or an XSM policy blob be signed?

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jun 13 06:35:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 06:35:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013804.1392025 (Exim 4.92)
	(envelope-from )
	id 1uPy0w-0001sU-1J; Fri, 13 Jun 2025 06:35:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013804.1392025; Fri, 13 Jun 2025 06:35: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 1uPy0v-0001sL-U3; Fri, 13 Jun 2025 06:35:45 +0000
Received: by outflank-mailman (input) for mailman id 1013804;
 Fri, 13 Jun 2025 06:35: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 1uPy0u-0001d7-OF
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 06:35:44 +0000
Received: from NAM04-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam04on20627.outbound.protection.outlook.com
 [2a01:111:f403:240a::627])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a03bad90-4820-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 08:35:43 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 PH8PR12MB7256.namprd12.prod.outlook.com (2603:10b6:510:223::15) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.33; Fri, 13 Jun
 2025 06:35:38 +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.8835.018; Fri, 13 Jun 2025
 06:35: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: a03bad90-4820-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=WUGq2G/yCv0hTDgYdQrR7yABVxaIT9mBOa2/5RrfmGQ5zDf+fxR3ChfO3BxCJwW9MGIBew/VN7fJa4Xnf6Gn97b5HxaShaCxV2GLW0kkbAnBp4fB7pDN9WYWPzBPA1mD7ABR0Ao1TXug9f1dC5S5cEF/lx5ZiHImOMPMY88HtpNLNd20XMtsETiYbq2k9p14bNvF59sg3S9Rg9KYWSizndWbg6Kta0XEd0QSkt76brBYVCxOMfZa3qGVkKYwYZk8sXI09R5lc8V6TPCWBvYwjhCthakG1HBgb+mgTsVbm1JT4o/6F8j4BCxeTX7tj3pGj+VO752DcgDBu91zsX0uYw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=453UZOf8DqXnlgtoH0CxSf+qNMouKVvUB4Lpp6Kfhs8=;
 b=M3OqMLoYJRc/SY6VtEFAGr0Qei16+t70Keiv1toiYNSrtNlCQXxtIM4QMmTY22jH9AUdLKun6ZxcjJXFDRKA/iRE8qDUDllNJjMQhDO4pbM5D6Uen0mg80+sSUxgo6b4HMQH76detgY02mhEcC94QJfVBsIg1vE7O7eBKrRTyK3dkSjp38HWLx5RjRIu7dh4iOBTf8QEmSyGxIVB2GotfNxx+8b8vZH68X7nWp3YP/YGulSgSLs+Mx7I/7FzqimB4eWDHcymAH16Rv69wH2LkpL2OrBR0zO+k7dMYIFNkFGUn1TVfVaf7w8TH7caaBS2pLQIQxyiUqDbFw3s0IMkZw==
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=453UZOf8DqXnlgtoH0CxSf+qNMouKVvUB4Lpp6Kfhs8=;
 b=4Xh342H9+Q0dOBw6iXo33nDY50vJR84ahzVLTPtVu8YgiN8kunJyFd68zStr0t8GgfW4VZylOlFOZO9OafxE+FcYM/e3wd8LfSIa7Ar2Oh056j/2cdEK3c0uaLGQef60r8R9f6oIrfu7lMGnmg1ngxDCGoiEvLh9/JZIpM2DmmE=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Andrew Cooper
	, Anthony PERARD ,
	"Orzel, Michal" , Julien Grall ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano
 Stabellini , "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v4 17/20] xen/sysctl: make CONFIG_COVERAGE depend on
 CONFIG_SYSCTL
Thread-Topic: [PATCH v4 17/20] xen/sysctl: make CONFIG_COVERAGE depend on
 CONFIG_SYSCTL
Thread-Index: AQHbz7F7SunEZNF6NkqENGvwpWoLO7P8fREAgAQ9xqA=
Date: Fri, 13 Jun 2025 06:35:38 +0000
Message-ID:
 
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
 <20250528091708.390767-18-Penny.Zheng@amd.com>
 <9db2daa0-8905-4b21-8161-27b7fb96dfef@suse.com>
In-Reply-To: <9db2daa0-8905-4b21-8161-27b7fb96dfef@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=True;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-06-13T06:35:32.0000000Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=3;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged
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_|PH8PR12MB7256:EE_
x-ms-office365-filtering-correlation-id: ca094e67-bb09-4e81-62f8-08ddaa4482eb
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?cG1WeUpJQmpqTlpNRTAvNmtpcDdoU2xoZU9RRytvd3RUbWtrekl4VEJBVzJR?=
 =?utf-8?B?ZUYwMHY5eUlhMDRQQjZKSERXVTdXVVdIdTBrbEVrKzlzVTNGaEJhWWkzY2ZT?=
 =?utf-8?B?a3U0bngzdGpNZnhZSkpIbkJCZm5BSUVYL0ZFQ3pyQ0g3R3IyUmdOMWJ5VzAr?=
 =?utf-8?B?eTY4WnhwRWVmSDlmNkRCVGxRenNId2JJaXZTaTlvaXR3Z0J4N2hzeTR0YnJj?=
 =?utf-8?B?MDJBUlBvd1ZleGtHc2xKaE14amZpeC91UEQvd0x6Y2FGK3V2bzhBWXcyOWhC?=
 =?utf-8?B?KzFNWkl1SW13d21EL1J3dVhXMC81Ymk2cEJlVjhIc1hpR01VVVRKd3lhMXBZ?=
 =?utf-8?B?QTZJMVRiWFpLTyswTGtjZ3BIS1VtbWhJSmhReGJMMTVrZkhDaGVlK25uSFhw?=
 =?utf-8?B?ODVBRmVvTlNKTHR1aFF2OWJVUHZoN21qR0FXVnd2Q0tlbHgzTExpZUxMU0p3?=
 =?utf-8?B?SEJ0aEVVL2UvM0RpSWhDUDZxR2F0NVh4ck1YMUp2Zkl1b2VkQm9Da2g3Wkt4?=
 =?utf-8?B?RHBLSjJ5dHI5OG9RTEJrVEZVKzNodzhPVXdQa2IyT1hmS3RFTEFzcitUaTNR?=
 =?utf-8?B?VmpaejRZWWxqSFhSVWF1eU0yZytMaWlhMkpwSjlUWE9DRjdIUWlmLzNCNFll?=
 =?utf-8?B?K2ptSVRFZ0RObndBU25ZbXd5WEYrbEhWeWl6dTgzcVQ1MmZOZWlaNXpYWDQ4?=
 =?utf-8?B?dXJxTHJKajJ6TEdhbGppVjZzaHRLWUp0dFdmWXhmb0t5RGZ1VVJNOHpTeDVq?=
 =?utf-8?B?cExJczlKbEdqOTdDbTc4NnNha3dhWE1UY1RyMHE5aGFlT1JaTWVReUN0M2lk?=
 =?utf-8?B?NFJtS2dvY0xBeUx6QU9BR2NVelNWN2tYb1QwVFE4aFgzcEQzUHFPc2dKeVB2?=
 =?utf-8?B?N01pUUlxUnRUYWQ1eG1BYk1RQnlESTNVK292bGlLUVBONXhkWFVTODVpKzFn?=
 =?utf-8?B?UjZhM0l5TzM3Y3JaejhmcUsyTWFJdXNSUjl1MGpGQ1FIQk4zTHdYVmZJQUVi?=
 =?utf-8?B?dk9XSVJNRWR1WldaNHRJZlpEWnNQWlhMQ2dPS1NSZFdzOEtTTkZsTXJKUEM4?=
 =?utf-8?B?UjI2WitoM0d5bUpMOVpUOThCcHZ2OTBiUGV6cUxRRGVHYjd6VURMYWExQjNC?=
 =?utf-8?B?NmFmMkJFWW44MGxCRXNJcGZ6OE85aWpiZzVxb3NYVHNlODdaVXFWdG12YXUx?=
 =?utf-8?B?YjV6Q0E5TWlBcFB6dzNWRkNlY2JudzdqYmFwV1p1Qzl5b0VqaC9DNStlN1gr?=
 =?utf-8?B?NTBVdjJOZ2N3UlVvcWwxdUMrVEtVNjFTY3BhWnhOQ2VEMnBpZmFiZUhrN2ww?=
 =?utf-8?B?ZGVraEZQVXFvRDgxeXNwc3BIVkd6M2VWb2ovcUlLWlN3ZE1nUHVWNWJ1WFVK?=
 =?utf-8?B?UFQ3YkI3WS9iYmM0YUJUTkhTVDRKMVJYVSs2YWM4UmM5bkxENzBmZUFkTkpx?=
 =?utf-8?B?bUF0ZE5sbEI1Snp3emdBanpLaERwWExKZHNGNzk0TmxjNXBjdml0aTBTbHc5?=
 =?utf-8?B?cTRBeWNFSEVBNnNmVDNZYlpETUFxaHFsd0VJaXhWNWdFbG43clBLbWJWakVP?=
 =?utf-8?B?WFZ1TVg2OE10aFdsc0gyMGVqcUcrYm1YZmxjazhGREFsUTNpcVNFRjVFQlh0?=
 =?utf-8?B?M2h0ZG1XMUJ5WE5WN1VQdjI2bDZ1aFVCZkNYQnJvZDF2T2UzMlMxeUkvNzhi?=
 =?utf-8?B?K3UwQlAycHErR3d3dXg3QW5zVGV6M251YVpzS3I0Zi9NaUt6NEhXN0Q4Uy8v?=
 =?utf-8?B?Z0p2U2RWSWU4c2wyUWdLNHhnZWhQcEVzR1VIdXZIOE92NStqOTkxTld6T1hJ?=
 =?utf-8?B?VlJXdXQ2SjNGb2FBSUVUcnlWd0N1bUNnVEVCM0QrNjRrSEFOdjFJSndzdDl3?=
 =?utf-8?B?cXFyYjZXUVRxeTJCMjVVdlA5NnhoT0NzWGFRTUF3Zng4L3hRZFFVMFJTSjVQ?=
 =?utf-8?B?VTR6czBadGVWMERDR2M3NEZlN01WZUVSQkVFL0w3ZGJyMUJxdHBCTnJXK3Br?=
 =?utf-8?B?dVg2RTE4ZUtBPT0=?=
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)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?dU5IQVcvWkNRQkN4ZUZZUjdNanBoWnJXWU95MDNUdDFsbVowQ2t0Wm42Tm5W?=
 =?utf-8?B?VlhKUkdWR0JEWG01ZG91aGxBWE9iakRvZW44Z20xNExpRC9hZHNDVjFudUVp?=
 =?utf-8?B?d1VhRTlqVjVYVEZQZGVoY3Nrb2VWLzZiMlpRWWJCTVhLbHBFb3ZUU0Q4MlJB?=
 =?utf-8?B?YVluQlpYU1pYakVlUWFLVDNDS0RvQ0xyM0JpYnpuQzNWYUI0a2s0ZUEwY1dO?=
 =?utf-8?B?dFRMSGhoaGt6QnQ4QVBoMGdLbHFlcklFTzBjb2lBMDNjUEc1SlJPd21WZVFP?=
 =?utf-8?B?MkNIL1RldmRKQWVlMml5S2JxWWRFbGVCTmY4b0NEdnl4U24wZGFuNitOM2Zh?=
 =?utf-8?B?R2ladWhqTS8rL1ZqdGJEeWVIVXJraXZPbWhkN0Z4azZOR2FCSkpMY0daaXNN?=
 =?utf-8?B?ekVBWE5mT01jLzdrdHIrTGo4NmRvQm9GdUFvMnlXdHFxcVVDckRJNnFzcEll?=
 =?utf-8?B?N1FBQkdtNjNveVhBelNZblFtS0c5WWJySkQxaHZQN1JsajUwZ3ZWeXowc2Yz?=
 =?utf-8?B?TGpsVzU1dzBVMmpMekFTYWVTYkVURm05VnFxcnJZZFlKVDdyeWZEUFFOZ3VC?=
 =?utf-8?B?NU56dnM1eTkyZ2t0eHRXVW95WmxFcnUrM2lMRmRJN1ErbU9jbzY3WGMxSm9R?=
 =?utf-8?B?bndUSUp0cXkvSEx5aU5zM1JFV2pxd3cxWTJhNTRmQzNaSUt1a3JRN0ZjU1dq?=
 =?utf-8?B?b2E3Y3RUV1AvOWdVc0EvRGtWVyt1dFBUWGRTejlSMEpSTVpxZ0lPeVQ3Nmd6?=
 =?utf-8?B?SlIxN0hOSE1wQUhIc1d2S0hINjhoaDhHRXgzQXpPUTExdVN4RWJBZ2FBaHMz?=
 =?utf-8?B?ME9lQXJoVS9OVVlqK2tDbnZKQXE0cVFwazRFREl1dlIzbThtdEp1clNtZHFL?=
 =?utf-8?B?dEFJNjJPdTVxMzA5cFJVdlpWZ1BjSldUTDNQMXowUDJDQ0VKdjE3T2VHaW91?=
 =?utf-8?B?OTNUQU12Rm5adE5NaEtCWldWc2dCSTVoNzd2dElmVGFqMXFhNXpvMzNPSzhN?=
 =?utf-8?B?UlFGNVI4bk5TOXh5SmZQdTE0cmVTSVZ2QVJacFJpUlNFeVpVUFdWSndVYzZ2?=
 =?utf-8?B?NDRML0grVEhhYWUwM2NQWFlFTGQ3TS9jR1NmeVMzTzl5YmxVcmtLeWp0b1M1?=
 =?utf-8?B?YUg5ZWhkcFFpeUdOUHhCTzVmZTRaWWVDLzc5OTJvbjJuV0dQOXVtTytVWTdU?=
 =?utf-8?B?aTF2YjFnQjErWmVuR2I3NGRtWG5uWDJkOEtHM0FGSzd5WjJwa2NQQmphMVFZ?=
 =?utf-8?B?UVRBMXRURDRlcDF5NkJySEJjVmdFY1gzZFdLRWZOT3hIUDU1RmE1ekZVY3M4?=
 =?utf-8?B?dWxhL3IxcGJJQVgxRFdmMmQxRHZ6eUFJdTRmcFQ5UnJWa0lOdDBwZ3FJL3lx?=
 =?utf-8?B?NU5Bb3dSZXI2bkJpdjE0dGRSYkRCdnRQM1RJTThwZi9BSTVDb1gybTlXaEN0?=
 =?utf-8?B?KzFjTVYyalRnWkxIVHlmNXpRcjhSRmhPckxObzIvY3NBWVRhNVFkNUs3UThE?=
 =?utf-8?B?MDJNOHNhSXZSdU9JSHFuYmI1ZnBQR1FQamNRc0E0OVlhc1cyRFlxa1AyTEVD?=
 =?utf-8?B?ZzdrMXdBZXFJNksyMmhzNTZmMGdoSHB2bDU2WTVmcUR4bEUxTDE1elJ6OE9y?=
 =?utf-8?B?TzRYK1JFM00vUVJ4VkRyc2Ztb0VPaDNOTnBXcUtybkM1ZndhL0piYWZhMitC?=
 =?utf-8?B?YXBYM0RBNHNrWGhWVFVhbDdoZWJ4NlJUaTVUVXJscnprU0x4Z2wrWUt2MFZq?=
 =?utf-8?B?MVZFOXoyb0NyYnhtUG85ckdoeWdzVEVtU0JaL1NXdGlTN1VCMlJEMGU0aVkx?=
 =?utf-8?B?L3VHSXZyWWt1VVNxRzBpTVZOOTQxcXJiR0Iwc2tKTFR6YXZSWkg2VFovUmNo?=
 =?utf-8?B?TUgzN28rMjdsOVVyc2d5THljRFA4SUw5QmNDYTRVSXgzWUNtMUpmekxaU3ZP?=
 =?utf-8?B?Qkdmclo3Y3BSNHRGQ0NneVowVVd6YjZaUnZWSTh3YUowb1MwaVJvaDJMTFY0?=
 =?utf-8?B?Q3lMTUZEckhFck80d1VBMnJra2dWZjBIYXA5K3AxNjlYY3hXTDVzLytyTG12?=
 =?utf-8?B?WHBybXZxWFhjUzlPNUtRaU1nT0ZWWjFCMnlzMkRhZFpWa21JOU43b0NQSXVN?=
 =?utf-8?Q?65c8=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: ca094e67-bb09-4e81-62f8-08ddaa4482eb
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2025 06:35:38.7400
 (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: yOmTEM4X+XReX8kYXZc4m11fPj5dJCSHaFCvkK+y7RW68w5CFLEBGpkCbcVKPD2LWZkxJ+/oFIC0uePu7ee8ag==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7256

W1B1YmxpY10NCg0KSGkNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBK
YW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFR1ZXNkYXksIEp1bmUgMTAs
IDIwMjUgOTo0OCBQTQ0KPiBUbzogUGVubnksIFpoZW5nIDxwZW5ueS56aGVuZ0BhbWQuY29tPg0K
PiBDYzogSHVhbmcsIFJheSA8UmF5Lkh1YW5nQGFtZC5jb20+OyBBbmRyZXcgQ29vcGVyDQo+IDxh
bmRyZXcuY29vcGVyM0BjaXRyaXguY29tPjsgQW50aG9ueSBQRVJBUkQgPGFudGhvbnkucGVyYXJk
QHZhdGVzLnRlY2g+Ow0KPiBPcnplbCwgTWljaGFsIDxNaWNoYWwuT3J6ZWxAYW1kLmNvbT47IEp1
bGllbiBHcmFsbCA8anVsaWVuQHhlbi5vcmc+OyBSb2dlciBQYXUNCj4gTW9ubsOpIDxyb2dlci5w
YXVAY2l0cml4LmNvbT47IFN0ZWZhbm8gU3RhYmVsbGluaSA8c3N0YWJlbGxpbmlAa2VybmVsLm9y
Zz47IHhlbi0NCj4gZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcNCj4gU3ViamVjdDogUmU6IFtQ
QVRDSCB2NCAxNy8yMF0geGVuL3N5c2N0bDogbWFrZSBDT05GSUdfQ09WRVJBR0UgZGVwZW5kDQo+
IG9uIENPTkZJR19TWVNDVEwNCj4NCj4gT24gMjguMDUuMjAyNSAxMToxNywgUGVubnkgWmhlbmcg
d3JvdGU6DQo+ID4gQWxsIGNvdmVyYWdlLXJlbGF0ZWQgb3Agc2hhbGwgYmUgd3JhcHBlZCBhcm91
bmQgd2l0aCBDT05GSUdfU1lTQ1RMLCBzbw0KPiA+IHdlIHNoYWxsIG1ha2UgQ09ORklHX0NPVkVS
QUdFIGRlcGVuZCBvbiBDT05GSUdfU1lTQ1RMLg0KPiA+DQo+ID4gU2lnbmVkLW9mZi1ieTogUGVu
bnkgWmhlbmcgPFBlbm55LlpoZW5nQGFtZC5jb20+DQo+ID4gUmV2aWV3ZWQtYnk6IFN0ZWZhbm8g
U3RhYmVsbGluaSA8c3N0YWJlbGxpbmlAa2VybmVsLm9yZz4NCj4gPiAtLS0NCj4gPiB2MSAtPiB2
MjoNCj4gPiAtIGNvbW1pdCBtZXNzYWdlIHJlZmFjdG9yDQo+ID4gLS0tDQo+ID4gdjMgLT4gdjQ6
DQo+ID4gLSBjb21taXQgbWVzc2FnZSByZWZhY3Rvcg0KPg0KPiBEZXNwaXRlIHRoZXNlIGVmZm9y
dHMgdGhlIGRlc2NyaXB0aW9uIHN0aWxsIGZhaWxzIHRvIHNheSBfd2h5XyB0aGUgc3VwcG9zZWQg
d3JhcHBpbmcNCj4gaXMgbmVlZGVkLiBBbmQgInN1cHBvc2VkIiBiZWNhdXNlIEkgY2FuJ3QgcmVh
bGx5IHNlZSBhbnkgd3JhcHBpbmcuIEFsbCB5b3UgZG8gaXMNCj4gYWRkIGEgZGVwZW5kZW5jeS4N
Cj4NCg0KV2lsbCBjaGFuZ2UgaXQgdG8NCiINClVzZXJzIHJlbHkgb24gU1lTQ1RMX2NvdmVyYWdl
X29wIGh5cGVyY2FsbCB0byBpbnRlcmFjdCB3aXRoIHRoZSBjb3ZlcmFnZSBkYXRhLA0KdGhhdCBp
cywgYWNjb3JkaW5nIG9wZXJhdGlvbnMgc2hhbGwgYmUgd3JhcHBlZCBhcm91bmQgd2l0aCBDT05G
SUdfU1lTQ1RMLg0KUmlnaHQgbm93LCBpdCBpcyBjb21waWxlZCB1bmRlciBDT05GSUdfQ09WRVJB
R0UsIHNvIHdlIHNoYWxsIG1ha2UNCkNPTkZJR19DT1ZFUkFHRSBkZXBlbmQgb24gQ09ORklHX1NZ
U0NUTA0KIg0KDQo+IEFuZCBidHcgLi4uDQo+DQo+ID4gLS0tIGEveGVuL0tjb25maWcuZGVidWcN
Cj4gPiArKysgYi94ZW4vS2NvbmZpZy5kZWJ1Zw0KPiA+IEBAIC0zNyw3ICszNyw3IEBAIGNvbmZp
ZyBTRUxGX1RFU1RTDQo+ID4NCj4gPiAgY29uZmlnIENPVkVSQUdFDQo+ID4gICAgIGJvb2wgIkNv
ZGUgY292ZXJhZ2Ugc3VwcG9ydCINCj4gPiAtICAgZGVwZW5kcyBvbiAhTElWRVBBVENIDQo+ID4g
KyAgIGRlcGVuZHMgb24gIUxJVkVQQVRDSCAmJiBTWVNDVEwNCj4NCj4gLi4uICJkZXBlbmRzIG9u
IFNZU0NUTCAmJiAhTElWRVBBVENIIiB3b3VsZCBmZWVsIG1vcmUgbmF0dXJhbGx5IHRvIG1lLg0K
DQpVbmRlcnN0b29kDQoNCj4NCj4gSmFuDQo=


From xen-devel-bounces@lists.xenproject.org Fri Jun 13 07:01:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 07:01:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013827.1392035 (Exim 4.92)
	(envelope-from )
	id 1uPyPw-0006gD-3G; Fri, 13 Jun 2025 07:01:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013827.1392035; Fri, 13 Jun 2025 07: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 1uPyPv-0006g5-TF; Fri, 13 Jun 2025 07:01:35 +0000
Received: by outflank-mailman (input) for mailman id 1013827;
 Fri, 13 Jun 2025 07:01: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 1uPyPu-0006fs-C7
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 07:01:34 +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 2feaacb6-4824-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 09:01:12 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by SA3PR12MB7951.namprd12.prod.outlook.com (2603:10b6:806:318::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.31; Fri, 13 Jun
 2025 07:00:59 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8792.034; Fri, 13 Jun 2025
 07:00: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: 2feaacb6-4824-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=wAUNYDVJfP+mDHFI4HNkKUDaTTtcYVQ2ZxK1gSl11fgL8TyFx7qmE4IuBzuyxuLhFJ6TXiBTkdFBps7x7ToMab/lzx4lZ8nZVBiauSP4FiXcw9l33EJNVy4+jh5pidkHUvM/lEOXwXOO7og7wkySC8aQCBnqB1aW9ElCEgC9m4pPuTm36abJdbUChyTaRJrxQzuKb/n55OWFPQAnzUOAWHjXLZfAP/I+dj6cg6r5fsBIS0dYr7XkGp60zph3YfKESvQp3x84OR2sg7cQC7ECJi9rS5b1nB+XNp6YYibL3MdZ6jKNYArtbE3ASkbQ0+w+nmR5A0bvfSxG9gkZIwvSbw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=mpBJDW7E0xQHEKHrzpv/PEO5+ab0kS0fFWVIyzAsoZs=;
 b=r1vPnK9P89ddFs+IztUE+SaQH3LwQvnQGTl5gH9osnEbnY8Joka9lkWiqNb9yUKQLsznUsb4YxjF4uc79SX5aOOGMpkZCHySumbKwOGJFpmo9XuZl58jqdPqdZT9bRUPJi3p9hnjIIwldvPVUVWfSej8q2vzYFzvcAqlYR2A3nLQ+cADuOsEn/6k9xDBrdfUs+5XhV4s3i4anF3oIf7SmAjNDbDzovqKSrlVJQLC0CF0yQpysl0OI8QHQhmdJ87IoCaZmHdu55aElUITNecspW9M4LBeAAqkggPVyltufJ+xiKODH89NTUyqDZUIXIC9upB8DPi+m3twwRBDBkpnYw==
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=mpBJDW7E0xQHEKHrzpv/PEO5+ab0kS0fFWVIyzAsoZs=;
 b=pOQIUvgGH5ywKz/D5us0o43RjmuDvchno0VD4dvfQRKEaRxPNc6/onNvFqWUaf+4Eac0Wy4ntE9ugvOdW5vIP7TQ/6EqepjEWN/9jyu9RTnWGQoCERFdF3/lBN7wo+tW6MT9ygqv64p3BXEfkZaSGGHE8wmA4+3sbfeDmMUK4/k=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Fri, 13 Jun 2025 09:00:56 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 6/6] arm/mpu: Enable read/write to protection regions
 for arm32
To: Ayan Kumar Halder ,
 Luca Fancellu ,
 Ayan Kumar Halder 
Cc: "xen-devel@lists.xenproject.org" ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250611143544.3453532-1-ayan.kumar.halder@amd.com>
 <20250611143544.3453532-7-ayan.kumar.halder@amd.com>
 <43768317-3409-46EA-B545-C78937EF42DC@arm.com>
 <9105e7c1-da96-4bf9-9de8-d397712b68f2@amd.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <9105e7c1-da96-4bf9-9de8-d397712b68f2@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR4P281CA0429.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:d1::10) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|SA3PR12MB7951:EE_
X-MS-Office365-Filtering-Correlation-Id: e580123c-c577-4d9e-8277-08ddaa480d1a
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?MStobThBOE90eFlyZXY1K1FnSGNvdkJ6M2VQdUFlSnhYR204d0o2V3pPQ0Np?=
 =?utf-8?B?WGZEK0Q3Y2tjNHpPaVJLZk1vUUhDQ003cDRSTHRZTEQydFNQT1U2bW1XNm9a?=
 =?utf-8?B?QTVzVURkL3Z1Z0pWV050L3I5WjAzVTFVNjRUdWorcm8rbkZVditTempVQ3E5?=
 =?utf-8?B?L0N1M05Vekp6UmxpUlJHTTIrODVJV0NmTDVXSFlVVTJSYVQrWHJNM3pxaGRu?=
 =?utf-8?B?YWN0MklwSlVScHREdWFzZXZ6YUcyZjRYN2RZN25pdWM5RVl4SDdaYkNqOS9T?=
 =?utf-8?B?MXVJejRXK0lsakIzK3A5dForRzFGNjNIaVF5ZXhLYW1mTHQrSlZFa0FSZW5t?=
 =?utf-8?B?UGY1UC8zeVFLQTR2L1l0bzVxVG92dGNjN0FVbnFLcGZKWG9JS0dycm9Tblhz?=
 =?utf-8?B?MzFYdHliaGo1alVMejcyVDUveHhBcjViRWJiSHNkWVlkME1MRGRLWFZKQjI3?=
 =?utf-8?B?c29BN2FseVR5Z1hENThhVTRoYlMwL1lMUldrMU1zQkdmMkcyTHVHWjhOVDQy?=
 =?utf-8?B?QS9zYnpUanN4TUN6RE1VV0RZc2dFQlpraGN5TjFWd2grQllGYTR1YWJ5eWxl?=
 =?utf-8?B?SmpDMjZGd252MlN3eEhXTWE4L25NdHp5WjAwMzVYWHJ6cHVnak1mMGY0VFBZ?=
 =?utf-8?B?ektXM3c1ZGFzM0RMSlhEMDZVVHA1MGZGa212UUtpVU1Wd2hyTVpzaFdXMUM3?=
 =?utf-8?B?ZGFYZ3krVTAwOE5xVTZ2cTJrS2xpZkE3TWVsN1ZUamxhUEsvMFk4REREWnZP?=
 =?utf-8?B?eWs0bmM0VjNHN0pPUjlWc3ozYTNuT2lkN25WQk4wc21vV1lwU3NISlJWelpS?=
 =?utf-8?B?TldQVjR4SjJVWGJoQllGZ3hFNEZwT0t5UDVXS0U1SDJ4U1ZPL1dyQnhJaTRP?=
 =?utf-8?B?ekg4L2t0RDFVOW1ZUE1IekQxbWVNQ1JlZlRUaVBMZytESjBYNXhSejAzeEVr?=
 =?utf-8?B?MGlSMXBTMFM2dyt1NmU5MnNQNXJvSnhNb3JPWGJvR1ZUY2ZrYndIZ3BpdUho?=
 =?utf-8?B?d29LT1NORThMcUNFSzI4VDRGZHRCWVNUYjZrUDZrdTdDOVJpR2ZjL29SSTVU?=
 =?utf-8?B?S1poWkJNenl3UVJoSEtaeVRITXRDajhvUlViVFYrZjhRZVZCYytYRm5DQmx6?=
 =?utf-8?B?N3JmU245MmhLSTI3NU10NDlFS0Y3OXhBR0ZDV1d6d1NKU3JhMXpxTHZYNmpa?=
 =?utf-8?B?emcxVWJka2VLTE04amJjMnY2RTZKNktQYUZFWDNhV1dDWVczQ3dFMUVVaW00?=
 =?utf-8?B?MWloNW1FRmFWYlVDbEFKK3RoQTJaeUlRNXgwMWxwcHl3aHpWT212YmJ2cFZm?=
 =?utf-8?B?cnREUU1Ma1Y1R253bEVnSUY1aTI4UnpvV2xFU2xLK0VYZ2U2blV4VHlzak5D?=
 =?utf-8?B?VDk0OGtlSCtjT1pIbm10YkowZittdG5JcForZlgwRUlEcEU0ZjVrY3RyQWtN?=
 =?utf-8?B?UnVPRDdxWUtrUGFhWW1ZK0EwSWhLWDh4OHArKytUd0R1dkFlNTdPdDMxU25L?=
 =?utf-8?B?QWF2WjhkMWl3ZjhxelBSSVRuWldMWkRVNFhQNGFZa0w5dTZRQW1NaXBLdGRa?=
 =?utf-8?B?TlVrNUFiRWdpN0JJMVQza2pTTzBXYW82TDdpMFdIVHdBZktxakplMzFGYkpI?=
 =?utf-8?B?S3MwQ3RHNS9hT0JhMEpGTnFQT1dOb1gxYmk2MWR1UDdZWWZRSGFoUUkrd1pP?=
 =?utf-8?B?ZmdKL2NoZjJjdDBhSzd1SFNxZEZoS2VZN0VCMDArMXIrYnNac3JQUHl0YWlz?=
 =?utf-8?B?NitLQUJvVUEwa0RNci8yRWFaQnBmcm15OTg5N3d0b2F1VmI4VG5RdzdvZEJH?=
 =?utf-8?B?VzR1czhvRGEveG1BZ1gwaTEreWhjSkRDUzQ0NFM1aFYwenFOcE03VmZ2Vlkz?=
 =?utf-8?B?WEwrbGd1bENOWXh6ZlZQdkJaTXZ4M1ZzUEN5SmhmckNKcjdtWm1kcndUT0Fn?=
 =?utf-8?Q?ktrloWa4Zys=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.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?MnMvdGdiM1Vqb0l5WGRiUnl2cG5OMU03d0tHVmJCWm9oZkhBcDhmV01jcnk4?=
 =?utf-8?B?SWFDWktKQm1LOTkxR2t5aHdoMXdmZVdiQ2Y0YzRvRktnamF0bXRjSkRYN0k3?=
 =?utf-8?B?LzJJY05jVFhsemgxd0VpTTJDZmFieHRCWEdHVWR6NGd4UkZrV2RKMUYvek1h?=
 =?utf-8?B?S21QWEh6bjFxL2Vqb2Z4b0svd3ZObHN1N1FnS1daN0NMQ3FhQ0xLQUJlQUNs?=
 =?utf-8?B?alM0OUsxanpkRGVVVkwxRDZtTFFEQmVUMEFLdTF6Mmk0WDJYSmxUTGJIaFFy?=
 =?utf-8?B?ME95QlQ5S2ZTRVNRdnhvVVczaGkrZW9nYjRPcU5ldTdDVGVSUWtlN3ozdFFP?=
 =?utf-8?B?WGdzM1piZitTclpvNDJKNDJIditMN2czYVVncWZXQ2d0QXVQT3BFQmphZUM0?=
 =?utf-8?B?RFl5Uk1xbWJiT3Q5RnRZWS9pOG0zT2dWRVF3QmY0OWhmRnJwSmg2blVaeWk3?=
 =?utf-8?B?QWh4aE5CZjJEY3MxTGRSa2pTelZBakJVbEtRSVhlQU5uTUV6Nmd1UFdabkRm?=
 =?utf-8?B?UmhOQXRHQmZkRmd6WlV5OGMyT0w5TzJWSFA5ZGFUTkdWT3hrUDFoSU9aWlk3?=
 =?utf-8?B?SmU5dXdxZXpMYkxrKzJLbjg1WVV2SEcyQjFVWWVGU1NUWXBkNkM4cXY2K1pD?=
 =?utf-8?B?dEo0M0NJZm9wczAvZkVxbGk0RnlHOXVtVjFJaXB5MjFYY0R2QmQrcjVDbTFO?=
 =?utf-8?B?QW9NMzdKTncxM0lLTkVYdUh3eGgwc0hjREpsN3dBNHZWc1hIQndWWklsOXdW?=
 =?utf-8?B?WXN1akJ1d3lWK2JTU01GY1NnaG0vbzZDRUlhS0xOZFp4aXRSODJpUHVuWUJy?=
 =?utf-8?B?cDBYSmtibUE3dHB2NDlMNGMxT1lFWnRyRGRkOWFHb29CNDBoUnZ6UjFLUVhk?=
 =?utf-8?B?NlVzQ2lGYWtvdXhOTWxVWTdWV1ZwYitka2YrOXE4eEVaZG1DMk1aVXBaSlV0?=
 =?utf-8?B?TWFrQ3R5Z1I3d2ljVlZFbU5wQk8vVGk2emJ1cWVqMS8xSVVhSlRDMldRaEl1?=
 =?utf-8?B?QVhsU0VSSTE2YlJZWitLNlFSZGl2dXVlYSs5RU5WeWc2TmQvUDRWenNVRjJG?=
 =?utf-8?B?RUhscDhGVkt3MjhnQldHbUZVRG9Sb3prMDE4czdIM3g0Tklub0R4UjcrSXNv?=
 =?utf-8?B?ZmdWT0h6aVFVTFZaK20vV3ZJMXBzVTVRMFY4OUo3aEVKR2VTTnYwWnA4eXJJ?=
 =?utf-8?B?eUhkakNtWmtCNFJ5dFlIZzF4NDNhTnZnTGVhK1d6UkFld0F5N1B6aEpCS2tG?=
 =?utf-8?B?dDBSVWVCRWI2M25mTndNQy9uOEpvSUlHR1E0Tno2TWZrMUtqR3k2dXlydnZG?=
 =?utf-8?B?d1VhcUZlU0E3RUdpL1FyVkZZM3ZPZnNoNVZBZDZhVDZKSkRUalJmZ1pCaTd1?=
 =?utf-8?B?RUtPcTJiME9PT0hyZHRKbzFNTnZzQUJZNHRrQ3BSWjhIOFpMK0ZwQW9GeXpY?=
 =?utf-8?B?SWtZS0szSllqdGFmTDNocWJBRDIwMlVBd0Q2eXR1SEl2ODBKaEF0YjFUNW9Z?=
 =?utf-8?B?Zko1OGFkaEc1c21GbE9ZdlhzOWJCajhCZURTcWRrWE1jR2dPdUlSZ2ZESHBH?=
 =?utf-8?B?UGRQOUh6RGYzUXFaUUxXMXBiSHRUSWFCQk5xTFhnQmxmY3hVTU1rMFdidHZU?=
 =?utf-8?B?d3g4WjBkaHk5ZElJUm1TY2kxUzN3NGhCNU55UGdOVzNrNEZKSnU0SXJ2ZXZV?=
 =?utf-8?B?SHVreU8vVThnVUxyaGM5ZUNsVkg0MFdJeTJnVW5DcGdsbFJRbG1iNGlhYmNK?=
 =?utf-8?B?SXZDeDE1SFEreTk1VDVtSlpDcWx0ZG9Za2JDOWt2eFdkL1ArSHcyUnJTYXZ3?=
 =?utf-8?B?V0VZUWtwZnVnRU5GMlFBZlVnTHVaZ3A4Sm5McFlZZXhGOUdiRlp3akJ1dVM2?=
 =?utf-8?B?YVQvU3NmSklGR3hQNDdSbFZFVTVvdHl4WmJsK3hicGZxYks2Q0xvWTlwZTVp?=
 =?utf-8?B?dEI3MlZhQWQ2RTV5TWZjb0dyRXQ0TjRNdHFQNzNIZHd3bnB4SXZOZmJ6VU5S?=
 =?utf-8?B?NHduckFqT1hrU043a1B5TWRCMldDWFpGQTRBbmtWdWJVRW9ISmZxUlp4VkJk?=
 =?utf-8?B?MnorbVFycXEzeWFQcS9CSmF6clR1bU1obWpCOUNFaS9ZNkl2YlFRRmVwam1L?=
 =?utf-8?Q?TGYc=3D?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e580123c-c577-4d9e-8277-08ddaa480d1a
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jun 2025 07:00:59.2670
 (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: SWVpZjXyAaIPiDnsF4za50pkCRn0Xjq54cfOA0zlTK0K1BmYiZER03SCZllfmbyk
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR12MB7951



On 12/06/2025 12:37, Ayan Kumar Halder wrote:
> 
> On 12/06/2025 10:35, Luca Fancellu wrote:
>> Hi Ayan,
> Hi Luca,
>>
>>> On 11 Jun 2025, at 15:35, Ayan Kumar Halder  wrote:
>>>
>>> Define prepare_selector(), read_protection_region() and
>>> write_protection_region() for arm32. Also, define
>>> GENERATE_{READ/WRITE}_PR_REG_OTHERS to access MPU regions from 32 to 255.
>>>
>>> Enable pr_{get/set}_{base/limit}(), region_is_valid() for arm32.
>>> Enable pr_of_addr() for arm32.
>>>
>>> Signed-off-by: Ayan Kumar Halder 
>>> ---
>> Based on your v2 (https://patchwork.kernel.org/project/xen-devel/patch/20250606164854.1551148-4-ayan.kumar.halder@amd.com/) I was imaging something like this:
>>
>> diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
>> index 74e96ca57137..5d324b2d4ca5 100644
>> --- a/xen/arch/arm/mpu/mm.c
>> +++ b/xen/arch/arm/mpu/mm.c
>> @@ -87,20 +87,28 @@ static void __init __maybe_unused build_assertions(void)
>>    */
>>   static void prepare_selector(uint8_t *sel)
>>   {
>> -#ifdef CONFIG_ARM_64
>>       uint8_t cur_sel = *sel;
>>   
>> +#ifdef CONFIG_ARM_64
>>       /*
>> -     * {read,write}_protection_region works using the direct access to the 0..15
>> -     * regions, so in order to save the isb() overhead, change the PRSELR_EL2
>> -     * only when needed, so when the upper 4 bits of the selector will change.
>> +     * {read,write}_protection_region works using the Arm64 direct access to the
>> +     * 0..15 regions, so in order to save the isb() overhead, change the
>> +     * PRSELR_EL2 only when needed, so when the upper 4 bits of the selector
>> +     * will change.
>>        */
>>       cur_sel &= 0xF0U;
>> +#else
>> +    /* Arm32 MPU can use direct access for 0-31 */
>> +    if ( cur_sel > 31 )
>> +        cur_sel = 0;
>> +#endif
>>       if ( READ_SYSREG(PRSELR_EL2) != cur_sel )
>>       {
>>           WRITE_SYSREG(cur_sel, PRSELR_EL2);
>>           isb();
>>       }
>> +
>> +#ifdef CONFIG_ARM_64
>>       *sel = *sel & 0xFU;
>>   #endif
>>   }
>> @@ -144,6 +152,12 @@ void read_protection_region(pr_t *pr_read, uint8_t sel)
>>           GENERATE_READ_PR_REG_CASE(29, pr_read);
>>           GENERATE_READ_PR_REG_CASE(30, pr_read);
>>           GENERATE_READ_PR_REG_CASE(31, pr_read);
>> +        case 32 ... 255:
>> +        {
>> +            pr->prbar.bits = READ_SYSREG(PRBAR_EL2);
>> +            pr->prlar.bits = READ_SYSREG(PRLAR_EL2);
>> +            break;
>> +        }
>>   #endif
>>       default:
>>           BUG(); /* Can't happen */
>> @@ -190,6 +204,12 @@ void write_protection_region(const pr_t *pr_write, uint8_t sel)
>>           GENERATE_WRITE_PR_REG_CASE(29, pr_write);
>>           GENERATE_WRITE_PR_REG_CASE(30, pr_write);
>>           GENERATE_WRITE_PR_REG_CASE(31, pr_write);
>> +        case 32 ... 255:
>> +        {
>> +            WRITE_SYSREG(pr->prbar.bits & ~MPU_REGION_RES0, PRBAR_EL2);
>> +            WRITE_SYSREG(pr->prlar.bits & ~MPU_REGION_RES0, PRLAR_EL2);
>> +            break;
>> +        }
>>   #endif
>>       default:
>>           BUG(); /* Can't happen */
>>
>>
>> Is it using too ifdefs in your opinion that would benefit the split you do in v3?
> 
> Yes. However, I understand that this is subjective. I need your and 
> Michal/Julien to have an opinion here whether to go with the split 
> (which means some amount of code duplication) or introduce if-defs. I 
> will be happy to proceed as per your opinions.
I don't have a strong opinion here. Maybe I slightly prefer the split to avoid
ifdefery.

~Michal



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 07:03:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 07:03:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013834.1392045 (Exim 4.92)
	(envelope-from )
	id 1uPyRL-0007Ey-Ak; Fri, 13 Jun 2025 07:03:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013834.1392045; Fri, 13 Jun 2025 07:03: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 1uPyRL-0007Er-6s; Fri, 13 Jun 2025 07:03:03 +0000
Received: by outflank-mailman (input) for mailman id 1013834;
 Fri, 13 Jun 2025 07:03: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 1uPyRJ-0007Eh-Q1
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 07:03: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 70f398af-4824-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 09:03:00 +0200 (CEST)
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 48E721F78E;
 Fri, 13 Jun 2025 07:02:59 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id BED8013782;
 Fri, 13 Jun 2025 07:02: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 NqoyLSLNS2jOEgAAD6G6ig
 (envelope-from ); Fri, 13 Jun 2025 07:02: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: 70f398af-4824-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749798179; 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=YtCuR1eybAp77fE00OpWM3TU/ImLKJeSuAAVFoht3gg=;
	b=yANbI/scmaho1TDuTul7Jwdm2lX9vb7YLSpNiSYBTKvif1zkY8B4cf12JIf2YQZzOpfYxr
	EsGrNmeUYbNeQFA8cl/zOqnMR0XoV4vsqC9vKOB0sPXwMaI+5/rnvrhgj9B2RDmic80+SO
	je7SR+bzaMOmymtG+cKUhYDaWHxRaBY=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749798179;
	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=YtCuR1eybAp77fE00OpWM3TU/ImLKJeSuAAVFoht3gg=;
	b=LFmJUxkV0s1fCzMOrcLSqpFr1hiEI9fFcomxo1Y/3WXnNwE5ZEB1uAC+HcKtI8tEmvAl3Y
	r2naVlz0EVAbVxAw==
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.de header.s=susede2_rsa header.b="yANbI/sc";
	dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=LFmJUxkV
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749798179; 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=YtCuR1eybAp77fE00OpWM3TU/ImLKJeSuAAVFoht3gg=;
	b=yANbI/scmaho1TDuTul7Jwdm2lX9vb7YLSpNiSYBTKvif1zkY8B4cf12JIf2YQZzOpfYxr
	EsGrNmeUYbNeQFA8cl/zOqnMR0XoV4vsqC9vKOB0sPXwMaI+5/rnvrhgj9B2RDmic80+SO
	je7SR+bzaMOmymtG+cKUhYDaWHxRaBY=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749798179;
	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=YtCuR1eybAp77fE00OpWM3TU/ImLKJeSuAAVFoht3gg=;
	b=LFmJUxkV0s1fCzMOrcLSqpFr1hiEI9fFcomxo1Y/3WXnNwE5ZEB1uAC+HcKtI8tEmvAl3Y
	r2naVlz0EVAbVxAw==
Message-ID: 
Date: Fri, 13 Jun 2025 09:02:58 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 02/25] drm/dumb-buffers: Provide helper to set pitch
 and size
To: Tomi Valkeinen 
Cc: dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org,
 freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
 imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org,
 nouveau@lists.freedesktop.org, virtualization@lists.linux.dev,
 spice-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org,
 linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
 intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org,
 simona@ffwll.ch, airlied@gmail.com, mripard@kernel.org,
 maarten.lankhorst@linux.intel.com, geert@linux-m68k.org
References: <20250311155120.442633-1-tzimmermann@suse.de>
 <20250311155120.442633-3-tzimmermann@suse.de>
 
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: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Queue-Id: 48E721F78E
X-Rspamd-Action: no action
X-Spam-Flag: NO
X-Spamd-Result: default: False [-3.01 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	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)[];
	ARC_NA(0.00)[];
	URIBL_BLOCKED(0.00)[suse.de:mid,suse.de:dkim,suse.de:email,ideasonboard.com:email,imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo,chromium.org:email];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	RCPT_COUNT_TWELVE(0.00)[20];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_ENVRCPT(0.00)[gmail.com];
	FREEMAIL_CC(0.00)[lists.freedesktop.org,lists.infradead.org,vger.kernel.org,lists.linux.dev,lists.xenproject.org,ffwll.ch,gmail.com,kernel.org,linux.intel.com,linux-m68k.org];
	RCVD_TLS_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	DNSWL_BLOCKED(0.00)[2a07:de40:b281:104:10:150:64:97:from,2a07:de40:b281:106:10:150:64:167:received];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[suse.de:+];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:mid,suse.de:dkim,suse.de:email]
X-Spam-Score: -3.01
X-Spam-Level: 

Hi

Am 12.06.25 um 10:36 schrieb Tomi Valkeinen:
> Hi,
>
> On 11/03/2025 17:47, Thomas Zimmermann wrote:
>> Add drm_modes_size_dumb(), a helper to calculate the dumb-buffer
>> scanline pitch and allocation size. Implementations of struct
>> drm_driver.dumb_create can call the new helper for their size
>> computations.
>>
>> There is currently quite a bit of code duplication among DRM's
>> memory managers. Each calculates scanline pitch and buffer size
>> from the given arguments, but the implementations are inconsistent
>> in how they treat alignment and format support. Later patches will
>> unify this code on top of drm_mode_size_dumb() as much as possible.
>>
>> drm_mode_size_dumb() uses existing 4CC format helpers to interpret
>> the given color mode. This makes the dumb-buffer interface behave
>> similar the kernel's video= parameter. Current per-driver implementations
>> again likely have subtle differences or bugs in how they support color
>> modes.
>>
>> The dumb-buffer UAPI is only specified for known color modes. These
>> values describe linear, single-plane RGB color formats or legacy index
>> formats. Other values should not be specified. But some user space
>> still does. So for unknown color modes, there are a number of known
>> exceptions for which drm_mode_size_dumb() calculates the pitch from
>> the bpp value, as before. All other values work the same but print
>> an error.
>>
>> v4:
>> - use %u conversion specifier (Geert)
>> - list DRM_FORMAT_Dn in UAPI docs (Geert)
>> - avoid dmesg spamming with drm_warn_once() (Sima)
>> - add more information about bpp special case (Sima)
>> - clarify parameters for hardware alignment
>> - add a TODO item for DUMB_CREATE2
>> v3:
>> - document the UAPI semantics
>> - compute scanline pitch from for unknown color modes (Andy, Tomi)
>>
>> Signed-off-by: Thomas Zimmermann 
>> ---
>>   Documentation/gpu/todo.rst         |  28 ++++++
>>   drivers/gpu/drm/drm_dumb_buffers.c | 132 +++++++++++++++++++++++++++++
>>   include/drm/drm_dumb_buffers.h     |  14 +++
>>   include/uapi/drm/drm_mode.h        |  50 ++++++++++-
>>   4 files changed, 223 insertions(+), 1 deletion(-)
>>   create mode 100644 include/drm/drm_dumb_buffers.h
>>
>> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
>> index c57777a24e03..f1bd741b06dc 100644
>> --- a/Documentation/gpu/todo.rst
>> +++ b/Documentation/gpu/todo.rst
>> @@ -515,6 +515,34 @@ Contact: Douglas Anderson 
>>   
>>   Level: Starter
>>   
>> +Implement a new DUMB_CREATE2 ioctl
>> +----------------------------------
>> +
>> +The current DUMB_CREATE ioctl is not well defined. Instead of a pixel and
>> +framebuffer format, it only accepts a color mode of vague semantics. Assuming
>> +a linear framebuffer, the color mode gives and idea of the supported pixel
>> +format. But userspace effectively has to guess the correct values. It really
>> +only works reliable with framebuffers in XRGB8888. Userspace has begun to
>> +workaround these limitations by computing arbitrary format's buffer sizes and
>> +calculating their sizes in terms of XRGB8888 pixels.
>> +
>> +One possible solution is a new ioctl DUMB_CREATE2. It should accept a DRM
>> +format and a format modifier to resolve the color mode's ambiguity. As
>> +framebuffers can be multi-planar, the new ioctl has to return the buffer size,
>> +pitch and GEM handle for each individual color plane.
>> +
>> +In the first step, the new ioctl can be limited to the current features of
>> +the existing DUMB_CREATE. Individual drivers can then be extended to support
>> +multi-planar formats. Rockchip might require this and would be a good candidate.
>> +
>> +In addition to the kernel implementation, there must be user-space support
>> +for the new ioctl. There's code in Mesa that might be able to use the new
>> +call.
>> +
>> +Contact: Thomas Zimmermann 
>> +
>> +Level: Advanced
>> +
>>   
>>   Core refactorings
>>   =================
>> diff --git a/drivers/gpu/drm/drm_dumb_buffers.c b/drivers/gpu/drm/drm_dumb_buffers.c
>> index 9916aaf5b3f2..97cd3dcb79f1 100644
>> --- a/drivers/gpu/drm/drm_dumb_buffers.c
>> +++ b/drivers/gpu/drm/drm_dumb_buffers.c
>> @@ -25,6 +25,8 @@
>>   
>>   #include 
>>   #include 
>> +#include 
>> +#include 
>>   #include 
>>   #include 
>>   
>> @@ -57,6 +59,136 @@
>>    * a hardware-specific ioctl to allocate suitable buffer objects.
>>    */
>>   
>> +static int drm_mode_align_dumb(struct drm_mode_create_dumb *args,
>> +			       unsigned long hw_pitch_align,
>> +			       unsigned long hw_size_align)
>> +{
>> +	u32 pitch = args->pitch;
>> +	u32 size;
>> +
>> +	if (!pitch)
>> +		return -EINVAL;
>> +
>> +	if (hw_pitch_align)
>> +		pitch = roundup(pitch, hw_pitch_align);
>> +
>> +	/* overflow checks for 32bit size calculations */
>> +	if (args->height > U32_MAX / pitch)
>> +		return -EINVAL;
>> +
> check_mul_overflow(args->height, pitch, &size)?

I wasn't aware of that. Requires some re-arrangement of the code, but 
probably makes sense.

>
>> +	if (!hw_size_align)
>> +		hw_size_align = PAGE_SIZE;
>> +	else if (!IS_ALIGNED(hw_size_align, PAGE_SIZE))
>> +		return -EINVAL; /* TODO: handle this if necessary */
>> +
>> +	size = ALIGN(args->height * pitch, hw_size_align);
>> +	if (!size)
>> +		return -EINVAL;
>> +
>> +	args->pitch = pitch;
>> +	args->size = size;
>> +
>> +	return 0;
>> +}
>> +
>> +/**
>> + * drm_mode_size_dumb - Calculates the scanline and buffer sizes for dumb buffers
>> + * @dev: DRM device
>> + * @args: Parameters for the dumb buffer
>> + * @hw_pitch_align: Hardware scanline alignment in bytes
>> + * @hw_size_align: Hardware buffer-size alignment in bytes
>> + *
>> + * The helper drm_mode_size_dumb() calculates the size of the buffer
>> + * allocation and the scanline size for a dumb buffer. Callers have to
>> + * set the buffers width, height and color mode in the argument @arg.
>> + * The helper validates the correctness of the input and tests for
>> + * possible overflows. If successful, it returns the dumb buffer's
>> + * required scanline pitch and size in &args.
>> + *
>> + * The parameter @hw_pitch_align allows the driver to specifies an
>> + * alignment for the scanline pitch, if the hardware requires any. The
>> + * calculated pitch will be a multiple of the alignment. The parameter
>> + * @hw_size_align allows to specify an alignment for buffer sizes. The
>> + * provided alignment should represent requirements of the graphics
>> + * hardware. drm_mode_size_dumb() handles GEM-related constraints
>> + * automatically across all drivers and hardware. For example, the
>> + * returned buffer size is always a multiple of PAGE_SIZE, which is
>> + * required by mmap().
>> + *
>> + * Returns:
>> + * Zero on success, or a negative error code otherwise.
>> + */
>> +int drm_mode_size_dumb(struct drm_device *dev,
>> +		       struct drm_mode_create_dumb *args,
>> +		       unsigned long hw_pitch_align,
>> +		       unsigned long hw_size_align)
>> +{
>> +	u64 pitch = 0;
>> +	u32 fourcc;
>> +
>> +	/*
>> +	 * The scanline pitch depends on the buffer width and the color
>> +	 * format. The latter is specified as a color-mode constant for
>> +	 * which we first have to find the corresponding color format.
>> +	 *
>> +	 * Different color formats can have the same color-mode constant.
>> +	 * For example XRGB8888 and BGRX8888 both have a color mode of 32.
>> +	 * It is possible to use different formats for dumb-buffer allocation
>> +	 * and rendering as long as all involved formats share the same
>> +	 * color-mode constant.
>> +	 */
>> +	fourcc = drm_driver_color_mode_format(dev, args->bpp);
>> +	if (fourcc != DRM_FORMAT_INVALID) {
>> +		const struct drm_format_info *info = drm_format_info(fourcc);
>> +
>> +		if (!info)
>> +			return -EINVAL;
>> +		pitch = drm_format_info_min_pitch(info, 0, args->width);
>> +	} else if (args->bpp) {
>> +		/*
>> +		 * Some userspace throws in arbitrary values for bpp and
>> +		 * relies on the kernel to figure it out. In this case we
>> +		 * fall back to the old method of using bpp directly. The
>> +		 * over-commitment of memory from the rounding is acceptable
>> +		 * for compatibility with legacy userspace. We have a number
>> +		 * of deprecated legacy values that are explicitly supported.
>> +		 */
>> +		switch (args->bpp) {
>> +		default:
>> +			drm_warn_once(dev,
>> +				      "Unknown color mode %u; guessing buffer size.\n",
>> +				      args->bpp);
>> +			fallthrough;
>> +		/*
>> +		 * These constants represent various YUV formats supported by
>> +		 * drm_gem_afbc_get_bpp().
>> +		 */
>> +		case 12: // DRM_FORMAT_YUV420_8BIT
>> +		case 15: // DRM_FORMAT_YUV420_10BIT
>> +		case 30: // DRM_FORMAT_VUY101010
>> +			fallthrough;
>> +		/*
>> +		 * Used by Mesa and Gstreamer to allocate NV formats and others
>> +		 * as RGB buffers. Technically, XRGB16161616F formats are RGB,
>> +		 * but the dumb buffers are not supposed to be used for anything
>> +		 * beyond 32 bits per pixels.
>> +		 */
>> +		case 10: // DRM_FORMAT_NV{15,20,30}, DRM_FORMAT_P010
>> +		case 64: // DRM_FORMAT_{XRGB,XBGR,ARGB,ABGR}16161616F
>> +			pitch = args->width * DIV_ROUND_UP(args->bpp, SZ_8);
>> +			break;
>> +		}
>> +	}
>> +
>> +	if (!pitch || pitch > U32_MAX)
>> +		return -EINVAL;
>> +
>> +	args->pitch = pitch;
>> +
>> +	return drm_mode_align_dumb(args, hw_pitch_align, hw_size_align);
>> +}
>> +EXPORT_SYMBOL(drm_mode_size_dumb);
>> +
>>   int drm_mode_create_dumb(struct drm_device *dev,
>>   			 struct drm_mode_create_dumb *args,
>>   			 struct drm_file *file_priv)
>> diff --git a/include/drm/drm_dumb_buffers.h b/include/drm/drm_dumb_buffers.h
>> new file mode 100644
>> index 000000000000..1f3a8236fb3d
>> --- /dev/null
>> +++ b/include/drm/drm_dumb_buffers.h
>> @@ -0,0 +1,14 @@
>> +/* SPDX-License-Identifier: MIT */
>> +
>> +#ifndef __DRM_DUMB_BUFFERS_H__
>> +#define __DRM_DUMB_BUFFERS_H__
>> +
>> +struct drm_device;
>> +struct drm_mode_create_dumb;
>> +
>> +int drm_mode_size_dumb(struct drm_device *dev,
>> +		       struct drm_mode_create_dumb *args,
>> +		       unsigned long hw_pitch_align,
>> +		       unsigned long hw_size_align);
>> +
>> +#endif
>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>> index c082810c08a8..efe8f5ad35ee 100644
>> --- a/include/uapi/drm/drm_mode.h
>> +++ b/include/uapi/drm/drm_mode.h
>> @@ -1058,7 +1058,7 @@ struct drm_mode_crtc_page_flip_target {
>>    * struct drm_mode_create_dumb - Create a KMS dumb buffer for scanout.
>>    * @height: buffer height in pixels
>>    * @width: buffer width in pixels
>> - * @bpp: bits per pixel
>> + * @bpp: color mode
>>    * @flags: must be zero
>>    * @handle: buffer object handle
>>    * @pitch: number of bytes between two consecutive lines
>> @@ -1066,6 +1066,54 @@ struct drm_mode_crtc_page_flip_target {
>>    *
>>    * User-space fills @height, @width, @bpp and @flags. If the IOCTL succeeds,
>>    * the kernel fills @handle, @pitch and @size.
>> + *
>> + * The value of @bpp is a color-mode number describing a specific format
>> + * or a variant thereof. The value often corresponds to the number of bits
>> + * per pixel for most modes, although there are exceptions. Each color mode
>> + * maps to a DRM format plus a number of modes with similar pixel layout.
>> + * Framebuffer layout is always linear.
>> + *
>> + * Support for all modes and formats is optional. Even if dumb-buffer
>> + * creation with a certain color mode succeeds, it is not guaranteed that
>> + * the DRM driver supports any of the related formats. Most drivers support
>> + * a color mode of 32 with a format of DRM_FORMAT_XRGB8888 on their primary
>> + * plane.
>> + *
>> + * +------------+------------------------+------------------------+
>> + * | Color mode | Framebuffer format     | Compatible formats     |
>> + * +============+========================+========================+
>> + * |     32     |  * DRM_FORMAT_XRGB8888 |  * DRM_FORMAT_BGRX8888 |
>> + * |            |                        |  * DRM_FORMAT_RGBX8888 |
>> + * |            |                        |  * DRM_FORMAT_XBGR8888 |
>> + * +------------+------------------------+------------------------+
>> + * |     24     |  * DRM_FORMAT_RGB888   |  * DRM_FORMAT_BGR888   |
>> + * +------------+------------------------+------------------------+
>> + * |     16     |  * DRM_FORMAT_RGB565   |  * DRM_FORMAT_BGR565   |
>> + * +------------+------------------------+------------------------+
>> + * |     15     |  * DRM_FORMAT_XRGB1555 |  * DRM_FORMAT_BGRX1555 |
>> + * |            |                        |  * DRM_FORMAT_RGBX1555 |
>> + * |            |                        |  * DRM_FORMAT_XBGR1555 |
>> + * +------------+------------------------+------------------------+
>> + * |      8     |  * DRM_FORMAT_C8       |  * DRM_FORMAT_D8       |
>> + * |            |                        |  * DRM_FORMAT_R8       |
>> + * +------------+------------------------+------------------------+
>> + * |      4     |  * DRM_FORMAT_C4       |  * DRM_FORMAT_D4       |
>> + * |            |                        |  * DRM_FORMAT_R4       |
>> + * +------------+------------------------+------------------------+
>> + * |      2     |  * DRM_FORMAT_C2       |  * DRM_FORMAT_D2       |
>> + * |            |                        |  * DRM_FORMAT_R2       |
>> + * +------------+------------------------+------------------------+
>> + * |      1     |  * DRM_FORMAT_C1       |  * DRM_FORMAT_D1       |
>> + * |            |                        |  * DRM_FORMAT_R1       |
>> + * +------------+------------------------+------------------------+
>> + *
>> + * Color modes of 10, 12, 15, 30 and 64 are only supported for use by
>> + * legacy user space. Please don't use them in new code. Other modes
>> + * are not support.
>> + *
>> + * Do not attempt to allocate anything but linear framebuffer memory
>> + * with single-plane RGB data. Allocation of other framebuffer
>> + * layouts requires dedicated ioctls in the respective DRM driver.
>>    */
>>   struct drm_mode_create_dumb {
>>   	__u32 height;
> Reviewed-by: Tomi Valkeinen 

Thanks for reviewing.

Best regards
Thomas

>
>   Tomi
>

-- 
--
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 Fri Jun 13 07:15:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 07:15:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013856.1392054 (Exim 4.92)
	(envelope-from )
	id 1uPydd-0001CJ-Gw; Fri, 13 Jun 2025 07:15:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013856.1392054; Fri, 13 Jun 2025 07:15: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 1uPydd-0001CC-EO; Fri, 13 Jun 2025 07:15:45 +0000
Received: by outflank-mailman (input) for mailman id 1013856;
 Fri, 13 Jun 2025 07:15: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 1uPydc-0001C6-3q
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 07:15:44 +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 3079c5a0-4826-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 09:15:31 +0200 (CEST)
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 4F20B2115E;
 Fri, 13 Jun 2025 07:15: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 CB0A513782;
 Fri, 13 Jun 2025 07:15: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 TbJIMBzQS2iFFgAAD6G6ig
 (envelope-from ); Fri, 13 Jun 2025 07:15: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: 3079c5a0-4826-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749798941; 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=AFKIeJdzd7Bm1UfGUYdUXTMZwzn7kuZf09ynXcNd27k=;
	b=wpnxcqgjRop7dkbkBQ/X1iuElaw96F5zP50QsPn5I4PbCQYjlf8kTIsBu6JxfU6RPDJuDp
	RxQ4MhnWMcmky2ZNo4wk7bRNFuuNxkOpgFB9eXHAcKu2tTzWDaCYQ4M/VUWfplABYgNbFh
	sVh+N4mU2AnW9XJXV/M4hBmN1ndOy/w=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749798941;
	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=AFKIeJdzd7Bm1UfGUYdUXTMZwzn7kuZf09ynXcNd27k=;
	b=kPjofHKQaFEdsoc79AwOm7JvdSfaz141myzJctvWsea6Z/9xOjZvLdd1Jo7NEsyl0iHep4
	TeHnsN5rMrD7G5Aw==
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749798941; 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=AFKIeJdzd7Bm1UfGUYdUXTMZwzn7kuZf09ynXcNd27k=;
	b=wpnxcqgjRop7dkbkBQ/X1iuElaw96F5zP50QsPn5I4PbCQYjlf8kTIsBu6JxfU6RPDJuDp
	RxQ4MhnWMcmky2ZNo4wk7bRNFuuNxkOpgFB9eXHAcKu2tTzWDaCYQ4M/VUWfplABYgNbFh
	sVh+N4mU2AnW9XJXV/M4hBmN1ndOy/w=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749798941;
	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=AFKIeJdzd7Bm1UfGUYdUXTMZwzn7kuZf09ynXcNd27k=;
	b=kPjofHKQaFEdsoc79AwOm7JvdSfaz141myzJctvWsea6Z/9xOjZvLdd1Jo7NEsyl0iHep4
	TeHnsN5rMrD7G5Aw==
Message-ID: 
Date: Fri, 13 Jun 2025 09:15:40 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 03/25] drm/gem-dma: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
To: Tomi Valkeinen 
Cc: dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org,
 freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
 imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org,
 nouveau@lists.freedesktop.org, virtualization@lists.linux.dev,
 spice-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org,
 linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
 intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org,
 simona@ffwll.ch, airlied@gmail.com, mripard@kernel.org,
 maarten.lankhorst@linux.intel.com, geert@linux-m68k.org
References: <20250311155120.442633-1-tzimmermann@suse.de>
 <20250311155120.442633-4-tzimmermann@suse.de>
 
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: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spamd-Result: default: False [-2.80 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_TLS_ALL(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[20];
	MIME_TRACE(0.00)[0:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	FREEMAIL_ENVRCPT(0.00)[gmail.com];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FROM_HAS_DN(0.00)[];
	FREEMAIL_CC(0.00)[lists.freedesktop.org,lists.infradead.org,vger.kernel.org,lists.linux.dev,lists.xenproject.org,ffwll.ch,gmail.com,kernel.org,linux.intel.com,linux-m68k.org];
	TO_DN_SOME(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:email,suse.de:mid]
X-Spam-Level: 
X-Spam-Flag: NO
X-Spam-Score: -2.80

Hi

Am 12.06.25 um 10:43 schrieb Tomi Valkeinen:
> Hi,
>
> On 11/03/2025 17:47, Thomas Zimmermann wrote:
>> Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
>> buffer size. Align the pitch to a multiple of 8.
>>
>> Push the current calculation into the only direct caller imx. Imx's
>> hardware requires the framebuffer width to be aligned to 8. The
>> driver's current approach is actually incorrect, as it only guarantees
>> this implicitly and requires bpp to be a multiple of 8 already. A
>> later commit will fix this problem by aligning the scanline pitch
>> such that an aligned width still fits into each scanline's memory.
>>
>> A number of other drivers are build on top of gem-dma helpers and
>> implement their own dumb-buffer allocation. These drivers invoke
>> drm_gem_dma_dumb_create_internal(), which is not affected by this
>> commit.
>>
>> Signed-off-by: Thomas Zimmermann 
>> ---
>>   drivers/gpu/drm/drm_gem_dma_helper.c     | 7 +++++--
>>   drivers/gpu/drm/imx/ipuv3/imx-drm-core.c | 2 ++
>>   2 files changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_gem_dma_helper.c b/drivers/gpu/drm/drm_gem_dma_helper.c
>> index b7f033d4352a..49be9b033610 100644
>> --- a/drivers/gpu/drm/drm_gem_dma_helper.c
>> +++ b/drivers/gpu/drm/drm_gem_dma_helper.c
>> @@ -20,6 +20,7 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>>   #include 
>>   #include 
>>   
>> @@ -304,9 +305,11 @@ int drm_gem_dma_dumb_create(struct drm_file *file_priv,
>>   			    struct drm_mode_create_dumb *args)
>>   {
>>   	struct drm_gem_dma_object *dma_obj;
>> +	int ret;
>>   
>> -	args->pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
>> -	args->size = args->pitch * args->height;
>> +	ret = drm_mode_size_dumb(drm, args, SZ_8, 0);
>> +	if (ret)
>> +		return ret;
>>   
>>   	dma_obj = drm_gem_dma_create_with_handle(file_priv, drm, args->size,
>>   						 &args->handle);
>> diff --git a/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c b/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
>> index ec5fd9a01f1e..e7025df7b978 100644
>> --- a/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
>> +++ b/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
>> @@ -145,6 +145,8 @@ static int imx_drm_dumb_create(struct drm_file *file_priv,
>>   	int ret;
>>   
>>   	args->width = ALIGN(width, 8);
>> +	args->pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
>> +	args->size = args->pitch * args->height;
>>   
>>   	ret = drm_gem_dma_dumb_create(file_priv, drm, args);
>>   	if (ret)
> Won't the pitch and size just be overwritten by the
> drm_gem_dma_dumb_create() call?

Right, looks like it. Thanks for looking over this. The call to 
drm_gem_dma_dumb_create() needs to be changed 
drm_gem_dma_dumb_create_internal(). The latter doesn't modify the 
arguments besides some sanity checks. BTW patch 10 cleans up imx 
entirely. Best regards Thomas
>
>   Tomi
>

-- 
--
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 Fri Jun 13 07:32:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 07:32:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013870.1392064 (Exim 4.92)
	(envelope-from )
	id 1uPyti-0004ED-Qd; Fri, 13 Jun 2025 07:32:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013870.1392064; Fri, 13 Jun 2025 07:32:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPyti-0004E6-Nu; Fri, 13 Jun 2025 07:32:22 +0000
Received: by outflank-mailman (input) for mailman id 1013870;
 Fri, 13 Jun 2025 07:32: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 1uPytg-0004E0-UL
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 07:32:21 +0000
Received: from mail.zytor.com (terminus.zytor.com [2607:7c80:54:3::136])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 889ff70f-4828-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 09:32:19 +0200 (CEST)
Received: from [192.168.7.202] ([71.202.166.45]) (authenticated bits=0)
 by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 55D7VjwM3704239
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO);
 Fri, 13 Jun 2025 00:31:46 -0700
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 889ff70f-4828-11f0-a309-13f23c93f187
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 55D7VjwM3704239
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com;
	s=2025052101; t=1749799910;
	bh=krbuP/fm6w7WAkYJYWFwpvmZlC0fDISskA1NKizA7xQ=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=ssHkh09EYcaM0Ax6sdq6MtHrSSxYTaTdcsnzbRZgcdG+Isq/WnrBYczUvXTg5CwxN
	 pcVjrm3xKQn0yhcf7jb4dEx6sAKdEgZR2whPfrJi89pD9zuGgdch3sodHzB0WrMC7R
	 znHrQnL1Zvv+QUqFkfvmElRpjUN5lFqBkpRJm4PrSkrsX90V3GU0gMSIA7JFCrIutu
	 PwNP6YQlhIiu/pootMO99LR+3o2402BhzCDOvvFgc9nC53bLkUx4x+coky0NVxfIxv
	 7y4XiCFqoDT400d95pn8JvIEA/eXVRCbaX7CtNG3q80d78+ryMmj16UFMuEHvO2ytx
	 T+ZJnfwKScM6Q==
Message-ID: <0c2dab1d-9b5c-4d34-af0e-8a14907d7335@zytor.com>
Date: Fri, 13 Jun 2025 00:31:44 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/6] x86/paravirt: Switch MSR access pv_ops functions to
 instruction interfaces
To: Juergen Gross , linux-kernel@vger.kernel.org,
        x86@kernel.org, virtualization@lists.linux.dev
Cc: Ajay Kaher ,
        Broadcom internal kernel review list
 ,
        Thomas Gleixner
 , Ingo Molnar ,
        Borislav Petkov ,
        Dave Hansen ,
        "H. Peter Anvin" ,
        Boris Ostrovsky ,
        xen-devel@lists.xenproject.org,
        Andrew Cooper 
References: <20250506092015.1849-1-jgross@suse.com>
 <20250506092015.1849-6-jgross@suse.com>
 <722f5b30-20e9-4540-98e4-d211d7c44cbe@zytor.com>
 <9f4e33d5-9cb3-4079-b764-87a15265fd52@suse.com>
 <2365af70-d36f-4663-b819-59d886936ef5@zytor.com>
 <8a82946a-6c3e-41d1-b3bd-be164dc6eeba@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: <8a82946a-6c3e-41d1-b3bd-be164dc6eeba@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 6/11/2025 5:58 AM, Juergen Gross wrote:
>> Here is a patch I cooked.  I added an ALTERNATIVE() hack because the 
>> new instructions can't be more than 6 bytes long.  But with the patch you
>> just sent, it shouldn't be needed.
> 
> I have meanwhile dropped the patch copying the original indirect call.
> 
> Reason is that I'm seeing a potential risk with current alternative
> patching when using ALTERNATIVE_[23](): depending on the tested features
> it might happen that an instruction sequence not suitable for the current
> runtime environment is patched in as an intermediate step. In case there
> is an interrupt happening just then AND the handling of the interrupt is
> using the patch site, this could result in crashes or undefined behavior.

Oh, I had assumed that Linux disables interrupts during the patching
process. Just out of curiosity, why are interrupts allowed in this case?

> 
> I have meanwhile a set of 3 patches fixing that problem by merging all
> alternative patching of a patch site in the local buffer and only then
> patching the code at the target site with the final result.
> 
> The same problem arises with your code below, but this time it isn't
> fixed by my patches: the two ALTERNATIVE() instances in the asm() construct
> would need to be patched in a single atomic operation to be consistent.
> Otherwise you could end up e.g. on bare metal with paravirt_read_msr()
> having replaced the indirect call with "rdmsr", but not yet having added
> the code to merge %rdx into %rax.
> 
> I'm just doing a V2 of my series, but this time including the additional
> support of the non-serializing and immediate forms. Lets see how this will
> look like. I will drop using the EAX_EDX_* macros, but due to the reason
> mentioned above I won't switch to your variant completely.

Great!

Thanks!
     Xin


From xen-devel-bounces@lists.xenproject.org Fri Jun 13 07:53:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 07:53:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013886.1392074 (Exim 4.92)
	(envelope-from )
	id 1uPzEH-0007HW-FG; Fri, 13 Jun 2025 07:53:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013886.1392074; Fri, 13 Jun 2025 07:53:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPzEH-0007HP-Cl; Fri, 13 Jun 2025 07:53:37 +0000
Received: by outflank-mailman (input) for mailman id 1013886;
 Fri, 13 Jun 2025 07:53: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 1uPzEG-0007HJ-Bu
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 07:53:36 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on20625.outbound.protection.outlook.com
 [2a01:111:f403:2407::625])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 817ad67b-482b-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 09:53:34 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by CH3PR12MB9124.namprd12.prod.outlook.com (2603:10b6:610:1a7::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.23; Fri, 13 Jun
 2025 07:53:31 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8792.034; Fri, 13 Jun 2025
 07:53: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: 817ad67b-482b-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=HpK/XViHUoZ/76+ZmwbB2l+BbJsylRDVAxeM84hj6bllku+a3Qk0s76HJjeR6w0M3RHCK38wKqjNhNme5JKtbE0XN59Jkj9gB569kwwvy9pt9ndneMbMbEGBkmbc3s2V3/rjsManPBaXHxFw20ZW+lT1lTYptJ8JDpV75CmB5jgU8kmC3Mxs0SToUQHwvZ2UAgkCeS/KPWHDTeu24xsU2AIMqw/d8Ry4gBB2jtmaZmnVrX9guF0cWgou6nfyllAaiReo+tBRrtp+op49aIQnZpXnjNz0ygeEZ581YIDK7SrM/CQl8C17TA23/jC+RxOmgGNpzxgORr4lwnpBH59Jlg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=CAcSQNZ0y2Sb6z/URFBCdGkghbTMqhrdlRt3DkGP44k=;
 b=AwquvirxVBVuaAMWEBqMPoMzsNb8Fba6dk/7GKW1h8CipfthU6Ro7pgAefJyoeCbhxKGPMAED54Id9Dt/Xgm5K2P6IZt1h/+90U57CyVJ7MmE/3HzQJ5DLIU7Df1DJp/EOf5cRSHCx50ucbErTwIC4adhdpfjLuKTiMIu9CJIl8sfHM51L0M6Ly0r9JKgk0e61RTHlw/7MyiaC/5Vwc/2L01/o0JUTTjNEx2gi0WtYjDzP3iFJL+7ISAxttuzKgOajf5ey8ki4m+jnMyTGD9+gdRkmDffQD1ugTxeF/8yafbwrVSRf2mPCDhY+SCriJsgPw/1/8k4fUhsO968bem4Q==
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=CAcSQNZ0y2Sb6z/URFBCdGkghbTMqhrdlRt3DkGP44k=;
 b=L/8mbylfyR8VI9VNUm58n6nzJyHcApOstDMZTZDXdFsAYzs6O5JiIFX5BzWTewymc5mHxUCbbGzRENeorjPwRwt0AImSVwuZvOrFED69vSGnyRqnQdyb90gPNMaWMYlp+UZF9rZa1wPgtIzt6uU2Hmw0u+2TMWXZEOUNTv/+H8g=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <8884a8e1-4816-4b08-9f27-58f1df0c1d30@amd.com>
Date: Fri, 13 Jun 2025 09:53:27 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4][PART 1 2/4] xen/arm: Implement PSCI SYSTEM_SUSPEND
 call for guests
To: Mykola Kvach , Julien Grall 
Cc: xen-devel@lists.xenproject.org, Mykola Kvach ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: 
 <1a8313537603bee36636b0fcd2fdc2f76a2374fb.1748337249.git.mykola_kvach@epam.com>
 
 
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: FR4P281CA0220.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:e4::15) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|CH3PR12MB9124:EE_
X-MS-Office365-Filtering-Correlation-Id: a3ded44d-3464-4864-68d5-08ddaa4f63e6
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?a2h2Y3ZGQlYvL2FOY3hwQXVzZGJjZlVlWTBWS1FEQlZsb1hPUFp1NnN6MDRo?=
 =?utf-8?B?V0hhWjJQeDIxRUo0ZmdsWHhTNmZOK1dQbnM1QXhwODlremJqODdxWGJZZU1V?=
 =?utf-8?B?cThIQ2xSUDduRHNVOUNhTmxHNDVGME5ESHNBVkFGWVJndUR1dHhmVFB1VmtB?=
 =?utf-8?B?Um1RRTRsRUFGRDd1ZHBDMmVPUzJWT3dqUEpJaE9YMHhNc25wQTVWSDRxOW9a?=
 =?utf-8?B?QXBUU3lsckppbUFHTmduamtYbHAySVlOVzdtampRUE5qUlJUZ2tPN0tDK2U1?=
 =?utf-8?B?VVJNUWNXMEdrU3IzRDB1RkdFN3NjZ04vYndodG9lQzJjRE1yZmNpTlQzcFpR?=
 =?utf-8?B?cUQyUHYvd1JldHlHVXdmV2pvbU96UGo1dWhILytNTWZZQ1Y1aVp4MHV3Vnhu?=
 =?utf-8?B?SHY1N2JvVHNLM291V3RIRGhEazlodkUyK2UxckNudDhIU3A0dENzdFNnTGlC?=
 =?utf-8?B?d1ZJK2t5U2RjM2lkQ09QU3E4VzUxUjJsQTRZejY5U2paRjc4TlY2T1lWem9h?=
 =?utf-8?B?dE8yYkI3K002ZXNzdnpHNUIzR3NnajJKZXVtc3lMdGRHbTZBRmw5dGoyT2dQ?=
 =?utf-8?B?aW5lNVNEK3JnK1lJNWMvTUZwQktHb2JLM2tUV1hrYTlSYStIMHBKR2lNNHkv?=
 =?utf-8?B?NXhOU0JQRWdxVHlTVXB6R2NwcjNicVlVWlB2UVpQNHZOSG5sR2tnYUh3NitM?=
 =?utf-8?B?aVdia3BXY2RjMXlmQkpUekR6bHRwSHl6NFlMckJ3b3gzbDdrdGd6N0F0c0NG?=
 =?utf-8?B?RDU4VjV2c1hzV2N3N25qUzBzT0FOR2grbVVKOWJEZFd4RWUxa0YybE9PSUJL?=
 =?utf-8?B?V3VkcHBaYmY4cktmaU5qdWliUGZncHZmMlp0WTQyYi9FQ0E5VjF0Nk5qa3hQ?=
 =?utf-8?B?R1ZPazNuU2tlMzE5akZic2l6eEhUdS9VS0JwdlhwdzIxTzF1MGl2Y3R0eTFw?=
 =?utf-8?B?TjBsaGZlT1Z5ejVNZGRpYmR1cUxxL05JZk9Wb2JWMzZBQkN2MlJncFdPVkdL?=
 =?utf-8?B?d0xRTkZXVENnNm9GLzNjOXZyZ2svY091amFGdU5IeHA3OVVoMVIyaC9hTkkw?=
 =?utf-8?B?WXNoTmRvY1ZkUno1NjU0L1UycDhqaTdQZDBuKzkzVXErc29OTUZidHZsOE50?=
 =?utf-8?B?QUFsWHBwN0NnOVh5NlpHelFiaWtxRkc4TFRuUWZ0MndwMzhJZ25qQmhLM2w1?=
 =?utf-8?B?QU5FaGNLci8yc0hnaVIxZ0VpYk5KVFAyVEQ3UzJIVVkyaGFHR1U2blIxTXh5?=
 =?utf-8?B?a21nN2xVZEhwcEs2dUYwSlUwc3RmUzYrM2s1ZzNFd0ZQY2QxTTJNMi84Y29E?=
 =?utf-8?B?dUQydlNhM0M0NTdkNUh5Yy9EOGwrZGtGMjRFd01xQWFrNGVYWnMwOEIvSmxn?=
 =?utf-8?B?cDZXbjgxNWtLMUJ5TlFtLzk4Z2xrZk93NVdFNngwemZtWDVrYXdkdktZSGdN?=
 =?utf-8?B?QjVZVUp6eUhwNEFpdWo2WUg5bkcyaS9aTHE5UEQzNmRoSjJPRlhPbGlrZFhJ?=
 =?utf-8?B?b2ZhRnFWNXNKckdQa0ZQLzVONFhnbFFJUjFFNlp6NFJhSTgvOVBZVDVHQ3Ry?=
 =?utf-8?B?Rm5iQWJVcGlEc3h2S1RjN1U3ZVBjcU9XUUJ2aXFmdjB1S3VYc09yNEFCMlc4?=
 =?utf-8?B?czFMVEJyK3hsVFpvdkJTazAvQUtaTXNYNnZ6NVNCSEw1WUY4ak5XS05VYlNK?=
 =?utf-8?B?Q2dqbkJyVGNuTDEreXE3YnRxNzd2TVFSSGNTK1cwMzBkN2ZLVkV5aTFaamlH?=
 =?utf-8?B?amZqMFoyYVdWUERka0dVNWIxR3hGV3NpdytkM01TOC9DRlMxZnczMzdadTNT?=
 =?utf-8?B?VjBzcmNEOXNqbE5FenptRkxVSTJpZjJsM29lcWFNUGZBNUJNd0dGcWIyQXRU?=
 =?utf-8?B?V3VUUkg0OGF2NGVaRkFkb3NvMW1jRWt5bGJ2a1B4QncrOGlmdUZoVE91c3NX?=
 =?utf-8?Q?ci6FpzhfVos=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.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?anhhWTAzek1LcVRScy8rcExHRUFQT1JuY0U3cUVKZWdHclR1YllmTU5wT1Nz?=
 =?utf-8?B?Q0Z3QmRKOXlTTldXRDVFdnV6WjdnMTV0VzVlWHQ1ajM2YTV4djVrWHp5ZGpn?=
 =?utf-8?B?aitMT1EvNG01OSthK01xSDNtZHppemZ4UWpySkJzUzVxNVJFc3FKaDJvS2NX?=
 =?utf-8?B?b2U4eVNnaGpoNjd6S1JOSVVnL09JMUcyK0dVMmJOVSs0U2FSOE1JN2RaS0Zt?=
 =?utf-8?B?RWQ4Z09EQXEzYXhlR0RES2xFeEY3RmplYzZ4Y3VZM1FENFJtaDdxZjhiN3RE?=
 =?utf-8?B?MjJNYlA1eWs1NkYxL1RMbDNQa1BDUWR0bm5CakdQMFovNUZ6Y2QvM3Y2dUY3?=
 =?utf-8?B?QklVb2pUUlRIOHNjZEkwU2l2eWtBWUxCVFh2M29YbU9rNmFTN3dtZGtVd2dF?=
 =?utf-8?B?ZXU4U2pnOC9TOFVIOC9uSDFIMWpEUk8yMm1iZ1dEenlmK1FOYjdxSDZDemQz?=
 =?utf-8?B?QkYwYTQ0YU02T20zbjUwbWVDUzc1RFAyRlZ2dHM0MFBKSXFHRS9FK1lVOWVE?=
 =?utf-8?B?eHRGUy81Y0FmN1ZqZHBSalhFcWRIRXdoSkkycVJlOVBYYnlTQzBUcDB3L01E?=
 =?utf-8?B?a0U2TUwxWXNNTkVmcU9IeG1yQm5IUmNqTE90RGZpQ3lLM3AydmYzMGM5T2Rj?=
 =?utf-8?B?VWxmazV6cXRTd1o2UXJlRjZJb3B4MzN0MHJhWlBKU2k0b3FOcGZHdFNOT05P?=
 =?utf-8?B?ZHRHcmVuT2dGZWJkWllaanhEU3BVM2JSMXNkZW43T1ZFcWZtR3JJWHA2TThu?=
 =?utf-8?B?V0MrM2YvZ3F6N1VWazJ1Zmo4ZUhoT1JObDNMT0E3OVZwWVBjVmR4WGNiU3RW?=
 =?utf-8?B?V2hvTDgwMTNYcjNmVkZoZHJUWEw0S21CWW5YM1haSDBRdEIvaC9YQWpvLzRj?=
 =?utf-8?B?d0o1aytNWThueG1PTkpKVFVseFNDZkt0WkpHdW1JNmkwbXdSYWFBaEZ6dVZT?=
 =?utf-8?B?OTRWMkdhdm12TTJCcFZON3RuZlFoTTJMc2k5RjMxT0hFZ1lUekRUY3ZQRnNm?=
 =?utf-8?B?Mi9oditDZ3pSVDJQMXREajFpc1FHSS9SSDBXS2JnS2xJMkZydllXSjhsOHFR?=
 =?utf-8?B?Vm9peDdWSGZjREcxZjFpYmc5cURkY2RWcEd4VHZtak5BKzdYZVJGYkU3MHh0?=
 =?utf-8?B?NVBOcTI1NHI0a1JWeko2V2pVRGFHY1o0a2xPak1XVVNTV0svQ3Rqc2NWRTUv?=
 =?utf-8?B?WS8xNTdGQlRFUFk2M3lqaWl1Z244MkVJZTI4bHUzclBZWTFJNld3R3R6Q3Ry?=
 =?utf-8?B?Mm1MUkREME9BN00zU2VvbGNOM0pUTzJYQzJuZ3E2VURGZ0JKK1NpSHJ0R25a?=
 =?utf-8?B?eVVmMWxGRWRsQzlwU09iNG52eGR0Y2ZQM0x2cFJpbGZpNmNtajRqQjI3MEE3?=
 =?utf-8?B?d0JmK1FkK0ZOK3pCRC90aXdLUmRDdTV5SS9GR0EvU1VaS2NkT0x5MjRZYzFH?=
 =?utf-8?B?S1FtU2ZveXFaU2xqUzhtSm1RcTFrUnBqWGdaNlNabFYyNjNrZFgvV3gzN3FY?=
 =?utf-8?B?d2Q0K1ZlenY1Sm1jTFJqeDRTQm9NeXFWL3JFblZrdmhqd1JiY0o5c2wxZTBy?=
 =?utf-8?B?cWdwZFJGaklDSXdSVVYxRnVEc3BOLzFtQ1c3eS9EM2lnaXB5bUZQTHNUVEhl?=
 =?utf-8?B?WEVsSHk5ZVl5VEI1L09mb2NjVEhva2hhMiszVkxoN0FvR0N3dVdVa1RDT3Fj?=
 =?utf-8?B?UkwrN3M4MmdET1A1d0hXWEZ2VlpIZUNFd05Jckp4aTZKbkkwZWQ5SU1od1pB?=
 =?utf-8?B?TGxEV1dXNjlFMHpCdWk2V1lMd3ppYnozclNHV3FxMFdNSkV5bDhCQXZZRkU5?=
 =?utf-8?B?T21ONGlwMWsybG9mUVJoWktIak4zbWJzQU1la2NZVlZheXJXazN0NnJaWGVu?=
 =?utf-8?B?NThjeTMrQldQNjZXS1F2alZSOG1lR293ajdkMXBjeEhOV3ROUEZMbWRQa2lL?=
 =?utf-8?B?dHVQcHpKMzljQXB2dE15TTEzRDBLQ2t5RHA0TktaSzRZYmR1Qk1pek5heFRa?=
 =?utf-8?B?QkZGeDVlVmtrT090UCsvQW5iQ2J5TWhvMGlPem56dEwrVmZXZ1pXUVN2NG5D?=
 =?utf-8?B?YVl4UmhlVXB3bkVIY1gwSUVJWFpWeUhjWEJpaW1xdUYvZXgxOUJETHNZMnNM?=
 =?utf-8?Q?yzdI=3D?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a3ded44d-3464-4864-68d5-08ddaa4f63e6
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jun 2025 07:53:31.4143
 (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: hXJg8KuC6QDm94fDRLo48aOAV86nYUiMLhtlrqKIsrTQWWtJbmco1fsAIJ0PyMfd
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB9124



On 06/06/2025 05:52, Mykola Kvach wrote:
> Hi, @Julien Grall
> 
> On Wed, Jun 4, 2025 at 2:00 AM Julien Grall  wrote:
>>
>> Hi Mykola,
>>
>> On 27/05/2025 10:18, Mykola Kvach wrote:
>>> From: Mykola Kvach 
>>>
>>> This patch adds support for the PSCI SYSTEM_SUSPEND function in the vPSCI
>>> (virtual PSCI) interface, allowing guests to request suspend via the PSCI
>>> v1.0 SYSTEM_SUSPEND call (both 32-bit and 64-bit variants).
>>>
>>> The implementation:
>>> - Adds SYSTEM_SUSPEND function IDs to PSCI definitions
>>> - Implements trapping and handling of SYSTEM_SUSPEND in vPSCI
>>> - Allows only non-hardware domains to invoke SYSTEM_SUSPEND; for the
>>>    hardware domain, PSCI_NOT_SUPPORTED is returned to avoid halting the
>>>    system in hwdom_shutdown() called from domain_shutdown
>>> - Ensures all secondary VCPUs of the calling domain are offline before
>>>    allowing suspend due to PSCI spec
>>> - Treats suspend as a "standby" operation: the domain is shut down with
>>>    SHUTDOWN_suspend, and resumes execution at the instruction following
>>>    the call
>>
>> Looking at the specification, I am still not convinced you can implement
>> PSCI SUSPEND as a NOP. For instance, in the section "5.1.19
>> SYSTEM_SUSPEND", the wording implies the call cannot return when it is
>> successul.
>>
>> I understand that 5.20.2 ("Caller reponsabilities" for SYSTEM_SUSPEND)
>> suggests the caller should apply all the rules from 5.4 ("Caller
>> responsabilties" for CPU_SUSPEND), but it is also mentioned that
>> SYSTEM_SUSPEND behave as the deepest power down state.
>>
>> So I don't think standby is an option. I would like an opinion from the
>> other maintainers.
> 
> Sure, let's discuss this with the others.
My understanding of the spec is that SYSTEM_SUSPEND is equivalent to CPU_SUSPEND
*for the deepest possible powerdown* state. CPU_SUSPEND can be implemented as
standby or powerdown, but the SYSTEM_SUSPEND only mentions powerdown state
(which is the true deepest state). Therefore I don't think standby could apply
to SYSTEM_SUSPEND and we could simply ignore the entry point address passed by OS.

~Michal

> 
>>
>>> +static int32_t do_psci_1_0_system_suspend(register_t epoint, register_t cid)
>>  > +{> +    struct vcpu *v;
>>> +    struct domain *d = current->domain;
>>> +
>>> +    /* Drop this check once SYSTEM_SUSPEND is supported in hardware domain */
>>> +    if ( is_hardware_domain(d) )
>>> +        return PSCI_NOT_SUPPORTED;
>>> +
>>> +    /* Ensure that all CPUs other than the calling one are offline */
>>> +    for_each_vcpu ( d, v )
>>> +    {
>>> +        if ( v != current && is_vcpu_online(v) )
>>
>> I think this is racy because you can still turn on a vCPU afterwards
>> from a vCPU you haven't checked.
>>
> 
> I'll think about how to protect against such cases.
> Thank you for pointing that out.
> 
>> Did you add this check just to follow the specification, or is there any
>> other problem in Xen?
> 
> Yes, it's just to comply with the specification — at least,
> I've never seen PSCI_DENIED triggered because of this check.
> It's a leftover from a previous patch series.
> 
>>
>>> +            return PSCI_DENIED;
>>  > +    }> +
>>> +    /*
>>> +     * System suspend requests are treated as performing standby
>>> +     * as this simplifies Xen implementation.
>>> +     *
>>> +     * Arm Power State Coordination Interface (DEN0022F.b)
>>
>> This comment is a bit too verbose. There is no need to copy/paste the
>> specification. You can just write a couple of sentence with link to the
>> specification.
> 
> Got it, I'll revise the comment accordingly.
> 
>>
>> Cheers,
>>
>> --
>> Julien Grall
>>
> 
> Best regards,
> Mykola



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 08:01:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 08:01:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013897.1392085 (Exim 4.92)
	(envelope-from )
	id 1uPzLg-0001DZ-Bk; Fri, 13 Jun 2025 08:01:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013897.1392085; Fri, 13 Jun 2025 08: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 1uPzLg-0001DS-8i; Fri, 13 Jun 2025 08:01:16 +0000
Received: by outflank-mailman (input) for mailman id 1013897;
 Fri, 13 Jun 2025 08: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 1uPzLe-0001DL-SI
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 08:01:14 +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 8c25676c-482c-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 10:01:01 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-441ab63a415so20175415e9.3
 for ; Fri, 13 Jun 2025 01:01:12 -0700 (PDT)
Received: from ?IPV6:2003:e5:872a:8800:5c7b:1ac1:4fa0:423b?
 (p200300e5872a88005c7b1ac14fa0423b.dip0.t-ipconnect.de.
 [2003:e5:872a:8800:5c7b:1ac1:4fa0:423b])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4532e224cb2sm46051975e9.5.2025.06.13.01.01.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 13 Jun 2025 01:01:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8c25676c-482c-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749801672; x=1750406472; 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=oVkBrK/A0vLvhoTA8U0y8twjRvHkjlMpOpc6rdFuRs4=;
        b=UJdaPW2NUz08ksGkQXZ8qS8wvayPjR/yhTQzT6IjUEkcPEd59H4UDQyl65sYchL2c2
         4zDTb05Qy3A6egtT3idtjBz6bhnVc4Awlj7Q3Hi4hEvk7UCiMCk93GKhONG2b+gMDi1h
         bDiFIUcR0p9+fQZFBGbSxZp8UMnlB6ZaJz5L3LNDYYLMaw1BdcfFiuu4D3GtHwIY7i3L
         ODEbCmM39S666QHCCL/U7ZDy2n7WMmQIxzHjUqnhMMfFKJfmpNSGRRjpyW1YnBWxX7Vy
         9/trj2g789fU6QJ2SoiC0UqVTc8n6ZRQIn4qgnH0GICa5ZMHYQwudEN8FrrWZCH0Nj1n
         uteA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749801672; x=1750406472;
        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=oVkBrK/A0vLvhoTA8U0y8twjRvHkjlMpOpc6rdFuRs4=;
        b=q33YrxxU0GtZFkTv54NAxRKKkslBd6XJfRWNWKrIsmo7EZA4nqeZkg3e+T0+5r8293
         7ALxy097i3gZ/peUFChhgHOdRLU6L7shNJumuzH4xmg88t+QYtEuEW13kmIb9IkEoWAr
         x//TaO+QdAdUyWBFpwPJZnow4ceEFFO13OcZlTIYjQBZhOmO8RlZbhHO+uOYujVhn0SB
         dH5FiIUejcWu5LWYT+EA//+6vh4Cpmp4pT6zy+hRods3bvxOY3zuD4PcoYK5Mm89Gw4S
         X531+z8eaEpmtmVM3Ft9yc7HOSG9HOMRUP0JgckAixoNpR6cXBHOkz2TWnVsVLZ3TBtV
         yWbw==
X-Forwarded-Encrypted: i=1; AJvYcCWD7byB69fuFG9/A44P+4RlRkxl5P360KihBkzftbwh/nNCkFPjxDa/Xor/6EDZmescukaSYkkfGx8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy7cOwX8cNSjRy+sl1n7xEY6kTSv6cnjUFnNe1uFkaCRe0QQ4L7
	DvG6vjgd4itl8icQKXAOv4OPIhJtZn5YuMy0jc+JxePqJBX2DS8L//F4uDAo0+XU8QY=
X-Gm-Gg: ASbGncvD17AboKepaIfFNxMs3oY+/cjmCIShbTWD6iycp1ckHqr3CG8erJ8kfAPoetd
	OqqfUWjkVxEfdbz0NRookZwoZlNX3SJzz2spoKeYyVcjM4VWq37sJjse53KW5kzrLjcH4tO3OvQ
	zQoncM6VjUQIoIoj0fF0YcMmK17Ee7gPzopXkdy/R1woX8MpnJhmdXkuM+nNokyxljfYhFHTY5R
	lWtEYaDDXrv8FEBxC7kFxgQe+tpe0riwX/l7v5+niM3NTyqD6RmGlrYbDfoiNRBoa3u25NnWcxA
	9bb3oUQtjaOnHOC55vPTQbM4fbMF8MWmXCTnM04BqEYzzDMmH+P7Ve1GKAAeimS/bKkyPcUVqAu
	fS2AMMoQdE4+Ir6cInAgRuHRkHTRpb66xMMerXqL6ShF6YbDniuM19mOJJDh8bib0dtg1TH6SE5
	R+cGH2CA2k9F0=
X-Google-Smtp-Source: AGHT+IFMe7wbeTc0LOBRSkO3BDuKqUyRIhs/5ZGTQ8wq12AaIc2cDx4+sbER33SEbuRIuacSzKv0ag==
X-Received: by 2002:a05:600c:4e02:b0:442:e147:bea6 with SMTP id 5b1f17b1804b1-45334a7fce4mr17323885e9.11.1749801671116;
        Fri, 13 Jun 2025 01:01:11 -0700 (PDT)
Message-ID: 
Date: Fri, 13 Jun 2025 10:01:09 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/6] x86/paravirt: Switch MSR access pv_ops functions to
 instruction interfaces
To: Xin Li , linux-kernel@vger.kernel.org, x86@kernel.org,
 virtualization@lists.linux.dev
Cc: Ajay Kaher ,
 Broadcom internal kernel review list
 , Thomas Gleixner
 , Ingo Molnar ,
 Borislav Petkov , Dave Hansen ,
 "H. Peter Anvin" ,
 Boris Ostrovsky ,
 xen-devel@lists.xenproject.org, Andrew Cooper 
References: <20250506092015.1849-1-jgross@suse.com>
 <20250506092015.1849-6-jgross@suse.com>
 <722f5b30-20e9-4540-98e4-d211d7c44cbe@zytor.com>
 <9f4e33d5-9cb3-4079-b764-87a15265fd52@suse.com>
 <2365af70-d36f-4663-b819-59d886936ef5@zytor.com>
 <8a82946a-6c3e-41d1-b3bd-be164dc6eeba@suse.com>
 <0c2dab1d-9b5c-4d34-af0e-8a14907d7335@zytor.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: <0c2dab1d-9b5c-4d34-af0e-8a14907d7335@zytor.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------STIfmqOdBFBaxqvTwNHJSgls"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------STIfmqOdBFBaxqvTwNHJSgls
Content-Type: multipart/mixed; boundary="------------tCGUA4CXW29PV7rMp3vv2bed";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Xin Li , linux-kernel@vger.kernel.org, x86@kernel.org,
 virtualization@lists.linux.dev
Cc: Ajay Kaher ,
 Broadcom internal kernel review list
 , Thomas Gleixner
 , Ingo Molnar ,
 Borislav Petkov , Dave Hansen ,
 "H. Peter Anvin" ,
 Boris Ostrovsky ,
 xen-devel@lists.xenproject.org, Andrew Cooper 
Message-ID: 
Subject: Re: [PATCH 5/6] x86/paravirt: Switch MSR access pv_ops functions to
 instruction interfaces
References: <20250506092015.1849-1-jgross@suse.com>
 <20250506092015.1849-6-jgross@suse.com>
 <722f5b30-20e9-4540-98e4-d211d7c44cbe@zytor.com>
 <9f4e33d5-9cb3-4079-b764-87a15265fd52@suse.com>
 <2365af70-d36f-4663-b819-59d886936ef5@zytor.com>
 <8a82946a-6c3e-41d1-b3bd-be164dc6eeba@suse.com>
 <0c2dab1d-9b5c-4d34-af0e-8a14907d7335@zytor.com>
In-Reply-To: <0c2dab1d-9b5c-4d34-af0e-8a14907d7335@zytor.com>

--------------tCGUA4CXW29PV7rMp3vv2bed
Content-Type: multipart/mixed; boundary="------------5Uu5knDZMhxHDHh1wwEwuctw"

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

T24gMTMuMDYuMjUgMDk6MzEsIFhpbiBMaSB3cm90ZToNCj4gT24gNi8xMS8yMDI1IDU6NTgg
QU0sIEp1ZXJnZW4gR3Jvc3Mgd3JvdGU6DQo+Pj4gSGVyZSBpcyBhIHBhdGNoIEkgY29va2Vk
LsKgIEkgYWRkZWQgYW4gQUxURVJOQVRJVkUoKSBoYWNrIGJlY2F1c2UgdGhlIG5ldyANCj4+
PiBpbnN0cnVjdGlvbnMgY2FuJ3QgYmUgbW9yZSB0aGFuIDYgYnl0ZXMgbG9uZy7CoCBCdXQg
d2l0aCB0aGUgcGF0Y2ggeW91DQo+Pj4ganVzdCBzZW50LCBpdCBzaG91bGRuJ3QgYmUgbmVl
ZGVkLg0KPj4NCj4+IEkgaGF2ZSBtZWFud2hpbGUgZHJvcHBlZCB0aGUgcGF0Y2ggY29weWlu
ZyB0aGUgb3JpZ2luYWwgaW5kaXJlY3QgY2FsbC4NCj4+DQo+PiBSZWFzb24gaXMgdGhhdCBJ
J20gc2VlaW5nIGEgcG90ZW50aWFsIHJpc2sgd2l0aCBjdXJyZW50IGFsdGVybmF0aXZlDQo+
PiBwYXRjaGluZyB3aGVuIHVzaW5nIEFMVEVSTkFUSVZFX1syM10oKTogZGVwZW5kaW5nIG9u
IHRoZSB0ZXN0ZWQgZmVhdHVyZXMNCj4+IGl0IG1pZ2h0IGhhcHBlbiB0aGF0IGFuIGluc3Ry
dWN0aW9uIHNlcXVlbmNlIG5vdCBzdWl0YWJsZSBmb3IgdGhlIGN1cnJlbnQNCj4+IHJ1bnRp
bWUgZW52aXJvbm1lbnQgaXMgcGF0Y2hlZCBpbiBhcyBhbiBpbnRlcm1lZGlhdGUgc3RlcC4g
SW4gY2FzZSB0aGVyZQ0KPj4gaXMgYW4gaW50ZXJydXB0IGhhcHBlbmluZyBqdXN0IHRoZW4g
QU5EIHRoZSBoYW5kbGluZyBvZiB0aGUgaW50ZXJydXB0IGlzDQo+PiB1c2luZyB0aGUgcGF0
Y2ggc2l0ZSwgdGhpcyBjb3VsZCByZXN1bHQgaW4gY3Jhc2hlcyBvciB1bmRlZmluZWQgYmVo
YXZpb3IuDQo+IA0KPiBPaCwgSSBoYWQgYXNzdW1lZCB0aGF0IExpbnV4IGRpc2FibGVzIGlu
dGVycnVwdHMgZHVyaW5nIHRoZSBwYXRjaGluZw0KPiBwcm9jZXNzLiBKdXN0IG91dCBvZiBj
dXJpb3NpdHksIHdoeSBhcmUgaW50ZXJydXB0cyBhbGxvd2VkIGluIHRoaXMgY2FzZT8NCg0K
SW50ZXJydXB0cyBhcmUgZGlzYWJsZWQgd2l0aGluIHRleHRfcG9rZV9lYXJseSgpIHdoaWxl
IHBhdGNoaW5nIGEgc2luZ2xlDQppbnN0YW5jZS4NCg0KSSBndWVzcyBrZWVwaW5nIGludGVy
cnVwdHMgZGlzYWJsZWQgZHVyaW5nIHRoZSBjb21wbGV0ZSBhcHBseV9hbHRlcm5hdGl2ZXMo
KQ0KaGFuZGxpbmcgd291bGQgcG90ZW50aWFsbHkgcmVzdWx0IGluIGEgdG9vIGxvbmcgcGVy
aW9kIHdpdGhvdXQgaGFuZGxpbmcgYW55DQppbnRlcnJ1cHRzLg0KDQoNCkp1ZXJnZW4NCg==

--------------5Uu5knDZMhxHDHh1wwEwuctw
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-----

--------------5Uu5knDZMhxHDHh1wwEwuctw--

--------------tCGUA4CXW29PV7rMp3vv2bed--

--------------STIfmqOdBFBaxqvTwNHJSgls
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/Ey8FAmhL2sUFAwAAAAAACgkQsN6d1ii/Ey8T
6wf+Lx95IbfTTKOQJFyx7WrMg/Jq+6GRUWowQjPiHr/aJ2NgIXbtQnBkykc8J89EMOvdqAW8C0Cc
bd5sVr161doZhvg+ZCIT6a65ziNnm559DTq1iXGc5k9VtqKRaooC7JJ8qvvVdAGBeCYBCTC/2UXc
MfiH8EaqL3YxPMhmEKEi5LU7LN6Ylfw93GkrpTbNu/lAMrGytCb4/rKcBMrT+steHNkWmcDqi1XB
xew917zFd74V70INHfo0/vp+Lic341GI4JJOSi1UzZ2a38QQNV8dOMG4DWvN62EipkMCNu8EkVWC
lQriuZk/bV7jOnAacKD6QzbwJVQIn9650sn/u5gBQQ==
=g6uR
-----END PGP SIGNATURE-----

--------------STIfmqOdBFBaxqvTwNHJSgls--


From xen-devel-bounces@lists.xenproject.org Fri Jun 13 08:26:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 08:26:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013904.1392094 (Exim 4.92)
	(envelope-from )
	id 1uPzkN-0004HM-3u; Fri, 13 Jun 2025 08:26:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013904.1392094; Fri, 13 Jun 2025 08:26:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uPzkN-0004HF-1O; Fri, 13 Jun 2025 08:26:47 +0000
Received: by outflank-mailman (input) for mailman id 1013904;
 Fri, 13 Jun 2025 08:26: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 1uPzkM-0004H9-GY
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 08:26:46 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 2221ee2b-4830-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 10:26:42 +0200 (CEST)
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 338E114BF;
 Fri, 13 Jun 2025 01:26:21 -0700 (PDT)
Received: from [10.57.84.117] (unknown [10.57.84.117])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 243333F66E;
 Fri, 13 Jun 2025 01:26:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2221ee2b-4830-11f0-a309-13f23c93f187
Message-ID: 
Date: Fri, 13 Jun 2025 09:26:37 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/6] mm: Lock kernel page tables before entering lazy MMU
 mode
Content-Language: en-GB
To: Alexander Gordeev ,
 Andrew Morton 
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org,
 linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org,
 Hugh Dickins , Nicholas Piggin ,
 Guenter Roeck , Juergen Gross ,
 Jeremy Fitzhardinge 
References: 
 <7bd3a45dbc375dc2c15cebae09cb2bb972d6039f.1749747752.git.agordeev@linux.ibm.com>
From: Ryan Roberts 
In-Reply-To: <7bd3a45dbc375dc2c15cebae09cb2bb972d6039f.1749747752.git.agordeev@linux.ibm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12/06/2025 18:36, Alexander Gordeev wrote:
> As a follow-up to commit 691ee97e1a9d ("mm: fix lazy mmu docs and
> usage") take a step forward and protect with a lock not only user,
> but also kernel mappings before entering the lazy MMU mode. With
> that the semantics of arch_enter|leave_lazy_mmu_mode() callbacks
> is consolidated, which allows further simplifications.
> 
> The effect of this consolidation is not fully preemptible (Real-Time)
> kernels can not enter the context switch while the lazy MMU mode is
> active - which is easier to comprehend.
> 
> Signed-off-by: Alexander Gordeev 
> ---
>  include/linux/pgtable.h | 12 ++++++------
>  mm/kasan/shadow.c       |  5 -----
>  mm/memory.c             |  5 ++++-
>  mm/vmalloc.c            |  6 ++++++
>  4 files changed, 16 insertions(+), 12 deletions(-)
> 
> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> index 0b6e1f781d86..33bf2b13c219 100644
> --- a/include/linux/pgtable.h
> +++ b/include/linux/pgtable.h
> @@ -224,12 +224,12 @@ static inline int pmd_dirty(pmd_t pmd)
>   * a raw PTE pointer after it has been modified are not guaranteed to be
>   * up to date.
>   *
> - * In the general case, no lock is guaranteed to be held between entry and exit
> - * of the lazy mode. So the implementation must assume preemption may be enabled
> - * and cpu migration is possible; it must take steps to be robust against this.
> - * (In practice, for user PTE updates, the appropriate page table lock(s) are
> - * held, but for kernel PTE updates, no lock is held). Nesting is not permitted
> - * and the mode cannot be used in interrupt context.
> + * For PREEMPT_RT kernels implementation must assume that preemption may
> + * be enabled and cpu migration is possible between entry and exit of the
> + * lazy MMU mode; it must take steps to be robust against this. There is
> + * no such assumption for non-PREEMPT_RT kernels, since both kernel and
> + * user page tables are protected with a spinlock while in lazy MMU mode.
> + * Nesting is not permitted and the mode cannot be used in interrupt context.

While I agree that spec for lazy mmu mode is not well defined, and welcome
changes to clarify and unify the implementations across arches, I think this is
a step in the wrong direction.

First the major one: you are serializing kernel pgtable operations that don't
need to be serialized. This, surely, can only lead to performance loss? vmalloc
could previously (mostly) run in parallel; The only part that was serialized was
the allocation of the VA space. Once that's done, operations on the VA space can
be done in parallel because each is only operating on the area it allocated.
With your change I think all pte operations are serialised with the single
init_mm.page_table_lock.

Additionally, some arches (inc arm64) use apply_to_page_range() to modify the
permissions of regions of kernel VA space. Again, we used to be able to modify
multiple regions in parallel, but you are now serializing this for no good reason.

Secondly, the lazy mmu handler still needs to handle the
preemption-while-in-lazy-mmu case because, as you mention, it can still be
preempted for PREEMPT_RT kernels where the spin lock is converted to a sleepable
lock.

So I think the handler needs to either explicitly disable preemption (as powerpc
and sparc do) or handle it by plugging into the arch-specific context switch
code (as x86 does) or only maintain per-task state in the first place (as arm64
does).

Thanks,
Ryan

>   */
>  #ifndef __HAVE_ARCH_ENTER_LAZY_MMU_MODE
>  #define arch_enter_lazy_mmu_mode()	do {} while (0)
> diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c
> index d2c70cd2afb1..45115bd770a9 100644
> --- a/mm/kasan/shadow.c
> +++ b/mm/kasan/shadow.c
> @@ -313,12 +313,10 @@ static int kasan_populate_vmalloc_pte(pte_t *ptep, unsigned long addr,
>  	__memset(page_to_virt(page), KASAN_VMALLOC_INVALID, PAGE_SIZE);
>  	pte = pfn_pte(page_to_pfn(page), PAGE_KERNEL);
>  
> -	spin_lock(&init_mm.page_table_lock);
>  	if (likely(pte_none(ptep_get(ptep)))) {
>  		set_pte_at(&init_mm, addr, ptep, pte);
>  		data->pages[index] = NULL;
>  	}
> -	spin_unlock(&init_mm.page_table_lock);
>  
>  	return 0;
>  }
> @@ -465,13 +463,10 @@ static int kasan_depopulate_vmalloc_pte(pte_t *ptep, unsigned long addr,
>  
>  	page = (unsigned long)__va(pte_pfn(ptep_get(ptep)) << PAGE_SHIFT);
>  
> -	spin_lock(&init_mm.page_table_lock);
> -
>  	if (likely(!pte_none(ptep_get(ptep)))) {
>  		pte_clear(&init_mm, addr, ptep);
>  		free_page(page);
>  	}
> -	spin_unlock(&init_mm.page_table_lock);
>  
>  	return 0;
>  }
> diff --git a/mm/memory.c b/mm/memory.c
> index 71b3d3f98999..1ddc532b1f13 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -3017,6 +3017,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
>  			pte = pte_offset_kernel(pmd, addr);
>  		if (!pte)
>  			return err;
> +		spin_lock(&init_mm.page_table_lock);
>  	} else {
>  		if (create)
>  			pte = pte_alloc_map_lock(mm, pmd, addr, &ptl);
> @@ -3042,7 +3043,9 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
>  
>  	arch_leave_lazy_mmu_mode();
>  
> -	if (mm != &init_mm)
> +	if (mm == &init_mm)
> +		spin_unlock(&init_mm.page_table_lock);
> +	else
>  		pte_unmap_unlock(mapped_pte, ptl);
>  
>  	*mask |= PGTBL_PTE_MODIFIED;
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index ab986dd09b6a..57b11000ae36 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -105,6 +105,7 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
>  	if (!pte)
>  		return -ENOMEM;
>  
> +	spin_lock(&init_mm.page_table_lock);
>  	arch_enter_lazy_mmu_mode();
>  
>  	do {
> @@ -132,6 +133,7 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
>  	} while (pte += PFN_DOWN(size), addr += size, addr != end);
>  
>  	arch_leave_lazy_mmu_mode();
> +	spin_unlock(&init_mm.page_table_lock);
>  	*mask |= PGTBL_PTE_MODIFIED;
>  	return 0;
>  }
> @@ -359,6 +361,7 @@ static void vunmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
>  	unsigned long size = PAGE_SIZE;
>  
>  	pte = pte_offset_kernel(pmd, addr);
> +	spin_lock(&init_mm.page_table_lock);
>  	arch_enter_lazy_mmu_mode();
>  
>  	do {
> @@ -379,6 +382,7 @@ static void vunmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
>  	} while (pte += (size >> PAGE_SHIFT), addr += size, addr != end);
>  
>  	arch_leave_lazy_mmu_mode();
> +	spin_unlock(&init_mm.page_table_lock);
>  	*mask |= PGTBL_PTE_MODIFIED;
>  }
>  
> @@ -525,6 +529,7 @@ static int vmap_pages_pte_range(pmd_t *pmd, unsigned long addr,
>  	if (!pte)
>  		return -ENOMEM;
>  
> +	spin_lock(&init_mm.page_table_lock);
>  	arch_enter_lazy_mmu_mode();
>  
>  	do {
> @@ -542,6 +547,7 @@ static int vmap_pages_pte_range(pmd_t *pmd, unsigned long addr,
>  	} while (pte++, addr += PAGE_SIZE, addr != end);
>  
>  	arch_leave_lazy_mmu_mode();
> +	spin_unlock(&init_mm.page_table_lock);
>  	*mask |= PGTBL_PTE_MODIFIED;
>  	return 0;
>  }



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 08:41:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 08:41:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013917.1392105 (Exim 4.92)
	(envelope-from )
	id 1uPzyE-000754-9B; Fri, 13 Jun 2025 08:41:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013917.1392105; Fri, 13 Jun 2025 08:41: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 1uPzyE-00074x-5l; Fri, 13 Jun 2025 08:41:06 +0000
Received: by outflank-mailman (input) for mailman id 1013917;
 Fri, 13 Jun 2025 08:41: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 1uPzyD-00074r-AJ
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 08:41:05 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id 1cc88b9e-4832-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 10:40:51 +0200 (CEST)
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 5C1C41CDD;
 Fri, 13 Jun 2025 01:40:42 -0700 (PDT)
Received: from [10.57.84.117] (unknown [10.57.84.117])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6DA213F66E;
 Fri, 13 Jun 2025 01:41:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1cc88b9e-4832-11f0-b894-0df219b8e170
Message-ID: <0ba9820d-f498-42b0-a663-6f4dca5374b4@arm.com>
Date: Fri, 13 Jun 2025 09:40:58 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 4/6] sparc/mm: Do not disable preemption in lazy MMU mode
Content-Language: en-GB
To: Alexander Gordeev ,
 Andrew Morton 
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
 sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org,
 linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org,
 Hugh Dickins , Nicholas Piggin ,
 Guenter Roeck , Juergen Gross ,
 Jeremy Fitzhardinge 
References: 
 
From: Ryan Roberts 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12/06/2025 18:36, Alexander Gordeev wrote:
> Commit a1d416bf9faf ("sparc/mm: disable preemption in lazy mmu mode")
> is not necessary anymore, since the lazy MMU mode is entered with a
> spinlock held and sparc does not support Real-Time. Thus, upon entering
> the lazy mode the preemption is already disabled.

Surely given Sparc knows that it doesn't support PREEMPT_RT, it is better for
it's implementation to explicitly disable preemption rather than rely on the
spinlock to do it, since the spinlock penalizes other arches unnecessarily? It
also prevents multiple CPUs from updating (different areas of) kernel pgtables
in parallel. The property Sparc needs is for the task to stay on the same CPU
without interruption, right? Same goes for powerpc.

> 
> Signed-off-by: Alexander Gordeev 
> ---
>  arch/sparc/include/asm/tlbflush_64.h |  2 +-
>  arch/sparc/mm/tlb.c                  | 12 ++++++++----
>  2 files changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/sparc/include/asm/tlbflush_64.h b/arch/sparc/include/asm/tlbflush_64.h
> index 8b8cdaa69272..a6d8068fb211 100644
> --- a/arch/sparc/include/asm/tlbflush_64.h
> +++ b/arch/sparc/include/asm/tlbflush_64.h
> @@ -44,7 +44,7 @@ void flush_tlb_kernel_range(unsigned long start, unsigned long end);
>  void flush_tlb_pending(void);
>  void arch_enter_lazy_mmu_mode(void);
>  void arch_leave_lazy_mmu_mode(void);
> -#define arch_flush_lazy_mmu_mode()      do {} while (0)
> +void arch_flush_lazy_mmu_mode(void);
>  
>  /* Local cpu only.  */
>  void __flush_tlb_all(void);
> diff --git a/arch/sparc/mm/tlb.c b/arch/sparc/mm/tlb.c
> index a35ddcca5e76..e46dfd5f2583 100644
> --- a/arch/sparc/mm/tlb.c
> +++ b/arch/sparc/mm/tlb.c
> @@ -52,10 +52,9 @@ void flush_tlb_pending(void)
>  
>  void arch_enter_lazy_mmu_mode(void)
>  {
> -	struct tlb_batch *tb;
> +	struct tlb_batch *tb = this_cpu_ptr(&tlb_batch);
>  
> -	preempt_disable();
> -	tb = this_cpu_ptr(&tlb_batch);
> +	VM_WARN_ON_ONCE(preemptible());
>  	tb->active = 1;
>  }
>  
> @@ -63,10 +62,15 @@ void arch_leave_lazy_mmu_mode(void)
>  {
>  	struct tlb_batch *tb = this_cpu_ptr(&tlb_batch);
>  
> +	VM_WARN_ON_ONCE(preemptible());
>  	if (tb->tlb_nr)
>  		flush_tlb_pending();
>  	tb->active = 0;
> -	preempt_enable();
> +}
> +
> +void arch_flush_lazy_mmu_mode(void)
> +{
> +	VM_WARN_ON_ONCE(preemptible());
>  }
>  
>  static void tlb_batch_add_one(struct mm_struct *mm, unsigned long vaddr,



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 08:57:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 08:57:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013931.1392115 (Exim 4.92)
	(envelope-from )
	id 1uQ0Dt-0000QQ-Iz; Fri, 13 Jun 2025 08:57:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013931.1392115; Fri, 13 Jun 2025 08:57:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uQ0Dt-0000QJ-F6; Fri, 13 Jun 2025 08:57:17 +0000
Received: by outflank-mailman (input) for mailman id 1013931;
 Fri, 13 Jun 2025 08:57: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 1uQ0Ds-0000QD-8v
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 08:57:16 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on2060e.outbound.protection.outlook.com
 [2a01:111:f403:200a::60e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5eb3e8ca-4834-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 10:57:02 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 SJ2PR12MB8977.namprd12.prod.outlook.com (2603:10b6:a03:539::20) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.19; Fri, 13 Jun
 2025 08:57: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.8835.018; Fri, 13 Jun 2025
 08:57: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: 5eb3e8ca-4834-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=rdHkdiM3JQvLiy4rEkUjrzQS/LtkuFyVApMcw1tvAZYuDzAIF5LLj11iVREPqxin0YNg31t9k6sn47O/anvUKLQGp03rLOq0YRzPRCFqp9qg6CGqt0x5RSxYuZ4EOn+SZNPorzkGm4awkLuzewr4ClXG3fjih2lEsK16JAi/FOOClvw8nAett+qkGWRiymWzNQ3QAXn9wfCiNreMd74cR505oeumpA5RWQzV8vX3JSUtIihwalnf+3VMakjraJBtgk/W71cjPCfGpP470AmYPdm0fgf+UD8JWfLE5+1hG5Wi9100se2XozKz5X+CMAp8hdtlnPav/DYqfhnSL6dalA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=nlSauoV2LjRS8KayhtQ7JOGxzqrkeuD5EDozn8s/AVw=;
 b=UGsJa62apOKQRkIMgih8jwl3BKhmSkjJteZ3DmP70LX24Y9Kg6okFXgYl3E0GcwkETjSDsrR7ih/m46YjKr6MEthDJ4v9gKuFBX2iOTNbcjuETzCmf44nETnPmLsOUvm8QycR/LHe/2AaU3PQIe04soyH47PvbmyVOfKZEnxKWM+qOCO8VYkCa3S5IeOoyWR2+uEb3mt6hqVYJjHkwo5ujiDMmTy2mB9PB+h/TMFpXBvE2ODNgu2WjrFaZZBM1oa2HMA1EF13Im+t0f1iWiMsyygVHNu8+FKsqW6k4rbmwArM9EhONmvDMhANgIi5WOWCHOEAo4dGONiRguwEnV+ow==
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=nlSauoV2LjRS8KayhtQ7JOGxzqrkeuD5EDozn8s/AVw=;
 b=FVlFWBpSWc1WAi7HKIlGMmhmKqegWaecouQCM+kqijwbcmuk7CrufbFAqDCSCl53oMp9XG4p8eWsMxDL1T4KJasldVnPtUZoukxGRJgNb2SeZ1CgGsVXeKtbbOr+s1ucUwTEmIyWx8L9dscFlEifLc8z4HOIxPwV6h+GlWdFTL4=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Stefano Stabellini
	, Andrew Cooper ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Anthony PERARD
	, "Orzel, Michal" , Julien
 Grall , "Stabellini, Stefano" ,
	Sergiy Kibrik , "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v4 20/20] xen/sysctl: wrap around sysctl hypercall
Thread-Topic: [PATCH v4 20/20] xen/sysctl: wrap around sysctl hypercall
Thread-Index: AQHbz7GB7JuzUuWzwkuFXAiKCBRn07P8fpKAgARiCjA=
Date: Fri, 13 Jun 2025 08:57:09 +0000
Message-ID:
 
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
 <20250528091708.390767-21-Penny.Zheng@amd.com>
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=True;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-06-13T08:57:02.0000000Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=3;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged
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_|SJ2PR12MB8977:EE_
x-ms-office365-filtering-correlation-id: 0429b226-5cb9-42ca-dfaf-08ddaa5847bb
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?WktJMGNNQ0hGVjdOMnkyMm44bEM0b3BPYkt6WlBlMnd5ZGZKRWVwSEF0czFq?=
 =?utf-8?B?YU1ka014OFlyNlZTMFBKK05QSkJFVzRmd0Y1bmZXVStOU0JqQ3J5Ykt0MlJB?=
 =?utf-8?B?VVBxOVNXaHJOVUF3ampwNWgrcVNOd1FWb05zazYrWThpWHJqc0xUcURmNlox?=
 =?utf-8?B?aVl0bEFUeTR2OTBTcTY0bTZqbjVITEl3UHpSblQ1QW1qblNINVlqejQ3NHk2?=
 =?utf-8?B?THVBdVUzUFdhd1dHaEhSanU3WWJoWUhHOSt2K2pBMk94ckJIVG40RXh6amVq?=
 =?utf-8?B?OTBsaGc0WlBVanJEWXArY21tcnJObmh1aXNZN0Nhd3ZQWG1CWnI4bFJGdTR6?=
 =?utf-8?B?YkhRNk9qUUZ0bERrRXg0UFBUeFdTY252TXQwbUhOamRudFhtaEZ2NG1zbi8v?=
 =?utf-8?B?NFNsMUpQV2VGanNtVC9iTStlYXdCai9OZXc1L09USXgrb2Rpd2xBdHJ5Q1Bx?=
 =?utf-8?B?N2lFL3huMSszQlBhNDZvZCsrSmt5WFRtbEt4MXI3Q1V4TW5JcmF1QXdiblU4?=
 =?utf-8?B?RDRmOHhjdWo2ajM1cGp4SzlrNWhCR2orV0JuYjM2b0t4UGRPUWVMREpuTXps?=
 =?utf-8?B?R3ZHZWE2TUYxMmNHTTVKSU14RXNCcW1TUzN6YlRJandPWUhUdjNrZUdEMlpH?=
 =?utf-8?B?ajY3N0U1RlozQmpqc1VHQ2RuTjNyclZ3eDVQVU5obUd0dVVrellFbFZFLzVT?=
 =?utf-8?B?Zm14VHBWME5BTlZqaDdaVWo3R0hMeTZHUEwyVVhrNnliaW5TaDhnT1J4ODhw?=
 =?utf-8?B?NUsrV2lxRDFPayswODZVRUVDTFhFcFdDTVlvYXV6S1R5VVdyZEdjR1Y1b0Rv?=
 =?utf-8?B?SmkrVEY1dTZsZENUVnMxdS9jQWs0OUJicUhuS2xxVUJYSnlZT0IrdDdTWTE1?=
 =?utf-8?B?STFoUnJLeFMveXVkbFhiZGFzRWh5bUhqQUlqWmtFTmFTVCtDTWJaamh4REVH?=
 =?utf-8?B?RVZjbStsSzdZKzBoQWpncWhvbGVDNVI1YW10RXVGOEpSSkF3eU9DeHpsT1Nq?=
 =?utf-8?B?ZllEaXZweURHckF1WTdVRHhSdXd6YUtia09zVTlUSkgzcXBTMDdHU0VCYWJG?=
 =?utf-8?B?dHJvZDYzRmdJQ3c2ZzRaS28zOHdIM2NLWHNlQlgvSEY1QXlpTnpqcWJxSy9t?=
 =?utf-8?B?N0N6SUNFWkh4akpUZGVVNFFnUUgrcTVvNWNzby9ra3hDVmN3TnhZcVJDZ0Vl?=
 =?utf-8?B?TjVBOW9pQUNvQ0Q5aHVKaGZFRGljMnUzUDZRQ0tYVzIzdmpLMUQ2UlFlMmpD?=
 =?utf-8?B?ci8wcjhkWVV5RFYwRjMvMEJaZUNHa3E4V2xPdUlRTFNQY2JITVBNSVZrc3Zv?=
 =?utf-8?B?dWh3azczSWExN1RscU1Wejdud3JjcVJTR3FvWHlleEc0dDV4TGpWS0JNVUYy?=
 =?utf-8?B?VUV0ZEFwdGVMaXpmUUJLTUtzYlk5cW9EYUFyM0NEc0VUZEdETmxza2VDQms1?=
 =?utf-8?B?b2pUVmRPYXRjUEdWaHM4ZE51MU1nZ2hBaThteDlVUU5HaGFRWG4zbWpMU0V5?=
 =?utf-8?B?b3E2b0FWb00yTjVFYlBrV29PbmxpYi96dm5XbGcxdnhwMGovOXluZTgzdVR1?=
 =?utf-8?B?eUFBODJvL0VyTTljUUxFdklHc09HWlIxYWNzK2ZWZ05QRVRpcnNQZ1ZzVzhP?=
 =?utf-8?B?QitvVVRDWW12ek1MVjBNMHptRnh3SktDMTl5SGVjckV3YUZsVno4SVZqcW14?=
 =?utf-8?B?aFo4Mld5NTgzMDFOTWI5MXFQaTA0NFVmVUhBdXAwcnZZTFUrVGtodUl2WXZx?=
 =?utf-8?B?YlhycTRMQlJSNkpLemI0ZEpZZjBSQ1hEa1RlcnpVNDV4Yy9DRFNLTDEwZmdr?=
 =?utf-8?B?cXhEY1ZMcjVWMzhaeUdmUGl2ZTFCMGNoSUdxRWxIbk4zMUdmbVJCZ29GRFlB?=
 =?utf-8?B?WndIcVJnMFhrem5Od09QazNsRTloQ0R2bkZ2MFhZZUlsOWJybHh3enRJaExP?=
 =?utf-8?B?TXl3elhPUU55SVpCcmdyOHB0TUR4YkVGL01lRzNkYXlPUmQrYVJjQ3BUTEpO?=
 =?utf-8?Q?Twgcf3e1YhlIxbMoPYrN3uNKoWDT0w=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)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?NVFtaEFhblQrQnZaSWJWSG9Jei9UVUtQMkl0a3h0c041R0pYUDZ5d3l2dWZr?=
 =?utf-8?B?Y05IT1BDQlhBazZrb1E5czB0TXBNY0xOY0RuandlWVVYamxGTkdIRDFnMG1H?=
 =?utf-8?B?Sm1ZZnFnS1dCVUV2eENyd3FzaXl5dkoxaEV6R0FLMHlZZk9oTy9VM2pBWXBP?=
 =?utf-8?B?UXRqVnp0U0ZkUkhCMUZmdFRYbjNpRjd0aUp1bTVzSWtKa0o5UXZCWkpDbGly?=
 =?utf-8?B?cVhPWU9acVNsZ0V0aXIwa0dTb2dBRnkvTG1JM2JtQUxwY09JSXVrRXJkNzlK?=
 =?utf-8?B?R2ozNVA0SkpjRU9VNWxJQnY5bEo0bXJYYlRjRlhuOW5SS2U0OUd1R3FXSUsz?=
 =?utf-8?B?eWlLdHltTVliRkIycm11TGFmSmZIaHBGdHhHZlJCemVXNHdWeDlBenlYdnR3?=
 =?utf-8?B?WDdoZ3dUQXVCaUM2THF5eTZiWG0wd0ZUN29tSmo0WnFpSklUeUU0anJaR2Vp?=
 =?utf-8?B?V25rdWRvcW5TZmRUVnFrcEJ1WkplM2lZTHNGUTRqSHBReGJtZjVmcTN5WUEz?=
 =?utf-8?B?N1ZSVnVjbVh6NjVEL1VLZkR4bm1tZFVjMnk4eUF4YjNzSlJjRTFVMWZVb2pU?=
 =?utf-8?B?dER4RTJxbEJtL25WMGtldlc0emFOMjM3ZmZsaG12UE00R1huV0R0TU9zUWEy?=
 =?utf-8?B?WkNsSC9kMWRJZHh6WFhyYTVTNzM3QmtSWFl1UTd4U2RBaEc5cDJhZFAvNDU2?=
 =?utf-8?B?cE5BZXpNTGlLTGlCbnczd2o1UGRhaXBzdWYyS0k1N1pRSTErc0NmZFJiU0JU?=
 =?utf-8?B?WE85T3VxRHpUWkZ2V3M2TEFReUJvZmtmTHJNSlc0d3F1b0ZWVkt3VWdvUWFY?=
 =?utf-8?B?eGg2cjQxVXBoRGplTXJva0dtMlN6R2M3VmdJVnBrbWVjQWVwRG5WRkhmRWtx?=
 =?utf-8?B?MGF6M21kSXVpckd3cjJ5L25uc00ybkE2N3VWVDEzOGRoRVFJekI5akxhc0V5?=
 =?utf-8?B?TlN0RWZ3VjZ2TS9SUnpzOEo1RjI3TzVOTzU0cFc4eEhxZGpLWEVFUUZ4c3lv?=
 =?utf-8?B?OVluSlowRjVJZjF4TU43SDV6NHNpN3AvMkJyeEhDTkg5R2hiQ0RnWnlnb1dO?=
 =?utf-8?B?S1Y5a1gveWtPWGNvYXlRTlk4bnllQy9acE5kREF4UjZIOGh6ZWYxTzR1UE5n?=
 =?utf-8?B?WE43VFdsa0JKMVRSaVZRbGZJQ3ZKVHNQYUlmeEVDcWVlQ2FialBtL0xZeHZU?=
 =?utf-8?B?cDVQWmF0d3lIdjVJUkdkaDE1NUUwem1rVzBVZG9mcitMeDg1ZjlKNjdmWExJ?=
 =?utf-8?B?RVl3aUpkRnp3Q3ErQncwcENFKzRrL29pN3lsQXpITm51TW9lQ0pULzB2SDZL?=
 =?utf-8?B?cllIVnF3YTJEWUxhL1l3RDRCcnd1UFRPRjlWVTNVZHJONGR5WEtZTGJ4NDl4?=
 =?utf-8?B?UnNaRjFndmxMVUNNVTBpMGwxRFdmVlYwRC91dml5bi9BeUc3UHUvY2VUUHdL?=
 =?utf-8?B?Wk50aEkrejFJNElTTjFoNGJmTGFxU0ptQld5aHlKSzkyb0ZmUzZtUjE0YkY1?=
 =?utf-8?B?SmhCbnZaZGhQZnRpUytzdDRJN2VDd0lubDZlcG9jcWozUWpaZ0hRUDI0UTJs?=
 =?utf-8?B?SzRsMG1wcWFieFFOSGZkenlVU2tKYlg3Mm1CUnJrellPN0RBbmRXNEM3MjhC?=
 =?utf-8?B?M2NtWTJTNjNVT1RQRnF4WTlKQUdsaFlXZ3Fsd1FHWTJMRTBJYnpHMHhkV1ZJ?=
 =?utf-8?B?WmlmdTVxeEZkbzk2SUlqUER3N1BlS1ByNm9YZGhiNm5mVWVFNGZteGdNMXE2?=
 =?utf-8?B?bnJqVDNwTktiYnBLcXV2TS8vSFZab3JPbFBFZkJhZ2k3VHFyUWEyWEpySUMy?=
 =?utf-8?B?cFhvNFZPcHl4YXBmVElvRlp1MmFleGlZMG5FU3Q4RzRRYTBBVklFR1h6SzA0?=
 =?utf-8?B?bjFSV1VuUUZNdno5QWJKUEN0WHBaZ2lRRG0vaFZUQlNtY2pqVkpCMjlGdld4?=
 =?utf-8?B?K21GU05WNDZ3K05sa1JVVldtSksreGRwemY5SUh0ZHFVeTdwS2h6WkRBSlFT?=
 =?utf-8?B?dUdERjFsQjlaQ0h4am5MTDZuSjFtY0ZLYnJHZmh6SDFUdC8ybThhRjh4MzlO?=
 =?utf-8?B?SWl2RmovRHZreFBZaUJCdERSUlU3eCtFTjlyZ3htdmplNmRCVFVRT0E4WS9P?=
 =?utf-8?Q?OAug=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: 0429b226-5cb9-42ca-dfaf-08ddaa5847bb
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2025 08:57:09.3349
 (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: +dUKpezUfg8MXdDBwsBlhttPxJ+3asq06YSrBlXx3SJGOIbIRv14JE63+Bx/udreTwE2oJ5by0F2qVO8AxQdzQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB8977

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFR1ZXNkYXksIEp1bmUgMTAsIDIwMjUg
OTo1MyBQTQ0KPiBUbzogUGVubnksIFpoZW5nIDxwZW5ueS56aGVuZ0BhbWQuY29tPg0KPiBDYzog
SHVhbmcsIFJheSA8UmF5Lkh1YW5nQGFtZC5jb20+OyBTdGVmYW5vIFN0YWJlbGxpbmkNCj4gPHNz
dGFiZWxsaW5pQGtlcm5lbC5vcmc+OyBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRy
aXguY29tPjsgUm9nZXINCj4gUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+OyBBbnRo
b255IFBFUkFSRA0KPiA8YW50aG9ueS5wZXJhcmRAdmF0ZXMudGVjaD47IE9yemVsLCBNaWNoYWwg
PE1pY2hhbC5PcnplbEBhbWQuY29tPjsgSnVsaWVuDQo+IEdyYWxsIDxqdWxpZW5AeGVuLm9yZz47
IFN0YWJlbGxpbmksIFN0ZWZhbm8gPHN0ZWZhbm8uc3RhYmVsbGluaUBhbWQuY29tPjsgU2VyZ2l5
DQo+IEtpYnJpayA8U2VyZ2l5X0tpYnJpa0BlcGFtLmNvbT47IHhlbi1kZXZlbEBsaXN0cy54ZW5w
cm9qZWN0Lm9yZw0KPiBTdWJqZWN0OiBSZTogW1BBVENIIHY0IDIwLzIwXSB4ZW4vc3lzY3RsOiB3
cmFwIGFyb3VuZCBzeXNjdGwgaHlwZXJjYWxsDQo+DQo+IE9uIDI4LjA1LjIwMjUgMTE6MTcsIFBl
bm55IFpoZW5nIHdyb3RlOg0KPiA+IEZyb206IFN0ZWZhbm8gU3RhYmVsbGluaSA8c3N0YWJlbGxp
bmlAa2VybmVsLm9yZz4NCj4gPg0KPiA+IFdyYXAgc3lzY3RsIGh5cGVyY2FsbCBkZWYgYW5kIHN5
c2N0bC5vIHdpdGggQ09ORklHX1NZU0NUTCwgYW5kIHNpbmNlDQo+ID4gUFZfU0hJTV9FWENMVVNJ
VkUgbmVlZHMgc29ydGluZyBpbiB0aGUgZnV0dXJlLCB3ZSBtb3ZlIHRoZW0gb3V0IG9mDQo+ID4g
UFZfU0hJTV9FWENMVVNJVkUgY29uZGl0aW9uIGF0IHRoZSBzYW1lIHRpbWUuDQo+ID4NCj4gPiBX
ZSBuZWVkIHRvIG1ha2UgU1lTQ1RMIHdpdGggcHJvbXB0IGJhY2sgYW5kIHN0YXRlIHVuc2V0dGlu
ZyBTWVNDVEwgaW4NCj4gPiBwdnNoaW1fZGVmY29uZmlnIHRvIGV4cGxpY2l0bHkgbWFrZSBpdCB1
bmF2YWlsYWJsZSBmb3IgUFYgc2hpbS4NCj4NCj4gSSdtIHN0cnVnZ2xpbmcgd2l0aCB0aGlzIHNl
bnRlbmNlLiBidXQgbmV2ZXJ0aGVsZXNzIGl0IHNlZW1zIHByZXR0eSBjbGVhciB0aGF0IHdoYXQN
Cj4gdGhlIGxhdHRlciBoYWxmIG9mIHRoZSBzZW50ZW5jZSBzYXlzIGlzIG5vdCB0aGUgZWZmZWN0
IG9mIC4uLg0KDQpIb3cgYWJvdXQg4oCcDQpXZSBzaGFsbCBhZGQgIiNDT05GSUdfU1lTQ1RMIGlz
IG5vdCBzZXQiIGluIHB2c2hpbV9kZWZjb25maWcgdG8gYXQgbGVhc3QgcHJvdmlkZQ0KY29ycmVj
dCBwcmVzZXQgZm9yIFBWIHNoaW0NCiINCg0KPg0KPiA+IC0tLSBhL3hlbi9hcmNoL3g4Ni9jb25m
aWdzL3B2c2hpbV9kZWZjb25maWcNCj4gPiArKysgYi94ZW4vYXJjaC94ODYvY29uZmlncy9wdnNo
aW1fZGVmY29uZmlnDQo+ID4gQEAgLTMxLDMgKzMxLDQgQEAgQ09ORklHX0VYUEVSVD15DQo+ID4g
ICMgSFlQRVJWX0hZUEVSVl9HVUVTVCBpcyBub3Qgc2V0DQo+ID4gICMgQ09ORklHX0hWTSBpcyBu
b3Qgc2V0DQo+ID4gICMgQ09ORklHX1ZHQSBpcyBub3Qgc2V0DQo+ID4gKyMgQ09ORklHX1NZU0NU
TCBpcyBub3Qgc2V0DQo+DQo+IC4uLiB0aGlzIGNoYW5nZS4gVGhlIG9wdGlvbiBpcyBzdGlsbCBn
b2luZyB0byBiZSBhdmFpbGFibGU7IGl0J3MganVzdCB0aGF0IHRoZSBwcmVzZXQgaXMgIm9mZiIN
Cj4gbm93Lg0KPg0KPiBKYW4NCg==


From xen-devel-bounces@lists.xenproject.org Fri Jun 13 09:04:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 09:04:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013941.1392136 (Exim 4.92)
	(envelope-from )
	id 1uQ0L2-0002PT-KG; Fri, 13 Jun 2025 09:04:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013941.1392136; Fri, 13 Jun 2025 09:04: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 1uQ0L2-0002PK-Ft; Fri, 13 Jun 2025 09:04:40 +0000
Received: by outflank-mailman (input) for mailman id 1013941;
 Fri, 13 Jun 2025 09: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 1uQ0L0-0002BZ-Gw
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 09:04:38 +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 6e808dd8-4835-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 11:04:37 +0200 (CEST)
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 0A00521268;
 Fri, 13 Jun 2025 09:04:37 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 785D713A9C;
 Fri, 13 Jun 2025 09:04:36 +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 qH36G6TpS2inNAAAD6G6ig
 (envelope-from ); Fri, 13 Jun 2025 09: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" 
X-Inumbo-ID: 6e808dd8-4835-11f0-a309-13f23c93f187
Authentication-Results: smtp-out1.suse.de;
	none
From: Thomas Zimmermann 
To: simona@ffwll.ch,
	airlied@gmail.com,
	mripard@kernel.org,
	maarten.lankhorst@linux.intel.com,
	geert@linux-m68k.org,
	tomi.valkeinen@ideasonboard.com
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann 
Subject: [PATCH v5 01/25] drm/dumb-buffers: Sanitize output on errors
Date: Fri, 13 Jun 2025 11:00:20 +0200
Message-ID: <20250613090431.127087-2-tzimmermann@suse.de>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250613090431.127087-1-tzimmermann@suse.de>
References: <20250613090431.127087-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Spam-Level: 
X-Spamd-Result: default: False [-4.00 / 50.00];
	REPLY(-4.00)[]
X-Spam-Flag: NO
X-Rspamd-Queue-Id: 0A00521268
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Action: no action
X-Spam-Score: -4.00

The ioctls MODE_CREATE_DUMB and MODE_MAP_DUMB return results into a
memory buffer supplied by user space. On errors, it is possible that
intermediate values are being returned. The exact semantics depends
on the DRM driver's implementation of these ioctls. Although this is
most-likely not a security problem in practice, avoid any uncertainty
by clearing the memory to 0 on errors.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Tomi Valkeinen 
---
 drivers/gpu/drm/drm_dumb_buffers.c | 40 ++++++++++++++++++++++--------
 1 file changed, 29 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_dumb_buffers.c b/drivers/gpu/drm/drm_dumb_buffers.c
index 70032bba1c97..9916aaf5b3f2 100644
--- a/drivers/gpu/drm/drm_dumb_buffers.c
+++ b/drivers/gpu/drm/drm_dumb_buffers.c
@@ -99,7 +99,30 @@ int drm_mode_create_dumb(struct drm_device *dev,
 int drm_mode_create_dumb_ioctl(struct drm_device *dev,
 			       void *data, struct drm_file *file_priv)
 {
-	return drm_mode_create_dumb(dev, data, file_priv);
+	struct drm_mode_create_dumb *args = data;
+	int err;
+
+	err = drm_mode_create_dumb(dev, args, file_priv);
+	if (err) {
+		args->handle = 0;
+		args->pitch = 0;
+		args->size = 0;
+	}
+	return err;
+}
+
+static int drm_mode_mmap_dumb(struct drm_device *dev, struct drm_mode_map_dumb *args,
+			      struct drm_file *file_priv)
+{
+	if (!dev->driver->dumb_create)
+		return -ENOSYS;
+
+	if (dev->driver->dumb_map_offset)
+		return dev->driver->dumb_map_offset(file_priv, dev, args->handle,
+						    &args->offset);
+	else
+		return drm_gem_dumb_map_offset(file_priv, dev, args->handle,
+					       &args->offset);
 }
 
 /**
@@ -120,17 +143,12 @@ int drm_mode_mmap_dumb_ioctl(struct drm_device *dev,
 			     void *data, struct drm_file *file_priv)
 {
 	struct drm_mode_map_dumb *args = data;
+	int err;
 
-	if (!dev->driver->dumb_create)
-		return -ENOSYS;
-
-	if (dev->driver->dumb_map_offset)
-		return dev->driver->dumb_map_offset(file_priv, dev,
-						    args->handle,
-						    &args->offset);
-	else
-		return drm_gem_dumb_map_offset(file_priv, dev, args->handle,
-					       &args->offset);
+	err = drm_mode_mmap_dumb(dev, args, file_priv);
+	if (err)
+		args->offset = 0;
+	return err;
 }
 
 int drm_mode_destroy_dumb(struct drm_device *dev, u32 handle,
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 09:04:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 09:04:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013940.1392125 (Exim 4.92)
	(envelope-from )
	id 1uQ0L1-0002Br-Bx; Fri, 13 Jun 2025 09:04:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013940.1392125; Fri, 13 Jun 2025 09: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 1uQ0L1-0002Bk-8J; Fri, 13 Jun 2025 09:04:39 +0000
Received: by outflank-mailman (input) for mailman id 1013940;
 Fri, 13 Jun 2025 09: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 1uQ0Kz-0002BZ-S7
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 09:04:38 +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 6e3d653c-4835-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 11:04:37 +0200 (CEST)
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 701A11F7ED;
 Fri, 13 Jun 2025 09:04:36 +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 D952B137FE;
 Fri, 13 Jun 2025 09:04: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 wChmM6PpS2inNAAAD6G6ig
 (envelope-from ); Fri, 13 Jun 2025 09:04: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: 6e3d653c-4835-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749805476; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding;
	bh=Cognuam3Nnn8rKlVmxnaH2SIEYJ0L+O3m38UIjpzf1M=;
	b=JhYaXkf9do51n73K/iLjwm7nHC8S7e0nVK1s9v8I2ZPmxjZn721KsstV88tf9wJmTOsXbb
	2KSW12/Rn//21FJ+NeV88eAvBKYN+ToELXufuiXJKkobpFBeFpV8GH66wBEUyaHD/7WS8X
	cf1jjBzCCWoTtf3FZv+F3DeeSh9sTx0=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749805476;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding;
	bh=Cognuam3Nnn8rKlVmxnaH2SIEYJ0L+O3m38UIjpzf1M=;
	b=EijQ9W4UcJFKx0GFiMCASsmN7Bv/B+ijlMOYEwmeXGmGWmaJAc8vhRIQ+b3eQnupw9Sp9L
	6+hx9rNfI1eQjNDg==
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749805476; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding;
	bh=Cognuam3Nnn8rKlVmxnaH2SIEYJ0L+O3m38UIjpzf1M=;
	b=JhYaXkf9do51n73K/iLjwm7nHC8S7e0nVK1s9v8I2ZPmxjZn721KsstV88tf9wJmTOsXbb
	2KSW12/Rn//21FJ+NeV88eAvBKYN+ToELXufuiXJKkobpFBeFpV8GH66wBEUyaHD/7WS8X
	cf1jjBzCCWoTtf3FZv+F3DeeSh9sTx0=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749805476;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding;
	bh=Cognuam3Nnn8rKlVmxnaH2SIEYJ0L+O3m38UIjpzf1M=;
	b=EijQ9W4UcJFKx0GFiMCASsmN7Bv/B+ijlMOYEwmeXGmGWmaJAc8vhRIQ+b3eQnupw9Sp9L
	6+hx9rNfI1eQjNDg==
From: Thomas Zimmermann 
To: simona@ffwll.ch,
	airlied@gmail.com,
	mripard@kernel.org,
	maarten.lankhorst@linux.intel.com,
	geert@linux-m68k.org,
	tomi.valkeinen@ideasonboard.com
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann 
Subject: [PATCH v5 00/25] drm/dumb-buffers: Fix and improve buffer-size calculation
Date: Fri, 13 Jun 2025 11:00:19 +0200
Message-ID: <20250613090431.127087-1-tzimmermann@suse.de>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-1.80 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FREEMAIL_TO(0.00)[ffwll.ch,gmail.com,kernel.org,linux.intel.com,linux-m68k.org,ideasonboard.com];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWELVE(0.00)[21];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FREEMAIL_ENVRCPT(0.00)[gmail.com];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	URIBL_BLOCKED(0.00)[suse.de:mid];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:mid]
X-Spam-Level: 
X-Spam-Flag: NO
X-Spam-Score: -1.80

Dumb-buffer pitch and size is specified by width, height, bits-per-pixel
plus various hardware-specific alignments. The calculation of these
values is inconsistent and duplicated among drivers. The results for
formats with bpp < 8 are sometimes incorrect.

This series fixes this for most drivers. Default scanline pitch and
buffer size are now calculated with the existing 4CC helpers. There is
a new helper drm_mode_size_dumb() that calculates scanline pitch and
buffer size according to driver requirements.

The series fixes the common GEM implementations for DMA, SHMEM and
VRAM. It further changes most implementations of dumb_create to use
the new helper. A small number of drivers has more complicated
calculations and will be updated by a later patches.

v5:
- use check_mul_overflow() for overflow test (Tomi)
- imx: fix intermediate code (Tomi)
- rz-du: include dumb-buffers header
v4:
- improve UAPI documentation
- document bpp special cases
- use drm_warn_once()
- add TODO lists
- armada: fix pitch alignment
v3:
- document UAPI semantics
- fall back to bpp-based allocation for unknown color modes
- cleanups
v2:
- rewrite series
- convert many individual drivers besides the shared GEM helpers

Thomas Zimmermann (25):
  drm/dumb-buffers: Sanitize output on errors
  drm/dumb-buffers: Provide helper to set pitch and size
  drm/gem-dma: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/gem-shmem: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/gem-vram: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/armada: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/exynos: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/gma500: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/hibmc: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/imx/ipuv3: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/loongson: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/mediatek: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/msm: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/nouveau: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/omapdrm: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/qxl: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/renesas/rcar-du: Compute dumb-buffer sizes with
    drm_mode_size_dumb()
  drm/renesas/rz-du: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/rockchip: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/tegra: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/virtio: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/vmwgfx: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/xe: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/xen: Compute dumb-buffer sizes with drm_mode_size_dumb()
  drm/xlnx: Compute dumb-buffer sizes with drm_mode_size_dumb()

 Documentation/gpu/todo.rst                    |  27 +++
 drivers/gpu/drm/armada/armada_gem.c           |  16 +-
 drivers/gpu/drm/drm_dumb_buffers.c            | 170 ++++++++++++++++--
 drivers/gpu/drm/drm_gem_dma_helper.c          |   7 +-
 drivers/gpu/drm/drm_gem_shmem_helper.c        |  16 +-
 drivers/gpu/drm/drm_gem_vram_helper.c         |  89 +++------
 drivers/gpu/drm/exynos/exynos_drm_gem.c       |   8 +-
 drivers/gpu/drm/gma500/gem.c                  |  21 +--
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c   |  25 ++-
 drivers/gpu/drm/imx/ipuv3/imx-drm-core.c      |  29 ++-
 drivers/gpu/drm/loongson/lsdc_gem.c           |  29 +--
 drivers/gpu/drm/mediatek/mtk_gem.c            |  13 +-
 drivers/gpu/drm/msm/msm_gem.c                 |  27 ++-
 drivers/gpu/drm/nouveau/nouveau_display.c     |   7 +-
 drivers/gpu/drm/omapdrm/omap_gem.c            |  15 +-
 drivers/gpu/drm/qxl/qxl_dumb.c                |  17 +-
 drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c |   7 +-
 drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c  |   8 +-
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c   |  12 +-
 drivers/gpu/drm/tegra/gem.c                   |   8 +-
 drivers/gpu/drm/virtio/virtgpu_gem.c          |  11 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c       |  21 +--
 drivers/gpu/drm/xe/xe_bo.c                    |   8 +-
 drivers/gpu/drm/xen/xen_drm_front.c           |   7 +-
 drivers/gpu/drm/xlnx/zynqmp_kms.c             |   7 +-
 include/drm/drm_dumb_buffers.h                |  14 ++
 include/drm/drm_gem_vram_helper.h             |   6 -
 include/uapi/drm/drm_mode.h                   |  50 +++++-
 28 files changed, 447 insertions(+), 228 deletions(-)
 create mode 100644 include/drm/drm_dumb_buffers.h


base-commit: 75238c32deae15ee4120b42a5be556ec36807a84
prerequisite-patch-id: c67e5d886a47b7d0266d81100837557fda34cb24
prerequisite-patch-id: a5a973e527c88a5b47053d7a72aefe0b550197cb
prerequisite-patch-id: 719d09751d38f5da743beed6266585ee063e1e29
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 09:04:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 09:04:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013942.1392144 (Exim 4.92)
	(envelope-from )
	id 1uQ0L4-0002eI-Pe; Fri, 13 Jun 2025 09:04:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013942.1392144; Fri, 13 Jun 2025 09:04: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 1uQ0L4-0002eB-Mt; Fri, 13 Jun 2025 09:04:42 +0000
Received: by outflank-mailman (input) for mailman id 1013942;
 Fri, 13 Jun 2025 09:04: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 1uQ0L3-0002BZ-4f
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 09:04:41 +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 7080979d-4835-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 11:04:40 +0200 (CEST)
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 C36EB21269;
 Fri, 13 Jun 2025 09:04: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 3A50C137FE;
 Fri, 13 Jun 2025 09:04: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 sFLXDKbpS2inNAAAD6G6ig
 (envelope-from ); Fri, 13 Jun 2025 09:04: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: 7080979d-4835-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749805478; 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=EvJWMBPNIKMb/FDBP5mOyHtRRzsRa/B2S8p/joEcNxg=;
	b=Of18GEUYQmNMfePX3aYsd1MA0QOLQuOHflm8Gg5XloteOgwHASUW+X/ZVrQErxNO+daqvn
	MqkjKM6CZhLBk8N4LekwkPIiVV1iD8LsnIcc+/vdyWmapQClKfVeq1LRZL0IyHbqraKeby
	TSw5i7Nbe0nNp0ddmMU5N4c/Q/mdbj4=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749805478;
	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=EvJWMBPNIKMb/FDBP5mOyHtRRzsRa/B2S8p/joEcNxg=;
	b=H6V5QIp7SvcMgjXyb9zFHVhDnMLISCiOa8buZ7DRfjmWbXeTbAPPnvUurvQdmqDBDVtqYO
	GT3vSIMifNaT//CA==
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749805478; 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=EvJWMBPNIKMb/FDBP5mOyHtRRzsRa/B2S8p/joEcNxg=;
	b=Of18GEUYQmNMfePX3aYsd1MA0QOLQuOHflm8Gg5XloteOgwHASUW+X/ZVrQErxNO+daqvn
	MqkjKM6CZhLBk8N4LekwkPIiVV1iD8LsnIcc+/vdyWmapQClKfVeq1LRZL0IyHbqraKeby
	TSw5i7Nbe0nNp0ddmMU5N4c/Q/mdbj4=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749805478;
	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=EvJWMBPNIKMb/FDBP5mOyHtRRzsRa/B2S8p/joEcNxg=;
	b=H6V5QIp7SvcMgjXyb9zFHVhDnMLISCiOa8buZ7DRfjmWbXeTbAPPnvUurvQdmqDBDVtqYO
	GT3vSIMifNaT//CA==
From: Thomas Zimmermann 
To: simona@ffwll.ch,
	airlied@gmail.com,
	mripard@kernel.org,
	maarten.lankhorst@linux.intel.com,
	geert@linux-m68k.org,
	tomi.valkeinen@ideasonboard.com
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann 
Subject: [PATCH v5 04/25] drm/gem-shmem: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Fri, 13 Jun 2025 11:00:23 +0200
Message-ID: <20250613090431.127087-5-tzimmermann@suse.de>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250613090431.127087-1-tzimmermann@suse.de>
References: <20250613090431.127087-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-5.30 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-0.999];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_TO(0.00)[ffwll.ch,gmail.com,kernel.org,linux.intel.com,linux-m68k.org,ideasonboard.com];
	MIME_TRACE(0.00)[0:+];
	TO_DN_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[21];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	RCVD_TLS_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	R_RATELIMIT(0.00)[to_ip_from(RLqirfcw6gnbcr9a9yhi49fhi6)];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	URIBL_BLOCKED(0.00)[suse.de:email,suse.de:mid];
	RCVD_COUNT_TWO(0.00)[2];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:email,suse.de:mid];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Spam-Level: 
X-Spam-Flag: NO
X-Spam-Score: -5.30

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 8.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/drm_gem_shmem_helper.c | 16 +++++-----------
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 8ac0b1fa5287..0fc09484dfa6 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -518,18 +519,11 @@ EXPORT_SYMBOL_GPL(drm_gem_shmem_purge_locked);
 int drm_gem_shmem_dumb_create(struct drm_file *file, struct drm_device *dev,
 			      struct drm_mode_create_dumb *args)
 {
-	u32 min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
+	int ret;
 
-	if (!args->pitch || !args->size) {
-		args->pitch = min_pitch;
-		args->size = PAGE_ALIGN(args->pitch * args->height);
-	} else {
-		/* ensure sane minimum values */
-		if (args->pitch < min_pitch)
-			args->pitch = min_pitch;
-		if (args->size < args->pitch * args->height)
-			args->size = PAGE_ALIGN(args->pitch * args->height);
-	}
+	ret = drm_mode_size_dumb(dev, args, SZ_8, 0);
+	if (ret)
+		return ret;
 
 	return drm_gem_shmem_create_with_handle(file, dev, args->size, &args->handle);
 }
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 09:04:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 09:04:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013943.1392156 (Exim 4.92)
	(envelope-from )
	id 1uQ0L6-0002tc-33; Fri, 13 Jun 2025 09:04:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013943.1392156; Fri, 13 Jun 2025 09:04: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 1uQ0L5-0002tO-UF; Fri, 13 Jun 2025 09:04:43 +0000
Received: by outflank-mailman (input) for mailman id 1013943;
 Fri, 13 Jun 2025 09: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 1uQ0L4-0002e2-OG
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 09:04:42 +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 699dbd89-4835-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 11:04:29 +0200 (CEST)
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 9882A1F863;
 Fri, 13 Jun 2025 09:04:37 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 12DC4137FE;
 Fri, 13 Jun 2025 09:04:37 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id sND+AqXpS2inNAAAD6G6ig
 (envelope-from ); Fri, 13 Jun 2025 09:04: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: 699dbd89-4835-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749805477; 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=9vrE958rjluy5GI9nSZtajZKau2LVUydgX9T0Pgwru0=;
	b=B7SOGyWTBIJl0U7KAZgyscWeBjgjCMs2Jhf4Aw7cP02t3rVbQFZ5Nx4gtmaw3vKKM3l6pW
	SBiBTnrRIei4pfaHnf5Vu5Gqf1WcyJS3GjiUVnZyhbYSzH85I72hoz7tMFmCNEpPG96br3
	/WvM33n4CDTSCFb89/cFcVR5i0CWDiQ=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749805477;
	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=9vrE958rjluy5GI9nSZtajZKau2LVUydgX9T0Pgwru0=;
	b=G5UsLMt3A0xlxF+srO3jbYALvYG7FkC1mJSP6zh42VpZ6Az6mzAy/lkhzjhcnNMVHf9H4F
	3ZoR+WZF471tO8DQ==
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749805477; 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=9vrE958rjluy5GI9nSZtajZKau2LVUydgX9T0Pgwru0=;
	b=B7SOGyWTBIJl0U7KAZgyscWeBjgjCMs2Jhf4Aw7cP02t3rVbQFZ5Nx4gtmaw3vKKM3l6pW
	SBiBTnrRIei4pfaHnf5Vu5Gqf1WcyJS3GjiUVnZyhbYSzH85I72hoz7tMFmCNEpPG96br3
	/WvM33n4CDTSCFb89/cFcVR5i0CWDiQ=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749805477;
	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=9vrE958rjluy5GI9nSZtajZKau2LVUydgX9T0Pgwru0=;
	b=G5UsLMt3A0xlxF+srO3jbYALvYG7FkC1mJSP6zh42VpZ6Az6mzAy/lkhzjhcnNMVHf9H4F
	3ZoR+WZF471tO8DQ==
From: Thomas Zimmermann 
To: simona@ffwll.ch,
	airlied@gmail.com,
	mripard@kernel.org,
	maarten.lankhorst@linux.intel.com,
	geert@linux-m68k.org,
	tomi.valkeinen@ideasonboard.com
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann 
Subject: [PATCH v5 02/25] drm/dumb-buffers: Provide helper to set pitch and size
Date: Fri, 13 Jun 2025 11:00:21 +0200
Message-ID: <20250613090431.127087-3-tzimmermann@suse.de>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250613090431.127087-1-tzimmermann@suse.de>
References: <20250613090431.127087-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Flag: NO
X-Spam-Score: -5.30
X-Spamd-Result: default: False [-5.30 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-0.999];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_TO(0.00)[ffwll.ch,gmail.com,kernel.org,linux.intel.com,linux-m68k.org,ideasonboard.com];
	MIME_TRACE(0.00)[0:+];
	TO_DN_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[21];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	R_RATELIMIT(0.00)[to_ip_from(RLqirfcw6gnbcr9a9yhi49fhi6)];
	RCVD_TLS_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[ideasonboard.com:email,suse.de:mid,suse.de:email];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Spam-Level: 

Add drm_modes_size_dumb(), a helper to calculate the dumb-buffer
scanline pitch and allocation size. Implementations of struct
drm_driver.dumb_create can call the new helper for their size
computations.

There is currently quite a bit of code duplication among DRM's
memory managers. Each calculates scanline pitch and buffer size
from the given arguments, but the implementations are inconsistent
in how they treat alignment and format support. Later patches will
unify this code on top of drm_mode_size_dumb() as much as possible.

drm_mode_size_dumb() uses existing 4CC format helpers to interpret
the given color mode. This makes the dumb-buffer interface behave
similar the kernel's video= parameter. Current per-driver implementations
again likely have subtle differences or bugs in how they support color
modes.

The dumb-buffer UAPI is only specified for known color modes. These
values describe linear, single-plane RGB color formats or legacy index
formats. Other values should not be specified. But some user space
still does. So for unknown color modes, there are a number of known
exceptions for which drm_mode_size_dumb() calculates the pitch from
the bpp value, as before. All other values work the same but print
an error.

v5:
- check for overflows with check_mul_overflow() (Tomi)
v4:
- use %u conversion specifier (Geert)
- list DRM_FORMAT_Dn in UAPI docs (Geert)
- avoid dmesg spamming with drm_warn_once() (Sima)
- add more information about bpp special case (Sima)
- clarify parameters for hardware alignment
- add a TODO item for DUMB_CREATE2
v3:
- document the UAPI semantics
- compute scanline pitch from for unknown color modes (Andy, Tomi)

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Tomi Valkeinen 
---
 Documentation/gpu/todo.rst         |  27 ++++++
 drivers/gpu/drm/drm_dumb_buffers.c | 130 +++++++++++++++++++++++++++++
 include/drm/drm_dumb_buffers.h     |  14 ++++
 include/uapi/drm/drm_mode.h        |  50 ++++++++++-
 4 files changed, 220 insertions(+), 1 deletion(-)
 create mode 100644 include/drm/drm_dumb_buffers.h

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index be8637da3fe9..f7312afa87b5 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -648,6 +648,33 @@ Contact: Thomas Zimmermann , Simona Vetter
 
 Level: Advanced
 
+Implement a new DUMB_CREATE2 ioctl
+----------------------------------
+
+The current DUMB_CREATE ioctl is not well defined. Instead of a pixel and
+framebuffer format, it only accepts a color mode of vague semantics. Assuming
+a linear framebuffer, the color mode gives and idea of the supported pixel
+format. But userspace effectively has to guess the correct values. It really
+only works reliable with framebuffers in XRGB8888. Userspace has begun to
+workaround these limitations by computing arbitrary format's buffer sizes and
+calculating their sizes in terms of XRGB8888 pixels.
+
+One possible solution is a new ioctl DUMB_CREATE2. It should accept a DRM
+format and a format modifier to resolve the color mode's ambiguity. As
+framebuffers can be multi-planar, the new ioctl has to return the buffer size,
+pitch and GEM handle for each individual color plane.
+
+In the first step, the new ioctl can be limited to the current features of
+the existing DUMB_CREATE. Individual drivers can then be extended to support
+multi-planar formats. Rockchip might require this and would be a good candidate.
+
+In addition to the kernel implementation, there must be user-space support
+for the new ioctl. There's code in Mesa that might be able to use the new
+call.
+
+Contact: Thomas Zimmermann 
+
+Level: Advanced
 
 Better Testing
 ==============
diff --git a/drivers/gpu/drm/drm_dumb_buffers.c b/drivers/gpu/drm/drm_dumb_buffers.c
index 9916aaf5b3f2..e9eed9a5b760 100644
--- a/drivers/gpu/drm/drm_dumb_buffers.c
+++ b/drivers/gpu/drm/drm_dumb_buffers.c
@@ -25,6 +25,8 @@
 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 
@@ -57,6 +59,134 @@
  * a hardware-specific ioctl to allocate suitable buffer objects.
  */
 
+static int drm_mode_align_dumb(struct drm_mode_create_dumb *args,
+			       unsigned long hw_pitch_align,
+			       unsigned long hw_size_align)
+{
+	u32 pitch = args->pitch;
+	u32 size;
+
+	if (!pitch)
+		return -EINVAL;
+
+	if (hw_pitch_align)
+		pitch = roundup(pitch, hw_pitch_align);
+
+	if (!hw_size_align)
+		hw_size_align = PAGE_SIZE;
+	else if (!IS_ALIGNED(hw_size_align, PAGE_SIZE))
+		return -EINVAL; /* TODO: handle this if necessary */
+
+	if (check_mul_overflow(args->height, pitch, &size))
+		return -EINVAL;
+	size = ALIGN(size, hw_size_align);
+	if (!size)
+		return -EINVAL;
+
+	args->pitch = pitch;
+	args->size = size;
+
+	return 0;
+}
+
+/**
+ * drm_mode_size_dumb - Calculates the scanline and buffer sizes for dumb buffers
+ * @dev: DRM device
+ * @args: Parameters for the dumb buffer
+ * @hw_pitch_align: Hardware scanline alignment in bytes
+ * @hw_size_align: Hardware buffer-size alignment in bytes
+ *
+ * The helper drm_mode_size_dumb() calculates the size of the buffer
+ * allocation and the scanline size for a dumb buffer. Callers have to
+ * set the buffers width, height and color mode in the argument @arg.
+ * The helper validates the correctness of the input and tests for
+ * possible overflows. If successful, it returns the dumb buffer's
+ * required scanline pitch and size in &args.
+ *
+ * The parameter @hw_pitch_align allows the driver to specifies an
+ * alignment for the scanline pitch, if the hardware requires any. The
+ * calculated pitch will be a multiple of the alignment. The parameter
+ * @hw_size_align allows to specify an alignment for buffer sizes. The
+ * provided alignment should represent requirements of the graphics
+ * hardware. drm_mode_size_dumb() handles GEM-related constraints
+ * automatically across all drivers and hardware. For example, the
+ * returned buffer size is always a multiple of PAGE_SIZE, which is
+ * required by mmap().
+ *
+ * Returns:
+ * Zero on success, or a negative error code otherwise.
+ */
+int drm_mode_size_dumb(struct drm_device *dev,
+		       struct drm_mode_create_dumb *args,
+		       unsigned long hw_pitch_align,
+		       unsigned long hw_size_align)
+{
+	u64 pitch = 0;
+	u32 fourcc;
+
+	/*
+	 * The scanline pitch depends on the buffer width and the color
+	 * format. The latter is specified as a color-mode constant for
+	 * which we first have to find the corresponding color format.
+	 *
+	 * Different color formats can have the same color-mode constant.
+	 * For example XRGB8888 and BGRX8888 both have a color mode of 32.
+	 * It is possible to use different formats for dumb-buffer allocation
+	 * and rendering as long as all involved formats share the same
+	 * color-mode constant.
+	 */
+	fourcc = drm_driver_color_mode_format(dev, args->bpp);
+	if (fourcc != DRM_FORMAT_INVALID) {
+		const struct drm_format_info *info = drm_format_info(fourcc);
+
+		if (!info)
+			return -EINVAL;
+		pitch = drm_format_info_min_pitch(info, 0, args->width);
+	} else if (args->bpp) {
+		/*
+		 * Some userspace throws in arbitrary values for bpp and
+		 * relies on the kernel to figure it out. In this case we
+		 * fall back to the old method of using bpp directly. The
+		 * over-commitment of memory from the rounding is acceptable
+		 * for compatibility with legacy userspace. We have a number
+		 * of deprecated legacy values that are explicitly supported.
+		 */
+		switch (args->bpp) {
+		default:
+			drm_warn_once(dev,
+				      "Unknown color mode %u; guessing buffer size.\n",
+				      args->bpp);
+			fallthrough;
+		/*
+		 * These constants represent various YUV formats supported by
+		 * drm_gem_afbc_get_bpp().
+		 */
+		case 12: // DRM_FORMAT_YUV420_8BIT
+		case 15: // DRM_FORMAT_YUV420_10BIT
+		case 30: // DRM_FORMAT_VUY101010
+			fallthrough;
+		/*
+		 * Used by Mesa and Gstreamer to allocate NV formats and others
+		 * as RGB buffers. Technically, XRGB16161616F formats are RGB,
+		 * but the dumb buffers are not supposed to be used for anything
+		 * beyond 32 bits per pixels.
+		 */
+		case 10: // DRM_FORMAT_NV{15,20,30}, DRM_FORMAT_P010
+		case 64: // DRM_FORMAT_{XRGB,XBGR,ARGB,ABGR}16161616F
+			pitch = args->width * DIV_ROUND_UP(args->bpp, SZ_8);
+			break;
+		}
+	}
+
+	if (!pitch || pitch > U32_MAX)
+		return -EINVAL;
+
+	args->pitch = pitch;
+
+	return drm_mode_align_dumb(args, hw_pitch_align, hw_size_align);
+}
+EXPORT_SYMBOL(drm_mode_size_dumb);
+
 int drm_mode_create_dumb(struct drm_device *dev,
 			 struct drm_mode_create_dumb *args,
 			 struct drm_file *file_priv)
diff --git a/include/drm/drm_dumb_buffers.h b/include/drm/drm_dumb_buffers.h
new file mode 100644
index 000000000000..1f3a8236fb3d
--- /dev/null
+++ b/include/drm/drm_dumb_buffers.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: MIT */
+
+#ifndef __DRM_DUMB_BUFFERS_H__
+#define __DRM_DUMB_BUFFERS_H__
+
+struct drm_device;
+struct drm_mode_create_dumb;
+
+int drm_mode_size_dumb(struct drm_device *dev,
+		       struct drm_mode_create_dumb *args,
+		       unsigned long hw_pitch_align,
+		       unsigned long hw_size_align);
+
+#endif
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index c082810c08a8..efe8f5ad35ee 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -1058,7 +1058,7 @@ struct drm_mode_crtc_page_flip_target {
  * struct drm_mode_create_dumb - Create a KMS dumb buffer for scanout.
  * @height: buffer height in pixels
  * @width: buffer width in pixels
- * @bpp: bits per pixel
+ * @bpp: color mode
  * @flags: must be zero
  * @handle: buffer object handle
  * @pitch: number of bytes between two consecutive lines
@@ -1066,6 +1066,54 @@ struct drm_mode_crtc_page_flip_target {
  *
  * User-space fills @height, @width, @bpp and @flags. If the IOCTL succeeds,
  * the kernel fills @handle, @pitch and @size.
+ *
+ * The value of @bpp is a color-mode number describing a specific format
+ * or a variant thereof. The value often corresponds to the number of bits
+ * per pixel for most modes, although there are exceptions. Each color mode
+ * maps to a DRM format plus a number of modes with similar pixel layout.
+ * Framebuffer layout is always linear.
+ *
+ * Support for all modes and formats is optional. Even if dumb-buffer
+ * creation with a certain color mode succeeds, it is not guaranteed that
+ * the DRM driver supports any of the related formats. Most drivers support
+ * a color mode of 32 with a format of DRM_FORMAT_XRGB8888 on their primary
+ * plane.
+ *
+ * +------------+------------------------+------------------------+
+ * | Color mode | Framebuffer format     | Compatible formats     |
+ * +============+========================+========================+
+ * |     32     |  * DRM_FORMAT_XRGB8888 |  * DRM_FORMAT_BGRX8888 |
+ * |            |                        |  * DRM_FORMAT_RGBX8888 |
+ * |            |                        |  * DRM_FORMAT_XBGR8888 |
+ * +------------+------------------------+------------------------+
+ * |     24     |  * DRM_FORMAT_RGB888   |  * DRM_FORMAT_BGR888   |
+ * +------------+------------------------+------------------------+
+ * |     16     |  * DRM_FORMAT_RGB565   |  * DRM_FORMAT_BGR565   |
+ * +------------+------------------------+------------------------+
+ * |     15     |  * DRM_FORMAT_XRGB1555 |  * DRM_FORMAT_BGRX1555 |
+ * |            |                        |  * DRM_FORMAT_RGBX1555 |
+ * |            |                        |  * DRM_FORMAT_XBGR1555 |
+ * +------------+------------------------+------------------------+
+ * |      8     |  * DRM_FORMAT_C8       |  * DRM_FORMAT_D8       |
+ * |            |                        |  * DRM_FORMAT_R8       |
+ * +------------+------------------------+------------------------+
+ * |      4     |  * DRM_FORMAT_C4       |  * DRM_FORMAT_D4       |
+ * |            |                        |  * DRM_FORMAT_R4       |
+ * +------------+------------------------+------------------------+
+ * |      2     |  * DRM_FORMAT_C2       |  * DRM_FORMAT_D2       |
+ * |            |                        |  * DRM_FORMAT_R2       |
+ * +------------+------------------------+------------------------+
+ * |      1     |  * DRM_FORMAT_C1       |  * DRM_FORMAT_D1       |
+ * |            |                        |  * DRM_FORMAT_R1       |
+ * +------------+------------------------+------------------------+
+ *
+ * Color modes of 10, 12, 15, 30 and 64 are only supported for use by
+ * legacy user space. Please don't use them in new code. Other modes
+ * are not support.
+ *
+ * Do not attempt to allocate anything but linear framebuffer memory
+ * with single-plane RGB data. Allocation of other framebuffer
+ * layouts requires dedicated ioctls in the respective DRM driver.
  */
 struct drm_mode_create_dumb {
 	__u32 height;
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 09:04:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 09:04:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013944.1392165 (Exim 4.92)
	(envelope-from )
	id 1uQ0L8-0003Ao-Bs; Fri, 13 Jun 2025 09:04:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013944.1392165; Fri, 13 Jun 2025 09: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 1uQ0L8-0003Ah-8l; Fri, 13 Jun 2025 09:04:46 +0000
Received: by outflank-mailman (input) for mailman id 1013944;
 Fri, 13 Jun 2025 09: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 1uQ0L6-0002e2-Uh
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 09:04:44 +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 6b6c7870-4835-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 11:04:32 +0200 (CEST)
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 AA4B22126D;
 Fri, 13 Jun 2025 09:04: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 03FC013A9C;
 Fri, 13 Jun 2025 09:04:39 +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 6LJgO6fpS2inNAAAD6G6ig
 (envelope-from ); Fri, 13 Jun 2025 09:04: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: 6b6c7870-4835-11f0-b894-0df219b8e170
Authentication-Results: smtp-out1.suse.de;
	none
From: Thomas Zimmermann 
To: simona@ffwll.ch,
	airlied@gmail.com,
	mripard@kernel.org,
	maarten.lankhorst@linux.intel.com,
	geert@linux-m68k.org,
	tomi.valkeinen@ideasonboard.com
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann ,
	Inki Dae ,
	Seung-Woo Kim ,
	Kyungmin Park ,
	Krzysztof Kozlowski ,
	Alim Akhtar 
Subject: [PATCH v5 07/25] drm/exynos: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Fri, 13 Jun 2025 11:00:26 +0200
Message-ID: <20250613090431.127087-8-tzimmermann@suse.de>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250613090431.127087-1-tzimmermann@suse.de>
References: <20250613090431.127087-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Spam-Level: 
X-Spamd-Result: default: False [-4.00 / 50.00];
	REPLY(-4.00)[]
X-Spam-Flag: NO
X-Rspamd-Queue-Id: AA4B22126D
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Action: no action
X-Spam-Score: -4.00

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. No alignment required.

Signed-off-by: Thomas Zimmermann 
Cc: Inki Dae 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Cc: Krzysztof Kozlowski 
Cc: Alim Akhtar 
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 4787fee4696f..ffa1c02b4b1e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -330,15 +331,16 @@ int exynos_drm_gem_dumb_create(struct drm_file *file_priv,
 	unsigned int flags;
 	int ret;
 
+	ret = drm_mode_size_dumb(dev, args, 0, 0);
+	if (ret)
+		return ret;
+
 	/*
 	 * allocate memory to be used for framebuffer.
 	 * - this callback would be called by user application
 	 *	with DRM_IOCTL_MODE_CREATE_DUMB command.
 	 */
 
-	args->pitch = args->width * ((args->bpp + 7) / 8);
-	args->size = args->pitch * args->height;
-
 	if (is_drm_iommu_supported(dev))
 		flags = EXYNOS_BO_NONCONTIG | EXYNOS_BO_WC;
 	else
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 09:04:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 09:04:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013945.1392175 (Exim 4.92)
	(envelope-from )
	id 1uQ0L9-0003Qq-JP; Fri, 13 Jun 2025 09:04:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013945.1392175; Fri, 13 Jun 2025 09:04: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 1uQ0L9-0003PP-Fi; Fri, 13 Jun 2025 09:04:47 +0000
Received: by outflank-mailman (input) for mailman id 1013945;
 Fri, 13 Jun 2025 09:04: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 1uQ0L7-0002BZ-QX
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 09:04:45 +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 7330f095-4835-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 11:04:45 +0200 (CEST)
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 34FE21F84C;
 Fri, 13 Jun 2025 09:04: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 9F7A713A9C;
 Fri, 13 Jun 2025 09:04:37 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id mBafJaXpS2inNAAAD6G6ig
 (envelope-from ); Fri, 13 Jun 2025 09:04: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: 7330f095-4835-11f0-a309-13f23c93f187
Authentication-Results: smtp-out2.suse.de;
	none
From: Thomas Zimmermann 
To: simona@ffwll.ch,
	airlied@gmail.com,
	mripard@kernel.org,
	maarten.lankhorst@linux.intel.com,
	geert@linux-m68k.org,
	tomi.valkeinen@ideasonboard.com
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann 
Subject: [PATCH v5 03/25] drm/gem-dma: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Fri, 13 Jun 2025 11:00:22 +0200
Message-ID: <20250613090431.127087-4-tzimmermann@suse.de>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250613090431.127087-1-tzimmermann@suse.de>
References: <20250613090431.127087-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Spamd-Result: default: False [-4.00 / 50.00];
	REPLY(-4.00)[]
X-Rspamd-Queue-Id: 34FE21F84C
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Action: no action
X-Spam-Level: 
X-Spam-Flag: NO
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Score: -4.00

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 8.

Push the current calculation into the only direct caller imx. Imx's
hardware requires the framebuffer width to be aligned to 8. The
driver's current approach is actually incorrect, as it only guarantees
this implicitly and requires bpp to be a multiple of 8 already. A
later commit will fix this problem by aligning the scanline pitch
such that an aligned width still fits into each scanline's memory.

A number of other drivers are build on top of gem-dma helpers and
implement their own dumb-buffer allocation. These drivers invoke
drm_gem_dma_dumb_create_internal(), which is not affected by this
commit.

v5:
- avoid reset of arguments (Tomi)

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/drm_gem_dma_helper.c     | 7 +++++--
 drivers/gpu/drm/imx/ipuv3/imx-drm-core.c | 4 +++-
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_dma_helper.c b/drivers/gpu/drm/drm_gem_dma_helper.c
index b7f033d4352a..49be9b033610 100644
--- a/drivers/gpu/drm/drm_gem_dma_helper.c
+++ b/drivers/gpu/drm/drm_gem_dma_helper.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -304,9 +305,11 @@ int drm_gem_dma_dumb_create(struct drm_file *file_priv,
 			    struct drm_mode_create_dumb *args)
 {
 	struct drm_gem_dma_object *dma_obj;
+	int ret;
 
-	args->pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
-	args->size = args->pitch * args->height;
+	ret = drm_mode_size_dumb(drm, args, SZ_8, 0);
+	if (ret)
+		return ret;
 
 	dma_obj = drm_gem_dma_create_with_handle(file_priv, drm, args->size,
 						 &args->handle);
diff --git a/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c b/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
index ec5fd9a01f1e..af4a30311e18 100644
--- a/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
@@ -145,8 +145,10 @@ static int imx_drm_dumb_create(struct drm_file *file_priv,
 	int ret;
 
 	args->width = ALIGN(width, 8);
+	args->pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
+	args->size = args->pitch * args->height;
 
-	ret = drm_gem_dma_dumb_create(file_priv, drm, args);
+	ret = drm_gem_dma_dumb_create_internal(file_priv, drm, args);
 	if (ret)
 		return ret;
 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 09:04:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 09:04:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013947.1392185 (Exim 4.92)
	(envelope-from )
	id 1uQ0LB-0003l8-T9; Fri, 13 Jun 2025 09:04:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013947.1392185; Fri, 13 Jun 2025 09:04:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uQ0LB-0003kt-PJ; Fri, 13 Jun 2025 09:04:49 +0000
Received: by outflank-mailman (input) for mailman id 1013947;
 Fri, 13 Jun 2025 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 1uQ0L9-0002BZ-RB
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 09:04:47 +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 7461e01e-4835-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 11:04:47 +0200 (CEST)
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 08E8B21274;
 Fri, 13 Jun 2025 09:04:42 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 5112313A9C;
 Fri, 13 Jun 2025 09:04: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 0N9qEqnpS2inNAAAD6G6ig
 (envelope-from ); Fri, 13 Jun 2025 09:04: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: 7461e01e-4835-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749805482; 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=UCz1iBvbEL5W8KPL1u0ee8Z156JiAXpxTWqwbW309PI=;
	b=gidma+D22RrHWwBc//NWB+/uCa8/Dj1LPhru5daNtc/lqMoi0yK08ON+RsZtBG8uE98sDz
	GVA5JRXLFLei/a2nI2jTH0MamtWdwVCir4VSoDsiVqnuOmTX5jSvNk/nRXJC/BfeDEo24T
	ryhMfdn00M7FE11y9seKiDQDZXPuewc=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749805482;
	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=UCz1iBvbEL5W8KPL1u0ee8Z156JiAXpxTWqwbW309PI=;
	b=YWEGj/63MhRpq8lXgv2heMPBV1B8fbq2ISI4BFfDhRKEZWYqiKnoMkIZYfhHobwOafSWIs
	SuEr+Uk2Xy4hDGCw==
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749805482; 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=UCz1iBvbEL5W8KPL1u0ee8Z156JiAXpxTWqwbW309PI=;
	b=gidma+D22RrHWwBc//NWB+/uCa8/Dj1LPhru5daNtc/lqMoi0yK08ON+RsZtBG8uE98sDz
	GVA5JRXLFLei/a2nI2jTH0MamtWdwVCir4VSoDsiVqnuOmTX5jSvNk/nRXJC/BfeDEo24T
	ryhMfdn00M7FE11y9seKiDQDZXPuewc=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749805482;
	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=UCz1iBvbEL5W8KPL1u0ee8Z156JiAXpxTWqwbW309PI=;
	b=YWEGj/63MhRpq8lXgv2heMPBV1B8fbq2ISI4BFfDhRKEZWYqiKnoMkIZYfhHobwOafSWIs
	SuEr+Uk2Xy4hDGCw==
From: Thomas Zimmermann 
To: simona@ffwll.ch,
	airlied@gmail.com,
	mripard@kernel.org,
	maarten.lankhorst@linux.intel.com,
	geert@linux-m68k.org,
	tomi.valkeinen@ideasonboard.com
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann ,
	Xinliang Liu ,
	Tian Tao ,
	Xinwei Kong ,
	Sumit Semwal ,
	Yongqin Liu ,
	John Stultz 
Subject: [PATCH v5 09/25] drm/hibmc: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Fri, 13 Jun 2025 11:00:28 +0200
Message-ID: <20250613090431.127087-10-tzimmermann@suse.de>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250613090431.127087-1-tzimmermann@suse.de>
References: <20250613090431.127087-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Flag: NO
X-Spam-Score: -5.30
X-Spamd-Result: default: False [-5.30 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-0.999];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_TO(0.00)[ffwll.ch,gmail.com,kernel.org,linux.intel.com,linux-m68k.org,ideasonboard.com];
	MIME_TRACE(0.00)[0:+];
	TO_DN_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[27];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	R_RATELIMIT(0.00)[to_ip_from(RLqirfcw6gnbcr9a9yhi49fhi6)];
	RCVD_TLS_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:mid,suse.de:email,linaro.org:email];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Spam-Level: 

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 128.

The hibmc driver's new hibmc_dumb_create() is similar to the one
in GEM VRAM helpers. The driver was the only caller of
drm_gem_vram_fill_create_dumb(). Remove the now unused helper.

Signed-off-by: Thomas Zimmermann 
Cc: Xinliang Liu 
Cc: Tian Tao 
Cc: Xinwei Kong 
Cc: Sumit Semwal 
Cc: Yongqin Liu 
Cc: John Stultz 
---
 drivers/gpu/drm/drm_gem_vram_helper.c         | 65 -------------------
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c   | 25 ++++++-
 include/drm/drm_gem_vram_helper.h             |  6 --
 3 files changed, 24 insertions(+), 72 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c b/drivers/gpu/drm/drm_gem_vram_helper.c
index 73383d5708e2..4f56e08efafa 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -406,71 +406,6 @@ void drm_gem_vram_vunmap(struct drm_gem_vram_object *gbo,
 }
 EXPORT_SYMBOL(drm_gem_vram_vunmap);
 
-/**
- * drm_gem_vram_fill_create_dumb() - Helper for implementing
- *				     &struct drm_driver.dumb_create
- *
- * @file:		the DRM file
- * @dev:		the DRM device
- * @pg_align:		the buffer's alignment in multiples of the page size
- * @pitch_align:	the scanline's alignment in powers of 2
- * @args:		the arguments as provided to
- *			&struct drm_driver.dumb_create
- *
- * This helper function fills &struct drm_mode_create_dumb, which is used
- * by &struct drm_driver.dumb_create. Implementations of this interface
- * should forwards their arguments to this helper, plus the driver-specific
- * parameters.
- *
- * Returns:
- * 0 on success, or
- * a negative error code otherwise.
- */
-int drm_gem_vram_fill_create_dumb(struct drm_file *file,
-				  struct drm_device *dev,
-				  unsigned long pg_align,
-				  unsigned long pitch_align,
-				  struct drm_mode_create_dumb *args)
-{
-	size_t pitch, size;
-	struct drm_gem_vram_object *gbo;
-	int ret;
-	u32 handle;
-
-	pitch = args->width * DIV_ROUND_UP(args->bpp, 8);
-	if (pitch_align) {
-		if (WARN_ON_ONCE(!is_power_of_2(pitch_align)))
-			return -EINVAL;
-		pitch = ALIGN(pitch, pitch_align);
-	}
-	size = pitch * args->height;
-
-	size = roundup(size, PAGE_SIZE);
-	if (!size)
-		return -EINVAL;
-
-	gbo = drm_gem_vram_create(dev, size, pg_align);
-	if (IS_ERR(gbo))
-		return PTR_ERR(gbo);
-
-	ret = drm_gem_handle_create(file, &gbo->bo.base, &handle);
-	if (ret)
-		goto err_drm_gem_object_put;
-
-	drm_gem_object_put(&gbo->bo.base);
-
-	args->pitch = pitch;
-	args->size = size;
-	args->handle = handle;
-
-	return 0;
-
-err_drm_gem_object_put:
-	drm_gem_object_put(&gbo->bo.base);
-	return ret;
-}
-EXPORT_SYMBOL(drm_gem_vram_fill_create_dumb);
-
 /*
  * Helpers for struct ttm_device_funcs
  */
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 768b97f9e74a..e88e8a897938 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -18,10 +18,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -70,7 +72,28 @@ static irqreturn_t hibmc_dp_interrupt(int irq, void *arg)
 static int hibmc_dumb_create(struct drm_file *file, struct drm_device *dev,
 			     struct drm_mode_create_dumb *args)
 {
-	return drm_gem_vram_fill_create_dumb(file, dev, 0, 128, args);
+	struct drm_gem_vram_object *gbo;
+	int ret;
+
+	ret = drm_mode_size_dumb(dev, args, SZ_128, 0);
+	if (ret)
+		return ret;
+
+	gbo = drm_gem_vram_create(dev, args->size, 0);
+	if (IS_ERR(gbo))
+		return PTR_ERR(gbo);
+
+	ret = drm_gem_handle_create(file, &gbo->bo.base, &args->handle);
+	if (ret)
+		goto err_drm_gem_object_put;
+
+	drm_gem_object_put(&gbo->bo.base);
+
+	return 0;
+
+err_drm_gem_object_put:
+	drm_gem_object_put(&gbo->bo.base);
+	return ret;
 }
 
 static const struct drm_driver hibmc_driver = {
diff --git a/include/drm/drm_gem_vram_helper.h b/include/drm/drm_gem_vram_helper.h
index 2dd42bed679d..1190064f5760 100644
--- a/include/drm/drm_gem_vram_helper.h
+++ b/include/drm/drm_gem_vram_helper.h
@@ -98,12 +98,6 @@ int drm_gem_vram_vmap(struct drm_gem_vram_object *gbo, struct iosys_map *map);
 void drm_gem_vram_vunmap(struct drm_gem_vram_object *gbo,
 			 struct iosys_map *map);
 
-int drm_gem_vram_fill_create_dumb(struct drm_file *file,
-				  struct drm_device *dev,
-				  unsigned long pg_align,
-				  unsigned long pitch_align,
-				  struct drm_mode_create_dumb *args);
-
 /*
  * Helpers for struct drm_driver
  */
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 09:04:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 09:04:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013948.1392191 (Exim 4.92)
	(envelope-from )
	id 1uQ0LC-0003pJ-F7; Fri, 13 Jun 2025 09:04:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013948.1392191; Fri, 13 Jun 2025 09:04:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uQ0LC-0003nt-3q; Fri, 13 Jun 2025 09:04:50 +0000
Received: by outflank-mailman (input) for mailman id 1013948;
 Fri, 13 Jun 2025 09:04: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 1uQ0LA-0002BZ-RQ
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 09:04:48 +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 74fc660b-4835-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 11:04:48 +0200 (CEST)
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 5C92E1F850;
 Fri, 13 Jun 2025 09:04:39 +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 CB29B13A9C;
 Fri, 13 Jun 2025 09:04: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 aIs2MKbpS2inNAAAD6G6ig
 (envelope-from ); Fri, 13 Jun 2025 09:04: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: 74fc660b-4835-11f0-a309-13f23c93f187
Authentication-Results: smtp-out2.suse.de;
	none
From: Thomas Zimmermann 
To: simona@ffwll.ch,
	airlied@gmail.com,
	mripard@kernel.org,
	maarten.lankhorst@linux.intel.com,
	geert@linux-m68k.org,
	tomi.valkeinen@ideasonboard.com
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann 
Subject: [PATCH v5 05/25] drm/gem-vram: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Fri, 13 Jun 2025 11:00:24 +0200
Message-ID: <20250613090431.127087-6-tzimmermann@suse.de>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250613090431.127087-1-tzimmermann@suse.de>
References: <20250613090431.127087-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Spam-Level: 
X-Spamd-Result: default: False [-4.00 / 50.00];
	REPLY(-4.00)[]
X-Spam-Flag: NO
X-Rspamd-Queue-Id: 5C92E1F850
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Action: no action
X-Spam-Score: -4.00

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Inline code from drm_gem_vram_fill_create_dumb() without
the existing size computation. Align the pitch to a multiple of 8.

Only hibmc and vboxvideo use gem-vram. Hibmc invokes the call to
drm_gem_vram_fill_create_dumb() directly and is therefore not affected.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/drm_gem_vram_helper.c | 24 +++++++++++++++++++++++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c b/drivers/gpu/drm/drm_gem_vram_helper.c
index ead50fef5e7d..73383d5708e2 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -544,10 +545,31 @@ int drm_gem_vram_driver_dumb_create(struct drm_file *file,
 				    struct drm_device *dev,
 				    struct drm_mode_create_dumb *args)
 {
+	struct drm_gem_vram_object *gbo;
+	int ret;
+
 	if (WARN_ONCE(!dev->vram_mm, "VRAM MM not initialized"))
 		return -EINVAL;
 
-	return drm_gem_vram_fill_create_dumb(file, dev, 0, 0, args);
+	ret = drm_mode_size_dumb(dev, args, SZ_8, 0);
+	if (ret)
+		return ret;
+
+	gbo = drm_gem_vram_create(dev, args->size, 0);
+	if (IS_ERR(gbo))
+		return PTR_ERR(gbo);
+
+	ret = drm_gem_handle_create(file, &gbo->bo.base, &args->handle);
+	if (ret)
+		goto err_drm_gem_object_put;
+
+	drm_gem_object_put(&gbo->bo.base);
+
+	return 0;
+
+err_drm_gem_object_put:
+	drm_gem_object_put(&gbo->bo.base);
+	return ret;
 }
 EXPORT_SYMBOL(drm_gem_vram_driver_dumb_create);
 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 09:04:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 09:04:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013949.1392204 (Exim 4.92)
	(envelope-from )
	id 1uQ0LE-0004MI-FO; Fri, 13 Jun 2025 09:04:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013949.1392204; Fri, 13 Jun 2025 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 1uQ0LE-0004M4-C2; Fri, 13 Jun 2025 09:04:52 +0000
Received: by outflank-mailman (input) for mailman id 1013949;
 Fri, 13 Jun 2025 09:04: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 1uQ0LD-0002BZ-Nq
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 09:04:51 +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 76c7baca-4835-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 11:04:51 +0200 (CEST)
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 F305B1F88B;
 Fri, 13 Jun 2025 09:04:39 +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 64947137FE;
 Fri, 13 Jun 2025 09:04:39 +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 2Eo0F6fpS2inNAAAD6G6ig
 (envelope-from ); Fri, 13 Jun 2025 09:04: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: 76c7baca-4835-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749805480; 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=j3VKbXZDAUYoMB40PQHaVxA6iryheH3NPuPPEd7ir9Y=;
	b=GQweqoLHYyAGJPXKoJHaT+88dZNUO1KMwFpf3GKhpyrB2MM534mgm4uNFHwTD5CrI+ntff
	DdG0ZMwiyrzxss9qkcEyiF6l328HiqTsBrXIZ2s/wuXeHiiARQK6cufu4QGUCzCI2L8lH4
	MmpRNYXzexV2VPe3jhYDRxG/T08mIPo=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749805480;
	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=j3VKbXZDAUYoMB40PQHaVxA6iryheH3NPuPPEd7ir9Y=;
	b=h6s3wBJ20ghKJBgKVT1tiiKLtr4Ujrg7ckMFeWWnEqyc9ZhHCKENUpWdYIpasMVSCaS6pA
	Y3VFAjRG4tMIMSCw==
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749805480; 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=j3VKbXZDAUYoMB40PQHaVxA6iryheH3NPuPPEd7ir9Y=;
	b=GQweqoLHYyAGJPXKoJHaT+88dZNUO1KMwFpf3GKhpyrB2MM534mgm4uNFHwTD5CrI+ntff
	DdG0ZMwiyrzxss9qkcEyiF6l328HiqTsBrXIZ2s/wuXeHiiARQK6cufu4QGUCzCI2L8lH4
	MmpRNYXzexV2VPe3jhYDRxG/T08mIPo=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749805480;
	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=j3VKbXZDAUYoMB40PQHaVxA6iryheH3NPuPPEd7ir9Y=;
	b=h6s3wBJ20ghKJBgKVT1tiiKLtr4Ujrg7ckMFeWWnEqyc9ZhHCKENUpWdYIpasMVSCaS6pA
	Y3VFAjRG4tMIMSCw==
From: Thomas Zimmermann 
To: simona@ffwll.ch,
	airlied@gmail.com,
	mripard@kernel.org,
	maarten.lankhorst@linux.intel.com,
	geert@linux-m68k.org,
	tomi.valkeinen@ideasonboard.com
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann ,
	Russell King 
Subject: [PATCH v5 06/25] drm/armada: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Fri, 13 Jun 2025 11:00:25 +0200
Message-ID: <20250613090431.127087-7-tzimmermann@suse.de>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250613090431.127087-1-tzimmermann@suse.de>
References: <20250613090431.127087-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-5.30 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	MID_CONTAINS_FROM(1.00)[];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-0.999];
	MIME_GOOD(-0.10)[text/plain];
	URIBL_BLOCKED(0.00)[suse.de:email,suse.de:mid];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[22];
	MIME_TRACE(0.00)[0:+];
	RCVD_COUNT_TWO(0.00)[2];
	FREEMAIL_TO(0.00)[ffwll.ch,gmail.com,kernel.org,linux.intel.com,linux-m68k.org,ideasonboard.com];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:email,suse.de:mid];
	RCVD_TLS_ALL(0.00)[];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	TO_DN_SOME(0.00)[];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Spam-Level: 
X-Spam-Flag: NO
X-Spam-Score: -5.30

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 128.

v4:
- align pitch to 128 bytes (Russell)

Signed-off-by: Thomas Zimmermann 
Cc: Russell King 
---
 drivers/gpu/drm/armada/armada_gem.c | 16 +++++++---------
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_gem.c b/drivers/gpu/drm/armada/armada_gem.c
index 1a1680d71486..a767c4edd5c8 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -9,6 +9,7 @@
 #include 
 
 #include 
+#include 
 #include 
 
 #include "armada_drm.h"
@@ -244,14 +245,13 @@ int armada_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
 	struct drm_mode_create_dumb *args)
 {
 	struct armada_gem_object *dobj;
-	u32 handle;
-	size_t size;
 	int ret;
 
-	args->pitch = armada_pitch(args->width, args->bpp);
-	args->size = size = args->pitch * args->height;
+	ret = drm_mode_size_dumb(dev, args, SZ_128, 0);
+	if (ret)
+		return ret;
 
-	dobj = armada_gem_alloc_private_object(dev, size);
+	dobj = armada_gem_alloc_private_object(dev, args->size);
 	if (dobj == NULL)
 		return -ENOMEM;
 
@@ -259,14 +259,12 @@ int armada_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
 	if (ret)
 		goto err;
 
-	ret = drm_gem_handle_create(file, &dobj->obj, &handle);
+	ret = drm_gem_handle_create(file, &dobj->obj, &args->handle);
 	if (ret)
 		goto err;
 
-	args->handle = handle;
-
 	/* drop reference from allocate - handle holds it now */
-	DRM_DEBUG_DRIVER("obj %p size %zu handle %#x\n", dobj, size, handle);
+	DRM_DEBUG_DRIVER("obj %p size %llu handle %#x\n", dobj, args->size, args->handle);
  err:
 	drm_gem_object_put(&dobj->obj);
 	return ret;
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 09:04:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 09:04:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013950.1392210 (Exim 4.92)
	(envelope-from )
	id 1uQ0LF-0004QD-04; Fri, 13 Jun 2025 09:04:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013950.1392210; Fri, 13 Jun 2025 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 1uQ0LE-0004PV-O2; Fri, 13 Jun 2025 09:04:52 +0000
Received: by outflank-mailman (input) for mailman id 1013950;
 Fri, 13 Jun 2025 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 1uQ0LD-0002e2-Qc
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 09:04:51 +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 6f8ccf26-4835-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 11:04:39 +0200 (CEST)
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 36C2421268;
 Fri, 13 Jun 2025 09:04: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 A5C2B13A9C;
 Fri, 13 Jun 2025 09:04:45 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id kDHvJq3pS2inNAAAD6G6ig
 (envelope-from ); Fri, 13 Jun 2025 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: 6f8ccf26-4835-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749805486; 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=5DQwIAKRIxg3GWTw/C3NgciSzFLmICKXiRkRnCfZnVQ=;
	b=qHLyjdMSFzxUZW3WivSTipg68so3HGMQI4Xpi86nsk87WrZywA0GGL73YCGs8Cz3sAOsJi
	oIwl4dF4NgjZEdMwcypNRZEIf7S9C+r/SWEFSIr/goBGd1/LY7BwltLWJQya8phF1jd7+G
	BVCFKZIdE1Pa++y+jSRVlfQFL09Xju4=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749805486;
	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=5DQwIAKRIxg3GWTw/C3NgciSzFLmICKXiRkRnCfZnVQ=;
	b=aiYG4tuLiNAlNMc5qvpWLt46ZC74YwoN6bC12dtPtvhRTsJr+z2TbxERSDUZugdOAl262t
	mstlptHfl+t++YBg==
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749805486; 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=5DQwIAKRIxg3GWTw/C3NgciSzFLmICKXiRkRnCfZnVQ=;
	b=qHLyjdMSFzxUZW3WivSTipg68so3HGMQI4Xpi86nsk87WrZywA0GGL73YCGs8Cz3sAOsJi
	oIwl4dF4NgjZEdMwcypNRZEIf7S9C+r/SWEFSIr/goBGd1/LY7BwltLWJQya8phF1jd7+G
	BVCFKZIdE1Pa++y+jSRVlfQFL09Xju4=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749805486;
	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=5DQwIAKRIxg3GWTw/C3NgciSzFLmICKXiRkRnCfZnVQ=;
	b=aiYG4tuLiNAlNMc5qvpWLt46ZC74YwoN6bC12dtPtvhRTsJr+z2TbxERSDUZugdOAl262t
	mstlptHfl+t++YBg==
From: Thomas Zimmermann 
To: simona@ffwll.ch,
	airlied@gmail.com,
	mripard@kernel.org,
	maarten.lankhorst@linux.intel.com,
	geert@linux-m68k.org,
	tomi.valkeinen@ideasonboard.com
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann 
Subject: [PATCH v5 15/25] drm/omapdrm: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Fri, 13 Jun 2025 11:00:34 +0200
Message-ID: <20250613090431.127087-16-tzimmermann@suse.de>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250613090431.127087-1-tzimmermann@suse.de>
References: <20250613090431.127087-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Flag: NO
X-Spam-Score: -5.30
X-Spamd-Result: default: False [-5.30 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-0.999];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_TO(0.00)[ffwll.ch,gmail.com,kernel.org,linux.intel.com,linux-m68k.org,ideasonboard.com];
	MIME_TRACE(0.00)[0:+];
	TO_DN_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[21];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	R_RATELIMIT(0.00)[to_ip_from(RLqirfcw6gnbcr9a9yhi49fhi6)];
	RCVD_TLS_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:mid,suse.de:email,ideasonboard.com:email];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Spam-Level: 

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 8.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Tomi Valkeinen 
Cc: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_gem.c | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c b/drivers/gpu/drm/omapdrm/omap_gem.c
index b9c67e4ca360..b8413a2dcdeb 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 
@@ -583,15 +584,13 @@ static int omap_gem_object_mmap(struct drm_gem_object *obj, struct vm_area_struc
 int omap_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
 		struct drm_mode_create_dumb *args)
 {
-	union omap_gem_size gsize;
-
-	args->pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
-
-	args->size = PAGE_ALIGN(args->pitch * args->height);
+	union omap_gem_size gsize = { };
+	int ret;
 
-	gsize = (union omap_gem_size){
-		.bytes = args->size,
-	};
+	ret = drm_mode_size_dumb(dev, args, SZ_8, 0);
+	if (ret)
+		return ret;
+	gsize.bytes = args->size;
 
 	return omap_gem_new_handle(dev, file, gsize,
 			OMAP_BO_SCANOUT | OMAP_BO_WC, &args->handle);
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 09:04:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 09:04:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013955.1392224 (Exim 4.92)
	(envelope-from )
	id 1uQ0LI-0005Bg-M9; Fri, 13 Jun 2025 09:04:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013955.1392224; Fri, 13 Jun 2025 09:04: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 1uQ0LI-0005BR-IF; Fri, 13 Jun 2025 09:04:56 +0000
Received: by outflank-mailman (input) for mailman id 1013955;
 Fri, 13 Jun 2025 09:04: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 1uQ0LH-0002e2-M7
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 09:04:55 +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 71da7819-4835-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 11:04:43 +0200 (CEST)
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 7746F21286;
 Fri, 13 Jun 2025 09:04:48 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id D5FA3137FE;
 Fri, 13 Jun 2025 09:04:47 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id gHjoMq/pS2inNAAAD6G6ig
 (envelope-from ); Fri, 13 Jun 2025 09:04:47 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 71da7819-4835-11f0-b894-0df219b8e170
Authentication-Results: smtp-out1.suse.de;
	none
From: Thomas Zimmermann 
To: simona@ffwll.ch,
	airlied@gmail.com,
	mripard@kernel.org,
	maarten.lankhorst@linux.intel.com,
	geert@linux-m68k.org,
	tomi.valkeinen@ideasonboard.com
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann ,
	Biju Das 
Subject: [PATCH v5 18/25] drm/renesas/rz-du: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Fri, 13 Jun 2025 11:00:37 +0200
Message-ID: <20250613090431.127087-19-tzimmermann@suse.de>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250613090431.127087-1-tzimmermann@suse.de>
References: <20250613090431.127087-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Spam-Level: 
X-Spamd-Result: default: False [-4.00 / 50.00];
	REPLY(-4.00)[]
X-Spam-Flag: NO
X-Rspamd-Queue-Id: 7746F21286
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Action: no action
X-Spam-Score: -4.00

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch according to hardware requirements.

v5:
- include dumb-buffers header for drm_mode_size_dumb() (kernel test robot)

Signed-off-by: Thomas Zimmermann 
Cc: Biju Das 
---
 drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c
index 55a97691e9b2..d446229bcfe7 100644
--- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c
+++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -181,10 +182,11 @@ const struct rzg2l_du_format_info *rzg2l_du_format_info(u32 fourcc)
 int rzg2l_du_dumb_create(struct drm_file *file, struct drm_device *dev,
 			 struct drm_mode_create_dumb *args)
 {
-	unsigned int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
-	unsigned int align = 16 * args->bpp / 8;
+	int ret;
 
-	args->pitch = roundup(min_pitch, align);
+	ret = drm_mode_size_dumb(dev, args, 16 * args->bpp / 8, 0);
+	if (ret)
+		return ret;
 
 	return drm_gem_dma_dumb_create_internal(file, dev, args);
 }
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 09:04:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 09:04:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013956.1392229 (Exim 4.92)
	(envelope-from )
	id 1uQ0LJ-0005Hb-77; Fri, 13 Jun 2025 09:04:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013956.1392229; Fri, 13 Jun 2025 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 1uQ0LI-0005Gl-Vs; Fri, 13 Jun 2025 09:04:56 +0000
Received: by outflank-mailman (input) for mailman id 1013956;
 Fri, 13 Jun 2025 09:04: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 1uQ0LH-0002e2-T0
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 09:04:55 +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 71e18b55-4835-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 11:04:43 +0200 (CEST)
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 49E391F78E;
 Fri, 13 Jun 2025 09:04: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 B1C0B137FE;
 Fri, 13 Jun 2025 09:04: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 eLYGKqjpS2inNAAAD6G6ig
 (envelope-from ); Fri, 13 Jun 2025 09:04: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: 71e18b55-4835-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749805481; 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=pL8BIAz+3TknRN85zYSjBUUnsd8cQe8ZmaDYWneQEX4=;
	b=qnzBIvdSAXQbKG2D/0OBFTs4apc1oGcdc2lMo3V/fA0fA0V1s+D0YAddWsUmdXhykKPqhI
	yB8tDwqmvyFG2KhextLm/2MizwF9Gs24uVkr0wZAdTw0aohbCr3Wq7l4XIPyhDWcI6dind
	YBw1H43uv9oWH51+4EtfMDEbIRWIRZM=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749805481;
	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=pL8BIAz+3TknRN85zYSjBUUnsd8cQe8ZmaDYWneQEX4=;
	b=HalWXNLaE7Vnen/y3IUTrNChIYVpQFAQgFkhF6W9Dw/fI0wQ4I4IegcpQmHfHXBFuyyOKW
	k7G6Hf7H/Y9PYtCg==
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749805481; 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=pL8BIAz+3TknRN85zYSjBUUnsd8cQe8ZmaDYWneQEX4=;
	b=qnzBIvdSAXQbKG2D/0OBFTs4apc1oGcdc2lMo3V/fA0fA0V1s+D0YAddWsUmdXhykKPqhI
	yB8tDwqmvyFG2KhextLm/2MizwF9Gs24uVkr0wZAdTw0aohbCr3Wq7l4XIPyhDWcI6dind
	YBw1H43uv9oWH51+4EtfMDEbIRWIRZM=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749805481;
	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=pL8BIAz+3TknRN85zYSjBUUnsd8cQe8ZmaDYWneQEX4=;
	b=HalWXNLaE7Vnen/y3IUTrNChIYVpQFAQgFkhF6W9Dw/fI0wQ4I4IegcpQmHfHXBFuyyOKW
	k7G6Hf7H/Y9PYtCg==
From: Thomas Zimmermann 
To: simona@ffwll.ch,
	airlied@gmail.com,
	mripard@kernel.org,
	maarten.lankhorst@linux.intel.com,
	geert@linux-m68k.org,
	tomi.valkeinen@ideasonboard.com
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann ,
	Patrik Jakobsson 
Subject: [PATCH v5 08/25] drm/gma500: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Fri, 13 Jun 2025 11:00:27 +0200
Message-ID: <20250613090431.127087-9-tzimmermann@suse.de>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250613090431.127087-1-tzimmermann@suse.de>
References: <20250613090431.127087-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-5.30 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	MID_CONTAINS_FROM(1.00)[];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	URIBL_BLOCKED(0.00)[imap1.dmz-prg2.suse.org:helo,suse.de:email,suse.de:mid];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	RCPT_COUNT_TWELVE(0.00)[22];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_TO(0.00)[ffwll.ch,gmail.com,kernel.org,linux.intel.com,linux-m68k.org,ideasonboard.com];
	FREEMAIL_ENVRCPT(0.00)[gmail.com];
	FREEMAIL_CC(0.00)[lists.freedesktop.org,lists.infradead.org,vger.kernel.org,lists.linux.dev,lists.xenproject.org,suse.de,gmail.com];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	TAGGED_RCPT(0.00)[];
	R_RATELIMIT(0.00)[to_ip_from(RLqirfcw6gnbcr9a9yhi49fhi6)];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:email,suse.de:mid]
X-Spam-Level: 
X-Spam-Flag: NO
X-Spam-Score: -5.30

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 64.

Signed-off-by: Thomas Zimmermann 
Cc: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/gem.c | 21 ++++++---------------
 1 file changed, 6 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
index 4b7627a72637..fc337db0a948 100644
--- a/drivers/gpu/drm/gma500/gem.c
+++ b/drivers/gpu/drm/gma500/gem.c
@@ -16,6 +16,7 @@
 #include 
 
 #include 
+#include 
 #include 
 
 #include "gem.h"
@@ -199,35 +200,25 @@ psb_gem_create(struct drm_device *dev, u64 size, const char *name, bool stolen,
 int psb_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
 			struct drm_mode_create_dumb *args)
 {
-	size_t pitch, size;
 	struct psb_gem_object *pobj;
 	struct drm_gem_object *obj;
-	u32 handle;
 	int ret;
 
-	pitch = args->width * DIV_ROUND_UP(args->bpp, 8);
-	pitch = ALIGN(pitch, 64);
-
-	size = pitch * args->height;
-	size = roundup(size, PAGE_SIZE);
-	if (!size)
-		return -EINVAL;
+	ret = drm_mode_size_dumb(dev, args, SZ_64, 0);
+	if (ret)
+		return ret;
 
-	pobj = psb_gem_create(dev, size, "gem", false, PAGE_SIZE);
+	pobj = psb_gem_create(dev, args->size, "gem", false, PAGE_SIZE);
 	if (IS_ERR(pobj))
 		return PTR_ERR(pobj);
 	obj = &pobj->base;
 
-	ret = drm_gem_handle_create(file, obj, &handle);
+	ret = drm_gem_handle_create(file, obj, &args->handle);
 	if (ret)
 		goto err_drm_gem_object_put;
 
 	drm_gem_object_put(obj);
 
-	args->pitch = pitch;
-	args->size = size;
-	args->handle = handle;
-
 	return 0;
 
 err_drm_gem_object_put:
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 09:05:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 09:05:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013959.1392245 (Exim 4.92)
	(envelope-from )
	id 1uQ0LN-0006Gx-Jc; Fri, 13 Jun 2025 09:05:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013959.1392245; Fri, 13 Jun 2025 09: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 1uQ0LN-0006GZ-DH; Fri, 13 Jun 2025 09:05:01 +0000
Received: by outflank-mailman (input) for mailman id 1013959;
 Fri, 13 Jun 2025 09: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 1uQ0LM-0002e2-1f
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 09:05: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 746b4825-4835-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 11:04:47 +0200 (CEST)
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 D93101F891;
 Fri, 13 Jun 2025 09:04:42 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 11BCF137FE;
 Fri, 13 Jun 2025 09:04:42 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id mOb7AqrpS2inNAAAD6G6ig
 (envelope-from ); Fri, 13 Jun 2025 09:04: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: 746b4825-4835-11f0-b894-0df219b8e170
Authentication-Results: smtp-out2.suse.de;
	none
From: Thomas Zimmermann 
To: simona@ffwll.ch,
	airlied@gmail.com,
	mripard@kernel.org,
	maarten.lankhorst@linux.intel.com,
	geert@linux-m68k.org,
	tomi.valkeinen@ideasonboard.com
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann ,
	Philipp Zabel ,
	Shawn Guo ,
	Sascha Hauer ,
	Pengutronix Kernel Team ,
	Fabio Estevam 
Subject: [PATCH v5 10/25] drm/imx/ipuv3: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Fri, 13 Jun 2025 11:00:29 +0200
Message-ID: <20250613090431.127087-11-tzimmermann@suse.de>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250613090431.127087-1-tzimmermann@suse.de>
References: <20250613090431.127087-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Spam-Level: 
X-Spamd-Result: default: False [-4.00 / 50.00];
	REPLY(-4.00)[]
X-Spam-Flag: NO
X-Rspamd-Queue-Id: D93101F891
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Action: no action
X-Spam-Score: -4.00

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. The hardware requires the framebuffer width to be a
multiple of 8. The scanline pitch has to be large enough to support
this. Therefore compute the byte size of 8 pixels in the given color
mode and align the pitch accordingly.

v5:
- fix typo in commit description

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Philipp Zabel 
Cc: Philipp Zabel 
Cc: Shawn Guo 
Cc: Sascha Hauer 
Cc: Pengutronix Kernel Team 
Cc: Fabio Estevam 
---
 drivers/gpu/drm/imx/ipuv3/imx-drm-core.c | 31 ++++++++++++++++++------
 1 file changed, 23 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c b/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
index af4a30311e18..465b5a6ad5bb 100644
--- a/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
@@ -17,7 +17,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -141,19 +143,32 @@ static int imx_drm_dumb_create(struct drm_file *file_priv,
 			       struct drm_device *drm,
 			       struct drm_mode_create_dumb *args)
 {
-	u32 width = args->width;
+	u32 fourcc;
+	const struct drm_format_info *info;
+	u64 pitch_align;
 	int ret;
 
-	args->width = ALIGN(width, 8);
-	args->pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
-	args->size = args->pitch * args->height;
-
-	ret = drm_gem_dma_dumb_create_internal(file_priv, drm, args);
+	/*
+	 * Hardware requires the framebuffer width to be aligned to
+	 * multiples of 8. The mode-setting code handles this, but
+	 * the buffer pitch has to be aligned as well. Set the pitch
+	 * alignment accordingly, so that the each scanline fits into
+	 * the allocated buffer.
+	 */
+	fourcc = drm_driver_color_mode_format(drm, args->bpp);
+	if (fourcc == DRM_FORMAT_INVALID)
+		return -EINVAL;
+	info = drm_format_info(fourcc);
+	if (!info)
+		return -EINVAL;
+	pitch_align = drm_format_info_min_pitch(info, 0, SZ_8);
+	if (!pitch_align || pitch_align > U32_MAX)
+		return -EINVAL;
+	ret = drm_mode_size_dumb(drm, args, pitch_align, 0);
 	if (ret)
 		return ret;
 
-	args->width = width;
-	return ret;
+	return drm_gem_dma_dumb_create(file_priv, drm, args);
 }
 
 static const struct drm_driver imx_drm_driver = {
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 09:10:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 09:10:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1013991.1392255 (Exim 4.92)
	(envelope-from )
	id 1uQ0Qp-0001Nv-7y; Fri, 13 Jun 2025 09:10:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1013991.1392255; Fri, 13 Jun 2025 09: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 1uQ0Qp-0001No-5A; Fri, 13 Jun 2025 09:10:39 +0000
Received: by outflank-mailman (input) for mailman id 1013991;
 Fri, 13 Jun 2025 09:10: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 1uQ0LU-0002BZ-G3
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 09:05:08 +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 7db4a5dd-4835-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 11:05:02 +0200 (CEST)
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 9D1041F88C;
 Fri, 13 Jun 2025 09:04: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 0F8CD137FE;
 Fri, 13 Jun 2025 09:04: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 MI1tAqvpS2inNAAAD6G6ig
 (envelope-from ); Fri, 13 Jun 2025 09:04:43 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7db4a5dd-4835-11f0-a309-13f23c93f187
Authentication-Results: smtp-out2.suse.de;
	none
From: Thomas Zimmermann 
To: simona@ffwll.ch,
	airlied@gmail.com,
	mripard@kernel.org,
	maarten.lankhorst@linux.intel.com,
	geert@linux-m68k.org,
	tomi.valkeinen@ideasonboard.com
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann ,
	Sui Jingfeng 
Subject: [PATCH v5 11/25] drm/loongson: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Fri, 13 Jun 2025 11:00:30 +0200
Message-ID: <20250613090431.127087-12-tzimmermann@suse.de>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250613090431.127087-1-tzimmermann@suse.de>
References: <20250613090431.127087-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Spamd-Result: default: False [-4.00 / 50.00];
	REPLY(-4.00)[]
X-Rspamd-Queue-Id: 9D1041F88C
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Action: no action
X-Spam-Level: 
X-Spam-Flag: NO
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Score: -4.00

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch according to hardware requirements.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Sui Jingfeng 
Cc: Sui Jingfeng 
---
 drivers/gpu/drm/loongson/lsdc_gem.c | 29 ++++++++---------------------
 1 file changed, 8 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/loongson/lsdc_gem.c b/drivers/gpu/drm/loongson/lsdc_gem.c
index a720d8f53209..9f982b85301f 100644
--- a/drivers/gpu/drm/loongson/lsdc_gem.c
+++ b/drivers/gpu/drm/loongson/lsdc_gem.c
@@ -6,6 +6,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -204,45 +205,31 @@ int lsdc_dumb_create(struct drm_file *file, struct drm_device *ddev,
 	const struct lsdc_desc *descp = ldev->descp;
 	u32 domain = LSDC_GEM_DOMAIN_VRAM;
 	struct drm_gem_object *gobj;
-	size_t size;
-	u32 pitch;
-	u32 handle;
 	int ret;
 
-	if (!args->width || !args->height)
-		return -EINVAL;
-
-	if (args->bpp != 32 && args->bpp != 16)
-		return -EINVAL;
-
-	pitch = args->width * args->bpp / 8;
-	pitch = ALIGN(pitch, descp->pitch_align);
-	size = pitch * args->height;
-	size = ALIGN(size, PAGE_SIZE);
+	ret = drm_mode_size_dumb(ddev, args, descp->pitch_align, 0);
+	if (ret)
+		return ret;
 
 	/* Maximum single bo size allowed is the half vram size available */
-	if (size > ldev->vram_size / 2) {
-		drm_err(ddev, "Requesting(%zuMiB) failed\n", size >> 20);
+	if (args->size > ldev->vram_size / 2) {
+		drm_err(ddev, "Requesting(%zuMiB) failed\n", (size_t)(args->size >> PAGE_SHIFT));
 		return -ENOMEM;
 	}
 
-	gobj = lsdc_gem_object_create(ddev, domain, size, false, NULL, NULL);
+	gobj = lsdc_gem_object_create(ddev, domain, args->size, false, NULL, NULL);
 	if (IS_ERR(gobj)) {
 		drm_err(ddev, "Failed to create gem object\n");
 		return PTR_ERR(gobj);
 	}
 
-	ret = drm_gem_handle_create(file, gobj, &handle);
+	ret = drm_gem_handle_create(file, gobj, &args->handle);
 
 	/* drop reference from allocate, handle holds it now */
 	drm_gem_object_put(gobj);
 	if (ret)
 		return ret;
 
-	args->pitch = pitch;
-	args->size = size;
-	args->handle = handle;
-
 	return 0;
 }
 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 09:11:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 09:11:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014011.1392264 (Exim 4.92)
	(envelope-from )
	id 1uQ0Rb-0002Ee-Jd; Fri, 13 Jun 2025 09:11:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014011.1392264; Fri, 13 Jun 2025 09:11:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uQ0Rb-0002EX-H3; Fri, 13 Jun 2025 09:11:27 +0000
Received: by outflank-mailman (input) for mailman id 1014011;
 Fri, 13 Jun 2025 09:11: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 1uQ0Lu-0002BZ-A1
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 09:05:34 +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 90312038-4835-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 11:05:34 +0200 (CEST)
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 EF9B41F8A8;
 Fri, 13 Jun 2025 09:04:53 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 62C7213A9C;
 Fri, 13 Jun 2025 09:04:53 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id eCq/FrXpS2inNAAAD6G6ig
 (envelope-from ); Fri, 13 Jun 2025 09:04: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: 90312038-4835-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749805494; 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=xTgJLZKjv1ShNDiAP6gz2e2IBWIMv9+AKE3JgrfHkhY=;
	b=rn6TtKGPOJFjUMFwbSCJZfAkpnCGSmgDNkjnf/6To20/nOznZ/odaS1mr2MD2JpTgph0Lc
	Jhz/eiLZN72mNMs8kA8onVO+3x28S59aRsqOX0xFOHYROP9AeRrVw0ArWqBR4G14ktRi/b
	qEzXSiJCRFe+4cAih2yx9mEBcHaJGb8=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749805494;
	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=xTgJLZKjv1ShNDiAP6gz2e2IBWIMv9+AKE3JgrfHkhY=;
	b=f0RIyjapDNaqegxghUGTlgNwmkujbOrE2wlhF0Oy99TvxOmzchXRGN2Vf83d/rhmLHYcxk
	M/dcwZkEFKZF4iAA==
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749805493; 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=xTgJLZKjv1ShNDiAP6gz2e2IBWIMv9+AKE3JgrfHkhY=;
	b=O6Z0PRGPpq8mmeve6mEtv2wlDyR3y4S617WpIQTDLVGyU5wuFemZB68O8J5ngmSWkIhtLj
	xyoqh0PR2FCuuxDLNRwv4jOFam7oa8P0Lek5eCKAMkUJp4DYlkA1mu8nH5WJu9ug6B72Gv
	liWA+CEHcnaG23m9PlyRvCNaEkGzkhg=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749805493;
	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=xTgJLZKjv1ShNDiAP6gz2e2IBWIMv9+AKE3JgrfHkhY=;
	b=GxplLMXkE2H32FCXiXASCcEVUHD/OZuHNzugRRtn2fz2Qc/U+QCSPGp/8hgatFA36DcWVs
	cnySRfhImxN7gKDw==
From: Thomas Zimmermann 
To: simona@ffwll.ch,
	airlied@gmail.com,
	mripard@kernel.org,
	maarten.lankhorst@linux.intel.com,
	geert@linux-m68k.org,
	tomi.valkeinen@ideasonboard.com
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann ,
	Laurent Pinchart 
Subject: [PATCH v5 25/25] drm/xlnx: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Fri, 13 Jun 2025 11:00:44 +0200
Message-ID: <20250613090431.127087-26-tzimmermann@suse.de>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250613090431.127087-1-tzimmermann@suse.de>
References: <20250613090431.127087-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-5.30 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-0.999];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_TO(0.00)[ffwll.ch,gmail.com,kernel.org,linux.intel.com,linux-m68k.org,ideasonboard.com];
	MIME_TRACE(0.00)[0:+];
	TO_DN_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[22];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	RCVD_TLS_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	R_RATELIMIT(0.00)[to_ip_from(RLqirfcw6gnbcr9a9yhi49fhi6)];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	URIBL_BLOCKED(0.00)[suse.de:email,suse.de:mid,imap1.dmz-prg2.suse.org:helo];
	RCVD_COUNT_TWO(0.00)[2];
	DBL_BLOCKED_OPENRESOLVER(0.00)[ideasonboard.com:email,suse.de:email,suse.de:mid];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Spam-Level: 
X-Spam-Flag: NO
X-Spam-Score: -5.30

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch according to hardware requirements.

Signed-off-by: Thomas Zimmermann 
Cc: Laurent Pinchart 
Cc: Tomi Valkeinen 
---
 drivers/gpu/drm/xlnx/zynqmp_kms.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c b/drivers/gpu/drm/xlnx/zynqmp_kms.c
index b47463473472..7ea0cd4f71d3 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_kms.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -363,10 +364,12 @@ static int zynqmp_dpsub_dumb_create(struct drm_file *file_priv,
 				    struct drm_mode_create_dumb *args)
 {
 	struct zynqmp_dpsub *dpsub = to_zynqmp_dpsub(drm);
-	unsigned int pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
+	int ret;
 
 	/* Enforce the alignment constraints of the DMA engine. */
-	args->pitch = ALIGN(pitch, dpsub->dma_align);
+	ret = drm_mode_size_dumb(drm, args, dpsub->dma_align, 0);
+	if (ret)
+		return ret;
 
 	return drm_gem_dma_dumb_create_internal(file_priv, drm, args);
 }
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 09:11:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 09:11:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014014.1392275 (Exim 4.92)
	(envelope-from )
	id 1uQ0Rf-0002VX-Rd; Fri, 13 Jun 2025 09:11:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014014.1392275; Fri, 13 Jun 2025 09:11:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uQ0Rf-0002VO-Oa; Fri, 13 Jun 2025 09:11:31 +0000
Received: by outflank-mailman (input) for mailman id 1014014;
 Fri, 13 Jun 2025 09:11:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uQ0LL-0002BZ-Dd
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 09:04:59 +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 7b2848a5-4835-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 11:04:59 +0200 (CEST)
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 1D02A2127F;
 Fri, 13 Jun 2025 09:04:50 +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 20C8F137FE;
 Fri, 13 Jun 2025 09:04: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 OJSgBrHpS2inNAAAD6G6ig
 (envelope-from ); Fri, 13 Jun 2025 09:04: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: 7b2848a5-4835-11f0-a309-13f23c93f187
Authentication-Results: smtp-out1.suse.de;
	none
From: Thomas Zimmermann 
To: simona@ffwll.ch,
	airlied@gmail.com,
	mripard@kernel.org,
	maarten.lankhorst@linux.intel.com,
	geert@linux-m68k.org,
	tomi.valkeinen@ideasonboard.com
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann ,
	Thierry Reding ,
	Thierry Reding ,
	Mikko Perttunen 
Subject: [PATCH v5 20/25] drm/tegra: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Fri, 13 Jun 2025 11:00:39 +0200
Message-ID: <20250613090431.127087-21-tzimmermann@suse.de>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250613090431.127087-1-tzimmermann@suse.de>
References: <20250613090431.127087-1-tzimmermann@suse.de>
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)[];
	TAGGED_RCPT(0.00)[]
X-Rspamd-Queue-Id: 1D02A2127F
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Action: no action
X-Spam-Level: 
X-Spam-Flag: NO
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Score: -4.00

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch according to hardware requirements.

Signed-off-by: Thomas Zimmermann 
Acked-by: Thierry Reding 
Cc: Thierry Reding 
Cc: Mikko Perttunen 
---
 drivers/gpu/drm/tegra/gem.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index dbc1394f96b8..9b9dabbc8ec9 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -16,6 +16,7 @@
 #include 
 
 #include 
+#include 
 #include 
 
 #include "drm.h"
@@ -542,12 +543,13 @@ void tegra_bo_free_object(struct drm_gem_object *gem)
 int tegra_bo_dumb_create(struct drm_file *file, struct drm_device *drm,
 			 struct drm_mode_create_dumb *args)
 {
-	unsigned int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
 	struct tegra_drm *tegra = drm->dev_private;
 	struct tegra_bo *bo;
+	int ret;
 
-	args->pitch = round_up(min_pitch, tegra->pitch_align);
-	args->size = args->pitch * args->height;
+	ret = drm_mode_size_dumb(drm, args, tegra->pitch_align, 0);
+	if (ret)
+		return ret;
 
 	bo = tegra_bo_create_with_handle(file, drm, args->size, 0,
 					 &args->handle);
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 09:11:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 09:11:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014015.1392280 (Exim 4.92)
	(envelope-from )
	id 1uQ0Rg-0002Xo-5r; Fri, 13 Jun 2025 09:11:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014015.1392280; Fri, 13 Jun 2025 09:11: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 1uQ0Rf-0002XK-V9; Fri, 13 Jun 2025 09:11:31 +0000
Received: by outflank-mailman (input) for mailman id 1014015;
 Fri, 13 Jun 2025 09:11:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uQ0LR-0002BZ-FG
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 09:05:05 +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 7d5e4adb-4835-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 11:05:02 +0200 (CEST)
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 6436921282;
 Fri, 13 Jun 2025 09:04:51 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id C6143137FE;
 Fri, 13 Jun 2025 09:04:50 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id sAX9LrLpS2inNAAAD6G6ig
 (envelope-from ); Fri, 13 Jun 2025 09:04: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: 7d5e4adb-4835-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749805491; 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=7jf9qOExxDcSOt4izp67/OXl6KEF+Jd/H4a7h9LsPuc=;
	b=OpvkHcV1/2de0xS4OZzHVt9N8jm2reUe5KPT9bWKoZ9u4z1dvB8sO7YYkQVOyDC7JLzXrr
	cvbV4vCNMIdtMSVxhO1smLBtMckCpfjFbUvWdvpBwoOGjK8llf8bXPfCzxP0Nh4BF+kTy4
	3kVow4aDqx4epsUoxiGzL6JpexbF2vI=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749805491;
	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=7jf9qOExxDcSOt4izp67/OXl6KEF+Jd/H4a7h9LsPuc=;
	b=uh5rpvHS8JlHCsb5KBUR7mEQa3z2/atdoBMkNf0dIomDDg2iOAkRvf0OrFRgb/vopVkntg
	CudKOkXm40sL13Cg==
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749805491; 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=7jf9qOExxDcSOt4izp67/OXl6KEF+Jd/H4a7h9LsPuc=;
	b=OpvkHcV1/2de0xS4OZzHVt9N8jm2reUe5KPT9bWKoZ9u4z1dvB8sO7YYkQVOyDC7JLzXrr
	cvbV4vCNMIdtMSVxhO1smLBtMckCpfjFbUvWdvpBwoOGjK8llf8bXPfCzxP0Nh4BF+kTy4
	3kVow4aDqx4epsUoxiGzL6JpexbF2vI=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749805491;
	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=7jf9qOExxDcSOt4izp67/OXl6KEF+Jd/H4a7h9LsPuc=;
	b=uh5rpvHS8JlHCsb5KBUR7mEQa3z2/atdoBMkNf0dIomDDg2iOAkRvf0OrFRgb/vopVkntg
	CudKOkXm40sL13Cg==
From: Thomas Zimmermann 
To: simona@ffwll.ch,
	airlied@gmail.com,
	mripard@kernel.org,
	maarten.lankhorst@linux.intel.com,
	geert@linux-m68k.org,
	tomi.valkeinen@ideasonboard.com
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann ,
	Zack Rusin ,
	Broadcom internal kernel review list 
Subject: [PATCH v5 22/25] drm/vmwgfx: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Fri, 13 Jun 2025 11:00:41 +0200
Message-ID: <20250613090431.127087-23-tzimmermann@suse.de>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250613090431.127087-1-tzimmermann@suse.de>
References: <20250613090431.127087-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Flag: NO
X-Spam-Score: -5.30
X-Spamd-Result: default: False [-5.30 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-0.999];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_TO(0.00)[ffwll.ch,gmail.com,kernel.org,linux.intel.com,linux-m68k.org,ideasonboard.com];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[23];
	ARC_NA(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:mid,suse.de:email];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Spam-Level: 

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch
and buffer size. No alignment required.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Zack Rusin 
Cc: Zack Rusin 
Cc: Broadcom internal kernel review list 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 21 ++++-----------------
 1 file changed, 4 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
index 7e281c3c6bc5..c4ac9b47e23a 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
@@ -15,6 +15,7 @@
 #include "vmw_surface_cache.h"
 #include "device_include/svga3d_surfacedefs.h"
 
+#include 
 #include 
 
 #define SVGA3D_FLAGS_64(upper32, lower32) (((uint64_t)upper32 << 32) | lower32)
@@ -2267,23 +2268,9 @@ int vmw_dumb_create(struct drm_file *file_priv,
 	 * contents is going to be rendered guest side.
 	 */
 	if (!dev_priv->has_mob || !vmw_supports_3d(dev_priv)) {
-		int cpp = DIV_ROUND_UP(args->bpp, 8);
-
-		switch (cpp) {
-		case 1: /* DRM_FORMAT_C8 */
-		case 2: /* DRM_FORMAT_RGB565 */
-		case 4: /* DRM_FORMAT_XRGB8888 */
-			break;
-		default:
-			/*
-			 * Dumb buffers don't allow anything else.
-			 * This is tested via IGT's dumb_buffers
-			 */
-			return -EINVAL;
-		}
-
-		args->pitch = args->width * cpp;
-		args->size = ALIGN(args->pitch * args->height, PAGE_SIZE);
+		ret = drm_mode_size_dumb(dev, args, 0, 0);
+		if (ret)
+			return ret;
 
 		ret = vmw_gem_object_create_with_handle(dev_priv, file_priv,
 							args->size, &args->handle,
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 09:11:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 09:11:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014017.1392295 (Exim 4.92)
	(envelope-from )
	id 1uQ0Rj-00032T-8b; Fri, 13 Jun 2025 09:11:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014017.1392295; Fri, 13 Jun 2025 09:11: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 1uQ0Rj-00032I-5Y; Fri, 13 Jun 2025 09:11:35 +0000
Received: by outflank-mailman (input) for mailman id 1014017;
 Fri, 13 Jun 2025 09:11: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 1uQ0Lh-0002BZ-J7
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 09:05:21 +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 85ba3f5d-4835-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 11:05:16 +0200 (CEST)
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 CF6921F897;
 Fri, 13 Jun 2025 09:04: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 3DFB3137FE;
 Fri, 13 Jun 2025 09:04: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 QPrGDa7pS2inNAAAD6G6ig
 (envelope-from ); Fri, 13 Jun 2025 09:04: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: 85ba3f5d-4835-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749805487; 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=DHZMHDqNQEonF81TK7C5w/D5ujQorpHJgouEZhO5vTM=;
	b=OdRRhCeDToJKRET8bZrXx9jE0JJsPZ9Ogbqwp4t534YZOsn/SfTTeXmvP1iho7eDalySm9
	wjxwkkEnQAILvAs5k+mStWKoXHEGvfB4QMJ+AwHRZzodZcdgz2QNJst80MEJWcdSiQxqfo
	m8f8taqR4dnS/rZVuMn9pZiwtmiPNCc=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749805487;
	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=DHZMHDqNQEonF81TK7C5w/D5ujQorpHJgouEZhO5vTM=;
	b=aywiWwJHCZSLu93x7DBxdNP2ASDS/QFOjegpuAuAyZzMD2aGSuuKyYXWlBg8HJGRrW5TBg
	5mXQ+9CgXZKDLnBQ==
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749805486; 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=DHZMHDqNQEonF81TK7C5w/D5ujQorpHJgouEZhO5vTM=;
	b=q/nH7Kk4uqKgGZfhVgLlnEEVnC7PDrPtfb8/L1H+1Xc9wRtrRiMxUK2dPVe2q+Ytql7MnJ
	upEZExufWFauuuIHayHwALWJNI9edaClgXOs690+gjjwoj/3DEG/lBiYPnchwJvaTblXjp
	uzuxM+IvCzM/m4gHPp1Ew5kZmIwdERc=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749805486;
	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=DHZMHDqNQEonF81TK7C5w/D5ujQorpHJgouEZhO5vTM=;
	b=RIl8rHiOjvj9M3pvRC6bQ1UxaIxZU62hp/HwPwgp2Ih/Farun+pxuszzWDdIoIQETcqa+H
	SaMaSgXqDgUMBJAg==
From: Thomas Zimmermann 
To: simona@ffwll.ch,
	airlied@gmail.com,
	mripard@kernel.org,
	maarten.lankhorst@linux.intel.com,
	geert@linux-m68k.org,
	tomi.valkeinen@ideasonboard.com
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann ,
	Dave Airlie ,
	Gerd Hoffmann 
Subject: [PATCH v5 16/25] drm/qxl: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Fri, 13 Jun 2025 11:00:35 +0200
Message-ID: <20250613090431.127087-17-tzimmermann@suse.de>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250613090431.127087-1-tzimmermann@suse.de>
References: <20250613090431.127087-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Flag: NO
X-Spam-Score: -5.30
X-Spamd-Result: default: False [-5.30 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-0.999];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_TO(0.00)[ffwll.ch,gmail.com,kernel.org,linux.intel.com,linux-m68k.org,ideasonboard.com];
	MIME_TRACE(0.00)[0:+];
	TO_DN_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[23];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	R_RATELIMIT(0.00)[to_ip_from(RLqirfcw6gnbcr9a9yhi49fhi6)];
	RCVD_TLS_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:mid,suse.de:email];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Spam-Level: 

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch
and buffer size. No alignment required.

Signed-off-by: Thomas Zimmermann 
Cc: Dave Airlie 
Cc: Gerd Hoffmann 
---
 drivers/gpu/drm/qxl/qxl_dumb.c | 17 ++++++++---------
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_dumb.c b/drivers/gpu/drm/qxl/qxl_dumb.c
index 17df5c7ccf69..1200946767ce 100644
--- a/drivers/gpu/drm/qxl/qxl_dumb.c
+++ b/drivers/gpu/drm/qxl/qxl_dumb.c
@@ -23,6 +23,8 @@
  *          Alon Levy
  */
 
+#include 
+
 #include "qxl_drv.h"
 #include "qxl_object.h"
 
@@ -35,14 +37,13 @@ int qxl_mode_dumb_create(struct drm_file *file_priv,
 	struct qxl_device *qdev = to_qxl(dev);
 	struct qxl_bo *qobj;
 	struct drm_gem_object *gobj;
-	uint32_t handle;
 	int r;
 	struct qxl_surface surf;
-	uint32_t pitch, format;
+	u32 format;
 
-	pitch = args->width * ((args->bpp + 1) / 8);
-	args->size = pitch * args->height;
-	args->size = ALIGN(args->size, PAGE_SIZE);
+	r = drm_mode_size_dumb(dev, args, 0, 0);
+	if (r)
+		return r;
 
 	switch (args->bpp) {
 	case 16:
@@ -57,20 +58,18 @@ int qxl_mode_dumb_create(struct drm_file *file_priv,
 
 	surf.width = args->width;
 	surf.height = args->height;
-	surf.stride = pitch;
+	surf.stride = args->pitch;
 	surf.format = format;
 	surf.data = 0;
 
 	r = qxl_gem_object_create_with_handle(qdev, file_priv,
 					      QXL_GEM_DOMAIN_CPU,
 					      args->size, &surf, &gobj,
-					      &handle);
+					      &args->handle);
 	if (r)
 		return r;
 	qobj = gem_to_qxl_bo(gobj);
 	qobj->is_dumb = true;
 	drm_gem_object_put(gobj);
-	args->pitch = pitch;
-	args->handle = handle;
 	return 0;
 }
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 09:11:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 09:11:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014029.1392305 (Exim 4.92)
	(envelope-from )
	id 1uQ0Rw-0003r2-HS; Fri, 13 Jun 2025 09:11:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014029.1392305; Fri, 13 Jun 2025 09: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 1uQ0Rw-0003qC-Ej; Fri, 13 Jun 2025 09:11:48 +0000
Received: by outflank-mailman (input) for mailman id 1014029;
 Fri, 13 Jun 2025 09: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 1uQ0Lc-0002BZ-Hv
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 09:05:16 +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 821aa037-4835-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 11:05:10 +0200 (CEST)
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 016D11F892;
 Fri, 13 Jun 2025 09:04:45 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 54C7D13A9C;
 Fri, 13 Jun 2025 09:04: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 mGBYE6zpS2inNAAAD6G6ig
 (envelope-from ); Fri, 13 Jun 2025 09:04: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: 821aa037-4835-11f0-a309-13f23c93f187
Authentication-Results: smtp-out2.suse.de;
	none
From: Thomas Zimmermann 
To: simona@ffwll.ch,
	airlied@gmail.com,
	mripard@kernel.org,
	maarten.lankhorst@linux.intel.com,
	geert@linux-m68k.org,
	tomi.valkeinen@ideasonboard.com
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann ,
	Dmitry Baryshkov ,
	Rob Clark ,
	Abhinav Kumar ,
	Sean Paul ,
	Marijn Suijten 
Subject: [PATCH v5 13/25] drm/msm: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Fri, 13 Jun 2025 11:00:32 +0200
Message-ID: <20250613090431.127087-14-tzimmermann@suse.de>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250613090431.127087-1-tzimmermann@suse.de>
References: <20250613090431.127087-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Spamd-Result: default: False [-4.00 / 50.00];
	REPLY(-4.00)[]
X-Rspamd-Queue-Id: 016D11F892
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Action: no action
X-Spam-Level: 
X-Spam-Flag: NO
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Score: -4.00

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch
and buffer size. Alignment is specified in bytes, but the hardware
requires the scanline pitch to be a multiple of 32 pixels. Therefore
compute the byte size of 32 pixels in the given color mode and align
the pitch accordingly. This replaces the existing code in the driver's
align_pitch() helper.

v3:
- clarify pitch alignment in commit message (Dmitry)

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Dmitry Baryshkov 
Cc: Rob Clark 
Cc: Abhinav Kumar 
Cc: Dmitry Baryshkov 
Cc: Sean Paul 
Cc: Marijn Suijten 
---
 drivers/gpu/drm/msm/msm_gem.c | 27 +++++++++++++++++++++++++--
 1 file changed, 25 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 2995e80fec3b..dd9d64537cd9 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -11,8 +11,10 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -700,8 +702,29 @@ void msm_gem_unpin_iova(struct drm_gem_object *obj,
 int msm_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
 		struct drm_mode_create_dumb *args)
 {
-	args->pitch = align_pitch(args->width, args->bpp);
-	args->size  = PAGE_ALIGN(args->pitch * args->height);
+	u32 fourcc;
+	const struct drm_format_info *info;
+	u64 pitch_align;
+	int ret;
+
+	/*
+	 * Adreno needs pitch aligned to 32 pixels. Compute the number
+	 * of bytes for a block of 32 pixels at the given color format.
+	 * Use the result as pitch alignment.
+	 */
+	fourcc = drm_driver_color_mode_format(dev, args->bpp);
+	if (fourcc == DRM_FORMAT_INVALID)
+		return -EINVAL;
+	info = drm_format_info(fourcc);
+	if (!info)
+		return -EINVAL;
+	pitch_align = drm_format_info_min_pitch(info, 0, SZ_32);
+	if (!pitch_align || pitch_align > U32_MAX)
+		return -EINVAL;
+	ret = drm_mode_size_dumb(dev, args, pitch_align, 0);
+	if (ret)
+		return ret;
+
 	return msm_gem_new_handle(dev, file, args->size,
 			MSM_BO_SCANOUT | MSM_BO_WC, &args->handle, "dumb");
 }
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 09:12:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 09:12:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014046.1392315 (Exim 4.92)
	(envelope-from )
	id 1uQ0SA-0004et-U6; Fri, 13 Jun 2025 09:12:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014046.1392315; Fri, 13 Jun 2025 09:12:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uQ0SA-0004ei-QR; Fri, 13 Jun 2025 09:12:02 +0000
Received: by outflank-mailman (input) for mailman id 1014046;
 Fri, 13 Jun 2025 09:12: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 1uQ0Lf-0002BZ-IX
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 09:05:19 +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 83e6370f-4835-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 11:05:13 +0200 (CEST)
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 9E5101F896;
 Fri, 13 Jun 2025 09:04:45 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 08101137FE;
 Fri, 13 Jun 2025 09:04:45 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id YEKZAK3pS2inNAAAD6G6ig
 (envelope-from ); Fri, 13 Jun 2025 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: 83e6370f-4835-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749805485; 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=xV/rClDUfCgVuPmCSOActQIgsfxDY8oPQuweoA/ffSQ=;
	b=qlMVT7vNnHSOv/vpD9RlSdHxWD5rt2xTwEa4OyBEYDldmyOf91q6YH+0UT6dCwTnv21J93
	/wsmjqPkelxg8CEiHED+kyCpl3Afc+9g5WZDus45IjX8oKeLXMAbhYbdNdvz2ggcwR+yML
	bh6Da6LIug8bTZVjB/koBhHGJjKkOsE=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749805485;
	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=xV/rClDUfCgVuPmCSOActQIgsfxDY8oPQuweoA/ffSQ=;
	b=Tgeyfox/qBVuHOt4rI8xForvg1EsZ92vf7KpmnOhb9lYz2nkl1rFZs6XwvUforXArhGLYo
	30lqTT0xfRRelNAQ==
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749805485; 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=xV/rClDUfCgVuPmCSOActQIgsfxDY8oPQuweoA/ffSQ=;
	b=qlMVT7vNnHSOv/vpD9RlSdHxWD5rt2xTwEa4OyBEYDldmyOf91q6YH+0UT6dCwTnv21J93
	/wsmjqPkelxg8CEiHED+kyCpl3Afc+9g5WZDus45IjX8oKeLXMAbhYbdNdvz2ggcwR+yML
	bh6Da6LIug8bTZVjB/koBhHGJjKkOsE=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749805485;
	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=xV/rClDUfCgVuPmCSOActQIgsfxDY8oPQuweoA/ffSQ=;
	b=Tgeyfox/qBVuHOt4rI8xForvg1EsZ92vf7KpmnOhb9lYz2nkl1rFZs6XwvUforXArhGLYo
	30lqTT0xfRRelNAQ==
From: Thomas Zimmermann 
To: simona@ffwll.ch,
	airlied@gmail.com,
	mripard@kernel.org,
	maarten.lankhorst@linux.intel.com,
	geert@linux-m68k.org,
	tomi.valkeinen@ideasonboard.com
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann ,
	Lyude Paul ,
	Karol Herbst ,
	Danilo Krummrich 
Subject: [PATCH v5 14/25] drm/nouveau: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Fri, 13 Jun 2025 11:00:33 +0200
Message-ID: <20250613090431.127087-15-tzimmermann@suse.de>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250613090431.127087-1-tzimmermann@suse.de>
References: <20250613090431.127087-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Flag: NO
X-Spam-Score: -5.30
X-Spamd-Result: default: False [-5.30 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-0.999];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_TO(0.00)[ffwll.ch,gmail.com,kernel.org,linux.intel.com,linux-m68k.org,ideasonboard.com];
	MIME_TRACE(0.00)[0:+];
	TO_DN_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[24];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	R_RATELIMIT(0.00)[to_ip_from(RLqirfcw6gnbcr9a9yhi49fhi6)];
	RCVD_TLS_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:mid,suse.de:email];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Spam-Level: 

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 256.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Lyude Paul 
Cc: Karol Herbst 
Cc: Lyude Paul 
Cc: Danilo Krummrich 
---
 drivers/gpu/drm/nouveau/nouveau_display.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c
index add006fc8d81..daa2528f9c9a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -808,9 +809,9 @@ nouveau_display_dumb_create(struct drm_file *file_priv, struct drm_device *dev,
 	uint32_t domain;
 	int ret;
 
-	args->pitch = roundup(args->width * (args->bpp / 8), 256);
-	args->size = args->pitch * args->height;
-	args->size = roundup(args->size, PAGE_SIZE);
+	ret = drm_mode_size_dumb(dev, args, SZ_256, 0);
+	if (ret)
+		return ret;
 
 	/* Use VRAM if there is any ; otherwise fallback to system memory */
 	if (nouveau_drm(dev)->client.device.info.ram_size != 0)
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 09:12:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 09:12:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014056.1392324 (Exim 4.92)
	(envelope-from )
	id 1uQ0SS-0005Qe-5F; Fri, 13 Jun 2025 09:12:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014056.1392324; Fri, 13 Jun 2025 09:12: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 1uQ0SS-0005QX-2P; Fri, 13 Jun 2025 09:12:20 +0000
Received: by outflank-mailman (input) for mailman id 1014056;
 Fri, 13 Jun 2025 09:12: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 1uQ0Lj-0002BZ-JP
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 09:05:23 +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 899ebb78-4835-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 11:05:22 +0200 (CEST)
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 1A3EF1F863;
 Fri, 13 Jun 2025 09:04: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 75AB113A9C;
 Fri, 13 Jun 2025 09:04:48 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id iJBYG7DpS2inNAAAD6G6ig
 (envelope-from ); Fri, 13 Jun 2025 09:04: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: 899ebb78-4835-11f0-a309-13f23c93f187
Authentication-Results: smtp-out2.suse.de;
	none
From: Thomas Zimmermann 
To: simona@ffwll.ch,
	airlied@gmail.com,
	mripard@kernel.org,
	maarten.lankhorst@linux.intel.com,
	geert@linux-m68k.org,
	tomi.valkeinen@ideasonboard.com
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann ,
	Heiko Stuebner ,
	Sandy Huang ,
	Andy Yan 
Subject: [PATCH v5 19/25] drm/rockchip: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Fri, 13 Jun 2025 11:00:38 +0200
Message-ID: <20250613090431.127087-20-tzimmermann@suse.de>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250613090431.127087-1-tzimmermann@suse.de>
References: <20250613090431.127087-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Spamd-Result: default: False [-4.00 / 50.00];
	REPLY(-4.00)[]
X-Rspamd-Queue-Id: 1A3EF1F863
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Action: no action
X-Spam-Level: 
X-Spam-Flag: NO
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Score: -4.00

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 64.

Signed-off-by: Thomas Zimmermann 
Acked-by: Heiko Stuebner 
Cc: Sandy Huang 
Cc: "Heiko Stübner" 
Cc: Andy Yan 
---
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index 6330b883efc3..3bd06202e232 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -9,6 +9,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -403,13 +404,12 @@ int rockchip_gem_dumb_create(struct drm_file *file_priv,
 			     struct drm_mode_create_dumb *args)
 {
 	struct rockchip_gem_object *rk_obj;
-	int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
+	int ret;
 
-	/*
-	 * align to 64 bytes since Mali requires it.
-	 */
-	args->pitch = ALIGN(min_pitch, 64);
-	args->size = args->pitch * args->height;
+	/* 64-byte alignment required by Mali */
+	ret = drm_mode_size_dumb(dev, args, SZ_64, 0);
+	if (ret)
+		return ret;
 
 	rk_obj = rockchip_gem_create_with_handle(file_priv, dev, args->size,
 						 &args->handle);
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 09:12:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 09:12:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014061.1392335 (Exim 4.92)
	(envelope-from )
	id 1uQ0SY-0005pa-DR; Fri, 13 Jun 2025 09:12:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014061.1392335; Fri, 13 Jun 2025 09:12:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uQ0SY-0005pT-A2; Fri, 13 Jun 2025 09:12:26 +0000
Received: by outflank-mailman (input) for mailman id 1014061;
 Fri, 13 Jun 2025 09:12: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 1uQ0Lq-0002BZ-Na
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 09:05:30 +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 8e0dfdc9-4835-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 11:05:30 +0200 (CEST)
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 A2CC11F898;
 Fri, 13 Jun 2025 09:04: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 6BF4A13A9C;
 Fri, 13 Jun 2025 09:04: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 CCLvGLPpS2inNAAAD6G6ig
 (envelope-from ); Fri, 13 Jun 2025 09:04: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: 8e0dfdc9-4835-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749805492; 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=co8oy2hD8rdxc+Ecu2XQ9CKCy4aLh0YIl4/k0TTFtWw=;
	b=njzl47lVWESzyaOgeHkQC23FWdD1IR9lcOYrIsKjJTDRxDQxyoV+eu21nY+uNw+i2Y4/m9
	jm1gtH5Z+2MHJuMSyqpAVVRGboPVn+nXsZX9MGVLykd1oYlcJKR0LtDddiZ483tYLgyBnm
	Aja3vjvOrPyJjLWt0yed1+ozDGgd8oY=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749805492;
	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=co8oy2hD8rdxc+Ecu2XQ9CKCy4aLh0YIl4/k0TTFtWw=;
	b=rO/Zx6Q3P5TDRPkWkZDmPciuekz8KUlXEQbwCbcgdOlg4j9Xl6NHKjy3sIswlAitA4o2GL
	Bn35tXJxOlWoIcAg==
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749805492; 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=co8oy2hD8rdxc+Ecu2XQ9CKCy4aLh0YIl4/k0TTFtWw=;
	b=njzl47lVWESzyaOgeHkQC23FWdD1IR9lcOYrIsKjJTDRxDQxyoV+eu21nY+uNw+i2Y4/m9
	jm1gtH5Z+2MHJuMSyqpAVVRGboPVn+nXsZX9MGVLykd1oYlcJKR0LtDddiZ483tYLgyBnm
	Aja3vjvOrPyJjLWt0yed1+ozDGgd8oY=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749805492;
	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=co8oy2hD8rdxc+Ecu2XQ9CKCy4aLh0YIl4/k0TTFtWw=;
	b=rO/Zx6Q3P5TDRPkWkZDmPciuekz8KUlXEQbwCbcgdOlg4j9Xl6NHKjy3sIswlAitA4o2GL
	Bn35tXJxOlWoIcAg==
From: Thomas Zimmermann 
To: simona@ffwll.ch,
	airlied@gmail.com,
	mripard@kernel.org,
	maarten.lankhorst@linux.intel.com,
	geert@linux-m68k.org,
	tomi.valkeinen@ideasonboard.com
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann ,
	Matthew Auld ,
	Lucas De Marchi ,
	=?UTF-8?q?Thomas=20Hellstr=C3=B6m?= ,
	Rodrigo Vivi 
Subject: [PATCH v5 23/25] drm/xe: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Fri, 13 Jun 2025 11:00:42 +0200
Message-ID: <20250613090431.127087-24-tzimmermann@suse.de>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250613090431.127087-1-tzimmermann@suse.de>
References: <20250613090431.127087-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-5.80 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_TO(0.00)[ffwll.ch,gmail.com,kernel.org,linux.intel.com,linux-m68k.org,ideasonboard.com];
	MIME_TRACE(0.00)[0:+];
	TO_DN_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[25];
	FREEMAIL_ENVRCPT(0.00)[gmail.com];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	RCVD_TLS_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	R_RATELIMIT(0.00)[to_ip_from(RLqirfcw6gnbcr9a9yhi49fhi6)];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	URIBL_BLOCKED(0.00)[suse.de:email,suse.de:mid,imap1.dmz-prg2.suse.org:helo];
	RCVD_COUNT_TWO(0.00)[2];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:email,suse.de:mid,intel.com:email]
X-Spam-Level: 
X-Spam-Flag: NO
X-Spam-Score: -5.80

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch
and buffer size. Align the pitch to a multiple of 8. Align the
buffer size according to hardware requirements.

Xe's internal calculation allowed for 64-bit wide buffer sizes, but
the ioctl's internal checks always verified against 32-bit wide limits.
Hance, it is safe to limit the driver code to 32-bit calculations as
well.

v3:
- mention 32-bit calculation in commit description (Matthew)

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Matthew Auld 
Cc: Lucas De Marchi 
Cc: "Thomas Hellström" 
Cc: Rodrigo Vivi 
---
 drivers/gpu/drm/xe/xe_bo.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
index 4e39188a021a..992aa9a1416b 100644
--- a/drivers/gpu/drm/xe/xe_bo.c
+++ b/drivers/gpu/drm/xe/xe_bo.c
@@ -9,6 +9,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -3098,14 +3099,13 @@ int xe_bo_dumb_create(struct drm_file *file_priv,
 	struct xe_device *xe = to_xe_device(dev);
 	struct xe_bo *bo;
 	uint32_t handle;
-	int cpp = DIV_ROUND_UP(args->bpp, 8);
 	int err;
 	u32 page_size = max_t(u32, PAGE_SIZE,
 		xe->info.vram_flags & XE_VRAM_FLAGS_NEED64K ? SZ_64K : SZ_4K);
 
-	args->pitch = ALIGN(args->width * cpp, 64);
-	args->size = ALIGN(mul_u32_u32(args->pitch, args->height),
-			   page_size);
+	err = drm_mode_size_dumb(dev, args, SZ_64, page_size);
+	if (err)
+		return err;
 
 	bo = xe_bo_create_user(xe, NULL, NULL, args->size,
 			       DRM_XE_GEM_CPU_CACHING_WC,
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 09:12:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 09:12:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014062.1392341 (Exim 4.92)
	(envelope-from )
	id 1uQ0SY-0005rI-Nl; Fri, 13 Jun 2025 09:12:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014062.1392341; Fri, 13 Jun 2025 09:12:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uQ0SY-0005qk-HA; Fri, 13 Jun 2025 09:12:26 +0000
Received: by outflank-mailman (input) for mailman id 1014062;
 Fri, 13 Jun 2025 09:12: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 1uQ0LV-0002BZ-GF
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 09:05:09 +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 7f856ebe-4835-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 11:05:06 +0200 (CEST)
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 5C1052127D;
 Fri, 13 Jun 2025 09:04:53 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id C296D137FE;
 Fri, 13 Jun 2025 09:04: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 IPrzLbTpS2inNAAAD6G6ig
 (envelope-from ); Fri, 13 Jun 2025 09:04: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: 7f856ebe-4835-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749805493; 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=/ahN4nYsnf/kPKgEdP2cQ//Kx80QNxPB7gu65ySdQUQ=;
	b=ps9udpyFFoLbMwsYWIJZuUjxv64eJNl1Zy63nh4SUCA09jdV9HIlXERA1gt4U5In5N/BW/
	qr5Y9K+r2dSEVj0QnoF5uNzmPAtauUVa1QfurYJJrmoEO02r08BABDiYGBeU1b2QK8hSXt
	Id8i7Su8hbQKHlrafU/lSiaRdJako5w=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749805493;
	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=/ahN4nYsnf/kPKgEdP2cQ//Kx80QNxPB7gu65ySdQUQ=;
	b=/xamGhAwuj+dAto3nT9Fp9Xp+pTG09eyNId6oG+ROK1rZK5nw4VZFyuIOMA3Nb0S4lcte7
	1O8OSEs+rPskoMDg==
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749805493; 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=/ahN4nYsnf/kPKgEdP2cQ//Kx80QNxPB7gu65ySdQUQ=;
	b=ps9udpyFFoLbMwsYWIJZuUjxv64eJNl1Zy63nh4SUCA09jdV9HIlXERA1gt4U5In5N/BW/
	qr5Y9K+r2dSEVj0QnoF5uNzmPAtauUVa1QfurYJJrmoEO02r08BABDiYGBeU1b2QK8hSXt
	Id8i7Su8hbQKHlrafU/lSiaRdJako5w=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749805493;
	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=/ahN4nYsnf/kPKgEdP2cQ//Kx80QNxPB7gu65ySdQUQ=;
	b=/xamGhAwuj+dAto3nT9Fp9Xp+pTG09eyNId6oG+ROK1rZK5nw4VZFyuIOMA3Nb0S4lcte7
	1O8OSEs+rPskoMDg==
From: Thomas Zimmermann 
To: simona@ffwll.ch,
	airlied@gmail.com,
	mripard@kernel.org,
	maarten.lankhorst@linux.intel.com,
	geert@linux-m68k.org,
	tomi.valkeinen@ideasonboard.com
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann ,
	Oleksandr Andrushchenko 
Subject: [PATCH v5 24/25] drm/xen: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Fri, 13 Jun 2025 11:00:43 +0200
Message-ID: <20250613090431.127087-25-tzimmermann@suse.de>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250613090431.127087-1-tzimmermann@suse.de>
References: <20250613090431.127087-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Flag: NO
X-Spam-Score: -5.30
X-Spamd-Result: default: False [-5.30 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-0.999];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_TO(0.00)[ffwll.ch,gmail.com,kernel.org,linux.intel.com,linux-m68k.org,ideasonboard.com];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[22];
	ARC_NA(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[epam.com:email,suse.de:mid,suse.de:email];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Spam-Level: 

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch
and buffer size. Align the pitch to a multiple of 8.

Signed-off-by: Thomas Zimmermann 
Cc: Oleksandr Andrushchenko 
---
 drivers/gpu/drm/xen/xen_drm_front.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/xen/xen_drm_front.c b/drivers/gpu/drm/xen/xen_drm_front.c
index 1bda7ef606cc..fd2f250fbc33 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -14,6 +14,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -414,8 +415,10 @@ static int xen_drm_drv_dumb_create(struct drm_file *filp,
 	 * object without pages etc.
 	 * For details also see drm_gem_handle_create
 	 */
-	args->pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
-	args->size = args->pitch * args->height;
+
+	ret = drm_mode_size_dumb(dev, args, SZ_8, 0);
+	if (ret)
+		return ret;
 
 	obj = xen_drm_front_gem_create(dev, args->size);
 	if (IS_ERR(obj)) {
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 09:12:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 09:12:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014063.1392356 (Exim 4.92)
	(envelope-from )
	id 1uQ0Sa-0006H1-07; Fri, 13 Jun 2025 09:12:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014063.1392356; Fri, 13 Jun 2025 09: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 1uQ0SZ-0006Fi-P7; Fri, 13 Jun 2025 09:12:27 +0000
Received: by outflank-mailman (input) for mailman id 1014063;
 Fri, 13 Jun 2025 09: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 1uQ0Lo-0002e2-3V
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 09:05:28 +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 8524f64d-4835-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 11:05:15 +0200 (CEST)
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 BED271F8A4;
 Fri, 13 Jun 2025 09:04:50 +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 23BA713A9C;
 Fri, 13 Jun 2025 09:04:50 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id 6KJ3B7LpS2inNAAAD6G6ig
 (envelope-from ); Fri, 13 Jun 2025 09:04: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: 8524f64d-4835-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749805490; 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=WqVzMC64hvC+7n4s+zagscNMG8z49p/xDo5yj6299ic=;
	b=QE7fkLNJpZZ5Y/enRElmqFiN996t6m9WB8szSbq+sahlNNtoLWRISRt+d7wK99MsDkgQ9k
	YK7+JZM1PPGB2uf3anr8fKHW7PzyOUZ+ZNA2O7t7F+3FfCtBfuy6lMtYABw69JQqMS9hWn
	XKypS5eVxU0H3mD62sGg2mxMNxmXYP0=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749805490;
	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=WqVzMC64hvC+7n4s+zagscNMG8z49p/xDo5yj6299ic=;
	b=GPaOUVZAJNwfFGBBl2PSl5SXv3KO3/KOBxkB+LpOn1Q/Le3tMxaHpE9QGXglu9CpTeGDFp
	JFEIMvyGQsZlI4DQ==
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749805490; 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=WqVzMC64hvC+7n4s+zagscNMG8z49p/xDo5yj6299ic=;
	b=QE7fkLNJpZZ5Y/enRElmqFiN996t6m9WB8szSbq+sahlNNtoLWRISRt+d7wK99MsDkgQ9k
	YK7+JZM1PPGB2uf3anr8fKHW7PzyOUZ+ZNA2O7t7F+3FfCtBfuy6lMtYABw69JQqMS9hWn
	XKypS5eVxU0H3mD62sGg2mxMNxmXYP0=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749805490;
	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=WqVzMC64hvC+7n4s+zagscNMG8z49p/xDo5yj6299ic=;
	b=GPaOUVZAJNwfFGBBl2PSl5SXv3KO3/KOBxkB+LpOn1Q/Le3tMxaHpE9QGXglu9CpTeGDFp
	JFEIMvyGQsZlI4DQ==
From: Thomas Zimmermann 
To: simona@ffwll.ch,
	airlied@gmail.com,
	mripard@kernel.org,
	maarten.lankhorst@linux.intel.com,
	geert@linux-m68k.org,
	tomi.valkeinen@ideasonboard.com
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann ,
	David Airlie ,
	Gerd Hoffmann ,
	Gurchetan Singh ,
	Chia-I Wu 
Subject: [PATCH v5 21/25] drm/virtio: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Fri, 13 Jun 2025 11:00:40 +0200
Message-ID: <20250613090431.127087-22-tzimmermann@suse.de>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250613090431.127087-1-tzimmermann@suse.de>
References: <20250613090431.127087-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-5.30 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	TO_DN_SOME(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_TO(0.00)[ffwll.ch,gmail.com,kernel.org,linux.intel.com,linux-m68k.org,ideasonboard.com];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	RCPT_COUNT_TWELVE(0.00)[25];
	ARC_NA(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:email,suse.de:mid];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_CC(0.00)[lists.freedesktop.org,lists.infradead.org,vger.kernel.org,lists.linux.dev,lists.xenproject.org,suse.de,redhat.com,chromium.org,gmail.com];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	RCVD_TLS_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	URIBL_BLOCKED(0.00)[imap1.dmz-prg2.suse.org:helo,suse.de:email,suse.de:mid];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Spam-Level: 
X-Spam-Flag: NO
X-Spam-Score: -5.30

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 4.

Signed-off-by: Thomas Zimmermann 
Cc: David Airlie 
Cc: Gerd Hoffmann 
Cc: Gurchetan Singh 
Cc: Chia-I Wu 
---
 drivers/gpu/drm/virtio/virtgpu_gem.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c b/drivers/gpu/drm/virtio/virtgpu_gem.c
index 90c99d83c4cf..7e515d6e781d 100644
--- a/drivers/gpu/drm/virtio/virtgpu_gem.c
+++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
@@ -23,6 +23,7 @@
  * WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
  */
 
+#include 
 #include 
 #include 
 
@@ -66,15 +67,14 @@ int virtio_gpu_mode_dumb_create(struct drm_file *file_priv,
 	struct virtio_gpu_object_params params = { 0 };
 	struct virtio_gpu_device *vgdev = dev->dev_private;
 	int ret;
-	uint32_t pitch;
+
+	ret = drm_mode_size_dumb(dev, args, SZ_4, 0);
+	if (ret)
+		return ret;
 
 	if (args->bpp != 32)
 		return -EINVAL;
 
-	pitch = args->width * 4;
-	args->size = pitch * args->height;
-	args->size = ALIGN(args->size, PAGE_SIZE);
-
 	params.format = virtio_gpu_translate_format(DRM_FORMAT_HOST_XRGB8888);
 	params.width = args->width;
 	params.height = args->height;
@@ -92,7 +92,6 @@ int virtio_gpu_mode_dumb_create(struct drm_file *file_priv,
 	if (ret)
 		goto fail;
 
-	args->pitch = pitch;
 	return ret;
 
 fail:
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 09:12:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 09:12:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014068.1392365 (Exim 4.92)
	(envelope-from )
	id 1uQ0Sh-0006qt-BN; Fri, 13 Jun 2025 09:12:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014068.1392365; Fri, 13 Jun 2025 09: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 1uQ0Sh-0006qm-7J; Fri, 13 Jun 2025 09:12:35 +0000
Received: by outflank-mailman (input) for mailman id 1014068;
 Fri, 13 Jun 2025 09:12: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 1uQ0Li-0002BZ-JN
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 09:05:22 +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 87748fb7-4835-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 11:05:19 +0200 (CEST)
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 A047C1F7ED;
 Fri, 13 Jun 2025 09:04: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 D715013A9C;
 Fri, 13 Jun 2025 09:04: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 aCYgM67pS2inNAAAD6G6ig
 (envelope-from ); Fri, 13 Jun 2025 09:04: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: 87748fb7-4835-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749805487; 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=hIqETTpCmmlNWY5V/Ih7xdzJjc+JnyaYMauo0rIgzcw=;
	b=MHZOYCM466cWZ7EGF8pd2wXKDgnewmFFy7Zzp4XN0zlkB4Xve7sqfr6M4CTtDgzuUKDf5m
	OAytF0jcmmTHy/YxMI7NQ/OHg+m7DC3HZQ133//zkIR9a6T2+sdr3zM2RKspiuBCE9mgR1
	1NZrZ9WBB/8V9vs17AUyR3MMhuFlzto=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749805487;
	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=hIqETTpCmmlNWY5V/Ih7xdzJjc+JnyaYMauo0rIgzcw=;
	b=ix0umhdxW7M8CDNMzcLPrhyAnF8TAkgQl7rnDo4Me1ne8BtKrwe2UY0KVhSuPGWWMnJ0HA
	TS5r78TcDU7YI9Dw==
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749805487; 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=hIqETTpCmmlNWY5V/Ih7xdzJjc+JnyaYMauo0rIgzcw=;
	b=MHZOYCM466cWZ7EGF8pd2wXKDgnewmFFy7Zzp4XN0zlkB4Xve7sqfr6M4CTtDgzuUKDf5m
	OAytF0jcmmTHy/YxMI7NQ/OHg+m7DC3HZQ133//zkIR9a6T2+sdr3zM2RKspiuBCE9mgR1
	1NZrZ9WBB/8V9vs17AUyR3MMhuFlzto=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749805487;
	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=hIqETTpCmmlNWY5V/Ih7xdzJjc+JnyaYMauo0rIgzcw=;
	b=ix0umhdxW7M8CDNMzcLPrhyAnF8TAkgQl7rnDo4Me1ne8BtKrwe2UY0KVhSuPGWWMnJ0HA
	TS5r78TcDU7YI9Dw==
From: Thomas Zimmermann 
To: simona@ffwll.ch,
	airlied@gmail.com,
	mripard@kernel.org,
	maarten.lankhorst@linux.intel.com,
	geert@linux-m68k.org,
	tomi.valkeinen@ideasonboard.com
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann ,
	Laurent Pinchart ,
	Kieran Bingham 
Subject: [PATCH v5 17/25] drm/renesas/rcar-du: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Fri, 13 Jun 2025 11:00:36 +0200
Message-ID: <20250613090431.127087-18-tzimmermann@suse.de>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250613090431.127087-1-tzimmermann@suse.de>
References: <20250613090431.127087-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Flag: NO
X-Spam-Score: -5.30
X-Spamd-Result: default: False [-5.30 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-0.999];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TAGGED_RCPT(0.00)[renesas];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[23];
	MIME_TRACE(0.00)[0:+];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:mid,suse.de:email,ideasonboard.com:email];
	RCVD_COUNT_TWO(0.00)[2];
	FREEMAIL_TO(0.00)[ffwll.ch,gmail.com,kernel.org,linux.intel.com,linux-m68k.org,ideasonboard.com];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	R_RATELIMIT(0.00)[to_ip_from(RLqirfcw6gnbcr9a9yhi49fhi6)];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Spam-Level: 

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch according to hardware requirements.

Signed-off-by: Thomas Zimmermann 
Cc: Laurent Pinchart 
Cc: Kieran Bingham 
---
 drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
index 4c8fe83dd610..dd353fb858ef 100644
--- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -407,8 +408,8 @@ int rcar_du_dumb_create(struct drm_file *file, struct drm_device *dev,
 			struct drm_mode_create_dumb *args)
 {
 	struct rcar_du_device *rcdu = to_rcar_du_device(dev);
-	unsigned int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
 	unsigned int align;
+	int ret;
 
 	/*
 	 * The R8A7779 DU requires a 16 pixels pitch alignment as documented,
@@ -419,7 +420,9 @@ int rcar_du_dumb_create(struct drm_file *file, struct drm_device *dev,
 	else
 		align = 16 * args->bpp / 8;
 
-	args->pitch = roundup(min_pitch, align);
+	ret = drm_mode_size_dumb(dev, args, align, 0);
+	if (ret)
+		return ret;
 
 	return drm_gem_dma_dumb_create_internal(file, dev, args);
 }
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 09:12:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 09:12:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014075.1392375 (Exim 4.92)
	(envelope-from )
	id 1uQ0Ss-0007l1-Jr; Fri, 13 Jun 2025 09:12:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014075.1392375; Fri, 13 Jun 2025 09:12: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 1uQ0Ss-0007km-Gj; Fri, 13 Jun 2025 09:12:46 +0000
Received: by outflank-mailman (input) for mailman id 1014075;
 Fri, 13 Jun 2025 09:12: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 1uQ0LW-0002e2-UH
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 09:05:10 +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 791833eb-4835-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 11:04:55 +0200 (CEST)
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 4D6B41F895;
 Fri, 13 Jun 2025 09:04: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 A519C137FE;
 Fri, 13 Jun 2025 09:04: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 wLPYJqvpS2inNAAAD6G6ig
 (envelope-from ); Fri, 13 Jun 2025 09:04:43 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 791833eb-4835-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749805484; 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=+oWjsDNgdReLHPGufgsHjLYvUDgBPaSeIOftSSBGais=;
	b=qjLrb0YO0OF5O9AFMpCwomhReVKLz63s4i9lKJrRQsNHCGxESOqzXhcg1CzLFVrRd12gje
	tzfM1Ell3cs1WWVCxcPzz6h/A/YnhZwlJQ50LFcz2g+ueN8SMlpNkOH4DtU7JqhBWud+tx
	0zaJceZSxCYW3niXkor7BJrUlToMCLY=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749805484;
	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=+oWjsDNgdReLHPGufgsHjLYvUDgBPaSeIOftSSBGais=;
	b=08AGzz8DatzqiXtEB4eGagQF9jhX4EZNT7LnLDw79E/lVF4qUOO2AeqK2PmHT5oiUz8Spu
	ozACi3IetRMlmKDg==
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1749805484; 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=+oWjsDNgdReLHPGufgsHjLYvUDgBPaSeIOftSSBGais=;
	b=qjLrb0YO0OF5O9AFMpCwomhReVKLz63s4i9lKJrRQsNHCGxESOqzXhcg1CzLFVrRd12gje
	tzfM1Ell3cs1WWVCxcPzz6h/A/YnhZwlJQ50LFcz2g+ueN8SMlpNkOH4DtU7JqhBWud+tx
	0zaJceZSxCYW3niXkor7BJrUlToMCLY=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1749805484;
	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=+oWjsDNgdReLHPGufgsHjLYvUDgBPaSeIOftSSBGais=;
	b=08AGzz8DatzqiXtEB4eGagQF9jhX4EZNT7LnLDw79E/lVF4qUOO2AeqK2PmHT5oiUz8Spu
	ozACi3IetRMlmKDg==
From: Thomas Zimmermann 
To: simona@ffwll.ch,
	airlied@gmail.com,
	mripard@kernel.org,
	maarten.lankhorst@linux.intel.com,
	geert@linux-m68k.org,
	tomi.valkeinen@ideasonboard.com
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org,
	xen-devel@lists.xenproject.org,
	Thomas Zimmermann ,
	Chun-Kuang Hu ,
	Philipp Zabel ,
	Matthias Brugger ,
	AngeloGioacchino Del Regno 
Subject: [PATCH v5 12/25] drm/mediatek: Compute dumb-buffer sizes with drm_mode_size_dumb()
Date: Fri, 13 Jun 2025 11:00:31 +0200
Message-ID: <20250613090431.127087-13-tzimmermann@suse.de>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250613090431.127087-1-tzimmermann@suse.de>
References: <20250613090431.127087-1-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Flag: NO
X-Spam-Score: -5.30
X-Spamd-Result: default: False [-5.30 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TAGGED_RCPT(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[25];
	MIME_TRACE(0.00)[0:+];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FREEMAIL_CC(0.00)[lists.freedesktop.org,lists.infradead.org,vger.kernel.org,lists.linux.dev,lists.xenproject.org,suse.de,kernel.org,pengutronix.de,gmail.com,collabora.com];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:mid,suse.de:email,collabora.com:email];
	FROM_HAS_DN(0.00)[];
	FREEMAIL_TO(0.00)[ffwll.ch,gmail.com,kernel.org,linux.intel.com,linux-m68k.org,ideasonboard.com];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	FROM_EQ_ENVFROM(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Spam-Level: 

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 8.

Signed-off-by: Thomas Zimmermann 
Cc: Chun-Kuang Hu 
Cc: Philipp Zabel 
Cc: Matthias Brugger 
Cc: AngeloGioacchino Del Regno 
---
 drivers/gpu/drm/mediatek/mtk_gem.c | 13 ++++---------
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_gem.c b/drivers/gpu/drm/mediatek/mtk_gem.c
index a172456d1d7b..21e08fabfd7f 100644
--- a/drivers/gpu/drm/mediatek/mtk_gem.c
+++ b/drivers/gpu/drm/mediatek/mtk_gem.c
@@ -8,6 +8,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -124,15 +125,9 @@ int mtk_gem_dumb_create(struct drm_file *file_priv, struct drm_device *dev,
 	struct mtk_gem_obj *mtk_gem;
 	int ret;
 
-	args->pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
-
-	/*
-	 * Multiply 2 variables of different types,
-	 * for example: args->size = args->spacing * args->height;
-	 * may cause coverity issue with unintentional overflow.
-	 */
-	args->size = args->pitch;
-	args->size *= args->height;
+	ret = drm_mode_size_dumb(dev, args, SZ_8, 0);
+	if (ret)
+		return ret;
 
 	mtk_gem = mtk_gem_create(dev, args->size, false);
 	if (IS_ERR(mtk_gem))
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 09:31:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 09:31:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014137.1392384 (Exim 4.92)
	(envelope-from )
	id 1uQ0kp-0004il-1W; Fri, 13 Jun 2025 09:31:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014137.1392384; Fri, 13 Jun 2025 09:31: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 1uQ0ko-0004ie-VD; Fri, 13 Jun 2025 09:31:18 +0000
Received: by outflank-mailman (input) for mailman id 1014137;
 Fri, 13 Jun 2025 09:31: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 1uQ0kn-0004iY-Ne
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 09:31:18 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20610.outbound.protection.outlook.com
 [2a01:111:f403:2412::610])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1f05a4ea-4839-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 11:31:03 +0200 (CEST)
Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
 by SA5PPFF1E6547B5.namprd12.prod.outlook.com
 (2603:10b6:80f:fc04::8ea) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.33; Fri, 13 Jun
 2025 09:30: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%2]) with mapi id 15.20.8835.018; Fri, 13 Jun 2025
 09:30: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: 1f05a4ea-4839-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=kpIJYvyZPtrzjXMm2NN3dexg3uOK/2IvLWlecnbB43JCxRUSOtJCnLO9IBLr8y+doXNnJ8egKpl8R0kbbVNHhnCOYBSfjv5NwtHvgFRfqdKJdorv1hIl9npEGwxG95MDXuti0VDeMTvjUabO+Xgg1FEB2olAniQ1jxOW0gpyiE0MiBsAbFZEMvrqTG8lylr88I/JwAgGijkUvcfXXBac0bbAGUn35fhvneDGdiDGk7jvltmmqugRN81l36L67ymOzsXPDdqcvNaYEWCf9EaTdCJirR/sD+KO9yatL5K+xEUWMfXUNiHTBtfyIrXWWTqIQ0Lu8xiPv6T0pjaEDsQWTQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=oZtqAEVsvgRRaAz4hZWMTFnxpJL5xeOQ3MWQ1jIMCF4=;
 b=OFXnu8olBV9QJ8KZlRWql/boHQY1npQ9IpOyUvkOrVFe+3SyYEGwXeFptl/zVmNNI8OU0xCNw7fE+UcO0r3Xnn9T3rCn6OxgyUHU/gCsCZuerVBrRX9uRQvt2dd1bdFj3ggCIn5NNC08irty/KQsLXcLsPTyS2Ssk8OvfazWmEDOeUtGbyA8IuiedHJnMGFY/A3CW754UNht2HRMgmvOnPqUZUXaBMB+TyhnVJnGPu72ncDKjingZwx1+bsL3LY6Fcr46keCFz/cxGqKbvb7UNwBTuXHlVGdWxetlrsWlrj2xFNJ5d5BNHIoPZPzGjbtXXrDfwLdwIOyAx6vb9HeDQ==
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=oZtqAEVsvgRRaAz4hZWMTFnxpJL5xeOQ3MWQ1jIMCF4=;
 b=0UaVUKaQ71tO3TrEuKYAZlofeidTgd0rMIbk3P2USoOTtkK50ekrwj+TpwCBuo/527y5vqcmcmqtb5NBoy9hswzhplU4ToL5TkNm0IuUixb63+UzEHp7mtgJ6kJZHUCVLBErFU6gIF9kCKuFPVTHFd/eTF0jxSrXO6CADp07Bcg=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <41eef9a1-1f43-4f2f-b79a-89c0d0ec941b@amd.com>
Date: Fri, 13 Jun 2025 10:30:54 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 6/6] arm/mpu: Enable read/write to protection regions
 for arm32
To: Ayan Kumar Halder ,
 xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: <20250611143544.3453532-1-ayan.kumar.halder@amd.com>
 <20250611143544.3453532-7-ayan.kumar.halder@amd.com>
Content-Language: en-GB
From: Ayan Kumar Halder 
In-Reply-To: <20250611143544.3453532-7-ayan.kumar.halder@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: MA2P292CA0020.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250::10)
 To PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|SA5PPFF1E6547B5:EE_
X-MS-Office365-Filtering-Correlation-Id: b91384bd-bc7f-4fac-6d39-08ddaa5d013d
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?Y0FzZkYyUjZldUpVVno5bU9tWmZJcmtYTEFhaDZBaHFZMVY2NWYxYUxKWGRP?=
 =?utf-8?B?Q2xTNTEvQ1ZqZjhQazRNcUtKNXB3dFFFSTF5YmVScmVGOFdaemtJb2g3bG51?=
 =?utf-8?B?cVpCVmVBalYwQjZ4R0pDMU9iY2oyaU94UFg2L2czTGxIcTJGeGNLK1l6azl6?=
 =?utf-8?B?MlM3NGhKazV5K21pTFRHQnVtejcwaFRhU3RTM3RSL004V3JtNHJ2c2FuVHM4?=
 =?utf-8?B?bmFuRElYeGgzVThvSzVIR1lSdzFqM0tQeUN2S1JVQVo4QnBYbzV0cVgvUXNB?=
 =?utf-8?B?TUlFelhoemcrZnh4b0xDcHFWNllRWWVCZnQrcGhTVjlqNjJ0SEFqcW5kVlgw?=
 =?utf-8?B?cTE3ZlJFbUJKWlpkaFFZcDcxU1h2bkZGdzJhSzZmYnFSa0VSN0JFZm9IWlZJ?=
 =?utf-8?B?cThTMkhjV1NxK2ZoZXQxaXlBRU1KMjd0dzJaQVpUa1o2L1FEWDZkQkh2Wi9z?=
 =?utf-8?B?QTJmbFJzSWVCV3Rab1BjdWZQVG5yVEJrMk56UXNSMERkeGxWUVBHZkFaQnE0?=
 =?utf-8?B?WjJpS0U5SS9xSUFtZkhWN3dSbjhJUlpFMEtiR3M2UlVCU3M4MzhFaFpMVkRG?=
 =?utf-8?B?NFFzSUxDb0tPUllZNlkxRjlWWjU5VUNnbTIxQkR0RTJtRHF6TC9SbjdiRnJI?=
 =?utf-8?B?K2xCWC9nQ1hYRXNrQnZOZTc2c1R5dU5KR0lPUWE3MnZ2UmVKbmlKbDZKNGxF?=
 =?utf-8?B?UitGZHB5SERIODF1bWRGZjEwSWJCUm8weE5WcUY4RlVkVXZSSmVIVXJ4bWYx?=
 =?utf-8?B?cUZjTHcwdG91Y0s0VGhCZ3dFNjVjem1ibTUrOWpGUC9wckRZcW1VV2J2UGZF?=
 =?utf-8?B?bk9yMm5aSGtKRnlvblRjWm4vMXlwcm11OUwzcks1U2Ftb0pQQXptKzBBOFFQ?=
 =?utf-8?B?N3BOVUJZS05ya0syNFZyaVFZTE0wN096NjhIejl5M09wb1ZWSVdpOG83MVBv?=
 =?utf-8?B?VWJTdDNsMEk5Zm1qdENrOUdQc3E1VVp5V1REQ3M1L1p2eFdIWUpRN2hmaGt4?=
 =?utf-8?B?eHNiUXBVVWlGWmVFRzZOU0ZpVyt3V3d2bjR1Um9tZEs4UFdFWHdTbWpmblRO?=
 =?utf-8?B?T1UrcWh0TUZWYjhWTXRWU0xSU1BJcWpuVXNBb1pBUUhmSVprakV0OThyMXBN?=
 =?utf-8?B?bGxlN2o4eE54TXd0anp6WXZYb1o0OHFTd1hoRlVTbDBQMFJTL1FkSzNad05l?=
 =?utf-8?B?azNYWmozMGhQaSswY1Q2dFBIamlKTmYzTSttK0ZleHdJdVF6TGhlTDN5cmZJ?=
 =?utf-8?B?c0JPYzFoN1BBR29tenZYNnVPYXhiaDMwWE1VZ3F6T09nRFpHM0JrWHplWEtp?=
 =?utf-8?B?WmpGOXBoYWIxTERvYkNBVTJhd1dXc3Znb3JUbkpRQmdkbEtFNmVlbjMzdU9Q?=
 =?utf-8?B?aVVuSXdCczhXMmp6U1Z1MkUzem8rZVk4YWZhWmNocFlnOWpGNjZqanh1eWVN?=
 =?utf-8?B?WWg0Rzd6T2RZbnFOSjRJNHhXK2IrRno5STYrZGhvRVVIVjNvc0NQUW4xeGts?=
 =?utf-8?B?YStzNFJGaHFscXJUcG1PM2NWSWdOV2U1ajJmNDhKejNYK1NQazVmOVk0RS8r?=
 =?utf-8?B?MUtsRG1QSTlXYlEweXpibVdkWVBYci9kaTBxeVUvSUJUbDllNXJPTmgzK09x?=
 =?utf-8?B?WXB4VlpDOXZxU2tHSmtUOTVqZ25BZEF1KytkcGZ5M21Ia08rL2tTaVZUc0lD?=
 =?utf-8?B?OTQ4V1V0eDlXcUE1WlZEbkp0c0ZucjJVejBMWkU0eWpmc0FpK0lWTTY5MzhV?=
 =?utf-8?B?QWFxbHNGckVXVUM2cnZES2FKMzJXdXRMbVNXMG5HVmFLVFNBbUVqenBYVWQ0?=
 =?utf-8?B?YnhaK3lsWkZHUXVtdnB1SWRuY2VFamM2L2VNYWZHdkRTdjViZ2dVMTNQSnRO?=
 =?utf-8?B?dWljWGFoRGp5WnFIVGJvZkJGeUVRUW9STDErbU1wZzB1Sml2R3VNaWp1dk9H?=
 =?utf-8?Q?g0u7pbP9sMg=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?Z0VUU2p4OVRvelFocWJabXYxVG0rRXNkYkRvRjg4alI3K3hNbUZVNDVuaGZQ?=
 =?utf-8?B?aEZ4dnNxc3ZKczFSOHZUbXJxdXorMWdjZU9NVm5mRDZEbS9XdTVDaXJPS1hp?=
 =?utf-8?B?cW82Vm5VbFJMR2JoTUpnVDhtVnV1aHFQTHVZMUUxN0wzNnhmRWhxMVIvcnVU?=
 =?utf-8?B?Q2hNZXVDSE1zK01WcEltQThKOVRoRTFJQllidmF6Wm85WjlIREh0VEdUck42?=
 =?utf-8?B?cERxaXdVcnZydUJoVE4vQUxMUFZCbFNIM25UTkxpcmp3VDJoNldzS1dsYXE4?=
 =?utf-8?B?cFhmVUUrQ3ExZUdwTnY0REJ6aDJXOS9TaFlKZ1lreTU3UkE2OTMzb2gyRGlU?=
 =?utf-8?B?dDZWWWczMUtJY1hSZzF1a25xZWFSSE1NNjBydmpLZ3UvNlZJS1Z1THNnVHZp?=
 =?utf-8?B?eWlMV2lJZFp3U3R2VmpLYnlFZFRxdzcxMHhES3BQaHNtcnVqWFV4SDgvSUxU?=
 =?utf-8?B?MWxrb1pyMWVHUk1xZkRxc3hOaDVoQlpEMS9IN285UzhycWV6Vkg2d2xRb3NU?=
 =?utf-8?B?UGtvNW44Y2lxOStZVnNmWjQ0K2RXRHg4T0FnVG53VG1nejBmblowYlo4MFpY?=
 =?utf-8?B?Z3pmajdRMi82VlZXWkxwN05CZm5YZ0dUTmtvcFhvenErbWN3VTFTNXNmSFlE?=
 =?utf-8?B?clhyTnVIRzdNdXllRStYdlRkQ2puSURwSTdlcmJKNWNYTjMydzl3MnlxRUdW?=
 =?utf-8?B?M3E3U0hkTmczdE1rWWZMTFNFc2lEcG11M2t3eW94bmlTalRmalNqMXA2amdL?=
 =?utf-8?B?MkdVM1hSWVN2SHRLemZadFRtV0FmRGliR3ozT3N2MUtzaHpmRUMxVHZCYTE3?=
 =?utf-8?B?Mkc2U3Z3cnIxSUR2VXVPcDhnQU5GTnFnQ0I1bWpYTjFPSW1IRm4wN0xBdlQ3?=
 =?utf-8?B?NG1ZQm9nYm1XUUhuK0N0MlVYeDA5VktmTW1ybU1jMWc0MmF0KzNmT1MrTHR2?=
 =?utf-8?B?T2ZUTnF0RG56WjlUdDFQdDRXZ1ZmSGRyN1dHUm5IdmNIVGNPUHRQck56V1Jp?=
 =?utf-8?B?SXlQZ3Q0NGk5UVZyMmh1Qkk3VUNZaEp1Uk8zR1VrelY0WkVPS2RsbERqaWlF?=
 =?utf-8?B?ZzJtZVVhakVId2VBbTdRSEpiSGRRbG5pQnhRYzlyT3Y0R1piY1BLM2dTS2FD?=
 =?utf-8?B?SzhjcGMrS0VKVzMxZVJLVU83Z21GRzRhTVZTZHhqMlBTblM3T05DWEhpeUZO?=
 =?utf-8?B?VDNnZXVQc080WHJkQllTemx4a3U5NjV4VnFCQTMwZEFmcGVONktKa1FjMUhw?=
 =?utf-8?B?by9WVkxIME1wcFM0MnJGdlpHb1BJcytEcDRnU3lhL3FNdUJVWTBYc0JzcEFm?=
 =?utf-8?B?SUlhVnFqZHpqK2d0ZFdRUVpKTlBudTVORlNHMG1HTzZBRk5QNzdFUHJRNWs1?=
 =?utf-8?B?ZkxKbWJzN0RhWGNmRWNzTmJiYkcyU0JuVXUwR0lXTXJFemlnR0hKcVRFS2VZ?=
 =?utf-8?B?WkEvbzdXQTBlMlpkM1ppZ0JROTZKVXF0ZlRWbVNmTEFsU2gwYjdEUFQvQXRj?=
 =?utf-8?B?Y1RhZHJQcGlSdks2RE4zNE5PUlpKaUM3Q2p4bUp2SFB4UkhLbURqMkdPVWRx?=
 =?utf-8?B?ZVpLMTJCYm8xa2l3ckdjTDE5eEIzdnNrakNRdFZERjB6eVFLVC9CVys5RkFS?=
 =?utf-8?B?aCswZ2RnczNwVFArZHZGcytHaXY5UUNqa1ZvUGhxVUNHUWdzdTZvdDNhbjRG?=
 =?utf-8?B?TGFRbFk0K2FDanBKRW56UXhFMDl1VmpSa2dZelBRNDdLT3pINTk2YUE0Mm1W?=
 =?utf-8?B?eFlwajA2WE1nMHArWkZTelhtaTI3WEZiekNRNXZvNDgyeGZOOWJ6NHovajRZ?=
 =?utf-8?B?b2p2Ty9KNG44dHFlaHdTcERubWdKTFZZdm9LOUg0QnIrRks4emV6elZwdVcz?=
 =?utf-8?B?THViK0hYMW1vdVhIOFZlVkYxT2l4YXZKcno1TzE1UjY2MkRjWkxUcWlidTM5?=
 =?utf-8?B?TEJUdlZ3ZGF0dzFPWlhqVTQ3N0tqZGtMMmRrclluNDFWbHZOMTV6QTBhL1pK?=
 =?utf-8?B?dmVOamJBaENvb09Kbk9Gbm95aDZBR2pqRVFlRmNyWFVoV2RIdWJqY0w5Y1Rz?=
 =?utf-8?B?YWxTcXVYZGpZUmVMam5nS25pQ3VhbmxybjhxQ1FQUDJDWXZBUGpiWWh1SUFw?=
 =?utf-8?Q?0foGmmjTnuNH1TI7TvB1DeVSB?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b91384bd-bc7f-4fac-6d39-08ddaa5d013d
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jun 2025 09:30:58.9203
 (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: CHFW8xrbz54SED+8wDgrA+Pg5AtOe1f/uBFVsCwX8gjhS2xoplGKtaY7e5LZSxS1qMLRfG4pNhUsRRYScUgOkg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA5PPFF1E6547B5


On 11/06/2025 15:35, Ayan Kumar Halder wrote:
> Define prepare_selector(), read_protection_region() and
> write_protection_region() for arm32. Also, define
> GENERATE_{READ/WRITE}_PR_REG_OTHERS to access MPU regions from 32 to 255.
>
> Enable pr_{get/set}_{base/limit}(), region_is_valid() for arm32.
> Enable pr_of_addr() for arm32.
>
> Signed-off-by: Ayan Kumar Halder 
> ---
> Changes from :-
>
> v1 - 1. Enable write_protection_region() for aarch32.
>
> v2 - 1. Enable access to protection regions from 0 - 255.
>
>   xen/arch/arm/include/asm/mpu.h  |   2 -
>   xen/arch/arm/mpu/arm32/Makefile |   1 +
>   xen/arch/arm/mpu/arm32/mm.c     | 165 ++++++++++++++++++++++++++++++++
>   xen/arch/arm/mpu/mm.c           |   2 -
>   4 files changed, 166 insertions(+), 4 deletions(-)
>   create mode 100644 xen/arch/arm/mpu/arm32/mm.c
>
> diff --git a/xen/arch/arm/include/asm/mpu.h b/xen/arch/arm/include/asm/mpu.h
> index 8f06ddac0f..63560c613b 100644
> --- a/xen/arch/arm/include/asm/mpu.h
> +++ b/xen/arch/arm/include/asm/mpu.h
> @@ -25,7 +25,6 @@
>   
>   #ifndef __ASSEMBLY__
>   
> -#ifdef CONFIG_ARM_64
>   /*
>    * Set base address of MPU protection region.
>    *
> @@ -85,7 +84,6 @@ static inline bool region_is_valid(const pr_t *pr)
>   {
>       return pr->prlar.reg.en;
>   }
> -#endif /* CONFIG_ARM_64 */
>   
>   #endif /* __ASSEMBLY__ */
>   
> diff --git a/xen/arch/arm/mpu/arm32/Makefile b/xen/arch/arm/mpu/arm32/Makefile
> index e15ce2f7be..3da872322e 100644
> --- a/xen/arch/arm/mpu/arm32/Makefile
> +++ b/xen/arch/arm/mpu/arm32/Makefile
> @@ -1 +1,2 @@
>   obj-y += domain-page.o
> +obj-y += mm.o
> diff --git a/xen/arch/arm/mpu/arm32/mm.c b/xen/arch/arm/mpu/arm32/mm.c
> new file mode 100644
> index 0000000000..5d3cb6dff7
> --- /dev/null
> +++ b/xen/arch/arm/mpu/arm32/mm.c
> @@ -0,0 +1,165 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define PRBAR_EL2_(n)   HPRBAR##n
> +#define PRLAR_EL2_(n)   HPRLAR##n
> +
> +#define GENERATE_WRITE_PR_REG_CASE(num, pr)                                 \
> +    case num:                                                               \
> +    {                                                                       \
> +        WRITE_SYSREG(pr->prbar.bits & ~MPU_REGION_RES0, PRBAR_EL2_(num));   \
> +        WRITE_SYSREG(pr->prlar.bits & ~MPU_REGION_RES0, PRLAR_EL2_(num));   \
> +        break;                                                              \
> +    }
> +
> +#define GENERATE_WRITE_PR_REG_OTHERS(num, pr)                               \
> +    case num:                                                               \
> +    {                                                                       \
> +        WRITE_SYSREG(pr->prbar.bits & ~MPU_REGION_RES0, HPRBAR);            \
> +        WRITE_SYSREG(pr->prlar.bits & ~MPU_REGION_RES0, HPRLAR);            \
> +        break;                                                              \
> +    }
> +
> +#define GENERATE_READ_PR_REG_CASE(num, pr)                                  \
> +    case num:                                                               \
> +    {                                                                       \
> +        pr->prbar.bits = READ_SYSREG(PRBAR_EL2_(num));                      \
> +        pr->prlar.bits = READ_SYSREG(PRLAR_EL2_(num));                      \
> +        break;                                                              \
> +    }
> +
> +#define GENERATE_READ_PR_REG_OTHERS(num, pr)                                \
> +    case num:                                                               \
> +    {                                                                       \
> +        pr->prbar.bits = READ_SYSREG(HPRBAR);                               \
> +        pr->prlar.bits = READ_SYSREG(HPRLAR);                               \
> +        break;                                                              \
> +    }
> +
> +/*
> + * Armv8-R supports direct access and indirect access to the MPU regions through
> + * registers:
> + *  - indirect access involves changing the MPU region selector, issuing an isb
> + *    barrier and accessing the selected region through specific registers
> + *  - direct access involves accessing specific registers that point to
> + *    specific MPU regions, without changing the selector, avoiding the use of
> + *    a barrier.
> + * For Arm32 the PR{B,L}AR_ELx (for n=0..31) are used for direct access to the
> + * first 32 MPU regions.
> + * For MPU region numbered 32..255, one need to set the region number in PRSELR_ELx,
> + * followed by configuring PR{B,L}AR_ELx.
> + */
> +inline void prepare_selector(uint8_t *sel)
> +{
> +    uint8_t cur_sel = *sel;
> +
> +    if ( cur_sel > 0x1FU )
> +    {
> +        WRITE_SYSREG(cur_sel, PRSELR_EL2);
> +        isb();
> +    }
> +}
> +
> +void read_protection_region(pr_t *pr_read, uint8_t sel)
> +{
> +    prepare_selector(&sel);
> +
> +    switch ( sel )
> +    {
> +        GENERATE_READ_PR_REG_CASE(0, pr_read);
> +        GENERATE_READ_PR_REG_CASE(1, pr_read);
> +        GENERATE_READ_PR_REG_CASE(2, pr_read);
> +        GENERATE_READ_PR_REG_CASE(3, pr_read);
> +        GENERATE_READ_PR_REG_CASE(4, pr_read);
> +        GENERATE_READ_PR_REG_CASE(5, pr_read);
> +        GENERATE_READ_PR_REG_CASE(6, pr_read);
> +        GENERATE_READ_PR_REG_CASE(7, pr_read);
> +        GENERATE_READ_PR_REG_CASE(8, pr_read);
> +        GENERATE_READ_PR_REG_CASE(9, pr_read);
> +        GENERATE_READ_PR_REG_CASE(10, pr_read);
> +        GENERATE_READ_PR_REG_CASE(11, pr_read);
> +        GENERATE_READ_PR_REG_CASE(12, pr_read);
> +        GENERATE_READ_PR_REG_CASE(13, pr_read);
> +        GENERATE_READ_PR_REG_CASE(14, pr_read);
> +        GENERATE_READ_PR_REG_CASE(15, pr_read);
> +        GENERATE_READ_PR_REG_CASE(16, pr_read);
> +        GENERATE_READ_PR_REG_CASE(17, pr_read);
> +        GENERATE_READ_PR_REG_CASE(18, pr_read);
> +        GENERATE_READ_PR_REG_CASE(19, pr_read);
> +        GENERATE_READ_PR_REG_CASE(20, pr_read);
> +        GENERATE_READ_PR_REG_CASE(21, pr_read);
> +        GENERATE_READ_PR_REG_CASE(22, pr_read);
> +        GENERATE_READ_PR_REG_CASE(23, pr_read);
> +        GENERATE_READ_PR_REG_CASE(24, pr_read);
> +        GENERATE_READ_PR_REG_CASE(25, pr_read);
> +        GENERATE_READ_PR_REG_CASE(26, pr_read);
> +        GENERATE_READ_PR_REG_CASE(27, pr_read);
> +        GENERATE_READ_PR_REG_CASE(28, pr_read);
> +        GENERATE_READ_PR_REG_CASE(29, pr_read);
> +        GENERATE_READ_PR_REG_CASE(30, pr_read);
> +        GENERATE_READ_PR_REG_CASE(31, pr_read);
> +        GENERATE_READ_PR_REG_OTHERS(32 ... 255, pr_read);

This should be 32 ... 254 . Thanks Luca for pointing this out.

The max number of regions supported is 255 (not 256). It is the maximum 
value of HMPUIR.

- Ayan

> +    default:
> +        BUG(); /* Can't happen */
> +        break;
> +    }
> +}
> +
> +void write_protection_region(const pr_t *pr_write, uint8_t sel)
> +{
> +    prepare_selector(&sel);
> +
> +    switch ( sel )
> +    {
> +        GENERATE_WRITE_PR_REG_CASE(0, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(1, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(2, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(3, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(4, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(5, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(6, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(7, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(8, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(9, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(10, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(11, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(12, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(13, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(14, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(15, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(16, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(17, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(18, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(19, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(20, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(21, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(22, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(23, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(24, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(25, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(26, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(27, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(28, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(29, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(30, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(31, pr_write);
> +        GENERATE_WRITE_PR_REG_OTHERS(32 ... 255, pr_write);
> +    default:
> +        BUG(); /* Can't happen */
> +        break;
> +    }
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
> index 7ab68fc8c7..ccfb37a67b 100644
> --- a/xen/arch/arm/mpu/mm.c
> +++ b/xen/arch/arm/mpu/mm.c
> @@ -39,7 +39,6 @@ static void __init __maybe_unused build_assertions(void)
>       BUILD_BUG_ON(PAGE_SIZE != SZ_4K);
>   }
>   
> -#ifdef CONFIG_ARM_64
>   pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags)
>   {
>       unsigned int attr_idx = PAGE_AI_MASK(flags);
> @@ -110,7 +109,6 @@ pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags)
>   
>       return region;
>   }
> -#endif /* CONFIG_ARM_64 */
>   
>   void __init setup_mm(void)
>   {


From xen-devel-bounces@lists.xenproject.org Fri Jun 13 09:34:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 09:34:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014150.1392394 (Exim 4.92)
	(envelope-from )
	id 1uQ0nX-00067T-Hf; Fri, 13 Jun 2025 09:34:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014150.1392394; Fri, 13 Jun 2025 09:34: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 1uQ0nX-00067L-F3; Fri, 13 Jun 2025 09:34:07 +0000
Received: by outflank-mailman (input) for mailman id 1014150;
 Fri, 13 Jun 2025 09:34: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 1uQ0nV-000678-Ib
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 09:34:05 +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 8b845b4e-4839-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 11:34:04 +0200 (CEST)
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 BA9B72186F;
 Fri, 13 Jun 2025 09:34: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 8A9F0137FE;
 Fri, 13 Jun 2025 09:34: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 FMy4H4vwS2jDPAAAD6G6ig
 (envelope-from ); Fri, 13 Jun 2025 09:34: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: 8b845b4e-4839-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1749807243; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=HmL+SUXn84DQyTGwzvsf9NWUSwsHo91ICHEyzRG2yx8=;
	b=lpN24zC7WD/eK117SwoAYZ/cF4nU4+LEabvXcZ1LQUS4N2KgjxvNSp13d+HcdT0yuMH1ru
	w20z1WQqCRNJqy/2iZADfifYW9CDf2OC8QxPHbhPGVE1mYE+g+gieCY8dzgCAiDwLdl/2c
	oAnr+dltr60BXACms8kgR5iSe/d2jpQ=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1749807243; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=HmL+SUXn84DQyTGwzvsf9NWUSwsHo91ICHEyzRG2yx8=;
	b=lpN24zC7WD/eK117SwoAYZ/cF4nU4+LEabvXcZ1LQUS4N2KgjxvNSp13d+HcdT0yuMH1ru
	w20z1WQqCRNJqy/2iZADfifYW9CDf2OC8QxPHbhPGVE1mYE+g+gieCY8dzgCAiDwLdl/2c
	oAnr+dltr60BXACms8kgR5iSe/d2jpQ=
Message-ID: <759aabab-a5d6-4fdf-b19a-65ad5363340d@suse.com>
Date: Fri, 13 Jun 2025 11:34:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [MINI-OS PATCH 00/12] kexec: add kexec support to Mini-OS
From: Juergen Gross 
To: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org,
 samuel.thibault@ens-lyon.org
References: <20250321092451.17309-1-jgross@suse.com>
 <25fce343-d18c-46b5-ac68-5ba4c1335df9@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: <25fce343-d18c-46b5-ac68-5ba4c1335df9@suse.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------z8WyUxu4jfBZtkknjzHUbVlf"
X-Spam-Flag: NO
X-Spam-Score: -6.20
X-Spamd-Result: default: False [-6.20 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SIGNED_PGP(-2.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];
	NEURAL_HAM_SHORT(-0.20)[-0.999];
	MIME_BASE64_TEXT(0.10)[];
	MIME_UNKNOWN(0.10)[application/pgp-keys];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~];
	MID_RHS_MATCH_FROM(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,imap1.dmz-prg2.suse.org:helo];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	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)[];
	TO_DN_NONE(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	HAS_ATTACHMENT(0.00)[]
X-Spam-Level: 

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------z8WyUxu4jfBZtkknjzHUbVlf
Content-Type: multipart/mixed; boundary="------------QS4ufNLs9K48IgXsi2pjyv9v";
 protected-headers="v1"
From: Juergen Gross 
To: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org,
 samuel.thibault@ens-lyon.org
Message-ID: <759aabab-a5d6-4fdf-b19a-65ad5363340d@suse.com>
Subject: Re: [MINI-OS PATCH 00/12] kexec: add kexec support to Mini-OS
References: <20250321092451.17309-1-jgross@suse.com>
 <25fce343-d18c-46b5-ac68-5ba4c1335df9@suse.com>
In-Reply-To: <25fce343-d18c-46b5-ac68-5ba4c1335df9@suse.com>

--------------QS4ufNLs9K48IgXsi2pjyv9v
Content-Type: multipart/mixed; boundary="------------8pEQatbnGK9eKvU6H820dX8Y"

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

T24gMDcuMDUuMjUgMTQ6NTgsIEp1ZXJnZW4gR3Jvc3Mgd3JvdGU6DQo+IFBpbmc/DQoNCkkn
ZCByZWFsbHkgYXBwcmVjaWF0ZSBzb21lIGZlZWRiYWNrLg0KDQoNCkp1ZXJnZW4NCg0KPiAN
Cj4gT24gMjEuMDMuMjUgMTA6MjQsIEp1ZXJnZW4gR3Jvc3Mgd3JvdGU6DQo+PiBBZGQgYmFz
aWMga2V4ZWMgc3VwcG9ydCB0byBNaW5pLU9TIGZvciBydW5uaW5nIGluIHg4NiBQVkggbW9k
ZS4NCj4+DQo+PiBXaXRoIHRoaXMgc2VyaWVzIGFwcGxpZWQgaXQgaXMgcG9zc2libGUgdG8g
YWN0aXZhdGUgYW5vdGhlciBrZXJuZWwNCj4+IGZyb20gd2l0aGluIE1pbmktT1MuDQo+Pg0K
Pj4gUmlnaHQgbm93IG5vIFhlbiByZWxhdGVkIHRlYXJkb3duIGlzIGRvbmUgKHNvIG5vIHJl
c2V0IG9mIGdyYW50IHRhYmxlLA0KPj4gZXZlbnQgY2hhbm5lbHMsIFBWIGRldmljZXMpLiBU
aGVzZSBzaG91bGQgYmUgYWRkZWQgdmlhIGtleGVjIGNhbGxiYWNrcw0KPj4gd2hpY2ggYXJl
IGFkZGVkIGFzIGEgZnJhbWV3b3JrLg0KPj4NCj4+IFRoaXMgaXMgYSBtYWpvciBidWlsZGlu
ZyBibG9jayBmb3Igc3VwcG9ydCBvZiBYZW5zdG9yZS1zdHViZG9tIGxpdmUNCj4+IHVwZGF0
ZSAoaW4gZmFjdCBJJ3ZlIHRlc3RlZCB0aGUga2V4ZWMgcGF0aCB0byB3b3JrIHVzaW5nIHRo
ZSBQVkgNCj4+IHZhcmlhbnQgb2YgWGVuc3RvcmUtc3R1YmRvbSkuDQo+Pg0KPj4gSnVlcmdl
biBHcm9zcyAoMTIpOg0KPj4gwqDCoCBhZGQga2V4ZWMgZnJhbWV3b3JrDQo+PiDCoMKgIE1p
bmktT1M6IGFkZCBmaW5hbCBrZXhlYyBzdGFnZQ0KPj4gwqDCoCBtaW5pLW9zOiBhZGQgZWxm
LmgNCj4+IMKgwqAgbWluaS1vczogYW5hbHl6ZSBuZXcga2VybmVsIGZvciBrZXhlYw0KPj4g
wqDCoCBtaW5pLW9zOiBrZXhlYzogZmluYWxpemUgcGFyYW1ldGVyIGxvY2F0aW9uIGFuZCBz
aXplDQo+PiDCoMKgIG1pbmktb3M6IHJlc2VydmUgbWVtb3J5IGJlbG93IGJvdW5kYXJ5DQo+
PiDCoMKgIG1pbmktb3M6IGtleGVjOiBidWlsZCBwYXJhbWV0ZXJzIGZvciBuZXcga2VybmVs
DQo+PiDCoMKgIG1pbmktb3M6IGtleGVjOiBtb3ZlIHVzZWQgcGFnZXMgYXdheSBmb3IgbmV3
IGtlcm5lbA0KPj4gwqDCoCBNaW5pLU9TOiBtbTogY2hhbmdlIHNldF9yZWFkb25seSgpIHRv
IGNoYW5nZV9yZWFkb25seSgpDQo+PiDCoMKgIE1pbmktT1M6IGtleGVjOiBzd2l0Y2ggcmVh
ZC1vbmx5IGFyZWEgdG8gYmUgd3JpdGFibGUgYWdhaW4NCj4+IMKgwqAgbWluaS1vczoga2V4
ZWM6IGFkZCBrZXhlYyBjYWxsYmFjayBmdW5jdGlvbmFsaXR5DQo+PiDCoMKgIG1pbmktb3M6
IGtleGVjOiBkbyB0aGUgZmluYWwga2V4ZWMgc3RlcA0KPj4NCj4+IMKgIENvbmZpZy5ta8Kg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqAgMSArDQo+PiDCoCBNYWtl
ZmlsZcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoCAxICsNCj4+
IMKgIGFyY2gveDg2L2tleGVjLmPCoMKgwqDCoMKgwqDCoMKgwqDCoCB8IDI3MyArKysrKysr
KysrKysrKysrKysrKysrKysrKysrKw0KPj4gwqAgYXJjaC94ODYvbWluaW9zLXg4Ni5sZHMu
U8KgIHzCoCAxNiArKw0KPj4gwqAgYXJjaC94ODYvbW0uY8KgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgIHwgMjM4ICsrKysrKysrKysrKysrKysrKysrLS0tLS0tDQo+PiDCoCBhcmNoL3g4
Ni90ZXN0YnVpbGQvYWxsLW5vwqAgfMKgwqAgMSArDQo+PiDCoCBhcmNoL3g4Ni90ZXN0YnVp
bGQvYWxsLXllcyB8wqDCoCAyICsNCj4+IMKgIGFyY2gveDg2L3Rlc3RidWlsZC9rZXhlY8Kg
wqAgfMKgwqAgNCArDQo+PiDCoCBhcmNoL3g4Ni94ODZfaHZtLlPCoMKgwqDCoMKgwqDCoMKg
IHzCoCA0NiArKysrKw0KPj4gwqAgaW5jbHVkZS9lbGYuaMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgIHwgMzQwICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysNCj4+
IMKgIGluY2x1ZGUva2V4ZWMuaMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgIDYzICsrKysr
KysNCj4+IMKgIGluY2x1ZGUvbW0uaMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKg
wqAgOCArDQo+PiDCoCBpbmNsdWRlL3g4Ni9vcy5owqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKg
wqAgNSArDQo+PiDCoCBrZXhlYy5jwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqAgfCAyNTMgKysrKysrKysrKysrKysrKysrKysrKysrKysrDQo+PiDCoCBtbS5jwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgIDg5ICsrKysr
KysrKy0NCj4+IMKgIDE1IGZpbGVzIGNoYW5nZWQsIDEyODkgaW5zZXJ0aW9ucygrKSwgNTEg
ZGVsZXRpb25zKC0pDQo+PiDCoCBjcmVhdGUgbW9kZSAxMDA2NDQgYXJjaC94ODYva2V4ZWMu
Yw0KPj4gwqAgY3JlYXRlIG1vZGUgMTAwNjQ0IGFyY2gveDg2L3Rlc3RidWlsZC9rZXhlYw0K
Pj4gwqAgY3JlYXRlIG1vZGUgMTAwNjQ0IGluY2x1ZGUvZWxmLmgNCj4+IMKgIGNyZWF0ZSBt
b2RlIDEwMDY0NCBpbmNsdWRlL2tleGVjLmgNCj4+IMKgIGNyZWF0ZSBtb2RlIDEwMDY0NCBr
ZXhlYy5jDQo+Pg0KPiANCg0K
--------------8pEQatbnGK9eKvU6H820dX8Y
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-----

--------------8pEQatbnGK9eKvU6H820dX8Y--

--------------QS4ufNLs9K48IgXsi2pjyv9v--

--------------z8WyUxu4jfBZtkknjzHUbVlf
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/Ey8FAmhL8IsFAwAAAAAACgkQsN6d1ii/Ey/+
+Qf/WysFGF1mnfatXjh2KnuUwTlX8nFhta/vonJgbVqjAQElKKtaPMixXgDubGz6VOV2MSMj8zzS
GDeWjdBJEaHL2G2g/WUvM4JSA9PXcaXApCwifjNw43+zZaPywIASiDwtgGk4JOsdWmwz8X2a7353
+icefOFjARu8tYkVJgWnr138c05JlAS+0fY/oOq9QSzlxa1IG0bJiYo9Biep7BiJAo1udCGr0QPw
/MHDpIws9BGSpou7URp6jSI2GDsPmxl6eybFuLKxec0FvhNCa3iO5pT252qLxIHDRkantE6NjarB
Wa1S40kujC47KePW8q3DzNX9rTPY/5M7wSy4cFpbLg==
=wXtE
-----END PGP SIGNATURE-----

--------------z8WyUxu4jfBZtkknjzHUbVlf--


From xen-devel-bounces@lists.xenproject.org Fri Jun 13 10:13:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 10:13:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014180.1392408 (Exim 4.92)
	(envelope-from )
	id 1uQ1Pf-0001Zg-GP; Fri, 13 Jun 2025 10:13:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014180.1392408; Fri, 13 Jun 2025 10:13: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 1uQ1Pf-0001ZZ-Dc; Fri, 13 Jun 2025 10:13:31 +0000
Received: by outflank-mailman (input) for mailman id 1014180;
 Fri, 13 Jun 2025 10:13: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 1uQ1Pe-0001ZT-93
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 10:13: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 0c922ef3-483f-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 12:13:28 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3a525eee2e3so1566294f8f.2
 for ; Fri, 13 Jun 2025 03:13:28 -0700 (PDT)
Received: from localhost.localdomain (188.226.6.51.dyn.plus.net.
 [51.6.226.188]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4532dea1b1asm49041305e9.14.2025.06.13.03.13.26
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Jun 2025 03:13:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0c922ef3-483f-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1749809607; x=1750414407; 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=bbQvKXfode3vKp2lM3/5KLgpJtUXhAU0zX5262RfasI=;
        b=bxWJJIcb/21NjHIkoaC34ot/KnYqIsAhw6uA8xW0rpEf2ljIG0V084CfZ3a5sWVqIL
         qrMi6XktdchLZ05nUsa2Q5wSVvY6Zaiyo09cGK1LnXwe8Vs3+RqE94TlpFhtRN8oHNoO
         pa4iaJN+fxp3vNl+dqP9pUlp5RH6mF8ZdtZIg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749809607; x=1750414407;
        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=bbQvKXfode3vKp2lM3/5KLgpJtUXhAU0zX5262RfasI=;
        b=LjoVw/eyYWoY2myOFRKyIXosk/URJ6jRVf8rQHz05+aJ74qq9L0hTGAi4MaoNl8qhl
         Dq4+n8K+El+JjhisRPF/7dhY+BMsm6F3D+a0p5Y7as4s64vXPa5qui22LeTIqARDpkfO
         T0U0EpjXxyTMOmbL/5KIiVFXoB5AQZDSx88XpCsDNAPN+OXpk32ud+C2vhY0yZoeZ7NB
         7SWzfnt6o2Wfi4GNl/1kdPOYGlZ9/EypZ0AWSDqLIDU9q9+QBEZBhPMnGdG28u7Tp0mN
         16ABH19GTtd/OHTWd79q76Jq/oiu01wA2cxHbFV7vfEYFltsMIiYSM1638d5slG7Pp6e
         TLGA==
X-Gm-Message-State: AOJu0YwOaI0QTDwN0cR5tc4SU+ZaT42knLwKaFYNVA1fKumDwNEwri1+
	WKxqqjG2Hh2hTdhbMzU0ThsbwuJVEEnivyOWsKnTMb5KgYJYGl/iOoUuGROiqNA/s0zVocBCiay
	eqUDKPPs=
X-Gm-Gg: ASbGncsyBSy0WyHYVahmd+qEVVqv+On3nyVRcZ8x/SqkQxaGbXDTO4rNyJGSGjE490/
	GarwInyzML2c34BowbqIxdjPrmkRfzskeDMCNgV/pJYsfGvMplQXkHZj7ql9Lg1GU1PH+nEXjf6
	8dEAqpnNZEYb4Kt0Ol3/ZVsU6HnWpgeNgUxJvxkBeR8dVKvabnxaI7D8oPsuR9QuPYJcEEOqKbi
	KD8r1Y1RLNPDZhIKSaCz1TB6FEsdZEB56JH5q3r+oaXg+jhLyqtkCOmN4/usnFi3RzfYe8gnM6j
	KEJJPYr6ho+orcmMw+smtBl6FySDc7CkQU4wTN069sW+67JM7Ezsenplp3kRkssHENjQomVBtiS
	zvoLUNs1mXQZzu8myICbi+UhFuqtqHThxDS4XxSdz
X-Google-Smtp-Source: AGHT+IHy/GyYYHuUrofCqs4FhNEwDFUe6d146z9qWDc9ZNTHuGWO4e5tOZd4O9USbOmp5dMqgBtmqQ==
X-Received: by 2002:a05:6000:420c:b0:391:3aaf:1d5f with SMTP id ffacd0b85a97d-3a56879428cmr2232805f8f.52.1749809607190;
        Fri, 13 Jun 2025 03:13:27 -0700 (PDT)
From: Frediano Ziglio 
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH] x86/pci: Use C99 style types for fixed integrals
Date: Fri, 13 Jun 2025 11:12:47 +0100
Message-ID: <20250613101249.164199-1-frediano.ziglio@cloud.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Just code style change.

Signed-off-by: Frediano Ziglio 
---
 xen/include/xen/pci.h | 26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index ef60196653..f22bbc2776 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -89,8 +89,8 @@ struct pci_dev_info {
     bool is_extfn;
     bool is_virtfn;
     struct {
-        u8 bus;
-        u8 devfn;
+        uint8_t bus;
+        uint8_t devfn;
     } physfn;
 };
 
@@ -209,26 +209,26 @@ static always_inline bool pcidevs_trylock(void)
 #define ASSERT_PDEV_LIST_IS_READ_LOCKED(d) ((void)(d))
 #endif
 
-bool pci_known_segment(u16 seg);
-bool pci_device_detect(u16 seg, u8 bus, u8 dev, u8 func);
+bool pci_known_segment(uint16_t seg);
+bool pci_device_detect(uint16_t seg, uint8_t bus, uint8_t dev, uint8_t func);
 int scan_pci_devices(void);
-enum pdev_type pdev_type(u16 seg, u8 bus, u8 devfn);
-int find_upstream_bridge(u16 seg, u8 *bus, u8 *devfn, u8 *secbus);
+enum pdev_type pdev_type(uint16_t seg, uint8_t bus, uint8_t devfn);
+int find_upstream_bridge(uint16_t seg, uint8_t *bus, uint8_t *devfn, uint8_t *secbus);
 
 void setup_hwdom_pci_devices(struct domain *d,
                              int (*handler)(uint8_t devfn,
                                             struct pci_dev *pdev));
 int pci_release_devices(struct domain *d);
-int pci_add_segment(u16 seg);
-const unsigned long *pci_get_ro_map(u16 seg);
-int pci_add_device(u16 seg, u8 bus, u8 devfn,
+int pci_add_segment(uint16_t seg);
+const unsigned long *pci_get_ro_map(uint16_t seg);
+int pci_add_device(uint16_t seg, uint8_t bus, uint8_t devfn,
                    const struct pci_dev_info *info, nodeid_t node);
-int pci_remove_device(u16 seg, u8 bus, u8 devfn);
+int pci_remove_device(uint16_t seg, uint8_t bus, uint8_t devfn);
 int pci_ro_device(int seg, int bus, int devfn);
 int pci_hide_device(unsigned int seg, unsigned int bus, unsigned int devfn);
 struct pci_dev *pci_get_pdev(const struct domain *d, pci_sbdf_t sbdf);
 struct pci_dev *pci_get_real_pdev(pci_sbdf_t sbdf);
-void pci_check_disable_device(u16 seg, u8 bus, u8 devfn);
+void pci_check_disable_device(uint16_t seg, uint8_t bus, uint8_t devfn);
 
 /*
  * Iterate without locking or preemption over all PCI devices known by Xen.
@@ -246,9 +246,9 @@ void pci_conf_write32(pci_sbdf_t sbdf, unsigned int reg, uint32_t data);
 uint32_t pci_conf_read(uint32_t cf8, uint8_t offset, uint8_t bytes);
 void pci_conf_write(uint32_t cf8, uint8_t offset, uint8_t bytes, uint32_t data);
 int pci_mmcfg_read(unsigned int seg, unsigned int bus,
-                   unsigned int devfn, int reg, int len, u32 *value);
+                   unsigned int devfn, int reg, int len, uint32_t *value);
 int pci_mmcfg_write(unsigned int seg, unsigned int bus,
-                    unsigned int devfn, int reg, int len, u32 value);
+                    unsigned int devfn, int reg, int len, uint32_t value);
 unsigned int pci_find_cap_offset(pci_sbdf_t sbdf, unsigned int cap);
 unsigned int pci_find_next_cap_ttl(pci_sbdf_t sbdf, unsigned int pos,
                                    const unsigned int caps[], unsigned int n,
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 10:13:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 10:13:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014181.1392419 (Exim 4.92)
	(envelope-from )
	id 1uQ1Pq-0001u6-Ne; Fri, 13 Jun 2025 10:13:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014181.1392419; Fri, 13 Jun 2025 10:13: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 1uQ1Pq-0001ty-Kk; Fri, 13 Jun 2025 10:13:42 +0000
Received: by outflank-mailman (input) for mailman id 1014181;
 Fri, 13 Jun 2025 10:13: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 1uQ1Pp-0001ZT-Q5
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 10:13:41 +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 12d252ff-483f-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 12:13:38 +0200 (CEST)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-451d7b50815so16103875e9.2
 for ; Fri, 13 Jun 2025 03:13:38 -0700 (PDT)
Received: from localhost.localdomain (188.226.6.51.dyn.plus.net.
 [51.6.226.188]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a568b7741bsm1908658f8f.98.2025.06.13.03.13.37
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Jun 2025 03:13:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 12d252ff-483f-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1749809618; x=1750414418; 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=1g0iRNh3eWaIg453dC2caqEusUjyjQC++hqpu26lyrk=;
        b=C442qQFFupaR4cMxB/HFXW+1oCbwsYb177rmrHehPqkCBWtD+XWfuB2ZzjLu/VQoBK
         rqge1BgsHMapldKbTKiIXL9upr2eyu6wPkJz9k7oofO++LoYL4HX2mHvS/+M6orJW3B8
         uYNOnUSlA4Y3A8XlxmvKJj7DmFZECGXPBeSlM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749809618; x=1750414418;
        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=1g0iRNh3eWaIg453dC2caqEusUjyjQC++hqpu26lyrk=;
        b=pHHeJae1+mgCyUrPMlQmA7mVFz0fxAfNOi3MoorCno2Pij5DvcSDUB6P9ujgr+2r+k
         O21qkd6Qpfs4zUOdJ60ASCnlJDD19TnDxzqVzhP8UELDYiUb4D1ypKxF55mFdXvz+Flz
         gGD8DqUDoxTynAJQzDpnBs9krIiamRfSunGyAIMTiua2QSuY2D6TNQoHWYhxqSiwM7fE
         HykNElSK9lIkz6VG77n7V08xpLqlNt6qgYvkKCUXATY778s86BrAXgXtH7nhyPRJekZ6
         PoSvW6Iecm8yp9X2b/8LG7tflRW/peaAIyQM2Uw2njz0+btD+vJKdvxSeGlHS/RX+ePc
         Tt+A==
X-Gm-Message-State: AOJu0YzHjKFlpRl4k0VxNBo9r3i8OFJC00rr4fSuRI/Jhwro5uU9qs8m
	CWFoNgewGJzh7dwXLdFlkIRYfECyJvMfLijfY+anA2UgBdDvN0p53uSGw3HWNb3L3rmEsxGKd+6
	E4zOld7Y=
X-Gm-Gg: ASbGncvPJ4kT5B4YxEspa8LVdxrMwqBA0EmPkcvRYmulVVS5nIiJcn1Hvqs8YbRaiZx
	FkjRhC61KyLfeW7uoCF8TUrmqDvX1wXFPGCZ+ZjNb85u8UFvQ0NIc5FeiHy03hf9WK+pZSmgLy8
	oB4cke2td9WTiP+R2QXDZPa4yUgDEdNVLwzVrU3jQx9bBNNxtLrS7343qKoxqImj4UPk5agz65m
	cXBFe2z+zrbfWF2yLKBb+JRopk9YmG9kFX3djxVdoc6Oi+GG1iMbTyCCwHB6BVP5CUgXK9oceBJ
	0kCD+Kn4SE8vSh0lSXXld2h9JMtE//CIXR7qtrxsbko10NkSYOrbaHqpM/04jIxvUjS6bVdrsd9
	2odKCATjuxvwuIA22B3S38Kw6NIlQnw==
X-Google-Smtp-Source: AGHT+IGfth0o918N3ezBc4IxajMTow9a3lvStQGcrOpV1RbH+j39h+zN5BGWfFdqPEAyTfy+k3l9cg==
X-Received: by 2002:a05:600c:6095:b0:43c:f513:9591 with SMTP id 5b1f17b1804b1-45334b0fc1emr25217705e9.14.1749809617714;
        Fri, 13 Jun 2025 03:13:37 -0700 (PDT)
From: Frediano Ziglio 
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH] drivers/pci: Add minor comment for maximum capability constant
Date: Fri, 13 Jun 2025 11:13:32 +0100
Message-ID: <20250613101334.164310-1-frediano.ziglio@cloud.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The comment is similar to extended capabilities in the function
below.

Signed-off-by: Frediano Ziglio 
---
 xen/drivers/pci/pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/drivers/pci/pci.c b/xen/drivers/pci/pci.c
index acf4cebe42..e1ddde90eb 100644
--- a/xen/drivers/pci/pci.c
+++ b/xen/drivers/pci/pci.c
@@ -11,7 +11,7 @@
 unsigned int pci_find_cap_offset(pci_sbdf_t sbdf, unsigned int cap)
 {
     u8 id;
-    int max_cap = 48;
+    int max_cap = 48; /* 192 bytes, minimum 4 bytes per capability */
     u8 pos = PCI_CAPABILITY_LIST;
     u16 status;
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 10:32:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 10:32:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014196.1392428 (Exim 4.92)
	(envelope-from )
	id 1uQ1hy-0007Eb-6x; Fri, 13 Jun 2025 10:32:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014196.1392428; Fri, 13 Jun 2025 10: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 1uQ1hy-0007De-3N; Fri, 13 Jun 2025 10:32:26 +0000
Received: by outflank-mailman (input) for mailman id 1014196;
 Fri, 13 Jun 2025 10:32: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 1uQ1hx-0007DY-4b
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 10:32:25 +0000
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com
 [2a00:1450:4864:20::234])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b127cf52-4841-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 12:32:23 +0200 (CEST)
Received: by mail-lj1-x234.google.com with SMTP id
 38308e7fff4ca-32a6f5cb6f9so9110101fa.2
 for ; Fri, 13 Jun 2025 03:32:23 -0700 (PDT)
Received: from pc636 (host-95-203-1-180.mobileonline.telia.com. [95.203.1.180])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-553ac1dc3absm402194e87.197.2025.06.13.03.32.08
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Jun 2025 03:32:09 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b127cf52-4841-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749810742; x=1750415542; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to;
        bh=Wu4qJvn4Llwk0tWZQ65fBk0n6CvVyWDwwMQQPjhEpAs=;
        b=E/V0Bl0Wo80aX2aQH0b2+MdRWyyLNS+5IcJmgJAcP/0CniDYtO0BAT+mWgTBPHfRNU
         rvEv7SJXQehxRzAp+4jrle+VKXxwARLdXK8m0GQ5Pjp13OlSI7a75WNdoFJYLoODmxGE
         Lv6w5ZvCFokfRLQTf4IxGff/LawYVBWJSox9VSrznVjjslnRXVPmvfPTQn1eaSa7H50M
         8YGaRX5XBf6cik/3x63MXksfxdc6pIEj5kYZqeys+SdZGfWkWErTrkDj8EIluEAzAFQf
         JWGx9cn2ZQTZWBVk2KuiTeFBJyDNnrqWaRIjgNSM3it1WHanqdOh8LtoMkA9LmphIX8S
         L8dQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749810742; x=1750415542;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Wu4qJvn4Llwk0tWZQ65fBk0n6CvVyWDwwMQQPjhEpAs=;
        b=c0nf42coP1UmWC0w64CwAvXrH7FPp1e3n1rorRlDYUMVYdrHWmUel1EHNnSrqB82F9
         jq5++tU1yDlPqjtLPHcoeeIA38I9UlJR40xaSyCvclzCZUsIDtUImYBdBv5rE6x/9ksl
         68Jsa2RWyw4yB9GO/fwMGK43/KH3XI4MjsiprK4V9M74ldbS75YFmfo/MP4TTROhc8nZ
         2pO0VmIAVLXOiVItWAAZ7EqKdbJKesA36+wC7HEv/aMIsMUcfsOvtZ7GDZ6/x93eXhbw
         UYlP4deh4Pn1lreJmx4+7Mgl6Bchj3iPdazgiNUoKs98F+iG78wrE1m26VejQLzjPFX8
         XXtQ==
X-Forwarded-Encrypted: i=1; AJvYcCUcnexuKqNg5fWYyiKh+buvlkWVOe3gl/e60MqjCS53IC7evFF3Qf0ez4jqSAg+KdU2nvcd7RqJBe4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyVLK9ykPpul+44PEwEVgbmnlITLbgreIvUH7GWpBSYiuVoN0fD
	lxvMk4Py646IEaP04MpxGkUkRJs8dQqkx+Rvh2DM0b3lehbSJt1PHrg7lTgjLfda
X-Gm-Gg: ASbGncvfWKGccGyApCYUqayDvpFxlIJ0EV+rV/P4+FEOdcMdwGQvgjdbSa0hkKCs4xK
	phSMXq8RHL+8OLxqHrlAiKF1joFY/spHCjFprwcmQ0sw/ncZXWtC/Q+z6Xt9ifFNw+t1L4AQnKb
	CW1wDtkLUSkjWBRyIHHZ0y19vMSr0IDalcixXA2ZrGmJnnxRaItbyUNEh57ef0KT7bjfDdNNDqb
	r0gzK2K3UXxwVj3slf2OCsLhVLWdFLU9copQP5R/ZPTroRYTT5s1Ax8cRz49C59e1SGNqUpfizq
	06SFEb/KZW2lvhOgFRqfBYeGzHG5U4vn8Gain6iZ2KzCloxs1xgaDcxw2t0EvfTv0EFs690KEuw
	6U4S7wWIj9PQ=
X-Google-Smtp-Source: AGHT+IH9UJ7uFj1fdsdkfO2A9iWrTLeLn4U5mol1YXw4WzFM5kRsgurhm6wsyckaQjO11Dn5eJdcbA==
X-Received: by 2002:a05:6512:3b06:b0:553:a3e7:812e with SMTP id 2adb3069b0e04-553af90817dmr681078e87.20.1749810730193;
        Fri, 13 Jun 2025 03:32:10 -0700 (PDT)
From: Uladzislau Rezki 
X-Google-Original-From: Uladzislau Rezki 
Date: Fri, 13 Jun 2025 12:32:06 +0200
To: Alexander Gordeev 
Cc: Andrew Morton , linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, sparclinux@vger.kernel.org,
	xen-devel@lists.xenproject.org, linuxppc-dev@lists.ozlabs.org,
	linux-s390@vger.kernel.org, Hugh Dickins ,
	Nicholas Piggin ,
	Guenter Roeck , Juergen Gross ,
	Jeremy Fitzhardinge ,
	Ryan Roberts 
Subject: Re: [PATCH 2/6] mm: Lock kernel page tables before entering lazy MMU
 mode
Message-ID: 
References: 
 <7bd3a45dbc375dc2c15cebae09cb2bb972d6039f.1749747752.git.agordeev@linux.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7bd3a45dbc375dc2c15cebae09cb2bb972d6039f.1749747752.git.agordeev@linux.ibm.com>

On Thu, Jun 12, 2025 at 07:36:09PM +0200, Alexander Gordeev wrote:
> As a follow-up to commit 691ee97e1a9d ("mm: fix lazy mmu docs and
> usage") take a step forward and protect with a lock not only user,
> but also kernel mappings before entering the lazy MMU mode. With
> that the semantics of arch_enter|leave_lazy_mmu_mode() callbacks
> is consolidated, which allows further simplifications.
> 
> The effect of this consolidation is not fully preemptible (Real-Time)
> kernels can not enter the context switch while the lazy MMU mode is
> active - which is easier to comprehend.
> 
> Signed-off-by: Alexander Gordeev 
> ---
>  include/linux/pgtable.h | 12 ++++++------
>  mm/kasan/shadow.c       |  5 -----
>  mm/memory.c             |  5 ++++-
>  mm/vmalloc.c            |  6 ++++++
>  4 files changed, 16 insertions(+), 12 deletions(-)
> 
> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> index 0b6e1f781d86..33bf2b13c219 100644
> --- a/include/linux/pgtable.h
> +++ b/include/linux/pgtable.h
> @@ -224,12 +224,12 @@ static inline int pmd_dirty(pmd_t pmd)
>   * a raw PTE pointer after it has been modified are not guaranteed to be
>   * up to date.
>   *
> - * In the general case, no lock is guaranteed to be held between entry and exit
> - * of the lazy mode. So the implementation must assume preemption may be enabled
> - * and cpu migration is possible; it must take steps to be robust against this.
> - * (In practice, for user PTE updates, the appropriate page table lock(s) are
> - * held, but for kernel PTE updates, no lock is held). Nesting is not permitted
> - * and the mode cannot be used in interrupt context.
> + * For PREEMPT_RT kernels implementation must assume that preemption may
> + * be enabled and cpu migration is possible between entry and exit of the
> + * lazy MMU mode; it must take steps to be robust against this. There is
> + * no such assumption for non-PREEMPT_RT kernels, since both kernel and
> + * user page tables are protected with a spinlock while in lazy MMU mode.
> + * Nesting is not permitted and the mode cannot be used in interrupt context.
>   */
>  #ifndef __HAVE_ARCH_ENTER_LAZY_MMU_MODE
>  #define arch_enter_lazy_mmu_mode()	do {} while (0)
> diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c
> index d2c70cd2afb1..45115bd770a9 100644
> --- a/mm/kasan/shadow.c
> +++ b/mm/kasan/shadow.c
> @@ -313,12 +313,10 @@ static int kasan_populate_vmalloc_pte(pte_t *ptep, unsigned long addr,
>  	__memset(page_to_virt(page), KASAN_VMALLOC_INVALID, PAGE_SIZE);
>  	pte = pfn_pte(page_to_pfn(page), PAGE_KERNEL);
>  
> -	spin_lock(&init_mm.page_table_lock);
>  	if (likely(pte_none(ptep_get(ptep)))) {
>  		set_pte_at(&init_mm, addr, ptep, pte);
>  		data->pages[index] = NULL;
>  	}
> -	spin_unlock(&init_mm.page_table_lock);
>  
>  	return 0;
>  }
> @@ -465,13 +463,10 @@ static int kasan_depopulate_vmalloc_pte(pte_t *ptep, unsigned long addr,
>  
>  	page = (unsigned long)__va(pte_pfn(ptep_get(ptep)) << PAGE_SHIFT);
>  
> -	spin_lock(&init_mm.page_table_lock);
> -
>  	if (likely(!pte_none(ptep_get(ptep)))) {
>  		pte_clear(&init_mm, addr, ptep);
>  		free_page(page);
>  	}
> -	spin_unlock(&init_mm.page_table_lock);
>  
>  	return 0;
>  }
> diff --git a/mm/memory.c b/mm/memory.c
> index 71b3d3f98999..1ddc532b1f13 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -3017,6 +3017,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
>  			pte = pte_offset_kernel(pmd, addr);
>  		if (!pte)
>  			return err;
> +		spin_lock(&init_mm.page_table_lock);
>  	} else {
>  		if (create)
>  			pte = pte_alloc_map_lock(mm, pmd, addr, &ptl);
> @@ -3042,7 +3043,9 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
>  
>  	arch_leave_lazy_mmu_mode();
>  
> -	if (mm != &init_mm)
> +	if (mm == &init_mm)
> +		spin_unlock(&init_mm.page_table_lock);
> +	else
>  		pte_unmap_unlock(mapped_pte, ptl);
>  
>  	*mask |= PGTBL_PTE_MODIFIED;
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index ab986dd09b6a..57b11000ae36 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -105,6 +105,7 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
>  	if (!pte)
>  		return -ENOMEM;
>  
> +	spin_lock(&init_mm.page_table_lock);
>
This is not good. We introduce another bottle-neck.

--
Uladzislau Rezki


From xen-devel-bounces@lists.xenproject.org Fri Jun 13 10:33:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 10:33:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014206.1392440 (Exim 4.92)
	(envelope-from )
	id 1uQ1jH-0008Af-Jr; Fri, 13 Jun 2025 10:33:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014206.1392440; Fri, 13 Jun 2025 10:33:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uQ1jH-0008AY-Fz; Fri, 13 Jun 2025 10:33:47 +0000
Received: by outflank-mailman (input) for mailman id 1014206;
 Fri, 13 Jun 2025 10:33: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 1uQ1jG-00089X-FH
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 10:33:46 +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 e23d13d1-4841-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 12:33:45 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a54700a463so1310405f8f.1
 for ; Fri, 13 Jun 2025 03:33:45 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2365d8a1fafsm11422905ad.70.2025.06.13.03.33.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 13 Jun 2025 03:33:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e23d13d1-4841-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749810825; x=1750415625; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=wNC66ikY/A4PiKfewBZdiNiqRm0SiC9C4Yi9KpR2H6o=;
        b=FQxeIIw4DQajsX7mfillwMblextLdnpesbg/ZTDpIT08Gb1u0BfIU5AImQ+gtaldxR
         u6ZPaV2X4FFIlzEhSmIo6hiJWiRu84lui1xtSC4Ikyl4H6h4vH0B5NEzDqWrjL33ZgRK
         ftRF4vv1xrAb1qxVtqgAbIX26d+eF8S4l+3dmXjX+mUWvP3QolugXQpABgH6JBJC7wFp
         XCVY1ka8rbj/+NgkREKirPsiowHWGxwelSZLHPI8OEqJ0OzSLaw7xVipM0FE3br02aVm
         d3DJVmgEX/LpBk5FdQ2waLnhblWMTnEfT9/CuZoqutZeS+hHumVyKiRGLdVAklnTxVts
         kl8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749810825; x=1750415625;
        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=wNC66ikY/A4PiKfewBZdiNiqRm0SiC9C4Yi9KpR2H6o=;
        b=m937og29GGG2EYi1S4KZJ4PfLC5m12HOQO6Iuk4T31pOclIQtiPTDm+bFkyefnEnkP
         qa6cvPQolJ5ArhmWSbTL4wL/E0+g2r2nVQXE+aeB8sQoOr6E282GLxsUZ7X1GoDaGpfG
         qLWo+PO+1Ej6xQ/1KMoQYOoHZxLaESr1pkmkA/krSAo/+zT83PKVjqV1UAGCA/wrx7hP
         9exPHuxByO1BY+85CHj1jBqnvHH40nfzeTZBMqO1efJ1rFJ7HusEIwJYdtSO0Mbwxnx0
         Yr90vztkb61IRmjN9/bccnNFshqZytp4q0E2OUJxWEr/gegbQYki1w6fyHpPyoVwcNc1
         Vw3g==
X-Forwarded-Encrypted: i=1; AJvYcCV6Pkjjxv6ZrmwHpwdMdJ+fJgKPFJ42e2u8a/XAroWj4TLR0N11DS6zcjSSlL3t4o2AUV619pTZl08=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywkv23KbE9C4X3Ofug1D1DFjuzosRRNMgeoOuW+1Charn3b+47M
	48fooplJWnr6Ei+Kg2r7QxbH2XiByb+yd+dpKxY+9fl1Wqna64XAKwc26bH7AR/PcQ==
X-Gm-Gg: ASbGncsI9zaLSabqL42ANaCqioYTv0vSlxS5FgUr3gQN78M+AnHWwy8yaHTx1gV0jAr
	suavF5W8m5BP8wlkSa5vZ8dCEIxWvSVs0B6aQTaRO37rX28GzwLKAzttG7U0isGtf8c/otC3Z4c
	JCgnldSvOHiVd6lzo0T06QlgxS+/1gLhoWnfPuNs6ql5h/8bxsWERS3gb35a6M7AtXFZCnhvL/m
	Vgy0E5z+teUjC2D+yFeC+4RHt5ngk2aBXE5KwhEysr8I34gR1rHwpm8bRLgjMnn5jWBWoFtbJgr
	6rsgGgcU4COF7OK5xqolMmKEudMYLWn2EaMQWIHkVUeuoU0qTVJEN4azDaqxqTS1Rclte3KAUG1
	QXqJ43cvoSv2sve39Se3lx/c0oT95YML3OrqZcg2bXKIJosA=
X-Google-Smtp-Source: AGHT+IEbbu90whiZYKluiN+LarlEwG6wvwpE9dj/a1LRqHOGadj1HeiZX24WGqSS9+Ey6HNIdyxcWg==
X-Received: by 2002:a05:6000:40d9:b0:3a4:e238:6496 with SMTP id ffacd0b85a97d-3a56d827f55mr191596f8f.18.1749810824958;
        Fri, 13 Jun 2025 03:33:44 -0700 (PDT)
Message-ID: <9ea9049f-1d29-4830-9d99-3f1e86356e17@suse.com>
Date: Fri, 13 Jun 2025 12:33:35 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] drivers/pci: Add minor comment for maximum capability
 constant
To: Frediano Ziglio 
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: <20250613101334.164310-1-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: <20250613101334.164310-1-frediano.ziglio@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.06.2025 12:13, Frediano Ziglio wrote:
> The comment is similar to extended capabilities in the function
> below.
> 
> Signed-off-by: Frediano Ziglio 

Acked-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 10:37:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 10:37:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014213.1392452 (Exim 4.92)
	(envelope-from )
	id 1uQ1mW-0001DH-28; Fri, 13 Jun 2025 10:37:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014213.1392452; Fri, 13 Jun 2025 10: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 1uQ1mV-0001DA-VD; Fri, 13 Jun 2025 10:37:07 +0000
Received: by outflank-mailman (input) for mailman id 1014213;
 Fri, 13 Jun 2025 10:37: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 1uQ1mU-0001Cy-LZ
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 10:37:06 +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 58ef8d08-4842-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 12:37:04 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3a507e88b0aso1993032f8f.1
 for ; Fri, 13 Jun 2025 03:37:04 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a568a5546asm1932027f8f.3.2025.06.13.03.37.03
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Jun 2025 03:37:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 58ef8d08-4842-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749811024; x=1750415824; 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=NZJcwfaB1xOTTE0hWQBI36KfPHx3equ3xZcmu8RTB98=;
        b=APwHETj1KR+MFZJv0Bs8WHsW7dkvmKCw4l6XN8Oaq+R0bMwk0oEJTP14SexPi8kVlD
         QnXxVUUcX0RDOwN0jwc50As1zjdXqMhpBMy1QEOvlqveRATj89zgF5vodMTKTkEjzeAO
         PWgh+zN/SAoh2tEmKoo+651wyxu4H6nxDrkuY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749811024; x=1750415824;
        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=NZJcwfaB1xOTTE0hWQBI36KfPHx3equ3xZcmu8RTB98=;
        b=h/ucfNc/2lOu5CtcugvyCS8WS3EP65+QNkTvDxZBQLSH74SN/H9klDSmHgdJa47Vlc
         rKf9k+uHuUCy4t1YukrtEPNSlMlEDHKNF4p8+1WOplkFYeo04Y4Pp/F/LIWIn5LZkvjM
         YKfsd6SzCg5IQx4eOPzaDrMwwcNXzz2ufT50mw2tEyMF2ckcm6L1oUnchXO8UlxcWH0W
         q7QVYI8Awb9ZbN+tW8IEaPjk2BOGz9+xnf3uAphR9AW9GM9aBFb+SNVXh0VmvQRpZlOD
         QnhicpLBgURLmQQNMlg0/XsoQkIb+mtwMBYfjT5wUbQ6fzRRYRueTbayWks2uLhCqjHH
         e2iA==
X-Gm-Message-State: AOJu0YxiedjA6aQsn1dDRBsGRT2jLV5aCfpIY2Okvxxyapo1nIPI8oDn
	aIpdF6wllk++lbV4nNOMVBE/57AvB9FD8ZE2m3QVPkvsKtTkP0hePIP6yLumBX46JL4=
X-Gm-Gg: ASbGncv6Lrx3vENQLcEqj+2KLz+EOmGj1b75tnnN/sYB9i6LQznYo9TvvwafxEvfb7N
	tP3cxztd8PP+x0N26BM/R/KgyyE5atyzJQGCNM+tT1Q0IQ5oKAwfFpV44/DNYCfms2AcyIyRpS+
	UhVNfsh02A8RAau1MgDgpd9QoPc9/eeuoKPxzmNkV41vyu5nz9P5jaGZgtsgNWjMo6I6qUdoCb7
	JJ6gXcW0I5yld5gwju4WJHJ+03jGYTAklLkRc4D2vuLYHmLzttj0C/e3k+SqSrAuEAsijIWcPDq
	TNS6wwxrNzhwpTPbY+6qVeapsamZCHWVbM1Lxw7uFJsOgdfBBNN8yL7oelwz0Wq75D5CyGBI7AW
	6b67N4bF/P0DEsABit3hLQnmpI+kXXA==
X-Google-Smtp-Source: AGHT+IF/UidgxPgXo0fy9Hq0e0DgKLdDQyuLAF4ikHMpkf933wMnnCchHR0ydMv1ApzQxJHqBQEu6g==
X-Received: by 2002:a05:6000:40de:b0:3a4:e68e:d33c with SMTP id ffacd0b85a97d-3a56877ab0dmr2115115f8f.47.1749811024142;
        Fri, 13 Jun 2025 03:37:04 -0700 (PDT)
Date: Fri, 13 Jun 2025 12:37:03 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Frediano Ziglio 
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH] x86/pci: Use C99 style types for fixed integrals
Message-ID: 
References: <20250613101249.164199-1-frediano.ziglio@cloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250613101249.164199-1-frediano.ziglio@cloud.com>

On Fri, Jun 13, 2025 at 11:12:47AM +0100, Frediano Ziglio wrote:
> Just code style change.
> 
> Signed-off-by: Frediano Ziglio 
> ---
>  xen/include/xen/pci.h | 26 +++++++++++++-------------

I think if you change the types of the declarations in pci.h you
should also change the types of the definitions in pci.c.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jun 13 10:40:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 10:40:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014227.1392462 (Exim 4.92)
	(envelope-from )
	id 1uQ1pc-0002hP-FI; Fri, 13 Jun 2025 10:40:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014227.1392462; Fri, 13 Jun 2025 10:40:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uQ1pc-0002hI-By; Fri, 13 Jun 2025 10:40:20 +0000
Received: by outflank-mailman (input) for mailman id 1014227;
 Fri, 13 Jun 2025 10:40: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 1uQ1pa-0002hC-R8
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 10:40:18 +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 ca555d73-4842-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 12:40:14 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a5257748e1so1496155f8f.2
 for ; Fri, 13 Jun 2025 03:40:14 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2365de78335sm11355315ad.117.2025.06.13.03.40.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 13 Jun 2025 03:40:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ca555d73-4842-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1749811214; x=1750416014; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Jfio+SURPBp/xyxYHWqlEWbdwyqneL3EihsmdfPpwwA=;
        b=e0ht8ekn8YuqXDgj0vACTOBwxQ0mVUBVpKP4W0C/SXrNFRja+cw8Fd/e3byyxSdobF
         S1XPJK1id9HpWCE3RgCz/JC5jnqHzFxFJ1vHF0+jg4YDlelpvK4hItW+9g5U8m40d5rP
         11aSrbNynBZTr69qc0Wumxy27LKNZCXCVV5LiUDOx4UPllPCQGaM9/oTklsq4xJGVfrr
         tovy9JgYhv1M8L4LfifKPJhv7pfXmUEeKwZu5teQ14aobFb+UiQCKNY1QGO5t5QVK6b8
         ZAFGZ163Qg8OAYbW9yOeVnhZamnYGO/nqOT2FJIh1kRDBAO6UkzZcI0zP0GUbZpuUU9f
         0jmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749811214; x=1750416014;
        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=Jfio+SURPBp/xyxYHWqlEWbdwyqneL3EihsmdfPpwwA=;
        b=Qr8h5tzGAB1Aiwg513LcjVqVVxhvfSRaG6EEQ3a39Q7LR08rSzb2vJ5clqriz83pFr
         81jQgnkqugQS9T+Ie7ZSNnaAnbSSP8FQwh+mwIWqyJX6mCpeIy7ZCUiIj/iNQqOBcLG9
         hVXEJTNH6z6t+Dm5wAEn6+UpL13W2RCAcLZ/ixDFe2HWXPRFRxe55WtBMPIEYE79i5rS
         R5kXV+U8a427z/vflwwj0qSR57Cm9dDjb4SGaVVh8vgWShRQPAMdfilTNW1YrZWb9MXn
         qBbFAdmiOdj6IlodyZ1iPPiYRa9aYnnNhHot/C2g9xnb8NAh9x8m7G7I1NlAdT4m0b8Y
         frRg==
X-Forwarded-Encrypted: i=1; AJvYcCV5jqwtQ6w22w4mg+PH10IR4MgA+w0bIHFGBAM4zacN+BqUA0PjcZBHtVwXQ/w01CRLGjVOaON7uNU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyopKpI3C2S7xOK/YETXl9ic1WfHjYt1T/aT/Eva117PO62opUe
	2opbcYnip36sgyFDVxyMvJ3T53gNCAEB9dJmtlTQt873Twl1MwqFBw/LSqDJFDVYiw==
X-Gm-Gg: ASbGnctd96rdNCjriBLB3/cYQIMuw8UpofDOr/BJ6cC+wI66U1SzZ4tE7Q3CNkv4B9F
	yXKNhuDobJLKloX8BvUlLYW2jei1/vNeUXM+VPKrxiXqcdPtpbTo7tMhD6MD6SEzugpBkNgEC35
	lbBcWPiuio2Y6tWl1q+2MwrTXdgji7JKirrOPxF+oEQjopPQIy475cilibFdmMNYtrPVpP9R9DH
	ibydM98OQI3ZfOobgOoGwPajejU3vdAInaSKvOi9YsCxo4wjqe0CHMiabFHz7NIbpxL6QisbUpl
	rdCIeaacO+eMqF3Tsa6fP/8cIiT8P3m2gT1KC206L9HsqoHpBmOB4bGp1rN4u78ZIv1ax5V0zVH
	oCQx54DGeHbzagfTAOyCbigyqqi90ilp+ol0BMef5LmIhxSg=
X-Google-Smtp-Source: AGHT+IFbYvpLqKAdsbR6/6+XQPQuRoPB7edq3zhE3fyJIcjF2VJyNDh3CX2kCItGStCAzCM+LKQKjA==
X-Received: by 2002:a05:6000:18a5:b0:3a3:7387:3078 with SMTP id ffacd0b85a97d-3a5686e945bmr2316365f8f.4.1749811214299;
        Fri, 13 Jun 2025 03:40:14 -0700 (PDT)
Message-ID: 
Date: Fri, 13 Jun 2025 12:40:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/pci: Use C99 style types for fixed integrals
To: Frediano Ziglio 
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: <20250613101249.164199-1-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: <20250613101249.164199-1-frediano.ziglio@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.06.2025 12:12, Frediano Ziglio wrote:
> Just code style change.
> 
> Signed-off-by: Frediano Ziglio 
> ---
>  xen/include/xen/pci.h | 26 +++++++++++++-------------
>  1 file changed, 13 insertions(+), 13 deletions(-)

Aiui Eclair will object to declarations now (again?) going out of sync with
definitions.

> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -89,8 +89,8 @@ struct pci_dev_info {
>      bool is_extfn;
>      bool is_virtfn;
>      struct {
> -        u8 bus;
> -        u8 devfn;
> +        uint8_t bus;
> +        uint8_t devfn;
>      } physfn;
>  };
>  
> @@ -209,26 +209,26 @@ static always_inline bool pcidevs_trylock(void)
>  #define ASSERT_PDEV_LIST_IS_READ_LOCKED(d) ((void)(d))
>  #endif
>  
> -bool pci_known_segment(u16 seg);
> -bool pci_device_detect(u16 seg, u8 bus, u8 dev, u8 func);
> +bool pci_known_segment(uint16_t seg);
> +bool pci_device_detect(uint16_t seg, uint8_t bus, uint8_t dev, uint8_t func);
>  int scan_pci_devices(void);
> -enum pdev_type pdev_type(u16 seg, u8 bus, u8 devfn);
> -int find_upstream_bridge(u16 seg, u8 *bus, u8 *devfn, u8 *secbus);
> +enum pdev_type pdev_type(uint16_t seg, uint8_t bus, uint8_t devfn);
> +int find_upstream_bridge(uint16_t seg, uint8_t *bus, uint8_t *devfn, uint8_t *secbus);

As you make style adjustments, please also obey to other aspects of style, like
line length here.

Overall, while I don't mind the change, I'm not sure all of it is worthwhile.
We're still only halfway through converting functions taking (s,b,d,f) tuples
to take either struct pci_dev * or sbdf_t instead. Going straight to there
where possible might be a more desirable approach.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jun 13 11:00:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 11:00:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014259.1392477 (Exim 4.92)
	(envelope-from )
	id 1uQ28y-0000hc-15; Fri, 13 Jun 2025 11:00:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014259.1392477; Fri, 13 Jun 2025 11:00: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 1uQ28x-0000hV-Tf; Fri, 13 Jun 2025 11:00:19 +0000
Received: by outflank-mailman (input) for mailman id 1014259;
 Fri, 13 Jun 2025 11:00: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 1uQ28w-0000hP-Br
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 11:00:18 +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 95daf426-4845-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 13:00:15 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-451d54214adso16469605e9.3
 for ; Fri, 13 Jun 2025 04:00:15 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-4532e25fd3asm47791845e9.36.2025.06.13.04.00.13
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Jun 2025 04:00:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 95daf426-4845-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749812414; x=1750417214; 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=r4tZV0lh7pgUMqNSuKskN/40S+WEMGUKoG0+u2XcGqY=;
        b=lCQVXN0tyHoBh8GzqBvezd1i46aeY5aADoyabCPJ3lacg+6enRc+riy3TcxRHXytRm
         /vxF747YzYPDLuKw2CzatF6K6d+BvuWxDUrNp1voaI00PxRWZXxpMSmeMIdPz04We94n
         zjjfrk+yTmygcCxZxowF87qDYp/vS2yx9z/oE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749812414; x=1750417214;
        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=r4tZV0lh7pgUMqNSuKskN/40S+WEMGUKoG0+u2XcGqY=;
        b=qCQSJfk+8mx/T7lplxMj4EtXyq8QiWpP9+pWqSmKYpuAxDJhWJb+1LnGItGgAowd+x
         X6IJlLQD15aAd0Hqhoj+Iby9FHc+yYflmk5qNBGxbYb1/TQVZTcgSxFp82L3NobsGcll
         VnbegGb1nXwOOYage9liMtH8y9jNkPfve+ASJFsNWILj3xSpO8BROPY5W3z014lgkvo5
         Qr6eU9/141sIBGwNxqJzDKyzRjKAxSYHyUpe50D8wK0HLScRBCGCmvjemVRgLqiDhoLd
         2GoyIv/AzzAOd3YA4Bqze0NFEz4MSVrr0+n/rl+gjakxeZMphmDN2dUuD109zhBW+/9q
         mFrg==
X-Gm-Message-State: AOJu0YwRnHOzHlca+v3Xb0Ciix7yZyVWtddWCmF4KJ7qpbiKMh4L3i/Q
	ZZhLxAwcITq1s++Auh1xYTo4lYDs508jIFpgGaLYJGwRnUz9tolShueMR4zMb06V8plwT/8nTKs
	LKg8r
X-Gm-Gg: ASbGncsg5rqoh2xvyc9OrGisw81ONiCNx+5ErYi6HkZUEbC+MN89KPgql9z0mjS4wgS
	dPQkB7o2TA6E2J8cwxBCD0cRfIiOp5+bo9dUJOaGlAwoJiyyjAFuVYYOlaMixdebifmxTCQmuxE
	qcpO4tTjlyjd7bzivBiQ2QP1SyxKrVTnUP2SpJ3yaWHSup1LDHFAgDu07B03TQbauUDyKSOOqVk
	2denJ9lG6xF5nb7al1DFWyGeC7ZdFmpfFpiY3NFvGxs7ZnpS74CQGb3luLFnyyxq3SSOmroyK5r
	X+hW4W85KKPs/qPwVFCwS+LbvC7ctriNZ8rK250DcwZRrzJ8hGZyC+2mJmR2BotBGMvJo4Pnsf/
	nq6VospGuhc7jDGDHFUFeUxLl4iXfeg==
X-Google-Smtp-Source: AGHT+IHPMX61YLxZKKE/Xlqk0QxRaHp+5//u97B3a2A0BYr//MtGg/kY+xvjzey6onIDF5M/pPKj4g==
X-Received: by 2002:a05:600c:1d8b:b0:442:f956:53f9 with SMTP id 5b1f17b1804b1-45334b63261mr26018365e9.18.1749812414213;
        Fri, 13 Jun 2025 04:00:14 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Oleksii Kurochko ,
	Community Manager ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Juergen Gross ,
	Anthoine Bourgeois 
Subject: [PATCH v5] x86/hvmloader: select xen platform pci MMIO BAR UC or WB MTRR cache attribute
Date: Fri, 13 Jun 2025 13:00:09 +0200
Message-ID: <20250613110009.31245-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The Xen platform PCI device (vendor ID 0x5853) exposed to x86 HVM guests
doesn't have the functionality of a traditional PCI device.  The exposed
MMIO BAR is used by some guests (including Linux) as a safe place to map
foreign memory, including the grant table itself.

Traditionally BARs from devices have the uncacheable (UC) cache attribute
from the MTRR, to ensure correct functionality of such devices.  hvmloader
mimics this behavior and sets the MTRR attributes of both the low and high
PCI MMIO windows (where BARs of PCI devices reside) as UC in MTRR.

This however causes performance issues for users of the Xen platform PCI
device BAR, as for the purposes of mapping remote memory there's no need to
use the UC attribute.  On Intel systems this is worked around by using
iPAT, that allows the hypervisor to force the effective cache attribute of
a p2m entry regardless of the guest PAT value.  AMD however doesn't have an
equivalent of iPAT, and guest PAT values are always considered.

Linux commit:

41925b105e34 xen: replace xen_remap() with memremap()

Attempted to mitigate this by forcing mappings of the grant-table to use
the write-back (WB) cache attribute.  However Linux memremap() takes MTRRs
into account to calculate which PAT type to use, and seeing the MTRR cache
attribute for the region being UC the PAT also ends up as UC, regardless of
the caller having requested WB.

As a workaround to allow current Linux to map the grant-table as WB using
memremap() introduce an xl.cfg option (xen_platform_pci_bar_uc=0) that can
be used to select whether the Xen platform PCI device BAR will have the UC
attribute in MTRR.  Such workaround in hvmloader should also be paired with
a fix for Linux so it attempts to change the MTRR of the Xen platform PCI
device BAR to WB by itself.

Overall, the long term solution would be to provide the guest with a safe
range in the guest physical address space where mappings to foreign pages
can be created.

Some vif throughput performance figures provided by Anthoine from a 8
vCPUs, 4GB of RAM HVM guest(s) running on AMD hardware:

Without this patch:
vm -> dom0: 1.1Gb/s
vm -> vm:   5.0Gb/s

With the patch:
vm -> dom0: 4.5Gb/s
vm -> vm:   7.0Gb/s

Reported-by: Anthoine Bourgeois 
Signed-off-by: Roger Pau Monné 
Reviewed-by: Oleksii Kurochko
Acked-by: Jan Beulich  # hvmloader
---
Changes since v4:
 - Rename to Xen platform PCI to avoid confusion.
 - Set hvmloader BAR default to UC.
 - Unconditionally write XS node in libxl.
 - Introduce define for Xen PCI vendor ID.

Changes since v3:
 - Add changelog.
 - Assign BARs normally for xenpci if special casing fails.

Changes since v2:
 - Add default value in xl.cfg.
 - List xenstore path in the pandoc file.
 - Adjust comment in hvmloader.
 - Fix commit message MIO -> MMIO.

Changes since v1:
 - Leave the xenpci BAR as UC by default.
 - Introduce an option to not set it as UC.
---
 CHANGELOG.md                            |  3 ++
 docs/man/xl.cfg.5.pod.in                |  8 ++++
 docs/misc/xenstore-paths.pandoc         |  5 +++
 tools/firmware/hvmloader/config.h       |  2 +-
 tools/firmware/hvmloader/pci.c          | 52 ++++++++++++++++++++++++-
 tools/firmware/hvmloader/util.c         |  2 +-
 tools/include/libxl.h                   |  9 +++++
 tools/libs/light/libxl_create.c         |  1 +
 tools/libs/light/libxl_dom.c            |  9 +++++
 tools/libs/light/libxl_types.idl        |  1 +
 tools/xl/xl_parse.c                     |  2 +
 xen/include/public/hvm/hvm_xs_strings.h |  2 +
 12 files changed, 92 insertions(+), 4 deletions(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 1ee2f42e7405..5f31ca08fe3f 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -15,6 +15,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
  - On x86:
    - Restrict the cache flushing done as a result of guest physical memory map
      manipulations and memory type changes.
+   - Allow controlling the MTRR cache attribute of the Xen platform PCI device
+     BAR for HVM guests, to improve performance of guests using it to map the
+     grant table or foreign memory.
 
 ### Added
  - On x86:
diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index c388899306c2..e6a8e12c99e2 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -2351,6 +2351,14 @@ Windows L.
 Setting B with the default device_model "qemu-xen"
 requires at least QEMU 1.6.
 
+
+=item B
+
+B Select whether the memory BAR of the Xen platform PCI device
+should have uncacheable (UC) cache attribute set in MTRR.
+
+Default is B.
+
 =item B or B
 
 The groups of Microsoft Hyper-V (AKA viridian) compatible enlightenments
diff --git a/docs/misc/xenstore-paths.pandoc b/docs/misc/xenstore-paths.pandoc
index 01a340fafcbe..4994194e2bfb 100644
--- a/docs/misc/xenstore-paths.pandoc
+++ b/docs/misc/xenstore-paths.pandoc
@@ -234,6 +234,11 @@ These xenstore values are used to override some of the default string
 values in the SMBIOS table constructed in hvmloader. See the SMBIOS
 table specification at http://www.dmtf.org/standards/smbios/ 
 
+#### ~/hvmloader/pci/xen-platform-pci-bar-uc = ("1"|"0") [HVM,INTERNAL]
+
+Select whether the Xen platform PCI device MMIO BAR will have the uncacheable
+cache attribute set in the MTRRs by hvmloader.
+
 #### ~/bios-strings/oem-* = STRING [HVM,INTERNAL]
 
 1 to 99 OEM strings can be set in xenstore using values of the form
diff --git a/tools/firmware/hvmloader/config.h b/tools/firmware/hvmloader/config.h
index 6e1da137d779..c159db30eea9 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -58,7 +58,7 @@ extern uint32_t *cpu_to_apicid;
 #define ACPI_TIS_HDR_ADDRESS 0xFED40F00UL
 
 extern uint32_t pci_mem_start;
-extern const uint32_t pci_mem_end;
+extern uint32_t pci_mem_end;
 extern uint64_t pci_hi_mem_start, pci_hi_mem_end;
 
 extern bool acpi_enabled;
diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index cc67b18c0361..c41c8d946ac4 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -29,8 +29,10 @@
 #include 
 #include 
 
+#define PCI_VENDOR_ID_XEN       0x5853
+
 uint32_t pci_mem_start = HVM_BELOW_4G_MMIO_START;
-const uint32_t pci_mem_end = RESERVED_MEMBASE;
+uint32_t pci_mem_end = RESERVED_MEMBASE;
 uint64_t pci_hi_mem_start = 0, pci_hi_mem_end = 0;
 
 /*
@@ -116,6 +118,8 @@ void pci_setup(void)
      * experience the memory relocation bug described below.
      */
     bool allow_memory_relocate = 1;
+    /* Select the MTRR cache attribute of the xen platform pci device BAR. */
+    bool xenpci_bar_uc = true;
 
     BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_IO !=
                  PCI_COMMAND_IO);
@@ -130,6 +134,12 @@ void pci_setup(void)
     printf("Relocating guest memory for lowmem MMIO space %s\n",
            allow_memory_relocate?"enabled":"disabled");
 
+    s = xenstore_read(HVM_XS_XEN_PLATFORM_PCI_BAR_UC, NULL);
+    if ( s )
+        xenpci_bar_uc = strtoll(s, NULL, 0);
+    printf("Xen platform PCI device BAR MTRR cache attribute set to %s\n",
+           xenpci_bar_uc ? "UC" : "WB");
+
     s = xenstore_read("platform/mmio_hole_size", NULL);
     if ( s )
         mmio_hole_size = strtoll(s, NULL, 0);
@@ -271,6 +281,44 @@ void pci_setup(void)
             if ( bar_sz == 0 )
                 continue;
 
+            if ( !xenpci_bar_uc &&
+                 ((bar_data & PCI_BASE_ADDRESS_SPACE) ==
+                   PCI_BASE_ADDRESS_SPACE_MEMORY) &&
+                 vendor_id == PCI_VENDOR_ID_XEN &&
+                 (device_id == 0x0001 || device_id == 0x0002) )
+            {
+                if ( is_64bar )
+                {
+                     printf("xen platform pci dev %02x:%x unexpected MMIO 64bit BAR%u\n",
+                            devfn >> 3, devfn & 7, bar);
+                     goto skip_xenpci;
+                }
+
+                if ( bar_sz > pci_mem_end ||
+                     ((pci_mem_end - bar_sz) & ~(bar_sz - 1)) < pci_mem_start )
+                {
+                     printf("xen platform pci dev %02x:%x BAR%u size %llx overflows low PCI hole\n",
+                            devfn >> 3, devfn & 7, bar, bar_sz);
+                     goto skip_xenpci;
+                }
+
+                /* Put unconditionally at the end of the low PCI MMIO hole. */
+                pci_mem_end -= bar_sz;
+                pci_mem_end &= ~(bar_sz - 1);
+                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
+                bar_data |= pci_mem_end;
+                pci_writel(devfn, bar_reg, bar_data);
+                pci_devfn_decode_type[devfn] |= PCI_COMMAND_MEMORY;
+
+                /* Prefix BAR address with a 0 to match format used below. */
+                printf("pci dev %02x:%x bar %02x size "PRIllx": 0%08x\n",
+                       devfn >> 3, devfn & 7, bar_reg,
+                       PRIllx_arg(bar_sz), bar_data);
+
+                continue;
+            }
+ skip_xenpci:
+
             for ( i = 0; i < nr_bars; i++ )
                 if ( bars[i].bar_sz < bar_sz )
                     break;
@@ -310,7 +358,7 @@ void pci_setup(void)
         }
 
         /* Enable bus master for this function later */
-        pci_devfn_decode_type[devfn] = PCI_COMMAND_MASTER;
+        pci_devfn_decode_type[devfn] |= PCI_COMMAND_MASTER;
     }
 
     if ( mmio_hole_size )
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 79c0e6bd4ad2..31b4411db7b4 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -867,7 +867,7 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
         config->table_flags |= ACPI_HAS_HPET;
 
     config->pci_start = pci_mem_start;
-    config->pci_len = pci_mem_end - pci_mem_start;
+    config->pci_len = RESERVED_MEMBASE - pci_mem_start;
     if ( pci_hi_mem_end > pci_hi_mem_start )
     {
         config->pci_hi_start = pci_hi_mem_start;
diff --git a/tools/include/libxl.h b/tools/include/libxl.h
index b7ad7735ca4c..a0c4fcfe2a54 100644
--- a/tools/include/libxl.h
+++ b/tools/include/libxl.h
@@ -1503,6 +1503,15 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst, const libxl_mac *src);
  */
 #define LIBXL_HAVE_CREATEINFO_XEND_SUSPEND_EVTCHN_COMPAT
 
+/*
+ * LIBXL_HAVE_XEN_PLATFORM_PCI_BAR_UC
+ *
+ * libxl_domain_build_info contains a boolean 'u.hvm.xen_platform_pci_bar_uc'
+ * field to signal whether the XenPCI device BAR should have UC cache attribute
+ * set in MTRR.
+ */
+#define LIBXL_HAVE_XEN_PLATFORM_PCI_BAR_UC
+
 typedef char **libxl_string_list;
 void libxl_string_list_dispose(libxl_string_list *sl);
 int libxl_string_list_length(const libxl_string_list *sl);
diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_create.c
index 8bc768b5156c..433800ef6c19 100644
--- a/tools/libs/light/libxl_create.c
+++ b/tools/libs/light/libxl_create.c
@@ -313,6 +313,7 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
         libxl_defbool_setdefault(&b_info->u.hvm.usb,                false);
         libxl_defbool_setdefault(&b_info->u.hvm.vkb_device,         true);
         libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci,   true);
+        libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci_bar_uc, true);
         libxl_defbool_setdefault(&b_info->u.hvm.pirq,               false);
 
         libxl_defbool_setdefault(&b_info->u.hvm.spice.enable, false);
diff --git a/tools/libs/light/libxl_dom.c b/tools/libs/light/libxl_dom.c
index 4d67b0d28294..a61085ca3b5f 100644
--- a/tools/libs/light/libxl_dom.c
+++ b/tools/libs/light/libxl_dom.c
@@ -819,6 +819,15 @@ static int hvm_build_set_xs_values(libxl__gc *gc,
             goto err;
     }
 
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        path = GCSPRINTF("/local/domain/%d/" HVM_XS_XEN_PLATFORM_PCI_BAR_UC,
+                         domid);
+        ret = libxl__xs_printf(gc, XBT_NULL, path, "%d",
+            libxl_defbool_val(info->u.hvm.xen_platform_pci_bar_uc));
+        if (ret)
+            goto err;
+    }
+
     return 0;
 
 err:
diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl
index 198515383012..0a4a1f0eb747 100644
--- a/tools/libs/light/libxl_types.idl
+++ b/tools/libs/light/libxl_types.idl
@@ -691,6 +691,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
                                        ("vkb_device",       libxl_defbool),
                                        ("soundhw",          string),
                                        ("xen_platform_pci", libxl_defbool),
+                                       ("xen_platform_pci_bar_uc", libxl_defbool),
                                        ("usbdevice_list",   libxl_string_list),
                                        ("vendor_device",    libxl_vendor_device),
                                        # See libxl_ms_vm_genid_generate()
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index 219e924779ff..6d42a4e0f7cb 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -2917,6 +2917,8 @@ skip_usbdev:
         xlu_cfg_replace_string (config, "soundhw", &b_info->u.hvm.soundhw, 0);
         xlu_cfg_get_defbool(config, "xen_platform_pci",
                             &b_info->u.hvm.xen_platform_pci, 0);
+        xlu_cfg_get_defbool(config, "xen_platform_pci_bar_uc",
+                            &b_info->u.hvm.xen_platform_pci_bar_uc, 0);
 
         if(b_info->u.hvm.vnc.listen
            && b_info->u.hvm.vnc.display
diff --git a/xen/include/public/hvm/hvm_xs_strings.h b/xen/include/public/hvm/hvm_xs_strings.h
index e1ed078628a0..e977d5a8b186 100644
--- a/xen/include/public/hvm/hvm_xs_strings.h
+++ b/xen/include/public/hvm/hvm_xs_strings.h
@@ -14,6 +14,8 @@
 #define HVM_XS_BIOS                    "hvmloader/bios"
 #define HVM_XS_GENERATION_ID_ADDRESS   "hvmloader/generation-id-address"
 #define HVM_XS_ALLOW_MEMORY_RELOCATE   "hvmloader/allow-memory-relocate"
+/* Set Xen platform pci device BAR as UC in MTRR */
+#define HVM_XS_XEN_PLATFORM_PCI_BAR_UC "hvmloader/pci/xen-platform-pci-bar-uc"
 
 /* The following values allow additional ACPI tables to be added to the
  * virtual ACPI BIOS that hvmloader constructs. The values specify the guest
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 13:01:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 13:01:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014350.1392486 (Exim 4.92)
	(envelope-from )
	id 1uQ42F-0005Xr-Id; Fri, 13 Jun 2025 13:01:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014350.1392486; Fri, 13 Jun 2025 13:01:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uQ42F-0005Xk-Fx; Fri, 13 Jun 2025 13:01:31 +0000
Received: by outflank-mailman (input) for mailman id 1014350;
 Fri, 13 Jun 2025 13:01:30 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uQ42E-0005Xe-CJ
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 13:01:30 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uQ42C-00H7Y4-30;
 Fri, 13 Jun 2025 13:01:28 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (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 1uQ42C-004QEa-1N;
 Fri, 13 Jun 2025 13:01: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=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding:
	Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date;
	bh=TLxfTk0M/zl8+aqDSMrB64PaN0fMFCrbvtx3rVjxWOg=; b=sHcc4XCqjBFkfc3B0YPaK6s5DK
	lfdf4TOsy+Tp5vFq+8V/EsH0yyXDQ+eOMlVyLUrfX8asJR3nNL6813DR4k2xFDv8UteC6HjbG2Eoi
	5yQZMMPaFLjJHJpCKhKt9IV2xEYdj9dbyrXu4/LJby0kMod0P1YsC+axM5G/wNsT34Jc=;
Date: Fri, 13 Jun 2025 15:01:26 +0200
From: Anthony PERARD 
To: Roger Pau Monne 
Cc: xen-devel@lists.xenproject.org,
	Oleksii Kurochko ,
	Community Manager ,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini ,
	Juergen Gross ,
	Anthoine Bourgeois 
Subject: Re: [PATCH v5] x86/hvmloader: select xen platform pci MMIO BAR UC or
 WB MTRR cache attribute
Message-ID: 
References: <20250613110009.31245-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250613110009.31245-1-roger.pau@citrix.com>

On Fri, Jun 13, 2025 at 01:00:09PM +0200, Roger Pau Monne wrote:
> The Xen platform PCI device (vendor ID 0x5853) exposed to x86 HVM guests
> doesn't have the functionality of a traditional PCI device.  The exposed
> MMIO BAR is used by some guests (including Linux) as a safe place to map
> foreign memory, including the grant table itself.
> 
> Traditionally BARs from devices have the uncacheable (UC) cache attribute
> from the MTRR, to ensure correct functionality of such devices.  hvmloader
> mimics this behavior and sets the MTRR attributes of both the low and high
> PCI MMIO windows (where BARs of PCI devices reside) as UC in MTRR.
> 
> This however causes performance issues for users of the Xen platform PCI
> device BAR, as for the purposes of mapping remote memory there's no need to
> use the UC attribute.  On Intel systems this is worked around by using
> iPAT, that allows the hypervisor to force the effective cache attribute of
> a p2m entry regardless of the guest PAT value.  AMD however doesn't have an
> equivalent of iPAT, and guest PAT values are always considered.
> 
> Linux commit:
> 
> 41925b105e34 xen: replace xen_remap() with memremap()
> 
> Attempted to mitigate this by forcing mappings of the grant-table to use
> the write-back (WB) cache attribute.  However Linux memremap() takes MTRRs
> into account to calculate which PAT type to use, and seeing the MTRR cache
> attribute for the region being UC the PAT also ends up as UC, regardless of
> the caller having requested WB.
> 
> As a workaround to allow current Linux to map the grant-table as WB using
> memremap() introduce an xl.cfg option (xen_platform_pci_bar_uc=0) that can
> be used to select whether the Xen platform PCI device BAR will have the UC
> attribute in MTRR.  Such workaround in hvmloader should also be paired with
> a fix for Linux so it attempts to change the MTRR of the Xen platform PCI
> device BAR to WB by itself.
> 
> Overall, the long term solution would be to provide the guest with a safe
> range in the guest physical address space where mappings to foreign pages
> can be created.
> 
> Some vif throughput performance figures provided by Anthoine from a 8
> vCPUs, 4GB of RAM HVM guest(s) running on AMD hardware:
> 
> Without this patch:
> vm -> dom0: 1.1Gb/s
> vm -> vm:   5.0Gb/s
> 
> With the patch:
> vm -> dom0: 4.5Gb/s
> vm -> vm:   7.0Gb/s
> 
> Reported-by: Anthoine Bourgeois 
> Signed-off-by: Roger Pau Monn 
> Reviewed-by: Oleksii Kurochko
> Acked-by: Jan Beulich  # hvmloader
> ---
> Changes since v4:
>  - Rename to Xen platform PCI to avoid confusion.
>  - Set hvmloader BAR default to UC.
>  - Unconditionally write XS node in libxl.
>  - Introduce define for Xen PCI vendor ID.

Reviewed-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Fri Jun 13 13:12:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 13:12:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014358.1392496 (Exim 4.92)
	(envelope-from )
	id 1uQ4D8-0007as-GU; Fri, 13 Jun 2025 13:12:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014358.1392496; Fri, 13 Jun 2025 13:12: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 1uQ4D8-0007al-Dv; Fri, 13 Jun 2025 13:12:46 +0000
Received: by outflank-mailman (input) for mailman id 1014358;
 Fri, 13 Jun 2025 13:12: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 1uQ4D7-0007af-FP
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 13:12:45 +0000
Received: from fhigh-b4-smtp.messagingengine.com
 (fhigh-b4-smtp.messagingengine.com [202.12.124.155])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 166b2a86-4858-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 15:12:43 +0200 (CEST)
Received: from phl-compute-10.internal (phl-compute-10.phl.internal
 [10.202.2.50])
 by mailfhigh.stl.internal (Postfix) with ESMTP id 15808254012F;
 Fri, 13 Jun 2025 09:12:41 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-10.internal (MEProxy); Fri, 13 Jun 2025 09:12:41 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
 13 Jun 2025 09:12:36 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 166b2a86-4858-11f0-b894-0df219b8e170
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=1749820360;
	 x=1749906760; bh=nic4krrDQvZMHzuHBfuhHul7sbLqjo8sqiELgpkyWwQ=; b=
	S/4TdprqVZEItFqsnfTKR32/snSDHdi4ZQgY4USZuK6lZ2kW6Rv0ch2t8Z/eAi4K
	P61Ks2JHQax3edyNJR24ENBkjShcqJbwhFBNldbzIrT1DyvFHoxXqX3PrfEo77Fx
	M55aFiuJeu42uGHxQedr378IM9Pi8QOh4MpnE+dt41vMduoqV5XkvDH432eNE60z
	rW4CBnQVjBHxhOebby17xELnWiCcyhj6Vpf6Id3+YPyMpJhGR74OtULwozjrDK7d
	a+FMxQed62Jlg6d0xOIVHQXR6BxEmbyvAkB7lmpZ9p4yZsXiSElIa8V2HjKg5ZQG
	yv21PMWwsx7VP36jU9KeBg==
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=
	1749820360; x=1749906760; bh=nic4krrDQvZMHzuHBfuhHul7sbLqjo8sqiE
	LgpkyWwQ=; b=Lv92+xNRcAFrIQP772pfzygmhR5arCHa6mgCzL6XzHrhOUxTYqy
	lxzHtNNdCugYJxlNhAufT0AzGeKmxVlAzu+SIemcgB6qVlQWOV+g0Wbz+Tj9liMA
	aGCuuc62PNT0/SdZyQPc9ynwgSvraiOjy/S7rjp6xExle8WskXUFU6v3k+6ALcYb
	uqtnSdYE+9qznsNy55AQy01J1hrkn774+SwoxWR+wB8I2+nD0SJEnMzinT1zIQ0k
	l0CYe7SKL4zNHoaVO+km35+ZBjvm3QT0K6SH+cdBvMVmFKG0RG35Q895jC8sUPXn
	E/aP4Y9nC5NXC0JoC0LmodkqlsArDJ+p7gQ==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugddukedtgecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp
    uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg
    hnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehgtderredttdej
    necuhfhrohhmpeforghrvghkucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoe
    hmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucgg
    tffrrghtthgvrhhnpefgudelteefvefhfeehieetleeihfejhfeludevteetkeevtedtvd
    egueetfeejudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr
    ohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpd
    hnsggprhgtphhtthhopedugedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepjhgs
    vghulhhitghhsehsuhhsvgdrtghomhdprhgtphhtthhopehsshhtrggsvghllhhinhhise
    hkvghrnhgvlhdrohhrghdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdig
    vghnphhrohhjvggtthdrohhrghdprhgtphhtthhopegrnhhthhhonhihrdhpvghrrghrug
    esvhgrthgvshdrthgvtghhpdhrtghpthhtohepmhhitghhrghlrdhorhiivghlsegrmhgu
    rdgtohhmpdhrtghpthhtohepjhhulhhivghnseigvghnrdhorhhgpdhrtghpthhtoheprh
    hoghgvrhdrphgruhestghithhrihigrdgtohhmpdhrtghpthhtohepjhhgrhhoshhssehs
    uhhsvgdrtghomhdprhgtphhtthhopehhuhgushhonhesthhrmhhmrdhnvght
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Fri, 13 Jun 2025 15:12:34 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Jan Beulich 
Cc: Stefano Stabellini ,
	Xen-devel ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Juergen Gross , Trammell Hudson ,
	Ross Lagerwall ,
	Frediano Ziglio ,
	Gerald Elder-Vass ,
	Kevin Lampis ,
	Andrew Cooper 
Subject: Re: [PATCH] docs: UEFI Secure Boot security policy
Message-ID: 
References: <20250611235851.167385-1-andrew.cooper3@citrix.com>
 
 <608cf9c5-f057-4d3b-8833-8ef040064fec@suse.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="YamY06O8Z+wvFSTe"
Content-Disposition: inline
In-Reply-To: <608cf9c5-f057-4d3b-8833-8ef040064fec@suse.com>


--YamY06O8Z+wvFSTe
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Fri, 13 Jun 2025 15:12:34 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Jan Beulich 
Cc: Stefano Stabellini ,
	Xen-devel ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Juergen Gross , Trammell Hudson ,
	Ross Lagerwall ,
	Frediano Ziglio ,
	Gerald Elder-Vass ,
	Kevin Lampis ,
	Andrew Cooper 
Subject: Re: [PATCH] docs: UEFI Secure Boot security policy

On Fri, Jun 13, 2025 at 08:35:26AM +0200, Jan Beulich wrote:
> On 12.06.2025 23:32, Stefano Stabellini wrote:
> > On Thu, 12 Jun 2025, Andrew Cooper wrote:
> >> +Support in Xen
> >> +--------------
> >> +
> >> +There are multiple ways to achieve this security goal, with differing
> >> +tradeoffs for the eventual system.
> >> +
> >> +On one end of the spectrum is the Unified Kernel Image.  e.g. Xen is =
bundled
> >> +with the dom0 kernel and init-ramdisk, with an embedded command line,=
 and with
> >> +livepatching and kexec compiled out, and suitably signed.  The signat=
ure is
> >> +checked by the bootloader and, as this covers all the privileged code=
, Xen
> >> +doesn't need to perform further checks itself.
> >> +
> >> +On the other end of the spectrum is maintaining the features of exist=
ing
> >> +deployments.  e.g. Xen needs signature checking capabilities for the =
dom0
> >> +kernel, livepatches and kexec kernels, and needs to allow the use of =
safe
> >> +command line options while disallowing unsafe ones.
> >=20
> > I just wanted to mention that there is one more option which I used in
> > the past: the firmware/bootloader loads Xen, the Dom0 kernel, and other
> > binaries, check their signatures, then boot Xen.
> >=20
> > This is similar to the "Unified Kernel Image" approach in the sense that
> > Xen doesn't need to do any signature checking for the dom0 kernel, but
> > it doesn't require all the binaries to be glued together.
> >=20
> > Assuming that the firmware/bootloader is capable of loading multiple
> > binaries and checking the signature of multiple binaries before booting
> > the next element, it works fine.
>=20
> How would an initrd, a ucode blob, or an XSM policy blob be signed?

At least grub supports gpg detached signatures, and can be configured to
require them.

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

--YamY06O8Z+wvFSTe
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmhMI8IACgkQ24/THMrX
1yzNUgf/UtRiHQdPBgWLUK/YlLpFwtsxPmtrYwRNu4/ucSVQmJr+dW+1KO/fnNo4
b0jk3qY2UJl7yrUdqwq+/sHxU6p7TO1URrRjLLmoiUbqK3ERV5y/XGdq9Qt2COOw
7OqjyTgqn6j2ukdc2iFCMxvFeekOkNV3TODpe4mFczE5RVG7RNw9sJY9DfmdfgPS
uEBVZJJoieQZ8VZ74EoVKqyGbA7+NqCIErtWqXnkhMeXeSx5dHJ9tq2AVPRdE58G
/E1Whw7l91QACp66b2NtdUQsiEID6/zje0UR5NWxtou64CHCJ65xuEW/NFtqFapw
xRgrrvMxbJTB+gQKVw2RmAQs3cS4dg==
=rkTk
-----END PGP SIGNATURE-----

--YamY06O8Z+wvFSTe--


From xen-devel-bounces@lists.xenproject.org Fri Jun 13 14:37:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 14:37:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014407.1392507 (Exim 4.92)
	(envelope-from )
	id 1uQ5We-0002Pz-8t; Fri, 13 Jun 2025 14:37:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014407.1392507; Fri, 13 Jun 2025 14:37: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 1uQ5We-0002Ps-5r; Fri, 13 Jun 2025 14:37:00 +0000
Received: by outflank-mailman (input) for mailman id 1014407;
 Fri, 13 Jun 2025 14:36: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 1uQ5Wc-0002Pm-0e
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 14:36:58 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20609.outbound.protection.outlook.com
 [2a01:111:f403:2412::609])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d938f2ba-4863-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 16:36:55 +0200 (CEST)
Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
 by DM6PR12MB4401.namprd12.prod.outlook.com (2603:10b6:5:2a9::15) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.38; Fri, 13 Jun
 2025 14:36:49 +0000
Received: from PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264]) by PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264%2]) with mapi id 15.20.8835.018; Fri, 13 Jun 2025
 14:36: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: d938f2ba-4863-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=GsuT/tOSWZR13eC0M8vuptMINBmy9u7jo0tOI93unVkixs9zov03XWL0/FG1DFhiVRqi0fgVDl4L/JIS+7vQZW8MvcAVjIyUmAZQGUHLOKQbuOoFjwwhepdKX3O+hwWBkL9oMxuX9UEvyZMn6E3C8bAZpO/VfLVA3F9VrY2gBwxLe7VHxTDiKyESBLw0Kdy+3Dd4U5hblrVlUK5z5JjYqyW1ryHLv3vYFeQ6nYAudxatIu1u6wAcTzMx/+1xnNy4oQ88ZIclz++uo0F6bB147l05feD2y9Jn5qNXv551hqmCMhxeC/dVUvyBSzn7wdpHunK8FsLuWO9vGFSZ0F7bgA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=5Bhfezr/npPdf/3ciPsOvpWHjiqsuZEZHbRLK1j6hSw=;
 b=aGGgocjXmp/t8LM9puwiCpvMyQeQ88XU3CM/PtTWHPl/EQ3PkrNFUXUucbvvMNBfBpQDjEdCUMXFWPMQReYATQt08bQOwQHuqVWYFJJTTNqbK12C4u1LWRUdsU8SnTt7P/8jHhb8E+lVQFrbsjTT9za9zqWCQRXGPiSGsUDYEi7CRCdlEGI/7FKOCW38agRhewestlyAT7gmqxGllQPIZw3AIAyODfOf5pbsL2YPNgbKroq/y3M8d46ds8waHZRFv1a2AuZ+/BjSqacXheNn8cSh3qqJ9avEVWEpRIRq8qXMvBlfbaQdFKdZGYpiMwWPb+nRKsmKtyS8a3eHM6rgKA==
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=5Bhfezr/npPdf/3ciPsOvpWHjiqsuZEZHbRLK1j6hSw=;
 b=jEub1mQ1RTcwzz3qRCb4Xlptp89gb20xJ/eUab+D+LKDfFalrFmGSrMlYJyrB0iotDb6HQtxfagHVBuIqh9iZFc5ozS63WfGMYaju2dNFEFtACrc3cnknfptAbgM3mdXLwdPiozO4yQa88il0RoEbR5t2piMdus2T8L5lGtAKAM=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <4403d50b-3380-4f94-8c14-f0eb2884b50d@amd.com>
Date: Fri, 13 Jun 2025 15:36:44 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/2] xen/char: implement suspend/resume calls for SCIF
 driver
Content-Language: en-GB
To: Mykola Kvach , xen-devel@lists.xenproject.org
Cc: Volodymyr Babchuk ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Oleksandr Andrushchenko ,
 Mykola Kvach 
References: 
 <3be3369910ec5159eab3cb26155da645dd1df83b.1749204282.git.mykola_kvach@epam.com>
From: Ayan Kumar Halder 
In-Reply-To: <3be3369910ec5159eab3cb26155da645dd1df83b.1749204282.git.mykola_kvach@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LO3P123CA0025.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:388::14) To PH8PR12MB7326.namprd12.prod.outlook.com
 (2603:10b6:510:216::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|DM6PR12MB4401:EE_
X-MS-Office365-Filtering-Correlation-Id: a6a7615d-c38e-4e64-f940-08ddaa87bacd
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?ckJmOEpkTHJxdE4wQ1NtTVF5LyttMjNOZ1dqNmdPMldzL25yazRKSnlmMzNk?=
 =?utf-8?B?OENIckVWS05ROUpIOTQzc1M5RUJtMnBzVnJYZUloRHFZamlGNUg5clkvYWZ2?=
 =?utf-8?B?aERLYlYveC9QT1Y5SS9PZkVmQ3F4MkR0RklpSElIaW5FV1ZEYStWb3VFaWZl?=
 =?utf-8?B?RG9MRXpoMmJuZlgxYkFEOVU2bGFvQ1hmVUZsNlhvUmhQcmtoNHo2U29iNkY0?=
 =?utf-8?B?ZncyaDR5aExCV1h2Q1JoRW5tQ1YyMlh6NnVjV1dDZ2ZDRnJBRFg0MFNHT1lO?=
 =?utf-8?B?MVRlUG9jK0E1ZGU0V251OXpxazhsMEVpVWZTcWs3NXFTalg1QmdtSVV3Q3lt?=
 =?utf-8?B?dUxDT3YvdWk3QU5HWWwyRzRzdmpzd0h1WU9wcjdJOGFRamp4M3V5anlNSWx6?=
 =?utf-8?B?RUI0TTN4a0QyNHBaRjZIRE9VaUdiZlVsWDFreER1UC9rcng4b3JIZXdvMkJK?=
 =?utf-8?B?ckNGSGtqSlB0WmlYVFhKUGFxbXdDM2dLWkluRDBQMVNGOVRXbmlJQ3d6dGU3?=
 =?utf-8?B?Y1k2WTdKZS81eEpucDdVQ3IzNktBM0VwS1cvWUI1aWIrR0lRa3VPbC9jRXVp?=
 =?utf-8?B?WGxlbXZhbGtoN1I3ang1MUlyWlc5dHMwUkg2V29JQXFnWUV6UzFXNXF5SEJO?=
 =?utf-8?B?cG9UaTdPbTBFcG9BUUlGU1pSZm1GN0lYZkhKYWpndzZMWVRVclJ0L1QxTnZ0?=
 =?utf-8?B?K0lyVm5MNzFVRHhSc2M2b2xucHNxQkVRUEZWQjJlSkVNM0dObW1xNnN1K3BP?=
 =?utf-8?B?bkV5M0szYndjWWFLN1Q2ZXp2WSt6YWVFWnVITDlXRHFJcW9qMXVRemsxUlBM?=
 =?utf-8?B?UmNJb3JYYTJWcmlTVllhUlIzMUZHTEY3Ylhxd1JYK2pYdFhMSjk4ckNsVitP?=
 =?utf-8?B?bVZtSUNaa2xPazk4Z3FPbkIxMHRtNTBHdVdXT3dObFBlQkQ1SWxZU0xFZFRo?=
 =?utf-8?B?eko0M0RYVWVDNHJIYWMzSldjM1B0MzIxR2NWbTQ2RTBJemhwRHBXUmFyU0Fs?=
 =?utf-8?B?a3hoMDgyTEQxMGtlQXRsNjRuSzdOaHJVWWVBdU02NnhndXhoQ3pEd2RLakx4?=
 =?utf-8?B?a1Foam5rQmNneVYxeEh2KzBpWTdFUWdwMzB1ZElsS3ljNzBWRHVGdG56bWZl?=
 =?utf-8?B?aE5LZ3lnSXFNVXVmNzhwSGEyR0UrcjF5N0M5T0NCa2dWN1VYSm5DWnpXeGtV?=
 =?utf-8?B?OWl2YXRpQXRTeUdkOUlNd1RVTUFYOEROUmhyc2lDNzladHRsdGc2NWhMODU0?=
 =?utf-8?B?a0lpYmUzR2NheW8zMkhTRVVxNDBqNnZyamRLaWFUYnI0bG1JYk16ZCtuc3Na?=
 =?utf-8?B?TnU4a295dXJNS293ZlV4Y3hpOXlvVTFVYllqVmg0UWlRSnlURjZIK3NaYnhi?=
 =?utf-8?B?VDdLMm04TWdWMHRNQnVaODUzdmZDZzQ5cWFSWUFIWElJVTBhRnMvNWVoSll6?=
 =?utf-8?B?c1NBeExpM2dWMTJBK1BwL0Zvekczb1ViSlZDZ0RCYzFoMzFqL1FQOVBuNzRF?=
 =?utf-8?B?cFArcUlSUHQvRURhMlhaUnoxTnFOVlF3RERiTHRHUjVQUXhzZjRMWTdIRTIv?=
 =?utf-8?B?YlVDRzAyVkpJcVZhOElhS3VsZDgxdnFvUkRVZUJ3V3VUOWJPNDE5b25Ga3pk?=
 =?utf-8?B?TGpQa2lETGdtV1l3d2p2K3E5Q1JrVDJqUVhOQkdFWHcyTnVtRnU5bWZVdG0y?=
 =?utf-8?B?Mi9YWWlzMkp6dUlqT3UxM2ZBanZyMmRvUy9aWGxpV1Vxei94SUFoaW5UTFI5?=
 =?utf-8?B?WXpRWXNTTXEzOEliR1J1MHJXNlNsdlR1aWxoY1locmkvYld4MUJtSlQvQ2RC?=
 =?utf-8?B?eHNhVTJOUlYzL2l0N1JGdklmb2p2Ny9CZWpGeVl5WXF4TlRsZkM2MkdySXc5?=
 =?utf-8?B?NmlmcVNYMDI3V2hLK1FXMjlxTi81UDk4UTFuOTVQRjh2eXY3S0R1K0NkcVlt?=
 =?utf-8?Q?WezHpnfBYNU=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?NktuU0c2UUxQaktDOTFSRXB2VC9ZcDd0ajV4MGUvRmhwRFNvbjNWcVh6TXFS?=
 =?utf-8?B?OWs0Z0ZRVjlNWVo4Yk1QK0Nnamg0N0UzbEZUS3NSNGM1ZTBGWjBROWlxMkd1?=
 =?utf-8?B?N2pMUGVMa0xZMHlLS000YlgzUW13dFJ5SFdQTUp3azZYclpFU2ZlNTRnVlcv?=
 =?utf-8?B?eVhoeXZhNC9mcWdsdHdFUks4YlpVRW40THZUcU1wRWVPcnVSRUV5U3NGNFRv?=
 =?utf-8?B?cFdXOWRwK05rbjRCR00rRHV2WHpqdzJYRm55NG0xbjlVYnNvVUZ0aHkyRmRv?=
 =?utf-8?B?TzA1MzNpTlF3Ni9kV3dzNk4xMXp1d1NRTHd0aWtPZExld0FuMzMzWm9RdGlM?=
 =?utf-8?B?WFJmZzNkcGo4bGZKSHBQOFB4NXdydklDMkwxVHZVRSt5dzU2OER0VFh5MFkz?=
 =?utf-8?B?SGt5UTlydjM3ZmlSNW01cC9hdmtCVmZxU2tXWUYra2dQOHlOcFhGSlg4dlRR?=
 =?utf-8?B?S3BPUFZBc3FadHdwUWt3Z0NCSXp5bjVXTE5GMTBWUFR5WVkxOHA1a2pTTnNq?=
 =?utf-8?B?d2JTSDFadVFQS28yTkxHUEp4WEFwVkUrMk5QM1hCSzR1K0ZqYTJHQzNOaGUw?=
 =?utf-8?B?THhWbFRRbzc4TVNaU3d0YnV1UUxlYkpvREhpNkhWN2x4Y1dIczd4bWdQbVg0?=
 =?utf-8?B?NCs1T29ybjdLcHBDdlNzVEpiV2MwR095SGtFdWw0WlVEcXhpc2dzQmVTNnhq?=
 =?utf-8?B?ZGZEZmxqZlUyL0plRkgwSkljWms1Q2gxMWIxZk9BRm1LZlJ0bk1vNzJlTFZ1?=
 =?utf-8?B?VzE3SWFnbWM0QVFKOGREaDRTMXdJWE1iOUNTNTBnQVg1OUNQYkZVWkJLcFR0?=
 =?utf-8?B?MUk2d2UyRUErU2pEZUV6d1pyTnZlc2NBOFBVSjB5QVBBbFB2YVBNVDgrR1hJ?=
 =?utf-8?B?RE5mMElHRS84bDNsb2JGR1dCVm9oZWprbGNwUjRrcFJYYWplNVpPQUF3N2tD?=
 =?utf-8?B?NG4xM2k1SjBOaXVpVERnT2FwdTd1Sk96MFpjd2lGNFhVT3ZwOEUvbFJsd0tR?=
 =?utf-8?B?ZFBVaUg4Ri9XRDRPbXBWdnQ5b2NtMDlUc2RRT0R3QWlMb2V6QVZBcmlQQ2to?=
 =?utf-8?B?dC9ZV2ljNXV0TkE2czhQcVVSOFlhK3BLOWhFdlpuYmswNEZsK3RxTll3VGJr?=
 =?utf-8?B?WDU3blQ4QTV4c0ZzaFdTdFV6YmU5aEJ6cWNOdkcwZVJibFJjQWllbE9KSHlW?=
 =?utf-8?B?RnZEa0RMTkIraGFVV1hZOTFOMnZRQWRhMmNvQ2dmaW9wQk05Z2RTUjZoVm95?=
 =?utf-8?B?bitxVHhBMktoNWN5bWI3TmlyYTlJaXNQQ3loOUVva2RsYjZQY0xxbEtLYjkv?=
 =?utf-8?B?MHluRGVIN3pYUmNXNTJPUkpRZkJoTmpRTUsreWJ6SGlVZmVoWFQwSUFlWjNM?=
 =?utf-8?B?Q0c4eTVibFI5K2JLYUNjbTdVdVpocytMSHpNZ0N0azdkc3Rzd29NTXEwL1RC?=
 =?utf-8?B?OC8xRFRJc3lkaXVOakVKSGFlaHNZbHhWTmZHbkdacWdVdE96c1V3OWxhYk9M?=
 =?utf-8?B?eG1PeFpFVitGYmZqZnY5TGNPeENMMHBneE9nN25TRGVXdWYzYy9lTCtyenh5?=
 =?utf-8?B?Y25pVFBZWHBhdUNpL0w2bDJZVllEa0pVMEI2blhUUTJHVkpRbmswR2h2Y2Fz?=
 =?utf-8?B?Y1A5MXJxT2pFMHVURWFuMUZvWVFLWlVVc2pqSmtxSkxBNmlZVytoSUJsMWgx?=
 =?utf-8?B?RjFTaHZaT0FyVzBxY0lHWkV2WGMyMXJLS1ZlTEc5dUdXL1RBY2I5WUExcHVn?=
 =?utf-8?B?TXNSN3R1bnJZYkEwZkt2RGplWEtja1o2UGxFYnNGL2Y5K042b05TcWlYVVZE?=
 =?utf-8?B?NWlPVHNPMElmeUpxS3k3Q1lpTW5XVG1UWHpIcWVFSmduRTVxblUxeWhFR25v?=
 =?utf-8?B?ZDFPSm5YNFBUMHFWSHNsZHA1aXVTcUxoWUxuMXdXcDJJcG9uTURXMjdsaFNw?=
 =?utf-8?B?OUJsQWZaUkpnWVpveDM0L3NXTTI5NEM2MjI2UGsrWUZ1ZzJKNkZxeklDN0RQ?=
 =?utf-8?B?aFo3NlR5UXMvb0oraHJDYlBpQURYOFdXTEhhcE9GMmMvU0ZyV2gvYUxKT21U?=
 =?utf-8?B?U0hkRnl2V3FydGY0UVoyYXdZR1NXWXpJaHh4SktzZisyYzNLNzQ0L0V0T3Fz?=
 =?utf-8?Q?ki6wDYl9MJYOQfU/ua3O/IBaP?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a6a7615d-c38e-4e64-f940-08ddaa87bacd
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jun 2025 14:36:49.1373
 (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: JxCtjTo7WWeCkxlJD3qgbTMngCUBiEF7m//FefpbBZhCY/N8XOfGS2v85Dti5bJMq+GITGlaJjk2ZE3AW8H3kg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4401

Hi Mykola,

On 06/06/2025 11:11, Mykola Kvach wrote:
> CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email.
>
>
> From: Volodymyr Babchuk 
>
> The changes have been tested only on the Renesas R-Car H3 Starter Kit board.

The commit message need to explain what the change is and why it is needed.

Also ...

>
> Signed-off-by: Volodymyr Babchuk 
> Signed-off-by: Oleksandr Andrushchenko 
> Signed-off-by: Mykola Kvach 
> ---
> In patch v2, I just added a CONFIG_SYSTEM_SUSPEND check around
> the suspend/resume functions in the SCIF driver.
> ---
>   xen/drivers/char/scif-uart.c | 40 ++++++++++++++++++++++++++++++++++--
>   1 file changed, 38 insertions(+), 2 deletions(-)
>
> diff --git a/xen/drivers/char/scif-uart.c b/xen/drivers/char/scif-uart.c
> index 757793ca45..888821a3b8 100644
> --- a/xen/drivers/char/scif-uart.c
> +++ b/xen/drivers/char/scif-uart.c
> @@ -139,9 +139,8 @@ static void scif_uart_interrupt(int irq, void *data)
>       }
>   }
>
> -static void __init scif_uart_init_preirq(struct serial_port *port)
> +static void scif_uart_disable(struct scif_uart *uart)
>   {
> -    struct scif_uart *uart = port->uart;
>       const struct port_params *params = uart->params;
>
>       /*
> @@ -155,6 +154,14 @@ static void __init scif_uart_init_preirq(struct serial_port *port)
>
>       /* Reset TX/RX FIFOs */
>       scif_writew(uart, SCIF_SCFCR, SCFCR_RFRST | SCFCR_TFRST);
> +}
> +
> +static void scif_uart_init_preirq(struct serial_port *port)
> +{
> +    struct scif_uart *uart = port->uart;
> +    const struct port_params *params = uart->params;
> +
> +    scif_uart_disable(uart);
>
>       /* Clear all errors and flags */
>       scif_readw(uart, params->status_reg);
> @@ -271,6 +278,31 @@ static void scif_uart_stop_tx(struct serial_port *port)
>       scif_writew(uart, SCIF_SCSCR, scif_readw(uart, SCIF_SCSCR) & ~SCSCR_TIE);
>   }
>
> +#ifdef CONFIG_SYSTEM_SUSPEND
> +
> +static void scif_uart_suspend(struct serial_port *port)
> +{
> +    struct scif_uart *uart = port->uart;
> +
> +    scif_uart_stop_tx(port);
> +    scif_uart_disable(uart);
> +}
> +
> +static void scif_uart_resume(struct serial_port *port)
> +{
> +    struct scif_uart *uart = port->uart;
> +    const struct port_params *params = uart->params;
> +    uint16_t ctrl;
> +
> +    scif_uart_init_preirq(port);
> +
> +    /* Enable TX/RX and Error Interrupts  */
> +    ctrl = scif_readw(uart, SCIF_SCSCR);
> +    scif_writew(uart, SCIF_SCSCR, ctrl | params->irq_flags);

If you can give reference to a public doc which describe these 
registers, it will be great.

Otherwise, the changes look ok to me.

> +}
> +
> +#endif /* CONFIG_SYSTEM_SUSPEND */
> +
>   static struct uart_driver __read_mostly scif_uart_driver = {
>       .init_preirq  = scif_uart_init_preirq,
>       .init_postirq = scif_uart_init_postirq,
> @@ -281,6 +313,10 @@ static struct uart_driver __read_mostly scif_uart_driver = {
>       .start_tx     = scif_uart_start_tx,
>       .stop_tx      = scif_uart_stop_tx,
>       .vuart_info   = scif_vuart_info,
> +#ifdef CONFIG_SYSTEM_SUSPEND
> +    .suspend      = scif_uart_suspend,
> +    .resume       = scif_uart_resume,
> +#endif
>   };
>
>   static const struct dt_device_match scif_uart_dt_match[] __initconst =
- Ayan
> --
> 2.48.1
>
>


From xen-devel-bounces@lists.xenproject.org Fri Jun 13 14:44:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 14:44:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014413.1392517 (Exim 4.92)
	(envelope-from )
	id 1uQ5dY-00043X-0O; Fri, 13 Jun 2025 14:44:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014413.1392517; Fri, 13 Jun 2025 14: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 1uQ5dX-00043Q-Ss; Fri, 13 Jun 2025 14:44:07 +0000
Received: by outflank-mailman (input) for mailman id 1014413;
 Fri, 13 Jun 2025 14: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 1uQ5dW-00043K-Mt
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 14:44:06 +0000
Received: from NAM02-SN1-obe.outbound.protection.outlook.com
 (mail-sn1nam02on20601.outbound.protection.outlook.com
 [2a01:111:f403:2406::601])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d8bb9f06-4864-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 16:44:03 +0200 (CEST)
Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
 by SJ2PR12MB9240.namprd12.prod.outlook.com (2603:10b6:a03:563::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.18; Fri, 13 Jun
 2025 14:43:55 +0000
Received: from PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264]) by PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264%2]) with mapi id 15.20.8835.018; Fri, 13 Jun 2025
 14:43: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: d8bb9f06-4864-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=hXDtSQI9ENfs63oi4CbjfUXkFASO7DJLbtk5TxFDUmZHbasGxfUvTj6qlj0G8bbSglyPMaFmaY10NzYxuUitRf8S9IAJ/IKlPpon/06KkmkVvpb+czllzNj5lnDmpNmGxlVXSJyQbHdDgbcx2JbFHbEWr78ndb1M7aSPMpllKb3WuPeEf0whxTcs50XdlpFneJ8Uzur5XmSbl7x9oEGxMtyYTnGUU58lqnYDCAk32VVtv81khhWc5jv6mhlSQSbTF/6MWEuAP0EC8zuORKtC0HsHzBwEMYpSFnquC2u38p/L7ERvRWaR5xqb0uWsKfISIciU0DOtQjbjCo4J5DWVgw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=vbJRgRNf05snyNeQ/jstq+iPYf5XCECNRfAnFmDvOuA=;
 b=YIuKXoXu0m2rhXA8vvPSWxGCzFM+S3yWToDtTcG0M9wnhQGkKHrn2BzBgLyy14MGYQKGmFKHYLvxeg7QyplqPYt0VIwctvAW7hcb0Hp+nXRW/PYc/ZpmbaE28z+0cbTzQSINDVH+YGnhFzuICdxXuZ+Cu7QgYJbZqp67y4PAqR63SW1nRNJg1aNC2EcfMySoBmjHzWNqSdc0We9OLH3Vy+y763VhSzzTjbjbDfGrFKQGbzDUhp9XO/+8HTjqoxqj/iHOk/TRL3DKugjdnDhRR6fSMxIcCLaVtznla14tWX8zygOltt8E03UOsroZZwDoze1DhU1iTx6kHpOFYlfx6w==
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=vbJRgRNf05snyNeQ/jstq+iPYf5XCECNRfAnFmDvOuA=;
 b=wEDeUtfKvPsgZ1fY7gxn5ZRWszmk+V/W2nu6FNH+Yn/6lYxh6KVx8yrRerBc2MTeu0W4LDHGGfEZHBZ+vZwfxCCjC9gTdepPqv3gp1FS3F2cgyPZj0AfvUyfjwoZ5KGR0e20dX9b92x7TZm+hDf4MQkQy+/Do/JQPgaUh/J9lKc=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Fri, 13 Jun 2025 15:43:50 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4][PART 2 02/10] xen/arm: Add suspend and resume timer
 helpers
Content-Language: en-GB
To: Mykola Kvach , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: 
 
From: Ayan Kumar Halder 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: AM0PR02CA0023.eurprd02.prod.outlook.com
 (2603:10a6:208:3e::36) To PH8PR12MB7326.namprd12.prod.outlook.com
 (2603:10b6:510:216::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|SJ2PR12MB9240:EE_
X-MS-Office365-Filtering-Correlation-Id: 98db99d5-3186-4bd1-1a3a-08ddaa88b8f3
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?bk5FN0xvZmFvMDc5OUVtQUdWZVYvZi9HRWx6VVdWVjRoN0g5TWZCcHBWd1BI?=
 =?utf-8?B?UFZwTlF4Y1IxS25ZZWNic2U0U082dzB6NGJySFFxRG1vWjhwOWtPVy9VeTlW?=
 =?utf-8?B?T09oYm9kM1NIazlsd01WbGF5Tzhod1BsdW11TzFNeHJiT2FKNzVnV1FFcXgz?=
 =?utf-8?B?Nk9OczAwakxOU1lCUU5JTWtCM3ZlRS9WWlJOcjhleFlSMzhIcmNMT0pla1No?=
 =?utf-8?B?TUpscjV0VExWc1IyejdYYkpJQlI1cVNYMUk3WU1pc003ZTZBSENjNjVRa05H?=
 =?utf-8?B?MHZkcDBYLzNERnkyL01EOU5yOG5nVk1xc1ppNEs1SnVDRXN6UGJjWVdzZW5m?=
 =?utf-8?B?SU0zMDQ5UU5BMm9uRC9iU2dvL3VXNTYyRkNRcTNQdjgyRjh5NE9RYjVPMUhL?=
 =?utf-8?B?eUNvRE5YeGpqdFdTU3cwKzFYZklNR1o5bTRkeXdzcHJXVVd4bGlLbzhTcW5P?=
 =?utf-8?B?dmlzVytVTDVic0ZIRWpDZkJITCtQMWxmdDJ6eDdnM2hjQ1FCM0FUaFRVMGFW?=
 =?utf-8?B?a0wwMXVQd2Exak50bFlzVnhEKzNDMnEwY3IyRWdXSTJHUmQ2eWg3bUczOWFP?=
 =?utf-8?B?OHRGdHQ0elZvWVo1ZGNsVENobG1yRzE1TDkrMUU2OWFMelcrMXNjbnY3Zjcr?=
 =?utf-8?B?MVZSbGdnRnVtOFNGOEt4UTV2Z3pORnJrYzZ3allOODdzNjBaM1B6aUFzUkt0?=
 =?utf-8?B?RHBEYUdWMTVsaFZKVGNSb2dyVFgwRGJyU1RlbmZFYWNWV2owanJXZGowclZF?=
 =?utf-8?B?d2V5blZ5QW41bTZiM21xSTN0Q2psU3RCOFhNd0hzTFZVTXNicHg4U2U0QzVt?=
 =?utf-8?B?dDduNFhBSC9JU09hL0NZSlVMTDFDclN0UXFMQ0NGUjZZOFVHZ1VvUC9ncEVM?=
 =?utf-8?B?T1RnU3dIMjRjVWozN0Y3cFNtTkYxdndrb1ZDa0k3N0lxWHVjVm1OZHZBSHJB?=
 =?utf-8?B?aklRK016V2RrUXVwTVAxZU5SdkhTdE11VUlpS0ZIazFqVXhZNHdmMUtGNE5h?=
 =?utf-8?B?YlhHQXZEa1N2V2JZM2J0OHBCT0lDbEhseS8xZTIxYlJXTnNqdi9oZmV5dWpE?=
 =?utf-8?B?YVdYSWVoaGlyY1BKZzBTWnVVczhaOUUxa2w1L0hVZWJMYjlIYmJQMGxQQkdL?=
 =?utf-8?B?OC95RUkvTlhqL21RZ1pMNExMMXVUZ1RwSVovM0R0TUIxTVZaRWUyYzRURzlj?=
 =?utf-8?B?QXpWZGh2dHFBMTFLTS9qSWpyc29LMXM4V1g1Q3IrWnVIMEFKa2JqN2MxYXU3?=
 =?utf-8?B?ditMWU1aUG9sUUtkNUpEaEIrclQ5OGF1dDVxTHp0cWRndW5xOW9wT3NXTmIv?=
 =?utf-8?B?cTU3R1dRb0tNYldXZ2c1VzFUbWpwU2o0dHZReWtNK3dsUlpjVnRYTWlrR2F0?=
 =?utf-8?B?UFZncldDaFZyeG4ySWM2QlY1dS9OSVoxNWY0OUFnYWxhNTE2aG83WHFNS01n?=
 =?utf-8?B?OFluYUNaRHV2Y0xZRlBlRTlTaDVoeDVhVW1QemwzMGxUQis1QjEvSUk0THh2?=
 =?utf-8?B?NU1FN1c3Wk9sdHpOZ0pVMnBqNHBValhFdDNiUHZaR21lUWM0ZnlSU0xjSzR3?=
 =?utf-8?B?WXJiL0Q4QnpicjFycTZoQ1FTMU1UbDA2bXNMNzFMVHJLRHp0U0pjWkZoL2Mv?=
 =?utf-8?B?MGlteEVoWXFIc0NLZnN3cko2bXQyQ3p5ZkpZd1dNRGQ2S1RxUVdxNjBobTB3?=
 =?utf-8?B?Y2ErWmd1cnU0a2s0NGFSQUJKcUNDK2d4SUcyeThOcnMwc1ZoWUM3dW9XUDMr?=
 =?utf-8?B?REZFaHJsMTVhT29jYW50MGllUmVPSzF1dFFpcVJNQ253MGV1YytTckdiL0Vq?=
 =?utf-8?B?L3lPTzBBdzh0dFdTZmRoNXRKQ1l3M3E1N3R6Wlp5aFVxUFltWU8xdVJSSzYx?=
 =?utf-8?B?bCt1c0VCTzAvUENWSzV1VUptbWRob0hHUkl5bndsUWNZRVo1bXZXa1hMbG9t?=
 =?utf-8?Q?6Es751pm84M=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)(376014)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?N2JKb2xPZnZ5cGtaSnJnYVhzeE1keG5NTnJEYllwTmp3MjJOKzVzekpQZnAv?=
 =?utf-8?B?ODJaa1BrejM0WlAxN3RmRXg0bXRpMWV4NFIrb3M1UGJ5Qmo2bWQ2Ym5ESTJo?=
 =?utf-8?B?dXZGOEJHa3psR3VKSHErbFozRWtINEVLbmh2YkN3Y1d2VkV4bDR2L3AyeVVx?=
 =?utf-8?B?N1lvU0RxaWliWFE0elhPZUZLZ2NhS09LRC9GakR5aFAvTHFzRXdHNVd0Q2cy?=
 =?utf-8?B?cWhVakNJT3JwcS9qcmFzcW9iWDhPSnFQWE4vVExFR1JtZGVXOVh2NTU4VzZ1?=
 =?utf-8?B?WXVYTklPZE1uTWtaY1Zha1pORDU0Zk02VlQ1SzFZblVSNjFSdkRMeFBxNUlI?=
 =?utf-8?B?RWVLVEg3SGxZY3NJbnppeWJUNHJiUk5KSGQyZTUzajlocGdyZWtacXM2UFRm?=
 =?utf-8?B?RHlORm1sU1VTZUw2eWl3dldMU0RmWEhXekt1MHdxcnpzWEc2YjVPT0QrQVE0?=
 =?utf-8?B?VUM0QkRoRGJXcnJQNnI2YUpPMlNuQTJscmJFTC9Sd2ljRGh5STdRM2JZN1hP?=
 =?utf-8?B?NFE1Z3VicDFpYTdmWVVQMEtEa3hJRnZCM1IzT3N1bmN3TVRhNmI0SHkrWUZB?=
 =?utf-8?B?VGhGSCtkMnhmZE95cWhEQzRzaG5POGttWm5CSllpWlFBN2NZQ21JMUozYWJn?=
 =?utf-8?B?b1ZsTXVHdkwxZk45N3NlcUV6dW1PQkRmN2RtbFZBaUNDSlphUDlmVUIxZVBF?=
 =?utf-8?B?cktDRzFNbGsvdXZFNWo0Nm9YUjB1d3pSMWJEVlgvd2MvN2lMZlcrZ21pWjh1?=
 =?utf-8?B?Mi9EbkFpb091bE9FMFpydGpEY2E2WXZ2c0tZenpkcXFIcDVpR3A2c2xnUkdC?=
 =?utf-8?B?RTBnQXgxQmd3YVY2REt2SnhUaDV3aE9BYUVQbXVmR09od0V3eXdIZ3pKaTRK?=
 =?utf-8?B?Wk5TWXJXL0pScGJHU3EydWliRWxodWRIbmJ5MGRRMlUwVlhzeEJDZnJjRU50?=
 =?utf-8?B?dXdzNGhTWWxLdlVkQkNkVkZ2OUFOWU9wNG1KeGc0Q090amFGN2J4UGVJRm0w?=
 =?utf-8?B?TS9FZlJTd056THhpWDNUSndJY0cwejdYZ3I2YmNjZE9tOGtlSm1zMHc3NG5x?=
 =?utf-8?B?M2NseFZWWDVvWkxDbGFBUFoxaksvWERqTXpNMHBTOUsrTXFBWk1qeUF6VVNT?=
 =?utf-8?B?ZEVla09zUmZ0UC8vblVZWnVOK2IvZmYyMWRVUVhKYjhKdTRPUlBFRjZ1cDY1?=
 =?utf-8?B?UC80UXcxV25wencrRlpwN0YwNjZvM3Z2bUhxYnIxNFhyeFFpbjhjamRIYkVn?=
 =?utf-8?B?K3VuMlhONm9WSGpTL3hFNEZPSDZ6MmVrdTFxT2Q2VFQ4a25DNGxDNHZUdEhv?=
 =?utf-8?B?cTBjcHZhWkV5RXF3RytqdGVtbjAyeUxlUGxmQ25nWGN5dGdPWVlVbGFNZG1k?=
 =?utf-8?B?WmQzcktvSktlY0JyclYzcnd5VGNFdGpYOFFWdTcvNVRqTGM3OGRNLzZxVHhE?=
 =?utf-8?B?ZHFFbFFrd1lMTzQ0QWQ4WHFxckFiKzFtZjZHbm5ZazZhcmlTb2hKbXpia04x?=
 =?utf-8?B?QWpwdW5DYjF6cHlnbWVBTjV0cWZkRG56aFZucjk0bTlYWElpSzNKbEJ0dEdS?=
 =?utf-8?B?V1NkNFAveGU1cEgrenpKRFlIamd0U2FMOXJBWGE3WTVJem1XZGRwTHlIbUhC?=
 =?utf-8?B?L1JieUtSaWZIOGp0cW53bzlIZnJoaWVaNFFVbXB3blNOQjJ1eThJNlNBOXZ4?=
 =?utf-8?B?ZmwyZ3llUG1TcHB3a3lmekhkMFFWOU5TcVc2cTJkME41d0NaNWhLU2JjcTBG?=
 =?utf-8?B?RUpsWEMwZGtqUlI3NC95TXZETjYyN2puQ2VOUjJSWFVEMXRjOXdabUxoS2ta?=
 =?utf-8?B?cGt4NTUyR3FndC9nczIrVG55aW9CTnNCQzV0cFFSNlQ3SjNLMGJLTTk2Tk1p?=
 =?utf-8?B?L2tveEhidUYveHk1U08vajhYUnc3ZVk2bkgyV01yanJoaHZLRXh5OUdGUGda?=
 =?utf-8?B?bHBDMzZpZW84NzJOQkVPQkhpcm5qNmovMTcrUzBwSHhKTktvMzFNbFJLc2FD?=
 =?utf-8?B?eUNWWFQ0cUFDTWkyWm0zSWlJN1RYeVBWOTNBNDI0T0JxY3JnSEhac0h0Nm0r?=
 =?utf-8?B?aCthVW5Od3VHNkk2YXVseWVrQ1NYRVdNTnhIYURURE5uYm1GN3YwUThqRVhC?=
 =?utf-8?Q?j50Yc++/XKEgqp9gsU7hXNu3p?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 98db99d5-3186-4bd1-1a3a-08ddaa88b8f3
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jun 2025 14:43:55.3319
 (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: Nxv0I8XawhuWl1xq/DlvC7DDWvjZZsFEbHOWYOO+CaJ6Dl2TdiiTZ8k0UHAaGri3LFf0C6n+ZN6z+96q5XaVFg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB9240

Hi Mykola,

On 02/06/2025 10:04, Mykola Kvach wrote:
> CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email.
>
>
> From: Mirela Simonovic 
>
> Timer interrupts must be disabled while the system is suspended to prevent
> spurious wake-ups. Suspending the timers involves disabling both the EL1
> physical timer and the EL2 hypervisor timer. Resuming consists of raising
> the TIMER_SOFTIRQ, which prompts the generic timer code to reprogram the
> EL2 timer as needed. Re-enabling of the EL1 timer is left to the entity
> that uses it.
>
> Introduce a new helper, disable_physical_timers, to encapsulate disabling
> of the physical timers.
>
> Signed-off-by: Mirela Simonovic 
> Signed-off-by: Saeed Nowshadi 
> Signed-off-by: Mykola Kvach 
> ---
> Changes in V4:
>    - Rephrased comment and commit message for better clarity
>    - Created separate function for disabling physical timers
>
> Changes in V3:
>    - time_suspend and time_resume are now conditionally compiled
>      under CONFIG_SYSTEM_SUSPEND
> ---
>   xen/arch/arm/include/asm/time.h |  5 +++++
>   xen/arch/arm/time.c             | 38 +++++++++++++++++++++++++++------
>   2 files changed, 37 insertions(+), 6 deletions(-)
>
> diff --git a/xen/arch/arm/include/asm/time.h b/xen/arch/arm/include/asm/time.h
> index 49ad8c1a6d..f4fd0c6af5 100644
> --- a/xen/arch/arm/include/asm/time.h
> +++ b/xen/arch/arm/include/asm/time.h
> @@ -108,6 +108,11 @@ void preinit_xen_time(void);
>
>   void force_update_vcpu_system_time(struct vcpu *v);
>
> +#ifdef CONFIG_SYSTEM_SUSPEND
> +void time_suspend(void);
> +void time_resume(void);
> +#endif /* CONFIG_SYSTEM_SUSPEND */
> +
>   #endif /* __ARM_TIME_H__ */
>   /*
>    * Local variables:
> diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
> index e74d30d258..ad984fdfdd 100644
> --- a/xen/arch/arm/time.c
> +++ b/xen/arch/arm/time.c
> @@ -303,6 +303,14 @@ static void check_timer_irq_cfg(unsigned int irq, const char *which)
>              "WARNING: %s-timer IRQ%u is not level triggered.\n", which, irq);
>   }
>
> +/* Disable physical timers for EL1 and EL2 on the current CPU */
> +static inline void disable_physical_timers(void)
> +{
> +    WRITE_SYSREG(0, CNTP_CTL_EL0);    /* Physical timer disabled */
> +    WRITE_SYSREG(0, CNTHP_CTL_EL2);   /* Hypervisor's timer disabled */
> +    isb();
> +}
> +
>   /* Set up the timer interrupt on this CPU */
>   void init_timer_interrupt(void)
>   {
> @@ -310,9 +318,7 @@ void init_timer_interrupt(void)
>       WRITE_SYSREG64(0, CNTVOFF_EL2);     /* No VM-specific offset */
>       /* Do not let the VMs program the physical timer, only read the physical counter */
>       WRITE_SYSREG(CNTHCTL_EL2_EL1PCTEN, CNTHCTL_EL2);
> -    WRITE_SYSREG(0, CNTP_CTL_EL0);    /* Physical timer disabled */
> -    WRITE_SYSREG(0, CNTHP_CTL_EL2);   /* Hypervisor's timer disabled */
> -    isb();
> +    disable_physical_timers();
>
>       request_irq(timer_irq[TIMER_HYP_PPI], 0, htimer_interrupt,
>                   "hyptimer", NULL);
> @@ -330,9 +336,7 @@ void init_timer_interrupt(void)
>    */
>   static void deinit_timer_interrupt(void)
>   {
> -    WRITE_SYSREG(0, CNTP_CTL_EL0);    /* Disable physical timer */
> -    WRITE_SYSREG(0, CNTHP_CTL_EL2);   /* Disable hypervisor's timer */
> -    isb();
> +    disable_physical_timers();
>
>       release_irq(timer_irq[TIMER_HYP_PPI], NULL);
>       release_irq(timer_irq[TIMER_VIRT_PPI], NULL);
> @@ -372,6 +376,28 @@ void domain_set_time_offset(struct domain *d, int64_t time_offset_seconds)
>       /* XXX update guest visible wallclock time */
>   }
>
> +#ifdef CONFIG_SYSTEM_SUSPEND
> +
> +void time_suspend(void)
> +{
> +    disable_physical_timers();
> +}
> +
> +void time_resume(void)
> +{
> +    /*
> +     * Raising the timer softirq triggers generic code to call reprogram_timer
> +     * with the correct timeout (not known here).
> +     *
> +     * No further action is needed to restore timekeeping after power down,
> +     * since the system counter is unaffected. See ARM DDI 0487 L.a, D12.1.2
> +     * "The system counter must be implemented in an always-on power domain."
> +     */
> +    raise_softirq(TIMER_SOFTIRQ);
> +}
> +
> +#endif /* CONFIG_SYSTEM_SUSPEND */
> +
>   static int cpu_time_callback(struct notifier_block *nfb,
>                                unsigned long action,
>                                void *hcpu)
A question. Do you see CPU_DYING gets invoked during platform suspend ? 
I wonder how this code path is invoked with

time_suspend()

- Ayan

> --
> 2.48.1
>
>


From xen-devel-bounces@lists.xenproject.org Fri Jun 13 15:08:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 15:08:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014446.1392527 (Exim 4.92)
	(envelope-from )
	id 1uQ61U-00074U-U6; Fri, 13 Jun 2025 15:08:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014446.1392527; Fri, 13 Jun 2025 15:08: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 1uQ61U-00074N-RL; Fri, 13 Jun 2025 15:08:52 +0000
Received: by outflank-mailman (input) for mailman id 1014446;
 Fri, 13 Jun 2025 15:08: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 1uQ61T-00074H-2i
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 15:08:51 +0000
Received: from DUZPR83CU001.outbound.protection.outlook.com
 (mail-northeuropeazlp170120005.outbound.protection.outlook.com
 [2a01:111:f403:c200::5])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4f1b7bc4-4868-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 17:08:49 +0200 (CEST)
Received: from AM6PR0202CA0063.eurprd02.prod.outlook.com
 (2603:10a6:20b:3a::40) by DB9PR08MB6635.eurprd08.prod.outlook.com
 (2603:10a6:10:254::12) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.25; Fri, 13 Jun
 2025 15:08:44 +0000
Received: from AMS0EPF000001AC.eurprd05.prod.outlook.com
 (2603:10a6:20b:3a:cafe::e9) by AM6PR0202CA0063.outlook.office365.com
 (2603:10a6:20b:3a::40) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.22 via Frontend Transport; Fri,
 13 Jun 2025 15:08:44 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 AMS0EPF000001AC.mail.protection.outlook.com (10.167.16.152) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.15
 via Frontend Transport; Fri, 13 Jun 2025 15:08:42 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com (2603:10a6:5:1c::25) by
 PA4PR08MB7411.eurprd08.prod.outlook.com (2603:10a6:102:2a3::12) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.19; Fri, 13 Jun
 2025 15:08:10 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668]) by DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668%2]) with mapi id 15.20.8813.024; Fri, 13 Jun 2025
 15:08: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: 4f1b7bc4-4868-11f0-a309-13f23c93f187
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=OF4i9MAsgaCYC2/eZAbczf6dVK30FDUNo9s/AdquJ9c+T2sX2DiiITpRh226gDTT2iTBbCcip02nhY2+1rBWAmJLUNBjDHGluVcHp7JO9TYi6wW8em4vReUc6HnJ2aXdG0M9HDAu7UJ6YCzxuimRof4J/EjmAMp3YypQhf+ebhORRA8EAcw50uYubIVzMli5pfqGswb/2meCbBemJZRwdGsG1oOOeifmzXD7PS+GYGgLECMa+2Ozft1GIrnOTeeJMVjMcLFUKkzKA+8noPg6Pchxai/QrKxMgLJhI7p9lXdOBSIY3QkkD6smQ7zxqTrqdZnzT6SISSUUUej/v8j3FA==
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=MXDymSsTrYYTlYE//xY6tmXz2/gWgkiBxyI9GOerb88=;
 b=J1+XqTOng4L3KRpBnZQfo9dM8Bl8FAzebJ/IXByVeLBVDepIAh9f94G9JvodfAfG6sW6EfdDJZNLFsa6k03pssu3s6U4OaGEsGdMpI4gsLrQxR8eLvUyII9a51OA0eUeH7Bf4+VBwORQM7/I2ZH+ysE7/RkqSAoaStcfx1j0Q/CIhka9SwkcTj4vAyMKIz7AlF29ar3jVQ7D8IGexUFE0yFcJI2viTc14UEMOQD3eCxZ2oOoGk/HXAtfLwfejtp2/WFPv4ZE1NcbdijLJZsbjNsgi9r5TF3KYKdxqOTe+AmyJAf+wC8eImxcksJAo8LUwYRxGcB4ksVn1LWQTd5Txw==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=amd.com smtp.mailfrom=arm.com; dmarc=pass
 (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
 (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=MXDymSsTrYYTlYE//xY6tmXz2/gWgkiBxyI9GOerb88=;
 b=NfHDcdE5yAiOp+dLYc2dB7McCM3Jkrzvd72F98alsqJkCty2upg2DnAjJs8Sx8/Wh8lbMh6p2BFyf34nUqHhdf4rbVf2xqOhDHXwtEG+wpM0aDWpUogYIh70XbyvqwysV7LyN1LamNwqImNwvyojuC5z0e+aGevHwyPcTWBpq40=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=uOwMtrCie1qwU6yNwvyUgPxfvhaXeceoQu6Wgt2OXq8tIng1bphKknxlQ1M6lAJS9AFao37R+G1yW3EFxX+EdMzt0k6KswU1GcMu5hVAiLHVxQDVyy2slnz7o8hDvtC5YVwsMCTIYLFbvwfE/qRAmi2hj/VPUP4H70Wow636b55V/gl+YaCcN/h1oSBg1fZBniSEiTbmMIcUSeGs4nH/bWULcBfu0D8KcPMej7KnOBcbnmLup+7xN0negayKlGtt9t6jE/ZnbdIvyEmmzsQuWAyvZQbcZm+sVsSQ4t26xdOpMocVPd3xiKLugysU+Dg4JgaBIb29AEECmMuov5t2aQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=MXDymSsTrYYTlYE//xY6tmXz2/gWgkiBxyI9GOerb88=;
 b=WTelt3pm9EB5iPjSLZFnRuiRDSz6VlKeYi71PtV9Bv6l3ExQHLvhZbVsnA50sHsclr3jcjU2L/PnYsjKYk9DTrTmDMJBe5z/DPax3lcJKa2misOCNUM5+LmC94vFKfqlH5ds6VjibAwlr28Ax+C0TcBb7HETiqKQ2qvCvUk9SYTCHq97nQd7woih0XpJcnOFc9B3F/TPFN4zUefJiy7Db9VZuoj23cQAvk8AKYPYd6JrbY4MGgdENOHI2kZCHt8QYwjeXekysNKUUx9QwahEJAT1gRr7wp8tflz1bitL2awBwVDyGyB0UQ91kU93Kw43w4WB5nwnbOO1qORJ3RfNLQ==
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=MXDymSsTrYYTlYE//xY6tmXz2/gWgkiBxyI9GOerb88=;
 b=NfHDcdE5yAiOp+dLYc2dB7McCM3Jkrzvd72F98alsqJkCty2upg2DnAjJs8Sx8/Wh8lbMh6p2BFyf34nUqHhdf4rbVf2xqOhDHXwtEG+wpM0aDWpUogYIh70XbyvqwysV7LyN1LamNwqImNwvyojuC5z0e+aGevHwyPcTWBpq40=
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 v3 4/6] arm/mpu: Move the functions to arm64 specific
 files
Thread-Topic: [PATCH v3 4/6] arm/mpu: Move the functions to arm64 specific
 files
Thread-Index: AQHb2t5pdnmvyzn4J0yiDihJhBlJArQBNBGA
Date: Fri, 13 Jun 2025 15:08:09 +0000
Message-ID: 
References: <20250611143544.3453532-1-ayan.kumar.halder@amd.com>
 <20250611143544.3453532-5-ayan.kumar.halder@amd.com>
In-Reply-To: <20250611143544.3453532-5-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.600.51.1.1)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB7PR08MB2987:EE_|PA4PR08MB7411:EE_|AMS0EPF000001AC:EE_|DB9PR08MB6635:EE_
X-MS-Office365-Filtering-Correlation-Id: 85e8d12e-b15f-443b-06f1-08ddaa8c2fb0
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?aDNIV2hmdUtESDg4NExnSWViMjREbWhGN1F6ZkZKa01KTHBEQWk4TGFXcFBm?=
 =?utf-8?B?V2JZSUxOMzBKak1WSXc4NklBbDQvV2l0ZytCMmZDZlhROFdYb3EzaWlwU0FW?=
 =?utf-8?B?UC9VK094NERvN1lYUTM5ZEJhUFZqakd0ZmF4OXhBb0xtWVhHaGZZT0l2UVlt?=
 =?utf-8?B?UHY1VVdpcXJib0twaHJxKzdPUmJFVFA4OFN0WWdmL3kzcTVWSmsvbnVTc0J1?=
 =?utf-8?B?ZENHa1poV2MzcWMxb2lxNWdNcjFMVWQwYVZ2NlV3TWFvcTJvNVVLUnZteWpD?=
 =?utf-8?B?YW5xSy9yb3FUMjkzMDU0VEJNNnFkMTRwOGoxUXFkZS90NnZkOERPeU1SNFRL?=
 =?utf-8?B?RDZjQTM1bjBSUWhJdjF3WFVVQkcwRVdPZ09xZG05SHJpRm9hMjF1T3Q3UlIy?=
 =?utf-8?B?V3pGd2RKM0orTUNXZGJaQlZaUzVOcVgveHcydEhoVXk0emNXN0Z2dU1md3BQ?=
 =?utf-8?B?V2xwbE1yWTNwWG1ZdlUxUnBlK25LN0s1ZXg5NEJ1WHBuRjVTVXpVbjNFMjEy?=
 =?utf-8?B?Ti9Sd1p3Smx6Q2cyM0YrZmp4YmJrRHN1QUJJVktyamh1bkQxQnVRR0VGelV5?=
 =?utf-8?B?SDZDN2dMdFZJT0IzbjB5Yk1EZWFZTnY4amxBNWhRQ0VQSC9jaUdJOW50TVUx?=
 =?utf-8?B?NFVaMDJZVm12RHJlOU5sWCtTcHI5QTFGYitPQ1l2MXl3NGxsNXlDVWw2dmo0?=
 =?utf-8?B?Sm1mSjM2aXJ0SjVVdFRsMzI1NVg1c21jMDFWRDNoQ2hWVExOV0N1cUo1VmNT?=
 =?utf-8?B?M2FaTHZLbEl6MTN3ZXgwNjdGRUhmbWNzN2E5Sm0wWWs3Q0hZR0EyWlJkc3h6?=
 =?utf-8?B?djNIMHdZK3ZVK0w0dmVVS01DZk5LeHI2N3VPNzBPamVGbXlqL2NBWDFkellY?=
 =?utf-8?B?KzFjZXdkbnlXOTU4WjF0Y0oxajNsc3dCOE9yS3Q4ZDI5NzZnR0JQVlZrWTEw?=
 =?utf-8?B?bHJOSDRIbjZFck1saVk5TTl1ZkpGVmd6YXQ3cWE1UkRTMEtWRjZVcE1rL21j?=
 =?utf-8?B?ZzlUR2NYRkczZTBPYWlxUjJOamZmaWJPVDEwTUF2L2lHMnIySnoxMTc0NGts?=
 =?utf-8?B?bmJwelM4NmJ2ekdrWDc3UTNsL0JwQ25lamNtTlFWQ2RGRjNEY1B5MWNsUUE0?=
 =?utf-8?B?aWdKN3p6UGhYaklFVU9xVkNVVSs2Q0FtT2x0K2FTbERPekFNTEtYZlJCdHlS?=
 =?utf-8?B?NnVVbHdzYWRiaXJpbzcrQklBU3lRTEU1ekpYcklkWjMxSytnd1o4U0JNV0dR?=
 =?utf-8?B?cm9uU3FmckY2MXFaT2pmSE92cGhka0dwbi9pbE40VUM0N1ZJSDFWeXgxb0tz?=
 =?utf-8?B?Z2hWOXkwZmRvVWhndFhqektPU0xobGVGSlVuaThVRmxYeVR1VzFqVEEweTgv?=
 =?utf-8?B?NGZCTFM0WHFNOWV1RmNBRXFrbzF3OWd2Y09RT2E2RHkxZjBFUHczNUNTSUE3?=
 =?utf-8?B?TXltWHdGajBRMWJmeXdiSit6YVlwV1ZBVlpvZVBpR2szSDcxTWw4bi82TWx4?=
 =?utf-8?B?QXU4TGl0aVVSWkhQNjhBazZYbEFqVnVjbGR2UWVCaUpKdXVuSnVDYVJMTkxV?=
 =?utf-8?B?Y1lmamNnZW5zK2VmY1RrWDE1a3pCVzFSSFN2UWVhbmt1RmFHelkxakp2UC9N?=
 =?utf-8?B?TGNzWnBMbzlrZlJITzQ3cmx3NDBLeGNhWE1rd3RTRXNpMnIyQ0wrOUppN3ky?=
 =?utf-8?B?NTJRVnRpeDV4REQrN1k0dmtVRjdkRU5LNmV5YnVWdW80MWxBT1Ywc3hsS0tw?=
 =?utf-8?B?NXBPdWdFVk5yZ05RbDlhTDN5amVSUVpYU1o4eVY0S2hYRVhPczJ5ZDZPZnVR?=
 =?utf-8?B?OFVlYzFhd0hPd3gwbHVzV295MGRsL3JwUlRnUzI1MW8xVlZ2TzdJaUhKR3Vj?=
 =?utf-8?B?ekt0TXhXdnV0bmFSdWczaENFUW16dVdNLzhROTU0dm1CaWQwOFp6NGl6QnN3?=
 =?utf-8?B?NVc0aERGVUppUmFaMkdqdldXTjdMK1ZDTXFKZ1JmRmNhVm0xbDFrc2xpZmdV?=
 =?utf-8?Q?Un0e8Wb7ZKSA/KaV4mDHLsHJphPn3I=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB7PR08MB2987.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: <643CF0BA9B0D734194DE689645AEE475@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR08MB7411
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AMS0EPF000001AC.eurprd05.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	f6dc8698-db9f-40e5-7a62-08ddaa8c1bf6
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700013|376014|14060799003|35042699022|82310400026|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?cHE5cnY3Q3lxMWorS01NRDF3UXRqWnhTdmw3R2RSb3ltelZiYWk0MVBjOWtE?=
 =?utf-8?B?UEIxQWN5NVllVGhMZXEwSVkyd2c0STBTcFczZnJZR2Q4RW1zOFRVQWwxUXpM?=
 =?utf-8?B?RHFuNVFycmx5YXdvWXRMbnMwOGVRZnFxQ3kwNUk2K2V0U0V4cWVrVG1sQTh0?=
 =?utf-8?B?Z1I1ZGlEVWxQZkthK3dXOEIwQ1pnSDJUN2lrQS9HdmhhSXBpUnZlL3p4Z1hQ?=
 =?utf-8?B?MFdTLzZkN1VDQWROV2Z4UG5mcXJyR0EvOHQwbE5ObktKblVEeFlPUytsTmgx?=
 =?utf-8?B?QXlyMWprKzlHbWZDcC9WNVcrdXltb0NRUFllaGxZelhoVzI3T1hMQS9ybkhE?=
 =?utf-8?B?dThUTTZGZFMzd24ya2dCQnhvVlNxYVFMUU91SmFGQ0tKdlF0VUx5ME8xQTlL?=
 =?utf-8?B?QzNScjNnZzRmK3RmV1lwcTJJVFRFZnp6UHFOUWQ4S3d3SS9NQm5QaW1IN1RY?=
 =?utf-8?B?N3ZvVzA0aVFPL0NWeDZEUFRDQXB2ek1VaEEvRVBRT05yZTJ0cHV4OHNPbm8v?=
 =?utf-8?B?b2h2b3pjZmo4WjIxU3Y1amlLMUV4NjBPdUJObXR0TzFPSmY5cEUrdzZBUEZj?=
 =?utf-8?B?K1ZIKytkQkJSeGdTOUFpVUJxUFAwSmNyYnZpd2lyTXg1aHJCRWh5WGlKcmhq?=
 =?utf-8?B?OUVrbjJQaGJneU5icXBOQ0RJRHREckZyMmh0OVFxNEhGVkJJckx1eUUzQUFX?=
 =?utf-8?B?dU45ekdXN2tHNGNYelBqTnRLQzQ2b1hCMXFnSjBuazBMK3Y3ZUFIL1RZbFhV?=
 =?utf-8?B?Ky9FYTFDd2pIUU9jS1I0d0JjQjdsZCsrUWtIb1oweDRjbjNZdVRnMWx5WjBx?=
 =?utf-8?B?ZUdSeHNYMDNpbVdpczhEYWsrWUlJMWMyeGgyZVJxS3UvcVE3V21Rc2d1MnRq?=
 =?utf-8?B?N25VRVc0UHMyK1lucUdOTGFGSUFTemVXL3lqdm5vSEFKUDRTaTVDSUpsTEdZ?=
 =?utf-8?B?VXBuaU9lZWd0UUh0WllkSFJaOXB1alBuNVgvNTUrN1I0V25TN3lWYnVMYzlZ?=
 =?utf-8?B?a2JtRjRWc2lOZGM0Y3d5RmZ2YnI1TlA1bXB2N0ZtMVlEeFVoNUZzaDM0eUJu?=
 =?utf-8?B?VXMyYnVSS1RjeXJmcXdMMjlDMC82ZFRJZ1J1dENYa0gycVRPS1NVY1BVSUx6?=
 =?utf-8?B?cm5kZEE5VmJ5YzQ4RkU1YmtQSUFWL2xRaGdYM1BDZnVuTEFONDRQS3RiOTBQ?=
 =?utf-8?B?UDA0ZUozOGgwOThpTVg4cHhlQUk1eStJTVFtYU42L2pHRCswaXZuekh2SGY5?=
 =?utf-8?B?R1E2NnZxb2Rwb081UC9TVXUwb1NoUENrYVg0V0NiZ0ZZeUtGV1lFVzB6Z0ZO?=
 =?utf-8?B?RFBaaDdTYUxXYytYeVkzeVVpR2xiWXBzQjlIK0RWRDBpbDdseENmNHdJYnJC?=
 =?utf-8?B?UWQ4aXpDRDZPU3hVMml2R2VhWjRrckM2b0ZTb1pPNXhVL01mWFFwaXVCZk96?=
 =?utf-8?B?S291cHFiT2NKZWVqVVdDcjZja3hOUEw2Y2t0ZTk0bFJLMXBlVE9Rb1B6bGt2?=
 =?utf-8?B?VG5FbGo1SURTTmlEU0NmSnM2RmVMZUZzeGZFRUNIVEhLdHBtNGwzNVgzY1hO?=
 =?utf-8?B?bVhDWXIxWk4rZW9pdWwvWGxLSitsK1BDSzdmZFMvVjBYSWIvbXk1cGFlRGh2?=
 =?utf-8?B?NlZTaWZ1bzREUm9FVmxHQlJhNENSOVFFZXVrZlJuN2pwWkxrRXhrRVliR1Zp?=
 =?utf-8?B?eGV1c09NY0c3K2d6Z2pPYVpXK255YzYvRzR5NnFhTzQycGFGYUpZSTNTR1Bv?=
 =?utf-8?B?SjAydnFiMkwwd1U0NFZQelFKQUNiazBVZVU5Y0ZGZ2l6ME9PUFp4UUtvSWNj?=
 =?utf-8?B?RUlYT1Nhb2d0U1hmMkpDWEIwOUpEeHYxdURPY0drL2w4T1lXMUxqeWg4ZnV2?=
 =?utf-8?B?dExyS08rY1NqV25Na05IcFFKMkx2bnl3ejlaeTZUbTJpbFhEd2pHQnJLMkUy?=
 =?utf-8?B?SDVGTWZUSkpIK2p3QXBSUXRzQmxLRi9rZVZtMThmNWkyU2tGTk5DeXhObkpl?=
 =?utf-8?B?aFFVN2RhMkNmeFZCZzZRdW5yN2lWTVE2eDR6dHpxRFQvVkxHRnQwZk1ZSWpP?=
 =?utf-8?Q?/ubZXW?=
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(376014)(14060799003)(35042699022)(82310400026)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jun 2025 15:08:42.7741
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 85e8d12e-b15f-443b-06f1-08ddaa8c2fb0
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com]
X-MS-Exchange-CrossTenant-AuthSource:
	AMS0EPF000001AC.eurprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB6635

SGkgQXlhbiwNCg0KPiBPbiAxMSBKdW4gMjAyNSwgYXQgMTU6MzUsIEF5YW4gS3VtYXIgSGFsZGVy
IDxheWFuLmt1bWFyLmhhbGRlckBhbWQuY29tPiB3cm90ZToNCj4gDQo+IHByZXBhcmVfc2VsZWN0
b3IoKSwgcmVhZF9wcm90ZWN0aW9uX3JlZ2lvbigpIGFuZCB3cml0ZV9wcm90ZWN0aW9uX3JlZ2lv
bigpDQo+IGRpZmZlciBzaWduaWZpY2FudGx5IGJldHdlZW4gYXJtMzIgYW5kIGFybTY0LiBUaHVz
LCBtb3ZlIHRoZXNlIGZ1bmN0aW9ucw0KPiB0byB0aGVpciBzcGVjaWZpYyBmb2xkZXJzLg0KDQog
ICBe4oCUIE5JVDog4oCcdG8gc3ViLWFyY2ggc3BlY2lmaWMgZm9sZGVy4oCdPyBXaGF0IGRvIHlv
dSB0aGluaz8NCg0KPiANCj4gR0VORVJBVEVfe1dSSVRFL1JFQUR9X1BSX1JFR19DQVNFIGFyZSBk
dXBsaWNhdGVkIGZvciBhcm0zMiBhbmQgYXJtNjQgc28NCj4gYXMgdG8gaW1wcm92ZSB0aGUgY29k
ZSByZWFkYWJpbGl0eS4NCg0KSXQgcmVhZHMgYSBiaXQgaGFyZCBpbiB0aGlzIHdheSwgd2hhdCBh
Ym91dDoNCg0K4oCcQWxzbyB0aGUgbWFjcm8gR0VORVJBVEVfe1dSSVRFL1JFQUR9X1BSX1JFR19D
QVNFIGFyZSBtb3ZlZCwgaW4gb3JkZXIgdG8NCmtlZXAgdGhlbSBpbiB0aGUgc2FtZSBmaWxlIG9m
IHRoZWlyIHVzYWdlIGFuZCBpbXByb3ZlIHJlYWRhYmlsaXR5Ig0KDQo+IA0KPiBTaWduZWQtb2Zm
LWJ5OiBBeWFuIEt1bWFyIEhhbGRlciA8YXlhbi5rdW1hci5oYWxkZXJAYW1kLmNvbT4NCj4gLS0t
DQo+IENoYW5nZXMgZnJvbSAtDQo+IA0KPiB2MS4udjIgLSBOZXcgcGF0Y2ggaW50cm9kdWNlZCBp
biB2My4NCj4gDQo+IHhlbi9hcmNoL2FybS9tcHUvTWFrZWZpbGUgICAgICAgfCAgIDEgKw0KPiB4
ZW4vYXJjaC9hcm0vbXB1L2FybTY0L01ha2VmaWxlIHwgICAxICsNCj4geGVuL2FyY2gvYXJtL21w
dS9hcm02NC9tbS5jICAgICB8IDEzMCArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKw0K
PiB4ZW4vYXJjaC9hcm0vbXB1L21tLmMgICAgICAgICAgIHwgMTE3IC0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0NCj4gNCBmaWxlcyBjaGFuZ2VkLCAxMzIgaW5zZXJ0aW9ucygrKSwgMTE3IGRl
bGV0aW9ucygtKQ0KPiBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2FyY2gvYXJtL21wdS9hcm02NC9N
YWtlZmlsZQ0KPiBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2FyY2gvYXJtL21wdS9hcm02NC9tbS5j
DQo+IA0KPiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL21wdS9NYWtlZmlsZSBiL3hlbi9hcmNo
L2FybS9tcHUvTWFrZWZpbGUNCj4gaW5kZXggOTM1OWQ3OTMzMi4uNDk2M2M4YjU1MCAxMDA2NDQN
Cj4gLS0tIGEveGVuL2FyY2gvYXJtL21wdS9NYWtlZmlsZQ0KPiArKysgYi94ZW4vYXJjaC9hcm0v
bXB1L01ha2VmaWxlDQo+IEBAIC0xLDQgKzEsNSBAQA0KPiBvYmotJChDT05GSUdfQVJNXzMyKSAr
PSBhcm0zMi8NCj4gK29iai0kKENPTkZJR19BUk1fNjQpICs9IGFybTY0Lw0KPiBvYmoteSArPSBt
bS5vDQo+IG9iai15ICs9IHAybS5vDQo+IG9iai15ICs9IHNldHVwLmluaXQubw0KPiBkaWZmIC0t
Z2l0IGEveGVuL2FyY2gvYXJtL21wdS9hcm02NC9NYWtlZmlsZSBiL3hlbi9hcmNoL2FybS9tcHUv
YXJtNjQvTWFrZWZpbGUNCj4gbmV3IGZpbGUgbW9kZSAxMDA2NDQNCj4gaW5kZXggMDAwMDAwMDAw
MC4uYjE4Y2VjNDgzNg0KPiAtLS0gL2Rldi9udWxsDQo+ICsrKyBiL3hlbi9hcmNoL2FybS9tcHUv
YXJtNjQvTWFrZWZpbGUNCj4gQEAgLTAsMCArMSBAQA0KPiArb2JqLXkgKz0gbW0ubw0KPiBkaWZm
IC0tZ2l0IGEveGVuL2FyY2gvYXJtL21wdS9hcm02NC9tbS5jIGIveGVuL2FyY2gvYXJtL21wdS9h
cm02NC9tbS5jDQo+IG5ldyBmaWxlIG1vZGUgMTAwNjQ0DQo+IGluZGV4IDAwMDAwMDAwMDAuLmE5
NzhjMWZjNmUNCj4gLS0tIC9kZXYvbnVsbA0KPiArKysgYi94ZW4vYXJjaC9hcm0vbXB1L2FybTY0
L21tLmMNCj4gQEAgLTAsMCArMSwxMzAgQEANCj4gKy8qIFNQRFgtTGljZW5zZS1JZGVudGlmaWVy
OiBHUEwtMi4wLW9ubHkgKi8NCj4gKw0KPiArI2luY2x1ZGUgPHhlbi9idWcuaD4NCj4gKyNpbmNs
dWRlIDx4ZW4vdHlwZXMuaD4NCj4gKyNpbmNsdWRlIDxhc20vbXB1Lmg+DQo+ICsjaW5jbHVkZSA8
YXNtL3N5c3JlZ3MuaD4NCj4gKyNpbmNsdWRlIDxhc20vc3lzdGVtLmg+DQo+ICsNCj4gKy8qDQo+
ICsgKiBUaGUgZm9sbG93aW5nIGFyZSBuZWVkZWQgZm9yIHRoZSBjYXNlczogR0VORVJBVEVfV1JJ
VEVfUFJfUkVHX0NBU0UNCj4gKyAqIGFuZCBHRU5FUkFURV9SRUFEX1BSX1JFR19DQVNFIHdpdGgg
bnVtPT0wDQo+ICsgKi8NCj4gKyNkZWZpbmUgUFJCQVIwX0VMMiBQUkJBUl9FTDINCj4gKyNkZWZp
bmUgUFJMQVIwX0VMMiBQUkxBUl9FTDINCj4gKw0KPiArI2RlZmluZSBQUkJBUl9FTDJfKG4pICAg
UFJCQVIjI24jI19FTDINCj4gKyNkZWZpbmUgUFJMQVJfRUwyXyhuKSAgIFBSTEFSIyNuIyNfRUwy
DQo+ICsNCj4gKyNkZWZpbmUgR0VORVJBVEVfV1JJVEVfUFJfUkVHX0NBU0UobnVtLCBwcikgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcDQo+ICsgICAgY2FzZSBudW06ICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXA0K
PiArICAgIHsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwNCj4gKyAgICAgICAgV1JJVEVfU1lTUkVHKHByLT5wcmJh
ci5iaXRzICYgfk1QVV9SRUdJT05fUkVTMCwgUFJCQVJfRUwyXyhudW0pKTsgICBcDQo+ICsgICAg
ICAgIFdSSVRFX1NZU1JFRyhwci0+cHJsYXIuYml0cyAmIH5NUFVfUkVHSU9OX1JFUzAsIFBSTEFS
X0VMMl8obnVtKSk7ICAgXA0KPiArICAgICAgICBicmVhazsgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwNCj4gKyAgICB9DQo+ICsN
Cj4gKyNkZWZpbmUgR0VORVJBVEVfUkVBRF9QUl9SRUdfQ0FTRShudW0sIHByKSAgICAgICAgICAg
ICAgICAgICAgICBcDQo+ICsgICAgY2FzZSBudW06ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXA0KPiArICAgIHsgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwNCj4gKyAgICAgICAgcHItPnBy
YmFyLmJpdHMgPSBSRUFEX1NZU1JFRyhQUkJBUl9FTDJfKG51bSkpOyAgICAgICAgICBcDQo+ICsg
ICAgICAgIHByLT5wcmxhci5iaXRzID0gUkVBRF9TWVNSRUcoUFJMQVJfRUwyXyhudW0pKTsgICAg
ICAgICAgXA0KPiArICAgICAgICBicmVhazsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwNCj4gKyAgICB9DQo+ICsNCj4gKy8qDQo+ICsgKiBBcm12OC1S
IHN1cHBvcnRzIGRpcmVjdCBhY2Nlc3MgYW5kIGluZGlyZWN0IGFjY2VzcyB0byB0aGUgTVBVIHJl
Z2lvbnMgdGhyb3VnaA0KPiArICogcmVnaXN0ZXJzOg0KPiArICogIC0gaW5kaXJlY3QgYWNjZXNz
IGludm9sdmVzIGNoYW5naW5nIHRoZSBNUFUgcmVnaW9uIHNlbGVjdG9yLCBpc3N1aW5nIGFuIGlz
Yg0KPiArICogICAgYmFycmllciBhbmQgYWNjZXNzaW5nIHRoZSBzZWxlY3RlZCByZWdpb24gdGhy
b3VnaCBzcGVjaWZpYyByZWdpc3RlcnMNCj4gKyAqICAtIGRpcmVjdCBhY2Nlc3MgaW52b2x2ZXMg
YWNjZXNzaW5nIHNwZWNpZmljIHJlZ2lzdGVycyB0aGF0IHBvaW50IHRvDQo+ICsgKiAgICBzcGVj
aWZpYyBNUFUgcmVnaW9ucywgd2l0aG91dCBjaGFuZ2luZyB0aGUgc2VsZWN0b3IsIGF2b2lkaW5n
IHRoZSB1c2Ugb2YNCj4gKyAqICAgIGEgYmFycmllci4NCj4gKyAqIEZvciBBcm02NCB0aGUgUFJ7
QixMfUFSX0VMeCAoZm9yIG49MCkgYW5kIFBSe0IsTH1BUjxuPl9FTHggKGZvciBuPTEuLjE1KSBh
cmUNCj4gKyAqIHVzZWQgZm9yIHRoZSBkaXJlY3QgYWNjZXNzIHRvIHRoZSByZWdpb25zIHNlbGVj
dGVkIGJ5DQo+ICsgKiBQUlNFTFJfRUwyLlJFR0lPTjw3OjQ+Om4sIHNvIDE2IHJlZ2lvbnMgY2Fu
IGJlIGRpcmVjdGx5IGFjY2Vzc2VkIHdoZW4gdGhlDQo+ICsgKiBzZWxlY3RvciBpcyBhIG11bHRp
cGxlIG9mIDE2LCBnaXZpbmcgYWNjZXNzIHRvIGFsbCB0aGUgc3VwcG9ydGVkIG1lbW9yeQ0KPiAr
ICogcmVnaW9ucy4NCj4gKyAqLw0KPiArc3RhdGljIHZvaWQgcHJlcGFyZV9zZWxlY3Rvcih1aW50
OF90ICpzZWwpDQo+ICt7DQo+ICsgICAgdWludDhfdCBjdXJfc2VsID0gKnNlbDsNCj4gKw0KPiAr
ICAgIC8qDQo+ICsgICAgICoge3JlYWQsd3JpdGV9X3Byb3RlY3Rpb25fcmVnaW9uIHdvcmtzIHVz
aW5nIHRoZSBkaXJlY3QgYWNjZXNzIHRvIHRoZSAwLi4xNQ0KPiArICAgICAqIHJlZ2lvbnMsIHNv
IGluIG9yZGVyIHRvIHNhdmUgdGhlIGlzYigpIG92ZXJoZWFkLCBjaGFuZ2UgdGhlIFBSU0VMUl9F
TDINCj4gKyAgICAgKiBvbmx5IHdoZW4gbmVlZGVkLCBzbyB3aGVuIHRoZSB1cHBlciA0IGJpdHMg
b2YgdGhlIHNlbGVjdG9yIHdpbGwgY2hhbmdlLg0KPiArICAgICAqLw0KPiArICAgIGN1cl9zZWwg
Jj0gMHhGMFU7DQo+ICsgICAgaWYgKCBSRUFEX1NZU1JFRyhQUlNFTFJfRUwyKSAhPSBjdXJfc2Vs
ICkNCj4gKyAgICB7DQo+ICsgICAgICAgIFdSSVRFX1NZU1JFRyhjdXJfc2VsLCBQUlNFTFJfRUwy
KTsNCj4gKyAgICAgICAgaXNiKCk7DQo+ICsgICAgfQ0KPiArICAgICpzZWwgPSAqc2VsICYgMHhG
VTsNCg0KVGhpcyBvbmUgaXMgZGlmZmVyZW50IGluIHRoZSBvcmlnaW5hbCBmaWxlICgqc2VsICY9
IDB4RlU7KQ0KDQpUaGUgcmVzdCBsb29rcyBnb29kIHRvIG1lIQ0KV2l0aCB0aGUgYWJvdmUgZml4
ZWQ6DQoNClJldmlld2VkLWJ5OiBMdWNhIEZhbmNlbGx1IDxsdWNhLmZhbmNlbGx1QGFybS5jb20+
DQoNCkNoZWVycywNCkx1Y2ENCg0K


From xen-devel-bounces@lists.xenproject.org Fri Jun 13 15:16:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 15:16:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014453.1392542 (Exim 4.92)
	(envelope-from )
	id 1uQ68z-0000Nj-VC; Fri, 13 Jun 2025 15:16:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014453.1392542; Fri, 13 Jun 2025 15:16: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 1uQ68z-0000Mz-Ou; Fri, 13 Jun 2025 15:16:37 +0000
Received: by outflank-mailman (input) for mailman id 1014453;
 Fri, 13 Jun 2025 15:16: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 1uQ68y-0000Kb-SM
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 15:16:36 +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 6553298b-4869-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 17:16:35 +0200 (CEST)
Received: from DS7P220CA0025.NAMP220.PROD.OUTLOOK.COM (2603:10b6:8:223::22) by
 DM4PR12MB6110.namprd12.prod.outlook.com (2603:10b6:8:ad::7) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8835.19; Fri, 13 Jun 2025 15:16:32 +0000
Received: from DS1PEPF00017097.namprd05.prod.outlook.com
 (2603:10b6:8:223:cafe::88) by DS7P220CA0025.outlook.office365.com
 (2603:10b6:8:223::22) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.23 via Frontend Transport; Fri,
 13 Jun 2025 15:16:32 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 DS1PEPF00017097.mail.protection.outlook.com (10.167.18.101) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Fri, 13 Jun 2025 15:16:31 +0000
Received: from xcbagarciav01.xilinx.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; Fri, 13 Jun
 2025 10:16:29 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6553298b-4869-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=tR0Lv8cfYYhQPMwywuQ1v9Ug90Whgk520nAaWu+rMZgLUTjkpmDD2ARH9Hgz0kR6DOpIxAcLU44ylDb/K+NMqAq4nDlR20MfPlc5kYDuQYBrwe1dmP86a6GueynivJ8RnMmh1AvgfL1kaDsOK6vVDFik76C4SgEXsTSeCaRGo12WtWyPk6swVzyZMKYCtxHe54XGLnRiF7JZUAg4O+qRbgHR2QoVODIpRx/wZtq+ePdXWArvLcgcUN1pFJ/ib2a417A411Yw+BfoKwDszpgQYwmffApIpzOG/kchP9KfivPMT86J36JYxqzMLLMI/FPX0khfN497lH/Th2rjqz8GgQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=J5OnCJJNwcHtcsp/MXejjMQBlQ9XSoV2j6h/sCF/MRg=;
 b=AlbIV8o9R4sJc2jSLlfR/iN5G34YQoPclSiul2G7KMFFyVYYZYKaeLbzULJIcMdMCJrn2waka5g4urTBQzR7BwjSJQhSwuH/vkjQ/ikXiEQYO3Ct7KVIReHPHyJh3zij4ZuJmng6SQwa4/WXA3llan3rw5MT6R4PO15Og6Du+ZXBMRceF2m/IOSmEY/7J0ZRGpN5J+HHESSk+uvzicJLXdflyiTXT9xKV/EQNLQGJX9r9x8VKierPN/7G2BDhFs8pJP1NxeZ0gO4Q6lt6A/KwMwYyuy+HZqikOC46Nw1nVwct5IzFTiv2rzsOMaZ22H/wTe5Ho7OtHTLR0s9XeG8cw==
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=J5OnCJJNwcHtcsp/MXejjMQBlQ9XSoV2j6h/sCF/MRg=;
 b=gdDpoKSCRMVN+PJ7B2fVhKYLGd4FrIeATHlag8dUA2bqgiXFbD3BpX1oY/3AwvXJ6H6WSZxbs2G9FdHghBHdLJ+jkWwqEGt9JqMWkkqGwjWjnk7fiSBlnwO5RaEY/vNhIojnntK/7WVVZQXpjaLHZQaCAxCmnUdoYg1uZFksEnk=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , "Daniel P. Smith"
	
Subject: [PATCH v3 01/14] arm/gnttab: Remove xen/grant_table.h cyclic include
Date: Fri, 13 Jun 2025 17:13:10 +0200
Message-ID: <20250613151612.754222-2-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250613151612.754222-1-agarciav@amd.com>
References: <20250613151612.754222-1-agarciav@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: DS1PEPF00017097:EE_|DM4PR12MB6110:EE_
X-MS-Office365-Filtering-Correlation-Id: 358b5fa8-b885-4f14-001e-08ddaa8d470c
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?YgySIpcr0kMOrRXEAp3vl3WqdCHHi3Kt3NQ8A+/iDrYgG2ELCKxDl+jK1wJs?=
 =?us-ascii?Q?VJ73PghczHCjodcaNTyCO6AkFssiRDn1m9hmhvaD6AYavtmaKL5BNkKzEnYg?=
 =?us-ascii?Q?TE4oIk+vk4PufSbXai0FImoQvshBkQSM77rKMdOOyT/81AJSat5yuRWEwF1i?=
 =?us-ascii?Q?92PHozg6vRAf3F0Odlc1e4lwDlzyoxGZZUK01xLaI4U76Wt9UDd9YZSww/7f?=
 =?us-ascii?Q?Z1ujmiRXGAttPGJ4azM9YZ2LNXmuVQKV93JS/wrm1QQluvN+9ZOlMK2UCnu7?=
 =?us-ascii?Q?vuxiqCApNUfykuFHD23ZOq+R00/YLxiuUCA20PUNisFCU6/SSwaMGzYLDhNz?=
 =?us-ascii?Q?DmxBIgf63VQ9UePJP7JCR+rFEGWV4oHRbbAF5UTOx2AJovTO2xNGVTk6scOP?=
 =?us-ascii?Q?6xA34kw2rocpCslBIAqEclbxTkEmOpJXjbk/x659l7KTfhFnIOP/5AFqaq2j?=
 =?us-ascii?Q?Y6R6L4YWIzkmXdr8TRlyxVY+fWHZHCKT+1KwUZV3YuQf+KtKrjXFO+GjYne7?=
 =?us-ascii?Q?WBbrgSnVqG6InQD9QtI7SGcj9pfJLetYoj1sdDbezXYMFUuNWEYw3+uUpgyV?=
 =?us-ascii?Q?Tx/psNh3T/o6kNf74KxvN9ylFOSb8bi42hOQ+uBTYVa9wIIQL/S6L1c/kioX?=
 =?us-ascii?Q?nDukbP2kzxHi8xu+QIoeHpJLSPNlk/IWBEy7OnGX3awC3bBYBurfv6CVn8K2?=
 =?us-ascii?Q?OGHt9SqwXGFeE49oEb1IxOb63FUvZ2onbHj8Qwq4GoWOcPB38GT4Ksds55QS?=
 =?us-ascii?Q?95hvPCFx2NOJyyrVWDHLV/NNw0GuYemdiNKixyd3Y62r8Ixb8UQ1SIs/ftqp?=
 =?us-ascii?Q?3cbQuZrGiNVNRxsDw3JqDxbLXowp9jlVMJqX/E15YMoALWCI452uuFNQ0zjZ?=
 =?us-ascii?Q?e88STDAQw5JJbHA0H1uNaQU0/FQyfCIdn5TQ0Ad1RtpcyU1x3hH2JoBupZuT?=
 =?us-ascii?Q?4GwOqOjaliILLPhbATlbkOr3kZIu0X0YdbQappaf+NmqpMo9r34G8YhB8kL0?=
 =?us-ascii?Q?7ZL4r+jpkJTwazCag6/Z1NTFhI6pSMAERLGBvk4an20vxvq/q5mb99ShNd+7?=
 =?us-ascii?Q?3lUzU8HU1ZCckNWb9FZ2AUVdPXx29YXgimP/wz8CziLv/dD9CdL26KU2uIBR?=
 =?us-ascii?Q?dbwEHAnFI0L0Dx4xilPuOceCJUig/t1DKK1q723OND0Wdn6PfuOFIZDwS3yU?=
 =?us-ascii?Q?Yt9Ram98TjfJUCECxv8KajsXVmJSXhZ3mMh9yGOfsqI/2ulKcNxi6az2ljsd?=
 =?us-ascii?Q?VA8UvmadLtevGEuaYDsQFmbeCL9a1CXeCO2dVaEPlwWpMr9Dk2X1qacIVQog?=
 =?us-ascii?Q?oM0zQwiViDkVzExzsBkc9/U14vTJNPYe82ciWo6esldtrGipxBfBWqI3EHr/?=
 =?us-ascii?Q?MHVrsLRi2yX4lkGpdA6aalywpvwDoI9wVUPnGiSyj0ZDFaO5IhvnZ7pAVrOQ?=
 =?us-ascii?Q?XiZ9VjrS6hiHzhYK/bZfRp2GX5dGEClLRZ93j8M5ZF9Nnk/jWJz1frUdJksh?=
 =?us-ascii?Q?QJ8VYemK/XeWIy+3vHh/rxv4Qum0g6JFjmNe?=
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: 13 Jun 2025 15:16:31.4753
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 358b5fa8-b885-4f14-001e-08ddaa8d470c
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:
	DS1PEPF00017097.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6110

The way they currently include each other, with one of the includes
being conditional on CONFIG_GRANT_TABLE, makes it hard to know which
contents are included when.

Break the cycle by removing the asm/grant_table.h include.

Not a functional change because.

Signed-off-by: Alejandro Vallejo 
---
v3:
  * Strictly remove the cycle in asm/grant_table.h
    (Keeping the conditional include is a terrible idea, IMO)
---
 xen/arch/arm/include/asm/grant_table.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/xen/arch/arm/include/asm/grant_table.h b/xen/arch/arm/include/asm/grant_table.h
index c5d87b60c4..c47058a3a0 100644
--- a/xen/arch/arm/include/asm/grant_table.h
+++ b/xen/arch/arm/include/asm/grant_table.h
@@ -1,7 +1,6 @@
 #ifndef __ASM_GRANT_TABLE_H__
 #define __ASM_GRANT_TABLE_H__
 
-#include 
 #include 
 #include 
 #include 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 15:16:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 15:16:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014455.1392567 (Exim 4.92)
	(envelope-from )
	id 1uQ692-00011W-IG; Fri, 13 Jun 2025 15:16:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014455.1392567; Fri, 13 Jun 2025 15:16: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 1uQ692-00011N-FP; Fri, 13 Jun 2025 15:16:40 +0000
Received: by outflank-mailman (input) for mailman id 1014455;
 Fri, 13 Jun 2025 15:16: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 1uQ691-0000Kb-9L
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 15:16:39 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on2061b.outbound.protection.outlook.com
 [2a01:111:f403:2417::61b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 667170b0-4869-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 17:16:38 +0200 (CEST)
Received: from DM6PR08CA0002.namprd08.prod.outlook.com (2603:10b6:5:80::15) by
 CYYPR12MB8889.namprd12.prod.outlook.com (2603:10b6:930:cb::16) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8792.39; Fri, 13 Jun 2025 15:16:35 +0000
Received: from DS1PEPF0001709B.namprd05.prod.outlook.com
 (2603:10b6:5:80:cafe::be) by DM6PR08CA0002.outlook.office365.com
 (2603:10b6:5:80::15) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.23 via Frontend Transport; Fri,
 13 Jun 2025 15:16:35 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 DS1PEPF0001709B.mail.protection.outlook.com (10.167.18.105) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Fri, 13 Jun 2025 15:16:35 +0000
Received: from xcbagarciav01.xilinx.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; Fri, 13 Jun
 2025 10:16:33 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 667170b0-4869-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=qAmIoKvttO5f+kfpHTQxmQKfBQDFx6k0p393NHD5uEa5cpTgivp9HJzNmwUrME8CJrYyc3d8SVSEPkK633Ilc2os/pF8YuA3sjJtjGRTqAGsxJ/ZqpyLh2Q3pCxNEwJzxsCrMf3Y9598+t+SFUBQtKy9mF4ZcR/2P4SHdgD2qelrKUgKPjPCb8WiY6T5RTzIYeBehlnxfQO2URJqv6pQmTsZVD5VQ/2VsdSEhB40jQ8cNSfmXXA4Yp0h/ffhdXYSIayBCYpVyMVgJTHSX0f6AVEu6iLF2jUNV4EYNR3Cp56LGHoBMQxY+KGis7qEd+M+dllOtPhvxfn5PU2chPbq4w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Bto0Sue9jzjcaEeJFmEWkgGlcmxgs86j5hGDpqnCvg8=;
 b=PlES03UWbQco7cdqDrNG+ROeqhAZ0lBYiH6kB6t+CFDMzWidrwSIezKdSSkS3uGzm6C13WT/98htxpC5Y9Ux1p5fHL1eibXoNmY/Y30zeiyYNmpqYQpC+rY/4EUP6/HH4j4vsnr9wCO/ldMIAW3zfUCJ0SFRCf/WOby5WzfLTBcHPguvlyHk18BBUyiXv01KKzGpnT3iK0676tCdsb+t74bw5LCpHWhj6mqIWxziWjnYCiwyjIqIY2TNVA9Ykd+f09dBMfbDUGzRPwQPjyu2grfH4iQSkpVmqOD3hcnAfFi4AI5j4UM+qqp57CklTDwnj2G37ojGLqqwLwk/x1y05Q==
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=Bto0Sue9jzjcaEeJFmEWkgGlcmxgs86j5hGDpqnCvg8=;
 b=SmEd7ei/JT0vEDsjbsYeQmEL97f4HkGNxz5qUtQuS4UfsQAZPimqyz0bnavyVVUSwYl47gnhaPOLP787LoY0HFbQVkkGzqo7BlfH5qqVQ5qtGV/f1kiUndhPtC9oyYwvaBPs/xt03hG7r81KH24Ul6reCpKVOEdNOH0N/nuYtPw=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , 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 03/14] CODING_STYLE: Custom type names must be snake-cased by word.
Date: Fri, 13 Jun 2025 17:13:12 +0200
Message-ID: <20250613151612.754222-4-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250613151612.754222-1-agarciav@amd.com>
References: <20250613151612.754222-1-agarciav@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: DS1PEPF0001709B:EE_|CYYPR12MB8889:EE_
X-MS-Office365-Filtering-Correlation-Id: d1ffcf5c-f8ab-4fbd-e882-08ddaa8d4964
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?iPVAqwMpnYZ36qKY9Yjv5vUn8JnJrk+HnKexAxEIqvsFqHLQJY8VuENS2LYk?=
 =?us-ascii?Q?/CH6l9kJWpJOmVZoI1UdRDgLeaCU0gBstRG5P0RfY33PihJheeEMRGlGLf4J?=
 =?us-ascii?Q?tD8SBWf3hj2KCeBEzn6IOlIASPUkm8Osv7JwXXiHOuuxVQZ+eBcFRzc+6zm1?=
 =?us-ascii?Q?lthl2ZYubSFpnN3W0WVX4KZ3DiI79SwBHHTrbNcMmzN9FSE5KyvSyn08osAd?=
 =?us-ascii?Q?j/nZEXYOdq8aMVdAuPV6TAKrbySpeoJsnPKyUqZKcfizuTB8BezcrrLzHnoz?=
 =?us-ascii?Q?GxG1ouzTf/nwSeKxObxg5y3/bjtrnZXwKr7CCo66mK9Fg9Ea8y7N6Qxmy50O?=
 =?us-ascii?Q?udqgt61VdoGhIm3Cy4g3J+nGKpl2FEaeGNzytuXfrfg19ZeSVbbaSHei2+DH?=
 =?us-ascii?Q?em3rGYKB4/IpL+yjC4K5FNYRo9/HodDqnE33OXQR3EiM5Bh8r1skQLm6tpv4?=
 =?us-ascii?Q?EpgHPRh8CNEFecWjrWp4jlyMEUghZSSBh3OvyieB7i+Z4mrQJ794zO1FMz8F?=
 =?us-ascii?Q?b4SK7A08RUnWBbYrCk1nqbk6IfVk6fx0oGPV5VckleEIQswQUXe9w69FetE+?=
 =?us-ascii?Q?N4AVdFO1nN4wvrGHEldG0NZ50+Bovvz9Cq37sLM/q0d4L0N1ms1ubtO3bucZ?=
 =?us-ascii?Q?C48EoEfXylyX7hoL5uTdeSn3QUpakHEgDNfuelyOcxjxFi3F9Pfc7LwHo6uu?=
 =?us-ascii?Q?5NyjS7TMdSOKP02rP7h2P0h7imiZOmdYt38g+LiXTTjU3fnzztzrYJbLS5BC?=
 =?us-ascii?Q?R4RAEuOq3ZTNBgE2jzp8Wv9CLyWGW5glLEyqgkuHFq8Od2DnvflhU51jhkvY?=
 =?us-ascii?Q?DsVHwQN/vULeOliCoAxTR0Pq5o/FVbOrZt5yeYcj5INz5rLvPP37Sn+OeOJX?=
 =?us-ascii?Q?8M/cKBcKNEYWntU1KUdbGQsH3ZBlwPz/VIHb+kqD59tzegf0x10dErRmZqhw?=
 =?us-ascii?Q?+TFZMXMapKOK+ZvqJrUX4AMWGm6LXHbFdmG1P8xgDMOMdZZ3y6kJGeQdrDUr?=
 =?us-ascii?Q?g8SjH1mdG2pGuiOnB33gZBEEt948EREdRSIkryCl/edKgAz8Ze48pU9V+elD?=
 =?us-ascii?Q?srNKL5w75yaEeldgMGm7qBejHB4du7BT5p4d20ypNJ04kHO2SmbGMrNj7OKE?=
 =?us-ascii?Q?AfYJcNZEAGeSmlPzIT5yunkUsCZmfNCzyPztnrbnWSLnm05qQqyJBXYF9bKd?=
 =?us-ascii?Q?gDYNAW4zVKA+ypp2p1GcBRhSc+HXrGxYgsJpP11+6Zj/eegIktiWcuvVM6jL?=
 =?us-ascii?Q?6ITen8bqE7uTgXHabz5SPoq4qWd+UxNsZQywU/9Hplk1z4fKkxXXuuHpbQQ0?=
 =?us-ascii?Q?H9/vbqalotF5+U8Y9owa07n95Jph32fDhtZ84tsTzM9jS8X//2UInLoSaYXR?=
 =?us-ascii?Q?1F/fCb0kv6OK99B5w5xK14hwisHzr2DdpFMiaAWw3hGGgxTTZPi3BLESTKtQ?=
 =?us-ascii?Q?aTrb0FFC6ubSooF7H7lg0OnH92zqxhvHUSWSzzFbtDFNKFa/jcuRbzlwjIPk?=
 =?us-ascii?Q?WzC2Y8yg57mmPxbTwTgoam5LOfyQCQqkGxII?=
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: 13 Jun 2025 15:16:35.4131
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d1ffcf5c-f8ab-4fbd-e882-08ddaa8d4964
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:
	DS1PEPF0001709B.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYYPR12MB8889

There's the unwritten convention in x86 of splitting type names using
underscores. Add such convention to the CODINNG_STYLE to make it
common and less unwritten.

Signed-off-by: Alejandro Vallejo 
---
 CODING_STYLE | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/CODING_STYLE b/CODING_STYLE
index 5644f1697f..e91ef7b3ca 100644
--- a/CODING_STYLE
+++ b/CODING_STYLE
@@ -126,6 +126,9 @@ register).
 Especially with pointer types, whenever the pointed to object is not
 (supposed to be) modified, qualify the pointed to type with "const".
 
+When defining types, split its words using underscores (e.g: prefer my_foo to
+myfoo).
+
 Comments
 --------
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 15:16:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 15:16:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014452.1392537 (Exim 4.92)
	(envelope-from )
	id 1uQ68z-0000Kt-MI; Fri, 13 Jun 2025 15:16:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014452.1392537; Fri, 13 Jun 2025 15:16: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 1uQ68z-0000Km-IK; Fri, 13 Jun 2025 15:16:37 +0000
Received: by outflank-mailman (input) for mailman id 1014452;
 Fri, 13 Jun 2025 15:16: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 1uQ68y-0000Kb-8J
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 15:16:36 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on2062c.outbound.protection.outlook.com
 [2a01:111:f403:2418::62c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 63fa5fde-4869-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 17:16:34 +0200 (CEST)
Received: from DS7PR03CA0111.namprd03.prod.outlook.com (2603:10b6:5:3b7::26)
 by PH8PR12MB7207.namprd12.prod.outlook.com (2603:10b6:510:225::14) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.39; Fri, 13 Jun
 2025 15:16:30 +0000
Received: from DS1PEPF0001709C.namprd05.prod.outlook.com
 (2603:10b6:5:3b7:cafe::f9) by DS7PR03CA0111.outlook.office365.com
 (2603:10b6:5:3b7::26) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.23 via Frontend Transport; Fri,
 13 Jun 2025 15:16:30 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 DS1PEPF0001709C.mail.protection.outlook.com (10.167.18.106) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Fri, 13 Jun 2025 15:16:29 +0000
Received: from xcbagarciav01.xilinx.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; Fri, 13 Jun
 2025 10:16:25 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 63fa5fde-4869-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=yZdnn4bhRWDNMX0veTAmEZ5l1LcxegyhULNPpM9iVtnuMJZ3Pua2T+0Q+yB3seGu/07GCF0jV0SJ40/774KIICcYjcicP0lIiYe3zaHWycps67dQFIpRJqiwpwH6tdTGS22+cd8Fh2tu2Q6+8/xUbkMewjmz3P0HFUXS6S2bzAR3Y8Dz50GwY6AXsI/zQRyIJ6Z/Psmig/Kynl8bCsbQgt0L8ZveCKda80aOwe5JGScbyOWbJocWtcwsdaWtokT1LTK2hqCN1+UukJekkL1wju1jgSBKlcxvj3ARXDDrOePn/FZTfqBrheMNodZBeAZorFey2W9/z1MfE5VutTThpQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=T/8591m6gZeWmotQSP3G4jc9QpcD9wa9uKHTk1MKAeE=;
 b=KylRfBAFSklOYh7Pg4S9RVcWZT7NAtH+9qAvmi8M2CQwxJMeTnrt2YXACrndz2wnweF7zf2cAliMFcicj4ZznbnTz2dykm7jpZ04iEUQou2pPZE6yIsn2+v+BULMy4yXHVWPSaEcuNdiqF6Cdph+gPDKYeAOHx5HKHehSy0qw0p0OVUcJfmemyYjmxFTfj3fAov7kMEhbumOh0U3X+UPf/2HunGl0gFikdArYog1ALfQw6wqnLAAbMGdHvTSHws/VNxrRn/UPGltw9KqqphkWUHcSQeGHu2UoFT4qg5EnV0mLjH9nkqCJpK30si28EVu/l4jnCbYO4blVV+asZbqfw==
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=T/8591m6gZeWmotQSP3G4jc9QpcD9wa9uKHTk1MKAeE=;
 b=v+wlxwJcIhMHNDQTWI+bOiT9YkwDZAohIrxWK6YyBN6YtDZDfZxlClHlKt6uhduxf9uBaeWA5FvyzWapSSVKCh6ZOJrd8t47HsALtBB/j0TiWTjVbiGeqHE87E4ks3ChBCf73K0un/p8oEK96qbeSDiLUndbd3+GmiFHzuPU93Y=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , Jan Beulich ,
	"Andrew Cooper" ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Anthony PERARD
	, "Daniel P. Smith"
	, Alistair Francis ,
	Bob Eshleman , "Connor Davis"
	, Oleksii Kurochko 
Subject: [PATCH v3 00/15] Allow x86 to unflatten DTs
Date: Fri, 13 Jun 2025 17:13:09 +0200
Message-ID: <20250613151612.754222-1-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: 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: DS1PEPF0001709C:EE_|PH8PR12MB7207:EE_
X-MS-Office365-Filtering-Correlation-Id: 83ccd0ce-eef2-4384-5bf0-08ddaa8d45e9
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|82310400026|376014|7416014|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?TiSrziEbtFuH1/nN9jUroWzaGdbSiixjRJZBLFU5r/GybdYiCha1NNk8n/ou?=
 =?us-ascii?Q?ZKJK6GTWK1dvayQzgBXwzZl53upT/QBl0B68mhbkFtgXu3gx+fkPEs+lmUzs?=
 =?us-ascii?Q?jipUwkXOO3GQJYruKdH811J4a8T+RwghjCOTTS4/arC9wOuzgN8lGQpZVRqK?=
 =?us-ascii?Q?qJZ74+4T8+Zcs0sV/4eAghaWZtg64DtHcdh637MY9w2dcj/0/Efv5ggfFMmD?=
 =?us-ascii?Q?Euxi6k1mVGJ6cmAeq2JBFshC4THNTNX/A15LFmizq/2zh1ipW98mWI1y4GFS?=
 =?us-ascii?Q?Me2VzSzJoFGhE9hYP2B20zUIxJUpfm/cdLH/EFLfFXfCedU4Er7L/55htrR5?=
 =?us-ascii?Q?hj+GT6BCtXYAIZSBm8e9AhkD/pP9fVYmFryO4eFNrJqGw6rTvqJasnSsiQpI?=
 =?us-ascii?Q?bYZSaY0Vr3z5/9Y/js5Kaj8T6GunuRs4s5i1VK/fS/IyjYqKXA6RQpZppycw?=
 =?us-ascii?Q?Bx16yQejDguj8oKbgwLdoxRJ/P4Yzcy0RJB+K4v1FO2U0eT1j8gHehm/oDtE?=
 =?us-ascii?Q?pZU64joRY9HiOF7t5ImreGyUYHQlG0sf0IWpqnaN6mFnqzG1WfVRXwzkyZtb?=
 =?us-ascii?Q?cZ9nnGzoCGspbhlF5/iU5K1z7ZhEt6A88cLjreH4LGLNinLSj47XWvnwolYl?=
 =?us-ascii?Q?kFMuSqZ/puNnx37KbUurgoH8dvDOD4mcLMaPzELd5raZ6zrDrYk/xg5blTSu?=
 =?us-ascii?Q?1MA5ssS0cSsrF/fDc8mMu11MBiD5jbpMvOxO0Z4ZMmLJ5OQ2BLtm3PFGBpoA?=
 =?us-ascii?Q?plWkezDzQ48q67mMXCOhDZcLntdzcCi8lB/9ZtHy0FQodNcGY38YflmG8lkX?=
 =?us-ascii?Q?Br/HoIn/ZlSHIHQwZXxblas/aBQ9gf659PphZy8GJX/rGuRq77A8he2AwsfF?=
 =?us-ascii?Q?xyQG57lw4N0lz8eYG2lPywLZEIB900/sCqxwQzgVfJI8/HThwNOkzZmKpKW8?=
 =?us-ascii?Q?r6718wj3zcu8mZTjyS+U1wsCqar7kQ0e75Aaey6847LiQVfUdNhltG+OL42d?=
 =?us-ascii?Q?pRYhuuCJCybU9lgw7Fh/4P0+TO8+d/hNCuladMUjxwv+vcWmJsYUEaQiIsNf?=
 =?us-ascii?Q?h9u2ZM0U9u+7Uu9obcI3eTEfdZa0+FzVpiHBhDsSsrxhuGQ8LVe+9bzHtL2T?=
 =?us-ascii?Q?9cEU6XxOBsKc1Uyvv49OB70fzKrnOXQlE0ojZSGp2kU7uQivOMjef+RbfAEg?=
 =?us-ascii?Q?eob4T97ZFj3MqDZ4w08p7dqQSyEpa53UvPC3/+uIjn0ZbQeJpz1V2NrKFTwR?=
 =?us-ascii?Q?UNgGZqan+z7czIdDR86wLdkNjRIu89B/c8c6Rr2CG29KvxzuEg7hJDY4vqVq?=
 =?us-ascii?Q?gIa466CFuk+17pER/Va76w2psJkokYFG8YRLFbGv0/JeNgIDWFNJ4cPt0d8r?=
 =?us-ascii?Q?b5UZ2Ln+pepNV1PtcMlNq9SwJnYG0tnXGb87KBwVFsjZX3uJ8wufP0lNEMzu?=
 =?us-ascii?Q?gY3lflBvi/A9ewilRVcjxj0tTN4/ynZzwxGKuS8xBo4qwDk7VsWYhQ=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)(82310400026)(376014)(7416014)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jun 2025 15:16:29.5718
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 83ccd0ce-eef2-4384-5bf0-08ddaa8d45e9
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:
	DS1PEPF0001709C.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7207

Hi,

New summary when compared to v2:

  * Patches 1 and 2 are just cleanup
  * Patch 3 is a modification of the CODING_STYLE to reflect the unwritten rule
    of splitting type names in words.
  * Patch 4 is a rename of struct bootmodule{,s} to boot_module{,s}, in accordance
    to the modification of patch 3. 
  * Patch 5-7 replaces x86-specific boot_{domain,module} defs in favour of
    common ones.
  * The rest are code motion and enablement of x86 to unflatten DTs and use
    some dom0less helpers.

v3 pipeline: https://gitlab.com/xen-project/people/agvallejo/xen/-/pipelines/1868636712

v2: https://lore.kernel.org/xen-devel/20250605194810.2782031-1-agarciav@amd.com/
v1: https://lore.kernel.org/xen-devel/20250530120242.39398-1-agarciav@amd.com/

Original cover letter:

This is the aftermath of this discussion:

  https://lore.kernel.org/xen-devel/DA1WWRUQLCAG.ZTVR1HXJ85V0@amd.com/https://lore.kernel.org/xen-devel/DA1WWRUQLCAG.ZTVR1HXJ85V0@amd.com/

It's a first round of cleanup and preparation to have a much easier time
later when integrating dom0less boot into hyperlaunch.

The refactor on device-tree/ is _fine_ by I'm open to other suggestions
to achieve the same thing. In particular, after this series x86 can
unflatten the DT host device tree when it has CONFIG_DOM0LESS_BOOT set,
which enables the builder to use factored-out functions from
dom0less-build.c (not done here).

The diffstat is deceptive because I renamed a large file and then
created a new file with the same name. There aren't that many LoC
changes.

Alejandro Vallejo (14):
  arm/gnttab: Remove xen/grant_table.h cyclic include
  x86: Preinitialise all modules to be of kind BOOTMOD_UNKNOWN
  CODING_STYLE: Custom type names must be snake-cased by word.
  xen: Rename bootmodule{,s} to boot_module{,s}
  x86: Replace arch-specific boot_module with common one
  xen: Refactor kernel_info to have a header like boot_domain
  x86: Replace arch-specific boot_domain common one bootdomain
  xen/dt: Move bootfdt functions to xen/bootfdt.h
  xen/dt: Move bootinfo functions to a new bootinfo.h
  xen/dt: Rename bootfdt.c -> bootinfo-fdt.c
  xen/dt: Extract helper to map nodes to module kinds
  xen/dt: ifdef out DEV_DT-related bits from device_tree.{c,h}
  xen/dt: Allow CONFIG_DOM0LESS_BOOT to include device-tree/
  kconfig: Allow x86 to pick CONFIG_DOM0LESS_BOOT

 CODING_STYLE                            |   3 +
 xen/arch/arm/dom0less-build.c           |   8 +-
 xen/arch/arm/domain_build.c             |  21 +-
 xen/arch/arm/efi/efi-boot.h             |   6 +-
 xen/arch/arm/include/asm/grant_table.h  |   1 -
 xen/arch/arm/kernel.c                   |  10 +-
 xen/arch/arm/llc-coloring.c             |   8 +-
 xen/arch/arm/mmu/setup.c                |  10 +-
 xen/arch/arm/setup.c                    |  11 +-
 xen/arch/riscv/mm.c                     |   2 +-
 xen/arch/riscv/setup.c                  |   2 +-
 xen/arch/x86/Kconfig                    |   1 +
 xen/arch/x86/cpu/microcode/core.c       |   7 +-
 xen/arch/x86/hvm/dom0_build.c           |   8 +-
 xen/arch/x86/include/asm/boot-domain.h  |  33 --
 xen/arch/x86/include/asm/bootfdt.h      |  56 ++
 xen/arch/x86/include/asm/bootinfo.h     |  57 +--
 xen/arch/x86/pv/dom0_build.c            |   6 +-
 xen/arch/x86/setup.c                    |  58 ++-
 xen/common/Kconfig                      |  13 +-
 xen/common/Makefile                     |   2 +-
 xen/common/device-tree/Makefile         |   9 +-
 xen/common/device-tree/bootfdt.c        | 654 ++----------------------
 xen/common/device-tree/bootinfo-fdt.c   | 583 +++++++++++++++++++++
 xen/common/device-tree/bootinfo.c       |  54 +-
 xen/common/device-tree/device-tree.c    |   2 +
 xen/common/device-tree/dom0less-build.c |  45 +-
 xen/common/device-tree/domain-build.c   |  22 +-
 xen/common/device-tree/kernel.c         |  30 +-
 xen/include/xen/bootfdt.h               | 277 +++-------
 xen/include/xen/bootinfo.h              | 213 ++++++++
 xen/include/xen/device_tree.h           |  44 +-
 xen/include/xen/fdt-domain-build.h      |   2 +-
 xen/include/xen/fdt-kernel.h            |  12 +-
 xen/xsm/xsm_policy.c                    |   4 +-
 35 files changed, 1162 insertions(+), 1112 deletions(-)
 delete mode 100644 xen/arch/x86/include/asm/boot-domain.h
 create mode 100644 xen/arch/x86/include/asm/bootfdt.h
 create mode 100644 xen/common/device-tree/bootinfo-fdt.c
 create mode 100644 xen/include/xen/bootinfo.h

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 15:16:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 15:16:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014454.1392557 (Exim 4.92)
	(envelope-from )
	id 1uQ691-0000mb-Bo; Fri, 13 Jun 2025 15:16:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014454.1392557; Fri, 13 Jun 2025 15:16: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 1uQ691-0000mS-6v; Fri, 13 Jun 2025 15:16:39 +0000
Received: by outflank-mailman (input) for mailman id 1014454;
 Fri, 13 Jun 2025 15:16: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 1uQ68z-0000Kb-Sa
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 15:16:37 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on2062d.outbound.protection.outlook.com
 [2a01:111:f403:2009::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6596cc6a-4869-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 17:16:37 +0200 (CEST)
Received: from DS7P220CA0027.NAMP220.PROD.OUTLOOK.COM (2603:10b6:8:223::19) by
 LV3PR12MB9213.namprd12.prod.outlook.com (2603:10b6:408:1a6::20) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.25; Fri, 13 Jun
 2025 15:16:33 +0000
Received: from DS1PEPF00017097.namprd05.prod.outlook.com (2603:10b6:8:223::4)
 by DS7P220CA0027.outlook.office365.com (2603:10b6:8:223::19) with
 Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.25
 via Frontend Transport; Fri, 13 Jun 2025 15:16:33 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 DS1PEPF00017097.mail.protection.outlook.com (10.167.18.101) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Fri, 13 Jun 2025 15:16:33 +0000
Received: from xcbagarciav01.xilinx.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; Fri, 13 Jun
 2025 10:16:31 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6596cc6a-4869-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=PL0V2z8o5prrW1Cf1eeiZXc8sbVqT9pxgIm1pTQwxCYt05f5GZAhjOS4SJuuraIsvRTutWmOfMjO6FNC2bEBBBn4J0NWb7PILO4k2yOHN+18xzwUQlVirLgEMcfy5bNmXH82yrEI30eWT3eoR3qjaQh2MHD94ebRuku/S5EU6po3eIYjnCjihZCum+lMxFLGYSR0jC5bP0DxL3+0ZPjS3BN3ocv+woSaRj3lz8LOKemunmyayu9GyDqWVVrfj0Cz08G3xGWe0ZY3wMr3WOhbXedTvi/Mkj2xx7m4mNCEpb+pGqXDXj4QpIeppKFxbVtuxXTkvPzFrO/IGD0bKRcAXg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=weLNhDghvy5grqCkI6xfefJ+ZcBJH01riMFjQPWY3SQ=;
 b=rg3iR9obO+3DfB2X3XjRuPnZEYzJI+k+ln3Vn5v7bvrbm6OHmov6PBG74zz2gURNbct94VhVTuKio9zv7UDD9PtA510RmoPj1Jc+aCij6hSw2P0qV3CCP+HjOIaTVQsM5oQ9+K70fSmW5DhpnodEpbdCxYCqqcx6E7Dh888M/+dxstRPcq5mooMcUFs93y/ZXWPAC+M8QDdDg6bPhl2U9gw6IVKGjacrJx70lLCSzjlSAQsNZDuJ0zzjriEK60Z1ErxMAcnbfyx2Pb8sRtrOeB7jdT6+GZ+XrIPjMUWs0w1+qKfj/LwkBe5jGIggy/GPhKcWovVgvorYZz/sUaIuoQ==
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=weLNhDghvy5grqCkI6xfefJ+ZcBJH01riMFjQPWY3SQ=;
 b=Ho5yUoYCeF618xshs+XqbtZcoV05lOxqS8w9jlDL8GzWBIK/Cw9Ax6dweWcKuh0E7PrwTmI+1gjWCvjCNenl6bz/G184c3fZ5wArD0TdiZk2X6S0bSXV6mEh9IdARiJIHRhWA0zF2bwVHxQu4nplwyG0zhjWhr7k2S6b9eTcqTg=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Daniel P.
 Smith" , Stefano Stabellini
	
Subject: [PATCH v3 02/14] x86: Preinitialise all modules to be of kind BOOTMOD_UNKNOWN
Date: Fri, 13 Jun 2025 17:13:11 +0200
Message-ID: <20250613151612.754222-3-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250613151612.754222-1-agarciav@amd.com>
References: <20250613151612.754222-1-agarciav@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: DS1PEPF00017097:EE_|LV3PR12MB9213:EE_
X-MS-Office365-Filtering-Correlation-Id: 8765acaf-6d40-4e83-d936-08ddaa8d484f
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?SYnjCFW3hzLciSSYT6u+o9ik1rUWS/0yiYogc9giHG5wPxKA7Rf/N41EzVzq?=
 =?us-ascii?Q?60HF5jmH7TptQHBLrpwoTXng/Fbx5lM4DFTgCXYjjdLgwMrO+z2PegkFJJUJ?=
 =?us-ascii?Q?lrpFocTNKIXZlQPQ7LgDnCU+FT/KntNS4pSSxDT73XrUnVbkTN+J9y6yuZHz?=
 =?us-ascii?Q?519pbcdNKIucZnVAjrG906RhhLLDR8BzMoqyO4x1SLu8dqVhCcQhQTroFSeq?=
 =?us-ascii?Q?SLO73nPoSqy/ChVqkQjHdd3+gdLij+zENJDcZxF6YSvsKPOQkBdiT9EPemsA?=
 =?us-ascii?Q?AEYY7m0qXgHNDEzQOc3RA5RNFjgv2aCf613cNSj+VGvKgIScr0ogQ5Rz/7CQ?=
 =?us-ascii?Q?nFQ8nsKjO8V3PBoyrAf92uTKfYJlMA3r55/u50GSJECJcpAyiNDFSrqkMX96?=
 =?us-ascii?Q?tDvFMY8auUk5K9Ya35tQGsJA88dGvloff395ghRIc+aCce/urQilQABD3+B0?=
 =?us-ascii?Q?sf5psqkXaHwpY3R4Yi5Yh/+AvW4eUYsoEb7V8nRCxayBYEZdEMe9th6GO5mJ?=
 =?us-ascii?Q?5cMMs53uQEca85OHCIrY33FgswyqP2AF+4HFlY/Xbe9eONWtBhJIVPS3+8Rx?=
 =?us-ascii?Q?agS9SEHBpa36lYbwF/4eKfwqXPj4I7p64wXJcDoOdYCskel9vifEI6sQITZw?=
 =?us-ascii?Q?Lawgvfrr8dQwte7LzOICiF1Klx6Uc/6BG1UaCcjS8JvY0OzrRzO3I34P4RdU?=
 =?us-ascii?Q?bpe9vFyD6iB+aMq7cT1JPRFa77SGdc4gRnoPrDbdXL760Cn07NJdRNpN25Ti?=
 =?us-ascii?Q?2Lt4iwdVA4EccvAgxTdxFPGcAtNXog5eQdOCj/ZV5TSV3WAgvL0a+uMuzJH/?=
 =?us-ascii?Q?a112Zq1PVqd7DEVEzHhGy8/I0Kw9MbeRJLPfav3daNcaNlJzcXPZJeGxxd/1?=
 =?us-ascii?Q?zVaxFQiqOSbFzFysaAPCFmCKq82qu+psRC4A5ZMUyWo9E6bGx/THazzDmzkH?=
 =?us-ascii?Q?7PCkJMDVlBvmIQBLkOUEBU143SLa2/CXuIRgEB+NlxNwWJ49pxuoppmLuKG1?=
 =?us-ascii?Q?5m0u95W4YiFipRP3oOwFC4ojpNeTjHjuXsSqScORcX37oOuAJ8Moc4QS8wjq?=
 =?us-ascii?Q?nYMtAadj34CtxP8g3cGtetQxlqYXLcg8iR4oloBXTMJTQjeBYfEACKXlO4bD?=
 =?us-ascii?Q?s9UGd1011IjgN5zVCcrydMUmHQTnpSi/DrLOPhS37P6aYe4x7GL6bn+9IuZO?=
 =?us-ascii?Q?rRCZfkMg8w6vJ2foIv9nWVUkl+MDwg6BasAal3XNQTAxOJ7QD/jf2CjHrKE7?=
 =?us-ascii?Q?1MJePGYUXbTX9VXH11rVrEOVWCoHHf16rYrX6REYhTUfcXvgaUiLCMCJH+kg?=
 =?us-ascii?Q?YUhfu0erWFtlq+H6ivXFeAWtt6vSEybhAHWFFMN/uFednvLGIDnB3V2lbdid?=
 =?us-ascii?Q?2cEINmIU7LDycj57P4ZGnznOLgTSPnUhhs49tMTnCu8Hb4tDkkrZvRsGA0gX?=
 =?us-ascii?Q?WE4PYFb8QRVwgZI2sohQgXcBxQ9EbzTSRTVuBqm1jRb4ULHqYcEVKvItetn/?=
 =?us-ascii?Q?VPfQ5sDg1QQLmZDTfVK6H8lD4JaZfwD6z6Qm?=
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: 13 Jun 2025 15:16:33.5969
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 8765acaf-6d40-4e83-d936-08ddaa8d484f
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:
	DS1PEPF00017097.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR12MB9213

A later patch removes boot_module and replaces its uses with bootmodule.
The equivalent field for "type" doesn't have BOOTMOD_UNKNOWN as a zero
value, so it must be explicitly set in the static xen_boot_info.

Not a functional change.

Signed-off-by: Alejandro Vallejo 
Reviewed-by: Stefano Stabellini 
---
 xen/arch/x86/setup.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 1f5cb67bd0..7d3b30e1db 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -298,6 +298,12 @@ struct boot_info __initdata xen_boot_info = {
     .loader = "unknown",
     .cmdline = "",
     .domains = { [0 ... MAX_NR_BOOTDOMS - 1] = { .domid = DOMID_INVALID } },
+    /*
+     * There's a MAX_NR_BOOTMODS-th entry in the array. It's not off by one.
+     *
+     * The extra entry exists to be able to add the Xen image as a module.
+     */
+    .mods = { [0 ... MAX_NR_BOOTMODS] = { .type = BOOTMOD_UNKNOWN } },
 };
 
 static struct boot_info *__init multiboot_fill_boot_info(
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 15:16:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 15:16:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014458.1392577 (Exim 4.92)
	(envelope-from )
	id 1uQ699-0001PO-P4; Fri, 13 Jun 2025 15:16:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014458.1392577; Fri, 13 Jun 2025 15:16:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uQ699-0001PE-Lz; Fri, 13 Jun 2025 15:16:47 +0000
Received: by outflank-mailman (input) for mailman id 1014458;
 Fri, 13 Jun 2025 15:16: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 1uQ698-0001Mm-89
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 15:16:46 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on2061c.outbound.protection.outlook.com
 [2a01:111:f403:2416::61c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 68e860fb-4869-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 17:16:43 +0200 (CEST)
Received: from DM6PR08CA0031.namprd08.prod.outlook.com (2603:10b6:5:80::44) by
 BY5PR12MB4162.namprd12.prod.outlook.com (2603:10b6:a03:201::11) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.25; Fri, 13 Jun
 2025 15:16:39 +0000
Received: from DS1PEPF0001709B.namprd05.prod.outlook.com
 (2603:10b6:5:80:cafe::b5) by DM6PR08CA0031.outlook.office365.com
 (2603:10b6:5:80::44) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.22 via Frontend Transport; Fri,
 13 Jun 2025 15:16:38 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 DS1PEPF0001709B.mail.protection.outlook.com (10.167.18.105) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Fri, 13 Jun 2025 15:16:38 +0000
Received: from xcbagarciav01.xilinx.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; Fri, 13 Jun
 2025 10:16:35 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 68e860fb-4869-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=eIaGggADv+g05F0/qIkRzvOLCE1t+yaKqRYWC0y6PUzT9mJgbTbKAxojPW8oU575iJ5Oi7jQJ8Y1n7x7++6q10r57/EzymV162Su3o8fM64adkKpCEmI75RGdl9hKFC/2ih8Gjd6f+tNpI9Qmu9NQBEKsUpuBC3cgO+Hp56vUVRsQdRBQVyEJHU6KBI5/5UiV3Q0RintV9DDOd6+FZ6HO3NWcPXsd2pj//12ALUY+xQGi3y2ftHKczRtxqpBhgOhJYS//O1EHU+BQQJv2hUdlAtsAZEWtWU84kPG7n0+jmaMuAEW92vzuf3pvmSUtH43vaMvaTLIfkQTdIViFJpBxQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=zJfJ8Dj29Mew3Bg03ew0zBBwme1Opwmqo96cBga08KU=;
 b=YHYE1Nnd8jsi2bLogTaWULt8SREjZpIevbV8Gy65mRpsLg5t7x2cKX3R+/PKiHH2xlWQ0bqmtl9nAsLblNu5d+nwSrpmTv5fTwxCUxQbDnNuyJxaCJjjbitG5vHtUkFOW3V/+zWQtiY5IYp/OaxpYwyesWBwH5q0DmBWy2Ye/CkEgmmHsXh5xrixgEvA5ZfEJ7DX1X4dY7dg2xXW7iBGFubj9k0rCEl1cLqZy80C+Ynd1irA0lPwupi2/4Kz4H+pKU87txatm3TcG1XA2ORr2bpkXAJO87LtMktf2ZgSj1esBAXOO/mUIQg651DMzAImlgz9Jg8aw+/rIaq13f9miQ==
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=zJfJ8Dj29Mew3Bg03ew0zBBwme1Opwmqo96cBga08KU=;
 b=MfxxyIrjNtikKpMM3qlznh38+CejDRJ9si3Gd4HUboLu1ZLn1njCP6AvUW4Kivnu6BNIjsMjshhy0E79DqBA7VCHcQGhnd8gUlJ5Si7/iK/ePJclY7kmG6X4EabxwkmxYA1WYEPhteNqAaWsouoAE6Uj9bCTJ5RJ5LG+v0OXnRc=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , Andrew Cooper
	, Anthony PERARD , "Jan
 Beulich" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, "Daniel P. Smith" 
Subject: [PATCH v3 04/14] xen: Rename bootmodule{,s} to boot_module{,s}
Date: Fri, 13 Jun 2025 17:13:13 +0200
Message-ID: <20250613151612.754222-5-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250613151612.754222-1-agarciav@amd.com>
References: <20250613151612.754222-1-agarciav@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: DS1PEPF0001709B:EE_|BY5PR12MB4162:EE_
X-MS-Office365-Filtering-Correlation-Id: 367f0235-8ea3-4a17-4637-08ddaa8d4b6d
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?76pQZLmgNHLTTBVnjUmVlm6JIY2joOCGdd2KgUz0E4EPi32mcYKRPqOVwsuS?=
 =?us-ascii?Q?xxfUI24XV9P/rw41ng73FBIo8pQE92iYa+J/gdj9+XJg2LH0sj8j/ZSPgNbk?=
 =?us-ascii?Q?jb9jeAna3NuACQKcG7prFtkTazvcKH4LDlyKtnNFLOetrKW/POkN943BVLwD?=
 =?us-ascii?Q?6R2ILy/rbKutiC/K91WBEDLV7L5BmW128Y2M7bL6KTmSoluhKxZt8K70bDhK?=
 =?us-ascii?Q?qnPkdg7IzAdiyxPZmpvlWAxqHabjstNscxCD8h8zusNefKTuBo/AdnJZa4+l?=
 =?us-ascii?Q?H+jLI275Oq/QB53zpxDrgq9tpmBJkTAlYZY1W/kqQIy0sw1Z5A4q5SyB+6Eq?=
 =?us-ascii?Q?R+yVWWh8CHxXMg28t5zxjdcG+MSHMH1tw71sJJZW/iQV6kd0i+hNb2A93/Dj?=
 =?us-ascii?Q?+3zGXaCPSaXCZChcLR1YkXXerOI9L/Xo4ZuLqBG0N6MR9GDutmoERR1+OeR8?=
 =?us-ascii?Q?o8JBinS8ivl2oi+JExOH26LTE1VxdtbvgOTCsEGm4dX15RH33Ve9WO9tWuzl?=
 =?us-ascii?Q?ARxmw1b6wIq16K3U+oJvIjq83HX+utT+iak+wUc2HrAqNUfjHvfOfbBFuojf?=
 =?us-ascii?Q?UQf/Rgxy1wIDlpPNe0y9UWZWwJkCTPCSU6S9hbFGjYOfy0s0v/tDLfuGh9VX?=
 =?us-ascii?Q?J1HyetoetC5QMNAjE+M79S0iaNb8fKvVj2sNGHOei8QYsZgdBtq8PYp+bUlC?=
 =?us-ascii?Q?MSejROZSpxlTlIE6uh3kGpkahtiB+ULAy5FjpcP5q5dbWUcu4Ck35RRIFTM8?=
 =?us-ascii?Q?Sk134H/xMX6XH5QKXg0hzwE56GGU8sVMz+nqv3WjO39OqN/CgLRbWa16tnpP?=
 =?us-ascii?Q?xm5vJTD9fZ0P4V1eKyqONAwcCFuopd0QGbcMJpFq9gmg50ZKBQGHBoX/6ofW?=
 =?us-ascii?Q?JCthiXaHJTE5/mI7oEPZlt4tf5oqvPAJhoL8KaVsoMkG1vco0Olgc5ociGc6?=
 =?us-ascii?Q?+ur/DzlIcFmjA8humZa4FoB2JIHKmPOSeoWNCf1zuYzU068UCFZugCohHWMD?=
 =?us-ascii?Q?09isn8w0u29TclmNjfOn8RLfP6El6G7XWtp0vuZmT1khhtdPU0Dn3W7pR8lF?=
 =?us-ascii?Q?T9SjE89oTERrSKkhD7wvwPmWUEJ6UXon182ao+zDlQ1tzFQs+okOWMmZ3eWb?=
 =?us-ascii?Q?Pp1SoJErGYq/r7BckYhSqCyh69V5DbhQvWBEuZLxNd0S9mlmz6sP7b3tovTM?=
 =?us-ascii?Q?UwTeMzsXrGTpS0zsf21cqoxVwRpXgnP5FlywSf1ofxUg6hPS5r8TF8Tngrdb?=
 =?us-ascii?Q?jZMZ+3LFxUcQ9+j5IGLX2j3MWBOxQDH6F9Cy3o9oD7sKC04u8mNDZTL7uO1M?=
 =?us-ascii?Q?5CqmMjLWiaVQe0GueoK2l4qT+yauQyhJC1ymQt9YHrKaJ4XNlRLsedP6TFmp?=
 =?us-ascii?Q?skhcY/EcU8x7cww4h85J9TAe9xBUXsk/6SXOf7ubQT4wJfIRDZoOUGhtDxnN?=
 =?us-ascii?Q?5/Ef+6EDqehDM6gLYgZ13Nhy4Q4+exELjGY7uL5cJ/gDBHtwHkjuNfp+PRNd?=
 =?us-ascii?Q?ejUY2sr0HTfBsdP7J80whgLrrWVbCIQboGDv?=
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: 13 Jun 2025 15:16:38.8236
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 367f0235-8ea3-4a17-4637-08ddaa8d4b6d
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:
	DS1PEPF0001709B.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4162

... in alignment with the new coding style on word splitting for type
names.

This aligns its name with the largely duplicate boot_module struct
in x86. While there's no equivalent to "struct bootmodules" in x86,
changing one and not the other is just confusing. Same with various
comments and function names.

Rather than making a long subfield name even longer, remove the
_bootmodule suffix in the kernel, initrd and dtb subfields.

Not a functional change.

Signed-off-by: Alejandro Vallejo 
---
 xen/arch/arm/domain_build.c             |  4 +-
 xen/arch/arm/efi/efi-boot.h             |  6 +--
 xen/arch/arm/kernel.c                   |  4 +-
 xen/arch/arm/llc-coloring.c             |  8 ++--
 xen/arch/arm/mmu/setup.c                | 10 ++---
 xen/arch/arm/setup.c                    | 10 ++---
 xen/common/device-tree/bootfdt.c        |  4 +-
 xen/common/device-tree/bootinfo.c       | 52 ++++++++++++-------------
 xen/common/device-tree/dom0less-build.c | 25 ++++++------
 xen/common/device-tree/domain-build.c   |  2 +-
 xen/common/device-tree/kernel.c         | 22 +++++------
 xen/include/xen/bootfdt.h               | 26 ++++++-------
 xen/include/xen/fdt-kernel.h            |  7 ++--
 xen/xsm/xsm_policy.c                    |  2 +-
 14 files changed, 90 insertions(+), 92 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 590f38e520..7096e176ed 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -579,7 +579,7 @@ static int __init write_properties(struct domain *d, struct kernel_info *kinfo,
 
     if ( dt_node_path_is_equal(node, "/chosen") )
     {
-        const struct bootmodule *initrd = kinfo->initrd_bootmodule;
+        const struct boot_module *initrd = kinfo->initrd;
 
         if ( bootargs )
         {
@@ -1447,7 +1447,7 @@ int __init make_chosen_node(const struct kernel_info *kinfo)
 {
     int res;
     const char *bootargs = NULL;
-    const struct bootmodule *initrd = kinfo->initrd_bootmodule;
+    const struct boot_module *initrd = kinfo->initrd;
     void *fdt = kinfo->fdt;
 
     dt_dprintk("Create chosen node\n");
diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
index d2a09ad3a1..2af8e8ea05 100644
--- a/xen/arch/arm/efi/efi-boot.h
+++ b/xen/arch/arm/efi/efi-boot.h
@@ -20,7 +20,7 @@ typedef struct {
 } module_info;
 
 /*
- * Binaries will be translated into bootmodules, the maximum number for them is
+ * Binaries will be translated into boot_modules, the maximum number for them is
  * MAX_MODULES where we should remove a unit for Xen and one for Xen DTB
  */
 #define MAX_UEFI_MODULES (MAX_MODULES - 2)
@@ -602,9 +602,9 @@ static void __init efi_arch_handle_module(const struct file *file,
 
     /*
      * modules_available is decremented here because for each dom0 file added
-     * from the configuration file, there will be an additional bootmodule,
+     * from the configuration file, there will be an additional boot_module,
      * so the number of available slots will be decremented because there is a
-     * maximum amount of bootmodules that can be loaded.
+     * maximum amount of boot_modules that can be loaded.
      */
     modules_available--;
 }
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index cb1efb19e7..e734ec5c1e 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -46,7 +46,7 @@ static void __init place_modules(struct kernel_info *info,
                                  paddr_t kernbase, paddr_t kernend)
 {
     /* Align DTB and initrd size to 2Mb. Linux only requires 4 byte alignment */
-    const struct bootmodule *mod = info->initrd_bootmodule;
+    const struct boot_module *mod = info->initrd;
     const struct membanks *mem = kernel_info_get_mem(info);
     const paddr_t initrd_len = ROUNDUP(mod ? mod->size : 0, MB(2));
     const paddr_t dtb_len = ROUNDUP(fdt_totalsize(info->fdt), MB(2));
@@ -175,7 +175,7 @@ static void __init kernel_zimage_load(struct kernel_info *info)
  * Check if the image is a uImage and setup kernel_info
  */
 int __init kernel_uimage_probe(struct kernel_info *info,
-                               struct bootmodule *mod)
+                               struct boot_module *mod)
 {
     struct {
         __be32 magic;   /* Image Header Magic Number */
diff --git a/xen/arch/arm/llc-coloring.c b/xen/arch/arm/llc-coloring.c
index 99ac10b610..6f78817c57 100644
--- a/xen/arch/arm/llc-coloring.c
+++ b/xen/arch/arm/llc-coloring.c
@@ -123,12 +123,12 @@ static paddr_t __init xen_colored_map_size(void)
 
 void __init arch_llc_coloring_init(void)
 {
-    struct bootmodule *xen_bootmodule = boot_module_find_by_kind(BOOTMOD_XEN);
+    struct boot_module *xen_boot_module = boot_module_find_by_kind(BOOTMOD_XEN);
 
-    BUG_ON(!xen_bootmodule);
+    BUG_ON(!xen_boot_module);
 
-    xen_bootmodule->size = xen_colored_map_size();
-    xen_bootmodule->start = get_xen_paddr(xen_bootmodule->size);
+    xen_boot_module->size = xen_colored_map_size();
+    xen_boot_module->start = get_xen_paddr(xen_boot_module->size);
 }
 
 /*
diff --git a/xen/arch/arm/mmu/setup.c b/xen/arch/arm/mmu/setup.c
index 30afe97781..eb8ed19ca1 100644
--- a/xen/arch/arm/mmu/setup.c
+++ b/xen/arch/arm/mmu/setup.c
@@ -246,7 +246,7 @@ paddr_t __init consider_modules(paddr_t s, paddr_t e,
 #ifdef CONFIG_STATIC_SHM
     const struct membanks *shmem = bootinfo_get_shmem();
 #endif
-    const struct bootmodules *mi = &bootinfo.modules;
+    const struct boot_modules *mi = &bootinfo.modules;
     int i;
     int nr;
 
@@ -273,8 +273,8 @@ paddr_t __init consider_modules(paddr_t s, paddr_t e,
     }
 
     /*
-     * i is the current bootmodule we are evaluating, across all
-     * possible kinds of bootmodules.
+     * i is the current boot_module we are evaluating, across all
+     * possible kinds of boot_modules.
      *
      * When retrieving the corresponding reserved-memory addresses, we
      * need to index the reserved_mem bank starting from 0, and only counting
@@ -328,8 +328,8 @@ 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;
+    struct boot_module *xen_boot_module = boot_module_find_by_kind(BOOTMOD_XEN);
+    mfn_t start_mfn = maddr_to_mfn(xen_boot_module->start), mfn;
 
     for_each_xen_colored_mfn ( start_mfn, mfn, i )
     {
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 734e23da44..8b2e65a1a5 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -206,11 +206,11 @@ static void __init processor_id(void)
 
 void __init discard_initial_modules(void)
 {
-    struct bootmodules *mi = &bootinfo.modules;
+    struct boot_modules *mi = &bootinfo.modules;
     int i;
 
     /*
-     * When using static heap feature, don't give bootmodules memory back to
+     * When using static heap feature, don't give boot_modules memory back to
      * the heap allocator
      */
     if ( using_static_heap )
@@ -303,7 +303,7 @@ void asmlinkage __init start_xen(unsigned long fdt_paddr)
 {
     size_t fdt_size;
     const char *cmdline;
-    struct bootmodule *xen_bootmodule;
+    struct boot_module *xen_boot_module;
     struct domain *d;
     int rc, i;
 
@@ -327,10 +327,10 @@ void asmlinkage __init start_xen(unsigned long fdt_paddr)
               fdt_paddr);
 
     /* Register Xen's load address as a boot module. */
-    xen_bootmodule = add_boot_module(BOOTMOD_XEN,
+    xen_boot_module = add_boot_module(BOOTMOD_XEN,
                              virt_to_maddr(_start),
                              (paddr_t)(uintptr_t)(_end - _start), false);
-    BUG_ON(!xen_bootmodule);
+    BUG_ON(!xen_boot_module);
 
     fdt_size = boot_fdt_info(device_tree_flattened, fdt_paddr);
 
diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
index 9daea06e57..39334d6205 100644
--- a/xen/common/device-tree/bootfdt.c
+++ b/xen/common/device-tree/bootfdt.c
@@ -314,7 +314,7 @@ static void __init process_multiboot_node(const void *fdt, int node,
     static int __initdata kind_guess = 0;
     const struct fdt_property *prop;
     const __be32 *cell;
-    bootmodule_kind kind;
+    boot_module_kind kind;
     paddr_t start, size;
     int len;
     /* sizeof("/chosen/") + DT_MAX_NAME + '/' + DT_MAX_NAME + '/0' => 92 */
@@ -518,7 +518,7 @@ static void __init early_print_info(void)
 {
     const struct membanks *mi = bootinfo_get_mem();
     const struct membanks *mem_resv = bootinfo_get_reserved_mem();
-    struct bootmodules *mods = &bootinfo.modules;
+    struct boot_modules *mods = &bootinfo.modules;
     struct bootcmdlines *cmds = &bootinfo.cmdlines;
     unsigned int i;
 
diff --git a/xen/common/device-tree/bootinfo.c b/xen/common/device-tree/bootinfo.c
index 717cfa0962..2a27d1318b 100644
--- a/xen/common/device-tree/bootinfo.c
+++ b/xen/common/device-tree/bootinfo.c
@@ -21,7 +21,7 @@
 
 struct bootinfo __initdata bootinfo = BOOTINFO_INIT;
 
-const char * __init boot_module_kind_as_string(bootmodule_kind kind)
+const char * __init boot_module_kind_as_string(boot_module_kind kind)
 {
     switch ( kind )
     {
@@ -49,7 +49,7 @@ static void __init dt_unreserved_regions(paddr_t s, paddr_t e,
     unsigned int i;
 
     /*
-     * i is the current bootmodule we are evaluating across all possible
+     * i is the current boot_module we are evaluating across all possible
      * kinds.
      */
     for ( i = first; i < reserved_mem->nr_banks; i++ )
@@ -143,18 +143,18 @@ static bool __init meminfo_overlap_check(const struct membanks *mem,
  * TODO: '*_end' could be 0 if the module/region is at the end of the physical
  * address space. This is for now not handled as it requires more rework.
  */
-static bool __init bootmodules_overlap_check(struct bootmodules *bootmodules,
-                                             paddr_t region_start,
-                                             paddr_t region_size)
+static bool __init boot_modules_overlap_check(struct boot_modules *boot_modules,
+                                              paddr_t region_start,
+                                              paddr_t region_size)
 {
     paddr_t mod_start = INVALID_PADDR, mod_end = 0;
     paddr_t region_end = region_start + region_size;
-    unsigned int i, mod_num = bootmodules->nr_mods;
+    unsigned int i, mod_num = boot_modules->nr_mods;
 
     for ( i = 0; i < mod_num; i++ )
     {
-        mod_start = bootmodules->module[i].start;
-        mod_end = mod_start + bootmodules->module[i].size;
+        mod_start = boot_modules->module[i].start;
+        mod_end = mod_start + boot_modules->module[i].size;
 
         if ( region_end <= mod_start || region_start >= mod_end )
             continue;
@@ -210,20 +210,20 @@ bool __init check_reserved_regions_overlap(paddr_t region_start,
                                    allow_memreserve_overlap) )
             return true;
 
-    /* Check if input region is overlapping with bootmodules */
-    if ( bootmodules_overlap_check(&bootinfo.modules,
-                                   region_start, region_size) )
+    /* Check if input region is overlapping with boot_modules */
+    if ( boot_modules_overlap_check(&bootinfo.modules,
+                                    region_start, region_size) )
         return true;
 
     return false;
 }
 
-struct bootmodule __init *add_boot_module(bootmodule_kind kind,
-                                          paddr_t start, paddr_t size,
-                                          bool domU)
+struct boot_module __init *add_boot_module(boot_module_kind kind,
+                                           paddr_t start, paddr_t size,
+                                           bool domU)
 {
-    struct bootmodules *mods = &bootinfo.modules;
-    struct bootmodule *mod;
+    struct boot_modules *mods = &bootinfo.modules;
+    struct boot_module *mod;
     unsigned int i;
 
     if ( mods->nr_mods == MAX_MODULES )
@@ -266,10 +266,10 @@ struct bootmodule __init *add_boot_module(bootmodule_kind kind,
  * XSM, DTB) or Dom0 modules. This is not suitable for looking up guest
  * modules.
  */
-struct bootmodule * __init boot_module_find_by_kind(bootmodule_kind kind)
+struct boot_module * __init boot_module_find_by_kind(boot_module_kind kind)
 {
-    struct bootmodules *mods = &bootinfo.modules;
-    struct bootmodule *mod;
+    struct boot_modules *mods = &bootinfo.modules;
+    struct boot_module *mod;
     int i;
     for (i = 0 ; i < mods->nr_mods ; i++ )
     {
@@ -281,7 +281,7 @@ struct bootmodule * __init boot_module_find_by_kind(bootmodule_kind kind)
 }
 
 void __init add_boot_cmdline(const char *name, const char *cmdline,
-                             bootmodule_kind kind, paddr_t start, bool domU)
+                             boot_module_kind kind, paddr_t start, bool domU)
 {
     struct bootcmdlines *cmds = &bootinfo.cmdlines;
     struct bootcmdline *cmd;
@@ -310,7 +310,7 @@ void __init add_boot_cmdline(const char *name, const char *cmdline,
  * XSM, DTB) or Dom0 modules. This is not suitable for looking up guest
  * modules.
  */
-struct bootcmdline * __init boot_cmdline_find_by_kind(bootmodule_kind kind)
+struct bootcmdline * __init boot_cmdline_find_by_kind(boot_module_kind kind)
 {
     struct bootcmdlines *cmds = &bootinfo.cmdlines;
     struct bootcmdline *cmd;
@@ -340,11 +340,11 @@ struct bootcmdline * __init boot_cmdline_find_by_name(const char *name)
     return NULL;
 }
 
-struct bootmodule * __init boot_module_find_by_addr_and_kind(bootmodule_kind kind,
-                                                             paddr_t start)
+struct boot_module * __init boot_module_find_by_addr_and_kind(
+    boot_module_kind kind, paddr_t start)
 {
-    struct bootmodules *mods = &bootinfo.modules;
-    struct bootmodule *mod;
+    struct boot_modules *mods = &bootinfo.modules;
+    struct boot_module *mod;
     unsigned int i;
 
     for (i = 0 ; i < mods->nr_mods ; i++ )
@@ -366,7 +366,7 @@ struct bootmodule * __init boot_module_find_by_addr_and_kind(bootmodule_kind kin
  */
 static paddr_t __init next_module(paddr_t s, paddr_t *end)
 {
-    struct bootmodules *mi = &bootinfo.modules;
+    struct boot_modules *mi = &bootinfo.modules;
     paddr_t lowest = ~(paddr_t)0;
     int i;
 
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
index 3d503c6973..221b875a2f 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -44,13 +44,13 @@ void __init set_xs_domain(struct domain *d)
 
 bool __init is_dom0less_mode(void)
 {
-    struct bootmodules *mods = &bootinfo.modules;
-    struct bootmodule *mod;
+    struct boot_modules *mods = &bootinfo.modules;
+    struct boot_module *mod;
     unsigned int i;
     bool dom0found = false;
     bool domUfound = false;
 
-    /* Look into the bootmodules */
+    /* Look into the boot_modules */
     for ( i = 0 ; i < mods->nr_mods ; i++ )
     {
         mod = &mods->module[i];
@@ -374,18 +374,17 @@ static int __init check_partial_fdt(void *pfdt, size_t size)
     return 0;
 }
 
-static int __init domain_handle_dtb_bootmodule(struct domain *d,
-                                               struct kernel_info *kinfo)
+static int __init domain_handle_dtb_boot_module(struct domain *d,
+                                                struct kernel_info *kinfo)
 {
     void *pfdt;
     int res, node_next;
 
-    pfdt = ioremap_cache(kinfo->dtb_bootmodule->start,
-                         kinfo->dtb_bootmodule->size);
+    pfdt = ioremap_cache(kinfo->dtb->start, kinfo->dtb->size);
     if ( pfdt == NULL )
         return -EFAULT;
 
-    res = check_partial_fdt(pfdt, kinfo->dtb_bootmodule->size);
+    res = check_partial_fdt(pfdt, kinfo->dtb->size);
     if ( res < 0 )
         goto out;
 
@@ -459,8 +458,8 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
     sizecells = GUEST_ROOT_SIZE_CELLS;
 
     /* Account for domU passthrough DT size */
-    if ( kinfo->dtb_bootmodule )
-        fdt_size += kinfo->dtb_bootmodule->size;
+    if ( kinfo->dtb )
+        fdt_size += kinfo->dtb->size;
 
     /* Cap to max DT size if needed */
     fdt_size = min(fdt_size, SZ_2M);
@@ -507,13 +506,13 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
         goto err;
 
     /*
-     * domain_handle_dtb_bootmodule has to be called before the rest of
+     * domain_handle_dtb_boot_module has to be called before the rest of
      * the device tree is generated because it depends on the value of
      * the field phandle_intc.
      */
-    if ( kinfo->dtb_bootmodule )
+    if ( kinfo->dtb )
     {
-        ret = domain_handle_dtb_bootmodule(d, kinfo);
+        ret = domain_handle_dtb_boot_module(d, kinfo);
         if ( ret )
             goto err;
     }
diff --git a/xen/common/device-tree/domain-build.c b/xen/common/device-tree/domain-build.c
index 6b8b8d7cac..fa4f700597 100644
--- a/xen/common/device-tree/domain-build.c
+++ b/xen/common/device-tree/domain-build.c
@@ -347,7 +347,7 @@ void __init dtb_load(struct kernel_info *kinfo,
 void __init initrd_load(struct kernel_info *kinfo,
                         copy_to_guest_phys_cb copy_to_guest)
 {
-    const struct bootmodule *mod = kinfo->initrd_bootmodule;
+    const struct boot_module *mod = kinfo->initrd;
     paddr_t load_addr = kinfo->initrd_paddr;
     paddr_t paddr, len;
     int node;
diff --git a/xen/common/device-tree/kernel.c b/xen/common/device-tree/kernel.c
index cb04cd9d50..e1b22dc1c7 100644
--- a/xen/common/device-tree/kernel.c
+++ b/xen/common/device-tree/kernel.c
@@ -21,7 +21,7 @@ static uint32_t __init output_length(char *image, unsigned long image_len)
     return *(uint32_t *)&image[image_len - 4];
 }
 
-int __init kernel_decompress(struct bootmodule *mod, uint32_t offset)
+int __init kernel_decompress(struct boot_module *mod, uint32_t offset)
 {
     char *output, *input;
     char magic[2];
@@ -92,7 +92,7 @@ int __init kernel_decompress(struct bootmodule *mod, uint32_t offset)
         free_domheap_page(pages + i);
 
     /*
-     * When using static heap feature, don't give bootmodules memory back to
+     * When using static heap feature, don't give boot_modules memory back to
      * the heap allocator
      */
     if ( using_static_heap )
@@ -118,7 +118,7 @@ int __init kernel_decompress(struct bootmodule *mod, uint32_t offset)
 int __init kernel_probe(struct kernel_info *info,
                         const struct dt_device_node *domain)
 {
-    struct bootmodule *mod = NULL;
+    struct boot_module *mod = NULL;
     struct bootcmdline *cmd = NULL;
     struct dt_device_node *node;
     u64 kernel_addr, initrd_addr, dtb_addr, size;
@@ -140,8 +140,8 @@ int __init kernel_probe(struct kernel_info *info,
 
         mod = boot_module_find_by_kind(BOOTMOD_KERNEL);
 
-        info->kernel_bootmodule = mod;
-        info->initrd_bootmodule = boot_module_find_by_kind(BOOTMOD_RAMDISK);
+        info->kernel = mod;
+        info->initrd = boot_module_find_by_kind(BOOTMOD_RAMDISK);
 
         cmd = boot_cmdline_find_by_kind(BOOTMOD_KERNEL);
         if ( cmd )
@@ -162,7 +162,7 @@ int __init kernel_probe(struct kernel_info *info,
                 dt_get_range(&val, node, &kernel_addr, &size);
                 mod = boot_module_find_by_addr_and_kind(
                         BOOTMOD_KERNEL, kernel_addr);
-                info->kernel_bootmodule = mod;
+                info->kernel = mod;
             }
             else if ( dt_device_is_compatible(node, "multiboot,ramdisk") )
             {
@@ -171,7 +171,7 @@ int __init kernel_probe(struct kernel_info *info,
 
                 val = dt_get_property(node, "reg", &len);
                 dt_get_range(&val, node, &initrd_addr, &size);
-                info->initrd_bootmodule = boot_module_find_by_addr_and_kind(
+                info->initrd = boot_module_find_by_addr_and_kind(
                         BOOTMOD_RAMDISK, initrd_addr);
             }
             else if ( dt_device_is_compatible(node, "multiboot,device-tree") )
@@ -183,7 +183,7 @@ int __init kernel_probe(struct kernel_info *info,
                 if ( val == NULL )
                     continue;
                 dt_get_range(&val, node, &dtb_addr, &size);
-                info->dtb_bootmodule = boot_module_find_by_addr_and_kind(
+                info->dtb = boot_module_find_by_addr_and_kind(
                         BOOTMOD_GUEST_DTB, dtb_addr);
             }
             else
@@ -201,10 +201,10 @@ int __init kernel_probe(struct kernel_info *info,
     }
 
     printk("Loading %pd kernel from boot module @ %"PRIpaddr"\n",
-           info->d, info->kernel_bootmodule->start);
-    if ( info->initrd_bootmodule )
+           info->d, info->kernel->start);
+    if ( info->initrd )
         printk("Loading ramdisk from boot module @ %"PRIpaddr"\n",
-               info->initrd_bootmodule->start);
+               info->initrd->start);
 
     /*
      * uImage isn't really used nowadays thereby leave kernel_uimage_probe()
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index ff40f3078e..236b456dd2 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -23,7 +23,7 @@ typedef enum {
     BOOTMOD_GUEST_DTB,
     BOOTMOD_MICROCODE,
     BOOTMOD_UNKNOWN
-}  bootmodule_kind;
+}  boot_module_kind;
 
 enum membank_type {
     /*
@@ -103,8 +103,8 @@ struct shared_meminfo {
  * initrd to be compatible with all versions of the multiboot spec.
  */
 #define BOOTMOD_MAX_CMDLINE 1024
-struct bootmodule {
-    bootmodule_kind kind;
+struct boot_module {
+    boot_module_kind kind;
     bool domU;
     paddr_t start;
     paddr_t size;
@@ -113,16 +113,16 @@ struct bootmodule {
 /* DT_MAX_NAME is the node name max length according the DT spec */
 #define DT_MAX_NAME 41
 struct bootcmdline {
-    bootmodule_kind kind;
+    boot_module_kind kind;
     bool domU;
     paddr_t start;
     char dt_name[DT_MAX_NAME];
     char cmdline[BOOTMOD_MAX_CMDLINE];
 };
 
-struct bootmodules {
+struct boot_modules {
     int nr_mods;
-    struct bootmodule module[MAX_MODULES];
+    struct boot_module module[MAX_MODULES];
 };
 
 struct bootcmdlines {
@@ -134,7 +134,7 @@ struct bootinfo {
     struct meminfo mem;
     /* The reserved regions are only used when booting using Device-Tree */
     struct meminfo reserved_mem;
-    struct bootmodules modules;
+    struct boot_modules modules;
     struct bootcmdlines cmdlines;
 #ifdef CONFIG_ACPI
     struct meminfo acpi;
@@ -176,16 +176,16 @@ bool check_reserved_regions_overlap(paddr_t region_start,
                                     paddr_t region_size,
                                     bool allow_memreserve_overlap);
 
-struct bootmodule *add_boot_module(bootmodule_kind kind,
+struct boot_module *add_boot_module(boot_module_kind kind,
                                    paddr_t start, paddr_t size, bool domU);
-struct bootmodule *boot_module_find_by_kind(bootmodule_kind kind);
-struct bootmodule * boot_module_find_by_addr_and_kind(bootmodule_kind kind,
+struct boot_module *boot_module_find_by_kind(boot_module_kind kind);
+struct boot_module * boot_module_find_by_addr_and_kind(boot_module_kind kind,
                                                              paddr_t start);
 void add_boot_cmdline(const char *name, const char *cmdline,
-                      bootmodule_kind kind, paddr_t start, bool domU);
-struct bootcmdline *boot_cmdline_find_by_kind(bootmodule_kind kind);
+                      boot_module_kind kind, paddr_t start, bool domU);
+struct bootcmdline *boot_cmdline_find_by_kind(boot_module_kind kind);
 struct bootcmdline * boot_cmdline_find_by_name(const char *name);
-const char *boot_module_kind_as_string(bootmodule_kind kind);
+const char *boot_module_kind_as_string(boot_module_kind kind);
 
 void populate_boot_allocator(void);
 
diff --git a/xen/include/xen/fdt-kernel.h b/xen/include/xen/fdt-kernel.h
index 1939c3ebf7..12a0b42d17 100644
--- a/xen/include/xen/fdt-kernel.h
+++ b/xen/include/xen/fdt-kernel.h
@@ -34,7 +34,7 @@ struct kernel_info {
     paddr_t gnttab_size;
 
     /* boot blob load addresses */
-    const struct bootmodule *kernel_bootmodule, *initrd_bootmodule, *dtb_bootmodule;
+    const struct boot_module *kernel, *initrd, *dtb;
     const char* cmdline;
     paddr_t dtb_paddr;
     paddr_t initrd_paddr;
@@ -121,7 +121,7 @@ int kernel_probe(struct kernel_info *info, const struct dt_device_node *domain);
  */
 void kernel_load(struct kernel_info *info);
 
-int kernel_decompress(struct bootmodule *mod, uint32_t offset);
+int kernel_decompress(struct boot_module *mod, uint32_t offset);
 
 int kernel_zimage_probe(struct kernel_info *info, paddr_t addr, paddr_t size);
 
@@ -130,8 +130,7 @@ int kernel_zimage_probe(struct kernel_info *info, paddr_t addr, paddr_t size);
  * call here just for compatability with Arm code.
  */
 #ifdef CONFIG_ARM
-struct bootmodule;
-int kernel_uimage_probe(struct kernel_info *info, struct bootmodule *mod);
+int kernel_uimage_probe(struct kernel_info *info, struct boot_module *mod);
 #endif
 
 #endif /* __XEN_FDT_KERNEL_H__ */
diff --git a/xen/xsm/xsm_policy.c b/xen/xsm/xsm_policy.c
index 7f70d860bd..1f88b4fc5a 100644
--- a/xen/xsm/xsm_policy.c
+++ b/xen/xsm/xsm_policy.c
@@ -68,7 +68,7 @@ int __init xsm_multiboot_policy_init(
 #ifdef CONFIG_HAS_DEVICE_TREE
 int __init xsm_dt_policy_init(void **policy_buffer, size_t *policy_size)
 {
-    struct bootmodule *mod = boot_module_find_by_kind(BOOTMOD_XSM);
+    struct boot_module *mod = boot_module_find_by_kind(BOOTMOD_XSM);
     paddr_t paddr, len;
 
     if ( !mod || !mod->size )
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 15:16:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 15:16:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014459.1392586 (Exim 4.92)
	(envelope-from )
	id 1uQ69C-0001iU-7M; Fri, 13 Jun 2025 15:16:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014459.1392586; Fri, 13 Jun 2025 15:16: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 1uQ69C-0001iJ-4M; Fri, 13 Jun 2025 15:16:50 +0000
Received: by outflank-mailman (input) for mailman id 1014459;
 Fri, 13 Jun 2025 15:16: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 1uQ69A-0001Mm-1F
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 15:16:48 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on2061b.outbound.protection.outlook.com
 [2a01:111:f403:2414::61b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6ac437a3-4869-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 17:16:45 +0200 (CEST)
Received: from DS7PR03CA0097.namprd03.prod.outlook.com (2603:10b6:5:3b7::12)
 by CYYPR12MB8853.namprd12.prod.outlook.com (2603:10b6:930:cb::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.18; Fri, 13 Jun
 2025 15:16:42 +0000
Received: from DS1PEPF0001709C.namprd05.prod.outlook.com
 (2603:10b6:5:3b7:cafe::ec) by DS7PR03CA0097.outlook.office365.com
 (2603:10b6:5:3b7::12) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.21 via Frontend Transport; Fri,
 13 Jun 2025 15:16:41 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 DS1PEPF0001709C.mail.protection.outlook.com (10.167.18.106) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Fri, 13 Jun 2025 15:16:41 +0000
Received: from xcbagarciav01.xilinx.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; Fri, 13 Jun
 2025 10:16:38 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6ac437a3-4869-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=U8tK9fc0So+dEv8cfZXlxoH3hlOTePXyTK0u+L0eHEazJTjPtjDKW5miwI0qWnnrZsnbiPehAR7iAAkaWL6wmJ9iVmZXWc6BsDkdkEdpuurdCZ+EEVhBaqP755sHAmZgurWseAnInviJFViHUSeNUf7vDJJg2bixRoU6h7Rj7n+VOV9kakypzNtVgSFklWxFGQzUggOZ7xe1uqDvmgK4e30kBT5KOs2uKh54dwr/F4HUv1V9jUanm1JhUyc91dlCfJI5VIIhwVJnu1blUa9cMyc8yKPszb0LafTTecBlcIUl3wTUwceWko0uvvAmrxaGbaztzeCzGI5V+maxHCErkQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=fuTUHPpW7/oLmgZ6zERNxr4Yy0wut8zcZxqimMu6Uqs=;
 b=KTwOGt8woWN4O+UKXeLLg+4/Ip8xOgF80pX4J4t03CxsWMo0mi1X2jMOc09eQgL97ftmsejvtTjmxNZVK9QAs1s5sNHolhg3RH472QcVeNhSTomcpF8/J5YFOf78gF37jBFqXQV6KhnAzvk4LFehU18m+5rRBhYMifIY5+kgqGQtoR5vRvkYeu/sICMchiLEbqUBpFyltudD+8kR8n4chcchb6g02JyHbSJXPAKQACC59Phckkf67VC5J/8ufm6jxHKEYTBx/qenkHj9Ah6yjIdPuyieXFI5y3MMewyvn958PZ4S26o/2aq/P97i+f02v24bzjngPCj445ftf5Zy5g==
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=fuTUHPpW7/oLmgZ6zERNxr4Yy0wut8zcZxqimMu6Uqs=;
 b=qZewcFjUBKNFha867ykXWS8s0dzRQXOqc7yz0u/33Nmy2oEajHTjlR+ZiT+FpK0+x8dSLzNyi1mxnKo8i2n+9Ji3p+vfoPGx+JInSb7EvM1GfDQLiXGwLEqDuIefv6TW42IxsjqX1PYj3VT6XkTbT/qtkwAjaShd0rMKReq+SEk=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Stefano
 Stabellini" , Julien Grall ,
	"Bertrand Marquis" , Michal Orzel
	, "Daniel P. Smith" 
Subject: [PATCH v3 05/14] x86: Replace arch-specific boot_module with common one
Date: Fri, 13 Jun 2025 17:13:14 +0200
Message-ID: <20250613151612.754222-6-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250613151612.754222-1-agarciav@amd.com>
References: <20250613151612.754222-1-agarciav@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: DS1PEPF0001709C:EE_|CYYPR12MB8853:EE_
X-MS-Office365-Filtering-Correlation-Id: adf927b5-630b-461d-3f4e-08ddaa8d4d0a
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?o6k741P9hkGIh6ZFCVCX6g4YtyxKfH1MRqOOJCMIEcJ7KMrzF133SA6WAx2a?=
 =?us-ascii?Q?s1zGrqQScEgpYLb4NI1gpv6sLsc6kzPXKQuzSoE55Yn5eu++OzQlMVOZLw70?=
 =?us-ascii?Q?KXAhwEFP4P/Nkdt/Y4kscVwVwizN4DWQJfUKKYyEVSCAUdKnoUBntradHxto?=
 =?us-ascii?Q?QNb8SpIqSoYL3siulTDFCRxm44WzghBn0q1LAKy78r1rcCLslNPMj57k6ZDk?=
 =?us-ascii?Q?2bKWoq3HsvVdADUo73yaYZFlrj2XQjyepW/2qC5Whc5UhVISzhhPBPJbvg99?=
 =?us-ascii?Q?9c99qC3FnHvEkqPm9DmmdpUmaSwF3a8l/0oxOUwWw+XrntJMDaEHSmZmtrdk?=
 =?us-ascii?Q?WzxYWsBrw+uLdhIDxMFUTa95htxW8fPI4BhyHIuYsWUpp5SMNLWteq0ylB74?=
 =?us-ascii?Q?dNTBA5NUKl2rssVnFZTBmro1v6FLk7oPYy+7QRieKQQbgH51tWALpemU183c?=
 =?us-ascii?Q?SI0T5BWUmDoZWLWO55uPltR26ODafNOS6uXHkohhs8mHpT4wmsJJYb+sgRsz?=
 =?us-ascii?Q?CgnmDvNiNdkekvk2/+JAuRRqoJhpKCss6svwue4aarMsl+THpQSj94fFZMyI?=
 =?us-ascii?Q?zlOjwRCH8Wwyl7bT0FoS9krgoooAl9L2t6JfBnkcFnaIZvYnL9VSuhXnz6cP?=
 =?us-ascii?Q?sZ3u1InEEgaNKp3H49rUhksUgM5Jj80bjweck+FzuTuYX+CmpAbZMfwxEPE5?=
 =?us-ascii?Q?vGWHVaFrWPjtqV0xePvqfg3BrnPyye9Oclr9wZCtVNvDkjt6JgoFzHXahCFy?=
 =?us-ascii?Q?YLH0wxmmwAh/K18Mvk+4j/KoKe6ilEsVp8JZlPrAngVK40PYKCovmCpgn2Vt?=
 =?us-ascii?Q?aQRL84izKrV9QnlTdytDVXMyOaesKuU0mW8C35Vaa3o103BUwNS9krxH4cvG?=
 =?us-ascii?Q?/YhVVB8B1H3Uf1Km+xdJTrYJVfSydmYVfwZnmtLcujy8aIOimX5YChsP9ROa?=
 =?us-ascii?Q?KDbVb5PoXvivYy3y2/4MiAdsrmw4l7Yi1CeKxEQLGQd8geFRjG4G186WyVbK?=
 =?us-ascii?Q?sCNpZZLl7sBPKX0SCDormB4stfEOu61lA0atQ3e63UaM4ebO/x6PZCLkqPeH?=
 =?us-ascii?Q?HgZg7MwQhniWhoA/qZAhhPrPN0aDjKMbam2vhrsEX4MvUr6NSRjbwqdEsUFf?=
 =?us-ascii?Q?eI/H6CLm7huIMo5dq+so6elriMFW8zSJ6vDy5fnueLat8ofdV2hVDJZ+FQJi?=
 =?us-ascii?Q?rNmP97zaXlLqHdoi/UxAFZunYn/jshGImM7RFHpER9npFcuHIU6AeIsr2xRo?=
 =?us-ascii?Q?y6bRamPrt+jY0O8L+uS1JqBItt9DM32YxEaKWwLJNLC9ggFeS7c1jBwd8X/3?=
 =?us-ascii?Q?A7PKU/tsXhZnIAoEQ6UnBhGVQFQoCXdR6o5SYZbyoeD9JUfQWXne56eTY9kO?=
 =?us-ascii?Q?95yZIqJKLyH7cYxNtSI0L9FfL2psG/tLbzyoU/HWqBRv5bHSFE1Kba7zQYot?=
 =?us-ascii?Q?/9fCwAxcJBA5yeCm+l5l60jdIhPzyYyS5SfbKSSYyfDz1O5NwmBi67qqoqVU?=
 =?us-ascii?Q?rHl2uX1+0Dua5GDaxYFBiV36V82Xe4sAXIPI?=
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: 13 Jun 2025 15:16:41.5293
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: adf927b5-630b-461d-3f4e-08ddaa8d4d0a
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:
	DS1PEPF0001709C.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYYPR12MB8853

These types resemble each other very closely in layout and intent,
and with "struct boot_module" already in common code it makes perfect
sense to merge them. In order to do so, add an arch-specific area for
x86-specific tidbits, and rename identical fields with conflicting
names.

No functional change intended.

Signed-off-by: Alejandro Vallejo 
---
 xen/arch/x86/cpu/microcode/core.c   |  7 ++--
 xen/arch/x86/hvm/dom0_build.c       |  8 ++---
 xen/arch/x86/include/asm/bootfdt.h  | 50 ++++++++++++++++++++++++++
 xen/arch/x86/include/asm/bootinfo.h | 56 +++--------------------------
 xen/arch/x86/pv/dom0_build.c        |  6 ++--
 xen/arch/x86/setup.c                | 42 +++++++++++-----------
 xen/include/xen/bootfdt.h           |  8 +++++
 xen/xsm/xsm_policy.c                |  2 +-
 8 files changed, 95 insertions(+), 84 deletions(-)
 create mode 100644 xen/arch/x86/include/asm/bootfdt.h

diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c
index 34a94cd25b..816e9bfe40 100644
--- a/xen/arch/x86/cpu/microcode/core.c
+++ b/xen/arch/x86/cpu/microcode/core.c
@@ -764,8 +764,7 @@ static int __init early_microcode_load(struct boot_info *bi)
             struct cpio_data cd;
 
             /* Search anything unclaimed or likely to be a CPIO archive. */
-            if ( bm->type != BOOTMOD_UNKNOWN &&
-                 bm->type != BOOTMOD_RAMDISK )
+            if ( bm->kind != BOOTMOD_UNKNOWN && bm->kind != BOOTMOD_RAMDISK )
                 continue;
 
             size = bm->size;
@@ -815,12 +814,12 @@ static int __init early_microcode_load(struct boot_info *bi)
             return -ENODEV;
         }
 
-        if ( bi->mods[idx].type != BOOTMOD_UNKNOWN )
+        if ( bi->mods[idx].kind != BOOTMOD_UNKNOWN )
         {
             printk(XENLOG_WARNING "Microcode: Chosen module %d already used\n", idx);
             return -ENODEV;
         }
-        bi->mods[idx].type = BOOTMOD_MICROCODE;
+        bi->mods[idx].kind = BOOTMOD_MICROCODE;
 
         size = bi->mods[idx].size;
         data = bootstrap_map_bm(&bi->mods[idx]);
diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index a038e58c11..8d2734f2b5 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -648,9 +648,9 @@ static int __init pvh_load_kernel(
 {
     struct domain *d = bd->d;
     struct boot_module *image = bd->kernel;
-    struct boot_module *initrd = bd->module;
+    struct boot_module *initrd = bd->initrd;
     void *image_base = bootstrap_map_bm(image);
-    void *image_start = image_base + image->headroom;
+    void *image_start = image_base + image->arch.headroom;
     unsigned long image_len = image->size;
     unsigned long initrd_len = initrd ? initrd->size : 0;
     size_t cmdline_len = bd->cmdline ? strlen(bd->cmdline) + 1 : 0;
@@ -721,9 +721,9 @@ static int __init pvh_load_kernel(
     {
         size_t initrd_space = elf_round_up(&elf, initrd_len);
 
-        if ( initrd->cmdline_pa )
+        if ( initrd->arch.cmdline_pa )
         {
-            initrd_cmdline = __va(initrd->cmdline_pa);
+            initrd_cmdline = __va(initrd->arch.cmdline_pa);
             if ( !*initrd_cmdline )
                 initrd_cmdline = NULL;
         }
diff --git a/xen/arch/x86/include/asm/bootfdt.h b/xen/arch/x86/include/asm/bootfdt.h
new file mode 100644
index 0000000000..a4c4bf30b9
--- /dev/null
+++ b/xen/arch/x86/include/asm/bootfdt.h
@@ -0,0 +1,50 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef X86_BOOTFDT_H
+#define X86_BOOTFDT_H
+
+#include 
+
+struct arch_boot_module
+{
+    /*
+     * Module State Flags:
+     *   relocated:   indicates module has been relocated in memory.
+     *   released:    indicates module's pages have been freed.
+     */
+    bool relocated:1;
+    bool released:1;
+
+    /*
+     * A boot module may need decompressing by Xen.  Headroom is an estimate of
+     * the additional space required to decompress the module.
+     *
+     * Headroom is accounted for at the start of the module.  Decompressing is
+     * done in-place with input=start, output=start-headroom, expecting the
+     * pointers to become equal (give or take some rounding) when decompression
+     * is complete.
+     *
+     * Memory layout at boot:
+     *
+     *               start ----+
+     *                         v
+     *   |<-----headroom------>|<------size------->|
+     *                         +-------------------+
+     *                         | Compressed Module |
+     *   +---------------------+-------------------+
+     *   |           Decompressed Module           |
+     *   +-----------------------------------------+
+     */
+    unsigned long headroom;
+    paddr_t cmdline_pa;
+};
+
+#endif /* X86_BOOTFDT_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/bootinfo.h b/xen/arch/x86/include/asm/bootinfo.h
index 3afc214c17..d33b100e04 100644
--- a/xen/arch/x86/include/asm/bootinfo.h
+++ b/xen/arch/x86/include/asm/bootinfo.h
@@ -8,6 +8,7 @@
 #ifndef X86_BOOTINFO_H
 #define X86_BOOTINFO_H
 
+#include 
 #include 
 #include 
 #include 
@@ -19,55 +20,6 @@
 /* Max number of boot domains that Xen can construct */
 #define MAX_NR_BOOTDOMS 1
 
-/* Boot module binary type / purpose */
-enum bootmod_type {
-    BOOTMOD_UNKNOWN,
-    BOOTMOD_XEN,
-    BOOTMOD_KERNEL,
-    BOOTMOD_RAMDISK,
-    BOOTMOD_MICROCODE,
-    BOOTMOD_XSM_POLICY,
-};
-
-struct boot_module {
-    enum bootmod_type type;
-
-    /*
-     * Module State Flags:
-     *   relocated: indicates module has been relocated in memory.
-     *   released:  indicates module's pages have been freed.
-     */
-    bool relocated:1;
-    bool released:1;
-
-    /*
-     * A boot module may need decompressing by Xen.  Headroom is an estimate of
-     * the additional space required to decompress the module.
-     *
-     * Headroom is accounted for at the start of the module.  Decompressing is
-     * done in-place with input=start, output=start-headroom, expecting the
-     * pointers to become equal (give or take some rounding) when decompression
-     * is complete.
-     *
-     * Memory layout at boot:
-     *
-     *               start ----+
-     *                         v
-     *   |<-----headroom------>|<------size------->|
-     *                         +-------------------+
-     *                         | Compressed Module |
-     *   +---------------------+-------------------+
-     *   |           Decompressed Module           |
-     *   +-----------------------------------------+
-     */
-    unsigned long headroom;
-
-    paddr_t cmdline_pa;
-
-    paddr_t start;
-    size_t size;
-};
-
 /*
  * Xen internal representation of information provided by the
  * bootloader/environment, or derived from the information.
@@ -94,16 +46,16 @@ struct boot_info {
  *      Failure - a value greater than MAX_NR_BOOTMODS
  */
 static inline unsigned int __init next_boot_module_index(
-    const struct boot_info *bi, enum bootmod_type t, unsigned int start)
+    const struct boot_info *bi, boot_module_kind k, unsigned int start)
 {
     unsigned int i;
 
-    if ( t == BOOTMOD_XEN )
+    if ( k == BOOTMOD_XEN )
         return bi->nr_modules;
 
     for ( i = start; i < bi->nr_modules; i++ )
     {
-        if ( bi->mods[i].type == t )
+        if ( bi->mods[i].kind == k )
             return i;
     }
 
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index e1b78d47c2..c37bea9454 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -375,7 +375,7 @@ static int __init dom0_construct(const struct boot_domain *bd)
     struct vcpu *v = d->vcpu[0];
 
     struct boot_module *image = bd->kernel;
-    struct boot_module *initrd = bd->module;
+    struct boot_module *initrd = bd->initrd;
     void *image_base;
     unsigned long image_len;
     void *image_start;
@@ -422,7 +422,7 @@ static int __init dom0_construct(const struct boot_domain *bd)
 
     image_base = bootstrap_map_bm(image);
     image_len = image->size;
-    image_start = image_base + image->headroom;
+    image_start = image_base + image->arch.headroom;
 
     d->max_pages = ~0U;
 
@@ -659,7 +659,7 @@ static int __init dom0_construct(const struct boot_domain *bd)
              * pages. Tell the boot_module handling that we've freed it, so the
              * memory is left alone.
              */
-            initrd->released = true;
+            initrd->arch.released = true;
         }
 
         iommu_memory_setup(d, "initrd", mfn_to_page(_mfn(initrd_mfn)),
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 7d3b30e1db..c00b22205a 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -303,7 +303,7 @@ struct boot_info __initdata xen_boot_info = {
      *
      * The extra entry exists to be able to add the Xen image as a module.
      */
-    .mods = { [0 ... MAX_NR_BOOTMODS] = { .type = BOOTMOD_UNKNOWN } },
+    .mods = { [0 ... MAX_NR_BOOTMODS] = { .kind = BOOTMOD_UNKNOWN } },
 };
 
 static struct boot_info *__init multiboot_fill_boot_info(
@@ -338,7 +338,7 @@ static struct boot_info *__init multiboot_fill_boot_info(
      */
     for ( i = 0; i < MAX_NR_BOOTMODS && i < bi->nr_modules; i++ )
     {
-        bi->mods[i].cmdline_pa = mods[i].string;
+        bi->mods[i].arch.cmdline_pa = mods[i].string;
 
         if ( efi_enabled(EFI_LOADER) )
         {
@@ -361,7 +361,7 @@ 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;
+    bi->mods[i].kind = BOOTMOD_XEN;
 
     return bi;
 }
@@ -388,11 +388,11 @@ unsigned long __init initial_images_nrpages(nodeid_t node)
 
 void __init release_boot_module(struct boot_module *bm)
 {
-    ASSERT(!bm->released);
+    ASSERT(!bm->arch.released);
 
     init_domheap_pages(bm->start, bm->start + PAGE_ALIGN(bm->size));
 
-    bm->released = true;
+    bm->arch.released = true;
 }
 
 void __init free_boot_modules(void)
@@ -402,7 +402,7 @@ void __init free_boot_modules(void)
 
     for ( i = 0; i < bi->nr_modules; ++i )
     {
-        if ( bi->mods[i].released )
+        if ( bi->mods[i].arch.released )
             continue;
 
         release_boot_module(&bi->mods[i]);
@@ -990,8 +990,9 @@ static size_t __init domain_cmdline_size(const struct boot_info *bi,
                                          const struct boot_domain *bd)
 {
     size_t s = bi->kextra ? strlen(bi->kextra) : 0;
+    const struct arch_boot_module *abm = &bd->kernel->arch;
 
-    s += bd->kernel->cmdline_pa ? strlen(__va(bd->kernel->cmdline_pa)) : 0;
+    s += abm->cmdline_pa ? strlen(__va(abm->cmdline_pa)) : 0;
 
     if ( s == 0 )
         return s;
@@ -1055,9 +1056,10 @@ 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->arch.cmdline_pa )
             strlcpy(cmdline,
-                    cmdline_cook(__va(bd->kernel->cmdline_pa), bi->loader),
+                    cmdline_cook(__va(bd->kernel->arch.cmdline_pa),
+                                 bi->loader),
                     cmdline_size);
 
         if ( bi->kextra )
@@ -1079,7 +1081,7 @@ static struct domain *__init create_dom0(struct boot_info *bi)
             strlcat(cmdline, " acpi=", cmdline_size);
             strlcat(cmdline, acpi_param, cmdline_size);
         }
-        bd->kernel->cmdline_pa = 0;
+        bd->kernel->arch.cmdline_pa = 0;
         bd->cmdline = cmdline;
     }
 
@@ -1292,7 +1294,7 @@ void asmlinkage __init noreturn __start_xen(void)
     }
 
     /* Dom0 kernel is always first */
-    bi->mods[0].type = BOOTMOD_KERNEL;
+    bi->mods[0].kind = BOOTMOD_KERNEL;
     bi->domains[0].kernel = &bi->mods[0];
 
     if ( pvh_boot )
@@ -1476,7 +1478,7 @@ void asmlinkage __init noreturn __start_xen(void)
         xen->size  = __2M_rwdata_end - _stext;
     }
 
-    bi->mods[0].headroom =
+    bi->mods[0].arch.headroom =
         bzimage_headroom(bootstrap_map_bm(&bi->mods[0]), bi->mods[0].size);
     bootstrap_unmap();
 
@@ -1558,9 +1560,9 @@ void asmlinkage __init noreturn __start_xen(void)
         for ( j = bi->nr_modules - 1; j >= 0; j-- )
         {
             struct boot_module *bm = &bi->mods[j];
-            unsigned long size = PAGE_ALIGN(bm->headroom + bm->size);
+            unsigned long size = PAGE_ALIGN(bm->arch.headroom + bm->size);
 
-            if ( bm->relocated )
+            if ( bm->arch.relocated )
                 continue;
 
             /* Don't overlap with other modules (or Xen itself). */
@@ -1570,12 +1572,12 @@ void asmlinkage __init noreturn __start_xen(void)
             if ( highmem_start && end > highmem_start )
                 continue;
 
-            if ( s < end && (bm->headroom || (end - size) > bm->start) )
+            if ( s < end && (bm->arch.headroom || (end - size) > bm->start) )
             {
-                move_memory(end - size + bm->headroom, bm->start, bm->size);
+                move_memory(end - size + bm->arch.headroom, bm->start, bm->size);
                 bm->start = (end - size);
-                bm->size += bm->headroom;
-                bm->relocated = true;
+                bm->size += bm->arch.headroom;
+                bm->arch.relocated = true;
             }
         }
 
@@ -1601,7 +1603,7 @@ void asmlinkage __init noreturn __start_xen(void)
 #endif
     }
 
-    if ( bi->mods[0].headroom && !bi->mods[0].relocated )
+    if ( bi->mods[0].arch.headroom && !bi->mods[0].arch.relocated )
         panic("Not enough memory to relocate the dom0 kernel image\n");
     for ( i = 0; i < bi->nr_modules; ++i )
     {
@@ -2159,7 +2161,7 @@ void asmlinkage __init noreturn __start_xen(void)
     initrdidx = first_boot_module_index(bi, BOOTMOD_UNKNOWN);
     if ( initrdidx < MAX_NR_BOOTMODS )
     {
-        bi->mods[initrdidx].type = BOOTMOD_RAMDISK;
+        bi->mods[initrdidx].kind = BOOTMOD_RAMDISK;
         bi->domains[0].module = &bi->mods[initrdidx];
         if ( first_boot_module_index(bi, BOOTMOD_UNKNOWN) < MAX_NR_BOOTMODS )
             printk(XENLOG_WARNING
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index 236b456dd2..854e7f1ed9 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -7,6 +7,10 @@
 #include 
 #include 
 
+#if __has_include()
+#include 
+#endif
+
 #define MIN_FDT_ALIGN 8
 
 #define NR_MEM_BANKS 256
@@ -108,6 +112,10 @@ struct boot_module {
     bool domU;
     paddr_t start;
     paddr_t size;
+
+#if __has_include()
+    struct arch_boot_module arch;
+#endif
 };
 
 /* DT_MAX_NAME is the node name max length according the DT spec */
diff --git a/xen/xsm/xsm_policy.c b/xen/xsm/xsm_policy.c
index 1f88b4fc5a..1b4030edb4 100644
--- a/xen/xsm/xsm_policy.c
+++ b/xen/xsm/xsm_policy.c
@@ -53,7 +53,7 @@ int __init xsm_multiboot_policy_init(
             printk("Policy len %#lx, start at %p.\n",
                    _policy_len,_policy_start);
 
-            bm->type = BOOTMOD_XSM_POLICY;
+            bm->kind = BOOTMOD_XSM;
             break;
 
         }
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 15:16:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 15:16:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014461.1392597 (Exim 4.92)
	(envelope-from )
	id 1uQ69G-00027I-JI; Fri, 13 Jun 2025 15:16:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014461.1392597; Fri, 13 Jun 2025 15:16: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 1uQ69G-000275-EO; Fri, 13 Jun 2025 15:16:54 +0000
Received: by outflank-mailman (input) for mailman id 1014461;
 Fri, 13 Jun 2025 15:16: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 1uQ69E-0001Mm-LU
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 15:16:52 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20614.outbound.protection.outlook.com
 [2a01:111:f403:2414::614])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6d7ea6ae-4869-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 17:16:50 +0200 (CEST)
Received: from DS7PR03CA0176.namprd03.prod.outlook.com (2603:10b6:5:3b2::31)
 by DS0PR12MB7993.namprd12.prod.outlook.com (2603:10b6:8:14b::14) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.42; Fri, 13 Jun
 2025 15:16:45 +0000
Received: from DS1PEPF00017099.namprd05.prod.outlook.com
 (2603:10b6:5:3b2:cafe::e5) by DS7PR03CA0176.outlook.office365.com
 (2603:10b6:5:3b2::31) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.23 via Frontend Transport; Fri,
 13 Jun 2025 15:16:45 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 DS1PEPF00017099.mail.protection.outlook.com (10.167.18.103) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Fri, 13 Jun 2025 15:16:45 +0000
Received: from xcbagarciav01.xilinx.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; Fri, 13 Jun
 2025 10:16:41 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6d7ea6ae-4869-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=MRrcV1wxy/9R3ITreg1GW+QpAfCRt8Cw2HU1Dud2GjrdD5yC7eDpLjQqs+YnGEoBDpWR2RofdgIo0/UQ2YAkbgMrQSWcIfAowbYoqthQZxO0EKlPeZqCs8WIGJQIHrAxrDgSlYibIGLUJWzJY+7NWEoBES7tePYZbcyJ130fxBeRvfmAyo177WeGqxDSsTjc05Dwzxj2loXyBU1fghYule+W8/8bBZeV6XZakLhbe70vDaqyRydyjeMZB+tzJB3dXYmnX/CRjXzeIGqimGo0HI5qZCkUHWeKTX5O/c6bYSKNWf/23U9fXlPwAVyPzVaR93LEXXMEuki7+t3/bYdnfg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=6WQXdNCQ4YEFOlOGIA7yPbS/pDs+RBMFXfZvWeMamn8=;
 b=yxJJ27BR1MsWa8mbzQQmoaC9T6NbyQwb0MEgjn2XOvTvhXkZv+30LvvK78+5xWBjxCzYLgyekFgYj+fMQFoQ6r8Qq1OUqQCc4Hx1z9EC5m9wk7cFxi+r9cvT11HE07OizZsyUhGvKYpJKqbRtSdAYw/l0LDQNZMN9dQtBQ4wGc5PiyTIlfY9Y0KVLhwI5Hv3g++pnGpLpKZNGGqw2gFo/O+Tg3axqo0ZJdzUjhXc+V8SGoLJkyhetUeCZXLgyrkB7CNJo5bIpx0IYyJiTAsxjhlQEaKNiz716pL+pDV+ZOteWjwUBXb4qtciPTq+n+6bcTSS6Jd4/hsAZZqFm+0sTA==
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=6WQXdNCQ4YEFOlOGIA7yPbS/pDs+RBMFXfZvWeMamn8=;
 b=3uSUr01nwq1y+fArkxvdyAxlINDZG5EzlXuuJ161zRkVyhzWSqwDsP5pdOPCK5OBZ+TE8JGaSQFRJ28WVPlRI15Bh+2eUpUZSl9fYx0mxCzs/8Lvl33s1I4m0EnIJCyS2nRSUBgIT8VYnIwFjQbsDByx8ro/GiIz672oZz9q6Vk=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , Andrew Cooper
	, Anthony PERARD , "Jan
 Beulich" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, "Daniel P. Smith" 
Subject: [PATCH v3 06/14] xen: Refactor kernel_info to have a header like boot_domain
Date: Fri, 13 Jun 2025 17:13:15 +0200
Message-ID: <20250613151612.754222-7-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250613151612.754222-1-agarciav@amd.com>
References: <20250613151612.754222-1-agarciav@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: DS1PEPF00017099:EE_|DS0PR12MB7993:EE_
X-MS-Office365-Filtering-Correlation-Id: 31b0e233-9149-42e7-75f7-08ddaa8d4f20
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|82310400026|7416014|36860700013|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?LHith88iTN5vFu3ItrV6WgdAvW94M5qsOdxy0vUwfy9yMDzr7U8x9Kk7rY0M?=
 =?us-ascii?Q?C8hRDaGpgJ65wELVdYJsMTCj77xQ8TixaW2WB4OCHLPmRJAgfbhwQIXhvBas?=
 =?us-ascii?Q?tFhA33F0LYgRDdth5v21Dvuh5u2qzHyZ/5vdSs5TTrskaKXNpKT+28Pduk1I?=
 =?us-ascii?Q?RBi/2ZOgb7fcihDrWApvnqhoBfOe9FZOxBFoE6mud/wtgT9TBdU7lB/wxSZj?=
 =?us-ascii?Q?6iJOCWeLcWsD4SA7EVTfW+aXQrNuDqmyvF9DCa0TFA1Z+SzmiFcwcCkRA68s?=
 =?us-ascii?Q?WNmZ0dxPR21KjbiFPS8gIXAUCnCIbYa3+jTfmriq/sBkAOS0u4z/rSujnEUB?=
 =?us-ascii?Q?J47RWCvtsHsPGS6bJu9rRjzYyyiGPGd6IZ2VfRzVSCYFfHa/KKAWcLUeywa7?=
 =?us-ascii?Q?e2zkRg0GbPmwrWeggpRFizwMiU2OO/wIHF4ZJdBIxnd0ELZ2VV3w9PWtearE?=
 =?us-ascii?Q?bINkPCs5nohZNVYWhXkgx3sO1Wl1t9Jb2ymjgB/E8SwvoQ2r4clK2p/zModE?=
 =?us-ascii?Q?ydUAs6fgs9ISXSrLMKv15LCIwmWdZjP+K1pNpGYQAn8e94c4p4b/dVNWlKit?=
 =?us-ascii?Q?hLytPeWJr10Fh/Nv2fhG5k2W64BWfDjSYujEkxn3yrhwzOzVhpTqS/JjoOTZ?=
 =?us-ascii?Q?YJynHSZEch/+JC8NoUzlx538Vyb2yX4ZvvQ9qIfWurHSsNCTDWFacXxf2BGk?=
 =?us-ascii?Q?sdIiYgmuF9ouXYF7qrwQLSiaXD23/Nt/zx38cK2uy8+/4z8ORkoOxrvCPuw3?=
 =?us-ascii?Q?N3mvZRq7GN9anT2HPiSDeC1i1X9T98wvfOLGDGjejCyjdzejjqx1c8QoZ02b?=
 =?us-ascii?Q?bI8NU9qKM9XtU1owYR1FIm2OzaAEmVsmZ2t0JIXq0Jzo58ch84CLYeRIlxlQ?=
 =?us-ascii?Q?gb7+uxztV/Cp10Y5GdkbvhbQPwcTpVQWBYQrvkJQRhbcNhDVOpG5n7f8H/CW?=
 =?us-ascii?Q?QrcsiMHjlH5EdNK2f0CKI1PndQ37khmsligTr2LjWfzIxfBXZwVHH0l140VD?=
 =?us-ascii?Q?ps6oz/wIyEjyX6+5CSUqHsubxm1G1P/38lWNOId38GnQEV/1iQ+owtHnqzpN?=
 =?us-ascii?Q?MkeQOvolZ9/hP+Ee2MDZcqSTPtWJkGzdLN/2Uqr73hWSEHR+BoYSFJ2krjwQ?=
 =?us-ascii?Q?9tsVWGzwItNiGh+061SSTtBNqBb716ej4ZJm0A1bhO8pdfcktcJiC2Ph9YSG?=
 =?us-ascii?Q?/9Ny/OHGkUxyxeTLoraG4YCPyvo9E1SN3sKrwit8/Dv0GA2bXDur5RlE02Fi?=
 =?us-ascii?Q?bXglGkcWLK4Wu6ZHxQNsXfNkAhRH2owSpv+AKT50B7ED808nH4hXiaXnM7Gg?=
 =?us-ascii?Q?i694l0OpB5VTMHz4N+kQwNsI2kWEfBSq35WRcu+FmH/iukNJGyUKsm7sQWG8?=
 =?us-ascii?Q?BEJE2f1HcGcX1/00wkQtv7SZ2XiDv0kk3RDTRyYj+IwpreYYr5e9OXxJdI5j?=
 =?us-ascii?Q?kbDIlw4FDYuA2hn/VOrl77sqfez1C0asZVCIRhtq6Q31t+GcIsov8OJewAuV?=
 =?us-ascii?Q?xddq999NBTrw+hqd3U79YazeUlhujjJN2fR9?=
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)(7416014)(36860700013)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jun 2025 15:16:45.0276
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 31b0e233-9149-42e7-75f7-08ddaa8d4f20
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:
	DS1PEPF00017099.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB7993

Create a struct header within kernel_info with the contents common to
kernel_info and boot_domain, and define that header in common code. This enables
x86 to use that header as-is and drop x86's boot_domain.

Not a functional change.

Signed-off-by: Alejandro Vallejo 
---
v3:
  * s/bootdomain/boot_domain/
---
 xen/arch/arm/dom0less-build.c           |  8 ++++----
 xen/arch/arm/domain_build.c             | 20 ++++++++++----------
 xen/arch/arm/kernel.c                   |  8 ++++----
 xen/common/device-tree/dom0less-build.c | 18 +++++++++---------
 xen/common/device-tree/domain-build.c   | 20 ++++++++++----------
 xen/common/device-tree/kernel.c         | 20 ++++++++++----------
 xen/include/xen/bootfdt.h               | 10 ++++++++++
 xen/include/xen/fdt-kernel.h            |  5 ++---
 8 files changed, 59 insertions(+), 50 deletions(-)

diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index 20aabf6be5..a335551484 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -32,7 +32,7 @@ static int __init make_gicv2_domU_node(struct kernel_info *kinfo)
     int res = 0;
     __be32 reg[(GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS) * 2];
     __be32 *cells;
-    const struct domain *d = kinfo->d;
+    const struct domain *d = kinfo->hdr.d;
 
     res = domain_fdt_begin_node(fdt, "interrupt-controller",
                                 vgic_dist_base(&d->arch.vgic));
@@ -85,7 +85,7 @@ static int __init make_gicv3_domU_node(struct kernel_info *kinfo)
     void *fdt = kinfo->fdt;
     int res = 0;
     __be32 *reg, *cells;
-    const struct domain *d = kinfo->d;
+    const struct domain *d = kinfo->hdr.d;
     unsigned int i, len = 0;
 
     res = domain_fdt_begin_node(fdt, "interrupt-controller",
@@ -152,7 +152,7 @@ static int __init make_gicv3_domU_node(struct kernel_info *kinfo)
 
 int __init make_intc_domU_node(struct kernel_info *kinfo)
 {
-    switch ( kinfo->d->arch.vgic.version )
+    switch ( kinfo->hdr.d->arch.vgic.version )
     {
 #ifdef CONFIG_GICV3
     case GIC_V3:
@@ -175,7 +175,7 @@ static int __init make_vpl011_uart_node(struct kernel_info *kinfo)
     gic_interrupt_t intr;
     __be32 reg[GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS];
     __be32 *cells;
-    struct domain *d = kinfo->d;
+    struct domain *d = kinfo->hdr.d;
 
     res = domain_fdt_begin_node(fdt, "sbsa-uart", d->arch.vpl011.base_addr);
     if ( res )
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 7096e176ed..4eb1ed0548 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -464,8 +464,8 @@ static int __init write_properties(struct domain *d, struct kernel_info *kinfo,
     int had_dom0_bootargs = 0;
     struct dt_device_node *iommu_node;
 
-    if ( kinfo->cmdline && kinfo->cmdline[0] )
-        bootargs = &kinfo->cmdline[0];
+    if ( kinfo->hdr.cmdline && kinfo->hdr.cmdline[0] )
+        bootargs = &kinfo->hdr.cmdline[0];
 
     /*
      * We always skip the IOMMU device when creating DT for hwdom if there is
@@ -579,7 +579,7 @@ static int __init write_properties(struct domain *d, struct kernel_info *kinfo,
 
     if ( dt_node_path_is_equal(node, "/chosen") )
     {
-        const struct boot_module *initrd = kinfo->initrd;
+        const struct boot_module *initrd = kinfo->hdr.initrd;
 
         if ( bootargs )
         {
@@ -1386,7 +1386,7 @@ int __init make_timer_node(const struct kernel_info *kinfo)
     if ( res )
         return res;
 
-    if ( !is_64bit_domain(kinfo->d) )
+    if ( !is_64bit_domain(kinfo->hdr.d) )
         res = fdt_property_string(fdt, "compatible", "arm,armv7-timer");
     else
         res = fdt_property_string(fdt, "compatible", "arm,armv8-timer");
@@ -1398,7 +1398,7 @@ int __init make_timer_node(const struct kernel_info *kinfo)
      * It always exposes an active-low level-sensitive interrupt.
      */
 
-    if ( is_hardware_domain(kinfo->d) )
+    if ( is_hardware_domain(kinfo->hdr.d) )
     {
         irq[TIMER_PHYS_SECURE_PPI] = timer_get_irq(TIMER_PHYS_SECURE_PPI);
         irq[TIMER_PHYS_NONSECURE_PPI] =
@@ -1447,7 +1447,7 @@ int __init make_chosen_node(const struct kernel_info *kinfo)
 {
     int res;
     const char *bootargs = NULL;
-    const struct boot_module *initrd = kinfo->initrd;
+    const struct boot_module *initrd = kinfo->hdr.initrd;
     void *fdt = kinfo->fdt;
 
     dt_dprintk("Create chosen node\n");
@@ -1455,9 +1455,9 @@ int __init make_chosen_node(const struct kernel_info *kinfo)
     if ( res )
         return res;
 
-    if ( kinfo->cmdline && kinfo->cmdline[0] )
+    if ( kinfo->hdr.cmdline && kinfo->hdr.cmdline[0] )
     {
-        bootargs = &kinfo->cmdline[0];
+        bootargs = &kinfo->hdr.cmdline[0];
         res = fdt_property(fdt, "bootargs", bootargs, strlen(bootargs) + 1);
         if ( res )
            return res;
@@ -1906,7 +1906,7 @@ static int __init construct_dom0(struct domain *d)
     d->max_pages = dom0_mem >> PAGE_SHIFT;
 
     kinfo.unassigned_mem = dom0_mem;
-    kinfo.d = d;
+    kinfo.hdr.d = d;
 
     rc = kernel_probe(&kinfo, NULL);
     if ( rc < 0 )
@@ -1918,7 +1918,7 @@ static int __init construct_dom0(struct domain *d)
 int __init construct_hwdom(struct kernel_info *kinfo,
                            const struct dt_device_node *node)
 {
-    struct domain *d = kinfo->d;
+    struct domain *d = kinfo->hdr.d;
     int rc;
 
     iommu_hwdom_init(d);
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index e734ec5c1e..10e5dcad5e 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -46,7 +46,7 @@ static void __init place_modules(struct kernel_info *info,
                                  paddr_t kernbase, paddr_t kernend)
 {
     /* Align DTB and initrd size to 2Mb. Linux only requires 4 byte alignment */
-    const struct boot_module *mod = info->initrd;
+    const struct boot_module *mod = info->hdr.initrd;
     const struct membanks *mem = kernel_info_get_mem(info);
     const paddr_t initrd_len = ROUNDUP(mod ? mod->size : 0, MB(2));
     const paddr_t dtb_len = ROUNDUP(fdt_totalsize(info->fdt), MB(2));
@@ -152,12 +152,12 @@ static void __init kernel_zimage_load(struct kernel_info *info)
 
     kernel = ioremap_wc(paddr, len);
     if ( !kernel )
-        panic("Unable to map the %pd kernel\n", info->d);
+        panic("Unable to map the %pd kernel\n", info->hdr.d);
 
-    rc = copy_to_guest_phys_flush_dcache(info->d, load_addr,
+    rc = copy_to_guest_phys_flush_dcache(info->hdr.d, load_addr,
                                          kernel, len);
     if ( rc != 0 )
-        panic("Unable to copy the kernel in the %pd memory\n", info->d);
+        panic("Unable to copy the kernel in the %pd memory\n", info->hdr.d);
 
     iounmap(kernel);
 }
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
index 221b875a2f..e321747175 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -167,18 +167,18 @@ static int __init handle_passthrough_prop(struct kernel_info *kinfo,
             return -EINVAL;
         }
 
-        res = iomem_permit_access(kinfo->d, paddr_to_pfn(mstart),
+        res = iomem_permit_access(kinfo->hdr.d, paddr_to_pfn(mstart),
                                   paddr_to_pfn(PAGE_ALIGN(mstart + size - 1)));
         if ( res )
         {
             printk(XENLOG_ERR "Unable to permit to dom%d access to"
                    " 0x%"PRIpaddr" - 0x%"PRIpaddr"\n",
-                   kinfo->d->domain_id,
+                   kinfo->hdr.d->domain_id,
                    mstart & PAGE_MASK, PAGE_ALIGN(mstart + size) - 1);
             return res;
         }
 
-        res = map_regions_p2mt(kinfo->d,
+        res = map_regions_p2mt(kinfo->hdr.d,
                                gaddr_to_gfn(gstart),
                                PFN_DOWN(size),
                                maddr_to_mfn(mstart),
@@ -217,7 +217,7 @@ static int __init handle_passthrough_prop(struct kernel_info *kinfo,
         return -EINVAL;
     }
 
-    res = map_device_irqs_to_domain(kinfo->d, node, true, NULL);
+    res = map_device_irqs_to_domain(kinfo->hdr.d, node, true, NULL);
     if ( res < 0 )
         return res;
 
@@ -229,7 +229,7 @@ static int __init handle_passthrough_prop(struct kernel_info *kinfo,
     if ( xen_force && !dt_device_is_protected(node) )
         return 0;
 
-    return iommu_assign_dt_device(kinfo->d, node);
+    return iommu_assign_dt_device(kinfo->hdr.d, node);
 }
 
 static int __init handle_prop_pfdt(struct kernel_info *kinfo,
@@ -296,14 +296,14 @@ static int __init handle_prop_pfdt(struct kernel_info *kinfo,
                                       address_cells, size_cells);
         if ( res < 0 )
         {
-            printk(XENLOG_ERR "Failed to assign device to %pd\n", kinfo->d);
+            printk(XENLOG_ERR "Failed to assign device to %pd\n", kinfo->hdr.d);
             return res;
         }
     }
     else if ( (xen_path && !xen_reg) || (xen_reg && !xen_path && !xen_force) )
     {
         printk(XENLOG_ERR "xen,reg or xen,path missing for %pd\n",
-               kinfo->d);
+               kinfo->hdr.d);
         return -EINVAL;
     }
 
@@ -605,7 +605,7 @@ static int __init alloc_xenstore_page(struct domain *d)
 
 static int __init alloc_xenstore_params(struct kernel_info *kinfo)
 {
-    struct domain *d = kinfo->d;
+    struct domain *d = kinfo->hdr.d;
     int rc = 0;
 
 #ifdef CONFIG_HVM
@@ -773,7 +773,7 @@ static int __init construct_domU(struct domain *d,
 
     d->max_pages = ((paddr_t)mem * SZ_1K) >> PAGE_SHIFT;
 
-    kinfo.d = d;
+    kinfo.hdr.d = d;
 
     rc = kernel_probe(&kinfo, node);
     if ( rc < 0 )
diff --git a/xen/common/device-tree/domain-build.c b/xen/common/device-tree/domain-build.c
index fa4f700597..6014e39fd6 100644
--- a/xen/common/device-tree/domain-build.c
+++ b/xen/common/device-tree/domain-build.c
@@ -76,7 +76,7 @@ bool __init allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn,
                                  paddr_t tot_size)
 {
     struct membanks *mem = kernel_info_get_mem(kinfo);
-    struct domain *d = kinfo->d;
+    struct domain *d = kinfo->hdr.d;
     struct membank *bank;
 
     /*
@@ -170,7 +170,7 @@ int __init find_unallocated_memory(const struct kernel_info *kinfo,
     unsigned int i, j;
     int res;
 
-    ASSERT(domain_use_host_layout(kinfo->d));
+    ASSERT(domain_use_host_layout(kinfo->hdr.d));
 
     unalloc_mem = rangeset_new(NULL, NULL, 0);
     if ( !unalloc_mem )
@@ -331,23 +331,23 @@ void __init dtb_load(struct kernel_info *kinfo,
     unsigned long left;
 
     printk("Loading %pd DTB to 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
-           kinfo->d, kinfo->dtb_paddr,
+           kinfo->hdr.d, kinfo->dtb_paddr,
            kinfo->dtb_paddr + fdt_totalsize(kinfo->fdt));
 
-    left = copy_to_guest(kinfo->d, kinfo->dtb_paddr,
+    left = copy_to_guest(kinfo->hdr.d, kinfo->dtb_paddr,
                          kinfo->fdt,
                          fdt_totalsize(kinfo->fdt));
 
     if ( left != 0 )
         panic("Unable to copy the DTB to %pd memory (left = %lu bytes)\n",
-              kinfo->d, left);
+              kinfo->hdr.d, left);
     xfree(kinfo->fdt);
 }
 
 void __init initrd_load(struct kernel_info *kinfo,
                         copy_to_guest_phys_cb copy_to_guest)
 {
-    const struct boot_module *mod = kinfo->initrd;
+    const struct boot_module *mod = kinfo->hdr.initrd;
     paddr_t load_addr = kinfo->initrd_paddr;
     paddr_t paddr, len;
     int node;
@@ -363,7 +363,7 @@ void __init initrd_load(struct kernel_info *kinfo,
     len = mod->size;
 
     printk("Loading %pd initrd from %"PRIpaddr" to 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
-           kinfo->d, paddr, load_addr, load_addr + len);
+           kinfo->hdr.d, paddr, load_addr, load_addr + len);
 
     /* Fix up linux,initrd-start and linux,initrd-end in /chosen */
     node = fdt_path_offset(kinfo->fdt, "/chosen");
@@ -386,12 +386,12 @@ void __init initrd_load(struct kernel_info *kinfo,
 
     initrd = ioremap_wc(paddr, len);
     if ( !initrd )
-        panic("Unable to map the %pd initrd\n", kinfo->d);
+        panic("Unable to map the %pd initrd\n", kinfo->hdr.d);
 
-    res = copy_to_guest(kinfo->d, load_addr,
+    res = copy_to_guest(kinfo->hdr.d, load_addr,
                         initrd, len);
     if ( res != 0 )
-        panic("Unable to copy the initrd in the %pd memory\n", kinfo->d);
+        panic("Unable to copy the initrd in the %pd memory\n", kinfo->hdr.d);
 
     iounmap(initrd);
 }
diff --git a/xen/common/device-tree/kernel.c b/xen/common/device-tree/kernel.c
index e1b22dc1c7..7a00768e6b 100644
--- a/xen/common/device-tree/kernel.c
+++ b/xen/common/device-tree/kernel.c
@@ -136,16 +136,16 @@ int __init kernel_probe(struct kernel_info *info,
     /* domain is NULL only for the hardware domain */
     if ( domain == NULL )
     {
-        ASSERT(is_hardware_domain(info->d));
+        ASSERT(is_hardware_domain(info->hdr.d));
 
         mod = boot_module_find_by_kind(BOOTMOD_KERNEL);
 
-        info->kernel = mod;
-        info->initrd = boot_module_find_by_kind(BOOTMOD_RAMDISK);
+        info->hdr.kernel = mod;
+        info->hdr.initrd = boot_module_find_by_kind(BOOTMOD_RAMDISK);
 
         cmd = boot_cmdline_find_by_kind(BOOTMOD_KERNEL);
         if ( cmd )
-            info->cmdline = &cmd->cmdline[0];
+            info->hdr.cmdline = &cmd->cmdline[0];
     }
     else
     {
@@ -162,7 +162,7 @@ int __init kernel_probe(struct kernel_info *info,
                 dt_get_range(&val, node, &kernel_addr, &size);
                 mod = boot_module_find_by_addr_and_kind(
                         BOOTMOD_KERNEL, kernel_addr);
-                info->kernel = mod;
+                info->hdr.kernel = mod;
             }
             else if ( dt_device_is_compatible(node, "multiboot,ramdisk") )
             {
@@ -171,7 +171,7 @@ int __init kernel_probe(struct kernel_info *info,
 
                 val = dt_get_property(node, "reg", &len);
                 dt_get_range(&val, node, &initrd_addr, &size);
-                info->initrd = boot_module_find_by_addr_and_kind(
+                info->hdr.initrd = boot_module_find_by_addr_and_kind(
                         BOOTMOD_RAMDISK, initrd_addr);
             }
             else if ( dt_device_is_compatible(node, "multiboot,device-tree") )
@@ -192,7 +192,7 @@ int __init kernel_probe(struct kernel_info *info,
         name = dt_node_name(domain);
         cmd = boot_cmdline_find_by_name(name);
         if ( cmd )
-            info->cmdline = &cmd->cmdline[0];
+            info->hdr.cmdline = &cmd->cmdline[0];
     }
     if ( !mod || !mod->size )
     {
@@ -201,10 +201,10 @@ int __init kernel_probe(struct kernel_info *info,
     }
 
     printk("Loading %pd kernel from boot module @ %"PRIpaddr"\n",
-           info->d, info->kernel->start);
-    if ( info->initrd )
+           info->hdr.d, info->hdr.kernel->start);
+    if ( info->hdr.initrd )
         printk("Loading ramdisk from boot module @ %"PRIpaddr"\n",
-               info->initrd->start);
+               info->hdr.initrd->start);
 
     /*
      * uImage isn't really used nowadays thereby leave kernel_uimage_probe()
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index 854e7f1ed9..be0abe30ef 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -100,6 +100,16 @@ struct shared_meminfo {
     struct shmem_membank_extra extra[NR_SHMEM_BANKS];
 };
 
+
+struct boot_domain {
+    struct domain *d;
+
+    struct boot_module *kernel;
+    struct boot_module *initrd;
+
+    const char* cmdline;
+};
+
 /*
  * The domU flag is set for kernels and ramdisks of "xen,domain" nodes.
  * The purpose of the domU flag is to avoid getting confused in
diff --git a/xen/include/xen/fdt-kernel.h b/xen/include/xen/fdt-kernel.h
index 12a0b42d17..fee8eac1db 100644
--- a/xen/include/xen/fdt-kernel.h
+++ b/xen/include/xen/fdt-kernel.h
@@ -16,7 +16,7 @@
 #endif
 
 struct kernel_info {
-    struct domain *d;
+    struct boot_domain hdr;
 
     void *fdt; /* flat device tree */
     paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
@@ -34,8 +34,7 @@ struct kernel_info {
     paddr_t gnttab_size;
 
     /* boot blob load addresses */
-    const struct boot_module *kernel, *initrd, *dtb;
-    const char* cmdline;
+    const struct boot_module *dtb;
     paddr_t dtb_paddr;
     paddr_t initrd_paddr;
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 15:16:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 15:16:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014462.1392607 (Exim 4.92)
	(envelope-from )
	id 1uQ69I-0002Wa-3Y; Fri, 13 Jun 2025 15:16:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014462.1392607; Fri, 13 Jun 2025 15: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 1uQ69H-0002VO-Ul; Fri, 13 Jun 2025 15:16:55 +0000
Received: by outflank-mailman (input) for mailman id 1014462;
 Fri, 13 Jun 2025 15:16: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 1uQ69G-0001Mm-Fx
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 15:16:54 +0000
Received: from NAM02-SN1-obe.outbound.protection.outlook.com
 (mail-sn1nam02on20601.outbound.protection.outlook.com
 [2a01:111:f403:2406::601])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6ebf9bf1-4869-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 17:16:52 +0200 (CEST)
Received: from DS7PR03CA0153.namprd03.prod.outlook.com (2603:10b6:5:3b2::8) by
 CY8PR12MB7516.namprd12.prod.outlook.com (2603:10b6:930:94::9) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8835.23; Fri, 13 Jun 2025 15:16:48 +0000
Received: from DS1PEPF00017098.namprd05.prod.outlook.com
 (2603:10b6:5:3b2:cafe::b8) by DS7PR03CA0153.outlook.office365.com
 (2603:10b6:5:3b2::8) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.22 via Frontend Transport; Fri,
 13 Jun 2025 15:16:47 +0000
Received: from SATLEXMB04.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.8835.15 via Frontend Transport; Fri, 13 Jun 2025 15:16:47 +0000
Received: from xcbagarciav01.xilinx.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; Fri, 13 Jun
 2025 10:16:44 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6ebf9bf1-4869-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=xEhTuLQPuXn+hEucg7cOPvu7xQPnzv5JP4wFF7ZA0Edge0/dX0Qbw9h6HNRdGGkZ0NELvIdro9XW4M4Og0LPSeqaQSpnaI0zMCpV7UYUalt4HqZcM7cyOgDGw4Q9zoASuvaxEGWrgXQMHaLjJDl5zr4e6b3mdNmO3ZVSoRalr0RdS0BxIIv/P4x1M2pAajUEH2T7nZKotZY+9Duz2tXs9PsTc98aF6aSz+LrLRxuiH882w13jTdSgjGycvZtlhcFUHpWQi38RhQp/Co7k5X+5GBx6Roh2YAfB0QqDRCMmPJNtY19zoteujo/Au8fgVktvVevTsUolQPfuZ6jMW8qYA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=9xud/1d9pBbDXUNWwaND3LfMeCwbP67tG/BP4SnNhQU=;
 b=nFgRZj4mrzI3Pe8HQyWfyko1ADekiCzB26j4tSN2mK6YI63tkzb+TkTLpvtGAndHWObejYZ9V896m2Q+dVGRBohy/ibpxLyWGPcJ8yjf30ZhJPqNf/5A8C4OoDhmlwLyT0FLCT2luseRTBPaK/W/3p4HVGRWgqF9TbL/jujM4rnbyhLC2FRxdkYw8j9Dn/eJGffSl0G1HY8HPpM3fSPO9TIF6iWlCOvSOK17/xIQvFbGmN+Yk+DoRezfp3X7trghs12/GTjzlCjEA8ieMszSoAP1RgTXrphbNuVsD3FL3wbMcK87LyTU4GDK+EQvCM1o5tSz4vmQt72r6Lqr3gHWNg==
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=9xud/1d9pBbDXUNWwaND3LfMeCwbP67tG/BP4SnNhQU=;
 b=XIQ6GicmcYjVJDLJisXWk//8c+1wx7L+dLmP0ZMc7TiY0YT6uSVUUQLRG4bf7GsyYurnONyUNdYUtuydqebG9LSnn3fIW38Q2RQArJECPr9kyLbkiYL0TOzqyQQAeZdoASSczeep9pBNg5HA3fYb6RggTkUbv4KRtNabVKcRGNs=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Stefano
 Stabellini" , Julien Grall ,
	"Bertrand Marquis" , Michal Orzel
	, "Daniel P. Smith" 
Subject: [PATCH v3 07/14] x86: Replace arch-specific boot_domain common one bootdomain
Date: Fri, 13 Jun 2025 17:13:16 +0200
Message-ID: <20250613151612.754222-8-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250613151612.754222-1-agarciav@amd.com>
References: <20250613151612.754222-1-agarciav@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: DS1PEPF00017098:EE_|CY8PR12MB7516:EE_
X-MS-Office365-Filtering-Correlation-Id: 02664675-41ad-413a-5189-08ddaa8d5090
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?qVCw8Haq8uvThLSrtQaWvsH1rLLSgnd0Sv/q2jI1blxKYVOC1E16UC020Ke3?=
 =?us-ascii?Q?GsIRhxaMDUs5A+EEWRgAle2OXcjwFR+Cgw1lJknkXdKlxIlvejeCO0Udq3KO?=
 =?us-ascii?Q?CCORadM6wh14jESXKCavAE2rH5z3oR2u2uaM7TkJOIGDyXfyczW1zfnhzqDr?=
 =?us-ascii?Q?sp7vF9R1e2lICEMiURG/L6YsG6oeY1kGxU5qOxNvt9uoLqxXtbCr6qgQWttA?=
 =?us-ascii?Q?4+Cx3LuaMudDu14KOHjOUJ+RuY+saKFU7nXXK+6zdhrHz3fr2winhRGdn4p5?=
 =?us-ascii?Q?yi8n2KKHiO2vaXlIUxSWO7Jc7FHZpX8Ks3MQt9pJCm/kSwsgjzmF9txqHivF?=
 =?us-ascii?Q?/aWUopca3Eqe+tugbTTDwwzoYTu7hpeyw18L3UhR0BqT8IskeWGD8LFQbJ5D?=
 =?us-ascii?Q?4RULkrsLkf3o3vp9ni30hGNs4v+jJ+3f1kziiitG8QNyEKDFeFhU8fNVWvtc?=
 =?us-ascii?Q?BSM7BTacDkIMxUcz5MBXCdubxmNKN9ipTLhs9oLqKlRHNMhMnpe9h+nO/E/S?=
 =?us-ascii?Q?xOZQd9Yq/lD0II9txk5jqyqG/KGuuH2uhT0Wf/XBmN/2c9eDVNZOfW1FxiiN?=
 =?us-ascii?Q?ugkCad5XnX6bKRnbsyUifquVRygaFbmDUHJMdPXhQ5NXxAayQ8myb9ap5jJq?=
 =?us-ascii?Q?pMla6NHdy8NVBmkPaHtNYrhK2l9GsrNpFzsIIv38mhkPkIygKuhOLwT51lq+?=
 =?us-ascii?Q?RGsvzk60lX0xNUQuCq7vxcz/ptrYKpysEuq/+Okcj/jyDNu1qw6WWMFVCw8i?=
 =?us-ascii?Q?aa7VjZb9eFtdIl7tDIKaMX1xqYKE2ULIFWx452ughz0jLncGOFrFWG01GCvi?=
 =?us-ascii?Q?EwyVTFvZ+q/02htzKQrIUYLiRDCoWSY2FLiMlklvf32y9svv32fArqG1b9Mk?=
 =?us-ascii?Q?x0I5U+uWjGxn/SIU5mHgGwemeyUqvOHSsykk+SS+GVB+RC1GWplHfz5UN3kV?=
 =?us-ascii?Q?hvWx64UFDZND2fBsRWSUSwtwNJLBEo1gilU+Xb6U5q0ckUh02chEFnDC9Na7?=
 =?us-ascii?Q?Ope6hqcS0Vp8IuODBoj/uuPl2ZCrBOWpAZMGFkF41T3ZwcZrCy5IxGDmsuLg?=
 =?us-ascii?Q?ZY2lrOdyKadTCsd1alY9M6Lh4Yv3ZLN02gTaVj7jG2TlvjwMIaY1WFoI6ucm?=
 =?us-ascii?Q?zxb7aw6HGcxLtIReLVOmYvsGovAE/uHLjOMGaXx6uiO42xPaJJK/rWUH7BVL?=
 =?us-ascii?Q?r4yyQc0n19/D1NDAdupzqdVtmmknCmyEr9Fe4qU3sJEt/mNJtH80YRHAJHUY?=
 =?us-ascii?Q?dimvaJmUDHopO0WWFBKpmPWqYibNejhET9UelS94r60bewCdLvR6h9CSi6ZP?=
 =?us-ascii?Q?mNytNoe2gMBNJRn1FulvA4K146PPju1S/3YApHQip/Simk9077DdNqlcY+ZC?=
 =?us-ascii?Q?CvlwzbEBaxLac6HyKaJBSsqRzQ866yhGjZXUlT0Oh3EORueP4nlBhgf2A1n3?=
 =?us-ascii?Q?OTQ8g60/NbUuK78T/BVbdigZFggrz66LtFvWsSKY7WIK0RiyZU4+y0Be95fZ?=
 =?us-ascii?Q?hToZ2PP33ZsIWmR0MyIO7SPi+3QimX6otDED?=
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: 13 Jun 2025 15:16:47.4410
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 02664675-41ad-413a-5189-08ddaa8d5090
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:
	DS1PEPF00017098.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7516

Add the single arch-specific field in an "arch" subfield defined in
asm/bootfdt.h.

No functional change intended.

Signed-off-by: Alejandro Vallejo 
---
v3:
  * Avoid the bootdomain/boot_domain renames.
---
 xen/arch/x86/include/asm/boot-domain.h | 33 --------------------------
 xen/arch/x86/include/asm/bootfdt.h     |  6 +++++
 xen/arch/x86/include/asm/bootinfo.h    |  1 -
 xen/arch/x86/setup.c                   | 12 ++++++----
 xen/include/xen/bootfdt.h              |  4 ++++
 5 files changed, 17 insertions(+), 39 deletions(-)
 delete mode 100644 xen/arch/x86/include/asm/boot-domain.h

diff --git a/xen/arch/x86/include/asm/boot-domain.h b/xen/arch/x86/include/asm/boot-domain.h
deleted file mode 100644
index d7c6042e25..0000000000
--- a/xen/arch/x86/include/asm/boot-domain.h
+++ /dev/null
@@ -1,33 +0,0 @@
-/* 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__
-
-#include 
-
-struct boot_domain {
-    domid_t domid;
-
-    struct boot_module *kernel;
-    struct boot_module *module;
-    const char *cmdline;
-
-    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/bootfdt.h b/xen/arch/x86/include/asm/bootfdt.h
index a4c4bf30b9..c21dbe961b 100644
--- a/xen/arch/x86/include/asm/bootfdt.h
+++ b/xen/arch/x86/include/asm/bootfdt.h
@@ -3,6 +3,12 @@
 #define X86_BOOTFDT_H
 
 #include 
+#include 
+
+struct arch_boot_domain
+{
+    domid_t domid;
+};
 
 struct arch_boot_module
 {
diff --git a/xen/arch/x86/include/asm/bootinfo.h b/xen/arch/x86/include/asm/bootinfo.h
index d33b100e04..4f2cc5906e 100644
--- a/xen/arch/x86/include/asm/bootinfo.h
+++ b/xen/arch/x86/include/asm/bootinfo.h
@@ -12,7 +12,6 @@
 #include 
 #include 
 #include 
-#include 
 
 /* Max number of boot modules a bootloader can provide in addition to Xen */
 #define MAX_NR_BOOTMODS 63
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index c00b22205a..f1b11028b5 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -297,7 +297,9 @@ static const char *cmdline_cook(const char *p, const char *loader_name);
 struct boot_info __initdata xen_boot_info = {
     .loader = "unknown",
     .cmdline = "",
-    .domains = { [0 ... MAX_NR_BOOTDOMS - 1] = { .domid = DOMID_INVALID } },
+    .domains = { [0 ... MAX_NR_BOOTDOMS - 1] = {
+        .arch.domid = DOMID_INVALID
+    }},
     /*
      * There's a MAX_NR_BOOTMODS-th entry in the array. It's not off by one.
      *
@@ -1039,11 +1041,11 @@ 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();
-    d = domain_create(bd->domid, &dom0_cfg,
+    bd->arch.domid = get_initial_domain_id();
+    d = domain_create(bd->arch.domid, &dom0_cfg,
                       pv_shim ? 0 : CDF_privileged | CDF_hardware);
     if ( IS_ERR(d) )
-        panic("Error creating d%u: %ld\n", bd->domid, PTR_ERR(d));
+        panic("Error creating d%u: %ld\n", bd->arch.domid, PTR_ERR(d));
 
     init_dom0_cpuid_policy(d);
 
@@ -2162,7 +2164,7 @@ void asmlinkage __init noreturn __start_xen(void)
     if ( initrdidx < MAX_NR_BOOTMODS )
     {
         bi->mods[initrdidx].kind = BOOTMOD_RAMDISK;
-        bi->domains[0].module = &bi->mods[initrdidx];
+        bi->domains[0].initrd = &bi->mods[initrdidx];
         if ( first_boot_module_index(bi, BOOTMOD_UNKNOWN) < MAX_NR_BOOTMODS )
             printk(XENLOG_WARNING
                    "Multiple initrd candidates, picking module #%u\n",
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index be0abe30ef..8ea52290b7 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -108,6 +108,10 @@ struct boot_domain {
     struct boot_module *initrd;
 
     const char* cmdline;
+
+#if __has_include()
+    struct arch_boot_domain arch;
+#endif
 };
 
 /*
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 15:16:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 15:16:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014463.1392617 (Exim 4.92)
	(envelope-from )
	id 1uQ69L-0002y4-AP; Fri, 13 Jun 2025 15:16:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014463.1392617; Fri, 13 Jun 2025 15:16:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uQ69L-0002xo-6i; Fri, 13 Jun 2025 15:16:59 +0000
Received: by outflank-mailman (input) for mailman id 1014463;
 Fri, 13 Jun 2025 15:16: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 1uQ69J-0001Mm-TA
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 15:16:57 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20618.outbound.protection.outlook.com
 [2a01:111:f403:2413::618])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 707f9579-4869-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 17:16:55 +0200 (CEST)
Received: from DM6PR02CA0125.namprd02.prod.outlook.com (2603:10b6:5:1b4::27)
 by PH7PR12MB6443.namprd12.prod.outlook.com (2603:10b6:510:1f9::5) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.40; Fri, 13 Jun
 2025 15:16:50 +0000
Received: from DS1PEPF00017096.namprd05.prod.outlook.com
 (2603:10b6:5:1b4:cafe::af) by DM6PR02CA0125.outlook.office365.com
 (2603:10b6:5:1b4::27) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.25 via Frontend Transport; Fri,
 13 Jun 2025 15:16:49 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 DS1PEPF00017096.mail.protection.outlook.com (10.167.18.100) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Fri, 13 Jun 2025 15:16:49 +0000
Received: from xcbagarciav01.xilinx.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; Fri, 13 Jun
 2025 10:16:47 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 707f9579-4869-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=FNt6MSrHIWkXeI8ynO5YJc3tI5GLJcJgNE1F2+VSHeOB4Fg3jxkSOkCE9BgKeQDaX5yxNxSl9xyGU+d8SajE2kyZOgBi1UBH6sLnnL4nMFjnnDoBsu08pmfx9z+4I9hKvkyrxf0zyztM7paQ96aQpE4yXpz2LK7+MIQR/yWzgIpjCvcZ5RtLagInil4JHCp3Cued4HcnMYywhh+7O16Twbs48ehkPtg4mP5a4vx5UoHIrpdLueEucYVYanmyiyvnz9eyyUE4Wyb7TH17MD5vxV0oHv5+LhdYell6WHvsoBr/B0LXdeVc4naTIEwAw3QxUH7ew7uLkx7tw3ghDWXFgQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Nv7HefR3nJ9xc+neaNOBWQ3D4cmv4f7mosLJypHGoOA=;
 b=ViuRhRSLgAdpTxmw2b8qA4aI5fEwZRARUrN1ncSAdrlknFzall8ycSgv8FhVqf2ab/9RXxPYRUJzsu1huS3divj6XZwZYQXVRF65jI4MZ3yvOyRG9H96fvvOnmK078oq0iDSd7o6DdmO7wv+1fjaW3BYBnOp0lfoJVydXMD6M/0fxP9YRWJr5FDhQpZHWPwhv8OsIfTpBcXyoGtwIUsHNEofJp8T/taOR0LQPRiQID4MJcqyPNm5N6+28tMy3tNNmIlCYCTVc44qAr+2hEHyhctHlZswF4uQGAq8ZQB81q1HN9q7hYBBwDZ4sialnSq2smkmkE+JiYKNCoi04gBm7w==
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=Nv7HefR3nJ9xc+neaNOBWQ3D4cmv4f7mosLJypHGoOA=;
 b=LCv2rmTDEyr5kz/j2eo726CgbR9Wv+IGvbCu60odiiynl+GXvQht0x9pBOOz8Fvo6PJyJ0oek62PuW43I1FzKDvFbCP0y/cG3Y6ZXVEYBHQe3Yma2om+LBMGsgfAHuoIftWMrqZh/SPqoVHoNtUskmZEzOihMcB0SRAlvUp1Qgo=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Daniel P.
 Smith" 
Subject: [PATCH v3 08/14] xen/dt: Move bootfdt functions to xen/bootfdt.h
Date: Fri, 13 Jun 2025 17:13:17 +0200
Message-ID: <20250613151612.754222-9-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250613151612.754222-1-agarciav@amd.com>
References: <20250613151612.754222-1-agarciav@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: DS1PEPF00017096:EE_|PH7PR12MB6443:EE_
X-MS-Office365-Filtering-Correlation-Id: 6f08ef3f-b1a2-4ef4-ff27-08ddaa8d519a
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?WKBKXzLaknyAR79cyhsHyMTVhMKAWibAZnIJ8IXDsNlpto2EhBQSxr0O1xkR?=
 =?us-ascii?Q?1vn/Zv+OhvoEToKg4Y6F10JNmOyyTW74uwnTBdrKWR7A0jLUBCaqi/iGc6fv?=
 =?us-ascii?Q?Ye2PKeJcgm7LBg8WVQcpWbj47GNCbIQ0PsIpAnn+EppIlcYfJGd+z8JL9fVY?=
 =?us-ascii?Q?etL8Jtoas1yYkQCqJuqcp6h4pFzJ6IUcDoTsYoy56H/hkOQL2a3e3opSDVMB?=
 =?us-ascii?Q?4PpZIpisByo+zfcSjul6S2edhnJWSFRn3NwUd1RZU4LBaDOQIMQpQqVXpZ+R?=
 =?us-ascii?Q?qxwHZphN9QR5iPfSOOEo/sFIpSmDcC64fD/eEnIX2YaV098o7QEshROSsogk?=
 =?us-ascii?Q?0Cn7SCySguLrIusYksJThzpfr2exCljbOxR8OqxQEGqMQPJOSHcYFJO4dmnq?=
 =?us-ascii?Q?I3TQcYkQIMSGtKtbofJpBYX4J+E4Q1XTwyx/gy2tCtNZHxLLdrLfl3nd1+WB?=
 =?us-ascii?Q?JS1QNwmL63rUcq3qXM8KOaTry02MJJK2W7YKu5RhaPzI31v8D9dh19krMoxd?=
 =?us-ascii?Q?jEpNZw2YcQ3CHqpvRUew5OK2E/OTXm3YIytHdicsgRASif2hXgoilmpPDdEi?=
 =?us-ascii?Q?WufBMYXnvA1ey2oSAfRDR1T24HD4Uq3P2x0jl1AvM5wdrQcF2Znn71I+oh/8?=
 =?us-ascii?Q?MoPJouDhYvYGHlBva6LGVrqAXWavPJXoezuDTb7XzF3Bh79f0agPmCajq3Q9?=
 =?us-ascii?Q?QAsX8OrVULhmYGJaKFMCB6wXHk7pIl8vCwZkR8dn7/1uK2q+N9eZCxSxy2rK?=
 =?us-ascii?Q?3/nLEReQ042gRYL+kA8axCGIPOhqomFZ1rqyevMwaX22AGn1B/2RRowb0hJQ?=
 =?us-ascii?Q?mrOADpqa7RXINeQqg2y1LHLzB4NqK8tpik/h79F9+h9pWAUTFlA6KgTP+Knr?=
 =?us-ascii?Q?eauTkKV9Ie91oPRqiCyaGavDbdOR8CQaArQuU/Q8CLKseTLvse+3QIkEyMp0?=
 =?us-ascii?Q?/tjOoySCZHC6E1rF3vmwgOlCTAnUxBlrvsdz3eRbOfJUpJJHRRj0vwma+aTF?=
 =?us-ascii?Q?LOVhaV4YKT1gEFtnfl5qNTfWXoC4v7jQV+21Eu/gtyKEsXfbJVyrgs4LFr1k?=
 =?us-ascii?Q?P5pGmKuKPbkb24j8iw+USfS7U5A85/8askFGWbEuDr8qaPA/pMwHzaWc8+1y?=
 =?us-ascii?Q?Kri3tcJ6Czo+1i1FiUTTGzjZ/hKjAqnAdyWoUDSB/zXalt5VHAFnb2zA61QW?=
 =?us-ascii?Q?rCseWp2PkN2d9apVCqK3zvT3I3XKjijs+UBX0AqPm0tspjcXZ2ZAolOmrMfm?=
 =?us-ascii?Q?06D1RM0ZhiS7UdRST9qG8eFuUfmpXAW1Dqk6NPV6HS3+fCqXSRNBEF6kZTcL?=
 =?us-ascii?Q?v9J0bt7uESUc1khFOrgdAlVrhNiBSVQ2pSmPEIAg+RSdkqYUZSAVhe9EVZ65?=
 =?us-ascii?Q?faq9WZ4hIp36oD6H5K79X4kTgj2rkP9xxoMp75crUZkd2d0rDmVDXaSt79O+?=
 =?us-ascii?Q?T2tvEedzWTNLoBMi3eRzmVgNMqXYI+LdtRvMUftsnx4HeKpVMgJV1qbVza8w?=
 =?us-ascii?Q?dTIrfaZFMvNI/asxLyWw5qK6uGIVg9hM86rR?=
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: 13 Jun 2025 15:16:49.1892
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 6f08ef3f-b1a2-4ef4-ff27-08ddaa8d519a
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:
	DS1PEPF00017096.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6443

Part of an unpicking process to extract bootfdt contents independent of bootinfo
to a separate file for x86 to take.

Move functions required for early FDT parsing from device_tree.h and arm's
setup.h onto bootfdt.h

Declaration motion only. Not a functional change.

Signed-off-by: Alejandro Vallejo 
---
v3:
  * Avoid mutations during code motion
---
 xen/include/xen/bootfdt.h     | 62 +++++++++++++++++++++++++++++++++++
 xen/include/xen/device_tree.h | 40 +---------------------
 2 files changed, 63 insertions(+), 39 deletions(-)

diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index 8ea52290b7..b6ae7d6aa6 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -2,6 +2,7 @@
 #ifndef XEN_BOOTFDT_H
 #define XEN_BOOTFDT_H
 
+#include 
 #include 
 #include 
 #include 
@@ -16,8 +17,53 @@
 #define NR_MEM_BANKS 256
 #define NR_SHMEM_BANKS 32
 
+/* Default #address and #size cells */
+#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
+#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
+
 #define MAX_MODULES 32 /* Current maximum useful modules */
 
+#define DEVICE_TREE_MAX_DEPTH 16
+
+/* Helper to read a big number; size is in cells (not bytes) */
+static inline u64 dt_read_number(const __be32 *cell, int size)
+{
+    u64 r = 0;
+
+    while ( size-- )
+        r = (r << 32) | be32_to_cpu(*(cell++));
+    return r;
+}
+
+static inline u64 dt_next_cell(int s, const __be32 **cellp)
+{
+    const __be32 *p = *cellp;
+
+    *cellp = p + s;
+    return dt_read_number(p, s);
+}
+
+typedef int (*device_tree_node_func)(const void *fdt,
+                                     int node, const char *name, int depth,
+                                     u32 address_cells, u32 size_cells,
+                                     void *data);
+
+/**
+ * device_tree_for_each_node - iterate over all device tree sub-nodes
+ * @fdt: flat device tree.
+ * @node: parent node to start the search from
+ * @func: function to call for each sub-node.
+ * @data: data to pass to @func.
+ *
+ * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
+ *
+ * Returns 0 if all nodes were iterated over successfully.  If @func
+ * returns a value different from 0, that value is returned immediately.
+ */
+int device_tree_for_each_node(const void *fdt, int node,
+                              device_tree_node_func func,
+                              void *data);
+
 typedef enum {
     BOOTMOD_XEN,
     BOOTMOD_FDT,
@@ -260,4 +306,20 @@ static inline struct membanks *membanks_xzalloc(unsigned int nr,
     return banks;
 }
 
+/*
+ * Interpret the property `prop_name` of `node` as a u32.
+ *
+ * Returns the property value on success; otherwise returns `dflt`.
+ */
+u32 device_tree_get_u32(const void *fdt, int node,
+                        const char *prop_name, u32 dflt);
+
+/*
+ * Interpret the property `prop_name` of `node` as a "reg".
+ *
+ * Returns outputs in `start` and `size`.
+ */
+void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
+                         uint32_t size_cells, paddr_t *start, paddr_t *size);
+
 #endif /* XEN_BOOTFDT_H */
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 75017e4266..0a22b1ba1d 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -10,6 +10,7 @@
 #ifndef __XEN_DEVICE_TREE_H__
 #define __XEN_DEVICE_TREE_H__
 
+#include 
 #include 
 
 #include 
@@ -22,8 +23,6 @@
 #include 
 #include 
 
-#define DEVICE_TREE_MAX_DEPTH 16
-
 /*
  * Struct used for matching a device
  */
@@ -164,17 +163,8 @@ struct dt_raw_irq {
     u32 specifier[DT_MAX_IRQ_SPEC];
 };
 
-typedef int (*device_tree_node_func)(const void *fdt,
-                                     int node, const char *name, int depth,
-                                     u32 address_cells, u32 size_cells,
-                                     void *data);
-
 extern const void *device_tree_flattened;
 
-int device_tree_for_each_node(const void *fdt, int node,
-                              device_tree_node_func func,
-                              void *data);
-
 /**
  * dt_unflatten_host_device_tree - Unflatten the host device tree
  *
@@ -245,10 +235,6 @@ void intc_dt_preinit(void);
 #define dt_node_cmp(s1, s2) strcasecmp((s1), (s2))
 #define dt_compat_cmp(s1, s2) strcasecmp((s1), (s2))
 
-/* Default #address and #size cells */
-#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
-#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
-
 #define dt_for_each_property_node(dn, pp)                   \
     for ( pp = (dn)->properties; (pp) != NULL; pp = (pp)->next )
 
@@ -258,16 +244,6 @@ void intc_dt_preinit(void);
 #define dt_for_each_child_node(dt, dn)                      \
     for ( dn = (dt)->child; (dn) != NULL; dn = (dn)->sibling )
 
-/* Helper to read a big number; size is in cells (not bytes) */
-static inline u64 dt_read_number(const __be32 *cell, int size)
-{
-    u64 r = 0;
-
-    while ( size-- )
-        r = (r << 32) | be32_to_cpu(*(cell++));
-    return r;
-}
-
 /* Wrapper for dt_read_number() to return paddr_t (instead of uint64_t) */
 static inline paddr_t dt_read_paddr(const __be32 *cell, int size)
 {
@@ -307,14 +283,6 @@ static inline int dt_size_to_cells(int bytes)
     return (bytes / sizeof(u32));
 }
 
-static inline u64 dt_next_cell(int s, const __be32 **cellp)
-{
-    const __be32 *p = *cellp;
-
-    *cellp = p + s;
-    return dt_read_number(p, s);
-}
-
 static inline const char *dt_node_full_name(const struct dt_device_node *np)
 {
     return (np && np->full_name) ? np->full_name : "";
@@ -949,12 +917,6 @@ int dt_get_pci_domain_nr(struct dt_device_node *node);
 
 struct dt_device_node *dt_find_node_by_phandle(dt_phandle handle);
 
-void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
-                         uint32_t size_cells, paddr_t *start, paddr_t *size);
-
-u32 device_tree_get_u32(const void *fdt, int node,
-                        const char *prop_name, u32 dflt);
-
 #ifdef CONFIG_DEVICE_TREE_DEBUG
 #define dt_dprintk(fmt, args...)  \
     printk(XENLOG_DEBUG fmt, ## args)
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 15:17:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 15:17:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014466.1392627 (Exim 4.92)
	(envelope-from )
	id 1uQ69N-0003Io-Id; Fri, 13 Jun 2025 15:17:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014466.1392627; Fri, 13 Jun 2025 15: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 1uQ69N-0003IX-EZ; Fri, 13 Jun 2025 15:17:01 +0000
Received: by outflank-mailman (input) for mailman id 1014466;
 Fri, 13 Jun 2025 15:16: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 1uQ69L-0000Kb-G3
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 15:16:59 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20623.outbound.protection.outlook.com
 [2a01:111:f403:2412::623])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 716e6506-4869-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 17:16:57 +0200 (CEST)
Received: from DS7PR03CA0174.namprd03.prod.outlook.com (2603:10b6:5:3b2::29)
 by MN0PR12MB6001.namprd12.prod.outlook.com (2603:10b6:208:37d::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.23; Fri, 13 Jun
 2025 15:16:53 +0000
Received: from DS1PEPF00017099.namprd05.prod.outlook.com
 (2603:10b6:5:3b2:cafe::1d) by DS7PR03CA0174.outlook.office365.com
 (2603:10b6:5:3b2::29) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.23 via Frontend Transport; Fri,
 13 Jun 2025 15:16:52 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 DS1PEPF00017099.mail.protection.outlook.com (10.167.18.103) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Fri, 13 Jun 2025 15:16:52 +0000
Received: from xcbagarciav01.xilinx.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; Fri, 13 Jun
 2025 10:16:48 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 716e6506-4869-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=C7kGyY+86JEmuwlqUDAYaO3UO0t/hCZcjzeoWENkslylKwwsjiSeetogTkf2Aa/EpbnNZ8QRUzv2BzMPRsc8TjV/RMGMBxAusEU9BJ1v2G3hzvi/e3szy430ZaG52EvHeUtUyrvUyRMVHs+bzL9auX0rPBtWKEg6zb7cmuoQQJzfg5d1mVhXd41bxU3hh1XeI/Mgj1HMwsXSW/LBE+aor2gyTMnNP+ynOj6ExiubHUw5Qa7NZnzV7wvIyEP6DeIOTmUmSD2CXJpKxN7PTUyLm8nWVhm3eTh7Xgzngvr/SHLpwkR/C6kbX9ifYVStxlePnWewrjcQ7JH6YBFOz6KzsQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=gqa711ud/gT5kwpGl0L7NZOMPRD7hoTJv+jyvoVvM74=;
 b=Ey5K2udFytN8DLoeyAo9jteAIFUx/fmkazTHTAUdv8apR3Fom9lyuyVQggXGi9MlLsIgFMnSSSaBsgQOF2gJGzfaHO788sQIkP51wG8kheDPxwV5A1i1She3NlVgHnTa63b+O7X4NmXOYgis2m4nhoIWbejZThwQx1xq1mKo30YxxHrJhy//Ha4/NYzkiFYxqRU27qdOBXTgRqZM5PPVbk/une9a4Py/dpUhf5dSJ02VDJ6dQUBBe8MyfOz7i0rRk2Fl8e/HWQQU4hqSqXol3f+2RLAbkIxyPZc7lbdAdu3rjBDhg2T0VSJi44nzl3dsLfEcOcPx+/pWtHUqQEma4w==
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=gqa711ud/gT5kwpGl0L7NZOMPRD7hoTJv+jyvoVvM74=;
 b=iV3HShoAUJjPDsipmqxQyEgwKkevM68kF3B6V5bibP3w/+l5G+kMOv1Db1dvIX22V4lpuiiacyBO26efs4jYOMSNRG09T94GX/ShX6RZrTnBYhyaZyVJnTDqqq4ogEBiSxE7MZAn6iLUXSzwNyb918bh9EU4SZfkwFg4VuVXlIc=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , 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"
	
Subject: [PATCH v3 09/14] xen/dt: Move bootinfo functions to a new bootinfo.h
Date: Fri, 13 Jun 2025 17:13:18 +0200
Message-ID: <20250613151612.754222-10-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250613151612.754222-1-agarciav@amd.com>
References: <20250613151612.754222-1-agarciav@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: DS1PEPF00017099:EE_|MN0PR12MB6001:EE_
X-MS-Office365-Filtering-Correlation-Id: 9742bea9-2ced-4c20-3e16-08ddaa8d538f
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|82310400026|376014|7416014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?AZDMOp4g5M+qdA7kJ694Q4fhefL7ydGF3F7pkEcbiUohT27iQEnDLc6dNy1F?=
 =?us-ascii?Q?uXomHZjP5LlmiIM+D0/Iy+fvqPIO3o5/OgOdKo6/3YH5ZMovIdZpxcDHjhfZ?=
 =?us-ascii?Q?TPQ/9IeWJOKbRAwO0xzyJe6eXRpTjS806+Ys2Y1vM5+EiMrtG+tVhdZslaP1?=
 =?us-ascii?Q?1D/MVoCa8YCZX5+lFPIh6PmdW7uQD9RV7ppqZP9QNvrzzEbsRqqeewDovP0y?=
 =?us-ascii?Q?UUELmd/nddmW6fz2RGdF919LARjfLzqe5ofAwhLyk8N5xOQ5B5S+5zEeGpMy?=
 =?us-ascii?Q?K78ksYZcgalQ7nSLz/n3B0ZGLqxOQtqI2epuAf2U5RpEtrN86WiH8EBA8F8X?=
 =?us-ascii?Q?ax7D++/qquKcVTXWK1RBsVnaCh6c7SNeONGYgwpSjVrqM4ejY4hmrLYb2rIm?=
 =?us-ascii?Q?16pxAag73Az28Vj4wJnCumg0r8Cby30QkhsS4RivqLTB6OBS5hvov5xOao20?=
 =?us-ascii?Q?3biOAnRYmziRQlks0bi0jAsO3u/Sm/QAWx2jJ6DrQtMazkSUvQVz8w9LR4eB?=
 =?us-ascii?Q?hBHR9HNLBDZqFv9YvpVUjL12nPSzzXhqyFwipvMUDl6GdPnw666+IwnF/Rzs?=
 =?us-ascii?Q?mJdLjZIIKj0uU5rRSoh1GOoYMz8nb/PahY1tdtOCqKiRnwirmeyFP6JfSheE?=
 =?us-ascii?Q?Bm46pnJQ9C7aoXD7LczdHzTW6PfIuOSIOeUXru8O8QIAIwfu8e3R1F9iiC+D?=
 =?us-ascii?Q?z67H7SXQ2N6FXbYdlD/teywlJViaacsgRc/ORkquhGJ73SsYQ/CpZTE5KZy6?=
 =?us-ascii?Q?ysmAgyqXUNmc9v1QIzbDhp9xP02pbsMG0quyHESsDIvqA3diKVpo21KEg+MO?=
 =?us-ascii?Q?1y5goJMQQsa91bPe5slDd2uSYJicl20NQDDqR7Rtf9uUxKGe8NHiR4Q9k9Za?=
 =?us-ascii?Q?NMWDvPk2mtEO9jjFKf8jVU/LlqIuBE7VnLaxP2z+HahG0ksO0mywjejLS6us?=
 =?us-ascii?Q?2xMmEIh4MGHPbPffWfjivVPbuXq1bgk8JPwx4tSUoHeeVRp7Zf4m2iFgFj2i?=
 =?us-ascii?Q?KE9wusM9MTQnUunWyqhudgAhWvRy9pl9hwIKUpHNJEjmAIX0Eg9SZIMCW50p?=
 =?us-ascii?Q?pD/G0BPG6SkJhYrD/jd6ueaz5A4nH60Vp93+3ikaPPyCKH7HPAHvYKa/D8RC?=
 =?us-ascii?Q?1P5q8iKYn4Tgz85u+ZgChkh8LKViTwlw/no/OnPZHk2K/DBA7fOLFnoYJhUL?=
 =?us-ascii?Q?xeq47rOyc/Duhbzsus77i6Rc7f6b395xEQ8msQye+X4VXlyqs3q7pgv1ubDg?=
 =?us-ascii?Q?Sdh/9gmFteJTGqY1cLGy+m6LGVhgUzvcEYyhqJgGOKLzmG9JPOpX/CQ1wNbV?=
 =?us-ascii?Q?zfO56O0VGIsBWGDMyJWCq6uwg1lC/Ve+Z5Jhg3lu+CpnwPj5j5uBEqsAeXjq?=
 =?us-ascii?Q?kKCLGj+tT2scjRHwmd6snsUKt+gajUmjC9fB2jj4Q/ljfUfhQCdd+7pRGySo?=
 =?us-ascii?Q?Hj0kx8hHcC7yH0XXvWOcjWGLWew37ljWFJfI6CewYlycKg+igH7iXfPqPmQ1?=
 =?us-ascii?Q?d3i5/ud5Cd6XVP3LXX86ihlchazA5QZcaZgw?=
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)(7416014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jun 2025 15:16:52.4677
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9742bea9-2ced-4c20-3e16-08ddaa8d538f
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:
	DS1PEPF00017099.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6001

Part of an unpicking process to extract bootfdt contents independent of
bootinfo to a separate file for x86 to take.

With this, bootfdt.h can be cleanly included from x86. A later patch
extracts the definitions so the functions may be called too.

Not a functional change.

Signed-off-by: Alejandro Vallejo 
---
v3:
  * Remove spurious include for bootinfo.h in mmu/mm.c
---
 xen/arch/arm/domain_build.c             |   1 +
 xen/arch/arm/setup.c                    |   1 +
 xen/arch/riscv/mm.c                     |   2 +-
 xen/arch/riscv/setup.c                  |   2 +-
 xen/common/device-tree/bootfdt.c        |   2 +-
 xen/common/device-tree/bootinfo.c       |   2 +-
 xen/common/device-tree/dom0less-build.c |   2 +-
 xen/common/device-tree/domain-build.c   |   2 +-
 xen/common/device-tree/kernel.c         |   2 +-
 xen/include/xen/bootfdt.h               | 208 -----------------------
 xen/include/xen/bootinfo.h              | 213 ++++++++++++++++++++++++
 xen/include/xen/device_tree.h           |   2 +-
 xen/include/xen/fdt-domain-build.h      |   2 +-
 xen/include/xen/fdt-kernel.h            |   2 +-
 14 files changed, 225 insertions(+), 218 deletions(-)
 create mode 100644 xen/include/xen/bootinfo.h

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 4eb1ed0548..4eb1b12916 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1,5 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 8b2e65a1a5..cc5e1be223 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -8,6 +8,7 @@
  * Copyright (c) 2011 Citrix Systems.
  */
 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
index 4047d67c0e..6ccd38091b 100644
--- a/xen/arch/riscv/mm.c
+++ b/xen/arch/riscv/mm.c
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 8bcd19218d..3e99e2e194 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -2,7 +2,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
index 39334d6205..1848478e82 100644
--- a/xen/common/device-tree/bootfdt.c
+++ b/xen/common/device-tree/bootfdt.c
@@ -5,7 +5,7 @@
  * Copyright (C) 2012-2014 Citrix Systems, Inc.
  */
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/device-tree/bootinfo.c b/xen/common/device-tree/bootinfo.c
index 2a27d1318b..00a43fb358 100644
--- a/xen/common/device-tree/bootinfo.c
+++ b/xen/common/device-tree/bootinfo.c
@@ -10,7 +10,7 @@
  */
 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
index e321747175..4413b17aac 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/device-tree/domain-build.c b/xen/common/device-tree/domain-build.c
index 6014e39fd6..0da598eac1 100644
--- a/xen/common/device-tree/domain-build.c
+++ b/xen/common/device-tree/domain-build.c
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/device-tree/kernel.c b/xen/common/device-tree/kernel.c
index 7a00768e6b..7f73520388 100644
--- a/xen/common/device-tree/kernel.c
+++ b/xen/common/device-tree/kernel.c
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index b6ae7d6aa6..373b548f20 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -4,9 +4,6 @@
 
 #include 
 #include 
-#include 
-#include 
-#include 
 
 #if __has_include()
 #include 
@@ -14,15 +11,10 @@
 
 #define MIN_FDT_ALIGN 8
 
-#define NR_MEM_BANKS 256
-#define NR_SHMEM_BANKS 32
-
 /* Default #address and #size cells */
 #define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
 #define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
 
-#define MAX_MODULES 32 /* Current maximum useful modules */
-
 #define DEVICE_TREE_MAX_DEPTH 16
 
 /* Helper to read a big number; size is in cells (not bytes) */
@@ -75,78 +67,6 @@ typedef enum {
     BOOTMOD_UNKNOWN
 }  boot_module_kind;
 
-enum membank_type {
-    /*
-     * The MEMBANK_DEFAULT type refers to either reserved memory for the
-     * device/firmware (when the bank is in 'reserved_mem') or any RAM (when
-     * the bank is in 'mem').
-     */
-    MEMBANK_DEFAULT,
-    /*
-     * The MEMBANK_STATIC_DOMAIN type is used to indicate whether the memory
-     * bank is bound to a static Xen domain. It is only valid when the bank
-     * is in reserved_mem.
-     */
-    MEMBANK_STATIC_DOMAIN,
-    /*
-     * The MEMBANK_STATIC_HEAP type is used to indicate whether the memory
-     * bank is reserved as static heap. It is only valid when the bank is
-     * in reserved_mem.
-     */
-    MEMBANK_STATIC_HEAP,
-    /*
-     * The MEMBANK_FDT_RESVMEM type is used to indicate whether the memory
-     * bank is from the FDT reserve map.
-     */
-    MEMBANK_FDT_RESVMEM,
-};
-
-enum region_type {
-    MEMORY,
-    RESERVED_MEMORY,
-    STATIC_SHARED_MEMORY
-};
-
-/* Indicates the maximum number of characters(\0 included) for shm_id */
-#define MAX_SHM_ID_LENGTH 16
-
-struct shmem_membank_extra {
-    char shm_id[MAX_SHM_ID_LENGTH];
-    unsigned int nr_shm_borrowers;
-};
-
-struct membank {
-    paddr_t start;
-    paddr_t size;
-    union {
-        enum membank_type type;
-#ifdef CONFIG_STATIC_SHM
-        struct shmem_membank_extra *shmem_extra;
-#endif
-    };
-};
-
-struct membanks {
-    __struct_group(membanks_hdr, common, ,
-        unsigned int nr_banks;
-        unsigned int max_banks;
-        enum region_type type;
-    );
-    struct membank bank[];
-};
-
-struct meminfo {
-    struct membanks_hdr common;
-    struct membank bank[NR_MEM_BANKS];
-};
-
-struct shared_meminfo {
-    struct membanks_hdr common;
-    struct membank bank[NR_SHMEM_BANKS];
-    struct shmem_membank_extra extra[NR_SHMEM_BANKS];
-};
-
-
 struct boot_domain {
     struct domain *d;
 
@@ -178,134 +98,6 @@ struct boot_module {
 #endif
 };
 
-/* DT_MAX_NAME is the node name max length according the DT spec */
-#define DT_MAX_NAME 41
-struct bootcmdline {
-    boot_module_kind kind;
-    bool domU;
-    paddr_t start;
-    char dt_name[DT_MAX_NAME];
-    char cmdline[BOOTMOD_MAX_CMDLINE];
-};
-
-struct boot_modules {
-    int nr_mods;
-    struct boot_module module[MAX_MODULES];
-};
-
-struct bootcmdlines {
-    unsigned int nr_mods;
-    struct bootcmdline cmdline[MAX_MODULES];
-};
-
-struct bootinfo {
-    struct meminfo mem;
-    /* The reserved regions are only used when booting using Device-Tree */
-    struct meminfo reserved_mem;
-    struct boot_modules modules;
-    struct bootcmdlines cmdlines;
-#ifdef CONFIG_ACPI
-    struct meminfo acpi;
-#endif
-#ifdef CONFIG_STATIC_SHM
-    struct shared_meminfo shmem;
-#endif
-};
-
-#ifdef CONFIG_ACPI
-#define BOOTINFO_ACPI_INIT                          \
-    .acpi.common.max_banks = NR_MEM_BANKS,          \
-    .acpi.common.type = MEMORY,
-#else
-#define BOOTINFO_ACPI_INIT
-#endif
-
-#ifdef CONFIG_STATIC_SHM
-#define BOOTINFO_SHMEM_INIT                         \
-    .shmem.common.max_banks = NR_SHMEM_BANKS,       \
-    .shmem.common.type = STATIC_SHARED_MEMORY,
-#else
-#define BOOTINFO_SHMEM_INIT
-#endif
-
-#define BOOTINFO_INIT                               \
-{                                                   \
-    .mem.common.max_banks = NR_MEM_BANKS,           \
-    .mem.common.type = MEMORY,                      \
-    .reserved_mem.common.max_banks = NR_MEM_BANKS,  \
-    .reserved_mem.common.type = RESERVED_MEMORY,    \
-    BOOTINFO_ACPI_INIT                              \
-    BOOTINFO_SHMEM_INIT                             \
-}
-
-extern struct bootinfo bootinfo;
-
-bool check_reserved_regions_overlap(paddr_t region_start,
-                                    paddr_t region_size,
-                                    bool allow_memreserve_overlap);
-
-struct boot_module *add_boot_module(boot_module_kind kind,
-                                   paddr_t start, paddr_t size, bool domU);
-struct boot_module *boot_module_find_by_kind(boot_module_kind kind);
-struct boot_module * boot_module_find_by_addr_and_kind(boot_module_kind kind,
-                                                             paddr_t start);
-void add_boot_cmdline(const char *name, const char *cmdline,
-                      boot_module_kind kind, paddr_t start, bool domU);
-struct bootcmdline *boot_cmdline_find_by_kind(boot_module_kind kind);
-struct bootcmdline * boot_cmdline_find_by_name(const char *name);
-const char *boot_module_kind_as_string(boot_module_kind kind);
-
-void populate_boot_allocator(void);
-
-size_t boot_fdt_info(const void *fdt, paddr_t paddr);
-
-const char *boot_fdt_cmdline(const void *fdt);
-int domain_fdt_begin_node(void *fdt, const char *name, uint64_t unit);
-
-static inline struct membanks *bootinfo_get_reserved_mem(void)
-{
-    return container_of(&bootinfo.reserved_mem.common, struct membanks, common);
-}
-
-static inline struct membanks *bootinfo_get_mem(void)
-{
-    return container_of(&bootinfo.mem.common, struct membanks, common);
-}
-
-#ifdef CONFIG_ACPI
-static inline struct membanks *bootinfo_get_acpi(void)
-{
-    return container_of(&bootinfo.acpi.common, struct membanks, common);
-}
-#endif
-
-#ifdef CONFIG_STATIC_SHM
-static inline struct membanks *bootinfo_get_shmem(void)
-{
-    return container_of(&bootinfo.shmem.common, struct membanks, common);
-}
-
-static inline struct shmem_membank_extra *bootinfo_get_shmem_extra(void)
-{
-    return bootinfo.shmem.extra;
-}
-#endif
-
-static inline struct membanks *membanks_xzalloc(unsigned int nr,
-                                                enum region_type type)
-{
-    struct membanks *banks = xzalloc_flex_struct(struct membanks, bank, nr);
-
-    if ( !banks )
-        goto out;
-
-    banks->max_banks = nr;
-    banks->type = type;
-
- out:
-    return banks;
-}
-
 /*
  * Interpret the property `prop_name` of `node` as a u32.
  *
diff --git a/xen/include/xen/bootinfo.h b/xen/include/xen/bootinfo.h
new file mode 100644
index 0000000000..f834f19571
--- /dev/null
+++ b/xen/include/xen/bootinfo.h
@@ -0,0 +1,213 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef XEN_BOOTINFO_H
+#define XEN_BOOTINFO_H
+
+#include 
+#include 
+#include 
+#include 
+
+#define NR_MEM_BANKS 256
+#define NR_SHMEM_BANKS 32
+
+#define MAX_MODULES 32 /* Current maximum useful modules */
+
+enum membank_type {
+    /*
+     * The MEMBANK_DEFAULT type refers to either reserved memory for the
+     * device/firmware (when the bank is in 'reserved_mem') or any RAM (when
+     * the bank is in 'mem').
+     */
+    MEMBANK_DEFAULT,
+    /*
+     * The MEMBANK_STATIC_DOMAIN type is used to indicate whether the memory
+     * bank is bound to a static Xen domain. It is only valid when the bank
+     * is in reserved_mem.
+     */
+    MEMBANK_STATIC_DOMAIN,
+    /*
+     * The MEMBANK_STATIC_HEAP type is used to indicate whether the memory
+     * bank is reserved as static heap. It is only valid when the bank is
+     * in reserved_mem.
+     */
+    MEMBANK_STATIC_HEAP,
+    /*
+     * The MEMBANK_FDT_RESVMEM type is used to indicate whether the memory
+     * bank is from the FDT reserve map.
+     */
+    MEMBANK_FDT_RESVMEM,
+};
+
+enum region_type {
+    MEMORY,
+    RESERVED_MEMORY,
+    STATIC_SHARED_MEMORY
+};
+
+/* Indicates the maximum number of characters(\0 included) for shm_id */
+#define MAX_SHM_ID_LENGTH 16
+
+struct shmem_membank_extra {
+    char shm_id[MAX_SHM_ID_LENGTH];
+    unsigned int nr_shm_borrowers;
+};
+
+struct membank {
+    paddr_t start;
+    paddr_t size;
+    union {
+        enum membank_type type;
+#ifdef CONFIG_STATIC_SHM
+        struct shmem_membank_extra *shmem_extra;
+#endif
+    };
+};
+
+struct membanks {
+    __struct_group(membanks_hdr, common, ,
+        unsigned int nr_banks;
+        unsigned int max_banks;
+        enum region_type type;
+    );
+    struct membank bank[];
+};
+
+struct meminfo {
+    struct membanks_hdr common;
+    struct membank bank[NR_MEM_BANKS];
+};
+
+struct shared_meminfo {
+    struct membanks_hdr common;
+    struct membank bank[NR_SHMEM_BANKS];
+    struct shmem_membank_extra extra[NR_SHMEM_BANKS];
+};
+
+/* DT_MAX_NAME is the node name max length according the DT spec */
+#define DT_MAX_NAME 41
+struct bootcmdline {
+    boot_module_kind kind;
+    bool domU;
+    paddr_t start;
+    char dt_name[DT_MAX_NAME];
+    char cmdline[BOOTMOD_MAX_CMDLINE];
+};
+
+struct boot_modules {
+    int nr_mods;
+    struct boot_module module[MAX_MODULES];
+};
+
+struct bootcmdlines {
+    unsigned int nr_mods;
+    struct bootcmdline cmdline[MAX_MODULES];
+};
+
+struct bootinfo {
+    struct meminfo mem;
+    /* The reserved regions are only used when booting using Device-Tree */
+    struct meminfo reserved_mem;
+    struct boot_modules modules;
+    struct bootcmdlines cmdlines;
+#ifdef CONFIG_ACPI
+    struct meminfo acpi;
+#endif
+#ifdef CONFIG_STATIC_SHM
+    struct shared_meminfo shmem;
+#endif
+};
+
+#ifdef CONFIG_ACPI
+#define BOOTINFO_ACPI_INIT                          \
+    .acpi.common.max_banks = NR_MEM_BANKS,          \
+    .acpi.common.type = MEMORY,
+#else
+#define BOOTINFO_ACPI_INIT
+#endif
+
+#ifdef CONFIG_STATIC_SHM
+#define BOOTINFO_SHMEM_INIT                         \
+    .shmem.common.max_banks = NR_SHMEM_BANKS,       \
+    .shmem.common.type = STATIC_SHARED_MEMORY,
+#else
+#define BOOTINFO_SHMEM_INIT
+#endif
+
+#define BOOTINFO_INIT                               \
+{                                                   \
+    .mem.common.max_banks = NR_MEM_BANKS,           \
+    .mem.common.type = MEMORY,                      \
+    .reserved_mem.common.max_banks = NR_MEM_BANKS,  \
+    .reserved_mem.common.type = RESERVED_MEMORY,    \
+    BOOTINFO_ACPI_INIT                              \
+    BOOTINFO_SHMEM_INIT                             \
+}
+
+extern struct bootinfo bootinfo;
+
+bool check_reserved_regions_overlap(paddr_t region_start,
+                                    paddr_t region_size,
+                                    bool allow_memreserve_overlap);
+
+struct boot_module *add_boot_module(boot_module_kind kind,
+                                    paddr_t start, paddr_t size, bool domU);
+struct boot_module *boot_module_find_by_kind(boot_module_kind kind);
+struct boot_module * boot_module_find_by_addr_and_kind(boot_module_kind kind,
+                                                             paddr_t start);
+void add_boot_cmdline(const char *name, const char *cmdline,
+                      boot_module_kind kind, paddr_t start, bool domU);
+struct bootcmdline *boot_cmdline_find_by_kind(boot_module_kind kind);
+struct bootcmdline * boot_cmdline_find_by_name(const char *name);
+const char *boot_module_kind_as_string(boot_module_kind kind);
+
+void populate_boot_allocator(void);
+
+size_t boot_fdt_info(const void *fdt, paddr_t paddr);
+const char *boot_fdt_cmdline(const void *fdt);
+int domain_fdt_begin_node(void *fdt, const char *name, uint64_t unit);
+
+static inline struct membanks *bootinfo_get_reserved_mem(void)
+{
+    return container_of(&bootinfo.reserved_mem.common, struct membanks, common);
+}
+
+static inline struct membanks *bootinfo_get_mem(void)
+{
+    return container_of(&bootinfo.mem.common, struct membanks, common);
+}
+
+#ifdef CONFIG_ACPI
+static inline struct membanks *bootinfo_get_acpi(void)
+{
+    return container_of(&bootinfo.acpi.common, struct membanks, common);
+}
+#endif
+
+#ifdef CONFIG_STATIC_SHM
+static inline struct membanks *bootinfo_get_shmem(void)
+{
+    return container_of(&bootinfo.shmem.common, struct membanks, common);
+}
+
+static inline struct shmem_membank_extra *bootinfo_get_shmem_extra(void)
+{
+    return bootinfo.shmem.extra;
+}
+#endif
+
+static inline struct membanks *membanks_xzalloc(unsigned int nr,
+                                                enum region_type type)
+{
+    struct membanks *banks = xzalloc_flex_struct(struct membanks, bank, nr);
+
+    if ( !banks )
+        goto out;
+
+    banks->max_banks = nr;
+    banks->type = type;
+
+ out:
+    return banks;
+}
+
+#endif /* XEN_BOOTINFO_H */
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 0a22b1ba1d..7d1c8bc305 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -10,7 +10,7 @@
 #ifndef __XEN_DEVICE_TREE_H__
 #define __XEN_DEVICE_TREE_H__
 
-#include 
+#include 
 #include 
 
 #include 
diff --git a/xen/include/xen/fdt-domain-build.h b/xen/include/xen/fdt-domain-build.h
index 45981dbec0..60565fdbf9 100644
--- a/xen/include/xen/fdt-domain-build.h
+++ b/xen/include/xen/fdt-domain-build.h
@@ -3,7 +3,7 @@
 #ifndef __XEN_FDT_DOMAIN_BUILD_H__
 #define __XEN_FDT_DOMAIN_BUILD_H__
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/include/xen/fdt-kernel.h b/xen/include/xen/fdt-kernel.h
index fee8eac1db..ee29aad9fe 100644
--- a/xen/include/xen/fdt-kernel.h
+++ b/xen/include/xen/fdt-kernel.h
@@ -7,7 +7,7 @@
 #ifndef __XEN_FDT_KERNEL_H__
 #define __XEN_FDT_KERNEL_H__
 
-#include 
+#include 
 #include 
 #include 
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 15:20:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 15:20:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014503.1392637 (Exim 4.92)
	(envelope-from )
	id 1uQ6Cy-0006sv-9O; Fri, 13 Jun 2025 15:20:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014503.1392637; Fri, 13 Jun 2025 15:20: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 1uQ6Cy-0006so-6r; Fri, 13 Jun 2025 15:20:44 +0000
Received: by outflank-mailman (input) for mailman id 1014503;
 Fri, 13 Jun 2025 15:20: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 1uQ69T-0001Mm-7I
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 15:17:07 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on20614.outbound.protection.outlook.com
 [2a01:111:f403:2407::614])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 766527aa-4869-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 17:17:05 +0200 (CEST)
Received: from DM5PR07CA0063.namprd07.prod.outlook.com (2603:10b6:4:ad::28) by
 SJ1PR12MB6100.namprd12.prod.outlook.com (2603:10b6:a03:45d::20) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.18; Fri, 13 Jun
 2025 15:17:00 +0000
Received: from DS1PEPF0001709A.namprd05.prod.outlook.com
 (2603:10b6:4:ad:cafe::8e) by DM5PR07CA0063.outlook.office365.com
 (2603:10b6:4:ad::28) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Fri,
 13 Jun 2025 15:17:00 +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.8835.15 via Frontend Transport; Fri, 13 Jun 2025 15:17:00 +0000
Received: from xcbagarciav01.xilinx.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; Fri, 13 Jun
 2025 10:16:57 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 766527aa-4869-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=pu3FzaIpM6PYMA+ZjlLKL/Ip5GxQuQ0CKklQGUEpTbyiEvtpObzgKlqs9/l6QVrO4ePgBnzKP3lLKvBq8moupwTwleQFmwFfuD4k/4XgQawiy15KXwLq8mdS8VAtdPupOgrvmWKaNaVKxvhetvLfqEPn3LwpjOIB3ZvgwmOgvf+TUdEFc7SP3Regptg8eOmzcT7Ezt3E42TlmkCmbiRQoJKAV79i5SK9ro2p4UDfH+4r7KS+EddbPT7Y8tKtfbrwHKpzP8oJAnZoZ026/4Qv/6GKCWQBTZCkMKd9XVHaqfF/IMkQaN+7vjFS7NYt8rnrcCMFjnVHKwORveVtB5zc9Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ZsYGQY7MHoojqL5zzyE/X5IQNTzAfHic3tkVjdKkdKc=;
 b=mWohS9rRl3um1solLXQBm3ds831+SOINu6lCwropNP0zlyCiEhQL92B90d9z2yi3uJJ0BVZ/+BAVcvmc3iOkECwKN8bj5vHxlJ/DArHeKaQ65v8oenY14czkzfwgl8yrkWs6MxT1yMxNEn8Y+GmOIletCboz5On/1vTeMhmB2xW//PbJ/RznH5IjBj1OLxArKmF+pJA9/chL+yY+iHYkWvH8PetJDvAECDEwSoeXVyv2bpzO+aqaJ5oJJDJNIS1yCTMg3l6GFOkEFleR+P9hwVn2VoYWKs1EMMqVl+/e9I1sTVA0e8WQOmF9zj0dF+4sNM5roq9kp17xTeHpfOlmMQ==
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=ZsYGQY7MHoojqL5zzyE/X5IQNTzAfHic3tkVjdKkdKc=;
 b=imVfSdBssbUVGp/OX2dKJn52x0KuxX8q6wi2aq/qfgBaiNPhB9GC76ojUqegQJJLsrOOKgq6eHT9x8zFvgRay4NujslX1B2p+21eBV5qxH0+vcvkagqbIjQ8rxDICQkcTj9/zRmxJ3nENlbnlT+kFyu2fDvT9CQDAk1Q/NtAhoE=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , "Julien
 Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Stefano Stabellini ,
	"Bertrand Marquis" , "Daniel P. Smith"
	
Subject: [PATCH v3 13/14] xen/dt: Allow CONFIG_DOM0LESS_BOOT to include device-tree/
Date: Fri, 13 Jun 2025 17:13:22 +0200
Message-ID: <20250613151612.754222-14-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250613151612.754222-1-agarciav@amd.com>
References: <20250613151612.754222-1-agarciav@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: DS1PEPF0001709A:EE_|SJ1PR12MB6100:EE_
X-MS-Office365-Filtering-Correlation-Id: 72202148-acec-47b6-943c-08ddaa8d585b
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?Ehy15L41VzN+4PYgXOqSluhYhKp7gyk2YqGOld6kBkTbOi6/JyRt0xBsikbt?=
 =?us-ascii?Q?vOTP9Wo74im/PL7omU3twlnoDC+diYTWuAOreWjULQZBvqIN/o5qD7Pgo2/Z?=
 =?us-ascii?Q?zp5/G1GorLpOBF1gdmUZ+VXsaA25eng9Dak801+KHF0kGSfBhBNT2uKA9Ovk?=
 =?us-ascii?Q?3mot+9qVIAJwb4X5+JjmX1v/wZWVZ0xPIyME7eGoZhDVOYK1XZz8BRIEi6gJ?=
 =?us-ascii?Q?ZjkD8dWomb2ccQDBNb4yEPv+MMl6BwJv4tOZRKavJ4ujJSP4+JRY8cHM6Lxp?=
 =?us-ascii?Q?nCmT3OOapgfvFFhPk3cu1m8ls53Pw1m8F7lBk1+DZqzpOSzsqZN9F/B1tZAN?=
 =?us-ascii?Q?STkcc4ZGjfijLpHKAwxFvc7L140qvfjMEnz1zbzn46dzLqAjXHdE6V1IOgzP?=
 =?us-ascii?Q?zmB5erHFSIOZE9S9vT4jEBv8zpmN2WuOKoUYvV97tHO4k4DQ/0JM+ENDB1jz?=
 =?us-ascii?Q?BN7fp+W1R/cpbK0DtTFfbeu+yal4/QRQBunwb0fN1JmmOM1djbsaHTtIGBym?=
 =?us-ascii?Q?wCYYz+OvhOoYb9O+lI+nj+WyjWRySypSS5UlLepcEMVCY1pm0i67TGuJ/iBH?=
 =?us-ascii?Q?QNmJTPQdvxY1r2Z8Eu2snGL28NMEjc3OxVGxDtUCBFNoK+8dEz7ztfDW/9zf?=
 =?us-ascii?Q?7bY6PhOtGdTd403uKfLmeP7qY0lcUI4mpSB0w118Uvf+un4VMFB2SXUMbxTF?=
 =?us-ascii?Q?yU+HMfoeqSjBmexYMblwFN2j4xiFI1nS1HwDwb8ZwLaSZ5a1T5aEVgmqCDgn?=
 =?us-ascii?Q?jLAJvGLIQUjkdl+aPZmhWLb4n68vUTYOBSpH+G3S0foft59auKKUKz0Z9LaQ?=
 =?us-ascii?Q?+2eN99KAaEHiQsvuGl6si/+aNnoaV8ys0kb5wxBKiB1yAqzgMvCqFM+g+SWy?=
 =?us-ascii?Q?BUHii7nnQSiNeHK5X47G2WYm7lN8RFpAwYRnSjVsBIVp6MONUOANqoOawqjS?=
 =?us-ascii?Q?OjyDzMuIjnM89YdQi0hzX09M6MtdzEc7HNm28O0Vwo+EWRZxcuH80y21UiBn?=
 =?us-ascii?Q?sYcLb1yGlCZBtlxRC+7O0gw0EA3nFQ2tBnj3lGwSUZtllsztH72veyFhLvIR?=
 =?us-ascii?Q?TX9JKiXkz/OISe+v4qM5I5wDux1b4BQ7P+MJIFYLQq139TkOsMWSMLYChWBq?=
 =?us-ascii?Q?uYpQR15ygzb01UqZoS2Fs87dp/fwX+2SImkZ6AICK9wBEtY3L2FF4hhHNCjc?=
 =?us-ascii?Q?1fKqvEjuAEE+Y16affFckkaUoXC0+9B2oTbAWma5g3/KjJi23ubBdFL04zv3?=
 =?us-ascii?Q?i+DCJNlwtpu4SpLVUDT26gYEmAua8NWzC8AwvXim3SwBASvPbLe9EZ7PgC4F?=
 =?us-ascii?Q?m1V57vMG6x16Mflr+crp4M1L5tl5BUl32HwVGkzPtnmQr19aR9paoYfJhPjU?=
 =?us-ascii?Q?enlD6oxjPh++zCaMBTryLQMBxsBbmaiqxX0w34n02aHQHDXlagXk0eH24Nwi?=
 =?us-ascii?Q?XMrlfSdubt1mgBsdlol4z+yAMsAD7qyaQDa6f2ZFnsolvWH5V3n4+hLoc+VW?=
 =?us-ascii?Q?RLNjL+2+AORxU7UxE4jmoiW8C8gJgDwPR6x1?=
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: 13 Jun 2025 15:17:00.5180
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 72202148-acec-47b6-943c-08ddaa8d585b
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: SJ1PR12MB6100

... without CONFIG_HAS_DEVICE_TREE

Signed-off-by: Alejandro Vallejo 
---
 xen/common/Kconfig              | 1 +
 xen/common/Makefile             | 2 +-
 xen/common/device-tree/Makefile | 8 ++++----
 3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 867710134a..2baa4221fd 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -14,6 +14,7 @@ config CORE_PARKING
 
 config DOM0LESS_BOOT
 	bool "Dom0less boot support" if EXPERT
+	select LIBFDT
 	depends on HAS_DOM0LESS && HAS_DEVICE_TREE && DOMAIN_BUILD_HELPERS
 	default y
 	help
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 98f0873056..2717c81f9c 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -8,7 +8,7 @@ obj-y += cpu.o
 obj-$(CONFIG_DEBUG_TRACE) += debugtrace.o
 obj-$(CONFIG_HAS_DEVICE_TREE) += device.o
 obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) += device.o
-obj-$(CONFIG_HAS_DEVICE_TREE) += device-tree/
+obj-$(firstword $(CONFIG_HAS_DEVICE_TREE) $(CONFIG_DOM0LESS_BOOT)) += device-tree/
 obj-$(CONFIG_IOREQ_SERVER) += dm.o
 obj-y += domain.o
 obj-y += event_2l.o
diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
index 8abc069c4b..cc56f42df9 100644
--- a/xen/common/device-tree/Makefile
+++ b/xen/common/device-tree/Makefile
@@ -1,11 +1,11 @@
 obj-y += bootfdt.init.o
-obj-y += bootinfo-fdt.init.o
-obj-y += bootinfo.init.o
-obj-y += device-tree.o
+obj-$(CONFIG_HAS_DEVICE_TREE) += bootinfo-fdt.init.o
+obj-$(CONFIG_HAS_DEVICE_TREE) += bootinfo.init.o
+obj-$(CONFIG_HAS_DEVICE_TREE) += device-tree.o
 obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.init.o
 obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.init.o
 obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o
-obj-y += intc.o
+obj-$(CONFIG_HAS_DEVICE_TREE) += intc.o
 obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o
 obj-$(CONFIG_STATIC_EVTCHN) += static-evtchn.init.o
 obj-$(CONFIG_STATIC_MEMORY) += static-memory.init.o
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 15:20:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 15:20:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014508.1392646 (Exim 4.92)
	(envelope-from )
	id 1uQ6D0-0007BM-GH; Fri, 13 Jun 2025 15:20:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014508.1392646; Fri, 13 Jun 2025 15:20: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 1uQ6D0-0007BC-CV; Fri, 13 Jun 2025 15:20:46 +0000
Received: by outflank-mailman (input) for mailman id 1014508;
 Fri, 13 Jun 2025 15: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 1uQ69S-0000Kb-MV
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 15:17:06 +0000
Received: from NAM02-SN1-obe.outbound.protection.outlook.com
 (mail-sn1nam02on20600.outbound.protection.outlook.com
 [2a01:111:f403:2406::600])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 76ae4f95-4869-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 17:17:06 +0200 (CEST)
Received: from DS7PR03CA0167.namprd03.prod.outlook.com (2603:10b6:5:3b2::22)
 by SJ5PPF183341E5B.namprd12.prod.outlook.com (2603:10b6:a0f:fc02::98c) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.19; Fri, 13 Jun
 2025 15:16:57 +0000
Received: from DS1PEPF00017099.namprd05.prod.outlook.com
 (2603:10b6:5:3b2:cafe::75) by DS7PR03CA0167.outlook.office365.com
 (2603:10b6:5:3b2::22) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.35 via Frontend Transport; Fri,
 13 Jun 2025 15:16:56 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 DS1PEPF00017099.mail.protection.outlook.com (10.167.18.103) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Fri, 13 Jun 2025 15:16:56 +0000
Received: from xcbagarciav01.xilinx.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; Fri, 13 Jun
 2025 10:16:54 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 76ae4f95-4869-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ye/oR4xH/xWMBPeQ3DXqE+9k6HWMzi+oUL/LEMGCO05eTzDjBMa8zb18OuDMuoiGu7LZN2maPvVobGz50f4OoukePw0wAg8iwnd+c0ifWSgKL8i50WdYQ2Zp/Oh39+LXmQPZT9zaaV51wBXvaM3GSx0+h1juMy+Pu3sGevl0zgYZWnZe5XpfbCEYS3LHgFFm5d82kdLjC/DXxSDRPCKTYbgWAOiDWMVEQvS/4ALkJIgXGA7XY8ohELFfrYxByI0gq+8N0/f9sfXjopebWwOSpYMDNoFXIBN7uzxAJaVQvcqYejBJOhWuF+aJNy5TXX2+W117gR00ACL0GBW0WDnXew==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=uob/oSE+6bN0bWhXyItFJeG5g7WMt2WYss/Pqm5LoVA=;
 b=Qeto5HKOuSbN9jAozaz33lJmHZhjI+F8ftXbjSlrvvyvvd4JT3cqL4eDnBeF00gqYTziwY0MmnVmvq1L5rQqxPWQatoB+g6DJj0bL9rDzS3XwK43iUPJVI0gQAa/yy6IirGo4LarGkGyxT8ZLLtgDJPRQVm/E2WmLeRNXUgADUPo3b4aKSnQWyg4TLi3y2eMoCisXQW2PY3r16iAbY1r3FHu9MB5Xvhqq/FXauyNXfRxQe9agxo2EeAsEgqdrLXzmogVUeKBROnNcQYloTGX6+oZmLyDVMIyeOGB4pB8l2RN4b6gpour5VUSz7YB7HaY58YJK0rUx9IKdQ8sGt35ng==
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=uob/oSE+6bN0bWhXyItFJeG5g7WMt2WYss/Pqm5LoVA=;
 b=IUo5OAdGR2wXB7JH5P6kulUGTgVXA+SQTaI/W9TPBQX+eYcWkWkwuJ8w7J7JfHuPlHmimvIagcb58OVgBLv4QLTvtzrxNGSOvH3JPENcYcFgj0EZV/Xk7YVUArLcETMRK+6G+aVHC3scKuIaCLbyMQP4Yh7mnkRWaFkk1amL4yQ=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Daniel P.
 Smith" 
Subject: [PATCH v3 11/14] xen/dt: Extract helper to map nodes to module kinds
Date: Fri, 13 Jun 2025 17:13:20 +0200
Message-ID: <20250613151612.754222-12-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250613151612.754222-1-agarciav@amd.com>
References: <20250613151612.754222-1-agarciav@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: DS1PEPF00017099:EE_|SJ5PPF183341E5B:EE_
X-MS-Office365-Filtering-Correlation-Id: beaba439-c982-43ca-0404-08ddaa8d5600
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?eMmTHWD0oQnRe6XWomp4a4zo4+JU13kacCpx+7nqQnyAXzNXFkakaWEOtFAO?=
 =?us-ascii?Q?okUEQrLusK16fgrOht9v4V1vpaxe+k6eUSX5fqsOwCqRPVlLXOaXl7cOKYYS?=
 =?us-ascii?Q?8TSp41VIuN4oFtFFzxue+zEuhC3vlSJNAo+U+3gyOms9QNbN5qT5YPe31pn5?=
 =?us-ascii?Q?WSK6lJ4QZ8XUPjJZrZS89slO9XsHFGL7JfPH+Q8N6oyoxIKHv57GIQ7ZTBSn?=
 =?us-ascii?Q?JnlsjaPxl0u4L2WBwScAsp4x4KVNM3oOD+s6325IZNUBGOdofEvHXmrU70eD?=
 =?us-ascii?Q?jjELIW7ssbmF7vh8rRXCwm1BCHW9HLxDElL1Py5nmL8CvyQY4Reg50/FSXEA?=
 =?us-ascii?Q?tEkh1jDxFDT1QrTrQOdF9J0PNuh6FT07umvSMFrVspk0UWsRlhIUHNYzybct?=
 =?us-ascii?Q?ly5Ob8v+meTTGDnaj7W072fa+OX7pS3PLTRDPsA1olEaQzjIzMOE/kwNQbfD?=
 =?us-ascii?Q?gSV2jTPLNRonqff5tFa1QpxneSiwuMRP2XKhgGP8/IJvgha8HxhowOFti9hn?=
 =?us-ascii?Q?ddlQlptrp8P20WCrnJxBbHLiDjYJsc7cdDYQgDbdlL4hOXyDepnLDwYXSlUE?=
 =?us-ascii?Q?EUKpvDuW1r93sVq2rMEk99jGpB+DzICZ7CkxIipXM0V+ruQNb1roWqGKTWJ0?=
 =?us-ascii?Q?g1J6csKgVQTITvKTtx0x7eo7tzZGjgr9UzSCEqf3SFa53IRM7jwUBYB2pGsj?=
 =?us-ascii?Q?uVuoCozeZZH2KqcK+Ifu6WuwGZxKMNIHHVahDA5tRxwq/+552pi7L0a5vCDZ?=
 =?us-ascii?Q?Me4Cr3n4UHy7SjsMGh2KYQEs2/7/hWhtqcwPDh+U2FC9kHIrr8k6Frt37JPU?=
 =?us-ascii?Q?45HpLbxYcjAWuE+t4kcQpAFRMeACj9eQ0+s+ZMK2DX4C3g7GMsB/itdEqtVi?=
 =?us-ascii?Q?W01gXEtSSJCyG71P0G2qT+T2wYzGvdRoRmkrjRuIjyydQE6Yg0n60g7bvKv7?=
 =?us-ascii?Q?vKfg2BhVnAnEYgX+AL+5GzXPgDBrJ7qNISe2fqUX8M6SLOXovVHS9bULnKn8?=
 =?us-ascii?Q?NIaU9HE/nGz3NJSQ721XLxOiUoGPvEO32DggMBl7yyUm3XWc1KyO7vF/aDic?=
 =?us-ascii?Q?a1wvYLx61Shq4tHpM6kJ8KUOtzMdjhwYsMsv6eoVRaM7YAukQHECwdzlx2hU?=
 =?us-ascii?Q?qbLdUYl9Mt5qCI9d8V3ilvVoPocG7x+cem8s1c/F+uRN31ubu0jOZJ/ei+9x?=
 =?us-ascii?Q?Z9okCt9myi4Z5RTjBVge6fmOZjgyQRn5hVF3eRRXL+CfSaFG62bOWwvhrpg+?=
 =?us-ascii?Q?bSNltK5MKMBgCbOhr0BRgyi3D+7fJLTOGOPmalBz/R/J/AMa8ra0uc4k+rG0?=
 =?us-ascii?Q?DW/5Gb5sf7h2rt44FP6Qof89blFL7NB842fJyH2lsrTegrP8XeyMhWojvytQ?=
 =?us-ascii?Q?xRzjiNw+toboxXFTzR8Ncmd4qByOj2BZ88DVCcNRuj4S0JkiyURLrPLO0ImE?=
 =?us-ascii?Q?UDbz+5DkcombKAHDyea2g5I9a+o6qFhphW/Ru48sZGLSnwVt0BNjeIam6ADw?=
 =?us-ascii?Q?dDv8dC5skMCtfdUQdcdqSo9/jgeyHQzGaP2j?=
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: 13 Jun 2025 15:16:56.5614
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: beaba439-c982-43ca-0404-08ddaa8d5600
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:
	DS1PEPF00017099.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ5PPF183341E5B

This will be required later by x86 code in order to do early identification
of boot modules when booting off a DTB.

Not a functional change.

Signed-off-by: Alejandro Vallejo 
Reviewed-by: Stefano Stabellini 
---
 xen/common/device-tree/bootfdt.c      | 18 ++++++++++++++++++
 xen/common/device-tree/bootinfo-fdt.c | 16 +---------------
 xen/include/xen/bootfdt.h             |  7 +++++++
 3 files changed, 26 insertions(+), 15 deletions(-)

diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
index 0d8d9ea357..8218c0a10b 100644
--- a/xen/common/device-tree/bootfdt.c
+++ b/xen/common/device-tree/bootfdt.c
@@ -4,6 +4,24 @@
 #include 
 #include 
 
+boot_module_kind __init fdt_node_to_kind(const void *fdt, int node)
+{
+    if ( fdt_node_check_compatible(fdt, node, "xen,linux-zimage") == 0 ||
+         fdt_node_check_compatible(fdt, node, "multiboot,kernel") == 0 )
+        return BOOTMOD_KERNEL;
+    if ( fdt_node_check_compatible(fdt, node, "xen,linux-initrd") == 0 ||
+         fdt_node_check_compatible(fdt, node, "multiboot,ramdisk") == 0 )
+        return BOOTMOD_RAMDISK;
+    if ( fdt_node_check_compatible(fdt, node, "xen,xsm-policy") == 0 )
+        return BOOTMOD_XSM;
+    if ( fdt_node_check_compatible(fdt, node, "multiboot,device-tree") == 0 )
+        return BOOTMOD_GUEST_DTB;
+    if ( fdt_node_check_compatible(fdt, node, "multiboot,microcode") == 0 )
+        return BOOTMOD_MICROCODE;
+
+    return BOOTMOD_UNKNOWN;
+}
+
 u32 __init device_tree_get_u32(const void *fdt, int node,
                                const char *prop_name, u32 dflt)
 {
diff --git a/xen/common/device-tree/bootinfo-fdt.c b/xen/common/device-tree/bootinfo-fdt.c
index 16036472f3..9b426c0a98 100644
--- a/xen/common/device-tree/bootinfo-fdt.c
+++ b/xen/common/device-tree/bootinfo-fdt.c
@@ -236,21 +236,7 @@ static void __init process_multiboot_node(const void *fdt, int node,
 
     cell = (const __be32 *)prop->data;
     device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
-
-    if ( fdt_node_check_compatible(fdt, node, "xen,linux-zimage") == 0 ||
-         fdt_node_check_compatible(fdt, node, "multiboot,kernel") == 0 )
-        kind = BOOTMOD_KERNEL;
-    else if ( fdt_node_check_compatible(fdt, node, "xen,linux-initrd") == 0 ||
-              fdt_node_check_compatible(fdt, node, "multiboot,ramdisk") == 0 )
-        kind = BOOTMOD_RAMDISK;
-    else if ( fdt_node_check_compatible(fdt, node, "xen,xsm-policy") == 0 )
-        kind = BOOTMOD_XSM;
-    else if ( fdt_node_check_compatible(fdt, node, "multiboot,device-tree") == 0 )
-        kind = BOOTMOD_GUEST_DTB;
-    else if ( fdt_node_check_compatible(fdt, node, "multiboot,microcode") == 0 )
-        kind = BOOTMOD_MICROCODE;
-    else
-        kind = BOOTMOD_UNKNOWN;
+    kind = fdt_node_to_kind(fdt, node);
 
     /**
      * Guess the kind of these first two unknowns respectively:
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index 373b548f20..8d3c1dc5ff 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -114,4 +114,11 @@ u32 device_tree_get_u32(const void *fdt, int node,
 void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
                          uint32_t size_cells, paddr_t *start, paddr_t *size);
 
+/*
+ * Probe an FDT node thought to be a boot module to identify its kind.
+ *
+ * If correctly identified, returns the detected kind, otherwise BOOTMOD_UNKNOWN
+ */
+boot_module_kind fdt_node_to_kind(const void *fdt, int node);
+
 #endif /* XEN_BOOTFDT_H */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 15:20:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 15:20:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014510.1392652 (Exim 4.92)
	(envelope-from )
	id 1uQ6D0-0007Dz-Rh; Fri, 13 Jun 2025 15:20:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014510.1392652; Fri, 13 Jun 2025 15:20: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 1uQ6D0-0007D1-Kl; Fri, 13 Jun 2025 15:20:46 +0000
Received: by outflank-mailman (input) for mailman id 1014510;
 Fri, 13 Jun 2025 15: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 1uQ69O-0000Kb-KE
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 15:17:02 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20628.outbound.protection.outlook.com
 [2a01:111:f403:2413::628])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7394be6b-4869-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 17:17:00 +0200 (CEST)
Received: from DM6PR08CA0033.namprd08.prod.outlook.com (2603:10b6:5:80::46) by
 PH0PR12MB7887.namprd12.prod.outlook.com (2603:10b6:510:26d::7) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8792.40; Fri, 13 Jun 2025 15:16:55 +0000
Received: from DS1PEPF0001709B.namprd05.prod.outlook.com
 (2603:10b6:5:80:cafe::9b) by DM6PR08CA0033.outlook.office365.com
 (2603:10b6:5:80::46) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.22 via Frontend Transport; Fri,
 13 Jun 2025 15:16:54 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 DS1PEPF0001709B.mail.protection.outlook.com (10.167.18.105) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Fri, 13 Jun 2025 15:16:54 +0000
Received: from xcbagarciav01.xilinx.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; Fri, 13 Jun
 2025 10:16:52 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7394be6b-4869-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=qS2A5NzGetULxuwL30BeVMNvXbsKvQRC1JLNI1zUp42o8CfX8UI001Wkp/dNEAP5CPZy8LAT3KZonsBkN1jQuXbJipfXVDnAtMjW2T42Z1Sk7ONoDt/k4vYeo7l9+WpSmqPT3Ts6njxGobHdmhIMxQElnPJqH59LylpGVkajb37f3Z59g0Q8JQFsMR8tDlxGKENQ35XQQr279380LuyD20zu9VPyb1l2MqXelkOEWTlg4hxaD9sECIgU8YowxaJfNmcq8vFso76/iu8WPmYD8WH7oNmsRx/wjCRiLYr5zDiJzSmtRVjivNEmqSS6R2+Skb6izGySKN4UdPM7Tak3QA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=EZ8mPV20eg3UxX25KPokn65IJOL0jNvmLs3RF/kL5p8=;
 b=w4Bhm5QfhUoVIpN8u2LYDxi1R7lUjg2v5wsoN9Jp1Be+dpUEGoG8WkRAYeBa0ExvuAenFh9st/tqbXwVbMxa0nwS7DQEoNVeQrA7I78X64XDbWpyl9iI8mdnE/TBxB3wTY7dSHr44bpGWcHGeej1r0+sZHyEvDkiknZdPzLBVdimF5sj/Hhm9ivvuilqVZbdLg36QO3c5P5wa5qHcR4o6uF5dBjAocahEPJOen9/emh3pzKn2gnBNNz/I86XI1xsU2y54LeQ0+85XuaD1sho3X777eKvUejxXdbY456U2RM1f5IFRFvdz4NjQUD6OUJToXOtoBmBS4VAOgveSdpClg==
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=EZ8mPV20eg3UxX25KPokn65IJOL0jNvmLs3RF/kL5p8=;
 b=PBUpHsTntKZDY9hFu63SzLMDv5/b/JcqJ6cQ5oekXmiwVBd3VQ8uQXB2pFJ7gM9dmxXNdnoXi+8QaRatEooFZyFdVDbyQVXsxoBG2uyyq8IPLz7GGuSkqUyvCHaDgDKZp6pvBJBWb3fyYb5dt6opLlXzEi2sEo+PmPm/Q91q/fo=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Daniel P.
 Smith" 
Subject: [PATCH v3 10/14] xen/dt: Rename bootfdt.c -> bootinfo-fdt.c
Date: Fri, 13 Jun 2025 17:13:19 +0200
Message-ID: <20250613151612.754222-11-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250613151612.754222-1-agarciav@amd.com>
References: <20250613151612.754222-1-agarciav@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: DS1PEPF0001709B:EE_|PH0PR12MB7887:EE_
X-MS-Office365-Filtering-Correlation-Id: 75c5b67d-3d88-4462-6bf7-08ddaa8d54fc
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|376014|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?vGl5NkIzn53Lcnav5fLC0TKVmUfrZQ57ZxWfW1Kzk7DDmKclJN+IrxfXttSN?=
 =?us-ascii?Q?OV3r0hovSHtH8TVTAwxGA9X3X8K5BvnY2AYBvb3wGDpR+hhISL+wrXa/Z8XM?=
 =?us-ascii?Q?cS83ttS27QcjKUQ0r2sT3ELFplLv5iLrcBZxzik+3uSBqSef2Ws7/IfQwYyy?=
 =?us-ascii?Q?Zf+mwvkMgP8+KY3k8q6WHQFhIgKIKvzJ+DbFjCzZq/oPBAsJFt7AAoDq07aI?=
 =?us-ascii?Q?MdAY83qHVD5+VIgQgJIbehMkeKDq9HsUxw05wfhXqifCY0ubHluV6vGOl23+?=
 =?us-ascii?Q?GpsuKnNJFSpvb29210AS/MXqG8ra7Qo+E1jly4tU5gGak4f0z77D2C4aJfKs?=
 =?us-ascii?Q?c3vKhiHgkPU0Pe/wCsYT2P8fTyOQhsvLYvZ8QJUlDSNsq9EkQbBdGfcjDmxx?=
 =?us-ascii?Q?3tNKigXIdsRZw7YoEOltvtk7yl+lZVVYaGLNyx/TgpbDUgUT8xdWcyx2cs7c?=
 =?us-ascii?Q?hOqn493yOKZYFak7etkZs0o/RWNTviDWDT5E9QD1CAoya+eHRnrFKNGh6Qpe?=
 =?us-ascii?Q?eGCzrKTVxNlS1VSadaMIpyVtoXaNuEVuV6qWBWyShCGU5xUXDlUMQIwQaBc2?=
 =?us-ascii?Q?sg8BIju157SaH4Gh+pvg92wGQD0dOz2qjNwqdV6D1Vkz3KIbxAqxlJbPDo+B?=
 =?us-ascii?Q?LexE6XdZj/RX4Bmg5AOzLfOC+q9HQG2M8EJPcANysh+alrJkHUa+VG3z1eOP?=
 =?us-ascii?Q?WuSe9gtS5OmPY9L2ipHpD7uyYiJH4eNVLWzSOW4Jgym9KPPdg20WtsPc6sl/?=
 =?us-ascii?Q?Sedvk7ecFP1JqgpEV8yrpDZAtW6/c8uIl6SmpRaeMF4JmMT6F7kT/DKjdXmF?=
 =?us-ascii?Q?DcVZKyfzs3jJ9y4CjTMfeZFZxDKPKnAjIOJwuC3V1f4Ej4b7F1g3KIV+5EIb?=
 =?us-ascii?Q?D9v2dcXjXbQr9LguyjNO/AMBfJfPysdq3bnww4cZ8dj7g+oivAEj4kAOLlmr?=
 =?us-ascii?Q?qomU+cZeVuPmDvTT+kkvo787taIpgI08+W1z5FQ/a5ZGMUMTYHVybzCYPNAK?=
 =?us-ascii?Q?0HPE1D7exA3KKzlkw++MRfUoJIGYhBMO/KEYbuEXL3i8fYd6rjE85nPGBxPA?=
 =?us-ascii?Q?PCPtVckZBY/RuEp/dtmwEhitVjHMMbPPYI3p/Hp4K9NpyFVsbnhu4x/1Ghud?=
 =?us-ascii?Q?6YRMydD0TG5y0c7HhajnTyn31xoelstjCqLUUSJqgw9bFvnXhDohJR3otx8J?=
 =?us-ascii?Q?TwvcTGBLirLP814CAXYsL8GDWRyGXyw6muKLd63XSZMR+hiHJkk7d7x7oon5?=
 =?us-ascii?Q?KXOyysOpG7Jw3uRXDonmKyqUtW0LH7no0mVBe/IqfnH146MC7hBSwIXpOEGH?=
 =?us-ascii?Q?equX+aVT4m49hrGn1pZlcLnKoMjgrvVcsFZUBLSMgOCd/0J4fYCjygPYr9fv?=
 =?us-ascii?Q?xaLjjPn2h+3DJx5WNCKzSzE/iKQea8fJCxUbgplwv3ruwYq859FntnwO6nVi?=
 =?us-ascii?Q?VhHqgcWVE4wZd91kFraH/61RdCkiQyXRx78V4wPC3x58X2YL4+af8AVbsKdF?=
 =?us-ascii?Q?7vwP9KEDrrG/aw5JIqKlQnLw49ZIbN/bazMO?=
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);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jun 2025 15:16:54.8615
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 75c5b67d-3d88-4462-6bf7-08ddaa8d54fc
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:
	DS1PEPF0001709B.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB7887

This file will eventually contain bootfdt helpers that make heavy use of
bootinfo. To simplify git history do the rename here explicitly. A later
patch extracts bootinfo-independent helpers into bootfdt.c.

Doing so here would needlessly pollute the diffs.

Not a functional change.

Signed-off-by: Alejandro Vallejo 
Reviewed-by: Stefano Stabellini 
---
 xen/common/device-tree/Makefile       |   1 +
 xen/common/device-tree/bootfdt.c      | 646 +-------------------------
 xen/common/device-tree/bootinfo-fdt.c | 597 ++++++++++++++++++++++++
 3 files changed, 619 insertions(+), 625 deletions(-)
 create mode 100644 xen/common/device-tree/bootinfo-fdt.c

diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
index 13127296cb..8abc069c4b 100644
--- a/xen/common/device-tree/Makefile
+++ b/xen/common/device-tree/Makefile
@@ -1,4 +1,5 @@
 obj-y += bootfdt.init.o
+obj-y += bootinfo-fdt.init.o
 obj-y += bootinfo.init.o
 obj-y += device-tree.o
 obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.init.o
diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
index 1848478e82..0d8d9ea357 100644
--- a/xen/common/device-tree/bootfdt.c
+++ b/xen/common/device-tree/bootfdt.c
@@ -1,206 +1,8 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
-/*
- * Early Device Tree
- *
- * Copyright (C) 2012-2014 Citrix Systems, Inc.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
+#include 
+#include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-static void __init __maybe_unused build_assertions(void)
-{
-    /*
-     * Check that no padding is between struct membanks "bank" flexible array
-     * member and struct meminfo "bank" member
-     */
-    BUILD_BUG_ON((offsetof(struct membanks, bank) !=
-                 offsetof(struct meminfo, bank)));
-    /* Ensure "struct membanks" and "struct membank" are equally aligned */
-    BUILD_BUG_ON(alignof(struct membanks) != alignof(struct membank));
-}
-
-static bool __init device_tree_node_is_available(const void *fdt, int node)
-{
-    const char *status;
-    int len;
-
-    status = fdt_getprop(fdt, node, "status", &len);
-    if ( !status )
-        return true;
-
-    if ( len > 0 )
-    {
-        if ( !strcmp(status, "ok") || !strcmp(status, "okay") )
-            return true;
-    }
-
-    return false;
-}
-
-static bool __init device_tree_node_matches(const void *fdt, int node,
-                                            const char *match)
-{
-    const char *name;
-    size_t match_len;
-
-    name = fdt_get_name(fdt, node, NULL);
-    match_len = strlen(match);
-
-    /* Match both "match" and "match@..." patterns but not
-       "match-foo". */
-    return strncmp(name, match, match_len) == 0
-        && (name[match_len] == '@' || name[match_len] == '\0');
-}
-
-static bool __init device_tree_node_compatible(const void *fdt, int node,
-                                               const char *match)
-{
-    int len, l;
-    const void *prop;
-
-    prop = fdt_getprop(fdt, node, "compatible", &len);
-    if ( prop == NULL )
-        return false;
-
-    while ( len > 0 ) {
-        if ( !dt_compat_cmp(prop, match) )
-            return true;
-        l = strlen(prop) + 1;
-        prop += l;
-        len -= l;
-    }
-
-    return false;
-}
-
-/*
- * Check if a node is a proper /memory node according to Devicetree
- * Specification v0.4, chapter 3.4.
- */
-static bool __init device_tree_is_memory_node(const void *fdt, int node,
-                                              int depth)
-{
-    const char *type;
-    int len;
-
-    if ( depth != 1 )
-        return false;
-
-    if ( !device_tree_node_matches(fdt, node, "memory") )
-        return false;
-
-    type = fdt_getprop(fdt, node, "device_type", &len);
-    if ( !type )
-        return false;
-
-    if ( (len <= strlen("memory")) || strcmp(type, "memory") )
-        return false;
-
-    return true;
-}
-
-void __init device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
-                                uint32_t size_cells, paddr_t *start,
-                                paddr_t *size)
-{
-    uint64_t dt_start, dt_size;
-
-    /*
-     * dt_next_cell will return uint64_t whereas paddr_t may not be 64-bit.
-     * Thus, there is an implicit cast from uint64_t to paddr_t.
-     */
-    dt_start = dt_next_cell(address_cells, cell);
-    dt_size = dt_next_cell(size_cells, cell);
-
-    if ( dt_start != (paddr_t)dt_start )
-    {
-        printk("Physical address greater than max width supported\n");
-        WARN();
-    }
-
-    if ( dt_size != (paddr_t)dt_size )
-    {
-        printk("Physical size greater than max width supported\n");
-        WARN();
-    }
-
-    /*
-     * Xen will truncate the address/size if it is greater than the maximum
-     * supported width and it will give an appropriate warning.
-     */
-    *start = dt_start;
-    *size = dt_size;
-}
-
-static int __init device_tree_get_meminfo(const void *fdt, int node,
-                                          const char *prop_name,
-                                          u32 address_cells, u32 size_cells,
-                                          struct membanks *mem,
-                                          enum membank_type type)
-{
-    const struct fdt_property *prop;
-    unsigned int i, banks;
-    const __be32 *cell;
-    u32 reg_cells = address_cells + size_cells;
-    paddr_t start, size;
-
-    if ( !device_tree_node_is_available(fdt, node) )
-        return 0;
-
-    if ( address_cells < 1 || size_cells < 1 )
-    {
-        printk("fdt: property `%s': invalid #address-cells or #size-cells",
-               prop_name);
-        return -EINVAL;
-    }
-
-    prop = fdt_get_property(fdt, node, prop_name, NULL);
-    if ( !prop )
-        return -ENOENT;
-
-    cell = (const __be32 *)prop->data;
-    banks = fdt32_to_cpu(prop->len) / (reg_cells * sizeof (u32));
-
-    for ( i = 0; i < banks && mem->nr_banks < mem->max_banks; i++ )
-    {
-        device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
-        /*
-         * Some valid device trees, such as those generated by OpenPOWER
-         * skiboot firmware, expose all reserved memory regions in the
-         * FDT memory reservation block AND in the reserved-memory node which
-         * has already been parsed. Thus, any matching overlaps in the
-         * reserved_mem banks should be ignored.
-         */
-        if ( mem == bootinfo_get_reserved_mem() &&
-             check_reserved_regions_overlap(start, size, true) )
-            return -EINVAL;
-        /* Some DT may describe empty bank, ignore them */
-        if ( !size )
-            continue;
-        mem->bank[mem->nr_banks].start = start;
-        mem->bank[mem->nr_banks].size = size;
-        mem->bank[mem->nr_banks].type = type;
-        mem->nr_banks++;
-    }
-
-    if ( i < banks )
-    {
-        printk("Warning: Max number of supported memory regions reached.\n");
-        return -ENOSPC;
-    }
-
-    return 0;
-}
+#include 
 
 u32 __init device_tree_get_u32(const void *fdt, int node,
                                const char *prop_name, u32 dflt)
@@ -214,18 +16,6 @@ u32 __init device_tree_get_u32(const void *fdt, int node,
     return fdt32_to_cpu(*(uint32_t*)prop->data);
 }
 
-/**
- * device_tree_for_each_node - iterate over all device tree sub-nodes
- * @fdt: flat device tree.
- * @node: parent node to start the search from
- * @func: function to call for each sub-node.
- * @data: data to pass to @func.
- *
- * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
- *
- * Returns 0 if all nodes were iterated over successfully.  If @func
- * returns a value different from 0, that value is returned immediately.
- */
 int __init device_tree_for_each_node(const void *fdt, int node,
                                      device_tree_node_func func,
                                      void *data)
@@ -273,429 +63,35 @@ int __init device_tree_for_each_node(const void *fdt, int node,
     return 0;
 }
 
-static int __init process_memory_node(const void *fdt, int node,
-                                      const char *name, int depth,
-                                      u32 address_cells, u32 size_cells,
-                                      struct membanks *mem)
-{
-    return device_tree_get_meminfo(fdt, node, "reg", address_cells, size_cells,
-                                   mem, MEMBANK_DEFAULT);
-}
-
-static int __init process_reserved_memory_node(const void *fdt, int node,
-                                               const char *name, int depth,
-                                               u32 address_cells,
-                                               u32 size_cells,
-                                               void *data)
-{
-    int rc = process_memory_node(fdt, node, name, depth, address_cells,
-                                 size_cells, data);
-
-    if ( rc == -ENOSPC )
-        panic("Max number of supported reserved-memory regions reached.\n");
-    else if ( rc != -ENOENT )
-        return rc;
-    return 0;
-}
-
-static int __init process_reserved_memory(const void *fdt, int node,
-                                          const char *name, int depth,
-                                          u32 address_cells, u32 size_cells)
-{
-    return device_tree_for_each_node(fdt, node,
-                                     process_reserved_memory_node,
-                                     bootinfo_get_reserved_mem());
-}
-
-static void __init process_multiboot_node(const void *fdt, int node,
-                                          const char *name,
-                                          u32 address_cells, u32 size_cells)
-{
-    static int __initdata kind_guess = 0;
-    const struct fdt_property *prop;
-    const __be32 *cell;
-    boot_module_kind kind;
-    paddr_t start, size;
-    int len;
-    /* sizeof("/chosen/") + DT_MAX_NAME + '/' + DT_MAX_NAME + '/0' => 92 */
-    char path[92];
-    int parent_node, ret;
-    bool domU;
-
-    parent_node = fdt_parent_offset(fdt, node);
-    ASSERT(parent_node >= 0);
-
-    /* Check that the node is under "/chosen" (first 7 chars of path) */
-    ret = fdt_get_path(fdt, node, path, sizeof (path));
-    if ( ret != 0 || strncmp(path, "/chosen", 7) )
-        return;
-
-    prop = fdt_get_property(fdt, node, "reg", &len);
-    if ( !prop )
-        panic("node %s missing `reg' property\n", name);
-
-    if ( len < dt_cells_to_size(address_cells + size_cells) )
-        panic("fdt: node `%s': `reg` property length is too short\n",
-                    name);
-
-    cell = (const __be32 *)prop->data;
-    device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
-
-    if ( fdt_node_check_compatible(fdt, node, "xen,linux-zimage") == 0 ||
-         fdt_node_check_compatible(fdt, node, "multiboot,kernel") == 0 )
-        kind = BOOTMOD_KERNEL;
-    else if ( fdt_node_check_compatible(fdt, node, "xen,linux-initrd") == 0 ||
-              fdt_node_check_compatible(fdt, node, "multiboot,ramdisk") == 0 )
-        kind = BOOTMOD_RAMDISK;
-    else if ( fdt_node_check_compatible(fdt, node, "xen,xsm-policy") == 0 )
-        kind = BOOTMOD_XSM;
-    else if ( fdt_node_check_compatible(fdt, node, "multiboot,device-tree") == 0 )
-        kind = BOOTMOD_GUEST_DTB;
-    else if ( fdt_node_check_compatible(fdt, node, "multiboot,microcode") == 0 )
-        kind = BOOTMOD_MICROCODE;
-    else
-        kind = BOOTMOD_UNKNOWN;
-
-    /**
-     * Guess the kind of these first two unknowns respectively:
-     * (1) The first unknown must be kernel.
-     * (2) Detect the XSM Magic from the 2nd unknown:
-     *     a. If it's XSM, set the kind as XSM, and that also means we
-     *     won't load ramdisk;
-     *     b. if it's not XSM, set the kind as ramdisk.
-     *     So if user want to load ramdisk, it must be the 2nd unknown.
-     * We also detect the XSM Magic for the following unknowns,
-     * then set its kind according to the return value of has_xsm_magic.
-     */
-    if ( kind == BOOTMOD_UNKNOWN )
-    {
-        switch ( kind_guess++ )
-        {
-        case 0: kind = BOOTMOD_KERNEL; break;
-        case 1: kind = BOOTMOD_RAMDISK; break;
-        default: break;
-        }
-        if ( kind_guess > 1 && has_xsm_magic(start) )
-            kind = BOOTMOD_XSM;
-    }
-
-    domU = fdt_node_check_compatible(fdt, parent_node, "xen,domain") == 0;
-    add_boot_module(kind, start, size, domU);
-
-    prop = fdt_get_property(fdt, node, "bootargs", &len);
-    if ( !prop )
-        return;
-    add_boot_cmdline(fdt_get_name(fdt, parent_node, &len), prop->data,
-                     kind, start, domU);
-}
-
-static int __init process_chosen_node(const void *fdt, int node,
-                                      const char *name,
-                                      u32 address_cells, u32 size_cells)
-{
-    const struct fdt_property *prop;
-    paddr_t start, end;
-    int len;
-
-    if ( fdt_get_property(fdt, node, "xen,static-heap", NULL) )
-    {
-        int rc;
-
-        printk("Checking for static heap in /chosen\n");
-
-        rc = device_tree_get_meminfo(fdt, node, "xen,static-heap",
-                                     address_cells, size_cells,
-                                     bootinfo_get_reserved_mem(),
-                                     MEMBANK_STATIC_HEAP);
-        if ( rc )
-            return rc;
-
-        using_static_heap = true;
-    }
-
-    printk("Checking for initrd in /chosen\n");
-
-    prop = fdt_get_property(fdt, node, "linux,initrd-start", &len);
-    if ( !prop )
-        /* No initrd present. */
-        return 0;
-    if ( len != sizeof(u32) && len != sizeof(u64) )
-    {
-        printk("linux,initrd-start property has invalid length %d\n", len);
-        return -EINVAL;
-    }
-    start = dt_read_paddr((const void *)&prop->data, dt_size_to_cells(len));
-
-    prop = fdt_get_property(fdt, node, "linux,initrd-end", &len);
-    if ( !prop )
-    {
-        printk("linux,initrd-end not present but -start was\n");
-        return -EINVAL;
-    }
-    if ( len != sizeof(u32) && len != sizeof(u64) )
-    {
-        printk("linux,initrd-end property has invalid length %d\n", len);
-        return -EINVAL;
-    }
-    end = dt_read_paddr((const void *)&prop->data, dt_size_to_cells(len));
-
-    if ( start >= end )
-    {
-        printk("linux,initrd limits invalid: %"PRIpaddr" >= %"PRIpaddr"\n",
-                  start, end);
-        return -EINVAL;
-    }
-
-    printk("Initrd %"PRIpaddr"-%"PRIpaddr"\n", start, end - 1);
-
-    add_boot_module(BOOTMOD_RAMDISK, start, end-start, false);
-
-    return 0;
-}
-
-static int __init process_domain_node(const void *fdt, int node,
-                                      const char *name,
-                                      u32 address_cells, u32 size_cells)
-{
-    const struct fdt_property *prop;
-
-    printk("Checking for \"xen,static-mem\" in domain node\n");
-
-    prop = fdt_get_property(fdt, node, "xen,static-mem", NULL);
-    if ( !prop )
-        /* No "xen,static-mem" present. */
-        return 0;
-
-    return device_tree_get_meminfo(fdt, node, "xen,static-mem", address_cells,
-                                   size_cells, bootinfo_get_reserved_mem(),
-                                   MEMBANK_STATIC_DOMAIN);
-}
-
-#ifndef CONFIG_STATIC_SHM
-static inline int process_shm_node(const void *fdt, int node,
-                                   uint32_t address_cells, uint32_t size_cells)
-{
-    printk("CONFIG_STATIC_SHM must be enabled for parsing static shared"
-            " memory nodes\n");
-    return -EINVAL;
-}
-#endif
-
-static int __init early_scan_node(const void *fdt,
-                                  int node, const char *name, int depth,
-                                  u32 address_cells, u32 size_cells,
-                                  void *data)
+void __init device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
+                                uint32_t size_cells, paddr_t *start,
+                                paddr_t *size)
 {
-    int rc = 0;
+    uint64_t dt_start, dt_size;
 
     /*
-     * If Xen has been booted via UEFI, the memory banks are
-     * populated. So we should skip the parsing.
+     * dt_next_cell will return uint64_t whereas paddr_t may not be 64-bit.
+     * Thus, there is an implicit cast from uint64_t to paddr_t.
      */
-    if ( !efi_enabled(EFI_BOOT) &&
-         device_tree_is_memory_node(fdt, node, depth) )
-        rc = process_memory_node(fdt, node, name, depth,
-                                 address_cells, size_cells, bootinfo_get_mem());
-    else if ( depth == 1 && !dt_node_cmp(name, "reserved-memory") )
-        rc = process_reserved_memory(fdt, node, name, depth,
-                                     address_cells, size_cells);
-    else if ( depth <= 3 && (device_tree_node_compatible(fdt, node, "xen,multiboot-module" ) ||
-              device_tree_node_compatible(fdt, node, "multiboot,module" )))
-        process_multiboot_node(fdt, node, name, address_cells, size_cells);
-    else if ( depth == 1 && device_tree_node_matches(fdt, node, "chosen") )
-        rc = process_chosen_node(fdt, node, name, address_cells, size_cells);
-    else if ( depth == 2 && device_tree_node_compatible(fdt, node, "xen,domain") )
-        rc = process_domain_node(fdt, node, name, address_cells, size_cells);
-    else if ( depth <= 3 && device_tree_node_compatible(fdt, node, "xen,domain-shared-memory-v1") )
-        rc = process_shm_node(fdt, node, address_cells, size_cells);
-
-    if ( rc < 0 )
-        printk("fdt: node `%s': parsing failed\n", name);
-    return rc;
-}
-
-static void __init early_print_info(void)
-{
-    const struct membanks *mi = bootinfo_get_mem();
-    const struct membanks *mem_resv = bootinfo_get_reserved_mem();
-    struct boot_modules *mods = &bootinfo.modules;
-    struct bootcmdlines *cmds = &bootinfo.cmdlines;
-    unsigned int i;
-
-    for ( i = 0; i < mi->nr_banks; i++ )
-        printk("RAM: %"PRIpaddr" - %"PRIpaddr"\n",
-                mi->bank[i].start,
-                mi->bank[i].start + mi->bank[i].size - 1);
-    printk("\n");
-    for ( i = 0 ; i < mods->nr_mods; i++ )
-        printk("MODULE[%d]: %"PRIpaddr" - %"PRIpaddr" %-12s\n",
-                i,
-                mods->module[i].start,
-                mods->module[i].start + mods->module[i].size - 1,
-                boot_module_kind_as_string(mods->module[i].kind));
-
-    for ( i = 0; i < mem_resv->nr_banks; i++ )
-    {
-        printk(" RESVD[%u]: %"PRIpaddr" - %"PRIpaddr"\n", i,
-               mem_resv->bank[i].start,
-               mem_resv->bank[i].start + mem_resv->bank[i].size - 1);
-    }
-#ifdef CONFIG_STATIC_SHM
-    early_print_info_shmem();
-#endif
-    printk("\n");
-    for ( i = 0 ; i < cmds->nr_mods; i++ )
-        printk("CMDLINE[%"PRIpaddr"]:%s %s\n", cmds->cmdline[i].start,
-               cmds->cmdline[i].dt_name,
-               &cmds->cmdline[i].cmdline[0]);
-    printk("\n");
-}
-
-/* This function assumes that memory regions are not overlapped */
-static int __init cmp_memory_node(const void *key, const void *elem)
-{
-    const struct membank *handler0 = key;
-    const struct membank *handler1 = elem;
-
-    if ( handler0->start < handler1->start )
-        return -1;
-
-    if ( handler0->start >= (handler1->start + handler1->size) )
-        return 1;
-
-    return 0;
-}
-
-static void __init swap_memory_node(void *_a, void *_b, size_t size)
-{
-    struct membank *a = _a, *b = _b;
-
-    SWAP(*a, *b);
-}
-
-/**
- * boot_fdt_info - initialize bootinfo from a DTB
- * @fdt: flattened device tree binary
- *
- * Returns the size of the DTB.
- */
-size_t __init boot_fdt_info(const void *fdt, paddr_t paddr)
-{
-    struct membanks *reserved_mem = bootinfo_get_reserved_mem();
-    struct membanks *mem = bootinfo_get_mem();
-    unsigned int i;
-    int nr_rsvd;
-    int ret;
-
-    ret = fdt_check_header(fdt);
-    if ( ret < 0 )
-        panic("No valid device tree\n");
-
-    add_boot_module(BOOTMOD_FDT, paddr, fdt_totalsize(fdt), false);
-
-    nr_rsvd = fdt_num_mem_rsv(fdt);
-    if ( nr_rsvd < 0 )
-        panic("Parsing FDT memory reserve map failed (%d)\n", nr_rsvd);
+    dt_start = dt_next_cell(address_cells, cell);
+    dt_size = dt_next_cell(size_cells, cell);
 
-    for ( i = 0; i < nr_rsvd; i++ )
+    if ( dt_start != (paddr_t)dt_start )
     {
-        struct membank *bank;
-        paddr_t s, sz;
-
-        if ( fdt_get_mem_rsv_paddr(device_tree_flattened, i, &s, &sz) < 0 )
-            continue;
-
-        if ( reserved_mem->nr_banks < reserved_mem->max_banks )
-        {
-            bank = &reserved_mem->bank[reserved_mem->nr_banks];
-            bank->start = s;
-            bank->size = sz;
-            bank->type = MEMBANK_FDT_RESVMEM;
-            reserved_mem->nr_banks++;
-        }
-        else
-            panic("Cannot allocate reserved memory bank\n");
+        printk("Physical address greater than max width supported\n");
+        WARN();
     }
 
-    ret = device_tree_for_each_node(fdt, 0, early_scan_node, NULL);
-    if ( ret )
-        panic("Early FDT parsing failed (%d)\n", ret);
-
-    /*
-     * On Arm64 setup_directmap_mappings() expects to be called with the lowest
-     * bank in memory first. There is no requirement that the DT will provide
-     * the banks sorted in ascending order. So sort them through.
-     */
-    sort(mem->bank, mem->nr_banks, sizeof(struct membank),
-         cmp_memory_node, swap_memory_node);
-
-    early_print_info();
-
-    return fdt_totalsize(fdt);
-}
-
-const __init char *boot_fdt_cmdline(const void *fdt)
-{
-    int node;
-    const struct fdt_property *prop;
-
-    node = fdt_path_offset(fdt, "/chosen");
-    if ( node < 0 )
-        return NULL;
-
-    prop = fdt_get_property(fdt, node, "xen,xen-bootargs", NULL);
-    if ( prop == NULL )
+    if ( dt_size != (paddr_t)dt_size )
     {
-        struct bootcmdline *dom0_cmdline =
-            boot_cmdline_find_by_kind(BOOTMOD_KERNEL);
-
-        if (fdt_get_property(fdt, node, "xen,dom0-bootargs", NULL) ||
-            ( dom0_cmdline && dom0_cmdline->cmdline[0] ) )
-            prop = fdt_get_property(fdt, node, "bootargs", NULL);
+        printk("Physical size greater than max width supported\n");
+        WARN();
     }
-    if ( prop == NULL )
-        return NULL;
-
-    return prop->data;
-}
 
-/*
- * Wrapper to convert physical address from paddr_t to uint64_t and
- * invoke fdt_begin_node(). This is required as the physical address
- * provided as part of node name should not contain any leading
- * zeroes. Thus, one should use PRIx64 (instead of PRIpaddr) to append
- * unit (which contains the physical address) with name to generate a
- * node name.
- */
-int __init domain_fdt_begin_node(void *fdt, const char *name, uint64_t unit)
-{
     /*
-     * The size of the buffer to hold the longest possible string (i.e.
-     * interrupt-controller@ + a 64-bit number + \0).
+     * Xen will truncate the address/size if it is greater than the maximum
+     * supported width and it will give an appropriate warning.
      */
-    char buf[38];
-    int ret;
-
-    /* ePAPR 3.4 */
-    ret = snprintf(buf, sizeof(buf), "%s@%"PRIx64, name, unit);
-
-    if ( ret >= sizeof(buf) )
-    {
-        printk(XENLOG_ERR
-               "Insufficient buffer. Minimum size required is %d\n",
-               (ret + 1));
-
-        return -FDT_ERR_TRUNCATED;
-    }
-
-    return fdt_begin_node(fdt, buf);
+    *start = dt_start;
+    *size = dt_size;
 }
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/common/device-tree/bootinfo-fdt.c b/xen/common/device-tree/bootinfo-fdt.c
new file mode 100644
index 0000000000..16036472f3
--- /dev/null
+++ b/xen/common/device-tree/bootinfo-fdt.c
@@ -0,0 +1,597 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Early Device Tree with bootinfo hooks
+ *
+ * Copyright (C) 2012-2014 Citrix Systems, Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static void __init __maybe_unused build_assertions(void)
+{
+    /*
+     * Check that no padding is between struct membanks "bank" flexible array
+     * member and struct meminfo "bank" member
+     */
+    BUILD_BUG_ON((offsetof(struct membanks, bank) !=
+                 offsetof(struct meminfo, bank)));
+    /* Ensure "struct membanks" and "struct membank" are equally aligned */
+    BUILD_BUG_ON(alignof(struct membanks) != alignof(struct membank));
+}
+
+static bool __init device_tree_node_is_available(const void *fdt, int node)
+{
+    const char *status;
+    int len;
+
+    status = fdt_getprop(fdt, node, "status", &len);
+    if ( !status )
+        return true;
+
+    if ( len > 0 )
+    {
+        if ( !strcmp(status, "ok") || !strcmp(status, "okay") )
+            return true;
+    }
+
+    return false;
+}
+
+static bool __init device_tree_node_matches(const void *fdt, int node,
+                                            const char *match)
+{
+    const char *name;
+    size_t match_len;
+
+    name = fdt_get_name(fdt, node, NULL);
+    match_len = strlen(match);
+
+    /* Match both "match" and "match@..." patterns but not
+       "match-foo". */
+    return strncmp(name, match, match_len) == 0
+        && (name[match_len] == '@' || name[match_len] == '\0');
+}
+
+static bool __init device_tree_node_compatible(const void *fdt, int node,
+                                               const char *match)
+{
+    int len, l;
+    const void *prop;
+
+    prop = fdt_getprop(fdt, node, "compatible", &len);
+    if ( prop == NULL )
+        return false;
+
+    while ( len > 0 ) {
+        if ( !dt_compat_cmp(prop, match) )
+            return true;
+        l = strlen(prop) + 1;
+        prop += l;
+        len -= l;
+    }
+
+    return false;
+}
+
+/*
+ * Check if a node is a proper /memory node according to Devicetree
+ * Specification v0.4, chapter 3.4.
+ */
+static bool __init device_tree_is_memory_node(const void *fdt, int node,
+                                              int depth)
+{
+    const char *type;
+    int len;
+
+    if ( depth != 1 )
+        return false;
+
+    if ( !device_tree_node_matches(fdt, node, "memory") )
+        return false;
+
+    type = fdt_getprop(fdt, node, "device_type", &len);
+    if ( !type )
+        return false;
+
+    if ( (len <= strlen("memory")) || strcmp(type, "memory") )
+        return false;
+
+    return true;
+}
+
+static int __init device_tree_get_meminfo(const void *fdt, int node,
+                                          const char *prop_name,
+                                          u32 address_cells, u32 size_cells,
+                                          struct membanks *mem,
+                                          enum membank_type type)
+{
+    const struct fdt_property *prop;
+    unsigned int i, banks;
+    const __be32 *cell;
+    u32 reg_cells = address_cells + size_cells;
+    paddr_t start, size;
+
+    if ( !device_tree_node_is_available(fdt, node) )
+        return 0;
+
+    if ( address_cells < 1 || size_cells < 1 )
+    {
+        printk("fdt: property `%s': invalid #address-cells or #size-cells",
+               prop_name);
+        return -EINVAL;
+    }
+
+    prop = fdt_get_property(fdt, node, prop_name, NULL);
+    if ( !prop )
+        return -ENOENT;
+
+    cell = (const __be32 *)prop->data;
+    banks = fdt32_to_cpu(prop->len) / (reg_cells * sizeof (u32));
+
+    for ( i = 0; i < banks && mem->nr_banks < mem->max_banks; i++ )
+    {
+        device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
+        /*
+         * Some valid device trees, such as those generated by OpenPOWER
+         * skiboot firmware, expose all reserved memory regions in the
+         * FDT memory reservation block AND in the reserved-memory node which
+         * has already been parsed. Thus, any matching overlaps in the
+         * reserved_mem banks should be ignored.
+         */
+        if ( mem == bootinfo_get_reserved_mem() &&
+             check_reserved_regions_overlap(start, size, true) )
+            return -EINVAL;
+        /* Some DT may describe empty bank, ignore them */
+        if ( !size )
+            continue;
+        mem->bank[mem->nr_banks].start = start;
+        mem->bank[mem->nr_banks].size = size;
+        mem->bank[mem->nr_banks].type = type;
+        mem->nr_banks++;
+    }
+
+    if ( i < banks )
+    {
+        printk("Warning: Max number of supported memory regions reached.\n");
+        return -ENOSPC;
+    }
+
+    return 0;
+}
+
+static int __init process_memory_node(const void *fdt, int node,
+                                      const char *name, int depth,
+                                      u32 address_cells, u32 size_cells,
+                                      struct membanks *mem)
+{
+    return device_tree_get_meminfo(fdt, node, "reg", address_cells, size_cells,
+                                   mem, MEMBANK_DEFAULT);
+}
+
+static int __init process_reserved_memory_node(const void *fdt, int node,
+                                               const char *name, int depth,
+                                               u32 address_cells,
+                                               u32 size_cells,
+                                               void *data)
+{
+    int rc = process_memory_node(fdt, node, name, depth, address_cells,
+                                 size_cells, data);
+
+    if ( rc == -ENOSPC )
+        panic("Max number of supported reserved-memory regions reached.\n");
+    else if ( rc != -ENOENT )
+        return rc;
+    return 0;
+}
+
+static int __init process_reserved_memory(const void *fdt, int node,
+                                          const char *name, int depth,
+                                          u32 address_cells, u32 size_cells)
+{
+    return device_tree_for_each_node(fdt, node,
+                                     process_reserved_memory_node,
+                                     bootinfo_get_reserved_mem());
+}
+
+static void __init process_multiboot_node(const void *fdt, int node,
+                                          const char *name,
+                                          u32 address_cells, u32 size_cells)
+{
+    static int __initdata kind_guess = 0;
+    const struct fdt_property *prop;
+    const __be32 *cell;
+    boot_module_kind kind;
+    paddr_t start, size;
+    int len;
+    /* sizeof("/chosen/") + DT_MAX_NAME + '/' + DT_MAX_NAME + '/0' => 92 */
+    char path[92];
+    int parent_node, ret;
+    bool domU;
+
+    parent_node = fdt_parent_offset(fdt, node);
+    ASSERT(parent_node >= 0);
+
+    /* Check that the node is under "/chosen" (first 7 chars of path) */
+    ret = fdt_get_path(fdt, node, path, sizeof (path));
+    if ( ret != 0 || strncmp(path, "/chosen", 7) )
+        return;
+
+    prop = fdt_get_property(fdt, node, "reg", &len);
+    if ( !prop )
+        panic("node %s missing `reg' property\n", name);
+
+    if ( len < dt_cells_to_size(address_cells + size_cells) )
+        panic("fdt: node `%s': `reg` property length is too short\n",
+                    name);
+
+    cell = (const __be32 *)prop->data;
+    device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
+
+    if ( fdt_node_check_compatible(fdt, node, "xen,linux-zimage") == 0 ||
+         fdt_node_check_compatible(fdt, node, "multiboot,kernel") == 0 )
+        kind = BOOTMOD_KERNEL;
+    else if ( fdt_node_check_compatible(fdt, node, "xen,linux-initrd") == 0 ||
+              fdt_node_check_compatible(fdt, node, "multiboot,ramdisk") == 0 )
+        kind = BOOTMOD_RAMDISK;
+    else if ( fdt_node_check_compatible(fdt, node, "xen,xsm-policy") == 0 )
+        kind = BOOTMOD_XSM;
+    else if ( fdt_node_check_compatible(fdt, node, "multiboot,device-tree") == 0 )
+        kind = BOOTMOD_GUEST_DTB;
+    else if ( fdt_node_check_compatible(fdt, node, "multiboot,microcode") == 0 )
+        kind = BOOTMOD_MICROCODE;
+    else
+        kind = BOOTMOD_UNKNOWN;
+
+    /**
+     * Guess the kind of these first two unknowns respectively:
+     * (1) The first unknown must be kernel.
+     * (2) Detect the XSM Magic from the 2nd unknown:
+     *     a. If it's XSM, set the kind as XSM, and that also means we
+     *     won't load ramdisk;
+     *     b. if it's not XSM, set the kind as ramdisk.
+     *     So if user want to load ramdisk, it must be the 2nd unknown.
+     * We also detect the XSM Magic for the following unknowns,
+     * then set its kind according to the return value of has_xsm_magic.
+     */
+    if ( kind == BOOTMOD_UNKNOWN )
+    {
+        switch ( kind_guess++ )
+        {
+        case 0: kind = BOOTMOD_KERNEL; break;
+        case 1: kind = BOOTMOD_RAMDISK; break;
+        default: break;
+        }
+        if ( kind_guess > 1 && has_xsm_magic(start) )
+            kind = BOOTMOD_XSM;
+    }
+
+    domU = fdt_node_check_compatible(fdt, parent_node, "xen,domain") == 0;
+    add_boot_module(kind, start, size, domU);
+
+    prop = fdt_get_property(fdt, node, "bootargs", &len);
+    if ( !prop )
+        return;
+    add_boot_cmdline(fdt_get_name(fdt, parent_node, &len), prop->data,
+                     kind, start, domU);
+}
+
+static int __init process_chosen_node(const void *fdt, int node,
+                                      const char *name,
+                                      u32 address_cells, u32 size_cells)
+{
+    const struct fdt_property *prop;
+    paddr_t start, end;
+    int len;
+
+    if ( fdt_get_property(fdt, node, "xen,static-heap", NULL) )
+    {
+        int rc;
+
+        printk("Checking for static heap in /chosen\n");
+
+        rc = device_tree_get_meminfo(fdt, node, "xen,static-heap",
+                                     address_cells, size_cells,
+                                     bootinfo_get_reserved_mem(),
+                                     MEMBANK_STATIC_HEAP);
+        if ( rc )
+            return rc;
+
+        using_static_heap = true;
+    }
+
+    printk("Checking for initrd in /chosen\n");
+
+    prop = fdt_get_property(fdt, node, "linux,initrd-start", &len);
+    if ( !prop )
+        /* No initrd present. */
+        return 0;
+    if ( len != sizeof(u32) && len != sizeof(u64) )
+    {
+        printk("linux,initrd-start property has invalid length %d\n", len);
+        return -EINVAL;
+    }
+    start = dt_read_paddr((const void *)&prop->data, dt_size_to_cells(len));
+
+    prop = fdt_get_property(fdt, node, "linux,initrd-end", &len);
+    if ( !prop )
+    {
+        printk("linux,initrd-end not present but -start was\n");
+        return -EINVAL;
+    }
+    if ( len != sizeof(u32) && len != sizeof(u64) )
+    {
+        printk("linux,initrd-end property has invalid length %d\n", len);
+        return -EINVAL;
+    }
+    end = dt_read_paddr((const void *)&prop->data, dt_size_to_cells(len));
+
+    if ( start >= end )
+    {
+        printk("linux,initrd limits invalid: %"PRIpaddr" >= %"PRIpaddr"\n",
+                  start, end);
+        return -EINVAL;
+    }
+
+    printk("Initrd %"PRIpaddr"-%"PRIpaddr"\n", start, end - 1);
+
+    add_boot_module(BOOTMOD_RAMDISK, start, end-start, false);
+
+    return 0;
+}
+
+static int __init process_domain_node(const void *fdt, int node,
+                                      const char *name,
+                                      u32 address_cells, u32 size_cells)
+{
+    const struct fdt_property *prop;
+
+    printk("Checking for \"xen,static-mem\" in domain node\n");
+
+    prop = fdt_get_property(fdt, node, "xen,static-mem", NULL);
+    if ( !prop )
+        /* No "xen,static-mem" present. */
+        return 0;
+
+    return device_tree_get_meminfo(fdt, node, "xen,static-mem", address_cells,
+                                   size_cells, bootinfo_get_reserved_mem(),
+                                   MEMBANK_STATIC_DOMAIN);
+}
+
+#ifndef CONFIG_STATIC_SHM
+static inline int process_shm_node(const void *fdt, int node,
+                                   uint32_t address_cells, uint32_t size_cells)
+{
+    printk("CONFIG_STATIC_SHM must be enabled for parsing static shared"
+            " memory nodes\n");
+    return -EINVAL;
+}
+#endif
+
+static int __init early_scan_node(const void *fdt,
+                                  int node, const char *name, int depth,
+                                  u32 address_cells, u32 size_cells,
+                                  void *data)
+{
+    int rc = 0;
+
+    /*
+     * If Xen has been booted via UEFI, the memory banks are
+     * populated. So we should skip the parsing.
+     */
+    if ( !efi_enabled(EFI_BOOT) &&
+         device_tree_is_memory_node(fdt, node, depth) )
+        rc = process_memory_node(fdt, node, name, depth,
+                                 address_cells, size_cells, bootinfo_get_mem());
+    else if ( depth == 1 && !dt_node_cmp(name, "reserved-memory") )
+        rc = process_reserved_memory(fdt, node, name, depth,
+                                     address_cells, size_cells);
+    else if ( depth <= 3 && (device_tree_node_compatible(fdt, node, "xen,multiboot-module" ) ||
+              device_tree_node_compatible(fdt, node, "multiboot,module" )))
+        process_multiboot_node(fdt, node, name, address_cells, size_cells);
+    else if ( depth == 1 && device_tree_node_matches(fdt, node, "chosen") )
+        rc = process_chosen_node(fdt, node, name, address_cells, size_cells);
+    else if ( depth == 2 && device_tree_node_compatible(fdt, node, "xen,domain") )
+        rc = process_domain_node(fdt, node, name, address_cells, size_cells);
+    else if ( depth <= 3 && device_tree_node_compatible(fdt, node, "xen,domain-shared-memory-v1") )
+        rc = process_shm_node(fdt, node, address_cells, size_cells);
+
+    if ( rc < 0 )
+        printk("fdt: node `%s': parsing failed\n", name);
+    return rc;
+}
+
+static void __init early_print_info(void)
+{
+    const struct membanks *mi = bootinfo_get_mem();
+    const struct membanks *mem_resv = bootinfo_get_reserved_mem();
+    struct boot_modules *mods = &bootinfo.modules;
+    struct bootcmdlines *cmds = &bootinfo.cmdlines;
+    unsigned int i;
+
+    for ( i = 0; i < mi->nr_banks; i++ )
+        printk("RAM: %"PRIpaddr" - %"PRIpaddr"\n",
+                mi->bank[i].start,
+                mi->bank[i].start + mi->bank[i].size - 1);
+    printk("\n");
+    for ( i = 0 ; i < mods->nr_mods; i++ )
+        printk("MODULE[%d]: %"PRIpaddr" - %"PRIpaddr" %-12s\n",
+                i,
+                mods->module[i].start,
+                mods->module[i].start + mods->module[i].size - 1,
+                boot_module_kind_as_string(mods->module[i].kind));
+
+    for ( i = 0; i < mem_resv->nr_banks; i++ )
+    {
+        printk(" RESVD[%u]: %"PRIpaddr" - %"PRIpaddr"\n", i,
+               mem_resv->bank[i].start,
+               mem_resv->bank[i].start + mem_resv->bank[i].size - 1);
+    }
+#ifdef CONFIG_STATIC_SHM
+    early_print_info_shmem();
+#endif
+    printk("\n");
+    for ( i = 0 ; i < cmds->nr_mods; i++ )
+        printk("CMDLINE[%"PRIpaddr"]:%s %s\n", cmds->cmdline[i].start,
+               cmds->cmdline[i].dt_name,
+               &cmds->cmdline[i].cmdline[0]);
+    printk("\n");
+}
+
+/* This function assumes that memory regions are not overlapped */
+static int __init cmp_memory_node(const void *key, const void *elem)
+{
+    const struct membank *handler0 = key;
+    const struct membank *handler1 = elem;
+
+    if ( handler0->start < handler1->start )
+        return -1;
+
+    if ( handler0->start >= (handler1->start + handler1->size) )
+        return 1;
+
+    return 0;
+}
+
+static void __init swap_memory_node(void *_a, void *_b, size_t size)
+{
+    struct membank *a = _a, *b = _b;
+
+    SWAP(*a, *b);
+}
+
+/**
+ * boot_fdt_info - initialize bootinfo from a DTB
+ * @fdt: flattened device tree binary
+ *
+ * Returns the size of the DTB.
+ */
+size_t __init boot_fdt_info(const void *fdt, paddr_t paddr)
+{
+    struct membanks *reserved_mem = bootinfo_get_reserved_mem();
+    struct membanks *mem = bootinfo_get_mem();
+    unsigned int i;
+    int nr_rsvd;
+    int ret;
+
+    ret = fdt_check_header(fdt);
+    if ( ret < 0 )
+        panic("No valid device tree\n");
+
+    add_boot_module(BOOTMOD_FDT, paddr, fdt_totalsize(fdt), false);
+
+    nr_rsvd = fdt_num_mem_rsv(fdt);
+    if ( nr_rsvd < 0 )
+        panic("Parsing FDT memory reserve map failed (%d)\n", nr_rsvd);
+
+    for ( i = 0; i < nr_rsvd; i++ )
+    {
+        struct membank *bank;
+        paddr_t s, sz;
+
+        if ( fdt_get_mem_rsv_paddr(device_tree_flattened, i, &s, &sz) < 0 )
+            continue;
+
+        if ( reserved_mem->nr_banks < reserved_mem->max_banks )
+        {
+            bank = &reserved_mem->bank[reserved_mem->nr_banks];
+            bank->start = s;
+            bank->size = sz;
+            bank->type = MEMBANK_FDT_RESVMEM;
+            reserved_mem->nr_banks++;
+        }
+        else
+            panic("Cannot allocate reserved memory bank\n");
+    }
+
+    ret = device_tree_for_each_node(fdt, 0, early_scan_node, NULL);
+    if ( ret )
+        panic("Early FDT parsing failed (%d)\n", ret);
+
+    /*
+     * On Arm64 setup_directmap_mappings() expects to be called with the lowest
+     * bank in memory first. There is no requirement that the DT will provide
+     * the banks sorted in ascending order. So sort them through.
+     */
+    sort(mem->bank, mem->nr_banks, sizeof(struct membank),
+         cmp_memory_node, swap_memory_node);
+
+    early_print_info();
+
+    return fdt_totalsize(fdt);
+}
+
+const __init char *boot_fdt_cmdline(const void *fdt)
+{
+    int node;
+    const struct fdt_property *prop;
+
+    node = fdt_path_offset(fdt, "/chosen");
+    if ( node < 0 )
+        return NULL;
+
+    prop = fdt_get_property(fdt, node, "xen,xen-bootargs", NULL);
+    if ( prop == NULL )
+    {
+        struct bootcmdline *dom0_cmdline =
+            boot_cmdline_find_by_kind(BOOTMOD_KERNEL);
+
+        if (fdt_get_property(fdt, node, "xen,dom0-bootargs", NULL) ||
+            ( dom0_cmdline && dom0_cmdline->cmdline[0] ) )
+            prop = fdt_get_property(fdt, node, "bootargs", NULL);
+    }
+    if ( prop == NULL )
+        return NULL;
+
+    return prop->data;
+}
+
+/*
+ * Wrapper to convert physical address from paddr_t to uint64_t and
+ * invoke fdt_begin_node(). This is required as the physical address
+ * provided as part of node name should not contain any leading
+ * zeroes. Thus, one should use PRIx64 (instead of PRIpaddr) to append
+ * unit (which contains the physical address) with name to generate a
+ * node name.
+ */
+int __init domain_fdt_begin_node(void *fdt, const char *name, uint64_t unit)
+{
+    /*
+     * The size of the buffer to hold the longest possible string (i.e.
+     * interrupt-controller@ + a 64-bit number + \0).
+     */
+    char buf[38];
+    int ret;
+
+    /* ePAPR 3.4 */
+    ret = snprintf(buf, sizeof(buf), "%s@%"PRIx64, name, unit);
+
+    if ( ret >= sizeof(buf) )
+    {
+        printk(XENLOG_ERR
+               "Insufficient buffer. Minimum size required is %d\n",
+               (ret + 1));
+
+        return -FDT_ERR_TRUNCATED;
+    }
+
+    return fdt_begin_node(fdt, buf);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 15:20:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 15:20:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014511.1392658 (Exim 4.92)
	(envelope-from )
	id 1uQ6D1-0007Jy-3W; Fri, 13 Jun 2025 15:20:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014511.1392658; Fri, 13 Jun 2025 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 1uQ6D0-0007If-SD; Fri, 13 Jun 2025 15:20:46 +0000
Received: by outflank-mailman (input) for mailman id 1014511;
 Fri, 13 Jun 2025 15:20: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 1uQ69P-0001Mm-UF
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 15:17:03 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on2062b.outbound.protection.outlook.com
 [2a01:111:f403:2414::62b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 74315ec5-4869-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 17:17:01 +0200 (CEST)
Received: from DM5PR07CA0079.namprd07.prod.outlook.com (2603:10b6:4:ad::44) by
 IA0PR12MB7649.namprd12.prod.outlook.com (2603:10b6:208:437::17) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.25; Fri, 13 Jun
 2025 15:16:58 +0000
Received: from DS1PEPF0001709A.namprd05.prod.outlook.com
 (2603:10b6:4:ad:cafe::b8) by DM5PR07CA0079.outlook.office365.com
 (2603:10b6:4:ad::44) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.19 via Frontend Transport; Fri,
 13 Jun 2025 15:16:58 +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.8835.15 via Frontend Transport; Fri, 13 Jun 2025 15:16:58 +0000
Received: from xcbagarciav01.xilinx.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; Fri, 13 Jun
 2025 10:16:56 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 74315ec5-4869-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=oir+acExoA4qX3AbruiBxJG5szffXfkpAwazU9HvEmocTnr368Z3f9Dg3NeVNpkN6Kjno3jgQSnSJd6DsmgUeS/QDiWFhv6WjzWD8qXRwP3LVPHSk3xRmUAPkmh6LxeY6/FYYKWqNeDTHSDC8nBME1O4YL27fis6IFf7TVUIvAKfL9NGCN60aprjZFtmd8BckFsDK2UlCdWwH6Ve/fPZIVYtJJ8hMHlgN0pLDOPYKZMhqnSYqg1i5r+cUsieSVvK4yhYKTefP0dEXYmyE1ENwmzAW7lBudp39du/wa3/E57fcR6rtA21BPJqZGNfgyfDW+nDe5YXNpW6WvyEoev83g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=brxUSyWoWAWqxgYUG8qaIMM7Yyx7/AEhfufohTwOIXw=;
 b=w98UlQ0DESOvBmVBzPA9TaCxX8vl+LrB7kDhQUNqg0ZUj+DBrvtuDCRFPNLFWnfVlQcLJ1V+3g/sjNAQoGzdQ6znMJT+Dt+aiWQo2uk+QZ1ES5RVnLOaNZ4yGEf8VMtTMsgUv3VxzkVPW2hJfnjpaIeNpoKv3whd/7Ypl4SOZFmUTo42ArlOIUDc+Lm8O8d8uUSlbSNUe3zZVGBEbVkyRntspjUJHWYFXnYPFbILPpxxViaUlU+YA/qWTe4mc3fO0uTnCO0CzGNZCICwiSig9pOIXhRcnwcaRqOgo34dRoJKzx6QMxxFNcBQBhuNSA//gjRYLGabf39AuNLWdJRrfw==
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=brxUSyWoWAWqxgYUG8qaIMM7Yyx7/AEhfufohTwOIXw=;
 b=pNKo9mmV4oDqgIJ+sjqn9NNtcxKjZexZ5LDy9EVjo4oq4kPKQqlviWdmnnQPKPtwgmzs5mHuMvlkxfybUUApSuAq5s1Hu6zwuSYAxutQTYjzXzdwLIvcHMqA5l5+eaa9Aw8AL/2NyRFZkyvz1Kppb9pwhx0nwUkKZf7SpIjjFAc=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Daniel P.
 Smith" 
Subject: [PATCH v3 12/14] xen/dt: ifdef out DEV_DT-related bits from device_tree.{c,h}
Date: Fri, 13 Jun 2025 17:13:21 +0200
Message-ID: <20250613151612.754222-13-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250613151612.754222-1-agarciav@amd.com>
References: <20250613151612.754222-1-agarciav@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: DS1PEPF0001709A:EE_|IA0PR12MB7649:EE_
X-MS-Office365-Filtering-Correlation-Id: 18e9a47c-06c6-4580-bfdb-08ddaa8d56fc
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?qg5eXVHasiZAJ1vpklXsNvZB9WtvIfF8lc46zZIY+Qc7uugp/agnb+ZY2ehJ?=
 =?us-ascii?Q?SV2Hm3Yt2HaAPNprjmBCCTwt8R+wLbwJMbiv78lbhh6v0woQSFUjlSGZtMMN?=
 =?us-ascii?Q?+nU+rMqAFNen/sSiLzPJ4LuTHHn0Iyk6v9XnAh8q2Gmdb3J6FDpAOPhunOtK?=
 =?us-ascii?Q?2oF6YwZscLDC8C6B2Y4OJHcIiaOrW0SiQbrzyFjrEIvMeX4kQnDUFMBbQMYG?=
 =?us-ascii?Q?p4bdcjrOXHCmtbZ5I9mZwT/nAjBclFwktOC3paT7+L7IaZR5qM0jQKYqHy+Q?=
 =?us-ascii?Q?8xqmxnAdMmO7y3w0BC0yhEcaJ6Xz8dYLqz7DgKcqm21OellkhKxhY4SUDJAw?=
 =?us-ascii?Q?eqMRT0CXK7M3OPMX/r5pKQ8M9rijOgS4nMGWpyjEUlz2AfZCo/vLcg2+FzU9?=
 =?us-ascii?Q?c0iL7dwqAheH0bk1o2D4p4VdiAfe1+1IsERji8IMD+mHO8OW84hdvyNLyV/J?=
 =?us-ascii?Q?Ocglpg1Z3f+w8FD/C4kC2+RcjujIDUZAKn7zypXPY+stSdjmbDa5Ii51wdmB?=
 =?us-ascii?Q?MqemEGYoeiwZ3o7q2LOjdBdwxh0QD8FUTnuRAvmQwNG16QEE5F6+G4dWYUWs?=
 =?us-ascii?Q?S/mafBHaFLwlWHD40tttVmte8USYcqIhCUSiav+oDgAcMpiqimGUKFc2RYUC?=
 =?us-ascii?Q?4FHQnVAt6vqs2GtKEqcr1oWM6X7m0HmFAbfRkV72/P3X3TSAxdSct1yYsi4Y?=
 =?us-ascii?Q?0dNxUE+1acl1THQh17e6zvwHKkRK/WjOTTxHZc1s1iWzg8XhBUOA3XW7oqz0?=
 =?us-ascii?Q?HgstKJYXbcyeBMPMpS2WHJuTcjkVq3C2OM6JenPQZ9TZiZEzb3kvCTQ2XaDu?=
 =?us-ascii?Q?5nZjYMx8hQJlrq1isqRgZ0drd/aWR7nfwL4tBqwVdE/AYAoyM6DckJG9cyki?=
 =?us-ascii?Q?bkjzFSlskIA5xrpHPjkAU/nRcULcsME+82eFB655MoYT6bzIjpUptS3j/p+P?=
 =?us-ascii?Q?IHDLBtGGylTQNbEGoP4HR9FZBHpQEenMUnir/z4HmDW9elBSWVXO1YUY6HvE?=
 =?us-ascii?Q?3jIVq4wcyNFHePzvBtSncBjzpZvs4GdRaqGAO5E9if0zcn4uq1iDpcU83nxP?=
 =?us-ascii?Q?dYlVqzhYElVqt1HyD1T2LYkhDEYXhr0PgRleaqlxIz3vzrN/XdsDsTG3lTyU?=
 =?us-ascii?Q?ik0ewNBB6BSIKFknpDGVj/hohcetXWgiCU7oxp0+AW4YHsO+8sQGYcp0gC/+?=
 =?us-ascii?Q?HaVtVaAlowJhMXdZERXYhS7pt2X+PbfjSwoCFWz7hafeY9oEqzhpe2SlbTYr?=
 =?us-ascii?Q?Tq4OeOKKqgi0qCeVTiMXNPv2nJIZpuyTgUoA3MLRm/7thX7hUvZhR7H536ZS?=
 =?us-ascii?Q?2apr5udHK4I+rPzPwIuN7fHVmuBmAb+w+/O4OrUDCsYlwELU96YXf/s2whE5?=
 =?us-ascii?Q?R7BviyX/fpcnos5+uNcA+mbR/gapScaQYKWUng0vYDij16izjzzsUrSzc1i1?=
 =?us-ascii?Q?GL5z4XAe4h8xJ1c3LWLkAxgfXIbzCVzYsqqDftsoyr28b8Qyg0lTYzqDhJWU?=
 =?us-ascii?Q?acRBVUTtNvNfHKUQ5jFP/Nosl5pq+dtqgjtw?=
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: 13 Jun 2025 15:16:58.2154
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 18e9a47c-06c6-4580-bfdb-08ddaa8d56fc
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: IA0PR12MB7649

... which means, device-tree.c stops requiring strictly CONFIG_HAS_DEVICE_TREE
and may function without it.

Not a functional change on architectures that currently use these files,
as they already select CONFIG_HAS_DEVICE_TREE.

Signed-off-by: Alejandro Vallejo 
---
 xen/common/device-tree/device-tree.c | 2 ++
 xen/include/xen/device_tree.h        | 4 ++++
 2 files changed, 6 insertions(+)

diff --git a/xen/common/device-tree/device-tree.c b/xen/common/device-tree/device-tree.c
index 886e6c7712..c8a9c0e46a 100644
--- a/xen/common/device-tree/device-tree.c
+++ b/xen/common/device-tree/device-tree.c
@@ -2028,9 +2028,11 @@ static unsigned long unflatten_dt_node(const void *fdt,
             ((char *)pp->value)[sz - 1] = 0;
             dt_dprintk("fixed up name for %s -> %s\n", pathp,
                        (char *)pp->value);
+#ifdef CONFIG_HAS_DEVICE_TREE
             /* Generic device initialization */
             np->dev.type = DEV_DT;
             np->dev.of_node = np;
+#endif /* CONFIG_HAS_DEVICE_TREE */
         }
     }
     if ( allnextpp )
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 7d1c8bc305..641f24518d 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -109,9 +109,12 @@ struct dt_device_node {
      */
     struct list_head domain_list;
 
+#ifdef CONFIG_HAS_DEVICE_TREE
     struct device dev;
+#endif /* CONFIG_HAS_DEVICE_TREE */
 };
 
+#ifdef CONFIG_HAS_DEVICE_TREE
 #define dt_to_dev(dt_node)  (&(dt_node)->dev)
 
 static inline struct dt_device_node *dev_to_dt(struct device *dev)
@@ -120,6 +123,7 @@ static inline struct dt_device_node *dev_to_dt(struct device *dev)
 
     return container_of(dev, struct dt_device_node, dev);
 }
+#endif /* CONFIG_HAS_DEVICE_TREE */
 
 #define MAX_PHANDLE_ARGS 16
 struct dt_phandle_args {
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 15:20:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 15:20:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014522.1392677 (Exim 4.92)
	(envelope-from )
	id 1uQ6D3-00081c-Jg; Fri, 13 Jun 2025 15:20:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014522.1392677; Fri, 13 Jun 2025 15:20: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 1uQ6D3-00081T-G6; Fri, 13 Jun 2025 15:20:49 +0000
Received: by outflank-mailman (input) for mailman id 1014522;
 Fri, 13 Jun 2025 15:20: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 1uQ69X-0001Mm-Fa
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 15:17:11 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on20614.outbound.protection.outlook.com
 [2a01:111:f403:2407::614])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 799ad5cc-4869-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 17:17:09 +0200 (CEST)
Received: from DM6PR21CA0004.namprd21.prod.outlook.com (2603:10b6:5:174::14)
 by BL3PR12MB6642.namprd12.prod.outlook.com (2603:10b6:208:38e::15) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.18; Fri, 13 Jun
 2025 15:17:07 +0000
Received: from DS1PEPF00017097.namprd05.prod.outlook.com
 (2603:10b6:5:174:cafe::14) by DM6PR21CA0004.outlook.office365.com
 (2603:10b6:5:174::14) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8857.13 via Frontend Transport; Fri,
 13 Jun 2025 15:17:06 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 DS1PEPF00017097.mail.protection.outlook.com (10.167.18.101) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Fri, 13 Jun 2025 15:17:06 +0000
Received: from xcbagarciav01.xilinx.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; Fri, 13 Jun
 2025 10:17:00 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 799ad5cc-4869-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=obMpc9QlRNAW/bwpgCLlAlgeoU4/9kfBuh3Fv+2Wq+w9DaBbQFu2jNGg11RqIsMakNoAHUCV8cdXtLvftTc2JmeU06AZVp+41jneT7R2WX2yE8qeX9OMzEYspWJUfSgd015d/H9XYAu/khh/txW+hi7NokgxtCzUHbE2kRJlmVN21L44+nS4QVcPrZ87qRc+XMmenGjbUuNvRj+nZVB2L9eh+v/m1rkWCAIuXKgh/6sIofyNzCsn2TCBfpn53BsjO8a4Fev4PYrZznTVwlqSx4uRsuoQhz0j8Jl+eyf6bkDQJjvyFd0EMj6bScGiBpWzNo1eB030k7jnRIC2+0i7RQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=3sXC7bKMTvaM/Im+RuFHkslTamk4z5CqhBmXTzNI29c=;
 b=EINLOJDib4CciGNtHiRc6OP4NqBxdCxXiJTY6A53P2V/oB7rZFrRE/BOu2ADU4y5PMKtQbZdUqz4qtyPxkAoSod2iH6m6vmHnLlSxKmD3djkwJ8+cG4pxzA9wtEVZ36FTFbpi0swh6Cg4VOm8zt+a8x15ohXaQZSZmbcGtcH0xj+L6jidAv3vlQEaBok73BUEM7zSOAojdpn1z6C/T8UKzhWzW2iO4Us6nKr1CHusH/oOo3cJBdfXnAbn2vuvRo5gY7HGh9TyAZa8KB+LaiFlI252tu+3l6UXPqr6+eINoMANv3cWK4JiK0XUWOx0IpBEppqI9dS8BNVRb+VEOdR+A==
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=3sXC7bKMTvaM/Im+RuFHkslTamk4z5CqhBmXTzNI29c=;
 b=dpw9vzYFEQNGa00IpRBjJy+Y5t1ncG6fnTdVkCMcK/QE4Hy4li5ca4tn7EGH/RGxdF3+PEcA2MhynPfWMmtwmePJOAOgFkm0OGsdYdzwqfo1ZcpB3cwbWwjW2gv8do/xdsEU5CpCric+9bTk9kAHBBv2dAgqZCtg6pA1/1WdjNI=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Anthony PERARD
	, Michal Orzel , "Julien
 Grall" , Stefano Stabellini ,
	"Bertrand Marquis" , "Daniel P. Smith"
	
Subject: [PATCH v3 14/14] kconfig: Allow x86 to pick CONFIG_DOM0LESS_BOOT
Date: Fri, 13 Jun 2025 17:13:23 +0200
Message-ID: <20250613151612.754222-15-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250613151612.754222-1-agarciav@amd.com>
References: <20250613151612.754222-1-agarciav@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: DS1PEPF00017097:EE_|BL3PR12MB6642:EE_
X-MS-Office365-Filtering-Correlation-Id: 517b1110-60dc-45d4-5435-08ddaa8d5c08
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:
	=?us-ascii?Q?OjKq3mdOoZRdd8pgia2dAGKeg46B/vg4h53JP2CgmvF0AMWjadMAKtmVudOd?=
 =?us-ascii?Q?r7HSGpF2FsX9ugbe2L26hS+9c3nA6jBzsPIv9Q/kXFHDWe8biX70JmeqCMdR?=
 =?us-ascii?Q?bCA1xkZkPATH/Dfgwc73W6+8uI8Eu88Pvg7glfhwUfOm/8YiNCYGzRvDRGi0?=
 =?us-ascii?Q?Y30WW3uRBWtz4rke3HhRaINmxryGsqz3KAl0lUZUGt+gOi9j/+Q6edTcfvK9?=
 =?us-ascii?Q?oYfpDRXUEfzRwQ1+ydIIHzid1wrKOBtpGKulZuTDcrCH7Tmfjy7fmJTRsn4L?=
 =?us-ascii?Q?r852OEcaF05I46EsDkQ4h5iIMcSlpNkEBw2+OaUDbtD+0j2HY0Ykj536EPBv?=
 =?us-ascii?Q?tkrl17ddVOYhRRpquywfWNlfuvHWzh+YrSNCr25I53vLW9InH5JE5GLBMF5U?=
 =?us-ascii?Q?Y+23u4+OKJsceYZT/mnmvCpHERRoGfm+OdklCSFmVFnVk0UJwE9XvU45nZlj?=
 =?us-ascii?Q?nBftn/i4e+gp7xWYV7u37/wP7exJJCy476xY05t1FCLmOMSI2Y1eAMDdhgIQ?=
 =?us-ascii?Q?nt456oo9OsygZhq0iFJjyttEo502Nru8N+uAR9u9n6k/p50oIEbAH8ifLx9T?=
 =?us-ascii?Q?kwlJ40/nCPxkuPy/ggGibu7H5UpXoUx5dugKIDB9A2OB/b0xXjM7m6dE2g8V?=
 =?us-ascii?Q?ZMjd1X0JpW1wV9XBQASCabjX65aSHIjLnypJ7oatcWXbZLGN7Jj3IIvcGSDK?=
 =?us-ascii?Q?1e7NjwWs90xqNGLCYeFyKTJ/GmNYp96YyKdGLEeoMwIioOCJUlYv2zFVR6ye?=
 =?us-ascii?Q?u+0vlccmuGSxzga1QdVWB47wiADE989s+M9qBrR9mkD0Pg77/pigSmh8iK/e?=
 =?us-ascii?Q?8Zfpnk5JcVE21s/ynLnXKIOEklGzGf8WLO79esO/NI/I26UZmjONqZJtonNb?=
 =?us-ascii?Q?6Tm1ROdlkXUneG0a7evW3b/7UDOT1X5Fdmb46c3tmgGnlgqFpdIivYMyyBtR?=
 =?us-ascii?Q?fVbbXYWzHNs7zOKuFc6aIfy2yk0SOs9X4JI7ZV+WH8HAKk6qXyX0GnSnHl3i?=
 =?us-ascii?Q?COR1ZOuQQXlNpUg/+fza8BZZ8iiTmIxZyLeMtVVCYPEB/fzFwLzW0ByosFV2?=
 =?us-ascii?Q?Pro+I052pBYpNpxEfm5ZGDrVVnFfTWynKD26LZ3QVPUE2/kceZerJ8gOgJux?=
 =?us-ascii?Q?Vj2Oirr/A9PgPav0AF7zDcb62mz2XvEeJCa9KxesgWk7xxMfTjjzHkyaYPhq?=
 =?us-ascii?Q?EPrRsOn4gPt5Qh0bXUeajgyHZPyPyAZmK6SxH1PIRn+4RWFaBqo1T0nfOTYv?=
 =?us-ascii?Q?MLLaCVAUwJtCNrybIwSdSj2lYM1SpIQ6rD5TwTAP5/nLygtMrXZN1He2YfqI?=
 =?us-ascii?Q?yNU8z4Ek/TgrcK38QLXovOCBbEBNvcqRCcT5GPwJIroQNygZuuYfFdcppkPH?=
 =?us-ascii?Q?V0Y3kzOYveWsUpGVXGIS1FCw8a4nqS4OCfGh+7X/UKANA24tAfrpbxFjkk8u?=
 =?us-ascii?Q?535oZ5KfQ+IFv0O7ZD2vNYk6+8ZaF7D2cak3qmOuZSPFfGTigGSyA1jUR9HQ?=
 =?us-ascii?Q?pw76VQBy6nZP8JTbnTtWpVWS3uSXsq3U7VlA?=
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: 13 Jun 2025 15:17:06.6834
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 517b1110-60dc-45d4-5435-08ddaa8d5c08
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:
	DS1PEPF00017097.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL3PR12MB6642

Without picking CONFIG_HAS_DEVICE_TREE.

In order to do that. Allow CONFIG_DOM0LESS_BOOT to enable a subset
of the common/device-tree/ directory. x86 doesn't want dom0less-build.c,
as that's tightly integrated still to the ARM way of building domains.

Requires "unsupported" for the time being until all required patches
make it through.

Signed-off-by: Alejandro Vallejo 
---
 xen/arch/x86/Kconfig            |  1 +
 xen/common/Kconfig              | 12 +++++++-----
 xen/common/device-tree/Makefile |  2 +-
 3 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 752d5141bb..cb4f9a834b 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -18,6 +18,7 @@ config X86
 	select HAS_COMPAT
 	select HAS_CPUFREQ
 	select HAS_DIT
+	select HAS_DOM0LESS
 	select HAS_EHCI
 	select HAS_EX_TABLE
 	select HAS_FAST_MULTIPLY
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 2baa4221fd..5118ea7453 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -13,15 +13,17 @@ config CORE_PARKING
 	depends on NR_CPUS > 1
 
 config DOM0LESS_BOOT
-	bool "Dom0less boot support" if EXPERT
+	bool "Dom0less boot support" if EXPERT && (!X86 || UNSUPPORTED)
 	select LIBFDT
-	depends on HAS_DOM0LESS && HAS_DEVICE_TREE && DOMAIN_BUILD_HELPERS
-	default y
+	depends on HAS_DOM0LESS && (X86 || (HAS_DEVICE_TREE && DOMAIN_BUILD_HELPERS))
+	default y if !X86
 	help
 	  Dom0less boot support enables Xen to create and start domU guests during
 	  Xen boot without the need of a control domain (Dom0), which could be
 	  present anyway.
 
+	  If unsure on x86, say N.
+
 config DOMAIN_BUILD_HELPERS
 	bool
 
@@ -155,7 +157,7 @@ config NUMA
 
 config STATIC_MEMORY
 	bool "Static Allocation Support (UNSUPPORTED)" if UNSUPPORTED
-	depends on DOM0LESS_BOOT
+	depends on HAS_DEVICE_TREE && DOM0LESS_BOOT
 	help
 	  Static Allocation refers to system or sub-system(domains) for
 	  which memory areas are pre-defined by configuration using physical
@@ -174,7 +176,7 @@ config STATIC_SHM
 
 config STATIC_EVTCHN
 	bool "Static event channel support on a dom0less system"
-	depends on DOM0LESS_BOOT
+	depends on HAS_DEVICE_TREE && DOM0LESS_BOOT
 	default y
 	help
 	  This option enables establishing static event channel communication
diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
index cc56f42df9..f5410e685b 100644
--- a/xen/common/device-tree/Makefile
+++ b/xen/common/device-tree/Makefile
@@ -3,7 +3,7 @@ obj-$(CONFIG_HAS_DEVICE_TREE) += bootinfo-fdt.init.o
 obj-$(CONFIG_HAS_DEVICE_TREE) += bootinfo.init.o
 obj-$(CONFIG_HAS_DEVICE_TREE) += device-tree.o
 obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.init.o
-obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.init.o
+obj-$(filter-out $(CONFIG_X86),$(CONFIG_DOM0LESS_BOOT)) += dom0less-build.init.o
 obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o
 obj-$(CONFIG_HAS_DEVICE_TREE) += intc.o
 obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 15:28:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 15:28:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014563.1392687 (Exim 4.92)
	(envelope-from )
	id 1uQ6Kn-0001MX-B2; Fri, 13 Jun 2025 15:28:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014563.1392687; Fri, 13 Jun 2025 15:28: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 1uQ6Kn-0001MQ-8N; Fri, 13 Jun 2025 15:28:49 +0000
Received: by outflank-mailman (input) for mailman id 1014563;
 Fri, 13 Jun 2025 15:28: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 1uQ6Km-0001MK-7z
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 15:28:48 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on2061f.outbound.protection.outlook.com
 [2a01:111:f403:2412::61f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 175ee497-486b-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 17:28:45 +0200 (CEST)
Received: from SJ0PR03CA0144.namprd03.prod.outlook.com (2603:10b6:a03:33c::29)
 by IA1PR12MB7542.namprd12.prod.outlook.com (2603:10b6:208:42e::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.18; Fri, 13 Jun
 2025 15:28:41 +0000
Received: from SJ1PEPF00001CE5.namprd03.prod.outlook.com
 (2603:10b6:a03:33c:cafe::db) by SJ0PR03CA0144.outlook.office365.com
 (2603:10b6:a03:33c::29) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.19 via Frontend Transport; Fri,
 13 Jun 2025 15:28:40 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ1PEPF00001CE5.mail.protection.outlook.com (10.167.242.21) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Fri, 13 Jun 2025 15:28:39 +0000
Received: from localhost (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; Fri, 13 Jun
 2025 10:28:36 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 175ee497-486b-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=e/4RG1UFsnkBZgO06h67fiyzs0tRQuFeqTU4noLDDrelWK8oiJ8a1DRrbmu5H6UW8PNGc4J9KmhJ9WEVWfxRSQSbpVvsM5r4J2Oq5grtzYgOEFoQV9v8VS7jwAE5CHs1LHg4vf5rsFIYaP49tFEdLEwp9z506SE+UQPMRes8nn0QfxXauHzsXmxzNDaA+ZqPnaMKLjllJoXqFUw2mRZ35n7ivXeceRMMQQ/40xmYe1kkMdDH7TfU/POOVCz3iuk4TcbV3jQjyVE+hg+9Xcq+0LS8nXYn1Cjh2XfI70IZbfEUoRhPoGY8mnqzKpsMgcrRDyz71VJeiWmuMCzdNj/bfw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=FiVtHZzVUiY9eQQnXi2ggx7iYYniToaPfuwduTW6X4A=;
 b=SMYIKx0GdvwXi3r7qbWO01cEpnYfC8Ug7+vcKclrspb99zL4KNiaGLWg86pbrCTW4abHK0CWkcOvTkq0lBhGUP0gkL5zitmj7HsFr3OIqhCj9c/lRF/aNm3W51VTZb612tYGLkdG0fN8IpzWvhFobKXyvJjURahBTt+ExxTRacrdG3C9eMVufdVYY23NwDTKzddG9ud0TSvOXxCyUfVu8GHbL1aPkrmea6QA+c7YwkTDv80Ncu0nKw8W09Y71S8d/hWJC6DH7sJdhjkzD+qgyLwbevsCGNlTLcx374bhMIi24/PV9z1APD30gfPpSpg74sELZbeReTnmSZow7/nXGw==
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=FiVtHZzVUiY9eQQnXi2ggx7iYYniToaPfuwduTW6X4A=;
 b=dy0heACa1IfADYLu6TM2nH4ckem/FKaI5Yx4YBlFJSqUV8jEUf7mU1MwoHOW8SKqsaCGR6z5Sw9eOm5H4Rh2X+6nzP5ap84Ior3RSFnPt6x9PIq89GfdOY31xOQk1fqwV09JqjFo05Rxr7SEhNpCtS63Af6xJynZxyKNTFf8hvM=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 13 Jun 2025 17:28:34 +0200
Message-ID: 
Subject: Re: [PATCH v3 00/15] Allow x86 to unflatten DTs
From: Alejandro Vallejo 
To: Alejandro Vallejo , 
CC: Stefano Stabellini , Julien Grall
	, Bertrand Marquis , Michal Orzel
	, Volodymyr Babchuk , "Jan
 Beulich" , Andrew Cooper ,
	=?utf-8?q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD
	, "Daniel P. Smith"
	, Alistair Francis ,
	Bob Eshleman , Connor Davis ,
	Oleksii Kurochko 
X-Mailer: aerc 0.20.1
References: <20250613151612.754222-1-agarciav@amd.com>
In-Reply-To: <20250613151612.754222-1-agarciav@amd.com>
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: SJ1PEPF00001CE5:EE_|IA1PR12MB7542:EE_
X-MS-Office365-Filtering-Correlation-Id: 927769fd-fe11-4e05-b50a-08ddaa8ef93f
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|1800799024|36860700013|7416014|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?UlFHQ0tQQnMyKzU5UEl1L3dIanNMSUNOOUxpL05hTXdOYUYzZ202d0NNSTFh?=
 =?utf-8?B?YlYwaDJuQ3RONDdxdzc0UXFETU5FRjc5NHlxczJtbmlSalB0OHYra3M3MnVX?=
 =?utf-8?B?QVNVVDVGWU9NeUZGY1hEZnRHWlRnUmtqQUREK3p4eFV5K3U1Yzk3UlJvNzRn?=
 =?utf-8?B?Nys5Yi96bUNud3F3VEdSOXkvTTQzcTZhNWhXS0dtV0RTTDdJQVg2U2VJMG41?=
 =?utf-8?B?T3hDZWxqMGo5WmI4ZSs5VGswQUFTS3ZGSmpvS1E3UkFyZmxjd1ZyVFBrLzFK?=
 =?utf-8?B?Z0JOc0xSK2paakdpamF1SmRVK2ZId0pwYmdxTHNjZThldjV2RUh1OWtsN0dq?=
 =?utf-8?B?aURxdEI3VGhGV0dyMnBjUTFuU0pjRFRuanFRbmpreUI4RHVLMzE2RzFZZ0d0?=
 =?utf-8?B?ZWEvNlBldTVRbHQ5bEpZdHR6S2dtQ3kvQ2VYR0NQbmpqK2ZpRVdZVWppU0Ni?=
 =?utf-8?B?c3U0eHJDck5OaExrNnNxb2tvV2RNc0V0OVZ1YkZBMlJIUUxPUUdwVXRkVXRS?=
 =?utf-8?B?QlVPTk5zRmwzeEZQamhRSmJZT3kzR01OZittRmVjb0Q4UDNXbUtVUDFGNUpS?=
 =?utf-8?B?VWJZVzlZZktrTXg5VW9RSGxhR3I3U2svbElXOTR1b1lsLzYvYUZRT1duSTdP?=
 =?utf-8?B?QkFGdCtyRGh1M3ppWEM3d0tGUE4zZEk3R1RWSEVWaHBKQWtWK0FoQ1ZNTGtB?=
 =?utf-8?B?YWhNQm9tbkMvd1RWc2ZqTnlqTDJZREtnV1VvNklTczhickZtOW5KODdCVWtS?=
 =?utf-8?B?aUxqTi9IUnh0Ti94aTdzaG9hcE0xTW1RWldlR0Z3S2xwSTc4NEM5bGs1UEI4?=
 =?utf-8?B?ZDJwTjdxbGpDTGwzV2ZCQmFWZVZ6K2orRDZBaHNJeEI5ODZvTzBrQS9ZRTQr?=
 =?utf-8?B?Ulk4SGNSZGgrTjZjdVNFbDBvMDRhR3U2SUM1NWp3L3VhYkhMVEZjNDN6STNJ?=
 =?utf-8?B?QXB4OUdLVXkzOStXQWNHbFdxL01GN2dPdmpFOGtOWGZBcTlHTWp0ZWVlQm0y?=
 =?utf-8?B?Y0RuUGFzMCs5NzNwaHRwcDIvRmZSSWJuWjRnRzNPdTNyVUc3WkxrWjR5MmhG?=
 =?utf-8?B?b2VXNWRRT3M1eXNMT0lzeEdYaWlmYjBGeUZ1WXMvaGxrUEpZWDI4VytXWXR2?=
 =?utf-8?B?REgrZ1FpcklTRjNRVmxmMmlSZVhKdWo0ZCs1bWF4dFdiMk5aenFmRTJKSmNN?=
 =?utf-8?B?ZDNMcmRkYmQ0cTlSSkNidUdyNW1QdTVDbmhmSWhnd1h2eEk1ZjNoUlE1Mk5F?=
 =?utf-8?B?SzdlTjZmUEZFL2Jva3U1YUY1c0NtbitOdGozRFpBdzBwZzN1REZnN1Z3eXlE?=
 =?utf-8?B?MHl6ZnJvZDd5UEN2VHIreEVNcnRPaFFtVGFHT2tUNURVQlp3Nmg2NEw4MjhE?=
 =?utf-8?B?NzFwTzVuVFZYVy94OTJKWUkxYmdKU3p1cU5uYXhrbndBMHdJZTdVMWY0TVJk?=
 =?utf-8?B?RGhvaUhHenlpRmRHanNuSUNBYi9CQWZGQUhwbHpIMitsb2pzRkFhSU9FVFRt?=
 =?utf-8?B?S1d4OVpuTEJOaThDa2JidmVtTjFma3l6UUNhdDFVSTJTVStmR0hNTCtxM0pi?=
 =?utf-8?B?bGZlN20vQ0tZYWNVQVlCV1ZBRzRVNUFSMTkxMXNzWkZwaUVSSXlBMjhEdExN?=
 =?utf-8?B?bnZTNExzN2todmtwSnZ2cWZiRjE1eERaVlZvZDFQWkN4d0VPV0lYbDA0M3pk?=
 =?utf-8?B?VEZkK0RLZjZLcWQyVDBaQnhxY2hENFB3N1NBd2JFNHR1VXA0a1NnbXg5aWxm?=
 =?utf-8?B?NDRnaFhYemVsWnNoVnJBME85b3lXbkhnZlR1eVNiNlVmaVRSSG4zR1F6UWtV?=
 =?utf-8?B?UG9qMUJ6SVFOR002TG55S0hYYk82c3VxVE5Ta3FxLzlxUjBDMkNxa0Faaloz?=
 =?utf-8?B?RkRqNkN2QzJ3K01QcHk3YVBhcW1VTmw3SVQycm91YlJBTDg0RHdyODFaTHFV?=
 =?utf-8?B?NDg5UU51TmdaY1YvM1BPT0s4MEZtcU96ZTFpSmlvZ0xlbHBjTFRVRG1xZkM5?=
 =?utf-8?B?dEJONWFUeERZRkVnbEZXN3NHVkRBS0lIeU1vTUx0QUN6d0d2RVdnRVh2cmN6?=
 =?utf-8?Q?3bR6QM?=
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);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jun 2025 15:28:39.8994
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 927769fd-fe11-4e05-b50a-08ddaa8ef93f
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:
	SJ1PEPF00001CE5.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB7542

Bah, ought to be 00/14. Missed during copy.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Fri Jun 13 15:31:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 15:31:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014573.1392697 (Exim 4.92)
	(envelope-from )
	id 1uQ6N4-0002xP-QV; Fri, 13 Jun 2025 15:31:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014573.1392697; Fri, 13 Jun 2025 15:31:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uQ6N4-0002xI-NH; Fri, 13 Jun 2025 15:31:10 +0000
Received: by outflank-mailman (input) for mailman id 1014573;
 Fri, 13 Jun 2025 15:31: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 1uQ6N3-0002wh-0v
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 15:31:09 +0000
Received: from AS8PR04CU009.outbound.protection.outlook.com
 (mail-westeuropeazlp170110003.outbound.protection.outlook.com
 [2a01:111:f403:c201::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6d257372-486b-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 17:31:08 +0200 (CEST)
Received: from DB8PR09CA0013.eurprd09.prod.outlook.com (2603:10a6:10:a0::26)
 by DBBPR08MB10411.eurprd08.prod.outlook.com (2603:10a6:10:536::21) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.25; Fri, 13 Jun
 2025 15:31:05 +0000
Received: from DB5PEPF00014B91.eurprd02.prod.outlook.com
 (2603:10a6:10:a0:cafe::7f) by DB8PR09CA0013.outlook.office365.com
 (2603:10a6:10:a0::26) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.22 via Frontend Transport; Fri,
 13 Jun 2025 15:31:05 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 DB5PEPF00014B91.mail.protection.outlook.com (10.167.8.229) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.15
 via Frontend Transport; Fri, 13 Jun 2025 15:31:04 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com (2603:10a6:5:1c::25) by
 DBBPR08MB5963.eurprd08.prod.outlook.com (2603:10a6:10:205::21) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8835.24; Fri, 13 Jun 2025 15:30:33 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668]) by DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668%2]) with mapi id 15.20.8813.024; Fri, 13 Jun 2025
 15:30: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: 6d257372-486b-11f0-a309-13f23c93f187
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=X5yrAOypvwstGXzTq4brH42yrX4NL+IRnPKaRuvLlV3SPCodjTQGFKweNHqEXDC9+tMGMN7JvBE5CmKnlvcHIxVjvKja4HFVckZsJlSbp6aFNF5blCRXrBKI28fhQPIpzkOTdXJJg0fzHXQWW056y4+9k+1askIgcKIEZePPiUEZF8xX9KTG+JEQWlOgEJDaaA+3SAPfWewkY49z1/JuIT2cOPkHdMgxixeC4gD4fvFr0B41PZbPQrejDbAJ0IEfvgy1qqNbw03JJ9evfopO4Ws3n/LnKU3XxItCQjZlz6tKXQTABO068CRxAsMY8qHZRBFitx10iT08U4tGCz+n7w==
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=dMIu5wUeJjbk+Ms45dViBZFyg9ZqYhOnoqv70elwZC8=;
 b=Lj0syba3sKWESx+FhGlGI7OYAb8ZzPrSniBx0RSZIwhd8XrHAai7snAax9GrvrcFEmpzKbLqZTJ/AILhRsvMDk2Wcr/SIvOUnlW1VmMp8646fkWOTMRAJJ9Mpcv/2sz/lVc8mydd15lLufo0dh1tZPY597ayAxHbsremV+OXcqrS9IbqYA2nh13BIhuhxwhEYP1vTh5XKM3OW2VXo2MxLAsFVl5ljCJeXnvnkMrTznXm4A1Tt1I+ffC3dlXTqfz3lOhq0n6jmrwk1Up6gxdNPU4gSf2fwlTo8QwHCL3X1hPz2R3V6pJy7WIAzAQE0Toy/TiSs897/77J9M00i4ftYQ==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=amd.com smtp.mailfrom=arm.com; dmarc=pass
 (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
 (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=dMIu5wUeJjbk+Ms45dViBZFyg9ZqYhOnoqv70elwZC8=;
 b=MJejARUxB1etrro2595jLQLS6C/E6mmQ+Fb+JM2UPMynTJ9i1fWx+Ry2OoUD0693Y/9vy8160wY4G+AO8E5ic2pve+UinlcsTqk8N0WOysvYBcLitXH4dwi/Wg1yQmZAJIVyvVt4W1Lv/sTbCuKlU7gYKVkZXtGcjF1A1tw0llc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=vHLFM7R1bC6KidbrhaRJsRU3Qlj6dlVP0LiG3ycp0s3c5TccdaHYsKPPaEBJD7rBs1q7gnMlzihxoPSphMKr+xBljfNzygvR3lpuvhGKUbzazpaCdkgq0/DkFti8sZmIvp2HCtFVBT6MINXzplFHIlSBBbCozI8s6yZq9gh/3/lUJD5ZL+9NpYxG2YA/jg8nPTyOplmsTZNUfwMuHiGMt9Bbuhd/2Zk3m6Cw6EKc1ET7vfIj8+tndDpt43YcV/MkU2gsTR+VT4h+318CFyCAqpTA492/Pw7qUuISqSiFzWkdPLMWd/GCUZvRl8vBgnoBczRZnqPsCkriXNdjczebog==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=dMIu5wUeJjbk+Ms45dViBZFyg9ZqYhOnoqv70elwZC8=;
 b=IsUQPOxN4OKj+w32NCSDCAERBIMnx2atZhPSkgy37/2Lu6iifzNVDn2iJH/nm8E14751jVMtQF2iZUHa7Al+jrXsMFn8ViyXBIUMaj7uceyv0lBhDDHYz8p3oGXYxoO0v4yrTUxcgGTObjtECX8oksPicoT3BUCtczHTnL+hS8psnZnZT2QqVgYaNYWhtoWRtSMnHZdGIO7zyV4sH0FwC3Q/qjxOWWI24h/31Fb4OA5eYeCs9aEa7oFfV7dZtSwT74hmY7hYoezYAuAcPvDfVUSIoP35qv6YKfCLq4iViXiEwgKBFK+wB3GdqZNCmZshU3yVbVe9vw9d/wlvZzHjLg==
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=dMIu5wUeJjbk+Ms45dViBZFyg9ZqYhOnoqv70elwZC8=;
 b=MJejARUxB1etrro2595jLQLS6C/E6mmQ+Fb+JM2UPMynTJ9i1fWx+Ry2OoUD0693Y/9vy8160wY4G+AO8E5ic2pve+UinlcsTqk8N0WOysvYBcLitXH4dwi/Wg1yQmZAJIVyvVt4W1Lv/sTbCuKlU7gYKVkZXtGcjF1A1tw0llc=
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 v3 1/6] arm/mpu: Introduce MPU memory region map structure
Thread-Topic: [PATCH v3 1/6] arm/mpu: Introduce MPU memory region map
 structure
Thread-Index: AQHb2t5CMbXSS0y8Xk2wSj8YvRec8LQBOlIA
Date: Fri, 13 Jun 2025 15:30:33 +0000
Message-ID: <99FAD22A-F056-40B3-81DF-A571AB6DD935@arm.com>
References: <20250611143544.3453532-1-ayan.kumar.halder@amd.com>
 <20250611143544.3453532-2-ayan.kumar.halder@amd.com>
In-Reply-To: <20250611143544.3453532-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.600.51.1.1)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB7PR08MB2987:EE_|DBBPR08MB5963:EE_|DB5PEPF00014B91:EE_|DBBPR08MB10411:EE_
X-MS-Office365-Filtering-Correlation-Id: 91ee2932-dcb8-4f60-dc2c-08ddaa8f4faf
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:
 =?utf-8?B?WEZJRFdRSmVLNWs3Nk1hdFpDQTVURC9NNFgrTVpZOXdtZDA3MTNHTTBMRFdD?=
 =?utf-8?B?ZS9lQmZvVWM3b0tNVUdUMEg2NDBDQXVrMU9WVVFscldaeUhYR0lUNGxwendu?=
 =?utf-8?B?aUcvRHllb1JDYW90ZnpEMWc0Zjh6YWtjdWEzTHVTQU16aVkrR2hmTDlIR3hX?=
 =?utf-8?B?L0FkY0k5ZjBoT1pWQzk1Sm85end6K0hzcU1hWFRwYXhzaXNvd1cvUjIvd2tI?=
 =?utf-8?B?Znd3ZWlXYW9nUmJWWS80UGVEYXhpZnN6SHpYWTFCS3daVjV3bFBTeXpKV2tM?=
 =?utf-8?B?Q09XWDcwUUI1OUZqVGpibjl4WUJOL24vUjJ3bXJRazFrbDJ3TkdRVUR2eGlN?=
 =?utf-8?B?VlRqYkdWVVd5UjVtY3p2b3FlNWVSQ3Y3aTNMdTcxS0gwNDZMUitNamVrbEoz?=
 =?utf-8?B?Tk1tSmVHUkZXQXhjaEF5TVlyRk9pc2VrYmJCOVpIeVI5VU9DczZvVjhCRThJ?=
 =?utf-8?B?d0QxUFBxM1FHcFpmYStvamhnV0ViaFBxdGtnMXN2OHprZEhDUVJ1bElnTTZv?=
 =?utf-8?B?K3Q0ZlJoZDE3VUhjL0RaL0RzcVJ6R1kyejg0OVFRbU1iL2FmKzUySzFhZWFp?=
 =?utf-8?B?WndXQjJPaTNsZlBUVGN4anFFUHZ1dHhvVmhiVE9HTlBSd1VWSFdyY1NIVE5U?=
 =?utf-8?B?YUlWVG9COUE1aldEbDl5dUtNL29BUXpYaGNoZ1kyNUZ5dkx4K0R4RDBBaEtV?=
 =?utf-8?B?Zlo3ZS9aUGVsOHRIZXFvbERhY0thUzJRTzV0ODR1aW1obGV1eG9aZlBERWtQ?=
 =?utf-8?B?NVp4elF3dW9CdURmNG5LOFdIUk5HL2gyVEFCYndvMVBQNmVmM2RLUS9kNE1u?=
 =?utf-8?B?eEJabE82d0tsVEh1QXB3NEhmWWlmTmhqQVByeDFEaE9nYkF0YkFNVFpWV0NG?=
 =?utf-8?B?WjFnbnEyc1A4dWwvaHdLeERPYm43Y3c1R05SY1FuVkZRNVpRbVlUSm40aFVn?=
 =?utf-8?B?YWRwUkJLcWtlejM5Z3h5TDQ2a1VMdXNRUnFZMnNEQ0M4UFBVK2dTZ1NhYVh6?=
 =?utf-8?B?Ukg0YW92UXNvbXUzVFY4MWF0NTZJYjF3VzI4bEVmcS9lM1Y0cnF3TVREVldh?=
 =?utf-8?B?RlVmblY1cTVOY1BZU0Yza1BOc3hPL1YrUzI2RUsyRWtnQjBZT21lMWMvTmcw?=
 =?utf-8?B?RnNnZ0V0akFNZHZ2ODVVYWR3bGlxL2tKU29neTBIY0Exazg5bWMrMXd5UjIr?=
 =?utf-8?B?WlJjZXczMGdJdnZVR1VjMXM2M1dIQnQzVzZwbllxSXQrMFR4YytWdkc3ZVMw?=
 =?utf-8?B?b2c0c1MyaTJiRjRWWkJZdWJlTEM2aTNqQllUdE9iYysvbHR1d1dmWXJuSVBq?=
 =?utf-8?B?TSttd0RzelQ3MWpScmg5L2NKWVdNbFpkUVh6R0wvZkpvbVQ3d3FlSDVTS0Ft?=
 =?utf-8?B?SjdaTlNicndDaU85M2x1dU1SVnVlQWd0RTEzV1hEaDh4VHBkNkJiV3o1QjRa?=
 =?utf-8?B?Q1k5M2pJdlRVYldLNHRZT3Z5MU9LbmoxZ2gwb012aXA5QmNITnZUOTBVWUNZ?=
 =?utf-8?B?VEszL2htV1ZRNm05NnY2Y1VVaUVjWlhWZG12dXlXWlRrNTREUHA4d3NxNVVl?=
 =?utf-8?B?ak5FSm94cjZiQ0hIZllUNksyYUZJc2puMXNuK0xzcGsxQmZ6Y0pFRGVmbFRH?=
 =?utf-8?B?a1ljWUpBTjRzZ3IyNUNBaVZERXpVMU5DRnlqSVFVd0g1TmpXZDRzYXhiWmhn?=
 =?utf-8?B?a2poWXVBRk40elBHSGYvaHVjaGwzL0ZxT2RVZk9BQlRjZXo1ZDR3Vzk3NEJw?=
 =?utf-8?B?OFJTbmFBaExZek5sYVFnRFFTTDlISmJuMXhwY2tubWtvYU9KYWE1b1E2NVZT?=
 =?utf-8?B?aGRWOGVmYmtvNFpmeUoxMExyNldVbnJhaDlOalZUeCtXV0dJWC9NRkloK3pp?=
 =?utf-8?B?OG4zNWhoNmJ4MUI1b2JOQkVEUitYTWQ2R3AvOG1pWjM5cVg4Mm93MVlGRytL?=
 =?utf-8?B?SGlVNUgvbVpVNWM2c2ZDTi9JWFpkNG05UVJQOGFRN0pOYmhCVFhUWDhJcm1s?=
 =?utf-8?Q?Smum8ocuKJAU6Ed/xBXovjUBhSHv88=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB7PR08MB2987.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="utf-8"
Content-ID: <5CA6007ED3FBC54883D04A9790164C39@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB5963
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DB5PEPF00014B91.eurprd02.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	e8a727ce-4668-41fe-c4cd-08ddaa8f3cae
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|35042699022|82310400026|14060799003|36860700013|1800799024|376014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?NnhLMGFJeXFIVVY4R1hoOVFvaHV6dER4a255a2VhTFVndnpYd0N2QlpGc0Zu?=
 =?utf-8?B?TE1WamJHYWxjRGkzOXVKMjNLSlgrQURMeCtaSmM5YU1kUVdJRUNPd1NjT3lF?=
 =?utf-8?B?MFJLYjUrSW91OTlTN2ErYjZNOHpxQ09SOHhQZmlNRGlSUGgyQzJZR011VmMy?=
 =?utf-8?B?MmpPTWVWaWRWak5WczFLMk5NV290ODN1WXFBbksxTTNvdjJjVy81SGVHYUNE?=
 =?utf-8?B?cUJPbnlERkdacGtqMGNQZWk0QTNlbTRuTnZDT0dkV2VkRFFzeEJXR0c4MGJz?=
 =?utf-8?B?S3Y4OHdmRFk2RXZUdmRQbVFLVUsxOUt4bXlPS29SSjVpNHZ6aUd5UE5lVkIr?=
 =?utf-8?B?SDV1Zjg4MHhVTFV5UDN0NitRNDZla3NGZ2tlcDNaUGk4RmxkcGZwTHBnNHcv?=
 =?utf-8?B?U3AvWFZTRXh4NjcvR0gwblZmK2h5RDBWdW11L3FpRVlvakw3QnpPRWZ0ODZ6?=
 =?utf-8?B?cnhEbDV1REd1RHVsSDZTNmxnYno1dm1mY2ZQUWVLamV3ZUJvWXFvaTJlaFY3?=
 =?utf-8?B?UFd6Ulc1N3dsSHp6OFdaaDA3SlBtYldJVXVsUzhJN2FEaWNCOGFaOERPMVpL?=
 =?utf-8?B?MU42ejdJczRFTnZHR2Jja3B3MUJxNmlNU2lJYmtUUWV3bkxUaU84NlNlL3ho?=
 =?utf-8?B?WThNTFpDMlZBUFB5VUxjR3A4UnZSak1wZ3EweFB1NUdVMEQ2dUQ4K1pUTHBm?=
 =?utf-8?B?VEhNOUhBU1p2a1N6bDlrNEFpYkNkUEtIcGZMRTVGbkc4L0ppcG9NK1FKbk9l?=
 =?utf-8?B?SHpqOXg5alVHQ0hSYkRPQXVQSDc2Tjc4WnRJOVN2M0c3ZWxIM3MzZUo1UHF3?=
 =?utf-8?B?eUNCcjF4OGtjQ05kNjVQSm9tbWcvaWI5bEh1WnBRVzZDazJlK0JwK2R5Rm9r?=
 =?utf-8?B?N0ZkSXZnMmlyejI4Vnoxb0REU2NoaEQyWllJVm1QQlJxU3hYa0c2N1BqdFgr?=
 =?utf-8?B?eVhNbVBXVmhLSVBhelVmanpUMnJoUGVDd0ZPNXNzZ2lVUjdTa1Z5MGd6WDVJ?=
 =?utf-8?B?dXlWemFWTkpSQWhtclU4blBxZDYyYlRxZjJYbndIc0ZrL00wcHpRQW9sZVl6?=
 =?utf-8?B?dHNIbUlhaGp1N2V3NUlRTUFYSmE5MFV5ZDNQVEFkeU0wSG9PeEVxVEU3WXUv?=
 =?utf-8?B?RDRyNWVMUW5ITjhsZG1sTGExSjJ0Nkd3WXRUZ2FiT055cm5jNGU4RXFVME1r?=
 =?utf-8?B?UGVhVFpNckdJVkVtelpEOEFJUGRCdXRxS2JMT1VoZS94eDFyNUIrR2hZMnFB?=
 =?utf-8?B?b1JSTUJxZ1g0cmk2RmExdjMwTjh0OTNHazlBNE1BQTZxOC91bDJoWjRHMUE1?=
 =?utf-8?B?ZlZKbVJzeDNxUW5yVmczSXp3MHRIWFFlZW4xekZVK0NSVy84eEJuU2I0L3c3?=
 =?utf-8?B?QXZMSWt6bUZsaXVYcUc3WERONWduZXZ4bldSNVlUNFZKNjBhbXJxbVQxVCtJ?=
 =?utf-8?B?RXFOM2F6RFRVYjJJVnc1WGkvL2JERlMzTFJPL0VtNERULzVIeTJrN211cHQx?=
 =?utf-8?B?a3RFUVZMcW9vNlpvR3ZQQ3pQdHlRSTQvYlltVlYrZlBvNTJ4aHU3TmRMa2Jj?=
 =?utf-8?B?WGxzS1NOU2pXNzJ3KzFTQU5YYWVYcGVhVkVycXYxU0lmRUYydnBiWXhPdjJP?=
 =?utf-8?B?bmJOeGh0TjlpVlBOZUN1TGtCL2FNRHd0QTRrNzgvWnZsTFhVSGxBOFozZVBk?=
 =?utf-8?B?TldYdFAwWndXTStNcVU0TStqajBsb1JCWDFFemdXUHdER0JYcXF0VWxpZ01n?=
 =?utf-8?B?bE5TZUo1bHhVNkNQZlFlcm93MWsxWnVISTRITVVMODhlRlhPOVg2TEY4TkNN?=
 =?utf-8?B?cUF0Um9wYmFXRDR3cW1SL1B1ME91aVFRRnM5d043UE5ubUhibmRudEIwYkZW?=
 =?utf-8?B?aDRmd0VtMk0rejhoV0h2NXRnT1JJRGdPVHpHZTZXeGpuOEp5OUhiT2JHcGZ2?=
 =?utf-8?B?V3JWbElId2txc1ExeVozbXZZcjltTllvaEl6NGJHRzVJV0k0VWlDMUpXVlFl?=
 =?utf-8?B?YjJycDMydS9xdmFzSlg3RVgva1E4TGE0cnZKcGVRdmJOZGE5TVc2ZFNBWW8x?=
 =?utf-8?Q?rfH2sD?=
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(35042699022)(82310400026)(14060799003)(36860700013)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jun 2025 15:31:04.9353
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 91ee2932-dcb8-4f60-dc2c-08ddaa8f4faf
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DB5PEPF00014B91.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB10411

SGkgQXlhbiwNCg0KPiBPbiAxMSBKdW4gMjAyNSwgYXQgMTU6MzUsIEF5YW4gS3VtYXIgSGFsZGVy
IDxheWFuLmt1bWFyLmhhbGRlckBhbWQuY29tPiB3cm90ZToNCj4gDQo+IEludHJvZHVjZSBwcl90
IHR5cGVkZWYgd2hpY2ggaXMgYSBzdHJ1Y3R1cmUgaGF2aW5nIHRoZSBwcmJhciBhbmQgcHJsYXIg
bWVtYmVycywNCj4gZWFjaCBiZWluZyBzdHJ1Y3R1cmVkIGFzIHRoZSByZWdpc3RlcnMgb2YgdGhl
IEFBcmNoMzIgQXJtdjgtUiBhcmNoaXRlY3R1cmUuDQo+IA0KPiBBbHNvLCBkZWZpbmUgTVBVX1JF
R0lPTl9SRVMwIHRvIDAgYXMgdGhlcmUgYXJlIG5vIHJlc2VydmVkIDAgYml0cyBiZXlvbmQgdGhl
DQo+IEJBU0Ugb3IgTElNSVQgYml0ZmllbGRzIGluIHByYmFyIG9yIHBybGFyIHJlc3BlY3RpdmVs
eS4NCj4gDQo+IEluIHByX29mX2FkZHIoKSwgZW5jbG9zZSBwcmJhciBhbmQgcHJsYXIgYXJtNjQg
c3BlY2lmaWMgYml0ZmllbGRzIHdpdGgNCj4gYXBwcm9wcmlhdGUgbWFjcm9zLiBTbywgdGhhdCB0
aGlzIGZ1bmN0aW9uIGNhbiBiZSBsYXRlciByZXVzZWQgZm9yIGFybTMyIGFzDQo+IHdlbGwuDQo+
IA0KPiBTaWduZWQtb2ZmLWJ5OiBBeWFuIEt1bWFyIEhhbGRlciA8YXlhbi5rdW1hci5oYWxkZXJA
YW1kLmNvbT4NCg0KTEdUTSEgSeKAmXZlIGFsc28gYnVpbHQgZm9yIEFybTMyIGFuZCBBcm02NC4N
Cg0KUmV2aWV3ZWQtYnk6IEx1Y2EgRmFuY2VsbHUgPGx1Y2EuZmFuY2VsbHVAYXJtLmNvbT4NCg0K


From xen-devel-bounces@lists.xenproject.org Fri Jun 13 15:40:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 15:40:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014597.1392708 (Exim 4.92)
	(envelope-from )
	id 1uQ6Vh-00051I-M8; Fri, 13 Jun 2025 15:40:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014597.1392708; Fri, 13 Jun 2025 15:40:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uQ6Vh-00050o-Gu; Fri, 13 Jun 2025 15:40:05 +0000
Received: by outflank-mailman (input) for mailman id 1014597;
 Fri, 13 Jun 2025 15:40: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 1uQ6Vg-0004iP-6T
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 15:40:04 +0000
Received: from AS8PR04CU009.outbound.protection.outlook.com
 (mail-westeuropeazlp170110003.outbound.protection.outlook.com
 [2a01:111:f403:c201::3])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ab9d6248-486c-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 17:40:02 +0200 (CEST)
Received: from DU2PR04CA0318.eurprd04.prod.outlook.com (2603:10a6:10:2b5::23)
 by AS8PR08MB6104.eurprd08.prod.outlook.com (2603:10a6:20b:299::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.18; Fri, 13 Jun
 2025 15:39:58 +0000
Received: from DU6PEPF00009526.eurprd02.prod.outlook.com
 (2603:10a6:10:2b5:cafe::a) by DU2PR04CA0318.outlook.office365.com
 (2603:10a6:10:2b5::23) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.25 via Frontend Transport; Fri,
 13 Jun 2025 15:39:58 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 DU6PEPF00009526.mail.protection.outlook.com (10.167.8.7) with Microsoft SMTP
 Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.15 via
 Frontend Transport; Fri, 13 Jun 2025 15:39:56 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com (2603:10a6:5:1c::25) by
 GVXPR08MB7727.eurprd08.prod.outlook.com (2603:10a6:150:6b::6) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8792.34; Fri, 13 Jun 2025 15:39:21 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668]) by DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668%2]) with mapi id 15.20.8813.024; Fri, 13 Jun 2025
 15:39: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: ab9d6248-486c-11f0-b894-0df219b8e170
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=EFK/KbcPj9Ns3d/AkuwQWUnSAsRyFXsFDahLebJYlEC2TDp7EQrios8pYCI7x6Ll+FN/l0KPGMDQzv20GGL4ZdRNCFSZUYbtPbA/xFx19aP2vDq8H98+ENu9Z6apKEC4IDv8YPF6WpSPa6kbvMjuUXNQ1v9r2VSoLS+gXMJnx0Hux+eGtqpMezy5v7qq90aVB1WDAh2VIV7txbAQtAqhnVDG6guu2ghkNdR8tqVyTiAz2inZj3xpw2ApxkHq/wuiGwqA8QOYXsOD9mnZoYZ+6NCHjJlrmXkCfpqgJ742B/6X4ukezx4dSRzRemUFpTv8obIy+dBoUIdw/F2KWWAc5Q==
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=xOeunrsjP1nZaW+DLJHQ+Z0jzivpn/v68lRbvAtK0V0=;
 b=zCfImC3mnlYCKkY3o0tpLXeeIJExzYRL10h/Q2yH0aJHNITqXM9LZOpDel8+sVQjivGDPgb4guz010NmUWmjqiJq8CYqnbpEdOhz12LBlEzcK1XeTls5zIivr6Ie73MyTAWXsyX/NfDOe33IbEnneEBV9pRZRDAR5YPE3WSnNLrKUZ9wxI9osmPBFFkpEeDURnXxygy3fgQ8Nh5DopejWkOkLKXkhdfN/uXEtW53bSNw+dkCyzba1OzickgzMI+frrmLWyQ1PknYw0nP56LG9QY1o+e9gYP+xtmjmoN4MAmF2kOqo3vncZ+eThOn/l5bLWKRkRO1sv3KJtcLEbrHYQ==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=amd.com smtp.mailfrom=arm.com; dmarc=pass
 (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
 (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=xOeunrsjP1nZaW+DLJHQ+Z0jzivpn/v68lRbvAtK0V0=;
 b=D9u/0X3KZSIBg6Zb7nMYNMSmqPsS6BiYNnPVVEye6fJ+QlSCW949gwfB6c2aIS/1r1p05sYvzHzyDjxqtgTH93y2qBLYCNpfts4CgRKTLuXQel3jQJTkB9jlKg87mnH2z7C96lHuLzRQSq2oXhli2VXdFl8qWRISRTua5GKJiLY=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=G6S/Elf97FoRfypsp78D5nt/UgkEyNXhoULjvdQfWl/AHd+tCFGRsFjmD95kTknYuFUmfLhuKXea6NhDdXTlLWLSY3T2+w5m8icvkyQZD6ymO5XvgubNbWz40pFak93nhwdJ/KYiPIQAt3nnYtzewQp2Du/YH+SGBwZ/x/9/qkbqbrNWqLNHo6eaB0yGd85omL58bKsOWzU8XGEfa7AcvmZxJ93lMHqyJY4Jumi0Zp6yOcm3UD/3bW9NF6DGbiWRZiG9pM9+zHEad50KZhSN9sNMPhidfAFf5u22/0S+15b+gvfWIX//h7WMHAkZ+mytjUn+8iF6fQxNyLX7q7PMMA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=xOeunrsjP1nZaW+DLJHQ+Z0jzivpn/v68lRbvAtK0V0=;
 b=liVk+XaS/WYru8IHD7c1L/H9A3boTPJIbtRNLVXbv0hvIg1216PvIo9pHnoNQeOATVREofxmiwmIkYZo6VCa3TgW11XlKnQDlOCP6+b/TWpwKpx2ickXv4TVnEGNICWrvHKjJwcFOtawUE44kcCryZL58UI4AN0d6PD/XpIsrhqARDwAX1Ck0rleiSkZndIT6oxYAZOA4xS+8Xw1XJ7XngwlmLwncboNu6E00EVAi5ssOvVFurkXgrmRKxi9RvFxbbGT+je7kGQFfKtkyWJ9jUPHTHadC/CxFtManszbK/xUpvnM8kxpW54eGGNI43TaL+4XB+3TADu6SAgTwNg8gQ==
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=xOeunrsjP1nZaW+DLJHQ+Z0jzivpn/v68lRbvAtK0V0=;
 b=D9u/0X3KZSIBg6Zb7nMYNMSmqPsS6BiYNnPVVEye6fJ+QlSCW949gwfB6c2aIS/1r1p05sYvzHzyDjxqtgTH93y2qBLYCNpfts4CgRKTLuXQel3jQJTkB9jlKg87mnH2z7C96lHuLzRQSq2oXhli2VXdFl8qWRISRTua5GKJiLY=
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 v3 2/6] arm/mpu: Provide and populate MPU C data
 structures
Thread-Topic: [PATCH v3 2/6] arm/mpu: Provide and populate MPU C data
 structures
Thread-Index: AQHb2t5PH46Li7ClPkCuT4B0B2toC7QBPMgA
Date: Fri, 13 Jun 2025 15:39:20 +0000
Message-ID: <067962B3-7AEA-4A4E-A55E-1BEC66132706@arm.com>
References: <20250611143544.3453532-1-ayan.kumar.halder@amd.com>
 <20250611143544.3453532-3-ayan.kumar.halder@amd.com>
In-Reply-To: <20250611143544.3453532-3-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.600.51.1.1)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB7PR08MB2987:EE_|GVXPR08MB7727:EE_|DU6PEPF00009526:EE_|AS8PR08MB6104:EE_
X-MS-Office365-Filtering-Correlation-Id: 943f7879-8271-4ea5-8eed-08ddaa908c6f
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:
 =?utf-8?B?VUlNWjFTaG1SbzJ3WVZvMGVmRXBNMys2VjFZTytyRTFSamR0RDYrWm5SUzA0?=
 =?utf-8?B?R1A5Vy82aEpyYWFUaCtVTWppTUJuaHlQQXFqUDlGeDQvVE9EYXJ2OTFEVmsx?=
 =?utf-8?B?TmE3cHV2VHQ3aVh2aE5Bd3JpZE9XbXQyOXdPazUzRXltUGJQVDQ5U1NLMVJO?=
 =?utf-8?B?V0o0bUJhYmgybmlDQTRJc01PTlV2dXUyeGdSc2xKSUYzSFUzajhYRlUwazlt?=
 =?utf-8?B?aVZ3QzVFSFRPd1RPcUVucE8yV24vKzNpL2xuTkxFeUdlMG53NjRibTY5QTdw?=
 =?utf-8?B?ZkNlRHFtSnpHSm1sSmtPck1jWWFKMU1nek8yeXlrV0l6TE5KY205eDNCdUdy?=
 =?utf-8?B?NzhpVEYrNm14ZVJzZi9VTUJqQ0pjaVFOU3NpK2JYdFA0YXh3YW9nS0VDVkdB?=
 =?utf-8?B?enpMVm96OE1qUzBaY3VKSmJ1d1dZaEpUK0lHUjhtZlk2VDYvR2ZoMGxmYmZ2?=
 =?utf-8?B?UUdCY3ZVbnpOV2pocXBabzFBK3pKOHhtN2RCZ0UxbWVoMmVocGgvU3NvYys4?=
 =?utf-8?B?UzUzNmxneUJzS3ZzRkNJOHdjMUxXT3UzM0VFT201WkczT3hEREQ2TTQ0QUVu?=
 =?utf-8?B?Si81Q3BESnFrQUlRcEkyS0xFWnUrTU9yQlh4cHdLWFovdjY3RG1BYXJOZkVt?=
 =?utf-8?B?NzhxNi8zeDMvYWYxejdTanp5enZ3SWptSWFGSDJycThWblBWZ0NlaWcxQ0Rt?=
 =?utf-8?B?ZW1peERiQ2ExTnBsTUVGZjd5MDJINjdPZFFjSVlZYXI3TDFUZlluZzN6TDdk?=
 =?utf-8?B?cFZLcnNsZ1BldGlNRnYyNXQzWEtFY2Y1ZU9Vc05rd2NGbDNBS0w2NVdYeXZj?=
 =?utf-8?B?ajVpL0FEdTZmS0EvUTBUSG50YUp4KzRQalZDRlpsVjlkbEdHUTNQVnF6Smdy?=
 =?utf-8?B?UzBkWWFXSUd6VDRKR2I1YW9GeXB3Vkt5eGswOXd5SmkzYmxkK1R0Ym1VazZB?=
 =?utf-8?B?eFM2ZVc4Z0M2VldYRFM4eWFPOGF3Vjh3UE9iRmNHUndoaTgwWDQrZVRkNnVw?=
 =?utf-8?B?cDVoWjhsNkQ3QUZUZTZEQmpGQkdzYTVJbmJFdmQ5Uk9laHFyWElEQUdEZ1pa?=
 =?utf-8?B?Y1BHbTg4YzNDVjJ5T3Zwd1IrRU0xWW9GS2kyRlYwSjNjMWprY3VIYmZRK1hH?=
 =?utf-8?B?MlgwcGxWVkxrUk1uZm9hNTU5WWNSSGI5YTUxOHpCSGE5dFowemwvRm9LK2cy?=
 =?utf-8?B?aElIa2dWZC9xb3haVnNrd0RDQ2xSR3hMOFVwTW9HRDRrSnduM0o3WXcxUUs3?=
 =?utf-8?B?RStGdlQ0TFZEcXkwZEZPc21LbTlkL043ejViRkVhSXo1UmltK29tckhJSTNW?=
 =?utf-8?B?VFpocVVuYkVYNW5BMW9KUDJnRVRBSXNVcUlSdDZ1TWdadnZiSlFOS3YrWis4?=
 =?utf-8?B?dTJSSStsbDV0elRjUVN1S1pSbnV1dVlEUmFCa2psZ00ybTMwdS9rb0lFU3BV?=
 =?utf-8?B?WGdROWcvS2d6UWpmeHVRQWVyaENuZHcvTTdDNW9wVkU3aHhyajg2OG9XclJR?=
 =?utf-8?B?d21GV09pTVBIcUxGR1Rhb3I4ZUp2d3V2V3VrYnRZck5icG1WaEwwdElDakVo?=
 =?utf-8?B?NFYvMzRDbzk5ekMrRG9xbDhnVWQ3VlVjUkRjdEdEZ3VGRDlwbGlDTXJCOU41?=
 =?utf-8?B?bnJERlpkY3dwY1FSeE82U2gvMW5MdXJ1MWhYTGV3OWc0eEdBM3AvRVFqR0tC?=
 =?utf-8?B?TFBLRzNMQzlKRjhhVEpQNGtUZk56aGowbHVQdENuSTlUSVI0cVVJUXh3OWRQ?=
 =?utf-8?B?NzFjYkRnOWNCRzVoVXdYeGdiWHpqbTc0WnZvN0lHWjgvV1VrT2V3OXZEYTl5?=
 =?utf-8?B?bnhwcUY5S2h1TlI1d0UxSVZtc0Y1TWNsOVloN0kyalVDRTFMbHpod3dRRURT?=
 =?utf-8?B?aGJyRzYwL3c3S3JVcUZzMklpd1R3WXNuaG5QeU8xTHhXQWZkdUpjZmhXblh0?=
 =?utf-8?B?ak1uZVVveVNzQVkrblVTaUgvcVBGc2dhY01ZdlE1QURUNURpaFZ6NGhaM1ZL?=
 =?utf-8?Q?kC9jnBFzLl+nA5UV/QVHkINAW6ZQa8=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB7PR08MB2987.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="utf-8"
Content-ID: <15A125CA29888E43B27187718AE7BDC8@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR08MB7727
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DU6PEPF00009526.eurprd02.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	898f20ec-cf2e-4e7a-5025-08ddaa90774b
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|1800799024|82310400026|14060799003|35042699022|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?N0ZHN1NMSk16aHFWNUtwVWFCUW5xc2loT3RrTHRVU1NVazZXWlNXOEJ0aVZY?=
 =?utf-8?B?TXdTQnNQaVFUYkx0U1c0ZlE3c3Q1T09ycDZ4NExpK2dPODc0L0d0UDRKQUls?=
 =?utf-8?B?R3A3ZjROcktjUXVYTTQwVFV5c1dWc2N2L2x1cWFhYmkrZ2tZTWdoRlQ3cHVk?=
 =?utf-8?B?OWliTkJyK3BVczhiRWxVdC9jeTBLOG5yRTU1YTNIbFg3R0hhRDkyRGdHaGx1?=
 =?utf-8?B?RW1SRG1OMHNUMkkzcUNna3Vzbm56WU5IaEdWblp0VmtNVDh2ZEF4UFZPSnJr?=
 =?utf-8?B?dmwrUnk2WmV0bzFQUENYRWdOUGxQWTd0M2duMC96cWFNMzc3UnpROGVteXht?=
 =?utf-8?B?YlFWNnpsV2RIWTNhMUdTVWNZUWNqdTVSTXJTZDVzVlp3MjNzUkYxMmUxNE5T?=
 =?utf-8?B?cExmNXMxdHlYMkhMUTdyNk9JQzZtM1VIT0pWbWx1SUlNUENHK3RXVXg3b1FS?=
 =?utf-8?B?aU84RDllLy8zeUl4dU9ycldZMEJMNjMrWjBMUlNEZVJ6eDNpSlh3YXFFclRB?=
 =?utf-8?B?V2lJWFFOc2tieE03M2FGcVkwSjRCMlFwQTVxUEFLN0R6aG5Od0MxUm8wRlNX?=
 =?utf-8?B?bG15VFNXZjEvKzJMbUFBNlZTY0NjdzdmNDc4ei9oSEJ1RkhYanJrZzRwbDJ6?=
 =?utf-8?B?RjR5d0pQY08vVnZjWWN5UXlzMXBEcjhndHErU2JzaWttTnFscXBVN2E1VUV4?=
 =?utf-8?B?WERRWFdZQnpvZHY0WXFJUThYc1FJOE51OHFhdzc1QzdlWWNIUWQ3amxXcDZ3?=
 =?utf-8?B?V1BDc0NOMGd6cU5EbEd6dGRFZ2JQNzVPeVI3MTZGdm1yK1Y4R0hUcUJPREpI?=
 =?utf-8?B?SjRaYXlmaVp2OTA0eXUzWHdJL2xpRmhPVFdCS0JoV3hFQjVJSWJWaVB1ZG5j?=
 =?utf-8?B?Z21Tbm1OQmJMeGphMjFrM3hVaXl6SEthY04zT1NEYzZ4U1VLY3NDSW5OS1Np?=
 =?utf-8?B?aGJtU1dHNzgrUnJDZXY5QkJkbHJSTFJrYzdWdXNReUQwTHgwN1Y5dGo2Tjcx?=
 =?utf-8?B?WHdSQjluN1lTM0FFSUFIWWtXOEsxWnBCWGNhQjBCZWNvQ0ZaTkhaelovNnp2?=
 =?utf-8?B?Y0Z6MnVlWGlta1paREJKeDhGYmVxZmEyWnp2NVdTTjMxZkpTaTZDNVhWbU5X?=
 =?utf-8?B?SjEvblhGKzU3L0FQZE5oNlhSVjVqZFl0eEQwWDFjN3JPSHc5aXFBY3hoREtY?=
 =?utf-8?B?SjdsRXM0dXlNdTM5eGg1MzM2UVNOQk9UaXBkU1hVQ2R5a3krMXJoRzZEcFM2?=
 =?utf-8?B?aDlRUW8xYWhqUSs5eURaaUhUSTUwWFd3R2tXYUJaZkpieDBYUmtlbXBpZEJs?=
 =?utf-8?B?bmh1Q2J5TFJvVWJjMjZRTVdvdXFyZDM0bXYzM0FmT2tYUWFsYkc4TnJHVHZn?=
 =?utf-8?B?Yk5lT0FlSFVQYnV2c2NrV2RvYzdNOXVPR0JlU2FjNGtGMjZSY0JVSi9hdWdE?=
 =?utf-8?B?cWlHUzNOYk00VXF6Nk5uTlFhR2tMalVBc1BBMGMxR3dwaVhRdEkzWVE4L3hY?=
 =?utf-8?B?UXZOQVJsYVRRZnEwdVBGc2g3SUlyV1daOUhOYmhzOFovZEJPS3JTZHVsMER4?=
 =?utf-8?B?UEYxY3R4VVhqb29QZ1ViN0Z2OWI2ZzE3T0o4WHdyaFJwaGVpa0o4RmwvQk4y?=
 =?utf-8?B?RmF2cnhldFNQQXNKZDNnUDdOZytabUYrTDNiMUJtdmhLTkJDbklEMWdvWkxP?=
 =?utf-8?B?QW5mYkpxRndFdHFDOVZoK3pHejZvV0l1ek9tOWhzajFTWDYxL3JvVnljZmZ2?=
 =?utf-8?B?ZldtZXB0Y2FwaU1xVDNaVnhRS3pxRTVSKzgwRVVFTXYyL2c3V0RpNDhKVDBF?=
 =?utf-8?B?RVNvUnpyV09NZFpWMzFOUVYyaS9nWkZGeXpsUDdmREJVVmxOcHRLTDVrbTVn?=
 =?utf-8?B?dE9TeVowdHd2bnZ1bDU0K2NCNFM2Z0lBWmluRVAyYnJFUnBpaE1DRkhRQU1C?=
 =?utf-8?B?dk13MkU4WTBTNlBjd0docEowOThhTzE4SDlLb3JCVHVPRlVzTjdMRXFobUd0?=
 =?utf-8?B?R2hKQkVoa083QTk2VHQ5dWVRb3p5NGtqR3dDU0p5aDJIbXV1eEVianNNUlR0?=
 =?utf-8?Q?1rawmz?=
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(1800799024)(82310400026)(14060799003)(35042699022)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jun 2025 15:39:56.3542
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 943f7879-8271-4ea5-8eed-08ddaa908c6f
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DU6PEPF00009526.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB6104

SGkgQXlhbiwNCg0KPiBPbiAxMSBKdW4gMjAyNSwgYXQgMTU6MzUsIEF5YW4gS3VtYXIgSGFsZGVy
IDxheWFuLmt1bWFyLmhhbGRlckBhbWQuY29tPiB3cm90ZToNCj4gDQo+IE1vZGlmeSBBcm0zMiBh
c3NlbWJseSBib290IGNvZGUgdG8gcmVzZXQgYW55IHVudXNlZCBNUFUgcmVnaW9uLCBpbml0aWFs
aXNlDQo+ICdtYXhfbXB1X3JlZ2lvbnMnIHdpdGggdGhlIG51bWJlciBvZiBzdXBwb3J0ZWQgTVBV
IHJlZ2lvbnMgYW5kIHNldC9jbGVhciB0aGUNCj4gYml0bWFwICd4ZW5fbXB1bWFwX21hc2snIHVz
ZWQgdG8gdHJhY2sgdGhlIGVuYWJsZWQgcmVnaW9ucy4NCj4gDQo+IEludHJvZHVjZSBjYWNoZS5T
IHRvIGhvbGQgYXJtMzIgY2FjaGUgcmVsYXRlZCBmdW5jdGlvbnMuDQo+IA0KPiBVc2UgdGhlIG1h
Y3JvIGRlZmluaXRpb24gZm9yICJkY2FjaGVfbGluZV9zaXplIiBmcm9tIGxpbnV4Lg0KPiANCj4g
Q2hhbmdlIHRoZSBvcmRlciBvZiByZWdpc3RlcnMgaW4gcHJlcGFyZV94ZW5fcmVnaW9uKCkgYXMg
J3N0cmQnIGluc3RydWN0aW9uDQo+IGlzIHVzZWQgdG8gc3RvcmUge3ByYmFyLCBwcmxhcn0gaW4g
YXJtMzIuIFRodXMsICdwcmJhcicgaGFzIHRvIGJlIGEgZXZlbg0KPiBudW1iZXJlZCByZWdpc3Rl
ciBhbmQgJ3BybGFyJyBpcyB0aGUgY29uc2VjdXRpdmVseSBvcmRlcmVkIHJlZ2lzdGVyLg0KPiAN
Cj4gU2lnbmVkLW9mZi1ieTogQXlhbiBLdW1hciBIYWxkZXIgPGF5YW4ua3VtYXIuaGFsZGVyQGFt
ZC5jb20+DQo+IC0tLQ0KDQpUaGlzIExHVE0sIEnigJl2ZSBhbHNvIGJ1aWx0IGZvciBBcm02NCBh
bmQgQXJtMzIuDQoNClJldmlld2VkLWJ5OiBMdWNhIEZhbmNlbGx1IDxsdWNhLmZhbmNlbGx1QGFy
bS5jb20+DQoNCg0K


From xen-devel-bounces@lists.xenproject.org Fri Jun 13 15:49:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 15:49:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014624.1392716 (Exim 4.92)
	(envelope-from )
	id 1uQ6eJ-0006dA-GI; Fri, 13 Jun 2025 15:48:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014624.1392716; Fri, 13 Jun 2025 15:48: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 1uQ6eJ-0006d3-Dg; Fri, 13 Jun 2025 15:48:59 +0000
Received: by outflank-mailman (input) for mailman id 1014624;
 Fri, 13 Jun 2025 15:48: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 1uQ6eH-0006cn-SK
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 15:48:57 +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 e9aa130b-486d-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 17:48:55 +0200 (CEST)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-ad8826c05f2so421707866b.3
 for ; Fri, 13 Jun 2025 08:48:55 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-adec8979563sm144821766b.158.2025.06.13.08.48.53
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Jun 2025 08:48:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e9aa130b-486d-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749829735; x=1750434535; 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=U18FNGQaQ2WOAoPIbpjFmVvamBgLJPNEgZzb8J9otcc=;
        b=H3Bgt2OhVepj2it+rTZTcsPGU75F7RJRiBVH1vuC3wX11byN+rfhz0JbpIoZr1wjV5
         iRY/1MwUmkKOz68tL7ybcJZrlh6rNanA4hHrMkqo6LVm7abfxfJcK2z2iv1D6IsGOvTN
         U94vBkeDtwTw+vZmrhqbQM0S2VJuva/xoPnwDaa21Ko+kV2Yz7YzTzAZhNQyY2WpkQsN
         DzBtTanEf4+pvQCuqIqRWjahrVLjcDKzxaQjtWiRDuK93z6uwN5e4c5HD/K0wuZ6lji0
         2w9/+GkaHTRB+xQYoDU/xtNvqiWvqqPcj0OgLYtZX1hDPLus9DDFYK2win7ikDCE4e8q
         FjtQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749829735; x=1750434535;
        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=U18FNGQaQ2WOAoPIbpjFmVvamBgLJPNEgZzb8J9otcc=;
        b=dKUe6CgG+Tpb5y2yjRjg9hQw4w6tKxXJJerjE6sN4/NrcjIfpCQIs7iEpjolTNV4mD
         t5rLW7gwHIO27luT5K8EBolxKm/SZgdCkuPaf9O+3lJmKHcV3E4rK76yl2I2bZpm6fXA
         NB+AjHXlVi448O58sbOhG9acjVBNKRmn0ErKP1+jfSEpIiVhVOlDqDftHbPYrsDA8QCW
         AtEHrhqzLIOvbbjPaTIppCjppgDxMY5Iv5lX8+q0vE+PsBf4mIEYUevk5ZE/7VGOFGuo
         WeFa7VbaDwumuqvr7JuCP1qP3cpHJnc0evv/uZ5A4cdZPO+jHQAuzWX5xFejhvazzlha
         7kkw==
X-Gm-Message-State: AOJu0YxRHKw1IBSsMOFeA7mzPzM3wrPGciIrdBpORZ3XhWxhjTg/4xLZ
	fhD7jGw+W+jzOVvIcXOOGow9BtUIGsyJIVvO3Zn+yytJetwCuFJjr6y7eSaw4A==
X-Gm-Gg: ASbGncs3XDuiHwYhXCetk+wQCRBT25KhxV//Q618Z0K7XwwC9n3+/vSUiYCUidRjpSp
	dTfeLPQ3WouIthAIs+1vYwmqNh8AiGtQ+0XcKaNTGRqeo1wFFTR4EUt4SH+3E9CWE2uSz2D6DF3
	mC3YI9I25l7nZxlRqcKevFhtLcaUJkxh4NSn6B4JQuCeJB5jBiQrlmZrVS6KdXnSEF9XsUpzBmN
	1TKTpkkR1cKjAA5VjTNzcUxPMLV8NCfwboTic6+dKsDCyBURWmOxl/UBDxdDSOTXtTi5BPiLDjp
	VwORV7g1gsqJDykxHcHNBg7t+am9uF49JARTEvxmKkSRb04T7hq2v3+LOriyUl3NXsnuHBEwnMN
	K1URDzM/dlvnLr9/X1A7c9UMV3owY
X-Google-Smtp-Source: AGHT+IGxz5wVTWFnAXzb/dl28GnEFScdeg3yQpCty9yM2B5NLJAZJpX/D93FqldXfK2v/H/epVLvSQ==
X-Received: by 2002:a17:907:706:b0:ad4:d00f:b4ca with SMTP id a640c23a62f3a-adec5d28463mr364608166b.50.1749829734640;
        Fri, 13 Jun 2025 08:48:54 -0700 (PDT)
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 v5 0/9] riscv: introduce basic UART support and interrupts for hypervisor mode
Date: Fri, 13 Jun 2025 17:48:39 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The patch series introduces basic UART support (in interrupt mode) and support of
interrupts for hypervisor mode.

To implement this the following has been added:
- APLIC and IMISC initialization.
- Introduce of intc_hw_operations abstraction.
- Introduce some APLIC and IMSIC operations.
- Introduce init_IRQ(), platform_get_irq() and setup_irq() functions.
- Update do_trap() handler to handle IRQ_S_EXT.
- Introduce some other functions such as: get_s_time(), smp_clear_cpu_maps(),
  ioremap().
- Enable UART. 

CI tests: https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/1868775206
---
Changes in V5:
 - Update CI tests link.
 - Mostly changes are patch-specific. Please check each patch separately.
---
Changes in V4:
 - Merged to staging:
    - xen/riscv: initialize bitmap to zero in riscv_fill_hwcap_from_isa_string()
    - xen/asm-generic: introduce asm-generic/irq-dt.h
    - xen/riscv: introduce smp_prepare_boot_cpu()
    - xen/riscv: introduce support of Svpbmt extension
    - add ioremap_*() variants using ioremap_attr()
    - xen/riscv: introduce init_IRQ()
    - xen/riscv: introduce platform_get_irq()
 - All other changes are patch-specific. Please check each patch separately.
---
Changes in V2:
 - Merged to staging:
    xen/riscv: initialize bitmap to zero in riscv_fill_hwcap_from_isa_string()
    xen/asm-generic: introduce asm-generic/irq-dt.h
 - All other changes are patch-specific. Please check each patch separately.
---

Oleksii Kurochko (9):
  xen/riscv: dt_processor_hartid() implementation
  xen/riscv: introduce register_intc_ops() and intc_hw_ops.
  xen/riscv: imsic_init() implementation
  xen/riscv: aplic_init() implementation
  xen/riscv: introduce intc_init() and helpers
  xen/riscv: implementation of aplic and imsic operations
  xen/riscv: add external interrupt handling for hypervisor mode
  xen/riscv: implement setup_irq()
  xen/riscv: add basic UART support

 xen/arch/riscv/Kconfig             |   1 +
 xen/arch/riscv/Makefile            |   1 +
 xen/arch/riscv/aplic-priv.h        |  38 +++
 xen/arch/riscv/aplic.c             | 295 +++++++++++++++++
 xen/arch/riscv/imsic.c             | 489 +++++++++++++++++++++++++++++
 xen/arch/riscv/include/asm/aplic.h |  73 +++++
 xen/arch/riscv/include/asm/imsic.h |  74 +++++
 xen/arch/riscv/include/asm/intc.h  |  32 ++
 xen/arch/riscv/include/asm/irq.h   |   8 +-
 xen/arch/riscv/include/asm/smp.h   |  17 +
 xen/arch/riscv/intc.c              |  55 ++++
 xen/arch/riscv/irq.c               | 131 ++++++++
 xen/arch/riscv/setup.c             |  14 +
 xen/arch/riscv/smpboot.c           |  77 +++++
 xen/arch/riscv/traps.c             |  19 ++
 xen/drivers/char/Kconfig           |   3 +-
 16 files changed, 1324 insertions(+), 3 deletions(-)
 create mode 100644 xen/arch/riscv/aplic-priv.h
 create mode 100644 xen/arch/riscv/imsic.c
 create mode 100644 xen/arch/riscv/include/asm/aplic.h
 create mode 100644 xen/arch/riscv/include/asm/imsic.h

-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 15:49:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 15:49:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014627.1392738 (Exim 4.92)
	(envelope-from )
	id 1uQ6eK-0006wl-Jl; Fri, 13 Jun 2025 15:49:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014627.1392738; Fri, 13 Jun 2025 15:49: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 1uQ6eK-0006vg-BT; Fri, 13 Jun 2025 15:49:00 +0000
Received: by outflank-mailman (input) for mailman id 1014627;
 Fri, 13 Jun 2025 15:48: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 1uQ6eJ-0006cn-HU
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 15:48: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 eacbe99d-486d-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 17:48:57 +0200 (CEST)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-ade58ef47c0so457361566b.1
 for ; Fri, 13 Jun 2025 08:48:57 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-adec8979563sm144821766b.158.2025.06.13.08.48.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Jun 2025 08:48:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: eacbe99d-486d-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749829737; x=1750434537; darn=lists.xenproject.org;
        h=content-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=R6A8r2DsEy0IO5GoSvvpcCWrmAlrTSeNGBRJKoWIeJE=;
        b=NebhAuNT1GH8t3ne8wvXlvR4xQfXK6UGdFjsO1Lw3xeK4SOmS09+33Y56RzDrbWaPV
         pfFA04R/LzvmvzkDW0FulT/zz0gpkHgkkK14Gwo4EjX15vPCuoCX/2lKrS268qe5lHJM
         SLpjL/YfXxKihQTsl3p/kIdMeET7F23llSRo2IdNfjn+BLHxpECPzjqI4/97A9vE1CH+
         M1PXgrWgXkmYv613oOWAPz1VPIiXSFHbAVCqJjJEvLvKa764oL9I5vzi8+IgqCjgKjMb
         azUvzCLaj7YxLy3GTyv0VlZk0Rblsi0FIrMGg89VP2bQh31kuFsBE29lTlI2rojLwDfU
         goQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749829737; x=1750434537;
        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=R6A8r2DsEy0IO5GoSvvpcCWrmAlrTSeNGBRJKoWIeJE=;
        b=Y0VCCi3BJxn0u9mJ3AqYn1bpSP6d/TBhH1uMLxi8TsnOlh2wmqi3d6l4dmZqgmSuTo
         /MN95Ba8tjqS08CUIEgzMKgPwUxKDcPqJmpYQvStiUpfXKg1i+y8uDmUh9v2FV59rirH
         EDGRY/vRMZgQAnVaEqdB2ORArkhAZmTdsM6AUABP6VLdDNMlpgqGlSpye2OH+QpqjHBE
         oMXa4A0w8d5IDqMbZbWCBVkhAkX0GKzZeipUhn1S7a92HjH8UbhFR6ArMMZVx6kQyzPU
         JSNAd499MZVKiug8fz3SpxcYb3VPHCAAvEbCky6VmQsCNEz/rlhoNWwNETXorcGH4aAL
         rGtQ==
X-Gm-Message-State: AOJu0Yz6fyxVHOZ4S0W8gHXICQ3DENcKBXDe4OnX785J+dY/L8W8jx8W
	gqtwwpnfwPLYS+nUMw8TtwgogSJJWgg1qWXV3hhY+jXemBIB010kGX73VEroXA==
X-Gm-Gg: ASbGncs1JXY4GKzauoaH+F/aotkRCi1hZLosXkpRE1RjXsgzv8/NOKKjoLi/Xe2QMYZ
	RFvLRoRcHEr4oVAJd+HfiVtYTMilKRcp5sOtVyEYGdUXZzRXopzKsHVtb6m/HTcrvNtrhbUkRtm
	/3jtKve8k0VRETFQSsux2QLGIvd1xaRVvC+lOPY2+X+1B5SxJaQCW7oAQyIuAg0crXfa+xuWDqf
	QgL9NmAmBwPDAvAICay/OaWICbyhZeyhLqnfFxmOcY5CVa+aN/rkoliT25og/GJpoMEBA+yjCzg
	rFcteyce/U6TTJ2P6Wm4QT4JfHPIqLOv12ATMD7gqqy1TTJ9tY1qGpTVIpaQ4cTDLUSzlXtLDFr
	4ZMZReXjPlKnH7vx/SOcvsjG+OXwXM2P4PKW64pU=
X-Google-Smtp-Source: AGHT+IHLGuZmkW+kSw560ggBD0NBIY1H4eKZ93nmmbFSZmm1UVBrZY9TNOMsy6/xMK/A0+7PYsLKIA==
X-Received: by 2002:a17:907:6d0a:b0:ad2:27b1:7214 with SMTP id a640c23a62f3a-adf9e1d7e73mr22733666b.17.1749829736693;
        Fri, 13 Jun 2025 08:48:56 -0700 (PDT)
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 ,
	Romain Caritey 
Subject: [PATCH v5 2/9] xen/riscv: introduce register_intc_ops() and intc_hw_ops.
Date: Fri, 13 Jun 2025 17:48:41 +0200
Message-ID: <67f202602066afc7334a15ed5cbdb96309e7d2b3.1749825782.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Introduce the intc_hw_operations structure to encapsulate interrupt
controller-specific data and operations. This structure includes:
- A pointer to interrupt controller information (`intc_info`)
- Callbacks to initialize the controller and set IRQ type/priority
- A reference to an interupt controller descriptor (`host_irq_type`)
- number of interrupt controller irqs.

Add function register_intc_ops() to mentioned above structure.

Co-developed-by: Romain Caritey 
Signed-off-by: Oleksii Kurochko 
Acked-by: Jan Beulich 
---
Changes in V5:
 - Nothing changed. Only rebase.
---
Changes in V4:
 - Add Acked-by: Jan Beulich .
---
Changes in V3:
 - Drop inclusion of xen/irq.h in asm/intc.h as forward declaration is enogh
   for types used in asm/intc.h.
 - Drop forward declaration for dt_device_node  and hw_irq_controller.
 - Declare intc_hw_ops as:
     const struct intc_hw_operations * __ro_after_init intc_hw_ops;
---
Changes in V2:
 - Declare host_irq_type member of intc_hw_operations as pointer-to-const.
 - Moved up forward declaration of irq_desc.
 - Use attribute __init for register_intc_ops().
 - Use attribute __ro_after_init for intc_hw_ops variable.
 - Update prototype of register_intc_ops() because of what mention in the
   previous point.
---
 xen/arch/riscv/include/asm/intc.h | 19 +++++++++++++++++++
 xen/arch/riscv/intc.c             |  9 +++++++++
 2 files changed, 28 insertions(+)

diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h
index 81f74736ba..434c9d0781 100644
--- a/xen/arch/riscv/include/asm/intc.h
+++ b/xen/arch/riscv/include/asm/intc.h
@@ -14,11 +14,30 @@ enum intc_version {
     INTC_APLIC,
 };
 
+struct irq_desc;
+
 struct intc_info {
     enum intc_version hw_version;
     const struct dt_device_node *node;
 };
 
+struct intc_hw_operations {
+    /* Hold intc hw information */
+    const struct intc_info *info;
+    /* Initialize the intc and the boot CPU */
+    int (*init)(void);
+
+    /* hw_irq_controller to enable/disable/eoi host irq */
+    const struct hw_interrupt_type *host_irq_type;
+
+    /* Set IRQ type */
+    void (*set_irq_type)(struct irq_desc *desc, unsigned int type);
+    /* Set IRQ priority */
+    void (*set_irq_priority)(struct irq_desc *desc, unsigned int priority);
+};
+
 void intc_preinit(void);
 
+void register_intc_ops(const struct intc_hw_operations *ops);
+
 #endif /* ASM__RISCV__INTERRUPT_CONTOLLER_H */
diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c
index 4061a3c457..1ecd651bf3 100644
--- a/xen/arch/riscv/intc.c
+++ b/xen/arch/riscv/intc.c
@@ -5,6 +5,15 @@
 #include 
 #include 
 
+#include 
+
+static const struct intc_hw_operations *__ro_after_init intc_hw_ops;
+
+void __init register_intc_ops(const struct intc_hw_operations *ops)
+{
+    intc_hw_ops = ops;
+}
+
 void __init intc_preinit(void)
 {
     if ( acpi_disabled )
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 15:49:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 15:49:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014626.1392730 (Exim 4.92)
	(envelope-from )
	id 1uQ6eK-0006n0-5h; Fri, 13 Jun 2025 15:49:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014626.1392730; Fri, 13 Jun 2025 15:49: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 1uQ6eJ-0006l7-V2; Fri, 13 Jun 2025 15:48:59 +0000
Received: by outflank-mailman (input) for mailman id 1014626;
 Fri, 13 Jun 2025 15:48: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 1uQ6eI-0006ch-O0
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 15:48:58 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20627.outbound.protection.outlook.com
 [2a01:111:f403:2413::627])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ea1b56da-486d-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 17:48:57 +0200 (CEST)
Received: from SA0PR11CA0089.namprd11.prod.outlook.com (2603:10b6:806:d2::34)
 by DS7PR12MB6262.namprd12.prod.outlook.com (2603:10b6:8:96::7) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8835.22; Fri, 13 Jun 2025 15:48:52 +0000
Received: from SA2PEPF00001506.namprd04.prod.outlook.com
 (2603:10b6:806:d2:cafe::48) by SA0PR11CA0089.outlook.office365.com
 (2603:10b6:806:d2::34) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.23 via Frontend Transport; Fri,
 13 Jun 2025 15:48:52 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SA2PEPF00001506.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.8835.15 via Frontend Transport; Fri, 13 Jun 2025 15:48:51 +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, 13 Jun
 2025 10:48:51 -0500
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; Fri, 13 Jun 2025 10:48:49 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ea1b56da-486d-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=UHE8QqG37/utkIBi5h2dNmoVDQK1juf9b9itrRCB/dSG0CDEedyUycxq2Qc18sNLvYbfRk7pBPEWO0w1uiGrA+1/L44wRVNeNLMV+3P7nVwCWysV0nEf+W53/YpLQeo8hf2nqF9zV5qBGH/klN7Za25BJ0lqDypBKw3+m59TvpGoRWrM9TAdKJGqo0zT79DzQovcMJnfvZqmGkXiSAmbfQV4sjWzXk3antB8BDt9xp6kP+VrdEVyPE1cs/BTlCUjNAYXjdd+qfXQRtZD5yGlivB3I6eaNyREI3hNKAu7jSDnUBKnMxWPHDcqH455ifxtpH9XmywP12TH1t5A9T8qJQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=9v0C6+RsIX+l4808sG+MpH7zRloooqS5T1YfefHTJCo=;
 b=FPCSPt2OxXLDxBoJ18EbZZy2ZXOGzdFHy3jzhS09Z5kZqKb4L+1en236eaDgs3QryMj5d9WH9UE1W7Efr3ADDle+akE8LNDCyWtEdZq4GBVgaubsu3/3oYR7VXaAR0ZZ5rHfBJHdDeKhob2QSOh6BU20WHgMk8uhAjbKiIMT2s3wJo9Dgtm1dOvqGBa4rvZ+7+PkwwE/HUjgcRsaO0S6Mec089vmemVZcrEaC2ldQcuWaxCS4wcJ/4QKAgDMDcZV5D58z+cviQ7mC3mmwrOwjB2mM8UP1bzfzT41kXF9fB00r/SdOJP+PLEEKQHSfesrmAzc0JPcnWqjmHgKUaEp4g==
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=9v0C6+RsIX+l4808sG+MpH7zRloooqS5T1YfefHTJCo=;
 b=ykIq4FdbVZs8108NcomX91diY4D62WsMie+PmanXmz7EOqNmsyoR21O0Xi2J+La2KPvt3wf/71M6iCxXNgCEFP/WUz/3nAy89egxigwMlHkvPA3zOeomCeuv1V9Zxvm8iafk34feAxioMjVdh7B+OZDyA4EGQPX+nNppQS68s+4=
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: Stewart Hildebrand 
To: 
CC: Rahul Singh , 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 ,
	Stewart Hildebrand 
Subject: [PATCH v8] xen/arm: pci: introduce PCI_PASSTHROUGH Kconfig option
Date: Fri, 13 Jun 2025 11:17:30 -0400
Message-ID: <20250613154847.317979-1-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB04.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SA2PEPF00001506:EE_|DS7PR12MB6262:EE_
X-MS-Office365-Filtering-Correlation-Id: ff5376b7-88b1-4d6b-ad15-08ddaa91cb7b
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|7416014|1800799024|82310400026|36860700013|13003099007;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?uAC+BVTKk//tf3FWsnvCngdHobzTluGT/AivdNgPXMG0t69izv73n6cfMk10?=
 =?us-ascii?Q?lrmYN/0/8UfAI1cha8vdzwyaLDuUVlheWueeB88zEv7BPwGpOh13SvJ4Pwms?=
 =?us-ascii?Q?ih9Ah7sOCmlRIWMTYhtMZOvhaaE62MtA0u49FgTruR5lEkP3lKpNNhy9amKE?=
 =?us-ascii?Q?A56FcQk9L9ZwCiKoDDK9N+6daK4zjeVlGlY9K4y7AstJIDcvL70cziaG/GJW?=
 =?us-ascii?Q?7IU3pV5skxt1jMP+DG67hQIl3sSYP6rNI5yhXbcWjledOYVyGrcAG0cE4Tpe?=
 =?us-ascii?Q?8eY+t3O3UFJQobwPWUV/v/0Vw/3A6dTuvMVAfE7uDWVEIKpyjJNIa/IgquxZ?=
 =?us-ascii?Q?JUWvmLOKrNU60qYx+fc452q4LCSSHRFJl7OB/+O0Fp40TDFSw3ah2xsTvy/h?=
 =?us-ascii?Q?D8Rkik08REY0WFLD8rroj70FrgfKN3dbV2uBRhUua3vOxsNcVRUBcdw1gpbq?=
 =?us-ascii?Q?eF9/mh1u3HQXEFlTxzt0vZhXyR+NMaSu11EgAbgl3gU/HHBYg4eJdSgJEug0?=
 =?us-ascii?Q?XhElzZZOX9/kWWjVpTERwBl+R/uSLXikIKyC83gJvdKLt0jPd1pZbtiOLpc4?=
 =?us-ascii?Q?llkeiPlvPjTes0mbA+8/qELaYq8ApTX/ie/2mFDO0nwYIeMCGp7DrLxbxF7Z?=
 =?us-ascii?Q?cnx/6OrRuj8ml0DIJDVsLX1iHLAspgDKM2hUQQsx38Mswaj6aTAvLJvJFngV?=
 =?us-ascii?Q?RfuGX9SCMbg8xBZRtUobRZbn3dDBbOjUI+fFUH+xQcEnySPU+6eVv51xx7ws?=
 =?us-ascii?Q?+FJWX2ZgYeEF8YHFSqnppK7A5LxlRoLDVJSiIn0+O2mp/d2/qFmGOGli+UyB?=
 =?us-ascii?Q?x6I/KHeIlkcDme2AOMAW5NGQF0ifSSRHcO2kESO/YXUx5asE0f+0OOTD4+E9?=
 =?us-ascii?Q?VBftRJTkHVoAOT7DotROEzzR9BvdhUUEFhHeFjjEZQAfngMQFlGfxcoFmG30?=
 =?us-ascii?Q?iUiOnJ1J10NFQGQ2z93T7Pgtej+4GacexARrZp3Rq8p0GqM8pMIPM2W0yYq8?=
 =?us-ascii?Q?BAY197JyfcMFz/0yPAVU4rj62gigrY/dJ9kdHLzyK//hEsPiUlWGgIqbNdye?=
 =?us-ascii?Q?GsGt8LRQUIvHdkoXKEGzm8SXLrdhIasBPkO4Xf3KDg0GNv8GBDZiLEm7nmot?=
 =?us-ascii?Q?FKaK8yuVhl6eqoDBr7Z5XkfvAgzlRbiU6GU1BB+/zUGJMrYq0SCUE87lrnJS?=
 =?us-ascii?Q?0f5g+j2M+5GcLta8vljOVYRIaGP1XD2My4i1qSls3iQa2dmAGq92eIU10wWJ?=
 =?us-ascii?Q?eHMGxM+OZcDEQdY+bs2CK1i+eIV8zbxntnqJwT8u52oXIigFJhjBw9pthvE8?=
 =?us-ascii?Q?O99r1/BQzSIhRoFxlFlR6Y7blewLU129+GEBd+/JcveSyUIjMjEsEeVmJ6om?=
 =?us-ascii?Q?Zm05Eap9yVtCXi6qdSzyGeLme9w0wo9gONI24r3STEYRMHmb6CVsIDR/fe5g?=
 =?us-ascii?Q?eMUMmmZLyV/qJqPXdzMvxEZE3wEdSYODn4cgExJGxyY4wKTCyKkxvQ=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)(7416014)(1800799024)(82310400026)(36860700013)(13003099007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jun 2025 15:48:51.6600
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ff5376b7-88b1-4d6b-ad15-08ddaa91cb7b
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:
	SA2PEPF00001506.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB6262

From: Rahul Singh 

Setting CONFIG_PCI_PASSTHROUGH=y will enable PCI passthrough on ARM,
even though the feature is not yet complete in the current upstream
codebase. The purpose of this is to make it easier to enable the
necessary configs (HAS_PCI, HAS_VPCI) for testing and development of PCI
passthrough on ARM, and to build it in CI.

Since PCI passthrough on ARM is still work in progress at this time,
make it depend on EXPERT.

Signed-off-by: Rahul Singh 
Signed-off-by: Stefano Stabellini 
Signed-off-by: Stewart Hildebrand 
---
The alpine-3.18-gcc-arm64-randconfig CI job should pick up the new
config option, but if we wanted it to be built more consistently in CI
we could add CONFIG_PCI_PASSTHROUGH=y to one of the arm jobs in
automation/gitlab-ci/build.yaml, e.g. alpine-3.18-gcc-debug-arm64.

v7->v8:
* remove select HAS_VPCI as HAS_VPCI_GUEST_SUPPORT already does so
* move select HAS_PCI to HAS_VPCI in common
* move remaining selects under config ARM_64
* add HAS_PASSTHROUGH
* remove "default n" since it is redundant

v6->v7:
* rebase
* send patch separately from series [3]
* add HAS_VPCI_GUEST_SUPPORT since it's upstream now
* drop Julien's A-b due to changes and was given several releases ago

v5->v6:
* no change

v4->v5:
* no change

v3->v4:
* no change

v2->v3:
* add Julien's A-b

v1->v2:
* drop "ARM" naming since it is already in an ARM category
* depend on EXPERT instead of UNSUPPORTED

Changes from downstream to v1:
* depends on ARM_64 (Stefano)
* Don't select HAS_VPCI_GUEST_SUPPORT since this config option is not currently
  used in the upstream codebase. This will want to be re-added here once the
  vpci series [2] is merged.
* Don't select ARM_SMMU_V3 since this option can already be selected
  independently. While PCI passthrough on ARM depends on an SMMU, it does not
  depend on a particular version or variant of an SMMU.
* Don't select HAS_ITS since this option can already be selected independently.
  HAS_ITS may want to be added here once the MSI series [1] is merged.
* Don't select LATE_HWDOM since this option is unrelated to PCI passthrough.

[1] https://gitlab.com/xen-project/people/bmarquis/xen-arm-poc/-/commits/poc/pci-passthrough
[2] https://lists.xenproject.org/archives/html/xen-devel/2023-10/msg00660.html
[3] https://lore.kernel.org/xen-devel/20231113222118.825758-1-stewart.hildebrand@amd.com/T/#t

(cherry picked from commit 9a08f1f7ce28ec619640ba9ce11018bf443e9a0e from the
 downstream branch [1])
---
 xen/arch/arm/Kconfig | 8 ++++++++
 xen/drivers/Kconfig  | 1 +
 2 files changed, 9 insertions(+)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 3f25da3ca5fd..95a2cd3d006d 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -8,6 +8,8 @@ config ARM_64
 	depends on !ARM_32
 	select 64BIT
 	select HAS_FAST_MULTIPLY
+	select HAS_VPCI_GUEST_SUPPORT if PCI_PASSTHROUGH
+	select HAS_PASSTHROUGH if PCI_PASSTHROUGH
 
 config ARM
 	def_bool y
@@ -258,6 +260,12 @@ config PARTIAL_EMULATION
 
 source "arch/arm/firmware/Kconfig"
 
+config PCI_PASSTHROUGH
+	bool "PCI passthrough" if EXPERT
+	depends on ARM_64
+	help
+	  This option enables PCI device passthrough
+
 endmenu
 
 menu "ARM errata workaround via the alternative framework"
diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig
index 20050e9bb8b3..d42314bb1904 100644
--- a/xen/drivers/Kconfig
+++ b/xen/drivers/Kconfig
@@ -14,6 +14,7 @@ source "drivers/video/Kconfig"
 
 config HAS_VPCI
 	bool
+	select HAS_PCI
 
 config HAS_VPCI_GUEST_SUPPORT
 	bool

base-commit: 229a11aac7bf52f4532ab732ed10f173bd332cd0
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 15:49:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 15:49:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014625.1392722 (Exim 4.92)
	(envelope-from )
	id 1uQ6eJ-0006fp-Rt; Fri, 13 Jun 2025 15:48:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014625.1392722; Fri, 13 Jun 2025 15:48: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 1uQ6eJ-0006fB-L9; Fri, 13 Jun 2025 15:48:59 +0000
Received: by outflank-mailman (input) for mailman id 1014625;
 Fri, 13 Jun 2025 15:48: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 1uQ6eI-0006cn-HP
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 15:48:58 +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 ea11d7e5-486d-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 17:48:56 +0200 (CEST)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-606ddbda275so4520020a12.1
 for ; Fri, 13 Jun 2025 08:48:56 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-adec8979563sm144821766b.158.2025.06.13.08.48.54
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Jun 2025 08:48:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ea11d7e5-486d-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749829736; x=1750434536; darn=lists.xenproject.org;
        h=content-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=o0jov675Ch52OlGerP1rZFs8+ZLJQY6S/aZdq380T/c=;
        b=Vcs2sGd1mUH/mGtkiCh2/Vx96CoP/TPelPcxkf6BUToVbUMdm8zm4l3gM3S+wH2XI0
         0wH1yMZa5550GYrszuBtOJfjxGkrFkNNUZGfdE+BRCzwJ2yu0yp34+Uz9Ttg44kS1qjW
         uIdpZylFLtl2+zsdlM94yiac/3l0nO6tYt9abTZXnCcu3a8knRybh51lIZnbhPlvnDo2
         p4qZkpv8QV/vVBPn39NlD2DYecP60HIl6z6nZ6ixh2QSIRnopZJL24lmQTUFUAZ2EwNk
         Rqk4ExbmesYHSEKJ/CFH/w/zMItS934L8IXRgnm+Pc52evBInxp7LN+JycIpa+TUSsXC
         rsZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749829736; x=1750434536;
        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=o0jov675Ch52OlGerP1rZFs8+ZLJQY6S/aZdq380T/c=;
        b=Q4I5EIHO25n2XKjcPUrslnwjmbu27Qf/7nA6/ws/EskgvNLLlv01IDvN5xFOgnMCvi
         u6GG6AwQUDwih8Nfaob1s4eg1/lLMotG8s0CCj6lqiUcBCUCemBabCGqwB3QFyDQs5Wl
         g+HxxiMwiUGvXH2rCmzTqWoD8xxDwZFkvrVSWJzm1SvjZciTo5N+F2IRZE+R7f6E44B9
         /yTq+Ar520B5nDk/qz5PbpGKbof0V5b7x2VSHgv1aKASpxoV9OeTqkjl4i+LONm1or9N
         M59dZWFQG4pn9AY/ghnaS7n/OsxAciOSOWH5Tclsi2rrY/361sA0fx8fPk5H5ibpHLli
         RIRQ==
X-Gm-Message-State: AOJu0Yw2GZyNfYOKjKbJKTp0KwjdkE1Xg0ALzqcZ7EF+dniVcEAjGCSm
	5bC/q5AAyEc2gSvqIf1w4zP3KpS+sGtMRHCigA4Six3r6PoK9Kfd8T1NABZNcQ==
X-Gm-Gg: ASbGncsxd4/6n9yBZHLVNB05x5RrT56Scpfj7c930PNwZa0Na/W8tA2WinRNHK8IFmG
	+x70ZuBV5FK16GunijGS2sdUs+IS3YXQOJkAhE4rF8TGZCHJLkjkcgJkugLWf1XxpDyPB9xzKD5
	2N9oTGPwetqCMVupoBFeoz17L16/NeZpW1J8wX9Qv4OLD6fnVMcSHNg3UBt7LKwDOHHIYqbVOG1
	RsCSDkvTmibw6Qse8OWbx4POa568CzQ9jvBGiUbM82Y+qCrHmaiZY0w+C49/y/KBWDVE6vkyEoy
	s3LZXJKCbkYV9xkqzqijAyiJg6iVHWIWSDPXw7zz9MAdaDvfy/PAQr4VZjf94TUR5R/CSt8eDpR
	SPxcZOTo8zLJdWXWRmQO5q+05MT29
X-Google-Smtp-Source: AGHT+IHNp2n+N2zSNwO1LYUnzX+dMDQhBgZi6TUsUHFgaKGAmAn5lMRdwaXrTiO0SGtTXsd8a+l96g==
X-Received: by 2002:a17:907:7241:b0:ad8:9428:6a27 with SMTP id a640c23a62f3a-adec5c7721dmr382814866b.50.1749829735525;
        Fri, 13 Jun 2025 08:48:55 -0700 (PDT)
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 v5 1/9] xen/riscv: dt_processor_hartid() implementation
Date: Fri, 13 Jun 2025 17:48:40 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Implements dt_processor_hartid() to get the hart ID of the given
device tree node and do some checks if CPU is available and given device
tree node has proper riscv,isa property.

As a helper function dt_get_hartid() is introduced to deal specifically
with reg propery of a CPU device node.

Signed-off-by: Oleksii Kurochko 
---
Changes in V5:
 - Rework ac overflow check in dt_get_hartid().
 - Update if check with (ac > 2) before dt_read_number() as it return uin64_t, so
   with ac > 2 it will return incorrect results. In case (ac > 2) return ~0UL,
   so this hartid will be skipped.
---
Changes in V4:
 - Sort properly inculsion of xen/types.h in riscv/smpboot.c.
 - Add overflow check of got address cell value in dt_get_hartid().
 - Use "%#lx" for loging recieved hartid from DTB.
 - s/-EINVAL/-ENODEV for recieved isa string from DTB.
---
Changes in V3:
 - s/dt_processor_cpuid/dt_processor_hartid.
 - s/dt_get_cpuid/dt_get_hartid.
 - use ~0UL in dt_get_cpuid() and in the comment above it.
 - change type for local variable ac in dt_get_cpuid() to unsigned int.
 - Update the return errors for dt_processor_cpuid().
 - Update the commit message + subject: s/cpuid/hartid.
---
Changes in V2:
 - s/of_get_cpu_hwid()/dt_get_cpu_id().
 - Update prototype of dt_get_cpu_hwid(), use pointer-to-const for cpun arg.
 - Add empty line before last return in dt_get_cpu_hwid().
 - s/riscv_of_processor_hartid/dt_processor_cpuid().
 - Use pointer-to_const for node argument of dt_processor_cpuid().
 - Use for hart_id unsigned long type as according to the spec for RV128
   mhartid register will be 128 bit long.
 - Update commit message and subject.
 - use 'CPU' instead of 'HART'.
 - Drop thread argument of dt_get_cpu_id() (of_get_cpu_hwid) as it is
   expected to be always 0 according to RISC-V's DTS binding.
---
 xen/arch/riscv/include/asm/smp.h |  4 ++
 xen/arch/riscv/smpboot.c         | 77 ++++++++++++++++++++++++++++++++
 2 files changed, 81 insertions(+)

diff --git a/xen/arch/riscv/include/asm/smp.h b/xen/arch/riscv/include/asm/smp.h
index 5e170b57b3..eb58b6576b 100644
--- a/xen/arch/riscv/include/asm/smp.h
+++ b/xen/arch/riscv/include/asm/smp.h
@@ -26,6 +26,10 @@ static inline void set_cpuid_to_hartid(unsigned long cpuid,
 
 void setup_tp(unsigned int cpuid);
 
+struct dt_device_node;
+int dt_processor_hartid(const struct dt_device_node *node,
+                        unsigned long *hartid);
+
 #endif
 
 /*
diff --git a/xen/arch/riscv/smpboot.c b/xen/arch/riscv/smpboot.c
index 0f9c2cc54a..470f6d1311 100644
--- a/xen/arch/riscv/smpboot.c
+++ b/xen/arch/riscv/smpboot.c
@@ -1,6 +1,9 @@
 #include 
+#include 
+#include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -14,3 +17,77 @@ void __init smp_prepare_boot_cpu(void)
     cpumask_set_cpu(0, &cpu_possible_map);
     cpumask_set_cpu(0, &cpu_online_map);
 }
+
+/**
+ * dt_get_hartid - Get the hartid from a CPU device node
+ *
+ * @cpun: CPU number(logical index) for which device node is required
+ *
+ * Return: The hartid for the CPU node or ~0UL if not found.
+ */
+static unsigned long dt_get_hartid(const struct dt_device_node *cpun)
+{
+    const __be32 *cell;
+    unsigned int ac;
+    uint32_t len;
+
+    ac = dt_n_addr_cells(cpun);
+    cell = dt_get_property(cpun, "reg", &len);
+
+    /*
+     * If ac > 2, the result may be truncated or meaningless unless
+     * dt_read_number() supports wider integers.
+     *
+     * TODO: drop (ac > 2) when dt_read_number() will support wider
+     *       integers.
+     */
+    if ( !cell || !ac || (ac > 2) || (ac > len / sizeof(*cell)) )
+        return ~0UL;
+
+    return dt_read_number(cell, ac);
+}
+
+/*
+ * Returns the hartid of the given device tree node, or -ENODEV if the node
+ * isn't an enabled and valid RISC-V hart node.
+ */
+int dt_processor_hartid(const struct dt_device_node *node,
+                        unsigned long *hartid)
+{
+    const char *isa;
+    int ret;
+
+    if ( !dt_device_is_compatible(node, "riscv") )
+    {
+        printk("Found incompatible CPU\n");
+        return -ENODEV;
+    }
+
+    *hartid = dt_get_hartid(node);
+    if ( *hartid == ~0UL )
+    {
+        printk("Found CPU without CPU ID\n");
+        return -ENODATA;
+    }
+
+    if ( !dt_device_is_available(node))
+    {
+        printk("CPU with hartid=%#lx is not available\n", *hartid);
+        return -ENODEV;
+    }
+
+    if ( (ret = dt_property_read_string(node, "riscv,isa", &isa)) )
+    {
+        printk("CPU with hartid=%#lx has no \"riscv,isa\" property\n", *hartid);
+        return ret;
+    }
+
+    if ( isa[0] != 'r' || isa[1] != 'v' )
+    {
+        printk("CPU with hartid=%#lx has an invalid ISA of \"%s\"\n", *hartid,
+               isa);
+        return -ENODEV;
+    }
+
+    return 0;
+}
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 15:49:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 15:49:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014628.1392757 (Exim 4.92)
	(envelope-from )
	id 1uQ6eL-0007WJ-WD; Fri, 13 Jun 2025 15:49:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014628.1392757; Fri, 13 Jun 2025 15:49:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uQ6eL-0007VW-S8; Fri, 13 Jun 2025 15:49:01 +0000
Received: by outflank-mailman (input) for mailman id 1014628;
 Fri, 13 Jun 2025 15:49: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 1uQ6eK-0006ch-Hs
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 15:49:00 +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 ebd2ca60-486d-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 17:48:59 +0200 (CEST)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-adb2bb25105so386965866b.0
 for ; Fri, 13 Jun 2025 08:48:59 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-adec8979563sm144821766b.158.2025.06.13.08.48.56
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Jun 2025 08:48:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ebd2ca60-486d-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749829739; x=1750434539; darn=lists.xenproject.org;
        h=content-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=/VTyeRYiX1XAnb1TXldryqy45I1dShILwiINfWUEwjw=;
        b=Tqh7beHqqh+HD3UO5WEo3kFDSPdHvhg3IGiChLBw5yMlnb66FEQ/j5PU20vLy/c6zw
         Ib+abtLBhIfrzqEwXFC1RIeovJvsz+uInouuH84XCNVfniDEVW+OhNBDkdUQLthcX8wq
         IywDXk7avR/ZLMDZlI8852/ytVhbvdNHcmLEl7nqeQPttWQmgB+OOxmZyxzHxosbl+8H
         IjSicg3q2rKP/cAQ9tE+dwk/DBDcSGOONRSJSlt15ehTogTPsXaDR1UJ850R2PPEqqic
         LNPDL3aWlnEhnvuK1YN2fi3wGEm1w/OfsA42I4hqYP9IZr0tVfkc10x2vl4r3JoLkO0M
         uDKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749829739; x=1750434539;
        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=/VTyeRYiX1XAnb1TXldryqy45I1dShILwiINfWUEwjw=;
        b=MHZG4Dna9XLCaORGQ2xAwwoq5ftAI4a+qtMTNj1s9nywKq1/K0m44G+MKqWSRcLQoy
         9NxMi/Rr/ae90bW/7jRaS33gpwd5PJQ3pv1U1wsndoJLj1p4v/vQoEWNYOoQ2bJNz1hG
         opAYUfZyQivHsF9pbxthKUYks2vh0Ia4WcPmwOSpj3gGVBKBCOGZ5iE1NPDBcTyeUhe0
         FXClmHINV4chcFmHWW1iMu7eemUtTl/rJYRgtF5ju5IBfS6uG0dLrvD1xnfp92n1HIlg
         h+tNUqlfBnQNtGWLe+Y1uBdo+kKASD9ZhSRtzLqONpUo0x3jPViBvwZJtCFgeC0BJLjm
         JhOQ==
X-Gm-Message-State: AOJu0Yz58+ZfbHa/N69cK9LiQaF0HW/ZnZqHNr9fRGWFRaDCQKec5jdi
	2gJgqw5Tc68bj49/A5bWgUBVHhqAEeVxT9CN/caQ+aPmWBRZyNnQzDqLMGF+uA==
X-Gm-Gg: ASbGncuNOhhXH3ym0PbnvCSfIAkhdUCFiOKwjzd3GKJVt0EKdSxGK8+T4W7N2CyOIZd
	nvzUIC2/w3GrQSWSf9+G6e+reQ+RYNjqZoXh+SHkDdDNM4SuBYvc1mTyfIrt8DZIwKJQIHE7VwU
	euwUtZPfw5ux8Ffop2x8sakW+QBD3U/Q2vMl1BJ++F0IhsBh6lAjyGRvAX2FO2lcGhn8oDabMyM
	+b3cKCzbYT5S9ePNjbHRyOQEpcfgoZkJvIQzvT31ngjEQfGGDrZxK4Pi4tQ2N/SSLnQP/+nDyHo
	68kDsHzdcKrpforMfg5rL4Wransp1w2T2fDqpExx7pzdQl9D2Ng0pBLxUp0OjrAREiwh3cT+a8L
	7bXZUmfBstaMJ+258zi7Bd8ymwp5PFXVCzxd6fVs=
X-Google-Smtp-Source: AGHT+IENIi8UeIHZvwcgJduAhJBy0le6i0KrHqUNkX1UFOCEiPLPvL+kCeSNzX62ppVGNFfyI0OBSw==
X-Received: by 2002:a17:907:9623:b0:ad5:a29c:efed with SMTP id a640c23a62f3a-adec5cb0022mr351587066b.33.1749829738153;
        Fri, 13 Jun 2025 08:48:58 -0700 (PDT)
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 ,
	Romain Caritey 
Subject: [PATCH v5 3/9] xen/riscv: imsic_init() implementation
Date: Fri, 13 Jun 2025 17:48:42 +0200
Message-ID: <0b366c5b7c8d34a98c8ec4bedf1f00b070a6fae1.1749825782.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

imsic_init() is introduced to parse device tree node, which has the following
bindings [2], and based on the parsed information update IMSIC configuration
which is stored in imsic_cfg.

The following helpers are introduces for imsic_init() usage:
  - imsic_parse_node() parses IMSIC node from DTS
  - imsic_get_parent_hartid() returns the hart ( CPU ) ID of the given device
    tree node.

This patch is based on the code from [1].

Since Microchip originally developed imsic.{c,h}, an internal discussion with
them led to the decision to use the MIT license.

[1] https://gitlab.com/xen-project/people/olkur/xen/-/commit/0b1a94f2bc3bb1a81cd26bb75f0bf578f84cb4d4
[2] https://elixir.bootlin.com/linux/v6.12/source/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml

Co-developed-by: Romain Caritey 
Signed-off-by: Oleksii Kurochko 
---
Changes in V5:
 - Drop trailing underscore for an argument of IMSIC_HART_SIZE macros.
 - Avoid wrapping format strings across lines.
 - Use 'unsigned int' for cpu variable inside imsic_init().
 - Use IMSIC_HART_SIZE() instead of open-code it.
 - s/msi[cpu].base_addr /mmios[].base_addr for the check which checks
   that MMIO addres is properly aligned.
 - s/XFREE/xvfree.
 - Drop zero-ing of  msi[cpu].{offset,base_addr} as msi[]  is zero-ed
   when is allocated and cpu id can't be found twice.
 - Add check to vefiry that CPU won't be found twice in interrupt-extended
   property of IMSIC node.
---
Changes in V4:
 - s/expected/intended in the comment above imsic_get_config().
 - [imsic_parse_node()] s/irq_num can be 0/irq_num can't be 0 in panic()
   message.
 - [imsic_parse_node()] Move "if ( irq_range[1] == IRQ_M_EXT )" after 'for loop'
   which checks interrupts-extended property.
 - [imsic_parse_node()] s/%d/%u for logging unsigned values.
 - [imsic_parse_node()] drop redundant check "(imsic_cfg.nr_ids & IMSIC_MIN_ID) != IMSIC_MIN_ID)".
 - [imsic_parse_node()] free irq_range much earlier and simlify error paths.
 - [imsic_parse_node()] s/-EINVAL/-ENOENT in the case of incorrect value for
   riscv,group-index-shift and id number.
 - [[imsic_parse_node()] s/xzalloc_array/xvzalloc_array.
 - s/xen_cpuid/cpu.
 - Identation fix.
 - use IMSIC_MMIO_PAGE_SZ instead of PAGE_SZ to check if interrupt file base
   addr is properly aligned.
 - s/ASM__RISCV__IMSIC_H/ASM_RISCV_IMSIC_H.
 - Drop *mmios from struct imsic_cfg as it is used only by imsic_init().
 - Drop cpus[] form struct imsic_mmios as it isn't really used.
 - Update declaration of hartid_to_cpuid() to return unsigned int instead of
   NR_CPUs as processor_id is in range [0, NR_CPUS) and NR_CPUs is less then
   unsigned int.
 - Calculate hart_index_bits as fls(*nr_parent_irqs - 1) to cover the case if
   nr_parent_irqs is a power of two.
 - Check an MMIO's size for IMSIC node.
---
Changes in V3:
 - Drop year in imsic.h in copyrights.
 - Correct identation in imsic_parse_node() and imsic_init()
   where for imsic_cfg.base_addr a mask is applied.
 - Use unsigned int istead of uint32_t for local variable nr_parent_irqs,
   index, nr_handlers in imsic_init().
 - Fix a leakage of ealiers successfull allocations in case if imsic_init()
   returns with an error.
 - Excess blank in printk() message: "%s: unable to parse MMIO regset %d\n".
 - Introduce hartid_to_cpuid() and use it in the check:
     if ( hardid_to_cpuid(cpuid) >= num_possible_cpus() )
   in imsic_init().
 - Use "%u" for unsigned int in printk(...).
 - Fix for loop condition: nr_mmios -> "j < nr_mmios".
 - [imsic_init()] Drop usage of j in nested loop. It is enough to have only
   index.
 - Change 0x%lx to %#lx for formatting of an address in printk().
 - [imsic_init()] Rename local variable cpuid to hartid.
 - s/imsic_get_parent_cpuid/imsic_get_parent_hartid, s/cpuid/hartid for an
   imsic_get_parent_hartid()'s argument.
 - Declare cpus member of struct imsic_mmios as cpumask_t.
 - [imsic_init()] Allocate imsic_mmios.cpus by using of alloc_cpumask_var().
 - [imsic_init()] Use cpumask_set_cpu() instead of bitmap_set().
 - [imsic_parse_node()] add check for correctness of "interrupt-extended" property.
 - [imsic_parse_node()] Use dt_node_name() or dt_full_node_name() instead of
   derefence of struct dt_node.
 - [imsic_parse_node()] Add cleanup label and update 'rc = XXX; goto cleanup'
   instead of 'return rc' as now we have to cleanup dynamically allocated irq_range
   array.
 - Add comments above imsic_init() and imsic_parse_node().
 - s/xen/arch/riscv/imsic.h/xen/arch/riscv/include/asm/imsic.h in the comment of
   imsic.h.
---
Changes in V2:
 - Drop years in copyrights.
 - s/riscv_of_processor_hartid/dt_processor_cpuid.
 - s/imsic_get_parent_hartid/imsic_get_parent_hartid.
   Rename argument hartid to cpuid.
   Make node argument const.
   Return res instead of -EINVAL for the failure case of dt_processor_cpuid().
   Drop local variable hart and use cpuid argument instead.
   Drop useless return res;
 - imsic_parse_node() changes:
   - Make node argument const.
   - Check the return value of dt_property_read_u32() directly instead of
     saving it to rc variable.
   - Update tmp usage, use short form "-=".
   - Update a check (imsic_cfg.nr_ids >= IMSIC_MAX_ID) to (imsic_cfg.nr_ids > IMSIC_MAX_ID)
     as IMSIC_MAX_ID is changed to maximum valid value, not just the firsr out-of-range.
   - Use `rc` to return value instead of explicitly use -EINVAL.
   - Use do {} while() to find number of MMIO register sets.
 - Set IMSIC_MAX_ID to 2047 (maximum possible IRQ number).
 - imsic_init() changes:
   - Use unsigned int in for's expression1.
   - s/xfree/XFEE.
   - Allocate msi and cpus array dynamically.
 - Drop forward declaration before declaration of imsic_get_config() in asm/imsic.h
   as it is not used as parameter type.
 - Align declaration of imisic_init with defintion.
 - s/harts/cpus in imisic_mmios.
   Also, change type from bool harts[NR_CPUS] to unsigned long *cpus.
 - Allocate msi member of imsic_config dynamically to save some memory.
 - Code style fixes.
 - Update the commit message.
---
 xen/arch/riscv/Makefile            |   1 +
 xen/arch/riscv/imsic.c             | 369 +++++++++++++++++++++++++++++
 xen/arch/riscv/include/asm/imsic.h |  55 +++++
 xen/arch/riscv/include/asm/smp.h   |  13 +
 4 files changed, 438 insertions(+)
 create mode 100644 xen/arch/riscv/imsic.c
 create mode 100644 xen/arch/riscv/include/asm/imsic.h

diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index a1c145c506..e2b8aa42c8 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -2,6 +2,7 @@ obj-y += aplic.o
 obj-y += cpufeature.o
 obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
 obj-y += entry.o
+obj-y += imsic.o
 obj-y += intc.o
 obj-y += irq.o
 obj-y += mm.o
diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c
new file mode 100644
index 0000000000..e7f06950de
--- /dev/null
+++ b/xen/arch/riscv/imsic.c
@@ -0,0 +1,369 @@
+/* SPDX-License-Identifier: MIT */
+
+/*
+ * xen/arch/riscv/imsic.c
+ *
+ * RISC-V Incoming MSI Controller support
+ *
+ * (c) Microchip Technology Inc.
+ * (c) Vates
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define IMSIC_HART_SIZE(guest_bits) (BIT(guest_bits, U) * IMSIC_MMIO_PAGE_SZ)
+
+struct imsic_mmios {
+    paddr_t base_addr;
+    unsigned long size;
+};
+
+static struct imsic_config imsic_cfg;
+
+/* Callers aren't intended to changed imsic_cfg so return const. */
+const struct imsic_config *imsic_get_config(void)
+{
+    return &imsic_cfg;
+}
+
+static int __init imsic_get_parent_hartid(const struct dt_device_node *node,
+                                          unsigned int index,
+                                          unsigned long *hartid)
+{
+    int res;
+    struct dt_phandle_args args;
+
+    res = dt_parse_phandle_with_args(node, "interrupts-extended",
+                                     "#interrupt-cells", index, &args);
+    if ( !res )
+        res = dt_processor_hartid(args.np->parent, hartid);
+
+    return res;
+}
+
+/*
+ * Parses IMSIC DT node.
+ *
+ * Returns 0 if initialization is successful, a negative value on failure,
+ * or IRQ_M_EXT if the IMSIC node corresponds to a machine-mode IMSIC,
+ * which should be ignored by the hypervisor.
+ */
+static int imsic_parse_node(const struct dt_device_node *node,
+                            unsigned int *nr_parent_irqs,
+                            unsigned int *nr_mmios)
+{
+    int rc;
+    unsigned int tmp;
+    paddr_t base_addr;
+    uint32_t *irq_range;
+
+    *nr_parent_irqs = dt_number_of_irq(node);
+    if ( !*nr_parent_irqs )
+        panic("%s: irq_num can't be 0. Check %s node\n", __func__,
+              dt_node_full_name(node));
+
+    irq_range = xvzalloc_array(uint32_t, *nr_parent_irqs * 2);
+    if ( !irq_range )
+        panic("%s: irq_range[] allocation failed\n", __func__);
+
+    if ( (rc = dt_property_read_u32_array(node, "interrupts-extended",
+                                    irq_range, *nr_parent_irqs * 2)) )
+        panic("%s: unable to find interrupt-extended in %s node: %d\n",
+              __func__, dt_node_full_name(node), rc);
+
+    /* Check that interrupts-extended property is well-formed. */
+    for ( unsigned int i = 2; i < (*nr_parent_irqs * 2); i += 2 )
+    {
+        if ( irq_range[i + 1] != irq_range[1] )
+            panic("%s: mode[%u] != %u\n", __func__, i + 1, irq_range[1]);
+    }
+
+    if ( irq_range[1] == IRQ_M_EXT )
+    {
+        /* Machine mode imsic node, ignore it. */
+        xfree(irq_range);
+
+        return IRQ_M_EXT;
+    }
+
+    xfree(irq_range);
+
+    if ( !dt_property_read_u32(node, "riscv,guest-index-bits",
+                               &imsic_cfg.guest_index_bits) )
+        imsic_cfg.guest_index_bits = 0;
+    tmp = BITS_PER_LONG - IMSIC_MMIO_PAGE_SHIFT;
+    if ( tmp < imsic_cfg.guest_index_bits )
+    {
+        printk(XENLOG_ERR "%s: guest index bits too big\n",
+               dt_node_name(node));
+        return -ENOENT;
+    }
+
+    /* Find number of HART index bits */
+    if ( !dt_property_read_u32(node, "riscv,hart-index-bits",
+                               &imsic_cfg.hart_index_bits) )
+        /* Assume default value */
+        imsic_cfg.hart_index_bits = fls(*nr_parent_irqs - 1);
+    tmp -= imsic_cfg.guest_index_bits;
+    if ( tmp < imsic_cfg.hart_index_bits )
+    {
+        printk(XENLOG_ERR "%s: HART index bits too big\n",
+               dt_node_name(node));
+        return -ENOENT;
+    }
+
+    /* Find number of group index bits */
+    if ( !dt_property_read_u32(node, "riscv,group-index-bits",
+                               &imsic_cfg.group_index_bits) )
+        imsic_cfg.group_index_bits = 0;
+    tmp -= imsic_cfg.hart_index_bits;
+    if ( tmp < imsic_cfg.group_index_bits )
+    {
+        printk(XENLOG_ERR "%s: group index bits too big\n",
+               dt_node_name(node));
+        return -ENOENT;
+    }
+
+    /* Find first bit position of group index */
+    tmp = IMSIC_MMIO_PAGE_SHIFT * 2;
+    if ( !dt_property_read_u32(node, "riscv,group-index-shift",
+                               &imsic_cfg.group_index_shift) )
+        imsic_cfg.group_index_shift = tmp;
+    if ( imsic_cfg.group_index_shift < tmp )
+    {
+        printk(XENLOG_ERR "%s: group index shift too small\n",
+               dt_node_name(node));
+        return -ENOENT;
+    }
+    tmp = imsic_cfg.group_index_bits + imsic_cfg.group_index_shift - 1;
+    if ( tmp >= BITS_PER_LONG )
+    {
+        printk(XENLOG_ERR "%s: group index shift too big\n",
+               dt_node_name(node));
+        return -ENOENT;
+    }
+
+    /* Find number of interrupt identities */
+    if ( !dt_property_read_u32(node, "riscv,num-ids", &imsic_cfg.nr_ids) )
+    {
+        printk(XENLOG_ERR "%s: number of interrupt identities not found\n",
+               node->name);
+        return -ENOENT;
+    }
+
+    if ( (imsic_cfg.nr_ids < IMSIC_MIN_ID) ||
+         (imsic_cfg.nr_ids > IMSIC_MAX_ID) )
+    {
+        printk(XENLOG_ERR "%s: invalid number of interrupt identities\n",
+               node->name);
+        return -ENOENT;
+    }
+
+    /* Compute base address */
+    *nr_mmios = 0;
+    rc = dt_device_get_address(node, *nr_mmios, &base_addr, NULL);
+    if ( rc )
+    {
+        printk(XENLOG_ERR "%s: first MMIO resource not found: %d\n",
+               dt_node_name(node), rc);
+        return rc;
+    }
+
+    imsic_cfg.base_addr = base_addr;
+    imsic_cfg.base_addr &= ~(BIT(imsic_cfg.guest_index_bits +
+                                 imsic_cfg.hart_index_bits +
+                                 IMSIC_MMIO_PAGE_SHIFT, UL) - 1);
+    imsic_cfg.base_addr &= ~((BIT(imsic_cfg.group_index_bits, UL) - 1) <<
+                             imsic_cfg.group_index_shift);
+
+    /* Find number of MMIO register sets */
+    do {
+        (*nr_mmios)++;
+    } while ( !dt_device_get_address(node, *nr_mmios, &base_addr, NULL) );
+
+    return 0;
+}
+
+/*
+ * Initialize the imsic_cfg structure based on the IMSIC DT node.
+ *
+ * Returns 0 if initialization is successful, a negative value on failure,
+ * or IRQ_M_EXT if the IMSIC node corresponds to a machine-mode IMSIC,
+ * which should be ignored by the hypervisor.
+ */
+int __init imsic_init(const struct dt_device_node *node)
+{
+    int rc;
+    unsigned long reloff, hartid;
+    unsigned int nr_parent_irqs, index, nr_handlers = 0;
+    paddr_t base_addr;
+    unsigned int nr_mmios;
+    struct imsic_mmios *mmios;
+    struct imsic_msi *msi = NULL;
+
+    /* Parse IMSIC node */
+    rc = imsic_parse_node(node, &nr_parent_irqs, &nr_mmios);
+    /*
+     * If machine mode imsic node => ignore it.
+     * If rc < 0 => parsing of IMSIC DT node failed.
+     */
+    if ( (rc == IRQ_M_EXT) || (rc < 0) )
+        return rc;
+
+    /* Allocate MMIO resource array */
+    mmios = xvzalloc_array(struct imsic_mmios, nr_mmios);
+    if ( !mmios )
+    {
+        rc = -ENOMEM;
+        goto imsic_init_err;
+    }
+
+    msi = xvzalloc_array(struct imsic_msi, nr_parent_irqs);
+    if ( !msi )
+    {
+        rc = -ENOMEM;
+        goto imsic_init_err;
+    }
+
+    /* Check MMIO register sets */
+    for ( unsigned int i = 0; i < nr_mmios; i++ )
+    {
+        unsigned int guest_bits = imsic_cfg.guest_index_bits;
+        unsigned long expected_mmio_size =
+            IMSIC_HART_SIZE(guest_bits) * nr_parent_irqs;
+
+        rc = dt_device_get_address(node, i, &mmios[i].base_addr,
+                                   &mmios[i].size);
+        if ( rc )
+        {
+            printk(XENLOG_ERR "%s: unable to parse MMIO regset %u\n",
+                   node->name, i);
+            goto imsic_init_err;
+        }
+
+        base_addr = mmios[i].base_addr;
+        base_addr &= ~(BIT(guest_bits +
+                           imsic_cfg.hart_index_bits +
+                           IMSIC_MMIO_PAGE_SHIFT, UL) - 1);
+        base_addr &= ~((BIT(imsic_cfg.group_index_bits, UL) - 1) <<
+                       imsic_cfg.group_index_shift);
+        if ( base_addr != imsic_cfg.base_addr )
+        {
+            rc = -EINVAL;
+            printk(XENLOG_ERR "%s: address mismatch for regset %u\n",
+                   node->name, i);
+            goto imsic_init_err;
+        }
+
+        if ( mmios[i].size != expected_mmio_size )
+        {
+            rc = -EINVAL;
+            printk(XENLOG_ERR "%s: IMSIC MMIO size is incorrect %ld, expected MMIO size: %ld\n",
+                   node->name, mmios[i].size, expected_mmio_size);
+            goto imsic_init_err;
+        }
+    }
+
+    /* Configure handlers for target CPUs */
+    for ( unsigned int i = 0; i < nr_parent_irqs; i++ )
+    {
+        unsigned int cpu;
+
+        rc = imsic_get_parent_hartid(node, i, &hartid);
+        if ( rc )
+        {
+            printk(XENLOG_WARNING "%s: cpu ID for parent irq%u not found\n",
+                   node->name, i);
+            continue;
+        }
+
+        cpu = hartid_to_cpuid(hartid);
+
+        /*
+         * If .base_addr is not 0, it indicates that the CPU has already been
+         * found.
+         * In this case, skip re-initialization to avoid duplicate setup.
+         * Also, print a warning message to signal that the DTS should be
+         * reviewed for possible duplication.
+         */
+        if ( msi[cpu].base_addr )
+        {
+            printk("%s: cpu%d is found twice in interrupts-extended prop\n",
+                  node->name, cpu);
+            continue;
+        }
+
+        if ( cpu >= num_possible_cpus() )
+        {
+            printk(XENLOG_WARNING "%s: unsupported hart ID=%#lx for parent irq%u\n",
+                   node->name, hartid, i);
+            continue;
+        }
+
+        /* Find MMIO location of MSI page */
+        reloff = i * IMSIC_HART_SIZE(imsic_cfg.guest_index_bits);
+        for ( index = 0; index < nr_mmios; index++ )
+        {
+            if ( reloff < mmios[index].size )
+                break;
+
+            /*
+             * MMIO region size may not be aligned to
+             * IMSIC_HART_SIZE(guest_index_bits) if
+             * holes are present.
+             */
+            reloff -= ROUNDUP(mmios[index].size,
+                      IMSIC_HART_SIZE(imsic_cfg.guest_index_bits));
+        }
+
+        if ( index == nr_mmios )
+        {
+            printk(XENLOG_WARNING "%s: MMIO not found for parent irq%u\n",
+                   node->name, i);
+            continue;
+        }
+
+        if ( !IS_ALIGNED(mmios[cpu].base_addr + reloff,
+                         IMSIC_MMIO_PAGE_SZ) )
+        {
+            printk(XENLOG_WARNING "%s: MMIO address %#lx is not aligned on a page\n",
+                   node->name, msi[cpu].base_addr + reloff);
+            continue;
+        }
+
+        msi[cpu].base_addr = mmios[index].base_addr;
+        msi[cpu].offset = reloff;
+
+        nr_handlers++;
+    }
+
+    if ( !nr_handlers )
+    {
+        printk(XENLOG_ERR "%s: No CPU handlers found\n", node->name);
+        rc = -ENODEV;
+        goto imsic_init_err;
+    }
+
+    imsic_cfg.msi = msi;
+
+    xvfree(mmios);
+
+    return 0;
+
+ imsic_init_err:
+    xvfree(mmios);
+    xvfree(msi);
+
+    return rc;
+}
diff --git a/xen/arch/riscv/include/asm/imsic.h b/xen/arch/riscv/include/asm/imsic.h
new file mode 100644
index 0000000000..9cd12365b1
--- /dev/null
+++ b/xen/arch/riscv/include/asm/imsic.h
@@ -0,0 +1,55 @@
+/* SPDX-License-Identifier: MIT */
+
+/*
+ * xen/arch/riscv/include/asm/imsic.h
+ *
+ * RISC-V Incoming MSI Controller support
+ *
+ * (c) Microchip Technology Inc.
+ */
+
+#ifndef ASM_RISCV_IMSIC_H
+#define ASM_RISCV_IMSIC_H
+
+#include 
+
+#define IMSIC_MMIO_PAGE_SHIFT   12
+#define IMSIC_MMIO_PAGE_SZ      (1UL << IMSIC_MMIO_PAGE_SHIFT)
+
+#define IMSIC_MIN_ID            63
+#define IMSIC_MAX_ID            2047
+
+struct imsic_msi {
+    paddr_t base_addr;
+    unsigned long offset;
+};
+
+struct imsic_config {
+    /* Base address */
+    paddr_t base_addr;
+
+    /* Bits representing Guest index, HART index, and Group index */
+    unsigned int guest_index_bits;
+    unsigned int hart_index_bits;
+    unsigned int group_index_bits;
+    unsigned int group_index_shift;
+
+    /* IMSIC phandle */
+    unsigned int phandle;
+
+    /* Number of parent irq */
+    unsigned int nr_parent_irqs;
+
+    /* Number off interrupt identities */
+    unsigned int nr_ids;
+
+    /* MSI */
+    const struct imsic_msi *msi;
+};
+
+struct dt_device_node;
+int imsic_init(const struct dt_device_node *node);
+
+const struct imsic_config *imsic_get_config(void);
+
+#endif /* ASM_RISCV_IMSIC_H */
diff --git a/xen/arch/riscv/include/asm/smp.h b/xen/arch/riscv/include/asm/smp.h
index eb58b6576b..57c8baa06c 100644
--- a/xen/arch/riscv/include/asm/smp.h
+++ b/xen/arch/riscv/include/asm/smp.h
@@ -3,6 +3,7 @@
 #define ASM__RISCV__SMP_H
 
 #include 
+#include 
 #include 
 
 #include 
@@ -18,6 +19,18 @@ static inline unsigned long cpuid_to_hartid(unsigned long cpuid)
     return pcpu_info[cpuid].hart_id;
 }
 
+static inline unsigned int hartid_to_cpuid(unsigned long hartid)
+{
+    for ( unsigned int cpuid = 0; cpuid < ARRAY_SIZE(pcpu_info); cpuid++ )
+    {
+        if ( hartid == cpuid_to_hartid(cpuid) )
+            return cpuid;
+    }
+
+    /* hartid isn't valid for some reason */
+    return NR_CPUS;
+}
+
 static inline void set_cpuid_to_hartid(unsigned long cpuid,
                                        unsigned long hartid)
 {
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 15:49:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 15:49:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014629.1392767 (Exim 4.92)
	(envelope-from )
	id 1uQ6eO-0007oW-7C; Fri, 13 Jun 2025 15:49:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014629.1392767; Fri, 13 Jun 2025 15:49:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uQ6eO-0007oL-2h; Fri, 13 Jun 2025 15:49:04 +0000
Received: by outflank-mailman (input) for mailman id 1014629;
 Fri, 13 Jun 2025 15:49: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 1uQ6eM-0006ch-CV
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 15:49:02 +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 ecfe9b31-486d-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 17:49:01 +0200 (CEST)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-6086502e750so4366643a12.3
 for ; Fri, 13 Jun 2025 08:49:01 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-adec8979563sm144821766b.158.2025.06.13.08.48.58
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Jun 2025 08:48:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ecfe9b31-486d-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749829741; x=1750434541; darn=lists.xenproject.org;
        h=content-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=YHqoFErtd8yGkd2BNMISXV9hdJ8jkEDcMnHOQfMkP38=;
        b=ValZsef9zYQ8EFFrdUBB3BK4DTEV1Csx211FpR3iTKnXk2g1hnfuaq7qLb29BkPxM+
         yQf/5I0BciM039Ju9Sj0UpimKsmumgtjtzMnncxWVPeNr2yJiPhtIAUnXoxcYedkEFqq
         NmTNhfdPfEshaiSxmKLIBRhh0Lhf68lbatWrUGf33Ha1zt3OCPLY+TWJS8YDZEAUm0gO
         lvb6JixYAKT8uG/C9U5rMf/1xvHiOxsyZkFMCfQEcMfilrUMIN1CHKv5LEb/8SEBTh8C
         Wyie7/LGE3/4pjD7q07NeKI6uwZ9U6nAbk5hZMyf7niskKAhN5J/QkUh/rrg2itE7AwU
         zDtg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749829741; x=1750434541;
        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=YHqoFErtd8yGkd2BNMISXV9hdJ8jkEDcMnHOQfMkP38=;
        b=Jb7gjSxwCuf+cwIudaVYdfu5wX2gF1gqgzOXRo3czqa7FjdIQOlNGoI1Z0Rushzbl8
         jyiwyDiX38zfC8JMeCwQAIOcGNmHuKUvzIGveh8zGVGhOhV0QRZTOADVsErf46KiaH+M
         wH52fiVi80DpSITkptxXroBAzec8yKGpFPnUHsAD1e3z2sJsUKbufDDCGbopVhvh/Bps
         CLtwg0uulqm/vVzE8rx7fuDoGzT5PuSETGSXYAEftRqRYwqysv8KaCATPugWvkZi0Mw/
         yYFHCJeZ5CivIfDQnf2wJtG5qwClo89G9cy/xwdWpXhPMZIBL9FbYzx7j2xeTloYpCh+
         r9vg==
X-Gm-Message-State: AOJu0YyBQ9eevJjWFuq+EECzj4ZvKYhubq5/pkYbQg4TIIgeobPWQCHd
	j3wD9KqPhPRSixljIIQGXnTiIEZD6IFeGQjsdLC527O/tKlp7a/dUq8LajQ2ZQ==
X-Gm-Gg: ASbGnctwDHihdRHiF1NnWbW+CC0y/IMHpiGt+sF455yDDoAmiwEyZpeNYvK0tf5yiwy
	wxKAwdT6jiYnodV7BE3UJIZakyA5iThehR/dKOq5/7kkMiZrvJw1NPDFz0lOwNHSTdO1cs3fEc3
	9sCLnh3urnFOBHuxY7gWSviQ596zhIBRggrI5ol5KIxkD/kRAGe9Jg3aJBrtdNi3T3hAQRSJKtS
	ewtgJ+Nf3eqm/3W1hZTNbb3+QgxVsYuDNLKjHR3pezH+VDbVTbVKH5NAKVUhYjp62O35PTrz55t
	/G2M17JIAnCQDVPcRMcmkpT6IIF4Uq63e3J/nE6jpXsmJ+D03mdyg9CJKejB93bUbRuymIKYYBB
	YMaQpfwLJvnWAmO0P0gBy8bxrDvva
X-Google-Smtp-Source: AGHT+IGCcBBwT8scCSkun7lleqBfm9R+4Munlim3AIUheOwZ0XdMjQiskEEtE7O8rPLmyuXV4BAhqw==
X-Received: by 2002:a17:907:7fa6:b0:ade:5ba:40e1 with SMTP id a640c23a62f3a-adec4ed1766mr357284666b.0.1749829740130;
        Fri, 13 Jun 2025 08:49:00 -0700 (PDT)
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 ,
	Romain Caritey 
Subject: [PATCH v5 4/9] xen/riscv: aplic_init() implementation
Date: Fri, 13 Jun 2025 17:48:43 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

aplic_init() function does the following few things:
 - checks that IMSIC in device tree node  ( by checking msi-parent property
   in APLIC node ) is present as current one implmenetaion of AIA is
   supported only MSI method.
 - initialize IMSIC based on IMSIC device tree node
 - Read value of APLIC's paddr start/end and size.
 - Map aplic.regs
 - Setup APLIC initial state interrupts (disable all interrupts, set
   interrupt type and default priority, confgifure APLIC domaincfg) by
   calling aplic_init_hw_interrutps().

aplic_init() is based on the code from [1] and [2].

Since Microchip originally developed aplic.c, an internal discussion with
them led to the decision to use the MIT license.

[1] https://gitlab.com/xen-project/people/olkur/xen/-/commit/7cfb4bd4748ca268142497ac5c327d2766fb342d
[2] https://gitlab.com/xen-project/people/olkur/xen/-/commit/392a531bfad39bf4656ce8128e004b241b8b3f3e

Co-developed-by: Romain Caritey 
Signed-off-by: Oleksii Kurochko 
---
Changes in V5:
 - Fix a typo in panic massege in aplic_init(): s/Failded/Failed.
 - Correct size check: (!IS_ALIGNED(size, KB(4)) && (size < KB(16))) ->
   (!IS_ALIGNED(size, KB(4)) || (size < KB(16))).
 - Avoid wrapping format strings across lines.
---
Changes in V4:
 - s/ASM__RISCV_PRIV_APLIC_H/ASM_RISCV_PRIV_APLIC_H
 - Drop APLIC_MAX_NUM_WIRED_IRQ_SOURCES and use ARRAY_SIZE(aplic.regs->sourcecfg).
 - Don't use 'else if' for the case when the earlier if() ends in an
   unconditional control flow change.
 - Use const for aplic_ops and drop __ro_after_init.
 - Add checks of APLIC's memory-mapped control region physical address and
   size.
 - s/ASM__RISCV__APLIC_H/ASM_RISCV_APLIC_H.
 - Use unsigned int in defintion of APLIC_DOMAINCFG_IE and APLIC_DOMAINCFG_DM.
 - set aplic_info.num_irqs to ARRAY_SIZE(aplic.regs->sourcecfg) if DT node
   provides too much.
 - Add some constraints for aplic.paddr_start and aplic.size.
---
Changes in V3:
 - Correct the comment on top of aplic-priv.h:
     xen/arch/riscv/aplic.h -> .../aplic-priv.h
 - Add __iomem for regs member of aplic_priv structure.
 - [aplic_init_hw_interrupts] Use ~0U instead of -1U in aplic_init_hw_interrupts()
   to disable all interrupts.
 - [aplic_init_hw_interrupts] Start 'i' (for-cycle variable) from 0, not from 1.
 - [aplic_init()] Declare imsic_node as pointer-to-const.
 - Use decimal for arrays in struct aplic_regs.
 - [aplic_init()] Check that aplic_info.num_irqs are less then 1023.
 - [aplic_init()] Drop out check of IMSIC's node interrupt-extended property
   from aplic_init().
---
Changes in V2:
 - use __ro_after_init for aplic_ops.
 - s/nr_irqs/num_irqs.
 - s/dt_processor_hartid/dt_processor_cpuid.
 - Drop confusing comment in aplic_init_hw_interrupts().
 - Code style fixes.
 - Drop years for Copyright.
 - Revert changes which drop nr_irq define from asm/irq.h,
   it shouldn't be, at least, part of this patch.
 - Drop paddr_enf from struct aplic_regs. It is enough to have pair
   (paddr_start, size).
 - Make  struct aplic_priv of asm/aplic.h private by moving it to
   riscv/aplic-priv.h.
 - Add the comment above the initialization of APLIC's target register.
 - use writel() to access APLIC's registers.
 - use 'unsinged int' for local variable i in aplic_init_hw_interrupts.
 - Add the check that all modes in interrupts-extended property of
   imsic node are equal. And drop rc != EOVERFLOW when interrupts-extended
   property is read.
 - Add cf_check to aplic_init().
 - Fix a cycle of clrie register initialization in aplic_init_hw_interrupts().
   Previous implementation leads to out-of-boundary.
 - Declare member num_irqs in struct intc_info as it is used by APLIC code.
---
 xen/arch/riscv/aplic-priv.h        |  34 ++++++++++
 xen/arch/riscv/aplic.c             | 103 +++++++++++++++++++++++++++++
 xen/arch/riscv/include/asm/aplic.h |  64 ++++++++++++++++++
 xen/arch/riscv/include/asm/intc.h  |   3 +
 4 files changed, 204 insertions(+)
 create mode 100644 xen/arch/riscv/aplic-priv.h
 create mode 100644 xen/arch/riscv/include/asm/aplic.h

diff --git a/xen/arch/riscv/aplic-priv.h b/xen/arch/riscv/aplic-priv.h
new file mode 100644
index 0000000000..7ed1ab8f4b
--- /dev/null
+++ b/xen/arch/riscv/aplic-priv.h
@@ -0,0 +1,34 @@
+/* SPDX-License-Identifier: MIT */
+
+/*
+ * xen/arch/riscv/aplic-priv.h
+ *
+ * Private part of aplic.h header.
+ *
+ * RISC-V Advanced Platform-Level Interrupt Controller support
+ *
+ * Copyright (c) Microchip.
+ * Copyright (c) Vates.
+ */
+
+#ifndef ASM_RISCV_PRIV_APLIC_H
+#define ASM_RISCV_PRIV_APLIC_H
+
+#include 
+
+#include 
+#include 
+
+struct aplic_priv {
+    /* base physical address and size */
+    paddr_t paddr_start;
+    size_t  size;
+
+    /* registers */
+    volatile struct aplic_regs __iomem *regs;
+
+    /* imsic configuration */
+    const struct imsic_config *imsic_cfg;
+};
+
+#endif /* ASM_RISCV_PRIV_APLIC_H */
diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c
index 10ae81f7ac..cc3e299212 100644
--- a/xen/arch/riscv/aplic.c
+++ b/xen/arch/riscv/aplic.c
@@ -9,19 +9,118 @@
  * Copyright (c) 2024-2025 Vates
  */
 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
+
+#include "aplic-priv.h"
 
 #include 
+#include 
 #include 
+#include 
+
+#define APLIC_DEFAULT_PRIORITY  1
+
+static struct aplic_priv aplic;
 
 static struct intc_info __ro_after_init aplic_info = {
     .hw_version = INTC_APLIC,
 };
 
+static void __init aplic_init_hw_interrupts(void)
+{
+    unsigned int i;
+
+    /* Disable all interrupts */
+    for ( i = 0; i < ARRAY_SIZE(aplic.regs->clrie); i++)
+        writel(~0U, &aplic.regs->clrie[i]);
+
+    /* Set interrupt type and default priority for all interrupts */
+    for ( i = 0; i < aplic_info.num_irqs; i++ )
+    {
+        writel(0, &aplic.regs->sourcecfg[i]);
+        /*
+         * Low bits of target register contains Interrupt Priority bits which
+         * can't be zero according to AIA spec.
+         * Thereby they are initialized to APLIC_DEFAULT_PRIORITY.
+         */
+        writel(APLIC_DEFAULT_PRIORITY, &aplic.regs->target[i]);
+    }
+
+    writel(APLIC_DOMAINCFG_IE | APLIC_DOMAINCFG_DM, &aplic.regs->domaincfg);
+}
+
+static int __init cf_check aplic_init(void)
+{
+    dt_phandle imsic_phandle;
+    const __be32 *prop;
+    uint64_t size, paddr;
+    const struct dt_device_node *imsic_node;
+    const struct dt_device_node *node = aplic_info.node;
+    int rc;
+
+    /* Check for associated imsic node */
+    if ( !dt_property_read_u32(node, "msi-parent", &imsic_phandle) )
+        panic("%s: IDC mode not supported\n", node->full_name);
+
+    imsic_node = dt_find_node_by_phandle(imsic_phandle);
+    if ( !imsic_node )
+        panic("%s: unable to find IMSIC node\n", node->full_name);
+
+    rc = imsic_init(imsic_node);
+    if ( rc == IRQ_M_EXT )
+        /* Machine mode imsic node, ignore this aplic node */
+        return 0;
+
+    if ( rc )
+        panic("%s: Failed to initialize IMSIC\n", node->full_name);
+
+    /* Find out number of interrupt sources */
+    if ( !dt_property_read_u32(node, "riscv,num-sources",
+                               &aplic_info.num_irqs) )
+        panic("%s: failed to get number of interrupt sources\n",
+              node->full_name);
+
+    if ( aplic_info.num_irqs > ARRAY_SIZE(aplic.regs->sourcecfg) )
+        aplic_info.num_irqs = ARRAY_SIZE(aplic.regs->sourcecfg);
+
+    prop = dt_get_property(node, "reg", NULL);
+    dt_get_range(&prop, node, &paddr, &size);
+    if ( !paddr )
+        panic("%s: first MMIO resource not found\n", node->full_name);
+
+    if ( !IS_ALIGNED(paddr, KB(4)) )
+        panic("%s: paddr of memory-mapped control region should be 4Kb aligned:%#lx\n",
+              __func__, paddr);
+
+    if ( !IS_ALIGNED(size, KB(4)) || (size < KB(16)) )
+        panic("%s: memory-mapped control region should be a multiple of 4 KiB in size and the smallest valid control is 16Kb: %#lx\n",
+              __func__, size);
+
+    aplic.paddr_start = paddr;
+    aplic.size = size;
+
+    aplic.regs = ioremap(paddr, size);
+    if ( !aplic.regs )
+        panic("%s: unable to map\n", node->full_name);
+
+    /* Setup initial state APLIC interrupts */
+    aplic_init_hw_interrupts();
+
+    return 0;
+}
+
+static const struct intc_hw_operations aplic_ops = {
+    .info                = &aplic_info,
+    .init                = aplic_init,
+};
+
 static int cf_check aplic_irq_xlate(const uint32_t *intspec,
                                     unsigned int intsize,
                                     unsigned int *out_hwirq,
@@ -53,8 +152,12 @@ static int __init aplic_preinit(struct dt_device_node *node, const void *dat)
 
     aplic_info.node = node;
 
+    aplic.imsic_cfg = imsic_get_config();
+
     dt_irq_xlate = aplic_irq_xlate;
 
+    register_intc_ops(&aplic_ops);
+
     return 0;
 }
 
diff --git a/xen/arch/riscv/include/asm/aplic.h b/xen/arch/riscv/include/asm/aplic.h
new file mode 100644
index 0000000000..fea95d4369
--- /dev/null
+++ b/xen/arch/riscv/include/asm/aplic.h
@@ -0,0 +1,64 @@
+/* SPDX-License-Identifier: MIT */
+
+/*
+ * xen/arch/riscv/asm/include/aplic.h
+ *
+ * RISC-V Advanced Platform-Level Interrupt Controller support
+ *
+ * Copyright (c) Microchip.
+ */
+
+#ifndef ASM_RISCV_APLIC_H
+#define ASM_RISCV_APLIC_H
+
+#include 
+
+#include 
+
+#define APLIC_DOMAINCFG_IE      BIT(8, U)
+#define APLIC_DOMAINCFG_DM      BIT(2, U)
+
+struct aplic_regs {
+    uint32_t domaincfg;
+    uint32_t sourcecfg[1023];
+    uint8_t _reserved1[3008];
+
+    uint32_t mmsiaddrcfg;
+    uint32_t mmsiaddrcfgh;
+    uint32_t smsiaddrcfg;
+    uint32_t smsiaddrcfgh;
+    uint8_t _reserved2[48];
+
+    uint32_t setip[32];
+    uint8_t _reserved3[92];
+
+    uint32_t setipnum;
+    uint8_t _reserved4[32];
+
+    uint32_t in_clrip[32];
+    uint8_t _reserved5[92];
+
+    uint32_t clripnum;
+    uint8_t _reserved6[32];
+
+    uint32_t setie[32];
+    uint8_t _reserved7[92];
+
+    uint32_t setienum;
+    uint8_t _reserved8[32];
+
+    uint32_t clrie[32];
+    uint8_t _reserved9[92];
+
+    uint32_t clrienum;
+    uint8_t _reserved10[32];
+
+    uint32_t setipnum_le;
+    uint32_t setipnum_be;
+    uint8_t _reserved11[4088];
+
+    uint32_t genmsi;
+    uint32_t target[1023];
+};
+
+#endif /* ASM_RISCV_APLIC_H */
diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h
index 434c9d0781..3c4b211f58 100644
--- a/xen/arch/riscv/include/asm/intc.h
+++ b/xen/arch/riscv/include/asm/intc.h
@@ -19,6 +19,9 @@ struct irq_desc;
 struct intc_info {
     enum intc_version hw_version;
     const struct dt_device_node *node;
+
+    /* number of irqs */
+    unsigned int num_irqs;
 };
 
 struct intc_hw_operations {
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 15:49:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 15:49:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014630.1392775 (Exim 4.92)
	(envelope-from )
	id 1uQ6eO-0007xI-Un; Fri, 13 Jun 2025 15:49:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014630.1392775; Fri, 13 Jun 2025 15:49:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uQ6eO-0007wc-MR; Fri, 13 Jun 2025 15:49:04 +0000
Received: by outflank-mailman (input) for mailman id 1014630;
 Fri, 13 Jun 2025 15:49: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 1uQ6eN-0006ch-C6
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 15:49:03 +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 edc1ef0b-486d-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 17:49:02 +0200 (CEST)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-ade48b24c97so337151766b.2
 for ; Fri, 13 Jun 2025 08:49:02 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-adec8979563sm144821766b.158.2025.06.13.08.49.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Jun 2025 08:49:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: edc1ef0b-486d-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749829742; x=1750434542; darn=lists.xenproject.org;
        h=content-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=kWLYSodiRsm7mDCKtezKwf+cxQyrLPn4QIQNMit6hRc=;
        b=boWo+MNP694kc4ZoJOqP0h//3WtVFQtD7ESqIvtJqnAzmWh6F8YfybhtzQ9i2o97g5
         ZxXXdErgHLLcGh1hiz3RE4+viKi6q5/pyicS3HMFJXFGje9xsWKzVay8HWm+G9kCX0TV
         TxB/dNV6xGfxsH7I6fkMmIQgf1CFeFnfjcewkRQmILFozDmgbctBXPJsdg9FBwVjciGy
         hmc1BQvSnQJLPoofYLAKF+gkbuIPs//LXFBZelcHZrGQ670WDZYptNC/sLEP75W3qfnh
         ccCviLzD82qDoAkyjLOfAxF/+zXv67hRWby4COhC3ykx8xSmRhwS93KeACJnEBrVdi1W
         xlIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749829742; x=1750434542;
        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=kWLYSodiRsm7mDCKtezKwf+cxQyrLPn4QIQNMit6hRc=;
        b=NtjstrOUYmsRy2jsxlPXjOeC4WuC0WqHuWCsf2iAz/IdXt4xLSpfPvHDJYb1YqDOOs
         MsMURIZ+w1RseCFl2gK9wpcpDfHT360Zn12slbJD46/srnhhU0xlSd54esNCNZp239We
         a1/6uEJgwxnCvbjVDsw9nCRJHHNBGXix8RoDzqiHBwa3qHJMuVf8Ql8sAg6TunIfZqxs
         tWrxZASp7K6kbeudcWkTX6ex2VHeBVf0z+MiNJhZgQLSB2dZSy+d8jp4OF5ubmFoeIT4
         3MvAFxjcZqoR8P+W9UZKc+q5HjPlcB1751C4ijqZX0ZApIE+eGOGSbZlCRy5aBh8DFK1
         yPIw==
X-Gm-Message-State: AOJu0YxKojEpJJhfvKrjAhhXkPts6S/Z4HxE02cE6tpJ5Zj4v+xAWENW
	6ifMTdp3paWG232EH1crYeFd91T1XdhuLkwINdiIJ+3KzXg4YgoK2lEZ/c0wRw==
X-Gm-Gg: ASbGncspQTgHatMw3CwGDQhUtZiz/6JHU/AgIHgsm9x8zWsZrGEMYlOoMD0yZXzLhHT
	KVi9E90na5RzTjLQG6C67wYInHLlim2ej1AqFqa7TdfrrZ5kfBHjAnrT9Ag4NyvY2ydN6yNw/SE
	X5LfA6JHmBAS+9PAq/GqNAwJSuxPrzi4hWix3dlVR8fuFWlmWbLwxODPr3fFjwDNOM7CfnQXc9u
	CqUbc5+CZJ51UrFGjoT4dZEK0ZtapBIfboX+i0yFaiyqvKtgNg8rkfoOBWpP8pyYJxdO9vh5lkW
	xwHQTGAlVEzMz+3b0FOUHtNKMOYl0UbT8k4ksTy0+WpNAuDAzZ/oFoDZkYGOmM7AAShNHcViDIJ
	AaNmRk3XFm6gs+Tp9hzNDuNzObQwW
X-Google-Smtp-Source: AGHT+IFwuzRAO2aMwCpzgznPpw9bLv4IXoL0CdMKxiA7lbCL/uvyHdV1Z4CzCzATm/7hUMWYyh0qBA==
X-Received: by 2002:a17:907:2d08:b0:ade:9e62:5fa8 with SMTP id a640c23a62f3a-adec56ad7c9mr349658966b.30.1749829741790;
        Fri, 13 Jun 2025 08:49:01 -0700 (PDT)
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 ,
	Romain Caritey 
Subject: [PATCH v5 5/9] xen/riscv: introduce intc_init() and helpers
Date: Fri, 13 Jun 2025 17:48:44 +0200
Message-ID: <90dea26b25c0934697885da2703842106b6aebaa.1749825782.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Introduce intc_init() to initialize the interrupt controller using the
registered hardware ops.
Also add intc_route_irq_to_xen() to route IRQs to Xen, with support for
setting IRQ type and priority via new internal helpers intc_set_irq_type()
and intc_set_irq_priority().

Call intc_init() to do basic initialization steps for APLIC and IMSIC.

Co-developed-by: Romain Caritey 
Signed-off-by: Oleksii Kurochko 
Acked-by: Jan Beulich 
---
Changes in V5:
 - Nothing changed. Only rebase.
---
Changes in V4:
 - Add Acked-by: Jan Beulich .
---
Changes in V3:
 - Drop ASSERIT(intc_hw_ops) in intc_init().
 - Drop ASSERT(intc_hw_ops) in intc_set_irq_type() and
   intc_set_irq_priority() as intc_init() will be called first and so if it
   won't crash, then intc_hw_ops is registered.
---
Changes in V2:
 - This patch was part of "xen/riscv: Introduce intc_hw_operations abstraction"
   and splitted to have ability to merge patch "xen/riscv: initialize interrupt controller"
   to the current patch (where intc_init() call is actually introduced).
 - Add checks of that callbacks aren't set to NULL in intc_set_irq_priority()
   and intc_set_irq_type().
 - add num_irqs member to struct intc_info as it is used now in
   intc_route_irq_to_xen().
 - Add ASSERT(spin_is_locked(&desc->lock)) to intc_set_irq_priority() in
   the case this function will be called outside intc_route_irq_to_xen().
---
 xen/arch/riscv/include/asm/intc.h |  4 +++
 xen/arch/riscv/intc.c             | 41 +++++++++++++++++++++++++++++++
 xen/arch/riscv/setup.c            |  2 ++
 3 files changed, 47 insertions(+)

diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h
index 3c4b211f58..a11b7aa55e 100644
--- a/xen/arch/riscv/include/asm/intc.h
+++ b/xen/arch/riscv/include/asm/intc.h
@@ -43,4 +43,8 @@ void intc_preinit(void);
 
 void register_intc_ops(const struct intc_hw_operations *ops);
 
+void intc_init(void);
+
+void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority);
+
 #endif /* ASM__RISCV__INTERRUPT_CONTOLLER_H */
diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c
index 1ecd651bf3..f2823267a9 100644
--- a/xen/arch/riscv/intc.c
+++ b/xen/arch/riscv/intc.c
@@ -1,9 +1,12 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
+#include 
 
 #include 
 
@@ -21,3 +24,41 @@ void __init intc_preinit(void)
     else
         panic("ACPI interrupt controller preinit() isn't implemented\n");
 }
+
+void __init intc_init(void)
+{
+    if ( intc_hw_ops->init() )
+        panic("Failed to initialize the interrupt controller drivers\n");
+}
+
+/* desc->irq needs to be disabled before calling this function */
+static void intc_set_irq_type(struct irq_desc *desc, unsigned int type)
+{
+    ASSERT(desc->status & IRQ_DISABLED);
+    ASSERT(spin_is_locked(&desc->lock));
+    ASSERT(type != IRQ_TYPE_INVALID);
+
+    if ( intc_hw_ops->set_irq_type )
+        intc_hw_ops->set_irq_type(desc, type);
+}
+
+static void intc_set_irq_priority(struct irq_desc *desc, unsigned int priority)
+{
+    ASSERT(spin_is_locked(&desc->lock));
+
+    if ( intc_hw_ops->set_irq_priority )
+        intc_hw_ops->set_irq_priority(desc, priority);
+}
+
+void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority)
+{
+    ASSERT(desc->status & IRQ_DISABLED);
+    ASSERT(spin_is_locked(&desc->lock));
+    /* Can't route interrupts that don't exist */
+    ASSERT(intc_hw_ops && desc->irq < intc_hw_ops->info->num_irqs);
+
+    desc->handler = intc_hw_ops->host_irq_type;
+
+    intc_set_irq_type(desc, desc->arch.type);
+    intc_set_irq_priority(desc, priority);
+}
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 8bcd19218d..0e7398159c 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -134,6 +134,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
 
     intc_preinit();
 
+    intc_init();
+
     printk("All set up\n");
 
     machine_halt();
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 15:49:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 15:49:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014631.1392787 (Exim 4.92)
	(envelope-from )
	id 1uQ6eS-0008Pi-5y; Fri, 13 Jun 2025 15:49:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014631.1392787; Fri, 13 Jun 2025 15:49: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 1uQ6eS-0008PR-1Y; Fri, 13 Jun 2025 15:49:08 +0000
Received: by outflank-mailman (input) for mailman id 1014631;
 Fri, 13 Jun 2025 15:49: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 1uQ6eQ-0006cn-Mp
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 15:49:06 +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 eeedc302-486d-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 17:49:04 +0200 (CEST)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-60179d8e65fso4105643a12.0
 for ; Fri, 13 Jun 2025 08:49:04 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-adec8979563sm144821766b.158.2025.06.13.08.49.02
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Jun 2025 08:49:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: eeedc302-486d-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749829744; x=1750434544; darn=lists.xenproject.org;
        h=content-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=d/DsIO3qh5Ntrrl6zJ6YNrhw7LFSUgr7qK7gHk29IDc=;
        b=VPp97P1smG4CK7K+VOcY6AupL664WNnn37ifzRD9lhnUSYtXcmhrw/T1QutJ8tQ+C6
         Z1IuWuBvv1++oYNoTKcrOt14xT1bgKFo2ZyY2Wh+8IeBohPoUuQY6jBAChNIP39dgMOP
         dtMyabKPs3DDZ7pnzQup3KOl0Q8IuXLS0YfSRNLWDdG14/pIcyoNbTzmzMHjJNaq2tLM
         KUaefwL88J1pFesCrG3gd+ZXNwCS6PJBPsSGVAqMUtjDRQ8jM6LbkAcOxGN5aH+yQkv3
         uTu26WIW+rIsq3jPAYhluYw3H8gp8YXJLDfRC8hPWKmBuhTKwMoLhZbK9LgESe0E5xUY
         wKJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749829744; x=1750434544;
        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=d/DsIO3qh5Ntrrl6zJ6YNrhw7LFSUgr7qK7gHk29IDc=;
        b=iJ24cnX6Nqf0JqJjCGbwyVhRJw0FGnzaYGaDtUzHUKxvyTuV/bqLrd/2gA6yEJbmok
         iIJjXf5hjbsY3CvP67wqcxsPJbFxi0XR7fOVXX8/Vj/WAi3oOzDxcCuqz9g6CGg9SQiX
         fNyLkMbOaR3jxDTu6v/9Js3oVbZCmeLEjXWFSoTuuPFyScgBla27urPzCpjWWIMNoq6L
         90ER+envSM3zfjvL/a9Bf9gaHOuUmyPueshrUVD75fcxBWu1Tr6rSVo3xFdbiYP3AkaX
         c7rysHCPxTKerMmWWRP6KjftSl8UvnGCvsD7sNk5to6LRO99Y0PtMKQzfg0xhiOmm9my
         Npnw==
X-Gm-Message-State: AOJu0YxBl28c52f6Ud7dGiUGpR6XT47EI6KEj+AFCYTTwCblkPaKGatA
	m9LvomdHc6Y06pKZZszqsFquBnRPECUmc5mneplkpHX22zdhZ5YRJEIYHcf/ew==
X-Gm-Gg: ASbGncsP1HA7dHdSFwtJnfbOPD8LSmgsrUi6a27eo43cL5nKuye9ymYV9+fi8vU/K3y
	XE5MC1wKKeR3nKISJgcyXFh4ul+7dVSXLTJkml2oS0J2DK+e3vCZaDQp0aUkwqd67z7tDInGJIZ
	O64CuQ7n7T8Z6djZlJNu+j8EjHJTWndEjX98W1HId0jDgVIyA0O3ce9VM8u9Ap96Yu3YtlyB5Ot
	7AUsePIlZpoKWqlKiHQiaBLxMGfc9Dc9S4HMWR8aao63DePhd6KVFiAhKUBklzu/kDKqV248Psj
	c+UjaM9gzxPeLlwxFhiJ8GPH9OFkmHaBF7lR6QhMUAQ17WeM+KRzn6yJwERTcpheWbuITFdMDUa
	Me0Iaf/JaUtnUQvSMhEGHux+11wFd
X-Google-Smtp-Source: AGHT+IGlilzWBOcrIk6xEzKjUhSp6Kry2hvDfxLl3QVs8wBkT2joe9NOgm6f8whQnW4t8+ONJnpuMw==
X-Received: by 2002:a17:907:7e8e:b0:ade:3015:534e with SMTP id a640c23a62f3a-adec5454bddmr368512266b.14.1749829743631;
        Fri, 13 Jun 2025 08:49:03 -0700 (PDT)
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 ,
	Romain Caritey 
Subject: [PATCH v5 6/9] xen/riscv: implementation of aplic and imsic operations
Date: Fri, 13 Jun 2025 17:48:45 +0200
Message-ID: <47ca7a83e6320547378bb8bc690f5309a6eaf53c.1749825782.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=all
Content-Transfer-Encoding: 8bit

Introduce interrupt controller descriptor for host APLIC to describe
the low-lovel hardare. It includes implementation of the following functions:
 - aplic_irq_startup()
 - aplic_irq_enable()
 - aplic_irq_disable()
 - aplic_set_irq_affinity()

As APLIC is used in MSI mode it requires to enable/disable interrupts not
only for APLIC but also for IMSIC. Thereby for the purpose of
aplic_irq_{enable,disable}() it is introduced imsic_irq_{enable,disable)().

For the purpose of aplic_set_irq_affinity() aplic_get_cpu_from_mask() is
introduced to get hart id.

Also, introduce additional interrupt controller h/w operations and
host_irq_type for APLIC:
 - aplic_host_irq_type

Patch is based on the code from [1].

[1] https://gitlab.com/xen-project/people/olkur/xen/-/commit/7390e2365828b83e27ead56b03114a56e3699dd5

Co-developed-by: Romain Caritey 
Signed-off-by: Oleksii Kurochko 
Acked-by: Jan Beulich 
---
Changes in V5:
 - Add Acked-by: Jan Beulich .
---
Changes in V4:
 - Code style fixes.
 - Add cf_check for hook functions.
 - Use min() macros instead of open-coding it in imsic_local_eix_update().
 - Update the comment above ASSERT() in imsic_irq_disable():
   s/aplic_irq_enable/aplic_irq_disable.
 - Add an explanatory comment above initializing of hhxs in
   aplic_set_irq_affinity().
---
Changes in V3:
 - Update the lock above lock member of struct aplic_priv and imsic_config struct.
 - Use spin_{un}lock() in aplic_irq_{enable,disable}() as it is IRQ-safe.
   Also drop local variable 'flags'.
 - Add ASSERT(spin_is_locked(&desc->lock)) to aplic_set_irq_affinity() and
   aplic_set_irq_type().
 - Use an initializer instead of spin_lock_init() for aplic.lock.
 - Drop "(l)" in the comment in imsic_irq_enable() as it doesn't point to
   anything.
 - Use ASSERT(!local_irq_is_enabled()) + spin_lock() in imsic_irq_{enable,disable}().
 - Use an initializer instead of spin_lock_init() for imsic_config.lock.
---
Changes in V2:
 - Move imsic_ids_local_delivery() and connected to it parts to the current
   patch to fix compilation issue. Also, add __init for
   imsic_ids_local_delivery().
 - Move introduction of aplic_set_irq_type() and aplic_set_irq_priority()
   to patch [PATCH v1 12/14] xen/riscv: implement setup_irq() where they
   really started to be used.
 - Update the commit message.
 - Drop is_used variable for imsic_cfg and use (aplic.regs->domaincfg & APLIC_DOMAINCFG_DM) instead.
 - Use writel() to write to APLIC regs.
 - Drop aplic_irq_shutdown() and use aplic_irq_disable explicitly.
 - Drop local variable cpu in aplic_get_cpu_from_mask():
   Use cpu_online_map instead of cpu_possible_map.
   Remame possible_mask to mask.
 - Code style fixes.
 - Move spin_lock(&aplic.lock) down before write to the register in aplic_set_irq_affinity.
 - Make aplic_host_irq_type const.
 - imsic_local_eix_update() updates:
   - move unsigned long isel, ireg; to inner loop.
   - Drop unnecessary parentheses.
   - Optimize inner loop of ireg's setting.
 - Drop aplic_irq_ack() and aplic_host_irq_end() as they do nothing.
 - Rename s/hwirq/irq.
 - Add explanatory comment to imsic_irq_enable() about why there is not -1 for IRQ in
   comparison with APLIC's sourcecfg.
 - Use IMSIC_MMIO_PAGE_SHIFT instead of constant 12 in aplic_set_irq_affinity().
 - s/aplic_host_irq_type/aplic_xen_irq_type
 - Drop set/clear of IRQ_DISABLED bit in aplic_{enable,disable}() as guest will always
   first request an interrupt and then only an interrupt will be enabled.
   (for example, in Arm, the physical interrupts would be enabled when the
   interrupt is initially routed. This could lead to problem because the guest
   will usually boot with interrupt disabled.)
---
 xen/arch/riscv/aplic-priv.h        |   4 +
 xen/arch/riscv/aplic.c             | 123 ++++++++++++++++++++++++++++-
 xen/arch/riscv/imsic.c             | 122 +++++++++++++++++++++++++++-
 xen/arch/riscv/include/asm/aplic.h |   2 +
 xen/arch/riscv/include/asm/imsic.h |  18 +++++
 5 files changed, 267 insertions(+), 2 deletions(-)

diff --git a/xen/arch/riscv/aplic-priv.h b/xen/arch/riscv/aplic-priv.h
index 7ed1ab8f4b..d377a7ac67 100644
--- a/xen/arch/riscv/aplic-priv.h
+++ b/xen/arch/riscv/aplic-priv.h
@@ -14,6 +14,7 @@
 #ifndef ASM_RISCV_PRIV_APLIC_H
 #define ASM_RISCV_PRIV_APLIC_H
 
+#include 
 #include 
 
 #include 
@@ -27,6 +28,9 @@ struct aplic_priv {
     /* registers */
     volatile struct aplic_regs __iomem *regs;
 
+    /* lock to protect access to APLIC's registers */
+    spinlock_t lock;
+
     /* imsic configuration */
     const struct imsic_config *imsic_cfg;
 };
diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c
index cc3e299212..f3f4a44649 100644
--- a/xen/arch/riscv/aplic.c
+++ b/xen/arch/riscv/aplic.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -23,11 +24,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define APLIC_DEFAULT_PRIORITY  1
 
-static struct aplic_priv aplic;
+static struct aplic_priv aplic = {
+    .lock = SPIN_LOCK_UNLOCKED,
+};
 
 static struct intc_info __ro_after_init aplic_info = {
     .hw_version = INTC_APLIC,
@@ -116,9 +120,126 @@ static int __init cf_check aplic_init(void)
     return 0;
 }
 
+static void cf_check aplic_irq_enable(struct irq_desc *desc)
+{
+    /*
+     * TODO: Currently, APLIC is supported only with MSI interrupts.
+     *       If APLIC without MSI interrupts is required in the future,
+     *       this function will need to be updated accordingly.
+     */
+    ASSERT(readl(&aplic.regs->domaincfg) & APLIC_DOMAINCFG_DM);
+
+    ASSERT(spin_is_locked(&desc->lock));
+
+    spin_lock(&aplic.lock);
+
+    /* Enable interrupt in IMSIC */
+    imsic_irq_enable(desc->irq);
+
+    /* Enable interrupt in APLIC */
+    writel(desc->irq, &aplic.regs->setienum);
+
+    spin_unlock(&aplic.lock);
+}
+
+static void cf_check aplic_irq_disable(struct irq_desc *desc)
+{
+    /*
+     * TODO: Currently, APLIC is supported only with MSI interrupts.
+     *       If APLIC without MSI interrupts is required in the future,
+     *       this function will need to be updated accordingly.
+     */
+    ASSERT(readl(&aplic.regs->domaincfg) & APLIC_DOMAINCFG_DM);
+
+    ASSERT(spin_is_locked(&desc->lock));
+
+    spin_lock(&aplic.lock);
+
+    /* disable interrupt in APLIC */
+    writel(desc->irq, &aplic.regs->clrienum);
+
+    /* disable interrupt in IMSIC */
+    imsic_irq_disable(desc->irq);
+
+    spin_unlock(&aplic.lock);
+}
+
+static unsigned int cf_check aplic_irq_startup(struct irq_desc *desc)
+{
+    aplic_irq_enable(desc);
+
+    return 0;
+}
+
+static unsigned int aplic_get_cpu_from_mask(const cpumask_t *cpumask)
+{
+    cpumask_t mask;
+
+    cpumask_and(&mask, cpumask, &cpu_online_map);
+
+    return cpumask_any(&mask);
+}
+
+static void cf_check aplic_set_irq_affinity(struct irq_desc *desc, const cpumask_t *mask)
+{
+    unsigned int cpu;
+    uint64_t group_index, base_ppn;
+    uint32_t hhxw, lhxw, hhxs, value;
+    const struct imsic_config *imsic = aplic.imsic_cfg;
+
+    /*
+     * TODO: Currently, APLIC is supported only with MSI interrupts.
+     *       If APLIC without MSI interrupts is required in the future,
+     *       this function will need to be updated accordingly.
+     */
+    ASSERT(readl(&aplic.regs->domaincfg) & APLIC_DOMAINCFG_DM);
+
+    ASSERT(!cpumask_empty(mask));
+
+    ASSERT(spin_is_locked(&desc->lock));
+
+    cpu = cpuid_to_hartid(aplic_get_cpu_from_mask(mask));
+    hhxw = imsic->group_index_bits;
+    lhxw = imsic->hart_index_bits;
+    /*
+     * Although this variable is used only once in the calculation of
+     * group_index, and it might seem that hhxs could be defined as:
+     *   hhxs = imsic->group_index_shift - IMSIC_MMIO_PAGE_SHIFT;
+     * and then the addition of IMSIC_MMIO_PAGE_SHIFT could be omitted
+     * when calculating the group index.
+     * It was done intentionally this way to follow the formula from
+     * the AIA specification for calculating the MSI address.
+     */
+    hhxs = imsic->group_index_shift - IMSIC_MMIO_PAGE_SHIFT * 2;
+    base_ppn = imsic->msi[cpu].base_addr >> IMSIC_MMIO_PAGE_SHIFT;
+
+    /* Update hart and EEID in the target register */
+    group_index = (base_ppn >> (hhxs + IMSIC_MMIO_PAGE_SHIFT)) &
+                  (BIT(hhxw, UL) - 1);
+    value = desc->irq;
+    value |= cpu << APLIC_TARGET_HART_IDX_SHIFT;
+    value |= group_index << (lhxw + APLIC_TARGET_HART_IDX_SHIFT);
+
+    spin_lock(&aplic.lock);
+
+    writel(value, &aplic.regs->target[desc->irq - 1]);
+
+    spin_unlock(&aplic.lock);
+}
+
+static const hw_irq_controller aplic_xen_irq_type = {
+    .typename     = "aplic",
+    .startup      = aplic_irq_startup,
+    .shutdown     = aplic_irq_disable,
+    .enable       = aplic_irq_enable,
+    .disable      = aplic_irq_disable,
+    .set_affinity = aplic_set_irq_affinity,
+};
+
 static const struct intc_hw_operations aplic_ops = {
     .info                = &aplic_info,
     .init                = aplic_init,
+    .host_irq_type       = &aplic_xen_irq_type,
 };
 
 static int cf_check aplic_irq_xlate(const uint32_t *intspec,
diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c
index e7f06950de..674c9b7b41 100644
--- a/xen/arch/riscv/imsic.c
+++ b/xen/arch/riscv/imsic.c
@@ -29,7 +29,124 @@ struct imsic_mmios {
     unsigned long size;
 };
 
-static struct imsic_config imsic_cfg;
+static struct imsic_config imsic_cfg = {
+    .lock = SPIN_LOCK_UNLOCKED,
+};
+
+#define IMSIC_DISABLE_EIDELIVERY    0
+#define IMSIC_ENABLE_EIDELIVERY     1
+#define IMSIC_DISABLE_EITHRESHOLD   1
+#define IMSIC_ENABLE_EITHRESHOLD    0
+
+#define imsic_csr_write(c, v)   \
+do {                            \
+    csr_write(CSR_SISELECT, c); \
+    csr_write(CSR_SIREG, v);    \
+} while (0)
+
+#define imsic_csr_set(c, v)     \
+do {                            \
+    csr_write(CSR_SISELECT, c); \
+    csr_set(CSR_SIREG, v);      \
+} while (0)
+
+#define imsic_csr_clear(c, v)   \
+do {                            \
+    csr_write(CSR_SISELECT, c); \
+    csr_clear(CSR_SIREG, v);    \
+} while (0)
+
+void __init imsic_ids_local_delivery(bool enable)
+{
+    if ( enable )
+    {
+        imsic_csr_write(IMSIC_EITHRESHOLD, IMSIC_ENABLE_EITHRESHOLD);
+        imsic_csr_write(IMSIC_EIDELIVERY, IMSIC_ENABLE_EIDELIVERY);
+    }
+    else
+    {
+        imsic_csr_write(IMSIC_EITHRESHOLD, IMSIC_DISABLE_EITHRESHOLD);
+        imsic_csr_write(IMSIC_EIDELIVERY, IMSIC_DISABLE_EIDELIVERY);
+    }
+}
+
+static void imsic_local_eix_update(unsigned long base_id, unsigned long num_id,
+                                   bool pend, bool val)
+{
+    unsigned long id = base_id, last_id = base_id + num_id;
+
+    while ( id < last_id )
+    {
+        unsigned long isel, ireg;
+        unsigned long start_id = id & (__riscv_xlen - 1);
+        unsigned long chunk = __riscv_xlen - start_id;
+        unsigned long count = min(last_id - id, chunk);
+
+        isel = id / __riscv_xlen;
+        isel *= __riscv_xlen / IMSIC_EIPx_BITS;
+        isel += pend ? IMSIC_EIP0 : IMSIC_EIE0;
+
+        ireg = GENMASK(start_id + count - 1, start_id);
+
+        id += count;
+
+        if ( val )
+            imsic_csr_set(isel, ireg);
+        else
+            imsic_csr_clear(isel, ireg);
+    }
+}
+
+void imsic_irq_enable(unsigned int irq)
+{
+    /*
+    * The only caller of imsic_irq_enable() is aplic_irq_enable(), which
+    * already runs with IRQs disabled. Therefore, there's no need to use
+    * spin_lock_irqsave() in this function.
+    *
+    * This ASSERT is added as a safeguard: if imsic_irq_enable() is ever
+    * called from a context where IRQs are not disabled,
+    * spin_lock_irqsave() should be used instead of spin_lock().
+    */
+    ASSERT(!local_irq_is_enabled());
+
+    spin_lock(&imsic_cfg.lock);
+    /*
+     * There is no irq - 1 here (look at aplic_set_irq_type()) because:
+     * From the spec:
+     *   When an interrupt file supports distinct interrupt identities,
+     *   valid identity numbers are between 1 and inclusive. The identity
+     *   numbers within this range are said to be implemented by the interrupt
+     *   file; numbers outside this range are not implemented. The number zero
+     *   is never a valid interrupt identity.
+     *   ...
+     *   Bit positions in a valid eiek register that don’t correspond to a
+     *   supported interrupt identity (such as bit 0 of eie0) are read-only zeros.
+     *
+     * So in EIx registers interrupt i corresponds to bit i in comparison wiht
+     * APLIC's sourcecfg which starts from 0.
+     */
+    imsic_local_eix_update(irq, 1, false, true);
+    spin_unlock(&imsic_cfg.lock);
+}
+
+void imsic_irq_disable(unsigned int irq)
+{
+   /*
+    * The only caller of imsic_irq_disable() is aplic_irq_disable(), which
+    * already runs with IRQs disabled. Therefore, there's no need to use
+    * spin_lock_irqsave() in this function.
+    *
+    * This ASSERT is added as a safeguard: if imsic_irq_disable() is ever
+    * called from a context where IRQs are not disabled,
+    * spin_lock_irqsave() should be used instead of spin_lock().
+    */
+    ASSERT(!local_irq_is_enabled());
+
+    spin_lock(&imsic_cfg.lock);
+    imsic_local_eix_update(irq, 1, false, false);
+    spin_unlock(&imsic_cfg.lock);
+}
 
 /* Callers aren't intended to changed imsic_cfg so return const. */
 const struct imsic_config *imsic_get_config(void)
@@ -355,6 +472,9 @@ int __init imsic_init(const struct dt_device_node *node)
         goto imsic_init_err;
     }
 
+    /* Enable local interrupt delivery */
+    imsic_ids_local_delivery(true);
+
     imsic_cfg.msi = msi;
 
     xvfree(mmios);
diff --git a/xen/arch/riscv/include/asm/aplic.h b/xen/arch/riscv/include/asm/aplic.h
index fea95d4369..c3f00238f2 100644
--- a/xen/arch/riscv/include/asm/aplic.h
+++ b/xen/arch/riscv/include/asm/aplic.h
@@ -18,6 +18,8 @@
 #define APLIC_DOMAINCFG_IE      BIT(8, U)
 #define APLIC_DOMAINCFG_DM      BIT(2, U)
 
+#define APLIC_TARGET_HART_IDX_SHIFT 18
+
 struct aplic_regs {
     uint32_t domaincfg;
     uint32_t sourcecfg[1023];
diff --git a/xen/arch/riscv/include/asm/imsic.h b/xen/arch/riscv/include/asm/imsic.h
index 9cd12365b1..378e49d933 100644
--- a/xen/arch/riscv/include/asm/imsic.h
+++ b/xen/arch/riscv/include/asm/imsic.h
@@ -11,6 +11,7 @@
 #ifndef ASM_RISCV_IMSIC_H
 #define ASM_RISCV_IMSIC_H
 
+#include 
 #include 
 
 #define IMSIC_MMIO_PAGE_SHIFT   12
@@ -19,6 +20,15 @@
 #define IMSIC_MIN_ID            63
 #define IMSIC_MAX_ID            2047
 
+#define IMSIC_EIDELIVERY        0x70
+
+#define IMSIC_EITHRESHOLD       0x72
+
+#define IMSIC_EIP0              0x80
+#define IMSIC_EIPx_BITS         32
+
+#define IMSIC_EIE0              0xC0
+
 struct imsic_msi {
     paddr_t base_addr;
     unsigned long offset;
@@ -45,6 +55,9 @@ struct imsic_config {
 
     /* MSI */
     const struct imsic_msi *msi;
+
+    /* Lock to protect access to IMSIC's stuff */
+    spinlock_t lock;
 };
 
 struct dt_device_node;
@@ -52,4 +65,9 @@ int imsic_init(const struct dt_device_node *node);
 
 const struct imsic_config *imsic_get_config(void);
 
+void imsic_irq_enable(unsigned int hwirq);
+void imsic_irq_disable(unsigned int hwirq);
+
+void imsic_ids_local_delivery(bool enable);
+
 #endif /* ASM_RISCV_IMSIC_H */
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 15:49:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 15:49:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014634.1392798 (Exim 4.92)
	(envelope-from )
	id 1uQ6eU-0000Kf-Jv; Fri, 13 Jun 2025 15:49:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014634.1392798; Fri, 13 Jun 2025 15: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 1uQ6eU-0000KB-DQ; Fri, 13 Jun 2025 15:49:10 +0000
Received: by outflank-mailman (input) for mailman id 1014634;
 Fri, 13 Jun 2025 15:49: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 1uQ6eS-0006cn-Mu
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 15:49:08 +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 f011e806-486d-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 17:49:06 +0200 (CEST)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-adb5cb6d8f1so399733566b.3
 for ; Fri, 13 Jun 2025 08:49:06 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-adec8979563sm144821766b.158.2025.06.13.08.49.03
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Jun 2025 08:49:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f011e806-486d-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749829746; x=1750434546; darn=lists.xenproject.org;
        h=content-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=G/8G0maLAdS7qiUNN1zQIFAqq4669vsyHIhw5b6gzZ8=;
        b=H5nIUquYVfIr+5UBu8MVnElaJthCWjE6NQQo3omwJzfKHHUxZ+iECw7bfwwK37Rjik
         m5vvCL2VSRlOCiYbZ3Irl4OnS9y9cCUOwPlrvWmr70ePlxTuUCo2scr3ZqzOuYpHbvaR
         DDc07ZyOA4mzZAekLGK6sb1Spyluv/GoauSX7x/41rJEMfNOdaiFPA7A3pLc8IgfK5al
         4L4voC4udOc23EZao0h9IpQXZPGUT5uG+OTLK8w9Heu/ssmhtoEiVBdcQlwEansXUTXa
         bkER1sY186dQvCoQdLBZHDv+c5Qz839Y7garIfPQ+5IWkBZz6uR5mnMQ2oAIilfQJYYz
         lcRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749829746; x=1750434546;
        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=G/8G0maLAdS7qiUNN1zQIFAqq4669vsyHIhw5b6gzZ8=;
        b=p6zVEFnb/ZJ3d5R1PxsL4RDONFDmJRbKS3lWi/IWHb0b96nYKW1kMXx7l4SJwy4OLf
         6Ayu6p7TZzeZ9fAr7jfk03bIoLjTFcoFWikihlgHGhk9oUFyrNdN3DqS6BNyOLar8q6w
         OKm3IrCsvTq1AoRlE4Vlrv3cp2WlgdC5aGfJ0SdASjVWui+O1UVLxk4KjCkAYwoEd8s0
         3QamNewo1z2ILBW/6PnEhS84qFc+olzx9Qyz6028cgvGM0o2nMy76Vf8gvG3PV03B1Ul
         nW1KMIaP2MQ6I1igUD1NxvKncuCN1HQlO0Ozb7aIkLykqNsqPJtrjG7LDl1oXEKpkr84
         P2iA==
X-Gm-Message-State: AOJu0YzxPu64QTzXH5javTajyhRZ7bZHrSHy6NqhEBXJRm6AhQ0nusMi
	K0V45BsBJIOG1nacIOBvd5La10ldyeYjja3R/TFSnA66yANam82g8k9WAhXhvA==
X-Gm-Gg: ASbGncse/4WATuoT9B3RovwQj/9TBBwSXeYy1drFYWv5DA+MiEDhs9DcGFsJWkNSFOC
	v4R/TAVoatXYG95Ew+Ob+xBf7DRh7Pmiz+3CHyokjC19h9YCXrimxIubmbqrv/DC0jOHn1sJvDG
	0YIQQthUqUFmJXKICQZYajR8NFTC45F/2b6AlYA7Fovb7UR9Snsm9T5ghXp0hxV0adqIs6v2hft
	N7Rg1Tf/3/I/YsfN/udw9UGn59cSuTYGwm8aUe8FkWY/z6L8B7Ao0LrZQdxbdApeqlMSq7ANcsf
	OmT6gBdsrDy4Oep1P6F3qbvwMCRX8X0YB9voO1G5dwYuRj89OiyTdQOaqmeKjhIe2go5W9oVA6D
	50t0kPkW9eaPsldvt+L/lnxp6NlF1
X-Google-Smtp-Source: AGHT+IE5T5Qjocief1oZduJTAONzPqr4yUERGVSSj6rRcJmvFl4TpiHXOdDafhuF40U3bNtdSpEV7w==
X-Received: by 2002:a17:907:9623:b0:ad5:a29c:efed with SMTP id a640c23a62f3a-adec5cb0022mr351633666b.33.1749829745688;
        Fri, 13 Jun 2025 08:49:05 -0700 (PDT)
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 ,
	Romain Caritey 
Subject: [PATCH v5 7/9] xen/riscv: add external interrupt handling for hypervisor mode
Date: Fri, 13 Jun 2025 17:48:46 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=all
Content-Transfer-Encoding: 8bit

Implement functions necessarry to have working external interrupts in
hypervisor mode. The following changes are done:
  - Add a common function intc_handle_external_irq() to call APLIC specific
    function to handle an interrupt.
  - Update do_trap() function to handle IRQ_S_EXT case; add the check to catch
    case when cause of trap is an interrupt.
  - Add handle_interrrupt() member to intc_hw_operations structure.
  - Enable local interrupt delivery for IMSIC by calling of
    imsic_ids_local_delivery() in imsic_init(); additionally introduce helper
    imsic_csr_write() to update IMSIC_EITHRESHOLD and IMSIC_EITHRESHOLD.
  - Enable hypervisor external interrupts.
  - Implement aplic_handler_interrupt() and use it to init ->handle_interrupt
    member of intc_hw_operations for APLIC.
  - Add implementation of do_IRQ() to dispatch the interrupt.

The current patch is based on the code from [1].

[1] https://gitlab.com/xen-project/people/olkur/xen/-/commit/7390e2365828b83e27ead56b03114a56e3699dd5

Co-developed-by: Romain Caritey 
Signed-off-by: Oleksii Kurochko 
Acked-by: Jan Beulich 
---
Changes in V4 - V5:
 - Nothing changed. Only rebase.
---
Changes in V3:
 - Add ASSERT(spin_is_locked(&desc->lock)) to aplic_set_irq_type().
 - Fix code style for switch () in aplic_set_irq_type().
 - Drop fallthrough between "case IRQ_TYPE_NONE: case IRQ_TYPE_INVALID:" as there
   is no other statements in "case IRQ_TYPE_NONE".
 - Add Acked-by: Jan Beulich .
---
Changes in V2:
 - use BIT() macros instead of 1UL << bit_num in aplic.c.
 - Drop passing of a cause to aplic_handle_interrupt() function. And update
   prototype of handle_interrupt() callback.
 - Drop ASSERT() in intc_handle_external_irqs() as it is useless.
 - Code style fixes.
 - Drop cause argument for intc_handle_external_irqs().
 - Update the commit message: drop words that imsic_ids_local_delivery() is
   implemented in this patch, it is only called.
 - Add cf_check for aplic_handle_interrupt(), aplic_set_irq_type().
 - Move forward declarations in asm/intc.h up.
 - Use plain C operator instead if {clear,set}_bit() for desc->status as it
   is always used under spinlock().
 - use writel() for writing to APLIC's sourcecfg in aplic_set_irq_type().
---
 xen/arch/riscv/aplic.c             | 71 ++++++++++++++++++++++++++++++
 xen/arch/riscv/include/asm/aplic.h |  7 +++
 xen/arch/riscv/include/asm/imsic.h |  1 +
 xen/arch/riscv/include/asm/intc.h  |  6 +++
 xen/arch/riscv/include/asm/irq.h   |  6 ++-
 xen/arch/riscv/intc.c              |  5 +++
 xen/arch/riscv/irq.c               | 47 ++++++++++++++++++++
 xen/arch/riscv/traps.c             | 19 ++++++++
 8 files changed, 161 insertions(+), 1 deletion(-)

diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c
index f3f4a44649..7e0cacc8d2 100644
--- a/xen/arch/riscv/aplic.c
+++ b/xen/arch/riscv/aplic.c
@@ -9,6 +9,7 @@
  * Copyright (c) 2024-2025 Vates
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -227,6 +228,71 @@ static void cf_check aplic_set_irq_affinity(struct irq_desc *desc, const cpumask
     spin_unlock(&aplic.lock);
 }
 
+static void cf_check aplic_handle_interrupt(struct cpu_user_regs *regs)
+{
+    /* disable to avoid more external interrupts */
+    csr_clear(CSR_SIE, BIT(IRQ_S_EXT, UL));
+
+    /* clear the pending bit */
+    csr_clear(CSR_SIP, BIT(IRQ_S_EXT, UL));
+
+    /* dispatch the interrupt */
+    do_IRQ(regs, csr_swap(CSR_STOPEI, 0) >> TOPI_IID_SHIFT);
+
+    /* enable external interrupts */
+    csr_set(CSR_SIE, BIT(IRQ_S_EXT, UL));
+}
+
+static void cf_check aplic_set_irq_type(struct irq_desc *desc, unsigned int type)
+{
+    /*
+    * Interrupt 0 isn't possible based on the spec:
+    *   Each of an APLIC’s interrupt sources has a fixed unique identity number in the range 1 to N,
+    *   where N is the total number of sources at the APLIC. The number zero is not a valid interrupt
+    *   identity number at an APLIC. The maximum number of interrupt sources an APLIC may support
+    *   is 1023.
+    *
+    * Thereby interrupt 1 will correspond to bit 0 in sourcecfg[] register,
+    * interrupt 2 ->sourcecfg[1] and so on.
+    *
+    * And that is the reason why we need -1.
+    */
+    unsigned int irq_bit = desc->irq - 1;
+
+    ASSERT(spin_is_locked(&desc->lock));
+
+    spin_lock(&aplic.lock);
+
+    switch ( type )
+    {
+    case IRQ_TYPE_EDGE_RISING:
+        writel(APLIC_SOURCECFG_SM_EDGE_RISE, &aplic.regs->sourcecfg[irq_bit]);
+        break;
+
+    case IRQ_TYPE_EDGE_FALLING:
+        writel(APLIC_SOURCECFG_SM_EDGE_FALL, &aplic.regs->sourcecfg[irq_bit]);
+        break;
+
+    case IRQ_TYPE_LEVEL_HIGH:
+        writel(APLIC_SOURCECFG_SM_LEVEL_HIGH, &aplic.regs->sourcecfg[irq_bit]);
+        break;
+
+    case IRQ_TYPE_LEVEL_LOW:
+        writel(APLIC_SOURCECFG_SM_LEVEL_LOW, &aplic.regs->sourcecfg[irq_bit]);
+        break;
+
+    case IRQ_TYPE_NONE:
+    case IRQ_TYPE_INVALID:
+        writel(APLIC_SOURCECFG_SM_INACTIVE, &aplic.regs->sourcecfg[irq_bit]);
+        break;
+
+    default:
+        panic("%s: APLIC doesnt support IRQ type: 0x%x?\n", __func__, type);
+    }
+
+    spin_unlock(&aplic.lock);
+}
+
 static const hw_irq_controller aplic_xen_irq_type = {
     .typename     = "aplic",
     .startup      = aplic_irq_startup,
@@ -240,6 +306,8 @@ static const struct intc_hw_operations aplic_ops = {
     .info                = &aplic_info,
     .init                = aplic_init,
     .host_irq_type       = &aplic_xen_irq_type,
+    .handle_interrupt    = aplic_handle_interrupt,
+    .set_irq_type        = aplic_set_irq_type,
 };
 
 static int cf_check aplic_irq_xlate(const uint32_t *intspec,
@@ -279,6 +347,9 @@ static int __init aplic_preinit(struct dt_device_node *node, const void *dat)
 
     register_intc_ops(&aplic_ops);
 
+    /* Enable supervisor external interrupt */
+    csr_set(CSR_SIE, BIT(IRQ_S_EXT, UL));
+
     return 0;
 }
 
diff --git a/xen/arch/riscv/include/asm/aplic.h b/xen/arch/riscv/include/asm/aplic.h
index c3f00238f2..b335b29d34 100644
--- a/xen/arch/riscv/include/asm/aplic.h
+++ b/xen/arch/riscv/include/asm/aplic.h
@@ -18,6 +18,13 @@
 #define APLIC_DOMAINCFG_IE      BIT(8, U)
 #define APLIC_DOMAINCFG_DM      BIT(2, U)
 
+#define APLIC_SOURCECFG_SM_INACTIVE     0x0
+#define APLIC_SOURCECFG_SM_DETACH       0x1
+#define APLIC_SOURCECFG_SM_EDGE_RISE    0x4
+#define APLIC_SOURCECFG_SM_EDGE_FALL    0x5
+#define APLIC_SOURCECFG_SM_LEVEL_HIGH   0x6
+#define APLIC_SOURCECFG_SM_LEVEL_LOW    0x7
+
 #define APLIC_TARGET_HART_IDX_SHIFT 18
 
 struct aplic_regs {
diff --git a/xen/arch/riscv/include/asm/imsic.h b/xen/arch/riscv/include/asm/imsic.h
index 378e49d933..c6c59215df 100644
--- a/xen/arch/riscv/include/asm/imsic.h
+++ b/xen/arch/riscv/include/asm/imsic.h
@@ -12,6 +12,7 @@
 #define ASM_RISCV_IMSIC_H
 
 #include 
+#include 
 #include 
 
 #define IMSIC_MMIO_PAGE_SHIFT   12
diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h
index a11b7aa55e..ecdc8a5e65 100644
--- a/xen/arch/riscv/include/asm/intc.h
+++ b/xen/arch/riscv/include/asm/intc.h
@@ -14,6 +14,7 @@ enum intc_version {
     INTC_APLIC,
 };
 
+struct cpu_user_regs;
 struct irq_desc;
 
 struct intc_info {
@@ -37,6 +38,9 @@ struct intc_hw_operations {
     void (*set_irq_type)(struct irq_desc *desc, unsigned int type);
     /* Set IRQ priority */
     void (*set_irq_priority)(struct irq_desc *desc, unsigned int priority);
+
+    /* handle external interrupt */
+    void (*handle_interrupt)(struct cpu_user_regs *regs);
 };
 
 void intc_preinit(void);
@@ -47,4 +51,6 @@ void intc_init(void);
 
 void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority);
 
+void intc_handle_external_irqs(struct cpu_user_regs *regs);
+
 #endif /* ASM__RISCV__INTERRUPT_CONTOLLER_H */
diff --git a/xen/arch/riscv/include/asm/irq.h b/xen/arch/riscv/include/asm/irq.h
index 84c3c2904d..94151eb083 100644
--- a/xen/arch/riscv/include/asm/irq.h
+++ b/xen/arch/riscv/include/asm/irq.h
@@ -33,16 +33,20 @@ struct arch_irq_desc {
     unsigned int type;
 };
 
+struct cpu_user_regs;
+struct dt_device_node;
+
 static inline void arch_move_irqs(struct vcpu *v)
 {
     BUG_ON("unimplemented");
 }
 
-struct dt_device_node;
 int platform_get_irq(const struct dt_device_node *device, int index);
 
 void init_IRQ(void);
 
+void do_IRQ(struct cpu_user_regs *regs, unsigned int irq);
+
 #endif /* ASM__RISCV__IRQ_H */
 
 /*
diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c
index f2823267a9..ea317aea5a 100644
--- a/xen/arch/riscv/intc.c
+++ b/xen/arch/riscv/intc.c
@@ -50,6 +50,11 @@ static void intc_set_irq_priority(struct irq_desc *desc, unsigned int priority)
         intc_hw_ops->set_irq_priority(desc, priority);
 }
 
+void intc_handle_external_irqs(struct cpu_user_regs *regs)
+{
+    intc_hw_ops->handle_interrupt(regs);
+}
+
 void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority)
 {
     ASSERT(desc->status & IRQ_DISABLED);
diff --git a/xen/arch/riscv/irq.c b/xen/arch/riscv/irq.c
index 669ef3ae9e..466f1b4ba9 100644
--- a/xen/arch/riscv/irq.c
+++ b/xen/arch/riscv/irq.c
@@ -11,6 +11,10 @@
 #include 
 #include 
 #include 
+#include 
+
+#include 
+#include 
 
 static irq_desc_t irq_desc[NR_IRQS];
 
@@ -90,3 +94,46 @@ void __init init_IRQ(void)
     if ( init_irq_data() < 0 )
         panic("initialization of IRQ data failed\n");
 }
+
+/* Dispatch an interrupt */
+void do_IRQ(struct cpu_user_regs *regs, unsigned int irq)
+{
+    struct irq_desc *desc = irq_to_desc(irq);
+    struct irqaction *action;
+
+    irq_enter();
+
+    spin_lock(&desc->lock);
+
+    if ( desc->handler->ack )
+        desc->handler->ack(desc);
+
+    if ( desc->status & IRQ_DISABLED )
+        goto out;
+
+    desc->status |= IRQ_INPROGRESS;
+
+    action = desc->action;
+
+    spin_unlock_irq(&desc->lock);
+
+#ifndef CONFIG_IRQ_HAS_MULTIPLE_ACTION
+    action->handler(irq, action->dev_id);
+#else
+    do {
+        action->handler(irq, action->dev_id);
+        action = action->next;
+    } while ( action );
+#endif /* CONFIG_IRQ_HAS_MULTIPLE_ACTION */
+
+    spin_lock_irq(&desc->lock);
+
+    desc->status &= ~IRQ_INPROGRESS;
+
+ out:
+    if ( desc->handler->end )
+        desc->handler->end(desc);
+
+    spin_unlock(&desc->lock);
+    irq_exit();
+}
diff --git a/xen/arch/riscv/traps.c b/xen/arch/riscv/traps.c
index ea3638a54f..f061004d83 100644
--- a/xen/arch/riscv/traps.c
+++ b/xen/arch/riscv/traps.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -128,6 +129,24 @@ void do_trap(struct cpu_user_regs *cpu_regs)
         }
         fallthrough;
     default:
+        if ( cause & CAUSE_IRQ_FLAG )
+        {
+            /* Handle interrupt */
+            unsigned long icause = cause & ~CAUSE_IRQ_FLAG;
+
+            switch ( icause )
+            {
+            case IRQ_S_EXT:
+                intc_handle_external_irqs(cpu_regs);
+                break;
+
+            default:
+                break;
+            }
+
+            break;
+        }
+
         do_unexpected_trap(cpu_regs);
         break;
     }
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 15:49:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 15:49:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014635.1392804 (Exim 4.92)
	(envelope-from )
	id 1uQ6eV-0000TJ-H0; Fri, 13 Jun 2025 15:49:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014635.1392804; Fri, 13 Jun 2025 15:49: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 1uQ6eV-0000RO-69; Fri, 13 Jun 2025 15:49:11 +0000
Received: by outflank-mailman (input) for mailman id 1014635;
 Fri, 13 Jun 2025 15: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 1uQ6eT-0006cn-Mt
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 15:49:09 +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 f0c278db-486d-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 17:49:07 +0200 (CEST)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-60727e46168so3871602a12.0
 for ; Fri, 13 Jun 2025 08:49:07 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-adec8979563sm144821766b.158.2025.06.13.08.49.05
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Jun 2025 08:49:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f0c278db-486d-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749829747; x=1750434547; darn=lists.xenproject.org;
        h=content-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=Ng1/O00EG3qvzx6QpvcaagFyielcBbUguKaEDbZry58=;
        b=KU60eSabMvBT28/NMRtsePRG499XRve6L4Z06PpYCNNuCmGjxSAln/UlhrYGE57G9y
         0HtxvJUrFadU11dHVX/lXu7tL6rfG6hWi0/ai4q4YoCRhoaSpNa8wYbziC7z1L476xro
         /Qsz3JFeGnZiDOlArXZJJlFbjCoMGIiOpETih9mbkHFFWlx4SpsOwGMTuywxzmmORweR
         ZCO0+ohxac2wcMo404auTXC7lvIBVN4asiKPRQ4i0vWXkKLHcvowiyHbqs/hm2ASdWZk
         xy5cMNlR67Ra8K3ayNPIFuqxQK5UtPkk7WYDc1aLeRM1qSdQly7dseTKYCbfx3+MzQZa
         26CA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749829747; x=1750434547;
        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=Ng1/O00EG3qvzx6QpvcaagFyielcBbUguKaEDbZry58=;
        b=fFKtHb4ZgP8MnpeNhjNTucMaaSGXsJsX9Hr5LrrgKCat1GDJd1ICviQ/deyHAUMptE
         rLhz53U3yKjNnqkGYBKa8ha1wHkZHwqMO8hB4EwhSeAXn8GMdqrcOlrCwLmBMrxsoGTn
         LO0UQ//iaWK+XuUtFbw45SSVRZXOf7u2DZ1jD3kApk3pI/wcx7SrE8wcFaolTS/ADaxk
         uMQZWAeswdexYTWPH9wIBVn1uhsai1gSa8zLTZkvmoFhxPqt3Bdhr3bV/YNNTk+l+6Zv
         5wCTu6ldj7NLUq4lZ84bwc+Hgvoo/fAF6ASg5HlUBgvfUF5rOd3YUhBD/KV3tC+kR+8M
         a/4w==
X-Gm-Message-State: AOJu0YwHWEargPLB9/plR7TRRKGjIXCPrHJGBtI5kKabdwdDFTcs08i3
	G0SnwJretDbKy4tfzyeRYW06RHcvfZonuQMwKlguyIV8+Fh36QXGMR/J6emPbA==
X-Gm-Gg: ASbGncsD+AZP0s0Yg9rCgvys2z2Jg9j+9xKJqcGCZTX+NxiVO4ln2DoBM47JEHSCMep
	OO76IdS6QViW44gnSr3Kg+T0YvcTLL1SzA+QEgEo47i0YfKXoJ0J1RkpG9z/7DHxJDxUbE2iUU7
	iFxModBgRGGofncOaL6KBf9RqfBfPJWBWIfBLwZqtPeWducRYgRzNV/zlmCmUKwEzLaqFqQBKTr
	VfgcwGaFyYxI2LUu6Ryx1CbKKb6dNQtKN4oDaNfxjC5Wc0HPCU7Bpx/TySOU9qnAYKWPVXsiqVM
	RwMYkwFfcq4T1myPpDAO8JsT5HPR8LKL/flAEnCGoAW0b1MBxKALzB2+tvTxZCjoMS2dsJSvUMs
	epPGg4pTQ75ULhKrpWhjYcciU2dY5pBPb60FQ3mY=
X-Google-Smtp-Source: AGHT+IE/3Xp4wH/5ZF0WFtvv8fz0DGFg6r9En/d1UaVZQcK/0802/7eUP+YSNHJznRL7QFiHkNUV5A==
X-Received: by 2002:a17:906:7956:b0:ad8:a4a8:103a with SMTP id a640c23a62f3a-adec559616cmr391301766b.4.1749829746719;
        Fri, 13 Jun 2025 08:49:06 -0700 (PDT)
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 ,
	Romain Caritey 
Subject: [PATCH v5 8/9] xen/riscv: implement setup_irq()
Date: Fri, 13 Jun 2025 17:48:47 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Introduce support for IRQ setup on RISC-V by implementing setup_irq() and
__setup_irq(), adapted and extended from an initial implementation by [1].

__setup_irq() does the following:
  - Sets up an IRQ action.
  - Validates that shared IRQs have non-NULL `dev_id` and are only used when
    existing handlers allow sharing.
  - Uses smp_wmb() to enforce memory ordering after assigning desc->action
    to ensure visibility before enabling the IRQ.
  - Supports multi-action setups via CONFIG_IRQ_HAS_MULTIPLE_ACTION.

setup_irq() does the following:
  - Converts IRQ number to descriptor and acquires its lock.
  - Rejects registration if the IRQ is already assigned to a guest domain,
    printing an error.
  - Delegates the core setup to __setup_irq().
  - On first-time setup, disables the IRQ, routes it to Xen using
    intc_route_irq_to_xen(), sets default CPU affinity (current CPU),
    calls the handler’s startup routine, and finally enables the IRQ.

irq_set_affinity() invokes set_affinity() callback from the IRQ handler
if present.

Defined IRQ_NO_PRIORITY as default priority used when routing IRQs to Xen.

[1] https://gitlab.com/xen-project/people/olkur/xen/-/commit/7390e2365828b83e27ead56b03114a56e3699dd5

Co-developed-by: Romain Caritey 
Signed-off-by: Oleksii Kurochko 
Acked-by: Jan Beulich 
---
Changes in V5:
 - Add Acked-by: Jan Beulich .
---
Changes in V3-4:
 - Nothing changed. Only rebase.
---
Changes in V2:
 - Added implenmtation of aplic_set_irq_type() as it is going to be used in
   this commit. And also, update the implementation of it. Make default case
   of switch to do panic().
 - Move all forward declaration up  in asm/irq.h.
 - s/__setup_irq/_setup_irq.
 - Code style fixes.
 - Update commit message.
 - use smp_wmb() instead of smp_mb() in _setup_irq().
 - Drop irq_set_affinity().
 - Use plain C operator instead if {clear,set}_bit() for desc->status as it
   is always used under spinlock().
 - Drop set_bit(_IRQ_DISABLED, &desc->status) in setup_irq() as in the case
   when IRQ is setuped for a first time, desc->status should be already set
   to IRQ_DISABLED in init_one_irq_desc().
----
 xen/arch/riscv/include/asm/irq.h |  2 +
 xen/arch/riscv/irq.c             | 84 ++++++++++++++++++++++++++++++++
 2 files changed, 86 insertions(+)

diff --git a/xen/arch/riscv/include/asm/irq.h b/xen/arch/riscv/include/asm/irq.h
index 94151eb083..f633636dc3 100644
--- a/xen/arch/riscv/include/asm/irq.h
+++ b/xen/arch/riscv/include/asm/irq.h
@@ -17,6 +17,8 @@
  */
 #define NR_IRQS 1024
 
+#define IRQ_NO_PRIORITY 0
+
 /* TODO */
 #define nr_irqs 0U
 #define nr_static_irqs 0
diff --git a/xen/arch/riscv/irq.c b/xen/arch/riscv/irq.c
index 466f1b4ba9..25d3295002 100644
--- a/xen/arch/riscv/irq.c
+++ b/xen/arch/riscv/irq.c
@@ -7,6 +7,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -63,6 +64,89 @@ int platform_get_irq(const struct dt_device_node *device, int index)
     return dt_irq.irq;
 }
 
+static int _setup_irq(struct irq_desc *desc, unsigned int irqflags,
+                      struct irqaction *new)
+{
+    bool shared = irqflags & IRQF_SHARED;
+
+    ASSERT(new != NULL);
+
+    /*
+     * Sanity checks:
+     *  - if the IRQ is marked as shared
+     *  - dev_id is not NULL when IRQF_SHARED is set
+     */
+    if ( desc->action != NULL && (!(desc->status & IRQF_SHARED) || !shared) )
+        return -EINVAL;
+    if ( shared && new->dev_id == NULL )
+        return -EINVAL;
+
+    if ( shared )
+        desc->status |= IRQF_SHARED;
+
+#ifdef CONFIG_IRQ_HAS_MULTIPLE_ACTION
+    new->next = desc->action;
+#endif
+
+    desc->action = new;
+    smp_wmb();
+
+    return 0;
+}
+
+int setup_irq(unsigned int irq, unsigned int irqflags, struct irqaction *new)
+{
+    int rc;
+    unsigned long flags;
+    struct irq_desc *desc = irq_to_desc(irq);
+    bool disabled;
+
+    spin_lock_irqsave(&desc->lock, flags);
+
+    disabled = (desc->action == NULL);
+
+    if ( desc->status & IRQ_GUEST )
+    {
+        spin_unlock_irqrestore(&desc->lock, flags);
+        /*
+         * TODO: would be nice to have functionality to print which domain owns
+         *       an IRQ.
+         */
+        printk(XENLOG_ERR "ERROR: IRQ %u is already in use by a domain\n", irq);
+        return -EBUSY;
+    }
+
+    rc = _setup_irq(desc, irqflags, new);
+    if ( rc )
+        goto err;
+
+    /* First time the IRQ is setup */
+    if ( disabled )
+    {
+        /* Route interrupt to xen */
+        intc_route_irq_to_xen(desc, IRQ_NO_PRIORITY);
+
+        /*
+         * We don't care for now which CPU will receive the
+         * interrupt.
+         *
+         * TODO: Handle case where IRQ is setup on different CPU than
+         *       the targeted CPU and the priority.
+         */
+        desc->handler->set_affinity(desc, cpumask_of(smp_processor_id()));
+
+        desc->handler->startup(desc);
+
+        /* Enable irq */
+        desc->status &= ~IRQ_DISABLED;
+    }
+
+ err:
+    spin_unlock_irqrestore(&desc->lock, flags);
+
+    return rc;
+}
+
 int arch_init_one_irq_desc(struct irq_desc *desc)
 {
     desc->arch.type = IRQ_TYPE_INVALID;
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 15:49:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 15:49:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014638.1392816 (Exim 4.92)
	(envelope-from )
	id 1uQ6eW-0000qp-SS; Fri, 13 Jun 2025 15:49:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014638.1392816; Fri, 13 Jun 2025 15:49: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 1uQ6eW-0000op-KB; Fri, 13 Jun 2025 15:49:12 +0000
Received: by outflank-mailman (input) for mailman id 1014638;
 Fri, 13 Jun 2025 15:49: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 1uQ6eU-0006cn-Mu
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 15:49:10 +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 f16b4efe-486d-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 17:49:08 +0200 (CEST)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-ad56cbc7b07so333047666b.0
 for ; Fri, 13 Jun 2025 08:49:08 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-adec8979563sm144821766b.158.2025.06.13.08.49.06
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Jun 2025 08:49:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f16b4efe-486d-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749829748; x=1750434548; darn=lists.xenproject.org;
        h=content-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=c5Lkbfnvd1QCDHpROG9OH/otgdh2NEdBGe+vvJ9B82I=;
        b=RH39gf91ScptKdVXhMs/cSuMdSwsZjaeuaUhGzFbiVftV7BgncT20yBp3BQNsLTV5T
         oRB5FaGf5RM+PstmdZu4X4umrReWdL68TlrkwBb4XdiTu9HibJ/Y+qZdixOu5/CbKmDu
         HGmkBIYugV4OcivTzKZbYMGrikwEKzsO3doKIdgU3g2p1vMRMcWeTIKZRR7Y7j6QQtAj
         rw95i13NQjps+HFV0TFMEgbfhI/FgFzJrPeU+0yFZ/llqixf9zVr4pyig+oMq/w2w1Kn
         Hb4+j/3Efh2D6ITjHNPaFrCq0bGCJhmz+MzYuefs7jURxVL6gFZnwreILaLw+sVZaS9J
         q/eQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749829748; x=1750434548;
        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=c5Lkbfnvd1QCDHpROG9OH/otgdh2NEdBGe+vvJ9B82I=;
        b=H5oFYSMCN9jAyJd+0aefTEOW+YxjbJ7zid6/NoWusHNQm7odcDwJsw2/RQikCnMjA3
         z38RGXKsA3Cy/QHJM9HKXULApT/KXmUeJ5Xs/4LGtorBIsEvdI89OmZV+ad3m5lhFuyV
         K79p9cFa+Q32tX3W+0TdNfuCO1p2MYcY4SoA3oXrmqba5nKb7PQ514eeAS51/a10gVV2
         NSM3xbNrSq31dZYNGuIh/kwOdcJ0PCLjALL5yUy5PLjDvk8xna/8uKCmc4jiBVYfbJlN
         qxpqikfz2qosOGRp5Lu0JTm4VqoXcItLhIwNLYgJeh+ZxkknHeLutswcPaXy/K+Zyr06
         i5lg==
X-Gm-Message-State: AOJu0Yx12Z+FCJIV8H95UXIyliU5o5OEbqYhjdEC2hJTfE23KFYDm/ZU
	Kj0XIg0jcWhOSm01mour1ktjrJyAQOkXrCYLGVb69o56bX7kFj4ARIfSaMkvMg==
X-Gm-Gg: ASbGncs26o/xLEv1pbCE+oBNpOljwMCF5YoLoZtsL87+0Lz38ciqKWimlwkNs+E130k
	hidDJ5jOEjpaJMFrHjZiUCWs5p9pCnNb03v2jbkhiRVbLFadM3W9Kg1Lfba5qvGf6kBA37Q2xPb
	YWCsPRmOxUFaxMChhJ7ZFQg+iY1SOmqvDVMFuuklZVjhNn8NJ4u+5s6zc8uIbHCbwqLosRAbN2O
	pMF4JhXXvatVBm5eizfGXYh613ebsp1A6UohQ2ywNgZogHmV/xDjtnfWQLZNw0Ybflm4Oe+9r1j
	Ga/lNqdZVmQYkbBKVQgtaARhTMli1w56UN5OAOR1+G21IjB+1bHxsRBeuzBruY1e/jXIwW4KvaI
	QoBHCIxeyo6jV3qNELyZLUs/qMnhZ
X-Google-Smtp-Source: AGHT+IF4HdQ4K6/e1c/Kjg77Lf3UA4pI1sMICe8tX4U+SECyg2QF9kkXnhTQ5AC2l5A/KM2+pPXYzg==
X-Received: by 2002:a17:906:c106:b0:add:ee2c:7313 with SMTP id a640c23a62f3a-adec55a7a66mr346620266b.22.1749829747753;
        Fri, 13 Jun 2025 08:49:07 -0700 (PDT)
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 v5 9/9] xen/riscv: add basic UART support
Date: Fri, 13 Jun 2025 17:48:48 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Update Kconfig to select GENERIC_UART_INIT for basic UART init ( find a dt node
and call device specific device_init() ).

Drop `default n if RISCV` statement for config HAS_NS16550 as now ns16550 is
ready to be compiled and used by RISC-V. Also, make the config user selectable
for everyone except X86.

Initialize a minimal amount of stuff to have UART and Xen console:
 - Initialize uart by calling uart_init().
 - Initialize Xen console by calling console_init_{pre,post}irq().
 - Initialize timer and its internal lists which are used by
   init_timer() which is called by ns16550_init_postirq(); otherwise
   "Unhandled exception: Store/AMO Page Fault" occurs.
 - Enable local interrupt to recieve an input from UART

Signed-off-by: Oleksii Kurochko 
Acked-by: Jan Beulich 
---
Changes in V4-V5:
 - Nothing changed. Only rebase.
---
Changes in v3:
 - Drop inclusion of  as nothing in setup.c requires it.
 - Add Acked-by: Jan Beulich .
---
Changes in v2:
 - Drop #include  in setup.c, isn't needed anymore.
 - Drop call of percpu_init_areas() as it was needed when I used polling
   mode for UART,  for this case percpu is used to receive serial port info:
     struct serial_port *port = this_cpu(poll_port);
   So percpu isn't really needed at the current development state.
 - Make HAS_NS16550 user selectable for everyone, except X86.
 - Update the commit message.
---
 xen/arch/riscv/Kconfig   |  1 +
 xen/arch/riscv/setup.c   | 12 ++++++++++++
 xen/drivers/char/Kconfig |  3 +--
 3 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/xen/arch/riscv/Kconfig b/xen/arch/riscv/Kconfig
index 62c5b7ba34..96bef90751 100644
--- a/xen/arch/riscv/Kconfig
+++ b/xen/arch/riscv/Kconfig
@@ -2,6 +2,7 @@ config RISCV
 	def_bool y
 	select FUNCTION_ALIGNMENT_16B
 	select GENERIC_BUG_FRAME
+	select GENERIC_UART_INIT
 	select HAS_DEVICE_TREE
 	select HAS_PMAP
 	select HAS_UBSAN
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 0e7398159c..a17096bf02 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -4,12 +4,15 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -134,8 +137,17 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
 
     intc_preinit();
 
+    uart_init();
+    console_init_preirq();
+
     intc_init();
 
+    timer_init();
+
+    local_irq_enable();
+
+    console_init_postirq();
+
     printk("All set up\n");
 
     machine_halt();
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index e6e12bb413..8e49a52c73 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -2,8 +2,7 @@ config GENERIC_UART_INIT
 	bool
 
 config HAS_NS16550
-	bool "NS16550 UART driver" if ARM
-	default n if RISCV
+	bool "NS16550 UART driver" if !X86
 	default y
 	help
 	  This selects the 16550-series UART support. For most systems, say Y.
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 15:56:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 15:56:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014703.1392833 (Exim 4.92)
	(envelope-from )
	id 1uQ6ln-0005qj-R8; Fri, 13 Jun 2025 15:56:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014703.1392833; Fri, 13 Jun 2025 15:56: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 1uQ6ln-0005pW-KS; Fri, 13 Jun 2025 15:56:43 +0000
Received: by outflank-mailman (input) for mailman id 1014703;
 Fri, 13 Jun 2025 15:56: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 1uQ6lm-0005oc-T8
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 15:56:42 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ff959bc8-486e-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 17:56:42 +0200 (CEST)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-6077dea37easo4390702a12.3
 for ; Fri, 13 Jun 2025 08:56:42 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-608b4a93b03sm1357883a12.54.2025.06.13.08.56.40
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Jun 2025 08:56:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ff959bc8-486e-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749830201; x=1750435001; darn=lists.xenproject.org;
        h=content-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=nL7nARGDQ50XMu4IV0d9zQhakNWn40CT42TpoqjeEbk=;
        b=VKkf9n71rzy5QZ5/Pl5SMIC1CGvZtafJF59mRG+CRyVJPvOFzyrl3o5QxW2rUCEzWw
         T0e1B5DaoWFCCi0sN7E2dh3PPt02YHe8XI0i5Yqyx0DLDye3Z9K9piNVH7v5BF3pywCM
         vGYyvBOXOeCOhHlgA5waNlfkFHv5y0xAGHOQK4ItaoF70LuLKjNuWXsh6BXlPlP2QQcA
         9Vaf+IC7fWOOpfci7VmhAirCcNqY+mFtVeBDtdR6kuBf9XrKvC+XBfYs5BhEPUk1kb7R
         Nftn2PIVFkQheMbnXgSZJQzz86HHT/QfzWOmNNFD9a5GtGx44HttHdkj/gp6cpXeLK+z
         PgGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749830201; x=1750435001;
        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=nL7nARGDQ50XMu4IV0d9zQhakNWn40CT42TpoqjeEbk=;
        b=tqeTn3e4flAp8yQuz5I6M9E96vZwDDPIOdKFzaVmHvMlwaKph93gJJKqVFtfsPvnq4
         8SBfsKmfPnXjDa2eID2q7AVxM3ujQxOL0ayqZDKc3M/bjpeElOHoodoiG+sC4kopYqti
         zgcuJwMxwBpnDFId1O+5tAZez6y3dOVy6clfjj3WL63wiSQyuD0nKHXwf/4jKf+52oEA
         JvUpSTHoq0Vzvk1C5chF4wQ9jHu4j+dXaPF37U1poziIwu5RkCuFjrszO1eNJGUIomSe
         BWF34VSy0MKCosgV/UsmWDG4UhsLskahZO0xgwz24oIq2+0gKu6p+MScY6Zc0zDwxgpy
         TyBw==
X-Gm-Message-State: AOJu0Yz0cyiXTVlv+3pG8RIOqQEpZKqFkdtJwZYNw2aUngcyqirbAR3c
	0RPv7s190qMuXSfSGQZLx5lFaueg1mzsvIQmjB4LqpD8NeLJjMmYNYtzFBXR7Q==
X-Gm-Gg: ASbGncuLd0cbmVBPhiL5ZauKg4i1fmfWKB6lNfCx0jbZqNixMdse/Uol0dVw5m1y1J1
	lxWI15DbdIYavao5mSV2hMBgSQdlvtgxW4F1tn1fz8wBx72BgSHsIO6cqNKA+5zpzsfNYehXUUh
	y79n/Ba9pQOW/DFI/ZHCJ0dHi5dbkLmcoU2fGT36zI/7MEpgn1G+0kqWCzKz+pO3sDgY0nuYIzh
	3qvTac6rSQrwuKaYphIV4YL7qFWpXUshv+AILooc6m/6cx9pa2bhfj8IYJg/W+u+8jn6V9kzT2p
	gCkmSjaRHFVxiLSvJdgbFEDYNc9MIv9rxurtfvs+WaqTfB+Vuiezwk76Tod8m9erzUa8iVjb9v9
	qzJyvFMKq33qcxsE6xe3w+1HXM6xH
X-Google-Smtp-Source: AGHT+IEgsfiFu8C5E+JUWbofGE4zlzEgehEqBX2LkqAdmeSZ5GBYRlpFEgsuZe194HQ+AG85Yu9H9A==
X-Received: by 2002:a05:6402:d08:b0:604:e6fb:e2e1 with SMTP id 4fb4d7f45d1cf-608b4a92b52mr3295769a12.33.1749830201206;
        Fri, 13 Jun 2025 08:56:41 -0700 (PDT)
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 v1 1/2] xen/riscv: rework asm/mm.h and asm/page.h includes to match other architectures
Date: Fri, 13 Jun 2025 17:56:35 +0200
Message-ID: <42696025e262f50ee7d26b252bfe3d3c0a9c77e6.1749829230.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

To align with other architectures where  is included from 
(and not the other way around), the following changes are made:
- Since  is no longer included in :
  - Move the definitions of paddr_to_pte() and pte_to_paddr() to ,
    as paddr_to_pfn() and pte_to_paddr() are already defined there.
  - Move _vmap_to_mfn() to  because mfn_from_pte() is defined there and
    open-code it inside macros vmap_to_mfn().
- Drop the inclusion of  from  to resolve a compilation error:
    ./include/xen/domain_page.h:63:12: error: implicit declaration of function '__mfn_to_virt'; did you mean 'mfn_to_nid'? [-Werror=implicit-function-declaration]
       63 |     return __mfn_to_virt(mfn_x(mfn));
  This happens because __mfn_to_virt() is defined in , but due to
  the current include chain:
    
      
        
          
            
              
                static inline void *map_domain_page_global(mfn_t mfn)
		{
		    return __mfn_to_virt(mfn_x(mfn));
                }
            ...
          ...
          #define __mfn_to_virt() ...

  This leads to a circular dependency and the build error above.

  As a result, since  is no longer included in
  , the flush_page_to_ram() definition cannot remain there.
  It is now moved to riscv/mm.c.

Including  from  does not cause issues with the
declaration/definition of clear_page() when  is included, and
also prevents build errors such as:
  common/domain.c: In function 'alloc_domain_struct':
  common/domain.c:797:5: error: implicit declaration of function 'clear_page';did you mean 'steal_page'? [-Werror=implicit-function-declaration]
  797 |     clear_page(d);
      |     ^~~~~~~~~~
      |     steal_page
caused by using clear_page() in common/domain.c.

Signed-off-by: Oleksii Kurochko 
---
 xen/arch/riscv/include/asm/mm.h   | 24 ++++++++++++++++++---
 xen/arch/riscv/include/asm/page.h | 35 +------------------------------
 xen/arch/riscv/mm.c               | 14 +++++++++++++
 3 files changed, 36 insertions(+), 37 deletions(-)

diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
index 01bbd92a06..9283616c02 100644
--- a/xen/arch/riscv/include/asm/mm.h
+++ b/xen/arch/riscv/include/asm/mm.h
@@ -12,6 +12,7 @@
 #include 
 #include 
 
+#include 
 #include 
 
 extern vaddr_t directmap_virt_start;
@@ -19,11 +20,21 @@ extern vaddr_t directmap_virt_start;
 #define pfn_to_paddr(pfn) ((paddr_t)(pfn) << PAGE_SHIFT)
 #define paddr_to_pfn(pa)  ((unsigned long)((pa) >> PAGE_SHIFT))
 
+static inline pte_t paddr_to_pte(paddr_t paddr,
+                                 unsigned int permissions)
+{
+    return (pte_t) { .pte = (paddr_to_pfn(paddr) << PTE_PPN_SHIFT) | permissions };
+}
+
+static inline paddr_t pte_to_paddr(pte_t pte)
+{
+    return pfn_to_paddr(pte.pte >> PTE_PPN_SHIFT);
+}
+
 #define gfn_to_gaddr(gfn)   pfn_to_paddr(gfn_x(gfn))
 #define gaddr_to_gfn(ga)    _gfn(paddr_to_pfn(ga))
 #define mfn_to_maddr(mfn)   pfn_to_paddr(mfn_x(mfn))
 #define maddr_to_mfn(ma)    _mfn(paddr_to_pfn(ma))
-#define vmap_to_mfn(va)     _vmap_to_mfn((vaddr_t)(va))
 #define vmap_to_page(va)    mfn_to_page(vmap_to_mfn(va))
 
 static inline void *maddr_to_virt(paddr_t ma)
@@ -35,6 +46,15 @@ static inline void *maddr_to_virt(paddr_t ma)
     return (void *)va;
 }
 
+#define mfn_from_pte(pte) maddr_to_mfn(pte_to_paddr(pte))
+
+#define vmap_to_mfn(va)                             \
+({                                                  \
+    pte_t __entry = pt_walk((vaddr_t)(va), NULL);   \
+    BUG_ON(!pte_is_mapping(__entry));               \
+    maddr_to_mfn(pte_to_paddr(__entry));            \
+})
+
 /*
  * virt_to_maddr() is expected to work with virtual addresses from either
  * the directmap region or Xen's linkage (XEN_VIRT_START) region.
@@ -76,8 +96,6 @@ static inline unsigned long virt_to_maddr(unsigned long va)
 #define virt_to_mfn(va)     __virt_to_mfn(va)
 #define mfn_to_virt(mfn)    __mfn_to_virt(mfn)
 
-#define mfn_from_pte(pte) maddr_to_mfn(pte_to_paddr(pte))
-
 struct page_info
 {
     /* Each frame can be threaded onto a doubly-linked list. */
diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h
index 4cb0179648..0684229790 100644
--- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -7,12 +7,10 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 
 #include 
-#include 
 #include 
 
 #define VPN_MASK                    (PAGETABLE_ENTRIES - 1UL)
@@ -114,17 +112,6 @@ typedef struct {
 #endif
 } pte_t;
 
-static inline pte_t paddr_to_pte(paddr_t paddr,
-                                 unsigned int permissions)
-{
-    return (pte_t) { .pte = (paddr_to_pfn(paddr) << PTE_PPN_SHIFT) | permissions };
-}
-
-static inline paddr_t pte_to_paddr(pte_t pte)
-{
-    return pfn_to_paddr(pte.pte >> PTE_PPN_SHIFT);
-}
-
 static inline bool pte_is_valid(pte_t p)
 {
     return p.pte & PTE_VALID;
@@ -198,18 +185,7 @@ 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)
 
-static inline void flush_page_to_ram(unsigned long mfn, bool sync_icache)
-{
-    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();
-}
+void flush_page_to_ram(unsigned long mfn, bool sync_icache);
 
 /* Write a pagetable entry. */
 static inline void write_pte(pte_t *p, pte_t pte)
@@ -231,15 +207,6 @@ static inline pte_t pte_from_mfn(mfn_t mfn, pte_attr_t flags)
 
 pte_t pt_walk(vaddr_t va, unsigned int *pte_level);
 
-static inline mfn_t _vmap_to_mfn(vaddr_t va)
-{
-    pte_t entry = pt_walk(va, NULL);
-
-    BUG_ON(!pte_is_mapping(entry));
-
-    return mfn_from_pte(entry);
-}
-
 #endif /* __ASSEMBLY__ */
 
 #endif /* ASM__RISCV__PAGE_H */
diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
index 4047d67c0e..774ea42f2d 100644
--- a/xen/arch/riscv/mm.c
+++ b/xen/arch/riscv/mm.c
@@ -3,6 +3,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -613,3 +614,16 @@ void __iomem *ioremap(paddr_t pa, size_t len)
 {
     return ioremap_attr(pa, len, PAGE_HYPERVISOR_NOCACHE);
 }
+
+void flush_page_to_ram(unsigned long mfn, bool sync_icache)
+{
+    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();
+}
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 15:56:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 15:56:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014702.1392827 (Exim 4.92)
	(envelope-from )
	id 1uQ6ln-0005ou-Id; Fri, 13 Jun 2025 15:56:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014702.1392827; Fri, 13 Jun 2025 15:56: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 1uQ6ln-0005on-Do; Fri, 13 Jun 2025 15:56:43 +0000
Received: by outflank-mailman (input) for mailman id 1014702;
 Fri, 13 Jun 2025 15:56: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 1uQ6lm-0005oc-Lz
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 15:56:42 +0000
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [2a00:1450:4864:20::531])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fef99832-486e-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 17:56:41 +0200 (CEST)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-606b6dbe316so4672433a12.3
 for ; Fri, 13 Jun 2025 08:56:41 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-608b4a93b03sm1357883a12.54.2025.06.13.08.56.39
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Jun 2025 08:56:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fef99832-486e-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749830200; x=1750435000; 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=YyES95+A2ACc3qewE69Vib3M9QUPkJE2MYtSgOXVrNA=;
        b=RnCUAbA9ofoFdYQ/aqpP8NsBhTtFKRz4Vg/fxoY9y/WLoK8XkvfOEBIm10NH6UKSdU
         SLG4yotYE2RYcpMa0sYSlhz3+Fm7kuP+gw0FAtctcAqhMM8pf7a7J8sESuU2aruDn9RQ
         6q9i2U4L1ndcfUDjexGfv8pE96Btr+9Dy+/eitVYHBKRV6/YfsAxSJEcVIpISh/bQ9xA
         i/PeY3ayzt1mtThKaEQbgclvCMuKd9tVbjoL/ahZow2WJ6uh6qoU4smbuC58z/Mnsbp2
         Ev89kcBLa8/QNS0bmv6zZu5tuGYdtHjSPcDHC+FbbVdgGoUTtT9YBhMK7FKunUpFPnhC
         42cg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749830200; x=1750435000;
        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=YyES95+A2ACc3qewE69Vib3M9QUPkJE2MYtSgOXVrNA=;
        b=BjTmkc/6NgBkpwNtfX7JkuRCivib3LUeKNg5Fbqrnuo3CsjvRUTY/IjQROlDGP9+10
         dEqI4JDIx5ESML4zj/3XAH1TTi455D6BUlW6o1+BJaHuPZNHsxUhXGx99jCXGNEbn0KJ
         0PvmoibkkVb2Kg8PBynCWcFPv09EsIVcVZJ2ISRhO0Z6BuIlRUIK4QeddH9YE8QJBfyy
         Ce156VRWmFWFxZ5klASVI7ffbIbxBdXMlFP2kZzBGBt0tlSUx7nhAtB04Xrc3y8ydOnt
         kRcB23f28xHkGAPaowQdcL1bHnyHw+6gNc1NDi0M+V0pSUm3+m6OhS/IN2dBmMsio32P
         nU/Q==
X-Gm-Message-State: AOJu0Yz8+xBmvQQad1JUtHb6GU94ZboUAgl5hI6vP6v1U2Yrd5YhIyAt
	MQx/51EvBKOHAin06pofwfLPpeZqlJxu+3Tx8KyK67C/UXeK08LtC3p+U1Jzvg==
X-Gm-Gg: ASbGncsyaWGQh9ufOmJLY7zkGGgEfQB+uIkBltRn1/IttK841zMB8kYboZy+fYhL4fD
	kj1tginzrqYrzurzx2af2L5NcXiyd80sFiTYo+ic4Ls6Q7tPL+nALVWoBASDZSfrBCgo8GAW1AP
	tnc2rMATOJXNBslSq+h7xuEKqZHf0UFirOz64jKjLES4AjeOFw1n23Qn+LpwsP2nzcpL4QCXGBH
	JTo40X0I6s1bvmUPxGc3vXWgTGaAZ9TC7xweqlq4jwQNq8JgY0DuuFDqJJfuRuPaAjEeiBJ2FUa
	fJ8JZEjVRKuiUcN6HrpWK9Nkppu/9Iv5gRVn9JzaJjJpLo0z1wkZWBKp7FH+Is5WrNGZ3oRakbX
	JQNsCO0+iX7WIBB/7k9G/9SEGplMYjNufj/SSs9s=
X-Google-Smtp-Source: AGHT+IEeV7ubfWODFOomRDVTltfDUbrjxPK/Rf+OVXFMo/Jx7FNTISHgk5rugXobGlpvgFlbMs06JA==
X-Received: by 2002:a05:6402:50cd:b0:607:5987:5ba1 with SMTP id 4fb4d7f45d1cf-608b498986bmr3265084a12.20.1749830200125;
        Fri, 13 Jun 2025 08:56:40 -0700 (PDT)
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 ,
	Bertrand Marquis ,
	Volodymyr Babchuk ,
	Shawn Anastasio 
Subject: [PATCH v1 0/2] Move alloc_domain_struct() to common code
Date: Fri, 13 Jun 2025 17:56:34 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

x86 has specific requirements about the allocation of the domain structure,
but that's not the case for ARM or likely other architectures.

Introduce a generic weak function that can be overwritten with an
architecture specific implementation if required.

RISC-V has a compilation issue [1] after an introduction of [2] becuase of
different way inclusion of asm/page.h and asm/mm.h (for more details please
check the patch [3]).
So rework asm/mm.h and asm/page.h includes to match other architectures.

[1] https://gitlab.com/xen-project/people/royger/xen/-/jobs/10328429719#L553
[2] xen/domain: introduce generic weak function for domain struct allocation
[3] xen/riscv: rework asm/mm.h and asm/page.h includes to match other architectures

CI tests:
  https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/1868877289

Oleksii Kurochko (1):
  xen/riscv: rework asm/mm.h and asm/page.h includes to match other
    architectures

Roger Pau Monne (1):
  xen/domain: introduce generic weak function for domain struct
    allocation

 xen/arch/arm/domain.c             | 12 -----------
 xen/arch/ppc/stubs.c              |  5 -----
 xen/arch/riscv/include/asm/mm.h   | 24 ++++++++++++++++++---
 xen/arch/riscv/include/asm/page.h | 35 +------------------------------
 xen/arch/riscv/mm.c               | 14 +++++++++++++
 xen/arch/riscv/stubs.c            |  5 -----
 xen/common/domain.c               | 14 +++++++++++++
 7 files changed, 50 insertions(+), 59 deletions(-)

-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 15:56:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 15:56:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014704.1392846 (Exim 4.92)
	(envelope-from )
	id 1uQ6lr-0006IS-5f; Fri, 13 Jun 2025 15:56:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014704.1392846; Fri, 13 Jun 2025 15:56:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uQ6lr-0006IL-2r; Fri, 13 Jun 2025 15:56:47 +0000
Received: by outflank-mailman (input) for mailman id 1014704;
 Fri, 13 Jun 2025 15:56: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 1uQ6lp-0006Ge-Kq
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 15:56:45 +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 008a3eab-486f-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 17:56:43 +0200 (CEST)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-607ec30df2bso4227443a12.1
 for ; Fri, 13 Jun 2025 08:56:43 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-608b4a93b03sm1357883a12.54.2025.06.13.08.56.41
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Jun 2025 08:56:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 008a3eab-486f-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749830203; x=1750435003; darn=lists.xenproject.org;
        h=content-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=tBkHTslrkdQm/XhjgO6ug1lELXFf148eDSnYyMvV87A=;
        b=XvFGKq4hQFNfH2ERKQ/n6wKCv0tI23/f39vtPWWMEvFI1oouE9o1ANFSe2zTVusGv3
         eEtEKLaaRPVWxooHNECO8EORUlscIing/JDUso/WN0HR1z9yT/ycDCVeuuJZqbiqm0zq
         GUZn4VM1nFJLPpC3p5QvvLGnJrO/Hqm7k+ZEnrKU4pbR/Q/yxl+y1MtgrkhVQ4up+D6y
         oyL7JF/pMPw8Eeqk4jEhyU4hfo4J7NXZxvYSOu2ldMJL6cAevUYlhLhhAXKz1MzxRJ72
         oKnW70A0yXPUcr+1y68GQm60EsaohN6iRLbVNs8R5qlURigMep6usX6XSJpP7EzOfOdi
         rXUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749830203; x=1750435003;
        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=tBkHTslrkdQm/XhjgO6ug1lELXFf148eDSnYyMvV87A=;
        b=M9+vEbldGzvXouvA35EWiUYULjipcZvdKtEe9yymJMPenJJqKULJ4Fh++1SCA1gH9x
         hhxDZK0ImdOLxB3tCmDrpdrxfWdHKebW4NtruR084044esh08E/z9xDO8esh9aWyWSxv
         ACpyL/uYuslDCn4/H9Z9QzAJyjENGRX+Gy6cIqunqsS95HkOh3exVyr4z26RJ74kvTd7
         K+Uj10pzKA9E/DHHNjF6jDoCjog9EMU1xomWV3TxzzB9LUiOgW11vw0Ak3icpXqegJtU
         MkY0nq4QQ9ThD1xI8p1e23ygJUMp40871ESh1sdXXeEKpxaF3gpqjyii90xnz2Ex47Nf
         QDXQ==
X-Gm-Message-State: AOJu0YxkbvvChJCsh9kZpj90TlCLbN2UgTfATU5opcGpT9bHO8deP7Jp
	nvElBEzuj5DL7GxVmijtR88cGfTKyn906SOX731X/g/fQedM8nKFPl7o65F5Xw==
X-Gm-Gg: ASbGncsgYsDNKysDJHLe4ACUtnfmuWGoqycafKbm8FlL/AQndEELK8p3LihRlmuUL19
	9kfRC8cT31qIFMcBOIQulPNgqf1gxs7Efwlg93ywjbIvMbDGxZf8kuos+aqFhqylR0V0f/ExwdF
	E6QrqoWE3QBpX0gnYd2HJ5ThgL1Fy02kfddVE62y3ixWBskN7tjdMOAktkOouiKVqTRwmOVaFrS
	KlSaUMehTLR8llL8e2LwEgGqSP6dp/H8CRcn0d1orPRI9dgC9s0JXLnz+g2bMxeFbXu4mlAfRwt
	emOzE8AJUr+Hoca19saWZMk2nf2AYBsZ8wDEik9x61MMJMVMyajDrsmOfzlMTE0csoo+2LKf8sy
	onI0Fwhpk52MrV60hVZ9hJ2OWIcZt
X-Google-Smtp-Source: AGHT+IFc/KLR1BzJIRacmaOsU4mrBKrO7Fs3Y8ikB2f0saA3ZsckBb22OGO4cGnpnPlrkqrMJxQHFw==
X-Received: by 2002:a05:6402:270d:b0:607:7aed:feef with SMTP id 4fb4d7f45d1cf-608b49fc0aamr3189540a12.34.1749830202560;
        Fri, 13 Jun 2025 08:56:42 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Andrew Cooper ,
	Anthony PERARD ,
	Jan Beulich ,
	Shawn Anastasio ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Oleksii Kurochko 
Subject: [PATCH v1 2/2] xen/domain: introduce generic weak function for domain struct allocation
Date: Fri, 13 Jun 2025 17:56:36 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Roger Pau Monne 

x86 has specific requirements about the allocation of the domain structure,
but that's not the case for ARM or likely other architectures.

Introduce a generic weak function that can be overwritten with an
architecture specific implementation if required.

No functional change intended.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Oleksii Kurochko 
---
Changes:
 - Add Reviewed-by: Oleksii Kurochko .
 - Add empty line before last return in alloc_domain_struct().
---
 xen/arch/arm/domain.c  | 12 ------------
 xen/arch/ppc/stubs.c   |  5 -----
 xen/arch/riscv/stubs.c |  5 -----
 xen/common/domain.c    | 14 ++++++++++++++
 4 files changed, 14 insertions(+), 22 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 45aeb8bddc..29588f869c 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -479,18 +479,6 @@ void startup_cpu_idle_loop(void)
     reset_stack_and_jump(idle_loop);
 }
 
-struct domain *alloc_domain_struct(void)
-{
-    struct domain *d;
-    BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
-    d = alloc_xenheap_pages(0, 0);
-    if ( d == NULL )
-        return NULL;
-
-    clear_page(d);
-    return d;
-}
-
 void free_domain_struct(struct domain *d)
 {
     free_xenheap_page(d);
diff --git a/xen/arch/ppc/stubs.c b/xen/arch/ppc/stubs.c
index 671e71aa0a..d999d22718 100644
--- a/xen/arch/ppc/stubs.c
+++ b/xen/arch/ppc/stubs.c
@@ -294,11 +294,6 @@ void vcpu_kick(struct vcpu *v)
     BUG_ON("unimplemented");
 }
 
-struct domain *alloc_domain_struct(void)
-{
-    BUG_ON("unimplemented");
-}
-
 struct vcpu *alloc_vcpu_struct(const struct domain *d)
 {
     BUG_ON("unimplemented");
diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c
index e396b67cd3..155e5a7f58 100644
--- a/xen/arch/riscv/stubs.c
+++ b/xen/arch/riscv/stubs.c
@@ -268,11 +268,6 @@ void vcpu_kick(struct vcpu *v)
     BUG_ON("unimplemented");
 }
 
-struct domain *alloc_domain_struct(void)
-{
-    BUG_ON("unimplemented");
-}
-
 struct vcpu *alloc_vcpu_struct(const struct domain *d)
 {
     BUG_ON("unimplemented");
diff --git a/xen/common/domain.c b/xen/common/domain.c
index e566a18747..c134868e95 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -785,6 +785,20 @@ static int sanitise_domain_config(struct xen_domctl_createdomain *config)
     return arch_sanitise_domain_config(config);
 }
 
+struct domain *__weak alloc_domain_struct(void)
+{
+    struct domain *d = alloc_xenheap_pages(0, 0);
+
+    BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
+
+    if ( !d )
+        return NULL;
+
+    clear_page(d);
+
+    return d;
+}
+
 struct domain *domain_create(domid_t domid,
                              struct xen_domctl_createdomain *config,
                              unsigned int flags)
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 13 16:03:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 16:03:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014725.1392857 (Exim 4.92)
	(envelope-from )
	id 1uQ6sP-0001GW-RL; Fri, 13 Jun 2025 16:03:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014725.1392857; Fri, 13 Jun 2025 16:03:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uQ6sP-0001GP-OR; Fri, 13 Jun 2025 16:03:33 +0000
Received: by outflank-mailman (input) for mailman id 1014725;
 Fri, 13 Jun 2025 16:03: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 1uQ6sO-0001GJ-0v
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 16:03:32 +0000
Received: from MRWPR03CU001.outbound.protection.outlook.com
 (mail-francesouthazlp170110003.outbound.protection.outlook.com
 [2a01:111:f403:c207::3])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f2698d79-486f-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 18:03:29 +0200 (CEST)
Received: from PA7P264CA0102.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:348::7)
 by PA4PR08MB6317.eurprd08.prod.outlook.com (2603:10a6:102:ec::11) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.24; Fri, 13 Jun
 2025 16:03:23 +0000
Received: from AM3PEPF0000A794.eurprd04.prod.outlook.com
 (2603:10a6:102:348:cafe::5b) by PA7P264CA0102.outlook.office365.com
 (2603:10a6:102:348::7) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.25 via Frontend Transport; Fri,
 13 Jun 2025 16:03:23 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 AM3PEPF0000A794.mail.protection.outlook.com (10.167.16.123) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.15
 via Frontend Transport; Fri, 13 Jun 2025 16:03:21 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com (2603:10a6:5:1c::25) by
 GV1PR08MB8713.eurprd08.prod.outlook.com (2603:10a6:150:82::13) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8835.22; Fri, 13 Jun 2025 16:02:47 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668]) by DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668%2]) with mapi id 15.20.8813.024; Fri, 13 Jun 2025
 16:02:47 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f2698d79-486f-11f0-b894-0df219b8e170
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=kkjOE2bKBeqaHQ86QSNfqIsAN+3bRR6zQcVpEI3GY6YkyelgYpaCcLyHCiYu1a+a8f84x135p5TLsXnOvEHQXuUxJqY2OukMhtiTudqYFxY4x5herNpTxmzKvKSKpUP/piS450YNlN2B4Q2Ww+Qq5FMVBc0yscLXZBPf324O+ynYX2P2JWVYPMTiLa18j06a8b5mmzFURuEoSPFfQNbq6ywLJQSfKJMrhUh3D/DNDW1ymluCIzsPdRumPcqVN1jZXNCdM7jo7KLgzWoDrir+D+GW+N+SKNAX3/42NJwL+YMwCmmzDlpQm6uAjfQ4ADHCTsPwKaveZHzU1pQCt9Dk7Q==
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=bDfV0u8Eafmo9ei8VEj30qjkRx0hMlGH8nNCQ9kbEqQ=;
 b=hM04L6fcO21LhKCVkRkoZb/4nbSyKZSvX4yTtLUdS+QFyqUmgq3Cg3mSVKyNoC6ICcnKiiM/GAsHgrcYxbsGhxAWiHByGEWL+2cxxY0TWQKgOyNc9pEshUgjaggV3vgUZLrmxbCzNJvhSfhnYRStbECGtX/LwLEk2fkXt5rlwlgPoitOfq8PAuXKkb6ntJoT2ousgzhYAsBTICOO+fIfjxyVnx/KK0JOpAGYxooUQjLDcInXwhyC5KAcXokxfeJ4DT6YNukEG+rtXttL6VG++13wxmv4kITv9szbjhsN53xHTbePX62A/f76p92f8sP4jPPHbQEseEVB/Ou3p9/ztg==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=amd.com smtp.mailfrom=arm.com; dmarc=pass
 (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
 (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=bDfV0u8Eafmo9ei8VEj30qjkRx0hMlGH8nNCQ9kbEqQ=;
 b=FTRPr59ebEhQM/74jZjZRfR/T/wxwOMXei3XzVCaPQN5QW/VEIDYPxJKFwuqHd8qkSbNrfe1p4Y5jc+Q6fAGR7RC0Dur7RAm+90jMf+6RvZP55FzQVgRLXt+Z2t0mEYVvnViQRTo1tgRDDm2OKy/kODog5I22X/KfE46jMlBtFo=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=nb562gC+LyiOswMRvWZEp74mhQ8XlCiHCOeaXewJvW1wxdlQeCom8qNp5LU0hUF5/KYEH8MtpDFcGYenIR6CjQiCVAv5g4bXMD+esFcT++zZGvRz1rTm9Oi2clcXx82zItjemILQVjI98F+Fjw393vWWPuMuM20oFbIIZxaGerjVmJfvPzBsd+gluSHy1EdynyQQZF21iAS+Ujao5PFORyK3VgqIuU+Vn4YLrsLHCaIGTfVjtQx2CYo/V2mOJLFRXtZIpWaQe5vhKxRPYMeFil2yaCvmWp+6neLtG9y77myvKqD3W1UjnJEbZcwPlfGlbIiv5J4fivvCPxhdPsCJHQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=bDfV0u8Eafmo9ei8VEj30qjkRx0hMlGH8nNCQ9kbEqQ=;
 b=AL6eLy2JF5i9Mlhz4v8mAsnzaWRQsrF9+4WO/I4Ij5klRsQHlIi+UHc1GFC09FvvYZK5CFwCnU4wo2sFTv0rOsvRCrIrVM/9MUdhb9Ip6P8SAlA3xZZSe3bUktj7yuaN1/LdUTgRKFaWpugH4LWEEpDYAJg5vfnZu0eWI6rH1tbvkpz0b+CZgaSiHR/Wf7Mz93z4I+ivYhtDS2dYGYHojy3o+ZtLRCrLwmwFkYvnHELa3p6MpA5C702B02ZeYzZHZG5G/kWLeFUmYJ2ZKisLeMjM7Z4A2tmrdgly9GHNwSvi6ef432JwOHNUox051sFALOioGpA1gneB9HRkpHFYvA==
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=bDfV0u8Eafmo9ei8VEj30qjkRx0hMlGH8nNCQ9kbEqQ=;
 b=FTRPr59ebEhQM/74jZjZRfR/T/wxwOMXei3XzVCaPQN5QW/VEIDYPxJKFwuqHd8qkSbNrfe1p4Y5jc+Q6fAGR7RC0Dur7RAm+90jMf+6RvZP55FzQVgRLXt+Z2t0mEYVvnViQRTo1tgRDDm2OKy/kODog5I22X/KfE46jMlBtFo=
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 v3 6/6] arm/mpu: Enable read/write to protection regions
 for arm32
Thread-Topic: [PATCH v3 6/6] arm/mpu: Enable read/write to protection regions
 for arm32
Thread-Index: AQHb2t7jddptbtJu60em4gEBgB1jlLQBQ1SA
Date: Fri, 13 Jun 2025 16:02:47 +0000
Message-ID: 
References: <20250611143544.3453532-1-ayan.kumar.halder@amd.com>
 <20250611143544.3453532-7-ayan.kumar.halder@amd.com>
In-Reply-To: <20250611143544.3453532-7-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.600.51.1.1)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB7PR08MB2987:EE_|GV1PR08MB8713:EE_|AM3PEPF0000A794:EE_|PA4PR08MB6317:EE_
X-MS-Office365-Filtering-Correlation-Id: 16fa992f-ccec-422b-6fd0-08ddaa93d1ce
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:
 =?utf-8?B?MlVMcTUwK29uWjhxWVNzeDdIcDZNdU8wbDJlb1pzY2Q4NGlSUlYvQTlEenI5?=
 =?utf-8?B?ZjRFb2RYL2JLSEVzN09qQ0lnbUR0aWtUVmVTYzFkZVU4bkdWTlFYV01jZGdW?=
 =?utf-8?B?N1duMmtpU0h4bG5XN1YwT0lYYXBwZHoxSGhHNVpxYS95SXZCbWwyZmFqSDZh?=
 =?utf-8?B?eWxCSlhORHVrZ0llZkk5RHVJMXh2NXNkbk93RmhpSUVlZ3pnQ1BvMVJnUnpY?=
 =?utf-8?B?YkVVR0N1RUN5Y25hdHJGbFVHZXBWTFMvYmJzWjVMZ2lTejYyZmhYTm5wSlp6?=
 =?utf-8?B?KzNKbm51azA5QnZHTlRremxPTWhKdjd6aXA1dVM4bERPSTBFZlpFa2c2Yk9y?=
 =?utf-8?B?VWhaVE1GcmFGVVFMaDZ3MXk4azgycEF0UFpvMC9PT0MxK0FHeFZsUElIbmRN?=
 =?utf-8?B?WDhFY1pUcGxSZzZnNml4Q3dZK294R0NaajRCRFcyK0YvSkVXbXB0cEl2c0py?=
 =?utf-8?B?aS9OdlU1eWZiQklaVFdXYnQwNU5hbnY4Zm90UzdrU1ZWVFFuUXdjTWo2UnpL?=
 =?utf-8?B?RVVLWnhZeEJ4ejFvQ01ocmVoMWxTYXBVZjRHaEx0Y2ZuY1Bhb3docXhEcjAr?=
 =?utf-8?B?MUo5alJaK0hmSzJ2cFMwRW4weWlCVytudE9qclBwdjBsZ1ExSk9GOFZ3dE1q?=
 =?utf-8?B?b1hqclVkc2RqZ1k1VS9rejBlSGdheEwraitRdE1HbEFlMXREMDAzUjVrMzha?=
 =?utf-8?B?RzBuTzBZVFBpYmdXT2hVOHdQZXNiVExKSzVkRmdrYXJaRHZ0NlVoTlVxZVJv?=
 =?utf-8?B?SklScXBJck80UHpuVks4aE1abmJ5MnE0TER6eThtOXFZNjkwL3hOQUE4Mll4?=
 =?utf-8?B?dzRmWWxxRTNSL0s0ckNmMHFPUTVQK25wVnU4YXF2dmozTWtUZ0hrUndQSElE?=
 =?utf-8?B?V042NHJaMVQxV0pBc2lPSHJVYXdEWnFyd01QdzJRTWFJSmhPYWZic3RWdU5j?=
 =?utf-8?B?OHhzaHJYNTZ2bWVzeHhiM01qcS9Semc3YjBpeWJVbUExRENNc2ppckk0MUd2?=
 =?utf-8?B?WjNYdjFSSTF5SkxXR05wRkQ2eUFxSk5Ub2ppR0pkdzMrbnlhUWJaQVV5cjBC?=
 =?utf-8?B?MjZ0aStNTkExZHVLV1hQd1pWZDM2bytUT0tscXYrSlVVWW5HejBJK2hab0Ez?=
 =?utf-8?B?NENvVEllZzZ1UmhYbGtsTHpZTHp4amJHWDhtbVJrUEtDNFlwdkpHSVFMY0M4?=
 =?utf-8?B?bnkxUTZrem90TGxOOVdxOHNBNDFMWTRQVWcxY05Tb2JKS2o3TjFEMjM0NHpF?=
 =?utf-8?B?MWNkUUxoelYvOFQrczlmZGxSbHNDekJDM0x3N1ppRlhlQmw3TVdQYnZUa2FH?=
 =?utf-8?B?RnpkMHE0Y0dhODdCajNBWG5vdlVvRi9LZEtWOFJ2ZVk0SENoU1d1azhMVGNm?=
 =?utf-8?B?azJzQVZVWEF1ZU9CQzRlVFJFeWEvYnRrcWlPODVaeEk4M3lLc2xoQURXZjIr?=
 =?utf-8?B?RGJMcUtoeG9yV0piWkJ3OEx1c2hzQjJEdEdiSExZeHpYUFVtTm9LVGtGeGk1?=
 =?utf-8?B?cVVKa0w2U29zejA4Y3Y1S2Rzdk4vMkN3b3lmaFRDRjZ2V0NFMVJEc3B5UFZQ?=
 =?utf-8?B?Q2xrcHlTdG02enZwNmJjSE50OTVzOUJPMStXOXM3aGpWZzI1U0M0aW43cUd5?=
 =?utf-8?B?YkhKOTFyTWFSZFFRcGlYRHRpRnA4UFV2T2JqVWM1Sm0renUzNVNSdXlrYXhX?=
 =?utf-8?B?SzdpNFZwUVRZUWxVSmR4SnBBeHd4TFl3T2doOTJqSW94bGsvRERiYUVqK1ZQ?=
 =?utf-8?B?VE5Ra0FOZk8zYUFZYlA3VjFiOWNuUUx2R29lTlJWdnR1VjhhS3hoQVdTeEhs?=
 =?utf-8?B?K3dIcmpUM3dJNHM3Z0RBOXZrdlRRVnFKSDFTWGc3c2xCR1dsaXBSU2RqZXRl?=
 =?utf-8?B?V1ZmUWdndjJVVnI2enFFeHBsN3BhdkRXaHI0dmo1WExVNC9KSjFyVFJTb0hR?=
 =?utf-8?B?em1VbVBEY3FTcFpKWmlleHRqc012d0dNTDNIWGRDRUhhUU02WDVRNUJScHZR?=
 =?utf-8?B?REZURml1dXp3PT0=?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB7PR08MB2987.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(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: GV1PR08MB8713
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AM3PEPF0000A794.eurprd04.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	14a65efe-b9e4-4658-8199-08ddaa93bdc4
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|14060799003|35042699022|1800799024|82310400026|376014|36860700013|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?TFdIMG9CaXB4Q3YvQ3RCQm1IeGVuZmR0N2UwNXhCWXlTMVQ3NkFOMU1sb3RQ?=
 =?utf-8?B?ZGFIRW0wR092S3VhdGI5WTdrUVg5cmdmWEVEeEd1SG83NkM3bytJZ3hjNWdm?=
 =?utf-8?B?L3R1VjhudzEwR3pzS3dBOWt6VElqMlZ4c0NWYlh5Sm1nSTg2QUh5YzQ5aExM?=
 =?utf-8?B?c0RVVDFlWm8xcVNKZUVmQTNGUS81VDNXSXFBazZMaVRFZzNTTStDNUxpYmor?=
 =?utf-8?B?byt4Y0FWUTZvYnhlVzdqNk1qNmt5d2tJeTRyRnNSN0ZIU1VwRkZzRWcrd1R0?=
 =?utf-8?B?ZUZsaThHT2VYTVhpUmxNMTdkaHo3UkdubzJsNk9uWXI5SjY3VXpPdkxaOWdP?=
 =?utf-8?B?b1IvSTlDdldibVZOMTVEc09MckdlQ3BEODkyRytHQ2tGU1pMYVQ1YmdPdS9R?=
 =?utf-8?B?Sng1Zm9JWjZTU1lKMzFPZ25pQ3E0bWY3aEtEZmZkdXpOa2FpcVpBMiszcGp1?=
 =?utf-8?B?ODRtMmxINGpVdTNZWUg3VlVGVjM4S000RmV0N1R6YktsSXJvb3NWVXRKSkw2?=
 =?utf-8?B?ekxoUDJ3bUFxZFZhd3RVWUVoRzFMK0tlM3plVWphKzhxa1ljVmFSd3NnYXJI?=
 =?utf-8?B?SUZtZzQ3R216VU9mdklTdGNwUVNzSGVDOGJDQlBFU1YrdmF1b0d1UE43VmtI?=
 =?utf-8?B?TGVldmoxK09waDZXcGRxTm5FV2FjMXFTb0dIWHZLdlZxSE9IYzVFVmdXbDln?=
 =?utf-8?B?cExQWmZTcFg3N3JEVG54MG9BbmFHay9zNExTMjU1TGV6UlgyaTgrQzhOZkRm?=
 =?utf-8?B?Wk40VVA1ZXg1azRDeUlvUU5EeG5nck9LRjRqMUY5VVU5ckF5TTNTYWhlUFl5?=
 =?utf-8?B?VVlNelhWWURlN2tKUUlFU3pERTl4c0ZKaHYzc29ac3d5ZklHejBBWkhIVzdS?=
 =?utf-8?B?ZzAxN3RDenc3YXhFWGpNdTNvMURjYzM5Mk8zaVVPVnVWRmJMdDIrMEVmSFJ1?=
 =?utf-8?B?cmJKWDFqYTFJSWI1K21keVozTEc2eE9Pem1QSis2NU5LOTE3Ylpxd1l2eFQ2?=
 =?utf-8?B?UFFDRTJQUUgwWkNjT094emwvZDUrcDRGZXk4M2pjWkpqc1Ezcm1jNHdNUlYw?=
 =?utf-8?B?bGowc1lNbDhsT0ovMEQyYzNkcHY2L2tvNXpRU08xall3Ni9YekxLbXZ0RTNu?=
 =?utf-8?B?SEpHZGxKMzFUNnVkZHV2d0FQQ3Y4UXdmeGloU2lKb1p3ejh5UWtIYmNMZXpM?=
 =?utf-8?B?emxtT1d5YnlTYTFZQUZ0UnMxNENnMzRtTlVQMlRVZjVWWUhYRVFVd2NlRkpD?=
 =?utf-8?B?Q0NvY1ZMU1VncDdrQ0tMRHhob0cvaG9NazBxZ2F1VGtraTBvZE1CTi9RMVBh?=
 =?utf-8?B?bVhSc0gwK2FyTTc1dXFJVTJKUlh1cjE5THVUVnovVFlsSVhqM2FwZmNsZTlV?=
 =?utf-8?B?STUyY2E1RlhvSmoySGkySVFYTDljTk0yTlFWZW5uQll3T2VCdFMyUlBCSDA5?=
 =?utf-8?B?UzFRdXV5REVwZ1YvZGtXNEI2c2llREd5NllPZXJDSUhMN0VCaUp6QWdhQmpO?=
 =?utf-8?B?M0tOSG1ERUhJeG9UZ0srWWxVRitrYWNLdVhlV29aRlErQUpaeW5uUitHZGN4?=
 =?utf-8?B?MlQwMUNOMklQdTJvT3RFRWM2RVdoVFN1b2lzTEF6MHliTk5xek12ZHZBQkVy?=
 =?utf-8?B?cnhoRjQrWTBSN29xcUZBLzg2T2ZUOGZrZGcyS25NSEZGMTFJS1VzRTNOQXZk?=
 =?utf-8?B?eEZXVDZpODVzbVdLZUtRdlhna1Zxc0NOOC9SVWV0WHF0eVFsNm9PZDBKT0kv?=
 =?utf-8?B?OWllaGhWWDlTdTdDRXlmZG5NVm5ZdVpSb0RoeXJSdHdZeDZ3K1BTWmpTSkVR?=
 =?utf-8?B?bHkvZzlJYUlwVTVXeXFUTVdyd2tTcnNkTXRvL1hjUmJURnk5T0NQYk9Lblhy?=
 =?utf-8?B?cklIRXNQZnkzSkR5SEVIcTlmcHgvZGFVVjlDRDh2aVorRmdCb2JYc2xNVUJK?=
 =?utf-8?B?dkZHRlJkOVloRThBSFc4RDY4aGZvYnVuMFZxeEVOdG01bUlyWEIrdk9BWHJ1?=
 =?utf-8?B?RXN2cjQ3ay9qYzdEamVvSDI2Uk9vSXFTak9QR1BJUGxvQWZtUXNjTkV0ZThI?=
 =?utf-8?Q?Jjfihv?=
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(14060799003)(35042699022)(1800799024)(82310400026)(376014)(36860700013)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jun 2025 16:03:21.2216
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 16fa992f-ccec-422b-6fd0-08ddaa93d1ce
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com]
X-MS-Exchange-CrossTenant-AuthSource:
	AM3PEPF0000A794.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR08MB6317

SGkgQXlhbiwNCg0KPiBPbiAxMSBKdW4gMjAyNSwgYXQgMTU6MzUsIEF5YW4gS3VtYXIgSGFsZGVy
IDxheWFuLmt1bWFyLmhhbGRlckBhbWQuY29tPiB3cm90ZToNCj4gDQo+IERlZmluZSBwcmVwYXJl
X3NlbGVjdG9yKCksIHJlYWRfcHJvdGVjdGlvbl9yZWdpb24oKSBhbmQNCj4gd3JpdGVfcHJvdGVj
dGlvbl9yZWdpb24oKSBmb3IgYXJtMzIuIEFsc28sIGRlZmluZQ0KPiBHRU5FUkFURV97UkVBRC9X
UklURX1fUFJfUkVHX09USEVSUyB0byBhY2Nlc3MgTVBVIHJlZ2lvbnMgZnJvbSAzMiB0byAyNTUu
DQo+IA0KPiBFbmFibGUgcHJfe2dldC9zZXR9X3tiYXNlL2xpbWl0fSgpLCByZWdpb25faXNfdmFs
aWQoKSBmb3IgYXJtMzIuDQo+IEVuYWJsZSBwcl9vZl9hZGRyKCkgZm9yIGFybTMyLg0KPiANCj4g
U2lnbmVkLW9mZi1ieTogQXlhbiBLdW1hciBIYWxkZXIgPGF5YW4ua3VtYXIuaGFsZGVyQGFtZC5j
b20+DQo+IC0tLQ0KPiBDaGFuZ2VzIGZyb20gOi0NCj4gDQo+IHYxIC0gMS4gRW5hYmxlIHdyaXRl
X3Byb3RlY3Rpb25fcmVnaW9uKCkgZm9yIGFhcmNoMzIuDQo+IA0KPiB2MiAtIDEuIEVuYWJsZSBh
Y2Nlc3MgdG8gcHJvdGVjdGlvbiByZWdpb25zIGZyb20gMCAtIDI1NS4NCj4gDQo+IHhlbi9hcmNo
L2FybS9pbmNsdWRlL2FzbS9tcHUuaCAgfCAgIDIgLQ0KPiB4ZW4vYXJjaC9hcm0vbXB1L2FybTMy
L01ha2VmaWxlIHwgICAxICsNCj4geGVuL2FyY2gvYXJtL21wdS9hcm0zMi9tbS5jICAgICB8IDE2
NSArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKw0KPiB4ZW4vYXJjaC9hcm0vbXB1L21t
LmMgICAgICAgICAgIHwgICAyIC0NCj4gNCBmaWxlcyBjaGFuZ2VkLCAxNjYgaW5zZXJ0aW9ucygr
KSwgNCBkZWxldGlvbnMoLSkNCj4gY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9hcmNoL2FybS9tcHUv
YXJtMzIvbW0uYw0KPiANCj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9t
cHUuaCBiL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9tcHUuaA0KPiBpbmRleCA4ZjA2ZGRhYzBm
Li42MzU2MGM2MTNiIDEwMDY0NA0KPiAtLS0gYS94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vbXB1
LmgNCj4gKysrIGIveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL21wdS5oDQo+IEBAIC0yNSw3ICsy
NSw2IEBADQo+IA0KPiAjaWZuZGVmIF9fQVNTRU1CTFlfXw0KPiANCj4gLSNpZmRlZiBDT05GSUdf
QVJNXzY0DQo+IC8qDQo+ICAqIFNldCBiYXNlIGFkZHJlc3Mgb2YgTVBVIHByb3RlY3Rpb24gcmVn
aW9uLg0KPiAgKg0KPiBAQCAtODUsNyArODQsNiBAQCBzdGF0aWMgaW5saW5lIGJvb2wgcmVnaW9u
X2lzX3ZhbGlkKGNvbnN0IHByX3QgKnByKQ0KPiB7DQo+ICAgICByZXR1cm4gcHItPnBybGFyLnJl
Zy5lbjsNCj4gfQ0KPiAtI2VuZGlmIC8qIENPTkZJR19BUk1fNjQgKi8NCj4gDQo+ICNlbmRpZiAv
KiBfX0FTU0VNQkxZX18gKi8NCj4gDQo+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vbXB1L2Fy
bTMyL01ha2VmaWxlIGIveGVuL2FyY2gvYXJtL21wdS9hcm0zMi9NYWtlZmlsZQ0KPiBpbmRleCBl
MTVjZTJmN2JlLi4zZGE4NzIzMjJlIDEwMDY0NA0KPiAtLS0gYS94ZW4vYXJjaC9hcm0vbXB1L2Fy
bTMyL01ha2VmaWxlDQo+ICsrKyBiL3hlbi9hcmNoL2FybS9tcHUvYXJtMzIvTWFrZWZpbGUNCj4g
QEAgLTEgKzEsMiBAQA0KPiBvYmoteSArPSBkb21haW4tcGFnZS5vDQo+ICtvYmoteSArPSBtbS5v
DQo+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vbXB1L2FybTMyL21tLmMgYi94ZW4vYXJjaC9h
cm0vbXB1L2FybTMyL21tLmMNCj4gbmV3IGZpbGUgbW9kZSAxMDA2NDQNCj4gaW5kZXggMDAwMDAw
MDAwMC4uNWQzY2I2ZGZmNw0KPiAtLS0gL2Rldi9udWxsDQo+ICsrKyBiL3hlbi9hcmNoL2FybS9t
cHUvYXJtMzIvbW0uYw0KPiBAQCAtMCwwICsxLDE2NSBAQA0KPiArLyogU1BEWC1MaWNlbnNlLUlk
ZW50aWZpZXI6IEdQTC0yLjAtb25seSAqLw0KPiArDQo+ICsjaW5jbHVkZSA8eGVuL2J1Zy5oPg0K
PiArI2luY2x1ZGUgPHhlbi90eXBlcy5oPg0KPiArI2luY2x1ZGUgPGFzbS9tcHUuaD4NCj4gKyNp
bmNsdWRlIDxhc20vc3lzcmVncy5oPg0KPiArI2luY2x1ZGUgPGFzbS9zeXN0ZW0uaD4NCj4gKw0K
PiArI2RlZmluZSBQUkJBUl9FTDJfKG4pICAgSFBSQkFSIyNuDQo+ICsjZGVmaW5lIFBSTEFSX0VM
Ml8obikgICBIUFJMQVIjI24NCj4gKw0KPiArI2RlZmluZSBHRU5FUkFURV9XUklURV9QUl9SRUdf
Q0FTRShudW0sIHByKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwNCj4gKyAgICBj
YXNlIG51bTogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBcDQo+ICsgICAgeyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXA0KPiArICAgICAgICBXUklU
RV9TWVNSRUcocHItPnByYmFyLmJpdHMgJiB+TVBVX1JFR0lPTl9SRVMwLCBQUkJBUl9FTDJfKG51
bSkpOyAgIFwNCj4gKyAgICAgICAgV1JJVEVfU1lTUkVHKHByLT5wcmxhci5iaXRzICYgfk1QVV9S
RUdJT05fUkVTMCwgUFJMQVJfRUwyXyhudW0pKTsgICBcDQoNCk1heWJlIHlvdSBkb27igJl0IG5l
ZWQgJyYgfk1QVV9SRUdJT05fUkVTMOKAmSBzaW5jZSB5b3VyIE1QVV9SRUdJT05fUkVTMCBpcyB6
ZXJvLCBoZXJlIGFuZCBiZWxvdw0KDQo+ICsgICAgICAgIGJyZWFrOyAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXA0KPiArICAgIH0N
Cj4gKw0KPiArI2RlZmluZSBHRU5FUkFURV9XUklURV9QUl9SRUdfT1RIRVJTKG51bSwgcHIpICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwNCj4gKyAgICBjYXNlIG51bTogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcDQo+
ICsgICAgeyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgXA0KPiArICAgICAgICBXUklURV9TWVNSRUcocHItPnByYmFy
LmJpdHMgJiB+TVBVX1JFR0lPTl9SRVMwLCBIUFJCQVIpOyAgICAgICAgICAgIFwNCj4gKyAgICAg
ICAgV1JJVEVfU1lTUkVHKHByLT5wcmxhci5iaXRzICYgfk1QVV9SRUdJT05fUkVTMCwgSFBSTEFS
KTsgICAgICAgICAgICBcDQo+ICsgICAgICAgIGJyZWFrOyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXA0KPiArICAgIH0NCj4gKw0K
PiArI2RlZmluZSBHRU5FUkFURV9SRUFEX1BSX1JFR19DQVNFKG51bSwgcHIpICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwNCj4gKyAgICBjYXNlIG51bTogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcDQo+ICsgICAg
eyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgXA0KPiArICAgICAgICBwci0+cHJiYXIuYml0cyA9IFJFQURfU1lTUkVH
KFBSQkFSX0VMMl8obnVtKSk7ICAgICAgICAgICAgICAgICAgICAgIFwNCj4gKyAgICAgICAgcHIt
PnBybGFyLmJpdHMgPSBSRUFEX1NZU1JFRyhQUkxBUl9FTDJfKG51bSkpOyAgICAgICAgICAgICAg
ICAgICAgICBcDQo+ICsgICAgICAgIGJyZWFrOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXA0KPiArICAgIH0NCj4gKw0KPiArI2Rl
ZmluZSBHRU5FUkFURV9SRUFEX1BSX1JFR19PVEhFUlMobnVtLCBwcikgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIFwNCj4gKyAgICBjYXNlIG51bTogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcDQo+ICsgICAgeyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXA0KPiArICAgICAgICBwci0+cHJiYXIuYml0cyA9IFJFQURfU1lTUkVHKEhQUkJB
Uik7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwNCj4gKyAgICAgICAgcHItPnBybGFy
LmJpdHMgPSBSRUFEX1NZU1JFRyhIUFJMQVIpOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBcDQo+ICsgICAgICAgIGJyZWFrOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgXA0KPiArICAgIH0NCj4gKw0KPiArLyoNCj4gKyAq
IEFybXY4LVIgc3VwcG9ydHMgZGlyZWN0IGFjY2VzcyBhbmQgaW5kaXJlY3QgYWNjZXNzIHRvIHRo
ZSBNUFUgcmVnaW9ucyB0aHJvdWdoDQo+ICsgKiByZWdpc3RlcnM6DQo+ICsgKiAgLSBpbmRpcmVj
dCBhY2Nlc3MgaW52b2x2ZXMgY2hhbmdpbmcgdGhlIE1QVSByZWdpb24gc2VsZWN0b3IsIGlzc3Vp
bmcgYW4gaXNiDQo+ICsgKiAgICBiYXJyaWVyIGFuZCBhY2Nlc3NpbmcgdGhlIHNlbGVjdGVkIHJl
Z2lvbiB0aHJvdWdoIHNwZWNpZmljIHJlZ2lzdGVycw0KPiArICogIC0gZGlyZWN0IGFjY2VzcyBp
bnZvbHZlcyBhY2Nlc3Npbmcgc3BlY2lmaWMgcmVnaXN0ZXJzIHRoYXQgcG9pbnQgdG8NCj4gKyAq
ICAgIHNwZWNpZmljIE1QVSByZWdpb25zLCB3aXRob3V0IGNoYW5naW5nIHRoZSBzZWxlY3Rvciwg
YXZvaWRpbmcgdGhlIHVzZSBvZg0KPiArICogICAgYSBiYXJyaWVyLg0KPiArICogRm9yIEFybTMy
IHRoZSBQUntCLEx9QVI8bj5fRUx4IChmb3Igbj0wLi4zMSkgYXJlIHVzZWQgZm9yIGRpcmVjdCBh
Y2Nlc3MgdG8gdGhlDQoNCkFybTMyIGhhdmUgUFJ7QixMfUFSIGJ1dCBpdOKAmXMgbm90IEVMMiwg
eW91IG1lYW4gSFBSQkFSIGhlcmUgYW5kIGJlbG93DQoNCj4gKyAqIGZpcnN0IDMyIE1QVSByZWdp
b25zLg0KPiArICogRm9yIE1QVSByZWdpb24gbnVtYmVyZWQgMzIuLjI1NSwgb25lIG5lZWQgdG8g
c2V0IHRoZSByZWdpb24gbnVtYmVyIGluIFBSU0VMUl9FTHgsDQoNCjMyLi4yNTQNCg0KYW5kIGFs
c28gbWF5YmUgeW91IGNhbiB1c2UgSFBSU0VMUiBpbnN0ZWFkIG9mIFBSU0VMUl9FTHgNCg0KPiAr
ICogZm9sbG93ZWQgYnkgY29uZmlndXJpbmcgUFJ7QixMfUFSX0VMeC4NCj4gKyAqLw0KPiAraW5s
aW5lIHZvaWQgcHJlcGFyZV9zZWxlY3Rvcih1aW50OF90ICpzZWwpDQo+ICt7DQo+ICsgICAgdWlu
dDhfdCBjdXJfc2VsID0gKnNlbDsNCj4gKw0KPiArICAgIGlmICggY3VyX3NlbCA+IDB4MUZVICkN
Cg0KY2FuIHdlIHVzZSAzMSBoZXJlPyBpbnN0ZWFkIG9mIHRoZSBoZXg/IEl0IHdvdWxkIGJlIHF1
aWNrZXIgdG8gYmUgcmVhZCBieSBhIGRldmVsb3Blci4NCg0KPiArICAgIHsNCj4gKyAgICAgICAg
V1JJVEVfU1lTUkVHKGN1cl9zZWwsIFBSU0VMUl9FTDIpOw0KPiArICAgICAgICBpc2IoKTsNCj4g
KyAgICB9DQo+ICt9DQo+ICsNCj4gK3ZvaWQgcmVhZF9wcm90ZWN0aW9uX3JlZ2lvbihwcl90ICpw
cl9yZWFkLCB1aW50OF90IHNlbCkNCj4gK3sNCj4gKyAgICBwcmVwYXJlX3NlbGVjdG9yKCZzZWwp
Ow0KPiArDQo+ICsgICAgc3dpdGNoICggc2VsICkNCj4gKyAgICB7DQo+ICsgICAgICAgIEdFTkVS
QVRFX1JFQURfUFJfUkVHX0NBU0UoMCwgcHJfcmVhZCk7DQo+ICsgICAgICAgIEdFTkVSQVRFX1JF
QURfUFJfUkVHX0NBU0UoMSwgcHJfcmVhZCk7DQo+ICsgICAgICAgIEdFTkVSQVRFX1JFQURfUFJf
UkVHX0NBU0UoMiwgcHJfcmVhZCk7DQo+ICsgICAgICAgIEdFTkVSQVRFX1JFQURfUFJfUkVHX0NB
U0UoMywgcHJfcmVhZCk7DQo+ICsgICAgICAgIEdFTkVSQVRFX1JFQURfUFJfUkVHX0NBU0UoNCwg
cHJfcmVhZCk7DQo+ICsgICAgICAgIEdFTkVSQVRFX1JFQURfUFJfUkVHX0NBU0UoNSwgcHJfcmVh
ZCk7DQo+ICsgICAgICAgIEdFTkVSQVRFX1JFQURfUFJfUkVHX0NBU0UoNiwgcHJfcmVhZCk7DQo+
ICsgICAgICAgIEdFTkVSQVRFX1JFQURfUFJfUkVHX0NBU0UoNywgcHJfcmVhZCk7DQo+ICsgICAg
ICAgIEdFTkVSQVRFX1JFQURfUFJfUkVHX0NBU0UoOCwgcHJfcmVhZCk7DQo+ICsgICAgICAgIEdF
TkVSQVRFX1JFQURfUFJfUkVHX0NBU0UoOSwgcHJfcmVhZCk7DQo+ICsgICAgICAgIEdFTkVSQVRF
X1JFQURfUFJfUkVHX0NBU0UoMTAsIHByX3JlYWQpOw0KPiArICAgICAgICBHRU5FUkFURV9SRUFE
X1BSX1JFR19DQVNFKDExLCBwcl9yZWFkKTsNCj4gKyAgICAgICAgR0VORVJBVEVfUkVBRF9QUl9S
RUdfQ0FTRSgxMiwgcHJfcmVhZCk7DQo+ICsgICAgICAgIEdFTkVSQVRFX1JFQURfUFJfUkVHX0NB
U0UoMTMsIHByX3JlYWQpOw0KPiArICAgICAgICBHRU5FUkFURV9SRUFEX1BSX1JFR19DQVNFKDE0
LCBwcl9yZWFkKTsNCj4gKyAgICAgICAgR0VORVJBVEVfUkVBRF9QUl9SRUdfQ0FTRSgxNSwgcHJf
cmVhZCk7DQo+ICsgICAgICAgIEdFTkVSQVRFX1JFQURfUFJfUkVHX0NBU0UoMTYsIHByX3JlYWQp
Ow0KPiArICAgICAgICBHRU5FUkFURV9SRUFEX1BSX1JFR19DQVNFKDE3LCBwcl9yZWFkKTsNCj4g
KyAgICAgICAgR0VORVJBVEVfUkVBRF9QUl9SRUdfQ0FTRSgxOCwgcHJfcmVhZCk7DQo+ICsgICAg
ICAgIEdFTkVSQVRFX1JFQURfUFJfUkVHX0NBU0UoMTksIHByX3JlYWQpOw0KPiArICAgICAgICBH
RU5FUkFURV9SRUFEX1BSX1JFR19DQVNFKDIwLCBwcl9yZWFkKTsNCj4gKyAgICAgICAgR0VORVJB
VEVfUkVBRF9QUl9SRUdfQ0FTRSgyMSwgcHJfcmVhZCk7DQo+ICsgICAgICAgIEdFTkVSQVRFX1JF
QURfUFJfUkVHX0NBU0UoMjIsIHByX3JlYWQpOw0KPiArICAgICAgICBHRU5FUkFURV9SRUFEX1BS
X1JFR19DQVNFKDIzLCBwcl9yZWFkKTsNCj4gKyAgICAgICAgR0VORVJBVEVfUkVBRF9QUl9SRUdf
Q0FTRSgyNCwgcHJfcmVhZCk7DQo+ICsgICAgICAgIEdFTkVSQVRFX1JFQURfUFJfUkVHX0NBU0Uo
MjUsIHByX3JlYWQpOw0KPiArICAgICAgICBHRU5FUkFURV9SRUFEX1BSX1JFR19DQVNFKDI2LCBw
cl9yZWFkKTsNCj4gKyAgICAgICAgR0VORVJBVEVfUkVBRF9QUl9SRUdfQ0FTRSgyNywgcHJfcmVh
ZCk7DQo+ICsgICAgICAgIEdFTkVSQVRFX1JFQURfUFJfUkVHX0NBU0UoMjgsIHByX3JlYWQpOw0K
PiArICAgICAgICBHRU5FUkFURV9SRUFEX1BSX1JFR19DQVNFKDI5LCBwcl9yZWFkKTsNCj4gKyAg
ICAgICAgR0VORVJBVEVfUkVBRF9QUl9SRUdfQ0FTRSgzMCwgcHJfcmVhZCk7DQo+ICsgICAgICAg
IEdFTkVSQVRFX1JFQURfUFJfUkVHX0NBU0UoMzEsIHByX3JlYWQpOw0KPiArICAgICAgICBHRU5F
UkFURV9SRUFEX1BSX1JFR19PVEhFUlMoMzIgLi4uIDI1NSwgcHJfcmVhZCk7DQoNCjMyIOKApiAy
NTQgaGVyZSBhbmQgaW4gdGhlIGJlbG93Lg0KDQo+ICsgICAgZGVmYXVsdDoNCj4gKyAgICAgICAg
QlVHKCk7IC8qIENhbid0IGhhcHBlbiAqLw0KPiArICAgICAgICBicmVhazsNCj4gKyAgICB9DQo+
ICt9DQo+ICsNCj4gK3ZvaWQgd3JpdGVfcHJvdGVjdGlvbl9yZWdpb24oY29uc3QgcHJfdCAqcHJf
d3JpdGUsIHVpbnQ4X3Qgc2VsKQ0KPiArew0KPiArICAgIHByZXBhcmVfc2VsZWN0b3IoJnNlbCk7
DQo+ICsNCj4gKyAgICBzd2l0Y2ggKCBzZWwgKQ0KPiArICAgIHsNCj4gKyAgICAgICAgR0VORVJB
VEVfV1JJVEVfUFJfUkVHX0NBU0UoMCwgcHJfd3JpdGUpOw0KPiArICAgICAgICBHRU5FUkFURV9X
UklURV9QUl9SRUdfQ0FTRSgxLCBwcl93cml0ZSk7DQo+ICsgICAgICAgIEdFTkVSQVRFX1dSSVRF
X1BSX1JFR19DQVNFKDIsIHByX3dyaXRlKTsNCj4gKyAgICAgICAgR0VORVJBVEVfV1JJVEVfUFJf
UkVHX0NBU0UoMywgcHJfd3JpdGUpOw0KPiArICAgICAgICBHRU5FUkFURV9XUklURV9QUl9SRUdf
Q0FTRSg0LCBwcl93cml0ZSk7DQo+ICsgICAgICAgIEdFTkVSQVRFX1dSSVRFX1BSX1JFR19DQVNF
KDUsIHByX3dyaXRlKTsNCj4gKyAgICAgICAgR0VORVJBVEVfV1JJVEVfUFJfUkVHX0NBU0UoNiwg
cHJfd3JpdGUpOw0KPiArICAgICAgICBHRU5FUkFURV9XUklURV9QUl9SRUdfQ0FTRSg3LCBwcl93
cml0ZSk7DQo+ICsgICAgICAgIEdFTkVSQVRFX1dSSVRFX1BSX1JFR19DQVNFKDgsIHByX3dyaXRl
KTsNCj4gKyAgICAgICAgR0VORVJBVEVfV1JJVEVfUFJfUkVHX0NBU0UoOSwgcHJfd3JpdGUpOw0K
PiArICAgICAgICBHRU5FUkFURV9XUklURV9QUl9SRUdfQ0FTRSgxMCwgcHJfd3JpdGUpOw0KPiAr
ICAgICAgICBHRU5FUkFURV9XUklURV9QUl9SRUdfQ0FTRSgxMSwgcHJfd3JpdGUpOw0KPiArICAg
ICAgICBHRU5FUkFURV9XUklURV9QUl9SRUdfQ0FTRSgxMiwgcHJfd3JpdGUpOw0KPiArICAgICAg
ICBHRU5FUkFURV9XUklURV9QUl9SRUdfQ0FTRSgxMywgcHJfd3JpdGUpOw0KPiArICAgICAgICBH
RU5FUkFURV9XUklURV9QUl9SRUdfQ0FTRSgxNCwgcHJfd3JpdGUpOw0KPiArICAgICAgICBHRU5F
UkFURV9XUklURV9QUl9SRUdfQ0FTRSgxNSwgcHJfd3JpdGUpOw0KPiArICAgICAgICBHRU5FUkFU
RV9XUklURV9QUl9SRUdfQ0FTRSgxNiwgcHJfd3JpdGUpOw0KPiArICAgICAgICBHRU5FUkFURV9X
UklURV9QUl9SRUdfQ0FTRSgxNywgcHJfd3JpdGUpOw0KPiArICAgICAgICBHRU5FUkFURV9XUklU
RV9QUl9SRUdfQ0FTRSgxOCwgcHJfd3JpdGUpOw0KPiArICAgICAgICBHRU5FUkFURV9XUklURV9Q
Ul9SRUdfQ0FTRSgxOSwgcHJfd3JpdGUpOw0KPiArICAgICAgICBHRU5FUkFURV9XUklURV9QUl9S
RUdfQ0FTRSgyMCwgcHJfd3JpdGUpOw0KPiArICAgICAgICBHRU5FUkFURV9XUklURV9QUl9SRUdf
Q0FTRSgyMSwgcHJfd3JpdGUpOw0KPiArICAgICAgICBHRU5FUkFURV9XUklURV9QUl9SRUdfQ0FT
RSgyMiwgcHJfd3JpdGUpOw0KPiArICAgICAgICBHRU5FUkFURV9XUklURV9QUl9SRUdfQ0FTRSgy
MywgcHJfd3JpdGUpOw0KPiArICAgICAgICBHRU5FUkFURV9XUklURV9QUl9SRUdfQ0FTRSgyNCwg
cHJfd3JpdGUpOw0KPiArICAgICAgICBHRU5FUkFURV9XUklURV9QUl9SRUdfQ0FTRSgyNSwgcHJf
d3JpdGUpOw0KPiArICAgICAgICBHRU5FUkFURV9XUklURV9QUl9SRUdfQ0FTRSgyNiwgcHJfd3Jp
dGUpOw0KPiArICAgICAgICBHRU5FUkFURV9XUklURV9QUl9SRUdfQ0FTRSgyNywgcHJfd3JpdGUp
Ow0KPiArICAgICAgICBHRU5FUkFURV9XUklURV9QUl9SRUdfQ0FTRSgyOCwgcHJfd3JpdGUpOw0K
PiArICAgICAgICBHRU5FUkFURV9XUklURV9QUl9SRUdfQ0FTRSgyOSwgcHJfd3JpdGUpOw0KPiAr
ICAgICAgICBHRU5FUkFURV9XUklURV9QUl9SRUdfQ0FTRSgzMCwgcHJfd3JpdGUpOw0KPiArICAg
ICAgICBHRU5FUkFURV9XUklURV9QUl9SRUdfQ0FTRSgzMSwgcHJfd3JpdGUpOw0KPiArICAgICAg
ICBHRU5FUkFURV9XUklURV9QUl9SRUdfT1RIRVJTKDMyIC4uLiAyNTUsIHByX3dyaXRlKTsNCj4g
KyAgICBkZWZhdWx0Og0KPiArICAgICAgICBCVUcoKTsgLyogQ2FuJ3QgaGFwcGVuICovDQo+ICsg
ICAgICAgIGJyZWFrOw0KPiArICAgIH0NCj4gK30NCj4gKw0KPiArLyoNCj4gKyAqIExvY2FsIHZh
cmlhYmxlczoNCj4gKyAqIG1vZGU6IEMNCj4gKyAqIGMtZmlsZS1zdHlsZTogIkJTRCINCj4gKyAq
IGMtYmFzaWMtb2Zmc2V0OiA0DQo+ICsgKiBpbmRlbnQtdGFicy1tb2RlOiBuaWwNCj4gKyAqIEVu
ZDoNCj4gKyAqLw0KPiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL21wdS9tbS5jIGIveGVuL2Fy
Y2gvYXJtL21wdS9tbS5jDQo+IGluZGV4IDdhYjY4ZmM4YzcuLmNjZmIzN2E2N2IgMTAwNjQ0DQo+
IC0tLSBhL3hlbi9hcmNoL2FybS9tcHUvbW0uYw0KPiArKysgYi94ZW4vYXJjaC9hcm0vbXB1L21t
LmMNCj4gQEAgLTM5LDcgKzM5LDYgQEAgc3RhdGljIHZvaWQgX19pbml0IF9fbWF5YmVfdW51c2Vk
IGJ1aWxkX2Fzc2VydGlvbnModm9pZCkNCj4gICAgIEJVSUxEX0JVR19PTihQQUdFX1NJWkUgIT0g
U1pfNEspOw0KPiB9DQo+IA0KPiAtI2lmZGVmIENPTkZJR19BUk1fNjQNCj4gcHJfdCBwcl9vZl9h
ZGRyKHBhZGRyX3QgYmFzZSwgcGFkZHJfdCBsaW1pdCwgdW5zaWduZWQgaW50IGZsYWdzKQ0KPiB7
DQo+ICAgICB1bnNpZ25lZCBpbnQgYXR0cl9pZHggPSBQQUdFX0FJX01BU0soZmxhZ3MpOw0KPiBA
QCAtMTEwLDcgKzEwOSw2IEBAIHByX3QgcHJfb2ZfYWRkcihwYWRkcl90IGJhc2UsIHBhZGRyX3Qg
bGltaXQsIHVuc2lnbmVkIGludCBmbGFncykNCj4gDQo+ICAgICByZXR1cm4gcmVnaW9uOw0KPiB9
DQo+IC0jZW5kaWYgLyogQ09ORklHX0FSTV82NCAqLw0KPiANCj4gdm9pZCBfX2luaXQgc2V0dXBf
bW0odm9pZCkNCj4gew0KPiAtLSANCj4gMi4yNS4xDQo+IA0KPiANCg0KQ2hlZXJzLA0KTHVjYQ0K
DQoNCg==


From xen-devel-bounces@lists.xenproject.org Fri Jun 13 17:40:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 17:40:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014788.1392890 (Exim 4.92)
	(envelope-from )
	id 1uQ8O6-0006i0-Ms; Fri, 13 Jun 2025 17:40:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014788.1392890; Fri, 13 Jun 2025 17: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 1uQ8O6-0006ht-KO; Fri, 13 Jun 2025 17:40:22 +0000
Received: by outflank-mailman (input) for mailman id 1014788;
 Fri, 13 Jun 2025 17:40: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 1uQ8O5-0006hV-4f
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 17:40:21 +0000
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com
 [2a00:1450:4864:20::132])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7a15a836-487d-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 19:40:20 +0200 (CEST)
Received: by mail-lf1-x132.google.com with SMTP id
 2adb3069b0e04-553b3316160so707746e87.2
 for ; Fri, 13 Jun 2025 10:40:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7a15a836-487d-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749836420; x=1750441220; 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=sLOpd5cfiZVf0bMJOMKGHCiUQkKcGg4iz1OWyEC2yps=;
        b=XT0yHTRAsKpvNoIwTf0hiWJP5o1ZCE/xGOxgSfDwo2jcBFegBUstY8RaDtpBGMMBlR
         qT88/8pUwiXanLdaNA55u2m0fPm0XB433OhWDS3xYwsemtnupSCM7Tqn/n11hgd7CW7p
         MDYos3DSlGS4nCzvQWJesZH1uZpacDx+ERUQgYIg1v4JHVGsHjxy6jmMF8NrDfv8GtQB
         n9CWnmDFf555mXmIlg2/iaXy12/vUvZLn0k7ETg5mmRmbJ464VQ8YuhykkR9RAoP9RN/
         UeC9RiK3syxeWCiP1wNt57mHheMRX3LQFNCBMA7XuG7zGb2L62GixQ53VoPtwUqVwwEp
         eOaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749836420; x=1750441220;
        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=sLOpd5cfiZVf0bMJOMKGHCiUQkKcGg4iz1OWyEC2yps=;
        b=cj8JUwLINHSzSJOp6Q0Eff6p8wv+REYJKJexTkpeQAqHZ8GC3dEgEcAaGrofmL/jx1
         h0/H48lxHM5apWdubgZfTEp3ns4kfexKEY2PUiWTGyNchGl453O72TdnGp1lbsL8j/ar
         pZZe526+Uv9BFltjb/3QWs6r4UmUJiV1V0MYtEK8B2/qFZgfU0annw99b0TgcGiBYAL/
         sgxc5v6TFtJNGTzyIGOoKTo+MU9iQalUS876agMZBy80AHPlHaZInyYzVo7rDT7QvJGi
         sZb+9LNUsEd/lZ2FooI1/85nukXpn37TJ3WBNuDLMvrY7Hu/2KnI3lDdblWeHP7HGr6M
         FmxQ==
X-Gm-Message-State: AOJu0YwHpc2eInPMjvFHxT58IoQg85/YJiJQrJNZJqbChB9cCwkOXL9Q
	IsIa8Lv64/1N/DPwhPvpjcYO0YQUc8JkteVCx0VZ9Xptz1HnObFbo9+0qmFycdf9T8ukZG98dU+
	emjGqGuNwrzEcequh1+1NeUbhOXhcnYM=
X-Gm-Gg: ASbGncuU36b3jpn/Uo6rrdke9KlQAVJf1OzSKxqRYzosjfY2EHVfjhzaqJ5BUKM3Eek
	f75qe4q4R+ZMFc5WYBcWCOTQBBIMAUXbd9htX0RS2nJFM7S+hzjF8P8sgei3YQFmlgrU3Hu4Ld6
	r7sXvuj3I29w6nlupoAUwCbQoWRfLentvEpwRNVhQNoQ==
X-Google-Smtp-Source: AGHT+IFYPsNfR8jj4o17Vd1AgYxI94ChEeiBHTzZ0wrwCeVlNn8vifoP0lfIiyB+jQcVCV/+O/EPJUUYJdFzVyxwm/c=
X-Received: by 2002:a05:6512:12ca:b0:553:2ed2:15b4 with SMTP id
 2adb3069b0e04-553b6f4d916mr27611e87.57.1749836419420; Fri, 13 Jun 2025
 10:40:19 -0700 (PDT)
MIME-Version: 1.0
References:  
 
In-Reply-To: 
From: Mykola Kvach 
Date: Fri, 13 Jun 2025 20:40:08 +0300
X-Gm-Features: AX0GCFvAfeLlu-0TTtcGflxTgYcfAKarDEpNqWhOfIVTRILlz72jMq_EEf0xzJQ
Message-ID: 
Subject: Re: [PATCH v4][PART 2 02/10] xen/arm: Add suspend and resume timer helpers
To: Ayan Kumar Halder 
Cc: xen-devel@lists.xenproject.org, 
	Stefano Stabellini , Julien Grall , 
	Bertrand Marquis , Michal Orzel , 
	Volodymyr Babchuk 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Ayan

On Fri, Jun 13, 2025 at 5:44=E2=80=AFPM Ayan Kumar Halder  wrote:
>
> Hi Mykola,
>
> On 02/06/2025 10:04, Mykola Kvach wrote:
> > CAUTION: This message has originated from an External Source. Please us=
e proper judgment and caution when opening attachments, clicking links, or =
responding to this email.
> >
> >
> > From: Mirela Simonovic 
> >
> > Timer interrupts must be disabled while the system is suspended to prev=
ent
> > spurious wake-ups. Suspending the timers involves disabling both the EL=
1
> > physical timer and the EL2 hypervisor timer. Resuming consists of raisi=
ng
> > the TIMER_SOFTIRQ, which prompts the generic timer code to reprogram th=
e
> > EL2 timer as needed. Re-enabling of the EL1 timer is left to the entity
> > that uses it.
> >
> > Introduce a new helper, disable_physical_timers, to encapsulate disabli=
ng
> > of the physical timers.
> >
> > Signed-off-by: Mirela Simonovic 
> > Signed-off-by: Saeed Nowshadi 
> > Signed-off-by: Mykola Kvach 
> > ---
> > Changes in V4:
> >    - Rephrased comment and commit message for better clarity
> >    - Created separate function for disabling physical timers
> >
> > Changes in V3:
> >    - time_suspend and time_resume are now conditionally compiled
> >      under CONFIG_SYSTEM_SUSPEND
> > ---
> >   xen/arch/arm/include/asm/time.h |  5 +++++
> >   xen/arch/arm/time.c             | 38 +++++++++++++++++++++++++++-----=
-
> >   2 files changed, 37 insertions(+), 6 deletions(-)
> >
> > diff --git a/xen/arch/arm/include/asm/time.h b/xen/arch/arm/include/asm=
/time.h
> > index 49ad8c1a6d..f4fd0c6af5 100644
> > --- a/xen/arch/arm/include/asm/time.h
> > +++ b/xen/arch/arm/include/asm/time.h
> > @@ -108,6 +108,11 @@ void preinit_xen_time(void);
> >
> >   void force_update_vcpu_system_time(struct vcpu *v);
> >
> > +#ifdef CONFIG_SYSTEM_SUSPEND
> > +void time_suspend(void);
> > +void time_resume(void);
> > +#endif /* CONFIG_SYSTEM_SUSPEND */
> > +
> >   #endif /* __ARM_TIME_H__ */
> >   /*
> >    * Local variables:
> > diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
> > index e74d30d258..ad984fdfdd 100644
> > --- a/xen/arch/arm/time.c
> > +++ b/xen/arch/arm/time.c
> > @@ -303,6 +303,14 @@ static void check_timer_irq_cfg(unsigned int irq, =
const char *which)
> >              "WARNING: %s-timer IRQ%u is not level triggered.\n", which=
, irq);
> >   }
> >
> > +/* Disable physical timers for EL1 and EL2 on the current CPU */
> > +static inline void disable_physical_timers(void)
> > +{
> > +    WRITE_SYSREG(0, CNTP_CTL_EL0);    /* Physical timer disabled */
> > +    WRITE_SYSREG(0, CNTHP_CTL_EL2);   /* Hypervisor's timer disabled *=
/
> > +    isb();
> > +}
> > +
> >   /* Set up the timer interrupt on this CPU */
> >   void init_timer_interrupt(void)
> >   {
> > @@ -310,9 +318,7 @@ void init_timer_interrupt(void)
> >       WRITE_SYSREG64(0, CNTVOFF_EL2);     /* No VM-specific offset */
> >       /* Do not let the VMs program the physical timer, only read the p=
hysical counter */
> >       WRITE_SYSREG(CNTHCTL_EL2_EL1PCTEN, CNTHCTL_EL2);
> > -    WRITE_SYSREG(0, CNTP_CTL_EL0);    /* Physical timer disabled */
> > -    WRITE_SYSREG(0, CNTHP_CTL_EL2);   /* Hypervisor's timer disabled *=
/
> > -    isb();
> > +    disable_physical_timers();
> >
> >       request_irq(timer_irq[TIMER_HYP_PPI], 0, htimer_interrupt,
> >                   "hyptimer", NULL);
> > @@ -330,9 +336,7 @@ void init_timer_interrupt(void)
> >    */
> >   static void deinit_timer_interrupt(void)
> >   {
> > -    WRITE_SYSREG(0, CNTP_CTL_EL0);    /* Disable physical timer */
> > -    WRITE_SYSREG(0, CNTHP_CTL_EL2);   /* Disable hypervisor's timer */
> > -    isb();
> > +    disable_physical_timers();
> >
> >       release_irq(timer_irq[TIMER_HYP_PPI], NULL);
> >       release_irq(timer_irq[TIMER_VIRT_PPI], NULL);
> > @@ -372,6 +376,28 @@ void domain_set_time_offset(struct domain *d, int6=
4_t time_offset_seconds)
> >       /* XXX update guest visible wallclock time */
> >   }
> >
> > +#ifdef CONFIG_SYSTEM_SUSPEND
> > +
> > +void time_suspend(void)
> > +{
> > +    disable_physical_timers();
> > +}
> > +
> > +void time_resume(void)
> > +{
> > +    /*
> > +     * Raising the timer softirq triggers generic code to call reprogr=
am_timer
> > +     * with the correct timeout (not known here).
> > +     *
> > +     * No further action is needed to restore timekeeping after power =
down,
> > +     * since the system counter is unaffected. See ARM DDI 0487 L.a, D=
12.1.2
> > +     * "The system counter must be implemented in an always-on power d=
omain."
> > +     */
> > +    raise_softirq(TIMER_SOFTIRQ);
> > +}
> > +
> > +#endif /* CONFIG_SYSTEM_SUSPEND */
> > +
> >   static int cpu_time_callback(struct notifier_block *nfb,
> >                                unsigned long action,
> >                                void *hcpu)
> A question. Do you see CPU_DYING gets invoked during platform suspend ?

Yes, it is invoked through the following code flow:
system_suspend (introduced in this patch series)
    -> disable_nonboot_cpus
        -> cpu_down
            -> take_cpu_down
                -> _take_cpu_down


> I wonder how this code path is invoked with
>
> time_suspend()

time_suspend is called directly from system_suspend,
which was introduced in one of the latest commits in this patch series.

In one of the previous patch series, there was a request to separate
implementations and usage of functions.
This was done to reduce the amount of code in each commit and to
simplify the review process.

>
> - Ayan
>
> > --
> > 2.48.1
> >
> >

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Fri Jun 13 18:26:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 18:26:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014819.1392901 (Exim 4.92)
	(envelope-from )
	id 1uQ96m-0003Su-Tl; Fri, 13 Jun 2025 18:26:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014819.1392901; Fri, 13 Jun 2025 18: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 1uQ96m-0003Sn-R8; Fri, 13 Jun 2025 18:26:32 +0000
Received: by outflank-mailman (input) for mailman id 1014819;
 Fri, 13 Jun 2025 18:26: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 1uQ96l-0003Sh-DJ
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 18:26:31 +0000
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com
 [2a00:1450:4864:20::136])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ec64a662-4883-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 20:26:29 +0200 (CEST)
Received: by mail-lf1-x136.google.com with SMTP id
 2adb3069b0e04-553241d30b3so2065017e87.3
 for ; Fri, 13 Jun 2025 11:26:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ec64a662-4883-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749839189; x=1750443989; 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=744Q4BaZEA37rjJV9mLugsQfyO+L5XOIK9X7Q5KQDbc=;
        b=erGdm9TZ+/h7yTXQD6sD3wIiERYoKFXCx8+2vtwMVE2WwYbIC9cXVnOEdi6dmZ31Nx
         SfFv/aZzPavAVyg50uElCguYBvZs4ho9pR6iu6mrqWOxKDY6+gFwS1eI7oduLVOqlru4
         HnlkOPHicURwP6Cnm6bQBVt2lj7y7i5Srqg49ZjSBoKncmCPgRZSUhP6zw/4SowkVRth
         4cBPT82CkDKLW7UHY+NIJOxTqTisISghD1/uFKQTuTBTSo3egZ6d/NqAG8ZxjodxqdC+
         dWatRU/RKazLuMB5ILehG+CUdTF4ncW4MEvNA+IfioeeuZsxUMCMbZxRZchvoeTeNGSV
         1+zg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749839189; x=1750443989;
        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=744Q4BaZEA37rjJV9mLugsQfyO+L5XOIK9X7Q5KQDbc=;
        b=s3H34VVywsGnkLo5jevePW+aaLMzMl6Aw6+rrIUzFsX7vRdk0pjn5jqzUxKjRRUorc
         8j1qgYQt0KSCExmJLY8poaHLvsxdgBMXibF2yflH5mFutG14FrawdS9xZMv1qFUQ5bEu
         4UL/dj0ZtfSHaIF1Y5sDzgC8qOTIYHiW61SihEsbewYgLxDtPPmGCpCjrTafhNKyxNtO
         sEB9bxxOGOintl94F9nYl1LXsH1byuL9LOti8HDPiniG6Lgo0YMn6egkpmH1U16yXaQQ
         Tyz0EGJRpagOXKT1Fpxs20oX+pOWtGGUrHRlKB6Bb5PrfTBqDg4iZYQihQk/Te9nV5gV
         FFZw==
X-Gm-Message-State: AOJu0YybPa6awJPAC1BZPoGts3YuVFB3Mo94GEUIinLQhjzzwu0fqMow
	OG8pHOZqvnJlMkVILMmR8+p99HDKXLYAR5VCp3To6cDPYVzRJKQ0F/3YpmH0OLzPxL7SDyuHT3o
	oUGhjAg4hOmG6ptb9GcTYspPeI4D0wQA=
X-Gm-Gg: ASbGncuqfnFiY7n083ty2/1WfAMVjN81HKm47N2D5kubiNRBbARQUH/r77yn99wOhSv
	i4EDQYZcwxb4hXDEIpzht4IEMT3kogxpcC2WvUSc1l9N4RlHIu99c86wRD2m/R/koJSGrqoqWns
	4x4jIIrKXRhH7XEOMYtNyy5XPEn3e/20Ev4lQ2F3brCA==
X-Google-Smtp-Source: AGHT+IEmMNVKSWJ6ZcdzB6hiq0iiWMoOGop98C+43yBO+IDYHL9fpfPXTTJ654SWhYnS9MYPDIpnuRxuGO6da3JCqZw=
X-Received: by 2002:a05:6512:68a:b0:553:663d:736c with SMTP id
 2adb3069b0e04-553b6e84d23mr100310e87.15.1749839188485; Fri, 13 Jun 2025
 11:26:28 -0700 (PDT)
MIME-Version: 1.0
References:  <3be3369910ec5159eab3cb26155da645dd1df83b.1749204282.git.mykola_kvach@epam.com>
 <4403d50b-3380-4f94-8c14-f0eb2884b50d@amd.com>
In-Reply-To: <4403d50b-3380-4f94-8c14-f0eb2884b50d@amd.com>
From: Mykola Kvach 
Date: Fri, 13 Jun 2025 21:26:16 +0300
X-Gm-Features: AX0GCFsh2EuSdYXKiv9tWNwCaeneeehXf_c1JaYNHsH5VfCHhZrq2I1e-i0rZmQ
Message-ID: 
Subject: Re: [PATCH v3 2/2] xen/char: implement suspend/resume calls for SCIF driver
To: Ayan Kumar Halder 
Cc: xen-devel@lists.xenproject.org, 
	Volodymyr Babchuk , Stefano Stabellini , 
	Julien Grall , Bertrand Marquis , 
	Michal Orzel , 
	Oleksandr Andrushchenko , Mykola Kvach 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Ayan

On Fri, Jun 13, 2025 at 5:36=E2=80=AFPM Ayan Kumar Halder  wrote:
>
> Hi Mykola,
>
> On 06/06/2025 11:11, Mykola Kvach wrote:
> > CAUTION: This message has originated from an External Source. Please us=
e proper judgment and caution when opening attachments, clicking links, or =
responding to this email.
> >
> >
> > From: Volodymyr Babchuk 
> >
> > The changes have been tested only on the Renesas R-Car H3 Starter Kit b=
oard.
>
> The commit message need to explain what the change is and why it is neede=
d.

Thanks for the feedback. I thought the information from the commit
message title would be enough.

I will add a few more words to clarify what the change is and why it's
needed to the commit message body.

>
> Also ...
>
> >
> > Signed-off-by: Volodymyr Babchuk 
> > Signed-off-by: Oleksandr Andrushchenko 
> > Signed-off-by: Mykola Kvach 
> > ---
> > In patch v2, I just added a CONFIG_SYSTEM_SUSPEND check around
> > the suspend/resume functions in the SCIF driver.
> > ---
> >   xen/drivers/char/scif-uart.c | 40 ++++++++++++++++++++++++++++++++++-=
-
> >   1 file changed, 38 insertions(+), 2 deletions(-)
> >
> > diff --git a/xen/drivers/char/scif-uart.c b/xen/drivers/char/scif-uart.=
c
> > index 757793ca45..888821a3b8 100644
> > --- a/xen/drivers/char/scif-uart.c
> > +++ b/xen/drivers/char/scif-uart.c
> > @@ -139,9 +139,8 @@ static void scif_uart_interrupt(int irq, void *data=
)
> >       }
> >   }
> >
> > -static void __init scif_uart_init_preirq(struct serial_port *port)
> > +static void scif_uart_disable(struct scif_uart *uart)
> >   {
> > -    struct scif_uart *uart =3D port->uart;
> >       const struct port_params *params =3D uart->params;
> >
> >       /*
> > @@ -155,6 +154,14 @@ static void __init scif_uart_init_preirq(struct se=
rial_port *port)
> >
> >       /* Reset TX/RX FIFOs */
> >       scif_writew(uart, SCIF_SCFCR, SCFCR_RFRST | SCFCR_TFRST);
> > +}
> > +
> > +static void scif_uart_init_preirq(struct serial_port *port)
> > +{
> > +    struct scif_uart *uart =3D port->uart;
> > +    const struct port_params *params =3D uart->params;
> > +
> > +    scif_uart_disable(uart);
> >
> >       /* Clear all errors and flags */
> >       scif_readw(uart, params->status_reg);
> > @@ -271,6 +278,31 @@ static void scif_uart_stop_tx(struct serial_port *=
port)
> >       scif_writew(uart, SCIF_SCSCR, scif_readw(uart, SCIF_SCSCR) & ~SCS=
CR_TIE);
> >   }
> >
> > +#ifdef CONFIG_SYSTEM_SUSPEND
> > +
> > +static void scif_uart_suspend(struct serial_port *port)
> > +{
> > +    struct scif_uart *uart =3D port->uart;
> > +
> > +    scif_uart_stop_tx(port);
> > +    scif_uart_disable(uart);
> > +}
> > +
> > +static void scif_uart_resume(struct serial_port *port)
> > +{
> > +    struct scif_uart *uart =3D port->uart;
> > +    const struct port_params *params =3D uart->params;
> > +    uint16_t ctrl;
> > +
> > +    scif_uart_init_preirq(port);
> > +
> > +    /* Enable TX/RX and Error Interrupts  */
> > +    ctrl =3D scif_readw(uart, SCIF_SCSCR);
> > +    scif_writew(uart, SCIF_SCSCR, ctrl | params->irq_flags);
>
> If you can give reference to a public doc which describe these
> registers, it will be great.

I don't think I can share documentation for the board I used for testing
this commit.

However, I searched for Linux boards that use the same driver and SCIF
register set with available documentation, and I found a few boards with
open documentation, for example, RZ/G1H or RZ/G1M:

https://www.renesas.com/en/products/microcontrollers-microprocessors/rz-mpu=
s/rzg1m-ultra-high-performance-microprocessors-15ghz-dual-core-arm-cortex-a=
15-cpus-3d-graphics-and-video

>
> Otherwise, the changes look ok to me.
>
> > +}
> > +
> > +#endif /* CONFIG_SYSTEM_SUSPEND */
> > +
> >   static struct uart_driver __read_mostly scif_uart_driver =3D {
> >       .init_preirq  =3D scif_uart_init_preirq,
> >       .init_postirq =3D scif_uart_init_postirq,
> > @@ -281,6 +313,10 @@ static struct uart_driver __read_mostly scif_uart_=
driver =3D {
> >       .start_tx     =3D scif_uart_start_tx,
> >       .stop_tx      =3D scif_uart_stop_tx,
> >       .vuart_info   =3D scif_vuart_info,
> > +#ifdef CONFIG_SYSTEM_SUSPEND
> > +    .suspend      =3D scif_uart_suspend,
> > +    .resume       =3D scif_uart_resume,
> > +#endif
> >   };
> >
> >   static const struct dt_device_match scif_uart_dt_match[] __initconst =
=3D
> - Ayan
> > --
> > 2.48.1
> >
> >

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Fri Jun 13 18:43:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 18:43:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014836.1392915 (Exim 4.92)
	(envelope-from )
	id 1uQ9Md-00067h-AK; Fri, 13 Jun 2025 18:42:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014836.1392915; Fri, 13 Jun 2025 18:42: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 1uQ9Md-00067a-6g; Fri, 13 Jun 2025 18:42:55 +0000
Received: by outflank-mailman (input) for mailman id 1014836;
 Fri, 13 Jun 2025 18:42: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 1uQ9Mb-00067U-VP
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 18:42:53 +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 36248c5a-4886-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 20:42:52 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a54700a463so1728123f8f.1
 for ; Fri, 13 Jun 2025 11:42:52 -0700 (PDT)
Received: from [192.168.86.29] ([90.250.112.104])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a5689e5f3dsm3134358f8f.0.2025.06.13.11.42.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 13 Jun 2025 11:42:50 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 36248c5a-4886-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749840171; x=1750444971; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=1z6HXF0Dny22KZLHcBuUDGdrZzhobEewsiDAS8gCAFo=;
        b=E/UqxWFkXWiS2OVIL63+8gLLQsQIT7xsLwOtW8dQ9LeElUSvBcXErC4t3g49lJa127
         4qcpkjSrT/ZyOpXrCvNlDexImbvwXY82J0g0RAaFMu6yyTr/d4jFHbMMJT+JiFmqCNdN
         GYn3kXOXbyFkrVZY7PiMtP4nAp/tsHYYTqkYY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749840171; x=1750444971;
        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=1z6HXF0Dny22KZLHcBuUDGdrZzhobEewsiDAS8gCAFo=;
        b=odFHoLXO96SLJf/oRIpFSEmL3NQuTeJ183f5LGolTq5TLAFOFpmF4InGmHMdtEyaOU
         9zjYcRoLE7XYiS3zG/EMpyl43uUCgbHR7HSn7Cuks6f7p9o4981Y8A1LTkPdOuZduonx
         L1BVTChP1LUQSaWQkODLOpGNP+tvOwPqrM7yf0xCLgSaoyd5Cazurb0Uyo0zPgXEVDxJ
         cEj/1sEHH8ALaBZLISdI64daaIp16vnWvNlu3FqF6TnALXu6hhRGPXKO4jJzQwcpo6in
         eEpuxVSPOtXL1vmnHTIQs1y4LaR4520dCineOcr6IViz3+qw+WCdwbM7aFdu8300NXvd
         AYDQ==
X-Forwarded-Encrypted: i=1; AJvYcCV3Y1//3axuMfIS+36R1y3RBBIPQ6h3cbceGQsVIsWIGrqv6AaVzEiV3FBXHLbfcMZh5Yx3oX457V8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwRuUpg7aUUbQ9T5y1YLd35RDxNNTvJG2XIwPxoLmQbeVKdCuAF
	wke6rap5KJJ88lwaFUWytcFXYaemACx3GEDOfwuSZKb4Mk0l9uuw42pjhCLKsh5j6uM=
X-Gm-Gg: ASbGncuwctQ15ypU/ajamngUuIUPMO2+e8CN/44pDEHzdJcibG4QCWiWq0ZzlPwPiIi
	orGxA9kI6OP08d3ZIRNEVkn1wowA1Y84v3e6EfT/jHkZ7/+dY66LDmPP/T3Eys+6S+MQvglXPBj
	u19R0uplBg39lW3xfExR2x5igLNnJTy3D0e7FoMAoOfFwbndp1Uq59x80FDgjTa7p/2xMVmNm+J
	8Ej2h6n5s26bDtBvM5CQbgFQrAZGZoBG1yq4wWOvpxZ1kYbGg/CSkNZGMEOlWQ1iepDwA2lOTkU
	ogHaUB02tJUesA479s5RpdZiN1DtPdb7L1K2tb+zEYBBZd7k8JNeaytDvH+IygMbFbyFKJlDzek
	=
X-Google-Smtp-Source: AGHT+IHFReEu1NzflyvBpF34FTgjNx9fyNxF08wuaqakwb7MNUHvmxH3+Toz/h4c1QhPCslaR7BaGQ==
X-Received: by 2002:a05:6000:230a:b0:3a4:f7e7:3630 with SMTP id ffacd0b85a97d-3a572e66e95mr837391f8f.15.1749840171318;
        Fri, 13 Jun 2025 11:42:51 -0700 (PDT)
Message-ID: <3fa9b5c6-da3c-44a6-b920-f3fb7379ea36@citrix.com>
Date: Fri, 13 Jun 2025 19:42:50 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/2] xen/riscv: rework asm/mm.h and asm/page.h includes
 to match other architectures
To: Oleksii Kurochko ,
 xen-devel@lists.xenproject.org
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini 
References: 
 <42696025e262f50ee7d26b252bfe3d3c0a9c77e6.1749829230.git.oleksii.kurochko@gmail.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: <42696025e262f50ee7d26b252bfe3d3c0a9c77e6.1749829230.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13/06/2025 4:56 pm, Oleksii Kurochko wrote:
> To align with other architectures where  is included from 
> (and not the other way around), the following changes are made:
> - Since  is no longer included in :
>   - Move the definitions of paddr_to_pte() and pte_to_paddr() to ,
>     as paddr_to_pfn() and pte_to_paddr() are already defined there.
>   - Move _vmap_to_mfn() to  because mfn_from_pte() is defined there and
>     open-code it inside macros vmap_to_mfn().
> - Drop the inclusion of  from  to resolve a compilation error:
>     ./include/xen/domain_page.h:63:12: error: implicit declaration of function '__mfn_to_virt'; did you mean 'mfn_to_nid'? [-Werror=implicit-function-declaration]
>        63 |     return __mfn_to_virt(mfn_x(mfn));
>   This happens because __mfn_to_virt() is defined in , but due to
>   the current include chain:
>     
>       
>         
>           
>             
>               
>                 static inline void *map_domain_page_global(mfn_t mfn)
> 		{
> 		    return __mfn_to_virt(mfn_x(mfn));
>                 }
>             ...
>           ...
>           #define __mfn_to_virt() ...
>
>   This leads to a circular dependency and the build error above.
>
>   As a result, since  is no longer included in
>   , the flush_page_to_ram() definition cannot remain there.
>   It is now moved to riscv/mm.c.
>
> Including  from  does not cause issues with the
> declaration/definition of clear_page() when  is included, and
> also prevents build errors such as:
>   common/domain.c: In function 'alloc_domain_struct':
>   common/domain.c:797:5: error: implicit declaration of function 'clear_page';did you mean 'steal_page'? [-Werror=implicit-function-declaration]
>   797 |     clear_page(d);
>       |     ^~~~~~~~~~
>       |     steal_page
> caused by using clear_page() in common/domain.c.
>
> Signed-off-by: Oleksii Kurochko 

Acked-by: Andrew Cooper 

This does want further cleaning, but is a step in the right direction.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri Jun 13 18:53:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 18:53:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014843.1392925 (Exim 4.92)
	(envelope-from )
	id 1uQ9WY-0007kE-85; Fri, 13 Jun 2025 18:53:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014843.1392925; Fri, 13 Jun 2025 18:53:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uQ9WY-0007k7-3j; Fri, 13 Jun 2025 18:53:10 +0000
Received: by outflank-mailman (input) for mailman id 1014843;
 Fri, 13 Jun 2025 18:53: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 1uQ9WW-0007k1-O4
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 18:53:08 +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 a51d0b09-4887-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 20:53:07 +0200 (CEST)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-451d7b50815so20749355e9.2
 for ; Fri, 13 Jun 2025 11:53:07 -0700 (PDT)
Received: from [192.168.86.29] ([90.250.112.104])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4532e244392sm60202635e9.22.2025.06.13.11.53.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 13 Jun 2025 11:53:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a51d0b09-4887-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749840787; x=1750445587; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=r4pqSywwy5E6XetqBTJ/AuYfB1FShu9uVvjKe48qvTA=;
        b=DS+dQfvyCmmcWp6vym/hJTWqWCge5AnTdC2L6lH6zYDsIO9PSwqtalPY0aGBKr1P+I
         lxwO7sQU5QGYBuDYuH/11JEsj50qft8hScuJJzESzw6UbrBs7xBxGVToiUU9JWOkD/qp
         RGlgUbd7piZ0SCI8sP2I5LOoB4nlxKaJwPESA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749840787; x=1750445587;
        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=r4pqSywwy5E6XetqBTJ/AuYfB1FShu9uVvjKe48qvTA=;
        b=hv/4Tgyrugzr4/nur5dn4mKypYI2MsMKP9LOm32jxwWzzg0F2aOa3A33CsJ5Bvc4rU
         QCz0mjfzj1E5jz40ljX1r/IpV0UGivl2d61g7RZMCKcXnKSubQ5sG+M46rzzZZUn+jtX
         tqaT8dI53L9zLejXNdh1NFxvJjMddhho7SQ4G+Iy8LQB9qug0V7jy29UWffhivLznoLi
         Q65POfIXygxapymJxy8vNQGvYHtwwB8uKYo8WKbJ38CHZDAEAb2arlMlgLlRyjWm6crj
         DHWKMP6vMoOTqpFEGWtciVUIZDrc1q0ULiEEn2fHzk2t+gvQCBFXDskDZkedVjf5diDu
         6oJQ==
X-Forwarded-Encrypted: i=1; AJvYcCWhDCZdJ9vCaTaGjULuVvGCYVXLXXB15rXtHd1JamW2nboCheZMqPnZf3tkb63aQno0Rpe5hUbRYGI=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw6tJdRX4xH/cMBhVlfc8szx45CvdUvg+gvHhC5A39gDD8fAgrN
	Y7/Y+9Iwf5j/squrL+WopQ8R2/x8GJ8ERueuY7I1o7ZDsTf+pggz3/Gpn3/q2xeip3o=
X-Gm-Gg: ASbGnct83mvIVe213wMGfDZUnK5CYQLHwfT/lB6SDcub8p1PLQ/B67IE2TxlYnVznXG
	+LBdWQckwQVX3vObPt/Fw4bm4keIbvK9xWL9Qv1+4nLfNAlJhziiQ+0zZz1po43TaIsRi+89QYY
	xvIxWMiG0y9rYMNPFVMVrRA/xl+hMOQd9JyEFJg5wcQAlz2NM5igB2fnR9I3GlJJfd/Un6t4qsZ
	6efNv4j5c5EmsyE6q5gAT1aZ3wDXQJYBiX+3zociwxMPciaaxeE9exyJtEBZiY7W7mKcPDqd9W1
	OzOPxU+4mzYnDeNHoeuAL5/zc1Cye4iddTK43J1ZPZn2titaNJGK3HnTJKOXlr5+ds8f4vtB/no
	=
X-Google-Smtp-Source: AGHT+IHBhbZTFDOZwMMA6u6HG/I4FtGbRTvrwiaEm+ZErQcOzCKsTajytCT9w4lt+oid8IV3Fkg1UQ==
X-Received: by 2002:a05:6000:2890:b0:3a4:f7df:7564 with SMTP id ffacd0b85a97d-3a5718b448bmr1033400f8f.0.1749840786967;
        Fri, 13 Jun 2025 11:53:06 -0700 (PDT)
Message-ID: <7ef86c5b-80ad-4bcf-8028-ef98616a8924@citrix.com>
Date: Fri, 13 Jun 2025 19:53:05 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/2] xen/domain: introduce generic weak function for
 domain struct allocation
To: Oleksii Kurochko ,
 xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Anthony PERARD , Jan Beulich ,
 Shawn Anastasio ,
 Alistair Francis ,
 Bob Eshleman , Connor Davis 
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 13/06/2025 4:56 pm, Oleksii Kurochko wrote:
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index e566a18747..c134868e95 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -785,6 +785,20 @@ static int sanitise_domain_config(struct xen_domctl_createdomain *config)
>      return arch_sanitise_domain_config(config);
>  }
>  
> +struct domain *__weak alloc_domain_struct(void)
> +{
> +    struct domain *d = alloc_xenheap_pages(0, 0);

I know you're just moving what ARM has, but this is spelt
alloc_xenheap_page();

> +
> +    BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
> +
> +    if ( !d )
> +        return NULL;
> +
> +    clear_page(d);
> +
> +    return d;
> +}
> +

This looks fine, but you must do the same with free_domain_struct() at
the same time to keep the pair symmetric.  That in turn gets you an even
bigger negative diffstat, and x86 doesn't even need to override the
common version.

vCPU really wants doing at the same time, although you're going to run
into problems on ARM there with the BUILD_BUG_ON().

However, I suspect we want to be building with -ffunction-sections
generally active, or IIRC we'll still have the weak copy present in the
final image.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri Jun 13 20:14:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 20:14:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014908.1392934 (Exim 4.92)
	(envelope-from )
	id 1uQAn0-0000kK-W0; Fri, 13 Jun 2025 20:14:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014908.1392934; Fri, 13 Jun 2025 20:14:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uQAn0-0000kD-TI; Fri, 13 Jun 2025 20:14:14 +0000
Received: by outflank-mailman (input) for mailman id 1014908;
 Fri, 13 Jun 2025 20:14: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 1uQAmz-0000k7-Gq
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 20:14:13 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org
 [2600:3c04:e001:324:0:1991:8:25])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f45df033-4892-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 22:14:05 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 5E05E62A07;
 Fri, 13 Jun 2025 20:14:04 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 48881C4CEE3;
 Fri, 13 Jun 2025 20:14: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: f45df033-4892-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749845644;
	bh=n1UkvtsKm2vJ/JKTBSMySqwzeAMiL/PPMSVvLGHEvDA=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=sCqTZmHgw2iZk8/sWeJtwhluGnjHi4JcYdSFJBrm7/0La/RCUXxim9bUC3nrWo3Nf
	 aGtvL4eXVGi1YmaOa0HQpAxswTj9/9TDVez2EUcgeombW07/qZ7YL6OpR/bGuJHP0V
	 VokAb7m0hwRp3/kkZdTimrdjqOUVbMULtl1hbn9JYxNiKUJ97+ndd6Z06CfzjQ/lif
	 SSwkBEQJ3yO41/wRky6GiSGPI3K0mH16jloYWIFZ8/JfXSVEh3ZmM6sGnGCgt3Lg5r
	 GPbcyduww+DOulNBNj7WpOFSOe5bqbF/soIN1SfFT4e13KCq6yM6Odgx6OroFA0eQp
	 kFA18izH3wvvg==
Date: Fri, 13 Jun 2025 13:14:01 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
cc: Jan Beulich , 
    Stefano Stabellini , 
    Xen-devel , 
    Anthony PERARD , 
    Michal Orzel , Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Juergen Gross , Trammell Hudson , 
    Ross Lagerwall , 
    Frediano Ziglio , 
    Gerald Elder-Vass , 
    Kevin Lampis , 
    Andrew Cooper 
Subject: Re: [PATCH] docs: UEFI Secure Boot security policy
In-Reply-To: 
Message-ID: 
References: <20250611235851.167385-1-andrew.cooper3@citrix.com>  <608cf9c5-f057-4d3b-8833-8ef040064fec@suse.com> 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-762728654-1749845644=:8480"

  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-762728654-1749845644=:8480
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Fri, 13 Jun 2025, Marek Marczykowski-Górecki wrote:
> On Fri, Jun 13, 2025 at 08:35:26AM +0200, Jan Beulich wrote:
> > On 12.06.2025 23:32, Stefano Stabellini wrote:
> > > On Thu, 12 Jun 2025, Andrew Cooper wrote:
> > >> +Support in Xen
> > >> +--------------
> > >> +
> > >> +There are multiple ways to achieve this security goal, with differing
> > >> +tradeoffs for the eventual system.
> > >> +
> > >> +On one end of the spectrum is the Unified Kernel Image.  e.g. Xen is bundled
> > >> +with the dom0 kernel and init-ramdisk, with an embedded command line, and with
> > >> +livepatching and kexec compiled out, and suitably signed.  The signature is
> > >> +checked by the bootloader and, as this covers all the privileged code, Xen
> > >> +doesn't need to perform further checks itself.
> > >> +
> > >> +On the other end of the spectrum is maintaining the features of existing
> > >> +deployments.  e.g. Xen needs signature checking capabilities for the dom0
> > >> +kernel, livepatches and kexec kernels, and needs to allow the use of safe
> > >> +command line options while disallowing unsafe ones.
> > > 
> > > I just wanted to mention that there is one more option which I used in
> > > the past: the firmware/bootloader loads Xen, the Dom0 kernel, and other
> > > binaries, check their signatures, then boot Xen.
> > > 
> > > This is similar to the "Unified Kernel Image" approach in the sense that
> > > Xen doesn't need to do any signature checking for the dom0 kernel, but
> > > it doesn't require all the binaries to be glued together.
> > > 
> > > Assuming that the firmware/bootloader is capable of loading multiple
> > > binaries and checking the signature of multiple binaries before booting
> > > the next element, it works fine.
> > 
> > How would an initrd, a ucode blob, or an XSM policy blob be signed?
> 
> At least grub supports gpg detached signatures, and can be configured to
> require them.

That's right. U-boot supports something similar as well.
--8323329-762728654-1749845644=:8480--


From xen-devel-bounces@lists.xenproject.org Fri Jun 13 21:29:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 21:29:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014942.1392946 (Exim 4.92)
	(envelope-from )
	id 1uQBxG-0000en-8V; Fri, 13 Jun 2025 21:28:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014942.1392946; Fri, 13 Jun 2025 21:28: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 1uQBxG-0000eg-4P; Fri, 13 Jun 2025 21:28:54 +0000
Received: by outflank-mailman (input) for mailman id 1014942;
 Fri, 13 Jun 2025 21:28: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 1uQBxF-0000ea-C7
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 21:28:53 +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 66b57bb3-489d-11f0-a309-13f23c93f187;
 Fri, 13 Jun 2025 23:28:52 +0200 (CEST)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-45310223677so21721515e9.0
 for ; Fri, 13 Jun 2025 14:28:51 -0700 (PDT)
Received: from [192.168.86.29] ([90.250.112.104])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4532e268de2sm63353035e9.40.2025.06.13.14.28.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 13 Jun 2025 14:28:50 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 66b57bb3-489d-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1749850131; x=1750454931; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=cQOKjkQulsizKiLm5UcaiTbCzLcGc8rQoJUelijvatQ=;
        b=C8mQpD6B6kt+I5SBk8ZbRE2kQehed7hwIlzCfaPhEfIrtDx36T0cbMKXeZoNwMT/Pw
         YbjG5RC9hVHX9d33AV1CupM5qvdY1GlRXAnoMq7XFnV9EQCvUe1xd7qAZtJ4chQKZ6mo
         f92fBLmI32wGXBYVPjNaIHz1iNYm/VEYijiBc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749850131; x=1750454931;
        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=cQOKjkQulsizKiLm5UcaiTbCzLcGc8rQoJUelijvatQ=;
        b=emlp0bTQXRz8VkSoKlygCF+1MvAVnHa31YCH4NEAJySvgaqISclgOAMmJNqqvG5cWp
         B+kJd2oJr7BlblWHDlEeM6immZaMeAs+kMnxZ/g2TnIjXZmFiIvdOsPCWkOfteWT1eTS
         MTP+SpjANXzWxZReU8sJ6/bP6uskl5TgKhqQMk+zSmHhoGMcPlFyEoIpr4SHECrv1/lV
         bTfRQgOYg3IRxixhLZdjk9f9Zf3zQRC1uvoGU4J+wti+4YuaTc8Z2RMQ02qiuZ4zyW13
         2dhjHqA0cBJNes8CJJD7dfyODVW5Nx9CUdgZZSXNidT0fyjR6nv05GL9RY1UHcfAzZnx
         oNJg==
X-Forwarded-Encrypted: i=1; AJvYcCVXIJFLlO053uFv75DMe8cNYX3bdtxiAV4a6XxW8SExgYf9OsyOgNwrcapRHWulX4K8vW0mUUUPpaM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyu94u8x5THo1r2VfL2v347UfBBpRE7WgxCxqPY0vljkUsG7Thf
	Jv8Wh25XUotMy/GOgt0cq4s97HW3q08g6ItvihaeKwbyxxNbofyKsMIOHvPFwsplicw=
X-Gm-Gg: ASbGnctG2ikDZCLRjK4+NiIJzpWGsje/sOgkZcQtjn5V1dnClmbKyuXlmuE4eLfWEjO
	fYqIuZiul7gcLu5Paws/SpGK2pAvDlrKJMxr/WX7oJ2ez8sKkkhJ6CAxqB078xwV8+juZ1KFxzq
	DytYzaS+0HEpZ41RhaozPFeH0pSoQ9+/q9I0evqgDPwQ8DRXxDKVVzqgl5Rz+tmJCaTKV1dCevw
	Cv2i2iPisvrlK5rbNENam4hninEOcw23Zh0faMl6U3K4RbWz5fyYuNEr3PE1gYWCiJmLOFv1puC
	XZrOqR1/KhT5V9j4Cl4n7jXH674KIcBZGlp41KKCRbuGQImbEpA29KJ3VtcPJNMI6EGFRf8Z6Bk
	=
X-Google-Smtp-Source: AGHT+IEGEgciZZYICSnuUD/+VQ46lh9Xp0U/h7JzgyzUX6oywN5jQPRXYnrk1qPrKLI/2bTns0nbOw==
X-Received: by 2002:a05:600c:1c90:b0:443:48:66d2 with SMTP id 5b1f17b1804b1-4533caf5cc0mr11920355e9.16.1749850131263;
        Fri, 13 Jun 2025 14:28:51 -0700 (PDT)
Message-ID: 
Date: Fri, 13 Jun 2025 22:28:50 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/3] x86/EFI: Fix detection of buildid
To: Jan Beulich 
Cc: Ross Lagerwall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 "Daniel P . Smith" ,
 Xen-devel 
References: <20250605111638.2869914-1-andrew.cooper3@citrix.com>
 <20250605111638.2869914-2-andrew.cooper3@citrix.com>
 <0a314400-126a-4c2a-b36c-dda61bb0b751@suse.com>
 
 <4d1f1b70-e309-453b-bae6-e066d49a417a@suse.com>
 <9200277c-aa8e-4fd9-ab6a-f9e106114f54@citrix.com>
 <6eaf2b27-969a-4326-9726-8b6e0994e006@suse.com>
 <3f9c5a18-2ea1-4e2d-80a0-773abc3598ae@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 10/06/2025 9:01 am, Jan Beulich wrote:
> On 06.06.2025 17:01, Andrew Cooper wrote:
>> On 06/06/2025 8:22 am, Jan Beulich wrote:
>>> On 05.06.2025 19:01, Andrew Cooper wrote:
>>>> On 05/06/2025 2:24 pm, Jan Beulich wrote:
>>>>> On 05.06.2025 14:14, Andrew Cooper wrote:
>>>>>> On 05/06/2025 1:02 pm, Jan Beulich wrote:
>>>>>>> On 05.06.2025 13:16, Andrew Cooper wrote:
>>>>>> This really is a property of being a PE32+ binary, and nothing to do
>>>>>> with EFI.
>>>>> Which still can be checked for without having this code path being taken
>>>>> for xen.gz, too: You could e.g. check for &efi > &_end. That's firmly an
>>>>> image property (yet I expect you're going to sigh about yet another hack).
>>>> It's all hacks, but no.
>>>>
>>>> I'm amazed MISRA hasn't spotted that we've got a global `struct efi
>>>> efi;` and a label named efi, creating an alias for the object with it
>>>> out of bounds in the compiled image.  But even then, it's based on
>>>> XEN_BUILD_EFI not XEN_BUILD_PE and does not distinguish the property
>>>> that matters.
>>> The use of XEN_BUILD_EFI in the linker script should have been switched
>>> to XEN_BUILD_PE when the split was introduced.
>> That doesn't build.  As I already explained, the stubs aren't split in a
>> way that allows that.
> Which then is a pretty clear indication that the split was wrong to do in
> the first place, don't you agree?

I think my feelings on how xen.efi was done are quite well known, but so
what?

I've spent longer than I can afford trying to untangle this, and its an
impenetrable mess.

>>>> But the argument I'm going to make this this:  Why do you want a check,
>>>> even if you can find a correct one (and as said before, I cannot)?
>>>>
>>>> This function is run exactly once.  We've excluded "nothing given by the
>>>> toolchain", and excluded "what the toolchain gave us was not the
>>>> expected ELF note".  The only thing left (modulo toolchain bugs) is the
>>>> CodeView region, and if it's not a valid CodeView region then we've
>>>> wasted a handful of cycles.
>>> Two reasons: Having code which cannot possibly do anything useful isn't
>>> good. Misra calls the latest the body of the inner if() "unreachable code"
>>> and objects to the presence of such in a build.
>> It's not unreachable code, not even theoretically.
> How is it not? If we build without this CodeView record, it very much is
> unreachable.

Compiling without a CodeView record doesn't magically cause the prior
logic to guarantee to succeed.

The compiler is forced to emit real conditional logic, and there's
almost 2^96 bit-pattens the toolchain could put into memory which will
very literally reach the CodeView check.

"The toolchain shouldn't cause this path to be executed" is not the same
as genuinely unreachable.

What safety certification is liable to complain about is the inability
to construct a test that demonstrates coverage, but I'm not changing
that property with this patch.
>>> And then, based on your reasoning above, why don't you also drop the
>>> #ifdef CONFIG_X86?
>> Because that's the one non-buggy way of excluding an impossible case.
>>
>> x86 is the only architecture possibly linking with pep emulation, and
>> therefore the only architecture to possibly have a CodeView record.
> And how's the, say, Arm case different from the x86 case with no such
> record built in? 

Because its currently impossible for ARM to have a codeview record.

Remember that ARM writes a MZ/PE header by hand in a flat binary.  It
does not use a PEP linker.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri Jun 13 21:31:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 21:31:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014949.1392955 (Exim 4.92)
	(envelope-from )
	id 1uQBzZ-0002CD-Io; Fri, 13 Jun 2025 21:31:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014949.1392955; Fri, 13 Jun 2025 21: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 1uQBzZ-0002C6-Fm; Fri, 13 Jun 2025 21:31:17 +0000
Received: by outflank-mailman (input) for mailman id 1014949;
 Fri, 13 Jun 2025 21:31: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 1uQBzY-0002C0-Gh
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 21:31:16 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b621f1ba-489d-11f0-b894-0df219b8e170;
 Fri, 13 Jun 2025 23:31:06 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 6D7A043A5F;
 Fri, 13 Jun 2025 21:31:04 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4F651C4CEE3;
 Fri, 13 Jun 2025 21:31:03 +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: b621f1ba-489d-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749850264;
	bh=TCTvJZPfNya2wmawUjIhBjizU6uMiRdystFvzNwHQxg=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=fjkF5Ch11BoMQz8usTpv5JcnStEWSXHgxE9GggQDtDVmT3344fAYwvY5tNjmKDX2r
	 2QDO3fr5549bgyUjxZLRVkJmv6bDouxgQXB+wDGk8Q1vV5FvZP7XlMYlY23/y67/Yw
	 OVqkJ3Da81j2nIzWm+V8Nj8turlQg03AUh7H0fnYMn8rpVj+HH42E0bwpw8rbH3DIZ
	 Dx8kN6xGdyiGbXJ3H+8TBKI2Lavnm/mWSGpQY7InIA5orceVmKMHtMO5hjlfFFKT9P
	 QUjFkeeX6qQ4dyRrHBY2k9JRjByx+inG8O1Gkwnqn4qPElEtwFpJDFaSt8QpGtWuPz
	 TdphKy5Kukfsg==
Date: Fri, 13 Jun 2025 14:31:02 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Andrew Cooper , 
    Ross Lagerwall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , 
    "Daniel P . Smith" , 
    Xen-devel , sstabellini@kernel.org
Subject: Re: [PATCH 1/3] x86/EFI: Fix detection of buildid
In-Reply-To: <6eaf2b27-969a-4326-9726-8b6e0994e006@suse.com>
Message-ID: 
References: <20250605111638.2869914-1-andrew.cooper3@citrix.com> <20250605111638.2869914-2-andrew.cooper3@citrix.com> <0a314400-126a-4c2a-b36c-dda61bb0b751@suse.com>  <4d1f1b70-e309-453b-bae6-e066d49a417a@suse.com>
 <9200277c-aa8e-4fd9-ab6a-f9e106114f54@citrix.com> <6eaf2b27-969a-4326-9726-8b6e0994e006@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-1885957098-1749850095=:8480"
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-1885957098-1749850095=:8480
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: 8BIT
Content-ID: 

On Fri, 6 Jun 2025, Jan Beulich wrote:
> > But the argument I'm going to make this this:  Why do you want a check,
> > even if you can find a correct one (and as said before, I cannot)?
> > 
> > This function is run exactly once.  We've excluded "nothing given by the
> > toolchain", and excluded "what the toolchain gave us was not the
> > expected ELF note".  The only thing left (modulo toolchain bugs) is the
> > CodeView region, and if it's not a valid CodeView region then we've
> > wasted a handful of cycles.
> 
> Two reasons: Having code which cannot possibly do anything useful isn't
> good. Misra calls the latest the body of the inner if() "unreachable code"
> and objects to the presence of such in a build. (I'm pretty sure Eclair
> wouldn't spot it, but that doesn't eliminate this being a violation of
> the respective rule.)

As far as I can tell this code can be reachable simply by having an
appropriate test with Xen booted via a non-EFI method and a CodeView
record being present. No code changes to Xen needed.


> And then, based on your reasoning above, why don't you also drop the
> #ifdef CONFIG_X86?

Because while theoretically possible, today there is not a single test
that would allow us to trigger this code on ARM. We would need to change
Xen to do it first.
--8323329-1885957098-1749850095=:8480--


From xen-devel-bounces@lists.xenproject.org Fri Jun 13 22:02:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 22:02:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1014983.1392965 (Exim 4.92)
	(envelope-from )
	id 1uQCTl-00068v-TT; Fri, 13 Jun 2025 22:02:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1014983.1392965; Fri, 13 Jun 2025 22: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 1uQCTl-00068o-Ps; Fri, 13 Jun 2025 22:02:29 +0000
Received: by outflank-mailman (input) for mailman id 1014983;
 Fri, 13 Jun 2025 22:02:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uQCTj-00068P-Av
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 22:02:28 +0000
Received: from 16.mo583.mail-out.ovh.net (16.mo583.mail-out.ovh.net
 [87.98.174.144]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 15e4d123-48a2-11f0-a309-13f23c93f187;
 Sat, 14 Jun 2025 00:02:24 +0200 (CEST)
Received: from director8.ghost.mail-out.ovh.net (unknown [10.109.139.43])
 by mo583.mail-out.ovh.net (Postfix) with ESMTP id 4bJtfl3BRfz1V6B
 for ; Fri, 13 Jun 2025 22:02:23 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-s646q (unknown [10.110.178.126])
 by director8.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 64279C0298;
 Fri, 13 Jun 2025 22:02:22 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.102])
 by ghost-submission-5b5ff79f4f-s646q with ESMTPSA
 id IUl4Ae6fTGi+Li0ALs7SAA
 (envelope-from ); Fri, 13 Jun 2025 22:02: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: 15e4d123-48a2-11f0-a309-13f23c93f187
Authentication-Results:garm.ovh; auth=pass (GARM-102R004075e58a4-1b67-4f52-abf0-04d9927e4d83,
                    FF81FBFBD66CD586AFAA25B56E63FC5C08F599B2) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
Date: Sat, 14 Jun 2025 01:01:52 +0300
From: Sergii Dmytruk 
To: ross.philipson@oracle.com
Cc: xen-devel@lists.xenproject.org, Jan Beulich ,
	Andrew Cooper ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	"Daniel P. Smith" ,
	trenchboot-devel@googlegroups.com
Subject: Re: [PATCH v3 08/22] x86/slaunch: restore boot MTRRs after Intel TXT
 DRTM
Message-ID: 
References: 
 <5b6b9bf165a4fd9444dc53848fb8faa2cea30781.1748611041.git.sergii.dmytruk@3mdeb.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
X-Ovh-Tracer-Id: 11524429973350954140
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugdduledutdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtugfgjgesthekredttddtjeenucfhrhhomhepufgvrhhgihhiucffmhihthhruhhkuceoshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmqeenucggtffrrghtthgvrhhnpeevveevgefgvdekvefhffevgeejgffghfehiedvffdtgfevudetkefhgfekfeffvdenucfkphepuddvjedrtddrtddruddpudejiedrudduuddrudekgedrvddvuddpfeejrdehledrudegvddruddtvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmpdhnsggprhgtphhtthhopedupdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdfovfetjfhoshhtpehmohehkeefmgdpmhhouggvpehsmhhtphhouhht
DKIM-Signature: a=rsa-sha256; bh=uROBNkJrqlizsEP7Y2MP2ACbfBDRCUXSKMG0sr3LgHo=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1749852143; v=1;
 b=aCPfZbdkfSXf8dWSfQpilUNY7+JpvfN2+7vD6bNaXD7E/lHZGXbZOPn47iaDcxiL6soTGM/T
 LmYOiO2dPNo7Ch75UkNphlX9AU3xk3r5YYAapUrIoiDK//+plfB/v3wz76TE/RjRMEnyEFIKxhg
 M/BqKN1cIUIziNN+kgH/sNVggtyFBTGjROTAXU8+QF6mneZJAAxFuHcwv3gvwT+ugqFv0WLMJ7S
 a100INb8eUmQX6mdBgv7Y/TUcpfpbCI2xYbT4i8YC0q/tyadOrcy0WjbkCFri/38rB8Ux3wCsBE
 FVNd2OEqGIhasRnIK+egv15qV2iycKMTR6ztb6+ugy66A==

On Tue, Jun 03, 2025 at 12:43:30PM -0700, ross.philipson@oracle.com wrote:
> On 5/30/25 6:17 AM, Sergii Dmytruk wrote:
> > From: Krystian Hebel 
> >
> > In preparation for TXT SENTER call, GRUB had to modify MTRR settings
> > to be UC for everything except SINIT ACM. Old values are restored
> > from SLRT where they were saved by the bootloader.
> >
> > Signed-off-by: Krystian Hebel 
> > Signed-off-by: Michał Żygowski 
> > Signed-off-by: Sergii Dmytruk 
> > ---
> >   xen/arch/x86/e820.c                  |  5 ++
> >   xen/arch/x86/include/asm/intel-txt.h |  3 ++
> >   xen/arch/x86/intel-txt.c             | 75 ++++++++++++++++++++++++++++
> >   3 files changed, 83 insertions(+)
> >
> > diff --git a/xen/arch/x86/e820.c b/xen/arch/x86/e820.c
> > index ca577c0bde..60f00e5259 100644
> > --- a/xen/arch/x86/e820.c
> > +++ b/xen/arch/x86/e820.c
> > @@ -11,6 +11,8 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> > +#include 
> >   /*
> >    * opt_mem: Limit maximum address of physical RAM.
> > @@ -442,6 +444,9 @@ static uint64_t __init mtrr_top_of_ram(void)
> >       ASSERT(paddr_bits);
> >       addr_mask = ((1ULL << paddr_bits) - 1) & PAGE_MASK;
> > +    if ( slaunch_active )
> > +        txt_restore_mtrrs(e820_verbose);
> > +
>
> I was just curious why they are being restored here in the e820 code? It
> seems that could be restored earlier. Until they are restored, most of RAM
> is set UC as you know. I also don't have an exact idea how early in Xen boot
> cycle this is occurring so maybe this is fine but obviously for performance
> reasons it should be done as early as possible.
>
> Thanks,
> Ross

Original MTRR values are in SLRT which is deliberately measured before
being used by e820 code.  I'm not sure if anything precludes moving that
part (mapping memory, interacting with TPM) earlier in __start_xen().
Could be worth trying moving it up.

Regards


From xen-devel-bounces@lists.xenproject.org Fri Jun 13 22:24:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 22:24:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1015001.1392975 (Exim 4.92)
	(envelope-from )
	id 1uQCpG-0000Ud-IR; Fri, 13 Jun 2025 22:24:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1015001.1392975; Fri, 13 Jun 2025 22:24:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uQCpG-0000UW-Eo; Fri, 13 Jun 2025 22:24:42 +0000
Received: by outflank-mailman (input) for mailman id 1015001;
 Fri, 13 Jun 2025 22:24: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 1uQCpE-0000UN-PK
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 22:24:40 +0000
Received: from 1.mo550.mail-out.ovh.net (1.mo550.mail-out.ovh.net
 [178.32.127.22]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 313ef355-48a5-11f0-a309-13f23c93f187;
 Sat, 14 Jun 2025 00:24:38 +0200 (CEST)
Received: from director6.ghost.mail-out.ovh.net (unknown [10.109.139.201])
 by mo550.mail-out.ovh.net (Postfix) with ESMTP id 4bJv8Q49gsz1YLg
 for ; Fri, 13 Jun 2025 22:24:38 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-6jjqj (unknown [10.108.42.231])
 by director6.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 9E5BF802E3;
 Fri, 13 Jun 2025 22:24:37 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.105])
 by ghost-submission-5b5ff79f4f-6jjqj with ESMTPSA
 id nFo/ESWlTGhd0AgALAQsQw
 (envelope-from ); Fri, 13 Jun 2025 22:24: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: 313ef355-48a5-11f0-a309-13f23c93f187
Authentication-Results:garm.ovh; auth=pass (GARM-105G006f1ff3a90-cd89-4239-a7a0-de23ff67a778,
                    FF81FBFBD66CD586AFAA25B56E63FC5C08F599B2) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
Date: Sat, 14 Jun 2025 01:24:08 +0300
From: Sergii Dmytruk 
To: ross.philipson@oracle.com
Cc: xen-devel@lists.xenproject.org, Jan Beulich ,
	Andrew Cooper ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	"Daniel P. Smith" ,
	trenchboot-devel@googlegroups.com
Subject: Re: [PATCH v3 10/22] x86/tpm.c: code for early hashing and extending
 PCRs (for TPM1.2)
Message-ID: 
References: 
 <0c249037eeda4809b565a55c6473bb21cdd0304e.1748611041.git.sergii.dmytruk@3mdeb.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Ovh-Tracer-Id: 11900199069111596188
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugdduledugecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhepvdfgveegtdffhfdugeevieehkeetudevfeefgedtleejledvfeeutdetudeiveelnecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukeegrddvvddupdefjedrheelrddugedvrddutdehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheehtdgmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=HSF48yJbymb3K12BUt7XLwXdb3ZWzPjRxTfidSxircw=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1749853478; v=1;
 b=TCBmiCcQSftaz2PrVRp0JaQyvpz6UOj6p191w13sMg0TC8nFTExcxSS6HYwzQ5DVXuCV4AZ6
 7jXMUpYXv5/Q4kNj5BXCdIca3MpsF1Z31h0lmWav6nuTes7yZLkH9MfGBFZxdcKL3r6wdAtPvt1
 MGR4M230wGYEBplx/mIGLeePe/RaITpbx3itu2uklBwA/pvW2jeIXSSQ9yOuAHHBtP/dt8JLOCR
 /ZOmnNOX58S9O7clmf85I9AsO+po9ZlqHfGE4TOF1ytTo2hcI1jQtlanNsM1SNhuTSpJK1djetT
 kn0haUiolyuvuWGTJIcUJfH4DfL4Tyg1OcEK8gWPK5BMg==

On Thu, Jun 05, 2025 at 10:43:10AM -0700, ross.philipson@oracle.com wrote:
> > +static void send_cmd(unsigned loc, uint8_t *buf, unsigned i_size,
> > +                     unsigned *o_size)
> > +{
> > +    /*
> > +     * Value of "data available" bit counts only when "valid" field is set as
> > +     * well.
> > +     */
> > +    const unsigned data_avail = STS_VALID | STS_DATA_AVAIL;
> > +
> > +    unsigned i;
> > +
> > +    /* Make sure TPM can accept a command. */
> > +    if ( (tis_read8(TPM_STS_(loc)) & STS_COMMAND_READY) == 0 )
> > +    {
> > +        /* Abort current command. */
> > +        tis_write8(TPM_STS_(loc), STS_COMMAND_READY);
> > +        /* Wait until TPM is ready for a new one. */
> > +        while ( (tis_read8(TPM_STS_(loc)) & STS_COMMAND_READY) == 0 );
> > +    }
> > +
> > +    for ( i = 0; i < i_size; i++ )
> > +        tis_write8(TPM_DATA_FIFO_(loc), buf[i]);
> > +
> > +    tis_write8(TPM_STS_(loc), STS_TPM_GO);
> > +
> > +    /* Wait for the first byte of response. */
> > +    while ( (tis_read8(TPM_STS_(loc)) & data_avail) != data_avail);
> > +
> > +    for ( i = 0; i < *o_size && tis_read8(TPM_STS_(loc)) & data_avail; i++ )
> > +        buf[i] = tis_read8(TPM_DATA_FIFO_(loc));
> > +
> > +    if ( i < *o_size )
> > +        *o_size = i;
> > +
> > +    tis_write8(TPM_STS_(loc), STS_COMMAND_READY);
> > +}

> Is this all that is needed to do the send? I would have thought you would at
> least also need that burst count logic to know when the TPM is ready for
> more data. There are also a number of timeouts that are supposed to be used.
> Maybe Daniel has some thoughts too.

The code in this form works without any issues.  Don't know why
burst count isn't taken into account here or why nothing breaks without
it, but this does seem wrong.  I think we needed something to work
before Daniel's version was ready and this implementation possibly
wasn't meant to stay.

> > +static inline bool is_tpm12(void)
> > +{
> > +    /*
> > +     * If one of these conditions is true:
> > +     *  - INTF_CAPABILITY_x.interfaceVersion is 0 (TIS <= 1.21)
> > +     *  - INTF_CAPABILITY_x.interfaceVersion is 2 (TIS == 1.3)
> > +     *  - STS_x.tpmFamily is 0
> > +     * we're dealing with TPM1.2.
> > +     */
> > +    uint32_t intf_version = tis_read32(TPM_INTF_CAPABILITY_(0))
> > +                          & INTF_VERSION_MASK;
> > +    return (intf_version == 0x00000000 || intf_version == 0x20000000 ||
> > +            (tis_read32(TPM_STS_(0)) & TPM_FAMILY_MASK) == 0);
> > +}
> > +
> > +/****************************** TPM1.2 specific *******************************/
> > +#define TPM_ORD_Extend              0x00000014
> > +#define TPM_ORD_SHA1Start           0x000000A0
> > +#define TPM_ORD_SHA1Update          0x000000A1
> > +#define TPM_ORD_SHA1CompleteExtend  0x000000A3
> > +
> > +#define TPM_TAG_RQU_COMMAND         0x00C1
> > +#define TPM_TAG_RSP_COMMAND         0x00C4
>
> I am not sure what the long term goal for a TPM driver in Xen might be but
> my suggestion is to lay out the driver more cleanly up front. Split the
> specification defined things (e.g. these things and other from TCG etc) from
> the driver implementation specific definitions and put them in separate
> headers. There is little enough core code now that just putting it all in
> tpm.c seems fine. Just my $0.02...
>
> Thanks,
> Ross

It could help readability to not have it all in one file.  Don't know
about plans for evolving the code for future use cases.

Regards


From xen-devel-bounces@lists.xenproject.org Fri Jun 13 22:47:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 22:47:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1015012.1392985 (Exim 4.92)
	(envelope-from )
	id 1uQDBA-0003F9-Ds; Fri, 13 Jun 2025 22:47:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1015012.1392985; Fri, 13 Jun 2025 22:47: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 1uQDBA-0003F2-BE; Fri, 13 Jun 2025 22:47:20 +0000
Received: by outflank-mailman (input) for mailman id 1015012;
 Fri, 13 Jun 2025 22:47: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 1uQDB9-0003Er-D2
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 22:47:19 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 59d9624b-48a8-11f0-b894-0df219b8e170;
 Sat, 14 Jun 2025 00:47:15 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 20E6A629D0;
 Fri, 13 Jun 2025 22:47:14 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2FC31C4CEEB;
 Fri, 13 Jun 2025 22:47: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: 59d9624b-48a8-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749854833;
	bh=ytw8JNslhXak2snPnJT5eJ2x9/n08SccQf+B2eSiPYo=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=oPuJcui8vBUye4pT6dkFenl4HHY8g9hvsKp4GRgAuFUV3WDDCVLaG3Nm2YV02AaH2
	 1IysDwLZC2ILM0/1zlEwgEjPoy59MwN4i+PcnHZlp2c70r7Redx9I2pB0AtlwmOvl8
	 63/ilqmDfLBoSOvoGr4wdrHceNLX4EvTJ2qmMmmSDTapeflI05vX2+iUSnF7TrYV1/
	 +Z/OUeNYAxuFnOtCYMxJ9+cXh2DIaBa+N0m/cFxaBNc6v4RogP+f1qIxAkyreQqxO6
	 Q+wATGgN2NjLajq79VcK7/oWnKirQnrHzLYlCxy5fPj4BAseUnpLhDNdW+zy/FVC9w
	 ayVjTfNyC/H/w==
Date: Fri, 13 Jun 2025 15:47:10 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Jason Andryuk , 
    Christian Lindig , 
    David Scott , Anthony PERARD , 
    Andrew Cooper , 
    Michal Orzel , Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini , 
    Bertrand Marquis , 
    Volodymyr Babchuk , 
    "Daniel P. Smith" , 
    xen-devel@lists.xenproject.org
Subject: Re: [PATCH 3/4] xen: Add DOMAIN_CAPS_DEVICE_MODEL &
 XEN_DOMCTL_CDF_device_model
In-Reply-To: 
Message-ID: 
References: <20250610225737.469690-1-jason.andryuk@amd.com> <20250610225737.469690-4-jason.andryuk@amd.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 Jun 2025, Jan Beulich wrote:
> On 11.06.2025 00:57, Jason Andryuk wrote:
> > To add more flexibility in system configuration add the new
> > DOMAIN_CAPS_DEVICE_MODEL flag and XEN_DOMCTL_CDF_device_model.
> > 
> > Thie new flag corresponds to allowing XSM_DM_PRIV for the domain.  This
> > will enable running device model emulators (QEMU) from the assigne
> > domain for multiple target domains.
> > 
> > Stubdoms assign target allowing the stubdom to serve as the device
> > model for a single domain.  This new flag allows the single domain to
> > provide emulators for multiple guests.
> > 
> > The specific scenario is a disaggregated system with the hardware domain
> > providing device models for muitple guest domains.
> 
> Why the hardware domain? Unless a DM also needs access to some of the
> physical hardware, it ought to run in a separate domain. Conceivably
> such a domain could service multiply guests, so maybe the "single
> target" concept presently used for stubdom simply needed extending?

Not necessarily. While it is possible to have driver domains, it is not
the default configuration.

In a default configuration, the hardware domain gets all the hardware by
default and therefore will also run the PV backends and Virtio backends.
The Virtio backends require DM hypercalls. Let me elaborate further.

In the datacenter, we have Dom0 typically with all the hardware, the
backends (PV and Virtio), and also the toolstack. Then all other domains
are created dynamically by the toolstack. Driver domains are possible
but not very common.

In automotive/embedded, the total number of domains is static, so we can
create them using dom0less. We don't need the toolstack to create VMs.
Also, we have safety concerns, so we want to take away as much
privileges as possible from Dom0. This is easy because thanks to
dom0less, we don't need the toolstack and we don't need to create VMs
dynamically.

So the model is that Dom0 becomes the hardware domain: it has all the
drivers and backends but it is not privileged in the sense of
creating/destroying other VMs. If a user wants to have Dom0 "super
powers", they can create an optional Control Domain. The Control Domain
is expected to be tiny, such as XTF or Zephyr. It will have the ability
that Dom0 used to have but without the drivers. From a privilege
perspective, the Control Domain could create additional VMs, but in
automotive/embedded it is not expected to be a use-case because the
total number of VMs is still static. 

So your point about driver domains. Yes, one can have driver domains the
same way that one can have driver domains in the datacenter but it is
not the default. The new default for embedded is what I described above
and I think it is a very widely applicable concept across industries:
automotive, industrial, robotics, etc. and also across vendors: AMD,
Xilinx, Renesas, EPAM, ARM, etc.


From xen-devel-bounces@lists.xenproject.org Fri Jun 13 22:52:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 22:52:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1015019.1392995 (Exim 4.92)
	(envelope-from )
	id 1uQDFe-0004lz-Qv; Fri, 13 Jun 2025 22:51:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1015019.1392995; Fri, 13 Jun 2025 22:51: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 1uQDFe-0004ls-OC; Fri, 13 Jun 2025 22:51:58 +0000
Received: by outflank-mailman (input) for mailman id 1015019;
 Fri, 13 Jun 2025 22:51: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 1uQDFd-0004lm-Sn
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 22:51: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 00bddc53-48a9-11f0-b894-0df219b8e170;
 Sat, 14 Jun 2025 00:51:55 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 193EC5C5DBA;
 Fri, 13 Jun 2025 22:49:37 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0C0FCC4CEE3;
 Fri, 13 Jun 2025 22:51:51 +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: 00bddc53-48a9-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749855113;
	bh=kJxIN50HwZ1kSekdF12jWd03NviJbPOIP0orbuA3eps=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=lX04w34Vu3TMZP4jAl2wDHl2HcYCeuBTh63RDBlgQihcqETLHEwb6mM4bHAruPPC2
	 YTAXKCrInpIwI1AD24yPRbTMh3C0ex3oDt0nq2QadeYGvfvT0hZbPJ8hIz4UEiaXbB
	 b7d9G1zXVLHFJp6Cj0W+due6iDn07s9wP0r6jVSg6q7G+miZ9QwR0fKhmwZdTs2Dhg
	 I7JPLPkjuRw641QsJDZIDnGvqQQNS9jnqWJlKvVuvNJuqVsUMZL2ojL02VPgg3rLWx
	 0s1kpIc6sP9FwLhCGR7qKYMXUBdB2Pu3CVWvQmRn5yGs8gAxXLIQbcNMu18FObV1Cy
	 MwK2FQFmlODzg==
Date: Fri, 13 Jun 2025 15:51:50 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jason Andryuk 
cc: Jan Beulich , 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
Subject: Re: [PATCH 4/4] xsm/dummy: Allow hwdom SYSCTL_readconsole/physinfo
In-Reply-To: 
Message-ID: 
References: <20250610225737.469690-1-jason.andryuk@amd.com> <20250610225737.469690-5-jason.andryuk@amd.com> <5f6d43da-2600-4c1c-9bcb-f13e8fce921e@suse.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 Jun 2025, Jason Andryuk wrote:
> On 2025-06-11 09:27, Jan Beulich wrote:
> > On 11.06.2025 00:57, Jason Andryuk wrote:
> > > Allow the hwdom to access the console, and to access physical
> > > information about the system.
> > > 
> > > xenconsoled can read Xen's dmesg.  If it's in hwdom, then that
> > > permission would be required.
> > 
> > Why would xenconsoled run in the hardware domain? It's purely a software
> > construct, isn't it? As a daemon, putting it in the control domain may
> > make sense. Otherwise it probably ought to go in a service domain.
> 
> My approach has been to transform dom0 into the hardware domain and add a new
> control domain.  xenconsoled was left running in the hardware domain.

I think we should keep xenconsoled in the hardware domain because the
control domain should be just optional. (However, one could say that with
Denis' recent changes xenconsoled is also optional because one can use
console hypercalls or emulators (PL011, NS16550) for all DomUs.)



> I suppose it could move.  Maybe that would be fine?  I haven't tried. The
> Hyperlaunch code populates the console grants to point at the hardware domain,
> and I just followed that.
> 
> One aspect of why I left most things running in the Hardware domain was to not
> run things in the Control domain.  If Control is the highest privileged
> entity, we'd rather run software in lower privileged places. Especially
> something like xenconsoled which is receiving data from the domUs.

Yes, I agree with Jason. It is a bad idea to run xenconsoled in the
Control Domain because the Control Domain is meant to be safe from
interference. We want to keep the number of potential vehicles for
interference down to a minimum and shared memory between Control Domain
and DomUs is certainly a vehicle for interference.


From xen-devel-bounces@lists.xenproject.org Fri Jun 13 22:59:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 22:59:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1015026.1393004 (Exim 4.92)
	(envelope-from )
	id 1uQDMg-0005Lx-H2; Fri, 13 Jun 2025 22:59:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1015026.1393004; Fri, 13 Jun 2025 22:59: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 1uQDMg-0005Lq-Dy; Fri, 13 Jun 2025 22:59:14 +0000
Received: by outflank-mailman (input) for mailman id 1015026;
 Fri, 13 Jun 2025 22:59: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 1uQDMf-0005Lk-6I
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 22:59:13 +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 04826943-48aa-11f0-a309-13f23c93f187;
 Sat, 14 Jun 2025 00:59:11 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 472155C5EAE;
 Fri, 13 Jun 2025 22:56:53 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id EA787C4CEE3;
 Fri, 13 Jun 2025 22:59:07 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 04826943-48aa-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749855549;
	bh=M7HjTnP6AklMB8JVcgr0sPm3URJ6h3TEpsF0SvDE9Mk=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=KGkmN6y0tgc7lHXJeALH45FONXWD8mEYcS8UTK6cc5vrTQ48QT5t1YGYTl6hfBtlk
	 PaLaQfaQPz54Nuh+vBcP02M0p/XxBcA/5C3G4t815SDHVcrSXgh2DctGdShE9HRU2w
	 IsUBFFCc51obc5S6NRc8rsqk40o24UBDo3bA2nmXnxiL2o9m08sPWwpMdhSYtMX3Hk
	 8qmTX95VxjNZ7NqERs5puYq2A+F6gX9rBIQ/4pMFzx9ZZmh470MpOWUS9e/WUOwRMG
	 4HvHCsHNU2IjBKQoLxIa5w2bx1/DHbBRTNhtghFUJLn7eiyPP8sxPpSOdhlsTiGld2
	 J3xBxOmKCEx1w==
Date: Fri, 13 Jun 2025 15:59:06 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Jason Andryuk , 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    Andrew Cooper , 
    Anthony PERARD , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    "Daniel P. Smith" , 
    Christian Lindig , 
    David Scott , xen-devel@lists.xenproject.org
Subject: Re: [PATCH 0/4] XSM changes for split hardware / control domain
In-Reply-To: 
Message-ID: 
References: <20250610225737.469690-1-jason.andryuk@amd.com> <0defc4e7-382b-4651-8255-652da17a2129@suse.com> <4b0b7554-e22f-4ef2-9236-bcc2079842d2@amd.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 Jun 2025, Jan Beulich wrote:
> On 11.06.2025 07:08, Jason Andryuk wrote:
> > On 2025-06-11 09:28, Jan Beulich wrote:
> >> On 11.06.2025 00:57, Jason Andryuk wrote:
> >>> Theses are the broad changes needed for a split hardware / control
> >>> domain.
> >>>
> >>> An earlier posting gave device_model privileges to hardware domain.  For
> >>> this posting, it was split out into a new capability.  This way the
> >>> operator can choose where to run the device models without making the
> >>> hardware domain have the permissions.
> >>>
> >>> The first patch add XSM_HW_PRIV for the hardware hypercalls.  Unlike the
> >>> first posting, the control domain can call these hypercalls even though
> >>> it doesn't really make sense.  The idea was to keep the control domain
> >>> all powerful from an XSM perspective.
> >>>
> >>> SILO is changed to allow control, hardwware or xenstore to service
> >>> domUs.  Xenstore and hardware will use grants for PV interfaces.
> >>> Control wouldn't typically provide PV interfaces to domUs, but it is
> >>> given the permision to do so.  Again, to keep control all powerful.
> >>>
> >>> xsm/dummy: Allow hwdom SYSCTL_readconsole/physinfo this is not strictly
> >>> needed.  xenconsoled could read Xen's dmesg.  If it's in hwdom, then
> >>> that permission would be required.  SYSCTL_physinfo is mainly to silence
> >>> xl messages, which are mostly cosmetic.
> >>>
> >>> Jason Andryuk (4):
> >>>    xen/xsm: Add XSM_HW_PRIV
> >>>    xsm/silo: Support hwdom/control domains
> >>>    xen: Add DOMAIN_CAPS_DEVICE_MODEL & XEN_DOMCTL_CDF_device_model
> >>>    xsm/dummy: Allow hwdom SYSCTL_readconsole/physinfo
> >>
> >> Overall I can't help the impression that this level of disaggregation simply
> >> requires the use of Flask.
> > 
> > I have thought about that.  The problem with Flask is the complexity of 
> > the security server.  We don't want to have to deal with all that code. 
> > A fixed policy is easier for our coverage testing.
> > 
> > Exposing separate control, hardware and xenstore capabilities, it makes 
> > sense for the default policy to function with them.
> 
> Yet as indicated in replies to individual patches - the boundaries between
> the three aren't clear, which imo goes (to some degree at least) against the
> purpose of "disaggregation".

At a high level things are clear. We have a static number of VMs, so
with Dom0less we don't need domain creation capabilities. Dom0 can be
de-privileged and becomes the Hardware Domain. To allow monitoring and
other privileged operations an optional Control Domain might be present
(or not).

- The Control Domain has d->is_privileged == true but has no direct
  access to hardware by default. With Dom0less ability to create all the
  VMs at boot, the Control Domain is not required for domain creation,
  so it is just optional.

- The Hardware Domain has all hardware by default but d->is_privileged
  == false. The Hardware Domain should be as close to a DomU as possible
  in terms of privileges but it must be able to run PV backends and
  Virtio backends.

- Xenstored will typically be in the Hardware Domain to enable PV
  backends, especially as the Control Domain is optional. It could also
  live in its own separate domain to speed up the boot. If a user
  chooses to deploy a Control Domain, xenstored could also run there.
  It could be entirely missing if a user only deploys Virtio. It makes
  sense to provide flexibility on this.

We have other instances of XSM policies without Flask, such as SILO. I
think the industrial/automotive use-case is clear enough and shared
among many Xen community members so I think it makes sense to optimize a
policy for it without having to involving Flask because Flask's
complexity would cause trouble in terms of coverage testing and
validation.


From xen-devel-bounces@lists.xenproject.org Fri Jun 13 23:44:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jun 2025 23:44:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1015062.1393015 (Exim 4.92)
	(envelope-from )
	id 1uQE4o-0003MD-Rp; Fri, 13 Jun 2025 23:44:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1015062.1393015; Fri, 13 Jun 2025 23:44: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 1uQE4o-0003M6-Nz; Fri, 13 Jun 2025 23:44:50 +0000
Received: by outflank-mailman (input) for mailman id 1015062;
 Fri, 13 Jun 2025 23:44: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 1uQE4m-0003J0-VZ
 for xen-devel@lists.xenproject.org; Fri, 13 Jun 2025 23:44:49 +0000
Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com
 [2607:f8b0:4864:20::735])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6330ab61-48b0-11f0-b894-0df219b8e170;
 Sat, 14 Jun 2025 01:44:47 +0200 (CEST)
Received: by mail-qk1-x735.google.com with SMTP id
 af79cd13be357-7c5a88b34a6so268501085a.3
 for ; Fri, 13 Jun 2025 16:44:47 -0700 (PDT)
Received: from [10.138.10.6] ([89.187.178.201])
 by smtp.gmail.com with ESMTPSA id
 af79cd13be357-7d3b8ee3f72sm233527285a.94.2025.06.13.16.44.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 13 Jun 2025 16:44:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6330ab61-48b0-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749858286; x=1750463086; darn=lists.xenproject.org;
        h=in-reply-to:subject:autocrypt:from:content-language:references:cc
         :to:user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=NV/OO/PkeIKV0keaBXKCAM7xZJJwqctUj/lozsMmipw=;
        b=F3B+AUvijdQGC8JB2zB3pLpOW6PXo4OzgZdsjtq1+k+89pNSpXp92dJMASay0OYvUI
         5SBuFnqTGc2BVqymsMZ3ZqTdiiOhSWhLLwiSmNAQtrnWrCHm83gaY9DZveMII5yiVP98
         ZlKeAWArQ6XyRALHKP85WEWTwxtHWhg2ZJBlqnuaNCTKnkgUMG+VslsXcxTgNUyWo0Yb
         vUVF+SMMfQzyWAZKMoskQbIYJzqygzqCpmewgOqgvfwarvZZ6cxydKbbWX41UXAmk9iF
         19E332JDfWARlfIip8aiRblf3lI5aNgbR2VgWOYQOpq/ef4F6fzSOjd6ZiddZ36h+skL
         MDzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749858286; x=1750463086;
        h=in-reply-to:subject:autocrypt:from:content-language:references:cc
         :to:user-agent:mime-version:date:message-id:x-gm-message-state:from
         :to:cc:subject:date:message-id:reply-to;
        bh=NV/OO/PkeIKV0keaBXKCAM7xZJJwqctUj/lozsMmipw=;
        b=k+0WKhxGb+0kcyXcuO2KlYSGMkSq7lwwukXsDpd0/uWNbcKaFWXqqtXf8XTjlHM19y
         tiA7cHdBg0LwqxyrR9hKg0OjkUpfB9xLn/TAPuSV2Md6dp4WSasFJamI9PPNokV2GnFx
         br121lapPCzuLyzWIeR5tP1MXBzmULoUWF6TRYuh2OnAdUacCPhwW2gdQ6HOydC+d0d2
         074814MmF6gJEIoAj6kK9Zama3HKYAA5wdntjGxLNtcDLDVBpwrxYwULPHYmEuPMh3nD
         /FK2ShZ6WgiaJvwAbjX3tFCCcoh9YyO0RToWr4I9YHJ0fd+13JQhTuAboxhwRG7XZTKC
         txEw==
X-Forwarded-Encrypted: i=1; AJvYcCXq5mf8d+OxY7oTEWpMaqHLuHI3dtr3x7KuezHYcZiUVUyriAoi2yKR3LqX+CDDoRoifaNv9tz+/G0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzB2rvrMzHLDWL5NS+iIxu1pT/Ra5UBQPP2s5i6RExFRTg2oeXr
	IzJGsnWC2SJhTo5rQYlXRyITXQpwQtI0O4OLm308pDTeQHP/GgZO7tYGFWXqxKyq
X-Gm-Gg: ASbGncts8Q0l+sCgqOyHRC0JFsch3U60hdKLEtYFCJUHv5u7+Fd0KyL0fWI3tSPhspc
	9bYEB/wHnOmpGp0CCsW6cdt+qSSGR2fxRuKToElY2ZJXrHmKi3reyXZgzhc0vAuJ6siQDekopkI
	2zI8Kt3ovQhPPEr1XIJ5In5i24W4wy+Q8Yodo7Z1Fssm7rtnDaaPBy66H3bwqzfmLcxo1mfvFZS
	ay2Jcb7VX+/EuAgzv2enTiqFNHR7jlDoP1hCXOegQTVyML7GEqSbVOtEQTZQAhKUIVfkGWCuGpY
	hoOtpSrjLPfOh10QRTSPbqOSpAYXLMcYAz+sVPnDnkDzi8rFU5i0ATOGgDvs8zfXLMs=
X-Google-Smtp-Source: AGHT+IHwRLRc+vN8A+iZZ//nt+Kh2QxbnKDMfIPcQmi6cRDhSEV4OTnx+VgYRqsn0fio6e3Cky3qEg==
X-Received: by 2002:a05:620a:44d0:b0:7d0:a309:b1a0 with SMTP id af79cd13be357-7d3c6c0c751mr213292185a.1.1749858285723;
        Fri, 13 Jun 2025 16:44:45 -0700 (PDT)
Message-ID: 
Date: Fri, 13 Jun 2025 19:44:36 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Stefano Stabellini ,
 Jan Beulich 
Cc: Jason Andryuk ,
 Christian Lindig , David Scott
 , Anthony PERARD ,
 Andrew Cooper ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Bertrand Marquis ,
 Volodymyr Babchuk ,
 "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org
References: <20250610225737.469690-1-jason.andryuk@amd.com>
 <20250610225737.469690-4-jason.andryuk@amd.com>
 
 
Content-Language: en-US
From: Demi Marie Obenour 
Autocrypt: addr=demiobenour@gmail.com; keydata=
 xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49yB+l2nipd
 aq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYfbWpr/si88QKgyGSV
 Z7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/UorR+FaSuVwT7rqzGrTlscnT
 DlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7MMPCJwI8JpPlBedRpe9tfVyfu3euTPLPx
 wcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9Hzx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR
 6h3nBc3eyuZ+q62HS1pJ5EvUT1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl
 5FMWo8TCniHynNXsBtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2
 Bkg1b//r6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nSm9BBff0N
 m0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQABzTxEZW1pIE1hcmll
 IE9iZW5vdXIgKGxvdmVyIG9mIGNvZGluZykgPGRlbWlvYmVub3VyQGdtYWlsLmNvbT7CwXgE
 EwECACIFAlp+A0oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELKItV//nCLBhr8Q
 AK/xrb4wyi71xII2hkFBpT59ObLN+32FQT7R3lbZRjVFjc6yMUjOb1H/hJVxx+yo5gsSj5LS
 9AwggioUSrcUKldfA/PKKai2mzTlUDxTcF3vKx6iMXKA6AqwAw4B57ZEJoMM6egm57TV19kz
 PMc879NV2nc6+elaKl+/kbVeD3qvBuEwsTe2Do3HAAdrfUG/j9erwIk6gha/Hp9yZlCnPTX+
 VK+xifQqt8RtMqS5R/S8z0msJMI/ajNU03kFjOpqrYziv6OZLJ5cuKb3bZU5aoaRQRDzkFIR
 6aqtFLTohTo20QywXwRa39uFaOT/0YMpNyel0kdOszFOykTEGI2u+kja35g9TkH90kkBTG+a
 EWttIht0Hy6YFmwjcAxisSakBuHnHuMSOiyRQLu43ej2+mDWgItLZ48Mu0C3IG1seeQDjEYP
 tqvyZ6bGkf2Vj+L6wLoLLIhRZxQOedqArIk/Sb2SzQYuxN44IDRt+3ZcDqsPppoKcxSyd1Ny
 2tpvjYJXlfKmOYLhTWs8nwlAlSHX/c/jz/ywwf7eSvGknToo1Y0VpRtoxMaKW1nvH0OeCSVJ
 itfRP7YbiRVc2aNqWPCSgtqHAuVraBRbAFLKh9d2rKFB3BmynTUpc1BQLJP8+D5oNyb8Ts4x
 Xd3iV/uD8JLGJfYZIR7oGWFLP4uZ3tkneDfYzsFNBFp+A0oBEAC9ynZI9LU+uJkMeEJeJyQ/
 8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd8xD57ue0eB47bcJv
 VqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPpI4gfUbVEIEQuqdqQyO4GAe+M
 kD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalql1/iSyv1WYeC1OAs+2BLOAT2NEggSiVO
 txEfgewsQtCWi8H1SoirakIfo45Hz0tk/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJ
 riwoaRIS8N2C8/nEM53jb1sH0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcN
 fRAIUrNlatj9TxwivQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6
 dCxN0GNAORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
 rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog2LNtcyCj
 kTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZAgrrnNz0iZG2DVx46
 x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJELKItV//nCLBwNIP/AiIHE8b
 oIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwjjVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGj
 gn0TPtsGzelyQHipaUzEyrsceUGWYoKXYyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8fr
 RHnJdBcjf112PzQSdKC6kqU0Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2
 E0rW4tBtDAn2HkT9uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHM
 OBvy3EhzfAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
 Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVssZ/rYZ9+5
 1yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aWemLLszcYz/u3XnbO
 vUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPthZlDnTnOT+C+OTsh8+m5tos8
 HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E
 +MYSfkEjBz0E8CLOcAw7JIwAaeBT
Subject: Re: [PATCH 3/4] xen: Add DOMAIN_CAPS_DEVICE_MODEL &
 XEN_DOMCTL_CDF_device_model
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------dG6Ag4Qzkc2OajInCuZQmtwP"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------dG6Ag4Qzkc2OajInCuZQmtwP
Content-Type: multipart/mixed; boundary="------------aUxdAcqKkwq0YgpZigNs09WE";
 protected-headers="v1"
From: Demi Marie Obenour 
To: Stefano Stabellini ,
 Jan Beulich 
Cc: Jason Andryuk ,
 Christian Lindig , David Scott
 , Anthony PERARD ,
 Andrew Cooper ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Bertrand Marquis ,
 Volodymyr Babchuk ,
 "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org
Message-ID: 
Subject: Re: [PATCH 3/4] xen: Add DOMAIN_CAPS_DEVICE_MODEL &
 XEN_DOMCTL_CDF_device_model
References: <20250610225737.469690-1-jason.andryuk@amd.com>
 <20250610225737.469690-4-jason.andryuk@amd.com>
 
 
In-Reply-To: 

--------------aUxdAcqKkwq0YgpZigNs09WE
Content-Type: multipart/mixed; boundary="------------h9XBH6XZNYsVjMpfnm9Lt0px"

--------------h9XBH6XZNYsVjMpfnm9Lt0px
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 6/13/25 18:47, Stefano Stabellini wrote:
> On Wed, 11 Jun 2025, Jan Beulich wrote:
>> On 11.06.2025 00:57, Jason Andryuk wrote:
>>> To add more flexibility in system configuration add the new
>>> DOMAIN_CAPS_DEVICE_MODEL flag and XEN_DOMCTL_CDF_device_model.
>>>
>>> Thie new flag corresponds to allowing XSM_DM_PRIV for the domain.  Th=
is
>>> will enable running device model emulators (QEMU) from the assigne
>>> domain for multiple target domains.
>>>
>>> Stubdoms assign target allowing the stubdom to serve as the device
>>> model for a single domain.  This new flag allows the single domain to=

>>> provide emulators for multiple guests.
>>>
>>> The specific scenario is a disaggregated system with the hardware dom=
ain
>>> providing device models for muitple guest domains.
>>
>> Why the hardware domain? Unless a DM also needs access to some of the
>> physical hardware, it ought to run in a separate domain. Conceivably
>> such a domain could service multiply guests, so maybe the "single
>> target" concept presently used for stubdom simply needed extending?
>=20
> Not necessarily. While it is possible to have driver domains, it is not=

> the default configuration.
>=20
> In a default configuration, the hardware domain gets all the hardware b=
y
> default and therefore will also run the PV backends and Virtio backends=
=2E
> The Virtio backends require DM hypercalls. Let me elaborate further.
>=20
> In the datacenter, we have Dom0 typically with all the hardware, the
> backends (PV and Virtio), and also the toolstack. Then all other domain=
s
> are created dynamically by the toolstack. Driver domains are possible
> but not very common.
>=20
> In automotive/embedded, the total number of domains is static, so we ca=
n
> create them using dom0less. We don't need the toolstack to create VMs.
> Also, we have safety concerns, so we want to take away as much
> privileges as possible from Dom0. This is easy because thanks to
> dom0less, we don't need the toolstack and we don't need to create VMs
> dynamically.
>=20
> So the model is that Dom0 becomes the hardware domain: it has all the
> drivers and backends but it is not privileged in the sense of
> creating/destroying other VMs. If a user wants to have Dom0 "super
> powers", they can create an optional Control Domain. The Control Domain=

> is expected to be tiny, such as XTF or Zephyr. It will have the ability=

> that Dom0 used to have but without the drivers. From a privilege
> perspective, the Control Domain could create additional VMs, but in
> automotive/embedded it is not expected to be a use-case because the
> total number of VMs is still static.=20
>=20
> So your point about driver domains. Yes, one can have driver domains th=
e
> same way that one can have driver domains in the datacenter but it is
> not the default. The new default for embedded is what I described above=

> and I think it is a very widely applicable concept across industries:
> automotive, industrial, robotics, etc. and also across vendors: AMD,
> Xilinx, Renesas, EPAM, ARM, etc.

I think the benefits of this are much reduced as long as the hardware
domain is not strongly isolated from the other domains, in the sense that=

the hardware domain being able to compromise other domains is not
considered a security vulnerability.  Specifically, in safety-critical
scenarios the hardware domain (which, to the best of my understanding,
generally runs Linux) must not be able to compromise any of the safety-
critical domains.

This is, of course, achievable, but my understanding is that it isn't
something guaranteed by upstream Xen.  Rather, each user must ensure
it by assigning any hardware that could compromise Xen to the control
domain or a quarantine domain.

Could this be included in documentation?
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
--------------h9XBH6XZNYsVjMpfnm9Lt0px
Content-Type: application/pgp-keys; name="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

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

xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49y
B+l2nipdaq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYf
bWpr/si88QKgyGSVZ7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/
UorR+FaSuVwT7rqzGrTlscnTDlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7M
MPCJwI8JpPlBedRpe9tfVyfu3euTPLPxwcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9H
zx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR6h3nBc3eyuZ+q62HS1pJ5EvU
T1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl5FMWo8TCniHynNXs
BtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2Bkg1b//r
6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nS
m9BBff0Nm0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQAB
zTxEZW1pIE9iZW5vdXIgKElUTCBFbWFpbCBLZXkpIDxhdGhlbmFAaW52aXNpYmxl
dGhpbmdzbGFiLmNvbT7CwY4EEwEIADgWIQR2h02fEza6IlkHHHGyiLVf/5wiwQUC
X6YJvQIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRCyiLVf/5wiwWRhD/0Y
R+YYC5Kduv/2LBgQJIygMsFiRHbR4+tWXuTFqgrxxFSlMktZ6gQrQCWe38WnOXkB
oY6n/5lSJdfnuGd2UagZ/9dkaGMUkqt+5WshLFly4BnP7pSsWReKgMP7etRTwn3S
zk1OwFx2lzY1EnnconPLfPBc6rWG2moA6l0WX+3WNR1B1ndqpl2hPSjT2jUCBWDV
rGOUSX7r5f1WgtBeNYnEXPBCUUM51pFGESmfHIXQrqFDA7nBNiIVFDJTmQzuEqIy
Jl67pKNgooij5mKzRhFKHfjLRAH4mmWZlB9UjDStAfFBAoDFHwd1HL5VQCNQdqEc
/9lZDApqWuCPadZN+pGouqLysesIYsNxUhJ7dtWOWHl0vs7/3qkWmWun/2uOJMQh
ra2u8nA9g91FbOobWqjrDd6x3ZJoGQf4zLqjmn/P514gb697788e573WN/MpQ5XI
Fl7aM2d6/GJiq6LC9T2gSUW4rbPBiqOCeiUx7Kd/sVm41p9TOA7fEG4bYddCfDsN
xaQJH6VRK3NOuBUGeL+iQEVF5Xs6Yp+U+jwvv2M5Lel3EqAYo5xXTx4ls0xaxDCu
fudcAh8CMMqx3fguSb7Mi31WlnZpk0fDuWQVNKyDP7lYpwc4nCCGNKCj622ZSocH
AcQmX28L8pJdLYacv9pU3jPy4fHcQYvmTavTqowGnM08RGVtaSBNYXJpZSBPYmVu
b3VyIChsb3ZlciBvZiBjb2RpbmcpIDxkZW1pb2Jlbm91ckBnbWFpbC5jb20+wsF4
BBMBAgAiBQJafgNKAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCyiLVf
/5wiwYa/EACv8a2+MMou9cSCNoZBQaU+fTmyzft9hUE+0d5W2UY1RY3OsjFIzm9R
/4SVccfsqOYLEo+S0vQMIIIqFEq3FCpXXwPzyimotps05VA8U3Bd7yseojFygOgK
sAMOAee2RCaDDOnoJue01dfZMzzHPO/TVdp3OvnpWipfv5G1Xg96rwbhMLE3tg6N
xwAHa31Bv4/Xq8CJOoIWvx6fcmZQpz01/lSvsYn0KrfEbTKkuUf0vM9JrCTCP2oz
VNN5BYzqaq2M4r+jmSyeXLim922VOWqGkUEQ85BSEemqrRS06IU6NtEMsF8EWt/b
hWjk/9GDKTcnpdJHTrMxTspExBiNrvpI2t+YPU5B/dJJAUxvmhFrbSIbdB8umBZs
I3AMYrEmpAbh5x7jEjoskUC7uN3o9vpg1oCLS2ePDLtAtyBtbHnkA4xGD7ar8mem
xpH9lY/i+sC6CyyIUWcUDnnagKyJP0m9ks0GLsTeOCA0bft2XA6rD6aaCnMUsndT
ctrab42CV5XypjmC4U1rPJ8JQJUh1/3P48/8sMH+3krxpJ06KNWNFaUbaMTGiltZ
7x9DngklSYrX0T+2G4kVXNmjaljwkoLahwLla2gUWwBSyofXdqyhQdwZsp01KXNQ
UCyT/Pg+aDcm/E7OMV3d4lf7g/CSxiX2GSEe6BlhSz+Lmd7ZJ3g32M1ARGVtaSBN
YXJpZSBPYmVub3VyIChJVEwgRW1haWwgS2V5KSA8ZGVtaUBpbnZpc2libGV0aGlu
Z3NsYWIuY29tPsLBjgQTAQgAOBYhBHaHTZ8TNroiWQcccbKItV//nCLBBQJgOEV+
AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJELKItV//nCLBKwoP/1WSnFdv
SAD0g7fD0WlF+oi7ISFT7oqJnchFLOwVHK4Jg0e4hGn1ekWsF3Ha5tFLh4V/7UUu
obYJpTfBAA2CckspYBqLtKGjFxcaqjjpO1I2W/jeNELVtSYuCOZICjdNGw2Hl9yH
KRZiBkqc9u8lQcHDZKq4LIpVJj6ZQV/nxttDX90ax2No1nLLQXFbr5wb465LAPpU
lXwunYDij7xJGye+VUASQh9datye6orZYuJvNo8Tr3mAQxxkfR46LzWgxFCPEAZJ
5P56Nc0IMHdJZj0Uc9+1jxERhOGppp5jlLgYGK7faGB/jTV6LaRQ4Ad+xiqokDWp
mUOZsmA+bMbtPfYjDZBz5mlyHcIRKIFpE1l3Y8F7PhJuzzMUKkJi90CYakCV4x/a
Zs4pzk5E96c2VQx01RIEJ7fzHF7lwFdtfTS4YsLtAbQFsKayqwkGcVv2B1AHeqdo
TMX+cgDvjd1ZganGlWA8Sv9RkNSMchn1hMuTwERTyFTr2dKPnQdA1F480+jUap41
ClXgn227WkCIMrNhQGNyJsnwyzi5wS8rBVRQ3BOTMyvGM07j3axUOYaejEpg7wKi
wTPZGLGH1sz5GljD/916v5+v2xLbOo5606j9dWf5/tAhbPuqrQgWv41wuKDi+dDD
EKkODF7DHes8No+QcHTDyETMn1RYm7t0RKR4zsFNBFp+A0oBEAC9ynZI9LU+uJkM
eEJeJyQ/8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd
8xD57ue0eB47bcJvVqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPp
I4gfUbVEIEQuqdqQyO4GAe+MkD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalq
l1/iSyv1WYeC1OAs+2BLOAT2NEggSiVOtxEfgewsQtCWi8H1SoirakIfo45Hz0tk
/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJriwoaRIS8N2C8/nEM53jb1sH
0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcNfRAIUrNlatj9Txwi
vQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6dCxN0GNA
ORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog
2LNtcyCjkTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZA
grrnNz0iZG2DVx46x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJ
ELKItV//nCLBwNIP/AiIHE8boIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwj
jVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGjgn0TPtsGzelyQHipaUzEyrsceUGWYoKX
YyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8frRHnJdBcjf112PzQSdKC6kqU0
Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2E0rW4tBtDAn2HkT9
uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHMOBvy3Ehz
fAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVss
Z/rYZ9+51yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aW
emLLszcYz/u3XnbOvUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPt
hZlDnTnOT+C+OTsh8+m5tos8HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj
6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E+MYSfkEjBz0E8CLOcAw7JIwAaeBTzsFN
BGbyLVgBEACqClxh50hmBepTSVlan6EBq3OAoxhrAhWZYEwN78k+ENhK68KhqC5R
IsHzlL7QHW1gmfVBQZ63GnWiraM6wOJqFTL4ZWvRslga9u28FJ5XyK860mZLgYhK
9BzoUk4s+dat9jVUbq6LpQ1Ot5I9vrdzo2p1jtQ8h9WCIiFxSYy8s8pZ3hHh5T64
GIj1m/kY7lG3VIdUgoNiREGf/iOMjUFjwwE9ZoJ26j9p7p1U+TkKeF6wgswEB1T3
J8KCAtvmRtqJDq558IU5jhg5fgN+xHB8cgvUWulgK9FIF9oFxcuxtaf/juhHWKMO
RtL0bHfNdXoBdpUDZE+mLBUAxF6KSsRrvx6AQyJs7VjgXJDtQVWvH0PUmTrEswgb
49nNU+dLLZQAZagxqnZ9Dp5l6GqaGZCHERJcLmdY/EmMzSf5YazJ6c0vO8rdW27M
kn73qcWAplQn5mOXaqbfzWkAUPyUXppuRHfrjxTDz3GyJJVOeMmMrTxH4uCaGpOX
Z8tN6829J1roGw4oKDRUQsaBAeEDqizXMPRc+6U9vI5FXzbAsb+8lKW65G7JWHym
YPOGUt2hK4DdTA1PmVo0DxH00eWWeKxqvmGyX+Dhcg+5e191rPsMRGsDlH6KihI6
+3JIuc0y6ngdjcp6aalbuvPIGFrCRx3tnRtNc7He6cBWQoH9RPwluwARAQABwsOs
BBgBCgAgFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmbyLVgCGwICQAkQsoi1X/+c
IsHBdCAEGQEKAB0WIQSilC2pUlbVp66j3+yzNoc6synyUwUCZvItWAAKCRCzNoc6
synyU85gD/0T1QDtPhovkGwoqv4jUbEMMvpeYQf+oWgm/TjWPeLwdjl7AtY0G9Ml
ZoyGniYkoHi37Gnn/ShLT3B5vtyI58ap2+SSa8SnGftdAKRLiWFWCiAEklm9FRk8
N3hwxhmSFF1KR/AIDS4g+HIsZn7YEMubBSgLlZZ9zHl4O4vwuXlREBEW97iL/FSt
VownU2V39t7PtFvGZNk+DJH7eLO3jmNRYB0PL4JOyyda3NH/J92iwrFmjFWWmmWb
/Xz8l9DIs+Z59pRCVTTwbBEZhcUc7rVMCcIYL+q1WxBG2e6lMn15OQJ5WfiE6E0I
sGirAEDnXWx92JNGx5l+mMpdpsWhBZ5iGTtttZesibNkQfd48/eCgFi4cxJUC4PT
UQwfD9AMgzwSTGJrkI5XGy+XqxwOjL8UA0iIrtTpMh49zw46uV6kwFQCgkf32jZM
OLwLTNSzclbnA7GRd8tKwezQ/XqeK3dal2n+cOr+o+Eka7yGmGWNUqFbIe8cjj9T
JeF3mgOCmZOwMI+wIcQYRSf+e5VTMO6TNWH5BI3vqeHSt7HkYuPlHT0pGum88d4a
pWqhulH4rUhEMtirX1hYx8Q4HlUOQqLtxzmwOYWkhl1C+yPObAvUDNiHCLf9w28n
uihgEkzHt9J4VKYulyJM9fe3ENcyU6rpXD7iANQqcr87ogKXFxknZ97uEACvSucc
RbnnAgRqZ7GDzgoBerJ2zrmhLkeREZ08iz1zze1JgyW3HEwdr2UbyAuqvSADCSUU
GN0vtQHsPzWl8onRc7lOPqPDF8OO+UfN9NAfA4wl3QyChD1GXl9rwKQOkbvdlYFV
UFx9u86LNi4ssTmU8p9NtHIGpz1SYMVYNoYy9NU7EVqypGMguDCL7gJt6GUmA0sw
p+YCroXiwL2BJ7RwRqTpgQuFL1gShkA17D5jK4mDPEetq1d8kz9rQYvAR/sTKBsR
ImC3xSfn8zpWoNTTB6lnwyP5Ng1bu6esS7+SpYprFTe7ZqGZF6xhvBPf1Ldi9UAm
U2xPN1/eeWxEa2kusidmFKPmN8lcT4miiAvwGxEnY7Oww9CgZlUB+LP4dl5VPjEt
sFeAhrgxLdpVTjPRRwTd9VQF3/XYl83j5wySIQKIPXgT3sG3ngAhDhC8I8GpM36r
8WJJ3x2yVzyJUbBPO0GBhWE2xPNIfhxVoU4cGGhpFqz7dPKSTRDGq++MrFgKKGpI
ZwT3CPTSSKc7ySndEXWkOYArDIdtyxdE1p5/c3aoz4utzUU7NDHQ+vVIwlnZSMiZ
jek2IJP3SZ+COOIHCVxpUaZ4lnzWT4eDqABhMLpIzw6NmGfg+kLBJhouqz81WITr
EtJuZYM5blWncBOJCoWMnBEcTEo/viU3GgcVRw=3D=3D
=3Dx94R
-----END PGP PUBLIC KEY BLOCK-----

--------------h9XBH6XZNYsVjMpfnm9Lt0px--

--------------aUxdAcqKkwq0YgpZigNs09WE--

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

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

iQIzBAEBCAAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmhMt+UACgkQszaHOrMp
8lNhkA/8DTe52735Pu75RiEKYfK/1lUwSBo4Z8o6HbQ+LC0CdphCl7PN/ClbW3tK
oT3OtUvp/9XU94zR08EAl/aoH24FhYzVTV3au4Q2WVjAfUcIk6jAdab3yEOWxyDt
ZtKeHqCMViRX3pbQbfSAC7xrsQxHwvP5UarqmgYPS170Bmv/jXF5aClzSr0Fy2AT
MpSKa+nBDj3d0mz2azmngcMnsWHGyrNBFlm9ADmCGkPyVSpMGkg0l2mOmpygMl28
Z116cFMji8zgqA+p0OeSdaOV+MutlawdqPE2HQT8U+4sDFy/WbkjKYhy/OLOnUlb
Fywq+vedKVNbYFj6j8ef75hMNEIB7imcaJKqC82IG1R37WAnOgdzCrmI1fS9TdDO
iQGiwlb/WJzj/wFMnIu2hm/0w7HXKnNl/ESkJrEZHIidQ6ze3DU/SlHP2jn7h6Q+
2XTV8dCkNTrogeaRd3TNgAtdzAIbNQPvpwd/PboPlRr7Nl4KitQKmQhWwqTgObL4
cwMVx+YUX5RUs+C7KgdfFxC3zR8LzYwKItEGG9vEaCPZ1xFca2JFmBT2cFDC/b+H
cflsHARvNpGRL/isNdahAKhutILggQRjuUfmWooLAuF0Vq8E1+qEUD4HKP7x4LuS
kpxn16/DhZtLXqqFqrWtFBDs/vlYIUmK6/E+Em4ler+HVqbDO9M=
=94MW
-----END PGP SIGNATURE-----

--------------dG6Ag4Qzkc2OajInCuZQmtwP--


From xen-devel-bounces@lists.xenproject.org Sat Jun 14 00:15:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jun 2025 00:15:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1015096.1393024 (Exim 4.92)
	(envelope-from )
	id 1uQEYf-0008AL-JM; Sat, 14 Jun 2025 00:15:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1015096.1393024; Sat, 14 Jun 2025 00:15:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uQEYf-0008AE-GF; Sat, 14 Jun 2025 00:15:41 +0000
Received: by outflank-mailman (input) for mailman id 1015096;
 Sat, 14 Jun 2025 00:15: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 1uQEYd-00089y-Gu
 for xen-devel@lists.xenproject.org; Sat, 14 Jun 2025 00:15:39 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id aac486bc-48b4-11f0-b894-0df219b8e170;
 Sat, 14 Jun 2025 02:15:25 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id D044643D83;
 Sat, 14 Jun 2025 00:15:23 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id CFE43C4CEE3;
 Sat, 14 Jun 2025 00:15: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: aac486bc-48b4-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749860123;
	bh=SwTR/pOsCNxz+6VZTkWd2pW+vd1wWK4HBfbJ1Zcc9oc=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=f2v/OcsCOicTeR2y2X9lObQ9K2/vm9gi7MaIwgltcLtr52qDcx5lyYFym8Vf/Czcd
	 fGKbdJXQKTPNRE8NxnBuWdR+fkIgwcrjM1yXJjpbQW5Mcj/rYn3gouTucqJM09xnU0
	 7kUGVcoP/djbrDYvpyXufy2MxXdQMG6M+Ga0cIYEfcZIkGr8T7uzAPeXzQCrP7r4Lf
	 WPuNDQrXQlqS/+IWalBQRLTQ/GxcpFfNIe+qa3MGsCGBqkfI2U+vHapX52MU3xKGDe
	 95TKLy2pHHGoHyXrHXMwp+4eHlLzOCmnTMe+ApHMEp7qik41RG7RXdd+HV2IMVY2gg
	 abUtf1PwsqxDg==
Date: Fri, 13 Jun 2025 17:15:20 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Demi Marie Obenour 
cc: Stefano Stabellini , 
    Jan Beulich , Jason Andryuk , 
    Christian Lindig , 
    David Scott , Anthony PERARD , 
    Andrew Cooper , 
    Michal Orzel , Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Bertrand Marquis , 
    Volodymyr Babchuk , 
    "Daniel P. Smith" , 
    xen-devel@lists.xenproject.org
Subject: Re: [PATCH 3/4] xen: Add DOMAIN_CAPS_DEVICE_MODEL &
 XEN_DOMCTL_CDF_device_model
In-Reply-To: 
Message-ID: 
References: <20250610225737.469690-1-jason.andryuk@amd.com> <20250610225737.469690-4-jason.andryuk@amd.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 Jun 2025, Demi Marie Obenour wrote:
> On 6/13/25 18:47, Stefano Stabellini wrote:
> > On Wed, 11 Jun 2025, Jan Beulich wrote:
> >> On 11.06.2025 00:57, Jason Andryuk wrote:
> >>> To add more flexibility in system configuration add the new
> >>> DOMAIN_CAPS_DEVICE_MODEL flag and XEN_DOMCTL_CDF_device_model.
> >>>
> >>> Thie new flag corresponds to allowing XSM_DM_PRIV for the domain.  This
> >>> will enable running device model emulators (QEMU) from the assigne
> >>> domain for multiple target domains.
> >>>
> >>> Stubdoms assign target allowing the stubdom to serve as the device
> >>> model for a single domain.  This new flag allows the single domain to
> >>> provide emulators for multiple guests.
> >>>
> >>> The specific scenario is a disaggregated system with the hardware domain
> >>> providing device models for muitple guest domains.
> >>
> >> Why the hardware domain? Unless a DM also needs access to some of the
> >> physical hardware, it ought to run in a separate domain. Conceivably
> >> such a domain could service multiply guests, so maybe the "single
> >> target" concept presently used for stubdom simply needed extending?
> > 
> > Not necessarily. While it is possible to have driver domains, it is not
> > the default configuration.
> > 
> > In a default configuration, the hardware domain gets all the hardware by
> > default and therefore will also run the PV backends and Virtio backends.
> > The Virtio backends require DM hypercalls. Let me elaborate further.
> > 
> > In the datacenter, we have Dom0 typically with all the hardware, the
> > backends (PV and Virtio), and also the toolstack. Then all other domains
> > are created dynamically by the toolstack. Driver domains are possible
> > but not very common.
> > 
> > In automotive/embedded, the total number of domains is static, so we can
> > create them using dom0less. We don't need the toolstack to create VMs.
> > Also, we have safety concerns, so we want to take away as much
> > privileges as possible from Dom0. This is easy because thanks to
> > dom0less, we don't need the toolstack and we don't need to create VMs
> > dynamically.
> > 
> > So the model is that Dom0 becomes the hardware domain: it has all the
> > drivers and backends but it is not privileged in the sense of
> > creating/destroying other VMs. If a user wants to have Dom0 "super
> > powers", they can create an optional Control Domain. The Control Domain
> > is expected to be tiny, such as XTF or Zephyr. It will have the ability
> > that Dom0 used to have but without the drivers. From a privilege
> > perspective, the Control Domain could create additional VMs, but in
> > automotive/embedded it is not expected to be a use-case because the
> > total number of VMs is still static. 
> > 
> > So your point about driver domains. Yes, one can have driver domains the
> > same way that one can have driver domains in the datacenter but it is
> > not the default. The new default for embedded is what I described above
> > and I think it is a very widely applicable concept across industries:
> > automotive, industrial, robotics, etc. and also across vendors: AMD,
> > Xilinx, Renesas, EPAM, ARM, etc.
> 
> I think the benefits of this are much reduced as long as the hardware
> domain is not strongly isolated from the other domains, in the sense that
> the hardware domain being able to compromise other domains is not
> considered a security vulnerability.  Specifically, in safety-critical
> scenarios the hardware domain (which, to the best of my understanding,
> generally runs Linux) must not be able to compromise any of the safety-
> critical domains.
> 
> This is, of course, achievable, but my understanding is that it isn't
> something guaranteed by upstream Xen.  Rather, each user must ensure
> it by assigning any hardware that could compromise Xen to the control
> domain or a quarantine domain.
> 
> Could this be included in documentation?

Yes, I agree that it should be included in the documentation.


From xen-devel-bounces@lists.xenproject.org Sat Jun 14 00:30:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jun 2025 00:30:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1015109.1393035 (Exim 4.92)
	(envelope-from )
	id 1uQEnC-0002QC-Q6; Sat, 14 Jun 2025 00:30:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1015109.1393035; Sat, 14 Jun 2025 00:30:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uQEnC-0002Q5-N9; Sat, 14 Jun 2025 00:30:42 +0000
Received: by outflank-mailman (input) for mailman id 1015109;
 Sat, 14 Jun 2025 00:30: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 1uQEnC-0002Om-0D
 for xen-devel@lists.xenproject.org; Sat, 14 Jun 2025 00:30: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 cc6117f8-48b6-11f0-a309-13f23c93f187;
 Sat, 14 Jun 2025 02:30:40 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 9380A5C5F8E;
 Sat, 14 Jun 2025 00:28:22 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id EC777C4CEE3;
 Sat, 14 Jun 2025 00:30: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: cc6117f8-48b6-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749861038;
	bh=Ch1wr2KOSVaH/QpDBPKZ6gySDFiWFtID0YyvTmUcuAo=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=Wvt2q/FLuOTtrwyUskgpE9vuo/vvr8pL+fjPnB05k2jBMz/A2vcSY4ac7fNifswS8
	 J2XWJCXp5ObOUDozdYgzjC3qcFllI1PhA2MXOcAk0rXyOiyBYLX9T07i1kJoMVTdK7
	 tni2yNMMYmrd/f8UbrzA4R7QmLawE1DzD1qh3oi4dHaWxOGZUdvesTq/PYuSlzJSx6
	 Digi1UIteJ1g6DLsA7rZoPWm5J7cJ7khn0I6oTr0Ao0XI7m5URUzeR8OszCSVUJv4r
	 9JF0nIv+gT16eQ97/yKWu2zRuRdKo8NGTr9Myqa3intvK5xiI4zeS4l2i6Exh17LO/
	 qaXSSJP0uDYvw==
Date: Fri, 13 Jun 2025 17:30:36 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    "Daniel P. Smith" 
Subject: Re: [PATCH v3 01/14] arm/gnttab: Remove xen/grant_table.h cyclic
 include
In-Reply-To: <20250613151612.754222-2-agarciav@amd.com>
Message-ID: 
References: <20250613151612.754222-1-agarciav@amd.com> <20250613151612.754222-2-agarciav@amd.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 Jun 2025, Alejandro Vallejo wrote:
> The way they currently include each other, with one of the includes
> being conditional on CONFIG_GRANT_TABLE, makes it hard to know which
> contents are included when.
> 
> Break the cycle by removing the asm/grant_table.h include.
> 
> Not a functional change because.
> 
> Signed-off-by: Alejandro Vallejo 

Reviewed-by: Stefano Stabellini 


> ---
> v3:
>   * Strictly remove the cycle in asm/grant_table.h
>     (Keeping the conditional include is a terrible idea, IMO)
> ---
>  xen/arch/arm/include/asm/grant_table.h | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/xen/arch/arm/include/asm/grant_table.h b/xen/arch/arm/include/asm/grant_table.h
> index c5d87b60c4..c47058a3a0 100644
> --- a/xen/arch/arm/include/asm/grant_table.h
> +++ b/xen/arch/arm/include/asm/grant_table.h
> @@ -1,7 +1,6 @@
>  #ifndef __ASM_GRANT_TABLE_H__
>  #define __ASM_GRANT_TABLE_H__
>  
> -#include 
>  #include 
>  #include 
>  #include 
> -- 
> 2.43.0
> 


From xen-devel-bounces@lists.xenproject.org Sat Jun 14 00:32:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jun 2025 00:32:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1015116.1393044 (Exim 4.92)
	(envelope-from )
	id 1uQEp2-0002xv-54; Sat, 14 Jun 2025 00:32:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1015116.1393044; Sat, 14 Jun 2025 00:32:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uQEp2-0002xo-1x; Sat, 14 Jun 2025 00:32:36 +0000
Received: by outflank-mailman (input) for mailman id 1015116;
 Sat, 14 Jun 2025 00:32:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uQEp1-0002xg-09
 for xen-devel@lists.xenproject.org; Sat, 14 Jun 2025 00:32:35 +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 0f582dc8-48b7-11f0-b894-0df219b8e170;
 Sat, 14 Jun 2025 02:32:33 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id D1C56A50033;
 Sat, 14 Jun 2025 00:32:31 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4C0E6C4CEE3;
 Sat, 14 Jun 2025 00:32: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: 0f582dc8-48b7-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749861151;
	bh=MkV8CeD2OfJIzE/EorxmkMN1DHR3eKYBFqseHr2L5NA=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=TrgFHxT3ibVI+AmCY+Va99lESHzhe1fhHnFszCuzBFYoqAESQaHjhKLkHQtZ/6Hq+
	 MwYbxmRXKg4ETpW17sbdYw8fkRT21YQZfk3HBovelN4voXfCJfmIIgwYoZjox2JVde
	 KpBxtE9eehyu9TvjJ6d1oXw34IJl9qHroK/WlsBvPiKwdMLsSg/WIpGfyO/EXQlaTY
	 8OfxG1zmuYf8g+SarIvQ9tcMRalXMnokVNzRcj1x2mpx7+M4mKto2jKYU2ZAcV4QJs
	 4QYGM4xXI5GLQdFm+DG7knOOycFqqH5OyaVoV30ERi7dkAxIiW/ePobf1JZbHUzJa5
	 406qaZUg4pPhQ==
Date: Fri, 13 Jun 2025 17:32:29 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
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 , 
    "Daniel P. Smith" 
Subject: Re: [PATCH v3 03/14] CODING_STYLE: Custom type names must be
 snake-cased by word.
In-Reply-To: <20250613151612.754222-4-agarciav@amd.com>
Message-ID: 
References: <20250613151612.754222-1-agarciav@amd.com> <20250613151612.754222-4-agarciav@amd.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 Jun 2025, Alejandro Vallejo wrote:
> There's the unwritten convention in x86 of splitting type names using
> underscores. Add such convention to the CODINNG_STYLE to make it
                                          ^ CODING_STYLE

> common and less unwritten.
> 
> Signed-off-by: Alejandro Vallejo 
> ---
>  CODING_STYLE | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/CODING_STYLE b/CODING_STYLE
> index 5644f1697f..e91ef7b3ca 100644
> --- a/CODING_STYLE
> +++ b/CODING_STYLE
> @@ -126,6 +126,9 @@ register).
>  Especially with pointer types, whenever the pointed to object is not
>  (supposed to be) modified, qualify the pointed to type with "const".
>  
> +When defining types, split its words using underscores (e.g: prefer my_foo to
> +myfoo).

Minor NIT:
When defining types, separate words using underscores (for example, use
"my_foo" instead of "myfoo").


Reviewed-by: Stefano Stabellini 


>  Comments
>  --------
>  
> -- 
> 2.43.0
> 


From xen-devel-bounces@lists.xenproject.org Sat Jun 14 00:42:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jun 2025 00:42:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1015122.1393055 (Exim 4.92)
	(envelope-from )
	id 1uQEyD-0004dB-00; Sat, 14 Jun 2025 00:42:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1015122.1393055; Sat, 14 Jun 2025 00: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 1uQEyC-0004d4-T9; Sat, 14 Jun 2025 00:42:04 +0000
Received: by outflank-mailman (input) for mailman id 1015122;
 Sat, 14 Jun 2025 00: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 1uQEyB-0004cy-8V
 for xen-devel@lists.xenproject.org; Sat, 14 Jun 2025 00:42:03 +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 5fd257db-48b8-11f0-b894-0df219b8e170;
 Sat, 14 Jun 2025 02:41:57 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 4B499A503DA;
 Sat, 14 Jun 2025 00:41:56 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 71445C4CEE3;
 Sat, 14 Jun 2025 00:41:54 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5fd257db-48b8-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749861716;
	bh=ScsbSM0QcZd088S7J/AtVpoB/+Y5ipd/fsKVrRT21Uo=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=uxFtMPiPHcuaRKa7s6h8Yyz8lT9uVTzkeL0+Rlp5TPvREEypsvoby0bPEZoDVJ6jW
	 05bMS6j3/mGQ1KC2Lr14t3VbQhXlqILS3GNP9f0tEVHM+ngQqeAnpfQsIvY9u7Et7u
	 AaI1kQ1UOM9vUH8MbGw0s1d3hYIucY5vrMe70B+aUN+oTAtfkHF4fuuztKk2ztlZi0
	 E9vhzjvIybGE3r9YFKKlQ9uT4J9gy/cBUQEfIS7hAcjL6/UKpyWEMpUur2DyrWZa8W
	 ydsHdl3sI3znUF/SqzKkotHR4QYCYZEASKyPFK5smWzhZ+TYbmp5RAV/lv4Guza5ti
	 kXqSs15kLwXsw==
Date: Fri, 13 Jun 2025 17:41:53 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    Andrew Cooper , 
    Anthony PERARD , 
    Jan Beulich , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    "Daniel P. Smith" 
Subject: Re: [PATCH v3 04/14] xen: Rename bootmodule{,s} to boot_module{,s}
In-Reply-To: <20250613151612.754222-5-agarciav@amd.com>
Message-ID: 
References: <20250613151612.754222-1-agarciav@amd.com> <20250613151612.754222-5-agarciav@amd.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 Jun 2025, Alejandro Vallejo wrote:
> ... in alignment with the new coding style on word splitting for type
> names.
> 
> This aligns its name with the largely duplicate boot_module struct
> in x86. While there's no equivalent to "struct bootmodules" in x86,
> changing one and not the other is just confusing. Same with various
> comments and function names.
> 
> Rather than making a long subfield name even longer, remove the
> _bootmodule suffix in the kernel, initrd and dtb subfields.
> 
> Not a functional change.
> 
> Signed-off-by: Alejandro Vallejo 
> ---
>  xen/arch/arm/domain_build.c             |  4 +-
>  xen/arch/arm/efi/efi-boot.h             |  6 +--
>  xen/arch/arm/kernel.c                   |  4 +-
>  xen/arch/arm/llc-coloring.c             |  8 ++--
>  xen/arch/arm/mmu/setup.c                | 10 ++---
>  xen/arch/arm/setup.c                    | 10 ++---
>  xen/common/device-tree/bootfdt.c        |  4 +-
>  xen/common/device-tree/bootinfo.c       | 52 ++++++++++++-------------
>  xen/common/device-tree/dom0less-build.c | 25 ++++++------
>  xen/common/device-tree/domain-build.c   |  2 +-
>  xen/common/device-tree/kernel.c         | 22 +++++------
>  xen/include/xen/bootfdt.h               | 26 ++++++-------
>  xen/include/xen/fdt-kernel.h            |  7 ++--
>  xen/xsm/xsm_policy.c                    |  2 +-
>  14 files changed, 90 insertions(+), 92 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 590f38e520..7096e176ed 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -579,7 +579,7 @@ static int __init write_properties(struct domain *d, struct kernel_info *kinfo,
>  
>      if ( dt_node_path_is_equal(node, "/chosen") )
>      {
> -        const struct bootmodule *initrd = kinfo->initrd_bootmodule;
> +        const struct boot_module *initrd = kinfo->initrd;
>  
>          if ( bootargs )
>          {
> @@ -1447,7 +1447,7 @@ int __init make_chosen_node(const struct kernel_info *kinfo)
>  {
>      int res;
>      const char *bootargs = NULL;
> -    const struct bootmodule *initrd = kinfo->initrd_bootmodule;
> +    const struct boot_module *initrd = kinfo->initrd;
>      void *fdt = kinfo->fdt;
>  
>      dt_dprintk("Create chosen node\n");
> diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
> index d2a09ad3a1..2af8e8ea05 100644
> --- a/xen/arch/arm/efi/efi-boot.h
> +++ b/xen/arch/arm/efi/efi-boot.h
> @@ -20,7 +20,7 @@ typedef struct {
>  } module_info;
>  
>  /*
> - * Binaries will be translated into bootmodules, the maximum number for them is
> + * Binaries will be translated into boot_modules, the maximum number for them is
>   * MAX_MODULES where we should remove a unit for Xen and one for Xen DTB
>   */
>  #define MAX_UEFI_MODULES (MAX_MODULES - 2)
> @@ -602,9 +602,9 @@ static void __init efi_arch_handle_module(const struct file *file,
>  
>      /*
>       * modules_available is decremented here because for each dom0 file added
> -     * from the configuration file, there will be an additional bootmodule,
> +     * from the configuration file, there will be an additional boot_module,
>       * so the number of available slots will be decremented because there is a
> -     * maximum amount of bootmodules that can be loaded.
> +     * maximum amount of boot_modules that can be loaded.
>       */
>      modules_available--;
>  }
> diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
> index cb1efb19e7..e734ec5c1e 100644
> --- a/xen/arch/arm/kernel.c
> +++ b/xen/arch/arm/kernel.c
> @@ -46,7 +46,7 @@ static void __init place_modules(struct kernel_info *info,
>                                   paddr_t kernbase, paddr_t kernend)
>  {
>      /* Align DTB and initrd size to 2Mb. Linux only requires 4 byte alignment */
> -    const struct bootmodule *mod = info->initrd_bootmodule;
> +    const struct boot_module *mod = info->initrd;
>      const struct membanks *mem = kernel_info_get_mem(info);
>      const paddr_t initrd_len = ROUNDUP(mod ? mod->size : 0, MB(2));
>      const paddr_t dtb_len = ROUNDUP(fdt_totalsize(info->fdt), MB(2));
> @@ -175,7 +175,7 @@ static void __init kernel_zimage_load(struct kernel_info *info)
>   * Check if the image is a uImage and setup kernel_info
>   */
>  int __init kernel_uimage_probe(struct kernel_info *info,
> -                               struct bootmodule *mod)
> +                               struct boot_module *mod)
>  {
>      struct {
>          __be32 magic;   /* Image Header Magic Number */
> diff --git a/xen/arch/arm/llc-coloring.c b/xen/arch/arm/llc-coloring.c
> index 99ac10b610..6f78817c57 100644
> --- a/xen/arch/arm/llc-coloring.c
> +++ b/xen/arch/arm/llc-coloring.c
> @@ -123,12 +123,12 @@ static paddr_t __init xen_colored_map_size(void)
>  
>  void __init arch_llc_coloring_init(void)
>  {
> -    struct bootmodule *xen_bootmodule = boot_module_find_by_kind(BOOTMOD_XEN);
> +    struct boot_module *xen_boot_module = boot_module_find_by_kind(BOOTMOD_XEN);
>  
> -    BUG_ON(!xen_bootmodule);
> +    BUG_ON(!xen_boot_module);
>  
> -    xen_bootmodule->size = xen_colored_map_size();
> -    xen_bootmodule->start = get_xen_paddr(xen_bootmodule->size);
> +    xen_boot_module->size = xen_colored_map_size();
> +    xen_boot_module->start = get_xen_paddr(xen_boot_module->size);
>  }
>  
>  /*
> diff --git a/xen/arch/arm/mmu/setup.c b/xen/arch/arm/mmu/setup.c
> index 30afe97781..eb8ed19ca1 100644
> --- a/xen/arch/arm/mmu/setup.c
> +++ b/xen/arch/arm/mmu/setup.c
> @@ -246,7 +246,7 @@ paddr_t __init consider_modules(paddr_t s, paddr_t e,
>  #ifdef CONFIG_STATIC_SHM
>      const struct membanks *shmem = bootinfo_get_shmem();
>  #endif
> -    const struct bootmodules *mi = &bootinfo.modules;
> +    const struct boot_modules *mi = &bootinfo.modules;
>      int i;
>      int nr;
>  
> @@ -273,8 +273,8 @@ paddr_t __init consider_modules(paddr_t s, paddr_t e,
>      }
>  
>      /*
> -     * i is the current bootmodule we are evaluating, across all
> -     * possible kinds of bootmodules.
> +     * i is the current boot_module we are evaluating, across all
> +     * possible kinds of boot_modules.
>       *
>       * When retrieving the corresponding reserved-memory addresses, we
>       * need to index the reserved_mem bank starting from 0, and only counting
> @@ -328,8 +328,8 @@ 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;
> +    struct boot_module *xen_boot_module = boot_module_find_by_kind(BOOTMOD_XEN);
> +    mfn_t start_mfn = maddr_to_mfn(xen_boot_module->start), mfn;
>  
>      for_each_xen_colored_mfn ( start_mfn, mfn, i )
>      {
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 734e23da44..8b2e65a1a5 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -206,11 +206,11 @@ static void __init processor_id(void)
>  
>  void __init discard_initial_modules(void)
>  {
> -    struct bootmodules *mi = &bootinfo.modules;
> +    struct boot_modules *mi = &bootinfo.modules;
>      int i;
>  
>      /*
> -     * When using static heap feature, don't give bootmodules memory back to
> +     * When using static heap feature, don't give boot_modules memory back to
>       * the heap allocator
>       */
>      if ( using_static_heap )
> @@ -303,7 +303,7 @@ void asmlinkage __init start_xen(unsigned long fdt_paddr)
>  {
>      size_t fdt_size;
>      const char *cmdline;
> -    struct bootmodule *xen_bootmodule;
> +    struct boot_module *xen_boot_module;
>      struct domain *d;
>      int rc, i;
>  
> @@ -327,10 +327,10 @@ void asmlinkage __init start_xen(unsigned long fdt_paddr)
>                fdt_paddr);
>  
>      /* Register Xen's load address as a boot module. */
> -    xen_bootmodule = add_boot_module(BOOTMOD_XEN,
> +    xen_boot_module = add_boot_module(BOOTMOD_XEN,
>                               virt_to_maddr(_start),
>                               (paddr_t)(uintptr_t)(_end - _start), false);
> -    BUG_ON(!xen_bootmodule);
> +    BUG_ON(!xen_boot_module);
>  
>      fdt_size = boot_fdt_info(device_tree_flattened, fdt_paddr);
>  
> diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
> index 9daea06e57..39334d6205 100644
> --- a/xen/common/device-tree/bootfdt.c
> +++ b/xen/common/device-tree/bootfdt.c
> @@ -314,7 +314,7 @@ static void __init process_multiboot_node(const void *fdt, int node,
>      static int __initdata kind_guess = 0;
>      const struct fdt_property *prop;
>      const __be32 *cell;
> -    bootmodule_kind kind;
> +    boot_module_kind kind;
>      paddr_t start, size;
>      int len;
>      /* sizeof("/chosen/") + DT_MAX_NAME + '/' + DT_MAX_NAME + '/0' => 92 */
> @@ -518,7 +518,7 @@ static void __init early_print_info(void)
>  {
>      const struct membanks *mi = bootinfo_get_mem();
>      const struct membanks *mem_resv = bootinfo_get_reserved_mem();
> -    struct bootmodules *mods = &bootinfo.modules;
> +    struct boot_modules *mods = &bootinfo.modules;
>      struct bootcmdlines *cmds = &bootinfo.cmdlines;
>      unsigned int i;
>  
> diff --git a/xen/common/device-tree/bootinfo.c b/xen/common/device-tree/bootinfo.c
> index 717cfa0962..2a27d1318b 100644
> --- a/xen/common/device-tree/bootinfo.c
> +++ b/xen/common/device-tree/bootinfo.c
> @@ -21,7 +21,7 @@
>  
>  struct bootinfo __initdata bootinfo = BOOTINFO_INIT;
>  
> -const char * __init boot_module_kind_as_string(bootmodule_kind kind)
> +const char * __init boot_module_kind_as_string(boot_module_kind kind)
>  {
>      switch ( kind )
>      {
> @@ -49,7 +49,7 @@ static void __init dt_unreserved_regions(paddr_t s, paddr_t e,
>      unsigned int i;
>  
>      /*
> -     * i is the current bootmodule we are evaluating across all possible
> +     * i is the current boot_module we are evaluating across all possible
>       * kinds.
>       */
>      for ( i = first; i < reserved_mem->nr_banks; i++ )
> @@ -143,18 +143,18 @@ static bool __init meminfo_overlap_check(const struct membanks *mem,
>   * TODO: '*_end' could be 0 if the module/region is at the end of the physical
>   * address space. This is for now not handled as it requires more rework.
>   */
> -static bool __init bootmodules_overlap_check(struct bootmodules *bootmodules,
> -                                             paddr_t region_start,
> -                                             paddr_t region_size)
> +static bool __init boot_modules_overlap_check(struct boot_modules *boot_modules,
> +                                              paddr_t region_start,
> +                                              paddr_t region_size)
>  {
>      paddr_t mod_start = INVALID_PADDR, mod_end = 0;
>      paddr_t region_end = region_start + region_size;
> -    unsigned int i, mod_num = bootmodules->nr_mods;
> +    unsigned int i, mod_num = boot_modules->nr_mods;
>  
>      for ( i = 0; i < mod_num; i++ )
>      {
> -        mod_start = bootmodules->module[i].start;
> -        mod_end = mod_start + bootmodules->module[i].size;
> +        mod_start = boot_modules->module[i].start;
> +        mod_end = mod_start + boot_modules->module[i].size;
>  
>          if ( region_end <= mod_start || region_start >= mod_end )
>              continue;
> @@ -210,20 +210,20 @@ bool __init check_reserved_regions_overlap(paddr_t region_start,
>                                     allow_memreserve_overlap) )
>              return true;
>  
> -    /* Check if input region is overlapping with bootmodules */
> -    if ( bootmodules_overlap_check(&bootinfo.modules,
> -                                   region_start, region_size) )
> +    /* Check if input region is overlapping with boot_modules */
> +    if ( boot_modules_overlap_check(&bootinfo.modules,
> +                                    region_start, region_size) )
>          return true;
>  
>      return false;
>  }
>  
> -struct bootmodule __init *add_boot_module(bootmodule_kind kind,
> -                                          paddr_t start, paddr_t size,
> -                                          bool domU)
> +struct boot_module __init *add_boot_module(boot_module_kind kind,
> +                                           paddr_t start, paddr_t size,
> +                                           bool domU)
>  {
> -    struct bootmodules *mods = &bootinfo.modules;
> -    struct bootmodule *mod;
> +    struct boot_modules *mods = &bootinfo.modules;
> +    struct boot_module *mod;
>      unsigned int i;
>  
>      if ( mods->nr_mods == MAX_MODULES )
> @@ -266,10 +266,10 @@ struct bootmodule __init *add_boot_module(bootmodule_kind kind,
>   * XSM, DTB) or Dom0 modules. This is not suitable for looking up guest
>   * modules.
>   */
> -struct bootmodule * __init boot_module_find_by_kind(bootmodule_kind kind)
> +struct boot_module * __init boot_module_find_by_kind(boot_module_kind kind)
>  {
> -    struct bootmodules *mods = &bootinfo.modules;
> -    struct bootmodule *mod;
> +    struct boot_modules *mods = &bootinfo.modules;
> +    struct boot_module *mod;
>      int i;
>      for (i = 0 ; i < mods->nr_mods ; i++ )
>      {
> @@ -281,7 +281,7 @@ struct bootmodule * __init boot_module_find_by_kind(bootmodule_kind kind)
>  }
>  
>  void __init add_boot_cmdline(const char *name, const char *cmdline,
> -                             bootmodule_kind kind, paddr_t start, bool domU)
> +                             boot_module_kind kind, paddr_t start, bool domU)
>  {
>      struct bootcmdlines *cmds = &bootinfo.cmdlines;
>      struct bootcmdline *cmd;
> @@ -310,7 +310,7 @@ void __init add_boot_cmdline(const char *name, const char *cmdline,
>   * XSM, DTB) or Dom0 modules. This is not suitable for looking up guest
>   * modules.
>   */
> -struct bootcmdline * __init boot_cmdline_find_by_kind(bootmodule_kind kind)
> +struct bootcmdline * __init boot_cmdline_find_by_kind(boot_module_kind kind)
>  {
>      struct bootcmdlines *cmds = &bootinfo.cmdlines;
>      struct bootcmdline *cmd;
> @@ -340,11 +340,11 @@ struct bootcmdline * __init boot_cmdline_find_by_name(const char *name)
>      return NULL;
>  }
>  
> -struct bootmodule * __init boot_module_find_by_addr_and_kind(bootmodule_kind kind,
> -                                                             paddr_t start)
> +struct boot_module * __init boot_module_find_by_addr_and_kind(
> +    boot_module_kind kind, paddr_t start)
>  {
> -    struct bootmodules *mods = &bootinfo.modules;
> -    struct bootmodule *mod;
> +    struct boot_modules *mods = &bootinfo.modules;
> +    struct boot_module *mod;
>      unsigned int i;
>  
>      for (i = 0 ; i < mods->nr_mods ; i++ )
> @@ -366,7 +366,7 @@ struct bootmodule * __init boot_module_find_by_addr_and_kind(bootmodule_kind kin
>   */
>  static paddr_t __init next_module(paddr_t s, paddr_t *end)
>  {
> -    struct bootmodules *mi = &bootinfo.modules;
> +    struct boot_modules *mi = &bootinfo.modules;
>      paddr_t lowest = ~(paddr_t)0;
>      int i;
>  
> diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
> index 3d503c6973..221b875a2f 100644
> --- a/xen/common/device-tree/dom0less-build.c
> +++ b/xen/common/device-tree/dom0less-build.c
> @@ -44,13 +44,13 @@ void __init set_xs_domain(struct domain *d)
>  
>  bool __init is_dom0less_mode(void)
>  {
> -    struct bootmodules *mods = &bootinfo.modules;
> -    struct bootmodule *mod;
> +    struct boot_modules *mods = &bootinfo.modules;
> +    struct boot_module *mod;
>      unsigned int i;
>      bool dom0found = false;
>      bool domUfound = false;
>  
> -    /* Look into the bootmodules */
> +    /* Look into the boot_modules */
>      for ( i = 0 ; i < mods->nr_mods ; i++ )
>      {
>          mod = &mods->module[i];
> @@ -374,18 +374,17 @@ static int __init check_partial_fdt(void *pfdt, size_t size)
>      return 0;
>  }
>  
> -static int __init domain_handle_dtb_bootmodule(struct domain *d,
> -                                               struct kernel_info *kinfo)
> +static int __init domain_handle_dtb_boot_module(struct domain *d,
> +                                                struct kernel_info *kinfo)
>  {
>      void *pfdt;
>      int res, node_next;
>  
> -    pfdt = ioremap_cache(kinfo->dtb_bootmodule->start,
> -                         kinfo->dtb_bootmodule->size);
> +    pfdt = ioremap_cache(kinfo->dtb->start, kinfo->dtb->size);
>      if ( pfdt == NULL )
>          return -EFAULT;
>  
> -    res = check_partial_fdt(pfdt, kinfo->dtb_bootmodule->size);
> +    res = check_partial_fdt(pfdt, kinfo->dtb->size);
>      if ( res < 0 )
>          goto out;
>  
> @@ -459,8 +458,8 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
>      sizecells = GUEST_ROOT_SIZE_CELLS;
>  
>      /* Account for domU passthrough DT size */
> -    if ( kinfo->dtb_bootmodule )
> -        fdt_size += kinfo->dtb_bootmodule->size;
> +    if ( kinfo->dtb )
> +        fdt_size += kinfo->dtb->size;
>  
>      /* Cap to max DT size if needed */
>      fdt_size = min(fdt_size, SZ_2M);
> @@ -507,13 +506,13 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
>          goto err;
>  
>      /*
> -     * domain_handle_dtb_bootmodule has to be called before the rest of
> +     * domain_handle_dtb_boot_module has to be called before the rest of
>       * the device tree is generated because it depends on the value of
>       * the field phandle_intc.
>       */
> -    if ( kinfo->dtb_bootmodule )
> +    if ( kinfo->dtb )
>      {
> -        ret = domain_handle_dtb_bootmodule(d, kinfo);
> +        ret = domain_handle_dtb_boot_module(d, kinfo);
>          if ( ret )
>              goto err;
>      }
> diff --git a/xen/common/device-tree/domain-build.c b/xen/common/device-tree/domain-build.c
> index 6b8b8d7cac..fa4f700597 100644
> --- a/xen/common/device-tree/domain-build.c
> +++ b/xen/common/device-tree/domain-build.c
> @@ -347,7 +347,7 @@ void __init dtb_load(struct kernel_info *kinfo,
>  void __init initrd_load(struct kernel_info *kinfo,
>                          copy_to_guest_phys_cb copy_to_guest)
>  {
> -    const struct bootmodule *mod = kinfo->initrd_bootmodule;
> +    const struct boot_module *mod = kinfo->initrd;
>      paddr_t load_addr = kinfo->initrd_paddr;
>      paddr_t paddr, len;
>      int node;
> diff --git a/xen/common/device-tree/kernel.c b/xen/common/device-tree/kernel.c
> index cb04cd9d50..e1b22dc1c7 100644
> --- a/xen/common/device-tree/kernel.c
> +++ b/xen/common/device-tree/kernel.c
> @@ -21,7 +21,7 @@ static uint32_t __init output_length(char *image, unsigned long image_len)
>      return *(uint32_t *)&image[image_len - 4];
>  }
>  
> -int __init kernel_decompress(struct bootmodule *mod, uint32_t offset)
> +int __init kernel_decompress(struct boot_module *mod, uint32_t offset)
>  {
>      char *output, *input;
>      char magic[2];
> @@ -92,7 +92,7 @@ int __init kernel_decompress(struct bootmodule *mod, uint32_t offset)
>          free_domheap_page(pages + i);
>  
>      /*
> -     * When using static heap feature, don't give bootmodules memory back to
> +     * When using static heap feature, don't give boot_modules memory back to
>       * the heap allocator
>       */
>      if ( using_static_heap )
> @@ -118,7 +118,7 @@ int __init kernel_decompress(struct bootmodule *mod, uint32_t offset)
>  int __init kernel_probe(struct kernel_info *info,
>                          const struct dt_device_node *domain)
>  {
> -    struct bootmodule *mod = NULL;
> +    struct boot_module *mod = NULL;
>      struct bootcmdline *cmd = NULL;
>      struct dt_device_node *node;
>      u64 kernel_addr, initrd_addr, dtb_addr, size;
> @@ -140,8 +140,8 @@ int __init kernel_probe(struct kernel_info *info,
>  
>          mod = boot_module_find_by_kind(BOOTMOD_KERNEL);
>  
> -        info->kernel_bootmodule = mod;
> -        info->initrd_bootmodule = boot_module_find_by_kind(BOOTMOD_RAMDISK);
> +        info->kernel = mod;
> +        info->initrd = boot_module_find_by_kind(BOOTMOD_RAMDISK);
>  
>          cmd = boot_cmdline_find_by_kind(BOOTMOD_KERNEL);
>          if ( cmd )
> @@ -162,7 +162,7 @@ int __init kernel_probe(struct kernel_info *info,
>                  dt_get_range(&val, node, &kernel_addr, &size);
>                  mod = boot_module_find_by_addr_and_kind(
>                          BOOTMOD_KERNEL, kernel_addr);
> -                info->kernel_bootmodule = mod;
> +                info->kernel = mod;
>              }
>              else if ( dt_device_is_compatible(node, "multiboot,ramdisk") )
>              {
> @@ -171,7 +171,7 @@ int __init kernel_probe(struct kernel_info *info,
>  
>                  val = dt_get_property(node, "reg", &len);
>                  dt_get_range(&val, node, &initrd_addr, &size);
> -                info->initrd_bootmodule = boot_module_find_by_addr_and_kind(
> +                info->initrd = boot_module_find_by_addr_and_kind(
>                          BOOTMOD_RAMDISK, initrd_addr);
>              }
>              else if ( dt_device_is_compatible(node, "multiboot,device-tree") )
> @@ -183,7 +183,7 @@ int __init kernel_probe(struct kernel_info *info,
>                  if ( val == NULL )
>                      continue;
>                  dt_get_range(&val, node, &dtb_addr, &size);
> -                info->dtb_bootmodule = boot_module_find_by_addr_and_kind(
> +                info->dtb = boot_module_find_by_addr_and_kind(
>                          BOOTMOD_GUEST_DTB, dtb_addr);
>              }
>              else
> @@ -201,10 +201,10 @@ int __init kernel_probe(struct kernel_info *info,
>      }
>  
>      printk("Loading %pd kernel from boot module @ %"PRIpaddr"\n",
> -           info->d, info->kernel_bootmodule->start);
> -    if ( info->initrd_bootmodule )
> +           info->d, info->kernel->start);
> +    if ( info->initrd )
>          printk("Loading ramdisk from boot module @ %"PRIpaddr"\n",
> -               info->initrd_bootmodule->start);
> +               info->initrd->start);
>  
>      /*
>       * uImage isn't really used nowadays thereby leave kernel_uimage_probe()
> diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
> index ff40f3078e..236b456dd2 100644
> --- a/xen/include/xen/bootfdt.h
> +++ b/xen/include/xen/bootfdt.h
> @@ -23,7 +23,7 @@ typedef enum {
>      BOOTMOD_GUEST_DTB,
>      BOOTMOD_MICROCODE,
>      BOOTMOD_UNKNOWN
> -}  bootmodule_kind;
> +}  boot_module_kind;
>  
>  enum membank_type {
>      /*
> @@ -103,8 +103,8 @@ struct shared_meminfo {
>   * initrd to be compatible with all versions of the multiboot spec.
>   */
>  #define BOOTMOD_MAX_CMDLINE 1024
> -struct bootmodule {
> -    bootmodule_kind kind;
> +struct boot_module {
> +    boot_module_kind kind;
>      bool domU;
>      paddr_t start;
>      paddr_t size;
> @@ -113,16 +113,16 @@ struct bootmodule {
>  /* DT_MAX_NAME is the node name max length according the DT spec */
>  #define DT_MAX_NAME 41
>  struct bootcmdline {
> -    bootmodule_kind kind;
> +    boot_module_kind kind;
>      bool domU;
>      paddr_t start;
>      char dt_name[DT_MAX_NAME];
>      char cmdline[BOOTMOD_MAX_CMDLINE];
>  };
>  
> -struct bootmodules {
> +struct boot_modules {
>      int nr_mods;
> -    struct bootmodule module[MAX_MODULES];
> +    struct boot_module module[MAX_MODULES];
>  };
>  
>  struct bootcmdlines {
> @@ -134,7 +134,7 @@ struct bootinfo {
>      struct meminfo mem;
>      /* The reserved regions are only used when booting using Device-Tree */
>      struct meminfo reserved_mem;
> -    struct bootmodules modules;
> +    struct boot_modules modules;
>      struct bootcmdlines cmdlines;
>  #ifdef CONFIG_ACPI
>      struct meminfo acpi;
> @@ -176,16 +176,16 @@ bool check_reserved_regions_overlap(paddr_t region_start,
>                                      paddr_t region_size,
>                                      bool allow_memreserve_overlap);
>  
> -struct bootmodule *add_boot_module(bootmodule_kind kind,
> +struct boot_module *add_boot_module(boot_module_kind kind,
>                                     paddr_t start, paddr_t size, bool domU);
> -struct bootmodule *boot_module_find_by_kind(bootmodule_kind kind);
> -struct bootmodule * boot_module_find_by_addr_and_kind(bootmodule_kind kind,
> +struct boot_module *boot_module_find_by_kind(boot_module_kind kind);
> +struct boot_module * boot_module_find_by_addr_and_kind(boot_module_kind kind,
>                                                               paddr_t start);
>  void add_boot_cmdline(const char *name, const char *cmdline,
> -                      bootmodule_kind kind, paddr_t start, bool domU);
> -struct bootcmdline *boot_cmdline_find_by_kind(bootmodule_kind kind);
> +                      boot_module_kind kind, paddr_t start, bool domU);
> +struct bootcmdline *boot_cmdline_find_by_kind(boot_module_kind kind);
>  struct bootcmdline * boot_cmdline_find_by_name(const char *name);
> -const char *boot_module_kind_as_string(bootmodule_kind kind);
> +const char *boot_module_kind_as_string(boot_module_kind kind);
>  
>  void populate_boot_allocator(void);
>  
> diff --git a/xen/include/xen/fdt-kernel.h b/xen/include/xen/fdt-kernel.h
> index 1939c3ebf7..12a0b42d17 100644
> --- a/xen/include/xen/fdt-kernel.h
> +++ b/xen/include/xen/fdt-kernel.h
> @@ -34,7 +34,7 @@ struct kernel_info {
>      paddr_t gnttab_size;
>  
>      /* boot blob load addresses */
> -    const struct bootmodule *kernel_bootmodule, *initrd_bootmodule, *dtb_bootmodule;
> +    const struct boot_module *kernel, *initrd, *dtb;
>      const char* cmdline;
>      paddr_t dtb_paddr;
>      paddr_t initrd_paddr;
> @@ -121,7 +121,7 @@ int kernel_probe(struct kernel_info *info, const struct dt_device_node *domain);
>   */
>  void kernel_load(struct kernel_info *info);
>  
> -int kernel_decompress(struct bootmodule *mod, uint32_t offset);
> +int kernel_decompress(struct boot_module *mod, uint32_t offset);
>  
>  int kernel_zimage_probe(struct kernel_info *info, paddr_t addr, paddr_t size);
>  
> @@ -130,8 +130,7 @@ int kernel_zimage_probe(struct kernel_info *info, paddr_t addr, paddr_t size);
>   * call here just for compatability with Arm code.
>   */
>  #ifdef CONFIG_ARM
> -struct bootmodule;

I just wanted to mention that I went line by line and this is the only
not search-and-replace change in this patch.

Reviewed-by: Stefano Stabellini 


> -int kernel_uimage_probe(struct kernel_info *info, struct bootmodule *mod);
> +int kernel_uimage_probe(struct kernel_info *info, struct boot_module *mod);
>  #endif
>  
>  #endif /* __XEN_FDT_KERNEL_H__ */
> diff --git a/xen/xsm/xsm_policy.c b/xen/xsm/xsm_policy.c
> index 7f70d860bd..1f88b4fc5a 100644
> --- a/xen/xsm/xsm_policy.c
> +++ b/xen/xsm/xsm_policy.c
> @@ -68,7 +68,7 @@ int __init xsm_multiboot_policy_init(
>  #ifdef CONFIG_HAS_DEVICE_TREE
>  int __init xsm_dt_policy_init(void **policy_buffer, size_t *policy_size)
>  {
> -    struct bootmodule *mod = boot_module_find_by_kind(BOOTMOD_XSM);
> +    struct boot_module *mod = boot_module_find_by_kind(BOOTMOD_XSM);
>      paddr_t paddr, len;
>  
>      if ( !mod || !mod->size )
> -- 
> 2.43.0
> 


From xen-devel-bounces@lists.xenproject.org Sat Jun 14 00:55:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jun 2025 00:55:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1015133.1393065 (Exim 4.92)
	(envelope-from )
	id 1uQFAh-0006Qs-65; Sat, 14 Jun 2025 00:54:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1015133.1393065; Sat, 14 Jun 2025 00:54: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 1uQFAh-0006Ql-2c; Sat, 14 Jun 2025 00:54:59 +0000
Received: by outflank-mailman (input) for mailman id 1015133;
 Sat, 14 Jun 2025 00:54: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 1uQFAf-0006Qf-RK
 for xen-devel@lists.xenproject.org; Sat, 14 Jun 2025 00:54:57 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2f8f32fe-48ba-11f0-a309-13f23c93f187;
 Sat, 14 Jun 2025 02:54:55 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 1F5114A8FE;
 Sat, 14 Jun 2025 00:54:54 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id A454AC4CEE3;
 Sat, 14 Jun 2025 00:54:52 +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: 2f8f32fe-48ba-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749862494;
	bh=5Y4Jxm55HtW/ogZ7bPNjtMmjHbwk/pl5TtQ0yTP0lWE=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=OmiZR2xiB1nJL6olbR3ynNR4g2gngq2j2XzO8F6xTtJOFzIw9X1t4Ab21wvLIv6GB
	 iQaoFz9tGZlXNMc4rFz9z7f/kTFeO1AUZu9nzPB1ngHZZUrnZHTD5drY4yLVS5KJZy
	 c8+3ViRNCG0za4MiTtL2NDLWaUI9iLRGKPMypNtJGrr89eEZYUgZK0Ysrsh3dz8BNR
	 1kJasS3+CqrC3RZSb0B6nlG9KuBH5Sby5/CtEW7WcPvtCbTE/HvdlbsuEIOWtCzqz5
	 ucteaRxQH7sbxQNB8fixn7nUOo2OJKOyWfDaNaR3xzgtWC9Z2fBFzEwU4/QfhcSzaF
	 uP8mP9j6rJtLg==
Date: Fri, 13 Jun 2025 17:54:51 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: xen-devel@lists.xenproject.org, Jan Beulich , 
    Andrew Cooper , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    "Daniel P. Smith" 
Subject: Re: [PATCH v3 05/14] x86: Replace arch-specific boot_module with
 common one
In-Reply-To: <20250613151612.754222-6-agarciav@amd.com>
Message-ID: 
References: <20250613151612.754222-1-agarciav@amd.com> <20250613151612.754222-6-agarciav@amd.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 Jun 2025, Alejandro Vallejo wrote:
> These types resemble each other very closely in layout and intent,
> and with "struct boot_module" already in common code it makes perfect
> sense to merge them. In order to do so, add an arch-specific area for
> x86-specific tidbits, and rename identical fields with conflicting
> names.
> 
> No functional change intended.
> 
> Signed-off-by: Alejandro Vallejo 

Hi Alejandro, this patch doesn't apply to staging anymore, it conflict
with 3998da124.


> ---
>  xen/arch/x86/cpu/microcode/core.c   |  7 ++--
>  xen/arch/x86/hvm/dom0_build.c       |  8 ++---
>  xen/arch/x86/include/asm/bootfdt.h  | 50 ++++++++++++++++++++++++++
>  xen/arch/x86/include/asm/bootinfo.h | 56 +++--------------------------
>  xen/arch/x86/pv/dom0_build.c        |  6 ++--
>  xen/arch/x86/setup.c                | 42 +++++++++++-----------
>  xen/include/xen/bootfdt.h           |  8 +++++
>  xen/xsm/xsm_policy.c                |  2 +-
>  8 files changed, 95 insertions(+), 84 deletions(-)
>  create mode 100644 xen/arch/x86/include/asm/bootfdt.h
> 
> diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c
> index 34a94cd25b..816e9bfe40 100644
> --- a/xen/arch/x86/cpu/microcode/core.c
> +++ b/xen/arch/x86/cpu/microcode/core.c
> @@ -764,8 +764,7 @@ static int __init early_microcode_load(struct boot_info *bi)
>              struct cpio_data cd;
>  
>              /* Search anything unclaimed or likely to be a CPIO archive. */
> -            if ( bm->type != BOOTMOD_UNKNOWN &&
> -                 bm->type != BOOTMOD_RAMDISK )
> +            if ( bm->kind != BOOTMOD_UNKNOWN && bm->kind != BOOTMOD_RAMDISK )
>                  continue;
>  
>              size = bm->size;
> @@ -815,12 +814,12 @@ static int __init early_microcode_load(struct boot_info *bi)
>              return -ENODEV;
>          }
>  
> -        if ( bi->mods[idx].type != BOOTMOD_UNKNOWN )
> +        if ( bi->mods[idx].kind != BOOTMOD_UNKNOWN )
>          {
>              printk(XENLOG_WARNING "Microcode: Chosen module %d already used\n", idx);
>              return -ENODEV;
>          }
> -        bi->mods[idx].type = BOOTMOD_MICROCODE;
> +        bi->mods[idx].kind = BOOTMOD_MICROCODE;
>  
>          size = bi->mods[idx].size;
>          data = bootstrap_map_bm(&bi->mods[idx]);
> diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
> index a038e58c11..8d2734f2b5 100644
> --- a/xen/arch/x86/hvm/dom0_build.c
> +++ b/xen/arch/x86/hvm/dom0_build.c
> @@ -648,9 +648,9 @@ static int __init pvh_load_kernel(
>  {
>      struct domain *d = bd->d;
>      struct boot_module *image = bd->kernel;
> -    struct boot_module *initrd = bd->module;
> +    struct boot_module *initrd = bd->initrd;

It looks like struct boot_domain is still calling its member "module" at
this point


>      void *image_base = bootstrap_map_bm(image);
> -    void *image_start = image_base + image->headroom;
> +    void *image_start = image_base + image->arch.headroom;
>      unsigned long image_len = image->size;
>      unsigned long initrd_len = initrd ? initrd->size : 0;
>      size_t cmdline_len = bd->cmdline ? strlen(bd->cmdline) + 1 : 0;
> @@ -721,9 +721,9 @@ static int __init pvh_load_kernel(
>      {
>          size_t initrd_space = elf_round_up(&elf, initrd_len);
>  
> -        if ( initrd->cmdline_pa )
> +        if ( initrd->arch.cmdline_pa )
>          {
> -            initrd_cmdline = __va(initrd->cmdline_pa);
> +            initrd_cmdline = __va(initrd->arch.cmdline_pa);
>              if ( !*initrd_cmdline )
>                  initrd_cmdline = NULL;
>          }
> diff --git a/xen/arch/x86/include/asm/bootfdt.h b/xen/arch/x86/include/asm/bootfdt.h
> new file mode 100644
> index 0000000000..a4c4bf30b9
> --- /dev/null
> +++ b/xen/arch/x86/include/asm/bootfdt.h
> @@ -0,0 +1,50 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef X86_BOOTFDT_H
> +#define X86_BOOTFDT_H
> +
> +#include 
> +
> +struct arch_boot_module
> +{
> +    /*
> +     * Module State Flags:
> +     *   relocated:   indicates module has been relocated in memory.
> +     *   released:    indicates module's pages have been freed.
> +     */
> +    bool relocated:1;
> +    bool released:1;
> +
> +    /*
> +     * A boot module may need decompressing by Xen.  Headroom is an estimate of
> +     * the additional space required to decompress the module.
> +     *
> +     * Headroom is accounted for at the start of the module.  Decompressing is
> +     * done in-place with input=start, output=start-headroom, expecting the
> +     * pointers to become equal (give or take some rounding) when decompression
> +     * is complete.
> +     *
> +     * Memory layout at boot:
> +     *
> +     *               start ----+
> +     *                         v
> +     *   |<-----headroom------>|<------size------->|
> +     *                         +-------------------+
> +     *                         | Compressed Module |
> +     *   +---------------------+-------------------+
> +     *   |           Decompressed Module           |
> +     *   +-----------------------------------------+
> +     */
> +    unsigned long headroom;
> +    paddr_t cmdline_pa;
> +};
> +
> +#endif /* X86_BOOTFDT_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/bootinfo.h b/xen/arch/x86/include/asm/bootinfo.h
> index 3afc214c17..d33b100e04 100644
> --- a/xen/arch/x86/include/asm/bootinfo.h
> +++ b/xen/arch/x86/include/asm/bootinfo.h
> @@ -8,6 +8,7 @@
>  #ifndef X86_BOOTINFO_H
>  #define X86_BOOTINFO_H
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -19,55 +20,6 @@
>  /* Max number of boot domains that Xen can construct */
>  #define MAX_NR_BOOTDOMS 1
>  
> -/* Boot module binary type / purpose */
> -enum bootmod_type {
> -    BOOTMOD_UNKNOWN,
> -    BOOTMOD_XEN,
> -    BOOTMOD_KERNEL,
> -    BOOTMOD_RAMDISK,
> -    BOOTMOD_MICROCODE,
> -    BOOTMOD_XSM_POLICY,
> -};
> -
> -struct boot_module {
> -    enum bootmod_type type;
> -
> -    /*
> -     * Module State Flags:
> -     *   relocated: indicates module has been relocated in memory.
> -     *   released:  indicates module's pages have been freed.
> -     */
> -    bool relocated:1;
> -    bool released:1;
> -
> -    /*
> -     * A boot module may need decompressing by Xen.  Headroom is an estimate of
> -     * the additional space required to decompress the module.
> -     *
> -     * Headroom is accounted for at the start of the module.  Decompressing is
> -     * done in-place with input=start, output=start-headroom, expecting the
> -     * pointers to become equal (give or take some rounding) when decompression
> -     * is complete.
> -     *
> -     * Memory layout at boot:
> -     *
> -     *               start ----+
> -     *                         v
> -     *   |<-----headroom------>|<------size------->|
> -     *                         +-------------------+
> -     *                         | Compressed Module |
> -     *   +---------------------+-------------------+
> -     *   |           Decompressed Module           |
> -     *   +-----------------------------------------+
> -     */
> -    unsigned long headroom;
> -
> -    paddr_t cmdline_pa;
> -
> -    paddr_t start;
> -    size_t size;
> -};
> -
>  /*
>   * Xen internal representation of information provided by the
>   * bootloader/environment, or derived from the information.
> @@ -94,16 +46,16 @@ struct boot_info {
>   *      Failure - a value greater than MAX_NR_BOOTMODS
>   */
>  static inline unsigned int __init next_boot_module_index(
> -    const struct boot_info *bi, enum bootmod_type t, unsigned int start)
> +    const struct boot_info *bi, boot_module_kind k, unsigned int start)
>  {
>      unsigned int i;
>  
> -    if ( t == BOOTMOD_XEN )
> +    if ( k == BOOTMOD_XEN )
>          return bi->nr_modules;
>  
>      for ( i = start; i < bi->nr_modules; i++ )
>      {
> -        if ( bi->mods[i].type == t )
> +        if ( bi->mods[i].kind == k )
>              return i;
>      }
>  
> diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
> index e1b78d47c2..c37bea9454 100644
> --- a/xen/arch/x86/pv/dom0_build.c
> +++ b/xen/arch/x86/pv/dom0_build.c
> @@ -375,7 +375,7 @@ static int __init dom0_construct(const struct boot_domain *bd)
>      struct vcpu *v = d->vcpu[0];
>  
>      struct boot_module *image = bd->kernel;
> -    struct boot_module *initrd = bd->module;
> +    struct boot_module *initrd = bd->initrd;
>      void *image_base;
>      unsigned long image_len;
>      void *image_start;
> @@ -422,7 +422,7 @@ static int __init dom0_construct(const struct boot_domain *bd)
>  
>      image_base = bootstrap_map_bm(image);
>      image_len = image->size;
> -    image_start = image_base + image->headroom;
> +    image_start = image_base + image->arch.headroom;
>  
>      d->max_pages = ~0U;
>  
> @@ -659,7 +659,7 @@ static int __init dom0_construct(const struct boot_domain *bd)
>               * pages. Tell the boot_module handling that we've freed it, so the
>               * memory is left alone.
>               */
> -            initrd->released = true;
> +            initrd->arch.released = true;
>          }
>  
>          iommu_memory_setup(d, "initrd", mfn_to_page(_mfn(initrd_mfn)),
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index 7d3b30e1db..c00b22205a 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -303,7 +303,7 @@ struct boot_info __initdata xen_boot_info = {
>       *
>       * The extra entry exists to be able to add the Xen image as a module.
>       */
> -    .mods = { [0 ... MAX_NR_BOOTMODS] = { .type = BOOTMOD_UNKNOWN } },
> +    .mods = { [0 ... MAX_NR_BOOTMODS] = { .kind = BOOTMOD_UNKNOWN } },
>  };
>  
>  static struct boot_info *__init multiboot_fill_boot_info(
> @@ -338,7 +338,7 @@ static struct boot_info *__init multiboot_fill_boot_info(
>       */
>      for ( i = 0; i < MAX_NR_BOOTMODS && i < bi->nr_modules; i++ )
>      {
> -        bi->mods[i].cmdline_pa = mods[i].string;
> +        bi->mods[i].arch.cmdline_pa = mods[i].string;
>  
>          if ( efi_enabled(EFI_LOADER) )
>          {
> @@ -361,7 +361,7 @@ 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;
> +    bi->mods[i].kind = BOOTMOD_XEN;
>  
>      return bi;
>  }
> @@ -388,11 +388,11 @@ unsigned long __init initial_images_nrpages(nodeid_t node)
>  
>  void __init release_boot_module(struct boot_module *bm)
>  {
> -    ASSERT(!bm->released);
> +    ASSERT(!bm->arch.released);
>  
>      init_domheap_pages(bm->start, bm->start + PAGE_ALIGN(bm->size));
>  
> -    bm->released = true;
> +    bm->arch.released = true;
>  }
>  
>  void __init free_boot_modules(void)
> @@ -402,7 +402,7 @@ void __init free_boot_modules(void)
>  
>      for ( i = 0; i < bi->nr_modules; ++i )
>      {
> -        if ( bi->mods[i].released )
> +        if ( bi->mods[i].arch.released )
>              continue;
>  
>          release_boot_module(&bi->mods[i]);
> @@ -990,8 +990,9 @@ static size_t __init domain_cmdline_size(const struct boot_info *bi,
>                                           const struct boot_domain *bd)
>  {
>      size_t s = bi->kextra ? strlen(bi->kextra) : 0;
> +    const struct arch_boot_module *abm = &bd->kernel->arch;
>  
> -    s += bd->kernel->cmdline_pa ? strlen(__va(bd->kernel->cmdline_pa)) : 0;
> +    s += abm->cmdline_pa ? strlen(__va(abm->cmdline_pa)) : 0;
>  
>      if ( s == 0 )
>          return s;
> @@ -1055,9 +1056,10 @@ 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->arch.cmdline_pa )
>              strlcpy(cmdline,
> -                    cmdline_cook(__va(bd->kernel->cmdline_pa), bi->loader),
> +                    cmdline_cook(__va(bd->kernel->arch.cmdline_pa),
> +                                 bi->loader),
>                      cmdline_size);
>  
>          if ( bi->kextra )
> @@ -1079,7 +1081,7 @@ static struct domain *__init create_dom0(struct boot_info *bi)
>              strlcat(cmdline, " acpi=", cmdline_size);
>              strlcat(cmdline, acpi_param, cmdline_size);
>          }
> -        bd->kernel->cmdline_pa = 0;
> +        bd->kernel->arch.cmdline_pa = 0;
>          bd->cmdline = cmdline;
>      }
>  
> @@ -1292,7 +1294,7 @@ void asmlinkage __init noreturn __start_xen(void)
>      }
>  
>      /* Dom0 kernel is always first */
> -    bi->mods[0].type = BOOTMOD_KERNEL;
> +    bi->mods[0].kind = BOOTMOD_KERNEL;
>      bi->domains[0].kernel = &bi->mods[0];
>  
>      if ( pvh_boot )
> @@ -1476,7 +1478,7 @@ void asmlinkage __init noreturn __start_xen(void)
>          xen->size  = __2M_rwdata_end - _stext;
>      }
>  
> -    bi->mods[0].headroom =
> +    bi->mods[0].arch.headroom =
>          bzimage_headroom(bootstrap_map_bm(&bi->mods[0]), bi->mods[0].size);
>      bootstrap_unmap();
>  
> @@ -1558,9 +1560,9 @@ void asmlinkage __init noreturn __start_xen(void)
>          for ( j = bi->nr_modules - 1; j >= 0; j-- )
>          {
>              struct boot_module *bm = &bi->mods[j];
> -            unsigned long size = PAGE_ALIGN(bm->headroom + bm->size);
> +            unsigned long size = PAGE_ALIGN(bm->arch.headroom + bm->size);
>  
> -            if ( bm->relocated )
> +            if ( bm->arch.relocated )
>                  continue;
>  
>              /* Don't overlap with other modules (or Xen itself). */
> @@ -1570,12 +1572,12 @@ void asmlinkage __init noreturn __start_xen(void)
>              if ( highmem_start && end > highmem_start )
>                  continue;
>  
> -            if ( s < end && (bm->headroom || (end - size) > bm->start) )
> +            if ( s < end && (bm->arch.headroom || (end - size) > bm->start) )
>              {
> -                move_memory(end - size + bm->headroom, bm->start, bm->size);
> +                move_memory(end - size + bm->arch.headroom, bm->start, bm->size);
>                  bm->start = (end - size);
> -                bm->size += bm->headroom;
> -                bm->relocated = true;
> +                bm->size += bm->arch.headroom;
> +                bm->arch.relocated = true;
>              }
>          }
>  
> @@ -1601,7 +1603,7 @@ void asmlinkage __init noreturn __start_xen(void)
>  #endif
>      }
>  
> -    if ( bi->mods[0].headroom && !bi->mods[0].relocated )
> +    if ( bi->mods[0].arch.headroom && !bi->mods[0].arch.relocated )
>          panic("Not enough memory to relocate the dom0 kernel image\n");
>      for ( i = 0; i < bi->nr_modules; ++i )
>      {
> @@ -2159,7 +2161,7 @@ void asmlinkage __init noreturn __start_xen(void)
>      initrdidx = first_boot_module_index(bi, BOOTMOD_UNKNOWN);
>      if ( initrdidx < MAX_NR_BOOTMODS )
>      {
> -        bi->mods[initrdidx].type = BOOTMOD_RAMDISK;
> +        bi->mods[initrdidx].kind = BOOTMOD_RAMDISK;
>          bi->domains[0].module = &bi->mods[initrdidx];
>          if ( first_boot_module_index(bi, BOOTMOD_UNKNOWN) < MAX_NR_BOOTMODS )
>              printk(XENLOG_WARNING
> diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
> index 236b456dd2..854e7f1ed9 100644
> --- a/xen/include/xen/bootfdt.h
> +++ b/xen/include/xen/bootfdt.h
> @@ -7,6 +7,10 @@
>  #include 
>  #include 
>  
> +#if __has_include()
> +#include 
> +#endif
> +
>  #define MIN_FDT_ALIGN 8
>  
>  #define NR_MEM_BANKS 256
> @@ -108,6 +112,10 @@ struct boot_module {
>      bool domU;
>      paddr_t start;
>      paddr_t size;
> +
> +#if __has_include()
> +    struct arch_boot_module arch;
> +#endif
>  };
>  
>  /* DT_MAX_NAME is the node name max length according the DT spec */
> diff --git a/xen/xsm/xsm_policy.c b/xen/xsm/xsm_policy.c
> index 1f88b4fc5a..1b4030edb4 100644
> --- a/xen/xsm/xsm_policy.c
> +++ b/xen/xsm/xsm_policy.c
> @@ -53,7 +53,7 @@ int __init xsm_multiboot_policy_init(
>              printk("Policy len %#lx, start at %p.\n",
>                     _policy_len,_policy_start);
>  
> -            bm->type = BOOTMOD_XSM_POLICY;
> +            bm->kind = BOOTMOD_XSM;
>              break;
>  
>          }
> -- 
> 2.43.0
> 


From xen-devel-bounces@lists.xenproject.org Sat Jun 14 00:58:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jun 2025 00:58:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1015140.1393074 (Exim 4.92)
	(envelope-from )
	id 1uQFDy-0006xL-Ja; Sat, 14 Jun 2025 00:58:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1015140.1393074; Sat, 14 Jun 2025 00:58: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 1uQFDy-0006xE-GB; Sat, 14 Jun 2025 00:58:22 +0000
Received: by outflank-mailman (input) for mailman id 1015140;
 Sat, 14 Jun 2025 00:58: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 1uQFDx-0006x8-7L
 for xen-devel@lists.xenproject.org; Sat, 14 Jun 2025 00:58:21 +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 a8d37feb-48ba-11f0-b894-0df219b8e170;
 Sat, 14 Jun 2025 02:58:19 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id C18BA5C5A60;
 Sat, 14 Jun 2025 00:56:00 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id A91FDC4CEE3;
 Sat, 14 Jun 2025 00:58: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: a8d37feb-48ba-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749862697;
	bh=2hWien/bpYiWG4yB1oY6NNFa7SpxGfkia0IGCGkB2Sk=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=IBwz5qYhLPXMGPTDaZ1eouvYlli+JqzfR7Keg8pre1OyhbAw5hGPwRa7I0jD0M9R9
	 yybwI75P0Pr7FH5yR2kCxNdq1p5z8tu2gi79wb7xwPnp0+DVIUwbZlCSKdgS49fUUU
	 ME6OCPutr1EVZHKsebPKhisUoTJHGCQkboc/fENX+2CKFBpEK6tHTdzV0r6UAU6lSr
	 EVVhSGJShrKgFpMV0XRcD71d1Q5yyDbicFYDtzwKHmyoL9neRqtV5msWIh+sImQr1y
	 yfaBKVnPF78KTJK6jY5lynlTs6jBl++Q/c1PpYeCHTV3SJRqO6JTkqO4+UkLS3ACZn
	 8U4ANe86QZwFg==
Date: Fri, 13 Jun 2025 17:58:14 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    Andrew Cooper , 
    Anthony PERARD , 
    Jan Beulich , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    "Daniel P. Smith" 
Subject: Re: [PATCH v3 06/14] xen: Refactor kernel_info to have a header like
 boot_domain
In-Reply-To: <20250613151612.754222-7-agarciav@amd.com>
Message-ID: 
References: <20250613151612.754222-1-agarciav@amd.com> <20250613151612.754222-7-agarciav@amd.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 Jun 2025, Alejandro Vallejo wrote:
> Create a struct header within kernel_info with the contents common to
> kernel_info and boot_domain, and define that header in common code. This enables
> x86 to use that header as-is and drop x86's boot_domain.
> 
> Not a functional change.
> 
> Signed-off-by: Alejandro Vallejo 

Reviewed-by: Stefano Stabellini 



From xen-devel-bounces@lists.xenproject.org Sat Jun 14 01:08:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jun 2025 01:08:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1015154.1393084 (Exim 4.92)
	(envelope-from )
	id 1uQFNT-0007zd-EX; Sat, 14 Jun 2025 01:08:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1015154.1393084; Sat, 14 Jun 2025 01:08: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 1uQFNT-0007zW-Br; Sat, 14 Jun 2025 01:08:11 +0000
Received: by outflank-mailman (input) for mailman id 1015154;
 Sat, 14 Jun 2025 01:08: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 1uQFNS-0007zQ-12
 for xen-devel@lists.xenproject.org; Sat, 14 Jun 2025 01:08:10 +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 08639518-48bc-11f0-a309-13f23c93f187;
 Sat, 14 Jun 2025 03:08:08 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 9ED8EA50EA3;
 Sat, 14 Jun 2025 01:08:07 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1AF55C4CEE3;
 Sat, 14 Jun 2025 01:08: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: 08639518-48bc-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749863287;
	bh=Skl9pqy7QFESPUsAsswkCSbtRvw/ygIJOK1oSXYKeiM=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=BtF2OmyIqElhACL6I9MfTRm2QPK6+x+fcLA4uG9ZblN5DRdkYjRubOUlUseYf+5L3
	 GCTVWqPmerhd9Hpg0lIlYL6dRN/2oei5LpTeWJv0sqBsqkfiWRFfS5/YDSjPi+Dptq
	 4W/XZqQE0VfuicfTlbzi2pOqNP4bkcoO4RJks4Zu5oSKpF+zcRwYWbEknqP+0sYpSU
	 DMOaDx5eucXNxj5LDMr6WQ4ZcboPAjeN/IlTP97vFo5yyans9u8vzWQddFfRCyEXBL
	 OV+Vy3zV7g827KPzzRrgfsJQ5g0O0d/zem/xKdwIjK2sf7eIH9Nqnb1Vq7XcmVkKJc
	 eYMcXAeCt+ZQg==
Date: Fri, 13 Jun 2025 18:08:04 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: xen-devel@lists.xenproject.org, Jan Beulich , 
    Andrew Cooper , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    "Daniel P. Smith" 
Subject: Re: [PATCH v3 07/14] x86: Replace arch-specific boot_domain common
 one bootdomain
In-Reply-To: <20250613151612.754222-8-agarciav@amd.com>
Message-ID: 
References: <20250613151612.754222-1-agarciav@amd.com> <20250613151612.754222-8-agarciav@amd.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 Jun 2025, Alejandro Vallejo wrote:
> Add the single arch-specific field in an "arch" subfield defined in
> asm/bootfdt.h.
> 
> No functional change intended.
> 
> Signed-off-by: Alejandro Vallejo 
>
> ---
> v3:
>   * Avoid the bootdomain/boot_domain renames.
> ---
>  xen/arch/x86/include/asm/boot-domain.h | 33 --------------------------
>  xen/arch/x86/include/asm/bootfdt.h     |  6 +++++
>  xen/arch/x86/include/asm/bootinfo.h    |  1 -
>  xen/arch/x86/setup.c                   | 12 ++++++----
>  xen/include/xen/bootfdt.h              |  4 ++++
>  5 files changed, 17 insertions(+), 39 deletions(-)
>  delete mode 100644 xen/arch/x86/include/asm/boot-domain.h
> 
> diff --git a/xen/arch/x86/include/asm/boot-domain.h b/xen/arch/x86/include/asm/boot-domain.h
> deleted file mode 100644
> index d7c6042e25..0000000000
> --- a/xen/arch/x86/include/asm/boot-domain.h
> +++ /dev/null
> @@ -1,33 +0,0 @@
> -/* 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__
> -
> -#include 
> -
> -struct boot_domain {
> -    domid_t domid;
> -
> -    struct boot_module *kernel;
> -    struct boot_module *module;
> -    const char *cmdline;
> -
> -    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/bootfdt.h b/xen/arch/x86/include/asm/bootfdt.h
> index a4c4bf30b9..c21dbe961b 100644
> --- a/xen/arch/x86/include/asm/bootfdt.h
> +++ b/xen/arch/x86/include/asm/bootfdt.h
> @@ -3,6 +3,12 @@
>  #define X86_BOOTFDT_H
>  
>  #include 
> +#include 
> +
> +struct arch_boot_domain
> +{
> +    domid_t domid;
> +};

With the understanding from your previous reply that it is best not to
use d->domain_id:

Reviewed-by: Stefano Stabellini 


>  struct arch_boot_module
>  {



From xen-devel-bounces@lists.xenproject.org Sat Jun 14 01:17:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jun 2025 01:17:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1015161.1393095 (Exim 4.92)
	(envelope-from )
	id 1uQFW4-0001Gq-89; Sat, 14 Jun 2025 01:17:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1015161.1393095; Sat, 14 Jun 2025 01: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 1uQFW4-0001Gj-4g; Sat, 14 Jun 2025 01:17:04 +0000
Received: by outflank-mailman (input) for mailman id 1015161;
 Sat, 14 Jun 2025 01: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 1uQFW2-0001Gd-Ts
 for xen-devel@lists.xenproject.org; Sat, 14 Jun 2025 01:17:02 +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 457687ce-48bd-11f0-a309-13f23c93f187;
 Sat, 14 Jun 2025 03:17:00 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id B1E06A50F80;
 Sat, 14 Jun 2025 01:16:59 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6E8C3C4CEE3;
 Sat, 14 Jun 2025 01:16:58 +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: 457687ce-48bd-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749863819;
	bh=6JESW/cI/lnx2FyTaKKVLeDgkRtZNQyle9Q+LwpGlYk=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=H7JCwUnCkTeXgXF0yk7DVzQKMs28wh/Kloj2ZElpjgD7ECfLc2T2392MHyNeZ0QCF
	 QRq3abskyXXygsdzNU3t6kyF09MKbZf5ytgrucTmiJQXrHLJNIalXZZO3qNvbRWcNW
	 n20OXATtTHy6Bin9JE0ASHFRN9SgIk1SJXYlFbEvDIR7vWCY/nDKEjEKfObM4wzOtp
	 YghJoEZ7I25BLKIZYZagYGhO1AXDEqyFSF0RwY2+52hvb8vIptbdrJEDJ81vYlYb05
	 JkKsQeW9APycXE+Z1y/Hy6Gv949bDTqaHkA66zB0g8z8PnQ7exg8Rhg681PIGBrZ6J
	 9asyw2s9K+l5g==
Date: Fri, 13 Jun 2025 18:16:57 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    "Daniel P. Smith" 
Subject: Re: [PATCH v3 08/14] xen/dt: Move bootfdt functions to
 xen/bootfdt.h
In-Reply-To: <20250613151612.754222-9-agarciav@amd.com>
Message-ID: 
References: <20250613151612.754222-1-agarciav@amd.com> <20250613151612.754222-9-agarciav@amd.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 Jun 2025, Alejandro Vallejo wrote:
> Part of an unpicking process to extract bootfdt contents independent of bootinfo
> to a separate file for x86 to take.
> 
> Move functions required for early FDT parsing from device_tree.h and arm's
> setup.h onto bootfdt.h
> 
> Declaration motion only. Not a functional change.
> 
> Signed-off-by: Alejandro Vallejo 
> ---
> v3:
>   * Avoid mutations during code motion
> ---
>  xen/include/xen/bootfdt.h     | 62 +++++++++++++++++++++++++++++++++++
>  xen/include/xen/device_tree.h | 40 +---------------------
>  2 files changed, 63 insertions(+), 39 deletions(-)
> 
> diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
> index 8ea52290b7..b6ae7d6aa6 100644
> --- a/xen/include/xen/bootfdt.h
> +++ b/xen/include/xen/bootfdt.h
> @@ -2,6 +2,7 @@
>  #ifndef XEN_BOOTFDT_H
>  #define XEN_BOOTFDT_H
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -16,8 +17,53 @@
>  #define NR_MEM_BANKS 256
>  #define NR_SHMEM_BANKS 32
>  
> +/* Default #address and #size cells */
> +#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
> +#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
> +
>  #define MAX_MODULES 32 /* Current maximum useful modules */
>  
> +#define DEVICE_TREE_MAX_DEPTH 16
> +
> +/* Helper to read a big number; size is in cells (not bytes) */
> +static inline u64 dt_read_number(const __be32 *cell, int size)
> +{
> +    u64 r = 0;
> +
> +    while ( size-- )
> +        r = (r << 32) | be32_to_cpu(*(cell++));
> +    return r;
> +}
> +
> +static inline u64 dt_next_cell(int s, const __be32 **cellp)
> +{
> +    const __be32 *p = *cellp;
> +
> +    *cellp = p + s;
> +    return dt_read_number(p, s);
> +}
> +
> +typedef int (*device_tree_node_func)(const void *fdt,
> +                                     int node, const char *name, int depth,
> +                                     u32 address_cells, u32 size_cells,
> +                                     void *data);
> +
> +/**
> + * device_tree_for_each_node - iterate over all device tree sub-nodes
> + * @fdt: flat device tree.
> + * @node: parent node to start the search from
> + * @func: function to call for each sub-node.
> + * @data: data to pass to @func.
> + *
> + * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
> + *
> + * Returns 0 if all nodes were iterated over successfully.  If @func
> + * returns a value different from 0, that value is returned immediately.
> + */
> +int device_tree_for_each_node(const void *fdt, int node,
> +                              device_tree_node_func func,
> +                              void *data);
> +
>  typedef enum {
>      BOOTMOD_XEN,
>      BOOTMOD_FDT,
> @@ -260,4 +306,20 @@ static inline struct membanks *membanks_xzalloc(unsigned int nr,
>      return banks;
>  }
>  
> +/*
> + * Interpret the property `prop_name` of `node` as a u32.
> + *
> + * Returns the property value on success; otherwise returns `dflt`.
> + */
> +u32 device_tree_get_u32(const void *fdt, int node,
> +                        const char *prop_name, u32 dflt);
> +
> +/*
> + * Interpret the property `prop_name` of `node` as a "reg".
> + *
> + * Returns outputs in `start` and `size`.
> + */
> +void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
> +                         uint32_t size_cells, paddr_t *start, paddr_t *size);
> +
>  #endif /* XEN_BOOTFDT_H */
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> index 75017e4266..0a22b1ba1d 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -10,6 +10,7 @@
>  #ifndef __XEN_DEVICE_TREE_H__
>  #define __XEN_DEVICE_TREE_H__
>  
> +#include 
>  #include 

This should not be needed?


>  #include 
> @@ -22,8 +23,6 @@
>  #include 
>  #include 
>  
> -#define DEVICE_TREE_MAX_DEPTH 16
> -
>  /*
>   * Struct used for matching a device
>   */
> @@ -164,17 +163,8 @@ struct dt_raw_irq {
>      u32 specifier[DT_MAX_IRQ_SPEC];
>  };
>  
> -typedef int (*device_tree_node_func)(const void *fdt,
> -                                     int node, const char *name, int depth,
> -                                     u32 address_cells, u32 size_cells,
> -                                     void *data);
> -
>  extern const void *device_tree_flattened;
>  
> -int device_tree_for_each_node(const void *fdt, int node,
> -                              device_tree_node_func func,
> -                              void *data);
> -
>  /**
>   * dt_unflatten_host_device_tree - Unflatten the host device tree
>   *
> @@ -245,10 +235,6 @@ void intc_dt_preinit(void);
>  #define dt_node_cmp(s1, s2) strcasecmp((s1), (s2))
>  #define dt_compat_cmp(s1, s2) strcasecmp((s1), (s2))
>  
> -/* Default #address and #size cells */
> -#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
> -#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
> -
>  #define dt_for_each_property_node(dn, pp)                   \
>      for ( pp = (dn)->properties; (pp) != NULL; pp = (pp)->next )
>  
> @@ -258,16 +244,6 @@ void intc_dt_preinit(void);
>  #define dt_for_each_child_node(dt, dn)                      \
>      for ( dn = (dt)->child; (dn) != NULL; dn = (dn)->sibling )
>  
> -/* Helper to read a big number; size is in cells (not bytes) */
> -static inline u64 dt_read_number(const __be32 *cell, int size)
> -{
> -    u64 r = 0;
> -
> -    while ( size-- )
> -        r = (r << 32) | be32_to_cpu(*(cell++));
> -    return r;
> -}
> -
>  /* Wrapper for dt_read_number() to return paddr_t (instead of uint64_t) */
>  static inline paddr_t dt_read_paddr(const __be32 *cell, int size)
>  {
> @@ -307,14 +283,6 @@ static inline int dt_size_to_cells(int bytes)
>      return (bytes / sizeof(u32));
>  }
>  
> -static inline u64 dt_next_cell(int s, const __be32 **cellp)
> -{
> -    const __be32 *p = *cellp;
> -
> -    *cellp = p + s;
> -    return dt_read_number(p, s);
> -}
> -
>  static inline const char *dt_node_full_name(const struct dt_device_node *np)
>  {
>      return (np && np->full_name) ? np->full_name : "";
> @@ -949,12 +917,6 @@ int dt_get_pci_domain_nr(struct dt_device_node *node);
>  
>  struct dt_device_node *dt_find_node_by_phandle(dt_phandle handle);
>  
> -void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
> -                         uint32_t size_cells, paddr_t *start, paddr_t *size);
> -
> -u32 device_tree_get_u32(const void *fdt, int node,
> -                        const char *prop_name, u32 dflt);
> -
>  #ifdef CONFIG_DEVICE_TREE_DEBUG
>  #define dt_dprintk(fmt, args...)  \
>      printk(XENLOG_DEBUG fmt, ## args)
> -- 
> 2.43.0
> 


From xen-devel-bounces@lists.xenproject.org Sat Jun 14 01:22:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jun 2025 01:22:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1015172.1393104 (Exim 4.92)
	(envelope-from )
	id 1uQFb7-0002yy-Rg; Sat, 14 Jun 2025 01:22:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1015172.1393104; Sat, 14 Jun 2025 01:22:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uQFb7-0002yr-OZ; Sat, 14 Jun 2025 01:22:17 +0000
Received: by outflank-mailman (input) for mailman id 1015172;
 Sat, 14 Jun 2025 01:22: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 1uQFb6-0002yl-U6
 for xen-devel@lists.xenproject.org; Sat, 14 Jun 2025 01:22:16 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org
 [2600:3c04:e001:324:0:1991:8:25])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fecf4ea0-48bd-11f0-b894-0df219b8e170;
 Sat, 14 Jun 2025 03:22:11 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 3992A629D4;
 Sat, 14 Jun 2025 01:22:10 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id D30BEC4CEE3;
 Sat, 14 Jun 2025 01:22:07 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fecf4ea0-48bd-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749864129;
	bh=nUVkCqf6pPRl03XJKF7KcVSRFSRbzWCyA1ncvVL4YmQ=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=YYcTKphWxZ/gS6kYobY020YRWNhR97/6ZuKGj0nTPM6SHSYuf5RKmwYpO4cic451N
	 qXoJzSmFGDJ1CGAoaKqmIuiP1Fr6CEuNCLWCOuYqVGOaldCH/xB/uFXXW8whh5g1ZX
	 nBcoTWQVm9zRqfaJI+A31QvPXgk1gWPeZLiKdWpmhOjxSSAGSzBParIw+jCSld48DB
	 ipKwk6hrd35z9pw6I9q3XdMpENmxeuM7VwdjWUXFu8gqHoKTd2Sswp6Co5iFNpZxkN
	 AhhdHUytWO0FJdhfi64nTjftIrR25WSKUe0SGvFwKYgKrVlv9AkFM3iNgY6cCtWDgt
	 J1bHGIYwrieiA==
Date: Fri, 13 Jun 2025 18:22:06 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    Andrew Cooper , 
    Anthony PERARD , 
    Jan Beulich , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Alistair Francis , 
    Bob Eshleman , 
    Connor Davis , 
    Oleksii Kurochko , 
    "Daniel P. Smith" 
Subject: Re: [PATCH v3 09/14] xen/dt: Move bootinfo functions to a new
 bootinfo.h
In-Reply-To: <20250613151612.754222-10-agarciav@amd.com>
Message-ID: 
References: <20250613151612.754222-1-agarciav@amd.com> <20250613151612.754222-10-agarciav@amd.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 Jun 2025, Alejandro Vallejo wrote:
> Part of an unpicking process to extract bootfdt contents independent of
> bootinfo to a separate file for x86 to take.
> 
> With this, bootfdt.h can be cleanly included from x86. A later patch
> extracts the definitions so the functions may be called too.
> 
> Not a functional change.
> 
> Signed-off-by: Alejandro Vallejo 

Reviewed-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Sat Jun 14 01:24:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jun 2025 01:24:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1015178.1393115 (Exim 4.92)
	(envelope-from )
	id 1uQFdC-0003W6-79; Sat, 14 Jun 2025 01:24:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1015178.1393115; Sat, 14 Jun 2025 01: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 1uQFdC-0003Vz-3U; Sat, 14 Jun 2025 01:24:26 +0000
Received: by outflank-mailman (input) for mailman id 1015178;
 Sat, 14 Jun 2025 01:24: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 1uQFdA-0003Vr-KF
 for xen-devel@lists.xenproject.org; Sat, 14 Jun 2025 01:24:24 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4c1d244f-48be-11f0-a309-13f23c93f187;
 Sat, 14 Jun 2025 03:24:21 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 1102C44910;
 Sat, 14 Jun 2025 01:24:20 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0E046C4CEE3;
 Sat, 14 Jun 2025 01:24: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: 4c1d244f-48be-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749864259;
	bh=7EdCI3syDbkpz8P45yBlM0QHGsxgwkRydgYwWknMJOY=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=sQirh3NYV/jqsqGjzqKEFqQzeLZznHNpTwmzv8l2GFnEjz1yVxPJcsQPFojIuUUQx
	 6B3wi0dz1lTGo0rBhmAPcL8vAZVwkooMnJMtqgLiSzNqW01D1alcNnKdWG8dryJVah
	 6RG3FvE7OjZ0IvVa7zMGF/a5QM2Ux2WyObtuHt1f8Or0J+7l1KqwAPZYi4i25Fgf7k
	 m+i6RmgdTyoOAX+iVXHbTTE+QsHBk9vENdkWN+z4+IXj/utUZYjU5HhbH/1wzQw9QN
	 /NUcSKbNDLE5bhm2Ke2bxM3dszOFBho80DdQPkxAYgbzNuDW28Tde6e/hno7TdAIz1
	 fMNrH/aLFBIYA==
Date: Fri, 13 Jun 2025 18:24:17 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    "Daniel P. Smith" 
Subject: Re: [PATCH v3 12/14] xen/dt: ifdef out DEV_DT-related bits from
 device_tree.{c,h}
In-Reply-To: <20250613151612.754222-13-agarciav@amd.com>
Message-ID: 
References: <20250613151612.754222-1-agarciav@amd.com> <20250613151612.754222-13-agarciav@amd.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 Jun 2025, Alejandro Vallejo wrote:
> ... which means, device-tree.c stops requiring strictly CONFIG_HAS_DEVICE_TREE
> and may function without it.
> 
> Not a functional change on architectures that currently use these files,
> as they already select CONFIG_HAS_DEVICE_TREE.
> 
> Signed-off-by: Alejandro Vallejo 

Reviewed-by: Stefano Stabellini 



From xen-devel-bounces@lists.xenproject.org Sat Jun 14 01:25:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jun 2025 01:25:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1015184.1393125 (Exim 4.92)
	(envelope-from )
	id 1uQFe7-000411-En; Sat, 14 Jun 2025 01:25:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1015184.1393125; Sat, 14 Jun 2025 01:25: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 1uQFe7-00040u-C4; Sat, 14 Jun 2025 01:25:23 +0000
Received: by outflank-mailman (input) for mailman id 1015184;
 Sat, 14 Jun 2025 01:25: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 1uQFe6-0003Vr-2d
 for xen-devel@lists.xenproject.org; Sat, 14 Jun 2025 01:25:22 +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 6eb9425b-48be-11f0-a309-13f23c93f187;
 Sat, 14 Jun 2025 03:25:19 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 6630CA50F91;
 Sat, 14 Jun 2025 01:25:18 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id B8522C4CEE3;
 Sat, 14 Jun 2025 01:25: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: 6eb9425b-48be-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749864318;
	bh=L8EhTOB7UxYfD4FL4DSbA53OV7AVMq2H6kN5vh0F/U0=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=PEAwlUrF6Mn9IApkuimshR/7wzzYKYF8S141V5Y9TBwXcBlVjy1zBkTyx3qgStMR3
	 rbY3CdPYuvfq6Cpmhu87FM18PKvouS/Uo8LoHn+54uleecuoMJ/i5usH6+mw4VAOS2
	 g1hHkQqzJ5RBZT4XKmNFcb9IHsaIWn2RSVAxrllZ9NRIUhyMJAIdLHIpePhuc9baTP
	 Dbnc+7+gu5cRW29bC6izSw2+RlzSD/nZafqT0wcWj4oNMCoSVj6oAjPGsa5DzAtKYj
	 GSVD4CkTaccZtfoOBRUcAykxaaQMhxZF6TizY98j2nMECmVWnc3ca6Q6ZnjdPZsE/W
	 BnOzEGTYHfRFg==
Date: Fri, 13 Jun 2025 18:25:15 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
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 , 
    Bertrand Marquis , 
    "Daniel P. Smith" 
Subject: Re: [PATCH v3 13/14] xen/dt: Allow CONFIG_DOM0LESS_BOOT to include
 device-tree/
In-Reply-To: <20250613151612.754222-14-agarciav@amd.com>
Message-ID: 
References: <20250613151612.754222-1-agarciav@amd.com> <20250613151612.754222-14-agarciav@amd.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 Jun 2025, Alejandro Vallejo wrote:
> ... without CONFIG_HAS_DEVICE_TREE
> 
> Signed-off-by: Alejandro Vallejo 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/common/Kconfig              | 1 +
>  xen/common/Makefile             | 2 +-
>  xen/common/device-tree/Makefile | 8 ++++----
>  3 files changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index 867710134a..2baa4221fd 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -14,6 +14,7 @@ config CORE_PARKING
>  
>  config DOM0LESS_BOOT
>  	bool "Dom0less boot support" if EXPERT
> +	select LIBFDT
>  	depends on HAS_DOM0LESS && HAS_DEVICE_TREE && DOMAIN_BUILD_HELPERS
>  	default y
>  	help
> diff --git a/xen/common/Makefile b/xen/common/Makefile
> index 98f0873056..2717c81f9c 100644
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -8,7 +8,7 @@ obj-y += cpu.o
>  obj-$(CONFIG_DEBUG_TRACE) += debugtrace.o
>  obj-$(CONFIG_HAS_DEVICE_TREE) += device.o
>  obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) += device.o
> -obj-$(CONFIG_HAS_DEVICE_TREE) += device-tree/
> +obj-$(firstword $(CONFIG_HAS_DEVICE_TREE) $(CONFIG_DOM0LESS_BOOT)) += device-tree/
>  obj-$(CONFIG_IOREQ_SERVER) += dm.o
>  obj-y += domain.o
>  obj-y += event_2l.o
> diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
> index 8abc069c4b..cc56f42df9 100644
> --- a/xen/common/device-tree/Makefile
> +++ b/xen/common/device-tree/Makefile
> @@ -1,11 +1,11 @@
>  obj-y += bootfdt.init.o
> -obj-y += bootinfo-fdt.init.o
> -obj-y += bootinfo.init.o
> -obj-y += device-tree.o
> +obj-$(CONFIG_HAS_DEVICE_TREE) += bootinfo-fdt.init.o
> +obj-$(CONFIG_HAS_DEVICE_TREE) += bootinfo.init.o
> +obj-$(CONFIG_HAS_DEVICE_TREE) += device-tree.o
>  obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.init.o
>  obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.init.o
>  obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o
> -obj-y += intc.o
> +obj-$(CONFIG_HAS_DEVICE_TREE) += intc.o
>  obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o
>  obj-$(CONFIG_STATIC_EVTCHN) += static-evtchn.init.o
>  obj-$(CONFIG_STATIC_MEMORY) += static-memory.init.o
> -- 
> 2.43.0
> 


From xen-devel-bounces@lists.xenproject.org Sat Jun 14 01:26:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jun 2025 01:26:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1015190.1393134 (Exim 4.92)
	(envelope-from )
	id 1uQFf2-0004Wh-NF; Sat, 14 Jun 2025 01:26:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1015190.1393134; Sat, 14 Jun 2025 01:26:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uQFf2-0004Wa-Kj; Sat, 14 Jun 2025 01:26:20 +0000
Received: by outflank-mailman (input) for mailman id 1015190;
 Sat, 14 Jun 2025 01:26: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 1uQFf2-0004WU-C9
 for xen-devel@lists.xenproject.org; Sat, 14 Jun 2025 01:26:20 +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 91b43dd0-48be-11f0-b894-0df219b8e170;
 Sat, 14 Jun 2025 03:26:18 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 267105C620E;
 Sat, 14 Jun 2025 01:24:00 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 30109C4CEE3;
 Sat, 14 Jun 2025 01:26: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: 91b43dd0-48be-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1749864376;
	bh=MKIhEtMQdkKqHIH25eJWd6I2t6EYo+tKXtUNq6Kc7Ds=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=tPniVEx0o/afz5gx+b701rIAkLnkck4301HRZC5M3bvzBwS/qrdc2q6+i7HQzn2zz
	 tmYxOrgOe4STknq2i+FcsUtlcq9huO5xN3KaErrUqWXAJGWl05g1JXrRddgAj7OHW5
	 2hmHCJ/kj8uyHXni75gViVeIwNO3bFD2iHJe3Vh2VEAHb/W8warLFfR/nKjZL6uOdI
	 ABMFisGsTpto1Z2Ph9yuqVXwEbgW74bpQYYKDiixOVkkQ1WjDrU6CA4xlz4HYAK8/e
	 fSfF+Kh/fDwJwlsdmXDlSenlGZtoVcpkJCN8R4M0JstSYUDwibMpyY3+o+mz8m7wRX
	 WGeOX5h5duj8g==
Date: Fri, 13 Jun 2025 18:26:14 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: xen-devel@lists.xenproject.org, Jan Beulich , 
    Andrew Cooper , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Anthony PERARD , 
    Michal Orzel , Julien Grall , 
    Stefano Stabellini , 
    Bertrand Marquis , 
    "Daniel P. Smith" 
Subject: Re: [PATCH v3 14/14] kconfig: Allow x86 to pick
 CONFIG_DOM0LESS_BOOT
In-Reply-To: <20250613151612.754222-15-agarciav@amd.com>
Message-ID: 
References: <20250613151612.754222-1-agarciav@amd.com> <20250613151612.754222-15-agarciav@amd.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 Jun 2025, Alejandro Vallejo wrote:
> Without picking CONFIG_HAS_DEVICE_TREE.
> 
> In order to do that. Allow CONFIG_DOM0LESS_BOOT to enable a subset
> of the common/device-tree/ directory. x86 doesn't want dom0less-build.c,
> as that's tightly integrated still to the ARM way of building domains.
> 
> Requires "unsupported" for the time being until all required patches
> make it through.
> 
> Signed-off-by: Alejandro Vallejo 

Reviewed-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Sat Jun 14 14:20:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jun 2025 14:20:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1015539.1393155 (Exim 4.92)
	(envelope-from )
	id 1uQRkW-0000YV-KQ; Sat, 14 Jun 2025 14:20:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1015539.1393155; Sat, 14 Jun 2025 14:20: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 1uQRkW-0000YM-GZ; Sat, 14 Jun 2025 14:20:48 +0000
Received: by outflank-mailman (input) for mailman id 1015539;
 Sat, 14 Jun 2025 14:20: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 1uQRkV-0000Xn-4t
 for xen-devel@lists.xenproject.org; Sat, 14 Jun 2025 14:20:47 +0000
Received: from AS8PR04CU009.outbound.protection.outlook.com
 (mail-westeuropeazlp170110003.outbound.protection.outlook.com
 [2a01:111:f403:c201::3])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c1d5af5d-492a-11f0-b894-0df219b8e170;
 Sat, 14 Jun 2025 16:20:44 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by GV1PR03MB8815.eurprd03.prod.outlook.com (2603:10a6:150:a1::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.25; Sat, 14 Jun
 2025 14:20:41 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%4]) with mapi id 15.20.8835.023; Sat, 14 Jun 2025
 14: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: c1d5af5d-492a-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=gvtAVj8ngVqJwPSyrfIJ+UvxegNA7s5nXJTGE5WhRO16861KERDzGTLyQcMuF/Ff/VbvKX9l3QXkRrZvese7ylZe8zktNkhCvLBzTkch5ixw5DkmPt/3fixL9yTZ+84FNrwFXi7+DAf25T6a9Z6X6ssrxjYm9FTi2ORANgFrxMFJ9dlqpt6mgxdok4N5sh5a4kf1zilAFeBZxFZ7ZvMgCrRZ2fSq6udVezbEKh5KEwa8cEER0YvEsNJmkAMCcGUiKnH26P6JccR72iDhA1e9MauGwXukPQKij1ksOAjwEfrBGrByvxt1Cu7D+R5o6sbkemsHfwer9FQPHC7msIjwvQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=610YW1FMZpiWpwnXWazvhuYEOfwA1T1X0AqhtLpOb2M=;
 b=w2Gtv3rdjXn+Ap3oMshfeeVVlrXhraqfigHF1nOAVC8IYoL6yKGjkJqLjwH1kD229Y/1hM3qx4Czrxin0f/GBJaoK/YnHo+px+BzhLSPAohohJhcbfftZPBi5s1JD2hfF+2vmDWuh2EGm1xFqfn4LqrnGuQTLNbG5lzBbuK5Me6bqm89Ea4JSdrXdFKacVLa2EjsxHMMRfi/HHhL7YwkBuORx+aceeqGe5LVq9p6twNPBe1YXrjFq2ekMYCixabsLOny7rvTWjm7PyXoB/UA8Ladk6569fGDbxvD9lpwsDHzlzP/C7AgtNgmm0T9oZ76wPlmK7wYF7OTX0MOcdhwBA==
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=610YW1FMZpiWpwnXWazvhuYEOfwA1T1X0AqhtLpOb2M=;
 b=MyWHoE6I7dPEZ+BGpDWZrqeyjVuVwzJnEYxZnZBzxeMbXpEFObMUKtzOPIVQI5Cc6tBi+G5t5cxrOXFkFhvPksZwSSKlecOwLfFfRkvnrKRRG6eN3P2lC6nCaAOxoCJyGik+MVk1XpxgsvNi2PseHn4QxlceORTEfGasoaJ5Q1c303vGEToBKmNFlGPdzUAFGEjiLliVUTpiaiAzpZABO4wJjCp383y6rImyDyj/WZgRHkB8hEQ7Fz8UAhTkm9gHdb8M42bTlzvTbXONh3pfYPQMigI0Oa00G3PBto4eP0zRzG9+/01MBL9zpVQJc1NRo7/Y25aaogRQAPOgfvgE8w==
From: Oleksii Moisieiev 
To: Oleksii Kurochko ,
	"xen-devel@lists.xenproject.org" 
CC: Ayan Kumar Halder , Mykyta Poturai
	, Juergen Gross , Teddy Astie
	, Bertrand Marquis , Luca
 Fancellu , Jason Andryuk ,
	Alejandro Vallejo , Sergii Dmytruk
	, Penny Zheng ,
	=?utf-8?B?TWFyZWsgTWFyY3p5a293c2tpLUfDs3JlY2tp?=
	, Roger Pau Monne ,
	Andrew Cooper , "dmkhn@proton.me"
	, Mykola Kvach , "Daniel P. Smith"
	, Grygorii Strashko ,
	Alejandro Vallejo , "committers@xenproject.org"
	, Community Manager
	
Subject: Re: Xen 4.21 Development Update [May]
Thread-Topic: Xen 4.21 Development Update [May]
Thread-Index: AQHb3TeBjze4CyxPok6FyLun6n8+8w==
Date: Sat, 14 Jun 2025 14:20:41 +0000
Message-ID: <020e4695-0335-4565-b9f9-955d94a6efb1@epam.com>
References: <7364a71d-2604-49ca-bab7-d21544d49b10@gmail.com>
In-Reply-To: <7364a71d-2604-49ca-bab7-d21544d49b10@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB8946:EE_|GV1PR03MB8815:EE_
x-ms-office365-filtering-correlation-id: dc3df3d6-6a16-4adb-6a56-08ddab4ea4c1
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|366016|7416014|376014|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?QWdDQ0YyU3hSbGgzUFJHbFpiak05U2FXOWJnZ0YxVldYN09wSXNDVUM0OTFF?=
 =?utf-8?B?endPaS9TaVRPNVhPcjBuWjhMLzhudzJMS1VQcEliOHpBWWZ4M0FrSi9JMERi?=
 =?utf-8?B?cWRKSndudE9OTmtQNFVxNG1NQnVGZlM2RGx0dEh0aFcydHFKYThwRTZpOGdK?=
 =?utf-8?B?cC9xNmUvNzFqQUk4RTkxdVpzU2VHVUVFaVRYcW9ndGcxcmRFSVlaVjNPY2E4?=
 =?utf-8?B?TS9WRnNYWW42QUJnN3A2aXZNZmgycHNQbWJIRnRwTjBKUXJyQm1sRC8yRWh3?=
 =?utf-8?B?UkEydHh1ajJ1QTNXN3hyeVF6TlFiM2ZMUlIzRjBTc0RsNGRrdDR2MC9IR0ls?=
 =?utf-8?B?ZnJVYzhkSFNudVIyWjJRbjhCayt1cWZWOWVMazk1NUxISy9QZzFLM0V2QVdC?=
 =?utf-8?B?ZVk1UXNwNEEvSzJwcWpUZlZHakg3RGtyNU05Vk90NEo5NnJabysvOURiQUQ5?=
 =?utf-8?B?d3pIMldWNkZ0UTI2OU9TRHFsbUc5Rm9BWkpDUzFiSFNPM2lKWVAxZ1JOSnh4?=
 =?utf-8?B?ZmtGck9ndjhtTDg1UUhLSXdndXh0am5rUkE4cGxCNzVsUjFldmIya2MvcHlX?=
 =?utf-8?B?QnNnZnVkYlZlNmcxQ3o5aC9PaUxMWHBOTDJ2L3I4SldpN3Y4REFTL1dERnhS?=
 =?utf-8?B?RHRoOXdEbklHWTdVT3l1akJSSmk0SjZ4LzhXK2liZVd1Nmp0bWVzeWhPZ2FZ?=
 =?utf-8?B?WEhkcHZKMm1FYXA2WnVoMXl1TDhCY2lTcGdIKzNTVHB1bHVUcFdDWHl4dDk3?=
 =?utf-8?B?eTF4VFhhdmxTZlF5VTRzZGgwUGpVQnBQV1VUMGxnMVNDNGVPcHJzeEtoNzU2?=
 =?utf-8?B?V2ZZTTdzVEJJc1pIUk1JQnJQbGFZdUs3WjNUUk4zbGM5MzhxZ0hlS0JwUVpG?=
 =?utf-8?B?NWkvVis2YjRMYU5zYTkyYzFSRm1uaEVqTDhyT1JudEFkdm1ZcUR5YXpjVWVJ?=
 =?utf-8?B?Y2dLK1FSdnJlZS8vakk1dkNXNUVEM1NEVVBsMWZvNCtMbTVxb3EyMEVRN1ZR?=
 =?utf-8?B?ZmVCbEpBR2pmN1VuKzdsSTZhV3pEUUE5TElhbVVKWExRUmx1dXI4RjNFcGMy?=
 =?utf-8?B?RFN2b1NmR3FzV05sYkhuS0JmSFVzK2VaQmpQVmtGUzNabksyT3NsQnVtcHhK?=
 =?utf-8?B?OS9NejIxNlpqR04rakdmNVhGT2c0aitXTGNtQ3hJc0FEMkxya3dIdkhueEdj?=
 =?utf-8?B?TEswcnlhb2ZiUjhpQ1ZSSnhoVEdZeVorOTVUaGp3ZWF1aElscFJYRjFKWVRI?=
 =?utf-8?B?NDdOMTZrYysvMDJiR08wZWlLTFJJMUMzM3hFdU8wc1dqQzBRVWx6UlAzc01M?=
 =?utf-8?B?UjdnT2tBU3pMSUVjMHo0RjF5QlFkcXFBWjRicDRWU0hSNVN4V1RrS0x6ZW1l?=
 =?utf-8?B?TTl5WnNFNUxoQktHeVJpaExNRmlVOFFyYVZydTBVSnRtc3lKSzYybmNpc3dN?=
 =?utf-8?B?ekIzK0E4UEw4Ylk2ZDRwaHhwVzRGbVd5bWpSamxTQmJhb2F0aDk3ekRIZisy?=
 =?utf-8?B?eWhDSHFnVG9TRGZNNGZCMTlIa3Y3bzB4V1YyazRPTk5EK1dySHZyQ1BYb0pE?=
 =?utf-8?B?VWl1dHRFQ0tmZ21Sc0NFYXFoOENPVGdmYU52MTN2Nzc2K1VLa3JVR1IwM0hN?=
 =?utf-8?B?aEpobmpPLzJ0Q1lCd2hGK2Q2cmcrUFhTYzhhaC82N09WSFhiaGpNU1RRbC9j?=
 =?utf-8?B?L2wzUGFxWE5vbjlRY0swVWdKV1FZcVhpM3dTRzJWVkFtUlhpK3puZVRaMEIv?=
 =?utf-8?B?dDBYcGYydnVReSt3T3VPZlA0Lzg4V0Q3RWNqRnI5cnlFVWEzeHJXZ0N3S24x?=
 =?utf-8?B?WHd0WDd5dTRsM3NJRFJSdW5LZ2lUZnRUMWplTG90cXFRMllMWlJqU0QvaG9J?=
 =?utf-8?B?eWE3a2x1ejlSRmlpUHVOR29sMmo2RzNvRlFsWElQUlg2L0xjV2FnZEd2M0Mr?=
 =?utf-8?Q?dpFxdoXW4C4=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(7416014)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?MkhxZEFtaGFlcTNNaS9jdmg3ZXo4UGxhNEFxZitIQXYrZWFkN24yZkduTVdo?=
 =?utf-8?B?V1VpL1dTcTc4VHVTVnBGdFRJTXRicmlDSjZLSmJuSzc0TlZDL3M1Vm0vOXZ2?=
 =?utf-8?B?L2Izc2FqTk1zMS9iTyttMTRZUDErMytRc2tJeTg5T3NvWXVYSWdENUMyVmRP?=
 =?utf-8?B?WE4xenRUZEt3ZDFQUWFXTUNUS3JkZWJZUElacTRwS2RYQVVhd21QUEFkWHRN?=
 =?utf-8?B?aU03NXM2NnBwOCtoVjdzMkEyWW40OG5pZ3NWOEZ6VmRrZ0tORkQxTDR6cER5?=
 =?utf-8?B?QW9Ya2lTNGtyaXlVMlJ2Y2J3cG4vbnJFWU43YkZnNkRER1MvcjhIclIxNW5q?=
 =?utf-8?B?eFltdHFmazNaY2Y2WmxpTU1FMU1Pc0dxUnFIY0VWbTNSc01ObjRDTTUrUFZq?=
 =?utf-8?B?Z2RjcU5xR3UrRkFKbnVvS0Q5ajVWOTJrM0dSdFFsRUk0bmFnbUswSHZvUVRP?=
 =?utf-8?B?M0RUa3YyNzVUYWRyWXJ3RTdNYnAyT05nNFc1K1g3RUlsbUg2eTlVa0t3cDln?=
 =?utf-8?B?WmlOU21laXFGN3pqaFhzREFZcnl6VENBbGp4SmcrMitxbG83WUhnQU9jZitE?=
 =?utf-8?B?UUtzMVBReUFLTXZrM3laRmpYVllnL3puS3cxUXhrT3dWYURDNGs3SzIxNndk?=
 =?utf-8?B?VVk3MTdGazJFYmRscmh1TWVlRWhIQ093QUZ1YjVsRUpEQ0ZKazc0L21pWnFk?=
 =?utf-8?B?NnFVUi9LVGtLTzlXa0ZJMVRuOGg4bVpFS3ZFdFplVDBrSklzOVNHQXUvSHFP?=
 =?utf-8?B?eGl0OGh6S3o3ai93T2I1Sk9ocmVuNHcwb3I1bzBDOGZESnRjTHB3SmRjUnkw?=
 =?utf-8?B?SDdLY1ViVlhtNVdzNjVMTGxqaE9OOHNFRGVDVTRneXJZMVVlVkZLQjNqc0lD?=
 =?utf-8?B?Z2FISFNPWWNYSysrOTFnRlZ4aVFEcVBVUTlyV2NRcG02OGdaQ055ZzQ5ZlBp?=
 =?utf-8?B?aThKUW9RemVEdVdORFhseHk3bUptd1lVWnN5Y014NlljbnlBY0tBMHhnUVNp?=
 =?utf-8?B?S3h6Z2hsaEJZL0NObzhKdnJpZ1NvbWJUajk0U0FQZEZvVmhRdWcvTGJlUCto?=
 =?utf-8?B?WlRrYXpBU1graVk5M283Y0IvY3ExRU1obmhQYWMreUZ6eWZXYWpsQmlhYTcx?=
 =?utf-8?B?b3ZVV2FpenMvcWgwSkhidmhXaFJHZVg0cTZNL0NUK1N0K1VOYm5jTVFkNkNM?=
 =?utf-8?B?WCtRVDd6RnJKelRTRkxaeHZXM3BEcXNSWGo1Wkw2OUI5TDlBZUI4UDhUbHdL?=
 =?utf-8?B?SWxaTnFTaEpmQ0IxZEltYklDMXVyQXhmZHJJckw4TU0rQ2xGMHZjR04wSUcr?=
 =?utf-8?B?cU1zQ3pJaEQ5Y3dFcXFxTmp1T1pFQlkzL29kZHRrZHo2cVZUcXl3d2IvK09o?=
 =?utf-8?B?WGNGVWRHRCthNVhrN2RMT2xUbEQvVTRBc3pqNVZ0cEdLTjkyT1RXYkhIckE1?=
 =?utf-8?B?M2JSL3JFMUJyMmRRV1JqQ216bmhqS3JKc3YvcExzdjdaQVBoTEd3ZE5tTnVB?=
 =?utf-8?B?ZURucTEvS0M1MkphMVJXbnR6R3REZUk4RGJjS1NXQnUvUDJjSG5kYWYzU1lX?=
 =?utf-8?B?VG5oSnNoZGtWNkhYZ0dHNjVVbUtneGdwWUZpbFRiNjhvMWc0SGFIS3dEeDh3?=
 =?utf-8?B?NkQ3b2hsQ3BCcW1sbTJRTDkvdjZja29xaDBtMGpSVmlBSk1abTFicEg1TXBD?=
 =?utf-8?B?NHhMTTFvMVY0bGlJdjRyN0ZCNGR4eFE0MU1qZWZuQVlrSUNSN0o0UDNIWVBi?=
 =?utf-8?B?WEtBYUpIZjhEYlhjQUJzdUVzWmpWQkZtazY0RGhnTWtKamVwSmhOUERGbmJH?=
 =?utf-8?B?WjZsd29GUU4wQWJPNm5Xc2Q1TDh1ajBhN0Z3Zi8wcTlYZ3pzSzNWYktUWC82?=
 =?utf-8?B?RFJ4dG1rOVlNWkZId0lkUklPaFgyT3hVOHBBUXUwVXdMSUdRanBVV0V6N3ZY?=
 =?utf-8?B?ZGU4OXE0TDVqdGx3N2U1S2Z0WHNjNWtDb2VPWnhERzR3bTcraEJpZHJ1RUhx?=
 =?utf-8?B?ZDFjRjZzb1d0VDJaK1hhU3hjaXN6bmNJWEdPWEVacGYzT0doTEVyY1ROYTFy?=
 =?utf-8?B?aVRqQ1B3VnplZ3RtSE1lMUh5ZFR2NjZpUXhlNzEwSjFtMnlqNHpwa2YzdGZy?=
 =?utf-8?B?NjE3VmU5WHZPdWlzQkNPbmhzN3ZNcXZMUjRtekpRUUFUbFNUZTN0NEhhelpn?=
 =?utf-8?B?Z0E9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dc3df3d6-6a16-4adb-6a56-08ddab4ea4c1
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2025 14:20:41.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: q9j7H7x+eYHZHmkcRgLdds40TZ7UbPqe3E9r+quicRTFZdLmcd03kvbInDPxI5cOz8FBW4A8HFiex7lI89UJ30IU39L7FWRWHICLrw33X94=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR03MB8815

SGkgT2xla3NpaSwNCg0KUGxlYXNlIHNlZSBiZWxvdy4NCg0KT24gMDIvMDYvMjAyNSAxOTozNywg
T2xla3NpaSBLdXJvY2hrbyB3cm90ZToNCj4gSGVsbG8gZXZlcnlvbmUsDQo+DQo+IFRoaXMgZW1h
aWwgb25seSB0cmFja3MgYmlnIGl0ZW1zIGZvciB4ZW4uZ2l0IHRyZWUuIFBsZWFzZSByZXBseSBm
b3IgDQo+IGl0ZW1zIHlvdQ0KPiB3b3VsZCBsaWtlIHRvIHNlZSBpbiA0LjIxIHNvIHRoYXQgcGVv
cGxlIGhhdmUgYW4gaWRlYSB3aGF0IGlzIGdvaW5nIG9uIA0KPiBhbmQNCj4gcHJpb3JpdGlzZSBh
Y2NvcmRpbmdseS4NCj4NCj4gWW91J3JlIHdlbGNvbWUgdG8gcHJvdmlkZSBkZXNjcmlwdGlvbiBh
bmQgdXNlIGNhc2VzIG9mIHRoZSBmZWF0dXJlIHlvdSdyZQ0KPiB3b3JraW5nIG9uLg0KPg0KPiA9
IFRpbWVsaW5lID0NCj4NCj4gQXMgdGhlcmUgaGFzbid0IGJlZW4gYW55IGZlZWRiYWNrIG9uIHRo
ZSBwcm9wb3NlZCB0aW1lbGluZSBzaGFyZWQgaGVyZToNCj4gaHR0cHM6Ly9sb3JlLmtlcm5lbC5v
cmcveGVuLWRldmVsLzY2NmUzZjQ5LTJmOTItNDgyOC04ODk3LTg1Nzk4MzJiY2FhMkBnbWFpbC5j
b20vVC8jdSANCj4NCj4NCj4gV2UgY2FuIHByb2NlZWQgd2l0aCB0aGUgc3VnZ2VzdGVkIHRpbWVs
aW5lIGFzIHRoZSByZWxlYXNlIHNjaGVkdWxlIGZvciANCj4gWGVuIDQuMjEuDQo+IEkndmUgdXBk
YXRlZCB0aGUgWGVuIDQuMjEgUmVsZWFzZSBOb3RlcyB3aXRoIHRoaXMgc2NoZWR1bGUsIHdoaWNo
IGNhbiANCj4gbm93IGJlDQo+IGFjY2Vzc2VkIHZpYSB0aGUgUk4gbGluazoNCj4gwqAgaHR0cHM6
Ly94ZW5iaXRzLnhlbi5vcmcvZG9jcy91bnN0YWJsZS9zdXBwb3J0LW1hdHJpeC5odG1sDQo+DQo+
ID0gVXBkYXRlcyA9DQo+DQo+IFRoZSBmb2xsb3dpbmcgaXRlbXMgKCB0aGUgbGlua3MgZm9yIHRo
ZW0gY291bGQgYmUgZm91bmQgaW50IHRoZSBsaXN0IA0KPiBiZWxvdyApDQo+IHdlcmUgbW92ZWQg
dG8gY29tcGxldGVkOg0KPiDCoCBbc2luY2UgTWF5IDYgLSBKdW4yXToNCj4gwqDCoMKgICogSHlw
ZXJ2aXNvcjoNCj4gwqDCoMKgwqDCoCAtIHRvb2xzOiByZW1vdmUgcWVtdS10cmFkaXRpb25hbA0K
PiDCoMKgwqAgKiBBcm06DQo+IMKgwqDCoMKgwqAgLSBQQ0kgZGV2aWNlcyBwYXNzdGhyb3VnaCBv
biBBcm0sIHBhcnQgMw0KPiDCoMKgwqAgKiB4ODY6DQo+IMKgwqDCoMKgwqAgLSB4ZW46IGNhY2hl
IGNvbnRyb2wgaW1wcm92ZW1lbnRzDQo+IMKgIFtzaW5jZSA0LjIwIHJlbGVzZSAtIE1heSA2XToN
Cj4gwqDCoMKgICogSHlwZXJ2aXNvcjoNCj4gwqDCoMKgwqDCoCAtIE1vdmUgcGFydHMgb2YgQXJt
J3MgRG9tMGxlc3MgdG8gY29tbW9uIGNvZGUNCj4gwqDCoMKgwqDCoCAtIHJlbW92ZSBsaWJ4ZW5j
dHJsIHVzYWdlIGZyb20geGVuc3RvcmVkDQo+IMKgwqDCoCAqIEFybToNCj4gwqDCoMKgwqDCoCAt
IEVuYWJsZSBlYXJseSBib290dXAgb2YgQXJtdjgtUiBBQXJjaDMyIHN5c3RlbXMNCj4gwqDCoMKg
ICogeDg2Og0KPiDCoMKgwqDCoMKgIC0geDg2L0hWTTogZW11bGF0aW9uIChNTUlPKSBpbXByb3Zl
bWVudHMNCj4gwqDCoMKgICogUklTQy1WOg0KPiDCoMKgwqDCoMKgIC0gUklTQy1WIHNvbWUgcHJl
aW5pdCBjYWxscy4NCj4gwqDCoMKgwqDCoCAtIEZpeGVzIGZvciBVQlNBTiAmIEdDT1Ygc3VwcG9y
dCBmb3IgUklTQy1WLg0KPg0KPiBTb21lIG5ldyBpdGVtcyBhZGRlZDoNCj4gwqBbc2luY2UgTWF5
XQ0KPiDCoMKgwqAgKiB4ODY6DQo+IMKgwqDCoMKgIC0gQWxsb3cgeDg2IHRvIHVuZmxhdHRlbiBE
VHMNCj4gwqDCoMKgwqAgLSBoeXBlcmxhdW5jaDogbW92ZSByZW1haW5pbmcgcHZoIGRvbTAgY29u
c3RydWN0aW9uDQo+IMKgwqDCoMKgIC0geDg2L2h5cGVybGF1bmNoOiBpbnRyb2R1Y2UgY29uY2Vw
dCBvZiBjb3JlIGRvbWFpbnMNCj4gwqDCoMKgwqAgLSBDb25maWRlbnRpYWwgY29tcHV0aW5nIGFu
ZCBBTUQgU0VWIHN1cHBvcnQNCj4gwqDCoMKgICogQXJtOg0KPiDCoMKgwqDCoCAtIFNNTVUgaGFu
ZGxpbmcgZm9yIFBDSWUgUGFzc3Rocm91Z2ggb24gQVJNDQo+IMKgwqDCoMKgIC0geGVuL2FybTog
c2NtaTogaW50cm9kdWNlIFNDSSBTQ01JIFNNQyBtdWx0aS1hZ2VudCBzdXBwb3J0DQo+IMKgwqDC
oMKgIC0gQWRkIGluaXRpYWwgWGVuIFN1c3BlbmQtdG8tUkFNIHN1cHBvcnQgb24gQVJNNjQNCj4g
wqDCoMKgICogUklTQy1WOg0KPiDCoMKgwqDCoCAtIGludHJvZHVjZSBwMm0gZnVuY3Rpb25hbGl0
eQ0KPiDCoFtzaW5jZSA0LjIwIHJlbGVhc2VdDQo+IMKgwqDCoCAqIEh5cGVydmlzb3I6DQo+IMKg
wqDCoMKgwqAgLSB0b29sczogcmVtb3ZlIHFlbXUtdHJhZGl0aW9uYWwNCj4gwqDCoMKgwqDCoCAt
IFBoeXNpY2FsIGFkZHJlc3MgaHlwZXJjYWxsIEFCSSAoIkhWTXYyIikNCj4gwqDCoMKgwqDCoCAt
IHhlbjogVW50YW5nbGUgbW0uaA0KPiDCoMKgwqDCoMKgIC0geGVuOiBpbnRyb2R1Y2UgQ09ORklH
X1NZU0NUTA0KPiDCoMKgwqDCoMKgIC0gQWRkIHN1cHBvcnQgZm9yIGV4YWN0LW5vZGUgbWVtb3J5
IGNsYWltcw0KPiDCoMKgwqDCoMKgIC0gU2V2ZXJhbCBDSSBjbGVhbnVwcyBhbmQgaW1wcm92ZW1l
bnRzLCBwbHVzIHlldCBhbm90aGVyIG5ldyBydW5uZXINCj4gwqDCoMKgICogeDg2Og0KPiDCoMKg
wqDCoMKgIC0geDg2L0VGSTogcHJldmVudCB3cml0ZS1leGVjdXRlIHNlY3Rpb25zDQo+IMKgwqDC
oMKgwqAgLSB4ODY6IFRyZW5jaGJvb3QgU2VjdXJlIExhdW5jaCBEUlRNIChYZW4pDQo+IMKgwqDC
oMKgwqAgLSBIeXBlcmxhdW5jaCBkZXZpY2UgdHJlZSBmb3IgZG9tMCAodjYpDQo+IMKgwqDCoMKg
wqAgLSBhbWQtY3BwYyBDUFUgUGVyZm9ybWFuY2UgU2NhbGluZyBEcml2ZXIgKHY0KQ0KPiDCoMKg
wqDCoMKgIC0gSHlwZXJsYXVuY2ggZG9tYWluIGJ1aWxkZXINCj4gwqDCoMKgwqDCoCAtIGtleGVj
OiBhZGQga2V4ZWMgc3VwcG9ydCB0byBNaW5pLU9TDQo+IMKgwqDCoMKgwqAgLSB4ZW46IGNhY2hl
IGNvbnRyb2wgaW1wcm92ZW1lbnRzIChzaG91bGQgYmUgbW92ZWQgdG8gDQo+ICJIeXBlcnZpc29y
Ij8pDQo+IMKgwqDCoMKgwqAgLSB4ODY6IGdlbmVyYXRlIHhlbi5lZmkgaW1hZ2Ugd2l0aCBubyB3
cml0ZS1leGVjdXRlIHNlY3Rpb25zDQo+IMKgwqDCoMKgwqAgLSB4ODYvYXNtOiBjbGVhbnVwcyBh
ZnRlciB0b29sY2hhaW4gYmFzZWxpbmUgdXBncmFkZQ0KPiDCoMKgwqAgKiBBcm06DQo+IMKgwqDC
oMKgwqAgLSBBZGQgc3VwcG9ydCBmb3IgUi1DYXIgR2VuNCBQQ0kgaG9zdCBjb250cm9sbGVyICh2
NCkNCj4gwqDCoMKgwqDCoCAtIEZGLUEgVk0gdG8gVk0gc3VwcG9ydCAodjUpDQo+IMKgwqDCoMKg
wqAgLSBGaXJzdCBjaHVuayBmb3IgQXJtIFI4MiBhbmQgTVBVIHN1cHBvcnQgKHY0KQ0KPiDCoMKg
wqDCoMKgIC0gQVJNIHNwbGl0IGhhcmR3YXJlIGFuZCBjb250cm9sIGRvbWFpbnMgKHY1KQ0KPiDC
oMKgwqDCoMKgIC0gTVBVIG1tIHN1YnNpc3RlbSBza2VsZXRvbg0KPiDCoMKgwqAgKiBSSVNDLVY6
DQo+IMKgwqDCoMKgwqAgLSBpbnRyb2R1Y2UgYmFzaWMgVUFSVCBzdXBwb3J0IGFuZCBpbnRlcnJ1
cHRzIGZvciBoeXBlcnZpc29yIG1vZGUNCj4NCj4gKiBGdWxsIGxpc3Qgb2YgaXRlbXMgOiAqDQo+
DQo+ID0gUHJvamVjdHMgPQ0KPg0KPiA9PSBIeXBlcnZpc29yID09DQo+DQo+ICogeGVuL2NvbnNv
bGU6IGNsZWFudXAgY29uc29sZSBpbnB1dCBzd2l0Y2ggbG9naWMgKHYxIC0+IHY1KQ0KPiDCoCAt
IERlbmlzIE11a2hpbg0KPiDCoCAtIA0KPiBodHRwczovL2xvcmUua2VybmVsLm9yZy94ZW4tZGV2
ZWwvMjAyNTA1MzAyMzE4NDEuNzMzODYtMS1kbXVraGluQGZvcmQuY29tLw0KPiDCoCAtIGh0dHBz
Oi8vcGF0Y2hldy5vcmcvWGVuLzIwMjUwNTMwMjMxODQxLjczMzg2LTEtZG11a2hpbkBmb3JkLmNv
bS8NCj4NCj4gKiB4ZW46IGludHJvZHVjZSBDT05GSUdfU1lTQ1RMICh2MyAtPiB2NCkNCj4gwqAg
LcKgIFBlbm55IFpoZW5nDQo+IMKgIC0gDQo+IGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3hlbi1k
ZXZlbC8yMDI1MDUyODA5MTcwOC4zOTA3NjctMS1QZW5ueS5aaGVuZ0BhbWQuY29tLw0KPiDCoCAt
IGh0dHBzOi8vcGF0Y2hldy5vcmcvWGVuLzIwMjUwNTI4MDkxNzA4LjM5MDc2Ny0xLVBlbm55Llpo
ZW5nQGFtZC5jb20vDQo+DQo+ICogUGh5c2ljYWwgYWRkcmVzcyBoeXBlcmNhbGwgQUJJICgiSFZN
djIiKQ0KPiDCoCAtIFRlZGR5IEFzdGllDQo+IMKgIC0gDQo+IGh0dHBzOi8vbG9yZS5rZXJuZWwu
b3JnL3hlbi1kZXZlbC9jb3Zlci4xNzQ0OTgxNjU0LmdpdC50ZWRkeS5hc3RpZUB2YXRlcy50ZWNo
Lw0KPg0KPiAqIHhlbjogVW50YW5nbGUgbW0uaA0KPiDCoCAtwqAgQW5kcmV3IENvb3Blcg0KPiDC
oCAtIA0KPiBodHRwczovL2xvcmUua2VybmVsLm9yZy94ZW4tZGV2ZWwvMjAyNTAzMTIxNzQ1MTMu
NDA3NTA2Ni0xLWFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20vDQo+IMKgIC0gDQo+IGh0dHBzOi8v
cGF0Y2hldy5vcmcvWGVuLzIwMjUwMzEyMTc0NTEzLjQwNzUwNjYtMS1hbmRyZXcuY29vcGVyM0Bj
aXRyaXguY29tLw0KPg0KPiAqIEFkZCBzdXBwb3J0IGZvciBleGFjdC1ub2RlIG1lbW9yeSBjbGFp
bXMNCj4gwqAgLcKgIEFsZWphbmRybyBWYWxsZWpvDQo+IMKgIC0gDQo+IGh0dHBzOi8vbG9yZS5r
ZXJuZWwub3JnL3hlbi1kZXZlbC8yMDI1MDMxNDE3MjUwMi41MzQ5OC0xLWFsZWphbmRyby52YWxs
ZWpvQGNsb3VkLmNvbS8NCj4gwqAgLSANCj4gaHR0cHM6Ly9wYXRjaGV3Lm9yZy9YZW4vMjAyNTAz
MTQxNzI1MDIuNTM0OTgtMS1hbGVqYW5kcm8udmFsbGVqb0BjbG91ZC5jb20vDQo+DQo+ICogU2V2
ZXJhbCBDSSBjbGVhbnVwcyBhbmQgaW1wcm92ZW1lbnRzLCBwbHVzIHlldCBhbm90aGVyIG5ldyBy
dW5uZXINCj4gwqAgLSBNYXJlayBNYXJjenlrb3dza2ktR8OzcmVja2kNCj4gwqAgLSANCj4gaHR0
cHM6Ly9sb3JlLmtlcm5lbC5vcmcveGVuLWRldmVsL2NvdmVyLjdkYTE3Nzc4ODI3NzQ0ODZhMTNl
NmYzOWZmNGEyMDk2ZjZiNzkwMWUuMTc0NDAyODU0OS5naXQtc2VyaWVzLm1hcm1hcmVrQGludmlz
aWJsZXRoaW5nc2xhYi5jb20vDQo+IMKgIC0gDQo+IGh0dHBzOi8vcGF0Y2hldy5vcmcvWGVuL2Nv
dmVyLjdkYTE3Nzc4ODI3NzQ0ODZhMTNlNmYzOWZmNGEyMDk2ZjZiNzkwMWUuMTc0NDAyODU0OS5n
aXQtc2VyaWVzLm1hcm1hcmVrQGludmlzaWJsZXRoaW5nc2xhYi5jb20vDQo+DQo+ICrCoCBSZW1v
dmUgdGhlIGRpcmVjdG1hcCAodjUpDQo+IMKgIC3CoCBBbGVqYW5kcm8gVmFsbGVqbw0KPiDCoCAt
IA0KPiBodHRwczovL2xvcmUua2VybmVsLm9yZy94ZW4tZGV2ZWwvMjAyNTAxMDgxNTE4MjIuMTYw
MzAtMS1hbGVqYW5kcm8udmFsbGVqb0BjbG91ZC5jb20vDQo+IMKgIC0gDQo+IGh0dHBzOi8vcGF0
Y2hldy5vcmcvWGVuLzIwMjUwMTA4MTUxODIyLjE2MDMwLTEtYWxlamFuZHJvLnZhbGxlam9AY2xv
dWQuY29tLw0KPg0KPiAqwqAgYXV0b21hdGlvbjogUmVmcmVzaCB0aGUgcmVtYWluaW5nIERlYmlh
biBjb250YWluZXJzICh2MikNCj4gwqAgLcKgIEphdmkgTWVyaW5vDQo+IMKgIC0gDQo+IGh0dHBz
Oi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZlbC9jb3Zlci4xNzMwNzQzMDc3LmdpdC5qYXZpLm1l
cmlub0BjbG91ZC5jb20vVC8jbTVkOWFjYjdjZjVkYjNjMmJlM2Q2NTI3ZGUxNGI2OWIwNzgxMjMx
NGUNCj4NCj4gKsKgIEdSVUI6IFN1cHBvcnRpbmcgU2VjdXJlIEJvb3Qgb2YgeGVuLmd6ICh2MSkN
Cj4gwqAgLcKgIFJvc3MgTGFnZXJ3YWxsDQo+IMKgIC0gDQo+IGh0dHBzOi8vcGF0Y2hldy5vcmcv
WGVuLzIwMjQwMzEzMTUwNzQ4Ljc5MTIzNi0xLXJvc3MubGFnZXJ3YWxsQGNpdHJpeC5jb20vDQo+
DQo+ICrCoCBNU0ktWCBzdXBwb3J0IHdpdGggcWVtdSBpbiBzdHViZG9tYWluLCBhbmQgb3RoZXIg
cmVsYXRlZCBjaGFuZ2VzICh2OCkNCj4gwqAgLcKgIE1hcmVrIE1hcmN6eWtvd3NraS1Hw7NyZWNr
aQ0KPiDCoCAtIA0KPiBodHRwczovL2xvcmUua2VybmVsLm9yZy94ZW4tZGV2ZWwvY292ZXIuMzNm
YjQzODViN2RkNmM1M2JkYTRhY2YwYTllOTE3NDhiM2Q3YjFmNy4xNzE1MzEzMTkyLmdpdC1zZXJp
ZXMubWFybWFyZWtAaW52aXNpYmxldGhpbmdzbGFiLmNvbS8NCj4gwqAgLcKgIE9ubHkgYXV0b21h
dGlvbiBwYXRjaCBsZWZ0IHRvIGJlIHJldmlld2VkL21lcmdlZC4NCj4NCj4gKsKgIFtSRkNdIElu
dHJvZHVjZSB4ZW5iaW5kZ2VuIHRvIGF1dG9nZW4gaHlwZXJjYWxsIHN0cnVjdHMgKHYxKQ0KPiDC
oCAtwqAgQWxlamFuZHJvIFZhbGxlam8NCj4gwqAgLSANCj4gaHR0cHM6Ly9wYXRjaGV3Lm9yZy9Y
ZW4vMjAyNDExMTUxMTUyMDAuMjgyNC0xLWFsZWphbmRyby52YWxsZWpvQGNsb3VkLmNvbS8NCj4N
Cj4gKsKgIEludHJvZHVjZSBOUzgyNTAgVUFSVCBlbXVsYXRvciAodjIpDQo+IMKgIC3CoCBEZW5p
cyBNdWtoaW4NCj4gwqAgLSANCj4gaHR0cHM6Ly9wYXRjaGV3Lm9yZy9YZW4vMjAyNDEyMDUtdnVh
cnQtbnM4MjUwLXYxLTAtZTlhYTkyMzEyN2ViQGZvcmQuY29tLw0KPg0KPiA9PT0geDg2ID09PQ0K
Pg0KPiAqIEFsbG93IHg4NiB0byB1bmZsYXR0ZW4gRFRzDQo+IMKgIC0gQWxlamFuZHJvIFZhbGxl
am8NCj4gwqAgLSANCj4gaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcveGVuLWRldmVsLzIwMjUwNTMw
MTIwMjQyLjM5Mzk4LTEtYWdhcmNpYXZAYW1kLmNvbS8NCj4gwqAgLSBodHRwczovL3BhdGNoZXcu
b3JnL1hlbi8yMDI1MDUzMDEyMDI0Mi4zOTM5OC0xLWFnYXJjaWF2QGFtZC5jb20vDQo+DQo+ICog
aHlwZXJsYXVuY2g6IG1vdmUgcmVtYWluaW5nIHB2aCBkb20wIGNvbnN0cnVjdGlvbiAodjIpDQo+
IMKgIC0gRGFuaWVsIFAuIFNtaXRoDQo+IMKgIC0gDQo+IGh0dHBzOi8vbG9yZS5rZXJuZWwub3Jn
L3hlbi1kZXZlbC8yMDI1MDUxNTEzMTkxMi41MDE5LTEtZHBzbWl0aEBhcGVydHVzc29sdXRpb25z
LmNvbS8NCj4NCj4gKiB4ODYvaHlwZXJsYXVuY2g6IGludHJvZHVjZSBjb25jZXB0IG9mIGNvcmUg
ZG9tYWlucyAodjIpDQo+IMKgIC0gRGFuaWVsIFAuIFNtaXRoDQo+IMKgIC0gDQo+IGh0dHBzOi8v
bG9yZS5rZXJuZWwub3JnL3hlbi1kZXZlbC8yMDI1MDUxNTEzMTk1MS41NTk0LTEtZHBzbWl0aEBh
cGVydHVzc29sdXRpb25zLmNvbS8NCj4NCj4gKiBDb25maWRlbnRpYWwgY29tcHV0aW5nIGFuZCBB
TUQgU0VWIHN1cHBvcnQNCj4gwqAgLSBUZWRkeSBBc3RpZQ0KPiDCoCAtIGh0dHBzOi8vcGF0Y2hl
dy5vcmcvWGVuL2NvdmVyLjE3NDczMTIzOTQuZ2l0LnRlZGR5LmFzdGllQHZhdGVzLnRlY2gvDQo+
IMKgIC0gDQo+IGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZlbC9jb3Zlci4xNzQ3MzEy
Mzk0LmdpdC50ZWRkeS5hc3RpZUB2YXRlcy50ZWNoLw0KPg0KPiAqIHg4Ni9lZmk6IEZpeCBib290
aW5nIHdoZW4gTlggaXMgZGlzYWJsZWQgKHYxIC0+IHYyKQ0KPiDCoCAtIEFuZHJldyBDb29wZXIN
Cj4gwqAgLSANCj4gaHR0cHM6Ly9wYXRjaGV3Lm9yZy9YZW4vMjAyNDA3MjIxMDE4MzguMzk0Njk4
My0xLWFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20vDQo+IMKgIC0gDQo+IGh0dHBzOi8vbG9yZS5r
ZXJuZWwub3JnL3hlbi1kZXZlbC8yMDI0MDcyMjEwMTgzOC4zOTQ2OTgzLTEtYW5kcmV3LmNvb3Bl
cjNAY2l0cml4LmNvbS8NCj4NCj4gKiB4ODYvYXNtOiBjbGVhbnVwcyBhZnRlciB0b29sY2hhaW4g
YmFzZWxpbmUgdXBncmFkZSAodjEgLT4gdjIpDQo+IMKgIC0gRGVuaXMgTXVraGluDQo+IMKgIC0g
DQo+IGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZlbC8yMDI1MDQwMzE4MjI1MC4zMzI5
NDk4LTEtZG11a2hpbkBmb3JkLmNvbS8NCj4gwqAgLSBodHRwczovL3BhdGNoZXcub3JnL1hlbi8y
MDI1MDQwMzE4MjI1MC4zMzI5NDk4LTEtZG11a2hpbkBmb3JkLmNvbS8NCj4NCj4gKiBhbWQtY3Bw
YyBDUFUgUGVyZm9ybWFuY2UgU2NhbGluZyBEcml2ZXIgKHY0IC0+IHY1KQ0KPiDCoCAtIFBlbm55
IFpoZW5nDQo+IMKgIC0gDQo+IGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZlbC8yMDI1
MDUyNzA4NDgzMy4zMzg0MjctMS1QZW5ueS5aaGVuZ0BhbWQuY29tLw0KPiDCoCAtIGh0dHBzOi8v
cGF0Y2hldy5vcmcvWGVuLzIwMjUwNDE0MDc0MDU2LjM2OTY4ODgtMS1QZW5ueS5aaGVuZ0BhbWQu
Y29tLw0KPg0KPiAqIHg4NjogVHJlbmNoYm9vdCBTZWN1cmUgTGF1bmNoIERSVE0gKFhlbikgKHYx
IC0+IHYzKQ0KPiDCoCAtIFNlcmdpaSBEbXl0cnVrDQo+IMKgIC0gDQo+IGh0dHBzOi8vcGF0Y2hl
dy5vcmcvWGVuL2NvdmVyLjE3NDUxNzIwOTQuZ2l0LnNlcmdpaS5kbXl0cnVrQDNtZGViLmNvbS8N
Cj4gwqAgLSANCj4gaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcveGVuLWRldmVsL2NvdmVyLjE3NDg2
MTEwNDEuZ2l0LnNlcmdpaS5kbXl0cnVrQDNtZGViLmNvbS8NCj4NCj4gKiB4ODYvRUZJOiBwcmV2
ZW50IHdyaXRlLWV4ZWN1dGUgc2VjdGlvbnMNCj4gwqAgLSBSb2dlciBQYXUgTW9ubmUgPHJvZ2Vy
LnBhdUBjaXRyaXguY29tPg0KPiDCoCAtIA0KPiBodHRwczovL2xvcmUua2VybmVsLm9yZy94ZW4t
ZGV2ZWwvMjAyNTA0MDExMzA4NDAuNzIxMTktMS1yb2dlci5wYXVAY2l0cml4LmNvbS8NCj4NCj4g
KiBIeXBlcmxhdW5jaCBkZXZpY2UgdHJlZSBmb3IgZG9tMCAodjYpDQo+IMKgIC0gQWxlamFuZHJv
IFZhbGxlam8NCj4gwqAgLSBodHRwczovL3BhdGNoZXcub3JnL1hlbi8yMDI1MDQyOTEyMzYyOS4y
MDgzOS0xLWFnYXJjaWF2QGFtZC5jb20vDQo+IMKgIC0gDQo+IGh0dHBzOi8vbG9yZS5rZXJuZWwu
b3JnL3hlbi1kZXZlbC8yMDI1MDQyOTEyMzYyOS4yMDgzOS0xLWFnYXJjaWF2QGFtZC5jb20vDQo+
DQo+ICogSHlwZXJsYXVuY2ggZG9tYWluIGJ1aWxkZXINCj4gwqAgLSBEYW5pZWwgUC4gU21pdGgN
Cj4gwqAgLSANCj4gaHR0cHM6Ly9wYXRjaGV3Lm9yZy9YZW4vMjAyNTA0MTkyMjA4MjAuNDIzNC0x
LWRwc21pdGhAYXBlcnR1c3NvbHV0aW9ucy5jb20vDQo+DQo+ICoga2V4ZWM6IGFkZCBrZXhlYyBz
dXBwb3J0IHRvIE1pbmktT1MNCj4gwqAgLSBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+
DQo+IMKgIC0gDQo+IGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZlbC8yMDI1MDMyMTA5
MjQ1MS4xNzMwOS0xLWpncm9zc0BzdXNlLmNvbS8NCj4NCj4gKiB4ODY6IGdlbmVyYXRlIHhlbi5l
ZmkgaW1hZ2Ugd2l0aCBubyB3cml0ZS1leGVjdXRlIHNlY3Rpb25zDQo+IMKgIC0gUm9nZXIgUGF1
IE1vbm5lDQo+IMKgIC0gDQo+IGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZlbC8yMDI1
MDMxODE3MzU0Ny41OTQ3NS0xLXJvZ2VyLnBhdUBjaXRyaXguY29tLw0KPg0KPiAqwqAgRXhwb3Nl
IGNvbnNpc3RlbnQgdG9wb2xvZ3kgdG8gZ3Vlc3RzICh2NykNCj4gwqAgLcKgIEFsZWphbmRybyBW
YWxsZWpvDQo+IMKgIC0gDQo+IGh0dHBzOi8vcGF0Y2hldy5vcmcvWGVuLzIwMjQxMDIxMTU0NjAw
LjExNzQ1LTEtYWxlamFuZHJvLnZhbGxlam9AY2xvdWQuY29tLw0KPg0KPiAqwqAgQm9vdCBtb2R1
bGVzIGZvciBIeXBlcmxhdW5jaCAodjkpDQo+IMKgIC3CoCBEYW5pZWwgUC4gU21pdGgNCj4gwqAg
LSANCj4gaHR0cHM6Ly9wYXRjaGV3Lm9yZy9YZW4vMjAyNDExMTUxMzEyMDQuMzIxMzUtMS1kcHNt
aXRoQGFwZXJ0dXNzb2x1dGlvbnMuY29tLw0KPg0KPiAqwqAgQWRkcmVzcyBTcGFjZSBJc29sYXRp
b24gRlBVIHByZXBhcmF0aW9ucyAodjItPnYzKQ0KPiDCoCAtwqAgQWxlamFuZHJvIFZhbGxlam8N
Cj4gwqAgLSANCj4gaHR0cHM6Ly9wYXRjaGV3Lm9yZy9YZW4vMjAyNTAxMTAxMzI4MjMuMjQzNDgt
MS1hbGVqYW5kcm8udmFsbGVqb0BjbG91ZC5jb20vDQo+DQo+ICrCoCB4ODYvYWx0ZXJuYXRpdmVz
OiBBZGp1c3QgYWxsIGluc24tcmVsYXRpdmUgZmllbGRzICh2MikNCj4gwqAgLcKgIEFuZHJldyBD
b29wZXINCj4gwqAgLSANCj4gaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcveGVuLWRldmVsLzIwMjQx
MDAyMTUyNzI1LjE4NDE1NzUtMS1hbmRyZXcuY29vcGVyM0BjaXRyaXguY29tL1QvI21hYzJkZWFl
YTdlMDJhMzQzMjEwZDYxODg3NDg2NDMzZDk0NmFkMTI5DQo+DQo+ICrCoCB4ODZlbXVsOiBtaXNj
IGFkZGl0aW9ucyAodjcpDQo+IMKgIC3CoCBKYW4gQmV1bGljaA0KPiDCoCAtIA0KPiBodHRwczov
L3BhdGNoZXcub3JnL1hlbi8zYTI1Y2Q1OS1lMWNiLTRiZmMtYjg2OC1mYjExNTk5ZDIyZjVAc3Vz
ZS5jb20vDQo+DQo+ICrCoCB4ODY6IHN1cHBvcnQgQVZYMTAgKHYzKQ0KPiDCoCAtwqAgSmFuIEJl
dWxpY2gNCj4gwqAgLSANCj4gaHR0cHM6Ly9wYXRjaGV3Lm9yZy9YZW4vNTE2YjdmOWEtMDQ4ZS00
MDlkLThhNGUtODlhZWI4ZmZhY2M0QHN1c2UuY29tLw0KPg0KPiAqwqAgVlQtZDogU0FUQyBoYW5k
bGluZzsgQVRTOiB0aWR5aW5nICh2MikNCj4gwqAgLcKgIEphbiBCZXVsaWNoDQo+IMKgIC0gDQo+
IGh0dHBzOi8vcGF0Y2hldy5vcmcvWGVuLzY0YjAyOGJlLTIxOTctNDk1MS1hZTViLTMyZjllYWJm
YTg0YUBzdXNlLmNvbS8NCj4NCj4gKsKgIHg4NjogcGFyYWxsZWxpemUgQVAgYnJpbmctdXAgZHVy
aW5nIGJvb3QgKHYxKQ0KPiDCoCAtwqAgS3J5c3RpYW4gSGViZWwNCj4gwqAgLSANCj4gaHR0cHM6
Ly9sb3JlLmtlcm5lbC5vcmcveGVuLWRldmVsL2NvdmVyLjE2OTk5ODIxMTEuZ2l0LmtyeXN0aWFu
LmhlYmVsQDNtZGViLmNvbS8NCj4NCj4gKsKgIHg4Ni9zcGVjLWN0cmw6IElCUEIgaW1wcm92ZW1l
bnRzICh2NCkNCj4gwqAgLcKgIEphbiBCZXVsaWNoDQo+IMKgIC0gDQo+IGh0dHBzOi8vcGF0Y2hl
dy5vcmcvWGVuLzA2NTkxYjY0LTJmMDUtYTRjYy1hMmYzLWE3NGMzYzRhNzZkNkBzdXNlLmNvbS8N
Cj4NCj4gKsKgIE1vdmUgc29tZSBib290IGNvZGUgZnJvbSBhc3NlbWJseSB0byBDICh2MikNCj4g
wqAgLcKgIEZyZWRpYW5vIFppZ2xpbw0KPiDCoCAtIA0KPiBodHRwczovL3BhdGNoZXcub3JnL1hl
bi8yMDI0MTEyMjA5MzM1OC40Nzg3NzQtMS1mcmVkaWFuby56aWdsaW9AY2xvdWQuY29tLw0KPg0K
PiAqwqAgeDg2OiBtZW1jcHkoKSAvIG1lbXNldCgpIChub24tKUVSTVMgZmxhdm9ycyBwbHVzIGZh
bGxvdXQgKHY0KQ0KPiDCoCAtwqAgSmFuIEJldWxpY2gNCj4gwqAgLSANCj4gaHR0cHM6Ly9wYXRj
aGV3Lm9yZy9YZW4vMTRiNjUyMzEtYjgzYi00M2ZiLWJiY2YtZGVjNWMwN2QyODViQHN1c2UuY29t
Lw0KPg0KPiAqwqAgYW1kLXBzdGF0ZSBDUFUgUGVyZm9ybWFuY2UgU2NhbGluZyBEcml2ZXIgKHYx
KQ0KPiDCoCAtwqAgUGVubnkgWmhlbmcNCj4gwqAgLSBodHRwczovL3BhdGNoZXcub3JnL1hlbi8y
MDI0MTIwMzA4MTExMS40NjM0MDAtMS1QZW5ueS5aaGVuZ0BhbWQuY29tLw0KPg0KPiA9PT0gQVJN
ID09PQ0KPg0KPiAqIFNNTVUgaGFuZGxpbmcgZm9yIFBDSWUgUGFzc3Rocm91Z2ggb24gQVJNICh2
MTEpDQo+IMKgIC0gTXlreXRhIFBvdHVyYWkNCj4gwqAgLSANCj4gaHR0cHM6Ly9sb3JlLmtlcm5l
bC5vcmcveGVuLWRldmVsL2NvdmVyLjE3NDE5NTg2NDcuZ2l0Lm15a3l0YV9wb3R1cmFpQGVwYW0u
Y29tLw0KPiDCoCAtIA0KPiBodHRwczovL3BhdGNoZXcub3JnL1hlbi9jb3Zlci4xNzQ4NDIyMjE3
LmdpdC5teWt5dGEuXzVGcG90dXJhaUBlcGFtLmNvbS8NCj4NCj4gKiB4ZW4vYXJtOiBzY21pOiBp
bnRyb2R1Y2UgU0NJIFNDTUkgU01DIG11bHRpLWFnZW50IHN1cHBvcnQNCj4gwqAgLSBHcnlnb3Jp
aSBTdHJhc2hrbw0KPiDCoCAtIA0KPiBodHRwczovL2xvcmUua2VybmVsLm9yZy94ZW4tZGV2ZWwv
MjAyNTAzMTExMTE2MTguMTg1MDkyNy0xLWdyeWdvcmlpX3N0cmFzaGtvQGVwYW0uY29tLw0KPg0K
SSBjb25maXJtIHRoYXQgdGhlcmUgYXJlIHBsYW5zIHRvIGludHJvZHVjZSBTQ0kgU0NNSSBTTUMg
bXVsdGktYWdlbnQgDQpzdXBwb3J0IGluIDQuMjEuDQoNCg0KVGhlIFY0IHBhdGNoIHNlcmllcyBo
YXMgYWxyZWFkeSBiZWVuIHBvc3RlZDoNCg0KaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcveGVuLWRl
dmVsL2NvdmVyLjE3NDc2Njk4NDUuZ2l0Lm9sZWtzaWlfbW9pc2llaWV2QGVwYW0uY29tLw0KDQoN
CkJlc3QgcmVnYXJkcywNCg0KT2xla3NpaQ0KDQo+ICogQWRkIGluaXRpYWwgWGVuIFN1c3BlbmQt
dG8tUkFNIHN1cHBvcnQgb24gQVJNNjQgKHY0KQ0KPiDCoCAtIE15a29sYSBLdmFjaA0KPiDCoCAt
IA0KPiBodHRwczovL2xvcmUua2VybmVsLm9yZy94ZW4tZGV2ZWwvY292ZXIuMTc0MTE2NDEzOC5n
aXQueGFrZXAuYW1hdG9wQGdtYWlsLmNvbS8NCj4gwqAgLSANCj4gaHR0cHM6Ly9wYXRjaGV3Lm9y
Zy9YZW4vY292ZXIuMTc0ODg0ODQ4Mi5naXQubXlrb2xhLl81Rmt2YWNoQGVwYW0uY29tLw0KPg0K
PiAqIEFkZCBzdXBwb3J0IGZvciBSLUNhciBHZW40IFBDSSBob3N0IGNvbnRyb2xsZXIgKHY0IC0+
IHY1KQ0KPiDCoCAtIE15a3l0YSBQb3R1cmFpDQo+IMKgIC0gDQo+IGh0dHBzOi8vbG9yZS5rZXJu
ZWwub3JnL3hlbi1kZXZlbC9jb3Zlci4xNzQ3ODIwODQ0LmdpdC5teWt5dGFfcG90dXJhaUBlcGFt
LmNvbS8NCj4gwqAgLSANCj4gaHR0cHM6Ly9wYXRjaGV3Lm9yZy9YZW4vY292ZXIuMTc0NzgyMDg0
NC5naXQubXlreXRhLl81RnBvdHVyYWlAZXBhbS5jb20vDQo+DQo+ICogRkYtQSBWTSB0byBWTSBz
dXBwb3J0ICh2NSAtPiB2NikNCj4gwqAgLSBCZXJ0cmFuZCBNYXJxdWlzIDxiZXJ0cmFuZC5tYXJx
dWlzQGFybS5jb20+DQo+IMKgIC0gDQo+IGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZl
bC9jb3Zlci4xNzQ3OTI1Mjg3LmdpdC5iZXJ0cmFuZC5tYXJxdWlzQGFybS5jb20vDQo+IMKgIC0g
DQo+IGh0dHBzOi8vcGF0Y2hldy5vcmcvWGVuL2NvdmVyLjE3NDc5MjUyODcuZ2l0LmJlcnRyYW5k
Lm1hcnF1aXNAYXJtLmNvbS8NCj4NCj4gKiBGaXJzdCBjaHVuayBmb3IgQXJtIFI4MiBhbmQgTVBV
IHN1cHBvcnQgKHY0IC0+IHY2KQ0KPiDCoCAtIEx1Y2EgRmFuY2VsbHUNCj4gwqAgLSANCj4gaHR0
cHM6Ly9sb3JlLmtlcm5lbC5vcmcveGVuLWRldmVsLzIwMjUwNTIzMDY1NDA2LjM3OTU0MjAtMS1s
dWNhLmZhbmNlbGx1QGFybS5jb20vDQo+IMKgIC0gDQo+IGh0dHBzOi8vcGF0Y2hldy5vcmcvWGVu
LzIwMjUwNTIzMDY1NDA2LjM3OTU0MjAtMS1sdWNhLmZhbmNlbGx1QGFybS5jb20vDQo+DQo+ICog
QVJNIHNwbGl0IGhhcmR3YXJlIGFuZCBjb250cm9sIGRvbWFpbnMgKHY1KQ0KPiDCoCAtIEphc29u
IEFuZHJ5dWsNCj4gwqAgLSANCj4gaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcveGVuLWRldmVsLzIw
MjUwNDE2MjEyOTExLjQxMDk0Ni0xLWphc29uLmFuZHJ5dWtAYW1kLmNvbS8NCj4gwqAgLSANCj4g
aHR0cHM6Ly9wYXRjaGV3Lm9yZy9YZW4vMjAyNTA0MTYyMTI5MTEuNDEwOTQ2LTEtamFzb24uYW5k
cnl1a0BhbWQuY29tLw0KPg0KPiAqIE1QVSBtbSBzdWJzaXN0ZW0gc2tlbGV0b24NCj4gwqAgLSBM
dWNhIEZhbmNlbGx1DQo+IMKgIC0gDQo+IGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZl
bC8yMDI1MDMxMjEzNTI1OC4xODE1NzA2LTEtbHVjYS5mYW5jZWxsdUBhcm0uY29tLw0KPiDCoCAt
IA0KPiBodHRwczovL3BhdGNoZXcub3JnL1hlbi8yMDI1MDMxMjEzNTI1OC4xODE1NzA2LTEtbHVj
YS5mYW5jZWxsdUBhcm0uY29tLw0KPg0KPiAqwqAgQWRkIFZpcnRpby1QQ0kgZm9yIGRvbTBsZXNz
IG9uIEFSTSAodjEpDQo+IMKgIC3CoCBFZGdhciBFLiBJZ2xlc2lhcw0KPiDCoCAtIA0KPiBodHRw
czovL2xvcmUua2VybmVsLm9yZy94ZW4tZGV2ZWwvMjAyNDA5MjQxNjIzNTkuMTM5MDQ4Ny0xLWVk
Z2FyLmlnbGVzaWFzQGdtYWlsLmNvbS9ULyNtZmExNDg5OTFiOTQwOGYyMjNhMDc5ZDRjZWY2MTAy
NDRkNWIwNGMyYg0KPiDCoCAtIA0KPiBodHRwczovL3BhdGNoZXcub3JnL1hlbi8yMDI0MDkyNDE2
MjM1OS4xMzkwNDg3LTEtZWRnYXIuaWdsZXNpYXNAZ21haWwuY29tLw0KPg0KPiAqwqAgRE9NQ1RM
LWJhc2VkIGd1ZXN0IG1hZ2ljIHJlZ2lvbiBhbGxvY2F0aW9uIGZvciAxMSBkb21VcyAodjQpDQo+
IMKgIC3CoCBIZW5yeSBXYW5nDQo+IMKgIC0gaHR0cHM6Ly9wYXRjaGV3Lm9yZy9YZW4vMjAyNDA0
MDkwNDUzNTcuMjM2ODAyLTEteGluLndhbmcyQGFtZC5jb20vDQo+DQo+ID09PSBSSVNDViA9PT0N
Cj4NCj4gKiByaXNjdjogaW50cm9kdWNlIGJhc2ljIFVBUlQgc3VwcG9ydCBhbmQgaW50ZXJydXB0
cyBmb3IgaHlwZXJ2aXNvciANCj4gbW9kZSAodjIgLT4gdjMpDQo+IMKgIC3CoCBPbGVrc2lpIEt1
cm9jaGtvDQo+IMKgIC0gDQo+IGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZlbC9jb3Zl
ci4xNzQ3ODQzMDA5LmdpdC5vbGVrc2lpLmt1cm9jaGtvQGdtYWlsLmNvbS8NCj4gwqAgLSANCj4g
aHR0cHM6Ly9wYXRjaGV3Lm9yZy9YZW4vY292ZXIuMTc0Nzg0MzAwOS5naXQub2xla3NpaS5rdXJv
Y2hrb0BnbWFpbC5jb20vDQo+DQo+ICogeGVuL3Jpc2N2OiBpbnRyb2R1Y2UgcDJtIGZ1bmN0aW9u
YWxpdHkgKHYxKQ0KPiDCoCAtIE9sZWtzaWkgS3Vyb2Noa28NCj4gwqAgLSANCj4gaHR0cHM6Ly9s
b3JlLmtlcm5lbC5vcmcveGVuLWRldmVsL2NvdmVyLjE3NDY4MDU5MDcuZ2l0Lm9sZWtzaWkua3Vy
b2Noa29AZ21haWwuY29tLw0KPiDCoCAtIA0KPiBodHRwczovL3BhdGNoZXcub3JnL1hlbi9jb3Zl
ci4xNzQ2ODA1OTA3LmdpdC5vbGVrc2lpLmt1cm9jaGtvQGdtYWlsLmNvbS8NCj4NCj4gPT09IFBQ
QyA9PT0NCj4NCj4gKsKgIEVhcmx5IEJvb3QgQWxsb2NhdGlvbiBvbiBQb3dlciAodjUpDQo+IMKg
IC3CoCBTaGF3biBBbmFzdGFzaW8NCj4gwqAgLSANCj4gaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcv
eGVuLWRldmVsL2NvdmVyLjE3MjczODg5MjUuZ2l0LnNhbmFzdGFzaW9AcmFwdG9yZW5naW5lZXJp
bmcuY29tL1QvI204Y2FjOTFhOTNiNTZhMzU5ZmEyZDVmMDg1OTZjNGJlNjFkY2EyOTBkDQo+IMKg
IC0gDQo+IGh0dHBzOi8vcGF0Y2hldy5vcmcvWGVuL2NvdmVyLjE3MjczODg5MjUuZ2l0LnNhbmFz
dGFzaW9AcmFwdG9yZW5naW5lZXJpbmcuY29tLw0KPg0KPiA9PSBDb21wbGV0ZWQgPT0NCj4NCj4g
PT09IEh5cGVydmlzb3IgPT09DQo+DQo+ICogdG9vbHM6IHJlbW92ZSBxZW11LXRyYWRpdGlvbmFs
DQo+IMKgIC0gSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1c2UuY29tPg0KPiDCoCAtIA0KPiBodHRw
czovL2xvcmUua2VybmVsLm9yZy94ZW4tZGV2ZWwvMjAyNTA1MjcxMzIwMzUuOTg1LTEtamdyb3Nz
QHN1c2UuY29tLw0KPg0KPiAqwqAgcmVtb3ZlIGxpYnhlbmN0cmwgdXNhZ2UgZnJvbSB4ZW5zdG9y
ZWQgKHY4KQ0KPiDCoCAtwqAgSnVlcmdlbiBHcm9zcw0KPiDCoCAtIA0KPiBodHRwczovL2xvcmUu
a2VybmVsLm9yZy94ZW4tZGV2ZWwvMjAyNTAyMDQxMTM0MDcuMTY4MzktMS1qZ3Jvc3NAc3VzZS5j
b20vDQo+DQo+ICogeGVuL2NvbmZpZy5oOiBNb3ZlIEJJVFNfUEVSXyogZGVmaW5pdGlvbnMgZnJv
bSBhc20vY29uZmlnLmggdG8gDQo+IHhlbi9jb25maWcuaA0KPiDCoCAtIE9sZWtzaWkgS3Vyb2No
a28NCj4gwqAgLSANCj4gaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcveGVuLWRldmVsLzZiMjFmYjA0
NmNmMWM4Y2E3NjBmNWFkNzJmYTNjYzEzYjU5YzQwNjkuMTc0MzA5MjQ4NS5naXQub2xla3NpaS5r
dXJvY2hrb0BnbWFpbC5jb20vDQo+DQo+ICogTW92ZSBwYXJ0cyBvZiBBcm0ncyBEb20wbGVzcyB0
byBjb21tb24gY29kZQ0KPiDCoCAtwqAgT2xla3NpaSBLdXJvY2hrbw0KPiDCoCAtIA0KPiBodHRw
czovL3BhdGNoZXcub3JnL1hlbi9jb3Zlci4xNzQ2NDY4MDAzLmdpdC5vbGVrc2lpLmt1cm9jaGtv
QGdtYWlsLmNvbS8NCj4gwqAgLSANCj4gaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcveGVuLWRldmVs
L2NvdmVyLjE3NDY0NjgwMDMuZ2l0Lm9sZWtzaWkua3Vyb2Noa29AZ21haWwuY29tL1QvI3QNCj4N
Cj4gPT09IHg4NiA9PT0NCj4NCj4gKiB4ZW46IGNhY2hlIGNvbnRyb2wgaW1wcm92ZW1lbnRzDQo+
IMKgIC0gUm9nZXIgUGF1IE1vbm5lDQo+IMKgIC0gDQo+IGh0dHBzOi8vbG9yZS5rZXJuZWwub3Jn
L3hlbi1kZXZlbC8yMDI1MDUwNjA4MzE0OC4zNDk2My0xLXJvZ2VyLnBhdUBjaXRyaXguY29tLw0K
Pg0KPiAqwqAgeDg2L0hWTTogZW11bGF0aW9uIChNTUlPKSBpbXByb3ZlbWVudHMgKHYzKQ0KPiDC
oCAtwqAgSmFuIEJldWxpY2gNCj4gwqAgLSANCj4gaHR0cHM6Ly9wYXRjaGV3Lm9yZy9YZW4vNzI5
Zjc4OTYtNTViNy00YjViLWE3ZTktNmViMDQyMGUwYjE0QHN1c2UuY29tLw0KPg0KPiA9PT0gQVJN
ID09PQ0KPiAqwqAgUENJIGRldmljZXMgcGFzc3Rocm91Z2ggb24gQXJtLCBwYXJ0IDMgKHYxNi0+
djIwLT52MjEpDQo+IMKgIC3CoCBTdGV3YXJ0IEhpbGRlYnJhbmQNCj4gwqAgLSANCj4gaHR0cHM6
Ly9wYXRjaGV3Lm9yZy9YZW4vMjAyNTA1MDgxMDQ2MDguNTMxMDc5LTEtc3Rld2FydC5oaWxkZWJy
YW5kQGFtZC5jb20vDQo+IMKgIC0gDQo+IGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZl
bC8yMDI1MDUwODEwNDYwOC41MzEwNzktMS1zdGV3YXJ0LmhpbGRlYnJhbmRAYW1kLmNvbS8NCj4N
Cj4gKiBFbmFibGUgZWFybHkgYm9vdHVwIG9mIEFybXY4LVIgQUFyY2gzMiBzeXN0ZW1zDQo+IMKg
IC0gQXlhbiBLdW1hciBIYWxkZXINCj4gwqAgLSANCj4gaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcv
eGVuLWRldmVsLzIwMjUwNDE0MTY0NTE0LjU4ODM3My0xLWF5YW4ua3VtYXIuaGFsZGVyQGFtZC5j
b20vDQo+IMKgIC0gDQo+IGh0dHBzOi8vcGF0Y2hldy5vcmcvWGVuLzIwMjUwNDE0MTY0NTE0LjU4
ODM3My0xLWF5YW4ua3VtYXIuaGFsZGVyQGFtZC5jb20vDQo+DQo+ID09PSBSSVNDLVYgPT09DQo+
DQo+ICogUklTQy1WIHNvbWUgcHJlaW5pdCBjYWxsczoNCj4gwqAgLcKgIE9sZWtzaWkgS3Vyb2No
a28NCj4gwqAgLSANCj4gaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcveGVuLWRldmVsLzRkZGRlNjAz
NDdlZGY2NzQwZmJjNjliNTczOWQwOTk2MTZmNWI1ZmYuMTc0MzE2NTc5MS5naXQub2xla3NpaS5r
dXJvY2hrb0BnbWFpbC5jb20vDQo+DQo+ICogRml4ZXMgZm9yIFVCU0FOICYgR0NPViBzdXBwb3J0
IGZvciBSSVNDLVY6DQo+IMKgIC3CoCBPbGVrc2lpIEt1cm9jaGtvDQo+IMKgIC0gDQo+IGh0dHBz
Oi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZlbC85ZmJiNWUxMzg5Yjg0YmVkMmU5NWY5OWU0YzM4
M2QwMjE1YzdhNTI0LjE3NDQ4ODkxODUuZ2l0Lm9sZWtzaWkua3Vyb2Noa29AZ21haWwuY29tLw0K
Pg0KPiBIYXZlIGEgZ29vZCB3ZWVrIQ0KPg0KPiBCZXN0IHJlZ2FyZHMsDQo+IMKgT2xla3NpaQ0K
Pg0KPg==


From xen-devel-bounces@lists.xenproject.org Sat Jun 14 14:20:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jun 2025 14:20:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1015538.1393145 (Exim 4.92)
	(envelope-from )
	id 1uQRkN-0000Iu-9V; Sat, 14 Jun 2025 14:20:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1015538.1393145; Sat, 14 Jun 2025 14:20: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 1uQRkN-0000Il-4X; Sat, 14 Jun 2025 14:20:39 +0000
Received: by outflank-mailman (input) for mailman id 1015538;
 Sat, 14 Jun 2025 14:20: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 1uQRkL-0000HI-BF
 for xen-devel@lists.xenproject.org; Sat, 14 Jun 2025 14:20:37 +0000
Received: from MRWPR03CU001.outbound.protection.outlook.com
 (mail-francesouthazlp170110003.outbound.protection.outlook.com
 [2a01:111:f403:c207::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bccc7174-492a-11f0-a309-13f23c93f187;
 Sat, 14 Jun 2025 16:20:35 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by GV1PR03MB8815.eurprd03.prod.outlook.com (2603:10a6:150:a1::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.25; Sat, 14 Jun
 2025 14:20:32 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%4]) with mapi id 15.20.8835.023; Sat, 14 Jun 2025
 14:20: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: bccc7174-492a-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=niz0wIJXlpWsRqgKvhOkzOydwoIxiiH1jp8sX2UNpFNy05utW8qMaKEXYqtiKmscXXG/ySAh4CJo4LYD+z8mNUlZF4vnpgmc/rwmkAQnj6Sv9iZeLjkms6twYq+b+3T9SaZOOkh1fSApX1KacXvM+W7JbfojtIpUjU/gcKr7lB2h8W2BMWICuq4ARnMMEHx/hRXZ/twRwkBk4QFBq3skmNUmn6wluty0eNvHh3Ijn9eL2EWAylHbks5cFzAf3Uocn84Y7VwXuHYvigWfYX4z4Lm8FhYHtORQtduZAV76Lza1PV9hMdODRo1OoCseIoFGZiJ3PRF7VH9IzXyRfuzDCA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=610YW1FMZpiWpwnXWazvhuYEOfwA1T1X0AqhtLpOb2M=;
 b=lnUoAtsOeZexrlZNpYAGHtJIMRdUvXg6a/xr2iJ29RUmo3oUW+ywfbGuI81lpFnB+eXgHh7N7LsHxA8NFIXAOVJmw5WI6u/bmiDk9hivMhx8m+jvPS13oSYq+O4svRX5Ul9qZlpt5VKtSVOH3nteHWFVxsDOeR3y5ZRzr/5nNWHq2dub/SecP8GRy62bnmRPaJFamKiY6Hb1/9JX2W1XhOMz3ZQC6sm4L2tvVVKK6lL2g1+70RRMuum5TryFy2wGhm3C1K2lT5TDvI21MoUxlq5hDTWjHUj2tJ75j/l3wmO+bR6RsaB0mehN4FVZuxG0xtXo20DkXp0K56TGNsMFiQ==
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=610YW1FMZpiWpwnXWazvhuYEOfwA1T1X0AqhtLpOb2M=;
 b=dP7uTyBECKhmiNnmqx4X9XeaHEtOOdDpmXJnv3KJ4O/D3Uy26SEzCy9jtSMNiqo13uXtyVN7Z4PvxogYN49TJ42JYmvnrzK0k48T3rVhGFAZqW3vII3QiMN6D9F81lPbwB1eiQCCCIkHPSKHtkJV32wuop+deltZdlbI21OHFqhShhbJffCH/mLp8WbFa18gqIOZaCM9HjntW35LdFlThI8TNLFYQ63m6VNaHDJXKJVOaXcsLqyuxpK8cYjt4aKdgYBjDXu3C98DgQOCqGFabdilruPFEmoRazMczvB8Yb+1g5iQh5VfvTa1J6Wc3zz4XvOdoPsOPOGdHPaB9ewUmw==
From: Oleksii Moisieiev 
To: Oleksii Kurochko ,
	"xen-devel@lists.xenproject.org" 
CC: Ayan Kumar Halder , Mykyta Poturai
	, Juergen Gross , Teddy Astie
	, Bertrand Marquis , Luca
 Fancellu , Jason Andryuk ,
	Alejandro Vallejo , Sergii Dmytruk
	, Penny Zheng ,
	=?utf-8?B?TWFyZWsgTWFyY3p5a293c2tpLUfDs3JlY2tp?=
	, Roger Pau Monne ,
	Andrew Cooper , "dmkhn@proton.me"
	, Mykola Kvach , "Daniel P. Smith"
	, Grygorii Strashko ,
	Alejandro Vallejo , "committers@xenproject.org"
	, Community Manager
	
Subject: Re: Xen 4.21 Development Update [May]
Thread-Topic: Xen 4.21 Development Update [May]
Thread-Index: AQHb3Td8jze4CyxPok6FyLun6n8+8w==
Date: Sat, 14 Jun 2025 14:20:31 +0000
Message-ID: <7bc7d3ed-6dce-4939-ac7e-470efa253d48@epam.com>
References: <7364a71d-2604-49ca-bab7-d21544d49b10@gmail.com>
In-Reply-To: <7364a71d-2604-49ca-bab7-d21544d49b10@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB8946:EE_|GV1PR03MB8815:EE_
x-ms-office365-filtering-correlation-id: 729d0c8e-8b25-4662-adea-08ddab4e9ef1
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|366016|7416014|376014|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?aS8zMGY1d2lUcE1oSG53RTBNR2gxeitFTlM4SEt1T2piRE56SUh6RHp0cXdq?=
 =?utf-8?B?MHVLZEd3dTNxaEFicnN3d0JndytxSlA2M2lhT05tMkNMcEFzTGlBaDF4dU95?=
 =?utf-8?B?SElTU25BWkhrUjhRT1JGLzA5eVRqSXRWYzBjUFg2dUFWS2E2L3BJS0xiODZr?=
 =?utf-8?B?VzR5bmswQSsrRUxCVHp3d1l1WjRralNUV0E1ckxmZzhxdE9yc0NOcEdYQTFW?=
 =?utf-8?B?K0VDSzdXNXdWbnNZend4UVZnNWxBVmhKZmp4aDVVMjQ5ck5RaW1lNjdHQVpT?=
 =?utf-8?B?b2k3anRnejZsbVNldGtEbWU0aEJvUWFZeEJsQW9wQTZEYVByTTZsYVVrOEJi?=
 =?utf-8?B?QnhDa29yVEtSUmpGVlVXK2UvdFB0S2Naa1grQTZwWEM2MTVydUphVWpEUnFx?=
 =?utf-8?B?aHJNc2dFOUtxcTVKTno5aHo0Njh5dXc4QU9GWXRIVlJRdXpiSFlTL3AyT1Fx?=
 =?utf-8?B?WlBUM1ZWbU16N1ZDcUFzQVRNalllTzYwUW9qSXJiRkEydzVyTkx3ZnF0aU9N?=
 =?utf-8?B?NWprYXhXTE1BKzBxRlNUVElZS3pDUWR0UU1TVDVpNDNRMElGNjNBVVVYWXVq?=
 =?utf-8?B?a2Zod0NVdHFnaEg4TFl6YjFRb0xwMmhacHNtTkJIajhBR2IyZHJ1aXV0RDNG?=
 =?utf-8?B?NVRvaVp2UloyMUZBZ2xTcVJhcTNzM1VsclNMK0VtTmlLOStpMWFaVHE5RTV2?=
 =?utf-8?B?THRCZjNEbmVxWTNXSEQyM1Fsakt1TENmaU1PenVlbkUrS2F6NThnZktubVNh?=
 =?utf-8?B?OVhUc2xhNDlqNjJMWlAzejh4M2FlZEx6MmpVUlc0anROa1dRMEFMOXEyd0hx?=
 =?utf-8?B?eDBNNkc2YjNMRVR4bUZ6eVZ5M1RYb242K2lyRlQ2MVk5MkpId05qSE1nZE1K?=
 =?utf-8?B?VFovUXphdmQ4THVHS3pwa2k1UWtuVGcrbGFYeWN2anFnV3Rtb1hLMmJTc1kv?=
 =?utf-8?B?VWJZcFltcjA4M2ljd0VFSXlackgrRFdYcDQ1c0NCZkM4cVdBRlhkU2JTWkM2?=
 =?utf-8?B?WjZhTHp3SWZ4aURDTjUzczlROExtcEs5Vk9KZE9PQXJqb3luRHh1bUJYdURD?=
 =?utf-8?B?K2ZFdEFJM3FoR2VRNVB4TDh4alNkTmY5UHpGbWMrT0k2cFJyd3RMZ2ZtWDJB?=
 =?utf-8?B?cUJtYzNkaXZZMWhvRkhaV2oySUlPRlBvY2pLZkN0TzZxaXJQZHFrb0JMWFZs?=
 =?utf-8?B?KzRkaVY4TmF6K1NHUHYzMThxSkRsM3VBNTlOQ2FrZE1CbVNmRldwbWwxYnRu?=
 =?utf-8?B?VjZMSC9UdzBTRTczUVhkSWVDSHRFRWY1VWllZUtqS0dwN2oxYjVHSzFLRktm?=
 =?utf-8?B?dmlVU3F1akp0Z3h1cEpqU2djTlNKNkVPRWZibTRMbWF6WnpBc2h1WllpWThw?=
 =?utf-8?B?VytuS1kybS9CSmRCSGlwR2lKZ2FCeFNBeDI2K3Axc1Rjci9NM1FFNEJySXpt?=
 =?utf-8?B?blBjWURWVkxDYjVTNzlRMDdFeTgxSjFxMDVZZmphY2NhRW41VHl4ZldLdjBG?=
 =?utf-8?B?VnNjSWEzSnd1djVTUGxsRzR2Q1JVeE9pYUhERUhkTlY1L3Z1Y3NudmhKbnJV?=
 =?utf-8?B?OHpkWS8rR0VITkN4bk5mZkZVWTdCVW9Ub3I1SkxnaGhlMnU5QUV1MkNYUy9t?=
 =?utf-8?B?MkVGdE9Hd2hPSkFwK1VQbXRjWldyZWxVK2plQXJtUnFPVVlabFNsa2tBTTlS?=
 =?utf-8?B?RjdKdEVWMXZEN0tFWXRJTDd0dUdVSHd6WHA2RnZLU3E0aVF1bDNJU3FkeGIx?=
 =?utf-8?B?ajUrMHpJYzNuTlZtZ01VUldBMDhpcWFUcUtNMzdoaHhGTUtMNjk4eGVvYzdB?=
 =?utf-8?B?eDh2eEhqVEtWZGRSS1RGS2RNcndjUHZXLys5UWNvR1N6RHhCN2FDUC9ORmRY?=
 =?utf-8?B?OGxnOUZlb2tGMkFuZmxDTzlqVVJJZ3hYVkkrZ0RBNitTbDFiTFVETEdpZDc0?=
 =?utf-8?Q?c2+FHcko3pU=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(7416014)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?bmJqOEVKWVMvZzBMSmg3cTcwYXExb1MvV2k1M2hUZXl5VUtWRVFoczM5cUk0?=
 =?utf-8?B?c1FvczJYcytMZ0NrMHpweHk3WXZZU0xhMGhIMkhIdThGeHdUbUlxUDIvL3RD?=
 =?utf-8?B?L2VmdnNIMTVSc3M1aGd0RnNmaDNYbzIxUC8rRmFkVldBakNGWUNwbjNnK3RZ?=
 =?utf-8?B?bHpjeDZIMTI5UzB5Q3Mrd0tSMmVXaG9GOS9nZWM0aUs3aW9oanROamkxYm94?=
 =?utf-8?B?TldBazFoeDVoN1JXSW0zeE1GNmZQcktPakM1SEhmcmNaT2RoMkh6NXF3cFZi?=
 =?utf-8?B?cTF4T2ZMWE5PLzBBcExZYThreFVDcVdjOU85djl2RGMvcDd6RzdkSkJGTkEr?=
 =?utf-8?B?elFJZ0RSTk1wcmMvWU91VnZvelJzWjNFSjRoU0hlOVJCT2UrMDZpeFJHVmta?=
 =?utf-8?B?bEI0bmgyK3RHdXJBYXYvYWpsSzdVSUtVR0NuNzlydGJ5WG11dzVRaXBLRS9L?=
 =?utf-8?B?WmJueU82T1ROeUl4VWplQ1BtWC9KWVZ1eUJ1SVJZUVJaM2M0eDJxN2pVUXMw?=
 =?utf-8?B?MCtyRFFHS2lFOGQ2ZUpCOEREV3NiYXRDZnNTUWdOUXpCWHE1WTBBM2h2T21h?=
 =?utf-8?B?TE9NQzdYWXhFYWxURE02RWVxYmYzcXJuUFZxU0JpRmZMakVvY1dSVWxDL1NI?=
 =?utf-8?B?NFk2VkFBVUgrVFlrdWYwRnRVR0laNjJ5cGFwbWJiQ3JkWUNSV04vaUI2czNC?=
 =?utf-8?B?cVY0N0FxNDgrNUxZNlhWRWNaRVNET1pMbTFpTFFQRXdZWC9RTXZuQkdxWThH?=
 =?utf-8?B?NHlOaXZiMDM2UG9ZLzVZN09DczA4UUJxeVAyajQxQ3U0MnBGdCs4U2RqaFRW?=
 =?utf-8?B?ekplcmo3RW1JWHhYTGVNLzNkdkNOS2hBaG5JanpYSUFrdlp1Yzh4TzNiMmg0?=
 =?utf-8?B?SkNpTHhma1k3ekVqZDhtOHBETVNXTTdQaW4rWGFYQndSUHlnSjhYZlJOcjZQ?=
 =?utf-8?B?UHV0L0tyVHk4TFA5eWFTdXJ6N25wMS9WZ3I0M0g0bnI0L0o2R1lZZzNXbzU2?=
 =?utf-8?B?eURtY2lQZUlDNE9OSFdLdTBkUVRybzZLOXJ1bi9TRStNWXBHVGxPMk1TdUR5?=
 =?utf-8?B?K3lkK1R3b1RaTkZTTVU2dmdmalRqVmlZRjBxVHFVM09YTmlVNWs3cEovYnF4?=
 =?utf-8?B?Z1l2S3ByMkNsWVZZVmc5eWk2aDRIRVVsdTBmQ1lGWnZzRHloYk1JOTl5ZVlr?=
 =?utf-8?B?NEovNkZ1QUhvS09vdlhWUFVMVjljMjBpSi9TR3ViSmdxemlQWnlOelpFT2NI?=
 =?utf-8?B?WWVsamtNTVZUSVRMNk42MWNYNUZzUmNnNjJLcGwrSHMvUmxzYlpmek1TWXQw?=
 =?utf-8?B?S0RONHI5ekRHdWR4RUxBTkQydzd5TWJrVDNDaHFqNWNVVHJXQjBxbmxYZHox?=
 =?utf-8?B?S3R0ME9oN0llVXNFY2ZqaCtVSnNidmxWUHBMay9Lb2tyUWRSUDBtSzlEVm8w?=
 =?utf-8?B?N2J1SUp4US8yZFpPcHREZitJTTdFSDEvM0dJRzFVbTUxbkNqUFVvZldweFVH?=
 =?utf-8?B?bTE3Nm5pL3RWTjVSNVpjVno5ZUp6cHJQOEpnT0JZN01qVHBwUU1lTnArYzdq?=
 =?utf-8?B?QW1PVVNNcU1LZnQvSGZYaFVYTVg0UnhMdnFwQkowKzN0RFBBV0pCSkI3eFBN?=
 =?utf-8?B?bTBBQW9CTGgrUEhMb3FLTHNuK3lodktENTZRZzZHbVluSTZwbklaV3Zib2pw?=
 =?utf-8?B?U1lWNzk4NlpvWDRFdWR6d0E1KzY0N2RSVVRadjR3MXlMYlJPTmhVTFRkc0pW?=
 =?utf-8?B?a3BURlI4QXAxMzliTzMvWks0cEQzRW56TTZlbG5Zdmx4dUh6WFl6RGRuamVn?=
 =?utf-8?B?QnlwUW9SYzVnTjgwZVNRcmVqQUVJdTBxMGY0NEZFUFg2OUpwV0QyYk9xU0xM?=
 =?utf-8?B?YUFjcDJ2V3E1TTR0QTgwaGFPSzRMWnUvVE5RdEJFV2p5K3BTZ1pkUFFvWVlB?=
 =?utf-8?B?RmcrYW9XYmpZY0dzNGtqUlBhU1U1aEx5ZlliNlZPUWFEQ2ZTMGtyODUwYWwz?=
 =?utf-8?B?MDdRQXBLN0dkdXBZayt5SUVNNG1VT1p5aUNjSmxTTEMrTmN5U2IyT0oyM09D?=
 =?utf-8?B?d0tvNmNtY1JTRkxlTnhpczBRK0Q3dURORDhFTVg4K0RKYVh6QWNpTTZoblJC?=
 =?utf-8?B?YTRsVXVKK280cnFEWXcwSCtBdG9wRm0za3kzdnZZUDlEZGZZaGg5dGlpS0Fx?=
 =?utf-8?B?eWc9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <0FED959BB8D4924193A58F82098FECF8@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: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 729d0c8e-8b25-4662-adea-08ddab4e9ef1
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2025 14:20:31.8605
 (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: vmNONtkOLpKxsx0xn6WAOo04+JHG1biPzzrymhm2uLDUI4WcajcHdIy29CHKbAHVBiwPwDJxE2+CFvYWxJ54+FmepT4/Kq2sUhokvy42HcQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR03MB8815

SGkgT2xla3NpaSwNCg0KUGxlYXNlIHNlZSBiZWxvdy4NCg0KT24gMDIvMDYvMjAyNSAxOTozNywg
T2xla3NpaSBLdXJvY2hrbyB3cm90ZToNCj4gSGVsbG8gZXZlcnlvbmUsDQo+DQo+IFRoaXMgZW1h
aWwgb25seSB0cmFja3MgYmlnIGl0ZW1zIGZvciB4ZW4uZ2l0IHRyZWUuIFBsZWFzZSByZXBseSBm
b3IgDQo+IGl0ZW1zIHlvdQ0KPiB3b3VsZCBsaWtlIHRvIHNlZSBpbiA0LjIxIHNvIHRoYXQgcGVv
cGxlIGhhdmUgYW4gaWRlYSB3aGF0IGlzIGdvaW5nIG9uIA0KPiBhbmQNCj4gcHJpb3JpdGlzZSBh
Y2NvcmRpbmdseS4NCj4NCj4gWW91J3JlIHdlbGNvbWUgdG8gcHJvdmlkZSBkZXNjcmlwdGlvbiBh
bmQgdXNlIGNhc2VzIG9mIHRoZSBmZWF0dXJlIHlvdSdyZQ0KPiB3b3JraW5nIG9uLg0KPg0KPiA9
IFRpbWVsaW5lID0NCj4NCj4gQXMgdGhlcmUgaGFzbid0IGJlZW4gYW55IGZlZWRiYWNrIG9uIHRo
ZSBwcm9wb3NlZCB0aW1lbGluZSBzaGFyZWQgaGVyZToNCj4gaHR0cHM6Ly9sb3JlLmtlcm5lbC5v
cmcveGVuLWRldmVsLzY2NmUzZjQ5LTJmOTItNDgyOC04ODk3LTg1Nzk4MzJiY2FhMkBnbWFpbC5j
b20vVC8jdSANCj4NCj4NCj4gV2UgY2FuIHByb2NlZWQgd2l0aCB0aGUgc3VnZ2VzdGVkIHRpbWVs
aW5lIGFzIHRoZSByZWxlYXNlIHNjaGVkdWxlIGZvciANCj4gWGVuIDQuMjEuDQo+IEkndmUgdXBk
YXRlZCB0aGUgWGVuIDQuMjEgUmVsZWFzZSBOb3RlcyB3aXRoIHRoaXMgc2NoZWR1bGUsIHdoaWNo
IGNhbiANCj4gbm93IGJlDQo+IGFjY2Vzc2VkIHZpYSB0aGUgUk4gbGluazoNCj4gwqAgaHR0cHM6
Ly94ZW5iaXRzLnhlbi5vcmcvZG9jcy91bnN0YWJsZS9zdXBwb3J0LW1hdHJpeC5odG1sDQo+DQo+
ID0gVXBkYXRlcyA9DQo+DQo+IFRoZSBmb2xsb3dpbmcgaXRlbXMgKCB0aGUgbGlua3MgZm9yIHRo
ZW0gY291bGQgYmUgZm91bmQgaW50IHRoZSBsaXN0IA0KPiBiZWxvdyApDQo+IHdlcmUgbW92ZWQg
dG8gY29tcGxldGVkOg0KPiDCoCBbc2luY2UgTWF5IDYgLSBKdW4yXToNCj4gwqDCoMKgICogSHlw
ZXJ2aXNvcjoNCj4gwqDCoMKgwqDCoCAtIHRvb2xzOiByZW1vdmUgcWVtdS10cmFkaXRpb25hbA0K
PiDCoMKgwqAgKiBBcm06DQo+IMKgwqDCoMKgwqAgLSBQQ0kgZGV2aWNlcyBwYXNzdGhyb3VnaCBv
biBBcm0sIHBhcnQgMw0KPiDCoMKgwqAgKiB4ODY6DQo+IMKgwqDCoMKgwqAgLSB4ZW46IGNhY2hl
IGNvbnRyb2wgaW1wcm92ZW1lbnRzDQo+IMKgIFtzaW5jZSA0LjIwIHJlbGVzZSAtIE1heSA2XToN
Cj4gwqDCoMKgICogSHlwZXJ2aXNvcjoNCj4gwqDCoMKgwqDCoCAtIE1vdmUgcGFydHMgb2YgQXJt
J3MgRG9tMGxlc3MgdG8gY29tbW9uIGNvZGUNCj4gwqDCoMKgwqDCoCAtIHJlbW92ZSBsaWJ4ZW5j
dHJsIHVzYWdlIGZyb20geGVuc3RvcmVkDQo+IMKgwqDCoCAqIEFybToNCj4gwqDCoMKgwqDCoCAt
IEVuYWJsZSBlYXJseSBib290dXAgb2YgQXJtdjgtUiBBQXJjaDMyIHN5c3RlbXMNCj4gwqDCoMKg
ICogeDg2Og0KPiDCoMKgwqDCoMKgIC0geDg2L0hWTTogZW11bGF0aW9uIChNTUlPKSBpbXByb3Zl
bWVudHMNCj4gwqDCoMKgICogUklTQy1WOg0KPiDCoMKgwqDCoMKgIC0gUklTQy1WIHNvbWUgcHJl
aW5pdCBjYWxscy4NCj4gwqDCoMKgwqDCoCAtIEZpeGVzIGZvciBVQlNBTiAmIEdDT1Ygc3VwcG9y
dCBmb3IgUklTQy1WLg0KPg0KPiBTb21lIG5ldyBpdGVtcyBhZGRlZDoNCj4gwqBbc2luY2UgTWF5
XQ0KPiDCoMKgwqAgKiB4ODY6DQo+IMKgwqDCoMKgIC0gQWxsb3cgeDg2IHRvIHVuZmxhdHRlbiBE
VHMNCj4gwqDCoMKgwqAgLSBoeXBlcmxhdW5jaDogbW92ZSByZW1haW5pbmcgcHZoIGRvbTAgY29u
c3RydWN0aW9uDQo+IMKgwqDCoMKgIC0geDg2L2h5cGVybGF1bmNoOiBpbnRyb2R1Y2UgY29uY2Vw
dCBvZiBjb3JlIGRvbWFpbnMNCj4gwqDCoMKgwqAgLSBDb25maWRlbnRpYWwgY29tcHV0aW5nIGFu
ZCBBTUQgU0VWIHN1cHBvcnQNCj4gwqDCoMKgICogQXJtOg0KPiDCoMKgwqDCoCAtIFNNTVUgaGFu
ZGxpbmcgZm9yIFBDSWUgUGFzc3Rocm91Z2ggb24gQVJNDQo+IMKgwqDCoMKgIC0geGVuL2FybTog
c2NtaTogaW50cm9kdWNlIFNDSSBTQ01JIFNNQyBtdWx0aS1hZ2VudCBzdXBwb3J0DQo+IMKgwqDC
oMKgIC0gQWRkIGluaXRpYWwgWGVuIFN1c3BlbmQtdG8tUkFNIHN1cHBvcnQgb24gQVJNNjQNCj4g
wqDCoMKgICogUklTQy1WOg0KPiDCoMKgwqDCoCAtIGludHJvZHVjZSBwMm0gZnVuY3Rpb25hbGl0
eQ0KPiDCoFtzaW5jZSA0LjIwIHJlbGVhc2VdDQo+IMKgwqDCoCAqIEh5cGVydmlzb3I6DQo+IMKg
wqDCoMKgwqAgLSB0b29sczogcmVtb3ZlIHFlbXUtdHJhZGl0aW9uYWwNCj4gwqDCoMKgwqDCoCAt
IFBoeXNpY2FsIGFkZHJlc3MgaHlwZXJjYWxsIEFCSSAoIkhWTXYyIikNCj4gwqDCoMKgwqDCoCAt
IHhlbjogVW50YW5nbGUgbW0uaA0KPiDCoMKgwqDCoMKgIC0geGVuOiBpbnRyb2R1Y2UgQ09ORklH
X1NZU0NUTA0KPiDCoMKgwqDCoMKgIC0gQWRkIHN1cHBvcnQgZm9yIGV4YWN0LW5vZGUgbWVtb3J5
IGNsYWltcw0KPiDCoMKgwqDCoMKgIC0gU2V2ZXJhbCBDSSBjbGVhbnVwcyBhbmQgaW1wcm92ZW1l
bnRzLCBwbHVzIHlldCBhbm90aGVyIG5ldyBydW5uZXINCj4gwqDCoMKgICogeDg2Og0KPiDCoMKg
wqDCoMKgIC0geDg2L0VGSTogcHJldmVudCB3cml0ZS1leGVjdXRlIHNlY3Rpb25zDQo+IMKgwqDC
oMKgwqAgLSB4ODY6IFRyZW5jaGJvb3QgU2VjdXJlIExhdW5jaCBEUlRNIChYZW4pDQo+IMKgwqDC
oMKgwqAgLSBIeXBlcmxhdW5jaCBkZXZpY2UgdHJlZSBmb3IgZG9tMCAodjYpDQo+IMKgwqDCoMKg
wqAgLSBhbWQtY3BwYyBDUFUgUGVyZm9ybWFuY2UgU2NhbGluZyBEcml2ZXIgKHY0KQ0KPiDCoMKg
wqDCoMKgIC0gSHlwZXJsYXVuY2ggZG9tYWluIGJ1aWxkZXINCj4gwqDCoMKgwqDCoCAtIGtleGVj
OiBhZGQga2V4ZWMgc3VwcG9ydCB0byBNaW5pLU9TDQo+IMKgwqDCoMKgwqAgLSB4ZW46IGNhY2hl
IGNvbnRyb2wgaW1wcm92ZW1lbnRzIChzaG91bGQgYmUgbW92ZWQgdG8gDQo+ICJIeXBlcnZpc29y
Ij8pDQo+IMKgwqDCoMKgwqAgLSB4ODY6IGdlbmVyYXRlIHhlbi5lZmkgaW1hZ2Ugd2l0aCBubyB3
cml0ZS1leGVjdXRlIHNlY3Rpb25zDQo+IMKgwqDCoMKgwqAgLSB4ODYvYXNtOiBjbGVhbnVwcyBh
ZnRlciB0b29sY2hhaW4gYmFzZWxpbmUgdXBncmFkZQ0KPiDCoMKgwqAgKiBBcm06DQo+IMKgwqDC
oMKgwqAgLSBBZGQgc3VwcG9ydCBmb3IgUi1DYXIgR2VuNCBQQ0kgaG9zdCBjb250cm9sbGVyICh2
NCkNCj4gwqDCoMKgwqDCoCAtIEZGLUEgVk0gdG8gVk0gc3VwcG9ydCAodjUpDQo+IMKgwqDCoMKg
wqAgLSBGaXJzdCBjaHVuayBmb3IgQXJtIFI4MiBhbmQgTVBVIHN1cHBvcnQgKHY0KQ0KPiDCoMKg
wqDCoMKgIC0gQVJNIHNwbGl0IGhhcmR3YXJlIGFuZCBjb250cm9sIGRvbWFpbnMgKHY1KQ0KPiDC
oMKgwqDCoMKgIC0gTVBVIG1tIHN1YnNpc3RlbSBza2VsZXRvbg0KPiDCoMKgwqAgKiBSSVNDLVY6
DQo+IMKgwqDCoMKgwqAgLSBpbnRyb2R1Y2UgYmFzaWMgVUFSVCBzdXBwb3J0IGFuZCBpbnRlcnJ1
cHRzIGZvciBoeXBlcnZpc29yIG1vZGUNCj4NCj4gKiBGdWxsIGxpc3Qgb2YgaXRlbXMgOiAqDQo+
DQo+ID0gUHJvamVjdHMgPQ0KPg0KPiA9PSBIeXBlcnZpc29yID09DQo+DQo+ICogeGVuL2NvbnNv
bGU6IGNsZWFudXAgY29uc29sZSBpbnB1dCBzd2l0Y2ggbG9naWMgKHYxIC0+IHY1KQ0KPiDCoCAt
IERlbmlzIE11a2hpbg0KPiDCoCAtIA0KPiBodHRwczovL2xvcmUua2VybmVsLm9yZy94ZW4tZGV2
ZWwvMjAyNTA1MzAyMzE4NDEuNzMzODYtMS1kbXVraGluQGZvcmQuY29tLw0KPiDCoCAtIGh0dHBz
Oi8vcGF0Y2hldy5vcmcvWGVuLzIwMjUwNTMwMjMxODQxLjczMzg2LTEtZG11a2hpbkBmb3JkLmNv
bS8NCj4NCj4gKiB4ZW46IGludHJvZHVjZSBDT05GSUdfU1lTQ1RMICh2MyAtPiB2NCkNCj4gwqAg
LcKgIFBlbm55IFpoZW5nDQo+IMKgIC0gDQo+IGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3hlbi1k
ZXZlbC8yMDI1MDUyODA5MTcwOC4zOTA3NjctMS1QZW5ueS5aaGVuZ0BhbWQuY29tLw0KPiDCoCAt
IGh0dHBzOi8vcGF0Y2hldy5vcmcvWGVuLzIwMjUwNTI4MDkxNzA4LjM5MDc2Ny0xLVBlbm55Llpo
ZW5nQGFtZC5jb20vDQo+DQo+ICogUGh5c2ljYWwgYWRkcmVzcyBoeXBlcmNhbGwgQUJJICgiSFZN
djIiKQ0KPiDCoCAtIFRlZGR5IEFzdGllDQo+IMKgIC0gDQo+IGh0dHBzOi8vbG9yZS5rZXJuZWwu
b3JnL3hlbi1kZXZlbC9jb3Zlci4xNzQ0OTgxNjU0LmdpdC50ZWRkeS5hc3RpZUB2YXRlcy50ZWNo
Lw0KPg0KPiAqIHhlbjogVW50YW5nbGUgbW0uaA0KPiDCoCAtwqAgQW5kcmV3IENvb3Blcg0KPiDC
oCAtIA0KPiBodHRwczovL2xvcmUua2VybmVsLm9yZy94ZW4tZGV2ZWwvMjAyNTAzMTIxNzQ1MTMu
NDA3NTA2Ni0xLWFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20vDQo+IMKgIC0gDQo+IGh0dHBzOi8v
cGF0Y2hldy5vcmcvWGVuLzIwMjUwMzEyMTc0NTEzLjQwNzUwNjYtMS1hbmRyZXcuY29vcGVyM0Bj
aXRyaXguY29tLw0KPg0KPiAqIEFkZCBzdXBwb3J0IGZvciBleGFjdC1ub2RlIG1lbW9yeSBjbGFp
bXMNCj4gwqAgLcKgIEFsZWphbmRybyBWYWxsZWpvDQo+IMKgIC0gDQo+IGh0dHBzOi8vbG9yZS5r
ZXJuZWwub3JnL3hlbi1kZXZlbC8yMDI1MDMxNDE3MjUwMi41MzQ5OC0xLWFsZWphbmRyby52YWxs
ZWpvQGNsb3VkLmNvbS8NCj4gwqAgLSANCj4gaHR0cHM6Ly9wYXRjaGV3Lm9yZy9YZW4vMjAyNTAz
MTQxNzI1MDIuNTM0OTgtMS1hbGVqYW5kcm8udmFsbGVqb0BjbG91ZC5jb20vDQo+DQo+ICogU2V2
ZXJhbCBDSSBjbGVhbnVwcyBhbmQgaW1wcm92ZW1lbnRzLCBwbHVzIHlldCBhbm90aGVyIG5ldyBy
dW5uZXINCj4gwqAgLSBNYXJlayBNYXJjenlrb3dza2ktR8OzcmVja2kNCj4gwqAgLSANCj4gaHR0
cHM6Ly9sb3JlLmtlcm5lbC5vcmcveGVuLWRldmVsL2NvdmVyLjdkYTE3Nzc4ODI3NzQ0ODZhMTNl
NmYzOWZmNGEyMDk2ZjZiNzkwMWUuMTc0NDAyODU0OS5naXQtc2VyaWVzLm1hcm1hcmVrQGludmlz
aWJsZXRoaW5nc2xhYi5jb20vDQo+IMKgIC0gDQo+IGh0dHBzOi8vcGF0Y2hldy5vcmcvWGVuL2Nv
dmVyLjdkYTE3Nzc4ODI3NzQ0ODZhMTNlNmYzOWZmNGEyMDk2ZjZiNzkwMWUuMTc0NDAyODU0OS5n
aXQtc2VyaWVzLm1hcm1hcmVrQGludmlzaWJsZXRoaW5nc2xhYi5jb20vDQo+DQo+ICrCoCBSZW1v
dmUgdGhlIGRpcmVjdG1hcCAodjUpDQo+IMKgIC3CoCBBbGVqYW5kcm8gVmFsbGVqbw0KPiDCoCAt
IA0KPiBodHRwczovL2xvcmUua2VybmVsLm9yZy94ZW4tZGV2ZWwvMjAyNTAxMDgxNTE4MjIuMTYw
MzAtMS1hbGVqYW5kcm8udmFsbGVqb0BjbG91ZC5jb20vDQo+IMKgIC0gDQo+IGh0dHBzOi8vcGF0
Y2hldy5vcmcvWGVuLzIwMjUwMTA4MTUxODIyLjE2MDMwLTEtYWxlamFuZHJvLnZhbGxlam9AY2xv
dWQuY29tLw0KPg0KPiAqwqAgYXV0b21hdGlvbjogUmVmcmVzaCB0aGUgcmVtYWluaW5nIERlYmlh
biBjb250YWluZXJzICh2MikNCj4gwqAgLcKgIEphdmkgTWVyaW5vDQo+IMKgIC0gDQo+IGh0dHBz
Oi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZlbC9jb3Zlci4xNzMwNzQzMDc3LmdpdC5qYXZpLm1l
cmlub0BjbG91ZC5jb20vVC8jbTVkOWFjYjdjZjVkYjNjMmJlM2Q2NTI3ZGUxNGI2OWIwNzgxMjMx
NGUNCj4NCj4gKsKgIEdSVUI6IFN1cHBvcnRpbmcgU2VjdXJlIEJvb3Qgb2YgeGVuLmd6ICh2MSkN
Cj4gwqAgLcKgIFJvc3MgTGFnZXJ3YWxsDQo+IMKgIC0gDQo+IGh0dHBzOi8vcGF0Y2hldy5vcmcv
WGVuLzIwMjQwMzEzMTUwNzQ4Ljc5MTIzNi0xLXJvc3MubGFnZXJ3YWxsQGNpdHJpeC5jb20vDQo+
DQo+ICrCoCBNU0ktWCBzdXBwb3J0IHdpdGggcWVtdSBpbiBzdHViZG9tYWluLCBhbmQgb3RoZXIg
cmVsYXRlZCBjaGFuZ2VzICh2OCkNCj4gwqAgLcKgIE1hcmVrIE1hcmN6eWtvd3NraS1Hw7NyZWNr
aQ0KPiDCoCAtIA0KPiBodHRwczovL2xvcmUua2VybmVsLm9yZy94ZW4tZGV2ZWwvY292ZXIuMzNm
YjQzODViN2RkNmM1M2JkYTRhY2YwYTllOTE3NDhiM2Q3YjFmNy4xNzE1MzEzMTkyLmdpdC1zZXJp
ZXMubWFybWFyZWtAaW52aXNpYmxldGhpbmdzbGFiLmNvbS8NCj4gwqAgLcKgIE9ubHkgYXV0b21h
dGlvbiBwYXRjaCBsZWZ0IHRvIGJlIHJldmlld2VkL21lcmdlZC4NCj4NCj4gKsKgIFtSRkNdIElu
dHJvZHVjZSB4ZW5iaW5kZ2VuIHRvIGF1dG9nZW4gaHlwZXJjYWxsIHN0cnVjdHMgKHYxKQ0KPiDC
oCAtwqAgQWxlamFuZHJvIFZhbGxlam8NCj4gwqAgLSANCj4gaHR0cHM6Ly9wYXRjaGV3Lm9yZy9Y
ZW4vMjAyNDExMTUxMTUyMDAuMjgyNC0xLWFsZWphbmRyby52YWxsZWpvQGNsb3VkLmNvbS8NCj4N
Cj4gKsKgIEludHJvZHVjZSBOUzgyNTAgVUFSVCBlbXVsYXRvciAodjIpDQo+IMKgIC3CoCBEZW5p
cyBNdWtoaW4NCj4gwqAgLSANCj4gaHR0cHM6Ly9wYXRjaGV3Lm9yZy9YZW4vMjAyNDEyMDUtdnVh
cnQtbnM4MjUwLXYxLTAtZTlhYTkyMzEyN2ViQGZvcmQuY29tLw0KPg0KPiA9PT0geDg2ID09PQ0K
Pg0KPiAqIEFsbG93IHg4NiB0byB1bmZsYXR0ZW4gRFRzDQo+IMKgIC0gQWxlamFuZHJvIFZhbGxl
am8NCj4gwqAgLSANCj4gaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcveGVuLWRldmVsLzIwMjUwNTMw
MTIwMjQyLjM5Mzk4LTEtYWdhcmNpYXZAYW1kLmNvbS8NCj4gwqAgLSBodHRwczovL3BhdGNoZXcu
b3JnL1hlbi8yMDI1MDUzMDEyMDI0Mi4zOTM5OC0xLWFnYXJjaWF2QGFtZC5jb20vDQo+DQo+ICog
aHlwZXJsYXVuY2g6IG1vdmUgcmVtYWluaW5nIHB2aCBkb20wIGNvbnN0cnVjdGlvbiAodjIpDQo+
IMKgIC0gRGFuaWVsIFAuIFNtaXRoDQo+IMKgIC0gDQo+IGh0dHBzOi8vbG9yZS5rZXJuZWwub3Jn
L3hlbi1kZXZlbC8yMDI1MDUxNTEzMTkxMi41MDE5LTEtZHBzbWl0aEBhcGVydHVzc29sdXRpb25z
LmNvbS8NCj4NCj4gKiB4ODYvaHlwZXJsYXVuY2g6IGludHJvZHVjZSBjb25jZXB0IG9mIGNvcmUg
ZG9tYWlucyAodjIpDQo+IMKgIC0gRGFuaWVsIFAuIFNtaXRoDQo+IMKgIC0gDQo+IGh0dHBzOi8v
bG9yZS5rZXJuZWwub3JnL3hlbi1kZXZlbC8yMDI1MDUxNTEzMTk1MS41NTk0LTEtZHBzbWl0aEBh
cGVydHVzc29sdXRpb25zLmNvbS8NCj4NCj4gKiBDb25maWRlbnRpYWwgY29tcHV0aW5nIGFuZCBB
TUQgU0VWIHN1cHBvcnQNCj4gwqAgLSBUZWRkeSBBc3RpZQ0KPiDCoCAtIGh0dHBzOi8vcGF0Y2hl
dy5vcmcvWGVuL2NvdmVyLjE3NDczMTIzOTQuZ2l0LnRlZGR5LmFzdGllQHZhdGVzLnRlY2gvDQo+
IMKgIC0gDQo+IGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZlbC9jb3Zlci4xNzQ3MzEy
Mzk0LmdpdC50ZWRkeS5hc3RpZUB2YXRlcy50ZWNoLw0KPg0KPiAqIHg4Ni9lZmk6IEZpeCBib290
aW5nIHdoZW4gTlggaXMgZGlzYWJsZWQgKHYxIC0+IHYyKQ0KPiDCoCAtIEFuZHJldyBDb29wZXIN
Cj4gwqAgLSANCj4gaHR0cHM6Ly9wYXRjaGV3Lm9yZy9YZW4vMjAyNDA3MjIxMDE4MzguMzk0Njk4
My0xLWFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20vDQo+IMKgIC0gDQo+IGh0dHBzOi8vbG9yZS5r
ZXJuZWwub3JnL3hlbi1kZXZlbC8yMDI0MDcyMjEwMTgzOC4zOTQ2OTgzLTEtYW5kcmV3LmNvb3Bl
cjNAY2l0cml4LmNvbS8NCj4NCj4gKiB4ODYvYXNtOiBjbGVhbnVwcyBhZnRlciB0b29sY2hhaW4g
YmFzZWxpbmUgdXBncmFkZSAodjEgLT4gdjIpDQo+IMKgIC0gRGVuaXMgTXVraGluDQo+IMKgIC0g
DQo+IGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZlbC8yMDI1MDQwMzE4MjI1MC4zMzI5
NDk4LTEtZG11a2hpbkBmb3JkLmNvbS8NCj4gwqAgLSBodHRwczovL3BhdGNoZXcub3JnL1hlbi8y
MDI1MDQwMzE4MjI1MC4zMzI5NDk4LTEtZG11a2hpbkBmb3JkLmNvbS8NCj4NCj4gKiBhbWQtY3Bw
YyBDUFUgUGVyZm9ybWFuY2UgU2NhbGluZyBEcml2ZXIgKHY0IC0+IHY1KQ0KPiDCoCAtIFBlbm55
IFpoZW5nDQo+IMKgIC0gDQo+IGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZlbC8yMDI1
MDUyNzA4NDgzMy4zMzg0MjctMS1QZW5ueS5aaGVuZ0BhbWQuY29tLw0KPiDCoCAtIGh0dHBzOi8v
cGF0Y2hldy5vcmcvWGVuLzIwMjUwNDE0MDc0MDU2LjM2OTY4ODgtMS1QZW5ueS5aaGVuZ0BhbWQu
Y29tLw0KPg0KPiAqIHg4NjogVHJlbmNoYm9vdCBTZWN1cmUgTGF1bmNoIERSVE0gKFhlbikgKHYx
IC0+IHYzKQ0KPiDCoCAtIFNlcmdpaSBEbXl0cnVrDQo+IMKgIC0gDQo+IGh0dHBzOi8vcGF0Y2hl
dy5vcmcvWGVuL2NvdmVyLjE3NDUxNzIwOTQuZ2l0LnNlcmdpaS5kbXl0cnVrQDNtZGViLmNvbS8N
Cj4gwqAgLSANCj4gaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcveGVuLWRldmVsL2NvdmVyLjE3NDg2
MTEwNDEuZ2l0LnNlcmdpaS5kbXl0cnVrQDNtZGViLmNvbS8NCj4NCj4gKiB4ODYvRUZJOiBwcmV2
ZW50IHdyaXRlLWV4ZWN1dGUgc2VjdGlvbnMNCj4gwqAgLSBSb2dlciBQYXUgTW9ubmUgPHJvZ2Vy
LnBhdUBjaXRyaXguY29tPg0KPiDCoCAtIA0KPiBodHRwczovL2xvcmUua2VybmVsLm9yZy94ZW4t
ZGV2ZWwvMjAyNTA0MDExMzA4NDAuNzIxMTktMS1yb2dlci5wYXVAY2l0cml4LmNvbS8NCj4NCj4g
KiBIeXBlcmxhdW5jaCBkZXZpY2UgdHJlZSBmb3IgZG9tMCAodjYpDQo+IMKgIC0gQWxlamFuZHJv
IFZhbGxlam8NCj4gwqAgLSBodHRwczovL3BhdGNoZXcub3JnL1hlbi8yMDI1MDQyOTEyMzYyOS4y
MDgzOS0xLWFnYXJjaWF2QGFtZC5jb20vDQo+IMKgIC0gDQo+IGh0dHBzOi8vbG9yZS5rZXJuZWwu
b3JnL3hlbi1kZXZlbC8yMDI1MDQyOTEyMzYyOS4yMDgzOS0xLWFnYXJjaWF2QGFtZC5jb20vDQo+
DQo+ICogSHlwZXJsYXVuY2ggZG9tYWluIGJ1aWxkZXINCj4gwqAgLSBEYW5pZWwgUC4gU21pdGgN
Cj4gwqAgLSANCj4gaHR0cHM6Ly9wYXRjaGV3Lm9yZy9YZW4vMjAyNTA0MTkyMjA4MjAuNDIzNC0x
LWRwc21pdGhAYXBlcnR1c3NvbHV0aW9ucy5jb20vDQo+DQo+ICoga2V4ZWM6IGFkZCBrZXhlYyBz
dXBwb3J0IHRvIE1pbmktT1MNCj4gwqAgLSBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+
DQo+IMKgIC0gDQo+IGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZlbC8yMDI1MDMyMTA5
MjQ1MS4xNzMwOS0xLWpncm9zc0BzdXNlLmNvbS8NCj4NCj4gKiB4ODY6IGdlbmVyYXRlIHhlbi5l
ZmkgaW1hZ2Ugd2l0aCBubyB3cml0ZS1leGVjdXRlIHNlY3Rpb25zDQo+IMKgIC0gUm9nZXIgUGF1
IE1vbm5lDQo+IMKgIC0gDQo+IGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZlbC8yMDI1
MDMxODE3MzU0Ny41OTQ3NS0xLXJvZ2VyLnBhdUBjaXRyaXguY29tLw0KPg0KPiAqwqAgRXhwb3Nl
IGNvbnNpc3RlbnQgdG9wb2xvZ3kgdG8gZ3Vlc3RzICh2NykNCj4gwqAgLcKgIEFsZWphbmRybyBW
YWxsZWpvDQo+IMKgIC0gDQo+IGh0dHBzOi8vcGF0Y2hldy5vcmcvWGVuLzIwMjQxMDIxMTU0NjAw
LjExNzQ1LTEtYWxlamFuZHJvLnZhbGxlam9AY2xvdWQuY29tLw0KPg0KPiAqwqAgQm9vdCBtb2R1
bGVzIGZvciBIeXBlcmxhdW5jaCAodjkpDQo+IMKgIC3CoCBEYW5pZWwgUC4gU21pdGgNCj4gwqAg
LSANCj4gaHR0cHM6Ly9wYXRjaGV3Lm9yZy9YZW4vMjAyNDExMTUxMzEyMDQuMzIxMzUtMS1kcHNt
aXRoQGFwZXJ0dXNzb2x1dGlvbnMuY29tLw0KPg0KPiAqwqAgQWRkcmVzcyBTcGFjZSBJc29sYXRp
b24gRlBVIHByZXBhcmF0aW9ucyAodjItPnYzKQ0KPiDCoCAtwqAgQWxlamFuZHJvIFZhbGxlam8N
Cj4gwqAgLSANCj4gaHR0cHM6Ly9wYXRjaGV3Lm9yZy9YZW4vMjAyNTAxMTAxMzI4MjMuMjQzNDgt
MS1hbGVqYW5kcm8udmFsbGVqb0BjbG91ZC5jb20vDQo+DQo+ICrCoCB4ODYvYWx0ZXJuYXRpdmVz
OiBBZGp1c3QgYWxsIGluc24tcmVsYXRpdmUgZmllbGRzICh2MikNCj4gwqAgLcKgIEFuZHJldyBD
b29wZXINCj4gwqAgLSANCj4gaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcveGVuLWRldmVsLzIwMjQx
MDAyMTUyNzI1LjE4NDE1NzUtMS1hbmRyZXcuY29vcGVyM0BjaXRyaXguY29tL1QvI21hYzJkZWFl
YTdlMDJhMzQzMjEwZDYxODg3NDg2NDMzZDk0NmFkMTI5DQo+DQo+ICrCoCB4ODZlbXVsOiBtaXNj
IGFkZGl0aW9ucyAodjcpDQo+IMKgIC3CoCBKYW4gQmV1bGljaA0KPiDCoCAtIA0KPiBodHRwczov
L3BhdGNoZXcub3JnL1hlbi8zYTI1Y2Q1OS1lMWNiLTRiZmMtYjg2OC1mYjExNTk5ZDIyZjVAc3Vz
ZS5jb20vDQo+DQo+ICrCoCB4ODY6IHN1cHBvcnQgQVZYMTAgKHYzKQ0KPiDCoCAtwqAgSmFuIEJl
dWxpY2gNCj4gwqAgLSANCj4gaHR0cHM6Ly9wYXRjaGV3Lm9yZy9YZW4vNTE2YjdmOWEtMDQ4ZS00
MDlkLThhNGUtODlhZWI4ZmZhY2M0QHN1c2UuY29tLw0KPg0KPiAqwqAgVlQtZDogU0FUQyBoYW5k
bGluZzsgQVRTOiB0aWR5aW5nICh2MikNCj4gwqAgLcKgIEphbiBCZXVsaWNoDQo+IMKgIC0gDQo+
IGh0dHBzOi8vcGF0Y2hldy5vcmcvWGVuLzY0YjAyOGJlLTIxOTctNDk1MS1hZTViLTMyZjllYWJm
YTg0YUBzdXNlLmNvbS8NCj4NCj4gKsKgIHg4NjogcGFyYWxsZWxpemUgQVAgYnJpbmctdXAgZHVy
aW5nIGJvb3QgKHYxKQ0KPiDCoCAtwqAgS3J5c3RpYW4gSGViZWwNCj4gwqAgLSANCj4gaHR0cHM6
Ly9sb3JlLmtlcm5lbC5vcmcveGVuLWRldmVsL2NvdmVyLjE2OTk5ODIxMTEuZ2l0LmtyeXN0aWFu
LmhlYmVsQDNtZGViLmNvbS8NCj4NCj4gKsKgIHg4Ni9zcGVjLWN0cmw6IElCUEIgaW1wcm92ZW1l
bnRzICh2NCkNCj4gwqAgLcKgIEphbiBCZXVsaWNoDQo+IMKgIC0gDQo+IGh0dHBzOi8vcGF0Y2hl
dy5vcmcvWGVuLzA2NTkxYjY0LTJmMDUtYTRjYy1hMmYzLWE3NGMzYzRhNzZkNkBzdXNlLmNvbS8N
Cj4NCj4gKsKgIE1vdmUgc29tZSBib290IGNvZGUgZnJvbSBhc3NlbWJseSB0byBDICh2MikNCj4g
wqAgLcKgIEZyZWRpYW5vIFppZ2xpbw0KPiDCoCAtIA0KPiBodHRwczovL3BhdGNoZXcub3JnL1hl
bi8yMDI0MTEyMjA5MzM1OC40Nzg3NzQtMS1mcmVkaWFuby56aWdsaW9AY2xvdWQuY29tLw0KPg0K
PiAqwqAgeDg2OiBtZW1jcHkoKSAvIG1lbXNldCgpIChub24tKUVSTVMgZmxhdm9ycyBwbHVzIGZh
bGxvdXQgKHY0KQ0KPiDCoCAtwqAgSmFuIEJldWxpY2gNCj4gwqAgLSANCj4gaHR0cHM6Ly9wYXRj
aGV3Lm9yZy9YZW4vMTRiNjUyMzEtYjgzYi00M2ZiLWJiY2YtZGVjNWMwN2QyODViQHN1c2UuY29t
Lw0KPg0KPiAqwqAgYW1kLXBzdGF0ZSBDUFUgUGVyZm9ybWFuY2UgU2NhbGluZyBEcml2ZXIgKHYx
KQ0KPiDCoCAtwqAgUGVubnkgWmhlbmcNCj4gwqAgLSBodHRwczovL3BhdGNoZXcub3JnL1hlbi8y
MDI0MTIwMzA4MTExMS40NjM0MDAtMS1QZW5ueS5aaGVuZ0BhbWQuY29tLw0KPg0KPiA9PT0gQVJN
ID09PQ0KPg0KPiAqIFNNTVUgaGFuZGxpbmcgZm9yIFBDSWUgUGFzc3Rocm91Z2ggb24gQVJNICh2
MTEpDQo+IMKgIC0gTXlreXRhIFBvdHVyYWkNCj4gwqAgLSANCj4gaHR0cHM6Ly9sb3JlLmtlcm5l
bC5vcmcveGVuLWRldmVsL2NvdmVyLjE3NDE5NTg2NDcuZ2l0Lm15a3l0YV9wb3R1cmFpQGVwYW0u
Y29tLw0KPiDCoCAtIA0KPiBodHRwczovL3BhdGNoZXcub3JnL1hlbi9jb3Zlci4xNzQ4NDIyMjE3
LmdpdC5teWt5dGEuXzVGcG90dXJhaUBlcGFtLmNvbS8NCj4NCj4gKiB4ZW4vYXJtOiBzY21pOiBp
bnRyb2R1Y2UgU0NJIFNDTUkgU01DIG11bHRpLWFnZW50IHN1cHBvcnQNCj4gwqAgLSBHcnlnb3Jp
aSBTdHJhc2hrbw0KPiDCoCAtIA0KPiBodHRwczovL2xvcmUua2VybmVsLm9yZy94ZW4tZGV2ZWwv
MjAyNTAzMTExMTE2MTguMTg1MDkyNy0xLWdyeWdvcmlpX3N0cmFzaGtvQGVwYW0uY29tLw0KPg0K
SSBjb25maXJtIHRoYXQgdGhlcmUgYXJlIHBsYW5zIHRvIGludHJvZHVjZSBTQ0kgU0NNSSBTTUMg
bXVsdGktYWdlbnQgDQpzdXBwb3J0IGluIDQuMjEuDQoNCg0KVGhlIFY0IHBhdGNoIHNlcmllcyBo
YXMgYWxyZWFkeSBiZWVuIHBvc3RlZDoNCg0KaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcveGVuLWRl
dmVsL2NvdmVyLjE3NDc2Njk4NDUuZ2l0Lm9sZWtzaWlfbW9pc2llaWV2QGVwYW0uY29tLw0KDQoN
CkJlc3QgcmVnYXJkcywNCg0KT2xla3NpaQ0KDQo+ICogQWRkIGluaXRpYWwgWGVuIFN1c3BlbmQt
dG8tUkFNIHN1cHBvcnQgb24gQVJNNjQgKHY0KQ0KPiDCoCAtIE15a29sYSBLdmFjaA0KPiDCoCAt
IA0KPiBodHRwczovL2xvcmUua2VybmVsLm9yZy94ZW4tZGV2ZWwvY292ZXIuMTc0MTE2NDEzOC5n
aXQueGFrZXAuYW1hdG9wQGdtYWlsLmNvbS8NCj4gwqAgLSANCj4gaHR0cHM6Ly9wYXRjaGV3Lm9y
Zy9YZW4vY292ZXIuMTc0ODg0ODQ4Mi5naXQubXlrb2xhLl81Rmt2YWNoQGVwYW0uY29tLw0KPg0K
PiAqIEFkZCBzdXBwb3J0IGZvciBSLUNhciBHZW40IFBDSSBob3N0IGNvbnRyb2xsZXIgKHY0IC0+
IHY1KQ0KPiDCoCAtIE15a3l0YSBQb3R1cmFpDQo+IMKgIC0gDQo+IGh0dHBzOi8vbG9yZS5rZXJu
ZWwub3JnL3hlbi1kZXZlbC9jb3Zlci4xNzQ3ODIwODQ0LmdpdC5teWt5dGFfcG90dXJhaUBlcGFt
LmNvbS8NCj4gwqAgLSANCj4gaHR0cHM6Ly9wYXRjaGV3Lm9yZy9YZW4vY292ZXIuMTc0NzgyMDg0
NC5naXQubXlreXRhLl81RnBvdHVyYWlAZXBhbS5jb20vDQo+DQo+ICogRkYtQSBWTSB0byBWTSBz
dXBwb3J0ICh2NSAtPiB2NikNCj4gwqAgLSBCZXJ0cmFuZCBNYXJxdWlzIDxiZXJ0cmFuZC5tYXJx
dWlzQGFybS5jb20+DQo+IMKgIC0gDQo+IGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZl
bC9jb3Zlci4xNzQ3OTI1Mjg3LmdpdC5iZXJ0cmFuZC5tYXJxdWlzQGFybS5jb20vDQo+IMKgIC0g
DQo+IGh0dHBzOi8vcGF0Y2hldy5vcmcvWGVuL2NvdmVyLjE3NDc5MjUyODcuZ2l0LmJlcnRyYW5k
Lm1hcnF1aXNAYXJtLmNvbS8NCj4NCj4gKiBGaXJzdCBjaHVuayBmb3IgQXJtIFI4MiBhbmQgTVBV
IHN1cHBvcnQgKHY0IC0+IHY2KQ0KPiDCoCAtIEx1Y2EgRmFuY2VsbHUNCj4gwqAgLSANCj4gaHR0
cHM6Ly9sb3JlLmtlcm5lbC5vcmcveGVuLWRldmVsLzIwMjUwNTIzMDY1NDA2LjM3OTU0MjAtMS1s
dWNhLmZhbmNlbGx1QGFybS5jb20vDQo+IMKgIC0gDQo+IGh0dHBzOi8vcGF0Y2hldy5vcmcvWGVu
LzIwMjUwNTIzMDY1NDA2LjM3OTU0MjAtMS1sdWNhLmZhbmNlbGx1QGFybS5jb20vDQo+DQo+ICog
QVJNIHNwbGl0IGhhcmR3YXJlIGFuZCBjb250cm9sIGRvbWFpbnMgKHY1KQ0KPiDCoCAtIEphc29u
IEFuZHJ5dWsNCj4gwqAgLSANCj4gaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcveGVuLWRldmVsLzIw
MjUwNDE2MjEyOTExLjQxMDk0Ni0xLWphc29uLmFuZHJ5dWtAYW1kLmNvbS8NCj4gwqAgLSANCj4g
aHR0cHM6Ly9wYXRjaGV3Lm9yZy9YZW4vMjAyNTA0MTYyMTI5MTEuNDEwOTQ2LTEtamFzb24uYW5k
cnl1a0BhbWQuY29tLw0KPg0KPiAqIE1QVSBtbSBzdWJzaXN0ZW0gc2tlbGV0b24NCj4gwqAgLSBM
dWNhIEZhbmNlbGx1DQo+IMKgIC0gDQo+IGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZl
bC8yMDI1MDMxMjEzNTI1OC4xODE1NzA2LTEtbHVjYS5mYW5jZWxsdUBhcm0uY29tLw0KPiDCoCAt
IA0KPiBodHRwczovL3BhdGNoZXcub3JnL1hlbi8yMDI1MDMxMjEzNTI1OC4xODE1NzA2LTEtbHVj
YS5mYW5jZWxsdUBhcm0uY29tLw0KPg0KPiAqwqAgQWRkIFZpcnRpby1QQ0kgZm9yIGRvbTBsZXNz
IG9uIEFSTSAodjEpDQo+IMKgIC3CoCBFZGdhciBFLiBJZ2xlc2lhcw0KPiDCoCAtIA0KPiBodHRw
czovL2xvcmUua2VybmVsLm9yZy94ZW4tZGV2ZWwvMjAyNDA5MjQxNjIzNTkuMTM5MDQ4Ny0xLWVk
Z2FyLmlnbGVzaWFzQGdtYWlsLmNvbS9ULyNtZmExNDg5OTFiOTQwOGYyMjNhMDc5ZDRjZWY2MTAy
NDRkNWIwNGMyYg0KPiDCoCAtIA0KPiBodHRwczovL3BhdGNoZXcub3JnL1hlbi8yMDI0MDkyNDE2
MjM1OS4xMzkwNDg3LTEtZWRnYXIuaWdsZXNpYXNAZ21haWwuY29tLw0KPg0KPiAqwqAgRE9NQ1RM
LWJhc2VkIGd1ZXN0IG1hZ2ljIHJlZ2lvbiBhbGxvY2F0aW9uIGZvciAxMSBkb21VcyAodjQpDQo+
IMKgIC3CoCBIZW5yeSBXYW5nDQo+IMKgIC0gaHR0cHM6Ly9wYXRjaGV3Lm9yZy9YZW4vMjAyNDA0
MDkwNDUzNTcuMjM2ODAyLTEteGluLndhbmcyQGFtZC5jb20vDQo+DQo+ID09PSBSSVNDViA9PT0N
Cj4NCj4gKiByaXNjdjogaW50cm9kdWNlIGJhc2ljIFVBUlQgc3VwcG9ydCBhbmQgaW50ZXJydXB0
cyBmb3IgaHlwZXJ2aXNvciANCj4gbW9kZSAodjIgLT4gdjMpDQo+IMKgIC3CoCBPbGVrc2lpIEt1
cm9jaGtvDQo+IMKgIC0gDQo+IGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZlbC9jb3Zl
ci4xNzQ3ODQzMDA5LmdpdC5vbGVrc2lpLmt1cm9jaGtvQGdtYWlsLmNvbS8NCj4gwqAgLSANCj4g
aHR0cHM6Ly9wYXRjaGV3Lm9yZy9YZW4vY292ZXIuMTc0Nzg0MzAwOS5naXQub2xla3NpaS5rdXJv
Y2hrb0BnbWFpbC5jb20vDQo+DQo+ICogeGVuL3Jpc2N2OiBpbnRyb2R1Y2UgcDJtIGZ1bmN0aW9u
YWxpdHkgKHYxKQ0KPiDCoCAtIE9sZWtzaWkgS3Vyb2Noa28NCj4gwqAgLSANCj4gaHR0cHM6Ly9s
b3JlLmtlcm5lbC5vcmcveGVuLWRldmVsL2NvdmVyLjE3NDY4MDU5MDcuZ2l0Lm9sZWtzaWkua3Vy
b2Noa29AZ21haWwuY29tLw0KPiDCoCAtIA0KPiBodHRwczovL3BhdGNoZXcub3JnL1hlbi9jb3Zl
ci4xNzQ2ODA1OTA3LmdpdC5vbGVrc2lpLmt1cm9jaGtvQGdtYWlsLmNvbS8NCj4NCj4gPT09IFBQ
QyA9PT0NCj4NCj4gKsKgIEVhcmx5IEJvb3QgQWxsb2NhdGlvbiBvbiBQb3dlciAodjUpDQo+IMKg
IC3CoCBTaGF3biBBbmFzdGFzaW8NCj4gwqAgLSANCj4gaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcv
eGVuLWRldmVsL2NvdmVyLjE3MjczODg5MjUuZ2l0LnNhbmFzdGFzaW9AcmFwdG9yZW5naW5lZXJp
bmcuY29tL1QvI204Y2FjOTFhOTNiNTZhMzU5ZmEyZDVmMDg1OTZjNGJlNjFkY2EyOTBkDQo+IMKg
IC0gDQo+IGh0dHBzOi8vcGF0Y2hldy5vcmcvWGVuL2NvdmVyLjE3MjczODg5MjUuZ2l0LnNhbmFz
dGFzaW9AcmFwdG9yZW5naW5lZXJpbmcuY29tLw0KPg0KPiA9PSBDb21wbGV0ZWQgPT0NCj4NCj4g
PT09IEh5cGVydmlzb3IgPT09DQo+DQo+ICogdG9vbHM6IHJlbW92ZSBxZW11LXRyYWRpdGlvbmFs
DQo+IMKgIC0gSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1c2UuY29tPg0KPiDCoCAtIA0KPiBodHRw
czovL2xvcmUua2VybmVsLm9yZy94ZW4tZGV2ZWwvMjAyNTA1MjcxMzIwMzUuOTg1LTEtamdyb3Nz
QHN1c2UuY29tLw0KPg0KPiAqwqAgcmVtb3ZlIGxpYnhlbmN0cmwgdXNhZ2UgZnJvbSB4ZW5zdG9y
ZWQgKHY4KQ0KPiDCoCAtwqAgSnVlcmdlbiBHcm9zcw0KPiDCoCAtIA0KPiBodHRwczovL2xvcmUu
a2VybmVsLm9yZy94ZW4tZGV2ZWwvMjAyNTAyMDQxMTM0MDcuMTY4MzktMS1qZ3Jvc3NAc3VzZS5j
b20vDQo+DQo+ICogeGVuL2NvbmZpZy5oOiBNb3ZlIEJJVFNfUEVSXyogZGVmaW5pdGlvbnMgZnJv
bSBhc20vY29uZmlnLmggdG8gDQo+IHhlbi9jb25maWcuaA0KPiDCoCAtIE9sZWtzaWkgS3Vyb2No
a28NCj4gwqAgLSANCj4gaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcveGVuLWRldmVsLzZiMjFmYjA0
NmNmMWM4Y2E3NjBmNWFkNzJmYTNjYzEzYjU5YzQwNjkuMTc0MzA5MjQ4NS5naXQub2xla3NpaS5r
dXJvY2hrb0BnbWFpbC5jb20vDQo+DQo+ICogTW92ZSBwYXJ0cyBvZiBBcm0ncyBEb20wbGVzcyB0
byBjb21tb24gY29kZQ0KPiDCoCAtwqAgT2xla3NpaSBLdXJvY2hrbw0KPiDCoCAtIA0KPiBodHRw
czovL3BhdGNoZXcub3JnL1hlbi9jb3Zlci4xNzQ2NDY4MDAzLmdpdC5vbGVrc2lpLmt1cm9jaGtv
QGdtYWlsLmNvbS8NCj4gwqAgLSANCj4gaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcveGVuLWRldmVs
L2NvdmVyLjE3NDY0NjgwMDMuZ2l0Lm9sZWtzaWkua3Vyb2Noa29AZ21haWwuY29tL1QvI3QNCj4N
Cj4gPT09IHg4NiA9PT0NCj4NCj4gKiB4ZW46IGNhY2hlIGNvbnRyb2wgaW1wcm92ZW1lbnRzDQo+
IMKgIC0gUm9nZXIgUGF1IE1vbm5lDQo+IMKgIC0gDQo+IGh0dHBzOi8vbG9yZS5rZXJuZWwub3Jn
L3hlbi1kZXZlbC8yMDI1MDUwNjA4MzE0OC4zNDk2My0xLXJvZ2VyLnBhdUBjaXRyaXguY29tLw0K
Pg0KPiAqwqAgeDg2L0hWTTogZW11bGF0aW9uIChNTUlPKSBpbXByb3ZlbWVudHMgKHYzKQ0KPiDC
oCAtwqAgSmFuIEJldWxpY2gNCj4gwqAgLSANCj4gaHR0cHM6Ly9wYXRjaGV3Lm9yZy9YZW4vNzI5
Zjc4OTYtNTViNy00YjViLWE3ZTktNmViMDQyMGUwYjE0QHN1c2UuY29tLw0KPg0KPiA9PT0gQVJN
ID09PQ0KPiAqwqAgUENJIGRldmljZXMgcGFzc3Rocm91Z2ggb24gQXJtLCBwYXJ0IDMgKHYxNi0+
djIwLT52MjEpDQo+IMKgIC3CoCBTdGV3YXJ0IEhpbGRlYnJhbmQNCj4gwqAgLSANCj4gaHR0cHM6
Ly9wYXRjaGV3Lm9yZy9YZW4vMjAyNTA1MDgxMDQ2MDguNTMxMDc5LTEtc3Rld2FydC5oaWxkZWJy
YW5kQGFtZC5jb20vDQo+IMKgIC0gDQo+IGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZl
bC8yMDI1MDUwODEwNDYwOC41MzEwNzktMS1zdGV3YXJ0LmhpbGRlYnJhbmRAYW1kLmNvbS8NCj4N
Cj4gKiBFbmFibGUgZWFybHkgYm9vdHVwIG9mIEFybXY4LVIgQUFyY2gzMiBzeXN0ZW1zDQo+IMKg
IC0gQXlhbiBLdW1hciBIYWxkZXINCj4gwqAgLSANCj4gaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcv
eGVuLWRldmVsLzIwMjUwNDE0MTY0NTE0LjU4ODM3My0xLWF5YW4ua3VtYXIuaGFsZGVyQGFtZC5j
b20vDQo+IMKgIC0gDQo+IGh0dHBzOi8vcGF0Y2hldy5vcmcvWGVuLzIwMjUwNDE0MTY0NTE0LjU4
ODM3My0xLWF5YW4ua3VtYXIuaGFsZGVyQGFtZC5jb20vDQo+DQo+ID09PSBSSVNDLVYgPT09DQo+
DQo+ICogUklTQy1WIHNvbWUgcHJlaW5pdCBjYWxsczoNCj4gwqAgLcKgIE9sZWtzaWkgS3Vyb2No
a28NCj4gwqAgLSANCj4gaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcveGVuLWRldmVsLzRkZGRlNjAz
NDdlZGY2NzQwZmJjNjliNTczOWQwOTk2MTZmNWI1ZmYuMTc0MzE2NTc5MS5naXQub2xla3NpaS5r
dXJvY2hrb0BnbWFpbC5jb20vDQo+DQo+ICogRml4ZXMgZm9yIFVCU0FOICYgR0NPViBzdXBwb3J0
IGZvciBSSVNDLVY6DQo+IMKgIC3CoCBPbGVrc2lpIEt1cm9jaGtvDQo+IMKgIC0gDQo+IGh0dHBz
Oi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZlbC85ZmJiNWUxMzg5Yjg0YmVkMmU5NWY5OWU0YzM4
M2QwMjE1YzdhNTI0LjE3NDQ4ODkxODUuZ2l0Lm9sZWtzaWkua3Vyb2Noa29AZ21haWwuY29tLw0K
Pg0KPiBIYXZlIGEgZ29vZCB3ZWVrIQ0KPg0KPiBCZXN0IHJlZ2FyZHMsDQo+IMKgT2xla3NpaQ0K
Pg0KPg==


From xen-devel-bounces@lists.xenproject.org Sat Jun 14 16:41:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jun 2025 16:41:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1015625.1393182 (Exim 4.92)
	(envelope-from )
	id 1uQTwD-0001Ue-Jd; Sat, 14 Jun 2025 16:41:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1015625.1393182; Sat, 14 Jun 2025 16:41:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uQTwD-0001UX-GS; Sat, 14 Jun 2025 16:41:01 +0000
Received: by outflank-mailman (input) for mailman id 1015625;
 Sat, 14 Jun 2025 16:40: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 1uQTwB-0001Aq-R3
 for xen-devel@lists.xenproject.org; Sat, 14 Jun 2025 16:40:59 +0000
Received: from mail-yw1-x112a.google.com (mail-yw1-x112a.google.com
 [2607:f8b0:4864:20::112a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 58de0f23-493e-11f0-a309-13f23c93f187;
 Sat, 14 Jun 2025 18:40:58 +0200 (CEST)
Received: by mail-yw1-x112a.google.com with SMTP id
 00721157ae682-70e1d8c2dc2so27363927b3.3; 
 Sat, 14 Jun 2025 09:40:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 58de0f23-493e-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749919257; x=1750524057; 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=42HLB7vPizxYysP77djk2L92Us5rCaaCpZzTdci5z24=;
        b=VWBFS513kb+RXIUJ8nKATywnf8hARg3JOPWBOGUNnJLyoq4ouwjaRhkS0FevoegrSN
         5/USROQh/lnqTlxXWSK8EE4IEEkSUMu+JTwdP370O+K4JB8wrYgvVGXT83imZzOeJPZv
         GV7BPSA1vSOI+nZE2vr5EjNIOwlXY3lPlbJoqVpUNkYxW56tdZo6i2MVD483s63T0CN0
         XEY4/wzsqfKauzc2634ceJc3okYMiE3Kbhi+Z2jAOagUzA+cGHsHbzm5TDidZiqJkEt6
         vba7GQHDHkFOpHzp2R0MqOQtlpeDcTk5Lse4GV1WdJDLtxUbnR+JluMU2Wuuno2MdFxD
         hPgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749919257; x=1750524057;
        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=42HLB7vPizxYysP77djk2L92Us5rCaaCpZzTdci5z24=;
        b=deVwUzAEm5szzxY+C8p2NHsZO7pbVdSIn/AjrrFsGySZdqTlosu0948ux64L7Ded8G
         3ngDb+Zyk5zkgRG6Ax2/1JQt95qPNfy7T6Sm0M7BMU+YY3924u1Ptx4bX77h8M/VOubB
         7a9CnOjTCxb74Y5AWOpu+QmYi9jFn98pqEGSkOI3SvceGhPGCqSQ2I0JdExjkG/tQ9TU
         urGF26L+NXklR6MRk32QogtTgpQMDO2PLTZXyGP2skg/OgJpTcsrSCGuM9GXxVvOJa1B
         2OuXPqELiLoY6CMYkI0cNjBcPMS1H14MDTLLM3QCU7GYbFQH2u5nW0GrFXF/bf/S7Cwi
         RUsQ==
X-Forwarded-Encrypted: i=1; AJvYcCXq+8jOAAfRE2MebBVemc/yqqOTCrZ+EI8JofBQ8izD6ZgMFvfYxCC+Dp5DH/nX3vCL9yPrbDYK5Uo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzPaamEBnODfuSX3I1h2NqEhQMXtgQiBw2XXjJNfVvQnfN3oLwx
	lJYvVSCEMdB+KxpchCJ5c9pdL+Q6yJlVGUNGtpnwNrCunWpp1Hne8+cpq7PhmXlWOpcyDDpbgyt
	xU81b0DEmyM6Mosx8poAl7uzry0JK+nA=
X-Gm-Gg: ASbGncu2Cx72u4zqbDXAe1ThL58BxpBvEwQJTSIqi4ba9aha4BonF0e1V2yNrzVMS7K
	M/6xEV56r5u6Eu7TOf+sk4FZQGrOUt1J9riyqRsA2GO++2XZlx+2FU6gtvnw1nwF3/Odp3PjSz2
	XNtQODP4xBXPxPMWWzoRwp4JzT7GX3Wxrct555IDCp
X-Google-Smtp-Source: AGHT+IGuuuPtD15+NIRs6pZG7pwSHOZbi5aqJoqJZZcGKqtWPCnsTvgV8mnXjUxGwLV7BMyrLSyX2ybHgpVzB0Jwedc=
X-Received: by 2002:a05:690c:4c08:b0:70f:8883:eb1a with SMTP id
 00721157ae682-7117537b9b5mr54186967b3.6.1749919257058; Sat, 14 Jun 2025
 09:40:57 -0700 (PDT)
MIME-Version: 1.0
References: <20250321092451.17309-1-jgross@suse.com> <20250321092451.17309-3-jgross@suse.com>
In-Reply-To: <20250321092451.17309-3-jgross@suse.com>
From: Jason Andryuk 
Date: Sat, 14 Jun 2025 12:40:46 -0400
X-Gm-Features: AX0GCFsY6c5o-q74wdQQKXJzn2F1w802AGfeuuQ3aB3gDR_WQuh4t3gmQe3EW3k
Message-ID: 
Subject: Re: [MINI-OS PATCH 02/12] kexec: add final kexec stage
To: Juergen Gross 
Cc: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org, 
	samuel.thibault@ens-lyon.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 21, 2025 at 5:25=E2=80=AFAM Juergen Gross  wro=
te:
>
> Add the code and data definitions of the final kexec stage.
>
> Put the code and related data into a dedicated section in order to be
> able to copy it to another location. For this reason there must be no
> absolute relocations being used in the code or data.
>
> Being functionally related, add a function for adding a final kexec
> action.
>
> Signed-off-by: Juergen Gross 

> --- /dev/null
> +++ b/arch/x86/kexec.c
> @@ -0,0 +1,109 @@

> +
> +/*
> + * Final stage of kexec. Copies all data to the final destinations, zero=
es
> + * .bss and activates new kernel.
> + * Must be called with interrupts off. Stack, code and data must be
> + * accessible via identity mapped virtual addresses (virt =3D=3D phys). =
Copying
> + * and zeroing is done using virtual addresses.
> + * No relocations inside the function are allowed, as it is copied to an
> + * allocated page before being executed.

"page" is stated here.  Do we need an ASSERT later?

> + */

> +void do_kexec(void *kexec_page)
> +{
> +    unsigned long actions;
> +    unsigned long stack;
> +    unsigned long final;
> +    unsigned long phys;
> +
> +    actions =3D get_kexec_addr(kexec_page, kexec_actions);
> +    stack =3D get_kexec_addr(kexec_page, kexec_stack + KEXEC_STACK_LONGS=
);
> +    final =3D get_kexec_addr(kexec_page, kexec_final);
> +    phys =3D get_kexec_addr(kexec_page, kexec_phys);
> +
> +    memcpy(kexec_page, _kexec_start, KEXEC_SECSIZE);
> +    asm("cli\n\t"
> +        "mov %0, %%"ASM_SP"\n\t"
> +        "mov %1, %%"ASM_ARG1"\n\t"
> +        "mov %2, %%"ASM_ARG2"\n\t"
> +        "jmp *%3"
> +        :"=3Dm" (stack), "=3Dm" (actions), "=3Dm" (phys)

Aren't these inputs and not outputs?

> +        :"m" (final));
> +}
> +
> +#endif /* CONFIG_KEXEC */


> diff --git a/include/kexec.h b/include/kexec.h
> index 6fd96774..722be456 100644
> --- a/include/kexec.h
> +++ b/include/kexec.h
> @@ -1,7 +1,34 @@

> +
> +int kexec_add_action(int action, void *dest, void *src, unsigned int len=
);
> +
> +#define KEXEC_SECSIZE ((unsigned long)_kexec_end - (unsigned long)_kexec=
_start)

Add a build assertion here?  Or maybe the correct amount is allocated
and it doesn't matter.

Generally looks good.

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Sat Jun 14 16:41:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jun 2025 16:41:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1015622.1393165 (Exim 4.92)
	(envelope-from )
	id 1uQTw3-0001B8-AO; Sat, 14 Jun 2025 16:40:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1015622.1393165; Sat, 14 Jun 2025 16:40:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uQTw3-0001B1-77; Sat, 14 Jun 2025 16:40:51 +0000
Received: by outflank-mailman (input) for mailman id 1015622;
 Sat, 14 Jun 2025 16:40: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 1uQTw1-0001Aq-Ni
 for xen-devel@lists.xenproject.org; Sat, 14 Jun 2025 16:40:49 +0000
Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com
 [2607:f8b0:4864:20::b2d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 51e5b372-493e-11f0-a309-13f23c93f187;
 Sat, 14 Jun 2025 18:40:48 +0200 (CEST)
Received: by mail-yb1-xb2d.google.com with SMTP id
 3f1490d57ef6-e733a6ff491so2952728276.2; 
 Sat, 14 Jun 2025 09:40:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 51e5b372-493e-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749919245; x=1750524045; 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=eyhGtYKM6CaMo7sZeOdWXFDLBzFhUdblvvIYybl912A=;
        b=JpuM6fVg/CgluctgalzPo55dKfiT90ZPEd2ZX1XQ9FOlw4xGLRVK8kARSOYgoAAwpA
         RgwoLKEYEH8eBa9wfoQltwTxtLV1neKZHiEfIHmPA6rEA9BUI9fbTus4sD0BJvCYbCxp
         rRWXBtEUXk4PslBidZIRtL3Nz/t8DNopCnM4nX1b8a+RgLn0KEUOfXvutRVxxNTN7YS0
         fH34lf7Nwf/eFq+ucT2ZSRoykMdm1O/VU/94EbK4SErwZ4Ab0YJrgdcz7ymIvENLVLl0
         949jiTsyh9I3u6VzT1ZzL93h+kvZYBrHKRui0EYIXfFCew921nX42apVhJPDyY/d61RN
         G4lQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749919245; x=1750524045;
        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=eyhGtYKM6CaMo7sZeOdWXFDLBzFhUdblvvIYybl912A=;
        b=F+uKFwPWJ05WXuUNtyXEW+ES3NEs/giO17VccXjlI+WA/shEzHgIwJ+1zrdio9S+v1
         0FYLCQwYHDtDqaj7fvgtMvQPjO8BGNyHssQbkQVcS6oHSnUdrM63DNH90wB8JXRiK06P
         VRVWcF4PwEYNoUFHA1+mZfmliLL11QQuNWXBjnQnUX3fqOxdcr74L9zyjZsVh0RP9vfj
         OaiO3+aequMsPqyGuZ9Er6Pr9+y7b/bpjNGmTlU/ZeMdkgmhU8tXFrxYPgCzioMi0Bkt
         40C3U+Cg9NiZ0FzeP9xydx/9Uc3YBXtPWE5Zsofu178fVDD72feJN8u686v0v6Nq/RBK
         zGlw==
X-Forwarded-Encrypted: i=1; AJvYcCXB2Rh4S1KK0dvc+aLwac/Jch0pM0qd0lvM7oEkMsGZeBbArK6Ke88w44oaI57u4G4bf6STjZAG5xA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw5jk+wuqHbSDTYDBiJbqAWgO670DY8fzY/ARZx1BcRY1bC1rLw
	WNgZ5Cyv5c0xaMHsMoiPzhqoKRjwwqJ4qHtT8JRtOWfAwC83P7gEeWO6d0bCqfCWzqeVckYmfZu
	+jQwACNTbdmxlpxMkhaffAm1qqhWXOR74fw==
X-Gm-Gg: ASbGnctmGQhecDbVLtb4HJDJ8v9tVsZsw+CqfSAi7/12N3cAPIeY9P/CGyTP98Quw1y
	Txa96NWLi6j1qDM3qx8oxrCDTBgFPx2lzgJ4B0JrdtMnMn+GKeBS6AssabpVk6XOriCqOrMK760
	8l4/T12Fvi7vIToQT2i/2MKOih3/ygQxPn5rUGEclu
X-Google-Smtp-Source: AGHT+IHXjOfj16s2KHf0PdH1p43swU4encjYeBVutq6Runhj97SwFXC6A3XMRCekZz++EQ+xq7Ob1fjJR5kLwcIbNVQ=
X-Received: by 2002:a05:690c:67c9:b0:70d:f673:141b with SMTP id
 00721157ae682-7117548a480mr49110147b3.13.1749919245231; Sat, 14 Jun 2025
 09:40:45 -0700 (PDT)
MIME-Version: 1.0
References: <20250321092451.17309-1-jgross@suse.com> <20250321092451.17309-2-jgross@suse.com>
In-Reply-To: <20250321092451.17309-2-jgross@suse.com>
From: Jason Andryuk 
Date: Sat, 14 Jun 2025 12:40:33 -0400
X-Gm-Features: AX0GCFto9IYCdtiXjfKnsdnT_mODOSsq1C0J0AMYEfT-wD-3cPSXfHy79Jr-Dlc
Message-ID: 
Subject: Re: [MINI-OS PATCH 01/12] kexec: add kexec framework
To: Juergen Gross 
Cc: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org, 
	samuel.thibault@ens-lyon.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 21, 2025 at 5:25=E2=80=AFAM Juergen Gross  wro=
te:
>
> Add a new config option CONFIG_KEXEC for support of kexec-ing into a
> new mini-os kernel. Add a related kexec.c source and a kexec.h header.
>
> For now allow CONFIG_KEXEC to be set only for PVH variant of mini-os.
>
> Signed-off-by: Juergen Gross 
> ---


> diff --git a/arch/x86/testbuild/all-yes b/arch/x86/testbuild/all-yes
> index 8ae489a4..99ba75dd 100644
> --- a/arch/x86/testbuild/all-yes
> +++ b/arch/x86/testbuild/all-yes
> @@ -19,3 +19,5 @@ CONFIG_BALLOON =3D y
>  CONFIG_USE_XEN_CONSOLE =3D y
>  # The following are special: they need support from outside
>  CONFIG_LWIP =3D n
> +# KEXEC only without PARAVIRT

Maybe: "KEXEC not implemented for PARAVIRT"?

> +CONFIG_KEXEC =3D n

> diff --git a/kexec.c b/kexec.c
> new file mode 100644
> index 00000000..53528169
> --- /dev/null
> +++ b/kexec.c
> @@ -0,0 +1,62 @@

> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * General approach for kexec support (PVH only) is as follows:
> + *
> + * - New kernel needs to be in memory in form of a ELF file in a virtual

"in the form of an ELF binary"

> + *   memory region.

Maybe just "The new kernel needs to be an ELF binary loaded into the
Mini-OS address space"?

> + * - A new start_info structure is constructed in memory with the final
> + *   memory locations included.
> + * - All memory areas needed for kexec execution are being finalized.
> + * - From here on a graceful failure is no longer possible.
> + * - Grants and event channels are torn down.
> + * - A temporary set of page tables is constructed at a location where i=
t
> + *   doesn't conflict with old and new kernel or start_info.
> + * - The final kexec execution stage is copied to a memory area below 4G=
 which
> + *   doesn't conflict with the target areas of kernel etc.
> + * - Cr3 is switched to the new set of page tables.
> + * - Execution continues in the final execution stage.
> + * - All data is copied to its final addresses.
> + * - Processing is switched to 32-bit mode without address translation.

Maybe "CPU is switched to 32-bit mode with paging disabled."?

Is the following memory layout correct?

[ 0 ... 8MB ] ... [ X ... X + Y ] ... [ Z ...      ]
 Old stubdom        New stubdom         kexec code

kexec code copies New stubdom to 0 and later jumps to New stubdom @ 0

The temporary page tables are to allow old stubdom and kexec code to
be called while overwriting the "Old stubdom" range which would
include the page tables originally used?  Or it can only run the kexec
code once old stubdom is overwritten, right?

I think some comments tweaks would be helpful, but code-wise
everything is okay, so:

Reviewed-by: Jason Andryuk 

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Sat Jun 14 16:41:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jun 2025 16:41:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1015648.1393197 (Exim 4.92)
	(envelope-from )
	id 1uQTwk-0002Fc-Tt; Sat, 14 Jun 2025 16:41:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1015648.1393197; Sat, 14 Jun 2025 16:41: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 1uQTwk-0002FT-Pv; Sat, 14 Jun 2025 16:41:34 +0000
Received: by outflank-mailman (input) for mailman id 1015648;
 Sat, 14 Jun 2025 16:41: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 1uQTwj-00022V-HK
 for xen-devel@lists.xenproject.org; Sat, 14 Jun 2025 16:41:33 +0000
Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com
 [2607:f8b0:4864:20::1134])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6b6bae7c-493e-11f0-b894-0df219b8e170;
 Sat, 14 Jun 2025 18:41:29 +0200 (CEST)
Received: by mail-yw1-x1134.google.com with SMTP id
 00721157ae682-70e2b601a6bso31702817b3.0; 
 Sat, 14 Jun 2025 09:41:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6b6bae7c-493e-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749919288; x=1750524088; 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=qJO3DPmTnpimcmFIlDN1TKqKbZ/I+JX6jYAuRKKryfQ=;
        b=HIeRLtXwS6fGCCSQvHYeSjk0S+Pw5SDGdW/k1qzqHr9eMyuwWm4Wq+g+O8mCqmlWBa
         91JTY34nnUo5vzIP3OkcGuf+4pJYiv+rdO8s1+ntu3adQsVuZJXXChDOKXTV11YbhTY8
         qt8/llesltUgA+hJ6lNGYsAov4wjB2HtZABPhevGXZ7vqrpw47SwCCEUMNl/hBXhRuxp
         fov0nf5UPNi5Mtdl0ed4RT8UZv/Bvf1yj0TD7+fYUczmDLreCcVQO2Ur4gYBgbGRMdMH
         GUYgJlKjgPxW3hZhaYxhF7arE6pjXXcuuMHO8/O+V0iCE05kj/kUSRtzD0/qyUrbnBhS
         MTlA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749919288; x=1750524088;
        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=qJO3DPmTnpimcmFIlDN1TKqKbZ/I+JX6jYAuRKKryfQ=;
        b=AB7e1lDQUTX6CkS/pBrJ4OQhbk0fMrO1bN50PDDZRJoGdaP/rkSuKc70ZYVvP0uJv4
         3zXs2giV8mfRlE53T7wfpvb13gD+zsUoCwdiD0sjj2ltx+e/N4ZfIqnpo238Isg1dBGZ
         0FcKYIZ/EGGnoLvwx9k9rz50gBt4cKOgMsNpMLAgcmgjej0obEo/8qIqYPF2ZRwLlanS
         +TRow+p3OM+XfxZHVxh/bEHvsTwgPTyN8VmDA0MI5gKitq6+ILr0Qxh+MFRtHgOYCcxy
         LaS7WQv3TeAcqNqkBFculit+ff1msup5NfBxMetJaND+m1ZGxnaebpjj12kFxSFqTIhl
         R9RQ==
X-Forwarded-Encrypted: i=1; AJvYcCXrMXHQjd8nwJtSa+m+fTrOXb2dMkgMRtRaoezpNMhBW9VMoQKS9C99ctXDKzqU0Rn1hT/cjGBIqCM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx9bReDz7QbqNp0ahgb3p+5OV7suB39rFFanOm8rzIV/iYJcFnl
	XMg8ODcLl8OfXfrxVOphTsFYCwLckG8OgqtJ2mhLcgD4d5EhJofDaI3AjArLe+Y4DxMnpL5Vj2J
	GajOhV/2TJ5Ris0ff3CrTscToDl+LrbWvRWQ2
X-Gm-Gg: ASbGnctxuX6TBM25kJokiXZPGJV4i1JAN/vbA8RglsyS/uxLACNix4i4oI10qP89UHS
	OcybOedmTxhaAFiFGogPcrqyCVTVoum7e0bMBARrr5QMD1DeI+rl9nuCTtVZabfOSvZtE3AIEaH
	YyLubvFurJDL6lmM5KfBbCIrewJcZV1t2TobImjllZ
X-Google-Smtp-Source: AGHT+IEAnAkQsLrLIFAiit2cbF9bQ5JMTM52mtEtI7vNK64Wm4m1DlZAuPMBQ/M4LIXcrt50+ZUHOh/osjgqg6qRb00=
X-Received: by 2002:a05:690c:7248:b0:70e:86a:ae1e with SMTP id
 00721157ae682-71175448c6fmr49156787b3.22.1749919288240; Sat, 14 Jun 2025
 09:41:28 -0700 (PDT)
MIME-Version: 1.0
References: <20250321092451.17309-1-jgross@suse.com> <20250321092451.17309-5-jgross@suse.com>
In-Reply-To: <20250321092451.17309-5-jgross@suse.com>
From: Jason Andryuk 
Date: Sat, 14 Jun 2025 12:41:17 -0400
X-Gm-Features: AX0GCFudxaAqybZz7opAuHCp3FhTMZE4WZiJAJp3RcPX6BCBtwpT63tnr4klkHA
Message-ID: 
Subject: Re: [MINI-OS PATCH 04/12] kexec: analyze new kernel for kexec
To: Juergen Gross 
Cc: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org, 
	samuel.thibault@ens-lyon.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 21, 2025 at 5:25=E2=80=AFAM Juergen Gross  wro=
te:
>
> Analyze the properties of the new kernel to be loaded by kexec. The
> data needed is:
>
> - upper boundary in final location
> - copy and memory clear operations
> - entry point and entry parameter
>
> Signed-off-by: Juergen Gross 

> +
> +static void check_notes_entry(elf_ehdr *ehdr, void *start, unsigned int =
len)

I think you should rename this to include read_ since it is necessary
to set kernel_entry.  read_phys32_entry_note() or
read_note_kernel_entry() or some variation.  To me, check_ implies a
boolean return without a side effect.

> @@ -54,9 +57,122 @@
>   * - The new kernel is activated.
>   */
>
> -int kexec(void *kernel, unsigned long kernel_size,
> -          const char *cmdline)

> +int kexec(void *kernel, unsigned long kernel_size, const char *cmdline)

NIT: introduce kexec() with the single line form to avoid changing it

Everything else looks good, so preferably with the renaming:

Reviewed-by: Jason Andryuk 

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Sat Jun 14 16:43:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jun 2025 16:43:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1015658.1393211 (Exim 4.92)
	(envelope-from )
	id 1uQTyU-0002vX-8Z; Sat, 14 Jun 2025 16:43:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1015658.1393211; Sat, 14 Jun 2025 16:43:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uQTyU-0002vQ-5S; Sat, 14 Jun 2025 16:43:22 +0000
Received: by outflank-mailman (input) for mailman id 1015658;
 Sat, 14 Jun 2025 16:43: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 1uQTyS-0002tF-MT
 for xen-devel@lists.xenproject.org; Sat, 14 Jun 2025 16:43:20 +0000
Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com
 [2607:f8b0:4864:20::b31])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ab8923f5-493e-11f0-b894-0df219b8e170;
 Sat, 14 Jun 2025 18:43:17 +0200 (CEST)
Received: by mail-yb1-xb31.google.com with SMTP id
 3f1490d57ef6-e740a09eb00so2579817276.0; 
 Sat, 14 Jun 2025 09:43:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ab8923f5-493e-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749919396; x=1750524196; 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=1VsPMzepTflWSN6sj4gCijnZcPZH6y1oYNdtH24EsqQ=;
        b=TMrE+k2YHToaLsv+4kEWVZiB2cK8y9jPhIEImMHawf2pj/hCWAI4iB+XMUYNi9uywb
         ojcBUTB8w7hAG1EaAj3WlT970yopjpLRNg+AXhTj/9dDvKh7oo5tFtMSN6JL5ptbD6rg
         Zfcy0q8QZvAOSBija96PRxXukk9LvXCa88eUFxxul/ZInrkLqP7eGpYkvrZd7VJhRYC1
         ZID5hF7c7ASbBuDyHXoVeAftiB3t28BhP4TdQFIGtCJrnppmID8u+3kIIv15ttPOQQZW
         RT2jjfO/dlgxG1vKc4ykoMfeHAiZe4KOhKp5CZEFVf4rZhDELLp3MQAhhGZjOTzUbOJf
         PDYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749919396; x=1750524196;
        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=1VsPMzepTflWSN6sj4gCijnZcPZH6y1oYNdtH24EsqQ=;
        b=VDFHN4uO/QwVeiy+etgCe7OnlgoEppKVdqQKVoXdrBc3vqEcohipI77N7HxGqM/YqS
         VxDALx4tr56npzBtL/RsFxLZxdrlIYgXleIfIZPQKP9907JWjV8DnPsp5iY/PNrqtcJ5
         QMXehriCx1cMrdEQCh8P+5KCMdNz3tEvaJHTqx30t77q7SwWlTUmwtQi3gF9d4hDnPic
         +7/PrMmOyGe2LJDo55i7uWxvBnW/q8axRqTR5IpAYToMwqXWP2W7AzQ3m+gZR/GNkSio
         xDhNL2Z4xES4eO8Ml24I+dOj2bWeYM4qiFWx/DquSIfd5JgqrsIB8iQUJXanKexPRgFW
         9HVQ==
X-Forwarded-Encrypted: i=1; AJvYcCWMAxTWHsO/lOPh+gh7n5hezNzCJut+Btot2moOE9OHN523xyqynSlyHF9Y6AJ3r1SoLwifm0W/Fbw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxURTK6Y3jZJIUL/qWdy86PaJx6M/90YO8jNTiKzwE5Ry+PMBls
	mS1IlNzmfVqUsBFMAc8sgFo1bp/Jn1M7jhW4qDh7yFDfS0RE24NJp6yyqU8RcG5BGdBZgWNcBCk
	E9BuoowodVf/RWvxab43tEmN6+LmotxE=
X-Gm-Gg: ASbGncvA1wGrwxkfoH8yvbQBcELKcupGdWVxvdRPooHyabllvQeL2zRKhUaADlbgVMf
	TCVQMe0AEHzFAuA3HyksVbHJFcVRh3I4avCtY5hrtc/1dl7C5wtbuHIEtFI5ZhG86Xl40D56AQu
	TRsL1gBQRP1hmUG8gA6YY7016srJdW80u5rU111Yjw
X-Google-Smtp-Source: AGHT+IHRZO/gCTRzBeDSbBoZQ2muL/3+1exHsIYorrrg5SWuDFcH2I4QGn5i1rE2RSkUpA0f64kf1sYKD6rCDscYbUg=
X-Received: by 2002:a05:690c:882:b0:70e:2246:1999 with SMTP id
 00721157ae682-71175457380mr47342547b3.21.1749919395886; Sat, 14 Jun 2025
 09:43:15 -0700 (PDT)
MIME-Version: 1.0
References: <20250321092451.17309-1-jgross@suse.com> <20250321092451.17309-6-jgross@suse.com>
In-Reply-To: <20250321092451.17309-6-jgross@suse.com>
From: Jason Andryuk 
Date: Sat, 14 Jun 2025 12:43:04 -0400
X-Gm-Features: AX0GCFsByrRDnafFmXpcq1dpAD05Z8tRENmkmf8yzt71Rcv4E0d_BqLOcOXZ7-I
Message-ID: 
Subject: Re: [MINI-OS PATCH 05/12] kexec: finalize parameter location and size
To: Juergen Gross 
Cc: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org, 
	samuel.thibault@ens-lyon.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 21, 2025 at 5:25=E2=80=AFAM Juergen Gross  wro=
te:
>
> Finalize the location and the size of the parameters for the new
> kernel. This is needed in order to avoid allocating new memory in the
> area occupied by the new kernel and parameters.
>
> Signed-off-by: Juergen Gross 

Reviewed-by: Jason Andryuk 


From xen-devel-bounces@lists.xenproject.org Sat Jun 14 16:56:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jun 2025 16:56:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1015676.1393221 (Exim 4.92)
	(envelope-from )
	id 1uQUBI-0004tD-C5; Sat, 14 Jun 2025 16:56:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1015676.1393221; Sat, 14 Jun 2025 16:56: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 1uQUBI-0004t6-7r; Sat, 14 Jun 2025 16:56:36 +0000
Received: by outflank-mailman (input) for mailman id 1015676;
 Sat, 14 Jun 2025 16:56: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 1uQUBH-0004sg-5T
 for xen-devel@lists.xenproject.org; Sat, 14 Jun 2025 16:56:35 +0000
Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com
 [2607:f8b0:4864:20::1136])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 859cbe8c-4940-11f0-b894-0df219b8e170;
 Sat, 14 Jun 2025 18:56:32 +0200 (CEST)
Received: by mail-yw1-x1136.google.com with SMTP id
 00721157ae682-710f39f5cb9so30829647b3.3; 
 Sat, 14 Jun 2025 09:56:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 859cbe8c-4940-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749920191; x=1750524991; 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=57YZdmcj8pxvunihyyOa15jxBR/jdBA4jxHwGJ8fFs0=;
        b=cDmHTf82aCNByE9Yc71GhkBo2WAN2bSd8S0KbxKHtWwl5V1WSDekPGUL/7Rk6SmNo7
         7sNL0dWoYukU+4EGsLwqfEpPtb/+LTCx5sJs7EIOH2KnebMEAP0ngoYZ71W6xJ2Kgeag
         qZyyT/0SLhPUrAvYP2SpFV1GCpt6+ZyExo3rwPn9aI9e+GH3vR6wFDFBTZWKmjgDeoGN
         ETUllH+3DLOsrt7Psg2mMwQswcnLo0OiCDn4d0R4gykdJilsD+zaqSMvD+6LX0XHOp8J
         ztneqmXKTn1wxRWXlVlCPs7hujSlCSa/58pXqntpZ0S1dgeIBZ5wVUcRFIxwcFZ0J4mI
         JbuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749920191; x=1750524991;
        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=57YZdmcj8pxvunihyyOa15jxBR/jdBA4jxHwGJ8fFs0=;
        b=EK5hHy1XVE/2AOdAkooHun/d3CZ/l2h4HSXXXPaZ3ws1qbA3oq40ZiYsFRqJdWqzH5
         af/69uIMD+OrefoxL2os6orvabgUvzS+3yx9bKBZl4D3NggVTfCFCaF8424bpv+5V/yk
         Ma4O6W0749YGyiURcWKeuU4OKQC0+smzJdLGvCX1GRuQovQRD9q+QmAtYcgxmKieQzMx
         qrDDD2Cvv651QzhbFPIXyQ70PCVECo5g7aYtzfIKE96L1Nv4ZEq4Tb1RBOYqMgFD8HRP
         DlQ67kSPXCjO0lu8fBY3T9RC+ToJhdJLo6+sC8MD3zWhtB/+c3hS1n9JiLpFFSC87AqI
         W4qg==
X-Forwarded-Encrypted: i=1; AJvYcCVwR8oOjHQVri6xeSIQFiPDLnJ1+0W/CdDSr3LCwVbSSx0X02l7XgrY7iUms05gbhJXvYehj3+Wn9I=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzEz3BB7PQu1p5eXka7lMPvVWwPUaZMderM9UGt/sMIByGbWBPf
	BTwTtbbx55Ya97DwJ4cpyJGDRs7gPLagUfzSvbWGZ12iVluntbhf+FC1jSvsf1RgoduR1YvHLpL
	4J28XL1+nTp6vJNNUab0Irp9S+wCpSN8=
X-Gm-Gg: ASbGncvg4Of3pdEM118hFyX7WmjjQdBsY+mbA1SKxcSrQWVfP3TrKWOIN5c2V3CXbhv
	Nq4RwmivB4oC5ql0foM1jWASELwdBBH230ElWpcVb14VZOBfBwsA5jFjBnQcPA5h+ipOCZoAUlD
	NyUuNPpxt/DfMpMxO8VS+G5G9oVjQPWocXODwmK1BW
X-Google-Smtp-Source: AGHT+IGiNrtalb4MqdAMJLaPjMcpCr6qlE1/JiVqtQyXZ3s0U5V67Jes0z7IMSZtxydESAGuVfIDSonkvZ74BYwoo04=
X-Received: by 2002:a05:690c:881:b0:70e:779:7e6a with SMTP id
 00721157ae682-7117543136fmr48735997b3.22.1749920191150; Sat, 14 Jun 2025
 09:56:31 -0700 (PDT)
MIME-Version: 1.0
References: <20250321092451.17309-1-jgross@suse.com> <20250321092451.17309-7-jgross@suse.com>
In-Reply-To: <20250321092451.17309-7-jgross@suse.com>
From: Jason Andryuk 
Date: Sat, 14 Jun 2025 12:56:20 -0400
X-Gm-Features: AX0GCFsQc_7JQjDEeTpyXiRlVMtWJznxeSDLm-k3l0EiyYD_6g9G_3l3BTKJE_A
Message-ID: 
Subject: Re: [MINI-OS PATCH 06/12] kexec: reserve memory below boundary
To: Juergen Gross 
Cc: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org, 
	samuel.thibault@ens-lyon.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 21, 2025 at 5:31=E2=80=AFAM Juergen Gross  wro=
te:
>
> In order to support kexec any memory used during copying the new
> kernel to its final destination must not overlap with the destination
> area.
>
> In order to achieve that add a new interface allowing to mark all
> allocatable memory below a specific physical address as not available.
>
> This is done by walking through all chunks of the buddy allocator and
> removing the chunks (or chunk parts) below the boundary. The removed
> chunks are put into a list in order to be able to undo the operation
> in case kexec is failing before doing any unrecoverable system
> modifications.
>
> Any pages freed located below the boundary need to go directly into
> the list of reserved pages instead of the free pool.
>
> Call the new function from kexec code.
>
> Signed-off-by: Juergen Gross 

Reviewed-by: Jason Andryuk 


From xen-devel-bounces@lists.xenproject.org Sat Jun 14 17:02:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jun 2025 17:02:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1015690.1393239 (Exim 4.92)
	(envelope-from )
	id 1uQUHO-0006pT-3K; Sat, 14 Jun 2025 17:02:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1015690.1393239; Sat, 14 Jun 2025 17: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 1uQUHN-0006pG-VN; Sat, 14 Jun 2025 17:02:53 +0000
Received: by outflank-mailman (input) for mailman id 1015690;
 Sat, 14 Jun 2025 17: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 1uQUHN-0006oq-Bd
 for xen-devel@lists.xenproject.org; Sat, 14 Jun 2025 17:02:53 +0000
Received: from mail-yw1-x112b.google.com (mail-yw1-x112b.google.com
 [2607:f8b0:4864:20::112b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 67be73db-4941-11f0-a309-13f23c93f187;
 Sat, 14 Jun 2025 19:02:51 +0200 (CEST)
Received: by mail-yw1-x112b.google.com with SMTP id
 00721157ae682-70e447507a0so23014307b3.0; 
 Sat, 14 Jun 2025 10:02:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 67be73db-4941-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749920570; x=1750525370; 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=f1rUaCtNzV4B4nne9ETOS7IrnAJZb2wTVv5/DHGcfCA=;
        b=DpSONPjw/PM1C6jaJ6YLxdMUI1gPaVvSe2aog4b/KJ5mHu6L5Bq9YYUxWVo39PP1vK
         n+ytF6FJspKo/sJ0zh0WAvLDL0leTKynBd93Ib3cLVzUGw7tH8CmsAx/aYh6NXAlzy9G
         FuF4uGtDpbD8bhk5UkTT9h3KTPeOkksNp+zkYjCGbPbOnV9CsCNZlYF7+FVi/3R+lZzq
         cEssDbD+A8p5w/xJHVM7aWDXk28ruWHeF5/Rfq6N5DWG1j7hLhAgGGD2H89ytCCKxPB+
         KIOidEdCwmCNYlKRbJIhGYefDt2YwveGtkfzDvk2tN4S+ZH/BJkpE2zkAqtx5nWEsKxi
         CYLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749920570; x=1750525370;
        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=f1rUaCtNzV4B4nne9ETOS7IrnAJZb2wTVv5/DHGcfCA=;
        b=LeJ6PDxklsQlxWQ7RN76Pvqnn8TciWGwnRwb3U1dzzfWVdvyq9UsCF6c7lKoMThnkJ
         vVVu2W5kpDYiX/x54iLEdZGEatu26FX3Obg6um8a+j6N23M717tmaCcLXBtrsqGxK21H
         pPj4AJOKy/A40v+cIpb+Yc/Z2ogyoPHxx9jST2anGPolmgea3OaqZeb7w6T0Ip/YzwZ4
         vs45OOL5t+nZyT6lNCL2tltodtCSm1T1bi0n+jGl3CtD+jQbqtPCY1xtXwCD0sCvy2d2
         8PuifvclUtZfQl8fxOlGMlllBc7chIn1XjQmBhf3eQvondRcqpMvgqL0fknKrKZyYbZD
         P2nQ==
X-Forwarded-Encrypted: i=1; AJvYcCUYtAXQ4REa3umyQaLErgv9aSFwAcR/e8SRX1LQdA8IUehtU8MJZ8QPDdh150/X7UeRMRwSLp55fms=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwAq5RdF6zCfToccivAJ2aZZW4LSc9HensW4GMzrgfYg0PCL3eS
	klD/zgo2tK68ugD2k/mO2G0NV7iXlRup49wwdsvp9dD8JcGSJTy5RdzNx4nSHsr45nwgP5JhLg+
	7sMH8KoG69T8wg9K2FyV9r+uRahsL2yc=
X-Gm-Gg: ASbGncskI82lkueei8hOuOOJdVBQl4N+nbn7CFh3ZY/OeoPl7mwDmPxRKRvoW32I1QQ
	BQxRWy2Mk+bquoTsor3rIbjdvnS/8lEg/f2LACcJiKySs86oCVTpnSfEdT7sz5T0Q+NI91KtbdN
	stG7Dd+1x0fBFv3VWzv0eYexphWyrleK6wrn4jX7H8
X-Google-Smtp-Source: AGHT+IFj3p5xXle6Z4j9FTHjmTsWeQaVLjYfgGif2AY1z4ez+pJDkc5DEE/s5+LpbmfVu0bmuAmdZFeRpEEfGBVaoSo=
X-Received: by 2002:a05:690c:83:b0:710:e4c4:a938 with SMTP id
 00721157ae682-71175463265mr49057837b3.38.1749920570575; Sat, 14 Jun 2025
 10:02:50 -0700 (PDT)
MIME-Version: 1.0
References: <20250321092451.17309-1-jgross@suse.com> <20250321092451.17309-8-jgross@suse.com>
In-Reply-To: <20250321092451.17309-8-jgross@suse.com>
From: Jason Andryuk 
Date: Sat, 14 Jun 2025 13:02:38 -0400
X-Gm-Features: AX0GCFtDlZJm9XQly_TrFooP5JTbN470WRlmToOXULLBRj_Z9pmgjQuKr5u9nN8
Message-ID: 
Subject: Re: [MINI-OS PATCH 07/12] kexec: build parameters for new kernel
To: Juergen Gross 
Cc: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org, 
	samuel.thibault@ens-lyon.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 21, 2025 at 5:30=E2=80=AFAM Juergen Gross  wro=
te:
>
> Build the parameters for the new kernel, consisting of the
> hvm_start_info struct, the memory map and the command line.
>
> Signed-off-by: Juergen Gross 

> @@ -212,4 +213,61 @@ void kexec_set_param_loc(const char *cmdline)

> +
> +    /* The call of the new kernel happens via the physical address! */
> +    if ( kexec_add_action(KEXEC_CALL, (void *)kernel_entry,

Maybe kernel_entry_pa, kernel_phys32_entry, or kernel_phys_entry would
be a better name to make the physical address clear?

Either way:
Reviewed-by: Jason Andryuk 

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Sat Jun 14 17:19:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jun 2025 17:19:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1015721.1393252 (Exim 4.92)
	(envelope-from )
	id 1uQUXo-0000WE-IR; Sat, 14 Jun 2025 17:19:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1015721.1393252; Sat, 14 Jun 2025 17:19:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uQUXo-0000W7-Fv; Sat, 14 Jun 2025 17:19:52 +0000
Received: by outflank-mailman (input) for mailman id 1015721;
 Sat, 14 Jun 2025 17:19: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 1uQUXn-0000UH-91
 for xen-devel@lists.xenproject.org; Sat, 14 Jun 2025 17:19:51 +0000
Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com
 [2607:f8b0:4864:20::1134])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c53187be-4943-11f0-b894-0df219b8e170;
 Sat, 14 Jun 2025 19:19:47 +0200 (CEST)
Received: by mail-yw1-x1134.google.com with SMTP id
 00721157ae682-70e40e3f316so22862127b3.0; 
 Sat, 14 Jun 2025 10:19:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c53187be-4943-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749921586; x=1750526386; 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=S5+N1kbLD+IUbDgxWMy//0LLQepPeelA35Ixfb+CwiA=;
        b=NBwsDE8PyEguPK5afSFuePtMPMxNhMJmOicbPAVOuE8yVT2AltlOTqdusQ5IoRnuOM
         jGjOGFPKVIvbktTiFBV7qGNag875eK3ZSw62f9DW3FRZMo5CSWw/VzJlHrTUUN6O1Knz
         XWAPcV1+HOr5frZiJfZ5A3huJRGnV1mpXPR2nyfG96g9Ln5EN94C/yhwbRZEFCyuaepq
         Y+AZwCAgOO2I1gxrJkewMAw+y/VeyGOZ5u3kmKA+bwZaohyG5y5K1maMtHerExTPTLUz
         4Lyo4uJshLOrZuGc8EnKaYZE954eTIjd6+dG2+rSUzpHmCR8MlDgmm1i2ixFM0gB5UuN
         nesw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749921586; x=1750526386;
        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=S5+N1kbLD+IUbDgxWMy//0LLQepPeelA35Ixfb+CwiA=;
        b=AHI3ZrGtiwBL3MTeeBVezmDF1K3PRvapkKy7OzTmerAeAJsINs7IIN5JZDvFypYos2
         SmVv8R0+RPXtNWRXLhJ9A+aNGgeL/qw5cp5gESgAv0dcXzqMtWNV+FUWG6O5chRvlvNo
         i/4iGPONgCqHxSbk4OKPOIWwKXQ79U2fz1g1eC6wNlrd5xWkaE5Jj3UATkhTWZ3LQpWN
         5uzDg5U8kyyiajPtQV28fr9C+E7F+5gTSLny5egrs9PpOtLd0hS3AnBfJeYT49keMGoJ
         eyqXSWxNHNM5yo9yFkxZtfhHsdoQJ7caOzJqRhiIUPhBnyqePnBUK/EGenPQveeKxO2j
         ctjw==
X-Forwarded-Encrypted: i=1; AJvYcCW4zCuEZK8ljhchxSfn79wmUp30MAOvsVEAsPgR/sq0DIzonwytTEs3af+dtkAi86S1S6kOn/6BPu4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YykUaBI8lMkFjYR6wSgn8WAQDezlrh6RhJ0C8tcUKrqw9CdTR58
	Hq2TztM+t8EFQT2uYn8x5bZ2HnIx3GAoJb+nDzNYZaXGgBX/jbMagyKVCZcqnpRF/j7X3aOgp6m
	07T+DoqyONOFFbJwaJRP8J6xBCjta8HY=
X-Gm-Gg: ASbGncu9dtj34IAltHCMIoiHcAKLdnY7WWE06aN99OzH9D9ynt7m674igjQGE4WNyQv
	evSbUrhEu/dE5b969qPUl9t00+N1aijrCjCRTUbEO/nc7T6GW+kDbPLfsO33ebym2vwBtXS99Wc
	6yLzk/iWE6Yurt1i+24TDlpTpGYLeSIy8CsIMQmg0O
X-Google-Smtp-Source: AGHT+IE4LIYBSmlVS/6k0rpCv0XLrSjXfkcQ20TNpGSk3ZsAIDJfeS5dHcRlzrgktwdNA4l7hOamsRcTlGnYcGs7/YQ=
X-Received: by 2002:a05:690c:e:b0:70c:b685:a6b7 with SMTP id
 00721157ae682-7117542acbamr49505167b3.21.1749921586367; Sat, 14 Jun 2025
 10:19:46 -0700 (PDT)
MIME-Version: 1.0
References: <20250321092451.17309-1-jgross@suse.com> <20250321092451.17309-9-jgross@suse.com>
In-Reply-To: <20250321092451.17309-9-jgross@suse.com>
From: Jason Andryuk 
Date: Sat, 14 Jun 2025 13:19:35 -0400
X-Gm-Features: AX0GCFv_TqYUW0fUZPc6Vd_64H8YW9QGcFaIkeY72FFc-on-IPVkwyXOwCIQMOY
Message-ID: 
Subject: Re: [MINI-OS PATCH 08/12] kexec: move used pages away for new kernel
To: Juergen Gross 
Cc: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org, 
	samuel.thibault@ens-lyon.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 21, 2025 at 5:30=E2=80=AFAM Juergen Gross  wro=
te:
>
> Copying the new kexec kernel must not overwrite any pages still needed
> during this process. Those are especially the GDT, IDT and page tables.
>
> Move those to new allocated pages and update any related pointers.
>
> In case the kexec process is cancelled later, don't undo any page table
> moves, as the system can just be used with the new layout. By freeing
> the original pages there is no memory leaking.
>
> GDT and IDT should be reverted to their original locations, as their
> original memory can't be freed due to not being whole pages.
>
> Signed-off-by: Juergen Gross 

Reviewed-by: Jason Andryuk 


From xen-devel-bounces@lists.xenproject.org Sat Jun 14 17:25:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jun 2025 17:25:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1015735.1393267 (Exim 4.92)
	(envelope-from )
	id 1uQUdd-0002KS-8j; Sat, 14 Jun 2025 17:25:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1015735.1393267; Sat, 14 Jun 2025 17:25: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 1uQUdd-0002KL-5p; Sat, 14 Jun 2025 17:25:53 +0000
Received: by outflank-mailman (input) for mailman id 1015735;
 Sat, 14 Jun 2025 17:25: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 1uQUdb-0002IU-Hs
 for xen-devel@lists.xenproject.org; Sat, 14 Jun 2025 17:25:51 +0000
Received: from mail-yw1-x112f.google.com (mail-yw1-x112f.google.com
 [2607:f8b0:4864:20::112f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9d455559-4944-11f0-a309-13f23c93f187;
 Sat, 14 Jun 2025 19:25:50 +0200 (CEST)
Received: by mail-yw1-x112f.google.com with SMTP id
 00721157ae682-70e64b430daso32320337b3.3; 
 Sat, 14 Jun 2025 10:25:50 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9d455559-4944-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749921949; x=1750526749; 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=vbnfxk0YQih9gvujZsNzCTqGTQ55nvK5zq1+UHCuDB0=;
        b=IiiXgsLe3anz/V8kYXQ73EONJwrHUXN7TjjcThAqcfMlbQelF+yS7ZCAK04itpOLts
         /izRUdR5+OdF4DTFM6p/UPvDFGbI3k/mwh8knRUrw+O9RiEZ/K08KXgO4bEVNoeYLT7q
         Bmdr5NDgyZKQzAiNCY5u70UgrK+2tEa69zN58o6K/4ZdJJMONWJ7FpdCvCrmjubZbFI1
         ilPgpWnk0kGU1ij+Xy56uL6DLiJ+BT5x5yUbtPXoC8v7SLOUmvcEH2sZoZ66p5TO6qlI
         JvVeIpKvEaE77abys+gogagokJtonYrxf/Pmj9pM3nmcc0vxGo2gTJw+uSe0TvK6dpHw
         zXjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749921949; x=1750526749;
        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=vbnfxk0YQih9gvujZsNzCTqGTQ55nvK5zq1+UHCuDB0=;
        b=lDmRc4rSkUc6zZBC8R2fFqJA4heKUSuhXcoJ/iGZXjSZ46s2hTC7aGzoXIQyK3Unoo
         NIVwyqDgsfRJiaqm+ij+bm9NcrLAxisW0QANw4k7Z+4x7YCuMAPKbZZUd10uY3h9iQge
         /XObR6++d7rRkH/JSYc1J4cYFgmrsi3VLA3FRn5BaADJ2tKPogBJ7XJZuSKz8LXzKmfU
         iFeKboaeuN9N5hx9HO5wOie4JAKevWRJBNnCNP8JKmO/K1Gt9VNbXQ0W/U24pVnMch2v
         ncfxjAoU/FohoCAW8LKzWEkgLINDoZ9dEMqBD36Omm1BzSlMn+fKgZbrlHii04ZMomJg
         O8cg==
X-Forwarded-Encrypted: i=1; AJvYcCWDWoOM8GjFWsrS2iyiXlgNGMMfcI9pPqEsKbcNFvbZvQ9KVwATpJu7eiF8xZ05Mj1hLKPjBDlS2Fw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx7f+hjJWrJOAl7HbW0xkFE7AQgYqknPG1rBs9jOTYYoatUl16z
	ZRA2OyI0EJwwq1o3TuUhcOU8FGuJpKXAfSRj6B2WYO3oJPOBdS0IUWeJjOcSyRJjjmITIFN8Krt
	lx4LsG4f1LgjmfOfNTEg8LtpZhHx2/e0=
X-Gm-Gg: ASbGncs97AHcZc5DeQ0O1HUgyLjTDs0uJ5EITTkB8q3xwM2Z6vkNUTiEnF1eS/xeHzy
	QJYDUYT1BibNg1vouUuq7ffCTdYVMCUhRgNCGqgUQYQDzWmiTBa4CCa5YV7C4Fk5HSj6uyvQYcZ
	OjmJBHgesUXis3PrcM/llEu89lWPzimtV+wNd+V2xI
X-Google-Smtp-Source: AGHT+IFsm2tvurGpV6S9c/mffNQzY7lacVCeLiBr9sF1kqRLjiaOobxR/tppTikGRjkS75pY5iAZl/fWZH4Yt0GumWA=
X-Received: by 2002:a05:690c:dc2:b0:70f:253d:f278 with SMTP id
 00721157ae682-711753bfb1amr56955057b3.15.1749921948798; Sat, 14 Jun 2025
 10:25:48 -0700 (PDT)
MIME-Version: 1.0
References: <20250321092451.17309-1-jgross@suse.com> <20250321092451.17309-10-jgross@suse.com>
In-Reply-To: <20250321092451.17309-10-jgross@suse.com>
From: Jason Andryuk 
Date: Sat, 14 Jun 2025 13:25:37 -0400
X-Gm-Features: AX0GCFurZKeqceyFP1qWkjYxiZaE69qGk71jjZj86ABOSfJdhRWdqne40IdwWk8
Message-ID: 
Subject: Re: [MINI-OS PATCH 09/12] mm: change set_readonly() to change_readonly()
To: Juergen Gross 
Cc: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org, 
	samuel.thibault@ens-lyon.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 21, 2025 at 5:31=E2=80=AFAM Juergen Gross  wro=
te:
>
> Rename set_readonly() to change_readonly() and add a parameter
> specifying whether it should set the kernel to readonly or to writable.
> At the same time move the boundary setting from the only caller into
> the function itself, avoiding the need to use the same boundaries in
> future, when it will be called to set the kernel to writable again.
> Make the function globally visible in order to allow calling it from
> kexec coding later.
>
> Merge clear_bootstrap() into change_readonly() and undo its setting of
> page 0 to invalid when setting the kernel writable.
>
> Signed-off-by: Juergen Gross 

Reviewed-by: Jason Andryuk 


From xen-devel-bounces@lists.xenproject.org Sat Jun 14 17:26:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jun 2025 17:26:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1015746.1393278 (Exim 4.92)
	(envelope-from )
	id 1uQUeY-0002rc-HK; Sat, 14 Jun 2025 17:26:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1015746.1393278; Sat, 14 Jun 2025 17:26:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uQUeY-0002rU-DA; Sat, 14 Jun 2025 17:26:50 +0000
Received: by outflank-mailman (input) for mailman id 1015746;
 Sat, 14 Jun 2025 17:26: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 1uQUeX-0002rH-1N
 for xen-devel@lists.xenproject.org; Sat, 14 Jun 2025 17:26:49 +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 beb6e51d-4944-11f0-b894-0df219b8e170;
 Sat, 14 Jun 2025 19:26:46 +0200 (CEST)
Received: by mail-yw1-x1135.google.com with SMTP id
 00721157ae682-70e6bddc30aso27404937b3.0; 
 Sat, 14 Jun 2025 10:26:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: beb6e51d-4944-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749922005; x=1750526805; 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=sJCZ4kEjuHzHgfAjb5QZWRKn5ynqjQ7bSPlRAN8WfrM=;
        b=gvLQ01Jr12sRNOggxlXkgljHyJr0iS8YkorZNxy62zXixJcSjfq+alFmhs4ez2xw5l
         alrpvfPhyJ5lINCZNdi30axM6c7Vhr1aRK+3vM7+MrXnkXuJ8hanAdZoZpfgXQhYDoJB
         DIoIdFYafzb0cW5FBxl43DUTch4FIrEQBhiy/FD1hIs7ehdJ4neyewwNTCSZeRGDZzGb
         e1axEH4FcKRKV7RqwC7GDY8PugqPMBVu/hYo6k0MkaFujdsSA81GMrj1toUkyq88UjRG
         cCNugIg5DYp1PnQRjgywahuidcbDmnBvCT3y9mrnWiGs1QaN53Gr6v6UxS5GyZjiKp6L
         Dqwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749922005; x=1750526805;
        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=sJCZ4kEjuHzHgfAjb5QZWRKn5ynqjQ7bSPlRAN8WfrM=;
        b=j73qNo64sAKv7PrhKs0BSEm9kLzfMrp+A1GU5opZ2yj0hwE7uZAVTatYRuAYpf0HIh
         dwbmgOGDUGyExnqof09eFgitKkCis1DBgSwaui3TeAk7jvlo0FlKF9Azh3eQfFRvf6eB
         PLaq6oOtouOE27V4zDLRhPd0cPo/n6PvLl9xlbOhQDsKxloP64HIq+oxCuAzM6GXzNjk
         iKtGEfSjuDjThfhVnX7fnAWuL6VzZlLbu7+6LuaAbJm0Yvauu0pJ+F5/5CjfgtL7Rjrh
         OqNaVVZjqd4QcE6muq+IwbAxNKOUGtAneRD2mWwFVxqRxiF8+TseYtfdCHCmb5MrAK9W
         OxRg==
X-Forwarded-Encrypted: i=1; AJvYcCU1+4rFXXET2E0nl03LbPYYREr/2LxfJRqyp3nu+qjQ67IBLbwQij9TQ/OPbAXaUyWaMWgUpSS28Wk=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyqnv+kTly8ag5Wu3kzp2RIDYe6YrS2dnMlR/l9wt9GnTA3I2Tm
	YZ2gHHfAbN2W+w2YblocGtl5vwAraDhbOEHlwvJW/ESdh/kJEaQo28/V8uvy+D8eRGWFhMLhcSk
	/JnQIApr0Rn3bO0VmHt+MEUtVLixxFUOQ7w==
X-Gm-Gg: ASbGnctQky0JXiVypCeycxyoqKRJp1xCFmFzkvX3XjC/RXy4QyEXT52zTnCqGd3fkfg
	QUyhNJCcY2qXdopdENpUtjJsoYGf0ZzLABxKfBTziM2gkc1MrXrAPSrgD7+9BBHlauoDzzWy864
	0HOcLL7meQVrlxv/OzBQqZsAzsjYQ7RGzXetaUEqfl
X-Google-Smtp-Source: AGHT+IEMALxpsIxc1eV0koLniB8nABNQTVZs7oJx4cD8JykKYVTYUDzGzuDIWZt6Ss52KBvEZEKMqw0MDi6Q1+QKQMQ=
X-Received: by 2002:a05:690c:a8e:b0:70d:f237:6a5a with SMTP id
 00721157ae682-71175383953mr52498777b3.8.1749922004928; Sat, 14 Jun 2025
 10:26:44 -0700 (PDT)
MIME-Version: 1.0
References: <20250321092451.17309-1-jgross@suse.com> <20250321092451.17309-11-jgross@suse.com>
In-Reply-To: <20250321092451.17309-11-jgross@suse.com>
From: Jason Andryuk 
Date: Sat, 14 Jun 2025 13:26:33 -0400
X-Gm-Features: AX0GCFv_vQ1r_KhhIS-I2AjPO6bAA15N3f0sysGZJIN02eP_RvQ3_B2THRGVnjQ
Message-ID: 
Subject: Re: [MINI-OS PATCH 10/12] kexec: switch read-only area to be writable again
To: Juergen Gross 
Cc: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org, 
	samuel.thibault@ens-lyon.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 21, 2025 at 5:30=E2=80=AFAM Juergen Gross  wro=
te:
>
> In order to allow writing the new kernel, make the readonly area
> covering current kernel text writable again.
>
> Signed-off-by: Juergen Gross 

Reviewed-by: Jason Andryuk 


From xen-devel-bounces@lists.xenproject.org Sat Jun 14 17:35:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jun 2025 17:35:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1015758.1393291 (Exim 4.92)
	(envelope-from )
	id 1uQUmP-0004oY-7P; Sat, 14 Jun 2025 17:34:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1015758.1393291; Sat, 14 Jun 2025 17:34:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uQUmP-0004oQ-4i; Sat, 14 Jun 2025 17:34:57 +0000
Received: by outflank-mailman (input) for mailman id 1015758;
 Sat, 14 Jun 2025 17:34: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 1uQUmO-0004oG-Bc
 for xen-devel@lists.xenproject.org; Sat, 14 Jun 2025 17:34:56 +0000
Received: from mail-yw1-x1131.google.com (mail-yw1-x1131.google.com
 [2607:f8b0:4864:20::1131])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e23c3f24-4945-11f0-a309-13f23c93f187;
 Sat, 14 Jun 2025 19:34:55 +0200 (CEST)
Received: by mail-yw1-x1131.google.com with SMTP id
 00721157ae682-70e767ce72eso27082487b3.1; 
 Sat, 14 Jun 2025 10:34:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e23c3f24-4945-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749922494; x=1750527294; 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=cDhV6xmUYC3b1Y5V49nJvlogNBha3UkbJu2YNvncJsw=;
        b=RFmC8HIvk8/V+kLJEz8hDjyioroD2x7OU1kXGXoF2KeMaq2IgTNZpvqbA3ndBDgjuB
         ns4MCr3fdxAbzYbkmq5Ey4Nv+tYxZCgX6KILLlHeyJUKIRf31KRZY5vMdsw2Bmg9/6qV
         xKU/gnAEfEPVHKtCS22eXvxD4QJpmp/uKbaTpjrcAdSHuNuTM4dfmNnovKGQjOJJoCVN
         BCKzE0c402IogbdlkVUvw3kOQr3QGVSd+jaUAgInU2b/WqWIHoANqAPh80IOREqVvaNk
         1ewC+dKm06dalFMVs8cOaGuHAotm1yvwUODr7KvM6w3AdSZcx4FY9UBMgkb+qV/E4o27
         J0Gg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749922494; x=1750527294;
        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=cDhV6xmUYC3b1Y5V49nJvlogNBha3UkbJu2YNvncJsw=;
        b=dUFoyOAccziwrB2+e/epRmJ/9mVTLTYU3TQ4zxV/p76Pku2oVgsHjp6/L+lcknjGuA
         Gf6ws16D+mmhTWzuyqgemrpCrqwI/aAJBcKr4mp4NUZZaqemWsmCfsOSU3TVaWimNZx1
         74NDm/5jV4Q/CefjYRyD7J2v2bBrEA71w0T/qvx04tCl/tn0kI0zCd73Kk0lkCunSe3P
         FfLfEmPeoCyjgrLK13/5CywtQRglrQZIsXaA4mPjw2uW0Dq5YRc1kDBnUGB02LJObJuN
         SHnbgW87wMCDvum/psv52LtzrBWdneA5IyFpkvPiuSpQFz2NZd/fJKGuY5WlE9H9VoXP
         mCqQ==
X-Forwarded-Encrypted: i=1; AJvYcCW4oZNCAXioQBLxjJ2C7tT08dqzvNaCo7LHzk857zQ42zBP+SMlONTUOGUWz2VikAXNn8wUfGS6Io4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzismVe3kuErZk5VETv0O97BH+pexeaJX+wdh1gf0fcPue4JokA
	VVpdZ0em0h1ZxlI7brFxFaEHAPbgYWq3kj+7UdSDSU3yU9fo/fMv3AYVCCljoTNjoZ613bOedrH
	dCvIK7VLjvMvM1auyXJeA0YdGYpgTV6FWUA==
X-Gm-Gg: ASbGncvDblIXN7+di1ypnfhdarPwnU5xcYvR7PKq4jVH85GxGNFh5jr9PNLrBQeuaEM
	EZpTlCjxv6qtofoi+h/H/++OEqIm+3kUA7TrPCVMnlbcjle4Ggh7iB9uaXKQpquHAAQlA2Dd8VO
	/oEvzBix6zeBg7AY0gHjxrf3mTdOieXTg7HI6vys3Z
X-Google-Smtp-Source: AGHT+IEnUXBHdZZan2t7hZNRwrxb/TNcAcSxV7uKg+6dvle3Ok1rtqBV4i+EiVk9yXrPN55zYZ/42AJ9ZjyntZ+/yn4=
X-Received: by 2002:a05:690c:c11:b0:702:d85:5347 with SMTP id
 00721157ae682-7117555004bmr51919337b3.36.1749922493964; Sat, 14 Jun 2025
 10:34:53 -0700 (PDT)
MIME-Version: 1.0
References: <20250321092451.17309-1-jgross@suse.com> <20250321092451.17309-12-jgross@suse.com>
In-Reply-To: <20250321092451.17309-12-jgross@suse.com>
From: Jason Andryuk 
Date: Sat, 14 Jun 2025 13:34:42 -0400
X-Gm-Features: AX0GCFsg2jB4J4zs2QFEH31Q5A472MF0rLBTdx-U_3wX75rW_56ooDO23PVenUU
Message-ID: 
Subject: Re: [MINI-OS PATCH 11/12] kexec: add kexec callback functionality
To: Juergen Gross 
Cc: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org, 
	samuel.thibault@ens-lyon.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 21, 2025 at 5:32=E2=80=AFAM Juergen Gross  wro=
te:
>
> Add a kexec_call() macro which will provide the capability to register
> a function for being called when doing a kexec() call. The called
> functions will be called with a boolean parameter "undo" indicating
> whether a previous call needs to be undone due to a failure during
> kexec().
>
> The related loop to call all callbacks is added to kexec().
>
> Signed-off-by: Juergen Gross 

> diff --git a/arch/x86/mm.c b/arch/x86/mm.c
> index f4419d95..26ede6f4 100644
> --- a/arch/x86/mm.c
> +++ b/arch/x86/mm.c
> @@ -529,7 +529,8 @@ void change_readonly(bool readonly)
>  #endif
>      }
>
> -    printk("setting %p-%p readonly\n", &_text, &_erodata);
> +    printk("setting %p-%p %s\n", &_text, &_erodata,
> +           readonly ? "readonly" : "writable");

Oh, I think this belongs in the earlier change.

With that moved, this one (and the earlier one still)

Code wise:
Reviewed-by: Jason Andryuk 

But this kexec_call() macro isn't actually used?  xenstore needs this
to prepare for kexec?

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Sat Jun 14 17:39:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jun 2025 17:39:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1015771.1393308 (Exim 4.92)
	(envelope-from )
	id 1uQUr4-0005TB-Sf; Sat, 14 Jun 2025 17:39:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1015771.1393308; Sat, 14 Jun 2025 17:39: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 1uQUr4-0005T4-PZ; Sat, 14 Jun 2025 17:39:46 +0000
Received: by outflank-mailman (input) for mailman id 1015771;
 Sat, 14 Jun 2025 17:39: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 1uQUr3-0005R1-Fl
 for xen-devel@lists.xenproject.org; Sat, 14 Jun 2025 17:39:45 +0000
Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com
 [2607:f8b0:4864:20::b2e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8e474e72-4946-11f0-a309-13f23c93f187;
 Sat, 14 Jun 2025 19:39:43 +0200 (CEST)
Received: by mail-yb1-xb2e.google.com with SMTP id
 3f1490d57ef6-e733cd55f9eso3000258276.1; 
 Sat, 14 Jun 2025 10:39:43 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8e474e72-4946-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749922783; x=1750527583; 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=jijwjlD7zMTQfj9ZUPoSFQPOyjJf+ju9Q9eltfAr+i0=;
        b=NEXBkN7bHPY5v+oDgJ2fUJKlsliRLRWK7WXocGsAklZvI4xdlPt6itJ1b3yOrk2E1i
         gZj/4Dq/hlBjyy0lfKGNdUAhfqjNflcT+3nO0Ankfy8UX3o7pviuNTpLcZLFJzpmE9aq
         8zTgBAlRUtZj6HniRxuAWf5uKGijZU5SnysBIVHMPUqpOUkfukyTMrU6Uvo2jGnlQwv1
         vdpKRUQYZ/Ey3K8zRag+Q0q2p5lnhaSQ2IwQGrMJu7GYIE8EqY43NPyi7739Tc9s5JKH
         INzB+v0sf9mpaoudlTnWfdlQPKBjAX2VtFhUNcBrRzSpEfteGX5man+pQudd/XXdq7Fo
         t4gw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749922783; x=1750527583;
        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=jijwjlD7zMTQfj9ZUPoSFQPOyjJf+ju9Q9eltfAr+i0=;
        b=Kfb+qUQhQf2AXrNR9OiDr4tJ6LqIxoiQiGhUNDiZydbbHTWqjskWixBAB3R+YsttPc
         b64YZE/L7j9kiA3ljnDZ5sMc0lgjJ+mPi1NNCOeq63m8o9Zp4IQAtcs0ecmgpo4JWb7y
         CXJIIjBpZNUp+qBYh0Y1TY1SNdncIyRseNDM4KJ462a8FOdUcqt7wr+G5QaFKo2MYIMP
         X6Mv+JtRV/2wzPDfh5n4TW6aRBNt1VhivzXL50ba3aRVP6NCFOV17sb4CH1CmsAx2bAN
         xjuaxPR/P7arpkeUg/aZCngL47FVFKwmGzL3XV68M/S/4YvX2fDbZMC8fygLDtZvK+Gf
         xORw==
X-Forwarded-Encrypted: i=1; AJvYcCWp6u5v+AeBsM9jefBgLLKfgQjetAcsXnueJgq1plU/kH81v67xiI4cvyd7zxoJ4zSuMN3niN2YiII=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzKb6ArbcmVw9vgljOulFMKTdJGdEEhy6eRdzTvce5o6TDv8NYQ
	1k9zbMV7buUnHIkBAlKuv1lA5AoaStq+0/KV5rikne3dWsopfEUgR7OXRPlGTKuxPFzjak5j8IX
	1mByyIzwvE0onTYH6zyxy2jgHtxuF9f+oWg==
X-Gm-Gg: ASbGncsgCPnLUAE5Gw2d4ewyZ4qIza8yD6bMbq5mEZk7YJ0rst34F1Vi+HeG2LiVDfu
	4z2AUq6h4RoFjROaCiHmDToSL8tqUL1HCSCdKFKOxbfAklF/ABzkMlQSgwRCPjNcQBVFIg+QIbH
	1jOyK7ush+mXYhgU3M3bcDYbbMKpmc/HSDabh+YJSi
X-Google-Smtp-Source: AGHT+IEguFkYRuTDYpwR+wOtT2AGfqk3ImQrbVLvk0/Pzt5cMnO3ib5w2H1HlfJpZjLABK2GVNFH2+Go8oYA5yVxtdg=
X-Received: by 2002:a05:690c:968e:b0:70d:ffaf:48e1 with SMTP id
 00721157ae682-7117539740emr48321707b3.9.1749922782746; Sat, 14 Jun 2025
 10:39:42 -0700 (PDT)
MIME-Version: 1.0
References: <20250321092451.17309-1-jgross@suse.com> <20250321092451.17309-13-jgross@suse.com>
In-Reply-To: <20250321092451.17309-13-jgross@suse.com>
From: Jason Andryuk 
Date: Sat, 14 Jun 2025 13:39:30 -0400
X-Gm-Features: AX0GCFva5OuwNXiOtNVtyFBSFpS4kWTwv5OKhrzObljnqSvIVGzUBq0rmIGD1TY
Message-ID: 
Subject: Re: [MINI-OS PATCH 12/12] kexec: do the final kexec step
To: Juergen Gross 
Cc: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org, 
	samuel.thibault@ens-lyon.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 21, 2025 at 5:30=E2=80=AFAM Juergen Gross  wro=
te:
>
> With all kexec preparations done, activate the new kernel.
>
> Signed-off-by: Juergen Gross 
> ---
>  kexec.c | 17 +++++++++++++++--
>  1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/kexec.c b/kexec.c
> index 2db876e8..85b09959 100644
> --- a/kexec.c
> +++ b/kexec.c
> @@ -169,6 +169,7 @@ int kexec(void *kernel, unsigned long kernel_size, co=
nst char *cmdline)

> @@ -192,6 +193,13 @@ int kexec(void *kernel, unsigned long kernel_size, c=
onst char *cmdline)
>      if ( ret )
>          goto err;
>
> +    kexec_page =3D (void *)alloc_page();

kexec_page() is referenced already in do_kexec(), but it hasn't been
hooked up yet, right?  I guess that is okay.

If not an ASSERT on 1 page, then allocate KEXEC_SECSIZE?

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 05:40:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 05:40:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016427.1393323 (Exim 4.92)
	(envelope-from )
	id 1uR2aF-0005gf-PO; Mon, 16 Jun 2025 05:40:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016427.1393323; Mon, 16 Jun 2025 05:40: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 1uR2aF-0005gV-KN; Mon, 16 Jun 2025 05:40:39 +0000
Received: by outflank-mailman (input) for mailman id 1016427;
 Mon, 16 Jun 2025 05:40: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 1uR2aE-0005dX-KO
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 05:40:38 +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 6bf5be09-4a74-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 07:40:33 +0200 (CEST)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-ade48b24c97so639847866b.2
 for ; Sun, 15 Jun 2025 22:40:33 -0700 (PDT)
Received: from ?IPV6:2003:e5:872a:8800:5c7b:1ac1:4fa0:423b?
 (p200300e5872a88005c7b1ac14fa0423b.dip0.t-ipconnect.de.
 [2003:e5:872a:8800:5c7b:1ac1:4fa0:423b])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-adecdcae670sm568395866b.184.2025.06.15.22.40.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 15 Jun 2025 22:40:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6bf5be09-4a74-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750052433; x=1750657233; 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=PtGa9BiltSEfCE6pUkFJ0nmDG9QdCpI+jRCiUubRb+8=;
        b=OTyBG0gu1dvYV1divgUSVeyjaC7/bGPMcaVn6vmH2K2pBmpWlLPSkwqrpVFt6c1ImS
         h8wIUmuyzVyRSf38zplT0UczHPj0jQN0vC298XZsmB2WGPHEeWQnFmpGcheuZMhYcwH4
         a63Rk9gNOQnrwQdtM/vCbXAEhAK+aseBABMQyJ5P1PfeVFxX1ooApOHRsAf8VhcokoXd
         jy9cy/PrbreTK8ygPHNj9D/3N8DHDzBBgtPBPjQVWWDL8Otnx5tYd/h/X5MIAp/KACcc
         ZF1mC3Cv/ilLWq65yqkzB6GY3XFEICsXPFld6dDW1tsfl8AFKSKFfqKEakR7TnK266PR
         UuUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750052433; x=1750657233;
        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=PtGa9BiltSEfCE6pUkFJ0nmDG9QdCpI+jRCiUubRb+8=;
        b=hV23oo0JXkp7Z9z5rx9ENCAWvxz79SGmM/5URqSrI+Fsvw3sgK0gD7UFpevBIS1Rva
         eKWR2vAWuAHQk2e8B2YH0xY+gxtET2QhdqRar4v7aA9flvfoY6fRxYPFZyz2xeo1g3E0
         /Pdvk8/hmCqrLRJR9L74NiYMTpQhGXnG2N1zReBHp4f3iTzbocelvMAxXvftxSdhpvxK
         /PPLYktYiop9jHLCjetpUKp4MTUYiklwqKxNncAOnokBgFjsTxad8ULU8Y0nfs29dkNo
         f9kwueNA5x+q/RtxMF6dUkTwueE8CLNo29BE1AzrDck1MwNePNA+6i9aPa8wQrJk9mIb
         6XAA==
X-Forwarded-Encrypted: i=1; AJvYcCXOTPgQUy1DCSEkTikRl0KDSN4LTqifhfv7uYWy94yaT5umNt2ICskI2SvlYnTAIAL3L5v0I0BH+e0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwDI6UH9+sChPnw0PyxUwwfHpFiwCUmAocRYkVaOJcHGqyiuC2z
	r/uLTQXksizUbrywZQ+WBEIsXOvgwbFUeipXx3bEbJhIYTNZfRHS57teTn024qtlYxc=
X-Gm-Gg: ASbGncvGa498UnFcruMM/kXc693hREEsJSTH64Lg4/WKq2otGKxV98Thmdts2qW0OAa
	qidMkUDrA9OmfuQ7nJSa2adrQ06Rt70/0KIqKxbKNuLBy791312/nbE90qbPv33Dkqs8osztTa1
	eYTcVlubIAX/eXTJt1mFvcnbqgpiqBx6+0B+jdFrjpS11/t0I91+HmgeAa1zlvAu20wJnKWTyX+
	wPKnA4fbrnmpwqjFWSjsqGYdYonYTG4/qOORzD9eteUU7AGSyDkUvjFhyOU0CmGfiGa8qyY+1bf
	o5O4iVzjH3lJD6w5ONjQ5xAfD9MNswY9o4fYS7rrpvmqq7WeUor/0Zt0PD0rse4x77sidi57C51
	azwObY2xGWK2dlyhNO2T4Pv7THJUxXk6xAk11lUB6qivfRr04b97TtHqx0C3LSfF4OPM6VVVjKO
	bmCd3tJfsqg5c=
X-Google-Smtp-Source: AGHT+IHmNIqU4mrDdCTj2UAWLWI8Q/UKK3omTAorxv5vfLr3BtPZtmxVVlWlAVrm4CHK/IeEO2hqxw==
X-Received: by 2002:a17:907:2da9:b0:ad8:a935:b907 with SMTP id a640c23a62f3a-adfad287d43mr647841466b.8.1750052433081;
        Sun, 15 Jun 2025 22:40:33 -0700 (PDT)
Message-ID: 
Date: Mon, 16 Jun 2025 07:40:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [MINI-OS PATCH 01/12] kexec: add kexec framework
To: Jason Andryuk 
Cc: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org,
 samuel.thibault@ens-lyon.org
References: <20250321092451.17309-1-jgross@suse.com>
 <20250321092451.17309-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="------------c1i91g09BY09HIQD05xjnWJE"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------c1i91g09BY09HIQD05xjnWJE
Content-Type: multipart/mixed; boundary="------------GXQaY9QphCH00dkYtbUAWd00";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Jason Andryuk 
Cc: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org,
 samuel.thibault@ens-lyon.org
Message-ID: 
Subject: Re: [MINI-OS PATCH 01/12] kexec: add kexec framework
References: <20250321092451.17309-1-jgross@suse.com>
 <20250321092451.17309-2-jgross@suse.com>
 
In-Reply-To: 

--------------GXQaY9QphCH00dkYtbUAWd00
Content-Type: multipart/mixed; boundary="------------JQrCHYqapAtOz1SfzK44M06F"

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

SmFzb24sDQoNCnRoYW5rcyBmb3IgaGF2aW5nIGEgbG9vayBhdCB0aGUgc2VyaWVzISBJIHZl
cnkgbXVjaCBhcHByZWNpYXRlIHRoYXQhDQoNCk9uIDE0LjA2LjI1IDE4OjQwLCBKYXNvbiBB
bmRyeXVrIHdyb3RlOg0KPiBPbiBGcmksIE1hciAyMSwgMjAyNSBhdCA1OjI14oCvQU0gSnVl
cmdlbiBHcm9zcyA8amdyb3NzQHN1c2UuY29tPiB3cm90ZToNCj4+DQo+PiBBZGQgYSBuZXcg
Y29uZmlnIG9wdGlvbiBDT05GSUdfS0VYRUMgZm9yIHN1cHBvcnQgb2Yga2V4ZWMtaW5nIGlu
dG8gYQ0KPj4gbmV3IG1pbmktb3Mga2VybmVsLiBBZGQgYSByZWxhdGVkIGtleGVjLmMgc291
cmNlIGFuZCBhIGtleGVjLmggaGVhZGVyLg0KPj4NCj4+IEZvciBub3cgYWxsb3cgQ09ORklH
X0tFWEVDIHRvIGJlIHNldCBvbmx5IGZvciBQVkggdmFyaWFudCBvZiBtaW5pLW9zLg0KPj4N
Cj4+IFNpZ25lZC1vZmYtYnk6IEp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT4NCj4+
IC0tLQ0KPiANCj4gDQo+PiBkaWZmIC0tZ2l0IGEvYXJjaC94ODYvdGVzdGJ1aWxkL2FsbC15
ZXMgYi9hcmNoL3g4Ni90ZXN0YnVpbGQvYWxsLXllcw0KPj4gaW5kZXggOGFlNDg5YTQuLjk5
YmE3NWRkIDEwMDY0NA0KPj4gLS0tIGEvYXJjaC94ODYvdGVzdGJ1aWxkL2FsbC15ZXMNCj4+
ICsrKyBiL2FyY2gveDg2L3Rlc3RidWlsZC9hbGwteWVzDQo+PiBAQCAtMTksMyArMTksNSBA
QCBDT05GSUdfQkFMTE9PTiA9IHkNCj4+ICAgQ09ORklHX1VTRV9YRU5fQ09OU09MRSA9IHkN
Cj4+ICAgIyBUaGUgZm9sbG93aW5nIGFyZSBzcGVjaWFsOiB0aGV5IG5lZWQgc3VwcG9ydCBm
cm9tIG91dHNpZGUNCj4+ICAgQ09ORklHX0xXSVAgPSBuDQo+PiArIyBLRVhFQyBvbmx5IHdp
dGhvdXQgUEFSQVZJUlQNCj4gDQo+IE1heWJlOiAiS0VYRUMgbm90IGltcGxlbWVudGVkIGZv
ciBQQVJBVklSVCI/DQoNCkZpbmUgd2l0aCBtZS4NCg0KPiANCj4+ICtDT05GSUdfS0VYRUMg
PSBuDQo+IA0KPj4gZGlmZiAtLWdpdCBhL2tleGVjLmMgYi9rZXhlYy5jDQo+PiBuZXcgZmls
ZSBtb2RlIDEwMDY0NA0KPj4gaW5kZXggMDAwMDAwMDAuLjUzNTI4MTY5DQo+PiAtLS0gL2Rl
di9udWxsDQo+PiArKysgYi9rZXhlYy5jDQo+PiBAQCAtMCwwICsxLDYyIEBADQo+IA0KPj4g
Kw0KPj4gKyNpbmNsdWRlIDxlcnJuby5oPg0KPj4gKyNpbmNsdWRlIDxtaW5pLW9zL29zLmg+
DQo+PiArI2luY2x1ZGUgPG1pbmktb3MvbGliLmg+DQo+PiArI2luY2x1ZGUgPG1pbmktb3Mv
a2V4ZWMuaD4NCj4+ICsNCj4+ICsvKg0KPj4gKyAqIEdlbmVyYWwgYXBwcm9hY2ggZm9yIGtl
eGVjIHN1cHBvcnQgKFBWSCBvbmx5KSBpcyBhcyBmb2xsb3dzOg0KPj4gKyAqDQo+PiArICog
LSBOZXcga2VybmVsIG5lZWRzIHRvIGJlIGluIG1lbW9yeSBpbiBmb3JtIG9mIGEgRUxGIGZp
bGUgaW4gYSB2aXJ0dWFsDQo+IA0KPiAiaW4gdGhlIGZvcm0gb2YgYW4gRUxGIGJpbmFyeSIN
Cj4gDQo+PiArICogICBtZW1vcnkgcmVnaW9uLg0KPiANCj4gTWF5YmUganVzdCAiVGhlIG5l
dyBrZXJuZWwgbmVlZHMgdG8gYmUgYW4gRUxGIGJpbmFyeSBsb2FkZWQgaW50byB0aGUNCj4g
TWluaS1PUyBhZGRyZXNzIHNwYWNlIj8NCg0KVGhlICJ2aXJ0dWFsIG1lbW9yeSByZWdpb24i
IGlzIHF1aXRlIGltcG9ydGFudCwgYXMgdGhpcyBhbGxvd3MgdG8gaGFuZGxlDQpjb25mbGlj
dHMgd2l0aCB0aGUgdGFyZ2V0IG1lbW9yeSBsYXlvdXQgb24gYSBwZXItcGFnZSBiYXNpcy4N
Cg0KPiANCj4+ICsgKiAtIEEgbmV3IHN0YXJ0X2luZm8gc3RydWN0dXJlIGlzIGNvbnN0cnVj
dGVkIGluIG1lbW9yeSB3aXRoIHRoZSBmaW5hbA0KPj4gKyAqICAgbWVtb3J5IGxvY2F0aW9u
cyBpbmNsdWRlZC4NCj4+ICsgKiAtIEFsbCBtZW1vcnkgYXJlYXMgbmVlZGVkIGZvciBrZXhl
YyBleGVjdXRpb24gYXJlIGJlaW5nIGZpbmFsaXplZC4NCj4+ICsgKiAtIEZyb20gaGVyZSBv
biBhIGdyYWNlZnVsIGZhaWx1cmUgaXMgbm8gbG9uZ2VyIHBvc3NpYmxlLg0KPj4gKyAqIC0g
R3JhbnRzIGFuZCBldmVudCBjaGFubmVscyBhcmUgdG9ybiBkb3duLg0KPj4gKyAqIC0gQSB0
ZW1wb3Jhcnkgc2V0IG9mIHBhZ2UgdGFibGVzIGlzIGNvbnN0cnVjdGVkIGF0IGEgbG9jYXRp
b24gd2hlcmUgaXQNCj4+ICsgKiAgIGRvZXNuJ3QgY29uZmxpY3Qgd2l0aCBvbGQgYW5kIG5l
dyBrZXJuZWwgb3Igc3RhcnRfaW5mby4NCj4+ICsgKiAtIFRoZSBmaW5hbCBrZXhlYyBleGVj
dXRpb24gc3RhZ2UgaXMgY29waWVkIHRvIGEgbWVtb3J5IGFyZWEgYmVsb3cgNEcgd2hpY2gN
Cj4+ICsgKiAgIGRvZXNuJ3QgY29uZmxpY3Qgd2l0aCB0aGUgdGFyZ2V0IGFyZWFzIG9mIGtl
cm5lbCBldGMuDQo+PiArICogLSBDcjMgaXMgc3dpdGNoZWQgdG8gdGhlIG5ldyBzZXQgb2Yg
cGFnZSB0YWJsZXMuDQo+PiArICogLSBFeGVjdXRpb24gY29udGludWVzIGluIHRoZSBmaW5h
bCBleGVjdXRpb24gc3RhZ2UuDQo+PiArICogLSBBbGwgZGF0YSBpcyBjb3BpZWQgdG8gaXRz
IGZpbmFsIGFkZHJlc3Nlcy4NCj4+ICsgKiAtIFByb2Nlc3NpbmcgaXMgc3dpdGNoZWQgdG8g
MzItYml0IG1vZGUgd2l0aG91dCBhZGRyZXNzIHRyYW5zbGF0aW9uLg0KPiANCj4gTWF5YmUg
IkNQVSBpcyBzd2l0Y2hlZCB0byAzMi1iaXQgbW9kZSB3aXRoIHBhZ2luZyBkaXNhYmxlZC4i
Pw0KDQpPa2F5Lg0KDQo+IA0KPiBJcyB0aGUgZm9sbG93aW5nIG1lbW9yeSBsYXlvdXQgY29y
cmVjdD8NCj4gDQo+IFsgMCAuLi4gOE1CIF0gLi4uIFsgWCAuLi4gWCArIFkgXSAuLi4gWyBa
IC4uLiAgICAgIF0NCj4gICBPbGQgc3R1YmRvbSAgICAgICAgTmV3IHN0dWJkb20gICAgICAg
ICBrZXhlYyBjb2RlDQoNCldpdGg6DQpPOiBvbGQgc3R1YmRvbSBrZXJuZWwNClA6IGFjdGl2
ZSBwYWdlIHRhYmxlcw0KTjogbmV3IHN0dWJkb20ga2VybmVsDQpaOiBrZXhlYyBjb2RlLg0K
DQpUaGUgZ3Vlc3QgcGh5c2ljYWwgbWVtb3J5IGxheW91dCBpcyBtb3JlIGxpa2U6DQpPUE9P
T05QLk5OLk4uTk5OLi5aTk4uLlBQLi4NCg0KVGhlIHRhcmdldCBsYXlvdXQgb2YgdGhpcyBl
eGFtcGxlIChiZWZvcmUgdGhlIGZpbmFsIGtleGVjIHN0YWdlKSB3aWxsIGJlOg0KTy5PT08u
Li4uTi5OLk5OTlAuWk5OUC5QUE5ODQoNCk5vdGUgdGhhdCBhbGwgY29uZmxpY3RpbmcgTiBh
bmQgUCBlbnRyaWVzIGhhdmUgYmVlbiBtb3ZlZCB0byBhIHBvc2l0aW9uDQpiZWhpbmQgdGhl
IHRhcmdldCBwb3NpdGlvbiBvZiB0aGUgbmV3IGtlcm5lbC4gVGhpcyBpbmNsdWRlcyB0aGUg
cGFnZQ0KdGFibGVzIGluIHRoZSBvbGQga2VybmVsIHdoaWNoIHdlcmUgcHJlLXBvcHVsYXRl
ZCBhdCBib290IHRpbWUuDQoNCkFuZCBiZWZvcmUgcGFzc2luZyBjb250cm9sIHRvIHRoZSBu
ZXcga2VybmVsIGl0IHdpbGwgYmU6DQpOTk5OTk5OTk4uLi4uLi4uLi5aLi4uLi4uLi4NCg0K
PiBrZXhlYyBjb2RlIGNvcGllcyBOZXcgc3R1YmRvbSB0byAwIGFuZCBsYXRlciBqdW1wcyB0
byBOZXcgc3R1YmRvbSBAIDANCg0KS2luZCBvZi4gVGhlICIwIiBpcyBub3QgaGFyZCB3aXJl
ZCBpbiB0aGUga2V4ZWMgY29kZS4NCg0KPiBUaGUgdGVtcG9yYXJ5IHBhZ2UgdGFibGVzIGFy
ZSB0byBhbGxvdyBvbGQgc3R1YmRvbSBhbmQga2V4ZWMgY29kZSB0bw0KPiBiZSBjYWxsZWQg
d2hpbGUgb3ZlcndyaXRpbmcgdGhlICJPbGQgc3R1YmRvbSIgcmFuZ2Ugd2hpY2ggd291bGQN
Cj4gaW5jbHVkZSB0aGUgcGFnZSB0YWJsZXMgb3JpZ2luYWxseSB1c2VkPyAgT3IgaXQgY2Fu
IG9ubHkgcnVuIHRoZSBrZXhlYw0KPiBjb2RlIG9uY2Ugb2xkIHN0dWJkb20gaXMgb3Zlcndy
aXR0ZW4sIHJpZ2h0Pw0KDQpZZXMuDQoNCkkganVzdCByZWFsaXplZCB0aGF0IHNvbWUgb2Yg
dGhlIGNvbW1lbnRzIGFyZSBzdGFsZSBub3cuIFRoZSBjdXJyZW50DQppbXBsZW1lbnRhdGlv
biBkb2Vzbid0IHNldHVwIGEgbmV3IHNldCBvZiBwYWdlIHRhYmxlcywgYnV0IGlzIHR3ZWFr
aW5nDQp0aGUgZXhpc3Rpbmcgb25lIHRvIGF2b2lkIGNvbmZsaWN0cy4NCg0KPiBJIHRoaW5r
IHNvbWUgY29tbWVudHMgdHdlYWtzIHdvdWxkIGJlIGhlbHBmdWwsIGJ1dCBjb2RlLXdpc2UN
Cj4gZXZlcnl0aGluZyBpcyBva2F5LCBzbzoNCj4gDQo+IFJldmlld2VkLWJ5OiBKYXNvbiBB
bmRyeXVrIDxqYXNvbi5hbmRyeXVrQGFtZC5jb20+DQoNClRoYW5rcywNCg0KDQpKdWVyZ2Vu
DQo=
--------------JQrCHYqapAtOz1SfzK44M06F
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-----

--------------JQrCHYqapAtOz1SfzK44M06F--

--------------GXQaY9QphCH00dkYtbUAWd00--

--------------c1i91g09BY09HIQD05xjnWJE
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/Ey8FAmhPrk8FAwAAAAAACgkQsN6d1ii/Ey87
fggAhswXmpvmF9HUuRnYGL/ul17z+fyh4TY2YMfllJc1W2v9MO9hbm/u9KUauFZpQsCDV8KxChjg
csfsPpkzWAMPl9wRMFllp9J5XyFNnemntadytKA8L2qZx68CsFMC6CgISM55of2AaU7TaniLI4pN
vVrEtmPShUTjGF3K41IZiFgPWcZppMaKPWhCXTRF12wZMppoa3EYjNIDTgr+/2sg3E41AohbTzBL
LJDOjXWHUP0TnQPztDHIpo6gnrwfuy7S67pTS4aj0OlQ1UoI9ZDaCNou97fRMszJSRhwLGZbX+GG
P2B+J0qHPl/6Q33pZ0I07argTwD1hXsZHXAQs6hBpg==
=I9Js
-----END PGP SIGNATURE-----

--------------c1i91g09BY09HIQD05xjnWJE--


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 05:57:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 05:57:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016439.1393333 (Exim 4.92)
	(envelope-from )
	id 1uR2qw-0007Tx-4c; Mon, 16 Jun 2025 05:57:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016439.1393333; Mon, 16 Jun 2025 05: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 1uR2qw-0007Tq-0t; Mon, 16 Jun 2025 05:57:54 +0000
Received: by outflank-mailman (input) for mailman id 1016439;
 Mon, 16 Jun 2025 05:57: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 1uR2qu-0007Tk-Or
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 05:57:53 +0000
Received: from AM0PR83CU005.outbound.protection.outlook.com
 (mail-westeuropeazlp170100001.outbound.protection.outlook.com
 [2a01:111:f403:c201::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d38e34f2-4a76-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 07:57:46 +0200 (CEST)
Received: from DUZPR01CA0235.eurprd01.prod.exchangelabs.com
 (2603:10a6:10:4b5::19) by AM9PR08MB5908.eurprd08.prod.outlook.com
 (2603:10a6:20b:283::12) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.30; Mon, 16 Jun
 2025 05:57:43 +0000
Received: from DU2PEPF00028D10.eurprd03.prod.outlook.com
 (2603:10a6:10:4b5:cafe::6) by DUZPR01CA0235.outlook.office365.com
 (2603:10a6:10:4b5::19) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.27 via Frontend Transport; Mon,
 16 Jun 2025 05:57:45 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) 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.8835.15
 via Frontend Transport; Mon, 16 Jun 2025 05:57:43 +0000
Received: from AM0PR08MB2978.eurprd08.prod.outlook.com (2603:10a6:208:66::17)
 by GV1PR08MB10752.eurprd08.prod.outlook.com (2603:10a6:150:15e::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Mon, 16 Jun
 2025 05:57:07 +0000
Received: from AM0PR08MB2978.eurprd08.prod.outlook.com
 ([fe80::d3b0:d923:6dfc:822c]) by AM0PR08MB2978.eurprd08.prod.outlook.com
 ([fe80::d3b0:d923:6dfc:822c%4]) with mapi id 15.20.8835.027; Mon, 16 Jun 2025
 05:57: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: d38e34f2-4a76-11f0-b894-0df219b8e170
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=LEvYiqUdG0F2w8d502SAeear/fjjAfW/cVDewwVhp53Ym0HPkeeBqfjzyoM/GWjJxtX0yDYYXtYisZAnKMQgMCc2UhAA/+h8JWLxUPOrlMXHjscvEYujhQ0/T6I+IkRkjWSA0GDlEEhvyp0BtH+Sjz5/FP6bxN4QhdD+G+WnD2pZEDm+VrtW08ghrTY4s9mR4EkfcSupPWFbLwroHMCZlRSZPFa0BfaTnZqqMEkeqmjTbPOygbaL9HIQyZMiaSIOA5MEdGXbOOiWvHe27xgounbCHLZmpnaqbaQ+C9NyZ4h9ufuu+dRX4rPDvvIgQFnOz9/oxBVUNDpBEeCj0YQOhQ==
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=sztFwjggV4UNJ2Hc1FrZKNJw+nI5bTE2MBT88wTcXgY=;
 b=BeLJ9Ea9XgktpUR0Ji902fN/CZgLXTPrn5Qw57f+frr1mYJZfjxcA4b9pvHCu1/EfGVbQyXEjfkRL04Wp72ou7HWyap2yDFgEO7KOH8KcDek420VUTpHCeVISPcMaVsLe1ADkvzjFvtdTsE1CFDukz2UwUtoSlVQhLiaZI+oraK17E6ggfQX7gGsEJrDYLaQPtAvuEZJ0PP87JrD8dPAwwJOj35/TMoL4oWB8d7I/G3wv3T+zxYAT/1FzVBrdVrnVK6AMG/BBDStaeTzqSfC1mtTVbFaV7UB2P7gHypzqIEEgZR2toOcixPa8lqZ0Gnj6H8xYPLnvUfhp7gwmk/fQg==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=amd.com smtp.mailfrom=arm.com; dmarc=pass
 (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
 (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=sztFwjggV4UNJ2Hc1FrZKNJw+nI5bTE2MBT88wTcXgY=;
 b=NkBGb2kHz2QzvyLDnFW+gekZQkP4LJJvguFXC+RLtPOgSXHW0e36pOzizFmxR9YnKT/jVUV+jbPmjEAWCZP5BjTWkWPyn/+NO14CSznAWmlFRKGafNPfHrAfn6Cp5fdODneY658SP21nACP/slOs2S84099FZdCfM50s5TYLEKg=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=jTopw+b+IYE7d+9SU/2Lilfg5LGrMBtYx4VEHnkchMqZJ77BFzMVBN5dhXIcNnko9uwfTeBwgVjNc/NDLX+DGsKXCi7S7lTSaJgt/sDJfss7khdPMmjiStCesX9qhuaj88zeR8/Nc+DORfT4mZZLjZA+K4BN5AOdvz/HTJTkvmW2eHPCU5bsIfOnb6deOWXgOrPuzeoPyGQyk/xrUsRhZZ/pm3UyQfvqvibNyPIyn9Kkt8lJJyiiU/hCoJliOu0yFS2jHrbRT+/KhvDZk4C/UjuG9lXEUMS08MzrkAIHNW2PZV/r1nJHkt75a/coUWtxH5UGUjlQ2CdNmBJ5265iYQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=sztFwjggV4UNJ2Hc1FrZKNJw+nI5bTE2MBT88wTcXgY=;
 b=npVCA3vhGm86pV1VvS6UABnIhbDgUm9Xtoc6qhoSs5NCoh3ZwtLT2P3jABhTnxXLE7RUrZqypzsQThKnuGEKSAlv9YwqrmbBucEBR4MN8juA+5EBA4jS2wRBK4hOHGVc8hT7v2sYnXBOXxa88HGuuC1Lx4WEaYRpWRzrDR/q9JO++4P1FlzgIWJrpvCMYfC6KBKv+5Nski1NdFqsEHowE1aQLMGNumJedh7k0b+v22Of29ynJ0iidxcj7+DpI/zvIzGlPWsCEf0rZ8qHx450usaA5XHsfda1a2aU1wy5ok+bYOHIJXwiRcDcE/XxrmfBP5OWEbIPZrgmy0l1HZlnCg==
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=sztFwjggV4UNJ2Hc1FrZKNJw+nI5bTE2MBT88wTcXgY=;
 b=NkBGb2kHz2QzvyLDnFW+gekZQkP4LJJvguFXC+RLtPOgSXHW0e36pOzizFmxR9YnKT/jVUV+jbPmjEAWCZP5BjTWkWPyn/+NO14CSznAWmlFRKGafNPfHrAfn6Cp5fdODneY658SP21nACP/slOs2S84099FZdCfM50s5TYLEKg=
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 v3 6/6] arm/mpu: Enable read/write to protection regions
 for arm32
Thread-Topic: [PATCH v3 6/6] arm/mpu: Enable read/write to protection regions
 for arm32
Thread-Index: AQHb2t7jddptbtJu60em4gEBgB1jlLQFURgA
Date: Mon, 16 Jun 2025 05:57:06 +0000
Message-ID: <4E45B90D-AE21-40C9-9543-3890FBECA276@arm.com>
References: <20250611143544.3453532-1-ayan.kumar.halder@amd.com>
 <20250611143544.3453532-7-ayan.kumar.halder@amd.com>
In-Reply-To: <20250611143544.3453532-7-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.600.51.1.1)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	AM0PR08MB2978:EE_|GV1PR08MB10752:EE_|DU2PEPF00028D10:EE_|AM9PR08MB5908:EE_
X-MS-Office365-Filtering-Correlation-Id: 73df25a7-0205-4d7d-a915-08ddac9ab5df
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?991NRl2jAvF0rZb3XtmdHnXsVxOJx5jxJjtrYtL/yAW46VUPKkKawAkuIqoc?=
 =?us-ascii?Q?mHHzaFexcP331Nir5TV5yojzme00Z4mvNZRf87e1zIV67WjRpRLPgjnOeRhK?=
 =?us-ascii?Q?K95q95xaKGvZehGRGsyKllOtoy6pBt0OeyMfAEwmP+liM52B4CKgeVMFXCWc?=
 =?us-ascii?Q?85etBaJRIBl+dhWF+U6If12ZsScuxvAh0xDChw8Qmx1//iqGef2VuH4gmX5D?=
 =?us-ascii?Q?dSG7fPOah8MVeJTYh7Dg0kE/fkrXyazSF6xnnyW3p3UwdTQ5EA7wYbKtLA58?=
 =?us-ascii?Q?1Gw5sVi6e2jb6UtS7xWag+swx8DHG6uX1Dr9C88EvDUjYSYc4NJhlYxwMcZl?=
 =?us-ascii?Q?ZCiY0fGmP3Z9MjWfRpQQ+vf1Y4/v2gXgI1BEXIBcG5oyXCu4VWZIyczUg8DR?=
 =?us-ascii?Q?2WNCVzNsrSIMv2p4f9V9PIlq91r9yTyf7s8rqmiSg7pWN2YuA/fEABEoaj6Q?=
 =?us-ascii?Q?5u+57Rmps7DHbzUVjLHm4tH4tXxSf5UCsyUqBOtYDSl9zpnEY7jRbXuDVIhE?=
 =?us-ascii?Q?EgMN619yi1ENxG3Z2MwQYqcH36tzmCf9m2xzQDPqlwkvfCslu0F5lgas7Bzu?=
 =?us-ascii?Q?W/zOwG4RDQZI4PCBsBPTXDZEe7mnVlXzrwZhSRcObuJ9LF2fWecuLrC2Yg3Q?=
 =?us-ascii?Q?Ej9FqX/JQLDKZofp3PNV6YWEOV2TSFXmEbdjjKa4rguY/ecCNfQ3tcr7EEYR?=
 =?us-ascii?Q?aeaVYkoViIRqx3nU3w9VhlRwBqI+GC8FOKLDEmb88N2jqj2Mwq8ElmA4k6A+?=
 =?us-ascii?Q?xmY0E3eZUx7uSh1BVmeyQ3/QJ3gPSO0lrzv+AqZTNaeekd4BttQia4oEdfKf?=
 =?us-ascii?Q?8biYBZ2Td9KW0cA7PZgOhZhWFVaLcv2tafMWF9sGVNNo61gjUe8AWEuVo6z8?=
 =?us-ascii?Q?mzL9Cm8K2XIMhzIv5iR+7SaldM77V/c88PYeWNpUf0PY3sowfFUACOPyWWTi?=
 =?us-ascii?Q?dgPmE2JL3ZIlcjVbBGh64OiDJhzOzap9DNiftvLVlueQnw1eQc39qZAHteuh?=
 =?us-ascii?Q?4x7kfIuQcj7BLKiPe4eHTcP3QmZ5rYuhtJQB9anNEkBcHq1DiwoW/cpX5L1Y?=
 =?us-ascii?Q?VxeFolLJDAbJFFo7364n6TlC1UThc7nuoRhSeCZFROU5a8BtVLGpERx/4YWe?=
 =?us-ascii?Q?ncjvUZtUieWELEyVLTpFD54lhZdMpnBAkTl/1HD6s1RjNChto+p3eJL+fc9C?=
 =?us-ascii?Q?YD4OSF/nfSSyzqEH8lPPBQusRdy8u7C3hGipnjVrK5kldfZjAHhzbuz6JxUq?=
 =?us-ascii?Q?2VIGX0BGAY4Lhu/1sBqrRThJRZcBCgYUNFcV7yV+Mt46WtPIPlOD9cI+bVxT?=
 =?us-ascii?Q?Ft4C/B2FrD2IR4GtzWl7os8llez/aBjVWZDFbRJSZY/4WV71WbsBdj21k5ru?=
 =?us-ascii?Q?7LeD1XayN4N9kibxsh4zl15KHibuNAlHv3f/c9/vbN4hzARhJEMMyxjewWKY?=
 =?us-ascii?Q?BrqnAaljHJvThDNEwxN8P9SJ27QNFDoxmkm+bWynF+bCq0cHNyDILQ=3D=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM0PR08MB2978.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: <0D92A7FE1164524B80BAFDD0B71357C4@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR08MB10752
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DU2PEPF00028D10.eurprd03.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	051c60f1-b681-40dc-431b-08ddac9aa02d
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|35042699022|82310400026|1800799024|14060799003|376014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?jBrmgOo68kXxaStbO84Uz20GIztFWDcuOnh5+UuzcRePUawCW6r6uXKV0IyH?=
 =?us-ascii?Q?oIBbJDIe+D6mFct5j6WLTkA436dd14SYhXX4vKyHh+vxyjkgW8SsRCqV4Hg2?=
 =?us-ascii?Q?C7rlOgvM6zAxmpt3TqmTdU3C7zxxSqqF8L/owIHTP2iv/69WqlumMN50Ybh+?=
 =?us-ascii?Q?qiROIhJ+4Yrvy+j9y6IOi3OUXidoUg3eAlvjjocTbG6enns5qPivNtbgIVHc?=
 =?us-ascii?Q?6OXCEEUiGTtx2AHGYX5ugaMw/zCbOl1el8aXo2qijhwnTLPFt7103pGjApMP?=
 =?us-ascii?Q?taY0JkOw3U/0PuzCUCdxz5QPD1vW6HTA3Wk7PYhjbqt8mSDM/BnS7ylRzOMr?=
 =?us-ascii?Q?SvwfYDrzKeqh4+glS2tZ1psv3RRMUqaJduKIaMPP7M5ZISU44Pq/DXiyYEpd?=
 =?us-ascii?Q?Nwb0aappwosJm8selFKTeSYKQDF7P2RKNAOg+dP6k3zk7il6pMbn/T2+0oUS?=
 =?us-ascii?Q?7ZMCtvX6DUuu05ZXiCMjoZxBbhyhiJyGbHG3RG0YnsmjIDQRhDmIOLfoRUui?=
 =?us-ascii?Q?YGmdcjI9Tc2Mg9twWvCSZcVmc3UnSJGSXieb4+jb2KZFjuYZPhbC+Zz1P44u?=
 =?us-ascii?Q?cS0S57POEbeYL0njsgawyc10d5IE9qFZaTlRR+aKgFsgD/npi8JvmLwOnyg8?=
 =?us-ascii?Q?TNzXylNVaWvGCuNBcZyFTGKCXJXndYYm/QKOE0Zf1ZqbP+3xiyc2XuwPnZls?=
 =?us-ascii?Q?JaAWuZfYdujfDOWBFji0jcmf4SPGiTZRqJo7qN1oePaPZCTcvKawE9Osx3P9?=
 =?us-ascii?Q?HodvIfOC2q2lwbah9Kh6YizfQiPwsbvMtvOTHosFJZiAWf0axEZKjoXpzeAB?=
 =?us-ascii?Q?NEHh9UKLWbM254DrqGVYNliDS1z1VdvZ/QCSSqN1OQGOH7MgMnyrwhMntrYC?=
 =?us-ascii?Q?GadcLQAOicbv+YpPFql5bqedT7vBYeMmw7fXi04GlINjB0zy2uMn1SvFOjiR?=
 =?us-ascii?Q?orlL3GuQtkAniFZX1NbGe8fU1BxNiXuesJkmB+NS3DHPD6O1BwKRH+FjZNFq?=
 =?us-ascii?Q?UU1rtfQ50D/uIP1L3Lo+lgJDDzqrZ7wPuHD1c9Ghuf/AAGWaUJX3TVaNq2ai?=
 =?us-ascii?Q?dr8UUXizbGj7iqS3ybvgav7BM0sCYlESer8RQcZLttcDoqv0oaCGhGTC9E3J?=
 =?us-ascii?Q?cSk/Umy8DZpWlKbLMCqFOKsXx3oAvF2QuWdr06w9TZvoCRNbo4OQryJAgZzx?=
 =?us-ascii?Q?UxvP+2AOnUjfZniZlHEm+PKiy9SVJP/3U+y8T1FuFn9DMskwHChxHz7lpJO5?=
 =?us-ascii?Q?YkJoiPbOr2/lmboJItnlO0WI/Bk9aLTpF/bexgYm/mRtArfpRcY/woMJ347e?=
 =?us-ascii?Q?5yNKT4miP352LsLWU2i7tv13C7crZR0f8xiTZWRvFtbiLBFgpCxStrLVw9q2?=
 =?us-ascii?Q?dlz8UM76oekTqWrWPF16RBQWoLk4Vq6UII1/dNPlSnAEa6CJeT3HjSrsAFCP?=
 =?us-ascii?Q?4WpjgTN8xnnasdA9c6Qnx18+aFfDTD0uoPT5Kl3U5+r0yjAsBStmj36KAbAM?=
 =?us-ascii?Q?7uuFF5H6tGR8VxBugu/3Qsh9JKBsH0RvQtXt?=
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(35042699022)(82310400026)(1800799024)(14060799003)(376014)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jun 2025 05:57:43.1808
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 73df25a7-0205-4d7d-a915-08ddac9ab5df
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DU2PEPF00028D10.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR08MB5908

Hi Ayan,

> On 11 Jun 2025, at 15:35, Ayan Kumar Halder  w=
rote:
>=20
> Define prepare_selector(), read_protection_region() and
> write_protection_region() for arm32. Also, define
> GENERATE_{READ/WRITE}_PR_REG_OTHERS to access MPU regions from 32 to 255.
>=20
> Enable pr_{get/set}_{base/limit}(), region_is_valid() for arm32.
> Enable pr_of_addr() for arm32.
>=20
> Signed-off-by: Ayan Kumar Halder 
> ---
> Changes from :-
>=20
> v1 - 1. Enable write_protection_region() for aarch32.
>=20
> v2 - 1. Enable access to protection regions from 0 - 255.
>=20
> xen/arch/arm/include/asm/mpu.h  |   2 -
> xen/arch/arm/mpu/arm32/Makefile |   1 +
> xen/arch/arm/mpu/arm32/mm.c     | 165 ++++++++++++++++++++++++++++++++
> xen/arch/arm/mpu/mm.c           |   2 -
> 4 files changed, 166 insertions(+), 4 deletions(-)
> create mode 100644 xen/arch/arm/mpu/arm32/mm.c
>=20
> diff --git a/xen/arch/arm/include/asm/mpu.h b/xen/arch/arm/include/asm/mp=
u.h
> index 8f06ddac0f..63560c613b 100644
> --- a/xen/arch/arm/include/asm/mpu.h
> +++ b/xen/arch/arm/include/asm/mpu.h
> @@ -25,7 +25,6 @@
>=20
> #ifndef __ASSEMBLY__
>=20
> -#ifdef CONFIG_ARM_64
> /*
>  * Set base address of MPU protection region.
>  *
> @@ -85,7 +84,6 @@ static inline bool region_is_valid(const pr_t *pr)
> {
>     return pr->prlar.reg.en;
> }
> -#endif /* CONFIG_ARM_64 */
>=20
> #endif /* __ASSEMBLY__ */
>=20
> diff --git a/xen/arch/arm/mpu/arm32/Makefile b/xen/arch/arm/mpu/arm32/Mak=
efile
> index e15ce2f7be..3da872322e 100644
> --- a/xen/arch/arm/mpu/arm32/Makefile
> +++ b/xen/arch/arm/mpu/arm32/Makefile
> @@ -1 +1,2 @@
> obj-y +=3D domain-page.o
> +obj-y +=3D mm.o
> diff --git a/xen/arch/arm/mpu/arm32/mm.c b/xen/arch/arm/mpu/arm32/mm.c
> new file mode 100644
> index 0000000000..5d3cb6dff7
> --- /dev/null
> +++ b/xen/arch/arm/mpu/arm32/mm.c
> @@ -0,0 +1,165 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define PRBAR_EL2_(n)   HPRBAR##n
> +#define PRLAR_EL2_(n)   HPRLAR##n
> +
> +#define GENERATE_WRITE_PR_REG_CASE(num, pr)                             =
    \
> +    case num:                                                           =
    \
> +    {                                                                   =
    \
> +        WRITE_SYSREG(pr->prbar.bits & ~MPU_REGION_RES0, PRBAR_EL2_(num))=
;   \
> +        WRITE_SYSREG(pr->prlar.bits & ~MPU_REGION_RES0, PRLAR_EL2_(num))=
;   \

I was also thinking that in this file now you can use directly HPR{B,L}AR instead of PR{B,L}AR_EL2

Cheers,
Luca=


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 05:58:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 05:58:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016449.1393343 (Exim 4.92)
	(envelope-from )
	id 1uR2ry-00081p-Fq; Mon, 16 Jun 2025 05:58:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016449.1393343; Mon, 16 Jun 2025 05: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 1uR2ry-00081i-Cz; Mon, 16 Jun 2025 05:58:58 +0000
Received: by outflank-mailman (input) for mailman id 1016449;
 Mon, 16 Jun 2025 05:58: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 1uR2rx-0007qW-FK
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 05:58:57 +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 fd39090b-4a76-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 07:58:56 +0200 (CEST)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-ad56cbc7b07so592462066b.0
 for ; Sun, 15 Jun 2025 22:58:56 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-adec81c0135sm586975766b.47.2025.06.15.22.58.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 15 Jun 2025 22:58:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fd39090b-4a76-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750053536; x=1750658336; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=jLx6ksudvbagyxfFpNwotUpr8FoEFp9Gcp/OrQhnumQ=;
        b=FsQ5/uf32Pn/dHblxY4DhSBliM/gc000gw/IPnjQsQKn5UTopoMR0rDg3iDcO4QejF
         LSFTjmC4GQemu52QLHXVOWluLgwQ+3P3/hLM7oiSLAKdwS43Qs13q/vsRKx0Ba1+xusN
         ogHV+9NapT3kmoWPmsVQ1K41D/byzQhHuhhOWdDavfAfNLjz/jtdmlMDtoIOFD2m8WEt
         1grkZavyequkW0Hb5nCocLEtFw4Jj9AdVWVeWJYHyENsGtdGbHEZWGHb3BKUJhVK/1qj
         54KOYYT45DCANqFlqBz7Es1jaMJmSTcu9XCB8o0GJgUu5eRb0QYuZREFPexC1snyK5A8
         AHNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750053536; x=1750658336;
        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=jLx6ksudvbagyxfFpNwotUpr8FoEFp9Gcp/OrQhnumQ=;
        b=fZLdXzNXPUcVy/rfFz6yumhbqI2ovKtLjB+A2wtZg6FRfI1pz7OnDRtRhpVz51YorA
         Kp0xyel2Rx3Drqz8oQ/BYjph3l+7PjGAMJSeSLqaovfuP11gtu21ZbaGYgLSdPwT5f1o
         8ndqq8QR+nJVTNEqIEKZFKRzSiwl6QcmTKPV5h0e8S2X6cyjRT2tbZVWa1Zp/j3huzl7
         CwHyzF8lqc29CZ11uT2r8JaRMOhJldObP73M73py+guPfFp28tO/qubl3ENzszswsFM/
         g2+Q2gwMAVBEQ349jL+ZlwMc5Homhx99dAJZYQpC2coLDBxSNpdMDT8CO9kIKebU4017
         cZoQ==
X-Forwarded-Encrypted: i=1; AJvYcCVImwxaIvaJZQhOznAtE1i9/6FLyxeTOhfv7HR+DFjEgFxUFNTRBFw5tJ/LpzbQvhgogzKScHcN9bM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy0D+tA02xCMLbvd3qxFqixCZmXxj4mn01hWSAnL1ofZayxS2vw
	paGW1tao9IILPLVZ46XGvHdJLC2KUMaTA46MfLq3inCqNlrU3tdv6KMsshCbxUvrsg==
X-Gm-Gg: ASbGncvJyGQ2/LKnDkeg7EPxXjAuK7R+BTDDYA96IM7gAexgC7n9hL9a5VEtYAJo2pA
	d8LU1utHwbULOMUUC4OLYJDUFH7xwO8zzrgS91nlwlzF4aVCyZGl1M4yvdej/DxkMrDeqPFj8AN
	LFiefIUOGdk4LyFmrwhysS3kVf8pk8krQHnmXL5UvndRmoPUESNDAyaB3BdJfpkzBZVA077DUoU
	l/jEb513FmabUIi0JK4UcHHj25UqehKgaq4L+hlWeH/osMulubiulWjFAPFmCDbuSBBBoG/YdYU
	lqCI8iuV8qEIhI7HKMJYauLT/Zcy4pnLvoHPqmazIFuHI2wPJlgfhHDoNg0F/DOFMHopQU0cFoV
	UZW4VIgl27GYlwLFuuDOdI7UaEVHg6V9hIHiFuOSl5JASSPA=
X-Google-Smtp-Source: AGHT+IFBc/QwE3hNQaVSDohAWIhYtXzPRNtwq3XqNsyWmCEPomw3q4cdNPBwzKPsuHzwfCiE3s/FzQ==
X-Received: by 2002:a17:907:3d8b:b0:ad2:43b6:dd75 with SMTP id a640c23a62f3a-adfad2a1ff8mr707130366b.10.1750053535746;
        Sun, 15 Jun 2025 22:58:55 -0700 (PDT)
Message-ID: <3ef3ed9d-d6af-4621-ab4c-eb2ea88081b3@suse.com>
Date: Mon, 16 Jun 2025 07:58:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/4] xen: Add DOMAIN_CAPS_DEVICE_MODEL &
 XEN_DOMCTL_CDF_device_model
To: Stefano Stabellini 
Cc: Jason Andryuk ,
 Christian Lindig , David Scott
 , Anthony PERARD ,
 Andrew Cooper ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Bertrand Marquis ,
 Volodymyr Babchuk ,
 "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org
References: <20250610225737.469690-1-jason.andryuk@amd.com>
 <20250610225737.469690-4-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 14.06.2025 00:47, Stefano Stabellini wrote:
> On Wed, 11 Jun 2025, Jan Beulich wrote:
>> On 11.06.2025 00:57, Jason Andryuk wrote:
>>> To add more flexibility in system configuration add the new
>>> DOMAIN_CAPS_DEVICE_MODEL flag and XEN_DOMCTL_CDF_device_model.
>>>
>>> Thie new flag corresponds to allowing XSM_DM_PRIV for the domain.  This
>>> will enable running device model emulators (QEMU) from the assigne
>>> domain for multiple target domains.
>>>
>>> Stubdoms assign target allowing the stubdom to serve as the device
>>> model for a single domain.  This new flag allows the single domain to
>>> provide emulators for multiple guests.
>>>
>>> The specific scenario is a disaggregated system with the hardware domain
>>> providing device models for muitple guest domains.
>>
>> Why the hardware domain? Unless a DM also needs access to some of the
>> physical hardware, it ought to run in a separate domain. Conceivably
>> such a domain could service multiply guests, so maybe the "single
>> target" concept presently used for stubdom simply needed extending?
> 
> Not necessarily. While it is possible to have driver domains, it is not
> the default configuration.
> 
> In a default configuration, the hardware domain gets all the hardware by
> default and therefore will also run the PV backends and Virtio backends.
> The Virtio backends require DM hypercalls. Let me elaborate further.
> 
> In the datacenter, we have Dom0 typically with all the hardware, the
> backends (PV and Virtio), and also the toolstack. Then all other domains
> are created dynamically by the toolstack. Driver domains are possible
> but not very common.
> 
> In automotive/embedded, the total number of domains is static, so we can
> create them using dom0less. We don't need the toolstack to create VMs.
> Also, we have safety concerns, so we want to take away as much
> privileges as possible from Dom0.

At least purely by the wording, this ...

> This is easy because thanks to
> dom0less, we don't need the toolstack and we don't need to create VMs
> dynamically.
> 
> So the model is that Dom0 becomes the hardware domain: it has all the
> drivers and backends but it is not privileged in the sense of
> creating/destroying other VMs. If a user wants to have Dom0 "super
> powers", they can create an optional Control Domain. The Control Domain
> is expected to be tiny, such as XTF or Zephyr. It will have the ability
> that Dom0 used to have but without the drivers. From a privilege
> perspective, the Control Domain could create additional VMs, but in
> automotive/embedded it is not expected to be a use-case because the
> total number of VMs is still static. 
> 
> So your point about driver domains. Yes, one can have driver domains the
> same way that one can have driver domains in the datacenter but it is
> not the default.

... kind of contradicts this: Running e.g. qemu in Dom0 gives Dom0 quite
a bit of extra privilege. (And no, the term "driver domain" does not
describe a domain running DMs, imo.)

Jan

> The new default for embedded is what I described above
> and I think it is a very widely applicable concept across industries:
> automotive, industrial, robotics, etc. and also across vendors: AMD,
> Xilinx, Renesas, EPAM, ARM, etc.



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 06:13:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 06:13:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016465.1393356 (Exim 4.92)
	(envelope-from )
	id 1uR36N-0002cR-OU; Mon, 16 Jun 2025 06:13:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016465.1393356; Mon, 16 Jun 2025 06:13: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 1uR36N-0002cK-LL; Mon, 16 Jun 2025 06:13:51 +0000
Received: by outflank-mailman (input) for mailman id 1016465;
 Mon, 16 Jun 2025 06:13: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 1uR36M-0002cE-MY
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 06:13:50 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 10d11d3d-4a79-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 08:13:48 +0200 (CEST)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-601dfef6a8dso6813500a12.1
 for ; Sun, 15 Jun 2025 23:13:48 -0700 (PDT)
Received: from ?IPV6:2003:e5:872a:8800:5c7b:1ac1:4fa0:423b?
 (p200300e5872a88005c7b1ac14fa0423b.dip0.t-ipconnect.de.
 [2003:e5:872a:8800:5c7b:1ac1:4fa0:423b])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-adfb80d6dc4sm358587366b.22.2025.06.15.23.13.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 15 Jun 2025 23:13:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 10d11d3d-4a79-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750054428; x=1750659228; 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=QAzBmuiIef1zA4biE5+aFtJ5DvgQft2xrm39rHrsYkU=;
        b=KxlBATOhcnnGMQYtgt3gq8Npo1s0oMnswworiaVZRPUZliNLNWjG4AYpaOa4DWt8hc
         QEXBGrFFObt4D1lgcX1JOdxODGsR2T81g5Nh2A0OqC2pLojXvUNJPUN4qN3KHiFMx6s2
         Py9UUhPn/qs5W0fUGMSc/DNmnIQAGQoUqBzVin1CuQbNB5Uz2l3OezQzaVCikB+VFSSH
         orm4tvWvCK34bfMWo7quiUH6FvZxA1zMytcdJ4eJh8FPIFLyhjMGoZF6569/NtBNY6rH
         0Y4xRqq/46r54AzUVBzLYbs2SBguzyGQRV41GSOse6KWhQmx0xWTXaU8y3Hw54+xzcSr
         NyBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750054428; x=1750659228;
        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=QAzBmuiIef1zA4biE5+aFtJ5DvgQft2xrm39rHrsYkU=;
        b=eMjDO27W8qcy2IDg6URPUXx+WDVBS95CY45utPjuSmWVCQD4C1QA1G5MxTJ7iNCwC9
         DOZ9J3DFD6zyAWFz6Q6PZxV5rAff0OxGUkYP+gFbfstyDzOtVgkIvKc3N2+AMyyBz8x1
         U+4gPXJ1o3EHQiHyqbiR3s9I7Z4xvPeW1JXx7qlGw24y0/g5c2CNndzkCWVSJbe/6YYR
         3p1awTobDagf6pizpGxFcrcl6zCfTAQx1cku+lg82Ke/d2l0Oi4t+nW1AWFoourgo5a5
         ZRdwSEOkvAc63zm7xsam2ew+e2colBe0xLiyTUlrciUeB/VYhWl2KOvNIh31ILRidfko
         yRxQ==
X-Forwarded-Encrypted: i=1; AJvYcCXAMRn9yW9RnLXEgMRLuETmV9CXn3Wa76GMcs/fSXIeJWMU8exgB80f8Xb+klBwtnbI3//+M/NvHXw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxdKMKBiTPo5/e61ZnvuZwbL7NhzQmDFEuTLH8wJY+bGly7cMAT
	moSdI9igUumJc2VMwmRnBrBfAo84LOr531BDBEMq+mzQtq9TNy7kbHky9LTs66mLDPE=
X-Gm-Gg: ASbGncv0JKkFUHQS1B1oCCb/1XQcvC/6kSe5T0IN9cTwxU81/oZ4IAU5mlX4AUChrUB
	RBN/r3X7eFnvCZmDf014aMFcQJTKFvhHqfkxSLcBYEyW1sAKum78Ks8jo7IYKdmpTns0sGBVGIA
	j69sSibrEg6z7eb6wU/WS3CBzZiitjnol1FCyJk65d+nQw8AjPGV6sTqHELkKxGdiNMn4u0RiIs
	CgbOA1ZoYCZ04vneCfse3mL5ihHw1ojb76w4HNXhaXplO4+FhYLN+HtkefDwkAH8jQoCOUISxzi
	/5ZeXLNyX25T1JSdZOR+rdkC0R8ztvc4P7oe88UY0x34A8io4KzSGokJ82hsNr8IExgbBn1hzG3
	z4Z+6KxkzyYWYklnW5k4x4v/xzCHkv9OwSoGBDFpVJxZVctvJ3lLct0NaxKfHucrRpsSDww/4dV
	00W6hca49ZgjQ=
X-Google-Smtp-Source: AGHT+IEsoHdPHs2GbHpJGfUiGgmexR2PZ6Zvdk+XC1uIxahYob5BezXWFK2gKm+98V4dM3aeloeTfQ==
X-Received: by 2002:a17:907:7248:b0:ada:4b3c:ea81 with SMTP id a640c23a62f3a-adfad48c061mr660330366b.39.1750054427628;
        Sun, 15 Jun 2025 23:13:47 -0700 (PDT)
Message-ID: <468294fd-8804-4099-866c-8ca98436e29a@suse.com>
Date: Mon, 16 Jun 2025 08:13:46 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [MINI-OS PATCH 02/12] kexec: add final kexec stage
To: Jason Andryuk 
Cc: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org,
 samuel.thibault@ens-lyon.org
References: <20250321092451.17309-1-jgross@suse.com>
 <20250321092451.17309-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="------------NhHe0hrQN32VlncWTXtpMlTE"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------NhHe0hrQN32VlncWTXtpMlTE
Content-Type: multipart/mixed; boundary="------------o04JBRKygnJKUQJx7M3oXwZV";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Jason Andryuk 
Cc: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org,
 samuel.thibault@ens-lyon.org
Message-ID: <468294fd-8804-4099-866c-8ca98436e29a@suse.com>
Subject: Re: [MINI-OS PATCH 02/12] kexec: add final kexec stage
References: <20250321092451.17309-1-jgross@suse.com>
 <20250321092451.17309-3-jgross@suse.com>
 
In-Reply-To: 

--------------o04JBRKygnJKUQJx7M3oXwZV
Content-Type: multipart/mixed; boundary="------------mGWeHJsTq5uDFwWtBfE5XXXM"

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

T24gMTQuMDYuMjUgMTg6NDAsIEphc29uIEFuZHJ5dWsgd3JvdGU6DQo+IE9uIEZyaSwgTWFy
IDIxLCAyMDI1IGF0IDU6MjXigK9BTSBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+
IHdyb3RlOg0KPj4NCj4+IEFkZCB0aGUgY29kZSBhbmQgZGF0YSBkZWZpbml0aW9ucyBvZiB0
aGUgZmluYWwga2V4ZWMgc3RhZ2UuDQo+Pg0KPj4gUHV0IHRoZSBjb2RlIGFuZCByZWxhdGVk
IGRhdGEgaW50byBhIGRlZGljYXRlZCBzZWN0aW9uIGluIG9yZGVyIHRvIGJlDQo+PiBhYmxl
IHRvIGNvcHkgaXQgdG8gYW5vdGhlciBsb2NhdGlvbi4gRm9yIHRoaXMgcmVhc29uIHRoZXJl
IG11c3QgYmUgbm8NCj4+IGFic29sdXRlIHJlbG9jYXRpb25zIGJlaW5nIHVzZWQgaW4gdGhl
IGNvZGUgb3IgZGF0YS4NCj4+DQo+PiBCZWluZyBmdW5jdGlvbmFsbHkgcmVsYXRlZCwgYWRk
IGEgZnVuY3Rpb24gZm9yIGFkZGluZyBhIGZpbmFsIGtleGVjDQo+PiBhY3Rpb24uDQo+Pg0K
Pj4gU2lnbmVkLW9mZi1ieTogSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1c2UuY29tPg0KPiAN
Cj4+IC0tLSAvZGV2L251bGwNCj4+ICsrKyBiL2FyY2gveDg2L2tleGVjLmMNCj4+IEBAIC0w
LDAgKzEsMTA5IEBADQo+IA0KPj4gKw0KPj4gKy8qDQo+PiArICogRmluYWwgc3RhZ2Ugb2Yg
a2V4ZWMuIENvcGllcyBhbGwgZGF0YSB0byB0aGUgZmluYWwgZGVzdGluYXRpb25zLCB6ZXJv
ZXMNCj4+ICsgKiAuYnNzIGFuZCBhY3RpdmF0ZXMgbmV3IGtlcm5lbC4NCj4+ICsgKiBNdXN0
IGJlIGNhbGxlZCB3aXRoIGludGVycnVwdHMgb2ZmLiBTdGFjaywgY29kZSBhbmQgZGF0YSBt
dXN0IGJlDQo+PiArICogYWNjZXNzaWJsZSB2aWEgaWRlbnRpdHkgbWFwcGVkIHZpcnR1YWwg
YWRkcmVzc2VzICh2aXJ0ID09IHBoeXMpLiBDb3B5aW5nDQo+PiArICogYW5kIHplcm9pbmcg
aXMgZG9uZSB1c2luZyB2aXJ0dWFsIGFkZHJlc3Nlcy4NCj4+ICsgKiBObyByZWxvY2F0aW9u
cyBpbnNpZGUgdGhlIGZ1bmN0aW9uIGFyZSBhbGxvd2VkLCBhcyBpdCBpcyBjb3BpZWQgdG8g
YW4NCj4+ICsgKiBhbGxvY2F0ZWQgcGFnZSBiZWZvcmUgYmVpbmcgZXhlY3V0ZWQuDQo+IA0K
PiAicGFnZSIgaXMgc3RhdGVkIGhlcmUuICBEbyB3ZSBuZWVkIGFuIEFTU0VSVCBsYXRlcj8N
Cg0KR29vZCBpZGVhLiBJJ2xsIGFkIGFuIEFTU0VSVCgpIHRvIHRoZSBsaW5rZXIgc2NyaXB0
IGluIG9yZGVyIHRvIGNhdGNoDQpzdWNoIGFuIGlzc3VlIGF0IGJ1aWxkIHRpbWUuDQoNCj4g
DQo+PiArICovDQo+IA0KPj4gK3ZvaWQgZG9fa2V4ZWModm9pZCAqa2V4ZWNfcGFnZSkNCj4+
ICt7DQo+PiArICAgIHVuc2lnbmVkIGxvbmcgYWN0aW9uczsNCj4+ICsgICAgdW5zaWduZWQg
bG9uZyBzdGFjazsNCj4+ICsgICAgdW5zaWduZWQgbG9uZyBmaW5hbDsNCj4+ICsgICAgdW5z
aWduZWQgbG9uZyBwaHlzOw0KPj4gKw0KPj4gKyAgICBhY3Rpb25zID0gZ2V0X2tleGVjX2Fk
ZHIoa2V4ZWNfcGFnZSwga2V4ZWNfYWN0aW9ucyk7DQo+PiArICAgIHN0YWNrID0gZ2V0X2tl
eGVjX2FkZHIoa2V4ZWNfcGFnZSwga2V4ZWNfc3RhY2sgKyBLRVhFQ19TVEFDS19MT05HUyk7
DQo+PiArICAgIGZpbmFsID0gZ2V0X2tleGVjX2FkZHIoa2V4ZWNfcGFnZSwga2V4ZWNfZmlu
YWwpOw0KPj4gKyAgICBwaHlzID0gZ2V0X2tleGVjX2FkZHIoa2V4ZWNfcGFnZSwga2V4ZWNf
cGh5cyk7DQo+PiArDQo+PiArICAgIG1lbWNweShrZXhlY19wYWdlLCBfa2V4ZWNfc3RhcnQs
IEtFWEVDX1NFQ1NJWkUpOw0KPj4gKyAgICBhc20oImNsaVxuXHQiDQo+PiArICAgICAgICAi
bW92ICUwLCAlJSJBU01fU1AiXG5cdCINCj4+ICsgICAgICAgICJtb3YgJTEsICUlIkFTTV9B
UkcxIlxuXHQiDQo+PiArICAgICAgICAibW92ICUyLCAlJSJBU01fQVJHMiJcblx0Ig0KPj4g
KyAgICAgICAgImptcCAqJTMiDQo+PiArICAgICAgICA6Ij1tIiAoc3RhY2spLCAiPW0iIChh
Y3Rpb25zKSwgIj1tIiAocGh5cykNCj4gDQo+IEFyZW4ndCB0aGVzZSBpbnB1dHMgYW5kIG5v
dCBvdXRwdXRzPw0KDQpPaCwgb2YgY291cnNlIHRoZXkgYXJlLg0KDQo+IA0KPj4gKyAgICAg
ICAgOiJtIiAoZmluYWwpKTsNCj4+ICt9DQo+PiArDQo+PiArI2VuZGlmIC8qIENPTkZJR19L
RVhFQyAqLw0KPiANCj4gDQo+PiBkaWZmIC0tZ2l0IGEvaW5jbHVkZS9rZXhlYy5oIGIvaW5j
bHVkZS9rZXhlYy5oDQo+PiBpbmRleCA2ZmQ5Njc3NC4uNzIyYmU0NTYgMTAwNjQ0DQo+PiAt
LS0gYS9pbmNsdWRlL2tleGVjLmgNCj4+ICsrKyBiL2luY2x1ZGUva2V4ZWMuaA0KPj4gQEAg
LTEsNyArMSwzNCBAQA0KPiANCj4+ICsNCj4+ICtpbnQga2V4ZWNfYWRkX2FjdGlvbihpbnQg
YWN0aW9uLCB2b2lkICpkZXN0LCB2b2lkICpzcmMsIHVuc2lnbmVkIGludCBsZW4pOw0KPj4g
Kw0KPj4gKyNkZWZpbmUgS0VYRUNfU0VDU0laRSAoKHVuc2lnbmVkIGxvbmcpX2tleGVjX2Vu
ZCAtICh1bnNpZ25lZCBsb25nKV9rZXhlY19zdGFydCkNCj4gDQo+IEFkZCBhIGJ1aWxkIGFz
c2VydGlvbiBoZXJlPyAgT3IgbWF5YmUgdGhlIGNvcnJlY3QgYW1vdW50IGlzIGFsbG9jYXRl
ZA0KPiBhbmQgaXQgZG9lc24ndCBtYXR0ZXIuDQo+IA0KPiBHZW5lcmFsbHkgbG9va3MgZ29v
ZC4NCg0KVGhhbmtzLA0KDQoNCkp1ZXJnZW4NCg==
--------------mGWeHJsTq5uDFwWtBfE5XXXM
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-----

--------------mGWeHJsTq5uDFwWtBfE5XXXM--

--------------o04JBRKygnJKUQJx7M3oXwZV--

--------------NhHe0hrQN32VlncWTXtpMlTE
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/Ey8FAmhPthoFAwAAAAAACgkQsN6d1ii/Ey9x
vQf9FHWDZhZbXkRCBZMbeoNTDAo65rsG7pjRV4Jut6NnlgdtFuSA97IKaSGu1b0uGr3/+NwgXUjF
3wczE0qltxMtjLP2R6ecMGAMvDLVlZYfQWHNzDj6AxAEkt+/pVsrerFxLLP05bSjl5x/bEsrg1kI
VnQaGFgUSgv+Ck94T7WJ63eqMOFRsH+WDloAStyUP7CUbfQYdf4I/0p02XGuDy2kcXx3H9wzTfno
4LnJwQhcQWr0gWKdadVNher6kUxAy7n6tiyFqEiy8rS+nyIRk8d1TmurpWcuCT8sb1Qu2p59N1+s
jUM2ybi8bjkPTdWVn3Vz+vLrr44UV2pCQonY/mYYFg==
=sbpA
-----END PGP SIGNATURE-----

--------------NhHe0hrQN32VlncWTXtpMlTE--


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 06:27:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 06:27:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016481.1393370 (Exim 4.92)
	(envelope-from )
	id 1uR3Ju-0004Ul-Vb; Mon, 16 Jun 2025 06:27:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016481.1393370; Mon, 16 Jun 2025 06: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 1uR3Ju-0004Ue-S3; Mon, 16 Jun 2025 06:27:50 +0000
Received: by outflank-mailman (input) for mailman id 1016481;
 Mon, 16 Jun 2025 06:27: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 1uR3Jt-0004UY-3j
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 06:27:49 +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 04540091-4a7b-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 08:27:46 +0200 (CEST)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-ad89c32a7b5so626664766b.2
 for ; Sun, 15 Jun 2025 23:27:46 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-adec88ff1a1sm589809066b.89.2025.06.15.23.27.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 15 Jun 2025 23:27:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 04540091-4a7b-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750055266; x=1750660066; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=JfU75DuIdo9Kgu/QrbsMWKdVFXqewUQLfKGYI3wuzEI=;
        b=b0qIac6CBA0wWrMQQkHzWDmO43hbjUg3vr9IMPUKQdU0w5OJjEvzlUM5/YVBtFaq5t
         b0XAQTAMRQD0IFGQWwZ8aiND2H/c1jh9ChzKMPQ63KqDcCZoT+/z3xJe/JJbySM1KRXx
         xnlJcLJYIF5QZiZ5dMxRheB2AcJeiziz/Z3ZmtxCKyJdXSjj2ss4Sdatn70wWFO3z556
         S14qo23jLo0Cjl+gwfazbqBLexFmsSiNe5UoAAGb9+/VQ3Ha5Qx2EaI50HHJo98gC5h+
         mzs9jLwugJjsWSFMBUDpmGSJmEvs4FdThe3VIxq8OTd7kEYdRunh3rMruN8Ve2m9ASTG
         U55A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750055266; x=1750660066;
        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=JfU75DuIdo9Kgu/QrbsMWKdVFXqewUQLfKGYI3wuzEI=;
        b=c/6VyF0E+ct0frdFp/LwZNc2FFa3AzAnGNXN90YJ/wWbFHcPVbQV0T/wN6CtV4rO3t
         MP5ILIx7eDf0Okujx13S/G48RYVLLTlaWSO9XkU9wtEYFMZFy2u+s5m8lgLfFIsg5YEd
         W5s+dwLx81KRfN67Vh4fMtCUt961XlnpsEIMGaeENIv5dADRqfTz4pz/AkIfz3RigJrT
         bFtp69+SA9aSbZ6QBRSXYDwV6MvIvG6eZFlROI05fCurheAVrgjvtJ94qNn4JEumC3dP
         FnxdKX61Qb/ahB3W+M7RGyQ7Up30B2RkoZuzb4VE6LwJrxsXJdDVMYUkWJe8yjJRULin
         JY3Q==
X-Forwarded-Encrypted: i=1; AJvYcCU47djK6Piz7uKyClXm9ODbCkEgb04VuaZKg8paok6uE0bxgXcXTidTlOmIFOBOZ7p1sF8W/+IY8qw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YybuDn3H8rLKsrru1VO3+pkZrAVhB7sei9bZJqtVY81PMoCPFLW
	wbfhi7z8jlRHMUaUHqRUjQhNr9Y47Nncqxrt8xC4cbEpoY+9PmW829hMvezvt0AFRg==
X-Gm-Gg: ASbGnct3c6ksWsukbZh1UemuWCmE79rjdVHmZppFzl66WXaWU7WfLwz6tjaCCn09plY
	E0OUkXaF9Sk2wAwVGBDmutEsRn3zaq5cd5o8m87mNaP+XJocHaZad3WJ2wK7Yv1NZpn9kz4d7sm
	ebe6cNym0mtcxoSxmsHQiBwQBnXBGhlfgdWxx0XuUdRcmg/aachft4E0IS2QAklgSTN3QnaOXET
	gr7SUybm5lWXqMagMyKhjpycyHJwM7XRFy4mIx/T7UCpPMsYUDKBD1WpgkbJTU/lTNd5b9UDbbA
	B6FhThvBDv0pjI4RyUInluaOI1fUfcj8VFM8aSaKqlwqXv9gMl4nUfEsODufafId8HAejoPeAJ/
	BXBefI3xIHHhYlBihFNtmSEUUghe75uvjGfBsxH/rbuKSxXU=
X-Google-Smtp-Source: AGHT+IFcX9G7lZBDk4EkJwcPsdTXIeengT650LQjZa1uTOlhLf3lu9uhwgshX3Yml7+Tj3sh/RIehQ==
X-Received: by 2002:a17:907:3ccb:b0:ad8:8364:d4ac with SMTP id a640c23a62f3a-adfad4feca7mr743711166b.55.1750055265729;
        Sun, 15 Jun 2025 23:27:45 -0700 (PDT)
Message-ID: <134c69c8-ccff-475c-8bf7-241ec4805754@suse.com>
Date: Mon, 16 Jun 2025 08:27:46 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/3] x86/EFI: Fix detection of buildid
To: Andrew Cooper 
Cc: Ross Lagerwall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 "Daniel P . Smith" ,
 Xen-devel 
References: <20250605111638.2869914-1-andrew.cooper3@citrix.com>
 <20250605111638.2869914-2-andrew.cooper3@citrix.com>
 <0a314400-126a-4c2a-b36c-dda61bb0b751@suse.com>
 
 <4d1f1b70-e309-453b-bae6-e066d49a417a@suse.com>
 <9200277c-aa8e-4fd9-ab6a-f9e106114f54@citrix.com>
 <6eaf2b27-969a-4326-9726-8b6e0994e006@suse.com>
 <3f9c5a18-2ea1-4e2d-80a0-773abc3598ae@citrix.com>
 
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 13.06.2025 23:28, Andrew Cooper wrote:
> On 10/06/2025 9:01 am, Jan Beulich wrote:
>> On 06.06.2025 17:01, Andrew Cooper wrote:
>>> On 06/06/2025 8:22 am, Jan Beulich wrote:
>>>> And then, based on your reasoning above, why don't you also drop the
>>>> #ifdef CONFIG_X86?
>>> Because that's the one non-buggy way of excluding an impossible case.
>>>
>>> x86 is the only architecture possibly linking with pep emulation, and
>>> therefore the only architecture to possibly have a CodeView record.
>> And how's the, say, Arm case different from the x86 case with no such
>> record built in? 
> 
> Because its currently impossible for ARM to have a codeview record.

There must be some pretty fundamental misunderstanding then: I can only
ask again - how's this different from xen.gz? There's not going to be
CodeView record there, yet still you enable the logic there. Hence the
body of the conditional is unreachable in that case.

To expand on my earlier suggestion (ab)using the "efi" global: With
the linker script having this

#ifdef EFI
  .reloc ALIGN(4) : {
    __base_relocs_start = .;
    *(.reloc)
    __base_relocs_end = .;
  }
#elif defined(XEN_BUILD_EFI)
  /*
   * Due to the way EFI support is currently implemented, these two symbols
   * need to be defined.  Their precise values shouldn't matter (the consuming
   * function doesn't get called), but to be on the safe side both values would
   * better match.  Of course the need to be reachable by the relocations
   * referencing them.
   */
  PROVIDE(__base_relocs_start = .);
  PROVIDE(__base_relocs_end = .);
#else
  efi = .;
#endif

where only the #if applies to xen.efi, can't we (ab)use the combination of the
other two symbols here to decide between xen.efi vs xen.gz?
__base_relocs_{start,efi} won't possibly be equal for xen.efi, except in an
extremely theoretical situation (and we could cover for that case by an ASSERT
in the linker script). Pseudo code:

#ifdef XEN_BUILD_EFI
    if ( __base_relocs_start != __base_relocs_end )
    {
        ...
    }
#endif

IOW that #if could simply replace the CONFIG_X86 one that's there right now.

> Remember that ARM writes a MZ/PE header by hand in a flat binary.  It
> does not use a PEP linker.

Of course. Much like for xen.gz there's no PEP linking involved.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 06:36:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 06:36:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016502.1393382 (Exim 4.92)
	(envelope-from )
	id 1uR3Sb-0006Ol-UZ; Mon, 16 Jun 2025 06:36:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016502.1393382; Mon, 16 Jun 2025 06:36:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uR3Sb-0006Oe-S4; Mon, 16 Jun 2025 06:36:49 +0000
Received: by outflank-mailman (input) for mailman id 1016502;
 Mon, 16 Jun 2025 06:36:48 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uR3Sa-0006OY-ML
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 06:36:48 +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 46614b1d-4a7c-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 08:36:46 +0200 (CEST)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-ad8826c05f2so797813666b.3
 for ; Sun, 15 Jun 2025 23:36:46 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-adfeaed2d10sm25248166b.105.2025.06.15.23.36.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 15 Jun 2025 23:36:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 46614b1d-4a7c-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750055806; x=1750660606; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=pFQeijgzx5FakN/hAjl4IqtirWujbmrpF9iZqvEVeP4=;
        b=Vm3S4GK9pVtpqvk61XwSBQDRlI4E66WZGrRD3MMVMVgPIyqSnZkqA5/AFnH2n5zdB0
         Rv27wp0DOlziBsUnoXwsyCLs1pGM/4i0P8/ORshI/h3X3EwYlx7avOQV2GQ0ttApbTzF
         wLIFZ1OA7aC4Z+IO30yKkJOrsIMEPzKzFq8WrwFxFzeQMKBEw+2DJuwQnCK38uZY+txs
         gIzIA+od6ZMVXovFMb7WaHf6pcch6bytRZ53YdSSjXpQ0N0OIpq9W9jpNtss3aV8aCBd
         csEyG6Ff1U/cp4wBGu2Td6utOzwNc0Ser0zxouIz2q0gU772VhGi4AcrtSZZ3O78QRCt
         bKHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750055806; x=1750660606;
        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=pFQeijgzx5FakN/hAjl4IqtirWujbmrpF9iZqvEVeP4=;
        b=C+aMSL3w0vTgDSP365quFa+8M3Qnbb6C2BN0+ahldGBDq6demBOqa1oQvh6hEgN9hF
         iUR9UfP9suk6qWJJc41LIkV4pPr49slbmfAkwl2ElS6aK8cRg9EVD+IJsMUGDEbyIaBV
         aG53685zgv16+9ptGP63ILoqTIyx3oKuyOTc4Sypronnn2NqvhrRpKMunA0iVVJUsAHy
         LksMuD34nyuJlSKfEjp2Km9fIIDQliReoaR4x7B1eh7iUh9dss/WxmXA1QUZL9xmVfiT
         N4uTtY25NE3hC/mP+ycUBn/iWRA+p+xv5cxtsrO9YK74R68TiOQRSHBSy9XvQBosgaRd
         loXw==
X-Forwarded-Encrypted: i=1; AJvYcCX1Z7kOgEZgkAoHD+OU7NNBQRSB9g7LTjoeal6Gg9+4rPBG/ktmG5mY5iTLe4hV2T5AwhLdiQBjl54=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx2Cr3FIxW4Zjyj1lUqsXxE7LBysq1ksJa08RbEMRxm2REny1Ds
	rlvYb7glVapNSZW9R0P3RS8MFdtp+LUz6u5cOzDkZPep+uc2ThAuipmZsFO2YNmKTw==
X-Gm-Gg: ASbGncvXsOXOmD/vO91s2DX7zYNzWvfAgUaS0VFfINBLnlieYzU66b5eMRw/WxjzGrS
	YMB32MiNOJND3vP0P58e/u417JYFD5jb63Hy2ZtMyh7GXmt4ylcBsjDmHzGPE9B80ACqkMfpWSp
	60sbpQ0JxzJDVDxscD99+WXn/G4dom+LPTscLt+m9R4E+yWyzGKX8/e1GeL4sUIE3S9lV2xX+BH
	2bpl6LWoKh2ACDUJMj534vVBcNsOTaXb1lQH5LVABLpl3pOalPvdedJ6kaTVE7RvIQScUeKOoI8
	Xynslb0Q+FexwrWG2UXRK2wB4ymVumvrp9/HhLp1u+cMQFDHEYH0XVv2qIc1JDuLkAiNBC3zz+D
	t2qzyHuOubvVJGRtTbpJ7MWISnvHMJl4lOtrLz3sK5lSQVa8=
X-Google-Smtp-Source: AGHT+IG47KLzpWhyrpGOiBAR0XfZMApSuMe8JIE4bSttiX2eX9eWC1SLRUVKnjyqX1woQ3x8nIxKXA==
X-Received: by 2002:a17:907:7216:b0:ade:4295:a814 with SMTP id a640c23a62f3a-adfad53f2e2mr766245166b.53.1750055806061;
        Sun, 15 Jun 2025 23:36:46 -0700 (PDT)
Message-ID: 
Date: Mon, 16 Jun 2025 08:36:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 4/4] xsm/dummy: Allow hwdom SYSCTL_readconsole/physinfo
To: Stefano Stabellini ,
 Jason Andryuk 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org
References: <20250610225737.469690-1-jason.andryuk@amd.com>
 <20250610225737.469690-5-jason.andryuk@amd.com>
 <5f6d43da-2600-4c1c-9bcb-f13e8fce921e@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 14.06.2025 00:51, Stefano Stabellini wrote:
> On Wed, 11 Jun 2025, Jason Andryuk wrote:
>> On 2025-06-11 09:27, Jan Beulich wrote:
>>> On 11.06.2025 00:57, Jason Andryuk wrote:
>>>> Allow the hwdom to access the console, and to access physical
>>>> information about the system.
>>>>
>>>> xenconsoled can read Xen's dmesg.  If it's in hwdom, then that
>>>> permission would be required.
>>>
>>> Why would xenconsoled run in the hardware domain? It's purely a software
>>> construct, isn't it? As a daemon, putting it in the control domain may
>>> make sense. Otherwise it probably ought to go in a service domain.
>>
>> My approach has been to transform dom0 into the hardware domain and add a new
>> control domain.  xenconsoled was left running in the hardware domain.
> 
> I think we should keep xenconsoled in the hardware domain because the
> control domain should be just optional. (However, one could say that with
> Denis' recent changes xenconsoled is also optional because one can use
> console hypercalls or emulators (PL011, NS16550) for all DomUs.)
> 
> 
> 
>> I suppose it could move.  Maybe that would be fine?  I haven't tried. The
>> Hyperlaunch code populates the console grants to point at the hardware domain,
>> and I just followed that.
>>
>> One aspect of why I left most things running in the Hardware domain was to not
>> run things in the Control domain.  If Control is the highest privileged
>> entity, we'd rather run software in lower privileged places. Especially
>> something like xenconsoled which is receiving data from the domUs.
> 
> Yes, I agree with Jason. It is a bad idea to run xenconsoled in the
> Control Domain because the Control Domain is meant to be safe from
> interference. We want to keep the number of potential vehicles for
> interference down to a minimum and shared memory between Control Domain
> and DomUs is certainly a vehicle for interference.

As much as it is when xenconsoled runs in the hardware domain? Especially
if the hardware domain is also running e.g. PV backends or qemu instances?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 06:42:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 06:42:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016510.1393403 (Exim 4.92)
	(envelope-from )
	id 1uR3Xk-0008Ol-OV; Mon, 16 Jun 2025 06:42:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016510.1393403; Mon, 16 Jun 2025 06:42: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 1uR3Xk-0008Oe-LT; Mon, 16 Jun 2025 06:42:08 +0000
Received: by outflank-mailman (input) for mailman id 1016510;
 Mon, 16 Jun 2025 06:42: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 1uR3Xj-0008OL-Lc
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 06:42:07 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20603.outbound.protection.outlook.com
 [2a01:111:f403:2412::603])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 034e3134-4a7d-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 08:42:05 +0200 (CEST)
Received: from DS7PR03CA0086.namprd03.prod.outlook.com (2603:10b6:5:3bb::31)
 by SJ1PR12MB6316.namprd12.prod.outlook.com (2603:10b6:a03:455::22) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.37; Mon, 16 Jun
 2025 06:41:59 +0000
Received: from CY4PEPF0000EE3B.namprd03.prod.outlook.com
 (2603:10b6:5:3bb:cafe::d) by DS7PR03CA0086.outlook.office365.com
 (2603:10b6:5:3bb::31) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.35 via Frontend Transport; Mon,
 16 Jun 2025 06:41:59 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CY4PEPF0000EE3B.mail.protection.outlook.com (10.167.242.14) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Mon, 16 Jun 2025 06:41:58 +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; Mon, 16 Jun 2025 01:41:55 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 034e3134-4a7d-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=U7jlSTNVfEByUaKRmV0UjO86HvUKcxE6TEwmciQS8kctlbLywGe3vrYYhqCQ06hLK4jdPW79gMK7aQ+2RXkc8ekoJyerHfcFqHbP1lK8BNSeHKfTNL20ppSo7iZ4xQRkifzoUmGRoc+dAGHKPMcbVg7YeVEyjoNaKmnKlwB2uHB4a2v3ciueb/dGqZdffIfxBJ1ypz6KnosGley7DPD56jND0iOBDbIKLShyHkYap5uiziJUQB1b1Jd9w+iOaD/FZqEg1VKu80vgiTKk2GslOC8XHS/ZhmUTye0n9p6H0T1PkGuVSMQ4rgTxDgQW6pb9vhT180kA9iFlBoiKwP3sOQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=mfxBvcM7kPRYtD82sxFFBc0FTulWEdHkRvG/HEviTvM=;
 b=jRCGbGgzwXHW+DpJvwaN3jydTaB5bWbd3DMRZktHXyJFA1IhPhVSx5VY6xEdNQW0ZMWgbPGMWpTvypLEJ0LEp83qi4kI1qgEPkjOraMABvX4aIchoGA7BjMsNxWYtdYFJ57cMw4mBmOvsWBeqn8IrifaFCjZ+TGzV6GJ+PC1NTK+kTJlGE85WWbyc2cMk0AsZrEXLQeKIqjiLHWJWROQF+7fFmJodI+qNwh9dZ6g6e/FD+1SEpVLZ+o4TnCcPb27IYab3IuYuMW1r2aYfUXnqxk6pJrkjAn3QWd/lJRqnp/lExL9E7Gjgge868jdcFmtgPGNR+cWot1sfrdOVByiHg==
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=mfxBvcM7kPRYtD82sxFFBc0FTulWEdHkRvG/HEviTvM=;
 b=o7RzxhebHduJlqlWRusYbKsQzAlB6hAlDpp3RwB6/pYpNNHA/g+vDYY4LOLu3N8janVBz27Gb0xflLbmYpwqpX99OZ9ZGKMkBf1fyiiC3F7NW5tZzkFs9mQJxH0aps6cO9sbzO7FiVPCUunE8xm7EIeka58xaCfsTf0Ll282AgA=
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?= , Anthony PERARD
	, Michal Orzel , "Julien
 Grall" , Stefano Stabellini 
Subject: [PATCH v5 01/18] xen/x86: remove "depends on !PV_SHIM_EXCLUSIVE"
Date: Mon, 16 Jun 2025 14:41:11 +0800
Message-ID: <20250616064128.581164-2-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250616064128.581164-1-Penny.Zheng@amd.com>
References: <20250616064128.581164-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: CY4PEPF0000EE3B:EE_|SJ1PR12MB6316:EE_
X-MS-Office365-Filtering-Correlation-Id: bcbe2dd2-33a5-4cdc-d8c1-08ddaca0e48f
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?Yc32FitU5tfYIt/PR9nOkTfe+1UpVC8xz4XJwbSy/1TUNmVwwgyJ89lEGZPP?=
 =?us-ascii?Q?9TDEepouumlvBVTno+ONEbxtcrsyxdyFbLMrtpBsPNvSDcVVI+3ZvFxBTgBS?=
 =?us-ascii?Q?hSXzq+sxHmN6pdHRjNjLysd6QjI7IzpaJruWG1jxHrQdDN4VbSlsL1W2IDb0?=
 =?us-ascii?Q?r92CM+iXHcOQUcahq7MMFO7P/Tlma8FhTY05Hj/t32CwMTu1HOd8KFX9Zt4K?=
 =?us-ascii?Q?w6sfoNupnlVz+IHWXFSc0wVyrrzToMgMe9MTGN4d71RxVjSFSo5V0/boOZpS?=
 =?us-ascii?Q?MNJ1QxDCNYW6Ta4igwmh+NZZE9Ilh/Iy/56AhAFOlHsBHCgVjfICbL6Px4aW?=
 =?us-ascii?Q?zgE2u7hSkffoh+8G7eENIUHbW1lddvCu3XXKtnVwzJc4VAI6LKSTLoPAgxQz?=
 =?us-ascii?Q?yQoKuZ2HjsnsG7P6Fx0y8msOcSZWGe0u3lcxE2Gmnf0MTxbiRjDxh4OJVC/2?=
 =?us-ascii?Q?pKiymIuU7HTTYoht4zlNfb+qYSDtcaabjQaYt4YZ+ag244aS4fB6lGwXrj9R?=
 =?us-ascii?Q?UvEpMJXc5oIzZ6V/LHTHAUet1kgz7ugrf8LJVJ217alwNJ+CwPmGx+obA59o?=
 =?us-ascii?Q?sT0VcY+y3NJLG+LjyZg47tjKYm2vYwU70AErOw0vk4i+S0r9OMwS3kHmKeI9?=
 =?us-ascii?Q?HuOjcYy4J10srNfuzYxnTfE0WNn6+Cm9Dhpt1oi8rTsVm1wNCeYN08n/0Tit?=
 =?us-ascii?Q?SbFiN9+jJ8KMpFtjXDV8fFg54GxJ0q6Bz96UQNwuIBzLay4MvrPQZeNDsZSy?=
 =?us-ascii?Q?B7LMGvyevZyxCEHh3u5QVlNXa7dbfnO0DR2wIVMObSP7iW/tFm5DIG3p5JXv?=
 =?us-ascii?Q?NvUA+F4ArJIsce9Fa9dqyJAfmAhw2kgTslL/0jO7jHzuy4gZNPyPLWKd/7qC?=
 =?us-ascii?Q?GIUecfEn+I6GlrIKN9FaxNTI5mSpNKwJBGA2hgw6OWkVl4MixNbk7gWVWOM4?=
 =?us-ascii?Q?hqYGjXDCFBOkJ7KWLAAX5LwtEfLYVyXdfYlu761w+4TNFfWwWeh3Zx69XvEB?=
 =?us-ascii?Q?kbgvQz4RBEKO1xqkYfM68DidYSTclyEqQmrVY11QamUfJj6d2eUjcow9XfUe?=
 =?us-ascii?Q?YQzjelICqAbHCUS77EUgEz6GaERVNUGMNvOSipBZQwEKdDS/6Qc03VwaPdKd?=
 =?us-ascii?Q?gdb2kPcDWwoy5dEgUF1WsSRhnaaQV5ATFkjs8XWqQ9+bu8sIFwTiTRHUHH9G?=
 =?us-ascii?Q?y524L7OqSNkTZOk9vBlwV/Wa9koliYZmURhbCGcb0f+mRq6/M+95LochSKaJ?=
 =?us-ascii?Q?nt3pcBpMBlg3hs94RXdQcyZftBrRac7FqtdfldynJPCbsGXLHJ6L9hpbF+t9?=
 =?us-ascii?Q?YSGimKgKuGkhSciCRZXg7pjr7FcHiZXSVDfRSiqMQZIk6wlwEMMbq39dAu4l?=
 =?us-ascii?Q?8wDfxLeaYA0yMR8wBayzXChYFWqRNl2sLpuLgbWAOinQqs58u69vxzQBe7fi?=
 =?us-ascii?Q?aYbJEM/wH+yxCXHRnuBW2ItUkaOrxNzwI24ENCEXEifAem/0tUzsB0CAVNWF?=
 =?us-ascii?Q?lUFbsILXOii/qR++OP0mPHsQ3Eay8xdgbv8L?=
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: 16 Jun 2025 06:41:58.4860
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: bcbe2dd2-33a5-4cdc-d8c1-08ddaca0e48f
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:
	CY4PEPF0000EE3B.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ1PR12MB6316

Remove all "depends on !PV_SHIM_EXCLUSIVE" (also the functionally
equivalent "if !...") in Kconfig file, since negative dependancy will badly
affect allyesconfig.

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
---
v2 -> v3:
- remove comment for PV_SHIM_EXCLUSIVE
---
v3 -> v4:
- explicitly state "CONFIG_xxx is not set" in "pvshim_defconfig"
- Add "default y" for SHADOW_PAGING and TBOOT
- refactor commit message
---
v4 -> v5:
- For not breaking allyesconfig, changes to defaults are actually not needed.
So remove them all
- Leave one blank lines
---
 xen/arch/x86/Kconfig      | 4 ----
 xen/arch/x86/hvm/Kconfig  | 1 -
 xen/drivers/video/Kconfig | 2 +-
 3 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 752d5141bb..b45f17a16e 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -289,8 +289,6 @@ config PV_SHIM_EXCLUSIVE
 
 	  If unsure, say N.
 
-if !PV_SHIM_EXCLUSIVE
-
 config HYPERV_GUEST
 	bool "Hyper-V Guest"
 	select GUEST
@@ -299,8 +297,6 @@ config HYPERV_GUEST
 
 	  If unsure, say N.
 
-endif
-
 config REQUIRE_NX
 	bool "Require NX (No eXecute) support"
 	help
diff --git a/xen/arch/x86/hvm/Kconfig b/xen/arch/x86/hvm/Kconfig
index 2def0f98e2..b903764bda 100644
--- a/xen/arch/x86/hvm/Kconfig
+++ b/xen/arch/x86/hvm/Kconfig
@@ -1,6 +1,5 @@
 menuconfig HVM
 	bool "HVM support"
-	depends on !PV_SHIM_EXCLUSIVE
 	default !PV_SHIM
 	select COMPAT
 	select IOREQ_SERVER
diff --git a/xen/drivers/video/Kconfig b/xen/drivers/video/Kconfig
index 245030beea..0a51e87eb2 100644
--- a/xen/drivers/video/Kconfig
+++ b/xen/drivers/video/Kconfig
@@ -3,7 +3,7 @@ config VIDEO
 	bool
 
 config VGA
-	bool "VGA support" if !PV_SHIM_EXCLUSIVE
+	bool "VGA support"
 	select VIDEO
 	depends on X86
 	default y if !PV_SHIM_EXCLUSIVE
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 06:42:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 06:42:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016511.1393413 (Exim 4.92)
	(envelope-from )
	id 1uR3Xm-0000CA-5Q; Mon, 16 Jun 2025 06:42:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016511.1393413; Mon, 16 Jun 2025 06:42:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uR3Xm-0000C1-16; Mon, 16 Jun 2025 06:42:10 +0000
Received: by outflank-mailman (input) for mailman id 1016511;
 Mon, 16 Jun 2025 06:42: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 1uR3Xk-0008OL-Bg
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 06:42:08 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20614.outbound.protection.outlook.com
 [2a01:111:f403:2418::614])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0453eb7c-4a7d-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 08:42:06 +0200 (CEST)
Received: from DS7PR03CA0089.namprd03.prod.outlook.com (2603:10b6:5:3bb::34)
 by MN0PR12MB5785.namprd12.prod.outlook.com (2603:10b6:208:374::17) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.19; Mon, 16 Jun
 2025 06:42:02 +0000
Received: from CY4PEPF0000EE3B.namprd03.prod.outlook.com
 (2603:10b6:5:3bb:cafe::e9) by DS7PR03CA0089.outlook.office365.com
 (2603:10b6:5:3bb::34) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.23 via Frontend Transport; Mon,
 16 Jun 2025 06:42:01 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CY4PEPF0000EE3B.mail.protection.outlook.com (10.167.242.14) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Mon, 16 Jun 2025 06:42: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; Mon, 16 Jun 2025 01:41:58 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0453eb7c-4a7d-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ZRDOxHFkZvT5c2/jo0F/DgLyo67EZH+4LCjjZktAggVWBLbWATRkAYbxuJq/ml36utiFW1QDGS6DBAhgRWnbg7FMB24lRO8kwF39Q53NripbkFzRZMKO5abXTnGqUzhzjJ7KbxyveaPYCLn3wrgSImJcy95guxXNOvzrhpa+zZgGDfs3mcO267HIm97lbeXTo9rldVjB6FyTclXjtRigLNVq0ux6HguuTQmJPBCDGxEXTdkbtGGT/VYj17gsFJli5Wb1fx38y93uBcPBNsR5QvqWJ0gXJCJ8Gd3g1GxpzepAOGMA/u5XgflRhSyO3T1y6pKNq1R1dEwpO4aQPlwvPA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=YdBaE2ZAn0zVs7zMkv6iVvtUYk0VsH6uGpj56SXk+SQ=;
 b=xyCs0IFzH6i9OORJ09ZJC9pqP0Xg9P/kjaFWraqXLMVbP4TWzICs4yjvjNhtoMrswBxzEqonF8xoItxorH3Y2DEvJnrAxqIy34040XVnqwE+07ErbqIcn2ik1T89FwbaDN9/tgiZ4eXBvoZCAX26nomDC9PQW07STH3876KLj8OrDLxs+HTtK8Y/HMwyF23aF7yKTGjnPkhClF+X9tPqeDtg+1Ovfx8pVzNdfkRsA9g7gz56dFvM/g5LHJxt73rItfeuT6KK1SXqKWN2CZZU64I2JAwyWtTc8acm9VlE9cujPSHVOLpZwC4xtxwUCqYor+VrcM678Uo9obt426fibg==
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=YdBaE2ZAn0zVs7zMkv6iVvtUYk0VsH6uGpj56SXk+SQ=;
 b=PUv4hF1JsRtBOoczgzd3zmVMlrjvbOjcTusHGCgB+5kjjGl5dkQkNttgVwYNhi3XSrIdn0NugCkAtoTyQHh3JLNKrW6p7rfgAQUNyQuN1Mx/rLBf9zlN62ucgOIJRDFB/X6kbRXqiAi68azlKSVHUtQ+VKthJU5sLeGisEgZU9k=
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: , Stefano Stabellini ,
	Andrew Cooper , Anthony PERARD
	, Michal Orzel , Jan Beulich
	, Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Stefano
 Stabellini" , Sergiy Kibrik ,
	Penny Zheng 
Subject: [PATCH v5 02/18] xen: introduce CONFIG_SYSCTL
Date: Mon, 16 Jun 2025 14:41:12 +0800
Message-ID: <20250616064128.581164-3-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250616064128.581164-1-Penny.Zheng@amd.com>
References: <20250616064128.581164-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: CY4PEPF0000EE3B:EE_|MN0PR12MB5785:EE_
X-MS-Office365-Filtering-Correlation-Id: 693c03f2-14ae-4213-4645-08ddaca0e664
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?yWOJh3NYI3SK0pXsl8XIkZRXQLbKaESDSpf4hQJVDagnSACtz8ayfRxuczyt?=
 =?us-ascii?Q?F6idTudMRT5L8i2XRQFH9NPVn/tt432DZBwNCQWDcgXKymisISiti7i2gjci?=
 =?us-ascii?Q?gGPgykVENrxtsTgjVH9UdtYr8jtMzvUTQs0/sT6hEutG55EETQZ/8JuBeuZl?=
 =?us-ascii?Q?Jl9x6a/f3UaABtFPU1AutSJnUVN+smzS9t23GmysduXZyiiMH20IqYWPubO3?=
 =?us-ascii?Q?csb5rnegXfEWEJsw4JMiXekiPcGB4NGNk+lQJwUcPR0scU8+UYiPXgoHLIyt?=
 =?us-ascii?Q?pMeAvT+y5FVxKNskGtwee+nlnbGTinFykLVw2An9eN7wqiUzDDmZ8U+h5IcU?=
 =?us-ascii?Q?7aC7JS8pX1tlNXZ9+CxkE2BHtHjV8Vqi71PhCGJIrrlyscf1p2/VkqTCD+Ba?=
 =?us-ascii?Q?yd8cgxcdcLiGhxJHRTaLC0NiC+CarB740qrNUFp3pxgFKp8SGnp3j62e46YX?=
 =?us-ascii?Q?ObCOKB59IFgMYra0klpQK/ojXntgONMz/aUg4wJx24SUyoQHmnnVMR6Pifvy?=
 =?us-ascii?Q?foyS+CbdhiYin5mC5TI+e3mU23uHH5VJduSwVzimODEH0y3lvR0aGnieyNH+?=
 =?us-ascii?Q?0QjBesa8cwesrWRR2o3trMWNpNOmFYHDsh2W6YCsXug2CpDWydCPGhdeZDLq?=
 =?us-ascii?Q?N0DOdashB3ixzfU7jWtYtCbpFmY6kpHn8SKG5XndGfYW5tO7FnkTSSkfzTFN?=
 =?us-ascii?Q?EkZ8Q6IyFedVtBtPQMQc3RIvd3VEN1n+scTwonxVG/SzEhuKo+/UIbTiKlWq?=
 =?us-ascii?Q?FQ8GfNXcDJF18G2piPX5bKY0DfsWMC+rJyllYU83eHAdP+BhigHnC1d6MAJV?=
 =?us-ascii?Q?8wCJVBHoPJ70/2yYKq8tE+rOCYTa8Prcx5IwWDm6+sUM6eAOKSawYX9L4NgE?=
 =?us-ascii?Q?mqIvGe+4hjbqEHLVxabIewbXgBbSxmG++eV01wyLse2iDcfDs7h02DcWtgnd?=
 =?us-ascii?Q?S+GjAp0foE9XvI+nPvRZAO5Xox3ODJ6U/Z7ckGkkZz3BNvZNptSXdU6Q7SgB?=
 =?us-ascii?Q?tr9B0jVxa3+anYMBwJsRV7ivs/3kEhY+0pQrdaD5r+25RlqpOVaKQutGOXoF?=
 =?us-ascii?Q?AcfybeIVoh8NtgNzFSfdkSpcQmI656UvGhHx2cqfn44W+KknmKxYRrYPAsE+?=
 =?us-ascii?Q?OSiw8nOagyvnlfoacyAyW4B9r5woWy+G12bkW5nNWL7yTMNQlkTI2woRl1C0?=
 =?us-ascii?Q?SDfxNqcQeuguMZfc5GWiqFQf0e6aTZDoeyC752XEQW4V8N4LEd1FKQIm9/7a?=
 =?us-ascii?Q?zGvy7u5hlD7L38QWP5sdXrW07BHuSt8XvDoGbNv/ctSvxGNRA0vUrPup4nH4?=
 =?us-ascii?Q?I+/nm5HeuKNz1G4I0IJ2vTxGjBwiStLlnqaq9h8QPsPdAglwIaO3g8E5RIiy?=
 =?us-ascii?Q?zg2TXIVbih6VoXvJuVWrvX29Wlrox8JgCQ5DIeGktMgjc7obDWeQdKLz3J25?=
 =?us-ascii?Q?3qvE5iTwcx7Uabm3FLtLlLx2Mu1pKad/lczRTJop2JjFyRnBIC42eXdINU4X?=
 =?us-ascii?Q?wB+QbQXspBiFNJNtPCm0E6ZXqUGR44jXQl7y?=
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: 16 Jun 2025 06:42:01.5558
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 693c03f2-14ae-4213-4645-08ddaca0e664
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:
	CY4PEPF0000EE3B.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB5785

From: Stefano Stabellini 

We introduce a new Kconfig CONFIG_SYSCTL, which shall only be disabled
on some dom0less systems or PV shim on x86, to reduce Xen footprint.

Making SYSCTL without prompt is transient and it will be adjusted in the final
patch. And the consequence of introducing "CONFIG_SYSCTL=y" in .config file
generated from pvshim_defconfig is transient too, which will also be adjusted
in the final patch.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Sergiy Kibrik 
Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
---
v2 -> v3:
- remove "intend to" in commit message
---
v3 -> v4:
- introduce the option without prompt (simply "defbool y") to eliminate the
need for transient "#ifdef CONFIG_SYSCTL"
- calling out the transient scenario in commit message
---
v4 -> v5:
- a simple definition "def_bool y" for CONFIG_SYSCTL is enough here
- refactor commit message
- blank line ahead of endmenu
---
 xen/common/Kconfig | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 867710134a..fb5c60517a 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -611,4 +611,12 @@ config SYSTEM_SUSPEND
 
 	  If unsure, say N.
 
+menu "Supported hypercall interfaces"
+	visible if EXPERT
+
+config SYSCTL
+	def_bool y
+
+endmenu
+
 endmenu
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 06:42:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 06:42:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016509.1393394 (Exim 4.92)
	(envelope-from )
	id 1uR3Xh-0008Ag-HM; Mon, 16 Jun 2025 06:42:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016509.1393394; Mon, 16 Jun 2025 06:42:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uR3Xh-0008AZ-DA; Mon, 16 Jun 2025 06:42:05 +0000
Received: by outflank-mailman (input) for mailman id 1016509;
 Mon, 16 Jun 2025 06:42:04 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uR3Xg-0008AT-Nw
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 06:42:04 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20618.outbound.protection.outlook.com
 [2a01:111:f403:2413::618])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 023dfabb-4a7d-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 08:42:03 +0200 (CEST)
Received: from PH0PR07CA0051.namprd07.prod.outlook.com (2603:10b6:510:e::26)
 by PH8PR12MB6674.namprd12.prod.outlook.com (2603:10b6:510:1c1::18) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.28; Mon, 16 Jun
 2025 06:41:56 +0000
Received: from CY4PEPF0000EE39.namprd03.prod.outlook.com
 (2603:10b6:510:e:cafe::2) by PH0PR07CA0051.outlook.office365.com
 (2603:10b6:510:e::26) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.23 via Frontend Transport; Mon,
 16 Jun 2025 06:41:56 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CY4PEPF0000EE39.mail.protection.outlook.com (10.167.242.11) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Mon, 16 Jun 2025 06:41:55 +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; Mon, 16 Jun 2025 01:41:50 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 023dfabb-4a7d-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=S7wblkaGtkOFGe7SLfcD8doc14+CjrCihwezYhOLIBqKkXymNjjZQXcGJO8migm2u1I49zIeZa4Yp4heGXsuuPO5NnkUQ6G6//nSzM/SydrW7C56XI1jNGTd5tcJRZODqiwfm02VGJy/fucuU/h/Hi0U/RpFFOpNMba3ZKtl3uCnmF2FqNMezyJEpejDFrWdBGO/iVFdh1XHIzywkop1LFiQ7sivZ4wSVUXNYHR8GYX8XOLC2YYyWQCWBc9Mqv0cnQuBwZbzCs+3rBvQEi0PFVH/bOmryaenrGm1Hmo6kHmwjJi1PEyChWp96Z3nCQy0Co6r9l1pgdHS8BRlIzcZ9w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ItL/mFS8c4oPecd9mD13j1wnQZRdCrGzOnxc+ZiEBKI=;
 b=VLcmDGFmDmm4mgrg6QZmVInfAsbPBk+BvwH7qJLU42YiFF3g1Jf/j24EVwNKoW/tBHlZk0nNmttNXOQW7w58lv5Ikixt3RB6dJuRDO0Jpjrj6B9NZdxcZg4q1ClYEzy8jkK9j0FLj0Qbz92X+QN4hxB+Wk/uce6qAoloKXevjAAfDMhioymed/buEKMLl3NIEmUAjSczn0W9qfKGD6AUC0l+VnvTUOulurFJqzhLpPYkwoXooBRA4AZx25SVqz+Btv/BpMEc+rFCLc15B8zEqNShkz/8csTFsiQ20gkjqwUBO9LqDUOtuAOPy3K/rd3xcANuJQ70+V1lSeVi3Bk+PA==
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=ItL/mFS8c4oPecd9mD13j1wnQZRdCrGzOnxc+ZiEBKI=;
 b=f/pYrXoR75C5eObT4PYZ3i603Q+06VhmMV1/HFZ6NJSPUEmKqT6+dHLRdhr49i+E9o2V6CDy6ZcEvTPvfMny6qD5ctpM57UT6fJrKM9t4icqKlarq2DOSDETP5yU3kntfkLf5c34KfdopT0ivBquHXLlay7ZwrIjA4viS6nsKQA=
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?= , Anthony PERARD
	, Michal Orzel , "Julien
 Grall" , Stefano Stabellini , "Daniel
 P. Smith" , Dario Faggioli
	, Juergen Gross , George Dunlap
	, Nathan Studer , "Stewart
 Hildebrand" , Bertrand Marquis ,
	Volodymyr Babchuk , Alistair Francis
	, Bob Eshleman , "Connor
 Davis" , Oleksii Kurochko 
Subject: [PATCH v5 00/18] xen: introduce CONFIG_SYSCTL
Date: Mon, 16 Jun 2025 14:41:10 +0800
Message-ID: <20250616064128.581164-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: CY4PEPF0000EE39:EE_|PH8PR12MB6674:EE_
X-MS-Office365-Filtering-Correlation-Id: 1421b45f-825b-4f79-7f2d-08ddaca0e2fc
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|7416014|82310400026|1800799024|36860700013|13003099007;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?LWD4048LrXXiet76Aca/9WpGmxPRG3v3ZrLPIl80iFkCTn25uuLSBoWVjrb3?=
 =?us-ascii?Q?5OToOJPhSUhl4B9fsIWWHunPjvgzhqJNmpqV8DZU4ynRKpm8mzYOjs8slVmx?=
 =?us-ascii?Q?w5lo04PZCcs8HCtpWggGgZkiL+frH9DxrhVPs6kYEAycA+Blxwq7bHtENVEj?=
 =?us-ascii?Q?uU1LlgDD2fdz7PtqvgeVP9f9ENP32MHlLVZ4RSAJh9WScTIwnVrnSHlQs1aq?=
 =?us-ascii?Q?SROh/dtVP1Bg3h/ifhEn32WkVlx49tyig6P/wEhUWLvjzITNdm0Qc76p+mgv?=
 =?us-ascii?Q?PReEPylIdHpUhxvSrJdKWnAJwu8NK+X4f63rFra7qp+toErubpaFFy+Lb87X?=
 =?us-ascii?Q?PSQNj229alFFYgXFd2oEKgRauPQjOxLUqQ2W0ye/PrcrKINGZ0pQtD/9/8wu?=
 =?us-ascii?Q?EsZRQfkFt9WPio2vRS1nRtosWuqNNmWckR9Ihg27/qHlCmAbxgIOd+5qPmC/?=
 =?us-ascii?Q?ylDYYvqhzbAg5iA9gIphvRtjxKvKMYsAIo/QY+0funDvkIe8E/Lo9Z080HD4?=
 =?us-ascii?Q?+dO3WyLKrgMEw6JpFQKapjfsqxANAGKyzuSvjXdTYNRBbjO45jhEGHz02Lmf?=
 =?us-ascii?Q?IMOlOq+ggTRQ4q59NcfKoj72XSO6/DxMaa8TbcjzG4ShxRjm3tfgDKSBcil/?=
 =?us-ascii?Q?r+3l4zMFvVcOKVEF0e7+f+JMOOhs9cmCVyaGpjz8jKNOMtooXRNSh24df16y?=
 =?us-ascii?Q?3vqwU5zV7/Xdr+VzmbTDfWlA7vnUTuGxNEMoj7yJzIC8iGtZJmwAomRFSMKE?=
 =?us-ascii?Q?BVltgi+kZCWHCwtBUd7nffsH3vtmToMzcbPhRrK9iLItwtZbgigtjNu5dzMY?=
 =?us-ascii?Q?mmZjRGEVUGd1dn7hJdnmVjLJKOOW5inc4a6LMzeTCmonyqv/6MmytaUAi2cL?=
 =?us-ascii?Q?AvkzDWvvMkJJY3yGqQXxCiCU7sRFihY0W+mAUn3RhK7qDRwLZli0TLANk0rU?=
 =?us-ascii?Q?pV6ypgqMrnjTrEourwtAtkUeasIdEqsyioo7ohoXmVoARO2C1DFhncG1gHVn?=
 =?us-ascii?Q?ZRXW4PNOBMbcTZewJsX2ri8x6D/58ETRPMkL2B0TNgUedwavvOi4KPcwNXqq?=
 =?us-ascii?Q?bVetm1/0WklB1dEM0Ub7ab/yP8s/y7jaENskDpEZAJkbBOXYlWkWEX589j/Z?=
 =?us-ascii?Q?YXzlEFAi8zatVkamNyFfxbPXJ5r4YvxRg/BQVq98WdeZmpBqk0HWNDxL0OMX?=
 =?us-ascii?Q?wlBXF/Bcw2nB0jzL0AMwLTde6uXWlaLKh0/stwoc0Uk0CsNma/uDU9nDqPJ+?=
 =?us-ascii?Q?uC8OOC/nrg+rsEB0ODkJWP626j4CVix+k8p/IkPCq242F0tEgYnOlKg1A04+?=
 =?us-ascii?Q?txefi6vPB+qrgo/zito2pd+W7lc2dpNzvhBddekBCRKHqBpmRNSEELIsrvHK?=
 =?us-ascii?Q?Kh0vtQD0I+xk7AjIAAYYsr0/LdE95Qhr3fssvjo18TUUY3Cn+o8XpIfg8hoi?=
 =?us-ascii?Q?DZ69k4aGv/GwC7poH+9qrBAJV8g5JVFO1cRtOtQHHIgZQ3r6g40j2nan2gva?=
 =?us-ascii?Q?gN1NWAft1ReAFWCV/SD70xyOlnaXlQqx6r9c?=
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)(7416014)(82310400026)(1800799024)(36860700013)(13003099007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jun 2025 06:41:55.8412
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1421b45f-825b-4f79-7f2d-08ddaca0e2fc
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:
	CY4PEPF0000EE39.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB6674

It can be beneficial for some dom0less systems to further reduce Xen footprint
via disabling 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:
- sysctl
- domctl
- hvm
- physdev
- platform

This patch serie is only focusing on introducing CONFIG_SYSCTL. Different
options will be covered in different patch serie.

Features, like LIVEPATCH, Overlay DTB, which fully rely on sysctl op, will
be wrapped with CONFIG_SYSCTL, to reduce Xen footprint as much as possible.

It is derived from Stefano Stabellini's commit "xen: introduce kconfig options to
disable hypercalls"(
https://lore.kernel.org/xen-devel/20241219092917.3006174-1-Sergiy_Kibrik@epam.com)

Penny Zheng (16):
  xen/x86: remove "depends on !PV_SHIM_EXCLUSIVE"
  xen/xsm: wrap around xsm_sysctl with CONFIG_SYSCTL
  xen/sysctl: wrap around XEN_SYSCTL_readconsole
  xen/sysctl: make CONFIG_TRACEBUFFER depend on CONFIG_SYSCTL
  xen/sysctl: wrap around XEN_SYSCTL_sched_id
  xen/sysctl: wrap around XEN_SYSCTL_perfc_op
  xen/sysctl: wrap around XEN_SYSCTL_lockprof_op
  xen/pmstat: introduce CONFIG_PM_OP
  xen/sysctl: introduce CONFIG_PM_STATS
  xen/sysctl: wrap around XEN_SYSCTL_page_offline_op
  xen/sysctl: wrap around XEN_SYSCTL_cpupool_op
  xen/sysctl: wrap around XEN_SYSCTL_scheduler_op
  xen/sysctl: wrap around XEN_SYSCTL_physinfo
  xen/sysctl: make CONFIG_COVERAGE depend on CONFIG_SYSCTL
  xen/sysctl: make CONFIG_LIVEPATCH depend on CONFIG_SYSCTL
  xen/sysctl: wrap around arch-specific arch_do_sysctl

Stefano Stabellini (2):
  xen: introduce CONFIG_SYSCTL
  xen/sysctl: wrap around sysctl hypercall

 xen/Kconfig.debug                            |   2 +-
 xen/arch/arm/Kconfig                         |   1 +
 xen/arch/arm/Makefile                        |   2 +-
 xen/arch/riscv/stubs.c                       |   2 +
 xen/arch/x86/Kconfig                         |   4 -
 xen/arch/x86/Makefile                        |   2 +-
 xen/arch/x86/acpi/cpu_idle.c                 |   2 +
 xen/arch/x86/acpi/cpufreq/hwp.c              |   6 +
 xen/arch/x86/acpi/cpufreq/powernow.c         |   4 +
 xen/arch/x86/configs/pvshim_defconfig        |   1 +
 xen/arch/x86/hvm/Kconfig                     |   1 -
 xen/arch/x86/psr.c                           |  18 +
 xen/common/Kconfig                           |  31 +-
 xen/common/Makefile                          |   2 +-
 xen/common/page_alloc.c                      |   4 +
 xen/common/perfc.c                           |   2 +
 xen/common/sched/arinc653.c                  |   6 +
 xen/common/sched/core.c                      |   4 +
 xen/common/sched/cpupool.c                   |   8 +
 xen/common/sched/credit.c                    |   4 +
 xen/common/sched/credit2.c                   |   4 +
 xen/common/sched/private.h                   |   4 +
 xen/common/spinlock.c                        |   2 +
 xen/common/sysctl.c                          |   4 +-
 xen/drivers/acpi/Makefile                    |   3 +-
 xen/drivers/acpi/pm-op.c                     | 397 +++++++++++++++++++
 xen/drivers/acpi/pmstat.c                    | 357 -----------------
 xen/drivers/char/console.c                   |   2 +
 xen/drivers/cpufreq/cpufreq_misc_governors.c |   2 +
 xen/drivers/cpufreq/cpufreq_ondemand.c       |   2 +
 xen/drivers/cpufreq/utility.c                |  41 --
 xen/drivers/video/Kconfig                    |   2 +-
 xen/include/acpi/cpufreq/cpufreq.h           |   3 -
 xen/include/acpi/cpufreq/processor_perf.h    |  10 +
 xen/include/hypercall-defs.c                 |   8 +-
 xen/include/xsm/xsm.h                        |  18 +
 xen/xsm/dummy.c                              |   6 +
 xen/xsm/flask/hooks.c                        |  14 +
 38 files changed, 569 insertions(+), 416 deletions(-)
 create mode 100644 xen/drivers/acpi/pm-op.c

-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 06:42:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 06:42:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016513.1393422 (Exim 4.92)
	(envelope-from )
	id 1uR3Xr-0000Ue-CA; Mon, 16 Jun 2025 06:42:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016513.1393422; Mon, 16 Jun 2025 06:42:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uR3Xr-0000UX-9I; Mon, 16 Jun 2025 06:42:15 +0000
Received: by outflank-mailman (input) for mailman id 1016513;
 Mon, 16 Jun 2025 06:42:14 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uR3Xq-0008AT-8O
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 06:42:14 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20617.outbound.protection.outlook.com
 [2a01:111:f403:2408::617])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0960059a-4a7d-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 08:42:13 +0200 (CEST)
Received: from CYXPR03CA0033.namprd03.prod.outlook.com (2603:10b6:930:d2::10)
 by BL3PR12MB6449.namprd12.prod.outlook.com (2603:10b6:208:3b8::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.19; Mon, 16 Jun
 2025 06:42:09 +0000
Received: from CY4PEPF0000EE3B.namprd03.prod.outlook.com
 (2603:10b6:930:d2:cafe::67) by CYXPR03CA0033.outlook.office365.com
 (2603:10b6:930:d2::10) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.28 via Frontend Transport; Mon,
 16 Jun 2025 06:42:09 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CY4PEPF0000EE3B.mail.protection.outlook.com (10.167.242.14) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Mon, 16 Jun 2025 06:42: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; Mon, 16 Jun 2025 01:42:01 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0960059a-4a7d-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=dZQKE99/25UYKWcOvuufFZ1Uuy0+RpgxsBXhTc5fj4IN9rNDEIpglJOr3Ul+tCDl+uolhoJBqVfm7bZbBm6t/IzihnLBN+jKvZ0k9n9gT0WqDeMrV6MMqhY+sHDH8SPUGPCkccOJRujLRR868dNZ1Arx74ba5QZlyBFqzEah7hIVTdzaUtONn1j9usvGxpPtTGwuXmQ9p9+YCaee7b1mOeonH4X0ezfRtKfWbgms/SvZC3SkOpAhAp9v++VV3MtgL193zahjTmP802dVdMyENIKFOt+5TzWzlfwshKm3O8lyYXp/kL4r4NQdVAKu0U4cOHbIVPSQ1pysK6ogLEGcDQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=XWDCQOD66ZKbLyRJ3ZdoNMgnP/71ZQbglzYq68MUnMQ=;
 b=tReB95Q+XdncCgvwcwngKDLuIkYKWjitScK3aRfwFXNFgP+R5KmgCXESkZIFPKy1xvFa9yrZsJvtRbiIsMaNsRBL4/KUGKv+SB9v9zy/oAIv9scetiiCgdYR1Q7XCx6nJyI/c6Q2Xlf5bwpGJsN8OyiNL5VGpSkOSSWMHG9HLPKCTwJV7s1F9kwjFBCOQQgQHR0GYmJUg9vJTGPkn3jgW5usfZQHmuIkSTuQrCPHIF6c4A+7aoVuvBRU0pRom1mwlKM/Lb5arj1u7R6LSaQUqqMtdw4qb1jF6/xnrivDi2f2vo6Q/aKMg8DcHMdrQ6ttjgQ5+E9LuhjfvbFV2E9nFw==
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=XWDCQOD66ZKbLyRJ3ZdoNMgnP/71ZQbglzYq68MUnMQ=;
 b=5h0P4pjkcg9umfrsEO71bRjjl1zDVa2eeWAcuVz+OV6tizxbBXo6LY1hP8NWb/9d+ByZtb4KdaBPipAtHG/uF8eZ+kWaKGfLU3FxYbexw2t/NLQ0MX8utgDBhnKoExcaxrtXOvfQ8ugqK98UcICsdrHTopVudmKwtVFJyYvkeZk=
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 , "Daniel P. Smith"
	, Stefano Stabellini 
Subject: [PATCH v5 03/18] xen/xsm: wrap around xsm_sysctl with CONFIG_SYSCTL
Date: Mon, 16 Jun 2025 14:41:13 +0800
Message-ID: <20250616064128.581164-4-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250616064128.581164-1-Penny.Zheng@amd.com>
References: <20250616064128.581164-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: CY4PEPF0000EE3B:EE_|BL3PR12MB6449:EE_
X-MS-Office365-Filtering-Correlation-Id: 3feb7145-1395-4aa8-04e8-08ddaca0eada
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?puiweZT6bQFA7hMhsGJ+j96r8M0JOp81WJa1lzZpsFxKTohWAuw4kLQtr1L7?=
 =?us-ascii?Q?Btf8mRaWMLGZqNYH7Wm4nrTHvu937VUx4X+0O/cwNcyGVY1BTxpIEoX+flBU?=
 =?us-ascii?Q?DjAbb8eHO8QX2UOTL4xiT0WYXStav3l5y7yG0b9pRUYcbuoCV6HL5E2l6ZJ+?=
 =?us-ascii?Q?kcBz78hea34aOJLkvam4cu1Ex6GaDFuIZcgVG2qwG3mc2jEICA8oQUqdtsbY?=
 =?us-ascii?Q?nwq58Kz/+NymBM7N6FbiScp3PC8ESsM6so7rcNSmNUFTLTdV5Oa9Kms7rPaw?=
 =?us-ascii?Q?hDZgj1hdx+VHyeXEbfRQva/BG9dRjIpDN1W2wnVNEgE4Kfhntz8UH/4uj2/w?=
 =?us-ascii?Q?F0nB9yzKS1CBxuMgEtC4PSJTKdZAuFj9BURmK5bNP7OZCYfIr8PEXFHK6q+I?=
 =?us-ascii?Q?G7HyEqgasIcs9e+W7Mq2O9Pi9cTz8XTezmJi1EMk6+vWvR6qbQRj3C/g6gkG?=
 =?us-ascii?Q?7Gk9IPVvEDKgj5++is1xjwz1odpP/Z44HzcGuq0pj5cQCGyHTDmy9vEusarT?=
 =?us-ascii?Q?GVBwVSnVvdWHS3wblaj1zZ3R+SuTmFKnOdv6lD0m6f7STKoY1zXA11517Ygu?=
 =?us-ascii?Q?qGWGAj5imBF+vFGLcv1KA5CGgOcnA2q04cBECdeQ+lhGcyt+6gqR2sBTsLuj?=
 =?us-ascii?Q?rTbYbwgYugDErgURVwWnWCp7KrO8HevLrWwocPNCoedJ5dEo0LGusnCPRnGv?=
 =?us-ascii?Q?xhW8kX65IT/fWosrsVXtPa5jt9QpDW37BMUCs9pUbVdndg9oqw+8pIiHd9A/?=
 =?us-ascii?Q?lxWUXNQytLzYpU8N5Zd7/Nv1yMC2S5R3IHKGG2RVMYXnnZY1lKbayYwOaKEh?=
 =?us-ascii?Q?RSEr+IJvJ4UHAYIxy18LnuliwiaKF8yDMXVRdKKixSWkilNL5pj8mUi6utuh?=
 =?us-ascii?Q?1Ab0LKq5C+Nu6+dEP8u0wxqovyiyHZriGiqqMeDTYm9/PsIvOpNdV7qTKdni?=
 =?us-ascii?Q?wjx99GjT3gr+OcbWnIHHuAZMhpMsxFr6g8HFNZV7edV7GZrkawDiipysJGYs?=
 =?us-ascii?Q?N5egogI9fxO6WSo7nrxHrN3Xjk3bQOic63khoRFzGTywIgprRMUhNgsAGleT?=
 =?us-ascii?Q?IV+wZrUvZ2oebrmw5VxxTpaXHyCmPq2TOmxbpxgGZyzm5W/IrJVUvTc/bmAK?=
 =?us-ascii?Q?QaG10NRt8yCUhKBoBaZh4vFQ/SZ5C8UlW71gLoEnHrPH4FRwyN7y+m38j/Y0?=
 =?us-ascii?Q?gruVxVFIYsSBKni1mfKwl1AtQe7wYwa9TmU/Myl0sW1eVGmSpK/Oyr3fPQQG?=
 =?us-ascii?Q?GQjNAww+8dwLhP4vkofFbVHSzMTdo5CwIxfEU2iWSxRQyP567fNvr0gnGjW4?=
 =?us-ascii?Q?HkVa5SexL3bObgsBi1lvmhSg8JklBBYPRYyDP21jFrlrD546yTXSokhMENt5?=
 =?us-ascii?Q?l9xlq46ZoikoVWwgH9yPv05Ympe0VXvZL/RIe+errPdhaNKcHBoTFLojppCi?=
 =?us-ascii?Q?rCmSTjjtNVQnl+dvndV5+cQlcBvnuRbABS5Hxi0jLzU9ZPAGXoPz0ev8cQ49?=
 =?us-ascii?Q?EENTGESj5VHuN/1mI3pFDBlI2GlXzBVv5txK?=
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: 16 Jun 2025 06:42:09.0378
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3feb7145-1395-4aa8-04e8-08ddaca0eada
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:
	CY4PEPF0000EE3B.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL3PR12MB6449

As function xsm_sysctl() is solely invoked in sysctl.c, we need to
wrap around it with CONFIG_SYSCTL

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
---
 xen/include/xsm/xsm.h | 4 ++++
 xen/xsm/dummy.c       | 2 ++
 xen/xsm/flask/hooks.c | 4 ++++
 3 files changed, 10 insertions(+)

diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 24acc16125..22e2429f52 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -261,7 +261,11 @@ static inline int xsm_domctl(xsm_default_t def, struct domain *d,
 
 static inline int xsm_sysctl(xsm_default_t def, int cmd)
 {
+#ifdef CONFIG_SYSCTL
     return alternative_call(xsm_ops.sysctl, cmd);
+#else
+    return -EOPNOTSUPP;
+#endif
 }
 
 static inline int xsm_readconsole(xsm_default_t def, uint32_t clear)
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 93fbfc43cc..93a0665ecc 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -22,7 +22,9 @@ static const struct xsm_ops __initconst_cf_clobber dummy_ops = {
     .sysctl_scheduler_op           = xsm_sysctl_scheduler_op,
     .set_target                    = xsm_set_target,
     .domctl                        = xsm_domctl,
+#ifdef CONFIG_SYSCTL
     .sysctl                        = xsm_sysctl,
+#endif
     .readconsole                   = xsm_readconsole,
 
     .evtchn_unbound                = xsm_evtchn_unbound,
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 6a53487ea4..3a43e5a1d6 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -856,6 +856,7 @@ static int cf_check flask_domctl(struct domain *d, unsigned int cmd,
     }
 }
 
+#ifdef CONFIG_SYSCTL
 static int cf_check flask_sysctl(int cmd)
 {
     switch ( cmd )
@@ -933,6 +934,7 @@ static int cf_check flask_sysctl(int cmd)
         return avc_unknown_permission("sysctl", cmd);
     }
 }
+#endif /* CONFIG_SYSCTL */
 
 static int cf_check flask_readconsole(uint32_t clear)
 {
@@ -1884,7 +1886,9 @@ static const struct xsm_ops __initconst_cf_clobber flask_ops = {
     .sysctl_scheduler_op = flask_sysctl_scheduler_op,
     .set_target = flask_set_target,
     .domctl = flask_domctl,
+#ifdef CONFIG_SYSCTL
     .sysctl = flask_sysctl,
+#endif
     .readconsole = flask_readconsole,
 
     .evtchn_unbound = flask_evtchn_unbound,
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 06:42:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 06:42:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016514.1393433 (Exim 4.92)
	(envelope-from )
	id 1uR3Xt-0000lc-Kf; Mon, 16 Jun 2025 06:42:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016514.1393433; Mon, 16 Jun 2025 06:42: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 1uR3Xt-0000lL-HG; Mon, 16 Jun 2025 06:42:17 +0000
Received: by outflank-mailman (input) for mailman id 1016514;
 Mon, 16 Jun 2025 06:42: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 1uR3Xs-0008AT-F4
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 06:42:16 +0000
Received: from NAM02-SN1-obe.outbound.protection.outlook.com
 (mail-sn1nam02on20614.outbound.protection.outlook.com
 [2a01:111:f403:2406::614])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0a379954-4a7d-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 08:42:16 +0200 (CEST)
Received: from CYXPR03CA0041.namprd03.prod.outlook.com (2603:10b6:930:d2::12)
 by SA1PR12MB6726.namprd12.prod.outlook.com (2603:10b6:806:255::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.28; Mon, 16 Jun
 2025 06:42:11 +0000
Received: from CY4PEPF0000EE3B.namprd03.prod.outlook.com
 (2603:10b6:930:d2:cafe::80) by CYXPR03CA0041.outlook.office365.com
 (2603:10b6:930:d2::12) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.28 via Frontend Transport; Mon,
 16 Jun 2025 06:42:11 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CY4PEPF0000EE3B.mail.protection.outlook.com (10.167.242.14) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Mon, 16 Jun 2025 06:42:11 +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; Mon, 16 Jun 2025 01:42:08 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0a379954-4a7d-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=B/LaStIm4XRo85XJZNtySVFEg5Dq+nBHRbKRaQCEIJFkmhUc/QN4kH7xpwnAN12JX6LurOfd5N2cBbaEtiJCNJjaPe11CKLgH+Hm87fDyxwId/dJrKwEpjgwJDE2AU04oF8/at8AjHpSqU2xjsNj77Uqe4ceDI+3PX88MZWUJuKTIunEOkKTr9AwoNbqE5Qyk4Po8wHP6wehkChrWrV36ByTL5u92PLIdqAHTanCFjboZduS2wcUIfNlTIP1vMQgPJe0GlYBqybszwiaYsnQlvLPqSDkFnKN7d3iLepI5IUyyxOp75Tf4ZgH+2Zo4F+P+i2WkTJgDjzHLNMBc5Ue5A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=NI/6AN7Kc6qmUPgrDZbatiRRdKNwzya65ykPb1EYoB8=;
 b=pmPUCcKHTzi1T5D8gKNR3M62YL+xgqB/SXi8hZfyBGvgFz1tMfIFiB723DUvipCaXGqr6+SqM1cwXvb+3klXCUP8ycuBrI2XLdEbsP9CgQFOmrW+yxb3tnTeuNvuJcqDMWIvVqQgtjZpnDF2GDtWQhJ+onTI8pnyzvCOuKmMohnK3dFwgIGe8Wd/sxR/ACu/tbZSpxJz2DnsL9nGymnd8QKWKzzW/HylFliBqByawNPGZdMy5czUtXBcgBkJhKa+8mBqxjC3oX+dUfba6jtqt/p7rS70DT0H2lauQBfd0RtV8ac/DpH9JXIMH7bMeprGUhVYus/EsnGp96mUXWCHzw==
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=NI/6AN7Kc6qmUPgrDZbatiRRdKNwzya65ykPb1EYoB8=;
 b=gegQpHswEfqYnNGunLpGnXgaCTPXRufrXhtULF0XY1g4xJQ99TMdUJIZROH0WGIlGSTg2sRqNwR4X+xFkVRTUyVaWyKbjca1Qp7Yi/1wIDBX1YtzUxoqzo2meqEcVmvU2vx7ID43DQI4vE+LlI1gVr2WzF1lrzHkIsP1jHDXR0w=
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 , Dario Faggioli
	, Juergen Gross , George Dunlap
	, Stefano Stabellini 
Subject: [PATCH v5 06/18] xen/sysctl: wrap around XEN_SYSCTL_sched_id
Date: Mon, 16 Jun 2025 14:41:16 +0800
Message-ID: <20250616064128.581164-7-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250616064128.581164-1-Penny.Zheng@amd.com>
References: <20250616064128.581164-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: CY4PEPF0000EE3B:EE_|SA1PR12MB6726:EE_
X-MS-Office365-Filtering-Correlation-Id: 17ef4b57-073b-4d34-24fc-08ddaca0ec5b
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?qeXX8PHAcHcAhHY1TA4E3l1oQYIIPH/ZM1MXvLz+4koHnRa3AZfU9Gcg1b8q?=
 =?us-ascii?Q?n24lopB/iSSw/1Exc9t5p9LGR28XRIRoIspmNPM8mkE1zcL/aoIJWWhbYCTY?=
 =?us-ascii?Q?STxM+1tTu5ADHDXPTB5rftnr2icRT3CLQ2JfZqWJlJHBF+tlkg/FdQ/nE9GV?=
 =?us-ascii?Q?8rNRhYc9llS8d81QyrIcASqj19MY4NvZ0qCtvzo7O3l91arxgazKqbGAFYGO?=
 =?us-ascii?Q?/DX0zmcllAUNFn+/ptCfK6uaRuyOHVyrbbN/L6Ni2WdnPPOFlcC1H60aJ+PG?=
 =?us-ascii?Q?RA9ooiRgV51mLYQ5YRqt18Lu/DjE3qc5ypcpmLvL2HYH0z8ppq6qqrVOjIkc?=
 =?us-ascii?Q?VKwv6FzlkrRuH5vLOhUtlKIBXIHYvkbXjX7WreKyjJBm6C2+cLe49rvmpF5Y?=
 =?us-ascii?Q?dOpW+SV7JFYwjAItmLdoKHp9suT6hPewHtZlcKqwWeRezVVHUV4NAqi+vbE7?=
 =?us-ascii?Q?VhF9YjBw2MJcIfj+8+A5IEHiUrmhVtxWjdPeZCVXOGKNQlPA9rhsGeK+saSR?=
 =?us-ascii?Q?HR1f86wPb/cwJdq8AYMigKE5jMhX1OkV/eW5uw9v2F/jIJIiyXMG6B3B5cT+?=
 =?us-ascii?Q?CbyfNVweu9FJdO8rXkESARmoeKxMTVhlcjlR4M54SV2vuWSLhDN4Z7RQKbAw?=
 =?us-ascii?Q?O664JEd/C24ZWbTVRTt7xsm6rYu5g5NmbwSempM/YTbjkiCWc8m62xQdElgA?=
 =?us-ascii?Q?dVNm0xflJQTuTBX+CeeRoxzHJvkaHDqrdyzU3OPjwRXtfjXslF/eFlI56nvu?=
 =?us-ascii?Q?+guxxw9Chrr4FAimq81+WMcsisFOKqojlP3atzOrhO9S4OcX/slC9MpQJbM+?=
 =?us-ascii?Q?Dnc0lQ2i8ZXI9H30ds2PxX0cxMvfoByvS81+EZ0EJVdht8QjiUI0exQ1k9SQ?=
 =?us-ascii?Q?1yTGAVYWIVI3j9HGw739hKv0MeT9dy5egGTV4cms3T3auPkoxVNvOZuj86YF?=
 =?us-ascii?Q?Yd96R/4v2C3jpqEfQ+NDBAFTj/ot8VnMCLchr7/vSHqS2/VVOO2EO/RCIblU?=
 =?us-ascii?Q?RDh/b7MrQCcb/Z/VbUdRS4Imq8qOJ3+cYIxW7R+zS+xGWU4ODw/GZJvtLw1+?=
 =?us-ascii?Q?Dnx80yKi8dD/IQ2LHIPz0m/DkXn/jE2oRKR1M0bdQxNFmJEHR9sliZa+nVWp?=
 =?us-ascii?Q?irTX76WWcUSm6VwrBg9Eill1l5iKNN+XmBHmk9X3N5oZ/fzSdRCPFxQYbbrA?=
 =?us-ascii?Q?D/w93dDDO2jns+7dN2FDeTNFkDKsGSm+xTzfkQd+ruXq8kK/e09Krnl7VyUK?=
 =?us-ascii?Q?D7b7CaB8DB07JBIN5GDuzkd2cFSAo9uLrcK6UmEi5gHiT9e6Kyv+TljLiYBH?=
 =?us-ascii?Q?/uM7jPCFNtXWLg2KMReOYNHrL9ed9APAhURY9gG6unxW39nXZxwZE4QU6i+Y?=
 =?us-ascii?Q?er9AKgTbezh4315mn3AB8ynLgVW76epw7Lm9nJjKWeW7C6/uzAIEAz4Roq7c?=
 =?us-ascii?Q?e47OBFALT7lrjZF4Ea12Uaj1o099iB7IyI7tEu+c/V3iKIeNMa9SUpda/VMj?=
 =?us-ascii?Q?KpYB7x8CzM3P0l01zqxUhdFDRHKJ/ANcLcHL?=
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: 16 Jun 2025 06:42:11.5614
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 17ef4b57-073b-4d34-24fc-08ddaca0ec5b
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:
	CY4PEPF0000EE3B.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB6726

The following function shall be wrapped:
- scheduler_id()

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
---
v3 -> v4:
- remove transient "#ifdef CONFIG_SYSCTL"
---
 xen/common/sched/core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index 9043414290..13fdf57e57 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -2069,11 +2069,13 @@ long do_set_timer_op(s_time_t timeout)
     return 0;
 }
 
+#ifdef CONFIG_SYSCTL
 /* scheduler_id - fetch ID of current scheduler */
 int scheduler_id(void)
 {
     return operations.sched_id;
 }
+#endif
 
 /* Adjust scheduling parameter for a given domain. */
 long sched_adjust(struct domain *d, struct xen_domctl_scheduler_op *op)
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 06:42:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 06:42:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016515.1393438 (Exim 4.92)
	(envelope-from )
	id 1uR3Xu-0000of-01; Mon, 16 Jun 2025 06:42:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016515.1393438; Mon, 16 Jun 2025 06:42: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 1uR3Xt-0000nm-P5; Mon, 16 Jun 2025 06:42:17 +0000
Received: by outflank-mailman (input) for mailman id 1016515;
 Mon, 16 Jun 2025 06:42: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 1uR3Xs-0008OL-TW
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 06:42:16 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20631.outbound.protection.outlook.com
 [2a01:111:f403:2009::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 09969e04-4a7d-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 08:42:15 +0200 (CEST)
Received: from CY5P221CA0093.NAMP221.PROD.OUTLOOK.COM (2603:10b6:930:9::24) by
 MW3PR12MB4460.namprd12.prod.outlook.com (2603:10b6:303:2f::7) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8835.28; Mon, 16 Jun 2025 06:42:09 +0000
Received: from CY4PEPF0000EE3C.namprd03.prod.outlook.com
 (2603:10b6:930:9:cafe::d3) by CY5P221CA0093.outlook.office365.com
 (2603:10b6:930:9::24) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.23 via Frontend Transport; Mon,
 16 Jun 2025 06:42:09 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CY4PEPF0000EE3C.mail.protection.outlook.com (10.167.242.13) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Mon, 16 Jun 2025 06:42: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; Mon, 16 Jun 2025 01:42:02 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 09969e04-4a7d-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=jfYqHoOngTmz0CNvFzfEiVCQkXDcn2AoCEAzePU8LeK69UOMtXGleDB/RhyuuegoX7D3kyXKJLR9edWFKeecg1n8twcAquCQyuyoQZ98WwE5bkd6U95yKn94I6mzyp3NOjkhpeHHAzalwGPbtAURSztTMCelrK8u2nhhjQNbmhMqfGIXQ3tesoI9bJV9tenQpXUskg1KgirhQg2XbsbNpa5PwEkEs6er9S5n6OVH0xVJDQYt+Czr5ElfNQWug19z5vEjqR3eaBYQnypazd8mgyqHqhlO6p37eAvAe8uEMqrRpevdpDgAqU0+MOnDfVzl2wkFUbWN1TOjYSRBVwsc1Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=QeIUmUq38Uzyb1WbuRkli9IxN8DEmf2a6PHRz26bpsY=;
 b=mA/h+WnWdkBfbOoKZcF/afE9XoraxvPgUvVB0WG+esE8zh3QX0ISspV0NoD5+l1qf7pvgQbtQt2dTvM3NnQUVwR7ZYdjkit6Bn5tXAu1/5zLrWz61YMSxOvZ8NuakmEJEDYLlPjjww7G4DxayKH8UHMV8gUSQmqmO3YoPZdDuaCkeWur0sFGb1SsnAV11r/sMzunnBsKj87eMT5NrvAlXapMR4cv8pfG74Q6OIA5yYlHY6rAnTBH+RkwcAjwYSqbbFqVATaypKVmylnfKmtQYhz0r4BRy4N2QfjpKYmoREpRpcdcKcEb9VoMyBSPUz55daHK3O7/1bxxWFuf6ubwUw==
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=QeIUmUq38Uzyb1WbuRkli9IxN8DEmf2a6PHRz26bpsY=;
 b=ZxkEb3PJGkcZdsQlk5o3u2bpTnFwTbUxJ8/bUwYDbyY3oKuK/eZ3YBN+mqPYVRaMeAFhjxCbV3A8MOcsbPyQ25SgEvJVWKx83+rA6clfD4R91syAihaerY/qzYNJxckfIWdaqoi6IzcpvTkj4Zrs1UR92qLZg5BXmkEyDv2hXJg=
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
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , "Julien
 Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Stefano Stabellini , "Daniel
 P. Smith" 
Subject: [PATCH v5 04/18] xen/sysctl: wrap around XEN_SYSCTL_readconsole
Date: Mon, 16 Jun 2025 14:41:14 +0800
Message-ID: <20250616064128.581164-5-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250616064128.581164-1-Penny.Zheng@amd.com>
References: <20250616064128.581164-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: CY4PEPF0000EE3C:EE_|MW3PR12MB4460:EE_
X-MS-Office365-Filtering-Correlation-Id: 3757cb68-d9f1-4953-73eb-08ddaca0eae2
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?RspbxeGpYR+qKUF1F18DZmoMDYi9OIsabq5gD46sZ8TW8ZrnlmbiVKgh8Wtu?=
 =?us-ascii?Q?HOi5qKA6kMZoc9vReZh03ZFH2SLZ7JryVyi3Dkw8TcuYxS5RZdGHPVZ4FqRA?=
 =?us-ascii?Q?Mdc23ty6NWVaKGD3AcbworD16mRVaf8MlAQvKEYY3NEb44d5d3HW+oBu8Ie6?=
 =?us-ascii?Q?eyHSqxRFokeS3ay+Zn70/oHUThiYX3TJ2BKbzYHIFICJD7kpURElVZIVwoU0?=
 =?us-ascii?Q?gNkPyPdSlhLa3jJQrZQ2/D05lM8cEaFrtIQ9EPCjPoS8fwfhayUlGO8V7yJN?=
 =?us-ascii?Q?zOrC3rje8MWwkSluVJO5gX3R2WK0+oyd9oEMOQaVhTqSkV7x1COZbdq/FlpA?=
 =?us-ascii?Q?bvVXPDM3/8pYEz/uK49ocEn1j9pnMIo94k3uV+hN8OxTiczsldUvw4OJC914?=
 =?us-ascii?Q?3EASq0IOCu/zxUp/0efiFJEwoJQOf/lQ36r8eOo3zGXbrezJ5raJAu5+lIcG?=
 =?us-ascii?Q?A1ucIs7Ff0NiS1JyWup8YftiQZP3aDQ7XheQLvs0ftx9OPqCtTAm4/2B9S+O?=
 =?us-ascii?Q?NCe9VKnJ6GkiC8SkfQIASlCNHG1fRjIK3vNs1j11EzSpm1a9xhQOUpzcdtIv?=
 =?us-ascii?Q?30bMOMHanQT8o60MpKLbfQi9vDUHlxzW8seYSrkNEEmQWPCryR60Wpmx66CI?=
 =?us-ascii?Q?lFVQXt39VyamKPzj70WX+GB8Pli1E/uLslOSDWDyY3XuJHWHqlzb7E1oasbJ?=
 =?us-ascii?Q?cLW+g3Z1MYTNl8fLKvH+OslJBBo/pxd7EcYBnnwnUKDT9ark4ZjGl+O/FVw2?=
 =?us-ascii?Q?ZbjkF9GtjdPoCLTDDe7ma7RC/Ziqp3CzA5ncTN3WKMuSmj0lkeY1Nz2ZsXrn?=
 =?us-ascii?Q?qn3OFOFTumBxgUA6U9EI40V2/Q4ge0LcNy3i4sM7R1BMxLcUOI/hJ0PS87i9?=
 =?us-ascii?Q?EB3vWgTU2WPfg2sS/SXkU7Q1PgT60h78xAZibirZz0w3lK11MQP3MOURvNvr?=
 =?us-ascii?Q?E3LvaNO4f8U8pshDHmXBZIRvoWvvQ3R/dL1x8ml4qlLN/xF/4GWDR1Sj6zKd?=
 =?us-ascii?Q?/duTEKb7DaAdCBV7/lHKEBTIfBB74sWbgw5GP2drG5+vJ1xrgC4GzUqpkUfv?=
 =?us-ascii?Q?rPShNnNl8nLcmy8Te6DKP1Wx/kz5GrOhHy2PDpxndv3NjR739Agk5cTKC60Y?=
 =?us-ascii?Q?4lU1f3LUn7GjVn/jjnWCoVtaANHopoqYnev7OVnL1Z3QAomyvT3Zjl8QKMMf?=
 =?us-ascii?Q?InGGe4yEuIzPWN4+H4MslrW6IWp+pkjzV9LpxRO2qQ1H+RhMWP5cL34yRE7E?=
 =?us-ascii?Q?tSecV+v6CB3YsE6KxuJG2wu3QKPzu+aCfCVYZrkaTGF2wDZKYeP3SyxUC2J2?=
 =?us-ascii?Q?oTCd8iLO8pUeCH6xT/g4hiBQUVs/7Y8aXcT7I5ujXBA4BLi83aHAcFMDgJ5M?=
 =?us-ascii?Q?39xmimKpV5VagTBdfvNt5NRjgf8QVV49niwTVycCcMpL2Ev6mu6rLKJ/ghVL?=
 =?us-ascii?Q?fui6JnbJbw+ySHLX/F5z7edGbBv08Ba5ihdWf7rxS1uvc/dyF0UrzW0E5zeN?=
 =?us-ascii?Q?dEghN30kFekzeFwufA1wJ4A2VS7dCxGVU9hn?=
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: 16 Jun 2025 06:42:09.0890
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3757cb68-d9f1-4953-73eb-08ddaca0eae2
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:
	CY4PEPF0000EE3C.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR12MB4460

The following functions is to deal with XEN_SYSCTL_readconsole sub-op, and
shall be wrapped:
- xsm_readconsole()
- read_console_ring()

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
---
v2 -> v3:
- move #endif up ahead of the blank line
---
v3 -> v4:
- remove transient "#ifdef CONFIG_SYSCTL"
---
 xen/drivers/char/console.c | 2 ++
 xen/include/xsm/xsm.h      | 4 ++++
 xen/xsm/dummy.c            | 2 +-
 xen/xsm/flask/hooks.c      | 4 ++--
 4 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 9a9836ba91..b9de9631ae 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -368,6 +368,7 @@ static void conring_puts(const char *str, size_t len)
         conringc = conringp - conring_size;
 }
 
+#ifdef CONFIG_SYSCTL
 long read_console_ring(struct xen_sysctl_readconsole *op)
 {
     XEN_GUEST_HANDLE_PARAM(char) str;
@@ -410,6 +411,7 @@ long read_console_ring(struct xen_sysctl_readconsole *op)
 
     return 0;
 }
+#endif /* CONFIG_SYSCTL */
 
 
 /*
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 22e2429f52..042a99449f 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -270,7 +270,11 @@ static inline int xsm_sysctl(xsm_default_t def, int cmd)
 
 static inline int xsm_readconsole(xsm_default_t def, uint32_t clear)
 {
+#ifdef CONFIG_SYSCTL
     return alternative_call(xsm_ops.readconsole, clear);
+#else
+    return -EOPNOTSUPP;
+#endif
 }
 
 static inline int xsm_evtchn_unbound(
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 93a0665ecc..cd0e844fcf 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -24,8 +24,8 @@ static const struct xsm_ops __initconst_cf_clobber dummy_ops = {
     .domctl                        = xsm_domctl,
 #ifdef CONFIG_SYSCTL
     .sysctl                        = xsm_sysctl,
-#endif
     .readconsole                   = xsm_readconsole,
+#endif
 
     .evtchn_unbound                = xsm_evtchn_unbound,
     .evtchn_interdomain            = xsm_evtchn_interdomain,
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 3a43e5a1d6..df7e10775b 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -934,7 +934,6 @@ static int cf_check flask_sysctl(int cmd)
         return avc_unknown_permission("sysctl", cmd);
     }
 }
-#endif /* CONFIG_SYSCTL */
 
 static int cf_check flask_readconsole(uint32_t clear)
 {
@@ -945,6 +944,7 @@ static int cf_check flask_readconsole(uint32_t clear)
 
     return domain_has_xen(current->domain, perms);
 }
+#endif /* CONFIG_SYSCTL */
 
 static inline uint32_t resource_to_perm(uint8_t access)
 {
@@ -1888,8 +1888,8 @@ static const struct xsm_ops __initconst_cf_clobber flask_ops = {
     .domctl = flask_domctl,
 #ifdef CONFIG_SYSCTL
     .sysctl = flask_sysctl,
-#endif
     .readconsole = flask_readconsole,
+#endif
 
     .evtchn_unbound = flask_evtchn_unbound,
     .evtchn_interdomain = flask_evtchn_interdomain,
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 06:42:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 06:42:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016517.1393453 (Exim 4.92)
	(envelope-from )
	id 1uR3Xw-0001K1-Bd; Mon, 16 Jun 2025 06:42:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016517.1393453; Mon, 16 Jun 2025 06:42:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uR3Xw-0001Js-7z; Mon, 16 Jun 2025 06:42:20 +0000
Received: by outflank-mailman (input) for mailman id 1016517;
 Mon, 16 Jun 2025 06:42: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 1uR3Xu-0008AT-L0
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 06:42:18 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on2060d.outbound.protection.outlook.com
 [2a01:111:f403:2413::60d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0b6b328e-4a7d-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 08:42:18 +0200 (CEST)
Received: from CY5P221CA0101.NAMP221.PROD.OUTLOOK.COM (2603:10b6:930:9::36) by
 MN0PR12MB6342.namprd12.prod.outlook.com (2603:10b6:208:3c1::9) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8835.29; Mon, 16 Jun 2025 06:42:14 +0000
Received: from CY4PEPF0000EE3C.namprd03.prod.outlook.com
 (2603:10b6:930:9:cafe::f6) by CY5P221CA0101.outlook.office365.com
 (2603:10b6:930:9::36) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.23 via Frontend Transport; Mon,
 16 Jun 2025 06:42:13 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CY4PEPF0000EE3C.mail.protection.outlook.com (10.167.242.13) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Mon, 16 Jun 2025 06:42: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; Mon, 16 Jun 2025 01:42:10 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0b6b328e-4a7d-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=vjoYUfl8lz0JQiz66yWKXsQWUGDR0UpeqxkvyAZ+E6kcHA8II7tWZLQ3UC+UIOgbNaiePyCSPQGd8lOpwI2626cCpyCPvG8Yxl7WO0o5T3ASycej5Zjquo8AL86PLTvZHCuDFogzxFyExlRRRKkyNrxZtgH62s/Tf5ZCUQIpD3+Njctghhy4krGzskCNYl2kmUkk0kiEl3acYQm2YHrf5VbTrobt33GThk3jqrY2ydX2Va37OxwTgMyF8kN8abavFVP6n5GZozW1hxW3rfhRTW5TJsa5GaD4YApUcfdJBtkK5z3ctLYZxbBgTvN1oL9TaFwzkJ+VgnnxptALIGCVaA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=WItGqxAhxBw21f3KfwdiFUW2nn+4erXPhuSpx0xV6H8=;
 b=CYbLa0axuaQcb2a3qxM6rV8bMJxK+kY247ouH/iDrkag12IbbbrZP3YmYrRju26gNjOydMJKZoE9cGIMCBrYc4L9S9WmDqDSOUbJi7RI9ENGovB9tmco8elqx6Ez2lREXMUXh+8a+DQfE11U1jNUJVZloElbbWxK/X5KEyuwPsozC0DbJLEzQkyrXTQJytR8+QsmmLMgYj6D2dMN6XeWcwfTkWU4hn1h9gW/tn6YZPlRCzqmyAxyrxk7/Aw1r/YkXpZmDYYlwlQcUUp0YIFBdbx6w+yqiUt7MEfi8Up1ozBKMkG+b9gvB6fnNnZECZPu0jkllpdUs8Hg6eUo3QoH+w==
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=WItGqxAhxBw21f3KfwdiFUW2nn+4erXPhuSpx0xV6H8=;
 b=GwlqlTm4RtJPDTvOuY1+9KYz5na1EUmw0YaJ8jK2wpaibb7pPq5PuSh5JjzBjzDf78lyavA4LRyasiTLi0hFbtAOAkrMJQaVjBsChDXL3ZTucmOlBDYpYZh6ekPaO8R8gTHyHivBxA+WfVAsdvlSAQSuTjyElTNDddcQDD3jiaY=
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
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , "Julien
 Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Stefano Stabellini 
Subject: [PATCH v5 07/18] xen/sysctl: wrap around XEN_SYSCTL_perfc_op
Date: Mon, 16 Jun 2025 14:41:17 +0800
Message-ID: <20250616064128.581164-8-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250616064128.581164-1-Penny.Zheng@amd.com>
References: <20250616064128.581164-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: CY4PEPF0000EE3C:EE_|MN0PR12MB6342:EE_
X-MS-Office365-Filtering-Correlation-Id: 7fc1f6b3-e0e3-4d65-0ad1-08ddaca0edbd
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?bfhAxVJu620eswKyDFk9HywK6NqQb7jskiZvsWqYZkURPTi3oYrWdTRMk9Hi?=
 =?us-ascii?Q?Hsvd3Uk17FgW60TeVoBkc5cMotn4WipYyQZl84yCBcpjcZXioQU/E8MFg8bW?=
 =?us-ascii?Q?ArkYvm2DoPpgifM7SOGzlZaEYQmXzr8zCbb30hNIYyPsJUpc3SecZwJ3qYy/?=
 =?us-ascii?Q?JNvsj3xDN0Qu5BfWOhBm/lEmbDLLIhHLtEZJNSGE6DGlU4KOdC8ie2UDNE1h?=
 =?us-ascii?Q?EfUthyHQPl9m8HTztBpWPIZQODtvUnx3IwqfGNyQd1WQyQWBSpE7NSYydn5l?=
 =?us-ascii?Q?CQUoB3nKlFt9Pe4Q3EFVkPUzfhCWMrlqd2ufpQNl8JHEUnpRfOH514Ud+9Ll?=
 =?us-ascii?Q?/AeSt0Asj/4jK80kf9ivv7dpWcIOaiXd5sZNV6QNU0kDl6sd6dP3Vbb0xq87?=
 =?us-ascii?Q?6miaYzB7CkWEyVO77fl3OMLCinJrpvaZnLsS8AyS7PjNngIiw+ad/f/QsqKS?=
 =?us-ascii?Q?3CqV+UH4akwUAXXG1L+rXk7EiTfppQfhTlkRvLyj8PyW3cu3Vgp7Z4hi3lDx?=
 =?us-ascii?Q?6rQxkE/PMft616pUu5FCJmkNUYGEZmtab3k9EgTLFE8uJjCsRBo9IIEI0x08?=
 =?us-ascii?Q?iNvI+tnZHqrcmkhLjuUW5FENj61r7cQCLku8FMUOsZs8YpLB74exE+T/oHnR?=
 =?us-ascii?Q?RC+0KuSmIV6aOYYoWRl6ExFe4mb+V4pQI+ZzbyVGxIEm8xz4XKkhwhbpwiK+?=
 =?us-ascii?Q?xUAZ+BF/XdUH7phxafZ7/u42GwXt2zvlk6y/KCpnvrZPEBg/9O9Q8FBvmvbu?=
 =?us-ascii?Q?6rNr4pUpn0TZEod0V98Aul0sKD6iXetrTXLY7WZD9j7slv7VOFiJfSKnE33P?=
 =?us-ascii?Q?qiHadFmbyrQrvTUVn6KN8C+vz0x8RlU3YCemPtpW+HeXpz8yEJTycHbzJqh+?=
 =?us-ascii?Q?7iXsKu10R+WfrlxEX5YKTPa+jkzKfNFs64IYvGpvrDr9DwROUe8QpEwXf6fN?=
 =?us-ascii?Q?rODyuHsvKlpiH1kTqt0MyW/aFPI+dYBRd46IluFgJyzQguDwusDtZmJOhyJy?=
 =?us-ascii?Q?SSR3OrfcH+Ia+lUIUI+Wy6jg6jXzVYmLj1+H1Xcr+oYj+RLftP+xwWwptqU+?=
 =?us-ascii?Q?f7Zge5ixLaIhobUDLqmoppiO8GxOrFY6PcrevHFY15Cg8wKRsNXd/P3Jnm3M?=
 =?us-ascii?Q?5/UpoCgKqQtemW09h53BFxHebaEzrFQejr4PI9SLOYibiqD2iKwMoRDTHYk1?=
 =?us-ascii?Q?VdsL7YsXf2td9IpAb97XKRwkS1KmPf5TEupiiwng4nXim/yjpJGsSEegsGA3?=
 =?us-ascii?Q?bWRkjG+CohVp6GJuMiHb9eKe/5+fWKJsT98gVvddjcKQbWnVHDF3sPbY5hcL?=
 =?us-ascii?Q?45DKuumno39nX5x5q0WXUqmMmWnQMkQifLjwScG4PmqUOi3r2kV+5iPtZdro?=
 =?us-ascii?Q?x8kXja9iwFLamDO3+VuZog2GWYmehIUaHAT7zJu3d0wfEkPKDFXdre7peY3T?=
 =?us-ascii?Q?stxGoYiiL9jjK06PvMA714uyMS5yUztt4kxw7D0BxKiSz7A6WoUAKYzJxBLU?=
 =?us-ascii?Q?5+TzDhM67ZNi/S0BNIg+ww0JUmX5Vbry/E5M?=
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: 16 Jun 2025 06:42:13.8768
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7fc1f6b3-e0e3-4d65-0ad1-08ddaca0edbd
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:
	CY4PEPF0000EE3C.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6342

perfc_control() and perfc_copy_info() are responsible for providing control
of perf counters via XEN_SYSCTL_perfc_op in DOM0, so they both shall
be wrapped.

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
---
v2 -> v3:
- add the blank line
---
v3 -> v4:
- remove transient "#ifdef CONFIG_SYSCTL"
---
 xen/common/perfc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/common/perfc.c b/xen/common/perfc.c
index 8302b7cf6d..0f3b89af2c 100644
--- a/xen/common/perfc.c
+++ b/xen/common/perfc.c
@@ -149,6 +149,7 @@ void cf_check perfc_reset(unsigned char key)
     }
 }
 
+#ifdef CONFIG_SYSCTL
 static struct xen_sysctl_perfc_desc perfc_d[NR_PERFCTRS];
 static xen_sysctl_perfc_val_t *perfc_vals;
 static unsigned int      perfc_nbr_vals;
@@ -265,6 +266,7 @@ int perfc_control(struct xen_sysctl_perfc_op *pc)
 
     return rc;
 }
+#endif /* CONFIG_SYSCTL */
 
 /*
  * Local variables:
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 06:42:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 06:42:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016518.1393458 (Exim 4.92)
	(envelope-from )
	id 1uR3Xw-0001MS-R4; Mon, 16 Jun 2025 06:42:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016518.1393458; Mon, 16 Jun 2025 06:42:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uR3Xw-0001M3-H6; Mon, 16 Jun 2025 06:42:20 +0000
Received: by outflank-mailman (input) for mailman id 1016518;
 Mon, 16 Jun 2025 06:42: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 1uR3Xv-0008OL-FG
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 06:42:19 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20617.outbound.protection.outlook.com
 [2a01:111:f403:2417::617])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0b16c8f8-4a7d-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 08:42:17 +0200 (CEST)
Received: from CY5P221CA0107.NAMP221.PROD.OUTLOOK.COM (2603:10b6:930:9::34) by
 SA1PR12MB8644.namprd12.prod.outlook.com (2603:10b6:806:384::17) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.26; Mon, 16 Jun
 2025 06:42:10 +0000
Received: from CY4PEPF0000EE3C.namprd03.prod.outlook.com
 (2603:10b6:930:9:cafe::a0) by CY5P221CA0107.outlook.office365.com
 (2603:10b6:930:9::34) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.23 via Frontend Transport; Mon,
 16 Jun 2025 06:42:10 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CY4PEPF0000EE3C.mail.protection.outlook.com (10.167.242.13) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Mon, 16 Jun 2025 06:42:10 +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; Mon, 16 Jun 2025 01:42:05 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0b16c8f8-4a7d-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=LHP8c6xltoivktzM5tyfbrozM1fc2rRGKmKhQj/FrNXXRllundcAnT25XAGa8gXWh2Rj6wKOyqh1vdtxaJODJKGeaarRB7rrPXr77ajClmLa8kY0qg2FsX6c/kpz+QvFOk2QnKfm64tSimRjFFMMcXoRCzIYueqm6s9UE7A+JLW/vomekJbqDivuluja/p0+iH+O7/vFVaBU88ckNmiqrXWUCCFUn3wVIGBXLZ5MGhSOlP3QvAPbSI9odQF9U/RACUALVLG7bMpKPDrA3Yu+ZzMiyNCcPxOpggsMNSrueczawJgUqDAD0z8byeAF5jIwpLl59F4Tor7iJ7M/dgBPdg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=30rk0j5lpGbWOdYBsFmDDdDPGEoAQD+DekB96/2T3ls=;
 b=b9iXDyeWayOphPyIBZFuMP4jAW9pxmeh5YddyZuwqjQGuGvgyhzM3w9DJ5NZQCEnhh/brLn29JDU+gAEP9AU3iplNOCGJ4+7Yp0aaWFag9hZD4unv8O3ZxOtMY+emA/W4N6Niw1370m600Ls6xMDa3aPsaQ2C8a0GIVaPlPZbc/y2O8SmOpfMS76X8txnzYFEV9cGHmQX8OumpDiD9dPtX3+jle/qOdyDmIBRwCGi/gMGd2BpVLjklnmYjMPxxub2VdMdj9tNj0vEU+aTuuGjz2xgdqOmo1aMRsPk9LCBM0xbJ8XXHGGIayBPQOPi0rari5lTDZhlg16JpkWvtRqaw==
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=30rk0j5lpGbWOdYBsFmDDdDPGEoAQD+DekB96/2T3ls=;
 b=IumSwuNJ99fQgcEkL5r40ziOqYDaVH+yPh3YryDSr+EE216tRUYDAaLC0NDnyU9x8NNFXcE/ondlAGOQXFfXET9YtfUwBua8no20HErDZfxDGvgAVi0nm42qDm1H3woCSqSiWQzOp6BGA6upZ3TOLY7v6IOyR6lXQBpFEv5h9kk=
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
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , "Julien
 Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Stefano Stabellini 
Subject: [PATCH v5 05/18] xen/sysctl: make CONFIG_TRACEBUFFER depend on CONFIG_SYSCTL
Date: Mon, 16 Jun 2025 14:41:15 +0800
Message-ID: <20250616064128.581164-6-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250616064128.581164-1-Penny.Zheng@amd.com>
References: <20250616064128.581164-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: CY4PEPF0000EE3C:EE_|SA1PR12MB8644:EE_
X-MS-Office365-Filtering-Correlation-Id: ca12a660-5509-4571-f80e-08ddaca0eb75
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?Auf/xhgScYdJ5B4hyxUV9bPsc3Rsqz0tC3vemEsk70ZyQ3pxguxOZc6j3kd3?=
 =?us-ascii?Q?v3rt9QzfaUkT0jXnrrgBLP1aTqq9qZZjmO2m1m8+Qv5DB4rZ65W2PZu99gkT?=
 =?us-ascii?Q?qX37ZifUKAIn+zWRwmo2cAJa0CDgoPWccAOujYpNLWL5uv9hH947Qe0GoMIK?=
 =?us-ascii?Q?EsVctk6YfzJM4saC5OISyktCgu6B6D/BbZzwqN2tGyDP5VFXzWLX7eHkOpHL?=
 =?us-ascii?Q?u6SYWeNphPac0HSu3LvsbClitEmW6TJijmbnwhyaQt+Z6QBvRQd8ckDDU1+r?=
 =?us-ascii?Q?9reeDyHJo5tHlIz3Oj0IlQdYe9mmJD/9XSx8c3PIxAUn0EmAWpTX7Y4G94qq?=
 =?us-ascii?Q?cQ4HrgvJf3h3m4E9wsP7Z1faClToYFrYshtpI93S8foyQ2Yqap3Na4skBhth?=
 =?us-ascii?Q?O4jYTyqI8D5jKbjhHOA5yUjBEwWoQKkxgvEMLt++3+FFkswsP94fmt61mFEa?=
 =?us-ascii?Q?PGL/UZ27a1DUvxHzAwIC8oXZZZbHk4don8vZG1UTF6oz/oAZLw1fS8UJFd0Q?=
 =?us-ascii?Q?xmJ2/9pZZCf/D4kq3Y0Im5qSoGMhO2Rl442YQ9xXgM0cxjxBDGvYFgfFnp4I?=
 =?us-ascii?Q?JfvxJzOf7F3BPzV1fQwrlCb2YJPhA9oUhGVH9RYCoqPF4/9jy+dM0ltkZQ/8?=
 =?us-ascii?Q?i8t95hnSI0hf4SxmTiqB/BnwFk9diE9nu40CO0Y52UR+efljPn7Kct+J6TLF?=
 =?us-ascii?Q?9QqK49WvncBSlb11k/fgjNSBr1pMFl/5hQsM5E0YfjaVBtEMrDCRGUq1eJQo?=
 =?us-ascii?Q?/acQ6p1QNBQW3X+p9AKVb8hA8XfxWRnKGG08/CPwmSK7hh8fc1rykbfpDUx0?=
 =?us-ascii?Q?XUFOiZVPyN/bMjsUAMoxTwZUg4ZifDf+dIwig/SfecrGZQnBRIYf+WAG4PUF?=
 =?us-ascii?Q?B2CvKVaU+93pG4j6L2w4sOgdCtAnmw1B3Uhz1h8XYDHXOrt7n5LquTCl23Cb?=
 =?us-ascii?Q?JQn4GFA+HYyndpSffCW7WvOIqBsQzVYBhpaCbL9LPDRi5H/o8XeWr0n7A+MP?=
 =?us-ascii?Q?A2fFWdlKuJ4NHBYOF1BKZho51YpsYqAjmmUiPKtIVKpg7v196giFATcy6Eq0?=
 =?us-ascii?Q?Vo6VAgLw8ZNNB4CzxzsLqE+RPeb1ov516lI8olaU0rqVjtcZq4PLhvLhLVpc?=
 =?us-ascii?Q?lgYxS5oA2rW/N8GitVwoSOPEqUkFsbpThUphocETcSF0lzlhRs+qMaI3Xnhu?=
 =?us-ascii?Q?CO+CYCmm6TQMVZrz/SGZIw3ieeTccfxVSNyPrCdJ+CFenvImxZfHn52WSan0?=
 =?us-ascii?Q?c9SEIqMO0LX0OnEbDznN2vwQ55QPJeTBR8hJbYD4ory0mHjPV9sJ3AJBFS2f?=
 =?us-ascii?Q?jTcV5sA4qZd/k15IMBMtFFoaU+p1vymqB/ehaUJd5wIkFGpOIAimBY0sdqWM?=
 =?us-ascii?Q?KFLeJARP/PRCwSPvzcwCVaMAQ+mE9sFHoIervu71u3MVtZT4OwucclvHYSsu?=
 =?us-ascii?Q?wqX6XwKBoRkRG7Wgh2aap31aeabey62n+b5ngIVzLfqd4U15Yeraur9fNoIw?=
 =?us-ascii?Q?3vQzSR4MmHdVJEd2Oc7VX8Qj1tXbUx0m5aPM?=
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: 16 Jun 2025 06:42:10.0558
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ca12a660-5509-4571-f80e-08ddaca0eb75
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:
	CY4PEPF0000EE3C.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB8644

Users could only access trace buffers via hypercall XEN_SYSCTL_tbuf_op,
so we shall make CONFIG_TRACEBUFFER depend on CONFIG_SYSCTL

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
---
 xen/common/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index fb5c60517a..dbd9747d1f 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -564,6 +564,7 @@ config DTB_FILE
 config TRACEBUFFER
 	bool "Enable tracing infrastructure" if EXPERT
 	default y
+	depends on SYSCTL
 	help
 	  Enable tracing infrastructure and pre-defined tracepoints within Xen.
 	  This will allow live information about Xen's execution and performance
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 06:42:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 06:42:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016520.1393471 (Exim 4.92)
	(envelope-from )
	id 1uR3Xy-0001mA-7c; Mon, 16 Jun 2025 06:42:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016520.1393471; Mon, 16 Jun 2025 06:42:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uR3Xy-0001kb-1p; Mon, 16 Jun 2025 06:42:22 +0000
Received: by outflank-mailman (input) for mailman id 1016520;
 Mon, 16 Jun 2025 06:42: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 1uR3Xw-0008AT-LS
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 06:42:20 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on2060d.outbound.protection.outlook.com
 [2a01:111:f403:2415::60d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0c94ab09-4a7d-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 08:42:20 +0200 (CEST)
Received: from CY5P221CA0079.NAMP221.PROD.OUTLOOK.COM (2603:10b6:930:9::16) by
 CH3PR12MB8912.namprd12.prod.outlook.com (2603:10b6:610:169::15) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.28; Mon, 16 Jun
 2025 06:42:16 +0000
Received: from CY4PEPF0000EE3C.namprd03.prod.outlook.com
 (2603:10b6:930:9:cafe::9e) by CY5P221CA0079.outlook.office365.com
 (2603:10b6:930:9::16) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.23 via Frontend Transport; Mon,
 16 Jun 2025 06:42:16 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CY4PEPF0000EE3C.mail.protection.outlook.com (10.167.242.13) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Mon, 16 Jun 2025 06:42:16 +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; Mon, 16 Jun 2025 01:42:13 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0c94ab09-4a7d-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=pVmLdi47vlZNlcUWRqS7mlnyQMAJCVFUpASLGD8RaIVWHrzCxzYYnJmn07j88lQGHU7xuKWj5BzHOQdrpMLddkZ5BUrvqOomE8lSamp4ywCyzqurVgd34lOv9XCuN6lvSygIf/3B9X33gP26nWfgT40vv6iWh6Nz+4mlcRJgYViT67rpBQM6sSPtcVPEbOcqdfJ+tCPz+kW8G3AR4TRu0HWWqNAucxDIduIFmoI+ucMEFR+RmpaGL2ApYd2I9V+DXIyVf2QZqHchCckmp9JZxSJ8FczYlKZaCK2ue/QTCFM0h8OftmqZj4I2a1t9CJvTtaF2CyxR+rFwAAUUtK8gxQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=TPsu3Whzar30hPPztM4eYMHCA+8Epbp9x/t6GVQxLw0=;
 b=SuNrWdKcc3XV4Y9qGslJOAQWyTvbW80BOpKG+N79L9nP3zF/uTdMTwXyg7VxR5XOTeNnGxc9j6yS7zzRWKPdSU99t+lrx3rYv2PI46LG9IWFPz9sNwJJavMcnSkr2rINyKsJTqPY2Sq3GfYzOSnv2OoKPLoj7AwiH6tTBjMZLYuDuKzo3lY3gSVHMwUeTxtXMPYuZ+ipo0dhcrb78VN+T5Nwj7KJAVdPkBC2mNlHQgWneAal+Dzdy74PtLwa3haYMnJKZ3oWUvlXcGl0LDqcq6uaLfpglrMlwCj6ZTIbELWCNWcxvIqX+1yE2X4R5bhjCZcZ6OlzaVp29BOvirj3wQ==
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=TPsu3Whzar30hPPztM4eYMHCA+8Epbp9x/t6GVQxLw0=;
 b=wOLJylAQuqi7OoMouxOcdy15IyJtli0NSftv8e30qmeKWqYI5Ft2M+DIwbBXX8QWdcxDSPwDBQuISpI1aXB8ZFc0QqA6+wnjcQg9M7oYq+Q12wNQ/5uP084qruD+m4h8JoHYRNteZQy/1VjIbTfTjJ6kwL14bSRczBhNpiPfoTE=
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
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , "Julien
 Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Stefano Stabellini 
Subject: [PATCH v5 08/18] xen/sysctl: wrap around XEN_SYSCTL_lockprof_op
Date: Mon, 16 Jun 2025 14:41:18 +0800
Message-ID: <20250616064128.581164-9-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250616064128.581164-1-Penny.Zheng@amd.com>
References: <20250616064128.581164-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: CY4PEPF0000EE3C:EE_|CH3PR12MB8912:EE_
X-MS-Office365-Filtering-Correlation-Id: 082a468c-fd40-4427-ef12-08ddaca0ef16
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?yIcXdGt3LmXI/IAj6VezHT7klzfM7kh3dc2XMb4TYML0X+scdgYjJZg7zPhL?=
 =?us-ascii?Q?/yIJFuYsr9eTQzjuCbNwIb2Gc0uyzSfiFtVIwO3b2YBJ4FSnwu3Wm8XLDGqV?=
 =?us-ascii?Q?ckSp24kR2V5frD9hxF28Ur1HiHmrLYpRAx0+HUOsfRcGquqYlmcmvz8EtM1w?=
 =?us-ascii?Q?zJQuMNT3MCZBEtuMVBsFxaGU58SDznDFvu+t1Nm57kKmf+VFXZHNH6AHOYvm?=
 =?us-ascii?Q?HX1Bo2XACCMx1lxKltUkcbKTkvSZ5mpp5EmFQnqxeOPN1okjqwuBAJxOazNQ?=
 =?us-ascii?Q?sMOoG8rLA+EHc4U6LQqdiQYMPuiQB7UKq6qbyBap+5wy34iU+OPCWM3Z9vce?=
 =?us-ascii?Q?UlC03Mw7KLdOcrOUQ3HlJcGKg5jjdQ6e8sD8N30DNz34dY1PswzXzH4SqXmR?=
 =?us-ascii?Q?xgCf1R/haOTGnNBA1I0KzRs3dJ9F6jcxG5UDDcYfz6B2tOmDn3RgtUJMEW6V?=
 =?us-ascii?Q?WWbkkNFHnoQZzad9v1YULKoHu42ZjMqM3BIBcAEbo12BhT8P5PGnuEZdr9KE?=
 =?us-ascii?Q?PCd2VXdy11gpxkSFCSD/dSoiIsaloPKiZ2uwDxqm75wE4NxsLH5+ZqqWOeEB?=
 =?us-ascii?Q?W2DUdGTim2mcqtSYxP7p7NWg8d1llbxOtm1weH6TPU+NLRoPzr+buzUFOsCk?=
 =?us-ascii?Q?j0wxhLIEuu9vQTeUe9TNGgzEQ1gZXaLII0A3DvwUUBu+rre2lBjHigPkEGjb?=
 =?us-ascii?Q?E5T3aJNolNblOU5oyV9L+9mfCITqLuduv+3A7JFjjnnlxX9kkV/mTtb4HmYg?=
 =?us-ascii?Q?ytwI6T7QvXb4a5b+U6AMR1cjNy9d49i76OPwa4kLsrj4nr1G4Q3waOYsMJcx?=
 =?us-ascii?Q?O8odZvIkjyIEvEE1U7L46iUKKqlW9p6JdaJBBxGhLZ5EhyKIWSRcjFuTZyaz?=
 =?us-ascii?Q?mEIorFHxl08oqGv5ZtIc5R8BUXgKq6iNHICuuPnPIAtlGu4uPdH4aNXm2FFj?=
 =?us-ascii?Q?w0No81xar/ylCcgMtnLNPRnHJMeb0B+LYZ4W6baez2pAM0PbX9dldVj2BCdh?=
 =?us-ascii?Q?k6c3LCCycBvwSdL+jhANGTrPIfljwJ1cWKL7jGNtavfMjqprSGZLxZxNPIVL?=
 =?us-ascii?Q?jaaPqVfRBj7bl+fpwTQSfhqQs4QcznIANeQWbKDQidmbvhxg1olHg3nV8ike?=
 =?us-ascii?Q?KepWDMifErfuydjqvlfTTIqf6OvCuWrt4RyNFjxorYtP2XkDt/qu3p5wM6Bp?=
 =?us-ascii?Q?XyBVWE0pgkiVQsIzmpTT8ptJJnw5/3fdk57hEzNFX8EjW8BtB54wZrWO8tOS?=
 =?us-ascii?Q?go2M8ObU9cThasYz4ZEMBsKZRXp9T269AEhBii7TEQx19SvfXMUjxB9inGFk?=
 =?us-ascii?Q?jn9WsfwfwG5iBHYb3q7rcPOXUbl/A0ZVKNtzKWB/JeF9xHj9yTtBAtbyGj+P?=
 =?us-ascii?Q?zPqlW9fayR9BgwotHWyb292xL/jEwfu4OOfmrTOGFaY0LX4bdsocNWdjGMUf?=
 =?us-ascii?Q?jIVLREthy9A5XFIYALtfDqE4U+PJ7OsDspmDn2jUAutkA3AYnzN251IHcC3q?=
 =?us-ascii?Q?KbO7z2cWe/DYj46XmC+1aPUs5VC3+IpFW2QC?=
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 Jun 2025 06:42:16.1444
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 082a468c-fd40-4427-ef12-08ddaca0ef16
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:
	CY4PEPF0000EE3C.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8912

The following function is only to serve spinlock profiling via
XEN_SYSCTL_lockprof_op, so it shall be wrapped:
- spinlock_profile_control()

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
---
v2 -> v3:
- add the blank line
---
v3 -> v4:
- remove transient "#ifdef CONFIG_SYSCTL"
---
 xen/common/spinlock.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index 38caa10a2e..0389293b09 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -690,6 +690,7 @@ void cf_check spinlock_profile_reset(unsigned char key)
     spinlock_profile_iterate(spinlock_profile_reset_elem, NULL);
 }
 
+#ifdef CONFIG_SYSCTL
 typedef struct {
     struct xen_sysctl_lockprof_op *pc;
     int                      rc;
@@ -749,6 +750,7 @@ int spinlock_profile_control(struct xen_sysctl_lockprof_op *pc)
 
     return rc;
 }
+#endif /* CONFIG_SYSCTL */
 
 void _lock_profile_register_struct(
     int32_t type, struct lock_profile_qhead *qhead, int32_t idx)
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 06:46:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 06:46:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016560.1393483 (Exim 4.92)
	(envelope-from )
	id 1uR3ba-0004Tf-Nf; Mon, 16 Jun 2025 06:46:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016560.1393483; Mon, 16 Jun 2025 06:46: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 1uR3ba-0004TY-Js; Mon, 16 Jun 2025 06:46:06 +0000
Received: by outflank-mailman (input) for mailman id 1016560;
 Mon, 16 Jun 2025 06:46: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 1uR3bY-0004TB-UJ
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 06:46: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 92b31696-4a7d-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 08:46:04 +0200 (CEST)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-ade5a0442dfso779151166b.1
 for ; Sun, 15 Jun 2025 23:46:04 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-adec81bb9e4sm593157266b.45.2025.06.15.23.46.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 15 Jun 2025 23:46:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 92b31696-4a7d-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750056363; x=1750661163; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=z4li5pnrfw+bj5h1kspRnPPFQ3tdxGne1EH5hCbEDn0=;
        b=QljBywIEyaItxF0QDvdJ/Klz/vvBvHHjHEJz589/sKxCqCvFrjgBVUlA3J4jPVayqh
         rVK7NV/WMOqz4KTF3sh0msmLPczpRuGqIKe5c0adefHLC/CvzZrE4+UrO1rW0gHaB1em
         /YobSViKBrqQDAj2cHNIcEwQr57Vg5JPALJJeQi2TFeWw+glE0gXENg1X8I2kYdgtrRD
         5BNJgdq5MmZNd3i5b0+1HDKL6l01SzX2wj9jw5vNrk0bjJTbax6zrn2TBhLVy9CFiTBf
         fpuPFrf5pC4SiJXBLQBBMnFgF9dGk/ReMJ3sxCC5awhWwnl9Oqy4s9ev7WPvNuA4LqkV
         nNFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750056363; x=1750661163;
        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=z4li5pnrfw+bj5h1kspRnPPFQ3tdxGne1EH5hCbEDn0=;
        b=QSKpo/EiHZVibiLF+5EAI3ylfuRazp+UF4eS0qfdvql9wIk8uLnrsRLSo2fQ8ao+q2
         2EgMa/yy/0S3f8k8u+mWzHqeMk2TBXpud74SKtPg+4L8pszWQP5oNIGdOIuW4WB+puYg
         MDdSXPB29lJ2XqOFWcoo2HAaJHoKp1Zt55tabIvi/0rXVg1jiOdU6/HHZFb76cSWSrdB
         IKFfVmt30zRyX8jLMKJRqDa9lDFQjtlKoJxHK2Zrj7cr7eSIsGIiZKFHosnxj2Igx/Rk
         ySzBs7IiLaOUzXXCWWNXwKwNMI7E7NdpJmOT2YnbgP0HMh2llYQXfllmZQZWxsetBwLx
         2uzA==
X-Forwarded-Encrypted: i=1; AJvYcCUdVawIDZG1htzVvLcCRndwYDxn7ITz5kKBDTWRtFs+otZE06PV5v0ff5E4ih4+EvGeR35VGc6bVUA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxJHXdLPBiYDjjt/gHG+QRTFnQCB5Tn9m4S1NXTOs1SwdFLvQo8
	M63CzpZeoY4tGYeC4JrLfqW7qs3A8KnUBXAy6cXxzagBBR2LoKuI5euAf5r0oYSjrg==
X-Gm-Gg: ASbGncurgAhQPaYMOjED51xX2K/wh/4WGOgw2DWo21f6ssthZSpdcMMSIZEz/pBp/K+
	rMWB5qiwEFAtyVQJAxNNL1KcgmiCIlmIgfDmvxN5Fw92nclO0oAC3dgrFAWX5Mau1DBIP0H07YY
	GpQROgPH/NRZXOZokU9l/j+haMtjs7L+8kbT+F9QwsqkYyLb8JXMBwnLeRZY4rN+4p9ZExHmCD5
	rPxnzCm0VH5BroD6fSQ1wQEALP45UnEiUeC6uhjIfk7fm7Z7PQUfLj5/5voYjWO0ywdmMl8z4lf
	x3QUvGZoQspsO0+cakPKliz14oW68hfVCCM5kunIP6wi8jshTmtMCx2vUfnK5LFlF+KLBR3WBNU
	ezF0Dz1yvnjKj9GM4dYEm3HrT0IOE3l+3zB9vtl4D4y7yRsc=
X-Google-Smtp-Source: AGHT+IGR5CjJEjIfiHWPTsDjdlyKeR9urcILrqUUW7YVtm5qG/pUoBwD1JhS+hiWXrDteqbtnykuyw==
X-Received: by 2002:a17:907:1b18:b0:ad2:2fe3:7074 with SMTP id a640c23a62f3a-adfad39c00amr702113966b.14.1750056363482;
        Sun, 15 Jun 2025 23:46:03 -0700 (PDT)
Message-ID: <938c0c34-5d98-4454-8e60-719b8eecc027@suse.com>
Date: Mon, 16 Jun 2025 08:46:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 02/14] x86: Preinitialise all modules to be of kind
 BOOTMOD_UNKNOWN
To: Alejandro Vallejo 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "Daniel P. Smith" ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250613151612.754222-1-agarciav@amd.com>
 <20250613151612.754222-3-agarciav@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: <20250613151612.754222-3-agarciav@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.06.2025 17:13, Alejandro Vallejo wrote:
> A later patch removes boot_module and replaces its uses with bootmodule.
> The equivalent field for "type" doesn't have BOOTMOD_UNKNOWN as a zero
> value, so it must be explicitly set in the static xen_boot_info.
> 
> Not a functional change.
> 
> Signed-off-by: Alejandro Vallejo 
> Reviewed-by: Stefano Stabellini 

Acked-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 06:48:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 06:48:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016569.1393492 (Exim 4.92)
	(envelope-from )
	id 1uR3dx-000506-1a; Mon, 16 Jun 2025 06:48:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016569.1393492; Mon, 16 Jun 2025 06:48:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uR3dw-0004zz-VG; Mon, 16 Jun 2025 06:48:32 +0000
Received: by outflank-mailman (input) for mailman id 1016569;
 Mon, 16 Jun 2025 06:48: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 1uR3dv-0004zt-9N
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 06:48:31 +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 e9ce6659-4a7d-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 08:48:30 +0200 (CEST)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-604f5691bceso8546927a12.0
 for ; Sun, 15 Jun 2025 23:48:30 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-608b4a5b6fdsm5648284a12.43.2025.06.15.23.48.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 15 Jun 2025 23:48:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e9ce6659-4a7d-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750056510; x=1750661310; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=3Eqz34ir83h+BPyKXu5kxE5u5V/uMIpX5Jbo0LuRxs8=;
        b=Y/6nwRQB9J/2viXU73sWJL/xcKf8OJqqYvwJ95EhoWRRgluNw6J0cT2Ndm4yuC5Y8L
         t1q2VRCf47aNmMmZVRNPLvPf4SuiqKgUbDQoF3miy92/jfKwHw/yTie3VI4YlkeZcrX0
         BE9JH0Uh7Swc2s1ExVUn9WE938pCr2sXm2i+FcOvOlgaq44x8lkCCzg95QMrNNYqw+mF
         9QvJ8FGUcW9KP6vku2/aBa+TcBMPTsTRlnvXfqmbEWOHKLoJokft8X785RyBHTrXEaBo
         EU3aSHMQlDzjuBcjThKDf5Dh3W81nOtbFAK4++3Usc5u7bPjU14KsaGT7Cf8ilfNwPcX
         B5Zw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750056510; x=1750661310;
        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=3Eqz34ir83h+BPyKXu5kxE5u5V/uMIpX5Jbo0LuRxs8=;
        b=dwISCaBZ0serWzQjcuOdk5OijcZ1xr8QWd0RAwSXkCVNKEpSzeaCT3yixgZX/LMSw6
         58FUGCTuk3nDvGZZ65vy/BNC5IpxGu/L8R4DbLSwcgpYvtjk8YLlVSQbYozduMOorDCK
         rEfQNAW0Ik/q2+CC8ma+qjtKnUkJPpv1phv+9Gk4hcu3diQlqtiWsx+ZsAiLsQrZFKOE
         qDjyttoduUNjOoZn4V+nf7EEWR0r9f5GLE3r8g9dtbVfpygFxiYwWDnLQucGLzjOqwtV
         uda14CuXUozzsW1uI0ok8OYBj34YYjzvj9DK8V2Y3sjd6rTq7qrbaXrrKvmgYLPFYTdL
         wa4w==
X-Forwarded-Encrypted: i=1; AJvYcCW9QI3gCcBoK6+LjPKb7M71ay8pocg/cWGaa3ESK9T03z/gB/lQK2b9sDpEoIpJmxnoSEVZTVeByi4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx+7+oxhqBvS2eY2iUArO86wlLviBNwJhRbT2t1E2tX6zLH80um
	5GISQAjqHoVmJFOn1E60UUW+t0togAy2kneVUdOm24m1IVhz1zMn6ksS+7IprXcUyw==
X-Gm-Gg: ASbGncuelT2J29vUPPkQloKdEgydwO8HWYpSLsnqxwZ8JTqBRbA93JuPkFvLmT/+4on
	jtXzxPa/4D08adTWhTRk+yr51FTtJSV9PT8DC5+UnKxsAKhNUd/IJ3jX68EU2oJ0kJHKTPnG3Hw
	0rx9qkusMOCS+0UCPLo4ovK85cA/N7aZ7VGmJVxvJoPQg33aFL/AI4xlN43UJD0tm1tc+8lmkIp
	YiKNbPrSccilXtxPhgdA4rJylE78/vl1ZFjioK1QLgsJEUHr3GEJZi4CVDnuY7G8k13D8mtxWnY
	hN3LKqd6UGgSDdTLe2KgF2RaJNp5374V0vflpLwklWxrUBLwv2RHwVQSqSEO8fVcax3gmfsAm6R
	TdygGIdWz4NtEqPXuB2obIyXyeWBCwL9mqt+iSKbTAh+2wrE=
X-Google-Smtp-Source: AGHT+IEgwZzxWAg+/xOcZxXgMaOMBfQjS/yCouKzxlecEf0qfKaS2DhinQpLv4n4rbE0lKgli3H2zg==
X-Received: by 2002:a05:6402:210b:b0:602:4405:777b with SMTP id 4fb4d7f45d1cf-608d09bb6fdmr7135068a12.24.1750056509665;
        Sun, 15 Jun 2025 23:48:29 -0700 (PDT)
Message-ID: 
Date: Mon, 16 Jun 2025 08:48:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 03/14] CODING_STYLE: Custom type names must be
 snake-cased by word.
To: Alejandro Vallejo 
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: <20250613151612.754222-1-agarciav@amd.com>
 <20250613151612.754222-4-agarciav@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: <20250613151612.754222-4-agarciav@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.06.2025 17:13, Alejandro Vallejo wrote:
> There's the unwritten convention in x86 of splitting type names using
> underscores. Add such convention to the CODINNG_STYLE to make it
> common and less unwritten.
> 
> Signed-off-by: Alejandro Vallejo 
> ---
>  CODING_STYLE | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/CODING_STYLE b/CODING_STYLE
> index 5644f1697f..e91ef7b3ca 100644
> --- a/CODING_STYLE
> +++ b/CODING_STYLE
> @@ -126,6 +126,9 @@ register).
>  Especially with pointer types, whenever the pointed to object is not
>  (supposed to be) modified, qualify the pointed to type with "const".
>  
> +When defining types, split its words using underscores (e.g: prefer my_foo to
> +myfoo).

Why's this being put in the Types section? This is about identifiers, and
ought to not be limited to the names of types.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 06:50:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 06:50:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016575.1393503 (Exim 4.92)
	(envelope-from )
	id 1uR3fy-0006TI-DV; Mon, 16 Jun 2025 06:50:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016575.1393503; Mon, 16 Jun 2025 06:50: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 1uR3fy-0006TB-Ak; Mon, 16 Jun 2025 06:50:38 +0000
Received: by outflank-mailman (input) for mailman id 1016575;
 Mon, 16 Jun 2025 06:50: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 1uR3YK-0008OL-DO
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 06:42:44 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20616.outbound.protection.outlook.com
 [2a01:111:f403:200a::616])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 199c6a8d-4a7d-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 08:42:42 +0200 (CEST)
Received: from DM6PR12CA0012.namprd12.prod.outlook.com (2603:10b6:5:1c0::25)
 by SN7PR12MB7881.namprd12.prod.outlook.com (2603:10b6:806:34a::9) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.28; Mon, 16 Jun
 2025 06:42:37 +0000
Received: from CY4PEPF0000EE38.namprd03.prod.outlook.com
 (2603:10b6:5:1c0:cafe::35) by DM6PR12CA0012.outlook.office365.com
 (2603:10b6:5:1c0::25) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.22 via Frontend Transport; Mon,
 16 Jun 2025 06:42:36 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CY4PEPF0000EE38.mail.protection.outlook.com (10.167.242.10) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Mon, 16 Jun 2025 06:42:36 +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; Mon, 16 Jun 2025 01:42:33 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 199c6a8d-4a7d-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=WqoOZWl7Z4nPqR1AKooQiOfTQ/zmTQDMb17XUv0gcPJG6ed0/TfNQfvO/cxgUjO/pPf5U2gJvjehFQrrG3tk0pDs3asdE6tYBOaWbDX3PDaFQVxZGDsZ4NXoTQ9ALu+pbbifnEk5vBnopdjdjx4n76TbEy0VnoNee7G7SlP7uLBf1d+AFuDYkM+j4gjIfmR0F0B/Fzb315abRnWUFMk0RgMDof+2zZo8yo6RrVZeo7ybepf0G0dWpXRfNqhHzpuj/qgmznlT7z6MoeyMlPpcj9pKt/9I1wxZMUmrCrEz9bOYPdg8quv0HUyoIC+/t1PEinOO9Zhs+JfU9Xys45jIvw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=35yKf3d5uTnHBVPeuSh9Vu35IJaCNYT50NKMa26ijs0=;
 b=HeKBuLv2T48qDcBrCKpmOwBTWTOh0EbClCBrvVaeW4E74KCxJaY68smX9a+6VPONK7zxPInckUYILnAieH8c9wL3a6QatUz11NKUh2EYe4Q1KjHUcLpKb3qgnjhBoBYwSmVNaBJWpeSDKsjDcCKcM1tHpq8XJGFfp2Oi/yWax+PJySj5nzokYo4h55NWXc7JG+KkL9+9vLx28WWHB4lqLVrWRkyhrIeosUsIWbqK3MBUQXpw+JGkHPPXymoxZI1nBpRap8Fve5dHvFMBdpyoZfPhSEANWzbC71x5862C4W2rWwqQL/XdlRlJQ2chvg8/nnbKXUYcxjIwH55qzxcJSQ==
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=35yKf3d5uTnHBVPeuSh9Vu35IJaCNYT50NKMa26ijs0=;
 b=XdEU2RZBaHDlOvEZQMALMuadRrMHetqlkQLFFzK+RDe7PQMtNXUu1A9KoirFrWNsitEiKca7bH8er3eIEyZOPTivrNFpl5lBcIxxRQLpzm0hKGOzS4+/Na+QhU+5z021IYOJLiSKfiub/HmLR0WiRuW8mLcJ5iFH65UTR+E7UhY=
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
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , "Julien
 Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Stefano Stabellini 
Subject: [PATCH v5 15/18] xen/sysctl: make CONFIG_COVERAGE depend on CONFIG_SYSCTL
Date: Mon, 16 Jun 2025 14:41:25 +0800
Message-ID: <20250616064128.581164-16-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250616064128.581164-1-Penny.Zheng@amd.com>
References: <20250616064128.581164-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: CY4PEPF0000EE38:EE_|SN7PR12MB7881:EE_
X-MS-Office365-Filtering-Correlation-Id: bbcc1672-6056-4d90-6681-08ddaca0fb27
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?uIeqRogR0GTLM99ELaLhwSw0Lng3zbltsyQPx4c0PHKDOM5ver6YNTRfD12r?=
 =?us-ascii?Q?NMYb/dRUatiwZhFlbwmeciPmORB7vhIeRE+eytN9oecDSMRcUhoSBKB+g7NW?=
 =?us-ascii?Q?eReNxzouff4KuJ1ATUiDCXFv7nqbf5/N9GiyfI4fRtWdKDf27tCEZgE3Yq+x?=
 =?us-ascii?Q?5KwbqDlNX/bhzpeh56p0LweemkS05kaK3/YJQ8qhtmvOiuuFhp4QKf7vgels?=
 =?us-ascii?Q?/EW69ud24KbvunNp0wwFMmEjE4pKiQUwldsBZmzJ28pz2Vabx1U3NsqPlRie?=
 =?us-ascii?Q?SWemtC93VZKa9EN4fF/vnrDzjpO1P64RURJxieLYX2Of6EFuKz88igKiZNr0?=
 =?us-ascii?Q?c4lDlYSJsP99KandwA0ZaLZG092IJ2xGV9xZu6+8XCdRgb0BPn1QS/QS3xi+?=
 =?us-ascii?Q?bMPZbq6o9kE/MwL2rrfgNCFRe+NpwzgIzLfDoFoPNvcIOTUmaUMA2wx9r9Ia?=
 =?us-ascii?Q?xmGACkGKcBVAbImtDdZDF1nt+Vx32ULSncxAKbLWGwmE7RrM+1Hc7vYwVmDQ?=
 =?us-ascii?Q?/p+m0947+YCbWwMFDeaF6LCQJ1ZkfrtujbWKNoGGskJ6UEahBgyKWybUYeze?=
 =?us-ascii?Q?mLu8ZTe6N1LKhhzGdnfpd/NwwKUmKOLgofWptxSeOXF+g+d2Y5T/Ont+A9kG?=
 =?us-ascii?Q?xJsaLlgoCQ4p5pithDhzmPgEdqxs17cMCFPVvbHsiBZ27i4MEGZcw9+JoCWl?=
 =?us-ascii?Q?b2xukKXLRzKNpmfVKsK1JhM+TEbLpEIkKDOnjN9R9c/ipZZcyg1D04NWWM6o?=
 =?us-ascii?Q?S5WJ9ZTgCa2oaHg83GK4qs1x7wVeBxm0bPOCT5yJAScHlzGYjn28GRbWldqG?=
 =?us-ascii?Q?Wa8d4fnfceDAv++kzMJDqqKN8+OurEnfS+wHj2FxuDRWmDQZaO/zYxbULsTz?=
 =?us-ascii?Q?Ywf1Ad1NAdFPmlxRbenvz26zA9XZntghI+l9VWgPnhzdXMoNjhCkCz7YBnSs?=
 =?us-ascii?Q?RjIbRnTx7PZNckvCJSdlzx5IyVOHIaKG+TjRX/ZD4zf+KljS19KC0ShjyxB0?=
 =?us-ascii?Q?12MROFfVDXdTgxp4DjbVgw7ZQJ93acb1uV7TT8tnYJ5wG6hLyBXKe53PpPkB?=
 =?us-ascii?Q?u6zX5UjuvyuUrG0tsk0DOcT0Y3vf7k8jIO2CO1kr6xVAtuf6WT7pTw67tfZI?=
 =?us-ascii?Q?MNp7VQwEx9wZXZn+pKnVtsCG3zXGe3VfnKIuZUY1cvYOrV34Ymu0YutRc1cU?=
 =?us-ascii?Q?b6WW5YxutO0tF6j2rZt+p4945Swu27wKVFRkktk/wZ8MK16ZEWifbJd0W91u?=
 =?us-ascii?Q?06ZuQNh7nhXwbqG9nAT0XXTUAB9g/Ujsz2xoQMGFX1Psg/MJrVFTGOiIkLut?=
 =?us-ascii?Q?l6Q7V+giF4JjqO4pX1/sA0dMJOlobj7lJNzgN75b4St56cnjVQFnywXv37dl?=
 =?us-ascii?Q?0vfz0z7Ca11rkZ+JdTN83FVia5eKGp4/kRDyff5P1w5G0Gn/eYI6KrcZPtYW?=
 =?us-ascii?Q?nmYHiJRkZri9BhRibgL3TLbcYt0ad2bem+BNNhfsfW62GuY0AsU8isgIjLHO?=
 =?us-ascii?Q?FaEI5Avlgd2xLmpC9jiTqkp4l/Sluv9CTQwM?=
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: 16 Jun 2025 06:42:36.3873
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: bbcc1672-6056-4d90-6681-08ddaca0fb27
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:
	CY4PEPF0000EE38.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7881

Users rely on SYSCTL_coverage_op hypercall to interact with the coverage data,
that is, according operations shall be wrapped around with CONFIG_SYSCTL.
Right now, it is compiled under CONFIG_COVERAGE, so we shall make
CONFIG_COVERAGE depend on CONFIG_SYSCTL.

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
---
v1 -> v2:
- commit message refactor
---
v3 -> v4:
- commit message refactor
---
v4 -> v5:
- commit message refactor
- switch the dependency order of "!LIVEPATCH" and "SYSCTL"
---
 xen/Kconfig.debug | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index d14093017e..38a134fa3b 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -37,7 +37,7 @@ config SELF_TESTS
 
 config COVERAGE
 	bool "Code coverage support"
-	depends on !LIVEPATCH
+	depends on SYSCTL && !LIVEPATCH
 	select SUPPRESS_DUPLICATE_SYMBOL_WARNINGS if !ENFORCE_UNIQUE_SYMBOLS
 	help
 	  Enable code coverage support.
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 06:51:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 06:51:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016590.1393516 (Exim 4.92)
	(envelope-from )
	id 1uR3gV-0007I2-Qi; Mon, 16 Jun 2025 06:51:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016590.1393516; Mon, 16 Jun 2025 06:51: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 1uR3gV-0007Hv-Ne; Mon, 16 Jun 2025 06:51:11 +0000
Received: by outflank-mailman (input) for mailman id 1016590;
 Mon, 16 Jun 2025 06:51: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 1uR3Y6-0008AT-GY
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 06:42:30 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20619.outbound.protection.outlook.com
 [2a01:111:f403:2417::619])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1069ea10-4a7d-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 08:42:26 +0200 (CEST)
Received: from DM6PR07CA0132.namprd07.prod.outlook.com (2603:10b6:5:330::25)
 by CH1PR12MB9600.namprd12.prod.outlook.com (2603:10b6:610:2ae::19) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Mon, 16 Jun
 2025 06:42:20 +0000
Received: from CY4PEPF0000EE3E.namprd03.prod.outlook.com
 (2603:10b6:5:330:cafe::be) by DM6PR07CA0132.outlook.office365.com
 (2603:10b6:5:330::25) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.23 via Frontend Transport; Mon,
 16 Jun 2025 06:42:20 +0000
Received: from SATLEXMB04.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.8835.15 via Frontend Transport; Mon, 16 Jun 2025 06:42: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; Mon, 16 Jun 2025 01:42:16 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1069ea10-4a7d-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=LPy+lMoajQQ5TkCQBGmIlNLaWNW09M8kbPjMoZZeeOffLMOUkhFOfi7UManYkIvqRCDrmRUpPSXPdr9xXg0wun+/KxyGerv5JwSXqGQxeawGWGoqMQ023qRa/xX80Iu1W/xF/Diz52Wu5Ct3nadNMps4qK/6a7z/FC7TMY9g0Pm30TefBqbWCTL+DrQRoutlmluwC7fPk/n7ta04VuZYaAHrAugqQHMMJqXV1aj/0z8Er5op/Grbr+EZjzK/Hm+Mv7U+LGYZu5+8EWMyXEdUgEC8gmlVgmQRzW53mIEqwOEhyO6ZEfI+EdFeIPKk5T7aUHPRpEKxzeU9MEI9gTiNFA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=W/nt6RoVAESwN8jaFZZLseGmNdLFdNJ/ZgXjpAnK/Xg=;
 b=rjj7rojOaUhJEuIaCCSsBKaJUdMMtmFQkemhUfvvofjdXzo04Klb7e0g6k+qTrrRpHeyRyPSXe4fxY3+DnRdHaMKXhy5mb46ZxZvjEqWh555pdRqwlv9m2ffK/RAUV8CjfmDbN4wznwpyUjXZ5+QCowA+SmQlSKXqEBpRjhmNKbADTrb8uawfTYTkTEHSYEdz96T05H9WERde6oLCUtY4aLH1XLId2qrmQN/0yDidD+w1Sb0R7WuerUeepq6/KtcTaGe5wl5TQQE0wS3vQNQyQ6wWe50fZD3DoPxUJz49qx4CeqL/CVY14eB9TctUBJeS0EtXnis7Qar9M5a5+/n2g==
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=W/nt6RoVAESwN8jaFZZLseGmNdLFdNJ/ZgXjpAnK/Xg=;
 b=tJW2ibmf4BhnEV4VwClD9Rngfyj3M82/TxGsm8Cx1cfPcJd2l5U/LcqZIKOqtXVJHzejv8XnIvW4fuZgQ4v4NzhTnon7Cc31axRrOEWy6RudcOJXamQfyYKM2mzwS4rAPvoTCFDce1+Z+6il1Tm6OcLJYolNC6uj/96DlGcVqjU=
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?= , Anthony PERARD
	, Michal Orzel , "Julien
 Grall" , Stefano Stabellini 
Subject: [PATCH v5 09/18] xen/pmstat: introduce CONFIG_PM_OP
Date: Mon, 16 Jun 2025 14:41:19 +0800
Message-ID: <20250616064128.581164-10-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250616064128.581164-1-Penny.Zheng@amd.com>
References: <20250616064128.581164-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: CY4PEPF0000EE3E:EE_|CH1PR12MB9600:EE_
X-MS-Office365-Filtering-Correlation-Id: 9c40f1ba-5bf9-4c91-4c4b-08ddaca0f11e
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?g4+IRUjk1YEie23VUlPq0xTw0glnPGbK4HviEBdj4XScRw11tLWhmnoqVqPU?=
 =?us-ascii?Q?cBt5rhxxfmvCeOCvsRfWouRpwDZS4Ptp4cI+n/N6CBtqvl3lqB0OABgsPqNn?=
 =?us-ascii?Q?mrac7dQZRsnMMNkG58T4+3lcbMVTBb/6wNSRgJC4lE1VF7GnGiPBadVaEl+i?=
 =?us-ascii?Q?XSAbiksYJrGqmvbsYGfSBkVT2/xabvT5kc44W4WxXgmQb759sV9WLgDCAHPA?=
 =?us-ascii?Q?vGEb2nao0EghWtM/C5Vg1itMVY8mV2rQvOOcoclUHMomSVBArKBj39jiwYa2?=
 =?us-ascii?Q?ERbBImor1wxm2Cpb/rACJ8GcHtq2nfXUx5pwYABTLlQl8XTQeOKTLQd+NvtN?=
 =?us-ascii?Q?7FlN7iFJZha1t2AskAul/EbkjbtJbWNA99FMoUx3Vae+I6p7PUk7RIFXdWIM?=
 =?us-ascii?Q?4XI2pxS3pn3z+f8X4mJVBWPXmg3/N3gfXyYrrvYakUTATfyi3oRB1m4DGa/q?=
 =?us-ascii?Q?4w3Ot9YBLtIfeqa4b+d4SYrnnPs6Olb06fI90MaO7czhD4ZQEggx2UhJ5K1s?=
 =?us-ascii?Q?8TPM6/l7xHP+RRT2db0KMyb2qW8gSkjtH8C5GJJgPhGsgP42wiHgn/n4JTOh?=
 =?us-ascii?Q?ukk9AqcD1fWx3I63CPD3M6vdJQVN5kM+mygPn1TeALMc39D5COyCmob0iBEE?=
 =?us-ascii?Q?pd4w0iXtJQ5+Uc1gt2r5zGdiaO2ld7C1QaYBOLLlrVHzqyop1AWSfaq5r+sy?=
 =?us-ascii?Q?fvmnsBVFAPqPAmzE5qrPbAns+gx4IouStoRsp3TCN2VNoBxrqHCKXR9kaJR9?=
 =?us-ascii?Q?uxKqYIjWgTL6h8YkUuURR81VASdxBprrR6rSdJF686xIOp0Vxd8uruzeEDhs?=
 =?us-ascii?Q?3E5y3ZdlaBPYvjAek4I3NAC4g0F6tzHyglPta2BIw4uNGZIoRXjb1cGxlXmE?=
 =?us-ascii?Q?5HlKfIDG15RiwFArfkQuYddK1MsJerOyK8Fdcu6jMrcz9icHc8gNTbtyfkXi?=
 =?us-ascii?Q?xLwiBgciUSsp9igMImiZaVgvK+Y6UwjnMM79XNpA1y+OeETEqamKEPQSZOyv?=
 =?us-ascii?Q?Ce6Wk0r28Ob60Gkmerorn/COcHvd8JPX01ctQjQVAyGdTdE16Wl55EjVQzAF?=
 =?us-ascii?Q?ZRp2h7QZFiVRrRqA/zoVszebUWCHgemhzeOen8KHOU8BK6aMxqqWbtY42LSE?=
 =?us-ascii?Q?IJm7QtGBecQLlSFnn0J/Ws8VhcPg/g3BazVfIXJd0xdEZc7eQWpz8I6hXBKX?=
 =?us-ascii?Q?EJdFtuonAtjB3WJ5ctIS3c+9Pi89GB6c0zM7d/p1MOQRKMAlM8nHJjTmjODK?=
 =?us-ascii?Q?GmslVBHJ07atAzBt0VLUlel/YX0A6sndoS/JC19qBCDqtYfztcs13ANNdDEl?=
 =?us-ascii?Q?LODcCUPYNMWCB/h1RIKlOXfpkv9pZ88RDtPy4YdRGAiJ+oiUA15PBxriGiap?=
 =?us-ascii?Q?gVjqTwqsQrguUODrmmxwDNji1GKgCafS8jAJkLm/jO0/bzmeWpbbEMN4pCEU?=
 =?us-ascii?Q?YqL4OJYYYfsFFm3XbaZ8Zk53xLv3bvJYPaa1HLoKsSPJDV7krOdjaX1ZZu6Z?=
 =?us-ascii?Q?stADK5g3C10R7K6YHpIIaIJO9AaVWdbI6vy+?=
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 Jun 2025 06:42:19.5475
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9c40f1ba-5bf9-4c91-4c4b-08ddaca0f11e
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:
	CY4PEPF0000EE3E.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH1PR12MB9600

We move the following functions into a new file drivers/acpi/pm-op.c, as
they are all more fitting in performance controling and only called by
do_pm_op():
 - get_cpufreq_para()
 - set_cpufreq_para()
 - set_cpufreq_gov()
 - set_cpufreq_cppc()
 - cpufreq_driver_getavg()
 - cpufreq_update_turbo()
 - cpufreq_get_turbo_status()
We introduce a new Kconfig CONFIG_PM_OP to wrap the new file.

Also, although the following helpers are only called by do_pm_op(), they have
dependency on local variable, we wrap them with CONFIG_PM_OP in place:
 - write_userspace_scaling_setspeed()
 - write_ondemand_sampling_rate()
 - write_ondemand_up_threshold()
 - get_cpufreq_ondemand_para()
 - cpufreq_driver.update()
 - get_hwp_para()
Various style corrections shall be applied at the same time while moving these
functions, including:
 - add extra space before and after bracket of if() and switch()
 - fix indentation
 - drop all the unnecessary inner figure braces

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
Acked-by: Jan Beulich 
---
v2 -> v3
- new commit
---
v3 -> v4:
- rename the file to pm-op.c
- drop all the unnecessary inner figure braces
- be consistent with the comment on the #endif
---
v4 -> v5:
- add blank line before endmenu
---
 xen/arch/x86/acpi/cpufreq/hwp.c              |   6 +
 xen/arch/x86/acpi/cpufreq/powernow.c         |   4 +
 xen/common/Kconfig                           |   8 +
 xen/common/sysctl.c                          |   2 +
 xen/drivers/acpi/Makefile                    |   1 +
 xen/drivers/acpi/pm-op.c                     | 397 +++++++++++++++++++
 xen/drivers/acpi/pmstat.c                    | 357 -----------------
 xen/drivers/cpufreq/cpufreq_misc_governors.c |   2 +
 xen/drivers/cpufreq/cpufreq_ondemand.c       |   2 +
 xen/drivers/cpufreq/utility.c                |  41 --
 xen/include/acpi/cpufreq/cpufreq.h           |   3 -
 11 files changed, 422 insertions(+), 401 deletions(-)
 create mode 100644 xen/drivers/acpi/pm-op.c

diff --git a/xen/arch/x86/acpi/cpufreq/hwp.c b/xen/arch/x86/acpi/cpufreq/hwp.c
index d5fa3d47ca..e4c09244ab 100644
--- a/xen/arch/x86/acpi/cpufreq/hwp.c
+++ b/xen/arch/x86/acpi/cpufreq/hwp.c
@@ -466,6 +466,7 @@ static int cf_check hwp_cpufreq_cpu_exit(struct cpufreq_policy *policy)
     return 0;
 }
 
+#ifdef CONFIG_PM_OP
 /*
  * The SDM reads like turbo should be disabled with MSR_IA32_PERF_CTL and
  * PERF_CTL_TURBO_DISENGAGE, but that does not seem to actually work, at least
@@ -508,6 +509,7 @@ static int cf_check hwp_cpufreq_update(unsigned int cpu, struct cpufreq_policy *
 
     return per_cpu(hwp_drv_data, cpu)->ret;
 }
+#endif /* CONFIG_PM_OP */
 
 static const struct cpufreq_driver __initconst_cf_clobber
 hwp_cpufreq_driver = {
@@ -516,9 +518,12 @@ hwp_cpufreq_driver = {
     .target = hwp_cpufreq_target,
     .init   = hwp_cpufreq_cpu_init,
     .exit   = hwp_cpufreq_cpu_exit,
+#ifdef CONFIG_PM_OP
     .update = hwp_cpufreq_update,
+#endif
 };
 
+#ifdef CONFIG_PM_OP
 int get_hwp_para(unsigned int cpu,
                  struct xen_cppc_para *cppc_para)
 {
@@ -639,6 +644,7 @@ int set_hwp_para(struct cpufreq_policy *policy,
 
     return hwp_cpufreq_target(policy, 0, 0);
 }
+#endif /* CONFIG_PM_OP */
 
 int __init hwp_register_driver(void)
 {
diff --git a/xen/arch/x86/acpi/cpufreq/powernow.c b/xen/arch/x86/acpi/cpufreq/powernow.c
index 69364e1855..12fca45b45 100644
--- a/xen/arch/x86/acpi/cpufreq/powernow.c
+++ b/xen/arch/x86/acpi/cpufreq/powernow.c
@@ -49,6 +49,7 @@ static void cf_check transition_pstate(void *pstate)
     wrmsrl(MSR_PSTATE_CTRL, *(unsigned int *)pstate);
 }
 
+#ifdef CONFIG_PM_OP
 static void cf_check update_cpb(void *data)
 {
     struct cpufreq_policy *policy = data;
@@ -77,6 +78,7 @@ static int cf_check powernow_cpufreq_update(
 
     return 0;
 }
+#endif /* CONFIG_PM_OP */
 
 static int cf_check powernow_cpufreq_target(
     struct cpufreq_policy *policy,
@@ -324,7 +326,9 @@ powernow_cpufreq_driver = {
     .target = powernow_cpufreq_target,
     .init   = powernow_cpufreq_cpu_init,
     .exit   = powernow_cpufreq_cpu_exit,
+#ifdef CONFIG_PM_OP
     .update = powernow_cpufreq_update
+#endif
 };
 
 unsigned int __init powernow_register_driver(void)
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index dbd9747d1f..943cf0a950 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -620,4 +620,12 @@ config SYSCTL
 
 endmenu
 
+config PM_OP
+	bool "Enable Performance Management Operation"
+	depends on ACPI && HAS_CPUFREQ && SYSCTL
+	default y
+	help
+	  This option shall enable userspace performance management control
+	  to do power/performance analyzing and tuning.
+
 endmenu
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index c2d99ae12e..daf57fbe56 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -174,7 +174,9 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
     case XEN_SYSCTL_get_pmstat:
         ret = do_get_pm_info(&op->u.get_pmstat);
         break;
+#endif
 
+#ifdef CONFIG_PM_OP
     case XEN_SYSCTL_pm_op:
         ret = do_pm_op(&op->u.pm_op);
         if ( ret == -EAGAIN )
diff --git a/xen/drivers/acpi/Makefile b/xen/drivers/acpi/Makefile
index 2fc5230253..1d811a51a7 100644
--- a/xen/drivers/acpi/Makefile
+++ b/xen/drivers/acpi/Makefile
@@ -6,6 +6,7 @@ obj-bin-y += tables.init.o
 obj-$(CONFIG_ACPI_NUMA) += numa.o
 obj-y += osl.o
 obj-$(CONFIG_HAS_CPUFREQ) += pmstat.o
+obj-$(CONFIG_PM_OP) += pm-op.o
 
 obj-$(CONFIG_X86) += hwregs.o
 obj-$(CONFIG_X86) += reboot.o
diff --git a/xen/drivers/acpi/pm-op.c b/xen/drivers/acpi/pm-op.c
new file mode 100644
index 0000000000..b6c590967e
--- /dev/null
+++ b/xen/drivers/acpi/pm-op.c
@@ -0,0 +1,397 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+/*
+ * 1. Get PM parameter
+ * 2. Provide user PM control
+ */
+static int cpufreq_update_turbo(unsigned int cpu, int new_state)
+{
+    struct cpufreq_policy *policy;
+    int curr_state;
+    int ret = 0;
+
+    if ( new_state != CPUFREQ_TURBO_ENABLED &&
+         new_state != CPUFREQ_TURBO_DISABLED )
+        return -EINVAL;
+
+    policy = per_cpu(cpufreq_cpu_policy, cpu);
+    if ( !policy )
+        return -EACCES;
+
+    if ( policy->turbo == CPUFREQ_TURBO_UNSUPPORTED )
+        return -EOPNOTSUPP;
+
+    curr_state = policy->turbo;
+    if ( curr_state == new_state )
+        return 0;
+
+    policy->turbo = new_state;
+    if ( cpufreq_driver.update )
+    {
+        ret = alternative_call(cpufreq_driver.update, cpu, policy);
+        if ( ret )
+            policy->turbo = curr_state;
+    }
+
+    return ret;
+}
+
+static int cpufreq_get_turbo_status(unsigned int cpu)
+{
+    struct cpufreq_policy *policy;
+
+    policy = per_cpu(cpufreq_cpu_policy, cpu);
+    return policy && policy->turbo == CPUFREQ_TURBO_ENABLED;
+}
+
+static int read_scaling_available_governors(char *scaling_available_governors,
+                                            unsigned int size)
+{
+    unsigned int i = 0;
+    struct cpufreq_governor *t;
+
+    if ( !scaling_available_governors )
+        return -EINVAL;
+
+    list_for_each_entry(t, &cpufreq_governor_list, governor_list)
+    {
+        i += scnprintf(&scaling_available_governors[i],
+                       CPUFREQ_NAME_LEN, "%s ", t->name);
+        if ( i > size )
+            return -EINVAL;
+    }
+    scaling_available_governors[i-1] = '\0';
+
+    return 0;
+}
+
+static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
+{
+    uint32_t ret = 0;
+    const struct processor_pminfo *pmpt;
+    struct cpufreq_policy *policy;
+    uint32_t gov_num = 0;
+    uint32_t *data;
+    char     *scaling_available_governors;
+    struct list_head *pos;
+    unsigned int cpu, i = 0;
+
+    pmpt = processor_pminfo[op->cpuid];
+    policy = per_cpu(cpufreq_cpu_policy, op->cpuid);
+
+    if ( !pmpt || !pmpt->perf.states ||
+         !policy || !policy->governor )
+        return -EINVAL;
+
+    list_for_each(pos, &cpufreq_governor_list)
+        gov_num++;
+
+    if ( (op->u.get_para.cpu_num  != cpumask_weight(policy->cpus)) ||
+         (op->u.get_para.freq_num != pmpt->perf.state_count)    ||
+         (op->u.get_para.gov_num  != gov_num) )
+    {
+        op->u.get_para.cpu_num =  cpumask_weight(policy->cpus);
+        op->u.get_para.freq_num = pmpt->perf.state_count;
+        op->u.get_para.gov_num  = gov_num;
+        return -EAGAIN;
+    }
+
+    if ( !(data = xzalloc_array(uint32_t,
+                                max(op->u.get_para.cpu_num,
+                                    op->u.get_para.freq_num))) )
+        return -ENOMEM;
+
+    for_each_cpu(cpu, policy->cpus)
+        data[i++] = cpu;
+    ret = copy_to_guest(op->u.get_para.affected_cpus,
+                        data, op->u.get_para.cpu_num);
+
+    for ( i = 0; i < op->u.get_para.freq_num; i++ )
+        data[i] = pmpt->perf.states[i].core_frequency * 1000;
+    ret += copy_to_guest(op->u.get_para.scaling_available_frequencies,
+                         data, op->u.get_para.freq_num);
+
+    xfree(data);
+    if ( ret )
+        return -EFAULT;
+
+    op->u.get_para.cpuinfo_cur_freq =
+        cpufreq_driver.get ? alternative_call(cpufreq_driver.get, op->cpuid)
+                           : policy->cur;
+    op->u.get_para.cpuinfo_max_freq = policy->cpuinfo.max_freq;
+    op->u.get_para.cpuinfo_min_freq = policy->cpuinfo.min_freq;
+    op->u.get_para.turbo_enabled = cpufreq_get_turbo_status(op->cpuid);
+
+    if ( cpufreq_driver.name[0] )
+        strlcpy(op->u.get_para.scaling_driver,
+                cpufreq_driver.name, CPUFREQ_NAME_LEN);
+    else
+        strlcpy(op->u.get_para.scaling_driver, "Unknown", CPUFREQ_NAME_LEN);
+
+    if ( IS_ENABLED(CONFIG_INTEL) &&
+         !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
+    {
+        if ( !(scaling_available_governors =
+               xzalloc_array(char, gov_num * CPUFREQ_NAME_LEN)) )
+            return -ENOMEM;
+        if ( (ret = read_scaling_available_governors(
+                        scaling_available_governors,
+                        (gov_num * CPUFREQ_NAME_LEN *
+                         sizeof(*scaling_available_governors)))) )
+        {
+            xfree(scaling_available_governors);
+            return ret;
+        }
+        ret = copy_to_guest(op->u.get_para.scaling_available_governors,
+                            scaling_available_governors,
+                            gov_num * CPUFREQ_NAME_LEN);
+        xfree(scaling_available_governors);
+        if ( ret )
+            return -EFAULT;
+
+        op->u.get_para.u.s.scaling_cur_freq = policy->cur;
+        op->u.get_para.u.s.scaling_max_freq = policy->max;
+        op->u.get_para.u.s.scaling_min_freq = policy->min;
+
+        if ( policy->governor->name[0] )
+            strlcpy(op->u.get_para.u.s.scaling_governor,
+                    policy->governor->name, CPUFREQ_NAME_LEN);
+        else
+            strlcpy(op->u.get_para.u.s.scaling_governor, "Unknown",
+                    CPUFREQ_NAME_LEN);
+
+        /* governor specific para */
+        if ( !strncasecmp(op->u.get_para.u.s.scaling_governor,
+                          "userspace", CPUFREQ_NAME_LEN) )
+            op->u.get_para.u.s.u.userspace.scaling_setspeed = policy->cur;
+
+        if ( !strncasecmp(op->u.get_para.u.s.scaling_governor,
+                          "ondemand", CPUFREQ_NAME_LEN) )
+            ret = get_cpufreq_ondemand_para(
+                &op->u.get_para.u.s.u.ondemand.sampling_rate_max,
+                &op->u.get_para.u.s.u.ondemand.sampling_rate_min,
+                &op->u.get_para.u.s.u.ondemand.sampling_rate,
+                &op->u.get_para.u.s.u.ondemand.up_threshold);
+    }
+
+    return ret;
+}
+
+static int set_cpufreq_gov(struct xen_sysctl_pm_op *op)
+{
+    struct cpufreq_policy new_policy, *old_policy;
+
+    old_policy = per_cpu(cpufreq_cpu_policy, op->cpuid);
+    if ( !old_policy )
+        return -EINVAL;
+
+    memcpy(&new_policy, old_policy, sizeof(struct cpufreq_policy));
+
+    new_policy.governor = __find_governor(op->u.set_gov.scaling_governor);
+    if ( new_policy.governor == NULL )
+        return -EINVAL;
+
+    return __cpufreq_set_policy(old_policy, &new_policy);
+}
+
+static int set_cpufreq_para(struct xen_sysctl_pm_op *op)
+{
+    int ret = 0;
+    struct cpufreq_policy *policy;
+
+    policy = per_cpu(cpufreq_cpu_policy, op->cpuid);
+
+    if ( !policy || !policy->governor )
+        return -EINVAL;
+
+    if ( hwp_active() )
+        return -EOPNOTSUPP;
+
+    switch( op->u.set_para.ctrl_type )
+    {
+    case SCALING_MAX_FREQ:
+    {
+        struct cpufreq_policy new_policy;
+
+        memcpy(&new_policy, policy, sizeof(struct cpufreq_policy));
+        new_policy.max = op->u.set_para.ctrl_value;
+        ret = __cpufreq_set_policy(policy, &new_policy);
+
+        break;
+    }
+
+    case SCALING_MIN_FREQ:
+    {
+        struct cpufreq_policy new_policy;
+
+        memcpy(&new_policy, policy, sizeof(struct cpufreq_policy));
+        new_policy.min = op->u.set_para.ctrl_value;
+        ret = __cpufreq_set_policy(policy, &new_policy);
+
+        break;
+    }
+
+    case SCALING_SETSPEED:
+    {
+        unsigned int freq =op->u.set_para.ctrl_value;
+
+        if ( !strncasecmp(policy->governor->name,
+                          "userspace", CPUFREQ_NAME_LEN) )
+            ret = write_userspace_scaling_setspeed(op->cpuid, freq);
+        else
+            ret = -EINVAL;
+
+        break;
+    }
+
+    case SAMPLING_RATE:
+    {
+        unsigned int sampling_rate = op->u.set_para.ctrl_value;
+
+        if ( !strncasecmp(policy->governor->name,
+                          "ondemand", CPUFREQ_NAME_LEN) )
+            ret = write_ondemand_sampling_rate(sampling_rate);
+        else
+            ret = -EINVAL;
+
+        break;
+    }
+
+    case UP_THRESHOLD:
+    {
+        unsigned int up_threshold = op->u.set_para.ctrl_value;
+
+        if ( !strncasecmp(policy->governor->name,
+                          "ondemand", CPUFREQ_NAME_LEN) )
+            ret = write_ondemand_up_threshold(up_threshold);
+        else
+            ret = -EINVAL;
+
+        break;
+    }
+
+    default:
+        ret = -EINVAL;
+        break;
+    }
+
+    return ret;
+}
+
+static int set_cpufreq_cppc(struct xen_sysctl_pm_op *op)
+{
+    struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_policy, op->cpuid);
+
+    if ( !policy || !policy->governor )
+        return -ENOENT;
+
+    if ( !hwp_active() )
+        return -EOPNOTSUPP;
+
+    return set_hwp_para(policy, &op->u.set_cppc);
+}
+
+int do_pm_op(struct xen_sysctl_pm_op *op)
+{
+    int ret = 0;
+    const struct processor_pminfo *pmpt;
+
+    switch ( op->cmd )
+    {
+    case XEN_SYSCTL_pm_op_set_sched_opt_smt:
+    {
+        uint32_t saved_value = sched_smt_power_savings;
+
+        if ( op->cpuid != 0 )
+            return -EINVAL;
+        sched_smt_power_savings = !!op->u.set_sched_opt_smt;
+        op->u.set_sched_opt_smt = saved_value;
+        return 0;
+    }
+
+    case XEN_SYSCTL_pm_op_get_max_cstate:
+        BUILD_BUG_ON(XEN_SYSCTL_CX_UNLIMITED != UINT_MAX);
+        if ( op->cpuid == 0 )
+            op->u.get_max_cstate = acpi_get_cstate_limit();
+        else if ( op->cpuid == 1 )
+            op->u.get_max_cstate = acpi_get_csubstate_limit();
+        else
+            ret = -EINVAL;
+        return ret;
+
+    case XEN_SYSCTL_pm_op_set_max_cstate:
+        if ( op->cpuid == 0 )
+            acpi_set_cstate_limit(op->u.set_max_cstate);
+        else if ( op->cpuid == 1 )
+            acpi_set_csubstate_limit(op->u.set_max_cstate);
+        else
+            ret = -EINVAL;
+        return ret;
+    }
+
+    if ( op->cpuid >= nr_cpu_ids || !cpu_online(op->cpuid) )
+        return -EINVAL;
+    pmpt = processor_pminfo[op->cpuid];
+
+    switch ( op->cmd & PM_PARA_CATEGORY_MASK )
+    {
+    case CPUFREQ_PARA:
+        if ( !(xen_processor_pmbits & XEN_PROCESSOR_PM_PX) )
+            return -ENODEV;
+        if ( !pmpt || !(pmpt->perf.init & XEN_PX_INIT) )
+            return -EINVAL;
+        break;
+    }
+
+    switch ( op->cmd )
+    {
+    case GET_CPUFREQ_PARA:
+        ret = get_cpufreq_para(op);
+        break;
+
+    case SET_CPUFREQ_GOV:
+        ret = set_cpufreq_gov(op);
+        break;
+
+    case SET_CPUFREQ_PARA:
+        ret = set_cpufreq_para(op);
+        break;
+
+    case SET_CPUFREQ_CPPC:
+        ret = set_cpufreq_cppc(op);
+        break;
+
+    case GET_CPUFREQ_AVGFREQ:
+        op->u.get_avgfreq = cpufreq_driver_getavg(op->cpuid, USR_GETAVG);
+        break;
+
+    case XEN_SYSCTL_pm_op_enable_turbo:
+        ret = cpufreq_update_turbo(op->cpuid, CPUFREQ_TURBO_ENABLED);
+        break;
+
+    case XEN_SYSCTL_pm_op_disable_turbo:
+        ret = cpufreq_update_turbo(op->cpuid, CPUFREQ_TURBO_DISABLED);
+        break;
+
+    default:
+        printk("not defined sub-hypercall @ do_pm_op\n");
+        ret = -ENOSYS;
+        break;
+    }
+
+    return ret;
+}
diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/acpi/pmstat.c
index 521db7e98e..6c563a53e2 100644
--- a/xen/drivers/acpi/pmstat.c
+++ b/xen/drivers/acpi/pmstat.c
@@ -333,360 +333,3 @@ int do_get_pm_info(struct xen_sysctl_get_pmstat *op)
 
     return ret;
 }
-
-/*
- * 1. Get PM parameter
- * 2. Provide user PM control
- */
-static int read_scaling_available_governors(char *scaling_available_governors,
-                                            unsigned int size)
-{
-    unsigned int i = 0;
-    struct cpufreq_governor *t;
-
-    if ( !scaling_available_governors )
-        return -EINVAL;
-
-    list_for_each_entry(t, &cpufreq_governor_list, governor_list)
-    {
-        i += scnprintf(&scaling_available_governors[i],
-                       CPUFREQ_NAME_LEN, "%s ", t->name);
-        if ( i > size )
-            return -EINVAL;
-    }
-    scaling_available_governors[i-1] = '\0';
-
-    return 0;
-}
-
-static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
-{
-    uint32_t ret = 0;
-    const struct processor_pminfo *pmpt;
-    struct cpufreq_policy *policy;
-    uint32_t gov_num = 0;
-    uint32_t *data;
-    char     *scaling_available_governors;
-    struct list_head *pos;
-    unsigned int cpu, i = 0;
-
-    pmpt = processor_pminfo[op->cpuid];
-    policy = per_cpu(cpufreq_cpu_policy, op->cpuid);
-
-    if ( !pmpt || !pmpt->perf.states ||
-         !policy || !policy->governor )
-        return -EINVAL;
-
-    list_for_each(pos, &cpufreq_governor_list)
-        gov_num++;
-
-    if ( (op->u.get_para.cpu_num  != cpumask_weight(policy->cpus)) ||
-         (op->u.get_para.freq_num != pmpt->perf.state_count)    ||
-         (op->u.get_para.gov_num  != gov_num) )
-    {
-        op->u.get_para.cpu_num =  cpumask_weight(policy->cpus);
-        op->u.get_para.freq_num = pmpt->perf.state_count;
-        op->u.get_para.gov_num  = gov_num;
-        return -EAGAIN;
-    }
-
-    if ( !(data = xzalloc_array(uint32_t,
-                                max(op->u.get_para.cpu_num,
-                                    op->u.get_para.freq_num))) )
-        return -ENOMEM;
-
-    for_each_cpu(cpu, policy->cpus)
-        data[i++] = cpu;
-    ret = copy_to_guest(op->u.get_para.affected_cpus,
-                        data, op->u.get_para.cpu_num);
-
-    for ( i = 0; i < op->u.get_para.freq_num; i++ )
-        data[i] = pmpt->perf.states[i].core_frequency * 1000;
-    ret += copy_to_guest(op->u.get_para.scaling_available_frequencies,
-                         data, op->u.get_para.freq_num);
-
-    xfree(data);
-    if ( ret )
-        return -EFAULT;
-
-    op->u.get_para.cpuinfo_cur_freq =
-        cpufreq_driver.get ? alternative_call(cpufreq_driver.get, op->cpuid)
-                           : policy->cur;
-    op->u.get_para.cpuinfo_max_freq = policy->cpuinfo.max_freq;
-    op->u.get_para.cpuinfo_min_freq = policy->cpuinfo.min_freq;
-    op->u.get_para.turbo_enabled = cpufreq_get_turbo_status(op->cpuid);
-
-    if ( cpufreq_driver.name[0] )
-        strlcpy(op->u.get_para.scaling_driver,
-            cpufreq_driver.name, CPUFREQ_NAME_LEN);
-    else
-        strlcpy(op->u.get_para.scaling_driver, "Unknown", CPUFREQ_NAME_LEN);
-
-    if ( IS_ENABLED(CONFIG_INTEL) &&
-         !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
-    {
-        if ( !(scaling_available_governors =
-               xzalloc_array(char, gov_num * CPUFREQ_NAME_LEN)) )
-            return -ENOMEM;
-        if ( (ret = read_scaling_available_governors(
-                        scaling_available_governors,
-                        (gov_num * CPUFREQ_NAME_LEN *
-                         sizeof(*scaling_available_governors)))) )
-        {
-            xfree(scaling_available_governors);
-            return ret;
-        }
-        ret = copy_to_guest(op->u.get_para.scaling_available_governors,
-                            scaling_available_governors,
-                            gov_num * CPUFREQ_NAME_LEN);
-        xfree(scaling_available_governors);
-        if ( ret )
-            return -EFAULT;
-
-        op->u.get_para.u.s.scaling_cur_freq = policy->cur;
-        op->u.get_para.u.s.scaling_max_freq = policy->max;
-        op->u.get_para.u.s.scaling_min_freq = policy->min;
-
-        if ( policy->governor->name[0] )
-            strlcpy(op->u.get_para.u.s.scaling_governor,
-                policy->governor->name, CPUFREQ_NAME_LEN);
-        else
-            strlcpy(op->u.get_para.u.s.scaling_governor, "Unknown",
-                    CPUFREQ_NAME_LEN);
-
-        /* governor specific para */
-        if ( !strncasecmp(op->u.get_para.u.s.scaling_governor,
-                          "userspace", CPUFREQ_NAME_LEN) )
-            op->u.get_para.u.s.u.userspace.scaling_setspeed = policy->cur;
-
-        if ( !strncasecmp(op->u.get_para.u.s.scaling_governor,
-                          "ondemand", CPUFREQ_NAME_LEN) )
-            ret = get_cpufreq_ondemand_para(
-                &op->u.get_para.u.s.u.ondemand.sampling_rate_max,
-                &op->u.get_para.u.s.u.ondemand.sampling_rate_min,
-                &op->u.get_para.u.s.u.ondemand.sampling_rate,
-                &op->u.get_para.u.s.u.ondemand.up_threshold);
-    }
-
-    return ret;
-}
-
-static int set_cpufreq_gov(struct xen_sysctl_pm_op *op)
-{
-    struct cpufreq_policy new_policy, *old_policy;
-
-    old_policy = per_cpu(cpufreq_cpu_policy, op->cpuid);
-    if ( !old_policy )
-        return -EINVAL;
-
-    memcpy(&new_policy, old_policy, sizeof(struct cpufreq_policy));
-
-    new_policy.governor = __find_governor(op->u.set_gov.scaling_governor);
-    if (new_policy.governor == NULL)
-        return -EINVAL;
-
-    return __cpufreq_set_policy(old_policy, &new_policy);
-}
-
-static int set_cpufreq_para(struct xen_sysctl_pm_op *op)
-{
-    int ret = 0;
-    struct cpufreq_policy *policy;
-
-    policy = per_cpu(cpufreq_cpu_policy, op->cpuid);
-
-    if ( !policy || !policy->governor )
-        return -EINVAL;
-
-    if ( hwp_active() )
-        return -EOPNOTSUPP;
-
-    switch(op->u.set_para.ctrl_type)
-    {
-    case SCALING_MAX_FREQ:
-    {
-        struct cpufreq_policy new_policy;
-
-        memcpy(&new_policy, policy, sizeof(struct cpufreq_policy));
-        new_policy.max = op->u.set_para.ctrl_value;
-        ret = __cpufreq_set_policy(policy, &new_policy);
-
-        break;
-    }
-
-    case SCALING_MIN_FREQ:
-    {
-        struct cpufreq_policy new_policy;
-
-        memcpy(&new_policy, policy, sizeof(struct cpufreq_policy));
-        new_policy.min = op->u.set_para.ctrl_value;
-        ret = __cpufreq_set_policy(policy, &new_policy);
-
-        break;
-    }
-
-    case SCALING_SETSPEED:
-    {
-        unsigned int freq =op->u.set_para.ctrl_value;
-
-        if ( !strncasecmp(policy->governor->name,
-                          "userspace", CPUFREQ_NAME_LEN) )
-            ret = write_userspace_scaling_setspeed(op->cpuid, freq);
-        else
-            ret = -EINVAL;
-
-        break;
-    }
-
-    case SAMPLING_RATE:
-    {
-        unsigned int sampling_rate = op->u.set_para.ctrl_value;
-
-        if ( !strncasecmp(policy->governor->name,
-                          "ondemand", CPUFREQ_NAME_LEN) )
-            ret = write_ondemand_sampling_rate(sampling_rate);
-        else
-            ret = -EINVAL;
-
-        break;
-    }
-
-    case UP_THRESHOLD:
-    {
-        unsigned int up_threshold = op->u.set_para.ctrl_value;
-
-        if ( !strncasecmp(policy->governor->name,
-                          "ondemand", CPUFREQ_NAME_LEN) )
-            ret = write_ondemand_up_threshold(up_threshold);
-        else
-            ret = -EINVAL;
-
-        break;
-    }
-
-    default:
-        ret = -EINVAL;
-        break;
-    }
-
-    return ret;
-}
-
-static int set_cpufreq_cppc(struct xen_sysctl_pm_op *op)
-{
-    struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_policy, op->cpuid);
-
-    if ( !policy || !policy->governor )
-        return -ENOENT;
-
-    if ( !hwp_active() )
-        return -EOPNOTSUPP;
-
-    return set_hwp_para(policy, &op->u.set_cppc);
-}
-
-int do_pm_op(struct xen_sysctl_pm_op *op)
-{
-    int ret = 0;
-    const struct processor_pminfo *pmpt;
-
-    switch ( op->cmd )
-    {
-    case XEN_SYSCTL_pm_op_set_sched_opt_smt:
-    {
-        uint32_t saved_value = sched_smt_power_savings;
-
-        if ( op->cpuid != 0 )
-            return -EINVAL;
-        sched_smt_power_savings = !!op->u.set_sched_opt_smt;
-        op->u.set_sched_opt_smt = saved_value;
-        return 0;
-    }
-
-    case XEN_SYSCTL_pm_op_get_max_cstate:
-        BUILD_BUG_ON(XEN_SYSCTL_CX_UNLIMITED != UINT_MAX);
-        if ( op->cpuid == 0 )
-            op->u.get_max_cstate = acpi_get_cstate_limit();
-        else if ( op->cpuid == 1 )
-            op->u.get_max_cstate = acpi_get_csubstate_limit();
-        else
-            ret = -EINVAL;
-        return ret;
-
-    case XEN_SYSCTL_pm_op_set_max_cstate:
-        if ( op->cpuid == 0 )
-            acpi_set_cstate_limit(op->u.set_max_cstate);
-        else if ( op->cpuid == 1 )
-            acpi_set_csubstate_limit(op->u.set_max_cstate);
-        else
-            ret = -EINVAL;
-        return ret;
-    }
-
-    if ( op->cpuid >= nr_cpu_ids || !cpu_online(op->cpuid) )
-        return -EINVAL;
-    pmpt = processor_pminfo[op->cpuid];
-
-    switch ( op->cmd & PM_PARA_CATEGORY_MASK )
-    {
-    case CPUFREQ_PARA:
-        if ( !(xen_processor_pmbits & XEN_PROCESSOR_PM_PX) )
-            return -ENODEV;
-        if ( !pmpt || !(pmpt->perf.init & XEN_PX_INIT) )
-            return -EINVAL;
-        break;
-    }
-
-    switch ( op->cmd )
-    {
-    case GET_CPUFREQ_PARA:
-    {
-        ret = get_cpufreq_para(op);
-        break;
-    }
-
-    case SET_CPUFREQ_GOV:
-    {
-        ret = set_cpufreq_gov(op);
-        break;
-    }
-
-    case SET_CPUFREQ_PARA:
-    {
-        ret = set_cpufreq_para(op);
-        break;
-    }
-
-    case SET_CPUFREQ_CPPC:
-        ret = set_cpufreq_cppc(op);
-        break;
-
-    case GET_CPUFREQ_AVGFREQ:
-    {
-        op->u.get_avgfreq = cpufreq_driver_getavg(op->cpuid, USR_GETAVG);
-        break;
-    }
-
-    case XEN_SYSCTL_pm_op_enable_turbo:
-    {
-        ret = cpufreq_update_turbo(op->cpuid, CPUFREQ_TURBO_ENABLED);
-        break;
-    }
-
-    case XEN_SYSCTL_pm_op_disable_turbo:
-    {
-        ret = cpufreq_update_turbo(op->cpuid, CPUFREQ_TURBO_DISABLED);
-        break;
-    }
-
-    default:
-        printk("not defined sub-hypercall @ do_pm_op\n");
-        ret = -ENOSYS;
-        break;
-    }
-
-    return ret;
-}
diff --git a/xen/drivers/cpufreq/cpufreq_misc_governors.c b/xen/drivers/cpufreq/cpufreq_misc_governors.c
index 0327fad23b..e5cb9ab02f 100644
--- a/xen/drivers/cpufreq/cpufreq_misc_governors.c
+++ b/xen/drivers/cpufreq/cpufreq_misc_governors.c
@@ -64,6 +64,7 @@ static int cf_check cpufreq_governor_userspace(
     return ret;
 }
 
+#ifdef CONFIG_PM_OP
 int write_userspace_scaling_setspeed(unsigned int cpu, unsigned int freq)
 {
     struct cpufreq_policy *policy;
@@ -80,6 +81,7 @@ int write_userspace_scaling_setspeed(unsigned int cpu, unsigned int freq)
 
     return __cpufreq_driver_target(policy, freq, CPUFREQ_RELATION_L);
 }
+#endif /* CONFIG_PM_OP */
 
 static bool __init cf_check
 cpufreq_userspace_handle_option(const char *name, const char *val)
diff --git a/xen/drivers/cpufreq/cpufreq_ondemand.c b/xen/drivers/cpufreq/cpufreq_ondemand.c
index 06cfc88d30..0126a3f5d9 100644
--- a/xen/drivers/cpufreq/cpufreq_ondemand.c
+++ b/xen/drivers/cpufreq/cpufreq_ondemand.c
@@ -57,6 +57,7 @@ static struct dbs_tuners {
 
 static DEFINE_PER_CPU(struct timer, dbs_timer);
 
+#ifdef CONFIG_PM_OP
 int write_ondemand_sampling_rate(unsigned int sampling_rate)
 {
     if ( (sampling_rate > MAX_SAMPLING_RATE / MICROSECS(1)) ||
@@ -93,6 +94,7 @@ int get_cpufreq_ondemand_para(uint32_t *sampling_rate_max,
 
     return 0;
 }
+#endif /* CONFIG_PM_OP */
 
 static void dbs_check_cpu(struct cpu_dbs_info_s *this_dbs_info)
 {
diff --git a/xen/drivers/cpufreq/utility.c b/xen/drivers/cpufreq/utility.c
index 723045b240..987c3b5929 100644
--- a/xen/drivers/cpufreq/utility.c
+++ b/xen/drivers/cpufreq/utility.c
@@ -224,47 +224,6 @@ int cpufreq_driver_getavg(unsigned int cpu, unsigned int flag)
     return policy->cur;
 }
 
-int cpufreq_update_turbo(unsigned int cpu, int new_state)
-{
-    struct cpufreq_policy *policy;
-    int curr_state;
-    int ret = 0;
-
-    if (new_state != CPUFREQ_TURBO_ENABLED &&
-        new_state != CPUFREQ_TURBO_DISABLED)
-        return -EINVAL;
-
-    policy = per_cpu(cpufreq_cpu_policy, cpu);
-    if (!policy)
-        return -EACCES;
-
-    if (policy->turbo == CPUFREQ_TURBO_UNSUPPORTED)
-        return -EOPNOTSUPP;
-
-    curr_state = policy->turbo;
-    if (curr_state == new_state)
-        return 0;
-
-    policy->turbo = new_state;
-    if (cpufreq_driver.update)
-    {
-        ret = alternative_call(cpufreq_driver.update, cpu, policy);
-        if (ret)
-            policy->turbo = curr_state;
-    }
-
-    return ret;
-}
-
-
-int cpufreq_get_turbo_status(unsigned int cpu)
-{
-    struct cpufreq_policy *policy;
-
-    policy = per_cpu(cpufreq_cpu_policy, cpu);
-    return policy && policy->turbo == CPUFREQ_TURBO_ENABLED;
-}
-
 /*********************************************************************
  *                 POLICY                                            *
  *********************************************************************/
diff --git a/xen/include/acpi/cpufreq/cpufreq.h b/xen/include/acpi/cpufreq/cpufreq.h
index 241117a9af..0742aa9f44 100644
--- a/xen/include/acpi/cpufreq/cpufreq.h
+++ b/xen/include/acpi/cpufreq/cpufreq.h
@@ -143,9 +143,6 @@ extern int cpufreq_driver_getavg(unsigned int cpu, unsigned int flag);
 #define CPUFREQ_TURBO_UNSUPPORTED   0
 #define CPUFREQ_TURBO_ENABLED       1
 
-int cpufreq_update_turbo(unsigned int cpu, int new_state);
-int cpufreq_get_turbo_status(unsigned int cpu);
-
 static inline int
 __cpufreq_governor(struct cpufreq_policy *policy, unsigned int event)
 {
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 06:51:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 06:51:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016592.1393523 (Exim 4.92)
	(envelope-from )
	id 1uR3gW-0007Ks-7Q; Mon, 16 Jun 2025 06:51:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016592.1393523; Mon, 16 Jun 2025 06:51: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 1uR3gV-0007Jr-UQ; Mon, 16 Jun 2025 06:51:11 +0000
Received: by outflank-mailman (input) for mailman id 1016592;
 Mon, 16 Jun 2025 06:51: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 1uR3Y7-0008AT-Gm
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 06:42:31 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20603.outbound.protection.outlook.com
 [2a01:111:f403:2415::603])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 121decc6-4a7d-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 08:42:29 +0200 (CEST)
Received: from DM6PR07CA0122.namprd07.prod.outlook.com (2603:10b6:5:330::18)
 by DS2PR12MB9639.namprd12.prod.outlook.com (2603:10b6:8:27a::18) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Mon, 16 Jun
 2025 06:42:25 +0000
Received: from CY4PEPF0000EE3E.namprd03.prod.outlook.com
 (2603:10b6:5:330:cafe::96) by DM6PR07CA0122.outlook.office365.com
 (2603:10b6:5:330::18) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.23 via Frontend Transport; Mon,
 16 Jun 2025 06:42:24 +0000
Received: from SATLEXMB04.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.8835.15 via Frontend Transport; Mon, 16 Jun 2025 06:42:24 +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; Mon, 16 Jun 2025 01:42:21 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 121decc6-4a7d-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=OGrLl+n8Nw6uW+xMdOhSMnfCeJLvrFaCfI4ifxcbKe8QzJdl6csF/pVMN3oCZBQZndcbnnUPU0GFLQ45yPl+PBtcEthrd/DqVlefWcRx+Kvl32ldxAtrhzpoS+A31mF6AduQk+tdHkS/GtOLVYvqNZ5uArgwcUwmidyNV7mIbN8wZRzdzCBo8ojVrQdBKrtrgf+gyYST9hQgmdtcftViheoB2b5JwkvWD7U5PNx+0WzL2vsO7JMwsmuwSVO/VhfSHalxLjotd81ZVX+6STIcRA34eobmYr9eFE62SdkWRc1vOFJbDzF0eq3UjFqPGrAx6TaGw8+4tiQi4BOR8mXmkA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=WurO22YY37NaFn6R/aK5cXS4C2DatHBPKOP8khrxpEY=;
 b=R6JBIlaB/wdYZbm1X5QOTtxvAxFXABVH8R2i0yZFKpaFOpcY1qrsL6RHVQJsz5jU8SXXyrXIs2OU281YzbRtHKzpNba7XfXVG7R7XxQEre8HP/4jK3GmhbiLUN9V+7AAPDuCQRTw5iLnrOBAMCWroXbNUf5gaozEWNqL7ZsDgHVV8r1QYjPGZbe3Xe/5LBwRjdB1y+WqhP7aLHjG0ZGdp1K5AZ2BCTJ9QmUrRXpn4TuD3L0SQrMyaBBXIYxwOj9F8tKLOoyIa/p/Al7FF4n3WJc7NIbCjgsDl9qf8TBsfVVOjFlePsXdFGm18t421/lUIz0rAnDEnscA4LEoaU8o4w==
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=WurO22YY37NaFn6R/aK5cXS4C2DatHBPKOP8khrxpEY=;
 b=nKgeLYRnT1EfWUqEolHqVU9iIL9ROQ2OusMfrYj8U9qSUyURru940W1dGTVI1oR3ptn7tJGxFqQim1s4Ohk2ID42wPL6HBHv0rk6jBRCEoIJkTac6mD45MulRjJFypIY2e/UrDEW/DSfhRe9pisYwJ2HSQro5dgbS77tQt0VcEg=
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
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , "Julien
 Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Stefano Stabellini , "Daniel
 P. Smith" 
Subject: [PATCH v5 11/18] xen/sysctl: wrap around XEN_SYSCTL_page_offline_op
Date: Mon, 16 Jun 2025 14:41:21 +0800
Message-ID: <20250616064128.581164-12-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250616064128.581164-1-Penny.Zheng@amd.com>
References: <20250616064128.581164-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: CY4PEPF0000EE3E:EE_|DS2PR12MB9639:EE_
X-MS-Office365-Filtering-Correlation-Id: 74a2a4c7-f714-492c-146c-08ddaca0f439
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?iMSFsTMFMZt4/C7a3KdBnrqTtfGAMSunASzQSIfjnt24JURIZu75F8Pa46jT?=
 =?us-ascii?Q?/zqKamm5oZsewwZ3/wXJ8IfGq5eRmroSlmpq+qEUYZ1y7YN8NILVSnx49fm3?=
 =?us-ascii?Q?2ShMBZfvuZ5gAoOr6Dzc5xQcuhNTc8a0dP0lA2Xq7NoMbVpmfiUlLH+S0Jgv?=
 =?us-ascii?Q?ae1jLJCwAo7pSYx14UTHc20jM2vYRT9swDeu7kTVcKs7hbth+jCUDverLIKN?=
 =?us-ascii?Q?Uat9EqFdLTVyEO25E2ZJssNqAmWijBc0m6uaBeuBSSv4CwBosGYYUUT/2ulc?=
 =?us-ascii?Q?7+VZXmjx8xucEAXHjBDy6z2SYrtUDBeMSLZJlbJYQCbT8Uv6KKUqkcXvr082?=
 =?us-ascii?Q?NW+QEjTDy/OgMgHyP1LQXVFQ3SkWf5kbLqOxdB2IkGSqV50ZgPt+EnEXgNiL?=
 =?us-ascii?Q?JXJMFL9IUNX9iddauQkbrYSRWPXSvKQQ9HY4NSDwvt7kXHqIdg28oc7tOtFn?=
 =?us-ascii?Q?PurxAcAhJvBT6wvUPO0meEU2DCMLE6V7u0cDgCwcGpbMJ3e25WDVrv0e1zTc?=
 =?us-ascii?Q?byuXj3Rup7hgr34PK+iWwBXtN6ySMG2g5gICBf7tUa5PRwB3UhcCGx3Mwhdg?=
 =?us-ascii?Q?Xj7vEdzkNxHD2EKikp1I/iue91H4QvzPWABwTfBfFt+nvqTaXiNX89usU1nk?=
 =?us-ascii?Q?equO3zS7sMbb9Elkfm56u52uMIL1q7QJbNCkNj6IVHwwz3eh5zGX08Zx24hn?=
 =?us-ascii?Q?0jv5Q21TsDXaw5steX37oSy+pfj+Dpvonz4MndQNsBaGdxQTsP8LrSkEK0Fa?=
 =?us-ascii?Q?FesvvQmjZ12IDAq/ESeeHsJupol3zxQCWaE73pPpWbtu7kbx/YYBS0mbbtxP?=
 =?us-ascii?Q?unxA28Dyeh5ki8KRFd0q2xgOoKtt0yJl1msa4iO1nJcaXsz/e15T2JnxsjWZ?=
 =?us-ascii?Q?uUAmhHVuc1IIL4WMORNQtcgZ2gfiPapMPbtBrsgCxouV+3sF4VHDpsGCmtIQ?=
 =?us-ascii?Q?+MYMhhwMRZy8TEiJEznRFZmsKLcQ1Wp4uGdX/gUVc+6aUN0uK73aXJRf9ihe?=
 =?us-ascii?Q?+1PGwhtV+ePLdRBhjYkN15LRO9tAz+lqY4Mfqi9CigIPY9TszXwp3T3fYTZa?=
 =?us-ascii?Q?NbdjBdGLUuNNsO31B32hxwbJzDLB1NxCRF/+RPe+7N4ok67Da5UBUwuw0GRR?=
 =?us-ascii?Q?JEU84Gfn5w7TuN1zLUeAj7Vdej02xtQZAsE7YqGQfb2H6XA30h+6j0AJfaQA?=
 =?us-ascii?Q?jNZrVYqPP6HhW55QZjWXJTsmLYpZkRwL/TRRyxlwq9TsnLxUjYRNDAfnBLYg?=
 =?us-ascii?Q?rlY2y5+1TZ4adHWDwVA5YXwdTA4K8iF2xo1Ax0pb7OuwKZew60xNjjM4m4KR?=
 =?us-ascii?Q?YPY8YDZZpuVE30GiqZsSHUp6cDyg66cFGtVE7E9I7Mi9fpFODLq16cUMPNm/?=
 =?us-ascii?Q?bfj1BMyCuBbwyXc6L53Jk52PVnutpCNaKfe8+247/EGZw9VojmI31vVqfULM?=
 =?us-ascii?Q?imqSi85nNf59BOULowM7og7fN63CGw0wAmq38QjTi8tVaetzNc1HGQvbpnWn?=
 =?us-ascii?Q?wqXqSygHv5mXKKeIcFlvfQJFeNAiLHSkdYqf?=
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: 16 Jun 2025 06:42:24.7566
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 74a2a4c7-f714-492c-146c-08ddaca0f439
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:
	CY4PEPF0000EE3E.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS2PR12MB9639

The following functions are only to deal with XEN_SYSCTL_page_offline_op,
then shall be wrapped:
- xsm_page_offline()
- online_page()
- query_page_offline()

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
---
v1 -> v2:
- add transient #ifdef in sysctl.c for correct compilation
- no need to wrap declarations
- place the #ifdef inside the function body to have less redundancy
---
v3 -> v4:
- remove transient "#ifdef CONFIG_SYSCTL"
---
 xen/common/page_alloc.c | 2 ++
 xen/include/xsm/xsm.h   | 6 ++++++
 xen/xsm/dummy.c         | 2 ++
 xen/xsm/flask/hooks.c   | 6 ++++++
 4 files changed, 16 insertions(+)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index b204f22f50..dec4cb2ab1 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1779,6 +1779,7 @@ int offline_page(mfn_t mfn, int broken, uint32_t *status)
     return 0;
 }
 
+#ifdef CONFIG_SYSCTL
 /*
  * Online the memory.
  *   The caller should make sure end_pfn <= max_page,
@@ -1863,6 +1864,7 @@ int query_page_offline(mfn_t mfn, uint32_t *status)
 
     return 0;
 }
+#endif /* CONFIG_SYSCTL */
 
 /*
  * This function should only be called with valid pages from the same NUMA
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 042a99449f..5ac99904c4 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -138,7 +138,9 @@ struct xsm_ops {
     int (*resource_setup_gsi)(int gsi);
     int (*resource_setup_misc)(void);
 
+#ifdef CONFIG_SYSCTL
     int (*page_offline)(uint32_t cmd);
+#endif
     int (*hypfs_op)(void);
 
     long (*do_xsm_op)(XEN_GUEST_HANDLE_PARAM(void) op);
@@ -597,7 +599,11 @@ static inline int xsm_resource_setup_misc(xsm_default_t def)
 
 static inline int xsm_page_offline(xsm_default_t def, uint32_t cmd)
 {
+#ifdef CONFIG_SYSCTL
     return alternative_call(xsm_ops.page_offline, cmd);
+#else
+    return -EOPNOTSUPP;
+#endif
 }
 
 static inline int xsm_hypfs_op(xsm_default_t def)
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index cd0e844fcf..d46413ad8c 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -96,7 +96,9 @@ static const struct xsm_ops __initconst_cf_clobber dummy_ops = {
     .resource_setup_gsi            = xsm_resource_setup_gsi,
     .resource_setup_misc           = xsm_resource_setup_misc,
 
+#ifdef CONFIG_SYSCTL
     .page_offline                  = xsm_page_offline,
+#endif
     .hypfs_op                      = xsm_hypfs_op,
     .hvm_param                     = xsm_hvm_param,
     .hvm_param_altp2mhvm           = xsm_hvm_param_altp2mhvm,
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index df7e10775b..45c12aa662 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1206,10 +1206,12 @@ static int cf_check flask_resource_unplug_core(void)
     return avc_current_has_perm(SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__UNPLUG, NULL);
 }
 
+#ifdef CONFIG_SYSCTL
 static int flask_resource_use_core(void)
 {
     return avc_current_has_perm(SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__USE, NULL);
 }
+#endif /* CONFIG_SYSCTL */
 
 static int cf_check flask_resource_plug_pci(uint32_t machine_bdf)
 {
@@ -1274,6 +1276,7 @@ static int cf_check flask_resource_setup_misc(void)
     return avc_current_has_perm(SECINITSID_XEN, SECCLASS_RESOURCE, RESOURCE__SETUP, NULL);
 }
 
+#ifdef CONFIG_SYSCTL
 static inline int cf_check flask_page_offline(uint32_t cmd)
 {
     switch ( cmd )
@@ -1288,6 +1291,7 @@ static inline int cf_check flask_page_offline(uint32_t cmd)
         return avc_unknown_permission("page_offline", cmd);
     }
 }
+#endif /* CONFIG_SYSCTL */
 
 static inline int cf_check flask_hypfs_op(void)
 {
@@ -1948,7 +1952,9 @@ static const struct xsm_ops __initconst_cf_clobber flask_ops = {
     .resource_setup_gsi = flask_resource_setup_gsi,
     .resource_setup_misc = flask_resource_setup_misc,
 
+#ifdef CONFIG_SYSCTL
     .page_offline = flask_page_offline,
+#endif
     .hypfs_op = flask_hypfs_op,
     .hvm_param = flask_hvm_param,
     .hvm_param_altp2mhvm = flask_hvm_param_altp2mhvm,
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 06:51:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 06:51:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016594.1393537 (Exim 4.92)
	(envelope-from )
	id 1uR3gX-0007lE-Ga; Mon, 16 Jun 2025 06:51:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016594.1393537; Mon, 16 Jun 2025 06: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 1uR3gX-0007kw-D3; Mon, 16 Jun 2025 06:51:13 +0000
Received: by outflank-mailman (input) for mailman id 1016594;
 Mon, 16 Jun 2025 06:51: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 1uR3YS-0008OL-4k
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 06:42:52 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20623.outbound.protection.outlook.com
 [2a01:111:f403:2009::623])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1e9824fe-4a7d-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 08:42:50 +0200 (CEST)
Received: from CY5PR15CA0099.namprd15.prod.outlook.com (2603:10b6:930:7::9) by
 CY3PR12MB9555.namprd12.prod.outlook.com (2603:10b6:930:10a::14) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.28; Mon, 16 Jun
 2025 06:42:46 +0000
Received: from CY4PEPF0000EE3D.namprd03.prod.outlook.com
 (2603:10b6:930:7:cafe::dd) by CY5PR15CA0099.outlook.office365.com
 (2603:10b6:930:7::9) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.17 via Frontend Transport; Mon,
 16 Jun 2025 06:42:46 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CY4PEPF0000EE3D.mail.protection.outlook.com (10.167.242.15) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Mon, 16 Jun 2025 06:42:46 +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; Mon, 16 Jun 2025 01:42:43 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1e9824fe-4a7d-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=J9JZQw5ms4AjSvk9Gio4QELYflws1yTdPRXKsZ1BM9GT8PjZIt/aWe5XRfXExrEduUNlOjiJ5bq/MY6sskEQqKGSUNf6V1oxWY6xqPKklFD7+702qTZ0xHLPp80kJqC2pNOF1CBIVbOJvZkZctoHRJuN31PXmTEr7LMO74snnu07oPq7XlVIpfBfY3CcS8E42Dp7U3Gx430qPKThy3EmiZ5s3vrpfiBqfsZbqM5hMsGZrydVV+ghgM0PK0GOQt27J9O92gNiNuSnfATu9Z4g6ZGgLC2RVwAD9KznaqRVh3VY27xrFKHkrlSWtq7mtdCk+ECHocqdQWmudKK/UqL1uQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=BjV4dXIDIbWp0L8VeuBDiAUAVrHgampbCea6EtH+5mI=;
 b=u2bWw3xil0yBGw62oyTN9ierYUfxcG3Klr2ihiOcFciiDs0khg1z45shUzPhh31wh7LJdHi50Yr34V6F1lLczX5ShSYUF8wlYlpQJvLkgaPmQ0r9enw16eKjv8Kq2/pt4P1dFhynpKAM9b3C/U/Fcuw80MuhMREKnLo1G3/vvHFbg/lxB6A2aQEnimMpS1vICC/TYw+5zMEExddX/p1cnijmiCziL7tl2y00up16oUbqBhNBdnz/4FwC9wkQ0T19R36EQdYmJkeoTRk97/I+ro0ugbsickgAhEinIO0gSuNyguKAF3FLeAnt6TYPlP0buzcvjnYyfX7qL5NDRqvBdA==
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=BjV4dXIDIbWp0L8VeuBDiAUAVrHgampbCea6EtH+5mI=;
 b=q5vLtFoUgZUqeueL283qLg8Hlv4D/boFmzocIFugY9MCjG7V2AKNp6gN/LiuygHiPVEb9sCtYTLsvGCcwji1LijAShDk1B0GoaKjtkyZGW1SBZbBW4K4bUHOXsmo/BcavyD7DeLEtb3RIZ8HibB5UVrUwmpm0fCBzDGlT8DlhgI=
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: , Stefano Stabellini , "Jan
 Beulich" , Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Anthony PERARD
	, Michal Orzel , "Julien
 Grall" , Stefano Stabellini , "Sergiy
 Kibrik" , Penny Zheng 
Subject: [PATCH v5 18/18] xen/sysctl: wrap around sysctl hypercall
Date: Mon, 16 Jun 2025 14:41:28 +0800
Message-ID: <20250616064128.581164-19-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250616064128.581164-1-Penny.Zheng@amd.com>
References: <20250616064128.581164-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: CY4PEPF0000EE3D:EE_|CY3PR12MB9555:EE_
X-MS-Office365-Filtering-Correlation-Id: d507cb0d-5841-4c08-f6c3-08ddaca10133
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?EmPfogi0i52IlRGbq9bGYewxbVmExiwdmDBgBX+DSxWIxp25qXz7are3dvcb?=
 =?us-ascii?Q?o7FTLkGgadGLOlBYAZSRPq8gqatAPtjBFfKnVgBe5lMJD3BmpMs5qOkeyTkI?=
 =?us-ascii?Q?i4nXRzyicN2RUAqc96zwF1mL5kIYo0VDKG1ww5BrWueD1/NbRJAADapfpQyF?=
 =?us-ascii?Q?oTqaDjTPeP+TmWFvz7IgtfyVxO+4QA3JKbzvbY5vhWvv0RHSyOfSrATEZVe/?=
 =?us-ascii?Q?K+v41FzVVJccbI+GWRUeIh03jVTm8o3AoumRp6vENkCtPWcws9YLoYCd7oky?=
 =?us-ascii?Q?C9K87W8lKN50xk6t/HuhFchuvooMsr0H6g2GUIzqMDSesiluiSht2qwLPmG9?=
 =?us-ascii?Q?UtlSR5BmWoKQA9igjdbr63ojkGNUlI6cPWjwr9Q55O/YQ2B/AL6ySCK3n++g?=
 =?us-ascii?Q?fWgqEYwksVhsVzDVrq6TchxGxIh2ElLETWHzDQ8Mqp1n3kMkCPFKFoyyu9gC?=
 =?us-ascii?Q?/urm0FDE29fyEN7DlSyknX4khI+mnfswOHnExvNA/jNBdR4b7sYXpSUXoFg7?=
 =?us-ascii?Q?xX8b7AmsNqVU8B5q2sUN3KRjN5NgnhS2mvpR91t2LRj6Q90AJ6jj+rFIOedL?=
 =?us-ascii?Q?1wSW1oQnmkwcHVEBxO8Os+7ksgtirSa/LfG6K6KIlhDOocKTHVjdowuxN/94?=
 =?us-ascii?Q?7xdJoSwi15sImNwxvjA7TRL/BDqD4lnAGtd6dBQyHIYGALEMrvL7VVx+TMfY?=
 =?us-ascii?Q?2sd63COxyCcwhRmSaEsQFT69r7xA7MbpvV4+vAM+IkTYvmsv8VLAMY0IMTlc?=
 =?us-ascii?Q?Ww3Jsnh+25o1WhvL9SgjAUrd2hlZ9NiV+xjS+2lcUxd3iphW6FI00QA+XseM?=
 =?us-ascii?Q?cwjgSutgg27tw4hB0ldyQ2fyxK4QdJAKFylByCgCgmwZapuudCBAS0w5sInF?=
 =?us-ascii?Q?6xy4kWWuJ/1lWexSSNEfC06KmNQq6Sefavc1GWDv4+dw8/nsYTBIysMeqz4H?=
 =?us-ascii?Q?YX+7k8ram1BnYXdHASa51JFIEWefxWxH7atnllA3AAZpZeY3GUKwT4oI2ANJ?=
 =?us-ascii?Q?8m2QttEKPppTo18YfwfnBQg33+xCZTk9Dey5BrQJRynFpCkewOhSf3fY/QWh?=
 =?us-ascii?Q?TlkO5DB/LLxBUGGaUIeWrP8u0jQ4oKyNScqlI23dNY/JsdRLCLOCSLce794+?=
 =?us-ascii?Q?Xdbsj0vKg2aizKqd9LBs83lLHZaMZWf0DjFq84IGzmZ63ODmxu0AnSgL2n8B?=
 =?us-ascii?Q?UQL0tPsgPKqVkYQanVpFF9nV+zEGzbXIVzA5BOiaHOhT2kz+30MSCSMIYIqU?=
 =?us-ascii?Q?rmDo9MuMyqeEzuj3SY5Q9Q77VpLKnSrgAxsCcoDApUaHyJUTEIJpVdnBHMFZ?=
 =?us-ascii?Q?J78ByDEYTUJ5q2P7y9XkzLh97NJVutHHjRFrHSPHUtSu475iQYV0W3P7/bYa?=
 =?us-ascii?Q?7VL5UH6NkoZMyT2XGcrkqnfc6pPvxgcfUPt9vsNLhG8bmis8/k+WXKgpIFaT?=
 =?us-ascii?Q?N1QVMJFhaXcSe2MjAEvrjQIy8wtds2GJBp6o5U6FikCc2ppdXYVPAzES1lFd?=
 =?us-ascii?Q?5qiA3iVFYvKr42dD/d99HMA4a6U6qbrawawW?=
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: 16 Jun 2025 06:42:46.5373
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d507cb0d-5841-4c08-f6c3-08ddaca10133
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:
	CY4PEPF0000EE3D.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY3PR12MB9555

From: Stefano Stabellini 

Wrap sysctl hypercall def and sysctl.o with CONFIG_SYSCTL, and since
PV_SHIM_EXCLUSIVE needs sorting in the future, we move them out of
PV_SHIM_EXCLUSIVE condition at the same time.

We need to make SYSCTL with prompt back, add help info and set default
value as y. We shall at least provide "# CONFIG_SYSCTL is not set" in preset
configs for PV shim on x86.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Sergiy Kibrik 
Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
---
v1 -> v2:
- remove all transient "#ifdef CONFIG_SYSCTL"-s in sysctl.c
---
v2 -> v3:
- move out of CONFIG_PV_SHIM_EXCLUSIVE condition
---
v3 -> v4:
- make SYSCTL with prompt
- state unsetting SYSCTL in pvshim_defconfig
---
v4 -> v5:
- adapt to the new changes in commit "xen: introduce CONFIG_SYSCTL"
- expand help info also for PV shim
- refactor commit message
---
 xen/arch/x86/configs/pvshim_defconfig | 1 +
 xen/common/Kconfig                    | 6 +++++-
 xen/common/Makefile                   | 2 +-
 xen/include/hypercall-defs.c          | 8 ++++++--
 4 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/configs/pvshim_defconfig b/xen/arch/x86/configs/pvshim_defconfig
index 2ad27f898e..dff1ecf674 100644
--- a/xen/arch/x86/configs/pvshim_defconfig
+++ b/xen/arch/x86/configs/pvshim_defconfig
@@ -26,3 +26,4 @@ CONFIG_EXPERT=y
 # CONFIG_INTEL_IOMMU is not set
 # CONFIG_DEBUG is not set
 # CONFIG_GDBSX is not set
+# CONFIG_SYSCTL is not set
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 65f07289dd..64865112a1 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -616,7 +616,11 @@ menu "Supported hypercall interfaces"
 	visible if EXPERT
 
 config SYSCTL
-	def_bool y
+	bool "Enable sysctl hypercall"
+	default y
+	help
+	  This option shall only be disabled on some dom0less systems, or
+	  PV shim on x86, to reduce Xen footprint.
 
 endmenu
 
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 98f0873056..15ab048244 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -49,6 +49,7 @@ obj-y += spinlock.o
 obj-$(CONFIG_STACK_PROTECTOR) += stack-protector.o
 obj-y += stop_machine.o
 obj-y += symbols.o
+obj-$(CONFIG_SYSCTL) += sysctl.o
 obj-y += tasklet.o
 obj-y += time.o
 obj-y += timer.o
@@ -70,7 +71,6 @@ 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_VM_EVENT) += monitor.o
-obj-y += sysctl.o
 endif
 
 extra-y := symbols-dummy.o
diff --git a/xen/include/hypercall-defs.c b/xen/include/hypercall-defs.c
index 7720a29ade..c1081d87a2 100644
--- a/xen/include/hypercall-defs.c
+++ b/xen/include/hypercall-defs.c
@@ -194,8 +194,10 @@ 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
+#ifndef CONFIG_PV_SHIM_EXCLUSIVE
 domctl(xen_domctl_t *u_domctl)
 paging_domctl_cont(xen_domctl_t *u_domctl)
 platform_op(xen_platform_op_t *u_xenpf_op)
@@ -273,8 +275,10 @@ physdev_op                         compat   do       hvm      hvm      do_arm
 #ifdef CONFIG_HVM
 hvm_op                             do       do       do       do       do
 #endif
-#ifndef CONFIG_PV_SHIM_EXCLUSIVE
+#ifdef CONFIG_SYSCTL
 sysctl                             do       do       do       do       do
+#endif
+#ifndef CONFIG_PV_SHIM_EXCLUSIVE
 domctl                             do       do       do       do       do
 #endif
 #ifdef CONFIG_KEXEC
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 06:51:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 06:51:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016614.1393547 (Exim 4.92)
	(envelope-from )
	id 1uR3gn-0000FU-O1; Mon, 16 Jun 2025 06:51:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016614.1393547; Mon, 16 Jun 2025 06:51: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 1uR3gn-0000FL-L2; Mon, 16 Jun 2025 06:51:29 +0000
Received: by outflank-mailman (input) for mailman id 1016614;
 Mon, 16 Jun 2025 06:51: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 1uR3YF-0008AT-TH
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 06:42:39 +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 177108fa-4a7d-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 08:42:38 +0200 (CEST)
Received: from PH0PR07CA0033.namprd07.prod.outlook.com (2603:10b6:510:e::8) by
 DM6PR12MB4388.namprd12.prod.outlook.com (2603:10b6:5:2a9::10) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8835.29; Mon, 16 Jun 2025 06:42:30 +0000
Received: from CY4PEPF0000EE39.namprd03.prod.outlook.com
 (2603:10b6:510:e:cafe::50) by PH0PR07CA0033.outlook.office365.com
 (2603:10b6:510:e::8) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.35 via Frontend Transport; Mon,
 16 Jun 2025 06:42:30 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CY4PEPF0000EE39.mail.protection.outlook.com (10.167.242.11) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Mon, 16 Jun 2025 06:42:29 +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; Mon, 16 Jun 2025 01:42:26 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 177108fa-4a7d-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lEwHkMVFyUoAryuLfS9brjyuxe8M1bXAGgKsX2mR5tk5c2KWmhzBVi4br6TUwEuy1ozhRdAF+/GyGvSZP2kESqZSPK5k3Is9yKMoClXvVrBbPy9LyMp58U5mLxpNUQtbznJ5kESCE3/rwJiTzzClqbd1ubTuIk/4M1nPQ0eUzPhyEtOqfaILgJuyW9O/bLAXGcyRq1gefnF/aNfd8hersKGQUO9ZrrTpNz4m/tqw8gQnA2J/zjbb2MUd+24Co+gtU3E2QnRFch1ZxxGeZtf7cw4uav+J1sNmyiQ5GPyPk2Y4necNkWeQUmrYyW04jenidtne5Py0Reng2f2ao7xHZg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=WvykzEStZK73rMFsbUxdbGQm1JqJFz8VY0tKPFQ221s=;
 b=RlJwTpLDW1+nH6YyAE+7cfVTpGRR9tBNlfxs+0b/ML8YVFZw+b9FJSOSGpVuM+dafkcuXYZkLXO3iaOrkEa1aEUD9b/XXwWMIYjM/U/EgfQoPA3TGvJlU+qwxZp1jZH7+gIWVp1lHbik73VMMI0YNoDimbWK1DXU6fwvQXDWboUq64kx+pc4EJs8bOA78ecgWIBVWetBWxNkYVh71FjAXqeAUrp4k7PtLFFkYbRifqurG+f2VvsAD2ibd1DUAB7gzMU9hhe1KG7fSPAXx9RR1F8eUHxW+nAMbTE9Ogfb+aeFCzfS1V40JjjdXwesq3F9OQROo0xPR2B2rhx0p1qKCA==
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=WvykzEStZK73rMFsbUxdbGQm1JqJFz8VY0tKPFQ221s=;
 b=XgMaJ80nw6WmQ+um0Sh+ikBCaMaeao7TcVEeAwsgR09VuELByXqIgc0uMIEQGCH2GZi+yifgbyECx50JfZqcu0obpv9XzFekUm/ycZXKOCuxQs3PeDQWX0JtK0ga+wsr7subDnHbDSm2PRBQyY6IHIlAzUONUSjYiuHhiXt/7SE=
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 , Nathan Studer
	, Stewart Hildebrand , "Dario
 Faggioli" , Juergen Gross , George
 Dunlap , "Daniel P. Smith"
	, Stefano Stabellini 
Subject: [PATCH v5 13/18] xen/sysctl: wrap around XEN_SYSCTL_scheduler_op
Date: Mon, 16 Jun 2025 14:41:23 +0800
Message-ID: <20250616064128.581164-14-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250616064128.581164-1-Penny.Zheng@amd.com>
References: <20250616064128.581164-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: CY4PEPF0000EE39:EE_|DM6PR12MB4388:EE_
X-MS-Office365-Filtering-Correlation-Id: 3e51a4db-d3b4-4bed-cb54-08ddaca0f751
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?25pPumus578d912yMsvMEDsV3WaJfObrSswiKnUcy7pRuXy3tSnFh5UTw0xd?=
 =?us-ascii?Q?6rY7bGxMJO9RqLs3Pho0mhVvPSzSWimOwo3zMNnBFmhuiCism1Aye2ZDvzs0?=
 =?us-ascii?Q?qCqrd5Q8BuN4r42eENtXPGH3lZlOafYUXIprPRTPZKSeDXJPSuL0dBfWTRQZ?=
 =?us-ascii?Q?vYqaFX6habrHwqZufxNW6viYAK8V7tls0FrfejG/hTYOjKfs0pmHCmi6ENwJ?=
 =?us-ascii?Q?PAisBEroZg6bLh41dtrxtMA2JgiiJUPJWkn3pZJ9AhQWaiyS6yRdS0+yloxx?=
 =?us-ascii?Q?7PZxstcPmYU97Jf3soEm91rSlb4ZLtoAT+5oFTpdGYSr2APtoV0Drvuc4Nz0?=
 =?us-ascii?Q?V8Az/8PZkNd0bQy6LACKChh30/TjLxc/CjjIFp4fN3DXZv0KQykb9mhlaYp7?=
 =?us-ascii?Q?Q/CXtxpfNCqVekU8M2J9bCpY21U5LnHpcavLC4FyoQ9Tqos6vNplYcTwwpv7?=
 =?us-ascii?Q?fB3yA0pxQ14mATW1KVAC9kJt/1EGmJr7Z+xhZYMqEiXOCCvBi7N2wir6jA1M?=
 =?us-ascii?Q?RKNmg6fm5pxVlYBCKZ+qhldzU+xf1CwFTAc/qx0t2ym6/N3W1/4oojrlHNx1?=
 =?us-ascii?Q?WXe47I66Nb66u2lt3pxGANreDBry3dbfiWDARNrDwB6w/MdbOMGA3TJoYPc4?=
 =?us-ascii?Q?7zZFOrwIrQlVY0FlBQjGCf5TZGsjMn1IcaCsjkXQkjmMQzwo/fh67IERVkzh?=
 =?us-ascii?Q?1nSJsYsy3ZY2iQ/MFEkByEdmw+ObK6BE/XC+nT5u6K+D0QpI1PRujiBkmbRN?=
 =?us-ascii?Q?T0tU6c42tAmVscLjds5yswNWd4JlQDRs4WAtp6gFkmLnrtdvie1aVHW8DewB?=
 =?us-ascii?Q?bkmz69EXPmBLuScMgX871NF5MvfiS59SfXMNQkkmYF6+uUvIdMX8vkqh4t8T?=
 =?us-ascii?Q?XlHxMNa+st7Sa02UcyT0Fk24M/k+RKge3kWxBUZDm9zdOXIB7/KH/mrkvtRu?=
 =?us-ascii?Q?Rc+OnJzt2H/eKl9JNNHe0ltSJ5FZRXwM18zDhrz4tzRFORtIQRP7TO30T29s?=
 =?us-ascii?Q?bKYHP2OXH4jLWR+QzcGxTH7nIoEyH0ktmwDmVYrUmSd2+XALas2rVXQCm4p/?=
 =?us-ascii?Q?9L2fHpCqZF7ic/iz75npFQErLyGCNSv1NzSLb7h4qTqkpREGJHwF+3w+izle?=
 =?us-ascii?Q?ev5tmWa0RgatBE9npmi64G6Fbsnu17s/0ToLOylzb+Bqi2YaZb534/Kc9G4B?=
 =?us-ascii?Q?NdV9x6U76p/numaF83ziDrxPpcGCe0nifhYUP8DzPzV9VlHfRBhcNscxUgIh?=
 =?us-ascii?Q?2puVPdghxCXK6cz5RO8o6WFJGSrNro2fV7Wbw4Ep5LptPg5Y07/O31zYVToI?=
 =?us-ascii?Q?dftDc1c1fBjJ81RLew7GWX7ZjDpkD4F25mio4eyMWRXjSC1tOY0wygTZ3c2e?=
 =?us-ascii?Q?aZcoZIwCqXurPkf/H36Np2CSRDZBnHnizbY86JyahySt0Tz1gRWzomCN3EKa?=
 =?us-ascii?Q?2YlORjwxP9wJv0iCESytr6IVKum0XLeNMl7HP7pO+Y+9O7bgIWTaVH9Op9wK?=
 =?us-ascii?Q?EGUvLOtrh+DVI4I+4/f5Ui/G+gniVvg1MOkB?=
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: 16 Jun 2025 06:42:29.9519
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3e51a4db-d3b4-4bed-cb54-08ddaca0f751
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:
	CY4PEPF0000EE39.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4388

Function sched_adjust_global is designed for XEN_SYSCTL_scheduler_op, so
itself and its calling flow, like .adjust_global, shall all be wrapped.

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
Acked-by: Stewart Hildebrand  #a653
---
v1 -> v2:
- no need to wrap declarations
- add transient #ifdef in sysctl.c for correct compilation
---
v2 -> v3:
- move #endif up ahead of the blank line
---
v3 -> v4:
- remove transient "#ifdef CONFIG_SYSCTL"
---
 xen/common/sched/arinc653.c | 6 ++++++
 xen/common/sched/core.c     | 2 ++
 xen/common/sched/credit.c   | 4 ++++
 xen/common/sched/credit2.c  | 4 ++++
 xen/common/sched/private.h  | 4 ++++
 xen/include/xsm/xsm.h       | 4 ++++
 xen/xsm/dummy.c             | 2 ++
 xen/xsm/flask/hooks.c       | 4 ++++
 8 files changed, 30 insertions(+)

diff --git a/xen/common/sched/arinc653.c b/xen/common/sched/arinc653.c
index 432ccfe662..3c014c9934 100644
--- a/xen/common/sched/arinc653.c
+++ b/xen/common/sched/arinc653.c
@@ -220,6 +220,7 @@ static void update_schedule_units(const struct scheduler *ops)
                       SCHED_PRIV(ops)->schedule[i].unit_id);
 }
 
+#ifdef CONFIG_SYSCTL
 /**
  * This function is called by the adjust_global scheduler hook to put
  * in place a new ARINC653 schedule.
@@ -334,6 +335,7 @@ arinc653_sched_get(
 
     return 0;
 }
+#endif /* CONFIG_SYSCTL */
 
 /**************************************************************************
  * Scheduler callback functions                                           *
@@ -653,6 +655,7 @@ a653_switch_sched(struct scheduler *new_ops, unsigned int cpu,
     return &sr->_lock;
 }
 
+#ifdef CONFIG_SYSCTL
 /**
  * Xen scheduler callback function to perform a global (not domain-specific)
  * adjustment. It is used by the ARINC 653 scheduler to put in place a new
@@ -692,6 +695,7 @@ a653sched_adjust_global(const struct scheduler *ops,
 
     return rc;
 }
+#endif /* CONFIG_SYSCTL */
 
 /**
  * This structure defines our scheduler for Xen.
@@ -726,7 +730,9 @@ static const struct scheduler sched_arinc653_def = {
     .switch_sched   = a653_switch_sched,
 
     .adjust         = NULL,
+#ifdef CONFIG_SYSCTL
     .adjust_global  = a653sched_adjust_global,
+#endif
 
     .dump_settings  = NULL,
     .dump_cpu_state = NULL,
diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index 13fdf57e57..ea95dea65a 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -2112,6 +2112,7 @@ long sched_adjust(struct domain *d, struct xen_domctl_scheduler_op *op)
     return ret;
 }
 
+#ifdef CONFIG_SYSCTL
 long sched_adjust_global(struct xen_sysctl_scheduler_op *op)
 {
     struct cpupool *pool;
@@ -2140,6 +2141,7 @@ long sched_adjust_global(struct xen_sysctl_scheduler_op *op)
 
     return rc;
 }
+#endif /* CONFIG_SYSCTL */
 
 static void vcpu_periodic_timer_work_locked(struct vcpu *v)
 {
diff --git a/xen/common/sched/credit.c b/xen/common/sched/credit.c
index a6bb321e7d..6dcf6b2c8b 100644
--- a/xen/common/sched/credit.c
+++ b/xen/common/sched/credit.c
@@ -1256,6 +1256,7 @@ __csched_set_tslice(struct csched_private *prv, unsigned int timeslice_ms)
     prv->credit = prv->credits_per_tslice * prv->ncpus;
 }
 
+#ifdef CONFIG_SYSCTL
 static int cf_check
 csched_sys_cntl(const struct scheduler *ops,
                         struct xen_sysctl_scheduler_op *sc)
@@ -1298,6 +1299,7 @@ csched_sys_cntl(const struct scheduler *ops,
     out:
     return rc;
 }
+#endif /* CONFIG_SYSCTL */
 
 static void *cf_check
 csched_alloc_domdata(const struct scheduler *ops, struct domain *dom)
@@ -2288,7 +2290,9 @@ static const struct scheduler sched_credit_def = {
 
     .adjust         = csched_dom_cntl,
     .adjust_affinity= csched_aff_cntl,
+#ifdef CONFIG_SYSCTL
     .adjust_global  = csched_sys_cntl,
+#endif
 
     .pick_resource  = csched_res_pick,
     .do_schedule    = csched_schedule,
diff --git a/xen/common/sched/credit2.c b/xen/common/sched/credit2.c
index 0a83f23725..0b3b61df57 100644
--- a/xen/common/sched/credit2.c
+++ b/xen/common/sched/credit2.c
@@ -3131,6 +3131,7 @@ csched2_aff_cntl(const struct scheduler *ops, struct sched_unit *unit,
         __clear_bit(__CSFLAG_pinned, &svc->flags);
 }
 
+#ifdef CONFIG_SYSCTL
 static int cf_check csched2_sys_cntl(
     const struct scheduler *ops, struct xen_sysctl_scheduler_op *sc)
 {
@@ -3162,6 +3163,7 @@ static int cf_check csched2_sys_cntl(
 
     return 0;
 }
+#endif /* CONFIG_SYSCTL */
 
 static void *cf_check
 csched2_alloc_domdata(const struct scheduler *ops, struct domain *dom)
@@ -4232,7 +4234,9 @@ static const struct scheduler sched_credit2_def = {
 
     .adjust         = csched2_dom_cntl,
     .adjust_affinity= csched2_aff_cntl,
+#ifdef CONFIG_SYSCTL
     .adjust_global  = csched2_sys_cntl,
+#endif
 
     .pick_resource  = csched2_res_pick,
     .migrate        = csched2_unit_migrate,
diff --git a/xen/common/sched/private.h b/xen/common/sched/private.h
index c0e7c96d24..d6884550cd 100644
--- a/xen/common/sched/private.h
+++ b/xen/common/sched/private.h
@@ -356,8 +356,10 @@ struct scheduler {
                                     struct sched_unit *unit,
                                     const struct cpumask *hard,
                                     const struct cpumask *soft);
+#ifdef CONFIG_SYSCTL
     int          (*adjust_global)  (const struct scheduler *ops,
                                     struct xen_sysctl_scheduler_op *sc);
+#endif
     void         (*dump_settings)  (const struct scheduler *ops);
     void         (*dump_cpu_state) (const struct scheduler *ops, int cpu);
     void         (*move_timers)    (const struct scheduler *ops,
@@ -510,11 +512,13 @@ static inline int sched_adjust_dom(const struct scheduler *s, struct domain *d,
     return s->adjust ? s->adjust(s, d, op) : 0;
 }
 
+#ifdef CONFIG_SYSCTL
 static inline int sched_adjust_cpupool(const struct scheduler *s,
                                        struct xen_sysctl_scheduler_op *op)
 {
     return s->adjust_global ? s->adjust_global(s, op) : 0;
 }
+#endif
 
 static inline void sched_move_timers(const struct scheduler *s,
                                      struct sched_resource *sr)
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 5ac99904c4..6e1789c314 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -57,7 +57,9 @@ struct xsm_ops {
     int (*domain_create)(struct domain *d, uint32_t ssidref);
     int (*getdomaininfo)(struct domain *d);
     int (*domctl_scheduler_op)(struct domain *d, int op);
+#ifdef CONFIG_SYSCTL
     int (*sysctl_scheduler_op)(int op);
+#endif
     int (*set_target)(struct domain *d, struct domain *e);
     int (*domctl)(struct domain *d, unsigned int cmd, uint32_t ssidref);
     int (*sysctl)(int cmd);
@@ -244,10 +246,12 @@ static inline int xsm_domctl_scheduler_op(
     return alternative_call(xsm_ops.domctl_scheduler_op, d, cmd);
 }
 
+#ifdef CONFIG_SYSCTL
 static inline int xsm_sysctl_scheduler_op(xsm_default_t def, int cmd)
 {
     return alternative_call(xsm_ops.sysctl_scheduler_op, cmd);
 }
+#endif
 
 static inline int xsm_set_target(
     xsm_default_t def, struct domain *d, struct domain *e)
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index d46413ad8c..8d44f5bfb6 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -19,7 +19,9 @@ static const struct xsm_ops __initconst_cf_clobber dummy_ops = {
     .domain_create                 = xsm_domain_create,
     .getdomaininfo                 = xsm_getdomaininfo,
     .domctl_scheduler_op           = xsm_domctl_scheduler_op,
+#ifdef CONFIG_SYSCTL
     .sysctl_scheduler_op           = xsm_sysctl_scheduler_op,
+#endif
     .set_target                    = xsm_set_target,
     .domctl                        = xsm_domctl,
 #ifdef CONFIG_SYSCTL
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 45c12aa662..a7cb33a718 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -626,6 +626,7 @@ static int cf_check flask_domctl_scheduler_op(struct domain *d, int op)
     }
 }
 
+#ifdef CONFIG_SYSCTL
 static int cf_check flask_sysctl_scheduler_op(int op)
 {
     switch ( op )
@@ -640,6 +641,7 @@ static int cf_check flask_sysctl_scheduler_op(int op)
         return avc_unknown_permission("sysctl_scheduler_op", op);
     }
 }
+#endif /* CONFIG_SYSCTL */
 
 static int cf_check flask_set_target(struct domain *d, struct domain *t)
 {
@@ -1887,7 +1889,9 @@ static const struct xsm_ops __initconst_cf_clobber flask_ops = {
     .domain_create = flask_domain_create,
     .getdomaininfo = flask_getdomaininfo,
     .domctl_scheduler_op = flask_domctl_scheduler_op,
+#ifdef CONFIG_SYSCTL
     .sysctl_scheduler_op = flask_sysctl_scheduler_op,
+#endif
     .set_target = flask_set_target,
     .domctl = flask_domctl,
 #ifdef CONFIG_SYSCTL
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 06:51:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 06:51:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016617.1393557 (Exim 4.92)
	(envelope-from )
	id 1uR3gp-0000WU-5F; Mon, 16 Jun 2025 06:51:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016617.1393557; Mon, 16 Jun 2025 06:51: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 1uR3gp-0000WL-0e; Mon, 16 Jun 2025 06:51:31 +0000
Received: by outflank-mailman (input) for mailman id 1016617;
 Mon, 16 Jun 2025 06:51: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 1uR3YR-0008AT-9s
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 06:42:51 +0000
Received: from NAM02-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam02on20618.outbound.protection.outlook.com
 [2a01:111:f403:2405::618])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1e5db3d8-4a7d-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 08:42:50 +0200 (CEST)
Received: from DM6PR12CA0016.namprd12.prod.outlook.com (2603:10b6:5:1c0::29)
 by PH7PR12MB6585.namprd12.prod.outlook.com (2603:10b6:510:213::22) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Mon, 16 Jun
 2025 06:42:43 +0000
Received: from CY4PEPF0000EE38.namprd03.prod.outlook.com
 (2603:10b6:5:1c0:cafe::55) by DM6PR12CA0016.outlook.office365.com
 (2603:10b6:5:1c0::29) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.21 via Frontend Transport; Mon,
 16 Jun 2025 06:42:43 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CY4PEPF0000EE38.mail.protection.outlook.com (10.167.242.10) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Mon, 16 Jun 2025 06:42:43 +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; Mon, 16 Jun 2025 01:42:39 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1e5db3d8-4a7d-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=KcaJn1l/dGt+BpTb4O2+okjS089GXEU5DRxwCb6S02yQABzIIp9pToPmhPtbUXK+WA+lxNlJV0eh5/MhlTIdkOj7G1jp17mQZ+V3blwecRfjMH6psMWvFdA4pkgEzgUrLyw8y/GtUQdn3GB2o4x3bOCnw91cFcDw+XHW4mCmbW9RWb1ZVCO7wp5EqbehOQHSWnIi3hqzC1WdpSMxbFUULFMKpSTeuraVx3KKp3HcNbomzXTH5ZlW214KlJFME+H+PeaFiUs6kt5XYdRUdrYICgnjB1fL57AdwgwcbfdwR5TI1gl3tSByZ7RCZUGSFHbkUZPLqmq58kJQHnrhEvuaug==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=dFLZ7b6gl3GP+IHNPjkhHrTHCTAFBKAP01UJHvvbNv4=;
 b=ZTLQnFBeEv5petbTTzYZze93v3BisjrGgsRZ8Yufxqu2rv8Zx5a6QKgjDAMQNXPodOgzcTtZvEhdUQB0V/8Y9aFbKW6NJtYel2Ihk1dg7Oan4Aso7/QpgU43voVLjcA3Rr+Pj2QC7RtOHO6gQth6tp/pUa0RspfOcXmybNfTBu23uv+YkkkFiq6rjjbhytvpsOyUDpSWn0RmqWq28HdjVHgTennN02exBJ8ZmKmu4/I6cQPLwhVOPvi9eXQ+8+wjBf4Q1blZ9adZjrroN3fcx9/LdBRhJ45nRr6esxZnLmytjlKvKWqxJ61byXo9STZXUqvN5ofjcxCKMgNTzA+LjQ==
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=dFLZ7b6gl3GP+IHNPjkhHrTHCTAFBKAP01UJHvvbNv4=;
 b=TBUFX0eArCWc1Ym7LU7h8hDjW3AwA2kbsA9/O3pDOZOvzovt9zgIlkzh6nC/58KZd/HzVeNvTpSz+9SFVRIfCtk5cP9HqLcC1ncDzXK0MZz1HqpOneVXLA6x2hpio8CD05yOvV1+IfzS0Fl7nZTIR2eoQ7oB4DGDiziveuLcaZI=
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 , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , Alistair Francis
	, Bob Eshleman , "Connor
 Davis" , Oleksii Kurochko
	, Jan Beulich , Andrew Cooper
	, =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, "Stefano Stabellini" ,
	Sergiy Kibrik 
Subject: [PATCH v5 17/18] xen/sysctl: wrap around arch-specific arch_do_sysctl
Date: Mon, 16 Jun 2025 14:41:27 +0800
Message-ID: <20250616064128.581164-18-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250616064128.581164-1-Penny.Zheng@amd.com>
References: <20250616064128.581164-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: CY4PEPF0000EE38:EE_|PH7PR12MB6585:EE_
X-MS-Office365-Filtering-Correlation-Id: a04c1807-ab17-4318-e855-08ddaca0ff2e
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|7416014|376014|82310400026|36860700013|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?IRBiahoJJq1UgpOFXM3QwFQuGw/8eOfnWJGh4k+IzUOa5tn4wVEEMNMj62/h?=
 =?us-ascii?Q?YUxIJLHzj1dAYlvWJofKB50L44N8fXVfqc8cxnQyovnYemlVwmerrxmjNyBl?=
 =?us-ascii?Q?VuGEFRnUlvI04G659rOMaNBSn1TDShQwVzdAbRXSY1fZUwsRyt/lGwHdgtlI?=
 =?us-ascii?Q?x/cQZwdwWBkGzA/Xn1d+v1vTmMXc5Asy5ylFo177D7tBJFy+McRKQwID9LRM?=
 =?us-ascii?Q?G69Y/2FHC18qcAKacVlPbJDqnGk8iXAUyDPbNq7c9ouNedbGeeW/ZdemWmVI?=
 =?us-ascii?Q?caaRFRmhohDOOujOWzIyMTlnHfSXSq11Dl+3sPmgxyAbgORlGagpIQeKbwqR?=
 =?us-ascii?Q?ZguKKGY2lw+k+VYx8/Sp9jzz8KruiAW9TNv+J5vWbE3LM/FLZ4yTMyaDHBNc?=
 =?us-ascii?Q?6VaCtEDZT3wlW3hJlfuZTNqq00UDWIpcVsccjNiCGrhiABPW/I0yWTqPSjIa?=
 =?us-ascii?Q?snbCgn6JdEbxP1iM2suUuXhJN6GqtX/wpY3YjY3nHxW4OOrPmrCdKmOaGl4s?=
 =?us-ascii?Q?UwLGgM+I7MYcUTKPNEv55Fvs6U7+B3pkL66JADkbjZ36FK/pa53vSsdoJ59T?=
 =?us-ascii?Q?ALf+jA1pR9dnR0hRbr2H2cUz+AXm345hXyJyAWN3WwGizcTuTjHE6+gPFzGx?=
 =?us-ascii?Q?tpbUwav1XwZnHo1TW/EzEhbIeHBS1x0cQRwo6HLyUNJ4i+bnAsw13HKr4uQs?=
 =?us-ascii?Q?LAeqm8OT+Vit2nZRgO4QWYUjGJODUjZq/EdUQRxIKvBptq8t+kL+E//PtEvr?=
 =?us-ascii?Q?qPqgMdqWQ3zQb2vll96Amylvs1FZHVSioLamrmkB/vqGpiYSXWexcT8+KKr7?=
 =?us-ascii?Q?/AwOoYgvLIFvod+6SiEy6N/47eAsuPI8P/Mgp0J8sCsapG2AIhhGGhkps04Q?=
 =?us-ascii?Q?Lrx2UId1uXCwzpVLvaQPNB7Ctg8i+2LE1jDmapWvqS0B+ib277rXFqt5RDQR?=
 =?us-ascii?Q?g1ALakbScHnOPh9WALsS0kHuUFn1iyIX0H04eNNyeLrBXZYV94wxIZZkAgQj?=
 =?us-ascii?Q?hMrAwGk6yUGjVaCea9BiEUcyBJC4HzRKMQxYBAc6dT/r4oAWJiyPmHzTNkL2?=
 =?us-ascii?Q?P3TSGhE/S/1b9nFMtrhwzJWDhmPsM97McuJ8LxO/hspI10jJa0dctSuJpKEF?=
 =?us-ascii?Q?XEFjHyvXltIBns+RJmnWWpXLdn8vJuiOoQdVbaYQrARzap9ZQ0+s7sqaLjTl?=
 =?us-ascii?Q?Kyi/4XiqXniAkQLOKzzxWZqz8+tS6q+D6wwEt39cA3aoi3K0wRXhsSaXY79m?=
 =?us-ascii?Q?e0yP76YESDbwd+QrsZ5qbRJ/moE5fAZy1zYWgLNi9/5ghbBh4j6cKFgcL2Bk?=
 =?us-ascii?Q?oxJEF1nN9mTCJZqT5AgJ8MBLptChbaDNINrGF43d5hVJdmNXrYlsPMLDxWqI?=
 =?us-ascii?Q?9R2uTQ/6rv7W40X9wvplup6tTy9SV94/KvPaNGXxXBS7lRdSQYw5b870LL6L?=
 =?us-ascii?Q?7W69XbB51XPz6gw28cQz2X3j1fR5FhJxEUsGQuhc0WUaABJmeOA1r9UBad/N?=
 =?us-ascii?Q?TeMhKnt0MkBaoo34lzV3WwtrDU4weRICxo5O?=
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);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jun 2025 06:42:43.1438
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: a04c1807-ab17-4318-e855-08ddaca0ff2e
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:
	CY4PEPF0000EE38.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6585

Function arch_do_sysctl is to perform arch-specific sysctl op.
Some functions, like psr_get_info() for x86, DTB overlay support for arm,
are solely available through sysctl op, then they all shall be wrapped
with CONFIG_SYSCTL

Also, remove all #ifdef CONFIG_SYSCTL-s in arch-specific sysctl.c, as
we put the guardian in Makefile for the whole file.
Since PV_SHIM_EXCLUSIVE needs sorting in the future, we move
obj-$(CONFIG_SYSCTL) += sysctl.o out of PV_SHIM_EXCLUSIVE condition.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Sergiy Kibrik 
Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
Acked-by: Jan Beulich 
---
v1 -> v2:
- use "depends on" for config OVERLAY_DTB
- no need to wrap declaration
- add transient #ifdef in sysctl.c for correct compilation
---
v2 -> v3:
- move obj-$(CONFIG_SYSCTL) += sysctl.o out of PV_SHIM_EXCLUSIVE condition
- move copyback out of #ifdef
- add #else process for default label
---
v3 -> v4:
- remove transient "#ifdef CONFIG_SYSCTL"
- move #ifdef ahead of the comment
---
 xen/arch/arm/Kconfig   |  1 +
 xen/arch/arm/Makefile  |  2 +-
 xen/arch/arm/sysctl.c  |  2 --
 xen/arch/riscv/stubs.c |  2 +-
 xen/arch/x86/Makefile  |  2 +-
 xen/arch/x86/psr.c     | 18 ++++++++++++++++++
 xen/arch/x86/sysctl.c  |  2 --
 7 files changed, 22 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 3f25da3ca5..e076419d5e 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -139,6 +139,7 @@ config HAS_ITS
 
 config OVERLAY_DTB
 	bool "DTB overlay support (UNSUPPORTED)" if UNSUPPORTED
+	depends on SYSCTL
 	help
 	  Dynamic addition/removal of Xen device tree nodes using a dtbo.
 
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index ab0a0c2be6..f833cdf207 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -51,7 +51,7 @@ obj-y += setup.o
 obj-y += shutdown.o
 obj-y += smp.o
 obj-y += smpboot.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/arm/sysctl.c b/xen/arch/arm/sysctl.c
index 2d350b700a..32cab4feff 100644
--- a/xen/arch/arm/sysctl.c
+++ b/xen/arch/arm/sysctl.c
@@ -15,7 +15,6 @@
 #include 
 #include 
 
-#ifdef CONFIG_SYSCTL
 void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
 {
     pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm | XEN_SYSCTL_PHYSCAP_hap;
@@ -23,7 +22,6 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
     pi->arch_capabilities |= MASK_INSR(sve_encode_vl(get_sys_vl_len()),
                                        XEN_SYSCTL_PHYSCAP_ARM_SVE_MASK);
 }
-#endif
 
 long arch_do_sysctl(struct xen_sysctl *sysctl,
                     XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c
index f86a1c17cb..8918cebf35 100644
--- a/xen/arch/riscv/stubs.c
+++ b/xen/arch/riscv/stubs.c
@@ -302,6 +302,7 @@ unsigned long raw_copy_from_guest(void *to, const void __user *from,
     BUG_ON("unimplemented");
 }
 
+#ifdef CONFIG_SYSCTL
 /* sysctl.c */
 
 long arch_do_sysctl(struct xen_sysctl *sysctl,
@@ -310,7 +311,6 @@ long arch_do_sysctl(struct xen_sysctl *sysctl,
     BUG_ON("unimplemented");
 }
 
-#ifdef CONFIG_SYSCTL
 void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
 {
     BUG_ON("unimplemented");
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index ce724a9daa..96d63219e7 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -63,6 +63,7 @@ obj-y += smpboot.o
 obj-y += spec_ctrl.o
 obj-y += srat.o
 obj-y += string.o
+obj-$(CONFIG_SYSCTL) += sysctl.o
 obj-y += time.o
 obj-y += traps-setup.o
 obj-y += traps.o
@@ -78,7 +79,6 @@ ifneq ($(CONFIG_PV_SHIM_EXCLUSIVE),y)
 obj-y += domctl.o
 obj-y += platform_hypercall.o
 obj-$(CONFIG_COMPAT) += x86_64/platform_hypercall.o
-obj-y += sysctl.o
 endif
 
 extra-y += asm-macros.i
diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index 5815a35335..499d320e61 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -133,9 +133,11 @@ static const struct feat_props {
      */
     enum psr_type alt_type;
 
+#ifdef CONFIG_SYSCTL
     /* get_feat_info is used to return feature HW info through sysctl. */
     bool (*get_feat_info)(const struct feat_node *feat,
                           uint32_t data[], unsigned int array_len);
+#endif
 
     /* write_msr is used to write out feature MSR register. */
     void (*write_msr)(unsigned int cos, uint32_t val, enum psr_type type);
@@ -418,6 +420,7 @@ static bool mba_init_feature(const struct cpuid_leaf *regs,
     return true;
 }
 
+#ifdef CONFIG_SYSCTL
 static bool cf_check cat_get_feat_info(
     const struct feat_node *feat, uint32_t data[], unsigned int array_len)
 {
@@ -430,6 +433,7 @@ static bool cf_check cat_get_feat_info(
 
     return true;
 }
+#endif /* CONFIG_SYSCTL */
 
 /* L3 CAT props */
 static void cf_check l3_cat_write_msr(
@@ -442,11 +446,14 @@ static const struct feat_props l3_cat_props = {
     .cos_num = 1,
     .type[0] = PSR_TYPE_L3_CBM,
     .alt_type = PSR_TYPE_UNKNOWN,
+#ifdef CONFIG_SYSCTL
     .get_feat_info = cat_get_feat_info,
+#endif
     .write_msr = l3_cat_write_msr,
     .sanitize = cat_check_cbm,
 };
 
+#ifdef CONFIG_SYSCTL
 /* L3 CDP props */
 static bool cf_check l3_cdp_get_feat_info(
     const struct feat_node *feat, uint32_t data[], uint32_t array_len)
@@ -458,6 +465,7 @@ static bool cf_check l3_cdp_get_feat_info(
 
     return true;
 }
+#endif /* CONFIG_SYSCTL */
 
 static void cf_check l3_cdp_write_msr(
     unsigned int cos, uint32_t val, enum psr_type type)
@@ -473,7 +481,9 @@ static const struct feat_props l3_cdp_props = {
     .type[0] = PSR_TYPE_L3_DATA,
     .type[1] = PSR_TYPE_L3_CODE,
     .alt_type = PSR_TYPE_L3_CBM,
+#ifdef CONFIG_SYSCTL
     .get_feat_info = l3_cdp_get_feat_info,
+#endif
     .write_msr = l3_cdp_write_msr,
     .sanitize = cat_check_cbm,
 };
@@ -489,11 +499,14 @@ static const struct feat_props l2_cat_props = {
     .cos_num = 1,
     .type[0] = PSR_TYPE_L2_CBM,
     .alt_type = PSR_TYPE_UNKNOWN,
+#ifdef CONFIG_SYSCTL
     .get_feat_info = cat_get_feat_info,
+#endif
     .write_msr = l2_cat_write_msr,
     .sanitize = cat_check_cbm,
 };
 
+#ifdef CONFIG_SYSCTL
 /* MBA props */
 static bool cf_check mba_get_feat_info(
     const struct feat_node *feat, uint32_t data[], unsigned int array_len)
@@ -508,6 +521,7 @@ static bool cf_check mba_get_feat_info(
 
     return true;
 }
+#endif /* CONFIG_SYSCTL */
 
 static void cf_check mba_write_msr(
     unsigned int cos, uint32_t val, enum psr_type type)
@@ -545,7 +559,9 @@ static const struct feat_props mba_props = {
     .cos_num = 1,
     .type[0] = PSR_TYPE_MBA_THRTL,
     .alt_type = PSR_TYPE_UNKNOWN,
+#ifdef CONFIG_SYSCTL
     .get_feat_info = mba_get_feat_info,
+#endif
     .write_msr = mba_write_msr,
     .sanitize = mba_sanitize_thrtl,
 };
@@ -808,6 +824,7 @@ static struct psr_socket_info *get_socket_info(unsigned int socket)
     return socket_info + socket;
 }
 
+#ifdef CONFIG_SYSCTL
 int psr_get_info(unsigned int socket, enum psr_type type,
                  uint32_t data[], unsigned int array_len)
 {
@@ -839,6 +856,7 @@ int psr_get_info(unsigned int socket, enum psr_type type,
 
     return -EINVAL;
 }
+#endif /* CONFIG_SYSCTL */
 
 int psr_get_val(struct domain *d, unsigned int socket,
                 uint32_t *val, enum psr_type type)
diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c
index f64addbe2b..1b04947516 100644
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -91,7 +91,6 @@ static long cf_check smt_up_down_helper(void *data)
     return ret;
 }
 
-#ifdef CONFIG_SYSCTL
 void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
 {
     memcpy(pi->hw_cap, boot_cpu_data.x86_capability,
@@ -105,7 +104,6 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
     if ( IS_ENABLED(CONFIG_SHADOW_PAGING) )
         pi->capabilities |= XEN_SYSCTL_PHYSCAP_shadow;
 }
-#endif /* CONFIG_SYSCTL */
 
 long arch_do_sysctl(
     struct xen_sysctl *sysctl, XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 06:51:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 06:51:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016627.1393566 (Exim 4.92)
	(envelope-from )
	id 1uR3gw-00011o-Ct; Mon, 16 Jun 2025 06:51:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016627.1393566; Mon, 16 Jun 2025 06:51: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 1uR3gw-00011W-9v; Mon, 16 Jun 2025 06:51:38 +0000
Received: by outflank-mailman (input) for mailman id 1016627;
 Mon, 16 Jun 2025 06:51: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 1uR3Y5-0008AT-GG
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 06:42:29 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on2062b.outbound.protection.outlook.com
 [2a01:111:f403:2413::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 105e7502-4a7d-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 08:42:26 +0200 (CEST)
Received: from CYXPR03CA0033.namprd03.prod.outlook.com (2603:10b6:930:d2::10)
 by DS0PR12MB8042.namprd12.prod.outlook.com (2603:10b6:8:141::9) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.28; Mon, 16 Jun
 2025 06:42:22 +0000
Received: from CY4PEPF0000EE3B.namprd03.prod.outlook.com
 (2603:10b6:930:d2:cafe::9) by CYXPR03CA0033.outlook.office365.com
 (2603:10b6:930:d2::10) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.28 via Frontend Transport; Mon,
 16 Jun 2025 06:42:22 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CY4PEPF0000EE3B.mail.protection.outlook.com (10.167.242.14) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Mon, 16 Jun 2025 06:42:22 +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; Mon, 16 Jun 2025 01:42:19 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 105e7502-4a7d-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=fwjKeKpuhSW+Za8Z4m3fix9CR5bTk3k2T45biUhGH75+IS93z3Ls3ycCmgDYA4+PP5dGCg2Yku8Cz9pxBKF6VnIMy2ZPtLtXnT9l0PR47x8ED/aKqN+2dUk81sqqn3rey66Jtg2+FMOaq8sYwbzr40Pdmo2X8N5v7TsAZkawmbH0GI+GZmL90HtWjCnZ55JsR0A3eh+rVxnOeyaJG2RCNPRlbZNa330zrW92mUMIfhNL1+l1E6fgRy8FIW5yqc5qo58gTSFOes5bwoxZDXw5QbrL0xL/XIvRds2dSTLSRafbA6OTreI7meZZfRT7NKs3t73zJjcVdkPsSIGPqYiZOw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=GoizLHkC9hrssFkuA6tARof3m6ES0g4Ie5FyhWkflVM=;
 b=nk0vVvVZQJ+6Qo2xpFL3oV3Fz73RKd5WxysRBtLFtSDBEufsoxv4cnA19laMoERlCskF2qqDg9Gb8FNMk/UBGbmzcY6hStFv2WfMtVfJEywfrxolbX82F47cOdV+gSY+W3P8XiftGGgZ2DZcyaUOtWbfQOzlTae/hxuYa7meYdCMJ53YO6ehOWs+citjBdiJhklNT7vYVcf47u/zrE5HCyHBNQVUxI521LLaQGVOVbsUtHbgO1pXqb6F0/A6ZaFOICjuTCdUBYmRkGrGAleNt/D39VMEMbFtBUDag/7p3Eh/7rME5MyirBtth8MCndmDxnqGi7WQvtRKmtX3zt+uNQ==
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=GoizLHkC9hrssFkuA6tARof3m6ES0g4Ie5FyhWkflVM=;
 b=Ns7JNVW1T+kzP/0Tj7sG8U8Kao0ycXs2X2W/f1dBR0/4EO4Gv6KqSGVDGsAAVYjpU7ihZfl91MM/QpHx0GEgCIAcZefR4aiF6sb2TbZE5IVUA7YAiL9V//51mFLhlZ92OICQTOzbTIJo7EKl6+L8+Avwm1ySSBnMQ1jHX0VSMCk=
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?= , Anthony PERARD
	, Michal Orzel , "Julien
 Grall" , Stefano Stabellini 
Subject: [PATCH v5 10/18] xen/sysctl: introduce CONFIG_PM_STATS
Date: Mon, 16 Jun 2025 14:41:20 +0800
Message-ID: <20250616064128.581164-11-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250616064128.581164-1-Penny.Zheng@amd.com>
References: <20250616064128.581164-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: CY4PEPF0000EE3B:EE_|DS0PR12MB8042:EE_
X-MS-Office365-Filtering-Correlation-Id: b716294d-ed1b-41f3-6748-08ddaca0f29f
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?x9h4FfCBcrCkDav5pEspxr8Y45avs+oSeB2HOjgFfB/EdPl17YS2m50WXDwp?=
 =?us-ascii?Q?qyi8js4Y5cosVlphoXbHBf9tood7f5uAVAnNX8LMwNXF/hXQMkmXdA6z12vd?=
 =?us-ascii?Q?l73Noyf7aNW8nqa3RAvEAl7vbUWPT3iU13FwCG1EPNCLnUK1ahtLBQiL6gHi?=
 =?us-ascii?Q?nHi9F4Zu1LaUHDqGd47cceWpjQ/WAADov3HoHEOD+ZoztoIoieENIUheEjLY?=
 =?us-ascii?Q?uX0C0oG8YEAbKdDVNtyeZ4/K8BJVlIH6/RvwOJ3TtfBWLa3BwWqPwCII+Rqh?=
 =?us-ascii?Q?61X54pSqae/JpmLE2GJhmgF6W3K9sFFB3d8NzShEjKTP+PFpftM/XKQLdGMR?=
 =?us-ascii?Q?5bUhC/4ndesXch+5QgSBapeuTWMQKtnCYK+g1zfgvC9iKlVe6VTULLI7krq7?=
 =?us-ascii?Q?UYYrzP7PkWUh2AHH7kI/j8DHrhuJ7dsij4A6DWaRo+kLlbSyVfkfg3J39r7e?=
 =?us-ascii?Q?IZvOCSHpaFIhW2rHgAEGhLm3B7f5wEhWYWCsMVdICZkUur1yOCo1t/5bYaZo?=
 =?us-ascii?Q?eexPg5anlq9Kdh4NZWpGp/o1TeZ59hqf517CrDG1mg+SonBZdscXrpeYVYwN?=
 =?us-ascii?Q?1v2yNawW9larfv2YFpSqBmsliQC9uTs9szRCm16Qob2W5oZTl4jL4dUnuVj+?=
 =?us-ascii?Q?hXcGkHItNausrVw5/zvJTfSOCm4FsJiY+EzHc9TP6ISrr+FJLkjdZlnbYyPj?=
 =?us-ascii?Q?mP9YXek86CBPyyOufGOR7OPguUOv0guHJbJR1p5hj+pcLlIRT893JveAMJhV?=
 =?us-ascii?Q?ydgSsd1MW6p7wC+qCTyIuePCxbV/1DRO+ZmmwWd+DPQ1mD6qAPIsyhVSIjgT?=
 =?us-ascii?Q?fVsU7YYxxmpnBRMe5Q9ZaUC3Jhk7aF6N0YwE13wU9OKfJnAFtUHx9q07XIGF?=
 =?us-ascii?Q?79HZPJkSQPX+tZve4zxlKLRYlPaVdi2lpIs2p/UwxrjeJUPdEjlquhgBwHq2?=
 =?us-ascii?Q?/e3r285tyVQldIYZ848MdDA5M6MUbqmMnyPHoho3r9zyH5wHTFS7Y2raD0jo?=
 =?us-ascii?Q?BqD6MAiRgDVeOdiAqvzppjzZGxIr+6UaGb4fdQbG91v/IYpcNHUJnmN830KV?=
 =?us-ascii?Q?spbmJwnJ2HRAqihXaCkiflaXJjj95Flial8ZO/u6aCxTA5T/JKP+JO6ROMdZ?=
 =?us-ascii?Q?s98xCtzMJBgnu/IzByhpnjv0l40KMS84RqE458qgqegCPKkL/HoUnHfg4gky?=
 =?us-ascii?Q?N1nw7jf1EH5nuROVs53bqrowSi+dIpYdt3NjKq9OSTw1+Eryr2iQ1wJdvTbj?=
 =?us-ascii?Q?Byci6OuJOdZNGaGAscRVdM8ck7KrtqHlqKPJEPB82b5FaIF7wvyToGAjTANu?=
 =?us-ascii?Q?6P8nOya5b++M2xB0/oSUWLgyPZzidksOb4A75ApwYxSSLqA4VrXOyo/59hN2?=
 =?us-ascii?Q?3YiT1KGNgmAF6yR0BsHSNQYFqXKOlIbmeNIz7mwXFeIjXK5WNC8+e5rcCy0a?=
 =?us-ascii?Q?tpSNvPPaqr3I+SCuKENZtcS7FIMg2iu+wSBoiBOHd/SlBWsSW6mlQ9pjDmG2?=
 =?us-ascii?Q?Jf5/INlZIulefa4I35EaysLmQIzBmVN5KIBO?=
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: 16 Jun 2025 06:42:22.0759
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b716294d-ed1b-41f3-6748-08ddaca0f29f
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:
	CY4PEPF0000EE3B.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB8042

We introduce a new Kconfig CONFIG_PM_STATS for wrapping all operations
regarding performance management statistics.
The major codes reside in xen/drivers/acpi/pmstat.c, including the
pm-statistic-related sysctl op: do_get_pm_info().
CONFIG_PM_STATS also shall depend on CONFIG_SYSCTL

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
Acked-by: Jan Beulich 
---
v1 -> v2:
- rename to CONFIG_PM_STATS
- fix indention and stray semicolon
- make code movements into a new commit
- No need to wrap inline functions and declarations
---
v2 -> v3:
- sepearte functions related to do_pm_op() into a new commit
- both braces shall be moved to the line with the closing parenthesis
---
v3 -> v4:
- be consistent with the comment on the #endif
---
v4 -> v5
- add blank line before endmenu
---
 xen/arch/x86/acpi/cpu_idle.c              |  2 ++
 xen/common/Kconfig                        |  8 ++++++++
 xen/common/sysctl.c                       |  2 +-
 xen/drivers/acpi/Makefile                 |  2 +-
 xen/include/acpi/cpufreq/processor_perf.h | 10 ++++++++++
 5 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/acpi/cpu_idle.c
index 1dbf15b01e..974d81b4d6 100644
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -1493,6 +1493,7 @@ static void amd_cpuidle_init(struct acpi_processor_power *power)
         vendor_override = -1;
 }
 
+#ifdef CONFIG_PM_STATS
 uint32_t pmstat_get_cx_nr(unsigned int cpu)
 {
     return processor_powers[cpu] ? processor_powers[cpu]->count : 0;
@@ -1612,6 +1613,7 @@ int pmstat_reset_cx_stat(unsigned int cpu)
 {
     return 0;
 }
+#endif /* CONFIG_PM_STATS */
 
 void cpuidle_disable_deep_cstate(void)
 {
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 943cf0a950..998e672fa7 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -628,4 +628,12 @@ config PM_OP
 	  This option shall enable userspace performance management control
 	  to do power/performance analyzing and tuning.
 
+config PM_STATS
+	bool "Enable Performance Management Statistics"
+	depends on ACPI && HAS_CPUFREQ && SYSCTL
+	default y
+	help
+	  Enable collection of performance management statistics to aid in
+	  analyzing and tuning power/performance characteristics of the system
+
 endmenu
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index daf57fbe56..5207664252 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -170,7 +170,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
         op->u.availheap.avail_bytes <<= PAGE_SHIFT;
         break;
 
-#if defined (CONFIG_ACPI) && defined (CONFIG_HAS_CPUFREQ)
+#ifdef CONFIG_PM_STATS
     case XEN_SYSCTL_get_pmstat:
         ret = do_get_pm_info(&op->u.get_pmstat);
         break;
diff --git a/xen/drivers/acpi/Makefile b/xen/drivers/acpi/Makefile
index 1d811a51a7..477408afbe 100644
--- a/xen/drivers/acpi/Makefile
+++ b/xen/drivers/acpi/Makefile
@@ -5,7 +5,7 @@ obj-$(CONFIG_X86) += apei/
 obj-bin-y += tables.init.o
 obj-$(CONFIG_ACPI_NUMA) += numa.o
 obj-y += osl.o
-obj-$(CONFIG_HAS_CPUFREQ) += pmstat.o
+obj-$(CONFIG_PM_STATS) += pmstat.o
 obj-$(CONFIG_PM_OP) += pm-op.o
 
 obj-$(CONFIG_X86) += hwregs.o
diff --git a/xen/include/acpi/cpufreq/processor_perf.h b/xen/include/acpi/cpufreq/processor_perf.h
index 6de43f8602..a9a3b7a372 100644
--- a/xen/include/acpi/cpufreq/processor_perf.h
+++ b/xen/include/acpi/cpufreq/processor_perf.h
@@ -9,9 +9,19 @@
 
 unsigned int powernow_register_driver(void);
 unsigned int get_measured_perf(unsigned int cpu, unsigned int flag);
+#ifdef CONFIG_PM_STATS
 void cpufreq_statistic_update(unsigned int cpu, uint8_t from, uint8_t to);
 int  cpufreq_statistic_init(unsigned int cpu);
 void cpufreq_statistic_exit(unsigned int cpu);
+#else
+static inline void cpufreq_statistic_update(unsigned int cpu, uint8_t from,
+                                            uint8_t to) {}
+static inline int cpufreq_statistic_init(unsigned int cpu)
+{
+    return 0;
+}
+static inline void cpufreq_statistic_exit(unsigned int cpu) {}
+#endif /* CONFIG_PM_STATS */
 
 int  cpufreq_limit_change(unsigned int cpu);
 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 06:52:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 06:52:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016650.1393577 (Exim 4.92)
	(envelope-from )
	id 1uR3hO-0002DS-M7; Mon, 16 Jun 2025 06:52:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016650.1393577; Mon, 16 Jun 2025 06: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 1uR3hO-0002DL-IL; Mon, 16 Jun 2025 06:52:06 +0000
Received: by outflank-mailman (input) for mailman id 1016650;
 Mon, 16 Jun 2025 06: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 1uR3YK-0008AT-PG
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 06:42:44 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20614.outbound.protection.outlook.com
 [2a01:111:f403:2417::614])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1a2116e8-4a7d-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 08:42:42 +0200 (CEST)
Received: from PH7P220CA0038.NAMP220.PROD.OUTLOOK.COM (2603:10b6:510:32b::21)
 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.8835.29; Mon, 16 Jun
 2025 06:42:35 +0000
Received: from CY4PEPF0000EE3A.namprd03.prod.outlook.com
 (2603:10b6:510:32b:cafe::ca) by PH7P220CA0038.outlook.office365.com
 (2603:10b6:510:32b::21) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.28 via Frontend Transport; Mon,
 16 Jun 2025 06:42:34 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CY4PEPF0000EE3A.mail.protection.outlook.com (10.167.242.12) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Mon, 16 Jun 2025 06:42: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; Mon, 16 Jun 2025 01:42:29 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1a2116e8-4a7d-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=PKjT1ndByP//M8rFHWQE582hF/30/TCl+rgNEJbH7H3Em0mPvapD7k6Y6ewnv0jzcH8JhyRj/5rPMyuIVIUdmCeZNbqiiBlTJyIaP3G96V8358soqE+5XSzxGcA5o5eSc2JrT9oOc8C1q004/yp3AvwFpYy9j5pmasSZbWzvgFOWPHaZCfvqVBECtcDuQsQIxXbv0iw0Hb/k9sFWFLxSPoenZoYUPCdAHxNYM7O8ir2nqX6Q//xukzDjAqmB3+aRW6eOyAuez4lwwu3LPdkVt27avBxLmYVYnR/wLoPZ8wBEEkvPOu+RzZMdZfa9o91PyTeOJ2k+nDF6mAqTBEGKOQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=3uc/bKe0ZCt/bgI6oHn77LOKodpngQIQmpimP9vAyxM=;
 b=mMFvkVHLS/U5ln8BNFoQyPwhcz4Qjjs5H5WDVK5alMumdtF102FSM0wSnc4gWDoPHhfSsBHa3mBQd2B0A9Gk/2GNZ5lVooWL5gg1N1gW+JaxxbDHh0wE/UM9KU23ZAw4JOatNtzguWyI2zrF4/11nXJ7G+8YM/rgPZgBO1Xt9v2LWXZwx5x8Ie08SAFmaSRIeLqPOl7xiCTXrDhJxqEUwE7O29Jc9enmnSegUdqiyzygvYLMI3+5hyZwqkOYP6OiuF9J5+Dkn3FywdtFB9Kccaz4CBi5pfX6QyEg5MleHWJrkbFR5G0MvxqR9G0L0HtelKgk15V/naq88iWMAx69cg==
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=3uc/bKe0ZCt/bgI6oHn77LOKodpngQIQmpimP9vAyxM=;
 b=CrIyVFWLBSTgGEFYwG4zOOxVeQmasaFcaJLKY93XyTToMBdz9ylBeIMFQ70+1Ha4dJizCOH+74N1xiSHi9wFBimZFnOVo+BaJa2H+qtwG9fECs1glOm11LthrJDdhIPqSo30ZVvnUUQAueEr56sOYL7OWNKbjPdHqBOozwcXUnU=
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 , 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 
Subject: [PATCH v5 14/18] xen/sysctl: wrap around XEN_SYSCTL_physinfo
Date: Mon, 16 Jun 2025 14:41:24 +0800
Message-ID: <20250616064128.581164-15-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250616064128.581164-1-Penny.Zheng@amd.com>
References: <20250616064128.581164-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: CY4PEPF0000EE3A:EE_|CH3PR12MB7572:EE_
X-MS-Office365-Filtering-Correlation-Id: 4a2cf989-4196-4d31-7dad-08ddaca0f9a4
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|7416014|376014|82310400026|36860700013|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?nxY+vf7oazKJkWncovIqEFvpQpG/sus6XBiBDdb0MqU3RKco5wqraTtxB8Cq?=
 =?us-ascii?Q?cJgqL7R7uBSPz9a9qfFoBGZQdajDq8YDydC0VImx1yGuALbu2Hy3UyYoy4FZ?=
 =?us-ascii?Q?GLaPw5lDScUHlELyLOynB3403XtznnMRmLJx6JpNdF8vO8fNCysf4vFCjZsy?=
 =?us-ascii?Q?YAd92tangbRYqmbEx8LK1b/YCUFKdK9Lv4cAO+HMouecaPZr/zG55XZURQAC?=
 =?us-ascii?Q?w7GlEHB2qRnMZtuN4HOzSVfiFdMybVHeeI064slOZ9+mmKlLXsegfLE5wrXg?=
 =?us-ascii?Q?nnKl2lGCbAMu9c+TYTdUZGaZI0hzf0LKxBCQYcPurwaL8ireLKwocFh5+soB?=
 =?us-ascii?Q?lICZDqs81pMyMrC7jEqY8EpePY+oZYl/Sgs7lchIcJHdbS+PNsDLGpmAHFpS?=
 =?us-ascii?Q?W9Pz6NPaWIoiyqCVlqdbGMHeS+GF5+6qNas/0Zt6ENnGMLEv2mBVAJxBZjkO?=
 =?us-ascii?Q?h0kIzpKhsfd5WfdKgBWAwUkK2U3tpqaFH6uC98b25QlexeSuv00XnolAWBol?=
 =?us-ascii?Q?PwowNuTNizuxSWe0HpCX1H5uxW8CRVajWgQyhG1scohZXLQsKFN7tvHkbL68?=
 =?us-ascii?Q?eeQ0+TEOgguzRKFpXCN3j4MVcN7jJ/yVfOn1tFG3Y6hT6jS0eC8bgVb3pA/J?=
 =?us-ascii?Q?T+YGLnTQtJH/qkUVkGl9XX8mKoJL9iMp4ciV0xOA5NC0k0B/3Z0ciM3PVTdq?=
 =?us-ascii?Q?jnqeINQSaNz+uQTl+icpP8E/+gf9tmSzKQ2G+JE0KEf1fS/afnb+xU4f+gJx?=
 =?us-ascii?Q?Gd7pXoYMakYoLLPM0I2IfMhrEWUc4QQb4FyDKMIp0tJ8C0PjHetFpJF4OkqB?=
 =?us-ascii?Q?8Pecg9fhTrRbwxQi4ysOycT/SrINvVrOnC9je52fmEpeomrIBtHhEQ4QbRma?=
 =?us-ascii?Q?2jYW10Ggw+Cspdx7trwTmv1ErfVm0s6mXlDSnxXgwqf+0KpICRLDNyrAONHl?=
 =?us-ascii?Q?HIIwPxB1gSIp2T2Du8KqDfKG+oVXhRu9nRyQoypawtT9IUxVOzBvpcXlojfE?=
 =?us-ascii?Q?CnrAZRJ0feu/ggJ/upnmdJ61WQ/+/LnUOx442myBEqE3f+J+qC2HMmoqgYP+?=
 =?us-ascii?Q?Icro4lIQVqP96xoclVIjINdvszdxBcG7vVcjEmSRsWTOaUIdos98tnMRu7xP?=
 =?us-ascii?Q?QwKuUMPDQk1XnuvNODvKZc/FEA4CsK7yPPzr9Y32xpvgs5k01YxePtKHAo8H?=
 =?us-ascii?Q?/7YJA2dEsLA+oY1WWEhFuaHV2eCQNkgjDHCybxplEUtNc/kcOm3ZKs24LSaX?=
 =?us-ascii?Q?R0V8VV+2t6PhDmLM3XlDRtMs3MQtp5voQhDy1AgGU93N6uVNjn4d52HuMYuH?=
 =?us-ascii?Q?uZYW2VgThvCBPatckJIYBQaVFGqooMRr7KcnH+h4nrpI1uXGm+lr3FehgXhk?=
 =?us-ascii?Q?8jD44mXSE1c8SZBE7DECNb7O8wSMEFWyxut03GBw69sRf2TM+fUdpLRVIE5c?=
 =?us-ascii?Q?It4Y9waewRMYLSlhrqqfC7gMNaOvEiUgVXnI+XlT5cy9v2k+XFcGzKWbsNoC?=
 =?us-ascii?Q?YeLsPNwEMzOwM6oQHh3MzFU7/0LXrtn4i+9i?=
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);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jun 2025 06:42:33.8486
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 4a2cf989-4196-4d31-7dad-08ddaca0f9a4
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:
	CY4PEPF0000EE3A.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB7572

The following functions are only used to deal with XEN_SYSCTL_physinfo,
then they shall be wrapped:
- arch_do_physinfo()
- get_outstanding_claims()

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
Acked-by: Jan Beulich 
---
v1 -> v2:
- no need to wrap declaration
- add transient #ifdef in sysctl.c for correct compilation
---
v2 -> v3:
- move #endif up ahead of the blank line
---
v3 -> v4:
- remove transient "#ifdef CONFIG_SYSCTL"
---
 xen/arch/arm/sysctl.c   | 2 ++
 xen/arch/riscv/stubs.c  | 2 ++
 xen/arch/x86/sysctl.c   | 2 ++
 xen/common/page_alloc.c | 2 ++
 4 files changed, 8 insertions(+)

diff --git a/xen/arch/arm/sysctl.c b/xen/arch/arm/sysctl.c
index 32cab4feff..2d350b700a 100644
--- a/xen/arch/arm/sysctl.c
+++ b/xen/arch/arm/sysctl.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 
+#ifdef CONFIG_SYSCTL
 void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
 {
     pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm | XEN_SYSCTL_PHYSCAP_hap;
@@ -22,6 +23,7 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
     pi->arch_capabilities |= MASK_INSR(sve_encode_vl(get_sys_vl_len()),
                                        XEN_SYSCTL_PHYSCAP_ARM_SVE_MASK);
 }
+#endif
 
 long arch_do_sysctl(struct xen_sysctl *sysctl,
                     XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c
index e396b67cd3..f86a1c17cb 100644
--- a/xen/arch/riscv/stubs.c
+++ b/xen/arch/riscv/stubs.c
@@ -310,10 +310,12 @@ long arch_do_sysctl(struct xen_sysctl *sysctl,
     BUG_ON("unimplemented");
 }
 
+#ifdef CONFIG_SYSCTL
 void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
 {
     BUG_ON("unimplemented");
 }
+#endif /* CONFIG_SYSCTL */
 
 /* p2m.c */
 
diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c
index 1b04947516..f64addbe2b 100644
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -91,6 +91,7 @@ static long cf_check smt_up_down_helper(void *data)
     return ret;
 }
 
+#ifdef CONFIG_SYSCTL
 void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
 {
     memcpy(pi->hw_cap, boot_cpu_data.x86_capability,
@@ -104,6 +105,7 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
     if ( IS_ENABLED(CONFIG_SHADOW_PAGING) )
         pi->capabilities |= XEN_SYSCTL_PHYSCAP_shadow;
 }
+#endif /* CONFIG_SYSCTL */
 
 long arch_do_sysctl(
     struct xen_sysctl *sysctl, XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index dec4cb2ab1..8177d12f50 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -601,6 +601,7 @@ out:
     return ret;
 }
 
+#ifdef CONFIG_SYSCTL
 void get_outstanding_claims(uint64_t *free_pages, uint64_t *outstanding_pages)
 {
     spin_lock(&heap_lock);
@@ -608,6 +609,7 @@ void get_outstanding_claims(uint64_t *free_pages, uint64_t *outstanding_pages)
     *free_pages = avail_heap_pages(MEMZONE_XEN + 1, NR_ZONES - 1, -1);
     spin_unlock(&heap_lock);
 }
+#endif /* CONFIG_SYSCTL */
 
 static bool __read_mostly first_node_initialised;
 #ifndef CONFIG_SEPARATE_XENHEAP
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 06:52:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 06:52:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016651.1393587 (Exim 4.92)
	(envelope-from )
	id 1uR3hY-0002dR-0u; Mon, 16 Jun 2025 06:52:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016651.1393587; Mon, 16 Jun 2025 06:52:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uR3hX-0002dD-Te; Mon, 16 Jun 2025 06:52:15 +0000
Received: by outflank-mailman (input) for mailman id 1016651;
 Mon, 16 Jun 2025 06: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 1uR3Y9-0008AT-FQ
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 06:42:33 +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 14e80e5c-4a7d-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 08:42:33 +0200 (CEST)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-606fdbd20afso8406771a12.1
 for ; Sun, 15 Jun 2025 23:42:33 -0700 (PDT)
Received: from ?IPV6:2003:e5:872a:8800:5c7b:1ac1:4fa0:423b?
 (p200300e5872a88005c7b1ac14fa0423b.dip0.t-ipconnect.de.
 [2003:e5:872a:8800:5c7b:1ac1:4fa0:423b])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-adec8153529sm592184866b.23.2025.06.15.23.42.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 15 Jun 2025 23:42:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 14e80e5c-4a7d-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750056152; x=1750660952; 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=AYFCQ6WsVUgyRd9/IeuXOI9XFmcm/xfYT+Apb/Pdycw=;
        b=J8HsgQTLFVDTtsecjMJRpZR0zcxIks+AXi12KUWMLXxK1pCFM7F6PvJrHt7vIXAZ1H
         t/z15WD9N15C+RIJFWXZOWNSL4Aa7qno3wZDUtd8FRo2QFvj2CNUi8PdhdQzJcbD6ASL
         Y5M3ssaE0JC/QzVLNhBI4SQm4rWu9JrxpwbMc9ypjbetGNF/ybjASPINXqcdOsx60Rrr
         irA2QQ2ScN1tE4iX0Ze0ks2oIbHMGYuJynSZOnhWZcp6UMGVkyHFuSK8VOSVRTtIhBqr
         GaO69aihRBASv9tU2CxIJt2fHN2J2lkUGuanvvf3ZI6JqrfxZkgA6gnbyaHSrmmzKl6f
         Hv8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750056152; x=1750660952;
        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=AYFCQ6WsVUgyRd9/IeuXOI9XFmcm/xfYT+Apb/Pdycw=;
        b=ex8XEKX+YjP0w8Y0GNsG4XYumLTxH8HoSUfkV2UOCeWmjjvTAzcQmRl6Oqla53++/b
         xciGq6fCUz37F3rSI9vvlZXt/Z9PSm3bDfv48OcXVxp2oYOt8zVtv4MV76lcBZ2m2MCJ
         QW1q5fvKc/1vWgeCuM23KFNXSDIHiKjxZE5NjRq5G1CzSgcxt4olAkjxLELVZ2aCe96J
         lAWTr+o8wa7MyG5db7JqqGVquDdHY76y5d4sI+p/OkmkwlFcgIvAv0X6eEiuXs8vF7DO
         NGikMm/Y78CycmDTu2053fo33NEvJvuPBu2y3qmXRaWo4x/Hy9RLYB9NZVOWOybQtwQm
         oH1w==
X-Forwarded-Encrypted: i=1; AJvYcCWFsum47nuOInqnuQ7qlbknTBZvR4y7izlHaHd9hBh9kQyPxrKt75lOEGvh3Tv8nBPRbxJ5PaLQZXc=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx9LqVYm0XVe478Kk/xLjIjEiRYzVgFxRc/G+3wiuLd3ozuJMCx
	64F8231VmmrWQXc3m5hQTCGAVfm0793k3w0S1VevoUQ50n6beLeU8is+7CC2yzJuEi8=
X-Gm-Gg: ASbGncuj+/JqfAZElpvMmcQ64yWzbm8IRNLJTdG5WRUKDYfvrBUDf9JDwhyH25Z4lPU
	6FeKmwAkOCw9ju6vxwMg8T2AfnlBYfgNFcYQMC+Xo6lNBZeWtPK2UzGyk/3lvXTE3qsMZenbHfg
	JiXK1Wfp/5DVhvZMHuNddbpcu9gzIGGr3lPmlVeUOBgga6RT3cEpIejWw7iB9R+1gGZbn7kptJR
	TSekGFRgztZelOMlhk0bj8BNQ/dYwHJcRP9vvqXd+S/d5QaDSiheFUuMEi8K7intv9S45iYUNrE
	/0M3Zk6XHk3EZjzh3ib/4+NzEhdBQMkk5DkRqB0uUBd34U9hZ0e5wf21iL3iXflcI4tJGvKtH7H
	1qR0rVpY/Ts9Yb05E7Ua60u16ku7snSptQ1DXn3mJjbrZ0ZLexS5Fplik5KAgj0Cs+ExKOBwVs9
	IoNRxsX7uVncU=
X-Google-Smtp-Source: AGHT+IE/bXr2uJdQLzAl8b0T1zSu9r244BZnep6cbbNI/lbBzJSIA5JcB+5JVCevI+SLAkxffBIs7A==
X-Received: by 2002:a17:907:7e92:b0:adb:2e9f:5d11 with SMTP id a640c23a62f3a-adfad4515f3mr607055566b.37.1750056152469;
        Sun, 15 Jun 2025 23:42:32 -0700 (PDT)
Message-ID: <11e127a7-ce8d-4704-b7ce-33dd998a4a54@suse.com>
Date: Mon, 16 Jun 2025 08:42:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [MINI-OS PATCH 04/12] kexec: analyze new kernel for kexec
To: Jason Andryuk 
Cc: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org,
 samuel.thibault@ens-lyon.org
References: <20250321092451.17309-1-jgross@suse.com>
 <20250321092451.17309-5-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="------------aA8WnijPMm071xk0705UBV1k"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------aA8WnijPMm071xk0705UBV1k
Content-Type: multipart/mixed; boundary="------------w0G0OEvnL1hFS01Ak0zeLU29";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Jason Andryuk 
Cc: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org,
 samuel.thibault@ens-lyon.org
Message-ID: <11e127a7-ce8d-4704-b7ce-33dd998a4a54@suse.com>
Subject: Re: [MINI-OS PATCH 04/12] kexec: analyze new kernel for kexec
References: <20250321092451.17309-1-jgross@suse.com>
 <20250321092451.17309-5-jgross@suse.com>
 
In-Reply-To: 

--------------w0G0OEvnL1hFS01Ak0zeLU29
Content-Type: multipart/mixed; boundary="------------9PGHRtoGNhO3chPi8ugDJbgB"

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

T24gMTQuMDYuMjUgMTg6NDEsIEphc29uIEFuZHJ5dWsgd3JvdGU6DQo+IE9uIEZyaSwgTWFy
IDIxLCAyMDI1IGF0IDU6MjXigK9BTSBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+
IHdyb3RlOg0KPj4NCj4+IEFuYWx5emUgdGhlIHByb3BlcnRpZXMgb2YgdGhlIG5ldyBrZXJu
ZWwgdG8gYmUgbG9hZGVkIGJ5IGtleGVjLiBUaGUNCj4+IGRhdGEgbmVlZGVkIGlzOg0KPj4N
Cj4+IC0gdXBwZXIgYm91bmRhcnkgaW4gZmluYWwgbG9jYXRpb24NCj4+IC0gY29weSBhbmQg
bWVtb3J5IGNsZWFyIG9wZXJhdGlvbnMNCj4+IC0gZW50cnkgcG9pbnQgYW5kIGVudHJ5IHBh
cmFtZXRlcg0KPj4NCj4+IFNpZ25lZC1vZmYtYnk6IEp1ZXJnZW4gR3Jvc3MgPGpncm9zc0Bz
dXNlLmNvbT4NCj4gDQo+PiArDQo+PiArc3RhdGljIHZvaWQgY2hlY2tfbm90ZXNfZW50cnko
ZWxmX2VoZHIgKmVoZHIsIHZvaWQgKnN0YXJ0LCB1bnNpZ25lZCBpbnQgbGVuKQ0KPiANCj4g
SSB0aGluayB5b3Ugc2hvdWxkIHJlbmFtZSB0aGlzIHRvIGluY2x1ZGUgcmVhZF8gc2luY2Ug
aXQgaXMgbmVjZXNzYXJ5DQo+IHRvIHNldCBrZXJuZWxfZW50cnkuICByZWFkX3BoeXMzMl9l
bnRyeV9ub3RlKCkgb3INCj4gcmVhZF9ub3RlX2tlcm5lbF9lbnRyeSgpIG9yIHNvbWUgdmFy
aWF0aW9uLiAgVG8gbWUsIGNoZWNrXyBpbXBsaWVzIGENCj4gYm9vbGVhbiByZXR1cm4gd2l0
aG91dCBhIHNpZGUgZWZmZWN0Lg0KDQpJJ2xsIGdvIHdpdGggcmVhZF9ub3RlX2VudHJ5KCku
DQoNCj4gDQo+PiBAQCAtNTQsOSArNTcsMTIyIEBADQo+PiAgICAqIC0gVGhlIG5ldyBrZXJu
ZWwgaXMgYWN0aXZhdGVkLg0KPj4gICAgKi8NCj4+DQo+PiAtaW50IGtleGVjKHZvaWQgKmtl
cm5lbCwgdW5zaWduZWQgbG9uZyBrZXJuZWxfc2l6ZSwNCj4+IC0gICAgICAgICAgY29uc3Qg
Y2hhciAqY21kbGluZSkNCj4gDQo+PiAraW50IGtleGVjKHZvaWQgKmtlcm5lbCwgdW5zaWdu
ZWQgbG9uZyBrZXJuZWxfc2l6ZSwgY29uc3QgY2hhciAqY21kbGluZSkNCj4gDQo+IE5JVDog
aW50cm9kdWNlIGtleGVjKCkgd2l0aCB0aGUgc2luZ2xlIGxpbmUgZm9ybSB0byBhdm9pZCBj
aGFuZ2luZyBpdA0KPiANCj4gRXZlcnl0aGluZyBlbHNlIGxvb2tzIGdvb2QsIHNvIHByZWZl
cmFibHkgd2l0aCB0aGUgcmVuYW1pbmc6DQo+IA0KPiBSZXZpZXdlZC1ieTogSmFzb24gQW5k
cnl1ayA8amFzb24uYW5kcnl1a0BhbWQuY29tPg0KDQpUaGFua3MsDQoNCg0KSnVlcmdlbg0K

--------------9PGHRtoGNhO3chPi8ugDJbgB
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-----

--------------9PGHRtoGNhO3chPi8ugDJbgB--

--------------w0G0OEvnL1hFS01Ak0zeLU29--

--------------aA8WnijPMm071xk0705UBV1k
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/Ey8FAmhPvNcFAwAAAAAACgkQsN6d1ii/Ey8Z
3Qf/chJd6vUDgMEz6Wr0ThCYubZhMOSeAdiyklSX1fWIJtQCIKGPG+bMgl7jyZzKBntF07u4lBNQ
Taixlr0oGhS0RvWlLKmqCNLLsPdgdgXmkH8Ffd3kgul3EuJ5S4UzDuCDv0ZwBd+IvBQD9wx2jKKc
dWdiwy+s+1cI2dYounoZpvpja2Tb2ccNDwxSOtIBVr/i4hdfxfe38hRZzWjdzj+2eiYisRv6flTp
2EtVZtaets/0OGqKqQrIsoXDL/6ZaxgX/bYGNmmOb30COBLJjpG1zHYOfehh6R0AyBRCjxlhlcI7
VGsMlr69u4YQ2PoQ3C+2L8jn5BcOLHjFFy0UEletHg==
=FN4F
-----END PGP SIGNATURE-----

--------------aA8WnijPMm071xk0705UBV1k--


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 06:52:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 06:52:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016652.1393597 (Exim 4.92)
	(envelope-from )
	id 1uR3hZ-0002tc-8z; Mon, 16 Jun 2025 06:52:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016652.1393597; Mon, 16 Jun 2025 06:52: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 1uR3hZ-0002sz-5N; Mon, 16 Jun 2025 06:52:17 +0000
Received: by outflank-mailman (input) for mailman id 1016652;
 Mon, 16 Jun 2025 06:52: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 1uR3Y7-0008OL-Qs
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 06:42:31 +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 12c37c43-4a7d-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 08:42:29 +0200 (CEST)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-606ddbda275so8168079a12.1
 for ; Sun, 15 Jun 2025 23:42:29 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-608b4ae4d18sm5401396a12.76.2025.06.15.23.42.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 15 Jun 2025 23:42:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 12c37c43-4a7d-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750056149; x=1750660949; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Y6Ixgi/lQfgC2ZOBDfuYOmHvXWJTuvopOJwaR7ysKb0=;
        b=WX09HKwk1WHW+ACFlQV7hpSEuquKM79vVU6DUge5pUDlIV81C60inV09M7AL13OJJV
         7/PSn8FFF9HXWAcuRO2P/za6R+NloxxBonxm7sBven5jN8vXQXApGFAfgxz9G42565Fe
         uc0Gi+H/5lwgI0nSMNv3egCpuBlo9F+R+05pc9vzO3taaag94yThCzkPK2Urjrv1zTKS
         aEPaqXaHAthV2tnEqNbJqopXLhzldBH2k2pvhcgQq5dRq6cMtFByR2dbICBJ4lXThg9x
         bb34Xsl8zVOhUq5DfzTM2lyUUhVQOMBhspSUdVrksMCjNKL9FrmECT7hnODpi9w889go
         2dFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750056149; x=1750660949;
        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=Y6Ixgi/lQfgC2ZOBDfuYOmHvXWJTuvopOJwaR7ysKb0=;
        b=XyOwAYo68dNT534oXD9iBy1gqdOyDdmghN3p1BqewZnXhctGCYzunaQyo8xAGo0acH
         xSBJUVpgsgsXgpkU8lZ/3vhm9iLwKqVQdpWC3C7RSkxzj7jF1fh0mPcGWtlYzEqMLi9R
         owGNjfJWQOJDjb3iHGYf2/SsxwDqkzjg1oZyzSvRihmRY1HndBPcHiR6NQlj+KhfxlC8
         uLmsJb7AeMx6GO1+Z5+1fCx/s7WX+fZiBTkFuM86yB2Hxv1mZZlpqIrO8AyvNVR01DRY
         ljq4oQ531nv5s6UwaVL/2IqlUJ+abQOvjx9IwrE5d5zjA8dIG1nmpIHn+AocqpkDaulF
         ye5A==
X-Forwarded-Encrypted: i=1; AJvYcCXfmPoDUycfXZI06ZPfrJywG0crnFCtLipp56H6WxISD7ytwg2QyHUVf5t3/ayntgE4EnsjRf66h9s=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxzp5wf/H4mD2xPGjlutkhMFK/FYTkgWrSJQ6u9lYA93SVCx8ux
	gDXkimADktkgFjQntKtT29X/7J3+AERtdmUswB+j+WLDbxFZBSWtLZjACFdz2uFG0g==
X-Gm-Gg: ASbGncs7/UXsovUScmx8yPmYZffrOZLcx3XR4mlOP0F+wBAqSGGs+Q6r+Ub+z3g1yPd
	w9xyTnx3Hs6LtLnxEIrRcy9D0SNAQDVAteN+55fFATy3OA9t0P2EhtGI/OiusOJdvUEl1FfMB4b
	q4MDXSHOuZ8EpWSpXHL9NAFd73wgGiOKJU4Rt8SlzhQ6YZtdMNMLFDFMGIEOiA3jlhKIhvIFZ9a
	BCR+1GgzGnkl61ufR5XO+PqNg3EvXaupjl1f8qQfS3bz5wWHXL59kUzInWrVWrHwFQvwyOrs+rj
	pFsUakVOZHE0VRoi2VE3WdAzWMeYZVXhWbRwqL0dP0ebgO1LNpbr8JuWREFBs1at4X3YrdDkFkq
	p9TfQV9XddmZP/m2jf5fowxNhbq4QxWkfQWlC/GgmVZKTiZw=
X-Google-Smtp-Source: AGHT+IH4MjH+3C2i1Lf/yexWSVdTiqU+BK2jLxxtTbw9ny9EgGU3UI/+1v/W6qveSN3ABoVsUcZlNA==
X-Received: by 2002:a05:6402:1d49:b0:607:783e:5970 with SMTP id 4fb4d7f45d1cf-608d0861911mr6934357a12.8.1750056148983;
        Sun, 15 Jun 2025 23:42:28 -0700 (PDT)
Message-ID: <3ecf10e5-5df7-4348-85a1-b8eecb940bf8@suse.com>
Date: Mon, 16 Jun 2025 08:42:29 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v8] xen/arm: pci: introduce PCI_PASSTHROUGH Kconfig option
To: Stewart Hildebrand 
Cc: Rahul Singh ,
 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: <20250613154847.317979-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: <20250613154847.317979-1-stewart.hildebrand@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.06.2025 17:17, Stewart Hildebrand wrote:
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -8,6 +8,8 @@ config ARM_64
>  	depends on !ARM_32
>  	select 64BIT
>  	select HAS_FAST_MULTIPLY
> +	select HAS_VPCI_GUEST_SUPPORT if PCI_PASSTHROUGH
> +	select HAS_PASSTHROUGH if PCI_PASSTHROUGH

Seeing this, I like this as little as I liked ...

> @@ -258,6 +260,12 @@ config PARTIAL_EMULATION
>  
>  source "arch/arm/firmware/Kconfig"
>  
> +config PCI_PASSTHROUGH
> +	bool "PCI passthrough" if EXPERT
> +	depends on ARM_64

... the form with the select-s put here. I'll (obviously) leave it to the
Arm maintainers to judge, but my recommendation would be to simply drop
this patch. As per the description it's merely "make it easier ...",
which imo doesn't warrant such an abuse of HAS_*.

As a nit: The select-s also would better be sorted alphabetically.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 06:52:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 06:52:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016660.1393608 (Exim 4.92)
	(envelope-from )
	id 1uR3hl-0003bv-Kh; Mon, 16 Jun 2025 06:52:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016660.1393608; Mon, 16 Jun 2025 06:52:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uR3hl-0003aq-FY; Mon, 16 Jun 2025 06:52:29 +0000
Received: by outflank-mailman (input) for mailman id 1016660;
 Mon, 16 Jun 2025 06:52: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 1uR3Y9-0008OL-3f
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 06:42:33 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20621.outbound.protection.outlook.com
 [2a01:111:f403:2416::621])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1325f776-4a7d-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 08:42:31 +0200 (CEST)
Received: from DM6PR07CA0130.namprd07.prod.outlook.com (2603:10b6:5:330::22)
 by MW3PR12MB4394.namprd12.prod.outlook.com (2603:10b6:303:54::20) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Mon, 16 Jun
 2025 06:42:27 +0000
Received: from CY4PEPF0000EE3E.namprd03.prod.outlook.com
 (2603:10b6:5:330:cafe::c3) by DM6PR07CA0130.outlook.office365.com
 (2603:10b6:5:330::22) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.24 via Frontend Transport; Mon,
 16 Jun 2025 06:42:27 +0000
Received: from SATLEXMB04.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.8835.15 via Frontend Transport; Mon, 16 Jun 2025 06:42: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; Mon, 16 Jun 2025 01:42:24 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1325f776-4a7d-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=h2RSQDnh23ayiLacUsiVdd0D6yfHBJ4n4kK8u7vMZuQIHgM1nEuSWFhUYBxclcaJkAA1IYIlprN6MsFi2i79p08eXQDQa29Kf8dcXF9zF/k3+ZgVA7JS6T5jG5GFdNoXfuTRz+amm6/0a1E88UMWZFkPFiReSTwG4RLqXIplG9pJb3j4W+F/6mj9dC+hkWX+xR2JnXR4YKkQ6lylShyX96FXP7eq1KW48l/C3Mnt9fe7HjuSf6DAUsWQ0QZIM62Kee96l9y8JPcwGwjlz3k9AhySYS4tLEPp0lt8Y+PJfyUB2N7uyxC9LktRFjSRCgahFl4lfb0xONTKFPNkuOmLdw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=IdgLxZJojMqTzA4uMqMuY2FrEHyVqR+LGLe1iCymvs4=;
 b=fwvtP2lwAJLF0jPayVMmPsFH4OvuDXDEvPZdDYIEYAH/2dBPLyFNmR0Ki7U228MWbcdfajeBViMtv1Ubc2iubjKtK5rWs0g1IM/1r85CYZzWiblbm8sRl+dZc1vNgcnLtzIhTmKU5eitvbBNLnw0oMlQcWPcZdVlKA0O8JKc/HnyepjNOBOJGDRosCxDO1P3NXv4W0mkEt7+zT8Zafuifglj8mSvTw77m202CZik8+UJiDd9N2WNPqtofpHxDPYASMVZaYFSOuq++Ulgu6yseSvH6takdD3ZDPT4V3E72/HP6b2PFNFmCNTMnDe7j6kJnfYm/ykUfKbBP6p7AFlxrw==
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=IdgLxZJojMqTzA4uMqMuY2FrEHyVqR+LGLe1iCymvs4=;
 b=iEw6oTT+nAEvpvNJ+dWwzji9G75ZHhRg3iCErln2PmtF5cvWdDGiZnCdcv0Tss8MUnZ5a6oPqXb6Sf3tx/zanRdzAuDQPjr1v0bySy44F43TH5BhWo0e6dwQe543qAykE7eJyK297oETcCXc7WYPqvw+/TJeuaCcKAs6iqYiZLw=
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 , Dario Faggioli
	, Juergen Gross , George Dunlap
	, Stefano Stabellini 
Subject: [PATCH v5 12/18] xen/sysctl: wrap around XEN_SYSCTL_cpupool_op
Date: Mon, 16 Jun 2025 14:41:22 +0800
Message-ID: <20250616064128.581164-13-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250616064128.581164-1-Penny.Zheng@amd.com>
References: <20250616064128.581164-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: CY4PEPF0000EE3E:EE_|MW3PR12MB4394:EE_
X-MS-Office365-Filtering-Correlation-Id: d2ac9b0a-e7e0-4a13-a6e1-08ddaca0f583
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?N7TrkZdxomMqq82l6RULfjzfDJ25xuBU194jIsNbKuCoFQeMa7a5FOwKrCQA?=
 =?us-ascii?Q?968QETWEA2f5J1hvbN+tzIHnz67EqzXwP20FDB3tty+Cnm0pjvzhv1ZBnDvl?=
 =?us-ascii?Q?TUOFCAk+c+lJFrsQ7V6PkNZ21/XfOjuHQtvRNi/TyPMLTtimUgdo9Z9l26dx?=
 =?us-ascii?Q?obKoFiJAAWwQqE8lRaovgygT0/R6FvIK5c+S1hx+h9e3arrhMsE5XeBrhKGd?=
 =?us-ascii?Q?lOluQDAj0ef/jdjE3dfC/Y5u75/wll1m+EikGgaVmoYC5rR4wfGc/7YdK71v?=
 =?us-ascii?Q?tnBTanHA2z2/Gt2xLhjSADb01lixN6dwlUZyV+68T7K7B334EgJkLgtAAHeA?=
 =?us-ascii?Q?96k4/eTqKtxtfmDmq51vTQdxoP5sHgMEHVCXOFQXHjYNDEc2j53/6cw3Bi/L?=
 =?us-ascii?Q?swXxlSaIEsBURPlsq8CVIC8C1wEvSRQjqBzLJnb7PgHN1dG1Xp2WAN2NQzmp?=
 =?us-ascii?Q?uM9qM5FvfFzB9LAew6zTwck8D38DPzXNjhjTLm6XAHz2GCfh3k34kykWzVXJ?=
 =?us-ascii?Q?fOpEWHFm3fihfLDFoAdJfFSNrNQZGh0HYXgdbuTruAKhnmmwyjGnp6JvHus1?=
 =?us-ascii?Q?ZWg1kh8KWxAnQs2y64wm6iB4AKQ5sidzhiJyV32vUOgiXJNQtDG/585pBd8h?=
 =?us-ascii?Q?QwZkro+KM8z4bNEQDWPVIZqro0SPzwyuLMfeF74tJ2xhZw2qEXH5oSjTLMI0?=
 =?us-ascii?Q?W4iNi5ajVXnZi1qOLJcu5hPpI/tUfSjqm6k9fEyUHQNuweTtTQvCzRJyQvul?=
 =?us-ascii?Q?hSU9ejDsfXHrIxMUTRzc+JIeSFLDfH0Z5XntJLtDBqBXCR4HhU+DfozJOr2d?=
 =?us-ascii?Q?3ZmBEq9dilG4VFd+99lLBTvMO3Rf4EFMHNI7pwMLyfhR7hrLzBGvstb4hfOe?=
 =?us-ascii?Q?3dQGvbMR7mvBlPOSMEejfbIF5ctI0oIUJenq0IvbFz2Qv7Rwu+xg9d3iIEAR?=
 =?us-ascii?Q?0UjjUx30tLJb8UCi3/5pPx5o/ChD341Hw6MtMH1/bbfnP+FPpq6o699Scln5?=
 =?us-ascii?Q?NnX++1uDUpR7LXEvRZ8VtIWkprgNOmP0JB3wc9wC8ZyBMpUPXrG7VW/Qv3ia?=
 =?us-ascii?Q?7czLdn//wPznf75uFZn+EUGxg9Qm6qdSITae6GubmnGp1tGEggLTeNDtxSBQ?=
 =?us-ascii?Q?NpDoipjna6G9yECpHbHOXb+aZvrZgkf/xAEvjuhzu7RnCXD0gNu7HqfI43MZ?=
 =?us-ascii?Q?9Uem3u+wk+GNdzRPKSPdTswby19XM7Wbl8OD6Vz9KtmpFG4BXbxCowjKt4TG?=
 =?us-ascii?Q?OOlEl54oaoIVN4VOrFlkJnygjYlus56Q3xxuZgcOPEmhmp6FdJAoxigb/HIL?=
 =?us-ascii?Q?YwKkxmgfpteVBAsTsQjm0dE+PuLQytkZfGYyZ4xRECSbHmqJZL0wvNSSHXG2?=
 =?us-ascii?Q?MLxyzb4EYaU7xcwfQ8tQzL4/yUt3g5sUpT6mCkrLadTBpDEQ+csEMbje2qBV?=
 =?us-ascii?Q?RiKISGYKgEOytlW+V26pdIcsHHfSxrDgpk8EShCt3fG9QIXey9vD8b4+XMxH?=
 =?us-ascii?Q?oUorZ0Y/BcjFiG87KfJ/90IG/Wo4EpqUSx27?=
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: 16 Jun 2025 06:42:26.9220
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d2ac9b0a-e7e0-4a13-a6e1-08ddaca0f583
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:
	CY4PEPF0000EE3E.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR12MB4394

Function cpupool_do_sysctl is designed for doing cpupool related sysctl
operations, and shall be wrapped.

The following static functions are only called by cpupool_do_sysctl(), then
shall be wrapped too:
- cpupool_get_next_by_id
- cpupool_destroy
- cpupool_unassign_cpu_helper
- cpupool_unassign_cpu

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
---
v1 -> v2:
- no need to wrap declaration
- add transient #ifdef in sysctl.c for correct compilation
---
v2 -> v3
- move #endif up ahead of the blank line
---
v3 -> v4:
- remove transient "#ifdef CONFIG_SYSCTL"
---
 xen/common/sched/cpupool.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/xen/common/sched/cpupool.c b/xen/common/sched/cpupool.c
index 3d02c7b706..f5459c2779 100644
--- a/xen/common/sched/cpupool.c
+++ b/xen/common/sched/cpupool.c
@@ -241,10 +241,12 @@ struct cpupool *cpupool_get_by_id(unsigned int poolid)
     return __cpupool_get_by_id(poolid, true);
 }
 
+#ifdef CONFIG_SYSCTL
 static struct cpupool *cpupool_get_next_by_id(unsigned int poolid)
 {
     return __cpupool_get_by_id(poolid, false);
 }
+#endif /* CONFIG_SYSCTL */
 
 void cpupool_put(struct cpupool *pool)
 {
@@ -352,6 +354,7 @@ static struct cpupool *cpupool_create(unsigned int poolid,
 
     return ERR_PTR(ret);
 }
+#ifdef CONFIG_SYSCTL
 /*
  * destroys the given cpupool
  * returns 0 on success, 1 else
@@ -379,6 +382,7 @@ static int cpupool_destroy(struct cpupool *c)
     debugtrace_printk("cpupool_destroy(pool=%u)\n", c->cpupool_id);
     return 0;
 }
+#endif /* CONFIG_SYSCTL */
 
 /*
  * Move domain to another cpupool
@@ -568,6 +572,7 @@ static int cpupool_unassign_cpu_start(struct cpupool *c, unsigned int cpu)
     return ret;
 }
 
+#ifdef CONFIG_SYSCTL
 static long cf_check cpupool_unassign_cpu_helper(void *info)
 {
     struct cpupool *c = info;
@@ -633,6 +638,7 @@ static int cpupool_unassign_cpu(struct cpupool *c, unsigned int cpu)
     }
     return continue_hypercall_on_cpu(work_cpu, cpupool_unassign_cpu_helper, c);
 }
+#endif /* CONFIG_SYSCTL */
 
 /*
  * add a new domain to a cpupool
@@ -810,6 +816,7 @@ static void cpupool_cpu_remove_forced(unsigned int cpu)
     rcu_read_unlock(&sched_res_rculock);
 }
 
+#ifdef CONFIG_SYSCTL
 /*
  * do cpupool related sysctl operations
  */
@@ -975,6 +982,7 @@ int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op)
 
     return ret;
 }
+#endif /* CONFIG_SYSCTL */
 
 unsigned int cpupool_get_id(const struct domain *d)
 {
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 06:52:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 06:52:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016661.1393612 (Exim 4.92)
	(envelope-from )
	id 1uR3hl-0003fK-UD; Mon, 16 Jun 2025 06:52:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016661.1393612; Mon, 16 Jun 2025 06:52:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uR3hl-0003ex-Nn; Mon, 16 Jun 2025 06:52:29 +0000
Received: by outflank-mailman (input) for mailman id 1016661;
 Mon, 16 Jun 2025 06:52: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 1uR3YM-0008OL-5v
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 06:42:46 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20600.outbound.protection.outlook.com
 [2a01:111:f403:2414::600])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1b42808c-4a7d-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 08:42:44 +0200 (CEST)
Received: from PH0PR07CA0032.namprd07.prod.outlook.com (2603:10b6:510:e::7) by
 IA1PR12MB7519.namprd12.prod.outlook.com (2603:10b6:208:418::22) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Mon, 16 Jun
 2025 06:42:40 +0000
Received: from CY4PEPF0000EE39.namprd03.prod.outlook.com
 (2603:10b6:510:e:cafe::ff) by PH0PR07CA0032.outlook.office365.com
 (2603:10b6:510:e::7) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.21 via Frontend Transport; Mon,
 16 Jun 2025 06:42:39 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CY4PEPF0000EE39.mail.protection.outlook.com (10.167.242.11) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Mon, 16 Jun 2025 06:42: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; Mon, 16 Jun 2025 01:42:36 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1b42808c-4a7d-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ZYP9fV3paS2Tlz56scLoanfwVAOpYFbJ0r/ynirTVelVl5UaQ0HYKNKAcfmp3XPK5zBe+6vuuEgl1n2/JfQBz936vx6ZaNbGojpX6Vq0uIvuZu1uaTjyt/ChplxmiYsABaUI2d7UvnR/NSaa0u+E2XG+ro6lEoXol8Ov56m2/+WM4xJjFfOoSsw/kL189O+dqPj17CskKvxZzIpDvcBvDu8i+gf0GYnGoU9XalgksnuNEldjEvQRJIi+u32V1XkUVBUKCb+2ZB7Pc2X3rfAgzUpWo56eFnvfBVIFfh8j6LpngnzH2jF5qzkU/I9FtlDDvdlzLn4I77aHvaSTPPhfuA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=XwJhrnnb+2MW/ne4s8eBK/wVf0i4fVNoPwNCu0hf/gQ=;
 b=pldeJ2jsfHOT491HG5xpseqxRRGD/gfBWhduaV4j/HT5ZyuliPPotDjLCWWen5rG9VT7kVIffZWU1hLMaGzQKkG9CoQPt/QjnfyVNNsHxTGXT2/LaTbPXMIzAEpGeg4eWJpRPTfR7q6rafzG6cEpUmJQHuM4tTh2uGdjSjpWKLDNUzYVOFaOqUbK1uHKGKhTDkqdRoh3ZC0cMH9rPZb+Y0QJvy2xphHnT/xGyiqxWHF1oo+JeKSDA7vD7polateTegZ/v7N7mcl58g27NVaYK1UtlI2LHd6cqmWNwbzt4Qto1jemlc6reHCBdj6FJMAamjiwIZRcjsyIbXnPkcRy4Q==
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=XwJhrnnb+2MW/ne4s8eBK/wVf0i4fVNoPwNCu0hf/gQ=;
 b=h4NSw7ZzQakB2qEsw3z4kvNHSAq9ia7Z2ZxhJwOcW0+C2VgEBEqnMeN8Vd/W0mxAKehY+f/NJzu0h6qQAYJDsO8wWsjQol8bTSw5iiR1obDIPYWYhwhJabbeDYzNxhKOmLFBpU2c7xddppb8Waiimz7KWqIyMYprOq9Bb3KnINI=
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
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , "Julien
 Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Stefano Stabellini 
Subject: [PATCH v5 16/18] xen/sysctl: make CONFIG_LIVEPATCH depend on CONFIG_SYSCTL
Date: Mon, 16 Jun 2025 14:41:26 +0800
Message-ID: <20250616064128.581164-17-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250616064128.581164-1-Penny.Zheng@amd.com>
References: <20250616064128.581164-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: CY4PEPF0000EE39:EE_|IA1PR12MB7519:EE_
X-MS-Office365-Filtering-Correlation-Id: 8e9c2d25-fa40-486d-d0fb-08ddaca0fcc2
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?zNtPxSMtMXi9I7N4GfqluPnMolpPKH2wyc8YvmYT4g3W+VGI3c0YGmanrRTZ?=
 =?us-ascii?Q?5IHMAN5/5O1dB1R403nVdOt9OILcwPFDcMKjHvUf3NUwlFfILG8PXFpt5jVp?=
 =?us-ascii?Q?6OK197aiLhpCaNITGhwzJCUiPoXbsMQyINjkA3MeRzMFGWgEaxnfP+jALC5H?=
 =?us-ascii?Q?8d+7vZa1YASNF2BZmsiDKHEPN3FiXD/J8+YAxIFwAJihe9q+X7QyZOBKB5Ey?=
 =?us-ascii?Q?lBYTuyRKhNSmeQXLR18RJw1FFg6zaUq9DJfCNS3AmWpLkQdL8IRKqTih5CvP?=
 =?us-ascii?Q?iyUNTM/4mORRAe0qPi72fv4t2613kQhKukf1LL5ij2MDHTW2tScuDvrT5zbH?=
 =?us-ascii?Q?8HhgQVdJr0KjpZ2px2eBjyLE7VTo4oGUQp17mtl2243gA+oLJq2jDqFX7/T2?=
 =?us-ascii?Q?shtPlzb9laNriwvOqkZ9JPFzuztj/02jWn0pRsS1GcxRKlF1UtCl+xyd0NIF?=
 =?us-ascii?Q?Q4zTYDNq2H4ePBt6B7QkFfFw9Gm3gg+H9uuhy0ez3SxaKWrE/87hfYeA/fjA?=
 =?us-ascii?Q?Y48z1mCqgUC1VhhXcxVdPKPlQXR8Cg0wScCXfgclER8xKCZAfPoPGdetalMf?=
 =?us-ascii?Q?5RxWhNlUD+YXIIaURdZ7KXvWJeG9SMXKRH5ll2utj+UIryUfXLSqp08BILn9?=
 =?us-ascii?Q?Sy+hARU2qv05gUkJ39QeI4iHEjg+rBLvlwZLPrhUT211HbbfX6AldAr+rP2m?=
 =?us-ascii?Q?uWyuBvHr6hrPrQdzqI0tjeE/GBtTf5DN8gldTYlRV9aHhGRaoopN39gdZ3Ln?=
 =?us-ascii?Q?YrJMGFy+T9x/zMc0YXdzWHHsJ9f91tCzU/ZC4tfs5TUkZzOR3TU19zwgGmix?=
 =?us-ascii?Q?Lg9gc0H17qff5tM2hvQ6wQnPAB9BAzM7HCallh3g3OgG7XObiQcbECM5z5Fx?=
 =?us-ascii?Q?FSQ8M3fZZaY6xtrqHhD7d7p6Zg8LySUVHQJ+TjYpfM+OF1rYdy3aMKieH0k5?=
 =?us-ascii?Q?wuYjXweaEGvyC4FnvNc/+o5/5BzQadS+q3beTiVz1mCkrsNh7coyNTO6gu1u?=
 =?us-ascii?Q?Di69UqRHJ/wWW8pkYiIKa7Gck7LgdyFHc+fsTMxv+yb7cxtFpr3pwYYRrOce?=
 =?us-ascii?Q?JHO/EH31Xh2PHdVZVc5azb4GmfgATw8gzVnRHqMRmD+3BaDpPGDC4ZIlsDOF?=
 =?us-ascii?Q?LcVHrniPJ+44t5jeF1Xsbo+waGv1BdiyUYEYfTAeL8/2xmaq44v3iD2td2uW?=
 =?us-ascii?Q?0JmtTdrFZYh18QD7DQoUpNjRO+x6Y8avtSdy/uFKqFS3YtWTgm6wm+/RCeGH?=
 =?us-ascii?Q?s4v3loCcHJU0odzdUC++AqUazb3TVG54X+LmEib7XvPNMOnUILwYeP9+sXpX?=
 =?us-ascii?Q?KpB2+S2iQETw46RpVJ1eMG6nLLKPLY+hDVHPC2bFdgyr4MFaRNc6qbOrMW/S?=
 =?us-ascii?Q?GxtvlKiUHAQ1IsCQSEREmaTBIyB5xELYHNtnyhLpo8vWsibmlxEU2Nh4/DsF?=
 =?us-ascii?Q?cHPZhYfCuMil7c5DJ2OME7mQHW9G4GliZ8H6C28lMlqJZxUVAsf8V3g01vPG?=
 =?us-ascii?Q?dT+RdgQKFWc5VnVVaUfUN27aXCbDFaEo4OJu?=
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: 16 Jun 2025 06:42:39.0806
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 8e9c2d25-fa40-486d-d0fb-08ddaca0fcc2
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:
	CY4PEPF0000EE39.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB7519

LIVEPATCH mechanism relies on LIVEPATCH_SYSCTL hypercall, so CONFIG_LIVEPATCH
shall depend on CONFIG_SYSCTL

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
---
v1 -> v2:
- commit message refactor
---
 xen/common/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 998e672fa7..65f07289dd 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -472,7 +472,7 @@ config CRYPTO
 config LIVEPATCH
 	bool "Live patching support"
 	default X86
-	depends on "$(XEN_HAS_BUILD_ID)" = "y"
+	depends on "$(XEN_HAS_BUILD_ID)" = "y" && SYSCTL
 	select CC_SPLIT_SECTIONS
 	help
 	  Allows a running Xen hypervisor to be dynamically patched using
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 06:55:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 06:55:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016678.1393627 (Exim 4.92)
	(envelope-from )
	id 1uR3kb-0005EJ-J9; Mon, 16 Jun 2025 06:55:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016678.1393627; Mon, 16 Jun 2025 06:55: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 1uR3kb-0005EC-F0; Mon, 16 Jun 2025 06:55:25 +0000
Received: by outflank-mailman (input) for mailman id 1016678;
 Mon, 16 Jun 2025 06:55: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 1uR3ka-0005E6-9z
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 06:55:24 +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 e00afe5c-4a7e-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 08:55:23 +0200 (CEST)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-6086502e750so7971173a12.3
 for ; Sun, 15 Jun 2025 23:55:23 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-608b48a8477sm5509939a12.6.2025.06.15.23.55.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 15 Jun 2025 23:55:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e00afe5c-4a7e-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750056923; x=1750661723; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=tzd93xJPRh+kyC2FiwEWVtguxpYX3lOmg5FXJ/gN6Cs=;
        b=LBSc0rpTtoSV1vzRqFIJJvYVyquM54aDqsuf2QKRvuZLDSInHOy9hli/qHuFqSkx/s
         pCZGHo+pXAsdkO/00QYw7p8ry9rBdo+1297K0YW+vTgkbXARfLLuq9KEpX9fb+9uCAhP
         aAjeYSthosL8HgSmslLQXWLafQh3sxN6BOuWl964hUQrmK5fP2yqWl20NhatZxGOsnXR
         gm5NNh9RS2MOq2Pm8s0KG9f1zl3egOCKJwnstwq6GOZ6tRf50QnpZiRhZMEVwk+ggV8Z
         Js8Oybf/srE5kAS0e/F2GbzABn66Pli9uO75fiQxs5OvGmy1xK2dhvgNtGGSvyjJK1Vi
         y4xg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750056923; x=1750661723;
        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=tzd93xJPRh+kyC2FiwEWVtguxpYX3lOmg5FXJ/gN6Cs=;
        b=Dbi7ivFdzaNqI7QvBOC7ea6EneY4mBt0P65xFyxJeJPc5EMlAsGSPYi5OOH+/xM5JY
         3GxPFDwliPm3o/rExeCS80Re/ddRsm++OGdO+WotTZsL1s4lDuM3UkDh1uhkr1P1cOVj
         DxMQQYr5UWTokMlV3zzsY8v29TroOqO81RmJKLa2foBfSPmqaTnZpj8WH8JLc5xuxX0z
         w2YoxWvd4M7yhze5WG2NqqWIACfD9GmieL19hyIN8ZNnsILqbAgr/pADCHVmGvhvKXyH
         C2czmihnIY9fO1dLZE0E7lEYJwfmHYDXNcfRNT1OMPi8r7l2HEi0nNvFHNwCO/WkH1mm
         Sm1w==
X-Forwarded-Encrypted: i=1; AJvYcCVVOGBBrLHTEwtw3VyPIw5TRnGCSyA0dN2cfFTE+rPYzYJCvQKAcFaN6VrtkYsiRgO/5iJf0uCQ/vk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyvLk0posP2iu/AiPS5XQk06dtPqYE669Go+Ne/QKRnj40EHLas
	xxHu/Kmh+IYyiOzOTRKxCww3hCbfKELxhuAFm++Ug6dev1mFyYgQSVawjRFO9wz/DA==
X-Gm-Gg: ASbGnctf8EVXiwan6GiENq/qdOLM4etGhEOwtnpEKGBBjUROLet9q3z5Hycs0Ccljoh
	/2l+DsjIFGz2LCD57ratplWlvM+YuXub3ZjijZqRUYcYXaEha2RLmdzcUtmmQQHlI8MtzJgBO0Z
	qiCDaYtsoJURA2wDUM/UJIz2mf/KmZf0kdPu7nWz0ckpbI4S04HWos5u5PS+XPUn3rB+oSRY82w
	WYJhmRFC8JW7SkI7HMhaH+T4GVGx1Haac6/6QofQ1Uwvu6FA1ZHxYzoOX0m2bJP7c38+mJ6Lw/T
	1EL/MgUZjtrrgX7mMSUoBdCVbNCYQGT1SgjXGQp4RDF8KTKqbGpd9bRuh8HQjbrf5gLSj4alGEa
	6K9seOpdADUmJWGVYIVD/GVJrDbiLio6i7MXFCA4LTr/4Nsg=
X-Google-Smtp-Source: AGHT+IEk4BWGYNhnjMemECiQpE/FvkHRHdM77O28ZHE/BMiMHcK4Ih+z/F4FO3omDfZKL1b0rEoPDA==
X-Received: by 2002:a05:6402:5cb:b0:5fd:c426:9d17 with SMTP id 4fb4d7f45d1cf-608d09f6da3mr7227377a12.34.1750056922779;
        Sun, 15 Jun 2025 23:55:22 -0700 (PDT)
Message-ID: 
Date: Mon, 16 Jun 2025 08:55:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 13/14] xen/dt: Allow CONFIG_DOM0LESS_BOOT to include
 device-tree/
To: Alejandro Vallejo 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org
References: <20250613151612.754222-1-agarciav@amd.com>
 <20250613151612.754222-14-agarciav@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: <20250613151612.754222-14-agarciav@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.06.2025 17:13, Alejandro Vallejo wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -14,6 +14,7 @@ config CORE_PARKING
>  
>  config DOM0LESS_BOOT
>  	bool "Dom0less boot support" if EXPERT
> +	select LIBFDT
>  	depends on HAS_DOM0LESS && HAS_DEVICE_TREE && DOMAIN_BUILD_HELPERS
>  	default y
>  	help

Nit: Imo it is good practice to have the select-s after the "depends on",
and perhaps also after any default(s).

> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -8,7 +8,7 @@ obj-y += cpu.o
>  obj-$(CONFIG_DEBUG_TRACE) += debugtrace.o
>  obj-$(CONFIG_HAS_DEVICE_TREE) += device.o
>  obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) += device.o
> -obj-$(CONFIG_HAS_DEVICE_TREE) += device-tree/
> +obj-$(firstword $(CONFIG_HAS_DEVICE_TREE) $(CONFIG_DOM0LESS_BOOT)) += device-tree/

Why not

obj-$(CONFIG_HAS_DEVICE_TREE) += device-tree/
obj-$(CONFIG_DOM0LESS_BOOT) += device-tree/

as we have it in a few similar situations?

And why would the duplication be needed in the first place? Shouldn't
DOM0LESS_BOOT imply HAS_DEVICE_TREE? Sadly the description once again
only says what is intended, but not why. And the dependency is actually
visible in patch context above, in the hunk altering xen/common/Kconfig.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 06:57:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 06:57:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016685.1393636 (Exim 4.92)
	(envelope-from )
	id 1uR3mA-0005jd-SM; Mon, 16 Jun 2025 06:57:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016685.1393636; Mon, 16 Jun 2025 06:57: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 1uR3mA-0005jW-Pf; Mon, 16 Jun 2025 06:57:02 +0000
Received: by outflank-mailman (input) for mailman id 1016685;
 Mon, 16 Jun 2025 06:57: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 1uR3m8-0005jQ-UH
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 06:57:00 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20614.outbound.protection.outlook.com
 [2a01:111:f403:2408::614])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 18b7a1a6-4a7f-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 08:56:58 +0200 (CEST)
Received: from CH2PR17CA0022.namprd17.prod.outlook.com (2603:10b6:610:53::32)
 by LV2PR12MB5800.namprd12.prod.outlook.com (2603:10b6:408:178::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.23; Mon, 16 Jun
 2025 06:56:53 +0000
Received: from CH1PEPF0000AD75.namprd04.prod.outlook.com
 (2603:10b6:610:53:cafe::4a) by CH2PR17CA0022.outlook.office365.com
 (2603:10b6:610:53::32) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.35 via Frontend Transport; Mon,
 16 Jun 2025 06:56:53 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CH1PEPF0000AD75.mail.protection.outlook.com (10.167.244.54) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Mon, 16 Jun 2025 06:56:52 +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 Jun
 2025 01:56:52 -0500
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 Jun
 2025 01:56:51 -0500
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; Mon, 16 Jun 2025 01:56:50 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 18b7a1a6-4a7f-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=p0JC+bNiinUAcQmdIDSXfPAj6XkiOi2ZweNEqWvRy7vk01jOtT0CilCDix3fGQb1JHO88Tk6frhpHSHyrHTgk3Q0cvSZTdxaV7dZ9w9qizx67O2IzBaF74aAZq6LFKMdqVgmT1AsnwJDw5FLEED7p22gOIpLbSPgfmwtzAfFZBKJt22pKYvVmWrswuTLzoJPwcW6iBFvCV2Z1psNfCoGAs52u9wDhDGNxLvLAgd/9leh4FUnWu7sRoMsvzTMcetPCMPrnbLOF+AVstiOCtKxDPilQGPy2nWBN3HMBh+leGmdkOsjS2mXUEofgTpz0eZhDhgZ6DD331YjnYcSHtZ/AQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=/u9vc2Yh18LQ/kV2+OYDJu5UeOkfnKzyLdi8UYEUIdc=;
 b=CY3WLzHNW8P6o0tnfNSQpQvRKaAk/ncQUCYCKJjBzaNd7aiOomZj6+qVXzrmCphvBHRWbyz7/WrjqRjIk6x4Rnzxfeza+hZqp2kTaF9YwKVG3Xzj3D3arBjlBE9kADZB1R0rfGUN3QYM+0zLA0jsNZCuatxD3nBtu4hkr0OjdY9nBRLt/Iu2WbwDnB2nc2yQMX4T67o4AVk/J7GgtdY2o6o83BL6+c8zrTp0iQwRhgsIOAUH+gqzILH37Wtf8HRIDzQ7KwlemRPvZIYoPSKujNVXvw9FIM4g3pYU48V408kSUlXCktUh3BdRywMLhGNC2/ik1fDOivFVK39HkjlabQ==
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=/u9vc2Yh18LQ/kV2+OYDJu5UeOkfnKzyLdi8UYEUIdc=;
 b=XTOZrXkRSpmeRsMJ+u0oqVWqHbW6XflEX/Y1nlIfTjWB9gpjUHEdjBciVjMYbYVHJwqEEbecoQL6Wn2qzVHvd9eNLnXMGKlbX49CdAy1dEjUrsmNlrV824oevX+xReBt0p5E6fv9wfp+xZXddWMGbSqNCTndk3FaRPzPY57itCw=
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 , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Volodymyr Babchuk 
Subject: [PATCH] xen/arm: Fix P2M root page tables invalidation
Date: Mon, 16 Jun 2025 08:56:48 +0200
Message-ID: <20250616065648.17517-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: CH1PEPF0000AD75:EE_|LV2PR12MB5800:EE_
X-MS-Office365-Filtering-Correlation-Id: ec51225b-92a1-48c4-1e47-08ddaca2f99d
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?T3MhFuNMLiNTn4L9okjquPqixSVp6or0q01RvjO6VTXxiNamTSD0kwHCJT+p?=
 =?us-ascii?Q?FM1EyEuyknFxdam0LthZutiugNUoFXAaDcChb0ee2VuvGmcp1YmtKfQpRuc+?=
 =?us-ascii?Q?8QgYhe9MlCWzl2e9hqNSaqQuM+k3oQcqG5AoRhDxuJ12fZ71Ui16+j+ybrJo?=
 =?us-ascii?Q?LDKqwr9QlcGeMnADRAjrYSvCtVVy5pSMGCJS+ouMAsCXOrlN83Vm10Tu0BYO?=
 =?us-ascii?Q?SsQj7f6zlrIVZ33tI5Ipb7oXrtHxmGvx2Uv1o+zhIEvtEatWRMZR6e6fABtJ?=
 =?us-ascii?Q?mY5NZJhWRUeXR5Ds8uFUFv/aJymKRslZSmdfRW1OJNSEZ0qC4tToE2rK0y+W?=
 =?us-ascii?Q?oNU42zY+cKCi4ZRflCbWQgZPIjyyfQae8Uv1QlO5jFWktbKgkgPeENrNx1sm?=
 =?us-ascii?Q?gwIxjrHxvuhJKDwz5KzN27kQDMMGwQHYsY0B1CsAWFKbWIFX02jOtLBEuYEw?=
 =?us-ascii?Q?a80EOT1o/DydCodS4iOb4lPCfABAx0aKzyM1pD9T3tVd9GSeKZUxA+wofFKz?=
 =?us-ascii?Q?zkyfazAqDNImKOgmySvJgu+zY9DxVL1gj9V+lGc7BYvdAfpA4eBy5TqjBooE?=
 =?us-ascii?Q?TAgm1uL+RA+TBgA1nAd/BvCY3AzdJCf11bKyr4ArF2bQfitdYqqOKmR564vA?=
 =?us-ascii?Q?XB3mqxHiuFcQdZKL38PL4lddyZdLdHDFCNqpsfCMQjnLAaPMZzE2Pyyh7dPs?=
 =?us-ascii?Q?mzOO1VBXN6W/twG1bG7zt/MExy/Iu+JZ6h3UnDS7LWatcZ3vV0zNt9wz13W3?=
 =?us-ascii?Q?95ck+7qcvCLTBkH1vrC2/SLKQG5dcJbn22i+lxFbwlMCNbg2m/TNk3aLiIfX?=
 =?us-ascii?Q?BPgkhgKuqVzvk+/RUKWA0FdMUUrftA8NvFVOK1BH1jsVnpZvXhvqfYFWQXDz?=
 =?us-ascii?Q?KUW4Q9DTmeUl6lPpZqqJ+sqWbomS71JOzsj6Icc9Fs1/6Jbyzb5TFA0J0kvA?=
 =?us-ascii?Q?046lOHfqxZ0KOQHVRVUenBx7kM1S26lAYRQmJZf29dsWn54waejZyTNjWwHj?=
 =?us-ascii?Q?0e/4AFhFnq/4rgLeRSUOVS32tjptKSQqKHDK8t/GsG/t7zSgSeUOvt+OB85d?=
 =?us-ascii?Q?5LQeyWkIJVdTTMdwp3r8zbCWSDPBey8aTp43V9klR64iVjvZT59peIW74m2s?=
 =?us-ascii?Q?CyNZMZ7Job25RSisd6b2ZzKkOBiKXgxqZ4LYx3Ppn81j2Zxh5u+ldnAH3Unh?=
 =?us-ascii?Q?KnQXQV1c6FGbCplperpaK8QuCbP/M1SP9/+957YNLH/30/HT1OdKds/F220a?=
 =?us-ascii?Q?tRraS2yJjr0ykrLzQ5NWIrCAQWbC4krV4zRXx7uNQAai8XeZUlkoy/Sr/+Mk?=
 =?us-ascii?Q?ngj4QigOyTjlp7ca8ZmMblywZ487mclK+ZutoQQ7F4zE9XDYNeWRUcAYxfoK?=
 =?us-ascii?Q?Y8+w0NLJPhPWKOduZjsrUNI0htziRN5rj0LWSIVrvGvimBFlBeF5hphNeIpu?=
 =?us-ascii?Q?7ruhhSsdrtmwIqFG1Ody7O8AQDsTwFdE/EudGnV8cucN/S8s7ofDyxghSjZ0?=
 =?us-ascii?Q?EYz35D6eB56TqM412NtrZqa4SezB+iDJZ7Dk?=
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);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jun 2025 06:56:52.8442
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ec51225b-92a1-48c4-1e47-08ddaca2f99d
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:
	CH1PEPF0000AD75.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV2PR12MB5800

Fix the condition part of the for loop in p2m_invalidate_root() that
uses P2M_ROOT_LEVEL instead of P2M_ROOT_PAGES. The goal here is to
invalidate all root page tables (that can be concatenated), so the loop
must iterate through all these pages. Root level can be 0 or 1, whereas
there can be 1,2,8,16 root pages. The issue may lead to some pages
not being invalidated and therefore the guest access won't be trapped.
We use it to track pages accessed by guest for set/way emulation provided
no IOMMU, IOMMU not enabled for the domain or P2M not shared with IOMMU.

Fixes: 2148a125b73b ("xen/arm: Track page accessed between batch of Set/Way operations")
Signed-off-by: Michal Orzel 
---
 xen/arch/arm/mmu/p2m.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/mmu/p2m.c b/xen/arch/arm/mmu/p2m.c
index d96078f547d5..67296dabb587 100644
--- a/xen/arch/arm/mmu/p2m.c
+++ b/xen/arch/arm/mmu/p2m.c
@@ -1291,7 +1291,7 @@ static void p2m_invalidate_root(struct p2m_domain *p2m)
 
     p2m_write_lock(p2m);
 
-    for ( i = 0; i < P2M_ROOT_LEVEL; i++ )
+    for ( i = 0; i < P2M_ROOT_PAGES; i++ )
         p2m_invalidate_table(p2m, page_to_mfn(p2m->root + i));
 
     p2m_write_unlock(p2m);
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 06:59:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 06:59:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016692.1393647 (Exim 4.92)
	(envelope-from )
	id 1uR3or-0006IE-8G; Mon, 16 Jun 2025 06:59:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016692.1393647; Mon, 16 Jun 2025 06:59: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 1uR3or-0006I7-5W; Mon, 16 Jun 2025 06:59:49 +0000
Received: by outflank-mailman (input) for mailman id 1016692;
 Mon, 16 Jun 2025 06:59: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 1uR3op-0006Hu-H5
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 06:59:47 +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 7d072ce1-4a7f-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 08:59:46 +0200 (CEST)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-606c5c9438fso8619813a12.2
 for ; Sun, 15 Jun 2025 23:59:46 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-adec8158bdasm597539666b.20.2025.06.15.23.59.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 15 Jun 2025 23:59:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7d072ce1-4a7f-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750057186; x=1750661986; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=0hOz3wq7rBMYcnCqYbyC3PEVumVIfMb9w57iEP5bteM=;
        b=KXT9IdEkNb5IZyUOS8Rcsr7+xWYRCJ+VwiT1D0tYi2GqUoolob+JdwTqmjLUQ5qDJ5
         GSu59RTkl2pw0W5u47pnOZhPBXu782Sce4GxEYrGi4k5dQtEKVklAFJPq622N3q3TzPt
         cxaljDkVZXT2peyK/wTh30XMSq5TbuhkDWPhvAhPgWseeSOhb6iltCJhWMXoSLv6su5D
         4hcChL/9Ubs8Pd/AGJnlex7QO7u0Awece6lVHJlfQjIG/hLCWPbs+ruGP6JUg5q4M69C
         QCa6sMKcjko5OEf+Dl5GkLzoKhzLkWtbJdyi7zVSINiM1oYomysCKg1W4L7aZTiWPQzd
         A1tQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750057186; x=1750661986;
        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=0hOz3wq7rBMYcnCqYbyC3PEVumVIfMb9w57iEP5bteM=;
        b=e2h3AvK6ocfAWL+XPEpyxLXwxoZwow+6AI5UYX11MPCL7P51qRRB/QQSzxFjzKwVgh
         4/eVl5bWzg/Y1Lq4a2md93321LDmsj/rqisocPHHmjLlWDhifGiotMCwziRw1MDdH/Fg
         NV6N/UgZ+sD2k+/GPvsljV/BQ59LA6nfmwXLf/aD6LK5aS6HO64RcQ7hq2R8epWSjsUJ
         zJAtKHRO9NpTRJXavRZK+g02A9kBLIriZrJgpnbDca9irBizYxmMglmQt9Vfm4v+h4Qe
         sgQYeKDrNRLpc4y3dHuamBpNVq+iK7Wlv/kCgRSRrjIhX/ic4CR0EJ0XmvOLvluDYrH1
         Gm/g==
X-Forwarded-Encrypted: i=1; AJvYcCVZBSEO04jC6rch8EhX9pQsleRBlL27W1HtOiD+gRHjGqkutwHIMa9L1351gP4Dq3GPgWjlBEbiXiU=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyg8Xm8h/J3sn79MIB6lS8sucR9xo3VYaATQsj8tm1FPefsfXuW
	g8xxPN7FwHMhVL0hmoHOvvaHUmqj1tHsQLc35x7fVyzrAcQlpGC1ml9PF4lJ4JfL6w==
X-Gm-Gg: ASbGncsAfrb3pMa1s8+G7mnbIOJ9hRBcO/tc6KVYoz88YxD2D9Hs+a/gLlISOnPP2zc
	k7GiAJ5IdpRD/YclGDtwDTEK8ePczTwvzcZXRygFgIn2+/z1vsNlY6MqFYT4U5Jo45Tw3TXJAzd
	7keipZKSjMxMRhoHaCwMrJIxD6Q9XmfyvKZ758myFOy1HFEEnV/cOmpxXfU59mRf/cjjw5Rslwc
	zCEg3hWWeb48SpUjHU0ToxFvJQ0tKMhiyya7cVr5JBrCBKd1rdYW9LxUnvg1RcLEvMdgIHL/ULY
	WvaXAeiQiQEWTfc2g4/njYKGIe9WpYxuoaL7I7ZzhwovKcqRuGP0OsFT6CtADwfqGZbSSiluj5h
	iu7sDkjg1fhwegtp70qDj6WbY4H8T2PJiqtoHlHpB7bfmZAI=
X-Google-Smtp-Source: AGHT+IGpaiRi0PsvnZCKAAbFPnQd0k9JBybH154fLCF8xAclGeVV7k8oYjhv+7K6LuMzlOBw8hmqRg==
X-Received: by 2002:a17:907:97d5:b0:ace:c518:1327 with SMTP id a640c23a62f3a-adfad309382mr722513266b.14.1750057186165;
        Sun, 15 Jun 2025 23:59:46 -0700 (PDT)
Message-ID: <79722683-cd29-4b38-bd93-ef9458f95056@suse.com>
Date: Mon, 16 Jun 2025 08:59:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 14/14] kconfig: Allow x86 to pick CONFIG_DOM0LESS_BOOT
To: Alejandro Vallejo 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org
References: <20250613151612.754222-1-agarciav@amd.com>
 <20250613151612.754222-15-agarciav@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: <20250613151612.754222-15-agarciav@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.06.2025 17:13, Alejandro Vallejo wrote:
> Without picking CONFIG_HAS_DEVICE_TREE.
> 
> In order to do that. Allow CONFIG_DOM0LESS_BOOT to enable a subset
> of the common/device-tree/ directory. x86 doesn't want dom0less-build.c,
> as that's tightly integrated still to the ARM way of building domains.

Which then is grossly misleading: x86 also ought to select HAS_DEVICE_TREE
if it wants to use that machinery. Instead of theis an the previous patch,
I think what we need is a new Kconfig setting to control the use of
dom0less-build.c.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 07:00:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 07:00:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016702.1393661 (Exim 4.92)
	(envelope-from )
	id 1uR3pY-0007qL-Mz; Mon, 16 Jun 2025 07:00:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016702.1393661; Mon, 16 Jun 2025 07:00: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 1uR3pY-0007qE-J0; Mon, 16 Jun 2025 07:00:32 +0000
Received: by outflank-mailman (input) for mailman id 1016702;
 Mon, 16 Jun 2025 07:00: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 1uR3pX-0006aT-9z
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 07:00:31 +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 968e8b0f-4a7f-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 09:00:29 +0200 (CEST)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-adeaa4f3d07so807800566b.0
 for ; Mon, 16 Jun 2025 00:00:29 -0700 (PDT)
Received: from ?IPV6:2003:e5:872a:8800:5c7b:1ac1:4fa0:423b?
 (p200300e5872a88005c7b1ac14fa0423b.dip0.t-ipconnect.de.
 [2003:e5:872a:8800:5c7b:1ac1:4fa0:423b])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-adec897be34sm596525966b.164.2025.06.16.00.00.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Jun 2025 00:00:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 968e8b0f-4a7f-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750057229; x=1750662029; 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=oM3HWedc39VOPKmVwddBr1kKRq04hYJM5xhlEjkVHGQ=;
        b=AGmHkjpOtHAMr2aFnv4Kk0W3flKsoqFvx+f/Gb1tpizMwu7/r3QqNhXOc1xarXdGNH
         cubGSJkIKJHupDcpJCovdQD1wj6e7o6NyIBpP1Z3KKc0IP4nTULTtzJkZuOofKAFVavb
         R+xieoyyHDS/siMECBi9J8Mi+C3d+6JnbMriEitjhauL7wevCPfH6fHAixGcsvg1ix5+
         4s9DWOPykfIkO0rsDEfu7x13LfdEzJ7TyBIEbXSX0k1ukFegRkiMvoABqHZT9TuoMX3V
         IvpeQoJQGYzCVXJ/txXtFvB2D0BeP1GheRlcXWY/YaMfycQUavZ40/jx9/97t/rZ7HDa
         mrOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750057229; x=1750662029;
        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=oM3HWedc39VOPKmVwddBr1kKRq04hYJM5xhlEjkVHGQ=;
        b=IkFpmFwcgToQst+/Qqbl81fJTm8VhvazXPx9fwEraZNDxUFEyaAlKCdYGnPtMms5Lz
         GX5WvbX4IW66z2xdCFmOqD4o/DKzWkpczLZWE+ow1VqKoKddaGGsI2uNzq0qcsaSLyP3
         cY7AhhkrQikTL/eCgM8YRclM/psfP6iquiW3VUYq2wqh9jl74zhZby4oKtu2NRQR+C3p
         RLAN/MfIwjeIDCUNZ1FTQC1SEMoIGJFfXLkohPSpsM+OU8CAdArPMNCWqqSrkUMF1SYG
         oJC0hrfQPTXwpHzzEu30b6QuX9USTC/CYAEPF1EX5eqCe2167YhcmInPdhhOLr65cva1
         F4tA==
X-Forwarded-Encrypted: i=1; AJvYcCWp05yIIUpHZIDHE9dm6lha/kOhdBf/rhEEiPFwB00ZOIhIdiIIPEEKT0Nt49VLLCOeBpClLqOH55U=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwQYezbEkPS0dwHou2/8tlWXKOcvABgPKe8CSx2l0fUmI8h6Slz
	TFf+3SgRAdN5SwCJOuZQGg+HyzckusrNOUn0mJS5ERvUUMYJrIdHEtfhXczIGKfUuT4=
X-Gm-Gg: ASbGncuQPTwmw0tr/o+SEb7JvMGQB4pHCMbNFxphVhfbf1O/KdniHqkIBFTlEwvdLBz
	8hqLkVyhb7Q8RTbGmxGDaaIcXqqT17YaAAdqtV33non9Wwb6UJXI1wZMzCbERbgUTtMBgHqKjMU
	jfwcIzr3sFXoKdc2Gj32i7F0fmKM3qN7mqNSxd1eXpwFSn5SwnE0KYN4Iad8nnd+pyrIlyUdfJE
	Ntfq0kTCkRE7XH8+LWG+wu6bHnFfkhXAhsh2u6om5uJyszDlTiD7dC46ly1f1g44hKQunFPxgHs
	3QlQRSIofib33/1LMrjQ7FmBOYX8qsS4L+aaPEPstYWdbM8gvWB7F6Kt4Lh18b5ZMMCYKWsAxA5
	p+XfSDXIGjBMRIcegfUmTG9Os+GN9BoaKZdZ21MVwpX/zvAXk4V7Gfi1KVYAyW8qitDvZmRMs31
	puDyJ9OFNUpF4=
X-Google-Smtp-Source: AGHT+IG/n5+540BGy+MIW+Lnzn5EW6s1JugtQvsPGVVQKBsb8ipq3nIQpXt5pjUeCcXM5uPPlNqADw==
X-Received: by 2002:a17:907:d8c:b0:ade:9b52:4d78 with SMTP id a640c23a62f3a-adfad638ddamr804041166b.48.1750057229003;
        Mon, 16 Jun 2025 00:00:29 -0700 (PDT)
Message-ID: <8971cebb-6b31-4de1-bed9-4b2d8a03f65d@suse.com>
Date: Mon, 16 Jun 2025 09:00:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [MINI-OS PATCH 07/12] kexec: build parameters for new kernel
To: Jason Andryuk 
Cc: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org,
 samuel.thibault@ens-lyon.org
References: <20250321092451.17309-1-jgross@suse.com>
 <20250321092451.17309-8-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="------------PQ9GWc69PSq0JtVaYS0G2ViE"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------PQ9GWc69PSq0JtVaYS0G2ViE
Content-Type: multipart/mixed; boundary="------------qoDqfXXY85M0zGLrFV9q45cx";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Jason Andryuk 
Cc: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org,
 samuel.thibault@ens-lyon.org
Message-ID: <8971cebb-6b31-4de1-bed9-4b2d8a03f65d@suse.com>
Subject: Re: [MINI-OS PATCH 07/12] kexec: build parameters for new kernel
References: <20250321092451.17309-1-jgross@suse.com>
 <20250321092451.17309-8-jgross@suse.com>
 
In-Reply-To: 

--------------qoDqfXXY85M0zGLrFV9q45cx
Content-Type: multipart/mixed; boundary="------------YzSBZLPQ5VCnVpxuPxiCrWTo"

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

T24gMTQuMDYuMjUgMTk6MDIsIEphc29uIEFuZHJ5dWsgd3JvdGU6DQo+IE9uIEZyaSwgTWFy
IDIxLCAyMDI1IGF0IDU6MzDigK9BTSBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+
IHdyb3RlOg0KPj4NCj4+IEJ1aWxkIHRoZSBwYXJhbWV0ZXJzIGZvciB0aGUgbmV3IGtlcm5l
bCwgY29uc2lzdGluZyBvZiB0aGUNCj4+IGh2bV9zdGFydF9pbmZvIHN0cnVjdCwgdGhlIG1l
bW9yeSBtYXAgYW5kIHRoZSBjb21tYW5kIGxpbmUuDQo+Pg0KPj4gU2lnbmVkLW9mZi1ieTog
SnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1c2UuY29tPg0KPiANCj4+IEBAIC0yMTIsNCArMjEz
LDYxIEBAIHZvaWQga2V4ZWNfc2V0X3BhcmFtX2xvYyhjb25zdCBjaGFyICpjbWRsaW5lKQ0K
PiANCj4+ICsNCj4+ICsgICAgLyogVGhlIGNhbGwgb2YgdGhlIG5ldyBrZXJuZWwgaGFwcGVu
cyB2aWEgdGhlIHBoeXNpY2FsIGFkZHJlc3MhICovDQo+PiArICAgIGlmICgga2V4ZWNfYWRk
X2FjdGlvbihLRVhFQ19DQUxMLCAodm9pZCAqKWtlcm5lbF9lbnRyeSwNCj4gDQo+IE1heWJl
IGtlcm5lbF9lbnRyeV9wYSwga2VybmVsX3BoeXMzMl9lbnRyeSwgb3Iga2VybmVsX3BoeXNf
ZW50cnkgd291bGQNCj4gYmUgYSBiZXR0ZXIgbmFtZSB0byBtYWtlIHRoZSBwaHlzaWNhbCBh
ZGRyZXNzIGNsZWFyPw0KDQpGaW5lIHdpdGggbWUuDQoNCj4gDQo+IEVpdGhlciB3YXk6DQo+
IFJldmlld2VkLWJ5OiBKYXNvbiBBbmRyeXVrIDxqYXNvbi5hbmRyeXVrQGFtZC5jb20+DQoN
ClRoYW5rcywNCg0KDQpKdWVyZ2VuDQo=
--------------YzSBZLPQ5VCnVpxuPxiCrWTo
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-----

--------------YzSBZLPQ5VCnVpxuPxiCrWTo--

--------------qoDqfXXY85M0zGLrFV9q45cx--

--------------PQ9GWc69PSq0JtVaYS0G2ViE
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/Ey8FAmhPwQwFAwAAAAAACgkQsN6d1ii/Ey8Q
ngf8DZ9THyZDrfPA3d3dblT+EqhhpIO2C4lVLm1mER/5DMPtBEgK7FAoj7bYQiyodoimOsmgebi6
NN1ytltoJrC3S2a67a7wwAHV556Gxu7d0GczGUqzu8oeeJ6lsLfiDKjjjA9ALbmXS2jgVMZx2qzL
U6nXBjA67K/wSo97bFb8z2X0lq5prrGpVHAEHa16+Exg1DP8ZL8Gwx4dBvwtxjmc9C1LwMBZ1H+W
d/tu8UROlmknwxW5/XcvwZKscb6qpJSxI8s+LHK8nUjXzF900xT6UNGBeVvS6iwnsUfJ3SggO8+8
kJOAZGOkZJ2NFTztk7L8NMyOpv5R/7JBbAH2hmMVEQ==
=DI1w
-----END PGP SIGNATURE-----

--------------PQ9GWc69PSq0JtVaYS0G2ViE--


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 07:01:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 07:01:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016718.1393670 (Exim 4.92)
	(envelope-from )
	id 1uR3qJ-00008z-UK; Mon, 16 Jun 2025 07:01:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016718.1393670; Mon, 16 Jun 2025 07:01: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 1uR3qJ-00008s-Rl; Mon, 16 Jun 2025 07:01:19 +0000
Received: by outflank-mailman (input) for mailman id 1016718;
 Mon, 16 Jun 2025 07:01: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 1uR3qJ-0006Hu-51
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 07:01:19 +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 b3d8d6b7-4a7f-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 09:01:18 +0200 (CEST)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-ad93ff9f714so728460966b.2
 for ; Mon, 16 Jun 2025 00:01:18 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-608b4a93b03sm5531809a12.54.2025.06.16.00.01.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Jun 2025 00:01:17 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b3d8d6b7-4a7f-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750057278; x=1750662078; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=dY8BGe9e9TqrPHAlEJu9QoJiufRE4AOYbMuv7tR3bJ0=;
        b=EwN5uR2I7hY3dD9bFmlslx+ZKgP+M5W/G58Wbwkf4yOmx1nWSO7YN9Epim1/Q0OFmS
         ibntom3zvBH66V4Kfvh9vf509od087I+JbcOoe9La852Dv68WGVUwzKktzeoK36yZqDQ
         DTaykunUT7MjnFBzOAESqJAtXEmSDt34LpFChZAKLIQqrXruUUAQJ15elHBb+GFyI0wf
         3m/fg7r2DPch/pzahfkzqlQ8uBkDrBWxwcwW6lWhdEuolpOvRp5XL1uF3C/afiPXXTbA
         g9wa1Si/mcwIRad3EAgisFyxf6kM10vwMVC3VSxsmMqDOYzdoPMWSR4iPcp7n2WwMWgw
         NFOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750057278; x=1750662078;
        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=dY8BGe9e9TqrPHAlEJu9QoJiufRE4AOYbMuv7tR3bJ0=;
        b=YRgc6r5hdj+H9gPoch18NXoOdAhShI9dJ5R4bXua9ibVcQCeiE1rP0noys3Ip/SCse
         pfmlLZKzBhjF3ZhJTaJDl+7CHwN8tIeFB5+vclud4OZm7jIiu5gDEKRLOcuGIBRrFRpK
         HkcakmMKa8LpdzDLCDymoKDreuLN6TkkrC5tDeFIMrPb3eUNhvqfRLVOZXtpilzPw6lj
         ZtM+/9+pFv0YM4gf5LRR/1WeBw0VicoelRIMZBWAeHs0ROCecPp0WEzMJgGilHymxCZh
         NnXVUdbtBsZIga02HHLuT8e0GZfbqRdbvFWgO+UzoKOlPQNKFObUmG3OLmLOYA4ww8u3
         2ixg==
X-Forwarded-Encrypted: i=1; AJvYcCV6W3PfH/ymD3v3HY+5Qjd5w9dqj5ejmnxS92hWqNitpkSheI24rHUkDcPvuR4MvTEWZS4wDYO3v4E=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxN76mKXo1rVXDgUXbBYKh81pyS4rQlnoYPK9GJ+2TvQK+dnKKI
	qc8Q9FX7MLoFVEmsW7qjfJjYBj5+PbjnOKvFI4S97eXv59P1Ow9GkHYYrz7KaLzNYQ==
X-Gm-Gg: ASbGncsKuZsFV5Vz9OQb+3nUx882nplGMo5J+jtKQloVUTEYgFMskfrjzy3sqhJ64NZ
	wcXae8eTgiedo+OcIM24U2jj60mj2/862Zee9a2bWijS7NUD3Xqvy/jVtrH05JrFZJ3VcY77qaD
	MzYYPKhvNYEGwu/8GC3I2+vrIDiobXubovPZulMxm4ziISkHWDTSYc30RtFcVyBql/LFyBGWRdf
	3UJS6oHkGe+eY3jfjPq46NVLQYL5DFmdOUcMCUi+jZn7SclyU4+onCP3zqkvql5sFP2bWPJ3Mft
	v1fap187JfyUAKV5bYCz2pvtm57eooabJoap8m+HcP5sPaKVyCMRdS9Jwq0/KWux2DqED8JpgwM
	kRZ7HMOY2dm8Vb11QoHSIVTLPoux2hRqQCSb2NMiFkjtvSuQ=
X-Google-Smtp-Source: AGHT+IFlKxIdHabl/a6Ds14tOCN/yATQW9hGL4chjm1Vrggn5+gHzMEhtQbTDNAuiSCZrcQCBAyGiw==
X-Received: by 2002:a17:907:96a8:b0:ad8:9466:3344 with SMTP id a640c23a62f3a-adfad4f38bfmr887367266b.43.1750057277650;
        Mon, 16 Jun 2025 00:01:17 -0700 (PDT)
Message-ID: <07d0b403-1fc0-4d19-beee-b6960b29c819@suse.com>
Date: Mon, 16 Jun 2025 09:01:18 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 12/14] xen/dt: ifdef out DEV_DT-related bits from
 device_tree.{c,h}
To: Alejandro Vallejo 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org
References: <20250613151612.754222-1-agarciav@amd.com>
 <20250613151612.754222-13-agarciav@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: <20250613151612.754222-13-agarciav@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.06.2025 17:13, Alejandro Vallejo wrote:
> ... which means, device-tree.c stops requiring strictly CONFIG_HAS_DEVICE_TREE
> and may function without it.

See my reply to patch 14. I consider it outright wrong (as being overly
misleading) to build device tree code without HAS_DEVICE_TREE=y.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 07:06:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 07:06:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016750.1393682 (Exim 4.92)
	(envelope-from )
	id 1uR3vN-0001mo-II; Mon, 16 Jun 2025 07:06:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016750.1393682; Mon, 16 Jun 2025 07:06: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 1uR3vN-0001mh-Ch; Mon, 16 Jun 2025 07:06:33 +0000
Received: by outflank-mailman (input) for mailman id 1016750;
 Mon, 16 Jun 2025 07:06: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 1uR3vM-0001mb-9n
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 07:06:32 +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 6d6cb53b-4a80-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 09:06:30 +0200 (CEST)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-ade5a0442dfso782513266b.1
 for ; Mon, 16 Jun 2025 00:06:30 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-adec8158d8esm600862666b.5.2025.06.16.00.06.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Jun 2025 00:06:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6d6cb53b-4a80-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750057590; x=1750662390; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=zefKGPnzL8rTRF0GxQFp+q3vEpr37GbVeWltEABQmLQ=;
        b=HZuibUktJId0BffufN4EeUUs+3STwxk2iK5e3HzfKxREriwpmZPdj2z/6jDPPhBXT1
         FXh07Au/InCC9DWSied82G7DLYBHXRqP87u432yF8gEuajXiNIDuEvM2deT3ItjkbmKO
         KiAtv2MpjGvzyt6tftDHaeVik4zNjifYfTgG1N5ei68fiqFBemcqdvl2KhusDDkbU5SB
         M2LovpwNIHJM/OQWhKSYq+pbJRvSVegrFOEVY+UAUZ3DdhtFAl9CAc/jNEnzU9isRSS3
         GK4aJXGAL5IuOxk18pEvNL2UBkegRlnQeVDr03WfctM9yHGVVKoN30STHXctd+oFr00T
         h5PA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750057590; x=1750662390;
        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=zefKGPnzL8rTRF0GxQFp+q3vEpr37GbVeWltEABQmLQ=;
        b=tBBxtpaSbvPuvGZB6Qk4jcGptwku56/ZMonou9Z5dIxF0DqMz6CsXFbTiTYaPVzXEB
         x4RHkDQXjW0AC/r3FzJ5jKL0jFHcJbcIp/bhQpyXGrCMyP5vsqkGDg2gUBTwH+co7ncB
         LoU9AqeStsOQs2Fd79kGH5+x6LnEScDy2s00Y+7EVY4hP3AtvNvfXHtFJ9+FJXhtyViI
         8kc9T+mJEM9Sud1p4JLp09a41q67nO7oq+5QyNLIdxQxTaBLyaw+h834uNKIRuL1sFCa
         22w/auHCXBB57sKmutkb77L/PtyryRtb+6zoMJYN6sEIkqnNRGuK1h5dichmwucwU9LA
         1BIQ==
X-Forwarded-Encrypted: i=1; AJvYcCWEr8OsS4CnVgEQG+17mftngZ+mUgWobwFPwnnPnzIyrJHRD0e6tc2pWZj6V9JAdEgsefQxvTTO2CU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyD3i43d52SnLzhQ1FEchM+Q0yoHn1xrmidoJgBV9cIN9ouZjGS
	6KXJTev5At3gLDUdfj9KXAKk4zTGhtDn+g1Hyb008uW0xloa6quiNAhUOCgK36FeZw==
X-Gm-Gg: ASbGnctjMigpS606mUxdWan+7qSCVshOV5eApdySYvtv8mNF/Lr9P2zW1flCEyjFID3
	tttYTi1Hocs3TsBf0qOdSHRpuzsJRHierEGpsPCFajYDhd92VBwBGek+/PEftQF9GE2k4e2KLW7
	uxVYc5FIVyfj+BmdaafMmhTQj+qyk12SR/cgdzeCGvK+IbJbHnd/cMnmB/LPgC8zWPP8PFLO5TS
	pmnYiuJYy/c3srbirtu2FCVwFkBpK6D0QqHnzjmz3emlylpKiFgOn2ZULubU17eZRctnooLywWP
	QomzK55dpuo6OesSRBEl47sDhaJMzFddDz7sgLM05JUIt5QByKIOTeZDhUjJTdiPuRtbWE5qBS0
	q+iOCs5Lm6baD0ws72zT+g7tS0UdK67UI1nyvRRa+3cl1tjc=
X-Google-Smtp-Source: AGHT+IGULn5tYmf25n4NDNY/oBM6WTjdmB21Omzn7g7B9GwreVjKO5N8hckVlY07JBMfWzwVHgkHWA==
X-Received: by 2002:a17:906:f583:b0:ad8:9c97:c2f7 with SMTP id a640c23a62f3a-adfad363e5amr807330166b.2.1750057589559;
        Mon, 16 Jun 2025 00:06:29 -0700 (PDT)
Message-ID: 
Date: Mon, 16 Jun 2025 09:06:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/2] xen/domain: introduce generic weak function for
 domain struct allocation
To: Andrew Cooper ,
 Oleksii Kurochko 
Cc: Roger Pau Monne ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Anthony PERARD ,
 Shawn Anastasio ,
 Alistair Francis ,
 Bob Eshleman , Connor Davis
 , xen-devel@lists.xenproject.org
References: 
 
 <7ef86c5b-80ad-4bcf-8028-ef98616a8924@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: <7ef86c5b-80ad-4bcf-8028-ef98616a8924@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 13.06.2025 20:53, Andrew Cooper wrote:
> On 13/06/2025 4:56 pm, Oleksii Kurochko wrote:
>> diff --git a/xen/common/domain.c b/xen/common/domain.c
>> index e566a18747..c134868e95 100644
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -785,6 +785,20 @@ static int sanitise_domain_config(struct xen_domctl_createdomain *config)
>>      return arch_sanitise_domain_config(config);
>>  }
>>  
>> +struct domain *__weak alloc_domain_struct(void)
>> +{
>> +    struct domain *d = alloc_xenheap_pages(0, 0);
> 
> I know you're just moving what ARM has, but this is spelt
> alloc_xenheap_page();
> 
>> +
>> +    BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
>> +
>> +    if ( !d )
>> +        return NULL;
>> +
>> +    clear_page(d);
>> +
>> +    return d;
>> +}
>> +
> 
> This looks fine, but you must do the same with free_domain_struct() at
> the same time to keep the pair symmetric.  That in turn gets you an even
> bigger negative diffstat, and x86 doesn't even need to override the
> common version.
> 
> vCPU really wants doing at the same time, although you're going to run
> into problems on ARM there with the BUILD_BUG_ON().
> 
> However, I suspect we want to be building with -ffunction-sections
> generally active, or IIRC we'll still have the weak copy present in the
> final image.

Instead of introducing a weak function in common code, why don't we move
the function there altogether, adding merely an arch hook to control the
flags to be passed into alloc_xenheap_pages()?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 07:08:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 07:08:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016757.1393690 (Exim 4.92)
	(envelope-from )
	id 1uR3xX-0002J7-Qi; Mon, 16 Jun 2025 07:08:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016757.1393690; Mon, 16 Jun 2025 07:08: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 1uR3xX-0002J0-O6; Mon, 16 Jun 2025 07:08:47 +0000
Received: by outflank-mailman (input) for mailman id 1016757;
 Mon, 16 Jun 2025 07:08: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 1uR3xW-0002Ip-PH
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 07:08:46 +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 bdb6ae20-4a80-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 09:08:44 +0200 (CEST)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-60780d74c8cso7525755a12.2
 for ; Mon, 16 Jun 2025 00:08:44 -0700 (PDT)
Received: from ?IPV6:2003:e5:872a:8800:5c7b:1ac1:4fa0:423b?
 (p200300e5872a88005c7b1ac14fa0423b.dip0.t-ipconnect.de.
 [2003:e5:872a:8800:5c7b:1ac1:4fa0:423b])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-adfade680d4sm444697866b.10.2025.06.16.00.08.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Jun 2025 00:08:43 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bdb6ae20-4a80-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750057724; x=1750662524; 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=+I72yCiZvSZ5VQ3Cp8cHIMHwkk7sv/Vv9aJvu6F9c3U=;
        b=J2NSHn9J79EQ+h9dR4aYBSu8zmhleVtKDn3ZPrn6c3j7x94CmwAwcPUSW4OYErBKET
         NjueBMEwJsW47KYqJ8AW864qaU1Gxh3wI1LmMnRZGwxLtYNft9M0bxlYy24VISd1EEQU
         TG+zxxhYHvu4+2EeEOJe5HT/N1048//GDgynPpclHetWTai/r/YSNZcLEKbXRi6whO1x
         5Uh/+KFSOwCkpyACpSmx7fPj+gyLWOK0TTyiehAODiB+v+4jsAuLk51l2IX3VoNrmryG
         QoJoLN7cOHmEA3BvdGOdaGxUIDrrmJ6QJqQrivcfqXrpO0Cj+r16zkq/K/2jW0TcT8/t
         bIrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750057724; x=1750662524;
        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=+I72yCiZvSZ5VQ3Cp8cHIMHwkk7sv/Vv9aJvu6F9c3U=;
        b=evk2t/rVsbB+pO+vC0MoJYp3AG0DIBSIdp3PfQI6jKx3wP/LB4ngeyvfHJABIOeFEx
         vfszOpvbQNwyHtggFdAhc1xJk/aCFcRPfva5Pgi/cRj0S1uN7cIEWTe7qx6UIBwHS6EH
         B9okL1pddBMWzNFdWzAqb28Owr71TZoBRcUhSiF9bbLnCLiG17/+mzHicgEtuGV54bix
         mQEU2Mj9sglJHzemLnd+sDgGwwVJ10wdxpo8Iso+30u8FMZDNMVdNFESlgnmp/2iOOvw
         t+nX8nA7qfw0dO5TFrHh21sl9q9o1EueyluYgT03TF+6Y/TQbMlU31LVhWikP47MJ0Ah
         NzvA==
X-Forwarded-Encrypted: i=1; AJvYcCVvzcv2bRIPGodKU2yKN42lFTf70JBO6u5VvUilhjfaAsZ4kiQMDTR/9TF4iQXTtYobnDt44AfmKDY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxUBstDGUgt1DdlgkdAsT8g/8xlFU2AON/hG2NysjNtxifRxvwJ
	ilzMgon+4nmnSA+kyY+8yp8iNgtwkbZ8KB9ercSglG4MLChvNXCPcrWJfgrbsDcFrWU=
X-Gm-Gg: ASbGnctXBcizTvQcYkj8bN2GeKXYN+GDqMNRyW+lJpuS2jryokYL3CJFGzyC8Oi2mWc
	aPgM20JPfqqaaxGBfWj+mS69YkQMUdW/wpFqlMr/MBFTnVtWr2CVJmMgbgObqWIfC7w1vgn0w1N
	+pChDM6QBPsJFmj7JZGYdpNmX2u6jd1e/ZuxTu9dSG3SRtOZSzG46hAtIb/1QlgNg5Fl06fzvOq
	+jelWfDDRxfNt82DgaymrndH8qjiLombWkHPztUcwBqSsSm7rLku4uR3Q5qwO2nb5/FcRmqLcQe
	Fv6Ry99wTl1swwI7Me+0TYOCu9PxpR8Ai2d9E1fxlx8H17tCZ7i1aDNgnxWfFMQHZ6ulCvQRYTR
	o6ZpjbFrjVTbKwsK7kVGfdCAwgusiq+ezVzVJ087Ij6zdZ1eZQKTeSAsvJMh+Q9bxaABOSXWGRd
	954CXDRHg4rXA=
X-Google-Smtp-Source: AGHT+IH+hFESYGI9L7mtofpdwV3qW0INSv2cqjLVh+LZoJkQyU1vr2nsEp36MHdl86wZlvrtS0RXeg==
X-Received: by 2002:a17:907:86ac:b0:ad5:6c54:1147 with SMTP id a640c23a62f3a-adfad4bf5cemr817834266b.48.1750057724215;
        Mon, 16 Jun 2025 00:08:44 -0700 (PDT)
Message-ID: 
Date: Mon, 16 Jun 2025 09:08:43 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [MINI-OS PATCH 11/12] kexec: add kexec callback functionality
To: Jason Andryuk 
Cc: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org,
 samuel.thibault@ens-lyon.org
References: <20250321092451.17309-1-jgross@suse.com>
 <20250321092451.17309-12-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="------------H612b77uQVqqYckaSTQjK0uU"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------H612b77uQVqqYckaSTQjK0uU
Content-Type: multipart/mixed; boundary="------------40zEQulrY1Z6J1ybyE76v00m";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Jason Andryuk 
Cc: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org,
 samuel.thibault@ens-lyon.org
Message-ID: 
Subject: Re: [MINI-OS PATCH 11/12] kexec: add kexec callback functionality
References: <20250321092451.17309-1-jgross@suse.com>
 <20250321092451.17309-12-jgross@suse.com>
 
In-Reply-To: 

--------------40zEQulrY1Z6J1ybyE76v00m
Content-Type: multipart/mixed; boundary="------------6Rcz6J9JWIKVOyIRACiCip21"

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

T24gMTQuMDYuMjUgMTk6MzQsIEphc29uIEFuZHJ5dWsgd3JvdGU6DQo+IE9uIEZyaSwgTWFy
IDIxLCAyMDI1IGF0IDU6MzLigK9BTSBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+
IHdyb3RlOg0KPj4NCj4+IEFkZCBhIGtleGVjX2NhbGwoKSBtYWNybyB3aGljaCB3aWxsIHBy
b3ZpZGUgdGhlIGNhcGFiaWxpdHkgdG8gcmVnaXN0ZXINCj4+IGEgZnVuY3Rpb24gZm9yIGJl
aW5nIGNhbGxlZCB3aGVuIGRvaW5nIGEga2V4ZWMoKSBjYWxsLiBUaGUgY2FsbGVkDQo+PiBm
dW5jdGlvbnMgd2lsbCBiZSBjYWxsZWQgd2l0aCBhIGJvb2xlYW4gcGFyYW1ldGVyICJ1bmRv
IiBpbmRpY2F0aW5nDQo+PiB3aGV0aGVyIGEgcHJldmlvdXMgY2FsbCBuZWVkcyB0byBiZSB1
bmRvbmUgZHVlIHRvIGEgZmFpbHVyZSBkdXJpbmcNCj4+IGtleGVjKCkuDQo+Pg0KPj4gVGhl
IHJlbGF0ZWQgbG9vcCB0byBjYWxsIGFsbCBjYWxsYmFja3MgaXMgYWRkZWQgdG8ga2V4ZWMo
KS4NCj4+DQo+PiBTaWduZWQtb2ZmLWJ5OiBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5j
b20+DQo+IA0KPj4gZGlmZiAtLWdpdCBhL2FyY2gveDg2L21tLmMgYi9hcmNoL3g4Ni9tbS5j
DQo+PiBpbmRleCBmNDQxOWQ5NS4uMjZlZGU2ZjQgMTAwNjQ0DQo+PiAtLS0gYS9hcmNoL3g4
Ni9tbS5jDQo+PiArKysgYi9hcmNoL3g4Ni9tbS5jDQo+PiBAQCAtNTI5LDcgKzUyOSw4IEBA
IHZvaWQgY2hhbmdlX3JlYWRvbmx5KGJvb2wgcmVhZG9ubHkpDQo+PiAgICNlbmRpZg0KPj4g
ICAgICAgfQ0KPj4NCj4+IC0gICAgcHJpbnRrKCJzZXR0aW5nICVwLSVwIHJlYWRvbmx5XG4i
LCAmX3RleHQsICZfZXJvZGF0YSk7DQo+PiArICAgIHByaW50aygic2V0dGluZyAlcC0lcCAl
c1xuIiwgJl90ZXh0LCAmX2Vyb2RhdGEsDQo+PiArICAgICAgICAgICByZWFkb25seSA/ICJy
ZWFkb25seSIgOiAid3JpdGFibGUiKTsNCj4gDQo+IE9oLCBJIHRoaW5rIHRoaXMgYmVsb25n
cyBpbiB0aGUgZWFybGllciBjaGFuZ2UuDQoNCkluZGVlZC4NCg0KPiANCj4gV2l0aCB0aGF0
IG1vdmVkLCB0aGlzIG9uZSAoYW5kIHRoZSBlYXJsaWVyIG9uZSBzdGlsbCkNCj4gDQo+IENv
ZGUgd2lzZToNCj4gUmV2aWV3ZWQtYnk6IEphc29uIEFuZHJ5dWsgPGphc29uLmFuZHJ5dWtA
YW1kLmNvbT4NCj4gDQo+IEJ1dCB0aGlzIGtleGVjX2NhbGwoKSBtYWNybyBpc24ndCBhY3R1
YWxseSB1c2VkPyAgeGVuc3RvcmUgbmVlZHMgdGhpcw0KPiB0byBwcmVwYXJlIGZvciBrZXhl
Yz8NCg0KVGhpcyB3aWxsIGJlIG5lZWRlZCB0byBlLmcuIGhhbmRsZSBGRF9DTE9FWEVDLg0K
DQoNCkp1ZXJnZW4NCg==
--------------6Rcz6J9JWIKVOyIRACiCip21
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-----

--------------6Rcz6J9JWIKVOyIRACiCip21--

--------------40zEQulrY1Z6J1ybyE76v00m--

--------------H612b77uQVqqYckaSTQjK0uU
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/Ey8FAmhPwvsFAwAAAAAACgkQsN6d1ii/Ey/R
0wf/YBtyrU3c5JaOQCwWK88TyKVhJ4VqCEFa5VNaON92BrFiyU5dl8uN5O/USeg7VeRvuTfrQDHb
C0Ry2LHgA4xekllfN4Ytia9SDZxZ1TtSibqh9w1u8M6l+o8xSEJuJ4BqPHXcN1TQ1fm8JqGJI2jV
Q6M+ba8W2ZydO8Nz78FKtARC1Js4xRtO60gyKlMev+b1HxcxMZqIZpQoKbwy6B/gxpKE3xZiCrep
Z2vFfmIQc3QvSmP0DwJaXvDmj+s8M8e90SQI7wED+JqNISU1y0de5VrYeRlH0WUVgsl9UMBfUuw+
w8kNkVYm8RI+LlIeur+P7OKorVNohIkFvJe+6gTP3g==
=I7VR
-----END PGP SIGNATURE-----

--------------H612b77uQVqqYckaSTQjK0uU--


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 07:09:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 07:09:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016774.1393705 (Exim 4.92)
	(envelope-from )
	id 1uR3yX-0002xu-Br; Mon, 16 Jun 2025 07:09:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016774.1393705; Mon, 16 Jun 2025 07:09: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 1uR3yX-0002xn-7T; Mon, 16 Jun 2025 07:09:49 +0000
Received: by outflank-mailman (input) for mailman id 1016774;
 Mon, 16 Jun 2025 07:09: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 1uR3yV-0002bg-4X
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 07:09:47 +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 e285219e-4a80-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 09:09:46 +0200 (CEST)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-ad8a6c202ffso761508466b.3
 for ; Mon, 16 Jun 2025 00:09:46 -0700 (PDT)
Received: from ?IPV6:2003:e5:872a:8800:5c7b:1ac1:4fa0:423b?
 (p200300e5872a88005c7b1ac14fa0423b.dip0.t-ipconnect.de.
 [2003:e5:872a:8800:5c7b:1ac1:4fa0:423b])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-adf688970a1sm495683166b.175.2025.06.16.00.09.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Jun 2025 00:09:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e285219e-4a80-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750057786; x=1750662586; 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=TdMrFDstKn6cFwXSX2aSGseaDZLzq5Mn2zXgiyVBtT8=;
        b=fGQyAKrmK5Ek8v5s3DU2jX2hpQoL89hympg5QT+WcxfDJgXImVgxkfBOJWbK1TgNHw
         B7z87J6nH0Yk9uPi8/3Z+76K1PuEFNo96GUEuc3oVumyzaUhYe41HwqmSkmnzzZJDSLQ
         xiAXvYZXSDmVLa3Oztrsrot1411RkvltwLu6o3Sqmy7gX0E5Eure+8A+s5o4P1EAMScm
         sZI+eEPtCo/HifZRupgpoeS72YfTL064TXYtO3w6RG+66GeKSzvDY5eanm9pcVLpXB30
         vOge3G0zNIcbecvq9vCcew1wfF6guFyb8+3a3+4BT/N1XF2T/0C76QmdeFG68w9r8Rl4
         ojTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750057786; x=1750662586;
        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=TdMrFDstKn6cFwXSX2aSGseaDZLzq5Mn2zXgiyVBtT8=;
        b=eBB5E3p34T67bN8+m/Ejk16f7UmT4o84hHCEQ5xNByTu8lsBW5oJ4U+y8dU5NhFEnj
         vUxIEe2yLwlqOt+c4Gb+qP1ZNNM7OO+Q9xdv+H250cacaV8LNgC4aDoxzQ5QCfg382uV
         tOTovZ3V8WDcx/mYkgh2CceLJWDfZX5hRUBXw0m9Y8xXjs9X1g0BjgV1YEOhTmj+yeEA
         Jbqga3NILkspXITMX7Fa2wHic0C5nkPRIE4CmHXNhdxuDVCW6s+NJR4xuRQC4QYbBNqU
         b7RI/WTPkTCEt5Vl7qsabMMSteuCvbfbqFd9LxCR6wp/J9SH7FfYiphH/PT7o3RtVRMj
         QOWw==
X-Forwarded-Encrypted: i=1; AJvYcCUKujpgJuo4RrHU+ur2MlPRY8SmP+xquzC6uzn0IRmzgYYNGwnPPa1N6DLn6BkWP1x/nzKORKEFVjc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxFYoD5TsUnq3y3tH1pWtRa4aCa7LT0KcBC1tlcKXymK20VGDwS
	uVc4mXF8IRdRW/0/w8bq6winKTB2LQ083Tfz6EaleVP4B4ooI07u2mipj0bzWRcX9WIaSvGh7UE
	M5sN35R4=
X-Gm-Gg: ASbGncvuO9snBkTKm8vuYqZNCOAwlvj4cixcz0ls3SFHk1vlrsHsFwuqm3E/DAf+hTH
	i/tLk3tZysPO5V4Lv/O1hJLf3qkeqdVR81Hpm4N2L47fZ18K+dgv7lzLEEkTKfHGvcK2TqVrvyl
	fnwwOTfmnykT8BeDKaaVqMN3BjamlqMrVn9m0uay41aPjWQXXU5U8oaRkQH/VBx4GITfChTLbhu
	/Jmqg7nzjJuqXBc29VURqzYo7erdLgRuQboBj3/+SmvHej6BdMyRUzhB4sJhxv93NybcxMFFavQ
	V10Rxrduj8cfJT+nqLOE/gD7dSU5SZKhchDDWMWttQW4LZBxBoR3QdhsFUdhA1SGMV5BhQTc64b
	HLSBMB8uMq6QEt1fQv/P0koJPrzDX/ibGQdQgbLBE1RFI+Jh7OK+k4/bu9OTgOpThHonMWgUEIR
	XD5tobihuB9xg=
X-Google-Smtp-Source: AGHT+IHYOJ/m4LZU+MYkhd+4VpPHnPSCBqI3ScgO3G6RETwNk4ZL2qvwaJO4dVa6IRKxQ2Me+WPtjg==
X-Received: by 2002:a17:907:86a3:b0:ade:a7b9:fa34 with SMTP id a640c23a62f3a-adfad43d8f6mr848269766b.45.1750057785854;
        Mon, 16 Jun 2025 00:09:45 -0700 (PDT)
Message-ID: <8ec281cf-0492-46b3-ae6b-ec3f2e595498@suse.com>
Date: Mon, 16 Jun 2025 09:09:44 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [MINI-OS PATCH 12/12] kexec: do the final kexec step
To: Jason Andryuk 
Cc: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org,
 samuel.thibault@ens-lyon.org
References: <20250321092451.17309-1-jgross@suse.com>
 <20250321092451.17309-13-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="------------A4dlste03f9KB1rlEcMDuTgz"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------A4dlste03f9KB1rlEcMDuTgz
Content-Type: multipart/mixed; boundary="------------7aUcww5pQYfuuokapTbgzTqU";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Jason Andryuk 
Cc: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org,
 samuel.thibault@ens-lyon.org
Message-ID: <8ec281cf-0492-46b3-ae6b-ec3f2e595498@suse.com>
Subject: Re: [MINI-OS PATCH 12/12] kexec: do the final kexec step
References: <20250321092451.17309-1-jgross@suse.com>
 <20250321092451.17309-13-jgross@suse.com>
 
In-Reply-To: 

--------------7aUcww5pQYfuuokapTbgzTqU
Content-Type: multipart/mixed; boundary="------------wkfD8VS06aXqbg0nPhKKGd3p"

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

T24gMTQuMDYuMjUgMTk6MzksIEphc29uIEFuZHJ5dWsgd3JvdGU6DQo+IE9uIEZyaSwgTWFy
IDIxLCAyMDI1IGF0IDU6MzDigK9BTSBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+
IHdyb3RlOg0KPj4NCj4+IFdpdGggYWxsIGtleGVjIHByZXBhcmF0aW9ucyBkb25lLCBhY3Rp
dmF0ZSB0aGUgbmV3IGtlcm5lbC4NCj4+DQo+PiBTaWduZWQtb2ZmLWJ5OiBKdWVyZ2VuIEdy
b3NzIDxqZ3Jvc3NAc3VzZS5jb20+DQo+PiAtLS0NCj4+ICAga2V4ZWMuYyB8IDE3ICsrKysr
KysrKysrKysrKy0tDQo+PiAgIDEgZmlsZSBjaGFuZ2VkLCAxNSBpbnNlcnRpb25zKCspLCAy
IGRlbGV0aW9ucygtKQ0KPj4NCj4+IGRpZmYgLS1naXQgYS9rZXhlYy5jIGIva2V4ZWMuYw0K
Pj4gaW5kZXggMmRiODc2ZTguLjg1YjA5OTU5IDEwMDY0NA0KPj4gLS0tIGEva2V4ZWMuYw0K
Pj4gKysrIGIva2V4ZWMuYw0KPj4gQEAgLTE2OSw2ICsxNjksNyBAQCBpbnQga2V4ZWModm9p
ZCAqa2VybmVsLCB1bnNpZ25lZCBsb25nIGtlcm5lbF9zaXplLCBjb25zdCBjaGFyICpjbWRs
aW5lKQ0KPiANCj4+IEBAIC0xOTIsNiArMTkzLDEzIEBAIGludCBrZXhlYyh2b2lkICprZXJu
ZWwsIHVuc2lnbmVkIGxvbmcga2VybmVsX3NpemUsIGNvbnN0IGNoYXIgKmNtZGxpbmUpDQo+
PiAgICAgICBpZiAoIHJldCApDQo+PiAgICAgICAgICAgZ290byBlcnI7DQo+Pg0KPj4gKyAg
ICBrZXhlY19wYWdlID0gKHZvaWQgKilhbGxvY19wYWdlKCk7DQo+IA0KPiBrZXhlY19wYWdl
KCkgaXMgcmVmZXJlbmNlZCBhbHJlYWR5IGluIGRvX2tleGVjKCksIGJ1dCBpdCBoYXNuJ3Qg
YmVlbg0KPiBob29rZWQgdXAgeWV0LCByaWdodD8gIEkgZ3Vlc3MgdGhhdCBpcyBva2F5Lg0K
DQpZZXMsIHNob3VsZG4ndCBjYXVzZSBhbnkgaXNzdWVzLg0KDQo+IA0KPiBJZiBub3QgYW4g
QVNTRVJUIG9uIDEgcGFnZSwgdGhlbiBhbGxvY2F0ZSBLRVhFQ19TRUNTSVpFPw0KDQpIYW5k
bGVkIG5vdyB2aWEgYW4gQVNTRVJUKCkgaW4gdGhlIGxpbmtlciBzY3JpcHQuDQoNCg0KSnVl
cmdlbg0K
--------------wkfD8VS06aXqbg0nPhKKGd3p
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-----

--------------wkfD8VS06aXqbg0nPhKKGd3p--

--------------7aUcww5pQYfuuokapTbgzTqU--

--------------A4dlste03f9KB1rlEcMDuTgz
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/Ey8FAmhPwzkFAwAAAAAACgkQsN6d1ii/Ey+d
4Qf+PzkYR5iEiTxWy9+kmeG83qC1jG6gN1TKBhynJneUSMsZEuXQuNCcueKxOIFiMo8AjJJ3Ryrh
S1gJCfH/YbNQ+aEojbVnUgPWTM+W/g3Vdqqx7uwvhMtkqAqCoGpe+27XblmVf8ol6qk2EBWcU0zv
dBh5liNl5WZzXO3WojgzhJHvv9dDyejDzAGGvQTQVraZvyJrT0QOlT/7jYuc/e2Uc4dJIFRlL7wK
Q8NOznh1eRykTflUzVZyP9pvM/1fRu5FwBVwuto9+FDJrizgWyiRG2WPr4iq2lsBcDX2W8lqwbRj
MlT1PMBvQLJ4C2Vt3yNioGcCcgMR8D3SJz2IKEwe+w==
=tEZy
-----END PGP SIGNATURE-----

--------------A4dlste03f9KB1rlEcMDuTgz--


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 07:35:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 07:35:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016792.1393719 (Exim 4.92)
	(envelope-from )
	id 1uR4Ne-0000gv-Ax; Mon, 16 Jun 2025 07:35:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016792.1393719; Mon, 16 Jun 2025 07:35: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 1uR4Ne-0000go-8G; Mon, 16 Jun 2025 07:35:46 +0000
Received: by outflank-mailman (input) for mailman id 1016792;
 Mon, 16 Jun 2025 07:35: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 1uR4Nd-0000gi-K7
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 07:35:45 +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 828f4775-4a84-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 09:35:43 +0200 (CEST)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-60780d74bbaso7514267a12.0
 for ; Mon, 16 Jun 2025 00:35:43 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-adfbfe03b0csm295507666b.121.2025.06.16.00.35.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Jun 2025 00:35:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 828f4775-4a84-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750059343; x=1750664143; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=KgpIFXhOjQrAaVZ03e/X9OuEuTN4xN5zksV4vQsJo/g=;
        b=JyNLIiH/MM9S5WeTaCJyTL4vFjdsqn+E181gG+dz0/KkL1ELhy9aCDegdAyMZJ2ZSh
         1bgtwM+vd7rfycnKIGHf8OR7AQW76ZWMDPA3dvKdzMuWmPsyR0h3GDrRPy495pC8WFSL
         chVVJBevJ0hYVSo4dsKTY97UgYvXSDIJKesPNKYaZvNnG7iQVMdpEqa+nYIvbzRq/Kca
         biX6ee7QjuheAwnub2iZ1J+CGCJ671Jj/3H7Dw3iwNlZuZmO+Bl/px0Ho3a4t4thF9aZ
         eTQlr5ikxc8cWtpFItQEF0FgR+w48fW/V9k06Bkvw2s4nmmz7Ik+wvYkT+tOf8+kJjqd
         Nywg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750059343; x=1750664143;
        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=KgpIFXhOjQrAaVZ03e/X9OuEuTN4xN5zksV4vQsJo/g=;
        b=M1gX1XRM3mKiHISS3sI5UA0gRRK3IdfTwQLwHrHK9PwadbXY6etUiT+WweHNZcXsIu
         1U4MIFr06Gg9buQuGdgnD5f29vDZ2B4qnGL8TMU7J0QMexpwuqfSl4YoN4SJtvn17Q3w
         6IOWNzpzL00ejPu/xFeZKfGRqnHMSSqjA0NIvc1++XE5F4lCZJ+A8hcZt4XzAQTRP8Cg
         rkl7vBzcaALT3PmlnOHsrAC1JFkPuTUQPg0KgVoXy+IgOiyeawSuqVWuo+xMK4ryt3YK
         am2Zf9aYhVti/I977VGhugUuDcqQj8TvXixgCi25rRrC05hE2is50/6PZapIwjHzQH9v
         mu3w==
X-Forwarded-Encrypted: i=1; AJvYcCVi//RgpDibZbi/RLXitCzEzr1awFQw8A7699KEJZ2vgydmAEmWwtg7i5clUJNJg12gOT6GCrEvA98=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyQHDPohJySVLhmIJJQjc0dIY8250siyQeoTgnb14yyqENFCCV6
	ruGTQVqCN1S+oOBVHH9poIAo9wft9t6/x6ziXdDD/XS7/sTXTA1Qt7afDk9lcwLPYg==
X-Gm-Gg: ASbGncu00SlFrllZ5A81Ln2P+fhhOPx04N8TwHj0XYCyJiJfKYNDq5RpmrThDSWH5ax
	bx5KNKVLOlwHVjx5Vi7y8HMBklwcBTZ+wI7kK4Jd2J+EIqwDFAZvpCgzHWC+bs7+V/PC6aS4qjX
	zxIJ2+YbipoOoKU4leQd/kCI7k9E6+LrxD0Q4Tbx+nezdHOb0eTUKhJXsjnJcBe1TNdbWn0OKlw
	tyzaQ6QKxDHG/cXGVErKrC8FSiNbhR7iJYAUZjarmr482Qz6mU0SWOE1n1DIlHuq/pOu++I8A/V
	eMXd4JoiVjQpcgL5dgLJiNgyfI1e7k/0e28/qKiHpKXHyN+3VVEGG8DeFQFGBReLUSJ294luueI
	p/VH0L6yCINMwrcJwGjz2m1e4R2c824ZvAl7GiH5MEVmDb84=
X-Google-Smtp-Source: AGHT+IFVVX4/32PLwF5Tme9MJZUF562d94YZCxXWEa443tlDT5ZW9/6ddlsgZxYa/kKB60brN806AQ==
X-Received: by 2002:a17:907:3d04:b0:acb:37ae:619c with SMTP id a640c23a62f3a-adf9e1d9404mr801302566b.15.1750059335649;
        Mon, 16 Jun 2025 00:35:35 -0700 (PDT)
Message-ID: <51d57968-0060-4c53-9c7e-3cabd84c0a4a@suse.com>
Date: Mon, 16 Jun 2025 09:35:37 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/arm: Fix P2M root page tables invalidation
To: Michal Orzel 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk ,
 xen-devel@lists.xenproject.org
References: <20250616065648.17517-1-michal.orzel@amd.com>
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20250616065648.17517-1-michal.orzel@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.06.2025 08:56, Michal Orzel wrote:
> Fix the condition part of the for loop in p2m_invalidate_root() that
> uses P2M_ROOT_LEVEL instead of P2M_ROOT_PAGES. The goal here is to
> invalidate all root page tables (that can be concatenated), so the loop
> must iterate through all these pages. Root level can be 0 or 1, whereas
> there can be 1,2,8,16 root pages. The issue may lead to some pages
> not being invalidated and therefore the guest access won't be trapped.
> We use it to track pages accessed by guest for set/way emulation provided
> no IOMMU, IOMMU not enabled for the domain or P2M not shared with IOMMU.

IOW no security concerns?

> Fixes: 2148a125b73b ("xen/arm: Track page accessed between batch of Set/Way operations")
> Signed-off-by: Michal Orzel 

Credit Oleksii with a Reported-by?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 07:39:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 07:39:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016798.1393729 (Exim 4.92)
	(envelope-from )
	id 1uR4Qk-0001DL-OG; Mon, 16 Jun 2025 07:38:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016798.1393729; Mon, 16 Jun 2025 07:38:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uR4Qk-0001DE-LS; Mon, 16 Jun 2025 07:38:58 +0000
Received: by outflank-mailman (input) for mailman id 1016798;
 Mon, 16 Jun 2025 07:38: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 1uR4Qj-0001D8-LQ
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 07:38:57 +0000
Received: from NAM04-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam04on2062d.outbound.protection.outlook.com
 [2a01:111:f403:2409::62d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f3fc8996-4a84-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 09:38:55 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by CH2PR12MB4085.namprd12.prod.outlook.com (2603:10b6:610:79::9) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.18; Mon, 16 Jun
 2025 07:38:51 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8835.027; Mon, 16 Jun 2025
 07:38: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: f3fc8996-4a84-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=gvRu9TFyPKCgnPMeflae0wu0y2Lgb+S4sJq1h2FNBtBPO6/fNR1/kvl3VF83bJP/8DgORSskZWqQEUGimjWy/ssf1mPZnTsuUVeILCy4zum19QNQFNA0Dsnk5jvtYzMT3mNnrflkOQfMEMNC/OGuQHn/kP8tP3xwUZhMXbJUe0rKysu1HRPuhK2B1FWido1v7Vt+i+bBSsojvJM18AuU57WAy16PezB5lSwoLy2hYEoLWakVzX+i+JKGwT/AjOZ7uZnsxxudpwNdIl/By7s7W0qth2iLNZX7LC8ARRElSAkmcD+tRFl1bVoie8Q/spjPqgayR5Yj4jylGjD9RCHxOw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=EYPssxpM01uvcl1obr7ERAD+Jpn7E9jmoJc7gDu1iTA=;
 b=E2mh4TfkfdD8oaY+IJtVeUOzueCUniAkCvL5kb7M8WIFER4rH+UNI+1w2V1YIw3vduRo+khONUd8la2NQrl3zmRGgdAN9YDcn7tacN9lLO/itxDEYwcVanY3zIgdeM6K6gQCiKZeHEFBP9gyYDCr5s8DxPXi38z7/mQj4seBQYznRVic4YZxwmHvIS4/yzK5eVSkX9AFdMBT+TD06gizY13X8TxJHGwD9g4X135+0YO+wN1ojeXVXJdqy1byoOVmpfazVxQlPFOZx2Q0+Ryan9n26UKM7g2Vn6j8gNH1XTpT5k9040ZndOFMVOMO4nWM+SlfnSQythZ2UjxYritJbA==
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=EYPssxpM01uvcl1obr7ERAD+Jpn7E9jmoJc7gDu1iTA=;
 b=Ax0v+YRCY4rUvGVL8YBcZV1hS7Dq8fPAz0jQZIKoHA7keqQ2s72cpT7okxbA9QmeJzTdEnUmTUTaIePYlGevmo2+/fMGR9Mvkb8XQNzi4S7JG9Z0iGO1TZWYdakAqBC578OQE1N2kzAYDv+xNPpeVu6K/6xFbNTkDhNz/Ek9mUA=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <9ed81c2c-d9b4-4941-a512-f4785a637652@amd.com>
Date: Mon, 16 Jun 2025 09:38:46 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/arm: Fix P2M root page tables invalidation
To: Jan Beulich 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk ,
 xen-devel@lists.xenproject.org
References: <20250616065648.17517-1-michal.orzel@amd.com>
 <51d57968-0060-4c53-9c7e-3cabd84c0a4a@suse.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <51d57968-0060-4c53-9c7e-3cabd84c0a4a@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: PH8P220CA0030.NAMP220.PROD.OUTLOOK.COM
 (2603:10b6:510:348::15) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|CH2PR12MB4085:EE_
X-MS-Office365-Filtering-Correlation-Id: 66b136f4-632c-464e-c568-08ddaca8d6c4
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?eWZZZ3hNWSt6ZlRkazRTV3QyQXVXZm1XRlB4aTcxeTZrd29yZmRKWHlBUzg2?=
 =?utf-8?B?amJhTmZ2azBaeU5sdmRHSnBPQkNyYXJBZ1cxejFEd0ZOZ0UvMUcwMVVzMW1y?=
 =?utf-8?B?c1VCMnNjQm56Ymt0OHozK3lZWWRJKzRSR1FMQXJSWHNmbHl0L3l3UUF5NFF4?=
 =?utf-8?B?MXIzUmZOZGFHK1oxTDVhREJqWUlDTngzTnlwdmtWS0lrdFhJQ2FmK25oSTc0?=
 =?utf-8?B?bWwxQTlhTzFnVzFOUkJ2Y0lveW5aNHF4VkZjcDlXUXhLc3pjdm5maTdGc2Zy?=
 =?utf-8?B?UC9kM1NTZ2N1SXhtU0JiWFA4SytlM3hlQ0pxeWVSMHVHYVZIU0pXb2Q3ejJv?=
 =?utf-8?B?TnBML2l3YitIMG5rbW5zZ0RrVkxtMjdzY2UyNlBBYmw5NytOVWk3R3hPTVJH?=
 =?utf-8?B?MTM2RmRFRGs5aW1vU29oRlAwcklreXB4UGRPelFxTHd2OWxQQzJ2eElQTTRS?=
 =?utf-8?B?dXQ3elh2Q0MwZlllQ1ZIQnRKMkRIMHptRkw5SnM2TXNEWk5tdzF3L3RrK3JY?=
 =?utf-8?B?bTR0MDNLUUVkUis1TDVrQ3dNOEU5RHR1c2U3aXgzMEw0aWw1aURQMCtDV1Q3?=
 =?utf-8?B?YmJRcGhnTytwLzlzdk9yQ1h2UnZMR2owa3o1STBoODUxdmsyODEzU29nZHlN?=
 =?utf-8?B?eVpyUXhuRFJGMXl6Wm0rOFhMWDhxS0VFTmpjZzllZEMvRkMzNUVkWCtIVXgx?=
 =?utf-8?B?SEZ6M2M1cGZlSHc1a2dLQUtrV3hXbHliVnhzeGlRbWVqZytydUxBUDNUVzY1?=
 =?utf-8?B?UUh5QXl5amtUOXpKczdGR2txN3pFeFY4TXJDNXhyU3kzOGhSRGhyOGtYSllI?=
 =?utf-8?B?Z3E1SDJnQjVuM2NtTWNOMG9wVFNUcWZobVdZMmhiYkVCQmhldUE4dkpyWmRl?=
 =?utf-8?B?RWNtQzNQbEtjVnZLS05DUm0vSUIrZG5pZmpIckxmSkVkWVpSRGJVYUFzaWlv?=
 =?utf-8?B?eHFYRVNMRHh0K0FNc1MyZ1ZLV2NkV3pVTm8rM0hyVXFxbGlpRlhsVzRQYlFB?=
 =?utf-8?B?TnBucmZLeDBSa0s4cGFCRTdheG5YZHR5N2tJTktYcjl3WUdLR0cxSGxZTHo0?=
 =?utf-8?B?bDBXQlp6alA5SFpOU0ZVWmMyeWRNZGM5MG5laG5aaG9TZUFiV0hqVko2czRl?=
 =?utf-8?B?MUh6TElEdlZmZ1FuVEdSR3dGQ2l5T2N3NmZPU1NHU2tyUFAwbHFiRXhuQXdC?=
 =?utf-8?B?NjNKc3I4TUc0VC81ZVVuRncyUGU5R1ByZTVKbmo4aEVuMXdEQXR5ekNTc1JG?=
 =?utf-8?B?MlAyZ0U2K0lsVjBucG9ialR5bW0wd1RwSjdjYWlXWWo0Z0tYWmlTU0VORkVj?=
 =?utf-8?B?TDJKRjZxb3h4MWxYd0E5c2RmVDZPMTVyUTh2OFg2czREdzc3S1JRclhtekdF?=
 =?utf-8?B?REJZZjlXRktBeU05NW5NdWpqVVFzRnI5cUNDTnkyZXgwVWFhZG5sRllvOUhJ?=
 =?utf-8?B?QS9jSFZMRkU0NzhQeXFDLzU1UjV5SFNzR3VGK1VzVlhxaUh6NDJjTm5UbE04?=
 =?utf-8?B?NTRUMFN2cXgvbVpsNU5qT0QwcEtrQldVNGpwTStTNUZmbTVXa0RrZ0tYR05q?=
 =?utf-8?B?dHJmeHVSWGFvS3NoZE9ZSnMxb3drUWdmc1lOdFJWUC9Wamk2YnIxTjFZZTFj?=
 =?utf-8?B?N2x5RGtlK2lBbFo2OW42eStFbkQ0bmltMU1QUUE1L2sreTJDa2dkZ1ZtTXZK?=
 =?utf-8?B?VFk4ZzAyZFBVODVEdnRzZ0N2ZnZOVUYzdytXcmZOZmZ6MUI5eW0yMEprVG9k?=
 =?utf-8?B?WElSVEFnMXhPUHovRUtsbmhKWko2OTRFWXZ1aTF4aDI5WWtyYVJXK0dGWHRv?=
 =?utf-8?B?a3VnVnJXa1ZOVGJYdnc2bWhRZTd6dGdIUWZGN1dXc21Ibm1EaEo4NWQ0bDMx?=
 =?utf-8?B?dWFnQ2pWRjB5VENubFlYZzNkanUrc2xUdXg0NHZoZERHaEE9PQ==?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.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?ZkViTnVneGx6TjlBRnBGZXR1TFZKTzRrWGZzWjVabGY4SWdFL2kxcVpBYkE4?=
 =?utf-8?B?SlVGaGZUVXdwUXdHcHF2U0s3dEZaYnMzOUdPTHVFaVVXUXZGTzJxT2lhR00x?=
 =?utf-8?B?cTJSSXd0Ujg4emFQbHV1QzliRW1sTHNUSmpKK1hTem91STh0bjZhSXU1b1ZP?=
 =?utf-8?B?c2gwYVVNRXhsQlNnWWtKakhzRzY1ekE1UGRNWUNVY1pGanNkSFdHYTdNZ2JJ?=
 =?utf-8?B?WWQ2bmNLUFhmaG4wenlUTmRSSjJDM2tpY25UM1Bvc3RFTmdPZGxrZmNPV01I?=
 =?utf-8?B?NFVkdXVEc29TYlZUTXlQSjZUMnl5V01jWHVSSDJEaDEwa0Fpc1lCa3BsN1hJ?=
 =?utf-8?B?SWdSVEttUVVoYWI0UzRyeWlPUjVEc09kdVZsNFJYcG40Nk5aWVdiT0k1MUtW?=
 =?utf-8?B?RTZZbGFqN3hWeUdleC9qeVlPaHkzZjRKdXozdzNOWUY0dE1VQ2o1V05qRHRn?=
 =?utf-8?B?YklsL1JYUlNpSlJWUmpMREpUWUtVYjI3MXhwN1B6NjM1TE5nRS9GMU9oNnZL?=
 =?utf-8?B?UG1RVW9VVjVGRndLU2FsaXBRaHcwTU9QZHZ5RkNVRGlUQ1I3aG9HQ1BkZCtL?=
 =?utf-8?B?RjA4ZllGZXZ2dWVPN0FJbXNIWFZtdXBsZ0hwOWlFZGNYM1d0Qis0czZSWWMx?=
 =?utf-8?B?S2pUZ0ZkZGlyb3p5aFRMUzdzbEY2STd1cnRmcUs2cUpJOFpEOENsOHZOVjEr?=
 =?utf-8?B?ZWhrZzhsUjMrcFlJRElmbVE2RllsdE5BZXl2OFJLYWRyRlN0b2h5MDBQd3BE?=
 =?utf-8?B?WFpRcVgrNEtiVHAvQTlVd1RuUzU1ZU1waUhQVjRnQTEvNllLWURYOGY0WWdy?=
 =?utf-8?B?OUc1bDZBbk1nRGh6bkFzcGNFS0JWWWJjVVgzUTdFT1BiKzJEM1dodXhBVXRW?=
 =?utf-8?B?Nlo3Y2F2bHZTQ3BBWmpGWmtVdUR5YkY2U1AzYUtUSzdLbC93MjBkejFUUi9Q?=
 =?utf-8?B?VVdhZGxHOVRUS1BVaGJKejl0M1RCR1VaYWo1WWVNcHViNTR3TUNOZzFndHln?=
 =?utf-8?B?MjArU01zR01PZnZFUS9qR0RaeTJJQW9DM24raEVQSjc0WkVrZVFWY1VLK0sy?=
 =?utf-8?B?ejZhVlkvbTdSL0lhZjhTejMzOEREWXFDRW4xWGhZdFR1a0dXclV0L2s2YWJN?=
 =?utf-8?B?bWwwWnhIZjBCLysyUnBDazlVeVJUb3YrNHdTNnpmK0tUY0R6K3N6Ri8zcCts?=
 =?utf-8?B?MlpPTjBGNjlnZEFBaGpOZDBKVVdGcWdURDRXcER4MFJPZFdJRE1WY0owVmoy?=
 =?utf-8?B?QVVrR094bjlHb0E2cHFzajdvQ0hJN011SW9oVmxMSEdrNHlPRXo5VDlYYWF3?=
 =?utf-8?B?Y0hBTEplQ3BhdGo0bFJYN0FuZUZEUDc0cjRQSGNYb0R1Mlh4R24vcXlrWXFL?=
 =?utf-8?B?K1RyK21wYVIrLzMyRnZ3TXNkSktXaG9INS9XRldoRDFhaXYwV2kyOC9vK0ww?=
 =?utf-8?B?Zk5uQmFDQ21qSU5DdWROa3FrbVNvV2dvV0hwaktSLy9Zak44MmZydjRMbzFK?=
 =?utf-8?B?WTFYSTl1R3ZadmlmT3lWZXIrSVhBVTlEVDBjZm5uVno0TWU0NkFWTkZweFZz?=
 =?utf-8?B?WkdQdWxwVkhZR3ZkelJBdklQS1lLTE1BRXdWdER5Sm90c2F4NUd3cjNOQS9O?=
 =?utf-8?B?QUFhNW4vRTZjSGY3SWk2L1RYTStqZGN0MUZPSGxqdFR3ekw0UEZOM2o5bG8w?=
 =?utf-8?B?dE1QbzNTOWpocjNUckpBZGZudVVSaTZ5YWNzeE1KOEVUUWQzZzdDM0xaRXhP?=
 =?utf-8?B?SDFQVDNOUFk4UGY4eTVqRUk0bkIvV0pzNldKV0pLbFBPQlUwOE96c0ppVWlp?=
 =?utf-8?B?N2IwcGhmM0hrdVUzZXJJVkxrYk1GMktIYkdUbTg5ZVNmTDk1S0h6VmZTb2Jp?=
 =?utf-8?B?QUZlWHkwaVd0V3Q1YTNYZkhHQXlrZGpPOU1lcG9BaGZObk9VSThtZHhFa3E0?=
 =?utf-8?B?bkNTYVNGVHc1L1lSaUlHb1hYYk45UkpHRkZ3RlJZeUc5MmNzWk82TWFJcEpx?=
 =?utf-8?B?RS9obllZTzdWZi9uWUp6L05Hd3FXWnl2cjYwYlVHM2JTZDNRa1JxRVNyRVA4?=
 =?utf-8?B?UkdncWYxUS92am1vSUJHMm43SkRRN0t4WmMvMVpFMjRHem1lQUNVclkwM0lt?=
 =?utf-8?Q?mJrE=3D?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 66b136f4-632c-464e-c568-08ddaca8d6c4
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jun 2025 07:38:51.5790
 (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: PFAFDJVODt+eqv0QO4Fpom8h/qaY/BGRSAL2Y4nZ5TNF7vegqD/8Ey26125UNMxh
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4085



On 16/06/2025 09:35, Jan Beulich wrote:
> On 16.06.2025 08:56, Michal Orzel wrote:
>> Fix the condition part of the for loop in p2m_invalidate_root() that
>> uses P2M_ROOT_LEVEL instead of P2M_ROOT_PAGES. The goal here is to
>> invalidate all root page tables (that can be concatenated), so the loop
>> must iterate through all these pages. Root level can be 0 or 1, whereas
>> there can be 1,2,8,16 root pages. The issue may lead to some pages
>> not being invalidated and therefore the guest access won't be trapped.
>> We use it to track pages accessed by guest for set/way emulation provided
>> no IOMMU, IOMMU not enabled for the domain or P2M not shared with IOMMU.
> 
> IOW no security concerns?
I discussed this with Julien and we don't think there are any.

> 
>> Fixes: 2148a125b73b ("xen/arm: Track page accessed between batch of Set/Way operations")
>> Signed-off-by: Michal Orzel 
> 
> Credit Oleksii with a Reported-by?
Sure thing:
Reported-by: Oleksii Kurochko 

~Michal



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 07:50:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 07:50:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016808.1393738 (Exim 4.92)
	(envelope-from )
	id 1uR4bb-0004EZ-S1; Mon, 16 Jun 2025 07:50:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016808.1393738; Mon, 16 Jun 2025 07:50: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 1uR4bb-0004ES-PE; Mon, 16 Jun 2025 07:50:11 +0000
Received: by outflank-mailman (input) for mailman id 1016808;
 Mon, 16 Jun 2025 07:50: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 1uR4ba-0004EM-SE
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 07:50:10 +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 85dd8adc-4a86-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 09:50:08 +0200 (CEST)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-6086502e750so8056884a12.3
 for ; Mon, 16 Jun 2025 00:50:08 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-608b4a5e6dbsm5659778a12.51.2025.06.16.00.50.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Jun 2025 00:50:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 85dd8adc-4a86-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750060207; x=1750665007; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=6kIqImNNLiwwjb6q/5i63GH9z5wMs+JvGmTmcsIbFDY=;
        b=bA6PRGU54sSbPveP4DkfTI0Xf/qip15WVFka2bMZNN8z5DO6ACCkyzRMMHCZtbnBBM
         gAYl4CZr7DFB49Fh9/yLFhSuAJaAwIXmIHuCjB8hY0c9K63MPOwvk8zc45BO1UC/3tjE
         jxYOkFeYaw6XsW5cfNyP4iQKTpp2g9sr3ld7g217Qu42InSxpk5l6QFA00HdDCN2ucAw
         fl53XCjZf7eF7u1zqunQ6ZCU1vgP46sR0/LHROCRHVMdc1MgAnLsuUxv+0WjVpCaJ1NF
         1aS7tx9UVPtY18w4Ibu3m8XqEujv2CgddaNBMclytwLj/00g9rA/X5UXUjDuutCO5h49
         skow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750060207; x=1750665007;
        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=6kIqImNNLiwwjb6q/5i63GH9z5wMs+JvGmTmcsIbFDY=;
        b=Cv9sWDeEf/v7enlI06G3Tg7Wh6T2ub4Ga064uaDO2t2auaSsGzc+zslfhFgXcP0WCw
         hygOhLmfsUuCVN0ZXCxjUkAy2zbLMnwKEvBEXA/iC+CgQWuQqYjeqZc5g23xWUTjt4x5
         yDG4ZDvbtOlRCf73gPe/Cd/ar67mRDECx21VrS2eKwKbJjK9+WU5+Mxm/53rUwy8rbvl
         mytg9XtbXHw8jsEzpLpyO+rlEucsvPG2pHINYnu1X8Cd+joiWCwfT3DWhr2tIKFvkn3B
         C7coOF5CLbSEEgP6AL/q0BY/SvGGFwyAdBQT1eIPUGOLnxsw9a+qz9VbL6l7SFxhviYL
         oBfg==
X-Forwarded-Encrypted: i=1; AJvYcCVKCUYDO71mazFWIupHSXvx9mZPUUr89U6GdR8gXDY8vKwbM3GzdSIFuMGwFzzrEr/YoH5CqrLQyWQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzR7iSX9IP9X/ZGrVxNTH9S4LqWXkwvwTOPskd69M20QC+da9tW
	7F/miiJzLBbklsY96KnfJZAE6/FlgiZYNLynzRcgbDQIxT7Hn7IFseg8mO7yc4iPxA==
X-Gm-Gg: ASbGncuCyysnD+l+5IMtEPNebvcic0c/lc1DiJ5v18KGTM90KBcXkEkm3TthgQYhYfZ
	qvmsA5jAV+NnJnu2U/rfobmSr3WH3w6aU5Do8/p3Nf3ryJ5rI6941tryQYFwr6MOyczesT3mrRI
	vL4+VgJpk22Kafv6dOehOyKGYMX9ZRVvhBcuwGBNeNNg63gN2UYAQlZOGaCuVpTwCQ4l5xg69gw
	zoi9meWaqvy1HBNxR/+0HHkRXXQ/lTVxIkbUDS9tAizruUXtM6lEi3kWhXOpclaVy/DxVl/XX6O
	ulGFf5PKPN4FGK2Ob6GFEjQB/UxJyWPiUb73qik6Kv3rIAe4Gtvr+kFFpyX1Q9Nnngqw5Qwsr0m
	r8XUuNsxl54UisW/Mo5b3F8kIntfP/a9QsS/aboRKU6ps4R4=
X-Google-Smtp-Source: AGHT+IHnm7ai6HUDdqsIVS3g0Gus5Ugui0QCT4/6sE+UE6ajE0UNX5U/Ri/qUMEqmr0fpL4E7mSYvw==
X-Received: by 2002:a05:6402:5245:b0:606:c5f9:8aea with SMTP id 4fb4d7f45d1cf-608d09aafdcmr7487746a12.16.1750060207557;
        Mon, 16 Jun 2025 00:50:07 -0700 (PDT)
Message-ID: <65183375-e9ce-4bbb-8f32-1ea9b3a53a60@suse.com>
Date: Mon, 16 Jun 2025 09:50:08 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 6/8] pdx: introduce a new compression algorithm based on
 offsets between regions
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Anthony PERARD ,
 Andrew Cooper ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk ,
 xen-devel@lists.xenproject.org
References: <20250611171636.5674-1-roger.pau@citrix.com>
 <20250611171636.5674-7-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: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 12.06.2025 16:03, Roger Pau Monné wrote:
> On Thu, Jun 12, 2025 at 10:27:03AM +0200, Jan Beulich wrote:
>> On 11.06.2025 19:16, Roger Pau Monne wrote:
>>> With the appearance of Intel Sierra Forest and Granite Rapids it's not
>>> possible to get a production x86 host wit the following memory map:
>>>
>>> SRAT: Node 0 PXM 0 [0000000000000000, 000000007fffffff]
>>> SRAT: Node 0 PXM 0 [0000000100000000, 000000407fffffff]
>>> SRAT: Node 1 PXM 1 [0000061e80000000, 0000065e7fffffff]
>>> SRAT: Node 2 PXM 2 [00000c3e80000000, 00000c7e7fffffff]
>>> SRAT: Node 3 PXM 3 [0000125e80000000, 0000129e7fffffff]
>>>
>>> This is from a four socket system, with each node having 256GB of memory.
>>> The total amount of RAM on the system is 1TB, but without enabling
>>> CONFIG_BIGMEM the last range is not accessible, as it's above the 16TB
>>> boundary covered by the frame table.
>>>
>>> Note that while the memory map is very sparse, it won't be compressible
>>> using the current algorithm that relies on all ranges having a shared
>>> zeroed region of bits that can be removed.
>>>
>>> The memory map presented above has the property of all regions being
>>> similarly spaced between each other, and all having also a similar size.
>>> This allows to compress them using the following formula:
>>>
>>>  pdx = (pfn % offset) + ((pfn / offset) * size)
>>>
>>> Where offset and size are two static coefficients calculated at
>>> initialization.
>>
>> What I would find useful here in addition would be offset and size values
>> resulting from the example memory map above. In particular, without looking
>> at the code in detail, it doesn't become quite clear how the two ranges on
>> node 0 are being dealt with. For what follows I'll assume they'd be folded
>> into a single range covering all of node 0.
> 
> Indeed, they are folded into a single range, that's why the function
> to register ranges takes an ID, so that for this algorithm ranges with
> the same ID are folded together.
> 
> For the above example the offset (pfn based) is 0x63e80000 and the
> size 0x8300000.  You can see those (and for all the other examples) on
> the test-pdx-offset.c file.

Oh, okay; didn't think of looking at the numbers in the test.

>> Along the lines of Andrew's concern regarding the division (and modulo)
>> involved, I wonder whether there might be an alternative with a lookup
>> array, holding bias values (e.g.) for each node. Main question there would
>> be how to quickly determine the array index to use, both from an incoming
>> MFN and an incoming PDX. If such an array wouldn't have too many entries,
>> such a lookup may end up being faster (on average) than a division.
>>
>> Taking the example above, such an array could be:
>>
>> [0x00] = 0,
>> [0x06] = 0x061e80000 - 1 * 0x5000000,
>> [0x0c] = 0x0c3e80000 - 2 * 0x5000000,
>> [0x12] = 0x125e80000 - 3 * 0x5000000,
>>
>> indexed by the top-so-many bits of the MFN. For the reverse array some
>> gap would need to be left between ranges (i.e. the 0x5000000 above would
>> perhaps need doubling; maybe a little less than that would suffice), such
>> that the array slot to use could be determined easily there as well.
> 
> I've assumed that any kind of lookups like this would end up being
> slower than arithmetic transformations.  I had the (maybe wrong)
> impression that having to fetch the adjustment from an array based on
> a calculated index would result in slower code that using constant
> coefficients.

Latency and throughput of DIV are quite a bit higher than those of memory
reads, assuming such reads come from a relatively hot cacheline. Then
again comparing such merely from spelled out numbers in some docs usually
doesn't work overly well.

> I was also worried about the extra memory consumption of this
> approach, but overall we can use a full page for the lookup table,
> which would allow up to 512 entries and that should be more than
> enough.

In the example above far less than a page should be needed. In general I'd
expect one array slot per (contiguous chunk on a) node.

> I can try to code this suggestion.  However it's hard to benchmark
> those algorithms, as the cost of rdtsc shadows the cost of the
> operation.  Then running the translation in a tight loop and averaging
> the result also doesn't seem very realistic, as the cache is hot in
> that case.

Except that, the fewer entries such an array would have, the hotter the
cacheline(s) can be expected to be anyway. But yes, gaining a clear
picture may be difficult. Then again please recall that my earlier
patching attempt (using BMI2 insns) was also rejected mainly on the
basis that the insns chosen are known to not perform well on some
hardware, without having taken any actual numbers (which again would
have been difficult to obtain in a representable way) into account.

Overall I'm not sure this alternative if worth trying out. I merely
wanted to point out there possibly is such an alternative, given the
concern Andrew had voiced. In the end there may be similar concerns
here ...

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 07:57:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 07:57:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016815.1393748 (Exim 4.92)
	(envelope-from )
	id 1uR4iy-00056z-ID; Mon, 16 Jun 2025 07:57:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016815.1393748; Mon, 16 Jun 2025 07:57: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 1uR4iy-00056s-Fi; Mon, 16 Jun 2025 07:57:48 +0000
Received: by outflank-mailman (input) for mailman id 1016815;
 Mon, 16 Jun 2025 07:57:46 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uR4iw-00056h-M5
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 07:57:46 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uR4is-004RfA-2x;
 Mon, 16 Jun 2025 07:57:42 +0000
Received: from [2a02:8012:3a1:0:64b5:81ad:1f26:5fcb]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uR4is-0076dH-1H;
 Mon, 16 Jun 2025 07:57: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" 
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=tRt68vllKD5DPfkrucpovmjiVUZriecmU3wqQ4Z+a7Y=; b=6wqG/xgJgS43iJ83njgNsyhCM/
	k8qzfdPq8ihY8TvaokqW3TDDMneGLG6C7SbXZ4AuCR0tb1kU7umpZvnYuUIioKHnSEZciZlPk4iGz
	kUmjxdF3t60cWGiVIwaHxryH9/4IfOSiONJijJY9pricNYK4MBTVLGbedrS36pwiaDmc=;
Message-ID: <93f19ebd-faa1-4811-97b1-2234025aa4b0@xen.org>
Date: Mon, 16 Jun 2025 08:57:39 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 12/14] xen/dt: ifdef out DEV_DT-related bits from
 device_tree.{c,h}
Content-Language: en-GB
To: Jan Beulich , Alejandro Vallejo 
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org
References: <20250613151612.754222-1-agarciav@amd.com>
 <20250613151612.754222-13-agarciav@amd.com>
 <07d0b403-1fc0-4d19-beee-b6960b29c819@suse.com>
From: Julien Grall 
In-Reply-To: <07d0b403-1fc0-4d19-beee-b6960b29c819@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

On 16/06/2025 08:01, Jan Beulich wrote:
> On 13.06.2025 17:13, Alejandro Vallejo wrote:
>> ... which means, device-tree.c stops requiring strictly CONFIG_HAS_DEVICE_TREE
>> and may function without it.
> 
> See my reply to patch 14. I consider it outright wrong (as being overly
> misleading) to build device tree code without HAS_DEVICE_TREE=y.

FWIW +1.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 08:00:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 08:00:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016823.1393759 (Exim 4.92)
	(envelope-from )
	id 1uR4ly-0007KI-29; Mon, 16 Jun 2025 08:00:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016823.1393759; Mon, 16 Jun 2025 08:00: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 1uR4lx-0007KB-Vb; Mon, 16 Jun 2025 08:00:53 +0000
Received: by outflank-mailman (input) for mailman id 1016823;
 Mon, 16 Jun 2025 08:00:53 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uR4lx-0007K5-7r
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 08:00:53 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uR4lw-004SGi-1x;
 Mon, 16 Jun 2025 08:00:52 +0000
Received: from [2a02:8012:3a1:0:64b5:81ad:1f26:5fcb]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uR4lw-0076kj-0t;
 Mon, 16 Jun 2025 08:00: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=Sr2GFh0p96NgK7r+6UcZ3nUuAKzYpE5wYqcOmcSczcs=; b=sC4SnoI31nWx4jJCiCovAftd+r
	ENGx5BdUh1uf0LUl5M7Mrh0HcA2sp29DW95farKeTQZ0TxwM37Nv0dr0SrppkU/5CdJ82GyvQu/WO
	k053u0sCZ4tW0PnBsFJe8sy1N+9MN2QasqJtPVl1eP6mTo+lBbqRRyZXCfkpg4S5bF68=;
Message-ID: <2a54e49b-c1ad-4654-9291-4373e92580ff@xen.org>
Date: Mon, 16 Jun 2025 09:00:50 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 14/14] kconfig: Allow x86 to pick CONFIG_DOM0LESS_BOOT
Content-Language: en-GB
To: Alejandro Vallejo , xen-devel@lists.xenproject.org
Cc: Jan Beulich , Andrew Cooper
 , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Anthony PERARD ,
 Michal Orzel ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 "Daniel P. Smith" 
References: <20250613151612.754222-1-agarciav@amd.com>
 <20250613151612.754222-15-agarciav@amd.com>
From: Julien Grall 
In-Reply-To: <20250613151612.754222-15-agarciav@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

On 13/06/2025 16:13, Alejandro Vallejo wrote:
> Without picking CONFIG_HAS_DEVICE_TREE.
> 
> In order to do that. Allow CONFIG_DOM0LESS_BOOT to enable a subset
> of the common/device-tree/ directory. 
 > x86 doesn't want dom0less-build.c,> as that's tightly integrated 
still to the ARM way of building domains.

I don't understand this argument. dom0less-build.c was moved to common 
and it will soon be used by RISC-V. This raises the question what's so 
special with x86?

Note I don't particularly care if you don't want to use it on x86. 
However, the argument provided is lacking some details... This will be 
useful in the future if someone thinks about consolidating the two.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 08:09:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 08:09:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016835.1393769 (Exim 4.92)
	(envelope-from )
	id 1uR4uO-00082e-Rh; Mon, 16 Jun 2025 08:09:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016835.1393769; Mon, 16 Jun 2025 08:09: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 1uR4uO-00082X-Ot; Mon, 16 Jun 2025 08:09:36 +0000
Received: by outflank-mailman (input) for mailman id 1016835;
 Mon, 16 Jun 2025 08:09:36 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uR4uN-00082R-VL
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 08:09:35 +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 3c98f501-4a89-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 10:09:33 +0200 (CEST)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-60702d77c60so8929894a12.3
 for ; Mon, 16 Jun 2025 01:09:33 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-608b4ae33acsm5642549a12.72.2025.06.16.01.09.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Jun 2025 01:09:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3c98f501-4a89-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750061373; x=1750666173; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=zZfHtjkdrYYmA9/heTYtJ0Yl/vLIy6strWdx3GoU9Gc=;
        b=cFyVnLP1722aaQuYF9uxlgkWTKj+5lHHqaoQILEs/ZfWfBJ7twJ28ocVfby/8c7j3j
         l8MjF1A7KJOYLnOt3R4lbQk7wR8U+OsULFT2giE5gH5h9Sbi31dI7AU91Su2GWFCL5DF
         gB4vEN82QeJ5UvvTeE9Apb9y4TrsVVFKNpcPwrbftZ/N7NK55f4LRv/61KwciXWDoUCR
         CuDMzz06VTXYtvBwN3iDrKd8jr8xqUZGh8H6HLCsuz8RH3DUEq4NQWN6qubWmecv8l6m
         fiSkStdTQEkdAhqP9SEzcfPpWNtmEcvBqTBeh6cfClJgW/7dathzRbByFaMsuQ6HTft6
         P00g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750061373; x=1750666173;
        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=zZfHtjkdrYYmA9/heTYtJ0Yl/vLIy6strWdx3GoU9Gc=;
        b=E5soYm1jAnPVc+FEfUYTZb0Q4n7Ij8PJ0RZrI7ZisbknrghEqiizMnFcIlwfDHoNiV
         K7+rk3JI7bxsikFajOFKAiFcuEHHUW6277JkUGY4eKpuhDwJnxFK4S2rkXSxtu5ECSQq
         xtFqAdl8HtBKPYMH0gPYbRKkrZhVNL3C/d2FlYVHDmqwipgF8XHWee4Ev0j0cLtfDInk
         zy2b2/USqJ2XPG5zP+V7LbZZS04yieFdXyXQ5Lz61WmlZ7pnjIMTVK2zlpCmkKCzRV6H
         uO+QqfE7XyVCL2IndU6CaDhbsI9Ua8uS8vNpEpe9wzucmvtUuMWNdgiP/nZmXDPZv93D
         gmgA==
X-Forwarded-Encrypted: i=1; AJvYcCUBgUACGHiVNaoDfm+A8CA3FhldoxQO7gcaeWkdL6IvZjkItfrMNwiCORdToZa3bF9bZtnDQBPrfoE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzOeO6nxNhhTL+j+OrQuARWG+C4aLHv8E0AsbqPsdtVcBNwQdTh
	lRzClu3mTrpiDS3aKRnzvQ/tloMe4/MR5+54KLz1lTr90T7z+cEjSJrCOOvpXRiYpg==
X-Gm-Gg: ASbGncvBFZbXAgu8j//BoA8VacP4giEQwEieSonNlAI4IbJQk+xqfCeMBPpiixOG/h5
	PypesWZRxCUFe7NIAXpsbM3x2QaFV0+Qnr4EpXAZ+qBYMfiafkzjv/Z2j9IT1fAFlvAYbZT0WVO
	TYK9tbf0OUBPsd+cN5XlA8vnQRpHF+oK7d1/3Et3bYQ+wIvFmL02Sc/OAxdYbm3eKG/KjJDG6Gz
	090Ioh+jsBLW6iOkqPK1xwsHM3PzSE/8/NRLeV8ojxyeveNWWLpIAcf2T+gMYEmoKMhEY1U7xx3
	3et/m8wV9iJQrwudOCciCTcL+Mciobmfwxf1VierQ85HzqB+gV2pVBqNR+XjKw6ch1qv7EVYEZI
	jx3Mih8XOF/ZgkOJt6uEusiUtTyg6rML9nNGxhlz4BXJrKIE=
X-Google-Smtp-Source: AGHT+IHHZG4vs1VM/y0jrZAygfYomS3PxI2UpN7jNa+OF9aBFw7XWH2pNe2RtYtVhV7zBeExwl2gnA==
X-Received: by 2002:a05:6402:2549:b0:602:17a1:c672 with SMTP id 4fb4d7f45d1cf-608d0861a94mr8003525a12.8.1750061373103;
        Mon, 16 Jun 2025 01:09:33 -0700 (PDT)
Message-ID: 
Date: Mon, 16 Jun 2025 10:09:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 1/9] xen/riscv: dt_processor_hartid() implementation
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 13.06.2025 17:48, Oleksii Kurochko wrote:
> Implements dt_processor_hartid() to get the hart ID of the given
> device tree node and do some checks if CPU is available and given device
> tree node has proper riscv,isa property.
> 
> As a helper function dt_get_hartid() is introduced to deal specifically
> with reg propery of a CPU device node.
> 
> Signed-off-by: Oleksii Kurochko 


Acked-by: Jan Beulich 

> @@ -14,3 +17,77 @@ void __init smp_prepare_boot_cpu(void)
>      cpumask_set_cpu(0, &cpu_possible_map);
>      cpumask_set_cpu(0, &cpu_online_map);
>  }
> +
> +/**
> + * dt_get_hartid - Get the hartid from a CPU device node
> + *
> + * @cpun: CPU number(logical index) for which device node is required
> + *
> + * Return: The hartid for the CPU node or ~0UL if not found.
> + */
> +static unsigned long dt_get_hartid(const struct dt_device_node *cpun)
> +{
> +    const __be32 *cell;
> +    unsigned int ac;
> +    uint32_t len;
> +
> +    ac = dt_n_addr_cells(cpun);
> +    cell = dt_get_property(cpun, "reg", &len);

I'll commit as is, but I'd like to note that such could be more compact:

    unsigned int ac = dt_n_addr_cells(cpun);
    uint32_t len;
    const __be32 *cell = dt_get_property(cpun, "reg", &len);

> +    /*
> +     * If ac > 2, the result may be truncated or meaningless unless
> +     * dt_read_number() supports wider integers.
> +     *
> +     * TODO: drop (ac > 2) when dt_read_number() will support wider
> +     *       integers.
> +     */
> +    if ( !cell || !ac || (ac > 2) || (ac > len / sizeof(*cell)) )
> +        return ~0UL;
> +
> +    return dt_read_number(cell, ac);

I'd further like to note that this will silently truncate from 64 to 32
bits (when ac == 2) for RV32.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 08:14:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 08:14:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016841.1393778 (Exim 4.92)
	(envelope-from )
	id 1uR4yo-0001JY-C7; Mon, 16 Jun 2025 08:14:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016841.1393778; Mon, 16 Jun 2025 08:14: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 1uR4yo-0001JR-8u; Mon, 16 Jun 2025 08:14:10 +0000
Received: by outflank-mailman (input) for mailman id 1016841;
 Mon, 16 Jun 2025 08:14:08 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uR4ym-0001JL-Nr
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 08:14:08 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uR4yi-004SUB-2W;
 Mon, 16 Jun 2025 08:14:04 +0000
Received: from [2a02:8012:3a1:0:64b5:81ad:1f26:5fcb]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uR4yi-00775o-1w;
 Mon, 16 Jun 2025 08: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" 
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=fHy39jn/6/6mAfxWaxgiVoi3sXyGx8bJ5mNHgpxp3wI=; b=L04yv9knEY0wf+glKqJ/NOAL1h
	o+IsApv5rTQR84vzLtqcHtvYidp/oRzjmQ6cEgHUIoNbcUr8dDlgCe3COoijfb+NtxMBYGJO2u5zS
	e2stGAuwOqwsiCU6TNNz8aY6Pfl2vTqWb2Ax49hVNfD2HOthRqoqCuyXNP90qrdBhtWM=;
Message-ID: <7f3b4494-7dd7-45a4-8d12-6f8012410a86@xen.org>
Date: Mon, 16 Jun 2025 09:14:02 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/arm: Fix P2M root page tables invalidation
Content-Language: en-GB
To: Jan Beulich , Michal Orzel 
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk ,
 xen-devel@lists.xenproject.org
References: <20250616065648.17517-1-michal.orzel@amd.com>
 <51d57968-0060-4c53-9c7e-3cabd84c0a4a@suse.com>
From: Julien Grall 
In-Reply-To: <51d57968-0060-4c53-9c7e-3cabd84c0a4a@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Jan,

On 16/06/2025 08:35, Jan Beulich wrote:
> On 16.06.2025 08:56, Michal Orzel wrote:
>> Fix the condition part of the for loop in p2m_invalidate_root() that
>> uses P2M_ROOT_LEVEL instead of P2M_ROOT_PAGES. The goal here is to
>> invalidate all root page tables (that can be concatenated), so the loop
>> must iterate through all these pages. Root level can be 0 or 1, whereas
>> there can be 1,2,8,16 root pages. The issue may lead to some pages
>> not being invalidated and therefore the guest access won't be trapped.
>> We use it to track pages accessed by guest for set/way emulation provided
>> no IOMMU, IOMMU not enabled for the domain or P2M not shared with IOMMU.
> 
> IOW no security concerns?

Copying/pasting what I wrote on the security channel for the record. 
(This was sent after you asked on xen-devel, sorry I should have done it 
before hand):

We both looked at the code and concluded that it is guarantreed that 
P2M_ROOT_PAGES >= P2M_ROOT_LEVEL. This means the only issue is an under 
invalidation. The logic is only used for the benefit of invalidating the 
guest memory when using cache flush by set/way. Because of the issue, 
the guest we may not clean & invalidate some RAM belonging to itself. We 
also don't rely on the p2m_invalidate_root() to ensure any scrubbed 
pages content have reached memory. So any under invalidation will only 
impact the guest.

Hence why we concluded it wasn't a security issue.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 08:15:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 08:15:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016851.1393789 (Exim 4.92)
	(envelope-from )
	id 1uR4zq-0001t5-OB; Mon, 16 Jun 2025 08:15:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016851.1393789; Mon, 16 Jun 2025 08:15:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uR4zq-0001sy-Ki; Mon, 16 Jun 2025 08:15:14 +0000
Received: by outflank-mailman (input) for mailman id 1016851;
 Mon, 16 Jun 2025 08:15:13 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uR4zp-0001ss-CV
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 08:15:13 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uR4zp-004SVL-04;
 Mon, 16 Jun 2025 08:15:13 +0000
Received: from [2a02:8012:3a1:0:64b5:81ad:1f26:5fcb]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uR4zo-007779-2l;
 Mon, 16 Jun 2025 08:15: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" 
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=SLkst4DFjN5lE14k+OR7aJJ+TerpwumiVnzjtjwU+AI=; b=5I2ZyNy+EINuRD3Fi7Nzx+Zrg6
	b1z8HGNBYXYTwGOEImmvEfXNNJBqzMoPsIeRgP9+HvUND3esFqe7zkq1NAVNgZIW80GFasZ8aEZXz
	RTDnfsNajHr80qhLazt+KkR6Yr0KhsiHh+E6bGYltbWlbb73+E+WTz0FzNDy8bgplbgQ=;
Message-ID: <6cd8c65a-c440-45e3-9bb1-e8c28e90ae56@xen.org>
Date: Mon, 16 Jun 2025 09:15:10 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/arm: Fix P2M root page tables invalidation
Content-Language: en-GB
To: Michal Orzel , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk ,
 Oleksii 
References: <20250616065648.17517-1-michal.orzel@amd.com>
From: Julien Grall 
In-Reply-To: <20250616065648.17517-1-michal.orzel@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

(+Oleksii)

Hi,

Adding Oleksii for visibility.

On 16/06/2025 07:56, Michal Orzel wrote:
> Fix the condition part of the for loop in p2m_invalidate_root() that
> uses P2M_ROOT_LEVEL instead of P2M_ROOT_PAGES. The goal here is to
> invalidate all root page tables (that can be concatenated), so the loop
> must iterate through all these pages. Root level can be 0 or 1, whereas
> there can be 1,2,8,16 root pages. The issue may lead to some pages
> not being invalidated and therefore the guest access won't be trapped.
> We use it to track pages accessed by guest for set/way emulation provided
> no IOMMU, IOMMU not enabled for the domain or P2M not shared with IOMMU.
> 
> Fixes: 2148a125b73b ("xen/arm: Track page accessed between batch of Set/Way operations")
> Signed-off-by: Michal Orzel 

Reviewed-by: Julien Grall 

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 08:16:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 08:16:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016857.1393798 (Exim 4.92)
	(envelope-from )
	id 1uR51R-0002PA-1R; Mon, 16 Jun 2025 08:16:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016857.1393798; Mon, 16 Jun 2025 08:16: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 1uR51Q-0002P3-Uh; Mon, 16 Jun 2025 08:16:52 +0000
Received: by outflank-mailman (input) for mailman id 1016857;
 Mon, 16 Jun 2025 08:16:51 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uR51P-0002Ox-6d
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 08:16:51 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uR51O-004SYv-2i;
 Mon, 16 Jun 2025 08:16:50 +0000
Received: from [2a02:8012:3a1:0:64b5:81ad:1f26:5fcb]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uR51O-0077CU-2A;
 Mon, 16 Jun 2025 08:16: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" 
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=0vlaOGK/FbiNzZriffdHbblDsVqw2Vqrfhfw/ES0JSE=; b=HW30mwxXJIpUS28CoIV+VomP5Y
	mDAnTUf76ldmQ65k2/HCr7u1+yD9m15nM7Ji2aooIy9zB629D5gc746tkcKFnD3mFsrGTcTHSy71Y
	PkKMyEN1YJSlKh/5D0Ox1w/eet0RL3k6/2iSNk4JuOJBqL4YVdeiDU9IqLdJdyEpawkk=;
Message-ID: <182d8f4f-f41d-4e10-99d9-83be7cc8d2b4@xen.org>
Date: Mon, 16 Jun 2025 09:16:48 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/6] arm/mpu: Introduce MPU memory region map structure
Content-Language: en-GB
To: Ayan Kumar Halder ,
 xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: <20250611143544.3453532-1-ayan.kumar.halder@amd.com>
 <20250611143544.3453532-2-ayan.kumar.halder@amd.com>
From: Julien Grall 
In-Reply-To: <20250611143544.3453532-2-ayan.kumar.halder@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Ayan,

On 11/06/2025 15:35, Ayan Kumar Halder wrote:
> Introduce pr_t typedef which is a structure having the prbar and prlar members,
> each being structured as the registers of the AArch32 Armv8-R architecture.
> 
> Also, define MPU_REGION_RES0 to 0 as there are no reserved 0 bits beyond the
> BASE or LIMIT bitfields in prbar or prlar respectively.
> 
> In pr_of_addr(), enclose prbar and prlar arm64 specific bitfields with
> appropriate macros. So, that this function can be later reused for arm32 as
> well.
> 
> Signed-off-by: Ayan Kumar Halder 

Acked-by: Julien Grall 

Cheers,

> ---
> Changes from v1 :-
> 
> 1. Preserve pr_t typedef in arch specific files.
> 
> 2. Fix typo.
> 
> v2 :-
> 
> 1. Change CONFIG_ARM64 to CONFIG_ARM_64 to enclose arm64 specific bitfields for
> prbar and prlar registers in pr_of_addr().
> 
>   xen/arch/arm/include/asm/arm32/mpu.h | 34 ++++++++++++++++++++++++++--
>   xen/arch/arm/mpu/mm.c                |  4 ++++
>   2 files changed, 36 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/include/asm/arm32/mpu.h b/xen/arch/arm/include/asm/arm32/mpu.h
> index f0d4d4055c..0a6930b3a0 100644
> --- a/xen/arch/arm/include/asm/arm32/mpu.h
> +++ b/xen/arch/arm/include/asm/arm32/mpu.h
> @@ -5,10 +5,40 @@
>   
>   #ifndef __ASSEMBLY__
>   
> +/*
> + * Unlike arm64, there are no reserved 0 bits beyond base and limit bitfield in
> + * prbar and prlar registers respectively.
> + */
> +#define MPU_REGION_RES0       0x0
> +
> +/* Hypervisor Protection Region Base Address Register */
> +typedef union {
> +    struct {
> +        unsigned int xn:1;       /* Execute-Never */
> +        unsigned int ap_0:1;     /* Access Permission AP[0] */
> +        unsigned int ro:1;       /* Access Permission AP[1] */
> +        unsigned int sh:2;       /* Shareability */
> +        unsigned int res0:1;
> +        unsigned int base:26;    /* Base Address */
> +    } reg;
> +    uint32_t bits;
> +} prbar_t;
> +
> +/* Hypervisor Protection Region Limit Address Register */
> +typedef union {
> +    struct {
> +        unsigned int en:1;     /* Region enable */
> +        unsigned int ai:3;     /* Memory Attribute Index */
> +        unsigned int res0:2;
> +        unsigned int limit:26; /* Limit Address */
> +    } reg;
> +    uint32_t bits;
> +} prlar_t;
> +
>   /* MPU Protection Region */
>   typedef struct {
> -    uint32_t prbar;
> -    uint32_t prlar;
> +    prbar_t prbar;
> +    prlar_t prlar;
>   } pr_t;
>   
>   #endif /* __ASSEMBLY__ */
> diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
> index 86fbe105af..3d37beab57 100644
> --- a/xen/arch/arm/mpu/mm.c
> +++ b/xen/arch/arm/mpu/mm.c
> @@ -167,7 +167,9 @@ pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags)
>       /* Build up value for PRBAR_EL2. */
>       prbar = (prbar_t) {
>           .reg = {
> +#ifdef CONFIG_ARM_64
>               .xn_0 = 0,
> +#endif
>               .xn = PAGE_XN_MASK(flags),
>               .ap_0 = 0,
>               .ro = PAGE_RO_MASK(flags)
> @@ -206,7 +208,9 @@ pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags)
>       /* Build up value for PRLAR_EL2. */
>       prlar = (prlar_t) {
>           .reg = {
> +#ifdef CONFIG_ARM_64
>               .ns = 0,        /* Hyp mode is in secure world */
> +#endif
>               .ai = attr_idx,
>               .en = 1,        /* Region enabled */
>           }};

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 08:25:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 08:25:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016871.1393832 (Exim 4.92)
	(envelope-from )
	id 1uR59j-0004Ym-1V; Mon, 16 Jun 2025 08:25:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016871.1393832; Mon, 16 Jun 2025 08:25: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 1uR59i-0004Yf-V6; Mon, 16 Jun 2025 08:25:26 +0000
Received: by outflank-mailman (input) for mailman id 1016871;
 Mon, 16 Jun 2025 08:25:26 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uR59i-0004YZ-Fr
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 08:25:26 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uR59i-004SjT-09;
 Mon, 16 Jun 2025 08:25:26 +0000
Received: from [2a02:8012:3a1:0:64b5:81ad:1f26:5fcb]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uR59h-0077dm-2k;
 Mon, 16 Jun 2025 08:25: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" 
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=EhwWTi6TgbQ/ygG0CtFy4MFehIWr2Ic3nEjDNEUHPyQ=; b=XaqgMEnSfGIs3PphmmlvnMySq4
	epxTmt4l3PisRj+jYkK4DOKSW0RCbni60eTQI7PwLdepJg0ujJDM6vymv/PPSz88zNb7MaVI8eXO5
	P2LHQ14j9nTUehhX3htPzLDpseuzqmv3IP/TT9vgupRUpA/wcrsK07AoyfY87/P/+CTg=;
Message-ID: 
Date: Mon, 16 Jun 2025 09:25:23 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/6] arm/mpu: Provide and populate MPU C data
 structures
Content-Language: en-GB
To: Ayan Kumar Halder ,
 xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: <20250611143544.3453532-1-ayan.kumar.halder@amd.com>
 <20250611143544.3453532-3-ayan.kumar.halder@amd.com>
From: Julien Grall 
In-Reply-To: <20250611143544.3453532-3-ayan.kumar.halder@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Ayan,

On 11/06/2025 15:35, Ayan Kumar Halder wrote:
> Modify Arm32 assembly boot code to reset any unused MPU region, initialise
> 'max_mpu_regions' with the number of supported MPU regions and set/clear the
> bitmap 'xen_mpumap_mask' used to track the enabled regions.
> 
> Introduce cache.S to hold arm32 cache related functions.
> 
> Use the macro definition for "dcache_line_size" from linux.
> 
> Change the order of registers in prepare_xen_region() as 'strd' instruction
> is used to store {prbar, prlar} in arm32. Thus, 'prbar' has to be a even
> numbered register and 'prlar' is the consecutively ordered register.
> 
> Signed-off-by: Ayan Kumar Halder 

Acked-by: Julien Grall 

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 08:46:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 08:46:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016880.1393851 (Exim 4.92)
	(envelope-from )
	id 1uR5UA-0007mE-QS; Mon, 16 Jun 2025 08:46:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016880.1393851; Mon, 16 Jun 2025 08:46:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uR5UA-0007m5-NA; Mon, 16 Jun 2025 08:46:34 +0000
Received: by outflank-mailman (input) for mailman id 1016880;
 Mon, 16 Jun 2025 08:46: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 1uR5U9-0007jR-Jy
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 08:46:33 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 61f6e740-4a8e-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 10:46:24 +0200 (CEST)
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 95DB82117F;
 Mon, 16 Jun 2025 08:46: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 69736139E2;
 Mon, 16 Jun 2025 08:46: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 3vgHGN3ZT2jUPwAAD6G6ig
 (envelope-from ); Mon, 16 Jun 2025 08:46: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: 61f6e740-4a8e-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750063582; 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=T4caMaW8bugDRSGPfSz/ynH/nu5eTDf2OXty7FDoRQY=;
	b=JAQq61Cpb3tVLl1TFx2NqWBYwNpGZUJqgo//fULC+siz5DGwF3yLMFnIWBbxTMumWVtu+S
	2SQLeV5o73fye1Ei0umtxHHfalcBANRZhDS1W0mHTXrfVAn2WgT3SXZ3HdaIV4eIPDyPJX
	o7gopzFyv5GweCwCDKlytGxQQJSpRI0=
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=gH0t1Ce5
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750063581; 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=T4caMaW8bugDRSGPfSz/ynH/nu5eTDf2OXty7FDoRQY=;
	b=gH0t1Ce5jC8inaTPV+MV2kZyg6G2BCFmwbuXNDJIcAqNHPtQaU4yVBirL4eRDiIQiqQ+6B
	cMJEVjY4gtYdgUp9og16JwT31ssHWMUFYYZMaFun0szb18/FcKQQ+r2WjZtJodyYvNecdb
	w2CgnrvPccxQIM42qalMrCkOGasG5Ug=
From: Juergen Gross 
To: minios-devel@lists.xenproject.org,
	xen-devel@lists.xenproject.org
Cc: samuel.thibault@ens-lyon.org,
	Juergen Gross 
Subject: [MINI-OS PATCH v2 00/12] kexec: add kexec support to Mini-OS
Date: Mon, 16 Jun 2025 10:46:07 +0200
Message-ID: <20250616084619.11112-1-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
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)[suse.com:dkim,suse.com:mid,imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns];
	RCVD_TLS_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	DKIM_TRACE(0.00)[suse.com:+]
X-Spam-Level: 
X-Spam-Flag: NO
X-Rspamd-Queue-Id: 95DB82117F
X-Rspamd-Action: no action
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Score: -3.01

Add basic kexec support to Mini-OS for running in x86 PVH mode.

With this series applied it is possible to activate another kernel
from within Mini-OS.

Right now no Xen related teardown is done (so no reset of grant table,
event channels, PV devices). These should be added via kexec callbacks
which are added as a framework.

This is a major building block for support of Xenstore-stubdom live
update (in fact I've tested the kexec path to work using the PVH
variant of Xenstore-stubdom).

Changes in V2:
- addressed comments

Juergen Gross (12):
  add kexec framework
  Mini-OS: add final kexec stage
  mini-os: add elf.h
  mini-os: analyze new kernel for kexec
  mini-os: kexec: finalize parameter location and size
  mini-os: reserve memory below boundary
  mini-os: kexec: build parameters for new kernel
  mini-os: kexec: move used pages away for new kernel
  Mini-OS: mm: change set_readonly() to change_readonly()
  Mini-OS: kexec: switch read-only area to be writable again
  mini-os: kexec: add kexec callback functionality
  mini-os: kexec: do the final kexec step

 Config.mk                  |   1 +
 Makefile                   |   1 +
 arch/x86/kexec.c           | 272 +++++++++++++++++++++++++++++++++
 arch/x86/minios-x86.lds.S  |  17 +++
 arch/x86/mm.c              | 238 ++++++++++++++++++++++-------
 arch/x86/testbuild/all-no  |   1 +
 arch/x86/testbuild/all-yes |   2 +
 arch/x86/testbuild/kexec   |   4 +
 arch/x86/x86_hvm.S         |  46 ++++++
 include/elf.h              | 300 +++++++++++++++++++++++++++++++++++++
 include/kexec.h            |  63 ++++++++
 include/mm.h               |   8 +
 include/x86/os.h           |   5 +
 kexec.c                    | 252 +++++++++++++++++++++++++++++++
 mm.c                       |  89 ++++++++++-
 15 files changed, 1248 insertions(+), 51 deletions(-)
 create mode 100644 arch/x86/kexec.c
 create mode 100644 arch/x86/testbuild/kexec
 create mode 100644 include/elf.h
 create mode 100644 include/kexec.h
 create mode 100644 kexec.c

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 08:46:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 08:46:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016883.1393865 (Exim 4.92)
	(envelope-from )
	id 1uR5UG-00084S-3v; Mon, 16 Jun 2025 08:46:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016883.1393865; Mon, 16 Jun 2025 08:46:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uR5UG-00084L-0f; Mon, 16 Jun 2025 08:46:40 +0000
Received: by outflank-mailman (input) for mailman id 1016883;
 Mon, 16 Jun 2025 08:46: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 1uR5UD-0007hV-Vy
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 08:46:37 +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 695bf66e-4a8e-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 10:46:36 +0200 (CEST)
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 2F11E21181;
 Mon, 16 Jun 2025 08:46: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 F3F4A139E2;
 Mon, 16 Jun 2025 08:46: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 b8obOuLZT2jgPwAAD6G6ig
 (envelope-from ); Mon, 16 Jun 2025 08:46: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: 695bf66e-4a8e-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750063587; 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=eIbkCenoZvqJqr3MP5CvMO1uqc+kjXWDfidavHJfSOg=;
	b=E4B/oENMbf4MVYNW+Xi+9rgx/R78CrdQ/RHbovg0TUQ9U/kZqBKiOQftJ/bJnKg/BGnGdG
	ZJn/UqW3DfyzvC4yEJLjrBTJKcJRjBUbp9qc0F6nJGRRhli9N20MoDbbEEU75ow3HJ34px
	BTKmSsmkCr++8XAiw79XqPCM3ydFqjk=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750063587; 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=eIbkCenoZvqJqr3MP5CvMO1uqc+kjXWDfidavHJfSOg=;
	b=E4B/oENMbf4MVYNW+Xi+9rgx/R78CrdQ/RHbovg0TUQ9U/kZqBKiOQftJ/bJnKg/BGnGdG
	ZJn/UqW3DfyzvC4yEJLjrBTJKcJRjBUbp9qc0F6nJGRRhli9N20MoDbbEEU75ow3HJ34px
	BTKmSsmkCr++8XAiw79XqPCM3ydFqjk=
From: Juergen Gross 
To: minios-devel@lists.xenproject.org,
	xen-devel@lists.xenproject.org
Cc: samuel.thibault@ens-lyon.org,
	Juergen Gross ,
	Jason Andryuk 
Subject: [MINI-OS PATCH v2 01/12] add kexec framework
Date: Mon, 16 Jun 2025 10:46:08 +0200
Message-ID: <20250616084619.11112-2-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250616084619.11112-1-jgross@suse.com>
References: <20250616084619.11112-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-2.80 / 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)[-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)[imap1.dmz-prg2.suse.org:helo,suse.com:email,suse.com:mid,amd.com:email];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Level: 
X-Spam-Flag: NO
X-Spam-Score: -2.80

Add a new config option CONFIG_KEXEC for support of kexec-ing into a
new mini-os kernel. Add a related kexec.c source and a kexec.h header.

For now allow CONFIG_KEXEC to be set only for PVH variant of mini-os.

Signed-off-by: Juergen Gross 
Reviewed-by: Jason Andryuk 
---
V2:
- reword some comments (Jason Andryuk)
---
 Config.mk                  |  1 +
 Makefile                   |  1 +
 arch/x86/testbuild/all-no  |  1 +
 arch/x86/testbuild/all-yes |  2 ++
 arch/x86/testbuild/kexec   |  4 +++
 include/kexec.h            |  7 +++++
 kexec.c                    | 60 ++++++++++++++++++++++++++++++++++++++
 7 files changed, 76 insertions(+)
 create mode 100644 arch/x86/testbuild/kexec
 create mode 100644 include/kexec.h
 create mode 100644 kexec.c

diff --git a/Config.mk b/Config.mk
index e493533a..e2afb1b4 100644
--- a/Config.mk
+++ b/Config.mk
@@ -204,6 +204,7 @@ CONFIG-n += CONFIG_LIBXENGUEST
 CONFIG-n += CONFIG_LIBXENTOOLCORE
 CONFIG-n += CONFIG_LIBXENTOOLLOG
 CONFIG-n += CONFIG_LIBXENMANAGE
+CONFIG-n += CONFIG_KEXEC
 # Setting CONFIG_USE_XEN_CONSOLE copies all print output to the Xen emergency
 # console apart of standard dom0 handled console.
 CONFIG-n += CONFIG_USE_XEN_CONSOLE
diff --git a/Makefile b/Makefile
index d094858a..a64913ad 100644
--- a/Makefile
+++ b/Makefile
@@ -51,6 +51,7 @@ src-y += gntmap.c
 src-y += gnttab.c
 src-y += hypervisor.c
 src-y += kernel.c
+src-$(CONFIG_KEXEC) += kexec.c
 src-y += lock.c
 src-y += main.c
 src-y += mm.c
diff --git a/arch/x86/testbuild/all-no b/arch/x86/testbuild/all-no
index 5b3e99ed..b2ee5ce8 100644
--- a/arch/x86/testbuild/all-no
+++ b/arch/x86/testbuild/all-no
@@ -18,3 +18,4 @@ CONFIG_LIBXS = n
 CONFIG_LWIP = n
 CONFIG_BALLOON = n
 CONFIG_USE_XEN_CONSOLE = n
+CONFIG_KEXEC = n
diff --git a/arch/x86/testbuild/all-yes b/arch/x86/testbuild/all-yes
index 8ae489a4..c9a990f9 100644
--- a/arch/x86/testbuild/all-yes
+++ b/arch/x86/testbuild/all-yes
@@ -19,3 +19,5 @@ CONFIG_BALLOON = y
 CONFIG_USE_XEN_CONSOLE = y
 # The following are special: they need support from outside
 CONFIG_LWIP = n
+# KEXEC not implemented for PARAVIRT
+CONFIG_KEXEC = n
diff --git a/arch/x86/testbuild/kexec b/arch/x86/testbuild/kexec
new file mode 100644
index 00000000..ea17b4d9
--- /dev/null
+++ b/arch/x86/testbuild/kexec
@@ -0,0 +1,4 @@
+CONFIG_PARAVIRT = n
+CONFIG_BALLOON = y
+CONFIG_USE_XEN_CONSOLE = y
+CONFIG_KEXEC = y
diff --git a/include/kexec.h b/include/kexec.h
new file mode 100644
index 00000000..6fd96774
--- /dev/null
+++ b/include/kexec.h
@@ -0,0 +1,7 @@
+#ifndef _KEXEC_H
+#define _KEXEC_H
+
+int kexec(void *kernel, unsigned long kernel_size,
+          const char *cmdline);
+
+#endif /* _KEXEC_H */
diff --git a/kexec.c b/kexec.c
new file mode 100644
index 00000000..7fcc5c6b
--- /dev/null
+++ b/kexec.c
@@ -0,0 +1,60 @@
+/******************************************************************************
+ * kexec.c
+ *
+ * Support of kexec (reboot locally into new mini-os kernel).
+ *
+ * Copyright (c) 2024, Juergen Gross, SUSE Linux GmbH
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#ifdef CONFIG_PARAVIRT
+#error "kexec support not implemented in PV variant"
+#endif
+
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * General approach for kexec support (PVH only) is as follows:
+ *
+ * - New kernel needs to be in memory in form of a ELF binary in a virtual
+ *   memory region.
+ * - A new start_info structure is constructed in memory with the final
+ *   memory locations included.
+ * - Page tables and memory pages of the new kernel binary conflicting with the
+ *   final memory layout are moved to non-conflicting locations.
+ * - All memory areas needed for kexec execution are being finalized.
+ * - The final kexec execution stage is copied to a memory area below 4G which
+ *   doesn't conflict with the target areas of kernel etc.
+ * - From here on a graceful failure is no longer possible.
+ * - Grants and event channels are torn down.
+ * - Execution continues in the final execution stage.
+ * - All data is copied to its final addresses.
+ * - CPU is switched to 32-bit mode with paging disabled.
+ * - The new kernel is activated.
+ */
+
+int kexec(void *kernel, unsigned long kernel_size, const char *cmdline)
+{
+    return ENOSYS;
+}
+EXPORT_SYMBOL(kexec);
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 08:46:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 08:46:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016887.1393878 (Exim 4.92)
	(envelope-from )
	id 1uR5UI-0008MC-EH; Mon, 16 Jun 2025 08:46:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016887.1393878; Mon, 16 Jun 2025 08:46: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 1uR5UI-0008M3-At; Mon, 16 Jun 2025 08:46:42 +0000
Received: by outflank-mailman (input) for mailman id 1016887;
 Mon, 16 Jun 2025 08:46: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 1uR5UH-0007jR-KB
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 08:46:41 +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 6ad61262-4a8e-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 10:46:38 +0200 (CEST)
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 5B3F01F38F;
 Mon, 16 Jun 2025 08:46: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 29430139E2;
 Mon, 16 Jun 2025 08:46: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 czqkCO7ZT2j+PwAAD6G6ig
 (envelope-from ); Mon, 16 Jun 2025 08:46: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: 6ad61262-4a8e-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750063598; 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=EYprPgKlu2rqJCyxTaoQnR7Oz+a9tTVs4vX0zP9GR4Y=;
	b=oUHhG+ibSeYEf6fZOIQnq/6IUeGc81v46tTZNBQfSvXGJzLhVWckDEYukjyNmYPomyijUa
	pS6uHk1GEsum385eSw10TpkHECdNhatrGstiPgfXusxNsn17gp3N6igrKoZ6+ZxOmzYxOG
	LZO3dypVFQovAW5dB7E24Hd3A9uXpWw=
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=oUHhG+ib
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750063598; 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=EYprPgKlu2rqJCyxTaoQnR7Oz+a9tTVs4vX0zP9GR4Y=;
	b=oUHhG+ibSeYEf6fZOIQnq/6IUeGc81v46tTZNBQfSvXGJzLhVWckDEYukjyNmYPomyijUa
	pS6uHk1GEsum385eSw10TpkHECdNhatrGstiPgfXusxNsn17gp3N6igrKoZ6+ZxOmzYxOG
	LZO3dypVFQovAW5dB7E24Hd3A9uXpWw=
From: Juergen Gross 
To: minios-devel@lists.xenproject.org,
	xen-devel@lists.xenproject.org
Cc: samuel.thibault@ens-lyon.org,
	Juergen Gross ,
	Jan Beulich 
Subject: [MINI-OS PATCH v2 03/12] mini-os: add elf.h
Date: Mon, 16 Jun 2025 10:46:10 +0200
Message-ID: <20250616084619.11112-4-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250616084619.11112-1-jgross@suse.com>
References: <20250616084619.11112-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
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)[imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns,suse.com:dkim,suse.com:mid,suse.com:email];
	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-Spam-Level: 
X-Spam-Flag: NO
X-Rspamd-Queue-Id: 5B3F01F38F
X-Rspamd-Action: no action
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Score: -3.01

Add some definitions for accessing an ELF file. Only the file header
and the program header are needed.

The main source for those are elfstructs.h and libelf.h from the Xen
tree. The license boiler plate of those files is being kept in the
resulting header file.

Signed-off-by: Juergen Gross 
Reviewed-by: Jan Beulich 
---
V2:
- remove some unneeded defines (Jan Beulich)
- remove not needed cast (Jan Beulich)
---
 include/elf.h | 300 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 300 insertions(+)
 create mode 100644 include/elf.h

diff --git a/include/elf.h b/include/elf.h
new file mode 100644
index 00000000..fb3cae08
--- /dev/null
+++ b/include/elf.h
@@ -0,0 +1,300 @@
+#ifndef __ELF_H__
+#define __ELF_H__
+/*
+ * Copyright (c) 1995, 1996 Erik Theisen.  All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. The name of the author may not be used to endorse or promote products
+ *    derived from this software without specific prior written permission
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+#include 
+
+typedef uint32_t    Elf32_Addr;  /* Unsigned program address */
+typedef uint32_t    Elf32_Off;   /* Unsigned file offset */
+typedef uint16_t    Elf32_Half;  /* Unsigned medium integer */
+typedef uint32_t    Elf32_Word;  /* Unsigned large integer */
+
+typedef uint64_t    Elf64_Addr;
+typedef uint64_t    Elf64_Off;
+typedef uint16_t    Elf64_Half;
+typedef uint32_t    Elf64_Word;
+typedef uint64_t    Elf64_Xword;
+
+/* Unique build id string format when using --build-id. */
+#define NT_GNU_BUILD_ID 3
+
+/*
+ * e_ident[] identification indexes
+ * See http://www.caldera.com/developers/gabi/2000-07-17/ch4.eheader.html
+ */
+#define EI_MAG0        0         /* file ID */
+#define EI_MAG1        1         /* file ID */
+#define EI_MAG2        2         /* file ID */
+#define EI_MAG3        3         /* file ID */
+#define EI_CLASS       4         /* file class */
+#define EI_DATA        5         /* data encoding */
+#define EI_VERSION     6         /* ELF header version */
+#define EI_OSABI       7         /* OS/ABI ID */
+#define EI_ABIVERSION  8         /* ABI version */
+#define EI_PAD         9         /* start of pad bytes */
+#define EI_NIDENT     16         /* Size of e_ident[] */
+
+/* e_ident[] magic number */
+#define ELFMAG0        0x7f      /* e_ident[EI_MAG0] */
+#define ELFMAG1        'E'       /* e_ident[EI_MAG1] */
+#define ELFMAG2        'L'       /* e_ident[EI_MAG2] */
+#define ELFMAG3        'F'       /* e_ident[EI_MAG3] */
+#define ELFMAG         "\177ELF" /* magic */
+#define SELFMAG        4         /* size of magic */
+
+/* e_ident[] file class */
+#define ELFCLASSNONE   0         /* invalid */
+#define ELFCLASS32     1         /* 32-bit objs */
+#define ELFCLASS64     2         /* 64-bit objs */
+#define ELFCLASSNUM    3         /* number of classes */
+
+/* e_ident[] data encoding */
+#define ELFDATANONE    0         /* invalid */
+#define ELFDATA2LSB    1         /* Little-Endian */
+#define ELFDATA2MSB    2         /* Big-Endian */
+#define ELFDATANUM     3         /* number of data encode defines */
+
+/* e_ident */
+#define IS_ELF(ehdr) ((ehdr).e_ident[EI_MAG0] == ELFMAG0 && \
+                      (ehdr).e_ident[EI_MAG1] == ELFMAG1 && \
+                      (ehdr).e_ident[EI_MAG2] == ELFMAG2 && \
+                      (ehdr).e_ident[EI_MAG3] == ELFMAG3)
+
+/* e_flags */
+#define EF_ARM_EABI_MASK    0xff000000
+#define EF_ARM_EABI_UNKNOWN 0x00000000
+#define EF_ARM_EABI_VER1    0x01000000
+#define EF_ARM_EABI_VER2    0x02000000
+#define EF_ARM_EABI_VER3    0x03000000
+#define EF_ARM_EABI_VER4    0x04000000
+#define EF_ARM_EABI_VER5    0x05000000
+
+/* ELF Header */
+typedef struct {
+    unsigned char e_ident[EI_NIDENT]; /* ELF Identification */
+    Elf32_Half    e_type;        /* object file type */
+    Elf32_Half    e_machine;     /* machine */
+    Elf32_Word    e_version;     /* object file version */
+    Elf32_Addr    e_entry;       /* virtual entry point */
+    Elf32_Off     e_phoff;       /* program header table offset */
+    Elf32_Off     e_shoff;       /* section header table offset */
+    Elf32_Word    e_flags;       /* processor-specific flags */
+    Elf32_Half    e_ehsize;      /* ELF header size */
+    Elf32_Half    e_phentsize;   /* program header entry size */
+    Elf32_Half    e_phnum;       /* number of program header entries */
+    Elf32_Half    e_shentsize;   /* section header entry size */
+    Elf32_Half    e_shnum;       /* number of section header entries */
+    Elf32_Half    e_shstrndx;    /* section header table's "section
+                                    header string table" entry offset */
+} Elf32_Ehdr;
+
+typedef struct {
+    unsigned char e_ident[EI_NIDENT]; /* Id bytes */
+    Elf64_Half    e_type;        /* file type */
+    Elf64_Half    e_machine;     /* machine type */
+    Elf64_Word    e_version;     /* version number */
+    Elf64_Addr    e_entry;       /* entry point */
+    Elf64_Off     e_phoff;       /* Program hdr offset */
+    Elf64_Off     e_shoff;       /* Section hdr offset */
+    Elf64_Word    e_flags;       /* Processor flags */
+    Elf64_Half    e_ehsize;      /* sizeof ehdr */
+    Elf64_Half    e_phentsize;   /* Program header entry size */
+    Elf64_Half    e_phnum;       /* Number of program headers */
+    Elf64_Half    e_shentsize;   /* Section header entry size */
+    Elf64_Half    e_shnum;       /* Number of section headers */
+    Elf64_Half    e_shstrndx;    /* String table index */
+} Elf64_Ehdr;
+
+/* e_type */
+#define ET_NONE      0           /* No file type */
+#define ET_REL       1           /* relocatable file */
+#define ET_EXEC      2           /* executable file */
+#define ET_DYN       3           /* shared object file */
+#define ET_CORE      4           /* core file */
+#define ET_NUM       5           /* number of types */
+#define ET_LOPROC    0xff00      /* reserved range for processor */
+#define ET_HIPROC    0xffff      /*   specific e_type */
+
+/* e_machine */
+#define EM_NONE         0        /* No Machine */
+#define EM_386          3        /* Intel 80386 */
+#define EM_PPC64       21        /* PowerPC 64-bit */
+#define EM_ARM         40        /* Advanced RISC Machines ARM */
+#define EM_X86_64      62        /* AMD x86-64 architecture */
+#define EM_AARCH64    183        /* ARM 64-bit */
+
+/* Version */
+#define EV_NONE      0           /* Invalid */
+#define EV_CURRENT   1           /* Current */
+#define EV_NUM       2           /* number of versions */
+
+/* Program Header */
+typedef struct {
+    Elf32_Word    p_type;        /* segment type */
+    Elf32_Off     p_offset;      /* segment offset */
+    Elf32_Addr    p_vaddr;       /* virtual address of segment */
+    Elf32_Addr    p_paddr;       /* physical address - ignored? */
+    Elf32_Word    p_filesz;      /* number of bytes in file for seg. */
+    Elf32_Word    p_memsz;       /* number of bytes in mem. for seg. */
+    Elf32_Word    p_flags;       /* flags */
+    Elf32_Word    p_align;       /* memory alignment */
+} Elf32_Phdr;
+
+typedef struct {
+    Elf64_Word    p_type;        /* entry type */
+    Elf64_Word    p_flags;       /* flags */
+    Elf64_Off     p_offset;      /* offset */
+    Elf64_Addr    p_vaddr;       /* virtual address */
+    Elf64_Addr    p_paddr;       /* physical address */
+    Elf64_Xword   p_filesz;      /* file size */
+    Elf64_Xword   p_memsz;       /* memory size */
+    Elf64_Xword   p_align;       /* memory & file alignment */
+} Elf64_Phdr;
+
+/* Segment types - p_type */
+#define PT_NULL      0           /* unused */
+#define PT_LOAD      1           /* loadable segment */
+#define PT_DYNAMIC   2           /* dynamic linking section */
+#define PT_INTERP    3           /* the RTLD */
+#define PT_NOTE      4           /* auxiliary information */
+#define PT_SHLIB     5           /* reserved - purpose undefined */
+#define PT_PHDR      6           /* program header */
+#define PT_NUM       7           /* Number of segment types */
+#define PT_LOPROC    0x70000000  /* reserved range for processor */
+#define PT_HIPROC    0x7fffffff  /*  specific segment types */
+
+/* Segment flags - p_flags */
+#define PF_X         0x1        /* Executable */
+#define PF_W         0x2        /* Writable */
+#define PF_R         0x4        /* Readable */
+#define PF_MASKPROC  0xf0000000 /* reserved bits for processor */
+                                /*  specific segment flags */
+
+/* Section Header */
+typedef struct {
+    Elf32_Word    sh_name;      /* name - index into section header
+                                   string table section */
+    Elf32_Word    sh_type;      /* type */
+    Elf32_Word    sh_flags;     /* flags */
+    Elf32_Addr    sh_addr;      /* address */
+    Elf32_Off     sh_offset;    /* file offset */
+    Elf32_Word    sh_size;      /* section size */
+    Elf32_Word    sh_link;      /* section header table index link */
+    Elf32_Word    sh_info;      /* extra information */
+    Elf32_Word    sh_addralign; /* address alignment */
+    Elf32_Word    sh_entsize;   /* section entry size */
+} Elf32_Shdr;
+
+typedef struct {
+    Elf64_Word    sh_name;      /* section name */
+    Elf64_Word    sh_type;      /* section type */
+    Elf64_Xword   sh_flags;     /* section flags */
+    Elf64_Addr    sh_addr;      /* virtual address */
+    Elf64_Off     sh_offset;    /* file offset */
+    Elf64_Xword   sh_size;      /* section size */
+    Elf64_Word    sh_link;      /* link to another */
+    Elf64_Word    sh_info;      /* misc info */
+    Elf64_Xword   sh_addralign; /* memory alignment */
+    Elf64_Xword   sh_entsize;   /* table entry size */
+} Elf64_Shdr;
+
+/* sh_type */
+#define SHT_NULL        0       /* inactive */
+#define SHT_PROGBITS    1       /* program defined information */
+#define SHT_SYMTAB      2       /* symbol table section */
+#define SHT_STRTAB      3       /* string table section */
+#define SHT_RELA        4       /* relocation section with addends*/
+#define SHT_HASH        5       /* symbol hash table section */
+#define SHT_DYNAMIC     6       /* dynamic section */
+#define SHT_NOTE        7       /* note section */
+#define SHT_NOBITS      8       /* no space section */
+#define SHT_REL         9       /* relation section without addends */
+#define SHT_SHLIB      10       /* reserved - purpose unknown */
+#define SHT_DYNSYM     11       /* dynamic symbol table section */
+#define SHT_NUM        12       /* number of section types */
+
+/* Note definitions */
+typedef struct {
+    Elf32_Word namesz;
+    Elf32_Word descsz;
+    Elf32_Word type;
+    char data[];
+} Elf32_Note;
+
+typedef struct {
+    Elf64_Word namesz;
+    Elf64_Word descsz;
+    Elf64_Word type;
+    char data[];
+} Elf64_Note;
+
+/* Abstraction layer for handling 32- and 64-bit ELF files. */
+
+typedef union {
+    Elf32_Ehdr e32;
+    Elf64_Ehdr e64;
+} elf_ehdr;
+
+static inline bool elf_is_32bit(elf_ehdr *ehdr)
+{
+    return ehdr->e32.e_ident[EI_CLASS] == ELFCLASS32;
+}
+
+static inline bool elf_is_64bit(elf_ehdr *ehdr)
+{
+    return ehdr->e32.e_ident[EI_CLASS] == ELFCLASS64;
+}
+
+#define ehdr_val(ehdr, elem) (elf_is_32bit(ehdr) ? (ehdr)->e32.elem : (ehdr)->e64.elem)
+
+typedef union {
+    Elf32_Phdr e32;
+    Elf64_Phdr e64;
+} elf_phdr;
+
+#define phdr_val(ehdr, phdr, elem) (elf_is_32bit(ehdr) ? (phdr)->e32.elem : (phdr)->e64.elem)
+
+typedef union {
+    Elf32_Shdr e32;
+    Elf64_Shdr e64;
+} elf_shdr;
+
+#define shdr_val(ehdr, shdr, elem) (elf_is_32bit(ehdr) ? (shdr)->e32.elem : (shdr)->e64.elem)
+
+typedef union {
+    Elf32_Note e32;
+    Elf64_Note e64;
+} elf_note;
+
+#define note_val(ehdr, note, elem) (elf_is_32bit(ehdr) ? (note)->e32.elem : (note)->e64.elem)
+
+static inline void *elf_ptr_add(void *ptr, unsigned long add)
+{
+    return ptr + add;
+}
+#endif /* __ELF_H__ */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 08:46:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 08:46:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016888.1393889 (Exim 4.92)
	(envelope-from )
	id 1uR5UJ-0000B5-PU; Mon, 16 Jun 2025 08:46:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016888.1393889; Mon, 16 Jun 2025 08:46: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 1uR5UJ-0000As-MT; Mon, 16 Jun 2025 08:46:43 +0000
Received: by outflank-mailman (input) for mailman id 1016888;
 Mon, 16 Jun 2025 08:46: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 1uR5UI-0007hV-U9
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 08:46:42 +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 6c289f1f-4a8e-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 10:46:41 +0200 (CEST)
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 C6B0A2118C;
 Mon, 16 Jun 2025 08:46: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 90F76139E2;
 Mon, 16 Jun 2025 08:46: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 EfPvIejZT2jpPwAAD6G6ig
 (envelope-from ); Mon, 16 Jun 2025 08:46: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: 6c289f1f-4a8e-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750063592; 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=2H0qWHO5jB15jbB7hAMsbxc9Fi6ipKfWjIbEbuSKCeQ=;
	b=NeAmfA7S9fIDRKkgzKVn9X+cNEBpZmm/+MEtqjZMNR0ycHN2YxdYXQXV/9y+Lfv54S0xAE
	j5zIC63cOCV0aSlTw/ITmkUpJXD7a6Cyuw55QtKa/TqWxoXs/JGgEFbKYxIR4zi42ZWZJQ
	foKRyKDHZL2eWOGt9ZtvtWu5PkQbzBE=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750063592; 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=2H0qWHO5jB15jbB7hAMsbxc9Fi6ipKfWjIbEbuSKCeQ=;
	b=NeAmfA7S9fIDRKkgzKVn9X+cNEBpZmm/+MEtqjZMNR0ycHN2YxdYXQXV/9y+Lfv54S0xAE
	j5zIC63cOCV0aSlTw/ITmkUpJXD7a6Cyuw55QtKa/TqWxoXs/JGgEFbKYxIR4zi42ZWZJQ
	foKRyKDHZL2eWOGt9ZtvtWu5PkQbzBE=
From: Juergen Gross 
To: minios-devel@lists.xenproject.org,
	xen-devel@lists.xenproject.org
Cc: samuel.thibault@ens-lyon.org,
	Juergen Gross 
Subject: [MINI-OS PATCH v2 02/12] Mini-OS: add final kexec stage
Date: Mon, 16 Jun 2025 10:46:09 +0200
Message-ID: <20250616084619.11112-3-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250616084619.11112-1-jgross@suse.com>
References: <20250616084619.11112-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-2.80 / 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)[-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_THREE(0.00)[4];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email,suse.com:mid,imap1.dmz-prg2.suse.org:helo];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Level: 
X-Spam-Flag: NO
X-Spam-Score: -2.80

Add the code and data definitions of the final kexec stage.

Put the code and related data into a dedicated section in order to be
able to copy it to another location. For this reason there must be no
absolute relocations being used in the code or data.

Being functionally related, add a function for adding a final kexec
action.

Signed-off-by: Juergen Gross 
---
V2:
- add ASSERT() to linker script (Jason Andryuk)
- fix asm() input/output parameter bug (Jason Andryuk)
---
 arch/x86/kexec.c          | 107 ++++++++++++++++++++++++++++++++++++++
 arch/x86/minios-x86.lds.S |   9 ++++
 arch/x86/x86_hvm.S        |  46 ++++++++++++++++
 include/kexec.h           |  27 ++++++++++
 include/x86/os.h          |   5 ++
 kexec.c                   |  22 ++++++++
 6 files changed, 216 insertions(+)
 create mode 100644 arch/x86/kexec.c

diff --git a/arch/x86/kexec.c b/arch/x86/kexec.c
new file mode 100644
index 00000000..a8a2fa97
--- /dev/null
+++ b/arch/x86/kexec.c
@@ -0,0 +1,107 @@
+/******************************************************************************
+ * kexec.c
+ *
+ * Support of kexec (reboot locally into new mini-os kernel).
+ *
+ * Copyright (c) 2024, Juergen Gross, SUSE Linux GmbH
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#ifdef CONFIG_KEXEC
+
+#include 
+#include 
+#include 
+
+/*
+ * Final stage of kexec. Copies all data to the final destinations, zeroes
+ * .bss and activates new kernel.
+ * Must be called with interrupts off. Stack, code and data must be
+ * accessible via identity mapped virtual addresses (virt == phys). Copying
+ * and zeroing is done using virtual addresses.
+ * No relocations inside the function are allowed, as it is copied to an
+ * allocated page before being executed.
+ */
+static void __attribute__((__section__(".text.kexec")))
+    kexec_final(struct kexec_action *actions, unsigned long real)
+{
+    char *src, *dest;
+    unsigned int a, cnt;
+
+    for ( a = 0; ; a++ )
+    {
+        switch ( actions[a].action )
+        {
+        case KEXEC_COPY:
+            dest = actions[a].dest;
+            src = actions[a].src;
+            for ( cnt = 0; cnt < actions[a].len; cnt++ )
+                *dest++ = *src++;
+            break;
+
+        case KEXEC_ZERO:
+            dest = actions[a].dest;
+            for ( cnt = 0; cnt < actions[a].len; cnt++ )
+                *dest++ = 0;
+            break;
+
+        case KEXEC_CALL:
+            asm("movl %0, %%ebx\n\t"
+                "movl %1, %%edi\n\t"
+                "jmp *%2"
+                : :"m" (actions[a].src), "m" (actions[a].dest), "m" (real));
+            break;
+        }
+    }
+}
+
+#define KEXEC_STACK_LONGS  8
+static unsigned long __attribute__((__section__(".data.kexec")))
+    kexec_stack[KEXEC_STACK_LONGS];
+
+static unsigned long get_kexec_addr(void *kexec_page, void *addr)
+{
+    unsigned long off = (unsigned long)addr - (unsigned long)_kexec_start;
+
+    return (unsigned long)kexec_page + off;
+}
+
+void do_kexec(void *kexec_page)
+{
+    unsigned long actions;
+    unsigned long stack;
+    unsigned long final;
+    unsigned long phys;
+
+    actions = get_kexec_addr(kexec_page, kexec_actions);
+    stack = get_kexec_addr(kexec_page, kexec_stack + KEXEC_STACK_LONGS);
+    final = get_kexec_addr(kexec_page, kexec_final);
+    phys = get_kexec_addr(kexec_page, kexec_phys);
+
+    memcpy(kexec_page, _kexec_start, KEXEC_SECSIZE);
+    asm("cli\n\t"
+        "mov %0, %%"ASM_SP"\n\t"
+        "mov %1, %%"ASM_ARG1"\n\t"
+        "mov %2, %%"ASM_ARG2"\n\t"
+        "jmp *%3"
+        : :"m" (stack), "m" (actions), "m" (phys), "m" (final));
+}
+
+#endif /* CONFIG_KEXEC */
diff --git a/arch/x86/minios-x86.lds.S b/arch/x86/minios-x86.lds.S
index 8aae2fd6..8a1db7d4 100644
--- a/arch/x86/minios-x86.lds.S
+++ b/arch/x86/minios-x86.lds.S
@@ -87,6 +87,15 @@ SECTIONS
 
         _edata = .;			/* End of data section */
 
+        . = ALIGN(8);
+        _kexec_start = .;		/* Kexec relocatable code/data */
+        .kexec : {
+                *(.text.kexec)
+                *(.data.kexec)
+        }
+        _kexec_end = .;
+        ASSERT(_kexec_end - _kexec_start <= 4096, "kexec code/data > 1 page")
+
         __bss_start = .;		/* BSS */
         .bss : {
                 *(.bss)
diff --git a/arch/x86/x86_hvm.S b/arch/x86/x86_hvm.S
index 42a5f02e..e2f82e96 100644
--- a/arch/x86/x86_hvm.S
+++ b/arch/x86/x86_hvm.S
@@ -85,4 +85,50 @@ page_table_l2:
 #endif
         .align __PAGE_SIZE, 0
 
+#ifdef CONFIG_KEXEC
+.section .text.kexec, "ax", @progbits
+
+/*
+ * Switch off paging and call new OS for kexec.
+ * %ebx holds the physical address of the start_info structure
+ * %edi holds the physical address of the entry point to call
+ */
+.globl kexec_phys
+kexec_phys:
+        /* Set DS, ES, SS to 0...ffffffff. */
+        mov $(GDTE_DS32_DPL0 * 8), %eax
+        mov %eax, %ds
+        mov %eax, %es
+        mov %eax, %ss
+
+#ifdef __x86_64__
+        /* Switch to 32-bit mode. */
+        pushq $(GDTE_CS32_DPL0 * 8)
+        lea cs32_switch(%rip),%edx
+        push %rdx
+        lretq
+
+        .code32
+cs32_switch:
+#endif
+        /* Set %cr0 and %cr4 (disables paging). */
+        mov $X86_CR0_PE, %eax
+        mov %eax, %cr0
+        mov $0, %eax
+        mov %eax, %cr4
+#ifdef __x86_64__
+        /* Disable 64-bit mode. */
+        mov $MSR_EFER, %ecx
+        rdmsr
+        btr $_EFER_LME, %eax
+        wrmsr
+#endif
+
+        jmp *%edi
+
+#ifdef __x86_64__
+        .code64
+#endif
+#endif /* CONFIG_KEXEC */
+
 .text
diff --git a/include/kexec.h b/include/kexec.h
index 6fd96774..722be456 100644
--- a/include/kexec.h
+++ b/include/kexec.h
@@ -1,7 +1,34 @@
 #ifndef _KEXEC_H
 #define _KEXEC_H
 
+/* One element of kexec actions (last element must have action KEXEC_CALL): */
+struct kexec_action {
+    enum {
+        KEXEC_COPY,   /* Copy len bytes from src to dest. */
+        KEXEC_ZERO,   /* Zero len bytes at dest. */
+        KEXEC_CALL    /* Call dest with paging turned off, param is src. */
+    } action;
+    unsigned int len;
+    void *dest;
+    void *src;
+};
+
+#define KEXEC_MAX_ACTIONS  16
+
+extern char _kexec_start[], _kexec_end[];
+extern struct kexec_action kexec_actions[KEXEC_MAX_ACTIONS];
+
+int kexec_add_action(int action, void *dest, void *src, unsigned int len);
+
+#define KEXEC_SECSIZE ((unsigned long)_kexec_end - (unsigned long)_kexec_start)
+
 int kexec(void *kernel, unsigned long kernel_size,
           const char *cmdline);
 
+/* Initiate final kexec stage. */
+void do_kexec(void *kexec_page);
+
+/* Assembler code for switching off paging and passing execution to new OS. */
+void kexec_phys(void);
+
 #endif /* _KEXEC_H */
diff --git a/include/x86/os.h b/include/x86/os.h
index 0095be13..8a057d81 100644
--- a/include/x86/os.h
+++ b/include/x86/os.h
@@ -27,6 +27,7 @@
 #define MSR_EFER          0xc0000080
 #define _EFER_LME         8             /* Long mode enable */
 
+#define X86_CR0_PE        0x00000001    /* Protected mode enable */
 #define X86_CR0_WP        0x00010000    /* Write protect */
 #define X86_CR0_PG        0x80000000    /* Paging */
 #define X86_CR4_PAE       0x00000020    /* enable physical address extensions */
@@ -64,9 +65,13 @@
 #if defined(__i386__)
 #define __SZ    "l"
 #define __REG   "e"
+#define ASM_ARG1 "eax"
+#define ASM_ARG2 "edx"
 #else
 #define __SZ    "q"
 #define __REG   "r"
+#define ASM_ARG1 "rdi"
+#define ASM_ARG2 "rsi"
 #endif
 
 #define ASM_SP  __REG"sp"
diff --git a/kexec.c b/kexec.c
index 7fcc5c6b..b69e145b 100644
--- a/kexec.c
+++ b/kexec.c
@@ -58,3 +58,25 @@ int kexec(void *kernel, unsigned long kernel_size, const char *cmdline)
     return ENOSYS;
 }
 EXPORT_SYMBOL(kexec);
+
+struct kexec_action __attribute__((__section__(".data.kexec")))
+    kexec_actions[KEXEC_MAX_ACTIONS];
+static unsigned int act_idx;
+
+int kexec_add_action(int action, void *dest, void *src, unsigned int len)
+{
+    struct kexec_action *act;
+
+    if ( act_idx == KEXEC_MAX_ACTIONS )
+        return -ENOSPC;
+
+    act = kexec_actions + act_idx;
+    act_idx++;
+
+    act->action = action;
+    act->len = len;
+    act->dest = dest;
+    act->src = src;
+
+    return 0;
+}
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 08:46:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 08:46:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016892.1393899 (Exim 4.92)
	(envelope-from )
	id 1uR5UM-0000Tg-1t; Mon, 16 Jun 2025 08:46:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016892.1393899; Mon, 16 Jun 2025 08:46: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 1uR5UL-0000TX-UO; Mon, 16 Jun 2025 08:46:45 +0000
Received: by outflank-mailman (input) for mailman id 1016892;
 Mon, 16 Jun 2025 08:46: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 1uR5UK-0007jR-Rb
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 08:46:44 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6e1ca925-4a8e-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 10:46:44 +0200 (CEST)
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 F08491F387;
 Mon, 16 Jun 2025 08:46: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 BED63139E2;
 Mon, 16 Jun 2025 08:46: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 oTULLfPZT2gFQAAAD6G6ig
 (envelope-from ); Mon, 16 Jun 2025 08:46: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: 6e1ca925-4a8e-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750063604; 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=ErW9+9DRpMiP5o75sVek1KZHEMoGAiJ0VRopG8PxS3M=;
	b=SWoQN4zlxWLi8ZKq2jWhfuB4yjsy5mSYgvK3YyZ+h+/nexswTQbjMgSPbXt4/KWLwkDezK
	jvqstgion871pR+Jm9cej3VnHV9VRBGVNo0DSteKAOKFcYurLAVWL8B15KLL5oAq/0IIYD
	LM+qRQ2xjl51xB4xBIoReu/zkvmuNYw=
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750063603; 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=ErW9+9DRpMiP5o75sVek1KZHEMoGAiJ0VRopG8PxS3M=;
	b=L/kjDblt1jRnE052nkLszKRxliRvJ4gQPpfqz0FQLZXZfJhtE40x+6oOtiAm+V6YsybFOp
	A+ls5LBf9wwwhM/33nz6IIfMONohLY5zY4/O6UPK1/+ti9+n+DQWaSPTcXb/Pz+kaYYLUZ
	fbCK8t/iepaP61IcUCpvwV3LV+aTuv8=
From: Juergen Gross 
To: minios-devel@lists.xenproject.org,
	xen-devel@lists.xenproject.org
Cc: samuel.thibault@ens-lyon.org,
	Juergen Gross ,
	Jason Andryuk 
Subject: [MINI-OS PATCH v2 04/12] mini-os: analyze new kernel for kexec
Date: Mon, 16 Jun 2025 10:46:11 +0200
Message-ID: <20250616084619.11112-5-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250616084619.11112-1-jgross@suse.com>
References: <20250616084619.11112-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-2.80 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-0.999];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCVD_COUNT_TWO(0.00)[2];
	TO_DN_SOME(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	RCPT_COUNT_FIVE(0.00)[5];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email,suse.com:mid,imap1.dmz-prg2.suse.org:helo,amd.com:email]
X-Spam-Level: 
X-Spam-Flag: NO
X-Spam-Score: -2.80

Analyze the properties of the new kernel to be loaded by kexec. The
data needed is:

- upper boundary in final location
- copy and memory clear operations
- entry point and entry parameter

Signed-off-by: Juergen Gross 
Reviewed-by: Jason Andryuk 
---
V2:
- rename check_notes_entry() (Jason Andryuk)
- rename kernel_entry to kernel_phys_entry (Jason Andryuk)
---
 arch/x86/kexec.c |  92 +++++++++++++++++++++++++++++++++++++
 include/kexec.h  |  11 +++++
 kexec.c          | 117 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 220 insertions(+)

diff --git a/arch/x86/kexec.c b/arch/x86/kexec.c
index a8a2fa97..736ca1bf 100644
--- a/arch/x86/kexec.c
+++ b/arch/x86/kexec.c
@@ -28,8 +28,15 @@
 
 #include 
 #include 
+#include 
+#include 
 #include 
 
+#include 
+#include 
+
+static unsigned long kernel_phys_entry = ~0UL;
+
 /*
  * Final stage of kexec. Copies all data to the final destinations, zeroes
  * .bss and activates new kernel.
@@ -104,4 +111,89 @@ void do_kexec(void *kexec_page)
         : :"m" (stack), "m" (actions), "m" (phys), "m" (final));
 }
 
+bool kexec_chk_arch(elf_ehdr *ehdr)
+{
+    return ehdr->e32.e_machine == EM_386 || ehdr->e32.e_machine == EM_X86_64;
+}
+
+static unsigned int note_data_sz(unsigned int sz)
+{
+    return (sz + 3) & ~3;
+}
+
+static void read_note_entry(elf_ehdr *ehdr, void *start, unsigned int len)
+{
+    elf_note *note = start;
+    unsigned int off, note_len, namesz, descsz;
+    char *val;
+
+    for ( off = 0; off < len; off += note_len )
+    {
+        namesz = note_data_sz(note_val(ehdr, note, namesz));
+        descsz = note_data_sz(note_val(ehdr, note, descsz));
+        val = note_val(ehdr, note, data);
+        note_len = val - (char *)note + namesz + descsz;
+
+        if ( !strncmp(val, "Xen", namesz) &&
+             note_val(ehdr, note, type) == XEN_ELFNOTE_PHYS32_ENTRY )
+        {
+            val += namesz;
+            switch ( note_val(ehdr, note, descsz) )
+            {
+            case 1:
+                kernel_phys_entry = *(uint8_t *)val;
+                return;
+            case 2:
+                kernel_phys_entry = *(uint16_t *)val;
+                return;
+            case 4:
+                kernel_phys_entry = *(uint32_t *)val;
+                return;
+            case 8:
+                kernel_phys_entry = *(uint64_t *)val;
+                return;
+            default:
+                break;
+            }
+        }
+
+        note = elf_ptr_add(note, note_len);
+    }
+}
+
+int kexec_arch_analyze_phdr(elf_ehdr *ehdr, elf_phdr *phdr)
+{
+    void *notes_start;
+    unsigned int notes_len;
+
+    if ( phdr_val(ehdr, phdr, p_type) != PT_NOTE || kernel_phys_entry != ~0UL )
+        return 0;
+
+    notes_start = elf_ptr_add(ehdr, phdr_val(ehdr, phdr, p_offset));
+    notes_len = phdr_val(ehdr, phdr, p_filesz);
+    read_note_entry(ehdr, notes_start, notes_len);
+
+    return 0;
+}
+
+int kexec_arch_analyze_shdr(elf_ehdr *ehdr, elf_shdr *shdr)
+{
+    void *notes_start;
+    unsigned int notes_len;
+
+    if ( shdr_val(ehdr, shdr, sh_type) != SHT_NOTE ||
+         kernel_phys_entry != ~0UL )
+        return 0;
+
+    notes_start = elf_ptr_add(ehdr, shdr_val(ehdr, shdr, sh_offset));
+    notes_len = shdr_val(ehdr, shdr, sh_size);
+    read_note_entry(ehdr, notes_start, notes_len);
+
+    return 0;
+}
+
+bool kexec_arch_need_analyze_shdrs(void)
+{
+    return kernel_phys_entry == ~0UL;
+}
 #endif /* CONFIG_KEXEC */
diff --git a/include/kexec.h b/include/kexec.h
index 722be456..f54cbb90 100644
--- a/include/kexec.h
+++ b/include/kexec.h
@@ -1,5 +1,6 @@
 #ifndef _KEXEC_H
 #define _KEXEC_H
+#include 
 
 /* One element of kexec actions (last element must have action KEXEC_CALL): */
 struct kexec_action {
@@ -18,6 +19,8 @@ struct kexec_action {
 extern char _kexec_start[], _kexec_end[];
 extern struct kexec_action kexec_actions[KEXEC_MAX_ACTIONS];
 
+extern unsigned long kexec_last_addr;
+
 int kexec_add_action(int action, void *dest, void *src, unsigned int len);
 
 #define KEXEC_SECSIZE ((unsigned long)_kexec_end - (unsigned long)_kexec_start)
@@ -31,4 +34,12 @@ void do_kexec(void *kexec_page);
 /* Assembler code for switching off paging and passing execution to new OS. */
 void kexec_phys(void);
 
+/* Check kernel to match current architecture. */
+bool kexec_chk_arch(elf_ehdr *ehdr);
+
+/* Architecture specific ELF handling functions. */
+int kexec_arch_analyze_phdr(elf_ehdr *ehdr, elf_phdr *phdr);
+int kexec_arch_analyze_shdr(elf_ehdr *ehdr, elf_shdr *shdr);
+bool kexec_arch_need_analyze_shdrs(void);
+
 #endif /* _KEXEC_H */
diff --git a/kexec.c b/kexec.c
index b69e145b..7c0e6377 100644
--- a/kexec.c
+++ b/kexec.c
@@ -31,6 +31,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 
 /*
@@ -53,8 +56,122 @@
  * - The new kernel is activated.
  */
 
+unsigned long kexec_last_addr;
+
+static int analyze_phdrs(elf_ehdr *ehdr)
+{
+    elf_phdr *phdr;
+    unsigned int n_hdr, i;
+    unsigned long paddr, offset, filesz, memsz;
+    int ret;
+
+    phdr = elf_ptr_add(ehdr, ehdr_val(ehdr, e_phoff));
+    n_hdr = ehdr_val(ehdr, e_phnum);
+    for ( i = 0; i < n_hdr; i++ )
+    {
+        ret = kexec_arch_analyze_phdr(ehdr, phdr);
+        if ( ret )
+            return ret;
+
+        if ( phdr_val(ehdr, phdr, p_type) == PT_LOAD &&
+             (phdr_val(ehdr, phdr, p_flags) & (PF_X | PF_W | PF_R)) )
+        {
+            paddr = phdr_val(ehdr, phdr, p_paddr);
+            offset = phdr_val(ehdr, phdr, p_offset);
+            filesz = phdr_val(ehdr, phdr, p_filesz);
+            memsz = phdr_val(ehdr, phdr, p_memsz);
+            if ( filesz > 0 )
+            {
+                ret = kexec_add_action(KEXEC_COPY, to_virt(paddr),
+                                       (char *)ehdr + offset, filesz);
+                if ( ret )
+                    return ret;
+            }
+            if ( memsz > filesz )
+            {
+                ret = kexec_add_action(KEXEC_ZERO, to_virt(paddr + filesz),
+                                       NULL, memsz - filesz);
+                if ( ret )
+                    return ret;
+            }
+            if ( paddr + memsz > kexec_last_addr )
+                kexec_last_addr = paddr + memsz;
+        }
+
+        phdr = elf_ptr_add(phdr, ehdr_val(ehdr, e_phentsize));
+    }
+
+    return 0;
+}
+
+static int analyze_shdrs(elf_ehdr *ehdr)
+{
+    elf_shdr *shdr;
+    unsigned int n_hdr, i;
+    int ret;
+
+    if ( !kexec_arch_need_analyze_shdrs() )
+        return 0;
+
+    shdr = elf_ptr_add(ehdr, ehdr_val(ehdr, e_shoff));
+    n_hdr = ehdr_val(ehdr, e_shnum);
+    for ( i = 0; i < n_hdr; i++ )
+    {
+        ret = kexec_arch_analyze_shdr(ehdr, shdr);
+        if ( ret )
+            return ret;
+
+        shdr = elf_ptr_add(shdr, ehdr_val(ehdr, e_shentsize));
+    }
+
+    return 0;
+}
+
+static int analyze_kernel(void *kernel, unsigned long size)
+{
+    elf_ehdr *ehdr = kernel;
+    int ret;
+
+    if ( !IS_ELF(ehdr->e32) )
+    {
+        printk("kexec: new kernel not an ELF file\n");
+        return ENOEXEC;
+    }
+    if ( ehdr->e32.e_ident[EI_DATA] != ELFDATA2LSB )
+    {
+        printk("kexec: ELF file of new kernel is big endian\n");
+        return ENOEXEC;
+    }
+    if ( !elf_is_32bit(ehdr) && !elf_is_64bit(ehdr) )
+    {
+        printk("kexec: ELF file of new kernel is neither 32 nor 64 bit\n");
+        return ENOEXEC;
+    }
+    if ( !kexec_chk_arch(ehdr) )
+    {
+        printk("kexec: ELF file of new kernel is not compatible with arch\n");
+        return ENOEXEC;
+    }
+
+    ret = analyze_phdrs(ehdr);
+    if ( ret )
+        return ret;
+
+    ret = analyze_shdrs(ehdr);
+    if ( ret )
+        return ret;
+
+    return 0;
+}
+
 int kexec(void *kernel, unsigned long kernel_size, const char *cmdline)
 {
+    int ret;
+
+    ret = analyze_kernel(kernel, kernel_size);
+    if ( ret )
+        return ret;
+
     return ENOSYS;
 }
 EXPORT_SYMBOL(kexec);
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 08:46:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 08:46:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016904.1393917 (Exim 4.92)
	(envelope-from )
	id 1uR5UU-00019m-Fq; Mon, 16 Jun 2025 08:46:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016904.1393917; Mon, 16 Jun 2025 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 1uR5UU-00019c-Ae; Mon, 16 Jun 2025 08:46:54 +0000
Received: by outflank-mailman (input) for mailman id 1016904;
 Mon, 16 Jun 2025 08:46: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 1uR5US-0007hV-FO
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 08:46:52 +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 717beb00-4a8e-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 10:46:50 +0200 (CEST)
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 A853821203;
 Mon, 16 Jun 2025 08:46: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 6FD76139E2;
 Mon, 16 Jun 2025 08:46: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 Q1epGfnZT2gPQAAAD6G6ig
 (envelope-from ); Mon, 16 Jun 2025 08:46: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: 717beb00-4a8e-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750063609; 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=Har4IwtPYyYJZu4D6gPZgpdZMuGaRz2PoPDisbs0FwU=;
	b=R83igbw1tj3VZ1xHwp86+zoOf0BMddI5D3JZHdZeQTL9irr1tyP2PmLv+pjUfRSF/FhnSE
	U1w7DJTaaiZJCk1CKBQYvYrzGDVxz/Ij32KRmJWHwvGtDa7lxZVHloBAatywys8KVMCzES
	hRF8oHhdtnxhXPX64tfCoFA/+9Ul5n0=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750063609; 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=Har4IwtPYyYJZu4D6gPZgpdZMuGaRz2PoPDisbs0FwU=;
	b=R83igbw1tj3VZ1xHwp86+zoOf0BMddI5D3JZHdZeQTL9irr1tyP2PmLv+pjUfRSF/FhnSE
	U1w7DJTaaiZJCk1CKBQYvYrzGDVxz/Ij32KRmJWHwvGtDa7lxZVHloBAatywys8KVMCzES
	hRF8oHhdtnxhXPX64tfCoFA/+9Ul5n0=
From: Juergen Gross 
To: minios-devel@lists.xenproject.org,
	xen-devel@lists.xenproject.org
Cc: samuel.thibault@ens-lyon.org,
	Juergen Gross ,
	Jason Andryuk 
Subject: [MINI-OS PATCH v2 05/12] mini-os: kexec: finalize parameter location and size
Date: Mon, 16 Jun 2025 10:46:12 +0200
Message-ID: <20250616084619.11112-6-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250616084619.11112-1-jgross@suse.com>
References: <20250616084619.11112-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-2.80 / 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)[-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)[amd.com:email,imap1.dmz-prg2.suse.org:helo,suse.com:email,suse.com:mid];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Level: 
X-Spam-Flag: NO
X-Spam-Score: -2.80

Finalize the location and the size of the parameters for the new
kernel. This is needed in order to avoid allocating new memory in the
area occupied by the new kernel and parameters.

Signed-off-by: Juergen Gross 
Reviewed-by: Jason Andryuk 
---
 arch/x86/kexec.c | 15 +++++++++++++++
 include/kexec.h  |  3 +++
 kexec.c          |  2 ++
 3 files changed, 20 insertions(+)

diff --git a/arch/x86/kexec.c b/arch/x86/kexec.c
index 736ca1bf..47830905 100644
--- a/arch/x86/kexec.c
+++ b/arch/x86/kexec.c
@@ -196,4 +196,19 @@ bool kexec_arch_need_analyze_shdrs(void)
 {
     return kernel_phys_entry == ~0UL;
 }
+
+static unsigned long kexec_param_loc;
+static unsigned int kexec_param_size;
+
+void kexec_set_param_loc(const char *cmdline)
+{
+    kexec_param_size = sizeof(struct hvm_start_info);
+    kexec_param_size += e820_entries * sizeof(struct hvm_memmap_table_entry);
+    kexec_param_size += strlen(cmdline) + 1;
+
+    kexec_last_addr = (kexec_last_addr + 7) & ~7UL;
+    kexec_param_loc = kexec_last_addr;
+    kexec_last_addr += kexec_param_size;
+    kexec_last_addr = round_pgup(kexec_last_addr);
+}
 #endif /* CONFIG_KEXEC */
diff --git a/include/kexec.h b/include/kexec.h
index f54cbb90..8a2b552f 100644
--- a/include/kexec.h
+++ b/include/kexec.h
@@ -42,4 +42,7 @@ int kexec_arch_analyze_phdr(elf_ehdr *ehdr, elf_phdr *phdr);
 int kexec_arch_analyze_shdr(elf_ehdr *ehdr, elf_shdr *shdr);
 bool kexec_arch_need_analyze_shdrs(void);
 
+/* Finalize parameter location and size. */
+void kexec_set_param_loc(const char *cmdline);
+
 #endif /* _KEXEC_H */
diff --git a/kexec.c b/kexec.c
index 7c0e6377..31839382 100644
--- a/kexec.c
+++ b/kexec.c
@@ -172,6 +172,8 @@ int kexec(void *kernel, unsigned long kernel_size, const char *cmdline)
     if ( ret )
         return ret;
 
+    kexec_set_param_loc(cmdline);
+
     return ENOSYS;
 }
 EXPORT_SYMBOL(kexec);
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 08:50:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 08:50:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016939.1393926 (Exim 4.92)
	(envelope-from )
	id 1uR5YA-0003qk-88; Mon, 16 Jun 2025 08:50:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016939.1393926; Mon, 16 Jun 2025 08:50: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 1uR5YA-0003qb-5O; Mon, 16 Jun 2025 08:50:42 +0000
Received: by outflank-mailman (input) for mailman id 1016939;
 Mon, 16 Jun 2025 08:50: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 1uR5Ut-0007jR-Ts
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 08:47:19 +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 8307937a-4a8e-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 10:47:19 +0200 (CEST)
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 B273A1F38F;
 Mon, 16 Jun 2025 08:47: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 80FDD139E2;
 Mon, 16 Jun 2025 08:47: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 sunAHRXaT2g6QAAAD6G6ig
 (envelope-from ); Mon, 16 Jun 2025 08:47: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: 8307937a-4a8e-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750063639; 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=9oEFTpU9aU3slJF04hBQYd4aVGaCv7knMZrTTup/bd0=;
	b=sheYdGj3pN/vC/Rmbq1lGWAmA2IZKgGLUu21+LihgsnyaOqBqkqlcef+YPpQOyq9qBTq7L
	NrPP5vKsYlPjyqVBpOYgFHhD2Up59/C+xiOJuB+8KsrQVU82c6aoS6iKL+MssAIV3z9uty
	iyautI2uJP/Yk0cXjsJbJSspA9XiWsw=
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=oY+0NaNR
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750063637; 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=9oEFTpU9aU3slJF04hBQYd4aVGaCv7knMZrTTup/bd0=;
	b=oY+0NaNR88YKEezyZT76ajQXIDV6E/w9gQmjqDAGaSEp+OI27LwPkMzRPFnCt2NOmklteT
	LNdGLs2sHtlW2IduhOupmr47jHWggPSzL1iN0NOYKkuFQXzU7euxBNVgUa35m9b63vV3cx
	Qp3e2ZqoEmOBFzN0sH79WGnM9zETq3s=
From: Juergen Gross 
To: minios-devel@lists.xenproject.org,
	xen-devel@lists.xenproject.org
Cc: samuel.thibault@ens-lyon.org,
	Juergen Gross ,
	Jason Andryuk 
Subject: [MINI-OS PATCH v2 10/12] Mini-OS: kexec: switch read-only area to be writable again
Date: Mon, 16 Jun 2025 10:46:17 +0200
Message-ID: <20250616084619.11112-11-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250616084619.11112-1-jgross@suse.com>
References: <20250616084619.11112-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Queue-Id: B273A1F38F
X-Rspamd-Action: no action
X-Spam-Flag: NO
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)[];
	RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received];
	DNSWL_BLOCKED(0.00)[2a07:de40:b281:104:10:150:64:97:from,2a07:de40:b281:106:10:150:64:167:received];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	DKIM_TRACE(0.00)[suse.com:+];
	RCPT_COUNT_FIVE(0.00)[5];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo,amd.com:email,suse.com:mid,suse.com:dkim,suse.com:email]
X-Spam-Score: -3.01
X-Spam-Level: 

In order to allow writing the new kernel, make the readonly area
covering current kernel text writable again.

Signed-off-by: Juergen Gross 
Reviewed-by: Jason Andryuk 
---
V2:
- modify printk() statement (Jason Andryuk)
---
 arch/x86/mm.c | 3 ++-
 kexec.c       | 3 +++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/x86/mm.c b/arch/x86/mm.c
index f4419d95..26ede6f4 100644
--- a/arch/x86/mm.c
+++ b/arch/x86/mm.c
@@ -529,7 +529,8 @@ void change_readonly(bool readonly)
 #endif
     }
 
-    printk("setting %p-%p readonly\n", &_text, &_erodata);
+    printk("setting %p-%p %s\n", &_text, &_erodata,
+           readonly ? "readonly" : "writable");
     walk_pt(start_address, ro.etext, change_readonly_func, &ro);
 
 #ifdef CONFIG_PARAVIRT
diff --git a/kexec.c b/kexec.c
index 3b11a69c..1ef7ce84 100644
--- a/kexec.c
+++ b/kexec.c
@@ -183,6 +183,8 @@ int kexec(void *kernel, unsigned long kernel_size, const char *cmdline)
         goto err;
     }
 
+    change_readonly(false);
+
     ret = kexec_move_used_pages(kexec_last_addr, (unsigned long)kernel,
                                 kernel_size);
     if ( ret )
@@ -192,6 +194,7 @@ int kexec(void *kernel, unsigned long kernel_size, const char *cmdline)
     ret = ENOSYS;
 
  err:
+    change_readonly(true);
     unreserve_memory_below();
     kexec_move_used_pages_undo();
     kexec_get_entry_undo();
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 08:50:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 08:50:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016944.1393943 (Exim 4.92)
	(envelope-from )
	id 1uR5YB-00048A-Oo; Mon, 16 Jun 2025 08:50:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016944.1393943; Mon, 16 Jun 2025 08:50:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uR5YB-00047I-JT; Mon, 16 Jun 2025 08:50:43 +0000
Received: by outflank-mailman (input) for mailman id 1016944;
 Mon, 16 Jun 2025 08:50: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 1uR5V4-0007hV-SQ
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 08:47:30 +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 88f20ac5-4a8e-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 10:47:29 +0200 (CEST)
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 DD17221203;
 Mon, 16 Jun 2025 08:47:28 +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 A87E4139E2;
 Mon, 16 Jun 2025 08:47:28 +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 oGyWJyDaT2hFQAAAD6G6ig
 (envelope-from ); Mon, 16 Jun 2025 08:47: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: 88f20ac5-4a8e-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750063649; 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=IMg43rEyz8CpFoVtq3k2oUri4d2hHuQbI9tlZdtJd1M=;
	b=RBycZqlgyhvjGURyBTEl+DgB6nQGhh31WKaVV+yTp1sAXttmg+yIRZ9ukSzGsZKHBoj0ij
	REk5qSbSMn7B/V/WkDfZJFZwpnGhvZxP0e6Vbm47m2+M3bB7WOMiJsEb42h7Vi8uUtIAfe
	XGe7W1XKAgxDD1/uhmOBMfx6dd+ohfU=
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=dYaRylJK
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750063648; 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=IMg43rEyz8CpFoVtq3k2oUri4d2hHuQbI9tlZdtJd1M=;
	b=dYaRylJK0V/t4bUa7GTifIuxYGsBu9t85xuZtG1CaUoZoxuvd5an6xk4mHpO7Mnz3VLPp3
	lyGpE1QHPLGkpJK7gIO0bQMrQee+GDMqR2JZL5rY7NJNs4DjFes4i3UVl51VExF0k8KaBk
	b9hndnRcm56g6Zm+Zo6APRP/RHPKP4k=
From: Juergen Gross 
To: minios-devel@lists.xenproject.org,
	xen-devel@lists.xenproject.org
Cc: samuel.thibault@ens-lyon.org,
	Juergen Gross 
Subject: [MINI-OS PATCH v2 12/12] mini-os: kexec: do the final kexec step
Date: Mon, 16 Jun 2025 10:46:19 +0200
Message-ID: <20250616084619.11112-13-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250616084619.11112-1-jgross@suse.com>
References: <20250616084619.11112-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
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)[suse.com:dkim,suse.com:mid,suse.com:email,imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns];
	RCVD_TLS_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	DKIM_TRACE(0.00)[suse.com:+]
X-Spam-Level: 
X-Spam-Flag: NO
X-Rspamd-Queue-Id: DD17221203
X-Rspamd-Action: no action
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Score: -3.01

With all kexec preparations done, activate the new kernel.

Signed-off-by: Juergen Gross 
---
 kexec.c | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/kexec.c b/kexec.c
index f42aa8ad..2607c819 100644
--- a/kexec.c
+++ b/kexec.c
@@ -168,6 +168,7 @@ int kexec(void *kernel, unsigned long kernel_size, const char *cmdline)
 {
     int ret;
     unsigned long *func;
+    void *kexec_page;
 
     ret = analyze_kernel(kernel, kernel_size);
     if ( ret )
@@ -191,6 +192,13 @@ int kexec(void *kernel, unsigned long kernel_size, const char *cmdline)
     if ( ret )
         goto err;
 
+    kexec_page = (void *)alloc_page();
+    if ( !kexec_page )
+    {
+        ret = ENOMEM;
+        goto err;
+    }
+
     for ( func = __kexec_array_start; func < __kexec_array_end; func++ )
     {
         ret = ((kexeccall_t)(*func))(false);
@@ -203,10 +211,15 @@ int kexec(void *kernel, unsigned long kernel_size, const char *cmdline)
         }
     }
 
-    /* Error exit. */
-    ret = ENOSYS;
+    /* Activate the new kernel. */
+    do_kexec(kexec_page);
+
+    /* do_kexec() shouldn't return, crash. */
+    BUG();
 
  err:
+    if ( kexec_page )
+        free_page(kexec_page);
     change_readonly(true);
     unreserve_memory_below();
     kexec_move_used_pages_undo();
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 08:50:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 08:50:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016954.1393965 (Exim 4.92)
	(envelope-from )
	id 1uR5YF-0004jt-67; Mon, 16 Jun 2025 08:50:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016954.1393965; Mon, 16 Jun 2025 08:50:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uR5YF-0004jU-0w; Mon, 16 Jun 2025 08:50:47 +0000
Received: by outflank-mailman (input) for mailman id 1016954;
 Mon, 16 Jun 2025 08:50: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 1uR5UX-0007jR-8c
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 08:46:57 +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 74d926bb-4a8e-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 10:46:55 +0200 (CEST)
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 44EB41F387;
 Mon, 16 Jun 2025 08:46: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 16AD3139E2;
 Mon, 16 Jun 2025 08:46: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 yj0oBP/ZT2gXQAAAD6G6ig
 (envelope-from ); Mon, 16 Jun 2025 08:46: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: 74d926bb-4a8e-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750063615; 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=t6vErAErnWD/FpLTzRhfE8JqNkLUXRMZRtPqHFEP1P8=;
	b=PHX2IwrcZ/YS5hTfN4yhU5/SXV3c3swS8eEhIhSMQZqnhRtqk9mZy8zfw2KirRigVGNjG+
	8wFtDb/QDlCghYPtOOd9KgwCx1CoXsPR214SgBevfEnowA9fHu+tVL2of+br5uMXGjlWTa
	H3aP2zAp1uGsrnSpfq0FFBfNApMf4Fo=
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750063615; 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=t6vErAErnWD/FpLTzRhfE8JqNkLUXRMZRtPqHFEP1P8=;
	b=PHX2IwrcZ/YS5hTfN4yhU5/SXV3c3swS8eEhIhSMQZqnhRtqk9mZy8zfw2KirRigVGNjG+
	8wFtDb/QDlCghYPtOOd9KgwCx1CoXsPR214SgBevfEnowA9fHu+tVL2of+br5uMXGjlWTa
	H3aP2zAp1uGsrnSpfq0FFBfNApMf4Fo=
From: Juergen Gross 
To: minios-devel@lists.xenproject.org,
	xen-devel@lists.xenproject.org
Cc: samuel.thibault@ens-lyon.org,
	Juergen Gross ,
	Jason Andryuk 
Subject: [MINI-OS PATCH v2 06/12] mini-os: reserve memory below boundary
Date: Mon, 16 Jun 2025 10:46:13 +0200
Message-ID: <20250616084619.11112-7-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250616084619.11112-1-jgross@suse.com>
References: <20250616084619.11112-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-2.80 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-0.999];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCVD_COUNT_TWO(0.00)[2];
	TO_DN_SOME(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	RCPT_COUNT_FIVE(0.00)[5];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email,suse.com:mid,amd.com:email,imap1.dmz-prg2.suse.org:helo]
X-Spam-Level: 
X-Spam-Flag: NO
X-Spam-Score: -2.80

In order to support kexec any memory used during copying the new
kernel to its final destination must not overlap with the destination
area.

In order to achieve that add a new interface allowing to mark all
allocatable memory below a specific physical address as not available.

This is done by walking through all chunks of the buddy allocator and
removing the chunks (or chunk parts) below the boundary. The removed
chunks are put into a list in order to be able to undo the operation
in case kexec is failing before doing any unrecoverable system
modifications.

Any pages freed located below the boundary need to go directly into
the list of reserved pages instead of the free pool.

Call the new function from kexec code.

Signed-off-by: Juergen Gross 
Reviewed-by: Jason Andryuk 
---
 include/mm.h |  5 +++
 kexec.c      |  5 +++
 mm.c         | 89 +++++++++++++++++++++++++++++++++++++++++++++++++++-
 3 files changed, 98 insertions(+), 1 deletion(-)

diff --git a/include/mm.h b/include/mm.h
index 4fc364ff..5775c3e1 100644
--- a/include/mm.h
+++ b/include/mm.h
@@ -57,6 +57,11 @@ unsigned long alloc_pages(int order);
 void free_pages(void *pointer, int order);
 #define free_page(p)    free_pages(p, 0)
 
+#ifdef CONFIG_KEXEC
+void reserve_memory_below(unsigned long boundary);
+void unreserve_memory_below(void);
+#endif
+
 static __inline__ int get_order(unsigned long size)
 {
     int order;
diff --git a/kexec.c b/kexec.c
index 31839382..1a90d8ab 100644
--- a/kexec.c
+++ b/kexec.c
@@ -174,6 +174,11 @@ int kexec(void *kernel, unsigned long kernel_size, const char *cmdline)
 
     kexec_set_param_loc(cmdline);
 
+    reserve_memory_below(kexec_last_addr);
+
+    /* Error exit. */
+    unreserve_memory_below();
+
     return ENOSYS;
 }
 EXPORT_SYMBOL(kexec);
diff --git a/mm.c b/mm.c
index a5d3f5e5..9236db58 100644
--- a/mm.c
+++ b/mm.c
@@ -230,6 +230,84 @@ static void init_page_allocator(unsigned long min, unsigned long max)
     mm_alloc_bitmap_remap();
 }
 
+#ifdef CONFIG_KEXEC
+static chunk_head_t *reserved_chunks;
+static unsigned long boundary_pfn;
+
+static void free_pages_below(void *pointer, unsigned int order)
+{
+    unsigned long pfn_s, pfn;
+    chunk_head_t *ch = pointer;
+
+    pfn_s = virt_to_pfn(ch);
+
+    if ( pfn_s + (1UL << order) <= boundary_pfn )
+    {
+        /* Put complete chunk into reserved list. */
+        ch->level = order;
+        ch->next = reserved_chunks;
+        reserved_chunks = ch;
+    }
+    else
+    {
+        /* Put pages below boundary into reserved list. */
+        for ( pfn = pfn_s; pfn < boundary_pfn; pfn++ )
+        {
+            chunk_head_t *ch_res = pfn_to_virt(pfn);
+
+            ch_res->level = 0;
+            ch_res->next = reserved_chunks;
+            reserved_chunks = ch_res;
+        }
+
+        /* Return pages above boundary to free pool again. */
+        for ( ; pfn < pfn_s + (1UL << order); pfn++ )
+            free_pages(pfn_to_virt(pfn), 0);
+    }
+}
+
+void reserve_memory_below(unsigned long boundary)
+{
+    unsigned long pfn;
+    unsigned int order;
+    chunk_head_t *ch;
+
+    ASSERT(!boundary_pfn);
+    boundary_pfn = PHYS_PFN(boundary);
+
+    for ( order = 0; order < FREELIST_SIZE; order++ )
+    {
+        for ( ch = free_list[order].next; !FREELIST_EMPTY(ch); ch = ch->next )
+        {
+            pfn = virt_to_pfn(ch);
+            if ( pfn >= boundary_pfn )
+                continue;
+
+            /* Dequeue from this level, at least parts will be reserved. */
+            dequeue_elem(ch);
+            /* Mark all as allocated, pieces above boundary will be returned. */
+            map_alloc(pfn, 1UL << ch->level);
+
+            free_pages_below(ch, ch->level);
+        }
+    }
+}
+
+void unreserve_memory_below(void)
+{
+    chunk_head_t *ch;
+
+    boundary_pfn = 0;
+
+    while ( reserved_chunks )
+    {
+        ch = reserved_chunks;
+        reserved_chunks = ch->next;
+        free_pages(ch, ch->level);
+    }
+}
+#endif /* CONFIG_KEXEC */
+
 /* Allocate 2^@order contiguous pages. Returns a VIRTUAL address. */
 unsigned long alloc_pages(int order)
 {
@@ -279,10 +357,19 @@ EXPORT_SYMBOL(alloc_pages);
 void free_pages(void *pointer, int order)
 {
     chunk_head_t *freed_ch, *to_merge_ch;
+    unsigned long pfn = virt_to_pfn(pointer);
     unsigned long mask;
 
+#ifdef CONFIG_KEXEC
+    if ( pfn < boundary_pfn )
+    {
+        free_pages_below(pointer, order);
+        return;
+    }
+#endif
+
     /* First free the chunk */
-    map_free(virt_to_pfn(pointer), 1UL << order);
+    map_free(pfn, 1UL << order);
 
     /* Create free chunk */
     freed_ch = (chunk_head_t *)pointer;
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 08:50:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 08:50:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016942.1393936 (Exim 4.92)
	(envelope-from )
	id 1uR5YB-000450-Ey; Mon, 16 Jun 2025 08:50:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016942.1393936; Mon, 16 Jun 2025 08:50:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uR5YB-00044t-C1; Mon, 16 Jun 2025 08:50:43 +0000
Received: by outflank-mailman (input) for mailman id 1016942;
 Mon, 16 Jun 2025 08:50: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 1uR5Uo-0007jR-GY
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 08:47:14 +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 7eedf500-4a8e-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 10:47:12 +0200 (CEST)
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 2B3FB1F387;
 Mon, 16 Jun 2025 08:47: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 E1D1D139E2;
 Mon, 16 Jun 2025 08:47:11 +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 c91kNQ/aT2gzQAAAD6G6ig
 (envelope-from ); Mon, 16 Jun 2025 08:47: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: 7eedf500-4a8e-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750063632; 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=PH+wEmmUZQaMniHgWmRo2+UM2z0RSGbsNqftNFMeuQo=;
	b=F86He+TTVrGS+5vuLSTsGyJlyDfbSDa2RjExEiUHJJVgeHR/0gNLAlWNdO94q/vQdZu95C
	YUUKnoK5lVD5tj9tj5TztJtAVntuujCirxRsmCiRo/3mmgP66lVjufKJe+y0i7/Q9Tp9gW
	keaScFbi1Mvlij0y3jhG7E+beTdJjv0=
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=F86He+TT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750063632; 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=PH+wEmmUZQaMniHgWmRo2+UM2z0RSGbsNqftNFMeuQo=;
	b=F86He+TTVrGS+5vuLSTsGyJlyDfbSDa2RjExEiUHJJVgeHR/0gNLAlWNdO94q/vQdZu95C
	YUUKnoK5lVD5tj9tj5TztJtAVntuujCirxRsmCiRo/3mmgP66lVjufKJe+y0i7/Q9Tp9gW
	keaScFbi1Mvlij0y3jhG7E+beTdJjv0=
From: Juergen Gross 
To: minios-devel@lists.xenproject.org,
	xen-devel@lists.xenproject.org
Cc: samuel.thibault@ens-lyon.org,
	Juergen Gross ,
	Jason Andryuk 
Subject: [MINI-OS PATCH v2 09/12] Mini-OS: mm: change set_readonly() to change_readonly()
Date: Mon, 16 Jun 2025 10:46:16 +0200
Message-ID: <20250616084619.11112-10-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250616084619.11112-1-jgross@suse.com>
References: <20250616084619.11112-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
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)[suse.com:dkim,suse.com:mid,suse.com:email,imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns,amd.com:email];
	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-Spam-Level: 
X-Spam-Flag: NO
X-Rspamd-Queue-Id: 2B3FB1F387
X-Rspamd-Action: no action
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Score: -3.01

Rename set_readonly() to change_readonly() and add a parameter
specifying whether it should set the kernel to readonly or to writable.
At the same time move the boundary setting from the only caller into
the function itself, avoiding the need to use the same boundaries in
future, when it will be called to set the kernel to writable again.
Make the function globally visible in order to allow calling it from
kexec coding later.

Merge clear_bootstrap() into change_readonly() and undo its setting of
page 0 to invalid when setting the kernel writable.

Signed-off-by: Juergen Gross 
Reviewed-by: Jason Andryuk 
---
 arch/x86/mm.c | 111 +++++++++++++++++++++++++++-----------------------
 include/mm.h  |   3 ++
 2 files changed, 64 insertions(+), 50 deletions(-)

diff --git a/arch/x86/mm.c b/arch/x86/mm.c
index a71eb192..f4419d95 100644
--- a/arch/x86/mm.c
+++ b/arch/x86/mm.c
@@ -405,17 +405,19 @@ static void build_pagetable(unsigned long *start_pfn, unsigned long *max_pfn)
  */
 extern struct shared_info shared_info;
 
-struct set_readonly_par {
+struct change_readonly_par {
     unsigned long etext;
 #ifdef CONFIG_PARAVIRT
     unsigned int count;
 #endif
+    bool readonly;
 };
 
-static int set_readonly_func(unsigned long va, unsigned int lvl, bool is_leaf,
-                             pgentry_t *pte, void *par)
+static int change_readonly_func(unsigned long va, unsigned int lvl,
+                                bool is_leaf, pgentry_t *pte, void *par)
 {
-    struct set_readonly_par *ro = par;
+    struct change_readonly_par *ro = par;
+    pgentry_t newval;
 
     if ( !is_leaf )
         return 0;
@@ -429,9 +431,11 @@ static int set_readonly_func(unsigned long va, unsigned int lvl, bool is_leaf,
         return 0;
     }
 
+    newval = ro->readonly ? (*pte & ~_PAGE_RW) : (*pte | _PAGE_RW);
+
 #ifdef CONFIG_PARAVIRT
     mmu_updates[ro->count].ptr = virt_to_mach(pte);
-    mmu_updates[ro->count].val = *pte & ~_PAGE_RW;
+    mmu_updates[ro->count].val = newval;
     ro->count++;
 
     if ( ro->count == L1_PAGETABLE_ENTRIES )
@@ -442,7 +446,7 @@ static int set_readonly_func(unsigned long va, unsigned int lvl, bool is_leaf,
          ro->count = 0;
     }
 #else
-    *pte &= ~_PAGE_RW;
+    *pte = newval;
 #endif
 
     return 0;
@@ -463,23 +467,6 @@ static void tlb_flush(void)
 }
 #endif
 
-static void set_readonly(void *text, void *etext)
-{
-    struct set_readonly_par setro = { .etext = (unsigned long)etext };
-    unsigned long start_address = PAGE_ALIGN((unsigned long)text);
-
-    printk("setting %p-%p readonly\n", text, etext);
-    walk_pt(start_address, setro.etext, set_readonly_func, &setro);
-
-#ifdef CONFIG_PARAVIRT
-    if ( setro.count &&
-         HYPERVISOR_mmu_update(mmu_updates, setro.count, NULL, DOMID_SELF) < 0)
-        BUG();
-#endif
-
-    tlb_flush();
-}
-
 /*
  * get the PTE for virtual address va if it exists. Otherwise NULL.
  */
@@ -508,6 +495,51 @@ static pgentry_t *get_pgt(unsigned long va)
     return tab;
 }
 
+void change_readonly(bool readonly)
+{
+    struct change_readonly_par ro = {
+        .etext = (unsigned long)&_erodata,
+        .readonly = readonly,
+    };
+    unsigned long start_address = PAGE_ALIGN((unsigned long)&_text);
+#ifdef CONFIG_PARAVIRT
+    pte_t nullpte = { };
+    int rc;
+#else
+    pgentry_t *pgt = get_pgt((unsigned long)&_text);
+#endif
+
+    if ( readonly )
+    {
+#ifdef CONFIG_PARAVIRT
+        if ( (rc = HYPERVISOR_update_va_mapping(0, nullpte, UVMF_INVLPG)) )
+            printk("Unable to unmap NULL page. rc=%d\n", rc);
+#else
+        *pgt = 0;
+        invlpg((unsigned long)&_text);
+#endif
+    }
+    else
+    {
+#ifdef CONFIG_PARAVIRT
+        /* No kexec support with PARAVIRT. */
+        BUG();
+#else
+        *pgt = L1_PROT;
+#endif
+    }
+
+    printk("setting %p-%p readonly\n", &_text, &_erodata);
+    walk_pt(start_address, ro.etext, change_readonly_func, &ro);
+
+#ifdef CONFIG_PARAVIRT
+    if ( ro.count &&
+         HYPERVISOR_mmu_update(mmu_updates, ro.count, NULL, DOMID_SELF) < 0)
+        BUG();
+#endif
+
+    tlb_flush();
+}
 
 /*
  * return a valid PTE for a given virtual address. If PTE does not exist,
@@ -789,31 +821,6 @@ int unmap_frames(unsigned long va, unsigned long num_frames)
 }
 EXPORT_SYMBOL(unmap_frames);
 
-/*
- * Clear some of the bootstrap memory
- */
-static void clear_bootstrap(void)
-{
-#ifdef CONFIG_PARAVIRT
-    pte_t nullpte = { };
-    int rc;
-#else
-    pgentry_t *pgt;
-#endif
-
-    /* Use first page as the CoW zero page */
-    memset(&_text, 0, PAGE_SIZE);
-    mfn_zero = virt_to_mfn((unsigned long) &_text);
-#ifdef CONFIG_PARAVIRT
-    if ( (rc = HYPERVISOR_update_va_mapping(0, nullpte, UVMF_INVLPG)) )
-        printk("Unable to unmap NULL page. rc=%d\n", rc);
-#else
-    pgt = get_pgt((unsigned long)&_text);
-    *pgt = 0;
-    invlpg((unsigned long)&_text);
-#endif
-}
-
 #ifdef CONFIG_PARAVIRT
 void p2m_chk_pfn(unsigned long pfn)
 {
@@ -884,8 +891,12 @@ void arch_init_mm(unsigned long* start_pfn_p, unsigned long* max_pfn_p)
     printk("    max_pfn: %lx\n", max_pfn);
 
     build_pagetable(&start_pfn, &max_pfn);
-    clear_bootstrap();
-    set_readonly(&_text, &_erodata);
+
+    /* Prepare page 0 as CoW page. */
+    memset(&_text, 0, PAGE_SIZE);
+    mfn_zero = virt_to_mfn((unsigned long)&_text);
+
+    change_readonly(true);
 
     *start_pfn_p = start_pfn;
     *max_pfn_p = max_pfn;
diff --git a/include/mm.h b/include/mm.h
index 5775c3e1..0a16d56c 100644
--- a/include/mm.h
+++ b/include/mm.h
@@ -25,6 +25,7 @@
 #ifndef _MM_H_
 #define _MM_H_
 
+#include 
 #if defined(__i386__)
 #include 
 #elif defined(__x86_64__)
@@ -92,4 +93,6 @@ extern unsigned long heap, brk, heap_mapped, heap_end;
 int free_physical_pages(xen_pfn_t *mfns, int n);
 void fini_mm(void);
 
+void change_readonly(bool readonly);
+
 #endif /* _MM_H_ */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 08:50:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 08:50:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016973.1393991 (Exim 4.92)
	(envelope-from )
	id 1uR5YK-0005QK-5H; Mon, 16 Jun 2025 08:50:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016973.1393991; Mon, 16 Jun 2025 08:50:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uR5YJ-0005P1-W7; Mon, 16 Jun 2025 08:50:51 +0000
Received: by outflank-mailman (input) for mailman id 1016973;
 Mon, 16 Jun 2025 08:50: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 1uR5Ub-0007jR-Qo
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 08:47:01 +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 78390ead-4a8e-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 10:47:01 +0200 (CEST)
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 E98762118C;
 Mon, 16 Jun 2025 08:47:00 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id AFA83139E2;
 Mon, 16 Jun 2025 08:47: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 sb9uKQTaT2ghQAAAD6G6ig
 (envelope-from ); Mon, 16 Jun 2025 08:47: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: 78390ead-4a8e-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750063621; 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=fyowQBL0+KxczJ3QgQBuNM66VYPd6WBeOp+F4jmgKk4=;
	b=cNJEHyikb9mt/7zsAQCnic9WNs6aNvWlVAo7gh5Foz8ylwwofNgGRJQdVwjOub6o+3afV2
	cfGHzesavDEPiFkJ+yu4RECAegYAu34Qavlgc0B6rpoWQ8EO/SgPi2t/NY8pGVUDmacdaF
	H2v2SEOHo8FR17XTiSMsAvqz0hUIzDQ=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750063620; 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=fyowQBL0+KxczJ3QgQBuNM66VYPd6WBeOp+F4jmgKk4=;
	b=b8TE957bRIDX2dKj2D4qCqXjot6zF2lhHmjCjRiwyB9XpopFzubXSiXK8jpJthg5yFsgrA
	yHw/6RvRm5L75cgVyPPBpVKIpW/tNqKH6H/6o1Ct0d25D+ny7ImtKuSfGrDwA+OnZ6JyvK
	aJvjIyol4usendyS26lfrJa4TZf3ii0=
From: Juergen Gross 
To: minios-devel@lists.xenproject.org,
	xen-devel@lists.xenproject.org
Cc: samuel.thibault@ens-lyon.org,
	Juergen Gross ,
	Jason Andryuk 
Subject: [MINI-OS PATCH v2 07/12] mini-os: kexec: build parameters for new kernel
Date: Mon, 16 Jun 2025 10:46:14 +0200
Message-ID: <20250616084619.11112-8-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250616084619.11112-1-jgross@suse.com>
References: <20250616084619.11112-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-2.80 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-0.999];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCVD_COUNT_TWO(0.00)[2];
	TO_DN_SOME(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	RCPT_COUNT_FIVE(0.00)[5];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email,suse.com:mid,imap1.dmz-prg2.suse.org:helo,amd.com:email]
X-Spam-Level: 
X-Spam-Flag: NO
X-Spam-Score: -2.80

Build the parameters for the new kernel, consisting of the
hvm_start_info struct, the memory map and the command line.

Signed-off-by: Juergen Gross 
Reviewed-by: Jason Andryuk 
---
 arch/x86/kexec.c | 58 ++++++++++++++++++++++++++++++++++++++++++++++++
 include/kexec.h  |  4 ++++
 kexec.c          | 13 ++++++++++-
 3 files changed, 74 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kexec.c b/arch/x86/kexec.c
index 47830905..fc58473e 100644
--- a/arch/x86/kexec.c
+++ b/arch/x86/kexec.c
@@ -199,6 +199,7 @@ bool kexec_arch_need_analyze_shdrs(void)
 
 static unsigned long kexec_param_loc;
 static unsigned int kexec_param_size;
+static unsigned long kexec_param_mem;
 
 void kexec_set_param_loc(const char *cmdline)
 {
@@ -211,4 +212,61 @@ void kexec_set_param_loc(const char *cmdline)
     kexec_last_addr += kexec_param_size;
     kexec_last_addr = round_pgup(kexec_last_addr);
 }
+
+int kexec_get_entry(const char *cmdline)
+{
+    struct hvm_start_info *info;
+    struct hvm_memmap_table_entry *mmap;
+    unsigned int order;
+    unsigned int i;
+
+    if ( kernel_phys_entry == ~0UL )
+        return ENOEXEC;
+
+    order = get_order(kexec_param_size);
+
+    kexec_param_mem = alloc_pages(order);
+    if ( !kexec_param_mem )
+        return ENOMEM;
+
+    info = (struct hvm_start_info *)kexec_param_mem;
+    memset(info, 0, sizeof(*info));
+    info->magic = XEN_HVM_START_MAGIC_VALUE;
+    info->version = 1;
+    info->cmdline_paddr = kexec_param_mem + sizeof(*info) +
+                          e820_entries * sizeof(struct hvm_memmap_table_entry);
+    info->memmap_paddr = kexec_param_mem + sizeof(*info);
+    info->memmap_entries = e820_entries;
+
+    mmap = (struct hvm_memmap_table_entry *)(info + 1);
+    for ( i = 0; i < e820_entries; i++ )
+    {
+        mmap->addr = e820_map[i].addr;
+        mmap->size = e820_map[i].size;
+        mmap->type = e820_map[i].type;
+        mmap++;
+    }
+
+    strcpy((char *)mmap, cmdline);
+
+    if ( kexec_add_action(KEXEC_COPY, to_virt(kexec_param_loc), info,
+                          kexec_param_size) )
+        return ENOSPC;
+
+    /* The call of the new kernel happens via the physical address! */
+    if ( kexec_add_action(KEXEC_CALL, (void *)kernel_phys_entry,
+                          (void *)kexec_param_loc, 0) )
+        return ENOSPC;
+
+    return 0;
+}
+
+void kexec_get_entry_undo(void)
+{
+    if ( kexec_param_mem )
+    {
+        free_pages((void *)kexec_param_mem, get_order(kexec_param_size));
+        kexec_param_mem = 0;
+    }
+}
 #endif /* CONFIG_KEXEC */
diff --git a/include/kexec.h b/include/kexec.h
index 8a2b552f..7b103dea 100644
--- a/include/kexec.h
+++ b/include/kexec.h
@@ -45,4 +45,8 @@ bool kexec_arch_need_analyze_shdrs(void);
 /* Finalize parameter location and size. */
 void kexec_set_param_loc(const char *cmdline);
 
+/* Get entry point and parameter of new kernel. */
+int kexec_get_entry(const char *cmdline);
+void kexec_get_entry_undo(void);
+
 #endif /* _KEXEC_H */
diff --git a/kexec.c b/kexec.c
index 1a90d8ab..e762fbeb 100644
--- a/kexec.c
+++ b/kexec.c
@@ -176,10 +176,21 @@ int kexec(void *kernel, unsigned long kernel_size, const char *cmdline)
 
     reserve_memory_below(kexec_last_addr);
 
+    ret = kexec_get_entry(cmdline);
+    if ( ret )
+    {
+        printk("kexec: ELF file of new kernel has no valid entry point\n");
+        goto err;
+    }
+
     /* Error exit. */
+    ret = ENOSYS;
+
+ err:
     unreserve_memory_below();
+    kexec_get_entry_undo();
 
-    return ENOSYS;
+    return ret;
 }
 EXPORT_SYMBOL(kexec);
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 08:50:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 08:50:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016981.1394003 (Exim 4.92)
	(envelope-from )
	id 1uR5YL-0005jV-Kt; Mon, 16 Jun 2025 08:50:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016981.1394003; Mon, 16 Jun 2025 08: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 1uR5YL-0005jB-HB; Mon, 16 Jun 2025 08:50:53 +0000
Received: by outflank-mailman (input) for mailman id 1016981;
 Mon, 16 Jun 2025 08:50: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 1uR5Uy-0007jR-7j
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 08:47:24 +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 85a4ee03-4a8e-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 10:47:23 +0200 (CEST)
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 53FAB21203;
 Mon, 16 Jun 2025 08:47: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 1BCF7139E2;
 Mon, 16 Jun 2025 08:47: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 +Cs4BRvaT2hAQAAAD6G6ig
 (envelope-from ); Mon, 16 Jun 2025 08:47: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: 85a4ee03-4a8e-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750063643; 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=k/MeYSsGBJ27+vnobz1RvxbDTqVako7BAJOkWTQLl8E=;
	b=GXDjXMGo+0jyW1vB1crqi8s5c4HCfFeRis9b1zeJ45ctD3I/jEBpSePWxd+6dr05WO8bUM
	VEC11DAu0zCijo+VAjliNqxmux25hCpMVsyRzX9BKg1AZCzDfzQo0X5u7N+MYSqwgsPhF1
	kfjYWesKAEyZNk9NLbamW9ewCBDyygM=
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=GXDjXMGo
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750063643; 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=k/MeYSsGBJ27+vnobz1RvxbDTqVako7BAJOkWTQLl8E=;
	b=GXDjXMGo+0jyW1vB1crqi8s5c4HCfFeRis9b1zeJ45ctD3I/jEBpSePWxd+6dr05WO8bUM
	VEC11DAu0zCijo+VAjliNqxmux25hCpMVsyRzX9BKg1AZCzDfzQo0X5u7N+MYSqwgsPhF1
	kfjYWesKAEyZNk9NLbamW9ewCBDyygM=
From: Juergen Gross 
To: minios-devel@lists.xenproject.org,
	xen-devel@lists.xenproject.org
Cc: samuel.thibault@ens-lyon.org,
	Juergen Gross ,
	Jason Andryuk 
Subject: [MINI-OS PATCH v2 11/12] mini-os: kexec: add kexec callback functionality
Date: Mon, 16 Jun 2025 10:46:18 +0200
Message-ID: <20250616084619.11112-12-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250616084619.11112-1-jgross@suse.com>
References: <20250616084619.11112-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Queue-Id: 53FAB21203
X-Rspamd-Action: no action
X-Spam-Flag: NO
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)[];
	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)[];
	RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received];
	DNSWL_BLOCKED(0.00)[2a07:de40:b281:106:10:150:64:167:received,2a07:de40:b281:104:10:150:64:97:from];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	DKIM_TRACE(0.00)[suse.com:+];
	RCPT_COUNT_FIVE(0.00)[5];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,suse.com:dkim,suse.com:email,imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo,amd.com:email]
X-Spam-Score: -3.01
X-Spam-Level: 

Add a kexec_call() macro which will provide the capability to register
a function for being called when doing a kexec() call. The called
functions will be called with a boolean parameter "undo" indicating
whether a previous call needs to be undone due to a failure during
kexec().

The related loop to call all callbacks is added to kexec().

Signed-off-by: Juergen Gross 
Reviewed-by: Jason Andryuk 
---
 arch/x86/minios-x86.lds.S |  8 ++++++++
 include/kexec.h           |  6 ++++++
 kexec.c                   | 13 +++++++++++++
 3 files changed, 27 insertions(+)

diff --git a/arch/x86/minios-x86.lds.S b/arch/x86/minios-x86.lds.S
index 8a1db7d4..8c6e0a60 100644
--- a/arch/x86/minios-x86.lds.S
+++ b/arch/x86/minios-x86.lds.S
@@ -58,6 +58,14 @@ SECTIONS
         }
         PROVIDE (__fini_array_end = .);
 
+#if defined(CONFIG_KEXEC)
+        PROVIDE (__kexec_array_start = .);
+        .kexec_array : {
+                *(.kexec_array)
+        }
+        PROVIDE (__kexec_array_end = .);
+#endif
+
         .ctors : {
                 __CTOR_LIST__ = .;
                 *(.ctors)
diff --git a/include/kexec.h b/include/kexec.h
index 411fa013..b89c3000 100644
--- a/include/kexec.h
+++ b/include/kexec.h
@@ -18,6 +18,12 @@ struct kexec_action {
 
 extern char _kexec_start[], _kexec_end[];
 extern struct kexec_action kexec_actions[KEXEC_MAX_ACTIONS];
+extern unsigned long __kexec_array_start[], __kexec_array_end[];
+
+typedef int(*kexeccall_t)(bool undo);
+#define kexec_call(func)                                                   \
+    static kexeccall_t __kexeccall_##func __attribute__((__used__))        \
+                       __attribute__((__section__(".kexec_array"))) = func
 
 extern unsigned long kexec_last_addr;
 
diff --git a/kexec.c b/kexec.c
index 1ef7ce84..f42aa8ad 100644
--- a/kexec.c
+++ b/kexec.c
@@ -167,6 +167,7 @@ static int analyze_kernel(void *kernel, unsigned long size)
 int kexec(void *kernel, unsigned long kernel_size, const char *cmdline)
 {
     int ret;
+    unsigned long *func;
 
     ret = analyze_kernel(kernel, kernel_size);
     if ( ret )
@@ -190,6 +191,18 @@ int kexec(void *kernel, unsigned long kernel_size, const char *cmdline)
     if ( ret )
         goto err;
 
+    for ( func = __kexec_array_start; func < __kexec_array_end; func++ )
+    {
+        ret = ((kexeccall_t)(*func))(false);
+        if ( ret )
+        {
+            for ( func--; func >= __kexec_array_start; func-- )
+                ((kexeccall_t)(*func))(true);
+
+            goto err;
+        }
+    }
+
     /* Error exit. */
     ret = ENOSYS;
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 08:50:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 08:50:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1016988.1394015 (Exim 4.92)
	(envelope-from )
	id 1uR5YP-0006Fu-01; Mon, 16 Jun 2025 08:50:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1016988.1394015; Mon, 16 Jun 2025 08:50: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 1uR5YO-0006Fb-QX; Mon, 16 Jun 2025 08:50:56 +0000
Received: by outflank-mailman (input) for mailman id 1016988;
 Mon, 16 Jun 2025 08:50: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 1uR5Uh-0007jR-Ep
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 08:47:07 +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 7b999b87-4a8e-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 10:47:06 +0200 (CEST)
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 861F32118C;
 Mon, 16 Jun 2025 08:47: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 4B8F4139E2;
 Mon, 16 Jun 2025 08:47: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 khXvEAraT2gsQAAAD6G6ig
 (envelope-from ); Mon, 16 Jun 2025 08:47: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: 7b999b87-4a8e-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750063626; 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=gNbWUmZdTVJqcXlU2fjp4XsMXe38emePLWQ2ppavBkA=;
	b=tls3nwVCrtCHQR59uMJcXlRMhSzYdIzt6nLDRUrn5+RcFk84twmAK068pfugW7FkGASKel
	omvkvRx7Ez7ZPUfB9awNnuzVEX00E9WvgLBp1SaJgt9kdeBwIr8QLdStc5veO8tRuo3SzN
	HJza56kLAE3SyO3bGwPWHlve/xxoPXc=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750063626; 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=gNbWUmZdTVJqcXlU2fjp4XsMXe38emePLWQ2ppavBkA=;
	b=tls3nwVCrtCHQR59uMJcXlRMhSzYdIzt6nLDRUrn5+RcFk84twmAK068pfugW7FkGASKel
	omvkvRx7Ez7ZPUfB9awNnuzVEX00E9WvgLBp1SaJgt9kdeBwIr8QLdStc5veO8tRuo3SzN
	HJza56kLAE3SyO3bGwPWHlve/xxoPXc=
From: Juergen Gross 
To: minios-devel@lists.xenproject.org,
	xen-devel@lists.xenproject.org
Cc: samuel.thibault@ens-lyon.org,
	Juergen Gross ,
	Jason Andryuk 
Subject: [MINI-OS PATCH v2 08/12] mini-os: kexec: move used pages away for new kernel
Date: Mon, 16 Jun 2025 10:46:15 +0200
Message-ID: <20250616084619.11112-9-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250616084619.11112-1-jgross@suse.com>
References: <20250616084619.11112-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-2.80 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-0.999];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCVD_COUNT_TWO(0.00)[2];
	TO_DN_SOME(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	RCPT_COUNT_FIVE(0.00)[5];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email,suse.com:mid,imap1.dmz-prg2.suse.org:helo,amd.com:email]
X-Spam-Level: 
X-Spam-Flag: NO
X-Spam-Score: -2.80

Copying the new kexec kernel must not overwrite any pages still needed
during this process. Those are especially the GDT, IDT and page tables.

Move those to new allocated pages and update any related pointers.

In case the kexec process is cancelled later, don't undo any page table
moves, as the system can just be used with the new layout. By freeing
the original pages there is no memory leaking.

GDT and IDT should be reverted to their original locations, as their
original memory can't be freed due to not being whole pages.

Signed-off-by: Juergen Gross 
Reviewed-by: Jason Andryuk 
---
 arch/x86/mm.c   | 126 ++++++++++++++++++++++++++++++++++++++++++++++++
 include/kexec.h |   5 ++
 kexec.c         |   6 +++
 3 files changed, 137 insertions(+)

diff --git a/arch/x86/mm.c b/arch/x86/mm.c
index 3ba6d917..a71eb192 100644
--- a/arch/x86/mm.c
+++ b/arch/x86/mm.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -923,3 +924,128 @@ unsigned long map_frame_virt(unsigned long mfn)
     return addr;
 }
 EXPORT_SYMBOL(map_frame_virt);
+
+#ifdef CONFIG_KEXEC
+static unsigned long kexec_gdt;
+static unsigned long kexec_idt;
+
+static int move_pt(unsigned long va, unsigned int lvl, bool is_leaf,
+                   pgentry_t *pte, void *par)
+{
+    unsigned long boundary_pfn = *(unsigned long *)par;
+    unsigned long pfn;
+    void *old_pg, *new_pg;
+
+    if ( is_leaf )
+        return 0;
+
+    pfn = (lvl == PAGETABLE_LEVELS + 1) ? PHYS_PFN(*(unsigned long *)pte)
+                                        : pte_to_mfn(*pte);
+    if ( pfn >= boundary_pfn )
+        return 0;
+
+    new_pg = (void *)alloc_page();
+    if ( !new_pg )
+        return ENOMEM;
+    old_pg = pfn_to_virt(pfn);
+    memcpy(new_pg, old_pg, PAGE_SIZE);
+    if ( lvl == PAGETABLE_LEVELS + 1 )
+        *(pgentry_t **)pte = new_pg;
+    else
+        *pte = ((unsigned long)new_pg & PAGE_MASK) | ptdata[lvl].prot;
+
+    tlb_flush();
+
+    free_page(old_pg);
+
+    return 0;
+}
+
+static int move_leaf(unsigned long va, unsigned int lvl, bool is_leaf,
+                     pgentry_t *pte, void *par)
+{
+    unsigned long boundary_pfn = *(unsigned long *)par;
+    unsigned long pfn;
+    void *old_pg, *new_pg;
+
+    if ( !is_leaf )
+        return 0;
+
+    /* No large page support, all pages must be valid. */
+    if ( (*pte & _PAGE_PSE) || !(*pte & _PAGE_PRESENT) )
+        return EINVAL;
+
+    pfn = pte_to_mfn(*pte);
+    if ( pfn >= boundary_pfn )
+        return 0;
+
+    new_pg = (void *)alloc_page();
+    if ( !new_pg )
+        return ENOMEM;
+    old_pg = pfn_to_virt(pfn);
+    memcpy(new_pg, old_pg, PAGE_SIZE);
+    *pte = ((unsigned long)new_pg & PAGE_MASK) | ptdata[lvl].prot;
+
+    invlpg(va);
+
+    free_page(old_pg);
+
+    return 0;
+}
+
+int kexec_move_used_pages(unsigned long boundary, unsigned long kernel,
+                          unsigned long kernel_size)
+{
+    int ret;
+    unsigned long boundary_pfn = PHYS_PFN(boundary);
+
+    kexec_gdt = alloc_page();
+    if ( !kexec_gdt )
+        return ENOMEM;
+    memcpy((char *)kexec_gdt, &gdt, sizeof(gdt));
+    gdt_ptr.base = kexec_gdt;
+    asm volatile("lgdt %0" : : "m" (gdt_ptr));
+
+    kexec_idt = alloc_page();
+    if ( !kexec_idt )
+        return ENOMEM;
+    memcpy((char *)kexec_idt, &idt, sizeof(idt));
+    idt_ptr.base = kexec_idt;
+    asm volatile("lidt %0" : : "m" (idt_ptr));
+
+    /* Top level page table needs special handling. */
+    ret = move_pt(0, PAGETABLE_LEVELS + 1, false, (pgentry_t *)(&pt_base),
+                  &boundary_pfn);
+    if ( ret )
+        return ret;
+    ret = walk_pt(0, ~0UL, move_pt, &boundary_pfn);
+    if ( ret )
+        return ret;
+
+    /* Move new kernel image pages. */
+    ret = walk_pt(kernel, kernel + kernel_size - 1, move_leaf, &boundary_pfn);
+    if ( ret )
+        return ret;
+
+    return 0;
+}
+
+void kexec_move_used_pages_undo(void)
+{
+    if ( kexec_gdt )
+    {
+        gdt_ptr.base = (unsigned long)&gdt;
+        asm volatile("lgdt %0" : : "m" (gdt_ptr));
+        free_page((void *)kexec_gdt);
+        kexec_gdt = 0;
+    }
+
+    if ( kexec_idt )
+    {
+        idt_ptr.base = (unsigned long)&idt;
+        asm volatile("lidt %0" : : "m" (idt_ptr));
+        free_page((void *)kexec_idt);
+        kexec_idt = 0;
+    }
+}
+#endif
diff --git a/include/kexec.h b/include/kexec.h
index 7b103dea..411fa013 100644
--- a/include/kexec.h
+++ b/include/kexec.h
@@ -49,4 +49,9 @@ void kexec_set_param_loc(const char *cmdline);
 int kexec_get_entry(const char *cmdline);
 void kexec_get_entry_undo(void);
 
+/* Move used pages away from new kernel area. */
+int kexec_move_used_pages(unsigned long boundary, unsigned long kernel,
+                          unsigned long kernel_size);
+void kexec_move_used_pages_undo(void);
+
 #endif /* _KEXEC_H */
diff --git a/kexec.c b/kexec.c
index e762fbeb..3b11a69c 100644
--- a/kexec.c
+++ b/kexec.c
@@ -183,11 +183,17 @@ int kexec(void *kernel, unsigned long kernel_size, const char *cmdline)
         goto err;
     }
 
+    ret = kexec_move_used_pages(kexec_last_addr, (unsigned long)kernel,
+                                kernel_size);
+    if ( ret )
+        goto err;
+
     /* Error exit. */
     ret = ENOSYS;
 
  err:
     unreserve_memory_below();
+    kexec_move_used_pages_undo();
     kexec_get_entry_undo();
 
     return ret;
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 09:05:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 09:05:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017066.1394025 (Exim 4.92)
	(envelope-from )
	id 1uR5mW-0001gC-75; Mon, 16 Jun 2025 09:05:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017066.1394025; Mon, 16 Jun 2025 09:05: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 1uR5mW-0001g5-42; Mon, 16 Jun 2025 09:05:32 +0000
Received: by outflank-mailman (input) for mailman id 1017066;
 Mon, 16 Jun 2025 09:05: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 1uR5mU-0001fz-MJ
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 09:05:30 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20610.outbound.protection.outlook.com
 [2a01:111:f403:2418::610])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0918b1e8-4a91-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 11:05:24 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 CY5PR12MB6156.namprd12.prod.outlook.com (2603:10b6:930:24::15) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8835.28; Mon, 16 Jun 2025 09:05:21 +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.8835.027; Mon, 16 Jun 2025
 09: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: 0918b1e8-4a91-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=UM4AvX0zHU8PourLkY8w8xTXqYkWNfFoHiVBDQPpNAdJcdJY4ZdF7oHmRm0YlBOoXG7f59qiJrbt+D3RRpfZbhDw4+avkfN27IAzP11PFxg3fgg7Bj2kFJusX0OVs6reHsJokISEnSQ6zN3iPZ7RznzEObKVreu4tATxIvxZd8XO1WeScLWxo1X4JvBZGd5keTyo3s2/nOdLFgm0GU6iJuP04qTn1rwauHo5F/4H41RbMImiD2+y9/XyIxyHYmaC5WMP/c3SaUtMmxGPNVFOjxZPzMPw0CIITP2y/7E7gDtxYqSViHCAmWoM1lSXszk8sv8wdFzzFbdZdoH6HOuolw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=86DipraPTR65br2hSMwr9FW4ooObYOdYVQ7sKn3EtmM=;
 b=GshT5erps1nRBHNYbD+GQ/jA7DzV64eVp/VBQIf23aj5zPuftBriITSwfVNMsqb8ysMmKKfY1CywDIjgZFzzhyZhk9Nr37eufXBWzDDnhKXQhk/1ermN3U9rYf3EEhU6BN2L7T0qebfC3hbHZS/98so2X1IAHGHp2DfzfHADjFKUI5lGBlFT7DmyaDkS+pPPdPbDTUn3hbsjWYmudUjATwdmOLy/YMbZSv7ObKsmKGuVszCxUMa3TBBxiBpmGtwDCrQcnMbAjiYGMHCZe0BZFa99sw/+b5ZTnAjBM7bSctMRmZyigpheEaw93V1dj3GrBQj/c0hrHYYGblXzDTqNMg==
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=86DipraPTR65br2hSMwr9FW4ooObYOdYVQ7sKn3EtmM=;
 b=MO0+02L7oJZMvwUP0qbLDJiejH3jigXRCDNKmXHHZbm1wOFqGBoZZHkvcCAEeHurkvoywKNBSothL5wv4N5THqOI3emLQwhlBUobmxyWSicd+KipCErpzjKigWWC2BgAHBeFI3sLzlbnwtM/eGUjgcM0VuyJCOvosc+SwPLNAL8=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v5 01/18] xen/pmstat: guard perf.states[] access with
 XEN_PX_INIT
Thread-Topic: [PATCH v5 01/18] xen/pmstat: guard perf.states[] access with
 XEN_PX_INIT
Thread-Index: AQHbzuQ5KDq5M5MbdEiyL/UuBwqBb7P+KsSAgALCz6A=
Date: Mon, 16 Jun 2025 09:05:20 +0000
Message-ID:
 
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-2-Penny.Zheng@amd.com>
 <0d60d42f-d844-41b5-a8ca-bdfe7883d15b@suse.com>
In-Reply-To: <0d60d42f-d844-41b5-a8ca-bdfe7883d15b@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=True;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-06-16T09:05:12.0000000Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=3;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged
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_|CY5PR12MB6156:EE_
x-ms-office365-filtering-correlation-id: 4278126c-be7e-4a04-86f8-08ddacb4ebee
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?UG9JblFFUTdLa21sYmNRd3pJYnhXNkQxRWo3TVhna2VSNHpWVzNYWXNLL1dr?=
 =?utf-8?B?Z0YyUERSNlB5TEJOb2ZkckIydXlNd1JWc0xWVTQ3YkVOVUEwR1FMV0NhTGF2?=
 =?utf-8?B?RGxYUWVYRkd0MmRFdmt3VjBxNXoxZGMwTGdWQ29Kc21OM1I2VDJSQVRVa1hx?=
 =?utf-8?B?bHg0MG9iSDNxSmo2bDhxSTNnclArdW1ROVBJOG5rM2pQR08vb0Z3MTJWUlpC?=
 =?utf-8?B?VVlPNEpFdWh4V1ErQkoybVZLWTR1WnRWYnMvWGs5cnBXZElwQ05KYU9CelRr?=
 =?utf-8?B?TTgyM3NaeVNPQ0hkbnZRVUJFdk9sNXNaZEFxN0RUUVVzdlY4M1ZPZ1hLQk9j?=
 =?utf-8?B?S0tsek8vRnppTUFIZWk3RG9Wc1ZRem5qWEE0eFdCTGlpVjVMcUtCU0NhL1ZM?=
 =?utf-8?B?d3hYN1FxMTJ6ekpNOHJ6MGJPNllWNG1yVXE5WXFsMlpXSk0xdE1nakFudG1k?=
 =?utf-8?B?UUJXK3owdlovQmZYNW0wZjluQi9lYURPUjBJSVNPUmw5U2pJWER4VHVKaWht?=
 =?utf-8?B?MDdaNjk5bnJ1RmtvcFdWMmlhUGFBaTVleFBabW5xUzB6N3p6UlpFNUhKdHoz?=
 =?utf-8?B?M0F4WS81Nm5CcWRDVUIxU2VaeUlNOVhuZGh3NURpRnltTDBMNHdqNlYvMzBB?=
 =?utf-8?B?b1gxb3ZHenVnYmpVaGFxbGpTVDZiRlhwZTRnNUN5QnJTM01hZEJObEZpOW5C?=
 =?utf-8?B?RTVHVXpLOW5rMkFFbTdJc0NId0VFaHU0WTBDRm5VT1RBUFM4b2pZblRPWm1O?=
 =?utf-8?B?WkxqWjE0bVFHdDg3OHkvNVAzbEd4L3IrT0FYRVdRckxpdCtqUzBGMGoxYVJQ?=
 =?utf-8?B?TjAyRDJTVmh6ZEd2M0RsZkluWFdvemFDWUxaL0hQWkxJT2ZFbE9mYUJ3RzFY?=
 =?utf-8?B?VXFWNlZHdG43QkNFZDRicVZ2cVlaZDJjRldmK2JYWXlmM2wveDhJd21odWkz?=
 =?utf-8?B?bFlYMEtieUZDbDZrbHU3dVg0bnY4YUtpTkU2S1lGYjJtUjdHOEJsTW41QkFQ?=
 =?utf-8?B?VDRjeG9VeVpZYlZIRWNWVVY4ZWsvQ3hSVEwzdWdPWGp2TzNMSk5acERQUTFO?=
 =?utf-8?B?a0srZ3hydXZTcWo4Y3hTSVpUSG1tN2h3aWlyalVXMUR2R2l3azB1Kzg4WmVw?=
 =?utf-8?B?TzVRMkhDNDY5WHgzdlJqdXhzU1RCekd3c2hxVjBaVGVGemNrUiszT2JQTnZC?=
 =?utf-8?B?UEFCNDNqZmo3Y3dvM2ZDN3hqRWlGaSt5aWZzNVQ4ZXNVcEF6N0RzUUQwbDZj?=
 =?utf-8?B?Rmc3ZE53emdRYmxkTTVMbWxPdk94ME9sSHMyZDdncHpIQy83a1JlMVRkVHdW?=
 =?utf-8?B?RHBpS0FqTzNmRVpkS2xtMFpId0Y3cWdPZkc2MEZCSVVBdFo1OTFBMDdyd0Nl?=
 =?utf-8?B?cm9teEJBanAwUm94R0NCVi9BNkR0UXlSczNhNm9WVmtlc2VoZklNS2NKbFBT?=
 =?utf-8?B?WTJkcGVIdXcvUklDL1ZOVGlpNm14bERaVkliNzVYMWZ2WjBwcFlHMkJnTG9S?=
 =?utf-8?B?Z216Yi9kOFY4cFZCcExob0xHcU04NVpYbzA2Mko0MXpFWGJteUcyTzFuc0ZL?=
 =?utf-8?B?NzFLTU94Q0ttVVpDZ1R3WGZRMVZ6R2hGR3JHY2xnUjNtRWZnUjNHbWpSaWdt?=
 =?utf-8?B?QlZxZWFBK2xzTFpQdnVPOS9pM1VpWFhubDgzWjF2dUFPSXl4Z1dzTFFoQkFK?=
 =?utf-8?B?QXVvYkdKMGlMVmJtTU5YaUh4eE5McUZGeXBBT2hnTkRJMTVDeEVOYVlubmlv?=
 =?utf-8?B?YlZiRktvR2JZZlBPTDVOTVU2YUpFSGdDSkZPSzVDc09CcDcrTzcvRXZyWXJT?=
 =?utf-8?B?MmVub1lPbG9MOG9Nbk9UTUcrejhkcFZ1SEVDcHFJVGtvQ0ExRGU0aFBHWUU0?=
 =?utf-8?B?MHg3V3Nnc1M1OTFQWnNuZjhQcG1lZ2dmczZHSVVYZVBieTJsNHZteEFBTVpP?=
 =?utf-8?B?Z3dYS2lyRldjVUtNV09sZSs2RXA0NDJRS0lsUnpVMlNaeEN0dEVEU09NcXZP?=
 =?utf-8?Q?xJ0NRTzpDRwnlYUVtAvgtpmntjJLlk=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)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?TGtiWTEzd0NKaEdFb0Rkc1FPRDV1Z21PRytxZUMreEkrZDVGWlpxZWZMRGYz?=
 =?utf-8?B?MG1EM0pEL25waGdzMjFnZ2lHbVRHNUJDanFBbW1iR1BpYVhHT0NUanF4MmQ2?=
 =?utf-8?B?QkcxSmM3Sm5mdDN3cXpaWCsrR3RyNFduV1dmR2txVnYyVzY5QUtNWHZVRTB2?=
 =?utf-8?B?SnRDWnQzQUhPM0FMUkR5YlhUUzBJTVFoNzNqNnBpT3Z2QjQ4bi9EL2h3Rm12?=
 =?utf-8?B?OU1iVXBUVzhLbWR5bzhJdmphdU5BOUx2VHFDdUx0aXFYb0ZFaUlLMWRJVXJD?=
 =?utf-8?B?QmFMZStiSmptUmhvVlNuM01DWmwvRVBXUTNWd1Y1a2VzOGhUUTJJZUlNeVBN?=
 =?utf-8?B?Snh6c2grMTVRODJObitHRDB3WC85TVlLM1RJb0pURlp3M2VWcEMvcHE5Z2NN?=
 =?utf-8?B?bTIrbGVJK2xxY1dOellpWmRkTTNGcnk2MSs4RklNSkhPMmNsdWQxc2JkTVhM?=
 =?utf-8?B?U2FuZ0xjSVZtOTFVcm9ockZjN2w0NFVabEFQellZakRjak5GdDBuWUcyRnkv?=
 =?utf-8?B?TEZMaDBkczNoSVVXSGZlWDRUWUpSQVVKU05ZbHVMdTRmSWcrbEZVTXJOamg4?=
 =?utf-8?B?cE8yT3d6Q2ZWN2FKekg1NmNiWmY2VWdreHZQLzhHNGtidW00U2s5bnljNTVk?=
 =?utf-8?B?bVNndklXWFc0bFFEOXNSZ0FSbWVQTnU3VDRzVjZWRXMwVXB0RFZXUXpydzhE?=
 =?utf-8?B?RE90WjZqblF6QTVHcFhGa3NGa3ZJeDI3NUFYR1cwMnUwK0VJNCt3UFJhbWhJ?=
 =?utf-8?B?aTU4c2xjV2ZxSHkyTmhscUp0eVRLOUJuK1RUSVp2NDZRUkFQa0l4OGM4Nlhl?=
 =?utf-8?B?NHZTbGRTaGEwdFN6TFh3MklhenM3ZnBXblNtU2xMc3ZidzRtVmcwTmF5L0RG?=
 =?utf-8?B?NnplNjZiS1p6V0U3Z3pKeHBiQm0zc3BMcGYzU2VQQUxrWkNJMVhqVFQrSXVa?=
 =?utf-8?B?M0tzMXlWM1h2ek5NQTBWWXFPV0JqMC93RGlWc1dGQVBVb2ZiQU1QeGdyV3lZ?=
 =?utf-8?B?ZG9iMGFlYnBTbURFVXJVcEpMelp2RmNHTFkxaUFodWlpVStUZ1NJalB2YnZT?=
 =?utf-8?B?WTlPWUp4QUF2Nm8yTE5PTFdQOFl0aDRKaUtvSzZFVDVxVUgvSGNheXJkOENp?=
 =?utf-8?B?RlZDYmF0L3VQVVIzTXpOMnNQak0raDNWeXpyWVdRRlc2ek1DNlhTV0tRQlZv?=
 =?utf-8?B?RWkveC82aXdJcXk5MnBOL3ZXMkxpTUZkUVBLQmxDa2s1Q2x5cjN6Q0pXdDRq?=
 =?utf-8?B?Y1MyczAzTkxwSEZ0bDZQbHZRcDF4bE1QeVpqTzhQanVOVTlPZ24vSjI3d25V?=
 =?utf-8?B?MGxPeGtDSW92MXJUdHNNUFUzdVEzVGlLZHJITDg1OXFUeEVsU0V5SFBtSHI0?=
 =?utf-8?B?cldWZHZmYlRwdFVQbHFiRUNDcTlrZDJwT3RuQUJWaGEwVjNxeWQ1OExCSHBj?=
 =?utf-8?B?c1dCbUg2QmlTenl2cHNDVFpnN1FMYUd6M2RpQ0lsaTRmekVqQldHd1I4ekk1?=
 =?utf-8?B?TUhRaVFaNnBjVmxvZUJQMEdSUzcyV2pHTmo0ZGkrd3FvMDJJM2gvV2xRQmZP?=
 =?utf-8?B?Y3hwWGwzWldBekh2c1ZMT2MxYlQvWkNlR29rbmtpMmFTYU4zWUwvS3dtaDAy?=
 =?utf-8?B?aG0wZkhNOFA0emNnSmFMSEdRNVV6N25vVURYckMrOVVvL21taHNZekxudFEr?=
 =?utf-8?B?UDdmTXViUm9rZzBKbXNDVEY0YzRFUGRFd2lDTzRRR0VzUDRiUEdFVWVXRTl6?=
 =?utf-8?B?aDVGZ2E4RUcvYlBaZ0J2MEtYQ0F5Y3lIUHRoU2M3UWFOdW8wbzlVU3MvaUpE?=
 =?utf-8?B?Z1AxMk1SS05hVmt4RkFCY2xDbkp3NlB6UkxXUURaQktBYkg2RjIycGg2UThr?=
 =?utf-8?B?K2hZREdFUnIwclBDT2g1MElpbVhZSVQwVE5adVJ0QlVGYUdDcnZrNnpPU016?=
 =?utf-8?B?K3YvbzN5V29EMTFGa3o0UDNhQklPdGVZb2tlM3Z6MUtSMXhkUzhHMWZreU9n?=
 =?utf-8?B?R0R6TnNudDVLdDM2ZEZsaEsxb0E3VWFUcVZnVW1IYnkzQ2wvS1NZV0ZjK2tP?=
 =?utf-8?B?eVlZTkVMb1FxZCtYUGN2OEUzeDJSQXc2N2NpNmZIbGFON3pSYm51a3M5ay85?=
 =?utf-8?Q?pkgo=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: 4278126c-be7e-4a04-86f8-08ddacb4ebee
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jun 2025 09:05:20.8585
 (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: mSgD1DZgEY0jNwYDInVELyVs7eZRr7btE81s2mTec0hQTfnGW5fLi3TLqdIw7nIO2DRV20VnYBglwRNZSKRwQA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR12MB6156

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVuZSAxMSwgMjAy
NSAxMToyMCBQTQ0KPiBUbzogUGVubnksIFpoZW5nIDxwZW5ueS56aGVuZ0BhbWQuY29tPg0KPiBD
YzogSHVhbmcsIFJheSA8UmF5Lkh1YW5nQGFtZC5jb20+OyB4ZW4tZGV2ZWxAbGlzdHMueGVucHJv
amVjdC5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSCB2NSAwMS8xOF0geGVuL3Btc3RhdDogZ3Vh
cmQgcGVyZi5zdGF0ZXNbXSBhY2Nlc3Mgd2l0aA0KPiBYRU5fUFhfSU5JVA0KPg0KPiBPbiAyNy4w
NS4yMDI1IDEwOjQ4LCBQZW5ueSBaaGVuZyB3cm90ZToNCj4gPiBBY2Nlc3NpbmcgdG8gcGVyZi5z
dGF0ZXNbXSBhcnJheSBzaGFsbCBub3QgYmUgb25seSBndWFyZGVkIHdpdGgNCj4gPiB1c2VyLWRl
ZmluZWQgaHlwZXJjYWxsIGlucHV0LCBzbyB3ZSBhZGQgWEVOX1BYX0lOSVQgY2hlY2sgdG8gZ2Fp
biBzYWZldHkuDQo+DQo+IFdoYXQgaXMgImd1YXJkZWQgd2l0aCB1c2VyLWRlZmluZWQgaHlwZXJj
YWxsIGlucHV0Ij8gQW5kIHdoYXQgc2FmZXR5IGFyZSB3ZQ0KPiBsYWNraW5nPw0KPg0KPiA+IC0t
LSBhL3hlbi9kcml2ZXJzL2FjcGkvcG1zdGF0LmMNCj4gPiArKysgYi94ZW4vZHJpdmVycy9hY3Bp
L3Btc3RhdC5jDQo+ID4gQEAgLTIyOCwxMCArMjI4LDEzIEBAIHN0YXRpYyBpbnQgZ2V0X2NwdWZy
ZXFfcGFyYShzdHJ1Y3QgeGVuX3N5c2N0bF9wbV9vcA0KPiAqb3ApDQo+ID4gICAgICByZXQgPSBj
b3B5X3RvX2d1ZXN0KG9wLT51LmdldF9wYXJhLmFmZmVjdGVkX2NwdXMsDQo+ID4gICAgICAgICAg
ICAgICAgICAgICAgICAgIGRhdGEsIG9wLT51LmdldF9wYXJhLmNwdV9udW0pOw0KPiA+DQo+ID4g
LSAgICBmb3IgKCBpID0gMDsgaSA8IG9wLT51LmdldF9wYXJhLmZyZXFfbnVtOyBpKysgKQ0KPiA+
IC0gICAgICAgIGRhdGFbaV0gPSBwbXB0LT5wZXJmLnN0YXRlc1tpXS5jb3JlX2ZyZXF1ZW5jeSAq
IDEwMDA7DQo+ID4gLSAgICByZXQgKz0gY29weV90b19ndWVzdChvcC0+dS5nZXRfcGFyYS5zY2Fs
aW5nX2F2YWlsYWJsZV9mcmVxdWVuY2llcywNCj4gPiAtICAgICAgICAgICAgICAgICAgICAgICAg
IGRhdGEsIG9wLT51LmdldF9wYXJhLmZyZXFfbnVtKTsNCj4gPiArICAgIGlmICggcG1wdC0+cGVy
Zi5pbml0ICYgWEVOX1BYX0lOSVQgKQ0KPiA+ICsgICAgew0KPiA+ICsgICAgICAgIGZvciAoIGkg
PSAwOyBpIDwgb3AtPnUuZ2V0X3BhcmEuZnJlcV9udW07IGkrKyApDQo+ID4gKyAgICAgICAgICAg
IGRhdGFbaV0gPSBwbXB0LT5wZXJmLnN0YXRlc1tpXS5jb3JlX2ZyZXF1ZW5jeSAqIDEwMDA7DQo+
ID4gKyAgICAgICAgcmV0ICs9IGNvcHlfdG9fZ3Vlc3Qob3AtPnUuZ2V0X3BhcmEuc2NhbGluZ19h
dmFpbGFibGVfZnJlcXVlbmNpZXMsDQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ZGF0YSwgb3AtPnUuZ2V0X3BhcmEuZnJlcV9udW0pOw0KPiA+ICsgICAgfQ0KPg0KPiBHb2luZyBm
cm9tIGp1c3QgdGhlIGNvZGUgY2hhbmdlOiBZb3Ugd2FudCB0byBhdm9pZCBjb3B5aW5nIG91dCBm
cmVxdWVuY3kgdmFsdWVzDQo+IHdoZW4gbm9uZSBoYXZlIGJlZW4gcmVwb3J0ZWQ/IEJ1dCB3aGVu
IG5vbmUgaGF2ZSBiZWVuIHJlcG9ydGVkLCBpc24ndCBwbXB0LQ0KPiA+cGVyZi5zdGF0ZV9jb3Vu
dCAoYWdhaW5zdCB3aGljaCBvcC0+dS5nZXRfcGFyYS5mcmVxX251bSB3YXMNCj4gdmFsaWRhdGVk
KSBzaW1wbHkgZ29pbmcgdG8gYmUgMD8gSWYgbm90LCBob3cgd291bGQgY2FsbGVycyBrbm93IHRo
YXQgbm8gZGF0YSB3YXMNCj4gaGFuZGVkIGJhY2sgdG8gdGhlbT8NCg0KSSBtYXkgbWlzdW5kZXJz
dGFuZCB3aGF0IHlvdSd2ZSBjb21tZW50ZWQgb24gdjQgcGF0Y2ggInRvb2xzL3hlbnBtOiBQcmlu
dCBDUFBDIHBhcmFtZXRlcnMgZm9yIGFtZC1jcHBjIGRyaXZlciIsIHF1b3RpbmcgdGhlIGRpc2N1
c3Npb24gdGhlcmUsDQoiDQpUaGlzIGxvb2tzIHF1ZXN0aW9uYWJsZSBhbGwgb24gaXRzIG93bi4g
V2hlcmUgaXMgaXQgdGhhdCAtPnBlcmYuc3RhdGVzIGFsbG9jYXRpb24NCmlzIGJlaW5nIGF2b2lk
ZWQ/IEkgZmlyc3QgdGhvdWdodCBpdCBtaWdodCBiZSBwYXRjaCAwNiB3aGljaCBpcyByZWxhdGVk
LCBidXQgdGhhdA0KZG9lc24ndCBsb29rIHRvIGJlIGl0LiBJbiBhbnkgZXZlbnQgZnVydGhlciBk
b3duIGZyb20gaGVyZSB0aGVyZSBpcw0KDQogICAgZm9yICggaSA9IDA7IGkgPCBvcC0+dS5nZXRf
cGFyYS5mcmVxX251bTsgaSsrICkNCiAgICAgICAgZGF0YVtpXSA9IHBtcHQtPnBlcmYuc3RhdGVz
W2ldLmNvcmVfZnJlcXVlbmN5ICogMTAwMDsNCg0KaS5lLiBhbiBhY2Nlc3MgdG8gdGhlIGFycmF5
IHNvbGVseSBiYXNlZCBvbiBoeXBlcmNhbGwgaW5wdXQuDQoiDQpJIHRob3VnaHQgd2Ugd2VyZSBp
bmRpY2F0aW5nIGEgc2NlbmFyaW8sIHVzZXIgYWNjaWRlbnRhbGx5IHdyaXRlcyB0aGUgIm9wLT51
LmdldF9wYXJhLmZyZXFfbnVtICIsIGFuZCBpdCBsZWFkcyB0byBhY2Nlc3Npbmcgb3V0LW9mLXJh
bmdlIGFycmF5IHNsb3QgaW4gQ1BQQyBtb2RlLiBUaGF0J3MgdGhlIHJlYXNvbiB3aHkgSSBhZGRl
ZCB0aGlzIGd1YXJkDQoNCkJ1aXQgYXMgeW91IHNhaWQgYXQgdGhlIHZlcnkgYmVnaW5uaW5nLCAg
b3AtPnUuZ2V0X3BhcmEuZnJlcV9udW0gaXMgdmFsaWRhdGVkIGFnYWluc3QgcG1wdC0+cGVyZi5z
dGF0ZV9jb3VudCwgc28gaWcgdGhlIGFib3ZlIHNjZW5hcmlvIHdpbGwgbm90IGhhcHBlbiwgSSds
bCBkZWxldGUgdGhpcyBjb21taXQuDQoNCj4NCj4gSmFuDQo=


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 09:15:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 09:15:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017087.1394058 (Exim 4.92)
	(envelope-from )
	id 1uR5wY-0004Ch-GL; Mon, 16 Jun 2025 09:15:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017087.1394058; Mon, 16 Jun 2025 09:15: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 1uR5wY-0004Ca-DV; Mon, 16 Jun 2025 09:15:54 +0000
Received: by outflank-mailman (input) for mailman id 1017087;
 Mon, 16 Jun 2025 09:15: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 1uR5wX-0004CU-TP
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 09:15:53 +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 7f886454-4a92-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 11:15:51 +0200 (CEST)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-6088d856c6eso7352386a12.0
 for ; Mon, 16 Jun 2025 02:15:51 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-adec897c397sm608227866b.167.2025.06.16.02.15.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Jun 2025 02:15:50 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7f886454-4a92-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750065351; x=1750670151; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=zakZW4TQ6czVjCAgC/J66dSaFBWhhBULmtTR8W6ffb4=;
        b=RNLMuLQGCFZ5qlgnXrdCCWdvxQM2PtfoA8HcQWirk71pK8zPhYr4cjgYtVHvV+BQk1
         5ZRLNWEYaWffSUGMt92fwPCpzf9V6OjJmpXmcByA2DltH8yJsBuA681qw6DbIIV5US/u
         +YO456nlzGuzRG2Ss1betQH+WOTzDkvvponruV9esY1C3yvIL7mydoV4s/SPtcea6ufg
         nI+s410LJ8yPEz2KMxCBzx7V8Eh/D3xwfj/a7fDhHoW/V+iLQPiwIHIdg5l0AMCTwCVr
         LN7Wyif6d10XSEhi6iqIFWMtH7o5znQDOpaCzXMkimY/wE6y+NfWxVDrVuGDzFJwb1ru
         iKjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750065351; x=1750670151;
        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=zakZW4TQ6czVjCAgC/J66dSaFBWhhBULmtTR8W6ffb4=;
        b=pxoRLT+8vqaIB7z8/1H2SIkbUU+Wu1zRt8NHalQZnttYB1G0CM9hzF0szO4TJEblm0
         YmvBHrKVLxOi3UTuZfD9/JJpod+yA3edN1x9YrV9264xnNlPJCZ+ChQsZd0dcbuGJg2I
         JJ1Zs0rJeUqiQc15e8PgrQT/Zta8PcDV9fg0OafNa6liBijhWLRe0RhZo9ZCe2vscotE
         x9gv4u2pdJ1fs1YXaKSDsHxKrYzlpCY3xEA9gW/n4BaXBUXDhh3PbrlbOlWXW9ZOHBZ9
         Z4Zz8jvzefX5AwEHLtiaEsuDptvbZDCVEAtHsRIPli9gLZceL5wR8EFv5Ua5k2Y4CMFj
         NkqA==
X-Forwarded-Encrypted: i=1; AJvYcCWNOG8Pkeo3d43SfEmEJDrYjKOUugLo6ywccX+oNrmI15BXDX/Obq8Uf+VpMvJhS3fC2YYCF09i+1c=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzlD9dPDZ+THOItCTfNE3jE4s1imvA8lfNUOJ5frRn0iCsvroiA
	WUZb1KGKGHkuBj454EvRC6qXhkV5YSFGGICNI0pef6mfty5MylKzMG2B3jzJ2VIcSw==
X-Gm-Gg: ASbGncviIOx6u8A+fmQKov5g7JB7YpgveqgQCBUvbFzECoAhhjzVNhZLJoCM2aJXeT1
	G4kkCq42ndbL2AmOihoNRM99pvX79aVVA25POdmDKt7O9eK5cciNlCWRBj26BelTzP09dYAunV6
	cXuZ9qCXh9A0lRaUFpzCnMOZgYoys5CmR/o/dNqtKlrHj82nBKBsEpWfv/QfS6fwAhmchve/mKf
	WCt4zfsKochjsRk2MUNN9RNzYW4A6WElQqQJXAOTW/QE8XKXLBlFxxFC44ZKlWtMMllIC50dMeY
	7UaKwml9Ndd0Vg7YWEZ1CqsGbd34Q/RWg567bu00YhT27dI6wSiBgYvmi5SrQjNsepv4bec7zmf
	/AgFngLB8fdLhj7IWKPQCR8czfgDPcflyHl6+7XyJ4KWgLSo=
X-Google-Smtp-Source: AGHT+IGeP7YdrEj/GzVMGc8LwA7MKUfDRO9xDdgl9D+d9wgz/mJYM7ESi0ud2XKGAU7fArSZn7pDeA==
X-Received: by 2002:a17:906:6a1b:b0:ad5:7234:e4a9 with SMTP id a640c23a62f3a-adfad54b256mr792891766b.28.1750065350914;
        Mon, 16 Jun 2025 02:15:50 -0700 (PDT)
Message-ID: 
Date: Mon, 16 Jun 2025 11:15:49 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 01/18] xen/pmstat: guard perf.states[] access with
 XEN_PX_INIT
To: "Penny, Zheng" 
Cc: "Huang, Ray" ,
 "xen-devel@lists.xenproject.org" 
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-2-Penny.Zheng@amd.com>
 <0d60d42f-d844-41b5-a8ca-bdfe7883d15b@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.06.2025 11:05, Penny, Zheng wrote:
> [Public]
> 
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Wednesday, June 11, 2025 11:20 PM
>> To: Penny, Zheng 
>> Cc: Huang, Ray ; xen-devel@lists.xenproject.org
>> Subject: Re: [PATCH v5 01/18] xen/pmstat: guard perf.states[] access with
>> XEN_PX_INIT
>>
>> On 27.05.2025 10:48, Penny Zheng wrote:
>>> Accessing to perf.states[] array shall not be only guarded with
>>> user-defined hypercall input, so we add XEN_PX_INIT check to gain safety.
>>
>> What is "guarded with user-defined hypercall input"? And what safety are we
>> lacking?
>>
>>> --- a/xen/drivers/acpi/pmstat.c
>>> +++ b/xen/drivers/acpi/pmstat.c
>>> @@ -228,10 +228,13 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op
>> *op)
>>>      ret = copy_to_guest(op->u.get_para.affected_cpus,
>>>                          data, op->u.get_para.cpu_num);
>>>
>>> -    for ( i = 0; i < op->u.get_para.freq_num; i++ )
>>> -        data[i] = pmpt->perf.states[i].core_frequency * 1000;
>>> -    ret += copy_to_guest(op->u.get_para.scaling_available_frequencies,
>>> -                         data, op->u.get_para.freq_num);
>>> +    if ( pmpt->perf.init & XEN_PX_INIT )
>>> +    {
>>> +        for ( i = 0; i < op->u.get_para.freq_num; i++ )
>>> +            data[i] = pmpt->perf.states[i].core_frequency * 1000;
>>> +        ret += copy_to_guest(op->u.get_para.scaling_available_frequencies,
>>> +                             data, op->u.get_para.freq_num);
>>> +    }
>>
>> Going from just the code change: You want to avoid copying out frequency values
>> when none have been reported? But when none have been reported, isn't pmpt-
>>> perf.state_count (against which op->u.get_para.freq_num was
>> validated) simply going to be 0? If not, how would callers know that no data was
>> handed back to them?
> 
> I may misunderstand what you've commented on v4 patch "tools/xenpm: Print CPPC parameters for amd-cppc driver", quoting the discussion there,
> "
> This looks questionable all on its own. Where is it that ->perf.states allocation
> is being avoided? I first thought it might be patch 06 which is related, but that
> doesn't look to be it. In any event further down from here there is
> 
>     for ( i = 0; i < op->u.get_para.freq_num; i++ )
>         data[i] = pmpt->perf.states[i].core_frequency * 1000;
> 
> i.e. an access to the array solely based on hypercall input.
> "
> I thought we were indicating a scenario, user accidentally writes the "op->u.get_para.freq_num ", and it leads to accessing out-of-range array slot in CPPC mode. That's the reason why I added this guard

Well, it's not an out-of-range access, but a NULL deref, but yes, the concern voiced
there is related. But that can't be done in an isolated patch, it makes sense only
together with the change to the if() that I did comment on. And even then if it is
guaranteed that perf.state_count is always 0 when perf.states is NULL, we'd be fine
without any change. Yet this latter aspect goes back to the question I had raised
there: "Where is it that ->perf.states allocation is being avoided?"

> Buit as you said at the very beginning,  op->u.get_para.freq_num is validated against pmpt->perf.state_count, so ig the above scenario will not happen, I'll delete this commit.

Not sure yet whether deleting is the right course of action.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 09:43:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 09:43:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017103.1394069 (Exim 4.92)
	(envelope-from )
	id 1uR6N7-0000dJ-Gy; Mon, 16 Jun 2025 09:43:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017103.1394069; Mon, 16 Jun 2025 09:43: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 1uR6N7-0000dC-Dc; Mon, 16 Jun 2025 09:43:21 +0000
Received: by outflank-mailman (input) for mailman id 1017103;
 Mon, 16 Jun 2025 09:43: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 1uR6N6-0000d6-A6
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 09:43:20 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on2062a.outbound.protection.outlook.com
 [2a01:111:f403:2415::62a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 549b691e-4a96-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 11:43:18 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 SN7PR12MB7201.namprd12.prod.outlook.com (2603:10b6:806:2a8::22) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.35; Mon, 16 Jun
 2025 09:43:15 +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.8835.027; Mon, 16 Jun 2025
 09:43: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: 549b691e-4a96-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=v8OEzSzKKTnQSWAfa7OLiFThhmWs8ioHVAQJi1vA0bjbWCxPHJpL7VZMi1+jBqFoyE2SueEl5/BZkFUHF1mNMSCjvSJc61ZJyiepwhiofZW7tIiN/YLtitExyGs1me6FmgiCAoS4k9g0KkxjMcTGcjhpgmxd2VZIqhFwABhB+S7hkIGxMp+hUYDfri38ylNQUnqw3dcKX5rkJmb0OxmkVMPqPfqsmpMDP8iEDmPBxUxvqD6+mkI/OG68wa0jKa3ZqhrmpNdgBDRLztoDsVEH/gKNdcCEjyrfty1g3Fu0RqNWsvNCHgjKey9+rcDj3mM6mcbImYozJE8hCclMMvpchg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=RVulP7Vi6An5GEs0rQDPdXKTKguq/7pkarZCmsj5ctM=;
 b=cO2dula6MuL3pjVkVoA2DEu7X2F8Tr7pKbXcgcvWb+QFT5F+W+UFqrxKL+9kqiJq5o95KRxaVGXhL7paTZkZathlLILaHEgtSbGjkEtGO9JjsIdlr5+FPHGsA7TxJxpWxBesQMQZbYLpeqHzUl1oo9nDHyg/KRBsHmihOZVk9yrRlOw6M+Ekc/K//byuMgjXDWBh7j5Fky63rHkBxYRh/rHW3sWOkqHkHpEEqYBTwckmUjObZELMbAH976IFmEzZzkB1HgLQR3sk1mU+glqcunwaW2EnvdFj0IamFNd05oflQhONAG1OOSYd0NTcgA1pgn4QILr5E9xeCAkyxhDVBQ==
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=RVulP7Vi6An5GEs0rQDPdXKTKguq/7pkarZCmsj5ctM=;
 b=ZqlsaEKx/6YaEtcz0wcfdVO3/a6gIbS3YYYmR6jqLfEZxMJaWfbIZmR2yfzrGVv4C2eME9UZkigT2gE7NtsBFQjoxxIyFcZkwYTXSGRDwcHO8y7zN+kjkd64Qs7UP9xbOS44x+4I2U+deUEO/otYllqZg+wDeHbiLGdWBxnQ2hA=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v5 03/18] xen/cpufreq: extract _PSD info from "struct
 xen_processor_performance"
Thread-Topic: [PATCH v5 03/18] xen/cpufreq: extract _PSD info from "struct
 xen_processor_performance"
Thread-Index: AQHbzuQ7tkLRAfE4aEeQu239amEhMrP+LqUAgAdzEsA=
Date: Mon, 16 Jun 2025 09:43:14 +0000
Message-ID:
 
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-4-Penny.Zheng@amd.com>
 <005a0e3a-dc8f-480f-8bb9-fd8eb164eb02@suse.com>
In-Reply-To: <005a0e3a-dc8f-480f-8bb9-fd8eb164eb02@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=True;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-06-16T09:43:06.0000000Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=3;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged
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_|SN7PR12MB7201:EE_
x-ms-office365-filtering-correlation-id: 9b390dde-b1c3-4ef4-78fc-08ddacba375a
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?RTFCdUlpT2k4dlI0Nk9SaXNIdUVIUk9CWENhdThxUE1FQVcvNFRQNGY1cWUv?=
 =?utf-8?B?cGxHVUlaQjlzNzJuSnQ1NjdJL0FhazJiY29SUHg4d2xiMkNWNmFvOGN1Y3NN?=
 =?utf-8?B?Z3JjK1V0RHZZQnVUeFovYW1zTWlkUE9NYUQrUVhRbERNQXBYZWtla2VRajl4?=
 =?utf-8?B?d0dlQURVKzRNczBBU292eTd5ZTl5dzRVQWlzRjJxMlRzUkFjREpFczZwbjRE?=
 =?utf-8?B?VlhVZ0QyUHdZV2FOa04xdGw2UDllUnJNK1BZQlNRcmlmb2kvYXBXLy9UcVRz?=
 =?utf-8?B?Ykw5bFBaSmF5UW9ZZEFXS1h2L1VCU3BIOEhCVC9pc05CeENxT1RsQ0NFQmts?=
 =?utf-8?B?Ui9ReWRSS2hTWjNVZGZMaFh2bHJtMGZZeDU0b25QZmg2Slg0MXJMcVNSU2N0?=
 =?utf-8?B?OWNnczVCR1YrQjc4TmMxWjRla1NuMWhobEpDVklXQkdBVXJ2dDFpdXIrb0VN?=
 =?utf-8?B?L0hVNFdiNkc2QXpqZDhjZkhzM1ZsNGhXczFGN2tneWU3T01VWjlUNkJWT01D?=
 =?utf-8?B?MU5vZ1IvSDNhSmNjZER0RGNIQVdKYkc3Q0pCYVhueXU1K3FJdzc5cnNFTVRN?=
 =?utf-8?B?cXB4eFFmWVY5aTNCeDFYcTM2OEJCbkg1U3Q1YmRKRkEzVkNucUREUThQTVpl?=
 =?utf-8?B?ZDBJRXFjZFg0a080ZytOM3FnajIvNi9EVzJiVVNJK0xHeENSN2N2WnFycE84?=
 =?utf-8?B?d2xDTnBEdzBjdDRBdkY1ZTR1eWZ3VjI2ckRvNTdya2h0ckdLcXNLbUJHNXhR?=
 =?utf-8?B?Q1NhcXRRdlVhOVBrdWpMS2NMN3JaRUtGc25MdXcrNWUxQnU3d0FUellXdXNn?=
 =?utf-8?B?Rndoc01KRUsyTGhHNTZwR24rdkI4bzdrTXZVSldPV29VdTdYQkdYUXJUdDNZ?=
 =?utf-8?B?R0h6TGdsalRiRXJyYXlYbGRkQkNqT1FFNzVmQUoxcXdTbFg5VnFHMHJydjZX?=
 =?utf-8?B?WFoyV3o0MnVNaFhnaTgrZ1pNYWpkRHMzZldJbTI1eWNpY1J5Q1pid3NONFc5?=
 =?utf-8?B?ZEttanpLMnI4cDlSb1dnWjRzckErZmJLWEc2ZjNzdVlXV3Nkdkc1L3ZBaHJM?=
 =?utf-8?B?SGNPRjhiYm1pWng4WnA4bEhyc3ZNY28wTzU5NFhRZkxFN25Ya1hackU3RXNW?=
 =?utf-8?B?b094cmVLUW1rL0FaeDc4QlY4K1MzOUxGanZuMlFtMkJwUG1jWmN5UFpQUVR6?=
 =?utf-8?B?TWNsa3NOQk5raisxNWFRWDBPQ28zQjFhMHR1ZmxPR2RVSjBNd0FwbjhRT2dL?=
 =?utf-8?B?SzcwZGQ2Wno2M0xvTjBGbDMrd2NwODZoYmpLKzNkL0lqckt1VWNhTENBQVd2?=
 =?utf-8?B?QUdMVkNKMGIwejAvUUJlcFRiby9obVpOQ3N5cWpKa2ppU1BBZTkrRmNhSVBZ?=
 =?utf-8?B?RTllc2U2TUh6a3BwelJ0T0RYT3Y2cW5neGxYaStyUXM4WldwTEU2eE9OSlF1?=
 =?utf-8?B?d01SV3dYZWlxYXJZenZJQjFjYTZJMjkrNjJmUHlYOXhpblVtdlJ4MERVQ2NX?=
 =?utf-8?B?R0lVVkZvS3dHUDhHcW0zS1FaT0Rram0vZ0o5VnhXUmZCa012RFJ6NDBKR2RT?=
 =?utf-8?B?UkEwVXFnUHJlT3duWUd4anhGQU1qMTgwaFpscVB5SlZtRjVHSnV4Mkk1b3hL?=
 =?utf-8?B?dDFYRWpqM3NmMHJxSGlqSUVCMmo4SUFSVU5uZU9FS0VHRndLSEdHQklFRmhV?=
 =?utf-8?B?TXJ3VVdmRlYvU3E3T282RC9yQmh3M3VUNldySXJ1ZnlxalFocTNScXJUdEkx?=
 =?utf-8?B?WGgwb3QzS2hOUFpuZFRCYS8vdXZpS3dyTXB2MjdKckluTjJObFBrU0hKVE1O?=
 =?utf-8?B?cWx0L3dlSysvdE90S0RlM0E5MDNTRXRSU0pUTGxJTkRwbUFQUHNuRGkxZnIv?=
 =?utf-8?B?clBwSGs1Z1c3aTY3b2tvQmI4aFppdkRMTFNaOTJUQ2FDcUNSTFVEM3dXNHV2?=
 =?utf-8?B?c0VXV3FKRWxNK01kbGxIa0ZXdmRHSTh1NXQxaDJlay8xSGpRS1VMWjY5NzZB?=
 =?utf-8?B?VmQzUGRNTkJRPT0=?=
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)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?dTY4STRFUkFOY1JTdDV0QzZFNnNWYmh2aG1kZHQvMXA1c2hUanVLUUNSVmxV?=
 =?utf-8?B?Z0w1Zk5XUW1OQVNWQUtNQ2NtZVA1OE5ybEEzZmpvK0RaQjJ5ckJ6anprNXFF?=
 =?utf-8?B?RXdkMkVhUVJpclB1ZWovYTBDVEJWVHZGeUthY0FqRWZKVkw3QkU1bE5pMmRC?=
 =?utf-8?B?MExmVmVyZzVHSkJLajlIQ3grUWsrQkp0ZEtPaml3eUt4OUtOa1U0OUE0OHFG?=
 =?utf-8?B?OU83dFBadXhvZWEyOFRhWGJmaHo1K2NZWFN4N3d3L1hvdDFTTzdUMTY4YUJa?=
 =?utf-8?B?YlpaUXVTSlU3VE9FUjJiWnVBVi9VSTdscCs4c0czbDcvdkhKK3AvU1UxbHk0?=
 =?utf-8?B?SUdjNmMrN29HTC9qM2M4WWc1T3doRlFLWlBlNlNIcmhwNENtTTZVM3FYZ3hN?=
 =?utf-8?B?enI1aHlpaTVKRHd1QnBzKzhxOEpqYW16UmcrZENORzhIV1N5Slh1M25WSlBD?=
 =?utf-8?B?QjNEekZLL0dyS0lYWjFpMGtwakRtQmsxZkVWUFJZZUhwN0tiOW1kcTJGSW9a?=
 =?utf-8?B?YUdQT3hGcWVXMTdJSnRIRlRCMDNuWVlCYUNPNHFwRVFrSkdza1pHaG1IczN5?=
 =?utf-8?B?WkhJM1FiWUdWVVhLMWJEdmFRUm5sT2xudm1iQ0hyQU5BeTdMRG96WVJqWTkv?=
 =?utf-8?B?a1VFaEREaVJUTk9SR1R0aEJXcVJwZGk2ZzJ5WFM4SWNuUUFTblBnUzdQRXdv?=
 =?utf-8?B?SVlPTEV1TFJyeW5TZzQ5ODJWY3hZZmxBcE9QMVZIMnl5QUExK3hJdVRQUkwy?=
 =?utf-8?B?UnJ1cUZ4VDlWWW0vMUZuR0JaeDVTVkRMTVZUdW9aK1dHQWVCSFBFWkxFcFFk?=
 =?utf-8?B?SDk2c2wzWHVrblV0M1RMUWVuYUgwam14RFpBU1BGTmJSejIxQ2l5VkhObzRk?=
 =?utf-8?B?cnZad1lsNFdGbk1QWm9halJvUVVnSExXQXdXWUQ1QjBHM0QzUTZ2bzJHRktZ?=
 =?utf-8?B?aVV5WTdVK1dmUjZUZ3Bnbyt4MWZOVDdBSlZWZXQxRlpQeE9iOWUyTlczbWs4?=
 =?utf-8?B?ZEZRdkU4NllrUWtJLzEyQTZlN2pJbFlJQ25NVDZJMHcxUTN0UGJrK2VpT3hQ?=
 =?utf-8?B?QjN0L1VzbkxiTktBQTlPRFkvQjRHUXNKUERWczFNdTJwLzlRRDhIcUZjS09N?=
 =?utf-8?B?bTJ1eVVBV0tGZktRdEF3bkxQVnJFTHpiVzg1K1pZcTI5L1dVUDVWcVhFbTQ4?=
 =?utf-8?B?MEhtUVpjVEN4b3NFa21uRmF3ZmduUWpPcDJkWmhhT0Q4bi9GMTJ3akpIRW1M?=
 =?utf-8?B?Ui9qLytqR09Qb0ltVUNaRllvdTBUZjk0NzBZeTZSQ2QwQlVRS1RwQWJ5WG0v?=
 =?utf-8?B?Z2RTUW85ampNSWp2YTNyTlQ5SEtFOUFTUjlXa21TM0xta3dCbzMxaHFNZWZY?=
 =?utf-8?B?THdNbCtQRGxSSFpJbWdWOXVMZWFPZ3ZtVWFJQU1OdWJJeFV5dDdzMjFJbk03?=
 =?utf-8?B?Q2RncUlEQnN0cG1zZSt5bk5vTmdQT1FmdEhFTVRxdHFzcmpOMmJRYk1DQXlv?=
 =?utf-8?B?Q1VqVDJnOHBGZitxWHhDUDNXZ1VKRG1wVXlpT0hlNWNuZ1Ryd0NPR25laFRa?=
 =?utf-8?B?UHMwVTRmZVdGeEYySXM1WWltaDc1NStYczNybFYySko4V3dlZDVyRTVFbTMx?=
 =?utf-8?B?M25UU0VwRlQ3RzBCS0ZSb2FuNSs4VzRkWGFzaVdOc3dNRmRLOWFMb3I0TEVE?=
 =?utf-8?B?d285S2xYS05MZjFrWE1zbUxYNVBZQkdlMTlwT2pKamNFTHh0ay9vVnBlY2Jy?=
 =?utf-8?B?dXdZQjQwd2p0dTQrWlhZdnhzVEp4eDZjYmh1ZlkvUlhDWm9yTGFlM0JZenh5?=
 =?utf-8?B?QnZYWW1Za0UzVGwyMTlpQmcwcTJIdHhkQ1dxZEQ2WHRhK2ZTRXV2QjMwTEEx?=
 =?utf-8?B?R20rbkJ2Wk9OTjRmVGVNeDkxUTdlQjZENGxEaGpqVUpKcy9vRkgxSFhNZ3d0?=
 =?utf-8?B?eXQrR2xoRGN3bXlQRVI5VEVVY1l5d2pydUEzbjhjbEowREw1c1c1Y091SENY?=
 =?utf-8?B?OWhwZklXaFpFY1hCUFV1VUI1bmlSSTE2UmtqQ0VtRUl0dHg2RTFaR0NaTlZx?=
 =?utf-8?B?SnlVSkczZzd4UHMxK2dLRkpYbTVmbnpOR3N3VXNROGdOTGQyL3JBb3IxdUc4?=
 =?utf-8?Q?yUYg=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: 9b390dde-b1c3-4ef4-78fc-08ddacba375a
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jun 2025 09:43:14.8904
 (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: slhOrH2WkH15kZgPBSpoiY8mzqq+2zY/qV7GEmzkgIvr06PKuRA4019ZRTxNMgXjRpRSCvF6wodidgVINKUh0g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7201

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVuZSAxMSwgMjAy
NSAxMTozNCBQTQ0KPiBUbzogUGVubnksIFpoZW5nIDxwZW5ueS56aGVuZ0BhbWQuY29tPg0KPiBD
YzogSHVhbmcsIFJheSA8UmF5Lkh1YW5nQGFtZC5jb20+OyB4ZW4tZGV2ZWxAbGlzdHMueGVucHJv
amVjdC5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSCB2NSAwMy8xOF0geGVuL2NwdWZyZXE6IGV4
dHJhY3QgX1BTRCBpbmZvIGZyb20gInN0cnVjdA0KPiB4ZW5fcHJvY2Vzc29yX3BlcmZvcm1hbmNl
Ig0KPg0KPiBPbiAyNy4wNS4yMDI1IDEwOjQ4LCBQZW5ueSBaaGVuZyB3cm90ZToNCj4gPiBAQCAt
NTQ1LDE0ICs1OTcsOSBAQCBpbnQgc2V0X3B4X3BtaW5mbyh1aW50MzJfdCBhY3BpX2lkLCBzdHJ1
Y3QNCj4gPiB4ZW5fcHJvY2Vzc29yX3BlcmZvcm1hbmNlICpwZXJmKQ0KPiA+DQo+ID4gICAgICBp
ZiAoIHBlcmYtPmZsYWdzICYgWEVOX1BYX1BTRCApDQo+ID4gICAgICB7DQo+ID4gLSAgICAgICAg
LyogY2hlY2sgZG9tYWluIGNvb3JkaW5hdGlvbiAqLw0KPiA+IC0gICAgICAgIGlmICggcGVyZi0+
c2hhcmVkX3R5cGUgIT0gQ1BVRlJFUV9TSEFSRURfVFlQRV9BTEwgJiYNCj4gPiAtICAgICAgICAg
ICAgIHBlcmYtPnNoYXJlZF90eXBlICE9IENQVUZSRVFfU0hBUkVEX1RZUEVfQU5ZICYmDQo+ID4g
LSAgICAgICAgICAgICBwZXJmLT5zaGFyZWRfdHlwZSAhPSBDUFVGUkVRX1NIQVJFRF9UWVBFX0hX
ICkNCj4gPiAtICAgICAgICB7DQo+ID4gLSAgICAgICAgICAgIHJldCA9IC1FSU5WQUw7DQo+ID4g
KyAgICAgICAgcmV0ID0gY2hlY2tfcHNkX3BtaW5mbyhwZXJmLT5zaGFyZWRfdHlwZSk7DQo+ID4g
KyAgICAgICAgaWYgKCByZXQgKQ0KPiA+ICAgICAgICAgICAgICBnb3RvIG91dDsNCj4gPiAtICAg
ICAgICB9DQo+ID4NCj4gPiAgICAgICAgICBweHB0LT5zaGFyZWRfdHlwZSA9IHBlcmYtPnNoYXJl
ZF90eXBlOw0KPiA+ICAgICAgICAgIG1lbWNweSgmcHhwdC0+ZG9tYWluX2luZm8sICZwZXJmLT5k
b21haW5faW5mbywNCj4NCj4gLi4uIHRoZSBuZWVkIGZvciB0aGlzIGNoYW5nZS4gQW5kIGV2ZW4g
aWYgdGhlcmUgaXMgYSBuZWVkLCBhIGZvbGxvdy1vbiBxdWVzdGlvbiB3b3VsZA0KPiBiZSBob3cg
dGhpcyByZWxhdGVzIHRvIHRoZSBzdWJqZWN0IG9mIHRoaXMgcGF0Y2guDQo+DQoNCkkgZXh0cmFj
dGVkIHRoaXMgc25pcHBldCBvdXQgZm9yIHNoYXJpbmcgdGhlIHNhbWUgY2hlY2tpbmcgbG9naWMg
Ym90aCBpbiBQeCBhbmQgbGF0ZXIgQ1BQQy4gVGhleSBib3RoIG5lZWQgX1BTRCBpbmZvDQpJIGNv
dWxkIGNoYW5nZSB0aXRsZSB0byAieGVuL2NwdWZyZXE6IG1ha2UgX1BTRCBpbmZvIGNvbW1vbiIg
YW5kIGFsc28gYWRkIGRlc2NyaXB0aW9uIGluIGNvbW1pdCBtZXNzYWdlIGZvcg0KaW50cm9kdWNp
bmcgY2hlY2tfcHNkX3BtaW5mbygpDQoNCj4gSmFuDQo=


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 09:51:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 09:51:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017110.1394078 (Exim 4.92)
	(envelope-from )
	id 1uR6V5-0002Ml-9F; Mon, 16 Jun 2025 09:51:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017110.1394078; Mon, 16 Jun 2025 09:51: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 1uR6V5-0002Me-6i; Mon, 16 Jun 2025 09:51:35 +0000
Received: by outflank-mailman (input) for mailman id 1017110;
 Mon, 16 Jun 2025 09:51: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 1uR6V3-0002MY-LL
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 09:51:33 +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 7aeeb459-4a97-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 11:51:31 +0200 (CEST)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-608acb0a27fso5106809a12.0
 for ; Mon, 16 Jun 2025 02:51:31 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-608b4a5b6a5sm6018466a12.40.2025.06.16.02.51.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Jun 2025 02:51:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7aeeb459-4a97-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750067491; x=1750672291; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=2prvmEzDSdVFicN8cGuHMukB6VrVtIiT2hWxH4ORT+c=;
        b=CWA7iSv4I3/aoW7deqakm/Lq7BFMZJL0vOUZYs7vErI0+VWy1w7d0iCnmQkMKS4IPz
         qeLLacNZNzq2pIgucGrE8t8b05Mu0oXvVMDWDfBWffD+k5YlbjqaEDr2xQ+dEbKJEgw7
         us9vRCMuZsb6UtiaG0G5y9Yv7lrKSdZXAD+jTJ+70DHAdERGOyLy5NQF6iPATQh0NkMl
         q1uTiDz0SSA0dx3O6p7Q1Vw1b82kIVz08Kn0OqZ5PAotoi55AIrnF3JXEGePXz8mpTm0
         E0Q0Uj2m5S3vc8dXMI6GnatTppUnlKnynxDjRQCmc0TWgzfUr62Tf1an6KYKq7C1njOY
         56og==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750067491; x=1750672291;
        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=2prvmEzDSdVFicN8cGuHMukB6VrVtIiT2hWxH4ORT+c=;
        b=etrFUfgWv3L44LfYd0+7HBOQPsvjJN+JlGPl3oomMs3ZVQwYFaJxHFUyfrDD1+Um1W
         FLwhMJKG6+PvHf60H19yU+27kw/zv+grlQBY2iHwncHRgxqT5M+L7mBOizCkHJP+u1VK
         YK9XZhRcHViQdkcAN/OKWUM3v8HmiF+4f2seyBeZo+IG5+5ImkYdBq4X/3DUX7C7KmE/
         6RcO45oImp5zTUszYLLXaghxtFfJlysX1MnjBXitXtKNmVgNXTt1gZkBifNwIhS0UmjL
         fCVz1qheibzLA7f8egyEZJNtLZs0sJyWR9zizT6/0tizpC2asW1SM0xd8glMLElu2XqP
         D0DQ==
X-Forwarded-Encrypted: i=1; AJvYcCXNR3AcbJCGF14TaaU0kKFD0bMOZs4kuDD1FibMMvk/Dm1fUkw+ympVTfP8nuWLfC0Z4YkSTQ7dFPk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyGea9jRTq6TunpFeAjjBvVGRYgAaMi8FyNP3auH7cGgRVyc0hh
	3UT/upYlYh40MBtbsNEDxOiHGBxn6bCZJSCRFjOMHbyaXdkoVt3YeeEFmxl0JJiZLw==
X-Gm-Gg: ASbGnctRNy3HFi8xDAvGJWYomqZnLpK10D4/rYJisJHXuHIdvDxsgF0ClRd2rDTGom6
	a+jf48f7m1KhSyaglQGYR9GHrDe8/rdMykqY2a3k+ogM9wpf9CRbrluwegufmN+M2Sd+2OWSP8X
	pVPi8nogxXQqWD9PnjqnzfLlsilq4RDHvHY254HuQLoPtXcxqQH5oDZ9x67wc9llK4QGGHGazQU
	B3P637uisgawGkhefKzy5+I0wgJ9mT/Ww/qMeXrpS9BsMprACc6lBCTrgo7PuGk+T0YOvdzWlmc
	E9BL3Dx7JopISGaN0OZAtzHijIzIYftmCxXhaVSx0hihw5dsqVecDrN327m5XhRbB2UOCEcYtC7
	/QhN0CWKhBQ4IUAJPTqGshaORUrdEKKiGt51vTFxKnM15+yY=
X-Google-Smtp-Source: AGHT+IE2Xf7vLQ6JMPRRw1icKwx35PSfmZIhM4IKXcJOjXspdYFdEOxXVnGNKIXrUZYHwRoGSuaLgQ==
X-Received: by 2002:a05:6402:d0b:b0:607:3344:6ef1 with SMTP id 4fb4d7f45d1cf-608d0979c1emr6483732a12.29.1750067490598;
        Mon, 16 Jun 2025 02:51:30 -0700 (PDT)
Message-ID: <824a8aa5-c603-47e8-8688-a324152329a9@suse.com>
Date: Mon, 16 Jun 2025 11:51:29 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 03/18] xen/cpufreq: extract _PSD info from "struct
 xen_processor_performance"
To: "Penny, Zheng" 
Cc: "Huang, Ray" ,
 "xen-devel@lists.xenproject.org" 
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-4-Penny.Zheng@amd.com>
 <005a0e3a-dc8f-480f-8bb9-fd8eb164eb02@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.06.2025 11:43, Penny, Zheng wrote:
> [Public]
> 
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Wednesday, June 11, 2025 11:34 PM
>> To: Penny, Zheng 
>> Cc: Huang, Ray ; xen-devel@lists.xenproject.org
>> Subject: Re: [PATCH v5 03/18] xen/cpufreq: extract _PSD info from "struct
>> xen_processor_performance"
>>
>> On 27.05.2025 10:48, Penny Zheng wrote:
>>> @@ -545,14 +597,9 @@ int set_px_pminfo(uint32_t acpi_id, struct
>>> xen_processor_performance *perf)
>>>
>>>      if ( perf->flags & XEN_PX_PSD )
>>>      {
>>> -        /* check domain coordination */
>>> -        if ( perf->shared_type != CPUFREQ_SHARED_TYPE_ALL &&
>>> -             perf->shared_type != CPUFREQ_SHARED_TYPE_ANY &&
>>> -             perf->shared_type != CPUFREQ_SHARED_TYPE_HW )
>>> -        {
>>> -            ret = -EINVAL;
>>> +        ret = check_psd_pminfo(perf->shared_type);
>>> +        if ( ret )
>>>              goto out;
>>> -        }
>>>
>>>          pxpt->shared_type = perf->shared_type;
>>>          memcpy(&pxpt->domain_info, &perf->domain_info,
>>
>> ... the need for this change. And even if there is a need, a follow-on question would
>> be how this relates to the subject of this patch.
> 
> I extracted this snippet out for sharing the same checking logic both in Px and later CPPC. They both need _PSD info

Right, and that (iirc) becomes visible later in the series. But it needs saying
here. As it stands the description talks of only get_psd_info() right now. And
the change above is also unrelated to the "extract" mentioned in the title.

> I could change title to "xen/cpufreq: make _PSD info common" and also add description in commit message for
> introducing check_psd_pminfo()

The title was probably fine; it's the description which was lacking. In fact
I'd deem "make ... common" misleading when there's no 2nd user (yet).

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 10:38:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 10:38:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017129.1394088 (Exim 4.92)
	(envelope-from )
	id 1uR7EF-0007ts-PM; Mon, 16 Jun 2025 10:38:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017129.1394088; Mon, 16 Jun 2025 10: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 1uR7EF-0007tl-Mf; Mon, 16 Jun 2025 10:38:15 +0000
Received: by outflank-mailman (input) for mailman id 1017129;
 Mon, 16 Jun 2025 10:38: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 1uR7ED-0007tf-Mc
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 10:38:13 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on2060d.outbound.protection.outlook.com
 [2a01:111:f403:2417::60d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fe1a31c7-4a9d-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 12:38:09 +0200 (CEST)
Received: from MN2PR16CA0009.namprd16.prod.outlook.com (2603:10b6:208:134::22)
 by SN7PR12MB8789.namprd12.prod.outlook.com (2603:10b6:806:34b::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Mon, 16 Jun
 2025 10:38:03 +0000
Received: from BL02EPF0002992B.namprd02.prod.outlook.com
 (2603:10b6:208:134:cafe::13) by MN2PR16CA0009.outlook.office365.com
 (2603:10b6:208:134::22) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Mon,
 16 Jun 2025 10:38:03 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL02EPF0002992B.mail.protection.outlook.com (10.167.249.56) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Mon, 16 Jun 2025 10:38:03 +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 Jun
 2025 05:38:01 -0500
Received: from [172.26.5.4] (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 Jun 2025 05:38:00 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fe1a31c7-4a9d-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=VeYxcrcTqC4Afuxzj1xH+0eNLocxVikKvs52YVChTSsu2BP22umBs8Fz2AJcwcl/RK4zw3gTDKGY/1GO6nZi1Da59PjwvIv+IagW6sqW61Vuck6g7HglcEx9D8MDvetOkiXlC7SvjVPok//eeraSrlILexNxTpBktQf+I7zxMQX50AM9wvT6KmEcMvxZzKCt6m9Smy6cuhthwAwzofpn8Vs4BdpoXbORPYN5WO3G1+uTLtqkBnJlp/DznoQ7C2WGbcuu9e+UAtntOm0fVArzc0ZAoLbPg/A0268mbxafPJl5qLDkgStv/L12E5jKAQ/ayuaj9iATZN+S/N1hmSS2VQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=7EmsksXGREpSy7vy4sYjcDMmvpG7ntID6tOBSgLkHf8=;
 b=SUxaLuyqYMNL0Oa3trWjozDa1wtivzbmsmpl6YSHTDE+hKm5vJjhTAR+VK08xOk1kOCmQ1EGjaTnw43lIkwvABmYlJf0C051KkqaCsBhMP65jS7jSw+/hlzI3Z2/DV75ZBujcx8usJ/RfMJxthDZnR7cDPK6/LYibd5J2zQP5oBXnaxyPFRzc/y9zZHxIyirhUZ4jC1vD4j1mKi7pwu/ZXNMPZvw4Cari2OUsvqUlkJfIZb5Wc1O00DGJs+k5/A4gOGfrG0YvZI+MgV4B7gpIvfI8uR53xFLA3nYqDaaNlTZzl43aNvFG9bqkk15ob6wDNKl5t0qoMHVy6bu8d2t3g==
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=7EmsksXGREpSy7vy4sYjcDMmvpG7ntID6tOBSgLkHf8=;
 b=kyvR4LTuLgArwPtVj9rWgHlwnE3L7m/8O/qbVMzd0spjZHsGVC9mBd8qN8LeTL8aXMmIYifa2dWbyGuVhso/pMijP4Ht69Xl7yztq230ynEYnE0pvUDIxyRmD+rLVTYLxPAYzPz/NVacoUYkfA6c63v+LGzm23LnBBqJ6c0Pbpo=
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: <2e0627fa-35b8-4d3d-a3bc-338f9f7ed61b@amd.com>
Date: Mon, 16 Jun 2025 06:37:55 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v8] xen/arm: pci: introduce PCI_PASSTHROUGH Kconfig option
To: Jan Beulich 
CC: Rahul Singh , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , Andrew Cooper
	, Anthony PERARD ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini
	, 
References: <20250613154847.317979-1-stewart.hildebrand@amd.com>
 <3ecf10e5-5df7-4348-85a1-b8eecb940bf8@suse.com>
Content-Language: en-US
From: Stewart Hildebrand 
In-Reply-To: <3ecf10e5-5df7-4348-85a1-b8eecb940bf8@suse.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB04.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL02EPF0002992B:EE_|SN7PR12MB8789:EE_
X-MS-Office365-Filtering-Correlation-Id: 211d4e9a-3594-423d-c706-08ddacc1df47
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|7416014|376014|82310400026|36860700013|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?UjlPMUV1Q0ZnQ2NnMEk4OXJUSDhkM0N3eTRWaWtVSmVhMHFTSDBsZnpqdkRZ?=
 =?utf-8?B?NjBhRzY2RFBoR25zTkVRSjcvdFRycWpHZDBpN0NVOXRMbkswSFdOZ3VpNVdN?=
 =?utf-8?B?WDQzckV1dTl5UHhRa3V3WVhoSWw4eTVKbENxNUVpQUZsSmxsM0phR2FsMEo1?=
 =?utf-8?B?eXliZUFVZjY5ZDJKRXZvNStURlcyUUNrY3BYcFBQdnJvaXFSL2pNdVAyaE0w?=
 =?utf-8?B?eFFFbHcvSHozdk1ndVJSdkNDK2RPUExvZUhVNnVNUlowNXcrSEtDcEVBYUlC?=
 =?utf-8?B?RUhSemZsL2gzSGVscVFJcW0wN05qSHZrbW1LTWNCVlpxdnZ5aEkraURxUWQ3?=
 =?utf-8?B?TlMzZDJkTEpHSUFQUDFNZGE2SDZhdVFsaXRqcktKMW5ybnFKVmRqRE8xTWFF?=
 =?utf-8?B?VXZHcFpBdlh5OUNtRnppQVRtOEJja3VTaTgvdXFsYUpobGcybndLVTBlK2hC?=
 =?utf-8?B?MGhwTmVkczNOOVVVbTNRY3NmV1BtbUxrSVR2aWZGWjFPSStTY3VGM0JMZ1A2?=
 =?utf-8?B?ekhBNTlLWklhb1gxNFZ5ME5sT3ZkSUltUU9WeGRFaXFQSW9jdG5lbEVqT3B0?=
 =?utf-8?B?TmNZdDRPL3RMYmdjdEpvNVFKVzZxeStkN1dQOFR0bDgyMUVPeXlhQ0JuVXJW?=
 =?utf-8?B?YWMvYTlJTHlQeG44Qmhpd1pIZExjSG5GeVBMVlNITGt3dnpTMUhvMHpHb0ZH?=
 =?utf-8?B?Y2hKcEFnL0N6UW5icWRrNFRDK3lOOERmaVhPUmZMakJNSFh3WW85SU1TN2c3?=
 =?utf-8?B?MEptVTBEd0lMNDVhaFhtd2VOcldETnRWOUd0cEJIdEhKMjkxK1U2YmdjM2Zn?=
 =?utf-8?B?T0dSN05lRnpKamdjaW56UkFFbGRJL3ZFdmV4clVzSkhRNnpXSnlFQzR4NVFY?=
 =?utf-8?B?a3hjVHArZG1obnY0VW9ZdVY2c0pPOXUyVkZ6d3JYSThHTFlDT0ZMcC9BS1l5?=
 =?utf-8?B?MjlWY2dzZjc3V05JckVYK2NhWU4zVk0vQ25qMkN2c1BRNnNqa2U4L1ZzL2ZC?=
 =?utf-8?B?QTFiclhOYlhzY0xlWXBzdnc0UktNVXNETU0ydkpTZzU4ZmZISFBpb0NOV3p6?=
 =?utf-8?B?eGd2d1p5ditaTisxVGFuSmxFSEVvcVQ2bmRLNEQrbm0wanFBOSs3Z1FtRmZn?=
 =?utf-8?B?cGF4YjZxMlZHdkhRdVA2TmplTHpSVm5iZmJqaU5jQzFPTzJPTXU2VW10V1I1?=
 =?utf-8?B?RjVyS1FwMnlIelNKOGl0UG1NM2hGSFJ0MGFKQ1gzdUVoWHpmT1BPdTluMnhB?=
 =?utf-8?B?QjhDbXRBclNSaHFRa0J2VU4wQnFzNzJadTlkTjNUSVJyd3NpOVlodTdCRFlm?=
 =?utf-8?B?N1U1L0NSUmxqcW53a016RXVXK1VpdVJwS0lTcVhITEVMUFU1TitZRjJHcFNk?=
 =?utf-8?B?TGgzTS9hSk1uWjNCV1owMWh0MFp5amFNQUdEdjJOajJVbERaSWtIRFRFeDFH?=
 =?utf-8?B?ME9MZVVFMEpQanpkZkNzTVlmaUhCYW01cW0zUVVlTzlSYUkzRzI0aW4rQWdj?=
 =?utf-8?B?S3dHWHA0UmwzZG9vN2piZ2lBdFYzaXBlWWRVajN1MmJjS1pyeUVsSWVrZlRX?=
 =?utf-8?B?YmZocUtINi84SFdVZnA4MTlhN0c2SDI1SHpCdnlxV205QlBYaUg1T3hZTUlF?=
 =?utf-8?B?Y0syOVlVREtZQVNseGJLb2Q5eHBKekdnRU9YSWliZjgyNk1ZaW1CVVZzd1M5?=
 =?utf-8?B?b0loN2JsaWdrdnUrTjJWa3BBSmdhVStldTlpM3pkZEJnMk5oTzlobVBOY0FP?=
 =?utf-8?B?bHhreExIKy9NQmJmVUlnVWwrUXVIbEpyMm5oZmhpVGxuREkyaXZMY2RUTnpW?=
 =?utf-8?B?UDk4L1hnamlSd1VEaUVOOVBuV3FmS0hlc3Y2aEdrdkN1aHN5ZkFjV0NtaE00?=
 =?utf-8?B?WXlVV1RvQnNPeTMrNXVKY1VTZDc3dkxmM254YXA1ZzcrUVA0QWRGK291Mmc2?=
 =?utf-8?B?cmFVZVVqWnBQYitvUkpURnViY1hCenl5VmNJcHIybXJkZkVaeHZYbkJLOHVv?=
 =?utf-8?B?TDBWSGU0ZnIycGFUVkMrQjNnWUJVa0pmTjNPVmdQT2VpdFdQUUllMFEzZ05P?=
 =?utf-8?Q?THAG7U?=
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);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jun 2025 10:38:03.0732
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 211d4e9a-3594-423d-c706-08ddacc1df47
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:
	BL02EPF0002992B.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB8789

On 6/16/25 02:42, Jan Beulich wrote:
> On 13.06.2025 17:17, Stewart Hildebrand wrote:
>> --- a/xen/arch/arm/Kconfig
>> +++ b/xen/arch/arm/Kconfig
>> @@ -8,6 +8,8 @@ config ARM_64
>>  	depends on !ARM_32
>>  	select 64BIT
>>  	select HAS_FAST_MULTIPLY
>> +	select HAS_VPCI_GUEST_SUPPORT if PCI_PASSTHROUGH
>> +	select HAS_PASSTHROUGH if PCI_PASSTHROUGH
> 
> Seeing this, I like this as little as I liked ...
> 
>> @@ -258,6 +260,12 @@ config PARTIAL_EMULATION
>>  
>>  source "arch/arm/firmware/Kconfig"
>>  
>> +config PCI_PASSTHROUGH
>> +	bool "PCI passthrough" if EXPERT
>> +	depends on ARM_64
> 
> ... the form with the select-s put here. I'll (obviously) leave it to the
> Arm maintainers to judge, but my recommendation would be to simply drop
> this patch. As per the description it's merely "make it easier ...",
> which imo doesn't warrant such an abuse of HAS_*.

"easier" was a poor choice of word. "possible" is more accurate. This
patch addresses a real issue: currently the PCI and vPCI bits can't be
built for Arm, allowing build issues to go unnoticed. E.g. see
4ce671963eb1 ("xen/arm: fix build with HAS_PCI").


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 10:38:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 10:38:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017131.1394098 (Exim 4.92)
	(envelope-from )
	id 1uR7ER-0008Aj-1o; Mon, 16 Jun 2025 10:38:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017131.1394098; Mon, 16 Jun 2025 10: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 1uR7EQ-0008Ac-Us; Mon, 16 Jun 2025 10:38:26 +0000
Received: by outflank-mailman (input) for mailman id 1017131;
 Mon, 16 Jun 2025 10: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 1uR7EQ-0007tf-3o
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 10:38:26 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 06e16277-4a9e-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 12:38:23 +0200 (CEST)
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 20AF6150C;
 Mon, 16 Jun 2025 03:38:01 -0700 (PDT)
Received: from PWQ0QT7DJ1 (unknown [10.57.64.69])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5303E3F58B;
 Mon, 16 Jun 2025 03:38:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 06e16277-4a9e-11f0-a309-13f23c93f187
Date: Mon, 16 Jun 2025 11:38:19 +0100
From: Hari Limaye 
To: Ayan Kumar Halder 
Cc: xen-devel@lists.xenproject.org, 
	Stefano Stabellini , Julien Grall , 
	Bertrand Marquis , Michal Orzel , 
	Volodymyr Babchuk 
Subject: Re: [PATCH v3 5/6] arm/mpu: Define arm32 system registers
Message-ID: 
References: <20250611143544.3453532-1-ayan.kumar.halder@amd.com>
 <20250611143544.3453532-6-ayan.kumar.halder@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250611143544.3453532-6-ayan.kumar.halder@amd.com>

Hi Ayan,

I checked the register definitions for HPR{B,L}AR against the Arm
Architecture Reference Manual Supplement for the Armv8-R AArch32
architecture profile (ARM DDI 0568A.c), specifically sections E2.2.3 and
E2.2.6, and everything looks correct to me.

On Wed, Jun 11, 2025 at 03:35:43PM +0000, Ayan Kumar Halder wrote:
> Fix the definition for HPRLAR.
> Define the base/limit address registers to access the first 32 protection
> regions.
> 
> Signed-off-by: Ayan Kumar Halder 
> ---

Reviewed-by: Hari Limaye 

Many thanks,
Hari


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 11:07:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 11:07:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017142.1394109 (Exim 4.92)
	(envelope-from )
	id 1uR7gj-0003rt-4L; Mon, 16 Jun 2025 11:07:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017142.1394109; Mon, 16 Jun 2025 11:07: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 1uR7gj-0003rm-0K; Mon, 16 Jun 2025 11:07:41 +0000
Received: by outflank-mailman (input) for mailman id 1017142;
 Mon, 16 Jun 2025 11:07: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 1uR7gh-0003rg-JV
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 11:07:39 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on2060d.outbound.protection.outlook.com
 [2a01:111:f403:2416::60d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1c41dc1b-4aa2-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 13:07:38 +0200 (CEST)
Received: from CH3P221CA0003.NAMP221.PROD.OUTLOOK.COM (2603:10b6:610:1e7::14)
 by BN7PPF862C85B20.namprd12.prod.outlook.com
 (2603:10b6:40f:fc02::6d7) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8678.29; Mon, 16 Jun
 2025 11:07:33 +0000
Received: from DS3PEPF000099E0.namprd04.prod.outlook.com
 (2603:10b6:610:1e7:cafe::e9) by CH3P221CA0003.outlook.office365.com
 (2603:10b6:610:1e7::14) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.35 via Frontend Transport; Mon,
 16 Jun 2025 11:07:34 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 DS3PEPF000099E0.mail.protection.outlook.com (10.167.17.203) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Mon, 16 Jun 2025 11:07:33 +0000
Received: from localhost (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, 16 Jun
 2025 06:07:31 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1c41dc1b-4aa2-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=RHbHfxGo22x9DZXgmAOSYIxV0hR0+qYqVrc1EJ5HiXH/xsyKYxWdMBltnRKd2EX7tzEPBuX7lWWW/iF+QSIUDN3ewmGoD4YI1OQo7emxCEfbSxScMxoBre5swrB6nUmJuqdOVZR6MlOrLr5CLMSWkxehQiQjMwHlp6fTbLTHSqk0aAqGSkjgtrTwE4ZjmLf1Xas0Z6pUh3XFe2DUtr1lRgjSQxjkX1MJj0n0MHmj13/bPgVOnOcXxnWykOiqe8BljITAAJRFutaaoysEl2ZRhjOSHITC+rfxht85EQlAQg9l0AMZzVzjlVNHuC/Xr046f9kEwmB7H76+R88Ff06wzw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=sLdGv+fG2t86tyUle0iGrYvhPoWrKjMYUwUgcNk5+DU=;
 b=HvWM2wPdjF54BWg8BQNITGb8bR72ljk3vPEnttCr/Anv4CZv9afUJjkedSENDkFUbVojU96S5ThIjPFIvyp+V8IF/cKt7H15oresoIYQtamwNmew1Or1VMM3shC3VtYbJEdowdzwSAQt/QQ4ly4hwYRs0DfIbyJ47ZRpC0N5wXAzLdWrZFkMO60blJ9G0URILx5gg454jWB8IewWYo/RhVzODStrYJBQ/V7XYtH99jzU7O4Ga6oUO0k7qlMKCdn5ucvSf2Vsqilp9B8LY9fA9Nfp9CrpC7lwvlVVMfMcq0JL7sl4e7FZoKMLFCr8P/wbwaS7UCJXrVlpc9YmJhCSYg==
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=sLdGv+fG2t86tyUle0iGrYvhPoWrKjMYUwUgcNk5+DU=;
 b=sGbZB4Ca+M121Pl96yGZO+nRMFpSw4p3zV7+Y+cECBJBazNt+BRVmBR1H3EcOuKP9D9p67WS1WSGMSbZ/Suub2CatGLA/zNVXVZPzZ8dIJFzSM20j+dKy3K/JaRmdiHEfJGtM2VQgpNJyvhzGmJD8HAclu3IMfBHxeIub3KUhM4=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 16 Jun 2025 13:07:30 +0200
Message-ID: 
CC: Andrew Cooper , Anthony PERARD
	, Michal Orzel , "Julien
 Grall" , =?utf-8?q?Roger_Pau_Monn=C3=A9?=
	, Stefano Stabellini , "Daniel
 P. Smith" , 
Subject: Re: [PATCH v3 03/14] CODING_STYLE: Custom type names must be
 snake-cased by word.
From: Alejandro Vallejo 
To: Jan Beulich 
X-Mailer: aerc 0.20.1
References: <20250613151612.754222-1-agarciav@amd.com>
 <20250613151612.754222-4-agarciav@amd.com>
 
In-Reply-To: 
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: DS3PEPF000099E0:EE_|BN7PPF862C85B20:EE_
X-MS-Office365-Filtering-Correlation-Id: 42d618ea-cb66-4b02-bfc4-08ddacc5fed7
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?TzNkTm5KSTVCUy9qWjNHeExMZ2dxcVdsMWZZYm1HVEUxdE9vYU9TdXlubkdm?=
 =?utf-8?B?ckswWkNNU1lLNkppWExvd3luYnBCLytMMFdOeUdpelF2ZUdSZ1VPTWtBbU42?=
 =?utf-8?B?Z0JXZktXR1YzV0RvQUp3dWtGNXNJYkI5bm40aGNydFN0azdWa2Z6Wm8rTVBL?=
 =?utf-8?B?RzhRZFdCejRZWVNzS2tOcE1tSVZ3TndIdnpwQkFUS0hvclRhQ21ZbXZ2Y1RF?=
 =?utf-8?B?cUc2TTNkL08yQ2MxR3gzclM5Q3VqQlN1RTg1RlRQcDE3SnNVWXc0MUxTakpO?=
 =?utf-8?B?WG5DRFVCN0daV3lOOXIwSnVTT1V0Y0xnQW96UmtxQS82ZFhtcnFINm1iQ2Jo?=
 =?utf-8?B?ZWdZeFhLWnR4TG9CM0t0WmFPdkZpdVZhWmRCQStZL1d5NlZoZWVJUEhsK3di?=
 =?utf-8?B?Kzd0YUpycjVGUDNoc0I2d1B2QUhFZG1zYkxuZFMyNnVuY3R6ejU0c0Rha2p1?=
 =?utf-8?B?WithSFpSMzF3K2dVaXlZanNMRnRLZUVNZFp0SitPcGNQK1QrN0tsS0o3U1pp?=
 =?utf-8?B?N0RBUnZPTzdDaDJHZEJWQnRNbmwrdktOaGp5TzdVNldDVVpFMmZrUzA5OFE2?=
 =?utf-8?B?WnNRaFlPQlNMOEdXMEpIV09DVUJWSUY0QnpVMFVycWlTWldsbXhZYlZrenVy?=
 =?utf-8?B?V0poQWVMeFNCZDNuZUttK2ttaDNDVkZBSFVRN2RaNDFQL0w1TnduN0RIbS96?=
 =?utf-8?B?dmxZLzhpdlJVemlhWktOSDVhUE5wN2w0TTBpRGNPN0cyNmpzNEFtQmxuS09M?=
 =?utf-8?B?ZVF5bGV1K2dKbG1TemkvMU5yWEY0SUJwU3YrNzJKQXc4VmVPd1NRTWRpRGVk?=
 =?utf-8?B?VTJ4OHY4dDRQbWRiQ1dTdGMvc0FUU0xLRzcxMGw3WXJ1NllJQ0tZVWsydGpj?=
 =?utf-8?B?d0VKOGRwN3BFY1BSSGZUejRlRGFFK0taeGZ6czMvRHFqeGNETEdYbjl4UE5D?=
 =?utf-8?B?cGJFeDdpaVNieFVpK09wSjUybGRVaWdPNGloR1VjY0N5VVlDb0tTL0xyT2xJ?=
 =?utf-8?B?R1ZXS0U1TjlNeGovbmZtNVNlUEIvNC9MTWU1TVZydHdQR2NJOUFhSmZvYjBM?=
 =?utf-8?B?eWsyTm8yQXhYZFdaWVRBR3Z6RUd2NXh5a09yR1hFZjVUb045cGkycXp5b0c1?=
 =?utf-8?B?dmlUTVh4eDJCQVg5Ykg1ekdCd2JJMzBJMmdrdVRPYTB2Mlk3SnlveTJuVkR0?=
 =?utf-8?B?VnVXTm80WlVhVFRLbmxtc2FvZ1F6QjN1NFVaRTdxanR1VW1ySUM4KzBWUUJm?=
 =?utf-8?B?VndTRmx1dEZOTjB2bm9DTWxLRTBiNVBLQ1RzcVpvZTZuZzFvcnVBbmx2eWJY?=
 =?utf-8?B?SndkMWRnMTZwcVBlaERXZHN6eVJUWHVSa3VTQUxjaHdGdmJFK042TWwyNVRl?=
 =?utf-8?B?Z0xCYkdVbDY3NllWeUVHQ2JVWXBOWW80bk9YMTBZbmc5SnBRNjQzQmhPYVFt?=
 =?utf-8?B?empiK2N4YkdJMnVwTUJmWnEwcjIya2NvbG1wTmVHQ3pJNy9JWExoZE1waWtk?=
 =?utf-8?B?YzlROXZhOXBLVE5JVTRvejBVRWNYQmhrbGZscXlCVFVXV3NLRUk3Zm9acnZ0?=
 =?utf-8?B?a2hhQ2tIZXRCb0JkRENyRWJSUmI2NDRrSjNkZndJbEF0UjBUNXBiVVZJR2Nh?=
 =?utf-8?B?TGFnNFJtRTF1dVlqUXRDN0JDa05vV3NhWG4zbyttL0l5cEJ6VWFEOEFxVTRt?=
 =?utf-8?B?Ri8xWU5hMmthSFI2VmszMG1JQk5sN1Z6NTVtdWZuM3Y1MXBYNVN6SEppcW94?=
 =?utf-8?B?NVowZmtHc2xpZFI0K3JsYkJTYys3M1B1eGYweFNzNys5WkJKNkgvMyswVndi?=
 =?utf-8?B?UDdHZHlLOFVrNVlsTStuL3RTeFZSTndGUURFVXE1U1BMY2dXTzZVYXlVWDRn?=
 =?utf-8?B?YWdoZnlJQm9FcVZHbUlEeGJ3SjFGUTh5Vmc2ZVJXYm5wamhiaGdYamdtL0xw?=
 =?utf-8?B?RFVoTVhrVUdFRGtQdDZqMVJIQkRYTTgxVS9CSXpSN2x3bkFZQnhSY21KZ05H?=
 =?utf-8?B?dWkwU0xYeUk0Q1Z2b3dzdnJDLzJpcjNyeHpCN2FZYk5aZEpUb2FtQm9RaUoz?=
 =?utf-8?Q?G+pSXH?=
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: 16 Jun 2025 11:07:33.9769
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 42d618ea-cb66-4b02-bfc4-08ddacc5fed7
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:
	DS3PEPF000099E0.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PPF862C85B20

On Mon Jun 16, 2025 at 8:48 AM CEST, Jan Beulich wrote:
> On 13.06.2025 17:13, Alejandro Vallejo wrote:
>> There's the unwritten convention in x86 of splitting type names using
>> underscores. Add such convention to the CODINNG_STYLE to make it
>> common and less unwritten.
>>=20
>> Signed-off-by: Alejandro Vallejo 
>> ---
>>  CODING_STYLE | 3 +++
>>  1 file changed, 3 insertions(+)
>>=20
>> diff --git a/CODING_STYLE b/CODING_STYLE
>> index 5644f1697f..e91ef7b3ca 100644
>> --- a/CODING_STYLE
>> +++ b/CODING_STYLE
>> @@ -126,6 +126,9 @@ register).
>>  Especially with pointer types, whenever the pointed to object is not
>>  (supposed to be) modified, qualify the pointed to type with "const".
>> =20
>> +When defining types, split its words using underscores (e.g: prefer my_=
foo to
>> +myfoo).
>
> Why's this being put in the Types section? This is about identifiers, and
> ought to not be limited to the names of types.
>
> Jan

Because the existing argument had to do with type names and I wanted to lim=
it
the blast radius of the new rules on architectures that don't currently fol=
low
them. I don't care where it sits or how large its scope is. If others are
equally happy to generalise to any identifier, I'm happy to do so.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 11:08:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 11:08:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017148.1394119 (Exim 4.92)
	(envelope-from )
	id 1uR7hq-0004Li-Cp; Mon, 16 Jun 2025 11:08:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017148.1394119; Mon, 16 Jun 2025 11:08:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uR7hq-0004Lb-9A; Mon, 16 Jun 2025 11:08:50 +0000
Received: by outflank-mailman (input) for mailman id 1017148;
 Mon, 16 Jun 2025 11:08: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 1uR7hp-0004LO-3F
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 11:08:49 +0000
Received: from NAM02-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam02on20626.outbound.protection.outlook.com
 [2a01:111:f403:2405::626])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 42d00dd9-4aa2-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 13:08:42 +0200 (CEST)
Received: from DS7PR05CA0105.namprd05.prod.outlook.com (2603:10b6:8:56::19) by
 BY5PR12MB4244.namprd12.prod.outlook.com (2603:10b6:a03:204::8) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8835.25; Mon, 16 Jun 2025 11:08:38 +0000
Received: from DS3PEPF000099E0.namprd04.prod.outlook.com
 (2603:10b6:8:56:cafe::ca) by DS7PR05CA0105.outlook.office365.com
 (2603:10b6:8:56::19) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.25 via Frontend Transport; Mon,
 16 Jun 2025 11:08:38 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 DS3PEPF000099E0.mail.protection.outlook.com (10.167.17.203) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Mon, 16 Jun 2025 11:08:37 +0000
Received: from localhost (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, 16 Jun
 2025 06:08:35 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 42d00dd9-4aa2-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=SK6NaSTzE9BJ2jTs1Hn5ktTRUziVDCMWd6SRqkp1jtD8cyykiQKnq9WtekHxYVYMDzDJHPcLehVwLKsT5eQZIbhrVeJX1ZqqsS1W7IaEVBzz8Ev+MQpv3D5aOe/H07tFA8kyCGoMD1h1K3GBg7lUTeQLtGcMjfHQpDdqVzRTYmY3Imsh6SNSa5Ex8wyHSCpLHioAllcsB/62fklQ1wclS3THgfOXNjdThl7HZT0hGHAi6Z27elI7iQbxkwfaU8nAhKbcP+6LAa7oaoQurr5Z9jlnjqKkuzp6Lk84qy0Zi1r39joCCX/6QCe86EfsDsAmfx1YN/bwu6OWRCCP1ovddg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=tML+fkkAsla4oagPUJMuFrBJe7qpUjDyEplBx4E4ySA=;
 b=qXFWa/cpWM6GtVQq2pHa+H7oOIOrDAnHgfFqAYVdm4sfOOA062Z2P67rFFZ3jOIFVHy2dJ6+dfW6IGBcps4rnw+tuRO/I8w+7Uw/hRz/JFU0U8SZYrvLTO3VwrF0ZupW70qEiy/2BpITSlkaWUT5o12hCS9UsryV5w/cawnYgC0aJwtl9983RSTBpnGKbCYt/So7tKjs41/KiFDldX5tZfpirvSK6KaJ/DmH61sIhMYTcPGuWJPfNKwDMYYuJ0SEmk/e/sOfJg+Ee7mhtQH4bBYcO3HWXRdQkm/yhEMnR7M+hHGiUtt0cNK6PXSjw80G1jS2U88mw3/NipTqQBSluw==
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=tML+fkkAsla4oagPUJMuFrBJe7qpUjDyEplBx4E4ySA=;
 b=yuNSRwDf9KsYslKgwgj2jxY7A2LwiTve6nvOx42RWNUo3COjVdLXMMYzPHU/3nSXLjxMoxuo8lF+xL2VD5nueT+YpPK3l5Pb+ZKddtnBvck+ekV3/LgzKBw5mP/lO+6HXGvKuf9WHOIptykRR3Wjvxg7poJbaEaWIRXS24OqRrM=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 16 Jun 2025 13:08:34 +0200
Message-ID: 
To: Stefano Stabellini 
CC: , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , "Julien
 Grall" , =?utf-8?q?Roger_Pau_Monn=C3=A9?=
	, "Daniel P. Smith" 
Subject: Re: [PATCH v3 03/14] CODING_STYLE: Custom type names must be
 snake-cased by word.
From: Alejandro Vallejo 
X-Mailer: aerc 0.20.1
References: <20250613151612.754222-1-agarciav@amd.com>
 <20250613151612.754222-4-agarciav@amd.com>
 
In-Reply-To: 
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: DS3PEPF000099E0:EE_|BY5PR12MB4244:EE_
X-MS-Office365-Filtering-Correlation-Id: c72d866c-14a3-4f0d-1f38-08ddacc624ea
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|82310400026|36860700013|1800799024|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?UFNkME1UVVJzazYramN1bC9qN1dYZSsrVUtFUm1PQ0tlOW9jTXJteUpZeGRM?=
 =?utf-8?B?SW82SVpvTlVuLzdTZnZPYmRjcGtQZWovQ2NSWWxXbUt4RHA1bjFUejJESEhY?=
 =?utf-8?B?MXMya1ozTTNnS0pmRnVjUi9LSWloV2NKNnNtYU5DR3pCV3AxTVp2U2c5NUMr?=
 =?utf-8?B?UWlMUWYvZkhtc1VqUHd0bS9LSG1jMVJsZkVBRHJTTDY5NDFjdmRrQnR2ZXcv?=
 =?utf-8?B?YW9MWkx6WExOSS9XQS9aWUgyRGZ3VkhRNERPZ2ZNYlVnTE9oUVVrTnViNGRW?=
 =?utf-8?B?WmgwSjA4VDdPL1paOVVqaFhHcC9BVkhQMDArMmt6ZDBvajJJVXZwSVRSZEF5?=
 =?utf-8?B?R0JJdU5qbmF3N0s5cWlyNThTNEdKenl6RlZSMEM4VEowdlZHaU5QNDk4dlhF?=
 =?utf-8?B?M2xYVm5jaXgzM2JWQXJFSk0xVjI1Z3dBYnhsVngwM0l5RGhnNStkckxZTTRO?=
 =?utf-8?B?NWJiWjFJVnhCS284T3pYUEs2Q0hybGtjQ2NmcUI5QjBZKzdjd05ZbzRFdHk3?=
 =?utf-8?B?WHNWM2M4a0FISys3RXN6L09Qd2JPMC9KZzUxeVp5Y2JvUDBOaG5KYWJORnJt?=
 =?utf-8?B?OURkSlZEZllucC9vcFhkOHFwclhwOGtMQTRuc0RJN0g0MDNQWi9YVDZ4anRv?=
 =?utf-8?B?UUhLSjN4YS8zZHIweXhlTWcwTXM4cUhqVlpNN21PTjhELzBNL1U5QzBibFJF?=
 =?utf-8?B?ZCsydCtEWm8xTUZjRXdkRU9jdER6N0FNTDBmaTJXK1ArUDhsTjRLcmdjeFNX?=
 =?utf-8?B?TmZ4QVgrZ25GY1d4bk11dSszRElheVU2WUVpZityd0hPd2NWeDlPbGRXVyth?=
 =?utf-8?B?ZGwxdzFtOS9mYTV3bXFkU29RdFlSa0pxMDFkdmlHL3VvbFFoZklUQmRsUkRO?=
 =?utf-8?B?eWlQZnI0ZlVPLzJjYlBSVE5RcW1RcHA3TGwrVlovNXM5dFZ3dkxtaUdOOERF?=
 =?utf-8?B?bnUzNnZ6QXhiZ25xL0haMVVNZkJabXo3V2dYWnZ1MjRCOVNUdmU2dU5rcm9V?=
 =?utf-8?B?VGFFN2dieUFoRVNBajFYblF3QnFSNUNRcWxoMVNNR2poSE9ZbmI5Nm1UUThJ?=
 =?utf-8?B?Qm1LM1VOSU9QM3pzdWg5TXlZTThCYW1Db0FFR0lYOHh2M3NFaFRBNFppbFFU?=
 =?utf-8?B?MG9PNlRrZ0lPVDBWSUpiaStKTUJkS1lUR0pmSFp0VUh3ekM5WHJhSkVuQVlC?=
 =?utf-8?B?L1gxV0R2YnBuL3FKNEFOaW9ZV202SHhOWlllbmN4NksxMjJiNnV0ektieFNj?=
 =?utf-8?B?c0srV2xZeWtqZ0ord2lDeVdNbkxMOG83eFd6eDdZY3hBOHM0SWlwazdsZ0lS?=
 =?utf-8?B?UG5SQW9CbnpqQmd0Q2k4RUdIYUhqTEgzdmYwS0lPRVdHT2ZFNWxZOGxEYzUv?=
 =?utf-8?B?dVhYNUJwRG5TNjZ6VmdteUpEdHRObms5aVhGQ3lacVl1OFQ1ZFFTaHBzUGZM?=
 =?utf-8?B?ckNJS0RaQTk4RGJFNWtCWURvOXBXQyswVHFIWDZ3ZUVnVnhkV1lNRWIzVUIx?=
 =?utf-8?B?MEdQUHdyNmxLejR2YnFtclBOVUVZY2h6aTQ5a2lHTWVzanVwYS9FRU03MHlt?=
 =?utf-8?B?QmpzWHhKWS9hVDdrWEQremdGR2RiTHVwL1FBSVJ3dkpmK0pnUWpJbVN3YU1N?=
 =?utf-8?B?YjNGL3lXamRTOWRrV2laRk1SeERJZnZUYjRXVzR1Q0F1Nk14RHloQ1ZHL3pQ?=
 =?utf-8?B?alpoZDJSenNqQ2VVSy9nSWV5SVlpYVlUMEZGeFRDSm84VUdSb0hEYVVpY0JN?=
 =?utf-8?B?bmpSL2pVMDdrOExZMG1HazNpWkI3OFM4c1RGRGdiK2o4d0hicVc0eGRYZGNk?=
 =?utf-8?B?WmN1MFRtUVpPT3cxUXFkR05vS01HdTVnbnh5K1dTYzJZaTVIa2gycUFSUGRv?=
 =?utf-8?B?T0ZWM0E2VyszaDA0STFoTmJvaS9ETjZMWVltYXlBSTJ1WExLeG1nSU1pNjJN?=
 =?utf-8?B?ZnhBbGJFQzN3cWhBMWNjMDVhcTlwdG80VVloYllVSXkyUEhINCthczRjY0Jx?=
 =?utf-8?B?T2s1dEtMcFQ4SlJZd3BaakU4Y1MwUWE3dWZXUk9ueXR6RzVqZkdvNlhxVGR1?=
 =?utf-8?Q?Hh4pkt?=
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)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jun 2025 11:08:37.8508
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c72d866c-14a3-4f0d-1f38-08ddacc624ea
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:
	DS3PEPF000099E0.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4244

On Sat Jun 14, 2025 at 2:32 AM CEST, Stefano Stabellini wrote:
> On Fri, 13 Jun 2025, Alejandro Vallejo wrote:
>> There's the unwritten convention in x86 of splitting type names using
>> underscores. Add such convention to the CODINNG_STYLE to make it
>                                           ^ CODING_STYLE
>
>> common and less unwritten.
>>=20
>> Signed-off-by: Alejandro Vallejo 
>> ---
>>  CODING_STYLE | 3 +++
>>  1 file changed, 3 insertions(+)
>>=20
>> diff --git a/CODING_STYLE b/CODING_STYLE
>> index 5644f1697f..e91ef7b3ca 100644
>> --- a/CODING_STYLE
>> +++ b/CODING_STYLE
>> @@ -126,6 +126,9 @@ register).
>>  Especially with pointer types, whenever the pointed to object is not
>>  (supposed to be) modified, qualify the pointed to type with "const".
>> =20
>> +When defining types, split its words using underscores (e.g: prefer my_=
foo to
>> +myfoo).
>
> Minor NIT:
> When defining types, separate words using underscores (for example, use
> "my_foo" instead of "myfoo").

Fine by me. That's clearer.

>
>
> Reviewed-by: Stefano Stabellini 

Thanks!

>
>
>>  Comments
>>  --------
>> =20
>> --=20
>> 2.43.0
>>=20

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 11:31:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 11:31:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017163.1394128 (Exim 4.92)
	(envelope-from )
	id 1uR83n-00006P-6n; Mon, 16 Jun 2025 11:31:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017163.1394128; Mon, 16 Jun 2025 11:31:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uR83n-00006I-3s; Mon, 16 Jun 2025 11:31:31 +0000
Received: by outflank-mailman (input) for mailman id 1017163;
 Mon, 16 Jun 2025 11:31: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 1uR83l-0008RD-F4
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 11:31:29 +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 6c1b3d3a-4aa5-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 13:31:19 +0200 (CEST)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-60780d74c85so6549033a12.2
 for ; Mon, 16 Jun 2025 04:31:19 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-608b4adeb51sm5923836a12.70.2025.06.16.04.31.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Jun 2025 04:31:18 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6c1b3d3a-4aa5-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750073479; x=1750678279; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=XAe+MWgJTvsR6VoPJ+x38dlb6fw2IK0oklKJhP7LoCo=;
        b=V5LZ2B16M1wI87xulmNRYEVfzWg7j1r2WFs+lqbrLUkf+Qe0VBsRnVXtd/fEC8l2Ep
         AGZ9aTX0uLasOityoTzp8uLwsG3kheP754pUe89K1xu2lZAgAmDxfgGtdBgKpDll1JoE
         XpKGKQgSMKaTLhNukIy7OBFGMSWzly9Ulc3o0ajxY3Bq49+6BQ0/gGrZCQQ/sHYelTvM
         aIzAe7uJbqwaDnOWy2Dv1b9zC6pOlnbixi5z1K4l6Lo2Qma0sNL3f05nd03WVx6ajchr
         39n8ppnVROaBcOj+HW67e+YNO8j9Q51/QuO2UT8b16vJTJm17OFrjlOEu/nNuPq0hTtF
         +uTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750073479; x=1750678279;
        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=XAe+MWgJTvsR6VoPJ+x38dlb6fw2IK0oklKJhP7LoCo=;
        b=VBj5wtdSrxXWg4jn1vvUL1FaDOKl0qCx6QUHLBDnNG5sM35FaUGdCc0+EtELXTeZJC
         caI6wqCfuFbs3JpJnq5xQG7vnaQ3mC/Hb/N8N6uiOE+HF5/siPC50WJ2wAbiS19nyx1j
         wly0mGFEsz//REi4zYhXCPv1V3q9lnblCKpDTqb9t8yiMmKefx5sE8AAORR0E4iV5A6f
         hCc2kLqjUdo2vKmYJfFyZh6s8uIed0uNQphgQHVcC8a43roamVKeS9zWuKSvDR4jOKpo
         d7+lt54pkCbSDrcG/80PfQY+R0EecEL2ZuYBkF2rIy/GKfa1jReswXqqmJrw3SSFsc+C
         hGAA==
X-Forwarded-Encrypted: i=1; AJvYcCWZige2aoHmhyMuOhkeA1G0uyX9JHQ4IUbkXXE0NF6a85D5U06UqliDsPyd+NUK9Z8+ie9NlVJISxg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy/cSVbSJ496u//UOEclAVpioy0HfMXhR7C03I/XRvE456+2XJU
	CUNfkmDCljLZ0NLTIj7e62nZqolVXOOjufPiRLJ2fQtEhyy/e+abFcPtC95EceZvOw==
X-Gm-Gg: ASbGncse1SrR1Mxx1tfUO8YNzdhcATSm5d6MEpkp9CO9J/b1Y439ZyjyZpTXvtUPEmm
	8lP8xUdF6pWFNwAJHq8XW3Mzckuc9l4arppZnS6ub9K0NQFDQMRq8+T8t2aMGyXSn+kJ81zWFiu
	1SYHF84PSAQxA7SoXDRaG1+e9JIYfRGeyOPnYrLFRLH6llh2vc7+d48399NvOprSLhSVaBTVwgq
	UHmofp1mTzhV9JBJnspWPoG2jh52FAoRAiHCXKG34dO5HrlWy+7zUXHTVknFutqY759ac5b5YMG
	lluaAY/lON9Jg6t56o3nNOIrA0uVvHJ2Wb7tuwBuYgqbHVyAd4WK3G4I/5LXVfvfeMurmXilMTf
	/VEYwUrmQmxNGm/o5nc1JYcM1iJGwqbxGdvEbk73j/zaHEAU=
X-Google-Smtp-Source: AGHT+IH+BLZwEcBLybJQKT5SFJQLs01w7H3/XLYig6z8CCdLC5U/AfTI5N+RnPzHCMzC5ebw9N/U0A==
X-Received: by 2002:a05:6402:350e:b0:607:1c07:727d with SMTP id 4fb4d7f45d1cf-608d09b8ec8mr7225402a12.23.1750073478680;
        Mon, 16 Jun 2025 04:31:18 -0700 (PDT)
Message-ID: 
Date: Mon, 16 Jun 2025 13:31:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v8] xen/arm: pci: introduce PCI_PASSTHROUGH Kconfig option
To: Stewart Hildebrand 
Cc: Rahul Singh ,
 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: <20250613154847.317979-1-stewart.hildebrand@amd.com>
 <3ecf10e5-5df7-4348-85a1-b8eecb940bf8@suse.com>
 <2e0627fa-35b8-4d3d-a3bc-338f9f7ed61b@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: <2e0627fa-35b8-4d3d-a3bc-338f9f7ed61b@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.06.2025 12:37, Stewart Hildebrand wrote:
> On 6/16/25 02:42, Jan Beulich wrote:
>> On 13.06.2025 17:17, Stewart Hildebrand wrote:
>>> --- a/xen/arch/arm/Kconfig
>>> +++ b/xen/arch/arm/Kconfig
>>> @@ -8,6 +8,8 @@ config ARM_64
>>>  	depends on !ARM_32
>>>  	select 64BIT
>>>  	select HAS_FAST_MULTIPLY
>>> +	select HAS_VPCI_GUEST_SUPPORT if PCI_PASSTHROUGH
>>> +	select HAS_PASSTHROUGH if PCI_PASSTHROUGH
>>
>> Seeing this, I like this as little as I liked ...
>>
>>> @@ -258,6 +260,12 @@ config PARTIAL_EMULATION
>>>  
>>>  source "arch/arm/firmware/Kconfig"
>>>  
>>> +config PCI_PASSTHROUGH
>>> +	bool "PCI passthrough" if EXPERT
>>> +	depends on ARM_64
>>
>> ... the form with the select-s put here. I'll (obviously) leave it to the
>> Arm maintainers to judge, but my recommendation would be to simply drop
>> this patch. As per the description it's merely "make it easier ...",
>> which imo doesn't warrant such an abuse of HAS_*.
> 
> "easier" was a poor choice of word. "possible" is more accurate. This
> patch addresses a real issue: currently the PCI and vPCI bits can't be
> built for Arm, allowing build issues to go unnoticed. E.g. see
> 4ce671963eb1 ("xen/arm: fix build with HAS_PCI").

Which gets us back to the question of whether to use "depends on
HAS_PASSTHROUGH" (I think yes then) and where to put the remaining select
(might then better move back to the new option).

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 11:35:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 11:35:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017170.1394138 (Exim 4.92)
	(envelope-from )
	id 1uR87W-0000fa-L9; Mon, 16 Jun 2025 11:35:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017170.1394138; Mon, 16 Jun 2025 11:35: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 1uR87W-0000fT-Ia; Mon, 16 Jun 2025 11:35:22 +0000
Received: by outflank-mailman (input) for mailman id 1017170;
 Mon, 16 Jun 2025 11:35: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 1uR87U-0000fN-Mp
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 11:35:20 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20610.outbound.protection.outlook.com
 [2a01:111:f403:2412::610])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id faf8a315-4aa5-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 13:35:19 +0200 (CEST)
Received: from SN7P222CA0019.NAMP222.PROD.OUTLOOK.COM (2603:10b6:806:124::13)
 by IA0PR12MB8713.namprd12.prod.outlook.com (2603:10b6:208:48e::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.28; Mon, 16 Jun
 2025 11:35:15 +0000
Received: from SN1PEPF00026369.namprd02.prod.outlook.com
 (2603:10b6:806:124:cafe::77) by SN7P222CA0019.outlook.office365.com
 (2603:10b6:806:124::13) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.22 via Frontend Transport; Mon,
 16 Jun 2025 11:35:14 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF00026369.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.8835.15 via Frontend Transport; Mon, 16 Jun 2025 11:35:14 +0000
Received: from localhost (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, 16 Jun
 2025 06:35:12 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: faf8a315-4aa5-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=dCknEX8HTfBYsBN/R3RIhHS1MCEMWIAofCZJxoCFrK/i+YtjzIijgaC85fA3OSRDtmK901QhDVveXN6eyqWinYOw9XLBBpGXms+vdGKTmvOnakQjW9udSJwR2uUZWMYNb6cG/Q23d60Cf1JElFTmCq7ZwtILYWqaJc5rJCbzSUR2B6OkaxVc+gWfmAGnZeDUIQVlDHw3fdMzzISo4gwddp7CcZOSKn3QehDpWKjNExMWvdq4/4oH+o6/4r8WfzezAA78MHI98F1H2caSnlyKo0SQKaFQKUQcQQEHGlYSBLe4gb3PTcZjDud9DvuDVcE2Jbg9Z8mwPHIFumLg3Cwf7A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=lDQ3bQFYdjDOzL3hTZiERV4U8ZBQU4fS93H25iuCVBU=;
 b=Bk/5a8BjU8YNPm7uutpCKNCgKjrvk5XuI8gRXXvGoqSCbMqr8mUaX/YZgbyEp4qd4wh7nEribPlSHV8ReXybwHllrba10qSvPzAKBjuoifdggkOvlAkkgdBsyI6+DDWThIm/N0qMbW6KWnbtXlGw0RQBSmqfM1pkW59viw83fSSeZSYzSuXEZchifTDeFnYiSmReYsT0wDM8X8UhsWcOVgLaPWgxOmK4g5XZcA+91d160S4TsipPQLnpjM82mOAMgHR+MbayfSM/s4hevig4oISg/w3UKg4jYZqULgnrWo/RgtYt+oyu/iiY2DpMtPqLVL3/X2li28MvBZkGdVZXRA==
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=lDQ3bQFYdjDOzL3hTZiERV4U8ZBQU4fS93H25iuCVBU=;
 b=vikwEr/Vyh1xvT25nHwpQuOQ1fvAwFqIV6Hq6xyuc4Y9Ff5srV/cWUj4Gr/fIHOPyWTtUjcEmPI03M3lhVXm4OtpBSNhMgzjHxej7eMBn5+pIVtBxkbEnN5NZ71RM6zbaWPEZlLtSW+qNsUAXIBUn7D159X7bMpWYT0GE9Fs8Qg=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 16 Jun 2025 13:35:11 +0200
Message-ID: 
CC: , Jan Beulich , "Andrew
 Cooper" , =?utf-8?q?Roger_Pau_Monn=C3=A9?=
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Daniel P.
 Smith" 
Subject: Re: [PATCH v3 05/14] x86: Replace arch-specific boot_module with
 common one
From: Alejandro Vallejo 
To: Stefano Stabellini 
X-Mailer: aerc 0.20.1
References: <20250613151612.754222-1-agarciav@amd.com>
 <20250613151612.754222-6-agarciav@amd.com>
 
In-Reply-To: 
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: SN1PEPF00026369:EE_|IA0PR12MB8713:EE_
X-MS-Office365-Filtering-Correlation-Id: 10276f65-c12b-4937-00b7-08ddacc9dcb5
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?d1E1WE1BM29laWtjNHg4Sml6bmtqMGFMeFpQRk9aQ0N6R2FMSm9WdU5OVVRp?=
 =?utf-8?B?TDJMOGxYSUFlOHN4U28reERIUUxXbVBUbDlBek9GWmk5SG5MelBmbUNMTUNq?=
 =?utf-8?B?V3RBWnFGM01QWk1LVlRvTFVPdDcwb2p4emJxSzEzQnNQMVZibjZESU4reW1S?=
 =?utf-8?B?WEdJbklHdUErRTVwQU81OFhPVTRpQm1vQTUvM2RoZjhPUTFYOU5TVUtRby9G?=
 =?utf-8?B?S3o3Ui9nMjhoU1NoMWovYUNQQzREa1RJbGtwbW1pemNZL0pBN2t5WWJMR2tZ?=
 =?utf-8?B?eHJRRDJibm0yaFhjeGowVjk5aksrYnRQL2w2WndleGJUc0NyY2Rqa1o2L2Za?=
 =?utf-8?B?RnJESm9QWG9FamcvUi9CaU9QWHNPY0YxT09Oejh1RFJIVjhJQ1RObklvMUhl?=
 =?utf-8?B?VWNCRjBpYjAzMTQydFFaUUFwUGo4eVd6clhnNE0zN1BNQ1I3SmFBMVpYMkhP?=
 =?utf-8?B?ZlZtS0FDaG1jRmVBeUEybjNFQU80aWFBbG1yK0t6SGRpRVc4Y3hOU2IyY01l?=
 =?utf-8?B?QW9ISWVVN3lPKzZxeVVyMFEwYk90cnFDTWhJNkZqVVNtRDltSmtFZzJkUFRt?=
 =?utf-8?B?QjFxMnQ4dlFPb3Y3RFNvZE41amVuNTlrT0pCeWU1UHgzUWd6M2JJbktYVHhB?=
 =?utf-8?B?MFJ3NmI5bzBBRmd6STluSGxPeERkL0ZOREhHS1I1SmtyUzExM25FTUdpaEky?=
 =?utf-8?B?bEdIeDVhUjBLSDFxbms4aUoxb2E0endCUG92bThjdTc1UTVzVmpVdEN1em1L?=
 =?utf-8?B?ZkFTQ1lkVGFvcXVFVWdkaTE5QllnM29Qb1RHdDZHWUpNRUNuUTZCT3RGeGFH?=
 =?utf-8?B?WnlKSE14VEtDdGR5V0srKytwM1RQNnRUQ0p1YVEwUUdRQkZmOTFpK2NsY0I0?=
 =?utf-8?B?RlFqdXZUTktKRUFjb25XRzhVcFBMOHc0N2V0Yy9scTZuMG9hZzNrUVBFd0k0?=
 =?utf-8?B?Q1hjN0pTQUxvZFprQkJxb1RERklLeHcweTdRc2tNdEYxRG5nUDJUWURXa3Rz?=
 =?utf-8?B?UFl2eFNILzhZblJySnoyMlhWcTVaejBuM3QxN2QyTjNOcUJCeHZhQ2VGbmR1?=
 =?utf-8?B?MVl5WDI5UDhkNVFiSXl4Z21HZU85Tm5oNkUwVHpidnlmS2l1eWdQOURUalVw?=
 =?utf-8?B?b3AvQjZ3NEJqeGdSZW5yeVByNSt0T00zbldvMFA5NG83cThKWWlQR1VGazJC?=
 =?utf-8?B?c01KdnNjNmppUThHRTRZeDVzUk85cDhqRlRzR3VISlRmaVhqM1ZXdFlYTlpu?=
 =?utf-8?B?eEUybHFZZ1cvdG4yWWNINlV2bytOdDI3OHNOYUNKYm83MU5ucVg1T1U4QlM0?=
 =?utf-8?B?OHBtdzgxYlhZNm1tN1UySm5BbGpYUVl5NGJPaEcyY2dhQ3FmZ1NVZjcrWnpR?=
 =?utf-8?B?eUl4byszL3B4VW5ZZnhDeGs0elAzL0o3dS9DU3A3dDlhNGx1d0ZYVTZGVDAy?=
 =?utf-8?B?a2hBWklXY2hzeTVoK2ZkMkpTN1p5THBMSlN6WWZnaDdpTDZteVZnNld2UFls?=
 =?utf-8?B?RG1PREZhRzEyc0FUVUlEcHRGRmozNlV1T2p0Q3Nrd1dFMVlLTEpJVnVsVXc4?=
 =?utf-8?B?RzVoaEhmWUtLNlRaeDR2dUVhNElneUJXV1BaVXlINUtwaUxxWkYrakpCMmlj?=
 =?utf-8?B?Mld5bTBUQWVueGkrYmpYSVFlK21XUmYzSldtaG5pZmhiRTFMV3hQSnMxbk5W?=
 =?utf-8?B?Yk9vYURDR2NJWC9KUHM3R04ydGNRNWFPMEVDYlZkMkx4RWNqQWFEK2VOdUFX?=
 =?utf-8?B?WnNMRUdXTmxCaG1VNFhTSmVaRXE5R1ZIeU1DTW5VUVl3Mlh5STVobWIrUUJm?=
 =?utf-8?B?SFdDcEdRbzduS2hkZEFaU0ROSnBQTTlxY2JHVmtqZm5LR214YmJ0SHdteXQv?=
 =?utf-8?B?TGFyQjd0UjdROFdoRVVwTFZNb3A5bUEwWWRnWGtCMWU4d3NBWVhQQ2daVktH?=
 =?utf-8?B?aDBscG4yVGJyVi93cU9Db09YV2c4SHlvRXh4SHNrbGRzRG1PcWRhODRoRm85?=
 =?utf-8?B?Ry9YZy9FZlFUbEhMbzFjWHBxOTVqeU5qWFdNMFZiZUQvdU40UEFlbVd4OEc0?=
 =?utf-8?Q?OUSjoO?=
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: 16 Jun 2025 11:35:14.7071
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 10276f65-c12b-4937-00b7-08ddacc9dcb5
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:
	SN1PEPF00026369.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB8713

On Sat Jun 14, 2025 at 2:54 AM CEST, Stefano Stabellini wrote:
> On Fri, 13 Jun 2025, Alejandro Vallejo wrote:
>> These types resemble each other very closely in layout and intent,
>> and with "struct boot_module" already in common code it makes perfect
>> sense to merge them. In order to do so, add an arch-specific area for
>> x86-specific tidbits, and rename identical fields with conflicting
>> names.
>>=20
>> No functional change intended.
>>=20
>> Signed-off-by: Alejandro Vallejo 
>
> Hi Alejandro, this patch doesn't apply to staging anymore, it conflict
> with 3998da124.

Ugh, I'll rebase it and re-send after the existing discussions are sorted.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 12:00:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 12:00:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017183.1394148 (Exim 4.92)
	(envelope-from )
	id 1uR8W5-0004vQ-Mu; Mon, 16 Jun 2025 12:00:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017183.1394148; Mon, 16 Jun 2025 12: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 1uR8W5-0004vJ-KD; Mon, 16 Jun 2025 12:00:45 +0000
Received: by outflank-mailman (input) for mailman id 1017183;
 Mon, 16 Jun 2025 12:00:45 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uR8W5-0004rC-3i
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 12:00:45 +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 878b5a4b-4aa9-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 14:00:43 +0200 (CEST)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-6084dfb4cd5so10400281a12.0
 for ; Mon, 16 Jun 2025 05:00:43 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-adec88fd993sm660714066b.94.2025.06.16.05.00.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Jun 2025 05:00:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 878b5a4b-4aa9-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750075243; x=1750680043; 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=gbEFUj4xOp4GCpLAe55r5DawhD49OKXqVJPjz0gLjKQ=;
        b=I2T7UWKDaxk3WbI43Eg2G8+lsn7gGHwzcI00mfEztIs3zECJdRG3e36lISMV04a3gP
         cpfzP9bZIFs1tDg9NhQoDmU+2AwQYx+JfLUK14Hjh3M7LiQkTy+brKt79FhVTWlVQIVV
         8E/NwNiXzHmf1Nid3a/Q5+V5DyOC6/oZr1MU71hCq94tzmEo27kN1sxoo4i8ZgFFSRCG
         BOi1ZzzdaeePVRL52eDFVYABI1bAUGLmFFYNWscUE5m0anbqcfLTXjySIgy0qAburIyo
         dMEPEXl3gDI9yyGmgt+1oUqe2+yT2dlYcMqLoBG7QRGcPdsBwrjIIsfxMmp0oaHJE2LX
         U+WA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750075243; x=1750680043;
        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=gbEFUj4xOp4GCpLAe55r5DawhD49OKXqVJPjz0gLjKQ=;
        b=ZmmYZUmgk0v2wef+7feIW7jpWytpZMzP+Lp8Pgna5G1BTU8cpVdRccW1s5iCfUqAda
         H7Tclk2y660v9Y1DUSxgQvzZy3qzvBnAKttzvaFV6RQzRXp1JhOsx12EOBij9rEVvkAV
         jsizCHD+J2AQmzYJ9qqRsU03Q3hq6BHiRbk1fGjkUo7kOjkoig0DL8cLewWhGsG17Ecz
         7wBOUC1P0VHe8lmsPxIp2ONkbUlW9trPiiwcjZDJ8SeAy1Ei2vVF/RtOMdHV06fuSZMQ
         PNXwehBvDknqqfxiJ3XGHwkM/MzfiYuCbil2HDMXk6jWuh1p5ZOhNyap/mpcm6Dq22RZ
         T2QA==
X-Gm-Message-State: AOJu0YyyQ7jQaoTnaGzrUcT2Xe1SAsaFlh3MPwdAxa27eRjdKX1T7ysD
	rSQrWvBS9cBKDv5eIVuphUT+nwCHhokOJJVQkF4IzArWtsIz1pBRvwcxJwADE91mY1/r5hQrNyT
	i5l4=
X-Gm-Gg: ASbGnctkiUU4C7tyqKFulDBAwJAEsCJ9NXFpH6XlVLHEQeYpiJ8rgeNvUmV4lcWXVzp
	DI4EQ/R+SatbgKyZNWPIrolL1Ay+UVZC8QPBxm9AoYbjFlYfCQ3fcKSpIugPU/iW37RG8OVj1dc
	E1IzNkbf5lgaRBbdDaJm2g5QfU0JfXcwlGd5IQUnF5JhazLkq75I0aErq2rTxq7d3/pkmTAZHVR
	0yrsi+1zPlWxpQSz/9wAhZ1LLMoNWsuEJnKrKdFrVE6laFFqmuuOx/9pKSkbniJ6bhv67vnxWXy
	k85BFrQby96R7dJsIV1uZmu2s5pJ2RXy+jjbYpv9tGMHP6fe/8qRu7FOe3z09/JR2wrg4xmSDaM
	MNApqo1PGUR4fT1vp4R4P6RsvfIHHzRHtQjXXjwR76yti1cc=
X-Google-Smtp-Source: AGHT+IFW6aGoQCp06pvgDpHVbIoriuJ9QGabn7q5z3ZAAPUJUSi37VS67E8/pcXhuvrvyF8NxD1c7g==
X-Received: by 2002:a17:907:3d45:b0:ad8:89c2:423f with SMTP id a640c23a62f3a-adf4c73201amr1034122466b.7.1750075242451;
        Mon, 16 Jun 2025 05:00:42 -0700 (PDT)
Message-ID: 
Date: Mon, 16 Jun 2025 14:00:41 +0200
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?= ,
 Ross Lagerwall 
From: Jan Beulich 
Subject: [PATCH] x86/pmstat: correct PMSTAT_get_pxstat buffer size checking
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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

min(pmpt->perf.state_count, op->u.getpx.total) == op->u.getpx.total can
be expressed differently as pmpt->perf.state_count >= op->u.getpx.total.
Copying when the two are equal is fine; (partial) copying when the state
count is larger than the number of array elements that a buffer was
allocated to hold is what - as per the comment - we mean to avoid. Drop
the use of min() again, but retain its effect for the subsequent copying
from pxpt->u.pt.

Fixes: aa70996a6896 ("x86/pmstat: Check size of PMSTAT_get_pxstat buffers")
Reported-by: Andrew Cooper 
Signed-off-by: Jan Beulich 

--- a/xen/drivers/acpi/pmstat.c
+++ b/xen/drivers/acpi/pmstat.c
@@ -272,11 +272,14 @@ int do_get_pm_info(struct xen_sysctl_get
 
         cpufreq_residency_update(op->cpuid, pxpt->u.cur);
 
-        ct = min(pmpt->perf.state_count, op->u.getpx.total + 0U);
-
-        /* Avoid partial copying of 2-D array */
-        if ( ct == op->u.getpx.total &&
-             copy_to_guest(op->u.getpx.trans_pt, pxpt->u.trans_pt, ct * ct) )
+        /*
+         * Avoid partial copying of 2-D array, whereas partial copying of a
+         * simple vector (further down) is deemed okay.
+         */
+        ct = pmpt->perf.state_count;
+        if ( ct > op->u.getpx.total )
+            ct = op->u.getpx.total;
+        else if ( copy_to_guest(op->u.getpx.trans_pt, pxpt->u.trans_pt, ct * ct) )
         {
             spin_unlock(cpufreq_statistic_lock);
             ret = -EFAULT;


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 12:58:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 12:58:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017199.1394160 (Exim 4.92)
	(envelope-from )
	id 1uR9Q3-0003Ib-H2; Mon, 16 Jun 2025 12:58:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017199.1394160; Mon, 16 Jun 2025 12:58: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 1uR9Q3-0003IT-CW; Mon, 16 Jun 2025 12:58:35 +0000
Received: by outflank-mailman (input) for mailman id 1017199;
 Mon, 16 Jun 2025 12:58: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 1uR9Q2-0003IK-Pe
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 12:58:34 +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 9bb1574c-4ab1-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 14:58:33 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a50956e5d3so3576410f8f.1
 for ; Mon, 16 Jun 2025 05:58:33 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-748900062cesm6896839b3a.57.2025.06.16.05.58.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Jun 2025 05:58:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9bb1574c-4ab1-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750078712; x=1750683512; 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=PbE554ZyoJxCF4Kt4rDM08ARYTbW+vpP1lliBK1TCig=;
        b=Avgi3OMlYILhNjGzEdjUeelmveHqoixMIlBkZVq9iScpaEM/HcTFlDnRVv4xp72yxa
         j+0FClaNox7tu+/94D/ibpXqmHZ757tWHOGirPcUuEd2DCghZkVkVrQahedx51rZc2Bw
         IFuLnHbZJp6F9txOdxEfgnKHh+Tvr3kRcLy7uwz3xdcRBoCUOCWAdQ+OuqsSBxjM4qbT
         HpV4PSZmJMW0jeJzbJUWHSiaAS3YWyp8tpRdrdLbK98jFX4dpuRyaKU5w0ZM8lKtbEP6
         2YBifxOkpxPvblLmWpYD60RW59sfdSY13otNJz3RkpRg+A3TUW6iXgu04jkWt6t/fI90
         noCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750078712; x=1750683512;
        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=PbE554ZyoJxCF4Kt4rDM08ARYTbW+vpP1lliBK1TCig=;
        b=Q1FkNzbV25XVbZztOdaSTrzcqKuXHJc1dnfDqUVIoJyNfIscs3AE3FN0k+HjfkHxYa
         QOXasD6VhdOUloTPgM0OgehvsogAXIoDHpj441t+k/ozTuMznqKMBDSXrd1EBAnBTLDe
         MQGMrldLA+q5tTNxJN+rCq2esuKkYAUAad9MWIc8zJORWw7zuSFBLIfOaFhEXCDD+5jF
         kZDzKk5QVoCa82ZgyWbMgWHgleuDkTPQ5qHkIRHcJY+wYehizic1UwDVpxghwpTD0SLV
         Bj8d1t8+9u7Ff8A74vtodNokLxF2XYKrVEzDmhOoLjW18f76csX1k0eZ94nuJuZAJncK
         kAUQ==
X-Gm-Message-State: AOJu0YyQh6N37ko1PuaYAtieRoZkHEeh5tlK2Ph0WpNBe2tUZ/FLsZHC
	YKyHK1DAVic5zHIMcahmoeQ47orPvmTrnKrfNotH1U314aTSfRUfgOO+5/zbKU+KEssNlFGY+rY
	7xU4=
X-Gm-Gg: ASbGncuiTtPd4DAjw4aMmK4c74m4B2FgEgQ1wEZ8i9MCPZzqyyK4dMKw70ArK243e+r
	mE+1TwlUu4bItkr9jPnhkE/s+uORPDKkAtxr7Lcqzo7pEih2frSQSLnBHv2g0rRD91Cx3cgpzOD
	RkcgJKejO5DAf/cjhzpzkjt7fw2Sdy+JIZHdNAVOAw+kbOdmr17pZFLkTyKg8nglxi3U13SJ6sG
	7+dVizwU/sB+srUAvhVfGf51Dm8CwF4dgpZ+C8Wjc95GzTGQAuYZnr44DrqNgZdcSfBXlpAHRCQ
	R8FTuk4eZuLjGNBabTORuOB2arEHBEHat7NCG+GkabUi63YVBs+RRkM+GIgBnrk/gtaXDnJvg7a
	28q1IpM7u5lgV/U3rdZwOlAdzgwF4esaxFLZrVAv0cOlm+2c=
X-Google-Smtp-Source: AGHT+IGxhOv4vac1qrCymhWvYvdcmQ5ZB1uZxPE7STEXABuL7tMNVTYtG64u2wdKbZ1n4ZLByiQUfg==
X-Received: by 2002:a05:6000:2893:b0:3a4:ee51:8144 with SMTP id ffacd0b85a97d-3a5723a3ac8mr7591992f8f.13.1750078710517;
        Mon, 16 Jun 2025 05:58:30 -0700 (PDT)
Message-ID: 
Date: Mon, 16 Jun 2025 14:58:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Jan Beulich 
Subject: [PATCH v6 0/7] x86: memcpy() / memset() (non-)ERMS flavors plus
 fallout
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

While the performance varies quite a bit on older (pre-ERMS) and newer
(ERMS) hardware, so far we've been going with just a single flavor of
these two functions, and oddly enough with ones not consistent with one
another. Using plain memcpy() / memset() on MMIO (video frame buffer)
is generally okay, but the ERMS variant of memcpy() turned out to
regress (boot) performance in a way easily visible to the human eye
(meanwhile addressed by using ioremap_wc() there).

1: x86: suppress ERMS for internal use when MISC_ENABLE.FAST_STRING is clear
2: x86/alternatives: serialize after (self-)modifying code
3: x86: re-work memset()
4: x86: re-work memcpy()
5: x86: control memset() and memcpy() inlining
6: x86: introduce "hot" and "cold" page clearing functions
7: mm: allow page scrubbing routine(s) to be arch controlled

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 12:59:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 12:59:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017205.1394168 (Exim 4.92)
	(envelope-from )
	id 1uR9R6-0003px-No; Mon, 16 Jun 2025 12:59:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017205.1394168; Mon, 16 Jun 2025 12:59: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 1uR9R6-0003pq-LD; Mon, 16 Jun 2025 12:59:40 +0000
Received: by outflank-mailman (input) for mailman id 1017205;
 Mon, 16 Jun 2025 12:59: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 1uR9R5-0003pW-FL
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 12:59:39 +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 c1f4b323-4ab1-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 14:59:37 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3a57ae5cb17so873011f8f.0
 for ; Mon, 16 Jun 2025 05:59:37 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-748900062dasm6979838b3a.66.2025.06.16.05.59.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Jun 2025 05:59:36 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c1f4b323-4ab1-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750078777; x=1750683577; 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=CCGJJ+18Hx71qZ1BImD3aJBlrhNSiedNN3y6oo5smPU=;
        b=d41sfRt1bRz3vh2iqAmbc2CMDYQUXhz3k1jIRkYdwBJ7+RG4JkFuIuTfXWAOxSOHo+
         rBhI45W+IY+sNefO1Goh0Qvt3MJlWfSXmNaZOSiV52B4B1inw9Hk2RVCcfC2yi+Rof4P
         GYki66At2+oM18rBiBxImN2LqoZUFe8zy4JW5945MvGhRJIuA/jMFA8QvAhNGz3C3H0X
         LZD/pt1EmwfYVfybV3LmU5UrDbua5v+YzL+ExLkguHTYsNrQE+FuZbga8wmCii4QEY/E
         I4jwPSDxWcdTeAfCSZjdDwYZBqf74rPWyGsb+V8UgLb7VLd2rM6SciqjfsH5S5IdA8Js
         9JZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750078777; x=1750683577;
        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=CCGJJ+18Hx71qZ1BImD3aJBlrhNSiedNN3y6oo5smPU=;
        b=BPaQ86XtkU1gbFytnhOaVja8Nakxtcv3wJtrso2FUtUU3E8+WEhnD982g5fyD0mAnr
         MItkb3oGpTsNDx+VIlvgAMV1Cc3I55O+qjbfxjY64iSdjLSiPlG+5mrZAbJeQhIKER3C
         ZmxZXuggzupSImtFzE7hWOP9QFf2t3GL2ZUDgNt2bDADYPXMPk2gY7zQ+PqdOlImMGHr
         tmZCbMB3V69AMkesa0R1vU5TcBpDYibnY2LELzBT+t7f5HFWaf8UQ0HPam2yP7p67+al
         84FKE2flh1TQgb3pjfEq11ZdfyouR5hQvdxo6WolMv+6HMJ6x0m8OrYb2H0JxCRRPiKu
         SEXw==
X-Gm-Message-State: AOJu0YxqbdFVboxGy7uzWpWbyyw2unUrZ5Yqzzf3+ELeDIjXWijIyQyI
	KQtWlFB3kwsXXN2U2sEIl2Ba6sJ6IwPeEiN7o09ULIv2NkMlaADtROndnJu/dbj3JsI4TSypYNr
	S26w=
X-Gm-Gg: ASbGncv/J2IQOW2ip+xQO2g5GEVFk0OKslV/ED72nIgiCG5KY+BszzSArPYFd65SrNu
	woqjaHP0h7QbUWGvDB0n0Whw3hNbDVyN07HyeyLBtQxNdleepSBhZG+pQs27NhtPFRl/8/5mGbd
	2rWh9QbS5jwSMYRWR3yhvZQEe7pKSHlhHgOdFkoEe2EAEM8uKGxVHniwr9zrENZEqAvg5VTdqpZ
	nqIFqBelv5cDFbGNCsEOqwRGttxTnARHbrI6sS1dQqiiXWpk/DF2Q2G8jNyAO56CpHaO6y/CrAZ
	EqdHbQ/xeDQ/DqybqZx0Isqg/M3vEoxJ3DlF38WLPAY8aR25eBQtk7GkfVALTDsXWOk8FhNi/KJ
	blmWqdv6RMwrgAzSdyKXQacYPB7Sbn8zIlgzWPafFait6cMk=
X-Google-Smtp-Source: AGHT+IGQhIvVILD/mLsyDr/e8gz5x5RpAZerphy1lrk8w1UAU+KzQbiDkF+IA9zWhP++hZpQROFQYg==
X-Received: by 2002:a05:6000:2313:b0:3a5:2d42:aa17 with SMTP id ffacd0b85a97d-3a572e79c14mr8398070f8f.31.1750078776746;
        Mon, 16 Jun 2025 05:59:36 -0700 (PDT)
Message-ID: 
Date: Mon, 16 Jun 2025 14:59:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v6 1/7] x86: suppress ERMS for internal use when
 MISC_ENABLE.FAST_STRING is clear
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
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

Before we start actually adjusting behavior when ERMS is available,
follow Linux commit 161ec53c702c ("x86, mem, intel: Initialize Enhanced
REP MOVSB/STOSB") and zap the CPUID-derived feature flag when the MSR
bit is clear. Don't extend the artificial clearing to guest view,
though: Guests can take their own decision in this regard, as they can
read (most of) MISC_ENABLE.

Signed-off-by: Jan Beulich 
---
TBD: Would be nice if "cpuid=no-erms" propagated to guest view (for
     "cpuid=" generally meaning to affect guests as well as Xen), but
     since both disabling paths use setup_clear_cpu_cap() they're
     indistinguishable in guest_common_feature_adjustments(). A separate
     boolean could take care of this, but would look clumsy to me.
---
v5: Correct guest_common_max_feature_adjustments() addition.
v4: Also adjust guest_common_max_feature_adjustments().
v3: New.

--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -366,8 +366,18 @@ static void cf_check early_init_intel(st
 		paddr_bits = 36;
 
 	if (c == &boot_cpu_data) {
+		uint64_t misc_enable;
+
 		check_memory_type_self_snoop_errata();
 
+		/*
+		 * If fast string is not enabled in IA32_MISC_ENABLE for any reason,
+		 * clear the enhanced fast string CPU capability.
+		 */
+		rdmsrl(MSR_IA32_MISC_ENABLE, misc_enable);
+		if (!(misc_enable & MSR_IA32_MISC_ENABLE_FAST_STRING))
+			setup_clear_cpu_cap(X86_FEATURE_ERMS);
+
 		intel_init_levelling();
 	}
 
--- a/xen/arch/x86/cpu-policy.c
+++ b/xen/arch/x86/cpu-policy.c
@@ -487,6 +487,12 @@ static void __init guest_common_max_feat
      */
     if ( test_bit(X86_FEATURE_RTM, fs) )
         __set_bit(X86_FEATURE_RTM_ALWAYS_ABORT, fs);
+
+    /*
+     * We expose MISC_ENABLE to guests, so our internal clearing of ERMS when
+     * FAST_STRING is not set should not affect the view of migrating-in guests.
+     */
+    __set_bit(X86_FEATURE_ERMS, fs);
 }
 
 static void __init guest_common_default_feature_adjustments(uint32_t *fs)
@@ -567,6 +573,16 @@ static void __init guest_common_default_
         __clear_bit(X86_FEATURE_RTM, fs);
         __set_bit(X86_FEATURE_RTM_ALWAYS_ABORT, fs);
     }
+
+    /*
+     * We expose MISC_ENABLE to guests, so our internal clearing of ERMS when
+     * FAST_STRING is not set should not propagate to guest view.  Guests can
+     * judge on their own whether to ignore the CPUID bit when the MSR bit is
+     * clear.  The bit being uniformly set in the max policies, we only need
+     * to clear it here (if hardware doesn't have it).
+     */
+    if ( !raw_cpu_policy.feat.erms )
+        __clear_bit(X86_FEATURE_ERMS, fs);
 }
 
 static void __init guest_common_feature_adjustments(uint32_t *fs)
--- a/xen/arch/x86/include/asm/msr-index.h
+++ b/xen/arch/x86/include/asm/msr-index.h
@@ -493,6 +493,7 @@
 #define MSR_IA32_THERM_INTERRUPT	0x0000019b
 #define MSR_IA32_THERM_STATUS		0x0000019c
 #define MSR_IA32_MISC_ENABLE		0x000001a0
+#define MSR_IA32_MISC_ENABLE_FAST_STRING  (1<<0)
 #define MSR_IA32_MISC_ENABLE_PERF_AVAIL   (1<<7)
 #define MSR_IA32_MISC_ENABLE_BTS_UNAVAIL  (1<<11)
 #define MSR_IA32_MISC_ENABLE_PEBS_UNAVAIL (1<<12)



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 13:00:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 13:00:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017206.1394178 (Exim 4.92)
	(envelope-from )
	id 1uR9RS-0004Zc-Vg; Mon, 16 Jun 2025 13:00:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017206.1394178; Mon, 16 Jun 2025 13: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 1uR9RS-0004Z5-Sk; Mon, 16 Jun 2025 13:00:02 +0000
Received: by outflank-mailman (input) for mailman id 1017206;
 Mon, 16 Jun 2025 13: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 1uR9RR-0003pW-RX
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 13:00:01 +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 cf83a78b-4ab1-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 15:00:00 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3a510432236so3313320f8f.0
 for ; Mon, 16 Jun 2025 06:00:00 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2365d88f447sm60051525ad.45.2025.06.16.05.59.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Jun 2025 05:59:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cf83a78b-4ab1-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750078799; x=1750683599; 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=+5Soi2kJcSJ+g49AA3Ctrt1tH15NUClp6ljEBqxL0MA=;
        b=CJ6AGN+AdNR7G/ELf5OxfU33EakJzDn6LwM1ZTbPHJpUUWW4PxNf2+0ViZAClRnGfS
         mD5na5OD8xFvYnL4f03GNO5msueXNppRgHujQ4oc4V6Qg0PCBKstg57BGO97l7RgdYWD
         ajvRg4b2R3YHIh5sseUAh3HiUfliYTudWNs+ryeloq9itqUYWCyrPARNFe4Z9IxRmX5n
         6qxbAYHCRZ7mFBtmP/pf5Hiu3n51l2a4gjc60X7AcwePo+y0kvV2Xvh+qZpT7yTqkQjt
         51SP3xY6ven9wCi1LCRlHXPY0xZ9rZ6WTFIrialpOCp2OsitEZEGHdbpeJ5Zl20dCc71
         IOVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750078799; x=1750683599;
        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=+5Soi2kJcSJ+g49AA3Ctrt1tH15NUClp6ljEBqxL0MA=;
        b=gmi3SEgKBWNhCtHYjKaFI2xGzqvVMQDyI41zl2+16cNL+s3gmi/WaWe5yK9B8NwkkM
         X4NWWXw0OpeOOuGZjGFBJDuSflz9ydmEb9tCjAWFquHon6vY4dQPns3zkiBZAWQcz5W1
         xgBQRhDgAI0RwmRQ3QMPhJnO/SPvpoIT4Gde+CC54k5B4suIwuppPJJEISjRNnCziPOV
         /XpDYFKgjhARmpGP5hUsK36yaHM/P/J9DkLYeLYJZR1K4d6xtTAdzlOkY+J4NorAnc+Z
         c9W0D70jSR5Xvt585rNGzqaqJXY5+lxoNmPtaxv5FzWnX0QQH/0VxpjE35yQ+R50sJKT
         rZmg==
X-Gm-Message-State: AOJu0YwEcsRVnCEg9FlCOJe0EzjP4Mp2WsvTkq2FMUwDG3OMGRhm3kwK
	Zn2XK/Dear0CtukE0DfpLUeLqtKOPExIGQUGNHKvkr20KWMZmK+rxXLyVbKQB4PGFBwKwpSNOL0
	dOUM=
X-Gm-Gg: ASbGncsn9aZ9LH/58uBOU+Foj9F0EiNd2tur/YYCzhpataPLDpJKAJ9wrabq87DZu/z
	ohKrejbeox0sH8NHjDy+S87NqXkzkiJPNkTilc1mJAnnJP6tgCmefcgElnQCEpQVXv62v3IKpVG
	q2omZYuqCrvnDZEJ2xtybNUPNTHldOxmab/EW96Kxpw5fbzQ4eFOfQDig2KGe2r7mCmir2B6j2q
	TPtghu8sONpbRutzW3KOksfknKCnRirQO9Kiq59AUAzT1MROb6DfUE5LyYbdhVacVvO5PFUwPo7
	sQoyrmpXim+SiQVNaXSiYH7tGAnpNoq88w+Ql0ajSpLNzcMUUrWzvPG4b43phuAObc/7vghMaMq
	IL0m+3fEs9Rd7kVHWeokZrHTaT2v3qhin9Fov3CaiXfE1dfg=
X-Google-Smtp-Source: AGHT+IHZNO5ywfqqom9NEqGjAoqenIhMq3NeePncRuDPT2gLtO+3sY5htYXdBhtw100vKrKUt+p1pw==
X-Received: by 2002:a05:6000:3112:b0:3a4:e480:b5df with SMTP id ffacd0b85a97d-3a572e79749mr8135800f8f.44.1750078799533;
        Mon, 16 Jun 2025 05:59:59 -0700 (PDT)
Message-ID: <658802b4-1847-455d-98ad-244d97fddc5e@suse.com>
Date: Mon, 16 Jun 2025 14:59:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v6 2/7] x86/alternatives: serialize after (self-)modifying
 code
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
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

While supposedly safe via enforcing a control flow change when modifying
already prefetched code, it may not really be. Afaik a request is
pending to drop the first of the two options in the SDM's "Handling
Self- and Cross-Modifying Code" section (still present there as of
version 087). Insert a serializing instruction there, and remove the
"noinline" in exchange.

Signed-off-by: Jan Beulich 
---
Strictly speaking with LIVEPATCH=n the if() (but not its body) is dead
code. Adding IS_ENABLED(CONFIG_LIVEPATCH) would feel quite a bit like
extra clutter, though. Plus Misra rule 2.2 is globally deviated anyway.
---
v6: Split off. Extend commentary. Load deterministic value into CR2.
    Drop "noinline".

--- a/xen/arch/x86/alternative.c
+++ b/xen/arch/x86/alternative.c
@@ -194,13 +194,18 @@ void *place_ret(void *ptr)
  * You should run this with interrupts disabled or on code that is not
  * executing.
  *
- * "noinline" to cause control flow change and thus invalidate I$ and
- * cause refetch after modification.
+ * While the SDM continues to suggest using "noinline" would be sufficient, it
+ * may not be, e.g. due to errata.  Issue a serializing insn afterwards, unless
+ * this is for live-patching, where we modify code before it goes live.  Issue
+ * a serializing insn which is unlikely to be intercepted by a hypervisor, in
+ * case we run virtualized ourselves.
  */
-static void init_or_livepatch noinline
+static void init_or_livepatch
 text_poke(void *addr, const void *opcode, size_t len)
 {
     memcpy(addr, opcode, len);
+    if ( system_state < SYS_STATE_active )
+        asm volatile ( "mov %0, %%cr2" :: "r" (0L) : "memory" );
 }
 
 extern void *const __initdata_cf_clobber_start[];



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 13:00:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 13:00:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017217.1394189 (Exim 4.92)
	(envelope-from )
	id 1uR9Rw-0005j8-CE; Mon, 16 Jun 2025 13:00:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017217.1394189; Mon, 16 Jun 2025 13:00: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 1uR9Rw-0005j1-9O; Mon, 16 Jun 2025 13:00:32 +0000
Received: by outflank-mailman (input) for mailman id 1017217;
 Mon, 16 Jun 2025 13: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 1uR9Rv-0005HG-2k
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 13:00:31 +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 e1a5f503-4ab1-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 15:00:30 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a575a988f9so1326015f8f.0
 for ; Mon, 16 Jun 2025 06:00:30 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b2fe164ca5fsm6787021a12.34.2025.06.16.06.00.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Jun 2025 06:00:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e1a5f503-4ab1-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750078830; x=1750683630; 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=pl2MdiB+kJYOREm+k9B0Yw8rIzN4HAkJgHoxKayTGVI=;
        b=NOlU31PpwkAnjBx12zZ7FxFoJ5lxRy345s0PPceqfm7A7hpIODhSdF+AztBnFN+DzZ
         5KEbYvDgNyMBHc//w7OO9Ao4QEDSDPER69Ux5wbAXcP+5ZimofXQ1OLt20ERCZnz6Zg3
         O5a8+zUqGRQhtgyCQllF7LMfGm8cH6vHjhAOh3i5jUDmmzqQzHe9i7GjRh2beXC4s8rE
         ajWpQ9k3W+BGj1pAPUzJVJYi2yvOFlfSSUaPq6HT2RB/dBXAvWHIpkvTKBICpA0v+QEr
         Bi8NQvMNK3oBohNs2Hi/Dvyb0HX1VCvI4pAo1NLUES/fBPv9mICFcyeTOZHskeln7/lT
         YfXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750078830; x=1750683630;
        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=pl2MdiB+kJYOREm+k9B0Yw8rIzN4HAkJgHoxKayTGVI=;
        b=TNHnCKT2HKhZOWTB+IMQaeCejnm174V4co9oHOScw/iHdV08bsqCKbg/fsJ+SeP3IJ
         IhAxD1c0/F9ECG+vgTNLmw7XdTJTajG9wwvuf6G+ML72lK7MrdMZborcGn/9zen/paXK
         Mo3yBxHlvJ6lBDG8H0q0igVID+RjwOtMigguJtDdCQgSC1TbERY9Mxntw9XRZpM+WbbO
         EFU/eSKkGUdyPAqPJNMC1Wble4bUMTaoPifsN1tKeEuJ/fA5dgP1IY5EkxEFBs2BxJQ+
         uIRMhX7lyCwgldUeVTdrvNgNYu1xMYtIxIpWSmYvRJlkWVvsRMSt1jgKBsA0XJAPaInU
         JWZg==
X-Gm-Message-State: AOJu0YwbdUjxUnKWG4EXMuxVVdqV0Tt8lF/EFq7gC7MkpIFAIs8m469O
	v4YW3/6wGbTVfdb7kb9eVEr1NH9hWxrPYsqtF8C/QpLCRaOnnIFOmyu7+73/qwfq0k9QrFRuG2o
	5Kzc=
X-Gm-Gg: ASbGncsCqIPwgxInVnqWR4OAbxZczu2/ty935OfvezKOOtqDL9uaSVzKzo4kiY5C1aV
	nallxkXEvG6Xgbfz5/2uuyTrwh7J7lEVsI++qyF+opRd7xjE/jRXv3Iz4XklwJNSc9XHdawPvXE
	/dnaUrAAWVf+a8mxO5DnqmCqWHDuZrc/wu/lzPyj5+tRJbDbKybm9UNm3oSnxj8GnZQHLdQZmW6
	8R6fgb1fsOgMpFBWSlbyP5H4ttSsakepggj06bWdL6qpaulBsSWxQqKm6AlwQMwb+iu4MitmXT9
	KwmIT1HXyUQlJfWflLrUd4ze9xB4pNCb6adY+QURuAhXGYneMEauwfoJPknliErmxaYgJSkYib/
	tI8YcaTrj++UKJcSrkhL1oRsBraNRSnD2x9Ycj/U0hGM7ktU=
X-Google-Smtp-Source: AGHT+IGq3KMYoJsXLu0qEqM3HhiyH8Fd/f20KFa779MiA8R/Ui7xgF7YCvdIS6kLCWefSfxrnkPBjg==
X-Received: by 2002:a05:6000:2881:b0:3a4:eef5:ae26 with SMTP id ffacd0b85a97d-3a572e9e42dmr5544178f8f.55.1750078829855;
        Mon, 16 Jun 2025 06:00:29 -0700 (PDT)
Message-ID: 
Date: Mon, 16 Jun 2025 15:00:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v6 3/7] x86: re-work memset()
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
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

Move the function to its own assembly file. Having it in C just for the
entire body to be an asm() isn't really helpful. Then have two flavors:
A "basic" version using qword steps for the bulk of the operation, and an
ERMS version for modern hardware, to be substituted in via alternatives
patching.

For RET to be usable in an alternative's replacement code, extend the
CALL/JMP patching to cover the case of "JMP __x86_return_thunk" coming
last in replacement code.

Signed-off-by: Jan Beulich 
---
We may want to consider branching over the REP STOSQ as well, if the
number of qwords turns out to be zero.
We may also want to consider using non-REP STOS{L,W,B} for the tail.
---
v5: Re-base.
v4: Use %r8 instead of %rsi in a few places.
v3: Re-base.

--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_RETURN_THUNK) += indirect-t
 obj-$(CONFIG_PV) += ioport_emulate.o
 obj-y += irq.o
 obj-$(CONFIG_KEXEC) += machine_kexec.o
+obj-y += memset.o
 obj-y += mm.o x86_64/mm.o
 obj-$(CONFIG_VM_EVENT) += monitor.o
 obj-y += mpparse.o
--- a/xen/arch/x86/alternative.c
+++ b/xen/arch/x86/alternative.c
@@ -351,6 +351,12 @@ static int init_or_livepatch _apply_alte
         /* 0xe8/0xe9 are relative branches; fix the offset. */
         if ( a->repl_len >= 5 && (*buf & 0xfe) == 0xe8 )
             *(int32_t *)(buf + 1) += repl - orig;
+        else if ( IS_ENABLED(CONFIG_RETURN_THUNK) &&
+                  a->repl_len > 5 && buf[a->repl_len - 5] == 0xe9 &&
+                  ((long)repl + a->repl_len +
+                   *(int32_t *)(buf + a->repl_len - 4) ==
+                   (long)__x86_return_thunk) )
+            *(int32_t *)(buf + a->repl_len - 4) += repl - orig;
 
         a->priv = 1;
 
--- /dev/null
+++ b/xen/arch/x86/memset.S
@@ -0,0 +1,30 @@
+#include 
+
+.macro memset
+        and     $7, %edx
+        shr     $3, %rcx
+        movzbl  %sil, %esi
+        mov     $0x0101010101010101, %rax
+        imul    %rsi, %rax
+        mov     %rdi, %r8
+        rep stosq
+        or      %edx, %ecx
+        jz      0f
+        rep stosb
+0:
+        mov     %r8, %rax
+        RET
+.endm
+
+.macro memset_erms
+        mov     %esi, %eax
+        mov     %rdi, %r8
+        rep stosb
+        mov     %r8, %rax
+        RET
+.endm
+
+FUNC(memset)
+        mov     %rdx, %rcx
+        ALTERNATIVE memset, memset_erms, X86_FEATURE_ERMS
+END(memset)
--- a/xen/arch/x86/string.c
+++ b/xen/arch/x86/string.c
@@ -22,19 +22,6 @@ void *(memcpy)(void *dest, const void *s
     return dest;
 }
 
-void *(memset)(void *s, int c, size_t n)
-{
-    long d0, d1;
-
-    asm volatile (
-        "rep stosb"
-        : "=&c" (d0), "=&D" (d1)
-        : "a" (c), "1" (s), "0" (n)
-        : "memory");
-
-    return s;
-}
-
 void *(memmove)(void *dest, const void *src, size_t n)
 {
     long d0, d1, d2;



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 13:01:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 13:01:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017228.1394200 (Exim 4.92)
	(envelope-from )
	id 1uR9SU-0006PK-LN; Mon, 16 Jun 2025 13:01:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017228.1394200; Mon, 16 Jun 2025 13:01:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uR9SU-0006PD-Gf; Mon, 16 Jun 2025 13:01:06 +0000
Received: by outflank-mailman (input) for mailman id 1017228;
 Mon, 16 Jun 2025 13: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 1uR9SU-0003pW-7t
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 13:01:06 +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 f5f27c6f-4ab1-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 15:01:04 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3a365a6804eso3189285f8f.3
 for ; Mon, 16 Jun 2025 06:01:04 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-748900d7e0asm6939967b3a.174.2025.06.16.06.01.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Jun 2025 06:01:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f5f27c6f-4ab1-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750078864; x=1750683664; 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=WQcA0jk9C0hbnGwgMgyk6/kBDd3xLT1I9c+U8NiS7QA=;
        b=EnFl/Lo0Dsq2zXASpFbbOcqQE7FWxD3vEprjfbu910qv3pzyDrXPENfEQg025sbWME
         dw/7C5hmV/a8630+Et0F162h2zMoOl11xp8v5DwR/cjYA8oly+wbKndBrFaGu7U1EjvH
         HeTud35xSWx+zHvPW47mBC9ukQFsMw2P29Iolwacxd+B26vFTR5T1DqoswaNnNRXtk0c
         3Pf0bAi/ATh1gOEjegBOLXq7NaY8z3NNalzIAI2nsHMKC4hMwk81fMY8FdRdB3QBdDLT
         x2Dkh6Z36fJw0cwupXA8qejtwFdMapuibYslTzjv6SIa2EqAsgeqsYClblKMKG/geuri
         ibDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750078864; x=1750683664;
        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=WQcA0jk9C0hbnGwgMgyk6/kBDd3xLT1I9c+U8NiS7QA=;
        b=Na4jqUljAxMDCdy5lNlieASPD89SIghyYMzTTzSiiwbgtGE3pDDiag26ESyP1g7Fj+
         TwZTNA7rORDC13mnIWnD5ZMyABSjgMpsHUui/vGyuBJQCu96NoaszZr8oSbja/s8A440
         fpTKLrlx4N7//eEYaWNAB2dz4xcJ1bJX0RRnO+ef81bok+QJDjev9PVLcsedydNl2yIO
         dA62ZZVrUAnHW2c0Tz8tWXZw0he7EBH0t9s3htisebBthToJvA/pW0gN4HlGZGTQGdvr
         yCyIIXU5zvEt7u0G6aeff1F/BZsipewavs4QpnG/5egs4o6qLjv2vBSvsW5IGf70hX44
         mEzQ==
X-Gm-Message-State: AOJu0Yy2uAlgtVmAGZtuGHggx72MztRt8k0+0NTs5lcnkWKSg+RAmOmy
	vl2OAOzrwT8X7Xt+hRuji62I0OLETyqtdo/U8/8AC0IzFcd2faKPyoYRgnN00815AoyTYRSRanR
	ikQ4=
X-Gm-Gg: ASbGnctQcwgFJvVdt3cyKgYzrwjbCxuujbedFllGjpUd3qJhmxicWUhebcII0Xi2ajL
	RZs1MqOhA4I8QDFYf55mazbzsC62KDugdgzPLVtbevgzZXO+DhJkcEGxqafu5a2jE5zazXkL7BM
	OIGQG6WM7tzdhZUGyRv5ScfBvDf1et+ffuxV5e83JNM5KtWDKiZwXzkuC4Lb4Zr7NbfELlLi+zI
	WUI8wJk66w7Wwy8hmGFAehz9qROJGUmC1oVf9VUbfSL1ds7JZtgQVL1BARlvlU+QLGR61S5AXAi
	fuvQVdvN7Imf/AojWd3l7mbs9wHLgQSkBjVvFdQ92Y6tWNbM9ioTZUepZWHE6vGif0cEyrvCnGK
	CGRcXccz8xiyXbvl8vSJsxmSxhbhxY82vc7uKmhhNpUxuBVY=
X-Google-Smtp-Source: AGHT+IFf29AbfGPH26yutrwPeNXyRBv8TOMvSaOgP0uOAz18ppyA5lsUOZBFuNdhP7jBbzTRijBxzQ==
X-Received: by 2002:a05:6000:290a:b0:3a4:f520:8bfc with SMTP id ffacd0b85a97d-3a5723a3b03mr6780273f8f.36.1750078863555;
        Mon, 16 Jun 2025 06:01:03 -0700 (PDT)
Message-ID: <991c9caf-c7b6-4e1f-9855-5b2930b7989c@suse.com>
Date: Mon, 16 Jun 2025 15:00:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v6 4/7] x86: re-work memcpy()
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
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

Move the function to its own assembly file. Having it in C just for the
entire body to be an asm() isn't really helpful. Then have two flavors:
A "basic" version using qword steps for the bulk of the operation, and an
ERMS version for modern hardware, to be substituted in via alternatives
patching.

Alternatives patching, however, requires an extra precaution: It uses
memcpy() itself, and hence the function may patch itself. Luckily the
patched-in code only replaces the prolog of the original function. Make
sure this remains this way.

Signed-off-by: Jan Beulich 
Reviewed-by: Teddy Astie 
---
We may want to consider branching over the REP MOVSQ as well, if the
number of qwords turns out to be zero.
We may also want to consider using non-REP MOVS{L,W,B} for the tail.

TBD: We may further need a workaround similar to Linux'es 8ca97812c3c8
     ("x86/mce: Work around an erratum on fast string copy
     instructions").

TBD: Some older AMD CPUs have an issue with REP MOVS when source and
     destination are misaligned with one another (modulo 32?), which may
     require a separate memcpy() flavor.
---
v6: Move alternatives.c change to a separate patch.
v5: Re-base.
v4: Use CR2 write as serializing insn, and limit its use to boot time.
v3: Re-base.

--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_RETURN_THUNK) += indirect-t
 obj-$(CONFIG_PV) += ioport_emulate.o
 obj-y += irq.o
 obj-$(CONFIG_KEXEC) += machine_kexec.o
+obj-y += memcpy.o
 obj-y += memset.o
 obj-y += mm.o x86_64/mm.o
 obj-$(CONFIG_VM_EVENT) += monitor.o
--- /dev/null
+++ b/xen/arch/x86/memcpy.S
@@ -0,0 +1,20 @@
+#include 
+
+FUNC(memcpy)
+        mov     %rdx, %rcx
+        mov     %rdi, %rax
+        /*
+         * We need to be careful here: memcpy() is involved in alternatives
+         * patching, so the code doing the actual copying (i.e. past setting
+         * up registers) may not be subject to patching (unless further
+         * precautions were taken).
+         */
+        ALTERNATIVE "and $7, %edx; shr $3, %rcx", \
+                    STR(rep movsb; RET), X86_FEATURE_ERMS
+        rep movsq
+        or      %edx, %ecx
+        jz      1f
+        rep movsb
+1:
+        RET
+END(memcpy)
--- a/xen/arch/x86/string.c
+++ b/xen/arch/x86/string.c
@@ -7,21 +7,6 @@
 
 #include 
 
-void *(memcpy)(void *dest, const void *src, size_t n)
-{
-    long d0, d1, d2;
-
-    asm volatile (
-        "   rep ; movs"__OS" ; "
-        "   mov %k4,%k3      ; "
-        "   rep ; movsb        "
-        : "=&c" (d0), "=&D" (d1), "=&S" (d2)
-        : "0" (n/BYTES_PER_LONG), "r" (n%BYTES_PER_LONG), "1" (dest), "2" (src)
-        : "memory" );
-
-    return dest;
-}
-
 void *(memmove)(void *dest, const void *src, size_t n)
 {
     long d0, d1, d2;



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 13:01:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 13:01:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017235.1394210 (Exim 4.92)
	(envelope-from )
	id 1uR9TK-00073I-Tv; Mon, 16 Jun 2025 13:01:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017235.1394210; Mon, 16 Jun 2025 13: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 1uR9TK-00073B-Pg; Mon, 16 Jun 2025 13:01:58 +0000
Received: by outflank-mailman (input) for mailman id 1017235;
 Mon, 16 Jun 2025 13:01: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 1uR9TK-00072w-9k
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 13:01:58 +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 1578a124-4ab2-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 15:01:57 +0200 (CEST)
Received: by mail-lf1-x130.google.com with SMTP id
 2adb3069b0e04-553be4d2fbfso1375852e87.0
 for ; Mon, 16 Jun 2025 06:01:57 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-748900b0d07sm6718883b3a.114.2025.06.16.06.01.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Jun 2025 06:01:53 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1578a124-4ab2-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750078917; x=1750683717; 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=uAx+h4vdQMnFmuPeDTCptQ0FqB53/bxqCnS75yppj5g=;
        b=WZ0SPab/uQmIKxX5ZZRbfrI/v6cqQ1TP2w15L+7hmDvYdhSGCy+XTmOaAWH/hQ2ue7
         w+Iftj5wgLNCZQgnr8LJhA14RW7fNWLUvC56RTOtNayx3gEbDxhu8rOHw4TAqpNWUVvS
         lJL5CmcyE08DczrxF4VOcqmSZBEwMXww1PLFqOw5kOpqpTSmSqOTPw6vKByra4ym8p+z
         qkhxb2L3NJmqbOGPP3zKW/RnvEzFppeBYvFfoqRxYj5Vn9pV0R+V1D6+g29XJU1CuBTS
         dNfxUON7tpl+Bw/+MCzyEXuYpOdT3YXlDjwvMrWu4IXZQq8T5Q4tsAmEuY1jdzieX84S
         KcRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750078917; x=1750683717;
        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=uAx+h4vdQMnFmuPeDTCptQ0FqB53/bxqCnS75yppj5g=;
        b=C8yyh7NXQQ7AyapY7r4pHMapzWIjD8zas0VL+lbBwvOuvh0Vt38p6uvMDU5cIaajNf
         +v+lEt7rvDS4sTeLy6BRp8FhsGV0f5cxVBmC8MtIOiq03icTnZCjN+ewOSyP/n3/Auge
         POnV57ByLrI6sndkZ2SBuky+Bh2cs0UZt8WCdL+O3+yE0GTLqIITzgrI5PJapFaU+nWP
         B8VIH/Q6+Sz81U/JksFS1Wg1XTeaNbtASE9yu8yhlPBMzA4+ZdRRgti9Uz+fFvef24k2
         ILIgdiL9QaTTMYhPnw4kqUOM1V9Mh0ec5e+VT9x8yNaDjrWZ6C/1f+YI3uSPz9VsU4/1
         ShmA==
X-Gm-Message-State: AOJu0Yzto8meqCdu/EUiXrOIHEwGrbVA7PgmnHzUpHXUZG4/wVyxeW71
	ZeP/VDJlAMgOWuSZMWup4ZbNevhKEAKTjIUPVLNJlnh8yDrU4S0BWwJggRSLVG91Fqd5TtbXZQO
	lAQI=
X-Gm-Gg: ASbGnctVF8CVO3oImWFrfybn9HS3uHI04NqmGnoXjiRSTORcyuHPtWYHgWOjUbjyJk7
	6XjihcFjic96kuWrSYK+uXuxhz7ostqqSHUUqAPlc1PBLFTpXGnX9TDpfSr0o3pMeRDWc3tsO8v
	XZZRmcu5B3x/joj2cXUTk88uMy8D1+nRrIEL5yGv7DhwsK17IFvawnOyC+G5wq94La7I2uYZJJ7
	jgSfkgyKUbhgE1Mle9Ei/9PDnG90R8Ud/iwh3NhHfB8zfnCbjGxWYzRSfSkKV/ebU21+SbNd1YZ
	0yhHUnDcTBOH6+cp8QOJfbif78UF9ON/SyNnx4hYSdOqe9T2GC3lRDyrxgeS1xvNuUHoHcj0v7C
	1kTnh6TT82Iii6t459Hv8wJe0HlZMi6+OdKMZiSowupZ5WctwB21F7fA12w==
X-Google-Smtp-Source: AGHT+IH/LQefGMLIyKc9oY2HjcKqXbVrCil1vf/R5BUo8lps01W8HAeW7Hf3ZcEI6+G7CvfD74aofA==
X-Received: by 2002:a05:6512:308b:b0:553:2438:8d02 with SMTP id 2adb3069b0e04-553b6f32e7emr2019776e87.47.1750078914340;
        Mon, 16 Jun 2025 06:01:54 -0700 (PDT)
Message-ID: 
Date: Mon, 16 Jun 2025 15:01:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v6 6/7] x86: introduce "hot" and "cold" page clearing
 functions
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
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

The present clear_page_sse2() is useful in case a page isn't going to
get touched again soon, or if we want to limit churn on the caches.
Amend it by alternatively using CLZERO, which has been found to be quite
a bit faster on Zen2 hardware at least. Note that to use CLZERO, we need
to know the cache line size, and hence a feature dependency on CLFLUSH
gets introduced.

For cases where latency is the most important aspect, or when it is
expected that sufficiently large parts of a page will get accessed again
soon after the clearing, introduce a "hot" alternative. Again use
alternatives patching to select between a "legacy" and an ERMS variant.

Don't switch any callers just yet - this will be the subject of
subsequent changes.

Signed-off-by: Jan Beulich 
---
v5: Re-base.
v3: Re-base.
v2: New.
---
Note: Ankur indicates that for ~L3-size or larger regions MOVNT/CLZERO
      is better even latency-wise.

--- a/xen/arch/x86/clear_page.S
+++ b/xen/arch/x86/clear_page.S
@@ -5,7 +5,7 @@
 #include 
 #include 
 
-FUNC(clear_page_sse2)
+        .macro clear_page_sse2
         mov     $PAGE_SIZE/32, %ecx
         xor     %eax,%eax
 
@@ -19,4 +19,42 @@ FUNC(clear_page_sse2)
 
         sfence
         RET
-END(clear_page_sse2)
+        .endm
+
+        .macro clear_page_clzero
+        mov     %rdi, %rax
+        mov     $PAGE_SIZE/64, %ecx
+        .globl clear_page_clzero_post_count
+clear_page_clzero_post_count:
+
+0:      clzero
+        sub     $-64, %rax
+        .globl clear_page_clzero_post_neg_size
+clear_page_clzero_post_neg_size:
+        sub     $1, %ecx
+        jnz     0b
+
+        sfence
+        RET
+        .endm
+
+FUNC(clear_page_cold)
+        ALTERNATIVE clear_page_sse2, clear_page_clzero, X86_FEATURE_CLZERO
+END(clear_page_cold)
+
+        .macro clear_page_stosb
+        mov     $PAGE_SIZE, %ecx
+        xor     %eax,%eax
+        rep stosb
+        .endm
+
+        .macro clear_page_stosq
+        mov     $PAGE_SIZE/8, %ecx
+        xor     %eax, %eax
+        rep stosq
+        .endm
+
+FUNC(clear_page_hot)
+        ALTERNATIVE clear_page_stosq, clear_page_stosb, X86_FEATURE_ERMS
+        RET
+END(clear_page_hot)
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -60,6 +60,9 @@ DEFINE_PER_CPU(bool, full_gdt_loaded);
 
 DEFINE_PER_CPU(uint32_t, pkrs);
 
+extern uint32_t clear_page_clzero_post_count[];
+extern int8_t clear_page_clzero_post_neg_size[];
+
 void __init setup_clear_cpu_cap(unsigned int cap)
 {
 	const uint32_t *dfs;
@@ -357,8 +360,38 @@ void __init early_cpu_init(bool verbose)
 
 	edx &= ~cleared_caps[FEATURESET_1d];
 	ecx &= ~cleared_caps[FEATURESET_1c];
-	if (edx & cpufeat_mask(X86_FEATURE_CLFLUSH))
-		c->x86_cache_alignment = ((ebx >> 8) & 0xff) * 8;
+	if (edx & cpufeat_mask(X86_FEATURE_CLFLUSH)) {
+		unsigned int size = ((ebx >> 8) & 0xff) * 8;
+
+		c->x86_cache_alignment = size;
+
+		/*
+		 * Patch in parameters of clear_page_cold()'s CLZERO
+		 * alternative. Note that for now we cap this at 128 bytes.
+		 * Larger cache line sizes would still be dealt with
+		 * correctly, but would cause redundant work done.
+		 */
+		if (size > 128)
+			size = 128;
+		if (size && !(size & (size - 1))) {
+			/*
+			 * Need to play some games to keep the compiler from
+			 * recognizing the negative array index as being out
+			 * of bounds. The labels in assembler code really are
+			 * _after_ the locations to be patched, so the
+			 * negative index is intentional.
+			 */
+			uint32_t *pcount = clear_page_clzero_post_count;
+			int8_t *neg_size = clear_page_clzero_post_neg_size;
+
+			OPTIMIZER_HIDE_VAR(pcount);
+			OPTIMIZER_HIDE_VAR(neg_size);
+			pcount[-1] = PAGE_SIZE / size;
+			neg_size[-1] = -size;
+		}
+		else
+			setup_clear_cpu_cap(X86_FEATURE_CLZERO);
+	}
 	/* Leaf 0x1 capabilities filled in early for Xen. */
 	c->x86_capability[FEATURESET_1d] = edx;
 	c->x86_capability[FEATURESET_1c] = ecx;
--- a/xen/arch/x86/include/asm/asm-defns.h
+++ b/xen/arch/x86/include/asm/asm-defns.h
@@ -1,5 +1,9 @@
 #include 
 
+.macro clzero
+    .byte 0x0f, 0x01, 0xfc
+.endm
+
 /*
  * Call a noreturn function.  This could be JMP, but CALL results in a more
  * helpful backtrace.  BUG is to catch functions which do decide to return...
--- a/xen/arch/x86/include/asm/page.h
+++ b/xen/arch/x86/include/asm/page.h
@@ -219,10 +219,11 @@ typedef struct { u64 pfn; } pagetable_t;
 #define pagetable_from_paddr(p) pagetable_from_pfn((p)>>PAGE_SHIFT)
 #define pagetable_null()        pagetable_from_pfn(0)
 
-void clear_page_sse2(void *pg);
+void clear_page_hot(void *pg);
+void clear_page_cold(void *pg);
 void copy_page_sse2(void *to, const void *from);
 
-#define clear_page(_p)      clear_page_sse2(_p)
+#define clear_page(_p)      clear_page_cold(_p)
 #define copy_page(_t, _f)   copy_page_sse2(_t, _f)
 
 /* Convert between Xen-heap virtual addresses and machine addresses. */
--- a/xen/tools/gen-cpuid.py
+++ b/xen/tools/gen-cpuid.py
@@ -212,6 +212,10 @@ def crunch_numbers(state):
         # the first place.
         APIC: [X2APIC, TSC_DEADLINE, EXTAPIC],
 
+        # The CLZERO insn requires a means to determine the cache line size,
+        # which is tied to the CLFLUSH insn.
+        CLFLUSH: [CLZERO],
+
         # AMD built MMXExtentions and 3DNow as extentions to MMX.
         MMX: [MMXEXT, _3DNOW],
 



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 13:02:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 13:02:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017243.1394218 (Exim 4.92)
	(envelope-from )
	id 1uR9UH-0007Z2-5V; Mon, 16 Jun 2025 13:02:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017243.1394218; Mon, 16 Jun 2025 13:02:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uR9UH-0007Yv-2i; Mon, 16 Jun 2025 13:02:57 +0000
Received: by outflank-mailman (input) for mailman id 1017243;
 Mon, 16 Jun 2025 13:02: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 1uR9UF-0007Yl-Cd
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 13:02:55 +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 3628b433-4ab2-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 15:02:52 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3a4ef2c2ef3so3731840f8f.2
 for ; Mon, 16 Jun 2025 06:02:52 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-74890006232sm6936111b3a.53.2025.06.16.06.02.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Jun 2025 06:02:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3628b433-4ab2-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750078972; x=1750683772; 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=+UiMK0XqUdP3w4VQXOM4KTrdMDDbozq0m8l9m7I8RdI=;
        b=J4pCGXalIPg3SFmTWpsbw5oey+n6asJ0AHNapQQMS1lG3tgUfcDfWx1nbPWFeOZoUW
         sQgqIJqS8WGd0mEhwb03CG3k+V7pl1rSNl6RjcTLQxgIF5XFj3FM8xLU6sultJJWy2br
         qhg1pXEHbrkZrJBXpdZnL7+GmNESbPqtdM/hmffwgfTXmqBAW8wwA0uO6aRAtCPQQB1m
         /PyH7bIe24H3SEniL2X7oIP08r6yGZGIEH9JzJ2oDkvnTddqEOYfINcvIz12m0frcafP
         x9K2NjzAo5VBpDCJPFVZzd2uiQYivU6cZz0HCRsrCTYa/lxvWdH5nv9+1kqzjYsCFmUq
         PUiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750078972; x=1750683772;
        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=+UiMK0XqUdP3w4VQXOM4KTrdMDDbozq0m8l9m7I8RdI=;
        b=AQ+epXnXZbkohB4XMJA1ypoeAToupyJe2asSFJIuMr0vvJI1WtV+c7UY0WaUzRef1S
         D9B09cdl2nGY6ZIWl6cXmHmbgwN+05Mp7LKax8M9Yq2rSbicWQslCGsa0Q3v2j2F44lx
         QlZJbS3qoMEZvQWE2CDGt6GlUClF0FY/ycgR6rkdvYRBqtQOs9d/arUUbV1P1VyEPciy
         isYix7xrV7L5rmB+iQSpLxqIxiCfqTLkGE8lnH26V1+yYTuKGhsHXM1RKnkbTIpn8KRM
         o8Kd4gmHBNauMEQb54ON/3iOw5fbbdFO9AXmpVy44XaBSuqbUlw7E4kQ5/7Tsqr7kVg/
         tG9Q==
X-Gm-Message-State: AOJu0YyCEqNOoEmVmWgB7pj8hlLTsb2WfyARsRXG+oZG3A1PszsZKvZL
	ATURFvseX7YTpjPgPVEPPKLaqWeSUAyYVX85EAxZMEnIr+KV4Na4THUR3fWAI5gkXGLdXhKLfan
	gaKs=
X-Gm-Gg: ASbGnct7GURDMl2QrCb9NQJDM1A+awKma1qqx1SOxz3VQyrG5XrMhV+fs8KJOPKUzU3
	U2M1KC0WAggyqvquQbTiLcd9RTL7pnLzqyUkrhy2kdlzQZTog6TrlWr9qxCJ8l9VR/1dNRnAlwt
	S4iqX1PEzahCjTn8XOyH3VlhpukHEMZ3GDdTN2uNoPwEOp7v7CHEpGcXHDwxjFmPyCviXDwXU0G
	ttOJjkVo3kZcVMJ8hcOvEeSaFYZ2psG+2jWKCiBwYtpDQjX3aziB8euXr7Ipz8seB4ra/rllVcN
	l8pmDAQWhlCtN7NThuJkWkHxAI8pI6PY/x6iqNyWsTkQeEh3jfHAjkB00DZFhySrb6msYJ9eWlf
	hfU9ElBXvgnm2WGoF1whqyDC6a/QlAt8iNUdd08+ZxubEm10=
X-Google-Smtp-Source: AGHT+IFIbky8FQo0JyQ9zkDb7pEz7pPbS+l5iuXqXV5EiNEBpskkZOf9XQK9TMnLuBufJjZUcy9pGg==
X-Received: by 2002:a5d:5f90:0:b0:3a4:e6e7:3acd with SMTP id ffacd0b85a97d-3a572371f31mr7318412f8f.18.1750078969953;
        Mon, 16 Jun 2025 06:02:49 -0700 (PDT)
Message-ID: <0d2b44e3-bf6c-40ae-be4f-d0ad2845e925@suse.com>
Date: Mon, 16 Jun 2025 15:02:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v6 7/7] mm: allow page scrubbing routine(s) to be arch
 controlled
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini ,
 Anthony PERARD ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Bertrand Marquis ,
 Volodymyr Babchuk ,
 Oleksii Kurochko ,
 Shawn Anastasio 
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

Especially when dealing with large amounts of memory, memset() may not
be very efficient; this can be bad enough that even for debug builds a
custom function is warranted. We additionally want to distinguish "hot"
and "cold" cases (with, as initial heuristic, "hot" being for any
allocations a domain does for itself, assuming that in all other cases
the page wouldn't be accessed [again] soon). The goal is for accesses
of "cold" pages to not disturb caches (albeit finding a good balance
between this and the higher latency looks to be difficult).

Keep the default fallback to clear_page_*() in common code; this may
want to be revisited down the road.

Signed-off-by: Jan Beulich 
Acked-by: Julien Grall 
Reviewed-by: Oleksii Kurochko
---
v6: Re-base.
v4: Re-base.
v3: Re-base.
v2: New.
---
The choice between hot and cold in scrub_one_page()'s callers is
certainly up for discussion / improvement.

--- a/xen/arch/arm/include/asm/page.h
+++ b/xen/arch/arm/include/asm/page.h
@@ -144,6 +144,12 @@ extern size_t dcache_line_bytes;
 
 #define copy_page(dp, sp) memcpy(dp, sp, PAGE_SIZE)
 
+#define clear_page_hot  clear_page
+#define clear_page_cold clear_page
+
+#define scrub_page_hot(page) memset(page, SCRUB_BYTE_PATTERN, PAGE_SIZE)
+#define scrub_page_cold      scrub_page_hot
+
 static inline size_t read_dcache_line_bytes(void)
 {
     register_t ctr;
--- a/xen/arch/ppc/include/asm/page.h
+++ b/xen/arch/ppc/include/asm/page.h
@@ -188,6 +188,12 @@ static inline void invalidate_icache(voi
 #define clear_page(page) memset(page, 0, PAGE_SIZE)
 #define copy_page(dp, sp) memcpy(dp, sp, PAGE_SIZE)
 
+#define clear_page_hot  clear_page
+#define clear_page_cold clear_page
+
+#define scrub_page_hot(page) memset(page, SCRUB_BYTE_PATTERN, PAGE_SIZE)
+#define scrub_page_cold      scrub_page_hot
+
 /* TODO: Flush the dcache for an entire page. */
 static inline void flush_page_to_ram(unsigned long mfn, bool sync_icache)
 {
--- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -185,6 +185,12 @@ static inline void invalidate_icache(voi
 #define clear_page(page) memset((void *)(page), 0, PAGE_SIZE)
 #define copy_page(dp, sp) memcpy(dp, sp, PAGE_SIZE)
 
+#define clear_page_hot  clear_page
+#define clear_page_cold clear_page
+
+#define scrub_page_hot(page) memset(page, SCRUB_BYTE_PATTERN, PAGE_SIZE)
+#define scrub_page_cold      scrub_page_hot
+
 void flush_page_to_ram(unsigned long mfn, bool sync_icache);
 
 /* Write a pagetable entry. */
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -58,6 +58,7 @@ obj-y += pci.o
 obj-y += physdev.o
 obj-$(CONFIG_COMPAT) += x86_64/physdev.o
 obj-$(CONFIG_X86_PSR) += psr.o
+obj-bin-$(CONFIG_DEBUG) += scrub_page.o
 obj-y += setup.o
 obj-y += shutdown.o
 obj-y += smp.o
--- a/xen/arch/x86/include/asm/page.h
+++ b/xen/arch/x86/include/asm/page.h
@@ -226,6 +226,11 @@ void copy_page_sse2(void *to, const void
 #define clear_page(_p)      clear_page_cold(_p)
 #define copy_page(_t, _f)   copy_page_sse2(_t, _f)
 
+#ifdef CONFIG_DEBUG
+void scrub_page_hot(void *);
+void scrub_page_cold(void *);
+#endif
+
 /* Convert between Xen-heap virtual addresses and machine addresses. */
 #define __pa(x)             (virt_to_maddr(x))
 #define __va(x)             (maddr_to_virt(x))
--- /dev/null
+++ b/xen/arch/x86/scrub_page.S
@@ -0,0 +1,39 @@
+        .file __FILE__
+
+#include 
+#include 
+#include 
+
+FUNC(scrub_page_cold)
+        mov     $PAGE_SIZE/32, %ecx
+        mov     $SCRUB_PATTERN, %rax
+
+0:      movnti  %rax,   (%rdi)
+        movnti  %rax,  8(%rdi)
+        movnti  %rax, 16(%rdi)
+        movnti  %rax, 24(%rdi)
+        add     $32, %rdi
+        sub     $1, %ecx
+        jnz     0b
+
+        sfence
+        ret
+END(scrub_page_cold)
+
+        .macro scrub_page_stosb
+        mov     $PAGE_SIZE, %ecx
+        mov     $SCRUB_BYTE_PATTERN, %eax
+        rep stosb
+        ret
+        .endm
+
+        .macro scrub_page_stosq
+        mov     $PAGE_SIZE/8, %ecx
+        mov     $SCRUB_PATTERN, %rax
+        rep stosq
+        ret
+        .endm
+
+FUNC(scrub_page_hot)
+        ALTERNATIVE scrub_page_stosq, scrub_page_stosb, X86_FEATURE_ERMS
+END(scrub_page_hot)
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -135,6 +135,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -800,27 +801,31 @@ static void page_list_add_scrub(struct p
         page_list_add(pg, &heap(node, zone, order));
 }
 
-/* SCRUB_PATTERN needs to be a repeating series of bytes. */
-#ifndef NDEBUG
-#define SCRUB_PATTERN        0xc2c2c2c2c2c2c2c2ULL
-#else
-#define SCRUB_PATTERN        0ULL
+/*
+ * While in debug builds we want callers to avoid relying on allocations
+ * returning zeroed pages, for a production build, clear_page_*() is the
+ * fastest way to scrub.
+ */
+#ifndef CONFIG_DEBUG
+# undef  scrub_page_hot
+# define scrub_page_hot clear_page_hot
+# undef  scrub_page_cold
+# define scrub_page_cold clear_page_cold
 #endif
-#define SCRUB_BYTE_PATTERN   (SCRUB_PATTERN & 0xff)
 
-static void scrub_one_page(const struct page_info *pg)
+static void scrub_one_page(const struct page_info *pg, bool cold)
 {
+    void *ptr;
+
     if ( unlikely(pg->count_info & PGC_broken) )
         return;
 
-#ifndef NDEBUG
-    /* Avoid callers relying on allocations returning zeroed pages. */
-    unmap_domain_page(memset(__map_domain_page(pg),
-                             SCRUB_BYTE_PATTERN, PAGE_SIZE));
-#else
-    /* For a production build, clear_page() is the fastest way to scrub. */
-    clear_domain_page(_mfn(page_to_mfn(pg)));
-#endif
+    ptr = __map_domain_page(pg);
+    if ( cold )
+        scrub_page_cold(ptr);
+    else
+        scrub_page_hot(ptr);
+    unmap_domain_page(ptr);
 }
 
 static void poison_one_page(struct page_info *pg)
@@ -1100,12 +1105,14 @@ static struct page_info *alloc_heap_page
     if ( first_dirty != INVALID_DIRTY_IDX ||
          (scrub_debug && !(memflags & MEMF_no_scrub)) )
     {
+        bool cold = d && d != current->domain;
+
         for ( i = 0; i < (1U << order); i++ )
         {
             if ( test_and_clear_bit(_PGC_need_scrub, &pg[i].count_info) )
             {
                 if ( !(memflags & MEMF_no_scrub) )
-                    scrub_one_page(&pg[i]);
+                    scrub_one_page(&pg[i], cold);
 
                 dirty_cnt++;
             }
@@ -1370,7 +1377,7 @@ bool scrub_free_pages(void)
                 {
                     if ( test_bit(_PGC_need_scrub, &pg[i].count_info) )
                     {
-                        scrub_one_page(&pg[i]);
+                        scrub_one_page(&pg[i], true);
                         /*
                          * We can modify count_info without holding heap
                          * lock since we effectively locked this buddy by
@@ -2074,7 +2081,7 @@ static struct page_info *alloc_color_hea
     if ( !(memflags & MEMF_no_scrub) )
     {
         if ( need_scrub )
-            scrub_one_page(pg);
+            scrub_one_page(pg, d != current->domain);
         else
             check_one_page(pg);
     }
@@ -2225,7 +2232,7 @@ static void __init cf_check smp_scrub_he
         if ( !mfn_valid(_mfn(mfn)) || !page_state_is(pg, free) )
             continue;
 
-        scrub_one_page(pg);
+        scrub_one_page(pg, true);
     }
 }
 
@@ -2923,7 +2930,7 @@ void unprepare_staticmem_pages(struct pa
         if ( need_scrub )
         {
             /* TODO: asynchronous scrubbing for pages of static memory. */
-            scrub_one_page(pg);
+            scrub_one_page(pg, true);
         }
 
         pg[i].count_info |= PGC_static;
--- /dev/null
+++ b/xen/include/xen/scrub.h
@@ -0,0 +1,24 @@
+#ifndef __XEN_SCRUB_H__
+#define __XEN_SCRUB_H__
+
+#include 
+
+/* SCRUB_PATTERN needs to be a repeating series of bytes. */
+#ifdef CONFIG_DEBUG
+# define SCRUB_PATTERN       _AC(0xc2c2c2c2c2c2c2c2,ULL)
+#else
+# define SCRUB_PATTERN       _AC(0,ULL)
+#endif
+#define SCRUB_BYTE_PATTERN   (SCRUB_PATTERN & 0xff)
+
+#endif /* __XEN_SCRUB_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 13:11:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 13:11:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017255.1394228 (Exim 4.92)
	(envelope-from )
	id 1uR9c8-0000xA-2O; Mon, 16 Jun 2025 13:11:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017255.1394228; Mon, 16 Jun 2025 13:11: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 1uR9c7-0000x3-W6; Mon, 16 Jun 2025 13:11:03 +0000
Received: by outflank-mailman (input) for mailman id 1017255;
 Mon, 16 Jun 2025 13: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 1uR9Sv-0003pW-TN
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 13:01:33 +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 067907d3-4ab2-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 15:01:32 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3a4f72cba73so3799122f8f.1
 for ; Mon, 16 Jun 2025 06:01:32 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2365dea8fd6sm60146695ad.145.2025.06.16.06.01.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Jun 2025 06:01:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 067907d3-4ab2-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750078892; x=1750683692; 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=/Qgc++fc93ux80i5RmqliRbRkUUe9ZSRv/76bEt+jaE=;
        b=Fvd92rhX/gAPMsa0EmEbLm/snAK+YAuvMOcGc+F4C9qGFP9a48R8me16HREG6w2x4q
         uG6m0f0MywfucW1CmdpWS8M7/hRxRaDXgslMwk3xYzQevpts6EoqYRpN6sblifzs4qWd
         NiatMNclheC+3J4dhJg3cSVjs/FcF4WR+q38b+HNwkKXY8XB1s/ltOl7iaP2EWHjHvM0
         2GXoEZysUpnmNV7P8F9q8rnO7wzW4IludakIz/aGJPmI21zxHtxsL6nufT13CSqNQ4fa
         M80DZbkqPOQ0YrFbyLIMfau92FaHwnlO5JQKS8pgRQFF59+Ajq+juOkLvmDR4VjVIkIN
         DnLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750078892; x=1750683692;
        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=/Qgc++fc93ux80i5RmqliRbRkUUe9ZSRv/76bEt+jaE=;
        b=P5GeYDflz5zQyQZ+eSYMzc+vpxZN9TTBHwOBYxMgy2Vu5az9m/yj6PSZo/NXtoi6Eg
         c9OTQcw7wdN4MdEUeh/lErNCcGz4ya/iX3mEIMhlscbjA37cBICuKOXu94EIpuz+lKOZ
         myiFjmolrT8ETBTDR8UnPWis8Leg+AABqRscgo7Wkolpibt3WynZ/f2VQZihCQStsZTP
         /8IJdDVx54JBM4ZhzIyK4Lg1IdhBDAdFm4FdK+n2hAL9oPlq+Y77uARy2LEuED+tEUA/
         xuYKrgPRN3A/bPVcYRCepFtPUekVizj+ypG+krk1VmBtpT5ZdRXtMcp5ZqapU7sChk8k
         d1GA==
X-Gm-Message-State: AOJu0YyJ8EvXAPlMf7NoIpCLcvgtOkZcStwCCq4yIoxgNuvsAKbBLiL2
	1UCp/aloHSlCEFo31cA1RaMzdAeC8g34OnlUlE/+8jlucqO62Nps/IK70PdqyDgWD23zgfHTrh5
	rCDs=
X-Gm-Gg: ASbGncsW5qZAzWKzGWBAf1uv3EsJnOMfk9mve5KJY9itoSGLF6e6F9bCxoC0B3IVWgk
	g9289I/XBQnvpAKUB1Gg6XitRYOjk7gK64Exp8QHFNvwwH8X7vrF3X1TnTPI30NVghZS/TD5yya
	Gs2JS2rWW5Pez5uoZaOaoES6qB6ujw8DEn+XMIs9uH4Rf/CuLcOrXQckLd4UuAvT5WPkoROzjZX
	fZNQzCdiwGWiPMN6HeBYA1oGY5nLM/OXO7MwQcFHQ10S6RrL2Sn4MdCqt0pBLa4jolrMfadU2Rt
	HsKej17trJZ7LOpSF36EXDvfAcLoVfbZfVFkdyh98KHwSn2F51njqSGs5L2NHfPSjzvFIP9SJqC
	xwOvgae7j7DG2Sr/CDd+wnFAP1EO17zFTc9GPslypb7CAnsk=
X-Google-Smtp-Source: AGHT+IF1/BiEdagP71nQb6AOqDYr1F9/K/R9nw/EWajmZrQN1TpdqMHOI4v1akSjxyuOoUWijBDTNg==
X-Received: by 2002:a05:6000:2f88:b0:3a5:1360:6b34 with SMTP id ffacd0b85a97d-3a56d7bacfdmr8843603f8f.2.1750078890953;
        Mon, 16 Jun 2025 06:01:30 -0700 (PDT)
Message-ID: 
Date: Mon, 16 Jun 2025 15:01:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v6 5/7] x86: control memset() and memcpy() inlining
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
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

Stop the compiler from inlining non-trivial memset() and memcpy() (for
memset() see e.g. map_vcpu_info() or kimage_load_segments() for
examples). This way we even keep the compiler from using REP STOSQ /
REP MOVSQ when we'd prefer REP STOSB / REP MOVSB (when ERMS is
available).

With gcc10 this yields a modest .text size reduction (release build) of
around 2k.

Unfortunately these options aren't understood by the clang versions I
have readily available for testing with; I'm unaware of equivalents.

Note also that using cc-option-add is not an option here, or at least I
couldn't make things work with it (in case the option was not supported
by the compiler): The embedded comma in the option looks to be getting
in the way.

Requested-by: Andrew Cooper 
Signed-off-by: Jan Beulich 
---
v3: Re-base.
v2: New.
---
The boundary values are of course up for discussion - I wasn't really
certain whether to use 16 or 32; I'd be less certain about using yet
larger values. A respective Linux patch [1] uses 256 ...

Similarly whether to permit the compiler to emit REP STOSQ / REP MOVSQ
for known size, properly aligned blocks is up for discussion.

[1] https://lore.kernel.org/lkml/20250605164733.737543-1-mjguzik@gmail.com/T/#u

--- a/xen/arch/x86/arch.mk
+++ b/xen/arch/x86/arch.mk
@@ -58,6 +58,9 @@ endif
 $(call cc-option-add,CFLAGS_stack_boundary,CC,-mpreferred-stack-boundary=3)
 export CFLAGS_stack_boundary
 
+CFLAGS += $(call cc-option,$(CC),-mmemcpy-strategy=unrolled_loop:16:noalign$(comma)libcall:-1:noalign)
+CFLAGS += $(call cc-option,$(CC),-mmemset-strategy=unrolled_loop:16:noalign$(comma)libcall:-1:noalign)
+
 ifeq ($(CONFIG_UBSAN),y)
 # Don't enable alignment sanitisation.  x86 has efficient unaligned accesses,
 # and various things (ACPI tables, hypercall pages, stubs, etc) are wont-fix.



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 13:20:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 13:20:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017264.1394239 (Exim 4.92)
	(envelope-from )
	id 1uR9lA-0002fi-Si; Mon, 16 Jun 2025 13:20:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017264.1394239; Mon, 16 Jun 2025 13:20:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uR9lA-0002fb-Pp; Mon, 16 Jun 2025 13:20:24 +0000
Received: by outflank-mailman (input) for mailman id 1017264;
 Mon, 16 Jun 2025 13:20: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 1uR9l8-0002fV-S9
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 13:20:22 +0000
Received: from mail-oo1-xc30.google.com (mail-oo1-xc30.google.com
 [2607:f8b0:4864:20::c30])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a470acad-4ab4-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 15:20:17 +0200 (CEST)
Received: by mail-oo1-xc30.google.com with SMTP id
 006d021491bc7-606440d92eeso2142062eaf.2
 for ; Mon, 16 Jun 2025 06:20:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a470acad-4ab4-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750080015; x=1750684815; 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=sO1GNpq15PCTF/PT+tBMoz1RhteBb8VqsNqH/jjIO7E=;
        b=E8rUQwrqn+uUHSlDBK2Y+25U3EJFZn5pd6rQKdJOgmBjyZmi+39JcjIhSyP0Z/MCK6
         8z7ssyjlGMYUz76lWJrth0L642CujnL9FZNJlFRW69JQq2k6MLguI9jTpIDdwuG2Gew7
         AHVCwLOyTTnrk6o3/M7/ar21B+d4/9q/YznSE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750080015; x=1750684815;
        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=sO1GNpq15PCTF/PT+tBMoz1RhteBb8VqsNqH/jjIO7E=;
        b=nl+1VdDRTugOFTNpndW7p+ldUqzmfC+ks/wtwCODSAcbgmUL3JZNG2+at1MywrNABO
         p9yWR0F2DxSqPVyOrBBK2kdZUVBiGKFR9Z78LjNCw3jaz9GFKZ+jn92Rxp7IkM563BUJ
         KKbbbT0nKGoQIDLUp7Ys+70M/OK+r9gIwwf4UkC6OyhNL7dC9BXxgyjeOIv1GD/6IzbV
         9KsNzzXDn1b/nh0fLrW2DHn0yB11uW9Z7I/Z6U9T3Bm1VmRu+xMufAwiwTIeqcplIu2j
         p0lSdvPdaduYWEeHmOY8tJbYLJFAAS0SXDZSk2rlaqkvJCz1iLvkDt/+FSMwnkYBQAYr
         v5BQ==
X-Gm-Message-State: AOJu0YyKXEVC5oHLSI/WFV+dgO9CjEs7+80/b4UTXN9cUOVH32YZ3u1s
	GuloCZFeF59C8JUfUrt3tqHx5qiaqgNGD+armSClzxy2ow++/Q+f2m5G5ExaNIiZV/ejDqYg84+
	u4APr+9acmMIvlZFR4RXzZ7XntJRwCzgZacR56lRC
X-Gm-Gg: ASbGncsAbdc8FNVXJq6RPHjzmZq+dd7jc/CqwmWy7A8pZDOFZSDR8UJbGZJBLWzf/kh
	9xkBQozQZJolFt+WRj+qOTGOBhl7+yAU1mHGJXis2ZRXZe7QElY4Br5W5ddWnl1+phYIAPNbrsT
	4O5gtks55IkQVq6wxSSubWMj1Aruq9lhnUfLZSOpSVbw==
X-Google-Smtp-Source: AGHT+IElknHf5fRK1/obsVEOLJZZRYfxK9SVu7sYNNKeRPSqYQHuPUbGzrXQIAbWm34jL2S5xllHiA3rnZwOqDUPU1I=
X-Received: by 2002:a05:6820:1610:b0:610:fbee:c0fa with SMTP id
 006d021491bc7-61110f4f8c5mr4566184eaf.1.1750080015568; Mon, 16 Jun 2025
 06:20:15 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Ross Lagerwall 
Date: Mon, 16 Jun 2025 14:20:03 +0100
X-Gm-Features: AX0GCFs_d0uEIt2jgsN2fMK5PknBcE2TxkRv-D3hhA1c26WYv8gCpV3sknQDdM4
Message-ID: 
Subject: Re: [PATCH] x86/pmstat: correct PMSTAT_get_pxstat buffer size checking
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" , 
	Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 16, 2025 at 1:00=E2=80=AFPM Jan Beulich  wro=
te:
>
> min(pmpt->perf.state_count, op->u.getpx.total) =3D=3D op->u.getpx.total c=
an
> be expressed differently as pmpt->perf.state_count >=3D op->u.getpx.total=
.
> Copying when the two are equal is fine; (partial) copying when the state
> count is larger than the number of array elements that a buffer was
> allocated to hold is what - as per the comment - we mean to avoid. Drop
> the use of min() again, but retain its effect for the subsequent copying
> from pxpt->u.pt.
>
> Fixes: aa70996a6896 ("x86/pmstat: Check size of PMSTAT_get_pxstat buffers=
")
> Reported-by: Andrew Cooper 
> Signed-off-by: Jan Beulich 
>

Reviewed-by: Ross Lagerwall 

Thanks,
Ross


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 13:27:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 13:27:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017270.1394249 (Exim 4.92)
	(envelope-from )
	id 1uR9s4-0003ZK-Ib; Mon, 16 Jun 2025 13:27:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017270.1394249; Mon, 16 Jun 2025 13:27: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 1uR9s4-0003ZD-Fh; Mon, 16 Jun 2025 13:27:32 +0000
Received: by outflank-mailman (input) for mailman id 1017270;
 Mon, 16 Jun 2025 13:27: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 1uR9s3-0003Z7-Pd
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 13:27:31 +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 a6bc6ec1-4ab5-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 15:27:29 +0200 (CEST)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-45348bff79fso15113945e9.2
 for ; Mon, 16 Jun 2025 06:27:29 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a568a547d2sm11372198f8f.19.2025.06.16.06.27.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 16 Jun 2025 06:27:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a6bc6ec1-4ab5-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750080449; x=1750685249; 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=j4HcH+lDGi4qpO9OpyIzLWxRMkCgRucsPoW+TGYmfvs=;
        b=JnUSuUPY8h8AXxZHXoE3MBlRHzvVDIbwgVf15birF991agDkVlRHCXQlBWOJNbZB+T
         FoLtNfCgFFRosmQt1OOdMkbCeGu3dAaxzleJJGlSo7/tmM1JyRqheeqrYumObNWKM53P
         JsLVgT0k0q3r3K5xynraOTQVKCTSKtoptqhhg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750080449; x=1750685249;
        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=j4HcH+lDGi4qpO9OpyIzLWxRMkCgRucsPoW+TGYmfvs=;
        b=O9Dj8j57LfOiTh8gLHdrBl5zyHSTxQgQsDyb69Vi1773XuNN223gVPZEqS8Ni/jK+d
         ue/ndvc1fVMN9dL66aNOYy4TYyWgdG1kUKdTi9OkUqbbAFzpdQcWoAcJkT6DHI7qs8aQ
         DjaFa/j3JIgFF3q0tzlBaMUILQ3DvFLYh3/ISUaeyW8ewSYE6kzZr4GYe/xTFuzR8qTV
         qJY7cZjny34dCNf+ZIcQjSSIy1sjdSLxt+dk1dgw5NZtszuCx9pLQ6AW3nZwvYytQEjl
         ohV0wp0Rs80KZCaLbhKnXhLaA094y1DFhKBWZVcnzL03ZsEZURk+Dblg1uFwQYvUtuz3
         1Pyg==
X-Gm-Message-State: AOJu0YzLr2eEra3jUKYGU5v098YNar8Ow3MbwoLU21F/xv4CP4cekkVk
	dNJ+PPRhzZv097UUPxXKNs1eq4FupkmFfIZMvlNCUKTkI8MXPM+PHxLK5XxXkEWrrd4=
X-Gm-Gg: ASbGncs/LgCaph5GomQ3WNfhwy4A6c7OTxNfQDl4hgIQl9bndJDm9E6LfgAwnkwUW1w
	ymg8FpkoFM7qLqTuUpgQ9LT2Dfsc7ncxmsuH36N3AwJTPUQadKgNCCqAc8qWXuvDcI2pAVchevO
	mcedWD5IkwZ47pIV34sVnJYgzxR3q9/ue35TjmFjqCILM5nDoFFxAWQIrtyqNLtFqmD4MKXuUz4
	ipthzMF1oCMEyzeRmakyuNKCDvWeYIZoKDmQSfukSvmK25LVWJSj+79a041/VZMw2jcc12BVTSh
	ywmpK07bzv/NINLMLfZN2uF8mOlVpO1kSvx7QP6FTPh8FX6f3u3FXE1xNCbXJo+wpYymwxHHgLu
	Q6FSxuRbRDsiz7tUgn0PXhR7b5CfVyhPQcXA=
X-Google-Smtp-Source: AGHT+IEwwayFXDezRmzlmgCJpJIaRn2NliXWt0j2ArJ7MYm9tKPltf5XVBkjESVnhz+7xvIeA7Wq2w==
X-Received: by 2002:a05:6000:290b:b0:3a5:2e84:cc7b with SMTP id ffacd0b85a97d-3a57238b7f2mr7257369f8f.11.1750080448986;
        Mon, 16 Jun 2025 06:27:28 -0700 (PDT)
Date: Mon, 16 Jun 2025 15:27:06 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" ,
	Andrew Cooper ,
	Julien Grall ,
	Stefano Stabellini ,
	Anthony PERARD ,
	Michal Orzel 
Subject: Re: [PATCH] memory: arrange to conserve on DMA reservation
Message-ID: 
References: <6565e881-ec59-4db4-834a-f694bf1b9427@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <6565e881-ec59-4db4-834a-f694bf1b9427@suse.com>

On Tue, Feb 25, 2025 at 03:58:34PM +0100, Jan Beulich wrote:
> Entities building domains are expected to deal with higher order
> allocation attempts (for populating a new domain) failing. If we set
> aside a reservation for DMA, try to avoid taking higher order pages from
> that reserve pool.
>
> Instead favor order-0 ones which often can still be
> supplied from higher addressed memory, even if we've run out of
> large/huge pages there.

I would maybe write that last sentence as:  force non zero order
allocations to use the non-DMA region, and if the region cannot
fulfill the request return an error to the caller for it to retry with
a smaller order.  Effectively this limits allocations from the DMA
region to only be of order 0 during physmap domain population.

> Signed-off-by: Jan Beulich 
> 
> ---
> RFC: More generally for any requests targeting remote domains?

I think doing the limitation for domain creation is fine, the more
that there are also other flags there.

> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -192,6 +192,14 @@ static void populate_physmap(struct memo
>           * delayed.
>           */
>          a->memflags |= MEMF_no_icache_flush;
> +
> +        /*
> +         * Heuristically assume that during domain construction the caller is
> +         * capable of falling back to order-0 allocations, allowing us to
> +         * conserve on memory otherwise held back for DMA purposes.
> +         */
> +        if ( a->extent_order )
> +            a->memflags |= MEMF_no_dma;

For PV domains: is it possible for toolstack to try to allocate a
certain amount of pages from the DMA pool for the benefit of the
domain?

I also wonder if it would make sense to attempt to implement the
logic on the toolstack side: meminit_{hvm,pv}()?

No strong opinion, but slightly less logic in the hypervisor, and
won't change the interface for possibly existing toolstacks that don't
pass MEMF_no_dma on purpose.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 13:57:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 13:57:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017283.1394259 (Exim 4.92)
	(envelope-from )
	id 1uRAL9-000820-Rp; Mon, 16 Jun 2025 13:57:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017283.1394259; Mon, 16 Jun 2025 13:57: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 1uRAL9-00081t-O5; Mon, 16 Jun 2025 13:57:35 +0000
Received: by outflank-mailman (input) for mailman id 1017283;
 Mon, 16 Jun 2025 13:57: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 1uRAL9-00081n-5m
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 13:57:35 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20605.outbound.protection.outlook.com
 [2a01:111:f403:2418::605])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d6b3cb92-4ab9-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 15:57:29 +0200 (CEST)
Received: from BYAPR02CA0042.namprd02.prod.outlook.com (2603:10b6:a03:54::19)
 by SJ5PPF4C62B9E70.namprd12.prod.outlook.com
 (2603:10b6:a0f:fc02::991) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.40; Mon, 16 Jun
 2025 13:57:24 +0000
Received: from SJ5PEPF00000206.namprd05.prod.outlook.com
 (2603:10b6:a03:54:cafe::f5) by BYAPR02CA0042.outlook.office365.com
 (2603:10b6:a03:54::19) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.23 via Frontend Transport; Mon,
 16 Jun 2025 13:57:24 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ5PEPF00000206.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.8835.15 via Frontend Transport; Mon, 16 Jun 2025 13:57:24 +0000
Received: from localhost (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, 16 Jun
 2025 08:57:22 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d6b3cb92-4ab9-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Yj/qZXysleKQ/YBOydKCjlx4bpL+BWAp2IZCKclYdcmV8YPvefGv21TeMN5Mwm2nayOTvxHzNpJbnECulVOHjm+9owQ+C/YdT3ENxErB0VfJ9Kl8gxjPAhAS9Mhe9lIDFxKHUO1jkwIsWLi3SmWv/mN9a+xLbuTTn/ywg16jAAqxtY+uGNNAy0+KKKifCpgFltOoY4HJxh94uPD4ip82mgPLWOk0Pu28oVKC9IwDa+9PBrwtLU6vF/kXN+hykVfohsowPQKLeLxPTg1Mg8XgWZyGLEYFVGbu+p2LzkeBmJIzRdpgPPOurU8dBLStcaFj0pPy2XIZzKBGEl2bJ24PAg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Yn5DtUjkdh7OjnMeZqeqJNCf8lcLQwrc/eIHXuMhi28=;
 b=NAbo1UHz66ZLUX1VFaZuw+uJMWxlN0rELvjEuIzEZ/fMSj/GfwfK9HWRpICyledkyx+SwhPTop+jTJMBldwvwX9R/f0L3Kn15D/DEdm/Hj3o3h/vTsegYA4nktPXVbfQjEIhBQtHzZiCs5AEPyNoNn59Grproe2n3Mcy3CPL5JlC559+KlZVjlWFvYFRhzQ8TyihAfaUBgOa5hdxpXPyoOsASTAmpt+n9YPperadBRE5iTi+xhksqpB91egur2Z0JkHv1Jxu8ZfNNyLO7zzSHjw6xh2C20lF37yebNLt/XZotUvZ76+wx+ZKC+HHT5ScLg5IIcdNUO5q/NHOsWdu3A==
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=Yn5DtUjkdh7OjnMeZqeqJNCf8lcLQwrc/eIHXuMhi28=;
 b=3WTIIMle0MK0RyKnwdT9/XUkUvNOxk+GiVfrbIRFR7dnL43TtTIaOJ89tPjlldj6g2A4sErvq9/1G9gP8up+cHkgiNMmW37yJPDj83IBUKfJg4ufoaP1tI6alTpB18HaujzgypmtmZiTWmvT7E3ScF3dhW4Y0ah/8KQzWtfTxOM=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 16 Jun 2025 15:57:21 +0200
Message-ID: 
To: Stefano Stabellini 
CC: , Julien Grall , "Bertrand
 Marquis" , Michal Orzel ,
	"Daniel P. Smith" 
Subject: Re: [PATCH v3 08/14] xen/dt: Move bootfdt functions to
 xen/bootfdt.h
From: Alejandro Vallejo 
X-Mailer: aerc 0.20.1
References: <20250613151612.754222-1-agarciav@amd.com>
 <20250613151612.754222-9-agarciav@amd.com>
 
In-Reply-To: 
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: SJ5PEPF00000206:EE_|SJ5PPF4C62B9E70:EE_
X-MS-Office365-Filtering-Correlation-Id: e47df39e-90f8-4739-236e-08ddacddb906
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?ZnhpUXZ0NXVPa0lRQjNtcHppQUR5UVhodUUzVm0zeEFWR25nb0o4K3Jqdk1U?=
 =?utf-8?B?Mjd2U2RzOVFUMFl1Q2hTbVY3d0ZSTGpsK0ord3hZcVBKazVDQkJjNDk4OXVp?=
 =?utf-8?B?Q2hqS2hzYTZJcVZGNU1OUVVtUXZqbk4xdC9rK1hpSmVuMld5YkxwMVE5dmVj?=
 =?utf-8?B?blB1WHRGb3VUWXgvNU9BRVJOK24vNWRwb3IzamFmNUZYeDZCZU9lTk1VL3o4?=
 =?utf-8?B?a3ltbTN4RldSY1dMaG5ZcnJRdXAwOTJTNlVZa1NUeDhIaDJNWXJ6WjRIeHZ3?=
 =?utf-8?B?Y3doN3FQbUJvb0wza2Fzc2VKanBVQWI2Ly9yR2V3VUNpWlNpeS9vVDgrRGpX?=
 =?utf-8?B?NzRSQkdtVVgrald6bXlGQmRZR0RiNURBOXZXbWwzbTBsT1ZjTVlEanUwN1ZM?=
 =?utf-8?B?RTFWQUtBZ1Y2Tmk5NFZxbXpOMm9VSG9kWXI5VzR1YXdoRzk1WG9iRGFsTmtJ?=
 =?utf-8?B?VytjcmY3bERUbW14MFIxYjZrUzNoOU4wTXo5YXZiYzBGdHlrMWRLaERSUkNt?=
 =?utf-8?B?TDZZWU9JVjBRbnRtN3NEQk9weDI5YWRTbWc3Vi92U2xMRFg1ZlVQMUlYcDdy?=
 =?utf-8?B?QktwK2hoUEEvV1lGV0VvR1ZGR2ZDUVRPci9vUkxIQ1ZXWjZPRVRwZS92cTBr?=
 =?utf-8?B?T0pETk9aZDNYeER3RUhWazFoU1A5ZnpTNmF5NlQ0bitkbFhwRGxnSlZlZnpE?=
 =?utf-8?B?TTkwa0tSb1JzcDdIeERhY3k1Q2JpL05xRWRQRTJIZU1FL1RBNEdXSUdYSGs3?=
 =?utf-8?B?cGxDT1BtQjBuamxmQ3MyVVcrcmhKWEg1dktrZHVNYWFnR0crbmFIYkV6ZHlV?=
 =?utf-8?B?QkJRSk11YjhFeVJMUGVDUURKNHpUNkxUMVdmVk5WM042M0QvcmlMTVZSL2w5?=
 =?utf-8?B?cXR5VGRQMEl0WWVZbElEMkUzeEwrWStuSEhTQjJQN3l5ZFYvaWt5NkRHU2Jt?=
 =?utf-8?B?RGk3dS9SeVBQVHFyV0t0MVN0YytzQzNWM2plU1FsTG1xQXZmd25NcDVQZTl5?=
 =?utf-8?B?TzJiVDRmR3V5V1hJdE92azhYT1MvWGJzTnkyTW1JU1lEVWhaMG8rY2c0NXgw?=
 =?utf-8?B?MXV4aWJ2Z1hQek5jdkhtSllidEgxaERUeUJpaVlZcEV2S3I2STVNZkx2aVZM?=
 =?utf-8?B?TmlsR1p6azZsWEYxUjRNcFhzZlpSVnZwV256YjFvWjlqTEtyazZDdy93M2NS?=
 =?utf-8?B?QU1HTXdjK1dxa0xzQVRBNzNVcW5xVFRuN3NFNmxscm5XbllQYTJ1eU9ieWhp?=
 =?utf-8?B?bUxad1puRUtpcnp6MUVoM2VVZ3lVbDNMSEtTbkdaQXUxemZycU1QUXRmK3JN?=
 =?utf-8?B?azFEaXRVaFNCTi9IS3Qrc3VoVXU4MWp1SWFBd3AxSWwycWhHTWJ0aXAwNzFW?=
 =?utf-8?B?N3FiSzNLNXY2YVNxaE8rTEJXU1k0Wm1hdTBnQW9XSDlTNEpVWFRvVVVkT1Vh?=
 =?utf-8?B?TmMwM3lTL1F0SXA5RDYvdTVjL0srUjkxdmlOZGp0TnNuSWJuMlVqcnhCSDh0?=
 =?utf-8?B?bVVIdEdEN0RyTkZHcmpTYS95U0lvbFFIM0drZy9ldGRMNFN3L0JtYUJyUWpJ?=
 =?utf-8?B?QXMrWnlxRmFvRUlUWVIwQmJpSWdjVmZaSXNRQ1BtVE1WTXUwdWFHNW15aUFW?=
 =?utf-8?B?cmpROGliQ3FRL2ZvRko2OThPc292d0YwbTh1RnljVmdLdTJld2dUYXhMWkp5?=
 =?utf-8?B?b0trRHVneC95YTFaQ0YyQ1dkYlZ6OEl5SExFRHRYMlRheUZodDliZnFwd2Nk?=
 =?utf-8?B?UXc5U0J5K0NuMlB0VFl4ajFxRUhpT3oraFpyaWx4WmRGWXlZYURNTk1Ucyto?=
 =?utf-8?B?OGt2WXdBTktSMXVDUUhRejBSeERkZDhqeFBpMXdQZ2w5Y3R4aTRkQk1MeFNN?=
 =?utf-8?B?Wml4SzFvcFBuTzNiaWdYRWFSUzdFMUI3WTN0Sm9LeEdiUjRYaWFyeHVQeFdE?=
 =?utf-8?B?b1E0UW5QYlZOYmhkSmNrUFl0YkZIUndwTlgyMmZDWjlxczJxZ2JncnI5VjNU?=
 =?utf-8?B?d1lNTGtTeitJTHZVWVJKYjhTZ2VkWnBzL1gwNHI3ZVR4QXoxVU1WdmxzT1FL?=
 =?utf-8?Q?zB3SNu?=
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: 16 Jun 2025 13:57:24.7147
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e47df39e-90f8-4739-236e-08ddacddb906
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:
	SJ5PEPF00000206.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ5PPF4C62B9E70

On Sat Jun 14, 2025 at 3:16 AM CEST, Stefano Stabellini wrote:
> On Fri, 13 Jun 2025, Alejandro Vallejo wrote:
>> Part of an unpicking process to extract bootfdt contents independent of =
bootinfo
>> to a separate file for x86 to take.
>>=20
>> Move functions required for early FDT parsing from device_tree.h and arm=
's
>> setup.h onto bootfdt.h
>>=20
>> Declaration motion only. Not a functional change.
>>=20
>> Signed-off-by: Alejandro Vallejo 
>> ---
>> v3:
>>   * Avoid mutations during code motion
>> ---
>>  xen/include/xen/bootfdt.h     | 62 +++++++++++++++++++++++++++++++++++
>>  xen/include/xen/device_tree.h | 40 +---------------------
>>  2 files changed, 63 insertions(+), 39 deletions(-)
>>=20
>> diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
>> index 8ea52290b7..b6ae7d6aa6 100644
>> --- a/xen/include/xen/bootfdt.h
>> +++ b/xen/include/xen/bootfdt.h
>> @@ -2,6 +2,7 @@
>>  #ifndef XEN_BOOTFDT_H
>>  #define XEN_BOOTFDT_H
>> =20
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -16,8 +17,53 @@
>>  #define NR_MEM_BANKS 256
>>  #define NR_SHMEM_BANKS 32
>> =20
>> +/* Default #address and #size cells */
>> +#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
>> +#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
>> +
>>  #define MAX_MODULES 32 /* Current maximum useful modules */
>> =20
>> +#define DEVICE_TREE_MAX_DEPTH 16
>> +
>> +/* Helper to read a big number; size is in cells (not bytes) */
>> +static inline u64 dt_read_number(const __be32 *cell, int size)
>> +{
>> +    u64 r =3D 0;
>> +
>> +    while ( size-- )
>> +        r =3D (r << 32) | be32_to_cpu(*(cell++));
>> +    return r;
>> +}
>> +
>> +static inline u64 dt_next_cell(int s, const __be32 **cellp)
>> +{
>> +    const __be32 *p =3D *cellp;
>> +
>> +    *cellp =3D p + s;
>> +    return dt_read_number(p, s);
>> +}
>> +
>> +typedef int (*device_tree_node_func)(const void *fdt,
>> +                                     int node, const char *name, int de=
pth,
>> +                                     u32 address_cells, u32 size_cells,
>> +                                     void *data);
>> +
>> +/**
>> + * device_tree_for_each_node - iterate over all device tree sub-nodes
>> + * @fdt: flat device tree.
>> + * @node: parent node to start the search from
>> + * @func: function to call for each sub-node.
>> + * @data: data to pass to @func.
>> + *
>> + * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
>> + *
>> + * Returns 0 if all nodes were iterated over successfully.  If @func
>> + * returns a value different from 0, that value is returned immediately=
.
>> + */
>> +int device_tree_for_each_node(const void *fdt, int node,
>> +                              device_tree_node_func func,
>> +                              void *data);
>> +
>>  typedef enum {
>>      BOOTMOD_XEN,
>>      BOOTMOD_FDT,
>> @@ -260,4 +306,20 @@ static inline struct membanks *membanks_xzalloc(uns=
igned int nr,
>>      return banks;
>>  }
>> =20
>> +/*
>> + * Interpret the property `prop_name` of `node` as a u32.
>> + *
>> + * Returns the property value on success; otherwise returns `dflt`.
>> + */
>> +u32 device_tree_get_u32(const void *fdt, int node,
>> +                        const char *prop_name, u32 dflt);
>> +
>> +/*
>> + * Interpret the property `prop_name` of `node` as a "reg".
>> + *
>> + * Returns outputs in `start` and `size`.
>> + */
>> +void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
>> +                         uint32_t size_cells, paddr_t *start, paddr_t *=
size);
>> +
>>  #endif /* XEN_BOOTFDT_H */
>> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree=
.h
>> index 75017e4266..0a22b1ba1d 100644
>> --- a/xen/include/xen/device_tree.h
>> +++ b/xen/include/xen/device_tree.h
>> @@ -10,6 +10,7 @@
>>  #ifndef __XEN_DEVICE_TREE_H__
>>  #define __XEN_DEVICE_TREE_H__
>> =20
>> +#include 
>>  #include 
>
> This should not be needed?

I wanted to avoid having to touch include sites. Let me check how many affe=
cted
places there are and fix up accordingly if any needs adjusting.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 14:03:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 14:03:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017294.1394268 (Exim 4.92)
	(envelope-from )
	id 1uRAQj-0001N1-Jd; Mon, 16 Jun 2025 14:03:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017294.1394268; Mon, 16 Jun 2025 14: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 1uRAQj-0001Mu-Gc; Mon, 16 Jun 2025 14:03:21 +0000
Received: by outflank-mailman (input) for mailman id 1017294;
 Mon, 16 Jun 2025 14:03: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 1uRAQi-0001Mo-IW
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 14:03:20 +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 a8261af6-4aba-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 16:03:19 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-45347d6cba3so3060205e9.0
 for ; Mon, 16 Jun 2025 07:03:19 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a568b2a6a5sm11098350f8f.74.2025.06.16.07.03.17
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 16 Jun 2025 07:03:17 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a8261af6-4aba-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750082599; x=1750687399; 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=pEtEOo3dPtG5Q3CZ9+L4F/cR8dKjHzu15YAAfWeblos=;
        b=BjIwQJpEfBl7KkhIwKBGmYP3p4nRUT92xG6AFBLJCXsnjfVRcXzLPzICKkmKxGgAao
         84lfJvKzwaq+3uXUD/N59/fJE4d2PLnqeg0Ji1Z55R20BfVpuQ7XUb99Vp7y9bNP/rip
         brYbXe2r28w0IjMKGgVXnATaqMchXUEg3hk60=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750082599; x=1750687399;
        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=pEtEOo3dPtG5Q3CZ9+L4F/cR8dKjHzu15YAAfWeblos=;
        b=km9XR8TnfrC1fxH/ruY5FKOAec5/f1ez+0/Db2x87q4b1oB3+XcjIrAebLG6DBMURs
         Yz297/NSZZMPftUaHStyHrgjk+NNVjmqcv2wUDV3NwCIeUN8ufhLA0UpCi8XT+iOzkeV
         alo05Wek6pn6iw+80mis36SFQuhjwyUclp2HgyMeCx8yjhEwkQ/WmptMuarkMqV5it+o
         pBd/EUv4EwdVlyMK8WnbzTWv7Rnyz8oz2N+/K+x0Jwi+Ipu419PxilpMENYBNzNdAo+g
         /0a5PwF7W2DkU63PjP9QVz6pncXejqoN/WYViDqDooyJxHUN+w2dJXgzKyMdbmSyuths
         okxA==
X-Gm-Message-State: AOJu0YzV+BjacQmCOXrSp3y7jEHbft4MNDcg0D7yjkxcE8NpHERpzeaf
	q85mVCDTC09RW+Ctfbiihz3qzguRgjfktnYcdp6hs0bJ9NeWoj7DXyP1pDCnoM15gfY=
X-Gm-Gg: ASbGnctbcBu7INCd2l9CMZZDt0FlfshQ3EFLoMWHx2InpraBC4kAuAIjRhDD0dGyQPv
	gbfJiWvzUC4F5EYcsmSVZN9vHixqvxmToz/j6MWueTqcyBzxrK01I90pIKRQucv87I9BldJY9S5
	hUAGKoHprKj1iyX5+vVML+V8QYAZbcj2bLLuY9Yow8GpQiZTT+TEwDiq4eOCIG20qh1sjMNs0zB
	3GVGOL1JkfYonjToYkDS6PkHG45rznKSX0HqVYKDdrlGrdsLberoBaNsT6KGJ/tT6DXrkWSTufi
	NqDdg8pnaBGodL9IWSAQUyBehPsu/RJ0CGqkTWUu7SkBUJL7gBMD718a3Z5fCwU+qua+bLPynPU
	4o4PHM0bWvd9YKIcwPB7xAxWYLQDx026ftD5XzONTC8F2wQ==
X-Google-Smtp-Source: AGHT+IGVcdSRHWnzf31oIyEOK0xRshXxIdb08Yr/8B8YUWUXjaGkBU7v+Tx3mw0wLPWxWsxTxR6Omg==
X-Received: by 2002:a05:600c:8b2a:b0:440:61eb:2ce5 with SMTP id 5b1f17b1804b1-4533cb488b5mr88651025e9.17.1750082597818;
        Mon, 16 Jun 2025 07:03:17 -0700 (PDT)
Date: Mon, 16 Jun 2025 16:03:14 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com,
	anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org,
	michal.orzel@amd.com, sstabellini@kernel.org,
	teddy.astie@vates.tech, dmukhin@ford.com
Subject: Re: [PATCH v7] xen/domain: rewrite emulation_flags_ok()
Message-ID: 
References: <20250610144500.3176661-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250610144500.3176661-1-dmukhin@ford.com>

On Tue, Jun 10, 2025 at 02:45:12PM +0000, dmkhn@proton.me wrote:
> From: Denis Mukhin 
> 
> Rewrite emulation_flags_ok() to simplify future modifications.
> 
> No functional change intended.
> 
> Signed-off-by: Denis Mukhin 
> ---
> Changes since v6:
> - simplified checks for PV further
> 
> Link to v6: https://lore.kernel.org/xen-devel/20250610004216.3012253-1-dmukhin@ford.com/
> Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/1862559089
> ---
>  xen/arch/x86/domain.c | 78 +++++++++++++++++++++++++++++++++----------
>  1 file changed, 60 insertions(+), 18 deletions(-)
> 
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index 7536b6c871..fdbd064ebf 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -743,32 +743,74 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
>      return 0;
>  }
>  
> +/*
> + * Verify that the domain's emulation flags resolve to a supported configuration.
> + *
> + * This ensures we only allow a known, safe subset of emulation combinations
> + * (for both functionality and security). Arbitrary mixes are likely to cause
> + * errors (e.g. null pointer dereferences).
> + *
> + * NB: use the internal X86_EMU_XXX symbols, not the public XEN_X86_EMU_XXX
> + * symbols.

Not sure if it's worth expanding the sentence a bit to add the reason
why X86_EMU_XXX should be used (so that we take build-time config
options into account for short-circuited emulations).

> + */
>  static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
>  {
> +    enum {
> +        CAP_PV          = BIT(0, U),
> +        CAP_HVM         = BIT(1, U),
> +        CAP_HWDOM       = BIT(2, U),
> +        CAP_DOMU        = BIT(3, U),
> +    };

You probably want to name this type.

> +    static const struct {
> +        unsigned int caps;

So it can be used here

> +        uint32_t min;
> +        uint32_t opt;
> +    } configs[] = {
> +#ifdef CONFIG_PV
> +        /* PV dom0 and domU */
> +        {
> +            .caps   = CAP_PV | CAP_HWDOM | CAP_DOMU,
> +            .opt    = X86_EMU_PIT,
> +        },
> +#endif /* #ifdef CONFIG_PV */
> +
> +#ifdef CONFIG_HVM
> +        /* PVH dom0 */
> +        {
> +            .caps   = CAP_HVM | CAP_HWDOM,
> +            .min    = X86_EMU_LAPIC | X86_EMU_IOAPIC | X86_EMU_VPCI,
> +        },
> +
> +        /* PVH domU */
> +        {
> +            .caps   = CAP_HVM | CAP_DOMU,
> +            .min    = X86_EMU_LAPIC,
> +        },
> +
> +        /* HVM domU */
> +        {
> +            .caps   = CAP_HVM | CAP_DOMU,
> +            .min    = X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ),
> +            /* HVM PIRQ feature is user-selectable. */
> +            .opt    = X86_EMU_USE_PIRQ,
> +        },
> +#endif /* #ifdef CONFIG_HVM */
> +    };
> +    unsigned int i;
> +    unsigned int caps = (is_pv_domain(d) ? CAP_PV : CAP_HVM) |
> +                        (is_hardware_domain(d) ? CAP_HWDOM : CAP_DOMU);

And here instead of using unsigned int?

> +
>  #ifdef CONFIG_HVM
>      /* This doesn't catch !CONFIG_HVM case but it is better than nothing */
>      BUILD_BUG_ON(X86_EMU_ALL != XEN_X86_EMU_ALL);
>  #endif
>  
> -    if ( is_hvm_domain(d) )
> -    {
> -        if ( is_hardware_domain(d) &&
> -             emflags != (X86_EMU_VPCI | X86_EMU_LAPIC | X86_EMU_IOAPIC) )
> -            return false;
> -        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)) &&
> -             emflags != X86_EMU_LAPIC )
> -            return false;
> -    }
> -    else if ( emflags != 0 && emflags != X86_EMU_PIT )
> -    {
> -        /* PV or classic PVH. */
> -        return false;
> -    }
> +    for ( i = 0; i < ARRAY_SIZE(configs); i++ )
> +        if ( (caps & configs[i].caps) == caps &&
> +             (emflags & ~configs[i].opt) == configs[i].min )
> +            return true;
>  
> -    return true;
> +    return false;
>  }
>  
>  void __init arch_init_idle_domain(struct domain *d)
> -- 
> 2.34.1
> 
> 


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 14:08:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 14:08:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017302.1394279 (Exim 4.92)
	(envelope-from )
	id 1uRAVx-0001wG-5l; Mon, 16 Jun 2025 14:08:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017302.1394279; Mon, 16 Jun 2025 14:08:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRAVx-0001w9-2t; Mon, 16 Jun 2025 14:08:45 +0000
Received: by outflank-mailman (input) for mailman id 1017302;
 Mon, 16 Jun 2025 14:08:43 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uRAVv-0001vy-Hz
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 14:08:43 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on2062f.outbound.protection.outlook.com
 [2a01:111:f403:2009::62f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 65ad1300-4abb-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 16:08:38 +0200 (CEST)
Received: from PH8PR20CA0024.namprd20.prod.outlook.com (2603:10b6:510:23c::19)
 by PH0PR12MB8797.namprd12.prod.outlook.com (2603:10b6:510:28d::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Mon, 16 Jun
 2025 14:08:34 +0000
Received: from CY4PEPF0000EDD7.namprd03.prod.outlook.com
 (2603:10b6:510:23c:cafe::b2) by PH8PR20CA0024.outlook.office365.com
 (2603:10b6:510:23c::19) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.25 via Frontend Transport; Mon,
 16 Jun 2025 14:08:34 +0000
Received: from SATLEXMB04.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.8835.15 via Frontend Transport; Mon, 16 Jun 2025 14:08:33 +0000
Received: from localhost (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, 16 Jun
 2025 09:08:31 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 65ad1300-4abb-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=NRDRNRCauDvkq6+OXulVGwJH49CVfemlb7qLFkvJzw2sMzPjq1B2N+Hz3qIq4wcZNfYdli3Suov+Qs464G9TvImBt4ZTU8R+TqJGR/r2pqKLMzK5FwBkmQdi5TCYd+q8eS5yA27bLpQYQ3RVnfzHJkfhMF5rr6lLPYB3LU0wjKmG73PnNnjPPswaLLOK8NAIZU1qazzqzmiqr037VULMN6IpiiPcHsV63km2rSNGcM6iv9uRlKroc9LPoYNs6/M6U3hNSc6EsoxS1mv13YQ6UHI+PXG1FqAVgJEVCk3XCjRxJx9A/8l4XaAND5N+uS03jPLC6E7I3Zwed0toFuWg7A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=o3fZjslBWIdPOqFP7dv90TaPfz4WBFA3AvqZfXgklTQ=;
 b=PLMUUi6lakIHf3FrDcNM+nOHq+og4KvQhkf/D+pHgQsrUJoh60pR/ouCJtbi1P06B1AzrZUKca2dNT50kPsFDocqAqmRQiMj9JCiZ6q7tKpFIyKkbXkcH8cNJUhC1+6voeYxoyXtxq5+QlXHZTdlDN4CvwL4kJhmCfR+jvCr65KbhWTB7viejZTpVfFV8Ivf1NhF6PQiIHa3uTJJT7MZKRxceOBx6p8qxq0dT0m/sbecB0CdiAzyDWsBtL6encKA6C2xcM2ZK93cpg5JAA6lCq9ur7Ct1Rs3egjtN8rqqZ/wnYcVLi9YRNlTCoJ9JSmdxUtIoyMM2EzVV6TajQZ55A==
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=o3fZjslBWIdPOqFP7dv90TaPfz4WBFA3AvqZfXgklTQ=;
 b=KvcR1XVQvtK1L8rRdzAfSSoKzPwMPfZCrOQxDhrD75gJzZkhdAmXxlUuj7E7xyL4jHk92FBmUxngE8H3YTr8ADAW6dAiAZ5OaFbeeUit+mT0Tl2jBuNbhX6liZ6wefOmHd/QY/CvyKkesa0XCRCm98eI78etpCX6LkDJU/lkSCs=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 16 Jun 2025 16:08:29 +0200
Message-ID: 
To: Jan Beulich 
CC: Andrew Cooper , Anthony PERARD
	, Michal Orzel , "Julien
 Grall" , =?utf-8?q?Roger_Pau_Monn=C3=A9?=
	, Stefano Stabellini ,
	"Bertrand Marquis" , "Daniel P. Smith"
	, , Xen-devel
	
Subject: Re: [PATCH v3 13/14] xen/dt: Allow CONFIG_DOM0LESS_BOOT to include
 device-tree/
From: Alejandro Vallejo 
X-Mailer: aerc 0.20.1
References: <20250613151612.754222-1-agarciav@amd.com>
 <20250613151612.754222-14-agarciav@amd.com>
 
In-Reply-To: 
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: CY4PEPF0000EDD7:EE_|PH0PR12MB8797:EE_
X-MS-Office365-Filtering-Correlation-Id: 0135fc72-b45f-4596-154b-08ddacdf47bb
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|1800799024|376014|7416014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?UHZYb2N2Z2o4U0E5ajh6MnkzYitiYlVlSXdEQXBwcVVBVE9XT0tsS1N2cHFz?=
 =?utf-8?B?TU9FVnhZL0k1TE5kd2xEajBRWDBycFJYWlVlRjJuTVNDVmxXVmQ2d3J3VVQ3?=
 =?utf-8?B?QlUyN3hBMHFhQ2dvZEI5eTY4VXRVMDUxZFl2aVM1a0N6OWpXT0w4bXpLRXFK?=
 =?utf-8?B?dkxCK0xrYVQ2NzNqTFB1SnZKVFAvb1BkZVBUaUJkV01wQWtEazdSN1lyMHJ5?=
 =?utf-8?B?Z1NBeUJTUXA5dVFVWEhQNjN1TDdhUGlYRVNRUDE4ZFdHek9NNERxVUYyRmps?=
 =?utf-8?B?ekJxUVF4aFlKTWxxM1l1SHU5UGhPcG1Ha2JoSDFXT0NBUU5vTlI0ZFBCeC9v?=
 =?utf-8?B?VExGTTBseGJKL1ZCOVp4N050RVdFNzgyZ3NML2xmZGtiR1h5SUczL3ljK1g4?=
 =?utf-8?B?ZkRxb0xVNVN3Q2V3SXFKNy9iRjY0aEkrS2R0RHZRSVpEZ1k2U0k3dzBxQUk4?=
 =?utf-8?B?N0N0bU9xakVaOHBWT00vK1ZGb28weVNYdGpndkdEdlhObVlXZDVjODNyOWYr?=
 =?utf-8?B?MnFZd0djN1dkVlpSUEppSEVUMU5jTzZ4VzJOT2FLaC9wWlZBVWpTS0ZMZEg0?=
 =?utf-8?B?NE85bm5VOWJld3NMdEplZy85QUVpWlBBN2Q4QUd3b0pxSmh2QkVtdmN6N2F5?=
 =?utf-8?B?TGhtRDdSQk9pNVRuOS96ZzNKRnJmR0lRcU1qcUFmdHFmTThiY3RXQTJ3Mm9T?=
 =?utf-8?B?VG0vR1Z0KzFzZFZwNUs5RTNteHBzZVR6aGNIRkJNYWxXNXdELzY1cXNhTHZi?=
 =?utf-8?B?dmVHZlhjYzNSbzJ6NW51SGg3azRoZ0Jzb0E2SDVJdmdudUoyRXlHcU1FcW5h?=
 =?utf-8?B?YnNleGtZVzlHUU9XdE9jOGx0ZXNaSmYvek5ucjVSY3ZSajlDT3k3YnEveUNz?=
 =?utf-8?B?eEU4RjVXeStDcXo3YnR3SVFRVkZPNkhiekFmb0grUEx0UFNsMjJNNmZzRmU5?=
 =?utf-8?B?UjVUajBQZ3Q0TmxlZTVSWVd3K212ckk2ZUNzTUorcURRcCtuMktiMGpXbUFK?=
 =?utf-8?B?NTFxZlo1Sjk2N1dlaW1XNkFFbmovdWRTQXVVTjRBMmZjN0tYbzZITFNSVFR6?=
 =?utf-8?B?VzQyOGplK2Ftdnh3VXhYY1RwSkJROXlOZE40ZkFmakZQY2tjM3ZDQ29oZkFH?=
 =?utf-8?B?d21ldDVzM2xwdnc3Vk5LNUs5TjV2alZXdXY4eVV2ajRHUzRlYy84LzVCbmZB?=
 =?utf-8?B?UzRnV1AyUnYycmpadi9DUWZZVjRlV1gxT295d2N1YUk2SlZFcjJES1JnM1hJ?=
 =?utf-8?B?U0xmYncwVjZla0h6N2pjUTRYUURNdjQ5djNlNzMxVFB1NldzWjYveUYzL0RK?=
 =?utf-8?B?UDFYOFJCN0llUjJzWGhrcGZDNk1zTmFjaFBtOVNXSy9jWXpiSWN2alhRdTBo?=
 =?utf-8?B?L2YvMm1BdWlyejRCMUFWelRXRkVQMTFHRE5lZHdSME9rUzdLYlBiaXdSVjJO?=
 =?utf-8?B?dmJ3YnI1U3luOUgrSjFHVG5PZ05OZnJxbERPKzA3TmV1Zm02WXVKSmtnUVpL?=
 =?utf-8?B?alFNKzhENzE1VjQ3WE9mUDdDMCs3M093RTZFMUdNL2Nvb0ZYOURwVm5idjB3?=
 =?utf-8?B?L2dBREwyL0dQTml0bmFIWEtVeldaNGJCZmJqL1V1OUJwNy9IS2UwOHIwS1cv?=
 =?utf-8?B?dzRnSld3cjR4SjRZVlVBOE5Td3U0Wjl4UzdEREFkNnFEaEkvZGNYdFQyZ05o?=
 =?utf-8?B?QU9IR0xDdnBGaEY5SmpGUWx3YzhUWUJrZXlyalZxRnB0NDVxTEtrV1I2Wmd2?=
 =?utf-8?B?U2hBZ0txaXN2WUJoeHkrY0RITUtOUnEwVkdUOWF2N1hmanRmNUVLcXd4WlQw?=
 =?utf-8?B?OXIxN2Y5dWZsM1dhMm1HT1ZHazZhdmNaVUpsZFlhS09qQXdhZ1IvcXdTR01q?=
 =?utf-8?B?dHdFaVZSeWxQdmdwQmNoa0gzakpKcGd5TUdpRjU4V3EwWENQQ2YxUzRtWUZq?=
 =?utf-8?B?LytQZ1dpcWREbWNuaWJIR3dxOEdGL0Y1bnplMDlSR2s1M2VQVVdPY2h2cDF0?=
 =?utf-8?B?OXZvbHpzRlVkb0JFU1BaM0FHTHQ3c2JLd2pqakM3WHNPaW9WVzA0cTR5dDlj?=
 =?utf-8?Q?3OWlV1?=
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)(7416014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jun 2025 14:08:33.6554
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 0135fc72-b45f-4596-154b-08ddacdf47bb
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:
	CY4PEPF0000EDD7.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB8797

On Mon Jun 16, 2025 at 8:55 AM CEST, Jan Beulich wrote:
> On 13.06.2025 17:13, Alejandro Vallejo wrote:
>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
>> @@ -14,6 +14,7 @@ config CORE_PARKING
>> =20
>>  config DOM0LESS_BOOT
>>  	bool "Dom0less boot support" if EXPERT
>> +	select LIBFDT
>>  	depends on HAS_DOM0LESS && HAS_DEVICE_TREE && DOMAIN_BUILD_HELPERS
>>  	default y
>>  	help
>
> Nit: Imo it is good practice to have the select-s after the "depends on",
> and perhaps also after any default(s).
>
>> --- a/xen/common/Makefile
>> +++ b/xen/common/Makefile
>> @@ -8,7 +8,7 @@ obj-y +=3D cpu.o
>>  obj-$(CONFIG_DEBUG_TRACE) +=3D debugtrace.o
>>  obj-$(CONFIG_HAS_DEVICE_TREE) +=3D device.o
>>  obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) +=3D device.o
>> -obj-$(CONFIG_HAS_DEVICE_TREE) +=3D device-tree/
>> +obj-$(firstword $(CONFIG_HAS_DEVICE_TREE) $(CONFIG_DOM0LESS_BOOT)) +=3D=
 device-tree/
>
> Why not
>
> obj-$(CONFIG_HAS_DEVICE_TREE) +=3D device-tree/
> obj-$(CONFIG_DOM0LESS_BOOT) +=3D device-tree/
>
> as we have it in a few similar situations?

Because I wasn't sure the build system would swallow it. If you claim it do=
es, sure.
I think the "firstword" version is clearer, but I don't mind.

>
> And why would the duplication be needed in the first place? Shouldn't
> DOM0LESS_BOOT imply HAS_DEVICE_TREE? Sadly the description once again
> only says what is intended, but not why. And the dependency is actually
> visible in patch context above, in the hunk altering xen/common/Kconfig.
>
> Jan

After this series the idea is that CONFIG_HAS_DEVICE_TREE means a platform
in which platform resources (memory, devices, etc) are described on DTs.

While x86 ends up understanding DTs to the extent that it's able to parse
and extract "xen,domain" nodes, it's not capable of much more than that. Th=
e
distinction is important because making x86 understand general DT (devices,=
 IRQs
and memory) would be far too invasive and not very helpful.

I can rename it to CONFIG_HAS_PLATFORM_DT or CONFIG_HAS_DT_DEVICES, or anyt=
hing
else if you (or anyone else) have any ideas.

TL;DR: It's to still be able to compile-out the bits x86 cannot use in the =
DT
machinery.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 14:12:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 14:12:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017312.1394289 (Exim 4.92)
	(envelope-from )
	id 1uRAa1-0003aW-Ks; Mon, 16 Jun 2025 14:12:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017312.1394289; Mon, 16 Jun 2025 14:12:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRAa1-0003aP-Hf; Mon, 16 Jun 2025 14:12:57 +0000
Received: by outflank-mailman (input) for mailman id 1017312;
 Mon, 16 Jun 2025 14:12: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 1uRAa0-0003aJ-Cf
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 14:12:56 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20625.outbound.protection.outlook.com
 [2a01:111:f403:2413::625])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fe8e4c23-4abb-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 16:12:55 +0200 (CEST)
Received: from CH2PR07CA0051.namprd07.prod.outlook.com (2603:10b6:610:5b::25)
 by SN7PR12MB7883.namprd12.prod.outlook.com (2603:10b6:806:32b::9)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.42; Mon, 16 Jun
 2025 14:12:51 +0000
Received: from CH3PEPF00000013.namprd21.prod.outlook.com
 (2603:10b6:610:5b:cafe::d9) by CH2PR07CA0051.outlook.office365.com
 (2603:10b6:610:5b::25) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.35 via Frontend Transport; Mon,
 16 Jun 2025 14:12:50 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH3PEPF00000013.mail.protection.outlook.com (10.167.244.118) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8880.0 via Frontend Transport; Mon, 16 Jun 2025 14:12:50 +0000
Received: from localhost (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, 16 Jun
 2025 09:12:48 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fe8e4c23-4abb-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=yZzH1sRv/Ro8GIwcU15iQ7Ru1+N9S4R2KcL26EPGW5Gh2ZG4z+SwXkt2bPwjozabLYMSAqaq8xA7fW8P2/Rb2FPZGhev/nb2u8GuTp9IDjd/ulx0ljrl0AJoMFT1y5rEXzMm3WEbMoVl6CQhHFcTeDM7uRxfFw/cm7f/LKDpj0LPsE6IpSSA2jAXETqAk6DSeEGCo2Od/IweAfxPzUdsjA5nFHJ7Mww5Qb4XYjcDUZ4CIJ81aNkrTs4/hcwrMdbz7MzeORhr/hnMBzd3tg3wQ5QSMjKjSxnVONBQ3mfLs4N8eLgZTmkElqnunV3x8AY55GTVdCZUwnSWXOwsLpXX8g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=rx7lp/ksjiw0VI7/3FfQcZx2MJDnwmnHgMFliPWDJXM=;
 b=wLX1jU5bJd4wzEJH9exZeQ0gbTwfv96uUi7qLVY0ay22nl3VN3/wo7LS85LSe4Fr7ablQW9OyyFiKNREcx0DUhK4LglQincJkZnQytDBrZ69rO26UfeNvqDMD18XJPQrI6YyPOFYwEMNFC70QxNt7nbUgvTmnYL+WPTpkPsIm5NqCCiz2EbPZp6lK3/o2FJFlBnldqMqzZTuqFb7r3btFDXCiScpU32mtkslCCp5HcS5enfxgj2CJG2hmOQGpYLp35vNdgAqBDQc+4kONVq4NYEWs4rzfwbxh62bA7WTMXfgajecx8PFkIrYw1vPFXtkB/cD2+STV46aQJgvLpXyCA==
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=rx7lp/ksjiw0VI7/3FfQcZx2MJDnwmnHgMFliPWDJXM=;
 b=GGyh05M5Ob2kQmEi/dB8O3NDTQXIyo8QEsreqEFgal81YIEEU6PxvW86PTtUSdgU3GGQ6TjFVMhVJ0G/O+w6lOy439BNxs8aC/FvA0ayJJY38lFl4AL4CVbRH88xNu2LfpZOJ1smQY4GBEJ119+DRpdCbvNlgZc+eSDJKEXMsvw=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 16 Jun 2025 16:12:46 +0200
Message-ID: 
Subject: Re: [PATCH v3 14/14] kconfig: Allow x86 to pick
 CONFIG_DOM0LESS_BOOT
From: Alejandro Vallejo 
To: Jan Beulich 
CC: Andrew Cooper ,
	=?utf-8?q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD
	, Michal Orzel , "Julien
 Grall" , Stefano Stabellini ,
	Bertrand Marquis , "Daniel P. Smith"
	, 
X-Mailer: aerc 0.20.1
References: <20250613151612.754222-1-agarciav@amd.com>
 <20250613151612.754222-15-agarciav@amd.com>
 <79722683-cd29-4b38-bd93-ef9458f95056@suse.com>
In-Reply-To: <79722683-cd29-4b38-bd93-ef9458f95056@suse.com>
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: CH3PEPF00000013:EE_|SN7PR12MB7883:EE_
X-MS-Office365-Filtering-Correlation-Id: 5375b4db-5ed2-4f17-dcf2-08ddacdfe0b9
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:
	=?utf-8?B?ZkZvaWczL2xpTVh0RDVURlZMMWpDV0Z3ck1GeUppN3R4aVBOdmVHdTVKWVVn?=
 =?utf-8?B?a2RiWjcvYkcrUklCQTNJN1BtZ25hV1VDRENWOFZPTkZtTi9oRHhUcWVFYjVp?=
 =?utf-8?B?S2ZQcVF6MEZNN2dFVWlQK1ZYTmVPMnlvTmVxSlJ3T1R6Q3dQYXhCa1lQU2xy?=
 =?utf-8?B?VWhFMDA1QmZkVjVRZHpnOG9RM1U2d0tsbWNTa2ZKUzJFZDFLVXUzTGV4cGVm?=
 =?utf-8?B?L29pTUJwU2lDa1kzNWpUOHhlT3ZIYWE5WjNJVkh5OHlVQ1VqZE43N1hCdW9S?=
 =?utf-8?B?RnFGM1hVM1JJam9nMHk3UFdIOC9ibDJla1FLbFo3VHJBdlk5UGhDb3R6anpk?=
 =?utf-8?B?eGxzTDVoakZKaHZWK29FdEZhSGVuK210N1M1SFp4MWErR1YrNmZkQy9pVk85?=
 =?utf-8?B?ZHZuNU0rU3I4MVMxRmdUcmFUWkRaRkFSNGQ2eUV6VnNpd1h4MEtOQTdPMGRL?=
 =?utf-8?B?TXY1YTVhT3BhbzNMWVdVS29ZV2xMNGtEdTBtSXJ6clNXaldCNUdLeFBDaDBn?=
 =?utf-8?B?MUlCZENzZmZnT2hEZ3oxRkwrb0h0cTdkOWJhcjJDOE5xMTBHcmVhNDBkd2hv?=
 =?utf-8?B?UlF6d0xVT3Y2cEVPdDJwM1dPYUg2M01rSkNnN2N1R3lOdXNHSEtmNXM2bHNJ?=
 =?utf-8?B?aE9HQVV3WjdDOWh6R1ZkS2tHRi9yQjJHcWJVK2tGMHg4VUVTVVFHODcrL2lw?=
 =?utf-8?B?T1JJZ3c5aXg5Z2ZlOWJEb29OWVV4bXpBZjJxL0c2TlZnaFlXb3FrSk45eCtx?=
 =?utf-8?B?NlJVQ21rSzA3cDdJK0lYQkZ0Ykpjc1pnV3huLzdoTDZoNW9Ib2Y0SG5iRHh2?=
 =?utf-8?B?c1dLNEMyWVRCSExnb1lYb3ZmcTNVdUVNNys3YWdlTFJhQmxuV3ZiWENWeEVv?=
 =?utf-8?B?VDJ5UzBaWWw1YTBNNGY0Vk9td1Z2SlFJWjNrTmN3dWFaREV3QmpscWk3R3Nx?=
 =?utf-8?B?Y2xXVUo5UitzakdoaDdBWVVNRWpLMktDK25wOHU3T1lWWlVTK0cyVkR6c0dB?=
 =?utf-8?B?cm4zaWQ0aHpLYkZaUlp0OW1qTG1hMG0wUG5ZUmlneXBvTFpNRjVHem56Smxr?=
 =?utf-8?B?aE5qMmdpZ25RSmxsUDhTWGxOcm5ZMXlNNmdwV1pyc2srUWxXSDNHOTRYU0NQ?=
 =?utf-8?B?ZHFnbk1jeEk1b0J5UWRaSVlaVzVHK1JkT1ZROFJYcGhDd284MVVESHIvUW1G?=
 =?utf-8?B?Wnoya2xKUzk3eUxTQmtOOVVDeUEvd1h1KzY4VUlyNXdDcnkwbmhQQ3cvRXpv?=
 =?utf-8?B?UHNQK0NKREVBa1BWb2hzSm5kZm9ndDUyMDZBcFMwUzZlLzgva3JUQ0hlM3RU?=
 =?utf-8?B?NmhhK1MrSnIvTUVDczQzYyswY2lHbmFQM1EvWmd2V01taGtGbHZSUlZ1SFNI?=
 =?utf-8?B?MUs3dkNpVVJjOExJZDI4Y2syZDVRbE5yN1lQN1NtMEZkZDZMSkxmbFZlTHpu?=
 =?utf-8?B?VGpLVGpxOGZxWDErSTlVb205djlGWW94Ly9jL3BWOVZIbUYxODdaaWF2b3Vh?=
 =?utf-8?B?QkJ6V21PRHRxa01URTZmN29mczVLQTIxVkpnd3VVQnQ3VThNYlBPTVdMK3JF?=
 =?utf-8?B?VVM5WEFXblQwbXcyRHp2Q21PVmk5VERzOTE4cXVkMFM3bHBVYTY2d2lvM0xO?=
 =?utf-8?B?RmF2Nko2WFNzYTNCeXFRZkhycStJTWV6eVpWdU14RDQ1K1Q4UUVMNlFpRW9z?=
 =?utf-8?B?YmtvQWg1aW5rWlllTkc4NFpUNk9SYWt2K1BoNnAvQVp6UlBleWRJRHAzaUJw?=
 =?utf-8?B?bzNBVnh3VisrOS9FcEdUbC9XK0UzTjFDdHh2K3lKQUxOVXA1YWt4Y2hvbkpU?=
 =?utf-8?B?NDA4T3JaR3dDTXRheXVZZWMvUXhLYnQycUZBaWtIdzhXQmxwQmlsVzJLSGFj?=
 =?utf-8?B?RFJlQm1DUG9nQ2lXcmUvQ1RCTTVub2Q0YXlRZTdGLzk2S0dtcDJJVU4wdTZn?=
 =?utf-8?B?ZWNaMjI2N3ZiaDloYnZZMnBsckllSzVySWNBUVJ0eWFESGtZbEYxMUdUUXc0?=
 =?utf-8?B?cllGTk9NR2l4QVZxT1VQSWRNYVZrZEFoemFPaGE4bkdNNVRNK2JNdUpzemFv?=
 =?utf-8?Q?P+CgpN?=
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: 16 Jun 2025 14:12:50.3898
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5375b4db-5ed2-4f17-dcf2-08ddacdfe0b9
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:
	CH3PEPF00000013.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7883

On Mon Jun 16, 2025 at 8:59 AM CEST, Jan Beulich wrote:
> On 13.06.2025 17:13, Alejandro Vallejo wrote:
>> Without picking CONFIG_HAS_DEVICE_TREE.
>>=20
>> In order to do that. Allow CONFIG_DOM0LESS_BOOT to enable a subset
>> of the common/device-tree/ directory. x86 doesn't want dom0less-build.c,
>> as that's tightly integrated still to the ARM way of building domains.
>
> Which then is grossly misleading: x86 also ought to select HAS_DEVICE_TRE=
E
> if it wants to use that machinery. Instead of theis an the previous patch=
,

It wants to use a _subset_. I can't use the full machinery.

> I think what we need is a new Kconfig setting to control the use of
> dom0less-build.c.
>
> Jan

It's not just dom0less-build.c. It's critical to avoid parsing device_t's
during the unflatten procedure (which is the few lines compiled out with
ifdef CONFIG_DEVICE_TREE).

Renaming CONFIG_HAS_DEVICE_TREE to CONFIG_HAS_PLATFORM_DT (with a suitable
`help` message for clarity, even though it would always be enabled) should
help clarify things.

Does that sound reasonable?

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 14:19:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 14:19:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017324.1394299 (Exim 4.92)
	(envelope-from )
	id 1uRAgM-0004G4-CL; Mon, 16 Jun 2025 14:19:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017324.1394299; Mon, 16 Jun 2025 14:19: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 1uRAgM-0004Fx-9i; Mon, 16 Jun 2025 14:19:30 +0000
Received: by outflank-mailman (input) for mailman id 1017324;
 Mon, 16 Jun 2025 14:19: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 1uRAgL-0004Fr-39
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 14:19:29 +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 e9392868-4abc-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 16:19:27 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3a361b8a664so4633147f8f.3
 for ; Mon, 16 Jun 2025 07:19:27 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b319467bd41sm3567857a12.24.2025.06.16.07.19.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Jun 2025 07:19:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e9392868-4abc-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750083567; x=1750688367; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=zVP5n4ekblcnUWvCNJVCmgzyA5qQ2D+3paM2EkBmvVs=;
        b=Elwie3kIUJj3RIQoo8081lp0X+giZBevLBG5T/w3GvEQc6Nz4DbE2aNkJPFs28ca/S
         2ATVMFiz/88BIr+A1R175WQqCt2EZve7gY3zFxoPUefq7ddAXr3qg0gmqqBnjCD6vlui
         aUVDG+SmBi/jcIs4IUrh0+kqxpVd//xvqyG2CIgisvYvS50z4WMlUXZxJQzu05DzADze
         eTMxC3sj9ON6sjGrAvfSaAz4dKFKuQ5l1axulIvLA2jAl60VYO82ip6cKaIjHtpgLHvp
         sdySCz70FE59PSAZG/ADn9uR3IMzdQk+hxYU0rht14o/zPVdGThRu2AG/DW+6bvkQOrX
         1JrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750083567; x=1750688367;
        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=zVP5n4ekblcnUWvCNJVCmgzyA5qQ2D+3paM2EkBmvVs=;
        b=DCyfg0AjMF2iq3VpiBs4IF0g7Uf7IEhQNolsRPZO8PmJk3iFciYIvwDmJYWqxZcfG0
         RIRqY4olkp0NOy26ABVUQqyzUT0mKRlsh5Q8swt1fgxYxz7ydG0/0803lnpuLfrlvp9L
         TFX0yN8NHy2UolPnh2cPc16kTdqv8gM90TbdakDnT6GPItW0KA2aewq3CI88l1R7/Vdi
         6CuWxMvw2Y3EWEKmYlAddbYJA3AcXTd7g/+QMuGWSmwBTAjGYqAGyyyUvZ7xLB62sFGA
         vg5TIY5zXbYBAkLftwBJ1MSiswLnQ07BmaLuPbnl2km30Zw5TatOmBOpxzj0Ul3YK/gO
         3BQA==
X-Forwarded-Encrypted: i=1; AJvYcCXMv4jT4ASqETvWGzHMLyGs1qk22EC8qh5EtCkhNIZFSZRMvL2LXhL3oiHQ8/e61xPIbuQgyumbzvQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzPi2nok1I4qE8j6kbaX6VlMAXGBZZyqS8/aHAY+7IXoTMzkcyE
	1u+f1q+zRt6aWJ8NQgjp1g6MotH+R2Z3e//9tyhTvSGE9l7jL9ajUirl+cHi3ajT7w==
X-Gm-Gg: ASbGncsZKgSiErYltHGaQUPp+k3hCGcxAhlZNLB3ZdBWLIwpNpHnNU5brrLKm7tKn7C
	fiVmkWNp9XaQDrkNAOQlQUgrEjAMPGMzFJI6Zx0dV8PgKpmY1x160ErJnmKdyiiAK/tsX3E83Vc
	8ncNjpuGsp+hqrH5Oae7JiQpa+XJliVpHjejeHdwjBTE4o2tiAYpUMpSYKHFrPAsiNPpMclU45c
	1eUxrki1LZRYqCilMe7SmyFM3ULcXbiaXeqRqy96K+Vx//zNZB6nzx5B3XPGnt5gYGP3B4pd2dm
	3SCJQHnidNb230BBSvPcwSnBCAOMH6zKG9Flb9+Li7wqMOvY3pRFyrtby+aiKTKBsXS2rKeXiha
	a+WUnuEUJ+j1lVpEuAJydhRPdmdnNKNEMIsfQ7T0jlzaIKfg=
X-Google-Smtp-Source: AGHT+IEGflE5Megwvd5acudINcgcqxFMTZQjxh101i/jslo9Kps0iCtpJ/A1aaLNj5QRlLVDQHNVHw==
X-Received: by 2002:a5d:64cd:0:b0:3a5:5270:c38f with SMTP id ffacd0b85a97d-3a5718b455fmr8419074f8f.0.1750083566733;
        Mon, 16 Jun 2025 07:19:26 -0700 (PDT)
Message-ID: <7581099b-96c8-4ec1-8323-8e93c3200f5b@suse.com>
Date: Mon, 16 Jun 2025 16:19:16 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 14/14] kconfig: Allow x86 to pick CONFIG_DOM0LESS_BOOT
To: Alejandro Vallejo 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org
References: <20250613151612.754222-1-agarciav@amd.com>
 <20250613151612.754222-15-agarciav@amd.com>
 <79722683-cd29-4b38-bd93-ef9458f95056@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.06.2025 16:12, Alejandro Vallejo wrote:
> On Mon Jun 16, 2025 at 8:59 AM CEST, Jan Beulich wrote:
>> On 13.06.2025 17:13, Alejandro Vallejo wrote:
>>> Without picking CONFIG_HAS_DEVICE_TREE.
>>>
>>> In order to do that. Allow CONFIG_DOM0LESS_BOOT to enable a subset
>>> of the common/device-tree/ directory. x86 doesn't want dom0less-build.c,
>>> as that's tightly integrated still to the ARM way of building domains.
>>
>> Which then is grossly misleading: x86 also ought to select HAS_DEVICE_TREE
>> if it wants to use that machinery. Instead of theis an the previous patch,
> 
> It wants to use a _subset_. I can't use the full machinery.
> 
>> I think what we need is a new Kconfig setting to control the use of
>> dom0less-build.c.
> 
> It's not just dom0less-build.c. It's critical to avoid parsing device_t's
> during the unflatten procedure (which is the few lines compiled out with
> ifdef CONFIG_DEVICE_TREE).
> 
> Renaming CONFIG_HAS_DEVICE_TREE to CONFIG_HAS_PLATFORM_DT (with a suitable
> `help` message for clarity, even though it would always be enabled) should
> help clarify things.
> 
> Does that sound reasonable?

Perhaps. The main input has to come from DT maintainers, though.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 14:23:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 14:23:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017330.1394309 (Exim 4.92)
	(envelope-from )
	id 1uRAka-0005yP-Sw; Mon, 16 Jun 2025 14:23:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017330.1394309; Mon, 16 Jun 2025 14:23:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRAka-0005yI-Q6; Mon, 16 Jun 2025 14:23:52 +0000
Received: by outflank-mailman (input) for mailman id 1017330;
 Mon, 16 Jun 2025 14:23:51 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uRAkZ-0005yC-HB
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 14:23:51 +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 853915bd-4abd-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 16:23:49 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3a57c8e247cso1269574f8f.1
 for ; Mon, 16 Jun 2025 07:23:49 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2365dea7d74sm61591235ad.152.2025.06.16.07.23.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Jun 2025 07:23:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 853915bd-4abd-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750083829; x=1750688629; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ikZ+uy/7321zHy987ZD8U0JK5yqsJpmJtPIaQKmwP1Y=;
        b=OGHIJyoPzyTqLA0LGjDwXKlcv8M5B7w8uY+SCcO68XrjlfhjgWyZbpfocRMglmEtEI
         4RNntweAZDktcakGZoF/ZCN/hxjcieXDtv0iwtFoMyVq464NfB6KJEm8FUcwnDP5Pxdt
         dyfRYXOtAIl8ELgb9RtwCCWnpQYmjUg/Ql8AP0rBiMdI3QLEHNbGJcUFZcdZFM9sOl/5
         L+kD5xEqz5oPKsfUlPCUCrOaRPybHRwsy9EJ1pYvo/aGGTuE67Kfsvkqz+cTHI627LXC
         /XBXRB6UqFmULsi8iQ+f3gS8pba/1u5rAgu+5k04x9bg0oP0OqYscAiYFPY9oBOTsf/x
         sg/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750083829; x=1750688629;
        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=ikZ+uy/7321zHy987ZD8U0JK5yqsJpmJtPIaQKmwP1Y=;
        b=SjZHaSPB+k9qTvZak28JuKb0DziOAnC3hoFPctelG4/UUt1QWaL1aR3QdGL6aEMH/I
         GUZttUW4uBeOMsoSvb7qwxaiwKWSzOxSRG/A6qb8BKv6DLtkjY/A2YCSuWw0/Y774x5R
         nfCHo/xVf9Uk5wdFQ8omi6kawCn8/UBVGFtSutgswINkRoA65K3nHhAryLev8agpH4pg
         qlO1jMkZjH789rP6ah/YECHd2rGYghkKESoFUS07JFx37dz0LzBKU9I+KI7ejykn9dlq
         La5bUwwbiBMWYCMQeD96UMglOugl0GIK/0kZJ7/GSnTaeme7We5ECxjSiupsKm8mWDG+
         m16g==
X-Gm-Message-State: AOJu0YzUG4c/8tZXPYm17c0MqDoEW16CPd6iEZTkBfwtZfMydXn2h4X7
	lbUFCk/H7AMjxzJhWI3tG1WLVBA2q3t0teXvrv4Mkpj45I3s5AuxU0GjF8KlC+ChFQ==
X-Gm-Gg: ASbGncvMNFx1CF2DsqwzORIsDjLOSZBlyVTt19ZheArb3GxdRSpDkE2mBclDbcOHVZm
	bFiccQxcR8ghWKVHxtEjyfeANsbHUWG+uFn4M4yHK+PUhKYFzaqROHfPP1CllpRBYsY1I/iYvZJ
	y7tAMlG3oXSy1B7GPaRlUkTQJ9Hpu1LxgOc2mEBr5MDL+g8vKnm6jEfAHyZjApzIKC665AkoLEE
	bH7Jw9IQ1UPmy4k5M04LA+f2FED15DPce0Qa+51GjJ1/f+vnxP57YdrPl9U2rqOuFA05+Xdd0aS
	qx5WYtyw5djPMnugCAtWx48V1OqfMYB4QB6UQmwMUxNJcHYUwGGpmuku0DYOipDKxLJmlCpRVRE
	7Uvj1Yr028KWB24Tgqq8MZSZQLilMea6l9WyFvZ8z7sdG656MfcyXrz292A==
X-Google-Smtp-Source: AGHT+IEw2+wFCttQxw8V67O46a2FNE+XdbiKrmlps/8wTagcFGcIM/mUbskwuAs/l5hBtSdglPploQ==
X-Received: by 2002:a05:6000:2507:b0:3a4:efc0:c90b with SMTP id ffacd0b85a97d-3a5723974e2mr8459803f8f.15.1750083828819;
        Mon, 16 Jun 2025 07:23:48 -0700 (PDT)
Message-ID: <9b036f26-f275-48d0-9a33-7cef38b29f48@suse.com>
Date: Mon, 16 Jun 2025 16:23:40 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] memory: arrange to conserve on DMA reservation
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper , Julien Grall ,
 Stefano Stabellini ,
 Anthony PERARD ,
 Michal Orzel 
References: <6565e881-ec59-4db4-834a-f694bf1b9427@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 16.06.2025 15:27, Roger Pau Monné wrote:
> On Tue, Feb 25, 2025 at 03:58:34PM +0100, Jan Beulich wrote:
>> Entities building domains are expected to deal with higher order
>> allocation attempts (for populating a new domain) failing. If we set
>> aside a reservation for DMA, try to avoid taking higher order pages from
>> that reserve pool.
>>
>> Instead favor order-0 ones which often can still be
>> supplied from higher addressed memory, even if we've run out of
>> large/huge pages there.
> 
> I would maybe write that last sentence as:  force non zero order
> allocations to use the non-DMA region, and if the region cannot
> fulfill the request return an error to the caller for it to retry with
> a smaller order.  Effectively this limits allocations from the DMA
> region to only be of order 0 during physmap domain population.

I can take this text, sure.

>> --- a/xen/common/memory.c
>> +++ b/xen/common/memory.c
>> @@ -192,6 +192,14 @@ static void populate_physmap(struct memo
>>           * delayed.
>>           */
>>          a->memflags |= MEMF_no_icache_flush;
>> +
>> +        /*
>> +         * Heuristically assume that during domain construction the caller is
>> +         * capable of falling back to order-0 allocations, allowing us to
>> +         * conserve on memory otherwise held back for DMA purposes.
>> +         */
>> +        if ( a->extent_order )
>> +            a->memflags |= MEMF_no_dma;
> 
> For PV domains: is it possible for toolstack to try to allocate a
> certain amount of pages from the DMA pool for the benefit of the
> domain?

Not directly at least. To benefit the domain, it would also need to be
told where in PFN space those pages would have ended up.

> I also wonder if it would make sense to attempt to implement the
> logic on the toolstack side: meminit_{hvm,pv}()?
> 
> No strong opinion, but slightly less logic in the hypervisor, and
> won't change the interface for possibly existing toolstacks that don't
> pass MEMF_no_dma on purpose.

MEMF_no_dma isn't exposed outside of the hypervisor.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 14:40:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 14:40:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017338.1394319 (Exim 4.92)
	(envelope-from )
	id 1uRB0V-0000PL-4G; Mon, 16 Jun 2025 14:40:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017338.1394319; Mon, 16 Jun 2025 14:40: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 1uRB0V-0000PE-1S; Mon, 16 Jun 2025 14:40:19 +0000
Received: by outflank-mailman (input) for mailman id 1017338;
 Mon, 16 Jun 2025 14:40: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 1uRB0T-0000P7-Br
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 14:40:17 +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 cfab5018-4abf-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 16:40:14 +0200 (CEST)
Received: from BN9PR03CA0342.namprd03.prod.outlook.com (2603:10b6:408:f6::17)
 by SN7PR12MB7204.namprd12.prod.outlook.com (2603:10b6:806:2ab::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.35; Mon, 16 Jun
 2025 14:40:07 +0000
Received: from BN2PEPF00004FC0.namprd04.prod.outlook.com
 (2603:10b6:408:f6:cafe::ba) by BN9PR03CA0342.outlook.office365.com
 (2603:10b6:408:f6::17) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.35 via Frontend Transport; Mon,
 16 Jun 2025 14:40:07 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN2PEPF00004FC0.mail.protection.outlook.com (10.167.243.186) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Mon, 16 Jun 2025 14:40:07 +0000
Received: from localhost (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, 16 Jun
 2025 09:40:00 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cfab5018-4abf-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=mHSP/lOeCPcf5A9YbQP1pzDY9ynoGoUXm+RfkihcwsTQJ/rv/UXq90QvCgjKBOAeb5qdxXbpL5SpkJmy0Kqt/vDB930IAOR67ksEtCbi9rLygXYGLFlyJeKTJ7r2gDsxoRWNne+61kA1TZrMDx8BY+HXKp/3Tu3mmgQ4U+8Zn/jSZh2L68ifNqWkuXKDqhecHM6Xuy1tiWnXrOg4f4gPc0ADtOkPD2374CG0c5o70UjnyS94YIt3+p8cAD1DsX70ctacGUnNsDy4GVJuiPdG+14xIlAst+wxYmR+yu2XVAQZJfFKCkA5WacgnNYDLiXu/wydgCucesprRRbUHzfMAA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=3qBU7Fg+QABi+iGcPxy3fjDFbaEAYIwssbUZIt3syaM=;
 b=AkElMJPTIX1VFQTKLbWTwwG30x7JCShgqCPaggtMt8jwPppPYtVr6Yf3mb+NDuCd0J+M7dCxCP1aGTzc5Q211x8U5DVb/6Mvwq8LcwoeO4em6foRH4dXMaT6emCGuOgT+ccUWbfIE7urWFNhfYRAhtRX7TXgur+qqwnW35Bl2HLQafW/EeVDdaXvctckqWywKTteLaPhxL/aTrBu/xW0+jblvNg0tAGDlE40axuSXKIFcjFbdDLWm+WVABNlg0Eolr47VRkul4yuKvnApoBekPBxBdYXROnDKdI8IDzyNVxdvRW3eJv7B9xR6A/IP6CNBzEzISrtLvbTWyCmPN2xDQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=temperror (sender ip
 is 165.204.84.17) smtp.rcpttodomain=xen.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=3qBU7Fg+QABi+iGcPxy3fjDFbaEAYIwssbUZIt3syaM=;
 b=kHhwP/2xCX6J1rY8fa21pR3VFbOi3G90Gor3kLkLRlE8eI5q7Zy2y27V/2xDUeWqslhjzVEwEmnOz6URNLhV6nqgdFe+agZP8yiltutxd5vHouN17tQsH/EeIDSxCWR1XJ1zpE4OEXgcT/inEfst63/GWCjCBye/5WcR1Xe6HWc=
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)
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 16 Jun 2025 16:39:59 +0200
Message-ID: 
CC: Jan Beulich , Andrew Cooper
	, =?utf-8?q?Roger_Pau_Monn=C3=A9?=
	, Anthony PERARD , "Michal
 Orzel" , Stefano Stabellini ,
	Bertrand Marquis , "Daniel P. Smith"
	
Subject: Re: [PATCH v3 14/14] kconfig: Allow x86 to pick
 CONFIG_DOM0LESS_BOOT
From: Alejandro Vallejo 
To: Julien Grall , 
X-Mailer: aerc 0.20.1
References: <20250613151612.754222-1-agarciav@amd.com>
 <20250613151612.754222-15-agarciav@amd.com>
 <2a54e49b-c1ad-4654-9291-4373e92580ff@xen.org>
In-Reply-To: <2a54e49b-c1ad-4654-9291-4373e92580ff@xen.org>
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: BN2PEPF00004FC0:EE_|SN7PR12MB7204:EE_
X-MS-Office365-Filtering-Correlation-Id: 5a6d5e9f-a1b3-4d95-81b6-08ddace3b055
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?ZUVWT2pTbS9JNXFxdEhvY0dLZTRySnBPeTZ1STZrcFNLVSthb21paWt1VjFV?=
 =?utf-8?B?ekFKcXlvanhpa3QvRUx2dDRINmdPQkY1YW5kWFhMUFRGb1JCMWNiMFV2M3pB?=
 =?utf-8?B?dnZxMXAvZzk0T2tDS2pSVFZoQ1BNUjdnMHpHdll4VkFrb1VGSnltVnN6a1M1?=
 =?utf-8?B?NlhVZkU2UjZ3SDR5bnFYdUlBQVkvR3RzaVBXKzA2c0Z2VTZPTXhFNnBzZGw4?=
 =?utf-8?B?TGRTS3ZEMmgxUnlsenNnNGFqTFlTYmxUdnJ3ci9qZWlkQXJiMnAzSTNMZkI0?=
 =?utf-8?B?QkZSOTFWdWNOT1poNml4OGJ1N1hoZExIK2pRVXFldGwzS1FVT0hPQVJKeEZv?=
 =?utf-8?B?cDloallOQS9meG5JZzRpR24velVnell0Qy9DT0U0d0dYLzJaaWc4bUowZllt?=
 =?utf-8?B?clE4bWhkLzNOZnNXVWxCSW1ncjVaQ2dJL3JtT29BTzk1bG5UbTJIQjlmUVFG?=
 =?utf-8?B?RW16dElXTllvZkphUHZCdVpFZ0RMVGJ3by9QMlV4bkt3ZmgxTUpuNGM3ZWx6?=
 =?utf-8?B?cVE0WGRRRWNBRzViWkFldUZkMFlPZkFPbXBKTDZxWTgzSVo0eVhxSUVxNmJq?=
 =?utf-8?B?UkFRaUQ0WVVvdDZ6OUNIYmhmYXRrcGJOTy92R2t4bm81cmdScWJTcGVvZUFs?=
 =?utf-8?B?QlF0bjJqbFZ5cDA4QjQ2ZStaaG1qck90cWVBditidS8yVzJpTmc2akF2LzFB?=
 =?utf-8?B?aFhZNERzZ2pkN0FmeWdUK2ZyaXRxMUdjWjZvVWpoaW1PY2xrVWprNHVQL0pu?=
 =?utf-8?B?TmNYMDBQYnFMZUVHNlNpMmhHUG9UM2RyNmdhWDNCajUybnZlL25JQm9rNStS?=
 =?utf-8?B?cm8yd1JKaCs4bms3NTFDRWxrREhxc0ZCR0xNc09pQXUxYXVMWmNTVmdwQUdB?=
 =?utf-8?B?Q2o1RjdUcGdhY3I0WWVjYktiQ2pNNFpHSUdlR2dOMXo3NzF2bjFpTGpTQmRz?=
 =?utf-8?B?TXpXQTJkVGpOUEV0bDBHdlI2OHJHRnRPQWJuQVpJSW5Rd2dhSWVGWlYwUU9L?=
 =?utf-8?B?cWdKckVUYVRpU0FmbXJiNmRkcFdHSkJEZFVjSjFqYmpPaEp5eG5jcXgzZFF2?=
 =?utf-8?B?dnY4VVJ6NWhMWXhQeDJLay9RMklLejA2aXdGa05QTVRJejdzSWRFWjJkNDZm?=
 =?utf-8?B?ZGg3NWlIOFl5N1hiaVRCb0JsUGZwT2J3T2RMWmpSWm01UlZTV2hpSXdUZ2F2?=
 =?utf-8?B?NDd3M3FtQ0NJbExjcm5jdytUOEFldkdNYXJsQm40bW1ySGhRaDJRLzNWdG5x?=
 =?utf-8?B?bVFuM2ZYMUZUT3U3QkI4K1lPOU9kOHBzSlVFSlRpckpQRXNWdmdIbTFTMkdr?=
 =?utf-8?B?UWtVMzIrRW8zYjZIMFAxUEpERExRN2JnZmtnaFVFRFlwNTArak9rbWlSd1Bu?=
 =?utf-8?B?MVJ1MG1oOU40QlkzeGVsbjNwUXRtR3BQazNkZWx6L2ZrOEZTVWpGbGlqeEcv?=
 =?utf-8?B?cWdqamo3MWxuZ1JBYWJxaHd4VUNWdFMvRzRvcUFwaFh1ZExLT09JR3JEcDRj?=
 =?utf-8?B?MXl5OUwxOUdlNHJOaElWbU5sUVpkbk8rNTZNcjFvUktKUHVQdGR4MDNGdjdy?=
 =?utf-8?B?N0oxODRVTjJmL1c3T1piVzJ4RkNRQzFmZ2hwTXVmTEFLMHoyTXZXaXlpbElm?=
 =?utf-8?B?Wjh6Y09OQnczZWhNQ3lJbjVGYXNMdGhaUklqWmUwY3hWQnJKaS8xQUQ4MjRD?=
 =?utf-8?B?YlExQTE1aGxNNkVZQTNmNW9zTEdHUWRFY1Evb29EdnBjSUFpenYyUUhTNXlE?=
 =?utf-8?B?NUVhdDI1TGFhWFNuS3BMVVFVTzl2c0xwbXZRMmhkaGVYNFRDM0lCTnZVRS96?=
 =?utf-8?B?SWp1YTYra2NiQ3NmMitNei9tWHp2eU5qUzBhQmJoemRiSis3V0lkUGFCQnhs?=
 =?utf-8?B?RW9NMndPZE1CK29pdkpmTy9jZC9kVVhEajhEcGFaYndRZnlLNXlpNGJoL2tV?=
 =?utf-8?B?NUljTm9qTGEwTExscXRtVHVRUGlMbk9IL0JNa29ObjZrSitkcHp1NlFMdFho?=
 =?utf-8?B?dVNVQjc5d29Zajd5NFhDUXY0ZFBaQkVPQklEdWFHblFYUGpLVzFVNGdYa1BG?=
 =?utf-8?Q?qSnWJo?=
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: 16 Jun 2025 14:40:07.2003
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5a6d5e9f-a1b3-4d95-81b6-08ddace3b055
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:
	BN2PEPF00004FC0.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7204

On Mon Jun 16, 2025 at 10:00 AM CEST, Julien Grall wrote:
> Hi,
>
> On 13/06/2025 16:13, Alejandro Vallejo wrote:
>> Without picking CONFIG_HAS_DEVICE_TREE.
>>=20
>> In order to do that. Allow CONFIG_DOM0LESS_BOOT to enable a subset
>> of the common/device-tree/ directory.=20
>  > x86 doesn't want dom0less-build.c,> as that's tightly integrated=20
> still to the ARM way of building domains.
>
> I don't understand this argument. dom0less-build.c was moved to common=20
> and it will soon be used by RISC-V. This raises the question what's so=20
> special with x86?

That's 2 separate matters:

  1. dom0less-build.c not being compiled in.
  2. CONFIG_DOM0LESS_BOOT enabling use of DT code without CONFIG_HAS_DEVICE=
_TREE.

(1) is a matter of not wanting to boil the ocean upfront. The way x86 and
everyone else build domains is just different and duplicated in non-trivial=
ly
consolidable ways. The goal here is to enable the domain builders in any ar=
ch
to use the same backbone. I don't want to go the extra mile just yet to uni=
fy
domain construction (though in time I will want to).

(2) has to do with compiling OUT things I really cannot have around. Anythi=
ng
involving devices described in a DT must not exist on x86, because it has n=
o
concept of a "struct device".

My intent is/was to repurpose CONFIG_HAS_DEVICE_TREE to mean "this hypervis=
or
goes on a platform that gives a platform-describing DT". On x86 that's give=
n by
DSDT/SSDTs with ACPI.

>
> Note I don't particularly care if you don't want to use it on x86.=20
> However, the argument provided is lacking some details... This will be=20
> useful in the future if someone thinks about consolidating the two.

I very definitely will want it all unified, but I'm working one elephant at
a time.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 14:46:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 14:46:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017345.1394329 (Exim 4.92)
	(envelope-from )
	id 1uRB6c-0001BG-Ob; Mon, 16 Jun 2025 14:46:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017345.1394329; Mon, 16 Jun 2025 14:46: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 1uRB6c-0001B9-LB; Mon, 16 Jun 2025 14:46:38 +0000
Received: by outflank-mailman (input) for mailman id 1017345;
 Mon, 16 Jun 2025 14:46: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 1uRB6b-0001B3-JI
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 14:46:37 +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 b1ae7ba0-4ac0-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 16:46:32 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a4e742dc97so3714052f8f.0
 for ; Mon, 16 Jun 2025 07:46:32 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a568a800d9sm11157887f8f.45.2025.06.16.07.46.30
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 16 Jun 2025 07:46:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b1ae7ba0-4ac0-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750085192; x=1750689992; 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=kDup5PmZLZjol1hr4+Jh9CeqzezFF4lo5IwNGLjG2Gw=;
        b=OCQ1MV4+697vBQxfCHBdA/JfbhjioWJf2xQptVq37GOwUWKY1vfzeKdT1VV0gvQlom
         sHgBFGnpaoGUUhcLssEZPf5ei5ryDgNv3lWYu+3Isk/4BIb0wBjto2Gw8ymIUPhzA2mg
         rTKXJxuLxcSu8XJtEQHuHU8ZL3XUYP6VjUT+k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750085192; x=1750689992;
        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=kDup5PmZLZjol1hr4+Jh9CeqzezFF4lo5IwNGLjG2Gw=;
        b=bjYfj2gS7zl97ABOHxkKJhur/wRvFVxjfKYArF8uvx/LKSPUg/8StugCbXwkHPbjkG
         PbsbZz0EG6AmnFqvR3swlkHUXWnkSzlnj5ddX2jfw9GeMmwqBVarJOIAbM/r1rD5JpzE
         bOArpy8uZIOXyesIiVYr7JW93sDPYnBsZgvZI4uFCOWrDuQAFmqYZFHmz31RvjnkizOl
         GwmEkPrO0dJrgXHGjMYrOx9YP5z7jiYRhBi9tKwGmVPWdMLJ4JiftfWbDy3mWEdoXW2G
         NgTbx1MgV/sHOB52NC6VeRU+PxnOkdbY10hA9x95NIKqNXmfPDj8741s6rlVmIl+5ae9
         jgkg==
X-Gm-Message-State: AOJu0Yzz45k0un+ot0+bYAoVBjPc7MHdLd2SYFORNHDZlrkFHre1WgZ2
	JvxWmau3R/Mn1sdmTcyHGPDmY4I3l/ENcbHwBGXWpVCEvYjUcmWcRyQI/oiK0Lo7tC4=
X-Gm-Gg: ASbGncvYfRIqlnxFWuNaLV1cDOwIytX0dhptJ8W32n+y6fkTqSYbGtYcqIoNym1lYbW
	/xXLJ9D12vTlJGOseRIEhhGqmy9YCMK11odOAfb5Jdtr8ots06woyrtniL6EFiQDRFp31Hn7Gbr
	Dwnjozl7Det3d4xGvAYrl3ZBIWq1UBbN/HhL0BjvbgJLyW2Uevb269JA/0hzoDISktKCz/YpYKA
	7IOJRIFoefxI9pRm6V4zuv5ujsmlzg5iGeTTDHb0mBvlnQeVC4xiW7JRkGZXwf3eDljExz/Flzi
	H6ucLa+uqYajs3yZxisohuCP6C1IzjmTPlGUAYEY3hon7nwCwqls6r5owOOZXFwYR3h0eGL8J2s
	hXyHyQ/KROl+YERrX48g0/XNuRMhzMAwjNC0=
X-Google-Smtp-Source: AGHT+IFIX/J69NlQgNq/gTfyxowuZT/8nib312hnAvvrzv4gS1wYr8D00jB1Q1ayE7bgEvVAcQEzdQ==
X-Received: by 2002:a5d:64c3:0:b0:3a4:f6f2:65e9 with SMTP id ffacd0b85a97d-3a572e7509cmr8228576f8f.19.1750085191856;
        Mon, 16 Jun 2025 07:46:31 -0700 (PDT)
Date: Mon, 16 Jun 2025 16:46:29 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" ,
	Andrew Cooper ,
	Julien Grall ,
	Stefano Stabellini ,
	Anthony PERARD ,
	Michal Orzel 
Subject: Re: [PATCH] memory: arrange to conserve on DMA reservation
Message-ID: 
References: <6565e881-ec59-4db4-834a-f694bf1b9427@suse.com>
 
 <9b036f26-f275-48d0-9a33-7cef38b29f48@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <9b036f26-f275-48d0-9a33-7cef38b29f48@suse.com>

On Mon, Jun 16, 2025 at 04:23:40PM +0200, Jan Beulich wrote:
> On 16.06.2025 15:27, Roger Pau Monné wrote:
> > On Tue, Feb 25, 2025 at 03:58:34PM +0100, Jan Beulich wrote:
> >> Entities building domains are expected to deal with higher order
> >> allocation attempts (for populating a new domain) failing. If we set
> >> aside a reservation for DMA, try to avoid taking higher order pages from
> >> that reserve pool.
> >>
> >> Instead favor order-0 ones which often can still be
> >> supplied from higher addressed memory, even if we've run out of
> >> large/huge pages there.
> > 
> > I would maybe write that last sentence as:  force non zero order
> > allocations to use the non-DMA region, and if the region cannot
> > fulfill the request return an error to the caller for it to retry with
> > a smaller order.  Effectively this limits allocations from the DMA
> > region to only be of order 0 during physmap domain population.
> 
> I can take this text, sure.
> 
> >> --- a/xen/common/memory.c
> >> +++ b/xen/common/memory.c
> >> @@ -192,6 +192,14 @@ static void populate_physmap(struct memo
> >>           * delayed.
> >>           */
> >>          a->memflags |= MEMF_no_icache_flush;
> >> +
> >> +        /*
> >> +         * Heuristically assume that during domain construction the caller is
> >> +         * capable of falling back to order-0 allocations, allowing us to
> >> +         * conserve on memory otherwise held back for DMA purposes.
> >> +         */
> >> +        if ( a->extent_order )
> >> +            a->memflags |= MEMF_no_dma;
> > 
> > For PV domains: is it possible for toolstack to try to allocate a
> > certain amount of pages from the DMA pool for the benefit of the
> > domain?
> 
> Not directly at least. To benefit the domain, it would also need to be
> told where in PFN space those pages would have ended up.

My question makes no sense anyway if MEMF_no_dma isn't exposed to the
hypercall interface.

> > I also wonder if it would make sense to attempt to implement the
> > logic on the toolstack side: meminit_{hvm,pv}()?
> > 
> > No strong opinion, but slightly less logic in the hypervisor, and
> > won't change the interface for possibly existing toolstacks that don't
> > pass MEMF_no_dma on purpose.
> 
> MEMF_no_dma isn't exposed outside of the hypervisor.

Oh, I see.

One question I have though, on systems with a low amount of memory
(let's say 8GB), does this lead to an increase in domain construction
time due to having to fallback to order 0 allocations when running out
of non-DMA memory?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 15:13:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 15:13:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017361.1394339 (Exim 4.92)
	(envelope-from )
	id 1uRBWe-0005OB-Mf; Mon, 16 Jun 2025 15:13:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017361.1394339; Mon, 16 Jun 2025 15:13:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRBWe-0005O4-Ir; Mon, 16 Jun 2025 15:13:32 +0000
Received: by outflank-mailman (input) for mailman id 1017361;
 Mon, 16 Jun 2025 15:13: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 1uRBWd-0005Ny-40
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 15:13:31 +0000
Received: from perceval.ideasonboard.com (perceval.ideasonboard.com
 [213.167.242.64]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6e6a286f-4ac4-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 17:13:18 +0200 (CEST)
Received: from pendragon.ideasonboard.com (81-175-209-231.bb.dnainternet.fi
 [81.175.209.231])
 by perceval.ideasonboard.com (Postfix) with ESMTPSA id 357B7346;
 Mon, 16 Jun 2025 17:13:13 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6e6a286f-4ac4-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;
	s=mail; t=1750086793;
	bh=0HNCExAqJ+LaxU1ueCxhXgS3CX0/GTT4qiqhOCeleZE=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=cd+rEl4LeP/ZHIM4gWEMYhjqXD0/rin9VjD52OOHdZvIkqhRoZaWZn00QN6bJnKA6
	 pVExi1IbQLR4xfrlBC/dpwg8ODX0SRU7pxY8ZM2CFH8LzJOKfAccxMJQ+5H54VHgVS
	 rCMxoyNkNFjfyxiC7+vvZacma5jP5aesiq8AWwhs=
Date: Mon, 16 Jun 2025 18:13:09 +0300
From: Laurent Pinchart 
To: Thomas Zimmermann 
Cc: simona@ffwll.ch, airlied@gmail.com, mripard@kernel.org,
	maarten.lankhorst@linux.intel.com, geert@linux-m68k.org,
	tomi.valkeinen@ideasonboard.com, dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org, freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org, imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org, nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev, spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v5 25/25] drm/xlnx: Compute dumb-buffer sizes with
 drm_mode_size_dumb()
Message-ID: <20250616151309.GF10542@pendragon.ideasonboard.com>
References: <20250613090431.127087-1-tzimmermann@suse.de>
 <20250613090431.127087-26-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250613090431.127087-26-tzimmermann@suse.de>

Hi Thomas,

Thank you for the patch.

On Fri, Jun 13, 2025 at 11:00:44AM +0200, Thomas Zimmermann wrote:
> Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
> buffer size. Align the pitch according to hardware requirements.
> 
> Signed-off-by: Thomas Zimmermann 
> Cc: Laurent Pinchart 
> Cc: Tomi Valkeinen 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/xlnx/zynqmp_kms.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c b/drivers/gpu/drm/xlnx/zynqmp_kms.c
> index b47463473472..7ea0cd4f71d3 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_kms.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -363,10 +364,12 @@ static int zynqmp_dpsub_dumb_create(struct drm_file *file_priv,
>  				    struct drm_mode_create_dumb *args)
>  {
>  	struct zynqmp_dpsub *dpsub = to_zynqmp_dpsub(drm);
> -	unsigned int pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
> +	int ret;
>  
>  	/* Enforce the alignment constraints of the DMA engine. */
> -	args->pitch = ALIGN(pitch, dpsub->dma_align);
> +	ret = drm_mode_size_dumb(drm, args, dpsub->dma_align, 0);
> +	if (ret)
> +		return ret;
>  
>  	return drm_gem_dma_dumb_create_internal(file_priv, drm, args);
>  }

-- 
Regards,

Laurent Pinchart


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 15:14:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 15:14:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017366.1394349 (Exim 4.92)
	(envelope-from )
	id 1uRBXE-0005oS-V9; Mon, 16 Jun 2025 15:14:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017366.1394349; Mon, 16 Jun 2025 15:14: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 1uRBXE-0005oL-RN; Mon, 16 Jun 2025 15:14:08 +0000
Received: by outflank-mailman (input) for mailman id 1017366;
 Mon, 16 Jun 2025 15:14: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 1uRBXD-0005jp-6c
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 15:14:07 +0000
Received: from perceval.ideasonboard.com (perceval.ideasonboard.com
 [213.167.242.64]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8b661730-4ac4-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 17:14:06 +0200 (CEST)
Received: from pendragon.ideasonboard.com (81-175-209-231.bb.dnainternet.fi
 [81.175.209.231])
 by perceval.ideasonboard.com (Postfix) with ESMTPSA id 55562346;
 Mon, 16 Jun 2025 17:13:54 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8b661730-4ac4-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;
	s=mail; t=1750086834;
	bh=aNDbKOOjHpsSVm/u+QK5zaGokrrj0d/sOrb/9/P49gE=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=QM67Xzx99jtSxFtbVWkxi9ny3lkeshszCYykwUWs4y08YnSKdKJ/O207ngwOCheOQ
	 TcS9TWQkg/ZF3B5IT/PRnJdD6ZeF54pordOC63Upxph3fPlOeSwafp7l71BiZ0xPAD
	 TAv/k4j+OiUsCXXAJRp6zom83aLOsyaQGJY4FajI=
Date: Mon, 16 Jun 2025 18:13:50 +0300
From: Laurent Pinchart 
To: Thomas Zimmermann 
Cc: simona@ffwll.ch, airlied@gmail.com, mripard@kernel.org,
	maarten.lankhorst@linux.intel.com, geert@linux-m68k.org,
	tomi.valkeinen@ideasonboard.com, dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org, freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org, imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org, nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev, spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org,
	Kieran Bingham 
Subject: Re: [PATCH v5 17/25] drm/renesas/rcar-du: Compute dumb-buffer sizes
 with drm_mode_size_dumb()
Message-ID: <20250616151350.GG10542@pendragon.ideasonboard.com>
References: <20250613090431.127087-1-tzimmermann@suse.de>
 <20250613090431.127087-18-tzimmermann@suse.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250613090431.127087-18-tzimmermann@suse.de>

Hi Thomas,

Thank you for the patch.

On Fri, Jun 13, 2025 at 11:00:36AM +0200, Thomas Zimmermann wrote:
> Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
> buffer size. Align the pitch according to hardware requirements.
> 
> Signed-off-by: Thomas Zimmermann 
> Cc: Laurent Pinchart 
> Cc: Kieran Bingham 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> index 4c8fe83dd610..dd353fb858ef 100644
> --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> @@ -11,6 +11,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -407,8 +408,8 @@ int rcar_du_dumb_create(struct drm_file *file, struct drm_device *dev,
>  			struct drm_mode_create_dumb *args)
>  {
>  	struct rcar_du_device *rcdu = to_rcar_du_device(dev);
> -	unsigned int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
>  	unsigned int align;
> +	int ret;
>  
>  	/*
>  	 * The R8A7779 DU requires a 16 pixels pitch alignment as documented,
> @@ -419,7 +420,9 @@ int rcar_du_dumb_create(struct drm_file *file, struct drm_device *dev,
>  	else
>  		align = 16 * args->bpp / 8;
>  
> -	args->pitch = roundup(min_pitch, align);
> +	ret = drm_mode_size_dumb(dev, args, align, 0);
> +	if (ret)
> +		return ret;
>  
>  	return drm_gem_dma_dumb_create_internal(file, dev, args);
>  }

-- 
Regards,

Laurent Pinchart


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 15:21:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 15:21:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017375.1394359 (Exim 4.92)
	(envelope-from )
	id 1uRBdo-0007cp-IZ; Mon, 16 Jun 2025 15:20:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017375.1394359; Mon, 16 Jun 2025 15: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 1uRBdo-0007ci-G1; Mon, 16 Jun 2025 15:20:56 +0000
Received: by outflank-mailman (input) for mailman id 1017375;
 Mon, 16 Jun 2025 15:20: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 1uRBdn-0007cc-JQ
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 15:20:55 +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 7e9a727e-4ac5-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 17:20:54 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3a361b8a664so4715099f8f.3
 for ; Mon, 16 Jun 2025 08:20:54 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-748a0666b1asm4827962b3a.144.2025.06.16.08.20.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Jun 2025 08:20:53 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7e9a727e-4ac5-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750087254; x=1750692054; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=TT5s+oHcVGNzryxf6YZ1fu7yLxh41sfErOzsIMk8gCs=;
        b=BHif7o8BOr4dCM6p4PUCZH0Gy0gmaqFxrXvQFx1ajtmiADjkHc1vXjLHN9ouCNe6yV
         xTvjz0KT4AvwfcUUe226HgYqTU30noVlOzATYklZckqQ9sWZFbekvEzL2IgzsBzHH1GY
         NzJQAic00QbYGfuOtegrey5wP1ubT9MIARCMCGeOjlfvQs0ST22bqCP2IxH96fB+J6c5
         fU/egXcE5GaGkMhlDFW++iy/vWhNB/S15LnhhvASy+miIyAai1pRgLC7OgPa2THIJFQO
         Sq4MW7qJkJ7k5Z4QaQT0/HWkKbw9SZPfzlmqDfdsZrq4DBPdXyqDPS5qVgXjy9ZEPaSA
         vxnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750087254; x=1750692054;
        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=TT5s+oHcVGNzryxf6YZ1fu7yLxh41sfErOzsIMk8gCs=;
        b=iSuRCQWP//7/kBs/jjTirg23YsGiab0fud21iZk3+dDVMlIZwioDGIRvxL/WQ3la6u
         cTmkekUi1SReUhv8aAF5Zps9estd9z/Y/I60fp/mJqlOStsdFAtaXB7X8xAomya+9nXL
         e1CsUhOt8p7WVoqQKbCXseUIfDavc3F7dvIhNYboV8mrEMmywUgJK/BtPsRxxBM6gKCI
         uqed/K/J+uTlbFpuiKfYp7pgfGTWezXJMXu1uJXvBtXG6ssd1c0m/baSdpAs01VGnW0R
         t0hEZE8L4VNRHy1mPh0MSy7H3Ez3XmkuWyksbq4xDjjN3eGWl4zitiJ0YQxj5AKZaQg5
         stPQ==
X-Gm-Message-State: AOJu0YzMnA+EYY5UHGv13A+JZ3Nsh28GHY11zf3WnXg1EEJfL2OcOEj1
	O++KhZdjCN83TLCZ07uGhZ24gHCP1cwXARGwaZlztyBfe2NHhf6+fBcM3SqYPaqaBg==
X-Gm-Gg: ASbGncvDOnD8TAimtOmUnjOoNmZ5c9FtbEaXSjvic/DSYG3dDzc70XnV6cBJWE74rJu
	iTX2ebcBKc0lYOK4l9R3Ytn+7E/mx2g/1O8mpG6YxZKIxk94p8E/ONgabJQUtyvDaPW9VmTMYI7
	51NDTTGwPPAOmps13mqvqbWiOvI+Ytg9RTnAS4uNRU43buKCoWsd9GVAoyKh3Pf5geAIl8GPsNp
	kM4T3dxI/fxSIyhA9N3nJ2ULQIiqHfSTMVjqSRRnM6zfjPnR5WF82JPhv11OdFn4ECw5fTaNQ3B
	q+qw6TWiBmj94Ejk0Er01i+VyVIS3nODqFMRl7IwAZuX5fPuWveYQUUacvyytrXrCbunoCr4rmN
	TDneXcc98rIPpzT0tHAoxcprKIVKe5uJXefxNutI5iPO7T9U=
X-Google-Smtp-Source: AGHT+IEohTIro7OLRx0dRZJXCQqrUawQA4y0yGYEom+Y0W2oF5WpH+gPufMdjJH1TyByEoha/7mq9w==
X-Received: by 2002:a05:6000:288d:b0:3a4:e4ee:4c7b with SMTP id ffacd0b85a97d-3a5723a3ad5mr8307496f8f.15.1750087253647;
        Mon, 16 Jun 2025 08:20:53 -0700 (PDT)
Message-ID: <2969b5d8-5879-4674-8332-046898e17257@suse.com>
Date: Mon, 16 Jun 2025 17:20:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] memory: arrange to conserve on DMA reservation
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper , Julien Grall ,
 Stefano Stabellini ,
 Anthony PERARD ,
 Michal Orzel 
References: <6565e881-ec59-4db4-834a-f694bf1b9427@suse.com>
 
 <9b036f26-f275-48d0-9a33-7cef38b29f48@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 16.06.2025 16:46, Roger Pau Monné wrote:
> One question I have though, on systems with a low amount of memory
> (let's say 8GB), does this lead to an increase in domain construction
> time due to having to fallback to order 0 allocations when running out
> of non-DMA memory?

It'll likely be slower, yes, but I can't guesstimate by how much.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 15:38:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 15:38:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017389.1394388 (Exim 4.92)
	(envelope-from )
	id 1uRBv0-0001YI-F2; Mon, 16 Jun 2025 15:38:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017389.1394388; Mon, 16 Jun 2025 15:38: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 1uRBv0-0001YB-Ba; Mon, 16 Jun 2025 15:38:42 +0000
Received: by outflank-mailman (input) for mailman id 1017389;
 Mon, 16 Jun 2025 15:38: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 1uRBuy-00015n-Fp
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 15:38:40 +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 f9dca812-4ac7-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 17:38:40 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3a507e88b0aso4574630f8f.1
 for ; Mon, 16 Jun 2025 08:38:40 -0700 (PDT)
Received: from gmail.com (140.red-213-97-47.staticip.rima-tde.net.
 [213.97.47.140]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a57b15015fsm5707473f8f.95.2025.06.16.08.38.37
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 16 Jun 2025 08:38:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f9dca812-4ac7-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750088318; x=1750693118; darn=lists.xenproject.org;
        h=content-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=4alejBC53+f14BfESAdUdsqdGSmpK0SJqs5nxYK3Y5U=;
        b=g/0TBfcqZZpyzl2HxWDOcEikhQHAVDHU5dv/AD9TGN3iZ+l1G2xWHxh4Q6f5GD8aIi
         IlldtUhkA4Mpxy3kDr3yAtZjbG6UyuLHkkveXIGX6VLKVUWeLILahZDgZgeBo5q3Lbgo
         AJxGNG3cvRcLlm/FLXye5VV8YBcoWjgCsTclOcHndooKVUrpAr1Q4CD65WRkanrTWB7s
         d7b0XPj/xXLIDzABUSW3V09fHN8qlxEM2q2YsxuvGlNcb2b49eoeSxxL3WAIQ4kMmEn0
         dSZK8jp1/0dVsQBLgDO5I+i9+U91b4fwdB+SpWSDFEMsIIDrk+dORj7Spp5np5usN8fA
         geNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750088318; x=1750693118;
        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=4alejBC53+f14BfESAdUdsqdGSmpK0SJqs5nxYK3Y5U=;
        b=a201GfMBFSwVCjOuc1PmDrejcFrQ96JiZTpEvAZURTU2fMoQN1K1PhMgTiKLOhFi2V
         tAK8k9KluoUQ7njslCSdVE6/2A3P5W5XDY8csY1TClcxVOXlUE9OoUO5suQi7X2LzS+z
         ePJ4Eju5wBsdtZ8EjDZvHoGECX/LbEclp1pA/LK/UU7Azri9SsQ4zKtd2FOINyBY0dLT
         lSIKiGMx4v7Zj5TNsj7E9680dlqNZ0SR0WeRp+0KUloMa1hbYYMS8UkXZF/haLBpG7qX
         hYbmJt01vORHsrjMz5/yYC26luIzIZKE0UKG7oV2igaNpsREle+mJh3JBla7zcYO/1qI
         no5g==
X-Gm-Message-State: AOJu0YyCDoXcf5mLw7aEtzu4gJfHJyS2ewd+vSWL/10q4gDHdODeXAF4
	QatxtwNF+epjkatAfxQY3m3jl8IPCGmEbq1uVxxX9Jt+YU3dW1RZ/yfJAKwARlJh9zU=
X-Gm-Gg: ASbGncvck1OpoQ9CyRtBTqfJ3rQuGNZZZxpYDaq+ZH8mvh2UHuQebg51acKQ7DKnfAK
	Zjawmtq6FIxFrkB1F7Xux3+FDKOHJh4T/4DCsCzGuxlxRnFL1DXX4KxLkD0llM5dFcv1o9T1B2G
	4mOMoWVpoSZHMRA7kA3h9gpBGVwDEsFQ6tl4zlhYXG1/C0wVOiko6m/OEusvjOqzN87BSS374Ko
	NExd8IJLUCDaHl2GXpRnE+8t3urEXKmdl1GeRx8l57YXjaJZCiQxZ47n27gF9RvfRrtbuATSnEv
	sWNeeP2xVkOgSRcTYk5EcoYtfS8hsFvVsf7NISnujrpys+VjrXTWxgodq9KMixytlRUMALKpH0t
	F8onmoGlqSUjIS0rSW0a1xvpbIEyWvZVBWStr6ZZL9u4=
X-Google-Smtp-Source: AGHT+IFs2+d0kAx8DgFcFSn1sGMDzQkUp4lDbG4NCVYXHJ39d4Q8R119BVcD6Ndzwxp5cN/IliGLnw==
X-Received: by 2002:a5d:6f01:0:b0:3a4:d8f8:fba7 with SMTP id ffacd0b85a97d-3a572367c78mr9839975f8f.2.1750088318282;
        Mon, 16 Jun 2025 08:38:38 -0700 (PDT)
From: "Edgar E. Iglesias" 
To: xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	julien@xen.org,
	bertrand.marquis@arm.com,
	michal.orzel@amd.com,
	Volodymyr_Babchuk@epam.com,
	andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	rosbrookn@gmail.com,
	gwd@xenproject.org,
	edgar.iglesias@amd.com
Subject: [PATCH v5 2/5] xen/arm: dom0less: Add trap-unmapped-accesses
Date: Mon, 16 Jun 2025 17:38:23 +0200
Message-ID: <20250616153826.404927-3-edgar.iglesias@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250616153826.404927-1-edgar.iglesias@gmail.com>
References: <20250616153826.404927-1-edgar.iglesias@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: "Edgar E. Iglesias" 

Add the trap-unmapped-accesses per-domain fdt property.

Signed-off-by: Edgar E. Iglesias 
Reviewed-by: Stefano Stabellini 
---
 docs/misc/arm/device-tree/booting.txt | 10 ++++++++++
 xen/arch/arm/dom0less-build.c         |  9 ++++++++-
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
index 59fa96a82e..07acc7ba64 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -225,6 +225,16 @@ with the following properties:
     option is provided with a non zero value, but the platform doesn't support
     SVE.
 
+- trap-unmapped-accesses
+
+    Optional. An integer that configures handling of accesses to unmapped
+    address ranges.
+    If set to 0, guest accesses will read all bits as ones, e.g 0xFFFFFFFF
+    for a 32bit access and writes will be ignored.
+    If set to 1, guest accesses will trap.
+
+    The default is 1 when trap-unmapped-accesses is absent.
+
 - xen,enhanced
 
     A string property. Possible property values are:
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index 981af5079f..4b285cff5e 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -344,8 +344,15 @@ void __init arch_create_domUs(struct dt_device_node *node,
 #endif
     }
 
-    /* Trap accesses to unmapped areas. */
+    /* Trap unmapped accesses by default. */
     d_cfg->flags |= XEN_DOMCTL_CDF_trap_unmapped_accesses;
+    if ( dt_property_read_u32(node, "trap-unmapped-accesses", &val) )
+    {
+        if ( val > 1 )
+            panic("trap-unmapped-accesses: supported values are 0 or 1");
+        if ( !val )
+            d_cfg->flags &= ~XEN_DOMCTL_CDF_trap_unmapped_accesses;
+    }
 }
 
 int __init init_intc_phandle(struct kernel_info *kinfo, const char *name,
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 15:38:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 15:38:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017388.1394378 (Exim 4.92)
	(envelope-from )
	id 1uRBuy-0001JZ-4R; Mon, 16 Jun 2025 15:38:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017388.1394378; Mon, 16 Jun 2025 15:38:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRBuy-0001JS-1n; Mon, 16 Jun 2025 15:38:40 +0000
Received: by outflank-mailman (input) for mailman id 1017388;
 Mon, 16 Jun 2025 15:38:38 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uRBuw-00015n-Dv
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 15:38:38 +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 f89c73eb-4ac7-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 17:38:38 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a582e09144so527585f8f.1
 for ; Mon, 16 Jun 2025 08:38:37 -0700 (PDT)
Received: from gmail.com (140.red-213-97-47.staticip.rima-tde.net.
 [213.97.47.140]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a568b09148sm11779613f8f.58.2025.06.16.08.38.35
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 16 Jun 2025 08:38:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f89c73eb-4ac7-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750088317; x=1750693117; darn=lists.xenproject.org;
        h=content-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=zpI3a3sfosj6hNi+fZow0piF9JHawLB1mde24/Cy8co=;
        b=X87z35S/RtddYuqQBFO/9HPGLYiabeffbNdbXteeNq6HIXRemxo3S2lGY/9+0rOjdl
         gPijxIOgSZtk4WsOMW7436dkKwEbHTWGgX5xqdSnHdfu81GRkZnZ6Q6zx41TDcT03UDP
         Lsjj3GghCHc2K3TnLQ6paFDC9SACy8Tlofmf9+kQG31Y8enQifCxDKx7CbbMb/Ss2dD/
         yZ9HFbLyrlp5LMEYbys62nuJ9y8+EwsdV/l3ngmIUap0FzZDjcybQH+Az7SOaUOGnBYi
         BMW5pA3h65Hvy3Ug4NAK9Kkp8QrOtqRYloClh33RMvIsI1OS4R5i6HVWJ/bpB+YYPQ1p
         /wxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750088317; x=1750693117;
        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=zpI3a3sfosj6hNi+fZow0piF9JHawLB1mde24/Cy8co=;
        b=xHe89ltgyEMyjA2O2dhT/QoDVOGvFzZ7Zeho+XLAUcRQu3iD52UcKsEkI17Ax78FhF
         TLu2pk4VolORzxPIkOo7NFFDU2M9nGy1g7OZBBNHlwG8mFiQqNECg93lWsLjA+SqS6pP
         L2S4P/63mnopjE1GhzvSYbzvuWQdaLIZCbfqqAlXIRPLSwLrjfwJ5wXLJZW7qU7V6gmi
         5xwqYcxS5aSsuZAX7SNrgAi02COY2w+dIoFfD8EG0RpfdiyuJm+DBdDG0QgqUOaqMU4w
         HYI++wnqOSCSb05DRtD+YFK/Z+sTFIcXf4kg6yQrdnMMu18Dh4WhqVYugoTnNSqEQtc2
         Dlxg==
X-Gm-Message-State: AOJu0Yz94maqxqOI/emN25Q9BV4LtcJkzhOJUt8NoJ0qXmNZ3XXb5KG7
	1Z4gukz+BLolLNE87fRWFIBlIF9Htcw8sDkRC6W0vdWWNb6L+/o9blDADsfaiRvmJWc=
X-Gm-Gg: ASbGncuOXRacPrMjm9nZHaGNsXPEUvtf3wSY2LmhihhZpzY+rAzriwWPzopQJf3PUla
	DH2OFsJDvu7/nq76yo7yZUuIR2tlE+msaT3ZWILEt9uZowFhRt9g7I7hRUFWa/00F+3v94Kv5so
	0hO4FkkoJXTcGBCG1qV9HJEFG26jZOVxctr+NBTGF8xS5gG3974sGX105WOiElZ47ImqfRk6T5s
	kOI9jqc3gOl4AcybpbX4Nfa+Vx0LWLFK2AHo1AsiwWP2uTyI4RrXWk6F3JuZsrpSv1cQyRrhl3B
	1br1SS/3rnwRGOTaMsI2TEkSXgZkqEdh21HU3M0WntbCSDimo3vf4ArC1fgzWfalMVCB8ojpuOn
	mKD6mwl1sBnFHX6d8wijaxq2LXjs26MnPYWOJRO02nOg=
X-Google-Smtp-Source: AGHT+IF7g9I61RmL20l+sNDoyY4icyG3G2rAgFLlGyf5RJWDQO30wiYD+Fw8Uv35X83UdC90RN6j+A==
X-Received: by 2002:a05:6000:288a:b0:3a5:3a3b:6a3a with SMTP id ffacd0b85a97d-3a572e5856amr8231804f8f.54.1750088316645;
        Mon, 16 Jun 2025 08:38:36 -0700 (PDT)
From: "Edgar E. Iglesias" 
To: xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	julien@xen.org,
	bertrand.marquis@arm.com,
	michal.orzel@amd.com,
	Volodymyr_Babchuk@epam.com,
	andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	rosbrookn@gmail.com,
	gwd@xenproject.org,
	edgar.iglesias@amd.com,
	Juergen Gross ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v5 1/5] xen/arm: Add way to disable traps on accesses to unmapped addresses
Date: Mon, 16 Jun 2025 17:38:22 +0200
Message-ID: <20250616153826.404927-2-edgar.iglesias@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250616153826.404927-1-edgar.iglesias@gmail.com>
References: <20250616153826.404927-1-edgar.iglesias@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: "Edgar E. Iglesias" 

Add a per-domain way to optionally disable traps for accesses
to unmapped addresses.

The domain flag is general but it's only implemented for Arm for now.

Signed-off-by: Edgar E. Iglesias 
Reviewed-by: Stefano Stabellini 
---
 tools/libs/light/libxl_arm.c  |  3 +++
 xen/arch/arm/dom0less-build.c |  3 +++
 xen/arch/arm/domain.c         |  3 ++-
 xen/arch/arm/domain_build.c   |  3 ++-
 xen/arch/arm/io.c             | 37 +++++++++++++++++++++++++++++++++--
 xen/arch/x86/domain.c         |  7 +++++++
 xen/common/domain.c           |  3 ++-
 xen/include/public/domctl.h   |  4 +++-
 8 files changed, 57 insertions(+), 6 deletions(-)

diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 75c811053c..9530996e72 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -233,6 +233,9 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
         config->arch.sve_vl = d_config->b_info.arch_arm.sve_vl / 128U;
     }
 
+    /* Trap accesses to unmapped areas. */
+    config->flags |= XEN_DOMCTL_CDF_trap_unmapped_accesses;
+
     return 0;
 }
 
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index 20aabf6be5..981af5079f 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -343,6 +343,9 @@ void __init arch_create_domUs(struct dt_device_node *node,
         panic("'sve' property found, but CONFIG_ARM64_SVE not selected\n");
 #endif
     }
+
+    /* Trap accesses to unmapped areas. */
+    d_cfg->flags |= XEN_DOMCTL_CDF_trap_unmapped_accesses;
 }
 
 int __init init_intc_phandle(struct kernel_info *kinfo, const char *name,
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 45aeb8bddc..be58a23dd7 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -612,7 +612,8 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
     unsigned int max_vcpus;
     unsigned int flags_required = (XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap);
     unsigned int flags_optional = (XEN_DOMCTL_CDF_iommu | XEN_DOMCTL_CDF_vpmu |
-                                   XEN_DOMCTL_CDF_xs_domain );
+                                   XEN_DOMCTL_CDF_xs_domain |
+                                   XEN_DOMCTL_CDF_trap_unmapped_accesses );
     unsigned int sve_vl_bits = sve_decode_vl(config->arch.sve_vl);
 
     if ( (config->flags & ~flags_optional) != flags_required )
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 590f38e520..845c92614b 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1971,7 +1971,8 @@ void __init create_dom0(void)
 {
     struct domain *dom0;
     struct xen_domctl_createdomain dom0_cfg = {
-        .flags = XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap,
+        .flags = XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap |
+                 XEN_DOMCTL_CDF_trap_unmapped_accesses,
         .max_evtchn_port = -1,
         .max_grant_frames = gnttab_dom0_frames(),
         .max_maptrack_frames = -1,
diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index 5a4b0e8f25..e599bbe043 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -21,6 +21,32 @@
 
 #include "decode.h"
 
+/* Handler for unmapped ranges. Writes ignored, reads return all ones.  */
+static int unmapped_read(struct vcpu *v, mmio_info_t *info, register_t *r,
+                         void *priv)
+{
+    uint64_t mask = GENMASK((1U << info->dabt.size) * 8 - 1, 0);
+
+    /* Mask off upper bits.  */
+    *r = UINT64_MAX & mask;
+    return 1;
+}
+
+static int unmapped_write(struct vcpu *v, mmio_info_t *info, register_t r,
+                          void *priv)
+{
+    return 1;
+}
+
+static const struct mmio_handler_ops unmapped_ops = {
+    .read = unmapped_read,
+    .write = unmapped_write
+};
+
+static const struct mmio_handler unmapped_handler = {
+    .ops = &unmapped_ops
+};
+
 static enum io_state handle_read(const struct mmio_handler *handler,
                                  struct vcpu *v,
                                  mmio_info_t *info)
@@ -175,11 +201,18 @@ enum io_state try_handle_mmio(struct cpu_user_regs *regs,
     handler = find_mmio_handler(v->domain, info->gpa);
     if ( !handler )
     {
+        bool trap_unmapped = v->domain->options &
+                                         XEN_DOMCTL_CDF_trap_unmapped_accesses;
         rc = try_fwd_ioserv(regs, v, info);
         if ( rc == IO_HANDLED )
             return handle_ioserv(regs, v);
-
-        return rc;
+        else if ( rc == IO_UNHANDLED && !trap_unmapped )
+        {
+            /* Fallback to the unmapped handler. */
+            handler = &unmapped_handler;
+        } else {
+            return rc;
+        }
     }
 
     /*
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 7536b6c871..fb7aea9168 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -713,6 +713,13 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
         }
     }
 
+    if ( config->flags & XEN_DOMCTL_CDF_trap_unmapped_accesses )
+    {
+        dprintk(XENLOG_INFO, "Unsupported trap_unmapped_accesses flag %#x\n",
+                config->flags);
+        return -EINVAL;
+    }
+
     if ( config->arch.misc_flags & ~XEN_X86_MSR_RELAXED )
     {
         dprintk(XENLOG_INFO, "Invalid arch misc flags %#x\n",
diff --git a/xen/common/domain.c b/xen/common/domain.c
index e566a18747..434d32901b 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -721,7 +721,8 @@ static int sanitise_domain_config(struct xen_domctl_createdomain *config)
          ~(XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap |
            XEN_DOMCTL_CDF_s3_integrity | XEN_DOMCTL_CDF_oos_off |
            XEN_DOMCTL_CDF_xs_domain | XEN_DOMCTL_CDF_iommu |
-           XEN_DOMCTL_CDF_nested_virt | XEN_DOMCTL_CDF_vpmu) )
+           XEN_DOMCTL_CDF_nested_virt | XEN_DOMCTL_CDF_vpmu |
+           XEN_DOMCTL_CDF_trap_unmapped_accesses) )
     {
         dprintk(XENLOG_INFO, "Unknown CDF flags %#x\n", config->flags);
         return -EINVAL;
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 5b2063eed9..be19ab5e26 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -66,9 +66,11 @@ struct xen_domctl_createdomain {
 #define XEN_DOMCTL_CDF_nested_virt    (1U << _XEN_DOMCTL_CDF_nested_virt)
 /* Should we expose the vPMU to the guest? */
 #define XEN_DOMCTL_CDF_vpmu           (1U << 7)
+/* Should we trap guest accesses to unmapped addresses? */
+#define XEN_DOMCTL_CDF_trap_unmapped_accesses  (1U << 8)
 
 /* Max XEN_DOMCTL_CDF_* constant.  Used for ABI checking. */
-#define XEN_DOMCTL_CDF_MAX XEN_DOMCTL_CDF_vpmu
+#define XEN_DOMCTL_CDF_MAX XEN_DOMCTL_CDF_trap_unmapped_accesses
 
     uint32_t flags;
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 15:38:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 15:38:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017387.1394368 (Exim 4.92)
	(envelope-from )
	id 1uRBuw-000166-Ud; Mon, 16 Jun 2025 15:38:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017387.1394368; Mon, 16 Jun 2025 15:38: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 1uRBuw-00015z-S3; Mon, 16 Jun 2025 15:38:38 +0000
Received: by outflank-mailman (input) for mailman id 1017387;
 Mon, 16 Jun 2025 15:38: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 1uRBuv-00015n-5P
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 15:38: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 f79c8d12-4ac7-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 17:38:36 +0200 (CEST)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-450cb2ddd46so26175165e9.2
 for ; Mon, 16 Jun 2025 08:38:36 -0700 (PDT)
Received: from gmail.com (140.red-213-97-47.staticip.rima-tde.net.
 [213.97.47.140]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4534172d2b0sm79261785e9.35.2025.06.16.08.38.33
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 16 Jun 2025 08:38:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f79c8d12-4ac7-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750088315; x=1750693115; 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=BTegug9VPi89e7lnmIXpFYt93qHuv9g7x2+kH7rDCJs=;
        b=Q0zbBsX9Jp2OO8mYDTNyTTCr/xxHychJTtmlEa642a0F4JNkKXjyXaX+ZPXZ9noAtJ
         4l9hXy9MoJgJebaZ21g8/oW03U060VhMwTN4o38ydqGy+Prw8/sj/7OXWoQC12/h3lbj
         wN/MQWEYpUsAwaFHLhUhXjqBCH17b0fTkksjfdcp6AiIIKwpp2O3ycnYWdNqemFNCTMT
         kIs4j34h8Wvusq8oePmlzeF8ZqpDSGmcRA/m/9gn5hfUlj/UK5Wy2UShxSzn5evqr77r
         n7NnF7WUwMMcv5dhaVlPvx/w/ENfh2LQlg3JVUJQMBCZm5P24Dvsz/1xWhyqq/dgixl2
         mYUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750088315; x=1750693115;
        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=BTegug9VPi89e7lnmIXpFYt93qHuv9g7x2+kH7rDCJs=;
        b=lO6GE4JYtc56ZlprNY+CM7iP3eUu4KQPa/sIJrXxzptqy6Xmv3ZdmkcltQbu60H/Cw
         NP1aOqtRrBS/jL6yn92CrEWW2pEvozkz134H9dWzSjTF9xC43IDaUlr8Qz3/LTyDRYVv
         VlS9XoGTXw53xcLkA62LQWU6lbwEqhVTvpBW5a13KHl6tHBooKmcLKaQ8fxl6c0CAnVZ
         ybbvdSp3be6CzqlwH0++CYBtmW9Ki+CzklFZGH7hVsg3+ZCrPtww8tmL35Ocp/d1kC+9
         uUOj7Mhzc619vREQa/tceOK/Q0q8SQNuchv9AXn8+KiKcIzVMn9bCqnZ/ZHmIshS24au
         /o6w==
X-Gm-Message-State: AOJu0YztwONO7gnVTROScn8eZ7+rCBPXjJNbQ8ucg55kK5NZzCTQG3ca
	wU9yXCRNpi7P6CK3M6FWewO8Ot7Q1+Ux2bJwAAzP1Pu6RjehapqoVUesTVw/tnBovxU=
X-Gm-Gg: ASbGncu6/llFPQKJql/uLicwHbWvkLVPguolXvcoCTb5EC9A9+gf50UE+df2Bg2Tzn6
	Fh8rlYsDEaRHYmZQcZ6hs43YyvjJcPFlUvzrYy306AShlhquV1uvmajBWZbmWxTMNd81CuL7FXG
	069YvRnwT3JT8Vo4guib8++IUHqk4SeFq6XXgAq+01ToBpNCtMkRpZxdqKKrBt92amWVO0Ymupc
	VJXhrb4eWSivoLxhG5hm/WMae3DrZG0FxRMXaOxA0PwpvCyXan/hlL3ZBintpsMGEd+f9/mrdi0
	0wgp5aVwcoOVikG99/4+7Y6yVawm3XsHkn04d864XM5uenuqTB+bTcxGHfan74QHho5ylR2FGaX
	vlpjx2vxLsCY9QuM0eQdgPDiOUTcgpxcfla8agD6RimI=
X-Google-Smtp-Source: AGHT+IFk0wAxcNwNljpT5PLOuRIPHNbq07VVNpKRd+rORL5fvAS0VfLSoBP9Fnz5j/bvqvybfP3OVQ==
X-Received: by 2002:a05:600c:350f:b0:441:ac58:ead5 with SMTP id 5b1f17b1804b1-4534f580000mr21613725e9.31.1750088314330;
        Mon, 16 Jun 2025 08:38:34 -0700 (PDT)
From: "Edgar E. Iglesias" 
To: xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	julien@xen.org,
	bertrand.marquis@arm.com,
	michal.orzel@amd.com,
	Volodymyr_Babchuk@epam.com,
	andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	rosbrookn@gmail.com,
	gwd@xenproject.org,
	edgar.iglesias@amd.com
Subject: [PATCH v5 0/5] xen/arm: Add option to optionally disable trapping on unmapped acceses
Date: Mon, 16 Jun 2025 17:38:21 +0200
Message-ID: <20250616153826.404927-1-edgar.iglesias@gmail.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: "Edgar E. Iglesias" 

This follows up on the virtio-pci discussion and adds a per-domain
option to select the behaviour of accesses to unmapped address ranges.
The new option is trap_unmapped_accesses, it's general but for now
only implemented for ARM.

I'm happy with any name, so if you have better ideas please suggest them!

I've included regenerated golang bindings as a separate patch.

Thanks,
Edgar

ChangeLog:

v4 -> v5:
* Reorder RB and AB tags to chronological order
* Rebase with master

v3 -> v4:
* Reject in x86 arch_sanitise_domain_config
* Add LIBXL_HAVE_TRAP_UNMAPPED_ACCESSES
* Remove "..is only implemented for ARM" from Arm specific documentation
* ARM -> Arm

v2 -> v3:
* Reword descriptions to clarify reads of all bits as ones
* Use GENMASK as GENMASK_ULL not needed
* Style fix in if/else
* Regenerate golang bindings
* Update ocaml bindings

v1 -> v2:
* Rename trap_unmapped_mmio to trap_unmapped_accesses
* Generalize to allow other archs to later support this option
* Change dom0less DT binding from boolean to integer
* Remove changes to autogenerated go bindings

Edgar E. Iglesias (5):
  xen/arm: Add way to disable traps on accesses to unmapped addresses
  xen/arm: dom0less: Add trap-unmapped-accesses
  tools/arm: Add the trap_unmapped_accesses xl config option
  tools/ocaml: Update bindings for CDF_TRAP_UNMAPPED_ACCESSES
  tools/golang: Regenerate bindings for trap_unmapped_accesses

 docs/man/xl.cfg.5.pod.in              |  9 +++++++
 docs/misc/arm/device-tree/booting.txt | 10 ++++++++
 tools/golang/xenlight/helpers.gen.go  |  6 +++++
 tools/golang/xenlight/types.gen.go    |  1 +
 tools/include/libxl.h                 |  7 +++++
 tools/libs/light/libxl_arm.c          |  3 +++
 tools/libs/light/libxl_create.c       |  3 +++
 tools/libs/light/libxl_types.idl      |  1 +
 tools/libs/light/libxl_x86.c          |  6 +++++
 tools/ocaml/libs/xc/xenctrl.ml        |  1 +
 tools/ocaml/libs/xc/xenctrl.mli       |  1 +
 tools/xl/xl_parse.c                   |  3 +++
 xen/arch/arm/dom0less-build.c         | 10 ++++++++
 xen/arch/arm/domain.c                 |  3 ++-
 xen/arch/arm/domain_build.c           |  3 ++-
 xen/arch/arm/io.c                     | 37 +++++++++++++++++++++++++--
 xen/arch/x86/domain.c                 |  7 +++++
 xen/common/domain.c                   |  3 ++-
 xen/include/public/domctl.h           |  4 ++-
 19 files changed, 112 insertions(+), 6 deletions(-)

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 15:41:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 15:41:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017411.1394400 (Exim 4.92)
	(envelope-from )
	id 1uRBy2-0003yd-Uc; Mon, 16 Jun 2025 15:41:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017411.1394400; Mon, 16 Jun 2025 15: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 1uRBy2-0003yW-Qc; Mon, 16 Jun 2025 15:41:50 +0000
Received: by outflank-mailman (input) for mailman id 1017411;
 Mon, 16 Jun 2025 15:41: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 1uRBy2-0003yP-0i
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 15:41:50 +0000
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com
 [2a00:1450:4864:20::333])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6a47c5a4-4ac8-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 17:41:48 +0200 (CEST)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-451e2f0d9c2so40588085e9.1
 for ; Mon, 16 Jun 2025 08:41:48 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-4532e232e4asm146606925e9.11.2025.06.16.08.41.46
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 16 Jun 2025 08:41:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6a47c5a4-4ac8-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750088508; x=1750693308; 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=Gsd37mpintvqqll2VXaHhVyGAM2PUNPG2rpZ7QLI5uA=;
        b=dqH7/9lVe7zFupuW1LmQnM6OjhpuFxXa1MzRcQmvyieDSi+4EfMjqbiU4mRONfFqFV
         CMX1qE4TOr2/fMsEuhm0mYdAx+QlMInwOYN5amZkyks1mEjL4Ux3dI9s8Fl1GVVWcVtN
         srX6h84PEoknTUN8Q/Pp0odJ0e8mIjYjkIeSs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750088508; x=1750693308;
        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=Gsd37mpintvqqll2VXaHhVyGAM2PUNPG2rpZ7QLI5uA=;
        b=LNzSY857IhJ4hocTq+VGGK+EXQFoOXLvF9mTqkf60yYK5xD3BSm7QgArdA+/OGa+8N
         LUznsyUxWEYNlmER+t/bdSi/00dnJGxAdajgd0oR50kpWzIqbB45DIm0+tN41u/IUVLt
         rwxkwktZNj/zvD8hjTA4yMmZ1x2fytht2xd+WmJk1v7wwdoqgKx/662/SdQYxBCV0Nqo
         9B9x00IWgCm3rLFjP/surbKovWqXu3giFK0cdUAkxC7/kM+Vqli9w9ODh/WRMTuz3A+p
         cmclXgc/PBBP1gXdGaqtPQP6Su1Hso66qfR73iVLlJVU4Qfg7BZaZ0yLXqmajS6Gk0jl
         ZoZg==
X-Gm-Message-State: AOJu0Yw2DBzvFLkQ2V2Jk+6Ee6D59DU3BgmWOA93ltpnvViKPj/oqkve
	XqUu8vZFay+iMMUqyln7xEXGi1E8KSZ2mlX95VEzo7T1aDk+O7WaSAMDbO+mR3dBge4=
X-Gm-Gg: ASbGnctvC3195c0hC6IIk+3QZUQNiyNY4S3Zopm+auWRf0A/UmGrtg2mG/Edsmp1YLr
	n2U5HyI8xnGe3EFhPvtwg+vUtl3YYxJFcf3WbluCXOMmaZeyMwonnZEFj0JbWTAuZj579rTMhaU
	pd+WQO8h77Ey/348hfiUdA/cTFh6frdbCsN8AIroDrzjH0utuat+2KynfkQJ9LNy2RY2QsN7Tq2
	4kv7sb94MByaXSFZhkIN0QeW/DQEPihLUtYgkBgYiD2sHbrhxHYx7/Ui7uKrN3Aqjlp+NbIPRBH
	7WhUDKQ/HNfras3yT5IVVLYaboQGNY/VPV9c9TXQJ7vVdSTEKRoQda5FV/RgzCg47zwlF0yGBRx
	SLxJ6b8ZnE4J992JXqapsoKw36/iGLMmXEnU=
X-Google-Smtp-Source: AGHT+IFWaBJmosdHxX3HA5XBljzOQzZ+5wC0CW/DYPk4tQ5374AU+m+iZv9u3XsodxqFJnFqQCpAvQ==
X-Received: by 2002:a05:600d:d:b0:453:45f1:9c96 with SMTP id 5b1f17b1804b1-45345f19d92mr52610645e9.14.1750088508087;
        Mon, 16 Jun 2025 08:41:48 -0700 (PDT)
Date: Mon, 16 Jun 2025 17:41:46 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" ,
	Andrew Cooper ,
	Julien Grall ,
	Stefano Stabellini ,
	Anthony PERARD ,
	Michal Orzel 
Subject: Re: [PATCH] memory: arrange to conserve on DMA reservation
Message-ID: 
References: <6565e881-ec59-4db4-834a-f694bf1b9427@suse.com>
 
 <9b036f26-f275-48d0-9a33-7cef38b29f48@suse.com>
 
 <2969b5d8-5879-4674-8332-046898e17257@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2969b5d8-5879-4674-8332-046898e17257@suse.com>

On Mon, Jun 16, 2025 at 05:20:45PM +0200, Jan Beulich wrote:
> On 16.06.2025 16:46, Roger Pau Monné wrote:
> > One question I have though, on systems with a low amount of memory
> > (let's say 8GB), does this lead to an increase in domain construction
> > time due to having to fallback to order 0 allocations when running out
> > of non-DMA memory?
> 
> It'll likely be slower, yes, but I can't guesstimate by how much.

Should there be some way to control this behavior then?  I'm mostly
thinking about client systems like Qubes where memory is likely
limited, and the extra slowness to create VMs could become
noticeable?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 15:53:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 15:53:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017434.1394433 (Exim 4.92)
	(envelope-from )
	id 1uRC95-0006Tn-CC; Mon, 16 Jun 2025 15:53:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017434.1394433; Mon, 16 Jun 2025 15:53:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRC95-0006TY-8Q; Mon, 16 Jun 2025 15:53:15 +0000
Received: by outflank-mailman (input) for mailman id 1017434;
 Mon, 16 Jun 2025 15: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 1uRC94-00060y-73
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 15:53:14 +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 029bd096-4aca-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 17:53:13 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a5123c1533so2700841f8f.2
 for ; Mon, 16 Jun 2025 08:53:13 -0700 (PDT)
Received: from gmail.com (140.red-213-97-47.staticip.rima-tde.net.
 [213.97.47.140]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a568a7e980sm11167447f8f.41.2025.06.16.08.53.11
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 16 Jun 2025 08:53:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 029bd096-4aca-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750089193; x=1750693993; darn=lists.xenproject.org;
        h=content-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=vQZpCaGwN67bAjam9mj+oezbvKc88yCztRac3tGbr1g=;
        b=ahxNKTcviVI81Q0UnH+VcQFEzqJdtlZyL0ypHMUPhr2zUxbgapkJ6OxCRMmWVsas2w
         F1BxeSnNSErM9StaGhwHzXH5DzNGYknNe2zJ0ZHuFtY65msk6+Y9sIpc8F/cd/DC5hKP
         o0CFj39sPOariMkmytDz7snQZB5UaDM166YSo7RoVmfAPEeaiWyhuE89lC6S+rqba441
         VP1+FMaIJTlP0t3tRo42KPrOT97bdOrJWSQrJjJkeodOFgrTOzYTjlXHsBAQieMgzWfk
         xV7y7dIxXIkJn39brr+a+3V7CTZae2YNIXq0Ka0nNnvTqbCs5DA9NiyF+5oqFEt6aYfn
         QGwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750089193; x=1750693993;
        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=vQZpCaGwN67bAjam9mj+oezbvKc88yCztRac3tGbr1g=;
        b=bnQnLXJgUt5fXLDntMs7KoK6EQsdJy/S7Ti6GzZDV6DlOcCYDCo6tIeAiUTNQYj3Tj
         x3yuiH6de4BbZPulcI7WL0sjsXkLiHFsSpGs5hGwwtrSy+Zeb+1Jog8OjsmZl3eIvdis
         Tfz1XI2Pf2ocsScboVIFfmy5iuLfl3HLcbNkMER45qYGXqnm2zvmvxh9djaqH5dop/Y3
         8rhvl4uWAJfTP7KVxLkPFXW9f65z/oNRZoJahxX87IM0LbTF7DJ1aLIs/SYGbv2mKiKw
         4HdJxSG3ynCAvlqL/N/8pVFyHVC7B4wi//5JxO/MxTzvsHr5hXpreUOUvZ/4gOYjL9CV
         2/Hw==
X-Gm-Message-State: AOJu0YyTuCg02ID7Om98RX8bfTRNZi6zH1y/ZWRsN5NGei+K+dOiz/3U
	+titQAjVsUiUe7EaFflK23EmTscQkHh4B+c6YhqhYn1U8I7RAsQwN1eTLqVt5mb+mjs=
X-Gm-Gg: ASbGncuZk5BRiKKBUDPjTbJRHXCBbG4MDUtBmEUNVRiHcUkWtWVUyU6EyKk5N06et6I
	szSW4YEh4MctgvpZfHGEyH8g9ZXW3QifAmKWzpamwHPBBIHq7oemeI7V61QIXXYf7V/vPENnwKs
	m8hszjo6rlhiWmUIqBRM8Ss0hub4YHtHa69T+D7LabtJDETTjl9Wfzq4+xEd4q81sGx8vmXagp+
	wC2HGxBaa3y63ImzWgIozwhwj5jj9AqBhakRar7IgyRQmdm4Lx6PkRZri49FX7Qttmbu8Zt5ADO
	gxxU6Nq25ZGMAd20vDMK2X0D3GIsDyzyLDueAgiQnudx0Wheh6KG77p+lUytw1S/JVP3ks+p+8n
	d/x6frt2JgU4XXZKqmEXZ4gPW8NrbAs8fPVfcNJVU5tw=
X-Google-Smtp-Source: AGHT+IHpvPp+/8SnXYZTtAz5euhAKk5EDZjL7senbpc2uPA0sxOxDiKrHxkM2fe273b0KhcegmhPuQ==
X-Received: by 2002:a05:6000:402a:b0:3a5:2208:41e3 with SMTP id ffacd0b85a97d-3a572398dcfmr7650682f8f.4.1750089192632;
        Mon, 16 Jun 2025 08:53:12 -0700 (PDT)
From: "Edgar E. Iglesias" 
To: xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	julien@xen.org,
	bertrand.marquis@arm.com,
	michal.orzel@amd.com,
	Volodymyr_Babchuk@epam.com,
	andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	rosbrookn@gmail.com,
	gwd@xenproject.org,
	edgar.iglesias@amd.com
Subject: [PATCH v5 5/5] tools/golang: Regenerate bindings for trap_unmapped_accesses
Date: Mon, 16 Jun 2025 17:53:06 +0200
Message-ID: <20250616155306.405257-3-edgar.iglesias@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250616153826.404927-1-edgar.iglesias@gmail.com>
References: <20250616153826.404927-1-edgar.iglesias@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: "Edgar E. Iglesias" 

Signed-off-by: Edgar E. Iglesias 
---
 tools/golang/xenlight/helpers.gen.go | 6 ++++++
 tools/golang/xenlight/types.gen.go   | 1 +
 2 files changed, 7 insertions(+)

diff --git a/tools/golang/xenlight/helpers.gen.go b/tools/golang/xenlight/helpers.gen.go
index 90846ea8e8..191be87297 100644
--- a/tools/golang/xenlight/helpers.gen.go
+++ b/tools/golang/xenlight/helpers.gen.go
@@ -1170,6 +1170,9 @@ x.Altp2M = Altp2MMode(xc.altp2m)
 x.VmtraceBufKb = int(xc.vmtrace_buf_kb)
 if err := x.Vpmu.fromC(&xc.vpmu);err != nil {
 return fmt.Errorf("converting field Vpmu: %v", err)
+}
+if err := x.TrapUnmappedAccesses.fromC(&xc.trap_unmapped_accesses);err != nil {
+return fmt.Errorf("converting field TrapUnmappedAccesses: %v", err)
 }
 
  return nil}
@@ -1695,6 +1698,9 @@ xc.altp2m = C.libxl_altp2m_mode(x.Altp2M)
 xc.vmtrace_buf_kb = C.int(x.VmtraceBufKb)
 if err := x.Vpmu.toC(&xc.vpmu); err != nil {
 return fmt.Errorf("converting field Vpmu: %v", err)
+}
+if err := x.TrapUnmappedAccesses.toC(&xc.trap_unmapped_accesses); err != nil {
+return fmt.Errorf("converting field TrapUnmappedAccesses: %v", err)
 }
 
  return nil
diff --git a/tools/golang/xenlight/types.gen.go b/tools/golang/xenlight/types.gen.go
index e7667f1ce3..656933c6c9 100644
--- a/tools/golang/xenlight/types.gen.go
+++ b/tools/golang/xenlight/types.gen.go
@@ -606,6 +606,7 @@ MsrRelaxed Defbool
 Altp2M Altp2MMode
 VmtraceBufKb int
 Vpmu Defbool
+TrapUnmappedAccesses Defbool
 }
 
 type DomainBuildInfoTypeUnion interface {
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 15:53:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 15:53:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017432.1394412 (Exim 4.92)
	(envelope-from )
	id 1uRC91-00061B-U2; Mon, 16 Jun 2025 15:53:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017432.1394412; Mon, 16 Jun 2025 15:53:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRC91-000614-RA; Mon, 16 Jun 2025 15:53:11 +0000
Received: by outflank-mailman (input) for mailman id 1017432;
 Mon, 16 Jun 2025 15:53:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uRC91-00060y-B4
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 15:53:11 +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 00adffa5-4aca-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 17:53:10 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-450cfb79177so28777845e9.0
 for ; Mon, 16 Jun 2025 08:53:10 -0700 (PDT)
Received: from gmail.com (140.red-213-97-47.staticip.rima-tde.net.
 [213.97.47.140]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a568b18f96sm11559372f8f.66.2025.06.16.08.53.08
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 16 Jun 2025 08:53:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 00adffa5-4aca-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750089189; x=1750693989; darn=lists.xenproject.org;
        h=content-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=hTTDVxBacMVhgiefAvTCo3jBlukvO39wp+PQztq5l5c=;
        b=Tgzi1FZPj7n+eBOobXJtL/ZQ88HAJ2A9cC3OYY6UB+/dOj6YpOBaqW1BRQdNN4vHyg
         1KSfdVSPYjW8Jpn6s022nC9wy5h+wXXwY6jo2vbA+4XRvOd2ARTWPTdupH8z0l1UloT5
         XPiPuxVZJsBZ38MVDYzIzNPOXiVP4xKt+MjDr53r5yHeFcerXXGMpdTjXhiBjb2pvDQZ
         CFXc6O9xvEbrFbeRo0cqFnuaNHymgfC9bCq3ldmupuL6tCNiICgtXNmpEiP24ZKElQww
         eikSTfSTyUPWrXKplMQEawno9H8JzR/laiayQi0oAKQHZRNFbAvfZY9hQr4ZIcVaHtuc
         eqmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750089189; x=1750693989;
        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=hTTDVxBacMVhgiefAvTCo3jBlukvO39wp+PQztq5l5c=;
        b=EhmvEL1h64uDIO4D53d4ZqSczYws8BzEc9SwXrW1IYrvagl/kN7bV32QMhXZ3kSqU6
         c36sQe/0RwWdXVzBVjEXYcnFXbta8bUCrZKika6Bn+VieNI0Qkt33yAVutgl/DLUjquf
         IKy6mjRgo8+jja2u9IzRIK8RUShxohR7W/RsBpSpUcIINubfFFQf50kG7i2qBLVlVzd1
         1Pjds9Dj/P+fWln8gYAUaAokelMFxI4vgGqLzSw0NZ7oNzRR00pHB677FLLhSZrnvRRr
         r9IQx2tYOWMa1lLyWYBvVg2SP+gCU2eIoXYqhbhooiQB2bWIVNBEn0ZyZPNZd467qFBS
         T7xA==
X-Gm-Message-State: AOJu0Yzqh3e7piwTiq3mHv1j2feIGv7Gu/WYdfH4lA+NzeoisES7Sofd
	eYQKlQ2xlLsJYTssuzNJfOiZfrR1iDA1zG9drE9Bx08/FloFEo2UXoUE3fbFig0APfI=
X-Gm-Gg: ASbGncte7C0W3S2DaJvryIMwPFDpqrz6klGMkT5Y3rcL1uL+KBL6C5bxb/xqZAOnOK3
	LCtPc1wD5zSXRFOGSGj5qveZeN8nZepYzlhHtEjs8D3SShualvlHrKN/ycpbRX28b8Mhp5n2Gtj
	o+ALYLCwqF3jx3bkRI6KmgCpkRqNam3Yvgsji4Xr2YjTMeunEuCKtTUhukvCyBuQxNiQq3nOza6
	ikmsbG5XXnab3tQAqOE1CBwldk8zUqbp8hawSc5omUy1C1+v647EBNM9sFhRt7iQGSt8Ly2WmO4
	AQ8i8y0+qdTvcyW8TyLPppi7gsrfnuXPjQYDrcBxvl5UN61r+emgirSuKDEpEx1Dmoz+y7alOUU
	FjzSidajjPiaqdO/b8bdRszyEar3e2QW5RsLDfXMqO9mEuuxK475EAQ==
X-Google-Smtp-Source: AGHT+IEz5F5xMW1sXDv3e6m8Wn+szYODBtW2rBwJBVBpWLBpMHya3TnaGhxYVqvOEcrfNj1OAknM2w==
X-Received: by 2002:a05:600c:3e8c:b0:440:6a37:be0d with SMTP id 5b1f17b1804b1-4533ca9cc5cmr108156355e9.15.1750089188813;
        Mon, 16 Jun 2025 08:53:08 -0700 (PDT)
From: "Edgar E. Iglesias" 
To: xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	julien@xen.org,
	bertrand.marquis@arm.com,
	michal.orzel@amd.com,
	Volodymyr_Babchuk@epam.com,
	andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	rosbrookn@gmail.com,
	gwd@xenproject.org,
	edgar.iglesias@amd.com,
	Juergen Gross 
Subject: [PATCH v5 3/5] tools/arm: Add the trap_unmapped_accesses xl config option
Date: Mon, 16 Jun 2025 17:53:04 +0200
Message-ID: <20250616155306.405257-1-edgar.iglesias@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250616153826.404927-1-edgar.iglesias@gmail.com>
References: <20250616153826.404927-1-edgar.iglesias@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: "Edgar E. Iglesias" 

Signed-off-by: Edgar E. Iglesias 
Reviewed-by: Stefano Stabellini 
---
 docs/man/xl.cfg.5.pod.in         | 9 +++++++++
 tools/include/libxl.h            | 7 +++++++
 tools/libs/light/libxl_arm.c     | 6 +++---
 tools/libs/light/libxl_create.c  | 3 +++
 tools/libs/light/libxl_types.idl | 1 +
 tools/libs/light/libxl_x86.c     | 6 ++++++
 tools/xl/xl_parse.c              | 3 +++
 7 files changed, 32 insertions(+), 3 deletions(-)

diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index c388899306..075e89e6d2 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -3056,6 +3056,15 @@ will be used for the domain. Otherwise, the value specified by the `nr_spis`
 parameter will be used. The number of SPIs should match the highest interrupt
 ID that will be assigned to the domain.
 
+=item B
+
+An Optional boolean parameter that configures handling of accesses to unmapped
+address ranges. If enabled, guest accesses will trap. If disabled, guest
+accesses will read all bits as ones, e.g 0xFFFFFFFF for a 32bit access and
+writes will be ignored.
+
+This option is only implemented for Arm where the default is enabled.
+
 =back
 
 =head3 x86
diff --git a/tools/include/libxl.h b/tools/include/libxl.h
index b7ad7735ca..24c81cf145 100644
--- a/tools/include/libxl.h
+++ b/tools/include/libxl.h
@@ -549,6 +549,13 @@
  */
 #define LIBXL_HAVE_VPMU 1
 
+/*
+ * LIBXL_HAVE_TRAP_UNMAPPED_ACCESSES indicates that libxl_domain_build_info
+ * has a trap_unmapped_accesses parameter, which allows the control of how
+ * accesses to unmapped adresses behave.
+ */
+#define LIBXL_HAVE_TRAP_UNMAPPED_ACCESSES 1
+
 /*
  * LIBXL_HAVE_PHYSINFO_CAP_GNTTAB indicates that libxl_physinfo has a
  * cap_gnttab_v1/2 fields, which indicates the available grant table ABIs.
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 9530996e72..afc62a5299 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -233,9 +233,6 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
         config->arch.sve_vl = d_config->b_info.arch_arm.sve_vl / 128U;
     }
 
-    /* Trap accesses to unmapped areas. */
-    config->flags |= XEN_DOMCTL_CDF_trap_unmapped_accesses;
-
     return 0;
 }
 
@@ -1714,6 +1711,9 @@ int libxl__arch_domain_build_info_setdefault(libxl__gc *gc,
     /* ACPI is disabled by default */
     libxl_defbool_setdefault(&b_info->acpi, false);
 
+    /* Trapping of unmapped accesses enabled by default.  */
+    libxl_defbool_setdefault(&b_info->trap_unmapped_accesses, true);
+
     /* Sanitise SVE parameter */
     if (b_info->arch_arm.sve_vl) {
         unsigned int max_sve_vl =
diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_create.c
index 8bc768b515..625ce5b040 100644
--- a/tools/libs/light/libxl_create.c
+++ b/tools/libs/light/libxl_create.c
@@ -605,6 +605,9 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
         if (libxl_defbool_val(b_info->vpmu))
             create.flags |= XEN_DOMCTL_CDF_vpmu;
 
+        if (libxl_defbool_val(b_info->trap_unmapped_accesses))
+            create.flags |= XEN_DOMCTL_CDF_trap_unmapped_accesses;
+
         assert(info->passthrough != LIBXL_PASSTHROUGH_DEFAULT);
         LOG(DETAIL, "passthrough: %s",
             libxl_passthrough_to_string(info->passthrough));
diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl
index 1985153830..57ae16ae78 100644
--- a/tools/libs/light/libxl_types.idl
+++ b/tools/libs/light/libxl_types.idl
@@ -736,6 +736,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
     ("vmtrace_buf_kb", integer),
 
     ("vpmu", libxl_defbool),
+    ("trap_unmapped_accesses", libxl_defbool),
 
     ], dir=DIR_IN,
        copy_deprecated_fn="libxl__domain_build_info_copy_deprecated",
diff --git a/tools/libs/light/libxl_x86.c b/tools/libs/light/libxl_x86.c
index 867addfcab..60d4e8661c 100644
--- a/tools/libs/light/libxl_x86.c
+++ b/tools/libs/light/libxl_x86.c
@@ -26,6 +26,11 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
     if (libxl_defbool_val(d_config->b_info.arch_x86.msr_relaxed))
         config->arch.misc_flags |= XEN_X86_MSR_RELAXED;
 
+    if (libxl_defbool_val(d_config->b_info.trap_unmapped_accesses)) {
+            LOG(ERROR, "trap_unmapped_accesses is not supported on x86\n");
+            return ERROR_FAIL;
+    }
+
     return 0;
 }
 
@@ -813,6 +818,7 @@ int libxl__arch_domain_build_info_setdefault(libxl__gc *gc,
 {
     libxl_defbool_setdefault(&b_info->acpi, true);
     libxl_defbool_setdefault(&b_info->arch_x86.msr_relaxed, false);
+    libxl_defbool_setdefault(&b_info->trap_unmapped_accesses, false);
 
     if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         /*
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index 219e924779..98b3612d0f 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -2972,6 +2972,9 @@ skip_usbdev:
     if (!xlu_cfg_get_long (config, "nr_spis", &l, 0))
         b_info->arch_arm.nr_spis = l;
 
+    xlu_cfg_get_defbool(config, "trap_unmapped_accesses",
+                        &b_info->trap_unmapped_accesses, 0);
+
     parse_vkb_list(config, d_config);
 
     d_config->virtios = NULL;
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 15:53:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 15:53:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017433.1394423 (Exim 4.92)
	(envelope-from )
	id 1uRC94-0006FQ-4T; Mon, 16 Jun 2025 15:53:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017433.1394423; Mon, 16 Jun 2025 15:53: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 1uRC94-0006FJ-1X; Mon, 16 Jun 2025 15:53:14 +0000
Received: by outflank-mailman (input) for mailman id 1017433;
 Mon, 16 Jun 2025 15:53: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 1uRC92-00060y-EF
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 15:53:12 +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 01923b91-4aca-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 17:53:12 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3a4fd1ba177so2664296f8f.0
 for ; Mon, 16 Jun 2025 08:53:11 -0700 (PDT)
Received: from gmail.com (140.red-213-97-47.staticip.rima-tde.net.
 [213.97.47.140]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a568a53f79sm11291109f8f.4.2025.06.16.08.53.09
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 16 Jun 2025 08:53:09 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 01923b91-4aca-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750089191; x=1750693991; darn=lists.xenproject.org;
        h=content-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=KeqjX2kaombgFMNPY6Wbvs43WcIJodVrLA2njPKaH3s=;
        b=cf8mbWBtwqt0L1dny3DgybPDZPDXQUlOupKDP3ug0E2/koaNAPWN4T9ZEXg6AZmQes
         9y8Gbo+jFEYmv3x4mDAKJQgEYvSg4PvIHVCQminUPpStkCFrdE4NHboL0AOKrBqCcxt5
         9FyNzrfQKSL5jGDkIgcQin1UNGxgj0okOx6gufbVVzkYWKFOIb5bWBBeJeQGek+gKYgl
         XqpQv5yQMFa/Q60eY8RPXJZzub++D8VKLs7zmHZf8K7f8vPg3P8sc1/9/9k05kuT1Jci
         csE7oAJ34TLxqP2Enaa0AL3svpxMpTZS8BYlWvI/XZKz50h4Zysic9j73kt3OOu0sE/b
         Txug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750089191; x=1750693991;
        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=KeqjX2kaombgFMNPY6Wbvs43WcIJodVrLA2njPKaH3s=;
        b=lbkbmPr7n7Zrwpq4ceOunewoMiXIAi9/TSLYJW4ujuWkOOwLMUEp89TgIbf4lMHPzh
         9KWeRT26kdVzla+cYQRMJbMY/BAFUY0/K/6xfzMhabXumthZfJzwwvNR4xt4bQpbCt8W
         0CsxELYKc1bkTwMw24GWNz8Qo6LAQDVyJcZI2J6hQAUhSfxOcby2D7o93clN+6KzSnE6
         v4n+dCjjVBy2ijBXT/pGExvGY9orhFyhW3Mram/cBi+bttZ35D1GP/r6c1aRK2ikOZFn
         10BUK7lek8GhdQKEQSuFhf4ZyM8sk36oQK7HJTTDTzbM+3XjGXO7oC65E7HJn4gBXaWI
         qBHw==
X-Gm-Message-State: AOJu0Yz5UI5ykmgyDxI/ZFnf/PLQ8g1grwNT3D6S8TD+3Dn7o1Q0U+kv
	UNxbOcPAvFe+09JLCwCRDWG1uzGzEADJrwNGsQypTWB/LHjs4D2VRdfKjLf7xx3toN8=
X-Gm-Gg: ASbGncsJoaKiqSopyferfSq/C+hp4Amw9Vhyw2gFUza4VEcXlC6VXBMM42ZOVzh7QaZ
	dIkZ7DDTCeHqrhdH1PDuRuXphb1sUce1na2WAax2uVLLxbuNKlbcBzC0Kkz9RAFwnRsSrnQqop3
	CSZ9q71dwMU/481g6XoyjkTTMx/Ey/xZQg4wHoN2yvj4XhI8BQR9CqrwyH5EHa9IDhgvC/AKR40
	+efA76+6VBZ6D1LOv1PR2IJ1HzVcMhwWfTrAw0dJkKnz4w29gWoQycT1xfMPOEy/JPpFoNoeqMk
	cZSLThFu25GplNGdAuBPMPajyHkFCQlGdcWjEo0AaJjo4hxYxWse4twd8nnPvrM/rqM5pK+UywY
	wPkbCigPZitm+nXbBGoUr2GXjsj8H/EbpLINa7Gvqc+s=
X-Google-Smtp-Source: AGHT+IEJnKqlLvXwblVqEE9CNuulNgsEyIc7AgnBYT7dSL/fPlVN589Joy5AFmHdvEb+ksj6ka1jtg==
X-Received: by 2002:a5d:64e3:0:b0:3a0:b565:a2cb with SMTP id ffacd0b85a97d-3a572384056mr10323750f8f.1.1750089190856;
        Mon, 16 Jun 2025 08:53:10 -0700 (PDT)
From: "Edgar E. Iglesias" 
To: xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	julien@xen.org,
	bertrand.marquis@arm.com,
	michal.orzel@amd.com,
	Volodymyr_Babchuk@epam.com,
	andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	rosbrookn@gmail.com,
	gwd@xenproject.org,
	edgar.iglesias@amd.com,
	Christian Lindig ,
	Christian Lindig ,
	David Scott 
Subject: [PATCH v5 4/5] tools/ocaml: Update bindings for CDF_TRAP_UNMAPPED_ACCESSES
Date: Mon, 16 Jun 2025 17:53:05 +0200
Message-ID: <20250616155306.405257-2-edgar.iglesias@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250616153826.404927-1-edgar.iglesias@gmail.com>
References: <20250616153826.404927-1-edgar.iglesias@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: "Edgar E. Iglesias" 

Signed-off-by: Edgar E. Iglesias 
Acked-by: Christian Lindig 
---
 tools/ocaml/libs/xc/xenctrl.ml  | 1 +
 tools/ocaml/libs/xc/xenctrl.mli | 1 +
 2 files changed, 2 insertions(+)

diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml
index 2690f9a923..7e1aabad6c 100644
--- a/tools/ocaml/libs/xc/xenctrl.ml
+++ b/tools/ocaml/libs/xc/xenctrl.ml
@@ -70,6 +70,7 @@ type domain_create_flag =
   | CDF_IOMMU
   | CDF_NESTED_VIRT
   | CDF_VPMU
+  | CDF_TRAP_UNMAPPED_ACCESSES
 
 type domain_create_iommu_opts =
   | IOMMU_NO_SHAREPT
diff --git a/tools/ocaml/libs/xc/xenctrl.mli b/tools/ocaml/libs/xc/xenctrl.mli
index febbe1f6ae..f44dba61ae 100644
--- a/tools/ocaml/libs/xc/xenctrl.mli
+++ b/tools/ocaml/libs/xc/xenctrl.mli
@@ -63,6 +63,7 @@ type domain_create_flag =
   | CDF_IOMMU
   | CDF_NESTED_VIRT
   | CDF_VPMU
+  | CDF_TRAP_UNMAPPED_ACCESSES
 
 type domain_create_iommu_opts =
   | IOMMU_NO_SHAREPT
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 16:00:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 16:00:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017457.1394442 (Exim 4.92)
	(envelope-from )
	id 1uRCFd-0007im-7c; Mon, 16 Jun 2025 16:00:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017457.1394442; Mon, 16 Jun 2025 16:00: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 1uRCFd-0007if-4a; Mon, 16 Jun 2025 16:00:01 +0000
Received: by outflank-mailman (input) for mailman id 1017457;
 Mon, 16 Jun 2025 15:59: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 1uRCFb-0007iZ-JD
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 15:59:59 +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 edda78db-4aca-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 17:59:48 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3a51481a598so2775014f8f.3
 for ; Mon, 16 Jun 2025 08:59:57 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-313c1b59ed4sm8823740a91.39.2025.06.16.08.59.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Jun 2025 08:59:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: edda78db-4aca-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750089596; x=1750694396; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=yL2JYLXKQZOHEL1A8htYWxPDv755EESrk+pltR12oX8=;
        b=UX6nVkmyz08HobnuLHFEgzsezdG/UP1JV773dVtSqG3Qk95QhDduvHBnFvpwSF5/BI
         7OJLRWxZBulo9VdUyBwrtrh5zv3dOGG/lxbywJB6zfIzYWYk+x7hHrXzZ557H76O9pGy
         Di2yROwr9DeeDUHrT+Suc13tZMQcZluVIXL7UaCiIsIlgctGQoRl7f9HAJawvwFhV9xd
         3RxZTzhVKzSGamDlX9G5rk82Kb/BYDVcYLgia3s+ruTiP9BYEJeV+9A6fZjDrHhPZiBL
         WuDIJ/1ImUJ2jVWeR7YYDPapXFjFsCc6oIBz1rk1THA3O9EK3KuWCo2xVaPrcy0ibBYC
         JFGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750089596; x=1750694396;
        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=yL2JYLXKQZOHEL1A8htYWxPDv755EESrk+pltR12oX8=;
        b=jwzxLlRsxL7dGRJaoWvL+jxkke1azlBuWwOGdHTytW4Gmq89QQMHv1KpQyxl6lI+Zs
         A1T72VNRiAOTt2FD1fL/ujcZCntfutcuNlJyRlT9gThQypRtypLPqIK/ExlxAkUHrnJh
         QpGC9zgv6+MwrFS5YQQm9gkg5Fb3QsE9vdFAR7YXN3mzYOxie1CwdemDBBu8W4p9P8r8
         Ds4WWzt7T1pBEHm/7/03tas1peQkGUJp7tfQoTtIG5wDOHn7QasjSjmoLHXHInVdGfTX
         6WtxYkDgtQccj4XrxjzNHB42uEPo25GxnO4fCt40YyzCOJGIlj8Ev3ij31My/MAp+oyD
         4E7Q==
X-Forwarded-Encrypted: i=1; AJvYcCVffhqLU8JxBpAoQ/qxLMVGUlwN5aDBpYB9mEW5LfkQHkP5Ircvqp5aTUFMVCi9MSZuTufU2KP1EY4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz+l/1Ou96Sr80uvfCEzHBi+gi55oFfoGBSIW+DFL5KrUiHhYqS
	C9gW06m53FxYHc+pybEKJD2ggejs71pyZJdKf4bWIn0k5FmioIiXFEK9RvKo390Z6w==
X-Gm-Gg: ASbGnctk56MwBHX6nmoGwrTxr2XsuIkGUQuDuT+t/ItMvp3ZZz0JG1Mssmh1xCDESL3
	XFlUJHy4dl5nGLzbsv3vFdTYdtDEjp9MfJ/jZFNEV4Fr5qM9NfD5tLOJkG0Klsmjw5KVNla91Bn
	Wtm9Bv3GZWFMnZ+qEp9oZqDT+qdiAK2KyfFXMhN3/O0iwLyiX7kQCu0xD2ZBV0OIDVZflzyL0kw
	BZZd7+xRAvytHcxCWWQJqhnu7OfWhTcIama8S0yQkcJSOvL/AZRAUWfqJx8JW68PCpcOVddRI9v
	4i3eJUUgqrXudoomOB7SBdtTg9wcH30R6JXE4QSuxWM4YJhqRk9EylT+Ca2AU3AfentthTxZFBB
	ro4jbyjn6fXswlFhlZuefrLZql8F4u0W/F/jLlzya/65Zuyu0JksCnKWS7Q==
X-Google-Smtp-Source: AGHT+IEP1UvTxZQNe7Dej0O6YFWgrJJV/EwBMPT2+yMDYd7L18+92RCil+8MRjeLz9HWdIRWsIFn0w==
X-Received: by 2002:a05:6000:288a:b0:3a5:3a3b:6a3a with SMTP id ffacd0b85a97d-3a572e5856amr8289514f8f.54.1750089596456;
        Mon, 16 Jun 2025 08:59:56 -0700 (PDT)
Message-ID: <964dcd5e-6a7d-41f2-94b4-c07672ffdc89@suse.com>
Date: Mon, 16 Jun 2025 17:59:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 10/18] xen/cpufreq: introduce a new amd cppc driver for
 cpufreq scaling
To: Penny Zheng 
Cc: ray.huang@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-11-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: <20250527084833.338427-11-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.05.2025 10:48, Penny Zheng wrote:
> --- a/xen/arch/x86/acpi/cpufreq/amd-cppc.c
> +++ b/xen/arch/x86/acpi/cpufreq/amd-cppc.c
> @@ -14,7 +14,56 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
> +#include 
> +#include 
> +
> +#define amd_cppc_err(cpu, fmt, args...)                             \
> +    printk(XENLOG_ERR "AMD_CPPC: CPU%u error: " fmt, cpu, ## args)
> +#define amd_cppc_warn(cpu, fmt, args...)                            \
> +    printk(XENLOG_WARNING "AMD_CPPC: CPU%u warning: " fmt, cpu, ## args)
> +#define amd_cppc_verbose(cpu, fmt, args...)                         \
> +({                                                                  \
> +    if ( cpufreq_verbose )                                          \
> +        printk(XENLOG_DEBUG "AMD_CPPC: CPU%u " fmt, cpu, ## args);  \
> +})

Nit: Much like in the file name, would you mind using AMD-CPPC in favor of
AMD_CPPC here, too?

> @@ -50,10 +99,323 @@ int __init amd_cppc_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 linear function passing by the 2 points:
> + *  - (Low perf, Low freq)
> + *  - (Nominal perf, Nominal freq)
> + * Parameter freq is always in kHz.
> + */
> +static int amd_cppc_khz_to_perf(const struct amd_cppc_drv_data *data,
> +                                unsigned int freq, uint8_t *perf)
> +{
> +    const struct xen_processor_cppc *cppc_data = data->cppc_data;
> +    unsigned int mul, div;
> +    int offset = 0, res;
> +
> +    if ( cppc_data->cpc.lowest_mhz && cppc_data->cpc.nominal_mhz )
> +    {
> +        mul = data->caps.nominal_perf - data->caps.lowest_perf;
> +        div = cppc_data->cpc.nominal_mhz - cppc_data->cpc.lowest_mhz;

What guarantees both of these values to be non-zero?

> +        /*
> +         * We don't need to convert to kHz for computing offset and can
> +         * directly use nominal_mhz and lowest_mhz as the division
> +         * will remove the frequency unit.
> +         */
> +        offset = data->caps.nominal_perf -
> +                 (mul * cppc_data->cpc.nominal_mhz) / div;
> +    }
> +    else
> +    {
> +        /* Read Processor Max Speed(MHz) as anchor point */
> +        mul = data->caps.highest_perf;
> +        div = this_cpu(pxfreq_mhz);
> +        if ( !div )
> +            return -EINVAL;

What's wrong about the function arguments in this case? (Same question again
on further uses of EINVAL below.)

> +static int cf_check amd_cppc_cpufreq_target(struct cpufreq_policy *policy,
> +                                            unsigned int target_freq,
> +                                            unsigned int relation)
> +{
> +    unsigned int cpu = policy->cpu;
> +    const struct amd_cppc_drv_data *data = per_cpu(amd_cppc_drv_data, cpu);
> +    uint8_t des_perf;
> +    int res;
> +
> +    if ( unlikely(!target_freq) )
> +        return 0;
> +
> +    res = amd_cppc_khz_to_perf(data, target_freq, &des_perf);
> +    if ( res )
> +        return res;
> +
> +    /*
> +     * Setting with "lowest_nonlinear_perf" to ensure governoring
> +     * performance in P-state range.
> +     */
> +    amd_cppc_write_request(policy->cpu, data->caps.lowest_nonlinear_perf,
> +                           des_perf, data->caps.highest_perf);

I fear I don't understand the comment, and hence it remains unclear to me
why lowest_nonlinear_perf is being used here.

> +static int cf_check amd_cppc_cpufreq_cpu_init(struct cpufreq_policy *policy)
> +{
> +    unsigned int cpu = policy->cpu;
> +    struct amd_cppc_drv_data *data;
> +
> +    data = xvzalloc(struct amd_cppc_drv_data);
> +    if ( !data )
> +        return -ENOMEM;
> +
> +    data->cppc_data = &processor_pminfo[cpu]->cppc_data;
> +
> +    per_cpu(amd_cppc_drv_data, cpu) = data;
> +
> +    on_selected_cpus(cpumask_of(cpu), amd_cppc_init_msrs, policy, 1);
> +
> +    /*
> +     * The enable bit is sticky, as we need to enable it at the very first
> +     * begining, before CPPC capability values sanity check.
> +     * If error path takes effective, not only amd-cppc cpufreq core fails

Nit: "takes effect" or "is taken".

> +     * to initialize, but also we could not fall back to legacy P-states
> +     * driver, irrespective of the command line specifying a fallback option.
> +     */
> +    if ( data->err )
> +    {
> +        amd_cppc_err(cpu, "Could not initialize cpufreq cores in CPPC mode\n");

Why "cores" (plural)?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 16:02:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 16:02:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017464.1394453 (Exim 4.92)
	(envelope-from )
	id 1uRCHr-0001b6-Jb; Mon, 16 Jun 2025 16:02:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017464.1394453; Mon, 16 Jun 2025 16: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 1uRCHr-0001az-Gl; Mon, 16 Jun 2025 16:02:19 +0000
Received: by outflank-mailman (input) for mailman id 1017464;
 Mon, 16 Jun 2025 16:02: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 1uRCHq-0001at-TO
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 16:02:18 +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 413499a5-4acb-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 18:02:08 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-451d41e1ad1so40794165e9.1
 for ; Mon, 16 Jun 2025 09:02:17 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-748900d2e25sm7240959b3a.171.2025.06.16.09.02.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Jun 2025 09:02:15 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 413499a5-4acb-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750089736; x=1750694536; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=1mLcw5w2P2QBxctahPP8wowYUSjN7hMNQywLrCe2FYE=;
        b=OMQubVDNxNYcJGqJBfMKd3oW7EQrjddPb383f/ec6HwEtNbRTvSZoWWvYYutoGMg8z
         AOyh9e7YNkaZ30VDesquCHeyNsSGf2v+kOcq6ver+7GsqA79XqzffKznU/X9MXo0GgkN
         9nNx3A3RnhARfThhi+HaW0b9mwYpbLnrh/sh+/A49amuRzE6Zw2+TQRo61e/ZjEpF3vj
         OMpNHgnIJBYJr63wvmdPR2XQRKYkWbL1jNYV4ttNOkCG+UJtYcEXmP3/bvDrSE3XoKK6
         kNfgR+VW8t+uKSZwa91dSVj1xjncbO0o884ohqRQQ7WNr3Io0pL8yWbvODaRSxWWQQ0e
         o+WQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750089736; x=1750694536;
        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=1mLcw5w2P2QBxctahPP8wowYUSjN7hMNQywLrCe2FYE=;
        b=qqGal0rjnb5g7ubmM9O+4ZaM6lnnDxvp455LgerxLLT4w8E+1Lcfu/5RJUTbn6GefD
         TYMndrPOzvrBRUa7aPzTE9T9eDYYpTEnXSeKrGI/JBlcf6LyC6bbXs7gpGwTnU7RMRs8
         nIhkcwGJoXFH7KqGEo53ssgmzbT2con9gLjR6Q6QsvwmCsidI8AnRHA4WaClwt9PuSCd
         8GrqQu4SL23DlLSxmYL3vb/Sj99h9knSjX11nXnuNu3UOxKvml2ch2XYvG5tibah+thL
         DZuaL/2jf3UyxL67tU+bf/dqPt2CBn8Tz4iBBcq84s8wH01qHfDrtJ9sTlCeGsZQjSVK
         N5Pw==
X-Gm-Message-State: AOJu0YwiORjtqJE58uB0t8O8NZvZHfTFhuYrS3QJJFx+61eVSnMPSgHq
	5CXAvXgG46xjIeNl4aYczD5shprL14gidIL8TNiDtpS5BZ+lZ5YesCMFs5GxdMS1pQ==
X-Gm-Gg: ASbGncvYzlzHFcqpFOvCL/bCA2GeUe2Ve06ob+CALIif3MhAEhl/zcR1D+Ycn6BpEUa
	3jixiHsI5RYedMMS04G+UoA9Wifvp9bRNvySdhv4FvMzkucTZc2ZB+LIamgCZOoLFcyn/8zBoKU
	gHoE07v0oS5WptIFcz7doxh5NmzJ7yx3zrTJMUH0xAr++eBIrzIjPWHQKxVrj3Dtm3xrxIkzQ5M
	awzo9xqn6MbyLWFwjZpLIqWMhPGRaWWzeXxHo718E83YaiYUPaZSXUNO/scYgdzcssR5+kvjnrw
	ZrEXrZ1HFlaXaFxSxkI8lDVEPu77Uad7I5mVWeHdVdmb5WZjgdBBayopBOqqGWNhMXR2vRUzEmf
	p/YWxo3Nf6RlVQBTOcCDSf6ANH3gM53b3ZLCkPaxSDBZvVCg=
X-Google-Smtp-Source: AGHT+IHyUw5sjRrR+IVm7BHEjz0Vvi0WBl82oFGl3BRjdsAgSCMNooOhcsF2U8Mr3fhWQDP3LQx7Pw==
X-Received: by 2002:a05:6000:40df:b0:3a4:cbc6:9db0 with SMTP id ffacd0b85a97d-3a572e563a8mr6702740f8f.51.1750089735760;
        Mon, 16 Jun 2025 09:02:15 -0700 (PDT)
Message-ID: 
Date: Mon, 16 Jun 2025 18:02:07 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] memory: arrange to conserve on DMA reservation
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper , Julien Grall ,
 Stefano Stabellini ,
 Anthony PERARD ,
 Michal Orzel 
References: <6565e881-ec59-4db4-834a-f694bf1b9427@suse.com>
 
 <9b036f26-f275-48d0-9a33-7cef38b29f48@suse.com>
 
 <2969b5d8-5879-4674-8332-046898e17257@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 16.06.2025 17:41, Roger Pau Monné wrote:
> On Mon, Jun 16, 2025 at 05:20:45PM +0200, Jan Beulich wrote:
>> On 16.06.2025 16:46, Roger Pau Monné wrote:
>>> One question I have though, on systems with a low amount of memory
>>> (let's say 8GB), does this lead to an increase in domain construction
>>> time due to having to fallback to order 0 allocations when running out
>>> of non-DMA memory?
>>
>> It'll likely be slower, yes, but I can't guesstimate by how much.
> 
> Should there be some way to control this behavior then?  I'm mostly
> thinking about client systems like Qubes where memory is likely
> limited, and the extra slowness to create VMs could become
> noticeable?

What kind of control would you be thinking of here? Yet another command
line option?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 16:13:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 16:13:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017480.1394467 (Exim 4.92)
	(envelope-from )
	id 1uRCSe-0003ni-KH; Mon, 16 Jun 2025 16:13:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017480.1394467; Mon, 16 Jun 2025 16:13: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 1uRCSe-0003nb-Gj; Mon, 16 Jun 2025 16:13:28 +0000
Received: by outflank-mailman (input) for mailman id 1017480;
 Mon, 16 Jun 2025 16:13: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 1uRCSd-0003nV-Ag
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 16:13:27 +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 d5529c92-4acc-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 18:13:26 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a54690d369so4824107f8f.3
 for ; Mon, 16 Jun 2025 09:13:26 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2365dea7db9sm63270755ad.144.2025.06.16.09.13.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Jun 2025 09:13:25 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d5529c92-4acc-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750090406; x=1750695206; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=AT51K1kyBLdfvjQr1IzBZ+xONHOeI1IdmdICRpv83DE=;
        b=T3GGJG7t4CIwj2HbZNiwnoWC2iHnKYqHF2I7zDonTbuzr81E1bi50TPHezm1pujfWp
         j31vEj7Af7NXoSdQ73acUpc2ZT6snsPN/D3z89OqTk6Oq5hOegCUCogbyFj/TtxgSWDu
         8T29+TKZyAA5p76rS+cP4acUQssAlYyAhSjauQ8mQbaJbfVU6AyRKwrIrMLFtA07H7jV
         jbTyIJKrLPYb0o7g2ewvYyUAVGEP/Z3M2MfDdrf+bBim5VEpX87+MpSyAliSUAUsiFhw
         YPfsaxefVelOPHAzoQjAK+8ixRTm1MqQs3LshpZahQXF0hNgJNXXnCv6F6FIdgkvttfx
         obOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750090406; x=1750695206;
        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=AT51K1kyBLdfvjQr1IzBZ+xONHOeI1IdmdICRpv83DE=;
        b=hXg963hODj1yHvMnqSVkQMdSDl63aHx3vfkwcnzXbddjQt9RI+EbH8q//ijKa/e9JY
         RoWc7M+gZ0c5FdL2DgYw8USNmlbDUtdjTmbpTr+kRFKpN2DGS5GmXxDDYv6bAHyDi2Yg
         7P/GJtlBKY7pqMbFAI2CZC6SrgA4a83JmRd9iwV/Zd9F7j+hLZoJueNL4qxLvzF/8ig4
         T2kLfmGFWctfTjIdb7VfnKaLh1+JKGKXkBurT6R8ltwYe95DordIGc0VYnHs26V9pUw0
         KoFd5iPhJp1t0fVAoRqn+1KV2AV5RGd4EnN34SJQO19MeAsbNZhrQz/jk9fBOQl+BGDM
         fqug==
X-Forwarded-Encrypted: i=1; AJvYcCWH1hPMsM6E2Oq9YC+gsX+XwtJuL8Pt+O5JFeY4QIVQz6OkVHP5R0n3rKPTvvbXFd/lIKJ2HLIEWW8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxdrTHF4KvgQjRT+LgoMHokL2zugi/Y5SzhWthSiBnr+beR6obJ
	HfY+kYRGBEO2TzqoJbhvQ+S0QHgisSqR+6x1c3xsTMl0zXgVLvPGBunCgSSxKSAiCg==
X-Gm-Gg: ASbGncvVXnioRfQfDwJFcLUEmOJ6XPQA/6/orTX9qzygn2vQWZtglGYLCYWXBfyDP3L
	WGHjfzIfodoDNCK5+/pn1jRLYpO4f8rIBb3YCiw2xijVjFoR1Fs16zC/KGEqiEbIRRBgUAX5gq5
	R/Vo5+NinHmMoff/Rm0780Ctxw8lkR5+is5C0/oW58L5FvyHO92QGoB2CWO23sHXx9nFYV2/Y/1
	1vXcmBpkjnZWM/A6Q5kV+wD+UK65BcNFRNvABMoCPYjIuGL/C9X6+bfLKi2sbh46PcBCnpY4NxD
	CHHO0eCzwykWnYOGxwWKapN+e7DMazGtawiITFHbZZo0mllYam8nZYG5oRX4NZ9LTrz6Hctet8g
	h3gYPjWo9h6ZqoXKd7oF/oY2QxX4c3k2cSIji6/zZkpPNMfaSFAXjJw7Uow==
X-Google-Smtp-Source: AGHT+IECM5JbJHOEvARDYqQudLpqHeJ5FkvDyxpxWr+fKcS9dglKfkigvj2PJ/j7ZCKHH0kAeMBcbw==
X-Received: by 2002:a05:6000:71a:b0:3a5:27ba:47c7 with SMTP id ffacd0b85a97d-3a572e2df96mr7586058f8f.48.1750090405604;
        Mon, 16 Jun 2025 09:13:25 -0700 (PDT)
Message-ID: 
Date: Mon, 16 Jun 2025 18:13:16 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 11/18] xen/x86: implement EPP support for the amd-cppc
 driver in active mode
To: Penny Zheng 
Cc: ray.huang@amd.com, Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-12-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: <20250527084833.338427-12-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.05.2025 10:48, Penny Zheng wrote:
> @@ -537,6 +537,14 @@ choice of `dom0-kernel` is deprecated and not supported by all Dom0 kernels.
>  * `amd-cppc` selects ACPI Collaborative Performance and Power Control (CPPC)
>    on supported AMD hardware to provide finer grained frequency control
>    mechanism. The default is disabled.
> +* `active` is a boolean to enable amd-cppc driver in active(autonomous) mode.
> +  In this mode, users could write to energy performance preference
> +  register(epp) to tell hardware if they want to bias toward performance or
> +  energy efficiency.

Who or what is "users" here? Certainly not the person reading the doc, trying
to determine whether to use this command line sub-option. That person can't
write to the EPP register. (Or really they maybe can, but they shouldn't.)
It's the driver which is supposed to be carrying out such writes, isn't it?

> +static int cf_check amd_cppc_epp_set_policy(struct cpufreq_policy *policy)
> +{
> +    const struct amd_cppc_drv_data *data = per_cpu(amd_cppc_drv_data,
> +                                                   policy->cpu);
> +    uint8_t max_perf, min_perf, epp;
> +
> +    /*
> +     * min_perf represents the idle frequency, while max_perf represents
> +     * the maximum frequency
> +     */
> +    max_perf = data->caps.highest_perf;
> +    min_perf = data->caps.lowest_perf;
> +
> +    /*
> +     * We set min_perf with highest_perf in performance mode
> +     * and max_perf with lowest_perf in powersave mode, to achieve
> +     * ultmost performance and power savings.
> +     */
> +    switch ( policy->policy )
> +    {
> +    case CPUFREQ_POLICY_PERFORMANCE:
> +        /* Force the epp value to be zero for performance policy */
> +        epp = CPPC_ENERGY_PERF_MAX_PERFORMANCE;
> +        min_perf = data->caps.highest_perf;
> +        break;
> +    case CPUFREQ_POLICY_POWERSAVE:
> +        /* Force the epp value to be 0xff for powersave policy */
> +        epp = CPPC_ENERGY_PERF_MAX_POWERSAVE;
> +        max_perf = data->caps.lowest_perf;
> +        break;
> +    default:
> +        epp = per_cpu(epp_init, policy->cpu);
> +        break;
> +    }

Blank lines please between non-fall-through case blocks.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 16:22:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 16:22:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017491.1394477 (Exim 4.92)
	(envelope-from )
	id 1uRCbW-0005dL-Db; Mon, 16 Jun 2025 16:22:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017491.1394477; Mon, 16 Jun 2025 16:22: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 1uRCbW-0005dE-Ab; Mon, 16 Jun 2025 16:22:38 +0000
Received: by outflank-mailman (input) for mailman id 1017491;
 Mon, 16 Jun 2025 16:22: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 1uRCbV-0005d8-BD
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 16:22:37 +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 1d415d60-4ace-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 18:22:36 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3a50fc819f2so4005409f8f.2
 for ; Mon, 16 Jun 2025 09:22:36 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-7488ffecd29sm7033077b3a.31.2025.06.16.09.22.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Jun 2025 09:22:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1d415d60-4ace-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750090956; x=1750695756; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=iJ22bVt6JnasgRgf0jzNkO9g0kG/12p0K1GXs13R5kU=;
        b=G2+b3ljizD4kFORYWTe+Aeiz09l3ozhXi9Hl6mWoNwMU6JOacqKmlh49D5ClG44wA5
         8LIX9GJYg2WmCMZrBNZ5R5fQSySVMbuXDmbxGXVAbO1ufWanrItCYpIG3c6s+nreN3Sj
         3v/3AwAffB3PR1MUKTN4k5tSEaFqQSq37tDeV+rd22O1qYaLDbAhwteykmAqingdTRQP
         QbcZhLsbuek923tcRwcrg+JY9bF9KA6iTmJOwgeTk2k8dprQyN7E09fwNrj0t9VR0yDb
         X4gsmMvp38VS7Tg+DTnuAdIdY0KZQF9+4bN8PZuH3YkLVS/t5DZuuyYLkkZNMQlZhzzp
         xNkg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750090956; x=1750695756;
        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=iJ22bVt6JnasgRgf0jzNkO9g0kG/12p0K1GXs13R5kU=;
        b=xLDA/Oo4mUTjLxK1REp27CnP5m3r+7R5bY7BFg7wXTaBqoG4PENTW1NVD/X0D7RxVj
         GuoKh7d86wqv7W/ik5dkiF/4ikbiIUUAMjp8iC7a6JXCIPBrYn7i/XPpL6TiJrzZmwlX
         hyU3r4eFnGFWU0/w2tih7Cx+Z8vsJ4a5yOOwcdgVSJYs1Ex1mua5fLd/VzPt0fHuT3jN
         BM/jiITtK889yKf9RsQ5R4XwZn9+vLXolh7drgBYikgq5LKPOOGOL68ZlcCy6PSZSFhQ
         L0b1hQD7vAhTxVjHnTB9Ss9lUsqZ2gidostyEHmhgmAwdzWXbLg1pTh2NMbDfQ9k9TMq
         GW+Q==
X-Forwarded-Encrypted: i=1; AJvYcCUPgrWryO0WY5ojnM1blyUQIhZ9jWzUWCc1QiWkUYV0DLCyabFEc2J0trQ4o2ilhDduG0w5W13K6Xo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyhLzSybk/KemTlKk7oQmaTNc5ZJ5Fn5ZJFf81y+qW3Z/Rx379k
	XVYsv+k0iEo4dGLVNVCMZZLyi4iCHFrwIk9gB/6umwI+j78WPMhBmEJeUCYwVzfdJw==
X-Gm-Gg: ASbGncvqH4MNt92+y0IwMlUsh7I3HP2d0cJnCE1Yh34qk/1oUhrmmnQjk1KtiZJzxAx
	YwsBE/+XsQDVEb1t8TRXygZW3ty3+5q47sRxcL13Th+GJD/54sVysRPH25+s/bXJlIkpCsEnz0U
	X/IUeQ0UwMfhNHjqCTxW0tMHke7Zce8owx0wDCgRnjJgtYBfvva6MHsFUeO9E0b3Vahrv7cZ3Im
	Hk+4gDlQkUO72wQBQaVY0lPQ5Inb0g07MlWcg8GrhCkPdK0B9mWcOT+KxLHGSPt9PvpDOP02QSh
	t9MwZdXkxsQAqXjkv+8xBK0Qq8GTZayp+rYchV0jhvO8WPr6NWeNYyLObNYbrycc+1F/cTj6xCQ
	w/1WL3eNGMY6pd4hIYTg2H+1964eaevx/pTrmMtxFbMAG8H4=
X-Google-Smtp-Source: AGHT+IHdvxuxQ5SG5jNnjzIdMVwiUNfIURrrc/a3Xr2Rx6VoNt0acRIWE+vqYfw0/jsSEa9bfkIMNw==
X-Received: by 2002:a05:6000:1888:b0:3a5:2949:6c38 with SMTP id ffacd0b85a97d-3a572e99690mr8949618f8f.52.1750090955720;
        Mon, 16 Jun 2025 09:22:35 -0700 (PDT)
Message-ID: <0a5c9445-904a-4321-8406-8618fd82313b@suse.com>
Date: Mon, 16 Jun 2025 18:22:29 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 12/18] xen/cpufreq: get performance policy from
 governor set via xenpm
To: Penny Zheng 
Cc: ray.huang@amd.com, xen-devel@lists.xenproject.org
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-13-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: <20250527084833.338427-13-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.05.2025 10:48, Penny Zheng wrote:
> --- a/xen/drivers/acpi/pmstat.c
> +++ b/xen/drivers/acpi/pmstat.c
> @@ -319,6 +319,14 @@ static int set_cpufreq_gov(struct xen_sysctl_pm_op *op)
>      if (new_policy.governor == NULL)
>          return -EINVAL;
>  
> +    new_policy.policy = cpufreq_policy_from_governor(new_policy.governor);
> +    if ( new_policy.policy == CPUFREQ_POLICY_UNKNOWN )
> +    {
> +        printk("Failed to get performance policy from %s, and users shall write epp values to deliver preference towards performance over efficiency",

This message is excessively long and is lacking a newline (i.e. effectively two:
one in the middle and one at the end; yet better would be to find less verbose
wording). What's worse, how would a "user" go about "writing epp values"?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 16:24:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 16:24:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017501.1394488 (Exim 4.92)
	(envelope-from )
	id 1uRCd7-0006CQ-TO; Mon, 16 Jun 2025 16:24:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017501.1394488; Mon, 16 Jun 2025 16: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 1uRCd7-0006CJ-O1; Mon, 16 Jun 2025 16:24:17 +0000
Received: by outflank-mailman (input) for mailman id 1017501;
 Mon, 16 Jun 2025 16:24: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 1uRCd5-0006CB-TF
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 16:24:15 +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 52233d1c-4ace-11f0-b894-0df219b8e170;
 Mon, 16 Jun 2025 18:24:05 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3a35c894313so5378689f8f.2
 for ; Mon, 16 Jun 2025 09:24:13 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-748a6b1d620sm4133340b3a.116.2025.06.16.09.24.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Jun 2025 09:24:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 52233d1c-4ace-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750091053; x=1750695853; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=eSCJ7/mkL3BvXuKI7zkoRMrFgPTCvPYO/2N1D8SOp9I=;
        b=ZLBPwPpy6LyaWNClZPBbHfp0aPYWfhnV1OVGdm8mwGpgCoRdqiziTkSJ3wiXkJrHlA
         W1S/r87PXUep6KYzQpTtT8rxuU5DZDlqG8dYuuDqzgYUhghLJVhFaPTpbh7XyXtvYEG0
         c2jfG9h7c1V4Y7ijE5M+s42apn17h+v/+lH+FEvwCnA+Z32yHJbIk6hoPWIxu2Rb9zPC
         /S6NZ0abImj2dHrjooOPfblkJUviqMluTCwOKnB7o2fdA2ehVpVmwdbYGg2Fqj4kNU34
         9wooI4bWnfsxbEjD7NIMioDneCxIkMa3cFY2PZtU5Ae4v4Zb2axHJhEX1jC+SSFunuct
         ItFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750091053; x=1750695853;
        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=eSCJ7/mkL3BvXuKI7zkoRMrFgPTCvPYO/2N1D8SOp9I=;
        b=mjcgpBQF4OrLR/ays8ifrt76XVn63dv16hkKGY6kdzZWDDAAIHwCGdB5Bix8SefAyp
         MPTPayIAam7/wowJglW/9WV6CHYbyoewaOncdOASdgrUuSinb/wVnf/1wsghVMkzav3u
         ptRPfsy0QfvETsyr5LojX0g75AQrqUsjzjKbiMdJDlR4XOMiFpj3FRRoqYqIZr0c6ttw
         wdbxNDPKzrC0MdDsybumfkwPOhLVcLFf9ttly2poyixiLMVn8DBHcMAHluHTiqQ85/Cy
         2jDh3A8dZeiZ3rVnPM6/UDKgRKHjwq4LXTA5UmAhOfCKknq6XpZsC7Akc4AgykL+xBrv
         jQaA==
X-Forwarded-Encrypted: i=1; AJvYcCXZixBKxS06T+iWxuLjd3BhEp7xf3DNdL0xNURLQDZ9EUDXtMWd72PUVPLbzeul4K83qg62NL4ccxo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzTmgIT/+aB/ixowpLMwPlaOdKbmcvr4btYcpU5qnrLbv+OwsSH
	AEtKBlTjo3ED7u+lE5K7djq88ajXD1CK1Ic3r7S0BJCk0GET6fAPY+BHc/dzu13aww==
X-Gm-Gg: ASbGnctEpp8KajFo/GRVwYxgVQGNPIcGqde374qVrqZnDIGOpSQj0RxIKjQ89BcPBxz
	sGUa/Ssp3maeMHW8r4/fQma5sta1MvV/uCOY7rs0e44O/dlYa6w5x+P59WGmI6zJ9hbp8DIYmrK
	Zd5pdCNo9sUnblJ8ipH6S2tibeZY399y6pURrIOe6vH5puvxBGnlgAaezgefmNmGEN+pxjUCfxG
	ivPXEXaS9cMIv7x8l2wItoL6yhIME8a1Uicuqm5pUm7vh4m5Q84NsfUthXH6Fk06oeG4sI6H0z/
	uxIAW5UOsyOpKcM36b8BuFA6u49nsetvVV7szB2/liWzf65vi9uJBt5u+iNLwOh1BCinw1GOn9H
	4JjAj8f/yC5pkigwp3F/RxnZDwhPxpbzzQ8Iht4zm1qJe0hrrQeWTF55o0w==
X-Google-Smtp-Source: AGHT+IH16MFIwKXm9NacQxcfC73Pa0ChKE7VbvK5ZZon+cljZ0ZTU1wUIHfm3XjFZVlZFHNTH6G98A==
X-Received: by 2002:a05:6000:230e:b0:3a4:e740:cd72 with SMTP id ffacd0b85a97d-3a572396df6mr8229313f8f.13.1750091053379;
        Mon, 16 Jun 2025 09:24:13 -0700 (PDT)
Message-ID: 
Date: Mon, 16 Jun 2025 18:24:06 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 13/18] xen/cpufreq: normalize hwp driver check with
 hwp_active()
To: Penny Zheng 
Cc: ray.huang@amd.com, xen-devel@lists.xenproject.org
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-14-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: <20250527084833.338427-14-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.05.2025 10:48, Penny Zheng wrote:
> Instead of using hypercall passing parameter to identify hwp driver,
> we shall use hwp_active(). Also, we've already used hwp_active() in
> do_get_pm_info() in the same file to do hwp driver check, it's
> better syncing with same way.
> 
> Signed-off-by: Penny Zheng 

Acked-by: Jan Beulich 

Is this okay to apply ahead of most/all of the earlier patches?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 17:05:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 17:05:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017509.1394497 (Exim 4.92)
	(envelope-from )
	id 1uRDGb-0003ZP-LI; Mon, 16 Jun 2025 17:05:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017509.1394497; Mon, 16 Jun 2025 17:05:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRDGb-0003ZI-IN; Mon, 16 Jun 2025 17:05:05 +0000
Received: by outflank-mailman (input) for mailman id 1017509;
 Mon, 16 Jun 2025 17:05:04 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uRDGa-0003ZC-4c
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 17:05:04 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on2060f.outbound.protection.outlook.com
 [2a01:111:f403:2418::60f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0a3a283a-4ad4-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 19:05:02 +0200 (CEST)
Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
 by SJ0PR12MB6808.namprd12.prod.outlook.com (2603:10b6:a03:47a::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.41; Mon, 16 Jun
 2025 17:04:57 +0000
Received: from PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264]) by PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264%2]) with mapi id 15.20.8835.027; Mon, 16 Jun 2025
 17:04: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: 0a3a283a-4ad4-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=AcQjBorX7K52e8zXNPeLeF52xjrA+z4a+8iQrhao9OF1tYXhB6W25b1BMC/BD/tTWG/TyAV+uGfEEUDTlyYkaC5kCRgZuQuZjpkDFOCpJi2t+khQRBWdgxAJ+AXnJkNj5GyIlSANoeIt2Z2k0eV5AMgJg6eZOA0loUfsVOZxAreX08b31VYizh25e+yTz6DYnazZ4kidujhGJjrsRJy6GQ4bZPWSgvIs9Wx5n+SyNMtX7u4jsvh5FfDVgIBFQdfmug3jUl+zGA24Cju1WTE+U6iJrf9leBdIZ1KDAk5O8+lGPBtujGW+kl5UuhF2lghvYqEIFQBBAGqG/n2FRZmKIw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=BVcjEOF6eT0bBuuDqPTmFuHl+8aKiC54N6sRdkEgYsk=;
 b=Db+zzzLtcWiz+hrsDSplinPPKfj+H59tY9gU6yDM+z9Fo1OeqoiqxLvdK+XFyXZgLBll/r1aW+7m3Rwd28psjTSIS+D/D/z3jpjQFe91MW70/opKWqjlzZpc2sHcJOBNXhO1Mr7xqoPaNPoeK2f0QnazFg1Q7RMILRRdmKQBKyVOkO/ymdHCJl6kLKzh6BkgWMP4xzTWyM51auemZq46gajozxJicFVHXsSnxOTJt7XmEBxTfAM+G9XGI0snkDsBZ9FKiXVMkrPzq4nbUroqUgl7z3bVJUEdAaBE9Xe/FgLS9IKSrUqMAF8oH0yX5nvCWyJNrHpuXJgdPlx+bVBFzA==
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=BVcjEOF6eT0bBuuDqPTmFuHl+8aKiC54N6sRdkEgYsk=;
 b=phqevA5a2SK0G15zyFS6gjOAKpUmfVs+6Jr4J6/5kPROeMYrcskKekKw7un3VcEKNZq5xkrrwVDAndG7HCjflV+XKn8/SPOwdAE6CeVRRr1TDvHEpt8FymuWY8gD69WldDJrronpdumjip1xW9nYTr9HMQFJN7lc1X+zaGZ+DLM=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Mon, 16 Jun 2025 18:04:51 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 4/6] arm/mpu: Move the functions to arm64 specific
 files
Content-Language: en-GB
To: Luca Fancellu ,
 Ayan Kumar Halder 
Cc: "xen-devel@lists.xenproject.org" ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: <20250611143544.3453532-1-ayan.kumar.halder@amd.com>
 <20250611143544.3453532-5-ayan.kumar.halder@amd.com>
 
From: Ayan Kumar Halder 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: AM6P191CA0054.EURP191.PROD.OUTLOOK.COM
 (2603:10a6:209:7f::31) To PH8PR12MB7326.namprd12.prod.outlook.com
 (2603:10b6:510:216::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|SJ0PR12MB6808:EE_
X-MS-Office365-Filtering-Correlation-Id: 30a8e00e-ffd3-417d-a8a7-08ddacf7ebd0
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?c09MMXFhNjM4SE1sdU05d2t3OXBDZ2paTEYyNmNYeVEzQU5aMW5CNUtUOExD?=
 =?utf-8?B?VC9uT2x6VHhiN05NbEkwVnNDeXJMYkRWdUhqNkNFdmdLUmpKOUY0UHBIUFdU?=
 =?utf-8?B?RmVxK2hLcUc3R1JzeFJNaTlybzhPOTY4bW9kY1ZkbEdrQ0h4K2xmMEdzM3Rm?=
 =?utf-8?B?a0ZhRHc3dlJkVW5kbDBQNTNJKzRhQW01OEJPaGVxWGYzNFZXMmlVWHR5QU9W?=
 =?utf-8?B?MEpmZnJaRHZEbjZodURXdFBFcXJxcm1hb3BMZk96eW5YSUw2Vi80eUl6SGdT?=
 =?utf-8?B?NEdjMkU0b0w5bVp6UmJtSXhSd2pRR1B6VW1wTlNpc0lML0dVOGcwYW9kNCtX?=
 =?utf-8?B?Z0VBNGJCODFJVWZhZWdLSVRuMHFia0hkdFZpZUNuVmp0VWNDaXlDamw5STU5?=
 =?utf-8?B?dmNPVCs1RnEzVXlmSkR5YmRBdGRZVE9mZWdxNmN3VU5McmdZV2s0eXhqbmoz?=
 =?utf-8?B?d2F1QTc5c1JSek1HLzFCdFZYeFVFZENPbGlWK1I4TnV4VGFCOGd5SHBTMGN5?=
 =?utf-8?B?RjZRdVM5NkhMN3BQNU9YdG5aVzV1emFkSi9jbnFmTnA5cjZkM01jTGpxWmdF?=
 =?utf-8?B?bkJZUFpWUGpPWEovSXgxcndRL0F2Q0JxWXk5S2dGTFdZTUhKb3NTcmJtS2JK?=
 =?utf-8?B?UWpTL2gvSjZFaGV1UzdwbkMrNlVQSHU3MDZKZTV5Q3dGRG5JYkc5RmpqQlJY?=
 =?utf-8?B?SytXTnlWZXhhdEhyT0EzZFNLemV2WXV1TkxkMllOYWYxazVYbDlxREdrZGFY?=
 =?utf-8?B?d1lMOTRuVHBta2V1WkdycWRZMUpPajRnYVM2M1NuYVJPWG05OXJpZnkrVXdx?=
 =?utf-8?B?aFNiUUtiY0FseTFKTzU4WjFDNHlMVGVuSFBEWmo2UnJyanoveCs2aGtJeXgx?=
 =?utf-8?B?dk1UVGVsVHlqWldjT1NUaHd4N3dkTHNpYTFwT2FuTEZ6czhMRndlTnQ0a1JC?=
 =?utf-8?B?T2dSaG1tUnV6aHh1N3NwUlZWSWNValVkSE5KcjExbVd2WlZuamExRDhkSkhB?=
 =?utf-8?B?ejUxSFdLcDNDZENJWGdPd0RTMjhsUVJta3RSdHZNTWFEU3dxd0lJc2cvRVVq?=
 =?utf-8?B?bFR5RVhFSzZwdFpCUVloOWFyTVBRTi9EejVvZFplUGRvanhPdFQya0wyK2Zs?=
 =?utf-8?B?U3liRVUzOTJ1RDk3SC9jQWVSdzltYnpNekc3WFdFcFZSTStjWENBQUowUE5j?=
 =?utf-8?B?ZWRaZ0RhTnRVN0NYSi9TNTQvcFJaYkRyS0NybTdoTkFYN21NcjJOQ2grcm1L?=
 =?utf-8?B?Q01wNjA2UHNWYU9RSkJ3c1VGbE11NnBsZkJENmZmcWgrM01hZEJTWFE2NEMw?=
 =?utf-8?B?UnlDbXAzY0RXSm1RNGZqOUR5ZVJyaWgwWGh2ekpzT2xNcFd4NStKM3pYK1lr?=
 =?utf-8?B?ZlMxbjRoUjVZYi9HVnFVcUo3YXpVY0tUYXo5Yk1udnAwNk1FNTBkcmYvamxw?=
 =?utf-8?B?dTkyOGsxeFFKUDNITktQbmVVeEp2UnlvVi9QczRNMVdqcHdVdXE3NTFRR3VZ?=
 =?utf-8?B?em44VTlvL0RaSnlOVlZCNEQ1RkJGbmsvU1JVK0twUFZrWi9VSW5tNHpUbG5O?=
 =?utf-8?B?QVpyZ1gyYys5dVdwbGxUa05hb0l5dmJMUGtiUWVFTmNaODFNNTEzakJzbDQ1?=
 =?utf-8?B?WmprcDNGMVhSZ0FBRktaN1N0VjM2dEVtK1EvM1JEck9yRmZZY3Q4K2o4cWhH?=
 =?utf-8?B?MlVRMmNkRll4bWVmNXVFVlNGT0IwNGhPVDEzL0dGMWJtQXhUS2orTHVKV1ZP?=
 =?utf-8?B?amJUc1ZBNEk1bjBubVlPbGNXYUptTGRzT0I0VlhrTTg0R29ielVwUUpUYmw5?=
 =?utf-8?B?Z3I1WnJBRUdFcjdScWY4QlZDWTdRU0lZS2wzdGcrQUlvZVpuZUh1S1JtVi9L?=
 =?utf-8?B?LzRQYy9wWXp6NWNZc29CSHlYR2J0UDJCT1N1U2tNdFB5QldrR0pGVENrRzVW?=
 =?utf-8?Q?7TpSgAaVS0k=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?aG5oc054amhWR2pJdSs1L2lLQnhRa3dVdDhsU1UwMWFGbTl5S0tjdHZoUjkr?=
 =?utf-8?B?c0JIOGRLd25ndjRZUUZHQzFVUjdRVTVheGtIQmtrczZoano0aVNBTVVadkE2?=
 =?utf-8?B?TnN3d1hKc0VubmJ3OTBidlhCVGk4dklFR1VvWUdQZTF1WktIaVNYeU9wNytG?=
 =?utf-8?B?Vk5HWklrWjBoTzErUGdrSHlzNnEyZmRxN0F1OEdmbVVUdVpxSm9pVFBVRnAr?=
 =?utf-8?B?aU1aWk00UXpYYlJybDlQZTR2U1ZKZDd4SG1oRGhINFc3Nm9CcTVWK3dCcnpl?=
 =?utf-8?B?bUNndmNsZTZDcElaTUZlVnZpZCsyUkpFbWo1NENranFTQTFhSnlndTVpOTc1?=
 =?utf-8?B?Unlub2JIWFlYSFNhblZZVmZadUhRR1V2UHg0dVE2MnBaOG11d1lkZEQrS1U3?=
 =?utf-8?B?QlB3dWhPOG9kOXBhdEttL29MZFFsdU8ySnU1QWpJVER3a3EwVk5rNjBKVFBk?=
 =?utf-8?B?dWRRbk5xZ2p5ZzRvTjJrb0w0cG1iWkNLK1h4LzZKWnZDZE4wYkdTM1B2RjQ5?=
 =?utf-8?B?b0htVXJSUWh4OGE1K2xNeWMwZlg2NlV3dFUvelFhajVCV2lZVEZ2ME9HWHp0?=
 =?utf-8?B?OFB3RmR1c1loby9vM011NnlxenBoUWVQR2ZYZ2tTVnZXSXBIeTF2ZU9QYURq?=
 =?utf-8?B?Rm12NGdHbDlZL3ZSakRNUk1TTU44UjFHdG5tQ0lGMDRrcURJUmwwTXJCWGE5?=
 =?utf-8?B?bWFBc20rQXh0NjB4bEhVM1RGelRQWVpJMTA5LzI4dUFWaFlPZ2RhcFBXV3d3?=
 =?utf-8?B?Sys0eUU1R3J6UDlxVCtzamJ5M1V2UVh6SWQzTUZ6Vmx4dVVtY1hBeUtFbVND?=
 =?utf-8?B?Qy94ZkFFMHBERXYvQnFjM0VDaGRMV200Myt4MW52YkFFZlZ2M3U5M1JTZVFG?=
 =?utf-8?B?Um9GWHJnZC9mZ0RHamZoQU5tRHRaNU1YcE1CRWEzSzFLVUFMK1VnTzBNRy9h?=
 =?utf-8?B?OE1hcUZ2enhmMHI0UWhwTjNxUUNrOTd0L2p5MVNBeTZLVnNYYVVRZHI4OWlR?=
 =?utf-8?B?alZIZWxpWi9PZjVSTi9mZjYrZDdSSEJ6MTE1ZFZCU1ZUOUhRUzFHL1pGbU5o?=
 =?utf-8?B?b29kWmZpSDlocXJiK1hTQnBXTXhxR25PNmhEYWlVOXZkcmYyS1RlVkRJVVpw?=
 =?utf-8?B?T3pJbGU1RWxuSE9aWlhFMlFwcytEeVRvM2VFV0RaWldUeGVTbi9iVUcxZEpu?=
 =?utf-8?B?UGZib3lYcms1NHNlREJaa0FpWlB1UEFid2I1dlJ4cGRBekYrNkFXbHFYcUJ3?=
 =?utf-8?B?b3AyUU9CRUFjU3VMUDBCWldPWk9iaVJFajlSRDNWdXVwNVc5dzA0N21hUzNX?=
 =?utf-8?B?OHFOaEhyazB5NW5zaWw3NEQ4Mi8rMGdPbWl1eFJaSTFsVFZPa3hwZXo3anZ2?=
 =?utf-8?B?MWgzc1VZL09IUHE2cm02SjVLUkxkVmM1TGE4cFBoZzkvUjRlb2hRZDJ2K3lz?=
 =?utf-8?B?eitqRy9WamlwVHl4cCtmWGxkRU9yWGxUTmlVZkxTMHFwYWREbHFlZmJuOExN?=
 =?utf-8?B?M1ZmWU9CU1RwcEtpUEE5N244NnVXYkdlNWRUeEtoa3U3ZzlCaUJWcGFHY1hm?=
 =?utf-8?B?aldocGlndVpLQ3FNcGZjSDN2Vmt4ekJSRWg5WG5jcFdBZmJvMFBqOS9CQWg1?=
 =?utf-8?B?WWt3b1JGa2NsOElCZUJrci9WR3hENFpnRUplU0U0S3lscllBbUZzb3BOMXUv?=
 =?utf-8?B?MC9EWkpDaUVzaVRGSzNsbSs2RTM1VnUwV01VRTAwdml6RkRFKzZ1QlkyYW5t?=
 =?utf-8?B?WjhiY2JYN2RpcGU2NFhUb1dla1dwYzQwdlRpajNsWDBUajNCWU0xZFFlSjlN?=
 =?utf-8?B?dGd0Yk9NeXYvSmF5WXJBY1Y5WFo2dW5jeGQ1UUU4NGdVR2tIV0dZWHJIclJT?=
 =?utf-8?B?TEt2dC9KdVRPZ0ZrVStCRGhBb1l3UzdTMFAxSXpCNE4vYW5VbFZxcEFBQ1Iv?=
 =?utf-8?B?OXhVcjFIMlpiWEJiZGlpV1R4Qld4N1hLUTZGT1JkM3RhY000RUtOaEJabFRS?=
 =?utf-8?B?VWZHS3l3Z2JmbDFrak5vcU8xVjdYNjNRV0NrQWMvVld5Q05nOFo5RDJGdUxp?=
 =?utf-8?B?SkJ3d1FCQ1JrbUd5OVdjMzRQNnRtemQzRmJYZE9HVGlteC8wR2F4UnlJQXUw?=
 =?utf-8?Q?WG+0c+vbHDOyHqESQnZ0YdQrc?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 30a8e00e-ffd3-417d-a8a7-08ddacf7ebd0
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jun 2025 17:04:57.3810
 (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: bBF5uyRK6jrLKCR/3o6mltUXA+BbTGBTNRzeX4MmHazhuVSAHF4hXGd1XlGi/fZ4W8rt5WzMW8b81J928xnEOA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB6808


On 13/06/2025 16:08, Luca Fancellu wrote:
> Hi Ayan,
Hi Luca,
>
>> On 11 Jun 2025, at 15:35, Ayan Kumar Halder  wrote:
>>
>> prepare_selector(), read_protection_region() and write_protection_region()
>> differ significantly between arm32 and arm64. Thus, move these functions
>> to their specific folders.
>     ^— NIT: “to sub-arch specific folder”? What do you think?
yes
>
>> GENERATE_{WRITE/READ}_PR_REG_CASE are duplicated for arm32 and arm64 so
>> as to improve the code readability.
> It reads a bit hard in this way, what about:
>
> “Also the macro GENERATE_{WRITE/READ}_PR_REG_CASE are moved, in order to
> keep them in the same file of their usage and improve readability"
yes, this reads better.
>
>> Signed-off-by: Ayan Kumar Halder 
>> ---
>> Changes from -
>>
>> v1..v2 - New patch introduced in v3.
>>
>> xen/arch/arm/mpu/Makefile       |   1 +
>> xen/arch/arm/mpu/arm64/Makefile |   1 +
>> xen/arch/arm/mpu/arm64/mm.c     | 130 ++++++++++++++++++++++++++++++++
>> xen/arch/arm/mpu/mm.c           | 117 ----------------------------
>> 4 files changed, 132 insertions(+), 117 deletions(-)
>> create mode 100644 xen/arch/arm/mpu/arm64/Makefile
>> create mode 100644 xen/arch/arm/mpu/arm64/mm.c
>>
>> diff --git a/xen/arch/arm/mpu/Makefile b/xen/arch/arm/mpu/Makefile
>> index 9359d79332..4963c8b550 100644
>> --- a/xen/arch/arm/mpu/Makefile
>> +++ b/xen/arch/arm/mpu/Makefile
>> @@ -1,4 +1,5 @@
>> obj-$(CONFIG_ARM_32) += arm32/
>> +obj-$(CONFIG_ARM_64) += arm64/
>> obj-y += mm.o
>> obj-y += p2m.o
>> obj-y += setup.init.o
>> diff --git a/xen/arch/arm/mpu/arm64/Makefile b/xen/arch/arm/mpu/arm64/Makefile
>> new file mode 100644
>> index 0000000000..b18cec4836
>> --- /dev/null
>> +++ b/xen/arch/arm/mpu/arm64/Makefile
>> @@ -0,0 +1 @@
>> +obj-y += mm.o
>> diff --git a/xen/arch/arm/mpu/arm64/mm.c b/xen/arch/arm/mpu/arm64/mm.c
>> new file mode 100644
>> index 0000000000..a978c1fc6e
>> --- /dev/null
>> +++ b/xen/arch/arm/mpu/arm64/mm.c
>> @@ -0,0 +1,130 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/*
>> + * The following are needed for the cases: GENERATE_WRITE_PR_REG_CASE
>> + * and GENERATE_READ_PR_REG_CASE with num==0
>> + */
>> +#define PRBAR0_EL2 PRBAR_EL2
>> +#define PRLAR0_EL2 PRLAR_EL2
>> +
>> +#define PRBAR_EL2_(n)   PRBAR##n##_EL2
>> +#define PRLAR_EL2_(n)   PRLAR##n##_EL2
>> +
>> +#define GENERATE_WRITE_PR_REG_CASE(num, pr)                                 \
>> +    case num:                                                               \
>> +    {                                                                       \
>> +        WRITE_SYSREG(pr->prbar.bits & ~MPU_REGION_RES0, PRBAR_EL2_(num));   \
>> +        WRITE_SYSREG(pr->prlar.bits & ~MPU_REGION_RES0, PRLAR_EL2_(num));   \
>> +        break;                                                              \
>> +    }
>> +
>> +#define GENERATE_READ_PR_REG_CASE(num, pr)                      \
>> +    case num:                                                   \
>> +    {                                                           \
>> +        pr->prbar.bits = READ_SYSREG(PRBAR_EL2_(num));          \
>> +        pr->prlar.bits = READ_SYSREG(PRLAR_EL2_(num));          \
>> +        break;                                                  \
>> +    }
>> +
>> +/*
>> + * Armv8-R supports direct access and indirect access to the MPU regions through
>> + * registers:
>> + *  - indirect access involves changing the MPU region selector, issuing an isb
>> + *    barrier and accessing the selected region through specific registers
>> + *  - direct access involves accessing specific registers that point to
>> + *    specific MPU regions, without changing the selector, avoiding the use of
>> + *    a barrier.
>> + * For Arm64 the PR{B,L}AR_ELx (for n=0) and PR{B,L}AR_ELx (for n=1..15) are
>> + * used for the direct access to the regions selected by
>> + * PRSELR_EL2.REGION<7:4>:n, so 16 regions can be directly accessed when the
>> + * selector is a multiple of 16, giving access to all the supported memory
>> + * regions.
>> + */
>> +static void prepare_selector(uint8_t *sel)
>> +{
>> +    uint8_t cur_sel = *sel;
>> +
>> +    /*
>> +     * {read,write}_protection_region works using the direct access to the 0..15
>> +     * regions, so in order to save the isb() overhead, change the PRSELR_EL2
>> +     * only when needed, so when the upper 4 bits of the selector will change.
>> +     */
>> +    cur_sel &= 0xF0U;
>> +    if ( READ_SYSREG(PRSELR_EL2) != cur_sel )
>> +    {
>> +        WRITE_SYSREG(cur_sel, PRSELR_EL2);
>> +        isb();
>> +    }
>> +    *sel = *sel & 0xFU;
> This one is different in the original file (*sel &= 0xFU;)
Agree with all of the suggested changes.
>
> The rest looks good to me!
> With the above fixed:
>
> Reviewed-by: Luca Fancellu 

- Ayan



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 17:06:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 17:06:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017516.1394506 (Exim 4.92)
	(envelope-from )
	id 1uRDHn-00043o-UK; Mon, 16 Jun 2025 17:06:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017516.1394506; Mon, 16 Jun 2025 17:06: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 1uRDHn-00043h-RV; Mon, 16 Jun 2025 17:06:19 +0000
Received: by outflank-mailman (input) for mailman id 1017516;
 Mon, 16 Jun 2025 17:06: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 1uRDHm-00043X-T1
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 17:06:18 +0000
Received: from NAM02-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam02on20608.outbound.protection.outlook.com
 [2a01:111:f403:2405::608])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3707732f-4ad4-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 19:06:17 +0200 (CEST)
Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
 by SJ0PR12MB6808.namprd12.prod.outlook.com (2603:10b6:a03:47a::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.41; Mon, 16 Jun
 2025 17:06:13 +0000
Received: from PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264]) by PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264%2]) with mapi id 15.20.8835.027; Mon, 16 Jun 2025
 17:06: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: 3707732f-4ad4-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=rJd9OVQOeZDHdgCpaxH6Gmd81XHpYfO73V/Ug+ODDxApJG4+oWXK+fIYlnkhIjPzJtdZQ+COT8zzgzsXRHv/IBuFuS2hQ1ZWzPvoqiN1co1ZSAmy6TgcSJXGihauzyvjx3btBn8vJECJrklp7fPi6hHCTyTD9QzWa1KWyzWZoF7cWbG2irYuRkQl83TelWn8+ZTy93Ipere/iuQCVCbuWaq3IHmz+6dlbGeraBEH43H85Jk8qJ76lFAfhaE8YDaIkkEXwE6JBt7AKM3wXH21Oms2t+2ry2aGVaDBdSsi40uqarIKP2FdqZxT35pPUTU4E6amJCGewo6MditaZJzKBQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Qh4W5qI+YCSSzs+c8qrJvVQS+T+ygAHQ5/ZlpJFgCmA=;
 b=RJVz+bKizm+PWi87VAHa5vRLZeUo1XE3aJ93iG0SLgWx781EpqPJ9dx9HVSDSU5oWKxeqdG88R2r+kHjBYIIveAFIgBIihIxJV0jpj2Lhhs6rTpgGO21Vzp4B1iP4kvK0sAChIuAxrK2tg4BCtLOuI4xP+v7VmXbdYCj8IezBeDcGDAWGRrOf9/NiJEanXLSUKHhqbIHks8vtuixUNV60SGubtaiXDRQLcE4fMu9D8408xbS0V/aCc22Z4kq7JhMVFn6hjyn5HEEJZDo5qLail91SSrVzlmLl3/zi7Mb4Q8oJl0apGnsnqd5F/iISfcRxaVLnxT0s+KICHFKARR0YA==
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=Qh4W5qI+YCSSzs+c8qrJvVQS+T+ygAHQ5/ZlpJFgCmA=;
 b=alw82FhneLz+miLFVVK5AQwlgj2KzAb+tzpc2+pgagJ/nUKAZDJar3FIJMgRkuL11d8N0Aq98Rnjh2brkYtFaYRPlun5uXyzIUHEL1oqOVW3+b2brggweNVYO+1OoAixo804fP8wEvlHIiFjHpDb6yRGePwJemwH14XIYxSIB4g=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Mon, 16 Jun 2025 18:06:08 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 5/6] arm/mpu: Define arm32 system registers
Content-Language: en-GB
To: Hari Limaye ,
 Ayan Kumar Halder 
Cc: xen-devel@lists.xenproject.org,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: <20250611143544.3453532-1-ayan.kumar.halder@amd.com>
 <20250611143544.3453532-6-ayan.kumar.halder@amd.com>
 
From: Ayan Kumar Halder 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: AM6P191CA0060.EURP191.PROD.OUTLOOK.COM
 (2603:10a6:209:7f::37) To PH8PR12MB7326.namprd12.prod.outlook.com
 (2603:10b6:510:216::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|SJ0PR12MB6808:EE_
X-MS-Office365-Filtering-Correlation-Id: 85a3e589-580a-4158-00dd-08ddacf818d7
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?U3lNUUZMRWpiajhCMlNXeDVxR3BJMWV0SThtQklRY3BsMnlDbVpQS3AyN011?=
 =?utf-8?B?N2QwL2hjOGREbW1STkgvd24rZ3IyUExZUmpYZ09CNVJwcXNQc1IzMVdKZzQx?=
 =?utf-8?B?WjMzOUxDTEpTeXp0V0c0RXQydTNKRG1relRkMWd3MzBvWDRpYVI4TGlqaitH?=
 =?utf-8?B?WGVXTWZPenAvU2wrMFNGajBUZkFBNTlNQlNwU3E3blh3QjRyc2RUb0I2UWVD?=
 =?utf-8?B?WGt0Y29Ja2ZpdUJld29jOVBOdFRHaklJSjhOOXhUTUFkOUcrM3Y0NXY5azJO?=
 =?utf-8?B?ZWErbG1ScEw2SkRhbGZSNFZlYVVSOTV3NThhRVpMQSthYVFIdy9aelk5RS9S?=
 =?utf-8?B?bkhqRnE4eUduWGQwOVpPOFdydk4zVmpLMTdYV1NSNjZMR2Urc3lScE9lZ3dE?=
 =?utf-8?B?YWRob2QzNnpBSGxrQ2dpYm5hK0F6RFJaNDZzUmFNWmI5N2Y5SGRjOEphMTZR?=
 =?utf-8?B?Q3FuK1JkWU5VM1ovZWE3Kzg4THNpVU5zQkhZSmlicktwM25RdHZMNzAxT1lN?=
 =?utf-8?B?ZlZBNGpHSFRoMWNzSHBXTjNCNWNic0FWWUlENExESS83NXN4TU9SY2xSSndB?=
 =?utf-8?B?WXdrclhUTGVvd3pCUHh5eUdHemFXaVFCUE9ERkRDNEN5R3BwSHV2QnExV1Y1?=
 =?utf-8?B?OUhtQmt2SnFNZ2RaNkR4UzhSWEx6Tm5pYS9aR1o5NHNyWWREc0t2d2J0bGo5?=
 =?utf-8?B?bFRDeWVDcVEzMUVaaExWRURpZUxxb0FZeCtJSTJNd0IzVGJuUHNZbnZWRENv?=
 =?utf-8?B?dXVtMEI0eFp3Vm1VUXNKV2VaeUkzTkFONE5EK25oZE5xcDhoSHExK1BselpR?=
 =?utf-8?B?UFlRUHdVZFhxeVYwQ3JMcXJpWTZ3dEo5ZEY5SlRKQzEvMGFucG9Jb050MFFI?=
 =?utf-8?B?VjNabG84L0h4cGh0ZFJkQmRSV3VRTDVFMHhJM2hqUjBwVlhmTmpPQnFDNDU4?=
 =?utf-8?B?RTdFenFyaWs5aURHU2lYQkJlNTB6elJ2UDJyMURsSmkrMVhEVlFLTk1adFhs?=
 =?utf-8?B?V29wWW1GZDh5RDVETkREOFhjNlRsUTJCWmQzQVAyUVFnUFd3Mnp3OVIrbGlN?=
 =?utf-8?B?ZnRLYTJITDdOUGttelNYV016TGZOYzV5V0NOZXgyYnprR1cwTHZ0cEhhUXpS?=
 =?utf-8?B?L1RqQ243cnZPUS8xcnBZU1k3UGlYY1BndU1GLzJteHhLTkxIdjEyZURxb29q?=
 =?utf-8?B?NVBrbUJ6WG5iOWlhKytzSU10SVF4L0ZNRXVSTlpzVmNSRytlREhEd2IyVDBT?=
 =?utf-8?B?aU1LQXV6QXhKYS9MbVF5dGJ5emtLQ3FiWVhXTzNlV2xtazhSemhFRDZ2b1pZ?=
 =?utf-8?B?RVo0NEQ3RkZIdS9OUEdrNkw0TGQvWit1SW5kdlVWenZMcHF1czlhRVFsYjJC?=
 =?utf-8?B?QzJyb3lPT3FKV3RqaC9pdXBvVmgwdThLNkNHSk9KNUdicW9rQzdtVVpXYUtx?=
 =?utf-8?B?dFdZbE44QW96MHl0UXBpL2g0QlhjR2FRM3JRcVdmTS9yd2tGeThrUkRySlh3?=
 =?utf-8?B?ZENKYmhNTkZ3ZFVOSXprNnU2S21OMkY3K2pHRGtnNTFQV0tSN2FMeEJCRVgv?=
 =?utf-8?B?aFdVdVN1d2FGMW9paVhKMTVQU0IwVFpsK08zSDhwbEpGU3FTVHZZN29XK20x?=
 =?utf-8?B?alNCa01xYkQ0bFY5MnRVaXFqaXRWWXkrbGU0VXppZTdVekRrY2tsNFZlWk9R?=
 =?utf-8?B?ejltL0Q3QVRjMmMxcWpSSWF3bU1iUjVlNm1GQThXbzQ1emRuM1dGSy9JU054?=
 =?utf-8?B?TkNiS2haaGhuZzRKZ2pFR3ZuKzhoRFMyOERxOHBERGZPekVGb3B5WStWdVMv?=
 =?utf-8?B?N2wzUWhOelE0YUZ5a2FGRGxsemNyemtxTmRDYlpaS1hSM0pUcTg3RHI3dGdX?=
 =?utf-8?B?bzQ5dTJ5VUNIUmVGbmxBM002RHRYN2tkU2lxU0sxRzlIT2Ntcjl4cWFhOUhE?=
 =?utf-8?Q?7dE4E99BRbQ=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)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?MWVWaTZJeHl1ZXZ0SG95NXlUdVBtQzBwZWJlZVVLWU5xSVBBNzhJZE5HVnFB?=
 =?utf-8?B?SVNnaVY3dm9CWGYwTDl1dUhBdUlXOEppVVZuV0pDeldlTXhhMEhXT2MwZFdY?=
 =?utf-8?B?NFMvMUhPTmNCWnVTSFN5UkJQV2xvQVV4dk9DNk55L2xLV2M1LzlPWnREaUtI?=
 =?utf-8?B?YVh5RkhVVWpWT01KZ1kzaXA4dHBoTG1tMGEyVjFPcDQrZlViNG45ZHdVc0xs?=
 =?utf-8?B?VlZEMndpNXBLdlZPRXVjdDhaZTF6QVYxSFlPVHB3U2ZQVFlDR2VQRGw1WGRW?=
 =?utf-8?B?ZmxCVHdiZzBvUlk3ZUl3dUhxQkV3WEFNQlVkOXhXS2Q2YUdOdGsra01pV1V6?=
 =?utf-8?B?bE5lcnZHTTlERG4rV2R0Tm16eGlBdnMxNXdBeXF3REZ4WkNsNnhyaGNrcVZP?=
 =?utf-8?B?NHNSTG1GQ3Z6SEZ2L3h2aDNJU2NUcHAyT01DUEw2c2RNNTZDNmtJZExkaVU4?=
 =?utf-8?B?bWhXdGdSYlA2VGJacUlqVzdCelgweW1obzZBaVNuUE04MjVwcWR5UHNUdnV5?=
 =?utf-8?B?TDBnd3VkUDF0QzNQaUYrcVdVV3pFQkw0aUtlcjJuT1c4S0tRaTQ4QVZWSGYx?=
 =?utf-8?B?dUpwMlZKbWZEQkhJcEtxOFdtYjhMbVNsVFhwVEEvVlpFbjdLTVhTRzlwelJi?=
 =?utf-8?B?TlBqNTVkZEdVb2lTN083ZjJZT0w5TGZJOEZKYUdyK2lDZjl6RW9PeiszZXNZ?=
 =?utf-8?B?ejJndmlScGhNNmdqL3BhaTJLTW5oVGtpamhRLzVkWnRWa3FMT3lBdnNZQUpu?=
 =?utf-8?B?cnc4Rms4UGtBMDlLUVF3blNFUmNxcU1DQTFOeG9aTUplQitlQStYbzNSTmF4?=
 =?utf-8?B?QzZRekhoZW85emtXbDBDMjJUWUNyTENCVHZ4eXBxMkpKKzluZ2p5K3NtRU1k?=
 =?utf-8?B?RVNJU2hZQWtRYTlVN0Q5NFNwd2NPdnFSZU5hSzNxcUdSSHE5T3FZVXhsTUxY?=
 =?utf-8?B?VlRYZlA3Y1ZpVUt2NmtMVFJuZ2ZwYmdCdklPVFZwNWt4UEhaaFcvaHpWcXNX?=
 =?utf-8?B?dlU2YnJWUzBocll1VVA3Z3BOZXpHdjNOK3pRQVd2d1QvWTF5bjNoamxUZU5y?=
 =?utf-8?B?UitqTStVc1l5YzVUZkw3eEF3em9NaDJZQ2xIejhadExWVnZpVU5SMjdDbjcz?=
 =?utf-8?B?N0I5NTVJV1BVZnFUcXJoZzFaQ3FiUjlXUC9WbnNjZmJkZDlRZGtKUjJtMU54?=
 =?utf-8?B?NXRjNFpXVXJhMVZLV0dyVXFMVm9JTDkrUFMvZE9TeTZjVVBYb09oaWFna1R4?=
 =?utf-8?B?VE4wNFNDTlJOUEJOWWphOHlERmJ3aS9HbXBXWndVT0xRREpEbW53ZUVLd0d0?=
 =?utf-8?B?K0ZhYVNYcytxaFkzZzR3cEozZVlIRFFXTll6Z2MrUEZ4anFPYUw1cXQ4Z2Y3?=
 =?utf-8?B?SnloSFZuSmtYTENmMGw3L2Zic0loWElNYnNvNXQ2blNUTmg1RzVoaW5YNlVP?=
 =?utf-8?B?R25Eb2luUTZaN2xVVnE2Z1RURWNxSTBOY0lIcEdWRk9RY2VPVVhVSFI0bFkz?=
 =?utf-8?B?MnB6VVJrM0Ivb2ZUYjdhZC91ZnVEYWZYVllVekhtZ01JQmx6SnFuV0RVUndm?=
 =?utf-8?B?cHdtcHV4cjQ4d3RCYzJiQSs5Ui8wV1lmdTl5VkdaaHZIS1JodmxQaWptTG4z?=
 =?utf-8?B?LytVVGJFNDNKL243VnBCWDFrY3JWbGE3dFZmcHM2M0M5TnU1ZlhWaUQ0Um5Q?=
 =?utf-8?B?QWd6c2swMlViK1duT1loSlNwRCtDc0oxZUJtaWNLTkVMazdSVExwZUk0Nnc2?=
 =?utf-8?B?V0NKb3J2NWwvVDNOV3gvVWM5cWxUUkNIMFFoSjJ5d1dKdFpKVitORWl0NUFv?=
 =?utf-8?B?V2F0UGdmNEh5aWRGSlZ0MVVZd2NlaWNEQTcyb3QzdGY4dWlkWVVnb1NUMmc5?=
 =?utf-8?B?NVY4U3MrRDZSaWIzQ2RsMHNiN05UY2U5ZWFYYWQrTkJEMlRKcHJ0aVBiUGls?=
 =?utf-8?B?YmpnOUtNaG5IUmpWOGJMdzlMM2FyQ3pEZEg1OUVxMWc0WHNKelJ1dnBpNFYx?=
 =?utf-8?B?d3NRUkIwS3FkYk1YanpNUFBLL1FrMStJZ29QaGFqYjdndkZTYXlZajdkdnpT?=
 =?utf-8?B?NDdMTDB4dDhvNzkzdmo4dVN3TEg0WW5NVVRsVE80UXpsclQyaW9YN0d3VDE4?=
 =?utf-8?Q?2MojBw/4IZtAz+LoNK4d6PCsr?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 85a3e589-580a-4158-00dd-08ddacf818d7
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jun 2025 17:06:12.8789
 (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: ded5rseh7oouwBf4lpUa9TNYh9OuzZQ3Ip3YOOEXc/XZVrRSYlC/zbQ6tXXnk4FeA2dQjNwga9wsxticZVQf/g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB6808


On 16/06/2025 11:38, Hari Limaye wrote:
> Hi Ayan,
Hi Hari,
>
> I checked the register definitions for HPR{B,L}AR against the Arm
> Architecture Reference Manual Supplement for the Armv8-R AArch32
> architecture profile (ARM DDI 0568A.c), specifically sections E2.2.3 and
> E2.2.6, and everything looks correct to me.
>
> On Wed, Jun 11, 2025 at 03:35:43PM +0000, Ayan Kumar Halder wrote:
>> Fix the definition for HPRLAR.
>> Define the base/limit address registers to access the first 32 protection
>> regions.
>>
>> Signed-off-by: Ayan Kumar Halder 
>> ---
> Reviewed-by: Hari Limaye 

Thanks and welcome to xen-devel. :)

- Ayan



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 17:23:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 17:23:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017526.1394517 (Exim 4.92)
	(envelope-from )
	id 1uRDYI-00072q-Dq; Mon, 16 Jun 2025 17:23:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017526.1394517; Mon, 16 Jun 2025 17:23: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 1uRDYI-00072j-Az; Mon, 16 Jun 2025 17:23:22 +0000
Received: by outflank-mailman (input) for mailman id 1017526;
 Mon, 16 Jun 2025 17:23: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 1uRDYG-00072d-Vd
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 17:23:21 +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 97b6a797-4ad6-11f0-a309-13f23c93f187;
 Mon, 16 Jun 2025 19:23:17 +0200 (CEST)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3a375e72473so2727228f8f.0
 for ; Mon, 16 Jun 2025 10:23:17 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a568b089d8sm11796159f8f.57.2025.06.16.10.23.16
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 16 Jun 2025 10:23:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 97b6a797-4ad6-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750094597; x=1750699397; 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=1tTYRtnAqp4wvvQwALHvpwDN0tZv49JWHfk+Pwsv8rE=;
        b=aU9sZO888S9P60VHoDPt7VQWRi1Ll7U8ZQPtv2yhWhQIR3qg8lilrgkozacfmScLAz
         Oo2j1VSEe7B/yd9TXwU7VI2LeLRvssubdjGlZH9Re91iRUY1+YIYi2rJeGqx+8NbzI9s
         LKGcGlF6MkJ7oFP2ku+Jw+xithnTwhBF9sjUY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750094597; x=1750699397;
        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=1tTYRtnAqp4wvvQwALHvpwDN0tZv49JWHfk+Pwsv8rE=;
        b=ANsr87nHOrGgZBbAsdRm43aar+njxPHvVlQFUKl9Q1IfwyNVOTOHOPquM9VE2sulGR
         fNrdjvUdbYu/blj9sx6wb+cmWebRea3NsIOBGFqLceWrLY5ZPS0xHp7117eUPjJZZ5fE
         MoYa8QNbFcufOw1IHXNp9sVutrNIINzovsqf8H+i1Rq/h92u5HeOYQosJhSXhSKepNkO
         1caoPTYgYzuxGQCBzZnxVRXVJiqwU0mdggdZ0oq8WmwxiPozyHdECAjf3WLGBR75tTQ4
         W96VRCj6oh5/EfKJGnSEzvTpdMZzSw6sheZfgUGAJdIvBDOyMc1OjL/aYwJhv/CtBVuG
         u3Uw==
X-Gm-Message-State: AOJu0YxVYJrvJWVXjsadSpLu2koOUaH3vAqmFLuLyAMjYrYzt4jXiaGx
	1LR6PetQkBKXk9MbrCPuDV0PPuabHUiX2eZkrGVn3EU4Nl8pm/cjyt7s2vB2dLdzHck=
X-Gm-Gg: ASbGncuqYl923gm0NE5qJWmjdKby94A5Bgq7h48i9/i/Z3enOOcYJ7tB0NCQcqxk+2a
	t8FBZ2TBvYjoYjF6oni3jqk/NzmFqR32Hy6DjYQ5Oh4P1wzsydTFb5A/SUcTEQDsJ9SLaVUROAZ
	jrWL+1SAiz95W2R2LENxwM/pB+COWZGrBrYUY61RwhRT62L8VpSo3gVyLzHMFZJWuyEh1WAPQNG
	PmgjUtBgcmQyU5siHQWBrv8Rzz3PKQbS7Q18KtbbXmaSrUksj3rfBVolQ4shMb1wxrOVm++HCZp
	YZ4IINAv8EOMnCp5qzTc9a1eeadg1PS7MhJrrM7IYMbaRaymarMYB22VMlhPdvLO8qj+OSfQmqt
	ysWgAdclEliJ5Zga/EabGFDAdw6qxug==
X-Google-Smtp-Source: AGHT+IFsVvsCBUebKHfHNpC0O96NEaolrNVy3e1bogKCd9jsSASq9I+jj1dtbJVf2PLT/4axNU4www==
X-Received: by 2002:a5d:5f48:0:b0:3a4:d8b6:ca3f with SMTP id ffacd0b85a97d-3a5723a291dmr7525543f8f.30.1750094597225;
        Mon, 16 Jun 2025 10:23:17 -0700 (PDT)
Date: Mon, 16 Jun 2025 19:23:15 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" ,
	Andrew Cooper ,
	Julien Grall ,
	Stefano Stabellini ,
	Anthony PERARD ,
	Michal Orzel 
Subject: Re: [PATCH] memory: arrange to conserve on DMA reservation
Message-ID: 
References: <6565e881-ec59-4db4-834a-f694bf1b9427@suse.com>
 
 <9b036f26-f275-48d0-9a33-7cef38b29f48@suse.com>
 
 <2969b5d8-5879-4674-8332-046898e17257@suse.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Mon, Jun 16, 2025 at 06:02:07PM +0200, Jan Beulich wrote:
> On 16.06.2025 17:41, Roger Pau Monné wrote:
> > On Mon, Jun 16, 2025 at 05:20:45PM +0200, Jan Beulich wrote:
> >> On 16.06.2025 16:46, Roger Pau Monné wrote:
> >>> One question I have though, on systems with a low amount of memory
> >>> (let's say 8GB), does this lead to an increase in domain construction
> >>> time due to having to fallback to order 0 allocations when running out
> >>> of non-DMA memory?
> >>
> >> It'll likely be slower, yes, but I can't guesstimate by how much.
> > 
> > Should there be some way to control this behavior then?  I'm mostly
> > thinking about client systems like Qubes where memory is likely
> > limited, and the extra slowness to create VMs could become
> > noticeable?
> 
> What kind of control would you be thinking of here? Yet another command
> line option?

I guess that would be enough.  I think we need a way to resort to the
previous behavior if required, and likely a CHANGELOG entry to notice
the change.

Overall, would it be possible to only include the flag if we know
there's non-DMA memory available to allocate?  Otherwise we are
crippling allocation performance when there's only DMA memory left.

That also raises the question whether it's an acceptable trade-off to
possibly shatter p2m super pages (that could be used if allocating
from the DMA pool) at the expense of not allocating from the DMA pool
until there's non-DMA memory left.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 23:39:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 23:39:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017560.1394527 (Exim 4.92)
	(envelope-from )
	id 1uRJQT-0006KS-Ar; Mon, 16 Jun 2025 23:39:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017560.1394527; Mon, 16 Jun 2025 23:39:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRJQT-0006KK-7c; Mon, 16 Jun 2025 23:39:41 +0000
Received: by outflank-mailman (input) for mailman id 1017560;
 Mon, 16 Jun 2025 23:39: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 1uRJQR-0006KE-Ol
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 23:39:39 +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 290ee1ff-4b0b-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 01:39:36 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 31EEE5C561D;
 Mon, 16 Jun 2025 23:37:18 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 02BB2C4CEEA;
 Mon, 16 Jun 2025 23:39: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: 290ee1ff-4b0b-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750117174;
	bh=qoNjzUrsbbLZ2YwToDWf9In6EJADVRiGdufE9CU/CmY=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=d/luVqJfvJnkDSKxdua4RlMmp2iTUW6SCGDIo/VuBQxj/nmpLv0IrkwhYdpYyNEjb
	 VhvnI3w+/vDIuX7SdoEqkykQCbZp9qaWkzC7ygb/to2YMMOG87O5/qQ95TizfdhlBU
	 wWiY+3g2gc7oXEbVE1togH7c7GAhU4abEUsIDUEOudXyMJQF7SPv5/Yl31SxUUB3yU
	 hY4bYGrt/H8A4Ufw9wENjQZOzabHNWEmcHefBGA0zuQXrYwCKUbLZPIN34YcCaYcfU
	 2XTiHymrGAxIOx90mJxyi4ML0iTCmuuXA9c5xeQpjWV4wB3Px0FyQ7Ifo8/A+idkHk
	 ipderh2NHC+nQ==
Date: Mon, 16 Jun 2025 16:39:28 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: Julien Grall , xen-devel@lists.xenproject.org, 
    Jan Beulich , Andrew Cooper , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Anthony PERARD , 
    Michal Orzel , 
    Stefano Stabellini , 
    Bertrand Marquis , 
    "Daniel P. Smith" 
Subject: Re: [PATCH v3 14/14] kconfig: Allow x86 to pick
 CONFIG_DOM0LESS_BOOT
In-Reply-To: 
Message-ID: 
References: <20250613151612.754222-1-agarciav@amd.com> <20250613151612.754222-15-agarciav@amd.com> <2a54e49b-c1ad-4654-9291-4373e92580ff@xen.org> 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 16 Jun 2025, Alejandro Vallejo wrote:
> On Mon Jun 16, 2025 at 10:00 AM CEST, Julien Grall wrote:
> > Hi,
> >
> > On 13/06/2025 16:13, Alejandro Vallejo wrote:
> >> Without picking CONFIG_HAS_DEVICE_TREE.
> >> 
> >> In order to do that. Allow CONFIG_DOM0LESS_BOOT to enable a subset
> >> of the common/device-tree/ directory. 
> >  > x86 doesn't want dom0less-build.c,> as that's tightly integrated 
> > still to the ARM way of building domains.
> >
> > I don't understand this argument. dom0less-build.c was moved to common 
> > and it will soon be used by RISC-V. This raises the question what's so 
> > special with x86?
> 
> That's 2 separate matters:
> 
>   1. dom0less-build.c not being compiled in.
>   2. CONFIG_DOM0LESS_BOOT enabling use of DT code without CONFIG_HAS_DEVICE_TREE.
> 
> (1) is a matter of not wanting to boil the ocean upfront. The way x86 and
> everyone else build domains is just different and duplicated in non-trivially
> consolidable ways. The goal here is to enable the domain builders in any arch
> to use the same backbone. I don't want to go the extra mile just yet to unify
> domain construction (though in time I will want to).
> 
> (2) has to do with compiling OUT things I really cannot have around. Anything
> involving devices described in a DT must not exist on x86, because it has no
> concept of a "struct device".
> 
> My intent is/was to repurpose CONFIG_HAS_DEVICE_TREE to mean "this hypervisor
> goes on a platform that gives a platform-describing DT". On x86 that's given by
> DSDT/SSDTs with ACPI.

Alejandro is suggesting two levels of Device Tree support:

- full DT support, including device discovery via DT
- minimal DT support, for the dom0less/hyperlaunch configuration

Reading this series, it looks reasonable to me, at least as a stepping
stone. I think it is expected that the kind of DT support needed by an
architecture like ARM or RISC-V is different from the one needed by an
architecture like x86. Of course we might be able to align things even
more in the future but as of today I think it is reasonable to
distinguish between the two.

That said, we might want to consider renaming or changing the kconfig
options. For instance:

- CONFIG_HAS_DEVICE_TREE -> enable minimal DT support
- CONFIG_DT_DEVICE_DISCOVERY -> device discovery via DT

In this model, all architectures would have CONFIG_HAS_DEVICE_TREE, but
only ARM and RISC-V would have CONFIG_DT_DEVICE_DISCOVERY.


> > Note I don't particularly care if you don't want to use it on x86. 
> > However, the argument provided is lacking some details... This will be 
> > useful in the future if someone thinks about consolidating the two.
> 
> I very definitely will want it all unified, but I'm working one elephant at
> a time.

+1


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 23:42:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 23:42:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017567.1394537 (Exim 4.92)
	(envelope-from )
	id 1uRJSo-0007tl-LB; Mon, 16 Jun 2025 23:42:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017567.1394537; Mon, 16 Jun 2025 23:42: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 1uRJSo-0007te-IK; Mon, 16 Jun 2025 23:42:06 +0000
Received: by outflank-mailman (input) for mailman id 1017567;
 Mon, 16 Jun 2025 23:42: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 1uRJSn-0007tT-1q
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 23:42:05 +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 80d2f218-4b0b-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 01:42:03 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 4AE645C1104;
 Mon, 16 Jun 2025 23:39:45 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 19583C4CEEA;
 Mon, 16 Jun 2025 23:41: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: 80d2f218-4b0b-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750117321;
	bh=xveEK3bSBxEPMMbaUq2f38hdtN983Wtdzbqu1rSdp2Q=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=H67XK6adOYyjdMGJ5dCNtg2Zhbn4pVACoeo0mq+AOWyOX2d7ZMIbDf81cKTl6nlX9
	 Z59dev91qsDdP5ehCbHtRb8AsYiLZY6Yr9ffgSTknNbhKEGg7nryIogrkActP4uL5I
	 AEN2udStmTBEnEs20o+i7CNZQ0gt2eDMm8J3smscl3Xg3o4j5G+cAmytd4qYHhUE3B
	 G7HKcAh+lIL/v2mRdeA7JZwEUDezDTLp7RtmfkoVZydVyIkUdGrwWvUWZOCu/tqULK
	 8ny57/gL0Z5nEdsdSMa+VS3ykJRspdNMycnSmpIdKE+85cctAWu9qNhDg67N5VSZDE
	 P7vAKZ7hMAmxg==
Date: Mon, 16 Jun 2025 16:41:58 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: Jan Beulich , Andrew Cooper , 
    Anthony PERARD , 
    Michal Orzel , Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini , 
    Bertrand Marquis , 
    "Daniel P. Smith" , 
    xen-devel@lists.xenproject.org, 
    Xen-devel 
Subject: Re: [PATCH v3 13/14] xen/dt: Allow CONFIG_DOM0LESS_BOOT to include
 device-tree/
In-Reply-To: 
Message-ID: 
References: <20250613151612.754222-1-agarciav@amd.com> <20250613151612.754222-14-agarciav@amd.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 Jun 2025, Alejandro Vallejo wrote:
> On Mon Jun 16, 2025 at 8:55 AM CEST, Jan Beulich wrote:
> > On 13.06.2025 17:13, Alejandro Vallejo wrote:
> >> --- a/xen/common/Kconfig
> >> +++ b/xen/common/Kconfig
> >> @@ -14,6 +14,7 @@ config CORE_PARKING
> >>  
> >>  config DOM0LESS_BOOT
> >>  	bool "Dom0less boot support" if EXPERT
> >> +	select LIBFDT
> >>  	depends on HAS_DOM0LESS && HAS_DEVICE_TREE && DOMAIN_BUILD_HELPERS
> >>  	default y
> >>  	help
> >
> > Nit: Imo it is good practice to have the select-s after the "depends on",
> > and perhaps also after any default(s).
> >
> >> --- a/xen/common/Makefile
> >> +++ b/xen/common/Makefile
> >> @@ -8,7 +8,7 @@ obj-y += cpu.o
> >>  obj-$(CONFIG_DEBUG_TRACE) += debugtrace.o
> >>  obj-$(CONFIG_HAS_DEVICE_TREE) += device.o
> >>  obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) += device.o
> >> -obj-$(CONFIG_HAS_DEVICE_TREE) += device-tree/
> >> +obj-$(firstword $(CONFIG_HAS_DEVICE_TREE) $(CONFIG_DOM0LESS_BOOT)) += device-tree/
> >
> > Why not
> >
> > obj-$(CONFIG_HAS_DEVICE_TREE) += device-tree/
> > obj-$(CONFIG_DOM0LESS_BOOT) += device-tree/
> >
> > as we have it in a few similar situations?
> 
> Because I wasn't sure the build system would swallow it. If you claim it does, sure.
> I think the "firstword" version is clearer, but I don't mind.
> 
> >
> > And why would the duplication be needed in the first place? Shouldn't
> > DOM0LESS_BOOT imply HAS_DEVICE_TREE? Sadly the description once again
> > only says what is intended, but not why. And the dependency is actually
> > visible in patch context above, in the hunk altering xen/common/Kconfig.
> >
> > Jan
> 
> After this series the idea is that CONFIG_HAS_DEVICE_TREE means a platform
> in which platform resources (memory, devices, etc) are described on DTs.
> 
> While x86 ends up understanding DTs to the extent that it's able to parse
> and extract "xen,domain" nodes, it's not capable of much more than that. The
> distinction is important because making x86 understand general DT (devices, IRQs
> and memory) would be far too invasive and not very helpful.
> 
> I can rename it to CONFIG_HAS_PLATFORM_DT or CONFIG_HAS_DT_DEVICES, or anything
> else if you (or anyone else) have any ideas.
> 
> TL;DR: It's to still be able to compile-out the bits x86 cannot use in the DT
> machinery.

Yeah, as it looks like not introducing HAS_DEVICE_TREE on x86 is causing
confusion, maybe it is better to add HAS_DEVICE_TREE to all arches and
use a different kconfig to say "this architecture supports device
discovery via DT", such as CONFIG_HAS_DT_DEVICES or
CONFIG_DT_DEVICE_DISCOVERY.



From xen-devel-bounces@lists.xenproject.org Mon Jun 16 23:45:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 23:45:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017575.1394547 (Exim 4.92)
	(envelope-from )
	id 1uRJWH-0008T7-2d; Mon, 16 Jun 2025 23:45:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017575.1394547; Mon, 16 Jun 2025 23: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 1uRJWH-0008T0-01; Mon, 16 Jun 2025 23:45:41 +0000
Received: by outflank-mailman (input) for mailman id 1017575;
 Mon, 16 Jun 2025 23:45: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 1uRJWF-0008Si-21
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 23:45:39 +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 009febd6-4b0c-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 01:45:38 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 1D9405C59CE;
 Mon, 16 Jun 2025 23:43:20 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id B91BAC4CEEA;
 Mon, 16 Jun 2025 23: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: 009febd6-4b0c-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750117536;
	bh=nvHZW6lSsrrSxdMrAt8qSEvrG6flsT2JbPu7qbHA84E=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=kLiVQlJ3j1n/apla7CA52s03MEWVXNq67ZzUsgTBXt5NgD7bMDPJM5CJFR8z9GoNt
	 xTzOigUnmHwlhQFf0oMTFzUqQ1csnm3N9dQCKkLvw8y+eyYnk2Hbpk5HTtJB4qdDO/
	 /dwE6HPuCqdn7BG/5uqV43mie8oU1JPRpwVIP/BPQc2kohCoYBW/+6y+f7+kvcJuqo
	 rGthT9A7reyVonX1gGfgWUJXoA5I4uXJ1Tr8K3vVF3Jcu3AxG41AnbTnyuKmm3fNzg
	 M2P0zRWYlNW+aXKInB9EM6Nlnq2f850aFvcp2f3Cs+fOUioP9Bfwg2Euw+2/4KjPYx
	 JVnjLEdcbhH1Q==
Date: Mon, 16 Jun 2025 16:45:33 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: rosbrookn@gmail.com
cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org, julien@xen.org, 
    bertrand.marquis@arm.com, michal.orzel@amd.com, Volodymyr_Babchuk@epam.com, 
    andrew.cooper3@citrix.com, anthony.perard@vates.tech, rosbrookn@gmail.com, 
    gwd@xenproject.org, edgar.iglesias@amd.com, edgar.iglesias@gmail.com
Subject: Golang review, was: [PATCH v5 5/5] tools/golang: Regenerate bindings
 for trap_unmapped_accesses
In-Reply-To: <20250616155306.405257-3-edgar.iglesias@gmail.com>
Message-ID: 
References: <20250616153826.404927-1-edgar.iglesias@gmail.com> <20250616155306.405257-3-edgar.iglesias@gmail.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

Hi Nick,

It would be good for you to review this patch.

If you are unable to do so, please let us know if you have any
objections to us committing this patch without your ack.

Cheers,

Stefano


On Mon, 16 Jun 2025, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias" 
> 
> Signed-off-by: Edgar E. Iglesias 
> ---
>  tools/golang/xenlight/helpers.gen.go | 6 ++++++
>  tools/golang/xenlight/types.gen.go   | 1 +
>  2 files changed, 7 insertions(+)
> 
> diff --git a/tools/golang/xenlight/helpers.gen.go b/tools/golang/xenlight/helpers.gen.go
> index 90846ea8e8..191be87297 100644
> --- a/tools/golang/xenlight/helpers.gen.go
> +++ b/tools/golang/xenlight/helpers.gen.go
> @@ -1170,6 +1170,9 @@ x.Altp2M = Altp2MMode(xc.altp2m)
>  x.VmtraceBufKb = int(xc.vmtrace_buf_kb)
>  if err := x.Vpmu.fromC(&xc.vpmu);err != nil {
>  return fmt.Errorf("converting field Vpmu: %v", err)
> +}
> +if err := x.TrapUnmappedAccesses.fromC(&xc.trap_unmapped_accesses);err != nil {
> +return fmt.Errorf("converting field TrapUnmappedAccesses: %v", err)
>  }
>  
>   return nil}
> @@ -1695,6 +1698,9 @@ xc.altp2m = C.libxl_altp2m_mode(x.Altp2M)
>  xc.vmtrace_buf_kb = C.int(x.VmtraceBufKb)
>  if err := x.Vpmu.toC(&xc.vpmu); err != nil {
>  return fmt.Errorf("converting field Vpmu: %v", err)
> +}
> +if err := x.TrapUnmappedAccesses.toC(&xc.trap_unmapped_accesses); err != nil {
> +return fmt.Errorf("converting field TrapUnmappedAccesses: %v", err)
>  }
>  
>   return nil
> diff --git a/tools/golang/xenlight/types.gen.go b/tools/golang/xenlight/types.gen.go
> index e7667f1ce3..656933c6c9 100644
> --- a/tools/golang/xenlight/types.gen.go
> +++ b/tools/golang/xenlight/types.gen.go
> @@ -606,6 +606,7 @@ MsrRelaxed Defbool
>  Altp2M Altp2MMode
>  VmtraceBufKb int
>  Vpmu Defbool
> +TrapUnmappedAccesses Defbool
>  }
>  
>  type DomainBuildInfoTypeUnion interface {
> -- 
> 2.43.0
> 


From xen-devel-bounces@lists.xenproject.org Mon Jun 16 23:56:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jun 2025 23:56:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017584.1394556 (Exim 4.92)
	(envelope-from )
	id 1uRJh3-0001q6-VE; Mon, 16 Jun 2025 23:56:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017584.1394556; Mon, 16 Jun 2025 23:56:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRJh3-0001pz-Sg; Mon, 16 Jun 2025 23:56:49 +0000
Received: by outflank-mailman (input) for mailman id 1017584;
 Mon, 16 Jun 2025 23:56: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 1uRJh1-0001pt-PS
 for xen-devel@lists.xenproject.org; Mon, 16 Jun 2025 23:56:47 +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 8efbd319-4b0d-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 01:56:46 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 33DD35C5B13;
 Mon, 16 Jun 2025 23:54:28 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id B856FC4CEEA;
 Mon, 16 Jun 2025 23:56:42 +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: 8efbd319-4b0d-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750118204;
	bh=WNc/y16cQBeEyfR17QwFLGF9C5XEiwh1M9yAt5oivAg=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=Uo6MZ/w9Nc8YpiS6NxGElMnUHKcOy476U6R3qpJZNJcjD9ALG6xDnQW5tTyBZqjbh
	 5zbkoKz24yiM+wgVBAExYX1VIpq282lTl46QMFR9dWIHI48sVLL/QbKhUjzb78eqRJ
	 DVGikApUyhzj78zccs9GOt+tJicZCUfszVe2Z9+WwoIdVCLugy7ZaySBNGbPj38xsN
	 5RoBvOQ8oHlO8/AqMNc7KhLWZLqUetDLIsGD3Tts38laSuIsV1DuqRSSQDilwoiBBr
	 chquD7hPWf9FK3emsdUaG/KplDHyPeI2QxJJrp9B+MGfD1CMvQGeVgRfu+U8txkdTw
	 IIp9UTQGeqHqg==
Date: Mon, 16 Jun 2025 16:56:41 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Stewart Hildebrand , 
    Rahul Singh , 
    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
Subject: Re: [PATCH v8] xen/arm: pci: introduce PCI_PASSTHROUGH Kconfig
 option
In-Reply-To: 
Message-ID: 
References: <20250613154847.317979-1-stewart.hildebrand@amd.com> <3ecf10e5-5df7-4348-85a1-b8eecb940bf8@suse.com> <2e0627fa-35b8-4d3d-a3bc-338f9f7ed61b@amd.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 Jun 2025, Jan Beulich wrote:
> On 16.06.2025 12:37, Stewart Hildebrand wrote:
> > On 6/16/25 02:42, Jan Beulich wrote:
> >> On 13.06.2025 17:17, Stewart Hildebrand wrote:
> >>> --- a/xen/arch/arm/Kconfig
> >>> +++ b/xen/arch/arm/Kconfig
> >>> @@ -8,6 +8,8 @@ config ARM_64
> >>>  	depends on !ARM_32
> >>>  	select 64BIT
> >>>  	select HAS_FAST_MULTIPLY
> >>> +	select HAS_VPCI_GUEST_SUPPORT if PCI_PASSTHROUGH
> >>> +	select HAS_PASSTHROUGH if PCI_PASSTHROUGH
> >>
> >> Seeing this, I like this as little as I liked ...
> >>
> >>> @@ -258,6 +260,12 @@ config PARTIAL_EMULATION
> >>>  
> >>>  source "arch/arm/firmware/Kconfig"
> >>>  
> >>> +config PCI_PASSTHROUGH
> >>> +	bool "PCI passthrough" if EXPERT
> >>> +	depends on ARM_64
> >>
> >> ... the form with the select-s put here. I'll (obviously) leave it to the
> >> Arm maintainers to judge, but my recommendation would be to simply drop
> >> this patch. As per the description it's merely "make it easier ...",
> >> which imo doesn't warrant such an abuse of HAS_*.
> > 
> > "easier" was a poor choice of word. "possible" is more accurate. This
> > patch addresses a real issue: currently the PCI and vPCI bits can't be
> > built for Arm, allowing build issues to go unnoticed. E.g. see
> > 4ce671963eb1 ("xen/arm: fix build with HAS_PCI").
> 
> Which gets us back to the question of whether to use "depends on
> HAS_PASSTHROUGH" (I think yes then) and where to put the remaining select
> (might then better move back to the new option).

In my opinion, HAS_ options should not be user-configurable but rather
properties of the architecture. Therefore, I would add HAS_PASSTHROUGH
to ARM_64 unconditionally. Then I would make PASSTHROUGH
user-configurable, but dependent on HAS_PASSTHROUGH.

In the rest of the code, we would update the checks to be based on
PASSTHROUGH instead of HAS_PASSTHROUGH.

That said, this patch is simpler while my suggestion is more invasive.
Also this patch is at v8 and we shouldn't keep increasing the scope of
the work for contributors. Finally, I am not certain all maintainers
would agree with my view I just outlined.

So based on the above, and based on the fact that we certainly need this
patch or something like it:

Acked-by: Stefano Stabellini 



From xen-devel-bounces@lists.xenproject.org Tue Jun 17 00:11:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 00:11:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017591.1394566 (Exim 4.92)
	(envelope-from )
	id 1uRJv2-0005Om-Gw; Tue, 17 Jun 2025 00:11:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017591.1394566; Tue, 17 Jun 2025 00: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 1uRJv2-0005Of-Dz; Tue, 17 Jun 2025 00:11:16 +0000
Received: by outflank-mailman (input) for mailman id 1017591;
 Tue, 17 Jun 2025 00:11: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 1uRJv0-0005OX-Oy
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 00:11:14 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8e4a9f29-4b0f-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 02:11:04 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 89583449B8;
 Tue, 17 Jun 2025 00:11:02 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1DFCCC4CEF5;
 Tue, 17 Jun 2025 00:11:00 +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: 8e4a9f29-4b0f-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750119062;
	bh=3u74A8COiJSaIMpap2C2Bqi8TnCI7uNJXIIzENszSyE=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=Wf7FJXu4dSz+pNFuYjgUnU4EQY72h3G86S/1nypz5+nbkJqzyPiQDJv/lj18kwm87
	 kflGVIa6+kUrd4RKHhGz/6O1ZaWx35T6LGyISnWan0ZuHWEv26s+wSrj0LIOBeIWLt
	 UIWdwnsFhn0N8329vLscYR9C2zngFc9Wpfp2Q+HrwT5pI+NAgG3QTczPod/Q6WrHT4
	 kT4M7gxMGk+dGo+XlJxi6tsixiLCyj3zBZKdHXu2BCgXgt27qU4NVd/jzGheMhtI9A
	 bq0WqQ95pOkFopoJWXTx33pM7yyxB/wEdovKP1fr9XeAMemujMCSukdsZTkbsm4CW7
	 hvQDHFePXLm+Q==
Date: Mon, 16 Jun 2025 17:10:59 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Stefano Stabellini , 
    Jason Andryuk , 
    Andrew Cooper , 
    Anthony PERARD , 
    Michal Orzel , Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    "Daniel P. Smith" , 
    xen-devel@lists.xenproject.org
Subject: Re: [PATCH 4/4] xsm/dummy: Allow hwdom SYSCTL_readconsole/physinfo
In-Reply-To: 
Message-ID: 
References: <20250610225737.469690-1-jason.andryuk@amd.com> <20250610225737.469690-5-jason.andryuk@amd.com> <5f6d43da-2600-4c1c-9bcb-f13e8fce921e@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 Jun 2025, Jan Beulich wrote:
> On 14.06.2025 00:51, Stefano Stabellini wrote:
> > On Wed, 11 Jun 2025, Jason Andryuk wrote:
> >> On 2025-06-11 09:27, Jan Beulich wrote:
> >>> On 11.06.2025 00:57, Jason Andryuk wrote:
> >>>> Allow the hwdom to access the console, and to access physical
> >>>> information about the system.
> >>>>
> >>>> xenconsoled can read Xen's dmesg.  If it's in hwdom, then that
> >>>> permission would be required.
> >>>
> >>> Why would xenconsoled run in the hardware domain? It's purely a software
> >>> construct, isn't it? As a daemon, putting it in the control domain may
> >>> make sense. Otherwise it probably ought to go in a service domain.
> >>
> >> My approach has been to transform dom0 into the hardware domain and add a new
> >> control domain.  xenconsoled was left running in the hardware domain.
> > 
> > I think we should keep xenconsoled in the hardware domain because the
> > control domain should be just optional. (However, one could say that with
> > Denis' recent changes xenconsoled is also optional because one can use
> > console hypercalls or emulators (PL011, NS16550) for all DomUs.)
> > 
> > 
> > 
> >> I suppose it could move.  Maybe that would be fine?  I haven't tried. The
> >> Hyperlaunch code populates the console grants to point at the hardware domain,
> >> and I just followed that.
> >>
> >> One aspect of why I left most things running in the Hardware domain was to not
> >> run things in the Control domain.  If Control is the highest privileged
> >> entity, we'd rather run software in lower privileged places. Especially
> >> something like xenconsoled which is receiving data from the domUs.
> > 
> > Yes, I agree with Jason. It is a bad idea to run xenconsoled in the
> > Control Domain because the Control Domain is meant to be safe from
> > interference. We want to keep the number of potential vehicles for
> > interference down to a minimum and shared memory between Control Domain
> > and DomUs is certainly a vehicle for interference.
> 
> As much as it is when xenconsoled runs in the hardware domain? Especially
> if the hardware domain is also running e.g. PV backends or qemu instances?

It looks like you are thinking of the possible
interference from the Hardware Domain to the Control Domain via
xenconsoled, correct?

If that is the case, good thinking. I can see that you have really
understood the essence of the problem we are trying to solve.

That is not an issue because the Control Domain shouldn't use PV
console. Instead, it should use the console hypercall, or the
PL011/NS16550 emulators in Xen.


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 00:21:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 00:21:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017602.1394577 (Exim 4.92)
	(envelope-from )
	id 1uRK50-0007Bq-Ht; Tue, 17 Jun 2025 00:21:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017602.1394577; Tue, 17 Jun 2025 00:21: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 1uRK50-0007Bj-F7; Tue, 17 Jun 2025 00:21:34 +0000
Received: by outflank-mailman (input) for mailman id 1017602;
 Tue, 17 Jun 2025 00:21: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 1uRK4z-0007Bd-EN
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 00:21:33 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org
 [2600:3c04:e001:324:0:1991:8:25])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0474ba08-4b11-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 02:21:31 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 4564B629DF;
 Tue, 17 Jun 2025 00:21:30 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 47C8EC4CEEA;
 Tue, 17 Jun 2025 00:21: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: 0474ba08-4b11-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750119690;
	bh=RHkuIpnIZX0wYKhXFDudawHGDMOOeYU3utuaBGcbUyU=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=LWwe6CIMH43QasEuDVs54ax1kj3lGHjDqStfAZxFxY23jMSVRgvTCEt7ucp9jZ402
	 N4ZH+Llq775Is5hUcLXtqU631YjdG5ZsgI2ZlsEmS4VPwc9tArSk2wUNryE/XXnOsg
	 +B7WN4d/k/YW4hkrXMXoiYv0eTgWopUo1iSx7G/CrIFUhTM56FaRBQEA0tjvJCTdUh
	 gYwJOLM4Uy17WDbvhIMN5nF6k/w9+hmzP1j3ns7QTlf4fxuQpWgc90p8+tzsDMCORl
	 cgXKV0EHcEzP7nstCxxu/x3Tnz5EgvxLVQqQvO3s3qnItkeCZ/vbIZKIEDlKyyqELu
	 gfkao9E0vLTXQ==
Date: Mon, 16 Jun 2025 17:21:26 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Stefano Stabellini , 
    Jason Andryuk , 
    Christian Lindig , 
    David Scott , Anthony PERARD , 
    Andrew Cooper , 
    Michal Orzel , Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Bertrand Marquis , 
    Volodymyr Babchuk , 
    "Daniel P. Smith" , 
    xen-devel@lists.xenproject.org
Subject: Re: [PATCH 3/4] xen: Add DOMAIN_CAPS_DEVICE_MODEL &
 XEN_DOMCTL_CDF_device_model
In-Reply-To: <3ef3ed9d-d6af-4621-ab4c-eb2ea88081b3@suse.com>
Message-ID: 
References: <20250610225737.469690-1-jason.andryuk@amd.com> <20250610225737.469690-4-jason.andryuk@amd.com>  
 <3ef3ed9d-d6af-4621-ab4c-eb2ea88081b3@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 Jun 2025, Jan Beulich wrote:
> On 14.06.2025 00:47, Stefano Stabellini wrote:
> > On Wed, 11 Jun 2025, Jan Beulich wrote:
> >> On 11.06.2025 00:57, Jason Andryuk wrote:
> >>> To add more flexibility in system configuration add the new
> >>> DOMAIN_CAPS_DEVICE_MODEL flag and XEN_DOMCTL_CDF_device_model.
> >>>
> >>> Thie new flag corresponds to allowing XSM_DM_PRIV for the domain.  This
> >>> will enable running device model emulators (QEMU) from the assigne
> >>> domain for multiple target domains.
> >>>
> >>> Stubdoms assign target allowing the stubdom to serve as the device
> >>> model for a single domain.  This new flag allows the single domain to
> >>> provide emulators for multiple guests.
> >>>
> >>> The specific scenario is a disaggregated system with the hardware domain
> >>> providing device models for muitple guest domains.
> >>
> >> Why the hardware domain? Unless a DM also needs access to some of the
> >> physical hardware, it ought to run in a separate domain. Conceivably
> >> such a domain could service multiply guests, so maybe the "single
> >> target" concept presently used for stubdom simply needed extending?
> > 
> > Not necessarily. While it is possible to have driver domains, it is not
> > the default configuration.
> > 
> > In a default configuration, the hardware domain gets all the hardware by
> > default and therefore will also run the PV backends and Virtio backends.
> > The Virtio backends require DM hypercalls. Let me elaborate further.
> > 
> > In the datacenter, we have Dom0 typically with all the hardware, the
> > backends (PV and Virtio), and also the toolstack. Then all other domains
> > are created dynamically by the toolstack. Driver domains are possible
> > but not very common.
> > 
> > In automotive/embedded, the total number of domains is static, so we can
> > create them using dom0less. We don't need the toolstack to create VMs.
> > Also, we have safety concerns, so we want to take away as much
> > privileges as possible from Dom0.
> 
> At least purely by the wording, this ...
> 
> > This is easy because thanks to
> > dom0less, we don't need the toolstack and we don't need to create VMs
> > dynamically.
> > 
> > So the model is that Dom0 becomes the hardware domain: it has all the
> > drivers and backends but it is not privileged in the sense of
> > creating/destroying other VMs. If a user wants to have Dom0 "super
> > powers", they can create an optional Control Domain. The Control Domain
> > is expected to be tiny, such as XTF or Zephyr. It will have the ability
> > that Dom0 used to have but without the drivers. From a privilege
> > perspective, the Control Domain could create additional VMs, but in
> > automotive/embedded it is not expected to be a use-case because the
> > total number of VMs is still static. 
> > 
> > So your point about driver domains. Yes, one can have driver domains the
> > same way that one can have driver domains in the datacenter but it is
> > not the default.
> 
> ... kind of contradicts this: Running e.g. qemu in Dom0 gives Dom0 quite
> a bit of extra privilege.

Yes, in an ideal world that would not be necessary. However, in
automotive Virtio has become the standard. While there are efforts
ongoing to rework the Virtio protocol to have a better security/safety
profile, we need to provide something that works today. Even PV drivers
are not perfect in that regard because I don't think we can claim they
are free from interference but that is another topic.

In order to provide something that works today, we need to have support
for virtio backends in the hardware domain. Like you said, that gives
quite a bit of extra privilege to the hardware domain which is not
acceptable when targeting a "safe" VM such as the Control Domain.

Thus, we have another series to restrict DM and foreign mapping
hypercalls from being able to target "safe" domains. In other words, the
patch series will prevent the hardware domain from being able to target
the Control Domain or another DomU configured as "safe" with DM
hypercalls or foreign mapping hypercalls.

It will be up to the user to decide which domUs the harwdare domain will
be able to target. That way, the user will still be able to configure
one or more VMs are completely protected from interference from the
hardware domain at the cost of having no (traditional) virtio devices.


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 01:02:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 01:02:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017610.1394586 (Exim 4.92)
	(envelope-from )
	id 1uRKi1-00039N-Er; Tue, 17 Jun 2025 01:01:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017610.1394586; Tue, 17 Jun 2025 01:01:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRKi1-00039G-Bi; Tue, 17 Jun 2025 01:01:53 +0000
Received: by outflank-mailman (input) for mailman id 1017610;
 Tue, 17 Jun 2025 01:01: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 1uRKhz-000398-8s
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 01:01:52 +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 9dd02b60-4b16-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 03:01:36 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9dd02b60-4b16-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1750122094; x=1750381294;
	bh=lOWjNrVJ+2owpZ3HYE+jAf5VTHLHLjZhbcR67OKBKJA=;
	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=FYkVjUR8QVoezEj0biPlh2jrjnCYBcm6435QEkzzSFQ6aspNEOpCaqGUuIv/wy6pu
	 Op84ZUpPHWCkZLNpa+vy4yvFomXdHePFleznFxphoMEnxuinnkHJ56um4grHk3delJ
	 EVIgHjB3j0jAQbfjva1yzF2F/s2f5Jj9ob1xOFitXWG6JUDEXHFleBi7vHe1hDcpd8
	 QUnHOsWT+2qx/Dh8qqnVRnOWVoHNihS7M9SkAFfDUQtMhsR5GGzcGgrl0Abo+yoYQj
	 BavmG7m0l8VlL3UkQ7ezAyfJAJGl3B4KSUAA03hbSliOjgfMpOI/N2TtYSdT5tIh39
	 YXqjj8QHpBNfg==
Date: Tue, 17 Jun 2025 01:01:29 +0000
To: Stefano Stabellini 
From: dmkhn@proton.me
Cc: Alejandro Vallejo , Julien Grall , xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , =?utf-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , Michal Orzel , Bertrand Marquis , "Daniel P. Smith" 
Subject: Re: [PATCH v3 14/14] kconfig: Allow x86 to pick CONFIG_DOM0LESS_BOOT
Message-ID: 
In-Reply-To: 
References: <20250613151612.754222-1-agarciav@amd.com> <20250613151612.754222-15-agarciav@amd.com> <2a54e49b-c1ad-4654-9291-4373e92580ff@xen.org>  
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: c5eedbfe6de051fd842a13fa2b997bbea3105621
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 16, 2025 at 04:39:28PM -0700, Stefano Stabellini wrote:
> On Mon, 16 Jun 2025, Alejandro Vallejo wrote:
> > On Mon Jun 16, 2025 at 10:00 AM CEST, Julien Grall wrote:
> > > Hi,
> > >
> > > On 13/06/2025 16:13, Alejandro Vallejo wrote:
> > >> Without picking CONFIG_HAS_DEVICE_TREE.
> > >>
> > >> In order to do that. Allow CONFIG_DOM0LESS_BOOT to enable a subset
> > >> of the common/device-tree/ directory.
> > >  > x86 doesn't want dom0less-build.c,> as that's tightly integrated
> > > still to the ARM way of building domains.
> > >
> > > I don't understand this argument. dom0less-build.c was moved to commo=
n
> > > and it will soon be used by RISC-V. This raises the question what's s=
o
> > > special with x86?
> >
> > That's 2 separate matters:
> >
> >   1. dom0less-build.c not being compiled in.
> >   2. CONFIG_DOM0LESS_BOOT enabling use of DT code without CONFIG_HAS_DE=
VICE_TREE.
> >
> > (1) is a matter of not wanting to boil the ocean upfront. The way x86 a=
nd
> > everyone else build domains is just different and duplicated in non-tri=
vially
> > consolidable ways. The goal here is to enable the domain builders in an=
y arch
> > to use the same backbone. I don't want to go the extra mile just yet to=
 unify
> > domain construction (though in time I will want to).
> >
> > (2) has to do with compiling OUT things I really cannot have around. An=
ything
> > involving devices described in a DT must not exist on x86, because it h=
as no
> > concept of a "struct device".
> >
> > My intent is/was to repurpose CONFIG_HAS_DEVICE_TREE to mean "this hype=
rvisor
> > goes on a platform that gives a platform-describing DT". On x86 that's =
given by
> > DSDT/SSDTs with ACPI.
>=20
> Alejandro is suggesting two levels of Device Tree support:
>=20
> - full DT support, including device discovery via DT
> - minimal DT support, for the dom0less/hyperlaunch configuration
>=20
> Reading this series, it looks reasonable to me, at least as a stepping
> stone. I think it is expected that the kind of DT support needed by an
> architecture like ARM or RISC-V is different from the one needed by an
> architecture like x86. Of course we might be able to align things even
> more in the future but as of today I think it is reasonable to
> distinguish between the two.
>=20
> That said, we might want to consider renaming or changing the kconfig
> options. For instance:
>=20
> - CONFIG_HAS_DEVICE_TREE -> enable minimal DT support
> - CONFIG_DT_DEVICE_DISCOVERY -> device discovery via DT

Perhaps, shorter name like CONFIG_DT will be satisfactory? (instead of
CONFIG_DT_DEVICE_DISCOVERY and 'similar' convention to existing CONFIG_ACPI=
)

>=20
> In this model, all architectures would have CONFIG_HAS_DEVICE_TREE, but
> only ARM and RISC-V would have CONFIG_DT_DEVICE_DISCOVERY.
>=20
>=20
> > > Note I don't particularly care if you don't want to use it on x86.
> > > However, the argument provided is lacking some details... This will b=
e
> > > useful in the future if someone thinks about consolidating the two.
> >
> > I very definitely will want it all unified, but I'm working one elephan=
t at
> > a time.
>=20
> +1
>=20



From xen-devel-bounces@lists.xenproject.org Tue Jun 17 01:13:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 01:13:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017617.1394596 (Exim 4.92)
	(envelope-from )
	id 1uRKsi-0004lu-D7; Tue, 17 Jun 2025 01:12:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017617.1394596; Tue, 17 Jun 2025 01:12:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRKsi-0004ln-9v; Tue, 17 Jun 2025 01:12:56 +0000
Received: by outflank-mailman (input) for mailman id 1017617;
 Tue, 17 Jun 2025 01:12: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 1uRKsg-0004lh-BN
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 01:12:54 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 30376a1b-4b18-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 03:12:52 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 175012276011683.16054328213681;
 Mon, 16 Jun 2025 18:12:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 30376a1b-4b18-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; t=1750122762; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=PRnnLn8asxGjdrc+NW8IDYvPBW2MZQ3bPKZe1SCXlFsZ0hdqcX9H6bKP34GTWv2UpzENQQ0MbJux2n+A2yYrAU21HhWCHniI08/GlSCyts0CMCffxv8TJM554N7/tzykhK0kK9QpCzVvXRs0dBVtJUhGeqRFEwRKOptI1428PAc=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1750122762; 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=ytmJcUszrbSRxoCYO2hzwfhrhHHlfDtLLipssx5+Fr8=; 
	b=e3ZgBt7cNQhfrSweWpqTUuvQymmInGdAmVJ/kgmrp/Z/idpLE2LhQB3/shypJzL9lNj1IEn11/Kxwfvr2PE4aZ+LQ4UZ3ZbnHl217fH1bYHnq6vVUiumBDduuimb9PihSoRaEWaTpXWJDNIvFXRwX2W2NjaUTRQqB7xS2XYiF6I=
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=1750122762;
	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=ytmJcUszrbSRxoCYO2hzwfhrhHHlfDtLLipssx5+Fr8=;
	b=nGkQElnn8088OouzTKElTijp+Hl6zyPn5MQkMGaHzFhij4hTFsrjTLA3wez22pqC
	0Sp5rReHh+OMYo2rnEjuFGsihCWjY+M66f5OwZdyal0INpbQPdPoNJXwjLttGjwbLxb
	/GLz5yIx4LvDwhciytu/gnKJ2wfsLoYqRQTvdrgs=
Message-ID: <5b4e69b1-b8da-46db-97a1-1bd90f292613@apertussolutions.com>
Date: Mon, 16 Jun 2025 21:12:37 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 04/14] xen: Rename bootmodule{,s} to boot_module{,s}
Content-Language: en-US
To: Alejandro Vallejo , 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_Pau_Monn=C3=A9?= 
References: <20250613151612.754222-1-agarciav@amd.com>
 <20250613151612.754222-5-agarciav@amd.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: <20250613151612.754222-5-agarciav@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External



V/r,
Daniel P. Smith
Apertus Solutions, LLC

On 6/13/25 11:13, Alejandro Vallejo wrote:
> ... in alignment with the new coding style on word splitting for type
> names.
> 
> This aligns its name with the largely duplicate boot_module struct
> in x86. While there's no equivalent to "struct bootmodules" in x86,
> changing one and not the other is just confusing. Same with various
> comments and function names.
> 
> Rather than making a long subfield name even longer, remove the
> _bootmodule suffix in the kernel, initrd and dtb subfields.
> 
> Not a functional change.
> 
> Signed-off-by: Alejandro Vallejo 
> ---
>   xen/arch/arm/domain_build.c             |  4 +-
>   xen/arch/arm/efi/efi-boot.h             |  6 +--
>   xen/arch/arm/kernel.c                   |  4 +-
>   xen/arch/arm/llc-coloring.c             |  8 ++--
>   xen/arch/arm/mmu/setup.c                | 10 ++---
>   xen/arch/arm/setup.c                    | 10 ++---
>   xen/common/device-tree/bootfdt.c        |  4 +-
>   xen/common/device-tree/bootinfo.c       | 52 ++++++++++++-------------
>   xen/common/device-tree/dom0less-build.c | 25 ++++++------
>   xen/common/device-tree/domain-build.c   |  2 +-
>   xen/common/device-tree/kernel.c         | 22 +++++------
>   xen/include/xen/bootfdt.h               | 26 ++++++-------
>   xen/include/xen/fdt-kernel.h            |  7 ++--
>   xen/xsm/xsm_policy.c                    |  2 +-
>   14 files changed, 90 insertions(+), 92 deletions(-)
> 



> diff --git a/xen/xsm/xsm_policy.c b/xen/xsm/xsm_policy.c
> index 7f70d860bd..1f88b4fc5a 100644
> --- a/xen/xsm/xsm_policy.c
> +++ b/xen/xsm/xsm_policy.c
> @@ -68,7 +68,7 @@ int __init xsm_multiboot_policy_init(
>   #ifdef CONFIG_HAS_DEVICE_TREE
>   int __init xsm_dt_policy_init(void **policy_buffer, size_t *policy_size)
>   {
> -    struct bootmodule *mod = boot_module_find_by_kind(BOOTMOD_XSM);
> +    struct boot_module *mod = boot_module_find_by_kind(BOOTMOD_XSM);
>       paddr_t paddr, len;
>   
>       if ( !mod || !mod->size )

Acked-By: Daniel P. Smith 


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 01:15:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 01:15:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017624.1394607 (Exim 4.92)
	(envelope-from )
	id 1uRKvK-0005KY-Qb; Tue, 17 Jun 2025 01:15:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017624.1394607; Tue, 17 Jun 2025 01: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 1uRKvK-0005KR-Nd; Tue, 17 Jun 2025 01:15:38 +0000
Received: by outflank-mailman (input) for mailman id 1017624;
 Tue, 17 Jun 2025 01:15: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 1uRKvJ-0005KL-Fw
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 01:15:37 +0000
Received: from mail-24418.protonmail.ch (mail-24418.protonmail.ch
 [109.224.244.18]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 92015b0f-4b18-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 03:15:35 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 92015b0f-4b18-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1750122933; x=1750382133;
	bh=V8tA88GmK5S4e3ACwyNRMtwEN2aBPQgDgihYPDpta1Y=;
	h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
	 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector:
	 List-Unsubscribe:List-Unsubscribe-Post;
	b=eNuSkmSaPAJOCvVqG/nv2c4jdk5Wf4vogbc5RGVcaf4gBARiRB2kdADxtUuQi/aE2
	 PZtB7ChXeAuh194OLMpZCqhTvu1aXd5QAQXARlaHpz5o6NRWdEgUCsz331CRwKB1ba
	 rqFchr1QY639PN+Y5RtoMceSyM08E1P+eZ6aIYCCfllSV8gPERSJo6exbVT48ZA3NJ
	 599ZHutpGNA9iWapNwyoXelsrhnHrhEMVPhn8+9clb/osCGQGJKtKW7dGYMEOsymX/
	 hcFnpfUFKLEwK3vTWfjw2660dzvIhF2CroRtLTKDKZ2dTLmo/p0D5eQk+O/dyNGBcp
	 lpzcLeCZgrNGw==
Date: Tue, 17 Jun 2025 01:15:27 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com
Subject: [PATCH v8] xen/domain: rewrite emulation_flags_ok()
Message-ID: <20250617011519.55386-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: fc9b315f0a826527ec80e7cb12b2a911aa5f25cf
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Rewrite emulation_flags_ok() to simplify future modifications.

No functional change intended.

Signed-off-by: Denis Mukhin 
---
Changes since v7:
- expanded the code commentary
- added named type for domain capabilities

Link to v7: https://lore.kernel.org/xen-devel/20250610144500.3176661-1-dmuk=
hin@ford.com/
Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/1=
873169059
---
 xen/arch/x86/domain.c | 79 +++++++++++++++++++++++++++++++++----------
 1 file changed, 61 insertions(+), 18 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 7536b6c8717e..d2049e4c636b 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -743,32 +743,75 @@ int arch_sanitise_domain_config(struct xen_domctl_cre=
atedomain *config)
     return 0;
 }
=20
+/*
+ * Verify that the domain's emulation flags resolve to a supported configu=
ration.
+ *
+ * This ensures we only allow a known, safe subset of emulation combinatio=
ns
+ * (for both functionality and security). Arbitrary mixes are likely to ca=
use
+ * errors (e.g. null pointer dereferences).
+ *
+ * NB: use the internal X86_EMU_XXX symbols, not the public XEN_X86_EMU_XX=
X
+ * symbols, to take build-time config options (e.g. CONFIG_HVM) into accou=
nt
+ * for short-circuited emulations.
+ */
 static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
 {
+    enum domain_capability {
+        CAP_PV          =3D BIT(0, U),
+        CAP_HVM         =3D BIT(1, U),
+        CAP_HWDOM       =3D BIT(2, U),
+        CAP_DOMU        =3D BIT(3, U),
+    };
+    static const struct {
+        enum domain_capability caps;
+        uint32_t min;
+        uint32_t opt;
+    } configs[] =3D {
+#ifdef CONFIG_PV
+        /* PV dom0 and domU */
+        {
+            .caps   =3D CAP_PV | CAP_HWDOM | CAP_DOMU,
+            .opt    =3D X86_EMU_PIT,
+        },
+#endif /* #ifdef CONFIG_PV */
+
+#ifdef CONFIG_HVM
+        /* PVH dom0 */
+        {
+            .caps   =3D CAP_HVM | CAP_HWDOM,
+            .min    =3D X86_EMU_LAPIC | X86_EMU_IOAPIC | X86_EMU_VPCI,
+        },
+
+        /* PVH domU */
+        {
+            .caps   =3D CAP_HVM | CAP_DOMU,
+            .min    =3D X86_EMU_LAPIC,
+        },
+
+        /* HVM domU */
+        {
+            .caps   =3D CAP_HVM | CAP_DOMU,
+            .min    =3D X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ),
+            /* HVM PIRQ feature is user-selectable. */
+            .opt    =3D X86_EMU_USE_PIRQ,
+        },
+#endif /* #ifdef CONFIG_HVM */
+    };
+    unsigned int i;
+    enum domain_capability caps =3D (is_pv_domain(d) ? CAP_PV : CAP_HVM) |
+                                  (is_hardware_domain(d) ? CAP_HWDOM : CAP=
_DOMU);
+
 #ifdef CONFIG_HVM
     /* This doesn't catch !CONFIG_HVM case but it is better than nothing *=
/
     BUILD_BUG_ON(X86_EMU_ALL !=3D XEN_X86_EMU_ALL);
 #endif
=20
-    if ( is_hvm_domain(d) )
-    {
-        if ( is_hardware_domain(d) &&
-             emflags !=3D (X86_EMU_VPCI | X86_EMU_LAPIC | X86_EMU_IOAPIC) =
)
-            return false;
-        if ( !is_hardware_domain(d) &&
-             /* HVM PIRQ feature is user-selectable. */
-             (emflags & ~X86_EMU_USE_PIRQ) !=3D
-             (X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ)) &&
-             emflags !=3D X86_EMU_LAPIC )
-            return false;
-    }
-    else if ( emflags !=3D 0 && emflags !=3D X86_EMU_PIT )
-    {
-        /* PV or classic PVH. */
-        return false;
-    }
+    for ( i =3D 0; i < ARRAY_SIZE(configs); i++ )
+        if ( (caps & configs[i].caps) =3D=3D caps &&
+             (emflags & ~configs[i].opt) =3D=3D configs[i].min )
+            return true;
=20
-    return true;
+    return false;
 }
=20
 void __init arch_init_idle_domain(struct domain *d)
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Tue Jun 17 01:22:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 01:22:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017631.1394616 (Exim 4.92)
	(envelope-from )
	id 1uRL20-0006tV-Gp; Tue, 17 Jun 2025 01:22:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017631.1394616; Tue, 17 Jun 2025 01: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 1uRL20-0006tO-EC; Tue, 17 Jun 2025 01:22:32 +0000
Received: by outflank-mailman (input) for mailman id 1017631;
 Tue, 17 Jun 2025 01:22: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 1uRL20-0006tI-4o
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 01:22:32 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 892fd95e-4b19-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 03:22:31 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1750123339686734.8714601525589;
 Mon, 16 Jun 2025 18:22:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 892fd95e-4b19-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; t=1750123342; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=guLVTL370fa9aZotpj9bM1tRY43VtXjofIavx+guh92rqDA81k7p/jouwNkJk7yOOCBMj8vC20bXa8OyEaNSSGdb4s3Ahz08qTyeQYuQ27zeHARSP0oZD4ki8VD7XwwGVbLvhgVV1bCnKWC3cilVuf9e3B4TgfOo/I5KOaUjvXg=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1750123342; 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=IoSrJTKypXGOtB6YRucBgGVtnz4ec4v6yExK2YDPJKA=; 
	b=KMvam5670GGaoiBbxKNoKw5t4d8pcu5QaFj3QuFJCyHPGNM1fJjbOsaQikFAql70ELXoHaOU/gOJyHrYe3/6Ew10SCipoQHHCamLPQQ8GgUM+dUJmsVd787yuCst0mu7p0d2aeWlHFs3tFuMlfLRLzKJMfIhuOknC6OM8xwHn54=
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=1750123341;
	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=IoSrJTKypXGOtB6YRucBgGVtnz4ec4v6yExK2YDPJKA=;
	b=W3giyVkGsZ9On0h60BDp80K21gTv0+Q8sRzAMqc86lOxfGpuf+tWz09Metxg0wSB
	kU7rVFfR7DmwfjYwRzIJAT5G2xkUnDdm3fSdyObDxck+3HrGcFaXev7VhYJPq3oqabC
	mekVgRfoKaFRb0C6Ej/+vEYn+pDPx9bdRb/ERUQs=
Message-ID: <4b33dbe2-ee86-441a-b426-6551ccd04b31@apertussolutions.com>
Date: Mon, 16 Jun 2025 21:22:17 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 06/14] xen: Refactor kernel_info to have a header like
 boot_domain
Content-Language: en-US
To: Alejandro Vallejo , 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_Pau_Monn=C3=A9?= 
References: <20250613151612.754222-1-agarciav@amd.com>
 <20250613151612.754222-7-agarciav@amd.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: <20250613151612.754222-7-agarciav@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External


On 6/13/25 11:13, Alejandro Vallejo wrote:
> Create a struct header within kernel_info with the contents common to
> kernel_info and boot_domain, and define that header in common code. This enables
> x86 to use that header as-is and drop x86's boot_domain

IMHO kernel_info is an extremely poor name for this structure and 
hyperlauch attempt to resolve some of these less than optimal choices is 
being undone.

v/r,
dps


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 01:27:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 01:27:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017641.1394627 (Exim 4.92)
	(envelope-from )
	id 1uRL6n-0007Wp-54; Tue, 17 Jun 2025 01:27:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017641.1394627; Tue, 17 Jun 2025 01:27: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 1uRL6n-0007Wi-21; Tue, 17 Jun 2025 01:27:29 +0000
Received: by outflank-mailman (input) for mailman id 1017641;
 Tue, 17 Jun 2025 01:27: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 1uRL6l-0007Wc-BI
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 01:27:28 +0000
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 39603728-4b1a-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 03:27:25 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 39603728-4b1a-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1750123644; x=1750382844;
	bh=2Ql7A9stfIaDn/0b3h4dzkJ7F54TB/MRgBtbMPWnly0=;
	h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
	 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector:
	 List-Unsubscribe:List-Unsubscribe-Post;
	b=SdRSNcQR7twDiO800mXT6Ch37nANzPBfAzhup6JNT0GYtIs3OGsQqiup7t3e/T8mz
	 c5UKwN5Dn9vsEdYMV7z0wQokdc1yA01MmsY3wDDuDPuIdWkwztcLcJcyOTIV/giyc9
	 6bFGayCsfr5BN/Hwz7Gj9yE0D5Xnl3SGZS2Mzr8OPCyyaGsRP2QnQbETYyRKQtFkh/
	 5Vbi5Gvg+RPn+hK/4Uy7p+oKtvCbkLDWUwQ6NP30jvwHJ9w1noFLbfw3oEHeEQiQ7M
	 abC06hBhlXwKFoSOQAJoDE7L7GXPcqUKMe2Ocff6bWMsJ6oOQT/+vfoLJD9emqQSPA
	 lHtnr5Jyo6/eA==
Date: Tue, 17 Jun 2025 01:27:19 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com
Subject: [PATCH v2] xen/console: introduce domain_console struct
Message-ID: <20250617012713.57074-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 823db6e1ad105196514db47a508dd2a404e48605
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Introduce domain_console for grouping data structures used for integrating
domain's diagnostic console with Xen's console driver.

Group all pbuf-related data structures under domain_console. Rename the mov=
ed
fields to plain .buf, .idx and .lock names, since all uses of the fields ar=
e
touched.

Bump the domain console buffer size to the closest power of 2 (256) and
rename the symbol to DOMAIN_CONSOLE_BUF_SIZE.

Move d->console->buf management under CONFIG_VERBOSE_DEBUG when the
HYPERCALL_console_io handler is enabled.

Finally, update the domain_console allocation code.

No functional change.

Signed-off-by: Denis Mukhin 
---
Changes since v1:
- added new struct domain_console
- updated allocation code for domain's console data structure
- bumped the size of the domain's output buffer to 256
- put domain's console buffer treatment under CONFIG_VERBOSE_DEBUG

I addressed most of the v1 feedback here, since all fields of the domain's
console data structures are touched.

Domain's console input buffer question is not addressed because it looks li=
ke a
separate (big) patch.

Link to v1: https://lore.kernel.org/xen-devel/20250606194937.2412579-1-dmuk=
hin@ford.com/
Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/1=
870179848
---
 xen/arch/arm/vpl011.c      |  2 +-
 xen/arch/x86/hvm/hvm.c     | 26 ++++++++++++++++----------
 xen/arch/x86/pv/shim.c     |  2 +-
 xen/common/domain.c        | 18 ++++++++++--------
 xen/drivers/char/console.c | 24 ++++++++++++++----------
 xen/include/xen/sched.h    | 27 +++++++++++++++++----------
 6 files changed, 59 insertions(+), 40 deletions(-)

diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 2b6f2a09bca6..f4a840da10c5 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -713,7 +713,7 @@ int domain_vpl011_init(struct domain *d, struct vpl011_=
init_info *info)
     }
     else
     {
-        d->console.input_allowed =3D true;
+        d->console->input_allowed =3D true;
         vpl011->backend_in_domain =3D false;
=20
         vpl011->backend.xen =3D xzalloc(struct vpl011_xen_backend);
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 056360d5fe50..4295d98ddeb1 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -559,7 +559,6 @@ void hvm_do_resume(struct vcpu *v)
 static int cf_check hvm_print_line(
     int dir, unsigned int port, unsigned int bytes, uint32_t *val)
 {
-    struct domain *cd =3D current->domain;
     char c =3D *val;
=20
     ASSERT(bytes =3D=3D 1 && port =3D=3D XEN_HVM_DEBUGCONS_IOPORT);
@@ -570,17 +569,24 @@ static int cf_check hvm_print_line(
=20
     if ( !is_console_printable(c) )
         return X86EMUL_OKAY;
-
-    spin_lock(&cd->pbuf_lock);
-    if ( c !=3D '\n' )
-        cd->pbuf[cd->pbuf_idx++] =3D c;
-    if ( (cd->pbuf_idx =3D=3D (DOMAIN_PBUF_SIZE - 1)) || (c =3D=3D '\n') )
+#ifdef CONFIG_VERBOSE_DEBUG
+    else
     {
-        cd->pbuf[cd->pbuf_idx] =3D '\0';
-        guest_printk(cd, XENLOG_G_DEBUG "%s\n", cd->pbuf);
-        cd->pbuf_idx =3D 0;
+        struct domain *cd =3D current->domain;
+        struct domain_console *cons =3D cd->console;
+
+        spin_lock(&cons->lock);
+        if ( c !=3D '\n' )
+            cons->buf[cons->idx++] =3D c;
+        if ( (cons->idx =3D=3D (DOMAIN_CONSOLE_BUF_SIZE - 1)) || (c =3D=3D=
 '\n') )
+        {
+            cons->buf[cons->idx] =3D '\0';
+            guest_printk(cd, XENLOG_G_DEBUG "%s\n", cons->buf);
+            cons->idx =3D 0;
+        }
+        spin_unlock(&cons->lock);
     }
-    spin_unlock(&cd->pbuf_lock);
+#endif
=20
     return X86EMUL_OKAY;
 }
diff --git a/xen/arch/x86/pv/shim.c b/xen/arch/x86/pv/shim.c
index bc2a7dd5fae5..bd29c53a2d34 100644
--- a/xen/arch/x86/pv/shim.c
+++ b/xen/arch/x86/pv/shim.c
@@ -239,7 +239,7 @@ void __init pv_shim_setup_dom(struct domain *d, l4_pgen=
try_t *l4start,
      */
     d->max_pages =3D domain_tot_pages(d);
=20
-    d->console.input_allowed =3D true;
+    d->console->input_allowed =3D true;
 }
=20
 static void write_start_info(struct domain *d)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index e566a1874795..578eb587e27e 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -669,7 +669,7 @@ static void _domain_destroy(struct domain *d)
     BUG_ON(!d->is_dying);
     BUG_ON(atomic_read(&d->refcnt) !=3D DOMAIN_DESTROYED);
=20
-    xfree(d->pbuf);
+    xfree(d->console);
=20
     argo_destroy(d);
=20
@@ -800,6 +800,11 @@ struct domain *domain_create(domid_t domid,
     if ( (d =3D alloc_domain_struct()) =3D=3D NULL )
         return ERR_PTR(-ENOMEM);
=20
+    err =3D -ENOMEM;
+    d->console =3D xvzalloc(typeof(*d->console));
+    if ( !d->console )
+        goto fail;
+
     /* Sort out our idea of is_system_domain(). */
     d->domain_id =3D domid;
     d->unique_id =3D get_unique_id();
@@ -832,7 +837,7 @@ struct domain *domain_create(domid_t domid,
         if ( old_hwdom )
             old_hwdom->cdf &=3D ~CDF_hardware;
=20
-        d->console.input_allowed =3D true;
+        d->console->input_allowed =3D true;
     }
=20
     /* Holding CDF_* internal flags. */
@@ -862,7 +867,9 @@ struct domain *domain_create(domid_t domid,
     spin_lock_init(&d->shutdown_lock);
     d->shutdown_code =3D SHUTDOWN_CODE_INVALID;
=20
-    spin_lock_init(&d->pbuf_lock);
+#ifdef CONFIG_VERBOSE_DEBUG
+    spin_lock_init(&d->console->lock);
+#endif
=20
     rwlock_init(&d->vnuma_rwlock);
=20
@@ -955,11 +962,6 @@ struct domain *domain_create(domid_t domid,
     if ( (err =3D argo_init(d)) !=3D 0 )
         goto fail;
=20
-    err =3D -ENOMEM;
-    d->pbuf =3D xzalloc_array(char, DOMAIN_PBUF_SIZE);
-    if ( !d->pbuf )
-        goto fail;
-
     if ( (err =3D sched_init_domain(d, config->cpupool_id)) !=3D 0 )
         goto fail;
=20
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 616f4968b004..61a804c09a50 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -524,7 +524,7 @@ struct domain *console_get_domain(void)
     if ( !d )
         return NULL;
=20
-    if ( d->console.input_allowed )
+    if ( d->console->input_allowed )
         return d;
=20
     rcu_unlock_domain(d);
@@ -567,7 +567,7 @@ static void console_switch_input(void)
         {
             rcu_unlock_domain(d);
=20
-            if ( !d->console.input_allowed )
+            if ( !d->console->input_allowed )
                 continue;
=20
             console_rx =3D next_rx;
@@ -754,9 +754,11 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM=
(char) buffer,
             console_send(kbuf, kcount, flags);
             nrspin_unlock_irq(&console_lock);
         }
+#ifdef CONFIG_VERBOSE_DEBUG
         else
         {
             char *kin =3D kbuf, *kout =3D kbuf, c;
+            struct domain_console *cons =3D cd->console;
=20
             /* Strip non-printable characters */
             do
@@ -769,23 +771,25 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARA=
M(char) buffer,
             } while ( --kcount > 0 );
=20
             *kout =3D '\0';
-            spin_lock(&cd->pbuf_lock);
+            spin_lock(&cons->lock);
             kcount =3D kin - kbuf;
             if ( c !=3D '\n' &&
-                 (cd->pbuf_idx + (kout - kbuf) < (DOMAIN_PBUF_SIZE - 1)) )
+                 cons->idx + kout - kbuf < DOMAIN_CONSOLE_BUF_SIZE - 1 )
             {
                 /* buffer the output until a newline */
-                memcpy(cd->pbuf + cd->pbuf_idx, kbuf, kout - kbuf);
-                cd->pbuf_idx +=3D (kout - kbuf);
+                memcpy(cons->buf + cons->idx, kbuf, kout - kbuf);
+                cons->idx +=3D (kout - kbuf);
             }
             else
             {
-                cd->pbuf[cd->pbuf_idx] =3D '\0';
-                guest_printk(cd, XENLOG_G_DEBUG "%s%s\n", cd->pbuf, kbuf);
-                cd->pbuf_idx =3D 0;
+                cons->buf[cons->idx] =3D '\0';
+                guest_printk(cd,
+                             XENLOG_G_DEBUG "%s%s\n", cons->buf, kbuf);
+                cons->idx =3D 0;
             }
-            spin_unlock(&cd->pbuf_lock);
+            spin_unlock(&cons->lock);
         }
+#endif
=20
         guest_handle_add_offset(buffer, kcount);
         count -=3D kcount;
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index fe53d4fab7ba..388ba70a41a9 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -371,6 +371,22 @@ struct evtchn_port_ops;
=20
 #define MAX_NR_IOREQ_SERVERS 8
=20
+/* Arbitrary value; must be a multiple of the cacheline size. */
+#define DOMAIN_CONSOLE_BUF_SIZE 256
+
+/* Domain console settings. */
+struct domain_console {
+#ifdef CONFIG_VERBOSE_DEBUG
+    /* hvm_print_line() and guest_console_write() logging. */
+    char *buf;
+    unsigned int idx;
+    spinlock_t lock;
+#endif /* CONFIG_VERBOSE_DEBUG */
+
+    /* Permission to take ownership of the physical console input. */
+    bool input_allowed;
+};
+
 struct domain
 {
     domid_t          domain_id;
@@ -562,12 +578,6 @@ struct domain
     /* Control-plane tools handle for this domain. */
     xen_domain_handle_t handle;
=20
-    /* hvm_print_line() and guest_console_write() logging. */
-#define DOMAIN_PBUF_SIZE 200
-    char       *pbuf;
-    unsigned int pbuf_idx;
-    spinlock_t  pbuf_lock;
-
     /* OProfile support. */
     struct xenoprof *xenoprof;
=20
@@ -653,10 +663,7 @@ struct domain
 #endif
=20
     /* Console settings. */
-    struct {
-        /* Permission to take ownership of the physical console input. */
-        bool input_allowed;
-    } console;
+    struct domain_console *console;
 } __aligned(PAGE_SIZE);
=20
 static inline struct page_list_head *page_to_list(
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Tue Jun 17 01:32:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 01:32:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017648.1394636 (Exim 4.92)
	(envelope-from )
	id 1uRLBl-0000hG-Ky; Tue, 17 Jun 2025 01:32:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017648.1394636; Tue, 17 Jun 2025 01:32:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRLBl-0000h9-IK; Tue, 17 Jun 2025 01:32:37 +0000
Received: by outflank-mailman (input) for mailman id 1017648;
 Tue, 17 Jun 2025 01:32: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 1uRLBk-0000h3-Hs
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 01:32:36 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f134759c-4b1a-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 03:32:35 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1750123946759626.2785154087962;
 Mon, 16 Jun 2025 18:32:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f134759c-4b1a-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; t=1750123948; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=DhOg1eh3CgOeEJojCIZS3aIh3pbnsVdf9Zc/lUj97sdyfAA0vW5qQ/fGxR2MKrhg3CrkLTD0Q0EVfbtPox2AuteQ81IXkzJD1tmYfSv9I7z5k1TKSqxdhUd6dhfJW0zyKilIS4rpsJIdbupihHRhrGHE4i8TaG242T0JTcI1hJY=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1750123948; 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=JJHOoCCrFEDDE3+elqGVFHThJKLiglOSjqYyAnkLAR4=; 
	b=em2yRfKvV6AQXbJ+NnLBHMlykUp7d6guIKj+hPFmI1lHDhNL326qaPkUlVfksGkeONvSgGrSV4yZvy/EBuIcPJcKWenCxkx+Gf/uC841MYSoKjcOBJtv3kxr1k/hTLI7p24oVooz+OvKzBMMVai6HN3Sl99vSZIH3qjYbaIJs2M=
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=1750123948;
	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=JJHOoCCrFEDDE3+elqGVFHThJKLiglOSjqYyAnkLAR4=;
	b=QcRmgWtz0fN+/5HFjF7aoqSoGbRdqpb6nUB9tzUWbPY17hBOIKJjVGheAgprLjGs
	mfEoO+hGyjkqXnN8nH6X15P4sx2zQ2puqNcHS3QEf9S3PAUoo/sCNgH20k2WFjcI8EI
	DCy2jqJxxrAQrjJ2AWNLoN9lkhAtIptz/ekf8U0w=
Message-ID: <9f430606-f79e-470b-8323-92cd8f0f8ddd@apertussolutions.com>
Date: Mon, 16 Jun 2025 21:32:24 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 12/19] xen/dt: Move bootfdt functions to xen/bootfdt.h
Content-Language: en-US
To: Alejandro Vallejo , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: 
 <20250530120242.39398-1-agarciav@amd.com>
 <20250530120242.39398-13-agarciav@amd.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: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 6/5/25 14:03, Alejandro Vallejo wrote:
> On Mon Jun 2, 2025 at 10:25 PM CEST, Daniel P. Smith wrote:
>>> +/* Helper to read a big number; size is in cells (not bytes) */
>>> +static inline u64 dt_read_number(const __be32 *cell, int size)
>>> +{
>>> +    u64 r = 0;
>>> +
>>> +    while ( size-- )
>>> +        r = (r << 32) | be32_to_cpu(*(cell++));
>>> +    return r;
>>> +}
>>
>> I know you are trying to keep code changes to a minimal but let's not
>> allow poorly constructed logic like this to continue to persist. This is
>> an unbounded, arbitrary read function that is feed parameters via
>> externally input. The DT spec declares only two number types for a
>> property, u32 and u64, see Table 2.3 in Section 2.2.4. There is no
>> reason to have an unbounded, arbitrary read function lying around
>> waiting to be leveraged in exploitation.
> 
> Seeing how it's a big lump of code motion, I really don't want to play games
> or I will myself lose track of what I changed and what I didn't.

You could have a preliminary commit before this one that removes a 
clearly vulnerable code, and then this commit can move it. Or reverse it 
and do the code move and fix it.

> While I agree it should probably be a switch statement (or factored away
> altogether), this isn't the place for it.

All due respect, but leaving code that is clearly a sitting 
vulnerability mine is not really a great choice.

V/r,
dps



From xen-devel-bounces@lists.xenproject.org Tue Jun 17 03:38:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 03:38:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017656.1394646 (Exim 4.92)
	(envelope-from )
	id 1uRN9H-0006oT-4Z; Tue, 17 Jun 2025 03:38:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017656.1394646; Tue, 17 Jun 2025 03:38: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 1uRN9H-0006oM-1g; Tue, 17 Jun 2025 03:38:11 +0000
Received: by outflank-mailman (input) for mailman id 1017656;
 Tue, 17 Jun 2025 03:38: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 1uRN9E-0006oG-PL
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 03:38:08 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20604.outbound.protection.outlook.com
 [2a01:111:f403:2009::604])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7a6d412c-4b2c-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 05:38:06 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 DM4PR12MB7717.namprd12.prod.outlook.com (2603:10b6:8:103::14) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8835.25; Tue, 17 Jun 2025 03:38:00 +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.8835.027; Tue, 17 Jun 2025
 03:37: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: 7a6d412c-4b2c-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=hR+oWidaK1bzdmlL4LDkbvE57h6nlyvuJFGEZ/UGlrMvL6gzV/StOEcAjT/Yaa0V8I3oe0VHBgVZPyO75iJdT+H/rJlo3y82jI2RhrC+7uapyRz1RHr/JZec5AF0pjOXGDkBs/9JfvCyP3K++iE4wZ1CT9dFxaLH7LV6J1iKLXOJg8HSC65BxqiS1tWSP+WiGlcaVEWEaEf77HdlrUcbvD+vTIo+e5P4CtXJzA82m+zC9Xbkw4pC8Z/qTZjfyFweYgXPCKUp+SEVFvwzULr6+S9rx2C+mc3EU0mnc+W3LCYr05XpNAtUZVhhYTLFsmUw/mv9IcbnU1TPUtt7Bo/xlA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=kfvLFk/btPx6m9wR5ht99Ql3XsUA6L4ajjpm7UMn3z8=;
 b=pUyxhK2SrG7MaU52lBVtpA7DDRkhLAMOfPoOG0URrhvBNxdx0MWpi6lLNiZTMysTIvqy74Bn4TrUdlQ3wrBqXceVDXN5BmGQf0YWTT4e5I9oPurymUfTRM4X+SA3dzx2NCDFC5nY1dXY7j72LcBxfYlKqx3XVedzKI6llx/gRoo0Cuh830wfugzeST9901XSfgdSuebDgVBMZ8DJv+ETEnQqQNxzu7Dmpnn87D/LpdjJEIEmoyEoViQ0b4A4gAOQh9C4k8HzYXuayp5n30iBjooGPmbQRFmJouxMXwzZ/RAwZxwquACfea1gnjcmNlc/+Z8E2kY/4e4BRoZpb0aqfg==
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=kfvLFk/btPx6m9wR5ht99Ql3XsUA6L4ajjpm7UMn3z8=;
 b=sfDuC+yXs2KrfyfavVvNz9dPUHKvh8MTU14uoHSPj1F/QhQQiej8YoOhAiILodM5eIfFswx4ckxO8NJjm/GE4eQWOkc0VF9sVb1VM0imMr7c70S2WcqpMje3OeLNpcYYKy5VyYfy0xuuRUZ+uE2qRAsDgWuC5kcV7+ju1xnnbNs=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v5 01/18] xen/pmstat: guard perf.states[] access with
 XEN_PX_INIT
Thread-Topic: [PATCH v5 01/18] xen/pmstat: guard perf.states[] access with
 XEN_PX_INIT
Thread-Index: AQHbzuQ5KDq5M5MbdEiyL/UuBwqBb7P+KsSAgALCz6CABLMkgIABL2Ig
Date: Tue, 17 Jun 2025 03:37:59 +0000
Message-ID:
 
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-2-Penny.Zheng@amd.com>
 <0d60d42f-d844-41b5-a8ca-bdfe7883d15b@suse.com>
 
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=True;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-06-17T03:37:51.0000000Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=3;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged
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_|DM4PR12MB7717:EE_
x-ms-office365-filtering-correlation-id: fd0ffee5-8f9c-46c4-24f9-08ddad505aec
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?VWlyYWhyM3BXTmFZWlBvN2YyT2RZT0F1S3Vodm1COUNpOEJVRnM5OHkxY3dh?=
 =?utf-8?B?WFp3aG9tWGpVVHVjV2FlL1NXZHpZR3FsMXR6bGVFb254WjFxeGhydUZtdzJP?=
 =?utf-8?B?NmFkQkwzRE0xME9pQmtSdXBpK1dNSmhiQVRYK2ltWTF3cmFEMVV4bkVvaEls?=
 =?utf-8?B?WnN4amx6RkxVOTVzSG1ROVNJVVFiZjlUSnJkQXd5YUN0R2t5UTFFbUg3UjBM?=
 =?utf-8?B?clozUXd1dHdGczhhbWs4UElHUmlmaE5wbDRmQ2dZMWhPOFJidGE0eGNpQVVz?=
 =?utf-8?B?bENMeVg4aDRMUUtITkYyb2YwMUtwcC9uMjhUQ0V6T3VtMzgrT2FROSt4eHEr?=
 =?utf-8?B?NjljN01KN29RNHJGM3hMb28zcUtzb3FxdnhyNUFzdW5DM2Z3NEM3SDJEdlBa?=
 =?utf-8?B?a1Z2U05Zc2FlZWt0YWxoVzdQZjVFRWdpT1ZNQnp3ZFRrbjBjOWpnbkFRWXVm?=
 =?utf-8?B?TmVJQ0hPbnhNd25QK25TOEpZWTBJaGxhVlI5c1RhSTAxaWNSNFNudjdDTTZI?=
 =?utf-8?B?N3BWSFZhL0NmNkc1elBEMjZDVE84SFZZN2dHVjI3Z2xFd2w4cUtPSmMyQ2lh?=
 =?utf-8?B?cnVBUmNQTzFYREtjWjM1QkIzT0Q0TnV1Q0tLb2RrQTVSZGZLckkxbEtiZWVY?=
 =?utf-8?B?T0d5RTV5K0I2QmltWjk2cS9GK2pLZnRVYWpwOTFnUUtKT2tJNEFSd2hDdll4?=
 =?utf-8?B?YUVGWndMQy9ObTR5T05jUkJLL3RSN3FNS0cwbktMV0NtcnVKZ3VFT0Vvak50?=
 =?utf-8?B?ZlZsUkdxbUlyeFRyejZjSndSMW5VajZ1ZzZOUnRhSkxJUHVubVhlVU8xL2lY?=
 =?utf-8?B?TE5iMU1SS0JrbFpMVm5ocGZBdUNiZ3gwdWVKa3pMSzVkMi9MVTBMZmFkQkMy?=
 =?utf-8?B?TDBQRER5R1BOeHFCSE1CdGlIcUZMQ0d6aG4zMTNkTzA2SWgvQUNPajEzSFBN?=
 =?utf-8?B?cHVxWjBXMVY3cE5ibURJbFVkQzBQbGRYOExLa0ROeEZyajJ2eExDVWVYcjF4?=
 =?utf-8?B?bWtxQlR4bElVOTZla2ZaeTkwL3l1OU8zNVNkQlFhMndBWk1OaVkxelZDWHg1?=
 =?utf-8?B?eVNSdXV0dGw5VXhmWWhsM2R4ek9TRGdjMXU4MElyb1Y5Q2d0cWJFMERBeGJo?=
 =?utf-8?B?UjMrcXowQ2xDS2FJYVhkVHRrT0VYbnY0b3NKUFFMR01obEpXN2tsUWhUWlRV?=
 =?utf-8?B?dFhSNThpTytVdGxRYThlV3NhaXFMMGVDMUZGdUFuZEt4RUx1TVFnK2JtdTRn?=
 =?utf-8?B?SXIraTU5Q2I0SlIxU29DVFJmOFJ0Q1EvcHdZRzZNVEZRMFRmQmR4QVVrZURy?=
 =?utf-8?B?cmgxZGJHbFZpbmNyWm1mZUR1eXN6aVNpckdkVnNXZHh4WndHUGRDS3JBZ3Rk?=
 =?utf-8?B?VDd1UVoycUZaSTd3a0I1QzQybDF1RnZJVmYzUmpGVnliV1djWjJEbWtWUFNs?=
 =?utf-8?B?TFp1OEt3eWhuNVRxUUVGWFcyTDBQOFJNalZTZzZ3SW5ta2ttTjgvVnVHd1h2?=
 =?utf-8?B?QUh4SkRIVFFXTC9CL1poRHhzMy84YVNoMEpXYlFLT01wQWNqTnBidDFQTlds?=
 =?utf-8?B?MVlmUS8rclJoTU03QlBIcTlEUDFSWE43U0w0MVdWTG83bWF6Y2picDEyR29I?=
 =?utf-8?B?SmtIdC9seHFTNEoreVJ5NXdEUEdQeE9mMXl2dDBrUFRhQm5yQlNyN2dBWmty?=
 =?utf-8?B?UUcxYzZmaGdCeGl0N2NiTFJjcURreERic2Uyd1k0NGRvZ2FmWlJ5ZHZDL2gx?=
 =?utf-8?B?eW9vaDhLQ2V1SnNlZXY5QUtTWWF1K1hBV1c0aWhiUk15MytTeWxrcEVTQ21Y?=
 =?utf-8?B?b20yT1NreDArMzVPOThkNTE0b2tYQjlycS9tMjVlamJvdG9lUVREYXBocFln?=
 =?utf-8?B?ZkttUUI4N3J4NEprL3hNV1Jxd1VBSStvZjdVY2wyYWwwQU9QZG5oSldYalF3?=
 =?utf-8?B?VnV4MkNLYmVHSjFsT0dyZ3RzU1lxemRCV2FCRGk5ZFlGSE8vVkxuQVlnTHo0?=
 =?utf-8?Q?8HcxvvgLFlN3Tsn5Dk1719GzFaneuU=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)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?UlBGa1VJYW05L2gvczkzZU5zRm84Z2dqdDFwNEhZcGtJTmVKNytXVEpRaUhX?=
 =?utf-8?B?Um8rMnlEMnhtQ3JUTTdvV0RtcUlwVU5Sc0VPNm84MXVLYTBSN0hsTHJNTml3?=
 =?utf-8?B?aXlQdlJnY2pIUjBCajRtZXVRYkJ3Sm13ajFva2xnYzFiSUsxSVFGNXpkTHpz?=
 =?utf-8?B?dGlFSHJaYlg1OS9LQUdOK2IyNHJqVzRCZ2VoNStvNVpLRThQc1hVZmlwOHdn?=
 =?utf-8?B?bGZ2TGVJUzRJRDhRYkJHekdiWWt2SXhLNDY2b0xMb1YzNGFveEFTMEJmUVJj?=
 =?utf-8?B?bExIR1FGZ0dDSzNxSHhrTFFOcW81TnBISFRremNVU3NuM05paks2OUxQVG5P?=
 =?utf-8?B?ZVluVEJsanpzYU8wYmlIdjZ4b002N1dVNVJ0Vk10aXh2QmwzeXZvbTA2b25N?=
 =?utf-8?B?SjIvRGwray9Za3cybVZZazdyU1NVdk9LNVJORGJUZUlBUVFSWXVETnJ4M21w?=
 =?utf-8?B?OVBIUm5YUzJFVmdpWlRISnZUZzdUSlh0amVyMFRJY1Y1V1Z3SVdxRmMzQm5E?=
 =?utf-8?B?aGhRMW9LZlZFWndtWXg1MC9naTUrSlNscnppTTU1K1c2UVV2aDFHWDd3RDJB?=
 =?utf-8?B?dElVcVJ4MUlsa2l2VkRBai83TDV1YUhpYi9ObHNEM1RkMUlaREpORklJR0pM?=
 =?utf-8?B?RGZVTml5d2JibDM5cG45aHI0L1gyZ1RuWW55VGY3dEhHNFM2bzk0ZU1QaEp0?=
 =?utf-8?B?ZGJ5NE5Td1ZGMVVha0R4MFFlOWlDVVI2K2ZoVVFGbml1NjQ0Z3lHc1dWaUR3?=
 =?utf-8?B?UmpEUThxRnlwSVIxK3FZTHJtdGw2MW1WYWErcWV6aGFjTjhTZWRxNkJFN2Vw?=
 =?utf-8?B?ajVUL1ByTHNmWTU3bHRJbTg3WGJIa25rektRK3p5djRjY0FLQ0cyYzRxdCtG?=
 =?utf-8?B?WTBrZ29sVm1vUlZoVXBwOUQwNDMvcW1hK1lOWk84NDhyTDhuUXpPQ2xSMmtY?=
 =?utf-8?B?b1QxbGFCMWRmNDlGYm0zUDN5K2JXMk9PUzRTS2ZIeXRMWldmTERaN2k3QUh2?=
 =?utf-8?B?aG1zWW41MlNOcjV2OCtUcVNOSzhOZjhiaWYzUGd3K3JPWlY3d2VEa2pPU0sv?=
 =?utf-8?B?cFlPWmdmd3E2UCsxZVlDTzlpWWcwUm92TkxQYnFTblZySGMveWh3N2hiZjl3?=
 =?utf-8?B?UVE4MmRHYkNDNzE2RUVmZmtoV3E4eHdBVWtDOVFDL0xDY2R2VXlXZ3pZK3lC?=
 =?utf-8?B?V3k3blM5dVZ2R1NYTkp3NzFOdDk4RzNNNC91SEs2Y2c0ZUFCTm1mSkNzUlBM?=
 =?utf-8?B?SGxxM2tLZDNpN1RiWURzbEF5bitjK1BkUDRzcjJLUDBlbUNUMkpETjh3aERG?=
 =?utf-8?B?L0crV25YUk50cDdoN3NVbWdPWUxtN3c3Tm1TdGxWckUzRDFZblhVNmVENEpv?=
 =?utf-8?B?VG8vdytZVHVaMmtSck4va2o5NjlkUUJqcEduYzgzT0R6RnVBbkE5anRjSTR0?=
 =?utf-8?B?ZE5kYkkrU0ZjdjdrNTZuVllWZFlhejd4VlNEUnZKZTQyeUVwWks2ZGZwbEdk?=
 =?utf-8?B?Y0dibVhlYXIwNzc5K0Q0dW01NWZGdXdZQ3hqb3RHVkg4NmpaZ3IxV0FCQ0Rx?=
 =?utf-8?B?OHBTWnkwWlRvWjkyazZRblYwM2c0UDFrUDVPQkkvd2txMW9ZWGhKTTBOUTF2?=
 =?utf-8?B?Sk80c3EzTVA2cVFrUjZ5MG1HQWgzSkV3bzZYU0RaSExFdUtlTXhzZ24yelNX?=
 =?utf-8?B?bElRRVBlYnE3enFRdGZBelB1UXZMbTROQzlyOUVlNmo2TXVmemhHcUtwRExM?=
 =?utf-8?B?Mi9uSUIvaTdBUituOGhMYkpWTC9LWWRBWEVjRitiaG9iTU9SQUk3Um9PMUpS?=
 =?utf-8?B?amt0aktmSEFubzR3TTBwMlJMcFVaWnJHbkUySCtKeWd0dWNLU2FwZytZSDBh?=
 =?utf-8?B?bk9qNElOallCTWExNGZJNDJuQ3h3SGFJNmRtZTNOZklUdUtySXp4QXRia0JP?=
 =?utf-8?B?WEZCQlNoaUcxc1Y2MDBZbjBXakYrdWMyeXROcCtSbEZGRDdpRVJDQ2dpdFhj?=
 =?utf-8?B?WWxjTklMTmFPOGtKTFcwRmpBMVh0Q1dQVEkrTDMybGpzSENiOHQwbzVTcE9L?=
 =?utf-8?B?a1hQQzlIQTc0TEFReEVtTXBtWDcwUmtLZTdnNnVqYmRNMzk4NXExL2g1NDFL?=
 =?utf-8?Q?Bako=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: fd0ffee5-8f9c-46c4-24f9-08ddad505aec
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2025 03:37:59.0652
 (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: 4xnmWk+v5oV0UD+yt/uAG7EpYEXwnxHjXnl1joPmb3R2R1+sOy/jS5+FHH2INadY8Vs9dES8xFTWYzzJIdFo3w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB7717

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IE1vbmRheSwgSnVuZSAxNiwgMjAyNSA1
OjE2IFBNDQo+IFRvOiBQZW5ueSwgWmhlbmcgPHBlbm55LnpoZW5nQGFtZC5jb20+DQo+IENjOiBI
dWFuZywgUmF5IDxSYXkuSHVhbmdAYW1kLmNvbT47IHhlbi1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0
Lm9yZw0KPiBTdWJqZWN0OiBSZTogW1BBVENIIHY1IDAxLzE4XSB4ZW4vcG1zdGF0OiBndWFyZCBw
ZXJmLnN0YXRlc1tdIGFjY2VzcyB3aXRoDQo+IFhFTl9QWF9JTklUDQo+DQo+IE9uIDE2LjA2LjIw
MjUgMTE6MDUsIFBlbm55LCBaaGVuZyB3cm90ZToNCj4gPiBbUHVibGljXQ0KPiA+DQo+ID4+IC0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IEphbiBCZXVsaWNoIDxqYmV1bGlj
aEBzdXNlLmNvbT4NCj4gPj4gU2VudDogV2VkbmVzZGF5LCBKdW5lIDExLCAyMDI1IDExOjIwIFBN
DQo+ID4+IFRvOiBQZW5ueSwgWmhlbmcgPHBlbm55LnpoZW5nQGFtZC5jb20+DQo+ID4+IENjOiBI
dWFuZywgUmF5IDxSYXkuSHVhbmdAYW1kLmNvbT47IHhlbi1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0
Lm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogW1BBVENIIHY1IDAxLzE4XSB4ZW4vcG1zdGF0OiBndWFy
ZCBwZXJmLnN0YXRlc1tdIGFjY2Vzcw0KPiA+PiB3aXRoIFhFTl9QWF9JTklUDQo+ID4+DQo+ID4+
IE9uIDI3LjA1LjIwMjUgMTA6NDgsIFBlbm55IFpoZW5nIHdyb3RlOg0KPiA+Pj4gQWNjZXNzaW5n
IHRvIHBlcmYuc3RhdGVzW10gYXJyYXkgc2hhbGwgbm90IGJlIG9ubHkgZ3VhcmRlZCB3aXRoDQo+
ID4+PiB1c2VyLWRlZmluZWQgaHlwZXJjYWxsIGlucHV0LCBzbyB3ZSBhZGQgWEVOX1BYX0lOSVQg
Y2hlY2sgdG8gZ2FpbiBzYWZldHkuDQo+ID4+DQo+ID4+IFdoYXQgaXMgImd1YXJkZWQgd2l0aCB1
c2VyLWRlZmluZWQgaHlwZXJjYWxsIGlucHV0Ij8gQW5kIHdoYXQgc2FmZXR5DQo+ID4+IGFyZSB3
ZSBsYWNraW5nPw0KPiA+Pg0KPiA+Pj4gLS0tIGEveGVuL2RyaXZlcnMvYWNwaS9wbXN0YXQuYw0K
PiA+Pj4gKysrIGIveGVuL2RyaXZlcnMvYWNwaS9wbXN0YXQuYw0KPiA+Pj4gQEAgLTIyOCwxMCAr
MjI4LDEzIEBAIHN0YXRpYyBpbnQgZ2V0X2NwdWZyZXFfcGFyYShzdHJ1Y3QNCj4gPj4+IHhlbl9z
eXNjdGxfcG1fb3ANCj4gPj4gKm9wKQ0KPiA+Pj4gICAgICByZXQgPSBjb3B5X3RvX2d1ZXN0KG9w
LT51LmdldF9wYXJhLmFmZmVjdGVkX2NwdXMsDQo+ID4+PiAgICAgICAgICAgICAgICAgICAgICAg
ICAgZGF0YSwgb3AtPnUuZ2V0X3BhcmEuY3B1X251bSk7DQo+ID4+Pg0KPiA+Pj4gLSAgICBmb3Ig
KCBpID0gMDsgaSA8IG9wLT51LmdldF9wYXJhLmZyZXFfbnVtOyBpKysgKQ0KPiA+Pj4gLSAgICAg
ICAgZGF0YVtpXSA9IHBtcHQtPnBlcmYuc3RhdGVzW2ldLmNvcmVfZnJlcXVlbmN5ICogMTAwMDsN
Cj4gPj4+IC0gICAgcmV0ICs9IGNvcHlfdG9fZ3Vlc3Qob3AtPnUuZ2V0X3BhcmEuc2NhbGluZ19h
dmFpbGFibGVfZnJlcXVlbmNpZXMsDQo+ID4+PiAtICAgICAgICAgICAgICAgICAgICAgICAgIGRh
dGEsIG9wLT51LmdldF9wYXJhLmZyZXFfbnVtKTsNCj4gPj4+ICsgICAgaWYgKCBwbXB0LT5wZXJm
LmluaXQgJiBYRU5fUFhfSU5JVCApDQo+ID4+PiArICAgIHsNCj4gPj4+ICsgICAgICAgIGZvciAo
IGkgPSAwOyBpIDwgb3AtPnUuZ2V0X3BhcmEuZnJlcV9udW07IGkrKyApDQo+ID4+PiArICAgICAg
ICAgICAgZGF0YVtpXSA9IHBtcHQtPnBlcmYuc3RhdGVzW2ldLmNvcmVfZnJlcXVlbmN5ICogMTAw
MDsNCj4gPj4+ICsgICAgICAgIHJldCArPSBjb3B5X3RvX2d1ZXN0KG9wLT51LmdldF9wYXJhLnNj
YWxpbmdfYXZhaWxhYmxlX2ZyZXF1ZW5jaWVzLA0KPiA+Pj4gKyAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgZGF0YSwgb3AtPnUuZ2V0X3BhcmEuZnJlcV9udW0pOw0KPiA+Pj4gKyAgICB9DQo+
ID4+DQo+ID4+IEdvaW5nIGZyb20ganVzdCB0aGUgY29kZSBjaGFuZ2U6IFlvdSB3YW50IHRvIGF2
b2lkIGNvcHlpbmcgb3V0DQo+ID4+IGZyZXF1ZW5jeSB2YWx1ZXMgd2hlbiBub25lIGhhdmUgYmVl
biByZXBvcnRlZD8gQnV0IHdoZW4gbm9uZSBoYXZlDQo+ID4+IGJlZW4gcmVwb3J0ZWQsIGlzbid0
IHBtcHQtDQo+ID4+PiBwZXJmLnN0YXRlX2NvdW50IChhZ2FpbnN0IHdoaWNoIG9wLT51LmdldF9w
YXJhLmZyZXFfbnVtIHdhcw0KPiA+PiB2YWxpZGF0ZWQpIHNpbXBseSBnb2luZyB0byBiZSAwPyBJ
ZiBub3QsIGhvdyB3b3VsZCBjYWxsZXJzIGtub3cgdGhhdA0KPiA+PiBubyBkYXRhIHdhcyBoYW5k
ZWQgYmFjayB0byB0aGVtPw0KPiA+DQo+ID4gSSBtYXkgbWlzdW5kZXJzdGFuZCB3aGF0IHlvdSd2
ZSBjb21tZW50ZWQgb24gdjQgcGF0Y2ggInRvb2xzL3hlbnBtOg0KPiA+IFByaW50IENQUEMgcGFy
YW1ldGVycyBmb3IgYW1kLWNwcGMgZHJpdmVyIiwgcXVvdGluZyB0aGUgZGlzY3Vzc2lvbiB0aGVy
ZSwgIg0KPiA+IFRoaXMgbG9va3MgcXVlc3Rpb25hYmxlIGFsbCBvbiBpdHMgb3duLiBXaGVyZSBp
cyBpdCB0aGF0IC0+cGVyZi5zdGF0ZXMNCj4gPiBhbGxvY2F0aW9uIGlzIGJlaW5nIGF2b2lkZWQ/
IEkgZmlyc3QgdGhvdWdodCBpdCBtaWdodCBiZSBwYXRjaCAwNg0KPiA+IHdoaWNoIGlzIHJlbGF0
ZWQsIGJ1dCB0aGF0IGRvZXNuJ3QgbG9vayB0byBiZSBpdC4gSW4gYW55IGV2ZW50IGZ1cnRoZXIN
Cj4gPiBkb3duIGZyb20gaGVyZSB0aGVyZSBpcw0KPiA+DQo+ID4gICAgIGZvciAoIGkgPSAwOyBp
IDwgb3AtPnUuZ2V0X3BhcmEuZnJlcV9udW07IGkrKyApDQo+ID4gICAgICAgICBkYXRhW2ldID0g
cG1wdC0+cGVyZi5zdGF0ZXNbaV0uY29yZV9mcmVxdWVuY3kgKiAxMDAwOw0KPiA+DQo+ID4gaS5l
LiBhbiBhY2Nlc3MgdG8gdGhlIGFycmF5IHNvbGVseSBiYXNlZCBvbiBoeXBlcmNhbGwgaW5wdXQu
DQo+ID4gIg0KPiA+IEkgdGhvdWdodCB3ZSB3ZXJlIGluZGljYXRpbmcgYSBzY2VuYXJpbywgdXNl
ciBhY2NpZGVudGFsbHkgd3JpdGVzIHRoZQ0KPiA+ICJvcC0+dS5nZXRfcGFyYS5mcmVxX251bSAi
LCBhbmQgaXQgbGVhZHMgdG8gYWNjZXNzaW5nIG91dC1vZi1yYW5nZQ0KPiA+IGFycmF5IHNsb3Qg
aW4gQ1BQQyBtb2RlLiBUaGF0J3MgdGhlIHJlYXNvbiB3aHkgSSBhZGRlZCB0aGlzIGd1YXJkDQo+
DQo+IFdlbGwsIGl0J3Mgbm90IGFuIG91dC1vZi1yYW5nZSBhY2Nlc3MsIGJ1dCBhIE5VTEwgZGVy
ZWYsIGJ1dCB5ZXMsIHRoZSBjb25jZXJuIHZvaWNlZA0KPiB0aGVyZSBpcyByZWxhdGVkLiBCdXQg
dGhhdCBjYW4ndCBiZSBkb25lIGluIGFuIGlzb2xhdGVkIHBhdGNoLCBpdCBtYWtlcyBzZW5zZSBv
bmx5DQo+IHRvZ2V0aGVyIHdpdGggdGhlIGNoYW5nZSB0byB0aGUgaWYoKSB0aGF0IEkgZGlkIGNv
bW1lbnQgb24uIEFuZCBldmVuIHRoZW4gaWYgaXQgaXMNCj4gZ3VhcmFudGVlZCB0aGF0IHBlcmYu
c3RhdGVfY291bnQgaXMgYWx3YXlzIDAgd2hlbiBwZXJmLnN0YXRlcyBpcyBOVUxMLCB3ZSdkIGJl
IGZpbmUNCj4gd2l0aG91dCBhbnkgY2hhbmdlLiBZZXQgdGhpcyBsYXR0ZXIgYXNwZWN0IGdvZXMg
YmFjayB0byB0aGUgcXVlc3Rpb24gSSBoYWQgcmFpc2VkDQo+IHRoZXJlOiAiV2hlcmUgaXMgaXQg
dGhhdCAtPnBlcmYuc3RhdGVzIGFsbG9jYXRpb24gaXMgYmVpbmcgYXZvaWRlZD8iDQo+DQoNCi0+
cGVyZi5zdGF0ZXMgaXMgYWxsb2NhdGVkIGluIHNldF9weF9wbWluZm8oKSwgd2hpY2ggaXMgYSBw
eC1zcGVjaWZpYyBmdW5jdGlvbi4NCkluIHRoZSBjYWxsZXIgb2Ygc2V0X3B4X3BtaW5mbygpLCB3
ZSBoYXZlIGFzc2VydGlvbiAiQVNTRVJUKCEoeGVuX3Byb2Nlc3Nvcl9wbWJpdHMgJiBYRU5fUFJP
Q0VTU09SX1BNX0NQUEMpKTsiDQp0byBlbnN1cmUgaXQgd2lsbCBub3QgYmUgaW52b2tlZCBpbiBD
UFBDIG1vZGUuDQoNCkFuc3dlcmluZyIgQW5kIGV2ZW4gdGhlbiBpZiBpdCBpcyAgZ3VhcmFudGVl
ZCB0aGF0IHBlcmYuc3RhdGVfY291bnQgaXMgYWx3YXlzIDAgd2hlbiBwZXJmLnN0YXRlcyBpcyBO
VUxMIiwgbWF5YmUgd2Ugc2hhbGwgYWRkIGFub3RoZXIgY2hlY2sNCmluIHRoZSB2ZXJ5IGJlZ2lu
bmluZyBvZiBnZXRfY3B1ZnJlcV9wYXJhKCk6DQpgYGANCmlmICggIXBtcHQgfHwgKChwbXB0LT5p
bml0ICYgWEVOX1BYX0lOSVQpICYmICFwbXB0LT5wZXJmLnN0YXRlcykgfHwgKChwbXB0LT5pbml0
ICYgWEVOX0NQUENfSU5JVCkgJiYgcG1wdC0+cGVyZi5zdGF0ZV9jb3VudCkpDQpgYGANCldlIGFy
ZSBlbnN1cmluZyBpbiBDUFBDIG1vZGUsIC0+cGVyZi5zdGF0ZV9jb3VudCBtdXN0IGJlIHplcm8s
IHRoZW4gb3AtPnUuZ2V0X3BhcmEuZnJlcV9udW0gaXMgdmFsaWRhdGVkIGFnYWluc3QgaXQsIHdl
IHdpbGwNCm5ldmVyIGVudGVyIGludG8gdGhlIGxvb3AuLi4NCg0KQW5kIGlmIHdlJ3JlIG9rYXkg
d2l0aCBhYm92ZSBjaGFuZ2UsIHJpZ2h0LCBpdCBzaGFsbCBub3QgYmUgZG9uZSBpbiBhbiBpc29s
YXRlZCBwYXRjaCwgYW5kIGl0IHNoYWxsIGJlIGFkZGVkIG9ubHkgdG9nZXRoZXIgd2l0aCB0aGUg
Y2hhbmdlIHRvIHRoZSBpZigpDQoNCj4gPiBCdWl0IGFzIHlvdSBzYWlkIGF0IHRoZSB2ZXJ5IGJl
Z2lubmluZywgIG9wLT51LmdldF9wYXJhLmZyZXFfbnVtIGlzIHZhbGlkYXRlZA0KPiBhZ2FpbnN0
IHBtcHQtPnBlcmYuc3RhdGVfY291bnQsIHNvIGlnIHRoZSBhYm92ZSBzY2VuYXJpbyB3aWxsIG5v
dCBoYXBwZW4sIEknbGwgZGVsZXRlDQo+IHRoaXMgY29tbWl0Lg0KPg0KPiBOb3Qgc3VyZSB5ZXQg
d2hldGhlciBkZWxldGluZyBpcyB0aGUgcmlnaHQgY291cnNlIG9mIGFjdGlvbi4NCj4NCj4gSmFu
DQo=


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 04:12:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 04:12:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017668.1394657 (Exim 4.92)
	(envelope-from )
	id 1uRNgf-0003Tq-Nm; Tue, 17 Jun 2025 04:12:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017668.1394657; Tue, 17 Jun 2025 04: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 1uRNgf-0003Tj-Kn; Tue, 17 Jun 2025 04:12:41 +0000
Received: by outflank-mailman (input) for mailman id 1017668;
 Tue, 17 Jun 2025 04:12: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 1uRNge-0003Td-DU
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 04:12:40 +0000
Received: from NAM02-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam02on20602.outbound.protection.outlook.com
 [2a01:111:f403:2405::602])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4e32598b-4b31-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 06:12:38 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 IA1PR12MB6163.namprd12.prod.outlook.com (2603:10b6:208:3e9::22) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Tue, 17 Jun
 2025 04:12:35 +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.8835.027; Tue, 17 Jun 2025
 04:12: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: 4e32598b-4b31-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ZduzlPCuMu9rBrvqPJk6WNEj1s2tUYX00TKjDRlXH7Fubsi3yVSTOn16PzptDvhnVCpS2PBf7oIrGPt6xaR2viiYK/EBcB6sXgn3K17lyootqPrgd9tqWu2NORj5ZrhekUZuxbiQ1CTGDFm+W3ZhHppHKV/X9vI/Hv2BuJ8AR01XFwH2fJbKR1/dH7hWwYSz/8WrxetmYkt6DIjyXonvbyCGwrtK94Y2DQh9sBRTuzleeQakITCyMxq16MSz6KDCEouxsqBN5cy/iiSeApfJM+qVAkr+fPFEFbJyi3eCNjbkGPhiZVVG9TLXoNBihDnQufq0PN++kQ1FV1cIBPa1wg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Zk0xlGTq5pzlkgXqyM5YgTpnYBf/brnDSmoj+Cn1hdE=;
 b=j4JULHu125lEUL2dxoKHPfqaBuzx2V+7RUAn2JtZ/n9ztwK54IFWSB+wfK8MhIFMyv53zFw91FZ2f8rtJQZIc1skH+m4Jnhb4MUM3OWud3tYtmadsn2FXf1sTrhHYMkRZZQffnGt4SlnFfhiDUiu9P+hTEhigspZpzCRLTn2g3eNIpPaFUvAPBEbKXzL/3e6omeX7/tCK+XL5+DpyWh/Eh3oOlogirrHGbniteLfm+R+LsMUeoiyHDW+ljUzn0/oK7YrlSo6ho9FIrf5P2rWQCw12VcDiX1JmcvTriIlgoUrGm8kheyLwRw0MO5QatVQCzUHKNbzjlitBe+c4MFC/Q==
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=Zk0xlGTq5pzlkgXqyM5YgTpnYBf/brnDSmoj+Cn1hdE=;
 b=Y1yVxSTz3wflF5aTzmcr3ikDcFzXDtLEKeGXUr89D4C4Pn4HD7YQ9p8+ua2NrTpm9VHTLFmvKe3JjDnW49cOtGhjsgdL4coPFiQ6YSFU+pNu4QN8r5d8K/tvrg4bU9BSkxKk/mwA+aL4E3Pqy05Cm5x6/ViGjU26W9g63Dply3s=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v5 03/18] xen/cpufreq: extract _PSD info from "struct
 xen_processor_performance"
Thread-Topic: [PATCH v5 03/18] xen/cpufreq: extract _PSD info from "struct
 xen_processor_performance"
Thread-Index: AQHbzuQ7tkLRAfE4aEeQu239amEhMrP+LqUAgAdzEsCAAAj3gIABLclw
Date: Tue, 17 Jun 2025 04:12:35 +0000
Message-ID:
 
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-4-Penny.Zheng@amd.com>
 <005a0e3a-dc8f-480f-8bb9-fd8eb164eb02@suse.com>
 
 <824a8aa5-c603-47e8-8688-a324152329a9@suse.com>
In-Reply-To: <824a8aa5-c603-47e8-8688-a324152329a9@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=True;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-06-17T04:12:28.0000000Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=3;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged
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_|IA1PR12MB6163:EE_
x-ms-office365-filtering-correlation-id: ce2b4d42-c7e2-4a5b-ae63-08ddad55304c
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?TzNJNndmblUzWWMrd1dWWlVqTVBXZ3l2d3VIYlFjSkgraUozakJuNmtTOVBX?=
 =?utf-8?B?TytYbVYvQzBvdEVWMHVjbHdBbFE4c1dmTllxdTNjRE11MVdleGl2K2xyOXlB?=
 =?utf-8?B?b05kakJXZm9rL1QvcGE0RVc3MktzbS9SNnVpNGVPcjlSR1FJeXdsemxmYi92?=
 =?utf-8?B?VmpnOTIyb3Z2L3NlMWNxcFdzeUpvL0pvbEhpSkEzQkNLVVlqRWRUajdONjQ4?=
 =?utf-8?B?Z3A0czRJUVY0MlZFSEN3OWJ2YUxIWnpLVnRsSlpHOG1oenFkZ3BXRklNOFlj?=
 =?utf-8?B?WGQyU2VtalUrSkR5ejN3QTljME5Zc2MyWllKNEduNTJlZStNeDRVS3pqUDFF?=
 =?utf-8?B?bUU1RUVuNkM0MGN0dVNoeWRzRHYvYTBGSE5XVjJjWlU2eGdta1dTbGFuaGNC?=
 =?utf-8?B?TldmclpTUVBBaElBVWp0WnFFb1grenJlcTRwcEVUU292UEp4aFJEOFpkRUMv?=
 =?utf-8?B?SFlwTHBsbVVVQkhla25RcUU3VmUrc042TnZoNVJpUE5Cb05nTGhaWDA5bnkv?=
 =?utf-8?B?ck5LaFkwRGloM3lPZjJIMUJZWnZrVTIvMlFXSDU3U2hDdXMvTVpZM1YxOG9T?=
 =?utf-8?B?TDMrWjBWbFB0QU9yeWZsZlhsRzEvM1pSNFZYUkFjWjNLTThmTTdlelV3Zlk3?=
 =?utf-8?B?eWlPR0cxOG9JcmJsTU9hSTNvbXRXUCtHclJ0QmJGV0R3Qm1HUHR5SHAvVU8v?=
 =?utf-8?B?ZW4xaEkxZjV4WE0xaXRCbjIxbEh5UFJQUnQya2FTTDNjMDhkNnlqVXRKd3FQ?=
 =?utf-8?B?SGdjL3dwdSs2by9UM3hHZUtYZC81cjZSMXMyVytMWitrbDBkY1EreUF2UDlR?=
 =?utf-8?B?L3dQanVVdVRyNGRRa3k3Vlp4ZjczTVgwUkczQnBYZnFBeFBpbFQzY3dNRERx?=
 =?utf-8?B?SHlGMGRZNFhqZlQrY2hLSURJaitGUmpabDByNWtMWE1ENlFoZmU0M1JYTnVH?=
 =?utf-8?B?WlVGSzN3enl6K2VYMFNNalVjYmhzRDR2cDV3MSswWXF5N2ZZT1lRdEVnZ0RR?=
 =?utf-8?B?RlhwMjdOa2huV21BV25yb2ZETVFNbTU1aUZhcWE4N095Q3RVaE8zQVVnT3cz?=
 =?utf-8?B?bnVIVmsvNytsTjNrK2lhYXZUQkJlUjVCaWJpUUZRZTBoZW9rU2lzejIzV3BP?=
 =?utf-8?B?K201aDBZcVlhL2RxaGl2MDJFSlJYc1ozSzdqM3N5V1Nza3grcnQ3NFlVaUl6?=
 =?utf-8?B?ZWkxdlRkM3piREl5L0ZPalc0aUg2WnhSeE5ndXN4UjdicFdDQmNTc093M21S?=
 =?utf-8?B?STl4MFFIbXlWZXdHR3BvbFpFNWxQbmc0M2UwT0pGWlBKQ1UvcEZ5dy9Rb00z?=
 =?utf-8?B?N2pMWHdBb3JiMWlQUWhYY1o2RHRXR1h2YnJ5dWhGZnZGRjlKT3dQNS9GWUpZ?=
 =?utf-8?B?VWNUbjJ5WUZSazhIbTk2dFdmVzVxbmh5QjFaenI1VzAvQ042T1JDTXVadGNS?=
 =?utf-8?B?ZnNtZ1k5M2ZZeFRkU1dGekNBRGc3Qm42dTdsUG5vOVdmYW1NRm9QcmpURlk2?=
 =?utf-8?B?OFFIZ1VyaHJHbHR5WW0xaUtHZU90ckN0SXk5OHQxQXA0aG5LejVjMXpIaEpH?=
 =?utf-8?B?UjZ0TWZxMUdGS3VETjQ5Vll2MHR4K3dhYWk0dVY3Yzk3b295NUx2eEFaNll2?=
 =?utf-8?B?TEYvSXhBN0hSRnNJY1UvWEVMaHV1bXJoRmZobVI2dVZXNWZiRFlTK040ODkx?=
 =?utf-8?B?MmM1S0VVWU5rRitsR1BxR2RoYnlJUTAzSFdvMjVhNko5bjNKdkRwRUROSHdF?=
 =?utf-8?B?aTFKZklMb25mRkVVZFpYUjZ0bVIwUjFCTzAvTlBNK2NYSUpWQ2ZHazZjeUx6?=
 =?utf-8?B?bXZlSnJ2QzV4ZXY4MzN2dmJXcWVJRU50M3AzczVOeXI2cFhJWkpVL1hBbjQ3?=
 =?utf-8?B?d1NGVmxmT2RJS2RTZUluUE81UGUvM29PQWlrMnc4QnQ3MDlWRlJLYmR1YlFO?=
 =?utf-8?B?aVBpVTFEZ3g5RmJCVDV4ejAwVEtjRUVWV2d2aU85MHVmZTVTenJQS0dudTlt?=
 =?utf-8?Q?hrWU4pCVjT+yOqLl8tzX7S8U42Sqak=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?SWtpRUl2SHdGd2JWY0k3YXprcjJwSUdaZGJaVms3YTBicWlKd05uSWhJcE14?=
 =?utf-8?B?NE45MzF6Q1VwYkdmaE44NXBQVlNPcGV4eGVtaWlFT2licTdJdXlrRVoxU253?=
 =?utf-8?B?S3d4NUg5N21RRmFDWFVaVnd5bGR1RjhTbVV2UENiK2MzbnZvNkI2TmxmVHJL?=
 =?utf-8?B?U1hsbXNHVk1RYmRFRFVwaWhPdkV1bkdaeW41U3NrdjF4WFUyaFlwN0U4U0pN?=
 =?utf-8?B?V1pyS3FsWGxHa09oUmF1SVNwYlB0T3ZvOEdBUkpIRDdybjZBMXZhUHNYVm1X?=
 =?utf-8?B?dWswN2tqdFRCNnBnMU1qbkxuZ00zbWw0V1VnMFZzTmpmVld4SHdubWFOUEdS?=
 =?utf-8?B?d0VKc3R5dHRYVE5jQzdiaDNqUkR5M20xVFc3M3dkRGtPMTQyZWpHN2xVVDJ4?=
 =?utf-8?B?eVhUV2NiSS9pRmo4SWZnVy8zcW5IblhyV0hiRE9Md0k4WHlscDJyYnA0YTU0?=
 =?utf-8?B?eEk4OGx6bHo4V2lWZXkzVUYvY0tnRXh3dm1BcFRsemErNkYxTDFUTGtSY0tj?=
 =?utf-8?B?K2QrTm00RHEveEE3TEJrU2FTdWZTaCs4S0M0K0Y1VVBGSW1CVktYcVQ5bG9E?=
 =?utf-8?B?MEd4ZnFleHpLNW16M1NER0tpTlZKa0ZyTXNuZ3V4YzM2a2I5RUlCeENSZjY2?=
 =?utf-8?B?djJBWVJSckMxb2l1K0ZHUTNqSnVudUhjbW4yWWxySjdaRjNiTmFHL1dBTWIz?=
 =?utf-8?B?VDN6QzlCSytIWmtGTnViUmxacktValdwT0YwNEJ0ZWRMNHVnNWlUTlV1UnNs?=
 =?utf-8?B?RWhUcS8rdnY0bkZCOHlVU09mTEVHNmRGMmdzTVpjZUdlU3pZYk9WUWRVdmp2?=
 =?utf-8?B?U0tlRkdRVXhaQktJdnYrY2cwYVVlM0xBRldESEJqUWhYb1VpTVM0T2FVT3di?=
 =?utf-8?B?aDlqVjFxdk8vWmovZmdhRDBUUzVveVlJMEYxL3JXaDRwMWRJU2FrazJjL3pL?=
 =?utf-8?B?eXNabDFCUnJPVWJpY2N2MkR3SzEyZUxJZm5yYzIya2xDYk5BUDdOVzlvbnhH?=
 =?utf-8?B?TEpqMFZGcFpuc3Nia2RKOE14VFVEL2s4eE5Zb0hWZ3FvdllmOEQyUHZyTDNE?=
 =?utf-8?B?djZKNnJQSnlZVHk4SDluL2gwSFloN1ZDeGU1bnYyckxZVlRMaEFXL0xwNjJP?=
 =?utf-8?B?WWdMMXZPWVpTQWR6NnMyOHUrd09MeVFSN1NtMzVOOWRLeUMxWHI1M0J5VGRl?=
 =?utf-8?B?YzNEQTN5TlVycnZHQXJDWEd0RTl2VkdpL3RhL2NPSnZHOGY2NGFicTZ1ODlz?=
 =?utf-8?B?L2RyY0N4UE5rWWJMMTJWajI1aHJERUQrWU93eTgrZDVKUDZ3V2Nuanlzc09N?=
 =?utf-8?B?R1FMYklFclhJOWNGSXhBZzFwOGNOSnVnbGVRakZ5S1MxUElLYmZxUDdkZzJm?=
 =?utf-8?B?OG9WcE5qNmJ3Nmx5UEFlNW1vVzNaL3lOOTYxWjdZaHNONWw1clB3SHpoeDQz?=
 =?utf-8?B?Qzd0bTNBelhZcTErd3c1MmtlOTBBUUx4bDZGQWlNRFF6R0pTUjIzTUNvb2lp?=
 =?utf-8?B?THhGaERKYlN6Q2RHeTQ2M203WjBJeU9XWHBSUXZmUTFIOXBxR3EzZEFrUGQ1?=
 =?utf-8?B?UUppWElPOVFIT1lvckQzcWJ2SVlsOVBvTjJBQUhET0lwRGhYd2c2MWJVeTV4?=
 =?utf-8?B?RWl3VDZwd3AzUGl0UUQ2YXVxN0JwYWNhckUrRXlWc2UrZ0lFV3oxR3V2SFVE?=
 =?utf-8?B?UlZvUnNpMXVPNVRRTXJvdXBaNjV4SHVjb0lyQ2NRVHlsbWZkQmlMbVZyOEhJ?=
 =?utf-8?B?NjgwQzdicDhTbVJSajQrYTZ2L0V5MXlzb0lreExjQnU3OUpNbjFkTU9VWTNM?=
 =?utf-8?B?THhFY2MzeXhHZktnbldhRy9rTGlsWlIzQjFDM2JjMjM5UXM3dGNqdXA4U2dJ?=
 =?utf-8?B?RW50bWhRUXR6Y2Jma1hDMVkwZXRlWDF0NDFRVmtYbFRZSHBqa3l5ZEgrU2pr?=
 =?utf-8?B?SzUyMnRadEVvRFlQbllKdEkwOWZHR3k3MFJQcHcyenhYSkY0QTBtZ00zeUx0?=
 =?utf-8?B?dkVFMWdTYTBreXpDeTBzK3IwVmYwSk1ZVCtGRjkvUk1ERlJGbWRNUmtreXdr?=
 =?utf-8?B?amxwNWFPRUFpWENNTVZFeU42N0JWRVI0NkwyTDBmK1Zob2VEYWxrY1RhTE05?=
 =?utf-8?Q?lVh4=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: ce2b4d42-c7e2-4a5b-ae63-08ddad55304c
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2025 04:12:35.0346
 (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: QZXg6+XqLJ1W70yjwulvj8mLdQshggCumJWPRuebpUlY3IOdEHcaxKksStlW78wnibuZ3yRYkW6bppVcmrKREQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB6163

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IE1vbmRheSwgSnVuZSAxNiwgMjAyNSA1
OjUxIFBNDQo+IFRvOiBQZW5ueSwgWmhlbmcgPHBlbm55LnpoZW5nQGFtZC5jb20+DQo+IENjOiBI
dWFuZywgUmF5IDxSYXkuSHVhbmdAYW1kLmNvbT47IHhlbi1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0
Lm9yZw0KPiBTdWJqZWN0OiBSZTogW1BBVENIIHY1IDAzLzE4XSB4ZW4vY3B1ZnJlcTogZXh0cmFj
dCBfUFNEIGluZm8gZnJvbSAic3RydWN0DQo+IHhlbl9wcm9jZXNzb3JfcGVyZm9ybWFuY2UiDQo+
DQo+IE9uIDE2LjA2LjIwMjUgMTE6NDMsIFBlbm55LCBaaGVuZyB3cm90ZToNCj4gPiBbUHVibGlj
XQ0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IEphbiBC
ZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4NCj4gPj4gU2VudDogV2VkbmVzZGF5LCBKdW5lIDEx
LCAyMDI1IDExOjM0IFBNDQo+ID4+IFRvOiBQZW5ueSwgWmhlbmcgPHBlbm55LnpoZW5nQGFtZC5j
b20+DQo+ID4+IENjOiBIdWFuZywgUmF5IDxSYXkuSHVhbmdAYW1kLmNvbT47IHhlbi1kZXZlbEBs
aXN0cy54ZW5wcm9qZWN0Lm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogW1BBVENIIHY1IDAzLzE4XSB4
ZW4vY3B1ZnJlcTogZXh0cmFjdCBfUFNEIGluZm8gZnJvbQ0KPiA+PiAic3RydWN0IHhlbl9wcm9j
ZXNzb3JfcGVyZm9ybWFuY2UiDQo+ID4+DQo+ID4+IE9uIDI3LjA1LjIwMjUgMTA6NDgsIFBlbm55
IFpoZW5nIHdyb3RlOg0KPiA+Pj4gQEAgLTU0NSwxNCArNTk3LDkgQEAgaW50IHNldF9weF9wbWlu
Zm8odWludDMyX3QgYWNwaV9pZCwgc3RydWN0DQo+ID4+PiB4ZW5fcHJvY2Vzc29yX3BlcmZvcm1h
bmNlICpwZXJmKQ0KPiA+Pj4NCj4gPj4+ICAgICAgaWYgKCBwZXJmLT5mbGFncyAmIFhFTl9QWF9Q
U0QgKQ0KPiA+Pj4gICAgICB7DQo+ID4+PiAtICAgICAgICAvKiBjaGVjayBkb21haW4gY29vcmRp
bmF0aW9uICovDQo+ID4+PiAtICAgICAgICBpZiAoIHBlcmYtPnNoYXJlZF90eXBlICE9IENQVUZS
RVFfU0hBUkVEX1RZUEVfQUxMICYmDQo+ID4+PiAtICAgICAgICAgICAgIHBlcmYtPnNoYXJlZF90
eXBlICE9IENQVUZSRVFfU0hBUkVEX1RZUEVfQU5ZICYmDQo+ID4+PiAtICAgICAgICAgICAgIHBl
cmYtPnNoYXJlZF90eXBlICE9IENQVUZSRVFfU0hBUkVEX1RZUEVfSFcgKQ0KPiA+Pj4gLSAgICAg
ICAgew0KPiA+Pj4gLSAgICAgICAgICAgIHJldCA9IC1FSU5WQUw7DQo+ID4+PiArICAgICAgICBy
ZXQgPSBjaGVja19wc2RfcG1pbmZvKHBlcmYtPnNoYXJlZF90eXBlKTsNCj4gPj4+ICsgICAgICAg
IGlmICggcmV0ICkNCj4gPj4+ICAgICAgICAgICAgICBnb3RvIG91dDsNCj4gPj4+IC0gICAgICAg
IH0NCj4gPj4+DQo+ID4+PiAgICAgICAgICBweHB0LT5zaGFyZWRfdHlwZSA9IHBlcmYtPnNoYXJl
ZF90eXBlOw0KPiA+Pj4gICAgICAgICAgbWVtY3B5KCZweHB0LT5kb21haW5faW5mbywgJnBlcmYt
PmRvbWFpbl9pbmZvLA0KPiA+Pg0KPiA+PiAuLi4gdGhlIG5lZWQgZm9yIHRoaXMgY2hhbmdlLiBB
bmQgZXZlbiBpZiB0aGVyZSBpcyBhIG5lZWQsIGENCj4gPj4gZm9sbG93LW9uIHF1ZXN0aW9uIHdv
dWxkIGJlIGhvdyB0aGlzIHJlbGF0ZXMgdG8gdGhlIHN1YmplY3Qgb2YgdGhpcyBwYXRjaC4NCj4g
Pg0KPiA+IEkgZXh0cmFjdGVkIHRoaXMgc25pcHBldCBvdXQgZm9yIHNoYXJpbmcgdGhlIHNhbWUg
Y2hlY2tpbmcgbG9naWMgYm90aA0KPiA+IGluIFB4IGFuZCBsYXRlciBDUFBDLiBUaGV5IGJvdGgg
bmVlZCBfUFNEIGluZm8NCj4NCj4gUmlnaHQsIGFuZCB0aGF0IChpaXJjKSBiZWNvbWVzIHZpc2li
bGUgbGF0ZXIgaW4gdGhlIHNlcmllcy4gQnV0IGl0IG5lZWRzIHNheWluZyBoZXJlLiBBcw0KPiBp
dCBzdGFuZHMgdGhlIGRlc2NyaXB0aW9uIHRhbGtzIG9mIG9ubHkgZ2V0X3BzZF9pbmZvKCkgcmln
aHQgbm93LiBBbmQgdGhlIGNoYW5nZQ0KPiBhYm92ZSBpcyBhbHNvIHVucmVsYXRlZCB0byB0aGUg
ImV4dHJhY3QiIG1lbnRpb25lZCBpbiB0aGUgdGl0bGUuDQo+DQo+ID4gSSBjb3VsZCBjaGFuZ2Ug
dGl0bGUgdG8gInhlbi9jcHVmcmVxOiBtYWtlIF9QU0QgaW5mbyBjb21tb24iIGFuZCBhbHNvDQo+
ID4gYWRkIGRlc2NyaXB0aW9uIGluIGNvbW1pdCBtZXNzYWdlIGZvciBpbnRyb2R1Y2luZyBjaGVj
a19wc2RfcG1pbmZvKCkNCj4NCj4gVGhlIHRpdGxlIHdhcyBwcm9iYWJseSBmaW5lOyBpdCdzIHRo
ZSBkZXNjcmlwdGlvbiB3aGljaCB3YXMgbGFja2luZy4gSW4gZmFjdCBJJ2QgZGVlbQ0KPiAibWFr
ZSAuLi4gY29tbW9uIiBtaXNsZWFkaW5nIHdoZW4gdGhlcmUncyBubyAybmQgdXNlciAoeWV0KS4N
Cj4NCg0KSG93IGFib3V0Og0KIg0KVGl0bGU6IHhlbi9jcHVmcmVxOiBleHBvcnQgX1BTRCBpbmZv
IGFuZCBjaGVja2luZw0KDQpfUFNEIGluZm8sIGNvbnNpc3RlZCBvZiAic2hhcmVkX3R5cGUiIGFu
ZCAic3RydWN0IHhlbl9wc2RfcGFja2FnZSIsIHdpbGwgbm90DQpvbmx5IGJlIHByb3ZpZGVkIGZy
b20gcHgtc3BlY2lmaWMgInN0cnVjdCB4ZW5fcHJvY2Vzc29yX3BlcmZvcm1hbmNlIiwgYnV0IGFs
c28NCmluIENQUEMgZGF0YS4NCg0KSW4gY3B1ZnJlcV9hZGQvZGVsX2NwdSgpLCBhIG5ldyBoZWxw
ZXIgZ2V0X3BzZF9pbmZvKCkgaXMgaW50cm9kdWNlZCB0bw0KZXhwb3J0IF9QU0QgaW5mby4gV2hp
bGUgaW4gc2V0X3B4X3BtaW5mbygpLCBjaGVja19wc2RfcG1pbmZvKCkgaXMgYWxzbyBpbnRyb2R1
Y2VkIHRvDQpleHBvcnQgX1BTRCB2YWx1ZSBjaGVja2luZy4NCmluIHRoZSBtZWFudGltZSwgdGhl
IGZvbGxvd2luZyBzdHlsZSBjb3JyZWN0aW9ucyBnZXQgYXBwbGllZCBhdCB0aGUgc2FtZSB0aW1l
OiAuLi4uLi4uLg0KYGBgDQoNCj4gSmFuDQo=


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 04:19:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 04:19:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017675.1394667 (Exim 4.92)
	(envelope-from )
	id 1uRNmq-00044Y-Dc; Tue, 17 Jun 2025 04:19:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017675.1394667; Tue, 17 Jun 2025 04:19:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRNmq-00044R-9r; Tue, 17 Jun 2025 04:19:04 +0000
Received: by outflank-mailman (input) for mailman id 1017675;
 Tue, 17 Jun 2025 04:19:03 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uRNmp-00044L-Ih
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 04:19:03 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on2060f.outbound.protection.outlook.com
 [2a01:111:f403:2009::60f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 318694a4-4b32-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 06:19:01 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 CH2PR12MB4215.namprd12.prod.outlook.com (2603:10b6:610:ab::24) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8835.29; Tue, 17 Jun 2025 04:18:56 +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.8835.027; Tue, 17 Jun 2025
 04:18: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: 318694a4-4b32-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=op34QFOkeCgV9YNIEKsOBbnKltSfjjhYt2dwmB7TKFSlOarOwX+xiiWU9sJEy0J4hqnc1FOAuHCQD8KMaGwmzp7zfANPZRgAECOtKXTHC6JClhNizuHETaZIWHCk7EsbDpiq20lXWEbmvnpOhbK+Xy6SdueO7R5N5Jr5LF+7LoaSGuPYcWigAsjmmG9PlKLRAvGeVVbWxXhoSCpMbDSmjIMq3RJa53cmnugZ6+W9lRAwTPG3TFyVqpCO2K9h4SgcyKAJyoX+yKvFedi6S1K9/Z0UF6NhRlLN2ZWZLk6ul3FzJOiMLpIwxQd1b3TF89wYYNgmc+mNrjlWW9fBTbKA/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=oIpxpE3uEtt2jbaKBahK6/4JCXHx7Ruvd4JUUf2fhzA=;
 b=sSSVZnpBwThkRTiKLl1AQkmX9CtrisZMnn5IhvmFonpkNQMzYXQ2+1ADQBBAc4Q7TWEvt3pNk8TMzwqMM0bRW/TIT9PdPF+O8vf+m0cjRBhl4RvO4+05++XTzKytwZnKgDKUCs2BbenwOicUHhi5ILjMq7jBHbD6jSi+Vqaf9ynMPEySB60L8M4Syae42YQcD/ukNKco8I0AfQakN06PrA2eYURWVRBCxUZPwMBJZv2TFhjBTp6utdSR5N+b53iFdNwsNRd1InbHtJ9D2L8z73YK2xA7aiYVtbcGkmOnlg9guhPCVvFH5Ztidx/+8pJ01v4liG026VbUdnt01ETHfQ==
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=oIpxpE3uEtt2jbaKBahK6/4JCXHx7Ruvd4JUUf2fhzA=;
 b=G/kJyC8V2J2aHk6eHz2AUgSCDFzXvnwy7vvXd5R/snhndrOs6gf+hWZk2KYGxG2RIIG5TtbGBTjsBsflOrKYdGCVQDeu6XWh2csvK5+6oljHN6kQ7XA2ImCd/5vN3F/Ck+pQZvy9LnKHASg0QTe2F5fzwrncq1vWvP7D9y449Xk=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Andrew Cooper
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Anthony PERARD , "Orzel,
 Michal" , Julien Grall , Stefano
 Stabellini , "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v5 04/18] xen/cpufreq: introduce new sub-hypercall to
 propagate CPPC data
Thread-Topic: [PATCH v5 04/18] xen/cpufreq: introduce new sub-hypercall to
 propagate CPPC data
Thread-Index: AQHbzuQ+jriHLS/NnEiww9yxRz3NOrP+OOqAgAdvjjA=
Date: Tue, 17 Jun 2025 04:18:55 +0000
Message-ID:
 
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-5-Penny.Zheng@amd.com>
 <0de0ea5c-64c9-4ac8-8e76-750cb3036419@suse.com>
In-Reply-To: <0de0ea5c-64c9-4ac8-8e76-750cb3036419@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=True;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-06-17T04:18:48.0000000Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=3;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged
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_|CH2PR12MB4215:EE_
x-ms-office365-filtering-correlation-id: 34c71ab7-bc2d-48a7-baa8-08ddad56133c
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?T2doa3NRMjhMSmpHOVQzM01xa3E2RHNkUVM1bTdJVmZBeXQwVVZYcmY1Zm9p?=
 =?utf-8?B?czcwVHhxVC9PNUtROC9nM3dCNXd1WmhZL1VucTNEeEQ3S0NiaDZFT2Jya3ov?=
 =?utf-8?B?ZG02cVUvQzloY0EvZnQ5c0tLeEV0cmtxU0trSUNqWHd6SlZwODJ4dDNIZysw?=
 =?utf-8?B?UlI2V3BGNFZubStTY1g5SzB0TXhhT3lLcnBGT0MrN05OU0VYVW1nY1E4bEI4?=
 =?utf-8?B?ZmZiZzI0YTdadWtJeG96Y0hsUEsxQVV6RldLSGlieEo1N3dMWE9TdnBJSTZa?=
 =?utf-8?B?VmdQTDdoNHRTYjdCbG9LZElWTHJRb0ZwMjhUYXFGWEJxbStEMFgzam9BZnp0?=
 =?utf-8?B?SXVxNXdkSFJmUDM1TjJ1d29zaENuTDV3dTQ4c1liSDRUdEwvU3l1OEZROTZo?=
 =?utf-8?B?MXdIUEJCMFdhOThWTERhZnFtY1kzZXEvR0JLODV3a0c0dkF5alo2KzlxR3VY?=
 =?utf-8?B?Tm1iaFBJeFhOTGMrL2xHL1FpRmFZWFhoTzYxMlJMak5ha0FIak1MVXdnZVE0?=
 =?utf-8?B?bmlNWHFvM1hjTUlJR1JTb05ESXF2Wm9GcWYrUzZJNG1VSE9SS2x1eDZEdi9Q?=
 =?utf-8?B?dnRFYXNacG9Xc0VndnNyWld5bkMwNDI4VkdyclBwdXVPMndvME1Vd3lMMnNX?=
 =?utf-8?B?TytaQ3FWUnp5eWpvVmozY3NiYUIvRDBHcnd2d3BaL0E3UTNCUDNmOThqUWFB?=
 =?utf-8?B?b0lnV0p4YU1qYXFjREluYkV3bDdFaXdra1VKQW9vbFNYMmpuVWNYL0ZtaHJO?=
 =?utf-8?B?cGVTaFlETVVzL2lPd2syZW12cGpFUXh5VGlwWkovN3hURnNFU2pBQ2lLWk1Y?=
 =?utf-8?B?RDl0SC9DWVlkN1RCbXptWm5URkV5SUliZW9obnY4UWNjT1B3bTVTVUEranFm?=
 =?utf-8?B?NEx5MHFHbWZPaG9MS3dKTkRMNURIZy94R3RXVmJsTkc4Z1R2OXlmbXFnNy9T?=
 =?utf-8?B?aHI3OFcwcHpha1EycG5jYmxMOEphWGxIaDNIcG1jUDZXSzVZYkM5VWVFVlVr?=
 =?utf-8?B?OXhEOU1iTmgxY21hV00zU05ZTE5DOU5sa1Z2akwvbEl3SnBOTmEwWW9DQUwx?=
 =?utf-8?B?b1lhUE13VnlrcG5yTW9rbXRXRDdjOVNPb0VocnJmblU4Z1ZKN1h0cVR5S05N?=
 =?utf-8?B?WFZFN0lwcEh1SFR3OEFRcnFyRGtlQVFQL3BkT29yYTVlWWdBcW1rbkExcVRr?=
 =?utf-8?B?MXNIQmNYZXZBVnhScU44UE0vNFhlU3NpNjFiZDRkUGM2YndFSUxOcm9sY3E2?=
 =?utf-8?B?VHNVMDR2QTFTNXhaYlUrVmxUUzBEQ3I3Vzd3TCtWVXdBaUdEbU1tdWNUUWZD?=
 =?utf-8?B?dXJwR1k0OEg5dTkySC9XdExyTTBCck8razYzZXJYKzhVSkhlSFo5QVFtU1Uw?=
 =?utf-8?B?bmtCSjkzM3BaWS9vTE5JSnh1ZWkrVmk0TzhCN1Q0RFowN1JGRWJtenNpbm5y?=
 =?utf-8?B?SnYzazFLS2FVSTlPMWxib3NEU1RXVXM3VHhUZ3IwNm1RdGZKSXFydFZ5Q0Vh?=
 =?utf-8?B?Nzc5VUM2Z05HMHVjVzd4bG1mSzdmclh0VWc5b3AraUtUcTBFWHh2Ym94em50?=
 =?utf-8?B?M2pOZkFwZ1g0Z25PanF6cXlBQ3BlV2tQWUhmVFlCMnNuVUVBNWt0aTJLSXhS?=
 =?utf-8?B?UkZpRjhNbUZxMTd6M2dTVEFnaXprOStkdHJFNGVuelF6WUZaTExSVWpWQnRm?=
 =?utf-8?B?TUZCTm9nb3ZyL0swZGh3RVNGTm1seitMMFR3Rm1uZFlHYllKTUUrUTZoL29R?=
 =?utf-8?B?YjJ3Ti9vWWpGV1lpVW1vb05VQnNIQUw4bWlDT2hIbWhqTWltRXhkdnZTdlRP?=
 =?utf-8?B?Z3FZZExoc1FXcmNKTXdQbjk5a3lRV2ZBOStiV0E1MkdyaXNKazlzRDN5RWMy?=
 =?utf-8?B?L1VremtVV0tkUVF5QlNJb0pOMU1UTDVLREd4N2xEbHNLbGU0WU1VNVdaVmhu?=
 =?utf-8?B?VUtKUi9KTzlQRkY2eUsrTURrRy9wZWtybTlZNGwwdHl1b3JoQjFUMkZYN1ls?=
 =?utf-8?Q?58DDBVaedZi7KusGlCurPFYuEr9rxI=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?d3lWZjdHTkxQcE9iMEEyWFBpOU4vd3JBSUJSUUpaeER0UWdIUnhvb2VleWk1?=
 =?utf-8?B?UlFQdDhOdTJBNjZkc2h5dEE4VldIVzZ4QmVQOXZXS2hVOHhZVjVZZHVUZFhh?=
 =?utf-8?B?dFRCaVlQUmk4TnhjNmgwMEpuWUF1bDg2QzRva2diMTRLdnZhM09rNGFrS09u?=
 =?utf-8?B?QWpJeGNQckpOMDlvclV0R284eS8wMGpwM2prSGZVeXAxOE1pdk1JVkVjbkRD?=
 =?utf-8?B?c2VlaGVWVXdPOWkzTlpJVTZkKzgvVWYwQ2N3NitLRi91LzZsS2dtR2xYVTM4?=
 =?utf-8?B?cXBUVFMvQmZqVkxPVk5wUDJNVnJTUE4vUUFydHFrdjRSeS92MWpaVXFSOFBk?=
 =?utf-8?B?MFBWVmxUS2gyaVhkbDhtSUh5djdTWmZUc3JEaUl0NTFpY3MraHo0YzJNdUhU?=
 =?utf-8?B?KzNucVdQclArZHlOOUNNdWREUWZBTW0wUE1FMHZjYW1ZSjlHNXZGRmRQc0xi?=
 =?utf-8?B?Y2MzQkcwOThQdWExckkvM0ZRcDY1UC85Mm1yRUxxNTdrN2x0VGZQd0JQQlYv?=
 =?utf-8?B?NlNhQnNIUDM5cVpsRFM2anBKWk5aT0ZHbDNqMlFKcjJCWVNqWHN3Wkt0ckgw?=
 =?utf-8?B?RmNCQkl1NE03MGF4QkF1Qy9qTXBMaWJKZmF6MWtCM2V1ZDUzcUZoUFVMNmtN?=
 =?utf-8?B?bU05MVRNc1dUTFRwUTRuaDZVWWxKajFWaUY1T0VaamxoNHlPUjBtTUVLcStJ?=
 =?utf-8?B?WVdyMWNKMk4yQ1pIdjJ0MVdHN1hnUU5odGZRYUVONW1BZFFsR0xENjJZMEZZ?=
 =?utf-8?B?ajZZdmp6V3JwMDFQZWhSWFYrQzJ5N2JjZ2pxd040dlorbmZBb1R1b01aVVBo?=
 =?utf-8?B?MDd1b21lMkZvaXhPVk9jVVRxanZBeGpjaHpxd3ZvR0t4d3BOU0w3enRNZEtu?=
 =?utf-8?B?ZUw4SFdrNFZJd0JGbTJtY2lxUzVBMG1kZks1ZVNnQ1NaL3pkSTBUZ1l1M2pk?=
 =?utf-8?B?U2FYNWE1UWxEeEgyY3lJWGF5Q3FZOVBvN0VyTi9kWkRrVW1EaGZmTlRUSEFk?=
 =?utf-8?B?QU1abnpUUUFabGF2ZkxmbHp5REd3bTBaSUhLOXYwQy9RYUM5aFNJeDJVdXd3?=
 =?utf-8?B?MlVaUFJacVFlMUx3MjZNUzl2b3liUmVXM2NRR2JaaWhSN1UyYkY4N1F6T1lZ?=
 =?utf-8?B?a2h5WEtzMEVPbGhscTNhN0RvS3VLU2dLbEErVW9taE9NaUhTRGkyMnN4Z3V2?=
 =?utf-8?B?UTBObHpsYURXR2wzd0NmUWczNlZSZkVMdDlsMm1YRE5HRFp0aVFGaHB3aS9K?=
 =?utf-8?B?TDVqYXV1WWFxc0Fxa1lsUVZGZ2huY0JGK1BJbGNZRjIxdUNsY1NzRnVEWkky?=
 =?utf-8?B?aStPY2E1eXNVWUtzNW43THNBVndyTzNaZUsxT3FYU2dMcTlJanZDUmxGLzg5?=
 =?utf-8?B?R2NrRDJselRjcWhId3FVVDdNUGl0bGdIbkQ0RkIyQ2RCY1dSWG5XMVZSU2tw?=
 =?utf-8?B?YzlGY1pmSFBhWXJld3o5QkhFcThkSHVRdUFxQWhuaHZ1eGZRM0x3bS9EUDl3?=
 =?utf-8?B?cFpDRTNHT3ZJUUZpQVNiQW5xMHlyNWNuQmdXdW82Q0lDRXZKSjA2MXBnVXk5?=
 =?utf-8?B?TEh3R0E0NDBXTVMxUWhqVkEvNHlxdDFrV0VNd0RJdmNWMmE4WDh6bm1qcWRI?=
 =?utf-8?B?aXBSaVFZUW9CTjdvK2dQbmY2OVVOK2R4TllueGpsYzZJSHJLRWx4UHN4c3JQ?=
 =?utf-8?B?T2FhKzl3WmpaOENrMjJIUnNwL1RDcnNnUnoraUNMZXViL3dEN0s4VytBMGlh?=
 =?utf-8?B?eDhUNTNreFdoYll4LzJEYWg3RnVIa01ROWxmS0R5TXJkZVgwSHVWRnl3cDIx?=
 =?utf-8?B?YUYzU0ZPWExocWw5YkM5SllEYW9BTTF1a0RIek9xZU4vUGkwaDZvbll2UUVN?=
 =?utf-8?B?M0F3cFV2b2hpbEtYeFFvMlZBNDRzNTkrN0x1NzVWbCt2YXF5ZkpVTEJic1NX?=
 =?utf-8?B?NXNPMkRCSTEvZGpvaCsrYXdDZDl2eit2WnQxbThMQklXcmtwQ1NNSlVYS2RO?=
 =?utf-8?B?OVBBRjc1SlNuZy92VlJjelpOanl2aEh4WUNuNmd4ZUYvSk93aGh1YVZETnBF?=
 =?utf-8?B?S0VFa2RjekU1YkRoTCtSdTNYdVdvaFpDUkQ1QzN0bmtZczJpSG1aamhwUmo0?=
 =?utf-8?Q?su1A=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: 34c71ab7-bc2d-48a7-baa8-08ddad56133c
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2025 04:18:55.7882
 (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: 4exwQyX2cKJlAzQ8LWfW3CRoeykk8GIvdMveF4h/MuDtOAzGAurjJCBmzL2WTY+DpgXwAPRAa2ZGqyLEPg73Fw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4215

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDEyLCAyMDI1
IDEyOjEwIEFNDQo+IFRvOiBQZW5ueSwgWmhlbmcgPHBlbm55LnpoZW5nQGFtZC5jb20+DQo+IENj
OiBIdWFuZywgUmF5IDxSYXkuSHVhbmdAYW1kLmNvbT47IEFuZHJldyBDb29wZXINCj4gPGFuZHJl
dy5jb29wZXIzQGNpdHJpeC5jb20+OyBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4
LmNvbT47DQo+IEFudGhvbnkgUEVSQVJEIDxhbnRob255LnBlcmFyZEB2YXRlcy50ZWNoPjsgT3J6
ZWwsIE1pY2hhbA0KPiA8TWljaGFsLk9yemVsQGFtZC5jb20+OyBKdWxpZW4gR3JhbGwgPGp1bGll
bkB4ZW4ub3JnPjsgU3RlZmFubyBTdGFiZWxsaW5pDQo+IDxzc3RhYmVsbGluaUBrZXJuZWwub3Jn
PjsgeGVuLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0gg
djUgMDQvMThdIHhlbi9jcHVmcmVxOiBpbnRyb2R1Y2UgbmV3IHN1Yi1oeXBlcmNhbGwgdG8NCj4g
cHJvcGFnYXRlIENQUEMgZGF0YQ0KPg0KPiBPbiAyNy4wNS4yMDI1IDEwOjQ4LCBQZW5ueSBaaGVu
ZyB3cm90ZToNCj4gPiBAQCAtNjM1LDYgKzY0MSwxMjQgQEAgb3V0Og0KPiA+ICAgICAgcmV0dXJu
IHJldDsNCj4gPiAgfQ0KPiA+DQo+ID4gK3N0YXRpYyB2b2lkIHByaW50X0NQUEMoY29uc3Qgc3Ry
dWN0IHhlbl9wcm9jZXNzb3JfY3BwYyAqY3BwY19kYXRhKSB7DQo+ID4gKyAgICBwcmludGsoIlx0
X0NQQzogaGlnaGVzdF9wZXJmPSV1LCBsb3dlc3RfcGVyZj0ldSwgIg0KPiA+ICsgICAgICAgICAg
ICJub21pbmFsX3BlcmY9JXUsIGxvd2VzdF9ub25saW5lYXJfcGVyZj0ldSwgIg0KPiA+ICsgICAg
ICAgICAgICJub21pbmFsX21oej0ldU1IeiwgbG93ZXN0X21oej0ldU1IelxuIiwNCj4gPiArICAg
ICAgICAgICBjcHBjX2RhdGEtPmNwYy5oaWdoZXN0X3BlcmYsIGNwcGNfZGF0YS0+Y3BjLmxvd2Vz
dF9wZXJmLA0KPiA+ICsgICAgICAgICAgIGNwcGNfZGF0YS0+Y3BjLm5vbWluYWxfcGVyZiwgY3Bw
Y19kYXRhLT5jcGMubG93ZXN0X25vbmxpbmVhcl9wZXJmLA0KPiA+ICsgICAgICAgICAgIGNwcGNf
ZGF0YS0+Y3BjLm5vbWluYWxfbWh6LCBjcHBjX2RhdGEtPmNwYy5sb3dlc3RfbWh6KTsgfQ0KPiA+
ICsNCj4gPiAraW50IHNldF9jcHBjX3BtaW5mbyh1bnNpZ25lZCBpbnQgYWNwaV9pZCwNCj4gPiAr
ICAgICAgICAgICAgICAgICAgICBjb25zdCBzdHJ1Y3QgeGVuX3Byb2Nlc3Nvcl9jcHBjICpjcHBj
X2RhdGEpIHsNCj4gPiArICAgIGludCByZXQgPSAwLCBjcHVpZDsNCj4gPiArICAgIHN0cnVjdCBw
cm9jZXNzb3JfcG1pbmZvICpwbV9pbmZvOw0KPiA+ICsNCj4gPiArICAgIGNwdWlkID0gZ2V0X2Nw
dV9pZChhY3BpX2lkKTsNCj4gPiArICAgIGlmICggY3B1aWQgPCAwIHx8ICFjcHBjX2RhdGEgKQ0K
Pg0KPiBUaGUgIWNwcGNfZGF0YSBwYXJ0IGlzbid0IHJlYWxseSBuZWVkZWQsIGlzIGl0Pw0KDQpJ
IGFkZGVkIGl0IGJlY2F1c2Ugc2V0X2NwcGNfcG1pbmZvKCkgaXMgYW4gZXh0ZXJuYWwgZnVuY3Rp
b24sIGFuZCBtYXliZSB3ZSBzaGFsbCB2YWxpZGF0ZSBlYWNoDQppbnB1dCBmb3IgYW55IGV4dGVy
bmFsIGZ1bmN0aW9ucz8gT3IgbWF5YmUgbm90LiBJJ20gbm90IHN1cmUgaWYgaXQgaXMgYSBNVVNU
Pw0KDQo+DQo+ID4gKyAgICAgICAgcG1faW5mby0+aW5pdCA9IFhFTl9DUFBDX0lOSVQ7DQo+ID4g
KyAgICAgICAgcmV0ID0gY3B1ZnJlcV9jcHVfaW5pdChjcHVpZCk7ICNpZm5kZWYgTkRFQlVHDQo+
ID4gKyAgICAgICAgaWYgKCByZXQgKQ0KPiA+ICsgICAgICAgICAgICBkcHJpbnRrKFhFTkxPR19X
QVJOSU5HLA0KPiA+ICsgICAgICAgICAgICAgICAgICAgICJDUFUgJXUgZmFpbGVkIHRvIGJlIGlu
aXRpYWxpemVkIHdpdGggYW1kLWNwcGMgbW9kZSwgYW5kIHVzZXJzDQo+IGNvdWxkIG9ubHkgcmVi
b290IGFuZCByZS1kZWZpbmUgY21kbGluZSB3aXRoIFwiY3B1ZnJlcT14ZW5cIiIsDQo+ID4gKyAg
ICAgICAgICAgICAgICAgICAgY3B1aWQpOw0KPiA+ICsjZW5kaWYNCj4NCj4gV2hhdCB1c2UgaWYg
dGhlICNpZmRlZiBoZXJlPyBUaGUgbW9yZSB0aGF0IE5ERUJVRyBjb250cm9scyBiZWhhdmlvciBv
Zg0KPiBBU1NFUlQoKSwgbm90IHRoYXQgb2YgKGRlYnVnKSBsb2dnaW5nLg0KPg0KDQpVbmRlcnN0
b29kLiBNYXliZSBJIHNoYWxsIHVzZSBvbmUtdGltZSBwcmludGtfb25jZSgpDQoNCj4NCj4gSmFu
DQo=


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 05:24:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 05:24:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017685.1394677 (Exim 4.92)
	(envelope-from )
	id 1uROng-0004c6-1G; Tue, 17 Jun 2025 05:24:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017685.1394677; Tue, 17 Jun 2025 05: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 1uROnf-0004bz-Uk; Tue, 17 Jun 2025 05:23:59 +0000
Received: by outflank-mailman (input) for mailman id 1017685;
 Tue, 17 Jun 2025 05: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 1uROne-0004bt-Qz
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 05:23:58 +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 3e6d2bbd-4b3b-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 07:23:47 +0200 (CEST)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-4531e146a24so32167925e9.0
 for ; Mon, 16 Jun 2025 22:23:47 -0700 (PDT)
Received: from ?IPV6:2003:ca:b711:f21a:fe:66b6:9dc3:86d6?
 (p200300cab711f21a00fe66b69dc386d6.dip0.t-ipconnect.de.
 [2003:ca:b711:f21a:fe:66b6:9dc3:86d6])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4532e243e59sm161778605e9.19.2025.06.16.22.23.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Jun 2025 22:23:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3e6d2bbd-4b3b-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750137827; x=1750742627; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=5MR8GbeSgTR/iq6fE8LX+vUJKse8ToE0O9/sKPOHwyw=;
        b=R91j+64ozeUoDYscA+/YRq5slQ5Ogo4h9tlPXi5IKKVcIRQjLGdvb0o7jVhlKsoxVY
         nqJzhR7DnXtlFwNCKPpcK+lBhLwDHi0VUcEAAu9+UYAWAosOyzaEC+NGJby749vT9wnT
         kbEFoBJGXe4/gEzH2eL9Z7dkoVVpgMjjhCKnIES9UFojYqyB+P+MYdl+7SCxlGV75gYY
         Tfp8RvvNO2bc79/xB7M2bRci30TM0x3u5UIJJqIM+nlvgCu+Z946DbMu2XRED9Yz9Tih
         gXy6fKnTzYm9zppu/qKpD5VPJL2ADgBQBH7EFUMzDR+mnzD7d6VgI11ym9WBaY+Nt86Q
         N0bw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750137827; x=1750742627;
        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=5MR8GbeSgTR/iq6fE8LX+vUJKse8ToE0O9/sKPOHwyw=;
        b=f/d+9H87dmRPcIjBR9WSMpvAPy7CxevRDGRW6/1qa63od/qxa025Ki/bnhivCVdGv1
         /RvZpqEpJ7g94k6kBK05vBsSn2kktPecggP62cAfgi0GL+vJ6XsbsOGcHpPe8gRUoH3D
         +ema0EL6+PzbhFWMHdXlrd2P/t5xvgpqKKQlmmpxq3I0LzsxaQWutKJ1c0UN8L2UHkB8
         3xcNSvJugvP2EcvuM0/U4GjwjrXEYLBo8QEsjduoREB87p92+kKBbklF7Km9FjdCm6AW
         cJsFjocHucTlVuZawWWmy97goFVOYQp8lD8wl6rW5lHgAGC8ryjrhm4cKV3YFjDG0DAx
         ah3g==
X-Forwarded-Encrypted: i=1; AJvYcCVp35J/v+Fatkp+4/A4YO6mfgXqRhjDIlCQk9uP3asaKM6e7zK5sLfkG1am1CfZov9+9icVujKmXGc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwW08HiBJ57DiJsntU+VJSoRVVGIzgi1klerOrZ/XRMvtX7BISu
	nuKVLvF53q9W+ow5QiMi7Vz8zwla3S+wZUznFoJKzCQ+jK7KEZ4rokQa6Z8NeVlvMA==
X-Gm-Gg: ASbGnctXCtxbEnnlaPaDBlF408ppVN2XvuB9jiLMr9BX6avI9mdbkwPNB0mWnLZ2C8S
	BqYOM+Cw6cUiTZYF4DgOq46M3Sti05ueGHrfYr0g5dip9RBE1Mw9antMLm369EsgEgGUbDHqiDG
	bcCLmkCQKwPrIrFDVVtchmN4MtzPlixaxNLhzyk6S+4dVJ5EQrzvAh/q/KB+dbvjGgPBfZ0zauJ
	Lk5E7rksR6kiyHQl6xVSwxeHDRAtfhYbSR4eTtOihVSkOHZTuAGh70p8tckCfcJfMj5+k+QHr1I
	QF6KztOHKrJfUt63w0SmsDjOCTrpApnHUnDBKvC/uePsz+85eb+MjuXJgyUEQnllKm3DzI5j5gB
	ywqnYu83xxGD0BTD+Bupu4HRoPvpvSieeFwKy8d7Pqk2Ocfzx5mjOX0wEohkXrmCd/wiTMv0Xws
	qcBsFdi3R1q/KYnn2SPl5Y1W859Q==
X-Google-Smtp-Source: AGHT+IEyC6SDQFvjNXMqoRIyXX2T6kdz29iwAANorohWJlk7paeNKUgxqgCQ8X/enVKEQhWzLaD2VA==
X-Received: by 2002:a05:600c:1d01:b0:442:ccf9:e6f2 with SMTP id 5b1f17b1804b1-4533caa6bb6mr108711325e9.16.1750137826620;
        Mon, 16 Jun 2025 22:23:46 -0700 (PDT)
Message-ID: <5645e4dc-7598-414d-a2b5-39066401e9b3@suse.com>
Date: Tue, 17 Jun 2025 07:23:43 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 4/4] xsm/dummy: Allow hwdom SYSCTL_readconsole/physinfo
To: Stefano Stabellini 
Cc: Jason Andryuk ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org
References: <20250610225737.469690-1-jason.andryuk@amd.com>
 <20250610225737.469690-5-jason.andryuk@amd.com>
 <5f6d43da-2600-4c1c-9bcb-f13e8fce921e@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.06.2025 02:10, Stefano Stabellini wrote:
> On Mon, 16 Jun 2025, Jan Beulich wrote:
>> On 14.06.2025 00:51, Stefano Stabellini wrote:
>>> On Wed, 11 Jun 2025, Jason Andryuk wrote:
>>>> On 2025-06-11 09:27, Jan Beulich wrote:
>>>>> On 11.06.2025 00:57, Jason Andryuk wrote:
>>>>>> Allow the hwdom to access the console, and to access physical
>>>>>> information about the system.
>>>>>>
>>>>>> xenconsoled can read Xen's dmesg.  If it's in hwdom, then that
>>>>>> permission would be required.
>>>>>
>>>>> Why would xenconsoled run in the hardware domain? It's purely a software
>>>>> construct, isn't it? As a daemon, putting it in the control domain may
>>>>> make sense. Otherwise it probably ought to go in a service domain.
>>>>
>>>> My approach has been to transform dom0 into the hardware domain and add a new
>>>> control domain.  xenconsoled was left running in the hardware domain.
>>>
>>> I think we should keep xenconsoled in the hardware domain because the
>>> control domain should be just optional. (However, one could say that with
>>> Denis' recent changes xenconsoled is also optional because one can use
>>> console hypercalls or emulators (PL011, NS16550) for all DomUs.)
>>>
>>>
>>>
>>>> I suppose it could move.  Maybe that would be fine?  I haven't tried. The
>>>> Hyperlaunch code populates the console grants to point at the hardware domain,
>>>> and I just followed that.
>>>>
>>>> One aspect of why I left most things running in the Hardware domain was to not
>>>> run things in the Control domain.  If Control is the highest privileged
>>>> entity, we'd rather run software in lower privileged places. Especially
>>>> something like xenconsoled which is receiving data from the domUs.
>>>
>>> Yes, I agree with Jason. It is a bad idea to run xenconsoled in the
>>> Control Domain because the Control Domain is meant to be safe from
>>> interference. We want to keep the number of potential vehicles for
>>> interference down to a minimum and shared memory between Control Domain
>>> and DomUs is certainly a vehicle for interference.
>>
>> As much as it is when xenconsoled runs in the hardware domain? Especially
>> if the hardware domain is also running e.g. PV backends or qemu instances?
> 
> It looks like you are thinking of the possible
> interference from the Hardware Domain to the Control Domain via
> xenconsoled, correct?

More like interference with the system as a whole, which simply includes
Control.

> If that is the case, good thinking. I can see that you have really
> understood the essence of the problem we are trying to solve.
> 
> That is not an issue because the Control Domain shouldn't use PV
> console. Instead, it should use the console hypercall, or the
> PL011/NS16550 emulators in Xen.

Well. I think the underlying concept of Control Domain being highly
privileged needs more general discussion. As indicated elsewhere, I
didn't think disaggregation (whichever way done) would leave any
domain with effectively full privilege. I wonder what others think.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 05:34:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 05:34:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017696.1394686 (Exim 4.92)
	(envelope-from )
	id 1uROxX-0006NL-3f; Tue, 17 Jun 2025 05:34:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017696.1394686; Tue, 17 Jun 2025 05:34:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uROxX-0006NE-0h; Tue, 17 Jun 2025 05:34:11 +0000
Received: by outflank-mailman (input) for mailman id 1017696;
 Tue, 17 Jun 2025 05:34: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 1uROxW-0006N8-LS
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 05:34:10 +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 b068a427-4b3c-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 07:34:08 +0200 (CEST)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-43ea40a6e98so65200345e9.1
 for ; Mon, 16 Jun 2025 22:34:08 -0700 (PDT)
Received: from ?IPV6:2003:ca:b711:f21a:fe:66b6:9dc3:86d6?
 (p200300cab711f21a00fe66b69dc386d6.dip0.t-ipconnect.de.
 [2003:ca:b711:f21a:fe:66b6:9dc3:86d6])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a568b2a6a5sm12788299f8f.74.2025.06.16.22.34.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Jun 2025 22:34:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b068a427-4b3c-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750138447; x=1750743247; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=D2f1itmEVIrle8OrIGrYJlEgsdZL5eJAQfLXLlsxXN8=;
        b=VT/1QZ8PaYWgt8rQzxmX1mSvONjyBdYiijCSAi6dt0xK83dOxXYzq93KQsWNOPlnz4
         eZBrku0R/U66Yu0aJNCs7P4kxFr5M0NlYqo3PbEdaVVAsoq14nClMsDdiJonrOh4OX+Y
         yhgZgXt03DVQ99oD0cpIKd2dH6dtfnCjyzm1EWpDgvwfFfC2awrgrYPJ0xvKcovOqaP0
         UOPEcoaHRlXe6ju/tMIuJH0lTTjDeITlAf7o5lM7R/WD2w0dLvE1W4u009Z6xZXYZvTs
         G98+g5ufKxLF6p86LZYD+/0DAP2/kocIj6msaaQt1OL5wBJoPguSbY38CHmL9d1OUwXU
         FzVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750138447; x=1750743247;
        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=D2f1itmEVIrle8OrIGrYJlEgsdZL5eJAQfLXLlsxXN8=;
        b=T5a2W4YeMuHttqaevb8mTQUOh/8sm1j0WEuhazvnaOPN63mthIh46QJwFBcUtpm00x
         94rKmJhs7H1yvd+htf91WNLyYRkanFs+ABVsbzRC44IYup1OIpldLNk1LvLRUwdN+xGA
         J6P/kkAFABi0XLMmyNf8PkilXsfd4MhYor23LHCcWZ5QdTcLsamMiO/euwEvm/n2T1r8
         vSNEzjFTR1kbnFQWmU6PStlhjV/fEssl4KSAtklHJ/CpAtOxDW/oWmG742gpuXPomvyK
         JFC1RbgvEWB1aKs63hQ4tBd8BNKv6i5TYgqSSGiHNcFZkpgqIT2TYyA/uNRWrYpwzy+H
         4QDA==
X-Forwarded-Encrypted: i=1; AJvYcCXS7j9KrRXsCD9YB0F734s0uocbmxKP1T2nlIU/AoSGMrktGE9UlwYPA+WpSOVg7AZt9yDrPWEiHpM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxQ4ErhaLUZLOffa4EulwiD1kJa9xsi192rE8xpFFiOz/mnHwro
	nr9Keq6bruOCknTiuUbWgNKjSPg6AxVq/ZQ/yo44iBVFmeJ01ucdEZpTX8abj7wnrM0xQ/ESbwQ
	41KY=
X-Gm-Gg: ASbGncuGDPOY8setTi2KP+HbLefJRez6nlHRAb6KYY47C2v2bgDndBnDg1QiNtLDF4t
	4iXbkqENgRYK0AX46s+PPfPyAl67RTrfOoyiYDcTdoX6qd12FyWhjzh54Mwj/C8tpRzGvtvF3Nt
	OJnx8E7N2PgguUuVOePSdziEOSvyrhprkO5W4ea03JikXDnCBwUZtHBZ49+7tC6vto4cKl1JW8O
	lfrNveFShir+1DV7xYeUF7LF05FjdW5FGmJPu4neo1aIF+LsrAkJQBSViX0tZ//hf+PnZx9mbTJ
	UwUy2J3rU0uaMkUZGSJdKJCL5+Zp1Gqtm4rVJOxzWAZrRRYrvKcu6ge20ZuYU34W5v+MDTj0bxZ
	uH0ixTG+Sb0jQ+8xUbVi6Ufy+41fZualX5mgb1ekJMBoPbzXkAczwBT49hUMFmCbZjL00GsvgNB
	vhRrSaf1JGLF9fiSU=
X-Google-Smtp-Source: AGHT+IGAkjSaRKXrdtrIHyxnxGkzD+xV2iNG4SuSIKDjbR2suVjLeXEOD/d00zjmd5DYt4owfwrWCw==
X-Received: by 2002:a05:6000:2286:b0:3a4:d83a:eb4c with SMTP id ffacd0b85a97d-3a572e9a4bamr8891130f8f.57.1750138447345;
        Mon, 16 Jun 2025 22:34:07 -0700 (PDT)
Message-ID: 
Date: Tue, 17 Jun 2025 07:34:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 03/18] xen/cpufreq: extract _PSD info from "struct
 xen_processor_performance"
To: "Penny, Zheng" 
Cc: "Huang, Ray" ,
 "xen-devel@lists.xenproject.org" 
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-4-Penny.Zheng@amd.com>
 <005a0e3a-dc8f-480f-8bb9-fd8eb164eb02@suse.com>
 
 <824a8aa5-c603-47e8-8688-a324152329a9@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.06.2025 06:12, Penny, Zheng wrote:
> [Public]
> 
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Monday, June 16, 2025 5:51 PM
>> To: Penny, Zheng 
>> Cc: Huang, Ray ; xen-devel@lists.xenproject.org
>> Subject: Re: [PATCH v5 03/18] xen/cpufreq: extract _PSD info from "struct
>> xen_processor_performance"
>>
>> On 16.06.2025 11:43, Penny, Zheng wrote:
>>> [Public]
>>>
>>>> -----Original Message-----
>>>> From: Jan Beulich 
>>>> Sent: Wednesday, June 11, 2025 11:34 PM
>>>> To: Penny, Zheng 
>>>> Cc: Huang, Ray ; xen-devel@lists.xenproject.org
>>>> Subject: Re: [PATCH v5 03/18] xen/cpufreq: extract _PSD info from
>>>> "struct xen_processor_performance"
>>>>
>>>> On 27.05.2025 10:48, Penny Zheng wrote:
>>>>> @@ -545,14 +597,9 @@ int set_px_pminfo(uint32_t acpi_id, struct
>>>>> xen_processor_performance *perf)
>>>>>
>>>>>      if ( perf->flags & XEN_PX_PSD )
>>>>>      {
>>>>> -        /* check domain coordination */
>>>>> -        if ( perf->shared_type != CPUFREQ_SHARED_TYPE_ALL &&
>>>>> -             perf->shared_type != CPUFREQ_SHARED_TYPE_ANY &&
>>>>> -             perf->shared_type != CPUFREQ_SHARED_TYPE_HW )
>>>>> -        {
>>>>> -            ret = -EINVAL;
>>>>> +        ret = check_psd_pminfo(perf->shared_type);
>>>>> +        if ( ret )
>>>>>              goto out;
>>>>> -        }
>>>>>
>>>>>          pxpt->shared_type = perf->shared_type;
>>>>>          memcpy(&pxpt->domain_info, &perf->domain_info,
>>>>
>>>> ... the need for this change. And even if there is a need, a
>>>> follow-on question would be how this relates to the subject of this patch.
>>>
>>> I extracted this snippet out for sharing the same checking logic both
>>> in Px and later CPPC. They both need _PSD info
>>
>> Right, and that (iirc) becomes visible later in the series. But it needs saying here. As
>> it stands the description talks of only get_psd_info() right now. And the change
>> above is also unrelated to the "extract" mentioned in the title.
>>
>>> I could change title to "xen/cpufreq: make _PSD info common" and also
>>> add description in commit message for introducing check_psd_pminfo()
>>
>> The title was probably fine; it's the description which was lacking. In fact I'd deem
>> "make ... common" misleading when there's no 2nd user (yet).
>>
> 
> How about:
> "
> Title: xen/cpufreq: export _PSD info and checking

As said, the original title was probably fine. In the new title (and also in
the text suggested below), I wonder what "export" means.

> _PSD info, consisted of "shared_type" and "struct xen_psd_package", will not
> only be provided from px-specific "struct xen_processor_performance", but also
> in CPPC data.
> 
> In cpufreq_add/del_cpu(), a new helper get_psd_info() is introduced to
> export _PSD info. While in set_px_pminfo(), check_psd_pminfo() is also introduced to
> export _PSD value checking.

How about "Two new helper functions are introduced to deal with _PSD. They
will later be re-used for handling the same data for CPPC."

Jan

> in the meantime, the following style corrections get applied at the same time: ........
> ```
> 
>> Jan



From xen-devel-bounces@lists.xenproject.org Tue Jun 17 05:39:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 05:39:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017703.1394696 (Exim 4.92)
	(envelope-from )
	id 1uRP2C-0006wT-KK; Tue, 17 Jun 2025 05:39:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017703.1394696; Tue, 17 Jun 2025 05:39: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 1uRP2C-0006wM-Hj; Tue, 17 Jun 2025 05:39:00 +0000
Received: by outflank-mailman (input) for mailman id 1017703;
 Tue, 17 Jun 2025 05:38: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 1uRP2B-0006wG-B9
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 05:38:59 +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 5ce48ef3-4b3d-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 07:38:57 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a54836cb7fso3580739f8f.2
 for ; Mon, 16 Jun 2025 22:38:57 -0700 (PDT)
Received: from ?IPV6:2003:ca:b711:f21a:fe:66b6:9dc3:86d6?
 (p200300cab711f21a00fe66b69dc386d6.dip0.t-ipconnect.de.
 [2003:ca:b711:f21a:fe:66b6:9dc3:86d6])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a568b28876sm12839951f8f.73.2025.06.16.22.38.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Jun 2025 22:38:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5ce48ef3-4b3d-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750138737; x=1750743537; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=+onuvzNiq176yQ8p8naS05aA5DxQlKVbmWiA5rgjdFc=;
        b=U0OJcccdzihOT5odUDvMw24DmxwpjJ8kCf69CRErepr0Zd+8YetZQbtD4Q9UknOZId
         aTIxup7rQ8+zOk5nFKV36XPgpPJ4NsIV9ESbsfb4H2ZIDZ72pfocV0bz1aE3QdAae5zt
         RC0M7tdiWxeLSNPUMlMe6ox37YmmOSCG11QZv8FASM2x5j38vsEmZj+k0ecyVH4xmnxx
         TJLIRXyPiT4o0KaLed8/XWs+cBMr/zNKs3ttGRHoKF4ldASFShkqvpnTjx7x/Jkw9r4x
         vyCPSnswo/SVQ/XMdgjTG87uBhT1RAq74QhI5zuKOuDWpij1pUPhauoVl1gA/uwQ++HD
         iofw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750138737; x=1750743537;
        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=+onuvzNiq176yQ8p8naS05aA5DxQlKVbmWiA5rgjdFc=;
        b=d+zwkc7tUXN6mtMWMWjYkTgHJw/hBzMkGPp0vEBYJQmWd8Og7mMN4PR7MIHpu8GRnx
         grFbKeWdS5TVA27Juv+O3oqlWTnf1jXZaq5d2B023qVD75N3hD2oUJronGE2iwhIPwyu
         uWnJQWfOKqDr0jdymFBeHC+mRAmDRI2MCm4h61XkZZnHzw0NPFeg95NJZhdqSYwWjJUO
         GVGRRnZK+/G7GeFTd9k2ZhF9n82wLSuNYsg/mnwhzr8juCp1YFoy2bvJzdC5v5c60gxJ
         urWrl0je0YDxoXL1IlwzCsGq9h6gAu54B46nQwdcQHax+kPsIWPodKnRdmr0zBARz2Ag
         IB1g==
X-Forwarded-Encrypted: i=1; AJvYcCXKkIF2M/Y+Hx4A8l0WotezzrlA1HJeMz1ep7gexuOacTJ4FVfZW4ubdYy4S5KHZ7eSskDDpTco5YI=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy14C/yYN8sENFcQRb86CE+CR+vMgdwTBCvtJz/Mwl0pMEf7dvP
	Ok8pqCkUibdqutYzoijx2EeHxbZmv4r8vtwcPHOEX2uFG1Zx3fge5BdnzeumSsX7+vWWrBlz3Wc
	hw3M=
X-Gm-Gg: ASbGncuesbwFx3oFnuYyHQ3Dj1onStYvjUIVeVwy37JgOKC7W69Kw4Fzkx/6NbSfzHm
	cH3yP5+HcJR9xoXMN18GkeCSbTmMC+xf5zOoPYa9Neu+MX3iBDnV1SErKDnMcELpr9Kg5WLRlir
	hmdVBkwD2KRArjVaOZTMun5HDzWVsMKwaCVhLZ1X3QN/Zr98nC0YG/sKmM2brN3NIyW9BsOvnhx
	qhGmAilQXdbFVuRrPytn7PpP+aP3r5+aJ/c3DE6zbd4KZJl5TfDMUWQOHrKx6X18pFlNjAmUpmA
	EDvDfCxH6SZIvgFcE7fSykdJ0Hv7PNwniFL4vRb2DmY31/mWoqSlhNKgYuNiPYZ7KeJ0iocs9ey
	WOQELO1Ph9tSnA2CXW6CIZqiO0yAvRya5VVGA9o1Nng40v2HoTdat2Yxivkdu270MPWsP/A7SQn
	ZW9ds7G7R3S0WOTEs=
X-Google-Smtp-Source: AGHT+IG/AZdb7p5o+ncvrqmpEMlCFOEwAOWO8E2d6qQkjJN6queWDIlnEyfdtgpYtRxOSnapQFFE7g==
X-Received: by 2002:a5d:5f87:0:b0:3a4:dd00:9af3 with SMTP id ffacd0b85a97d-3a572e588d7mr8747779f8f.56.1750138736735;
        Mon, 16 Jun 2025 22:38:56 -0700 (PDT)
Message-ID: 
Date: Tue, 17 Jun 2025 07:38:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 04/18] xen/cpufreq: introduce new sub-hypercall to
 propagate CPPC data
To: "Penny, Zheng" 
Cc: "Huang, Ray" ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 "Orzel, Michal" , Julien Grall ,
 Stefano Stabellini ,
 "xen-devel@lists.xenproject.org" 
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-5-Penny.Zheng@amd.com>
 <0de0ea5c-64c9-4ac8-8e76-750cb3036419@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.06.2025 06:18, Penny, Zheng wrote:
> [Public]
> 
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Thursday, June 12, 2025 12:10 AM
>> To: Penny, Zheng 
>> Cc: Huang, Ray ; Andrew Cooper
>> ; Roger Pau Monné ;
>> Anthony PERARD ; Orzel, Michal
>> ; Julien Grall ; Stefano Stabellini
>> ; xen-devel@lists.xenproject.org
>> Subject: Re: [PATCH v5 04/18] xen/cpufreq: introduce new sub-hypercall to
>> propagate CPPC data
>>
>> On 27.05.2025 10:48, Penny Zheng wrote:
>>> @@ -635,6 +641,124 @@ out:
>>>      return ret;
>>>  }
>>>
>>> +static void print_CPPC(const struct xen_processor_cppc *cppc_data) {
>>> +    printk("\t_CPC: highest_perf=%u, lowest_perf=%u, "
>>> +           "nominal_perf=%u, lowest_nonlinear_perf=%u, "
>>> +           "nominal_mhz=%uMHz, lowest_mhz=%uMHz\n",
>>> +           cppc_data->cpc.highest_perf, cppc_data->cpc.lowest_perf,
>>> +           cppc_data->cpc.nominal_perf, cppc_data->cpc.lowest_nonlinear_perf,
>>> +           cppc_data->cpc.nominal_mhz, cppc_data->cpc.lowest_mhz); }
>>> +
>>> +int set_cppc_pminfo(unsigned int acpi_id,
>>> +                    const 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 )
>>
>> The !cppc_data part isn't really needed, is it?
> 
> I added it because set_cppc_pminfo() is an external function, and maybe we shall validate each
> input for any external functions? Or maybe not. I'm not sure if it is a MUST?

It's not. If look through code globally, it is rare that we have such checks.
Many of them are imo pointless (and thus giving bad examples). In certain
cases they're meaningful to have.

>>> +        pm_info->init = XEN_CPPC_INIT;
>>> +        ret = cpufreq_cpu_init(cpuid); #ifndef NDEBUG
>>> +        if ( ret )
>>> +            dprintk(XENLOG_WARNING,
>>> +                    "CPU %u failed to be initialized with amd-cppc mode, and users
>> could only reboot and re-define cmdline with \"cpufreq=xen\"",
>>> +                    cpuid);
>>> +#endif
>>
>> What use if the #ifdef here? The more that NDEBUG controls behavior of
>> ASSERT(), not that of (debug) logging.
> 
> Understood. Maybe I shall use one-time printk_once()

Perhaps, also considering that the action to take is relevant also in
release builds. However, "users could only" is once again odd wording for
a log message. How about "CPU%u failed amd-cppc mode init; use \"cpufreq=xen\"
instead"?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 06:00:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 06:00:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017711.1394707 (Exim 4.92)
	(envelope-from )
	id 1uRPMT-0001Tj-5M; Tue, 17 Jun 2025 05:59:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017711.1394707; Tue, 17 Jun 2025 05: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 1uRPMT-0001Tc-2l; Tue, 17 Jun 2025 05:59:57 +0000
Received: by outflank-mailman (input) for mailman id 1017711;
 Tue, 17 Jun 2025 05:59:56 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uRPMR-0001TQ-TT
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 05:59:56 +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 48837778-4b40-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 07:59:52 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 PH7PR12MB7871.namprd12.prod.outlook.com (2603:10b6:510:27d::18) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.28; Tue, 17 Jun
 2025 05:59:47 +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.8835.027; Tue, 17 Jun 2025
 05:59: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: 48837778-4b40-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=zJAxeopSda1idqTrexJh5nPU0M8AQbDOrV6nc1P9ZKa0NM23JxqWER4CN8Omf6evmuuqWo6ZtOCCgP7pJ9uz2UPIO8+f3lNgjiwoVG0dlS6sLBzO6649FudUUk/Wx/USjT+on8tXOjlNzAb5iFPp5btVBRPu1/j+rjRYKqT8V1AWKsWx07RxwO1WwWsSsLmZUnpX3WZdJ6u+MxvTR6zkRQP2O4/rkzDfGal2HFc0ZJvnBV26Fnrbe3afnD1lvjsnorgJC3d3xsSVzNH2ot2mmMBdvdBL/FEAim6XR3TmgABlF3TTTA11KdsB3NoQJXsPRH7rjBDRNt8zsSrzpeH3PQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=WeCtjvwUQlw0E6jxPQjg5dAnYKyJUVJjSp8ObjgbPTU=;
 b=BXOTbptXRS0HmpHnXxgJzC67c5fL1QWbFgVpqIBjwj5CsY5S556W3NUxRkqCR/5gtpU8oSS+mdULAodZ/eUvgzEQdr3DBz0m0QUKob+AqLJROy1o00O1F5CY0ZKRumk14Q4NiyXbNATeTJeXxhIa0BS4Y5aA+js4zOy3SJxOx1+czYd4z1BfLU2k2FOGA1mWHn2UvRjQ5621904m6numnn/8V9Z7h44komGTI6TvuNCQtXR18UZvv63820bdo0rHFe487HkTTi/HkD9ekSAMoportiE3jGH8EbEnbQ0BcwgNefwOqpQlaLyLA/53CbfbB+abBINc8Wz75Tr3T0i8+w==
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=WeCtjvwUQlw0E6jxPQjg5dAnYKyJUVJjSp8ObjgbPTU=;
 b=tFxiZBou8HhG/e/LK0QPelmGQU9uth6JWBw7fSVK1LQct7mm1g1gBASRx0iIm+2elc5eB/SXjCQSIWdh3IH9ar8bUW7NsdKd0PDMkvHFCSlqnmNGmNec866p7ASvHwk82C323bK1tia6bdAsSzFi2AX87U9SVafiMqbO68YONXo=
From: "Penny, Zheng" 
To: "Andryuk, Jason" , "xen-devel@lists.xenproject.org"
	
CC: "Huang, Ray" , Jan Beulich 
Subject: RE: [PATCH v5 05/18] xen/cpufreq: refactor cmdline "cpufreq=xxx"
Thread-Topic: [PATCH v5 05/18] xen/cpufreq: refactor cmdline "cpufreq=xxx"
Thread-Index: AQHbzuQ9uCUmVxaE7E6nhT8/lomgsbP9sLQAgAlLVmA=
Date: Tue, 17 Jun 2025 05:59:46 +0000
Message-ID:
 
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-6-Penny.Zheng@amd.com>
 <4d6a72fc-5e7d-4817-8b52-b6b24fca9d25@amd.com>
In-Reply-To: <4d6a72fc-5e7d-4817-8b52-b6b24fca9d25@amd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=True;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-06-17T05:59:32.0000000Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=3;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged
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_|PH7PR12MB7871:EE_
x-ms-office365-filtering-correlation-id: a2cbfeee-e690-4320-3183-08ddad6429b6
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|366016|1800799024|376014|38070700018|7053199007;
x-microsoft-antispam-message-info:
 =?utf-8?B?c2xCRTlwaTZtV0EvK2sza21UcjFSVDhRZzV4cTZ2Yzl1dzFEY3JBSGlDYlFk?=
 =?utf-8?B?VU5jT0l6YytUeFJPY0F2NFBKSzk0bjNFNFIrUEZheDRvLzg4TWludXFTWXBL?=
 =?utf-8?B?OXUyb29XeFJNZUk2SlZBaFVPSkM3VUszRGY0TStpSXowUWoraXQvblNDSGQ5?=
 =?utf-8?B?OFlaaHZBcFhJWHBmK3R5T2UzczQ3Y0FOSnFpSlQwMEdOS28vazF0Nko0dm0z?=
 =?utf-8?B?d0lGRlE3R2hFSDhuTW90aXc0V3FYcE9uakxCeEJQdW9EODRBMjNxSHd3U2pu?=
 =?utf-8?B?WlNlVTdtdkVVS2NrSmV5czlIMjdmekdiR1hYV2FCRGRRbHdlbTlyazdlLzQ4?=
 =?utf-8?B?cXk2T1ByTG40amo1WlgxUEJiM3FhNEFEK2JGQ0JxLzFKQ3VQUmhOanJxZ0Nt?=
 =?utf-8?B?aXNFUmIyTG05U2RxSkU4WUJKS0hNNGFjTFY5Z3U4bUpqekpZb3ZvL0E1WTdk?=
 =?utf-8?B?c1FjMkw4VUF5YXBtRWFScHVRQWxZMnlhcEFEV0F6c0w5Tm82eGROVWdGV2FT?=
 =?utf-8?B?b04vSkRjYmlqUjVoWmNKMXVXY2JNTW1oVGYxVjc1SmdFRlhVNEZHQ2E0dGlq?=
 =?utf-8?B?dnRjUmd5a0xlY0p3TnlqOXlod1E1WExXVEFjbG9kT0RGM0VrVU1jbDNSQnZB?=
 =?utf-8?B?aEF2YXBqNDloMU9xNXB1M1BmM1ArQ0dUd2RkblAzZCtuL295ai9NSTlGYWpR?=
 =?utf-8?B?YUdtdk9taWdOMllsU0JaemtENGVYdjhKSktSbTZBVnJxcTljSlRwd3cyRzZ0?=
 =?utf-8?B?cldtMWZqSjRRUlg2TW11SHdqYVpWUUs2bFBvdXdzQzhFb1BiN2txZUg4STJk?=
 =?utf-8?B?QWUzUlJSVzdva3RPZm5idWdscEF0WCtHb3Q0MEptV1RBY0YvWU1VZGNSOE12?=
 =?utf-8?B?d05xVnZZNU1kdkZydW11Ris0TDBCWlNDY0svMFdTdGZaL0pVb3NENkRFT2pk?=
 =?utf-8?B?SXVGQkVNd0FPdlN5Rlo4bWRJNUVFcDRMd3h0aDQ1OHdLZW9vNVVOSFFNRnpR?=
 =?utf-8?B?UlFDbFhpQXA2RE1XYTJjc3V2czQ1akwzMnNsSW50b2RqSzRBZEZXMTNXLzNR?=
 =?utf-8?B?OG85VmhWc1JKNjRnVFdPODVGaGY5eFFmV0tXcmNTbjMrY3NZbDdEVHRrMTVv?=
 =?utf-8?B?SVdTd2V4MUpUNm1UOUw4VXdtZHFDdUZwVFlLR2NoTEtpeklOT2I3QTBUOFlw?=
 =?utf-8?B?MXRoSHBqS1pFc2tvRmhiZjkzUFdWT1VERUlzNjl1eDNtdEhyQWRhdmV0eExr?=
 =?utf-8?B?MGJqZ3BPZ0VrWGtGeGZRNzg4NXpIU2dKR2hQazM4STdzU0lRSkcrbkRrdDdw?=
 =?utf-8?B?N1JxbmM4TWd0aVEyd0FoS1E3OVAzUGlHeWM3VG1EMVNsZk1ERU5qcDZzOWp5?=
 =?utf-8?B?WnpZQ3hmNmtjOUJySXNMY0RKaDZGWDBsYjFBZEM5SDNhNnJKSjdwenZsc2N4?=
 =?utf-8?B?Ymx4NlFZWGl6V21lbGRUTkNnM2liUjQ3NXI5VnVRejlnaGhKQW9jalk3QlZ6?=
 =?utf-8?B?MUJPWTdaa1RtQ2psWDFzeVptYURoN045YklxeWFzUEIvSVVocnNHMXA3M3NU?=
 =?utf-8?B?V1ZXSUtKQ1J2SWltblB3c1ZWc2NOdnNpQW8rSURHZE1sV3VzQURCVllHYW1F?=
 =?utf-8?B?dGlOVlhhT2crMEpCb214UFZqQVc1MUp0NUswNTRneFo5TEd4REYwbDFwRGoy?=
 =?utf-8?B?MGRKYlYzVzFXWVVTN0o2VmJEMDBsT2pHTUEyWTFJbUkvQ2ZnUjl4K2licEE3?=
 =?utf-8?B?d3N2aXdMYzMzNUluMUEycW56L1B1M1dqWUJMUGtrYklmQ3BGbzVUbVJNMDJI?=
 =?utf-8?B?WkU2M05DMDVmc2RFNlYvMFRYUGVmQlRiOVBtU2dNZGN6THNSZWN1NXE0Lzdr?=
 =?utf-8?B?ZzgvOXg2a2tudVVZUytkV2YrVDFyeG01VXVRa1NnSU94dTZlUVJRM3Jnc05Q?=
 =?utf-8?B?eTA2Ukc1dnYxSUxQNXRKcXlOelVuWjRpZ1dkcXRLWFNxdnZKRm5xcHdIb3B4?=
 =?utf-8?Q?IsSeskIEr/EvIjoqIxX3kSSS0R6Ca0=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)(7053199007);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?eU9Oc0p0c0NndGZia1IvekE3UUMvRGkxOVlLeVE0VkpCSjlmRXZaSU1xQ0NY?=
 =?utf-8?B?SXRlYmJKVXdnRW45L2pxTllteHdJbFViRlRhSVNCSDZkTXR3YnZwdGw5WU5p?=
 =?utf-8?B?ZVd0ME1BaFRtMm04cFZTQkZVT2YyWWE0aDM2bHJVb253L0xIVHdGeEEybDAw?=
 =?utf-8?B?NTlLNXV1WHlOK2JnaTlYNzZsZWNmZ1pOUXI4UmJ5T0hRVXFOOEo5U0Z3d3oz?=
 =?utf-8?B?SW9yd1FiMk5YaGpRSUplQUNBK3Q0eWsxb3pTaFZsMElNZnk3Q1VoVFF3NWtm?=
 =?utf-8?B?cUNoNmxieS9yeE50elZSc1ZZR245SVFnQjJjM0Rxd1g5amxSaGFQRElvakZs?=
 =?utf-8?B?cUt4ZThVZXlHUlhWdXAycmZKTE0wU0VGc20veFQ4ZkVZR1oyUkJLL0FqaUpm?=
 =?utf-8?B?ME9VZmNqYjFlRXdTVzUwbTk3ZVBXcGRteitOb0hKZ2lFU3RUY3JobkxFbzVt?=
 =?utf-8?B?REpjWEx3SXkwWEFDUU5xTGJBSmRmU0xScU9kK3NZdnZpZlN3L3VnOUVVV2xY?=
 =?utf-8?B?QUhVZlp6Ny9CVmg4S0tHVjlqVG5JS3I4akZQTEpWWDNZbEFKQkRpQ2N3WVVs?=
 =?utf-8?B?MVpvek1mR1RURk9yY1NMdUR1THh4NmtpWHdKVzMrNTZrWmVDTXNoUVFQR1By?=
 =?utf-8?B?alhZaGJQMDZ3S1gzU3FMMkIwdWpnNWpjYXoyT0lNYU1aZUtvaFBhL3p5czNa?=
 =?utf-8?B?QW9tYTRqcGIwbmRVdUsyeTZzdWs5QXNpSEV5UENSVytLbGlhMElYZmtTU0NR?=
 =?utf-8?B?WExMdHVMVWV6Q1cwVUg0R1RpOVBwcVNQS01RQUJ4WWR2NVVnS3FzQktOcCsx?=
 =?utf-8?B?dDMrN2VuM2d3TDJCWDY0VzIyQTdCSElLd1RxY0pkeXdTTDM3akRvRUcrYWh2?=
 =?utf-8?B?b2RyS0RGd1pSSDBpS21SdG1CYjRkb1pPQ0p2REtyODBwNG1vZzZZMWdsN1BW?=
 =?utf-8?B?cDB5U0hyK0gyRG5sU1VwMmwyby9uV0dmcDlDWlJkZUdzMWtFZkFwb1FMUHhk?=
 =?utf-8?B?d0FuaDBLMVVHQ3l2Ti90cXdMalBFQ3RNV2JvR2l2OEMraGp4ekNrWk1SaDJv?=
 =?utf-8?B?VVpIcU42Qi9NYkFTYktRS252cER2MHkzN3lrZlFLQlRIcXRzbHg1K0w4aWJ5?=
 =?utf-8?B?VTdFbTZMcU8ycjVwcXkxbjZrdG44aFpuaHM2TTl5OElPbmZaM1duWld6a3BH?=
 =?utf-8?B?K0ZkbVZOOVA4V29UdnF6bEYzUFhGc2RJMllvc0JzQlNTaXhQMlhTOEVDVjh5?=
 =?utf-8?B?bVFpUW9yRDg2M050d0VXNk5YalpQaExTQU9HWHhuRWVUUnRQOWJ0bkJhWFhL?=
 =?utf-8?B?akZubHFSZ0wvS3ZlSkFlaUh5K0RTZ2NDSmFyS3E4My83TnJHRzFwei9LUFZS?=
 =?utf-8?B?WnU5cnY4N3FQd1Evb0lFdzh5NjRPTkpCVHkrZkhTbXpXbk9Pc3NHQ1JGK3cz?=
 =?utf-8?B?Y2c4b3h0SHhyWTdUODIwOTdaYmZhK2pTdmRSemprMUFrZERSSWgrdHR1S0hP?=
 =?utf-8?B?amFBNU9ON3lySUdVbFN5bHBxUmVmQmZuZi85dFNoMUtaQW9IUjloOGhwVTl4?=
 =?utf-8?B?bFBGT1dyZ05BOWpJTVhKWmlOVEFlKzV1ZWdwZzU1cmRMYmlRRjZEb2M4S0dG?=
 =?utf-8?B?UUErbmdubm9vZXUrVmNjWWZpZU5SeURhVTQzY0NwcFN1cjJKWFpqLzNjS1do?=
 =?utf-8?B?SXlmTmFyN0tab0lFYm1xNzl6SUpEcmViL3JVTVp5KzA1VzJyWjNubUdzWGo4?=
 =?utf-8?B?UG9ueGRMUkZ5VUt1bitQb3ZvYnE3OGZQVUFyWElsN01RWk1XWTdySnA0cTNO?=
 =?utf-8?B?aFQyRzl1VEtya1o5enNNdHYyZTh4VEE5TElURUpra1oyb1FKekI0MG1xMlNr?=
 =?utf-8?B?c1l1bi9DQWxCOFVLNVlqTFh3dW1uYUxlalRZSjEyS3hEeXhpeERWSHhBUnRV?=
 =?utf-8?B?cERhSTdBWkY2V1VzVStkZHdZS0ZFM1BWWFpVYWtkSkxnSkxVOGFxK2puTGFo?=
 =?utf-8?B?bVovQ3lsaitKbnZlNWxQQ25INWZrNklKN243a2Fub3d2c3hsUnU4UWwycWxR?=
 =?utf-8?B?M0tKY2MyclRhd2cvZzc4ZXAxTUo5WU5hMWxjMFpETXBncWtCTGdVQm5EdGx5?=
 =?utf-8?Q?dq2A=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: a2cbfeee-e690-4320-3183-08ddad6429b6
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2025 05:59:46.3984
 (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: i2muESd8YHog9/3xlJU0SO2YABRV59MeHtrGl8xsUOdWflxQ38EogBFf3XzjkZPTj8PmSF3jBIzW3ziK8mWUGQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB7871

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYXNvbiBB
bmRyeXVrIDxqYXNvbi5hbmRyeXVrQGFtZC5jb20+DQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVuZSAx
MSwgMjAyNSA0OjAzIFBNDQo+IFRvOiBQZW5ueSwgWmhlbmcgPHBlbm55LnpoZW5nQGFtZC5jb20+
OyB4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcNCj4gQ2M6IEh1YW5nLCBSYXkgPFJheS5I
dWFuZ0BhbWQuY29tPjsgSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KPiBTdWJqZWN0
OiBSZTogW1BBVENIIHY1IDA1LzE4XSB4ZW4vY3B1ZnJlcTogcmVmYWN0b3IgY21kbGluZSAiY3B1
ZnJlcT14eHgiDQo+DQo+IEhpIFBlbm55LA0KPg0KPiBPbiAyMDI1LTA1LTI3IDA0OjQ4LCBQZW5u
eSBaaGVuZyB3cm90ZToNCj4gPiBBIGhlbHBlciBmdW5jdGlvbiBoYW5kbGVfY3B1ZnJlcV9jbWRs
aW5lKCkgaXMgaW50cm9kdWNlZCB0byB0aWR5DQo+ID4gZGlmZmVyZW50IGhhbmRsaW5nIHBhdGhl
cy4NCj4gPiBXZSBhbHNvIGFkZCBhIG5ldyBoZWxwZXIgY3B1ZnJlcV9vcHRzX2NvbnRhaW4oKSB0
byBpZ25vcmUgYW5kIHdhcm4NCj4gPiB1c2VyIHJlZHVuZGFudCBzZXR0aW5nLCBsaWtlICJjcHVm
cmVxPWh3cDtod3A7eGVuIg0KPiA+DQo+ID4gU2lnbmVkLW9mZi1ieTogUGVubnkgWmhlbmcgPFBl
bm55LlpoZW5nQGFtZC5jb20+DQo+DQo+ID4gQEAgLTExNCwyMCArMTYxLDE0IEBAIHN0YXRpYyBp
bnQgX19pbml0IGNmX2NoZWNrDQo+ID4gc2V0dXBfY3B1ZnJlcV9vcHRpb24oY29uc3QgY2hhciAq
c3RyKQ0KPiA+DQo+ID4gICAgICAgICAgIGlmICggY2hvaWNlID4gMCB8fCAhY21kbGluZV9zdHJj
bXAoc3RyLCAieGVuIikgKQ0KPiA+ICAgICAgICAgICB7DQo+ID4gLSAgICAgICAgICAgIHhlbl9w
cm9jZXNzb3JfcG1iaXRzIHw9IFhFTl9QUk9DRVNTT1JfUE1fUFg7DQo+ID4gLSAgICAgICAgICAg
IGNwdWZyZXFfY29udHJvbGxlciA9IEZSRVFDVExfeGVuOw0KPiA+IC0gICAgICAgICAgICBjcHVm
cmVxX3hlbl9vcHRzW2NwdWZyZXFfeGVuX2NudCsrXSA9IENQVUZSRVFfeGVuOw0KPiA+IC0gICAg
ICAgICAgICByZXQgPSAwOw0KPiA+ICsgICAgICAgICAgICByZXQgPSBoYW5kbGVfY3B1ZnJlcV9j
bWRsaW5lKENQVUZSRVFfeGVuKTsNCj4NCj4gRG8gd2UgbmVlZCB0byBjaGVjayByZXQgYW5kIGVy
cm9yIG91dD8gIChhbmQgYmVsb3cpDQo+DQoNClJpZ2h0LCB3ZSBuZWVkLCB0aGFua3MsIHdpbGwg
Zml4DQoNCj4gVGhhbmtzLA0KPiBKYXNvbg0KPg0KPiA+ICAgICAgICAgICAgICAgaWYgKCBhcmdb
MF0gJiYgYXJnWzFdICkNCj4gPiAgICAgICAgICAgICAgICAgICByZXQgPSBjcHVmcmVxX2NtZGxp
bmVfcGFyc2UoYXJnICsgMSwgZW5kKTsNCj4gPiAgICAgICAgICAgfQ0KPiA+ICAgICAgICAgICBl
bHNlIGlmICggSVNfRU5BQkxFRChDT05GSUdfSU5URUwpICYmIGNob2ljZSA8IDAgJiYNCj4gPiAg
ICAgICAgICAgICAgICAgICAgICFjbWRsaW5lX3N0cmNtcChzdHIsICJod3AiKSApDQo+ID4gICAg
ICAgICAgIHsNCj4gPiAtICAgICAgICAgICAgeGVuX3Byb2Nlc3Nvcl9wbWJpdHMgfD0gWEVOX1BS
T0NFU1NPUl9QTV9QWDsNCj4gPiAtICAgICAgICAgICAgY3B1ZnJlcV9jb250cm9sbGVyID0gRlJF
UUNUTF94ZW47DQo+ID4gLSAgICAgICAgICAgIGNwdWZyZXFfeGVuX29wdHNbY3B1ZnJlcV94ZW5f
Y250KytdID0gQ1BVRlJFUV9od3A7DQo+ID4gLSAgICAgICAgICAgIHJldCA9IDA7DQo+ID4gKyAg
ICAgICAgICAgIHJldCA9IGhhbmRsZV9jcHVmcmVxX2NtZGxpbmUoQ1BVRlJFUV9od3ApOw0KPiA+
ICAgICAgICAgICAgICAgaWYgKCBhcmdbMF0gJiYgYXJnWzFdICkNCj4gPiAgICAgICAgICAgICAg
ICAgICByZXQgPSBod3BfY21kbGluZV9wYXJzZShhcmcgKyAxLCBlbmQpOw0KPiA+ICAgICAgICAg
ICB9DQoNCg==


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 06:17:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 06:17:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017724.1394717 (Exim 4.92)
	(envelope-from )
	id 1uRPdX-0004Zw-Ix; Tue, 17 Jun 2025 06:17:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017724.1394717; Tue, 17 Jun 2025 06: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 1uRPdX-0004Zp-G2; Tue, 17 Jun 2025 06:17:35 +0000
Received: by outflank-mailman (input) for mailman id 1017724;
 Tue, 17 Jun 2025 06:17: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 1uRPdW-0004Zj-JT
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 06:17:34 +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 c0ce8a74-4b42-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 08:17:32 +0200 (CEST)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-453066fad06so39425575e9.2
 for ; Mon, 16 Jun 2025 23:17:32 -0700 (PDT)
Received: from ?IPV6:2003:ca:b711:f21a:fe:66b6:9dc3:86d6?
 (p200300cab711f21a00fe66b69dc386d6.dip0.t-ipconnect.de.
 [2003:ca:b711:f21a:fe:66b6:9dc3:86d6])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4532e243e59sm162872685e9.19.2025.06.16.23.17.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Jun 2025 23:17:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c0ce8a74-4b42-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750141052; x=1750745852; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=j+cvENjQSVy6AR3VFR9VvG6CKctBWzuWV9105hi+jVU=;
        b=MoDSUvkovtR7p3U80ocUy6cPrIg/K4NdOwbCsQsDLSi/tA1UTSQA7vKmWPUSqTEUwF
         zRgSqQzk6iY3m5RaZrwJs1ZbcsZwj7dF99qC6Q2UMoS11N5wYMEJxqd0gm4wyMnFmJzP
         5DRFDjPB0gknSDdhuuNp8Ey7x038ikka2R08tiacPLNi2UFFvoTTMLLslO3mg8E7qMVr
         EhO2JEJ3INmyYZMtNwrcmdSa7+BoprBZCvtSUfsaQKCHTXA468+xtlGX15CfUFz/E6nv
         M1MW2RBEKmutm6+dAgyw3OxEzqwLJM9g22y+n8rllyau8xR2JiaVY4ClY9JlrVU9nc5Y
         3vug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750141052; x=1750745852;
        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=j+cvENjQSVy6AR3VFR9VvG6CKctBWzuWV9105hi+jVU=;
        b=X2Nj6eR72K/bcO1yDQ3Aa3+g2+JO590MGm3nEXktJ6bMG3ar+Nb5xugQtL6qYyC5Q8
         8rYlictpe4+hpPPe6JtEVvlLozQIXa5Kej/fH+iR+ENnUrCUlB/1q7AIgO8nMiIcGh06
         QMXrj9WFRRGLpwW9l18Hv7/VLEHFcEUjWIXRG9OxYsv5a6hTt6hYo2uVwUD98C74rZME
         ohqPRNO8QnlgkVvgIm7I1Uvw83+KIfBoAktinstcuy8cgvERzoHR61hk5HWWVrN/Sj5w
         fO4frkm5YNXo53LUahLRDcGS1AyFALy0wJtHhayjOyBb+S7qvjb2ph7zCJjFBtyxpNf/
         vaFw==
X-Forwarded-Encrypted: i=1; AJvYcCXJMSAS1pwkYdJy2hKvzeTMA67Rx5jFigznqiGVQp5ZsxpRhOR774Qv5qqGXDgM5CNoY/d3MaYD/qY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw/Up27pVL5AcR8woEvFXXM2mK/9NheCTDQA3v/4EF+X6cXshal
	JS+4yPSTXFHtwOJRd5FlhY/aiezrT81w+q8It5wVW6Tumh5/lX6vyg+1ZtpKDP0g6g==
X-Gm-Gg: ASbGnctid5BOsSlLfGhCFBZibwIV2/KLTrPUHE+mrGyh1awe7pQza46BIoxjns0Hxhx
	VIfME+eLARFEYxaP/UkNNH5lsFCigcBTnBpqyWz5RgGI+tdRSj5lMw2NbZuFyFGAdFYufa58F2c
	tAjmd8d+ewrni0OlR3nLAD0xVRrhRQzsD7QCfDnaNG2TjOd2UdMGa9uLARIBpP4zM6mqRerpCOu
	WLTYUC4OtRc7EYlfkkwX4Tyi2z3969dD72SOlA4wFrD2LfIrEGxqdc9GdldMsp8WKBvd9veu7Ym
	MBUDV+7ThgciGJMgcas55f9n7/T0SYjp2MzTebdN7JO1tQKr2sBkUCwTSllYA+XMx35PWHQmP8z
	gWyigFUTDsJehmqfIpVRmQvMVIyHMhddQVm+yHch9lei385UfpKdVT7NWt8tFm5QN/QWcNxwBWM
	W8Ofn5INDP2zIKwzA=
X-Google-Smtp-Source: AGHT+IFlBHcJwxNmB5dE8FBMuuD+3OJX7kazG0LZHXwJnfUv1JOT/WsWHXsqYU/6/415jw52oN3x8w==
X-Received: by 2002:a05:600c:8b26:b0:43c:fe5e:f040 with SMTP id 5b1f17b1804b1-4533cab1613mr89633665e9.23.1750141051824;
        Mon, 16 Jun 2025 23:17:31 -0700 (PDT)
Message-ID: 
Date: Tue, 17 Jun 2025 08:17:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 14/14] kconfig: Allow x86 to pick CONFIG_DOM0LESS_BOOT
To: Stefano Stabellini ,
 Alejandro Vallejo 
Cc: Julien Grall , xen-devel@lists.xenproject.org,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 Michal Orzel ,
 Bertrand Marquis ,
 "Daniel P. Smith" 
References: <20250613151612.754222-1-agarciav@amd.com>
 <20250613151612.754222-15-agarciav@amd.com>
 <2a54e49b-c1ad-4654-9291-4373e92580ff@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: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17.06.2025 01:39, Stefano Stabellini wrote:
> On Mon, 16 Jun 2025, Alejandro Vallejo wrote:
>> On Mon Jun 16, 2025 at 10:00 AM CEST, Julien Grall wrote:
>>> Hi,
>>>
>>> On 13/06/2025 16:13, Alejandro Vallejo wrote:
>>>> Without picking CONFIG_HAS_DEVICE_TREE.
>>>>
>>>> In order to do that. Allow CONFIG_DOM0LESS_BOOT to enable a subset
>>>> of the common/device-tree/ directory. 
>>>  > x86 doesn't want dom0less-build.c,> as that's tightly integrated 
>>> still to the ARM way of building domains.
>>>
>>> I don't understand this argument. dom0less-build.c was moved to common 
>>> and it will soon be used by RISC-V. This raises the question what's so 
>>> special with x86?
>>
>> That's 2 separate matters:
>>
>>   1. dom0less-build.c not being compiled in.
>>   2. CONFIG_DOM0LESS_BOOT enabling use of DT code without CONFIG_HAS_DEVICE_TREE.
>>
>> (1) is a matter of not wanting to boil the ocean upfront. The way x86 and
>> everyone else build domains is just different and duplicated in non-trivially
>> consolidable ways. The goal here is to enable the domain builders in any arch
>> to use the same backbone. I don't want to go the extra mile just yet to unify
>> domain construction (though in time I will want to).
>>
>> (2) has to do with compiling OUT things I really cannot have around. Anything
>> involving devices described in a DT must not exist on x86, because it has no
>> concept of a "struct device".
>>
>> My intent is/was to repurpose CONFIG_HAS_DEVICE_TREE to mean "this hypervisor
>> goes on a platform that gives a platform-describing DT". On x86 that's given by
>> DSDT/SSDTs with ACPI.
> 
> Alejandro is suggesting two levels of Device Tree support:
> 
> - full DT support, including device discovery via DT
> - minimal DT support, for the dom0less/hyperlaunch configuration
> 
> Reading this series, it looks reasonable to me, at least as a stepping
> stone. I think it is expected that the kind of DT support needed by an
> architecture like ARM or RISC-V is different from the one needed by an
> architecture like x86. Of course we might be able to align things even
> more in the future but as of today I think it is reasonable to
> distinguish between the two.
> 
> That said, we might want to consider renaming or changing the kconfig
> options. For instance:
> 
> - CONFIG_HAS_DEVICE_TREE -> enable minimal DT support
> - CONFIG_DT_DEVICE_DISCOVERY -> device discovery via DT
> 
> In this model, all architectures would have CONFIG_HAS_DEVICE_TREE,

In which case - do we still need HAS_DEVICE_TREE?

Jan

> but
> only ARM and RISC-V would have CONFIG_DT_DEVICE_DISCOVERY.


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 06:19:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 06:19:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017730.1394726 (Exim 4.92)
	(envelope-from )
	id 1uRPfp-00057g-VE; Tue, 17 Jun 2025 06:19:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017730.1394726; Tue, 17 Jun 2025 06:19: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 1uRPfp-00057Z-ST; Tue, 17 Jun 2025 06:19:57 +0000
Received: by outflank-mailman (input) for mailman id 1017730;
 Tue, 17 Jun 2025 06:19: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 1uRPfn-00057K-So
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 06:19:55 +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 1521b23d-4b43-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 08:19:54 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3a5123c1533so2993195f8f.2
 for ; Mon, 16 Jun 2025 23:19:54 -0700 (PDT)
Received: from ?IPV6:2003:ca:b711:f21a:fe:66b6:9dc3:86d6?
 (p200300cab711f21a00fe66b69dc386d6.dip0.t-ipconnect.de.
 [2003:ca:b711:f21a:fe:66b6:9dc3:86d6])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4533fc6578csm95968035e9.19.2025.06.16.23.19.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Jun 2025 23:19:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1521b23d-4b43-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750141193; x=1750745993; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ALRs4fmk1Q3nugPIiT3bDFR9S6UwtHGaAddsMOx48nQ=;
        b=LrprPPgOPAqFIDOROVNS8zqDGxIz7bbNbu6KwFF9vK9G9SLMAlolQuy1ExXAFqrxaq
         BcSyhpm6z63AStCtoL8ovTYnb9kNKLE60GSrQbgcUhCn5wDX+i0le+kdZ+P5lIWwDC2L
         uLgy9P8XR+fJ4DaN1+//AFaJo+BW5R0VzsyOiCgTcGaHA8xw4Gd9XwnYPyhJaYplPXp5
         KowB8L4uuNJuPkUSir3XhDA84Idk43E4Jt+rZ0IY2rhipp8FgvNWXJavpxNbE+p4xodi
         thGlyIqZofiwP63OvYCTqGa3dmhcbyS9jnBrVP/60Vsi2HxSdTkJMF89AYGBMJKvh0R4
         cKCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750141193; x=1750745993;
        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=ALRs4fmk1Q3nugPIiT3bDFR9S6UwtHGaAddsMOx48nQ=;
        b=vZij7K/RZQES8jn+FuKblyrtTLe/KMj7tzBt65SCHMX3hQuk0L/bdTvCdOf8xq017Q
         pg4+XQ54GhVI45FgUkzhyoMIqRAl9R0IfB6BWScM+DlTBsdNtYke6kEVWjgHYXXkLial
         cB+AXWggZJA3qG4J402HxAzmn2/Z/Pyg3TVHBCsC8h7TbZm1fPfvMwae9eSQaZifEiN4
         4STa3gI9htTXmDTlTFDjdt0XAX6kAEvCPx/xBDQTMvOBQyWeTzIKpIQicTYpbwHLGjBK
         TUjoB/f294F6uq5hNRbk0vHjFb49xwA/C6XhFBsew1E6lakbNWMngrAYTxvd2Ucy2hE5
         Qwlg==
X-Forwarded-Encrypted: i=1; AJvYcCWn1PG8gtWmM+nDCJvUPauMHdw55gGIxyeBG3z8Beb5bEPyxQo5U/yzqyGtZALU31lAhg3FfX8kNyQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzCowR5x+A1HjdHclzsJozmXf4yNOn4o5JZStw72eM1gBX6sGRX
	rIFaklAUBaxH9kdIosdnraNWvM4dEB9Z55Ujl3ButalGs+g0YBYzY3USYKxcw9T12A==
X-Gm-Gg: ASbGncsJlaYrwj1s8JzEj0ErCy5HbeiJs5zXZExtb0HfOGh1q6W6znDyc9as6R7lt5n
	LBQ1sQCCk99TjKo4v8mpK016cHlOiq+OHdJlMOFRQxmG1N4k2osXKLUlutFPTgcPaD01lVzcxp4
	8q+86F5A08Xi0eGPtaTmjMwWy+2CfP70PzxhTOkonVzXd0ptfH/iMtM/VfmW+Hzh0zexOjZZHvR
	cVBsIIjVy5+xQiDNsWpdhsrOv2x1/NzbUnE5WCc/PNBIALhrhmmsVK8T1l/09Gv328ONG3r6qEX
	GiUrjj44gFKIO04Uwd7jwekG4w8dQOBWSW87GcUjkQemCqZOHEkGpYZAivZhcJg78GqeXP3oOvu
	G1alpZcbS9xClRRhvhX7CGemsQc+FqZm2dy+RAJ1z2o9c2oZvfo29AeM+wtOq1U3RKK8KrHZ7pB
	GCZeNK7UI/5cGFLO8=
X-Google-Smtp-Source: AGHT+IFXBgUPGTuHt0KPiOAOpdj0QiXbrr9arIjTOHRbPSXK4lSbODGK04pKIFeGwWxuaPOPzcWcMw==
X-Received: by 2002:a05:6000:26ca:b0:3a5:2f23:3780 with SMTP id ffacd0b85a97d-3a5723a2dbamr9748671f8f.18.1750141193311;
        Mon, 16 Jun 2025 23:19:53 -0700 (PDT)
Message-ID: 
Date: Tue, 17 Jun 2025 08:19:51 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v8] xen/domain: rewrite emulation_flags_ok()
To: dmkhn@proton.me, roger.pau@citrix.com
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, sstabellini@kernel.org, teddy.astie@vates.tech,
 dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250617011519.55386-1-dmukhin@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: <20250617011519.55386-1-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17.06.2025 03:15, dmkhn@proton.me wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -743,32 +743,75 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
>      return 0;
>  }
>  
> +/*
> + * Verify that the domain's emulation flags resolve to a supported configuration.
> + *
> + * This ensures we only allow a known, safe subset of emulation combinations
> + * (for both functionality and security). Arbitrary mixes are likely to cause
> + * errors (e.g. null pointer dereferences).
> + *
> + * NB: use the internal X86_EMU_XXX symbols, not the public XEN_X86_EMU_XXX
> + * symbols, to take build-time config options (e.g. CONFIG_HVM) into account
> + * for short-circuited emulations.
> + */
>  static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
>  {
> +    enum domain_capability {
> +        CAP_PV          = BIT(0, U),
> +        CAP_HVM         = BIT(1, U),
> +        CAP_HWDOM       = BIT(2, U),
> +        CAP_DOMU        = BIT(3, U),
> +    };
> +    static const struct {
> +        enum domain_capability caps;
> +        uint32_t min;
> +        uint32_t opt;
> +    } configs[] = {
> +#ifdef CONFIG_PV
> +        /* PV dom0 and domU */
> +        {
> +            .caps   = CAP_PV | CAP_HWDOM | CAP_DOMU,

Just to double check - are we sure Misra / Eclair will like this (ab)use
of an enum?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 06:54:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 06:54:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017745.1394738 (Exim 4.92)
	(envelope-from )
	id 1uRQCh-0001r6-BZ; Tue, 17 Jun 2025 06:53:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017745.1394738; Tue, 17 Jun 2025 06: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 1uRQCh-0001qz-7D; Tue, 17 Jun 2025 06:53:55 +0000
Received: by outflank-mailman (input) for mailman id 1017745;
 Tue, 17 Jun 2025 06: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 1uRQCg-0001qt-4n
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 06:53:54 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d45c299e-4b47-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 08:53:52 +0200 (CEST)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 (Authenticated sender: nicola)
 by support.bugseng.com (Postfix) with ESMTPA id C8A064EE7C1C;
 Tue, 17 Jun 2025 08:53:51 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d45c299e-4b47-11f0-a309-13f23c93f187
Authentication-Results: bugseng.com; arc=none smtp.remote-ip=162.55.131.47
ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1750143231;
	b=gZfktH5TiOXRPiSsNnIcawv9QwZjwTdA9ZSRmmzunsqe52jOGk33n/lE/I7+F6UnMdSh
	 wT/WemMC3qJORpmc1B5+9VVIjnAjvSejytAruHgkpVB98OltAbS+fOfGFmVzAH3IzFJLD
	 iXfiFKTzACD4KZMbC1LmKiMTegMFNH1mWpYfC5XmOyRIluPiXrpOpBd+Ynprae/V+tlHB
	 3KhjXwolbFF9LRqIxlZLAQiG2o2OgmquVNyz9Ug6KKMMy6axA0i3Q1aoWLlV7iI8ZYOjJ
	 RzFixUasbrWyaKhm1fP2Vn5Zqj2lXGPS7fY335bOTrDXugIEib68hfFdbwturb2JjMNAW
	 UI6HZcSudyUWbHcUkXt+EZmh1L+US08TwGPtAnzMNj5pkneDCEpoAurau15IW9scpRXYr
	 R4tgZf+sosQQaZcvNA/8UTaZU7RPgfJpu2Ym/47p/dz45WFi4toWaKuNRMHS98BDOdGty
	 pxXLHa6yHQtu583x72kfLqSdVFJjS6SZJM4HhO4i9DvgRM50eanCMcA8m2OnMXxwmxDc/
	 ZDRkKgEKhHyHZgzaMQv3O+PBsEFthbE3PF7MCch8zVFT7FO/dUy5CjT/eqSuW5YJU8FrX
	 UxChwkpP/LlzUjEfhQDem2NDKQeN0gFqU7Iaw+H8VjRe8sIZ7zDZFsCNDtw+294=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1750143231;
	h=DKIM-Signature:MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:
	 References:Message-ID:X-Sender:Organization:Content-Type:
	 Content-Transfer-Encoding;
	bh=S03k3Fmg7265fhYKh78nbXNwDP7Tiwoipxv7pXiHa1Q=;
	b=WwFcghydvrwBu46H5sBI7e8W1jezRKS7i6rPEVk1bafM9hOIOBf/b2pioeOFKD+lEoL+
	 znE1jdYBzWZHO4F9r3Ix9G9PGFMbZhJj//njk2VN7dAh5QI1ewVRkyp59H9IZiq/gsuq7
	 EPwl1rLObOXLj0/F59uJEdxdRxu6O9LFuGgaBDgEp3VSSa0K6f1YDr9IadAX9piuDb6wg
	 61tZoTKzOU+EcoJUzxA+zIxwE5x4jlrrpPzyptRKcST8s8Mgqu201s2/rK3QTihvKrNTx
	 YjOfQ4o1qVGKIEWTYOFtJwfgZsGgaljWqQeiBnknAclGcPsO5fViN+RCEmIwKuov1yIAJ
	 x1w5euFNNDFQmlLUGpMTtL2mITfVAN8W3cDr7QUTzLdiOPouTCGE1XDtYJrV9B0FWQVNM
	 Ld34M+a9uaSoQdkca4R1qpWSTLyPbcIdSQRXWu4v7S9+hHcdZ9Ksgak6HM/MelF0/sk1V
	 9VfVWMOUCVZFp9jbCLOzGFT+Kv4z9cRmCwdA5Aj2z0NsZLF8/9bgbKxHXtMwTOysH3e1u
	 7nUxpj7o4AaZ0ROgQjDmEUIV27ZehRNd6Rs9nzlFzSXFKlZlxr7KdIhJ8e1K8qC6fc8Zk
	 BcrHYxCMVFarZ9/wcTn6cYAghJI+3QXR9zfgfr5rGq148hl/BESGG3a4A2tLRtg=
ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1750143231; bh=/nJ/eYz09zkR/gCLYXtdlWHqP/b6YHgk+W4MIan9/lM=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=opWKoyFY8Qavl0RdwcfzCoUnjVqDBMO+QVnDmRSPkz6u7J8Jvu5KekA85n97vMV5l
	 Fq0nkoaRBgSNFIuGTiyXCQUeeSh3mfz0SWqwoUa9IQcOe+mosOKIfiweXihJckilxz
	 iwblcu0gfSKcOQQf0XPbALqHlsByjnTgTIEggczjQKkr1xMb0wUqfLpk4FGi5uO8m9
	 aaw1I/3ud5de3DoCMZyksudiwA78Sz6BiGOLp5lErr41tCi6TxRSsN8wn4d54hTzEP
	 MJi1/YEHNhV9IVebMlFzJM4QmF1NogiHVE7VPICUjQfqVkxc/imxja8BgmXOGfnmtq
	 q/wPaRgF2m/Vg==
MIME-Version: 1.0
Date: Tue, 17 Jun 2025 08:53:51 +0200
From: Nicola Vetrini 
To: Jan Beulich 
Cc: dmkhn@proton.me, roger.pau@citrix.com, andrew.cooper3@citrix.com,
 anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com,
 sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com,
 xen-devel@lists.xenproject.org
Subject: Re: [PATCH v8] xen/domain: rewrite emulation_flags_ok()
In-Reply-To: 
References: <20250617011519.55386-1-dmukhin@ford.com>
 
Message-ID: 
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 2025-06-17 08:19, Jan Beulich wrote:
> On 17.06.2025 03:15, dmkhn@proton.me wrote:
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -743,32 +743,75 @@ int arch_sanitise_domain_config(struct 
>> xen_domctl_createdomain *config)
>>      return 0;
>>  }
>> 
>> +/*
>> + * Verify that the domain's emulation flags resolve to a supported 
>> configuration.
>> + *
>> + * This ensures we only allow a known, safe subset of emulation 
>> combinations
>> + * (for both functionality and security). Arbitrary mixes are likely 
>> to cause
>> + * errors (e.g. null pointer dereferences).
>> + *
>> + * NB: use the internal X86_EMU_XXX symbols, not the public 
>> XEN_X86_EMU_XXX
>> + * symbols, to take build-time config options (e.g. CONFIG_HVM) into 
>> account
>> + * for short-circuited emulations.
>> + */
>>  static bool emulation_flags_ok(const struct domain *d, uint32_t 
>> emflags)
>>  {
>> +    enum domain_capability {
>> +        CAP_PV          = BIT(0, U),
>> +        CAP_HVM         = BIT(1, U),
>> +        CAP_HWDOM       = BIT(2, U),
>> +        CAP_DOMU        = BIT(3, U),
>> +    };
>> +    static const struct {
>> +        enum domain_capability caps;
>> +        uint32_t min;
>> +        uint32_t opt;
>> +    } configs[] = {
>> +#ifdef CONFIG_PV
>> +        /* PV dom0 and domU */
>> +        {
>> +            .caps   = CAP_PV | CAP_HWDOM | CAP_DOMU,
> 
> Just to double check - are we sure Misra / Eclair will like this 
> (ab)use
> of an enum?
> 
> Jan

Likely not, but x86_64 is build with CONFIG_PV=n

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 07:09:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 07:09:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017765.1394751 (Exim 4.92)
	(envelope-from )
	id 1uRQRh-0003nL-Jk; Tue, 17 Jun 2025 07:09:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017765.1394751; Tue, 17 Jun 2025 07:09:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRQRh-0003nE-GZ; Tue, 17 Jun 2025 07:09:25 +0000
Received: by outflank-mailman (input) for mailman id 1017765;
 Tue, 17 Jun 2025 07:09: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 1uRQRf-0003mM-UH
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 07:09:24 +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 fe03ae6b-4b49-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 09:09:21 +0200 (CEST)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-6097b404f58so2031422a12.3
 for ; Tue, 17 Jun 2025 00:09:21 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-608b4adea28sm7349891a12.69.2025.06.17.00.09.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Jun 2025 00:09:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fe03ae6b-4b49-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750144161; x=1750748961; 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=bEeP4aV8ba20MLCuov8VPQ/W6UufLD63nz1kwE8kDM8=;
        b=UrdYiyNN8x6PJfw6pWtVTEAanH14tEC+oYRJv31aOZY5plXikbY1BakTKx6z00xlYg
         JaTc1PGHT6zhLNrOeHx7jx5pYhs5CWGPK4cCKjjPtGpj2KgtcgnFv8YXrnRrREU2rR5s
         tRanvR2myXDd/BWmBiYeL4HBWkNeb7Ymr9mdKen2K20cBlyBfJG/8xnZggITlNPzvuj1
         BGZFkDkyEz7JshaGgSXCZM9lnMHJalweAPczZP6qg2JUdKb4JkA0zVf2UptbwC4MZPAK
         7mNZWYk3TnQyP74FSzKho3I7XN4IikShU98lg9Y4k8sR0ddZoiWPYY0rPn6vIDoZsVQQ
         RyDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750144161; x=1750748961;
        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=bEeP4aV8ba20MLCuov8VPQ/W6UufLD63nz1kwE8kDM8=;
        b=P9uXj+uM0hQgUqn2wYffNYrO90Hdzn5ZNOHW9ECCGzpslmup1y/1mg4ffhnblxUh1u
         oDKxBEdzD++KmRtjJMdq2QQTGyVs4jxq7fieBUbPXFu4w/HLEDk7L8mGuCP+fL2Zfy1c
         6H/6DmBHKp1xww0Onm1KuYO1MDQvqj2FErqP41lMYYjihEWU2p+VktfvVNrrqMFvPg65
         smEY/HIb2Oddc5oDGTk5Sn903RBVj2sdqdY7zQCD0AAuIjKZtH0YddDsy78dqzLYkkT9
         6I+DxPIwHLspHhZb1Sqm1/37c+8YW6CAr8cCP6H1r4KkcwKSNpQf4kzXiXwwBFssOpZd
         ADHg==
X-Forwarded-Encrypted: i=1; AJvYcCVTcdDOdRb04RNI7bpI8bsQLhZ1yRLyKScxKbbhQ8jr3YU0wojLxWwtYinAB+KgTosox2qJ/uSjA+c=@lists.xenproject.org
X-Gm-Message-State: AOJu0YySFJPHAPhZzVL6ykeXhw0E+HA9G/yVyp7/CCxOD8zantS/iYzr
	7jP5NVdrL9N6OR4OhgeKFHaYUcMdiJrPmT5ebcXw6y8bDxsPOjwWuJtG
X-Gm-Gg: ASbGncvHCCFtg175ClSdmoKiCdeLpx76wSXqvmhSj8L/opC9PKPGXopwlcj6MNfKuCA
	DVOBVLNpGeIBysdKC1DVk7y7GOJPT546aV7iHbAPsawWspvFbjdU6RhsuDw6D0kARyVAre7HsGO
	T40j6x1H05iCQstwJ1d0/6l4lqCxn7rEM6aVsjnQktECpKQY3n0cMKIASitWNUQOINpX+9owJSO
	2wOmBCPmA1K6VVTKJI54lRmskWzHp+bjwVlKODFBwI9mX/9eh4blEuJc9Cw5Y+AYtdSKJBNbbpU
	nUuNaqedozNkGkhiRuJQom8+orFzFVKv3BIaHZMI3uk6JeWzo2icIfxQIiwY4MLt/BtzXcbpzAh
	T/28BaTMntj9wVARFp2OdAtRLf1Yod6g9SBPq1cF1agceHg==
X-Google-Smtp-Source: AGHT+IFf9Lk4JFAOLQ9bBRkot0eXijwQ7ZtO0Uo9kGqH6jEbcELVSX8PwjSuaL3Ew85HiYtbHDtRvA==
X-Received: by 2002:a05:6402:26c7:b0:608:47ee:dc4 with SMTP id 4fb4d7f45d1cf-608d09cf155mr9933526a12.23.1750144160711;
        Tue, 17 Jun 2025 00:09:20 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------B0Qy7QKMeOBJiRuzXBIFI7sN"
Message-ID: <313996d5-8801-4aed-92f8-e96d57dd9429@gmail.com>
Date: Tue, 17 Jun 2025 09:09:19 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 8/8] pdx: introduce a command line option for offset
 compression
To: Roger Pau Monne , xen-devel@lists.xenproject.org
Cc: Community Manager ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , Stefano Stabellini 
References: <20250611171636.5674-1-roger.pau@citrix.com>
 <20250611171636.5674-9-roger.pau@citrix.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <20250611171636.5674-9-roger.pau@citrix.com>

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


On 6/11/25 7:16 PM, Roger Pau Monne wrote:
> Allow controlling whether to attempt PDX compression, and which algorithm
> to use to calculate the coefficients.  Document the option and also add a
> CHANGELOG entry for the newly added feature.
>
> Note the work has been originally done to cope with the new Intel
> Sapphire/Granite Rapids, however the compression is not explicitly tied to
> Intel or x86, and hence could be helpful on other architectures.
>
> Signed-off-by: Roger Pau Monné
> ---
>   CHANGELOG.md                      |  3 +++
>   docs/misc/xen-command-line.pandoc | 22 ++++++++++++++++++
>   xen/common/pdx.c                  | 38 +++++++++++++++++++++++++++----
>   3 files changed, 59 insertions(+), 4 deletions(-)

LGTM: Reviewed-by: Oleksii Kurochko

Thanks.

~ Oleksii

>
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index 23215a8cc1e6..48327f03078f 100644
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -20,6 +20,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>        table or foreign memory.
>   
>   ### Added
> + - Introduce new PDX compression algorithm to cope with Intel Sapphire and
> +   Granite Rapids having sparse memory maps.
> +
>    - On x86:
>      - Option to attempt to fixup p2m page-faults on PVH dom0.
>      - Resizable BARs is supported for PVH dom0.
> diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
> index b0eadd2c5d58..06819576a06b 100644
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -2072,6 +2072,28 @@ for all of them (`true`), only for those subject to XPTI (`xpti`) or for
>   those not subject to XPTI (`no-xpti`). The feature is used only in case
>   INVPCID is supported and not disabled via `invpcid=false`.
>   
> +### pdx-compress
> +> `=  | auto | fast | slow`
> +
> +> Default: `auto`
> +
> +Only relevant when hypervisor is build with PFN PDX offset compression
> +`CONFIG_PDX_OFFSET_COMPRESSION`.
> +
> +Controls whether Xen will engage in PFN compression, and which algorithm will
> +be used to calculate the compression coefficients:
> +
> +* `auto`: default choice, attempt fast calculation of compression
> +  coefficients, if that's not successful fallback to slow calculation.
> +
> +* `fast`: only attempt fast calculation of coefficients, if it fails PFN PDX
> +  compression will be disabled.
> +
> +* `slow`: only attempt slow calculation of coefficients, if it fails PFN PDX
> +  compression will be disabled.
> +
> +Note `pdx-compress=true` is equivalent to `pdx-compress=auto`.
> +
>   ### ple_gap
>   > `= `
>   
> diff --git a/xen/common/pdx.c b/xen/common/pdx.c
> index feabdcded804..5fd01305a7be 100644
> --- a/xen/common/pdx.c
> +++ b/xen/common/pdx.c
> @@ -19,6 +19,7 @@
>   #include 
>   #include 
>   #include 
> +#include 
>   #include 
>   #include 
>   #include 
> @@ -468,11 +469,40 @@ STATIC void __init pfn_offset_sanitize_ranges(void)
>   }
>   
>   #ifdef __XEN__
> +static enum {
> +    PDX_AUTO, /* Fast first, fallback to slow if fast is not successful. */
> +    PDX_NO,   /* Do not attempt compression. */
> +    PDX_FAST, /* Only attempt fast calculation of compression parameters. */
> +    PDX_SLOW, /* Only attempt slow calculation of compression parameters. */
> +} compress_mode __initdata;
> +
> +static int __init cf_check parse_pdx_param(const char *arg)
> +{
> +    int val;
> +
> +    if ( !arg )
> +        return -EINVAL;
> +
> +    if ( (val = parse_bool(arg, NULL)) != -1 )
> +        compress_mode = val ? PDX_AUTO : PDX_NO;
> +    else if ( !strcmp(arg, "auto") )
> +        compress_mode = PDX_AUTO;
> +    else if ( !strcmp(arg, "fast") )
> +        compress_mode = PDX_FAST;
> +    else if ( !strcmp(arg, "slow") )
> +        compress_mode = PDX_SLOW;
> +    else
> +        return -EINVAL;
> +
> +    return 0;
> +}
> +custom_param("pdx-compress", parse_pdx_param);
> +
>   bool __init pfn_pdx_compression_setup(paddr_t base)
>   {
> -    bool use_slow = false;
> +    bool use_slow = compress_mode == PDX_SLOW;
>   
> -    if ( nr <= 1 )
> +    if ( nr <= 1 || compress_mode == PDX_NO )
>           return false;
>   
>       if ( nr > ARRAY_SIZE(ranges) )
> @@ -507,11 +537,11 @@ bool __init pfn_pdx_compression_setup(paddr_t base)
>               dprintk(XENLOG_DEBUG,
>                       "Find PFN compression coefficients using %s algorithm failed\n",
>                       use_slow ? "slow" : "fast");
> -            if ( use_slow )
> +            if ( compress_mode == PDX_FAST || use_slow )
>                   return false;
>           }
>   
> -        if ( use_slow )
> +        if ( compress_mode == PDX_FAST || use_slow )
>               break;
>       }
>   
--------------B0Qy7QKMeOBJiRuzXBIFI7sN
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
    
  
  
    

    
    
    
    
    On 6/11/25 7:16 PM, Roger Pau Monne
      wrote:
    
    
    
    
    
      
    Allow controlling whether to attempt PDX compression, and which algorithm
to use to calculate the coefficients.  Document the option and also add a
CHANGELOG entry for the newly added feature.

Note the work has been originally done to cope with the new Intel
Sapphire/Granite Rapids, however the compression is not explicitly tied to
Intel or x86, and hence could be helpful on other architectures.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
    
    
    
    
    
      
    ---
 CHANGELOG.md                      |  3 +++
 docs/misc/xen-command-line.pandoc | 22 ++++++++++++++++++
 xen/common/pdx.c                  | 38 +++++++++++++++++++++++++++----
 3 files changed, 59 insertions(+), 4 deletions(-)
    
    
    
    
    LGTM: Reviewed-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

Thanks.

~ Oleksii

    
    
    
      
    
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 23215a8cc1e6..48327f03078f 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -20,6 +20,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
      table or foreign memory.
 
 ### Added
+ - Introduce new PDX compression algorithm to cope with Intel Sapphire and
+   Granite Rapids having sparse memory maps.
+
  - On x86:
    - Option to attempt to fixup p2m page-faults on PVH dom0.
    - Resizable BARs is supported for PVH dom0.
diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index b0eadd2c5d58..06819576a06b 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -2072,6 +2072,28 @@ for all of them (`true`), only for those subject to XPTI (`xpti`) or for
 those not subject to XPTI (`no-xpti`). The feature is used only in case
 INVPCID is supported and not disabled via `invpcid=false`.
 
+### pdx-compress
+> `= <boolean> | auto | fast | slow`
+
+> Default: `auto`
+
+Only relevant when hypervisor is build with PFN PDX offset compression
+`CONFIG_PDX_OFFSET_COMPRESSION`.
+
+Controls whether Xen will engage in PFN compression, and which algorithm will
+be used to calculate the compression coefficients:
+
+* `auto`: default choice, attempt fast calculation of compression
+  coefficients, if that's not successful fallback to slow calculation.
+
+* `fast`: only attempt fast calculation of coefficients, if it fails PFN PDX
+  compression will be disabled.
+
+* `slow`: only attempt slow calculation of coefficients, if it fails PFN PDX
+  compression will be disabled.
+
+Note `pdx-compress=true` is equivalent to `pdx-compress=auto`.
+
 ### ple_gap
 > `= <integer>`
 
diff --git a/xen/common/pdx.c b/xen/common/pdx.c
index feabdcded804..5fd01305a7be 100644
--- a/xen/common/pdx.c
+++ b/xen/common/pdx.c
@@ -19,6 +19,7 @@
 #include <xen/mm.h>
 #include <xen/bitops.h>
 #include <xen/nospec.h>
+#include <xen/param.h>
 #include <xen/pfn.h>
 #include <xen/sections.h>
 #include <xen/sort.h>
@@ -468,11 +469,40 @@ STATIC void __init pfn_offset_sanitize_ranges(void)
 }
 
 #ifdef __XEN__
+static enum {
+    PDX_AUTO, /* Fast first, fallback to slow if fast is not successful. */
+    PDX_NO,   /* Do not attempt compression. */
+    PDX_FAST, /* Only attempt fast calculation of compression parameters. */
+    PDX_SLOW, /* Only attempt slow calculation of compression parameters. */
+} compress_mode __initdata;
+
+static int __init cf_check parse_pdx_param(const char *arg)
+{
+    int val;
+
+    if ( !arg )
+        return -EINVAL;
+
+    if ( (val = parse_bool(arg, NULL)) != -1 )
+        compress_mode = val ? PDX_AUTO : PDX_NO;
+    else if ( !strcmp(arg, "auto") )
+        compress_mode = PDX_AUTO;
+    else if ( !strcmp(arg, "fast") )
+        compress_mode = PDX_FAST;
+    else if ( !strcmp(arg, "slow") )
+        compress_mode = PDX_SLOW;
+    else
+        return -EINVAL;
+
+    return 0;
+}
+custom_param("pdx-compress", parse_pdx_param);
+
 bool __init pfn_pdx_compression_setup(paddr_t base)
 {
-    bool use_slow = false;
+    bool use_slow = compress_mode == PDX_SLOW;
 
-    if ( nr <= 1 )
+    if ( nr <= 1 || compress_mode == PDX_NO )
         return false;
 
     if ( nr > ARRAY_SIZE(ranges) )
@@ -507,11 +537,11 @@ bool __init pfn_pdx_compression_setup(paddr_t base)
             dprintk(XENLOG_DEBUG,
                     "Find PFN compression coefficients using %s algorithm failed\n",
                     use_slow ? "slow" : "fast");
-            if ( use_slow )
+            if ( compress_mode == PDX_FAST || use_slow )
                 return false;
         }
 
-        if ( use_slow )
+        if ( compress_mode == PDX_FAST || use_slow )
             break;
     }
 

    
    
    
  


--------------B0Qy7QKMeOBJiRuzXBIFI7sN--


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 07:15:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 07:15:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017783.1394772 (Exim 4.92)
	(envelope-from )
	id 1uRQXU-0005ci-C3; Tue, 17 Jun 2025 07:15:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017783.1394772; Tue, 17 Jun 2025 07:15: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 1uRQXU-0005cb-9U; Tue, 17 Jun 2025 07:15:24 +0000
Received: by outflank-mailman (input) for mailman id 1017783;
 Tue, 17 Jun 2025 07:15: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 1uRQXS-0005cC-Ny
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 07:15:22 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on2062e.outbound.protection.outlook.com
 [2a01:111:f403:2412::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d349f0f5-4b4a-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 09:15:21 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 IA0PPF6483BC7EA.namprd12.prod.outlook.com (2603:10b6:20f:fc04::bcf)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.25; Tue, 17 Jun
 2025 07:15: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.8835.027; Tue, 17 Jun 2025
 07:15: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: d349f0f5-4b4a-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=VCpcOk9HByOvKYkIdV6/Lh9SRutiZ0OxD21EDD4bpMzt5UhABPR1oj9rhZL/y+bCw1cOelFoe4aWjg0udyro4r3ZBeuJWyPjXvLSmMfprmxndjdPLBfoPF0NyTV9lhNmqhUHx4ErLiMVIUgkiAkgCxn3eTCOSlJPuOZkBbkqtuREKbNq2Qa+ezpwRcICfKH0T4hZi/04/iaPEZmnjX0uh+SwtWXP3eTQiwNS/IBPFlz0DIbFsj3UWF2Yv1J6v6wyz4Y/OGIeG0OAhjunlTxTjxpLKNwDLd0y4jZrlwWzj1ib+RxsHxELqzsWfpR3vEP6Kh5/7gAl7t7RnFeMYbGR0A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=pIIWYbo09XV2wspvt9ywdNSEyBMkIvQeHXjtvk3bUsM=;
 b=bmH82fIs/tMKDSOK0XrZQ+y3hpqEbnppI1eeopIC5UBYT8FHoB2VmV1w7yo8mDa96z+nO0nfILs08NikOol2Ks/73lvgVx2pmciRAkwaGkY0sfF9eCrwwP6Ckh9uqVCiUdlEhBj2MZNULcUQYxSkI4RIS1RKoO8YotOx+Q84wy1jC6B6QPjyRMYbnh+BJ0Q9Lyl+8Hvj4m3Ft5K5/iw8xG6X9eBCGoGRWXOhssihkQ3HowH+0FWJ8Dl5Q1oOavX9GZEd9K1jqDWyvWomAGbPQj1EeSffhYMh8RGx7LcB08p3qffjlhQjYYLck716J7QO+ICiszeiCHIIMYSTixLGpQ==
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=pIIWYbo09XV2wspvt9ywdNSEyBMkIvQeHXjtvk3bUsM=;
 b=dQokHpL6UdmvjQp5wsDnU+W0n1jZq/TiEJWEYoYhJfPtQ/1zsFNQKoAfv/XI7b4lDu1IO4aUYh46LGpIY3cvHphOtdRA4JQ+nqhEAiqpzwT4swHj7XUI+xyB5EIJzEpqnuXDirW4rep51VTH8foWQm6vKNBL2dYWqIodlmxCMU8=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Andrew Cooper
	, Anthony PERARD ,
	"Orzel, Michal" , Julien Grall ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano
 Stabellini , "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v5 06/18] xen/x86: introduce "cpufreq=amd-cppc" xen
 cmdline
Thread-Topic: [PATCH v5 06/18] xen/x86: introduce "cpufreq=amd-cppc" xen
 cmdline
Thread-Index: AQHbzuRARq8PSmkmBEm8nuMU3PtyjLP/b5OAgAeOMuA=
Date: Tue, 17 Jun 2025 07:15:09 +0000
Message-ID:
 
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-7-Penny.Zheng@amd.com>
 <3edeeff2-5728-46cc-9436-01e5e3cf2bd3@suse.com>
In-Reply-To: <3edeeff2-5728-46cc-9436-01e5e3cf2bd3@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=True;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-06-17T07:15:03.0000000Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=3;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged
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_|IA0PPF6483BC7EA:EE_
x-ms-office365-filtering-correlation-id: e11c47fe-07a5-4cce-b9be-08ddad6eb1ac
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?eUhVQ0U4b3VHT0JSSDNVT1dnU3puSVYxRzJkc1NlQWpyZmdJQTgwOXZRRW9s?=
 =?utf-8?B?eHJGOWx3OHBBdFB5enB5dTNqTStqbE1yZGswSytOWldSTGd6Q3p2UnRRVmpU?=
 =?utf-8?B?Qll3Rkd6TSttazdsMVhFWGYvNlZjcmdyTzdLd08rT3VETDltOUJWVnhIakxL?=
 =?utf-8?B?akVzdUNFZjVQQzZ4RXZLeDVKNEhkdm9qcGZIMTd5aHN6bUUwUGVLZVI3Qmk3?=
 =?utf-8?B?TlpZR2pNemgrekFlZkMrZ0YyaS9iYWFtdzB3NDgyQW5rVEdsUldIMEpNMEla?=
 =?utf-8?B?YUZXeXJZdU5wbkJYR3NjalBway9ZbzdqUktFQm9Ra29hYUlRd2JvN0tSZ2ty?=
 =?utf-8?B?TzZQOGlOakU1WW8remh4RExRMXBDZ0lUR29sdmdweHFHa2haa2dLQkdDd3dS?=
 =?utf-8?B?ODUvdFhwNmVEckUyN2JVbXJ2cGV5ZmhJTXRuWTlub3EvMTNqZ3ZTb3l0VUph?=
 =?utf-8?B?WGxEWHNBbkNJZ0didnF0QUw4ckhXVG5INXhzSmszVVNVZ1NGOVFnd09ybm9k?=
 =?utf-8?B?N25YYUlOd0xGanNYbGthR3NUVXBXTVBZU2VlUUpPemJtcmtKZFg4QklLWUtO?=
 =?utf-8?B?ODFFVTNNV21odmdmUjJFSWo0RWJ2Nm5ZRStGamtjZjMvbkIwQ3NjdEZicE5y?=
 =?utf-8?B?OUFEMXVaa2N3YkJVZE9GdmpoV1I5aXh5VStxNnlSMzJiWjZXazhnNE1CZHli?=
 =?utf-8?B?SCsrSmROT2JUTUdrdXAycGREaHQwTWFmcHQxQnVRUUV5akl0aXd1VFFxVmtn?=
 =?utf-8?B?YjE5QUVGTVVPUzRwZndIYW9OUHgxU213WmwrKzRGcllsSU9WcHhUcTQvVUVS?=
 =?utf-8?B?T3plSnJmcmdCdGN6UEl4a05IbmVCRGJZTW1lT210OWRUeHJuTzIzeCtQb2F0?=
 =?utf-8?B?bFU5M3BXeHUwRjhpamZCYkxzZWJSQzZiQmtMdndMT0Foc3poV1ZraW92ZjZK?=
 =?utf-8?B?MzlySzczY0dmY0h6ZllMQ2gvYW1FMDFhZHVyVnhOVDl1RU8wYk5GN0JWK3lP?=
 =?utf-8?B?N1M0UEZVUlBEaXFBNDAwVDJacWVVbTgweTJtK3BGRU5UQnQvQjJVcklxbnBP?=
 =?utf-8?B?c05GUFJzTWJ4RFBOTkdqWTdZVDBPeGo5U0pWdGpMUkk1YittdzlRMFhTL0lO?=
 =?utf-8?B?VlV2Q3o5cVJ3TjMrRU04dGNoS2hKR0l0YmRQMTc4UUl6bE5rd0YweTlPQ21C?=
 =?utf-8?B?T09EelZRbW0rMDdMTTlVdjFYR1hmRFhwZWQzNzdibFplN1BiUDV0cmFYOHV1?=
 =?utf-8?B?K01BeFh2UGRZTGc3YTNEaGYrUkQyNmJEeVVkaXBSN1M4MlJxSUYzSDdnbWx1?=
 =?utf-8?B?NWx3R1lQNllRVFA0UEFnRzlkeFh2Y2I2Ny83cUN4a1YxMVdvb21pY3RGZVo5?=
 =?utf-8?B?MHZVYW10UXFtdlJaUWEwcElJdm5hTW1NUHA0RjZUYURNYzhzaTdSakRITGZ4?=
 =?utf-8?B?K0NLWkV3b1ZiNjMvclMwNkMvdytnTWNua2pFK0VTNTBzWjlnZHF4Qnp0aDVJ?=
 =?utf-8?B?dS9XS2lnKzJWek8yUjZGYzYvVUFGUGRUbTh2WDJaZ0FNY0VnQVU3WUg3cFFB?=
 =?utf-8?B?N2hrNEJBODlyeUc1Nk9nUHdrQjBrekY1SmJvN0hTM2JjSmswNWVLVGlRUnU4?=
 =?utf-8?B?N2ZiRVdlNXB0NTEraHFrMUducFY0YlpvYVg0cjk0RTlDM3ZEdk95ZHlTSGg0?=
 =?utf-8?B?eUtmWHFFNEJMQjFRNE9kT2VjRGdJRmNOU0tFSGxuUHpVZzhzR3hVeC9sZUda?=
 =?utf-8?B?SmpXQ1cwT3hKTGh3WklIVHB6OS85NUVZQ25CcVNoNDdPcSs4UzJ3NXNZTDJk?=
 =?utf-8?B?ZVFxdi9sSmNTZE5HVlhvUlhJUEZpam14N0tpQ0g5STBTbEx1Zlc4M21oaVds?=
 =?utf-8?B?dkYxVDM5TkVPMjBCWFFtOWxxUW85N3BhNVRQK0IzeCtFWkd2L1A5c09QSE1P?=
 =?utf-8?B?YWZaYzd0bjI3TjY5cVBYSmF3RlBPK1lCSXh2bFJlVmVzS1k2V0J4SnR3NCt1?=
 =?utf-8?Q?UcnHSffQ8O+GZcU33/qNviaYSyYoOU=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)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?UHgyaXozdzRSbFhTVWhDOTV0K3p3MkdvMmVMdW9iT0hBdjZRNnNMbTQxZ0FF?=
 =?utf-8?B?RE5QcWRVb05JazlvTHozY3JKZ0ZzT0dIYSszUWI3TDVucEs4SDNMb2NJSklv?=
 =?utf-8?B?cndJVjYvQWM2T0R0R3JHSHUyVTlMY2htSjhUNHdTb3JjL2FTTGNCeVA4UEE4?=
 =?utf-8?B?WVdoQWg2T2lpWk9sNlZDQXV2VXJzazBJNzhUU2hydTBBVVpWanlLVzRuMitE?=
 =?utf-8?B?dUlBYlZjcDE0NllXelVGV05YaE9sUTFzWUtSR3Y0bHpYZ1hQWWZ5Z09Ta3F3?=
 =?utf-8?B?cElMQkZHQUNoU3ZYRXhIelhpcE40V2xQMk1nZi9LWlo2QSt1Z3pyQWszT3Vj?=
 =?utf-8?B?a1dxZ0hqOUJEOCs1TTFqNEEzZmYyeFRBbFN5Y0oyNTFZazR6MjJ6bHA4cGVs?=
 =?utf-8?B?V280bDBwTWtOdFhWL0NnUXNGbUw0TWhNSXNUQTVNZXcxZ1V0c3Z5V0hnVUNP?=
 =?utf-8?B?M2t2b2oranFIZ3BjVDM1eUZoTS9FWFJLY0ZXNFFYUGk4UDdoSmhuVnlJQzZX?=
 =?utf-8?B?a2tlU0ZEdCsva1ptcVV6U1NKMHlUc2Z0c0xTaGtJOVdHSVl6dFQwTnZYa3Ur?=
 =?utf-8?B?ZWxSMUkvSmI0QUkxYjhaZ25jVVpRRXM0L2lIRVRRRzBTV2hUejBOMWNBeDZh?=
 =?utf-8?B?cjc1NHlRcEQzUnNMYkQxbWcyR0ZMK1RnSWJRT3BTTUU3RmZVYSsrWE5nY3Iy?=
 =?utf-8?B?eHEwRTVqRFhsRyt3ZkpPSEx2QTBnTXdRWmthUWFWbmsxRE1INW1hL2lGY3oy?=
 =?utf-8?B?NVc4aWMzQ29JWGxZYjVOU1c5UmxZY1NTNjY5eHRDOCttbGYyRzhuL044T1k4?=
 =?utf-8?B?OGNtUGN4QStxeC9wdTFXb0d2NEVWYWY5ZHEvYW5vYzJuZnZsa2h4cFBwdlh4?=
 =?utf-8?B?WmxIUmlqc2dMa2I3cmRwN0dmeXF2aTBMdUVvOEszdkg5aEtmdFRmOWVVdDlr?=
 =?utf-8?B?SzM5SUppUGQzM0VEam9JaUMzSTJZVXZGN1R5Vm1PMkJzVmI1Yjg5Sm1hYm82?=
 =?utf-8?B?UzNJMWcvdGc0T2tlRUdVSkUxcmVwSUMwSkxiYktvUW1wNE9ERTcvNm9LVklJ?=
 =?utf-8?B?Zk4wWGxDZU5jbUlRY1NqdHA1dzd3cWo2clVYeWFSeHFPOGNZWGF0OUZtVi9T?=
 =?utf-8?B?WTUreWNvU01iQXh5MUxXVmpaYVB6Y1NGYkdkYXpqemdZZ0M1YmwydnBhRDFa?=
 =?utf-8?B?SjdxZE5LMjJvWkxwWXNoODFEMEJONnRhQThPRDJ4Z0pUVCtoN2pZZTB6T1gr?=
 =?utf-8?B?dHV4OENUeVNqTWFjWnl1UzBWQjZoN1VDZEFEY0loSzZPS1NFWmxLYW5Kb3h0?=
 =?utf-8?B?cDZmRVBkVmxBRWR1OWNsUEF5elQ3ak1oWFkrSXhPNnJFMVI4R2VoWitYNStB?=
 =?utf-8?B?R0tRV0IvNEVCckl2MGpodEFoSmt0NmJjcnkyWlVmclh2c0pUZnIrR000WGEr?=
 =?utf-8?B?VTZ4Y0E1S3dYSjg1TmkzYkw4eGt4c3U3YWM2RnJYZi9MR09Ud3RyZ2lSTFZS?=
 =?utf-8?B?ZFdmWEV0NDhqQzIxMEw5ZGdRU3NXTVJxbDBWcFB6eHZRRTR3L0lURlR1MFBx?=
 =?utf-8?B?MzdzT1cxbDB0UXNHOUhGRjBpZGxOenBCQ1VXdHBmM0VLZzdJOHI1NVVhMlpE?=
 =?utf-8?B?Snc3SGowdC8ybmd4N1BxQXhKUWJxQms4WXhQM1R6MVFhTFY0M25OQUJYeFVr?=
 =?utf-8?B?c0hRNDVFTC93T3pONDUyVFZIRjNmOVQ1VWpMVWt0eGpqVFB6QTdQMDZidi9t?=
 =?utf-8?B?b3VFc0hwL2JkOVZvOHJ3c1ZnMjU4YjNiWTFCVUhaTUo3dWVjcjVZcFBZdlZF?=
 =?utf-8?B?Q3lYNmUraFNHRUNJdzNXYU4rblF1Z1RONm1NMmx4cStuOUVuZ0FpTHo5RDk2?=
 =?utf-8?B?b0p4NEROTldwVXhXOTRpei9YNG9mdFJaa1V1bWR0ZEhwdlVOUHozeFlRbzZ1?=
 =?utf-8?B?eWJ1VDdIV0g3S3A3K2JRYk5LSlJUQTJObkJuY013ZGtKeVUyYUFyaFZlc3N4?=
 =?utf-8?B?T3lRdVBWelFDRVRnRzl6d0lIV0J4V1I2ZlQwR0xiMmQvVDhpTnU5NXVGZnc4?=
 =?utf-8?B?Qm5SWWFrM1FYaEp4THMzbXcySXFPQ1VEbTRtMzlhMjdYNUh3bFhnd1NtYVQ4?=
 =?utf-8?Q?6nu8=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: e11c47fe-07a5-4cce-b9be-08ddad6eb1ac
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2025 07:15:09.4828
 (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: 6lzcNOgeMB0Ue12aVKvwhlDwAwLoURyC2WDhPHA4W6RLq5ShxWHfBXAXodbZaUeGcbv7dOEwM81lWYIGHxGTfg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PPF6483BC7EA

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDEyLCAyMDI1
IDY6NDIgUE0NCj4gVG86IFBlbm55LCBaaGVuZyA8cGVubnkuemhlbmdAYW1kLmNvbT4NCj4gQ2M6
IEh1YW5nLCBSYXkgPFJheS5IdWFuZ0BhbWQuY29tPjsgQW5kcmV3IENvb3Blcg0KPiA8YW5kcmV3
LmNvb3BlcjNAY2l0cml4LmNvbT47IEFudGhvbnkgUEVSQVJEIDxhbnRob255LnBlcmFyZEB2YXRl
cy50ZWNoPjsNCj4gT3J6ZWwsIE1pY2hhbCA8TWljaGFsLk9yemVsQGFtZC5jb20+OyBKdWxpZW4g
R3JhbGwgPGp1bGllbkB4ZW4ub3JnPjsgUm9nZXIgUGF1DQo+IE1vbm7DqSA8cm9nZXIucGF1QGNp
dHJpeC5jb20+OyBTdGVmYW5vIFN0YWJlbGxpbmkgPHNzdGFiZWxsaW5pQGtlcm5lbC5vcmc+OyB4
ZW4tDQo+IGRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0gg
djUgMDYvMThdIHhlbi94ODY6IGludHJvZHVjZSAiY3B1ZnJlcT1hbWQtY3BwYyIgeGVuDQo+IGNt
ZGxpbmUNCj4NCj4gT24gMjcuMDUuMjAyNSAxMDo0OCwgUGVubnkgWmhlbmcgd3JvdGU6DQo+ID4g
VXNlcnMgbmVlZCB0byBzZXQgImNwdWZyZXE9YW1kLWNwcGMiIGluIHhlbiBjbWRsaW5lIHRvIGVu
YWJsZSBhbWQtY3BwYw0KPiA+IGRyaXZlciwgd2hpY2ggc2VsZWN0cyBBQ1BJIENvbGxhYm9yYXRp
dmUgUGVyZm9ybWFuY2UgYW5kIFBvd2VyIENvbnRyb2wNCj4gPiAoQ1BQQykgb24gc3VwcG9ydGVk
IEFNRCBoYXJkd2FyZSB0byBwcm92aWRlIGEgZmluZXIgZ3JhaW5lZCBmcmVxdWVuY3kNCj4gPiBj
b250cm9sIG1lY2hhbmlzbS4NCj4gPiBgdmVyYm9zZWAgb3B0aW9uIGNhbiBhbHNvIGJlIGluY2x1
ZGVkIHRvIHN1cHBvcnQgdmVyYm9zZSBwcmludC4NCj4gPg0KPiA+IFdoZW4gdXNlcnMgc2V0dGlu
ZyAiY3B1ZnJlcT1hbWQtY3BwYyIsIGEgbmV3IGFtZC1jcHBjIGRyaXZlciBzaGFsbCBiZQ0KPiA+
IHJlZ2lzdGVyZWQgYW5kIHVzZWQuIEFsbCBob29rcyBmb3IgYW1kLWNwcGMgZHJpdmVyIGFyZSB0
cmFuc2llbnRseQ0KPiA+IG1pc3NpbmcgYW5kIHdpbGwgYmUgaW1wbGVtZW50ZWQgaW4gdGhlIG9u
Z29pbmcgY29tbWl0cy4NCj4gPg0KPiA+IE5ldyB4ZW4tcG0gaW50ZXJuYWwgZmxhZyBYRU5fUFJP
Q0VTU09SX1BNX0NQUEMgaXMgaW50cm9kdWNlZCwgdG8gYmUNCj4gPiBkaWZmZXJlbnRpYXRlZCB3
aXRoIGxlZ2FjeSBYRU5fUFJPQ0VTU09SX1BNX1BYLiBXZSBkZWZpbmUNCj4gPiBYRU5fUFJPQ0VT
U09SX1BNX0NQUEMgMHgxMDAsIGFzIGl0IGlzIHRoZSBuZXh0IHZhbHVlIHRvIHVzZSBhZnRlcg0K
PiA+IDgtYml0cyB3aWRlIHB1YmxpYyB4ZW4tcG0gb3B0aW9ucy4gQWxsIHhlbi1wbSBmbGFnIGNo
ZWNraW5nIGludm9sdmluZw0KPiA+IFhFTl9QUk9DRVNTT1JfUE1fUFggc2hhbGwgYWxzbyBiZSB1
cGRhdGVkIHRvIGNvbnNpZGVyDQo+IFhFTl9QUk9DRVNTT1JfUE1fQ1BQQyBub3cuDQo+ID4NCj4g
PiBYZW4gaXMgbm90IGV4cGVjdGVkIHRvIHN1cHBvcnQgYm90aCBvciBtaXhlZCBtb2RlIChDUFBD
ICYgbGVnYWN5IFBTUywNCj4gPiBfUENULA0KPiA+IF9QUEMpIG9wZXJhdGlvbnMsIHNvIG9ubHkg
b25lIGNwdWZyZXEgZHJpdmVyIGdldHMgcmVnaXN0ZXJkLCBlaXRoZXINCj4gPiBhbWQtY3BwYyBv
ciBsZWdhY3kgUC1zdGF0ZXMgZHJpdmVyLCB3aGljaCBpcyByZWZsZWN0ZWQgYW5kIGFzc2VydGVk
IGJ5DQo+ID4gdGhlIGluY29tcGF0aWJsZSBmbGFncyBYRU5fUFJPQ0VTU09SX1BNX1BYIGFuZA0K
PiBYRU5fUFJPQ0VTU09SX1BNX0NQUEMuDQo+ID4NCj4gPiBTaWduZWQtb2ZmLWJ5OiBQZW5ueSBa
aGVuZyA8UGVubnkuWmhlbmdAYW1kLmNvbT4NCj4gPiAtLS0NCj4gPiB2MSAtPiB2MjoNCj4gPiAt
IE9iZXkgdG8gYWxwaGFiZXRpYyBzb3J0aW5nIGFuZCBhbHNvIHN0cmljdCBpdCB3aXRoIENPTkZJ
R19BTUQNCj4gPiAtIFJlbW92ZSB1bm5lY2Vzc2FyeSBlbXB0eSBjb21tZW50IGxpbmUNCj4gPiAt
IFVzZSBfX2luaXRjb25zdF9jZl9jbG9iYmVyIGZvciBwcmUtZmlsbGVkIHN0cnVjdHVyZSBjcHVm
cmVxX2RyaXZlcg0KPiA+IC0gTWFrZSBuZXcgc3dpdGNoLWNhc2UgY29kZSBhcHBseSB0byBIeWdv
biBDUFVzIHRvbw0KPiA+IC0gQ2hhbmdlIEVOT1NZUyB3aXRoIEVPUE5PVFNVUFANCj4gPiAtIEJs
YW5rcyBhcm91bmQgYmluYXJ5IG9wZXJhdG9yDQo+ID4gLSBDaGFuZ2UgYWxsIGFtZF8vLXBzdGF0
ZSBkZWZpbmVkIHZhbHVlcyB0byBhbWRfLy1jcHBjDQo+ID4gLS0tDQo+ID4gdjIgLT4gdjMNCj4g
PiAtIHJlZmFjdG9yIHRvbyBsb25nIGxpbmVzDQo+ID4gLSBNYWtlIHN1cmUgWEVOX1BST0NFU1NP
Ul9QTV9QWCBhbmQgWEVOX1BST0NFU1NPUl9QTV9DUFBDDQo+IGluY29tcGF0aWJsZQ0KPiA+IGZs
YWdzIGFmdGVyIGNwdWZyZXEgcmVnaXN0ZXIgcmVnaXN0cmFudGlvbg0KPiA+IC0tLQ0KPiA+IHYz
IC0+IHY0Og0KPiA+IC0gaW50cm9kdWNlIFhFTl9QUk9DRVNTT1JfUE1fQ1BQQyBpbiB4ZW4gaW50
ZXJuYWwgaGVhZGVyDQo+ID4gLSBjb21wbGVtZW50ICJIeWdvbiIgaW4gbG9nIG1lc3NhZ2UNCj4g
PiAtIHJlbW92ZSB1bm5lY2Vzc2FyeSBpZigpDQo+ID4gLSBncm93IGNwdWZyZXFfeGVuX29wdHNb
XSBhcnJheQ0KPiA+IC0tLQ0KPiA+IHY0IC0+IHY1Og0KPiA+IC0gcmVtb3ZlIFhFTl9QUk9DRVNT
T1JfUE1feHh4IGZsYWcgc2FuaXRpemF0aW9uIGZyb20gaW5kaXZpZHVhbCBkcml2ZXINCj4gPiAt
IHByZWZlciAhIG92ZXIgIj09IDAiIGluIHB1cmVseSBib29sZWFuIGNvbnRleHRzDQo+ID4gLSBC
bGFuayBsaW5lIGJldHdlZW4gbm9uLWZhbGwtdGhyb3VnaCBjYXNlIGJsb2Nrcw0KPiA+IC0gYWRk
IGJ1aWxkLXRpbWUgY2hlY2tpbmcgYmV0d2VlbiBpbnRlcm5hbCBhbmQgcHVibGljDQo+ID4gWEVO
X1BST0NFU1NPUl9QTV8qIHZhbHVlcw0KPiA+IC0gZGVmaW5lIFhFTl9QUk9DRVNTT1JfUE1fQ1BQ
QyB3aXRoIDB4MTAwLCBhcyBpdCBpcyB0aGUgbmV4dCB2YWx1ZSB0bw0KPiA+IHVzZSBhZnRlciBw
dWJsaWMgaW50ZXJmYWNlLCBhbmQgcHVibGljIG1hc2sgU0lGX1BNX01BU0sgaXMgOCBiaXRzIHdp
ZGUuDQo+ID4gLSBhcyBEb20wIHdpbGwgc2VuZCB0aGUgQ1BQQy9QeCBkYXRhIHdoZW5ldmVyIGl0
IGNvdWxkLCB0aGUgcmV0dXJuDQo+ID4gdmFsdWUgc2hhbGwgYmUgMCBpbnN0ZWFkIG9mIC1FTk9T
WVMvRU9QTk9UU1VQIHdoZW4gcGxhdGZvcm0gZG9lc24ndCByZXF1aXJlDQo+IHRoZXNlIGRhdGEu
DQo+ID4gLS0tDQo+ID4gIGRvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLnBhbmRvYyAgICAgICAg
IHwgIDcgKystDQo+ID4gIHhlbi9hcmNoL3g4Ni9hY3BpL2NwdWZyZXEvTWFrZWZpbGUgICAgICAg
IHwgIDEgKw0KPiA+ICB4ZW4vYXJjaC94ODYvYWNwaS9jcHVmcmVxL2FtZC1jcHBjLmMgICAgICB8
IDY4ICsrKysrKysrKysrKysrKysrKysrKysrDQo+ID4gIHhlbi9hcmNoL3g4Ni9hY3BpL2NwdWZy
ZXEvY3B1ZnJlcS5jICAgICAgIHwgNjMgKysrKysrKysrKysrKysrKysrKystDQo+ID4gIHhlbi9h
cmNoL3g4Ni9wbGF0Zm9ybV9oeXBlcmNhbGwuYyAgICAgICAgIHwgMTMgKysrKy0NCj4gPiAgeGVu
L2RyaXZlcnMvYWNwaS9wbXN0YXQuYyAgICAgICAgICAgICAgICAgfCAgMyArLQ0KPiA+ICB4ZW4v
ZHJpdmVycy9jcHVmcmVxL2NwdWZyZXEuYyAgICAgICAgICAgICB8IDE4ICsrKysrLQ0KPiA+ICB4
ZW4vaW5jbHVkZS9hY3BpL2NwdWZyZXEvY3B1ZnJlcS5oICAgICAgICB8ICA2ICstDQo+ID4gIHhl
bi9pbmNsdWRlL2FjcGkvY3B1ZnJlcS9wcm9jZXNzb3JfcGVyZi5oIHwgIDMgKw0KPiA+ICB4ZW4v
aW5jbHVkZS9wdWJsaWMvc3lzY3RsLmggICAgICAgICAgICAgICB8ICAxICsNCj4gPiAgMTAgZmls
ZXMgY2hhbmdlZCwgMTc1IGluc2VydGlvbnMoKyksIDggZGVsZXRpb25zKC0pICBjcmVhdGUgbW9k
ZQ0KPiA+IDEwMDY0NCB4ZW4vYXJjaC94ODYvYWNwaS9jcHVmcmVxL2FtZC1jcHBjLmMNCj4NCj4g
PiBAQCAtMTU3LDcgKzE2Miw2MyBAQCBzdGF0aWMgaW50IF9faW5pdCBjZl9jaGVjaw0KPiA+IGNw
dWZyZXFfZHJpdmVyX2luaXQodm9pZCkNCj4gPg0KPiA+ICAgICAgICAgIGNhc2UgWDg2X1ZFTkRP
Ul9BTUQ6DQo+ID4gICAgICAgICAgY2FzZSBYODZfVkVORE9SX0hZR09OOg0KPiA+IC0gICAgICAg
ICAgICByZXQgPSBJU19FTkFCTEVEKENPTkZJR19BTUQpID8gcG93ZXJub3dfcmVnaXN0ZXJfZHJp
dmVyKCkgOiAtDQo+IEVOT0RFVjsNCj4gPiArICAgICAgICAgICAgdW5zaWduZWQgaW50IGk7DQo+
ID4gKw0KPiA+ICsgICAgICAgICAgICBpZiAoICFJU19FTkFCTEVEKENPTkZJR19BTUQpICkNCj4g
PiArICAgICAgICAgICAgew0KPiA+ICsgICAgICAgICAgICAgICAgcmV0ID0gLUVOT0RFVjsNCj4g
PiArICAgICAgICAgICAgICAgIGJyZWFrOw0KPiA+ICsgICAgICAgICAgICB9DQo+ID4gKyAgICAg
ICAgICAgIHJldCA9IC1FTk9FTlQ7DQo+ID4gKw0KPiA+ICsgICAgICAgICAgICBmb3IgKCBpID0g
MDsgaSA8IGNwdWZyZXFfeGVuX2NudDsgaSsrICkNCj4gPiArICAgICAgICAgICAgew0KPiA+ICsg
ICAgICAgICAgICAgICAgc3dpdGNoICggY3B1ZnJlcV94ZW5fb3B0c1tpXSApDQo+ID4gKyAgICAg
ICAgICAgICAgICB7DQo+ID4gKyAgICAgICAgICAgICAgICBjYXNlIENQVUZSRVFfeGVuOg0KPiA+
ICsgICAgICAgICAgICAgICAgICAgIHJldCA9IHBvd2Vybm93X3JlZ2lzdGVyX2RyaXZlcigpOw0K
PiA+ICsgICAgICAgICAgICAgICAgICAgIGJyZWFrOw0KPiA+ICsNCj4gPiArICAgICAgICAgICAg
ICAgIGNhc2UgQ1BVRlJFUV9hbWRfY3BwYzoNCj4gPiArICAgICAgICAgICAgICAgICAgICByZXQg
PSBhbWRfY3BwY19yZWdpc3Rlcl9kcml2ZXIoKTsNCj4gPiArICAgICAgICAgICAgICAgICAgICBi
cmVhazsNCj4gPiArDQo+ID4gKyAgICAgICAgICAgICAgICBjYXNlIENQVUZSRVFfbm9uZToNCj4g
PiArICAgICAgICAgICAgICAgICAgICByZXQgPSAwOw0KPiA+ICsgICAgICAgICAgICAgICAgICAg
IGJyZWFrOw0KPiA+ICsNCj4gPiArICAgICAgICAgICAgICAgIGRlZmF1bHQ6DQo+ID4gKyAgICAg
ICAgICAgICAgICAgICAgcHJpbnRrKFhFTkxPR19XQVJOSU5HDQo+ID4gKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICJVbnN1cHBvcnRlZCBjcHVmcmVxIGRyaXZlciBmb3IgdmVuZG9yIEFNRCBv
ciBIeWdvblxuIik7DQo+ID4gKyAgICAgICAgICAgICAgICAgICAgYnJlYWs7DQo+ID4gKyAgICAg
ICAgICAgICAgICB9DQo+ID4gKw0KPiA+ICsgICAgICAgICAgICAgICAgaWYgKCByZXQgIT0gLUVO
T0RFViApDQo+ID4gKyAgICAgICAgICAgICAgICAgICAgYnJlYWs7DQo+DQo+IFRoaXMsIEkgdGhp
bmssIG5lZWRzIHNvbWUgY29tbWVudGluZy4gSXQncyBub3QgcXVpdGUgY2xlYXIgd2h5IHdlIHNo
b3VsZG4ndCB0cnkgdGhlDQo+IG5leHQgb3B0aW9uIGlmIHJlZ2lzdHJhdGlvbiBmYWlsZWQgd2l0
aCBvdGhlciB0aGFuIC1FTk9ERVYuDQo+DQoNCkkgZm9sbG93ZWQgdGhlIG9yaWdpbmFsIGxvZ2lj
Lg0KTm93LCBJJ20gdHJ5aW5nIHRvIHVuZGVyc3RhbmQgdGhlIHJlYXNvbi4gSSByZWFkIHRoZSBy
ZWxhdGVkIGNvZGUsIHRoZXJlIGFyZSB0d28gY29kZSBwYXRoIGVycm9yaW5nIG91dCBvdGhlciB0
aGFuIC1FTk9ERVYNCkluIGNwdWZyZXFfcmVnaXN0ZXJfZHJpdmVyKCksIGVpdGhlciB0aGUgZHJp
dmVyIGl0c2VsZiBpcyBicm9rZW4sIGxpa2UgbWlzc2luZyBtYW5kYXRvcnkgaG9va3MsIGV0Yywg
eWV0IGluIHdoaWNoIGNhc2UsIElNTyB3ZSBzaGFsbCB0cnkgdGhlIGZhbGxiYWNrIG9wdGlvbiwN
Cm9yIHJlcGVhdGVkIHJlZ2lzdHJhdGlvbiwgVEJILCB3aGljaCBzZWVtcyB1bmxpa2VseSB0byBt
ZS4gY3B1ZnJlcV9kcml2ZXJfaW5pdCgpIGlzIGEgcHJlc21wIGNhbGwsIHNvIHJlcGVhdGVkIHJl
Z2lzdHJhdGlvbiBkb2Vzbid0IGNvbWUgZnJvbSByYWNpbmcuDQpUaGVuIGlmIHdlIHN1Y2Nlc3Nm
dWxseSByZWdpc3RlcmVkIGEgZHJpdmVyLCB3ZSB3aWxsIGltbWVkaWF0ZWx5IGV4aXQgdGhlIGxv
b3AuIEhvdyBjb21lIHdlIHdpbGwgcmVnaXN0ZXIgdHdpY2U/DQpPciBhbSBJIG1pc3Npbmcgc29t
ZXRoaW5nIGZvciB0aGlzIGVycm9yIHBhdGg6DQpgYGANCiAgICAgICAgaWYgKCBjcHVmcmVxX2Ry
aXZlci5pbml0ICkNCiAgICAgICAgICAgICAgICByZXR1cm4gLUVCVVNZOw0KYGBgDQoNCj4NCj4g
PiArICAgICAgICAgICAgICAgICAgICBicmVhazsNCj4gPiArICAgICAgICAgICAgICAgIH0NCj4g
PiArICAgICAgICAgICAgfQ0KPg0KPiBXaHkgZG9lcyB0aGlzIHBydW5pbmcgb2YgeGVuX3Byb2Nl
c3Nvcl9wbWJpdHMgc2l0IGluIHRoZSBBTUQtb25seSBjb2RlIHBhdGg/DQo+IElpcmMgZWFybGll
ciBvbiB5b3UgaGFkIGl0IGluIHRoZSAqX3JlZ2lzdGVyX2RyaXZlcigpIHRoZW1zZWx2ZXMsIGFu
ZCBteSByZXF1ZXN0IHdhcw0KPiB0byBwdXQgaXQgaW4gYSBjZW50cmFsLCBnZW5lcmljIHBsYWNl
LiBJdCdzIGNlbnRyYWwgbm93LCBidXQgbm90IGdlbmVyaWMgKGFuZCB0aGlzIHdheSBpdA0KPiBj
b3VsZCBhcyB3ZWxsIGhhdmUgcmVtYWluZWQgaW4gKl9yZWdpc3Rlcl9kcml2ZXIoKSkuDQo+DQoN
ClRydWUsIGJlZm9yZSwgSSB3YXMgd3JvbmdseSBhc3N1bWVkIHRoYXQgWEVOX1BST0NFU1NPUl9Q
TV9DUFBDIGNvdWxkIG9ubHkgYmUgaW5pdGlhbGl6ZWQgaW4gQU1ELg0KV2UgY291bGQgYWxzbyBw
cm92aWRlICJjcHVmcmVxPWFtZC1jcHBjIiBpbiBJTlRFTCBwbGF0Zm9ybSwgeWV0IHVuZGVyIHdo
aWNoIHNjZW5hcmlvLCB3ZSBzaGFsbCBzZXQgcmV0IHdpdGggLUVOT0RFViBlcnJubyAocmlnaHQg
bm93IGlzIC1FTk9FTlQsIG5lZWQgdG8gZml4KSB0byBrZWVwIGxvb3BpbmcgYW5kIHRyeSB0aGUg
bmV4dCBvcHRpb24uLi4NCknigJlsbCBtb3ZlIGl0IG91dCBvZiB0aGUgQU1ELW9ubHkgcGF0Y2gs
IGFuZCBwdXQgaXQgYWZ0ZXIgdGhlIHdob2xlIHN3aXRjaC1jYXNlDQoNCj4NCj4gSmFuDQo=


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 07:16:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 07:16:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017790.1394782 (Exim 4.92)
	(envelope-from )
	id 1uRQYG-000667-KA; Tue, 17 Jun 2025 07:16:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017790.1394782; Tue, 17 Jun 2025 07: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 1uRQYG-000660-HO; Tue, 17 Jun 2025 07:16:12 +0000
Received: by outflank-mailman (input) for mailman id 1017790;
 Tue, 17 Jun 2025 07:16: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 1uRQYE-000642-V5
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 07:16:10 +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 f0e41b79-4b4a-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 09:16:09 +0200 (CEST)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-adb2bb25105so916358766b.0
 for ; Tue, 17 Jun 2025 00:16:09 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-adec81562ecsm802501966b.27.2025.06.17.00.16.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Jun 2025 00:16:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f0e41b79-4b4a-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750144569; x=1750749369; 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=3Ah1lcLne+pI4unO6xxJUtv9kU/DwTiXbQt10O1vsR8=;
        b=UMoR7m6LCOZvR2dpR020J/FxoX6Oq6Mk02MlOy+jM0BerOlDjCdSLSdjig5D2W0c1R
         mwhQtMJji0fITdDEV3cy0TB5fxOaW4CqDe21ppkO7NKt2EdUTLv7Y6fArgSUzIWfHJMm
         Jkm9MaBsdcIGzJ1k4K0C1cvubTKdRKQ/GtdnOV7ufFkJU1coUtpLaOpnm796jBIAjuvI
         AKvXplpr+kKhfZpFqD46A5O6SOAUl2ZkjYz6zeNNIygUz5LS4K0NATUCvhhj9izyJNWi
         0RTlIv9CdIo1EhISNBB33nTdNkWdWDWdq9Qm5NMWv+GBLCWLUfkjyEXGMRCanNhHFqV8
         HJUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750144569; x=1750749369;
        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=3Ah1lcLne+pI4unO6xxJUtv9kU/DwTiXbQt10O1vsR8=;
        b=UkZ/Db+CPdgpDIu7giz6zOgNv++5OGr9STPthPAmEADjGPU0wjgKKdd6//jYc91mBj
         ex/qJpofPbp/Zt9arwB9R1jwoXxTAbqmVUoJC2odQTumdPLrL9G4MZmnmwgNerjPY68E
         9+zdQ+OJKKut9dp6c08ogWBUCUmMaJBUqjJFiEW2c3inValP1oNO+ON2KxsnBkuv/YR4
         SZkv9Rw8j58IA+thOJK0+cdrrjcBt2CqUGqHsdliRvsaXQAz26DYoqwShNZcS0jK0W8+
         rt/zOOo1rH0C0CwAaL1eIKrNk/im5/1+DnfxI7aRRYxLZuRsYEtepQH7WEhUGv69zDFR
         ThTA==
X-Forwarded-Encrypted: i=1; AJvYcCUIOaYL1hWyGiSAuT5qx1wL8IVG9AHkJdlTrp+d2PmFCZ9rJKC3GYnHan2MYq7jedTVRAVICTf/7p0=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz21ANUGMBdIWcWsPDuxFa+t39vkhdTXkN/7wllfgaLzVCanhPV
	uEK1CWoFbphF3zDcKeck+UzhMneKPznBUYB5H2hWauW71imaAVnQEFAK
X-Gm-Gg: ASbGncttn0/C0m1FwJCPlJU0578B9PnAd0oafhVUVkPk6CieFKFS+f7szqF688a02xE
	Q3Ts4cKsMA5CqXIMvlyYoCJBQX+VM3ezngKghLzqtd44Jn8kFetH3Xbl0J+5Itnafyf4k9rs61F
	8xjUVNNr6ADmk9yLL7e3E++H8ZdxlGkdNVRwFLAZFJ1lxpjDn62AjC3QxcFZsIls90D+dA93lwX
	+t4CvzYJyxBbPuCPdiWk0GsXeqiDVUt13Dtn0M9ic/VieMI4xBrPeMN+VIyJwJZen65qmeSrHT1
	diGTbEoAscsyg6OHuTUl+Vczby5tugWag7c6gSqkln+if+ASXMBWm75UJGvyOJ344p6PpyA7Tul
	0UeMRP17AOJEwWjuMAwJY6E3vmH//DjAU9LM=
X-Google-Smtp-Source: AGHT+IHFyACyZ1pUqFlH3ZjviZ32gP4rW4cGrPFjDvZsNtgze0BSWUDSKyhgOD3lF5gIem48RgddNw==
X-Received: by 2002:a17:907:c0d:b0:ad8:8efe:31fb with SMTP id a640c23a62f3a-adfad4f5918mr1281139866b.54.1750144568429;
        Tue, 17 Jun 2025 00:16:08 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------SzwOD00Xg0gbG5SJ0mOofsZV"
Message-ID: <5648bdc5-20e0-4d2d-a6df-93b4088c106c@gmail.com>
Date: Tue, 17 Jun 2025 09:16:06 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/arm: Fix P2M root page tables invalidation
To: Julien Grall , Michal Orzel ,
 xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250616065648.17517-1-michal.orzel@amd.com>
 <6cd8c65a-c440-45e3-9bb1-e8c28e90ae56@xen.org>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <6cd8c65a-c440-45e3-9bb1-e8c28e90ae56@xen.org>

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


On 6/16/25 10:15 AM, Julien Grall wrote:
> (+Oleksii)
>
> Hi,
>
> Adding Oleksii for visibility.

Thanks for adding me.

>
> On 16/06/2025 07:56, Michal Orzel wrote:
>> Fix the condition part of the for loop in p2m_invalidate_root() that
>> uses P2M_ROOT_LEVEL instead of P2M_ROOT_PAGES. The goal here is to

I used P2M_ROOT_PAGES for RISC-V for the similar case. This patch just confirms
that it was a correct decision.

Thanks.

~ Oleksii

>> invalidate all root page tables (that can be concatenated), so the loop
>> must iterate through all these pages. Root level can be 0 or 1, whereas
>> there can be 1,2,8,16 root pages. The issue may lead to some pages
>> not being invalidated and therefore the guest access won't be trapped.
>> We use it to track pages accessed by guest for set/way emulation 
>> provided
>> no IOMMU, IOMMU not enabled for the domain or P2M not shared with IOMMU.
>>
>> Fixes: 2148a125b73b ("xen/arm: Track page accessed between batch of 
>> Set/Way operations")
>> Signed-off-by: Michal Orzel 
>
> Reviewed-by: Julien Grall 
>
> Cheers,
>
--------------SzwOD00Xg0gbG5SJ0mOofsZV
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    

    
    
    
    
    On 6/16/25 10:15 AM, Julien Grall
      wrote:
    
    
    
    
    (+Oleksii)
      
    
      
    
      Hi,
      
    
      
    
      Adding Oleksii for visibility.
      
    
    
    
    
    Thanks for adding me.


    
    
    
      
    
      On 16/06/2025 07:56, Michal Orzel wrote:
      
    
      
    Fix the condition part of the for loop in
        p2m_invalidate_root() that
        
    
        uses P2M_ROOT_LEVEL instead of P2M_ROOT_PAGES. The goal here is
        to
        
    
      
    
    
    
    
    I used P2M_ROOT_PAGES for RISC-V for the similar case. This patch just confirms
that it was a correct decision.

Thanks.

~ Oleksii


    
    
    
      
    invalidate all root page tables (that can
        be concatenated), so the loop
        
    
        must iterate through all these pages. Root level can be 0 or 1,
        whereas
        
    
        there can be 1,2,8,16 root pages. The issue may lead to some
        pages
        
    
        not being invalidated and therefore the guest access won't be
        trapped.
        
    
        We use it to track pages accessed by guest for set/way emulation
        provided
        
    
        no IOMMU, IOMMU not enabled for the domain or P2M not shared
        with IOMMU.
        
    
        
    
        Fixes: 2148a125b73b ("xen/arm: Track page accessed between batch
        of Set/Way operations")
        
    
        Signed-off-by: Michal Orzel <michal.orzel@amd.com>
        
    
      
    
      
    
      Reviewed-by: Julien Grall <jgrall@amazon.com>
      
    
      
    
      Cheers,
      
    
      
    
    
    
  


--------------SzwOD00Xg0gbG5SJ0mOofsZV--


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 07:18:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 07:18:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017797.1394793 (Exim 4.92)
	(envelope-from )
	id 1uRQak-0006ew-VL; Tue, 17 Jun 2025 07:18:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017797.1394793; Tue, 17 Jun 2025 07:18:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRQak-0006ep-Rc; Tue, 17 Jun 2025 07:18:46 +0000
Received: by outflank-mailman (input) for mailman id 1017797;
 Tue, 17 Jun 2025 07:18: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 1uRQaj-0006eh-5P
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 07:18:45 +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 4addbeeb-4b4b-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 09:18:40 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-450ccda1a6eso47574895e9.2
 for ; Tue, 17 Jun 2025 00:18:40 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-4532e256630sm170414585e9.29.2025.06.17.00.18.38
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 17 Jun 2025 00:18:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4addbeeb-4b4b-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750144719; x=1750749519; 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=+iQbnVi6qoNwPsH0EtCP5cn6bop7bqaemlZH8HM2uEw=;
        b=nbxM+QUdQYofUznprZ9r+XpUoUUCikPVmhZy9E1XADB3M0URPFgD0BG+aoJo6A0fl2
         e5GooAhZ5a4qQ0dw6ATD9F0S0b1ysW+IW5u9alFR0Fb7RbMxzTEHdAxE6YMvY79nZcbn
         yHH1UeJRcfaCcs5Eo3yt1W2ME9k2f9FtptNx8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750144719; x=1750749519;
        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=+iQbnVi6qoNwPsH0EtCP5cn6bop7bqaemlZH8HM2uEw=;
        b=JFjl7HsI7nhuZJ/EqM4YTQDa67J3IrqMhUBeUfPBf5DcfK2P+YaI+QUxpwtge3eNNv
         8TGl20pK5URnxeSeEFfvce4ajkI113XmaV5O4bafr62yC+ctXl+m2OrY6aTonNZzpagO
         WHMVZv71+YZNUIwuUAlVNAbeSNsV0D0JNLDJ16LObLCQ50M4PX2A9G/RAoHVYJA34IKj
         Zy4+lzLo+6xBc+dJCT1GU9doWlri15F9105T9SOtb+qiIg6xSj6xCBpHTHwkkHzqvIIr
         uikMm7yGSCN0/YSwybGMiT+ea2qujKx+DfkqYPxQRqzBwYNd+lYl28+aaUBD//r9W3Jb
         KXPg==
X-Forwarded-Encrypted: i=1; AJvYcCWW+EXptLB1/jw8Gig5+C3iCiWtFecOEGWUIEOqzd/pDyCm33HXoSQJz/J1Ml2QswoBhfABJogaSnk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwH8pp0gkkI5FPxHCHu6rcdPRATu/TI86g6kyVgLMY8VF8AI7z0
	oZTCKZrVREJeHfZbqeTxhyj4QDDitOwcXeDHdItG+LWMeTz+NSQYvSxRqCqbd1Ef+RE=
X-Gm-Gg: ASbGncvqR2rp3b/uIt5ROTCKF/V4Gb0F5tmph4MpRt6lFI0joyWtP2B+wkEEaGABS7k
	qPPlQxyIzo9SX7Wdh2ZhDJ/3iKDCcamz8al8b/nHQB1O/n2lFl+8nzDXA1dPXLEu2k8G5I+2ky6
	nSrTHdEqBqRpiCqLZqy8jxNUbDTnRF/5f4MX/jsAmoXEkhPVRhhiyfX/cXQy8YG4xdSv/RWIV5a
	GPLcG8/L2tOL1ro6e8zXlKbXMXkMPKF5N3pSeTHXpOip7shqCpbECTFlF90MxoyDuENSejS64gU
	KszRP57WwvYpFdfSG1uuJGb5qX1ndhsdThcx81QHoLLr56XJihRpj5EDLp8+U5WyidkPrHtSaMX
	lshl7w/JiI8xge2tT81MOlO0zGgz+lJOwhoYC8IyF
X-Google-Smtp-Source: AGHT+IE4C2uJmQXMPvZdb8Xrem8XtAHjIBoaRB4On7ei1ddLTt5F2DEdkizjKItH/5J2E5RS3lJSBg==
X-Received: by 2002:a05:600c:6211:b0:43c:f8fe:dd82 with SMTP id 5b1f17b1804b1-4533cab86f3mr111739135e9.18.1750144719476;
        Tue, 17 Jun 2025 00:18:39 -0700 (PDT)
Date: Tue, 17 Jun 2025 09:18:38 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Nicola Vetrini 
Cc: Jan Beulich , dmkhn@proton.me,
	andrew.cooper3@citrix.com, anthony.perard@vates.tech,
	julien@xen.org, michal.orzel@amd.com, sstabellini@kernel.org,
	teddy.astie@vates.tech, dmukhin@ford.com,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v8] xen/domain: rewrite emulation_flags_ok()
Message-ID: 
References: <20250617011519.55386-1-dmukhin@ford.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 

On Tue, Jun 17, 2025 at 08:53:51AM +0200, Nicola Vetrini wrote:
> On 2025-06-17 08:19, Jan Beulich wrote:
> > On 17.06.2025 03:15, dmkhn@proton.me wrote:
> > > --- a/xen/arch/x86/domain.c
> > > +++ b/xen/arch/x86/domain.c
> > > @@ -743,32 +743,75 @@ int arch_sanitise_domain_config(struct
> > > xen_domctl_createdomain *config)
> > >      return 0;
> > >  }
> > > 
> > > +/*
> > > + * Verify that the domain's emulation flags resolve to a supported
> > > configuration.
> > > + *
> > > + * This ensures we only allow a known, safe subset of emulation
> > > combinations
> > > + * (for both functionality and security). Arbitrary mixes are
> > > likely to cause
> > > + * errors (e.g. null pointer dereferences).
> > > + *
> > > + * NB: use the internal X86_EMU_XXX symbols, not the public
> > > XEN_X86_EMU_XXX
> > > + * symbols, to take build-time config options (e.g. CONFIG_HVM)
> > > into account
> > > + * for short-circuited emulations.
> > > + */
> > >  static bool emulation_flags_ok(const struct domain *d, uint32_t
> > > emflags)
> > >  {
> > > +    enum domain_capability {
> > > +        CAP_PV          = BIT(0, U),
> > > +        CAP_HVM         = BIT(1, U),
> > > +        CAP_HWDOM       = BIT(2, U),
> > > +        CAP_DOMU        = BIT(3, U),
> > > +    };
> > > +    static const struct {
> > > +        enum domain_capability caps;
> > > +        uint32_t min;
> > > +        uint32_t opt;
> > > +    } configs[] = {
> > > +#ifdef CONFIG_PV
> > > +        /* PV dom0 and domU */
> > > +        {
> > > +            .caps   = CAP_PV | CAP_HWDOM | CAP_DOMU,
> > 
> > Just to double check - are we sure Misra / Eclair will like this (ab)use
> > of an enum?
> > 
> > Jan
> 
> Likely not, but x86_64 is build with CONFIG_PV=n

It's doing the same for HVM also, so it would trigger for the instance
below then.  I will ack v7 then, which used an unsigned int instead.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 07:19:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 07:19:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017807.1394803 (Exim 4.92)
	(envelope-from )
	id 1uRQbr-0007FE-C3; Tue, 17 Jun 2025 07:19:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017807.1394803; Tue, 17 Jun 2025 07:19:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRQbr-0007F7-7t; Tue, 17 Jun 2025 07:19:55 +0000
Received: by outflank-mailman (input) for mailman id 1017807;
 Tue, 17 Jun 2025 07:19: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 1uRQbq-0007Ez-56
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 07:19:54 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20607.outbound.protection.outlook.com
 [2a01:111:f403:2416::607])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 75565d9f-4b4b-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 09:19:52 +0200 (CEST)
Received: from PH7P222CA0018.NAMP222.PROD.OUTLOOK.COM (2603:10b6:510:33a::12)
 by MN0PR12MB5785.namprd12.prod.outlook.com (2603:10b6:208:374::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.19; Tue, 17 Jun
 2025 07:19:46 +0000
Received: from SN1PEPF0002BA4F.namprd03.prod.outlook.com
 (2603:10b6:510:33a:cafe::15) by PH7P222CA0018.outlook.office365.com
 (2603:10b6:510:33a::12) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.21 via Frontend Transport; Tue,
 17 Jun 2025 07:19:45 +0000
Received: from SATLEXMB03.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.8835.15 via Frontend Transport; Tue, 17 Jun 2025 07:19: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; Tue, 17 Jun
 2025 02:19:45 -0500
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; Tue, 17 Jun
 2025 02:19:44 -0500
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, 17 Jun 2025 02:19:43 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 75565d9f-4b4b-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=CmRtaVZWqTppZYoHtwJlDKOlq4dBxMlb7JWuohon6/XIx/GmYBSAhlkr3S4KJ3NGTCo5d75Ct4MzWLenz3SilaPd7F7va4Qx0/byWoVgYb9HE23LZQ4/bg4aOVfMEqZs+1d1R+uE/WzceilUcPKiBAYoEedgQn6U0aV2Q98hVE6Cs0E7u+NyDiaVoaea/J6atfTDyDS2bWDYGMzZQNuBA/7Shcg482H20ESliX5VQ9XXDdzlTPh/zBEYOiKBl6EtyYFWGCUKk6Wo8wbA4No9tl7hXNr8kP6IKZs44DHmfzJ18kwS/gMIeisO64mXsOaH7zH2Fr7NByS7aCI9JfOXsQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=lbDd2DpkJV2lGbpCrWTmXsmmQtaUABV0UM6Kmtyx9Io=;
 b=RV9BUt2KexIOIvvwxRvNzkrEWI/OgZyn/b4S3MOWpevQjufpjXXIbLHhy05J4mmkzlKp6tTwQOMe6lhElP9HJjjd4FXWDpbUM69jLONoYyl9nju9YA5gqyt0K3Bh0fpqtjCYSDEhOijieayQDe3dlFR1+fjB/pbDBQlrXn+J92XkMBM0HpS3n4pN9D4cHeXQxP7+We7TknUJppyIOK4e8bcivXg7nCv9Mabc800cVYgfmpq7YM47CEiPKDLejS3fxW98XCMWCRe7UzbSP0aKybYBK9vyjj2eV4/w2TnYFiLa1O+vi7K+1fRdzzax2aMt1MXEshIP5XHUQ/yy7xvOKA==
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=lbDd2DpkJV2lGbpCrWTmXsmmQtaUABV0UM6Kmtyx9Io=;
 b=DvAK7laRvhAijY9hTLHCfJn2mLrGr0HKNon1ySGpZj7fQMTPUWPgKjEOEd6plskMMTyL5nItKcW9cUzXpPs2cs8/EYAwfYgg3zL2uKovhMDcurAWriF63EgLqOIhmi1r0oHPxVGUKsJ6UWLath/FhL8O8W4xN2A0MYTCVryam2o=
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 , Andrew Cooper
	, Anthony PERARD , "Jan
 Beulich" , Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Stefano
 Stabellini" 
Subject: [PATCH] console: Do not duplicate early printk messages on conring flush
Date: Tue, 17 Jun 2025 09:19:40 +0200
Message-ID: <20250617071940.10445-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 (SATLEXMB05.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF0002BA4F:EE_|MN0PR12MB5785:EE_
X-MS-Office365-Filtering-Correlation-Id: edd65454-a15f-4dec-ad8c-08ddad6f5635
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?EHHnrVVKGRleVKOKePSghi3VvJHHqCYbF+0efYSgwbH4t8omgE3B6DGDBV49?=
 =?us-ascii?Q?VSBwmAJVo7zak5a+BOuZs7iZzl4EtZ+Iz3zwIaYNUUS56dWtMFUoq7fNgcF0?=
 =?us-ascii?Q?S7HUK2NeApC+JS4+m0eD0o/SdrYUU/0kCumpitxA1ymrVN6muADaE5rjdXoy?=
 =?us-ascii?Q?YkU44r6yvdaz1vMcP/px4Uw+LzNrp9B8x0EB93Kj65HQQObdq8jUtQIX6lI4?=
 =?us-ascii?Q?6ao44XIC8VRIgV0CQ5jqYg1/Bek+iIWMgU7qb91IjmAfuAgEzL2WcgHN3yA3?=
 =?us-ascii?Q?VqzEVn60wDPAEydSGIkfp1bPZXDQi9lxWmLNottmrd0ChzET2TvnPd58QCMK?=
 =?us-ascii?Q?VNBcPOmekKUV4Xx+DaBDD6LCTjTiFeKzxIYLK3UxUh5x78apG3oy+VWBL3j5?=
 =?us-ascii?Q?LV2aUf7evYgOVuWDKZTXI1gJIl1nlb2nupELwhDPVivYKfgsilXlauGsT3Bj?=
 =?us-ascii?Q?mmhjUvI9TDiOdYGUyeVNxVhgqZvj8N4/sr8vpJfu5M5KcWZSeQWoNM4Huswa?=
 =?us-ascii?Q?HvFFYfyawoIA9y6RMrjoyzULL5XVXuVVX8LY0ejWLfwr8CHSDYNlu+NwAKFh?=
 =?us-ascii?Q?83Kl+RmkmbCg8ifDQURA23GgemaYLHpY/vzGeYli9gLtq1ZgHiXI/tXKpFJY?=
 =?us-ascii?Q?vEekVw/8rE9D3LaBEAhBthnnkOkRlwBEiRf2+RBjdrhPC92Ff4RyCpDdtcI4?=
 =?us-ascii?Q?TtGz6pknnUHV2y0M/KzRov5+5jMQq25sI6N9AHvj+DFbeF3UgXwohGx2Q1JT?=
 =?us-ascii?Q?yeRldyJNqmxjiGbusptMJAYo8yzk/DRtxtzshy30zK1jeQYC95RBEiBqn2tA?=
 =?us-ascii?Q?CKmYvipq0tVubtMnPmNS1mu4XaJ6fghffJeyAFR3atsgMQQzNpQHGhrz/yDQ?=
 =?us-ascii?Q?FrFTy0JyGhgTzpqy7BdzF2QaPkorpcHjdsvwQZ+5dYYT8lvIh/LZLHuTYwt0?=
 =?us-ascii?Q?+2IGFmNxJ3Q2Zxk2Bu2/lGDnDVNfSJxkzzFXkIXW3t9uXVMuNxtV7aifXSb8?=
 =?us-ascii?Q?UKeh5R5ab9pgngpgPhKsR2LzxSv8ZLdMhqyGzpZNqW6NT2Dn05bmki/YRmqZ?=
 =?us-ascii?Q?PHaEkR034fEOHVLzC9EQ2oFiToXV1SSBE5Mncf3Xp6O0Kn3sf4rfoBCw68G0?=
 =?us-ascii?Q?T5rfn5gQRdBfzdJ5+8Hsy2vRS05zrkE32FPQMhukVAcQq5Gkjh0yXfrTGe/x?=
 =?us-ascii?Q?EFgtOq+VeyiIX35DPsqoNoQXOns0RzIbchgzIBEOOx1Wp0wOVlt0526nq07e?=
 =?us-ascii?Q?oOfMknRVlbArdq/N3VC7B4tus7hrnrFlf9ikC/04C+JCj7OVJsJxKeAl3tf2?=
 =?us-ascii?Q?Z2UALHV8UyHFv20NW4HqKkwqtm/MaZTy1hXCN07CCdFQzd9f7sRUYsnGDscT?=
 =?us-ascii?Q?QEZIYopPfCBJTWydWe1qmDbu9g+e+p07comw3Vtu0SfTTe1oCSulihLff+Fd?=
 =?us-ascii?Q?0LBZRUKUISZcyfReN8Anb5GACv5VFXwLVpPgPWCrRJ2aTEuDAtYo1NbSeBQO?=
 =?us-ascii?Q?/gj0JZxeeBGpvedvu189LPkYQ6sFskqpqKPb?=
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);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jun 2025 07:19:45.5083
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: edd65454-a15f-4dec-ad8c-08ddad6f5635
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:
	SN1PEPF0002BA4F.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB5785

Commit f6d1bfa16052 introduced flushing conring in console_init_preirq().
However, when CONFIG_EARLY_PRINTK is enabled, the early boot messages
had already been sent to serial before main console initialization. This
results in all the early boot messages being duplicated.

Change conring_flush() to accept argument listing devices to which to
flush conring. We don't want to send to serial at console initialization
when using early printk, but we want these messages to be send at conring
dump triggered by keyhandler.

Fixes: f6d1bfa16052 ("xen/console: introduce conring_flush()")
Signed-off-by: Michal Orzel 
---
 xen/drivers/char/console.c | 20 ++++++++++++++------
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 9a9836ba91e7..5879e31786ba 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -453,9 +453,9 @@ void console_serial_puts(const char *s, size_t nr)
 }
 
 /*
- * Flush contents of the conring to the physical console devices.
+ * Flush contents of the conring to the selected console devices.
  */
-static int conring_flush(void)
+static int conring_flush(unsigned int flags)
 {
     uint32_t idx, len, sofar, c;
     unsigned int order;
@@ -479,7 +479,7 @@ static int conring_flush(void)
         c += len;
     }
 
-    console_send(buf, sofar, CONSOLE_SERIAL | CONSOLE_VIDEO | CONSOLE_PV);
+    console_send(buf, sofar, flags);
 
     free_xenheap_pages(buf, order);
 
@@ -491,7 +491,7 @@ static void cf_check conring_dump_keyhandler(unsigned char key)
     int rc;
 
     printk("'%c' pressed -> dumping console ring buffer (dmesg)\n", key);
-    rc = conring_flush();
+    rc = conring_flush(CONSOLE_SERIAL | CONSOLE_VIDEO | CONSOLE_PV);
     if ( rc )
         printk("failed to dump console ring buffer: %d\n", rc);
 }
@@ -1042,6 +1042,7 @@ void __init console_init_preirq(void)
 {
     char *p;
     int sh;
+    unsigned int flags = CONSOLE_SERIAL | CONSOLE_VIDEO | CONSOLE_PV;
 
     serial_init_preirq();
 
@@ -1084,8 +1085,15 @@ void __init console_init_preirq(void)
     serial_set_rx_handler(sercon_handle, serial_rx);
     pv_console_set_rx_handler(serial_rx);
 
-    /* NB: send conring contents to all enabled physical consoles, if any */
-    conring_flush();
+    /*
+     * NB: send conring contents to all enabled physical consoles, if any.
+     * Skip serial if CONFIG_EARLY_PRINTK is enabled, which means the early
+     * messages have already been sent to serial.
+     */
+    if ( IS_ENABLED(CONFIG_EARLY_PRINTK) )
+        flags &= ~CONSOLE_SERIAL;
+
+    conring_flush(flags);
 
     /* HELLO WORLD --- start-of-day banner text. */
     nrspin_lock(&console_lock);
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Tue Jun 17 07:20:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 07:20:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017814.1394813 (Exim 4.92)
	(envelope-from )
	id 1uRQcF-0000D2-Jr; Tue, 17 Jun 2025 07:20:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017814.1394813; Tue, 17 Jun 2025 07:20:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRQcF-0000Cv-GR; Tue, 17 Jun 2025 07:20:19 +0000
Received: by outflank-mailman (input) for mailman id 1017814;
 Tue, 17 Jun 2025 07:20: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 1uRQcE-0007U6-Kw
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 07:20:18 +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 849fb7d6-4b4b-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 09:20:17 +0200 (CEST)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3a4f379662cso4641510f8f.0
 for ; Tue, 17 Jun 2025 00:20:16 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-4532e16b425sm164099065e9.34.2025.06.17.00.20.15
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 17 Jun 2025 00:20:15 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 849fb7d6-4b4b-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750144816; x=1750749616; 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=KgWoRbkLxlLo+X13Ky07ieYTngN+X9YzX1O9bj+yzYM=;
        b=BpCgj2MuJSyqK7fHTjsrX5znhCSxzVi1G64MpCSNefU2Aq/2olC9YhHS711r/xTHvZ
         pdpTsjAMyo1JCUdvOsh2l/kWbGMA5HyRKcjd7d1NyGnhJScavyHuCqOGNvJhWkwl3ETB
         Jcey4CU8dqwHrwzzMSirhKGNHbUgo4cpiw0Zw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750144816; x=1750749616;
        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=KgWoRbkLxlLo+X13Ky07ieYTngN+X9YzX1O9bj+yzYM=;
        b=e2P6ZCEb68psxN2bbqs8tmBQm+7PCL6e1c1MmMc6kWz14B77niEIdyNfND/36hXKzo
         fs49C6FojPixbnh8YWYCfzAfEYDVayBTaOiScvWvVmVqE6fFXpPVtvrHpWYOhV/462gD
         wI+2137eYi5CHTAyKof3+AZFZfk2QR/qDEyyDTnjE/E4XvMejfG0JdraLS7X8rP0eimd
         0Q4I6/O8ijguhVqosJJCQ+LIz+0oxK3gFNf7bkzNx0qNxhDHimU/0Nv5xYaPcvvPg5Cl
         mZHyRjIVFbpPMtQWgo/elDaAhW9NicwQpqGd+pFHCnmYEI6dCirJB1Q1qvQgiMqQclab
         zuMQ==
X-Gm-Message-State: AOJu0YwYmdNB1ACyjXhYd8CrRfZbUeu8N6kfcrhQ+AWXkSNFoW/Hy8H/
	XrDVONg/U2hqg3aeAJm3xps6JhtFzrF3tIcqU30FEjTrPJuz3afFoN3CjbTCYncNG6A=
X-Gm-Gg: ASbGncsqZqTvI6NTv6vIg5W4NlZSz+sEbJnk5SglAPnzoRd0K3g8VvVQEWHZNsbk6kn
	x16AuWyCUW8MSca+xumDxfBQajl7K8pvAe3bK5n5FFI9ZJj2rYjUcOl0c1AC6+vIagKazTI5v5b
	UkNI2OGXCNATv1VTQHOPbs34cgk+Lbz8WntxSn/EwgrOuBFCgwrlszeTdtsq6IQvrzmaqkmsMC0
	xld2Zxrc5zsSQyTGU+VWN6/E6FjRxTnKjDs5nQNcHf8lfLpmZsUpBL03rQMCyetPX7bjDvWnbWd
	cltl0FaM6TcOGFweUqTvCYeVJG73vOFj3kJJ68Fz26dC6uFwjB+zyKT6GTfYLmYUOJ20PcV1dKZ
	3kHqJ48r/FNro07kyynV098TQ1jdooQ==
X-Google-Smtp-Source: AGHT+IG2AxQJSRkyM98/mvsz0ESKrdJqmbcO+tm2Qr5g00asmiIGkso15oBBB4DDU4D9d6HqfOBSig==
X-Received: by 2002:a05:6000:4308:b0:3a4:cfbf:519b with SMTP id ffacd0b85a97d-3a572c455d4mr10586378f8f.44.1750144816295;
        Tue, 17 Jun 2025 00:20:16 -0700 (PDT)
Date: Tue, 17 Jun 2025 09:20:15 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com,
	anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org,
	michal.orzel@amd.com, sstabellini@kernel.org,
	teddy.astie@vates.tech, dmukhin@ford.com
Subject: Re: [PATCH v7] xen/domain: rewrite emulation_flags_ok()
Message-ID: 
References: <20250610144500.3176661-1-dmukhin@ford.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Mon, Jun 16, 2025 at 04:03:14PM +0200, Roger Pau Monné wrote:
> On Tue, Jun 10, 2025 at 02:45:12PM +0000, dmkhn@proton.me wrote:
> > From: Denis Mukhin 
> > 
> > Rewrite emulation_flags_ok() to simplify future modifications.
> > 
> > No functional change intended.
> > 
> > Signed-off-by: Denis Mukhin 
> > ---
> > Changes since v6:
> > - simplified checks for PV further
> > 
> > Link to v6: https://lore.kernel.org/xen-devel/20250610004216.3012253-1-dmukhin@ford.com/
> > Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/1862559089
> > ---
> >  xen/arch/x86/domain.c | 78 +++++++++++++++++++++++++++++++++----------
> >  1 file changed, 60 insertions(+), 18 deletions(-)
> > 
> > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> > index 7536b6c871..fdbd064ebf 100644
> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -743,32 +743,74 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
> >      return 0;
> >  }
> >  
> > +/*
> > + * Verify that the domain's emulation flags resolve to a supported configuration.
> > + *
> > + * This ensures we only allow a known, safe subset of emulation combinations
> > + * (for both functionality and security). Arbitrary mixes are likely to cause
> > + * errors (e.g. null pointer dereferences).
> > + *
> > + * NB: use the internal X86_EMU_XXX symbols, not the public XEN_X86_EMU_XXX
> > + * symbols.
> 
> Not sure if it's worth expanding the sentence a bit to add the reason
> why X86_EMU_XXX should be used (so that we take build-time config
> options into account for short-circuited emulations).

With this comment adjusted as you have in v8:

Reviewed-by: Roger Pau Monné 

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 07:34:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 07:34:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017854.1394855 (Exim 4.92)
	(envelope-from )
	id 1uRQps-0003Hl-4q; Tue, 17 Jun 2025 07:34:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017854.1394855; Tue, 17 Jun 2025 07: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 1uRQpr-0003HZ-W6; Tue, 17 Jun 2025 07:34:23 +0000
Received: by outflank-mailman (input) for mailman id 1017854;
 Tue, 17 Jun 2025 07:34: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 1uRQpq-00031F-Rh
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 07:34:22 +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 7c46ec44-4b4d-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 09:34:21 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a53359dea5so3652449f8f.0
 for ; Tue, 17 Jun 2025 00:34:22 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a57b15015fsm7488323f8f.95.2025.06.17.00.34.20
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 17 Jun 2025 00:34:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7c46ec44-4b4d-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750145662; x=1750750462; 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=T/lgz/gActmKMq+HBrVyBXjFkXG0GLK33eVDEVDlgvc=;
        b=rNpsD5KUv3sN+C5s2xKwox3zpzjSvAeatXKvAN3PqBSh2l7aCoIzX0tEN/A8SqhaYq
         LjNX2MC7btAVHRo2/RuJj68efnt0GyekaebFSfFQSmFILfh7bvOHFJmHHgw6+a8IDtuc
         7RcpOAvY6vUo9jftrvXLUgBGa2SJU9cCRI4uc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750145662; x=1750750462;
        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=T/lgz/gActmKMq+HBrVyBXjFkXG0GLK33eVDEVDlgvc=;
        b=Gk/xvKa/BmUgnx8x3dUOkTsur88C1LoNT1Xo4ONGgNowVAwH34AS2BpNQU8yroAxnR
         h+ZkmU3rrNiHpurGQSJ5O8TQnoWzZr8xvfjKQTRnf8XhVtBoo2reXxgi27G5BMrsC/JO
         qGO6Xrtt+JdhMl6vQUCFqMXdKCezCPc7J/8NMR5UG3MG8+ALobZG76sApdCxMP7Ilfy0
         hog1vHarEw5BpXBz4kwExfmrw420iR6TXFmKPsQc85s+cpuxizsgHtnGj3ofI7OvBy0L
         s9w7hPbnJUrzxHuCsAixYX6RhAlPWRba0jEDiO9kbSrFiGDvKXyQVqPcSC1aazrzbAzE
         xr9A==
X-Gm-Message-State: AOJu0Yy9RU2wUkPVhzOLjFZN2UTCNEUQIn6StFxflRIF3IcndXs2yJwr
	go2tXXQEwGwOORPcFVLTadgkeDaFvNWP7VRHHrjA50UKZ2JOC/XivyVXWoTq8Zt1F1U=
X-Gm-Gg: ASbGnctbQSy3ea6d92B71hJuVpDAZyW8Y8wbrkC1dbqgE9A0ze850SKsF5u+wC8UEFv
	shq8sWTLmxjOFXsnX9m+6KBln+zjV19rfQCJ/nOhixA+dytdWaC0yis3yBiwAtHv9ORNKHLKVmt
	OFBXNQ8ULi2/QkcjWeZOvrJSFsYbCo7U0WCZKopE/ZQnqU7EjpJIxLPzRRC2XqYYlDAQ4Gx6lMj
	puNLFnHKMGUGBhSc15pN6jNs+WNWL5bVLnT/7QI1dH5lq6/NKhCQ28XR60ZeJHQ+v039HXd4Dlm
	PnriRSGS1nmd42LlXIixPmC1lt6hqFxwFntc93bxq8pTCYZQOFN7EPVs5WTb7w1QqlfVTs7aY8T
	xfQy5eFcosA31j4/KDUzPvpKiJkxenQ==
X-Google-Smtp-Source: AGHT+IGW3YfSmdFOQsnAznjxQYSOz95paO7wFu72AY1IIpRokbzL1fJO2xkHmoQzrvs7ZUEBMur8zg==
X-Received: by 2002:a05:6000:288a:b0:3a5:3a3b:6a3a with SMTP id ffacd0b85a97d-3a572e5856amr9878648f8f.54.1750145661536;
        Tue, 17 Jun 2025 00:34:21 -0700 (PDT)
Date: Tue, 17 Jun 2025 09:34:20 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" ,
	Andrew Cooper , Wei Liu 
Subject: Re: [PATCH v3] x86/HVM: restrict use of pinned cache attributes as
 well as associated flushing
Message-ID: 
References: <35ba8ca3-ed00-491e-a782-2974597cfdb3@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <35ba8ca3-ed00-491e-a782-2974597cfdb3@suse.com>

On Wed, Jun 11, 2025 at 12:19:30PM +0200, Jan Beulich wrote:
> We don't permit use of uncachable memory types elsewhere unless a domain
> meets certain criteria. Enforce this also during registration of pinned
> cache attribute ranges.
> 
> Furthermore restrict cache flushing to just
> - registration of uncachable ranges,
> - de-registration of cachable ranges.
> 
> While there, also (mainly by calling memory_type_changed())
> - take CPU self-snoop as well as IOMMU snoop into account (albeit the
>   latter still is a global property rather than a per-domain one),
> - avoid flushes when the domain isn't running yet (which ought to be the
>   common case).
> 
> Reported-by: Andrew Cooper 
> Signed-off-by: Jan Beulich 

Reviewed-by: Roger Pau Monné 

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 08:35:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 08:35:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017979.1394885 (Exim 4.92)
	(envelope-from )
	id 1uRRmO-0003Y5-Id; Tue, 17 Jun 2025 08:34:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017979.1394885; Tue, 17 Jun 2025 08:34:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRRmO-0003Xy-Fx; Tue, 17 Jun 2025 08:34:52 +0000
Received: by outflank-mailman (input) for mailman id 1017979;
 Tue, 17 Jun 2025 08:34: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 1uRRmN-0003Xs-O0
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 08:34:52 +0000
Received: from DU2PR03CU002.outbound.protection.outlook.com
 (mail-northeuropeazlp170110003.outbound.protection.outlook.com
 [2a01:111:f403:c200::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id edd13904-4b55-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 10:34:48 +0200 (CEST)
Received: from AM9P250CA0010.EURP250.PROD.OUTLOOK.COM (2603:10a6:20b:21c::15)
 by GV2PR08MB8728.eurprd08.prod.outlook.com (2603:10a6:150:b3::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.28; Tue, 17 Jun
 2025 08:34:44 +0000
Received: from DB5PEPF00014B8B.eurprd02.prod.outlook.com
 (2603:10a6:20b:21c:cafe::ec) by AM9P250CA0010.outlook.office365.com
 (2603:10a6:20b:21c::15) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.22 via Frontend Transport; Tue,
 17 Jun 2025 08:34:43 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 DB5PEPF00014B8B.mail.protection.outlook.com (10.167.8.199) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.15
 via Frontend Transport; Tue, 17 Jun 2025 08:34:43 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com (2603:10a6:5:1c::25) by
 PAWPR08MB10118.eurprd08.prod.outlook.com (2603:10a6:102:368::19) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.28; Tue, 17 Jun
 2025 08:34:09 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668]) by DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668%2]) with mapi id 15.20.8835.027; Tue, 17 Jun 2025
 08:34: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: edd13904-4b55-11f0-a309-13f23c93f187
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=I/q1GtTXD7Uy0GetUiKK93Wy2itF5q2mVJxNfpCjXxXRGag2SQQH+l4DO+5XfVFtBp/KxxxoI91lRo9s6Z1Z9cCEq4FcshlwGenL9NX1yd8hvzfWQ/q1EzAeSsqGEgfMRxrmD8UDDd9rGAS3qXrTJ89bZCdB/QJCp0cPWJStd6dzX+VZCXnqXhrnjwFBThO5xR4pHno57+pDz5oBEbOH08I3Ow9uoLZ/T7YhsKIm2yjSmyE4+/K/I4xbSRr3AD6opJt9Cjc+907x35BJIfqCIsf9D6u5og+02Q9IZAvZ7IoSyVvtBMU3d+87YAWs9kBGASOx22B27HzH1Q/LVlsCbA==
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=/CqsIrdGBjKGPG7A2+c9dkfoIZsjNWgoPUATn9f4q8E=;
 b=cf9FPJC7/jqp1+ba8FtQMOBoce/iB1NNcyE1BXWFA4sKlVo/tcUjRfCyXQCO8Z3ynsTkF9npKBv8ThZt3Nqbcacf2hCrSMW94kFg9YwB+DCXmnjw5+HcKUrFTDRbCf8cVyTH3M8TjVROmi7x95kcd9bYaWCjsNSGtn4zXmOlf4dmtTpeu4NcdDrHdDYkTla/9xj6SNIILIzswiMRBxg4oUb4mSk50ZlNZZTbHdHQkfAZlV3babEzasJuvrC1HZQuvtCQyGh8KfBzBr8tlhclnyL4BT/o9f2LXpzQXapgrkZdEPWoifHaF7Yj0ZPiYzaMwKktFGZbrp4C/7fkvT4shw==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=amd.com smtp.mailfrom=arm.com; dmarc=pass
 (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
 (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=/CqsIrdGBjKGPG7A2+c9dkfoIZsjNWgoPUATn9f4q8E=;
 b=atmT+zTS37W9fP99WCVXoM1gXrJPjDl0dhNu81gzJB+KQqQ2u9CNhQ0HPYHPPggqYJYG7jtP4qD5E3pcMSy6Et227RQT1VPOCojBJyPKq9OuFPHfcAKKCLQtGr4IH2R5GvZbl67BGyVcyoxF5PuEZqyGA39VKSS88hZHEbPxVCA=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=gSeTIF9ojrNkXYiNcQzP/lQnVSCDOd3MWvnzknjd55LkQa2sg6xu1ZsoM988uLKrEbEmu5pZq9O2Yo3aFi3f+671+8rhIGJCuWJ9DAm+mHHvqB1QchmnIwT3ykmL9xkIUF1OqD4r6V5B6EpsBK8WoPlP/SA8Dy3UhITrgG1f5RYerh+T7qaCQXQ5gRfswLqpAEYtT7FwzDVc6q86sJHTPLfsQab9mXCwtk8YEuMKDMXJxWtGWQ0y3xgmbsmC0dGK5TiBRLsWdvQDvNJKWHCJdHrMRvN8mhRtPAW6XsRUavMcVWK9Qun5Q9NNJVU5CqomC4LU9yQBDMvld/OZmeIdbA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=/CqsIrdGBjKGPG7A2+c9dkfoIZsjNWgoPUATn9f4q8E=;
 b=hmCRc8IT8ajwypnulvJOB6eHIro+fPxJhJ/xZ2mnRA8BhHsKknTU0VFSdU3CULUvr6Gx/EsCt33O9twOBfEu6DGTqx0WC7ketkoXfKXaumf8xav2XWdgKe+/5flY0iBeWSTkmGN49PzPUWEizpJeVZoAZjdj/hrKDdqGSYZcpo/EKZGILJzmOPt+xDxUvQkPIsoAhMlGHgzYZ3W+seq28eR8gug/q8IOjbJwJWrSVpMZLFZEug+k1gVDw/1n9OlXaAjiZoX64GBBjgNev3YhlfzCK/XMqvI14OXDJkDNogxO4a3WaU5WcDTzNr6cbYuQZtuIM9QJI3BW44t0eJdJ7g==
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=/CqsIrdGBjKGPG7A2+c9dkfoIZsjNWgoPUATn9f4q8E=;
 b=atmT+zTS37W9fP99WCVXoM1gXrJPjDl0dhNu81gzJB+KQqQ2u9CNhQ0HPYHPPggqYJYG7jtP4qD5E3pcMSy6Et227RQT1VPOCojBJyPKq9OuFPHfcAKKCLQtGr4IH2R5GvZbl67BGyVcyoxF5PuEZqyGA39VKSS88hZHEbPxVCA=
From: Luca Fancellu 
To: Michal Orzel 
CC: "xen-devel@lists.xenproject.org" , Andrew
 Cooper , Anthony PERARD
	, Jan Beulich , Julien Grall
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Stefano Stabellini 
Subject: Re: [PATCH] console: Do not duplicate early printk messages on
 conring flush
Thread-Topic: [PATCH] console: Do not duplicate early printk messages on
 conring flush
Thread-Index: AQHb31hHwh97vWYji0Krd5CV3ZKI8LQHBluA
Date: Tue, 17 Jun 2025 08:34:09 +0000
Message-ID: <46A1D85C-483B-4386-91F7-FD59A9698052@arm.com>
References: <20250617071940.10445-1-michal.orzel@amd.com>
In-Reply-To: <20250617071940.10445-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.600.51.1.1)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB7PR08MB2987:EE_|PAWPR08MB10118:EE_|DB5PEPF00014B8B:EE_|GV2PR08MB8728:EE_
X-MS-Office365-Filtering-Correlation-Id: 0be5b115-a2f4-4e0f-9194-08ddad79cf51
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?ZEFYN0RIRndqUnFESWtGNWhhWmluMHdPTnRLRFYrdE8wRmtmYTBodkUraVV1?=
 =?utf-8?B?TDN4RndNUmlINnYrYkN5ZUs1aHRHOXJOV0NWTXdzZ0h3ZVdJYTRhV2Zad0tz?=
 =?utf-8?B?QzJvN2V2Uk8veG96SkZlcjRaVnJaVTJaTjFNWnNZaTdVM0laTVBwMnpSb2dj?=
 =?utf-8?B?bktUMGdkRDlMNER4QVltU29JNERsVXF6L0l4bG9MSWFZeEVHbml3VEk4WnQ4?=
 =?utf-8?B?RzJwSWluRkRaWDlNTk1WVGRZaHhzNTUzZ1dhL1A1d3ZaYjRyWjA3YTg1TXBV?=
 =?utf-8?B?ZlZzelR5ZlF1UHpMd3RkWHMyc0JZL25RTVFLcXNNL3F2T1dJWEd3TEtFZW1U?=
 =?utf-8?B?OTd2MlZjNXFxOGxraGhmdUdXaXRGTEtKOGpaeTNiSHZxTWp1bDljZndTdjJH?=
 =?utf-8?B?K3lrOUkwVlNPNmRYdmY2am9HaWlNb2VSM3BWMW04N3JFMldzc1kweDdEbUZ5?=
 =?utf-8?B?SjJ0QTBXWVNoUk83VWIyTUMxbkQvRWVFZVdsczJIRHBWR01sYTVoOWczUlpv?=
 =?utf-8?B?KzB1MWZ2Y0RMWDlnaVZseklMb2J3V25iaTJPNEtuWDhWbEc2Y2JZRGNneC93?=
 =?utf-8?B?aUxBQk83NTJGUXg0Z1VqT0duSFROaHNZM3ZXUFcwa0tGUUpUdEdYTEgwdVJQ?=
 =?utf-8?B?UXdwcGd5RGkrMVJHMWJ6N3czZVNYcGtpRm1XbURzZDZBOTUzMjFMVHdpRmNl?=
 =?utf-8?B?dkhZYk1xS2d2bHZhQXFvdnhSZmd1S2tNbGlabVY4M0dSbXcrUHVVQjZBdVds?=
 =?utf-8?B?eEJxUEJyN3hvbm5IRnFnRGlGckxzSlkxQVpJTHBvQTFoOEM3eEJmamZ6TWQr?=
 =?utf-8?B?RFBHR3pqTlZYdm83b0JoK21MM2UvbWZWaFdydGwrZjJtZENCN2JTUTBORGtj?=
 =?utf-8?B?MzF0SnZveEF6TGlXSk1iSzRBK3lQNnk2MStWdDdEeUVSZEh2cWhhNXVDNUxI?=
 =?utf-8?B?czZlVGJUZ2pYVy95UmQ2Mkw2L3RRcHd0UGZLaThSVlJheG5wZnJEYW14MDJE?=
 =?utf-8?B?a3RGYlBZbkdSTGhWY3NPdlRqcmNkdUdDSWtINUVBcUljcmNFR2czK0hrZjhv?=
 =?utf-8?B?U3AycUV3aDVEdi9IOVpvM05aU1RiUGpEOWpPdEVuTmp2d0F6TXVtNitQWld5?=
 =?utf-8?B?UW52QjVJdWV2ZlJ3eEtYK0h4STRUYnR5OUpZVkxscUFCZlF6UU1uc2FsSmZY?=
 =?utf-8?B?WWZDWms2ZUFlQW5XK0JobVhCQThBM3Nud3BzaTVVaStwUXd4OURuVWlSYzlu?=
 =?utf-8?B?WXBPY2xqZzJwWHY2TFVPdjlBaVYrL1RQTEVnUE5jSHQwcS9jSVZSeldaOG50?=
 =?utf-8?B?dE1VQzRMR1JhN3Nkdis5dG5UOWUxYjQ1SnNaUmd1WlRRRExyZjA3amNwdFVV?=
 =?utf-8?B?QnhjVUlXRTZ4S1RsZEdSL1o1eFllZkZ3a3FwVkx5Q1VSUys3VWpRK0pNcGg5?=
 =?utf-8?B?eTlad3MvZU0vOHVwNEQvcnVJMnlxQ1MwWlEzSkdVSXprR1E2cTUzdU4zbklm?=
 =?utf-8?B?VFhoMHJEY2g2Vi82T1NPVEdILzhRMlBFL0k5VkVybjM1eXJnT1VZTkV5eHJI?=
 =?utf-8?B?bVBpU01wbm1UY2NSWGc0Nit3a2JPWFVpYTArUGtSSENtM1RKdkdONk54SWZp?=
 =?utf-8?B?TS9kcjk3ZnlqUHRuOEUxbkNVQzFKZ1M2aVUzU25ObHZMdm8rOTRSdnBuR1Y5?=
 =?utf-8?B?MmRqSkg0SEdKUkRvbTJhczl0VmhUUTVERkF5RzExZWtBNnp2TTJMN2lJYmlB?=
 =?utf-8?B?NCt3VnZHcXVSb3hFaEk3ekpxaFZxMk5saktUSkV6ekxMRDM0WGJUWk8xSW9N?=
 =?utf-8?B?b2dCeGp2WUpRYXNlbkhMZ3Rad0JJMmdteXVITnY5ay9qM2VWYXl5UjBKcktv?=
 =?utf-8?B?eXE5cVZjcGFxQ3l4OU5ZbWlMUTdaeGVFSGpKcnhZdCtJMnEzZnhDcC9YaXNH?=
 =?utf-8?B?Qnp4eVBMWWxjQnhzVWZLUU8xemszVno2VUhscllkZXoyWW1BTUEwVVVXR0FO?=
 =?utf-8?B?RkkyTnRjVFRBPT0=?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB7PR08MB2987.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: <5E4DD83C74B3724A8760CD151B15E3C5@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR08MB10118
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DB5PEPF00014B8B.eurprd02.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	60a74e1a-95b2-41ba-885c-08ddad79baea
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|35042699022|36860700013|82310400026|1800799024|14060799003|376014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?YlErOGFIQ3hFd2FMUnY2K3JCMzdVMkpBcmdTWjNPSzVVdHZNZWFaWTZSUU5x?=
 =?utf-8?B?cE04blhRd3ZJMWhDSTVZT2R4M29FeFhodGRjTEE4ZVJiVXV0d1RlL1IyM25x?=
 =?utf-8?B?RThpbWJzaDJmMFFaRENrcWpYL3l6bHB2RjZ1djlsU3J5SEhuSXpWclJFRkN5?=
 =?utf-8?B?cEg1bVlRanNpZ3VFTmZvRUpSeGdiYmZwMVB0OXljSUZ2NGwva2lNdVNHVFFQ?=
 =?utf-8?B?OTM2ck1kS0hpUHpJaXBxQ0wrTXhGMUcwZDdCSnBYUDVMQkY4elArSkJkdmFj?=
 =?utf-8?B?YnB4Mk1mZjM0RkZ2ajNldWVqMDI4MDJJY01lRjVpUWtJZmtPM09kMExlcW81?=
 =?utf-8?B?UElGMEVvdWR1S2FXaXh0QkxIVHVhYVcrcEVTQUk1RTRraUpnR0RZQytDeGxt?=
 =?utf-8?B?ZUU2RHZXdTBIakhGSHcvellsaGpDclZpUFVuNWczVlNSQkdqNEE3b0tRbHBj?=
 =?utf-8?B?clVCSmQ2U2t6ZjdMNmdoT1Q0UXhyQngrMjcwT2pGZCtGSW9IYjNoYSsrYkRi?=
 =?utf-8?B?OEc1eGFVMHVOY1ByRDEvMGdKSXRTMXIvaFpmUUZ5ZnpQUjk3SiswalI1b0Jx?=
 =?utf-8?B?OVoybjJWeWdzb2kyVmJUZ0MwUUh0cVloVXY3d2pHWCtHSWFzL1FxZjFHUytW?=
 =?utf-8?B?dEdFWmdNYS9hV0ppeTFCQlZBUE4rbGVneXpnN1FHalpmTUI1am84RDVpT1FV?=
 =?utf-8?B?QlFjenBqeDFQWWw0L1NsVmdTK2ZHUTRWRkJjTnkrWm02ZU5tV3ZGSVVMb2My?=
 =?utf-8?B?MmpmK3pMWlUyWGIvTEQzVld6ZHpPck81SWI4V1k5NDdRZmttS1V2Yk1hdWVE?=
 =?utf-8?B?MUxGaVdUZmdYWlRsY0dBRnl5MXdicFozS2UzRktDTU5SeWJ0YjZzSzduL2ow?=
 =?utf-8?B?VXZxSStpWEl6N3pKSXVidFRnRjFZZU1UanJMYXpRcHRCZFMvYlpJSExOa0U1?=
 =?utf-8?B?VXcxZUpha2RBb0pCa0xlREhqQzhQOHVSZngyNkNQTXRicHNDNHEyNXovNFJl?=
 =?utf-8?B?ZG1xUjRYaXFCL2pUaEpkSGVKQWY3NldrQ05rNWRyeWFUZzhkQWJJdi9namhT?=
 =?utf-8?B?UTNWaGxlMk1YaU1HTURvSGdOZkZweWlWNUFZQ1ZuVk5oYUNIQ2JtR2tNam9w?=
 =?utf-8?B?QVd2NEdYRXdYTkRlRlh3OGtmOHpYSWlzUTlkdjBtN0UyOWQwZzJBTU1SODFY?=
 =?utf-8?B?TlRZTFFWZVdob1Jpajh1RlpONGdNN1UvRzhTTVZTK3JoZWpwZWt2RTBPQW5H?=
 =?utf-8?B?cWJmZGc0L2dldTJvd2puZXZRVWlFM2ZjTXJIVGduWW1BdzU4ZExYdEpTNEdk?=
 =?utf-8?B?cExLT2tlem1Vazl4TFZrR3ljdExQMVBFck1wVFA0ZXFuZjNhM3FGS1RmKzJu?=
 =?utf-8?B?ajVoTUlBbFRrenpWQ2hSaDczL3VFbVcxQTRrNUpudXFxb2lUTm82bjMzQko1?=
 =?utf-8?B?N0R3ZHRYOWt2d3hNSGQ5VE5wQ1ZVek9LcjVCRFplV2FDd0NhN0w4YitvTmtl?=
 =?utf-8?B?eWpMYzA2cjZVUThJMk8vSERqb3Y4Wm50T2J0VXdlUk5CWUV5VTVDd3J0djJ0?=
 =?utf-8?B?SmFheFJYNTFTNGQrWW5Ia0M0enA3Qm44YUc1MGxSM3ordWF4dHZpckZzeE9p?=
 =?utf-8?B?amJhdGVhaGIvRHdnRTc0RWthYXpxaXgrd1E1YzdOMG5oL0dXaWRleHNFTnkw?=
 =?utf-8?B?Ym5xaWxNekYrb0tHYmhmTTdDeVhGQXBFR2x2RGRjc3FDOXlSaSsxQ3Z4UHFK?=
 =?utf-8?B?U1RQSTlzQStNbmJUcDRaQkZrSjFGZUhpZTk3eWhNcUIrS1ZpTHppeUpTVTl3?=
 =?utf-8?B?TjE3S3dza2pxOHNEWHpJSG9PMm9VSmpYVmpnN3lPdkJKR0dGNGZzTUdmZ3B0?=
 =?utf-8?B?RHkxN1h4WWhQSGgzMnp2YzNDeXY1ZG1od3BucjB3b010cjBKV3VFMjYyTHVX?=
 =?utf-8?B?dTNyNnY2UDdNb2R2QVNjWENMVUxJNmtrN1NQZERyMXBLMEY5KytjL0EzSmFq?=
 =?utf-8?B?NHlQcFpLY0N2L3pycUJDeG4rdHZwd0QzeGpucXg0dkc4cHl1bWVLYmd1bVJs?=
 =?utf-8?Q?A9VIM4?=
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(35042699022)(36860700013)(82310400026)(1800799024)(14060799003)(376014)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jun 2025 08:34:43.6238
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 0be5b115-a2f4-4e0f-9194-08ddad79cf51
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DB5PEPF00014B8B.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR08MB8728

SGkgTWljaGFsLA0KDQo+IE9uIDE3IEp1biAyMDI1LCBhdCAwODoxOSwgTWljaGFsIE9yemVsIDxt
aWNoYWwub3J6ZWxAYW1kLmNvbT4gd3JvdGU6DQo+IA0KPiBDb21taXQgZjZkMWJmYTE2MDUyIGlu
dHJvZHVjZWQgZmx1c2hpbmcgY29ucmluZyBpbiBjb25zb2xlX2luaXRfcHJlaXJxKCkuDQo+IEhv
d2V2ZXIsIHdoZW4gQ09ORklHX0VBUkxZX1BSSU5USyBpcyBlbmFibGVkLCB0aGUgZWFybHkgYm9v
dCBtZXNzYWdlcw0KPiBoYWQgYWxyZWFkeSBiZWVuIHNlbnQgdG8gc2VyaWFsIGJlZm9yZSBtYWlu
IGNvbnNvbGUgaW5pdGlhbGl6YXRpb24uIFRoaXMNCj4gcmVzdWx0cyBpbiBhbGwgdGhlIGVhcmx5
IGJvb3QgbWVzc2FnZXMgYmVpbmcgZHVwbGljYXRlZC4NCj4gDQo+IENoYW5nZSBjb25yaW5nX2Zs
dXNoKCkgdG8gYWNjZXB0IGFyZ3VtZW50IGxpc3RpbmcgZGV2aWNlcyB0byB3aGljaCB0bw0KPiBm
bHVzaCBjb25yaW5nLiBXZSBkb24ndCB3YW50IHRvIHNlbmQgdG8gc2VyaWFsIGF0IGNvbnNvbGUg
aW5pdGlhbGl6YXRpb24NCj4gd2hlbiB1c2luZyBlYXJseSBwcmludGssIGJ1dCB3ZSB3YW50IHRo
ZXNlIG1lc3NhZ2VzIHRvIGJlIHNlbmQgYXQgY29ucmluZw0KDQpOSVQ6IHMvc2VuZC9zZW50Lw0K
DQo+IGR1bXAgdHJpZ2dlcmVkIGJ5IGtleWhhbmRsZXIuDQo+IA0KPiBGaXhlczogZjZkMWJmYTE2
MDUyICgieGVuL2NvbnNvbGU6IGludHJvZHVjZSBjb25yaW5nX2ZsdXNoKCkiKQ0KPiBTaWduZWQt
b2ZmLWJ5OiBNaWNoYWwgT3J6ZWwgPG1pY2hhbC5vcnplbEBhbWQuY29tPg0KPiAtLS0NCj4geGVu
L2RyaXZlcnMvY2hhci9jb25zb2xlLmMgfCAyMCArKysrKysrKysrKysrKy0tLS0tLQ0KPiAxIGZp
bGUgY2hhbmdlZCwgMTQgaW5zZXJ0aW9ucygrKSwgNiBkZWxldGlvbnMoLSkNCj4gDQoNClRoaXMg
TEdUTSwgSeKAmXZlIGFsc28gdGVzdGVkIHdpdGggZnZwLWJhc2UgZm9yIGFybTY0IHdpdGggQ09O
RklHX0VBUkxZX1BSSU5USy4NCg0KUmV2aWV3ZWQtYnk6IEx1Y2EgRmFuY2VsbHUgPGx1Y2EuZmFu
Y2VsbHVAYXJtLmNvbT4NClRlc3RlZC1ieTogTHVjYSBGYW5jZWxsdSA8bHVjYS5mYW5jZWxsdUBh
cm0uY29tPg0KDQpDaGVlcnMsDQpMdWNhDQoNCg==


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 08:37:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 08:37:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017990.1394895 (Exim 4.92)
	(envelope-from )
	id 1uRRp9-00048L-3P; Tue, 17 Jun 2025 08:37:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017990.1394895; Tue, 17 Jun 2025 08: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 1uRRp8-00048E-Vn; Tue, 17 Jun 2025 08:37:42 +0000
Received: by outflank-mailman (input) for mailman id 1017990;
 Tue, 17 Jun 2025 08:37: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 1uRRp7-000486-Jv
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 08:37:41 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20603.outbound.protection.outlook.com
 [2a01:111:f403:200a::603])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 54108cdc-4b56-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 10:37:40 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 MN0PR12MB6104.namprd12.prod.outlook.com (2603:10b6:208:3c8::14) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.23; Tue, 17 Jun
 2025 08:37:35 +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.8835.027; Tue, 17 Jun 2025
 08:37: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: 54108cdc-4b56-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=SarLjttMj6JAjjK0puUDWaLUVfnojJGf84P34T4ivxEi9FCpYpymT27rdz2D0mLEhAvXNqbkvkuqNXoGM2I5tQQ4SbgXs3iY0jApcg/xFoeIPqEoWd28fIPBhJBi+ewJqDj20zhrStouBgT5mcMVsKj34A5AnuHEjixwEnDmZR1JLC1YyfOYaKwHyiX9mjiQ/IUA/4yIQJHRBsxzJ7LzzuMTbS30IicPLITWBzmB33Euu2Zq47VRHveLSO/NjrBT7fZDipUiAqGqubl5J82aUoS/kFU0bPZRb7EAk4UUM4yt+TBqaO+oNW8pMGzWFw+/1XS7lgJC7kcVB81YJdpDgA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Nf0QYkR/TafdU4WgMuO/fHhhOQMqY8vnUfXysXD//aA=;
 b=E0RClnAhr3Kr/Ag7s0/TZdHwNyPuDeN42shopX7W+XkE5Yz3T5MEmkAPjZ/5p4KMT6A6ZNBwgJD0b9gZ5OUqzjHESu80RBDCg7d7X9bA94gGsDhnPFRWaDIkg6f10ZnrgnTTedx78VxtFirvAILj9QRsJa1Ka511mwqUH1WUT/E+KZNMsM3n3p3FCyn8lWdNZVKpna/4/ZCq/jC2MAAqAWOgIP2t4mEme5RPwOsdwJLp1p7IG5TRWsUJOdlb5HJ9Wj48XI/3hJOGnE7BH/bymcdM/s+qmDUgrVNgdBU0/NlGKvBMaIHXxMYw/yN3/QRQHj50/jG5JdsgrEPypjP1Ow==
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=Nf0QYkR/TafdU4WgMuO/fHhhOQMqY8vnUfXysXD//aA=;
 b=uSsX8V3juHjPeVvsrOBteqdor8CtC8j61dUp39MdlBsZYC3JX8rLJjQvVE/23iHif53VAincxqRK82hXF+7O8ae7r8FWKG0Eh9WqTiRQtovWHJam9ysR44hZ1K2II12I8yEt+6KXJmvljWvqAjiw1ITjCxZ7tvzu99x3927fmgw=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Andrew Cooper
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v5 08/18] xen/cpu: Expand core frequency calculation for
 AMD Family 1Ah CPUs
Thread-Topic: [PATCH v5 08/18] xen/cpu: Expand core frequency calculation for
 AMD Family 1Ah CPUs
Thread-Index: AQHbzuRB4/qHZZI650u0dV+1tuD8lbP/mD+AgAeP7oA=
Date: Tue, 17 Jun 2025 08:37:35 +0000
Message-ID:
 
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-9-Penny.Zheng@amd.com>
 <711ac855-78e9-41bf-b057-4ed809b89c9c@suse.com>
In-Reply-To: <711ac855-78e9-41bf-b057-4ed809b89c9c@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=True;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-06-17T08:37:25.0000000Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=3;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged
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_|MN0PR12MB6104:EE_
x-ms-office365-filtering-correlation-id: cb38ce9f-8d61-472f-82cf-08ddad7a357b
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?WGFuLzhSRkZ4TkpkcGc4T3lTclJMcDBBSndDcVpIQTNpYVlQRmZNbXpwbUhz?=
 =?utf-8?B?MnNBL0t4alN4M2t3dFpkU0JYamZVc1VVYUlPZ2dYOWRmaW9oYTI4amQvUGU1?=
 =?utf-8?B?bXMxYk9BbmhZOFhwVTBTRHhEWG1OZW5tVTd1eTJnM2pnSENmNldSRTZjRGc2?=
 =?utf-8?B?c3VEaDY0WFlBdzhDVDJUVXMvcHFWbnJ1Z2tlKzhKUTF2MEZRMXBnb1NXYW9X?=
 =?utf-8?B?cVhjZ2h3Rmc2UmtvZTAyMGEzU3pkNHRjK3R3M0VhbUJhb1pkUzhYejZYaXZw?=
 =?utf-8?B?YWNtb3lLR0VrR21jZFJJQXBaMnJHbm12ODFXcW5CTXNZYkFVS296V2JQd2lp?=
 =?utf-8?B?QU9lYzVUTkZiZFZaeXJZNXZCMXhDQmZLQTVoNXM0ekFNSUEwMEo2OHJBNUIw?=
 =?utf-8?B?TzNXNGpzRlQ2T1E4UFNDTTc3eGZ3WWdObHBSNXJrZnFtbHZLR2JOK0tlVWJo?=
 =?utf-8?B?bE9BdHI0bEV2V2FhT04wdUZWNUFFdG5lL0pxekhBajZPMGRvTENTbDJBWW4y?=
 =?utf-8?B?RDYwdEE3SThOS2F5R3ZWVThYYUdqazZkV2dHQmk4SytuT29TRFBONFBxd0hE?=
 =?utf-8?B?OTRtT3VrS3MyZGxRckNybG4vZjBLRnJiSVlUbEpTM21LSGNOTGl5R2NSbHFD?=
 =?utf-8?B?NHB2ck5Ec1l4Q2NSaktsRjJCK3BPcXNkOU1lU281akl1UUFTUjJZSkZZNWU1?=
 =?utf-8?B?ckZ5UmFkYlBOTzlrbE5UZEJIMFp6N1VMRUpxci82bDR0UHFmejc0VDVrNERE?=
 =?utf-8?B?eTB0K1F6aFdHdXNwK2VkR21CQldTbHNSaWFjOVZCSEduR3FQZ2czbGR4L2VF?=
 =?utf-8?B?am9IWWc4elpoSTFDc25wenZKUW83RE5qZW1Ma0dvNU11cU1GQU5icENFQ2pm?=
 =?utf-8?B?RzVrWlE4Y3R0eTZhTzFUS1BBLytIeVV2T0dLMEdJN2dtNjcvK1Q2T1ZXSEJ0?=
 =?utf-8?B?VVRvTGpiZjRyUVNxcXB0QUZhSGkzYjNkaFZnTHVtTHVIQWZ0bkRVV1FjSlFV?=
 =?utf-8?B?eEZYeEVVUkxsL2svck8rZmNnNmtuMHJTK2ZualVQRXVwbnduMzBwd3Y5R3Zt?=
 =?utf-8?B?dFU1b1NIMjh3OXpQNEFUYzQxeUFkS2tMV29jakg0aUJkVHgyVVBudGhRVUho?=
 =?utf-8?B?QTFQaVZ6RVBxUXdqQWMyTGd2SHJHTDQ1T3lwZHlVaGdCalR3aUUzL1FjU0Ny?=
 =?utf-8?B?emRBZjh2cjBPMFFwWFFEK29malMza1J2VFRXSTZoQ3pSU3FxOURhRG92N2pl?=
 =?utf-8?B?SEt3Uy9UN0FPenNTK0RnOG56SmdyT284a1YvYjlocGZoL1BYeTNKTlZBQW9s?=
 =?utf-8?B?YnFrSHlWUmhudU51Wk54bGcxYjN0TDc2N2hJa2NtWU5wa0d6bGdQY1Q1UUVa?=
 =?utf-8?B?VERncHNnWHk2Nmp3eUIzUkhza2IxcEM1SkNwUDBPSU9ocTBzYUpseHhWSEFT?=
 =?utf-8?B?QUs1LytXYi9kSndKbzIvU2k3SDZ3Rmw5YTI4NXF0NDl3OUlnSUgzcERJMzlo?=
 =?utf-8?B?QWZ2NGpBTHNXZXR3YlpSbk5ob25LR1BSSjVEU29qbUJ0dFA4K3VXSWV6V2FL?=
 =?utf-8?B?bm5FcXFvbWVYZDdjTHFpTzE4MEU4YThWTWI1VEVVRUpiQXlMaUlVOUhjOXhk?=
 =?utf-8?B?ODBiYXdLd1ZwN1pxNmZNMHNCMnFTdjZ3OFRxM2hPZ3Y4NGwwN1JGRUxYSnhl?=
 =?utf-8?B?Nm4vb2xhL3VGQWJHWXRGMk1keGx3cFlBb3JxZmdNU0k5QUJxdXNWaldrdGxa?=
 =?utf-8?B?c2dQbmJFOXZPSThtVzM4emVxdUZPTnk5cFRMS29Ubnh2R0lkRUN0YWZlMEtF?=
 =?utf-8?B?REtsQ09veXppMUNjKzRQckVWU0t3SmJGYzhLYWpKU0R0SHZqOHorSk11bHB4?=
 =?utf-8?B?c1RvdWl3SHhPU252VzJxNlNaMGwxSk9BRmxwYUpYYXV3WCtJUmltM0JDSUtv?=
 =?utf-8?B?SW9LVlVWRkNhR09YUXdEdjhLcGp1YXhJd0hzTzIrYVZLcW9tK2tYZGVYRkVl?=
 =?utf-8?Q?eNalFPzuquCzaGUQ9tyUWm2pNx1E6M=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?SmZMT1JvQWVNNkgvdEFBR2VoN0xYaVZIRkowWE9idjVzdG5lVFY2RmdIb0hm?=
 =?utf-8?B?NGp5TnRxWDBhLy9QOVhiT1g5V2RWb211Q2ZJT0dIVW04emVvSVhaUzZzeTA4?=
 =?utf-8?B?bzZaejVzaU5nNlh1emlLNHFHckIrUVY4QW8wWmZSNE1lbFNTZjVXZ3owb1M1?=
 =?utf-8?B?UW1oOFVUMmdOcFZYNGtGd0xRait2MVh6QmxaRlJESnVka1pqcUFCV1lNZHNY?=
 =?utf-8?B?Q2lTbGRRRTBsbVVNV1dDZnEyVzV3MEVJTThrMTRMQ3o0c3A2SGtadXJyK01p?=
 =?utf-8?B?YUd4RnM3R05NZE9WQTFHc0djb1Y1QnN1YXo3b3pnQWFXQndwVC95a0R0aWpu?=
 =?utf-8?B?S0JGL2F1RVlldXJ1ZnRYRXdtRlMrV0FsREQyL01hMDRWaGE3d3lSUSsyK08z?=
 =?utf-8?B?SjQxUzlKUlFSQ1hvVWNPQTlUdTRPbDVpYWdib3hqamk2bHpyTU8yWmlta3pj?=
 =?utf-8?B?WGlVbzZFN3BhamRkWUxNd1Vuc3pPYURKRlk4MWs1dkcreXlBM0xpT3E1S0Vo?=
 =?utf-8?B?TS92SUp6dkU5WStwZU1vV29CUXRHNWFkRStrTklsbVM2QUNiU1lCZFp3aGt0?=
 =?utf-8?B?YU1LWk92RXU5bE1VMUVNemVhcUJLbjJZS2p5R0k4TkNGYTdBWUdwNGMxYzVU?=
 =?utf-8?B?V2VxUWl5NC82aVhseFNDZnhjY2xnQVQ2dFVxdFhsWEhNUG9PN3JJeTRUQWli?=
 =?utf-8?B?UW5uMWxUWHVaQzZOUUVRUXB6czV1bWxXbS80enhPTkQ5aURaL2YxSjViU1N2?=
 =?utf-8?B?QUVsVnBwcWJlalUwbk9GQmIvTnU2N25jaEdib2VPVndGM093d1MvcHFsaUZp?=
 =?utf-8?B?VndDOVE3OHZMQ2dFYkEyQWlSdzR0Y0lvYjVkT0JUNk1Pc0E1bWMyL1JLUzNF?=
 =?utf-8?B?dlZ5UUNKT2FFcEVxZER0TE5SL2ZNNUpsSHdGOTJ2dEx5cHVxNHEydCtJaHFx?=
 =?utf-8?B?cHFZTVQ5RmEyQlVyYTdkU01XYldsM25GeFlXYUhpMWRBYWhnekwzSWFzazM0?=
 =?utf-8?B?dHp4bmpVWitvY0dnR0tzazliTEFVbTEydzRxOVVDbzdoOEZCZ093b2xhQXhO?=
 =?utf-8?B?ZUdlQmVDdVlwdDJ5NU01ZlZvTnRUVnhOOENySW5mdTkyckY2UFdGTHA0eUpU?=
 =?utf-8?B?MTZRWmdneWtQeThDL3oxUXBIdlVnOTJBY1o2UkdWdGgwN3VNRytia2RycEVo?=
 =?utf-8?B?ajJwY0Fwc1ZOYUQyeUsxUmNGSy9CbE5NN09ieWJuYjVRSXFpbnVEVFpFcXQ3?=
 =?utf-8?B?RHFNUVVPNTFGU2wzcytrQXd4dnptbzM0c0QxQ2ZoLzZ2cFVSRDJRYUhEOWJw?=
 =?utf-8?B?T2dVSFFxdVl1R1BqNW9BQXJSTElZbzB5UDgzSkg4N2IyWnoxYUdHTjdIRmJJ?=
 =?utf-8?B?WUNEZjRuNnZaaTQ2bVJBRUcwSW9vMll1MExoVVlUZjdNbUk0ZE9JRTdXNTFx?=
 =?utf-8?B?N3MvaVBFaEZ2SzlOZEhMbytISW5qelRROENLdVNIUVRvQWFnR1N2VGtmcnhl?=
 =?utf-8?B?S1hyS3k5dktnWU83Ti9oR0Yxem1FREtsNVBER2oyWXZVNk4zT1VYVitjQnVX?=
 =?utf-8?B?MjNtUHJ3dlk0cXhESTN6N0ppa0JPMSs0YWpmc3ZqZHp5NlVFbzZvUjArVXFi?=
 =?utf-8?B?Z2JORlVNNHlJdm5xOWRJOVh5bVZXTFh6L2lwRG5QbHU2cGlxM1ByZ1RrS2RG?=
 =?utf-8?B?SjBHQWFNYmlHTTJNcy82cmpHOU9DVzZYTXJ6eDRhNWxpaFZaR1BRQ2U2L05v?=
 =?utf-8?B?UXBWWEJmOEtEUEVCQWcwZlR2NkRoKzR2NU9zS0crYlN5VlNDVG9iYk1SOVp6?=
 =?utf-8?B?eTBWR2NVTmc5ZVdlcTMvVGVmS3EydlNnTko3L1B2N25YNm1Cd1dWcW95T2Uv?=
 =?utf-8?B?bUFyQnFkNU5LcVNsYTA1TzlrRTUxaDZLb09rdDdSYmRGZVJoVU03N1dxSExB?=
 =?utf-8?B?blpPZjVBQS9oeDB3MEY3bUhrTmxMc1ZLT2pVZ0plVWh5Y016aTV2alViN3Mw?=
 =?utf-8?B?L0ZGZFI3U0NmUHZJZGcvZGtQblNtYVMvbjJEbGMwR0JKbDZFQ05NNHUwdVFu?=
 =?utf-8?B?VC9qeTdDckRwdFN6YzZMMXlGR0E4ZUdZUzByRy9pMFlPMXc1VzZMWC9TNDRC?=
 =?utf-8?Q?CYTw=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: cb38ce9f-8d61-472f-82cf-08ddad7a357b
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2025 08:37:35.0968
 (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: hURPr8dexF+VXaHPlA3dDKxto0KiTrq5J5Uhj2HzVPsKvmvpKnBe3eXjwBKK0T90i2aQfyjeADYL8OuIo45WDg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6104

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDEyLCAyMDI1
IDk6MDggUE0NCj4gVG86IFBlbm55LCBaaGVuZyA8cGVubnkuemhlbmdAYW1kLmNvbT4NCj4gQ2M6
IEh1YW5nLCBSYXkgPFJheS5IdWFuZ0BhbWQuY29tPjsgQW5kcmV3IENvb3Blcg0KPiA8YW5kcmV3
LmNvb3BlcjNAY2l0cml4LmNvbT47IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXgu
Y29tPjsgeGVuLQ0KPiBkZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZw0KPiBTdWJqZWN0OiBSZTog
W1BBVENIIHY1IDA4LzE4XSB4ZW4vY3B1OiBFeHBhbmQgY29yZSBmcmVxdWVuY3kgY2FsY3VsYXRp
b24gZm9yDQo+IEFNRCBGYW1pbHkgMUFoIENQVXMNCj4NCj4gT24gMjcuMDUuMjAyNSAxMDo0OCwg
UGVubnkgWmhlbmcgd3JvdGU6DQo+ID4gLS0tIGEveGVuL2FyY2gveDg2L2NwdS9hbWQuYw0KPiA+
ICsrKyBiL3hlbi9hcmNoL3g4Ni9jcHUvYW1kLmMNCj4gPiBAQCAtNTgzLDEyICs1ODMsNDAgQEAg
c3RhdGljIHZvaWQgYW1kX2dldF90b3BvbG9neShzdHJ1Y3QgY3B1aW5mb194ODYgKmMpDQo+ID4g
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICA6DQo+ID4gYy0+Y3B1X2NvcmVfaWQpOyAgfQ0KPiA+DQo+ID4gK3N0YXRpYyB1bnNpZ25lZCBp
bnQgYXR0cl9jb25zdCBhbWRfcGFyc2VfZnJlcSh1bnNpZ25lZCBpbnQgZmFtaWx5LA0KPiA+ICsg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVuc2lnbmVkIGludCB2YWx1
ZSkNCj4gPiArew0KPiA+ICsgICB1bnNpZ25lZCBpbnQgZnJlcSA9IDA7DQo+ID4gKw0KPiA+ICsg
ICBzd2l0Y2ggKGZhbWlseSkgew0KPiA+ICsgICBjYXNlIDB4MTAgLi4uIDB4MTY6DQo+ID4gKyAg
ICAgICAgICAgZnJlcSA9ICgoKHZhbHVlICYgMHgzZikgKyAweDEwKSAqIDEwMCkgPj4gKCh2YWx1
ZSA+PiA2KSAmIDcpOw0KPiA+ICsgICAgICAgICAgIGJyZWFrOw0KPiA+ICsNCj4gPiArICAgY2Fz
ZSAweDE3IC4uLiAweDE5Og0KPiA+ICsgICAgICAgICAgIGZyZXEgPSAoKHZhbHVlICYgMHhmZikg
KiAyNSAqIDgpIC8gKCh2YWx1ZSA+PiA4KSAmIDB4M2YpOw0KPiA+ICsgICAgICAgICAgIGJyZWFr
Ow0KPiA+ICsNCj4gPiArICAgY2FzZSAweDFBOg0KPiA+ICsgICAgICAgICAgIGZyZXEgPSAodmFs
dWUgJiAweGZmZikgKiA1Ow0KPiA+ICsgICAgICAgICAgIGJyZWFrOw0KPiA+ICsNCj4gPiArICAg
ZGVmYXVsdDoNCj4gPiArICAgICAgICAgICBwcmludGsoWEVOTE9HX0VSUg0KPiA+ICsgICAgICAg
ICAgICAgICAgICAiVW5zdXBwb3J0ZWQgY3B1IGZhbWlseSAweCV4IG9uIGNwdWZyZXEgcGFyc2lu
ZyIsDQo+ID4gKyAgICAgICAgICAgICAgICAgIGZhbWlseSk7DQo+DQo+IEkgdGhpbmsgSSByZXF1
ZXN0ZWQgYmVmb3JlIChlbHNld2hlcmUpIHRvIHByZWZlciAlI3ggb3ZlciAweCV4Lg0KPg0KPiBI
b3dldmVyLCB3aHkgdGhlIGxvZyBtZXNzYWdlPyBXaXRoIC4uLg0KPg0KPiA+ICsgICAgICAgICAg
IGJyZWFrOw0KPiA+ICsgICB9DQo+ID4gKw0KPiA+ICsgICByZXR1cm4gZnJlcTsNCj4gPiArfQ0K
PiA+ICsNCj4gPiAgdm9pZCBhbWRfbG9nX2ZyZXEoY29uc3Qgc3RydWN0IGNwdWluZm9feDg2ICpj
KSAgew0KPiA+ICAgICB1bnNpZ25lZCBpbnQgaWR4ID0gMCwgaDsNCj4gPiAgICAgdWludDY0X3Qg
aGksIGxvLCB2YWw7DQo+ID4NCj4gPiAtICAgaWYgKGMtPng4NiA8IDB4MTAgfHwgYy0+eDg2ID4g
MHgxOSB8fA0KPiA+ICsgICBpZiAoYy0+eDg2IDwgMHgxMCB8fCBjLT54ODYgPiAweDFBIHx8DQo+
DQo+IC4uLiB0aGlzIGNvbmRpdGlvbiwgdGhlcmUgc2ltcGx5IGNvdWxkIGJlIEFTU0VSVF9VTlJF
QUNIQUJMRSgpIHRoZXJlPyBIYXBweQ0KPiB0byBhZGp1c3Qgd2hpbGUgY29tbWl0dGluZywgc28g
bG9uZyBhcyB5b3UgYWdyZWUuIFdpdGggdGhlIGFkanVzdG1lbnQ6DQo+IFJldmlld2VkLWJ5OiBK
YW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+DQoNCkFncmVlZCwgdGh4DQoNCj4gSmFu
DQo=


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 09:15:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 09:15:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1017999.1394905 (Exim 4.92)
	(envelope-from )
	id 1uRSPT-0000sl-OI; Tue, 17 Jun 2025 09:15:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1017999.1394905; Tue, 17 Jun 2025 09:15:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRSPT-0000se-Ka; Tue, 17 Jun 2025 09:15:15 +0000
Received: by outflank-mailman (input) for mailman id 1017999;
 Tue, 17 Jun 2025 09:15: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 1uRSPS-0000sY-2c
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 09:15:14 +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 92b99877-4b5b-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 11:15:12 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3a54700a46eso3501808f8f.1
 for ; Tue, 17 Jun 2025 02:15:12 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2365de782c8sm74888445ad.94.2025.06.17.02.15.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Jun 2025 02:15:11 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 92b99877-4b5b-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750151712; x=1750756512; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=T/xbfcQE9fcmbG/Cayk7Rg/b8k8OXv0fYg2I6v//2HA=;
        b=TlG4+yMiDHzt2wH63s8mE5Cjf0OCPbeYClgWYTRt2oXQhQq8iKIKvi3vfjSRd/2DuX
         TmTfmrOth3t+9vy34WKvsmhdzNhqH5ms8QK49GVLHIkR5t/Kj7LoMVIKI8o+HtsUoVVb
         wsSUF84pPVoQcMZcjdt/3dxMaroFEIIFZy2+uMhfGT487Mp5gJY3ADQJPqGIGcKLmRim
         KX/su4GH6ooPRiGNgZFx0N124l5u4i37K26LjUL4XUmtIH5rmiuGEAOn+kwciQXw34L+
         Vh6YslpuQY/utvuJjoEUjdQb5el4Sb5vLhuiUz9li9pBbapLxD4sqhFbhF6QckPqZb/Q
         8plA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750151712; x=1750756512;
        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=T/xbfcQE9fcmbG/Cayk7Rg/b8k8OXv0fYg2I6v//2HA=;
        b=mULmU7pAo8nQl5wg3CnMoUM/gt3Lf91cDR8pKsJiJvyKxBpfb5hw7672rVwXGsseoE
         AihE7Pcl7pzMy0USLq43BZ4zWls8Sk45CAhjrke6R7IzVCJRmEC6zjUeGmLyfFr1UvLH
         C3hicB6fYe5LFpFPKQQvfVhJdz56Db2FBG0D8IrAAOuC1WSE2FLSTsBAja19KOcZvklJ
         lG8dhjHiweY6Cwe4rApcyiCyqUoZkucH3icuIROIJht39nZbHigAvSk02rJIm8M1S9vW
         0ssK8AcY/gnS3az7F0QjPRod7ab/R+gq2Sb3PkCovdrq7T1yiZmmfG1QGPcsfe2fcTE8
         MO7Q==
X-Forwarded-Encrypted: i=1; AJvYcCWqVl61LMxoosUyHCkW5JgiAcAaEa7qbsURGhpyvd8hC0G9r4keFC2qv5E317UsqtkoMUwhC6MTiJM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyIlslrRVvPfeZac4s7RsIZTIQ8DaJmBcWIXsXc5+nJFbhw2i6H
	UF4iSlSyPs8dU1exzOxJEgFpBqFdEP7fwrM4uePMc1a6vQ/1JCwDBFlbaaOEtGa2tQ==
X-Gm-Gg: ASbGncvoQ6JT/yUcQ69soc9/Pea+eKDQlMIBm4bYZ940FN9njx4lXh2ffLUZhJHPhpN
	Bb9ObBokt6/ozl9KED0yw1jvagH+5B3ISDO3SLGsfBt7ydJB38UWEu0toFRA0/F9/UXWJgXLPhW
	OmYVtVZGVEt+whqqwQ6vKPdcQF09DlZTLmwP00SPokikW7aWvEUQxsZYIhnwKP6YUrAJeZPXRfK
	HDn3cr8vFK7ySHzi4Xth6FRvcSpA+fp6eYI5YdbfBZtXJ7diWHGuwl9OEI+ZcnLp9Grk2Sqg0BH
	37TII7buDe3x/4HojIR3xSKZFoncIxEsmAvP7iJIG7TCXMx5f6hRmzxG4otWVQJBaQYuUW08zOv
	HiKCsvkOmo9w1Y9GQHvnVwwIzmiUjFSxkBPf1cOdSbLMKlCQ=
X-Google-Smtp-Source: AGHT+IER8oZL0YHmFcci1GTJOHBizxCQwD8trDSSa86CuTURBEX67btE1rH3o6/64EPcxqfzoliCvg==
X-Received: by 2002:a05:6000:18ae:b0:3a4:d939:62f8 with SMTP id ffacd0b85a97d-3a5723a3f05mr8546333f8f.32.1750151711758;
        Tue, 17 Jun 2025 02:15:11 -0700 (PDT)
Message-ID: 
Date: Tue, 17 Jun 2025 11:15:01 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v8] xen/domain: rewrite emulation_flags_ok()
To: Nicola Vetrini 
Cc: dmkhn@proton.me, roger.pau@citrix.com, andrew.cooper3@citrix.com,
 anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com,
 sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com,
 xen-devel@lists.xenproject.org
References: <20250617011519.55386-1-dmukhin@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: 7bit

On 17.06.2025 08:53, Nicola Vetrini wrote:
> On 2025-06-17 08:19, Jan Beulich wrote:
>> On 17.06.2025 03:15, dmkhn@proton.me wrote:
>>> --- a/xen/arch/x86/domain.c
>>> +++ b/xen/arch/x86/domain.c
>>> @@ -743,32 +743,75 @@ int arch_sanitise_domain_config(struct 
>>> xen_domctl_createdomain *config)
>>>      return 0;
>>>  }
>>>
>>> +/*
>>> + * Verify that the domain's emulation flags resolve to a supported 
>>> configuration.
>>> + *
>>> + * This ensures we only allow a known, safe subset of emulation 
>>> combinations
>>> + * (for both functionality and security). Arbitrary mixes are likely 
>>> to cause
>>> + * errors (e.g. null pointer dereferences).
>>> + *
>>> + * NB: use the internal X86_EMU_XXX symbols, not the public 
>>> XEN_X86_EMU_XXX
>>> + * symbols, to take build-time config options (e.g. CONFIG_HVM) into 
>>> account
>>> + * for short-circuited emulations.
>>> + */
>>>  static bool emulation_flags_ok(const struct domain *d, uint32_t 
>>> emflags)
>>>  {
>>> +    enum domain_capability {
>>> +        CAP_PV          = BIT(0, U),
>>> +        CAP_HVM         = BIT(1, U),
>>> +        CAP_HWDOM       = BIT(2, U),
>>> +        CAP_DOMU        = BIT(3, U),
>>> +    };
>>> +    static const struct {
>>> +        enum domain_capability caps;
>>> +        uint32_t min;
>>> +        uint32_t opt;
>>> +    } configs[] = {
>>> +#ifdef CONFIG_PV
>>> +        /* PV dom0 and domU */
>>> +        {
>>> +            .caps   = CAP_PV | CAP_HWDOM | CAP_DOMU,
>>
>> Just to double check - are we sure Misra / Eclair will like this 
>> (ab)use
>> of an enum?
> 
> Likely not, but x86_64 is build with CONFIG_PV=n

CONFIG_HVM code further down in the patch is pretty similar.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 09:21:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 09:21:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018006.1394915 (Exim 4.92)
	(envelope-from )
	id 1uRSVB-0002TB-AL; Tue, 17 Jun 2025 09:21:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018006.1394915; Tue, 17 Jun 2025 09: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 1uRSVB-0002T4-7W; Tue, 17 Jun 2025 09:21:09 +0000
Received: by outflank-mailman (input) for mailman id 1018006;
 Tue, 17 Jun 2025 09:21: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 1uRSVA-0002Sy-2T
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 09:21:08 +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 66300aeb-4b5c-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 11:21:07 +0200 (CEST)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3a4ef2c2ef3so4510971f8f.2
 for ; Tue, 17 Jun 2025 02:21:07 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-236934a9be9sm8393765ad.47.2025.06.17.02.21.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Jun 2025 02:21:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 66300aeb-4b5c-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750152066; x=1750756866; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=LiFy+lU0j8w4MeGQcckXznrKwlEJssO7K8m0olMxEPc=;
        b=UJSSMd6tyxwspjw01RYdUwYbCgTaLTwRq246+iL0I3/iVSKKfql+A/QTwQNm5OZ1w2
         CNH3dNUj2MD2rXI4jzGE306ThJwyJRk8qY94YwV0GL+5PoxNrZDKffmxaj45hNgFufV3
         MLI8zKDfyBkRZQ77vnWvOTloH1WKFn56VkGCyI4zpqT6VZrF8SjAPFkratA/LigC/61g
         nZFBGdQ+B+Mb6fQqXZPNM9/cDXQqwSnIZOEEJ+QQjGlJNcd3UdU3RrTXTb0nxc3U8w0W
         4gLxbyGVC8ps/BeEzzgWNjij5N6+7RgjoQIR6PLq9a9PZpGen08YflWDBapmxbWJT28g
         8vMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750152066; x=1750756866;
        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=LiFy+lU0j8w4MeGQcckXznrKwlEJssO7K8m0olMxEPc=;
        b=e+WkTne5qtI/7xfxPUJUiTbsCBsijInxgIrUIfTA0T9Eis9F/IJG3dF/7cXoDXMN6t
         fg/tzSwYVT4/5j+X1iMtSjRevlEqpJ7UGrB75QhDTioghBXldIz8XVNrkreYKJh2hROt
         oNCTLQLm7mAg+zwitVFGpE4Ab7SpN9cMOPflw4LlxCtalaQfWfa9X6c+38JLYnYGnDxS
         UA3PQxLgavqtdAvfvUCTcHdAuAs+SKsPEEFXhkmcGoRh1VX8A7OQ0RXi0PbVnlBccyAZ
         gxOucoGtHLpn8y1ZGgjJl8X9lRy39x+bny+s/kiTUBqz4M57IcV+osdN/XAtuQ0eQCYw
         pdQQ==
X-Forwarded-Encrypted: i=1; AJvYcCW8nWwDZsdVn7tZnZW016j9Ll4uvuSQMF30KKu6WHm/9Ls1C5nNI/ltJVXEccSWeVVakASs6bvljOs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxueGzkJYCz40/klSVWmvItk8tsVeakhHkQxGQrvJIlUCRENFqj
	gH0geAo9d/vCEql4phXyhwLFOJP7WT7Oq2GJ+Xr5oaCEKiNQQ/00f3+a4kju+ebDig==
X-Gm-Gg: ASbGncvLlr+97ccV8bAyvZIfw8yTSiJmXcV9vvi5P6oO44uOC4fn5C3o3Aas13HBqLb
	ZViMP2x40DcJENIQBOTFlY/xNTyez4DH/2x7TrBOqW2jCTEsyYxP4QBffF2XMgQD2eU/6Grl8kX
	cRQZLw3qRjXfZpLi+nGPAgiYYUWmQtimLhzU/EGQWuedcj0wNw4O3fv683COcJffXN16iixYWo2
	0E0wcxjZvMdn4wB3VbcszF6712OTfI/vcCjXIkJRlYjJfrL+KYM9zoohzDL9tjDjmjH0BYY9dyO
	tulqBRjc6/sompUTYUbF8S25KXokoMcS/OZNZfy+7bp2zKZF0TwbZ6N+sNat30t5t9xBO/BwfZg
	g0KHHydXrNTYSkGOBcmW6kTJQDSzQ4X3CwaUD53jdJkCCygEH+TqEm+D/SQ==
X-Google-Smtp-Source: AGHT+IFaHQzj0MirwfyIOAWq7Ss4/ea1aKyXAKi26Qt14UnhsL+9+crgrWLtvhoan8fJDi9Zk0btEg==
X-Received: by 2002:a05:6000:2310:b0:3a4:f7ae:77ca with SMTP id ffacd0b85a97d-3a57236773fmr10771831f8f.3.1750152066480;
        Tue, 17 Jun 2025 02:21:06 -0700 (PDT)
Message-ID: <4068d1cd-6328-445e-a2f2-e5384f3a9fa5@suse.com>
Date: Tue, 17 Jun 2025 11:20:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 06/18] xen/x86: introduce "cpufreq=amd-cppc" xen
 cmdline
To: "Penny, Zheng" 
Cc: "Huang, Ray" ,
 Andrew Cooper ,
 Anthony PERARD ,
 "Orzel, Michal" , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 "xen-devel@lists.xenproject.org" 
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-7-Penny.Zheng@amd.com>
 <3edeeff2-5728-46cc-9436-01e5e3cf2bd3@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.06.2025 09:15, Penny, Zheng wrote:
> [Public]
> 
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Thursday, June 12, 2025 6:42 PM
>> To: Penny, Zheng 
>> Cc: Huang, Ray ; Andrew Cooper
>> ; Anthony PERARD ;
>> Orzel, Michal ; Julien Grall ; Roger Pau
>> Monné ; Stefano Stabellini ; xen-
>> devel@lists.xenproject.org
>> Subject: Re: [PATCH v5 06/18] xen/x86: introduce "cpufreq=amd-cppc" xen
>> cmdline
>>
>> On 27.05.2025 10:48, Penny Zheng wrote:
>>> Users need to set "cpufreq=amd-cppc" in xen cmdline to enable amd-cppc
>>> 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-cppc", a new amd-cppc driver shall be
>>> registered and used. All hooks for amd-cppc driver are transiently
>>> missing and will be implemented in the ongoing commits.
>>>
>>> New xen-pm internal flag XEN_PROCESSOR_PM_CPPC is introduced, to be
>>> differentiated with legacy XEN_PROCESSOR_PM_PX. We define
>>> XEN_PROCESSOR_PM_CPPC 0x100, as it is the next value to use after
>>> 8-bits wide public xen-pm options. All xen-pm flag checking involving
>>> XEN_PROCESSOR_PM_PX shall also be updated to consider
>> XEN_PROCESSOR_PM_CPPC now.
>>>
>>> Xen is not expected to support both or mixed mode (CPPC & legacy PSS,
>>> _PCT,
>>> _PPC) operations, so only one cpufreq driver gets registerd, either
>>> amd-cppc or legacy P-states driver, which is reflected and asserted by
>>> the incompatible flags XEN_PROCESSOR_PM_PX and
>> XEN_PROCESSOR_PM_CPPC.
>>>
>>> Signed-off-by: Penny Zheng 
>>> ---
>>> v1 -> v2:
>>> - Obey to alphabetic sorting and also strict it with CONFIG_AMD
>>> - Remove unnecessary empty comment line
>>> - Use __initconst_cf_clobber for pre-filled structure cpufreq_driver
>>> - Make new switch-case code apply to Hygon CPUs too
>>> - Change ENOSYS with EOPNOTSUPP
>>> - Blanks around binary operator
>>> - Change all amd_/-pstate defined values to amd_/-cppc
>>> ---
>>> v2 -> v3
>>> - refactor too long lines
>>> - Make sure XEN_PROCESSOR_PM_PX and XEN_PROCESSOR_PM_CPPC
>> incompatible
>>> flags after cpufreq register registrantion
>>> ---
>>> v3 -> v4:
>>> - introduce XEN_PROCESSOR_PM_CPPC in xen internal header
>>> - complement "Hygon" in log message
>>> - remove unnecessary if()
>>> - grow cpufreq_xen_opts[] array
>>> ---
>>> v4 -> v5:
>>> - remove XEN_PROCESSOR_PM_xxx flag sanitization from individual driver
>>> - prefer ! over "== 0" in purely boolean contexts
>>> - Blank line between non-fall-through case blocks
>>> - add build-time checking between internal and public
>>> XEN_PROCESSOR_PM_* values
>>> - define XEN_PROCESSOR_PM_CPPC with 0x100, as it is the next value to
>>> use after public interface, and public mask SIF_PM_MASK is 8 bits wide.
>>> - as Dom0 will send the CPPC/Px data whenever it could, the return
>>> value shall be 0 instead of -ENOSYS/EOPNOTSUP when platform doesn't require
>> these data.
>>> ---
>>>  docs/misc/xen-command-line.pandoc         |  7 ++-
>>>  xen/arch/x86/acpi/cpufreq/Makefile        |  1 +
>>>  xen/arch/x86/acpi/cpufreq/amd-cppc.c      | 68 +++++++++++++++++++++++
>>>  xen/arch/x86/acpi/cpufreq/cpufreq.c       | 63 ++++++++++++++++++++-
>>>  xen/arch/x86/platform_hypercall.c         | 13 ++++-
>>>  xen/drivers/acpi/pmstat.c                 |  3 +-
>>>  xen/drivers/cpufreq/cpufreq.c             | 18 +++++-
>>>  xen/include/acpi/cpufreq/cpufreq.h        |  6 +-
>>>  xen/include/acpi/cpufreq/processor_perf.h |  3 +
>>>  xen/include/public/sysctl.h               |  1 +
>>>  10 files changed, 175 insertions(+), 8 deletions(-)  create mode
>>> 100644 xen/arch/x86/acpi/cpufreq/amd-cppc.c
>>
>>> @@ -157,7 +162,63 @@ static int __init cf_check
>>> cpufreq_driver_init(void)
>>>
>>>          case X86_VENDOR_AMD:
>>>          case X86_VENDOR_HYGON:
>>> -            ret = IS_ENABLED(CONFIG_AMD) ? powernow_register_driver() : -
>> ENODEV;
>>> +            unsigned int i;
>>> +
>>> +            if ( !IS_ENABLED(CONFIG_AMD) )
>>> +            {
>>> +                ret = -ENODEV;
>>> +                break;
>>> +            }
>>> +            ret = -ENOENT;
>>> +
>>> +            for ( i = 0; i < cpufreq_xen_cnt; i++ )
>>> +            {
>>> +                switch ( cpufreq_xen_opts[i] )
>>> +                {
>>> +                case CPUFREQ_xen:
>>> +                    ret = powernow_register_driver();
>>> +                    break;
>>> +
>>> +                case CPUFREQ_amd_cppc:
>>> +                    ret = amd_cppc_register_driver();
>>> +                    break;
>>> +
>>> +                case CPUFREQ_none:
>>> +                    ret = 0;
>>> +                    break;
>>> +
>>> +                default:
>>> +                    printk(XENLOG_WARNING
>>> +                           "Unsupported cpufreq driver for vendor AMD or Hygon\n");
>>> +                    break;
>>> +                }
>>> +
>>> +                if ( ret != -ENODEV )
>>> +                    break;
>>
>> This, I think, needs some commenting. It's not quite clear why we shouldn't try the
>> next option if registration failed with other than -ENODEV.
> 
> I followed the original logic.

Which may easily itself be partly bogus.

> Now, I'm trying to understand the reason. I read the related code, there are two code path erroring out other than -ENODEV
> In cpufreq_register_driver(), either the driver itself is broken, like missing mandatory hooks, etc, yet in which case, IMO we shall try the fallback option,
> or repeated registration, TBH, which seems unlikely to me. cpufreq_driver_init() is a presmp call, so repeated registration doesn't come from racing.
> Then if we successfully registered a driver, we will immediately exit the loop. How come we will register twice?
> Or am I missing something for this error path:
> ```
>         if ( cpufreq_driver.init )
>                 return -EBUSY;
> ```

Imo this error path is there "just in case".

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 09:26:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 09:26:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018017.1394924 (Exim 4.92)
	(envelope-from )
	id 1uRSaX-00037o-TN; Tue, 17 Jun 2025 09:26:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018017.1394924; Tue, 17 Jun 2025 09:26: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 1uRSaX-00037h-Qm; Tue, 17 Jun 2025 09:26:41 +0000
Received: by outflank-mailman (input) for mailman id 1018017;
 Tue, 17 Jun 2025 09:26: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 1uRSaW-00037b-NS
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 09:26:40 +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 2b6a3a91-4b5d-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 11:26:38 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3a5257748e1so3899935f8f.2
 for ; Tue, 17 Jun 2025 02:26:38 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2366e7c0560sm55830945ad.76.2025.06.17.02.26.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Jun 2025 02:26:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2b6a3a91-4b5d-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750152398; x=1750757198; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=NQBXs3S1f+lE4mMsp0/pWt6ljKkaFfV3Jq0c27jtglQ=;
        b=U7NjN/84YkRi2K19pV1BW6ljUsowMCEw3u1/gouOb9CQUZQzmZwrrc4kU8WKFDgUOV
         880Ui3EW63YmjuIVZ+pWMh2oMoVKJg3/ddCSahC7eGJ0NwXaGtklnXM0ysIZdctihV9A
         Xd2vgoXxDD4uAOuFI+mkymIxWN0aVqmFUA3BS42XM7Ic9cJ1fI6FegU+klNwqlgNHR6N
         B03bApuySxu+4opPv2n9ZvP6x5eEP9D3irxPxOHkukd0lF0kR2SJh4F8MHwYEsx85iY4
         bknf78i80Cf7+keFQCIj6Bel8jUVFmmZD3/+gxMyDy4uhX7Hci6p/vK0hdXE9C4nDL8C
         +i7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750152398; x=1750757198;
        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=NQBXs3S1f+lE4mMsp0/pWt6ljKkaFfV3Jq0c27jtglQ=;
        b=U7zwrTptUDUXfHH+5VbW+FrS+OQMoGCzWS0DSSwbLHA9iafvvQW1VWxs4E92H9J1V9
         l1v/asxYKf5mPRw4Hw0hVK3jERtgD4hQBYy/m8f2NbwNM7RLjUIUUrpJZEOBfgIP8Dwb
         076CZ0X4Jcn26eGz4RC9UMGU1GD9NNRG8bslnm9WNOUV4D1LSqcis6UTTBXFeNNIr8vc
         aJG7R/ZIbO8DNj0GfXnFrpkSCnaxSZe4uOfEVk9jLe3ZU9pfg2ylc+7ko3kXRuJ64a4m
         i769A5Xpsa1z1/pgiZMXFcjCDvIuL2Kj3069+FXZkjwqeUGwgGCVRL+WXKe/6aJhihqN
         jx/A==
X-Forwarded-Encrypted: i=1; AJvYcCVZ8xs+ThMTj4cJGbpnWW54EP69WCx+skt6UwbH+zTPz992wi8KUFGOc2iKSS36D8O229wbeL+kP/w=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywki4+SH6ty3aN7p3WfubiG6FA9bJWmRF0NbmGGoy8cEbCiAjkn
	RicjN9F0DOBxpRgaPIZbnIHBZGuYpAcYc7O0RbzBPivA9gzHzayyCg93XwgyeOevEg==
X-Gm-Gg: ASbGncvM6aofo5OsSHMjfaVJtGa4m9lBTrvJQnqBhaqFkebSuTAB37OmuzO4ENlqdhk
	0Pm3eiSFb8UejxB0UJnnO+BHFRg/miYa7buZEUuAirbR+Y7GGfk2wPKNaxbqMZu6Xe5IrpROm8k
	4mgd5JmcS9eF101LTfR0LhJy3ZSUpRyq7/UGqs1OgHklqf+oKuN2G0OKGYeQEeyhbh0dB7hNMno
	asfqIVagx42q5gtStSLfvvh3OKJ2w0fmRPIOQZb8TZjfV5ZutHfO0JRj4HfyleQaREP8n//ZENn
	yEDy1+j8d2/u/f+MdvOXcllTsNExYrD38E/mPNoSlDJbaipup1YnvGi4Fd5P4FVv3rXivzQLBlM
	Rwjlk00TzlhmBfXVQrr2Vh/ZQt+vThySgKZWJz0ohEY0iC84=
X-Google-Smtp-Source: AGHT+IEpU4zreM2vo0JIBYlGSNuiZizgwBcR2dgu8ko4jNFR6cIsS/uTnHqzDN7PYOkkC2+M+m/wrA==
X-Received: by 2002:a05:6000:4021:b0:3a4:f5f6:b4ab with SMTP id ffacd0b85a97d-3a5723a2e2bmr9641434f8f.30.1750152397611;
        Tue, 17 Jun 2025 02:26:37 -0700 (PDT)
Message-ID: 
Date: Tue, 17 Jun 2025 11:26:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] console: Do not duplicate early printk messages on
 conring flush
To: Michal Orzel 
Cc: Andrew Cooper ,
 Anthony PERARD , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250617071940.10445-1-michal.orzel@amd.com>
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20250617071940.10445-1-michal.orzel@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17.06.2025 09:19, Michal Orzel wrote:
> @@ -1084,8 +1085,15 @@ void __init console_init_preirq(void)
>      serial_set_rx_handler(sercon_handle, serial_rx);
>      pv_console_set_rx_handler(serial_rx);
>  
> -    /* NB: send conring contents to all enabled physical consoles, if any */
> -    conring_flush();
> +    /*
> +     * NB: send conring contents to all enabled physical consoles, if any.
> +     * Skip serial if CONFIG_EARLY_PRINTK is enabled, which means the early
> +     * messages have already been sent to serial.
> +     */
> +    if ( IS_ENABLED(CONFIG_EARLY_PRINTK) )
> +        flags &= ~CONSOLE_SERIAL;

Does EARLY_PRINTK=y alone guarantee everything was output? That is, is there
no chance that early-console init may have failed? (Sorry, I don't know much
about early-console in Xen, as that's Arm-only.)

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 09:48:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 09:48:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018033.1394935 (Exim 4.92)
	(envelope-from )
	id 1uRSvY-0005vZ-JV; Tue, 17 Jun 2025 09:48:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018033.1394935; Tue, 17 Jun 2025 09:48: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 1uRSvY-0005vS-Go; Tue, 17 Jun 2025 09:48:24 +0000
Received: by outflank-mailman (input) for mailman id 1018033;
 Tue, 17 Jun 2025 09:48: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 1uRSvX-0005v6-QT
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 09:48:23 +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 344acc4d-4b60-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 11:48:21 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a54690d369so5593868f8f.3
 for ; Tue, 17 Jun 2025 02:48:21 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-748900b0683sm8651549b3a.130.2025.06.17.02.48.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Jun 2025 02:48:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 344acc4d-4b60-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750153701; x=1750758501; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ikxvVEdP9tQdIuc4q/UjfxjrPXG9GPPrznF6OIrLP/E=;
        b=eQ+M4dsXEw3HSnNpFsuWM4gxprZvCH1ViLswYKjkimWWpG+s42ONBa70tcJQGygWU7
         gSTEo62tdy/z/au4Ka3QZa6Zoffs/iWJLPj/9VffodTRQH5yiai0bFYDsj3ajTmCUkqL
         yVYysoJ9AyPzdl1hpibGIyQsLtHdyOaQO6CpcVjq9rwUbZwLY5ZqDoIM9MHbnFRBlstx
         QKliAZobG9tRt0uwsXuGrBC9vpvp12YDYcR3bvl1rrlXKhkwPjK1nmBv5BUP+VMDq2/y
         BBhe0iRBoCGwo1UCFartdP9uqrxznTFhMqEBJCv71LSVYJTTnF0ALkn7CYEaarXjeDUT
         n8yQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750153701; x=1750758501;
        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=ikxvVEdP9tQdIuc4q/UjfxjrPXG9GPPrznF6OIrLP/E=;
        b=lgaY3ie2m39kB3qiFE+m+8zlnmBBRmNEkYSda4xsmFA/NmM9oiOfDoLcNIoVjBh5p8
         RMBf8zoNpxZMcPoq8sxcZN7SCpOA2BIv+W7724nNk2Nnxj2ZubXNNXQsByryu3VupXpd
         xHzkaB8EZH5k4XOS/kSoioWCjTA5h+tO92aZkD5Ey3M69KKDSvhASo4tHbbwmm/6+th/
         7/ZlX2Uk5WdHSzrdGK7mvpKJDIeeAqFMm9Q1Kceyq8O+pwx+awn4mNzuRgRYCrukq+yr
         9V0cBdA9U2quPSXJJrygLg+T0o+DebwNpliqUS9qvFrdnM+EZDE+GzXKjZNPcrQVfdan
         vseg==
X-Forwarded-Encrypted: i=1; AJvYcCU+H5NP4Hw2a5P5ke6aryR/fXO30EOji1ifKSTYIJpzL0uBvA4ZlkupsA5FK/fJk1NmKWcQQqHyhcM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxWyZPZ9WzYTCeGxxYdmgpQG3w0a4uURiVgKNxZRdGw2uVIjD+X
	WBcwalHe8ozqdVjq0Nk1pVBXarcOn8HCUKgZAe6HJj4FyfMpydZgTojrH4Aknq0M9A==
X-Gm-Gg: ASbGncuFhjLz8c2EzA3iWOq0Ynm2crxhV6iu5vBqCsYX7MDk/KAeqkkiXmmGYMj4Xm4
	LOMG8TLPXIkEecJc7NxNig1RtxTUmrCoIjucOEGkqRxaSndH1K0ZPIIbqH3qis12B0UZ8uIjqvi
	w2BtzXUOsTTdclQ1dLcTofMIc2TcRkAghPiTRUFOiW0IRWh6mO/zxvPtH+aYMBOKe+Aaw1yU1Ec
	gQod999YK8uMvLOdCg3oywhdTPfTGpXgoR/4e2syRk8rSc0bJJEFB3ypS3YKroDDHr78T7+ZYB4
	LBXmqqclwcPjSqOb+lZ4W4oMfqn+NHIp9L53QKBgu3zAHnPHVnDZRCrVL7f2MIEUktLEMDV47PI
	kN5qlHtUaLnZFSaNVitGQiXOAtpOVu+cof2GDnU1V1GVRigk=
X-Google-Smtp-Source: AGHT+IHBaiZ7pnGrNmDhm4DHvqZaWV3zskMW5sJ9LSmLPX/DH9KNPNKoUus2TPmUySqpGc3NIRH0xA==
X-Received: by 2002:a05:6000:2c13:b0:3a4:ef36:1f4d with SMTP id ffacd0b85a97d-3a5723a4c09mr10845553f8f.38.1750153700916;
        Tue, 17 Jun 2025 02:48:20 -0700 (PDT)
Message-ID: <1ac74dd3-e0c5-43e5-9eed-c1a2cc17d068@suse.com>
Date: Tue, 17 Jun 2025 11:48:10 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen/console: introduce domain_console struct
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org,
 teddy.astie@vates.tech, dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250617012713.57074-1-dmukhin@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: <20250617012713.57074-1-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17.06.2025 03:27, dmkhn@proton.me wrote:
> From: Denis Mukhin 
> 
> Introduce domain_console for grouping data structures used for integrating
> domain's diagnostic console with Xen's console driver.
> 
> Group all pbuf-related data structures under domain_console. Rename the moved
> fields to plain .buf, .idx and .lock names, since all uses of the fields are
> touched.
> 
> Bump the domain console buffer size to the closest power of 2 (256) and
> rename the symbol to DOMAIN_CONSOLE_BUF_SIZE.
> 
> Move d->console->buf management under CONFIG_VERBOSE_DEBUG when the
> HYPERCALL_console_io handler is enabled.

This, if at all, needs to be a separate change (with its own justification).
I for one don't think VERBOSE_DEBUG is intended to control any kind of guest
output.

> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -559,7 +559,6 @@ void hvm_do_resume(struct vcpu *v)
>  static int cf_check hvm_print_line(
>      int dir, unsigned int port, unsigned int bytes, uint32_t *val)
>  {
> -    struct domain *cd = current->domain;
>      char c = *val;
>  
>      ASSERT(bytes == 1 && port == XEN_HVM_DEBUGCONS_IOPORT);
> @@ -570,17 +569,24 @@ static int cf_check hvm_print_line(
>  
>      if ( !is_console_printable(c) )
>          return X86EMUL_OKAY;

After this "return" ...

> -
> -    spin_lock(&cd->pbuf_lock);
> -    if ( c != '\n' )
> -        cd->pbuf[cd->pbuf_idx++] = c;
> -    if ( (cd->pbuf_idx == (DOMAIN_PBUF_SIZE - 1)) || (c == '\n') )
> +#ifdef CONFIG_VERBOSE_DEBUG
> +    else

... there's no point to have "else" here.

>      {
> -        cd->pbuf[cd->pbuf_idx] = '\0';
> -        guest_printk(cd, XENLOG_G_DEBUG "%s\n", cd->pbuf);
> -        cd->pbuf_idx = 0;
> +        struct domain *cd = current->domain;

We normally name such a variable d. It also looks as if this could be pointer-
to-const.

> +        struct domain_console *cons = cd->console;
> +
> +        spin_lock(&cons->lock);
> +        if ( c != '\n' )
> +            cons->buf[cons->idx++] = c;
> +        if ( (cons->idx == (DOMAIN_CONSOLE_BUF_SIZE - 1)) || (c == '\n') )
> +        {
> +            cons->buf[cons->idx] = '\0';
> +            guest_printk(cd, XENLOG_G_DEBUG "%s\n", cons->buf);
> +            cons->idx = 0;
> +        }
> +        spin_unlock(&cons->lock);
>      }
> -    spin_unlock(&cd->pbuf_lock);
> +#endif

None of the re-indentation is really warranted here (and will likely go away
anyway once the #ifdef is dropped).

> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -669,7 +669,7 @@ static void _domain_destroy(struct domain *d)
>      BUG_ON(!d->is_dying);
>      BUG_ON(atomic_read(&d->refcnt) != DOMAIN_DESTROYED);
>  
> -    xfree(d->pbuf);
> +    xfree(d->console);
>  
>      argo_destroy(d);
>  
> @@ -800,6 +800,11 @@ struct domain *domain_create(domid_t domid,
>      if ( (d = alloc_domain_struct()) == NULL )
>          return ERR_PTR(-ENOMEM);
>  
> +    err = -ENOMEM;
> +    d->console = xvzalloc(typeof(*d->console));
> +    if ( !d->console )
> +        goto fail;

This definitely need to move down some, at least ...

>      /* Sort out our idea of is_system_domain(). */
>      d->domain_id = domid;
>      d->unique_id = get_unique_id();

... past here. There absolutely must not be struct domain instances be
passed around (see e.g. the call to sched_destroy_domain()) without the
domain ID set. It's hard to see ...

> @@ -862,7 +867,9 @@ struct domain *domain_create(domid_t domid,
>      spin_lock_init(&d->shutdown_lock);
>      d->shutdown_code = SHUTDOWN_CODE_INVALID;
>  
> -    spin_lock_init(&d->pbuf_lock);
> +#ifdef CONFIG_VERBOSE_DEBUG
> +    spin_lock_init(&d->console->lock);
> +#endif

.. why here or ...

> @@ -955,11 +962,6 @@ struct domain *domain_create(domid_t domid,
>      if ( (err = argo_init(d)) != 0 )
>          goto fail;
>  
> -    err = -ENOMEM;
> -    d->pbuf = xzalloc_array(char, DOMAIN_PBUF_SIZE);
> -    if ( !d->pbuf )
> -        goto fail;

... even here wouldn't be early enough anyway.

And btw - where did this buffer allocation move? I don't see anywhere
that d->console->buf would now be initialized. (However, see below.)

> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -371,6 +371,22 @@ struct evtchn_port_ops;
>  
>  #define MAX_NR_IOREQ_SERVERS 8
>  
> +/* Arbitrary value; must be a multiple of the cacheline size. */
> +#define DOMAIN_CONSOLE_BUF_SIZE 256

Where does the relationship with cache line size come from? What if
Xen was to run on hardware (whichever arch) with 512-byte cache lines?

> +/* Domain console settings. */
> +struct domain_console {
> +#ifdef CONFIG_VERBOSE_DEBUG
> +    /* hvm_print_line() and guest_console_write() logging. */
> +    char *buf;

To avoid the need to do yet another separate allocation, how about ...

> +    unsigned int idx;
> +    spinlock_t lock;
> +#endif /* CONFIG_VERBOSE_DEBUG */
> +
> +    /* Permission to take ownership of the physical console input. */
> +    bool input_allowed;

    char buf[DOMAIN_CONSOLE_BUF_SIZE];

Ultimately this would allow the buffer size to be e.g. command line
controlled (if so desired), by then simply converting to a flexible
array member.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 09:53:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 09:53:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018040.1394945 (Exim 4.92)
	(envelope-from )
	id 1uRT06-0007Xg-3s; Tue, 17 Jun 2025 09:53:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018040.1394945; Tue, 17 Jun 2025 09:53: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 1uRT06-0007XZ-0q; Tue, 17 Jun 2025 09:53:06 +0000
Received: by outflank-mailman (input) for mailman id 1018040;
 Tue, 17 Jun 2025 09:53: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 1uRT04-0007XT-Bz
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 09:53:04 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20631.outbound.protection.outlook.com
 [2a01:111:f403:2413::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id daab473e-4b60-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 11:53:01 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by SN7PR12MB6669.namprd12.prod.outlook.com (2603:10b6:806:26f::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Tue, 17 Jun
 2025 09:52:58 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8835.027; Tue, 17 Jun 2025
 09:52: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: daab473e-4b60-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=K5CgG31FhWVc7l1L4AkbeCtxKdZe/23mqyTtOLjH5yMGKqsrJOdjAbkVZI/8z7ovVCiq6iHplk9WroVDLcqGAeVoBxpnw6WhJPpHaJtcGbE42aLH0Goo+sUMTlgkSgaLu5hzCXXOu2WPNaAS4nvz5sBe4avn1EfC2+9HX2FXZqhutxxKOveYHVSeTVNItXzWnTogT/xVTq8cmE+FfeLnc1NRkttLkD2cZO2mZfxjHxjWwHKgEKNV+U50oggTiydTBqTGYHo3DkZyb1rzF3vq/oFDjcUcGSL+xXcZ1/chT0w3fEoBCKpk3j9CmTe4OYACcl28loInqRdAPFoK3j+SKw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=wX+USrUT6qkhyvuW01KYiizlOIB5ks+AR8MFu+veyhY=;
 b=SVSC4GOsRkq7PBn7b8LcNqOrFDLDgaSqbAYalODbxtdjDSYr7TpHuBgR8mm6qM/U2VUmN/W9Vucip1c33kH82yoa+QuflM5HqF/gIIxdXeV+ZLCcGHmi2ObBQHxDKaNxM+id6CE/gVl5KSfTdUTblRFawQI85Z+4EW4FCOC2balz9ahJxrOONzR5l6rUNdcT/TVc+BelWdzrkfT8XINgpZq7lDw1Ih1n672CCP/hMDC4hmVcRT4RF/9Qz2czLcuPnlM0CiCZuJ0HHM+hHdz08xcQ8C2EmKVKQZWPlsVEWFftfmSY3bzcTVai4u83vms2WLUx4PtFmnntYhgHKXNnUQ==
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=wX+USrUT6qkhyvuW01KYiizlOIB5ks+AR8MFu+veyhY=;
 b=G6iUHyHe0DgpkKm2WFnaZWQCx1mCG0JMP/geMDdG8l0RCMCIjBg1i5mDzJx9jpoFQ8sVPHg8UhkZUiXz3r5/XZSIY9LmfL3yItdz5s/yx7fUbRwPic4hOlBDY5IYNEc2kV8QHNcPi/cuF1Li6r52XFsKe0udDylLBJ3wP7WZ3rs=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <903dbadc-e0e7-480c-9144-3446f7079d63@amd.com>
Date: Tue, 17 Jun 2025 11:52:47 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] console: Do not duplicate early printk messages on
 conring flush
To: Jan Beulich 
Cc: Andrew Cooper ,
 Anthony PERARD , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250617071940.10445-1-michal.orzel@amd.com>
 
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: JNAP275CA0033.ZAFP275.PROD.OUTLOOK.COM (2603:1086:0:4d::14)
 To BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|SN7PR12MB6669:EE_
X-MS-Office365-Filtering-Correlation-Id: 385d7282-3aa7-4a03-9e09-08ddad84bd20
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?bkNVYXh1MDc4MzhzV1ZYT1o0ZFl5MHdJSkFSQklTbm9abTA2elNpV0JLdnpu?=
 =?utf-8?B?dENIOE1zZFZhUFRaOHU0cnZDVUFVVlVXaVRodlRRRldxNG5SUjB3ZktaalR6?=
 =?utf-8?B?TjVmS3ErN0dETWV2VENKdXVPQ1BjUG1GZjJ4M1ZSaHY5dDdoV29EK3VTaGNy?=
 =?utf-8?B?Nis0RmNtdm1ldTdMZTBsTU1xWjFZbms3M01yTE1mL01LMWVTbFIvRkRBeVNW?=
 =?utf-8?B?TDR5M0xTOTkzbDJpMldqYS9HTEJSVHBpNk9aYUZIb0wyMWZIcGQ3cGtpSldR?=
 =?utf-8?B?Z0x3NytsVFV2QkFpeVIwNGtmVmNPVjZzZCtxTmlTSUZzamFrdTRXV2VRektC?=
 =?utf-8?B?VU85KzRyekpPRlo3TmV5Y0lXYmpoK2xxM3pTb2lDbThwWXl4cmowTlNQMGNj?=
 =?utf-8?B?bkl0VTF0ekEzWG9Sd1Z3cSthQ1V4L2xDcHNEbHNvdUpvVVkrRzluVzFsOFk0?=
 =?utf-8?B?RmU2ZFZHQlgwZkpvRW92Z0hQeTYrRFNidDVxU25OVitLVFlVMGdWZGF6MS9I?=
 =?utf-8?B?dm91bjM2dHQrOG1vT1lmeUordTNZNmpUMFI1ZCt1Q2ozd3R6UVBMNVB0RElV?=
 =?utf-8?B?M2w4ZFJiVFNVMHRYN0pDWUYyeTNwdC85cmwvK1RxR21WZkZaYi9YVEsrYll0?=
 =?utf-8?B?TjJrSGlxRVR5SkJxNjh6R291TndNbTd2K2lSSHdyWnM3b1dSSUkrY2hqdlJY?=
 =?utf-8?B?OC9HSmRjSHVZek8rcWlSU1hNY2dacDQvVkZRYkNIMkdmU2RCbXo0NkVZeUE4?=
 =?utf-8?B?ZXB0VHN4N2JrUlFGYXF4cUpnZFVIRzZvc0N4V1VQZzRkV01nWWcvZ25iWkpL?=
 =?utf-8?B?TDZ2UE9COW4xaWxQeWQrdHBONU95a0J5Y1U2U2VkUkdUdDZqeU4wd1hkRWVr?=
 =?utf-8?B?ZGNiMytHRXAwd3dEZjRYVGtVWHhodUpoVVhDbWJIUm1paDhpYUZIYkQ3NlI5?=
 =?utf-8?B?RGxoUW56M0oxK1Nob3UzMTNrU1hOVXkzYWdZZ3hFa2dhU3RTQ3ZmMDRzbVI5?=
 =?utf-8?B?YUU1N3Vzb2NhbUwyNXJYNFJSbnRKU0FBV1NCUUVobmlQTm56K21jdHlXZW0z?=
 =?utf-8?B?R2pTT29hTkV6eE5kdSs3SGQ4aW1qcDhFLzBnTk80UEpIbTVWZTZzKzNrd01r?=
 =?utf-8?B?UzRSTXZZMjRzbUx3L29iOHEvUEFLV3MrN0lHWGpqR2FxNkFOZTVZemNNdkp6?=
 =?utf-8?B?TlczVmZpTVk3RkdFYUxmRXVZbS9CY1ZGaEN4aCt2NGFucllRMkJPY2VOd3NE?=
 =?utf-8?B?SjVkTVA0cWgrL2c5KzN6WW1zVzh6SkR4RXp4emw1cXQvYm1MR05QM1lWcmlV?=
 =?utf-8?B?Nmx5OXkvY2gxNjk3VWNFd0ZEWmxlTmtUQ29Wa0M0ODczcGVuajRmUHQwWE4w?=
 =?utf-8?B?OXhESW9LVno1YzBMNmJZSjB0c1lwd3p0UjZzWWxxVjVObjBzL09kS0ZnU3RI?=
 =?utf-8?B?MVVQM3U1RldHZnNzTWh3aEh6Zk9HOUd1NENxRHFxSDlpdmxKaFpPTHYwT0FF?=
 =?utf-8?B?NFVRaW1teTQxaHg0M1EweTI2Wjd4TW43WFNuQ20vTDdTbkFPT0dHT0wxUkF4?=
 =?utf-8?B?YkJLRUNOY0NHdTBOVDVPRjZOV1B1bnBOUngyOGxFZlNrV0txRHBlSTlFZENn?=
 =?utf-8?B?bVdnbjJqOFhjNERSMVhEOThPYnd3SUIrTHJ2YVRVTUdhVzBYOFk3d2JjNU9M?=
 =?utf-8?B?eDFSMUdPV3BoSEFMZzJwUnNhM2REbnEwMUFpSWtQN055dU5FZ3NYLzZRb3Bm?=
 =?utf-8?B?ZHpnMHB2V3lhY0NLTHlWREEvNnNCYWgxbk8yOGRBZFZvVUUzcTlldGhET25J?=
 =?utf-8?B?dVV5MVlXZkVheUxTVC8rdHhLdnQxckV2d1NZWmM0OS9ONmc1Z1l6aittbmJ5?=
 =?utf-8?B?SGxqTjljUG1rUHJHdW55MG9WNUFsYWFwUWlkZzRJaDBYdU03b3NraS82MHF5?=
 =?utf-8?Q?Hbag0bsFkH8=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?UTlRWVRWdTkvQURURDhwR1hSTkhZMEx1R3ZYVFJRRnJpY0pBeSt5TVExbVRF?=
 =?utf-8?B?cForRVphV0t3REJxTXpaemNoS09pTTdmTXpvUnUwRUExaHlBdlNxWVhGRC9V?=
 =?utf-8?B?MkJTN0V5dHNSYUFCeVkxSG9hM0tITWRKVEV4RkRiQ2w4Wk1rR1FJQ285SkNu?=
 =?utf-8?B?RjJZQ1Yvd3QxemFjQmV4YlFsNXVJZmp1anpNd2FTSEJ1UWZKYkNwUW1NajJT?=
 =?utf-8?B?Q042bnpBdW8wd3dlZWhNWUFjUWRSYXdJdkltVjdER1ZZM2tVOWw1dVRsZEo4?=
 =?utf-8?B?VU9xbUZaM1dEMlcvSXpDZEhMeGJYaUtRTExlaVJBQVA4QWxJbG5DaGFKWjQr?=
 =?utf-8?B?aG8wdiswSnRLK3QzdUFRaVdXTkR3UkFEREdONFBYb0JGZEpHYmJCREFodlpl?=
 =?utf-8?B?Ry9wVjlrcG5zN1ZLRUh3R1NGcGd1M2RJaGFmYWhETkd3RFFYaUtEZnVVemo1?=
 =?utf-8?B?ODh2c3N2WmU1WUl2ajcySXplb2ZYUi9BVzBXNEZiUWxRNVBwMlRpUjVUaVVZ?=
 =?utf-8?B?eGNybmVrS2l4QnpKUlJRYURvUDBZSTNVM3psaU1qUU9FUmxYVjI4QWs1K1d5?=
 =?utf-8?B?TmVRTnYxTzFmbENLNzFIandseTNnWXJSbWVaNmpFaG8xSFpBTkZtblZEb1pj?=
 =?utf-8?B?OGozT1drRVlodTd0emk3amI4SDNoYU93Zk5Ram5Va1NpUkp2K3pLWE9TWVRk?=
 =?utf-8?B?ZThLOElOelhWS1kyRGpjeWZGcDhwMkhMOEQ5YmJJZ2RKdHlSenBWcnhieHdP?=
 =?utf-8?B?dlZ1NVVsQUVaQVp4d3owM2F2UWdZR3FDQi8rMVBiTGRaUHRtYlFTdm44RHdX?=
 =?utf-8?B?N3JjczVYbVhEZkR0d2g2SmZkZEU4cXM4UCt0Qk9pYUo4enlXWGF4SEw1Umhl?=
 =?utf-8?B?L29nSFI2UkxIV0dYTEJyL2gvZEZDY0hJTFdNMnMweEZubEtZNEdCaityc1dX?=
 =?utf-8?B?VE03YVR3c2psL21USXNWbkp4a1g3aGFrOE1TMWVuR3FqemV6RUgzVEx6dnZS?=
 =?utf-8?B?WVZJdzdzOGEvcnNjTTJHSDYyQ0tiYUtkRXNEaWl1WGp0MWhRbzAxMjN6ejZP?=
 =?utf-8?B?TmFmU2plZ0xKVmQ2Lzh3ZDNaakpTTU5CREhtam0wUTdKaHgzdnAvM1JxREZK?=
 =?utf-8?B?akJHWE5GM2dBMEJoYld2VXNTeXlZN1RPOHNTZ0RVd2pLMEsvMFZKNjVGKzhE?=
 =?utf-8?B?ODVEc0FiYnV1bXo3M01CVzVYc05lWDRzMDcxaS95eGYxUCsyWmFlYzcydExt?=
 =?utf-8?B?S01GOFVid3JBck5tbnk2aDJDT1dCZ3JhbXRNeHEyQ21jYzlRc2hNNFJFczRH?=
 =?utf-8?B?cjlRLzVpbkJmeXU1cTQxS29keTNMWmlLaFIwZmcxTXhQRjBuZUdwSUpEUkY2?=
 =?utf-8?B?aVlOYjkxNWFLTGdORzI0dnkwWkE5SzdoeGlMRmlFQm41SVRsb2RpMHRxL0pV?=
 =?utf-8?B?Y1FDM0ttTXZmRXUvQjZxeWNCTzNlaDhGOCtNL082QUwyVUMzLytxVW1TVnc4?=
 =?utf-8?B?NmRlVG1QR1FyaTVlNG1IUUN4OXFwS21KVXZZWHZMU0NIZ2VVRXdOd0tFNzg0?=
 =?utf-8?B?TFhoYzNFTjR5Nng4MFhrVGJjWXFqWW9jSElsSXJDY0gvQ3Y4Rm85RnNnWUgx?=
 =?utf-8?B?ZTh4blZ0ZlBKSXFYd0MxVDRDZ1Z4T1U4Ny8vSjhLUkQzdHdFTlAwaXVLbDRm?=
 =?utf-8?B?ZWNSQ0ZrdUd4NURoeURVVXczNThpam1YYzRFWFJVVklqdGw4YnVuSkg3bkx3?=
 =?utf-8?B?Q0VhUzBNbnE2M3J3RGl3emgrZmxBZ3VkdzNMR09sZ2g4N05SVTE0UEZyNUJG?=
 =?utf-8?B?cGt1ck15c2trdzl4U1dGTTQwajdXTEZtL1B6QlVrU3plR3JhMUlZSTVqa3pV?=
 =?utf-8?B?Sy9jNEFIN3RPYS9zSTBqOWNUemRjelFQWVhXd3FvT3o3R3MzTE4wWGJuZ0J0?=
 =?utf-8?B?OXhjVWNHQUU1RzdldzhjTXMyeS9Edm1jRSs1YTVVV0FqZ05wbHpnYmZJbDE1?=
 =?utf-8?B?bU5HRlJzM29UUTlJWEhXMld2Umhab3JhT3p3N3ZUMG8rSkVJZWE4UHVHWXBx?=
 =?utf-8?B?amJmSjZIdzgwTTM1TFlqZXE4YVBVUlViVTNYRi9GVGF4WFdUazhUdFlFODd0?=
 =?utf-8?Q?At+An9SDsnvJ/YaLq+qCnPaJY?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 385d7282-3aa7-4a03-9e09-08ddad84bd20
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jun 2025 09:52:58.0498
 (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: lpusQpOOt5d8LgcyJ9nZzCQyb4JrEQ+1siChz3bAmLe559qfZi0f24HAiRFhNo7H
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB6669



On 17/06/2025 11:26, Jan Beulich wrote:
> On 17.06.2025 09:19, Michal Orzel wrote:
>> @@ -1084,8 +1085,15 @@ void __init console_init_preirq(void)
>>      serial_set_rx_handler(sercon_handle, serial_rx);
>>      pv_console_set_rx_handler(serial_rx);
>>  
>> -    /* NB: send conring contents to all enabled physical consoles, if any */
>> -    conring_flush();
>> +    /*
>> +     * NB: send conring contents to all enabled physical consoles, if any.
>> +     * Skip serial if CONFIG_EARLY_PRINTK is enabled, which means the early
>> +     * messages have already been sent to serial.
>> +     */
>> +    if ( IS_ENABLED(CONFIG_EARLY_PRINTK) )
>> +        flags &= ~CONSOLE_SERIAL;
> 
> Does EARLY_PRINTK=y alone guarantee everything was output? That is, is there
> no chance that early-console init may have failed? (Sorry, I don't know much
> about early-console in Xen, as that's Arm-only.)
There is no init function for the early printk and no function related to early
printk returns something.

~Michal



From xen-devel-bounces@lists.xenproject.org Tue Jun 17 09:53:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 09:53:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018041.1394955 (Exim 4.92)
	(envelope-from )
	id 1uRT08-0007mD-Cy; Tue, 17 Jun 2025 09:53:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018041.1394955; Tue, 17 Jun 2025 09:53:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRT08-0007m6-AC; Tue, 17 Jun 2025 09:53:08 +0000
Received: by outflank-mailman (input) for mailman id 1018041;
 Tue, 17 Jun 2025 09:53: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 1uRT06-0007XT-VB
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 09:53:06 +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 dd48dcd1-4b60-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 11:53:05 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-453426170b6so15856115e9.1
 for ; Tue, 17 Jun 2025 02:53:05 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2365d88f447sm75509655ad.45.2025.06.17.02.52.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Jun 2025 02:53:04 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: dd48dcd1-4b60-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750153984; x=1750758784; 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=/NhOlmMTj9iwnS+Cvnb8YLBqjtPN9tAIt1TSWDHLYYs=;
        b=LlMgiQgKwMQWSXGx2Khe4QszIw0hofn+NFcQSloSGZkd/Zy7bIOTynZylUvYF12dkX
         QLk3a85OnuRWKKoExdeQ7gekcvIm7qy0H7VTSGiDMgDlzalf6anJGnSJiMOu4aeP9+2t
         MDv1G0k7l9gecV2iypbR/sTmiHdRqjwXuWcewrrMc9KtC/FCFxl4XocnmXLstjrzdBGV
         duDOOXhkK0d0IovbY90yBa1l6YKy0Bauz/EPbKaSMZ8F+3fU39iVLhjq1DT/YF+JOBjO
         eibX7ddaQAkWzLGNROhkS+W2od6G6Uh19BfuhTRdlIoFaeIOWbrBn5N/ZXB79ViQY2m5
         zKww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750153984; x=1750758784;
        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=/NhOlmMTj9iwnS+Cvnb8YLBqjtPN9tAIt1TSWDHLYYs=;
        b=NcmA27vzRY4sYNnlRZbIzKkdyG3IRrdDZZ/1WwuWGCDGHNRpAp94aaLcjHpiwHQbG7
         wlHS8fl6TQ2U3b48Yfj93+aqi/8SYZ4LjS9T2EsAR5dg1OeMwnC3+KdxLdr6nDtCSW9r
         cB9s6jBmtcgDW9l+cqrurVVxrw/qYBKXDYtO13nflFnsPja/t8MmiLPL7jW2L9b0ci/Q
         SsLXrRrTzLPHKQH5MdKAElqZwe9GzT5BiWP16NPtQxHM0HcPFvhYbEn1XAvFkJjhh1xV
         dZTieEyG4jxFtvUXF/bxMF42bKI6MoJ13HePovdlputGiyWJUx3iByxiu7DiGuBc/H4n
         7WQQ==
X-Forwarded-Encrypted: i=1; AJvYcCWb0hiftd3PjJh0rHmHoZ9ksB8C1Fahx0MOQDE4Y/QsP0S7mlxweN+iIijRJZs8/NaI9uqfWrSnaco=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxR8j/pzM1eOK6aNKbZy72D5innjxJxUhswmTY+BSHe3VaAksYA
	7vWWZhmrongEH12+zj+J8Xnq1kD6GHBZnzGP4iI6cwaPSHbDhAFG83mu+15eKXDm6Q==
X-Gm-Gg: ASbGncvfhzvf+kH6CxSGC5SVryQbXBzbWBV2s0rgrlSM0hLwD60nUycDe59EFXCz4Me
	veQ/igFHn6yumrgRHuOAz8cIclW+19zrcjIJ2XXnwTln7STLaGuisFPOT6kY5zEdw2oylI+6y38
	FakoU7hgkHhLC+JlBX7z92EGxeOtLIEudcFvuGeQS69wt8VWQ4oldqm+QffZofyl01nP0bJEfhj
	e3giEBEHErZkVlegJavnevZtAwHFgiNGQW79Ap58ELfGwmzFt55v+1Vg4a9Dys8XVMozCarP8Wv
	rX6ykpbQ2micP18lkfQ3EdXnUYt9dmEMPV2zKB4hggDRlhvF3WWnp7qxBtt+L+hnzAGZ27/5XL/
	K6ezY7Nty7Vldau5Fh5MC1oTd0cvn544vh4tp6ubGEaoGh8o=
X-Google-Smtp-Source: AGHT+IFRwA06Alg15IA790mL6WSzkoRqipFVlCMWuIChPUlFFSN4xuOJXf1GS7jNAa3qtGCpydougg==
X-Received: by 2002:a5d:5f8b:0:b0:3a4:da0e:517a with SMTP id ffacd0b85a97d-3a56d837d63mr14136598f8f.23.1750153984507;
        Tue, 17 Jun 2025 02:53:04 -0700 (PDT)
Message-ID: <01ff8001-9233-475d-8b26-6825ba326bde@suse.com>
Date: Tue, 17 Jun 2025 11:52:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen/console: introduce domain_console struct
From: Jan Beulich 
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org,
 teddy.astie@vates.tech, dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250617012713.57074-1-dmukhin@ford.com>
 <1ac74dd3-e0c5-43e5-9eed-c1a2cc17d068@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: <1ac74dd3-e0c5-43e5-9eed-c1a2cc17d068@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17.06.2025 11:48, Jan Beulich wrote:
> On 17.06.2025 03:27, dmkhn@proton.me wrote:
>> From: Denis Mukhin 
>>
>> Introduce domain_console for grouping data structures used for integrating
>> domain's diagnostic console with Xen's console driver.
>>
>> Group all pbuf-related data structures under domain_console. Rename the moved
>> fields to plain .buf, .idx and .lock names, since all uses of the fields are
>> touched.
>>
>> Bump the domain console buffer size to the closest power of 2 (256) and
>> rename the symbol to DOMAIN_CONSOLE_BUF_SIZE.
>>
>> Move d->console->buf management under CONFIG_VERBOSE_DEBUG when the
>> HYPERCALL_console_io handler is enabled.
> 
> This, if at all, needs to be a separate change (with its own justification).
> I for one don't think VERBOSE_DEBUG is intended to control any kind of guest
> output.

Hmm, the option's help text indeed says it mixes two unrelated things. Maybe
this wants untangling. With a behavioral change like the one you suggest, that
help text would need updating in any event, though.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 10:06:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 10:06:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018056.1394964 (Exim 4.92)
	(envelope-from )
	id 1uRTCk-0001YY-Fj; Tue, 17 Jun 2025 10:06:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018056.1394964; Tue, 17 Jun 2025 10:06:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRTCk-0001YR-D8; Tue, 17 Jun 2025 10:06:10 +0000
Received: by outflank-mailman (input) for mailman id 1018056;
 Tue, 17 Jun 2025 10:06: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 1uRTCj-0001YL-2p
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 10:06:09 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20622.outbound.protection.outlook.com
 [2a01:111:f403:2413::622])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id aef836e3-4b62-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 12:06:07 +0200 (CEST)
Received: from MW4PR03CA0007.namprd03.prod.outlook.com (2603:10b6:303:8f::12)
 by PH8PR12MB7277.namprd12.prod.outlook.com (2603:10b6:510:223::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.28; Tue, 17 Jun
 2025 10:05:58 +0000
Received: from SJ5PEPF000001CF.namprd05.prod.outlook.com
 (2603:10b6:303:8f:cafe::64) by MW4PR03CA0007.outlook.office365.com
 (2603:10b6:303:8f::12) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.23 via Frontend Transport; Tue,
 17 Jun 2025 10:05:58 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ5PEPF000001CF.mail.protection.outlook.com (10.167.242.43) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Tue, 17 Jun 2025 10:05:58 +0000
Received: from localhost (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, 17 Jun
 2025 05:05:55 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: aef836e3-4b62-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=G3Dh9wimFpSXCRD2z9j157l0Lp5l21Yby+BG+s/NNY+eDH0KNveknVA4TzrWEgWUx3d9PHm5+XVIt3ax+eRgzFXHtyOOzIAr4RkdUBRGwWKdNDDJHC1yDvGQJqs5TiYTPKL4RyXCYZZp+WgWmgsjjeQ83Iva9knbb45yq35J9aFn9su2i3SvfPkWxj4TeXQUGglRzGFNhhXNToJrAMPKewj4orJByMnpfR+vRJPsFdbKAIyVIIiwUvjKKAN7QnIiEA3nvQLHtwjm3/ERdx8E+huNkCByRJMkWwrrz9lfc2SJSzLYffEWf9AOoxbPtxM3qiILhBbBaEiRPelyytn0sQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=JQIRDRDP+DrnJgoJHFlAKc3k8AM7vs3qKBi025NYhP0=;
 b=podLQLwLm57rstsSKvZ87uJjncFe888ZdBiU0PSAnhh7FDTRH2ZuBmk2VPzLqrBzU9Gw0SnV3tcK/fllkAzK+iVRaDE2DXxAJqQmZMrIz3rt9tArY6gDkyyl+8mv7M62U+WdgoeuOqOzaGNSqCEy9pTN5nzpoqaiE27WIUYwqCniqftYKBkp1PCXaM7XrtDyosxs7RKPe2/EWuCM4bHKMAOgkMRWoe8wG2oGIUVK8+itdy2ptEg1riKwR3eJvfciid2N7l8nPEaoNMM4Z859aM7a6v2zTZHe6nA2xkQO9+ZZgPpjLuIRoB8OQiNLm2QwUjhNjHbqNy6derK3CXH4Pg==
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=JQIRDRDP+DrnJgoJHFlAKc3k8AM7vs3qKBi025NYhP0=;
 b=J9tN8nn4QuT97S+0Arpilk/PzL3s4idob/HbuIyxJQk+f1BPr6bQdIZkcI4/NsVtBW4zdDlG6iN4w8IK8+J2T2mLra4qQJYhMRJ0c931qjXGqwMQ5Y1lATzYPLuezi2pB6yRljnTPjf8T0XTP0ZAIef34ijG7thLIU0aiEzeyWw=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 17 Jun 2025 12:05:54 +0200
Message-ID: 
CC: 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 v3 06/14] xen: Refactor kernel_info to have a header
 like boot_domain
From: Alejandro Vallejo 
To: "Daniel P. Smith" ,
	
X-Mailer: aerc 0.20.1
References: <20250613151612.754222-1-agarciav@amd.com>
 <20250613151612.754222-7-agarciav@amd.com>
 <4b33dbe2-ee86-441a-b426-6551ccd04b31@apertussolutions.com>
In-Reply-To: <4b33dbe2-ee86-441a-b426-6551ccd04b31@apertussolutions.com>
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: SJ5PEPF000001CF:EE_|PH8PR12MB7277:EE_
X-MS-Office365-Filtering-Correlation-Id: 0dff3368-9327-48a3-fdff-08ddad868e54
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|82310400026|1800799024|7416014|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?WE1yU0FjVkVCa3ZVNFFSaVhpamJwSUZMbFhCWExuR3lsb1pNdldrTlNBNkJa?=
 =?utf-8?B?RWZMRTFiMlhEMnhnb3VBYlNRNWNZQ1RkbnFObElWTTArOFl4bWVPcFIwT3hG?=
 =?utf-8?B?MUdJRXZleks1b1lZRThsL2dUczEvNG9KbllOeU1zUlFIRTdBT252N2FTQ1do?=
 =?utf-8?B?M0t3VFZEdUJJMUdJRHZlTHl5NVV6bGNqQ3RlaGVhK3J3ejl1UmYvV1IrMTVX?=
 =?utf-8?B?cDU2NU96R0tZcE1XVVJFT203UytHbGVCSVY3SnkreEp0Ym5xSzhndDA1VmZv?=
 =?utf-8?B?dWVNZlVFQkFMSzNobE14YWZxN042WHFGT2tuSjlhMjBkTmgwdlhNbE43bGYv?=
 =?utf-8?B?S1lnamNCZUNpMXNPTEJkUDE0UEI3dWpIUUhpM1N5dDd6emUydjlab01aUFJ6?=
 =?utf-8?B?bmxZc0oxUHUxdFBoMXViWHVmV0o2Z01Ud1gyTU1OZTgyK3dtRWl1aWhFRFAz?=
 =?utf-8?B?amNsd0xUeVhsVUpBeTVFTnBZOUx6Z3VuSjlNQ1VhV3JlZWZHNUpKZEFyVWlC?=
 =?utf-8?B?NStGUnluY3lvZjczY3dBUXpaTGw3b1hOOXhWdExDQmZQd0F2TloyRFdscGFZ?=
 =?utf-8?B?eWdzeEZaMXprVTRJUmJjT1YzSHhsKzhBOEp6eXpJbGVKb3FMWmZwUmhaMDBu?=
 =?utf-8?B?MFE0cUs4bE9wemx5S2lybkFuSEJuZE5BeW5vZmJuSGdFM3F4YlpqR251Ukho?=
 =?utf-8?B?Qis3RTdieDh5Zm5JdWVNQ1ZXUElFaXVHWFl4bTNTN0xNUXU1c2NLekViSXVN?=
 =?utf-8?B?ZGJxTTZ1aThSb1NPSmlId2kzTkdLNGd6NjRIZ2Vyb0FMN0E1dnlqZzMwVlBH?=
 =?utf-8?B?U09tVldKK09OZk5nWlJjd2JKTkdpakV5VEJDM01ZUngzZUt3VzZkTExhUHUy?=
 =?utf-8?B?ZUM3U1hKdDE1dlNMZXd1dzVWcWZmei96eEZuQ3NXT2lUUGUzTmpuY1ZHZE9S?=
 =?utf-8?B?eFN6Q1JuTGUxajV0L0xrS1NuVzRKakVMc1NMVWJBREs5bnZkMjBIWkg5bTZZ?=
 =?utf-8?B?NzhLTzJqb3Z4dSttc3hVYnBxbzYvYWhSWnIrazdNOTNTc2orMUY2c0lzVnlP?=
 =?utf-8?B?TWVySEtHUnhoTWhjZUNTK1NvU0pXR1BHSHQzSk5MTUhqeTlRU0NHNzQwazNX?=
 =?utf-8?B?aHlxbURrWVVuMlRvck9EZFpLVEc1ZlMzeXdiR2N0K0tCS3FoU3ZhUGtNR2V2?=
 =?utf-8?B?V3pBNjgyWmV6bENXQjQvSG1LQkNNelZVaTNtWTR1VWk1cTRjbVA4NDcwbWI5?=
 =?utf-8?B?WWdZRkpWZ29JeGl3Tk1TSjQ2a0NiOWVCc25kdm9ROG1mUkJ6MDhrdmpHTEZu?=
 =?utf-8?B?VUZjSjJlcmFEZldXRkp0c0FXUW1vcVVrbXYwTGlwK2ppOVBueG9QM2dsOEc4?=
 =?utf-8?B?N3d3WUNZZHZmMDNPcC9lNjYydHp4K2dBVU5GZVBFTFl3NTNwTm9tTk1TOEVB?=
 =?utf-8?B?NUhBSWk0YkdYbkFKZk1FamYyOTNJSnhUdjhKZmRLZGFJbllBM0xRVTMxbTk5?=
 =?utf-8?B?a3IvSUU4MnhYV2oyWnBGT2tMK2NEL05xK3gyN0M3R21RVk1aU2RYckpXNUsr?=
 =?utf-8?B?RUZ4bVdybWlYSmxYWExiNjFCTFY0UGZaTGp4UHNmUDV1N3huNjRNVGhVUXBa?=
 =?utf-8?B?dm5DMm14VjZLTktlUVFOS0V4ZWFFYmpFdE51YXl4RzZaM3d2UkJvcUQ0NVlq?=
 =?utf-8?B?RTJKZXh2OVlpdUpLQ1UzQ3h6N0NpMTJIVk5hNUdrZUZxaEZvQXpQcUhobXl1?=
 =?utf-8?B?Uldsc1M3RU1GUlVDT3JlazZLK01KeldLMzlXb2ZKc2VOUDNwSjNubURxS1U0?=
 =?utf-8?B?U2MzU2VFQ1A1SGsvME5RN0xySmkyekRlR3FDaC9SWG9GbHJ4OE9GdVMzVndB?=
 =?utf-8?B?SHRlVk9FMkJyWmRlQlg5dEM0NC9uZjN1Y01pdUlHVHN4TTVzR0xjek9WRGFu?=
 =?utf-8?B?SEFmSmFqQVBmOFFVSjVoUHFmRnNmUW5DOHRkdzYxT3FQTkxld3lheW0yZ3Y5?=
 =?utf-8?B?SDRwd2U4Z1hqMXM1OGU4bWhsWmR1VTFTNldBaW1uM2NwRUVsNCtmTnR5RDRz?=
 =?utf-8?Q?Z6hLbr?=
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)(7416014)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jun 2025 10:05:58.0288
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 0dff3368-9327-48a3-fdff-08ddad868e54
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:
	SJ5PEPF000001CF.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7277

On Tue Jun 17, 2025 at 3:22 AM CEST, Daniel P. Smith wrote:
>
> On 6/13/25 11:13, Alejandro Vallejo wrote:
>> Create a struct header within kernel_info with the contents common to
>> kernel_info and boot_domain, and define that header in common code. This=
 enables
>> x86 to use that header as-is and drop x86's boot_domain
>
> IMHO kernel_info is an extremely poor name for this structure and=20
> hyperlauch attempt to resolve some of these less than optimal choices is=
=20
> being undone.
>
> v/r,
> dps

kernel_info is a big misnomer, which is why I originally typedeff'd it to
bootdomain_t. Note however that at no point (in v3) does kernel_info reach =
x86.
The header is effectively what was already in boot_domain, except it's comm=
on
code now so the domid field (not yet included in dom0less) goes on an "arch=
"
subfield. And x86 only uses that header and doesn't know or care about the =
rest.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 10:08:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 10:08:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018062.1394974 (Exim 4.92)
	(envelope-from )
	id 1uRTFB-00024s-SN; Tue, 17 Jun 2025 10:08:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018062.1394974; Tue, 17 Jun 2025 10: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 1uRTFB-00024l-PW; Tue, 17 Jun 2025 10:08:41 +0000
Received: by outflank-mailman (input) for mailman id 1018062;
 Tue, 17 Jun 2025 10: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 1uRTFA-00024f-UC
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 10:08:40 +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 09b3bef6-4b63-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 12:08:38 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3a510432236so3993063f8f.0
 for ; Tue, 17 Jun 2025 03:08:38 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2365deb0f55sm75870345ad.188.2025.06.17.03.08.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Jun 2025 03:08:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 09b3bef6-4b63-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750154918; x=1750759718; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=/G0xM7PKUijSaxYeTVZlljJZhsxjs9kjAz8E8g8k3sA=;
        b=JDF+rz6eC8mTvPXtCGvNdRw+2irAZ/htvmR43glKm5qeYncc4sAzPF0DkiaedE5nG/
         q7pOLIbQpqWFUTzEQFmGs0ZFl53Rp5LVK4zw3mMofyeUyO+FraF6cceCkomc8mQ7Su/1
         K4Aftiq63zoSmMCjmfeGII248fbNCbiN9grRzw52SCIophxvvzrb1qLUHJfqR/iTuKeI
         cMa6KvFqaV/9eUTn23hbKHhRbmkVeSZG/hA+cH/tHc4jl8vINoDzrRjFFijMlNmw8mS9
         JZ6PUt1wTNm5aqydYruol378hG2m+z4bvgEw+TdzQ3m7g4O/XjxigUesnGoWNuY3d4fk
         ZsXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750154918; x=1750759718;
        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=/G0xM7PKUijSaxYeTVZlljJZhsxjs9kjAz8E8g8k3sA=;
        b=jlnWQHSBeq/rrObjSSE01s5ZEuxHX2RngJ2YWkEGLKjM0hRqC8uaPfGfD5Yl0CPqRj
         +ssji3EnAvg5UEhVDjd6rCR8Q3dMzDapBwY6SXKNcwh1VbYvUxG1tj8/qISChJzAGhOK
         0lmeYhig7dcvXFgM1FYwQx7gvLEQwmuVdTDBDbkjOZwbG96Fddi6XYhUKtU0EA9uvl9Q
         QAVa75+g6f540xjyA1aB0b2t0wr1SXgadml6wuKF+itD3XALVnIIWkfv4kNW/Br5LAZv
         hAGBAwgMddX9gF+ffRSr53n04lINaLByCihVp8nij6uRYSmhBQ9LqHz5cQ0m8B26io8v
         OQSg==
X-Forwarded-Encrypted: i=1; AJvYcCXjz9G9Re1EPEEnOhNHESKQYn6JtzTzTVedF4ihIX/2DU/ChuXn6SoStTTtMb3ClDov598Gv31Fse8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw3Usak9+Q4czyrw2EfgKY9ENETGZBk1pzwAlIA9XFPbUHTfWJL
	hbWqm3BVjhTc3N9j3/q4ou8BpGlePdY1cgUsu/VVu9vdzQWrHW1JA8BuEnzKSoXPgA==
X-Gm-Gg: ASbGncsih/Pfp3wKekOsr9+YXOFeQLi8PMGOcutVFsedAdwVnlRF5FV3Zfmd+UpkIDi
	dw83DCKPJu2ikHi4PePOL/PFwZqZSbmlJTe4uiRwBN9ty3EGJy1oXIG/c/qShqVXAmf4XkBEX0B
	ysOWXV2hx/DmH1aDlysfisf/SSKQGfoeq50CpjjGLBXyidEjjQ/drEgV7yjp+xvJTCypo/zXDnk
	hgNNTgVyc0kQMMEzu1eGT1FM1yE9BtSrDELgfuBWmDuVw7NIa9D5RuxP6EO39busnzl5qhm0nul
	82BM26CdDIW5TUDOZ11wsonDKUGTob07UN16INjg4w2unRTSVOFHtZhEa7WtCPbswfH+QyVb8w2
	kDnfkgNBpN/FPWjj0NWaA4EqzjDMpebMJ54yQgmCQcJGF3BU=
X-Google-Smtp-Source: AGHT+IFZ7tdos8JEFArZnLuChDHHRx1qYbKLToTiu2R/wOKrsdnvK8OsMMYu4/qb9okmZyHZBXe0Kw==
X-Received: by 2002:a05:6000:26cd:b0:3a3:6595:921f with SMTP id ffacd0b85a97d-3a572e79674mr8119315f8f.41.1750154918001;
        Tue, 17 Jun 2025 03:08:38 -0700 (PDT)
Message-ID: <1e3fa4e5-9409-46ec-abba-1bbd14602d79@suse.com>
Date: Tue, 17 Jun 2025 12:08:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 14/18] xen/cpufreq: introduce GET_CPUFREQ_CPPC sub-cmd
To: Penny Zheng 
Cc: ray.huang@amd.com, Anthony PERARD ,
 Juergen Gross , Andrew Cooper ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-15-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: <20250527084833.338427-15-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.05.2025 10:48, Penny Zheng wrote:
> --- a/tools/misc/xenpm.c
> +++ b/tools/misc/xenpm.c
> @@ -69,6 +69,7 @@ void show_help(void)
>              " set-max-cstate        |'unlimited' [|'unlimited']\n"
>              "                                     set the C-State limitation ( >= 0) and\n"
>              "                                     optionally the C-sub-state limitation ( >= 0)\n"
> +            " get-cpufreq-cppc      [cpuid]       list cpu cppc parameter of CPU  or all\n"
>              " set-cpufreq-cppc      [cpuid] [balance|performance|powersave] *\n"
>              "                                     set Hardware P-State (HWP) parameters\n"
>              "                                     on CPU  or all if omitted.\n"
> @@ -812,33 +813,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 )
> -    {
> -        const xc_cppc_para_t *cppc = &p_cpufreq->u.cppc_para;
> -
> -        printf("cppc variables       :\n");
> -        printf("  hardware limits    : lowest [%"PRIu32"] lowest nonlinear [%"PRIu32"]\n",
> -               cppc->lowest, cppc->lowest_nonlinear);
> -        printf("                     : nominal [%"PRIu32"] highest [%"PRIu32"]\n",
> -               cppc->nominal, cppc->highest);
> -        printf("  configured limits  : min [%"PRIu32"] max [%"PRIu32"] energy perf [%"PRIu32"]\n",
> -               cppc->minimum, cppc->maximum, cppc->energy_perf);
> -
> -        if ( cppc->features & XEN_SYSCTL_CPPC_FEAT_ACT_WINDOW )
> -        {
> -            unsigned int activity_window;
> -            const char *units;
> -
> -            activity_window = calculate_activity_window(cppc, &units);
> -            printf("                     : activity_window [%"PRIu32" %s]\n",
> -                   activity_window, units);
> -        }
> -
> -        printf("                     : desired [%"PRIu32"%s]\n",
> -               cppc->desired,
> -               cppc->desired ? "" : " hw autonomous");
> -    }
> -    else
> +    if ( !hwp )
>      {
>          if ( p_cpufreq->gov_num )
>              printf("scaling_avail_gov    : %s\n",

I'm not sure it is a good idea to alter what is being output for
get-cpufreq-para. People may simply miss that output then, without having
any indication where it went.

> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -462,7 +462,6 @@ struct xen_get_cpufreq_para {
>                  struct  xen_ondemand ondemand;
>              } u;
>          } s;
> -        struct xen_cppc_para cppc_para;
>      } u;
>  
>      int32_t turbo_enabled;
> @@ -493,6 +492,7 @@ struct xen_sysctl_pm_op {
>      #define SET_CPUFREQ_PARA           (CPUFREQ_PARA | 0x03)
>      #define GET_CPUFREQ_AVGFREQ        (CPUFREQ_PARA | 0x04)
>      #define SET_CPUFREQ_CPPC           (CPUFREQ_PARA | 0x05)
> +    #define GET_CPUFREQ_CPPC           (CPUFREQ_PARA | 0x06)
>  
>      /* set/reset scheduler power saving option */
>      #define XEN_SYSCTL_pm_op_set_sched_opt_smt    0x21
> @@ -517,6 +517,7 @@ struct xen_sysctl_pm_op {
>      uint32_t cpuid;
>      union {
>          struct xen_get_cpufreq_para get_para;
> +        struct xen_cppc_para        cppc_para;
>          struct xen_set_cpufreq_gov  set_gov;
>          struct xen_set_cpufreq_para set_para;
>          struct xen_set_cppc_para    set_cppc;

This (tools-only) public interface change, otoh, may be okay to do.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 10:20:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 10:20:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018069.1394985 (Exim 4.92)
	(envelope-from )
	id 1uRTQ7-0003w0-Rv; Tue, 17 Jun 2025 10:19:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018069.1394985; Tue, 17 Jun 2025 10:19:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRTQ7-0003vt-PB; Tue, 17 Jun 2025 10:19:59 +0000
Received: by outflank-mailman (input) for mailman id 1018069;
 Tue, 17 Jun 2025 10:19: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 1uRTQ7-0003vn-69
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 10:19:59 +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 9eb4b530-4b64-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 12:19:58 +0200 (CEST)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3a52874d593so5350683f8f.0
 for ; Tue, 17 Jun 2025 03:19:58 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2365deb23e9sm76102845ad.187.2025.06.17.03.19.53
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Jun 2025 03:19:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9eb4b530-4b64-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750155597; x=1750760397; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=S4yCxuBD3RxG17f6d6WlqGN28gipJrYWH+YwyKTSXdg=;
        b=YrFp4B6oE92t5ZKmz22i4C7jL8HAnxpmyJGnK80UwWG7JBlWT8F1CA3vD1orkNKDMQ
         2eoksdcV+HJQaLlrqWZTFdvyTB4kGStxoGbYXZIi9CYHWG8hwiSl1zj2QKAp10Hplo9w
         5em35gB3PjxQhN7S40Gx0B5fDWoa1bAKbMTD4ylXmwD03bNQ2zHbvk4RlTcEhDaqZD1B
         SxnLUZ14X90SKXyhjDqSCvynJ0hhts5zNgXJTb42iCXIlb01+oPajiSzWzgGAMQQbriF
         xRXzstFQyVRiVM1iYO12s55BHShRCknJxQC18UCBRBcEqk6WzvqyrAr+sV4gKAnrA8wb
         +11w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750155597; x=1750760397;
        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=S4yCxuBD3RxG17f6d6WlqGN28gipJrYWH+YwyKTSXdg=;
        b=XyC1yaRjIpGVnJgRVzbqO2ICynvLnSwVLYfd0PkFjPmjbNqa/Tri0MQOUnkKWwKcUl
         RCAEWH1j31cwMJi3QDOVf8AIkggXzHGX21Hg8RVrU6BIbRQ82EtfrBdgIRouwJ2daP6g
         QuZFiUz1dB0+FVK4Sd8SJbyRtrDmLUJ4XzabrhHJaY5N83LH68+bof72Q77NwS3vOt7R
         xluuXswRqMxhqQzKktYSGY3dE4QsYAUKcygT4Lim4gHyHKdJNrB+Y5TQThJQMTfsGLvw
         p0Xe1PCfOK1UmgXSMgVrRxAMRP3CqH/7KoYiOjO+7GRWeG/k7Tyx70MBu8+dWjzlqIZ8
         5h/A==
X-Forwarded-Encrypted: i=1; AJvYcCV45ycniBR1U7KaJiD5zrnCEN68X+Zi2LoIxxiMclNbPvDHCCPdbEQ4QvlsRS5qnkOqRQzX3BsZ0gQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx+xRom217YA2rIwBfYdvvyb20yJMNRYU0HSTcmGHR35JfQ+BKs
	9fIG3ofLkN7MD4HZrBEeUn8f8QiaqVANQe1YV8aYYJYqt7CaP7gdV9bANyFBMM/VXA==
X-Gm-Gg: ASbGncuaczncP9C/pDmiiUgLbrTAFOoByy6FHHGwqsVDgBJMhNLrgTlCCb2ncwg+cDz
	04FBawaWdWBxsl1nXM8dkY2BoHZhZ2MgaEYcl0CniF1FdiiufTQmYfWNvAFZhfZWBP/GY4kgkNJ
	oSPg+V8zPfd6N7MVzC3XqJpbaRTySTInNqkKFgrfFoOl1D0MYb3owURThP2PI6ddATpEkUCh8YT
	8XOdMPX/K7io1r4IzI5oNbdV9N6A4E5h1C6cXeE0EIydPUwjbsWJUWPtggJ2TLsG2f1W6N7axSf
	YqmUB9sPexvO4nyoNqtGgTWZNTZSOsojc63f91CwNxfiYuGq8U7hhXRXBdTZ5tN3yt0COyqLQzr
	DXcwzbvzS2mpsb02Pk99rH0ZbFnhap/Hu9dLtSkarA7zjljI=
X-Google-Smtp-Source: AGHT+IFQVKF57mxSgD1K19/rbXGej4+5ZqdW/keihxrMZ0Zth8kxWqY84u/yFny1bzHojvJ1VqOE1Q==
X-Received: by 2002:a05:6000:2913:b0:3a3:71cb:f0bd with SMTP id ffacd0b85a97d-3a57237de18mr10384947f8f.23.1750155597430;
        Tue, 17 Jun 2025 03:19:57 -0700 (PDT)
Message-ID: <30bee151-2cb4-4072-a299-d3725be8fe7d@suse.com>
Date: Tue, 17 Jun 2025 12:19:50 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 15/18] xen/cpufreq: bypass governor-related para for
 amd-cppc-epp
To: Penny Zheng 
Cc: ray.huang@amd.com, Anthony PERARD ,
 xen-devel@lists.xenproject.org
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-16-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: <20250527084833.338427-16-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.05.2025 10:48, Penny Zheng wrote:
> --- a/xen/drivers/acpi/pmstat.c
> +++ b/xen/drivers/acpi/pmstat.c
> @@ -253,7 +253,8 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
>      else
>          strlcpy(op->u.get_para.scaling_driver, "Unknown", CPUFREQ_NAME_LEN);
>  
> -    if ( !hwp_active() )
> +    /* bypass hwp and amd-cppc-epp driver */

Nit (comment style): Want to start with a capital letter. See ./CODING_STYLE.

> +    if ( !hwp_active() && cpufreq_driver.setpolicy == NULL )

We generally prefer the shorter "!cpufreq_driver.setpolicy".

And then - is using the presence of that hook really a good criteria to use
here (and below)?

> @@ -346,7 +347,8 @@ static int set_cpufreq_para(struct xen_sysctl_pm_op *op)
>      if ( !policy || !policy->governor )
>          return -EINVAL;
>  
> -    if ( hwp_active() )
> +    /* bypass hwp and amd-cppc-epp driver */
> +    if ( hwp_active() || cpufreq_driver.setpolicy == NULL )
>          return -EOPNOTSUPP;

Isn't this the wrong way round? I.e. don't you mean "!= NULL" (or the equivalent
thereof) here?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 10:35:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 10:35:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018083.1394995 (Exim 4.92)
	(envelope-from )
	id 1uRTfG-00072A-73; Tue, 17 Jun 2025 10:35:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018083.1394995; Tue, 17 Jun 2025 10: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 1uRTfG-000723-4A; Tue, 17 Jun 2025 10:35:38 +0000
Received: by outflank-mailman (input) for mailman id 1018083;
 Tue, 17 Jun 2025 10:35: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 1uRTfE-00071x-K0
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 10:35:36 +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 cd8d3bb9-4b66-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 12:35:35 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3a510432236so4016107f8f.0
 for ; Tue, 17 Jun 2025 03:35:35 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-313c1b499c0sm10193516a91.29.2025.06.17.03.35.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Jun 2025 03:35:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cd8d3bb9-4b66-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750156535; x=1750761335; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=XQQTrRfNHm7CV2lqUXXSjbBc03p0TU3sjU6o7uzbLf0=;
        b=NU9Wa9u3wIEVOpXXPUQNKi9nDou1s34AMrwEu8puyNuTHYRp3b1sO6AFliDVURLUHs
         IlzEdm+zn4TaUnq7jp9ZYJdFmcKXb6eqabDUXxQW09XEpWWdaBVoefNhB7IrojiJrO8y
         JY2g31n8ZeE7BtFV67Fz/fdOQEI6MOqx5/hts2RSQk/IyYawqgyW/E5R9DCfrOyRf818
         5uOe+Sms9QYhoyZo4yTsKXGsekjHMpTNcH9g9m4GOxYBv4aZOqqGPx0koT8tMDhTpAiv
         zWRQRYFO0JNBMRvmISbJePeeaYMF5BIP4NyHeDVG/Jeg9QnPQFLbeL5dG7btmUhsriqD
         syzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750156535; x=1750761335;
        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=XQQTrRfNHm7CV2lqUXXSjbBc03p0TU3sjU6o7uzbLf0=;
        b=OZJNb+jIZCWpi2neOxTR6sjDkedg/eUF/w0supcFGXdLjJTHS5bP8MA8+6dHZSD4Ym
         oKh4FWykO5zw0EyZn+bsURY65Y+SP74Fb+5xjN0Pw85tW4S9dpZR+Jin1xO1iKXVK/8B
         us08b+49zViczHBB3VoGXCPWpVkkRufon4m7ECNyD2406Xfnypa3nFrCgnfa0kvrhhgC
         30EUTPSEvcAwcdA9lJiScVn3P+Oz68scA86m7yCwudHk/V6W3+AhxYYvquUHlo5dWcik
         8MlpkjWRrGTAnLRFz1+iHVAG2xem+b96BfyHpcpw80h9zF0RE7aifAM48QZtvy89HIfm
         cWsA==
X-Forwarded-Encrypted: i=1; AJvYcCW0fL3cLrB1ANvZiwmXnfAK700FkhPmvznssZZF2ZPq7yDmEgF1A7RdnO5yJIljsfwbEggN4HuYYkA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzEeWhcX8Y7cDhLAYNxMAuuN76a6xtjDNtPktk7Kqhm3SKLPoet
	udnAXXyW2FwYCbLIs3c3qeCkHqUyD5pYqe5KI3UN+eWAzHgZl2ydxXZbUes3VdsCBQ==
X-Gm-Gg: ASbGnctEsBKhb1/4lH6cpjCUiJ94z+D5pjkBIs8ab0o/jUymnsbTjSQ2CFghZzHbPsk
	l7QZ+GPnEm7IoVA4LHwwpoj6Eg99LVrOUJUP9zB8PRiQCOdOjshq8Q+DNQTWLx9HcW8slZZx5f6
	SqxKb0h8kCMy4s9eMQwrp0mnQa6X8dhPDRvOAEMFQpUTQnts7fCkRFFMv+hJeWcDMeWscFDb5K8
	zRUG0kvJ26zykX9XOetbkxMmXh+t0wTxssq8wIlV2hlPMQ6PNFl4azp9ZUVSW4UwTpiwIV+s9ZY
	5KQyI4rNt9R1IL2a0QqSqA8Tu2OH6rqlVAl1dZhUBrhE3+VWvp38U73pQzGMaydGdqt9aMK6fkJ
	eKfNz+k/HQK76AniWNunwyVs7XyNWyrPAYFR1hV6UN5K6Bi8=
X-Google-Smtp-Source: AGHT+IErWHAQwd1+eTfJ4ks1U/1/HXuh1ZJkT9hgyE1ZzOedz1B01JaOLTrNfJEVRDDaTiuGMMmKng==
X-Received: by 2002:a05:6000:188b:b0:3a4:f379:65bc with SMTP id ffacd0b85a97d-3a572e79551mr10001142f8f.40.1750156534873;
        Tue, 17 Jun 2025 03:35:34 -0700 (PDT)
Message-ID: 
Date: Tue, 17 Jun 2025 12:35:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 14/18] xen/cpufreq: introduce GET_CPUFREQ_CPPC sub-cmd
To: Penny Zheng 
Cc: ray.huang@amd.com, Anthony PERARD ,
 Juergen Gross , Andrew Cooper ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-15-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: <20250527084833.338427-15-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.05.2025 10:48, Penny Zheng wrote:
> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -462,7 +462,6 @@ struct xen_get_cpufreq_para {
>                  struct  xen_ondemand ondemand;
>              } u;
>          } s;
> -        struct xen_cppc_para cppc_para;
>      } u;
>  
>      int32_t turbo_enabled;
> @@ -493,6 +492,7 @@ struct xen_sysctl_pm_op {
>      #define SET_CPUFREQ_PARA           (CPUFREQ_PARA | 0x03)
>      #define GET_CPUFREQ_AVGFREQ        (CPUFREQ_PARA | 0x04)
>      #define SET_CPUFREQ_CPPC           (CPUFREQ_PARA | 0x05)
> +    #define GET_CPUFREQ_CPPC           (CPUFREQ_PARA | 0x06)
>  
>      /* set/reset scheduler power saving option */
>      #define XEN_SYSCTL_pm_op_set_sched_opt_smt    0x21
> @@ -517,6 +517,7 @@ struct xen_sysctl_pm_op {
>      uint32_t cpuid;
>      union {
>          struct xen_get_cpufreq_para get_para;
> +        struct xen_cppc_para        cppc_para;
>          struct xen_set_cpufreq_gov  set_gov;
>          struct xen_set_cpufreq_para set_para;
>          struct xen_set_cppc_para    set_cppc;

Imo with the move and new use, the struct wants to become xen_get_cppc_para.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 10:38:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 10:38:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018090.1395005 (Exim 4.92)
	(envelope-from )
	id 1uRTi9-0007Xo-JN; Tue, 17 Jun 2025 10:38:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018090.1395005; Tue, 17 Jun 2025 10:38:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRTi9-0007Xh-Gn; Tue, 17 Jun 2025 10:38:37 +0000
Received: by outflank-mailman (input) for mailman id 1018090;
 Tue, 17 Jun 2025 10:38: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 1uRTi8-0007Xb-De
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 10:38:36 +0000
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com
 [2a00:1450:4864:20::42c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 37e3dd26-4b67-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 12:38:34 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a35c894313so6254285f8f.2
 for ; Tue, 17 Jun 2025 03:38:34 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2365d8a1ac4sm76418965ad.74.2025.06.17.03.38.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Jun 2025 03:38:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 37e3dd26-4b67-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750156713; x=1750761513; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=i2BolxaOx19/UhTG2jY2iLKgkGHeDnex5eKgAFybgdc=;
        b=XP6kIBKxHpZ+4a4cxyjfD8d/ql2bUGBGDmW5URR11KvT+jU1I07HP9SaxkUa7yQ8CD
         nNyZgdVTbB7hSr94Ob2qen2q/JK9vmrwxpcU/Iwa4PyRNI14miAyL+E0XDukqjO1rz8N
         nNHnIZb610MKgnBd+N+3ZNNIgc5KyByDpqr+JPRcI/HB1xuDqzp6oGbVe7m4NNbiONyP
         M0SeQJQw2ioC0Uiyuawh3rEbdM3D67oKhE4hHgQz809JCFBxGCcRz0Xc3zRrjErWpRbQ
         g3/qfhqEOU6AX97Pc375rxQKA5WqSbX31bKYSckglAy9v7dqJ6M8KCWSlRszdkP2xaJQ
         7YWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750156713; x=1750761513;
        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=i2BolxaOx19/UhTG2jY2iLKgkGHeDnex5eKgAFybgdc=;
        b=S1UZlQyRBIJ+P+CGruPKh4YJzkCNBvJdFV+8Uch6+Z//xxciKKoIgBnywSa2GwxvW+
         ljVswaT7uwNvFrg4TduE7dvdmf/RD5Sp5n3+xKlwaUgx5sX95i5v+927NbcH2g5yn7Jf
         hz6Gu8nH57Z65bCuBPlqmBchpjoxNAOApeGpK931aWkyhDzkv2drx2TygQV6PNaRtH1N
         GpqipGXppG3YpTb5DA6NBjZlGMU5AfhBLV4HqDGBDqr8IVpX0AqPta80PmucmLIYLf36
         7Rk9Gr6r/8ZsXZjCrhJBgaJs7wHixxfHwm60EazQIfOvdOfEj91k6UhAE1nal+sQ/UTK
         p2yQ==
X-Forwarded-Encrypted: i=1; AJvYcCU6TtMSt+RvHUxVJnOuWrjOMG4b0dVVHJMvpGWA01q40kt2bwF8KU0+t9BRwcZG3YD6rK4ufE69vLA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwGGyznHIafbyqeWm/Zlrq0xNKg86qpWP+6fy6d/QwpMC4j2Jq/
	h4oKAzl/pqTLqZtEleNEOWSRprIp+MgM89rGUhnejHjdqwk6EihTZJSQpYaHqU58MA==
X-Gm-Gg: ASbGnctMKHGuKdJlONC4nPDR9Fy2nTr2FRBbfbv0sXQV0dFVgyCQYSjS6G0cg/IkFX/
	MB8PwOspwEYHPflGNBT0iTn0L0prw5DncSENt/xKJB04d0YrJPjf9an3D+Bpwp8W/UIm+4bJuDr
	WuXX3+kcX7he91Pb89hrQ2XgeMlRCg2zAY/ClAPcXRSuPKOOGjL963kOTONz5hBZOyswTX+K5Tc
	EPaI12//h9RKdlRaW9gCWWmLZV9hMbRisO4iVhTFi0RmE/FpzQZB3HFUG6bGf1BEkxN4gcp9X5c
	1muoZopFy/hwYKNafggjMmIxQ29Hym3Ifl8S8VhlnVb3N1E3ou4Mj5oQi6+o4xMl3CFRoBoDYmS
	P9GWdClgPmFX5LM3feaSATQkaB70NiR7XfaUsvjisCSjNeiM=
X-Google-Smtp-Source: AGHT+IEqSOJprLmdLkEgsRZqFspvNpiGEiVRmG0buSiS4/iIMqsaPP3lHl3cWYXl/sxsP1KwI1Ql+A==
X-Received: by 2002:a5d:5f96:0:b0:3a5:2fb2:35ac with SMTP id ffacd0b85a97d-3a5723a182cmr10355893f8f.24.1750156713498;
        Tue, 17 Jun 2025 03:38:33 -0700 (PDT)
Message-ID: 
Date: Tue, 17 Jun 2025 12:38:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 18/18] xen/cpufreq: Adapt SET/GET_CPUFREQ_CPPC
 xen_sysctl_pm_op for amd-cppc driver
To: Penny Zheng 
Cc: ray.huang@amd.com, Anthony PERARD ,
 Andrew Cooper ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-19-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: <20250527084833.338427-19-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.05.2025 10:48, Penny Zheng wrote:
> --- a/tools/misc/xenpm.c
> +++ b/tools/misc/xenpm.c
> @@ -38,6 +38,13 @@
>  static xc_interface *xc_handle;
>  static unsigned int max_cpu_nr;
>  
> +static const char cpufreq_policy_str[][12] = {
> +    [XEN_CPUFREQ_POLICY_UNKNOWN] = "none",

Why not "unknown"?

> +    [XEN_CPUFREQ_POLICY_POWERSAVE] = "powersave",
> +    [XEN_CPUFREQ_POLICY_PERFORMANCE] = "performance",
> +    [XEN_CPUFREQ_POLICY_BALANCE] = "balance",
> +};
> +
>  /* help message */
>  void show_help(void)
>  {
> @@ -984,6 +991,9 @@ static void print_cppc_para(unsigned int cpuid,
>      printf("                     : desired [%"PRIu32"%s]\n",
>             cppc->desired,
>             cppc->desired ? "" : " hw autonomous");
> +
> +    printf("  performance policy : %s\n",
> +           cpufreq_policy_str[cppc->policy]);

What if for whatever reason the value you get is 4? Please avoid array overruns
also in user space tools.

> --- a/xen/arch/x86/acpi/cpufreq/amd-cppc.c
> +++ b/xen/arch/x86/acpi/cpufreq/amd-cppc.c
> @@ -506,6 +506,135 @@ static int cf_check amd_cppc_epp_set_policy(struct cpufreq_policy *policy)
>      return 0;
>  }
>  
> +int get_amd_cppc_para(const struct cpufreq_policy *policy,
> +                      struct xen_cppc_para *cppc_para)
> +{
> +    const struct amd_cppc_drv_data *data = per_cpu(amd_cppc_drv_data,
> +                                                   policy->cpu);
> +
> +    if ( data == NULL )
> +        return -ENODATA;
> +
> +    cppc_para->policy           = policy->policy;
> +    cppc_para->lowest           = data->caps.lowest_perf;
> +    cppc_para->lowest_nonlinear = data->caps.lowest_nonlinear_perf;
> +    cppc_para->nominal          = data->caps.nominal_perf;
> +    cppc_para->highest          = data->caps.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,
> +                      const struct xen_set_cppc_para *set_cppc)
> +{
> +    unsigned int cpu = policy->cpu;
> +    struct amd_cppc_drv_data *data = per_cpu(amd_cppc_drv_data, cpu);
> +    uint8_t max_perf, min_perf, des_perf = 0, epp;
> +
> +    if ( data == NULL )
> +        return -ENOENT;
> +
> +    /* Validate all parameters */
> +    if ( set_cppc->minimum > UINT8_MAX || set_cppc->maximum > UINT8_MAX ||
> +         set_cppc->desired > UINT8_MAX || set_cppc->energy_perf > UINT8_MAX )
> +        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;

If the respective flag is set, is the field being zero legitimate? In patch
10 you reject finding zero perf values.

> +    /* Activity window not supported in MSR */
> +    if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_ACT_WINDOW )
> +        return -EOPNOTSUPP;
> +
> +    /* Return if there is nothing to do. */
> +    if ( set_cppc->set_params == 0 )
> +        return 0;
> +
> +    epp = per_cpu(epp_init, cpu);
> +    /*
> +     * Apply presets:
> +     * XEN_SYSCTL_CPPC_SET_DESIRED reflects whether desired perf is set, which
> +     * is also the flag to distinguish between passive mode and active mode.
> +     * When it is set, CPPC in passive mode, only
> +     * XEN_SYSCTL_CPPC_SET_PRESET_NONE could be chosen.
> +     * when it is not set, CPPC in active mode, three different profile
> +     * XEN_SYSCTL_CPPC_SET_PRESET_POWERSAVE/PERFORMANCE/BALANCE are provided,
> +     */
> +    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;
> +        policy->policy = CPUFREQ_POLICY_POWERSAVE;
> +        min_perf = data->caps.lowest_perf;
> +        /* Lower max frequency to lowest */
> +        max_perf = data->caps.lowest_perf;
> +        epp = CPPC_ENERGY_PERF_MAX_POWERSAVE;
> +        break;
> +
> +    case XEN_SYSCTL_CPPC_SET_PRESET_PERFORMANCE:
> +        if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_DESIRED )
> +            return -EINVAL;
> +        /* Increase idle frequency to highest */
> +        policy->policy = CPUFREQ_POLICY_PERFORMANCE;
> +        min_perf = data->caps.highest_perf;
> +        max_perf = data->caps.highest_perf;
> +        epp = CPPC_ENERGY_PERF_MAX_PERFORMANCE;
> +        break;
> +
> +    case XEN_SYSCTL_CPPC_SET_PRESET_BALANCE:
> +        if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_DESIRED )
> +            return -EINVAL;
> +        policy->policy = CPUFREQ_POLICY_BALANCE;
> +        min_perf = data->caps.lowest_perf;
> +        max_perf = data->caps.highest_perf;
> +        epp = CPPC_ENERGY_PERF_BALANCE;
> +        break;

Isn't this more line "ondemand"? To me, "balance" would mean tying perf to at
least close around the middle of lowest and highest.

> +    case XEN_SYSCTL_CPPC_SET_PRESET_NONE:
> +        /*
> +         * In paasive mode, Xen governor is responsible for perfomance tuning.

Nit: passive

> +         * we shall set lowest_perf with "lowest_nonlinear_perf" to ensure
> +         * governoring performance in P-states range.
> +         */
> +        min_perf = data->caps.lowest_nonlinear_perf;
> +        max_perf = data->caps.highest_perf;

As in the earlier patch - I fear I don't understand the comment, and hence why
to use lowest-nonlinear here remains unclear to me.

> --- a/xen/drivers/acpi/pmstat.c
> +++ b/xen/drivers/acpi/pmstat.c
> @@ -334,6 +334,10 @@ static int get_cpufreq_cppc(struct xen_sysctl_pm_op *op)
>      if ( hwp_active() )
>          ret = get_hwp_para(op->cpuid, &op->u.cppc_para);
>  
> +    if ( processor_pminfo[op->cpuid]->init & XEN_CPPC_INIT )
> +        ret = get_amd_cppc_para(per_cpu(cpufreq_cpu_policy, op->cpuid),
> +                                &op->u.cppc_para);

This is a case where I think you would better use "else if". Otherwise it
looks as if both paths could be taken (and "ret" as well as op->u.cppc_para
be overwritten BY this second call).

> --- a/xen/include/acpi/cpufreq/cpufreq.h
> +++ b/xen/include/acpi/cpufreq/cpufreq.h
> @@ -134,14 +134,16 @@ 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
> +#define CPUFREQ_POLICY_UNKNOWN      XEN_CPUFREQ_POLICY_UNKNOWN
>  /*
>   * 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
> +#define CPUFREQ_POLICY_POWERSAVE    XEN_CPUFREQ_POLICY_POWERSAVE
> +#define CPUFREQ_POLICY_PERFORMANCE  XEN_CPUFREQ_POLICY_PERFORMANCE
> +/* Achieved only via xenpm XEN_SYSCTL_CPPC_SET_PRESET_BALANCE preset */
> +#define CPUFREQ_POLICY_BALANCE      XEN_CPUFREQ_POLICY_BALANCE

We don't need both sets of manifest constants, do we?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 10:39:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 10:39:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018097.1395014 (Exim 4.92)
	(envelope-from )
	id 1uRTjM-00085Q-Sq; Tue, 17 Jun 2025 10:39:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018097.1395014; Tue, 17 Jun 2025 10:39: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 1uRTjM-00085J-Pt; Tue, 17 Jun 2025 10:39:52 +0000
Received: by outflank-mailman (input) for mailman id 1018097;
 Tue, 17 Jun 2025 10:39: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 1uRTjL-000859-NG
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 10:39:51 +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 65abccca-4b67-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 12:39:51 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3a507e88b0aso5373908f8f.1
 for ; Tue, 17 Jun 2025 03:39:50 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-31421af1575sm2302169a91.39.2025.06.17.03.39.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Jun 2025 03:39:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 65abccca-4b67-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750156790; x=1750761590; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=PyQnQYz5V1+8Q8y/82lgC6LaO5G1+AGy3gkP0xeWvS0=;
        b=Yd6zZDLPTz49nLCBT7PQD1qExNTB/fxrApnJW+Ct+h0GYqyULaxKKpKSEQZ8UZ6zrN
         +K1XLEWO2HCxZct78vS9NkYc/Hf+S3jcdxxmhKXZqQhNNaHEgzITcSomPZ6ryiK1kh/Z
         NTqOxi0EhqNmsLXe5cD+y8tGYEca+CqRe0ItnJCp2NtRt+EBgDjppoWPrmk4Uy6ddtjX
         IUFTEsMT7Gt/9vZJ3ci7Bz1zAb1z9oQtIiesrLZ/+nmR26fhkBLxcgcPyXQ30bWAM5br
         2F7Lgcz4zR7kCJdGwVJlKl88xkFqxmqTDoTkdJvWsQBg+FqfGmXKG1oG1TS1SnhbLudK
         gvvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750156790; x=1750761590;
        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=PyQnQYz5V1+8Q8y/82lgC6LaO5G1+AGy3gkP0xeWvS0=;
        b=Cl3vYgdKTBGouuT6miWoJ+xKHddLpgtgFvZIV6Dk7uyemzpC7kb4GNSQH/00MYg+II
         buntY1wVh+71cDg/8jrmugH2JZYxp0erEU5R+KBZkmPTmwNv0QMZjaPeAFtbDMxrBpuh
         m8oIJvWlMt7mkrNl/9Tv3JV+prl+jQAY1G/G/2J0ACHJdKcj6H7COqjC8HvFgT/coHRR
         q+7N8BwEuRkgVYHSe7SHhnPQeLfulGMDbBsYhBznZbDgA//vDybvrCrzNh/0Hadm5AU5
         hnEF5A86DJleuNMnoqE2oawWNNY2QyJrSQPUjFQmqVtXTUSdNlsADr4CYAgEAs/MGckY
         FCAw==
X-Forwarded-Encrypted: i=1; AJvYcCUwn2VkPhXSWkOGNJExTQ9CL2fIGuseNzQqct7K/xMOv359ZVG8sENYQJKaqBXFRezDxbg9M5mCoT4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz+NPrDKXlG98I1bZaOXy6c27juf6A9l9TBq5gvz4nOcgyK78hr
	3fpBkAIvDzVxnftFQrjl/5gzQXF7yljYX3tGVB7ywZ8gp7jFCl2twfM+HdDnb7BaRg==
X-Gm-Gg: ASbGncu3q8YB02gxc1SWgaAI+0PxBsfGsTDyPDoQaBHEUg+sK04fJHZrSLA3DI3iqNF
	qsLMJBoMamdJXeTA+OPeRoKgrxe4W/mqTuUFnS7JoJr2ONnhcXhWCUhG+CSoIlLtocmU1bRMjg8
	QyVvOoWKOFnI2MLepu5oe8jrZd6cllknjGah458KjQgwX8GaVCVvbVATravwFa2fS4VmoHEGON0
	tIuNpdN/LtnFwLWRdCchgBj6/+fwEEjtKdDV7M6RozAhl41b56j3CNd7zSEQE+dR1TVwvr2IG9X
	VlEF3Mv1McpHuX4QNmnOwK95aIPOJbfv85eW4Y13oxlzSJJ9kyMupQjz57H9q7sYLXUT7+92CO9
	gprcaqERSQtDaX6puhbJSVIq9JYgQmbOYP5OhqcJgC6W3+24=
X-Google-Smtp-Source: AGHT+IFtEERDLhNIDdLOqPOqdiIEs9M9cQZqK+kxkeUyBlK7Tip+o5YfPkrhl1bxJpQDAx+ftsTGVg==
X-Received: by 2002:a05:6000:2dc3:b0:3a5:1240:6802 with SMTP id ffacd0b85a97d-3a572e58463mr10583089f8f.57.1750156790031;
        Tue, 17 Jun 2025 03:39:50 -0700 (PDT)
Message-ID: <73d66cbf-9b0c-475a-9e5e-0e5cd456c09e@suse.com>
Date: Tue, 17 Jun 2025 12:39:40 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 18/18] xen/cpufreq: Adapt SET/GET_CPUFREQ_CPPC
 xen_sysctl_pm_op for amd-cppc driver
To: Penny Zheng 
Cc: ray.huang@amd.com, Anthony PERARD ,
 Andrew Cooper ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-19-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: <20250527084833.338427-19-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.05.2025 10:48, Penny Zheng wrote:
> +int set_amd_cppc_para(struct cpufreq_policy *policy,
> +                      const struct xen_set_cppc_para *set_cppc)
> +{
> +    unsigned int cpu = policy->cpu;
> +    struct amd_cppc_drv_data *data = per_cpu(amd_cppc_drv_data, cpu);
> +    uint8_t max_perf, min_perf, des_perf = 0, epp;
> +
> +    if ( data == NULL )
> +        return -ENOENT;
> +
> +    /* Validate all parameters */
> +    if ( set_cppc->minimum > UINT8_MAX || set_cppc->maximum > UINT8_MAX ||
> +         set_cppc->desired > UINT8_MAX || set_cppc->energy_perf > UINT8_MAX )
> +        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 in MSR */
> +    if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_ACT_WINDOW )
> +        return -EOPNOTSUPP;
> +
> +    /* Return if there is nothing to do. */
> +    if ( set_cppc->set_params == 0 )
> +        return 0;
> +
> +    epp = per_cpu(epp_init, cpu);
> +    /*
> +     * Apply presets:
> +     * XEN_SYSCTL_CPPC_SET_DESIRED reflects whether desired perf is set, which
> +     * is also the flag to distinguish between passive mode and active mode.
> +     * When it is set, CPPC in passive mode, only
> +     * XEN_SYSCTL_CPPC_SET_PRESET_NONE could be chosen.
> +     * when it is not set, CPPC in active mode, three different profile
> +     * XEN_SYSCTL_CPPC_SET_PRESET_POWERSAVE/PERFORMANCE/BALANCE are provided,
> +     */
> +    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;
> +        policy->policy = CPUFREQ_POLICY_POWERSAVE;
> +        min_perf = data->caps.lowest_perf;
> +        /* Lower max frequency to lowest */
> +        max_perf = data->caps.lowest_perf;
> +        epp = CPPC_ENERGY_PERF_MAX_POWERSAVE;
> +        break;
> +
> +    case XEN_SYSCTL_CPPC_SET_PRESET_PERFORMANCE:
> +        if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_DESIRED )
> +            return -EINVAL;
> +        /* Increase idle frequency to highest */
> +        policy->policy = CPUFREQ_POLICY_PERFORMANCE;
> +        min_perf = data->caps.highest_perf;
> +        max_perf = data->caps.highest_perf;
> +        epp = CPPC_ENERGY_PERF_MAX_PERFORMANCE;
> +        break;
> +
> +    case XEN_SYSCTL_CPPC_SET_PRESET_BALANCE:
> +        if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_DESIRED )
> +            return -EINVAL;
> +        policy->policy = CPUFREQ_POLICY_BALANCE;
> +        min_perf = data->caps.lowest_perf;
> +        max_perf = data->caps.highest_perf;
> +        epp = CPPC_ENERGY_PERF_BALANCE;
> +        break;
> +
> +    case XEN_SYSCTL_CPPC_SET_PRESET_NONE:
> +        /*
> +         * In paasive mode, Xen governor is responsible for perfomance tuning.
> +         * we shall set lowest_perf with "lowest_nonlinear_perf" to ensure
> +         * governoring performance in P-states range.
> +         */
> +        min_perf = data->caps.lowest_nonlinear_perf;
> +        max_perf = data->caps.highest_perf;
> +        break;

Oh, also - can you really leave policy->policy unaltered here?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 10:42:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 10:42:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018108.1395025 (Exim 4.92)
	(envelope-from )
	id 1uRTlQ-0001RH-DD; Tue, 17 Jun 2025 10:42:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018108.1395025; Tue, 17 Jun 2025 10:42:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRTlQ-0001RA-Ad; Tue, 17 Jun 2025 10:42:00 +0000
Received: by outflank-mailman (input) for mailman id 1018108;
 Tue, 17 Jun 2025 10:41: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 1uRTlO-0001R4-UF
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 10:41:58 +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 b0691522-4b67-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 12:41:56 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a589d99963so380006f8f.1
 for ; Tue, 17 Jun 2025 03:41:56 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b2fe1639f97sm7167169a12.6.2025.06.17.03.41.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Jun 2025 03:41:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b0691522-4b67-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750156916; x=1750761716; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=9XVUbgTH5fUnqcfnCTzFYc/VmoaQkC1tHorq0Mjd8VM=;
        b=GYH9a/nhbOY3ybxeUoPuimcTRbxzqHm5tCvOlaiC1IGanet2dg6By4WY8avVEV4Q/3
         pqF7HI0bEj4+wyeS0TtTsDRZ0UIAC69zFX2NsN4FVKWosSbk8OiUmEa9f4IW2MLtFlV/
         DqcAcMnEl/ANHi2bw3sAyJdbnEzxpuYvOLjBAe/UTaHUaM3gpCtdtIjSeb7VHX60pSnX
         Mh334OQjZDdOPfm2A7za5+M2dL/Q8UGAQtumvPSvP+bS3IPgwDwMqGKzUJWQHLYYBn+B
         zsiQAyfsoFRqqxYAClsQnF3tl7bjCPxE+7wrLqrYlij+rl9NIHeTOd1Kl2vxHq8o/1mx
         UZ9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750156916; x=1750761716;
        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=9XVUbgTH5fUnqcfnCTzFYc/VmoaQkC1tHorq0Mjd8VM=;
        b=wCZjs8SHJ6cRRGvDCnle3nTqf6GDhTX6vXQg3H9PMNi5WOuqW/83g3MAKEj4FFOFqq
         3n7LOP//+bPsNuo3OHZI8qavRfs65+p4a/xu8h2Y8XECV+hmKO+uG3k12q4DrkHpJjL1
         EHZuMn0m/cYPvdzJSUBdTpBTHR3pd/qPtAh7Xx44YtwZXwT8Cas3AgUI5ye76cqDlY+E
         VQ/Ij1kzy0qbCPZbg+iGM8vZFdFOeMt/fuF+B98sT6o6MCPr8ReRI8HQGfuJv2b9K5HG
         B2LLBjYi/fh2oJKQNmnCOhcsowQAoa7mXyNno8gZBb/8EK0UJEHB3P+za4YuIk74O7PC
         r/eA==
X-Forwarded-Encrypted: i=1; AJvYcCXv/8hIZ9Pek/H7sCT8gKkvU9GQQvqorSAbchwEOwokqh8R/Vv1z2MnWXK4+08LnAMGfcncEW/2bmg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzsPCUAwUy1cpq1g7ymdJO4b8ZI9sDKYzXfhud+PCENmehEhZIn
	WOKupBc4uPPvqq1hslXgjQYRxxeOE0tiVSX50XMElBcHX7+cCpahKkVS41DsbZdCsQ==
X-Gm-Gg: ASbGnct2dxJnPR3KtThJlIJRFDwDSjgbhKEwV1XZaHB7NQN+V2QCWLDuDDvvnPyBfXR
	OOSZEaIDT+/I/qaI9J333U98NXZZ02+kqUptSq50b6l6iJN8kWeGyLzBlwsYpLgCS5A4PaGfkq+
	wiPQHwJ/Hk0zZms6TsyOmZ1yGi19Ss9+f7ZpsQtINrrN/PIWgbBKx538mK6OMhx80nmu9oQVfNB
	OIhFKfCPkqcMGSUM/kT1K0FHCy8Mpamva8yUCl84+aW2a5il4qBfP/mLn4Ddgru35c2HX5gM1+M
	GKigx+KWGTC5VsM1sJFmxJQkmT2YJT9iFd1xCUhyuZz6NXBx8kfmmAkrHiHY/2WLtXDqiUbKHdm
	0E+MU585uvGsRR2Vapl1jd6Eyd0McV8QEPpHeCe/vleSB8MY=
X-Google-Smtp-Source: AGHT+IFCaK459zifzsmsptsoG3CBxxqdMq4sLXCGh/9c3nnwuWy2HzxlGstBGysLCrq1pdOPnGpLwA==
X-Received: by 2002:a05:6000:2884:b0:3a4:dd8e:e16d with SMTP id ffacd0b85a97d-3a572373c1emr11332622f8f.15.1750156915699;
        Tue, 17 Jun 2025 03:41:55 -0700 (PDT)
Message-ID: 
Date: Tue, 17 Jun 2025 12:41:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 00/18] amd-cppc CPU Performance Scaling Driver
To: Penny Zheng 
Cc: ray.huang@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , Juergen Gross
 , xen-devel@lists.xenproject.org
References: <20250527084833.338427-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: <20250527084833.338427-1-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.05.2025 10:48, Penny Zheng wrote:
> amd-cppc 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_cppc driver has 2 operation modes: autonomous (active) mode,
> and non-autonomous (passive) mode. We register different CPUFreq driver
> for different modes, "amd-cppc" for passive mode and "amd-cppc-epp"
> for active mode.
> 
> The passive mode leverages common governors such as *ondemand*,
> *performance*, etc, to manage the performance tuning. While 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
> in hardware will automatically 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-cppc is enabled on passive mode with a top-level `cpufreq=amd-cppc` option,
> while users add extra `active` flag to select active mode.
> 
> With `cpufreq=amd-cppc,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      580000 KHz
>   Avg freq      580000 KHz
>   Avg freq      580000 KHz
> Setting CPU in performance mode
> Sampling and Outputs:
>   Avg freq      4640000 KHz
>   Avg freq      4220000 KHz
>   Avg freq      4640000 KHz
> 
> Penny Zheng (18):
>   xen/cpufreq: guard perf.states[] access with XEN_PX_INIT
>   xen/cpufreq: move "init" flag into common structure
>   xen/cpufreq: extract _PSD info from "struct xen_processor_performance"
>   xen/cpufreq: introduce new sub-hypercall to propagate CPPC data
>   xen/cpufreq: refactor cmdline "cpufreq=xxx"
>   xen/cpufreq: introduce "cpufreq=amd-cppc" xen cmdline
>   xen/cpufreq: disable px statistic info in amd-cppc mode
>   xen/cpu: Expand core frequency calculation for AMD Family 1Ah CPUs
>   xen/amd: introduce amd_process_freq() to get processor frequency
>   xen/cpufreq: introduce a new amd cppc driver for cpufreq scaling
>   xen/cpufreq: implement EPP support for the amd-cppc driver in active
>     mode
>   xen/cpufreq: get performance policy from governor set via xenpm
>   xen/cpufreq: normalize hwp driver check with hwp_active()
>   xen/cpufreq: introduce GET_CPUFREQ_CPPC sub-cmd
>   xen/cpufreq: bypass governor-related para for amd-cppc-epp
>   tools: drop "has_num" condition check for cppc mode
>   tools: optimize cpufreq average freq print
>   xen/cpufreq: Adapt SET/GET_CPUFREQ_CPPC xen_sysctl_pm_op for amd-cppc
>     driver

As indicated in individual replies, three of the patches may be possible to
go in before you re-post. Subject to what I said in the replies (patches 02,
08, and 13). Please clarify what (if anything) to do.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 11:08:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 11:08:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018115.1395036 (Exim 4.92)
	(envelope-from )
	id 1uRUAq-0004bz-Ek; Tue, 17 Jun 2025 11:08:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018115.1395036; Tue, 17 Jun 2025 11:08:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRUAq-0004bs-AO; Tue, 17 Jun 2025 11:08:16 +0000
Received: by outflank-mailman (input) for mailman id 1018115;
 Tue, 17 Jun 2025 11:08: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 1uRUAp-0004bm-D6
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 11:08:15 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20628.outbound.protection.outlook.com
 [2a01:111:f403:200a::628])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5c3fc548-4b6b-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 13:08:13 +0200 (CEST)
Received: from SA9PR13CA0093.namprd13.prod.outlook.com (2603:10b6:806:24::8)
 by LV2PR12MB5871.namprd12.prod.outlook.com (2603:10b6:408:174::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Tue, 17 Jun
 2025 11:08:09 +0000
Received: from SN1PEPF0002529D.namprd05.prod.outlook.com
 (2603:10b6:806:24:cafe::7b) by SA9PR13CA0093.outlook.office365.com
 (2603:10b6:806:24::8) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.19 via Frontend Transport; Tue,
 17 Jun 2025 11:08:09 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF0002529D.mail.protection.outlook.com (10.167.242.4) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Tue, 17 Jun 2025 11:08:08 +0000
Received: from xcbagarciav01.xilinx.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, 17 Jun
 2025 06:08:05 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5c3fc548-4b6b-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=dMvGCeL5li0+J2E3W+rmcwPQTuHi/wRb3GcNNIjbIWxrWGxT8TyKmiuHl478VhOjgSuZ3nKQPdia7/Gf42vxu/OIlWVtQWhzUQMF0o9zmvkakpGjgWLAnoKH4ckqMIjiI04s+OD0HTnCaknb3814tJwqwzJDkDDOcVBSrCcyjZj0Rvpz8IXcSM9buxRq8YV9PT/bE6tC+qK9xk6swfp4fAN7e2E/XJeMsiZimTBX/aqtTtu0/8HxXcH6k3lmN5QZiemI91lsVuOnN5EfpDTVdGVY2BGbeh6X/YrYzmdWJwTA8kDWci0KNSU53jkHA8KZ2UAfALdBfN7GxFhF75rkag==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=uNYUIHXWtbZjevhX/1UeT4Xuly3MaAkGOlEVEfaYe3w=;
 b=Xhxdy7gO3FINJ7fx9R7ASoTRmdB2xO8VZyDwFkCZC8RvjH7APVOYJkurZEpRvOXnCToJRx+p520RqHNH0JbIyPduG51KmTEpff4QDHnvSw4xCK84+IOyxVUgABnRBDckceCzCUOXkAijWHRQ1TRULtKtAcy/BUHT141k1NhJsImWcJOt0CcRhB2S1HuDw6bkrG1W7lELcS3DkyRrzgIVvqgG4eLcB1wPZwAoWxk2W7pA30E1QRyfjb56WEcoqY0HyVKjjnyTsaMsloTu6P9hKDSTzCs+h7nQrusYAX5IkF2sCiBm16EayAk7tmBoMNNzTpntAsESkJOOKrXw5SNxcA==
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=uNYUIHXWtbZjevhX/1UeT4Xuly3MaAkGOlEVEfaYe3w=;
 b=LEx+cKrLnzY8goeZciLsYQUsW57r9VIbMoqNgFPAGUKJ65JM4vx/1ZhSUP1KZwt8qKpggdvPg2TRGLizPYYjj7eYn4hcd5PJ9xGq1KW5zuQoz9H9CBGSzOV/AtXQcYfrFN7jHLztdAjT5Oz4C34gOiDDryjUYgfMJZA/Ctq3dZs=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Daniel P .
 Smith " 
Subject: [PATCH] xen/dt: Remove loop in dt_read_number()
Date: Tue, 17 Jun 2025 13:07:40 +0200
Message-ID: <20250617110741.34648-1-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: 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: SN1PEPF0002529D:EE_|LV2PR12MB5871:EE_
X-MS-Office365-Filtering-Correlation-Id: aea6fb25-62be-48d2-0f7e-08ddad8f3dc2
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?oeODxL7zyRB+CNHhF77j08Ak88tLSYZwbiyjzuOVj3fond2G7Edmwtkceu31?=
 =?us-ascii?Q?MnbO2o/cn6Yol+qKvLlF/Bnx+VhfCVAjgY5baDWQN10w/CqztNJcpKehyqvz?=
 =?us-ascii?Q?5Mcg7+x0uwJzr+17AaO9ZRW1/BJOQRflq0m3e2Jtm+qY2JQKEEvMXCIpr9OT?=
 =?us-ascii?Q?mZ1DhcLhpKhlnY/VkTXzMmGluP2bnL96/lyz5WRJlRNNOb5p55OE7ROaBcbg?=
 =?us-ascii?Q?8FWLQWtbInEKzXklUQvpJqnfRsgHf48Q8AUFeN5dH1UDhCXzEVF27KPFaeR3?=
 =?us-ascii?Q?S97aysFzxw9nKKuoTY3iRv+XTPbWfDoQr3Mx7nZTjpo6r9WfCD0C8C0b9wMB?=
 =?us-ascii?Q?MB1gGvS9DadSuyQ3NX1YzKhm3xk7UliyXLcRdvSvre5LeK7D8iUhd5gP4610?=
 =?us-ascii?Q?S2CgBfSq4Z1/r35t4821EIOc0hf8UI99N3RKweeHC4RyC10KOqkYZR4x5z3D?=
 =?us-ascii?Q?wOZ77hFzeVJhWJyxVIZsFg1RKCS/FjHFm8lKo9rCg7zodrgQuMe4GZpDOfq9?=
 =?us-ascii?Q?AolT0xTd5x1zbW5AjiMb8EIyZPG1G0HZnvNgfjTbDljfyFvfK/bYpBZa9b/Y?=
 =?us-ascii?Q?ymS8P/veTlC+Ppf41pfVJwaKzU0kyrElyJDP6E1fNMqeZ9jN8opv7tLP74M5?=
 =?us-ascii?Q?QNlFD0junm36Ald6yUi+sUf3RwhEH/0s+N8tpwitWH7EvRY1TF5GYsRRc2yP?=
 =?us-ascii?Q?CUmuSt/Z5i2IL4nGmv74yj5T85IB8LfjwjbiTAVfwczbx2p7W7GkHQ1uXar0?=
 =?us-ascii?Q?YgGQBMnyg5qbjytHtSqF5vdEpAXLSrSxeNUyhStc/tHIhqfs3SPPeKPalAMc?=
 =?us-ascii?Q?eJHrbb+HRgQF36B6+ysS7LbG7MlYXKjYiC+Lf+N1K/50fRR0oYWOTcL1HLMe?=
 =?us-ascii?Q?90ze6E5rM3L2XQWgHqNZAxX+X9bgVVI1eSiEIGPSMpkqkW1PMYixHWO1YtZt?=
 =?us-ascii?Q?M/03q1J/k9Z+B8os7ivgO/oKg7OZzCEKiips5pe0F9Y5HCoVFH3UpUcvWlx4?=
 =?us-ascii?Q?bWT10bsdBtdpeAIPSspA9I11Fzd8HsKZuv6TfDpu1U42I5K0fcLEN5p+XJtV?=
 =?us-ascii?Q?2pdXn7G/jq/nO50hNyB1cun75kOr4VSCfztESXm7KPL/H5v1ENlFijMRPjNM?=
 =?us-ascii?Q?3QKbJtnQNP2mTLRSMAbo9/Cn7lx9ffRGlg0p62R9DOoXkJjoRuDGamEL8JBC?=
 =?us-ascii?Q?HRxXuJ7GI5cXSQVBatkzFOzIAMte/Xifap8nvIROPXfdiImat05UAwExmlpO?=
 =?us-ascii?Q?zsc15EGLvG1YpxpkRAmK+MGQG4jQoG41+ltAV9fGUZAv+G1YZDTxr9APWnZ3?=
 =?us-ascii?Q?YSk6zoD+A0jrn1StqYk5qPltyhi/5TWCLmAf6r+rrB0IQygt7uJO96YX1kHI?=
 =?us-ascii?Q?QLdgNPbQez6GkLlMcW/oa4kACeIUzIIFcXnvQxONU/SQTxPEIRIZc9U1f4IW?=
 =?us-ascii?Q?5UZgP9OsXaelHzuOosMXUVl2l+iXvQZUFYua14lrlnuIf9YTWMRzAQvuUrPz?=
 =?us-ascii?Q?LitZMH3pVx47fMz9Et3nKL31inSFUgS+Cdf9?=
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: 17 Jun 2025 11:08:08.3896
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: aea6fb25-62be-48d2-0f7e-08ddad8f3dc2
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:
	SN1PEPF0002529D.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV2PR12MB5871

The DT spec declares only two number types for a property: u32 and u64,
as per Table 2.3 in Section 2.2.4. Remove unbounded loop and replace
with a switch statement. Default to a size of 1 cell in the nonsensical
size case, with a warning printed on the Xen console.

Suggested-by: Daniel P. Smith" 
Signed-off-by: Alejandro Vallejo 
---
Based on this suggestion by Daniel:

    https://lore.kernel.org/xen-devel/a66c11c4-cfac-4934-b1f5-e07c728db8de@apertussolutions.com/

I'd be happier panicking there, seeing how DTs are by their very nature
trusted blobs. But I suspect defaulting to something will find less
resistance in review. I don't care much either way.
---
 xen/include/xen/device_tree.h | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 75017e4266..2daef8659e 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -261,10 +261,19 @@ void intc_dt_preinit(void);
 /* Helper to read a big number; size is in cells (not bytes) */
 static inline u64 dt_read_number(const __be32 *cell, int size)
 {
-    u64 r = 0;
+    u64 r = be32_to_cpu(*cell);
+
+    switch ( size )
+    {
+    case 1:
+        break;
+    case 2:
+        r = (r << 32) | be32_to_cpu(cell[1]);
+    default:
+        // Nonsensical size. default to 1.
+        printk(XENLOG_WARNING "dt_read_number(%d) bad size", size);
+    };
 
-    while ( size-- )
-        r = (r << 32) | be32_to_cpu(*(cell++));
     return r;
 }
 

base-commit: 14c57887f36937c1deb9eeca852c3a7595d2d0b8
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 17 11:13:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 11:13:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018122.1395051 (Exim 4.92)
	(envelope-from )
	id 1uRUFW-0006Mn-8L; Tue, 17 Jun 2025 11:13:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018122.1395051; Tue, 17 Jun 2025 11:13: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 1uRUFW-0006Ll-1d; Tue, 17 Jun 2025 11:13:06 +0000
Received: by outflank-mailman (input) for mailman id 1018122;
 Tue, 17 Jun 2025 11:13: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 1uRUFU-0006Jw-W9
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 11:13:04 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on2061c.outbound.protection.outlook.com
 [2a01:111:f403:2418::61c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 08d2bcd5-4b6c-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 13:13:04 +0200 (CEST)
Received: from PH7PR10CA0011.namprd10.prod.outlook.com (2603:10b6:510:23d::12)
 by SJ0PR12MB6902.namprd12.prod.outlook.com (2603:10b6:a03:484::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Tue, 17 Jun
 2025 11:12:57 +0000
Received: from SJ1PEPF000023D8.namprd21.prod.outlook.com
 (2603:10b6:510:23d:cafe::a3) by PH7PR10CA0011.outlook.office365.com
 (2603:10b6:510:23d::12) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.28 via Frontend Transport; Tue,
 17 Jun 2025 11:12:56 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ1PEPF000023D8.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.8880.0 via Frontend Transport; Tue, 17 Jun 2025 11:12:55 +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, 17 Jun
 2025 06:12:55 -0500
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, 17 Jun
 2025 06:12:54 -0500
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; Tue, 17 Jun 2025 06:12:53 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 08d2bcd5-4b6c-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ThxhpZ4SDkM0Jk5OcwpOIKTNmtCMRkij5M49TEzwqrA3K+a8KAAuKYI1/dR6FnpR678QjMm7udPIV4K0aWT7dcHX3q/MY8mbI1zpppx4vkY6isBgRHgFeza+HS+AeARkm6wPx15oxzaC+iEU+20SzWk/+24DBtGdmnlX0mwIbEWB6Riys3zJI1JSyB/M68TMgwHttAUIo104VJZeKA2We3tQwe/jMaXDNNHUrtq9CigFsoFe3HjxAORCkIg2X8tmQ63BFivAPhXWKeB4Si/tNX+VcZ5JQsngCjE1jL6Vhl+ar4NzuVx34IwcXJkr7713alHrgMcDCUcEuJ6tycU4Lg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=T1/wMALtMDqzv1qV3h0JNM+GXkFFx8YFBARFPB/TzdM=;
 b=vmfven9ay7BTZ0r+8E91gdNamFYfsEdV6KOn/PG/GGgXaoUqGqzymQwIhCtGkJJBfsdsUrcuPhJQd9BbklV2uysauzMTN9HaNmaPrlDQOBUMn9wrxc/cDMyTit/mn3pO8YiGsZYn5sBzWIYMTf+f28gm8qO8V7Z7/KVyppbTpI6h8ADT/bhyITS4krO1caJlGROi6NSaXod7pAZRE8K6aXVQS6jNt4XVoCz2vwqCQC7ars4rJbUmC3GwLWV7GcdXcCLY6W/aEBh3qCoqAMxGL3ZqZiQw0E7fSZs5Yvsrb1zV86Uvc71QMXotKnTji+EJ+8g58o9bGMVN4n9c5tgVXg==
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=T1/wMALtMDqzv1qV3h0JNM+GXkFFx8YFBARFPB/TzdM=;
 b=Tqg3HUhSKqAJ5Od5kvQH9C2Pybz0sYJuq6lzCBkc53JH7EdvOmBq2c7UO8er7iF5MLjKRvw+dNSC9z3ZCbroBed1v+2QBD0lqLPlEmVpW0UUDPLB5FOBMRKLNFhm1NEmW1QJMI4oof3b+q11xc5GKE6QLYZzRqGcncPJLPr8vBo=
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 ,
	Hari Limaye 
Subject: [PATCH v4 0/3] Enable R52 support for the first chunk of MPU support
Date: Tue, 17 Jun 2025 12:12:48 +0100
Message-ID: <20250617111251.1711553-1-ayan.kumar.halder@amd.com>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF000023D8:EE_|SJ0PR12MB6902:EE_
X-MS-Office365-Filtering-Correlation-Id: 860d46a1-9a56-4ac3-2b15-08ddad8fe932
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?EwGdOXJx5GF/N3WxEu0TfPM3c8td0Ji7shbPny8fWfFTYaMM+OJFeci8XhIG?=
 =?us-ascii?Q?JnkEa6fOzVcvo7fG0kINBX/AIB/3QFjBgeTLqnkTDYqq99xUMGH9GBLVT3rv?=
 =?us-ascii?Q?qDD8UoPoa3saKFY7AvPxpSPj0yLZXLN8fO8Bbxw9rJf8ZRiHm/uPoYs2QtW8?=
 =?us-ascii?Q?e7EmidEQiyUodhSMPxV30lUVuopU0+//AWZvufFLpvcqOHrK1BVqHA5z+gGO?=
 =?us-ascii?Q?W54TEH1qTBM0Swun4nm9WsNCbRvtJwZvRXisHU8Pb2Zx3Qfr1FyFhD/AlzNb?=
 =?us-ascii?Q?Uwq+jIcpRFMB0DUPfBi2T8QuX2Cae+H2syzfGMdNTQm7WtX01r8Kw63t4ThT?=
 =?us-ascii?Q?8Bv1rMfGvZ0nYylz4brpGOZbyuXYTEsuvurXtYYo8KgqanB6IyukEFwyf+wM?=
 =?us-ascii?Q?zX/tK9xN/J6Wy640mvF40TZ9IAxJTc+bmsULGPbLYJ/tbxI/afj8ZxgJb+G/?=
 =?us-ascii?Q?AajXykED6C8iFhEqzje67dwPVrvz8oMplnG9eD/1ITq6RqvKKIs+b2koSKA2?=
 =?us-ascii?Q?Y3Xs1ZGH/VDQl+EDLVhA2ijxRehBXnaPOb25JcDXieeY9n5oD+/dahjZ4W9B?=
 =?us-ascii?Q?C9Of3zfhg+EfkKJ+p9QuDIOkH8yDUfHYlA1kgOyZmUrZfIJ0LGzkDh36/DL3?=
 =?us-ascii?Q?Yr++nLrmzEgf/KWMAEjeFdwy78PMbN6Ki1SZtxc1zkcWuLos0G0QFMQH1QuC?=
 =?us-ascii?Q?GIuwFF+yyKfI4iOUna1WrjLBRRpt51BDgtAUZEEKq8vH6UQEjcFh75FVmuO8?=
 =?us-ascii?Q?NeKphZsTHcWFXe2M8DbmC7hOGtWAUozzvVvG7hlQq3sZR1mrDrhlC0I/zXdj?=
 =?us-ascii?Q?tcm9cxNlyzD+SG3HWFnp8HGXQwYmoYvDdIcMUCrDQ6P7N3szoI2vWGUsw+2J?=
 =?us-ascii?Q?UbOCwoV1OuFB9SUkEDmpIu6m+CL7awIXLaUCvVp+tyOJUqBXh/2I4F7JUahQ?=
 =?us-ascii?Q?rRAx4a1sezWyK2R/ESJu86O+DDdKl0XfvvmUr1A5bgNkUh6PgdTZsTLIwnW6?=
 =?us-ascii?Q?3v78JTHKkFmuNAppGDkO6rc18H2VF2KNwIeKCC6V1Pr2dyNoVY9PCBtdOnMR?=
 =?us-ascii?Q?1n3m4yTNu9xQvRvN3aa95YruMkNzJFCX6oD0cY8ZpTQen4dYH5Jc0pZQ5roU?=
 =?us-ascii?Q?Atq+kjD/1K1A84by5eqerqhTSLPnPNp/i8bkJn5H/ZaiKjBsYgZhBiXeXhY9?=
 =?us-ascii?Q?jwdywbJNIQI79gGmrehnxJahstlyA0sjYX+UtpAig5wZCa95ASaTKqhTkRb8?=
 =?us-ascii?Q?Z3TVqKenXqJIuz5yqQBC5luORXDksUX3iy8wvoI7jdE/LskZReLZuTI3mxDi?=
 =?us-ascii?Q?lIiU1kb7cGCFsCfX5fWXhqjeony/rY48jW1kWkMFxST1cEtS4hza07jYjBND?=
 =?us-ascii?Q?ZqHkmf9iTBNFBA/LsAH9z12tlDbVogz6NdtBuUY3/iUvmlVpFVSYVuQw9jo6?=
 =?us-ascii?Q?B9IpG1wq19tkk8xmugtA2Mnqs3KcGSOgkwyNM7aqerQEVS1VkfM9mrEgnz5n?=
 =?us-ascii?Q?5iRUovELjV6lLOoD1GIYCjaVbLOhDdsJhSgN?=
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: 17 Jun 2025 11:12:55.9445
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 860d46a1-9a56-4ac3-2b15-08ddad8fe932
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:
	SJ1PEPF000023D8.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB6902

Hi all,

This patch serie enables R52 support based on Luca's series.
"[PATCH v6 0/6] First chunk for Arm R82 and MPU support".

Changes from :-

v1 - Changes mentioned in individual patches

v2 - Split "arm/mpu: Provide access to the MPU region from the C code"
into 4 patches.

v3 - Patches 1,2 are merged. Patch 3 is dropped.

Ayan Kumar Halder (3):
  arm/mpu: Move the functions to arm64 specific files
  arm/mpu: Define arm32 system registers
  arm/mpu: Enable read/write to protection regions for arm32

 xen/arch/arm/include/asm/mpu.h        |   2 -
 xen/arch/arm/include/asm/mpu/cpregs.h |  68 ++++++++++-
 xen/arch/arm/mpu/Makefile             |   2 +
 xen/arch/arm/mpu/arm32/Makefile       |   1 +
 xen/arch/arm/mpu/arm32/mm.c           | 164 ++++++++++++++++++++++++++
 xen/arch/arm/mpu/arm64/Makefile       |   1 +
 xen/arch/arm/mpu/arm64/mm.c           | 130 ++++++++++++++++++++
 xen/arch/arm/mpu/mm.c                 | 119 -------------------
 8 files changed, 365 insertions(+), 122 deletions(-)
 create mode 100644 xen/arch/arm/mpu/arm32/Makefile
 create mode 100644 xen/arch/arm/mpu/arm32/mm.c
 create mode 100644 xen/arch/arm/mpu/arm64/Makefile
 create mode 100644 xen/arch/arm/mpu/arm64/mm.c

-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Tue Jun 17 11:13:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 11:13:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018121.1395045 (Exim 4.92)
	(envelope-from )
	id 1uRUFV-0006KE-Uo; Tue, 17 Jun 2025 11:13:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018121.1395045; Tue, 17 Jun 2025 11:13: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 1uRUFV-0006K7-SB; Tue, 17 Jun 2025 11:13:05 +0000
Received: by outflank-mailman (input) for mailman id 1018121;
 Tue, 17 Jun 2025 11:13: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 1uRUFU-0006Jw-AF
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 11:13:04 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20602.outbound.protection.outlook.com
 [2a01:111:f403:2408::602])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 086b85ec-4b6c-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 13:13:02 +0200 (CEST)
Received: from PH1PEPF000132F9.NAMP220.PROD.OUTLOOK.COM (2603:10b6:518:1::2a)
 by SA1PR12MB7173.namprd12.prod.outlook.com (2603:10b6:806:2b4::5)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.23; Tue, 17 Jun
 2025 11:12:59 +0000
Received: from SJ1PEPF000023D4.namprd21.prod.outlook.com
 (2a01:111:f403:c902::13) by PH1PEPF000132F9.outlook.office365.com
 (2603:1036:903:47::3) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.23 via Frontend Transport; Tue,
 17 Jun 2025 11:12:59 +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.8880.0 via Frontend Transport; Tue, 17 Jun 2025 11:12:58 +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, 17 Jun
 2025 06:12:57 -0500
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, 17 Jun
 2025 06:12:57 -0500
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; Tue, 17 Jun 2025 06:12:56 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 086b85ec-4b6c-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=yO3GCub3QsUMhc+mPJqheCpPm6lgf9zbIXsoSxTJKZSrz8lOTz4ws5btZkugKNw0j4VQQLt5Q8q08i7if5kR3zibyiYgOCBR6wnnmtKom2G03qObanivN7mrXmUAJ6Bv128jnCfqaNy80ylV6qZfhhPfXNhfTziHBOawNoPiiHzXar7tFvryZir91jTU8gz2qjLpzFnxFr/qf4aF/8OL7tz5KIUal/qO4vE+O4yF3/bypeGWVu+27NfT5HTLnydGDxoEYQueAUjXLKZp+7wsZZh3RyVDTnovuzgQvt/33Xwrx2ZgBf2ZlxaFgeqQscCfO3ZX5utgHFWlTvdKwmPc+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=iTsKhPMFekwFkA5dxGfoQy5FLg3/1ViS8KSn6edb4tE=;
 b=nthiiLGNV0QXydZD2b6tzh6EU27+IFTdDhRtz+G2cDDW86OtblcliTPp2HpfCER7FpFM7pBjgdhSYmNPD5bgsSA+G1gGcck8pg/sxOMUpnec6B7VaQHyLjSD6Wdc++7+HRHbQ9LtdpdDHpb3XFTXC18RSDmlaIYnCuAdnDs/EYQcRoDcd9LvQf6HCoSa0ArdYhl5pg9rda1OEs48YhXlaSgZpRticMNyZu8oRCXZ/sWjy1Y4eQmov2DRWCftmvD2Dylps2l6jbNmG/Js4BuGIYymHmL+RDNboUTDjdh2tOFQx2QhTQHGholVy1Rwz7KSoHDjBRTaItK9rmAZxfzLeg==
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=iTsKhPMFekwFkA5dxGfoQy5FLg3/1ViS8KSn6edb4tE=;
 b=l6Y3oNg3Vz+GbHLRdGphAoaIRcJJEph25O8uqqaFfLPrX9fwCxcfqPHwGO389twi33uOTamHeHhyocv7dXP0xXtR1WIbMjh6CQXhcHoBoPda2YgwDZB9jNbhlJUhku/Wuj1jXEobBeakq9cpS6FQKod6o8PG3Bpc+U4XiRXi98w=
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 ,
	Hari Limaye 
Subject: [PATCH v4 1/3] arm/mpu: Move the functions to arm64 specific files
Date: Tue, 17 Jun 2025 12:12:49 +0100
Message-ID: <20250617111251.1711553-2-ayan.kumar.halder@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20250617111251.1711553-1-ayan.kumar.halder@amd.com>
References: <20250617111251.1711553-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: SJ1PEPF000023D4:EE_|SA1PR12MB7173:EE_
X-MS-Office365-Filtering-Correlation-Id: eaa5714d-c6fa-46c9-53d3-08ddad8fead1
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?xyHy4SWlKlLRLzrVEh5h/oyfiHtveONkE7kE3+/509tE9kXQfwITbIl5ytaZ?=
 =?us-ascii?Q?pFFhSr8tVxUp9lGZn36NJlW46+QwW5O7yQeBfjBGAKR+FXIEwFj/xomPi/gu?=
 =?us-ascii?Q?1hReoC00oUFJMNTJHzlUIcw+yxW4ogzC8z9C0UQ/7PpVQ080AbyW0mDUH0sO?=
 =?us-ascii?Q?IFGfe0SjGwCXGO54pD6EeAThn3ngp2XBhHhgcClRWSXdeXXE7tED9JzFxAeS?=
 =?us-ascii?Q?GzERUOgbNAueFnbwOpssBZ3wgScaDAtxN/F1Vqa2NIxIjZ6s+h4BtChxSN0s?=
 =?us-ascii?Q?xnlIE7xLDohSkpe8tIdpfLdt0b4akJUyRHhz5QAe2ivGR9cwHAFukB6UmKev?=
 =?us-ascii?Q?u/4wFOTU+NGhbKIJpkKUeUMVEGjQt4eRden2LKpLdz2CfPlRNAwOgGuF4mOA?=
 =?us-ascii?Q?c33r63RJk1XDrAsRH/76Tr5SmBEUS3qHgW5XErb+OL4u3jC1PDSOCliXGSYN?=
 =?us-ascii?Q?xWf1KojbDsmWdfak4ohNZeVRsZvfdhWZM9id7Afjqf0nrMuWbDuvP2RFPl0A?=
 =?us-ascii?Q?rPvzvkCCv24Qf8zAIIQjsJC6McVMkGAZ8VM8ZdY6s0vaPzM2titMkxnyqu4b?=
 =?us-ascii?Q?+Vh654oCczQ8+fW1umDPrSP8TMs56CV0stIY9bzIkzO1rnxVl8cz1+RiouUM?=
 =?us-ascii?Q?mMyxTkINo3uoIw5DPdlVwE5Nn4jyAQfqCVqM7KeHrUy4DTAFmpisYgohv+97?=
 =?us-ascii?Q?ufIms9ZmvwWVLH8BbExZrjZIjBWa+4dpGF+XSU526B0L4ea3FIcdDFEu1LIS?=
 =?us-ascii?Q?/Yy71fFqNvKVRhQx/jrM3rjlY86k6qDIVeK+NkczoSA4AyX8+BLgZyly6rMv?=
 =?us-ascii?Q?lRNgwFHJ2nXMIaJY8DcQTzR6/tCvcSIeDeWdQKzb1miZWMeyfqdJAEhs5HeJ?=
 =?us-ascii?Q?YxauCvWhGEDUP6JVDkvBuwQezhyzzi2qIyHaWYbnouwQZNCPFED5iwZ4uV/Y?=
 =?us-ascii?Q?7dFx5cPfPII00LvB6eWbYl6h3n9lI0NmsJJ7xcFYB2bsgXr5ema9R1KEaMX6?=
 =?us-ascii?Q?fnsbaGyZec57RpDXMBRb89uYtElxWWq6664WZli6+MdxnNPxnAxFZxf9CqsN?=
 =?us-ascii?Q?h3csx3bYdT//O9hWNJnxV2TuezfrxYebz6lK+nJhDy/PLVnH56Zxl7ypYGhH?=
 =?us-ascii?Q?HNNKqWW1xzl5HIhZlINaolksn/F7nxcEWsbYJ8xU+BG/xjhPyZW9Ck7cNBLj?=
 =?us-ascii?Q?23vS+3nENIM4gGfvLxBUGyzihF0WPm1xXQgM4loaGxo/wYaSy1DEbhmM8YDp?=
 =?us-ascii?Q?uieGGH0/W7BkpP1eLpNev0d1aeBsNlpBvMwiPRjDSXrJzE/hKIvg5KUOC0D7?=
 =?us-ascii?Q?/T2ayl7He6rnTfkxS3n/eYRmZ8H+DHD/wsVirVHIeKZtj1gpl9x7I4Ip4r65?=
 =?us-ascii?Q?0J+riIAGME8n9gKDWMxxCuSVduvZ90jr+ejNZep7cIJExsODuTZsecw5hirq?=
 =?us-ascii?Q?mUhoSrUBf1Bwo0aiQUlCkds+J8wBGYV1J1B6Q4bADSF3M18XxNAO7KMFuCx6?=
 =?us-ascii?Q?LEQqA1rQVnddUX7XTIC09qdCYj25dn+8DTsr?=
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: 17 Jun 2025 11:12:58.6657
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: eaa5714d-c6fa-46c9-53d3-08ddad8fead1
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: SA1PR12MB7173

prepare_selector(), read_protection_region() and write_protection_region()
differ significantly between arm32 and arm64. Thus, move these functions
to their sub-arch specific folder.

Also the macro GENERATE_{WRITE/READ}_PR_REG_CASE are moved, in order to
keep them in the same file of their usage and improve readability.

Signed-off-by: Ayan Kumar Halder 
Reviewed-by: Luca Fancellu 
---
Changes from -

v2 - New patch introduced in v3.

v3 - 1. Add Luca's R-b.

 xen/arch/arm/mpu/Makefile       |   1 +
 xen/arch/arm/mpu/arm64/Makefile |   1 +
 xen/arch/arm/mpu/arm64/mm.c     | 130 ++++++++++++++++++++++++++++++++
 xen/arch/arm/mpu/mm.c           | 117 ----------------------------
 4 files changed, 132 insertions(+), 117 deletions(-)
 create mode 100644 xen/arch/arm/mpu/arm64/Makefile
 create mode 100644 xen/arch/arm/mpu/arm64/mm.c

diff --git a/xen/arch/arm/mpu/Makefile b/xen/arch/arm/mpu/Makefile
index 808e3e2cb3..5ad15e93be 100644
--- a/xen/arch/arm/mpu/Makefile
+++ b/xen/arch/arm/mpu/Makefile
@@ -1,4 +1,5 @@
 obj-$(CONFIG_ARM_32) += domain-page.o
+obj-$(CONFIG_ARM_64) += arm64/
 obj-y += mm.o
 obj-y += p2m.o
 obj-y += setup.init.o
diff --git a/xen/arch/arm/mpu/arm64/Makefile b/xen/arch/arm/mpu/arm64/Makefile
new file mode 100644
index 0000000000..b18cec4836
--- /dev/null
+++ b/xen/arch/arm/mpu/arm64/Makefile
@@ -0,0 +1 @@
+obj-y += mm.o
diff --git a/xen/arch/arm/mpu/arm64/mm.c b/xen/arch/arm/mpu/arm64/mm.c
new file mode 100644
index 0000000000..ed643cad40
--- /dev/null
+++ b/xen/arch/arm/mpu/arm64/mm.c
@@ -0,0 +1,130 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * The following are needed for the cases: GENERATE_WRITE_PR_REG_CASE
+ * and GENERATE_READ_PR_REG_CASE with num==0
+ */
+#define PRBAR0_EL2 PRBAR_EL2
+#define PRLAR0_EL2 PRLAR_EL2
+
+#define PRBAR_EL2_(n)   PRBAR##n##_EL2
+#define PRLAR_EL2_(n)   PRLAR##n##_EL2
+
+#define GENERATE_WRITE_PR_REG_CASE(num, pr)                                 \
+    case num:                                                               \
+    {                                                                       \
+        WRITE_SYSREG(pr->prbar.bits & ~MPU_REGION_RES0, PRBAR_EL2_(num));   \
+        WRITE_SYSREG(pr->prlar.bits & ~MPU_REGION_RES0, PRLAR_EL2_(num));   \
+        break;                                                              \
+    }
+
+#define GENERATE_READ_PR_REG_CASE(num, pr)                      \
+    case num:                                                   \
+    {                                                           \
+        pr->prbar.bits = READ_SYSREG(PRBAR_EL2_(num));          \
+        pr->prlar.bits = READ_SYSREG(PRLAR_EL2_(num));          \
+        break;                                                  \
+    }
+
+/*
+ * Armv8-R supports direct access and indirect access to the MPU regions through
+ * registers:
+ *  - indirect access involves changing the MPU region selector, issuing an isb
+ *    barrier and accessing the selected region through specific registers
+ *  - direct access involves accessing specific registers that point to
+ *    specific MPU regions, without changing the selector, avoiding the use of
+ *    a barrier.
+ * For Arm64 the PR{B,L}AR_ELx (for n=0) and PR{B,L}AR_ELx (for n=1..15) are
+ * used for the direct access to the regions selected by
+ * PRSELR_EL2.REGION<7:4>:n, so 16 regions can be directly accessed when the
+ * selector is a multiple of 16, giving access to all the supported memory
+ * regions.
+ */
+static void prepare_selector(uint8_t *sel)
+{
+    uint8_t cur_sel = *sel;
+
+    /*
+     * {read,write}_protection_region works using the direct access to the 0..15
+     * regions, so in order to save the isb() overhead, change the PRSELR_EL2
+     * only when needed, so when the upper 4 bits of the selector will change.
+     */
+    cur_sel &= 0xF0U;
+    if ( READ_SYSREG(PRSELR_EL2) != cur_sel )
+    {
+        WRITE_SYSREG(cur_sel, PRSELR_EL2);
+        isb();
+    }
+    *sel &= 0xFU;
+}
+
+void read_protection_region(pr_t *pr_read, uint8_t sel)
+{
+    prepare_selector(&sel);
+
+    switch ( sel )
+    {
+        GENERATE_READ_PR_REG_CASE(0, pr_read);
+        GENERATE_READ_PR_REG_CASE(1, pr_read);
+        GENERATE_READ_PR_REG_CASE(2, pr_read);
+        GENERATE_READ_PR_REG_CASE(3, pr_read);
+        GENERATE_READ_PR_REG_CASE(4, pr_read);
+        GENERATE_READ_PR_REG_CASE(5, pr_read);
+        GENERATE_READ_PR_REG_CASE(6, pr_read);
+        GENERATE_READ_PR_REG_CASE(7, pr_read);
+        GENERATE_READ_PR_REG_CASE(8, pr_read);
+        GENERATE_READ_PR_REG_CASE(9, pr_read);
+        GENERATE_READ_PR_REG_CASE(10, pr_read);
+        GENERATE_READ_PR_REG_CASE(11, pr_read);
+        GENERATE_READ_PR_REG_CASE(12, pr_read);
+        GENERATE_READ_PR_REG_CASE(13, pr_read);
+        GENERATE_READ_PR_REG_CASE(14, pr_read);
+        GENERATE_READ_PR_REG_CASE(15, pr_read);
+    default:
+        BUG(); /* Can't happen */
+        break;
+    }
+}
+
+void write_protection_region(const pr_t *pr_write, uint8_t sel)
+{
+    prepare_selector(&sel);
+
+    switch ( sel )
+    {
+        GENERATE_WRITE_PR_REG_CASE(0, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(1, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(2, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(3, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(4, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(5, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(6, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(7, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(8, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(9, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(10, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(11, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(12, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(13, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(14, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(15, pr_write);
+    default:
+        BUG(); /* Can't happen */
+        break;
+    }
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
index 3d37beab57..7ab68fc8c7 100644
--- a/xen/arch/arm/mpu/mm.c
+++ b/xen/arch/arm/mpu/mm.c
@@ -29,35 +29,6 @@ DECLARE_BITMAP(xen_mpumap_mask, MAX_MPU_REGION_NR) \
 /* EL2 Xen MPU memory region mapping table. */
 pr_t __cacheline_aligned __section(".data") xen_mpumap[MAX_MPU_REGION_NR];
 
-#ifdef CONFIG_ARM_64
-/*
- * The following are needed for the cases: GENERATE_WRITE_PR_REG_CASE
- * and GENERATE_READ_PR_REG_CASE with num==0
- */
-#define PRBAR0_EL2 PRBAR_EL2
-#define PRLAR0_EL2 PRLAR_EL2
-
-#define PRBAR_EL2_(n)   PRBAR##n##_EL2
-#define PRLAR_EL2_(n)   PRLAR##n##_EL2
-
-#endif /* CONFIG_ARM_64 */
-
-#define GENERATE_WRITE_PR_REG_CASE(num, pr)                                 \
-    case num:                                                               \
-    {                                                                       \
-        WRITE_SYSREG(pr->prbar.bits & ~MPU_REGION_RES0, PRBAR_EL2_(num));   \
-        WRITE_SYSREG(pr->prlar.bits & ~MPU_REGION_RES0, PRLAR_EL2_(num));   \
-        break;                                                              \
-    }
-
-#define GENERATE_READ_PR_REG_CASE(num, pr)                      \
-    case num:                                                   \
-    {                                                           \
-        pr->prbar.bits = READ_SYSREG(PRBAR_EL2_(num));          \
-        pr->prlar.bits = READ_SYSREG(PRLAR_EL2_(num));          \
-        break;                                                  \
-    }
-
 static void __init __maybe_unused build_assertions(void)
 {
     /*
@@ -69,94 +40,6 @@ static void __init __maybe_unused build_assertions(void)
 }
 
 #ifdef CONFIG_ARM_64
-/*
- * Armv8-R supports direct access and indirect access to the MPU regions through
- * registers:
- *  - indirect access involves changing the MPU region selector, issuing an isb
- *    barrier and accessing the selected region through specific registers
- *  - direct access involves accessing specific registers that point to
- *    specific MPU regions, without changing the selector, avoiding the use of
- *    a barrier.
- * For Arm64 the PR{B,L}AR_ELx (for n=0) and PR{B,L}AR_ELx (for n=1..15) are
- * used for the direct access to the regions selected by
- * PRSELR_EL2.REGION<7:4>:n, so 16 regions can be directly accessed when the
- * selector is a multiple of 16, giving access to all the supported memory
- * regions.
- */
-static void prepare_selector(uint8_t *sel)
-{
-    uint8_t cur_sel = *sel;
-
-    /*
-     * {read,write}_protection_region works using the direct access to the 0..15
-     * regions, so in order to save the isb() overhead, change the PRSELR_EL2
-     * only when needed, so when the upper 4 bits of the selector will change.
-     */
-    cur_sel &= 0xF0U;
-    if ( READ_SYSREG(PRSELR_EL2) != cur_sel )
-    {
-        WRITE_SYSREG(cur_sel, PRSELR_EL2);
-        isb();
-    }
-    *sel &= 0xFU;
-}
-
-void read_protection_region(pr_t *pr_read, uint8_t sel)
-{
-    prepare_selector(&sel);
-
-    switch ( sel )
-    {
-        GENERATE_READ_PR_REG_CASE(0, pr_read);
-        GENERATE_READ_PR_REG_CASE(1, pr_read);
-        GENERATE_READ_PR_REG_CASE(2, pr_read);
-        GENERATE_READ_PR_REG_CASE(3, pr_read);
-        GENERATE_READ_PR_REG_CASE(4, pr_read);
-        GENERATE_READ_PR_REG_CASE(5, pr_read);
-        GENERATE_READ_PR_REG_CASE(6, pr_read);
-        GENERATE_READ_PR_REG_CASE(7, pr_read);
-        GENERATE_READ_PR_REG_CASE(8, pr_read);
-        GENERATE_READ_PR_REG_CASE(9, pr_read);
-        GENERATE_READ_PR_REG_CASE(10, pr_read);
-        GENERATE_READ_PR_REG_CASE(11, pr_read);
-        GENERATE_READ_PR_REG_CASE(12, pr_read);
-        GENERATE_READ_PR_REG_CASE(13, pr_read);
-        GENERATE_READ_PR_REG_CASE(14, pr_read);
-        GENERATE_READ_PR_REG_CASE(15, pr_read);
-    default:
-        BUG(); /* Can't happen */
-        break;
-    }
-}
-
-void write_protection_region(const pr_t *pr_write, uint8_t sel)
-{
-    prepare_selector(&sel);
-
-    switch ( sel )
-    {
-        GENERATE_WRITE_PR_REG_CASE(0, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(1, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(2, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(3, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(4, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(5, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(6, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(7, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(8, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(9, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(10, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(11, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(12, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(13, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(14, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(15, pr_write);
-    default:
-        BUG(); /* Can't happen */
-        break;
-    }
-}
-
 pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags)
 {
     unsigned int attr_idx = PAGE_AI_MASK(flags);
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Tue Jun 17 11:13:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 11:13:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018123.1395065 (Exim 4.92)
	(envelope-from )
	id 1uRUFa-0006os-Hj; Tue, 17 Jun 2025 11:13:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018123.1395065; Tue, 17 Jun 2025 11:13: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 1uRUFa-0006oj-F7; Tue, 17 Jun 2025 11:13:10 +0000
Received: by outflank-mailman (input) for mailman id 1018123;
 Tue, 17 Jun 2025 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 1uRUFZ-0006nm-Jk
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 11:13:09 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on2060e.outbound.protection.outlook.com
 [2a01:111:f403:2413::60e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0b17e769-4b6c-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 13:13:07 +0200 (CEST)
Received: from PH1PEPF000132F9.NAMP220.PROD.OUTLOOK.COM (2603:10b6:518:1::2a)
 by SJ0PR12MB5663.namprd12.prod.outlook.com (2603:10b6:a03:42a::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.28; Tue, 17 Jun
 2025 11:13:01 +0000
Received: from SJ1PEPF000023D4.namprd21.prod.outlook.com
 (2a01:111:f403:c902::13) by PH1PEPF000132F9.outlook.office365.com
 (2603:1036:903:47::3) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.23 via Frontend Transport; Tue,
 17 Jun 2025 11:13:01 +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.8880.0 via Frontend Transport; Tue, 17 Jun 2025 11:13:00 +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, 17 Jun
 2025 06:13:00 -0500
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; Tue, 17 Jun 2025 06:12:59 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0b17e769-4b6c-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=WPrcb9PxmftpypCLJF3M+0GOuGIJtM5JxpQhs6YZgH9UvL+V2o3Omam3UcjzK7okLi+BtrAU+PzcZotcrHXOEHh5fswTkT1jh73ToINmSXQRg1qZY2KWxTFyC5bAUcrjgQ9zS+KdMk6JRHTDh1SnPUcp8DGvJ+gfJ5NjT5imReTZQglfmvs4fsAxZf81lqNcow4eyW8RWSXCubE0QM9XVtwmLsJ0R2YHtQvuEpcA8cDHRpAeFHyUsD/urLgdY1w4Oi3FqKSb6aiEjWwvYDzR/lk5ARPJTxp9CNwu3i+IWsUTopDS+1I6RfYMVCl3ysFLAn4tyeKTohC1x03OlJPS1g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ZBWonEOx3cR135w9gJzkI2e+vQSR+H8cHG9c5fj+CkY=;
 b=qFYRMJaTyJZ62nk6C2eya28mjt1Jh+tLQvRcDn2smodSCKvMSnP8SnG3JtOXVLoao4zxplSmv2PzRUsTAusMh1B8MDlPbfXZlI878qdK0qbyUzH0h2ftpAtcTb4ojntD7V+whb9l9n+HlVmLp9B+tyypuDgyz3pptITLtutEA/FNV998Hv8BSP2vxYq8mITi+ieC+TLG8I7Y+5UNz9VvJm15MfY6nKDHubuUBmflK54r5TfZa0Ljkk7rmW+6LqVCvuZdgWp47uSpEbVbv0wcsVG+0qyJtZ51yG46KFo5l+ZMsov6QLZ2NL5CKHc3e6L0C8CIvbmfSfWc9wveAFQWJg==
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=ZBWonEOx3cR135w9gJzkI2e+vQSR+H8cHG9c5fj+CkY=;
 b=UQ8zT78vFgq+SIEjRvI5CTu1/CIDEmDa0k1X5OHE0VFIXR7Pj9Uln1Gvdxu8cnMh8+0KnTzfoZmd7EH/y3O32HzvvhsQECpE7LFz4UaGunL4h+HhYTL2m0uiQJMeCgJjMv7xFQybIImJeC88aQ6BFDq8Rhh9Trcwri+bg/m469Y=
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 ,
	Hari Limaye 
Subject: [PATCH v4 2/3] arm/mpu: Define arm32 system registers
Date: Tue, 17 Jun 2025 12:12:50 +0100
Message-ID: <20250617111251.1711553-3-ayan.kumar.halder@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20250617111251.1711553-1-ayan.kumar.halder@amd.com>
References: <20250617111251.1711553-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: SJ1PEPF000023D4:EE_|SJ0PR12MB5663:EE_
X-MS-Office365-Filtering-Correlation-Id: 28d5c5a5-1973-42bd-ca37-08ddad8fec1a
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?MIv8KLmoMAMsbCj68gdKbrTEv7b0QjM70X3FOc5Ca2/2B5fOvJBgtkoZSVkk?=
 =?us-ascii?Q?AYY9KaCk/3XHqChGaYxxbB0q+gSsXS4p4X6/UsVU1Ijpwps11zP30WxdKCSY?=
 =?us-ascii?Q?Hw9QuP+H9H5Fx/2W4bijoPj24k3H0Z0b/94+lg0XCo3SuunU9kPaZl4RwtZW?=
 =?us-ascii?Q?3Vmc/Ld0BxYwruSEZdVZHNDuUgY6fDBlwOseglKPlTh9c0PWkrM6Jdqyon5Z?=
 =?us-ascii?Q?YWc33GOebkBAUU/INPWSABEKJEkzNtTTDHAdOI/RVemPEdr2DHJ184G978vW?=
 =?us-ascii?Q?A9f80Q3EEXkmrBnu32/PS4f4mxj8a3jq63b0oa6WV4+mYC8LlCAADjkkel98?=
 =?us-ascii?Q?j8seXMQOvE43UAkSlYMQEfYTAwZwBfWummFzTnw72jbSLLUrfJo3IjXYRN7p?=
 =?us-ascii?Q?bcUarF1xekwmL6Bo2FnmvVIzHIJ4JD2OLdl+nIJ09w5+FxN20nchww+YkGv7?=
 =?us-ascii?Q?9QBAiDs4n9HR0g+FcrCM+7Y+Pi8FbwR3OXn1AuW7O7MYIYeEZJ1/cQROHfiy?=
 =?us-ascii?Q?sOZSMPeYfF7Ex5jq2WcmYlDZ8+oW9H2ULDj+oW+pMjQ2haDcQBHt/zjovxfM?=
 =?us-ascii?Q?YvqM7F1HK0rFg94ibqTFfNa9w1qC9rjdHeoZjvNWjprC8/W8NmkOfR+9lJcF?=
 =?us-ascii?Q?MH/fdC0pISPT/Bt4zuOvb3NtqD6mHmZU3ABiK7VJyBAFSEDGGHXk9Yx3zmA9?=
 =?us-ascii?Q?mopPTQe03tvwGb29UTZ/Annb/ltYgIDoK+VOGOZdQJNg6mBMSads8H/vsU4/?=
 =?us-ascii?Q?/VWfLUXHy6kCZKxYfEc9O3zX+ic87FnHUxOAgSLXpCSLKMGKRiMzOl4Oq8Nl?=
 =?us-ascii?Q?9SX+WjvHZuSbp4rR9vJ/dApG3yez2dgyY8837/hmAiK0Mov7ExfWmVBKI39/?=
 =?us-ascii?Q?SgehBiKQkh/calNryJHef26iwQIDDkrfe8iYYum7sX6s93YTlVJvEdKfcsUT?=
 =?us-ascii?Q?J3yod1pTY/ijPzKnJrdfN9Pe7Fz3ZvQ3Rh5Bv0e+wHSZAq3Gf6aVTvufdDrF?=
 =?us-ascii?Q?xknkZZyEB02TeQcrRuNeoJIWo0hbERoji23+6kmI+rzQsZSeqkkcu+4Cw6bR?=
 =?us-ascii?Q?QGfOJpKdDQ+j7fewdTHZXngBNfPsBV1N370m07cTo5cFSF2gS+4Gyp+tWyVo?=
 =?us-ascii?Q?ZGY1N+AUSrALbT1mQRFN2rmra8it7C0Xoj+xLF1Jdj+vIrdl9Bi2o4EUOON2?=
 =?us-ascii?Q?ZdEhD2tnQfyQAjph6PmTwpSIKbrrW24UuGk+iEBjgbgTyCTXE0dhfq29mVdq?=
 =?us-ascii?Q?uEiIFKAo+RaKB3oiuAL/jEhWn6YZlKVolqAj6HheclCiIHJMnpyr26xySOgE?=
 =?us-ascii?Q?oQjBpcRQUGaIbCYCNFrGVmRjN1BDvXKRoKIQfzzNqEedoMvp3pnUn6bbugqg?=
 =?us-ascii?Q?IYpb1JSEsTkRZp0uC3rFcfiOZMiMGroWll7dJ1uFHfQFTpKkxmgKuhfMCq8x?=
 =?us-ascii?Q?Ps4YaeGwSZZkok1uRc+9ogUpIdU6qf4CV8k3Yb/Mh2KSgnjubIigQfhzkjRZ?=
 =?us-ascii?Q?ObNHfptKgl26TW0Jd9CEMwHcua7p5Gdihq8A?=
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: 17 Jun 2025 11:13:00.8238
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 28d5c5a5-1973-42bd-ca37-08ddad8fec1a
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: SJ0PR12MB5663

Fix the definition for HPRLAR.
Define the base/limit address registers to access the first 32 protection
regions.

Signed-off-by: Ayan Kumar Halder 
Reviewed-by: Hari Limaye 
---
Changes from :-

v2 - New patch introduced in v3 (Extracted from 
"arm/mpu: Provide access to the MPU region from the C code").

v3 - Add Hari's R-b.

 xen/arch/arm/include/asm/mpu/cpregs.h | 68 ++++++++++++++++++++++++++-
 1 file changed, 67 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/include/asm/mpu/cpregs.h b/xen/arch/arm/include/asm/mpu/cpregs.h
index d5cd0e04d5..bb15e02df6 100644
--- a/xen/arch/arm/include/asm/mpu/cpregs.h
+++ b/xen/arch/arm/include/asm/mpu/cpregs.h
@@ -9,7 +9,73 @@
 /* CP15 CR6: MPU Protection Region Base/Limit/Select Address Register */
 #define HPRSELR         p15,4,c6,c2,1
 #define HPRBAR          p15,4,c6,c3,0
-#define HPRLAR          p15,4,c6,c8,1
+#define HPRLAR          p15,4,c6,c3,1
+
+/* CP15 CR6: MPU Protection Region Base/Limit Address Register */
+#define HPRBAR0         p15,4,c6,c8,0
+#define HPRLAR0         p15,4,c6,c8,1
+#define HPRBAR1         p15,4,c6,c8,4
+#define HPRLAR1         p15,4,c6,c8,5
+#define HPRBAR2         p15,4,c6,c9,0
+#define HPRLAR2         p15,4,c6,c9,1
+#define HPRBAR3         p15,4,c6,c9,4
+#define HPRLAR3         p15,4,c6,c9,5
+#define HPRBAR4         p15,4,c6,c10,0
+#define HPRLAR4         p15,4,c6,c10,1
+#define HPRBAR5         p15,4,c6,c10,4
+#define HPRLAR5         p15,4,c6,c10,5
+#define HPRBAR6         p15,4,c6,c11,0
+#define HPRLAR6         p15,4,c6,c11,1
+#define HPRBAR7         p15,4,c6,c11,4
+#define HPRLAR7         p15,4,c6,c11,5
+#define HPRBAR8         p15,4,c6,c12,0
+#define HPRLAR8         p15,4,c6,c12,1
+#define HPRBAR9         p15,4,c6,c12,4
+#define HPRLAR9         p15,4,c6,c12,5
+#define HPRBAR10        p15,4,c6,c13,0
+#define HPRLAR10        p15,4,c6,c13,1
+#define HPRBAR11        p15,4,c6,c13,4
+#define HPRLAR11        p15,4,c6,c13,5
+#define HPRBAR12        p15,4,c6,c14,0
+#define HPRLAR12        p15,4,c6,c14,1
+#define HPRBAR13        p15,4,c6,c14,4
+#define HPRLAR13        p15,4,c6,c14,5
+#define HPRBAR14        p15,4,c6,c15,0
+#define HPRLAR14        p15,4,c6,c15,1
+#define HPRBAR15        p15,4,c6,c15,4
+#define HPRLAR15        p15,4,c6,c15,5
+#define HPRBAR16        p15,5,c6,c8,0
+#define HPRLAR16        p15,5,c6,c8,1
+#define HPRBAR17        p15,5,c6,c8,4
+#define HPRLAR17        p15,5,c6,c8,5
+#define HPRBAR18        p15,5,c6,c9,0
+#define HPRLAR18        p15,5,c6,c9,1
+#define HPRBAR19        p15,5,c6,c9,4
+#define HPRLAR19        p15,5,c6,c9,5
+#define HPRBAR20        p15,5,c6,c10,0
+#define HPRLAR20        p15,5,c6,c10,1
+#define HPRBAR21        p15,5,c6,c10,4
+#define HPRLAR21        p15,5,c6,c10,5
+#define HPRBAR22        p15,5,c6,c11,0
+#define HPRLAR22        p15,5,c6,c11,1
+#define HPRBAR23        p15,5,c6,c11,4
+#define HPRLAR23        p15,5,c6,c11,5
+#define HPRBAR24        p15,5,c6,c12,0
+#define HPRLAR24        p15,5,c6,c12,1
+#define HPRBAR25        p15,5,c6,c12,4
+#define HPRLAR25        p15,5,c6,c12,5
+#define HPRBAR26        p15,5,c6,c13,0
+#define HPRLAR26        p15,5,c6,c13,1
+#define HPRBAR27        p15,5,c6,c13,4
+#define HPRLAR27        p15,5,c6,c13,5
+#define HPRBAR28        p15,5,c6,c14,0
+#define HPRLAR28        p15,5,c6,c14,1
+#define HPRBAR29        p15,5,c6,c14,4
+#define HPRLAR29        p15,5,c6,c14,5
+#define HPRBAR30        p15,5,c6,c15,0
+#define HPRLAR30        p15,5,c6,c15,1
+#define HPRBAR31        p15,5,c6,c15,4
+#define HPRLAR31        p15,5,c6,c15,5
 
 /* Aliases of AArch64 names for use in common code */
 #ifdef CONFIG_ARM_32
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Tue Jun 17 11:13:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 11:13:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018125.1395075 (Exim 4.92)
	(envelope-from )
	id 1uRUFg-00079p-PJ; Tue, 17 Jun 2025 11:13:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018125.1395075; Tue, 17 Jun 2025 11: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 1uRUFg-00079f-MJ; Tue, 17 Jun 2025 11:13:16 +0000
Received: by outflank-mailman (input) for mailman id 1018125;
 Tue, 17 Jun 2025 11: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 1uRUFf-0006Jw-RJ
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 11:13:15 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on2060d.outbound.protection.outlook.com
 [2a01:111:f403:2414::60d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0fbe5737-4b6c-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 13:13:15 +0200 (CEST)
Received: from PH1PEPF000132F3.NAMP220.PROD.OUTLOOK.COM (2603:10b6:518:1::38)
 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.8857.19; Tue, 17 Jun
 2025 11:13:09 +0000
Received: from SJ1PEPF000023D4.namprd21.prod.outlook.com
 (2a01:111:f403:c902::13) by PH1PEPF000132F3.outlook.office365.com
 (2603:1036:903:47::3) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.23 via Frontend Transport; Tue,
 17 Jun 2025 11:13:09 +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.8880.0 via Frontend Transport; Tue, 17 Jun 2025 11:13:09 +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, 17 Jun
 2025 06:13:03 -0500
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, 17 Jun
 2025 06:13:03 -0500
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; Tue, 17 Jun 2025 06:13:02 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0fbe5737-4b6c-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=PVtVNRdztqsJds18rXzw5E5aui2VtgG2g6n14OC5ETuvFn2lwGoygWBhaGDK5ohBqFSoOXhkTCqweQPwNZNdIerBRImInJ6+7NlPUWsEfTp/wsP0NmSdiGUipKmlRk1YugFbthOIcMHtmBx/Cpa8ZQhpMjqsSbvY2oUhXChktkYgfFLclvLt5lZrWQDHIWI0OCvpLX9GNHA/C+nXa9Wld35FcmJY17eFay2Xq2uvwE8nSjhymXatKTNOLqTTwclSuOnZoapQkYj9wA8+KHn1x7UcPjfvAJORUn10hLgBRpG6o8987aO9cVO853z0BxAWbQhqK/hiikno8D1piF5IPA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=AN9WdqwVCm1lPI+a3SLeICCSGdyyYOJ1GEWKR/CXCuc=;
 b=I8vpUWJGxODmWnieDLhYYHGw+N+CqBEjKR2C+qHzNXlg5Ld+r/OfGxIjCtAxkhPB0EfRUhmGF+eaESI9N/tHKlMwBsiKhyyZagI/BbkKE41GsuJ7QoBk4tcolKJ2gASoJx90YeAzByDdL/Db3Nh3B6Q5otn+D1d9MwgduzCn252TDbetrnTwNKO0CihxhLtuLVLkilmN1BFJup6zekkK4yxxXxnaWE9WybzXwh/MDQtjSD7gSykb24otDjJ6RxU1DyNktsQzCrDQrEyt84inMO0Yy2MZg1i1v5QR7OFSEr3iG4lDQfle6nAY9B54IFFGlNhqWGToAx076G/cG3FR0g==
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=AN9WdqwVCm1lPI+a3SLeICCSGdyyYOJ1GEWKR/CXCuc=;
 b=gljnQI6dSZMtMUmGjRVWT1zHq9PXyyBhuBEiqtqygkcGRGfsAecYTh7H42Ow6wi4gGI7tDLvaA6F69ADW2RzDFfu8SpxNNiBj6artzEKbdjdb6hdnpWCl7SqT86t6QmeqOsBXlUspzrJIQE4hrJwueEH7RVJy27Cy+tEeilAArc=
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 ,
	Hari Limaye 
Subject: [PATCH v4 3/3] arm/mpu: Enable read/write to protection regions for arm32
Date: Tue, 17 Jun 2025 12:12:51 +0100
Message-ID: <20250617111251.1711553-4-ayan.kumar.halder@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20250617111251.1711553-1-ayan.kumar.halder@amd.com>
References: <20250617111251.1711553-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: SJ1PEPF000023D4:EE_|DM6PR12MB4121:EE_
X-MS-Office365-Filtering-Correlation-Id: 9bead7af-c7ff-4fe5-6c17-08ddad8ff104
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|376014|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?NJ7UEkvaXSYmv6bp5kQW6gOtxSmqS8OGh1K3m3QtI8CK5FXECgewI33RqKoS?=
 =?us-ascii?Q?mRMS2bjXhSHjbQk94QePSmW9LgVmufdatOttQ6mmvfC9Y3qBVAfboTgVrDZu?=
 =?us-ascii?Q?RvHwREedlmmqfUcTJ6AIBM0eMNBVbGzIcH/ceX92ZihY+Wrx4IRXBFmbpxVk?=
 =?us-ascii?Q?X/CHsj4HVu2QUiR4XbZ2Be80N0QA0hoHu0BU3yCGugQP3h5llRp7TvQUBGoW?=
 =?us-ascii?Q?RgHWc6+/5KowYoTH8mL+1NokQ0Sjgszoq366IsSTT+AESxujCvqU1hi3bnat?=
 =?us-ascii?Q?/75lnCKQf47KDnFWW5Bq5q5B4JO8Y5pVe4pgUCv6BBwQpY6GT9IZc9w8Ne9H?=
 =?us-ascii?Q?SKlJjRE2gF8fZCg11B40Ai2b8s300uB+sbUZ/CKBjz7C0bZhs2ZfdkqJOjjW?=
 =?us-ascii?Q?QSyL3ZFYex5JGXxV4VWtaqFODQxk51fort+EgXT2nGe2ZfFqq8cA3hGCvMQ6?=
 =?us-ascii?Q?S9279hZEhP+SG78h+jYtkcrHr+MgsxCUPSfZc7phUE3VwOQbEpjE++tlm+sj?=
 =?us-ascii?Q?xpVuCJKIg1kl6fJr9oBNLJk51Eeaqk5rd9SsD8l67UTwx2O2MSp/KnuP/y3F?=
 =?us-ascii?Q?kE7Yg3ITUnuS00Y18hJQYvA0kL3wnihhBbKZWzzi3FOYSXTbOlqHL2I7EW3h?=
 =?us-ascii?Q?0OLdNj40d9r7bmlFJ6s1uWq6KtTTut3rSESXbyupvQ8o7oms77ruGgTKGWL2?=
 =?us-ascii?Q?l4VQhOJL8Til/aXMIJuov9ogdSwrjKKjR2bmAy0V5q02wxyNbTnU8ZCvOIM2?=
 =?us-ascii?Q?K6yma7TMpmDxYJDPBDjQZaBuxaG3EPhWo7clf69IoHmuMbmmta+1y0zvln3b?=
 =?us-ascii?Q?eIHm8AFMg0PDp+Y7TZuGtB05cYQ0fITn23mfCbaENhK/1QYI7cHCeMcKyXda?=
 =?us-ascii?Q?q94CryW9LESErnVGKFIn62IIzFlyAyehwryfzLuXdoL/dprMsIdPUBN1qa8P?=
 =?us-ascii?Q?VtYsYTAa0ymetsVMhSNOByeg/TY3CzrYRz1uIvZW0R1Hw861oYJqZjZ7Aeze?=
 =?us-ascii?Q?Gw8ITHblR7ISioTsc2+HpXLb63btEVgt78L132H3HAp3oICkFN7ZCrYcIivk?=
 =?us-ascii?Q?uM7ycgh9eOLu3bmNH0y1AnsqAeVUl8QlTAYPYZr1u7fg2INAtd1ug3JefZ31?=
 =?us-ascii?Q?xkIxzSAkBAWNh+aYR9cB9JdUvSDuNHeLWOoNmJcsRwlwQTnqkF0sHbNNmIx6?=
 =?us-ascii?Q?dX+AVf4pljsDR5s4SKv6psrrzs7OO110KAK5Gj9HKFqLFxJ3xoSQjwKNo4TY?=
 =?us-ascii?Q?WgzPunrbTDeOtbLqSoRyLacIC8OogU/RRZUdzEGr7tZLHKYKrOSBm8Iqi1CW?=
 =?us-ascii?Q?CT42VPEpocFxqwT4LYchpUWxtdVo3gKEcrhN2ho6HGysnV4nPi/nbe7uITy0?=
 =?us-ascii?Q?CkbrAJoiCnFEwq0nNFj9x51mS/0o+IZdAeDc6OLNkupIpcl9aKOhaDRW0dBt?=
 =?us-ascii?Q?7u9EhcajiUnCUJkb6bBRo0Dj1zpXclKlhC6BcPLEZUek4roOEDAbMqtZj+xs?=
 =?us-ascii?Q?xylbnH4cDO06LDVqPQJb96F6jfJVK1U6fXsK?=
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);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jun 2025 11:13:09.0679
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9bead7af-c7ff-4fe5-6c17-08ddad8ff104
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: DM6PR12MB4121

Define prepare_selector(), read_protection_region() and
write_protection_region() for arm32. Also, define
GENERATE_{READ/WRITE}_PR_REG_OTHERS to access MPU regions from 32 to 254.

Enable pr_{get/set}_{base/limit}(), region_is_valid() for arm32.
Enable pr_of_addr() for arm32.

The maximum number of regions supported is 255 (which corresponds to the
maximum value in HMPUIR).

Signed-off-by: Ayan Kumar Halder 
---
Changes from :-

v1 - 1. Enable write_protection_region() for aarch32.

v2 - 1. Enable access to protection regions from 0 - 255.

v3 - 1. The maximum number of regions is 255. Thus, regions numbered 0 - 254
are supported.

2. prepare_selector() is modified to ensure HPRSELR is written when accessing
any region beyond 31 and the current value differs from the region number to
be accessed.

 xen/arch/arm/include/asm/mpu.h  |   2 -
 xen/arch/arm/mpu/Makefile       |   1 +
 xen/arch/arm/mpu/arm32/Makefile |   1 +
 xen/arch/arm/mpu/arm32/mm.c     | 164 ++++++++++++++++++++++++++++++++
 xen/arch/arm/mpu/mm.c           |   2 -
 5 files changed, 166 insertions(+), 4 deletions(-)
 create mode 100644 xen/arch/arm/mpu/arm32/Makefile
 create mode 100644 xen/arch/arm/mpu/arm32/mm.c

diff --git a/xen/arch/arm/include/asm/mpu.h b/xen/arch/arm/include/asm/mpu.h
index 8f06ddac0f..63560c613b 100644
--- a/xen/arch/arm/include/asm/mpu.h
+++ b/xen/arch/arm/include/asm/mpu.h
@@ -25,7 +25,6 @@
 
 #ifndef __ASSEMBLY__
 
-#ifdef CONFIG_ARM_64
 /*
  * Set base address of MPU protection region.
  *
@@ -85,7 +84,6 @@ static inline bool region_is_valid(const pr_t *pr)
 {
     return pr->prlar.reg.en;
 }
-#endif /* CONFIG_ARM_64 */
 
 #endif /* __ASSEMBLY__ */
 
diff --git a/xen/arch/arm/mpu/Makefile b/xen/arch/arm/mpu/Makefile
index 5ad15e93be..58c9b5b4e8 100644
--- a/xen/arch/arm/mpu/Makefile
+++ b/xen/arch/arm/mpu/Makefile
@@ -1,4 +1,5 @@
 obj-$(CONFIG_ARM_32) += domain-page.o
+obj-$(CONFIG_ARM_32) += arm32/
 obj-$(CONFIG_ARM_64) += arm64/
 obj-y += mm.o
 obj-y += p2m.o
diff --git a/xen/arch/arm/mpu/arm32/Makefile b/xen/arch/arm/mpu/arm32/Makefile
new file mode 100644
index 0000000000..b18cec4836
--- /dev/null
+++ b/xen/arch/arm/mpu/arm32/Makefile
@@ -0,0 +1 @@
+obj-y += mm.o
diff --git a/xen/arch/arm/mpu/arm32/mm.c b/xen/arch/arm/mpu/arm32/mm.c
new file mode 100644
index 0000000000..c0317a4ada
--- /dev/null
+++ b/xen/arch/arm/mpu/arm32/mm.c
@@ -0,0 +1,164 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define GENERATE_WRITE_PR_REG_CASE(num, pr)               \
+    case num:                                             \
+    {                                                     \
+        WRITE_SYSREG(pr->prbar.bits, HPRBAR##num);        \
+        WRITE_SYSREG(pr->prlar.bits, HPRLAR##num);        \
+        break;                                            \
+    }
+
+#define GENERATE_WRITE_PR_REG_OTHERS(num, pr)             \
+    case num:                                             \
+    {                                                     \
+        WRITE_SYSREG(pr->prbar.bits, HPRBAR);             \
+        WRITE_SYSREG(pr->prlar.bits, HPRLAR);             \
+        break;                                            \
+    }
+
+#define GENERATE_READ_PR_REG_CASE(num, pr)                \
+    case num:                                             \
+    {                                                     \
+        pr->prbar.bits = READ_SYSREG(HPRBAR##num);        \
+        pr->prlar.bits = READ_SYSREG(HPRLAR##num);        \
+        break;                                            \
+    }
+
+#define GENERATE_READ_PR_REG_OTHERS(num, pr)              \
+    case num:                                             \
+    {                                                     \
+        pr->prbar.bits = READ_SYSREG(HPRBAR);             \
+        pr->prlar.bits = READ_SYSREG(HPRLAR);             \
+        break;                                            \
+    }
+
+/*
+ * Armv8-R supports direct access and indirect access to the MPU regions through
+ * registers:
+ *  - indirect access involves changing the MPU region selector, issuing an isb
+ *    barrier and accessing the selected region through specific registers
+ *  - direct access involves accessing specific registers that point to
+ *    specific MPU regions, without changing the selector, avoiding the use of
+ *    a barrier.
+ * For Arm32 the HPR{B,L}AR (for n=0..31) are used for direct access to the
+ * first 32 MPU regions.
+ * For MPU region numbered 32..254, one need to set the region number in HPRSELR,
+ * followed by configuring HPR{B,L}AR.
+ */
+static void prepare_selector(uint8_t *sel)
+{
+    uint8_t cur_sel = *sel;
+    /* The top 24 bits of HPRSELR are RES0. */
+    uint8_t val = READ_SYSREG(HPRSELR) & 0xff;
+
+    if ( (cur_sel > 31) && (cur_sel != val) )
+    {
+        WRITE_SYSREG(cur_sel, HPRSELR);
+        isb();
+    }
+}
+
+void read_protection_region(pr_t *pr_read, uint8_t sel)
+{
+    prepare_selector(&sel);
+
+    switch ( sel )
+    {
+        GENERATE_READ_PR_REG_CASE(0, pr_read);
+        GENERATE_READ_PR_REG_CASE(1, pr_read);
+        GENERATE_READ_PR_REG_CASE(2, pr_read);
+        GENERATE_READ_PR_REG_CASE(3, pr_read);
+        GENERATE_READ_PR_REG_CASE(4, pr_read);
+        GENERATE_READ_PR_REG_CASE(5, pr_read);
+        GENERATE_READ_PR_REG_CASE(6, pr_read);
+        GENERATE_READ_PR_REG_CASE(7, pr_read);
+        GENERATE_READ_PR_REG_CASE(8, pr_read);
+        GENERATE_READ_PR_REG_CASE(9, pr_read);
+        GENERATE_READ_PR_REG_CASE(10, pr_read);
+        GENERATE_READ_PR_REG_CASE(11, pr_read);
+        GENERATE_READ_PR_REG_CASE(12, pr_read);
+        GENERATE_READ_PR_REG_CASE(13, pr_read);
+        GENERATE_READ_PR_REG_CASE(14, pr_read);
+        GENERATE_READ_PR_REG_CASE(15, pr_read);
+        GENERATE_READ_PR_REG_CASE(16, pr_read);
+        GENERATE_READ_PR_REG_CASE(17, pr_read);
+        GENERATE_READ_PR_REG_CASE(18, pr_read);
+        GENERATE_READ_PR_REG_CASE(19, pr_read);
+        GENERATE_READ_PR_REG_CASE(20, pr_read);
+        GENERATE_READ_PR_REG_CASE(21, pr_read);
+        GENERATE_READ_PR_REG_CASE(22, pr_read);
+        GENERATE_READ_PR_REG_CASE(23, pr_read);
+        GENERATE_READ_PR_REG_CASE(24, pr_read);
+        GENERATE_READ_PR_REG_CASE(25, pr_read);
+        GENERATE_READ_PR_REG_CASE(26, pr_read);
+        GENERATE_READ_PR_REG_CASE(27, pr_read);
+        GENERATE_READ_PR_REG_CASE(28, pr_read);
+        GENERATE_READ_PR_REG_CASE(29, pr_read);
+        GENERATE_READ_PR_REG_CASE(30, pr_read);
+        GENERATE_READ_PR_REG_CASE(31, pr_read);
+        GENERATE_READ_PR_REG_OTHERS(32 ... 254, pr_read);
+    default:
+        BUG(); /* Can't happen */
+        break;
+    }
+}
+
+void write_protection_region(const pr_t *pr_write, uint8_t sel)
+{
+    prepare_selector(&sel);
+
+    switch ( sel )
+    {
+        GENERATE_WRITE_PR_REG_CASE(0, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(1, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(2, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(3, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(4, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(5, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(6, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(7, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(8, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(9, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(10, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(11, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(12, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(13, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(14, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(15, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(16, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(17, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(18, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(19, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(20, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(21, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(22, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(23, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(24, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(25, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(26, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(27, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(28, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(29, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(30, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(31, pr_write);
+        GENERATE_WRITE_PR_REG_OTHERS(32 ... 254, pr_write);
+    default:
+        BUG(); /* Can't happen */
+        break;
+    }
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
index 7ab68fc8c7..ccfb37a67b 100644
--- a/xen/arch/arm/mpu/mm.c
+++ b/xen/arch/arm/mpu/mm.c
@@ -39,7 +39,6 @@ static void __init __maybe_unused build_assertions(void)
     BUILD_BUG_ON(PAGE_SIZE != SZ_4K);
 }
 
-#ifdef CONFIG_ARM_64
 pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags)
 {
     unsigned int attr_idx = PAGE_AI_MASK(flags);
@@ -110,7 +109,6 @@ pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags)
 
     return region;
 }
-#endif /* CONFIG_ARM_64 */
 
 void __init setup_mm(void)
 {
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Tue Jun 17 11:27:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 11:27:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018165.1395084 (Exim 4.92)
	(envelope-from )
	id 1uRUTV-0001TG-6C; Tue, 17 Jun 2025 11:27:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018165.1395084; Tue, 17 Jun 2025 11:27: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 1uRUTV-0001T9-2k; Tue, 17 Jun 2025 11:27:33 +0000
Received: by outflank-mailman (input) for mailman id 1018165;
 Tue, 17 Jun 2025 11:27: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 1uRUTT-0001T3-Vb
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 11:27:31 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on2062e.outbound.protection.outlook.com
 [2a01:111:f403:200a::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0d5cd550-4b6e-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 13:27:30 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by DM4PR12MB6012.namprd12.prod.outlook.com (2603:10b6:8:6c::5) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8835.29; Tue, 17 Jun 2025 11:27:24 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8835.027; Tue, 17 Jun 2025
 11:27: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: 0d5cd550-4b6e-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=rJi/7x31xdbTiaOT4SSC+h/SLTMl7tt+J+zmiu6I+KI3KdLoL2khhRXeE8MiACs7ZcObtyHnx6fT+NmLO7TbY85YmlFvm+gZbGeu/LGhsrMh0S9EPYQnYl+d8JWCuOxvqvlfmToe9vO1qAYpJ7pHd/KIG7j4pVzQ1FthhM9WbB5D18bLBbP/eO+7pnwGLV77FIFnbo/BDHrNbpW9tMZ17BwZkOSv/LL24MAS2W9zd0uvE8qghfoRIfmJkYpMYUPgLLxO/O5NzDCcGEMBDBvAXZKkRSIG1HfETkVbO2WprzDuHbOz+sc6TFsrVCEVN682WsaY/TfXbsZB5kWiQmrLYA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=sK9BICF0G35sXATrXxrFQ6Qn6ZiR7c6VekeQ/UCU0I8=;
 b=wCMktTu+Pe3/JPii+woT1TGaWdN8/cw3IX0Ri4HpUicT0DeP8RKEdR4F0FjPRt2mlOSakHbTz5PoOxrYTDYrDnGZXdrxovky/U2l15p7obxUG2jHxrZYJrpUYNSt5D4hjZAXAu/p371e3kb6+D9ZNaOXu0ypB5j+Ncfc9P8gg3M5UhYd7sBbFw/hvHOFoO2RiAqzobGn/rOcWagCSEW7FMGbm4xbdHZYiIPyvSL61ZYGoTT5l5f+8hPThAD/AuVsTo+fH7Rgju673tR1B8NlPFI9wW2zy0oABEICW/LdEXC6NZhJft66FqlfgVOPBHPvaNH5rFpbo2/JYDeckS8Viw==
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=sK9BICF0G35sXATrXxrFQ6Qn6ZiR7c6VekeQ/UCU0I8=;
 b=SEk09z+vUrjjXCoqoQj8MDdJYs0zXNSy4FLH1FKLc+euxjpBkFxvM6JvgaD0M9fxf//MBoXWdGJcH2TFK3Ernb+72tFdTHkWmYvM7F3hJwaXfV2NlD5n3r4jwa4MZ2Xy96/+cmH1U8AFyaQwu0fIO400qrLaQC0jTa+LS9si+bs=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <37865b70-e69d-455e-9bcc-98e9924c24c2@amd.com>
Date: Tue, 17 Jun 2025 13:27:19 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 1/3] arm/mpu: Move the functions to arm64 specific
 files
To: Ayan Kumar Halder ,
 xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk ,
 Luca Fancellu , Hari Limaye 
References: <20250617111251.1711553-1-ayan.kumar.halder@amd.com>
 <20250617111251.1711553-2-ayan.kumar.halder@amd.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250617111251.1711553-2-ayan.kumar.halder@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR4P281CA0191.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:ca::11) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|DM4PR12MB6012:EE_
X-MS-Office365-Filtering-Correlation-Id: 47d8bec6-542d-44ca-4fb5-08ddad91ee8a
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?Q1NuMld5WHBHaEhJZzkvRGlGdklFc3Y5UjhjcTRiZFMyWXNGVE01Y3NLbm16?=
 =?utf-8?B?bzZRaWdLWndnMWg2bEpYbElZUlRwdEpDZm1VRkx4TDFzNTBUYmpZN2xZTjAz?=
 =?utf-8?B?eEdoUEZMaDZXcGJVWDE4K2xKc0tqQVpwekwrZyszRVBMMmw0N0s4aHlPYWNm?=
 =?utf-8?B?MGowNW0yN3gzdlFhME1ESHB1WVNXRGkvSXZTNFNoRnZTVWFrbVphNHA5WUJz?=
 =?utf-8?B?VUxhSkpYM1ZYU1g1amJuckhQeUtYR1NFOE91OGFxWHczczlIN3NrbWROL3dl?=
 =?utf-8?B?MytESXlvWTVSRzJORUNwSW9ka2JMRjdDTzZ3OFkrVEdOUkdNMkQxc213TFFU?=
 =?utf-8?B?dUZNTVhyQUhKMFZPK2ZNaWdQcDY2dEJSQ1p3blM5UDBnb2dtck9wdVJZd25W?=
 =?utf-8?B?T3JKSzZsdVI4MC9iakk4NEN4ajFsbno2NE9ET3EyRk9nbzc5c2p4Z005NlEr?=
 =?utf-8?B?R2diOVM4MlM0OWM0eVFqUlFiMWlsaVRVL1pZa3dFclNOU3ROZ2c5NUJkL21H?=
 =?utf-8?B?QlF0bnVBVitOMUY1ejVxWUY1cUwwOVp6SE0rNmVCZVhQVnJGRTJrU3czUmtL?=
 =?utf-8?B?dTUvdlhOQnVSOUo1dkYvTzB4WUNRck5mTXAzT1JwN3FvK1lHaTFncTlvZDA0?=
 =?utf-8?B?L1NGRDhJQ3ZFdURQTDJIbHl2WDd5NkpGTWg1b1ZlYUhtem5CSkZYem9Pb3Nx?=
 =?utf-8?B?eEpVcWVLeUJ6VWNqS25iQU9FTXpNdUdtVElKb29NL2JDNXRjN3dmcXMrUEJ6?=
 =?utf-8?B?ZjFVdzkyNkY0dXh5VEo4Sm5Mdm4va0NRZHhNdmc2dmtiZDltWTRvdnFVaWda?=
 =?utf-8?B?cit5VzJHTGdyQmVmY3Y1cEdlLzdKa1I3SWtLVHRTNXlDUTJFd1pPOGY0M1BF?=
 =?utf-8?B?S29sbTFCQ3BYNHBOcVdLU1JPQUErUWx2Y3pJOFlKMlhjZnZIcDRaTTVabHpw?=
 =?utf-8?B?eEN0M2dZZjZwaDFINXJaOGtUSVBkTFNadnYyRENhMmo1eFo4ZkF3RzYwdm9C?=
 =?utf-8?B?dnlMUjRmTDd5UXdCVllnT29CcHNJblVZYnNRMTJIQW45R0k0QXZnQjJ1VDlM?=
 =?utf-8?B?eVlqbVpCQjNRdTBkZmxHWFZaWHV0Z0dWNTl1ejZPd1pIWGtwNW1sUEFoN2Nr?=
 =?utf-8?B?VFkwMWF2bk0zOFNsK2gwMDBRVWxNYUZUeXpyWDVGVWdrWkJEUDdOZFhWNkU1?=
 =?utf-8?B?dVRiMmc0M3Q4VmlvaW90MmFaTlBnaFo1OVRSTXJvM3F5V1o3NFgrRFJ1OWpF?=
 =?utf-8?B?SHU4WlpsYWNjQVV3KysvL0tyMkwxYUZ4WmlQdmc1dVR3WW04NkpmMnU5ZFRT?=
 =?utf-8?B?ckJMWmEzU2Q5K1dsUWFKenhYWllWZ2RBWWlWUU5vVkJ5cEVVcFM1RlRFdlB1?=
 =?utf-8?B?RDMvZ0ZhU1pGK1UyaGgvakxMRHlhUk91dGxORXRTVUJ1QzVvZkNPUHIwOERY?=
 =?utf-8?B?dVhEVFFQbG9GL3FVTHpObDRhSnkxY1ljb3Y3bmtXSXVjY1FGaFpoK3lUbFdO?=
 =?utf-8?B?RTRJdHovQ1BlR3JhUlJaaUhpbVd3S3hIa0dXbTB3YmczWmdySGh5bGJiZjhJ?=
 =?utf-8?B?czBXWFRkTG1XWFVSYkdHTGtrNFJLTUhGSTMwbEs5WnBHcjI0OUtta3FLWmZ0?=
 =?utf-8?B?YzQ0S1N1eVJRRG1PUXVtRGUvVEdFTEdXRTN0MmUyV3I2Q2FTYlZrYnk4NXpl?=
 =?utf-8?B?ZHNIa1ZycXpaTVB3bi8wc3NMeCs3NnpLS0VzL0Y0RjVNZ2IrUXB5RkdIa1BR?=
 =?utf-8?B?MzJaWHQwRDVqL2JrOW5ZdWpQVXVGY1ZvTnh6dkU3em54bzJKSW1ZRnZrS3hU?=
 =?utf-8?B?RVFWcVZITUNPSVk4WmxlaDJESW9MUVhGSFUrSEluRis1aU1rMzZiQk9odjli?=
 =?utf-8?B?S2ZiQWR1UFdBRUh1SXQzS25wKzhMNEFiYS95czZFdHB1aHlBOUp1T1lSVE9w?=
 =?utf-8?Q?p+pBltZH+qk=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.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?Mk9IMi84aytMVDBudWxOTnZaSDJqWnpONytSZGhmeVFRSWl5bkEweHlRa0tE?=
 =?utf-8?B?RVlQajNUWmYxWENCVkIxY0taOGJpb0xmdUhOZHdvR3ZudEVZc3RCQkh3Tmdz?=
 =?utf-8?B?OEUyc3Y4a3R5c3RyanNCdUxmalJGbGJzVk0zMHNRQ1cvQ2YrVnFHSlhEK2tX?=
 =?utf-8?B?ZHZRbjlTUjk1R3BDdk8zL1ArUUdNSUFCaVc0L0FQcDQxMVVsdzY0RnJDeE5B?=
 =?utf-8?B?cXgxUC9JcEp5NmRwVHNPeWtiKzRRaVlwTDFOTjdUQWNPQkdDelV5RmdvSnZP?=
 =?utf-8?B?QUhkREpXS1VJcjlsWVE1UnFOaVozL1ljWTNSMUIvekttYWpteWxGbHBUVjNn?=
 =?utf-8?B?NUVFR3FtNTR4RnM5Rkprbk9SM0cvaTNsZVkvMHJlWk1obFJzM0JpS081cmZh?=
 =?utf-8?B?eEdFSzhxR0xaNkdzUkpPRmNaTXFWV0MvV1ROSFAraEpMbEhta0FZcHY4YTZn?=
 =?utf-8?B?SXlnZmZZaWpuVmoxdFlmaEp2ODREM2RJdUZxanVBdithejNmaTFOWG1ZODY4?=
 =?utf-8?B?M2E4MUhXYnRPalQvM2RWcFZVcFREYU41cUR2bjVCelBNSno0a04vREwycUpH?=
 =?utf-8?B?RFllcEdOenAvdjR6bEVvWkxxVWw5NXgyb3dUaXNQTXpYempabWlvNlFQYkxZ?=
 =?utf-8?B?c3lQZUpFVlppeGlLcjQ2eHh2ZG5vV05weGE5bkhHc09ZMzlYT2JpRUZkWG56?=
 =?utf-8?B?M0I1ZUl1OFRpUlFpQjdpRWZyM2lJZThKMFNLQ25MUUdCSll1c0w1SDNwNmlB?=
 =?utf-8?B?OFVGOEg0UTI0OGcyVFpGdmJmZENMbVBIRGxLMyt6QTE5UmdzUmRyZG1Vcmtl?=
 =?utf-8?B?cllNeGx2MzN1UzB5anUyOFV1RUhvZm53RmRadTh6UzhnNnZ3dHV5UHRZanMw?=
 =?utf-8?B?dmJyRWZVak5YV2RHWWt6Q2J3TUIybWtEN1czb2tBc01OK1NndWE3RTFBd1Ni?=
 =?utf-8?B?dWcwT3hlUE9zb3A1dHQrZld0OHpiRkdWVkpxYWVUKzZnL2sxUzlyU2pDakJs?=
 =?utf-8?B?YnI5UTBVVGExb044K0hpanpzUUZmcmU5bG1QeU5zRTNGSnJpMkVZQ3F0RTBR?=
 =?utf-8?B?V1RUZHZ2VVhBWFFZMmU1VHZXdkk4SGYvNkx1ZGwyOWk0TEYzSmxpYlp6TEdC?=
 =?utf-8?B?UDJFc2xmcVZSbXd2dmhTU0RDT09LbnhKTkh2bzNjTmxraFdlSVc0bHc4RFll?=
 =?utf-8?B?bW0wa00vT2ozcTFTQlRJRE5hblY0Y3duL3czOWF4VEpBZVVZbnJyYnlhVzRr?=
 =?utf-8?B?L2tlazBjamtIakRKMnRUMnM3TDhZclVCMEZzdVU3VnZRbGk1N1JQRkozdk9n?=
 =?utf-8?B?elhNSW42ZXNpZjc1dWNraEovTVdnRkhaNTN0Qm01bDFYMFlkSTh0MXE0SEEy?=
 =?utf-8?B?VzduWlJDVDczemFxaXhEMElFQ1M5bk9aU2lscStiREs4RDc1VUdZbzNHMDgx?=
 =?utf-8?B?YzdWODBzYWNwVVFic2RmQ3FsWEg3clVwREZhTDhFL1d0aURkQ3BPazRwbXRa?=
 =?utf-8?B?ZUNYdmlUYzJKSE5XenpMMHJwbEJFVktGV283aTk1Yno2OTZRUmVoTk1oeEFz?=
 =?utf-8?B?ck43MmNTUVM3VDFrMzBSRC9qa1JmZTVMbnUwQ1p5NU1WaXZRT2Zzb0FyZ0Fi?=
 =?utf-8?B?elRiV2psanZXNFhZTVdRcmFBcCs5QW03L2VJOXRMSC9FWFJndk1peFpONVhm?=
 =?utf-8?B?RnNIMWFFMnhCdmlRQnV2TXpqZDBSZU4wNlFSSHZtUnJFcW5YTmxIdWw3OEZt?=
 =?utf-8?B?b2R4eWxGdkxjektQakJvaG1PZFFYUzlwZ1ZBTU1DNHFiMmExcEFaMnEvZ1Mr?=
 =?utf-8?B?NHZMYTRGUk5CenNESE10cUpQdUJYaWlUdzlkY3VreGJPT2FhK3gyUDRBSGFZ?=
 =?utf-8?B?NWdUK3JDVWpxTlBOdGRjUHhIeko3ZWRWcmp3WDEvS0J2NmwyQVlpa3d4cjVt?=
 =?utf-8?B?eC8rMVhGbUZ0TmNhMkdQWC80WXpjL0VnT3NrL09DdGhFNnU1QkUrY3ZKeUt2?=
 =?utf-8?B?eEpQV0FWSkxXZ1YvMTFZYzE5N2ZqVnN2V0JndHZnVThzaHhMcGp0MzVyRWt1?=
 =?utf-8?B?c0RNSzc0eHczN2c3a1g1YjFZRThLa3A0SHFJRytWUUpJNzBIWmJsNE1HdWZ5?=
 =?utf-8?Q?f6Z0O7801Tnp2o3+DGOZ/4P/q?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 47d8bec6-542d-44ca-4fb5-08ddad91ee8a
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jun 2025 11:27:24.2275
 (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: PfFoa/N4za22eJ2UDVBqedyzT1NKDZufiKCOQhrscVvt6IXoCr7Tsmyq9nhTcnXP
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6012



On 17/06/2025 13:12, Ayan Kumar Halder wrote:
> prepare_selector(), read_protection_region() and write_protection_region()
> differ significantly between arm32 and arm64. Thus, move these functions
> to their sub-arch specific folder.
> 
> Also the macro GENERATE_{WRITE/READ}_PR_REG_CASE are moved, in order to
> keep them in the same file of their usage and improve readability.
> 
> Signed-off-by: Ayan Kumar Halder 
> Reviewed-by: Luca Fancellu 
> ---
> Changes from -
> 
> v2 - New patch introduced in v3.
> 
> v3 - 1. Add Luca's R-b.
> 
>  xen/arch/arm/mpu/Makefile       |   1 +
>  xen/arch/arm/mpu/arm64/Makefile |   1 +
>  xen/arch/arm/mpu/arm64/mm.c     | 130 ++++++++++++++++++++++++++++++++
>  xen/arch/arm/mpu/mm.c           | 117 ----------------------------
>  4 files changed, 132 insertions(+), 117 deletions(-)
>  create mode 100644 xen/arch/arm/mpu/arm64/Makefile
>  create mode 100644 xen/arch/arm/mpu/arm64/mm.c
> 
> diff --git a/xen/arch/arm/mpu/Makefile b/xen/arch/arm/mpu/Makefile
> index 808e3e2cb3..5ad15e93be 100644
> --- a/xen/arch/arm/mpu/Makefile
> +++ b/xen/arch/arm/mpu/Makefile
> @@ -1,4 +1,5 @@
>  obj-$(CONFIG_ARM_32) += domain-page.o
> +obj-$(CONFIG_ARM_64) += arm64/
I think this should be above domain-page given alphabetical sorting.

Acked-by: Michal Orzel 

~Michal



From xen-devel-bounces@lists.xenproject.org Tue Jun 17 11:27:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 11:27:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018169.1395095 (Exim 4.92)
	(envelope-from )
	id 1uRUTq-0001sR-F2; Tue, 17 Jun 2025 11:27:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018169.1395095; Tue, 17 Jun 2025 11:27: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 1uRUTq-0001sK-Av; Tue, 17 Jun 2025 11:27:54 +0000
Received: by outflank-mailman (input) for mailman id 1018169;
 Tue, 17 Jun 2025 11:27: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 1uRUTp-0001T3-6a
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 11:27:53 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20618.outbound.protection.outlook.com
 [2a01:111:f403:2418::618])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1aa49400-4b6e-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 13:27:52 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by DM4PR12MB6012.namprd12.prod.outlook.com (2603:10b6:8:6c::5) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8835.29; Tue, 17 Jun 2025 11:27:48 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8835.027; Tue, 17 Jun 2025
 11:27: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: 1aa49400-4b6e-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ClfxftURnuKe3l6kQXevRkytCcKzyZn4Eo5nRif4AQqtF8nXALaqannUuKe+xKKBUun5ZDPXuupwohibfM4zCBx6g0HRryrFTGaRkMCn5vUYNrn8XQP0Irqf0LifWYdP3F07MtyFp9MxzEgfzBDv/zcPPl4oZWCkD3ZIk5GllP0sHSOM00aBAar7RLxavtJoULUo7RqPlNWhQP7KxkpDEUCC2uBVZq7jKhqJ+ZET4pSOeL4/1M9ZLuz5Z0RWH6qmudj48rwNZaAjYaWtgCooirEMlJiRzOsnStqGuA5abQ6sC5yY3AT9piVJRDbXn0Kr7Zh0Tb/SEJ86fWb9wdLpxg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=fzTRSgf7Noak51by0NfK64ahBcITKG/+48ydLW45mTs=;
 b=xMGRR5SLPs0yRAgtVJiPf4mqzWkh1NO706Wx+dHkvYMhC77sgsugdb4oPB1o2XVebupm56HnvTMVP0+JP1haCXOIptTlklMwmrgtgFZUfUWt3pJvFlfMGIcnNzIedapOWd7xe+pYziZ1Z6HFcctm8sjsYxzO7Em7TUxoUcuOYV5gcQupDVxlFJWw/UTsDddDCwou9fPsBbdHg5iHae899qhbBUJhovQ3GCBaHCenHmpXMKAYguSrbEOc5M3jvfVZ0ba8SETZSak/V7O7n9m24yk97peSZDq5TYp3CcGuYNsook5gqIx8sFrOBmUMQjrot+I1I9d7stcYRjSqPTO8Uw==
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=fzTRSgf7Noak51by0NfK64ahBcITKG/+48ydLW45mTs=;
 b=jP78K1QeYDV4YGcQ9cRJCLvYpnJ+yv25N+HCD9pbAS8ijGlENkBk9j7mWiBvJzc20W2dEL4EyGcymAeZRF23FWFi1qRfNj5D424ftTs0z9sDTp1RFUdrBWqQKIR4MBFpaX1Z3reb9VrAKvIwkJCqvt6OVRQIwnFx2LJQPB8e8ME=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Tue, 17 Jun 2025 13:27:44 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 2/3] arm/mpu: Define arm32 system registers
To: Ayan Kumar Halder ,
 xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk ,
 Luca Fancellu , Hari Limaye 
References: <20250617111251.1711553-1-ayan.kumar.halder@amd.com>
 <20250617111251.1711553-3-ayan.kumar.halder@amd.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250617111251.1711553-3-ayan.kumar.halder@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR4P281CA0189.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:ca::14) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|DM4PR12MB6012:EE_
X-MS-Office365-Filtering-Correlation-Id: 59d7077c-7431-43a1-f9b4-08ddad91fd1a
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?cjBramZ6OFJleEJpQ295eXVkYWVqOUtRMXl3ZlhQbU95TmJyUTYySFRUcGk2?=
 =?utf-8?B?eWxKVFlHQnhwWndDaXBhaE4yWHFZSHNsZlAxYXVDb0lPS01sQWFnTHBNckg1?=
 =?utf-8?B?NUYxZ040TmRqZnZRZzVVaGF0a1F6bFFjTS9sQUVsS3crZzBwQjR2RnRJVFl2?=
 =?utf-8?B?TXYvRkJjUVh5WE8rS0FOcGhtZCtWVUVVbDhmRGJmR2RpWDNBNWtOZlRLbHdP?=
 =?utf-8?B?azdUZVRQNk1iYjNLbnpFYkI4QWJtdUllS0lucjZiQTcwMkpibmRvcXFnUmha?=
 =?utf-8?B?SU9FSHhZVWZna1NaemNBNzdFZlYvelY3cE5lVDBEdlBOaGNDK3BlZUN0L3dI?=
 =?utf-8?B?dWh5OU5vODg1OWhicTFxdndUSE5nLy9wT2N2dVd3WktPM3JnSXVXNVlVYWZW?=
 =?utf-8?B?OGNEcHl4NXZyNUNCQ08ybEtVUEV0bUNIdzNKNmZQaDlrd2dMQ0dpSHJIM05h?=
 =?utf-8?B?OGJrYXJSbE1FYThnVE5WZ0loUGRZaUMyc09zOEF0Zk9oc2RiYzUxMXJUNzZE?=
 =?utf-8?B?Z3Z3ZFRjWVJrZVVzMFgrRDVVWDBZRXdqdm1BTkJHbU55WVU4VHpIY2VMdlRq?=
 =?utf-8?B?eDN3WDdHMXY5SmFmR2lCVGFETGtSTExOekpPeUZUMGJEcnlhN0lIWnptWWhu?=
 =?utf-8?B?VldmZWtsV0JFcm1aMHdMNnl2Vml0TEJKZzNlNWFBT3hsQjZhMUVQazB0Uk1R?=
 =?utf-8?B?cys1VXk2Z05QcVlaZU0vZ3NNVHVxYjRJelFIeGEwRHQ3YTNWa0xUdk82Wkpy?=
 =?utf-8?B?ZmhvNWxzQ0I4Qy83dFI1Y0l3SkZnSStveFh3T2hiVTM2NDlqYUQwZzlCVlBj?=
 =?utf-8?B?UUVIUnRhbjRhMHhxdWlic3lFOS9UVlNGTFc3SnB4MHJhZEFtcmQrWitmMExI?=
 =?utf-8?B?Z2pEbHVocTdUaDd4cFZGRTRPK3g3VjY3K1ozcWVXZ0pVT3YzYThlTDdyL0Rt?=
 =?utf-8?B?TU1nallmL0l2NTFLbXN5dnRZUDdmcEIwTXdxbWlJYmZ1c3hScGRBbk5uWnJq?=
 =?utf-8?B?NytzamRCdVMwaFgwN2xoQVJOa3FJeDhvUUorYWkwaFJ4UlZKWklqTFhuZCtW?=
 =?utf-8?B?V0VZSUw4d1A0UlMzaUxrdGhVZjRhcW45eFdONm1vcVZMbU1EV3ZFd0ZIYmpi?=
 =?utf-8?B?TDVoSndQVUhFOUpZeHBLLzRsRGMwY0I2QkpIMDVyZmtnTFh3L0ZDOG9CcWYx?=
 =?utf-8?B?YkI5ekxXa2ZXeGVTUGtKclFiRU9LYkdkWWFCRDFvWS9IY0RYRnB1TDhVNEJH?=
 =?utf-8?B?TXc0QnpXMjAwSWc5SDFOMTV1RWdHbk5ZS3NPU1NMUWVaOFIrTGNFWEdNNVlm?=
 =?utf-8?B?aWE2ZDU4TWpRZGN3NkRra2FIRjR0M2xvZHNPSEZXb2hIK1B5cE9nRFhNSDJ4?=
 =?utf-8?B?ZVk3aHRqTnBwbHZLdEdRa0k1dzFFcHlINU1CMCsyeVllMEs2c1luOXp6YStH?=
 =?utf-8?B?cWY3MTcxT2xmckJDZS9XejZGZVVHYWJQZnZPNndPSURyQ25qZGpFb0JGWTZI?=
 =?utf-8?B?bW96bEIvcTlQS0gzWnduLzhZdVNUQU1ncWV5ZkFmU1RCYStQSEpzODEyWU5L?=
 =?utf-8?B?NnJqRUNnS1gvZDFyc2orelhkcGtIdkdsY0VTek1YNHpzT2tWcElXMDRBaXpX?=
 =?utf-8?B?a1UyQ1YzVnlRMGJyREhwWDk4L3RMTWNiQ3gvQ2tWaTFVTXlRQjRyWnBTT3JN?=
 =?utf-8?B?VGgrdHZBRDR1cVhqRENScXZ4d2QzeGUvbmRDM1Y4NzFvOFh1aGhKWVorSjJy?=
 =?utf-8?B?cnBJa3BldDd0b29SSnZkVlNzQzVjTzczc1p5SUd4K0hLdW5BazFaU0N3L3BU?=
 =?utf-8?B?U2s1dE1ybjhrcjNPclNmcDZwQzdvd05vdTZUT3BTQ3RNWS96TGhvZXFzbVY3?=
 =?utf-8?B?dHg5L0ZiK0MxSnhnYXlyM1FPQmY2V2VmUlNFOTNESTBwdmVHRGJUSiszWFRs?=
 =?utf-8?Q?pNLtH5iKPsA=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.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?YjBEaTIxMXczNklTYjBFV0dDUW8xbmZySlpISzFuY25OR0Y3eDFNMm14S1N0?=
 =?utf-8?B?TEVsdnZyOUZyQ3dKdVlBUG04RHhZSEVzTnlIWmtZNHQrSnpoQ0ZjL1A1V0ZR?=
 =?utf-8?B?Wmt2Ylc4YVBZWEZ6TVdSU1NyN2tEODVlZlZRUndIQjZzTlpoRVRwM1JUai9w?=
 =?utf-8?B?Uk9JYi8vWGF4djdaTkNvQXQyYjJ6eGcxTFNLak9JdzFONkkxVmJmQTUyb3hW?=
 =?utf-8?B?NEVCR1NDRHlIMGp3NGlKaS9XcHpPZEpjMUtjcUdqZTA2Z2gxV0xRcmxpVVJV?=
 =?utf-8?B?REhzRGxsajh6a3V2ZU1VNDBNeU1jU3YydTMzcnNZYS9EbDJISGswNEpJaVBr?=
 =?utf-8?B?MGlpNG5CWXJOVk5UajJEcnh6MEJLc05sUW5reVJqWWNyaDFRckp0ZDhwMXdW?=
 =?utf-8?B?RzdUSmFsT2VVbzVjTGkrSjhoRFZXWGxPcDFJWE1YQU81eWRDVUhYZytqVlkz?=
 =?utf-8?B?Q0RIZ1loR3NuRmZtVVJJUzBnMFl5N25RUWxpRTNYYUlRcVpjaE5CNk01NnAy?=
 =?utf-8?B?dWtMMnJiM241dEEwL2NSNXNrbTNpWjFDVG5OeDJsOGlod0dSYVh2L29QbTlG?=
 =?utf-8?B?YWR1YXFkY0hzTDV5dnVzWko2OGNPZzJhd3hqZUtrVnRuT2pKMGJDdHVGenYx?=
 =?utf-8?B?LzlrbkxhTlFPNlRwdXQ4YVFsRnJwUFpNaWtiRlNnMzRFdWJyRnNjVi9hb3k3?=
 =?utf-8?B?ajJST0Q5RmFoeWt4dmdLWC9oczNzUGhkbWU3ajl3VUJFSXg3YVJ0dXc3aW8r?=
 =?utf-8?B?bzAremp5ODV6N2h2aUpXVVJxeis5YjBZaWs1MUY2YUZDaEM2QUVVTzQ4Ykkv?=
 =?utf-8?B?am5hVUJMbGNXZVhWZ2VXTDNya2tjS0xWeDFCam5NVlpDajhxa3dLOW9oSHdv?=
 =?utf-8?B?elRlWWdVbDJLZThTbHpDb1hFQ2phOE9JRmU3R2tSa0YraFEwTVg3YUkxMlFO?=
 =?utf-8?B?NFdlVUF3YlpWdVpOL2NLTnNQVzAvY1RSUndmekUyQTVRVGhveGN2V0M2OENG?=
 =?utf-8?B?dk1hY1lxVEw5c0tOQno4NHJheUx1YmVvOU9VUjdhSE5BSFg2ejVsNU9mUWt6?=
 =?utf-8?B?eCtFSGdSbTNKUnU0WnZYWldCR1g0TElaQ3ozWUVxRlNKZzRjT1FkQTJENXB0?=
 =?utf-8?B?WlJwMjZoWGs0QXM5UmZPSFBScWovOXExbXBHdVREUS91cFkvM2hYc20rWlFO?=
 =?utf-8?B?ZEg3aGorUDdJemNUR01oQ2ZyYnREOG9BaUlMT2NQWWNvYjlmaFB6czF1cEhV?=
 =?utf-8?B?cjN2UW5ZR1BXMGtqM1IvQmlyTCtDalVPbXZRbFZLcnE5ZnVVUE82VG5jSi9m?=
 =?utf-8?B?ZlZkZVU0Z3g0d2prWXE4bGI4ZGNFWWtLZExiVlBoR0JrSU9lUTZEWXM3VS9P?=
 =?utf-8?B?b25QTDJUMHVTMWFWeGdvTDdlM1o1NnFLcy9qbS9VZms1ZW5qT1prMUtSS2NC?=
 =?utf-8?B?Z29NMUZ3aVBNL2JuU3E2UTF2TVZKVmRVdFRYa2dBa3hLTy9ucHowVlQvOVQy?=
 =?utf-8?B?eTdUVkY5REtSTSt1UW0zcUpYc3JCb3FzUFVjR0xIS0doMEkxcHBEWUsxVjd3?=
 =?utf-8?B?SXM0ZTdPMi9jeXovejVpVlNJc0w2bnREcGU5YTUvK3VpejRqOFVRYW93amh2?=
 =?utf-8?B?SGRmQVBsWURMai9FMjg0RTBHYmMzaE1zT1Q0N3lLYW9IMjNWKzJCNXlWUEVB?=
 =?utf-8?B?U0plRUwyMWdkVUM1R20vLzRLUmxsaXhISng3eldscXBPdHg3aVYyS2RVd2NH?=
 =?utf-8?B?Q2l3K0N3WE5FRERYdGxTakpObkZZd2Z0K01JWHE2Z3NRdlJJcUZYU3lQSFY5?=
 =?utf-8?B?aFp2cTV5cGcwWVM3RWFlU0MxbGc0YUlyeVI4M0s5VStKdlQ3OHczNkUxMnAv?=
 =?utf-8?B?L3lDdFhrSWtleVR6bDk4bjZyRThKY2tNNE1tRnFoNEdSQk8vazdqTlRWYjRp?=
 =?utf-8?B?NHhtRWgwY1lnR0o3UmorTk5vZTVtbWkrR3FadHFWVTEyTUFzMTI0b2RhNjBJ?=
 =?utf-8?B?bUt3UTJoSnVpUkNvdnI4a1VNZldDRUlKZzNaMHkrUUpRcmN2c2k4NmpYaVMy?=
 =?utf-8?B?YUZOR3hmajludjVWb0E0UU1QR1B3d004a1dDd1Z4SDIyTDdmYUtoQnBkWit3?=
 =?utf-8?Q?cZVoPvrh4vRB4HpjzXw+9jzBz?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 59d7077c-7431-43a1-f9b4-08ddad91fd1a
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jun 2025 11:27:48.6825
 (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: FhDuqmtnljJRhZRaTk4/n7iypNG6DPcIvI+Lizmr6DkozOcY2oLv9nABFXv/YFif
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6012



On 17/06/2025 13:12, Ayan Kumar Halder wrote:
> Fix the definition for HPRLAR.
> Define the base/limit address registers to access the first 32 protection
> regions.
> 
> Signed-off-by: Ayan Kumar Halder 
> Reviewed-by: Hari Limaye 
Acked-by: Michal Orzel 

~Michal



From xen-devel-bounces@lists.xenproject.org Tue Jun 17 11:36:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 11:36:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018178.1395105 (Exim 4.92)
	(envelope-from )
	id 1uRUcL-0003oR-7X; Tue, 17 Jun 2025 11:36:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018178.1395105; Tue, 17 Jun 2025 11:36: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 1uRUcL-0003oK-4o; Tue, 17 Jun 2025 11:36:41 +0000
Received: by outflank-mailman (input) for mailman id 1018178;
 Tue, 17 Jun 2025 11:36: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 1uRUcK-0003oE-Mw
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 11:36:40 +0000
Received: from NAM02-SN1-obe.outbound.protection.outlook.com
 (mail-sn1nam02on2061e.outbound.protection.outlook.com
 [2a01:111:f403:2406::61e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 54c3e7ec-4b6f-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 13:36:39 +0200 (CEST)
Received: from BLAPR05CA0030.namprd05.prod.outlook.com (2603:10b6:208:335::11)
 by DS7PR12MB6141.namprd12.prod.outlook.com (2603:10b6:8:9b::15) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Tue, 17 Jun
 2025 11:36:34 +0000
Received: from BL6PEPF00022574.namprd02.prod.outlook.com
 (2603:10b6:208:335:cafe::7) by BLAPR05CA0030.outlook.office365.com
 (2603:10b6:208:335::11) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.25 via Frontend Transport; Tue,
 17 Jun 2025 11:36:34 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL6PEPF00022574.mail.protection.outlook.com (10.167.249.42) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Tue, 17 Jun 2025 11:36:33 +0000
Received: from localhost (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, 17 Jun
 2025 06:36:32 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 54c3e7ec-4b6f-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lOCG0I4flZ9h8dEWxSBJL8Bjju1Ix8G3YoxG9H47BLidE9NbPTo9S4Jjd/YTKT62LdtWsgtB+Qy6LidWWKMl2Uuk7riMBhnlqoonLd37JTOKemz8/b0jGjmLBxK1BAaGDhSSoqP9IWMqd0NMh+VrScIvouvA/Z+3QTWCUCSESuEcSuaNaqPHWqPPrmaTfrXozdC+GtPe6v7/JcLjXjqrnyL879d0uQbI1Y+uMCJTT5ZlTixz0VOL+as0Lpjd1KQbQWEZyIsBUy+CJLJ1/u+Xcpsen1sbbCXCBlep4wo5pcYMudj5Hj1n05Ae+9f0GPAoqh4cddwblwmvaifInbslRw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Q+hLMQohkGA0mRWXwRR+PeBKyEaJsyg0lqF1Eox3Abw=;
 b=Ki5RS7ASAWrg0c6AZjNhaoIr6cFB/7k4Aj0aOFOA4PuBUiapYfRQy1HIfHY/CguSCtWC5wWua32EWuwS5O2v8jauL3+aw7Bu/HlyyCA/HgYcNM+tADIQ6QYdWnuuaSrLWufqt4SeOCoBGWKc1W5ihgHCeeF5VwvkkxHCemm6FqOnlWRRc2Jcvc12caTLAVJpiKOlpQ0h2JmdxS4WYP05ttTuDK+YISEwYOnQ2a3+W5kowJovmYVI6Andn4d5cOUL1hMIij554ERvbcBXDF+PU+makNk6nHzJov1tnrUvyERL+46Hm/z1n0v61TckEiRuX+V0hq5acMtftBSDkctHrQ==
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=Q+hLMQohkGA0mRWXwRR+PeBKyEaJsyg0lqF1Eox3Abw=;
 b=dhozMuaI68KvpB/3YGIy3HQQNL0p1csASiDfdxgrmY3WB/YkGMxp8cJ7e2gnjkX6cWU7wNYTKCQXUymgnX+l8WwheXE56Wb7rbwcVPol9fXAjmIWrC6N3PEbETkcqXdiXsNLqE2jM8MiuGq0gKHauBjJcRa5qHsZ/m1MMMwp8b8=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 17 Jun 2025 13:36:30 +0200
Message-ID: 
From: Alejandro Vallejo 
To: Stefano Stabellini 
CC: , Jan Beulich , "Andrew
 Cooper" , =?utf-8?q?Roger_Pau_Monn=C3=A9?=
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Daniel P.
 Smith" 
Subject: Re: [PATCH v3 05/14] x86: Replace arch-specific boot_module with
 common one
X-Mailer: aerc 0.20.1
References: <20250613151612.754222-1-agarciav@amd.com>
 <20250613151612.754222-6-agarciav@amd.com>
 
In-Reply-To: 
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: BL6PEPF00022574:EE_|DS7PR12MB6141:EE_
X-MS-Office365-Filtering-Correlation-Id: c12f32e2-f9be-4df9-7c85-08ddad93365a
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:
	=?utf-8?B?VW4yVUdmOCtYMHNDSndWR2YwUC9BNG1pZytIeTZFSmZYK2dQQ2xiQjNEdXNm?=
 =?utf-8?B?dHJKTjBBRFpkUy9DZnFueTJVRW9lMjlYR0NpTkx2cGVrcFNyakwvUWhEdEZN?=
 =?utf-8?B?UGhUVDdHOUNXT2hrWDV0Unl1a3JiQVdLWUhHQ0lTekcyWGxFYWREekNXNEJF?=
 =?utf-8?B?VWFmSk1uQTNQWS93Q1hkS3FmZGdMaFMxZVBzenFTcnVBY0lja1VZNHNjYXJL?=
 =?utf-8?B?L0kyU0o0UUdXMXhIMDNnbjlObmMrL0tYV1BGdFBFeTVmR0tGWk5GTXdrdTIx?=
 =?utf-8?B?OGc0aGIvV2djZ0JhRnBlOTFseHdQY1ovQmNJSm9ockVzVmQ2eGE0NEJWZUFZ?=
 =?utf-8?B?VVBtWnJCRU5tVUQrcmxHV2wwMkFOV3VKbS9CSktDZ3F5SFpkS3VKM2ZGU3gx?=
 =?utf-8?B?S2JGUURaakhCWFhLS2RPVTJyM1V1cXZDTEJ4aFhvTGNYYXh6cUFoRmc4UjB6?=
 =?utf-8?B?QWMwWms4RjhtZ1NxVEkrRm1ZQ3lWQlRoRjYzQWJWZVB2UHdCTUh3cHBOZ2lG?=
 =?utf-8?B?MmZKcDRiYzEzbWdGZHpQdUZ2MVM5WVd3Y3p2YUE0RTZTVndKbkxuREhQWG80?=
 =?utf-8?B?NlBQeTVWVFRiNlUyajAxeGhhRUR6eW1EUXVWQ1p0S0QvQUgyVHBHL1dNbEd6?=
 =?utf-8?B?QnNVbjlaS1FmdVBjMEdLVkVZYWNaQnlIM3A2a1VVbTdGSWlLTGNwWDZ3YXZP?=
 =?utf-8?B?YVU3Y3NBUEp2YmFjYkZqYUVHQnN5b1NLSUlpY0w5dzBUNWpEbmxEc1hWSW1K?=
 =?utf-8?B?MEJkYWVyOXluL3YvOUg3OThpR0ticTdka0p4UEtwdHBGaWh1MmZkNWtFTEps?=
 =?utf-8?B?WEpDc2hpVGJIc1Fsd1czeTFETi9laWRaOHgrRXRGQnBTOU0weDVXeUJlOC85?=
 =?utf-8?B?REwrdndaK2VSd2luVDBxRjNDNEZOOU5SeS93dzRuZHdXa1Vnc1Q3RGsxY0J6?=
 =?utf-8?B?cUtlNVhlZjZBQ3JkUis0eGNGNWRMM2hxaEk1bXZwb20rbTZub2tGdHg0cEFF?=
 =?utf-8?B?NklsNWxGa3NNNElaa2FnNkZLQVBaSDRneVRkb0tReG5JL0U1RnpNMSt6RVFt?=
 =?utf-8?B?NExRdnkxbmVxb2orc0hzN1NzeFJ6U29FZU5VWno5bXFUWDYyM1hpTGFRYnJE?=
 =?utf-8?B?ZitaTnNkWnBHTUwvMzcyZTNGamdHL2RGNk0xQWlCd0JhektTWGlyUWNFTHZT?=
 =?utf-8?B?NDJxeFBHUEU0c0tGQ0NhaTBKQ09vK3JoM0Q1ZWhid0lRTFBzbGQvQ1VNQTla?=
 =?utf-8?B?M1NwNmtBQ0k4STNnWE5RUHh4VFQwRWxXZ3d5bzVFd2RUUFgvOE9vdzlLa05O?=
 =?utf-8?B?QTFQVmJ0c0tQdXhMcHZod3RyQjFGR2FsOXBmZHVBRjMvQ0h6WGxUU2VoWXA0?=
 =?utf-8?B?NThXa0RyTW1HQS85Z25PdHFyb2ZJbzFadXlMeTlzMmpPbHlNNHNRbVBONnJ6?=
 =?utf-8?B?ZmMzVCsrOEhUODZ4ZXh0NmphUSs3SjR0cVQzN2N3TVpkSjNuZm1pdFZpSk51?=
 =?utf-8?B?SExTTnZmd3BheWFZanB6a0R1aTEvUUxMdzJWZkF5K3NIZ2ZjQ0tLc0NJRzFB?=
 =?utf-8?B?ZVlqT1N3dzJCSW9vY251UEJhcFEzeC90Y3pDcC9Ca1R4ZFZNWEFOT0RaT1lt?=
 =?utf-8?B?N01ZUXFkRzVsT0I1bk94aXFSVjQzdkRnMTRsUlhmWlA4U01CZG1uTEw4akZK?=
 =?utf-8?B?NkpJTzkwYXpzdWRtUm5CdjJlRkxMZXdEUkdVR29Pc0QweWdxUlpJa1hOK2FL?=
 =?utf-8?B?ZVhUaCtobGlyRFljVFhPODBESHFXUmlFTi8vMzRHTFdTL3J1T2QxRkZ0WDEz?=
 =?utf-8?B?clVvOXdKa09uK2V1Tm5SK20zbjk5eVpMdWxpQVNBSUttZjl3ZHlwUWhTaHdO?=
 =?utf-8?B?b0pwMXVuNVk3dmVaZDlmSk96YSsvekdiZ2pnUHZJOTk3T2FRMHdUK2NRTGlo?=
 =?utf-8?B?SFcyM0tuNi8wbS9RYmVLa01pV0MyNzlxOFVHOFcyeW9sbWI3dDZzM0NZajB4?=
 =?utf-8?B?LzVwNzR2V1JFSk5haHZkUUV4UGlKVTYzZnVLV2FtSGN6bUk1c1dsR0NlWFZj?=
 =?utf-8?B?TCs3NUNzdEVwenUwODhXVmlpQlhBeHpVajlDUT09?=
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: 17 Jun 2025 11:36:33.9705
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c12f32e2-f9be-4df9-7c85-08ddad93365a
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:
	BL6PEPF00022574.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB6141

On Sat Jun 14, 2025 at 2:54 AM CEST, Stefano Stabellini wrote:
> On Fri, 13 Jun 2025, Alejandro Vallejo wrote:
>> diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build=
.c
>> index a038e58c11..8d2734f2b5 100644
>> --- a/xen/arch/x86/hvm/dom0_build.c
>> +++ b/xen/arch/x86/hvm/dom0_build.c
>> @@ -648,9 +648,9 @@ static int __init pvh_load_kernel(
>>  {
>>      struct domain *d =3D bd->d;
>>      struct boot_module *image =3D bd->kernel;
>> -    struct boot_module *initrd =3D bd->module;
>> +    struct boot_module *initrd =3D bd->initrd;
>
> It looks like struct boot_domain is still calling its member "module" at
> this point

Bah, yes. Way too many lines in the diff.

What's _really_ fun is that the pipeline passed. Including the job to build
each commit.

  https://gitlab.com/xen-project/people/agvallejo/xen/-/pipelines/186863671=
2

I'll have to look into what the hell happened.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 12:11:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 12:11:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018203.1395115 (Exim 4.92)
	(envelope-from )
	id 1uRVAC-0001Dk-Ua; Tue, 17 Jun 2025 12:11:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018203.1395115; Tue, 17 Jun 2025 12: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 1uRVAC-0001Dd-Rn; Tue, 17 Jun 2025 12:11:40 +0000
Received: by outflank-mailman (input) for mailman id 1018203;
 Tue, 17 Jun 2025 12:11: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 1uRVAB-0001DX-SH
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 12:11:40 +0000
Received: from DB3PR0202CU003.outbound.protection.outlook.com
 (mail-northeuropeazlp170100001.outbound.protection.outlook.com
 [2a01:111:f403:c200::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 35cb093f-4b74-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 14:11:34 +0200 (CEST)
Received: from AS4P190CA0014.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:5de::18)
 by DB5PR08MB10287.eurprd08.prod.outlook.com (2603:10a6:10:4a5::5)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.26; Tue, 17 Jun
 2025 12:11:31 +0000
Received: from AMS0EPF00000196.eurprd05.prod.outlook.com
 (2603:10a6:20b:5de:cafe::5) by AS4P190CA0014.outlook.office365.com
 (2603:10a6:20b:5de::18) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.28 via Frontend Transport; Tue,
 17 Jun 2025 12:11:31 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) 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.8835.15
 via Frontend Transport; Tue, 17 Jun 2025 12:11:29 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com (2603:10a6:5:1c::25) by
 DB4PR08MB8101.eurprd08.prod.outlook.com (2603:10a6:10:387::19) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8835.27; Tue, 17 Jun 2025 12:10:55 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668]) by DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668%2]) with mapi id 15.20.8835.027; Tue, 17 Jun 2025
 12:10: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: 35cb093f-4b74-11f0-b894-0df219b8e170
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=P2vQ55CcVn4k0FOC3YGQs9DAKXwxx26QCJ4UNa+E2YNi/hyjGlkLyOjPwrNv/dOObhvzjgQOJe7yHKoxmviBaf0KLPo0DkPaJsrOxZEEcE2nUvl1EmeIlmSJ0dySgayEvaHMyjezlvBwS9WGS46ieEH8YA5LsI5AbkrFuZHgqlqBPIlngLfNgE4xD22FBZktla2uI0pq/+mgVd/UA1srlSeCEA2uhMbD6Wn8teDcELbWRNHZKF7t6wpVGK5UqJ+NqPPaKGfeWQtulcul3GjLlIExgr8pICoUXsDh8WIZEh4u3ZGj6qfWq89IRDmnHXE7UQoU0fHkAXBkyv5JtzGX+A==
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=olLLjdyqXVGiqCNTPf9sFi0kcBRSa5KdI4XNMGPFlgo=;
 b=eIWEtG77b51slEJ4YBQ9ee4cEVH4xJgrKWv1+F9yvbUKGxVb4AwO0JlN795ZGQ70eJinFLvempCZGudh5JUyU8b7EQ1X/a0ovuIMYV681QhhiviUhh/FMuLg3CzSR4PH+vw8vIj+D3CYCuWO0mfZoQstZm3+6YpNvD2RZvJZPtsp3r3diCk3GcuETS6jNCEFZUADBIU/UgXViN3BCeLTYNfPnA8OuHOh/5AMyC1rpqUF1d6c/tcndx85USn2Qza9u6bLtfZ2TrvVmnHPt/FfBNpXAU0dGuvxCbMVCIlQbB5J5qG9wgl76kKFF5QcrBlIOMqBbgCC1HKEsJ0+TAHJnw==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=amd.com smtp.mailfrom=arm.com; dmarc=pass
 (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
 (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=olLLjdyqXVGiqCNTPf9sFi0kcBRSa5KdI4XNMGPFlgo=;
 b=CNW5w16gfUIxDih7hi1Bkx1mrIBHBpEy6Ylc/dhwMwx0Ra02qu1shMlc9t7yOJqED19oPdTRRgVxDcNNW90ISRxyxRx3A5o5TjFSNn80jGu8HvkG/lZAOcOMhKT0Vus/bTLbCukAV9RYuRdQkkXpY1qcZU732sRtWwYt4EKaXjw=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=dc+1ubszXks+zfdK5Na/n4XyQDTwVK7IaSqFELuCwdcYlKvc0zttY8GaDKpGDdeH5zHhu/+AkeS/7gMGyrJsZTG3Apv1GCn81QM8MCU8EEC7zeNTSYXjwNC92Vqs0y7hVmdZ7zsGi4wQHF7GfhdnJAsSZt0UROx/xZPg/omVLh2o1HJgZCeUWa3P2ykKeWM+FfjAd7YWATr+W7eu7ymMXPI1uokTIh0Cxqek1nkoM51CWMgeBAP9TSYDEN7rttXK9d1Tr61N4AChlTdbc8ojZ665E4/d51cNpj1QZUvmcADad/K6EeD98iU5U6KM/2YsQSVk6KkUxfqMQWudqd2Wbw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=olLLjdyqXVGiqCNTPf9sFi0kcBRSa5KdI4XNMGPFlgo=;
 b=Ta6lUy9Da2/kur1lxsA+TeQF2+31umt3YTqar5Wjgh0KcVMOh6NmKFRLXwihA1etf8jt1jYlYnHKT++RuOc2iNTKoe03/130QiGywSU105ZDDnLJNj9lugJBWwNOYjHUMhuSVk69pYNaK8hBT1cXKyA86G1zabMI4aVZO/n5HbE22nQWnbX/RIbfzNtlEX4yPGhaT7wHxyXL72gKlEWPf6XwFRfSAH7lbfNy8uv00UMryutUKhEMBYMuGdQtzsn9MqQc8eDZnKeca/W7wMrhePLB8AvFJc0bG4yA2dQrWMPivaDylHV1KWFgpsAPuAcD7BXO1RYIHXrqSFduf6sP+g==
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=olLLjdyqXVGiqCNTPf9sFi0kcBRSa5KdI4XNMGPFlgo=;
 b=CNW5w16gfUIxDih7hi1Bkx1mrIBHBpEy6Ylc/dhwMwx0Ra02qu1shMlc9t7yOJqED19oPdTRRgVxDcNNW90ISRxyxRx3A5o5TjFSNn80jGu8HvkG/lZAOcOMhKT0Vus/bTLbCukAV9RYuRdQkkXpY1qcZU732sRtWwYt4EKaXjw=
From: Luca Fancellu 
To: Ayan Kumar Halder 
CC: "xen-devel@lists.xenproject.org" , Stefano
 Stabellini , Julien Grall , Bertrand
 Marquis , Michal Orzel ,
	Volodymyr Babchuk , Hari Limaye
	
Subject: Re: [PATCH v4 3/3] arm/mpu: Enable read/write to protection regions
 for arm32
Thread-Topic: [PATCH v4 3/3] arm/mpu: Enable read/write to protection regions
 for arm32
Thread-Index: AQHb33jUYqpTUMJwa0i5eroPaBJrrLQHQquA
Date: Tue, 17 Jun 2025 12:10:55 +0000
Message-ID: <918086D9-A60F-4A07-A898-DF9AD3610191@arm.com>
References: <20250617111251.1711553-1-ayan.kumar.halder@amd.com>
 <20250617111251.1711553-4-ayan.kumar.halder@amd.com>
In-Reply-To: <20250617111251.1711553-4-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.600.51.1.1)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB7PR08MB2987:EE_|DB4PR08MB8101:EE_|AMS0EPF00000196:EE_|DB5PR08MB10287:EE_
X-MS-Office365-Filtering-Correlation-Id: 7f9b5b63-f655-4393-e2a7-08ddad9817ab
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:
 =?utf-8?B?Si9TdHNnR1huTmZnMXNDakd3MStNcUtYSldYeStYR2hmUjJBV3hHV0ErZXFU?=
 =?utf-8?B?OC9XS3JjNU9IUUtqaG9vdGhyaHJJNFZmTExJbHljQVdjd3laQWQwTDZSTkJu?=
 =?utf-8?B?bEJrTUlMSFhaMmVDbXBkQW1PRVpCa0ZQL1QyeGp0MjhqUTV2ZUozK2FMWEVk?=
 =?utf-8?B?VGRLUTFWR0o3U2xEZUpFSzJEdFRWUnNITzVvbGcyWjAzbWJTeFgyeFRMV2h5?=
 =?utf-8?B?RTJoZVY4KytUWk1pTmhpNmZxVi92MFNON1ZiSnFNOHVqSGFDblVnSk82MkJ2?=
 =?utf-8?B?WnUxRVNwbG85MjREYkV4bEIycTlFUnpZZWNIWkZ3MUR5QjlyeTBWdDdzSTgx?=
 =?utf-8?B?dkJoSHlWUjJWUEI0cVJMMlM4V3ZTYS92N1VkSnR2aDlaa3BzbVhCU1ZMVGNj?=
 =?utf-8?B?LzdKS0J1WE9aNTFwV1FqblVOZ0QydVhkeUpmRDFRWk9FZGdkOEVLb1NweTF1?=
 =?utf-8?B?N1k0SitKUCtnalMrN3Bselh1STl1b09lZmJnRnU2cXB0N1QrNW1lcjBWbmdK?=
 =?utf-8?B?bm9pU0xVVUo3ZDU4azhaUzBqL1lOaHhsaVo4TkFOejRSWUpvSlNEN29qTFZz?=
 =?utf-8?B?eFgwbjJLdTd3bngwclJjVFFWQ29hdnFET0RPMytpR28rUHgrOXhYeFRIUnBB?=
 =?utf-8?B?Nm5DcGNsNHl4NHJlejh3SStvSHpxNG1pOHgzN004ZzZPbWdQcWxWR2x6OGlH?=
 =?utf-8?B?WmhleFhtQkd2VkRyMXhtSW51ZHlKczhQcmNuS2JpT2tzaEpKRXVmcTllSFNp?=
 =?utf-8?B?QXVxRVlnbVVHVlYrdUZaeDZWb0tucVc4Rzd4SXA1Um92TmxVSUNESkl4cHlr?=
 =?utf-8?B?RVRnQnk1Y0xtWnJFT0VVOHBkRXlDZy94S1pWVWhFTEc2SVdpV2U4NXpaUDZB?=
 =?utf-8?B?U0srRUQ1aUR2L2lsbHNpSnM4cndNT3Z1S3VWcjJ1MnZWcjVtdDNvNm5aaFBM?=
 =?utf-8?B?YmlybDI4RmZWT213c2JwOEQ5TTdnUGN2QXo5RERLYlhJMnhVc0dJdi9wbVgy?=
 =?utf-8?B?RnNINmp1UHBVU3hyRG80KzZER3MxZTFRQWYrTVhhSTR3MGE1MlR2VHZyVTgv?=
 =?utf-8?B?REJ1eW5ycWZZaXFZbDlhcjFUM2RmTnM3TC9VaXBhTy8xR2pEVHp1cWhXZ2ZD?=
 =?utf-8?B?a0ptK05IZjVSUks2NlFvaC9PU0MyK3VFVjYybkhESEhjV21BQm1NUFpTejUy?=
 =?utf-8?B?d2JNcXFIV1hjNDFQaEJmNHYwaTRvUG0wSFpzdUNWZzBINTNEMVRJVFoxQkFF?=
 =?utf-8?B?MGhWTDlnekorOXAwUUg3cVEvM0U4eWFCRDhSdkFUdEtWVWw0TS9DV0xDRmZ5?=
 =?utf-8?B?NEVlODJyMStsY1Q4Z25jbThKcEQrMXYvT2R4dkRpZmtpeER5UW4xU0JNcnNT?=
 =?utf-8?B?OUNnZWhTdS9zUTJ2dDVRL2gvRDVxRithWEZiRGVNMmVZQ3U2azRKL1JCM0Zy?=
 =?utf-8?B?ZUdxNGFkNi9hWHA5eFM2Zm02VFZBT1dCWXVjVjNLY0ZGUStRdGQzamVrK1Vm?=
 =?utf-8?B?RytIcHdodks3bnhhNVh0aG5BQ092QVpzOG90VHBKRU9SaG03MCs0MjBFMnR3?=
 =?utf-8?B?NjhKbGhaM2ZtbkFEMFpNODdGZktqV2J4K2JXajVST0p5ektBR0VmdTg4Qnpr?=
 =?utf-8?B?RVVRdXQzTDQyQWtYU0Yrc3NiOFk0d01Nc2w0MzAwUWNDRnVLbFc2b3gvaGMy?=
 =?utf-8?B?a1NjUTZFMExMdEVtby9BNW10QUJlWk8vcWJqYzRiYzBmMzhKVTdac0pJN2c0?=
 =?utf-8?B?Y2VnVU1yMU5vSzFkeEpJSnZlSU9YdTl4SE91RXovL0YyR2dQVytEM3NzRVZv?=
 =?utf-8?B?M0dxU1E3OVJJdTlFekFjdDUxWlE4MVVxbmtDRFowZXhPL2VKbjZuYkUzMWhq?=
 =?utf-8?B?RW5WUnFDQ3BoV1Y0dWlCMktTR3VlZXd6ZUlWdE5IWXRTSWkvOVZNS0xpQi9G?=
 =?utf-8?B?akhxc3gzbkdQL2htbXN1OHN4blQwMFN3dzVjd1lkMFFrc1NRcWdtSTVEMnE3?=
 =?utf-8?B?aFU0VVFwVWlRPT0=?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB7PR08MB2987.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(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: DB4PR08MB8101
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AMS0EPF00000196.eurprd05.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	f6bbf9e0-426c-4635-7c9b-08ddad980322
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|35042699022|36860700013|82310400026|376014|1800799024|14060799003|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?aC96VlUwR0ErMll6bmdmL29vK1ZSbC94MU5oOFZQai9wbzNjRlV0ZER0UWRY?=
 =?utf-8?B?WjFhUXdoWmREZnVOc0loaU45Snkxams3eDl5SFIxMCt2M1AzQ2lRS0U2NUhY?=
 =?utf-8?B?WEo3U1Z6TGV3c2wyUEZIWVFUbHpJVURxTUVTaWFiUjZwN2dqWVB5VmRvaWRK?=
 =?utf-8?B?dzBuOWY0ejVPbGEwTjB2eWlLMzgyWjNCTWJDRFBDQ2lhd2J1dnhHMzh0S1ZW?=
 =?utf-8?B?U2hRY0xDVEQrT25uRFlyMkh3cnNFdURzSXhwRTh5QnZGbVBDc3cvK0c1dGlJ?=
 =?utf-8?B?Z2htVGtHTXROWHVSbGRpM3NBT0d2VHV6SGdEUGdnUC94ampnMXdIQ0dkRk82?=
 =?utf-8?B?bVdCUG5aVGUwK3F5d2VORW01QmVBNWt6REQ5RlhWSUswbGhRM0kxU0JmWmd1?=
 =?utf-8?B?blBJQWVFdnNYcVM4Y3lMZkhJbWh6bTVaUnJyamJTMWQwUFYybDRHMXJCK1ZN?=
 =?utf-8?B?WVJtMVJsckJSU3BkWXlKUFNuWTlsVytsNENsdzZnM1ZlN3NNU3RpTFRqS2tY?=
 =?utf-8?B?RU8xNWlCaFpvcE9VczVxNStvcXhiQis3WUNyK3hlNjE5cThQY210WUp5K2hX?=
 =?utf-8?B?S0hzTnNESEt0c1U0YmJydUF3b3NMRkVzL2h2N28rdDN0WHV3S25vaTd0Q3VZ?=
 =?utf-8?B?SEl4c3JIS1doa0VZa3VidGdiMWFyR1hzc0lBZDgyOWE3WjZFaG45Unl2a2pY?=
 =?utf-8?B?WDhPT0NRNjlNVzFrcWZONjVLR2xxTkZTUHRXTTJ2MXFZUisxUnZNaTA2NEFR?=
 =?utf-8?B?MXljQTNQdE5SZ0VodWZ5eVhCY0FoZTcrRG5HOHNjWmNmaGlMeTVoaWdRZmVC?=
 =?utf-8?B?U3VBTzY2b2VsS2RDYVVub1ZNN2hqbzFjSmNqeWVkQkFKTVNiaDJPc05IYTNM?=
 =?utf-8?B?bzhsMFU5S0VLR01TaklQbkxpcjdkUEpEVDVpNTE4QjZ3ZlNrQ0JwY0QrS2Z1?=
 =?utf-8?B?cnhRdmpEMXZRL3lGK2xDRCs3bHlkZGx6b0JpWG5yVGg4N045WU5WMnVFanNq?=
 =?utf-8?B?cndQc2lqTkpOK1pJZnJyKzB0aHgxOWlPc05WcXdGNHNRRXdveG95M0tVLzdW?=
 =?utf-8?B?RXNUREtGeEZTOWVMWDUrMTFHT0tWdyt0emI0VTJIRWE2dVhmaFRJOGl0ekho?=
 =?utf-8?B?dkxJbkNqc1BUR25mQm8xL1FoRnFISTczSS9DTHEydDQzb1ltRllUWTZCbGtt?=
 =?utf-8?B?RDllWS9Xb1NRWlEvSXRPVCtzS3N0eWVDSVV0TWRsWmkzU0R4VDJQb3hWWDJt?=
 =?utf-8?B?VDlldlMwMjh2LzVGU3FFeTg2elZlcWN0R2VTeXh4czUrenh2c2xUd0RsMHhs?=
 =?utf-8?B?T2pQL0RFUWhyYmlrMXRjdEZ3WDFjNjdKTjEzTnVDWE1JYWdtaTIrT2VpK1lm?=
 =?utf-8?B?SjV4bWRqNEtEWjFoVUUySVlTdGFXcnBxRytmUlpwUU1MTTBFSXU2NEd6a2lL?=
 =?utf-8?B?b1BxVGlyU2crbWQ1Y3FVcmdQelBQcGZFMEFzZTJ5RHBRbUdGOVE1RzQ3R3JE?=
 =?utf-8?B?RldBeHc3T3ZpQlJ1Z2RJMUxKQ0ZWN2w3dER6UURBcWhWZndXa0xkbGcvajJL?=
 =?utf-8?B?cmFCa2lmUHhMWjZiaGZwQ0krVHowNXY1NkNsNGY2aStUdFVzdGVMNy9nTjg0?=
 =?utf-8?B?ZkZON0JZZXBXL1VmVm9KcmNjcmZTQ2E4MEpEc2xwQXNPdjBVcElMK3hYakxS?=
 =?utf-8?B?YVU1ckh3YXVKNUhDZGhxVGFCeWpQbHhLWjRxMEkyMEFmYk1RMTIwbzRRcUJa?=
 =?utf-8?B?bE5tdTBCUzhpT2tKU0paS0RYQndUeDlIK2JPL3JKZXJDbTFlVHBXQktsYkQ0?=
 =?utf-8?B?MWJYclk2dlpxczQ0eUloYW53RVlTaHM4VXFzVm12K3RoTm5YeUZHRmlqbS8w?=
 =?utf-8?B?RzU4S1I5M3o2emthYkl0VkkrZlU3MVZseHZQWnFSa000Ykw5c2dnbUdiQlVt?=
 =?utf-8?B?OVhZOEdyekd0ODlOYUR6K0ZpOFNJdGhURFNrajF3V0o5OUN1bmNVVU1UOVEy?=
 =?utf-8?B?SjJ1TGFMclFXc0k2elJVdkpRK002cHBKY2ozYzFaYXBYSkppWVRYWEF4N09Q?=
 =?utf-8?Q?Gvtlox?=
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(35042699022)(36860700013)(82310400026)(376014)(1800799024)(14060799003)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jun 2025 12:11:29.9288
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7f9b5b63-f655-4393-e2a7-08ddad9817ab
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com]
X-MS-Exchange-CrossTenant-AuthSource:
	AMS0EPF00000196.eurprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR08MB10287

SGkgQXlhbiwNCg0KPiBPbiAxNyBKdW4gMjAyNSwgYXQgMTI6MTIsIEF5YW4gS3VtYXIgSGFsZGVy
IDxheWFuLmt1bWFyLmhhbGRlckBhbWQuY29tPiB3cm90ZToNCj4gDQo+IERlZmluZSBwcmVwYXJl
X3NlbGVjdG9yKCksIHJlYWRfcHJvdGVjdGlvbl9yZWdpb24oKSBhbmQNCj4gd3JpdGVfcHJvdGVj
dGlvbl9yZWdpb24oKSBmb3IgYXJtMzIuIEFsc28sIGRlZmluZQ0KPiBHRU5FUkFURV97UkVBRC9X
UklURX1fUFJfUkVHX09USEVSUyB0byBhY2Nlc3MgTVBVIHJlZ2lvbnMgZnJvbSAzMiB0byAyNTQu
DQo+IA0KPiBFbmFibGUgcHJfe2dldC9zZXR9X3tiYXNlL2xpbWl0fSgpLCByZWdpb25faXNfdmFs
aWQoKSBmb3IgYXJtMzIuDQo+IEVuYWJsZSBwcl9vZl9hZGRyKCkgZm9yIGFybTMyLg0KPiANCj4g
VGhlIG1heGltdW0gbnVtYmVyIG9mIHJlZ2lvbnMgc3VwcG9ydGVkIGlzIDI1NSAod2hpY2ggY29y
cmVzcG9uZHMgdG8gdGhlDQo+IG1heGltdW0gdmFsdWUgaW4gSE1QVUlSKS4NCj4gDQo+IFNpZ25l
ZC1vZmYtYnk6IEF5YW4gS3VtYXIgSGFsZGVyIDxheWFuLmt1bWFyLmhhbGRlckBhbWQuY29tPg0K
PiDigJQNClRoaXMgbG9va3MgZ29vZCB0byBtZSENCg0KUmV2aWV3ZWQtYnk6IEx1Y2EgRmFuY2Vs
bHUgPGx1Y2EuZmFuY2VsbHVAYXJtLmNvbT4NCg0KQ2hlZXJzLA0KTHVjYQ0KDQo=


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 12:33:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 12:33:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018209.1395125 (Exim 4.92)
	(envelope-from )
	id 1uRVV6-00045R-HE; Tue, 17 Jun 2025 12:33:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018209.1395125; Tue, 17 Jun 2025 12:33: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 1uRVV6-00045K-Dq; Tue, 17 Jun 2025 12:33:16 +0000
Received: by outflank-mailman (input) for mailman id 1018209;
 Tue, 17 Jun 2025 12:33: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 1uRVV4-00045E-SV
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 12:33: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 3b60381c-4b77-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 14:33:11 +0200 (CEST)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-450dd065828so45630745e9.2
 for ; Tue, 17 Jun 2025 05:33:11 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4532e243e59sm172795835e9.19.2025.06.17.05.33.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Jun 2025 05:33:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3b60381c-4b77-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750163591; x=1750768391; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=CFsnUMIKZWQrS60244cHKr2U2aZk5I35nwpyMeRtocU=;
        b=GzpAnMaWw7y6tG/G3rSVd6UxTUlG6jDWdO1Z01oejvgrr+vDx2IHBxW4zTXlRsDUib
         4DvSxLyBdRgiuhvVpztaekouCUC003c5YSJ1Qmwm4djyBSmHkYYQm/28q9ttarVoZ5fx
         6qAgmeBgHYDSsNTyze8lYmt8FkwSOHn9o2Y+o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750163591; x=1750768391;
        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=CFsnUMIKZWQrS60244cHKr2U2aZk5I35nwpyMeRtocU=;
        b=V4yLdsWPSR76wpgJCPOHIYr/FL5crAQ9RCw16WPMeujZ2kbkbnK0n3SSYy14kDmC++
         M3GcB2kS9N8nPWN0Vll2Qz56QqlVWqTJcif8zgDNam+YUhAZNXMMbIQ702/jV9y92mXj
         5DNVgbUCYlbRrKeKMSrAu//1wjKPNDCEi1oLfNHID/qGZ0sfMFlogxRWJGXgwCh3D5t7
         eqz4O4u7NOw6M3ydCqxub+hqignhCPZXLPQinbPGOcTtRr4KbOsau2zIuw9INqcSf/C+
         NS818CooRsEDEe6rBXjMZ92vgdZGIDdJGeaGilVM8anOKlI/CqxlJN3fG4hutsrhNlhC
         5ZtA==
X-Forwarded-Encrypted: i=1; AJvYcCWWjgqnWFRjQLtUKIJ1LFIStbxlQY3dhMev3xzTsnn1ivEc7tJHmn1q0i2q5Nq42IuoY8RTqrOaQQU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzOkoAYzUX0Z5I9+dw4SQmWp2mMlH9UbeWtEwyQOoxzOh4+cO+1
	sRRPBcTrf9uuHVuB84jntB0tEQRWbj5s9Tt3s9PQY+Hpb1an1HjZnW+mYrQXVupkq2M=
X-Gm-Gg: ASbGncvvM6wSorkqrtB1DLUtFHS0ZatgsibJDsVKaepnWCZ7Lk9LJxbBILHrYVAR+cR
	F3rwLmbwJy0YaFVFgTHnwgehFvotVBfUNyQQ0WmodMrDbnTCu8E9iGA4GfdS8oBrQFkwJYkGu14
	MKPrzhw2bSYoS+aa3Hys3xBMm/+gbnCQ4sQ2etu3SEWmNjI0X+/wm+IYI0Uzs0JXiw9/eQOeCo0
	h+fT3q+L04Ez9klEeHOliwavt29DOW7CerSC5u18MdWKVbOkIUjPP7ropGN2ivDT2NCSVk5VN3h
	fMXM2mdbPHnZ5+/aYIaT9SOM8n4GuDXkxvUdQzdf7F0HU+l1cp8yDgXeZD2p4RjAG/tFetMJz6O
	ObRXZCRxnfcO000rZ3DgMCIRF3m8=
X-Google-Smtp-Source: AGHT+IGj26pUOZaq5kw5OdEH2GfEdgf5nxMu/V8rLrjN7VCv6vt9PYVMuLaXPmpMk7Pu+8V6au18xg==
X-Received: by 2002:a05:600c:8685:b0:453:483b:6272 with SMTP id 5b1f17b1804b1-453483b6369mr58304935e9.7.1750163591230;
        Tue, 17 Jun 2025 05:33:11 -0700 (PDT)
Message-ID: <6e8ca83e-1d0a-4126-9219-c02b98011e47@citrix.com>
Date: Tue, 17 Jun 2025 13:33:09 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/dt: Remove loop in dt_read_number()
To: Alejandro Vallejo , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 "Daniel P . Smith" 
References: <20250617110741.34648-1-agarciav@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: <20250617110741.34648-1-agarciav@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17/06/2025 12:07 pm, Alejandro Vallejo wrote:
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> index 75017e4266..2daef8659e 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -261,10 +261,19 @@ void intc_dt_preinit(void);
>  /* Helper to read a big number; size is in cells (not bytes) */
>  static inline u64 dt_read_number(const __be32 *cell, int size)
>  {
> -    u64 r = 0;
> +    u64 r = be32_to_cpu(*cell);
> +
> +    switch ( size )
> +    {
> +    case 1:
> +        break;
> +    case 2:
> +        r = (r << 32) | be32_to_cpu(cell[1]);
> +    default:
> +        // Nonsensical size. default to 1.
> +        printk(XENLOG_WARNING "dt_read_number(%d) bad size", size);
> +    };
>  
> -    while ( size-- )
> -        r = (r << 32) | be32_to_cpu(*(cell++));
>      return r;
>  }

What testing has this had?

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 13:26:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 13:26:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018220.1395135 (Exim 4.92)
	(envelope-from )
	id 1uRWKY-0001p0-AI; Tue, 17 Jun 2025 13:26:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018220.1395135; Tue, 17 Jun 2025 13:26: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 1uRWKY-0001ot-7c; Tue, 17 Jun 2025 13:26:26 +0000
Received: by outflank-mailman (input) for mailman id 1018220;
 Tue, 17 Jun 2025 12:59: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 1uRVun-0006vG-V3
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 12:59:50 +0000
Received: from mail-vk1-xa32.google.com (mail-vk1-xa32.google.com
 [2607:f8b0:4864:20::a32])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f1ee0b54-4b7a-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 14:59:47 +0200 (CEST)
Received: by mail-vk1-xa32.google.com with SMTP id
 71dfb90a1353d-5314b486207so947097e0c.2
 for ; Tue, 17 Jun 2025 05:59:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f1ee0b54-4b7a-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750165186; x=1750769986; 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=IJGnTu2P8k2zWLpKT9gQ0C6Ynav6qAdbDTnXBuG6SzE=;
        b=cdGaYDQPmb2t4AfUZE3geWdL5Q/R9OI20zInszY62oC4KfE7yTv3n3b38ZSLHq9SCy
         HdmPLsovITj7qkqNAQvZKE5yaWfORhV4AqinQCGAFDL1NI0rWZOQMh+QkWdBqeIdlhB2
         5lyIToqV7HjB4MIrkxaeKrOYgjk4id22ljysU3pfYnsk6h3/wDRzcp4ZPNoGzfCcW5a6
         oI3hG/OsHzCe26PSMqo2rzOxUbkN5jm3qmhICeG2NrGjxYBPF+V/AEc3C8urqfscnJDR
         RduJeVG9ao5iV7pQBQSkDOY/WpyvustdiYccJ6haHbbIklPe2lIROc1s5NiJtppWuJkf
         8pMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750165186; x=1750769986;
        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=IJGnTu2P8k2zWLpKT9gQ0C6Ynav6qAdbDTnXBuG6SzE=;
        b=LZKwNalAwsi7lLBABwaNu0BmuT0LrqLn647rURC/jBK5ujBOsrsq0u9T/aKaI1vlpJ
         2YaHfpZjaKRAtWtw6mhYJIBokf9HB2rMBlC+lnBfE/QAIkgtW9LoX25mr0SJw77OcH0+
         pIQl8QvUAA2Y9dTYVFJPC3frrSeL6UALCYI4+BfnxU8gppoQAozRFGQyPZfOvkZbbktY
         /iO4qJVm2ZV3WsZgcYJtmeN/Lguar8CXkETfckvlMfbcb/hsVjcluiH3wvlqQCVzI3iQ
         GT8h9cWDqbZ5jjPhpiV4K4bAXRvyWMUFVGA+ihjzC1P5ZF/bntq+IAfm3rStV3nnxcW9
         2H9Q==
X-Forwarded-Encrypted: i=1; AJvYcCXYBkKNXS+XEh8c8FHOrXVigkaHsTvz0uaqf7xQ0zx6jXAb4Cs1g8Ppx2jsXvSQoLisGeO/8AB1VE8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwqRPsJKyYP/sP0Wyf4ZOa2WtMzpvwaL7zCpuIRp8UF0dfvsH8F
	LcNU/6l2PNbrKty5GnwZRR7EjkcqqIfyVtMkSXtAl9KVAangrwk6Ac12rdLXUARsDn/vFCYUc5P
	3XvZdfRDrbfXqGMMevy59lqQDb1qNjVU=
X-Gm-Gg: ASbGnctGKo+Tc6RBVX+TB4O83RW5XAKeURb3gkVnxbsd4KqyHpz1rlKiJhc+Yjay7dF
	0cTmHsQ2QwvWgERQYpXEfv6uJOPxRNz1kiaziYBFosO1hiGt02uoIi1j9xB7Y27CVlkw5yyHlDK
	pjhroSPTML93Isb2DKQzmXGjoU+I6UJtSsKperBduVkA==
X-Google-Smtp-Source: AGHT+IFyDxk9ofOoSE1jUdDwuXC6uj68bPw86gFHeN0xbFulbam2J1M/auQRgbuNa5uXdcywAXE8tSUc/+x2hYqgo2M=
X-Received: by 2002:a05:6122:4586:b0:52f:47de:3700 with SMTP id
 71dfb90a1353d-53149677e4amr8402312e0c.5.1750165185838; Tue, 17 Jun 2025
 05:59:45 -0700 (PDT)
MIME-Version: 1.0
References: <20250613090431.127087-1-tzimmermann@suse.de> <20250613090431.127087-8-tzimmermann@suse.de>
In-Reply-To: <20250613090431.127087-8-tzimmermann@suse.de>
From: Inki Dae 
Date: Tue, 17 Jun 2025 21:59:08 +0900
X-Gm-Features: Ac12FXy1YqAOwtksyoMPU_mcRXzK8GOxRWP5F_To6gWRQ1V5y95DviShSwJIG6g
Message-ID: 
Subject: Re: [PATCH v5 07/25] drm/exynos: Compute dumb-buffer sizes with drm_mode_size_dumb()
To: Thomas Zimmermann 
Cc: simona@ffwll.ch, airlied@gmail.com, mripard@kernel.org, 
	maarten.lankhorst@linux.intel.com, geert@linux-m68k.org, 
	tomi.valkeinen@ideasonboard.com, dri-devel@lists.freedesktop.org, 
	linux-mediatek@lists.infradead.org, freedreno@lists.freedesktop.org, 
	linux-arm-msm@vger.kernel.org, imx@lists.linux.dev, 
	linux-samsung-soc@vger.kernel.org, nouveau@lists.freedesktop.org, 
	virtualization@lists.linux.dev, spice-devel@lists.freedesktop.org, 
	linux-renesas-soc@vger.kernel.org, linux-rockchip@lists.infradead.org, 
	linux-tegra@vger.kernel.org, intel-xe@lists.freedesktop.org, 
	xen-devel@lists.xenproject.org, Seung-Woo Kim , 
	Kyungmin Park , Krzysztof Kozlowski , 
	Alim Akhtar 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

2025=EB=85=84 6=EC=9B=94 13=EC=9D=BC (=EA=B8=88) =EC=98=A4=ED=9B=84 6:05, T=
homas Zimmermann =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1=
:
>
> Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
> buffer size. No alignment required.
>

Acked-by : Inki Dae 

Thanks,
Inki Dae

> Signed-off-by: Thomas Zimmermann 
> Cc: Inki Dae 
> Cc: Seung-Woo Kim 
> Cc: Kyungmin Park 
> Cc: Krzysztof Kozlowski 
> Cc: Alim Akhtar 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_gem.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c b/drivers/gpu/drm/ex=
ynos/exynos_drm_gem.c
> index 4787fee4696f..ffa1c02b4b1e 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -11,6 +11,7 @@
>  #include 
>  #include 
>
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -330,15 +331,16 @@ int exynos_drm_gem_dumb_create(struct drm_file *fil=
e_priv,
>         unsigned int flags;
>         int ret;
>
> +       ret =3D drm_mode_size_dumb(dev, args, 0, 0);
> +       if (ret)
> +               return ret;
> +
>         /*
>          * allocate memory to be used for framebuffer.
>          * - this callback would be called by user application
>          *      with DRM_IOCTL_MODE_CREATE_DUMB command.
>          */
>
> -       args->pitch =3D args->width * ((args->bpp + 7) / 8);
> -       args->size =3D args->pitch * args->height;
> -
>         if (is_drm_iommu_supported(dev))
>                 flags =3D EXYNOS_BO_NONCONTIG | EXYNOS_BO_WC;
>         else
> --
> 2.49.0
>
>


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 13:27:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 13:27:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018240.1395144 (Exim 4.92)
	(envelope-from )
	id 1uRWLs-0002N0-Nx; Tue, 17 Jun 2025 13:27:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018240.1395144; Tue, 17 Jun 2025 13:27: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 1uRWLs-0002Mt-LA; Tue, 17 Jun 2025 13:27:48 +0000
Received: by outflank-mailman (input) for mailman id 1018240;
 Tue, 17 Jun 2025 13:27: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 1uRWLr-000277-BD
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 13:27:47 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20605.outbound.protection.outlook.com
 [2a01:111:f403:2415::605])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d99fb7af-4b7e-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 15:27:44 +0200 (CEST)
Received: from CH2PR04CA0017.namprd04.prod.outlook.com (2603:10b6:610:52::27)
 by PH0PR12MB7905.namprd12.prod.outlook.com (2603:10b6:510:28b::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.19; Tue, 17 Jun
 2025 13:27:41 +0000
Received: from DS2PEPF00003444.namprd04.prod.outlook.com
 (2603:10b6:610:52:cafe::da) by CH2PR04CA0017.outlook.office365.com
 (2603:10b6:610:52::27) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.21 via Frontend Transport; Tue,
 17 Jun 2025 13:27:41 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 DS2PEPF00003444.mail.protection.outlook.com (10.167.17.71) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Tue, 17 Jun 2025 13:27:40 +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, 17 Jun
 2025 08:27:40 -0500
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, 17 Jun
 2025 08:27:39 -0500
Received: from [172.26.5.4] (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 Jun 2025 08:27:38 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d99fb7af-4b7e-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=sPlp7GmVwjiEXhS12rtPLAJJ8sUWgFmb7pbh8furcj/GeqXdH3UTFdJtRtP0+cH0qA2yVuV/UcT0WWbEE/IOwFj2Idj13qx3m4gNwtoKVqv8eOxvJb4dg/MMFt9J3wxIfFbm5EY2YCC3oMahnef8b/EVRXxF/eHEOhGNif93M6FsgjPyWNw/EKAsHrMwKb01A/OaApEZXakIYgKkZkMks6m+CTT1QyW5VCoMA0URs6I8RpyAQzG4987eN42TkhiuxhHAm8GpP/6yfmh7t/V18FH37nl+eIwj4ZctZYNR9ZEHgNtlBVlz9qxpzOzmbwEeyiRqs2rh++oRDW3QDIEr8g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=YBXBAFzwqtxsbqBHL4ZUIRDK5QRO12IVuEoQld/AAoE=;
 b=EqbjAdfkgo9hY8cLUE2eQghePAgoSMTMQiyG3zg36wYqfIxM9xAyKxSi4c5Dff13wuABGgjTAa38ZtXEn1xabEvO8zKIUvqvZnLJCldX0dbSb6ABNl0qWtB/97jSfrFoV+gy3vf5H9FGdptgdIQKLnhu5uXavx4b7CrABZv3Gsx7ahvl+nGcCOQgaHSkweDLoPpfL+uhPdJhOUTlm7Z4D8hOIRioG/wPPF6RUWlY0gS2qB07p4Fp+w3D9c5MxcrQbYHlHJoQHdqrZWlb0hn2+hww9VtcxkNHJcx0JcI4zYr9qvOm57IzigMzq+m+SoRr2YmlTc+cVcH54XNvIsyhtA==
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=YBXBAFzwqtxsbqBHL4ZUIRDK5QRO12IVuEoQld/AAoE=;
 b=3W9PRHwvepGX08poQpSRMJwj8fuP6PKJNSSoEnQ7GPSI2dMWV0fdyG2GZGgLXAVCbE1qB5y4lBVrx+pZVygLQs2rWXLlffWen/KF67ui13GA2/Ueli2OwtXQ7n3A+CrhspoutGRDYfJ5mQwOGKmqWKMI2hTyhTKIdozdHzQroKA=
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: <71689454-3014-473e-bbdb-6c11033c9338@amd.com>
Date: Tue, 17 Jun 2025 09:27:38 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 1/2] xen/arm: exclude xen,reg from direct-map domU
 extended regions
To: "Orzel, Michal" , 
CC: Stefano Stabellini , Julien Grall
	, Bertrand Marquis , "Volodymyr
 Babchuk" 
References: <20250611175106.269829-1-stewart.hildebrand@amd.com>
 <20250611175106.269829-2-stewart.hildebrand@amd.com>
 
Content-Language: en-US
From: Stewart Hildebrand 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS2PEPF00003444:EE_|PH0PR12MB7905:EE_
X-MS-Office365-Filtering-Correlation-Id: cabebd2d-03dc-43b2-0be9-08ddada2bc0d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|376014|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?Qk1WRDRYZFZRWklaNnBMbUl4RC9zWjNDc3FCRlhkUGFJcHRhM1Y1RmV5OVo4?=
 =?utf-8?B?ek5xdGFLeVBXU0FmSzljWTlaY2pKTUpIQmQ3Q01idzZGdE5Yd253a2luNmRY?=
 =?utf-8?B?TW9RVWVjVE92VE15QktEZ2IzWWVwWUJpRHN1NDJSaGJ4QkRUQjdtOGYxR1Rj?=
 =?utf-8?B?SWljeW81NGJtbzB6bWNHTkxRcWYwdmJWTHc5aTBuSkt2RFhNdlBXRUc1M1BR?=
 =?utf-8?B?Y0FhVlV4eWgrNEJOV0x5ZlJXK1pqRnB1Witrd1FKS0RsQXdRUnA0NlJOcDVk?=
 =?utf-8?B?Ym9MYWJmdTZ3Q255aWMxV3RxZFZOY2RFb0kvNUlEZTJwQlNlMUNWSEhoaGp0?=
 =?utf-8?B?SUh6L1diSnFxaHFWakw4TjZiMTErYjd2WjZ5LzhERVJjNUdHWFhxNVBXWVJY?=
 =?utf-8?B?VThHNVo5b3hGVFR1V0NJeUZoRTFUZmczRWhDTEpiWmhBa2FtcGFENmxtb3VS?=
 =?utf-8?B?bUxoUHEzdEpId1pGelZUVjdWL1hycmYyOFdVbEtYSTh3UlppSTVDVFVKY29l?=
 =?utf-8?B?dFdFMkliY1pnd1M5Um0rdHhRYzRUSlc4UzU5ekVLQ09LQkZUZEp4QTJ3MXhl?=
 =?utf-8?B?dGE4YlV3SUswd01qRCt3WnZmeW04ZjRwNlg0YVdOWjRFUXFGdnJvWklDVXhC?=
 =?utf-8?B?Z2t2Njd2blhneS93a2F0K2Y5YWFtMXl4V3pia3ZZL1dHRUlscmNUekIxaHlJ?=
 =?utf-8?B?WUpmVTJ1YnVITVV4M0dYa05Bc3p4V2dZeVQ0M0picXJIK0lFaWhCQ3h1eWxS?=
 =?utf-8?B?Nmt0QnZBUVk1S3E1NEVPMS9OYmcrSGRTbWpodm0vY21FRFoyUmJCU0E0ejEr?=
 =?utf-8?B?STBCMzFpNmtmUUNNMFBzczF2YTNoazFldFgyZkNRUzh3aFUvdkZrYTl0NEww?=
 =?utf-8?B?RnhiOU1LdWhlSUtUM2E4R2ZhN2NRYW1CaTlGMFIxWit2VnlrKzYrc3VwaVNH?=
 =?utf-8?B?dzhMcjJQcElENGRNdnJmZHJ4TlBrSnpIWllwNzNjeTFVTi9PWU1sVUk4QWto?=
 =?utf-8?B?ZnNjbWJOam9jMjR2WFRtM3I2WmZuTlNBZDVEeXBVV1JtNEtVZEMwS0gydDNz?=
 =?utf-8?B?M3BwMWxpNnBHbTVZSWZldXhpRG44VnBqZDN4dHRuQ1pQYVV1TFMzVmpPWG1V?=
 =?utf-8?B?VWxidWhkZXlCTHBQNmh4SFBDU2g1RTQxRmtJT3p2eXVWVE1lWjM2dUhkclhm?=
 =?utf-8?B?THhFUGtvM2xUTzVlaCtJNW01WmZzYXVMTEZlVWRYUjd3MEt5ckw3Uk14RWcr?=
 =?utf-8?B?eDV2dmZpRjRHQlplRkdaeFBLWlFVUnNVcU1tOUN6dUNaVDNIYk1lTVI5TVFk?=
 =?utf-8?B?cGNMak9kWlFlM0hWN3gvZ0VvOTVIek44OTU1RlY4WkhnRU9zSEhya3VtdzNm?=
 =?utf-8?B?VU5mSml5NS9pSmFLN0I3V3dHam5ENW4wT0F0QVhWMDI2Z3QyejI5ZC80MHlX?=
 =?utf-8?B?akpZeWFvbHdWR0RxK0ZHTDl6ekdlQ3pOdHpXNE44Skhkci9FNzdZZlJreXZT?=
 =?utf-8?B?NEh0Ym8veW5PN1ZUcUZZOTQ1R3pXM1NuSTd6bURrVk05dDI1OTdQSksxbG5F?=
 =?utf-8?B?MWl4bmhvTkE3Rm5zNzRwakl3SUU4TXJMaml4b1pDUVR0OHRYY2tzZjFZYXp5?=
 =?utf-8?B?Z2k1VkhRMXIzendScTVXdFpCbkJLQ1hXRHovVlJWQW96Yy9KNmNOL3ZRcmhs?=
 =?utf-8?B?UHBYd1hxdGJ3L05jUmNYZzB3MzIzaVNzMUkxM0VFYzcxak5mS04vSHhJNFBw?=
 =?utf-8?B?UkZ1REJqcmoveHlaNWJKYys1MWo0Q1E3Ukg1QUhQWWlHQWd4cWtsNWVaL2ZC?=
 =?utf-8?B?SHZpKzRXZ2xDVk1ud1d5b0dKWjBIS2xGQmdtSTBmR0QvVUZmbWxSV2ZYSVV5?=
 =?utf-8?B?bXNaYk1Wd3hPWFZzeFFCZEQrcGlPeE4ra2RKcFFkVXpUZGVZRTBtajdFbXZa?=
 =?utf-8?B?T0F3THFsS0VReFFWVGRicGs0M0h2WnpmSjRSbjMzTmUwSE5CSFhJeGIvSDZE?=
 =?utf-8?B?NktyOUx2ekNRTUo2ajZtV2VqeWpJblRkSCt5clcxSVZRMVM5ZG1FZ0JEUnBx?=
 =?utf-8?Q?mfsQpF?=
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);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jun 2025 13:27:40.6929
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: cabebd2d-03dc-43b2-0be9-08ddada2bc0d
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:
	DS2PEPF00003444.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB7905

On 6/12/25 05:06, Orzel, Michal wrote:
> On 11/06/2025 19:51, Stewart Hildebrand wrote:
>> Similarly to fba1b0974dd8, when a device is passed through to a
>> direct-map dom0less domU, the xen,reg ranges may overlap with the
>> extended regions. Remove xen,reg from direct-map domU extended regions.
>>
>> Take the opportunity to update the comment ahead of find_memory_holes().
>>
>> Signed-off-by: Stewart Hildebrand 
>> ---
>> v4->v5:
>> * remove extranous -1 and +1
>> * create local helper function to count ranges
>>
>> v3->v4:
>> * conditionally allocate xen_reg
>> * use rangeset_report_ranges()
>> * make find_unallocated_memory() cope with NULL entry
>>
>> v2->v3:
>> * new patch
>> ---
>>  xen/arch/arm/domain_build.c           | 80 +++++++++++++++++++++++++--
>>  xen/common/device-tree/domain-build.c |  5 ++
>>  2 files changed, 80 insertions(+), 5 deletions(-)
>>
>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> index 590f38e52053..cef6c85e22ec 100644
>> --- a/xen/arch/arm/domain_build.c
>> +++ b/xen/arch/arm/domain_build.c
>> @@ -792,15 +792,17 @@ static int __init handle_pci_range(const struct dt_device_node *dev,
>>  }
>>  
>>  /*
>> - * Find the holes in the Host DT which can be exposed to Dom0 as extended
>> - * regions for the special memory mappings. In order to calculate regions
>> - * we exclude every addressable memory region described by "reg" and "ranges"
>> - * properties from the maximum possible addressable physical memory range:
>> + * Find the holes in the Host DT which can be exposed to Dom0 or a direct-map
> If you took occasion to improve this comment, then I would replace Dom0 with hwdom.

Will do.

>> + * domU as extended regions for the special memory mappings. In order to
>> + * calculate regions we exclude every addressable memory region described by
>> + * "reg" and "ranges" properties from the maximum possible addressable physical
>> + * memory range:
>>   * - MMIO
>>   * - Host RAM
>>   * - PCI aperture
>>   * - Static shared memory regions, which are described by special property
>>   *   "xen,shared-mem"
>> + * - xen,reg mappings
>>   */
>>  static int __init find_memory_holes(const struct kernel_info *kinfo,
>>                                      struct membanks *ext_regions)
>> @@ -882,6 +884,13 @@ static int __init find_memory_holes(const struct kernel_info *kinfo,
>>          }
>>      }
>>  
>> +    if ( kinfo->xen_reg_assigned )
>> +    {
>> +        res = rangeset_subtract(mem_holes, kinfo->xen_reg_assigned);
>> +        if ( res )
>> +            goto out;
>> +    }
>> +
>>      start = 0;
>>      end = (1ULL << p2m_ipa_bits) - 1;
>>      res = rangeset_report_ranges(mem_holes, PFN_DOWN(start), PFN_DOWN(end),
>> @@ -962,11 +971,51 @@ static int __init find_domU_holes(const struct kernel_info *kinfo,
>>      return res;
>>  }
>>  
>> +static int __init count(unsigned long s, unsigned long e, void *data)
>> +{
>> +    unsigned int *cnt = data;
>> +
>> +    (*cnt)++;
>> +
>> +    return 0;
>> +}
>> +
>> +static unsigned int __init count_ranges(struct rangeset *r)
>> +{
>> +    unsigned int cnt = 0;
>> +
>> +    rangeset_report_ranges(r, 0, PFN_DOWN((1ULL << p2m_ipa_bits) - 1), count,
> I don't think it's ok with MISRA C to not check the return code, even though in
> this case it's always 0. Either we should check or have (void).

I'll add (void).

>> +                           &cnt);
>> +
>> +    return cnt;
>> +}
>> +
>> +static int __init rangeset_to_membank(unsigned long s_gfn, unsigned long e_gfn,
> Here you use s_gfn, e_gfn but for count() you used s,e. Even if unused, I would
> prefer consistency.

I'll make it consistent.

>> +                                      void *data)
>> +{
>> +    struct membanks *membank = data;
>> +    paddr_t s = pfn_to_paddr(s_gfn);
>> +    paddr_t e = pfn_to_paddr(e_gfn + 1);
>> +
>> +    if ( membank->nr_banks >= membank->max_banks )
>> +        return 0;
>> +
>> +    membank->bank[membank->nr_banks].start = s;
>> +    membank->bank[membank->nr_banks].size = e - s;
>> +    membank->nr_banks++;
>> +
>> +    return 0;
>> +}
>> +
>>  static int __init find_host_extended_regions(const struct kernel_info *kinfo,
>>                                               struct membanks *ext_regions)
>>  {
>>      int res;
>>      struct membanks *gnttab = membanks_xzalloc(1, MEMORY);
>> +    struct membanks *xen_reg =
>> +        kinfo->xen_reg_assigned
>> +        ? membanks_xzalloc(count_ranges(kinfo->xen_reg_assigned), MEMORY)
>> +        : NULL;
>>  
>>      /*
>>       * Exclude the following regions:
>> @@ -974,6 +1023,7 @@ static int __init find_host_extended_regions(const struct kernel_info *kinfo,
>>       * 2) Remove reserved memory
>>       * 3) Grant table assigned to domain
>>       * 4) Remove static shared memory (when the feature is enabled)
>> +     * 5) Remove xen,reg
>>       */
>>      const struct membanks *mem_banks[] = {
>>          kernel_info_get_mem_const(kinfo),
>> @@ -982,12 +1032,29 @@ static int __init find_host_extended_regions(const struct kernel_info *kinfo,
>>  #ifdef CONFIG_STATIC_SHM
>>          bootinfo_get_shmem(),
>>  #endif
>> +        xen_reg,
>>      };
>>  
>>      dt_dprintk("Find unallocated memory for extended regions\n");
>>  
>>      if ( !gnttab )
>> -        return -ENOMEM;
>> +    {
>> +        res = -ENOMEM;
>> +        goto out;
>> +    }
>> +
>> +    if ( kinfo->xen_reg_assigned )
>> +    {
>> +        if ( !xen_reg )
>> +        {
>> +            res = -ENOMEM;
>> +            goto out;
>> +        }
>> +
>> +        rangeset_report_ranges(kinfo->xen_reg_assigned, 0,
>> +                               PFN_DOWN((1ULL << p2m_ipa_bits) - 1),
>> +                               rangeset_to_membank, xen_reg);
>> +    }
>>  
>>      gnttab->nr_banks = 1;
>>      gnttab->bank[0].start = kinfo->gnttab_start;
>> @@ -995,6 +1062,9 @@ static int __init find_host_extended_regions(const struct kernel_info *kinfo,
>>  
>>      res = find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_banks),
>>                                    ext_regions, add_ext_regions);
>> +
>> + out:
>> +    xfree(xen_reg);
>>      xfree(gnttab);
>>  
>>      return res;
>> diff --git a/xen/common/device-tree/domain-build.c b/xen/common/device-tree/domain-build.c
>> index 6b8b8d7cacb6..99ea81198a76 100644
>> --- a/xen/common/device-tree/domain-build.c
>> +++ b/xen/common/device-tree/domain-build.c
>> @@ -193,6 +193,10 @@ int __init find_unallocated_memory(const struct kernel_info *kinfo,
>>  
>>      /* Remove all regions listed in mem_banks */
>>      for ( i = 0; i < nr_mem_banks; i++ )
>> +    {
>> +        if ( !mem_banks[i] )
>> +            continue;
>> +
>>          for ( j = 0; j < mem_banks[i]->nr_banks; j++ )
>>          {
>>              start = mem_banks[i]->bank[j].start;
>> @@ -212,6 +216,7 @@ int __init find_unallocated_memory(const struct kernel_info *kinfo,
>>                  goto out;
>>              }
>>          }
>> +    }
>>  
>>      start = 0;
>>      end = (1ULL << p2m_ipa_bits) - 1;
> 
> Other than that, LGTM:
> Reviewed-by: Michal Orzel 

Thanks!


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 14:21:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 14:21:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018259.1395155 (Exim 4.92)
	(envelope-from )
	id 1uRXBQ-0001LQ-CP; Tue, 17 Jun 2025 14:21:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018259.1395155; Tue, 17 Jun 2025 14: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 1uRXBQ-0001LJ-8G; Tue, 17 Jun 2025 14:21:04 +0000
Received: by outflank-mailman (input) for mailman id 1018259;
 Tue, 17 Jun 2025 14:21: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 1uRXBP-0001LD-Dz
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 14:21:03 +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 4bcd73f4-4b86-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 16:21:01 +0200 (CEST)
Received: by mail-lf1-x12c.google.com with SMTP id
 2adb3069b0e04-54b09cb06b0so6503451e87.1
 for ; Tue, 17 Jun 2025 07:21:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4bcd73f4-4b86-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750170061; x=1750774861; 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=gb1p60QKBhAo5gm48IbBprTChd0rb8NUwjl2AKG+uAU=;
        b=ZFWzctj0Hg8bFbFFZdCNX84eKHkyowcRCfUraFMzECdFEjDrY2cXOpweobIeW1gzbV
         PvwlbrYYLn11SvUSowIwXVxorQpMeCcilkiCqtJWkNSbps1Ll+3VT/qDI/DF/VZ0mEMT
         8qMn66XB4QL6z4DpNkt+q8Nzb+tn+pPsRdUtPDKljnnXz+ywuJ1aZTt5Kzep4FljMe5h
         6Ff7hyM8b3M3tl9RQrsenX2JoDFApNv8U0F3eEC5ZQ3BFTRo8zCV6URksRSL1vtQi0uG
         aCXJgwMVHAvEtUonkiE7E1bPM9UMGd455UEIsZbLLndbzqTRwSOg4nLU5O2vMhjiixqq
         XlPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750170061; x=1750774861;
        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=gb1p60QKBhAo5gm48IbBprTChd0rb8NUwjl2AKG+uAU=;
        b=T7/Ts0Q4KZmI0BoYs1kpSVTTFlqeWWoc4yn6GY8ArKJVz0bu8PtNwbyW5bKsDeV1v5
         mr3pt7SzBQiXNdIKHGwB7Dg8T3KIYO7/t+Ut6zLpqZWEWlDAMsMc148Q5g5fg5wAGYjU
         VreR3Yjloy58Nmsk8o8UgAVAgX2LeUCEwBeZEIIU+ENA2qlkzOPbID452O1L3flvxnxw
         BbmV0d30G8hlThBJmW4H5F6U9TzkBS4xmdnuxt4z40gA+4O1A2CboZIm43ko5DPusoZv
         99yWK6KnfOTHSPeoIYkkdVc6I+AIQh9BPKayWWpqNbS1G8pJzl5aAcRucRegWpAvCj9U
         V4vg==
X-Gm-Message-State: AOJu0YxtgjeaJgxfz7SZXRzUCYgDP3IMv6WDRj0Art0av0+iJQlJbHCY
	9MLe5zAHTCKF+fZbmcVNmtCu8moLEPzhzxj5104rVDB2gsqzBI6bumpiFcVaaObPFpKDy5ec9rS
	DNtT+9cSmI1dUS/4C+nrKBsc+ndOXgng=
X-Gm-Gg: ASbGncvVFVVjmh/O1YKOVVXdDQaXVphGWTCSNh5cRqAfNQWH32BdGzbU8pR6ZazgZWz
	6UKAPyXVFTfYZTLJAc/EqQtYpuoAMucgqa8FKZ86BXpxN11n3u9icqZ+zyBUm2ZrLjPk0BwL3NK
	MVPfqUvNh3jeuHmVI5nlPfiCFAjmpCdoI60qfGH3fXww==
X-Google-Smtp-Source: AGHT+IGpDLlB2hDY8gGqmKWsHL6uzavqzlynacH+3UmZ6F5ABRmviyigN5EacpqL+Rtbi5602dvff4p0hsFbTijEx/0=
X-Received: by 2002:a05:6512:6ca:b0:54a:cc04:ea24 with SMTP id
 2adb3069b0e04-553b6f43b4cmr3467607e87.46.1750170060891; Tue, 17 Jun 2025
 07:21:00 -0700 (PDT)
MIME-Version: 1.0
References: <20250616153826.404927-1-edgar.iglesias@gmail.com> <20250616155306.405257-3-edgar.iglesias@gmail.com>
In-Reply-To: <20250616155306.405257-3-edgar.iglesias@gmail.com>
From: Nick Rosbrook 
Date: Tue, 17 Jun 2025 10:20:48 -0400
X-Gm-Features: AX0GCFu-1vtvMVC7dIRnYOZGf23BFMdfvzA3WdOumLzAWNbjfNXpK22jyUACsZI
Message-ID: 
Subject: Re: [PATCH v5 5/5] tools/golang: Regenerate bindings for trap_unmapped_accesses
To: "Edgar E. Iglesias" 
Cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org, julien@xen.org, 
	bertrand.marquis@arm.com, michal.orzel@amd.com, Volodymyr_Babchuk@epam.com, 
	andrew.cooper3@citrix.com, anthony.perard@vates.tech, gwd@xenproject.org, 
	edgar.iglesias@amd.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 16, 2025 at 11:53=E2=80=AFAM Edgar E. Iglesias
 wrote:
>
> From: "Edgar E. Iglesias" 
>
> Signed-off-by: Edgar E. Iglesias 

Acked-by: Nick Rosbrook 

Sorry for the delay.

-Nick


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 15:00:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 15:00:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018272.1395164 (Exim 4.92)
	(envelope-from )
	id 1uRXnJ-0006JD-3i; Tue, 17 Jun 2025 15:00:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018272.1395164; Tue, 17 Jun 2025 15:00: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 1uRXnJ-0006J6-1E; Tue, 17 Jun 2025 15:00:13 +0000
Received: by outflank-mailman (input) for mailman id 1018272;
 Tue, 17 Jun 2025 15:00: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 1uRXnI-0006J0-3X
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 15:00:12 +0000
Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com
 [2607:f8b0:4864:20::72b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c3a8e2f8-4b8b-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 17:00:11 +0200 (CEST)
Received: by mail-qk1-x72b.google.com with SMTP id
 af79cd13be357-7cadc92771dso628152985a.1
 for ; Tue, 17 Jun 2025 08:00:10 -0700 (PDT)
Received: from six.. ([69.53.121.20]) by smtp.gmail.com with ESMTPSA id
 af79cd13be357-7d3b8dc9e15sm665761485a.9.2025.06.17.08.00.08
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 17 Jun 2025 08:00:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c3a8e2f8-4b8b-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750172409; x=1750777209; 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=JZArjs3/+CYFN5nJYtjt1e9TA00uz0flf6Zhhx8TEXc=;
        b=CIGuKpBIFIrGeDFmnSU+hk3twGI+6/p+AeC2+hSCmm3K2FD0VHTS+O2BuNe9tqBubQ
         4lXm6fwwbMgqfIa4vIv9OtM9EbhJQqrgBMabiE/4aRH8VMa/3Gz4wWsaOOORo+SPLOmN
         +WAtiJNCD2A/EBxXUIRGSBfPuxBGYP6rPVhY8z5m0xHA2KtoO2QmRgcsXV3wE8mLb8UY
         qiXjV9tIrhpT3kjxRxA4AYWljvXsmNO0z1cujj0N+WvQOuraMWOH3tjSpB4wdk8ES9+T
         2OFqkBjVbitFyAJWySuWC+6srL0DV8wtu/JbJdzsGDo+1O3a70keDnL3O+qH3xVNUpGc
         KWhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750172409; x=1750777209;
        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=JZArjs3/+CYFN5nJYtjt1e9TA00uz0flf6Zhhx8TEXc=;
        b=p3GluUaIEmi9qDAcbNWcH+AOMVgKEGc4ICyPPwBoeLMOQdzVLenEh096QS3bPFamSJ
         L/j1nLMcSRW56um8PtqL+HBVW07WBSy4r3JTgoJHwdRQc17LVleKV57HCqOUatT//YpR
         klxhq5h4Yb8wGUboj/t/fd/zcUeQJXPvg3FAgIUpAVI5CB5GIdViVHrb6w1ekQ37i4xO
         4+1fkWIWr7f1FhQy0YlOI0LpTcrMBkkM0w6qVm15Ke5Joxy5NPVu5sBsHHcO7ejvng9Q
         pqe/X+vJ0F/QZrti4KllhqyXsusuEbO022yt4XTCe7bOBm6SXj0FkM+0l2qKXPTN/iTo
         EI/w==
X-Gm-Message-State: AOJu0YzqDUdyYzoZHcLaxAViv160sOLauaPkdGUlfFl3dDf+o07Nvvy0
	T2TgQEPOdw7AT7taMqlYXhd6Qpee2WuDnHA+wqZcRzYKAGkSdvLP0Ozw2TEZnxRN
X-Gm-Gg: ASbGncsKlCkAHJCuJaBsFYR4VOswWLbMzepL0IIk07zyaVd+LxUSo8LG5JbmksrQOGb
	Jrv5Onef/EBWgpRKTUScapHb2QXusDNt/G+2qp2dXw9GE/cHLLjX7Ssw9aMuX9qaAan8tlaYqqQ
	5eRih3wxtqkCnxlPsZedyXBGbzwJWCwZI0jun3iwFrxvpMU8OgdjHzVEvR6xk5WijR+p11wG0TN
	/e5h7P4r6jU5CWnhiwKxF2+RY5BFn3FlNUEeRHCr0qPNbmPzfF96wukAyM8y5sACquBgnVJ0Wwy
	r1P0WmT7IOCg/vK5g8qXxOsxROyUfbEbACaoCMiORS6uaGT81II=
X-Google-Smtp-Source: AGHT+IEJfRnIEDPWFQs1ZZ2EtpF0pkHEYAk8w5jqrQ2FmlqKdmACsKxO/myeIuGn4aLn6f/ZiOj1NA==
X-Received: by 2002:a05:620a:a10a:b0:7d3:a6c7:4eb2 with SMTP id af79cd13be357-7d3c6cd4e97mr1672780785a.31.1750172409022;
        Tue, 17 Jun 2025 08:00:09 -0700 (PDT)
From: Nick Rosbrook 
To: xen-devel@lists.xenproject.org
Cc: Nick Rosbrook ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH] MAINTAINERS: update my email address
Date: Tue, 17 Jun 2025 11:00:02 -0400
Message-ID: <55a35aed605bafd38b6ccfd0bb6e401a5fdf9794.1750172048.git.rosbrookn@gmail.com>
X-Mailer: git-send-email 2.48.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Change rosbrookn@gmail.com -> enr0n@ubuntu.com

Signed-off-by: Nick Rosbrook 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 13f31b0c1b..9aa7dd2f57 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -330,7 +330,7 @@ F:	xen/arch/x86/debug.c
 F:	tools/debugger/gdbsx/
 
 GOLANG BINDINGS
-M:	Nick Rosbrook 
+M:	Nick Rosbrook 
 R:	George Dunlap 
 S:	Maintained
 F:	tools/golang
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Tue Jun 17 15:32:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 15:32:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018279.1395175 (Exim 4.92)
	(envelope-from )
	id 1uRYI8-0001pH-8G; Tue, 17 Jun 2025 15:32:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018279.1395175; Tue, 17 Jun 2025 15:32: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 1uRYI8-0001pA-5H; Tue, 17 Jun 2025 15:32:04 +0000
Received: by outflank-mailman (input) for mailman id 1018279;
 Tue, 17 Jun 2025 15: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 1uRYI6-0001p4-P0
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 15:32:02 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id 33edfab6-4b90-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 17:31:57 +0200 (CEST)
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 5D095150C;
 Tue, 17 Jun 2025 08:31:35 -0700 (PDT)
Received: from PWQ0QT7DJ1 (unknown [10.57.67.3])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 04BDF3F673;
 Tue, 17 Jun 2025 08:31:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 33edfab6-4b90-11f0-b894-0df219b8e170
Date: Tue, 17 Jun 2025 16:31:53 +0100
From: Hari Limaye 
To: Ayan Kumar Halder 
Cc: xen-devel@lists.xenproject.org, 
	Stefano Stabellini , Julien Grall , 
	Bertrand Marquis , Michal Orzel , 
	Volodymyr Babchuk , Luca Fancellu 
Subject: Re: [PATCH v4 3/3] arm/mpu: Enable read/write to protection regions
 for arm32
Message-ID: 
References: <20250617111251.1711553-1-ayan.kumar.halder@amd.com>
 <20250617111251.1711553-4-ayan.kumar.halder@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250617111251.1711553-4-ayan.kumar.halder@amd.com>

Hi Ayan,

> +/*
> + * Armv8-R supports direct access and indirect access to the MPU regions through
> + * registers:
> + *  - indirect access involves changing the MPU region selector, issuing an isb
> + *    barrier and accessing the selected region through specific registers
> + *  - direct access involves accessing specific registers that point to
> + *    specific MPU regions, without changing the selector, avoiding the use of
> + *    a barrier.
> + * For Arm32 the HPR{B,L}AR (for n=0..31) are used for direct access to the
> + * first 32 MPU regions.
> + * For MPU region numbered 32..254, one need to set the region number in HPRSELR,
> + * followed by configuring HPR{B,L}AR.
> + */
> +static void prepare_selector(uint8_t *sel)

NIT: s/one need/one needs/
NIT: s/MPU region numbered/MPU regions numbered/

Also - it's not clear to me what is meant by "followed by configuring HPR{B,L}AR";
if I understand correctly, once we have set the region number in HPRSELR
and issued an isb we can simply read/write HPR{B,L}AR as indicated in
the bullet point above?

> On Tue, Jun 17, 2025 at 12:12:51PM +0000, Ayan Kumar Halder wrote:
> Define prepare_selector(), read_protection_region() and
> write_protection_region() for arm32. Also, define
> GENERATE_{READ/WRITE}_PR_REG_OTHERS to access MPU regions from 32 to 254.
> 
> Enable pr_{get/set}_{base/limit}(), region_is_valid() for arm32.
> Enable pr_of_addr() for arm32.
> 
> The maximum number of regions supported is 255 (which corresponds to the
> maximum value in HMPUIR).
> 
> Signed-off-by: Ayan Kumar Halder 
> Reviewed-by: Luca Fancellu 
> ---

Apart from the above, all LGTM! I've tested compilation for both 64-bit
and 32-bit and all is building successfully.

Reviewed-by: Hari Limaye 
Tested-by: Hari Limaye 

Cheers,
Hari


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 15:56:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 15:56:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018309.1395197 (Exim 4.92)
	(envelope-from )
	id 1uRYg2-0004oE-6E; Tue, 17 Jun 2025 15:56:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018309.1395197; Tue, 17 Jun 2025 15:56: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 1uRYg2-0004o7-2l; Tue, 17 Jun 2025 15:56:46 +0000
Received: by outflank-mailman (input) for mailman id 1018309;
 Tue, 17 Jun 2025 15:56: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 1uRYg0-0004mx-7J
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 15:56:44 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on2060d.outbound.protection.outlook.com
 [2a01:111:f403:2009::60d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a8a0b3c4-4b93-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 17:56:42 +0200 (CEST)
Received: from DS7PR05CA0096.namprd05.prod.outlook.com (2603:10b6:8:56::28) by
 MN2PR12MB4064.namprd12.prod.outlook.com (2603:10b6:208:1d3::17) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Tue, 17 Jun
 2025 15:56:38 +0000
Received: from CH3PEPF00000011.namprd21.prod.outlook.com
 (2603:10b6:8:56:cafe::7) by DS7PR05CA0096.outlook.office365.com
 (2603:10b6:8:56::28) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.23 via Frontend Transport; Tue,
 17 Jun 2025 15:56:38 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH3PEPF00000011.mail.protection.outlook.com (10.167.244.116) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8880.0 via Frontend Transport; Tue, 17 Jun 2025 15:56:37 +0000
Received: from localhost (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, 17 Jun
 2025 10:56:36 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a8a0b3c4-4b93-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=RX9GKksfxiyHmHkHg56KJiwXTvixRMfjrpfY/QRgDL1m5Q9RnTA8J4+8Isv0tyKhRd9wtMlSkMGUAlOKB7pIksUVivQ8ubJLsxK1WveHHAHmTVNWlU5em7gR9haFYk4fmrPJ815Fzor9VP8MK+nXwG9oEoAqxO7O5mDV+hCw0b2Mj0bFa0aDh+hP88hufFYr1VrAztwcURYnAXk92a0flif+1m4I6tdHQqbMOvG7x+JroaieTrSn/S3ThKEwVhorr7JYWP9G84JOziRscWr03q+idepCX88gOvrhlNlh2km1m8nHNgAYwdbkLXllgZ6P9wXV08uo2ZO5b1rBPODLvg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=3gdMmFUb8Iy758QKJQLE75KpucuoGbFVvBD/T257d/A=;
 b=Uh5E21LPIcKhpqSr+qKwa9qQGzRI0j01/Fa6isPT1YWKjnynoZzRV6X5HykAn8w6UDYXh9duHTppiGVC7Wb7wc3yzUK4ScVDCBLx0W2GOI1Ga7UWykJS4b85D0cNl7TyhPCURqmEwCgFtjMpcGT2c0B8TdaHoxTfn7rWFiiRvRlIc1Bki+3Qr90qCCUUEYHoFKeSiiYv8zxi8JFcgscMHs3CcSrtBpVsIu25tKKRQ7c9cMWYICwioKZ+vwyaI1o6unqGZlG4IJMSrXD1eJAosPK3zPOwpXdeva64v1dRLcAWr5tXEA3jEnbWksWOmDipQ34WpgBRtRTltG+gFn1cjA==
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=3gdMmFUb8Iy758QKJQLE75KpucuoGbFVvBD/T257d/A=;
 b=fxrW0eZDbGi/WV6fG1MAZT0S/U00sPSi7WAHUs0YbxCVw2SDun23mL46qMaWba09qjR7AyzBzkej+OsADkG3QSUxTMH0zB2BPjVlEjWBZ6nGPT5hIAbxWZtzlL1oGTm4Pu4PdUE5xper8KvoXa/csLvR6ZsjupSwazQt6JVyos8=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 17 Jun 2025 17:56:34 +0200
Message-ID: 
CC: Stefano Stabellini , Julien Grall
	, Bertrand Marquis , Michal Orzel
	, "Daniel P . Smith " 
Subject: Re: [PATCH] xen/dt: Remove loop in dt_read_number()
From: Alejandro Vallejo 
To: Alejandro Vallejo , 
X-Mailer: aerc 0.20.1
References: <20250617110741.34648-1-agarciav@amd.com>
In-Reply-To: <20250617110741.34648-1-agarciav@amd.com>
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: CH3PEPF00000011:EE_|MN2PR12MB4064:EE_
X-MS-Office365-Filtering-Correlation-Id: 9213c7a1-dae6-4bc1-7614-08ddadb78b00
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:
	=?utf-8?B?SnUxZno0dVpYL1FjZlZtQXdIanRib0ZKUkFMK2Nmd0FHeVQxaUI2VTBIcG1Q?=
 =?utf-8?B?dnpvUkJ2MHNGL3JrejNaTURKWmIxbmY4aHFOUjA3VjUzK3NDK0VZQ2hKcGYz?=
 =?utf-8?B?K0J3ZFU3UDB5c2o4eXV1S0RFdTBRVjcrWDE4RyswOThLMUpPSUh3bFRwdkNm?=
 =?utf-8?B?TnV0YmQwWXZhMDlQdTZXdVFra3BWUWs5ZjEwQm90SXYwMi9TZ0hDa1ZCL2dp?=
 =?utf-8?B?ZFpoRXhUQ3p0RGJXNGgwMUQvMEJkRkxVdnQ3bVhMSHhTd2JOTmlva09pd3Ni?=
 =?utf-8?B?emI3cFA1dzhNanVmeHE1YitzUVNvVHJDc1d0OGYxaTFsTFVkQjV2NXJ0K0Nj?=
 =?utf-8?B?VExKS04wa3h3T25rZjREKzRyL2VEdmt6TnlWR2dXWU15TnlmcS92L1RWdkF2?=
 =?utf-8?B?YmU4Y1RjZlJuSFlRYkZ2WmhlTGwrYlE0b1J6S05DQkp0bGdPMUZ3ZmdjK1RF?=
 =?utf-8?B?eFBMSFB0UElxaWFRVFk3ODJwWHZMWVY2YlYvczlqR0hlVndVOGNHWHA0aXFM?=
 =?utf-8?B?VUtRWjkrdDJ4d2VWNUU2RHY5dnhLSlhGTXI5dkFxci9jWGVmZFpyT3NheUtq?=
 =?utf-8?B?Qk05R3dsM2VFRFdiUkl1c0pRM1l4ZkpnOGRBN0dyYXdjOGRZMzlXbmwvSy9F?=
 =?utf-8?B?MTl1Sy9QODdLdnFjL0E2UUpnbHJRTjJST1FXb3lOU0pwYnNKMXdCbGZvcUcx?=
 =?utf-8?B?UmN2VXZoYm1ITVY2R01qYkN3bG80SEJKcXVoaUMzTUcxaGlIUGVpZzdQOTEz?=
 =?utf-8?B?TkVEV2VIYTQxQzdEK2FEdHYzdnIxZHBYZnNTaUQ3WWl5T0dvWkNjTytKaDJj?=
 =?utf-8?B?cTIxbVhVeUt6WHdnNDZseTU5ajVNNjVsc0xFQTBYUUM2Ui9xcVpiQ0l3THFH?=
 =?utf-8?B?U21vbWJnNkJnWGJ6VmxtdTlmV3JmdUlsa25nWXZxMkpFem91aUUzQlVOMUhl?=
 =?utf-8?B?YjlpZ3hvS2FCR29XL3NJQnZwc2tHTHZEUW9aNHVYOFJtaHpWZTFSTjhKVzVi?=
 =?utf-8?B?QlpreVRWUHVQN20xWTFUa29WSS9vQkxRRk16a2V2T2ttMzNobThwdmJHckgx?=
 =?utf-8?B?ZVlHSml5TkxkbU1kRWVHRWlWZ05EcXZJWGxoSk1TWkhMd3M3b1ZIOHhyK1ZC?=
 =?utf-8?B?K2UvVXBPS3VLdEZkNTI0T2cxK0d1TjBlcFE0ZjZKQkE1a25yazg4U2lDSTlp?=
 =?utf-8?B?MUNrRlhKbEZyakdYakhpQ0ZIUVNUZnZ5SCt4RUhFUlFCWjRxY3ZyTjJWeFNI?=
 =?utf-8?B?ellQbUtuNERoYnBDYzJWcXRBbnNVM3B2WG94c0RZdTI0Nkg4L3FHcVVISVph?=
 =?utf-8?B?NVIxeHJDSFRQSm9Ldk5FTU5QWXZBWmN4U1d6OTVNSUMvVXhiSWp1MjJ6NnYx?=
 =?utf-8?B?bWpGR2FmS2Q0UFMzQ0hBTGcza1JFendUOEJZTmwwSlJETGR6REZ3RWRtejdX?=
 =?utf-8?B?UHVGekc1ejN5Y0w1Tld3MEg3UkpnZkJlWFJJWFdYei9ZTHE4bE1TdmZNajRj?=
 =?utf-8?B?ejNCcUJiMlBBMzlrK0RKakJOWjRtQ3V1dHQ1TldZUmpJcmRQNHlCZWlualVn?=
 =?utf-8?B?RitFOVl4YnRvcDZwWjVKMVFGTWlLTG0yTHhiTTFNZmR4RmdRbXIzL1NZbFU5?=
 =?utf-8?B?RVc2Tnk0WHpFS25RckpoNXJWa1JCM2IxenY3TUlsc2pGSHdpOU9paXlINW5r?=
 =?utf-8?B?NjMvaHBiYVVqQ1YxOEc2TnU1Vk5pL0xlZDMwazZjZ1NCYkV5aE93dXZpOGE5?=
 =?utf-8?B?NGFNTnZqTVQvSC85TVdTdVFZNDZ6S2pkTDJlNExFWEtwQ1BqK1lTVUN6cmMy?=
 =?utf-8?B?dzBKSC9zdlFYbFdqQmFvOHRxRnk1Wk9IVmpUMEgxMEJHMXZFdW5iUGZ4MFZT?=
 =?utf-8?B?MTVsTjdkWEdDTGYyaWhiZmlpaGNtTi83MnJsWGNxYnowWWQrMmxyOFprR2tm?=
 =?utf-8?B?THlvTk9vSVc0MDNvanpzR0thV29EVnRESk5EcjJvT2haNERwNWo4V3N0OEpy?=
 =?utf-8?B?bEo4Y1hLWDV6L2t3UTBUSldKbEh6dW1jNG9nN1ZQU0lXVitOZEJwa1Q4c2ls?=
 =?utf-8?Q?r/jWdQ?=
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: 17 Jun 2025 15:56:37.8625
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9213c7a1-dae6-4bc1-7614-08ddadb78b00
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:
	CH3PEPF00000011.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4064

On Tue Jun 17, 2025 at 1:07 PM CEST, Alejandro Vallejo wrote:
> The DT spec declares only two number types for a property: u32 and u64,
> as per Table 2.3 in Section 2.2.4. Remove unbounded loop and replace
> with a switch statement. Default to a size of 1 cell in the nonsensical
> size case, with a warning printed on the Xen console.
>
> Suggested-by: Daniel P. Smith" 
> Signed-off-by: Alejandro Vallejo 
> ---
> Based on this suggestion by Daniel:
>
>     https://lore.kernel.org/xen-devel/a66c11c4-cfac-4934-b1f5-e07c728db8d=
e@apertussolutions.com/
>
> I'd be happier panicking there, seeing how DTs are by their very nature
> trusted blobs. But I suspect defaulting to something will find less
> resistance in review. I don't care much either way.
> ---
>  xen/include/xen/device_tree.h | 15 ++++++++++++---
>  1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.=
h
> index 75017e4266..2daef8659e 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -261,10 +261,19 @@ void intc_dt_preinit(void);
>  /* Helper to read a big number; size is in cells (not bytes) */
>  static inline u64 dt_read_number(const __be32 *cell, int size)
>  {
> -    u64 r =3D 0;
> +    u64 r =3D be32_to_cpu(*cell);
> +
> +    switch ( size )
> +    {
> +    case 1:
> +        break;
> +    case 2:
> +        r =3D (r << 32) | be32_to_cpu(cell[1]);

Bah, missing break. And with a printk rather than a panic CI stayed green w=
hen
it shouldn't have been.

> +    default:
> +        // Nonsensical size. default to 1.
> +        printk(XENLOG_WARNING "dt_read_number(%d) bad size", size);

I'll add an ASSERT_UNREACHABLE() here for good measure.

> +    };
> =20
> -    while ( size-- )
> -        r =3D (r << 32) | be32_to_cpu(*(cell++));
>      return r;
>  }
> =20
>
> base-commit: 14c57887f36937c1deb9eeca852c3a7595d2d0b8


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 16:00:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 16:00:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018315.1395206 (Exim 4.92)
	(envelope-from )
	id 1uRYjF-0006Pf-K5; Tue, 17 Jun 2025 16:00:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018315.1395206; Tue, 17 Jun 2025 16:00:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRYjF-0006P2-G7; Tue, 17 Jun 2025 16:00:05 +0000
Received: by outflank-mailman (input) for mailman id 1018315;
 Tue, 17 Jun 2025 16: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 1uRYjD-0005wN-FK
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 16:00:03 +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 1ff59d6e-4b94-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 18:00:01 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3a365a6804eso4390097f8f.3
 for ; Tue, 17 Jun 2025 09:00:01 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-7488ffed093sm9036662b3a.3.2025.06.17.08.59.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Jun 2025 09:00:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1ff59d6e-4b94-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750176001; x=1750780801; 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=Ki4IbC7ROqNGLBYTQOjKQFfjkG1lVUcOescUCgLCdP4=;
        b=YpoxWDKfpN5MVHO3UPIz7FqemKM4K2tEr6oq/KUM7Br9KCQf72Vd85VnPS90DvxTJI
         UvyjfBF2qe2pO6zSevXDQPNbSZ+muPWjzVFyiPtNHgFEI2RHrN/beAtx7KwBNZLYTpz5
         xvGW056WlbhOJZWdyPrz6QhR0BDFcyDNUCf2dBu09SnY9mvMXyajqrVQQxe5xD53mYOz
         ktNYQK7GmeTE6FxWjhgUw4lO98+Y69v4fOTpwr5mAH2Fe98E7ZUSg6WE30cEEAnOxWsj
         grt+bi4OTDgPBCPGWFBM8qiJHOdqKGTVYspCpQZOt/wptWCmKi3wx9Sz0xCgLfQnRP6Z
         s/AQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750176001; x=1750780801;
        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=Ki4IbC7ROqNGLBYTQOjKQFfjkG1lVUcOescUCgLCdP4=;
        b=rwzj6An/g89gNedbXJT56bB+X6HlQG/rbTaav+o/yj+OXxWh24QPnJqL7XZata40n7
         6NQkuuKS1/zik4eMhK/tNgJGwINzu5QHLXgjVY1UUH3XiDjr69ZYNC9mJ4QarJq30lPZ
         f2LePOMajl33RBXEcuCFEKKbQBXnmVdVu0E8e/9ON+ARdVAdsghhPTX61KkOr+WHY7BQ
         sLoSSS9mM8d77UchRDSjR8KVCcdMVr0mDwEzIsw/hRfDAr1Rjqp0Rizw5APcdnnoKQ/U
         m8P7DmRwm4C9aie5Yli2nOlsAn9s0n8ra/oy7j+ryKa6L0iLIWTanWQjQVhlZ39GzpZS
         +UNw==
X-Gm-Message-State: AOJu0YxQMHNDLoEkxDKzqoADaUUzFQLRUTSQaNUfM4l88LtK289ZLfyV
	itOW2P4VMjpopQiabD1BqZ2yUkg8zYYmfAqW0oS9Lme5BXXT01DbWFCD1x6WbnB3l866a8f5CAs
	/ANE=
X-Gm-Gg: ASbGnctpfhaIq/vf58ckOfNrSaWRoY/s5WZphhJoGz6sXhHdpOHKSqjyqf8uMhhHX0V
	HRjUkLiJGus7Hdm5WIsYUIS8CR0ycVwd2XVToULWVlh8D2SZd1j2f0+PSCVZ3T11Ght1SK/9dqy
	/TBmMT0sMCCd2QAYR+Ooxne9HUX5Y3rZcFLgBsr+OLpsSQlmaWZTv2t4Y1aWIO79YTlz6fOHJwz
	vfwxKxuc2EuFdayHjsCsGBZ2ZP+MrF0Hird6Sd1HgAfktLQGm/r57toigUHP3vE31DmInJNm4LA
	3OPK+YUWbV+npaI5aOUUrp4psqouHd8JrzNOW2OFdGQ8Ui45blBKQ3f5DUy/b7qxlg/+56wrr29
	XiByJHA9Ec7146GTvgkbzDrMheWhiVEeOt845iFoPO2OZNoY=
X-Google-Smtp-Source: AGHT+IGINzCxn2M3ByB5Ku7GU9Z5rnexHKxsfNOb13WFVyR36K5BdxVRGSVr1fVyEKIrERZHk/JQ4w==
X-Received: by 2002:a05:6000:4387:b0:3a5:2d42:aa23 with SMTP id ffacd0b85a97d-3a5723720aamr9692354f8f.22.1750176000682;
        Tue, 17 Jun 2025 09:00:00 -0700 (PDT)
Message-ID: <080f33dc-6381-4b85-8fd5-78e93e265b13@suse.com>
Date: Tue, 17 Jun 2025 17:59:53 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Jan Beulich 
Subject: [PATCH v2 0/5] vVMX: VMX insn handling
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

Originally, while dealing with some other patch, I merely noticed the
issue addressed by patch 1. That quickly grew then, though.

1: adjust reg_read() for 32-bit guests
2: adjust reg_write() for 32-bit guests
3: prefer hvm_long_mode_active() in decode_vmx_inst()
4: operand size in decode_vmx_inst()
5: address size in decode_vmx_inst()

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 16:01:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 16:01:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018320.1395217 (Exim 4.92)
	(envelope-from )
	id 1uRYkG-0007Od-Sn; Tue, 17 Jun 2025 16:01:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018320.1395217; Tue, 17 Jun 2025 16: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 1uRYkG-0007OW-Pp; Tue, 17 Jun 2025 16:01:08 +0000
Received: by outflank-mailman (input) for mailman id 1018320;
 Tue, 17 Jun 2025 16:01: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 1uRYkF-0007ON-NM
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 16:01: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 4683e42b-4b94-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 18:01:06 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a4ef2c2ef3so4881352f8f.2
 for ; Tue, 17 Jun 2025 09:01:06 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b31c1b48c69sm887321a12.31.2025.06.17.09.01.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Jun 2025 09:01:04 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4683e42b-4b94-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750176065; x=1750780865; 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=ulK3xIt+h78Zthsg3MeayiU/GOWMs3yPXN88/YiK/8M=;
        b=dX+60u4LpyCgl/JljXPSdAFq3KawB5eFiH0qRGVKHXc69KQcQBiRVpyjmPVAXVtdmI
         BSbF79J/8EVDm4fNwPolXqBwsRGhBJKOooLc9aHyVGydyPfTCN+u38SJSwHb5KJQOFQB
         aaPt92Qwfv9HHkVuo75F2f8Y+F+mU2VAC0woHLylnzYCfeJvqiF191aIGnmfqEW8JAKy
         BN3hUq3ADb0bNEUpBRnFlOGKN+Re1OWUWhwxtoq3jl8XQGCPrkDgLBCN6VM83liyCZuK
         owriRjuWm1LSKXT6sKwbPc53pygW+Te9dKVFn38naAffNIH/99AKUFXwB7CrWeTsqQt9
         25Yw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750176065; x=1750780865;
        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=ulK3xIt+h78Zthsg3MeayiU/GOWMs3yPXN88/YiK/8M=;
        b=dnfixQVqRxugQqYJf7/7UVg4OjcjJZBSSub4U/2jFZgSVZ258oGNnnUbu2iayVSxnt
         AWdU9OzpW1NdKhy+8RS91O2OpQRb2M9FxmgBGPiLRzNrhG+cHPUDtGIzqN6LXSR8irPm
         rhHw8Q30OrAE4iOS8BVc7tL28B3auhG5mews1EeJxKj78bkBDLXrdGjqEKw1/lVzFzv/
         M8Lx4XZgup7Ys4ZlflwJ9DdC+n3jLXxJYZE93jgA/ahlqw/16nnm7SNCoOyX8pJGKFLs
         3ToyVc9BODnXyLACEFZYhVzgG0icLdjaFOgJGxatvxVB76P4fqlZXKn05e8lmvavTYNI
         MRog==
X-Gm-Message-State: AOJu0Yxl/mNSNXHdDKVghKFPR39bP9Ym2v+x1SFvhzDcyYesXLN/roYN
	AxqtF6jlW+YVWX18/uPvkBXDl2Nou30xSbS/GyrY8iUglIaalhbnylF22T0nk0UrJgAFQftUW5I
	8I9w=
X-Gm-Gg: ASbGncsHmWaaLP8dJMNFicnyu5icfUhcd/xwAVTkO4qXuEJVZGUXS+j2ATU9kPhnzLQ
	FMYJIDlIvQujLhs3V2QzNTILLZEQmJ0bwcR1SfpyAlLhSl+tpCTtI88hIXwRa0Un/ul9oXkGFxG
	+8BYulpllv1fT4vNw7sssGXfp9DgD190H5gYgiIHrnumVNIFGPPCQ7pcnT4C+R6AZrrazetuGu1
	fJmoM4EMCMT0jnDdfiy530MrPdB+q2d5fYa8m5pi+csonuIAaZO7kBjLYXDrjpGOZEus/sYNL0/
	OJ2QOjVjZoQnE9L8DhPsG1BFQhHGpFAmMSte+6IR+drwp+iBAw7tgGMrqr/HYXNvAOvyvTeRmGd
	SUQpSdfj+Gk3RDf7a9YPIxMzFrrdoDfD/xvmNaty68poOwLqEs0XLTB3Jsw==
X-Google-Smtp-Source: AGHT+IFjZmYHii4t2L2R0ugtCzUKVlmB42TBcZ5xy1BcP9d5aOoVv0yvcaJKBbeg5694XWmPTYP8tw==
X-Received: by 2002:a05:6000:22c2:b0:3a4:fea6:d49f with SMTP id ffacd0b85a97d-3a572e568b4mr10994770f8f.49.1750176065283;
        Tue, 17 Jun 2025 09:01:05 -0700 (PDT)
Message-ID: <6702a867-da38-46e1-88d3-614776f55e5e@suse.com>
Date: Tue, 17 Jun 2025 18:00:58 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v2 1/5] vVMX: adjust reg_read() for 32-bit guests
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <080f33dc-6381-4b85-8fd5-78e93e265b13@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: <080f33dc-6381-4b85-8fd5-78e93e265b13@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Using the full 64-bit register values is wrong in this case; especially
soon after a mode switch from long mode to 32-bit one upper halves of
registers may continue to be non-zero.

Fixes: 09fce8016596 ("Nested VMX: Emulation of guest VMXON/OFF instruction")
Signed-off-by: Jan Beulich 
---
Note that the affected VMX insns are invalid to use from compatibility
mode, and hence the more expensive vmx_guest_x86_mode() doesn't need
using here. (VMCALL and VMFUNC, which are permitted in compatibility
mode, aren't taking this path. In fact both aren't dealt with at all
[explicitly] in vvmx.c.)
---
v2: Add code comment.

--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -360,7 +360,18 @@ enum vmx_insn_errno set_vvmcs_real_safe(
 static unsigned long reg_read(struct cpu_user_regs *regs,
                               unsigned int index)
 {
-    return *decode_gpr(regs, index);
+    unsigned long val = *decode_gpr(regs, index);
+
+    /*
+     * Outside of 64-bit mode, zero-extend the result from 32 bits, like
+     * hardware would.
+     * NB: A long-mode check is sufficient here, as insns this logic is used
+     * for will #UD in compatibility mode (and hence not make it here).
+     */
+    if ( !hvm_long_mode_active(current) )
+        val = (uint32_t)val;
+
+    return val;
 }
 
 static void reg_write(struct cpu_user_regs *regs,



From xen-devel-bounces@lists.xenproject.org Tue Jun 17 16:01:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 16:01:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018323.1395227 (Exim 4.92)
	(envelope-from )
	id 1uRYkh-0007oW-4M; Tue, 17 Jun 2025 16:01:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018323.1395227; Tue, 17 Jun 2025 16:01: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 1uRYkh-0007oP-10; Tue, 17 Jun 2025 16:01:35 +0000
Received: by outflank-mailman (input) for mailman id 1018323;
 Tue, 17 Jun 2025 16:01: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 1uRYkf-0007f6-TX
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 16:01:33 +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 55b111d6-4b94-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 18:01:31 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3a54836cb7fso4139209f8f.2
 for ; Tue, 17 Jun 2025 09:01:31 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b2fe168a0c2sm7592910a12.60.2025.06.17.09.01.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Jun 2025 09:01:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 55b111d6-4b94-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750176091; x=1750780891; 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=1gWmQLQxYAEESQC8axErZtnimL9IBwDep0Ap1Gsnze4=;
        b=OI5i2BN2KJr4N9JVzxlJA9fCZt46qUHTvyo+AQHJqrsYGzIcv0/WZu0dNiiDUSA5TN
         NS4cncvOBGbQKk5IhLWzxZJ+AJY3fDVinYEPL1wTKkS5kfnbL2QQPMrsNZp1kasPGG6S
         TCANY5RJEj4lSNwKzzwhTKzCHeIRtdmJugpCl2Myx7Da4TO2gyGFQ9kwmlnwylN/e2Iy
         eFm5I+t5sfraSvpEBBlt6fjUlQ/y6vORYkhGMEfLV4wcPrwnf61NpRoTh83SacQWvw5p
         bJfv9024LNkUT06eXcBAQnK5v6LbU0nusfwwiQGEU8X/U380pVnxDqMSHMYFaI6ScNuJ
         UDQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750176091; x=1750780891;
        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=1gWmQLQxYAEESQC8axErZtnimL9IBwDep0Ap1Gsnze4=;
        b=E7t4cZc12Ts4nOxqptA1aNU77U6u02QLD8ObYImibhnFMGhxYbuIbM+cRQW7mvEgy+
         uHGGqSGH42/0U2uZksy1gZP7EPUaO+ItvGFKgG4rbErWN5mtV2F1Z2mGrazYoiIbR0HZ
         +yjprDCXRZAS4Yi3Rg0Pz7xBbDH+Sc6M474U1qDU+6vK8qFEz3f+6je5YZ4OAauN8dE2
         IkFvjHKnm5offU9wfRzq+bZ2RP2nc3pUsuk7/VwCuWZlD8Vt3gXPRRwiEbav1ztgAhdz
         X51EtU6BJECIbEk7lB3UxQTC7n3MMp+wVYpCIVflWyJN9xhQYVd5lOFX152HH4AcpckP
         YABg==
X-Gm-Message-State: AOJu0YxqXypWYnulRBjYFS1d+XR8+7qNGoMCRljU9zy4aHUs+827zGAs
	JtiGmRzm2+ZS6m6DPXCBWrMslmThyCWh0iX2FZofguPShcaqkyljKe9qCcepMdtAKMMNzjG1o79
	MKdI=
X-Gm-Gg: ASbGncur02BNCIaRpROaZMQ+bV3Y5e3QCCSp3BXVxSa639u0xoy/L1/V/zk5N8FuPEy
	MXeQ3P+/oRwor7AL7mFuwKFhnMDxZF5hT0xsseiAx0j6NTP5kgVj8yx6xJ55dyV2FzQ5ZGWuNvV
	5LygggI8woUCO28wTC4qPixoSWX1o2ZpYuttMvLsSKqmPtNkEb+6nGD7JvrD/pkmfgXNEfXqwk6
	hZoq7KQ9qnN8zsMOSQESzGKgS+gHj9eX2mPTtRFiNrMpV9XUphNe7XrhCqr/2DRFK7vmJbGdKqP
	ZmjzShrrBptuHiMNgQZz84j+jiqrcTSphI74lLwlf/3v7GgLHr5PLXxNIb3mmmfdiTvhF6a0Ay6
	8Vo2melumMEHSH6SkjZpm8zdRMYg4Hag2CyDkeQZHjMgs9pM=
X-Google-Smtp-Source: AGHT+IEijHlGceymDYKDl6o4LnhCwxti4p6phzM8aOgYlCUv9bYiElLA/eBJVIACtiNFVUBe0QtYIw==
X-Received: by 2002:a5d:64e3:0:b0:3a4:df80:7284 with SMTP id ffacd0b85a97d-3a572367931mr11854548f8f.1.1750176090784;
        Tue, 17 Jun 2025 09:01:30 -0700 (PDT)
Message-ID: <808044df-5892-43e8-9a35-10f1d9a971c9@suse.com>
Date: Tue, 17 Jun 2025 18:01:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v2 2/5] vVMX: adjust reg_write() for 32-bit guests
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <080f33dc-6381-4b85-8fd5-78e93e265b13@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: <080f33dc-6381-4b85-8fd5-78e93e265b13@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Using the full 64-bit register values is slightly wrong in this case;
32-bit writes of registers would normally zero-extend the value to 64
bits. The difference may be observable after switching (back) to 64-bit
mode (even if as per the spec upper halves of registers are undefined
after a mode switch, in reality they retain their values).

Fixes: 33a7028fec44 ("Nexted VMX: Emulation of guest VMREAD")
Signed-off-by: Jan Beulich 
---
Note that the sole affected VMX insn (VMREAD) is invalid to use from
compatibility mode, and hence the more expensive vmx_guest_x86_mode()
doesn't need using here.
---
v2: Add code comment.

--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -378,6 +378,14 @@ static void reg_write(struct cpu_user_re
                       unsigned int index,
                       unsigned long value)
 {
+    /*
+     * Outside of 64-bit mode, make sure we don't store non-zero upper halves
+     * in GPRs.
+     * NB: A long-mode check is sufficient here, as insns this logic is used
+     * for will #UD in compatibility mode (and hence not make it here).
+     */
+    if ( !hvm_long_mode_active(current) )
+        value = (uint32_t)value;
     *decode_gpr(regs, index) = value;
 }
 



From xen-devel-bounces@lists.xenproject.org Tue Jun 17 16:02:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 16:02:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018328.1395237 (Exim 4.92)
	(envelope-from )
	id 1uRYl4-0008FX-Ej; Tue, 17 Jun 2025 16:01:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018328.1395237; Tue, 17 Jun 2025 16: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 1uRYl4-0008FQ-As; Tue, 17 Jun 2025 16:01:58 +0000
Received: by outflank-mailman (input) for mailman id 1018328;
 Tue, 17 Jun 2025 16: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 1uRYl3-00088u-Ij
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 16:01:57 +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 64f9fd46-4b94-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 18:01:57 +0200 (CEST)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-3a4fea34e07so3346563f8f.1
 for ; Tue, 17 Jun 2025 09:01:57 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23692e44fcesm15327245ad.169.2025.06.17.09.01.53
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Jun 2025 09:01:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 64f9fd46-4b94-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750176116; x=1750780916; 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=kbK8A6UfhnsYfm+d2Zb2+HPRhtyajycOq9heJRLUnAo=;
        b=U9vru15wWlEjVchU6yC3JVz2j0jh07gN2B5AjPpzNIg5KX5tjh5BUND3Qk8e+yCx5Y
         8zTjvg3BAp3CnyCTgoMqyyqnrSu0Xh1VBMh8o/k2FRarP0Qfsq5s4RCPvzuKm2A7xlf9
         CVXhUMU0u8hWYVqw+Nd6RgaYsoO8xl8WdbdL+ERszcLMHfrOE09kegtEXlf0BwkR0hE5
         NamRwoBD9tGevePeotXPVAEvIL/8gc+A94SCIJU8zRPFXRhaujbhwh2MzRnT2WqQnHd/
         JhFA0WG3pSrbFyvPUatCuBkkjPdtkHQqDODTVAPLfQF011PsAel8z6dw5Eowhf2NBHrQ
         lu4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750176116; x=1750780916;
        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=kbK8A6UfhnsYfm+d2Zb2+HPRhtyajycOq9heJRLUnAo=;
        b=JVExQ484HmBlySk9rOT2i3/bvDKvQ0x6fSwmQ5WWO5+OQ7trHTmLO3mb4vfJv4OC28
         LzoJ57dTR/yqXmnNyW33ye+J1naFqOgEji/xIvez3j7vgb4p6+81ZBMCoALe2PBWsUtG
         PPN9+QsuYY/UY98u3O1RkaYGJqdVan0f3pTeQXX91Aa2BjSnZB/mZ/Eva4pRZV3HZ0oo
         YqVIfwm75iHCsrndQEmM5GH+Z1aIm9P5zjI0JKr/o94X9YLAkE8PAGkfCHBnowvkSTJO
         Np8nut5RBZ/qU+OXFDoeOtZSvj0WK38vl6RvHMYViApOrwk3mCG5Hw+/pjTxm9+Od9nF
         3b0A==
X-Gm-Message-State: AOJu0Yyk0zvc1WavNYpIfm5SnxDXFdOGVbmNecL3OZ95QqnnizpXM2IL
	miuN4ivK9NZinzZmc0cP3KqC6IYaReW6Tb6VSyUYwuSQ9SUGCk4rKB3Q3u8fcw29t/yZp4R7Atp
	P3d4=
X-Gm-Gg: ASbGncsO/wT2aUp1v1N1v2C/OdvZnAPl4T+gk/4/RZlrknj//lZOXikzs+fUK0AsOJ3
	XIXzPE4EMc8imfzoXz650ZV6SaehtJKNlmsDC7hd2H/goFklSO7bVtJu8P6z4lIrEMOY4AbBlfO
	WNxoQXjExhHL2p3su+4UGjDmrYR0ThWsg6m/sS9OIYTBsFCBv6VSZRH/uVDFSdMB//dUoQ2a7/0
	8R90Zp/DSyd4qiKqRD7uyr0Szcrv5ZRb2chVW+raAaf4zZ2U36LL5pn6Ye8gQ1tX++R3/y6plMG
	WehrycvcxVOzntDzftM4JEOMDmRHtvLDvt+JUbmCRMWTRqnZhTC6QoDT5MsEj+8d/5cmSKi2dpZ
	wFOPKoebMESrr+ggIzU8ebOtryX3u7YrrmlbgXjpKLJ1Kf2I=
X-Google-Smtp-Source: AGHT+IFQloxc1HO51Alt+gIn4xw7hcnYk6sIpicZjdJHPtrOPiDNlAJ3k7VsgBmyqCoSBTTUM9cC0w==
X-Received: by 2002:a5d:5f87:0:b0:3a4:dd00:9af3 with SMTP id ffacd0b85a97d-3a572e588d7mr10765151f8f.56.1750176116374;
        Tue, 17 Jun 2025 09:01:56 -0700 (PDT)
Message-ID: <23dc1582-0e24-41ed-9433-787c7ef6f658@suse.com>
Date: Tue, 17 Jun 2025 18:01:49 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v2 3/5] vVMX: prefer hvm_long_mode_active() in
 decode_vmx_inst()
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <080f33dc-6381-4b85-8fd5-78e93e265b13@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: <080f33dc-6381-4b85-8fd5-78e93e265b13@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

All affected VMX insns are invalid to use from compatibility mode,
and hence the more expensive vmx_guest_x86_mode() doesn't need
using here.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -430,7 +430,7 @@ static int decode_vmx_inst(struct cpu_us
     }
     else
     {
-        bool mode_64bit = vmx_guest_x86_mode(v) == X86_MODE_64BIT;
+        bool mode_64bit = hvm_long_mode_active(v);
 
         decode->type = VMX_INST_MEMREG_TYPE_MEMORY;
 



From xen-devel-bounces@lists.xenproject.org Tue Jun 17 16:02:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 16:02:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018342.1395246 (Exim 4.92)
	(envelope-from )
	id 1uRYlc-0000SB-LP; Tue, 17 Jun 2025 16:02:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018342.1395246; Tue, 17 Jun 2025 16: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 1uRYlc-0000S4-IZ; Tue, 17 Jun 2025 16:02:32 +0000
Received: by outflank-mailman (input) for mailman id 1018342;
 Tue, 17 Jun 2025 16: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 1uRYlb-0007f6-Cg
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 16:02:31 +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 786d636d-4b94-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 18:02:29 +0200 (CEST)
Received: by mail-lf1-x12a.google.com with SMTP id
 2adb3069b0e04-553bcba4ff8so2877205e87.2
 for ; Tue, 17 Jun 2025 09:02:29 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-748900b09f1sm9014057b3a.113.2025.06.17.09.02.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Jun 2025 09:02:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 786d636d-4b94-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750176149; x=1750780949; 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=m0r2g8AumYTO+yNs7PfmqPv/BjQUKEeF7pA9dmiAzgc=;
        b=NyIwtuHJIHvzl1WfYneJJco0VYKxUq8YTxSwIZdWNcZToPGQqPgyNEHZypWOZQijlw
         aWj+mb9ZE6hJELkKTPbf+YW8td172vgx+plAiu5tYAtZGtqS9Xa2PYBeCQW6HrAzrj/6
         +lv9rRGV8/JVB1avwmjPPy2NEP0O70xaj3gnIvutry0dYZ32iwj9AvTCPJOlNMKXVivR
         r65z4Wi42J1Nw/UsKyoPQ0v9Uc6OafuCG+6ExFL3p5VEKeHBO2dFGXUA962CPkslOs2w
         1yIQsb5aGY+EiaFqUa8bYiMrzKRTDhx+t5e1MR7+KMcDi36rSia4JatrY3Bqb3vMfiXF
         m4RA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750176149; x=1750780949;
        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=m0r2g8AumYTO+yNs7PfmqPv/BjQUKEeF7pA9dmiAzgc=;
        b=CJXkUzg+X3GMXH5wMR+PhYsknLfa6XUB93ZglgUQQDXgDlLmyTNHbo06qZLZJP/SrN
         Ou2y0yAZ1pFnCGZ3llm+edtCqrf5UFLC6S2hny05yAfQXfyPT6UB8djmY9F0bY+A8zGU
         X7XhVjDsTaxbtgG/fsS7QIahKgeElLGGcOQwNnuyDSM2Av88hRB+b8iXZqPj8wffzKXQ
         yQpPn9rkPdmw6uTUL0f8Ys3mkgFmrp82zfpNcsxZTu3k+eNNEfmR48VjC4B8eXNDOtKm
         BbNWFsiCeu6xTGQwdnMd+Nm3GiMOTuChtowvFR+keBPEhuOzVDauIYwb+GPW1exvs5CC
         3hfw==
X-Gm-Message-State: AOJu0Yw0XnTBMNJy6NhQZ7LQfM8/1xIkhl6PwCHJGQRXMwetamE2YWOi
	zdWnIkipaZUxpQZAsV5pNamwSX+yvlGZhtOydvyX4OQyn5i8RE+htA0uO4Ml29ktXPSTC9lXYCe
	WeBo=
X-Gm-Gg: ASbGncvFneY6dBcQEaoZLFqkRZj8VF/7kwxoJyBCpSjhvhWV35Z1VOtywaR7kh8VAt8
	SHiM25FChiT8qY6fZlERxWv4O6Zh+RrctVydOXxmcRmt3UkJSwnEOsVjBAOVy2sQ8Mp6vN1fjcT
	9JXob0ABsTATu9mCLcyDcO8vXI4rmc2e1xoQbYNoS/JBRbYfXxNBzZyVM4DDKIjMcvVf076U+LD
	hUd1D0ZSUYYa0sgtXLJYCXqgKMZUloTh+Avs1bgsGwAneXS5M4PR6d+wH9sgVMGVJ7SEHRVgsjL
	4TP06nvJslxFPgBxs/KsNt8NYd7vX4LeonHK9MGLlEjX0vvn0i/YlcuguAzOp4gRLfLFMFGaYDO
	BlWU9TUY5fYx9ugzt487Xr2RYgbCiexSE7Ai9z+6XoJsidNY=
X-Google-Smtp-Source: AGHT+IHW7PvOSxWAKW31+3M7RYDViPeuR9qGeTgU3uJr15ojueHOvA46JpnfdZEme8SB7cuDRQR7Pw==
X-Received: by 2002:a05:6512:15aa:b0:553:34d6:d67d with SMTP id 2adb3069b0e04-553b6f4e4b3mr3497288e87.46.1750176148524;
        Tue, 17 Jun 2025 09:02:28 -0700 (PDT)
Message-ID: <283e9961-7bf8-4f2c-9fcc-f4e09c91a28a@suse.com>
Date: Tue, 17 Jun 2025 18:02:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v2 4/5] vVMX: operand size in decode_vmx_inst()
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <080f33dc-6381-4b85-8fd5-78e93e265b13@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: <080f33dc-6381-4b85-8fd5-78e93e265b13@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Address size is entirely irrelevant to operand size determination; For
VMREAD and VMWRITE outside of 64-bit mode operand size is 32 bits, while
in 64-bit mode it's (naturally) 64 bits. For all other insns it's 64
bits (a physical address) or 128 bits (INVEPT, INVVPID). To limit the
amount of change here, keep the latter at reading only 64 bits from
guest space.

Fixes: 09fce8016596 ("Nested VMX: Emulation of guest VMXON/OFF instruction")
Signed-off-by: Jan Beulich 
---
Beyond the wrong operand handling for INVEPT and INVVPID, the latter
also doesn't even have the part read checked to have bits 16 and above
all clear.

--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -411,13 +411,13 @@ static inline u32 __n2_secondary_exec_co
 
 static int decode_vmx_inst(struct cpu_user_regs *regs,
                            struct vmx_inst_decoded *decode,
-                           unsigned long *poperandS)
+                           unsigned long *poperandS, unsigned int size)
 {
     struct vcpu *v = current;
     union vmx_inst_info info;
     struct segment_register seg;
     unsigned long base, index, seg_base, disp, offset;
-    int scale, size;
+    unsigned int scale;
 
     __vmread(VMX_INSTRUCTION_INFO, &offset);
     info.word = offset;
@@ -449,7 +449,8 @@ static int decode_vmx_inst(struct cpu_us
 
         __vmread(EXIT_QUALIFICATION, &disp);
 
-        size = 1 << (info.fields.addr_size + 1);
+        if ( !size )
+            size = 4 << mode_64bit;
 
         offset = base + index * scale + disp;
         base = !mode_64bit || info.fields.segment >= x86_seg_fs ?
@@ -464,7 +465,9 @@ static int decode_vmx_inst(struct cpu_us
         if ( poperandS != NULL )
         {
             pagefault_info_t pfinfo;
-            int rc = hvm_copy_from_guest_linear(poperandS, base, size,
+            int rc = hvm_copy_from_guest_linear(poperandS, base,
+                                                min_t(unsigned int, size,
+                                                      sizeof(*poperandS)),
                                                 0, &pfinfo);
 
             if ( rc == HVMTRANS_bad_linear_to_gfn )
@@ -1561,7 +1564,7 @@ static int nvmx_handle_vmxon(struct cpu_
     uint32_t nvmcs_revid;
     int rc;
 
-    rc = decode_vmx_inst(regs, &decode, &gpa);
+    rc = decode_vmx_inst(regs, &decode, &gpa, sizeof(gpa));
     if ( rc != X86EMUL_OKAY )
         return rc;
 
@@ -1788,7 +1791,7 @@ static int nvmx_handle_vmptrld(struct cp
     unsigned long gpa = 0;
     int rc;
 
-    rc = decode_vmx_inst(regs, &decode, &gpa);
+    rc = decode_vmx_inst(regs, &decode, &gpa, sizeof(gpa));
     if ( rc != X86EMUL_OKAY )
         return rc;
 
@@ -1865,7 +1868,7 @@ static int nvmx_handle_vmptrst(struct cp
     unsigned long gpa = 0;
     int rc;
 
-    rc = decode_vmx_inst(regs, &decode, &gpa);
+    rc = decode_vmx_inst(regs, &decode, &gpa, sizeof(gpa));
     if ( rc != X86EMUL_OKAY )
         return rc;
 
@@ -1891,7 +1894,7 @@ static int nvmx_handle_vmclear(struct cp
     void *vvmcs;
     int rc;
 
-    rc = decode_vmx_inst(regs, &decode, &gpa);
+    rc = decode_vmx_inst(regs, &decode, &gpa, sizeof(gpa));
     if ( rc != X86EMUL_OKAY )
         return rc;
 
@@ -1953,7 +1956,7 @@ static int nvmx_handle_vmread(struct cpu
     u64 value = 0;
     int rc;
 
-    rc = decode_vmx_inst(regs, &decode, NULL);
+    rc = decode_vmx_inst(regs, &decode, NULL, 0);
     if ( rc != X86EMUL_OKAY )
         return rc;
 
@@ -1996,7 +1999,7 @@ static int nvmx_handle_vmwrite(struct cp
     enum vmx_insn_errno err;
     int rc;
 
-    rc = decode_vmx_inst(regs, &decode, &operand);
+    rc = decode_vmx_inst(regs, &decode, &operand, 0);
     if ( rc != X86EMUL_OKAY )
         return rc;
 
@@ -2038,7 +2041,7 @@ static int nvmx_handle_invept(struct cpu
     unsigned long eptp;
     int ret;
 
-    if ( (ret = decode_vmx_inst(regs, &decode, &eptp)) != X86EMUL_OKAY )
+    if ( (ret = decode_vmx_inst(regs, &decode, &eptp, 16)) != X86EMUL_OKAY )
         return ret;
 
     switch ( reg_read(regs, decode.reg2) )
@@ -2066,7 +2069,7 @@ static int nvmx_handle_invvpid(struct cp
     unsigned long vpid;
     int ret;
 
-    if ( (ret = decode_vmx_inst(regs, &decode, &vpid)) != X86EMUL_OKAY )
+    if ( (ret = decode_vmx_inst(regs, &decode, &vpid, 16)) != X86EMUL_OKAY )
         return ret;
 
     switch ( reg_read(regs, decode.reg2) )



From xen-devel-bounces@lists.xenproject.org Tue Jun 17 16:10:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 16:10:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018354.1395258 (Exim 4.92)
	(envelope-from )
	id 1uRYti-0002GW-GX; Tue, 17 Jun 2025 16:10:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018354.1395258; Tue, 17 Jun 2025 16:10: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 1uRYti-0002GP-B2; Tue, 17 Jun 2025 16:10:54 +0000
Received: by outflank-mailman (input) for mailman id 1018354;
 Tue, 17 Jun 2025 16:10: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 1uRYm2-0007f6-Gy
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 16:02:58 +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 88a830a3-4b94-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 18:02:56 +0200 (CEST)
Received: by mail-lf1-x130.google.com with SMTP id
 2adb3069b0e04-5535652f42cso5897291e87.2
 for ; Tue, 17 Jun 2025 09:02:56 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-74890083c0fsm9033929b3a.72.2025.06.17.09.02.53
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Jun 2025 09:02:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 88a830a3-4b94-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750176176; x=1750780976; 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=3VoPrsapEJe6cnYVGPlEbMcKBx2LN9u76bVC8NTafYM=;
        b=QTcdaAEYqvb6VCs1ey0tE+knX2Rwk9sVOrxa7HHcfzE3ZTSJn7VmBHT5L5P2/Ttej/
         /Fd9UZf36oZjj90oFtjDMRRsh+cn6+53PwUEzJY9MT+EIAHVH1Aw1dvdXna/TAVxYeZM
         cz8RlhFVzgFdEQlY4t4W2Y9FV5TQ8wKgqGhOh30kLxk/AMFoGB5ulOPsp5EyrRc+ZyQq
         fPfWDton79Brw25ZXj4CuOsEjTgsp/sG1lPGrv2yj+XIu4mVpXR9BlQsjCaah40d0sKB
         uPV1n/8AAcBVXlu+F1EejDGjrAAf6wQyWKL83tSnKj4ySnjZgzSm7f5wqxJwqPcPTB4h
         bN9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750176176; x=1750780976;
        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=3VoPrsapEJe6cnYVGPlEbMcKBx2LN9u76bVC8NTafYM=;
        b=YE4/uX/yxQwruWZBAL/Ta+T7GXzRuIqgM6I+/ew1QjZmC5K2nlRGeVmH2rPIbU48nx
         EH3SsKDJyMw5dA+DMPu4CPiMQY7QEOa6mvL2lUhVpjNaAn2PUtP67EmcKTmrjD2o7eIz
         6h13H0e/t12EnfCqjAuJReXd7uwj3wjzx5nG6VQDt0ZOSk55BcJJI8HPSDruH9W5sL1O
         m01/3J7AqtxQkJfcVgAJ/rQtGoa9MRpTZiNvCvpLek3310J9aD3DKKxB0P4KWnwuvRe7
         IhCZlLhMYhu7PbDyHUGXt6IkIBx6+z1Bh4HkV01rNMhY25M1yKj6rDn0ftNqlfo6vVI6
         vO8g==
X-Gm-Message-State: AOJu0YwdXXGug6MSo4MFjxse2BT91w/m9nXN/o7Q31EANUvsxD0lQNYV
	h91R4rvOihrEy8qIdu+v8xtEP2zlNebVY1jUL8v2AstCHPcbqQ6IcitRGtKzvpTwW2bC+ow5T7e
	8/rg=
X-Gm-Gg: ASbGnctn8nSTRDpPObVBGEaie8hPuVggq1+sFco5NzT9uHpIMyjq/Llz1HWco77iaK4
	M4VnYw1spGd00Uuy7JhiXdxvRctJDQQroghgzElH/1WYeTQAh5yzN+EXTfzmTCQT4Tw5gZRPurR
	HhBi2gXZClXbWTs1xB7P5tSr/sFr+jcH+3rqpLeLEPvKAmibskKYc4Z3nuDZrtODtA8Z9Vjctyy
	yavT2iiA/6z248H0Mzw81IylZv5kM4xsC+BddKx8fnir/FYwV83Qsopd1p8Xk5nies3c7oP3Wfh
	02l5oUEwhov7D3yEZSrnpQrvHZUa71w7P3x8+PVojEhDBp3Vx5NuZAeoFjZCjGRJub2oRNX9AgM
	oIlR8QSy6EbCPCjRc81sxbxjRkSgkpvXq2B3Lvm5MyVncLCY=
X-Google-Smtp-Source: AGHT+IE19BxAWlHpgOXiWe2qTL9rpAV4ct7l2odaZJlPG0+KL8RAh62AvEcmfqulcGKe0/k4ttRBJA==
X-Received: by 2002:a05:6512:4011:b0:553:ad48:3f2b with SMTP id 2adb3069b0e04-553b6e7d1e3mr3501048e87.2.1750176176030;
        Tue, 17 Jun 2025 09:02:56 -0700 (PDT)
Message-ID: <5bc8d03f-ee68-4405-b615-f3183d60c2b5@suse.com>
Date: Tue, 17 Jun 2025 18:02:49 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v2 5/5] vVMX: address size in decode_vmx_inst()
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <080f33dc-6381-4b85-8fd5-78e93e265b13@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: <080f33dc-6381-4b85-8fd5-78e93e265b13@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

While the original use of the address size file in the instruction info
provided was wrong, it still wants using: The offset into the designated
segment still may need truncating accordingly.

Fixes: 09fce8016596 ("Nested VMX: Emulation of guest VMXON/OFF instruction")
Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -453,6 +453,13 @@ static int decode_vmx_inst(struct cpu_us
             size = 4 << mode_64bit;
 
         offset = base + index * scale + disp;
+        switch ( info.fields.addr_size )
+        {
+        case 0: offset = (uint16_t)offset; break;
+        case 1: offset = (uint32_t)offset; break;
+        default:                           break;
+        }
+
         base = !mode_64bit || info.fields.segment >= x86_seg_fs ?
                seg_base + offset : offset;
         if ( offset + size - 1 < offset ||



From xen-devel-bounces@lists.xenproject.org Tue Jun 17 16:29:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 16:29:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018361.1395267 (Exim 4.92)
	(envelope-from )
	id 1uRZBL-0004Hf-Qi; Tue, 17 Jun 2025 16:29:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018361.1395267; Tue, 17 Jun 2025 16:29: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 1uRZBL-0004HY-Ne; Tue, 17 Jun 2025 16:29:07 +0000
Received: by outflank-mailman (input) for mailman id 1018361;
 Tue, 17 Jun 2025 16:29: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 1uRZBJ-0004HS-Ki
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 16:29:05 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on2061a.outbound.protection.outlook.com
 [2a01:111:f403:2408::61a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2db3631c-4b98-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 18:29:03 +0200 (CEST)
Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
 by DM4PR12MB6205.namprd12.prod.outlook.com (2603:10b6:8:a8::19) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Tue, 17 Jun
 2025 16:28: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%2]) with mapi id 15.20.8835.027; Tue, 17 Jun 2025
 16:28: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: 2db3631c-4b98-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=q7cVa8Z33I7KqRzvPjBx6HkfptkHAAc90JcvF/5FXL2+6TBZuOqccye4hzlSfB2eLWpXP7fQOGLhJlLYG1a5GdOEGVRbxjORWO5cBHAbnCfvB25evJf/P6dD9RUlrIwzlZhrzX/VCBE7k1odr/PHNnMKEF0RBxEgtSMN0/6bVi0E6KyJlu7vvrEJz2XVDXFnIsIIDNfYU+OKis20ZbKEwcbq/qK3UJQ+iGjkjnrysgL+IZJGVOixw4I+lnFlqizFFR4Ea1Nzwf03wo76TnKgmrd2rwRSzwUhtg5wqzd8pLxL9wE2GvwYWPF1BHj1j1IA/oadzlCWHgxVtPpaeTd7aQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Rz+fx19Fsuiha2f8OkeysdgWFIsl4ZRR/PssR75h0cM=;
 b=YG4xkcBVZRLe5+hFvO0aDIhxlLWcCvWkTeN2GvneeOyMayH4JoTf5JgUSwPZo9xf0+3BrSqSeTJ66+a4y5lw6yRL2L04Hsv4h4TW+RD9OOEY5McGVuSslqYj5vflsHroblp+kxyRCHprsApDySic7WdYlJAtulaC6iBTEZ0XnTvFtyRAg2GZ4YiQhZSFpFA8Xa4D/RIZKaNYPiRD6okbpAgGc5OTRIVonHQf7j8pF505ZQUwDDmRTL1UckjqYY5qbfy2FTpl3p0V7COrWmUMv0VwdQ+R345sWGc5sA/xiFgn/VKC1MkOk45EbjOaJPN6vp1jErdJ1NKg1I0wwoSHlQ==
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=Rz+fx19Fsuiha2f8OkeysdgWFIsl4ZRR/PssR75h0cM=;
 b=r2AUC+VWXt9ksoUe3wYmfgzku1+17CXvVcbbt+5U/B/6cEwozrYmdB1LBg1nPpHI0pHtP70T1TmnMYsN55YE2x6wxUh02KK9o6ZAwC3pTawf3Uwyql60/4/th1rgc4Z9CxplfZkaRhK1zRn3+VouG7aORnpSvQhNcVYWfa5+3vc=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Tue, 17 Jun 2025 17:28:54 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 3/3] arm/mpu: Enable read/write to protection regions
 for arm32
Content-Language: en-GB
To: Hari Limaye ,
 Ayan Kumar Halder 
Cc: xen-devel@lists.xenproject.org,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Luca Fancellu 
References: <20250617111251.1711553-1-ayan.kumar.halder@amd.com>
 <20250617111251.1711553-4-ayan.kumar.halder@amd.com>
 
From: Ayan Kumar Halder 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LO0P265CA0004.GBRP265.PROD.OUTLOOK.COM
 (2603:10a6:600:355::14) To PH8PR12MB7326.namprd12.prod.outlook.com
 (2603:10b6:510:216::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|DM4PR12MB6205:EE_
X-MS-Office365-Filtering-Correlation-Id: 25becd48-f54c-4e55-41b6-08ddadbc0ff6
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?UmNVMklxV0VoVkFNcWxRSmhQNFRybStvclJwdDFRWmNibWZsZVRvMkcvWW9j?=
 =?utf-8?B?NVZDVU93SnVJakNwWFU1MzJqL3NSOXM1SGhFeTkzTnlRMmEyT1hxOUwxdFBI?=
 =?utf-8?B?U3B5TnNYczJsd3NlaU9qLzBrQ1dWZi9mRi92NUx5RmVKdy84UVB0cHA2OVAw?=
 =?utf-8?B?WVZ6cW1iMkZPOVp4cGVKSUJOSjVVaWFyekY1c0h4Ylpia1RVVWxEREZueEN1?=
 =?utf-8?B?YldHcm9YRkk1anVRMGxkdnlsRmx0YWtCNzNwcVJwQ2JsbFVoVFh0THo5N25m?=
 =?utf-8?B?NlFMNmhLd0xLSFpoUnBnUGt1NmNrWnV5VXdxUjFGZlhNUFE3RkY0SUxicXRU?=
 =?utf-8?B?azNmZzVmb2pmcUNHSnNWNkJFbUpITHVpZmY4N1lWdktLMHQ3dU5VZ0FTMmQ5?=
 =?utf-8?B?MHBJQU9rNEh6QTlSdW1qc0JjeUU0U0FOZnpiOUVMb1BTbDJORVd0aTZ1RzlZ?=
 =?utf-8?B?cENPSjZwbDFhS0RXTFo2c1NPaHB3YnhTdjlNMzZad25udWp3amdqVUpyRktS?=
 =?utf-8?B?cWtIMkdaRk5COEM4TjRlNGFlVFdZUHBGK3NjcFJ2TGVMWUpCMjB1bjROMUJv?=
 =?utf-8?B?TGtKaUFLVHY0VEhaWW5wQklzbERlSk82SHBzVDJxd2RiVUhhMHVCOUhLUHlV?=
 =?utf-8?B?S2dCWlM3RVhiYzZmZ1ZuaGJUcWlKRHR3c3h0MmlzOGZiTUlQQkVvUFF6aGZo?=
 =?utf-8?B?MmNXQk1NK1cyT1haMlZSck9PSkZ3M2lKMEF2ZlBlbUVUb3pLRjYrSmUxOWMr?=
 =?utf-8?B?MU1Rd2lNOXEzVVg2aGh2SnRTaEZhNVN2bTBwbGF0Z3c1S2dIRDZTei9yWkVq?=
 =?utf-8?B?bzB0SjhXYi9uSjdIRU1Uc1NDMjU5QVJ1TmFOaEx0TmZsa1crS3hVdHNrWlQ5?=
 =?utf-8?B?SG1vREpmZER0UkRlK1laT2w2c2FDdmFucTNVblV6QW5wNWJkcXlMYnlzSXlr?=
 =?utf-8?B?TWhPbDU4Qk02VTUwV2FOanA4bXNDZ2YvVXRqT3F1T0JzWEJ1Vmw3N0s5Slh4?=
 =?utf-8?B?MkpKL1J5bHNUUVZFVXgzcDNNRnA4a1dwY29ENDdqZm85UlExTUZwMWZQTEdI?=
 =?utf-8?B?TW5jeFVVdU5IdlpiR1ZnalN6WEFCelJpSlI0VS9CVDZpMEl3VGRrd2lvOXc5?=
 =?utf-8?B?b1FZTENTWDBwWTVYTm1CdUoyQllPTVFldE9MbEx5aG1WRTJBQlo1RW1wWTd2?=
 =?utf-8?B?WE1CQjMvOGl6R0IwbldHbTYrY0JJL0p6UXBKdTRGWkhYR2g5WEIvYUFKbzlU?=
 =?utf-8?B?VTdXazcxSUcvVlplaUZNUlFmU05CanZReUdtY1FDUE80UkZTbnAzUEw2aVlE?=
 =?utf-8?B?aUE4T1Q1eGkzMnRaaEs3aXlPbFc1d0NvWXJIMWpLVEE4a0hGL2xnMkp6MXpk?=
 =?utf-8?B?cG55UlMvcE1EdGp6T0wvWXlQbnlKQUdlZ2pzZDhxRm0yOUtCZXl1N21qbGd1?=
 =?utf-8?B?SGZOS2tQNk9jS2taNCtwb1M1ZjMyQm1QQVcwRGlvSGkwR1N4Sy9wVnloSXdU?=
 =?utf-8?B?NEFVekJaUWJ2d2RQVnlabS8yWWxITTBrcU9SeG5KeUJ0SDhmNU5MY2dPME9a?=
 =?utf-8?B?VGYyaWcxOUk3OHlmRGQ3UW5uQVlFMkNDVUhkNDcvOFo2QndRdEV5V1BkeVdh?=
 =?utf-8?B?NlRmeVlLN2psNFR0Z21GTEttQkVDSkRUN3RQZDN0RVZvRnlzbERTaThsVDFZ?=
 =?utf-8?B?ZWpGSStrVVhNSlBWcFBRUlRhTXBGaEpGdHBiMFhZcWFVbWxPVno3TzF3L1RR?=
 =?utf-8?B?ekp6MDVmNENKelhTanBvcjlLSW1qMHRRRERBdGxLdG1yeTR0VW4yb0w0L1Bo?=
 =?utf-8?B?ZzFrQnplTlZjV3l4cmZFdTBFUW1va2V1ZDMxck1HUHhvZW9EZ3Njb1JOdndC?=
 =?utf-8?B?MDdtRlcwTE1MU2draE1jaWtYbHNCVTg0RjkvZnFIdVQwMWhvbXF2MzB2Mzhp?=
 =?utf-8?Q?bLwn4PhHqgE=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)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?czNHNnNFWE91QUlXKzcrcFhsUEVFa2RHNlJia094MFdmTmkwT3drbHJsTlJo?=
 =?utf-8?B?YVUvc2RvaUlQWFZZQnUyek1pdHRqaTJXMzNhSG5jb1pmZEtTQ2RoblQ5ZGRI?=
 =?utf-8?B?eG0vK2dBU2JFN2VKc3o1U2g0aUt1b2pFL3VYWHpoSDVMNG5uVTBycWVsY0Zk?=
 =?utf-8?B?L1RCTjZLUUtMeEFaT3ZTRm9xUFpjbFNIbnVqWG9mS1VKa0Yyc0w1ZTlMemFy?=
 =?utf-8?B?RktYOTdjd0MvNENLR1M4QWpuNXFJQlllLzZFaGVSdEduTU95RXFGcTJPMzRU?=
 =?utf-8?B?b0kyZjRBL1Y3QWhrS0Uwb2tiTXE5d1R6MmdwYVE3NlRpQlI3b3o4QU1UTXZV?=
 =?utf-8?B?eUxNLzFONjJjWlJrWTl3U1QySUJ0aExWL1cxMXZZSnhPczJ4OWxObDA5OTBK?=
 =?utf-8?B?bGdQTVpMZm8yMVZoNndEdWVveld1WUtzMXF0RmpXUDJKTytUZlQxTW9MQ3l3?=
 =?utf-8?B?dzBlc2RtTTZjZHMyNDRmWnlsN2dLcEsxZ3RiUS9XaHM0ZWFGOVVkcEtkN1RG?=
 =?utf-8?B?cHliREFUMjFuaTdPeFo0eERjQ0NCc3g4YjJuMXZ2QzZ2UnNkN0FQc0hNeXFK?=
 =?utf-8?B?RUFDTHVoTldRamlxMzhYRVFkbHUramVHaERjcDM1SmdnQjFiblNPSGZOcXI2?=
 =?utf-8?B?M0dkcTRvSGdtQUVuTElOVU1kK2dNcndRZUtUTjRTUW1HSkY0Q3Q2WThhbHZn?=
 =?utf-8?B?R1dXbVpYLzNLOU9VR3l5MnF6RkxtN0lQeVhVVTRGV2ROcHdRdUVEREhXeFpE?=
 =?utf-8?B?N20waEU0VnZrQ0l5UXFMQ0ZoMWhib1I3VkFVQnhCWWIyYkZPNlFESzNsS0tw?=
 =?utf-8?B?UmNXWkU3TDY3VkZ0UlVSUE5XL21aWWlEdlpnWmZnMDNxblR3amNZSUF0eDBD?=
 =?utf-8?B?OUttQS9jWlN2cFQvOVFEN1QvSkNIaHc4L1dBVCtPSEsyb3UvQU5jclNMVVlt?=
 =?utf-8?B?UzZ2L2ZZQTg3S283emZaMlBXeXFha0ZiMXZCcHZBUndkWDRFL1V1b2czaitQ?=
 =?utf-8?B?dldGLy9tZ1pvYXpDSWJiQmJyZUpvdnZiZGpGQTJtczBpdys1cHd0SFlYdkhW?=
 =?utf-8?B?Wk5GbWNZRzBNODUxbjg0NklBQjFoMUQyQXA5L3k0WnlVWmE5cDhyaHJaSU1I?=
 =?utf-8?B?UlZiVXk4YllkdnRrTy9WOWgzRmVQOWo2emhpdDBmMWxnNGYvMFRDeWd4N1U1?=
 =?utf-8?B?c0M3cm05OGQ0WjFGUFMzZEVZYllBUVdSY1ByWnB0V1BJN3c5TnovK0U1RGhK?=
 =?utf-8?B?YTdOUjJWSmV0YWY1aTZhTWowQ1Z6SVB1Q2FSZWtVWFY5N3duV0ZhbjZvQkQ2?=
 =?utf-8?B?YWVlc2dUc2dXTE5VcFAzbjAxQ0dOeUFtNDlaa2dibGUvTXF0UTlSTmMza3Fj?=
 =?utf-8?B?VmU0MFpXSkduT0w4eWZwVFN6NEtEQmhNSmM2cHlhVGlqQlRaZGhaOU1yK1dF?=
 =?utf-8?B?V0FMWFlwZWsvb2Z4Rmp4bVAyUVI3T1g5Qjg3YWxJUjRvSE92cU9MZmVCUHhm?=
 =?utf-8?B?K0hvOTJ4NEJDOWhNRE5OOFVZSlVvQnFtTFdNbUcvZXlXYXo0UG9EWHR5SFl2?=
 =?utf-8?B?UkhoU1Q4cUhvQ09uNXJTQ0dISXBMYTlDVzdNLzQya1ZNYVVTRTQwdFkycEwv?=
 =?utf-8?B?UmNFNFpYYWNuKzRuTE5EVWIxY0FwUnRFd3BaM1FNTTRKckdRRHNHaDhhYVBn?=
 =?utf-8?B?WnZxajNSdUJtb1J2WHF0MFA2THhVU0J4Y3hCWFBVS3ZFMzl3NUZhS0E1bklW?=
 =?utf-8?B?d0pUT1dxOGJ0ZVNoU05Id29XZk9NTml6RWh4TGdVVFhKNmVuVTZHWmJCTS9h?=
 =?utf-8?B?RnB2dTNoMWtrUFA0dXByRXF2TWVlaTlJOEFtRXlIMEtvV0VwOS9keVpYSElm?=
 =?utf-8?B?R1liTTNJcWlQOE5Fa1V0c0txNFhiOTEzTDV5MXAra003M2IwbXZWc3U1Y2V4?=
 =?utf-8?B?bCswbGw5ZkxnY0FHMlZhbDFZMGJRQzUyL2lDMkVnV3JyRkcwRkRHQWpnWWFL?=
 =?utf-8?B?SWFteU1TVy9EajNTL0Y4ZU9FeGxDVFMwSHlJaE1RZW4xQmwwMEhHRUdlQjJS?=
 =?utf-8?B?aEwwYWpNOW9KWFB1eHVrK1NYS2g4QW8xTUhPWTFGaU5OVkdZa1BBUU44NzR0?=
 =?utf-8?Q?if9o2+XhTDSd8E3XgX2jY6009?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 25becd48-f54c-4e55-41b6-08ddadbc0ff6
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jun 2025 16:28:59.2143
 (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: p2iwHI5dC2A8uScRQkI1Df9bMwIjIO1Eg5wvt4NQJ/1JWxgIHtq4vd0J/oh3OEdpoPcuN55JfE34HikcI3vxeg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6205


On 17/06/2025 16:31, Hari Limaye wrote:
> Hi Ayan,
Hi Hari,
>
>> +/*
>> + * Armv8-R supports direct access and indirect access to the MPU regions through
>> + * registers:
>> + *  - indirect access involves changing the MPU region selector, issuing an isb
>> + *    barrier and accessing the selected region through specific registers
>> + *  - direct access involves accessing specific registers that point to
>> + *    specific MPU regions, without changing the selector, avoiding the use of
>> + *    a barrier.
>> + * For Arm32 the HPR{B,L}AR (for n=0..31) are used for direct access to the
>> + * first 32 MPU regions.
>> + * For MPU region numbered 32..254, one need to set the region number in HPRSELR,
>> + * followed by configuring HPR{B,L}AR.
>> + */
>> +static void prepare_selector(uint8_t *sel)
> NIT: s/one need/one needs/
> NIT: s/MPU region numbered/MPU regions numbered/
Ack.
>
> Also - it's not clear to me what is meant by "followed by configuring HPR{B,L}AR";
> if I understand correctly, once we have set the region number in HPRSELR
> and issued an isb we can simply read/write HPR{B,L}AR as indicated in
> the bullet point above?
yes, this is correct.
>
>> On Tue, Jun 17, 2025 at 12:12:51PM +0000, Ayan Kumar Halder wrote:
>> Define prepare_selector(), read_protection_region() and
>> write_protection_region() for arm32. Also, define
>> GENERATE_{READ/WRITE}_PR_REG_OTHERS to access MPU regions from 32 to 254.
>>
>> Enable pr_{get/set}_{base/limit}(), region_is_valid() for arm32.
>> Enable pr_of_addr() for arm32.
>>
>> The maximum number of regions supported is 255 (which corresponds to the
>> maximum value in HMPUIR).
>>
>> Signed-off-by: Ayan Kumar Halder 
>> Reviewed-by: Luca Fancellu 
>> ---
> Apart from the above, all LGTM! I've tested compilation for both 64-bit
> and 32-bit and all is building successfully.
>
> Reviewed-by: Hari Limaye 
> Tested-by: Hari Limaye 

- Ayan



From xen-devel-bounces@lists.xenproject.org Tue Jun 17 16:45:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 16:45:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018374.1395276 (Exim 4.92)
	(envelope-from )
	id 1uRZR3-0007Op-71; Tue, 17 Jun 2025 16:45:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018374.1395276; Tue, 17 Jun 2025 16:45: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 1uRZR3-0007Oi-4P; Tue, 17 Jun 2025 16:45:21 +0000
Received: by outflank-mailman (input) for mailman id 1018374;
 Tue, 17 Jun 2025 16:45: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 1uRZR2-0007Oc-Lg
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 16:45:20 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20610.outbound.protection.outlook.com
 [2a01:111:f403:2009::610])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 72c5d71a-4b9a-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 18:45:18 +0200 (CEST)
Received: from PH7P221CA0012.NAMP221.PROD.OUTLOOK.COM (2603:10b6:510:32a::29)
 by BN7PPF28614436A.namprd12.prod.outlook.com
 (2603:10b6:40f:fc02::6c9) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Tue, 17 Jun
 2025 16:45:13 +0000
Received: from CY4PEPF0000EE3F.namprd03.prod.outlook.com
 (2603:10b6:510:32a:cafe::32) 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.8835.30 via Frontend Transport; Tue,
 17 Jun 2025 16:45:12 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CY4PEPF0000EE3F.mail.protection.outlook.com (10.167.242.17) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Tue, 17 Jun 2025 16:45:11 +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; Tue, 17 Jun
 2025 11:45:08 -0500
Received: from xsjvictlira50.xilinx.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 via Frontend
 Transport; Tue, 17 Jun 2025 11:45:07 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 72c5d71a-4b9a-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=scrrEFDC7mhkoUDHz5fjKTr/QcYHlktVMlwtolK/6ZQmDO9P+vNjKnAevwxokdPkPAMjwdxJWy2pZ+/+jdK8NrLxf2+41nVKllKInXNfUXuzVKtTl3lHV8VrMVLssweHZbinFHeN4gzNpiJe/8uqk+5toCtYr9BLd9j2slw4Dg9KLHZTdq/9AE4G7XXQY9+ekeGthHtSNOHeZoLQLqB0/nw6zlfzbCwAnL9iSB8egqzDcDsf44Kec9tojr7XKFKd4VAuPSr847A+bJFEZMVv5+gTDFggdzYj0Dux1lx21WkafLU0p8D+jVm0Q6RYk+hSPDQlGScxhfb67JrWFhfk2w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=X0QV8ndC6NFKGSOtPHxZFmAQtmqwxkUGIhEfBRv68F4=;
 b=JVsPWKBpE5WZ3X7t6Smn3Yagp+AIQWpqTcClsZPHjfYOb/8SbrxgFSGX/tQWdGqoSFzSLReCCxxbXHws558IJWASUBBVFNkf3bvgvNQ+ctcclqvJIUL7v5xWCX0KgrcB+wshWK1uyVopafwa8RfN1BhplEz2ZC3qVy3NP9Gs/QNBVMquX1+lywZLwaEYyvJw/bSnb4LVU1anl+obR6aYBSgs7PU/TIcVmnGE0fTwYnREIq4D66bcOaJRMld1B7NTLW6Oklu9X6Cph/zMqDrJTbaYysX970s1V3PTpL9TKI/RI6j4E0pp6uitpF3jdAcu1Xu+c984I7Zx1GAdTe25Ww==
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=X0QV8ndC6NFKGSOtPHxZFmAQtmqwxkUGIhEfBRv68F4=;
 b=IXaPOutaHXLV3GuXnhcvSHYXOlAVjzjK+nOM1+NvUwub00OMGPYR8C7iuB8+Ol9r7KouWeQVA31rZ71lgtIpr/s/YqZ4aN2K6ET+IcQ/tfU1zy7gkWjuzgkr9G9vNngtOUorBTM1XSslfXKOc9UsKjfH/Z5E52sWGJ4En5ISmSE=
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: 
To: 
CC: Victor Lira , Michal Orzel ,
	Stefano Stabellini 
Subject: [PATCH v1] automation: disable terminal echo in xilinx test scripts
Date: Tue, 17 Jun 2025 09:44:49 -0700
Message-ID: <20250617164449.3925765-1-victorm.lira@amd.com>
X-Mailer: git-send-email 2.47.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB04.amd.com: victorm.lira@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000EE3F:EE_|BN7PPF28614436A:EE_
X-MS-Office365-Filtering-Correlation-Id: e741fa61-40f3-4a44-82ee-08ddadbe53e3
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?ROE5mg/6ESEycPQ+G9y9G9hsTHXfGvyLk4naoisIa1yotCXzeSgeQhW0FJhR?=
 =?us-ascii?Q?BCdJGyh7kbgYdnVP2ufbqtEq9uOD2Z8o5lSR+dl0qGPUB8lumusw245cEjmW?=
 =?us-ascii?Q?fcvGivJeM8k1DOsKCtbeiFrw3H82vKR9fZ+qmdkhZW3JBCE0J9hka4GIwUqv?=
 =?us-ascii?Q?p5zyBOz733g2GBQsStnn5A7osNJbW/bvpe79h0Jgg1Q2bVQSJdXJCo3n3cPt?=
 =?us-ascii?Q?JsUJ7XUfOpicOlYlAK37072bbNQeZSElAD2Rc2tqJAx9xuwxmcLcCNwoV5vu?=
 =?us-ascii?Q?NGgr1L7Ozxty3LhnoSHhrs2hkqXkzszZwhNC89nQwD7yMbiPrQ2ON+23ZDBx?=
 =?us-ascii?Q?X1Zfsy5Hj17yFrnCyexzACQTRIQ6WOWTiAw+PW4VWzTvsMLKII8QZEV0DC3E?=
 =?us-ascii?Q?hacjLvFkupzorzq7cEZN8FJ8ZJjYu1/AcR2y4i7qKO7PqKG/pZjPr4+tJ9iJ?=
 =?us-ascii?Q?BB96Y2zDhgYJSgvq892C1qGYg+5ry9bUZQdFsN5aq9yxgUsZnZvt8ko4ewUq?=
 =?us-ascii?Q?muwT5PjwCAvaPPiOFx28Z6Rvp3BWyUId74iFq2onbInvUaeh95eFDHkRQ0jl?=
 =?us-ascii?Q?R/aZ2Foe5pI+gGdLjobZGxN9pQGVrp6nES2pawBaIoDx0kbUSlDRQvyBSKWo?=
 =?us-ascii?Q?d44lOzE9DxfCfq4UcYV540W3qXGAsLZuEz5U4fkDVzOiubWmdG6zSjj47rrX?=
 =?us-ascii?Q?k9X/PP5CsNk/2lQftSpDALhjLuS+FEcd4EXB3K7XEZdIj1eJJ9DMIHO8K0l+?=
 =?us-ascii?Q?d4C20crBy/y/omIInIlFo8SuzK8X26RgvzhFltpfOnFJkZXo5wWoZ1R/4gAz?=
 =?us-ascii?Q?YN1wqviNkHTvZexgpdfYhndkLmyccu8PFAczxn6CeCRPF8JgjVeXXZk62uPQ?=
 =?us-ascii?Q?Fh76boLBooGXbIory9BjvkLRuZIp3+60J3VoYBvu1IwL4VWybHDmKsldifw5?=
 =?us-ascii?Q?T3ITOJV7+ID3Z6vqQhUj6UzVHsTk2cK6xrcU/dH8DolsyAphnOxI8pZ8gmsX?=
 =?us-ascii?Q?e7eJDEs7VtT3DtXXQtUIHFQ3b61lW78MwOaBDF/Q9YqNvrs292SqZvjd3S48?=
 =?us-ascii?Q?Cj/k5wrICcdDNga1BZ14cGQg3CXRk+ra6k04sc1ts/bdK0PJbh4NKEBsYegn?=
 =?us-ascii?Q?UzHu9qgxk7o7nvbpaSDkGXZ5Po5DomwbMOpftw0sPIEjlT+jF0op5fhHgOz+?=
 =?us-ascii?Q?JSwnRQq4fH8AF+Z+smESLhN5djCiLxZVMGShoq7QyTKScEPiOJ2u1gwLXvqN?=
 =?us-ascii?Q?eAmt0ggPHdsKKldfC16wG/3NDp6AjNwd96Kv5sy0nv/h1Ch0+FWSSEe/HotF?=
 =?us-ascii?Q?6aXy53/ocXr7UlYM1RVP9imyEIhyEwVyv6OwNMUTGcaseFRL1ZpKgdU27bPJ?=
 =?us-ascii?Q?TUowXToquCLzNKK0rVmWBLxprccfIFgjXYvvwaSCM+LJKrsUrzhVzUhcJi9g?=
 =?us-ascii?Q?g5Mnh/B83H3V0vZFfIyHAzFQCRaaL0OY+4g4Et0rKWYpLjjZnKijqE/UgbVN?=
 =?us-ascii?Q?GNv9e0GDsk6mLbcQO7Griv1xNr4QAMIXXTqd?=
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: 17 Jun 2025 16:45:11.8415
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e741fa61-40f3-4a44-82ee-08ddadbe53e3
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:
	CY4PEPF0000EE3F.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PPF28614436A

From: Victor Lira 

The default terminal settings in Linux will enable echo which interferes with
these tests. Set the value in the script to avoid failure caused by a settings
reset.

Signed-off-by: Victor Lira 
---
Cc: Michal Orzel 
Cc: Stefano Stabellini 
---
 automation/scripts/xilinx-smoke-dom0-x86_64.sh    | 2 +-
 automation/scripts/xilinx-smoke-dom0less-arm64.sh | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/automation/scripts/xilinx-smoke-dom0-x86_64.sh b/automation/scripts/xilinx-smoke-dom0-x86_64.sh
index 71cdb295b2..6970a8658d 100755
--- a/automation/scripts/xilinx-smoke-dom0-x86_64.sh
+++ b/automation/scripts/xilinx-smoke-dom0-x86_64.sh
@@ -165,7 +165,7 @@ sleep 5
 sh /scratch/gitlab-runner/${TEST_BOARD}.sh 1
 sleep 5
 set +e
-stty -F ${SERIAL_DEV} 57600
+stty -F ${SERIAL_DEV} 57600 -echo

 # Capture test result and power off board before exiting.
 export PASSED="${PASS_MSG}"
diff --git a/automation/scripts/xilinx-smoke-dom0less-arm64.sh b/automation/scripts/xilinx-smoke-dom0less-arm64.sh
index 293232eebf..1d7162f1b3 100755
--- a/automation/scripts/xilinx-smoke-dom0less-arm64.sh
+++ b/automation/scripts/xilinx-smoke-dom0less-arm64.sh
@@ -128,7 +128,7 @@ cd $START
 # connect to serial
 SERIAL_DEV="/dev/serial/zynq"
 set +e
-stty -F ${SERIAL_DEV} 115200
+stty -F ${SERIAL_DEV} 115200 -echo

 # Capture test result and power off board before exiting.
 export PASSED="${passed}"
--
2.34.1


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 17:14:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 17:14:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018391.1395287 (Exim 4.92)
	(envelope-from )
	id 1uRZt4-00031g-CE; Tue, 17 Jun 2025 17:14:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018391.1395287; Tue, 17 Jun 2025 17:14: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 1uRZt4-00031Z-9a; Tue, 17 Jun 2025 17:14:18 +0000
Received: by outflank-mailman (input) for mailman id 1018391;
 Tue, 17 Jun 2025 17:14: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 1uRZt3-00031T-0b
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 17:14:17 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20619.outbound.protection.outlook.com
 [2a01:111:f403:2418::619])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7da9a652-4b9e-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 19:14:14 +0200 (CEST)
Received: from CH2PR14CA0029.namprd14.prod.outlook.com (2603:10b6:610:60::39)
 by IA1PR12MB8263.namprd12.prod.outlook.com (2603:10b6:208:3f8::9)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.28; Tue, 17 Jun
 2025 17:14:10 +0000
Received: from CH1PEPF0000AD80.namprd04.prod.outlook.com
 (2603:10b6:610:60:cafe::70) by CH2PR14CA0029.outlook.office365.com
 (2603:10b6:610:60::39) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.32 via Frontend Transport; Tue,
 17 Jun 2025 17:14:10 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH1PEPF0000AD80.mail.protection.outlook.com (10.167.244.90) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Tue, 17 Jun 2025 17:14:10 +0000
Received: from xcbagarciav01.xilinx.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, 17 Jun
 2025 12:14:08 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7da9a652-4b9e-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=dN8yqFz1kLAEq0P4HtMIhnEw1lhJAHOrkjMuOBBVqY1KZWb94xjV0CxROqDQnt9IYLLe34V9WafoqmIvO/WGybQqvimk9ctC9zpJpbQrAWloRwfnRFf/j6SwWZJz+TcONNhaIti7jmeC710q4pud57IYy//AqsMsDZh5donom/QfdWiGfOjmEQFekN12eTzYHNohmTXBpCWW5NkeXzcvRHLqzFf94KKENcrSl4Zvi9z88SvA/jT8JvNMG9KOeg2VgLwoTMPNUU0mnzwJVOVNawme3rYCr3+3t7unVqqVFDFH8xYI0rQAu2I4RhYcHo+1uEfCaHgkqjBfFGwySxpvdw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=626UhhwDAAKKE8InXLkNjul1IpTXB+/Xqq68g0GeaK8=;
 b=TT13PB01a5EOy61WcWpj6+g+6OZheIq2efVQSMu6YaIMWnPX/wGxZcUulIYJfHRSFn76agW4yA6aPapKoAIRFUa02fVfav2vSabibmXoULP1CvvwejTCIEwt1gJNR/CeHdO7KuSQt/VDdG7qOpeZEZbuXSA556KqogxVduf2/g7qAaVnAljdyiLH8O7RCaCs6/vpl8vGFkeL9DpUlXEtJTLgS6sMZO7N82IDd6ocRT2qI0foQpALbuR1eKa0kITFiCbA14j/GVUCU2ybDdmGtqKPoZSuZmDvgJTxglgikiI+Npw7Xkw5wDjuRXn1ezXNrSZIWoTykdTTt3GcYj0d0A==
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=626UhhwDAAKKE8InXLkNjul1IpTXB+/Xqq68g0GeaK8=;
 b=A/BGe533bBWi4h5bbM3UdFYz/09qG5xbzcZsPMwks6E90HJ/kePYGsjA7zOXgHfwsHxEnnV7LWQxPGr/idKYU9tiKRk4UQEoh6ZXB8qHQMdE6BiLTehTXraZagnU0ftDwhb3acZxmoPUL4zfukkDp3VPKjhMxy06nuhlQdDOan8=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel 
Subject: [PATCH v2] xen/dt: Remove loop in dt_read_number()
Date: Tue, 17 Jun 2025 19:13:57 +0200
Message-ID: <20250617171358.670642-1-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: 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: CH1PEPF0000AD80:EE_|IA1PR12MB8263:EE_
X-MS-Office365-Filtering-Correlation-Id: c4fefd52-b252-4fbc-343b-08ddadc25ffd
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:
	=?us-ascii?Q?PBWAIuQuBRMR/AHT7eJFLlqnH69tw2165z5b+05+JgHX2niYduUNIpDgXw6E?=
 =?us-ascii?Q?ZCTQUsM3j8DJjE91nRD+IqSS/CrHCK5yj+ygwEOUldDnU9hWsgEjkt5t2iee?=
 =?us-ascii?Q?45OoaCNGzMea2wbMk3GswIs4V9DQGsvT3HhpQHv43860zmv15FNafvO9e/wB?=
 =?us-ascii?Q?Qz/LAj0LNdZLMNI7x5D343hbKuuff9uB2058JJd2yTawglC2b3Vs5iuM1c3Z?=
 =?us-ascii?Q?vh1dMAux+pB2Bx2bbdbroJikYgSlAaBVj6JFeI/th+RinLwJ/l6dTwNPkfUF?=
 =?us-ascii?Q?dDAhrBGVYIPyNF1Au1l1eMWDXmKYZ2UXPLBEOiEGRoGLZSUA8ZEpe0K3vHIX?=
 =?us-ascii?Q?6kZdf+pNP9gbLmtW26IGxMJOkEkctv7bdFwK8p6ZtI3OvQbH6UsszqhtLxNb?=
 =?us-ascii?Q?kKcof4bByWFQfHgnW7KmUxOiaOyzM1S9Ty5AoXtxcljC4m+0WxlumnoHcxtY?=
 =?us-ascii?Q?7Q3X0gpvRoaIDaMrJZT3I+06MqjB1AmwFmpQqrpQIaxmZqLymPiZ98nw5v42?=
 =?us-ascii?Q?cDxeBhtUTXD2V5vs2kKmaXIlf0sojRaTEnNu8WCdLygQQjxYssINzhJGx75Y?=
 =?us-ascii?Q?0lgNvB6IfLkEHXkwV2SYD1lMAuM+F4fH9TA6SOivNHcmwVveOuQjys8gdJdf?=
 =?us-ascii?Q?lPIcltfWnMTKTL0zEDCnlEsUbE0PJUP18/Eg+KpkkFpLLDrNzgPFxoMrrOFG?=
 =?us-ascii?Q?nuOXUEC0hPK87kxETQ/CvTcXlRyPj1AU6ieZrunIt349kWTR1Vtyo9aSAYE3?=
 =?us-ascii?Q?4Z6tNuZrJ7Yk30H/+xF9pGcmkgVpAj8MckGy85+gkO04XdpbWWeCxw/JYKwG?=
 =?us-ascii?Q?9U02yYEAhXHfo+/5EGCwnUYjew4dNadR6uSOE+iMgGGVEcndk7wipwYT9ws6?=
 =?us-ascii?Q?k3SrFxo1EBhBRuNBU2ki5A8kFGd+wdupKxPPTp4Dng0XvUhCyrkk549TRMaQ?=
 =?us-ascii?Q?MGZv/ANfdAFnsagpxUOR1MiSosbUkJVuV3ZS8FKacgrNuRBG6d5E7lTIHJ0d?=
 =?us-ascii?Q?yTjp10DEbKvmqgsJoV6f/TsOEoUPeAJGVzqsljciPOjJctrXC3yB3uJFn18O?=
 =?us-ascii?Q?9siJkAIXCwZ1rlZXFpugLYLjmmWp3z/hBh54IXJMC2TjbbDIPJ/M+owWHL7/?=
 =?us-ascii?Q?XBoVds5jW3LqRyFlQP66fl4QmO62oEZ6o66F98rY2N1F4vzM95MrBt+EBvJY?=
 =?us-ascii?Q?YZtcwTnDGubBsB5iMB6rSbuI7dwnI0ZiRdvNJNKzWtMs+uzMyurcFW45ATOL?=
 =?us-ascii?Q?HoCdUNqcNiBzb6x5Jzm4blJPn90+soratNYw90sXfkdPHXck8btHOhPbmDAC?=
 =?us-ascii?Q?DheUemznZGS/mwr6ZhDUyRzXtw+HBDKnbW7/V8fsalTil7OzAkClw6jb2g4m?=
 =?us-ascii?Q?jBCY0R6hUKx71EuO/xuZxPNAwSUXwdNZUIiXWCmebXK+XWQaLboDAL3sovie?=
 =?us-ascii?Q?gilRaLZcN0HFujMGPDH3QwJwjA+WPl7l7HFRfj53UTPUtSH1sZXKIvWWAcSV?=
 =?us-ascii?Q?0WXRQScwPN8ZGuuLwbsQbv8AKC1duEuYqrea?=
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: 17 Jun 2025 17:14:10.1635
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c4fefd52-b252-4fbc-343b-08ddadc25ffd
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:
	CH1PEPF0000AD80.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB8263

The DT spec declares only two number types for a property: u32 and u64,
as per Table 2.3 in Section 2.2.4. Remove unbounded loop and replace
with a switch statement. Default to a size of 1 cell in the nonsensical
size case, with a warning printed on the Xen console.

Suggested-by: Daniel P. Smith" 
Signed-off-by: Alejandro Vallejo 
---
v2:
  * Added missing `break` on the `case 2:` branch and added ASSERT_UNREACHABLE() to the deafult path
---
 xen/include/xen/device_tree.h | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 75017e4266..2ec668b94a 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -261,10 +261,21 @@ void intc_dt_preinit(void);
 /* Helper to read a big number; size is in cells (not bytes) */
 static inline u64 dt_read_number(const __be32 *cell, int size)
 {
-    u64 r = 0;
+    u64 r = be32_to_cpu(*cell);
+
+    switch ( size )
+    {
+    case 1:
+        break;
+    case 2:
+        r = (r << 32) | be32_to_cpu(cell[1]);
+        break;
+    default:
+        // Nonsensical size. default to 1.
+        printk(XENLOG_WARNING "dt_read_number(%d) bad size\n", size);
+        ASSERT_UNREACHABLE();
+    };
 
-    while ( size-- )
-        r = (r << 32) | be32_to_cpu(*(cell++));
     return r;
 }
 

base-commit: 14c57887f36937c1deb9eeca852c3a7595d2d0b8
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 17 17:54:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 17:54:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018403.1395297 (Exim 4.92)
	(envelope-from )
	id 1uRaVu-0007zn-2L; Tue, 17 Jun 2025 17:54:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018403.1395297; Tue, 17 Jun 2025 17:54: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 1uRaVt-0007zg-Vf; Tue, 17 Jun 2025 17:54:25 +0000
Received: by outflank-mailman (input) for mailman id 1018403;
 Tue, 17 Jun 2025 17:54: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 1uRaVt-0007za-6Z
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 17:54:25 +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 1841b3bf-4ba4-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 19:54:22 +0200 (CEST)
Received: from MW4PR04CA0057.namprd04.prod.outlook.com (2603:10b6:303:6a::32)
 by SJ2PR12MB7867.namprd12.prod.outlook.com (2603:10b6:a03:4cd::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Tue, 17 Jun
 2025 17:54:17 +0000
Received: from SJ1PEPF0000231F.namprd03.prod.outlook.com
 (2603:10b6:303:6a:cafe::e1) by MW4PR04CA0057.outlook.office365.com
 (2603:10b6:303:6a::32) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.25 via Frontend Transport; Tue,
 17 Jun 2025 17:54:17 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ1PEPF0000231F.mail.protection.outlook.com (10.167.242.235) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Tue, 17 Jun 2025 17:54:15 +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, 17 Jun
 2025 12:54:14 -0500
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, 17 Jun
 2025 12:54:14 -0500
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, 17 Jun 2025 12:54:13 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1841b3bf-4ba4-11f0-a309-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=JCcpXkDdfrjOl4dCUkINYe+EtcUDoE+42/khsPDX4CDfaXQtuNo3cwGYMhbzReTF5SSpjPR4fKnbw/Oaf5n9kTGJrNfCr4toEINiNbAQ/BsNNKqCj+7f2H15l474/7rb8hIjlDO5FfdflI6AQQrvDlxKkREsg/KhJV4VhUi+oCWQW0reTVU5tL/rRpj3o33gIXi49jzhqbYpEWyEZrGkDpLnM8U2UxsZ1nWHb2z75mKUsOam8rNAU2PhblmbQJPB76OwwRx8jpKqdoASeyOoXad4+nriAkwfzCbOVx/6N15FhOtuJOmgsSxHHKufEZRhzYq83k/Z7omh0B40PxKydg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=cbf8WffqeqpYzH93KaXhGWMu3rJ0HjAVyQhb8//6aww=;
 b=Lkc/KLIO4u2XtnfUYMqubgG41m5KJ7VdFRv7ulIKbTedlj6hGYkqF95ogAIw/phMvZuLw45tMK68g/Tt5UgN1FNXux4O9Djk/zoVAYn5KWRf+jIdWxBvic+d0Rs4lWnR14oUTKQGRaVJqoqrpdxiqGa8HGWD2ChwJGEtkcNDItECUTgeCj+DhXXWMw8JEa+eNr7bk3yRuan6lZS3fxkZhS/xiggWzMBz8mKY8oTD8IAfaTB2wU9CUPRkMaAor6yvO/a0Im3medrsKkO5dmXMnxpARI9eYKG30Rz7+2mUddL2xS8VFc08ENxuxvmUDqR2kHpunkGiCJEQ06PC0Jk7qw==
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=cbf8WffqeqpYzH93KaXhGWMu3rJ0HjAVyQhb8//6aww=;
 b=5l9gfwSLjq4YbZYl0xwxPi/8BSgssj4XbAeqrSR0asdZJojEr3/91eB4Rlz6A3IE8UQJUvYmofBoiHRAMB/dFwruYo7m/24xXH4tqT7+5SvZW8oJwo3JH7E6PT/bsYi00v7ehFIaCDxVaj69iK6VqPF38+6v/nIIZ2vnhmvTh1I=
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: Stewart Hildebrand 
To: 
CC: Stewart Hildebrand , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , Anthony PERARD
	, Juergen Gross 
Subject: [PATCH v6 0/2] arm: extended regions fixes
Date: Tue, 17 Jun 2025 13:54:03 -0400
Message-ID: <20250617175411.398083-1-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF0000231F:EE_|SJ2PR12MB7867:EE_
X-MS-Office365-Filtering-Correlation-Id: bed19be2-cd01-41a3-1b3f-08ddadc7f9a8
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?sp+qlJ5mM1CzrPJFE4kvZJQvWdp8EbwcSbMUs55+ID35gXkdMRWlvN1c8JxM?=
 =?us-ascii?Q?Wy1T2JFB+kbnCzkIH4MldUQDiZcGdQ8QdSnAh9D4hH4ekmkf5Upjlzq0CRKM?=
 =?us-ascii?Q?EilbY5Qn/7EiAHAT6nck2UKzU3ADCWosz9t87iGkHDxGf3P+uk6fPP1SMb25?=
 =?us-ascii?Q?EtgN+iKYtu21TrIcjhnTXa96srevlueLaAtiTGdUBJb0Knde6tiQXioHB5jq?=
 =?us-ascii?Q?rjd5fv7b8b0tIaN6AHJRf+ev+KpDFwV2JlmMRZI5vWihT3bQO1+Jc4zBsZB8?=
 =?us-ascii?Q?jzVjMM6wxstqb4jIEK46INNs8z11nG6fqlNhuo4FRgGPqqcEtBvgM3oI+V55?=
 =?us-ascii?Q?vIU0nyaZRfUbZhZKuQeZryFugEqCXvnIwmUezpuKzzz6R9i0CvqIltyHA4a2?=
 =?us-ascii?Q?tcUTnphUcedcM/XPdj1f/mys3yp7fjOlmD4b72Uw242EJkVV7TSapHyRmL9C?=
 =?us-ascii?Q?P2S5qT/UBow+oNzqrYIOejO/4enMdMsOfI77UgU7wNednYbbExvtLLQhy52r?=
 =?us-ascii?Q?DAI9PhFmcc33zPX0Azrp3TtxEQmlWDzDT0kM6ESRLtag1vzoZepz6GgpysgW?=
 =?us-ascii?Q?0qvFDP6ztdci2q6C3C+w/JzkUANwDr2yLGQv20ByknrrpxSKAbKTNbXLNNRC?=
 =?us-ascii?Q?32+D2jMxuB3mTTMIzZGb/XHM28qIQ0OBbJAaCSW+IuinR8Zfx90+3KTORjgC?=
 =?us-ascii?Q?danHB50L7lyoUZ05yeG3GPP1wvb59HMqQMIkR3es9X+i/EaObYrW6+f6e2lb?=
 =?us-ascii?Q?G2hBei/pjtEX/1ho2Ol3Gxr+6uMVncYB4B1FPdIWMEATN12CDz/ioVygPnDu?=
 =?us-ascii?Q?37yJpP4fFa7jeepMlFb5jtYfy5GGQ/O+o0ywRzCDxhhPL50AIcgMT8GfOwoz?=
 =?us-ascii?Q?lXhp8QdD7ObcPK6fRAs9iaHsNr36433S/S/4V52XRZFDMxxc1hYyaYUuv11N?=
 =?us-ascii?Q?4srMbpQbM802Jd9a8b41BwCWoaRezn5K0+ELspAOczo3KbV/qlhR7ci+zhY4?=
 =?us-ascii?Q?m7XpT/IOvmeYyvWH07nltWPe5dF0ykaohOdl2pdUfN5oJEhvrpKkyfKLOlE5?=
 =?us-ascii?Q?ZV5vv83iQqCAjkAUZdGXdFmtr62njx/ny+lE6bwSLDiKO9I1mrZsmWP2TGJ5?=
 =?us-ascii?Q?5Sba1sSZG11EcQPsRsI8e/PO84Q9YuJiFvSWw0ZOphqLH+OW7vB7YpmSLNA/?=
 =?us-ascii?Q?UJFA1jZauXa3LCCU6LM+3wy9K3FpXqfcQFp/GknNFZP8i2RS01iJuQvTpETy?=
 =?us-ascii?Q?X8YDyc+mlhEnPkNvc83bBsTpMABvAP3zqhU1ZaG0+r6GTT9lkIICihNYvUIS?=
 =?us-ascii?Q?rfL1cpJFXbtL1aDMEov4zfp1rA/ZaZAFZ3hdRFrg3qZkhBpXMA+sfAT3Fnnk?=
 =?us-ascii?Q?aezeY3uwKJbUqaJSRNQqO29979G4SxvcPv8tnZb4WMLre8Pss+1IzyjgR/zj?=
 =?us-ascii?Q?T5BL0u/Vt0Gokp9jyPBuSXS8HB8n0nixbVyyq3oysRWDY06/dWni5mlwHix3?=
 =?us-ascii?Q?LAsUQye6kUtqV70hppReK+HHlMVIG2utvV4G?=
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: 17 Jun 2025 17:54:15.3769
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: bed19be2-cd01-41a3-1b3f-08ddadc7f9a8
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:
	SJ1PEPF0000231F.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB7867

v5->v6:
* minor updates - see individual patches

v4->v5:
* see individual patches

v3->v4:
* see individual patches

v2->v3:
* drop committed patches
* add ("xen/arm: exclude xen,reg from direct-map domU extended regions")

v1->v2:
* rebase
* address feedback

Stewart Hildebrand (2):
  xen/arm: exclude xen,reg from direct-map domU extended regions
  tools/arm: exclude iomem from domU extended regions

 tools/libs/light/libxl_arm.c          | 110 +++++++++++++++++++++-----
 xen/arch/arm/domain_build.c           |  80 +++++++++++++++++--
 xen/common/device-tree/domain-build.c |   5 ++
 3 files changed, 171 insertions(+), 24 deletions(-)


base-commit: 14c57887f36937c1deb9eeca852c3a7595d2d0b8
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 17 17:54:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 17:54:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018404.1395308 (Exim 4.92)
	(envelope-from )
	id 1uRaWA-0008IE-BB; Tue, 17 Jun 2025 17:54:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018404.1395308; Tue, 17 Jun 2025 17:54:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRaWA-0008I7-6O; Tue, 17 Jun 2025 17:54:42 +0000
Received: by outflank-mailman (input) for mailman id 1018404;
 Tue, 17 Jun 2025 17:54:41 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uRaW9-0008Hi-0K
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 17:54:41 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20617.outbound.protection.outlook.com
 [2a01:111:f403:200a::617])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1cf72c56-4ba4-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 19:54:30 +0200 (CEST)
Received: from MW2PR2101CA0030.namprd21.prod.outlook.com (2603:10b6:302:1::43)
 by DS5PPF4ACC15C0E.namprd12.prod.outlook.com (2603:10b6:f:fc00::64c)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.30; Tue, 17 Jun
 2025 17:54:24 +0000
Received: from SJ1PEPF00002319.namprd03.prod.outlook.com
 (2603:10b6:302:1:cafe::f8) by MW2PR2101CA0030.outlook.office365.com
 (2603:10b6:302:1::43) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8880.4 via Frontend Transport; Tue,
 17 Jun 2025 17:54:23 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ1PEPF00002319.mail.protection.outlook.com (10.167.242.229) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8835.15 via Frontend Transport; Tue, 17 Jun 2025 17:54:22 +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, 17 Jun
 2025 12:54:21 -0500
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, 17 Jun 2025 12:54:20 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1cf72c56-4ba4-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lmiBZkTK2Ey9+NOXdUOK+Yb4tekdt22SHhu8QCCCGAjvoZti5YbhuQKfvwbkHXhNpHYVdGvosRcZh9zepifveKIhaktIQNzdyU4XHANCyak99/C9UEuQSFtLtCGasCrulwGRAlGiyp32fyOqZPhsRRqyc4vdB0D+RNwbAsunQlgfcz+iZOMrZpYcEpZkkWNWgOiOqx0CKcaOyWyhDQPa0JrGl26KI7mntJwgR9+qcPg3E6PhgX90zZbyXYKA/ldpw0ft7037ZvoryEMORia+QH1rh54p+GfWNh+BSIrzAv8jcRcaDMTqDmmB1iUukgqzehg4bmFfBGs6ctqa+pzGgg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=LTmpaxR8fmnRkqMk+mbPZ48PkiFD8VMw7o1OmZesvR8=;
 b=lxBM4QrSrXXN1PgkGEhwUF/h/i05FHegauD/i2M5YJ4oFbzgaz8wdkjZd10TwiE/IR/ZBwYxByWjjpDt1dTE4rCHj+89viw4kB5oUY8Q1Xrxy+GJ0wSMSGVhE6Kkp/8APYuwIQO+69cYrT8UGja2Pf8U9AxIgdhIdz6MOmi49uhgu/51hqSNFimnPMnshgUucRq4NMNthfpCxgSIU15gCC8+xCig7oD9SZlqXyiRGQIpG1H0YIhibcBla9sO9v1IwAZqrkTLu09bXvzN/YMRSw2Du8JF0thofrC+UXhSHlb4PW+0K2+bL9I0Ud2p3oYBXljizBURwCz0mzhT46z7hQ==
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=LTmpaxR8fmnRkqMk+mbPZ48PkiFD8VMw7o1OmZesvR8=;
 b=VSs4Qzg8q+v/7m5mowpIaI+yVJJV8UayDYF+1tr8CzNyV2Y3afBM7x2/ESk4Qqu2X1MfdHgZ3PoiDs8+198U93f3EvhVCBpQPp9DuKl2kHKujVq/Tn26cEiqeX0KJHn11LiP/FzN0w/Wp2pbSc/nYF/rM2cLhmX+cAPI9LA7b9M=
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: Stewart Hildebrand 
To: 
CC: Stewart Hildebrand , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" 
Subject: [PATCH v6 1/2] xen/arm: exclude xen,reg from direct-map domU extended regions
Date: Tue, 17 Jun 2025 13:54:04 -0400
Message-ID: <20250617175411.398083-2-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250617175411.398083-1-stewart.hildebrand@amd.com>
References: <20250617175411.398083-1-stewart.hildebrand@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB04.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF00002319:EE_|DS5PPF4ACC15C0E:EE_
X-MS-Office365-Filtering-Correlation-Id: 14ecaf2a-aa8e-4071-561f-08ddadc7fdcb
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?/Z9O229qL4uFLZe/ZbYALPLvZyDaEDfRGqvly/5B+nX/zgmuqAFtNPjEr4J9?=
 =?us-ascii?Q?wQiAt3AuiWopgwuBda+rgi8VmNJuFAvBsOTCrfNX+dmRmUCCIehe+xTas7P6?=
 =?us-ascii?Q?mioHbfOy3wQibZ/VDqDhPZfRmE5UFYOwChB5S+tkA8Gd4ADdqp/xavj+Hl7Y?=
 =?us-ascii?Q?HeIgzRgSiJmNZ2NvOj75OD3Xt9LzL8mvNc3HomREa42I+JOZIVkjpv+neXGl?=
 =?us-ascii?Q?sjZyudkg9rAk89gdgqLvNj8nkQ+/zPkEimF+E1ivmiCLCdQNLZuunN6vR5KW?=
 =?us-ascii?Q?xfVbkRqVFDHwsHVNS6UIZRJ0QGwqFCOe/Do5YL8t3Spid9r3CwZo55uAdf8x?=
 =?us-ascii?Q?zxOUFmqDSUVFINUr8I8FzifxsTlLVIq8Gdds/sPFQm3GIEAn+h6ZyJgjOweu?=
 =?us-ascii?Q?+uA3E82rk7HPzt+RjuslGjk9ePeJOlEDpvCR8tXsTqhfNvBybdMdY7Vh9hDG?=
 =?us-ascii?Q?X37eF1FJOih9fCLvwlR1BBO0sjmnG+Jm3pbv5cRH515mOgnoW4hwvt1ZDKkx?=
 =?us-ascii?Q?AA7nmo4NaGsxR6oqlyGltD8hzF4sqiw16vZKhrvVCdEJg+wlum4/0BB7ljq4?=
 =?us-ascii?Q?ky3GNVqvVGUl+h5w5JAMP6V7P3Kw6Y4rdfTW2EQvGVsfwJgG9pZzrkVNLj9i?=
 =?us-ascii?Q?kvlPPHt3BAcWLQ4OMLBMNB0JV3mE51OAqNKIbTbFaFV66IM8g0dxcwPESQQH?=
 =?us-ascii?Q?/lft+KEP96QH/w8RPb2RsXvLVR2lFMB2F+lnS37dyk/z7mrD2ZA4HPZ5N1g5?=
 =?us-ascii?Q?8+Db/wbeKfNtRpsFPjKKF0ArOc2Y1zNHRfMylh9bsreLokNRhe7XwxKY2X4i?=
 =?us-ascii?Q?wxiJn2WRR+naIPOYmyf0dC+pFT0hES6CtEuLp7f62F54kLzM8oGm5iD53EsT?=
 =?us-ascii?Q?7nDsh3hGYACmPmcl/bmzZobRJL1VX/efMsOAFgfA5NwysBAptX7OmdA6Xn3N?=
 =?us-ascii?Q?1Vg2SnRBmvnFIiQ5Dyb8xoiZFaiv85VNHDIruZ0UaWS1oOBCIA7yog0bXdiS?=
 =?us-ascii?Q?A9GdGSiNFv4d/9NIsW49+WYx4fSFTV4BXfiyKWs/fxOONNRceDysXKsWSdTm?=
 =?us-ascii?Q?vm9zVTOIsh550DgBK5E4de/jY7nK2+eg+STvrelN1GL74Xcv2lfVFqzjSL1h?=
 =?us-ascii?Q?IxuPu4TOfqZMplKCwL4biBSI7QoIjpOCW4Ky4Aj01H0aw1csir4ttwNvKTH8?=
 =?us-ascii?Q?ikr3/JLTfIVElNhIKxuWi7O+FcqWrIjx/4BqDBE4h4i6CjKSAXOS16pmuAk9?=
 =?us-ascii?Q?f8fLus/c1xGRR967PNC5hanTX8J2LNxaHbglfZHfXqEEMRFzX0iaLZsBRWR5?=
 =?us-ascii?Q?SEFvFXxhr3+KaEqHT8RY9YLvVVu5OewZLQsmjvNMqHAL9mJyhYGGCbNMRKBO?=
 =?us-ascii?Q?o0ZjyNj1Ufw3+DC0qmkBxOm25CfnT2SCjj9YxpWsr8L5qOuYlthj/VXr++bp?=
 =?us-ascii?Q?ok8u2MlARRqs7ts6s8zDBCNjsBVVQb2bYmA7gN9WNyKllLRS2boAY4VRX23v?=
 =?us-ascii?Q?YPdWcFToEErY44BDN91P9IxygpZKs4ZbhQeQ?=
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: 17 Jun 2025 17:54:22.3150
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 14ecaf2a-aa8e-4071-561f-08ddadc7fdcb
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:
	SJ1PEPF00002319.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS5PPF4ACC15C0E

Similarly to fba1b0974dd8, when a device is passed through to a
direct-map dom0less domU, the xen,reg ranges may overlap with the
extended regions. Remove xen,reg from direct-map domU extended regions.

Take the opportunity to update the comment ahead of find_memory_holes().

Signed-off-by: Stewart Hildebrand 
Reviewed-by: Michal Orzel 
---
v5->v6:
* s/Dom0/hwdom/ in comment
* add _gfn suffix to args in count()
* add (void) to indicate ignored return value of rangeset_report_ranges
* add Michal's R-b

v4->v5:
* remove extranous -1 and +1
* create local helper function to count ranges

v3->v4:
* conditionally allocate xen_reg
* use rangeset_report_ranges()
* make find_unallocated_memory() cope with NULL entry

v2->v3:
* new patch
---
 xen/arch/arm/domain_build.c           | 80 +++++++++++++++++++++++++--
 xen/common/device-tree/domain-build.c |  5 ++
 2 files changed, 80 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 590f38e52053..077c4a2494f4 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -792,15 +792,17 @@ static int __init handle_pci_range(const struct dt_device_node *dev,
 }
 
 /*
- * Find the holes in the Host DT which can be exposed to Dom0 as extended
- * regions for the special memory mappings. In order to calculate regions
- * we exclude every addressable memory region described by "reg" and "ranges"
- * properties from the maximum possible addressable physical memory range:
+ * Find the holes in the Host DT which can be exposed to hwdom or a direct-map
+ * domU as extended regions for the special memory mappings. In order to
+ * calculate regions we exclude every addressable memory region described by
+ * "reg" and "ranges" properties from the maximum possible addressable physical
+ * memory range:
  * - MMIO
  * - Host RAM
  * - PCI aperture
  * - Static shared memory regions, which are described by special property
  *   "xen,shared-mem"
+ * - xen,reg mappings
  */
 static int __init find_memory_holes(const struct kernel_info *kinfo,
                                     struct membanks *ext_regions)
@@ -882,6 +884,13 @@ static int __init find_memory_holes(const struct kernel_info *kinfo,
         }
     }
 
+    if ( kinfo->xen_reg_assigned )
+    {
+        res = rangeset_subtract(mem_holes, kinfo->xen_reg_assigned);
+        if ( res )
+            goto out;
+    }
+
     start = 0;
     end = (1ULL << p2m_ipa_bits) - 1;
     res = rangeset_report_ranges(mem_holes, PFN_DOWN(start), PFN_DOWN(end),
@@ -962,11 +971,51 @@ static int __init find_domU_holes(const struct kernel_info *kinfo,
     return res;
 }
 
+static int __init count(unsigned long s_gfn, unsigned long e_gfn, void *data)
+{
+    unsigned int *cnt = data;
+
+    (*cnt)++;
+
+    return 0;
+}
+
+static unsigned int __init count_ranges(struct rangeset *r)
+{
+    unsigned int cnt = 0;
+
+    (void) rangeset_report_ranges(r, 0, PFN_DOWN((1ULL << p2m_ipa_bits) - 1),
+                                  count, &cnt);
+
+    return cnt;
+}
+
+static int __init rangeset_to_membank(unsigned long s_gfn, unsigned long e_gfn,
+                                      void *data)
+{
+    struct membanks *membank = data;
+    paddr_t s = pfn_to_paddr(s_gfn);
+    paddr_t e = pfn_to_paddr(e_gfn + 1);
+
+    if ( membank->nr_banks >= membank->max_banks )
+        return 0;
+
+    membank->bank[membank->nr_banks].start = s;
+    membank->bank[membank->nr_banks].size = e - s;
+    membank->nr_banks++;
+
+    return 0;
+}
+
 static int __init find_host_extended_regions(const struct kernel_info *kinfo,
                                              struct membanks *ext_regions)
 {
     int res;
     struct membanks *gnttab = membanks_xzalloc(1, MEMORY);
+    struct membanks *xen_reg =
+        kinfo->xen_reg_assigned
+        ? membanks_xzalloc(count_ranges(kinfo->xen_reg_assigned), MEMORY)
+        : NULL;
 
     /*
      * Exclude the following regions:
@@ -974,6 +1023,7 @@ static int __init find_host_extended_regions(const struct kernel_info *kinfo,
      * 2) Remove reserved memory
      * 3) Grant table assigned to domain
      * 4) Remove static shared memory (when the feature is enabled)
+     * 5) Remove xen,reg
      */
     const struct membanks *mem_banks[] = {
         kernel_info_get_mem_const(kinfo),
@@ -982,12 +1032,29 @@ static int __init find_host_extended_regions(const struct kernel_info *kinfo,
 #ifdef CONFIG_STATIC_SHM
         bootinfo_get_shmem(),
 #endif
+        xen_reg,
     };
 
     dt_dprintk("Find unallocated memory for extended regions\n");
 
     if ( !gnttab )
-        return -ENOMEM;
+    {
+        res = -ENOMEM;
+        goto out;
+    }
+
+    if ( kinfo->xen_reg_assigned )
+    {
+        if ( !xen_reg )
+        {
+            res = -ENOMEM;
+            goto out;
+        }
+
+        rangeset_report_ranges(kinfo->xen_reg_assigned, 0,
+                               PFN_DOWN((1ULL << p2m_ipa_bits) - 1),
+                               rangeset_to_membank, xen_reg);
+    }
 
     gnttab->nr_banks = 1;
     gnttab->bank[0].start = kinfo->gnttab_start;
@@ -995,6 +1062,9 @@ static int __init find_host_extended_regions(const struct kernel_info *kinfo,
 
     res = find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_banks),
                                   ext_regions, add_ext_regions);
+
+ out:
+    xfree(xen_reg);
     xfree(gnttab);
 
     return res;
diff --git a/xen/common/device-tree/domain-build.c b/xen/common/device-tree/domain-build.c
index 6b8b8d7cacb6..99ea81198a76 100644
--- a/xen/common/device-tree/domain-build.c
+++ b/xen/common/device-tree/domain-build.c
@@ -193,6 +193,10 @@ int __init find_unallocated_memory(const struct kernel_info *kinfo,
 
     /* Remove all regions listed in mem_banks */
     for ( i = 0; i < nr_mem_banks; i++ )
+    {
+        if ( !mem_banks[i] )
+            continue;
+
         for ( j = 0; j < mem_banks[i]->nr_banks; j++ )
         {
             start = mem_banks[i]->bank[j].start;
@@ -212,6 +216,7 @@ int __init find_unallocated_memory(const struct kernel_info *kinfo,
                 goto out;
             }
         }
+    }
 
     start = 0;
     end = (1ULL << p2m_ipa_bits) - 1;
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 17 17:54:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 17:54:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018405.1395317 (Exim 4.92)
	(envelope-from )
	id 1uRaWD-0000At-Nh; Tue, 17 Jun 2025 17:54:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018405.1395317; Tue, 17 Jun 2025 17: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 1uRaWD-0000Am-Kt; Tue, 17 Jun 2025 17:54:45 +0000
Received: by outflank-mailman (input) for mailman id 1018405;
 Tue, 17 Jun 2025 17:54:44 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uRaWC-0008Hi-0I
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 17:54:44 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20619.outbound.protection.outlook.com
 [2a01:111:f403:2009::619])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 248ee751-4ba4-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 19:54:42 +0200 (CEST)
Received: from CPYP284CA0050.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:81::19)
 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.8835.29; Tue, 17 Jun
 2025 17:54:34 +0000
Received: from MWH0EPF000971E8.namprd02.prod.outlook.com
 (2603:10d6:103:81:cafe::3f) by CPYP284CA0050.outlook.office365.com
 (2603:10d6:103:81::19) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.22 via Frontend Transport; Tue,
 17 Jun 2025 17:54:33 +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.8835.15 via Frontend Transport; Tue, 17 Jun 2025 17:54:32 +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 Jun
 2025 12:54:28 -0500
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, 17 Jun 2025 12:54:28 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 248ee751-4ba4-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Opp+ksGDZ0ymJfPvw+IEsjgcA58OFjlU7sYZ9kn6xoeK+RdYGtmrc3OEUMa5aj8W84drfBXgyXxsYjUwZHKIle1mc3Gnkh1ISJEV/4cBGucELcUk5memrHTiLBeZuCNWKBmnGnG3JR+TFfh//WJmxdb4VOY2SU7unNAnPjAvWfdvE8RzdV1q5iRHfdjh8kvNKZPkYhpTpiIwrzQWErxBbqNQZjfKWsgLbDizBugEk2WvSPYfXkJNhTH02T8fRXKStpGxCj1ApxHVbMtLhizAWnL+GzIDhgavKpYwqEhZy5gqcD37iPpcEXI6FBktEASvVZXt1sQWTmgeOAAsVq879g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=g1HnX/uD/d1EMBFjvqziyhkrvmBbMyjU+rbRy1CyT3Y=;
 b=w2+67dUej3RA9l7cRNRLu2nPsy6i+GgBvmG3NwNpPJgvVF9GJ10x9YfjfJVjSnaXT3fOv2/hUx4vr3msa/ihaTxM/vFx2BsSZFz22KXSWLUORZgV2xQfgFxJA2qsoilDbdCozRtVG48Wf5CUGeFD44UKbMwe/BdKcDgYlhXob1LK2tHPoHE1VxXcj8v5LjSV9wvpfE4DH7wgr1lJxu1ymCQDkCAvLfMMGhPXWKIb46jdKLzHPPXQ+MdnuxoNMwoXCuykcoLVERhDM4OxJS+8BE/cu0XPbM5Ukvxhx6OWCNV+Kc2DLNacu/I37nSVDg8wxsqIST/ALyuXBcYF/naEPw==
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=g1HnX/uD/d1EMBFjvqziyhkrvmBbMyjU+rbRy1CyT3Y=;
 b=BemZXtuaeojg3XxUaQEoATuz61r20TA7t34XS5SxyiDmbPA9QYtQdfIZFFm22pRQ3d3ZM2I062jmwzw0keqphxZh+7HJMyqrkMLzVlhZZ3a/U51Bo0WDHEBocYeo4tadsz3KukSvCNm8efVB4TfcumxEbvt1qSfSS+Mzup4tE8A=
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 , Anthony PERARD
	, Juergen Gross , "Stefano
 Stabellini" 
Subject: [PATCH v6 2/2] tools/arm: exclude iomem from domU extended regions
Date: Tue, 17 Jun 2025 13:54:05 -0400
Message-ID: <20250617175411.398083-3-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250617175411.398083-1-stewart.hildebrand@amd.com>
References: <20250617175411.398083-1-stewart.hildebrand@amd.com>
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: MWH0EPF000971E8:EE_|CY5PR12MB6647:EE_
X-MS-Office365-Filtering-Correlation-Id: 40d6ed04-72fd-4650-7b38-08ddadc80405
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?Lhh95Ih7KwYKBBlGcynvTsy14xdprS4xcUIWhRoFjpGB7+KnibEBwtRLwayC?=
 =?us-ascii?Q?XjIuzvGhOnTUXYJakddsfXT07JfNkyOsK2q/Xo80Hr+/Rs9AMBSNJJx62rP5?=
 =?us-ascii?Q?slzpSPRIVEMsLKDL9nAd1XQ+n66Ua3cIXxVIXluz9J529zGXgeS7+bJmpR3o?=
 =?us-ascii?Q?z0T0bcAZUucd6MSZbRAnODnlxT7fzh6YHYDKRnNWl8YD/nTnjAoc+nFA8M7U?=
 =?us-ascii?Q?XDUdXpImJUzGOuj0DDvGJjt4hPI3DXisakcajKJYn5eVA7za33sCExTa6Wzt?=
 =?us-ascii?Q?k/RUe4d+LuC8dT/gbqdnFlWTU/I5gh39w1NNON1Lftig2vLS7Nqsp0AKZI7v?=
 =?us-ascii?Q?WfIDi+M9E5bL+xABYhI5fEsFY1zJ3NpX5lT5AyLu6o2KLhjyAmV06+q63k71?=
 =?us-ascii?Q?lN4USJHPDEYwN56cy6yfj2pq8aN6xNtBpC0wGBspvVpzeCjpiHCjxBegMZKY?=
 =?us-ascii?Q?Hawaew4b1KnKP2xJN9jRfM3DJXYySKgpmcrqH1WNEhrfgO/XZLrRnAk6pGR7?=
 =?us-ascii?Q?xIsZqvLO4JfrhomYyQkYCYGx3iOqE15QzIQ8nfP4ZL6kXcniX9Bu10CihPFT?=
 =?us-ascii?Q?OKtWl5m3ZsWezZY6Pzqg11IfTs+FX24c4wNkcP5fF8KaVF4jMaFp6I4k3iiT?=
 =?us-ascii?Q?6Z+hx2gXZ1SfcDI/0Rc8HLGy7QwKN/gFZ6YjlnSFEt3xIbP6mSS32R0059di?=
 =?us-ascii?Q?uIXA0GGxOXqeXzobyo7tR6vTRaIPV2B71dhDKFlvqpxoTeOD4je3CjlJy5lz?=
 =?us-ascii?Q?VUyXLyXdLJrF/rUIXI+1T78wrwFjBLJApIpWkPUJqHbrO458mx00vNnkt9+Z?=
 =?us-ascii?Q?KNjsY4yycRBXI1APZl8kSfcqzSU2RL1whksyyFSNgQix+U1nFA9uRe6aaQ+g?=
 =?us-ascii?Q?uL6gP+ywqSxNlq4Oz3EC02kU1h0hq8/5eLwnWhnZcABbGO9gqqZJjxmlv5Lr?=
 =?us-ascii?Q?qYwaSU5nlUJMMSAL4kLrOiJ5bms2eI3Us93PLSdD89PBzbkFEm1VC1jfAiOb?=
 =?us-ascii?Q?HFrLJ2+dKaSz/hIzrsEmsL5KO4GyE3dWAdeBGWmrvrCzL6f7lyHf2WyrMZu4?=
 =?us-ascii?Q?MSkqEZJzj11WNGHqPdjt7xyHvlOJSML7OK95zEj1Xhdw8+fRKBYBFgpoi9+G?=
 =?us-ascii?Q?a21b4BM5YzJxQENE6W2so1BfcZKRREHDdXj3jfjTiC9uCseWElBTgdJGqRV8?=
 =?us-ascii?Q?XbtDkWhF6QKtyDgYe/eOTe71oxHJLmStGghyy5QtLZOQ/sr3jG7eHn0z98nM?=
 =?us-ascii?Q?uCJ0cCSbmrMTn2yXGJu0v62Yux5sVjOVGQ1n2F7R0Ec/URPcYemp4F8+g6V6?=
 =?us-ascii?Q?bJsksJgRPI5mcs3FO2RSjnAvsGuH/BUupx0W3tA0xl/tia3fRC1jmNTflbFT?=
 =?us-ascii?Q?urxbG4kOelv99Pail0pX3oHIQ7ciGNzkDtsk8P6TqdIXQPI/tKLVXAOudJB7?=
 =?us-ascii?Q?wCMrGNcm+1zbiX+hQJc0Tb7U9GxzBiYtBks09Tej7V2zL73/5+JNJh2eaYmX?=
 =?us-ascii?Q?YvKhqzf1479c5JlhLllYB8x7ZJAuuGnJBDIu?=
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: 17 Jun 2025 17:54:32.7642
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 40d6ed04-72fd-4650-7b38-08ddadc80405
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: CY5PR12MB6647

When a device is passed through to a xl domU, the iomem ranges may
overlap with the extended regions. Remove iomem from extended regions.

Signed-off-by: Stewart Hildebrand 
Reviewed-by: Anthony PERARD 
---
Not sure if we need a Fixes: tag, but if we do:
Fixes: 57f87857dc2d ("libxl/arm: Add handling of extended regions for DomU")

v5->v6:
* no change

v4->v5:
* add Anthony's R-b

v3->v4:
* use "else" instead of continue + another if statement
* remove assert
* s/iomem.end >=/unallocated.start >/ in two conditions
* new variable to distinguish unallocated size from region size
* print base + size - 1

v2->v3:
* no change

v1->v2:
* no change
---
 tools/libs/light/libxl_arm.c | 110 +++++++++++++++++++++++++++++------
 1 file changed, 91 insertions(+), 19 deletions(-)

diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 75c811053c7c..3086c52acf83 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -798,6 +798,8 @@ static int make_timer_node(libxl__gc *gc, void *fdt,
     return 0;
 }
 
+#define MAX_NR_EXT_REGIONS   256
+
 static int make_hypervisor_node(libxl__gc *gc, void *fdt,
                                 const libxl_version_info *vers)
 {
@@ -821,7 +823,7 @@ static int make_hypervisor_node(libxl__gc *gc, void *fdt,
      */
     res = fdt_property_reg_placeholder(gc, fdt, GUEST_ROOT_ADDRESS_CELLS,
                                        GUEST_ROOT_SIZE_CELLS,
-                                       GUEST_RAM_BANKS + 1);
+                                       MAX_NR_EXT_REGIONS + 1);
     if (res) return res;
 
     /*
@@ -1517,17 +1519,29 @@ static void finalise_one_node(libxl__gc *gc, void *fdt, const char *uname,
 
 #define EXT_REGION_MIN_SIZE   xen_mk_ullong(0x0004000000) /* 64MB */
 
-static int finalize_hypervisor_node(libxl__gc *gc, struct xc_dom_image *dom)
+static int compare_iomem(const void *a, const void *b)
+{
+    const libxl_iomem_range *x = a, *y = b;
+
+    if (x->gfn < y->gfn)
+        return -1;
+    if (x->gfn > y->gfn)
+        return 1;
+    return 0;
+}
+
+static int finalize_hypervisor_node(libxl__gc *gc,
+                                    libxl_domain_build_info *b_info,
+                                    struct xc_dom_image *dom)
 {
     void *fdt = dom->devicetree_blob;
-    uint64_t region_size[GUEST_RAM_BANKS] = {0}, region_base[GUEST_RAM_BANKS],
-        bankend[GUEST_RAM_BANKS];
+    uint64_t region_base[MAX_NR_EXT_REGIONS], region_size[MAX_NR_EXT_REGIONS];
     uint32_t regs[(GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS) *
-                  (GUEST_RAM_BANKS + 1)];
+                  (MAX_NR_EXT_REGIONS + 1)];
     be32 *cells = ®s[0];
     const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
     const uint64_t banksize[] = GUEST_RAM_BANK_SIZES;
-    unsigned int i, len, nr_regions = 0;
+    unsigned int i, j, len, nr_regions = 0;
     libxl_dominfo info;
     int offset, rc;
 
@@ -1542,20 +1556,82 @@ static int finalize_hypervisor_node(libxl__gc *gc, struct xc_dom_image *dom)
     if (info.gpaddr_bits > 64)
         return ERROR_INVAL;
 
+    qsort(b_info->iomem, b_info->num_iomem, sizeof(libxl_iomem_range),
+          compare_iomem);
+
     /*
      * Try to allocate separate 2MB-aligned extended regions from the first
      * and second RAM banks taking into the account the maximum supported
      * guest physical address space size and the amount of memory assigned
      * to the guest.
      */
-    for (i = 0; i < GUEST_RAM_BANKS; i++) {
-        region_base[i] = bankbase[i] +
+    for (i = 0; i < GUEST_RAM_BANKS && nr_regions < MAX_NR_EXT_REGIONS; i++) {
+        struct {
+            uint64_t start;
+            uint64_t end; /* inclusive */
+        } unallocated;
+        uint64_t unallocated_size = 0;
+
+        unallocated.start = bankbase[i] +
             ALIGN_UP_TO_2MB((uint64_t)dom->rambank_size[i] << XC_PAGE_SHIFT);
 
-        bankend[i] = ~0ULL >> (64 - info.gpaddr_bits);
-        bankend[i] = min(bankend[i], bankbase[i] + banksize[i] - 1);
-        if (bankend[i] > region_base[i])
-            region_size[i] = bankend[i] - region_base[i] + 1;
+        unallocated.end = ~0ULL >> (64 - info.gpaddr_bits);
+        unallocated.end = min(unallocated.end, bankbase[i] + banksize[i] - 1);
+
+        if (unallocated.end >= unallocated.start)
+            unallocated_size = unallocated.end - unallocated.start + 1;
+
+        if (unallocated_size < EXT_REGION_MIN_SIZE)
+            continue;
+
+        /* Exclude iomem */
+        for (j = 0; j < b_info->num_iomem && nr_regions < MAX_NR_EXT_REGIONS;
+             j++) {
+            struct {
+                uint64_t start;
+                uint64_t end; /* inclusive */
+            } iomem;
+
+            iomem.start = b_info->iomem[j].gfn << XC_PAGE_SHIFT;
+            iomem.end = ((b_info->iomem[j].gfn + b_info->iomem[j].number)
+                         << XC_PAGE_SHIFT) - 1;
+
+            if (iomem.end >= unallocated.start
+                && iomem.start <= unallocated.end) {
+
+                if (iomem.start <= unallocated.start) {
+                    unallocated.start = iomem.end + 1;
+
+                    if (unallocated.start > unallocated.end)
+                        break;
+                } else {
+                    uint64_t size = iomem.start - unallocated.start;
+
+                    if (size >= EXT_REGION_MIN_SIZE) {
+                        region_base[nr_regions] = unallocated.start;
+                        region_size[nr_regions] = size;
+                        nr_regions++;
+                    }
+
+                    unallocated.start = iomem.end + 1;
+
+                    if (unallocated.start > unallocated.end)
+                        break;
+                }
+            }
+        }
+
+        if (unallocated.end >= unallocated.start
+            && nr_regions < MAX_NR_EXT_REGIONS)
+        {
+            uint64_t size = unallocated.end - unallocated.start + 1;
+
+            if (size >= EXT_REGION_MIN_SIZE) {
+                region_base[nr_regions] = unallocated.start;
+                region_size[nr_regions] = size;
+                nr_regions++;
+            }
+        }
     }
 
     /*
@@ -1565,16 +1641,12 @@ static int finalize_hypervisor_node(libxl__gc *gc, struct xc_dom_image *dom)
     set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
               GUEST_GNTTAB_BASE, GUEST_GNTTAB_SIZE);
 
-    for (i = 0; i < GUEST_RAM_BANKS; i++) {
-        if (region_size[i] < EXT_REGION_MIN_SIZE)
-            continue;
-
+    for (i = 0; i < nr_regions; i++) {
         LOG(DEBUG, "Extended region %u: %#"PRIx64"->%#"PRIx64"",
-            nr_regions, region_base[i], region_base[i] + region_size[i]);
+            i, region_base[i], region_base[i] + region_size[i] - 1);
 
         set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
                   region_base[i], region_size[i]);
-        nr_regions++;
     }
 
     if (!nr_regions)
@@ -1626,7 +1698,7 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc *gc,
 
     }
 
-    res = finalize_hypervisor_node(gc, dom);
+    res = finalize_hypervisor_node(gc, &d_config->b_info, dom);
     if (res)
         return res;
 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 17 17:57:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 17:57:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018428.1395327 (Exim 4.92)
	(envelope-from )
	id 1uRaYQ-00019j-5M; Tue, 17 Jun 2025 17:57:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018428.1395327; Tue, 17 Jun 2025 17:57: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 1uRaYQ-00019c-1Y; Tue, 17 Jun 2025 17:57:02 +0000
Received: by outflank-mailman (input) for mailman id 1018428;
 Tue, 17 Jun 2025 17:57: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 1uRaYO-00019S-0J
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 17:57:01 +0000
Received: from mail-24416.protonmail.ch (mail-24416.protonmail.ch
 [109.224.244.16]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 761093de-4ba4-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 19:56:57 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 761093de-4ba4-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1750183016; x=1750442216;
	bh=9u6hJ4xWUQc5IKDjPmlWG7cEI/62Ja7mW08rzqxwFno=;
	h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
	 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector:
	 List-Unsubscribe:List-Unsubscribe-Post;
	b=KhVeysJjxw62OqNRp1gpzqMJINLKsQcTlvdwXpMf9+H7Vb4kdAzuIev62+3yC4PNV
	 TDRDXvs85zUCm7QC0QNRYbUZr3pnFdT5XCI8WAvaFq0oOszyGxJcDz47h0EG0OPd1W
	 aelxLi1U30oGWUDPsBIW6GiN6CuarM1DaOt4zwir9qHM/180z2M0m2KDk+t4lTpDo8
	 S1JkigOWZitAKXhJEhrpEldwAbBj3pmnfvjjh+DzXgmbtrU6bK3tRiwwwix58el53A
	 roDACmDbPHCOc/aLNS0g8tc6jXKtpKdKFBpYESjVI5x7ZrXDn6kyHYgyqqJIR+54qh
	 z3dwJwy4ev00Q==
Date: Tue, 17 Jun 2025 17:56:51 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com
Subject: [PATCH v9] xen/domain: rewrite emulation_flags_ok()
Message-ID: <20250617175639.134786-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 0aea16868e521a603b68685eb6a296c7bf275c4f
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Rewrite emulation_flags_ok() to simplify future modifications.

No functional change intended.

Signed-off-by: Denis Mukhin 
Reviewed-by: Roger Pau Monn=C3=A9 
---
Changes since v8:
- Added Roger's R-b as per
  https://lore.kernel.org/xen-devel/aFEXL5kbhaIXi-Xc@macbook.local/
- Dropped named type for domain capabilities

Link to v8: https://lore.kernel.org/xen-devel/20250617011519.55386-1-dmukhi=
n@ford.com/
Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/1=
874984813
---
 xen/arch/x86/domain.c | 79 +++++++++++++++++++++++++++++++++----------
 1 file changed, 61 insertions(+), 18 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 7536b6c8717e..0a649566a7cd 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -743,32 +743,75 @@ int arch_sanitise_domain_config(struct xen_domctl_cre=
atedomain *config)
     return 0;
 }
=20
+/*
+ * Verify that the domain's emulation flags resolve to a supported configu=
ration.
+ *
+ * This ensures we only allow a known, safe subset of emulation combinatio=
ns
+ * (for both functionality and security). Arbitrary mixes are likely to ca=
use
+ * errors (e.g. null pointer dereferences).
+ *
+ * NB: use the internal X86_EMU_XXX symbols, not the public XEN_X86_EMU_XX=
X
+ * symbols, to take build-time config options (e.g. CONFIG_HVM) into accou=
nt
+ * for short-circuited emulations.
+ */
 static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
 {
+    enum {
+        CAP_PV          =3D BIT(0, U),
+        CAP_HVM         =3D BIT(1, U),
+        CAP_HWDOM       =3D BIT(2, U),
+        CAP_DOMU        =3D BIT(3, U),
+    };
+    static const struct {
+        unsigned int caps;
+        uint32_t min;
+        uint32_t opt;
+    } configs[] =3D {
+#ifdef CONFIG_PV
+        /* PV dom0 and domU */
+        {
+            .caps   =3D CAP_PV | CAP_HWDOM | CAP_DOMU,
+            .opt    =3D X86_EMU_PIT,
+        },
+#endif /* #ifdef CONFIG_PV */
+
+#ifdef CONFIG_HVM
+        /* PVH dom0 */
+        {
+            .caps   =3D CAP_HVM | CAP_HWDOM,
+            .min    =3D X86_EMU_LAPIC | X86_EMU_IOAPIC | X86_EMU_VPCI,
+        },
+
+        /* PVH domU */
+        {
+            .caps   =3D CAP_HVM | CAP_DOMU,
+            .min    =3D X86_EMU_LAPIC,
+        },
+
+        /* HVM domU */
+        {
+            .caps   =3D CAP_HVM | CAP_DOMU,
+            .min    =3D X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ),
+            /* HVM PIRQ feature is user-selectable. */
+            .opt    =3D X86_EMU_USE_PIRQ,
+        },
+#endif /* #ifdef CONFIG_HVM */
+    };
+    unsigned int i;
+    unsigned int caps =3D (is_pv_domain(d) ? CAP_PV : CAP_HVM) |
+                        (is_hardware_domain(d) ? CAP_HWDOM : CAP_DOMU);
+
 #ifdef CONFIG_HVM
     /* This doesn't catch !CONFIG_HVM case but it is better than nothing *=
/
     BUILD_BUG_ON(X86_EMU_ALL !=3D XEN_X86_EMU_ALL);
 #endif
=20
-    if ( is_hvm_domain(d) )
-    {
-        if ( is_hardware_domain(d) &&
-             emflags !=3D (X86_EMU_VPCI | X86_EMU_LAPIC | X86_EMU_IOAPIC) =
)
-            return false;
-        if ( !is_hardware_domain(d) &&
-             /* HVM PIRQ feature is user-selectable. */
-             (emflags & ~X86_EMU_USE_PIRQ) !=3D
-             (X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ)) &&
-             emflags !=3D X86_EMU_LAPIC )
-            return false;
-    }
-    else if ( emflags !=3D 0 && emflags !=3D X86_EMU_PIT )
-    {
-        /* PV or classic PVH. */
-        return false;
-    }
+    for ( i =3D 0; i < ARRAY_SIZE(configs); i++ )
+        if ( (caps & configs[i].caps) =3D=3D caps &&
+             (emflags & ~configs[i].opt) =3D=3D configs[i].min )
+            return true;
=20
-    return true;
+    return false;
 }
=20
 void __init arch_init_idle_domain(struct domain *d)
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Tue Jun 17 17:58:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 17:58:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018437.1395337 (Exim 4.92)
	(envelope-from )
	id 1uRaZf-0001ex-DU; Tue, 17 Jun 2025 17:58:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018437.1395337; Tue, 17 Jun 2025 17:58: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 1uRaZf-0001eq-Aj; Tue, 17 Jun 2025 17:58:19 +0000
Received: by outflank-mailman (input) for mailman id 1018437;
 Tue, 17 Jun 2025 17:58: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 1uRaZe-0001eQ-Nw
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 17:58:18 +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 a487654b-4ba4-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 19:58:16 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 4C65E5C67E1;
 Tue, 17 Jun 2025 17:55:58 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 88B00C4CEE3;
 Tue, 17 Jun 2025 17:58: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: a487654b-4ba4-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750183094;
	bh=2DmOSNKBo5Sbby04E2nvUQ2EOWwkSnyxYx/uVcxEfKo=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=D06oi1zG7+mz+MV4Vlql8zgSpu346pUeQwUja7MBVIEnk06lxUO0jQ2GLY4eqxgw/
	 jBHx7it+/uhjX066wtTAUGve6pNQmMVrKaskARWyxQ9ReGZp53nuzqwCJ+heYdlEqn
	 xWR2yCWBoibnC5NoSjUeB7LYHNsZNYXKvsBV2aOMz5oq1Vcmoi2q7tSjJY1G7lnIOl
	 SEp7nsyZXWhVd4lmxvFY3U/afADTAqRcBcTKwyzoqIu4WotJQcu3Zucb69+rt/6+0i
	 wSJ2hrgKBmMTxX/dTC7VMkN29CbdWYXTKIK6BlTnQD6heMQzvafcAf+V500p1kqVCa
	 T+ne2AUJE35Eg==
Date: Tue, 17 Jun 2025 10:58:12 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Michal Orzel 
cc: xen-devel@lists.xenproject.org, Andrew Cooper , 
    Anthony PERARD , 
    Jan Beulich , Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini 
Subject: Re: [PATCH] console: Do not duplicate early printk messages on
 conring flush
In-Reply-To: <20250617071940.10445-1-michal.orzel@amd.com>
Message-ID: 
References: <20250617071940.10445-1-michal.orzel@amd.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 Jun 2025, Michal Orzel wrote:
> Commit f6d1bfa16052 introduced flushing conring in console_init_preirq().
> However, when CONFIG_EARLY_PRINTK is enabled, the early boot messages
> had already been sent to serial before main console initialization. This
> results in all the early boot messages being duplicated.
> 
> Change conring_flush() to accept argument listing devices to which to
> flush conring. We don't want to send to serial at console initialization
> when using early printk, but we want these messages to be send at conring
> dump triggered by keyhandler.
> 
> Fixes: f6d1bfa16052 ("xen/console: introduce conring_flush()")
> Signed-off-by: Michal Orzel 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/drivers/char/console.c | 20 ++++++++++++++------
>  1 file changed, 14 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index 9a9836ba91e7..5879e31786ba 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -453,9 +453,9 @@ void console_serial_puts(const char *s, size_t nr)
>  }
>  
>  /*
> - * Flush contents of the conring to the physical console devices.
> + * Flush contents of the conring to the selected console devices.
>   */
> -static int conring_flush(void)
> +static int conring_flush(unsigned int flags)
>  {
>      uint32_t idx, len, sofar, c;
>      unsigned int order;
> @@ -479,7 +479,7 @@ static int conring_flush(void)
>          c += len;
>      }
>  
> -    console_send(buf, sofar, CONSOLE_SERIAL | CONSOLE_VIDEO | CONSOLE_PV);
> +    console_send(buf, sofar, flags);
>  
>      free_xenheap_pages(buf, order);
>  
> @@ -491,7 +491,7 @@ static void cf_check conring_dump_keyhandler(unsigned char key)
>      int rc;
>  
>      printk("'%c' pressed -> dumping console ring buffer (dmesg)\n", key);
> -    rc = conring_flush();
> +    rc = conring_flush(CONSOLE_SERIAL | CONSOLE_VIDEO | CONSOLE_PV);
>      if ( rc )
>          printk("failed to dump console ring buffer: %d\n", rc);
>  }
> @@ -1042,6 +1042,7 @@ void __init console_init_preirq(void)
>  {
>      char *p;
>      int sh;
> +    unsigned int flags = CONSOLE_SERIAL | CONSOLE_VIDEO | CONSOLE_PV;
>  
>      serial_init_preirq();
>  
> @@ -1084,8 +1085,15 @@ void __init console_init_preirq(void)
>      serial_set_rx_handler(sercon_handle, serial_rx);
>      pv_console_set_rx_handler(serial_rx);
>  
> -    /* NB: send conring contents to all enabled physical consoles, if any */
> -    conring_flush();
> +    /*
> +     * NB: send conring contents to all enabled physical consoles, if any.
> +     * Skip serial if CONFIG_EARLY_PRINTK is enabled, which means the early
> +     * messages have already been sent to serial.
> +     */
> +    if ( IS_ENABLED(CONFIG_EARLY_PRINTK) )
> +        flags &= ~CONSOLE_SERIAL;
> +
> +    conring_flush(flags);
>  
>      /* HELLO WORLD --- start-of-day banner text. */
>      nrspin_lock(&console_lock);
> -- 
> 2.25.1
> 


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 17:59:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 17:59:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018446.1395348 (Exim 4.92)
	(envelope-from )
	id 1uRaaz-0002Co-Nf; Tue, 17 Jun 2025 17:59:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018446.1395348; Tue, 17 Jun 2025 17:59: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 1uRaaz-0002Ch-Jt; Tue, 17 Jun 2025 17:59:41 +0000
Received: by outflank-mailman (input) for mailman id 1018446;
 Tue, 17 Jun 2025 17:59: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 1uRaay-00029n-Rj
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 17:59: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 d67074ba-4ba4-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 19:59:40 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id D96ABA51830;
 Tue, 17 Jun 2025 17:59:38 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id F1AF2C4CEE7;
 Tue, 17 Jun 2025 17:59: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: d67074ba-4ba4-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750183178;
	bh=FGszfJXbk0E0WGlrlFXbMX9YMoQiKINJaDgfBZRZyHs=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=aF8yRil56F0r3zxynKcCp9yj1S6vEvOFoRWfe7KyecD5I6CccokV/W80POpqQYUYU
	 0WTausQ67P189R3p2fVAEx+ABk2eoA8y1Ghu75b7nO76DRIOKrDk9/dXnyYsFWyrCH
	 tSk7gVKF1ziqtf/iLHtyzjvV8Q78LjBsmOyq3h55o54MsIOYnx0W+8R2AeuM8xon3J
	 uIto5qz9l99IVtME/nuTVM0kpj+ARXRd6FcFlbZmOykDO52Jg0ZY6bofqB6Pf8NWHL
	 MDbJ2PAcVlAqveZtf7JZlVvh6XdSCikVOt5MDbbSAeX3bJ+TlYiUs8VquSZPY8iKql
	 6o5S37ZTOYmnQ==
Date: Tue, 17 Jun 2025 10:59:36 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Victor Lira 
cc: xen-devel@lists.xenproject.org, Michal Orzel , 
    Stefano Stabellini 
Subject: Re: [PATCH v1] automation: disable terminal echo in xilinx test
 scripts
In-Reply-To: <20250617164449.3925765-1-victorm.lira@amd.com>
Message-ID: 
References: <20250617164449.3925765-1-victorm.lira@amd.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 Jun 2025, victorm.lira@amd.com wrote:
> From: Victor Lira 
> 
> The default terminal settings in Linux will enable echo which interferes with
> these tests. Set the value in the script to avoid failure caused by a settings
> reset.
> 
> Signed-off-by: Victor Lira 

Acked-by: Stefano Stabellini 


> ---
> Cc: Michal Orzel 
> Cc: Stefano Stabellini 
> ---
>  automation/scripts/xilinx-smoke-dom0-x86_64.sh    | 2 +-
>  automation/scripts/xilinx-smoke-dom0less-arm64.sh | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/automation/scripts/xilinx-smoke-dom0-x86_64.sh b/automation/scripts/xilinx-smoke-dom0-x86_64.sh
> index 71cdb295b2..6970a8658d 100755
> --- a/automation/scripts/xilinx-smoke-dom0-x86_64.sh
> +++ b/automation/scripts/xilinx-smoke-dom0-x86_64.sh
> @@ -165,7 +165,7 @@ sleep 5
>  sh /scratch/gitlab-runner/${TEST_BOARD}.sh 1
>  sleep 5
>  set +e
> -stty -F ${SERIAL_DEV} 57600
> +stty -F ${SERIAL_DEV} 57600 -echo
> 
>  # Capture test result and power off board before exiting.
>  export PASSED="${PASS_MSG}"
> diff --git a/automation/scripts/xilinx-smoke-dom0less-arm64.sh b/automation/scripts/xilinx-smoke-dom0less-arm64.sh
> index 293232eebf..1d7162f1b3 100755
> --- a/automation/scripts/xilinx-smoke-dom0less-arm64.sh
> +++ b/automation/scripts/xilinx-smoke-dom0less-arm64.sh
> @@ -128,7 +128,7 @@ cd $START
>  # connect to serial
>  SERIAL_DEV="/dev/serial/zynq"
>  set +e
> -stty -F ${SERIAL_DEV} 115200
> +stty -F ${SERIAL_DEV} 115200 -echo
> 
>  # Capture test result and power off board before exiting.
>  export PASSED="${passed}"
> --
> 2.34.1
> 


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 19:00:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 19:00:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018468.1395357 (Exim 4.92)
	(envelope-from )
	id 1uRbXF-0001g7-V6; Tue, 17 Jun 2025 18:59:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018468.1395357; Tue, 17 Jun 2025 18:59: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 1uRbXF-0001g0-S4; Tue, 17 Jun 2025 18:59:53 +0000
Received: by outflank-mailman (input) for mailman id 1018468;
 Tue, 17 Jun 2025 18:59: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 1uRbXC-0001fu-9G
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 18:59:52 +0000
Received: from mail-10630.protonmail.ch (mail-10630.protonmail.ch
 [79.135.106.30]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3c89369b-4bad-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 20:59:46 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3c89369b-4bad-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1750186785; x=1750445985;
	bh=YebZoXWCGUK9x54d9Bs/zn4kf8VJfonuAGPBWlMfrgE=;
	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=I4UqD5U6bmYvOb9j34Tm8P5MVflSLEoKZMa0dZwQX0bpp1oVgbsiiAaaz1Y56HHTG
	 bSn+TGs+itxqf8eBaTiImqLfzOgxaLrX3xx46PtKFjdkXBktiQJ/RhU5GwvdQuSWyE
	 tPOXaf7IXu5LBbjTjq2J6HvKGaUeLewwWyM//R9vC9o8zjglzYhUyOd6KCLajWjWTB
	 5BiguvVnc7YknfAacofGfd9CjDRdGYsbASXasQk6YQiMUNtQv1LFeNNHa/F3TZ8jJH
	 APbiWfY+C5E118KVXafJQAEv5JzbAiCx1He2zGmVM4pmBzLZPma4gGzeMUwc8EstBi
	 k+8gibnrWELMQ==
Date: Tue, 17 Jun 2025 18:59:41 +0000
To: Michal Orzel 
From: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Anthony PERARD , Jan Beulich , Julien Grall , =?utf-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini 
Subject: Re: [PATCH] console: Do not duplicate early printk messages on conring flush
Message-ID: 
In-Reply-To: <20250617071940.10445-1-michal.orzel@amd.com>
References: <20250617071940.10445-1-michal.orzel@amd.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 419bcdb39540859e55922c88db2fc7af8e49d16b
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 17, 2025 at 09:19:40AM +0200, Michal Orzel wrote:
> Commit f6d1bfa16052 introduced flushing conring in console_init_preirq().
> However, when CONFIG_EARLY_PRINTK is enabled, the early boot messages
> had already been sent to serial before main console initialization. This
> results in all the early boot messages being duplicated.
>=20
> Change conring_flush() to accept argument listing devices to which to
> flush conring. We don't want to send to serial at console initialization
> when using early printk, but we want these messages to be send at conring
> dump triggered by keyhandler.
>=20
> Fixes: f6d1bfa16052 ("xen/console: introduce conring_flush()")
> Signed-off-by: Michal Orzel 

Reviewed-by: Denis Mukhin 

> ---
>  xen/drivers/char/console.c | 20 ++++++++++++++------
>  1 file changed, 14 insertions(+), 6 deletions(-)
>=20
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index 9a9836ba91e7..5879e31786ba 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -453,9 +453,9 @@ void console_serial_puts(const char *s, size_t nr)
>  }
>=20
>  /*
> - * Flush contents of the conring to the physical console devices.
> + * Flush contents of the conring to the selected console devices.
>   */
> -static int conring_flush(void)
> +static int conring_flush(unsigned int flags)
>  {
>      uint32_t idx, len, sofar, c;
>      unsigned int order;
> @@ -479,7 +479,7 @@ static int conring_flush(void)
>          c +=3D len;
>      }
>=20
> -    console_send(buf, sofar, CONSOLE_SERIAL | CONSOLE_VIDEO | CONSOLE_PV=
);
> +    console_send(buf, sofar, flags);
>=20
>      free_xenheap_pages(buf, order);
>=20
> @@ -491,7 +491,7 @@ static void cf_check conring_dump_keyhandler(unsigned=
 char key)
>      int rc;
>=20
>      printk("'%c' pressed -> dumping console ring buffer (dmesg)\n", key)=
;
> -    rc =3D conring_flush();
> +    rc =3D conring_flush(CONSOLE_SERIAL | CONSOLE_VIDEO | CONSOLE_PV);
>      if ( rc )
>          printk("failed to dump console ring buffer: %d\n", rc);
>  }
> @@ -1042,6 +1042,7 @@ void __init console_init_preirq(void)
>  {
>      char *p;
>      int sh;
> +    unsigned int flags =3D CONSOLE_SERIAL | CONSOLE_VIDEO | CONSOLE_PV;
>=20
>      serial_init_preirq();
>=20
> @@ -1084,8 +1085,15 @@ void __init console_init_preirq(void)
>      serial_set_rx_handler(sercon_handle, serial_rx);
>      pv_console_set_rx_handler(serial_rx);
>=20
> -    /* NB: send conring contents to all enabled physical consoles, if an=
y */
> -    conring_flush();
> +    /*
> +     * NB: send conring contents to all enabled physical consoles, if an=
y.
> +     * Skip serial if CONFIG_EARLY_PRINTK is enabled, which means the ea=
rly
> +     * messages have already been sent to serial.
> +     */
> +    if ( IS_ENABLED(CONFIG_EARLY_PRINTK) )
> +        flags &=3D ~CONSOLE_SERIAL;
> +
> +    conring_flush(flags);
>=20
>      /* HELLO WORLD --- start-of-day banner text. */
>      nrspin_lock(&console_lock);
> --
> 2.25.1
>=20
>=20



From xen-devel-bounces@lists.xenproject.org Tue Jun 17 19:03:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 19:03:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018475.1395366 (Exim 4.92)
	(envelope-from )
	id 1uRbaM-0003F9-Ai; Tue, 17 Jun 2025 19:03:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018475.1395366; Tue, 17 Jun 2025 19:03: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 1uRbaM-0003F2-8E; Tue, 17 Jun 2025 19:03:06 +0000
Received: by outflank-mailman (input) for mailman id 1018475;
 Tue, 17 Jun 2025 19:03: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 1uRbaK-0003Ew-LR
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 19:03:04 +0000
Received: from mail-10628.protonmail.ch (mail-10628.protonmail.ch
 [79.135.106.28]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b196e198-4bad-11f0-a309-13f23c93f187;
 Tue, 17 Jun 2025 21:03:03 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b196e198-4bad-11f0-a309-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1750186982; x=1750446182;
	bh=GXg+ZWBOoLacSfrxkIxkToMvDVjoH881aIfuu/mn5iU=;
	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=h0R/OZLjSa70W3wtrgrr1+c0EEAMUlkobTQOowGNVJxMw7OPSvmRZx5Cogt3P7CQZ
	 uL6nB7ZNkpW8NB44EG+Dg5qTxCQK78n15iFiWprLFiHmPitTQnkV5eVGDSEH44VUtS
	 Fp2G24aXNEc9Or+99KnA+AI4LFtTeYfq9YJ+LCimaFrVH/vEfNOaNQzJ65EmxO5gKS
	 s7oFiaFDftI6XXFXvkNRBm7mx7IuQ5fON8JwxEWjHMBQR78WRMrp7PC6H3ZflYthlE
	 N3xbppXuJ35zY5IdUIA9YqOdPZneDR92+XycsDdgxQpGVXLHMxEHEZdZO1veIp31Om
	 H9Y0XXxtjA/qA==
Date: Tue, 17 Jun 2025 19:02:57 +0000
To: Jan Beulich 
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2] xen/console: introduce domain_console struct
Message-ID: 
In-Reply-To: <1ac74dd3-e0c5-43e5-9eed-c1a2cc17d068@suse.com>
References: <20250617012713.57074-1-dmukhin@ford.com> <1ac74dd3-e0c5-43e5-9eed-c1a2cc17d068@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: cf302f9b224c3a6337c5b5cedef78fe10828da11
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 17, 2025 at 11:48:10AM +0200, Jan Beulich wrote:
> On 17.06.2025 03:27, dmkhn@proton.me wrote:
> > From: Denis Mukhin 
> >
> > Introduce domain_console for grouping data structures used for integrat=
ing
> > domain's diagnostic console with Xen's console driver.
> >
> > Group all pbuf-related data structures under domain_console. Rename the=
 moved
> > fields to plain .buf, .idx and .lock names, since all uses of the field=
s are
> > touched.
> >
> > Bump the domain console buffer size to the closest power of 2 (256) and
> > rename the symbol to DOMAIN_CONSOLE_BUF_SIZE.
> >
> > Move d->console->buf management under CONFIG_VERBOSE_DEBUG when the
> > HYPERCALL_console_io handler is enabled.
>=20
> This, if at all, needs to be a separate change (with its own justificatio=
n).
> I for one don't think VERBOSE_DEBUG is intended to control any kind of gu=
est
> output.
>=20
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -559,7 +559,6 @@ void hvm_do_resume(struct vcpu *v)
> >  static int cf_check hvm_print_line(
> >      int dir, unsigned int port, unsigned int bytes, uint32_t *val)
> >  {
> > -    struct domain *cd =3D current->domain;
> >      char c =3D *val;
> >
> >      ASSERT(bytes =3D=3D 1 && port =3D=3D XEN_HVM_DEBUGCONS_IOPORT);
> > @@ -570,17 +569,24 @@ static int cf_check hvm_print_line(
> >
> >      if ( !is_console_printable(c) )
> >          return X86EMUL_OKAY;
>=20
> After this "return" ...
>=20
> > -
> > -    spin_lock(&cd->pbuf_lock);
> > -    if ( c !=3D '\n' )
> > -        cd->pbuf[cd->pbuf_idx++] =3D c;
> > -    if ( (cd->pbuf_idx =3D=3D (DOMAIN_PBUF_SIZE - 1)) || (c =3D=3D '\n=
') )
> > +#ifdef CONFIG_VERBOSE_DEBUG
> > +    else
>=20
> ... there's no point to have "else" here.
>=20
> >      {
> > -        cd->pbuf[cd->pbuf_idx] =3D '\0';
> > -        guest_printk(cd, XENLOG_G_DEBUG "%s\n", cd->pbuf);
> > -        cd->pbuf_idx =3D 0;
> > +        struct domain *cd =3D current->domain;
>=20
> We normally name such a variable d. It also looks as if this could be poi=
nter-
> to-const.
>=20
> > +        struct domain_console *cons =3D cd->console;
> > +
> > +        spin_lock(&cons->lock);
> > +        if ( c !=3D '\n' )
> > +            cons->buf[cons->idx++] =3D c;
> > +        if ( (cons->idx =3D=3D (DOMAIN_CONSOLE_BUF_SIZE - 1)) || (c =
=3D=3D '\n') )
> > +        {
> > +            cons->buf[cons->idx] =3D '\0';
> > +            guest_printk(cd, XENLOG_G_DEBUG "%s\n", cons->buf);
> > +            cons->idx =3D 0;
> > +        }
> > +        spin_unlock(&cons->lock);
> >      }
> > -    spin_unlock(&cd->pbuf_lock);
> > +#endif
>=20
> None of the re-indentation is really warranted here (and will likely go a=
way
> anyway once the #ifdef is dropped).
>=20
> > --- a/xen/common/domain.c
> > +++ b/xen/common/domain.c
> > @@ -669,7 +669,7 @@ static void _domain_destroy(struct domain *d)
> >      BUG_ON(!d->is_dying);
> >      BUG_ON(atomic_read(&d->refcnt) !=3D DOMAIN_DESTROYED);
> >
> > -    xfree(d->pbuf);
> > +    xfree(d->console);
> >
> >      argo_destroy(d);
> >
> > @@ -800,6 +800,11 @@ struct domain *domain_create(domid_t domid,
> >      if ( (d =3D alloc_domain_struct()) =3D=3D NULL )
> >          return ERR_PTR(-ENOMEM);
> >
> > +    err =3D -ENOMEM;
> > +    d->console =3D xvzalloc(typeof(*d->console));
> > +    if ( !d->console )
> > +        goto fail;
>=20
> This definitely need to move down some, at least ...
>=20
> >      /* Sort out our idea of is_system_domain(). */
> >      d->domain_id =3D domid;
> >      d->unique_id =3D get_unique_id();
>=20
> ... past here. There absolutely must not be struct domain instances be
> passed around (see e.g. the call to sched_destroy_domain()) without the
> domain ID set. It's hard to see ...
>=20
> > @@ -862,7 +867,9 @@ struct domain *domain_create(domid_t domid,
> >      spin_lock_init(&d->shutdown_lock);
> >      d->shutdown_code =3D SHUTDOWN_CODE_INVALID;
> >
> > -    spin_lock_init(&d->pbuf_lock);
> > +#ifdef CONFIG_VERBOSE_DEBUG
> > +    spin_lock_init(&d->console->lock);
> > +#endif
>=20
> .. why here or ...
>=20
> > @@ -955,11 +962,6 @@ struct domain *domain_create(domid_t domid,
> >      if ( (err =3D argo_init(d)) !=3D 0 )
> >          goto fail;
> >
> > -    err =3D -ENOMEM;
> > -    d->pbuf =3D xzalloc_array(char, DOMAIN_PBUF_SIZE);
> > -    if ( !d->pbuf )
> > -        goto fail;
>=20
> ... even here wouldn't be early enough anyway.
>=20
> And btw - where did this buffer allocation move? I don't see anywhere
> that d->console->buf would now be initialized. (However, see below.)
>=20
> > --- a/xen/include/xen/sched.h
> > +++ b/xen/include/xen/sched.h
> > @@ -371,6 +371,22 @@ struct evtchn_port_ops;
> >
> >  #define MAX_NR_IOREQ_SERVERS 8
> >
> > +/* Arbitrary value; must be a multiple of the cacheline size. */
> > +#define DOMAIN_CONSOLE_BUF_SIZE 256
>=20
> Where does the relationship with cache line size come from? What if
> Xen was to run on hardware (whichever arch) with 512-byte cache lines?
>=20
> > +/* Domain console settings. */
> > +struct domain_console {
> > +#ifdef CONFIG_VERBOSE_DEBUG
> > +    /* hvm_print_line() and guest_console_write() logging. */
> > +    char *buf;
>=20
> To avoid the need to do yet another separate allocation, how about ...
>=20
> > +    unsigned int idx;
> > +    spinlock_t lock;
> > +#endif /* CONFIG_VERBOSE_DEBUG */
> > +
> > +    /* Permission to take ownership of the physical console input. */
> > +    bool input_allowed;
>=20
>     char buf[DOMAIN_CONSOLE_BUF_SIZE];
>=20
> Ultimately this would allow the buffer size to be e.g. command line
> controlled (if so desired), by then simply converting to a flexible
> array member.

Whoops, apologies for the bogus change.
Looks like I posted from the wrong branch.

>=20
> Jan



From xen-devel-bounces@lists.xenproject.org Tue Jun 17 20:35:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 20:35:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018503.1395377 (Exim 4.92)
	(envelope-from )
	id 1uRd1h-0005KD-SF; Tue, 17 Jun 2025 20:35:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018503.1395377; Tue, 17 Jun 2025 20:35: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 1uRd1h-0005K6-Oq; Tue, 17 Jun 2025 20:35:25 +0000
Received: by outflank-mailman (input) for mailman id 1018503;
 Tue, 17 Jun 2025 20:35:24 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uRd1g-0005K0-Ua
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 20:35:24 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uRd1g-006MO8-0S;
 Tue, 17 Jun 2025 20:35:24 +0000
Received: from [2a02:8012:3a1:0:e9a3:882d:7e0:8b9]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uRd1f-008qG6-2k;
 Tue, 17 Jun 2025 20:35: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" 
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=cwpUiem4Y2hMK+oqZ3xRDxR+R9xAKA/gte+4qjDW5qM=; b=2MyZlxNyBoqqSVHghdnCSn7+yS
	ZFlllUP3h/bv4eDuc+hqpfqIyk/UxgNT42qTnhu3Wo2Z+AqfxtxqhVqTSW2urP8qPFRIKXLgEVU+v
	HUgPlgIJC2tKCpJoFoKSY7JVavOs9daX2A14TQTVGf12O791CiEP2vXYItszxOHQPeMQ=;
Message-ID: <8e7f1680-0747-4640-b35b-cdd2468dbfdd@xen.org>
Date: Tue, 17 Jun 2025 21:35:22 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/dt: Remove loop in dt_read_number()
To: Alejandro Vallejo , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 "Daniel P . Smith" 
References: <20250617110741.34648-1-agarciav@amd.com>
Content-Language: en-GB
From: Julien Grall 
In-Reply-To: <20250617110741.34648-1-agarciav@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Alejandro,

On 17/06/2025 12:07, Alejandro Vallejo wrote:
> The DT spec declares only two number types for a property: u32 and u64,
> as per Table 2.3 in Section 2.2.4. Remove unbounded loop and replace
> with a switch statement. Default to a size of 1 cell in the nonsensical
> size case, with a warning printed on the Xen console.
> 
> Suggested-by: Daniel P. Smith" 
> Signed-off-by: Alejandro Vallejo 
> ---
> Based on this suggestion by Daniel:
> 
>      https://lore.kernel.org/xen-devel/a66c11c4-cfac-4934-b1f5-e07c728db8de@apertussolutions.com/
> 
> I'd be happier panicking there, seeing how DTs are by their very nature
> trusted blobs. But I suspect defaulting to something will find less
> resistance in review. I don't care much either way.
> ---
>   xen/include/xen/device_tree.h | 15 ++++++++++++---
>   1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> index 75017e4266..2daef8659e 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -261,10 +261,19 @@ void intc_dt_preinit(void);
>   /* Helper to read a big number; size is in cells (not bytes) */
>   static inline u64 dt_read_number(const __be32 *cell, int size)
>   {
> -    u64 r = 0;
> +    u64 r = be32_to_cpu(*cell);
> +
> +    switch ( size )
> +    {
> +    case 1:
> +        break;
> +    case 2:
> +        r = (r << 32) | be32_to_cpu(cell[1]);
> +    default:
> +        // Nonsensical size. default to 1.
> +        printk(XENLOG_WARNING "dt_read_number(%d) bad size", size);

Aside what Andrew wrote. I would consider to use at least 
ASSERT_UNREACHABLE() for debug build. I am not sure what's the best 
approach for release build. But this likely want to a XENLOG_ERR.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Tue Jun 17 20:35:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 20:35:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018507.1395387 (Exim 4.92)
	(envelope-from )
	id 1uRd28-0005jG-24; Tue, 17 Jun 2025 20:35:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018507.1395387; Tue, 17 Jun 2025 20:35:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRd27-0005j7-Vi; Tue, 17 Jun 2025 20:35:51 +0000
Received: by outflank-mailman (input) for mailman id 1018507;
 Tue, 17 Jun 2025 20:35: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 1uRd26-0005in-Pb
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 20:35:50 +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 a710e856-4bba-11f0-a30a-13f23c93f187;
 Tue, 17 Jun 2025 22:35:49 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 664FCA51E05;
 Tue, 17 Jun 2025 20:35:48 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4C4D1C4CEF1;
 Tue, 17 Jun 2025 20:35:47 +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: a710e856-4bba-11f0-a30a-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750192548;
	bh=uAi8POX0ByOPTyFAILw9Y1dj0FN6VKth7MfuDiGcRz8=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=dZ/Ljp2u3OhxVyVFRykPGqmJZx6dnnxpayoCSadlRWufMYX03RQUQaeb5rWb9IsO1
	 qD367hlYYUnZYifoZi0AU/UPmEa5f9wil1Uxx9uA8MaNMv+rzKrgMndOpN2vBVwp33
	 OkuRf2W33i1O76u+x9Ov2l7b13MCiK1HEWB8QThQ6wRD+BeQQrtQzoI9WuRFB1PA3S
	 /Uha7asKUEHmQDl4Stt3/VPV3DcT407JgIW5iSx/epSD0Gjy2rw17G3QW/QI7UQI+t
	 9oCMlmRoiR4cR5gqRgqkq/wHRFeBAPo54gHGerBlt5VDKdky4xnhv2Us5TV+4sp3gs
	 hK5IxF8YXmjAQ==
Date: Tue, 17 Jun 2025 13:35:45 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel 
Subject: Re: [PATCH v2] xen/dt: Remove loop in dt_read_number()
In-Reply-To: <20250617171358.670642-1-agarciav@amd.com>
Message-ID: 
References: <20250617171358.670642-1-agarciav@amd.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 Jun 2025, Alejandro Vallejo wrote:
> The DT spec declares only two number types for a property: u32 and u64,
> as per Table 2.3 in Section 2.2.4. Remove unbounded loop and replace
> with a switch statement. Default to a size of 1 cell in the nonsensical
> size case, with a warning printed on the Xen console.
> 
> Suggested-by: Daniel P. Smith" 
> Signed-off-by: Alejandro Vallejo 
> ---
> v2:
>   * Added missing `break` on the `case 2:` branch and added ASSERT_UNREACHABLE() to the deafult path
> ---
>  xen/include/xen/device_tree.h | 17 ++++++++++++++---
>  1 file changed, 14 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> index 75017e4266..2ec668b94a 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -261,10 +261,21 @@ void intc_dt_preinit(void);
>  /* Helper to read a big number; size is in cells (not bytes) */
>  static inline u64 dt_read_number(const __be32 *cell, int size)
>  {
> -    u64 r = 0;
> +    u64 r = be32_to_cpu(*cell);
> +
> +    switch ( size )
> +    {
> +    case 1:
> +        break;
> +    case 2:
> +        r = (r << 32) | be32_to_cpu(cell[1]);
> +        break;
> +    default:
> +        // Nonsensical size. default to 1.

NIT: comment style is /* comment */

> +        printk(XENLOG_WARNING "dt_read_number(%d) bad size\n", size);
> +        ASSERT_UNREACHABLE();

You need a break statement even after ASSERT_UNREACHABLE() for MISRA R16.3


> +    };
>  
> -    while ( size-- )
> -        r = (r << 32) | be32_to_cpu(*(cell++));
>      return r;
>  }
>  
> 
> base-commit: 14c57887f36937c1deb9eeca852c3a7595d2d0b8
> -- 
> 2.43.0
> 


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 20:38:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 20:38:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018517.1395397 (Exim 4.92)
	(envelope-from )
	id 1uRd4U-0006Lb-E0; Tue, 17 Jun 2025 20:38:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018517.1395397; Tue, 17 Jun 2025 20:38: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 1uRd4U-0006LU-Aw; Tue, 17 Jun 2025 20:38:18 +0000
Received: by outflank-mailman (input) for mailman id 1018517;
 Tue, 17 Jun 2025 20:38:16 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uRd4S-0006LO-Jj
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 20:38:16 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uRd4S-006MSj-0k;
 Tue, 17 Jun 2025 20:38:16 +0000
Received: from [2a02:8012:3a1:0:e9a3:882d:7e0:8b9]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uRd4S-008qNI-0G;
 Tue, 17 Jun 2025 20:38: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=1cARaKhBjDmYXDKwyZtM+IVdgNvnTgjM3ZgkmDc2aTY=; b=uvCYoZ/ItubvCLSZYPogx0+1w8
	Ps6SzAKSHVDGE/xic+V/TeBYKyDdW8f7MifO3D+rNAKuB4435kGPn75UwM07/X/RnNutj7B7fXlHv
	s7VfGbI7yurWGYYh/qgIgBSBM9O78vWyimo2LB1ulTYf0/CYSBT4a2pdpl2agw+qrtIM=;
Message-ID: <4ee07b7b-9c75-4e19-8594-803b9edec5d7@xen.org>
Date: Tue, 17 Jun 2025 21:38:14 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen/dt: Remove loop in dt_read_number()
Content-Language: en-GB
To: Alejandro Vallejo , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel 
References: <20250617171358.670642-1-agarciav@amd.com>
From: Julien Grall 
In-Reply-To: <20250617171358.670642-1-agarciav@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Alejandro,

Sorry I didn't see there was a v2.

On 17/06/2025 18:13, Alejandro Vallejo wrote:
> The DT spec declares only two number types for a property: u32 and u64,
> as per Table 2.3 in Section 2.2.4. Remove unbounded loop and replace
> with a switch statement. Default to a size of 1 cell in the nonsensical
> size case, with a warning printed on the Xen console.
> 
> Suggested-by: Daniel P. Smith" 
> Signed-off-by: Alejandro Vallejo 
> ---
> v2:
>    * Added missing `break` on the `case 2:` branch and added ASSERT_UNREACHABLE() to the deafult path
> ---
>   xen/include/xen/device_tree.h | 17 ++++++++++++++---
>   1 file changed, 14 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> index 75017e4266..2ec668b94a 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -261,10 +261,21 @@ void intc_dt_preinit(void);
>   /* Helper to read a big number; size is in cells (not bytes) */
>   static inline u64 dt_read_number(const __be32 *cell, int size)
>   {
> -    u64 r = 0;
> +    u64 r = be32_to_cpu(*cell);
> +
> +    switch ( size )
> +    {
> +    case 1:
> +        break;
> +    case 2:
> +        r = (r << 32) | be32_to_cpu(cell[1]);
> +        break;
> +    default:
> +        // Nonsensical size. default to 1.
> +        printk(XENLOG_WARNING "dt_read_number(%d) bad size\n", size);

I think this needs to at least be a XENLOG_ERR.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Tue Jun 17 21:02:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 21:02:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018531.1395406 (Exim 4.92)
	(envelope-from )
	id 1uRdS8-0001vb-02; Tue, 17 Jun 2025 21:02:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018531.1395406; Tue, 17 Jun 2025 21: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 1uRdS7-0001vU-Tk; Tue, 17 Jun 2025 21:02:43 +0000
Received: by outflank-mailman (input) for mailman id 1018531;
 Tue, 17 Jun 2025 21: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 1uRdS6-0001vO-EV
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 21:02:42 +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 620f44b1-4bbe-11f0-b894-0df219b8e170;
 Tue, 17 Jun 2025 23:02:32 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id B37B65C5E68;
 Tue, 17 Jun 2025 21:00:13 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id E0282C4CEE3;
 Tue, 17 Jun 2025 21:02: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: 620f44b1-4bbe-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750194150;
	bh=tLEpIxi5l6oSc84fZGU36wS/qMjNnrsl4ukBbDUEVlU=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=S221HgyKunaFanOemN1sAYFN7yIAUbj+HdZDZxhuwB3NaCtIfLEyKeKMjopOMWxFa
	 PbV9xpW9Y6JCJECLtySJqJVDqEyYQwCEPuPiw/LqcF86fgpnz0xyH5f6gYikZjHnpw
	 KFyOyjW6SUIWMMII+3cgXN1RoxRXWBqud74O4ImK4AcNpgM3SYTBYKyR5ybqGalv4f
	 1Ry07KqMcb3V4cZL4Jx+Y3sN5neofElG+hhFNVrHmEtPxkD6QDu3Ci3fe8ZniZActC
	 LkBPI8BWALt2HqAXwx3oOvrUexxeUymr9/u/L4VFsbLxQrQ2/saJicUv9gw+2hW0k+
	 4kTfJclYKs54A==
Date: Tue, 17 Jun 2025 14:02:27 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Nick Rosbrook 
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 
Subject: Re: [PATCH] MAINTAINERS: update my email address
In-Reply-To: <55a35aed605bafd38b6ccfd0bb6e401a5fdf9794.1750172048.git.rosbrookn@gmail.com>
Message-ID: 
References: <55a35aed605bafd38b6ccfd0bb6e401a5fdf9794.1750172048.git.rosbrookn@gmail.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 Jun 2025, Nick Rosbrook wrote:
> Change rosbrookn@gmail.com -> enr0n@ubuntu.com
> 
> Signed-off-by: Nick Rosbrook 

Acked-by: Stefano Stabellini 


> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 13f31b0c1b..9aa7dd2f57 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -330,7 +330,7 @@ F:	xen/arch/x86/debug.c
>  F:	tools/debugger/gdbsx/
>  
>  GOLANG BINDINGS
> -M:	Nick Rosbrook 
> +M:	Nick Rosbrook 
>  R:	George Dunlap 
>  S:	Maintained
>  F:	tools/golang
> -- 
> 2.48.1
> 


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 22:52:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 22:52:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018556.1395454 (Exim 4.92)
	(envelope-from )
	id 1uRf9u-0006s3-VQ; Tue, 17 Jun 2025 22:52:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018556.1395454; Tue, 17 Jun 2025 22:52: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 1uRf9u-0006rw-Ra; Tue, 17 Jun 2025 22:52:02 +0000
Received: by outflank-mailman (input) for mailman id 1018556;
 Tue, 17 Jun 2025 22:52: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 1uRf9u-0006ro-8P
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 22:52:02 +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 ad2d4754-4bcd-11f0-a30a-13f23c93f187;
 Wed, 18 Jun 2025 00:52:00 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 489C05C53F0;
 Tue, 17 Jun 2025 22:49:42 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 92038C4CEE3;
 Tue, 17 Jun 2025 22:51: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: ad2d4754-4bcd-11f0-a30a-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750200718;
	bh=Spc04Q5E4aU7xLHQhioCLSz0rEpRmZag58hMfDZCJYE=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=ZS09iev8n7N8sK/CZPwy/YnRNIfC9GPM7ZmjBN88D30MULd6NloqcOwv8Uz7nc29G
	 k3uNQEKoDuCVkdkizBebz4rJHf53rSoufmFGOnzpXiQ+9IR60+PeiPVkaW/LD2p+ES
	 CQ07on2z0CXaflrhvnbY/NJf4n59aoFs13bxFG3+uhqLQ21gWWYBlatUODhMqvvI8f
	 TZOXQIuK691J5u4Wbl/27kzyEhECNEh2FgSjx6NqWoHGmZFD48wPzBNQaitLn7or+7
	 do1mlIsnOwirmgqRxA3t9laL+9t4Y9RSCDz4ranLn/x2FwuJLF2AX+Gc4+gIIvWvmK
	 D/GOynk2fuVUw==
Date: Tue, 17 Jun 2025 15:51:51 -0700 (PDT)
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 
Subject: Re: [PATCH v6 3/4] xen/arm: add support for PCI child bus
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 Thu, 12 Jun 2025, Mykyta Poturai wrote:
> From: Oleksandr Andrushchenko 
> 
> PCI host bridges often have different ways to access the root and child
> bus configuration spaces. One of the examples is Designware's host bridge
> and its multiple clones [1].
> 
> Linux kernel implements this by instantiating a child bus when device
> drivers provide not only the usual pci_ops to access ECAM space (this is
> the case for the generic host bridge), but also means to access the child
> bus which has a dedicated configuration space and own implementation for
> accessing the bus, e.g. child_ops.
> 
> For Xen it is not feasible to fully implement PCI bus infrastructure as
> Linux kernel does, but still child bus can be supported.
> 
> Add support for the PCI child bus which includes the following changes:
> - introduce bus mapping functions depending on SBDF
> - assign bus start and end for the child bus and re-configure the same for
>   the parent (root) bus
> - make pci_find_host_bridge be aware of multiple busses behind the same bridge
> - update pci_host_bridge_mappings, so it also doesn't map to guest the memory
>   spaces belonging to the child bus
> - make pci_host_common_probe accept one more pci_ops structure for the child bus
> - install MMIO handlers for the child bus for hardware domain
> - re-work vpci_mmio_{write|read} with parent and child approach in mind
> 
> [1] https://elixir.bootlin.com/linux/v5.15/source/drivers/pci/controller/dwc
> 
> Signed-off-by: Oleksandr Andrushchenko 
> Signed-off-by: Mykyta Poturai 

[...]


> diff --git a/xen/arch/arm/pci/pci-host-common.c b/xen/arch/arm/pci/pci-host-common.c
> index 53953d4895..487c545f3a 100644
> --- a/xen/arch/arm/pci/pci-host-common.c
> +++ b/xen/arch/arm/pci/pci-host-common.c
> @@ -57,17 +57,12 @@ static void pci_ecam_free(struct pci_config_window *cfg)
>      xfree(cfg);
>  }
>  
> -static struct pci_config_window * __init
> -gen_pci_init(struct dt_device_node *dev, const struct pci_ecam_ops *ops)
> +void __init pci_generic_init_bus_range(struct dt_device_node *dev,
> +                                       struct pci_host_bridge *bridge,
> +                                       struct pci_config_window *cfg)
>  {
> -    int err, cfg_reg_idx;
>      u32 bus_range[2];
> -    paddr_t addr, size;
> -    struct pci_config_window *cfg;
> -
> -    cfg = xzalloc(struct pci_config_window);
> -    if ( !cfg )
> -        return NULL;
> +    int err;
>  
>      err = dt_property_read_u32_array(dev, "bus-range", bus_range,
>                                       ARRAY_SIZE(bus_range));
> @@ -82,6 +77,35 @@ gen_pci_init(struct dt_device_node *dev, const struct pci_ecam_ops *ops)
>          if ( cfg->busn_end > cfg->busn_start + 0xff )
>              cfg->busn_end = cfg->busn_start + 0xff;
>      }
> +}
> +
> +void __init pci_generic_init_bus_range_child(struct dt_device_node *dev,
> +                                             struct pci_host_bridge *bridge,
> +                                             struct pci_config_window *cfg)
> +{
> +    cfg->busn_start = bridge->cfg->busn_start + 1;
> +    cfg->busn_end = bridge->cfg->busn_end;
> +    bridge->cfg->busn_end = bridge->cfg->busn_start;

I think Stewart meant that pci_generic_init_bus_range_child should be
renamed pci_designware_init_bus_range_child and moved to
pci-designware.c.

However, given that we don't have a second user of this and I am not
certain how generic (or not) this bus_range_child function is, also
considering the other comments have been addressed:

Reviewed-by: Stefano Stabellini 

It can be moved later as appropriate if this turns out not to be generic
once we have a second user.


> +    printk(XENLOG_INFO "Root bus end updated: [bus %x-%x]\n",
> +           bridge->cfg->busn_start, bridge->cfg->busn_end);
> +}



From xen-devel-bounces@lists.xenproject.org Tue Jun 17 23:23:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 23:23:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018583.1395463 (Exim 4.92)
	(envelope-from )
	id 1uRfe0-0002Ps-8i; Tue, 17 Jun 2025 23:23:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018583.1395463; Tue, 17 Jun 2025 23:23: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 1uRfe0-0002Pl-60; Tue, 17 Jun 2025 23:23:08 +0000
Received: by outflank-mailman (input) for mailman id 1018583;
 Tue, 17 Jun 2025 23:23: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 1uRfdy-0002Pf-NU
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 23:23:07 +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 fd464b20-4bd1-11f0-b894-0df219b8e170;
 Wed, 18 Jun 2025 01:22:52 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 317C0A52036;
 Tue, 17 Jun 2025 23:22:51 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2A3D2C4CEE3;
 Tue, 17 Jun 2025 23:22: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: fd464b20-4bd1-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750202570;
	bh=lspH1xxD1aF2iqCdvDAZhEbXErSu7sxLWREDfLcDE+k=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=Gbd5DmBz+/nPQKGE2dx6gocLR43RQ3KZjcH23W51mO+HclORauxIoR8rV3S1Qj44Z
	 UzC4m9Eb/tmu+KQ1gvwRErcg5e1Esf+ntPZNtYtGABkeJosO8588NSoVcE6hBjxFw1
	 qDXRulEfFdg4oIBneN4HgHdhIxmo4yVxRzAzEw0iYkOcGk9rT0r/8Rk5n+uD9BXCVl
	 MQJxXCqygiWyL1hIyS22vQrzNxTwyjhM6zzekzl7sXKDMgTQnRgYzNIdxIzyKgjB25
	 pDW4+ru7B7uf8gwq8OnZBnlun9d/eTAu1x34TdhPq6DavBgcp0vXw12jgv1cKaPQXV
	 U8662OZOeNMWQ==
Date: Tue, 17 Jun 2025 16:22:47 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Oleksii Moisieiev 
cc: Stefano Stabellini , 
    "xen-devel@lists.xenproject.org" , 
    Andrew Cooper , 
    Anthony PERARD , 
    Bertrand Marquis , 
    Jan Beulich , Juergen Gross , 
    Julien Grall , Michal Orzel , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Volodymyr Babchuk , 
    Grygorii Strashko 
Subject: Re: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC
 multi-agent driver
In-Reply-To: <6080ff71-2634-4269-8a63-fdafdf03f01b@epam.com>
Message-ID: 
References:  <318044ae12f13b6b297b3f5fda577a1a6cd143da.1747669845.git.oleksii_moisieiev@epam.com> 
 <6080ff71-2634-4269-8a63-fdafdf03f01b@epam.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-165160365-1750201972=:1780597"
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-165160365-1750201972=:1780597
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: 8BIT
Content-ID: 

On Thu, 12 Jun 2025, Oleksii Moisieiev wrote:
> Hi Stefano,
> 
> I'm very sorry for a long silence. Please see my answers below:
> 
> 
> On 23/05/2025 23:06, Stefano Stabellini wrote:
> > One question for Bertrand below
> >
> >
> > On Mon, 19 May 2025, Oleksii Moisieiev wrote:
> >> This patch introduces SCI driver to support for ARM EL3 Trusted Firmware-A
> >> (TF-A) which provides SCMI interface with multi-agnet support, as shown
> >> below.
> >>
> >>    +-----------------------------------------+
> >>    |                                         |
> >>    | EL3 TF-A SCMI                           |
> >>    +-------+--+-------+--+-------+--+-------++
> >>    |shmem0 |  |shmem1 |  |shmem2 |  |shmemX |
> >>    +-----+-+  +---+---+  +--+----+  +---+---+
> >> smc-id0 |        |         |           |
> >> agent0  |        |         |           |
> >>    +-----v--------+---------+-----------+----+
> >>    |              |         |           |    |
> >>    |              |         |           |    |
> >>    +--------------+---------+-----------+----+
> >>           smc-id1 |  smc-id2|    smc-idX|
> >>           agent1  |  agent2 |    agentX |
> >>                   |         |           |
> >>              +----v---+  +--v-----+  +--v-----+
> >>              |        |  |        |  |        |
> >>              | Dom0   |  | Dom1   |  | DomX   |
> >>              |        |  |        |  |        |
> >>              |        |  |        |  |        |
> >>              +--------+  +--------+  +--------+
> >>
> >> The EL3 SCMI multi-agent firmware expected to provide SCMI SMC/HVC shared
> >> memory transport for every Agent in the system.
> >>
> >> The SCMI Agent transport channel defined by pair:
> >>   - smc-id: SMC/HVC id used for Doorbell
> >>   - shmem: shared memory for messages transfer, Xen page aligned,
> >>   p2m_mmio_direct_nc.
> >>
> >> The follwoing SCMI Agents expected to be defined by SCMI FW to enable SCMI
> >> multi-agent functionality under Xen:
> >> - Xen manegement agent: trusted agents that accesses to the Base Protocol
> >> commands to configure agent specific permissions
> >> - OSPM VM agents: non-trusted agent, one for each Guest domain which is
> >>    allowed direct HW access. At least one OSPM VM agent has to be provided
> >>    by FW if HW is handled only by Dom0 or Driver Domain.
> >>
> >> The EL3 SCMI FW expected to implement following Base protocol messages:
> >> - BASE_DISCOVER_AGENT
> >> - BASE_RESET_AGENT_CONFIGURATION (optional)
> >> - BASE_SET_DEVICE_PERMISSIONS (optional)
> >>
> >> The SCI SCMI SMC multi-agent driver implements following functionality:
> >> - It's initialized based on the Host DT SCMI node (only one SCMI interface
> >> is supported) which describes Xen management agent SCMI interface.
> >>
> >> scmi_shm_0 : sram@47ff0000 {
> >>      compatible = "arm,scmi-shmem";
> >>      reg = <0x0 0x47ff0000 0x0 0x1000>;
> >> };
> >> firmware {
> >>      scmi: scmi {
> >>          compatible = "arm,scmi-smc";
> >>          arm, smc - id = <0x82000002>; // Xen manegement agent smc-id
> > some extra spaces, it might be a copy/paste error
> +
> >>          \#address-cells = < 1>;
> >>          \#size-cells = < 0>;
> >>          \#access-controller - cells = < 1>;
> >>          shmem = <&scmi_shm_0>; // Xen manegement agent shmem
> >>
> >>          protocol@X{
> >>          };
> >>      };
> >> };
> >>
> >> - It obtains Xen specific SCMI Agent's configuration from the Host DT,
> >> probes Agents and build SCMI Agents list; The Agents configuration is taken from:
> >>
> >> chosen {
> >>    xen,scmi-secondary-agents = <
> >>              1 0x82000003 &scmi_shm_1
> >>              2 0x82000004 &scmi_shm_2
> >>              3 0x82000005 &scmi_shm_3
> >>              4 0x82000006 &scmi_shm_4>;
> >> }
> >>
> >> /{
> >>      scmi_shm_1: sram@47ff1000 {
> >>              compatible = "arm,scmi-shmem";
> >>              reg = <0x0 0x47ff1000 0x0 0x1000>;
> >>      };
> >>      scmi_shm_2: sram@47ff2000 {
> >>              compatible = "arm,scmi-shmem";
> >>              reg = <0x0 0x47ff2000 0x0 0x1000>;
> >>      };
> >>      scmi_shm_3: sram@47ff3000 {
> >>              compatible = "arm,scmi-shmem";
> >>              reg = <0x0 0x47ff3000 0x0 0x1000>;
> >>      };
> >> }
> >>    where first item is "agent_id", second - "arm,smc-id", and third - "arm,scmi-shmem" for
> >>    this agent_id.
> >>
> >>    Note that Xen is the only one entry in the system which need to know
> >>    about SCMI multi-agent support.
> >>
> >> - It implements the SCI subsystem interface required for configuring and
> >> enabling SCMI functionality for Dom0/hwdom and Guest domains. To enable
> >> SCMI functionality for domain it has to be configured with unique supported
> >> SCMI Agent_id and use corresponding SCMI SMC/HVC shared memory transport
> >> [smc-id, shmem] defined for this SCMI Agent_id.
> >> - Once Xen domain is configured it can communicate with EL3 SCMI FW:
> >>    -- zero-copy, the guest domain puts SCMI message in shmem;
> >>    -- the guest triggers SMC/HVC exception with smc-id (doorbell);
> >>    -- the Xen driver catches exception, do checks and synchronously forwards
> >>    it to EL3 FW.
> >> - the Xen driver sends BASE_RESET_AGENT_CONFIGURATION message to Xen
> >>    management agent channel on domain destroy event. This allows to reset
> >>    resources used by domain and so implement use-case like domain reboot.
> >>
> >> Dom0 Enable SCMI SMC:
> >>   - pass dom0_scmi_agent_id= in Xen command line. if not provided
> >>     SCMI will be disabled for Dom0 and all SCMI nodes removed from Dom0 DT.
> >>     The driver updates Dom0 DT SCMI node "arm,smc-id" value and fix up shmem
> >>     node according to assigned agent_id.
> >>
> >> Guest domains enable SCMI SMC:
> >>   - xl.cfg: add configuration option as below
> >>
> >>     arm_sci = "type=scmi_smc_multiagent,agent_id=2"
> >>
> >>   - xl.cfg: enable access to the "arm,scmi-shmem" which should correspond assigned agent_id for
> >>     the domain, for example:
> >>
> >> iomem = [
> >>      "47ff2,1@22001",
> >> ]
> > Looking at the code and the configuration options, it looks like it is
> > possible to map a scmi-shmem channel at a different address for the
> > guest. It seems like it would work. Is that correct?
> >
> Yes it will. in our case address 22001000 should be the save as
> sram@22001000 in the domain device-tree.
> >>   - DT: add SCMI nodes to the Driver domain partial device tree as in the
> >>   below example. The "arm,smc-id" should correspond assigned agent_id for the domain:
> >>
> >> passthrough {
> >>     scmi_shm_0: sram@22001000 {
> >>         compatible = "arm,scmi-shmem";
> >>         reg = <0x0 0x22001000 0x0 0x1000>;
> >>     };
> >>
> >>     firmware {
> >>          compatible = "simple-bus";
> >>              scmi: scmi {
> >>                  compatible = "arm,scmi-smc";
> >>                  arm,smc-id = <0x82000004>;
> >>                  shmem = <&scmi_shm_0>;
> >>                  ...
> >>              }
> >>      }
> >> }
> >>
> >> SCMI "4.2.1.1 Device specific access control"
> >>
> >> The XEN SCI SCMI SMC multi-agent driver performs "access-controller" provider function
> >> in case EL3 SCMI FW implements SCMI "4.2.1.1 Device specific access control" and provides the
> >> BASE_SET_DEVICE_PERMISSIONS command to configure the devices that an agents have access to.
> >> The DT SCMI node should "#access-controller-cells=<1>" property and DT devices should be bound
> >> to the Xen SCMI.
> >>
> >> &i2c1 {
> >>      access-controllers = <&scmi 0>;
> >> };
> >>
> >> The Dom0 and dom0less domains DT devices will be processed automatically through
> >> sci_assign_dt_device() call, but to assign SCMI devices from toolstack the xl.cfg:"dtdev" property
> >> shell be used:
> >>
> >> dtdev = [
> >>      "/soc/i2c@e6508000",
> >> ]
> >>
> >> xl.cfg:dtdev will contain all nodes which are under SCMI management (not only those which are behind IOMMU).
> >>
> >> [1]https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> >> [2]https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/access-controllers/access-controllers.yaml
> >> Signed-off-by: Oleksii Moisieiev
> >> Signed-off-by: Grygorii Strashko
> > Thanks for the long explanation, great work! I am really looking forward
> > to have this feature in the tree soon.
> >
> >
> >> ---
> >>
> >> Changes in v4:
> >> - toolstack comments from Anthony PERARD
> >> - added dom0less support
> >> - added doc for "xen,scmi-secondary-agents"
> >>
> >>   docs/man/xl.cfg.5.pod.in                    |  13 +
> >>   docs/misc/arm/device-tree/booting.txt       |  60 ++
> >>   docs/misc/xen-command-line.pandoc           |   9 +
> >>   tools/libs/light/libxl_arm.c                |   4 +
> >>   tools/libs/light/libxl_types.idl            |   4 +-
> >>   tools/xl/xl_parse.c                         |  12 +
> >>   xen/arch/arm/dom0less-build.c               |  11 +
> >>   xen/arch/arm/domain_build.c                 |   3 +-
> >>   xen/arch/arm/firmware/Kconfig               |  11 +
> >>   xen/arch/arm/firmware/Makefile              |   1 +
> >>   xen/arch/arm/firmware/scmi-proto.h          | 164 ++++
> >>   xen/arch/arm/firmware/scmi-shmem.c          | 173 ++++
> >>   xen/arch/arm/firmware/scmi-shmem.h          |  45 +
> >>   xen/arch/arm/firmware/scmi-smc-multiagent.c | 860 ++++++++++++++++++++
> >>   xen/include/public/arch-arm.h               |   3 +
> >>   15 files changed, 1371 insertions(+), 2 deletions(-)
> >>   create mode 100644 xen/arch/arm/firmware/scmi-proto.h
> >>   create mode 100644 xen/arch/arm/firmware/scmi-shmem.c
> >>   create mode 100644 xen/arch/arm/firmware/scmi-shmem.h
> >>   create mode 100644 xen/arch/arm/firmware/scmi-smc-multiagent.c
> >>
> >> diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> >> index 1ccf50b8ea..302c46d8bc 100644
> >> --- a/docs/man/xl.cfg.5.pod.in
> >> +++ b/docs/man/xl.cfg.5.pod.in
> >> @@ -3122,8 +3122,21 @@ single SCMI OSPM agent support.
> >>   Should be used together with B Xen command line
> >>   option.
> >>
> >> +=item B
> >> +
> >> +Enables ARM SCMI SMC multi-agent support for the guest by enabling SCMI over
> >> +SMC calls forwarding from domain to the EL3 firmware (like Trusted Firmware-A)
> >> +with a multi SCMI OSPM agent support. The SCMI B should be
> >> +specified for the guest.
> >> +
> >>   =back
> >>
> >> +=item B
> >> +
> >> +Specifies a non-zero ARM SCI agent id for the guest. This option is mandatory
> >> +if the SCMI SMC support is enabled for the guest. The agent ids of domains
> >> +existing on a single host must be unique and in the range [1..255].
> >> +
> >>   =back
> >>
> >>   =back
> >> diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
> >> index 8943c04173..c8923ab8b2 100644
> >> --- a/docs/misc/arm/device-tree/booting.txt
> >> +++ b/docs/misc/arm/device-tree/booting.txt
> >> @@ -296,6 +296,20 @@ with the following properties:
> >>       Should be used together with dom0_scmi_smc_passthrough Xen command line
> >>       option.
> >>
> >> +    - "scmi_smc_multiagent"
> >> +
> >> +    Enables ARM SCMI SMC multi-agent support for the guest by enabling SCMI over
> >> +    SMC calls forwarding from domain to the EL3 firmware (like ARM
> >> +    Trusted Firmware-A) with a multi SCMI OSPM agent support.
> >> +    The SCMI agent_id should be specified for the guest with "xen,sci_agent_id"
> >> +    property.
> >> +
> >> +- "xen,sci_agent_id"
> >> +
> >> +    Specifies a non-zero ARM SCI agent id for the guest. This option is
> >> +    mandatory if the SCMI SMC "scmi_smc_multiagent" support is enabled for
> >> +    the guest. The agent ids of guest must be unique and in the range [1..255].
> >> +
> >>   Under the "xen,domain" compatible node, one or more sub-nodes are present
> >>   for the DomU kernel and ramdisk.
> >>
> >> @@ -764,3 +778,49 @@ The automatically allocated static shared memory will get mapped at
> >>   0x80000000 in DomU1 guest physical address space, and at 0x90000000 in DomU2
> >>   guest physical address space. DomU1 is explicitly defined as the owner domain,
> >>   and DomU2 is the borrower domain.
> >> +
> >> +SCMI SMC multi-agent support
> >> +============================
> >> +
> >> +For enabling the ARM SCMI SMC multi-agent support (enabled by CONFIG_SCMI_SMC_MA)
> >> +the Xen specific SCMI Agent's configuration shell be provided in the Host DT
> >> +according to the SCMI compliant EL3 Firmware specification with
> >> +ARM SMC/HVC transport using property "xen,scmi-secondary-agents" under
> >> +the top-level "chosen" node:
> >> +
> >> +- xen,scmi-secondary-agents
> >> +
> >> +    Defines a set of SCMI agents configuration supported by SCMI EL3 FW and
> >> +    available for Xen. Each Agent defined as triple consisting of:
> >> +    SCMI agent_id,
> >> +    SMC/HVC function_id assigned for the agent transport ("arm,smc-id"),
> >> +    phandle to SCMI SHM assigned for the agent transport ("arm,scmi-shmem").
> >> +
> >> +As an example:
> >> +
> >> +chosen {
> >> +    xen,scmi-secondary-agents = <
> >> +        1 0x82000003 &scmi_shm_1
> >> +        2 0x82000004 &scmi_shm_2
> >> +        3 0x82000005 &scmi_shm_3
> >> +        4 0x82000006 &scmi_shm_4>;
> >> +}
> > NIT: it should be };
> +
> > Looking at scmi_probe, collect_agents, and the following SCMI
> > SCMI_BASE_DISCOVER_AGENT request, I wonder: do we actually need this
> > information?
> >
> > It looks like we can discover the agend_ids for every channel, I guess
> > what we need to know is the shmem location for every channel? But the
> > full list of shmem channel is available below thanks to the scmi-shmem
> > nodes.
> >
> > So, we have the list of scmi-shmem anyway, and we can probe the
> > agent_id. The only parameter left is the smc_id/func_id.
> >
> > Or maybe smc_id/func_id can be calculated from agent_id?
> >
> > I am asking mostly because if a user is supposed to add this
> > xen,scmi-secondary-agents property, where are they supposed to find the
> > smc_id/func_id information?
> >
> > It is important that we write down in this document how the user is
> > expected to find out what 1 is 0x82000003 which is scmi_shm_1.
> 
> That's a very good question! The issue here is that there are no
> 
> explicit requirements defining the relationship between agent_id and
> func_id.
> 
> 
> For example, in ARM-TF, different implementations can use different
> func_ids.
> 
> To provide better flexibility, we decided to separate agent_id from func_id.
> 
> 
> Currently, the SCMI_BASE_DISCOVER_AGENT calls from the probe are intended to
> 
> verify that all registered agents are present and that the configuration
> is correct.
> 
> However, I understand that this additional validation could be optional
> to save traffic.
> 
> 
> To address this, I’m considering adding a configuration option, such as
> 
> CONFIG_SCMI_AGENT_VALIDATION, which can be disabled to reduce boot time
> if this
> 
> validation is not necessary for certain use cases.
> 
> 
> Lastly, I’ll be updating the document to include clearer information
> about the
> 
> relationship between func_id and agent_id in the upcoming v5.
 
The key point here is to make it easier for the user. If we can make
agent_id or func_id optional it would make users lives easier.

Alternative, or in addition to this, we should make the docs as clear as
possible so that people can figure it out without having to ask
questions on xen-devel.

 
> >> +/{
> >> +        scmi_shm_1: sram@47ff1000 {
> >> +                compatible = "arm,scmi-shmem";
> >> +                reg = <0x0 0x47ff1000 0x0 0x1000>;
> >> +        };
> >> +        scmi_shm_2: sram@47ff2000 {
> >> +                compatible = "arm,scmi-shmem";
> >> +                reg = <0x0 0x47ff2000 0x0 0x1000>;
> >> +        };
> >> +        scmi_shm_3: sram@47ff3000 {
> >> +                compatible = "arm,scmi-shmem";
> >> +                reg = <0x0 0x47ff3000 0x0 0x1000>;
> >> +        };
> >> +        scmi_shm_3: sram@47ff4000 {
> >> +                compatible = "arm,scmi-shmem";
> >> +                reg = <0x0 0x47ff4000 0x0 0x1000>;
> >> +        };
> > Are these scmi_shm_1 - scmi_shm_3 under the top level device tree node?
> > Or are under /firmware? Or are they under /chosen?
> >
> > I take they are under the top level node together with scmi_shm_0?
> >
> > Can you please also clarify in the document as well?
> >
> >
> all these nodes are on the top level of the device-tree. But there is no
> specific place for them.
> 
> They could be subnodes to some memory-region for example. I will clarify
> this.
> 
> >> +}
> >> diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
> >> index 8e50f6b7c7..bc3c64d6ec 100644
> >> --- a/docs/misc/xen-command-line.pandoc
> >> +++ b/docs/misc/xen-command-line.pandoc
> >> @@ -1091,6 +1091,15 @@ which serves as Driver domain. The SCMI will be disabled for Dom0/hwdom and
> >>   SCMI nodes removed from Dom0/hwdom device tree.
> >>   (for example, thin Dom0 with Driver domain use-case).
> >>
> >> +### dom0_scmi_agent_id (ARM)
> >> +> `= `
> >> +
> >> +The option is available when `CONFIG_SCMI_SMC_MA` is compiled in, and allows to
> >> +enable SCMI functionality for Dom0 by specifying a non-zero ARM SCMI agent id.
> >> +The SCMI will be disabled for Dom0 if this option is not specified
> >> +(for example, thin Dom0 or dom0less use-cases).
> >> +The agent ids of domains existing on a single host must be unique.
> >> +
> >>   ### dtuart (ARM)
> >>   > `= path [:options]`
> >>
> >> diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
> >> index 28ba9eb787..7712f53cd4 100644
> >> --- a/tools/libs/light/libxl_arm.c
> >> +++ b/tools/libs/light/libxl_arm.c
> >> @@ -229,6 +229,10 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
> >>       case LIBXL_ARM_SCI_TYPE_SCMI_SMC:
> >>           config->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC;
> >>           break;
> >> +    case LIBXL_ARM_SCI_TYPE_SCMI_SMC_MULTIAGENT:
> >> +        config->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA;
> >> +        config->arch.arm_sci_agent_id = d_config->b_info.arch_arm.arm_sci.agent_id;
> >> +        break;
> >>       default:
> >>           LOG(ERROR, "Unknown ARM_SCI type %d",
> >>               d_config->b_info.arch_arm.arm_sci.type);
> >> diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl
> >> index aa2190ab5b..11e31ce786 100644
> >> --- a/tools/libs/light/libxl_types.idl
> >> +++ b/tools/libs/light/libxl_types.idl
> >> @@ -553,11 +553,13 @@ libxl_sve_type = Enumeration("sve_type", [
> >>
> >>   libxl_arm_sci_type = Enumeration("arm_sci_type", [
> >>       (0, "none"),
> >> -    (1, "scmi_smc")
> >> +    (1, "scmi_smc"),
> >> +    (2, "scmi_smc_multiagent")
> >>       ], init_val = "LIBXL_ARM_SCI_TYPE_NONE")
> >>
> >>   libxl_arm_sci = Struct("arm_sci", [
> >>       ("type", libxl_arm_sci_type),
> >> +    ("agent_id", uint8)
> >>       ])
> >>
> >>   libxl_rdm_reserve = Struct("rdm_reserve", [
> >> diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
> >> index bd22be9d33..81aa3797e3 100644
> >> --- a/tools/xl/xl_parse.c
> >> +++ b/tools/xl/xl_parse.c
> >> @@ -1306,6 +1306,18 @@ static int parse_arm_sci_config(XLU_Config *cfg, libxl_arm_sci *arm_sci,
> >>               }
> >>           }
> >>
> >> +        if (MATCH_OPTION("agent_id", ptr, oparg)) {
> >> +            unsigned long val = parse_ulong(oparg);
> >> +
> >> +            if (!val || val > 255) {
> >> +                fprintf(stderr, "An invalid ARM_SCI agent_id specified (%lu). Valid range [1..255]\n",
> >> +                        val);
> >> +                ret = ERROR_INVAL;
> >> +                goto parse_error;
> >> +            }
> >> +            arm_sci->agent_id = val;
> >> +        }
> >> +
> >>           ptr = strtok(NULL, ",");
> >>       }
> >>
> >> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
> >> index 0a00f03a25..43d21eb889 100644
> >> --- a/xen/arch/arm/dom0less-build.c
> >> +++ b/xen/arch/arm/dom0less-build.c
> >> @@ -835,6 +835,17 @@ int __init domu_dt_sci_parse(struct dt_device_node *node,
> >>           d_cfg->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_NONE;
> >>       else if ( !strcmp(sci_type, "scmi_smc") )
> >>           d_cfg->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC;
> >> +    else if ( !strcmp(sci_type, "scmi_smc_multiagent") )
> >> +    {
> >> +        uint32_t agent_id = 0;
> >> +
> >> +        if ( !dt_property_read_u32(node, "xen,sci_agent_id", &agent_id) ||
> >> +             !agent_id )
> > shouldn't we check that agent_id <= 255 ?
> 
> I see no limitation about max agent_id in DEN0056E document, it's uint32_t.
> 
> >> +            return -EINVAL;
> >> +
> >> +        d_cfg->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA;
> >> +        d_cfg->arch.arm_sci_agent_id = agent_id;
> >> +    }
> >>       else
> >>       {
> >>           printk(XENLOG_ERR "xen,sci_type in not valid (%s) for domain %s\n",
> >> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> >> index 36d28b52a4..0c9274a2b3 100644
> >> --- a/xen/arch/arm/domain_build.c
> >> +++ b/xen/arch/arm/domain_build.c
> >> @@ -616,7 +616,8 @@ static int __init write_properties(struct domain *d, struct kernel_info *kinfo,
> >>                    dt_property_name_is_equal(prop, "linux,uefi-mmap-start") ||
> >>                    dt_property_name_is_equal(prop, "linux,uefi-mmap-size") ||
> >>                    dt_property_name_is_equal(prop, "linux,uefi-mmap-desc-size") ||
> >> -                 dt_property_name_is_equal(prop, "linux,uefi-mmap-desc-ver"))
> >> +                 dt_property_name_is_equal(prop, "linux,uefi-mmap-desc-ver") ||
> >> +                 dt_property_name_is_equal(prop, "xen,scmi-secondary-agents") )
> >>                   continue;
> >>
> >>               if ( dt_property_name_is_equal(prop, "xen,dom0-bootargs") ) diff --git a/xen/arch/arm/firmware/Kconfig
> >> b/xen/arch/arm/firmware/Kconfig index 5c5f0880c4..6b051c8ada 100644
> >> --- a/xen/arch/arm/firmware/Kconfig +++
> >> b/xen/arch/arm/firmware/Kconfig @@ -29,6 +29,17 @@ config SCMI_SMC
> >> driver domain. Use with EL3 firmware which supports only single SCMI
> >> OSPM agent. +config SCMI_SMC_MA + bool "Enable ARM SCMI SMC multi-agent driver"
> >> +    select ARM_SCI
> >> +    help
> >> +      Enables SCMI SMC/HVC multi-agent in XEN to pass SCMI requests from Domains
> >> +      to EL3 firmware (TF-A) which supports multi-agent feature.
> >> +      This feature allows to enable SCMI per Domain using unique SCMI agent_id,
> >> +      so Domain is identified by EL3 firmware as an SCMI Agent and can access
> >> +      allowed platform resources through dedicated SMC/HVC Shared memory based
> >> +      transport.
> >> +
> >>   endchoice
> >>
> >>   endmenu
> >> diff --git a/xen/arch/arm/firmware/Makefile b/xen/arch/arm/firmware/Makefile
> >> index 71bdefc24a..37927e690e 100644
> >> --- a/xen/arch/arm/firmware/Makefile
> >> +++ b/xen/arch/arm/firmware/Makefile
> >> @@ -1,2 +1,3 @@
> >>   obj-$(CONFIG_ARM_SCI) += sci.o
> >>   obj-$(CONFIG_SCMI_SMC) += scmi-smc.o
> >> +obj-$(CONFIG_SCMI_SMC_MA) += scmi-shmem.o scmi-smc-multiagent.o
> >> diff --git a/xen/arch/arm/firmware/scmi-proto.h b/xen/arch/arm/firmware/scmi-proto.h
> >> new file mode 100644
> >> index 0000000000..3f4b9c5d6b
> >> --- /dev/null
> >> +++ b/xen/arch/arm/firmware/scmi-proto.h
> >> @@ -0,0 +1,164 @@
> >> +/* SPDX-License-Identifier: GPL-2.0-only */
> >> +/*
> >> + * Arm System Control and Management Interface definitions
> >> + * Version 3.0 (DEN0056C)
> >> + *
> >> + * Copyright (c) 2024 EPAM Systems
> >> + */
> >> +
> >> +#ifndef XEN_ARCH_ARM_SCI_SCMI_PROTO_H_
> >> +#define XEN_ARCH_ARM_SCI_SCMI_PROTO_H_
> > NIT: ARM_FIRMWARE_SCMI_PROTO_H
> +
> >> +#include 
> >> +
> >> +#define SCMI_SHORT_NAME_MAX_SIZE 16
> >> +
> >> +/* SCMI status codes. See section 4.1.4 */
> >> +#define SCMI_SUCCESS              0
> >> +#define SCMI_NOT_SUPPORTED      (-1)
> >> +#define SCMI_INVALID_PARAMETERS (-2)
> >> +#define SCMI_DENIED             (-3)
> >> +#define SCMI_NOT_FOUND          (-4)
> >> +#define SCMI_OUT_OF_RANGE       (-5)
> >> +#define SCMI_BUSY               (-6)
> >> +#define SCMI_COMMS_ERROR        (-7)
> >> +#define SCMI_GENERIC_ERROR      (-8)
> >> +#define SCMI_HARDWARE_ERROR     (-9)
> >> +#define SCMI_PROTOCOL_ERROR     (-10)
> >> +
> >> +/* Protocol IDs */
> >> +#define SCMI_BASE_PROTOCOL 0x10
> >> +
> >> +/* Base protocol message IDs */
> >> +#define SCMI_BASE_PROTOCOL_VERSION            0x0
> >> +#define SCMI_BASE_PROTOCOL_ATTIBUTES          0x1
> >> +#define SCMI_BASE_PROTOCOL_MESSAGE_ATTRIBUTES 0x2
> >> +#define SCMI_BASE_DISCOVER_AGENT              0x7
> >> +#define SCMI_BASE_SET_DEVICE_PERMISSIONS      0x9
> >> +#define SCMI_BASE_RESET_AGENT_CONFIGURATION   0xB
> >> +
> >> +typedef struct scmi_msg_header {
> >> +    uint8_t id;
> >> +    uint8_t type;
> >> +    uint8_t protocol;
> >> +    uint32_t status;
> >> +} scmi_msg_header_t;
> >> +
> >> +/* Table 2 Message header format */
> >> +#define SCMI_HDR_ID    GENMASK(7, 0)
> >> +#define SCMI_HDR_TYPE  GENMASK(9, 8)
> >> +#define SCMI_HDR_PROTO GENMASK(17, 10)
> >> +
> >> +#define SCMI_FIELD_GET(_mask, _reg)                                            \
> >> +    ((typeof(_mask))(((_reg) & (_mask)) >> (ffs64(_mask) - 1)))
> >> +#define SCMI_FIELD_PREP(_mask, _val)                                           \
> >> +    (((typeof(_mask))(_val) << (ffs64(_mask) - 1)) & (_mask))
> >> +
> >> +static inline uint32_t pack_scmi_header(scmi_msg_header_t *hdr)
> >> +{
> >> +    return SCMI_FIELD_PREP(SCMI_HDR_ID, hdr->id) |
> >> +           SCMI_FIELD_PREP(SCMI_HDR_TYPE, hdr->type) |
> >> +           SCMI_FIELD_PREP(SCMI_HDR_PROTO, hdr->protocol);
> >> +}
> >> +
> >> +static inline void unpack_scmi_header(uint32_t msg_hdr, scmi_msg_header_t *hdr)
> >> +{
> >> +    hdr->id = SCMI_FIELD_GET(SCMI_HDR_ID, msg_hdr);
> >> +    hdr->type = SCMI_FIELD_GET(SCMI_HDR_TYPE, msg_hdr);
> >> +    hdr->protocol = SCMI_FIELD_GET(SCMI_HDR_PROTO, msg_hdr);
> >> +}
> >> +
> >> +static inline int scmi_to_xen_errno(int scmi_status)
> >> +{
> >> +    if ( scmi_status == SCMI_SUCCESS )
> >> +        return 0;
> >> +
> >> +    switch ( scmi_status )
> >> +    {
> >> +    case SCMI_NOT_SUPPORTED:
> >> +        return -EOPNOTSUPP;
> >> +    case SCMI_INVALID_PARAMETERS:
> >> +        return -EINVAL;
> >> +    case SCMI_DENIED:
> >> +        return -EACCES;
> >> +    case SCMI_NOT_FOUND:
> >> +        return -ENOENT;
> >> +    case SCMI_OUT_OF_RANGE:
> >> +        return -ERANGE;
> >> +    case SCMI_BUSY:
> >> +        return -EBUSY;
> >> +    case SCMI_COMMS_ERROR:
> >> +        return -ENOTCONN;
> >> +    case SCMI_GENERIC_ERROR:
> >> +        return -EIO;
> >> +    case SCMI_HARDWARE_ERROR:
> >> +        return -ENXIO;
> >> +    case SCMI_PROTOCOL_ERROR:
> >> +        return -EBADMSG;
> >> +    default:
> >> +        return -EINVAL;
> >> +    }
> >> +}
> >> +
> >> +/* PROTOCOL_VERSION */
> >> +#define SCMI_VERSION_MINOR GENMASK(15, 0)
> >> +#define SCMI_VERSION_MAJOR GENMASK(31, 16)
> >> +
> >> +struct scmi_msg_prot_version_p2a {
> >> +    uint32_t version;
> >> +} __packed;
> >> +
> >> +/* BASE PROTOCOL_ATTRIBUTES */
> >> +#define SCMI_BASE_ATTR_NUM_PROTO GENMASK(7, 0)
> >> +#define SCMI_BASE_ATTR_NUM_AGENT GENMASK(15, 8)
> >> +
> >> +struct scmi_msg_base_attributes_p2a {
> >> +    uint32_t attributes;
> >> +} __packed;
> >> +
> >> +/*
> >> + * BASE_DISCOVER_AGENT
> >> + */
> >> +#define SCMI_BASE_AGENT_ID_OWN 0xFFFFFFFF
> >> +
> >> +struct scmi_msg_base_discover_agent_a2p {
> >> +    uint32_t agent_id;
> >> +} __packed;
> >> +
> >> +struct scmi_msg_base_discover_agent_p2a {
> >> +    uint32_t agent_id;
> >> +    char name[SCMI_SHORT_NAME_MAX_SIZE];
> >> +} __packed;
> >> +
> >> +/*
> >> + * BASE_SET_DEVICE_PERMISSIONS
> >> + */
> >> +#define SCMI_BASE_DEVICE_ACCESS_ALLOW           BIT(0, UL)
> >> +
> >> +struct scmi_msg_base_set_device_permissions_a2p {
> >> +    uint32_t agent_id;
> >> +    uint32_t device_id;
> >> +    uint32_t flags;
> >> +} __packed;
> >> +
> >> +/*
> >> + * BASE_RESET_AGENT_CONFIGURATION
> >> + */
> >> +#define SCMI_BASE_AGENT_PERMISSIONS_RESET       BIT(0, UL)
> >> +
> >> +struct scmi_msg_base_reset_agent_cfg_a2p {
> >> +    uint32_t agent_id;
> >> +    uint32_t flags;
> >> +} __packed;
> >> +
> >> +#endif /* XEN_ARCH_ARM_SCI_SCMI_PROTO_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/arch/arm/firmware/scmi-shmem.c b/xen/arch/arm/firmware/scmi-shmem.c
> >> new file mode 100644
> >> index 0000000000..dd613ee0b5
> >> --- /dev/null
> >> +++ b/xen/arch/arm/firmware/scmi-shmem.c
> >> @@ -0,0 +1,173 @@
> >> +/* SPDX-License-Identifier: GPL-2.0-only */
> >> +/*
> >> + * SCI SCMI multi-agent driver, using SMC/HVC shmem as transport.
> >> + *
> >> + * Oleksii Moisieiev
> >> + * Copyright (c) 2025 EPAM Systems
> >> + */
> >> +/* SPDX-License-Identifier: GPL-2.0-only */
> >> +
> >> +#include 
> >> +#include 
> >> +
> >> +#include "scmi-proto.h"
> >> +#include "scmi-shmem.h"
> > This code is written more generically than the description implies. If
> > we only want to make SMC calls to TF-A on EL3 and exchange data with it
> > over shared memory, then I think:
> > - we don't need the __iomem tag, as there is no MMIO
> > - we only need a DMB, not a DSB (readl and writel imply DSB, use only
> >    readl_relaxed and writel_relaxed)
> >
> > On the other hand, if we also want to handle the case where the SCMI
> > server could be on a separate co-processor, then what this code is doing
> > is not sufficient because we also need a dcache flush, in addition to
> > the DSB.
> >
> > Bertrand, can you double-check?
> >
> >
> >> +/*
> >> + * Copy data from IO memory space to "real" memory space.
> >> + */
> >> +static void __memcpy_fromio(void *to, const volatile void __iomem *from,
> >> +                            size_t count)
> >> +{
> >> +    while ( count && !IS_ALIGNED((unsigned long)from, 4) )
> >> +    {
> >> +        *(u8 *)to = readb_relaxed(from);
> >> +        from++;
> >> +        to++;
> >> +        count--;
> >> +    }
> >> +
> >> +    while ( count >= 4 )
> >> +    {
> >> +        *(u32 *)to = readl_relaxed(from);
> >> +        from += 4;
> >> +        to += 4;
> >> +        count -= 4;
> >> +    }
> >> +
> >> +    while ( count )
> >> +    {
> >> +        *(u8 *)to = readb_relaxed(from);
> >> +        from++;
> >> +        to++;
> >> +        count--;
> >> +    }
> >> +}
> >> +
> >> +/*
> >> + * Copy data from "real" memory space to IO memory space.
> >> + */
> >> +static void __memcpy_toio(volatile void __iomem *to, const void *from,
> >> +                          size_t count)
> >> +{
> >> +    while ( count && !IS_ALIGNED((unsigned long)to, 4) )
> >> +    {
> >> +        writeb_relaxed(*(u8 *)from, to);
> >> +        from++;
> >> +        to++;
> >> +        count--;
> >> +    }
> >> +
> >> +    while ( count >= 4 )
> >> +    {
> >> +        writel_relaxed(*(u32 *)from, to);
> >> +        from += 4;
> >> +        to += 4;
> >> +        count -= 4;
> >> +    }
> >> +
> >> +    while ( count )
> >> +    {
> >> +        writeb_relaxed(*(u8 *)from, to);
> >> +        from++;
> >> +        to++;
> >> +        count--;
> >> +    }
> >> +}
> > I don't understand why we need __memcpy_fromio and __memcpy_toio: can't
> > we use a simple memcpy?
> 
> This approach was used because we're trying to access shared memory
> between two independent systems:
> 
> Arm-TF and Xen in our case which places some chunks of data to the same
> memory. And, according to the [0]
> 
> ```
> 
> Some devices (such as framebuffers) would like to use larger transfers than
> 8 bytes at a time. For these devices, the memcpy_toio(),
> memcpy_fromio() and memset_io() functions are
> provided. Do not use memset or memcpy on IO addresses; they are not
> guaranteed to copy data in order.
> 
> ```
> 
> Also, the same approach was used by Arm team when introducing scmi
> driver to the Linux kernel [1]
> 
> 
> [0]: https://www.kernel.org/doc/Documentation/driver-api/device-io.rst
> 
> [1]:https://git.iliana.fyi/linux/patch/?id=d5141f37c42e0b833863f157ac4cee203b2ba3d2


Keep in mind that [0] refers specifically to access to MMIO regions. I
assume that the SCMI shared buffers are on normal memory? Regarding [1],
it makes sense if Linux is trying to support shared memory over MMIO.

Looking at one of your replies below, I am guessing the memory buffers
are actually in normal memory but the issue is that TF-A is mapping them
as uncacheable. Is that correct?

In that case, I still don't understand why a simple memcpy would not be
sufficient. Can you check?

If yes, then for now I would just simplify it down to memcpy. When
someone adds support for an SCMI server elsewhere we could look into
adding a more sophisticated memcpy and we can look at the details at
that point in time. Specifically, I am not convinced that memcpy_toio
and memcpy_fromio would work if the SCMI server is on a separate
non-coherent microcontroller.


> >> +static inline int
> >> +shmem_channel_is_free(const volatile struct scmi_shared_mem __iomem *shmem)
> >> +{
> >> +    return (readl(&shmem->channel_status) &
> >> +            SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE) ? 0 : -EBUSY;
> >> +}
> >> +
> >> +int shmem_put_message(volatile struct scmi_shared_mem __iomem *shmem,
> >> +                      scmi_msg_header_t *hdr, void *data, int len)
> >> +{
> >> +    int ret;
> >> +
> >> +    if ( (len + sizeof(shmem->msg_header)) > SCMI_SHMEM_MAPPED_SIZE )
> >> +    {
> >> +        printk(XENLOG_ERR "scmi: Wrong size of smc message. Data is invalid\n");
> >> +        return -EINVAL;
> >> +    }
> >> +
> >> +    ret = shmem_channel_is_free(shmem);
> >> +    if ( ret )
> >> +        return ret;
> >> +
> >> +    writel_relaxed(0x0, &shmem->channel_status);
> >> +    /* Writing 0x0 right now, but "shmem"_FLAG_INTR_ENABLED can be set */
> >> +    writel_relaxed(0x0, &shmem->flags);
> >> +    writel_relaxed(sizeof(shmem->msg_header) + len, &shmem->length);
> >> +    writel(pack_scmi_header(hdr), &shmem->msg_header);
> >> +
> >> +    if ( len > 0 && data )
> >> +        __memcpy_toio(shmem->msg_payload, data, len);
> >> +
> >> +    return 0;
> >> +}
> >> +
> >> +int shmem_get_response(const volatile struct scmi_shared_mem __iomem *shmem,
> >> +                       scmi_msg_header_t *hdr, void *data, int len)
> >> +{
> >> +    int recv_len;
> >> +    int ret;
> >> +    int pad = sizeof(hdr->status);
> >> +
> >> +    if ( len >= SCMI_SHMEM_MAPPED_SIZE - sizeof(shmem) )
> >> +    {
> >> +        printk(XENLOG_ERR
> >> +               "scmi: Wrong size of input smc message. Data may be invalid\n");
> >> +        return -EINVAL;
> >> +    }
> >> +
> >> +    ret = shmem_channel_is_free(shmem);
> >> +    if ( ret )
> >> +        return ret;
> >> +
> >> +    recv_len = readl(&shmem->length) - sizeof(shmem->msg_header);
> >> +
> >> +    if ( recv_len < 0 )
> >> +    {
> >> +        printk(XENLOG_ERR
> >> +               "scmi: Wrong size of smc message. Data may be invalid\n");
> >> +        return -EINVAL;
> >> +    }
> >> +
> >> +    unpack_scmi_header(readl(&shmem->msg_header), hdr);
> >> +
> >> +    hdr->status = readl(&shmem->msg_payload);
> >> +    recv_len = recv_len > pad ? recv_len - pad : 0;
> >> +
> >> +    ret = scmi_to_xen_errno(hdr->status);
> >> +    if ( ret )
> >> +    {
> >> +        printk(XENLOG_DEBUG "scmi: Error received: %d\n", ret);
> >> +        return ret;
> >> +    }
> >> +
> >> +    if ( recv_len > len )
> >> +    {
> >> +        printk(XENLOG_ERR
> >> +               "scmi: Not enough buffer for message %d, expecting %d\n",
> >> +               recv_len, len);
> >> +        return -EINVAL;
> >> +    }
> >> +
> >> +    if ( recv_len > 0 )
> >> +        __memcpy_fromio(data, shmem->msg_payload + pad, recv_len);
> >> +
> >> +    return 0;
> >> +}
> >> +
> >> +/*
> >> + * 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/firmware/scmi-shmem.h b/xen/arch/arm/firmware/scmi-shmem.h
> >> new file mode 100644
> >> index 0000000000..2f8e23ff76
> >> --- /dev/null
> >> +++ b/xen/arch/arm/firmware/scmi-shmem.h
> >> @@ -0,0 +1,45 @@
> >> +/* SPDX-License-Identifier: GPL-2.0-only */
> >> +/*
> >> + * Arm System Control and Management Interface definitions
> >> + * Version 3.0 (DEN0056C)
> >> + * Shared Memory based Transport
> >> + *
> >> + * Copyright (c) 2024 EPAM Systems
> >> + */
> >> +
> >> +#ifndef XEN_ARCH_ARM_SCI_SCMI_SHMEM_H_
> >> +#define XEN_ARCH_ARM_SCI_SCMI_SHMEM_H_
> > NIT: ARM_FIRMWARE_SCMI_SHMEM_H
> >
> +
> >> +#include 
> >> +
> >> +#define SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE  BIT(0, UL)
> >> +#define SCMI_SHMEM_CHAN_STAT_CHANNEL_ERROR BIT(1, UL)
> >> +
> >> +struct scmi_shared_mem {
> >> +    uint32_t reserved;
> >> +    uint32_t channel_status;
> >> +    uint32_t reserved1[2];
> >> +    uint32_t flags;
> >> +    uint32_t length;
> >> +    uint32_t msg_header;
> >> +    uint8_t msg_payload[];
> >> +};
> >> +
> >> +#define SCMI_SHMEM_MAPPED_SIZE PAGE_SIZE
> >> +
> >> +int shmem_put_message(volatile struct scmi_shared_mem __iomem *shmem,
> >> +                      scmi_msg_header_t *hdr, void *data, int len);
> >> +
> >> +int shmem_get_response(const volatile struct scmi_shared_mem __iomem *shmem,
> >> +                       scmi_msg_header_t *hdr, void *data, int len);
> >> +#endif /* XEN_ARCH_ARM_SCI_SCMI_SHMEM_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/arch/arm/firmware/scmi-smc-multiagent.c b/xen/arch/arm/firmware/scmi-smc-multiagent.c
> >> new file mode 100644
> >> index 0000000000..e023bca3a1
> >> --- /dev/null
> >> +++ b/xen/arch/arm/firmware/scmi-smc-multiagent.c
> >> @@ -0,0 +1,860 @@
> >> +/* SPDX-License-Identifier: GPL-2.0-only */
> >> +/*
> >> + * SCI SCMI multi-agent driver, using SMC/HVC shmem as transport.
> >> + *
> >> + * Oleksii Moisieiev
> >> + * Copyright (c) 2025 EPAM Systems
> >> + */
> >> +
> >> +#include 
> >> +
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +#include 
> >> +#include 
> >> +
> >> +#include "scmi-proto.h"
> >> +#include "scmi-shmem.h"
> >> +
> >> +#define SCMI_AGENT_ID_INVALID 0xFF
> >> +
> >> +static uint8_t __initdata opt_dom0_scmi_agent_id = SCMI_AGENT_ID_INVALID;
> >> +integer_param("dom0_scmi_agent_id", opt_dom0_scmi_agent_id);
> >> +
> >> +#define SCMI_SECONDARY_AGENTS "xen,scmi-secondary-agents"
> >> +
> >> +#define HYP_CHANNEL 0x0
> >> +
> >> +struct scmi_channel {
> >> +    uint32_t agent_id;
> >> +    uint32_t func_id;
> >> +    domid_t domain_id;
> >> +    uint64_t paddr;
> >> +    uint64_t len;
> >> +    struct scmi_shared_mem __iomem *shmem;
> >> +    spinlock_t lock;
> >> +    struct list_head list;
> >> +};
> >> +
> >> +struct scmi_data {
> >> +    struct list_head channel_list;
> >> +    spinlock_t channel_list_lock;
> >> +    uint32_t func_id;
> >> +    bool initialized;
> >> +    uint32_t shmem_phandle;
> >> +    struct dt_device_node *dt_dev;
> >> +};
> >> +
> >> +static struct scmi_data scmi_data;
> >> +
> >> +static int send_smc_message(struct scmi_channel *chan_info,
> >> +                            scmi_msg_header_t *hdr, void *data, int len)
> >> +{
> >> +    struct arm_smccc_res resp;
> >> +    int ret;
> >> +
> >> +    ret = shmem_put_message(chan_info->shmem, hdr, data, len);
> >> +    if ( ret )
> >> +        return ret;
> >> +
> >> +    arm_smccc_1_1_smc(chan_info->func_id, 0, 0, 0, 0, 0, 0, 0, &resp);
> >> +
> >> +    if ( resp.a0 )
> >> +        return -EOPNOTSUPP;
> > Why if repo.a0 != 0 then we assume -EOPNOTSUPP? Is this part of the SCMI
> > specification?
> 
> Please see 7.1 of [1]. The following codes are supported :
> 
> 0 for success
> 
> -1 as not_supported
> 
> -2 as not_required
> 
> -3 as invalid_parameter.
> 
> For all non-zero results we assume that this call is not supported by
> system or has different revision
> 
> which we also doesn't support.

For -1 and -2 make sense. I am less sure about converting -3 into
-EOPNOTSUPP. But I'll trust your judgment.


> [1] DEN0028
> https://documentation-service.arm.com/static/5f8edaeff86e16515cdbe4c6
> >> +    return 0;
> >> +}
> >> +
> >> +static int do_smc_xfer(struct scmi_channel *chan_info, scmi_msg_header_t *hdr,
> >> +                       void *tx_data, int tx_size, void *rx_data, int rx_size)
> >> +{
> >> +    int ret = 0;
> >> +
> >> +    ASSERT(chan_info && chan_info->shmem);
> >> +
> >> +    if ( !hdr )
> >> +        return -EINVAL;
> >> +
> >> +    spin_lock(&chan_info->lock);
> >> +
> >> +    printk(XENLOG_DEBUG
> >> +           "scmi: agent_id = %d msg_id = %x type = %d, proto = %x\n",
> >> +           chan_info->agent_id, hdr->id, hdr->type, hdr->protocol);
> >> +
> >> +    ret = send_smc_message(chan_info, hdr, tx_data, tx_size);
> >> +    if ( ret )
> >> +        goto clean;
> >> +
> >> +    ret = shmem_get_response(chan_info->shmem, hdr, rx_data, rx_size);
> >> +
> >> +clean:
> >> +    printk(XENLOG_DEBUG
> >> +           "scmi: get smc response agent_id = %d msg_id = %x proto = %x res=%d\n",
> >> +           chan_info->agent_id, hdr->id, hdr->protocol, ret);
> >> +
> >> +    spin_unlock(&chan_info->lock);
> >> +
> >> +    return ret;
> >> +}
> >> +
> >> +static struct scmi_channel *get_channel_by_id(uint32_t agent_id)
> >> +{
> >> +    struct scmi_channel *curr;
> >> +    bool found = false;
> >> +
> >> +    spin_lock(&scmi_data.channel_list_lock);
> >> +    list_for_each_entry(curr, &scmi_data.channel_list, list)
> >> +    {
> >> +        if ( curr->agent_id == agent_id )
> >> +        {
> >> +            found = true;
> >> +            break;
> >> +        }
> >> +    }
> >> +
> >> +    spin_unlock(&scmi_data.channel_list_lock);
> >> +    if ( found )
> >> +        return curr;
> >> +
> >> +    return NULL;
> >> +}
> >> +
> >> +static struct scmi_channel *acquire_scmi_channel(struct domain *d,
> >> +                                                 uint32_t agent_id)
> >> +{
> >> +    struct scmi_channel *curr;
> >> +    struct scmi_channel *ret = ERR_PTR(-ENOENT);
> >> +
> >> +    spin_lock(&scmi_data.channel_list_lock);
> >> +    list_for_each_entry(curr, &scmi_data.channel_list, list)
> >> +    {
> >> +        if ( curr->agent_id == agent_id )
> >> +        {
> >> +            if ( curr->domain_id != DOMID_INVALID )
> >> +            {
> >> +                ret = ERR_PTR(-EEXIST);
> >> +                break;
> >> +            }
> >> +
> >> +            curr->domain_id = d->domain_id;
> >> +            ret = curr;
> >> +            break;
> >> +        }
> >> +    }
> >> +
> >> +    spin_unlock(&scmi_data.channel_list_lock);
> >> +
> >> +    return ret;
> >> +}
> >> +
> >> +static void relinquish_scmi_channel(struct scmi_channel *channel)
> >> +{
> >> +    ASSERT(channel != NULL);
> >> +
> >> +    spin_lock(&scmi_data.channel_list_lock);
> >> +    channel->domain_id = DOMID_INVALID;
> >> +    spin_unlock(&scmi_data.channel_list_lock);
> >> +}
> >> +
> >> +static int map_channel_memory(struct scmi_channel *channel)
> >> +{
> >> +    ASSERT(channel && channel->paddr);
> >> +    channel->shmem = ioremap_nocache(channel->paddr, SCMI_SHMEM_MAPPED_SIZE);
> > ioremap is for MMIO, if these shared memory channels are on DDR, then it
> > would not be the right call. Are the "arm,scmi-shmem" address ranges
> > part of the memory node ranges? Or are they completely separate?
> >
> > Also, why nocache? Wouldn't we want ioremap_cache?
> >
> Currently, they are separate nodes but could potentially be part of the
> "memory-region".
> 
>  From what I see in the Linux kernel, devm_ioremap is being used to map
> the memory.
> 
> Could there be something more to this approach?
> 
> [0]:https://git.iliana.fyi/linux/patch/?id=1dc6558062dadfabd2fb3bd885fa6e92ec7196f2

I am guessing that TF-A is mapping memory as uncacheable so we should do
the same in Xen.


> >> +    if ( !channel->shmem )
> >> +        return -ENOMEM;
> >> +
> >> +    channel->shmem->channel_status = SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE;
> >> +    printk(XENLOG_DEBUG "scmi: Got shmem %lx after vmap %p\n", channel->paddr,
> >> +           channel->shmem);
> >> +
> >> +    return 0;
> >> +}
> >> +
> >> +static void unmap_channel_memory(struct scmi_channel *channel)
> >> +{
> >> +    ASSERT(channel && channel->shmem);
> >> +    iounmap(channel->shmem);
> >> +    channel->shmem = NULL;
> >> +}
> >> +
> >> +static struct scmi_channel *smc_create_channel(uint32_t agent_id,
> >> +                                               uint32_t func_id, uint64_t addr)
> >> +{
> >> +    struct scmi_channel *channel;
> >> +
> >> +    channel = get_channel_by_id(agent_id);
> >> +    if ( channel )
> >> +        return ERR_PTR(EEXIST);
> >> +
> >> +    channel = xmalloc(struct scmi_channel);
> >> +    if ( !channel )
> >> +        return ERR_PTR(ENOMEM);
> >> +
> >> +    spin_lock_init(&channel->lock);
> >> +    channel->agent_id = agent_id;
> >> +    channel->func_id = func_id;
> >> +    channel->domain_id = DOMID_INVALID;
> >> +    channel->shmem = NULL;
> >> +    channel->paddr = addr;
> >> +    list_add_tail(&channel->list, &scmi_data.channel_list);
> >> +    return channel;
> >> +}
> >> +
> >> +static void free_channel_list(void)
> >> +{
> >> +    struct scmi_channel *curr, *_curr;
> >> +
> >> +    list_for_each_entry_safe(curr, _curr, &scmi_data.channel_list, list)
> >> +    {
> >> +        list_del(&curr->list);
> >> +        xfree(curr);
> >> +    }
> >> +}
> >> +
> >> +static int __init
> >> +scmi_dt_read_hyp_channel_addr(struct dt_device_node *scmi_node, u64 *addr,
> >> +                              u64 *size)
> >> +{
> >> +    struct dt_device_node *shmem_node;
> >> +    const __be32 *prop;
> >> +
> >> +    prop = dt_get_property(scmi_node, "shmem", NULL);
> >> +    if ( !prop )
> >> +        return -EINVAL;
> >> +
> >> +    shmem_node = dt_find_node_by_phandle(be32_to_cpup(prop));
> >> +    if ( IS_ERR_OR_NULL(shmem_node) )
> >> +    {
> >> +        printk(XENLOG_ERR
> >> +               "scmi: Device tree error, can't parse reserved memory %ld\n",
> >> +               PTR_ERR(shmem_node));
> >> +        return PTR_ERR(shmem_node);
> >> +    }
> >> +
> >> +    return dt_device_get_address(shmem_node, 0, addr, size);
> >> +}
> >> +
> >> +/*
> >> + * Handle Dom0 SCMI specific DT nodes
> >> + *
> >> + * Make a decision on copying SCMI specific nodes into Dom0 device tree.
> >> + * For SCMI multi-agent case:
> >> + * - shmem nodes will not be copied and generated instead if SCMI
> >> + *   is enabled for Dom0
> >> + * - scmi node will be copied if SCMI is enabled for Dom0
> >> + */
> >> +static bool scmi_dt_handle_node(struct domain *d, struct dt_device_node *node)
> >> +{
> >> +    static const struct dt_device_match skip_matches[] __initconst = {
> >> +        DT_MATCH_COMPATIBLE("arm,scmi-shmem"),
> >> +        { /* sentinel */ },
> >> +    };
> >> +    static const struct dt_device_match scmi_matches[] __initconst = {
> >> +        DT_MATCH_PATH("/firmware/scmi"),
> >> +        { /* sentinel */ },
> >> +    };
> >> +
> >> +    if ( !scmi_data.initialized )
> >> +        return false;
> >> +
> >> +    /* always drop shmem */
> >> +    if ( dt_match_node(skip_matches, node) )
> >> +    {
> >> +        dt_dprintk("  Skip scmi shmem\n");
> >> +        return true;
> >> +    }
> >> +
> >> +    /* drop scmi if not enabled */
> >> +    if ( dt_match_node(scmi_matches, node) && !sci_domain_is_enabled(d) )
> >> +    {
> >> +        dt_dprintk("  Skip scmi node\n");
> >> +        return true;
> >> +    }
> >> +
> >> +    return false;
> >> +}
> >> +
> >> +/*
> >> + * Finalize Dom0 SCMI specific DT nodes
> >> + *
> >> + * if SCMI is enabled for Dom0:
> >> + * - generate shmem node
> >> + * - map SCMI shmem MMIO into Dom0
> >> + */
> >> +static int scmi_dt_finalize(struct domain *d, void *fdt)
> >> +{
> >> +    __be32 reg[GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS];
> >> +    struct scmi_channel *channel;
> >> +    int nodeoffset;
> >> +    __be32 *cells;
> >> +    __be32 val;
> >> +    char buf[64];
> >> +    int res, rc;
> >> +
> >> +    if ( !sci_domain_is_enabled(d) )
> >> +        return 0;
> >> +
> >> +    channel = d->arch.sci_data;
> >> +
> >> +    /*
> >> +     * Replace "arm,smc-id" with proper value assigned for Dom0 SCMI channel
> >> +     */
> >> +    nodeoffset = fdt_node_offset_by_compatible(fdt, -1, "arm,scmi-smc");
> >> +    if ( nodeoffset < 0 )
> >> +        return -ENODEV;
> >> +
> >> +    cells = (__be32 *)&val;
> >> +    dt_set_cell(&cells, 1, channel->func_id);
> >> +    res = fdt_setprop_inplace(fdt, nodeoffset, "arm,smc-id", &val, sizeof(val));
> >> +    if ( res )
> >> +        return -EINVAL;
> >> +
> > Are you sure it is worth to go through all this trouble to modify FDT in
> > place when we could simply generate the DT node from scratch like we do
> > for example for the GIC? This seems to be more error prone as well. Is
> > generating it from scratch is really difficult? If it is difficult then OK.
> >
> In the last patch [0] of the series, there is a proposal to separate
> 
>   the Xen privileged agent from the Dom0 agent. This eliminates the
> 
> need to modify the Xen Device Tree Blob (DTB), which is a positive
> improvement
> 
> since the Dom0 agent node is already present in the device tree.
> 
> However, the issue with SCMI node generation lies in the need to handle
> 
> the list of protocols that are supported across the system.
> 
> If we want to generate the SCMI node for Dom0, we need to:
> 
> Copy these protocols from a centralized or predefined source.
> Set the correct phandle for each subnode within the SCMI node, ensuring
> 
> accurate representation and functionality.
> This extra step of managing the protocols and phandles adds
> 
> complexity but is necessary for ensuring proper support for Dom0.
> 
> [0]
> https://lists.xenproject.org/archives/html/xen-devel/2025-05/msg01041.html

I was only commenting that rather than trying to modify the DT in place
we could create the node for Dom0 from scratch (artificially), based on
host DT information as required (fetching data from the host DT as
required and copying it to the Dom0 DT).


> >> +    /*
> >> +     * All SCMI shmem nodes should be removed from Dom0 DT at this point, so
> >> +     * the shmem node for Dom0 need to be generated from SCMI channel assigned
> >> +     * to Dom0.
> >> +     * The original SCMI shmem node from platform DT is used by Xen SCMI driver
> >> +     * itself as privileged channel (agent_id=0) to manage other SCMI
> >> +     * agents (domains).
> >> +     */
> >> +    snprintf(buf, sizeof(buf), "scmi-shmem@%lx", channel->paddr);
> >> +
> >> +    res = fdt_begin_node(fdt, buf);
> >> +    if ( res )
> >> +        return res;
> >> +
> >> +    res = fdt_property_string(fdt, "compatible", "arm,scmi-shmem");
> >> +    if ( res )
> >> +        return res;
> >> +
> >> +    cells = ®[0];
> >> +
> >> +    dt_child_set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
> >> +                       channel->paddr, SCMI_SHMEM_MAPPED_SIZE);
> >> +
> >> +    res = fdt_property(fdt, "reg", reg, sizeof(reg));
> >> +    if ( res )
> >> +        return res;
> >> +
> >> +    res = fdt_property_cell(fdt, "phandle", scmi_data.shmem_phandle);
> >> +    if ( res )
> >> +        return res;
> >> +
> >> +    res = fdt_end_node(fdt);
> >> +    if ( res )
> >> +        return res;
> >> +
> >> +    /*
> >> +     * Map SCMI shmem into Dom0 here as shmem nodes are excluded from
> >> +     * generic Dom0 DT processing
> >> +     */
> >> +    res = iomem_permit_access(d, paddr_to_pfn(channel->paddr),
> >> +                              paddr_to_pfn(channel->paddr +
> >> +                                           SCMI_SHMEM_MAPPED_SIZE - 1));
> >> +    if ( res )
> >> +        return res;
> >> +
> >> +    res = map_regions_p2mt(d, gaddr_to_gfn(channel->paddr),
> >> +                           PFN_UP(SCMI_SHMEM_MAPPED_SIZE),
> >> +                           maddr_to_mfn(channel->paddr), p2m_mmio_direct_nc);
> >> +    if ( res )
> >> +    {
> >> +        rc = iomem_deny_access(d, paddr_to_pfn(channel->paddr),
> >> +                               paddr_to_pfn(channel->paddr +
> >> +                                            SCMI_SHMEM_MAPPED_SIZE - 1));
> >> +        if ( rc )
> >> +            printk(XENLOG_ERR "scmi: Unable to deny iomem access , err = %d\n",
> >> +                   rc);
> >> +    }
> >> +
> >> +    return res;
> >> +}
> >> +
> >> +static int scmi_assign_device(uint32_t agent_id, uint32_t device_id,
> >> +                              uint32_t flags)
> >> +{
> >> +    struct scmi_msg_base_set_device_permissions_a2p tx;
> >> +    struct scmi_channel *channel;
> >> +    scmi_msg_header_t hdr;
> >> +    int ret;
> >> +
> >> +    channel = get_channel_by_id(HYP_CHANNEL);
> >> +    if ( !channel )
> >> +        return -EINVAL;
> >> +
> >> +    hdr.id = SCMI_BASE_SET_DEVICE_PERMISSIONS;
> >> +    hdr.type = 0;
> >> +    hdr.protocol = SCMI_BASE_PROTOCOL;
> >> +
> >> +    tx.agent_id = agent_id;
> >> +    tx.device_id = device_id;
> >> +    tx.flags = flags;
> >> +
> >> +    ret = do_smc_xfer(channel, &hdr, &tx, sizeof(tx), NULL, 0);
> >> +    if ( ret == -EOPNOTSUPP )
> >> +        return 0;
> > Is it actually OK to pretend that everything worked if the return is
> > -EOPNOTSUPP? I mean that in this case can we assume that the device is
> > actually assigned anyway? Wouldn't follow up SCMI operations on this
> > device fail?
> >
> I think you right. Will fix in v5
> >> +    return ret;
> >> +}
> >> +
> >> +static int scmi_dt_assign_device(struct domain *d,
> >> +                                 struct dt_phandle_args *ac_spec)
> >> +{
> >> +    struct scmi_channel *agent_channel;
> >> +    uint32_t scmi_device_id = ac_spec->args[0];
> >> +    int ret;
> >> +
> >> +    if ( !d->arch.sci_data )
> >> +        return 0;
> >> +
> >> +    /* The access-controllers is specified for DT dev, but it's not a SCMI */
> >> +    if ( ac_spec->np != scmi_data.dt_dev )
> >> +        return 0;
> > I wonder if this should be an error
> >
> We don’t expect the DT node access-controller to rely solely on SCMI.
> Therefore,
> 
> if a DT node has an access-controller but it’s not associated with SCMI,
> we should simply
> 
> ignore that node without raising an error.
> 
> 
> That’s my understanding of the situation.

I understand that, but should scmi_dt_assign_device be called in such as
a case? I didn't go back and look at the original code in writing this
comment.

 
> >> +    agent_channel = d->arch.sci_data;
> >> +
> >> +    spin_lock(&agent_channel->lock);
> >> +
> >> +    ret = scmi_assign_device(agent_channel->agent_id, scmi_device_id,
> >> +                             SCMI_BASE_DEVICE_ACCESS_ALLOW);
> >> +    if ( ret )
> >> +    {
> >> +        printk(XENLOG_ERR
> >> +               "scmi: could not assign dev for %pd agent:%d dev_id:%u (%d)",
> >> +               d, agent_channel->agent_id, scmi_device_id, ret);
> >> +    }
> >> +
> >> +    spin_unlock(&agent_channel->lock);
> >> +    return ret;
> >> +}
> >> +
> >> +static __init int collect_agents(struct dt_device_node *scmi_node)
> >> +{
> >> +    const struct dt_device_node *chosen_node;
> >> +    const __be32 *prop;
> >> +    uint32_t len, i;
> >> +
> >> +    chosen_node = dt_find_node_by_path("/chosen");
> >> +    if ( !chosen_node )
> >> +    {
> >> +        printk(XENLOG_ERR "scmi: chosen node not found\n");
> >> +        return -ENOENT;
> >> +    }
> >> +
> >> +    prop = dt_get_property(chosen_node, SCMI_SECONDARY_AGENTS, &len);
> >> +    if ( !prop )
> >> +    {
> >> +        printk(XENLOG_WARNING "scmi: No %s property found\n",
> >> +               SCMI_SECONDARY_AGENTS);
> >> +        return -ENODEV;
> >> +    }
> >> +
> >> +    if ( len % (3 * sizeof(uint32_t)) )
> >> +    {
> >> +        printk(XENLOG_ERR "scmi: Invalid length of %s property: %d\n",
> >> +               SCMI_SECONDARY_AGENTS, len);
> >> +        return -EINVAL;
> >> +    }
> >> +
> >> +    for ( i = 0; i < len / (3 * sizeof(uint32_t)); i++ )
> >> +    {
> >> +        uint32_t agent_id = be32_to_cpu(*prop++);
> >> +        uint32_t smc_id = be32_to_cpu(*prop++);
> >> +        uint32_t shmem_phandle = be32_to_cpu(*prop++);
> >> +        struct dt_device_node *node = dt_find_node_by_phandle(shmem_phandle);
> >> +        u64 addr, size;
> >> +        int ret;
> >> +
> >> +        if ( !node )
> >> +        {
> >> +            printk(XENLOG_ERR "scmi: Could not find shmem node for agent %d\n",
> >> +                   agent_id);
> >> +            return -EINVAL;
> >> +        }
> >> +
> >> +        ret = dt_device_get_address(node, 0, &addr, &size);
> >> +        if ( ret )
> >> +        {
> >> +            printk(XENLOG_ERR
> >> +                   "scmi: Could not read shmem address for agent %d: %d",
> >> +                   agent_id, ret);
> >> +            return ret;
> >> +        }
> >> +
> >> +        if ( !IS_ALIGNED(size, SCMI_SHMEM_MAPPED_SIZE) )
> >> +        {
> >> +            printk(XENLOG_ERR "scmi: shmem memory is not aligned\n");
> >> +            return -EINVAL;
> >> +        }
> >> +
> >> +        ret = PTR_RET(smc_create_channel(agent_id, smc_id, addr));
> >> +        if ( ret )
> >> +        {
> >> +            printk(XENLOG_ERR "scmi: Could not create channel for agent %d: %d",
> >> +                   agent_id, ret);
> >> +            return ret;
> >> +        }
> >> +
> >> +        printk(XENLOG_DEBUG "scmi: Agent %d SMC %X addr %lx\n", agent_id,
> >> +               smc_id, addr);
> >> +    }
> >> +
> >> +    return 0;
> >> +}
> >> +
> >> +static int scmi_domain_init(struct domain *d,
> >> +                            struct xen_domctl_createdomain *config)
> >> +{
> >> +    struct scmi_channel *channel;
> >> +    int ret;
> >> +
> >> +    if ( !scmi_data.initialized )
> >> +        return 0;
> >> +
> >> +    /*
> >> +     * Special case for Dom0 - the SCMI support is enabled basing on
> >> +     * "dom0_sci_agent_id" Xen command line parameter
> >> +     */
> >> +    if ( is_hardware_domain(d) )
> >> +    {
> >> +        if ( opt_dom0_scmi_agent_id != SCMI_AGENT_ID_INVALID )
> >> +        {
> >> +            config->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA;
> >> +            config->arch.arm_sci_agent_id = opt_dom0_scmi_agent_id;
> >> +        }
> >> +        else
> >> +            config->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_NONE;
> >> +    }
> >> +
> >> +    if ( config->arch.arm_sci_type == XEN_DOMCTL_CONFIG_ARM_SCI_NONE )
> >> +        return 0;
> >> +
> >> +    channel = acquire_scmi_channel(d, config->arch.arm_sci_agent_id);
> >> +    if ( IS_ERR(channel) )
> >> +    {
> >> +        printk(XENLOG_ERR
> >> +               "scmi: Failed to acquire SCMI channel for agent_id %u: %ld\n",
> >> +               config->arch.arm_sci_agent_id, PTR_ERR(channel));
> >> +        return PTR_ERR(channel);
> >> +    }
> >> +
> >> +    printk(XENLOG_INFO
> >> +           "scmi: Acquire channel id = 0x%x, domain_id = %d paddr = 0x%lx\n",
> >> +           channel->agent_id, channel->domain_id, channel->paddr);
> >> +
> >> +    /*
> >> +     * Dom0 (if present) needs to have an access to the guest memory range
> >> +     * to satisfy iomem_access_permitted() check in XEN_DOMCTL_iomem_permission
> >> +     * domctl.
> > Ideally this should not be needed but I understand we don't have an
> > easy solution, I think we can go ahead with this for now.
> >
> >> +     */
> >> +    if ( hardware_domain && !is_hardware_domain(d) )
> >> +    {
> >> +        ret = iomem_permit_access(hardware_domain, paddr_to_pfn(channel->paddr),
> >> +                                  paddr_to_pfn(channel->paddr + PAGE_SIZE - 1));
> >> +        if ( ret )
> >> +            goto error;
> >> +    }
> >> +
> >> +    d->arch.sci_data = channel;
> >> +    d->arch.sci_enabled = true;
> >> +
> >> +    return 0;
> >> +
> >> +error:
> >> +    relinquish_scmi_channel(channel);
> >> +    return ret;
> >> +}
> >> +
> >> +int scmi_domain_sanitise_config(struct xen_domctl_createdomain *config)
> >> +{
> >> +    if ( config->arch.arm_sci_type != XEN_DOMCTL_CONFIG_ARM_SCI_NONE &&
> >> +         config->arch.arm_sci_type != XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA )
> >> +    {
> >> +        dprintk(XENLOG_INFO, "scmi: Unsupported ARM_SCI type\n");
> >> +        return -EINVAL;
> >> +    }
> >> +    else if ( config->arch.arm_sci_type ==
> >> +              XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA &&
> >> +              config->arch.arm_sci_agent_id == 0 )
> >> +    {
> >> +        dprintk(XENLOG_INFO,
> >> +                "scmi: A zero ARM SCMI agent_id is not supported\n");
> >> +        return -EINVAL;
> >> +    }
> >> +
> >> +    return 0;
> >> +}
> >> +
> >> +static int scmi_relinquish_resources(struct domain *d)
> >> +{
> >> +    int ret;
> >> +    struct scmi_channel *channel, *agent_channel;
> >> +    scmi_msg_header_t hdr;
> >> +    struct scmi_msg_base_reset_agent_cfg_a2p tx;
> >> +
> >> +    if ( !d->arch.sci_data )
> >> +        return 0;
> >> +
> >> +    agent_channel = d->arch.sci_data;
> >> +
> >> +    spin_lock(&agent_channel->lock);
> >> +    tx.agent_id = agent_channel->agent_id;
> >> +    spin_unlock(&agent_channel->lock);
> >> +
> >> +    channel = get_channel_by_id(HYP_CHANNEL);
> >> +    if ( !channel )
> >> +    {
> >> +        printk(XENLOG_ERR
> >> +               "scmi: Unable to get Hypervisor scmi channel for domain %d\n",
> >> +               d->domain_id);
> >> +        return -EINVAL;
> >> +    }
> >> +
> >> +    hdr.id = SCMI_BASE_RESET_AGENT_CONFIGURATION;
> >> +    hdr.type = 0;
> >> +    hdr.protocol = SCMI_BASE_PROTOCOL;
> >> +
> >> +    tx.flags = 0;
> >> +
> >> +    ret = do_smc_xfer(channel, &hdr, &tx, sizeof(tx), NULL, 0);
> >> +    if ( ret == -EOPNOTSUPP )
> >> +        return 0;
> >> +
> >> +    return ret;
> >> +}
> >> +
> >> +static void scmi_domain_destroy(struct domain *d)
> >> +{
> >> +    struct scmi_channel *channel;
> >> +
> >> +    if ( !d->arch.sci_data )
> >> +        return;
> >> +
> >> +    channel = d->arch.sci_data;
> >> +    spin_lock(&channel->lock);
> >> +
> >> +    relinquish_scmi_channel(channel);
> >> +    printk(XENLOG_DEBUG "scmi: Free domain %d\n", d->domain_id);
> >> +
> >> +    d->arch.sci_data = NULL;
> >> +    d->arch.sci_enabled = true;
> >> +
> >> +    spin_unlock(&channel->lock);
> >> +}
> >> +
> >> +static bool scmi_handle_call(struct cpu_user_regs *regs)
> >> +{
> >> +    uint32_t fid = (uint32_t)get_user_reg(regs, 0);
> >> +    struct scmi_channel *agent_channel;
> >> +    struct domain *d = current->domain;
> >> +    struct arm_smccc_res resp;
> >> +    bool res = false;
> >> +
> >> +    if ( !sci_domain_is_enabled(d) )
> >> +        return false;
> >> +
> >> +    agent_channel = d->arch.sci_data;
> >> +    spin_lock(&agent_channel->lock);
> >> +
> >> +    if ( agent_channel->func_id != fid )
> >> +    {
> >> +        res = false;
> >> +        goto unlock;
> >> +    }
> >> +
> >> +    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),
> >> +                      &resp);
> >> +
> >> +    set_user_reg(regs, 0, resp.a0);
> >> +    set_user_reg(regs, 1, resp.a1);
> >> +    set_user_reg(regs, 2, resp.a2);
> >> +    set_user_reg(regs, 3, resp.a3);
> >> +    res = true;
> >> +unlock:
> >> +    spin_unlock(&agent_channel->lock);
> >> +
> >> +    return res;
> >> +}
> >> +
> >> +static const struct sci_mediator_ops scmi_ops = {
> >> +    .domain_init = scmi_domain_init,
> >> +    .domain_destroy = scmi_domain_destroy,
> >> +    .relinquish_resources = scmi_relinquish_resources,
> >> +    .handle_call = scmi_handle_call,
> >> +    .dom0_dt_handle_node = scmi_dt_handle_node,
> >> +    .dom0_dt_finalize = scmi_dt_finalize,
> >> +    .domain_sanitise_config = scmi_domain_sanitise_config,
> >> +    .assign_dt_device = scmi_dt_assign_device,
> >> +};
> >> +
> >> +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 __init int scmi_probe(struct dt_device_node *scmi_node, const void *data)
> >> +{
> >> +    u64 addr, size;
> >> +    int ret, i;
> >> +    struct scmi_channel *channel, *agent_channel;
> >> +    int n_agents;
> >> +    scmi_msg_header_t hdr;
> >> +    struct scmi_msg_base_attributes_p2a rx;
> >> +
> >> +    ASSERT(scmi_node != NULL);
> >> +
> >> +    INIT_LIST_HEAD(&scmi_data.channel_list);
> >> +    spin_lock_init(&scmi_data.channel_list_lock);
> >> +
> >> +    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;
> >> +
> >> +    if ( !dt_property_read_u32(scmi_node, "arm,smc-id", &scmi_data.func_id) )
> >> +    {
> >> +        printk(XENLOG_ERR "scmi: unable to read smc-id from DT\n");
> >> +        return -ENOENT;
> >> +    }
> >> +
> >> +    /* save shmem phandle and re-use it fro Dom0 DT shmem node */
> >> +    if ( !dt_property_read_u32(scmi_node, "shmem", &scmi_data.shmem_phandle) )
> >> +    {
> >> +        printk(XENLOG_ERR "scmi: unable to read shmem phandle from DT\n");
> >> +        return -ENOENT;
> >> +    }
> >> +
> >> +    ret = scmi_dt_read_hyp_channel_addr(scmi_node, &addr, &size);
> >> +    if ( IS_ERR_VALUE(ret) )
> >> +        return -ENOENT;
> >> +
> >> +    if ( !IS_ALIGNED(size, SCMI_SHMEM_MAPPED_SIZE) )
> >> +    {
> >> +        printk(XENLOG_ERR "scmi: shmem memory is not aligned\n");
> >> +        return -EINVAL;
> >> +    }
> >> +
> >> +    scmi_data.dt_dev = scmi_node;
> >> +
> >> +    channel = smc_create_channel(HYP_CHANNEL, scmi_data.func_id, addr);
> >> +    if ( IS_ERR(channel) )
> >> +        goto out;
> >> +
> >> +    ret = map_channel_memory(channel);
> >> +    if ( ret )
> >> +        goto out;
> >> +
> >> +    channel->domain_id = DOMID_XEN;
> >> +
> >> +    hdr.id = SCMI_BASE_PROTOCOL_ATTIBUTES;
> >> +    hdr.type = 0;
> >> +    hdr.protocol = SCMI_BASE_PROTOCOL;
> >> +
> >> +    ret = do_smc_xfer(channel, &hdr, NULL, 0, &rx, sizeof(rx));
> >> +    if ( ret )
> >> +        goto error;
> >> +
> >> +    n_agents = SCMI_FIELD_GET(SCMI_BASE_ATTR_NUM_AGENT, rx.attributes);
> >> +    printk(XENLOG_DEBUG "scmi: Got agent count %d\n", n_agents);
> >> +
> >> +    ret = collect_agents(scmi_node);
> >> +    if ( ret )
> >> +        goto error;
> >> +
> >> +    i = 1;
> >> +
> >> +    list_for_each_entry(agent_channel, &scmi_data.channel_list, list)
> >> +    {
> >> +        struct scmi_msg_base_discover_agent_p2a da_rx;
> >> +        struct scmi_msg_base_discover_agent_a2p da_tx;
> >> +
> >> +        ret = map_channel_memory(agent_channel);
> >> +        if ( ret )
> >> +            goto error;
> >> +
> >> +        hdr.id = SCMI_BASE_DISCOVER_AGENT;
> >> +        hdr.type = 0;
> >> +        hdr.protocol = SCMI_BASE_PROTOCOL;
> >> +
> >> +        da_tx.agent_id = agent_channel->agent_id;
> >> +
> >> +        ret = do_smc_xfer(agent_channel, &hdr, &da_tx, sizeof(da_tx), &da_rx,
> >> +                          sizeof(da_rx));
> >> +        if ( agent_channel->domain_id != DOMID_XEN )
> >> +            unmap_channel_memory(agent_channel);
> >> +        if ( ret )
> >> +            goto error;
> >> +
> >> +        printk(XENLOG_DEBUG "id=0x%x name=%s\n", da_rx.agent_id, da_rx.name);
> >> +
> >> +        agent_channel->agent_id = da_rx.agent_id;
> > It is OK to set agent_channel->agent_id to the value provided by the
> > SCMI server, but if we are also taking the agent_channel->agent_id value
> > from the user via device tree, shouldn't we throw an error if there is a
> > mismatch?
> >
> > Or even better: can we avoid taking the value via device tree to make it
> > easier to configure?
> >
> I plan to drop the last line, as there’s no need to overwrite agent_id.
> 
> However, we cannot avoid obtaining agent_id from the device tree because,
> 
> according to section 4.2.2.9 [0], an agent can only be discovered by its
> agent_id in
> 
> a privileged domain. Alternatively, each agent can obtain its own ID by
> providing
> 
> 0xFFFFFFFF as agent_id and using its own channel.

That would be great! Anything to reduce the number of required (not
optional) configuration options.
--8323329-165160365-1750201972=:1780597--


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 23:39:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 23:39:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018594.1395472 (Exim 4.92)
	(envelope-from )
	id 1uRftT-0004C6-N1; Tue, 17 Jun 2025 23:39:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018594.1395472; Tue, 17 Jun 2025 23:39:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRftT-0004Bz-KL; Tue, 17 Jun 2025 23:39:07 +0000
Received: by outflank-mailman (input) for mailman id 1018594;
 Tue, 17 Jun 2025 23:39:06 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uRftS-0004Bt-0C
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 23:39:06 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4036f2a2-4bd4-11f0-a30a-13f23c93f187;
 Wed, 18 Jun 2025 01:39:03 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 840886111C;
 Tue, 17 Jun 2025 23:39:02 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3EB9AC4CEE3;
 Tue, 17 Jun 2025 23:39:00 +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: 4036f2a2-4bd4-11f0-a30a-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750203541;
	bh=X9VOxrivhGHFtdsJ34e8lSsPNqWIXUmXGH6Zi4vTE7A=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=cI5d/YT1Kk0jKVxyxV9PRPyz74vogJd55SIb9OlDHUepfl4rHRLrrcQlnW2DlhIrE
	 uS3kVo4K4qH/73GI48DkTRLsVHgxULbxZxZ+SXobnmlIhqWQyC4uz8H4B3P5/jACyA
	 BA1FCpgxWTyKbSUK9S5zE6uJkP4BQeN2xFipGAMDPe2LeVOrnPpBgWhXMt2290dj2R
	 gdydhQ6CQooSMfAs1WJWi4/5Gd9Ke2LpNvCHLOZx1CcRJMzFv1gwjwVTS6lbJHKdpk
	 Fr8H60r41XOgTYuYGfrVQ5+LjDFCXPJGY5Xo2PykNLnfmmXBomQSOzDfPZulvn8V45
	 JAjcBpGTBL+ig==
Date: Tue, 17 Jun 2025 16:38:58 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Grygorii Strashko 
cc: Bertrand Marquis , 
    Stefano Stabellini , 
    Oleksii Moisieiev , 
    "xen-devel@lists.xenproject.org" , 
    Andrew Cooper , 
    Anthony PERARD , 
    Jan Beulich , Juergen Gross , 
    Julien Grall , Michal Orzel , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Volodymyr Babchuk 
Subject: Re: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC
 multi-agent driver
In-Reply-To: <50ff5d2b-bd17-4833-b497-0dda6f75964a@epam.com>
Message-ID: 
References:  <318044ae12f13b6b297b3f5fda577a1a6cd143da.1747669845.git.oleksii_moisieiev@epam.com>  <04B1F737-5E6B-47C0-B2B9-74288C68E68A@arm.com>
 <50ff5d2b-bd17-4833-b497-0dda6f75964a@epam.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 Jun 2025, Grygorii Strashko wrote:
> On 02.06.25 10:17, Bertrand Marquis wrote:
> > Hi Stefano and Oleksii,
> > 
> > > On 23 May 2025, at 22:06, Stefano Stabellini 
> > > wrote:
> > > 
> > > One question for Bertrand below
> > > 
> > > 
> > > On Mon, 19 May 2025, Oleksii Moisieiev wrote:
> > > > This patch introduces SCI driver to support for ARM EL3 Trusted
> > > > Firmware-A
> > > > (TF-A) which provides SCMI interface with multi-agnet support, as shown
> > > > below.
> > > > 
> > > >   +-----------------------------------------+
> > > >   |                                         |
> > > >   | EL3 TF-A SCMI                           |
> > > >   +-------+--+-------+--+-------+--+-------++
> > > >   |shmem0 |  |shmem1 |  |shmem2 |  |shmemX |
> > > >   +-----+-+  +---+---+  +--+----+  +---+---+
> > > > smc-id0 |        |         |           |
> > > > agent0  |        |         |           |
> > > >   +-----v--------+---------+-----------+----+
> > > >   |              |         |           |    |
> > > >   |              |         |           |    |
> > > >   +--------------+---------+-----------+----+
> > > >          smc-id1 |  smc-id2|    smc-idX|
> > > >          agent1  |  agent2 |    agentX |
> > > >                  |         |           |
> > > >             +----v---+  +--v-----+  +--v-----+
> > > >             |        |  |        |  |        |
> > > >             | Dom0   |  | Dom1   |  | DomX   |
> > > >             |        |  |        |  |        |
> > > >             |        |  |        |  |        |
> > > >             +--------+  +--------+  +--------+
> > > > 
> > > > The EL3 SCMI multi-agent firmware expected to provide SCMI SMC/HVC
> > > > shared
> > > > memory transport for every Agent in the system.
> > > > 
> > > > The SCMI Agent transport channel defined by pair:
> > > > - smc-id: SMC/HVC id used for Doorbell
> > > > - shmem: shared memory for messages transfer, Xen page aligned,
> > > > p2m_mmio_direct_nc.
> > > > 
> > > > The follwoing SCMI Agents expected to be defined by SCMI FW to enable
> > > > SCMI
> > > > multi-agent functionality under Xen:
> > > > - Xen manegement agent: trusted agents that accesses to the Base
> > > > Protocol
> > > > commands to configure agent specific permissions
> > > > - OSPM VM agents: non-trusted agent, one for each Guest domain which is
> > > >   allowed direct HW access. At least one OSPM VM agent has to be
> > > > provided
> > > >   by FW if HW is handled only by Dom0 or Driver Domain.
> > > > 
> > > > The EL3 SCMI FW expected to implement following Base protocol messages:
> > > > - BASE_DISCOVER_AGENT
> > > > - BASE_RESET_AGENT_CONFIGURATION (optional)
> > > > - BASE_SET_DEVICE_PERMISSIONS (optional)
> > > > 
> > > > The SCI SCMI SMC multi-agent driver implements following functionality:
> > > > - It's initialized based on the Host DT SCMI node (only one SCMI
> > > > interface
> > > > is supported) which describes Xen management agent SCMI interface.
> > > > 
> > > > scmi_shm_0 : sram@47ff0000 {
> > > >     compatible = "arm,scmi-shmem";
> > > >     reg = <0x0 0x47ff0000 0x0 0x1000>;
> > > > };
> > > > firmware {
> > > >     scmi: scmi {
> > > >         compatible = "arm,scmi-smc";
> > > >         arm, smc - id = <0x82000002>; // Xen manegement agent smc-id
> > > 
> > > some extra spaces, it might be a copy/paste error
> > > 
> > > 
> > > >         \#address-cells = < 1>;
> > > >         \#size-cells = < 0>;
> > > >         \#access-controller - cells = < 1>;
> > > >         shmem = <&scmi_shm_0>; // Xen manegement agent shmem
> > > > 
> > > >         protocol@X{
> > > >         };
> > > >     };
> > > > };
> > > > 
> > > > - It obtains Xen specific SCMI Agent's configuration from the Host DT,
> > > > probes Agents and build SCMI Agents list; The Agents configuration is
> > > > taken from:
> > > > 
> > > > chosen {
> > > >   xen,scmi-secondary-agents = <
> > > > 1 0x82000003 &scmi_shm_1
> > > > 2 0x82000004 &scmi_shm_2
> > > > 3 0x82000005 &scmi_shm_3
> > > > 4 0x82000006 &scmi_shm_4>;
> > > > }
> > > > 
> > > > /{
> > > > scmi_shm_1: sram@47ff1000 {
> > > > compatible = "arm,scmi-shmem";
> > > > reg = <0x0 0x47ff1000 0x0 0x1000>;
> > > > };
> > > > scmi_shm_2: sram@47ff2000 {
> > > > compatible = "arm,scmi-shmem";
> > > > reg = <0x0 0x47ff2000 0x0 0x1000>;
> > > > };
> > > > scmi_shm_3: sram@47ff3000 {
> > > > compatible = "arm,scmi-shmem";
> > > > reg = <0x0 0x47ff3000 0x0 0x1000>;
> > > > };
> > > > }
> > > >   where first item is "agent_id", second - "arm,smc-id", and third -
> > > > "arm,scmi-shmem" for
> > > >   this agent_id.
> > > > 
> > > >   Note that Xen is the only one entry in the system which need to know
> > > >   about SCMI multi-agent support.
> > > > 
> > > > - It implements the SCI subsystem interface required for configuring and
> > > > enabling SCMI functionality for Dom0/hwdom and Guest domains. To enable
> > > > SCMI functionality for domain it has to be configured with unique
> > > > supported
> > > > SCMI Agent_id and use corresponding SCMI SMC/HVC shared memory transport
> > > > [smc-id, shmem] defined for this SCMI Agent_id.
> > > > - Once Xen domain is configured it can communicate with EL3 SCMI FW:
> > > >   -- zero-copy, the guest domain puts SCMI message in shmem;
> > > >   -- the guest triggers SMC/HVC exception with smc-id (doorbell);
> > > >   -- the Xen driver catches exception, do checks and synchronously
> > > > forwards
> > > >   it to EL3 FW.
> > > > - the Xen driver sends BASE_RESET_AGENT_CONFIGURATION message to Xen
> > > >   management agent channel on domain destroy event. This allows to reset
> > > >   resources used by domain and so implement use-case like domain reboot.
> > > > 
> > > > Dom0 Enable SCMI SMC:
> > > > - pass dom0_scmi_agent_id= in Xen command line. if not
> > > > provided
> > > >    SCMI will be disabled for Dom0 and all SCMI nodes removed from Dom0
> > > > DT.
> > > >    The driver updates Dom0 DT SCMI node "arm,smc-id" value and fix up
> > > > shmem
> > > >    node according to assigned agent_id.
> > > > 
> > > > Guest domains enable SCMI SMC:
> > > > - xl.cfg: add configuration option as below
> > > > 
> > > >    arm_sci = "type=scmi_smc_multiagent,agent_id=2"
> > > > 
> > > > - xl.cfg: enable access to the "arm,scmi-shmem" which should correspond
> > > > assigned agent_id for
> > > >    the domain, for example:
> > > > 
> > > > iomem = [
> > > >     "47ff2,1@22001",
> > > > ]
> > > 
> > > Looking at the code and the configuration options, it looks like it is
> > > possible to map a scmi-shmem channel at a different address for the
> > > guest. It seems like it would work. Is that correct?
> > > 
> > > 
> > > > - DT: add SCMI nodes to the Driver domain partial device tree as in the
> > > > below example. The "arm,smc-id" should correspond assigned agent_id for
> > > > the domain:
> > > > 
> > > > passthrough {
> > > >    scmi_shm_0: sram@22001000 {
> > > >        compatible = "arm,scmi-shmem";
> > > >        reg = <0x0 0x22001000 0x0 0x1000>;
> > > >    };
> > > > 
> > > >    firmware {
> > > >         compatible = "simple-bus";
> > > >             scmi: scmi {
> > > >                 compatible = "arm,scmi-smc";
> > > >                 arm,smc-id = <0x82000004>;
> > > >                 shmem = <&scmi_shm_0>;
> > > >                 ...
> > > >             }
> > > >     }
> > > > }
> > > > 
> > > > SCMI "4.2.1.1 Device specific access control"
> > > > 
> > > > The XEN SCI SCMI SMC multi-agent driver performs "access-controller"
> > > > provider function
> > > > in case EL3 SCMI FW implements SCMI "4.2.1.1 Device specific access
> > > > control" and provides the
> > > > BASE_SET_DEVICE_PERMISSIONS command to configure the devices that an
> > > > agents have access to.
> > > > The DT SCMI node should "#access-controller-cells=<1>" property and DT
> > > > devices should be bound
> > > > to the Xen SCMI.
> > > > 
> > > > &i2c1 {
> > > > access-controllers = <&scmi 0>;
> > > > };
> > > > 
> > > > The Dom0 and dom0less domains DT devices will be processed automatically
> > > > through
> > > > sci_assign_dt_device() call, but to assign SCMI devices from toolstack
> > > > the xl.cfg:"dtdev" property
> > > > shell be used:
> > > > 
> > > > dtdev = [
> > > >     "/soc/i2c@e6508000",
> > > > ]
> > > > 
> > > > xl.cfg:dtdev will contain all nodes which are under SCMI management (not
> > > > only those which are behind IOMMU).
> > > > 
> > > > [1]
> > > > https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > > > [2]
> > > > https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/access-controllers/access-controllers.yaml
> > > > Signed-off-by: Oleksii Moisieiev 
> > > > Signed-off-by: Grygorii Strashko 
> > > 
> > > Thanks for the long explanation, great work! I am really looking forward
> > > to have this feature in the tree soon.
> > > 
> > > 
> > > > ---
> > > > 
> > > > Changes in v4:
> > > > - toolstack comments from Anthony PERARD
> > > > - added dom0less support
> > > > - added doc for "xen,scmi-secondary-agents"
> > > > 
> > > > docs/man/xl.cfg.5.pod.in                    |  13 +
> > > > docs/misc/arm/device-tree/booting.txt       |  60 ++
> > > > docs/misc/xen-command-line.pandoc           |   9 +
> > > > tools/libs/light/libxl_arm.c                |   4 +
> > > > tools/libs/light/libxl_types.idl            |   4 +-
> > > > tools/xl/xl_parse.c                         |  12 +
> > > > xen/arch/arm/dom0less-build.c               |  11 +
> > > > xen/arch/arm/domain_build.c                 |   3 +-
> > > > xen/arch/arm/firmware/Kconfig               |  11 +
> > > > xen/arch/arm/firmware/Makefile              |   1 +
> > > > xen/arch/arm/firmware/scmi-proto.h          | 164 ++++
> > > > xen/arch/arm/firmware/scmi-shmem.c          | 173 ++++
> > > > xen/arch/arm/firmware/scmi-shmem.h          |  45 +
> > > > xen/arch/arm/firmware/scmi-smc-multiagent.c | 860 ++++++++++++++++++++
> > > > xen/include/public/arch-arm.h               |   3 +
> > > > 15 files changed, 1371 insertions(+), 2 deletions(-)
> > > > create mode 100644 xen/arch/arm/firmware/scmi-proto.h
> > > > create mode 100644 xen/arch/arm/firmware/scmi-shmem.c
> > > > create mode 100644 xen/arch/arm/firmware/scmi-shmem.h
> > > > create mode 100644 xen/arch/arm/firmware/scmi-smc-multiagent.c
> > > > 
> > > > diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> > > > index 1ccf50b8ea..302c46d8bc 100644
> > > > --- a/docs/man/xl.cfg.5.pod.in
> > > > +++ b/docs/man/xl.cfg.5.pod.in
> > > > @@ -3122,8 +3122,21 @@ single SCMI OSPM agent support.
> > > > Should be used together with B Xen command
> > > > line
> > > > option.
> > > > 
> > > > +=item B
> > > > +
> > > > +Enables ARM SCMI SMC multi-agent support for the guest by enabling SCMI
> > > > over
> > > > +SMC calls forwarding from domain to the EL3 firmware (like Trusted
> > > > Firmware-A)
> > > > +with a multi SCMI OSPM agent support. The SCMI B should be
> > > > +specified for the guest.
> > > > +
> > > > =back
> > > > 
> > > > +=item B
> > > > +
> > > > +Specifies a non-zero ARM SCI agent id for the guest. This option is
> > > > mandatory
> > > > +if the SCMI SMC support is enabled for the guest. The agent ids of
> > > > domains
> > > > +existing on a single host must be unique and in the range [1..255].
> > > > +
> > > > =back
> > > > 
> > > > =back
> > > > diff --git a/docs/misc/arm/device-tree/booting.txt
> > > > b/docs/misc/arm/device-tree/booting.txt
> > > > index 8943c04173..c8923ab8b2 100644
> > > > --- a/docs/misc/arm/device-tree/booting.txt
> > > > +++ b/docs/misc/arm/device-tree/booting.txt
> > > > @@ -296,6 +296,20 @@ with the following properties:
> > > >      Should be used together with dom0_scmi_smc_passthrough Xen command
> > > > line
> > > >      option.
> > > > 
> > > > +    - "scmi_smc_multiagent"
> > > > +
> > > > +    Enables ARM SCMI SMC multi-agent support for the guest by enabling
> > > > SCMI over
> > > > +    SMC calls forwarding from domain to the EL3 firmware (like ARM
> > > > +    Trusted Firmware-A) with a multi SCMI OSPM agent support.
> > > > +    The SCMI agent_id should be specified for the guest with
> > > > "xen,sci_agent_id"
> > > > +    property.
> > > > +
> > > > +- "xen,sci_agent_id"
> > > > +
> > > > +    Specifies a non-zero ARM SCI agent id for the guest. This option is
> > > > +    mandatory if the SCMI SMC "scmi_smc_multiagent" support is enabled
> > > > for
> > > > +    the guest. The agent ids of guest must be unique and in the range
> > > > [1..255].
> > > > +
> > > > Under the "xen,domain" compatible node, one or more sub-nodes are
> > > > present
> > > > for the DomU kernel and ramdisk.
> > > > 
> > > > @@ -764,3 +778,49 @@ The automatically allocated static shared memory
> > > > will get mapped at
> > > > 0x80000000 in DomU1 guest physical address space, and at 0x90000000 in
> > > > DomU2
> > > > guest physical address space. DomU1 is explicitly defined as the owner
> > > > domain,
> > > > and DomU2 is the borrower domain.
> > > > +
> > > > +SCMI SMC multi-agent support
> > > > +============================
> > > > +
> > > > +For enabling the ARM SCMI SMC multi-agent support (enabled by
> > > > CONFIG_SCMI_SMC_MA)
> > > > +the Xen specific SCMI Agent's configuration shell be provided in the
> > > > Host DT
> > > > +according to the SCMI compliant EL3 Firmware specification with
> > > > +ARM SMC/HVC transport using property "xen,scmi-secondary-agents" under
> > > > +the top-level "chosen" node:
> > > > +
> > > > +- xen,scmi-secondary-agents
> > > > +
> > > > +    Defines a set of SCMI agents configuration supported by SCMI EL3 FW
> > > > and
> > > > +    available for Xen. Each Agent defined as triple consisting of:
> > > > +    SCMI agent_id,
> > > > +    SMC/HVC function_id assigned for the agent transport
> > > > ("arm,smc-id"),
> > > > +    phandle to SCMI SHM assigned for the agent transport
> > > > ("arm,scmi-shmem").
> > > > +
> > > > +As an example:
> > > > +
> > > > +chosen {
> > > > +    xen,scmi-secondary-agents = <
> > > > +        1 0x82000003 &scmi_shm_1
> > > > +        2 0x82000004 &scmi_shm_2
> > > > +        3 0x82000005 &scmi_shm_3
> > > > +        4 0x82000006 &scmi_shm_4>;
> > > > +}
> > > 
> > > NIT: it should be };
> > > 
> > > Looking at scmi_probe, collect_agents, and the following SCMI
> > > SCMI_BASE_DISCOVER_AGENT request, I wonder: do we actually need this
> > > information?
> > > 
> > > It looks like we can discover the agend_ids for every channel, I guess
> > > what we need to know is the shmem location for every channel? But the
> > > full list of shmem channel is available below thanks to the scmi-shmem
> > > nodes.
> > > 
> > > So, we have the list of scmi-shmem anyway, and we can probe the
> > > agent_id. The only parameter left is the smc_id/func_id.
> > > 
> > > Or maybe smc_id/func_id can be calculated from agent_id?
> > > 
> > > I am asking mostly because if a user is supposed to add this
> > > xen,scmi-secondary-agents property, where are they supposed to find the
> > > smc_id/func_id information?
> > > 
> > > It is important that we write down in this document how the user is
> > > expected to find out what 1 is 0x82000003 which is scmi_shm_1.
> > > 
> > > 
> > > > +/{
> > > > +        scmi_shm_1: sram@47ff1000 {
> > > > +                compatible = "arm,scmi-shmem";
> > > > +                reg = <0x0 0x47ff1000 0x0 0x1000>;
> > > > +        };
> > > > +        scmi_shm_2: sram@47ff2000 {
> > > > +                compatible = "arm,scmi-shmem";
> > > > +                reg = <0x0 0x47ff2000 0x0 0x1000>;
> > > > +        };
> > > > +        scmi_shm_3: sram@47ff3000 {
> > > > +                compatible = "arm,scmi-shmem";
> > > > +                reg = <0x0 0x47ff3000 0x0 0x1000>;
> > > > +        };
> > > > +        scmi_shm_3: sram@47ff4000 {
> > > > +                compatible = "arm,scmi-shmem";
> > > > +                reg = <0x0 0x47ff4000 0x0 0x1000>;
> > > > +        };
> > > 
> > > Are these scmi_shm_1 - scmi_shm_3 under the top level device tree node?
> > > Or are under /firmware? Or are they under /chosen?
> > > 
> > > I take they are under the top level node together with scmi_shm_0?
> > > 
> > > Can you please also clarify in the document as well?
> > > 
> > > 
> > > > +}
> > > > diff --git a/docs/misc/xen-command-line.pandoc
> > > > b/docs/misc/xen-command-line.pandoc
> > > > index 8e50f6b7c7..bc3c64d6ec 100644
> > > > --- a/docs/misc/xen-command-line.pandoc
> > > > +++ b/docs/misc/xen-command-line.pandoc
> > > > @@ -1091,6 +1091,15 @@ which serves as Driver domain. The SCMI will be
> > > > disabled for Dom0/hwdom and
> > > > SCMI nodes removed from Dom0/hwdom device tree.
> > > > (for example, thin Dom0 with Driver domain use-case).
> > > > 
> > > > +### dom0_scmi_agent_id (ARM)
> > > > +> `= `
> > > > +
> > > > +The option is available when `CONFIG_SCMI_SMC_MA` is compiled in, and
> > > > allows to
> > > > +enable SCMI functionality for Dom0 by specifying a non-zero ARM SCMI
> > > > agent id.
> > > > +The SCMI will be disabled for Dom0 if this option is not specified
> > > > +(for example, thin Dom0 or dom0less use-cases).
> > > > +The agent ids of domains existing on a single host must be unique.
> > > > +
> > > > ### dtuart (ARM)
> > > > > `= path [:options]`
> > > > 
> > > > diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
> > > > index 28ba9eb787..7712f53cd4 100644
> > > > --- a/tools/libs/light/libxl_arm.c
> > > > +++ b/tools/libs/light/libxl_arm.c
> > > > @@ -229,6 +229,10 @@ int libxl__arch_domain_prepare_config(libxl__gc
> > > > *gc,
> > > >      case LIBXL_ARM_SCI_TYPE_SCMI_SMC:
> > > >          config->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC;
> > > >          break;
> > > > +    case LIBXL_ARM_SCI_TYPE_SCMI_SMC_MULTIAGENT:
> > > > +        config->arch.arm_sci_type =
> > > > XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA;
> > > > +        config->arch.arm_sci_agent_id =
> > > > d_config->b_info.arch_arm.arm_sci.agent_id;
> > > > +        break;
> > > >      default:
> > > >          LOG(ERROR, "Unknown ARM_SCI type %d",
> > > >              d_config->b_info.arch_arm.arm_sci.type);
> > > > diff --git a/tools/libs/light/libxl_types.idl
> > > > b/tools/libs/light/libxl_types.idl
> > > > index aa2190ab5b..11e31ce786 100644
> > > > --- a/tools/libs/light/libxl_types.idl
> > > > +++ b/tools/libs/light/libxl_types.idl
> > > > @@ -553,11 +553,13 @@ libxl_sve_type = Enumeration("sve_type", [
> > > > 
> > > > libxl_arm_sci_type = Enumeration("arm_sci_type", [
> > > >      (0, "none"),
> > > > -    (1, "scmi_smc")
> > > > +    (1, "scmi_smc"),
> > > > +    (2, "scmi_smc_multiagent")
> > > >      ], init_val = "LIBXL_ARM_SCI_TYPE_NONE")
> > > > 
> > > > libxl_arm_sci = Struct("arm_sci", [
> > > >      ("type", libxl_arm_sci_type),
> > > > +    ("agent_id", uint8)
> > > >      ])
> > > > 
> > > > libxl_rdm_reserve = Struct("rdm_reserve", [
> > > > diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
> > > > index bd22be9d33..81aa3797e3 100644
> > > > --- a/tools/xl/xl_parse.c
> > > > +++ b/tools/xl/xl_parse.c
> > > > @@ -1306,6 +1306,18 @@ static int parse_arm_sci_config(XLU_Config *cfg,
> > > > libxl_arm_sci *arm_sci,
> > > >              }
> > > >          }
> > > > 
> > > > +        if (MATCH_OPTION("agent_id", ptr, oparg)) {
> > > > +            unsigned long val = parse_ulong(oparg);
> > > > +
> > > > +            if (!val || val > 255) {
> > > > +                fprintf(stderr, "An invalid ARM_SCI agent_id specified
> > > > (%lu). Valid range [1..255]\n",
> > > > +                        val);
> > > > +                ret = ERROR_INVAL;
> > > > +                goto parse_error;
> > > > +            }
> > > > +            arm_sci->agent_id = val;
> > > > +        }
> > > > +
> > > >          ptr = strtok(NULL, ",");
> > > >      }
> > > > 
> > > > diff --git a/xen/arch/arm/dom0less-build.c
> > > > b/xen/arch/arm/dom0less-build.c
> > > > index 0a00f03a25..43d21eb889 100644
> > > > --- a/xen/arch/arm/dom0less-build.c
> > > > +++ b/xen/arch/arm/dom0less-build.c
> > > > @@ -835,6 +835,17 @@ int __init domu_dt_sci_parse(struct dt_device_node
> > > > *node,
> > > >          d_cfg->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_NONE;
> > > >      else if ( !strcmp(sci_type, "scmi_smc") )
> > > >          d_cfg->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC;
> > > > +    else if ( !strcmp(sci_type, "scmi_smc_multiagent") )
> > > > +    {
> > > > +        uint32_t agent_id = 0;
> > > > +
> > > > +        if ( !dt_property_read_u32(node, "xen,sci_agent_id", &agent_id)
> > > > ||
> > > > +             !agent_id )
> > > 
> > > shouldn't we check that agent_id <= 255 ?
> > > 
> > > 
> > > > +            return -EINVAL;
> > > > +
> > > > +        d_cfg->arch.arm_sci_type =
> > > > XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA;
> > > > +        d_cfg->arch.arm_sci_agent_id = agent_id;
> > > > +    }
> > > >      else
> > > >      {
> > > >          printk(XENLOG_ERR "xen,sci_type in not valid (%s) for domain
> > > > %s\n",
> > > > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > > > index 36d28b52a4..0c9274a2b3 100644
> > > > --- a/xen/arch/arm/domain_build.c
> > > > +++ b/xen/arch/arm/domain_build.c
> > > > @@ -616,7 +616,8 @@ static int __init write_properties(struct domain *d,
> > > > struct kernel_info *kinfo,
> > > >                   dt_property_name_is_equal(prop,
> > > > "linux,uefi-mmap-start") ||
> > > >                   dt_property_name_is_equal(prop,
> > > > "linux,uefi-mmap-size") ||
> > > >                   dt_property_name_is_equal(prop,
> > > > "linux,uefi-mmap-desc-size") ||
> > > > -                 dt_property_name_is_equal(prop,
> > > > "linux,uefi-mmap-desc-ver"))
> > > > +                 dt_property_name_is_equal(prop,
> > > > "linux,uefi-mmap-desc-ver") ||
> > > > +                 dt_property_name_is_equal(prop,
> > > > "xen,scmi-secondary-agents") )
> > > >                  continue;
> > > > 
> > > >              if ( dt_property_name_is_equal(prop, "xen,dom0-bootargs") )
> > > > diff --git a/xen/arch/arm/firmware/Kconfig
> > > > b/xen/arch/arm/firmware/Kconfig
> > > > index 5c5f0880c4..6b051c8ada 100644
> > > > --- a/xen/arch/arm/firmware/Kconfig
> > > > +++ b/xen/arch/arm/firmware/Kconfig
> > > > @@ -29,6 +29,17 @@ config SCMI_SMC
> > > >    driver domain.
> > > >    Use with EL3 firmware which supports only single SCMI OSPM agent.
> > > > 
> > > > +config SCMI_SMC_MA
> > > > + bool "Enable ARM SCMI SMC multi-agent driver"
> > > > + select ARM_SCI
> > > > + help
> > > > +   Enables SCMI SMC/HVC multi-agent in XEN to pass SCMI requests from
> > > > Domains
> > > > +   to EL3 firmware (TF-A) which supports multi-agent feature.
> > > > +   This feature allows to enable SCMI per Domain using unique SCMI
> > > > agent_id,
> > > > +   so Domain is identified by EL3 firmware as an SCMI Agent and can
> > > > access
> > > > +   allowed platform resources through dedicated SMC/HVC Shared memory
> > > > based
> > > > +   transport.
> > > > +
> > > > endchoice
> > > > 
> > > > endmenu
> > > > diff --git a/xen/arch/arm/firmware/Makefile
> > > > b/xen/arch/arm/firmware/Makefile
> > > > index 71bdefc24a..37927e690e 100644
> > > > --- a/xen/arch/arm/firmware/Makefile
> > > > +++ b/xen/arch/arm/firmware/Makefile
> > > > @@ -1,2 +1,3 @@
> > > > obj-$(CONFIG_ARM_SCI) += sci.o
> > > > obj-$(CONFIG_SCMI_SMC) += scmi-smc.o
> > > > +obj-$(CONFIG_SCMI_SMC_MA) += scmi-shmem.o scmi-smc-multiagent.o
> > > > diff --git a/xen/arch/arm/firmware/scmi-proto.h
> > > > b/xen/arch/arm/firmware/scmi-proto.h
> > > > new file mode 100644
> > > > index 0000000000..3f4b9c5d6b
> > > > --- /dev/null
> > > > +++ b/xen/arch/arm/firmware/scmi-proto.h
> > > > @@ -0,0 +1,164 @@
> > > > +/* SPDX-License-Identifier: GPL-2.0-only */
> > > > +/*
> > > > + * Arm System Control and Management Interface definitions
> > > > + * Version 3.0 (DEN0056C)
> > > > + *
> > > > + * Copyright (c) 2024 EPAM Systems
> > > > + */
> > > > +
> > > > +#ifndef XEN_ARCH_ARM_SCI_SCMI_PROTO_H_
> > > > +#define XEN_ARCH_ARM_SCI_SCMI_PROTO_H_
> > > 
> > > NIT: ARM_FIRMWARE_SCMI_PROTO_H
> > > 
> > > 
> > > > +#include 
> > > > +
> > > > +#define SCMI_SHORT_NAME_MAX_SIZE 16
> > > > +
> > > > +/* SCMI status codes. See section 4.1.4 */
> > > > +#define SCMI_SUCCESS              0
> > > > +#define SCMI_NOT_SUPPORTED      (-1)
> > > > +#define SCMI_INVALID_PARAMETERS (-2)
> > > > +#define SCMI_DENIED             (-3)
> > > > +#define SCMI_NOT_FOUND          (-4)
> > > > +#define SCMI_OUT_OF_RANGE       (-5)
> > > > +#define SCMI_BUSY               (-6)
> > > > +#define SCMI_COMMS_ERROR        (-7)
> > > > +#define SCMI_GENERIC_ERROR      (-8)
> > > > +#define SCMI_HARDWARE_ERROR     (-9)
> > > > +#define SCMI_PROTOCOL_ERROR     (-10)
> > > > +
> > > > +/* Protocol IDs */
> > > > +#define SCMI_BASE_PROTOCOL 0x10
> > > > +
> > > > +/* Base protocol message IDs */
> > > > +#define SCMI_BASE_PROTOCOL_VERSION            0x0
> > > > +#define SCMI_BASE_PROTOCOL_ATTIBUTES          0x1
> > > > +#define SCMI_BASE_PROTOCOL_MESSAGE_ATTRIBUTES 0x2
> > > > +#define SCMI_BASE_DISCOVER_AGENT              0x7
> > > > +#define SCMI_BASE_SET_DEVICE_PERMISSIONS      0x9
> > > > +#define SCMI_BASE_RESET_AGENT_CONFIGURATION   0xB
> > > > +
> > > > +typedef struct scmi_msg_header {
> > > > +    uint8_t id;
> > > > +    uint8_t type;
> > > > +    uint8_t protocol;
> > > > +    uint32_t status;
> > > > +} scmi_msg_header_t;
> > > > +
> > > > +/* Table 2 Message header format */
> > > > +#define SCMI_HDR_ID    GENMASK(7, 0)
> > > > +#define SCMI_HDR_TYPE  GENMASK(9, 8)
> > > > +#define SCMI_HDR_PROTO GENMASK(17, 10)
> > > > +
> > > > +#define SCMI_FIELD_GET(_mask, _reg)
> > > > \
> > > > +    ((typeof(_mask))(((_reg) & (_mask)) >> (ffs64(_mask) - 1)))
> > > > +#define SCMI_FIELD_PREP(_mask, _val)
> > > > \
> > > > +    (((typeof(_mask))(_val) << (ffs64(_mask) - 1)) & (_mask))
> > > > +
> > > > +static inline uint32_t pack_scmi_header(scmi_msg_header_t *hdr)
> > > > +{
> > > > +    return SCMI_FIELD_PREP(SCMI_HDR_ID, hdr->id) |
> > > > +           SCMI_FIELD_PREP(SCMI_HDR_TYPE, hdr->type) |
> > > > +           SCMI_FIELD_PREP(SCMI_HDR_PROTO, hdr->protocol);
> > > > +}
> > > > +
> > > > +static inline void unpack_scmi_header(uint32_t msg_hdr,
> > > > scmi_msg_header_t *hdr)
> > > > +{
> > > > +    hdr->id = SCMI_FIELD_GET(SCMI_HDR_ID, msg_hdr);
> > > > +    hdr->type = SCMI_FIELD_GET(SCMI_HDR_TYPE, msg_hdr);
> > > > +    hdr->protocol = SCMI_FIELD_GET(SCMI_HDR_PROTO, msg_hdr);
> > > > +}
> > > > +
> > > > +static inline int scmi_to_xen_errno(int scmi_status)
> > > > +{
> > > > +    if ( scmi_status == SCMI_SUCCESS )
> > > > +        return 0;
> > > > +
> > > > +    switch ( scmi_status )
> > > > +    {
> > > > +    case SCMI_NOT_SUPPORTED:
> > > > +        return -EOPNOTSUPP;
> > > > +    case SCMI_INVALID_PARAMETERS:
> > > > +        return -EINVAL;
> > > > +    case SCMI_DENIED:
> > > > +        return -EACCES;
> > > > +    case SCMI_NOT_FOUND:
> > > > +        return -ENOENT;
> > > > +    case SCMI_OUT_OF_RANGE:
> > > > +        return -ERANGE;
> > > > +    case SCMI_BUSY:
> > > > +        return -EBUSY;
> > > > +    case SCMI_COMMS_ERROR:
> > > > +        return -ENOTCONN;
> > > > +    case SCMI_GENERIC_ERROR:
> > > > +        return -EIO;
> > > > +    case SCMI_HARDWARE_ERROR:
> > > > +        return -ENXIO;
> > > > +    case SCMI_PROTOCOL_ERROR:
> > > > +        return -EBADMSG;
> > > > +    default:
> > > > +        return -EINVAL;
> > > > +    }
> > > > +}
> > > > +
> > > > +/* PROTOCOL_VERSION */
> > > > +#define SCMI_VERSION_MINOR GENMASK(15, 0)
> > > > +#define SCMI_VERSION_MAJOR GENMASK(31, 16)
> > > > +
> > > > +struct scmi_msg_prot_version_p2a {
> > > > +    uint32_t version;
> > > > +} __packed;
> > > > +
> > > > +/* BASE PROTOCOL_ATTRIBUTES */
> > > > +#define SCMI_BASE_ATTR_NUM_PROTO GENMASK(7, 0)
> > > > +#define SCMI_BASE_ATTR_NUM_AGENT GENMASK(15, 8)
> > > > +
> > > > +struct scmi_msg_base_attributes_p2a {
> > > > +    uint32_t attributes;
> > > > +} __packed;
> > > > +
> > > > +/*
> > > > + * BASE_DISCOVER_AGENT
> > > > + */
> > > > +#define SCMI_BASE_AGENT_ID_OWN 0xFFFFFFFF
> > > > +
> > > > +struct scmi_msg_base_discover_agent_a2p {
> > > > +    uint32_t agent_id;
> > > > +} __packed;
> > > > +
> > > > +struct scmi_msg_base_discover_agent_p2a {
> > > > +    uint32_t agent_id;
> > > > +    char name[SCMI_SHORT_NAME_MAX_SIZE];
> > > > +} __packed;
> > > > +
> > > > +/*
> > > > + * BASE_SET_DEVICE_PERMISSIONS
> > > > + */
> > > > +#define SCMI_BASE_DEVICE_ACCESS_ALLOW           BIT(0, UL)
> > > > +
> > > > +struct scmi_msg_base_set_device_permissions_a2p {
> > > > +    uint32_t agent_id;
> > > > +    uint32_t device_id;
> > > > +    uint32_t flags;
> > > > +} __packed;
> > > > +
> > > > +/*
> > > > + * BASE_RESET_AGENT_CONFIGURATION
> > > > + */
> > > > +#define SCMI_BASE_AGENT_PERMISSIONS_RESET       BIT(0, UL)
> > > > +
> > > > +struct scmi_msg_base_reset_agent_cfg_a2p {
> > > > +    uint32_t agent_id;
> > > > +    uint32_t flags;
> > > > +} __packed;
> > > > +
> > > > +#endif /* XEN_ARCH_ARM_SCI_SCMI_PROTO_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/arch/arm/firmware/scmi-shmem.c
> > > > b/xen/arch/arm/firmware/scmi-shmem.c
> > > > new file mode 100644
> > > > index 0000000000..dd613ee0b5
> > > > --- /dev/null
> > > > +++ b/xen/arch/arm/firmware/scmi-shmem.c
> > > > @@ -0,0 +1,173 @@
> > > > +/* SPDX-License-Identifier: GPL-2.0-only */
> > > > +/*
> > > > + * SCI SCMI multi-agent driver, using SMC/HVC shmem as transport.
> > > > + *
> > > > + * Oleksii Moisieiev 
> > > > + * Copyright (c) 2025 EPAM Systems
> > > > + */
> > > > +/* SPDX-License-Identifier: GPL-2.0-only */
> > > > +
> > > > +#include 
> > > > +#include 
> > > > +
> > > > +#include "scmi-proto.h"
> > > > +#include "scmi-shmem.h"
> > > 
> > > This code is written more generically than the description implies. If
> > > we only want to make SMC calls to TF-A on EL3 and exchange data with it
> > > over shared memory, then I think:
> > > - we don't need the __iomem tag, as there is no MMIO
> > 
> > agree
> > 
> > > - we only need a DMB, not a DSB (readl and writel imply DSB, use only
> > >   readl_relaxed and writel_relaxed)
> > 
> > agree
> > 
> > > 
> > > On the other hand, if we also want to handle the case where the SCMI
> > > server could be on a separate co-processor, then what this code is doing
> > > is not sufficient because we also need a dcache flush, in addition to
> > > the DSB.
> > > 
> > > Bertrand, can you double-check?
> > 
> > If we want to handle a case where the memory is accessible to a coprocessor
> > but there is no cache coherency, we need to flush the dcache definitely.
> > 
> > Seeing the amount of data here, I do agree with Stefano that it would be a
> > good
> > idea to make the provision to flush the data cache in all cases. Even if the
> > data
> > is accessed by a secure partition or the firmware coherently, flushing in
> > all cases
> > would have very limited performance impact here.
> > 
> > There is the other solution to have some kind of parameter to say if the
> > accessor
> > has coherent cache access but I do not think the performance impact here
> > would
> > justify such a complexity.
> > 
> The SCMI shmem expected to be mapped as MT_NON_CACHEABLE in all cases.

Is that part of the spec?


> The Linux does devm_ioremap() -> ioremap() ->
> (ARM64)  __ioremap((addr), (size), __pgprot(PROT_DEVICE_nGnRE))
> 
> There is also note in docs:
> "+- shmem: shared memory for messages transfer, **Xen page aligned** with
> mapping``p2m_mmio_direct_nc``."
> 
> In the case of SCP - the SCMI shmem can be actually be in SRAM.
> 
> So, are you sure cache manipulations are required here?

No, if the memory is mapped as uncacheable everywhere then the cache
manipulations are not needed. However, we probably still need a dsb.

I understand now why they decided to use __memcpy_fromio in Linux: it is
not MMIO but they needed a memcpy followed by DSB, so they decided to
reuse the existing MMIO functions although the buffer is not MMIO.

In Xen I would prefer we just used memcpy followed by DSB. The opinion
of other maintainers is very welcome.


From xen-devel-bounces@lists.xenproject.org Tue Jun 17 23:57:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jun 2025 23:57:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018612.1395484 (Exim 4.92)
	(envelope-from )
	id 1uRgAr-00073H-BG; Tue, 17 Jun 2025 23:57:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018612.1395484; Tue, 17 Jun 2025 23:57:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRgAr-00073A-60; Tue, 17 Jun 2025 23:57:05 +0000
Received: by outflank-mailman (input) for mailman id 1018612;
 Tue, 17 Jun 2025 23:57: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 1uRgAp-000733-UG
 for xen-devel@lists.xenproject.org; Tue, 17 Jun 2025 23:57:04 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id be0bd7d0-4bd6-11f0-a30a-13f23c93f187;
 Wed, 18 Jun 2025 01:56:53 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 5C6CA6111C;
 Tue, 17 Jun 2025 23:56:52 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4513BC4CEE3;
 Tue, 17 Jun 2025 23:56: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: be0bd7d0-4bd6-11f0-a30a-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750204612;
	bh=6co/NqIy1XaVnFLBhLEVyQ5k5/wpTLT6j9j0nPeOMqk=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=K/wn/J/RYSKewCQAcPkkrUjNmTCTTJDeCLr5hWjJjKwo2BHxsf1yp46vGv6GSxrUt
	 QHNJaPwCpj05bej6vpVQQGTMP9iMlsFGeKBmBmKcDmJ5gFilIcfignv/epsybuIHGq
	 Da72KwHN6EhXXFTtbXCN0jCrxvmklzXYQHK/YUfFTjz0b5abRiH0LiyaPdQZzApMQt
	 fSiBS1oHpPYyGHQFG9MWEQ70UGR7Avn8kz5ktfpPGz2IB0qBOVrVpVYOdXMpLvlEft
	 4d1FwNy2KSVQEUIdZVip/eJsMHVgCsq4ZfsCrqH35AYNBHm++hYuYC2lsT9mqSxYBY
	 VgjaFVb1WF5ig==
Date: Tue, 17 Jun 2025 16:56:48 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Stefano Stabellini 
cc: Oleksii Moisieiev , 
    "xen-devel@lists.xenproject.org" , 
    Andrew Cooper , 
    Anthony PERARD , 
    Bertrand Marquis , 
    Jan Beulich , Juergen Gross , 
    Julien Grall , Michal Orzel , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Volodymyr Babchuk , 
    Grygorii Strashko 
Subject: Re: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC
 multi-agent driver
In-Reply-To: 
Message-ID: 
References:  <318044ae12f13b6b297b3f5fda577a1a6cd143da.1747669845.git.oleksii_moisieiev@epam.com>  <6080ff71-2634-4269-8a63-fdafdf03f01b@epam.com>
 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1934469375-1750204611=:1780597"

  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-1934469375-1750204611=:1780597
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Tue, 17 Jun 2025, Stefano Stabellini wrote:
> On Thu, 12 Jun 2025, Oleksii Moisieiev wrote:
> > Hi Stefano,
> > 
> > I'm very sorry for a long silence. Please see my answers below:
> > 
> > 
> > On 23/05/2025 23:06, Stefano Stabellini wrote:
> > > One question for Bertrand below
> > >
> > >
> > > On Mon, 19 May 2025, Oleksii Moisieiev wrote:
> > >> This patch introduces SCI driver to support for ARM EL3 Trusted Firmware-A
> > >> (TF-A) which provides SCMI interface with multi-agnet support, as shown
> > >> below.
> > >>
> > >>    +-----------------------------------------+
> > >>    |                                         |
> > >>    | EL3 TF-A SCMI                           |
> > >>    +-------+--+-------+--+-------+--+-------++
> > >>    |shmem0 |  |shmem1 |  |shmem2 |  |shmemX |
> > >>    +-----+-+  +---+---+  +--+----+  +---+---+
> > >> smc-id0 |        |         |           |
> > >> agent0  |        |         |           |
> > >>    +-----v--------+---------+-----------+----+
> > >>    |              |         |           |    |
> > >>    |              |         |           |    |
> > >>    +--------------+---------+-----------+----+
> > >>           smc-id1 |  smc-id2|    smc-idX|
> > >>           agent1  |  agent2 |    agentX |
> > >>                   |         |           |
> > >>              +----v---+  +--v-----+  +--v-----+
> > >>              |        |  |        |  |        |
> > >>              | Dom0   |  | Dom1   |  | DomX   |
> > >>              |        |  |        |  |        |
> > >>              |        |  |        |  |        |
> > >>              +--------+  +--------+  +--------+
> > >>
> > >> The EL3 SCMI multi-agent firmware expected to provide SCMI SMC/HVC shared
> > >> memory transport for every Agent in the system.
> > >>
> > >> The SCMI Agent transport channel defined by pair:
> > >>   - smc-id: SMC/HVC id used for Doorbell
> > >>   - shmem: shared memory for messages transfer, Xen page aligned,
> > >>   p2m_mmio_direct_nc.
> > >>
> > >> The follwoing SCMI Agents expected to be defined by SCMI FW to enable SCMI
> > >> multi-agent functionality under Xen:
> > >> - Xen manegement agent: trusted agents that accesses to the Base Protocol
> > >> commands to configure agent specific permissions
> > >> - OSPM VM agents: non-trusted agent, one for each Guest domain which is
> > >>    allowed direct HW access. At least one OSPM VM agent has to be provided
> > >>    by FW if HW is handled only by Dom0 or Driver Domain.
> > >>
> > >> The EL3 SCMI FW expected to implement following Base protocol messages:
> > >> - BASE_DISCOVER_AGENT
> > >> - BASE_RESET_AGENT_CONFIGURATION (optional)
> > >> - BASE_SET_DEVICE_PERMISSIONS (optional)
> > >>
> > >> The SCI SCMI SMC multi-agent driver implements following functionality:
> > >> - It's initialized based on the Host DT SCMI node (only one SCMI interface
> > >> is supported) which describes Xen management agent SCMI interface.
> > >>
> > >> scmi_shm_0 : sram@47ff0000 {
> > >>      compatible = "arm,scmi-shmem";
> > >>      reg = <0x0 0x47ff0000 0x0 0x1000>;
> > >> };
> > >> firmware {
> > >>      scmi: scmi {
> > >>          compatible = "arm,scmi-smc";
> > >>          arm, smc - id = <0x82000002>; // Xen manegement agent smc-id
> > > some extra spaces, it might be a copy/paste error
> > +
> > >>          \#address-cells = < 1>;
> > >>          \#size-cells = < 0>;
> > >>          \#access-controller - cells = < 1>;
> > >>          shmem = <&scmi_shm_0>; // Xen manegement agent shmem
> > >>
> > >>          protocol@X{
> > >>          };
> > >>      };
> > >> };
> > >>
> > >> - It obtains Xen specific SCMI Agent's configuration from the Host DT,
> > >> probes Agents and build SCMI Agents list; The Agents configuration is taken from:
> > >>
> > >> chosen {
> > >>    xen,scmi-secondary-agents = <
> > >>              1 0x82000003 &scmi_shm_1
> > >>              2 0x82000004 &scmi_shm_2
> > >>              3 0x82000005 &scmi_shm_3
> > >>              4 0x82000006 &scmi_shm_4>;
> > >> }
> > >>
> > >> /{
> > >>      scmi_shm_1: sram@47ff1000 {
> > >>              compatible = "arm,scmi-shmem";
> > >>              reg = <0x0 0x47ff1000 0x0 0x1000>;
> > >>      };
> > >>      scmi_shm_2: sram@47ff2000 {
> > >>              compatible = "arm,scmi-shmem";
> > >>              reg = <0x0 0x47ff2000 0x0 0x1000>;
> > >>      };
> > >>      scmi_shm_3: sram@47ff3000 {
> > >>              compatible = "arm,scmi-shmem";
> > >>              reg = <0x0 0x47ff3000 0x0 0x1000>;
> > >>      };
> > >> }
> > >>    where first item is "agent_id", second - "arm,smc-id", and third - "arm,scmi-shmem" for
> > >>    this agent_id.
> > >>
> > >>    Note that Xen is the only one entry in the system which need to know
> > >>    about SCMI multi-agent support.
> > >>
> > >> - It implements the SCI subsystem interface required for configuring and
> > >> enabling SCMI functionality for Dom0/hwdom and Guest domains. To enable
> > >> SCMI functionality for domain it has to be configured with unique supported
> > >> SCMI Agent_id and use corresponding SCMI SMC/HVC shared memory transport
> > >> [smc-id, shmem] defined for this SCMI Agent_id.
> > >> - Once Xen domain is configured it can communicate with EL3 SCMI FW:
> > >>    -- zero-copy, the guest domain puts SCMI message in shmem;
> > >>    -- the guest triggers SMC/HVC exception with smc-id (doorbell);
> > >>    -- the Xen driver catches exception, do checks and synchronously forwards
> > >>    it to EL3 FW.
> > >> - the Xen driver sends BASE_RESET_AGENT_CONFIGURATION message to Xen
> > >>    management agent channel on domain destroy event. This allows to reset
> > >>    resources used by domain and so implement use-case like domain reboot.
> > >>
> > >> Dom0 Enable SCMI SMC:
> > >>   - pass dom0_scmi_agent_id= in Xen command line. if not provided
> > >>     SCMI will be disabled for Dom0 and all SCMI nodes removed from Dom0 DT.
> > >>     The driver updates Dom0 DT SCMI node "arm,smc-id" value and fix up shmem
> > >>     node according to assigned agent_id.
> > >>
> > >> Guest domains enable SCMI SMC:
> > >>   - xl.cfg: add configuration option as below
> > >>
> > >>     arm_sci = "type=scmi_smc_multiagent,agent_id=2"
> > >>
> > >>   - xl.cfg: enable access to the "arm,scmi-shmem" which should correspond assigned agent_id for
> > >>     the domain, for example:
> > >>
> > >> iomem = [
> > >>      "47ff2,1@22001",
> > >> ]
> > > Looking at the code and the configuration options, it looks like it is
> > > possible to map a scmi-shmem channel at a different address for the
> > > guest. It seems like it would work. Is that correct?
> > >
> > Yes it will. in our case address 22001000 should be the save as
> > sram@22001000 in the domain device-tree.
> > >>   - DT: add SCMI nodes to the Driver domain partial device tree as in the
> > >>   below example. The "arm,smc-id" should correspond assigned agent_id for the domain:
> > >>
> > >> passthrough {
> > >>     scmi_shm_0: sram@22001000 {
> > >>         compatible = "arm,scmi-shmem";
> > >>         reg = <0x0 0x22001000 0x0 0x1000>;
> > >>     };
> > >>
> > >>     firmware {
> > >>          compatible = "simple-bus";
> > >>              scmi: scmi {
> > >>                  compatible = "arm,scmi-smc";
> > >>                  arm,smc-id = <0x82000004>;
> > >>                  shmem = <&scmi_shm_0>;
> > >>                  ...
> > >>              }
> > >>      }
> > >> }
> > >>
> > >> SCMI "4.2.1.1 Device specific access control"
> > >>
> > >> The XEN SCI SCMI SMC multi-agent driver performs "access-controller" provider function
> > >> in case EL3 SCMI FW implements SCMI "4.2.1.1 Device specific access control" and provides the
> > >> BASE_SET_DEVICE_PERMISSIONS command to configure the devices that an agents have access to.
> > >> The DT SCMI node should "#access-controller-cells=<1>" property and DT devices should be bound
> > >> to the Xen SCMI.
> > >>
> > >> &i2c1 {
> > >>      access-controllers = <&scmi 0>;
> > >> };
> > >>
> > >> The Dom0 and dom0less domains DT devices will be processed automatically through
> > >> sci_assign_dt_device() call, but to assign SCMI devices from toolstack the xl.cfg:"dtdev" property
> > >> shell be used:
> > >>
> > >> dtdev = [
> > >>      "/soc/i2c@e6508000",
> > >> ]
> > >>
> > >> xl.cfg:dtdev will contain all nodes which are under SCMI management (not only those which are behind IOMMU).
> > >>
> > >> [1]https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > >> [2]https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/access-controllers/access-controllers.yaml
> > >> Signed-off-by: Oleksii Moisieiev
> > >> Signed-off-by: Grygorii Strashko
> > > Thanks for the long explanation, great work! I am really looking forward
> > > to have this feature in the tree soon.
> > >
> > >
> > >> ---
> > >>
> > >> Changes in v4:
> > >> - toolstack comments from Anthony PERARD
> > >> - added dom0less support
> > >> - added doc for "xen,scmi-secondary-agents"
> > >>
> > >>   docs/man/xl.cfg.5.pod.in                    |  13 +
> > >>   docs/misc/arm/device-tree/booting.txt       |  60 ++
> > >>   docs/misc/xen-command-line.pandoc           |   9 +
> > >>   tools/libs/light/libxl_arm.c                |   4 +
> > >>   tools/libs/light/libxl_types.idl            |   4 +-
> > >>   tools/xl/xl_parse.c                         |  12 +
> > >>   xen/arch/arm/dom0less-build.c               |  11 +
> > >>   xen/arch/arm/domain_build.c                 |   3 +-
> > >>   xen/arch/arm/firmware/Kconfig               |  11 +
> > >>   xen/arch/arm/firmware/Makefile              |   1 +
> > >>   xen/arch/arm/firmware/scmi-proto.h          | 164 ++++
> > >>   xen/arch/arm/firmware/scmi-shmem.c          | 173 ++++
> > >>   xen/arch/arm/firmware/scmi-shmem.h          |  45 +
> > >>   xen/arch/arm/firmware/scmi-smc-multiagent.c | 860 ++++++++++++++++++++
> > >>   xen/include/public/arch-arm.h               |   3 +
> > >>   15 files changed, 1371 insertions(+), 2 deletions(-)
> > >>   create mode 100644 xen/arch/arm/firmware/scmi-proto.h
> > >>   create mode 100644 xen/arch/arm/firmware/scmi-shmem.c
> > >>   create mode 100644 xen/arch/arm/firmware/scmi-shmem.h
> > >>   create mode 100644 xen/arch/arm/firmware/scmi-smc-multiagent.c
> > >>
> > >> diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> > >> index 1ccf50b8ea..302c46d8bc 100644
> > >> --- a/docs/man/xl.cfg.5.pod.in
> > >> +++ b/docs/man/xl.cfg.5.pod.in
> > >> @@ -3122,8 +3122,21 @@ single SCMI OSPM agent support.
> > >>   Should be used together with B Xen command line
> > >>   option.
> > >>
> > >> +=item B
> > >> +
> > >> +Enables ARM SCMI SMC multi-agent support for the guest by enabling SCMI over
> > >> +SMC calls forwarding from domain to the EL3 firmware (like Trusted Firmware-A)
> > >> +with a multi SCMI OSPM agent support. The SCMI B should be
> > >> +specified for the guest.
> > >> +
> > >>   =back
> > >>
> > >> +=item B
> > >> +
> > >> +Specifies a non-zero ARM SCI agent id for the guest. This option is mandatory
> > >> +if the SCMI SMC support is enabled for the guest. The agent ids of domains
> > >> +existing on a single host must be unique and in the range [1..255].
> > >> +
> > >>   =back
> > >>
> > >>   =back
> > >> diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
> > >> index 8943c04173..c8923ab8b2 100644
> > >> --- a/docs/misc/arm/device-tree/booting.txt
> > >> +++ b/docs/misc/arm/device-tree/booting.txt
> > >> @@ -296,6 +296,20 @@ with the following properties:
> > >>       Should be used together with dom0_scmi_smc_passthrough Xen command line
> > >>       option.
> > >>
> > >> +    - "scmi_smc_multiagent"
> > >> +
> > >> +    Enables ARM SCMI SMC multi-agent support for the guest by enabling SCMI over
> > >> +    SMC calls forwarding from domain to the EL3 firmware (like ARM
> > >> +    Trusted Firmware-A) with a multi SCMI OSPM agent support.
> > >> +    The SCMI agent_id should be specified for the guest with "xen,sci_agent_id"
> > >> +    property.
> > >> +
> > >> +- "xen,sci_agent_id"
> > >> +
> > >> +    Specifies a non-zero ARM SCI agent id for the guest. This option is
> > >> +    mandatory if the SCMI SMC "scmi_smc_multiagent" support is enabled for
> > >> +    the guest. The agent ids of guest must be unique and in the range [1..255].
> > >> +
> > >>   Under the "xen,domain" compatible node, one or more sub-nodes are present
> > >>   for the DomU kernel and ramdisk.
> > >>
> > >> @@ -764,3 +778,49 @@ The automatically allocated static shared memory will get mapped at
> > >>   0x80000000 in DomU1 guest physical address space, and at 0x90000000 in DomU2
> > >>   guest physical address space. DomU1 is explicitly defined as the owner domain,
> > >>   and DomU2 is the borrower domain.
> > >> +
> > >> +SCMI SMC multi-agent support
> > >> +============================
> > >> +
> > >> +For enabling the ARM SCMI SMC multi-agent support (enabled by CONFIG_SCMI_SMC_MA)
> > >> +the Xen specific SCMI Agent's configuration shell be provided in the Host DT
> > >> +according to the SCMI compliant EL3 Firmware specification with
> > >> +ARM SMC/HVC transport using property "xen,scmi-secondary-agents" under
> > >> +the top-level "chosen" node:
> > >> +
> > >> +- xen,scmi-secondary-agents
> > >> +
> > >> +    Defines a set of SCMI agents configuration supported by SCMI EL3 FW and
> > >> +    available for Xen. Each Agent defined as triple consisting of:
> > >> +    SCMI agent_id,
> > >> +    SMC/HVC function_id assigned for the agent transport ("arm,smc-id"),
> > >> +    phandle to SCMI SHM assigned for the agent transport ("arm,scmi-shmem").
> > >> +
> > >> +As an example:
> > >> +
> > >> +chosen {
> > >> +    xen,scmi-secondary-agents = <
> > >> +        1 0x82000003 &scmi_shm_1
> > >> +        2 0x82000004 &scmi_shm_2
> > >> +        3 0x82000005 &scmi_shm_3
> > >> +        4 0x82000006 &scmi_shm_4>;
> > >> +}
> > > NIT: it should be };
> > +
> > > Looking at scmi_probe, collect_agents, and the following SCMI
> > > SCMI_BASE_DISCOVER_AGENT request, I wonder: do we actually need this
> > > information?
> > >
> > > It looks like we can discover the agend_ids for every channel, I guess
> > > what we need to know is the shmem location for every channel? But the
> > > full list of shmem channel is available below thanks to the scmi-shmem
> > > nodes.
> > >
> > > So, we have the list of scmi-shmem anyway, and we can probe the
> > > agent_id. The only parameter left is the smc_id/func_id.
> > >
> > > Or maybe smc_id/func_id can be calculated from agent_id?
> > >
> > > I am asking mostly because if a user is supposed to add this
> > > xen,scmi-secondary-agents property, where are they supposed to find the
> > > smc_id/func_id information?
> > >
> > > It is important that we write down in this document how the user is
> > > expected to find out what 1 is 0x82000003 which is scmi_shm_1.
> > 
> > That's a very good question! The issue here is that there are no
> > 
> > explicit requirements defining the relationship between agent_id and
> > func_id.
> > 
> > 
> > For example, in ARM-TF, different implementations can use different
> > func_ids.
> > 
> > To provide better flexibility, we decided to separate agent_id from func_id.
> > 
> > 
> > Currently, the SCMI_BASE_DISCOVER_AGENT calls from the probe are intended to
> > 
> > verify that all registered agents are present and that the configuration
> > is correct.
> > 
> > However, I understand that this additional validation could be optional
> > to save traffic.
> > 
> > 
> > To address this, I’m considering adding a configuration option, such as
> > 
> > CONFIG_SCMI_AGENT_VALIDATION, which can be disabled to reduce boot time
> > if this
> > 
> > validation is not necessary for certain use cases.
> > 
> > 
> > Lastly, I’ll be updating the document to include clearer information
> > about the
> > 
> > relationship between func_id and agent_id in the upcoming v5.
>  
> The key point here is to make it easier for the user. If we can make
> agent_id or func_id optional it would make users lives easier.
> 
> Alternative, or in addition to this, we should make the docs as clear as
> possible so that people can figure it out without having to ask
> questions on xen-devel.
> 
>  
> > >> +/{
> > >> +        scmi_shm_1: sram@47ff1000 {
> > >> +                compatible = "arm,scmi-shmem";
> > >> +                reg = <0x0 0x47ff1000 0x0 0x1000>;
> > >> +        };
> > >> +        scmi_shm_2: sram@47ff2000 {
> > >> +                compatible = "arm,scmi-shmem";
> > >> +                reg = <0x0 0x47ff2000 0x0 0x1000>;
> > >> +        };
> > >> +        scmi_shm_3: sram@47ff3000 {
> > >> +                compatible = "arm,scmi-shmem";
> > >> +                reg = <0x0 0x47ff3000 0x0 0x1000>;
> > >> +        };
> > >> +        scmi_shm_3: sram@47ff4000 {
> > >> +                compatible = "arm,scmi-shmem";
> > >> +                reg = <0x0 0x47ff4000 0x0 0x1000>;
> > >> +        };
> > > Are these scmi_shm_1 - scmi_shm_3 under the top level device tree node?
> > > Or are under /firmware? Or are they under /chosen?
> > >
> > > I take they are under the top level node together with scmi_shm_0?
> > >
> > > Can you please also clarify in the document as well?
> > >
> > >
> > all these nodes are on the top level of the device-tree. But there is no
> > specific place for them.
> > 
> > They could be subnodes to some memory-region for example. I will clarify
> > this.
> > 
> > >> +}
> > >> diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
> > >> index 8e50f6b7c7..bc3c64d6ec 100644
> > >> --- a/docs/misc/xen-command-line.pandoc
> > >> +++ b/docs/misc/xen-command-line.pandoc
> > >> @@ -1091,6 +1091,15 @@ which serves as Driver domain. The SCMI will be disabled for Dom0/hwdom and
> > >>   SCMI nodes removed from Dom0/hwdom device tree.
> > >>   (for example, thin Dom0 with Driver domain use-case).
> > >>
> > >> +### dom0_scmi_agent_id (ARM)
> > >> +> `= `
> > >> +
> > >> +The option is available when `CONFIG_SCMI_SMC_MA` is compiled in, and allows to
> > >> +enable SCMI functionality for Dom0 by specifying a non-zero ARM SCMI agent id.
> > >> +The SCMI will be disabled for Dom0 if this option is not specified
> > >> +(for example, thin Dom0 or dom0less use-cases).
> > >> +The agent ids of domains existing on a single host must be unique.
> > >> +
> > >>   ### dtuart (ARM)
> > >>   > `= path [:options]`
> > >>
> > >> diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
> > >> index 28ba9eb787..7712f53cd4 100644
> > >> --- a/tools/libs/light/libxl_arm.c
> > >> +++ b/tools/libs/light/libxl_arm.c
> > >> @@ -229,6 +229,10 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
> > >>       case LIBXL_ARM_SCI_TYPE_SCMI_SMC:
> > >>           config->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC;
> > >>           break;
> > >> +    case LIBXL_ARM_SCI_TYPE_SCMI_SMC_MULTIAGENT:
> > >> +        config->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA;
> > >> +        config->arch.arm_sci_agent_id = d_config->b_info.arch_arm.arm_sci.agent_id;
> > >> +        break;
> > >>       default:
> > >>           LOG(ERROR, "Unknown ARM_SCI type %d",
> > >>               d_config->b_info.arch_arm.arm_sci.type);
> > >> diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl
> > >> index aa2190ab5b..11e31ce786 100644
> > >> --- a/tools/libs/light/libxl_types.idl
> > >> +++ b/tools/libs/light/libxl_types.idl
> > >> @@ -553,11 +553,13 @@ libxl_sve_type = Enumeration("sve_type", [
> > >>
> > >>   libxl_arm_sci_type = Enumeration("arm_sci_type", [
> > >>       (0, "none"),
> > >> -    (1, "scmi_smc")
> > >> +    (1, "scmi_smc"),
> > >> +    (2, "scmi_smc_multiagent")
> > >>       ], init_val = "LIBXL_ARM_SCI_TYPE_NONE")
> > >>
> > >>   libxl_arm_sci = Struct("arm_sci", [
> > >>       ("type", libxl_arm_sci_type),
> > >> +    ("agent_id", uint8)
> > >>       ])
> > >>
> > >>   libxl_rdm_reserve = Struct("rdm_reserve", [
> > >> diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
> > >> index bd22be9d33..81aa3797e3 100644
> > >> --- a/tools/xl/xl_parse.c
> > >> +++ b/tools/xl/xl_parse.c
> > >> @@ -1306,6 +1306,18 @@ static int parse_arm_sci_config(XLU_Config *cfg, libxl_arm_sci *arm_sci,
> > >>               }
> > >>           }
> > >>
> > >> +        if (MATCH_OPTION("agent_id", ptr, oparg)) {
> > >> +            unsigned long val = parse_ulong(oparg);
> > >> +
> > >> +            if (!val || val > 255) {
> > >> +                fprintf(stderr, "An invalid ARM_SCI agent_id specified (%lu). Valid range [1..255]\n",
> > >> +                        val);
> > >> +                ret = ERROR_INVAL;
> > >> +                goto parse_error;
> > >> +            }
> > >> +            arm_sci->agent_id = val;
> > >> +        }
> > >> +
> > >>           ptr = strtok(NULL, ",");
> > >>       }
> > >>
> > >> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
> > >> index 0a00f03a25..43d21eb889 100644
> > >> --- a/xen/arch/arm/dom0less-build.c
> > >> +++ b/xen/arch/arm/dom0less-build.c
> > >> @@ -835,6 +835,17 @@ int __init domu_dt_sci_parse(struct dt_device_node *node,
> > >>           d_cfg->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_NONE;
> > >>       else if ( !strcmp(sci_type, "scmi_smc") )
> > >>           d_cfg->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC;
> > >> +    else if ( !strcmp(sci_type, "scmi_smc_multiagent") )
> > >> +    {
> > >> +        uint32_t agent_id = 0;
> > >> +
> > >> +        if ( !dt_property_read_u32(node, "xen,sci_agent_id", &agent_id) ||
> > >> +             !agent_id )
> > > shouldn't we check that agent_id <= 255 ?
> > 
> > I see no limitation about max agent_id in DEN0056E document, it's uint32_t.
> > 
> > >> +            return -EINVAL;
> > >> +
> > >> +        d_cfg->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA;
> > >> +        d_cfg->arch.arm_sci_agent_id = agent_id;
> > >> +    }
> > >>       else
> > >>       {
> > >>           printk(XENLOG_ERR "xen,sci_type in not valid (%s) for domain %s\n",
> > >> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > >> index 36d28b52a4..0c9274a2b3 100644
> > >> --- a/xen/arch/arm/domain_build.c
> > >> +++ b/xen/arch/arm/domain_build.c
> > >> @@ -616,7 +616,8 @@ static int __init write_properties(struct domain *d, struct kernel_info *kinfo,
> > >>                    dt_property_name_is_equal(prop, "linux,uefi-mmap-start") ||
> > >>                    dt_property_name_is_equal(prop, "linux,uefi-mmap-size") ||
> > >>                    dt_property_name_is_equal(prop, "linux,uefi-mmap-desc-size") ||
> > >> -                 dt_property_name_is_equal(prop, "linux,uefi-mmap-desc-ver"))
> > >> +                 dt_property_name_is_equal(prop, "linux,uefi-mmap-desc-ver") ||
> > >> +                 dt_property_name_is_equal(prop, "xen,scmi-secondary-agents") )
> > >>                   continue;
> > >>
> > >>               if ( dt_property_name_is_equal(prop, "xen,dom0-bootargs") ) diff --git a/xen/arch/arm/firmware/Kconfig
> > >> b/xen/arch/arm/firmware/Kconfig index 5c5f0880c4..6b051c8ada 100644
> > >> --- a/xen/arch/arm/firmware/Kconfig +++
> > >> b/xen/arch/arm/firmware/Kconfig @@ -29,6 +29,17 @@ config SCMI_SMC
> > >> driver domain. Use with EL3 firmware which supports only single SCMI
> > >> OSPM agent. +config SCMI_SMC_MA + bool "Enable ARM SCMI SMC multi-agent driver"
> > >> +    select ARM_SCI
> > >> +    help
> > >> +      Enables SCMI SMC/HVC multi-agent in XEN to pass SCMI requests from Domains
> > >> +      to EL3 firmware (TF-A) which supports multi-agent feature.
> > >> +      This feature allows to enable SCMI per Domain using unique SCMI agent_id,
> > >> +      so Domain is identified by EL3 firmware as an SCMI Agent and can access
> > >> +      allowed platform resources through dedicated SMC/HVC Shared memory based
> > >> +      transport.
> > >> +
> > >>   endchoice
> > >>
> > >>   endmenu
> > >> diff --git a/xen/arch/arm/firmware/Makefile b/xen/arch/arm/firmware/Makefile
> > >> index 71bdefc24a..37927e690e 100644
> > >> --- a/xen/arch/arm/firmware/Makefile
> > >> +++ b/xen/arch/arm/firmware/Makefile
> > >> @@ -1,2 +1,3 @@
> > >>   obj-$(CONFIG_ARM_SCI) += sci.o
> > >>   obj-$(CONFIG_SCMI_SMC) += scmi-smc.o
> > >> +obj-$(CONFIG_SCMI_SMC_MA) += scmi-shmem.o scmi-smc-multiagent.o
> > >> diff --git a/xen/arch/arm/firmware/scmi-proto.h b/xen/arch/arm/firmware/scmi-proto.h
> > >> new file mode 100644
> > >> index 0000000000..3f4b9c5d6b
> > >> --- /dev/null
> > >> +++ b/xen/arch/arm/firmware/scmi-proto.h
> > >> @@ -0,0 +1,164 @@
> > >> +/* SPDX-License-Identifier: GPL-2.0-only */
> > >> +/*
> > >> + * Arm System Control and Management Interface definitions
> > >> + * Version 3.0 (DEN0056C)
> > >> + *
> > >> + * Copyright (c) 2024 EPAM Systems
> > >> + */
> > >> +
> > >> +#ifndef XEN_ARCH_ARM_SCI_SCMI_PROTO_H_
> > >> +#define XEN_ARCH_ARM_SCI_SCMI_PROTO_H_
> > > NIT: ARM_FIRMWARE_SCMI_PROTO_H
> > +
> > >> +#include 
> > >> +
> > >> +#define SCMI_SHORT_NAME_MAX_SIZE 16
> > >> +
> > >> +/* SCMI status codes. See section 4.1.4 */
> > >> +#define SCMI_SUCCESS              0
> > >> +#define SCMI_NOT_SUPPORTED      (-1)
> > >> +#define SCMI_INVALID_PARAMETERS (-2)
> > >> +#define SCMI_DENIED             (-3)
> > >> +#define SCMI_NOT_FOUND          (-4)
> > >> +#define SCMI_OUT_OF_RANGE       (-5)
> > >> +#define SCMI_BUSY               (-6)
> > >> +#define SCMI_COMMS_ERROR        (-7)
> > >> +#define SCMI_GENERIC_ERROR      (-8)
> > >> +#define SCMI_HARDWARE_ERROR     (-9)
> > >> +#define SCMI_PROTOCOL_ERROR     (-10)
> > >> +
> > >> +/* Protocol IDs */
> > >> +#define SCMI_BASE_PROTOCOL 0x10
> > >> +
> > >> +/* Base protocol message IDs */
> > >> +#define SCMI_BASE_PROTOCOL_VERSION            0x0
> > >> +#define SCMI_BASE_PROTOCOL_ATTIBUTES          0x1
> > >> +#define SCMI_BASE_PROTOCOL_MESSAGE_ATTRIBUTES 0x2
> > >> +#define SCMI_BASE_DISCOVER_AGENT              0x7
> > >> +#define SCMI_BASE_SET_DEVICE_PERMISSIONS      0x9
> > >> +#define SCMI_BASE_RESET_AGENT_CONFIGURATION   0xB
> > >> +
> > >> +typedef struct scmi_msg_header {
> > >> +    uint8_t id;
> > >> +    uint8_t type;
> > >> +    uint8_t protocol;
> > >> +    uint32_t status;
> > >> +} scmi_msg_header_t;
> > >> +
> > >> +/* Table 2 Message header format */
> > >> +#define SCMI_HDR_ID    GENMASK(7, 0)
> > >> +#define SCMI_HDR_TYPE  GENMASK(9, 8)
> > >> +#define SCMI_HDR_PROTO GENMASK(17, 10)
> > >> +
> > >> +#define SCMI_FIELD_GET(_mask, _reg)                                            \
> > >> +    ((typeof(_mask))(((_reg) & (_mask)) >> (ffs64(_mask) - 1)))
> > >> +#define SCMI_FIELD_PREP(_mask, _val)                                           \
> > >> +    (((typeof(_mask))(_val) << (ffs64(_mask) - 1)) & (_mask))
> > >> +
> > >> +static inline uint32_t pack_scmi_header(scmi_msg_header_t *hdr)
> > >> +{
> > >> +    return SCMI_FIELD_PREP(SCMI_HDR_ID, hdr->id) |
> > >> +           SCMI_FIELD_PREP(SCMI_HDR_TYPE, hdr->type) |
> > >> +           SCMI_FIELD_PREP(SCMI_HDR_PROTO, hdr->protocol);
> > >> +}
> > >> +
> > >> +static inline void unpack_scmi_header(uint32_t msg_hdr, scmi_msg_header_t *hdr)
> > >> +{
> > >> +    hdr->id = SCMI_FIELD_GET(SCMI_HDR_ID, msg_hdr);
> > >> +    hdr->type = SCMI_FIELD_GET(SCMI_HDR_TYPE, msg_hdr);
> > >> +    hdr->protocol = SCMI_FIELD_GET(SCMI_HDR_PROTO, msg_hdr);
> > >> +}
> > >> +
> > >> +static inline int scmi_to_xen_errno(int scmi_status)
> > >> +{
> > >> +    if ( scmi_status == SCMI_SUCCESS )
> > >> +        return 0;
> > >> +
> > >> +    switch ( scmi_status )
> > >> +    {
> > >> +    case SCMI_NOT_SUPPORTED:
> > >> +        return -EOPNOTSUPP;
> > >> +    case SCMI_INVALID_PARAMETERS:
> > >> +        return -EINVAL;
> > >> +    case SCMI_DENIED:
> > >> +        return -EACCES;
> > >> +    case SCMI_NOT_FOUND:
> > >> +        return -ENOENT;
> > >> +    case SCMI_OUT_OF_RANGE:
> > >> +        return -ERANGE;
> > >> +    case SCMI_BUSY:
> > >> +        return -EBUSY;
> > >> +    case SCMI_COMMS_ERROR:
> > >> +        return -ENOTCONN;
> > >> +    case SCMI_GENERIC_ERROR:
> > >> +        return -EIO;
> > >> +    case SCMI_HARDWARE_ERROR:
> > >> +        return -ENXIO;
> > >> +    case SCMI_PROTOCOL_ERROR:
> > >> +        return -EBADMSG;
> > >> +    default:
> > >> +        return -EINVAL;
> > >> +    }
> > >> +}
> > >> +
> > >> +/* PROTOCOL_VERSION */
> > >> +#define SCMI_VERSION_MINOR GENMASK(15, 0)
> > >> +#define SCMI_VERSION_MAJOR GENMASK(31, 16)
> > >> +
> > >> +struct scmi_msg_prot_version_p2a {
> > >> +    uint32_t version;
> > >> +} __packed;
> > >> +
> > >> +/* BASE PROTOCOL_ATTRIBUTES */
> > >> +#define SCMI_BASE_ATTR_NUM_PROTO GENMASK(7, 0)
> > >> +#define SCMI_BASE_ATTR_NUM_AGENT GENMASK(15, 8)
> > >> +
> > >> +struct scmi_msg_base_attributes_p2a {
> > >> +    uint32_t attributes;
> > >> +} __packed;
> > >> +
> > >> +/*
> > >> + * BASE_DISCOVER_AGENT
> > >> + */
> > >> +#define SCMI_BASE_AGENT_ID_OWN 0xFFFFFFFF
> > >> +
> > >> +struct scmi_msg_base_discover_agent_a2p {
> > >> +    uint32_t agent_id;
> > >> +} __packed;
> > >> +
> > >> +struct scmi_msg_base_discover_agent_p2a {
> > >> +    uint32_t agent_id;
> > >> +    char name[SCMI_SHORT_NAME_MAX_SIZE];
> > >> +} __packed;
> > >> +
> > >> +/*
> > >> + * BASE_SET_DEVICE_PERMISSIONS
> > >> + */
> > >> +#define SCMI_BASE_DEVICE_ACCESS_ALLOW           BIT(0, UL)
> > >> +
> > >> +struct scmi_msg_base_set_device_permissions_a2p {
> > >> +    uint32_t agent_id;
> > >> +    uint32_t device_id;
> > >> +    uint32_t flags;
> > >> +} __packed;
> > >> +
> > >> +/*
> > >> + * BASE_RESET_AGENT_CONFIGURATION
> > >> + */
> > >> +#define SCMI_BASE_AGENT_PERMISSIONS_RESET       BIT(0, UL)
> > >> +
> > >> +struct scmi_msg_base_reset_agent_cfg_a2p {
> > >> +    uint32_t agent_id;
> > >> +    uint32_t flags;
> > >> +} __packed;
> > >> +
> > >> +#endif /* XEN_ARCH_ARM_SCI_SCMI_PROTO_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/arch/arm/firmware/scmi-shmem.c b/xen/arch/arm/firmware/scmi-shmem.c
> > >> new file mode 100644
> > >> index 0000000000..dd613ee0b5
> > >> --- /dev/null
> > >> +++ b/xen/arch/arm/firmware/scmi-shmem.c
> > >> @@ -0,0 +1,173 @@
> > >> +/* SPDX-License-Identifier: GPL-2.0-only */
> > >> +/*
> > >> + * SCI SCMI multi-agent driver, using SMC/HVC shmem as transport.
> > >> + *
> > >> + * Oleksii Moisieiev
> > >> + * Copyright (c) 2025 EPAM Systems
> > >> + */
> > >> +/* SPDX-License-Identifier: GPL-2.0-only */
> > >> +
> > >> +#include 
> > >> +#include 
> > >> +
> > >> +#include "scmi-proto.h"
> > >> +#include "scmi-shmem.h"
> > > This code is written more generically than the description implies. If
> > > we only want to make SMC calls to TF-A on EL3 and exchange data with it
> > > over shared memory, then I think:
> > > - we don't need the __iomem tag, as there is no MMIO
> > > - we only need a DMB, not a DSB (readl and writel imply DSB, use only
> > >    readl_relaxed and writel_relaxed)
> > >
> > > On the other hand, if we also want to handle the case where the SCMI
> > > server could be on a separate co-processor, then what this code is doing
> > > is not sufficient because we also need a dcache flush, in addition to
> > > the DSB.
> > >
> > > Bertrand, can you double-check?
> > >
> > >
> > >> +/*
> > >> + * Copy data from IO memory space to "real" memory space.
> > >> + */
> > >> +static void __memcpy_fromio(void *to, const volatile void __iomem *from,
> > >> +                            size_t count)
> > >> +{
> > >> +    while ( count && !IS_ALIGNED((unsigned long)from, 4) )
> > >> +    {
> > >> +        *(u8 *)to = readb_relaxed(from);
> > >> +        from++;
> > >> +        to++;
> > >> +        count--;
> > >> +    }
> > >> +
> > >> +    while ( count >= 4 )
> > >> +    {
> > >> +        *(u32 *)to = readl_relaxed(from);
> > >> +        from += 4;
> > >> +        to += 4;
> > >> +        count -= 4;
> > >> +    }
> > >> +
> > >> +    while ( count )
> > >> +    {
> > >> +        *(u8 *)to = readb_relaxed(from);
> > >> +        from++;
> > >> +        to++;
> > >> +        count--;
> > >> +    }
> > >> +}
> > >> +
> > >> +/*
> > >> + * Copy data from "real" memory space to IO memory space.
> > >> + */
> > >> +static void __memcpy_toio(volatile void __iomem *to, const void *from,
> > >> +                          size_t count)
> > >> +{
> > >> +    while ( count && !IS_ALIGNED((unsigned long)to, 4) )
> > >> +    {
> > >> +        writeb_relaxed(*(u8 *)from, to);
> > >> +        from++;
> > >> +        to++;
> > >> +        count--;
> > >> +    }
> > >> +
> > >> +    while ( count >= 4 )
> > >> +    {
> > >> +        writel_relaxed(*(u32 *)from, to);
> > >> +        from += 4;
> > >> +        to += 4;
> > >> +        count -= 4;
> > >> +    }
> > >> +
> > >> +    while ( count )
> > >> +    {
> > >> +        writeb_relaxed(*(u8 *)from, to);
> > >> +        from++;
> > >> +        to++;
> > >> +        count--;
> > >> +    }
> > >> +}
> > > I don't understand why we need __memcpy_fromio and __memcpy_toio: can't
> > > we use a simple memcpy?
> > 
> > This approach was used because we're trying to access shared memory
> > between two independent systems:
> > 
> > Arm-TF and Xen in our case which places some chunks of data to the same
> > memory. And, according to the [0]
> > 
> > ```
> > 
> > Some devices (such as framebuffers) would like to use larger transfers than
> > 8 bytes at a time. For these devices, the memcpy_toio(),
> > memcpy_fromio() and memset_io() functions are
> > provided. Do not use memset or memcpy on IO addresses; they are not
> > guaranteed to copy data in order.
> > 
> > ```
> > 
> > Also, the same approach was used by Arm team when introducing scmi
> > driver to the Linux kernel [1]
> > 
> > 
> > [0]: https://www.kernel.org/doc/Documentation/driver-api/device-io.rst
> > 
> > [1]:https://git.iliana.fyi/linux/patch/?id=d5141f37c42e0b833863f157ac4cee203b2ba3d2
> 
> 
> Keep in mind that [0] refers specifically to access to MMIO regions. I
> assume that the SCMI shared buffers are on normal memory? Regarding [1],
> it makes sense if Linux is trying to support shared memory over MMIO.
> 
> Looking at one of your replies below, I am guessing the memory buffers
> are actually in normal memory but the issue is that TF-A is mapping them
> as uncacheable. Is that correct?
> 
> In that case, I still don't understand why a simple memcpy would not be
> sufficient. Can you check?
> 
> If yes, then for now I would just simplify it down to memcpy. When
> someone adds support for an SCMI server elsewhere we could look into
> adding a more sophisticated memcpy and we can look at the details at
> that point in time. Specifically, I am not convinced that memcpy_toio
> and memcpy_fromio would work if the SCMI server is on a separate
> non-coherent microcontroller.

See my other reply: https://marc.info/?l=xen-devel&m=175020352903542

I think we should implement this as:
memcpy(to, from, count); dsb(st or ld);
--8323329-1934469375-1750204611=:1780597--


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 00:04:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 00:04:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018623.1395492 (Exim 4.92)
	(envelope-from )
	id 1uRgIM-000111-To; Wed, 18 Jun 2025 00:04:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018623.1395492; Wed, 18 Jun 2025 00:04:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRgIM-00010u-Qk; Wed, 18 Jun 2025 00:04:50 +0000
Received: by outflank-mailman (input) for mailman id 1018623;
 Wed, 18 Jun 2025 00:04: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 1uRgIK-00010o-PD
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 00:04:48 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org
 [2600:3c04:e001:324:0:1991:8:25])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d80b5d08-4bd7-11f0-a30a-13f23c93f187;
 Wed, 18 Jun 2025 02:04:47 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id C438A629C5;
 Wed, 18 Jun 2025 00:04:45 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id A5AEEC4CEE3;
 Wed, 18 Jun 2025 00:04: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: d80b5d08-4bd7-11f0-a30a-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750205085;
	bh=S6LmIBSMSPvwWa/NclMirxSjiCctzIioVBLdBfRn+KY=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=LTsV6rghZVpjqMlZATeWN7t9JDCwKUtA5u0ho7PUcD3k7Ey+qHF32WFFA9E8NV4iY
	 8pYTtJrP09jDLyWxFmnHdzHCvSHtXRBeJv2eHpWDYgyy8z/8fjAx8tu+rRTAXy3SO/
	 YdikwLn7QXdw+jV9g4FdxAIKu8x5+g2K4wybf+lVhEULWt/3R6NXz53rcLrrcrzbZr
	 djOxH52MqVYrX+w2x4FFympxPfr2pRRy886sZyrST63cRzE9VJ0bfb08ApYfiphXbS
	 gnV/2+LWslYqhH++CJiQ7Q38rfIud7Ag5ikXrodZSfZIg3bivWLRDKP++ZzbC0XDHu
	 b9q6Za8MYkHsA==
Date: Tue, 17 Jun 2025 17:04:42 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Oleksii Moisieiev 
cc: Stefano Stabellini , 
    "xen-devel@lists.xenproject.org" , 
    Andrew Cooper , 
    Anthony PERARD , 
    Bertrand Marquis , 
    Jan Beulich , Juergen Gross , 
    Julien Grall , Michal Orzel , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Volodymyr Babchuk , 
    Grygorii Strashko 
Subject: Re: [RFC PATCH v4 5/8] xen/domctl: extend XEN_DOMCTL_assign_device
 to handle not only iommu
In-Reply-To: 
Message-ID: 
References:  <4f58bf9c47c40413ee9250c4cd21458382aac857.1747669845.git.oleksii_moisieiev@epam.com> 
 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1675787614-1750205085=:1780597"

  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-1675787614-1750205085=:1780597
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Thu, 12 Jun 2025, Oleksii Moisieiev wrote:
> Hi Stefano,
> 
> I'm very sorry for a long silence. Please see my answers below:
> 
> On 22/05/2025 03:25, Stefano Stabellini wrote:
> > On Mon, 19 May 2025, Oleksii Moisieiev wrote:
> >> From: Grygorii Strashko
> >>
> >> Add chained handling of assigned DT devices to support access-controller
> >> functionality through SCI framework, so DT device assign request can be
> >> passed to FW for processing and enabling VM access to requested device
> >> (for example, device power management through FW interface like SCMI).
> >>
> >> The SCI access-controller DT device processing is chained after IOMMU
> >> processing and expected to be executed for any DT device regardless of its
> >> protection by IOMMU (or if IOMMU is disabled).
> >>
> >> This allows to pass not only IOMMU protected DT device through
> >> xl.cfg:"dtdev" property for processing:
> >>
> >> dtdev = [
> >>      "/soc/video@e6ef0000", <- IOMMU protected device
> >>      "/soc/i2c@e6508000", <- not IOMMU protected device
> >> ]
> >>
> >> The change is done in two parts:
> >> 1) update iommu_do_dt_domctl() to check for dt_device_is_protected() and
> >> not fail if DT device is not protected by IOMMU
> >> 2) add chained call to sci_do_domctl() in do_domctl()
> >>
> >> Signed-off-by: Grygorii Strashko
> >> Signed-off-by: Oleksii Moisieiev
> >> ---
> >>
> >>
> >>
> >>   xen/arch/arm/firmware/sci.c             | 37 +++++++++++++++++++++++++
> >>   xen/arch/arm/include/asm/firmware/sci.h | 14 ++++++++++
> >>   xen/common/domctl.c                     | 19 +++++++++++++
> >>   xen/drivers/passthrough/device_tree.c   |  6 ++++
> >>   4 files changed, 76 insertions(+)
> >>
> >> diff --git a/xen/arch/arm/firmware/sci.c b/xen/arch/arm/firmware/sci.c
> >> index e1522e10e2..8efd541c4f 100644
> >> --- a/xen/arch/arm/firmware/sci.c
> >> +++ b/xen/arch/arm/firmware/sci.c
> >> @@ -126,6 +126,43 @@ int sci_assign_dt_device(struct domain *d, struct dt_device_node *dev)
> >>       return 0;
> >>   }
> >>   
> >> +int sci_do_domctl(struct xen_domctl *domctl, struct domain *d,
> >> +                  XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
> >> +{
> >> +    struct dt_device_node *dev;
> >> +    int ret = 0;
> >> +
> >> +    switch ( domctl->cmd )
> >> +    {
> >> +    case XEN_DOMCTL_assign_device:
> >> +        ret = -EOPNOTSUPP;
> > Are you sure -EOPNOTSUPP is the right error code for the 3 checks below?
> 
> The -EOPNOTSUPP code is used because this is part of a chained call after
> iommu_do_domctl, as stated in xen/common/domctl.c:859. The 
> XEN_DOMCTL_assign_device
> call is expected to handle any DT device, regardless of whether the DT 
> device is
> protected by an IOMMU or if the IOMMU is disabled.
> The following cases are considered:
> 
> 1. IOMMU Protected Device (Success)
> 
> If the device is protected by the IOMMU and iommu_do_domctl returns 0, 
> we continue
> processing the DT device by calling sci_do_domctl.
> 
> 2. IOMMU Disabled (-EOPNOTSUPP from iommu_do_domctl)
> 
> If iommu_do_domctl returns -EOPNOTSUPP, indicating that the IOMMU is 
> disabled,
> we still proceed to call sci_do_domctl.

OK this makes sense.  I think it is OK to have a special error code to
say "the IOMMU is disabled" but I don't know if it is a good idea to try
to use -EOPNOTSUPP for that. -EOPNOTSUPP could mean a hypervisor
configuration with domctl disabled, for instance.

It might be wiser to use a different error code. Maybe ENOENT?


> 3. Error from iommu_do_domctl (Fail State)
> 
> If iommu_do_domctl returns any error, the system enters a fail state, and
> sci_do_domctl is not called.
> 
> 4. -EOPNOTSUPP from sci_do_domctl
> 
> If sci_do_domctl returns -EOPNOTSUPP, this indicates one of the following:
> - The provided device is not a DT device.
> - There is no cur_mediator available (indicating that the SCI subsystem 
> is enabled
> in the configuration, but no mediator was provided).
> - The current mediator does not support assign_dt_device (this is 
> expected to be changed;
> see below for details).
> In this case, -EOPNOTSUPP is returned but will be ignored, and the 
> original return value from iommu_do_domctl will be used as the final result.

Same comment as before. We need to be careful not confuse this case you
described with other cases where sci_do_domctl is simply not
implemented.


> 5. Return Code from sci_do_domctl
> 
> If sci_do_domctl returns 0 (success) or an error code (failure),
> the return value from iommu_do_domctl is overridden, and the result from 
> sci_do_domctl is returned.
> Note: -EOPNOTSUPP from iommu_do_domctl will also be overridden since
> step 2 was successfully completed (or failed).
> >> +        if ( domctl->u.assign_device.dev != XEN_DOMCTL_DEV_DT )
> >> +            break;
> > this one
> >
> >> +        if ( !cur_mediator )
> >> +            break;
> > this one
> >
> >> +        if ( !cur_mediator->assign_dt_device )
> >> +            break;
> > and also this one? It seems more like an -EINVAL as the caller used a
> > wrong parameter?
> 
> I think you are right that this case should return -EINVAL because we 
> should fail if mediator
> 
> without implemented mandatory features was provided. Will be fixed.
> 
> >> +        ret = dt_find_node_by_gpath(domctl->u.assign_device.u.dt.path,
> >> +                                    domctl->u.assign_device.u.dt.size, &dev);
> >> +        if ( ret )
> >> +            return ret;
> >> +
> >> +        ret = sci_assign_dt_device(d, dev);
> >> +        if ( ret )
> >> +            break;
> >> +
> >> +        break;
> >> +    default:
> >> +        /* do not fail here as call is chained with iommu handling */
> > It looks like this should be an error
> >
> >
> >> +        break;
> >> +    }
> >> +
> >> +    return ret;
> >> +}
> >> +
> >>   static int __init sci_init(void)
> >>   {
> >>       struct dt_device_node *np;
> >> diff --git a/xen/arch/arm/include/asm/firmware/sci.h b/xen/arch/arm/include/asm/firmware/sci.h
> >> index 71fb54852e..b8d1bc8a62 100644
> >> --- a/xen/arch/arm/include/asm/firmware/sci.h
> >> +++ b/xen/arch/arm/include/asm/firmware/sci.h
> >> @@ -146,6 +146,14 @@ int sci_dt_finalize(struct domain *d, void *fdt);
> >>    * control" functionality.
> >>    */
> >>   int sci_assign_dt_device(struct domain *d, struct dt_device_node *dev);
> >> +
> >> +/*
> >> + * SCI domctl handler
> >> + *
> >> + * Only XEN_DOMCTL_assign_device is handled for now.
> >> + */
> >> +int sci_do_domctl(struct xen_domctl *domctl, struct domain *d,
> >> +                  XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl);
> >>   #else
> >>   
> >>   static inline bool sci_domain_is_enabled(struct domain *d)
> >> @@ -195,6 +203,12 @@ static inline int sci_assign_dt_device(struct domain *d,
> >>       return 0;
> >>   }
> >>   
> >> +static inline int sci_do_domctl(struct xen_domctl *domctl, struct domain *d,
> >> +                                XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
> >> +{
> >> +    return 0;
> >> +}
> >> +
> >>   #endif /* CONFIG_ARM_SCI */
> >>   
> >>   #endif /* __ASM_ARM_SCI_H */
> >> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> >> index 05abb581a0..a74ee92067 100644
> >> --- a/xen/common/domctl.c
> >> +++ b/xen/common/domctl.c
> >> @@ -27,6 +27,7 @@
> >>   #include 
> >>   #include 
> >>   #include 
> >> +#include 
> >>   #include 
> >>   #include 
> >>   #include 
> >> @@ -851,6 +852,24 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
> >>       case XEN_DOMCTL_deassign_device:
> >>       case XEN_DOMCTL_get_device_group:
> >>           ret = iommu_do_domctl(op, d, u_domctl);
> >> +
> >> +        if ( !ret || ret == -EOPNOTSUPP )
> > It is better to invert the check:
> >
> > if ( ret < 0 && ret != -EOPNOTSUPP )
> >      return ret;
> +
> >> +        {
> >> +            int ret1;
> >> +            /*
> >> +             * Add chained handling of assigned DT devices to support
> >> +             * access-controller functionality through SCI framework, so
> >> +             * DT device assign request can be passed to FW for processing and
> >> +             * enabling VM access to requested device.
> >> +             * The access-controller DT device processing is chained after IOMMU
> >> +             * processing and expected to be executed for any DT device
> >> +             * regardless if DT device is protected by IOMMU or not (or IOMMU
> >> +             * is disabled).
> >> +             */
> >> +            ret1 = sci_do_domctl(op, d, u_domctl);
> >> +            if ( ret1 != -EOPNOTSUPP )
> >> +                ret = ret1;
> >> +        }
> >>           break;
> >>   
> >>       case XEN_DOMCTL_get_paging_mempool_size:
> >> diff --git a/xen/drivers/passthrough/device_tree.c b/xen/drivers/passthrough/device_tree.c
> >> index 075fb25a37..2624767e51 100644
> >> --- a/xen/drivers/passthrough/device_tree.c
> >> +++ b/xen/drivers/passthrough/device_tree.c
> >> @@ -318,6 +318,12 @@ int iommu_do_dt_domctl(struct xen_domctl *domctl, struct domain *d,
> >>               break;
> >>           }
> >>   
> >> +        if ( !dt_device_is_protected(dev) )
> >> +        {
> >> +            ret = 0;
> >> +            break;
> >> +        }
> > I am concerned about this: previously we would call
> > iommu_assign_dt_device and the same check at the beginning of
> > iommu_assign_dt_device would return -EINVAL. Now it is a success.
> >
> > I am not sure this is appropriate. I wonder if instead we should:
> >
> > - remove this chunk from the patch
> > - change the return error for !dt_device_is_protected at the top of
> >    iommu_assign_dt_device from -EINVAL to -EOPNOTSUPP
> > - this would fall into the same ret != -EOPNOTSUPP check after
> >    iommu_do_domctl
> 
> That's a good point. I think we should do the same for
> 
>  > if ( !is_iommu_enabled(d) )
> 
>  >  return -EINVAL;
> 
> because in this case we should process sci as well. I will do the change
> 
> >>           ret = iommu_assign_dt_device(d, dev);
> >>   
> >>           if ( ret )
> >> -- 
> >> 2.34.1
> >>
--8323329-1675787614-1750205085=:1780597--


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 00:35:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 00:35:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018637.1395528 (Exim 4.92)
	(envelope-from )
	id 1uRgln-0005EN-FX; Wed, 18 Jun 2025 00:35:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018637.1395528; Wed, 18 Jun 2025 00: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 1uRgln-0005EG-B8; Wed, 18 Jun 2025 00:35:15 +0000
Received: by outflank-mailman (input) for mailman id 1018637;
 Wed, 18 Jun 2025 00:35: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 1uRgll-0005EA-Kb
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 00:35:13 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org
 [2600:3c0a:e001:78e:0:1991:8:25])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 172ca89d-4bdc-11f0-a30a-13f23c93f187;
 Wed, 18 Jun 2025 02:35:11 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 9DC874A2C2;
 Wed, 18 Jun 2025 00:35:09 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id D70BDC4CEED;
 Wed, 18 Jun 2025 00:35:07 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 172ca89d-4bdc-11f0-a30a-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750206909;
	bh=UOuwfDQz2R22Dh9kKXcyrh9jxqtyQwXC010GfL5BkhY=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=ePYdm9QHKmdYJzRTmawYWt5PIXWtgLAR7IbjfEYJTH3qWCtVbPXRd/f91AT7xfjXS
	 rVlQs2Tcx+ha8172oAkcWrqDBq273x9PNv3s0c+ErojO7VlkPR6jtiNpczgat60IPR
	 ECNLOmBYZ2oLeJGGPsz3Yi6QAKMohaOmDSA42uKdCS211Tsqk6UrRmT+KdRkPl12eO
	 lexsMsLkOrJNhGfvfaMxuVtgI16WsXqY6iZTjx/BOwYmI/0cVm3c8Kn/pGrS7HvMBT
	 KHIbDavz3J1BZ4RYlRfYtmBSOtctBS7ZoiByapxxX6PV7Yu4hr31tO8ZLZqHpAsjf7
	 4OlZ7Shfqti7A==
Date: Tue, 17 Jun 2025 17:35:06 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Oleksii Moisieiev 
cc: Stefano Stabellini , 
    "xen-devel@lists.xenproject.org" , 
    Andrew Cooper , 
    Anthony PERARD , 
    Bertrand Marquis , 
    Jan Beulich , Juergen Gross , 
    Julien Grall , Michal Orzel , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Volodymyr Babchuk , 
    Grygorii Strashko 
Subject: Re: [RFC PATCH v4 8/8] docs: arm: proposal to add separate SCMI node
 for Xen agent
In-Reply-To: 
Message-ID: 
References:  <3f7e1e99f5d1018064f3c4825aff16bd487cf558.1747669845.git.oleksii_moisieiev@epam.com> 
 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-2077371509-1750206562=:1780597"
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-2077371509-1750206562=:1780597
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: 8BIT
Content-ID: 

On Thu, 12 Jun 2025, Oleksii Moisieiev wrote:
> On 23/05/2025 23:19, Stefano Stabellini wrote:
> > On Mon, 19 May 2025, Oleksii Moisieiev wrote:
> >> From: Grygorii Strashko
> >>
> >> Proposal description to add separate SCMI DT node for Xen management agent
> >> under "chosen" or xen-config node, like Hyperlaunch "xen,config".
> > I think it is OK to place a larger "xen,config" node under /chosen with
> > more information for Xen to setup SCMI more easily.
> >
> >
> >> This proposal introduces a new approach to the Xen multi-domain
> >> configuration, where all Xen-specific configuration has been moved
> >> under the "/chosen" node. This requires less Dom0 device tree
> >> manipulation and isolates Xen configuration from domain configuration.
> >>
> >> This approach provides the following device tree (DT) parameters:
> >>
> >> - "xen,scmi-secondary-agents": A Xen-specific parameter under the
> >> "/chosen" node, which describes the SCMI agent configuration for
> >> the domains.
> >> - the SCMI configuration for Xen (privileged agent) and the shared
> >> memory configuration for all agents are provided under the "/chosen"
> >> node and are used strictly by Xen for its initial configuration.
> >> - the scmi_shm and SCMI configuration for Dom0 are placed in the
> >> "/firmware/scmi" node so that they can be moved to Dom0 without
> >> any changes.
> > Isn't the SCMI configuration present in /firmware/scmi referring to the
> > privileged agent=0 meant to be used by Xen?
> >
> > I certainly see benefits in simplifying the configuration and especially
> > reducing the amount of changes a user might have to make on the
> > underlying device tree, but if the user needs to change /firmware/scmi
> > with the Dom0 information, it seems more dangerous and error prone than
> > the previous approach.
> >
> The idea is to move the privileged agent=0 configuration to the /chosen 
> node and
> 
> assign agent=1 to the Dom0 node under /firmware/scmi.
> 
> Benefits of This Approach:
> - No Modification of the Xen DT Node Required
> 
>      This eliminates the need to modify the Xen Device Tree (DT) node 
> before creating Dom0 in
> 
>      order to set the correct shared memory (shmem).
> 
> -Consistent SCMI Configuration Format
> 
>    The Dom0 DT will have the same SCMI configuration format as other 
> domains, simplifying the
> 
>    overall configuration process.
> 
> - Unified SCMI Configuration Method
> 
>     There will no longer be a need to use a different approach for SCMI 
> configuration in Dom0
> 
>    compared to other domains.
> 
> - Separation Between Dom0 and Privileged Node
> 
>        This provides a clear separation between the Dom0 node and the 
> privileged node.
> 
>        For example:
>              If Dom0 only requires the clock protocol, but the Xen SCMI 
> configuration requires additional protocols,
> 
>              this approach allows Dom0 to receive only the necessary 
> protocol configuration.

I don't think this is a good idea because we end up confusing the data
for Xen and the data for the DomUs/Dom0 in the host device tree.

I think we should follow these very simple guidelines:

- The host DTB (the DTB given to Xen at boot) should be the same for Xen
  and for Linux baremetal (no KVM), with the exception of the data under
  the /chosen node

- We can place Xen specific configurations under the /chosen node in the
  host DTB, both Xen hypervisor configuration and also Dom0/DomU
  configurations

This way, the host information remains generic and the configuration for
Xen the domUs/Dom0 is kept clearly separate from the rest. I don't
think we can break these two assumptions but we have more freedom with
the rest.

If we start with these two simple assumptions, here are the
consequences:

- data under /firmware/scmi should be the same for Xen and baremetal
  Linux, ideally it would describe Xen's agent0 channel in both cases

- We can add as many nodes as we like under /chosen, including a
  xen,config node and also additional nodes for the domains config

- We can define the new nodes under /chosen to be as simple as possible
  for the user to configure them, while also trying to minimize
  complexity in Xen in terms of DT manipulations



If the Xen SCMI configuration data cannot be the same as the Linux
baremetal SCMI configuration (i.e. /firmware/scmi has to be different in
the two cases) I would still suggest to avoid modifying /firmware/scmi
for Xen and instead provide the Xen configuration under /chosen. It is
important to keep everything in the host DTB (except /chosen) the same
between Linux baremetal and Xen.

However, we can add a new node similar to /firmware/scmi under /chosen
specifically for Xen, such as /chosen/xen-config/scmi

The Dom0 configuration cannot be expected to be under /firmware/scmi.
However, it could also be defined under /chosen.

Keep in mind that the more we add to /chosen the more difficult it will
be for the user to configure the system. I think we should plan ahead to
have ImageBuilder be able to generate the DT nodes under /chosen for Xen
starting from the simplest possible configuration format provided by the
user. The more complex and rich are the device tree nodes under /chosen,
the more important is the documentation and ImageBuilder support for it.




> >> This configuration allows the use of Xen-specific nodes to provide
> >> information strictly needed by Xen while using the default SCMI
> >> configuration for Dom0 and other domains. As a result, no additional
> >> bindings need to be introduced to the device tree.
> > This is not actually implemented by this patch series, right?
> It is not. Just posted this document as a proposal.
> >> Signed-off-by: Grygorii Strashko
> >> Signed-off-by: Oleksii Moisieiev
> >> ---
> >>
> >>
> >>
> >>   .../arm/firmware/arm-scmi-proposal.rst        | 224 ++++++++++++++++++
> >>   1 file changed, 224 insertions(+)
> >>   create mode 100644 docs/hypervisor-guide/arm/firmware/arm-scmi-proposal.rst
> >>
> >> diff --git a/docs/hypervisor-guide/arm/firmware/arm-scmi-proposal.rst b/docs/hypervisor-guide/arm/firmware/arm-scmi-proposal.rst
> >> new file mode 100644
> >> index 0000000000..fcc2ed2b65
> >> --- /dev/null
> >> +++ b/docs/hypervisor-guide/arm/firmware/arm-scmi-proposal.rst
> >> @@ -0,0 +1,224 @@
> >> +
> >> +Proposal for SCMI multi-agent driver bindings
> >> +=============================================
> >> +
> >> +Now the Xen configuration for SCMI multi-agent support is done in a bit complicated way, especially
> >> +from SCMI multi-agent driver initialization and Dom0 DT manipulation point of view.
> >> +Also it does not take into account future requirements to support SCP SCMI FW.
> >> +
> >> +To enable SCMI multi-agent user need:
> >> +
> >> +* take host DT with basic SCMI enabled
> >> +* add SCMI shared-memory nodes for all agents
> >> +* update SCMI node to point on SCMI Xen management channel (``[smc-id, shmem]``)
> >> +* add "xen,scmi-secondary-agents" property to the "\chosen" node
> >> +
> >> +.. code::
> >> +
> >> +   chosen {
> >> +      xen,scmi-secondary-agents = <
> >> +                    1 0x82000003 &scmi_shm_1
> >> +                    2 0x82000004 &scmi_shm_2
> >> +                    3 0x82000005 &scmi_shm_3
> >> +                    4 0x82000006 &scmi_shm_4>;
> >> +    }
> >> +
> >> +    /{
> >> +            // SCMI shared-memory nodes for all agents
> >> +            scmi_shm_0 : sram@47ff0000 {
> >> +                compatible = "arm,scmi-shmem";
> >> +                reg = <0x0 0x47ff0000 0x0 0x1000>;
> >> +            };
> >> +            scmi_shm_1: sram@47ff1000 {
> >> +                    compatible = "arm,scmi-shmem";
> >> +                    reg = <0x0 0x47ff1000 0x0 0x1000>;
> >> +            };
> >> +            scmi_shm_2: sram@47ff2000 {
> >> +                    compatible = "arm,scmi-shmem";
> >> +                    reg = <0x0 0x47ff2000 0x0 0x1000>;
> >> +            };
> >> +            scmi_shm_3: sram@47ff3000 {
> >> +                    compatible = "arm,scmi-shmem";
> >> +                    reg = <0x0 0x47ff3000 0x0 0x1000>;
> >> +            };
> >> +            scmi_shm_4: sram@47ff4000 {
> >> +                    compatible = "arm,scmi-shmem";
> >> +                    reg = <0x0 0x47ff4000 0x0 0x1000>;
> >> +            };
> >> +
> >> +            firmware {
> >> +                scmi: scmi {
> >> +                    compatible = "arm,scmi-smc";
> >> +                    arm, smc - id = <0x82000002>; <--- Xen management agent channel "smc-id"
> >> +                    #address-cells = < 1>;
> >> +                    #size-cells = < 0>;
> >> +                    #access-controller-cells = < 1>;
> >> +                    shmem = <&scmi_shm_0>; <--- Xen management agent channel "shmem"
> >> +
> >> +                    protocol@X{
> >> +                    };
> >> +                };
> >> +            };
> >> +    }
> >> +
> >> +Important thing to note is that all information about multi-channel support is strictly Xen specific.
> >> +
> >> +During initialization the SCMI multi-agent driver uses Host DT SCMI node and
> >> +"xen,scmi-secondary-agents" property to init itself and then, during Dom0 creation, manipulates
> >> +Dom0 DT to remove Xen specific SCMI info and update dom0 SCMI nodes with Dom0 SCMI agent specific
> >> +information.
> >> +
> >> +There are two negative points:
> >> +
> >> +1) Double DT modification - one is user to set up SCMI Xen support in Host DT, second -
> >> +   Dom0 DT manipulation.
> >> +2) In case of future support of mailbox shared-memory transport there could be up to 4 mailboxes and
> >> +   up to 2 shared-memories per SCMI agent channel.
> >> +
> >> +Hence SCMI multi-agent support is Xen specific knowledge there is a proposal to add it as Xen
> >> +specific DT definitions and so minimize Host and Dom0 DT manipulations.
> >> +Those definitions can be added in "/chosen" or, ideally, in "xen,config" node (like in Hyperlaunch design).
> >> +
> >> +The SCMI binding stays generic, just two SCMI nodes defined - one for Xen management channel and
> >> +one for Host Dom0 OSPM.
> >> +
> >> +Example of using "chosen" for configuration:
> >> +
> >> +.. code::
> >> +
> >> +    /{
> >> +
> >> +        chosen {
> >> +            ...
> >> +
> >> +            // Xen SCMI management channel
> >> +            scmi_shm_0 : sram@47ff0000 {
> >> +                compatible = "arm,scmi-shmem";
> >> +                reg = <0x0 0x47ff0000 0x0 0x1000>;
> >> +            };
> >> +            scmi_xen: scmi {
> >> +                compatible = "arm,scmi-smc";
> >> +                arm,smc-id = <0x82000002>; <--- Xen manegement agent smc-id
> >> +                #address-cells = < 1>;
> >> +                #size-cells = < 0>;
> >> +                #access-controller-cells = < 1>;
> >> +                shmem = <&scmi_shm_0>; <--- Xen manegement agent shmem
> >> +            };
> >> +
> >> +            // SCMI multi-agent configuration
> >> +            scmi_shm_2: sram@47ff2000 {
> >> +                    compatible = "arm,scmi-shmem";
> >> +                    reg = <0x0 0x47ff2000 0x0 0x1000>;
> >> +            };
> >> +            scmi_shm_3: sram@47ff3000 {
> >> +                    compatible = "arm,scmi-shmem";
> >> +                    reg = <0x0 0x47ff3000 0x0 0x1000>;
> >> +            };
> >> +            scmi_shm_4: sram@47ff4000 {
> >> +                    compatible = "arm,scmi-shmem";
> >> +                    reg = <0x0 0x47ff4000 0x0 0x1000>;
> >> +            };
> >> +            xen,scmi-secondary-agents = <
> >> +                        1 0x82000003 &scmi_shm
> >> +                        2 0x82000004 &scmi_shm_2
> >> +                        3 0x82000005 &scmi_shm_3
> >> +                        4 0x82000006 &scmi_shm_4>;
> >> +        };
> >> +
> >> +        // Host SCMI OSPM channel - provided to the Dom0 as is if SCMI enabled for it
> >> +        scmi_shm: sram@47ff1000 {
> >> +                compatible = "arm,scmi-shmem";
> >> +                reg = <0x0 0x47ff1000 0x0 0x1000>;
> >> +        };
> >> +
> >> +        firmware {
> >> +            scmi: scmi {
> >> +                compatible = "arm,scmi-smc";
> >> +                arm,smc-id = <0x82000003>; <--- Host OSPM agent smc-id
> >> +                #address-cells = < 1>;
> >> +                #size-cells = < 0>;
> >> +                shmem = <&scmi_shm>; <--- Host OSPM agent shmem
> > By OSPM you mean Dom0 and not Xen? So this is a change compared to a
> > device tree for baremetal Linux without Xen?
> >
> > Let me ask the same question differently. In the case of barematal Linux
> > without Xen (no KVM), what would Linux see under /firmware/scmi as
> > smc-id and shmem? The same as the one that Xen would use for itself? Or
> > the same as the ones that Dom0 would use when Xen is present?
> 
> If this DT is used with the baremetal Linux - then the Linux Kernel will
> 
> see Dom0 "smc-id" and "shmen" under /firmware/scmi.
> 
> >> +                protocol@X{
> >> +                };
> >> +            };
> >> +        };
> >> +    }
> >> +
> >> +
> >> +In the above case:
> >> +
> >> +1) Xen SCMI multi-agent can be probed with DT configuration from "chosen" (or special "xen,config")
> >> +   node and all Xen related nodes can be easily dropped from Dom0 DT.
> >> +2) Host SCMI OSPM channel DT nodes can be copied to Dom0 DT without changes if SCMI enabled for it.
> >> +3) Future support for mailbox shared-memory transport (SCP SCMI FW) can be simplified as no more
> >> +   manipulation required with Dom0 SCMI "arm,smc-id" and "shmem" DT properties.
> > Yes, I can see the benefit if we can arrange it so that the underlying
> > host device tree is the same that Linux would use baremetal. And all the
> > extra configuration is placed under /chosen in "xen,config" node or
> > similar. I would probably call it "xen,scmi".
> 
> Personally, I would keep "xen,config" as it leaves room to add additional
> 
> configuration nodes in the future.
> 
> >> +Example of using "xen,config" for configuration:
> >> +
> >> +.. code::
> >> +
> >> +    hypervisor {
> >> +        compatible = “hypervisor,xen”
> >> +
> >> +        // Configuration container
> >> +        config {
> >> +            compatible = "xen,config";
> >> +            ...
> >> +
> >> +            // Xen SCMI management channel
> >> +            scmi_shm_0 : sram@47ff0000 {
> >> +                compatible = "arm,scmi-shmem";
> >> +                reg = <0x0 0x47ff0000 0x0 0x1000>;
> >> +            };
> >> +            scmi_xen: scmi {
> >> +                compatible = "arm,scmi-smc";
> >> +                arm,smc-id = <0x82000002>; <--- Xen manegement agent smc-id
> >> +                #address-cells = < 1>;
> >> +                #size-cells = < 0>;
> >> +                #access-controller-cells = < 1>;
> >> +                shmem = <&scmi_shm_0>; <--- Xen manegement agent shmem
> >> +            };
> >> +
> >> +            // SCMI multi-agent configuration
> >> +            scmi_shm_2: sram@47ff2000 {
> >> +                    compatible = "arm,scmi-shmem";
> >> +                    reg = <0x0 0x47ff2000 0x0 0x1000>;
> >> +            };
> >> +            scmi_shm_3: sram@47ff3000 {
> >> +                    compatible = "arm,scmi-shmem";
> >> +                    reg = <0x0 0x47ff3000 0x0 0x1000>;
> >> +            };
> >> +            scmi_shm_4: sram@47ff4000 {
> >> +                    compatible = "arm,scmi-shmem";
> >> +                    reg = <0x0 0x47ff4000 0x0 0x1000>;
> >> +            };
> >> +            xen,scmi-secondary-agents = <
> >> +                        1 0x82000003 &scmi_shm
> >> +                        2 0x82000004 &scmi_shm_2
> >> +                        3 0x82000005 &scmi_shm_3
> >> +                        4 0x82000006 &scmi_shm_4>;
> >> +        };
> >> +    };
> >> +
> >> +    /{
> >> +        // Host SCMI OSPM channel - provided to the Dom0 as is if SCMI enabled for it
> >> +        scmi_shm: sram@47ff1000 {
> >> +                compatible = "arm,scmi-shmem";
> >> +                reg = <0x0 0x47ff1000 0x0 0x1000>;
> >> +        };
> >> +
> >> +        firmware {
> >> +            scmi: scmi {
> >> +                compatible = "arm,scmi-smc";
> >> +                arm,smc-id = <0x82000003>; <--- Host OSPM agent smc-id
> >> +                #address-cells = < 1>;
> >> +                #size-cells = < 0>;
> >> +                shmem = <&scmi_shm>; <--- Host OSPM agent shmem
> >> +
> >> +                protocol@X{
> >> +                };
> >> +            };
> >> +        };
> >> +    }
> >> -- 
> >> 2.34.1
--8323329-2077371509-1750206562=:1780597--


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 00:39:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 00:39:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018648.1395536 (Exim 4.92)
	(envelope-from )
	id 1uRgqD-0005rI-2s; Wed, 18 Jun 2025 00:39:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018648.1395536; Wed, 18 Jun 2025 00:39:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRgqD-0005rB-0Q; Wed, 18 Jun 2025 00:39:49 +0000
Received: by outflank-mailman (input) for mailman id 1018648;
 Wed, 18 Jun 2025 00:39: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 1uRgqB-0005qy-KP
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 00:39:47 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bb236e1b-4bdc-11f0-a30a-13f23c93f187;
 Wed, 18 Jun 2025 02:39:46 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 1322644E93;
 Wed, 18 Jun 2025 00:39:45 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 879ECC4CEE3;
 Wed, 18 Jun 2025 00:39: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: bb236e1b-4bdc-11f0-a30a-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750207184;
	bh=0hBdAZ96Ubc//sEhEq32FEgyaJbHQWtXSDZVWGVorkQ=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=XC//rBOHNuQoTJjiSWmV5zy73LqoTRPJqDI/MO8r5l1YrKh467gpRgIxhrqdkAPXq
	 AwbtfUjg06mDeToU4f/xYA89D5O1PWB94QKT+lGUepOQ3CK6ybc3RRD7nwDyjyX34D
	 dlmYKcSLz4yO50vklh4rbx+AsbIrAdBbJ2SJHowyq1gqXNNm07+ABgzSOQ3EplkKTH
	 8ZcYrky5q/+P9R6ZBG8qGjpprypLcQJ8SMGDjOxIc1H7b9+W9pSn4q3AjMb3Y+bcVL
	 1eOLeoN6eWP71oIVvHIn3JZChPPbR/wwAJinBEDxG+RAhkt91QoFa42K1vIHOGCq9l
	 dImHwqtoVFRkg==
Date: Tue, 17 Jun 2025 17:39:42 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Stefano Stabellini , dmkhn@proton.me, 
    andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org, 
    michal.orzel@amd.com, roger.pau@citrix.com, dmukhin@ford.com, 
    xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 2/2] xen/console: unify printout behavior for UART
 emulators
In-Reply-To: 
Message-ID: 
References: <20250606201102.2414022-1-dmukhin@ford.com> <20250606201102.2414022-3-dmukhin@ford.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 Jun 2025, Jan Beulich wrote:
> On 11.06.2025 21:07, Stefano Stabellini wrote:
> > On Wed, 11 Jun 2025, Jan Beulich wrote:
> >> On 11.06.2025 02:07, dmkhn@proton.me wrote:
> >>> On Tue, Jun 10, 2025 at 10:21:40AM +0200, Jan Beulich wrote:
> >>>> On 06.06.2025 22:11, dmkhn@proton.me wrote:
> >>>>> From: Denis Mukhin 
> >>>>>
> >>>>> If virtual UART from domain X prints on the physical console, the behavior is
> >>>>> updated to (see [1]):
> >>>>> - console focus in domain X: do not prefix messages;
> >>>>> - no console focus in domain X: prefix all messages with "(dX)".
> >>>>
> >>>> While, as indicated (much) earlier, I can see why omitting the prefix
> >>>> may make sense for the domain having input focus, ...
> >>>>
> >>>>> --- a/xen/drivers/char/console.c
> >>>>> +++ b/xen/drivers/char/console.c
> >>>>> @@ -740,7 +740,17 @@ 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 */
> >>>>> +            char prefix[16] = "";
> >>>>> +            struct domain *consd;
> >>>>> +
> >>>>> +            consd = console_get_domain();
> >>>>> +            if ( consd != cd )
> >>>>> +                snprintf(prefix, sizeof(prefix), "(d%d) ", cd->domain_id);
> >>>>> +            console_put_domain(consd);
> >>>>> +
> >>>>>              nrspin_lock_irq(&console_lock);
> >>>>> +            if ( prefix[0] != '\0' )
> >>>>> +                console_send(prefix, strlen(prefix), flags);
> >>>>>              console_send(kbuf, kcount, flags);
> >>>>>              nrspin_unlock_irq(&console_lock);
> >>>>>          }
> >>>>
> >>>> ... this, aiui, is a behavioral change for the non-dom0less case, where
> >>>> Dom0 output will suddenly also gain the prefix. Which I don't think is
> >>>> wanted: Switching focus between Xen and Dom0 should remain unaffected
> >>>> in this regard.
> >>>
> >>> This change ensures that dom0 traces aren't mixed with domU traces when domU
> >>> has input focus, or with Xen traces when the administrator is in the diagnostic
> >>> console.
> >>
> >> That's what the description also tries to describe, yet I still regard it as
> >> a behavioral regression in (at least) the described scenario. The hardware
> >> domain presently not having (d0) prefixed to its output is deliberate imo,
> >> not accidental.
> > 
> > If we only consider the classic dom0 and dom0less usage models, then
> > what you wrote makes perfect sense. In the classic dom0 case, it is best
> > for dom0 to have no prefix, which is the current behavior.
> > 
> > However, things become more complex with dom0less. As we have discussed
> > previously, it has already become desirable on both ARM and x86 to align
> > on the same behavior. During our last discussion, the preference was to
> > add a '(d0)' prefix to clearly differentiate output from dom0 and other
> > domains.
> > 
> > Up to now, we could easily detect the two different cases depending on
> > the boot configuration. The problem arises with Denis' patches, which
> > add the ability for dynamically created guests via `xl` to access an
> > emulated NS16550 UART that prints to the console. Because these guests
> > are created dynamically, it is not clear how we are going to handle
> > this case.
> 
> Why would this be not clear? We already prefix their output with "(d)"
> when going the traditional way. The same would then apply to output
> coming through the emulated UART.
>
> > If we follow the dom0less preference, then we would need a '(d0)' prefix
> > for dom0. If we follow the classic dom0 model, then dom0 would remain
> > without a prefix, and the new domUs would have a prefix. This would
> > cause an inconsistency. However, this is what we have today on ARM with
> > dom0less.
> > 
> > If Jan feels strongly that we should retain no prefix for the classic
> > dom0 case, which is understandable, then I believe the best course of
> > action would be to change our stance on dom0less on both ARM and x86 and
> > also use no prefix for dom0 in the dom0less case (which is the current
> > state on ARM).
> 
> Leaving aside that "dom0 in the dom0less" ought to really be not-a-thing,
> I disagree. Present behavior of not prefixing the domain's output which
> has input focus continues to make sense. That requires Dom0 to have a
> prefix whenever it doesn't have input focus.

If I understood correctly I like your proposal. Let me rephrase it to
make sure we are aligned. You are suggesting that:

- domains without input focus will print with a (d) prefix
- the domain with input focus will print without a (d) prefix
- this applies to both DomUs and Dom0
- this applies to both predefined domains and also dynamic domains

I am OK with that. I believe this is not the current behavior on ARM but
I can appreciate the simple consistency of it.


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 00:41:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 00:41:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018655.1395547 (Exim 4.92)
	(envelope-from )
	id 1uRgrm-0007TS-Ef; Wed, 18 Jun 2025 00:41:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018655.1395547; Wed, 18 Jun 2025 00:41: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 1uRgrm-0007TL-Ba; Wed, 18 Jun 2025 00:41:26 +0000
Received: by outflank-mailman (input) for mailman id 1018655;
 Wed, 18 Jun 2025 00:41: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 1uRgrl-0007TF-S6
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 00:41:25 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f5e1a56d-4bdc-11f0-a30a-13f23c93f187;
 Wed, 18 Jun 2025 02:41:24 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 3908244DC3;
 Wed, 18 Jun 2025 00:41:23 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9CC3DC4CEE3;
 Wed, 18 Jun 2025 00:41: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: f5e1a56d-4bdc-11f0-a30a-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750207283;
	bh=HDpt+A1782zET1ue/ODOiJOIHN8q0DJhaCgkR15C/HI=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=WUS2Ki3UZJLD6qJ6b8ZfvrPw40KHJq+dZ498AmDIrMQk+ZHqfV6tgSDJUJCpQVnXC
	 TqUG+pOwOsmPVhrTxpV02yERSU9OCLx547zhBhrNN98uoZ1n2pApvFnkzj2Qrg67fU
	 D/YFt97FWHwgqsHwpXILNHqZ+wXsx4It44QCqRfITeZLKBFQo3t3EjJm87dJ7xJ044
	 LFCC8Uh7B/W8/yixDiEhD5hEbC4tf8cWib5wyneE+O1szP+D3ZUQXXfMphRd/0ssz+
	 gBcAEEZxxsMMrmcr65NjMs+6AyccEkIQHddUvat9CwuDkGR+9JpgXppdvP98L+Nqac
	 jISv4LwG7e3KQ==
Date: Tue, 17 Jun 2025 17:41:20 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Victor Lira 
cc: xen-devel@lists.xenproject.org, 
    Nicola Vetrini , 
    Andrew Cooper , 
    Anthony PERARD , 
    Michal Orzel , Jan Beulich , 
    Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=83=C2=A9?= , 
    Stefano Stabellini , 
    Federico Serafini , 
    Bertrand Marquis 
Subject: Re: [PATCH v2 1/3] xen/keyhandler: add missing noreturn attribute
In-Reply-To: <20250606212712.1901838-1-victorm.lira@amd.com>
Message-ID: 
References: <20250606212712.1901838-1-victorm.lira@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 6 Jun 2025, victorm.lira@amd.com wrote:
> From: Nicola Vetrini 
> 
> Function `reboot_machine' does not return, but lacks the `noreturn'
> attribute.
> 
> Functions that never return should be declared with a `noreturn'
> attribute.
> 
> The lack of `noreturn' causes a violation of MISRA C Rule 17.11 (not
> currently accepted in Xen), and also Rule 2.1: "A project shall not
> contain unreachable code". Depending on the compiler used and the
> compiler optimization used, the lack of `noreturn' might lead to the
> presence of unreachable code.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini 
> Signed-off-by: Victor Lira 

Reviewed-by: Stefano Stabellini 



From xen-devel-bounces@lists.xenproject.org Wed Jun 18 00:46:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 00:46:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018661.1395557 (Exim 4.92)
	(envelope-from )
	id 1uRgwG-00082q-Vz; Wed, 18 Jun 2025 00:46:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018661.1395557; Wed, 18 Jun 2025 00:46:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRgwG-00082j-SN; Wed, 18 Jun 2025 00:46:04 +0000
Received: by outflank-mailman (input) for mailman id 1018661;
 Wed, 18 Jun 2025 00:46: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 1uRgwF-00082d-VC
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 00:46:03 +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 9b2f1c02-4bdd-11f0-b894-0df219b8e170;
 Wed, 18 Jun 2025 02:46:01 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id AA2EBA5232D;
 Wed, 18 Jun 2025 00:46:00 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id D7E22C4CEE3;
 Wed, 18 Jun 2025 00:45:58 +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: 9b2f1c02-4bdd-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750207560;
	bh=UAw8UxiK2ci4QjrfhyEPKCzc8CQhr4sgjiQ16wZ/jKk=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=vLT6P78XEg4Is3dZCIbLMucw2KgSdzVlnIry5yUKJBvq7z/e+XwrMl75rXTR6p9am
	 t9hotlFXbV/vU9q14lVxMyau3zk+dBsbhbm3RpqTsSOMv2GWregbceaDDEVIjCjQMh
	 oJmejeuq1yIIEJUKvOiA32NBdAm/hQ8L/y5wWUAfd/AK2yvj92adiakgmiiDmU4hMS
	 t2W1r84xjsXXOHUj3BAz/7QWvaFMn8pvhOswD8Z8HrySj0yj9LbrgvjJ+Z9WnTWXaj
	 qMmeBpig4gR5mY+kb6Vl5bZ23QP00Oj+aCAhNUbPLP6o7dNcW1zi1ZVEt118/VlqwV
	 JN1AscuH3j3lw==
Date: Tue, 17 Jun 2025 17:45:57 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Victor Lira 
cc: xen-devel@lists.xenproject.org, 
    Nicola Vetrini , 
    Andrew Cooper , 
    Anthony PERARD , 
    Michal Orzel , Jan Beulich , 
    Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=83=C2=A9?= , 
    Stefano Stabellini , 
    Federico Serafini , 
    Bertrand Marquis 
Subject: Re: [PATCH v2 2/3] xen/arm: add missing noreturn attributes
In-Reply-To: <20250606212712.1901838-2-victorm.lira@amd.com>
Message-ID: 
References: <20250606212712.1901838-1-victorm.lira@amd.com> <20250606212712.1901838-2-victorm.lira@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 6 Jun 2025, victorm.lira@amd.com wrote:
> From: Nicola Vetrini 
> 
> The marked functions never return to their caller, but lack the
> `noreturn' attribute.
> 
> Functions that never return should be declared with a `noreturn'
> attribute.
> 
> The lack of `noreturn' causes a violation of MISRA C Rule 17.11 (not
> currently accepted in Xen), and also Rule 2.1: "A project shall not
> contain unreachable code". Depending on the compiler used and the
> compiler optimization used, the lack of `noreturn' might lead to the
> presence of unreachable code.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini 
> Signed-off-by: Victor Lira 

Reviewed-by: Stefano Stabellini 



From xen-devel-bounces@lists.xenproject.org Wed Jun 18 00:48:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 00:48:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018667.1395568 (Exim 4.92)
	(envelope-from )
	id 1uRgz0-00007j-Cd; Wed, 18 Jun 2025 00:48:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018667.1395568; Wed, 18 Jun 2025 00:48:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRgz0-00007a-84; Wed, 18 Jun 2025 00:48:54 +0000
Received: by outflank-mailman (input) for mailman id 1018667;
 Wed, 18 Jun 2025 00:48: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 1uRgyy-00007S-Tw
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 00:48:52 +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 ffc0c61c-4bdd-11f0-b894-0df219b8e170;
 Wed, 18 Jun 2025 02:48:50 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 9DC705C5516;
 Wed, 18 Jun 2025 00:46:32 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6B647C4CEE3;
 Wed, 18 Jun 2025 00:48:47 +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: ffc0c61c-4bdd-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750207728;
	bh=UAw8UxiK2ci4QjrfhyEPKCzc8CQhr4sgjiQ16wZ/jKk=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=t1nlekeaY/ZFX81zu7znZGyTQpUiriQU+hfOVl7hI0WVpCglCNBjaGDH7CobmJxM5
	 JeiZCbmxvUsxJ4DYXQrnGFty4QRLvJjVfzOzDghVXW/GR1zGCFphYl5pSZEZXhrlV4
	 Rl3eNu8Qgy390mzHVJAsW+a0PQsoVLi3IjDdDaDf8MCGvpa7TDQ97Be/d90QiqTXMz
	 JPNlu3NNN/q+7RVRj0AMIe57b/nr7UiOOabtTYiZecGy+vS96XC3tGMALPnXMwoNkg
	 8GIGveQ/XPmJUg3lnFcZARSdkaON7E/v5cw82p44bWRoLp8MIr/n8XtNoQ/YgWZBKv
	 bvzoCuCkB5SoQ==
Date: Tue, 17 Jun 2025 17:48:45 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Victor Lira 
cc: xen-devel@lists.xenproject.org, 
    Nicola Vetrini , 
    Andrew Cooper , 
    Anthony PERARD , 
    Michal Orzel , Jan Beulich , 
    Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=83=C2=A9?= , 
    Stefano Stabellini , 
    Federico Serafini , 
    Bertrand Marquis 
Subject: Re: [PATCH v2 3/3] xen/x86: add missing noreturn attributes
In-Reply-To: <20250606212712.1901838-3-victorm.lira@amd.com>
Message-ID: 
References: <20250606212712.1901838-1-victorm.lira@amd.com> <20250606212712.1901838-2-victorm.lira@amd.com> <20250606212712.1901838-3-victorm.lira@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 6 Jun 2025, victorm.lira@amd.com wrote:
> From: Nicola Vetrini 
> 
> The marked functions never return to their caller, but lack the
> `noreturn' attribute.
> 
> Functions that never return should be declared with a `noreturn'
> attribute.
> 
> The lack of `noreturn' causes a violation of MISRA C Rule 17.11 (not
> currently accepted in Xen), and also Rule 2.1: "A project shall not
> contain unreachable code". Depending on the compiler used and the
> compiler optimization used, the lack of `noreturn' might lead to the
> presence of unreachable code.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini 
> Signed-off-by: Victor Lira 

Reviewed-by: Stefano Stabellini 



From xen-devel-bounces@lists.xenproject.org Wed Jun 18 04:55:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 04:55:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018724.1395636 (Exim 4.92)
	(envelope-from )
	id 1uRkpa-0003kn-JK; Wed, 18 Jun 2025 04:55:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018724.1395636; Wed, 18 Jun 2025 04: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 1uRkpa-0003kg-Fj; Wed, 18 Jun 2025 04:55:26 +0000
Received: by outflank-mailman (input) for mailman id 1018724;
 Wed, 18 Jun 2025 02:02: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 1uRi7v-0001hQ-RK
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 02:02:11 +0000
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [160.30.148.35])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3b27f94c-4be8-11f0-b894-0df219b8e170;
 Wed, 18 Jun 2025 04:02:07 +0200 (CEST)
Received: from mse-fl2.zte.com.cn (unknown [10.5.228.133])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by mxhk.zte.com.cn (FangMail) with ESMTPS id 4bMRnM6lHcz8RTWX;
 Wed, 18 Jun 2025 10:01:59 +0800 (CST)
Received: from xaxapp05.zte.com.cn ([10.99.98.109])
 by mse-fl2.zte.com.cn with SMTP id 55I21qOP018640;
 Wed, 18 Jun 2025 10:01:52 +0800 (+08)
 (envelope-from jiang.peng9@zte.com.cn)
Received: from mapi (xaxapp01[null]) by mapi (Zmail) with MAPI id mid31;
 Wed, 18 Jun 2025 10:01:53 +0800 (CST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3b27f94c-4be8-11f0-b894-0df219b8e170
Date: Wed, 18 Jun 2025 10:01:53 +0800 (CST)
X-Zmail-TransId: 2af968521e11ffffffffad8-e8144
X-Mailer: Zmail v1.0
Message-ID: <20250618100153468I5faNUAhCdtMA01OuuTKC@zte.com.cn>
Mime-Version: 1.0
From: 
To: 
Cc: , ,
        , ,
        , ,
        
Subject: =?UTF-8?B?W1BBVENIXSB4ZW4veGVuYnVzOiBmaXggVz0xIGJ1aWxkIHdhcm5pbmcgaW4geGVuYnVzX3ZhX2Rldl9lcnJvcgogZnVuY3Rpb24=?=
Content-Type: multipart/mixed;
	boundary="=====_001_next====="
X-MAIL:mse-fl2.zte.com.cn 55I21qOP018640
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 68521E16.000/4bMRnM6lHcz8RTWX



--=====_001_next=====
Content-Type: multipart/related;
	boundary="=====_002_next====="


--=====_002_next=====
Content-Type: multipart/alternative;
	boundary="=====_003_next====="


--=====_003_next=====
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: base64

RnJvbTogUGVuZyBKaWFuZyA8amlhbmcucGVuZzlAenRlLmNvbS5jbj4NCg0KVGhpcyBwYXRjaCBm
aXhlcyBhIFc9MSBmb3JtYXQtc3RyaW5nIHdhcm5pbmcgcmVwb3J0ZWQgYnkgR0NDIDEyLjMuMA0K
YnkgYW5ub3RhdGluZyB4ZW5idXNfc3dpdGNoX2ZhdGFsKCkgYW5kIHhlbmJ1c192YV9kZXZfZXJy
b3IoKQ0Kd2l0aCB0aGUgX19wcmludGYgYXR0cmlidXRlLiBUaGUgYXR0cmlidXRlIGVuYWJsZXMg
Y29tcGlsZS10aW1lDQp2YWxpZGF0aW9uIG9mIHByaW50Zi1zdHlsZSBmb3JtYXQgc3RyaW5ncyBp
biB0aGVzZSBmdW5jdGlvbnMuDQoNClRoZSBvcmlnaW5hbCB3YXJuaW5nIHRyYWNlOg0KZHJpdmVy
cy94ZW4veGVuYnVzL3hlbmJ1c19jbGllbnQuYzozMDQ6OTogd2FybmluZzogZnVuY3Rpb24gJ3hl
bmJ1c192YV9kZXZfZXJyb3InIG1pZ2h0IGJlDQphIGNhbmRpZGF0ZSBmb3IgJ2dudV9wcmludGYn
IGZvcm1hdCBhdHRyaWJ1dGUgWy1Xc3VnZ2VzdC1hdHRyaWJ1dGU9Zm9ybWF0XQ0KDQpTaWduZWQt
b2ZmLWJ5OiBQZW5nIEppYW5nIDxqaWFuZy5wZW5nOUB6dGUuY29tLmNuPg0KLS0tDQogZHJpdmVy
cy94ZW4veGVuYnVzL3hlbmJ1c19jbGllbnQuYyB8IDIgKysNCiAxIGZpbGUgY2hhbmdlZCwgMiBp
bnNlcnRpb25zKCspDQoNCmRpZmYgLS1naXQgYS9kcml2ZXJzL3hlbi94ZW5idXMveGVuYnVzX2Ns
aWVudC5jIGIvZHJpdmVycy94ZW4veGVuYnVzL3hlbmJ1c19jbGllbnQuYw0KaW5kZXggNTFiMzEy
NGIwZDU2Li5lNzNlYzIyNWQ0YTYgMTAwNjQ0DQotLS0gYS9kcml2ZXJzL3hlbi94ZW5idXMveGVu
YnVzX2NsaWVudC5jDQorKysgYi9kcml2ZXJzL3hlbi94ZW5idXMveGVuYnVzX2NsaWVudC5jDQpA
QCAtMjAyLDYgKzIwMiw3IEBAIGludCB4ZW5idXNfd2F0Y2hfcGF0aGZtdChzdHJ1Y3QgeGVuYnVz
X2RldmljZSAqZGV2LA0KIH0NCiBFWFBPUlRfU1lNQk9MX0dQTCh4ZW5idXNfd2F0Y2hfcGF0aGZt
dCk7DQogDQorX19wcmludGYoNCwgNSkNCiBzdGF0aWMgdm9pZCB4ZW5idXNfc3dpdGNoX2ZhdGFs
KHN0cnVjdCB4ZW5idXNfZGV2aWNlICosIGludCwgaW50LA0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBjb25zdCBjaGFyICosIC4uLik7DQogDQpAQCAtMjg3LDYgKzI4OCw3IEBAIGlu
dCB4ZW5idXNfZnJvbnRlbmRfY2xvc2VkKHN0cnVjdCB4ZW5idXNfZGV2aWNlICpkZXYpDQogfQ0K
IEVYUE9SVF9TWU1CT0xfR1BMKHhlbmJ1c19mcm9udGVuZF9jbG9zZWQpOw0KIA0KK19fcHJpbnRm
KDMsIDApDQogc3RhdGljIHZvaWQgeGVuYnVzX3ZhX2Rldl9lcnJvcihzdHJ1Y3QgeGVuYnVzX2Rl
dmljZSAqZGV2LCBpbnQgZXJyLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25z
dCBjaGFyICpmbXQsIHZhX2xpc3QgYXApDQogew0KLS0gDQoyLjI1LjE=


--=====_003_next=====
Content-Type: text/html ;
	charset="UTF-8"
Content-Transfer-Encoding: base64

PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPjxwPkZyb206IFBlbmcgSmlhbmcgJmx0O2ppYW5nLnBl
bmc5QHp0ZS5jb20uY24mZ3Q7PC9wPjxwPjxicj48L3A+PHA+VGhpcyBwYXRjaCBmaXhlcyBhIFc9
MSBmb3JtYXQtc3RyaW5nIHdhcm5pbmcgcmVwb3J0ZWQgYnkgR0NDIDEyLjMuMDwvcD48cD5ieSBh
bm5vdGF0aW5nIHhlbmJ1c19zd2l0Y2hfZmF0YWwoKSBhbmQgeGVuYnVzX3ZhX2Rldl9lcnJvcigp
PC9wPjxwPndpdGggdGhlIF9fcHJpbnRmIGF0dHJpYnV0ZS4gVGhlIGF0dHJpYnV0ZSBlbmFibGVz
IGNvbXBpbGUtdGltZTwvcD48cD52YWxpZGF0aW9uIG9mIHByaW50Zi1zdHlsZSBmb3JtYXQgc3Ry
aW5ncyBpbiB0aGVzZSBmdW5jdGlvbnMuPC9wPjxwPjxicj48L3A+PHA+VGhlIG9yaWdpbmFsIHdh
cm5pbmcgdHJhY2U6PC9wPjxwPmRyaXZlcnMveGVuL3hlbmJ1cy94ZW5idXNfY2xpZW50LmM6MzA0
Ojk6IHdhcm5pbmc6IGZ1bmN0aW9uICd4ZW5idXNfdmFfZGV2X2Vycm9yJyBtaWdodCBiZTwvcD48
cD5hIGNhbmRpZGF0ZSBmb3IgJ2dudV9wcmludGYnIGZvcm1hdCBhdHRyaWJ1dGUgWy1Xc3VnZ2Vz
dC1hdHRyaWJ1dGU9Zm9ybWF0XTwvcD48cD48YnI+PC9wPjxwPlNpZ25lZC1vZmYtYnk6IFBlbmcg
SmlhbmcgJmx0O2ppYW5nLnBlbmc5QHp0ZS5jb20uY24mZ3Q7PC9wPjxwPi0tLTwvcD48cD4mbmJz
cDtkcml2ZXJzL3hlbi94ZW5idXMveGVuYnVzX2NsaWVudC5jIHwgMiArKzwvcD48cD4mbmJzcDsx
IGZpbGUgY2hhbmdlZCwgMiBpbnNlcnRpb25zKCspPC9wPjxwPjxicj48L3A+PHA+ZGlmZiAtLWdp
dCBhL2RyaXZlcnMveGVuL3hlbmJ1cy94ZW5idXNfY2xpZW50LmMgYi9kcml2ZXJzL3hlbi94ZW5i
dXMveGVuYnVzX2NsaWVudC5jPC9wPjxwPmluZGV4IDUxYjMxMjRiMGQ1Ni4uZTczZWMyMjVkNGE2
IDEwMDY0NDwvcD48cD4tLS0gYS9kcml2ZXJzL3hlbi94ZW5idXMveGVuYnVzX2NsaWVudC5jPC9w
PjxwPisrKyBiL2RyaXZlcnMveGVuL3hlbmJ1cy94ZW5idXNfY2xpZW50LmM8L3A+PHA+QEAgLTIw
Miw2ICsyMDIsNyBAQCBpbnQgeGVuYnVzX3dhdGNoX3BhdGhmbXQoc3RydWN0IHhlbmJ1c19kZXZp
Y2UgKmRldiw8L3A+PHA+Jm5ic3A7fTwvcD48cD4mbmJzcDtFWFBPUlRfU1lNQk9MX0dQTCh4ZW5i
dXNfd2F0Y2hfcGF0aGZtdCk7PC9wPjxwPiZuYnNwOzwvcD48cD4rX19wcmludGYoNCwgNSk8L3A+
PHA+Jm5ic3A7c3RhdGljIHZvaWQgeGVuYnVzX3N3aXRjaF9mYXRhbChzdHJ1Y3QgeGVuYnVzX2Rl
dmljZSAqLCBpbnQsIGludCw8L3A+PHA+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGNvbnN0IGNoYXIgKiwgLi4uKTs8L3A+PHA+Jm5ic3A7PC9w
PjxwPkBAIC0yODcsNiArMjg4LDcgQEAgaW50IHhlbmJ1c19mcm9udGVuZF9jbG9zZWQoc3RydWN0
IHhlbmJ1c19kZXZpY2UgKmRldik8L3A+PHA+Jm5ic3A7fTwvcD48cD4mbmJzcDtFWFBPUlRfU1lN
Qk9MX0dQTCh4ZW5idXNfZnJvbnRlbmRfY2xvc2VkKTs8L3A+PHA+Jm5ic3A7PC9wPjxwPitfX3By
aW50ZigzLCAwKTwvcD48cD4mbmJzcDtzdGF0aWMgdm9pZCB4ZW5idXNfdmFfZGV2X2Vycm9yKHN0
cnVjdCB4ZW5idXNfZGV2aWNlICpkZXYsIGludCBlcnIsPC9wPjxwPiZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBjb25zdCBjaGFyICpmbXQsIHZh
X2xpc3QgYXApPC9wPjxwPiZuYnNwO3s8L3A+PHA+LS0mbmJzcDs8L3A+PHA+Mi4yNS4xPC9wPjxw
IHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZhbWlseTrlvq7ova/pm4Xpu5EsTWljcm9zb2Z0
IFlhSGVpOyI+PGJyPjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk65b6u
6L2v6ZuF6buRLE1pY3Jvc29mdCBZYUhlaTsiPjxicj48L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZTox
NHB4O2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kSxNaWNyb3NvZnQgWWFIZWk7Ij48YnI+PC9wPjxw
IHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZhbWlseTrlvq7ova/pm4Xpu5EsTWljcm9zb2Z0
IFlhSGVpOyI+PGJyPjwvcD48L2Rpdj4=


--=====_003_next=====--

--=====_002_next=====--

--=====_001_next=====--



From xen-devel-bounces@lists.xenproject.org Wed Jun 18 06:15:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 06:15:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018791.1395647 (Exim 4.92)
	(envelope-from )
	id 1uRm4d-0004yh-2y; Wed, 18 Jun 2025 06:15:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018791.1395647; Wed, 18 Jun 2025 06: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 1uRm4d-0004ya-0M; Wed, 18 Jun 2025 06:15:03 +0000
Received: by outflank-mailman (input) for mailman id 1018791;
 Wed, 18 Jun 2025 06:15: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 1uRm4b-0004yU-10
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 06:15:01 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20618.outbound.protection.outlook.com
 [2a01:111:f403:2413::618])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8c6b7800-4c0b-11f0-b894-0df219b8e170;
 Wed, 18 Jun 2025 08:14:54 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 DS2PR12MB9589.namprd12.prod.outlook.com (2603:10b6:8:279::7) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8835.35; Wed, 18 Jun 2025 06:14:51 +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.8835.027; Wed, 18 Jun 2025
 06:14: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: 8c6b7800-4c0b-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=rSbjTn5g9qD/y7MMFoNLEQ9lebyxJUh+A7joHv/yrEfPlJZWMBWvpvqaYUOo+posQYCuuxs2vMHKUqN3ShO0LXjqtfv0GkpEYXtDU1UCbQuzeQKcYW5+QuD0G35lD8KhE5w5dB32oXZRBqzM4k5JEaWaCppC1NtTSmoCiqZZ0CPxGbu95meKxIRKBDTdgVtcQZArC7mnVSkWvlryJUmYuWbiSo5Xe891eD+9exKFtKV8vT7x8ITSO4h/xXAOIeEeUW3CYEpMuKjiKu4uDXzqVnBWkT6J16PffQYMisVCrgLE/PCDtH3p5Ys8KT7w/nj/smJsL//7dF0BJk3orsSg8g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=2nWrf/BkyrVp/Xubv+mTIZwVfT3na+aymVVlKwCzzgg=;
 b=nQ/Ihezg93PW19Kv46pqejUqIS7TjssAy3wezunRXIgnq1AVW7jXfZPHoZLjWY9QTMp/BShnB6yWypWRpCPnVnrIJiKwhcYwZp/ve7vuRB6uGsWMXy4yAQC5LzrpNMggzov6Sozj5Yv0HRhRuVhVwl24xYFJqIxDVHehzb0R+oChHLGpNU+nAGeTzMJ4VCMtGKXGm5h62zfVm9DZJdOwNbelhagdJiqfLFnECVTkwVW422ixuZQru0vpFLZozPdq014itL28b3+UwJlp/tFnLdGcoeOVWUzIvIhkSwvmV6GdEGN6Wfkysiu8ZDu9lPTZt0mHA2sf5ycSOArCjc97EQ==
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=2nWrf/BkyrVp/Xubv+mTIZwVfT3na+aymVVlKwCzzgg=;
 b=3YljeYv9uX+Xcq1KEbTzmqrVQD0k806w+GPHKizbDqElW6qPBPRnA/0bhtWDanGltDKl2hG9Vp/Rd4OERKzUKnKmdhqKsh5b8wL7v6K7U4l/pBYK0usz2zBqilN1i9RdiJgSqz11FKT9QVYzKnVoqdjF3MnOC1mhJn9l7iCt3qM=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Andrew Cooper
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Anthony PERARD , "Orzel,
 Michal" , Julien Grall , Stefano
 Stabellini , Juergen Gross ,
	"xen-devel@lists.xenproject.org" 
Subject: RE: [PATCH v5 00/18] amd-cppc CPU Performance Scaling Driver
Thread-Topic: [PATCH v5 00/18] amd-cppc CPU Performance Scaling Driver
Thread-Index: AQHbzuQ5QS9t68DsIkSY3rIqCe+mtLQHSw6AgAEwUfA=
Date: Wed, 18 Jun 2025 06:14:50 +0000
Message-ID:
 
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=True;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-06-18T06:14:33.0000000Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=3;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged
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_|DS2PR12MB9589:EE_
x-ms-office365-filtering-correlation-id: 06f37197-973c-4c86-94f0-08ddae2f6f16
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?ZFJpZUhUZVYxZXQvVU5PRmRMVERPS3o0L083WWhFeXIxZTAwR2IzM3dzQk90?=
 =?utf-8?B?RW9uNnpaUnRJdUl0bGgzYllab0ppQnI1Y2F0ekNub2EyTjcxbldCVHpacWtK?=
 =?utf-8?B?T1c5ZEg0WWgra1crOXlDUXlxWjUwenpXOWw2SnpzQjhHSEF2RzI3VkVwL2lO?=
 =?utf-8?B?bjNrSisxdmFQZFNhZytHMGVNT0RVVWpLdllGVHVPZnVjOFBiRXZUL1RXckNs?=
 =?utf-8?B?TFJwa3pHUng0VGhOYkFCc2tvMHF2U1dNZ1JRVFVhQmF0TzU0WXRTandTeUUx?=
 =?utf-8?B?WE1rbzE3cnd2SWZETDBiYU9saVdYRzV2K3JCOWpIaXN5Yng1d1ZRVUxvWG53?=
 =?utf-8?B?U0pKNTJSWFlONFNvZ1g0QXpCMkIxcDhBVzJKdmJSclNWelQvQzJYcWZWeXFY?=
 =?utf-8?B?YjBnMTVXc0pLL1NuRGhEbEFIcUk5anZjYVpRNS96MHNTY0hSTW5rSzE0WVhO?=
 =?utf-8?B?NWl6M2VTUmNRN2pWNE1tSVZlYks3WGtWUi9tcDNVaGpoZVF4ay9wWjZGMGdV?=
 =?utf-8?B?T0U0cVhRMWhLaXZxd2hQL3puNXlhVnJFaDhSQVdXZHlMWkZ1MS81WlRSdnZ2?=
 =?utf-8?B?NVJCUFpEN3RPT3V0eFBHYnFNZTdyenlwZHkybE9NVTlRSUJ4QTgwbWlxMUhu?=
 =?utf-8?B?THdFdU95NHRKWXo0eExwNDBrWmtBYUhmdnpTdURBSXBqbVUybkpLMmV1ZmM1?=
 =?utf-8?B?WjhPTWZHZlQ2aXdxbnZZRG1zZDk2TGc5dUFTY3JRK1ZCb1AyNjZzMEU3aUd5?=
 =?utf-8?B?TzAvR1I0dnd0YmNLZjNaUEVsWTRrTGE1M05OanZMamNqdVV3TldMQnFJcmlP?=
 =?utf-8?B?bU5NZGVYN3BzUXM2YSszbHJ2TjkyOGFqNWNKNnB1UnlTK1drVmU3bzlXbW1y?=
 =?utf-8?B?NkV2MWgrSnlndytOZ001a3dmUmFZV1FMRVhXWmVJSldFa3I4Um0zRVdtc3NM?=
 =?utf-8?B?eTVkTTl3akpMclNmM3M4L2V5djZFa3lxZ2pHZTcwdDFQRkVjUWhXUFQzTC8r?=
 =?utf-8?B?RG56anViaDhHU0VxRU5pM2R1VHJRTC9zWkloWTlYQ2RBdWtuaHVQYmFZOW5k?=
 =?utf-8?B?T2Q3T2IrMHpiaUVOUEF6MXFLQ214Y2xmZ0graUJHdHpSQ2pCalBIano5Y3lE?=
 =?utf-8?B?RHJ1Z3c5bndPc3dhZHJ5cXlONTVLMFQ5WjJFanZtd01wZE1jTVQrVFpmMlZr?=
 =?utf-8?B?dmtVZmhoU0p3ZUg2dUxuTFFpUlFQbGxOTEJyeGhWaDFGZTcxakF5MHFjWVlD?=
 =?utf-8?B?V29OK1NIcVZ3ZjNWOVpLQmxvNnJrbm5XNE1wdndqMXRzekNxUldNYXUzQmUz?=
 =?utf-8?B?UEpocDJoSXBqbks1U3JXOWE0SXQ3eEYzWHBYOWZwKzdrdWpmZ2FFRjRMNTJN?=
 =?utf-8?B?d2V0YUZqQ1dWVjVsQnJadkZ5N1FZMTM2SVpWclN0L0JzVzMzK3h4MEhrZThz?=
 =?utf-8?B?MUlrOWVTT1pRbnl4a1AzL0pCamFKUGp2d0hoTUlVSm1JbmtYQWhGVDRNUThL?=
 =?utf-8?B?R2M0YitzaHQyVjJpY01ZaUMvVkZuZmFBM3I1NkZWM3NxSTJRNzZJZmRidWJJ?=
 =?utf-8?B?bzBSRDZybjFBZFE2R0ZsaEd4dEJOd1dkUTJtSm4rSzl2bmxjTC9xQ29YdjJE?=
 =?utf-8?B?V0llQUZSOWJEdWlxd3FzQU5GbVdic2ZGQzR4cDdXTzQrZkZzWFFpaTZxQ1cz?=
 =?utf-8?B?Qllqd2drL3hHL1RXbENPTVF2UzUzZVBkYjdkZkQreEl4ZzVhck1IQ3QzYjFX?=
 =?utf-8?B?NXBmaHFycGo1elZUb0h4c2RlR2d6V0o1SDVaQjJnNFErdHYyV1QwMUdZYjZX?=
 =?utf-8?B?U1FHSTU3WVVOdXVqa2t5aTZZOW1maytrVDZZb2JTc2dxSklpRnVZV1g1TDJD?=
 =?utf-8?B?ZDZSRCs2ZUpseUpUUTZGMWp0MWVzNmdlRk8yYkFDMWNLYVl2VFIvdnZKUDFh?=
 =?utf-8?B?OHBTUGZ5c2Q3MEpvc1IybmNpQmtIMk14U0lpMERyeW9LRjA2S2RjVlVTMEN4?=
 =?utf-8?Q?bl+0605ZJYUCvUKb77+/IBbkptAwX4=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?Ri9Pb21XdlZDU2Mya2x4THNRbWtoQisvS1pIVG95UzVPVzU4RjZNSWxFQ041?=
 =?utf-8?B?eUh6bngzT3paYVZFSE4wekxNcWxTNW1RYVBEV2FFSnRWTkxBRE5KUlcwMkdi?=
 =?utf-8?B?Q3lubnJNdmpNUmFrYUhoSERuREhsSnV3dDRiMzhsL2ZlUm9aYWd4MlB2Uk0v?=
 =?utf-8?B?Qk0yQ1dxM3g1Rk1jOWpEb2xhQmdKZlBuOWFtWTZLNEZtRUVCRWFXNzU5VEN0?=
 =?utf-8?B?OHJ3TzhZRmpQbG9qT1NKcXJzeHltc1JVWmtOZFF6YXd2RkRXU3Z4SFQ4UDMx?=
 =?utf-8?B?UnYzRDJRS25rWlVJRnRMNlUvTXd3ckdETkY3M2todlFGOHNpMTlhOXM1NEQv?=
 =?utf-8?B?SjdDMHJ0YmRCTTA5RWh1NEhHWmNqdm52REZ1dHlLM0NKTW1uWHhITm5ETmND?=
 =?utf-8?B?emxhZjdHNmhoSGhFZkxlZC9hTkpxVmlHanVVV2h5Q2F6NnRzaFRhWFdoSFJr?=
 =?utf-8?B?aGEyb1dpRzJBQ24rbXdGdUY2NnZvSXRkWllTczNWVmJ4RnZXb285N2pIWmh6?=
 =?utf-8?B?NFdvajEwbWpKWC9MYzhrZ0VDMkNLVUVPZFdPMGNhWm40dExsd3hRcVYwaEdZ?=
 =?utf-8?B?QnZEZ0hYTTRONlZYcnN5ZGp3TXc5aS9IUmc5eDgyVGJHL1NPNVIxT05mUGxX?=
 =?utf-8?B?Y1NpYWNhb0dickgxQ3lMV3F0Q1lHQ25JYUhTUlRzWSszTlFvT0V1TEZvMU1P?=
 =?utf-8?B?TnYyaHErMjdIZ1BQUXFQWkd4RkVRUlZ2THlNRGVBWkI5RDI4Wll2UUYvRVVL?=
 =?utf-8?B?TXFlNk8vZUxxU3JKek5uMWRid0IycjE4cGNBc1FTZWxWMnYxV1J2bWtRcjZZ?=
 =?utf-8?B?SVNhZFNnZjUrSHh3Z0cvaHZrSENOVDZkZG5UUDZOUFNGNm5JdHQ0TlZMUC9n?=
 =?utf-8?B?TWpHWFMvRnRDRHhyYVBEL1FUTzNaaGhYbnBwMUtBU0k4bEhiemNQTk5uZWZV?=
 =?utf-8?B?QUJTeS9OYkV0QUljNjZlSkxKVVBJYmZ4WG95Wmh2dW55b0RuSktVMTdvelFP?=
 =?utf-8?B?VUdZcWFWSGdERk83Y1Zkd1BNZEQ1Q0xVRkxPWS9yd0ltRld2ODFjaW1oakdR?=
 =?utf-8?B?UXhmUTdRc1BOaW55Tkx2ZWFRUnhiU0EvZW1TWVVqbE1uQzEzdXdsWWVNYUY0?=
 =?utf-8?B?cjE2bXd3M2dHb2I1UlFMbURudENzY1VuYUZsd3ZUSDJIYXoxbDA1RmFTdWpz?=
 =?utf-8?B?Qk8xcVlVMVJ5aWs0bjlTN1RmZEg3REdXckZ4WE5JOVlBbEpmVlc0czUzQ3BS?=
 =?utf-8?B?ZENZRiszb0pSR1BLV1RIbmlkbjgrK2JYRWQwaENaT0xTN0x3ODJURWNGZGlp?=
 =?utf-8?B?MDN6VFpyRXhUUi9hRFpKdDV1WnJCZmNBOGNEelZldHZHQWJuSXpZNFlvYVFT?=
 =?utf-8?B?MVJOclR3SFFFRzdvdXZEeTIyM2xLSS90dC9JcnNuMlowNG0vSkRjZkZSS2VN?=
 =?utf-8?B?eW9JVngwZzZ1cmRBV0VYR3NGOUsybFBPQ1dDYXVuenR1ZjdOTTRrNTZMS25p?=
 =?utf-8?B?cWpLMWxwU3lWWFh1ZXRJdGIreWV0SXlMWlZ3QjZlMnhQRWwrNytWZHpualNF?=
 =?utf-8?B?SXc0a1ZGeCtkY0dpbmlES3NEb0hUeEZKSDlKQnMrSjFrNzIrWjlqeWlsQWxF?=
 =?utf-8?B?R3k1NjR6VkQ0MVRPK1BKQUtXeGNXeXpNZHdZMXlCNmt1STdCYm9kZzF5SExE?=
 =?utf-8?B?NllYekRqMnBkN0RkQU82ZDY3aytLSDE3RGFwU05LdTl0ZlU1WWM4NU9GTGNJ?=
 =?utf-8?B?WW5vZ1FEQ3R1R2Rtb1daUysydnpVWW8yOGVCUi9UY0xuMVNCcFd0TnVPNXlu?=
 =?utf-8?B?dERURHhLNzhZSWw1ekJDakdEb2luN3ZMc0RHVlYzTG1XY3ZFWlB0VXcxNjFV?=
 =?utf-8?B?SUtOY3JvVWU5THdqTVdwcXNHL1hhcnpCVjhzQ1lxYkpmSDVGbWdqc3BtYWNX?=
 =?utf-8?B?Rm53NWsvNEN6Qks0MFJVYUhkRng3cWxtalFtWGJoTTV6bjZoTVJ0d25qaklI?=
 =?utf-8?B?OHR4ZndJVUNhTUdGSEJRMkoyTXBHT0hEOUk3QkpsTDdtcjV5b0RmY24wVGoz?=
 =?utf-8?B?ZjFrZGlvZm80Z015TlIrVW5uU0paNExJOGpUd2lyVVFTczc0dis0VEJQeDhj?=
 =?utf-8?Q?sclY=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: 06f37197-973c-4c86-94f0-08ddae2f6f16
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2025 06:14:50.6609
 (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: uy0p/FYjuRuKOaF0GwhCnahHT1+LT1580uzfabvzjcs5wbR6vhVHxpI866KiH43OHRShJs5QW9cQ0aQfcK4BtA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS2PR12MB9589

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFR1ZXNkYXksIEp1bmUgMTcsIDIwMjUg
Njo0MiBQTQ0KPiBUbzogUGVubnksIFpoZW5nIDxwZW5ueS56aGVuZ0BhbWQuY29tPg0KPiBDYzog
SHVhbmcsIFJheSA8UmF5Lkh1YW5nQGFtZC5jb20+OyBBbmRyZXcgQ29vcGVyDQo+IDxhbmRyZXcu
Y29vcGVyM0BjaXRyaXguY29tPjsgUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5j
b20+Ow0KPiBBbnRob255IFBFUkFSRCA8YW50aG9ueS5wZXJhcmRAdmF0ZXMudGVjaD47IE9yemVs
LCBNaWNoYWwNCj4gPE1pY2hhbC5PcnplbEBhbWQuY29tPjsgSnVsaWVuIEdyYWxsIDxqdWxpZW5A
eGVuLm9yZz47IFN0ZWZhbm8gU3RhYmVsbGluaQ0KPiA8c3N0YWJlbGxpbmlAa2VybmVsLm9yZz47
IEp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT47IHhlbi0NCj4gZGV2ZWxAbGlzdHMueGVu
cHJvamVjdC5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSCB2NSAwMC8xOF0gYW1kLWNwcGMgQ1BV
IFBlcmZvcm1hbmNlIFNjYWxpbmcgRHJpdmVyDQo+DQo+IE9uIDI3LjA1LjIwMjUgMTA6NDgsIFBl
bm55IFpoZW5nIHdyb3RlOg0KPiA+IGFtZC1jcHBjIGlzIHRoZSBBTUQgQ1BVIHBlcmZvcm1hbmNl
IHNjYWxpbmcgZHJpdmVyIHRoYXQgaW50cm9kdWNlcyBhDQo+ID4gbmV3IENQVSBmcmVxdWVuY3kg
Y29udHJvbCBtZWNoYW5pc20gb24gbW9kZXJuIEFNRCBBUFUgYW5kIENQVSBzZXJpZXMNCj4gPiBp
biBYZW4uIFRoZSBuZXcgbWVjaGFuaXNtIGlzIGJhc2VkIG9uIENvbGxhYm9yYXRpdmUgUHJvY2Vz
c29yDQo+ID4gUGVyZm9ybWFuY2UgQ29udHJvbCAoQ1BQQykgd2hpY2ggcHJvdmlkZXMgZmluZXIg
Z3JhaW4gZnJlcXVlbmN5DQo+ID4gbWFuYWdlbWVudCB0aGFuIGxlZ2FjeSBBQ1BJIGhhcmR3YXJl
IFAtU3RhdGVzLiBDdXJyZW50IEFNRCBDUFUvQVBVDQo+ID4gcGxhdGZvcm1zIGFyZSB1c2luZyB0
aGUgQUNQSSBQLXN0YXRlcyBkcml2ZXIgdG8gbWFuYWdlIENQVSBmcmVxdWVuY3kNCj4gPiBhbmQg
Y2xvY2tzIHdpdGggc3dpdGNoaW5nIG9ubHkgaW4gMyBQLXN0YXRlcy4gQ1BQQyByZXBsYWNlcyB0
aGUgQUNQSQ0KPiA+IFAtc3RhdGVzIGNvbnRyb2xzIGFuZCBhbGxvd3MgYSBmbGV4aWJsZSwgbG93
LWxhdGVuY3kgaW50ZXJmYWNlIGZvciBYZW4NCj4gPiB0byBkaXJlY3RseSBjb21tdW5pY2F0ZSB0
aGUgcGVyZm9ybWFuY2UgaGludHMgdG8gaGFyZHdhcmUuDQo+ID4NCj4gPiBhbWRfY3BwYyBkcml2
ZXIgaGFzIDIgb3BlcmF0aW9uIG1vZGVzOiBhdXRvbm9tb3VzIChhY3RpdmUpIG1vZGUsIGFuZA0K
PiA+IG5vbi1hdXRvbm9tb3VzIChwYXNzaXZlKSBtb2RlLiBXZSByZWdpc3RlciBkaWZmZXJlbnQg
Q1BVRnJlcSBkcml2ZXINCj4gPiBmb3IgZGlmZmVyZW50IG1vZGVzLCAiYW1kLWNwcGMiIGZvciBw
YXNzaXZlIG1vZGUgYW5kICJhbWQtY3BwYy1lcHAiDQo+ID4gZm9yIGFjdGl2ZSBtb2RlLg0KPiA+
DQo+ID4gVGhlIHBhc3NpdmUgbW9kZSBsZXZlcmFnZXMgY29tbW9uIGdvdmVybm9ycyBzdWNoIGFz
ICpvbmRlbWFuZCosDQo+ID4gKnBlcmZvcm1hbmNlKiwgZXRjLCB0byBtYW5hZ2UgdGhlIHBlcmZv
cm1hbmNlIHR1bmluZy4gV2hpbGUgdGhlIGFjdGl2ZQ0KPiA+IG1vZGUgdXNlcyBlcHAgdG8gcHJv
dmlkZXMgYSBoaW50IHRvIHRoZSBoYXJkd2FyZSBpZiBzb2Z0d2FyZSB3YW50cyB0bw0KPiA+IGJp
YXMgdG93YXJkIHBlcmZvcm1hbmNlICgweDApIG9yIGVuZXJneSBlZmZpY2llbmN5ICgweGZmKS4g
Q1BQQyBwb3dlcg0KPiA+IGFsZ29yaXRobSBpbiBoYXJkd2FyZSB3aWxsIGF1dG9tYXRpY2FsbHkg
Y2FsY3VsYXRlIHRoZSBydW50aW1lDQo+ID4gd29ya2xvYWQgYW5kIGFkanVzdCB0aGUgcmVhbHRp
bWUgY3B1IGNvcmVzIGZyZXF1ZW5jeSBhY2NvcmRpbmcgdG8gdGhlDQo+ID4gcG93ZXIgc3VwcGx5
IGFuZCB0aGVybWFsLCBjb3JlIHZvbHRhZ2UgYW5kIHNvbWUgb3RoZXIgaGFyZHdhcmUgY29uZGl0
aW9ucy4NCj4gPg0KPiA+IGFtZC1jcHBjIGlzIGVuYWJsZWQgb24gcGFzc2l2ZSBtb2RlIHdpdGgg
YSB0b3AtbGV2ZWwNCj4gPiBgY3B1ZnJlcT1hbWQtY3BwY2Agb3B0aW9uLCB3aGlsZSB1c2VycyBh
ZGQgZXh0cmEgYGFjdGl2ZWAgZmxhZyB0byBzZWxlY3QgYWN0aXZlDQo+IG1vZGUuDQo+ID4NCj4g
PiBXaXRoIGBjcHVmcmVxPWFtZC1jcHBjLGFjdGl2ZWAsIHdlIGRpZCBhIDYwcyBzYW1wbGluZyB0
ZXN0IHRvIHNlZSB0aGUNCj4gPiBDUFUgZnJlcXVlbmN5IGNoYW5nZSwgdGhyb3VnaCB0d2Vha2lu
ZyB0aGUgZW5lcmd5X3BlcmYgcHJlZmVyZW5jZSBmcm9tDQo+ID4gYHhlbnBtIHNldC1jcHVmcmVx
LWNwcGMgcG93ZXJzYXZlYCB0byBgeGVucG0gc2V0LWNwdWZyZXEtY3BwYyBwZXJmb3JtYW5jZWAu
DQo+ID4gVGhlIG91dHB1dHMgYXJlIGFzIGZvbGxvd3M6DQo+ID4gYGBgDQo+ID4gU2V0dGluZyBD
UFUgaW4gcG93ZXJzYXZlIG1vZGUNCj4gPiBTYW1wbGluZyBhbmQgT3V0cHV0czoNCj4gPiAgIEF2
ZyBmcmVxICAgICAgNTgwMDAwIEtIeg0KPiA+ICAgQXZnIGZyZXEgICAgICA1ODAwMDAgS0h6DQo+
ID4gICBBdmcgZnJlcSAgICAgIDU4MDAwMCBLSHoNCj4gPiBTZXR0aW5nIENQVSBpbiBwZXJmb3Jt
YW5jZSBtb2RlDQo+ID4gU2FtcGxpbmcgYW5kIE91dHB1dHM6DQo+ID4gICBBdmcgZnJlcSAgICAg
IDQ2NDAwMDAgS0h6DQo+ID4gICBBdmcgZnJlcSAgICAgIDQyMjAwMDAgS0h6DQo+ID4gICBBdmcg
ZnJlcSAgICAgIDQ2NDAwMDAgS0h6DQo+ID4NCj4gPiBQZW5ueSBaaGVuZyAoMTgpOg0KPiA+ICAg
eGVuL2NwdWZyZXE6IGd1YXJkIHBlcmYuc3RhdGVzW10gYWNjZXNzIHdpdGggWEVOX1BYX0lOSVQN
Cj4gPiAgIHhlbi9jcHVmcmVxOiBtb3ZlICJpbml0IiBmbGFnIGludG8gY29tbW9uIHN0cnVjdHVy
ZQ0KPiA+ICAgeGVuL2NwdWZyZXE6IGV4dHJhY3QgX1BTRCBpbmZvIGZyb20gInN0cnVjdCB4ZW5f
cHJvY2Vzc29yX3BlcmZvcm1hbmNlIg0KPiA+ICAgeGVuL2NwdWZyZXE6IGludHJvZHVjZSBuZXcg
c3ViLWh5cGVyY2FsbCB0byBwcm9wYWdhdGUgQ1BQQyBkYXRhDQo+ID4gICB4ZW4vY3B1ZnJlcTog
cmVmYWN0b3IgY21kbGluZSAiY3B1ZnJlcT14eHgiDQo+ID4gICB4ZW4vY3B1ZnJlcTogaW50cm9k
dWNlICJjcHVmcmVxPWFtZC1jcHBjIiB4ZW4gY21kbGluZQ0KPiA+ICAgeGVuL2NwdWZyZXE6IGRp
c2FibGUgcHggc3RhdGlzdGljIGluZm8gaW4gYW1kLWNwcGMgbW9kZQ0KPiA+ICAgeGVuL2NwdTog
RXhwYW5kIGNvcmUgZnJlcXVlbmN5IGNhbGN1bGF0aW9uIGZvciBBTUQgRmFtaWx5IDFBaCBDUFVz
DQo+ID4gICB4ZW4vYW1kOiBpbnRyb2R1Y2UgYW1kX3Byb2Nlc3NfZnJlcSgpIHRvIGdldCBwcm9j
ZXNzb3IgZnJlcXVlbmN5DQo+ID4gICB4ZW4vY3B1ZnJlcTogaW50cm9kdWNlIGEgbmV3IGFtZCBj
cHBjIGRyaXZlciBmb3IgY3B1ZnJlcSBzY2FsaW5nDQo+ID4gICB4ZW4vY3B1ZnJlcTogaW1wbGVt
ZW50IEVQUCBzdXBwb3J0IGZvciB0aGUgYW1kLWNwcGMgZHJpdmVyIGluIGFjdGl2ZQ0KPiA+ICAg
ICBtb2RlDQo+ID4gICB4ZW4vY3B1ZnJlcTogZ2V0IHBlcmZvcm1hbmNlIHBvbGljeSBmcm9tIGdv
dmVybm9yIHNldCB2aWEgeGVucG0NCj4gPiAgIHhlbi9jcHVmcmVxOiBub3JtYWxpemUgaHdwIGRy
aXZlciBjaGVjayB3aXRoIGh3cF9hY3RpdmUoKQ0KPiA+ICAgeGVuL2NwdWZyZXE6IGludHJvZHVj
ZSBHRVRfQ1BVRlJFUV9DUFBDIHN1Yi1jbWQNCj4gPiAgIHhlbi9jcHVmcmVxOiBieXBhc3MgZ292
ZXJub3ItcmVsYXRlZCBwYXJhIGZvciBhbWQtY3BwYy1lcHANCj4gPiAgIHRvb2xzOiBkcm9wICJo
YXNfbnVtIiBjb25kaXRpb24gY2hlY2sgZm9yIGNwcGMgbW9kZQ0KPiA+ICAgdG9vbHM6IG9wdGlt
aXplIGNwdWZyZXEgYXZlcmFnZSBmcmVxIHByaW50DQo+ID4gICB4ZW4vY3B1ZnJlcTogQWRhcHQg
U0VUL0dFVF9DUFVGUkVRX0NQUEMgeGVuX3N5c2N0bF9wbV9vcCBmb3IgYW1kLQ0KPiBjcHBjDQo+
ID4gICAgIGRyaXZlcg0KPg0KPiBBcyBpbmRpY2F0ZWQgaW4gaW5kaXZpZHVhbCByZXBsaWVzLCB0
aHJlZSBvZiB0aGUgcGF0Y2hlcyBtYXkgYmUgcG9zc2libGUgdG8gZ28gaW4NCj4gYmVmb3JlIHlv
dSByZS1wb3N0LiBTdWJqZWN0IHRvIHdoYXQgSSBzYWlkIGluIHRoZSByZXBsaWVzIChwYXRjaGVz
IDAyLCAwOCwgYW5kIDEzKS4NCj4gUGxlYXNlIGNsYXJpZnkgd2hhdCAoaWYgYW55dGhpbmcpIHRv
IGRvLg0KPg0KDQpGb3IgcGF0Y2ggMDIsIHRoZSBvbmx5IGNvbmNlcm4gaXMgdGhhdCBpdCBpcyBi
YXNlZCBvbiAwMSwgYW5kIDAxIHNoYWxsIGJlIHJlbW92ZWQgYW5kIEknbGwgYWRkIGV4dHJhIGNo
ZWNrIGZvciBDUFBDIHRvIGVuc3VyZSAtPnBlcmYuc3RhdGVfY291bnQgbXVzdCBiZSB6ZXJvIGlu
IGdldF9jcHVmcmVxX3BhcmEoKQ0KRm9yIHBhdGNoIDA4LCBJIGFscmVhZHkgaGF2ZSBhZ3JlZWQg
aW4gaW5kaXZpZHVhbCByZXBseQ0KRm9yIHBhdGNoIDEzLCBvayBmb3IgbWUgdG9vDQoNCj4gSmFu
DQo=


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 06:28:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 06:28:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018802.1395657 (Exim 4.92)
	(envelope-from )
	id 1uRmHL-0006hQ-9P; Wed, 18 Jun 2025 06:28:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018802.1395657; Wed, 18 Jun 2025 06: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 1uRmHL-0006hJ-67; Wed, 18 Jun 2025 06:28:11 +0000
Received: by outflank-mailman (input) for mailman id 1018802;
 Wed, 18 Jun 2025 06:28: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 1uRmHK-0006hD-IW
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 06:28:10 +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 66274080-4c0d-11f0-b894-0df219b8e170;
 Wed, 18 Jun 2025 08:28:08 +0200 (CEST)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3a57c8e247cso3058461f8f.1
 for ; Tue, 17 Jun 2025 23:28:08 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-748e8c829a4sm625497b3a.83.2025.06.17.23.28.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Jun 2025 23:28:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 66274080-4c0d-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750228087; x=1750832887; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=TTVn4Hl64czbo+ZZy1AaXGIeiX0PCzGpyRcEjxxJJYc=;
        b=UMmirXpGRI00asJRJyx7NsQiOwwoanAyGT7Gp1kB3e9iEQdJeIDZofHcySzpY7fZvg
         bu51BCAH5kCO5+WXc+k+PEoQqu/cn/drribkG4VQcDSi/KZiNYepjEM873QxZu32Yegq
         Dek9tsZRdp2SwvIzrgnsI9bJCG+U1mJ/64okGNCgGwBWZ9kZltYq7daweKw8OglQMW3W
         OT6r2Qh+ryVE7J1RKL90G4mnA3ILKlkbz1zl0jeJZCz+/To9MKZp4LsZac8jsNdu6P9I
         lPn/aQrZdXnX/73hUJItp03Unu5H1xIzN+EdLnX/A2P8GtxfsDp8Tw35M9nTHyoG9Hjp
         FRCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750228087; x=1750832887;
        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=TTVn4Hl64czbo+ZZy1AaXGIeiX0PCzGpyRcEjxxJJYc=;
        b=mp5UNvWUOQ6ufo3x1dLpakwNftrRKxqvH8J6hFoMseIDHU3Ye/qDzVNnTgGMzg1qWh
         9GC7u9F1zC+o+PLHfBxu/FW7V729mE9b1ii2iq3t5dDp65vS6d0Ceidna4beX6tewvoK
         x+wMUVf345GNulmrgoSl0zQkEVDBD9b5h20Fhj2Xd2D1k7MY0iMg0a+dhrpWs7SLR8EW
         IJWxDCEVKvvwub5o4io7LTk2pgSdCl48P8P2DPB037PWBTHEe4kUQU6qgHA52S9vQRL9
         9oXSilmyWAKvc0w9P9w7zjaQOOpDl4GWqpf08SMCJCYLrDCDppMosmBAXPohXYzLSppe
         oyNg==
X-Forwarded-Encrypted: i=1; AJvYcCWiiEUAYQjx93RHTh7UZ7gLAhMFDWYUcAss/mZn4iPTKXUApTYBxbWHqkd3XydxUix545BrM+/mO30=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyVqY+uWNuLqLeC3GMoIOxuD9oX7CoDaale9KjTqdwojFwPyJoy
	EP6j4eQMBLIlRQ8pDiK7RlSv1cspzWu0I/9mVmxAnaA3ceKkAuGRzpFDaRu8vu1PDA==
X-Gm-Gg: ASbGncvzlz0nWSRpttO58x9oCDxO/ip9ew7Ui079xWLIAndYUHKy/fQrZmkPuor6P2+
	+30xW8fXk/GZ9djegDnSzpNnUfyuwHmvxDm8iEZAE12cqDW0FSm+oaKHuBuwokGuEtwG4P+R79D
	cWOJX6BfcHZdCdaqoJp2hXYm8Fb3JG8sju+gwi+DHSAevw5ig5VvHu2wnqQRvtmpBHACGQ71SMI
	2Nr8fEfVFNMZSfPgJiwL45K8ew568VrxmhsNpSm9nVJz6539ZSKx/Jr6mntMKLQ1eSL5AX4D5GL
	9gPcDNi6eavlVOG2b6/p6R5hK2OdAymVbn6rIFNPCbJNqaz7WmgmOlO3A3THi2v6dJBpBk/wtP6
	6H9EuWjnyDcaDCf18MsstFG5+fWTrhDmVz7rM9nPTaWuyEt8=
X-Google-Smtp-Source: AGHT+IH6CHj7L2gZtKnioPF+XoHpgOaAE4Sk+6oHuXBf1iy/gcigmFP5syXiz9bey7wFNGLZ0BFuaQ==
X-Received: by 2002:a05:6000:1a85:b0:3a4:f70d:a65e with SMTP id ffacd0b85a97d-3a572e6b9f4mr13606368f8f.37.1750228087540;
        Tue, 17 Jun 2025 23:28:07 -0700 (PDT)
Message-ID: <2f726960-4bdc-4996-b204-722c0253e2ab@suse.com>
Date: Wed, 18 Jun 2025 08:27:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/2] xen/console: unify printout behavior for UART
 emulators
To: Stefano Stabellini 
Cc: dmkhn@proton.me, andrew.cooper3@citrix.com, anthony.perard@vates.tech,
 julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com,
 dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250606201102.2414022-1-dmukhin@ford.com>
 <20250606201102.2414022-3-dmukhin@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: 7bit

On 18.06.2025 02:39, Stefano Stabellini wrote:
> On Thu, 12 Jun 2025, Jan Beulich wrote:
>> On 11.06.2025 21:07, Stefano Stabellini wrote:
>>> On Wed, 11 Jun 2025, Jan Beulich wrote:
>>>> On 11.06.2025 02:07, dmkhn@proton.me wrote:
>>>>> On Tue, Jun 10, 2025 at 10:21:40AM +0200, Jan Beulich wrote:
>>>>>> On 06.06.2025 22:11, dmkhn@proton.me wrote:
>>>>>>> From: Denis Mukhin 
>>>>>>>
>>>>>>> If virtual UART from domain X prints on the physical console, the behavior is
>>>>>>> updated to (see [1]):
>>>>>>> - console focus in domain X: do not prefix messages;
>>>>>>> - no console focus in domain X: prefix all messages with "(dX)".
>>>>>>
>>>>>> While, as indicated (much) earlier, I can see why omitting the prefix
>>>>>> may make sense for the domain having input focus, ...
>>>>>>
>>>>>>> --- a/xen/drivers/char/console.c
>>>>>>> +++ b/xen/drivers/char/console.c
>>>>>>> @@ -740,7 +740,17 @@ 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 */
>>>>>>> +            char prefix[16] = "";
>>>>>>> +            struct domain *consd;
>>>>>>> +
>>>>>>> +            consd = console_get_domain();
>>>>>>> +            if ( consd != cd )
>>>>>>> +                snprintf(prefix, sizeof(prefix), "(d%d) ", cd->domain_id);
>>>>>>> +            console_put_domain(consd);
>>>>>>> +
>>>>>>>              nrspin_lock_irq(&console_lock);
>>>>>>> +            if ( prefix[0] != '\0' )
>>>>>>> +                console_send(prefix, strlen(prefix), flags);
>>>>>>>              console_send(kbuf, kcount, flags);
>>>>>>>              nrspin_unlock_irq(&console_lock);
>>>>>>>          }
>>>>>>
>>>>>> ... this, aiui, is a behavioral change for the non-dom0less case, where
>>>>>> Dom0 output will suddenly also gain the prefix. Which I don't think is
>>>>>> wanted: Switching focus between Xen and Dom0 should remain unaffected
>>>>>> in this regard.
>>>>>
>>>>> This change ensures that dom0 traces aren't mixed with domU traces when domU
>>>>> has input focus, or with Xen traces when the administrator is in the diagnostic
>>>>> console.
>>>>
>>>> That's what the description also tries to describe, yet I still regard it as
>>>> a behavioral regression in (at least) the described scenario. The hardware
>>>> domain presently not having (d0) prefixed to its output is deliberate imo,
>>>> not accidental.
>>>
>>> If we only consider the classic dom0 and dom0less usage models, then
>>> what you wrote makes perfect sense. In the classic dom0 case, it is best
>>> for dom0 to have no prefix, which is the current behavior.
>>>
>>> However, things become more complex with dom0less. As we have discussed
>>> previously, it has already become desirable on both ARM and x86 to align
>>> on the same behavior. During our last discussion, the preference was to
>>> add a '(d0)' prefix to clearly differentiate output from dom0 and other
>>> domains.
>>>
>>> Up to now, we could easily detect the two different cases depending on
>>> the boot configuration. The problem arises with Denis' patches, which
>>> add the ability for dynamically created guests via `xl` to access an
>>> emulated NS16550 UART that prints to the console. Because these guests
>>> are created dynamically, it is not clear how we are going to handle
>>> this case.
>>
>> Why would this be not clear? We already prefix their output with "(d)"
>> when going the traditional way. The same would then apply to output
>> coming through the emulated UART.
>>
>>> If we follow the dom0less preference, then we would need a '(d0)' prefix
>>> for dom0. If we follow the classic dom0 model, then dom0 would remain
>>> without a prefix, and the new domUs would have a prefix. This would
>>> cause an inconsistency. However, this is what we have today on ARM with
>>> dom0less.
>>>
>>> If Jan feels strongly that we should retain no prefix for the classic
>>> dom0 case, which is understandable, then I believe the best course of
>>> action would be to change our stance on dom0less on both ARM and x86 and
>>> also use no prefix for dom0 in the dom0less case (which is the current
>>> state on ARM).
>>
>> Leaving aside that "dom0 in the dom0less" ought to really be not-a-thing,
>> I disagree. Present behavior of not prefixing the domain's output which
>> has input focus continues to make sense. That requires Dom0 to have a
>> prefix whenever it doesn't have input focus.
> 
> If I understood correctly I like your proposal. Let me rephrase it to
> make sure we are aligned. You are suggesting that:
> 
> - domains without input focus will print with a (d) prefix
> - the domain with input focus will print without a (d) prefix
> - this applies to both DomUs and Dom0

Except in the non-dom0less case, at least up and until there's at least
one other domain. I.e. I'd like to keep Dom0 boot output as it is today,
regardless of the presence of e.g. "conswitch=".

Jan

> - this applies to both predefined domains and also dynamic domains
> 
> I am OK with that. I believe this is not the current behavior on ARM but
> I can appreciate the simple consistency of it.



From xen-devel-bounces@lists.xenproject.org Wed Jun 18 06:38:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 06:38:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018809.1395667 (Exim 4.92)
	(envelope-from )
	id 1uRmQw-0008P6-3t; Wed, 18 Jun 2025 06:38:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018809.1395667; Wed, 18 Jun 2025 06: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 1uRmQw-0008Oz-19; Wed, 18 Jun 2025 06:38:06 +0000
Received: by outflank-mailman (input) for mailman id 1018809;
 Wed, 18 Jun 2025 06:38: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 1uRmQu-0008Ot-MP
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 06:38:04 +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 c9142ebd-4c0e-11f0-a30a-13f23c93f187;
 Wed, 18 Jun 2025 08:38:03 +0200 (CEST)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-4530921461aso56019325e9.0
 for ; Tue, 17 Jun 2025 23:38:03 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2365d8a183asm91968075ad.53.2025.06.17.23.37.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Jun 2025 23:38:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c9142ebd-4c0e-11f0-a30a-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750228683; x=1750833483; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=a+o9Cx0kPDj6marB3XKFr4cvPdDIdjpwasKdBBVlKPY=;
        b=XeaqB76dU/rPYH9snNRcKR5FH7CEaBSOlfE0xet53qnDe+ChliE3FjbgwOTaNAnP1a
         eruLvGSyNadrKqA0ZCGM+r0OQeha9N9z64wMV3J73s3H95Ea0SVO4SCzvtv+d4IOkkB8
         LSEjU63jvVmjKTv+ZNsAs3ygX1/FyA0stmVvhDlC+Bz8B/q8gnqNCk6NrpsAuSkxz4Te
         lFuaLhbJfaNiNqsFAGvR/PVMtVfQNOAqsIzRsfHwo6N+X4qP8VvQzUNa0IEmC2mKtHuS
         HMcRJdErkdvMAwL1GhGi1nkxS2zfP1kX0cB8t96uR1pgJJ9QStgfZD5YllBFwsNFI46H
         mupQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750228683; x=1750833483;
        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=a+o9Cx0kPDj6marB3XKFr4cvPdDIdjpwasKdBBVlKPY=;
        b=MPJJODz3y3KNvfonb9+KiK3VoPJTJBtPoJnPJel1lpffWWr6GiEUaY9A04CCHzukpf
         HAzUkNGSQWYPfEKZ30cSPbaquzqof9XiISN9M3LIumwoFxYqmldlu8YKV/J4pih3G6XR
         P0UKj7aAcZgPdnJMki7ZC2nkePuVLFha7jetv5a2265K7rcYw222TtGBL8PT+b7KQSV5
         aYIK0u9auPSPlHDMqec6jxWfm7CzuXAGsER70xBZNaBaDSimaYzsqeDnjpKQJWsOk1Eq
         aqaz2HqRG1a2zZtj8kB67U9TqcTFb5o4J3d1A5LPfVKHd9e520XphP+Cm4WouL0phVlp
         a5nA==
X-Forwarded-Encrypted: i=1; AJvYcCUIEsW61VBpsXanmtyRFx2DpU5mi5bb29HJqvqs7v4V/EDHZCQpstVn1p2lPTcOE2nRdALea+w3TkI=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz/zgS+5bxgrKCxTNcPrF+XLYdkQ07EN+Tglb6PNVLI1APfAkbO
	mZVWDj8/zjOc34Uy/apKqkFmkAb7IOCfw7Zkzf0UhwBy4xSkDmHKlm6l4S8Qnu9jdg==
X-Gm-Gg: ASbGnctTfUQHyMyZKGobSadTgysz+T0IE+tFuM5vq6htR1c+5CJDeqP0GifFlvhQEAp
	Zh7VB5Z2qRSWskN6hjrgd5KGDK7mSxla+YzrTtKy3izDAQpVVo4DN9lkhbRDuZN/NV75zBVtxHQ
	6zfL5gO3wWSFvIPUHtDe7iotAuK2AoE8lWyswkRovca42ZFTJTtPvdDazyAQIr+XgTG1nL+4TzS
	nMBZLhxIH2372NbsTdGAEvseHVgmS/pSpmrUR5N7kL4iNsac6DQqf+qVzXz2vK5e41J0GVSTrFc
	TkZSJHe8Ea4flZO04kc+Bx1ZEG4q18EaZJpKrEvyseTnEHHLnDeUbYFz6DBcuxgRpKmojyxr/qx
	pdhlNEgqy1jnq79XNtqjyqC5XC87RrxSJf2yJez8lUB+4yMRSFumapgXmnw==
X-Google-Smtp-Source: AGHT+IGt0ZUyDxLCWcUHBPF3ZxD3N4f8U+i/60UgHPNRxQa9mS5d0H0+ig3JtSnJmNso02dm7iAifA==
X-Received: by 2002:a05:6000:1887:b0:3a4:e393:11e2 with SMTP id ffacd0b85a97d-3a5723a22d6mr13711435f8f.34.1750228682993;
        Tue, 17 Jun 2025 23:38:02 -0700 (PDT)
Message-ID: 
Date: Wed, 18 Jun 2025 08:37:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen/dt: Remove loop in dt_read_number()
To: Alejandro Vallejo 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel , xen-devel@lists.xenproject.org
References: <20250617171358.670642-1-agarciav@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: <20250617171358.670642-1-agarciav@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17.06.2025 19:13, Alejandro Vallejo wrote:
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -261,10 +261,21 @@ void intc_dt_preinit(void);
>  /* Helper to read a big number; size is in cells (not bytes) */
>  static inline u64 dt_read_number(const __be32 *cell, int size)
>  {
> -    u64 r = 0;
> +    u64 r = be32_to_cpu(*cell);
> +
> +    switch ( size )
> +    {
> +    case 1:
> +        break;
> +    case 2:
> +        r = (r << 32) | be32_to_cpu(cell[1]);
> +        break;
> +    default:
> +        // Nonsensical size. default to 1.
> +        printk(XENLOG_WARNING "dt_read_number(%d) bad size\n", size);

Might be good to entirely unambiguously indicate it's the 2nd argument.
Iirc an approach we use elsewhere is to spell it dt_read_number(,%d).

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 07:04:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 07:04:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018816.1395676 (Exim 4.92)
	(envelope-from )
	id 1uRmq4-0003yk-1w; Wed, 18 Jun 2025 07:04:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018816.1395676; Wed, 18 Jun 2025 07:04: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 1uRmq3-0003yd-VM; Wed, 18 Jun 2025 07:04:03 +0000
Received: by outflank-mailman (input) for mailman id 1018816;
 Wed, 18 Jun 2025 07:04: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 1uRmq3-0003yX-10
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 07:04:03 +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 68ff6a90-4c12-11f0-b894-0df219b8e170;
 Wed, 18 Jun 2025 09:04:00 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-450d668c2a1so2395105e9.0
 for ; Wed, 18 Jun 2025 00:04:00 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-7488ffecce6sm10534181b3a.10.2025.06.18.00.03.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Jun 2025 00:03:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 68ff6a90-4c12-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750230240; x=1750835040; 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=WwiLSuNhnr4M4BxYNCLPFs9KKYxhMlfbdYVygsxw8F4=;
        b=agr3eItWSDT0Yj8j8vvPjombGYz+J2wVLrqI0H3uABfjayNTA+mDkXJJg14BD2eqhl
         THWZQLA1hCzgatuNcvfuEKQs+Df7FRre2Wcfnd29WbQiTIlfEufIU7szB/ONhoslt00O
         e8qOWywnrBfmNVIV/5AlDixSuljMsEfT+KgS7NStS52yGURp6wSBEnAsbOYZ8pX7a8x4
         +hXzAmK/MnX3Lh0IRgrT2x0ULYIntqjYwrwlzijIJPmVUQ2VlTe1/IN8yasRZy0CciN7
         Ri+pWd4bJ6JxifMveXyQifQura16Y2VxsCr6pI4IcaaUIIUrd2RVCry9VPX9YYuZXxCB
         lGUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750230240; x=1750835040;
        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=WwiLSuNhnr4M4BxYNCLPFs9KKYxhMlfbdYVygsxw8F4=;
        b=wO+S+3vlj9FhQ0DzeLxMqqofCDX7plcX4RuUcp5kIQbeZkGPK4GQ9a02VGgweCY8nR
         bIxDCQ+57IfBUEZrFHtar2L/zMMHVG5P0KMF6cuPtNVMgRH443mrG91LxxHjUvxbJsxw
         7RcOWjgtvgEvLpcTpYrU3JCQ2Fvn+0ZAG3rdPTSXPV9Tx2uElGeji6dZSAG72Vz5GKud
         UBGxlwZJqj3pDX4b70u6prlCT2EE4BifcJr4gmhwVqmH/oADEN0bBPLTBM/3Udg/o0/7
         nW73HIgPNFu3u8Q3jicS8QWghMYMyBT3H6IBsrQqy9o0Jc0O8Qtm2MUcGhfdz3pcp71F
         WJgA==
X-Gm-Message-State: AOJu0YxWZp1KDkOZVmKxZhV4kl2FvwN4l7fjLqTmbXHaM9chmbiQdEb5
	74XaZIs/us54mzMryJeyOs8mNB0qCyVHZ+AQNxSMDwoQ7C/7HEctKf5DGwrnHuksor4707yc9Ec
	HHk4=
X-Gm-Gg: ASbGncuJ15sC4hNJBraWScpkP3nA+l3LnzSh3GQBd6ss3YMbtT9oLbK+3OYrxMKOtct
	WkKzKNSCZjTO5kQ8SPfeuSdahA+VUfnrTi82dR8A6Ide352U8DJcZnjsxlu2CO0OvPZWiWkDCix
	ZPao5cuQGXltaU7OAMmy0OqT5rk+Jhey/6qWje+1i7e8NI4OgjWnhbX5HPy+2TvX/9ZU7XqiLo1
	BiSvTR6AgiotLmlIokvyzguq5L+kIHEKOHFPpRrpHzaN/1RS2QlfpM2DKTWpK5WHlPaZgSHZ26p
	yaPviiCe+7UDZKvvraL6C+99nmiSn16G/sGnhtVhbVqxNPVuzoGbgyez47ZQGsjP/ClEm76ApPU
	UEKfjglOF2yGU2ubfOehQi9Vn319eYKWWRxZf4oZL68BBerUzRCsWiUwDTA==
X-Google-Smtp-Source: AGHT+IHWWWMg55BdleC+j2/hzOYuL9wzoV2xmLxnYUz6rXYEVA9i7dMwfIQrqT6OyhC5YDdGFRrcfw==
X-Received: by 2002:a05:6000:2408:b0:3a4:eb7a:2ccb with SMTP id ffacd0b85a97d-3a58e169b1emr1026150f8f.16.1750230239800;
        Wed, 18 Jun 2025 00:03:59 -0700 (PDT)
Message-ID: <585f1b0b-6768-4f9c-8f9f-bcf6e20fbfb7@suse.com>
Date: Wed, 18 Jun 2025 09:03:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Jan Beulich 
Subject: [PATCH v8 0/7] x86emul: misc additions
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

1: x86emul: support LKGS
2: x86emul+VMX: support {RD,WR}MSRLIST
3: x86emul: support USER_MSR instructions
4: x86/cpu-policy: re-arrange no-VMX logic
5: VMX: support USER_MSR
6: x86emul: support MSR_IMM instructions
7: x86emul: support non-SIMD MOVRS

Due to lack of specification the VMX counterpart for MSR_IMM continues to
be missing (unlike USER_MSR).

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 07:05:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 07:05:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018822.1395686 (Exim 4.92)
	(envelope-from )
	id 1uRmqz-0004UK-Ai; Wed, 18 Jun 2025 07:05:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018822.1395686; Wed, 18 Jun 2025 07: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 1uRmqz-0004UB-7z; Wed, 18 Jun 2025 07:05:01 +0000
Received: by outflank-mailman (input) for mailman id 1018822;
 Wed, 18 Jun 2025 07: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 1uRmqy-0004U2-8J
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 07:05:00 +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 8b56d358-4c12-11f0-b894-0df219b8e170;
 Wed, 18 Jun 2025 09:04:58 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a522224582so3613840f8f.3
 for ; Wed, 18 Jun 2025 00:04:58 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-748900ad2absm10166075b3a.110.2025.06.18.00.04.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Jun 2025 00:04:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8b56d358-4c12-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750230297; x=1750835097; 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=PQnQFyVz2WysDVSYTMC3e0YMSUDDKmixVkszbOo00FQ=;
        b=V+wASutsGjyqVlPF1I8d/FDH7h/irKMoau4I6rh1q1/vj4iAhmbJmmHMjmlQjFsZKC
         JFMYG2m5yrz5EUAwk3l24X2VGiIe+tGiDjb2xYqhGLFUk0f3muD+ek13L9FllYGXx2tT
         xaoSbGf/NPXpVR/0pItchstQ6aS64mU8KEiuGlDgwYMPN8p5gW42TrK/ufnax+atxAkX
         aNcbUWf72GvHpfmbDtFS1xkfVYxdoZsI8Auyj0oo+/Fg4RDBKgslB3tdIWlszuQtVV2W
         LIF+8HwsxQaAjN4loDq6eKISGNzZxYpmmhNyUgZQ2ogwPnko8h1ahiKlyrW9Aom8Vanm
         awHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750230297; x=1750835097;
        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=PQnQFyVz2WysDVSYTMC3e0YMSUDDKmixVkszbOo00FQ=;
        b=js57X5wQsi+73kUjAohDBgw23LyjbZc4dkM4nbaxGGvXb4FIiQSWLiH+5xXRNWt4Eu
         5hNjg1lvslICpji9QdsWf5MgerH2gog3OoL4jm4tQC/jcyNb0HnckmgboFPgWVhc7GlF
         XbDH/yaPCHHfNStaFntfM65dtIydZFvnqLZEYBMUtUhd+UcYVl3F0UqMu/MuNgg8EKxC
         BxQyFn1bLW3EYIF9Gyl6ATvlAQ0DMBMHYSidm/I0QmOYj10CTGoToCKUhnf2dPbMb7za
         A73CEb5ynl3yKRMp9EJFzu33wO4AQhNGarNwbIbm4U4b0M2DY7PS3C2jv5W3S5B5uVud
         /wKQ==
X-Gm-Message-State: AOJu0YzCwEhzKxFAwnFvcMpHNbjMMy69XoYmwzUZmC1qKFasdXoZmxFn
	G+3g2FJzsxzXdIrT016i93WNZfHBO1gqWZlnsx9S6REPFMnU1EuRCCGcEtot9z+Wke6CBC7AD+B
	KVOo=
X-Gm-Gg: ASbGncuUgcefEeYd2AvKjvmdos3sheePyVKAeoqDQcxqxkn6EH4akXFejOxFfNgKiwN
	krobrkb6971Ixjk7p+uhbBEkf1kLt/5esEXSMRuCP2OT0uilrRBJri0zpdYY8AMtWC9kAOU/MH2
	EbHy5eDYINOLYlvMotHP0BI8xJwbRDiOTc/DiB4/OjD3e9J3yAmtKZEbFkHsyUN+rieKsD/YJl8
	Wjq/91iW9xZoOWd3paj27fKB4Ozz4n5pSke6KhO2F4lAJivPxABySj5t6RLBHA2/r2szDo0jzk4
	BmNV51T05Zu0Cg5hroMKzuML+bQaq/oe4rzW9epwUefjybDo5rL+V0KuAml3QZlo3JWVlK0u/0G
	BxZJMznpEIEDZYNU/y6KQhWjFuKke01YsMZ/J/lC+zoESMCo=
X-Google-Smtp-Source: AGHT+IGFqwQjUJE3OuHUEsmJiIZ89nuKxTEV9GOfLx+MHNEM1LcOkkiUJp1oFwpYHrbHPtMWvYKAsQ==
X-Received: by 2002:a05:6000:2dc3:b0:3a5:39a0:2309 with SMTP id ffacd0b85a97d-3a572e586dbmr13051979f8f.55.1750230297256;
        Wed, 18 Jun 2025 00:04:57 -0700 (PDT)
Message-ID: <03d20e4f-f264-49ce-8f6e-1a8217d1da87@suse.com>
Date: Wed, 18 Jun 2025 09:04:50 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v8 1/7] x86emul: support LKGS
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <585f1b0b-6768-4f9c-8f9f-bcf6e20fbfb7@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: <585f1b0b-6768-4f9c-8f9f-bcf6e20fbfb7@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Provide support for this insn, which is a prereq to FRED. CPUID-wise
introduce both its, FRED's, and the NMI_SRC bit at this occasion, thus
allowing to also express the dependency right away.

While adding a testcase, also add a SWAPGS one. In order to not affect
the behavior of pre-existing tests, install write_{segment,msr} hooks
only transiently.

Signed-off-by: Jan Beulich 
---
Instead of ->read_segment() we could of course also use ->read_msr() to
fetch the original GS base. I don't think I can see a clear advantage of
either approach; the way it's done it matches how we handle SWAPGS.

For PV save_segments() would need adjustment, but the insn being
restricted to ring 0 means PV guests can't use it anyway (unless we
wanted to emulate it as another privileged insn).
---
v8: Re-base.
v6: Use MSR constants in test harness. S->s in cpufeatureset.h. Add
    NMI_SRC feature bits. Re-base.
v5: Re-base.
v3: Add dependency on LM. Re-base.
v2: Use X86_EXC_*. Add comments.

--- a/tools/tests/x86_emulator/predicates.c
+++ b/tools/tests/x86_emulator/predicates.c
@@ -326,6 +326,7 @@ static const struct {
     { { 0x00, 0x18 }, { 2, 2 }, T, R }, /* ltr */
     { { 0x00, 0x20 }, { 2, 2 }, T, R }, /* verr */
     { { 0x00, 0x28 }, { 2, 2 }, T, R }, /* verw */
+    { { 0x00, 0x30 }, { 0, 2 }, T, R, pfx_f2 }, /* lkgs */
     { { 0x01, 0x00 }, { 2, 2 }, F, W }, /* sgdt */
     { { 0x01, 0x08 }, { 2, 2 }, F, W }, /* sidt */
     { { 0x01, 0x10 }, { 2, 2 }, F, R }, /* lgdt */
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -672,6 +672,10 @@ static int blk(
     return x86_emul_blk((void *)offset, p_data, bytes, eflags, state, ctxt);
 }
 
+#ifdef __x86_64__
+static unsigned long gs_base, gs_base_shadow;
+#endif
+
 static int read_segment(
     enum x86_segment seg,
     struct segment_register *reg,
@@ -681,8 +685,30 @@ static int read_segment(
         return X86EMUL_UNHANDLEABLE;
     memset(reg, 0, sizeof(*reg));
     reg->p = 1;
+
+#ifdef __x86_64__
+    if ( seg == x86_seg_gs )
+        reg->base = gs_base;
+#endif
+
+    return X86EMUL_OKAY;
+}
+
+#ifdef __x86_64__
+static int write_segment(
+    enum x86_segment seg,
+    const struct segment_register *reg,
+    struct x86_emulate_ctxt *ctxt)
+{
+    if ( !is_x86_user_segment(seg) )
+        return X86EMUL_UNHANDLEABLE;
+
+    if ( seg == x86_seg_gs )
+        gs_base = reg->base;
+
     return X86EMUL_OKAY;
 }
+#endif
 
 static int read_msr(
     unsigned int reg,
@@ -695,6 +721,20 @@ static int read_msr(
         *val = ctxt->addr_size > 32 ? EFER_LME | EFER_LMA : 0;
         return X86EMUL_OKAY;
 
+#ifdef __x86_64__
+    case MSR_GS_BASE:
+        if ( ctxt->addr_size < 64 )
+            break;
+        *val = gs_base;
+        return X86EMUL_OKAY;
+
+    case MSR_SHADOW_GS_BASE:
+        if ( ctxt->addr_size < 64 )
+            break;
+        *val = gs_base_shadow;
+        return X86EMUL_OKAY;
+#endif
+
     case MSR_TSC_AUX:
 #define TSC_AUX_VALUE 0xCACACACA
         *val = TSC_AUX_VALUE;
@@ -704,6 +744,31 @@ static int read_msr(
     return X86EMUL_UNHANDLEABLE;
 }
 
+#ifdef __x86_64__
+static int write_msr(
+    unsigned int reg,
+    uint64_t val,
+    struct x86_emulate_ctxt *ctxt)
+{
+    switch ( reg )
+    {
+    case MSR_GS_BASE:
+        if ( ctxt->addr_size < 64 || !is_canonical_address(val) )
+            break;
+        gs_base = val;
+        return X86EMUL_OKAY;
+
+    case MSR_SHADOW_GS_BASE:
+        if ( ctxt->addr_size < 64 || !is_canonical_address(val) )
+            break;
+        gs_base_shadow = val;
+        return X86EMUL_OKAY;
+    }
+
+    return X86EMUL_UNHANDLEABLE;
+}
+#endif
+
 #define INVPCID_ADDR 0x12345678
 #define INVPCID_PCID 0x123
 
@@ -1338,6 +1403,41 @@ int main(int argc, char **argv)
         printf("%u bytes read - ", bytes_read);
         goto fail;
     }
+    printf("okay\n");
+
+    emulops.write_segment = write_segment;
+    emulops.write_msr     = write_msr;
+
+    printf("%-40s", "Testing swapgs...");
+    instr[0] = 0x0f; instr[1] = 0x01; instr[2] = 0xf8;
+    regs.eip = (unsigned long)&instr[0];
+    gs_base = 0xffffeeeecccc8888UL;
+    gs_base_shadow = 0x0000111122224444UL;
+    rc = x86_emulate(&ctxt, &emulops);
+    if ( (rc != X86EMUL_OKAY) ||
+         (regs.eip != (unsigned long)&instr[3]) ||
+         (gs_base != 0x0000111122224444UL) ||
+         (gs_base_shadow != 0xffffeeeecccc8888UL) )
+        goto fail;
+    printf("okay\n");
+
+    printf("%-40s", "Testing lkgs 2(%rdx)...");
+    instr[0] = 0xf2; instr[1] = 0x0f; instr[2] = 0x00; instr[3] = 0x72; instr[4] = 0x02;
+    regs.eip = (unsigned long)&instr[0];
+    regs.edx = (unsigned long)res;
+    res[0]   = 0x00004444;
+    res[1]   = 0x8888cccc;
+    i = cpu_policy.extd.nscb; cpu_policy.extd.nscb = true; /* for AMD */
+    rc = x86_emulate(&ctxt, &emulops);
+    if ( (rc != X86EMUL_OKAY) ||
+         (regs.eip != (unsigned long)&instr[5]) ||
+         (gs_base != 0x0000111122224444UL) ||
+         gs_base_shadow )
+        goto fail;
+
+    cpu_policy.extd.nscb = i;
+    emulops.write_segment = NULL;
+    emulops.write_msr     = NULL;
 #endif
     printf("okay\n");
 
--- a/tools/tests/x86_emulator/x86-emulate.c
+++ b/tools/tests/x86_emulator/x86-emulate.c
@@ -85,6 +85,7 @@ bool emul_test_init(void)
     cpu_policy.feat.invpcid = true;
     cpu_policy.feat.adx = true;
     cpu_policy.feat.rdpid = true;
+    cpu_policy.feat.lkgs = true;
     cpu_policy.feat.wrmsrns = true;
     cpu_policy.extd.clzero = true;
 
--- a/xen/arch/x86/x86_emulate/decode.c
+++ b/xen/arch/x86/x86_emulate/decode.c
@@ -744,8 +744,12 @@ decode_twobyte(struct x86_emulate_state
         case 0:
             s->desc |= DstMem | SrcImplicit | Mov;
             break;
+        case 6:
+            if ( !(s->modrm_reg & 1) && mode_64bit() )
+            {
         case 2: case 4:
-            s->desc |= SrcMem16;
+                s->desc |= SrcMem16;
+            }
             break;
         }
         break;
--- a/xen/arch/x86/x86_emulate/private.h
+++ b/xen/arch/x86/x86_emulate/private.h
@@ -607,6 +607,7 @@ amd_like(const struct x86_emulate_ctxt *
 #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)
 #define vcpu_has_avx_ifma()    (ctxt->cpuid->feat.avx_ifma)
 #define vcpu_has_avx_vnni_int8() (ctxt->cpuid->feat.avx_vnni_int8)
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -2899,8 +2899,35 @@ x86_emulate(
                 break;
             }
             break;
-        default:
-            generate_exception_if(true, X86_EXC_UD);
+        case 6: /* lkgs */
+            generate_exception_if((modrm_reg & 1) || vex.pfx != vex_f2,
+                                  X86_EXC_UD);
+            generate_exception_if(!mode_64bit() || !mode_ring0(), X86_EXC_UD);
+            vcpu_must_have(lkgs);
+            fail_if(!ops->read_segment || !ops->read_msr ||
+                    !ops->write_segment || !ops->write_msr);
+            if ( (rc = ops->read_msr(MSR_SHADOW_GS_BASE, &msr_val,
+                                     ctxt)) != X86EMUL_OKAY ||
+                 (rc = ops->read_segment(x86_seg_gs, &sreg,
+                                         ctxt)) != X86EMUL_OKAY )
+                goto done;
+            dst.orig_val = sreg.base; /* Preserve full GS Base. */
+            if ( (rc = protmode_load_seg(x86_seg_gs, src.val, false, &sreg,
+                                         ctxt, ops)) != X86EMUL_OKAY ||
+                 /* Write (32-bit) base into SHADOW_GS. */
+                 (rc = ops->write_msr(MSR_SHADOW_GS_BASE, sreg.base,
+                                      ctxt)) != X86EMUL_OKAY )
+                goto done;
+            sreg.base = dst.orig_val; /* Reinstate full GS Base. */
+            if ( (rc = ops->write_segment(x86_seg_gs, &sreg,
+                                          ctxt)) != X86EMUL_OKAY )
+            {
+                /* Best effort unwind (i.e. no real error checking). */
+                if ( ops->write_msr(MSR_SHADOW_GS_BASE, msr_val,
+                                    ctxt) == X86EMUL_EXCEPTION )
+                    x86_emul_reset_event(ctxt);
+                goto done;
+            }
             break;
         }
         break;
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -310,7 +310,10 @@ XEN_CPUFEATURE(ARCH_PERF_MON, 10*32+8) /
 XEN_CPUFEATURE(FZRM,         10*32+10) /*A  Fast Zero-length REP MOVSB */
 XEN_CPUFEATURE(FSRS,         10*32+11) /*A  Fast Short REP STOSB */
 XEN_CPUFEATURE(FSRCS,        10*32+12) /*A  Fast Short REP CMPSB/SCASB */
+XEN_CPUFEATURE(FRED,         10*32+17) /*   Flexible Return and Event Delivery */
+XEN_CPUFEATURE(LKGS,         10*32+18) /*s  Load Kernel GS Base */
 XEN_CPUFEATURE(WRMSRNS,      10*32+19) /*S  WRMSR Non-Serialising */
+XEN_CPUFEATURE(NMI_SRC,      10*32+20) /*   NMI-source reporting */
 XEN_CPUFEATURE(AMX_FP16,     10*32+21) /*   AMX FP16 instruction */
 XEN_CPUFEATURE(AVX_IFMA,     10*32+23) /*A  AVX-IFMA Instructions */
 XEN_CPUFEATURE(LAM,          10*32+26) /*   Linear Address Masking */
--- a/xen/tools/gen-cpuid.py
+++ b/xen/tools/gen-cpuid.py
@@ -274,7 +274,8 @@ def crunch_numbers(state):
         # superpages, PCID and PKU are only available in 4 level paging.
         # 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],
+        LM: [CX16, PCID, LAHF_LM, PAGE1GB, PKU, NO_LMSL, AMX_TILE, CMPCCXADD,
+             LKGS],
 
         # AMD K6-2+ and K6-III processors shipped with 3DNow+, beyond the
         # standard 3DNow in the earlier K6 processors.
@@ -343,6 +344,9 @@ def crunch_numbers(state):
         # computational instructions.  All further AMX features are built on top
         # of AMX-TILE.
         AMX_TILE: [AMX_BF16, AMX_INT8, AMX_FP16, AMX_COMPLEX],
+
+        # FRED builds on the LKGS instruction.
+        LKGS: [FRED],
     }
 
     deep_features = tuple(sorted(deps.keys()))



From xen-devel-bounces@lists.xenproject.org Wed Jun 18 07:05:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 07:05:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018830.1395697 (Exim 4.92)
	(envelope-from )
	id 1uRmrS-00051w-MR; Wed, 18 Jun 2025 07:05:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018830.1395697; Wed, 18 Jun 2025 07: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 1uRmrS-00051p-Il; Wed, 18 Jun 2025 07:05:30 +0000
Received: by outflank-mailman (input) for mailman id 1018830;
 Wed, 18 Jun 2025 07:05: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 1uRmrQ-0004wT-UR
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 07:05:29 +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 9d55b5c2-4c12-11f0-a30a-13f23c93f187;
 Wed, 18 Jun 2025 09:05:28 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3a575a988f9so2651436f8f.0
 for ; Wed, 18 Jun 2025 00:05:28 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-748900b2c0esm10541844b3a.131.2025.06.18.00.05.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Jun 2025 00:05:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9d55b5c2-4c12-11f0-a30a-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750230327; x=1750835127; 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=khWW6r80k8IrkW+b3trheAtatC5BSjt+cDlCwNxHE98=;
        b=Y/Qt3Xe4/PFmn4AOazYt5H51s1C41gYcMP76dbjO6UtpttXf3vxFu21fZJH1LvzvQv
         cAzri/piUl+IUh8gYYWyNf6ZZlCGEmCoMiTdgzyn3eyCPQcdvcVIGe8QDEWamhDhd3eL
         a5avpSgOxhpahCMBv2gb1Izqg/NxZ88uN4MRCDrnuTjZ4int40CSpwZJ0RPPE8apW21/
         fYGua+qaL7XIOV/Bf8m4khCs30JmyqLrZ6YWTaHGHLwfY/Ztu4c4/4fMv7E7GbeZspwH
         tmjKJv6Zw2rKRfNr9JkTSKE9znTAzh2b5H+Wzgx7cHsxcvazK6woCoabyvWa3Hsf79TJ
         Z+tw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750230327; x=1750835127;
        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=khWW6r80k8IrkW+b3trheAtatC5BSjt+cDlCwNxHE98=;
        b=SP5ZQL4Ioh4xi530Eqh1jZ2mEMvYWxkE8J1gsXx7gghXmbfMGd7+gUCrJjiy8Aw6Ih
         Q6j7a+6xrP2a4lOM7vHhyFVKiXc/IDQDhUbAM3EaGpaWFu0+dLXv/HP6NFfGQ9p/rCmj
         eiHW2BmC2xA5KBcD6dVJoS/JJlfr6GF+wrjjQE7TxQwLhmYwQjTaa6AzgXlo657gXPIO
         0/2tUwR/fPzv6EufGaJelNQcLqsxk1R9O8ZJ+IZfEbkEu/2wn1xvC54wnPemWbM3xCA5
         SGzQVGd0t4Zv4XdGMQOVDCufNNNQEzPrjMZI8R1kQFep3aSSMOgLBhTD4s0rn8WobdpD
         72eA==
X-Gm-Message-State: AOJu0YyYSjiBEq6XLc3fNEcp5ydUBme8T1OkKJbGOr2xXig/L8hrERSJ
	rthnJ0ml/BLnK6jvIfwTomBrCgfgKKlToCTsqwOFbVSl4YYxRDxhTiTciC5/yJwYJ+kiVNHQLRM
	8uII=
X-Gm-Gg: ASbGncvQMjunXfuspTuPw05PszQknZXzjgIH/mCXJGAq/AUNLC1+9DoQ0dshDY8M4nA
	uI9nKTg4GsX5n0tYRc2TlXK3fWANyn3Fgzb3OZi7bAjaclnnrkk+lgh+wJ12o40V5PTelu+meHI
	IlbHhN+TAmfVhCWbXyGfirSCnQLcimy7tqEoI91qPF74bF+3qlvR31B5OfvaPlCDsz/t0otpX9i
	HdrGGyiVyJ1NpkCODMSgaVuy1qXSV4vULlLv6TGhMQnmmmhrpDTVJi3Yxdh1NdjJE0+neHUBsjn
	qUoxsMu12oMvYyiXVgJ+TG1gMwADBHWP1/Rp9nmoyrSNsSVH1h85c7/ThZF2FGyCS39Y8LYJEvy
	RHC3E6biwxcmz5TuzaW9Auc8qYJLxr7pAPH2N798SF/3/62A=
X-Google-Smtp-Source: AGHT+IGxqsrzd1IczfaXRztPvdj4/HJORWofMRwaAuEE4Crrr83CXHb9QO7BoWLnDEUmEYRhptsLkA==
X-Received: by 2002:a05:6000:2881:b0:3a4:eef5:ae26 with SMTP id ffacd0b85a97d-3a572e9e42dmr10083130f8f.55.1750230327495;
        Wed, 18 Jun 2025 00:05:27 -0700 (PDT)
Message-ID: <228a62ce-dbf2-435a-9c6e-02c0dd3c9dbd@suse.com>
Date: Wed, 18 Jun 2025 09:05:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v8 2/7] x86emul+VMX: support {RD,WR}MSRLIST
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <585f1b0b-6768-4f9c-8f9f-bcf6e20fbfb7@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: <585f1b0b-6768-4f9c-8f9f-bcf6e20fbfb7@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

These are "compound" instructions to issue a series of RDMSR / WRMSR
respectively. In the emulator we can therefore implement them by using
the existing msr_{read,write}() hooks. The memory accesses utilize that
the HVM ->read() / ->write() hooks are already linear-address
(x86_seg_none) aware (by way of hvmemul_virtual_to_linear() handling
this case).

Preemption is being checked for in WRMSRLIST handling only, as only MSR
writes are expected to possibly take long.

Signed-off-by: Jan Beulich 
---
RFC: In vmx_vmexit_handler() handling is forwarded to the emulator
     blindly. Alternatively we could consult the exit qualification and
     process just a single MSR at a time (without involving the
     emulator), exiting back to the guest after every iteration. (I
     don't think a mix of both models makes a lot of sense.)

The precise behavior of MSR_BARRIER is still not spelled out in ISE 050,
so the (minimal) implementation continues to be a guess for now.

Wouldn't calculate_hvm_max_policy() for MPX better behave the same way
as done here, at least from an abstract perspective (assuming that AMD
won't add such functionality now that Intel have deprecated it)?
---
v8: Re-base.
v6: Use MSR constants in test harness. Re-base.
v5: Add missing vmx_init_vmcs_config() and construct_vmcs() adjustments.
    Avoid unnecessary uses of r(). Re-base.
v3: Add dependency on LM. Limit exposure to HVM. Utilize new info from
    ISE 050. Re-base.
v2: Use X86_EXC_*. Add preemption checking to WRMSRLIST handling. Remove
    the feature from "max" when the VMX counterpart isn't available.

--- a/tools/tests/x86_emulator/predicates.c
+++ b/tools/tests/x86_emulator/predicates.c
@@ -342,6 +342,8 @@ static const struct {
     { { 0x01, 0xc4 }, { 2, 2 }, F, N }, /* vmxoff */
     { { 0x01, 0xc5 }, { 2, 2 }, F, N }, /* pconfig */
     { { 0x01, 0xc6 }, { 2, 2 }, F, N }, /* wrmsrns */
+    { { 0x01, 0xc6 }, { 0, 2 }, F, W, pfx_f2 }, /* rdmsrlist */
+    { { 0x01, 0xc6 }, { 0, 2 }, F, R, pfx_f3 }, /* wrmsrlist */
     { { 0x01, 0xc8 }, { 2, 2 }, F, N }, /* monitor */
     { { 0x01, 0xc9 }, { 2, 2 }, F, N }, /* mwait */
     { { 0x01, 0xca }, { 2, 2 }, F, N }, /* clac */
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -625,7 +625,7 @@ static int write(
     if ( verbose )
         printf("** %s(%u, %p,, %u,)\n", __func__, seg, (void *)offset, bytes);
 
-    if ( !is_x86_user_segment(seg) )
+    if ( !is_x86_user_segment(seg) && seg != x86_seg_none )
         return X86EMUL_UNHANDLEABLE;
     memcpy((void *)offset, p_data, bytes);
     return X86EMUL_OKAY;
@@ -717,6 +717,10 @@ static int read_msr(
 {
     switch ( reg )
     {
+    case MSR_BARRIER:
+        *val = 0;
+        return X86EMUL_OKAY;
+
     case MSR_EFER:
         *val = ctxt->addr_size > 32 ? EFER_LME | EFER_LMA : 0;
         return X86EMUL_OKAY;
@@ -1434,9 +1438,53 @@ int main(int argc, char **argv)
          (gs_base != 0x0000111122224444UL) ||
          gs_base_shadow )
         goto fail;
+    printf("okay\n");
 
     cpu_policy.extd.nscb = i;
     emulops.write_segment = NULL;
+
+    printf("%-40s", "Testing rdmsrlist...");
+    instr[0] = 0xf2; instr[1] = 0x0f; instr[2] = 0x01; instr[3] = 0xc6;
+    regs.rip = (unsigned long)&instr[0];
+    regs.rsi = (unsigned long)(res + 0x80);
+    regs.rdi = (unsigned long)(res + 0x80 + 0x40 * 2);
+    regs.rcx = 0x0002000100008000UL;
+    gs_base_shadow = 0x0000222244446666UL;
+    memset(res + 0x80, ~0, 0x40 * 8 * 2);
+    res[0x80 + 0x0f * 2] = MSR_GS_BASE;
+    res[0x80 + 0x0f * 2 + 1] = 0;
+    res[0x80 + 0x20 * 2] = MSR_SHADOW_GS_BASE;
+    res[0x80 + 0x20 * 2 + 1] = 0;
+    res[0x80 + 0x31 * 2] = MSR_BARRIER;
+    res[0x80 + 0x31 * 2 + 1] = 0;
+    rc = x86_emulate(&ctxt, &emulops);
+    if ( (rc != X86EMUL_OKAY) ||
+         (regs.rip != (unsigned long)&instr[4]) ||
+         regs.rcx ||
+         (res[0x80 + (0x40 + 0x0f) * 2] != (unsigned int)gs_base) ||
+         (res[0x80 + (0x40 + 0x0f) * 2 + 1] != (gs_base >> (8 * sizeof(int)))) ||
+         (res[0x80 + (0x40 + 0x20) * 2] != (unsigned int)gs_base_shadow) ||
+         (res[0x80 + (0x40 + 0x20) * 2 + 1] != (gs_base_shadow >> (8 * sizeof(int)))) ||
+         res[0x80 + (0x40 + 0x31) * 2] || res[0x80 + (0x40 + 0x31) * 2 + 1] )
+        goto fail;
+    printf("okay\n");
+
+    printf("%-40s", "Testing wrmsrlist...");
+    instr[0] = 0xf3; instr[1] = 0x0f; instr[2] = 0x01; instr[3] = 0xc6;
+    regs.eip = (unsigned long)&instr[0];
+    regs.rsi -= 0x11 * 8;
+    regs.rdi -= 0x11 * 8;
+    regs.rcx = 0x0002000100000000UL;
+    res[0x80 + 0x0f * 2] = MSR_SHADOW_GS_BASE;
+    res[0x80 + 0x20 * 2] = MSR_GS_BASE;
+    rc = x86_emulate(&ctxt, &emulops);
+    if ( (rc != X86EMUL_OKAY) ||
+         (regs.rip != (unsigned long)&instr[4]) ||
+         regs.rcx ||
+         (gs_base != 0x0000222244446666UL) ||
+         (gs_base_shadow != 0x0000111122224444UL) )
+        goto fail;
+
     emulops.write_msr     = NULL;
 #endif
     printf("okay\n");
--- a/tools/tests/x86_emulator/x86-emulate.c
+++ b/tools/tests/x86_emulator/x86-emulate.c
@@ -87,6 +87,7 @@ bool emul_test_init(void)
     cpu_policy.feat.rdpid = true;
     cpu_policy.feat.lkgs = true;
     cpu_policy.feat.wrmsrns = true;
+    cpu_policy.feat.msrlist = true;
     cpu_policy.extd.clzero = true;
 
     if ( cpu_has_xsave )
--- a/xen/arch/x86/cpu-policy.c
+++ b/xen/arch/x86/cpu-policy.c
@@ -778,6 +778,9 @@ static void __init calculate_hvm_max_pol
             __clear_bit(X86_FEATURE_XSAVES, fs);
     }
 
+    if ( !cpu_has_vmx_msrlist )
+        __clear_bit(X86_FEATURE_MSRLIST, fs);
+
     /*
      * Xen doesn't use PKS, so the guest support for it has opted to not use
      * the VMCS load/save controls for efficiency reasons.  This depends on
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -354,8 +354,9 @@ static int vmx_init_vmcs_config(bool bsp
 
     if ( caps.cpu_based_exec_control & CPU_BASED_ACTIVATE_TERTIARY_CONTROLS )
     {
-        uint64_t opt = (TERTIARY_EXEC_VIRT_SPEC_CTRL |
-                        TERTIARY_EXEC_EPT_PAGING_WRITE);
+        uint64_t opt = TERTIARY_EXEC_EPT_PAGING_WRITE |
+                       TERTIARY_EXEC_ENABLE_MSRLIST |
+                       TERTIARY_EXEC_VIRT_SPEC_CTRL;
 
         caps.tertiary_exec_control = adjust_vmx_controls2(
             "Tertiary Exec Control", 0, opt,
@@ -1103,7 +1104,8 @@ static int construct_vmcs(struct vcpu *v
         v->arch.hvm.vmx.exec_control |= CPU_BASED_RDTSC_EXITING;
 
     v->arch.hvm.vmx.secondary_exec_control = vmx_caps.secondary_exec_control;
-    v->arch.hvm.vmx.tertiary_exec_control  = vmx_caps.tertiary_exec_control;
+    v->arch.hvm.vmx.tertiary_exec_control  = vmx_caps.tertiary_exec_control &
+                                             ~TERTIARY_EXEC_ENABLE_MSRLIST;
 
     /*
      * Disable features which we don't want active by default:
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -884,6 +884,20 @@ static void cf_check vmx_cpuid_policy_ch
     else
         vmx_set_msr_intercept(v, MSR_PKRS, VMX_MSR_RW);
 
+    if ( cp->feat.msrlist )
+    {
+        vmx_clear_msr_intercept(v, MSR_BARRIER, VMX_MSR_RW);
+        v->arch.hvm.vmx.tertiary_exec_control |= TERTIARY_EXEC_ENABLE_MSRLIST;
+        vmx_update_tertiary_exec_control(v);
+    }
+    else if ( v->arch.hvm.vmx.tertiary_exec_control &
+              TERTIARY_EXEC_ENABLE_MSRLIST )
+    {
+        vmx_set_msr_intercept(v, MSR_BARRIER, VMX_MSR_RW);
+        v->arch.hvm.vmx.tertiary_exec_control &= ~TERTIARY_EXEC_ENABLE_MSRLIST;
+        vmx_update_tertiary_exec_control(v);
+    }
+
  out:
     vmx_vmcs_exit(v);
 
@@ -3824,6 +3838,22 @@ gp_fault:
     return X86EMUL_EXCEPTION;
 }
 
+static bool cf_check is_msrlist(
+    const struct x86_emulate_state *state, const struct x86_emulate_ctxt *ctxt)
+{
+
+    if ( ctxt->opcode == X86EMUL_OPC(0x0f, 0x01) )
+    {
+        unsigned int rm, reg;
+        int mode = x86_insn_modrm(state, &rm, ®);
+
+        /* This also includes WRMSRNS; should be okay. */
+        return mode == 3 && rm == 6 && !reg;
+    }
+
+    return false;
+}
+
 static void vmx_do_extint(struct cpu_user_regs *regs)
 {
     unsigned long vector;
@@ -4631,6 +4661,17 @@ void asmlinkage vmx_vmexit_handler(struc
         }
         break;
 
+    case EXIT_REASON_RDMSRLIST:
+    case EXIT_REASON_WRMSRLIST:
+        if ( vmx_guest_x86_mode(v) != 8 || !currd->arch.cpuid->feat.msrlist )
+        {
+            ASSERT_UNREACHABLE();
+            hvm_inject_hw_exception(X86_EXC_UD, X86_EVENT_NO_EC);
+        }
+        else if ( !hvm_emulate_one_insn(is_msrlist, "MSR list") )
+            hvm_inject_hw_exception(X86_EXC_GP, 0);
+        break;
+
     case EXIT_REASON_VMXOFF:
     case EXIT_REASON_VMXON:
     case EXIT_REASON_VMCLEAR:
--- a/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
+++ b/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
@@ -262,8 +262,13 @@ void vmx_vmcs_reload(struct vcpu *v);
 #define TERTIARY_EXEC_EPT_PAGING_WRITE          BIT(2, UL)
 #define TERTIARY_EXEC_GUEST_PAGING_VERIFY       BIT(3, UL)
 #define TERTIARY_EXEC_IPI_VIRT                  BIT(4, UL)
+#define TERTIARY_EXEC_ENABLE_MSRLIST            BIT(6, UL)
 #define TERTIARY_EXEC_VIRT_SPEC_CTRL            BIT(7, UL)
 
+#define cpu_has_vmx_msrlist \
+    (IS_ENABLED(CONFIG_INTEL_VMX) && \
+     (vmx_caps.tertiary_exec_control & TERTIARY_EXEC_ENABLE_MSRLIST))
+
 #define cpu_has_vmx_virt_spec_ctrl \
      (vmx_caps.tertiary_exec_control & TERTIARY_EXEC_VIRT_SPEC_CTRL)
 
--- a/xen/arch/x86/include/asm/hvm/vmx/vmx.h
+++ b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
@@ -201,6 +201,8 @@ static inline void pi_clear_sn(struct pi
 #define EXIT_REASON_XRSTORS             64
 #define EXIT_REASON_BUS_LOCK            74
 #define EXIT_REASON_NOTIFY              75
+#define EXIT_REASON_RDMSRLIST           78
+#define EXIT_REASON_WRMSRLIST           79
 /* Remember to also update VMX_PERF_EXIT_REASON_SIZE! */
 
 /*
--- a/xen/arch/x86/include/asm/msr-index.h
+++ b/xen/arch/x86/include/asm/msr-index.h
@@ -24,6 +24,8 @@
 #define  APIC_BASE_ENABLE                   (_AC(1, ULL) << 11)
 #define  APIC_BASE_ADDR_MASK                _AC(0x000ffffffffff000, ULL)
 
+#define MSR_BARRIER                         0x0000002f
+
 #define MSR_TEST_CTRL                       0x00000033
 #define  TEST_CTRL_SPLITLOCK_DETECT         (_AC(1, ULL) << 29)
 #define  TEST_CTRL_SPLITLOCK_DISABLE        (_AC(1, ULL) << 31)
--- a/xen/arch/x86/include/asm/perfc_defn.h
+++ b/xen/arch/x86/include/asm/perfc_defn.h
@@ -6,7 +6,7 @@ PERFCOUNTER_ARRAY(exceptions,
 
 #ifdef CONFIG_HVM
 
-#define VMX_PERF_EXIT_REASON_SIZE 76
+#define VMX_PERF_EXIT_REASON_SIZE 80
 #define VMEXIT_NPF_PERFC 143
 #define SVM_PERF_EXIT_REASON_SIZE (VMEXIT_NPF_PERFC + 1)
 PERFCOUNTER_ARRAY(vmexits,              "vmexits",
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -147,6 +147,12 @@ int guest_rdmsr(struct vcpu *v, uint32_t
     case MSR_AMD_PPIN:
         goto gp_fault;
 
+    case MSR_BARRIER:
+        if ( !cp->feat.msrlist )
+            goto gp_fault;
+        *val = 0;
+        break;
+
     case MSR_IA32_FEATURE_CONTROL:
         /*
          * Architecturally, availability of this MSR is enumerated by the
@@ -428,6 +434,7 @@ int guest_wrmsr(struct vcpu *v, uint32_t
         uint64_t rsvd;
 
         /* Read-only */
+    case MSR_BARRIER:
     case MSR_IA32_PLATFORM_ID:
     case MSR_CORE_CAPABILITIES:
     case MSR_INTEL_CORE_THREAD_COUNT:
--- a/xen/arch/x86/x86_emulate/0f01.c
+++ b/xen/arch/x86/x86_emulate/0f01.c
@@ -11,6 +11,7 @@
 #include "private.h"
 
 #ifdef __XEN__
+#include 
 #include 
 #endif
 
@@ -28,6 +29,7 @@ int x86emul_0f01(struct x86_emulate_stat
     switch ( s->modrm )
     {
         unsigned long base, limit, cr0, cr0w, cr4;
+        unsigned int n;
         struct segment_register sreg;
         uint64_t msr_val;
 
@@ -42,6 +44,64 @@ int x86emul_0f01(struct x86_emulate_stat
                                 ((uint64_t)regs->r(dx) << 32) | regs->eax,
                                 ctxt);
             goto done;
+
+        case vex_f3: /* wrmsrlist */
+            vcpu_must_have(msrlist);
+            generate_exception_if(!mode_64bit(), X86_EXC_UD);
+            generate_exception_if(!mode_ring0() || (regs->esi & 7) ||
+                                  (regs->edi & 7),
+                                  X86_EXC_GP, 0);
+            fail_if(!ops->write_msr);
+            while ( regs->r(cx) )
+            {
+                n = __builtin_ffsl(regs->r(cx)) - 1;
+                if ( (rc = ops->read(x86_seg_none, regs->r(si) + n * 8,
+                                     &msr_val, 8, ctxt)) != X86EMUL_OKAY )
+                    break;
+                generate_exception_if(msr_val != (uint32_t)msr_val,
+                                      X86_EXC_GP, 0);
+                base = msr_val;
+                if ( (rc = ops->read(x86_seg_none, regs->r(di) + n * 8,
+                                     &msr_val, 8, ctxt)) != X86EMUL_OKAY ||
+                     (rc = ops->write_msr(base, msr_val, ctxt)) != X86EMUL_OKAY )
+                    break;
+                regs->r(cx) &= ~(1UL << n);
+
+#ifdef __XEN__
+                if ( regs->r(cx) && local_events_need_delivery() )
+                {
+                    rc = X86EMUL_RETRY;
+                    break;
+                }
+#endif
+            }
+            goto done;
+
+        case vex_f2: /* rdmsrlist */
+            vcpu_must_have(msrlist);
+            generate_exception_if(!mode_64bit(), X86_EXC_UD);
+            generate_exception_if(!mode_ring0() || (regs->esi & 7) ||
+                                  (regs->edi & 7),
+                                  X86_EXC_GP, 0);
+            fail_if(!ops->read_msr || !ops->write);
+            while ( regs->r(cx) )
+            {
+                n = __builtin_ffsl(regs->r(cx)) - 1;
+                if ( (rc = ops->read(x86_seg_none, regs->r(si) + n * 8,
+                                     &msr_val, 8, ctxt)) != X86EMUL_OKAY )
+                    break;
+                generate_exception_if(msr_val != (uint32_t)msr_val,
+                                      X86_EXC_GP, 0);
+                if ( (rc = ops->read_msr(msr_val, &msr_val,
+                                         ctxt)) != X86EMUL_OKAY ||
+                     (rc = ops->write(x86_seg_none, regs->r(di) + n * 8,
+                                      &msr_val, 8, ctxt)) != X86EMUL_OKAY )
+                    break;
+                regs->r(cx) &= ~(1UL << n);
+            }
+            if ( rc != X86EMUL_OKAY )
+                ctxt->regs->r(cx) = regs->r(cx);
+            goto done;
         }
         generate_exception(X86_EXC_UD);
 
--- a/xen/arch/x86/x86_emulate/private.h
+++ b/xen/arch/x86/x86_emulate/private.h
@@ -610,6 +610,7 @@ amd_like(const struct x86_emulate_ctxt *
 #define vcpu_has_lkgs()        (ctxt->cpuid->feat.lkgs)
 #define vcpu_has_wrmsrns()     (ctxt->cpuid->feat.wrmsrns)
 #define vcpu_has_avx_ifma()    (ctxt->cpuid->feat.avx_ifma)
+#define vcpu_has_msrlist()     (ctxt->cpuid->feat.msrlist)
 #define vcpu_has_avx_vnni_int8() (ctxt->cpuid->feat.avx_vnni_int8)
 #define vcpu_has_avx_ne_convert() (ctxt->cpuid->feat.avx_ne_convert)
 #define vcpu_has_avx_vnni_int16() (ctxt->cpuid->feat.avx_vnni_int16)
--- a/xen/arch/x86/x86_emulate/util.c
+++ b/xen/arch/x86/x86_emulate/util.c
@@ -100,6 +100,9 @@ bool cf_check x86_insn_is_mem_access(con
         break;
 
     case X86EMUL_OPC(0x0f, 0x01):
+        /* {RD,WR}MSRLIST */
+        if ( mode_64bit() && s->modrm == 0xc6 )
+            return s->vex.pfx >= vex_f3;
         /* Cover CLZERO. */
         return (s->modrm_rm & 7) == 4 && (s->modrm_reg & 7) == 7;
     }
@@ -160,7 +163,11 @@ bool cf_check x86_insn_is_mem_write(cons
         case 0xff: /* Grp5 */
             break;
 
-        case X86EMUL_OPC(0x0f, 0x01): /* CLZERO is the odd one. */
+        case X86EMUL_OPC(0x0f, 0x01):
+            /* RDMSRLIST */
+            if ( mode_64bit() && s->modrm == 0xc6 )
+                return s->vex.pfx == vex_f2;
+            /* CLZERO is another odd one. */
             return (s->modrm_rm & 7) == 4 && (s->modrm_reg & 7) == 7;
 
         default:
--- a/xen/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],
+             LKGS, MSRLIST],
 
         # AMD K6-2+ and K6-III processors shipped with 3DNow+, beyond the
         # standard 3DNow in the earlier K6 processors.



From xen-devel-bounces@lists.xenproject.org Wed Jun 18 07:05:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 07:05:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018837.1395707 (Exim 4.92)
	(envelope-from )
	id 1uRmrs-0005UQ-Tb; Wed, 18 Jun 2025 07:05:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018837.1395707; Wed, 18 Jun 2025 07:05: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 1uRmrs-0005UJ-QR; Wed, 18 Jun 2025 07:05:56 +0000
Received: by outflank-mailman (input) for mailman id 1018837;
 Wed, 18 Jun 2025 07: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 1uRmrq-0004U2-Hc
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 07:05:54 +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 abc52071-4c12-11f0-b894-0df219b8e170;
 Wed, 18 Jun 2025 09:05:52 +0200 (CEST)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3a53359dea5so4551691f8f.0
 for ; Wed, 18 Jun 2025 00:05:52 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-31429aae8eesm2736086a91.40.2025.06.18.00.05.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Jun 2025 00:05:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: abc52071-4c12-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750230352; x=1750835152; 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=ahgmDD+UAYdCA6LK0dCpFHM/dWs4Qa1gLE1F4JjLxuE=;
        b=a0dhouonyI7wSKGy7F+FDE51AumGj6ZZHyHkJKCrej3AXKLlgQvN/vMpQLiBERLKoQ
         w/nXHvvhAvXEyYwKa4HD+boSO3XRveBK9RJtowOA8xUnl7gRjpZ1XQj3Hu5g7bfTOtt3
         VbbrgFY95EQemKB8zObCxL7pLAVx0Q05d7kyWyAjaCZNiVnDtIkLsQ+FPOebQOs1m4O6
         wV3BIuS+CuqpND0/x273dytPvvLlAQFGaYdr6Y0H2b7uQIFeUPD8pj3TkdWBcr4APUzQ
         c9SRQTpaKaRZ4jUj+teR1rpgWsrF10V/1dWIfApJydtneMGzWuiU15HnsJowOBiEkser
         T0hQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750230352; x=1750835152;
        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=ahgmDD+UAYdCA6LK0dCpFHM/dWs4Qa1gLE1F4JjLxuE=;
        b=BWvOKcSaV88AsfywUKvRVreJCEDaxBwr51oG+WeAslCmBe6d8IIRc+MLKVjRFYp8iC
         cNrt7Vq9sygjj60sUl0Z93QQkZu3DqU+1XmZpexOvTliJFa4sNdtfLU6K/SFvE+/kf1N
         mQWeRT8eEtMvjRjdzxNZU/YI1+Al/gPSm4cJPMgfwSGpBdcDEHy12M/J7voSpHC+18NR
         Cg9AcPA4b1nXYQzzNLqHyrwEt97Xn510yTm97hmMpuOt/+eo9uP+gj6pvCQoNfHaREkU
         algbivZ7AfAJpn8XADfuTsn7fuEDSbFlUfii42H4zwK6HFSIoCprSqv3+3um+8nRJVnZ
         AQ3w==
X-Gm-Message-State: AOJu0YzlzEiVB/Yz5VK2YXV3h+38Ur3sU2AXGtCdqxiqU0sUhp1/73fk
	N0h3iUG96Kz0HP2C1RgStE4yEl9xFMrA61A7kqxxtn+/eBsxcWHqlH3pmGlVDxHygSy7deseyhK
	FAfE=
X-Gm-Gg: ASbGncvZyHgvlIlfbcM+S3g/LiDKvPyqSk14+acOHg6DZA2l9ZlTwbCpYURwFcjCpJX
	MsLEmg2m0JYqMN3vAga+9quscZznlCX8ZhaTALUoJbngJkwAK3TCMDBNmPOzRRVBV1i6ySc1JC8
	HhcqXShv0h4sSeCHIzdwJ4ovp2C47XiiDnL5aCZ112oEwMshiaZLUexFLQb2kTD2sOzi2PdtoAE
	rUHg0zY5l7Pf6tB/ygLBmQAOkxaQ2w440N9hSZLKyPRAGLG72OeaK8sPar67qll5RKwgaX7rSlx
	7hPl0n9QdJ0IopF6HzJKjHvibVe+GJXRSLb9xAxNWRwEdYFVzG8o3r12EywRgn/ZCus0HlI/W7U
	D6SDwg+esw1gC4QE1VSqnqX2NSyTc63ttn11er/UkUTGwoGo=
X-Google-Smtp-Source: AGHT+IF2KH8iYqLtvWdlCIBMhALI5ywkB7SAScVAcGgMtKSrka/uiLIBi9UJ3BGFviNLMBwFwvLemA==
X-Received: by 2002:a5d:64ee:0:b0:3a4:f744:e00c with SMTP id ffacd0b85a97d-3a5723a2dafmr11947449f8f.29.1750230351745;
        Wed, 18 Jun 2025 00:05:51 -0700 (PDT)
Message-ID: <25af4f84-8e24-4738-bf4b-79e8ead3e970@suse.com>
Date: Wed, 18 Jun 2025 09:05:44 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v8 3/7] x86emul: support USER_MSR instructions
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <585f1b0b-6768-4f9c-8f9f-bcf6e20fbfb7@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: <585f1b0b-6768-4f9c-8f9f-bcf6e20fbfb7@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?
---
v8: Switch to using fallthrough pseudo-keyword. Re-base.
v7.1: Add MSR-specific feature checks for UWRMSR (incl the UTMR feature
      bit and its overriding in the test harness).
v7: Add missing vcpu_must_have() and override in emul_test_init(). Use
    MSR constants even more.
v6: Add MSR_UINTR_TIMER to header. Use MSR constants in test harness.
    Re-base.
v5: Correct ModR/M.reg check for VEX-encoded forms. Cosmetic test
    harness adjustment. Re-base.
v4: MSR index input regs are 64-bit (albeit only the APX spec has it
    this way for now).
v3: New.

--- a/tools/tests/x86_emulator/predicates.c
+++ b/tools/tests/x86_emulator/predicates.c
@@ -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
@@ -195,6 +199,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
@@ -202,6 +202,7 @@ enum vex_opcx {
     vex_0f3a,
     evex_map5 = 5,
     evex_map6,
+    vex_map7,
 };
 
 enum vex_pfx {
@@ -258,6 +259,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.
@@ -614,6 +616,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
@@ -7075,10 +7075,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;
+        fallthrough;
+    case X86EMUL_OPC_VEX_F3(7, 0xf8): /* uwrmsr r64,imm32 */
+    case X86EMUL_OPC_VEX_F2(7, 0xf8): /* urdmsr imm32,r64 */
+        generate_exception_if(!mode_64bit() || ea.type != OP_REG, X86_EXC_UD);
+        generate_exception_if(vex.l || vex.w, X86_EXC_UD);
+        generate_exception_if(vex.opcx && ((modrm_reg & 7) || vex.reg != 0xf),
+                              X86_EXC_UD);
+        vcpu_must_have(user_msr);
+        fail_if(!ops->read_msr);
+        if ( ops->read_msr(MSR_USER_MSR_CTL, &msr_val, ctxt) != X86EMUL_OKAY )
+        {
+            x86_emul_reset_event(ctxt);
+            msr_val = 0;
+        }
+        generate_exception_if(!(msr_val & USER_MSR_ENABLE), X86_EXC_UD);
+        generate_exception_if(imm1 & ~0x3fff, X86_EXC_GP, 0);
+
+        /* Check the corresponding bitmap. */
+        ea.mem.off = msr_val & ~0xfff;
+        if ( vex.pfx != vex_f2 )
+            ea.mem.off += 0x800;
+        ea.mem.off += imm1 >> 3;
+        if ( (rc = ops->read(x86_seg_sys, ea.mem.off, &b, 1,
+                             ctxt)) != X86EMUL_OKAY )
+            goto done;
+        generate_exception_if(!(b & (1 << (imm1 & 7))), X86_EXC_GP, 0);
+
+        /* Carry out the actual MSR access. */
+        if ( vex.pfx == vex_f2 )
+        {
+            /* urdmsr */
+            if ( (rc = ops->read_msr(imm1, &msr_val, ctxt)) != X86EMUL_OKAY )
+                goto done;
+            dst.val = msr_val;
+            ASSERT(dst.type == OP_REG);
+            dst.bytes = 8;
+        }
+        else
+        {
+            /* uwrmsr */
+            switch ( imm1 )
+            {
+            case 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
@@ -357,7 +357,9 @@ XEN_CPUFEATURE(AVX_VNNI_INT8,      15*32
 XEN_CPUFEATURE(AVX_NE_CONVERT,     15*32+ 5) /*A  AVX-NE-CONVERT Instructions */
 XEN_CPUFEATURE(AMX_COMPLEX,        15*32+ 8) /*   AMX Complex Instructions */
 XEN_CPUFEATURE(AVX_VNNI_INT16,     15*32+10) /*A  AVX-VNNI-INT16 Instructions */
+XEN_CPUFEATURE(UTMR,               15*32+13) /*   User Timer */
 XEN_CPUFEATURE(PREFETCHI,          15*32+14) /*A  PREFETCHIT{0,1} Instructions */
+XEN_CPUFEATURE(USER_MSR,           15*32+15) /*   U{RD,WR}MSR Instructions */
 XEN_CPUFEATURE(UIRET_UIF,          15*32+17) /*   UIRET updates UIF */
 XEN_CPUFEATURE(CET_SSS,            15*32+18) /*   CET Supervisor Shadow Stacks safe to use */
 XEN_CPUFEATURE(SLSM,               15*32+24) /*   Static Lockstep Mode */
--- a/xen/tools/gen-cpuid.py
+++ b/xen/tools/gen-cpuid.py
@@ -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 Jun 18 07:06:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 07:06:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018847.1395717 (Exim 4.92)
	(envelope-from )
	id 1uRmsJ-00062x-8V; Wed, 18 Jun 2025 07:06:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018847.1395717; Wed, 18 Jun 2025 07:06: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 1uRmsJ-00062q-5r; Wed, 18 Jun 2025 07:06:23 +0000
Received: by outflank-mailman (input) for mailman id 1018847;
 Wed, 18 Jun 2025 07:06: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 1uRmsH-0004wT-QT
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 07:06:21 +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 bcfc6e68-4c12-11f0-a30a-13f23c93f187;
 Wed, 18 Jun 2025 09:06:21 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a510432236so4844993f8f.0
 for ; Wed, 18 Jun 2025 00:06:21 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2369d2e3507sm14537535ad.130.2025.06.18.00.06.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Jun 2025 00:06:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bcfc6e68-4c12-11f0-a30a-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750230381; x=1750835181; 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=FstPDyVgVxeevXHNpusP3FrMG+9yEgYGd1uLLSNLSeg=;
        b=O7Y50X0ZNRgwyDjTzZnUvmSJfVK41YAHBtG93TvZFiZu5zN0mt3+a6PFfhJ1DW2cRt
         p+v0SzS/FYwfyQNI440C+oCyXHfOXy5VpCbSQs2McikjThxtiJFtpcot174NU7kT36wn
         Vs6viGPy8h40lP8h4YfbIMZTmThT2FK+gUYCyn5c9krGt+TMkvh10gCCEjOEwjwbrtmr
         LUdbLQWPT7WbSVzWU7OirUo+7V4yLc8vV+ua8oHaWefOT3XPY9MUuZAttftQIosaPXNy
         6MCd7Dwp6G3egE9pFeZCdDAtgmFKipdfFp2AsO7DUEc85ZfBkeNEAV7S3L3jOEcb+IUa
         zjhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750230381; x=1750835181;
        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=FstPDyVgVxeevXHNpusP3FrMG+9yEgYGd1uLLSNLSeg=;
        b=Ni4RaMfsGJE6lgIJrSbM47nL8W/2Sdaw7prm7/+CtTtjyTdC92Kiu5wOKaBZjM8XA2
         Phd09rNSQ5W2d+TKLNbhjauWd83nsi8QGUA4bHxUE5neLzy90ycvw8Qj00ygvh1plsPA
         o4AXoy1u8+fWXh8lLRbpW8Ev6gXBGYoqQiLM2Ced0h6yncA35Gfjxodk1Gwhmd4myNRR
         1IP3RsneeoY2YnPxSAd+ry/gf05fdwEhQ9T/WL2BSrtulRkfkzbuDOnaEkMH0CgS3IMT
         XuemRwTbjmha1HhTfUumiauLoEXo7F89XC3u1opWtVf4D2fLmBmcMq5M4i+KfzYYsrMu
         Hapw==
X-Gm-Message-State: AOJu0YyeZFIfIzQM+R0mlFUiED6UBnMbm8plQmhmCcObal9NqLU4ovGC
	WCyX/saMnI9j5NPWDLWlkSO82SrIGjKuHIkVz3v/QbOPmLjRlQ0JA5aUQkMLVWqh4QjpvZsW4nj
	/2L0=
X-Gm-Gg: ASbGncvx+ExzuZ5siitnhOOflFvH3WQjaQfkmA55yQ/1Ay7J3jJIaf3X0WKdSsebZyA
	4mv7VDzqkp9RLGK7JhoR2PkrXsr8RxYRIlSPFnVyxYkPYEifIQZ6M0hu/m+YqGJ+moaF9DUCx2G
	lw4CTU4TTLtrMb5G35Q4Yk85Msuhm0mzpmHzHzhfLknffIVTTX2KzOeigb3Jsyc98bbdvmzJIrg
	iUnBObKoFEHB/NOrlyawfjqpjlTTzm/kB4t9T/KQtQchtlag5VaaOkrYJGW6Tw5/nARscMZKbKI
	1vvoAMdVd1RB+r5jx12cix+l/OTUs9SqfJ+nCmi0g8ytUOINwi5b8/T3UyyrxRfCqdqk2YCG9X+
	lyilHppL8tDOmXhnSoCgFxKw3jbhTM7aOUiT+gG4sf5Of9AikNx1QccMzTQ==
X-Google-Smtp-Source: AGHT+IG8mUrEBNWCYdcA7I1LZpx2oIp751GREWT3zQa32v728K6BJqGmbGUPiA34WPbdkmxvXEd7lA==
X-Received: by 2002:a05:6000:290b:b0:3a4:dcb0:a4c with SMTP id ffacd0b85a97d-3a57238b8e6mr13005014f8f.12.1750230380686;
        Wed, 18 Jun 2025 00:06:20 -0700 (PDT)
Message-ID: <5b0be3b6-53fb-42ab-b2d9-141f7fae1496@suse.com>
Date: Wed, 18 Jun 2025 09:06:13 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v8 4/7] x86/cpu-policy: re-arrange no-VMX logic
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <585f1b0b-6768-4f9c-8f9f-bcf6e20fbfb7@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: <585f1b0b-6768-4f9c-8f9f-bcf6e20fbfb7@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Move the PKS check into an "else" for the corresponding "if()", such
that further adjustments (like for USER_MSR) can easily be put there as
well.

Signed-off-by: Jan Beulich 
---
v5: Re-base.
v4: New.

--- a/xen/arch/x86/cpu-policy.c
+++ b/xen/arch/x86/cpu-policy.c
@@ -777,19 +777,20 @@ static void __init calculate_hvm_max_pol
         if ( !cpu_has_vmx_xsaves )
             __clear_bit(X86_FEATURE_XSAVES, fs);
     }
+    else
+    {
+        /*
+         * Xen doesn't use PKS, so the guest support for it has opted to not use
+         * the VMCS load/save controls for efficiency reasons.  This depends on
+         * the exact vmentry/exit behaviour, so don't expose PKS in other
+         * situations until someone has cross-checked the behaviour for safety.
+         */
+        __clear_bit(X86_FEATURE_PKS, fs);
+    }
 
     if ( !cpu_has_vmx_msrlist )
         __clear_bit(X86_FEATURE_MSRLIST, fs);
 
-    /*
-     * Xen doesn't use PKS, so the guest support for it has opted to not use
-     * the VMCS load/save controls for efficiency reasons.  This depends on
-     * the exact vmentry/exit behaviour, so don't expose PKS in other
-     * situations until someone has cross-checked the behaviour for safety.
-     */
-    if ( !cpu_has_vmx )
-        __clear_bit(X86_FEATURE_PKS, fs);
-
     /* 
      * Make adjustments to possible (nested) virtualization features exposed
      * to the guest



From xen-devel-bounces@lists.xenproject.org Wed Jun 18 07:06:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 07:06:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018852.1395728 (Exim 4.92)
	(envelope-from )
	id 1uRmsV-0006P6-IS; Wed, 18 Jun 2025 07:06:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018852.1395728; Wed, 18 Jun 2025 07:06:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRmsV-0006Ox-Cx; Wed, 18 Jun 2025 07:06:35 +0000
Received: by outflank-mailman (input) for mailman id 1018852;
 Wed, 18 Jun 2025 07:06: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 1uRmsT-0004wT-OW
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 07:06:33 +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 c32f36da-4c12-11f0-a30a-13f23c93f187;
 Wed, 18 Jun 2025 09:06:32 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by SN7PR12MB6839.namprd12.prod.outlook.com (2603:10b6:806:265::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.20; Wed, 18 Jun
 2025 07:06:27 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8835.027; Wed, 18 Jun 2025
 07:06: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: c32f36da-4c12-11f0-a30a-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=GYirddU3zYB2S8rVr0eEm1t8NR/DrQjiRzWx9xFhnqW7AkyG7D4Jeyfeo7TQV1jOemLV7CTYkQcUpLfvVTfdeMzQhvIyHtq3rthgo2mtYzRxPA35z4vvvhCREcKsEGa68h+Z0Pq9l4hXhIlxhJjd7oZ9l0R6UJCB6W+aoWSJbiRO1lLsKQ5BAe9VA18a9COVrwblIos8daSJLre+gotkHva6bJrgc0bK8HaVXzNnNFyYyA5JzdzT2y5n+Tos+k2++Fa0ZiMlIFqsIVwiEES7m/6zrIqnwMQigPordxC9dC9Q+peViwpVPiHEfGaSCnzsRAbKwfu4oV+l1agptlbBFQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Ml9P/qbE0KF6UxVD6+jSSpsdZqlyn0DrI+ve2Nni0zI=;
 b=j4Twjztr2dd9BNDe/zXvFkqkLHLDdTzNwsNtodyEUlDJGGfOi3ctFmgtMSGdKrxtr0b7H/xDnmm90Ab9kYQIv/i6inWeeoyvNTK15lB45c9sLzp8L20zmebdJHUD7l7/AjMEgjuCHr8L5MeLvD8uj8Lh7l2exZVyKopKP+bkXomk8UslWgl2olJgR7BLxs7qkHumEnVn0edO6/99JcqV4PqhIoCjSXwUEnfq0/+VjwWShUGoLZAmVvQGjas2fuu+xANFtI4H92wVi/m1O3QKiOH9t2zFkrvmbA1zGOoEj2n/Gipq/XeyRmjNSByGIw5W4P+V66Z9hRzKIj0eBiJADA==
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=Ml9P/qbE0KF6UxVD6+jSSpsdZqlyn0DrI+ve2Nni0zI=;
 b=sPj0j7d4JprIhm0HBhjgyquRrpvRSgNPlFEZnC5zTrAoSdiTZvLWC4072uh57thrxn2MpU/gYtNELdDK8nzEuekR7VLzoRx6ubbCQcDW3UNE+zQZ/KY62lnYq+04ZE/We96JSXDKX8mllrZVs+nmtDdOjBKQEMnFLZ9JVK7REnA=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Wed, 18 Jun 2025 09:06:23 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen/dt: Remove loop in dt_read_number()
To: Alejandro Vallejo , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis 
References: <20250617171358.670642-1-agarciav@amd.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250617171358.670642-1-agarciav@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: PA7P264CA0196.FRAP264.PROD.OUTLOOK.COM
 (2603:10a6:102:36d::9) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|SN7PR12MB6839:EE_
X-MS-Office365-Filtering-Correlation-Id: a05efdd3-c5d4-4b1f-65e1-08ddae36a4ab
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?WXBkYzd0cm1KcDBJNGZueFJwL3doTnFuZ01sQ2RaMkl0MXBnRHZaUmtXcGtk?=
 =?utf-8?B?RHQ4d3NkcXFQYW01Z1luTGE4aDVEQk9QZnNnS3dNV0xkQ1M5RlI5R2lhcUxm?=
 =?utf-8?B?MG50Sm0vNGdWQUZCK2VNSmhSRnNjZHRIMU9MZnNhamxtUWxKV2Y4NUlvUDRI?=
 =?utf-8?B?MGg0L0NJVGthRWE2YlBmYXhSQWR3OUk5UU5uSStXbTQ1U3JSZ3pwSC9pMXF0?=
 =?utf-8?B?YUFHVU5KNXU0NHlpODV5dGt6dkp5TEd4MlpjVnBtV3o4bGl1RlZ0QnhUQ2dp?=
 =?utf-8?B?TCtFZ3FKQmR4YmExMU56YTBIM2VmTE1ya09Bd05UanhNRmw4NFZMMXBIZlF3?=
 =?utf-8?B?WnBiRzNGMHNET1gzSTlGeDBFUWM1T2hDa1p0TFJoODJuTU5JcjZobmNpa3pn?=
 =?utf-8?B?azVnOHlTKzFoZFAyYno4dWx2OXlCenhOVXRJT3J0eExBeTdFUEZqVElGT05m?=
 =?utf-8?B?SDNXb0Uxd3JEa2h6NzVuMHdweThWMjNIT05PN1ZTeXlWSTh4MVNXdHJZUllq?=
 =?utf-8?B?cFdrQ1IvU2FYOTdhZEJxL3RybnpkckpSdHFiVDZXM3V2T3FEUllDd3hQZVBY?=
 =?utf-8?B?MHhBdDgxdjZibHhtMXQ3YkxCMDZsZXZTUE9JUUxoQjFEaUk4QXRPOUxwZHhR?=
 =?utf-8?B?Z0lTOWQzejhvdUhaZ3hkUFZ2RjRKOVYrRmFhVVN6RlFUWVlLejRQRFlaTVBQ?=
 =?utf-8?B?czFQc2ZSVExPOEQ0TS9zdDJIRi9MeVRubENJRE9SLzhxazV3QjNybkZCVGF5?=
 =?utf-8?B?VVYzQSt3dWJkazNnekVGZU1sbzlmcmJvSnc5YlczZUx3Szd5aGlMQWc5ejE2?=
 =?utf-8?B?NFRENDNoVjBtNHo2cVRmS1JjOTZ5RVJ4YzlJZVNpYi8yTlJhV0lCYkljeE42?=
 =?utf-8?B?bHdHS25tNVdYV3FMODlTTW5lbnpUWXdWbVRGRmJnWThyWDBpRks0SGNIZHBW?=
 =?utf-8?B?dXpJZXpxK3pncitrRmlzVkdtd3FnaHkwUkp3aTVlRlVhMGtXQlFEd2kxRzNk?=
 =?utf-8?B?ZE9UQzlkaUVCLzMzdjFWK1JFL0cvQXJ6eWlJcERES08wSHkwUXJBQzMyUHV2?=
 =?utf-8?B?SGlGS0REYzVTWnFTMlJXS1lGV2x0aWNkeCtZanIycitKK1g2RWlwL2s0alJq?=
 =?utf-8?B?YW44by9aQU55eTdJK3ZYTEhRcEZsQkhsYWtsUFhjaWpxWks2Sm1keGhBN3M2?=
 =?utf-8?B?b1ppTndyZVM5Q3RKUTI2S25ja0JzS2R2bHJsZncvdEJjejZtTHcxbHJmcnBE?=
 =?utf-8?B?a1BRZHJuY2VuMS9WVFZNWlFkc0xkREdFWlpNbDlSdTdqenpHZXcvK1p0SS9x?=
 =?utf-8?B?ODRSVUEvWUxtbjhMZnNEZEFSQzROYkkwNFJ4cTBWVFpnbmRlTU1OeTE4Q0xD?=
 =?utf-8?B?NXlONGsyS2hDMVgyNjNUQmxCckJ3d3pJdEE5eUN5NE1zbUF2aFJiWjA0RDEv?=
 =?utf-8?B?T1lHbXVXWHNkcTdubTdxOEdRUStITDNBcWxrREFoNmxpTlAwTVVYOHliV3dE?=
 =?utf-8?B?Qnd3UXRidHMrMVNSREZnNGVhaEkwQ2FySCszVnJ5TFAyUTJTdVhPb2ZKMlo3?=
 =?utf-8?B?Zi8ra0s1RUlDdk0xbHdVY09RYXVSVXNhYUk1cEVmRjNUK2JNQWtkMjRYOVhp?=
 =?utf-8?B?VVNMU3FMbEc4RUNmekJKYnB4Qk9YRnBxcGU1Y3VlK01ua3YwOUQ3bTB1dW5B?=
 =?utf-8?B?MEQ2bzl4ZTRBcCthOEc1elJFOFRCemQxK2JOYW9qUzY3SDBGV3hpVXpVaFVJ?=
 =?utf-8?B?ZUlwQUNwTTJyUU9QellLenFzbmNVSDFvSEtVS041Z3lzNUJ5bVlzWWcyU0da?=
 =?utf-8?B?WVhzQjFJc2wrbVV3RmxIVGV4K2dMVVE5N2VzODdyaUxuRS9yYnB3dXE2NmxP?=
 =?utf-8?B?YXlBNUN4R1hVMzFQRDRDRjZrUmo4Y0pObWpndUEzOTFzcUJlWDA4YzYvdjZU?=
 =?utf-8?Q?htYpMYSCMtA=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.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?SlJON0xNMjZRK2RrNG9Rbnc5RDdacmlzZ0JBbjVtY28veFlIemsxMi9PTUhL?=
 =?utf-8?B?N2FoQW4ralBCazZjd3J6eVNaaUFpRmZSSXc2ZEtXT3RDcmxnaC9GR25yTEVs?=
 =?utf-8?B?QXRubFhNMFAxQ1o3Q3Z0Tmtpd3JJQUtGZWsycDZiQ3ZWVkROZTJvS0x1eU1K?=
 =?utf-8?B?Q09KYTlaVHVuR2h1a1IxazhPS3VMbUhQRjZMNjVadVk3cERnakpmdXBhR2Ji?=
 =?utf-8?B?NFlzWHg5MXNaZkUxb1U0SWJMUG1uVmUwZWNHWE9rN1dFOGd6dkVJTzZBWjFV?=
 =?utf-8?B?blA2cWNndlh6NkNUTlh1c2tyM2M5MWw1Z1NrUE5qVmdKL0dhYmVHN1d0anY4?=
 =?utf-8?B?K1dhcmNXaHVrdEVQODhyNnNnTjNITC9pVTdLRGQzdkhUdXRXYnFJRmQwYTVn?=
 =?utf-8?B?QzFJb2R4cFBUaFM3aUp2M1lRVEdyWW9nemk5dGZHTm5wTlVhc0ZWWW4zTEZB?=
 =?utf-8?B?bW10VTZlS0hzSnpaczJOOWZMVXYvNDh4TXB1bFlINjNQWDVONkpZMEhQZFF2?=
 =?utf-8?B?VEdKMlNLM3hxVk91MW54MHFxMDhJTy9zblFDTWdYa0tTMGhVNWdZM053M0Ny?=
 =?utf-8?B?TXJ0YWJFbTlXZlJwVkthYmdLSWtmSnkvb21oUnNnbGhUOGdwK3pmaWRQbkl4?=
 =?utf-8?B?ejlHaGFINGRaaXhXY3poMFAwQkdIWW15RU56OU5QY3QwRW5qcUFyU0lBQWx4?=
 =?utf-8?B?dk5Va3QrQStOTVZVbkZmaTZyejNLNzJCWmd2ZkgyZG5zMDBWdnRObXNPclNU?=
 =?utf-8?B?d0RnOHVva1VCVnpEMWpNN2VkQTl2VjdHQkJCeEY2bjI5MHB1TGM2SWZlc0RX?=
 =?utf-8?B?OGJaN25KY2p5R2NvM1F2cmIwNUN1cEh3NUtsOGIrYWlBcFQ3c0FkUDVlZ1lk?=
 =?utf-8?B?SWxyVk9zcWlGTWxHbEg4VVZJaXJBRXFzbHorOS9OcGZKT0lleE1oY1hIbkhT?=
 =?utf-8?B?ZXZyTDB6YU4rRW5Kay92Wjk3ZEkyTWFKU3BYbzAvaHBzTXprb2dmWEUzYXUv?=
 =?utf-8?B?ZTdSM0kzMW0yNm1DU3VHSEwrMzJwSFN4eUVzU2NNWFgxZk1GYzV1akVia2g1?=
 =?utf-8?B?Y0JMNmdhdzdpaE52elFSckh2KzR4MGpjSVF1TG80VExaNjcrbXJUaXZkK3hi?=
 =?utf-8?B?ZDVTVCtpWmdXZzd5bXIvVU9FMkl4ODJncExjVDV2a0NBVEZsWCtEK1RneDd1?=
 =?utf-8?B?d1NPQWFGT2o2cWFHcE4xWllBSnJRWHFYTFJjVnY2bm41d2hPamdpY2VOU3lO?=
 =?utf-8?B?dFNiZjA2eG02VkpTODN3Qyt3aVdQQVRGa3g0cUUybWNEamIvQ24zYmloQzhj?=
 =?utf-8?B?U2FZVXhJMjd3S2lVdjRLUEdLQjR5MHNGYnMvWE5BL3dTcGpvYlpVdUNjL1dM?=
 =?utf-8?B?RUVKeE9PdktFTVdNYS9ZQXp5VGNRRE81K0NyTFliR3dZSTNNcHAyU2lvNCtn?=
 =?utf-8?B?L3RiSm01cEtwVlh6UVpvTGZqWmxWSTlzcUZxN1ZHMTY0ZkZUTDV6MThFb3Qz?=
 =?utf-8?B?aGlCdXR6N2RydlZFZ09vOG5TR2RITjRlbWVsejlic1gzaUxtNEt3LzhyaTRs?=
 =?utf-8?B?WVN0UDRsU2Voc3hIRVI4c0JxQnJKaWNoaXluRnhSb2RLUkRwWDJnbWVHa25Y?=
 =?utf-8?B?UitTN3lIbjFjcWtTSFJveSt2QXNMSENKaStRQmowZ0FmcTFQTjFjZ1d0KzlJ?=
 =?utf-8?B?dHNhVHRVREd6WEI4K09YQ1JTOUJLNmZYMS9hQU1Xb0NZVTMzOTJGbjJycm1j?=
 =?utf-8?B?cmVBR2VNcXJQSjJwWGllVmJlMEp6L3JZTzF0MlVUTG5XVHpQNHFEUi9XU3lG?=
 =?utf-8?B?RXM3ZTMvQ0o0bEVva1lmUFZXRUU2NGIvOXVzOS9GRFRWUTY4UkpjbHAwcFJX?=
 =?utf-8?B?cnE1NVM2eExtRFhBYnBTTWE5L2l2U3NVeC9NU01PbzhkYmpoNi9KUUlCQUFD?=
 =?utf-8?B?VnpxWHlMZ3lWeU1ubEJseTN5dWhWV1JBaGo5MmsrSDhJM0xNRVVTQlJWOFBN?=
 =?utf-8?B?THhyNlBuUy9WV3VKcmNSMUU3aSt1VmZkQ2ozM2xVem9acnZPUkhBemZtTkdx?=
 =?utf-8?B?aVRES0drRWNCL1NOUjNMZmRLVUZvYzRLWCtLS0ZkaUcxYTZWVmtnVGFIYUIx?=
 =?utf-8?Q?F7QU=3D?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a05efdd3-c5d4-4b1f-65e1-08ddae36a4ab
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jun 2025 07:06:27.2378
 (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: KCm00JynhUirwizwXeddPIGnVS/6M1VbiIvvZHX3+YYGUUzobIsn0beawrL1qckx
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB6839



On 17/06/2025 19:13, Alejandro Vallejo wrote:
> The DT spec declares only two number types for a property: u32 and u64,
> as per Table 2.3 in Section 2.2.4. Remove unbounded loop and replace
> with a switch statement. Default to a size of 1 cell in the nonsensical
> size case, with a warning printed on the Xen console.
> 
> Suggested-by: Daniel P. Smith" 
> Signed-off-by: Alejandro Vallejo 
> ---
> v2:
>   * Added missing `break` on the `case 2:` branch and added ASSERT_UNREACHABLE() to the deafult path
> ---
>  xen/include/xen/device_tree.h | 17 ++++++++++++++---
>  1 file changed, 14 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> index 75017e4266..2ec668b94a 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -261,10 +261,21 @@ void intc_dt_preinit(void);
>  /* Helper to read a big number; size is in cells (not bytes) */
>  static inline u64 dt_read_number(const __be32 *cell, int size)
>  {
> -    u64 r = 0;
> +    u64 r = be32_to_cpu(*cell);
> +
> +    switch ( size )
> +    {
> +    case 1:
> +        break;
> +    case 2:
> +        r = (r << 32) | be32_to_cpu(cell[1]);
> +        break;
> +    default:
> +        // Nonsensical size. default to 1.
I wonder why there are so many examples of device trees in Linux with
#address-cells = <3>? Also, libfdt defines FDT_MAX_NCELLS as 4 with comment:
"maximum value for #address-cells and #size-cells" but I guess it follows the
IEE1275 standard and DT spec "is loosely related" to it.

~Michal



From xen-devel-bounces@lists.xenproject.org Wed Jun 18 07:07:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 07:07:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018858.1395736 (Exim 4.92)
	(envelope-from )
	id 1uRmtT-00078B-OS; Wed, 18 Jun 2025 07:07:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018858.1395736; Wed, 18 Jun 2025 07:07:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRmtT-000784-Le; Wed, 18 Jun 2025 07:07:35 +0000
Received: by outflank-mailman (input) for mailman id 1018858;
 Wed, 18 Jun 2025 07:07: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 1uRmtS-00077n-DW
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 07:07:34 +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 e80ec7f4-4c12-11f0-a30a-13f23c93f187;
 Wed, 18 Jun 2025 09:07:33 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3a4f71831abso5863280f8f.3
 for ; Wed, 18 Jun 2025 00:07:33 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2365d8a5b26sm92610185ad.87.2025.06.18.00.07.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Jun 2025 00:07:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e80ec7f4-4c12-11f0-a30a-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750230453; x=1750835253; 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=kzoqyNL2bozGaoyRe3gin1wz6oRTYFxHZ457waajCrA=;
        b=FpJDOarmjCeCE5n0y6Xm33JhxrwFKil/XBgNGduB92z2qkJMosOX643wX6bXv/+TrP
         SRhHzBorq1hm0IdzNwGUgwlu9lA9VUj/UlTBNI/sL+S92Bo7y19ELIHkfjhcSvqBniIL
         b4UHg4r0267HcaDSaKGejw1ALvbcL91EqmfD5LvSzv+4C4clK5JpMVng0jFpWybefGxh
         bCD57eQHPksceFN+EB/IEnQWIaJnx4jWloYFwanL5lKRq2kjgoZ8P0ZB4sv/dIN7EgV6
         xKICv9X8Q9UByX2NKX5D09hDqXnlfcbzNRWtIofsBNK4ypxBz4hSpiCHP/5AyZeXEtrf
         IOpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750230453; x=1750835253;
        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=kzoqyNL2bozGaoyRe3gin1wz6oRTYFxHZ457waajCrA=;
        b=gLrpxFAewYY1Dgn5nOwxc5U0OFpV9Y8JV6TMK914ZTpiv9zkycQ/+GhJMkwtB5taXf
         DCgrOD+kIq8kcR3olvWbwG8ah0CLFUiimFBaLOwfurHEPiDGd8JETNo5GZUB4lii1RNM
         rloWA6lmRS3ymJ4H8qEF3XT/0+HMjAGnFfrnL2yzV5GLAQWOJeU3vKejfIh3rJ0K3yhO
         ELVktidTl768mxATEsPuxTuaJqXb26yEu5rwuLE83O0FfVy0JZ3boXB1qkC3JZxs20Th
         B5p2Cg11Jf9IyhyF3c/ISBOya24aiDzcLyGXT31zEzyombTC322QIY1iVhjf3hr+4VFQ
         ny0g==
X-Gm-Message-State: AOJu0YyNPsWnDwUZB268rsaMdov1gBdtXBBxH3lTZYtX66jCCmMB4cuR
	zKQH4s2ErGEp6DT4/xbPBAvXCQ1ec3HrlYiZBMgxcvH9i3g4a8xxt7WA2+y9Nt2C0hGpE2FbJmI
	W490=
X-Gm-Gg: ASbGncsiy+uLAsAIwwOHGarupH5Hsq3zGbncUvU3eS4g9ZL3BjZPPUO4PuadarZLNYc
	pLBMlQjGzHZnMJED52dfcZopvgOK/ZjjLyJ3sGMY6/efoS+PegjTw2a6CFuwcR6O118/U6NX0l3
	KBCOaK9FQP6rUQQ8ZHiGYoLytZWSWtk2mnMF+ErMmlF6q+VQAD/Wo2MHQgOXunMD55zRiWTnrb5
	GXZfy3xj35GrVAqLJe5hLElSMPZ0j/yq/V07tkXoi3hkO+U99BBtyuQaCCmJIweGkt9grThymHF
	Kji4W2KH5kUS8qFufZzb9HYcWBN0xBDg8TimO97i23UxvciEZbbzwPYewZqjt+Hb1Gomp0MK0Wf
	U0NufKqWoBUaSAnhYQlE8hnLyIWgANFIjXeyQ+816nQ4zA2w=
X-Google-Smtp-Source: AGHT+IGBvd8LY/GHCZit8xjh49F0KaXFuMkzJRz/HRK1h0wGuT/fVdIVagU/q5bxNj50RcQsKNuOpA==
X-Received: by 2002:a05:6000:3104:b0:3a4:c713:7d8 with SMTP id ffacd0b85a97d-3a572373dc4mr12163715f8f.16.1750230452913;
        Wed, 18 Jun 2025 00:07:32 -0700 (PDT)
Message-ID: <8b2b6887-a780-47d9-9ef6-bd03c644b6e6@suse.com>
Date: Wed, 18 Jun 2025 09:07:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v8 6/7] x86emul: support MSR_IMM instructions
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <585f1b0b-6768-4f9c-8f9f-bcf6e20fbfb7@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: <585f1b0b-6768-4f9c-8f9f-bcf6e20fbfb7@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Encoding-wise these are very similar to URDMSR/UWRMSR, so existing logic
is easy to extend.

Signed-off-by: Jan Beulich 
---
RFC only for now, as the VMX part is missing: The existing intercepts
can't be re-used unmodified, as those require the MSR index to be
fetched from guest ECX.
---
v8: Don't mark the feature 's' just yet. Re-base.
v7: New.

--- a/tools/tests/x86_emulator/predicates.c
+++ b/tools/tests/x86_emulator/predicates.c
@@ -1519,6 +1519,8 @@ static const struct vex {
     { { 0xdf }, 3, T, R, pfx_66, WIG, Ln }, /* vaeskeygenassist */
     { { 0xf0 }, 3, T, R, pfx_f2, Wn, L0 }, /* rorx */
 }, vex_map7[] = {
+    { { 0xf6, 0xc0 }, 6, F, N, pfx_f3, W0, L0 }, /* wrmsrns */
+    { { 0xf6, 0xc0 }, 6, F, N, pfx_f2, W0, L0 }, /* rdmsr */
     { { 0xf8, 0xc0 }, 6, F, N, pfx_f3, W0, L0 }, /* uwrmsr */
     { { 0xf8, 0xc0 }, 6, F, N, pfx_f2, W0, L0 }, /* urdmsr */
 };
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -1574,6 +1574,30 @@ int main(int argc, char **argv)
     if ( (rc != X86EMUL_EXCEPTION) ||
          (regs.rip != (unsigned long)&instr[0]) )
         goto fail;
+    printf("okay\n");
+
+    printf("%-40s", "Testing rdmsr $MSR_GS_BASE,%rdx...");
+    instr[0] = 0xc4; instr[1] = 0xe7; instr[2] = 0x7b; instr[3] = 0xf6; instr[4] = 0xc2;
+    *(uint32_t *)&instr[5] = MSR_GS_BASE;
+    regs.rip = (unsigned long)&instr[0];
+    regs.rdx = ~gs_base;
+    rc = x86_emulate(&ctxt, &emulops);
+    if ( (rc != X86EMUL_OKAY) ||
+         (regs.rip != (unsigned long)&instr[9]) ||
+         (regs.rdx != gs_base) )
+        goto fail;
+    printf("okay\n");
+
+    printf("%-40s", "Testing wrmsrns %rsi,$MSR_SHADOW_GS_BASE...");
+    instr[0] = 0xc4; instr[1] = 0xe7; instr[2] = 0x7a; instr[3] = 0xf6; instr[4] = 0xc6;
+    *(uint32_t *)&instr[5] = MSR_SHADOW_GS_BASE;
+    regs.rip = (unsigned long)&instr[0];
+    regs.rsi = 0x665544332211UL;
+    rc = x86_emulate(&ctxt, &emulops);
+    if ( (rc != X86EMUL_OKAY) ||
+         (regs.rip != (unsigned long)&instr[9]) ||
+         (gs_base_shadow != 0x665544332211UL) )
+        goto fail;
 
     emulops.write_msr     = NULL;
 #endif
--- a/tools/tests/x86_emulator/x86-emulate.c
+++ b/tools/tests/x86_emulator/x86-emulate.c
@@ -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.msr_imm = true;
     cpu_policy.feat.user_msr = true;
     cpu_policy.extd.clzero = true;
 
--- a/xen/arch/x86/x86_emulate/decode.c
+++ b/xen/arch/x86/x86_emulate/decode.c
@@ -1262,8 +1262,9 @@ int x86emul_decode(struct x86_emulate_st
                     case vex_map7:
                         opcode |= MASK_INSR(7, X86EMUL_OPC_EXT_MASK);
                         /*
-                         * No table lookup here for now, as there's only a single
-                         * opcode point (0xf8) populated in map 7.
+                         * No table lookup here for now, as there are only two
+                         * (very similar) opcode points (0xf6, 0xf8) populated
+                         * in map 7.
                          */
                         d = DstMem | SrcImm | ModRM | Mov;
                         s->op_bytes = 8;
--- a/xen/arch/x86/x86_emulate/private.h
+++ b/xen/arch/x86/x86_emulate/private.h
@@ -613,6 +613,7 @@ amd_like(const struct x86_emulate_ctxt *
 #define vcpu_has_wrmsrns()     (ctxt->cpuid->feat.wrmsrns)
 #define vcpu_has_avx_ifma()    (ctxt->cpuid->feat.avx_ifma)
 #define vcpu_has_msrlist()     (ctxt->cpuid->feat.msrlist)
+#define vcpu_has_msr_imm()     (ctxt->cpuid->feat.msr_imm)
 #define vcpu_has_avx_vnni_int8() (ctxt->cpuid->feat.avx_vnni_int8)
 #define vcpu_has_avx_ne_convert() (ctxt->cpuid->feat.avx_ne_convert)
 #define vcpu_has_avx_vnni_int16() (ctxt->cpuid->feat.avx_vnni_int16)
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -7075,6 +7075,34 @@ x86_emulate(
         state->simd_size = simd_none;
         break;
 
+    case X86EMUL_OPC_VEX_F3(7, 0xf6): /* wrmsrns r64,imm32 */
+    case X86EMUL_OPC_VEX_F2(7, 0xf6): /* rdmsr imm32,r64 */
+        generate_exception_if(!mode_64bit() || ea.type != OP_REG, 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(msr_imm);
+        generate_exception_if(!mode_ring0(), X86_EXC_GP, 0);
+        if ( vex.pfx == vex_f2 )
+        {
+            /* urdmsr */
+            fail_if(!ops->read_msr);
+            if ( (rc = ops->read_msr(imm1, &msr_val, ctxt)) != X86EMUL_OKAY )
+                goto done;
+            dst.val = msr_val;
+            ASSERT(dst.type == OP_REG);
+            dst.bytes = 8;
+        }
+        else
+        {
+            /* wrmsrns */
+            fail_if(!ops->write_msr);
+            if ( (rc = ops->write_msr(imm1, dst.val, ctxt)) != X86EMUL_OKAY )
+                goto done;
+            dst.type = OP_NONE;
+        }
+        break;
+
     case X86EMUL_OPC_F3(0x0f38, 0xf8): /* enqcmds r,m512 / uwrmsr r64,r32 */
     case X86EMUL_OPC_F2(0x0f38, 0xf8): /* enqcmd r,m512 / urdmsr r32,r64 */
         if ( ea.type == OP_MEM )
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -351,6 +351,7 @@ XEN_CPUFEATURE(MCDT_NO,            13*32
 XEN_CPUFEATURE(UC_LOCK_DIS,        13*32+ 6) /*   UC-lock disable */
 
 /* Intel-defined CPU features, CPUID level 0x00000007:1.ecx, word 14 */
+XEN_CPUFEATURE(MSR_IMM,            14*32+ 5) /*   RDMSR/WRMSRNS with immediate operand */
 
 /* Intel-defined CPU features, CPUID level 0x00000007:1.edx, word 15 */
 XEN_CPUFEATURE(AVX_VNNI_INT8,      15*32+ 4) /*A  AVX-VNNI-INT8 Instructions */
--- a/xen/tools/gen-cpuid.py
+++ b/xen/tools/gen-cpuid.py
@@ -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, USER_MSR],
+             LKGS, MSRLIST, USER_MSR, MSR_IMM],
 
         # AMD K6-2+ and K6-III processors shipped with 3DNow+, beyond the
         # standard 3DNow in the earlier K6 processors.



From xen-devel-bounces@lists.xenproject.org Wed Jun 18 07:08:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 07:08:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018869.1395747 (Exim 4.92)
	(envelope-from )
	id 1uRmuG-0007jB-4K; Wed, 18 Jun 2025 07:08:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018869.1395747; Wed, 18 Jun 2025 07:08:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRmuG-0007j4-0n; Wed, 18 Jun 2025 07:08:24 +0000
Received: by outflank-mailman (input) for mailman id 1018869;
 Wed, 18 Jun 2025 07:08: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 1uRmuE-00077n-ER
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 07:08:22 +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 04c14f44-4c13-11f0-a30a-13f23c93f187;
 Wed, 18 Jun 2025 09:08:22 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3a4fea34e07so3702806f8f.1
 for ; Wed, 18 Jun 2025 00:08:21 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-313c19b79acsm12003041a91.5.2025.06.18.00.08.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Jun 2025 00:08:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 04c14f44-4c13-11f0-a30a-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750230501; x=1750835301; 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=FHMinJJYzb3weGrutdOpi8qoKyoOq7iYKxbEejfM2Xw=;
        b=Zeef/invsxbgBZt3At+lyM5O2MCrhSWwwfhHi7v78pV28moQuTd91Tz6Dk/8BW4zGi
         7XT2cL3Gs7JjxCAJYf12UFnqF0b86+KaWBBAOnTIz3XzU9sS6JH2k2pPuMi6w1HDOn9v
         XgDNf16h1OFO2TXU1+QyxNeoo4C86D5oiPq5QfOJ9kxG2C9MrVHOWBTuZvAckZ+oYIwR
         p85sEHWeFzCu/q/mnPeR0e44pUQbqQYtcfQZ4CyBVsTXru2x/FAT2YYMFtHKIhs5JAry
         c91zj6VUGN6ZS1XhCzRNZY4r4D/kl1RHoFD3fTZjzGzNSIQr+FzysS/f89IZUSvuqsSN
         a19A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750230501; x=1750835301;
        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=FHMinJJYzb3weGrutdOpi8qoKyoOq7iYKxbEejfM2Xw=;
        b=M4GKoDTFzwUpES87cN0vZBk9AUbac6mxq8Jqiap+8lEZ6xHVi0n7Qmlmb0vlu4gKSL
         i4wAW+KFyZ6OfpDrc7vBQxPc2Zq4jJptW9BBPpMfRSr0UIpSY4pZc3djekcfMWDgFpOZ
         gnvWz1PV9Xa+wEDFwHUObuXhCS8dH8RMg/iYeNGv/58RzN1wYvO59oGGVMvPGs7b/pwi
         yzwRmdbh030uDwA6v4XGldBVmPmqE6Z2Gc5vznKl2IiwnQ94Sdt8NGCmkMnHeR2Ly3m7
         4hq/eNsj5lLiuOrHwTW3COEsqiMY3kBKhPK49D7tqlXWRLodxqlRPk7jnATrBAYpguoY
         4XgA==
X-Gm-Message-State: AOJu0YxZS2A4ndHIrQSHm9y3pDOslcUNGR1+dyoVhPa3zRa8uArLVICX
	DelAz8+EWaPm3AqjGMC3yNfbvVQltsyOnOHlmPf61LETDayWjMxP/kZ/xwJ6G3HQJyytxGDy/E7
	k6m0=
X-Gm-Gg: ASbGnctW8lXhznMR03p02dFkf971fLKajSXE4MAyllMzz26xmfTztyryzSytFuSCvY4
	08njF8JcOPoHNx/PVv6q7ty6Jl0E0rj3yIKhwiiEKll4Z/oOkbX7c+RLEcRmY7V+y3IlO830oNI
	xS6hM26XhiefUionKWPpzv0y9Kh341N7eDOtOENnxzIpINzC9s4BogJJO1Jybfp59MvGXmXQzvs
	pc+MAGQ8satIOc0jEzkWT32pNG462nrjPKVzMfRtp5mAPuGwvFva2WcrlPRByG37hDdQ7sjLlHs
	Wr4jA0MgnuOX478DqnCr80NjWS5x2vW5ObMvjF6o6LZT+QtGscd/1+yxmDslgkBxc5D3JTaQhiO
	+1A9INgBw0tLkjVCYQCfokh6lULCr1mds1do8sWH81eAqK7g=
X-Google-Smtp-Source: AGHT+IHMMbuHbacSpKwuipsSSNt+OiLU3ta9UHLCzzV8EL74oF7jmOExmlGC6iRRVdmKMY7lCAKOXw==
X-Received: by 2002:a05:6000:40df:b0:3a4:cbc6:9db0 with SMTP id ffacd0b85a97d-3a572e563a8mr11088437f8f.51.1750230501089;
        Wed, 18 Jun 2025 00:08:21 -0700 (PDT)
Message-ID: <8e5acc40-ffdd-408e-af4c-c98fe94fb798@suse.com>
Date: Wed, 18 Jun 2025 09:08:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v8 7/7] x86emul: support non-SIMD MOVRS
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <585f1b0b-6768-4f9c-8f9f-bcf6e20fbfb7@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: <585f1b0b-6768-4f9c-8f9f-bcf6e20fbfb7@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
MOVs.

Signed-off-by: Jan Beulich 
---
SDE: -dmr
---
v7: New.

--- a/tools/tests/x86_emulator/predicates.c
+++ b/tools/tests/x86_emulator/predicates.c
@@ -843,6 +843,9 @@ static const struct {
     { { 0x80 }, { 2, 2 }, T, R, pfx_66 }, /* invept */
     { { 0x81 }, { 2, 2 }, T, R, pfx_66 }, /* invvpid */
     { { 0x82 }, { 2, 2 }, T, R, pfx_66 }, /* invpcid */
+    { { 0x8a }, { 2, 2 }, T, R, pfx_no }, /* movrsb */
+    { { 0x8b }, { 2, 2 }, T, R, pfx_no }, /* movrs{d,q} */
+    { { 0x8b }, { 2, 2 }, T, R, pfx_66 }, /* movrsw */
     { { 0xc8 }, { 2, 2 }, T, R, pfx_no }, /* sha1nexte */
     { { 0xc9 }, { 2, 2 }, T, R, pfx_no }, /* sha1msg1 */
     { { 0xca }, { 2, 2 }, T, R, pfx_no }, /* sha1msg2 */
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -1869,6 +1869,29 @@ int main(int argc, char **argv)
     }
     else
         printf("skipped\n");
+
+    {
+        /* For the non-SIMD forms the emulator doesn't itself use MOVRS. */
+        bool movrs = cpu_policy.feat.movrs;
+
+        cpu_policy.feat.movrs = true;
+
+        printf("%-40s", "Testing movrs 6(%rdi),%si...");
+        instr[0] = 0x66; instr[1] = 0x0f; instr[2] = 0x38;
+        instr[3] = 0x8b; instr[4] = 0x77; instr[5] = 0x06;
+        regs.rip = (unsigned long)&instr[0];
+        regs.rsi = 0x8888777766665555UL;
+        regs.rdi = (unsigned long)res;
+        res[1]   = 0x88777788U;
+        rc = x86_emulate(&ctxt, &emulops);
+        if ( (rc != X86EMUL_OKAY) ||
+             (regs.rip != (unsigned long)&instr[6]) ||
+             (regs.rsi != 0x8888777766668877UL) )
+            goto fail;
+        printf("okay\n");
+
+        cpu_policy.feat.movrs = movrs;
+    }
 #endif /* x86-64 */
 
     printf("%-40s", "Testing shld $1,%ecx,(%edx)...");
--- a/xen/arch/x86/x86_emulate/decode.c
+++ b/xen/arch/x86/x86_emulate/decode.c
@@ -901,7 +901,8 @@ decode_0f38(struct x86_emulate_state *s,
 {
     switch ( ctxt->opcode & X86EMUL_OPC_MASK )
     {
-    case 0x00 ... 0xef:
+    case 0x00 ... 0x89:
+    case 0x8c ... 0xef:
     case 0xf2 ... 0xf5:
     case 0xf7:
     case 0xfa ... 0xff:
@@ -912,6 +913,13 @@ decode_0f38(struct x86_emulate_state *s,
         ctxt->opcode |= MASK_INSR(s->vex.pfx, X86EMUL_OPC_PFX_MASK);
         break;
 
+    case 0x8a ... 0x8b: /* movrs */
+        s->desc = DstReg | SrcMem | Mov;
+        if ( !(ctxt->opcode & 1) )
+            s->desc |= ByteOp;
+        s->simd_size = simd_none;
+        break;
+
     case X86EMUL_OPC_VEX_66(0, 0x2d): /* vmaskmovpd */
         s->simd_size = simd_packed_fp;
         break;
--- a/xen/arch/x86/x86_emulate/private.h
+++ b/xen/arch/x86/x86_emulate/private.h
@@ -613,6 +613,7 @@ amd_like(const struct x86_emulate_ctxt *
 #define vcpu_has_wrmsrns()     (ctxt->cpuid->feat.wrmsrns)
 #define vcpu_has_avx_ifma()    (ctxt->cpuid->feat.avx_ifma)
 #define vcpu_has_msrlist()     (ctxt->cpuid->feat.msrlist)
+#define vcpu_has_movrs()       (ctxt->cpuid->feat.movrs)
 #define vcpu_has_msr_imm()     (ctxt->cpuid->feat.msr_imm)
 #define vcpu_has_avx_vnni_int8() (ctxt->cpuid->feat.avx_vnni_int8)
 #define vcpu_has_avx_ne_convert() (ctxt->cpuid->feat.avx_ne_convert)
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -6374,6 +6374,16 @@ x86_emulate(
         fault_suppression = false;
         goto avx512f_no_sae;
 
+#endif /* !X86EMUL_NO_SIMD */
+
+    case X86EMUL_OPC(0x0f38, 0x8a)
+     ... X86EMUL_OPC(0x0f38, 0x8b): /* movrs */
+        vcpu_must_have(movrs);
+        dst.val = src.val;
+        break;
+
+#ifndef X86EMUL_NO_SIMD
+
     case X86EMUL_OPC_VEX_66(0x0f38, 0x8c): /* vpmaskmov{d,q} mem,{x,y}mm,{x,y}mm */
     case X86EMUL_OPC_VEX_66(0x0f38, 0x8e): /* vpmaskmov{d,q} {x,y}mm,{x,y}mm,mem */
         generate_exception_if(ea.type != OP_MEM, X86_EXC_UD);
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -319,6 +319,7 @@ XEN_CPUFEATURE(AVX_IFMA,     10*32+23) /
 XEN_CPUFEATURE(LAM,          10*32+26) /*   Linear Address Masking */
 XEN_CPUFEATURE(MSRLIST,      10*32+27) /*   {RD,WR}MSRLIST instructions */
 XEN_CPUFEATURE(NO_INVD,      10*32+30) /*   INVD instruction unusable */
+XEN_CPUFEATURE(MOVRS,        10*32+31) /*a  MOV-read-shared instructions */
 
 /* AMD-defined CPU features, CPUID level 0x80000021.eax, word 11 */
 XEN_CPUFEATURE(NO_NEST_BP,         11*32+ 0) /*A  No Nested Data Breakpoints */
--- 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, USER_MSR, MSR_IMM],
+             LKGS, MSRLIST, USER_MSR, MSR_IMM, MOVRS],
 
         # 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 Jun 18 07:11:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 07:11:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018882.1395758 (Exim 4.92)
	(envelope-from )
	id 1uRmwk-0001Cj-H5; Wed, 18 Jun 2025 07:10:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018882.1395758; Wed, 18 Jun 2025 07:10: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 1uRmwk-0001Cc-Ct; Wed, 18 Jun 2025 07:10:58 +0000
Received: by outflank-mailman (input) for mailman id 1018882;
 Wed, 18 Jun 2025 07:10: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 1uRmsj-0004U2-JB
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 07:06:49 +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 ccadedfc-4c12-11f0-b894-0df219b8e170;
 Wed, 18 Jun 2025 09:06:47 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-453398e90e9so36368465e9.1
 for ; Wed, 18 Jun 2025 00:06:47 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-748900b04e4sm10190513b3a.121.2025.06.18.00.06.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Jun 2025 00:06:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ccadedfc-4c12-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750230407; x=1750835207; 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=1+Q+rknhKt/qTaPwfO0xWIDCympY5+1iNAgBNhqS5wA=;
        b=EgLVEw+UBcpPaC0XuoD4aIvWUT2Ebk3TYkCWNUAqzRF6rrmMvjnxPbZgQHeQtqoxDT
         igsBADVQYzxar9aHKn4TKZi0ZR4yZWz6STUnE30P+Sngysmx+CGCtSYovf6JaPCMyWLp
         /e0R9DtihYhbhP4Ep3dv6JJ3fo2szoJxf8lnnVcTydynWAFRApxcrteAU4/FHLPji3tL
         MKY10ev6tUQoJI9Af9mIelvQzRs2a7v5n/xjvFQhRz8vazuqi/NYUYixhRFC3FL0hy8+
         eim2E9ibUdg+rizvOR1yRsrVWOdHlPMciWBPIKo2lXHB4bEGQEBbGbUAk3M+hv0N4a4t
         Mjhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750230407; x=1750835207;
        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=1+Q+rknhKt/qTaPwfO0xWIDCympY5+1iNAgBNhqS5wA=;
        b=Yh8xwfIxHS1PfWJIumG2UEg+bv7nqWF4fZdZYcSjQa4MS4M8JOv/nBCGr+jdEDRSdY
         uqXCYPSIFDGHu9fEGNYkoczIB8bQKM5UUOup+j9lDJ67VhL9stfLVT27A6mgl9mZTmtE
         Jh26fj3C+gQVoQY5eXI8Hi7d0kLu7xME5cI30ENpOqe7Yy64DHHK/kpsKPD0bvCDY/0K
         a6vJKNxCby8pPi6m7U8De/AzDrwe6TdmB0sjTj2LFObvYhSZUHuZHWkLjCZ1FhZQeDnB
         W3+ylWp/w1XnWMSTzJtN/2hkzJaBYNGZoEAz5IrM43HgBAtGjRCXYgHm1kJlE2Rv3VFT
         VDBg==
X-Gm-Message-State: AOJu0YzlGrq1JXNVYuwrqTYspQvdRT6z9+vCfJTMQT7u1eXC2i7MFTQF
	Bg2U5B/Pg0b4b8K8m0Yfd+JvZAMpxKH+cfgFxI+raDl3sgK4dx5JQdMHqXNmzFWosMaFdCz5NQp
	sc0c=
X-Gm-Gg: ASbGncuC/l5hR90tiAQS1MLNuG5m7P4lDiFvlXlRzoobEPBQBeels3tc+kCoykQkIzb
	fU7DaAu7lFpl82pW3XvA1rp8WvQH0iPfq1DgtLtJyVfh3dF749DZUAeyWaei5Z1sn1KVRTTWGnD
	Dh0llijQdagkmySZgeBl8AhrbQf3jRW/QuH9ViDG4gMZah6qCRCbOs9pXwRKvIHQj074S6hw5oS
	njekoeHAiTPhoH4y5DmVVk0wBdsTY2kjMdfxpX0UTfBqFb4iVzQqWVEmlmi3wqXO15T7MvzAGf1
	PCrhrlmqPdKufGGszu8+M2z4so39DTTxRlJ9TSDT3cQr2ek428YaeAIAnYugwPih3ufWAaRWROD
	67h6M6+86qQBZXyaCxDSYNgbCQPn1HHOP8rAXr8oZHX7O7kg=
X-Google-Smtp-Source: AGHT+IEBN2BJ+TAWvyGINJEN+nc1df7+YK49H46qOh2T0bDaAI2wGF4uxJVml01lbg233xK9NZ4EZA==
X-Received: by 2002:a05:6000:26ca:b0:3a5:2f23:3780 with SMTP id ffacd0b85a97d-3a5723a2dbamr13140820f8f.18.1750230407036;
        Wed, 18 Jun 2025 00:06:47 -0700 (PDT)
Message-ID: <0557b0e8-cd02-4812-9b58-62784afafe8e@suse.com>
Date: Wed, 18 Jun 2025 09:06:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v8 5/7] VMX: support USER_MSR
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <585f1b0b-6768-4f9c-8f9f-bcf6e20fbfb7@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: <585f1b0b-6768-4f9c-8f9f-bcf6e20fbfb7@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hook up the new VM exit codes and handle guest accesses, context switch,
and save/restore. At least for now don't allow the guest direct access
to the control MSR; this may need changing if guests were to frequently
access it (e.g. on their own context switch path).

While there also correct a one-off in union ldt_or_tr_instr_info's
comment.

Signed-off-by: Jan Beulich 
---
Needing to change two places in hvm.c continues to be unhelpful; I
recall I already did forget to also adjust hvm_load_cpu_msrs() for XFD.
Considering that MSRs typically arrive in the order the table has it,
couldn't we incrementally look up the incoming MSR index there, falling
back to a full lookup only when the incremental lookup failed (and thus
not normally re-iterating through the initial part of the array)?

Said comment in union ldt_or_tr_instr_info is further odd (same for
union gdt_or_idt_instr_info's) in that Instruction Information is only a
32-bit field. Hence bits 32-63 aren't undefined, but simply don't exist.

RFC: The wee attempt to "deal" with nested is likely wrong, but I'm
     afraid I simply don't know where such enforcement would be done
     properly. Returning an error there is also commented out, for
     domain_cpu_policy_changed() returning void without "x86/xstate:
     re-size save area when CPUID policy changes" in place.
---
v8: Re-base.
v5: Introduce user_msr_gpr().
v4: New.

--- a/xen/arch/x86/cpu-policy.c
+++ b/xen/arch/x86/cpu-policy.c
@@ -786,6 +786,12 @@ static void __init calculate_hvm_max_pol
          * situations until someone has cross-checked the behaviour for safety.
          */
         __clear_bit(X86_FEATURE_PKS, fs);
+
+        /*
+         * Don't expose USER_MSR until it is known how (if at all) it is
+         * virtualized on SVM.
+         */
+        __clear_bit(X86_FEATURE_USER_MSR, fs);
     }
 
     if ( !cpu_has_vmx_msrlist )
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -450,6 +450,10 @@ void domain_cpu_policy_changed(struct do
         }
     }
 
+    /* Nested doesn't have the necessary processing, yet. */
+    if ( nestedhvm_enabled(d) && p->feat.user_msr )
+        return /* -EINVAL */;
+
     for_each_vcpu ( d, v )
     {
         cpu_policy_updated(v);
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1383,6 +1383,7 @@ static int cf_check hvm_load_cpu_xsave_s
 
 #define HVM_CPU_MSR_SIZE(cnt) offsetof(struct hvm_msr, msr[cnt])
 static const uint32_t msrs_to_send[] = {
+    MSR_USER_MSR_CTL,
     MSR_SPEC_CTRL,
     MSR_INTEL_MISC_FEATURES_ENABLES,
     MSR_PKRS,
@@ -1537,6 +1538,7 @@ static int cf_check hvm_load_cpu_msrs(st
         {
             int rc;
 
+        case MSR_USER_MSR_CTL:
         case MSR_SPEC_CTRL:
         case MSR_INTEL_MISC_FEATURES_ENABLES:
         case MSR_PKRS:
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -689,13 +689,18 @@ static void cf_check vmx_vcpu_destroy(st
 }
 
 /*
- * To avoid MSR save/restore at every VM exit/entry time, we restore
- * the x86_64 specific MSRs at domain switch time. Since these MSRs
- * are not modified once set for para domains, we don't save them,
- * but simply reset them to values set in percpu_traps_init().
+ * To avoid MSR save/restore at every VM exit/entry time, we restore the
+ * x86_64 specific MSRs at vcpu switch time. Since these MSRs are not
+ * modified once set for para domains, we don't save them, but simply clear
+ * them or reset them to values set in percpu_traps_init().
  */
-static void vmx_restore_host_msrs(void)
+static void vmx_restore_host_msrs(const struct vcpu *v)
 {
+    const struct vcpu_msrs *msrs = v->arch.msrs;
+
+    if ( msrs->user_msr_ctl.enable )
+        wrmsrl(MSR_USER_MSR_CTL, 0);
+
     /* No PV guests?  No need to restore host SYSCALL infrastructure. */
     if ( !IS_ENABLED(CONFIG_PV) )
         return;
@@ -749,6 +754,9 @@ static void vmx_restore_guest_msrs(struc
 
     if ( cp->feat.pks )
         wrpkrs(msrs->pkrs);
+
+    if ( msrs->user_msr_ctl.enable )
+        wrmsrl(MSR_USER_MSR_CTL, msrs->user_msr_ctl.raw);
 }
 
 void vmx_update_cpu_exec_control(struct vcpu *v)
@@ -1192,7 +1200,7 @@ static void cf_check vmx_ctxt_switch_fro
     if ( !v->arch.fully_eager_fpu )
         vmx_fpu_leave(v);
     vmx_save_guest_msrs(v);
-    vmx_restore_host_msrs();
+    vmx_restore_host_msrs(v);
     vmx_save_dr(v);
 
     if ( v->domain->arch.hvm.pi_ops.flags & PI_CSW_FROM )
@@ -4172,6 +4180,14 @@ static int vmx_handle_apic_write(void)
     return vlapic_apicv_write(current, exit_qualification & 0xfff);
 }
 
+static unsigned int user_msr_gpr(void)
+{
+    user_msr_instr_info_t info;
+
+    __vmread(VMX_INSTRUCTION_INFO, &info.raw);
+    return info.gpr;
+}
+
 static void undo_nmis_unblocked_by_iret(void)
 {
     unsigned long guest_info;
@@ -4672,6 +4688,41 @@ void asmlinkage vmx_vmexit_handler(struc
             hvm_inject_hw_exception(X86_EXC_GP, 0);
         break;
 
+    case EXIT_REASON_URDMSR:
+    {
+        uint64_t msr_content = 0;
+
+        __vmread(EXIT_QUALIFICATION, &exit_qualification);
+        switch ( hvm_msr_read_intercept(exit_qualification, &msr_content) )
+        {
+        case X86EMUL_OKAY:
+            *decode_gpr(regs, user_msr_gpr()) = msr_content;
+            update_guest_eip(); /* Safe: URDMSR */
+            break;
+
+        case X86EMUL_EXCEPTION:
+            hvm_inject_hw_exception(X86_EXC_GP, 0);
+            break;
+        }
+        break;
+    }
+
+    case EXIT_REASON_UWRMSR:
+        __vmread(EXIT_QUALIFICATION, &exit_qualification);
+        switch ( hvm_msr_write_intercept(exit_qualification,
+                                         *decode_gpr(regs, user_msr_gpr()),
+                                         true) )
+        {
+        case X86EMUL_OKAY:
+            update_guest_eip(); /* Safe: UWRMSR */
+            break;
+
+        case X86EMUL_EXCEPTION:
+            hvm_inject_hw_exception(X86_EXC_GP, 0);
+            break;
+        }
+        break;
+
     case EXIT_REASON_VMXOFF:
     case EXIT_REASON_VMXON:
     case EXIT_REASON_VMCLEAR:
--- a/xen/arch/x86/include/asm/hvm/vmx/vmx.h
+++ b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
@@ -203,6 +203,8 @@ static inline void pi_clear_sn(struct pi
 #define EXIT_REASON_NOTIFY              75
 #define EXIT_REASON_RDMSRLIST           78
 #define EXIT_REASON_WRMSRLIST           79
+#define EXIT_REASON_URDMSR              80
+#define EXIT_REASON_UWRMSR              81
 /* Remember to also update VMX_PERF_EXIT_REASON_SIZE! */
 
 /*
@@ -577,8 +579,18 @@ typedef union ldt_or_tr_instr_info {
         base_reg_invalid        :1,  /* bit 27 - Base register invalid */
         instr_identity          :1,  /* bit 28 - 0:LDT, 1:TR */
         instr_write             :1,  /* bit 29 - 0:store, 1:load */
-                                :34; /* bits 31:63 - Undefined */
+                                :34; /* bits 30:63 - Undefined */
     };
 } ldt_or_tr_instr_info_t;
 
+/* VM-Exit instruction info for URDMSR and UWRMSR */
+typedef union user_msr_instr_info {
+    unsigned long raw;
+    struct {
+        unsigned int            :3,  /* Bits 0:2 - Undefined */
+        gpr                     :4,  /* Bits 3:6 - Source/Destination register */
+                                :25; /* bits 7:31 - Undefined */
+    };
+} user_msr_instr_info_t;
+
 #endif /* __ASM_X86_HVM_VMX_VMX_H__ */
--- a/xen/arch/x86/include/asm/msr.h
+++ b/xen/arch/x86/include/asm/msr.h
@@ -277,6 +277,20 @@ uint64_t msr_spec_ctrl_valid_bits(const
 struct vcpu_msrs
 {
     /*
+     * 0x0000001c - MSR_USER_MSR_CTL
+     *
+     * Value is guest chosen, and always loaded in vcpu context.
+     */
+    union {
+        uint64_t raw;
+        struct {
+            bool enable:1;
+            unsigned int :11;
+            unsigned long bitmap:52;
+        };
+    } user_msr_ctl;
+
+    /*
      * 0x00000048 - MSR_SPEC_CTRL
      * 0xc001011f - MSR_VIRT_SPEC_CTRL (if X86_FEATURE_AMD_SSBD)
      *
--- a/xen/arch/x86/include/asm/perfc_defn.h
+++ b/xen/arch/x86/include/asm/perfc_defn.h
@@ -6,7 +6,7 @@ PERFCOUNTER_ARRAY(exceptions,
 
 #ifdef CONFIG_HVM
 
-#define VMX_PERF_EXIT_REASON_SIZE 80
+#define VMX_PERF_EXIT_REASON_SIZE 82
 #define VMEXIT_NPF_PERFC 143
 #define SVM_PERF_EXIT_REASON_SIZE (VMEXIT_NPF_PERFC + 1)
 PERFCOUNTER_ARRAY(vmexits,              "vmexits",
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -279,6 +279,12 @@ int guest_rdmsr(struct vcpu *v, uint32_t
         *val = msrs->xss.raw;
         break;
 
+    case MSR_USER_MSR_CTL:
+        if ( !cp->feat.user_msr )
+            goto gp_fault;
+        *val = msrs->user_msr_ctl.raw;
+        break;
+
     case 0x40000000 ... 0x400001ff:
         if ( is_viridian_domain(d) )
         {
@@ -617,6 +623,19 @@ int guest_wrmsr(struct vcpu *v, uint32_t
         msrs->xss.raw = val;
         break;
 
+    case MSR_USER_MSR_CTL:
+        if ( !cp->feat.user_msr )
+            goto gp_fault;
+
+        if ( (val & ~(USER_MSR_ENABLE | USER_MSR_ADDR_MASK)) ||
+             !is_canonical_address(val) )
+            goto gp_fault;
+
+        msrs->user_msr_ctl.raw = val;
+        if ( v == curr )
+            wrmsrl(MSR_USER_MSR_CTL, val);
+        break;
+
     case 0x40000000 ... 0x400001ff:
         if ( is_viridian_domain(d) )
         {
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -359,7 +359,7 @@ XEN_CPUFEATURE(AMX_COMPLEX,        15*32
 XEN_CPUFEATURE(AVX_VNNI_INT16,     15*32+10) /*A  AVX-VNNI-INT16 Instructions */
 XEN_CPUFEATURE(UTMR,               15*32+13) /*   User Timer */
 XEN_CPUFEATURE(PREFETCHI,          15*32+14) /*A  PREFETCHIT{0,1} Instructions */
-XEN_CPUFEATURE(USER_MSR,           15*32+15) /*   U{RD,WR}MSR Instructions */
+XEN_CPUFEATURE(USER_MSR,           15*32+15) /*s  U{RD,WR}MSR Instructions */
 XEN_CPUFEATURE(UIRET_UIF,          15*32+17) /*   UIRET updates UIF */
 XEN_CPUFEATURE(CET_SSS,            15*32+18) /*   CET Supervisor Shadow Stacks safe to use */
 XEN_CPUFEATURE(SLSM,               15*32+24) /*   Static Lockstep Mode */



From xen-devel-bounces@lists.xenproject.org Wed Jun 18 07:23:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 07:23:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018893.1395767 (Exim 4.92)
	(envelope-from )
	id 1uRn8R-0002uU-G8; Wed, 18 Jun 2025 07:23:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018893.1395767; Wed, 18 Jun 2025 07:23: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 1uRn8R-0002uN-D7; Wed, 18 Jun 2025 07:23:03 +0000
Received: by outflank-mailman (input) for mailman id 1018893;
 Wed, 18 Jun 2025 07:23:02 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uRn8Q-0002sv-9E
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 07:23:02 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uRn8N-007mqs-1C;
 Wed, 18 Jun 2025 07:22:59 +0000
Received: from [2a02:8012:3a1:0:64b5:81ad:1f26:5fcb]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uRn8M-009Mon-3C;
 Wed, 18 Jun 2025 07: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" 
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=8aFOdicdhZSYQpw8utsqP6kBFkP/wqBVhk2/BY88tMI=; b=OPCOmKJNTV92h5stRF2dQSJ9/8
	SuCs0Iglw+CoI3lfJVu7vv9APX/Nmt1cjPeSRM3qrjQlJPTXjhm1TX7F+CWPgcO2FNwqhKi1W+t8A
	i98MspLXqQ+vGtKVxvxzh8B0PLccasD+q0U71LfVMNaYTk0GWO4GZfdw82oN/bNvVA84=;
Message-ID: <538e4b45-74e7-4992-a9e2-7678756f7612@xen.org>
Date: Wed, 18 Jun 2025 08:22:55 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC
 multi-agent driver
Content-Language: en-GB
To: Stefano Stabellini ,
 Grygorii Strashko 
Cc: Bertrand Marquis ,
 Oleksii Moisieiev ,
 "xen-devel@lists.xenproject.org" ,
 Andrew Cooper ,
 Anthony PERARD , Jan Beulich ,
 Juergen Gross , Michal Orzel ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Volodymyr Babchuk 
References: 
 <318044ae12f13b6b297b3f5fda577a1a6cd143da.1747669845.git.oleksii_moisieiev@epam.com>
 
 <04B1F737-5E6B-47C0-B2B9-74288C68E68A@arm.com>
 <50ff5d2b-bd17-4833-b497-0dda6f75964a@epam.com>
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

On 18/06/2025 00:38, Stefano Stabellini wrote:
> On Thu, 12 Jun 2025, Grygorii Strashko wrote:
>> On 02.06.25 10:17, Bertrand Marquis wrote:
>>>> On the other hand, if we also want to handle the case where the SCMI
>>>> server could be on a separate co-processor, then what this code is doing
>>>> is not sufficient because we also need a dcache flush, in addition to
>>>> the DSB.
>>>>
>>>> Bertrand, can you double-check?
>>>
>>> If we want to handle a case where the memory is accessible to a coprocessor
>>> but there is no cache coherency, we need to flush the dcache definitely.
>>>
>>> Seeing the amount of data here, I do agree with Stefano that it would be a
>>> good
>>> idea to make the provision to flush the data cache in all cases. Even if the
>>> data
>>> is accessed by a secure partition or the firmware coherently, flushing in
>>> all cases
>>> would have very limited performance impact here.
>>>
>>> There is the other solution to have some kind of parameter to say if the
>>> accessor
>>> has coherent cache access but I do not think the performance impact here
>>> would
>>> justify such a complexity.
>>>
>> The SCMI shmem expected to be mapped as MT_NON_CACHEABLE in all cases.

I can't find MT_NON_CACHEABLE anywhere in Xen or Linux. My 
interpretation is that the memory attribute would be normal memory non 
cacheable. However, this doesn't add up with ...

>> The Linux does devm_ioremap() -> ioremap() ->
>> (ARM64)  __ioremap((addr), (size), __pgprot(PROT_DEVICE_nGnRE))

... this line. This is device nGnRE which is a lot more restrictive (for 
instance it doesn't allow unaligned access).

>>
>> There is also note in docs:
>> "+- shmem: shared memory for messages transfer, **Xen page aligned** with
>> mapping``p2m_mmio_direct_nc``."
>>
>> In the case of SCP - the SCMI shmem can be actually be in SRAM.
>>
>> So, are you sure cache manipulations are required here?
> 
> No, if the memory is mapped as uncacheable everywhere then the cache
> manipulations are not needed. However, we probably still need a dsb.
> 
> I understand now why they decided to use __memcpy_fromio in Linux: it is
> not MMIO but they needed a memcpy followed by DSB, so they decided to
> reuse the existing MMIO functions although the buffer is not MMIO.

 From my understanding, memcpy_fromio() is not just a mempcy() + dsb. It 
also guarantees the access will be aligned (this is not guarantee by our 
memcpy()).

Now the question is why does Linux map the region Device nGnRE but we 
are mapping non-cacheable?

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Wed Jun 18 07:29:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 07:29:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018904.1395776 (Exim 4.92)
	(envelope-from )
	id 1uRnE8-0003ro-6V; Wed, 18 Jun 2025 07:28:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018904.1395776; Wed, 18 Jun 2025 07:28:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRnE8-0003rh-3j; Wed, 18 Jun 2025 07:28:56 +0000
Received: by outflank-mailman (input) for mailman id 1018904;
 Wed, 18 Jun 2025 07:28:54 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uRnE6-0003rZ-Sr
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 07:28:54 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uRnE6-007n1S-0e;
 Wed, 18 Jun 2025 07:28:54 +0000
Received: from [2a02:8012:3a1:0:64b5:81ad:1f26:5fcb]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uRnE5-009N5a-37;
 Wed, 18 Jun 2025 07:28: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" 
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=sGZjI4tbZbPBWUj9naF9XCrtdWBwG8WfLSjdxottyYc=; b=YSO8a4yGan0zatsEnxsEgW+26q
	FQuKLLu6M14uK0c/2VcvqxqbUc2Ae1IKiAML9lbCNxqsLltG905mlypAXaE2gyCemJAkCR8nntEJL
	k/lgEHsruBAJ0yts2pEoiuigfUe1F6oBtW/JSCIWenlOvDnygwTCsk/EQ7LTdpIMPspw=;
Message-ID: <13d95459-ea77-46ea-84e4-cccece4cd496@xen.org>
Date: Wed, 18 Jun 2025 08:28:51 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC
 multi-agent driver
Content-Language: en-GB
To: Oleksii Moisieiev ,
 "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Bertrand Marquis , Jan Beulich
 , Juergen Gross ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini ,
 Volodymyr Babchuk ,
 Grygorii Strashko 
References: 
 <318044ae12f13b6b297b3f5fda577a1a6cd143da.1747669845.git.oleksii_moisieiev@epam.com>
From: Julien Grall 
In-Reply-To: <318044ae12f13b6b297b3f5fda577a1a6cd143da.1747669845.git.oleksii_moisieiev@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Oleksii,

On 19/05/2025 16:50, Oleksii Moisieiev wrote:
> This patch introduces SCI driver to support for ARM EL3 Trusted Firmware-A
> (TF-A) which provides SCMI interface with multi-agnet support, as shown

s/multi-agnet/multi-agent/

> below.
> 
>    +-----------------------------------------+
>    |                                         |
>    | EL3 TF-A SCMI                           |
>    +-------+--+-------+--+-------+--+-------++
>    |shmem0 |  |shmem1 |  |shmem2 |  |shmemX |
>    +-----+-+  +---+---+  +--+----+  +---+---+
> smc-id0 |        |         |           |
> agent0  |        |         |           |
>    +-----v--------+---------+-----------+----+
>    |              |         |           |    |
>    |              |         |           |    |
>    +--------------+---------+-----------+----+
>           smc-id1 |  smc-id2|    smc-idX|
>           agent1  |  agent2 |    agentX |
>                   |         |           |
>              +----v---+  +--v-----+  +--v-----+
>              |        |  |        |  |        |
>              | Dom0   |  | Dom1   |  | DomX   |
>              |        |  |        |  |        |
>              |        |  |        |  |        |
>              +--------+  +--------+  +--------+
> 
> The EL3 SCMI multi-agent firmware expected to provide SCMI SMC/HVC shared
> memory transport for every Agent in the system.
> 
> The SCMI Agent transport channel defined by pair:
>   - smc-id: SMC/HVC id used for Doorbell
>   - shmem: shared memory for messages transfer, Xen page aligned,
>   p2m_mmio_direct_nc.

It is not clear why we nention Xen page aligned and p2m_mmio_direct_nc. 
Is this multi-agent protocol tied to Xen?

That said... p2m_mmio_direct_nc is a type used in the stage 2 
page-tables to indicate how we restrict access from the domain.

The resulting memory attribute will be a combination of stage-1 + 
stage-2. In the future, we may decide to use FWB which will allow Xen to 
force a specific memory attribute.

This is also purely internal decision. In the documentation, you should 
spell out the memory attribute that should be used. From the discussion 
on this patch, it is still unclear whether the region should be mapped 
as Device nGnRE or normal memory non-cacheabl.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Wed Jun 18 07:46:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 07:46:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018927.1395808 (Exim 4.92)
	(envelope-from )
	id 1uRnUq-0007RI-O2; Wed, 18 Jun 2025 07:46:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018927.1395808; Wed, 18 Jun 2025 07: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 1uRnUq-0007RB-Jf; Wed, 18 Jun 2025 07:46:12 +0000
Received: by outflank-mailman (input) for mailman id 1018927;
 Wed, 18 Jun 2025 07: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 1uRnUo-0007R3-Qf
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 07:46:10 +0000
Received: from m16.mail.163.com (m16.mail.163.com [117.135.210.4])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id 46fb2dbd-4c18-11f0-b894-0df219b8e170;
 Wed, 18 Jun 2025 09:46:02 +0200 (CEST)
Received: from andyshrk$163.com ( [58.22.7.114] ) by
 ajax-webmail-wmsvr-40-103 (Coremail) ; Wed, 18 Jun 2025 15:45:00 +0800
 (CST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 46fb2dbd-4c18-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com;
	s=s110527; h=Date:From:To:Subject:Content-Type:MIME-Version:
	Message-ID; bh=iJe8xguxUKaxBEIyQgGloMLTQZvG1pmxXtuDZXWFdMk=; b=o
	tcUhR4M2NRRiyHXlBSP8R9EjB3C0gNCiY2j/Cxf6MlBoWrnbQ0HI3uC1XcDDqdep
	Vy64Xqnph6RWZOZtTYws5G+AGfJpvS/TzRfXAxCiSzlanYJAu9SU6UEDzLjNBYpK
	dZf2bxBnrt0BDW3/atNvJflluCtwkq+QKmU7FGQFOc=
X-Originating-IP: [58.22.7.114]
Date: Wed, 18 Jun 2025 15:45:00 +0800 (CST)
From: "Andy Yan" 
To: "Thomas Zimmermann" 
Cc: simona@ffwll.ch, airlied@gmail.com, mripard@kernel.org,
	maarten.lankhorst@linux.intel.com, geert@linux-m68k.org,
	tomi.valkeinen@ideasonboard.com, dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org, freedreno@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org, imx@lists.linux.dev,
	linux-samsung-soc@vger.kernel.org, nouveau@lists.freedesktop.org,
	virtualization@lists.linux.dev, spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org
Subject: Re:[PATCH v5 02/25] drm/dumb-buffers: Provide helper to set pitch
 and size
X-Priority: 3
X-Mailer: Coremail Webmail Server Version XT5.0.14 build 20240801(9da12a7b)
 Copyright (c) 2002-2025 www.mailtech.cn 163com
In-Reply-To: <20250613090431.127087-3-tzimmermann@suse.de>
References: <20250613090431.127087-1-tzimmermann@suse.de>
 <20250613090431.127087-3-tzimmermann@suse.de>
X-NTES-SC: AL_Qu2eAv6YvU8r5iWeZekfmkcVgOw9UcO5v/Qk3oZXOJF8jC3pxB8AV3NTMGPMwcWDBhmonQiHSjJy8+ZjY5ByWr8wBZ26EkXLbzVmS1V4yXEbfg==
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset=UTF-8
MIME-Version: 1.0
Message-ID: <6d7ec290.6d99.19781ff9696.Coremail.andyshrk@163.com>
X-Coremail-Locale: zh_CN
X-CM-TRANSID:ZygvCgD3n4h8blJoNyQfAA--.23669W
X-CM-SenderInfo: 5dqg52xkunqiywtou0bp/xtbB0hNwXmhSbBhBTgABsv
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==

CkhpLCAKCkF0IDIwMjUtMDYtMTMgMTc6MDA6MjEsICJUaG9tYXMgWmltbWVybWFubiIgPHR6aW1t
ZXJtYW5uQHN1c2UuZGU+IHdyb3RlOgo+QWRkIGRybV9tb2Rlc19zaXplX2R1bWIoKSwgYSBoZWxw
ZXIgdG8gY2FsY3VsYXRlIHRoZSBkdW1iLWJ1ZmZlcgo+c2NhbmxpbmUgcGl0Y2ggYW5kIGFsbG9j
YXRpb24gc2l6ZS4gSW1wbGVtZW50YXRpb25zIG9mIHN0cnVjdAo+ZHJtX2RyaXZlci5kdW1iX2Ny
ZWF0ZSBjYW4gY2FsbCB0aGUgbmV3IGhlbHBlciBmb3IgdGhlaXIgc2l6ZQo+Y29tcHV0YXRpb25z
Lgo+Cj5UaGVyZSBpcyBjdXJyZW50bHkgcXVpdGUgYSBiaXQgb2YgY29kZSBkdXBsaWNhdGlvbiBh
bW9uZyBEUk0ncwo+bWVtb3J5IG1hbmFnZXJzLiBFYWNoIGNhbGN1bGF0ZXMgc2NhbmxpbmUgcGl0
Y2ggYW5kIGJ1ZmZlciBzaXplCj5mcm9tIHRoZSBnaXZlbiBhcmd1bWVudHMsIGJ1dCB0aGUgaW1w
bGVtZW50YXRpb25zIGFyZSBpbmNvbnNpc3RlbnQKPmluIGhvdyB0aGV5IHRyZWF0IGFsaWdubWVu
dCBhbmQgZm9ybWF0IHN1cHBvcnQuIExhdGVyIHBhdGNoZXMgd2lsbAo+dW5pZnkgdGhpcyBjb2Rl
IG9uIHRvcCBvZiBkcm1fbW9kZV9zaXplX2R1bWIoKSBhcyBtdWNoIGFzIHBvc3NpYmxlLgo+Cj5k
cm1fbW9kZV9zaXplX2R1bWIoKSB1c2VzIGV4aXN0aW5nIDRDQyBmb3JtYXQgaGVscGVycyB0byBp
bnRlcnByZXQKPnRoZSBnaXZlbiBjb2xvciBtb2RlLiBUaGlzIG1ha2VzIHRoZSBkdW1iLWJ1ZmZl
ciBpbnRlcmZhY2UgYmVoYXZlCj5zaW1pbGFyIHRoZSBrZXJuZWwncyB2aWRlbz0gcGFyYW1ldGVy
LiBDdXJyZW50IHBlci1kcml2ZXIgaW1wbGVtZW50YXRpb25zCj5hZ2FpbiBsaWtlbHkgaGF2ZSBz
dWJ0bGUgZGlmZmVyZW5jZXMgb3IgYnVncyBpbiBob3cgdGhleSBzdXBwb3J0IGNvbG9yCj5tb2Rl
cy4KPgo+VGhlIGR1bWItYnVmZmVyIFVBUEkgaXMgb25seSBzcGVjaWZpZWQgZm9yIGtub3duIGNv
bG9yIG1vZGVzLiBUaGVzZQo+dmFsdWVzIGRlc2NyaWJlIGxpbmVhciwgc2luZ2xlLXBsYW5lIFJH
QiBjb2xvciBmb3JtYXRzIG9yIGxlZ2FjeSBpbmRleAo+Zm9ybWF0cy4gT3RoZXIgdmFsdWVzIHNo
b3VsZCBub3QgYmUgc3BlY2lmaWVkLiBCdXQgc29tZSB1c2VyIHNwYWNlCj5zdGlsbCBkb2VzLiBT
byBmb3IgdW5rbm93biBjb2xvciBtb2RlcywgdGhlcmUgYXJlIGEgbnVtYmVyIG9mIGtub3duCj5l
eGNlcHRpb25zIGZvciB3aGljaCBkcm1fbW9kZV9zaXplX2R1bWIoKSBjYWxjdWxhdGVzIHRoZSBw
aXRjaCBmcm9tCj50aGUgYnBwIHZhbHVlLCBhcyBiZWZvcmUuIEFsbCBvdGhlciB2YWx1ZXMgd29y
ayB0aGUgc2FtZSBidXQgcHJpbnQKPmFuIGVycm9yLgo+Cj52NToKPi0gY2hlY2sgZm9yIG92ZXJm
bG93cyB3aXRoIGNoZWNrX211bF9vdmVyZmxvdygpIChUb21pKQo+djQ6Cj4tIHVzZSAldSBjb252
ZXJzaW9uIHNwZWNpZmllciAoR2VlcnQpCj4tIGxpc3QgRFJNX0ZPUk1BVF9EbiBpbiBVQVBJIGRv
Y3MgKEdlZXJ0KQo+LSBhdm9pZCBkbWVzZyBzcGFtbWluZyB3aXRoIGRybV93YXJuX29uY2UoKSAo
U2ltYSkKPi0gYWRkIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgYnBwIHNwZWNpYWwgY2FzZSAoU2lt
YSkKPi0gY2xhcmlmeSBwYXJhbWV0ZXJzIGZvciBoYXJkd2FyZSBhbGlnbm1lbnQKPi0gYWRkIGEg
VE9ETyBpdGVtIGZvciBEVU1CX0NSRUFURTIKPnYzOgo+LSBkb2N1bWVudCB0aGUgVUFQSSBzZW1h
bnRpY3MKPi0gY29tcHV0ZSBzY2FubGluZSBwaXRjaCBmcm9tIGZvciB1bmtub3duIGNvbG9yIG1v
ZGVzIChBbmR5LCBUb21pKQo+Cj5TaWduZWQtb2ZmLWJ5OiBUaG9tYXMgWmltbWVybWFubiA8dHpp
bW1lcm1hbm5Ac3VzZS5kZT4KPlJldmlld2VkLWJ5OiBUb21pIFZhbGtlaW5lbiA8dG9taS52YWxr
ZWluZW5AaWRlYXNvbmJvYXJkLmNvbT4KICBSZXZpZXdlZC1ieTogQW5keSBZYW4gPGFuZHlzaHJr
QDE2My5jb20+Cgo+LS0tCj4gRG9jdW1lbnRhdGlvbi9ncHUvdG9kby5yc3QgICAgICAgICB8ICAy
NyArKysrKysKPiBkcml2ZXJzL2dwdS9kcm0vZHJtX2R1bWJfYnVmZmVycy5jIHwgMTMwICsrKysr
KysrKysrKysrKysrKysrKysrKysrKysrCj4gaW5jbHVkZS9kcm0vZHJtX2R1bWJfYnVmZmVycy5o
ICAgICB8ICAxNCArKysrCj4gaW5jbHVkZS91YXBpL2RybS9kcm1fbW9kZS5oICAgICAgICB8ICA1
MCArKysrKysrKysrLQo+IDQgZmlsZXMgY2hhbmdlZCwgMjIwIGluc2VydGlvbnMoKyksIDEgZGVs
ZXRpb24oLSkKPiBjcmVhdGUgbW9kZSAxMDA2NDQgaW5jbHVkZS9kcm0vZHJtX2R1bWJfYnVmZmVy
cy5oCj4KPmRpZmYgLS1naXQgYS9Eb2N1bWVudGF0aW9uL2dwdS90b2RvLnJzdCBiL0RvY3VtZW50
YXRpb24vZ3B1L3RvZG8ucnN0Cj5pbmRleCBiZTg2MzdkYTNmZTkuLmY3MzEyYWZhODdiNSAxMDA2
NDQKPi0tLSBhL0RvY3VtZW50YXRpb24vZ3B1L3RvZG8ucnN0Cj4rKysgYi9Eb2N1bWVudGF0aW9u
L2dwdS90b2RvLnJzdAo+QEAgLTY0OCw2ICs2NDgsMzMgQEAgQ29udGFjdDogVGhvbWFzIFppbW1l
cm1hbm4gPHR6aW1tZXJtYW5uQHN1c2UuZGU+LCBTaW1vbmEgVmV0dGVyCj4gCj4gTGV2ZWw6IEFk
dmFuY2VkCj4gCj4rSW1wbGVtZW50IGEgbmV3IERVTUJfQ1JFQVRFMiBpb2N0bAo+Ky0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPisKPitUaGUgY3VycmVudCBEVU1CX0NSRUFURSBp
b2N0bCBpcyBub3Qgd2VsbCBkZWZpbmVkLiBJbnN0ZWFkIG9mIGEgcGl4ZWwgYW5kCj4rZnJhbWVi
dWZmZXIgZm9ybWF0LCBpdCBvbmx5IGFjY2VwdHMgYSBjb2xvciBtb2RlIG9mIHZhZ3VlIHNlbWFu
dGljcy4gQXNzdW1pbmcKPithIGxpbmVhciBmcmFtZWJ1ZmZlciwgdGhlIGNvbG9yIG1vZGUgZ2l2
ZXMgYW5kIGlkZWEgb2YgdGhlIHN1cHBvcnRlZCBwaXhlbAo+K2Zvcm1hdC4gQnV0IHVzZXJzcGFj
ZSBlZmZlY3RpdmVseSBoYXMgdG8gZ3Vlc3MgdGhlIGNvcnJlY3QgdmFsdWVzLiBJdCByZWFsbHkK
Pitvbmx5IHdvcmtzIHJlbGlhYmxlIHdpdGggZnJhbWVidWZmZXJzIGluIFhSR0I4ODg4LiBVc2Vy
c3BhY2UgaGFzIGJlZ3VuIHRvCj4rd29ya2Fyb3VuZCB0aGVzZSBsaW1pdGF0aW9ucyBieSBjb21w
dXRpbmcgYXJiaXRyYXJ5IGZvcm1hdCdzIGJ1ZmZlciBzaXplcyBhbmQKPitjYWxjdWxhdGluZyB0
aGVpciBzaXplcyBpbiB0ZXJtcyBvZiBYUkdCODg4OCBwaXhlbHMuCj4rCj4rT25lIHBvc3NpYmxl
IHNvbHV0aW9uIGlzIGEgbmV3IGlvY3RsIERVTUJfQ1JFQVRFMi4gSXQgc2hvdWxkIGFjY2VwdCBh
IERSTQo+K2Zvcm1hdCBhbmQgYSBmb3JtYXQgbW9kaWZpZXIgdG8gcmVzb2x2ZSB0aGUgY29sb3Ig
bW9kZSdzIGFtYmlndWl0eS4gQXMKPitmcmFtZWJ1ZmZlcnMgY2FuIGJlIG11bHRpLXBsYW5hciwg
dGhlIG5ldyBpb2N0bCBoYXMgdG8gcmV0dXJuIHRoZSBidWZmZXIgc2l6ZSwKPitwaXRjaCBhbmQg
R0VNIGhhbmRsZSBmb3IgZWFjaCBpbmRpdmlkdWFsIGNvbG9yIHBsYW5lLgo+Kwo+K0luIHRoZSBm
aXJzdCBzdGVwLCB0aGUgbmV3IGlvY3RsIGNhbiBiZSBsaW1pdGVkIHRvIHRoZSBjdXJyZW50IGZl
YXR1cmVzIG9mCj4rdGhlIGV4aXN0aW5nIERVTUJfQ1JFQVRFLiBJbmRpdmlkdWFsIGRyaXZlcnMg
Y2FuIHRoZW4gYmUgZXh0ZW5kZWQgdG8gc3VwcG9ydAo+K211bHRpLXBsYW5hciBmb3JtYXRzLiBS
b2NrY2hpcCBtaWdodCByZXF1aXJlIHRoaXMgYW5kIHdvdWxkIGJlIGEgZ29vZCBjYW5kaWRhdGUu
Cj4rCj4rSW4gYWRkaXRpb24gdG8gdGhlIGtlcm5lbCBpbXBsZW1lbnRhdGlvbiwgdGhlcmUgbXVz
dCBiZSB1c2VyLXNwYWNlIHN1cHBvcnQKPitmb3IgdGhlIG5ldyBpb2N0bC4gVGhlcmUncyBjb2Rl
IGluIE1lc2EgdGhhdCBtaWdodCBiZSBhYmxlIHRvIHVzZSB0aGUgbmV3Cj4rY2FsbC4KPisKPitD
b250YWN0OiBUaG9tYXMgWmltbWVybWFubiA8dHppbW1lcm1hbm5Ac3VzZS5kZT4KPisKPitMZXZl
bDogQWR2YW5jZWQKPiAKPiBCZXR0ZXIgVGVzdGluZwo+ID09PT09PT09PT09PT09Cj5kaWZmIC0t
Z2l0IGEvZHJpdmVycy9ncHUvZHJtL2RybV9kdW1iX2J1ZmZlcnMuYyBiL2RyaXZlcnMvZ3B1L2Ry
bS9kcm1fZHVtYl9idWZmZXJzLmMKPmluZGV4IDk5MTZhYWY1YjNmMi4uZTllZWQ5YTViNzYwIDEw
MDY0NAo+LS0tIGEvZHJpdmVycy9ncHUvZHJtL2RybV9kdW1iX2J1ZmZlcnMuYwo+KysrIGIvZHJp
dmVycy9ncHUvZHJtL2RybV9kdW1iX2J1ZmZlcnMuYwo+QEAgLTI1LDYgKzI1LDggQEAKPiAKPiAj
aW5jbHVkZSA8ZHJtL2RybV9kZXZpY2UuaD4KPiAjaW5jbHVkZSA8ZHJtL2RybV9kcnYuaD4KPisj
aW5jbHVkZSA8ZHJtL2RybV9kdW1iX2J1ZmZlcnMuaD4KPisjaW5jbHVkZSA8ZHJtL2RybV9mb3Vy
Y2MuaD4KPiAjaW5jbHVkZSA8ZHJtL2RybV9nZW0uaD4KPiAjaW5jbHVkZSA8ZHJtL2RybV9tb2Rl
Lmg+Cj4gCj5AQCAtNTcsNiArNTksMTM0IEBACj4gICogYSBoYXJkd2FyZS1zcGVjaWZpYyBpb2N0
bCB0byBhbGxvY2F0ZSBzdWl0YWJsZSBidWZmZXIgb2JqZWN0cy4KPiAgKi8KPiAKPitzdGF0aWMg
aW50IGRybV9tb2RlX2FsaWduX2R1bWIoc3RydWN0IGRybV9tb2RlX2NyZWF0ZV9kdW1iICphcmdz
LAo+KwkJCSAgICAgICB1bnNpZ25lZCBsb25nIGh3X3BpdGNoX2FsaWduLAo+KwkJCSAgICAgICB1
bnNpZ25lZCBsb25nIGh3X3NpemVfYWxpZ24pCj4rewo+Kwl1MzIgcGl0Y2ggPSBhcmdzLT5waXRj
aDsKPisJdTMyIHNpemU7Cj4rCj4rCWlmICghcGl0Y2gpCj4rCQlyZXR1cm4gLUVJTlZBTDsKPisK
PisJaWYgKGh3X3BpdGNoX2FsaWduKQo+KwkJcGl0Y2ggPSByb3VuZHVwKHBpdGNoLCBod19waXRj
aF9hbGlnbik7Cj4rCj4rCWlmICghaHdfc2l6ZV9hbGlnbikKPisJCWh3X3NpemVfYWxpZ24gPSBQ
QUdFX1NJWkU7Cj4rCWVsc2UgaWYgKCFJU19BTElHTkVEKGh3X3NpemVfYWxpZ24sIFBBR0VfU0la
RSkpCj4rCQlyZXR1cm4gLUVJTlZBTDsgLyogVE9ETzogaGFuZGxlIHRoaXMgaWYgbmVjZXNzYXJ5
ICovCj4rCj4rCWlmIChjaGVja19tdWxfb3ZlcmZsb3coYXJncy0+aGVpZ2h0LCBwaXRjaCwgJnNp
emUpKQo+KwkJcmV0dXJuIC1FSU5WQUw7Cj4rCXNpemUgPSBBTElHTihzaXplLCBod19zaXplX2Fs
aWduKTsKPisJaWYgKCFzaXplKQo+KwkJcmV0dXJuIC1FSU5WQUw7Cj4rCj4rCWFyZ3MtPnBpdGNo
ID0gcGl0Y2g7Cj4rCWFyZ3MtPnNpemUgPSBzaXplOwo+Kwo+KwlyZXR1cm4gMDsKPit9Cj4rCj4r
LyoqCj4rICogZHJtX21vZGVfc2l6ZV9kdW1iIC0gQ2FsY3VsYXRlcyB0aGUgc2NhbmxpbmUgYW5k
IGJ1ZmZlciBzaXplcyBmb3IgZHVtYiBidWZmZXJzCj4rICogQGRldjogRFJNIGRldmljZQo+KyAq
IEBhcmdzOiBQYXJhbWV0ZXJzIGZvciB0aGUgZHVtYiBidWZmZXIKPisgKiBAaHdfcGl0Y2hfYWxp
Z246IEhhcmR3YXJlIHNjYW5saW5lIGFsaWdubWVudCBpbiBieXRlcwo+KyAqIEBod19zaXplX2Fs
aWduOiBIYXJkd2FyZSBidWZmZXItc2l6ZSBhbGlnbm1lbnQgaW4gYnl0ZXMKPisgKgo+KyAqIFRo
ZSBoZWxwZXIgZHJtX21vZGVfc2l6ZV9kdW1iKCkgY2FsY3VsYXRlcyB0aGUgc2l6ZSBvZiB0aGUg
YnVmZmVyCj4rICogYWxsb2NhdGlvbiBhbmQgdGhlIHNjYW5saW5lIHNpemUgZm9yIGEgZHVtYiBi
dWZmZXIuIENhbGxlcnMgaGF2ZSB0bwo+KyAqIHNldCB0aGUgYnVmZmVycyB3aWR0aCwgaGVpZ2h0
IGFuZCBjb2xvciBtb2RlIGluIHRoZSBhcmd1bWVudCBAYXJnLgo+KyAqIFRoZSBoZWxwZXIgdmFs
aWRhdGVzIHRoZSBjb3JyZWN0bmVzcyBvZiB0aGUgaW5wdXQgYW5kIHRlc3RzIGZvcgo+KyAqIHBv
c3NpYmxlIG92ZXJmbG93cy4gSWYgc3VjY2Vzc2Z1bCwgaXQgcmV0dXJucyB0aGUgZHVtYiBidWZm
ZXIncwo+KyAqIHJlcXVpcmVkIHNjYW5saW5lIHBpdGNoIGFuZCBzaXplIGluICZhcmdzLgo+KyAq
Cj4rICogVGhlIHBhcmFtZXRlciBAaHdfcGl0Y2hfYWxpZ24gYWxsb3dzIHRoZSBkcml2ZXIgdG8g
c3BlY2lmaWVzIGFuCj4rICogYWxpZ25tZW50IGZvciB0aGUgc2NhbmxpbmUgcGl0Y2gsIGlmIHRo
ZSBoYXJkd2FyZSByZXF1aXJlcyBhbnkuIFRoZQo+KyAqIGNhbGN1bGF0ZWQgcGl0Y2ggd2lsbCBi
ZSBhIG11bHRpcGxlIG9mIHRoZSBhbGlnbm1lbnQuIFRoZSBwYXJhbWV0ZXIKPisgKiBAaHdfc2l6
ZV9hbGlnbiBhbGxvd3MgdG8gc3BlY2lmeSBhbiBhbGlnbm1lbnQgZm9yIGJ1ZmZlciBzaXplcy4g
VGhlCj4rICogcHJvdmlkZWQgYWxpZ25tZW50IHNob3VsZCByZXByZXNlbnQgcmVxdWlyZW1lbnRz
IG9mIHRoZSBncmFwaGljcwo+KyAqIGhhcmR3YXJlLiBkcm1fbW9kZV9zaXplX2R1bWIoKSBoYW5k
bGVzIEdFTS1yZWxhdGVkIGNvbnN0cmFpbnRzCj4rICogYXV0b21hdGljYWxseSBhY3Jvc3MgYWxs
IGRyaXZlcnMgYW5kIGhhcmR3YXJlLiBGb3IgZXhhbXBsZSwgdGhlCj4rICogcmV0dXJuZWQgYnVm
ZmVyIHNpemUgaXMgYWx3YXlzIGEgbXVsdGlwbGUgb2YgUEFHRV9TSVpFLCB3aGljaCBpcwo+KyAq
IHJlcXVpcmVkIGJ5IG1tYXAoKS4KPisgKgo+KyAqIFJldHVybnM6Cj4rICogWmVybyBvbiBzdWNj
ZXNzLCBvciBhIG5lZ2F0aXZlIGVycm9yIGNvZGUgb3RoZXJ3aXNlLgo+KyAqLwo+K2ludCBkcm1f
bW9kZV9zaXplX2R1bWIoc3RydWN0IGRybV9kZXZpY2UgKmRldiwKPisJCSAgICAgICBzdHJ1Y3Qg
ZHJtX21vZGVfY3JlYXRlX2R1bWIgKmFyZ3MsCj4rCQkgICAgICAgdW5zaWduZWQgbG9uZyBod19w
aXRjaF9hbGlnbiwKPisJCSAgICAgICB1bnNpZ25lZCBsb25nIGh3X3NpemVfYWxpZ24pCj4rewo+
Kwl1NjQgcGl0Y2ggPSAwOwo+Kwl1MzIgZm91cmNjOwo+Kwo+KwkvKgo+KwkgKiBUaGUgc2Nhbmxp
bmUgcGl0Y2ggZGVwZW5kcyBvbiB0aGUgYnVmZmVyIHdpZHRoIGFuZCB0aGUgY29sb3IKPisJICog
Zm9ybWF0LiBUaGUgbGF0dGVyIGlzIHNwZWNpZmllZCBhcyBhIGNvbG9yLW1vZGUgY29uc3RhbnQg
Zm9yCj4rCSAqIHdoaWNoIHdlIGZpcnN0IGhhdmUgdG8gZmluZCB0aGUgY29ycmVzcG9uZGluZyBj
b2xvciBmb3JtYXQuCj4rCSAqCj4rCSAqIERpZmZlcmVudCBjb2xvciBmb3JtYXRzIGNhbiBoYXZl
IHRoZSBzYW1lIGNvbG9yLW1vZGUgY29uc3RhbnQuCj4rCSAqIEZvciBleGFtcGxlIFhSR0I4ODg4
IGFuZCBCR1JYODg4OCBib3RoIGhhdmUgYSBjb2xvciBtb2RlIG9mIDMyLgo+KwkgKiBJdCBpcyBw
b3NzaWJsZSB0byB1c2UgZGlmZmVyZW50IGZvcm1hdHMgZm9yIGR1bWItYnVmZmVyIGFsbG9jYXRp
b24KPisJICogYW5kIHJlbmRlcmluZyBhcyBsb25nIGFzIGFsbCBpbnZvbHZlZCBmb3JtYXRzIHNo
YXJlIHRoZSBzYW1lCj4rCSAqIGNvbG9yLW1vZGUgY29uc3RhbnQuCj4rCSAqLwo+Kwlmb3VyY2Mg
PSBkcm1fZHJpdmVyX2NvbG9yX21vZGVfZm9ybWF0KGRldiwgYXJncy0+YnBwKTsKPisJaWYgKGZv
dXJjYyAhPSBEUk1fRk9STUFUX0lOVkFMSUQpIHsKPisJCWNvbnN0IHN0cnVjdCBkcm1fZm9ybWF0
X2luZm8gKmluZm8gPSBkcm1fZm9ybWF0X2luZm8oZm91cmNjKTsKPisKPisJCWlmICghaW5mbykK
PisJCQlyZXR1cm4gLUVJTlZBTDsKPisJCXBpdGNoID0gZHJtX2Zvcm1hdF9pbmZvX21pbl9waXRj
aChpbmZvLCAwLCBhcmdzLT53aWR0aCk7Cj4rCX0gZWxzZSBpZiAoYXJncy0+YnBwKSB7Cj4rCQkv
Kgo+KwkJICogU29tZSB1c2Vyc3BhY2UgdGhyb3dzIGluIGFyYml0cmFyeSB2YWx1ZXMgZm9yIGJw
cCBhbmQKPisJCSAqIHJlbGllcyBvbiB0aGUga2VybmVsIHRvIGZpZ3VyZSBpdCBvdXQuIEluIHRo
aXMgY2FzZSB3ZQo+KwkJICogZmFsbCBiYWNrIHRvIHRoZSBvbGQgbWV0aG9kIG9mIHVzaW5nIGJw
cCBkaXJlY3RseS4gVGhlCj4rCQkgKiBvdmVyLWNvbW1pdG1lbnQgb2YgbWVtb3J5IGZyb20gdGhl
IHJvdW5kaW5nIGlzIGFjY2VwdGFibGUKPisJCSAqIGZvciBjb21wYXRpYmlsaXR5IHdpdGggbGVn
YWN5IHVzZXJzcGFjZS4gV2UgaGF2ZSBhIG51bWJlcgo+KwkJICogb2YgZGVwcmVjYXRlZCBsZWdh
Y3kgdmFsdWVzIHRoYXQgYXJlIGV4cGxpY2l0bHkgc3VwcG9ydGVkLgo+KwkJICovCj4rCQlzd2l0
Y2ggKGFyZ3MtPmJwcCkgewo+KwkJZGVmYXVsdDoKPisJCQlkcm1fd2Fybl9vbmNlKGRldiwKPisJ
CQkJICAgICAgIlVua25vd24gY29sb3IgbW9kZSAldTsgZ3Vlc3NpbmcgYnVmZmVyIHNpemUuXG4i
LAo+KwkJCQkgICAgICBhcmdzLT5icHApOwo+KwkJCWZhbGx0aHJvdWdoOwo+KwkJLyoKPisJCSAq
IFRoZXNlIGNvbnN0YW50cyByZXByZXNlbnQgdmFyaW91cyBZVVYgZm9ybWF0cyBzdXBwb3J0ZWQg
YnkKPisJCSAqIGRybV9nZW1fYWZiY19nZXRfYnBwKCkuCj4rCQkgKi8KPisJCWNhc2UgMTI6IC8v
IERSTV9GT1JNQVRfWVVWNDIwXzhCSVQKPisJCWNhc2UgMTU6IC8vIERSTV9GT1JNQVRfWVVWNDIw
XzEwQklUCj4rCQljYXNlIDMwOiAvLyBEUk1fRk9STUFUX1ZVWTEwMTAxMAo+KwkJCWZhbGx0aHJv
dWdoOwo+KwkJLyoKPisJCSAqIFVzZWQgYnkgTWVzYSBhbmQgR3N0cmVhbWVyIHRvIGFsbG9jYXRl
IE5WIGZvcm1hdHMgYW5kIG90aGVycwo+KwkJICogYXMgUkdCIGJ1ZmZlcnMuIFRlY2huaWNhbGx5
LCBYUkdCMTYxNjE2MTZGIGZvcm1hdHMgYXJlIFJHQiwKPisJCSAqIGJ1dCB0aGUgZHVtYiBidWZm
ZXJzIGFyZSBub3Qgc3VwcG9zZWQgdG8gYmUgdXNlZCBmb3IgYW55dGhpbmcKPisJCSAqIGJleW9u
ZCAzMiBiaXRzIHBlciBwaXhlbHMuCj4rCQkgKi8KPisJCWNhc2UgMTA6IC8vIERSTV9GT1JNQVRf
TlZ7MTUsMjAsMzB9LCBEUk1fRk9STUFUX1AwMTAKPisJCWNhc2UgNjQ6IC8vIERSTV9GT1JNQVRf
e1hSR0IsWEJHUixBUkdCLEFCR1J9MTYxNjE2MTZGCj4rCQkJcGl0Y2ggPSBhcmdzLT53aWR0aCAq
IERJVl9ST1VORF9VUChhcmdzLT5icHAsIFNaXzgpOwo+KwkJCWJyZWFrOwo+KwkJfQo+Kwl9Cj4r
Cj4rCWlmICghcGl0Y2ggfHwgcGl0Y2ggPiBVMzJfTUFYKQo+KwkJcmV0dXJuIC1FSU5WQUw7Cj4r
Cj4rCWFyZ3MtPnBpdGNoID0gcGl0Y2g7Cj4rCj4rCXJldHVybiBkcm1fbW9kZV9hbGlnbl9kdW1i
KGFyZ3MsIGh3X3BpdGNoX2FsaWduLCBod19zaXplX2FsaWduKTsKPit9Cj4rRVhQT1JUX1NZTUJP
TChkcm1fbW9kZV9zaXplX2R1bWIpOwo+Kwo+IGludCBkcm1fbW9kZV9jcmVhdGVfZHVtYihzdHJ1
Y3QgZHJtX2RldmljZSAqZGV2LAo+IAkJCSBzdHJ1Y3QgZHJtX21vZGVfY3JlYXRlX2R1bWIgKmFy
Z3MsCj4gCQkJIHN0cnVjdCBkcm1fZmlsZSAqZmlsZV9wcml2KQo+ZGlmZiAtLWdpdCBhL2luY2x1
ZGUvZHJtL2RybV9kdW1iX2J1ZmZlcnMuaCBiL2luY2x1ZGUvZHJtL2RybV9kdW1iX2J1ZmZlcnMu
aAo+bmV3IGZpbGUgbW9kZSAxMDA2NDQKPmluZGV4IDAwMDAwMDAwMDAwMC4uMWYzYTgyMzZmYjNk
Cj4tLS0gL2Rldi9udWxsCj4rKysgYi9pbmNsdWRlL2RybS9kcm1fZHVtYl9idWZmZXJzLmgKPkBA
IC0wLDAgKzEsMTQgQEAKPisvKiBTUERYLUxpY2Vuc2UtSWRlbnRpZmllcjogTUlUICovCj4rCj4r
I2lmbmRlZiBfX0RSTV9EVU1CX0JVRkZFUlNfSF9fCj4rI2RlZmluZSBfX0RSTV9EVU1CX0JVRkZF
UlNfSF9fCj4rCj4rc3RydWN0IGRybV9kZXZpY2U7Cj4rc3RydWN0IGRybV9tb2RlX2NyZWF0ZV9k
dW1iOwo+Kwo+K2ludCBkcm1fbW9kZV9zaXplX2R1bWIoc3RydWN0IGRybV9kZXZpY2UgKmRldiwK
PisJCSAgICAgICBzdHJ1Y3QgZHJtX21vZGVfY3JlYXRlX2R1bWIgKmFyZ3MsCj4rCQkgICAgICAg
dW5zaWduZWQgbG9uZyBod19waXRjaF9hbGlnbiwKPisJCSAgICAgICB1bnNpZ25lZCBsb25nIGh3
X3NpemVfYWxpZ24pOwo+Kwo+KyNlbmRpZgo+ZGlmZiAtLWdpdCBhL2luY2x1ZGUvdWFwaS9kcm0v
ZHJtX21vZGUuaCBiL2luY2x1ZGUvdWFwaS9kcm0vZHJtX21vZGUuaAo+aW5kZXggYzA4MjgxMGMw
OGE4Li5lZmU4ZjVhZDM1ZWUgMTAwNjQ0Cj4tLS0gYS9pbmNsdWRlL3VhcGkvZHJtL2RybV9tb2Rl
LmgKPisrKyBiL2luY2x1ZGUvdWFwaS9kcm0vZHJtX21vZGUuaAo+QEAgLTEwNTgsNyArMTA1OCw3
IEBAIHN0cnVjdCBkcm1fbW9kZV9jcnRjX3BhZ2VfZmxpcF90YXJnZXQgewo+ICAqIHN0cnVjdCBk
cm1fbW9kZV9jcmVhdGVfZHVtYiAtIENyZWF0ZSBhIEtNUyBkdW1iIGJ1ZmZlciBmb3Igc2Nhbm91
dC4KPiAgKiBAaGVpZ2h0OiBidWZmZXIgaGVpZ2h0IGluIHBpeGVscwo+ICAqIEB3aWR0aDogYnVm
ZmVyIHdpZHRoIGluIHBpeGVscwo+LSAqIEBicHA6IGJpdHMgcGVyIHBpeGVsCj4rICogQGJwcDog
Y29sb3IgbW9kZQo+ICAqIEBmbGFnczogbXVzdCBiZSB6ZXJvCj4gICogQGhhbmRsZTogYnVmZmVy
IG9iamVjdCBoYW5kbGUKPiAgKiBAcGl0Y2g6IG51bWJlciBvZiBieXRlcyBiZXR3ZWVuIHR3byBj
b25zZWN1dGl2ZSBsaW5lcwo+QEAgLTEwNjYsNiArMTA2Niw1NCBAQCBzdHJ1Y3QgZHJtX21vZGVf
Y3J0Y19wYWdlX2ZsaXBfdGFyZ2V0IHsKPiAgKgo+ICAqIFVzZXItc3BhY2UgZmlsbHMgQGhlaWdo
dCwgQHdpZHRoLCBAYnBwIGFuZCBAZmxhZ3MuIElmIHRoZSBJT0NUTCBzdWNjZWVkcywKPiAgKiB0
aGUga2VybmVsIGZpbGxzIEBoYW5kbGUsIEBwaXRjaCBhbmQgQHNpemUuCj4rICoKPisgKiBUaGUg
dmFsdWUgb2YgQGJwcCBpcyBhIGNvbG9yLW1vZGUgbnVtYmVyIGRlc2NyaWJpbmcgYSBzcGVjaWZp
YyBmb3JtYXQKPisgKiBvciBhIHZhcmlhbnQgdGhlcmVvZi4gVGhlIHZhbHVlIG9mdGVuIGNvcnJl
c3BvbmRzIHRvIHRoZSBudW1iZXIgb2YgYml0cwo+KyAqIHBlciBwaXhlbCBmb3IgbW9zdCBtb2Rl
cywgYWx0aG91Z2ggdGhlcmUgYXJlIGV4Y2VwdGlvbnMuIEVhY2ggY29sb3IgbW9kZQo+KyAqIG1h
cHMgdG8gYSBEUk0gZm9ybWF0IHBsdXMgYSBudW1iZXIgb2YgbW9kZXMgd2l0aCBzaW1pbGFyIHBp
eGVsIGxheW91dC4KPisgKiBGcmFtZWJ1ZmZlciBsYXlvdXQgaXMgYWx3YXlzIGxpbmVhci4KPisg
Kgo+KyAqIFN1cHBvcnQgZm9yIGFsbCBtb2RlcyBhbmQgZm9ybWF0cyBpcyBvcHRpb25hbC4gRXZl
biBpZiBkdW1iLWJ1ZmZlcgo+KyAqIGNyZWF0aW9uIHdpdGggYSBjZXJ0YWluIGNvbG9yIG1vZGUg
c3VjY2VlZHMsIGl0IGlzIG5vdCBndWFyYW50ZWVkIHRoYXQKPisgKiB0aGUgRFJNIGRyaXZlciBz
dXBwb3J0cyBhbnkgb2YgdGhlIHJlbGF0ZWQgZm9ybWF0cy4gTW9zdCBkcml2ZXJzIHN1cHBvcnQK
PisgKiBhIGNvbG9yIG1vZGUgb2YgMzIgd2l0aCBhIGZvcm1hdCBvZiBEUk1fRk9STUFUX1hSR0I4
ODg4IG9uIHRoZWlyIHByaW1hcnkKPisgKiBwbGFuZS4KPisgKgo+KyAqICstLS0tLS0tLS0tLS0r
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKPisgKiB8
IENvbG9yIG1vZGUgfCBGcmFtZWJ1ZmZlciBmb3JtYXQgICAgIHwgQ29tcGF0aWJsZSBmb3JtYXRz
ICAgICB8Cj4rICogKz09PT09PT09PT09PSs9PT09PT09PT09PT09PT09PT09PT09PT0rPT09PT09
PT09PT09PT09PT09PT09PT09Kwo+KyAqIHwgICAgIDMyICAgICB8ICAqIERSTV9GT1JNQVRfWFJH
Qjg4ODggfCAgKiBEUk1fRk9STUFUX0JHUlg4ODg4IHwKPisgKiB8ICAgICAgICAgICAgfCAgICAg
ICAgICAgICAgICAgICAgICAgIHwgICogRFJNX0ZPUk1BVF9SR0JYODg4OCB8Cj4rICogfCAgICAg
ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8ICAqIERSTV9GT1JNQVRfWEJHUjg4ODgg
fAo+KyAqICstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLSsKPisgKiB8ICAgICAyNCAgICAgfCAgKiBEUk1fRk9STUFUX1JHQjg4OCAg
IHwgICogRFJNX0ZPUk1BVF9CR1I4ODggICB8Cj4rICogKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwo+KyAqIHwgICAgIDE2ICAg
ICB8ICAqIERSTV9GT1JNQVRfUkdCNTY1ICAgfCAgKiBEUk1fRk9STUFUX0JHUjU2NSAgIHwKPisg
KiArLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0rCj4rICogfCAgICAgMTUgICAgIHwgICogRFJNX0ZPUk1BVF9YUkdCMTU1NSB8ICAq
IERSTV9GT1JNQVRfQkdSWDE1NTUgfAo+KyAqIHwgICAgICAgICAgICB8ICAgICAgICAgICAgICAg
ICAgICAgICAgfCAgKiBEUk1fRk9STUFUX1JHQlgxNTU1IHwKPisgKiB8ICAgICAgICAgICAgfCAg
ICAgICAgICAgICAgICAgICAgICAgIHwgICogRFJNX0ZPUk1BVF9YQkdSMTU1NSB8Cj4rICogKy0t
LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tKwo+KyAqIHwgICAgICA4ICAgICB8ICAqIERSTV9GT1JNQVRfQzggICAgICAgfCAgKiBEUk1f
Rk9STUFUX0Q4ICAgICAgIHwKPisgKiB8ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg
ICAgIHwgICogRFJNX0ZPUk1BVF9SOCAgICAgICB8Cj4rICogKy0tLS0tLS0tLS0tLSstLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwo+KyAqIHwgICAgICA0
ICAgICB8ICAqIERSTV9GT1JNQVRfQzQgICAgICAgfCAgKiBEUk1fRk9STUFUX0Q0ICAgICAgIHwK
PisgKiB8ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHwgICogRFJNX0ZPUk1B
VF9SNCAgICAgICB8Cj4rICogKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwo+KyAqIHwgICAgICAyICAgICB8ICAqIERSTV9GT1JN
QVRfQzIgICAgICAgfCAgKiBEUk1fRk9STUFUX0QyICAgICAgIHwKPisgKiB8ICAgICAgICAgICAg
fCAgICAgICAgICAgICAgICAgICAgICAgIHwgICogRFJNX0ZPUk1BVF9SMiAgICAgICB8Cj4rICog
Ky0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tKwo+KyAqIHwgICAgICAxICAgICB8ICAqIERSTV9GT1JNQVRfQzEgICAgICAgfCAgKiBE
Uk1fRk9STUFUX0QxICAgICAgIHwKPisgKiB8ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg
ICAgICAgIHwgICogRFJNX0ZPUk1BVF9SMSAgICAgICB8Cj4rICogKy0tLS0tLS0tLS0tLSstLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwo+KyAqCj4rICog
Q29sb3IgbW9kZXMgb2YgMTAsIDEyLCAxNSwgMzAgYW5kIDY0IGFyZSBvbmx5IHN1cHBvcnRlZCBm
b3IgdXNlIGJ5Cj4rICogbGVnYWN5IHVzZXIgc3BhY2UuIFBsZWFzZSBkb24ndCB1c2UgdGhlbSBp
biBuZXcgY29kZS4gT3RoZXIgbW9kZXMKPisgKiBhcmUgbm90IHN1cHBvcnQuCj4rICoKPisgKiBE
byBub3QgYXR0ZW1wdCB0byBhbGxvY2F0ZSBhbnl0aGluZyBidXQgbGluZWFyIGZyYW1lYnVmZmVy
IG1lbW9yeQo+KyAqIHdpdGggc2luZ2xlLXBsYW5lIFJHQiBkYXRhLiBBbGxvY2F0aW9uIG9mIG90
aGVyIGZyYW1lYnVmZmVyCj4rICogbGF5b3V0cyByZXF1aXJlcyBkZWRpY2F0ZWQgaW9jdGxzIGlu
IHRoZSByZXNwZWN0aXZlIERSTSBkcml2ZXIuCj4gICovCj4gc3RydWN0IGRybV9tb2RlX2NyZWF0
ZV9kdW1iIHsKPiAJX191MzIgaGVpZ2h0Owo+LS0gCj4yLjQ5LjAKPgo+Cj5fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+TGludXgtcm9ja2NoaXAgbWFpbGlu
ZyBsaXN0Cj5MaW51eC1yb2NrY2hpcEBsaXN0cy5pbmZyYWRlYWQub3JnCj5odHRwOi8vbGlzdHMu
aW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LXJvY2tjaGlwCg==


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 07:47:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 07:47:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018935.1395817 (Exim 4.92)
	(envelope-from )
	id 1uRnWB-0007vz-Vo; Wed, 18 Jun 2025 07:47:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018935.1395817; Wed, 18 Jun 2025 07:47: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 1uRnWB-0007vs-Sn; Wed, 18 Jun 2025 07:47:35 +0000
Received: by outflank-mailman (input) for mailman id 1018935;
 Wed, 18 Jun 2025 07:47:34 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uRnWA-0007vk-Fh
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 07:47:34 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uRnWA-007naI-0B;
 Wed, 18 Jun 2025 07:47:34 +0000
Received: from [2a02:8012:3a1:0:64b5:81ad:1f26:5fcb]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uRnW9-009OPT-2i;
 Wed, 18 Jun 2025 07:47: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=VQ1ipKEYHpcMR4+lWNrV1w8Do8BanX2kgmPmoEm/3cc=; b=u+Sl56rqiPF1EstNQFHMOD7Cr0
	Ask6DRXjuV7kd52ebv9QVSNtDDpUBko+eV5t+TKcMPddWQ7uJkCCpt1ZY7jM97v7zRSBfz6LVCV/H
	CfYu+HqIWcOYhPFXWRxjNFT2I9kjhqRn2SrKfjPVA06CRPYa/pksJQC4xNsP5+P3fKJA=;
Message-ID: <7d47a2bc-3313-4d42-8b47-bfc2de1356ff@xen.org>
Date: Wed, 18 Jun 2025 08:47:32 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen/dt: Remove loop in dt_read_number()
Content-Language: en-GB
To: "Orzel, Michal" ,
 Alejandro Vallejo , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis 
References: <20250617171358.670642-1-agarciav@amd.com>
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Michal,

On 18/06/2025 08:06, Orzel, Michal wrote:
> 
> 
> On 17/06/2025 19:13, Alejandro Vallejo wrote:
>> The DT spec declares only two number types for a property: u32 and u64,
>> as per Table 2.3 in Section 2.2.4. Remove unbounded loop and replace
>> with a switch statement. Default to a size of 1 cell in the nonsensical
>> size case, with a warning printed on the Xen console.
>>
>> Suggested-by: Daniel P. Smith" 
>> Signed-off-by: Alejandro Vallejo 
>> ---
>> v2:
>>    * Added missing `break` on the `case 2:` branch and added ASSERT_UNREACHABLE() to the deafult path
>> ---
>>   xen/include/xen/device_tree.h | 17 ++++++++++++++---
>>   1 file changed, 14 insertions(+), 3 deletions(-)
>>
>> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
>> index 75017e4266..2ec668b94a 100644
>> --- a/xen/include/xen/device_tree.h
>> +++ b/xen/include/xen/device_tree.h
>> @@ -261,10 +261,21 @@ void intc_dt_preinit(void);
>>   /* Helper to read a big number; size is in cells (not bytes) */
>>   static inline u64 dt_read_number(const __be32 *cell, int size)
>>   {
>> -    u64 r = 0;
>> +    u64 r = be32_to_cpu(*cell);
>> +
>> +    switch ( size )
>> +    {
>> +    case 1:
>> +        break;
>> +    case 2:
>> +        r = (r << 32) | be32_to_cpu(cell[1]);
>> +        break;
>> +    default:
>> +        // Nonsensical size. default to 1.
> I wonder why there are so many examples of device trees in Linux with
> #address-cells = <3>? Also, libfdt defines FDT_MAX_NCELLS as 4 with comment:
> "maximum value for #address-cells and #size-cells" but I guess it follows the
> IEE1275 standard and DT spec "is loosely related" to it.

A lot of the use seems to be related to PCI. Below an example from [1]:

     pcie {
         #address-cells = <3>;
         #size-cells = <2>;

         pcie@0 {
             device_type = "pci";
             reg = <0x0 0x0 0x0 0x0 0x0>;
             #address-cells = <3>;
             #size-cells = <2>;
             ranges;

             wifi@0 {
                 compatible = "pci17cb,1109";
                 reg = <0x0 0x0 0x0 0x0 0x0>;

                 qcom,calibration-variant = "RDP433_1";

                 ports {
                     #address-cells = <1>;
                     #size-cells = <0>;

                     port@0 {
                         reg = <0>;

                         wifi1_wsi_tx: endpoint {
                             remote-endpoint = <&wifi2_wsi_rx>;
                         };
                     };

                     port@1 {
                         reg = <1>;

                         wifi1_wsi_rx: endpoint {
                             remote-endpoint = <&wifi3_wsi_tx>;
                         };
                     };
                 };
             };
         };

"reg" has effectively 5 cells (3 for address and 2 for size).

 From a very brief look, I couldn't find how this is interpreted. But I 
don't see how dt_read_number() can be used in this case. So I think it 
makes sense to restrict. The question though is whether it is a good 
idea to cap the value and behave differently from Linux.

Speaking of which there are another fun different behavior between Linux 
and Xen in DT. The default size of the root #address is 2 in Xen (see 
DT_ROOT_NODE_ADDR_CELLS_DEFAULT) which is spec compliant. But Linux will 
use 1 (see OF_ROOT_NODE_ADDR_CELLS_DEFAULT). I haven't seen any issue so 
far, but only notice recently when working on a separate project 
recently. I am still undecided for this one whether Xen should change 
because technically a Device-Tree should nowadays always provide 
#address-cells and #size-cells.

Cheers,

[1] devicetree/bindings/net/wireless/qcom,ath12k-wsi.yaml

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Wed Jun 18 08:29:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 08:29:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018971.1395846 (Exim 4.92)
	(envelope-from )
	id 1uRoAD-00062a-Cc; Wed, 18 Jun 2025 08:28:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018971.1395846; Wed, 18 Jun 2025 08: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 1uRoAD-00062T-9k; Wed, 18 Jun 2025 08:28:57 +0000
Received: by outflank-mailman (input) for mailman id 1018971;
 Wed, 18 Jun 2025 08:28: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 1uRoAB-00062N-To
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 08:28:55 +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 4463e883-4c1e-11f0-a30a-13f23c93f187;
 Wed, 18 Jun 2025 10:28:54 +0200 (CEST)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-60780d74c85so10100435a12.2
 for ; Wed, 18 Jun 2025 01:28:53 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2365e0cffffsm93944795ad.248.2025.06.18.01.22.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Jun 2025 01:22:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4463e883-4c1e-11f0-a30a-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750235332; x=1750840132; 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=xpxvw8i+JRCZShJeI1r+FrzPafAxEdWvg0TDgLnUWD0=;
        b=CrwqbWJwizWAyMRn/PzSw0kZeEsect12tHjwUpBXW9Y3uYCcp7UME1N264VLoAbbbU
         gVVBsMgQikZ/qRruOB2VRNt7LsZjZkXGyrbbKrJ60T+XsKOX6bH7t0W52aOMFNRewmPF
         PAejzH5fCo7l/lcXLpxzoD0MiWf9INmsG568h94JbsxGThACWLcYo+ScpVEoqS9ir4cl
         2pbqUsPNKzpFmaGBAaq+k6I/7OCiQAqjREA4xIKiUYvkEPlLwrGhYW5dG4vAE+DUS3rI
         YYImPJ4CBH5/GgSl2k2RBA2kXpQ8BaVqAcaF+ksqU8Z+d6qG6iiKPdhuOvNhv/bSJWsF
         nGhQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750235332; x=1750840132;
        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=xpxvw8i+JRCZShJeI1r+FrzPafAxEdWvg0TDgLnUWD0=;
        b=LhIYeXu4O0xzWk00NpvDndREx7esbgBI1TPPg/3ClzMdoyjCL2V7RWcE/hjPByppt8
         Nq1tkpsM5vPcKzg72438tHY52x8SP96m4fyTMqfly84RvKDu4Qx3+dQG9PWso3zG97+g
         0LbKdSGRT9xX8sSH223mdoI+rNMZsmRrIeT80mVTBnXAMm3g4Ny/GpuIZW6/KJRUyP/F
         b4EJBc+1KImRUeqiYR4uVvIHX8515P3b/iJAS4IYndfORXTVqiJX0VCyCe8U899VnWs1
         8rOOfAHGQ4jqbNNDxtl1jSaFJOep24db1GEi81f+P77jbMF0hvMA/T05ALUrDUgJMKHV
         GWYQ==
X-Gm-Message-State: AOJu0Yznta/wc5yXQaFNhlXobdJv4jxWyrf2yBWtgIroWEwPP168oAjJ
	Zk7uyrrhRMC6H/cIqiRJO7PD7Vx29E4EfdowdIHNonSy7eAyrN9+mrQ9M/yqFkVM3p2LF3iuwIh
	BL/0=
X-Gm-Gg: ASbGncueYdNrUpHYseG0mifgZoz8TvTLuGGXA/pPAb58qe4yLDoQxaXYUbuyOIW6v1G
	bcpi8s3HHNZxWXbAyVWWCWeC4WZh8zipF+VIqqQmKGBlZcYHgE9xJ99h/O62INRgtseA/b6ODn/
	dVjfuQLb9mLVist7GiteRe0gEbkCORfqrBi4yt3ZA9j4DkclhhBLzQ64d6LZzNLoBB/7nhixiON
	XPl1hpPCJenSGR6zP5J7X7rjZL8uXj5FdLqr3wwpr5t0LfCr5d3tpKe1bm3fVXX3LeFknsYXiS9
	2otZMjJSrUjAkwI6WC9OCj1biy+TSyOcfyQ9d4iBihiNGO/DqhVx0GDMwbpiD4Jg445JSSM7C52
	l4qrtdEbZJftwKA339IkXq6L+8uz1wNfpv4GcvNm05wv26ZetMGAZaVZD6Q==
X-Google-Smtp-Source: AGHT+IH3AZ2OPnAfPra3LUaK/1dD6GEEVvepeivu8b7/ZzQci5mAFN6jhgJmYgFwnbVBx5yKtY1BlA==
X-Received: by 2002:a5d:64ce:0:b0:3a4:f513:7f03 with SMTP id ffacd0b85a97d-3a572e8bfb1mr12246224f8f.44.1750234962175;
        Wed, 18 Jun 2025 01:22:42 -0700 (PDT)
Message-ID: 
Date: Wed, 18 Jun 2025 10:22:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini ,
 Anthony PERARD ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 
From: Jan Beulich 
Subject: [PATCH] xen/build: pass -fzero-init-padding-bits=all to gcc15
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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

See the respective bullet point in the Caveats section of
https://gcc.gnu.org/gcc-15/changes.html.

While I'm unaware of us currently relying on the pre-gcc15 behavior,
let's still play safe and retain what unknowingly we may have been
relying upon.

According to my observations, on x86 generated code changes
- somewhere deep in modify_bars(), presumably from the struct map_data
  initializer in apply_map() (a new MOVQ),
- in vpci_process_pending(), apparently again from the struct map_data
  initializer (and again a new MOVQ),
- near the top of find_cpio_data(), presumably from the struct cpio_data
  initializer (a MOVW changing to a MOVQ).

Requested-by: Andrew Cooper 
Signed-off-by: Jan Beulich 
---
apply_map() being inlined is kind of against our intentions, seeing that
it's marked __init. Should we add noinline there? After all post-init
this is effectively unreachable code, which Misra opposes to.

--- a/xen/Makefile
+++ b/xen/Makefile
@@ -396,6 +396,7 @@ endif
 CFLAGS-$(CONFIG_CC_SPLIT_SECTIONS) += -ffunction-sections -fdata-sections
 
 CFLAGS += -nostdinc -fno-builtin -fno-common
+$(call cc-option-add,CFLAGS,CC,-fzero-init-padding-bits=all)
 CFLAGS += -Werror -Wredundant-decls -Wwrite-strings -Wno-pointer-arith
 CFLAGS += -Wdeclaration-after-statement -Wuninitialized
 $(call cc-option-add,CFLAGS,CC,-Wvla)


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 09:13:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 09:13:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1018980.1395860 (Exim 4.92)
	(envelope-from )
	id 1uRorH-0003um-Gu; Wed, 18 Jun 2025 09:13:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1018980.1395860; Wed, 18 Jun 2025 09:13: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 1uRorH-0003uf-EJ; Wed, 18 Jun 2025 09:13:27 +0000
Received: by outflank-mailman (input) for mailman id 1018980;
 Wed, 18 Jun 2025 09:13: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 1uRorF-0003uZ-He
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 09:13:25 +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 7c03e442-4c24-11f0-a30a-13f23c93f187;
 Wed, 18 Jun 2025 11:13:23 +0200 (CEST)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-adb2bb25105so1133818466b.0
 for ; Wed, 18 Jun 2025 02:13:23 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-adec8982f4esm1037154766b.176.2025.06.18.02.13.20
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 18 Jun 2025 02:13:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7c03e442-4c24-11f0-a30a-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750238002; x=1750842802; 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=SimK3Vzm4oopunXcaB2KG1naXZ0rung4wUt4Ht0KGxk=;
        b=L3o50coiDgKqya0gaoswyG3te/PQHDCOfdu0x7txPRQXOkjVkLUkjVDC/V6tkQJn9q
         SS8wiPfE1Jl0R/xeaPyI8HckOYhXqhBtcfTsGShGpxPXhKlJ3T4S3eT2d6CsP+9wKRsR
         fGXz7/eWM6cprCzJ6OXb1iCPJ2ug3031c1jFoON+t5cNKBI6ef6TAZ/1wwODlKC9Tl91
         yVDtgZzv/ylnfEv/ud909uwTgzGB92fXMnH7uEvVeGWX/hCLKoBsyntA6/e9O1YfxTqV
         dNka/TEPbQSc++yD0Au/xiumz+eTh7cJQrbVTo0kRV6E40ftWQBomVknwDijDatlpAjC
         +XtA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750238002; x=1750842802;
        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=SimK3Vzm4oopunXcaB2KG1naXZ0rung4wUt4Ht0KGxk=;
        b=KgYUN3hsiG0HRu1+4W0/wyj0VLcXYWvEy/HB9MILjbE7AxMPf94NZRdPtg/RL4tkN6
         rRRBRax6qtUkMEhKsLnW4v8bi2MEzztHJaf3/UOv82n51UcKc85dC9sCmvhC7NmqoT30
         iKO5XndZ9NYGKmTxmfaIvBxHyp9CZE0p2FJsF62097aA3FQaco3a7ld+2mmoo6dL7OS8
         Iow8lAYCVWLfaAy1XQuB9uvTjzCDLHfarRM995zaTGiHHheM1vRMmYuB/KtqS/vmw1qa
         4oiZNrheutkWuMgqoTipqLkA5w8H1r8aRM5n0nGcW2PIHP3fMupAz8K3X2tSSNd/an1L
         m11A==
X-Gm-Message-State: AOJu0YxZhM4Q5ZTJBogP4vOwtYZSDuUstg6c74bSOU+aQ5D4LIBkF6j4
	lgJpa6Ey5F68mjJs8HpAxjDXvtltrTOHE+QHozLRqQ8OhuM9rQwNOs8I+R8Ngw==
X-Gm-Gg: ASbGncuL7IPhTsQNi1Bf9zXZz738PAIqTdvP0O41DYm/cMSxnEstBq2CdOy2xIOUMok
	83NNjdlq8+4KrpayZU/XQMW5P2nEHE2SruSPTaIGaCl5nzn66g2GjryzWuRqWiy+MUEVbROs6Dw
	BK6eHLi142ouy+bB9CFDfTgUFaNJyYaZXSsDc+SO0pbpu+4J5Allr+JHBO9WADAcPmSqTR0mVIY
	Qq/n37khfgWbdoIFU+TCNEAXmBZRELrOy2FVrxPjYG2BP9gtfIlA4x1bajrnlUh++eqprZ4FFyo
	iK6IKr0DctzlPAruBsmamCEypNXlOfbQ4XTAhLtDGWFL97WvtZ0sPjVl3Rfbgiuj8IbXlFb1lX8
	MdKn23XZ704UgMPTcZso16aAqsP/c
X-Google-Smtp-Source: AGHT+IFdMBkSD1M9vseqf9WvEBR79tIc3p05InTdbTzOF7W1VRUmTy/CA32y9BgsSVUHZtr50zKO2w==
X-Received: by 2002:a17:906:4fd5:b0:ad8:8efe:3205 with SMTP id a640c23a62f3a-adfad4f585fmr1196891066b.55.1750238002216;
        Wed, 18 Jun 2025 02:13:22 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	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 v1] xen: move __ro_after_init section symbols to xen/sections.h
Date: Wed, 18 Jun 2025 11:13:16 +0200
Message-ID: <1254ad9fd9f9fefc71ff8a5f5d23f5037d854943.1750237599.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Instead of declaring __ro_after_init_{start,end} in each architecture's
asm/setup.h, move these declarations to the common header xen/sections.h.

This centralizes the declarations and reduces duplication across
architectures.

No functional change intended.

Signed-off-by: Oleksii Kurochko 
---
CI tests:
  https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/1875993985  
---
 xen/arch/arm/include/asm/setup.h | 2 --
 xen/arch/x86/include/asm/setup.h | 1 -
 xen/include/xen/sections.h       | 3 +++
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
index 2b58549c1a..b199d92a42 100644
--- a/xen/arch/arm/include/asm/setup.h
+++ b/xen/arch/arm/include/asm/setup.h
@@ -65,8 +65,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 const char __ro_after_init_start[], __ro_after_init_end[];
-
 struct init_info
 {
     /* Pointer to the stack, used by head.S when entering in C */
diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/asm/setup.h
index ac34c69855..b01e83a8ed 100644
--- a/xen/arch/x86/include/asm/setup.h
+++ b/xen/arch/x86/include/asm/setup.h
@@ -5,7 +5,6 @@
 #include 
 
 extern const char __2M_text_start[], __2M_text_end[];
-extern const char __ro_after_init_start[], __ro_after_init_end[];
 extern const char __2M_rodata_start[], __2M_rodata_end[];
 extern char __2M_init_start[], __2M_init_end[];
 extern char __2M_rwdata_start[], __2M_rwdata_end[];
diff --git a/xen/include/xen/sections.h b/xen/include/xen/sections.h
index fe49d7d0e6..cd542bfe10 100644
--- a/xen/include/xen/sections.h
+++ b/xen/include/xen/sections.h
@@ -5,6 +5,9 @@
 
 #include 
 
+/* SAF-0-safe */
+extern const char __ro_after_init_start[], __ro_after_init_end[];
+
 /* SAF-0-safe */
 extern char __init_begin[], __init_end[];
 #define is_init_section(p) ({                           \
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed Jun 18 09:41:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 09:41:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019005.1395871 (Exim 4.92)
	(envelope-from )
	id 1uRpIG-0007qQ-LK; Wed, 18 Jun 2025 09:41:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019005.1395871; Wed, 18 Jun 2025 09:41:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRpIG-0007qJ-Hr; Wed, 18 Jun 2025 09:41:20 +0000
Received: by outflank-mailman (input) for mailman id 1019005;
 Wed, 18 Jun 2025 09:41: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 1uRpIF-0007qD-MZ
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 09:41:19 +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 5af4a96b-4c28-11f0-b894-0df219b8e170;
 Wed, 18 Jun 2025 11:41:05 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3a4e742dc97so343231f8f.0
 for ; Wed, 18 Jun 2025 02:41:05 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-748e61679c5sm1211984b3a.84.2025.06.18.02.40.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Jun 2025 02:41:04 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5af4a96b-4c28-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750239665; x=1750844465; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=SV7QTOB9IB/5KYixPXUSsCr0q60ZGrKFcI3Mfs64WIU=;
        b=dr1sqdiN0qhZ6kFmO55MuU3HvGBIr1fZ037mjhwUQdWXZ0fDgRhJeEy7cLkA2aMnUQ
         a1w08szNzYILmFbdCDAM9NKITgqON6Ljg7MzS52dS+l1GhQxx9xLVmRiIyGop0aggJ6p
         VQjjjamQbRWiFASFV0H+SGJ/T3NRCzD5zmpolwAw+3igL01BNH4dll4D/DQx1DTiFFpS
         pFkyEBj899Vnvei1flAIHKWhilhYJdOIS7rPfwAxWy85aep5yW5e9beAS264oIKiUaPb
         Jv4TpCLX18ywcSEtife9eXPX2qUbiNfJU1uOnOqkjKZ+mnyNt4MwEfVFz0/cdSqLsHO7
         cZ4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750239665; x=1750844465;
        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=SV7QTOB9IB/5KYixPXUSsCr0q60ZGrKFcI3Mfs64WIU=;
        b=o2GwwLSIkUAIAlNCEiWTnlFQiJzxC+dILIXVtdf/hSy9gzTXrT0eG+0sbL5YZ9w3YO
         oA7x/DXvz4k0KY8HC2yG+jI6wncpLvRqU0RIBKhyHVqJqy+WHwY3LrISSuc9gD7rdFfo
         NUlxaIyggEKNXZXk/KPzr/jJZ+WhA2A4xu55bn5qgAmWA4o6V7CSPUyrYiplH/ykMxe+
         msQJq8DH+jrimAMC6kRg69iwafGd89NT5B4udy55gRBLOdA7AAmfaQjc2LxMjCi91GJA
         CPcJy25spVOY0y6quAq52FO+X2PpIqZ6yh3zUb2kzpKsL6AmZdw9bOlckqQ5eTw9VX2T
         G4GA==
X-Forwarded-Encrypted: i=1; AJvYcCUh0JefXOi4w0gJaEEb73SSQLJLlPdSOpTGR07k85jhWvsfKxp+YnrhP+8FIsFbrxC6GyZR78LPEKk=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw6kKHoxTgMy++JHExynOt/QJ99vDG/tcB5XYPhJYbrxxNFVKoG
	9ZMpMYREr2V55oVJOnaMR62Nbb7Df5XRNm/P213CT48MURjvJDfSrdovKjb1BD3QKg==
X-Gm-Gg: ASbGncuye8GPLn2ispVHeaQPzWgiRA8luJpMddNOqjfTEAQ9uUkzn74q+Xn/jkHeTSH
	XTFEMrXt1YCi3Gb78dPXDFyBgLUgMIt36zlXLn8sRxo+NfrhqHoMejozJuF4aqZSto/HybRIdQv
	g+wKNqLvjOnJc7DxKAcxTgyfsrnI81Dw/faiNFj0ZtyJkXLU7KXDjbzfFINt9jVt3NQbRVKUqTM
	CVT2rEw3KmROxklD+UOVIzXVpLzKa7NGEBjCnjSMWhDKDcqVHMZvGoMk1tN4c2u8FOAM7XMbx+W
	BRDdA32Kk45nYQv9W7c155J5w8NWO2e6F1sH7jretFqgnRYkame+/iizE3tjDhp18Nat46x7xnE
	VegiB2MftipuCi61ntDQKOq5Vm+S7F+3VP0WEIAq/PATFxKI=
X-Google-Smtp-Source: AGHT+IEv/QrVTUnBd251BQDLimQBRKSx7cOjgm22JinTb5IdAD0WAuipPE9l7D+vG2I+bvNQa5hZqA==
X-Received: by 2002:a05:6000:2881:b0:3a4:d685:3de7 with SMTP id ffacd0b85a97d-3a58e14562amr1472982f8f.8.1750239665219;
        Wed, 18 Jun 2025 02:41:05 -0700 (PDT)
Message-ID: 
Date: Wed, 18 Jun 2025 11:40:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1] xen: move __ro_after_init section symbols to
 xen/sections.h
To: Oleksii Kurochko 
Cc: 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: <1254ad9fd9f9fefc71ff8a5f5d23f5037d854943.1750237599.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: <1254ad9fd9f9fefc71ff8a5f5d23f5037d854943.1750237599.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 18.06.2025 11:13, Oleksii Kurochko wrote:
> Instead of declaring __ro_after_init_{start,end} in each architecture's
> asm/setup.h, move these declarations to the common header xen/sections.h.
> 
> This centralizes the declarations and reduces duplication across
> architectures.
> 
> No functional change intended.
> 
> Signed-off-by: Oleksii Kurochko 

It can probably go in as-is, hence
Acked-by: Jan Beulich 
but ...

> --- a/xen/include/xen/sections.h
> +++ b/xen/include/xen/sections.h
> @@ -5,6 +5,9 @@
>  
>  #include 
>  
> +/* SAF-0-safe */
> +extern const char __ro_after_init_start[], __ro_after_init_end[];
> +
>  /* SAF-0-safe */
>  extern char __init_begin[], __init_end[];
>  #define is_init_section(p) ({                           \

... I generally dislike this pattern of adding to the front, as if the
addition was more important than what's there already. But maybe that's
indeed just me ...

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 10:18:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 10:18:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019028.1395886 (Exim 4.92)
	(envelope-from )
	id 1uRprm-0003Wa-Dd; Wed, 18 Jun 2025 10:18:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019028.1395886; Wed, 18 Jun 2025 10:18:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRprm-0003WT-90; Wed, 18 Jun 2025 10:18:02 +0000
Received: by outflank-mailman (input) for mailman id 1019028;
 Wed, 18 Jun 2025 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 1uRprk-0003WN-Qf
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 10:18:00 +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 81e95848-4c2d-11f0-a30a-13f23c93f187;
 Wed, 18 Jun 2025 12:17:58 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3a57c8e247cso3213940f8f.1
 for ; Wed, 18 Jun 2025 03:17:58 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-313c1c6a80bsm12349266a91.44.2025.06.18.03.17.53
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Jun 2025 03:17:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 81e95848-4c2d-11f0-a30a-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750241878; x=1750846678; 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=lTcj4F18ielqy3N30HxOMFo1QHYtCfKFunvb6xsSaz8=;
        b=f5/zzFb/klmpT8RUZJuHiPJKV/N39T5ph6gLBh4H4gBxRm5WglGvuy25hDTYS6d8pX
         1XBgChNd8MdYzDpo8jN8tZBWs64A/s7s+FFqJ6gprdyzh0QytSBKB2O4Qi+ngoxr6TsJ
         PhQMEKk++NRYF8VZHEYv7hpeOSL0t3QcY3U5I1ywn3KMBSCNQzhAG5Wk44uyuchx4oN2
         X/5e4eKvMWg3+Q0kzh3Wl2jWMTbP6PINZ/YzrPQwqgskTL+sqSvhJzgTz11RrHuTrlhd
         DgKwyGf0SYHLj1ZOmSr5aHkNM0c57Ic979YgVn8jL6byHlI14JdY8hc0KviR9rfrDR2k
         VidA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750241878; x=1750846678;
        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=lTcj4F18ielqy3N30HxOMFo1QHYtCfKFunvb6xsSaz8=;
        b=MZG+O0F08sNR3t+UFlrFDwWKEtlAdd/MHVqsLuPB3sLuRTOM8gE8Do98Tn9sHUphN/
         e7pSDCUkiX9LAhvwg3XCmPPjKjcTUt89xwMJjgSzCURL4zN3gkn5ygY6/eUz+lzqKL+O
         i6aXQahPhyH3wyogCgVDoNKhivYG7uhvt6QanRWiHEPP+WCml5VY8UCbFLP6lmgMSdOn
         3CXomusSHX4g+gMwtyasSSjHWmCOiSblYJlXWMd6T0Qjcri9StBr3cckrxxnWzEfGMq/
         yJ8cMpYWsS6DcwKNyPX1P+JEPsjIzdoGzRs1Idj5o2IozJP4okpVgXIrXVfPWNZN+T6k
         cbKQ==
X-Gm-Message-State: AOJu0Yzv0EpVoyjtlSHirOT5f3B9ksQOzZyiPA+Kqv/EWYnE1mUPzqa3
	5/eIFLDTVFdrNgM9t9TXCHIch1oTrfK8Uf67mYxNk5PS5INzkZJDVXYhNCVcbyPsAv3YH49B6SY
	VYZE=
X-Gm-Gg: ASbGncv+eJx02PsKWP8eVPnB2lhvunJvRVQlqLnr+qZk+OR1R8NKmN6V0lW7Ox6FGhW
	BGvqP/pkjAAeUUYmO45aqLBwIwpnGCM/v56/s9IKn5G3UGOJS+8lVEcR/ejzVfFVzYqbv8gdLfZ
	yFCGyLlqasVjDTg35M50F/UYFezpcywhzH31UtqUO9qGEpcwmt/A1mP4yjmlCHwUxhXZqz8w8Fy
	OqkyQx4sjmEHB6wpRnJ7aYYm+lnvDg5//j/dHbdMMJlgd+SQFIOn5vQ7cJwvKcBQsXRk2V166in
	+z0mWwCY71tx3lSmfLPi95OUIoaCVI7HniZUpEIbrfHZgTXgcaL3gIDyoBDehYu8KUBbd8UdIuv
	186b3Wov6A97PSmHNz/rZ6sqKrlFG9ZMkwZdm12LLwYFYYk4=
X-Google-Smtp-Source: AGHT+IFhpdbRQbB2G+DgsX8ubk6qlIxzd0fwMkTgMBrOdi1huey823h/9o1k8OaXDfEpVJixAdQz/A==
X-Received: by 2002:a05:6000:3112:b0:3a4:e480:b5df with SMTP id ffacd0b85a97d-3a572e79749mr14751450f8f.44.1750241878068;
        Wed, 18 Jun 2025 03:17:58 -0700 (PDT)
Message-ID: <57107b15-affc-43a6-b6f3-6196b40bbc8b@suse.com>
Date: Wed, 18 Jun 2025 12:17:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini ,
 Anthony PERARD ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 
From: Jan Beulich 
Subject: [PATCH] xvmalloc: extend to cover multi-dimensional arrays
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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

Take care of the multiplication(s) involved in determining overall size
in the macros themselves, saturating to ULONG_MAX. This way on 64-bit
systems the subsequent check against UINT_MAX will fail, while on 32-
bit systems allocations of this size simply cannot be fulfilled anyway
(such an allocation would consume the entire address space).

The only place where we truly consume guest input (but constrained to
hwdom) is cpufreq_statistic_init(). Play safe however and convert the
other three instances where a multiplication is involved as well.

While touching those sites also switch to xv*alloc_array(), following
what was settled upon when those were introduced. Don't bother extending
x*alloc_array() the same way.

Reported-by: Andrew Cooper 
Signed-off-by: Jan Beulich 
---
To my surprise code gen even improves a tiny bit for do_memory_op(), in
surrounding code (with gcc14).

--- a/xen/arch/x86/cpu/mcheck/mctelem.c
+++ b/xen/arch/x86/cpu/mcheck/mctelem.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -340,7 +341,7 @@ void __init mctelem_init(unsigned int da
 
 	if ((mctctl.mctc_elems = xmalloc_array(struct mctelem_ent,
 	    MC_NENT)) == NULL ||
-	    (datarr = xmalloc_bytes(MC_NENT * datasz)) == NULL) {
+	    (datarr = xvmalloc_array(char, MC_NENT, datasz)) == NULL) {
 		xfree(mctctl.mctc_elems);
 		printk("Allocations for MCA telemetry failed\n");
 		return;
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -26,6 +26,8 @@
 #include 
 #include 
 #include 
+#include 
+
 #include 
 #include 
 #include 
@@ -160,7 +162,7 @@ void vnuma_destroy(struct vnuma_info *vn
     {
         xfree(vnuma->vmemrange);
         xfree(vnuma->vcpu_to_vnode);
-        xfree(vnuma->vdistance);
+        xvfree(vnuma->vdistance);
         xfree(vnuma->vnode_to_pnode);
         xfree(vnuma);
     }
@@ -197,7 +199,7 @@ static struct vnuma_info *vnuma_alloc(un
     if ( !vnuma )
         return ERR_PTR(-ENOMEM);
 
-    vnuma->vdistance = xmalloc_array(unsigned int, nr_vnodes * nr_vnodes);
+    vnuma->vdistance = xvmalloc_array(unsigned int, nr_vnodes, nr_vnodes);
     vnuma->vcpu_to_vnode = xmalloc_array(unsigned int, nr_vcpus);
     vnuma->vnode_to_pnode = xmalloc_array(nodeid_t, nr_vnodes);
     vnuma->vmemrange = xmalloc_array(xen_vmemrange_t, nr_ranges);
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -26,6 +26,8 @@
 #include 
 #include 
 #include 
+#include 
+
 #include 
 #include 
 #include 
@@ -1750,7 +1752,7 @@ long do_memory_op(unsigned long cmd, XEN
 
         read_unlock(&d->vnuma_rwlock);
 
-        tmp.vdistance = xmalloc_array(unsigned int, dom_vnodes * dom_vnodes);
+        tmp.vdistance = xvmalloc_array(unsigned int, dom_vnodes, dom_vnodes);
         tmp.vmemrange = xmalloc_array(xen_vmemrange_t, dom_vranges);
         tmp.vcpu_to_vnode = xmalloc_array(unsigned int, dom_vcpus);
 
@@ -1813,7 +1815,7 @@ long do_memory_op(unsigned long cmd, XEN
  vnumainfo_out:
         rcu_unlock_domain(d);
 
-        xfree(tmp.vdistance);
+        xvfree(tmp.vdistance);
         xfree(tmp.vmemrange);
         xfree(tmp.vcpu_to_vnode);
         break;
--- a/xen/drivers/acpi/pmstat.c
+++ b/xen/drivers/acpi/pmstat.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -126,7 +127,7 @@ int cpufreq_statistic_init(unsigned int
     }
     per_cpu(cpufreq_statistic_data, cpu) = pxpt;
 
-    pxpt->u.trans_pt = xzalloc_array(uint64_t, count * count);
+    pxpt->u.trans_pt = xvzalloc_array(uint64_t, count, count);
     if ( !pxpt->u.trans_pt )
     {
         xfree(pxpt);
@@ -137,7 +138,7 @@ int cpufreq_statistic_init(unsigned int
     pxpt->u.pt = xzalloc_array(struct pm_px_val, count);
     if ( !pxpt->u.pt )
     {
-        xfree(pxpt->u.trans_pt);
+        xvfree(pxpt->u.trans_pt);
         xfree(pxpt);
         spin_unlock(cpufreq_statistic_lock);
         return -ENOMEM;
@@ -171,7 +172,7 @@ void cpufreq_statistic_exit(unsigned int
         return;
     }
 
-    xfree(pxpt->u.trans_pt);
+    xvfree(pxpt->u.trans_pt);
     xfree(pxpt->u.pt);
     xfree(pxpt);
     per_cpu(cpufreq_statistic_data, cpu) = NULL;
--- a/xen/include/xen/xvmalloc.h
+++ b/xen/include/xen/xvmalloc.h
@@ -22,11 +22,24 @@
     (typeof(*(ptr)) *)p_;                                      \
 })
 
+#define DIM_MUL1(n) (n)
+#define DIM_MUL2(n1, n2) ({                                     \
+    unsigned long res_;                                         \
+    __builtin_umull_overflow(n1, n2, &res_) ? ULONG_MAX : res_; \
+})
+#define DIM_MUL3(n1, n2, n3) DIM_MUL2(DIM_MUL2(n1, n2), n3)
+#define DIM_MUL4(n1, n2, n3, n4) DIM_MUL2(DIM_MUL2(n1, n2), \
+                                          DIM_MUL2(n3, n4))
+#define DIM_MUL_(n, nums...) DIM_MUL##n(nums)
+#define DIM_MUL(n, nums...) DIM_MUL_(n, ## nums)
+
 /* Allocate space for array of typed objects. */
-#define xvmalloc_array(_type, _num) \
-    ((_type *)_xvmalloc_array(sizeof(_type), __alignof__(_type), _num))
-#define xvzalloc_array(_type, _num) \
-    ((_type *)_xvzalloc_array(sizeof(_type), __alignof__(_type), _num))
+#define xvmalloc_array(type, num, nums...) \
+    ((type *)_xvmalloc_array(sizeof(type), __alignof__(type), \
+                             DIM_MUL(count_args(num, ## nums), num, ## nums)))
+#define xvzalloc_array(type, num, nums...) \
+    ((type *)_xvzalloc_array(sizeof(type), __alignof__(type), \
+                             DIM_MUL(count_args(num, ## nums), num, ## nums)))
 
 /* Allocate space for a structure with a flexible array of typed objects. */
 #define xvzalloc_flex_struct(type, field, nr) \


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 10:28:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 10:28:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019039.1395895 (Exim 4.92)
	(envelope-from )
	id 1uRq1d-0005My-Bk; Wed, 18 Jun 2025 10:28:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019039.1395895; Wed, 18 Jun 2025 10:28:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRq1d-0005Mr-8v; Wed, 18 Jun 2025 10:28:13 +0000
Received: by outflank-mailman (input) for mailman id 1019039;
 Wed, 18 Jun 2025 10:28: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 1uRq1b-0005Ml-KZ
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 10:28:11 +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 ede9c377-4c2e-11f0-b894-0df219b8e170;
 Wed, 18 Jun 2025 12:28:09 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a4fea34e07so3825996f8f.1
 for ; Wed, 18 Jun 2025 03:28:09 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2365e0cffe6sm95788225ad.245.2025.06.18.03.28.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Jun 2025 03:28:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ede9c377-4c2e-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750242489; x=1750847289; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=fGeFrsVfOPDpETi8ACldN3VXeYoeBYMm5S1M4SvLJ+w=;
        b=TEGrefr+krZvKFgRXCHD+g3p6FfPn4VYpKEYMf+WadnqsVn/x6pSZsXzBTq9+r/+pE
         WuqGjnAW2s5rasyci+dqC8LE+rgwuPI6jcWmRWk9ulQsaTlgHMYkXpgtqgRjNCF6O4Ui
         lq/iu+VGspIIFDcE5m6Gy/j54GKuXHKrK90xX0Ga5u8hTR4d/oAurlRWJt4UztVO21SK
         xTbHHJFgAkViBOIhdpMR9+yTG92wwRwDjzjBAe8ogAk58NUfUlKcyUmu9SJzq0dKb+bN
         bRuCUPyRdG+rsWRujuwpEp5Uy01rIXzRomqUOS8p61sbmWwkMj9smJBfeOhKcZ9HaGu2
         8AeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750242489; x=1750847289;
        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=fGeFrsVfOPDpETi8ACldN3VXeYoeBYMm5S1M4SvLJ+w=;
        b=T27a7wPnkS9ayJWN/3/p3CTAxtiTOnYKJsCLhiJ6PrUL7fbkGWqqV9wXavvFuqP0TN
         5D17/YOt1RApIQ7EdbUzbHgkWBlHIH4nWMTuNVLdh5jKKfsRecABHpulO4fNNuTg5g7E
         aQ1dODtx7W5Yqvf218JMfoaMBjKTy9QrHxltYv4COtcCMvGsJ1nPINdlFN4ISl8Ng6Xf
         u2OL90Fb+byhyWfANVMxnAXPfXwjgiHNZIVywKXkwwYPOTzgxKssS1Q66Alm02fAiSCg
         +1CennzoS9IlorLItKU75rkcgaleDBKvif1szBLtdrPJ7fQWRh0bBtg42/MWVL4jeEvu
         pzdw==
X-Forwarded-Encrypted: i=1; AJvYcCW5vc11+thnneyo+eFOLjOf5ZVIJk2eDF5Z4HayOPQLb/bAv8V416FWzLKIfeN6C8RWjm+ap2nDPps=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxoRsdgG3WcMeV+jJBor1zhgtv98zYwEBUFWX6FFy6zuPu14HPS
	LmIuLf5R5FE7YWndSo+0BXr/1Rz/t+6d+OE1Rx+X6WRtla2/c5QditBoiR3PEt6oCQ==
X-Gm-Gg: ASbGncsp/i+Bls9XU1omZB0xQObulzpSxuL2rc0zO7ef0WuX2Mq3BbdS6B6qAGOFyB0
	2EftmaygFD32q4pjEPFxOmWHePWWiouNtzfKwuoWqNK4uAGrJUzXkNiv3pRB1WmnFDTKlya9NXP
	QnF1gWrvuUeJ3i5zEsMgtnQoRVwVYWZnuxC6GanGNjYCz73rsbUftJPZ9Idg6TQ7AXNZLhplHXD
	tRWixi5aC2SNoTHcNg1mymh+ky7i8r1oQxoZySe2LG4YGKRyfHQ313R8wcJ1kfW19W7JjX0aNUs
	ll9PEZ6mVXk5XPaXm/OsPpKt4Iuf5jKP/KE88Ntw4Wg1iIopP0oMdXQzQkv+q5oaMv2xuV0o+qf
	LAOGwaYbHJseQz6c7LEOSk19LbCgyWNVNYup/ZlT3u4F/QebWrUuITtQDEQ==
X-Google-Smtp-Source: AGHT+IHcFqHKstTzlqOf8MRwCPVNqzb2i9CCIMgWnpLUPEbBBCt9uXIHtpwwdqe1pENOjjQHvnjQeg==
X-Received: by 2002:a05:6000:4602:b0:3a5:2182:bd11 with SMTP id ffacd0b85a97d-3a572373c13mr15065840f8f.20.1750242488744;
        Wed, 18 Jun 2025 03:28:08 -0700 (PDT)
Message-ID: 
Date: Wed, 18 Jun 2025 12:28:01 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 01/20] xen/pmstat: consolidate code into pmstat.c
To: Penny Zheng 
Cc: ray.huang@amd.com, Stefano Stabellini ,
 xen-devel@lists.xenproject.org
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
 <20250528091708.390767-2-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: <20250528091708.390767-2-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 28.05.2025 11:16, Penny Zheng wrote:
> We move the following functions into drivers/acpi/pmstat.c, as they
> are all designed for performance statistic:
> - cpufreq_residency_update()
> - cpufreq_statistic_reset()
> - cpufreq_statistic_update()
> - cpufreq_statistic_init()
> - cpufreq_statistic_exit()

You say move, but ...

> +int cpufreq_statistic_init(unsigned int cpu)
> +{
> +    unsigned int i, count;
> +    struct pm_px *pxpt;
> +    const struct processor_pminfo *pmpt = processor_pminfo[cpu];
> +    spinlock_t *cpufreq_statistic_lock = &per_cpu(cpufreq_statistic_lock, cpu);
> +
> +    spin_lock_init(cpufreq_statistic_lock);
> +
> +    if ( !pmpt )
> +        return -EINVAL;
> +
> +    spin_lock(cpufreq_statistic_lock);
> +
> +    pxpt = per_cpu(cpufreq_statistic_data, cpu);
> +    if ( pxpt )
> +    {
> +        spin_unlock(cpufreq_statistic_lock);
> +        return 0;
> +    }
> +
> +    count = pmpt->perf.state_count;
> +
> +    pxpt = xzalloc(struct pm_px);
> +    if ( !pxpt )
> +    {
> +        spin_unlock(cpufreq_statistic_lock);
> +        return -ENOMEM;
> +    }
> +    per_cpu(cpufreq_statistic_data, cpu) = pxpt;

... how come this moved up (back) here, when it was ...

> -int cpufreq_statistic_init(unsigned int cpu)
> -{
> -    uint32_t i, count;
> -    struct pm_px *pxpt;
> -    const struct processor_pminfo *pmpt = processor_pminfo[cpu];
> -    spinlock_t *cpufreq_statistic_lock = &per_cpu(cpufreq_statistic_lock, cpu);
> -
> -    spin_lock_init(cpufreq_statistic_lock);
> -
> -    if ( !pmpt )
> -        return -EINVAL;
> -
> -    spin_lock(cpufreq_statistic_lock);
> -
> -    pxpt = per_cpu(cpufreq_statistic_data, cpu);
> -    if ( pxpt ) {
> -        spin_unlock(cpufreq_statistic_lock);
> -        return 0;
> -    }
> -
> -    count = pmpt->perf.state_count;
> -
> -    pxpt = xzalloc(struct pm_px);
> -    if ( !pxpt ) {
> -        spin_unlock(cpufreq_statistic_lock);
> -        return -ENOMEM;
> -    }
> -
> -    pxpt->u.trans_pt = xzalloc_array(uint64_t, count * count);
> -    if (!pxpt->u.trans_pt) {
> -        xfree(pxpt);
> -        spin_unlock(cpufreq_statistic_lock);
> -        return -ENOMEM;
> -    }
> -
> -    pxpt->u.pt = xzalloc_array(struct pm_px_val, count);
> -    if (!pxpt->u.pt) {
> -        xfree(pxpt->u.trans_pt);
> -        xfree(pxpt);
> -        spin_unlock(cpufreq_statistic_lock);
> -        return -ENOMEM;
> -    }
> -
> -    pxpt->u.total = count;
> -    pxpt->u.usable = count - pmpt->perf.platform_limit;
> -
> -    for ( i = 0; i < count; i++ )
> -        pxpt->u.pt[i].freq = pmpt->perf.states[i].core_frequency;
> -
> -    pxpt->prev_state_wall = NOW();
> -    pxpt->prev_idle_wall = get_cpu_idle_time(cpu);
> -
> -    per_cpu(cpufreq_statistic_data, cpu) = pxpt;

... moved down here just a few weeks ago? See a1ce987411f61 ("cpufreq: don't
leave stale statistics pointer"). I'll make yet another patch, but you want
to be more careful when re-basing. The other recent change, c6e0a55396233
("cpufreq: use existing local var in cpufreq_statistic_init()"), was also
lost.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 10:35:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 10:35:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019046.1395906 (Exim 4.92)
	(envelope-from )
	id 1uRq8p-00073b-2h; Wed, 18 Jun 2025 10:35:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019046.1395906; Wed, 18 Jun 2025 10:35:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRq8o-00073U-Uz; Wed, 18 Jun 2025 10:35:38 +0000
Received: by outflank-mailman (input) for mailman id 1019046;
 Wed, 18 Jun 2025 10:35: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 1uRq8m-00073O-TX
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 10:35:36 +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 f77e423a-4c2f-11f0-b894-0df219b8e170;
 Wed, 18 Jun 2025 12:35:35 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a53359dea5so4705820f8f.0
 for ; Wed, 18 Jun 2025 03:35:34 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2365deb87ddsm96601295ad.177.2025.06.18.03.35.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Jun 2025 03:35:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f77e423a-4c2f-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750242934; x=1750847734; 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=8xkeOw2RFxhc3i1l1Ye9F1X5bFVCvJghO+E1EtWrnr0=;
        b=UEhlQdeznWyUkByUcBrLdaoGntbUyifbK/EF2CQs52itrc1Pgtm8fstsXawzyfoHOR
         dzq3JlxXJTZXJrl93gdZ+GPPnmR4yp8vpJst4t2eX/Vi8Ts5O2/oZikjPN5IYXkAcZki
         huf+wGec1iALOWg4EiIdSyYOy/bniAbFXAfnML3uFmAXrQP0tE49IuobtU1G33Swz54Z
         zZK6AfSFlNevtpUofPAuyvFCiyB140sKC5fKxtFceuI1ew2gFJgTI/pzDwrupBn+FUhg
         Y73lW31CaGYN5u6WGONdYqZgoY5XgOcn7pUEfjCyt+zLycisM5hbhdFs1olL0Mhp2uKG
         nLhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750242934; x=1750847734;
        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=8xkeOw2RFxhc3i1l1Ye9F1X5bFVCvJghO+E1EtWrnr0=;
        b=oAeWB+QYwItptoaP/HjB6Yhjc9nr/4XibACRtQTcm40PopFsOYIGt6uaFGH71XXWX/
         tPG7yGJsnEIJIYzbIMMgqU1lyAmIFvTyzEDF1Gs2xZfYXAwOwf+12Hyw6KnMAjif71qH
         Wy/wVbImSjSHM9e/3YKEsRPQFBfhXDhu4JD4yK6vWTKifb/0Prq8FgZUZRDs51x5G78s
         pDKw0LKCwM+PxxEtOEhDWlJS1fhsWhapAS02tym9bU2no9DuaAem+T1PFSeUxMro4wz7
         ib8Q26UAlcOBHpA7LRtTjr6NVIEaNVD8upTMqIQfgrzM4VIrQqu4LTHqXAvvRDwLxlmq
         dPdA==
X-Gm-Message-State: AOJu0YwsEQ84lpikRUJ3m/4+b29DLolMKyvvS1BBirqBQ6Q2R+dY6Zz+
	TFFJnzI9DA5PLeco4WiYb/hTFOJEvAOA1xEliBvE8HcqsI0B9yMJUrhMv3p3kUP7yqZaYeJUDT3
	jjJo=
X-Gm-Gg: ASbGncueCVPquezKI1U8i7vkDCN1P6LI1ryhuGbPuZfdQqfsd1Vk2z4dtPtlh9nUf5O
	wYxN+i4UnvMnQyXWN05Cxu26+EzP5g+PksRQs0D8mH6krh4oGqWftr4EA8xOXVm5lJfLnap8qOi
	JuYaHvUUErCNTQeeXsdzJfkVKMYRdwkwiOmuUTzaW4GRkBMiPVkK/t1jI2EebByT5QT/ZYaZoNU
	tNRi7d0F0+L00D8tb0tOKIoeRcLx9Gf+mBLTiOqSvyT2z+DXZ6ek+RqE60vDspo13Iyzxxj5k82
	wp0HCaAoniyxtV0y4xl7DIJpMDX2DBBhdvQKn+DQe0E6yAtAppWbzcBRPp76iWWM2ubcMexGE2w
	HcN0hUrVfPVlgr2jocAbyj5DHOExJD3uLfQ53wFrAfaw19CA=
X-Google-Smtp-Source: AGHT+IGxUaKuUNhO2EryXxYcTI4kA1LbTs4SK+Bwop9pRfn379NzQawiHDXKUjYCMsHBETpduKXMCw==
X-Received: by 2002:a05:6000:2dc4:b0:3a5:2b1d:7889 with SMTP id ffacd0b85a97d-3a5723af48amr14570188f8f.43.1750242934358;
        Wed, 18 Jun 2025 03:35:34 -0700 (PDT)
Message-ID: <2e354a84-2277-4a7f-8291-3f19526d645a@suse.com>
Date: Wed, 18 Jun 2025 12:35:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini ,
 Anthony PERARD ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Penny Zheng 
From: Jan Beulich 
Subject: [PATCH] x86/pmstat: restore changes lost by "consolidation"
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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

Both c6e0a5539623 ("cpufreq: use existing local var in
cpufreq_statistic_init()") and a1ce987411f6 ("cpufreq: don't leave stale
statistics pointer") were lost in the course of "moving" the code,
presumably due to overly lax re-basing.

Fixes: bf0cd071db2a ("xen/pmstat: consolidate code into pmstat.c")
Signed-off-by: Jan Beulich 

--- a/xen/drivers/acpi/pmstat.c
+++ b/xen/drivers/acpi/pmstat.c
@@ -124,7 +124,6 @@ int cpufreq_statistic_init(unsigned int
         spin_unlock(cpufreq_statistic_lock);
         return -ENOMEM;
     }
-    per_cpu(cpufreq_statistic_data, cpu) = pxpt;
 
     pxpt->u.trans_pt = xzalloc_array(uint64_t, count * count);
     if ( !pxpt->u.trans_pt )
@@ -143,15 +142,17 @@ int cpufreq_statistic_init(unsigned int
         return -ENOMEM;
     }
 
-    pxpt->u.total = pmpt->perf.state_count;
-    pxpt->u.usable = pmpt->perf.state_count - pmpt->perf.platform_limit;
+    pxpt->u.total = count;
+    pxpt->u.usable = count - pmpt->perf.platform_limit;
 
-    for ( i = 0; i < pmpt->perf.state_count; i++ )
+    for ( i = 0; i < count; i++ )
         pxpt->u.pt[i].freq = pmpt->perf.states[i].core_frequency;
 
     pxpt->prev_state_wall = NOW();
     pxpt->prev_idle_wall = get_cpu_idle_time(cpu);
 
+    per_cpu(cpufreq_statistic_data, cpu) = pxpt;
+
     spin_unlock(cpufreq_statistic_lock);
 
     return 0;


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 11:00:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 11:00:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019058.1395915 (Exim 4.92)
	(envelope-from )
	id 1uRqX7-0002cY-S1; Wed, 18 Jun 2025 11:00:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019058.1395915; Wed, 18 Jun 2025 11: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 1uRqX7-0002cR-PA; Wed, 18 Jun 2025 11:00:45 +0000
Received: by outflank-mailman (input) for mailman id 1019058;
 Wed, 18 Jun 2025 11:00: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 1uRqX6-0002cL-Sy
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 11:00:44 +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 7880aaea-4c33-11f0-b894-0df219b8e170;
 Wed, 18 Jun 2025 13:00:39 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3a53359dea5so4723622f8f.0
 for ; Wed, 18 Jun 2025 04:00:39 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a568a54aeasm16860560f8f.14.2025.06.18.04.00.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Jun 2025 04:00:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7880aaea-4c33-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750244439; x=1750849239; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Pz/j6REenJK98gq4UAuf9ldxO4zim6CyD7BhTzRWWzk=;
        b=ideMGNHV9P2fSssZ3kW03v4Du+1k0l6sZR0yv2txBG6myE/aVpUkVXw0aej3gxRiEH
         ijaATOe1t2YF+cv1MPG65I4pj5QExCq9GGavaKXV1CYVjaLlX4wSXdcG+gkT/1m45u9G
         /RMe5H06z9+NeNr5c7dgewqNBuJHwY6PDX+Qw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750244439; x=1750849239;
        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=Pz/j6REenJK98gq4UAuf9ldxO4zim6CyD7BhTzRWWzk=;
        b=ttQwKX9LSJYsyRWGQ0OAL/F1c2E9vtMoRpzSR6NXhOe/A2twnKnP+N7OSpk0wyg9o7
         cZhsBz1gxp9OQ0KAdWyTTpfg9WyiNj9RpP0aOlM0cN4Mw4ZMiA2FHC2VaiAOkMgSMPEC
         KlgIPpZjgq/Ee5OqDW7QH8RvPdVj/I9T5x53tcAvhn9Go8sHpgRFcny85UAdt5Ke7Xb8
         /bjz+8b6RIhDcwDz1k7xMHMjs2m28Y36LUWLq/Q+dtO6Up1Tcvh5iliNQ8hHSVvRcnSJ
         syiGo+af9YaaXejK9Fmtbsqf7gov7M4tGp6C5x/PTKSvzE1lLIKmvmvTd/BuBCRItq12
         BOPQ==
X-Forwarded-Encrypted: i=1; AJvYcCU3Zqe+Gn65xTy/RdmcJ0G4qyEbuPbpx2zIzBbvMx1Ex7A4Pvcggv/mG7gksLhbb086t7gQ+fuqluE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwetPu8bJOU92hhjYwvEoC8hogJYq+xY/OcMebnC2g8UnHy6z3G
	Or6tAP73esEzAJUCokfY5bMTh5Muc+ek3FYf/GLF9L9FiZLQZuPL++vKKVevssVVkEI=
X-Gm-Gg: ASbGncses5M9LDtATkLVJQAnakD1K9S0Ip8+Hv2BJdomjLJnHNaV8U90b9+3s/iY2E2
	v1T27D2wAJu0aBmIAqhpm0lnBO7tTOiygxm+qCWp9Db3h3p7KaZpMyrvQkOxbYKgv9MkN3HxtwS
	4hTHK9MnTBFOadjEqj/A3pTHKZx5QdVXoeSI+VQLiXs0RxfLN8uKG/JW4v+zZDUCVeFlYCbFKrg
	ZeB8ownT5C58z9u6My5VAWZ+ceIQmzJbFHi0Ah4MqhRyI2CwTf0OAemB4NNJTFPUTw2W3NuKFJg
	eGIyIP+eNO0chY2It5wR4QCUkbRlY0D5gmNpqCVDDrzx2b1zqFrBDBruYqydsNFOPRQNwWvVQJN
	/QbrpPL/MfkVnvDViKL0iRULYneE=
X-Google-Smtp-Source: AGHT+IFbH9ETYF0uCKrdWmfx8uxACSUbNymbt2EiJHCh6eMiGtL4o4ECMgn0Bn80tJ/s1HgHJnAf2Q==
X-Received: by 2002:a05:6000:2003:b0:3a4:e6d7:6160 with SMTP id ffacd0b85a97d-3a5723679cdmr12189875f8f.6.1750244439145;
        Wed, 18 Jun 2025 04:00:39 -0700 (PDT)
Message-ID: <4a0e4e50-1e4d-4046-8897-b4769591650b@citrix.com>
Date: Wed, 18 Jun 2025 12:00:37 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/pmstat: restore changes lost by "consolidation"
To: Jan Beulich ,
 "xen-devel@lists.xenproject.org" 
Cc: Julien Grall , Stefano Stabellini
 , Anthony PERARD ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Penny Zheng 
References: <2e354a84-2277-4a7f-8291-3f19526d645a@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: <2e354a84-2277-4a7f-8291-3f19526d645a@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 18/06/2025 11:35 am, Jan Beulich wrote:
> Both c6e0a5539623 ("cpufreq: use existing local var in
> cpufreq_statistic_init()") and a1ce987411f6 ("cpufreq: don't leave stale
> statistics pointer") were lost in the course of "moving" the code,
> presumably due to overly lax re-basing.
>
> Fixes: bf0cd071db2a ("xen/pmstat: consolidate code into pmstat.c")
> Signed-off-by: Jan Beulich 

Acked-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 11:27:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 11:27:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019071.1395925 (Exim 4.92)
	(envelope-from )
	id 1uRqx2-0005lC-S2; Wed, 18 Jun 2025 11:27:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019071.1395925; Wed, 18 Jun 2025 11:27: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 1uRqx2-0005l5-PA; Wed, 18 Jun 2025 11:27:32 +0000
Received: by outflank-mailman (input) for mailman id 1019071;
 Wed, 18 Jun 2025 11:27: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 1uRqx1-0005kz-54
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 11:27:31 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20613.outbound.protection.outlook.com
 [2a01:111:f403:2413::613])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2eb95f51-4c37-11f0-b894-0df219b8e170;
 Wed, 18 Jun 2025 13:27:15 +0200 (CEST)
Received: from DM6PR03CA0092.namprd03.prod.outlook.com (2603:10b6:5:333::25)
 by CH3PR12MB8728.namprd12.prod.outlook.com (2603:10b6:610:171::12) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Wed, 18 Jun
 2025 11:27:11 +0000
Received: from DS1PEPF00017096.namprd05.prod.outlook.com
 (2603:10b6:5:333:cafe::61) by DM6PR03CA0092.outlook.office365.com
 (2603:10b6:5:333::25) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.30 via Frontend Transport; Wed,
 18 Jun 2025 11:27:11 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 DS1PEPF00017096.mail.protection.outlook.com (10.167.18.100) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8857.21 via Frontend Transport; Wed, 18 Jun 2025 11:27:10 +0000
Received: from localhost (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 Jun
 2025 06:27:08 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2eb95f51-4c37-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=u5bVQbkm7PkhixT3QmX7bPFGazmuCDfhRw/P/PaNCb8Bnwkbpohcq7P2XFDJk/bkXsZYBw8RMKtKkDU1iGYQ+8Wvp0x4dS3oLtNFcXXoct5R09cQtNGZgAXe/NPYk4dWOi0N4lX6vzoNJrr5nidlyv8mAVH7Jf61AS/AcpRxKzS5Ao9YGPBgGrxT/Mho0cgPAdbNkhqRuI8aB0YZWhvyra8LYbi0NL4rP89LLbrzDpurco9u3PFzD8lYzQDxmprlkjO6coYztucml4N0nxItmT25/Bo0iDo8n0QwGHMvQNg1PqY8dm84n/mFLkA5Gg0bdweh8ljZfRii1GiyhRp4UA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=mWPZS55WWSHLHUZtdI+rkuAR3JOR9CRD/RZ+ZiQf0yw=;
 b=ugsu8xV/hT0QdBmmx4x5JQrUv4CdCpZzy5nM4JS35xWUQ/h6Zgckl9MyXQT8f+TzJAU+YQtrrWrdw9NWb4+dqb4C0uQwPF/ZgAbBafeOKuuugeqh/M7KMmRkD6t59qrYK5doLiue7RMh1OC04/XrhXi7/eP+bZhoFaFH2laq2SyYVY2bm0NpptGaHeF0dpZYpCobzwEpY0ZMZF8XW4hignDTDdtGSUCmhS+zLwoqZk9nzl+p9EQbjbQ5VYz94upX3G30QyHxH/C4SgCCW3hNx7dncuRdIEX3WZklxqYI+CYPOGl+chwT0ozL8eS1Q16HhKzIT5GU6J+AdZGd+tQwRw==
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=mWPZS55WWSHLHUZtdI+rkuAR3JOR9CRD/RZ+ZiQf0yw=;
 b=BZjOhxVhI2y6XyK6kpkzfmhxNedylARpzIQ+CY7uml0vZF70hY0i9FGOO4L4dnmcQzPDHQYhmJLSO6EdMOh/K70s4vhKGAqsG0PclLA+e+pfIYX06vge9ICjitAPgR+r2hsocwkEBSxgeOjGWDECUUanqTWJwSQ4PmHuuKuxfgU=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 18 Jun 2025 13:27:07 +0200
Message-ID: 
To: "Orzel, Michal" , 
CC: Stefano Stabellini , Julien Grall
	, Bertrand Marquis 
Subject: Re: [PATCH v2] xen/dt: Remove loop in dt_read_number()
From: Alejandro Vallejo 
X-Mailer: aerc 0.20.1
References: <20250617171358.670642-1-agarciav@amd.com>
 
In-Reply-To: 
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: DS1PEPF00017096:EE_|CH3PR12MB8728:EE_
X-MS-Office365-Filtering-Correlation-Id: 9fff05df-19e4-453e-77a7-08ddae5b10e6
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:
	=?utf-8?B?U3NERVNwSW9lelhhQjBIajBoMVpyczVDWGk1dmU2NlR3SVRENTRsSmM2QmVF?=
 =?utf-8?B?RzI0U1lkZWIybGtvMUVIUHNXRk1DL3ZodUxsOWRWRENrT3Z0ME1JNXI0Z21G?=
 =?utf-8?B?MEFsdnc2R09iNWZ3RWpyZjJybHo5WFhLaXNLMi9LN2xlL3I1aW1RTWZRTjN2?=
 =?utf-8?B?N0FhR3k3cWE4KzBReXpWaHpINlFtVjlKR1p5MC9BZmQrempUb3dYcXdYbDZu?=
 =?utf-8?B?emxPQk5zd1Z6YkxoZGJ6UVdDaVJEdWtnUFRhcnRoVGN2Sk5XeFdJVUtRMHFO?=
 =?utf-8?B?N3F6YklTRlNpbWpWN1JxaVRNaDdCSFBoUlE4eGlpaXd5ckNuaXM4SmdteHkr?=
 =?utf-8?B?K3hMSFo0V3dZZmx2WWdZNnV1bDhBN3VaOFNLQmJDRlNEajRKQWxZK2xuV08w?=
 =?utf-8?B?Um1kMUNMRTNIOXF2aktCM3JiaWhPQU1TL1ZuOU9RR3hXSVVBa24zdDROVzJr?=
 =?utf-8?B?eDA2Y1NmNGlGMFpqTVlBeCt4ZlArUTMzNk1nTHA5RmwvKzFSVC9aZWtrc01H?=
 =?utf-8?B?MVVUcWVtckhYV3FGMDFDditMandxV200U1A1QXo1amRjV1dyWWZKcS9kaGVC?=
 =?utf-8?B?bURqL29aOUJjZU9CMkdVUGdSbnlYMGVkTWVSeXhnUmhpTS83c0NYdlk2QktW?=
 =?utf-8?B?MlQ5eFpVM3VwWFllcWJvUjhycTZucmZ2UU10OEE1NzZoMGdjcTVwd3ViUWxS?=
 =?utf-8?B?a3VtbEZWV2h1VmJiYi9YTTNRY2lLd3BoNy9LdkpROFEvaFV1am1JUVhYR091?=
 =?utf-8?B?eTJWVFJKblUvNzk3TGxhS3VPQXdNZmJOeCt4V3ExRUlPc1FDU1llQnR0eXQz?=
 =?utf-8?B?RW9SUzZiMlY2bU15cXpVR09XZWgrQWkxeDV4bHBweUJMNXdadCtqQ2tFZnNR?=
 =?utf-8?B?eFNLVGgxV0hRRDdJcWd6OERJSXlPOU1sbUtQSTMyRTRjNjVyQ3Vac0hRYUxE?=
 =?utf-8?B?QUt6TU5uQnJHUGpscDFaaGRTaHVra0RwcHFHaC9uVDlSUXZQUll0NnJkQ25q?=
 =?utf-8?B?eFB6NkRtY0xaZ1FRT2NmNWk0anNaSVdoV3BuZ1E5Slozb29yRStEdUVZbFo5?=
 =?utf-8?B?R01ybGdjQTYva3pSNkhuUEhrMnd2N1VwUjN3bGI0Z0l3Sk0zY1BPcldCVldS?=
 =?utf-8?B?QTRHYWVFVDNjdU4vVjUzY0tRc1Yxd0JCWU5RREpJRjNPak0yR2RJVGRJeVpL?=
 =?utf-8?B?VHR3SnAvcTNCRGRpRVF2Syt3SFlNNHdtK2ZRd1B6TVU5OVBKM0ZzSUN1T3hz?=
 =?utf-8?B?UEVycmFCdThqZVJ4TGVya1ZXdmJBMVVndDFoM2dwOXdNK3lBVzlMdnluYk5l?=
 =?utf-8?B?NUlvakFSaG9pN2ZNdERpSCt0TnZSeityMVlxZk43UHROSEZoZlZpYUNDQnlC?=
 =?utf-8?B?NXhaMDBkekJGZHE4d3FuUDVvZ2U4bnhsUVp3QXpQR0NvSmYzWC9FdXZkWmVI?=
 =?utf-8?B?VlRSQ3NYMlhucDBHY0JjRUhhbXUxOHhpdnBYcnR1NmxuUXBsWlltWXRwTlBu?=
 =?utf-8?B?YUJhSXpGRk16R1pWM2EyckJFR3g2MWQ4WEdDWjlTNWk4MjEvQmRHUlJxeDRL?=
 =?utf-8?B?bXNKNno0UHNqK0VNUmxHZUJzbXRqV1REUzUxZHU2SHRNT3crbVVwb2JOeFE2?=
 =?utf-8?B?d000elZwZ3cyN09JVmRacENpd2Q5bzlYMlpndkx5a0NacUJnT21mazJIV0k3?=
 =?utf-8?B?eHRTNm5hRVlXazVtTFRuQmNxYVVhR2RUbHZJdTBUWTNSNmVzbGZGUlhlUEl4?=
 =?utf-8?B?QmJ2S3BhSEZXQkdYRFl5cnJ5blVuN0NsTDMyWlNBOHRxQjR1WU9uSFlNOTZB?=
 =?utf-8?B?SFdtckdCcEZRenNQVnVmbFhDT1ZvbzBMME1qVmh3S2JWVVJLOUpZQXdueUdJ?=
 =?utf-8?B?VUM4R29WTnpHK1RFK0JTenVPdU9jaS90ckJXeEJXRDdzRk9RTG42OUE1Vnhm?=
 =?utf-8?B?ZjlQUmVMK2tXazZ1QUNQOGxUYXpnTDZtZ3FESW9OMGdhMjlVNkJYeW9IalRr?=
 =?utf-8?B?NmZEbGlKQVFYLy9wL3h2RVlLdG5BeldIUDFpRkZkNSthVlJhOVZ5Q0o5aTdx?=
 =?utf-8?Q?t1EUSV?=
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: 18 Jun 2025 11:27:10.4513
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9fff05df-19e4-453e-77a7-08ddae5b10e6
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:
	DS1PEPF00017096.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8728

On Wed Jun 18, 2025 at 9:06 AM CEST, Michal Orzel wrote:
>
>
> On 17/06/2025 19:13, Alejandro Vallejo wrote:
>> The DT spec declares only two number types for a property: u32 and u64,
>> as per Table 2.3 in Section 2.2.4. Remove unbounded loop and replace
>> with a switch statement. Default to a size of 1 cell in the nonsensical
>> size case, with a warning printed on the Xen console.
>>=20
>> Suggested-by: Daniel P. Smith" 
>> Signed-off-by: Alejandro Vallejo 
>> ---
>> v2:
>>   * Added missing `break` on the `case 2:` branch and added ASSERT_UNREA=
CHABLE() to the deafult path
>> ---
>>  xen/include/xen/device_tree.h | 17 ++++++++++++++---
>>  1 file changed, 14 insertions(+), 3 deletions(-)
>>=20
>> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree=
.h
>> index 75017e4266..2ec668b94a 100644
>> --- a/xen/include/xen/device_tree.h
>> +++ b/xen/include/xen/device_tree.h
>> @@ -261,10 +261,21 @@ void intc_dt_preinit(void);
>>  /* Helper to read a big number; size is in cells (not bytes) */
>>  static inline u64 dt_read_number(const __be32 *cell, int size)
>>  {
>> -    u64 r =3D 0;
>> +    u64 r =3D be32_to_cpu(*cell);
>> +
>> +    switch ( size )
>> +    {
>> +    case 1:
>> +        break;
>> +    case 2:
>> +        r =3D (r << 32) | be32_to_cpu(cell[1]);
>> +        break;
>> +    default:
>> +        // Nonsensical size. default to 1.
> I wonder why there are so many examples of device trees in Linux with
> #address-cells =3D <3>? Also, libfdt defines FDT_MAX_NCELLS as 4 with com=
ment:
> "maximum value for #address-cells and #size-cells" but I guess it follows=
 the
> IEE1275 standard and DT spec "is loosely related" to it.
>
> ~Michal

I could imagine DT's encoding CHERI 64bit capabilities as addresses, which =
could
require 4 cells. Needless to say, this function wouldn't even be in the top=
 10
biggest problems in making Xen happy running on a CHERI-capable processor.

As for #address-cells =3D <3>, I really can't think of a reason except test=
ing
theoretical corner cases. =20

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 12:04:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 12:04:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019097.1395935 (Exim 4.92)
	(envelope-from )
	id 1uRrWj-0002x7-Kd; Wed, 18 Jun 2025 12:04:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019097.1395935; Wed, 18 Jun 2025 12:04:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRrWj-0002x0-Hf; Wed, 18 Jun 2025 12:04:25 +0000
Received: by outflank-mailman (input) for mailman id 1019097;
 Wed, 18 Jun 2025 12: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 1uRrWh-0002w6-TZ
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 12:04:23 +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 5f28b320-4c3c-11f0-a30a-13f23c93f187;
 Wed, 18 Jun 2025 14:04:22 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3a35c894313so7661505f8f.2
 for ; Wed, 18 Jun 2025 05:04:22 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b2fe16806casm9085827a12.50.2025.06.18.05.04.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Jun 2025 05:04:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5f28b320-4c3c-11f0-a30a-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750248262; x=1750853062; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=WAYPCJixiV7zgK7cyTRMK8RBH+JSfm3R5cByYNdSMT0=;
        b=fXiSdSx+8w/OwgHZx7/kh3PyXsAu8VnmNOiouqukhU+g8fxsNP9qqYmMqcuto74nXb
         nMbx8fEeZ4RHxfK4q5D3ntc0yt6plIIOH4XuaCzUDOXvcSdjTMvBGLbI3A8ZA7/pU1Em
         jc6eoqtZztj5YTTTb7lW35EUzEWKQe9OQJSlaI6Ui/hTXSNH0IrpHVXSO2QQt3m7swSd
         TWG03+YK2qk/GqzfgGNnqv58VU6MOeq8OOij7W7GypGNAJMLhXBXn6tCdQYiO8Wzc9EB
         a8KCNqMSV8OXhVBbZYG9KanGca9Qdt+RYdQQgGa3jCHR8EtA8DjZ1v6aRUijpa+oS2wG
         reSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750248262; x=1750853062;
        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=WAYPCJixiV7zgK7cyTRMK8RBH+JSfm3R5cByYNdSMT0=;
        b=GR6mlSoyFwl9YJBFZGvnb2SCPw06JGwS0UZjmRS+nFV+niNM4BdaGRPwXECwYpUti7
         JbzA7HGh4Ooq8ANWoVl0165+unhafTbBcgm3E3EmLajt5V8rn2IYTopNkh7V0oBkIYhl
         ANFja9z3g7kWcVWwRATUAd80y57hT66mE5NpIOTIbyN+KtpylCFLkaZmb9C7vaw60DkD
         D+7l6tp7BzkyoQKRJiiszExG6hP/lolz3lN1MhIAonrCxo+2KypMt/I5p8ZTTrdTPnqE
         eOsial1dXV8gMYlL5NnlbTa50NkLkTFgiND2B2gAWfSqtCOll8nLpNVzjzexm7dNxe61
         DhWA==
X-Gm-Message-State: AOJu0YxePMhQYArMDc3ZezU489UCErpQh5MTCEg/t1WhsdQIMT4oTxkl
	Gnsp4IymZw0Jo+rg4MGyCWuywL1YCpZfIeswHT0Of5TRUfTBih4Kr+8fQiduhUcULg==
X-Gm-Gg: ASbGncvT3Y7v7wXk4gWS9P/x861pxq17l0RmbQ6m+6cUpsgTCLJ/HBJPTKThXRGlB8/
	RH67x9ufsXn3fg3eC/6GWUDlwlDKYkQm8gj3dkU5PjCryZOECJmXNBdfNcTWwRp8ad2ruS9zUSL
	YQVmGm3hydvkS7OzD3QWwv6qFGqJaHk+0wH+Nn/9IcQJhi69GqtB1PXz2SYx/Ip/fSkIEapIF7x
	NCg+Duo4Khm5v2JJzEgVQOkOYBQx1EMoybHxa/kCmRE0KthsrYAA/RnZ5cYuM7Vwxy5nxn9AQKL
	73+poauB0B1VySVhj2InlD75Qw4WJgmMYeBNWDz2ulEtCoKyOcdwhRLC7FgjH4KJKrQdLZ87D+C
	0il3beTXJrlAsCCH75hdpNZyk7Xk8EcBc3nx5fTK9Gf1lLbB9gKv5tD8ymA==
X-Google-Smtp-Source: AGHT+IGZlPYGbMox5qe2KykBkj7lQJoPaUBiX7q+45+t3Ng0r5pmnq6Q6iLeEEUC0bfcAhLduHb3pw==
X-Received: by 2002:a05:6000:178b:b0:3a4:d8f2:d9d with SMTP id ffacd0b85a97d-3a572e6f2b3mr13840139f8f.38.1750248262065;
        Wed, 18 Jun 2025 05:04:22 -0700 (PDT)
Message-ID: <8f3f8815-a60d-4c8b-af2b-fc8ed5f9ba32@suse.com>
Date: Wed, 18 Jun 2025 14:04:12 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] memory: arrange to conserve on DMA reservation
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper , Julien Grall ,
 Stefano Stabellini ,
 Anthony PERARD ,
 Michal Orzel 
References: <6565e881-ec59-4db4-834a-f694bf1b9427@suse.com>
 
 <9b036f26-f275-48d0-9a33-7cef38b29f48@suse.com>
 
 <2969b5d8-5879-4674-8332-046898e17257@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 16.06.2025 19:23, Roger Pau Monné wrote:
> On Mon, Jun 16, 2025 at 06:02:07PM +0200, Jan Beulich wrote:
>> On 16.06.2025 17:41, Roger Pau Monné wrote:
>>> On Mon, Jun 16, 2025 at 05:20:45PM +0200, Jan Beulich wrote:
>>>> On 16.06.2025 16:46, Roger Pau Monné wrote:
>>>>> One question I have though, on systems with a low amount of memory
>>>>> (let's say 8GB), does this lead to an increase in domain construction
>>>>> time due to having to fallback to order 0 allocations when running out
>>>>> of non-DMA memory?
>>>>
>>>> It'll likely be slower, yes, but I can't guesstimate by how much.
>>>
>>> Should there be some way to control this behavior then?  I'm mostly
>>> thinking about client systems like Qubes where memory is likely
>>> limited, and the extra slowness to create VMs could become
>>> noticeable?
>>
>> What kind of control would you be thinking of here? Yet another command
>> line option?
> 
> I guess that would be enough.  I think we need a way to resort to the
> previous behavior if required,

Thinking about it, there already is "dma_bits=". Simply setting this low
enough would have largely the same effect as yet another new command line
option. Thoughts?

> and likely a CHANGELOG entry to notice the change.

Hmm, not sure here. This is too small imo, and really an implementation
detail.

> Overall, would it be possible to only include the flag if we know
> there's non-DMA memory available to allocate?  Otherwise we are
> crippling allocation performance when there's only DMA memory left.

Imo trying to determine this would only make sense if the result can
then be relied upon. To determine we'd need to obtain the heap lock,
and we'd need to not drop it until after the allocation(s) were done.
I think that's far away from being a realistic option.

> That also raises the question whether it's an acceptable trade-off to
> possibly shatter p2m super pages (that could be used if allocating
> from the DMA pool) at the expense of not allocating from the DMA pool
> until there's non-DMA memory left.

This being an acceptable tradeoff is imo an implicit pre-condition of
adding such a heuristic. For the system as a whole, exhausting special
purpose memory is likely worse than some loss of performance. Plus as
said above, people valuing performance more can reduce the "DMA pool".

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 13:02:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 13:02:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019126.1395949 (Exim 4.92)
	(envelope-from )
	id 1uRsRE-0002CI-Hm; Wed, 18 Jun 2025 13:02:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019126.1395949; Wed, 18 Jun 2025 13: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 1uRsRE-0002CB-Ez; Wed, 18 Jun 2025 13:02:48 +0000
Received: by outflank-mailman (input) for mailman id 1019126;
 Wed, 18 Jun 2025 13:02: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 1uRsRD-0002C0-M6
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 13:02:47 +0000
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com
 [2a00:1450:4864:20::133])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 87955d9b-4c44-11f0-a30a-13f23c93f187;
 Wed, 18 Jun 2025 15:02:46 +0200 (CEST)
Received: by mail-lf1-x133.google.com with SMTP id
 2adb3069b0e04-5534edc6493so7402932e87.1
 for ; Wed, 18 Jun 2025 06:02:46 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b319dc80726sm6692738a12.68.2025.06.18.06.02.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Jun 2025 06:02:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 87955d9b-4c44-11f0-a30a-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750251766; x=1750856566; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=9mxW8Ip0OJGiaE4zcQWftfcdMa53m9+kFOqq7fEAC7Y=;
        b=TxJOHIoaLopgM8Ms4rOgcEO/VEH2ZYNObZUjxuDDUmz/kqgLmkdJ2LPp8YeGfFzcUC
         L0IL8nIL5jO8rXwU3eyN+edUO/ZqwurKaH46uD8efchjB4f4a5GZ1F9faC79AG9LBAV9
         yUYqiSj828lslOKq2j0jG6pDV3QxjPSticEs6bHW5Exe6vqXMS72DVMlXpJEdKG7NYl9
         LVSPQOu3wivX+1AbdRpCJuqL8D0d15BQlxlyAG70eEqKgHmTpL4uQ2Zw8C5S/T4+khIX
         L61kw0lHAcJ9ite273eeaesQthTJ+krCjmpDYSkGnuGyUPZ0OsoUK29vRPJ8diTPc8pi
         bE0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750251766; x=1750856566;
        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=9mxW8Ip0OJGiaE4zcQWftfcdMa53m9+kFOqq7fEAC7Y=;
        b=bxq2Wnq9imS+/MEPc4nqLokTuoYnu6YxHUqiA/wAPcL/tRghlP1B6ahkyIsHhUgIhv
         CohYfYE/bZ7m8JhbPL2z/eIkm40po8n9ryjvcT+V9dbA2InhRdyNDoipk0xaV5ARWUAy
         q1Bnzzfbzy7ZcrqQMJNEIlD0y8eisaUeMhaidgtnlVxRrizig4VJTl2XJqL0CEWxOfEf
         HQkZJcZt/znCYrcFdZjfCVAUcL0NIrMp1ThkepzPS94fxdMp29GwKKM/TFPi4kK2tWbX
         Q/gHgql24asPGAryuDmk/I2N/9XZWtzec3IwEdAGXm6I/dB8AOEmfnWcs+N83ssvQBWm
         3AIA==
X-Forwarded-Encrypted: i=1; AJvYcCXFWCSuW/NmUe2fOCul6oJZ5Agqn7K53xmAW43Taj2kXEy2nuwJLmL9wVRKSCMQXhSkrmkYZY3YeUo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyOPfBGpIKSd15AcpsNikRqcC552LV3+TwtlYBMmML/ad6BSkkh
	2RJ+6TEa45kMIiaWWoQ6zP0OJJpzLLdaf2x5+8gIFaMCrELhqWzNzoUQWdws/HyZbg==
X-Gm-Gg: ASbGnct95XfWPolEJsVx9fPyZEuPuw5zo+IphlItwZlzWeGNV4TjKYAa0cbE8lE3Dco
	ENJzm11LI+EX+5z4pr0LO0oleEXR2WiL3sFEKeVCp2ib1N4e+NcbvRnwsUnCPdRMYnkJ0GTcne4
	j2QLbo83U0GTf+iTW+0S6vZ5EQgPlCfTizAG1HQA335MpjLDT/9dffcWqrN0HAIONY9h4XoJIQ3
	Jv8/Ah+uVunN6FoH8R0THR4pJZ2/VBlwapsbAZRbKYAg5QkLYjG/tHI7wuOfDBzphHegQdmaiwW
	KcjRUreIwQjUNyN3wVz5ltb1ifkiUTsxGrBVsLMkfohFFze5VSHuLwB4qh31LMc9qpcYzgycSgA
	mWKcKaPNfBeFEenYCfMnPg1R7OTSkSe5iX5H4RcZJNp7uX/M=
X-Google-Smtp-Source: AGHT+IHB5JKeDvRaqXdeKot7/rQXchhr/yB3zfkDGX6fvI9p0Yz7aItJdqWC3+MK3g6vFfnEbBQHYA==
X-Received: by 2002:a05:6512:b0a:b0:54f:bce6:63bd with SMTP id 2adb3069b0e04-553b6f62293mr4655492e87.54.1750251765332;
        Wed, 18 Jun 2025 06:02:45 -0700 (PDT)
Message-ID: <4e8efcc9-9721-450b-b27c-2caac4aedfb7@suse.com>
Date: Wed, 18 Jun 2025 15:02:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 6/8] pdx: introduce a new compression algorithm based on
 offsets between regions
To: Roger Pau Monne 
Cc: Anthony PERARD ,
 Andrew Cooper ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk ,
 xen-devel@lists.xenproject.org
References: <20250611171636.5674-1-roger.pau@citrix.com>
 <20250611171636.5674-7-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: <20250611171636.5674-7-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 11.06.2025 19:16, Roger Pau Monne wrote:
> With the appearance of Intel Sierra Forest and Granite Rapids it's not
> possible to get a production x86 host wit the following memory map:
> 
> SRAT: Node 0 PXM 0 [0000000000000000, 000000007fffffff]
> SRAT: Node 0 PXM 0 [0000000100000000, 000000407fffffff]
> SRAT: Node 1 PXM 1 [0000061e80000000, 0000065e7fffffff]
> SRAT: Node 2 PXM 2 [00000c3e80000000, 00000c7e7fffffff]
> SRAT: Node 3 PXM 3 [0000125e80000000, 0000129e7fffffff]

Looks like these aren't the numbers that the test harness uses. The main
properties (relevant for the algorithms) look to be the same, though.

> ---
> We can discuss whether we want both the fast and the slow variants.  The
> slow (brute force) was added as a result of me playing with weird region
> layouts where the fast one didn't manage to compress, or the resulting
> coefficients had a poor compression ratio.  However at this point the
> slow variant has only proven helpful in synthetic cases, I haven't (yet?)
> seen a real host memory layout that would benefit from it.

I'm not convinced we need the slow variant right away. What exactly (if
anything) is going to be wanted/needed on future hardware we'll only really
know when such arrives. However, see also my comment on xen/pdx.h.

> @@ -297,7 +309,223 @@ void __init pfn_pdx_compression_reset(void)
>      pfn_pdx_hole_shift = 0;
>  }
>  
> -#endif /* CONFIG_PDX_COMPRESSION */
> +#elif defined(CONFIG_PDX_OFFSET_COMPRESSION) /* CONFIG_PDX_MASK_COMPRESSION */
> +
> +unsigned long __ro_after_init pdx_offset = ~0UL;
> +unsigned long __ro_after_init pdx_size = ~0UL;
> +
> +static unsigned long __initdata top_pfn;
> +
> +bool pdx_is_region_compressible(paddr_t base, unsigned long npages)
> +{
> +    return !pdx_size ? true
> +                     : (PFN_DOWN(base) % pdx_offset) + npages <= pdx_size;
> +}
> +
> +STATIC bool __init pfn_offset_calculate_fast(unsigned long base)
> +{
> +    unsigned long size = max((1UL << MAX_ORDER), base);

Since pfn_pdx_compression_setup(), where "base" originally comes from, has no
caller (yet), it's hard to follow what "base" is and why it would affect "size".

> +    unsigned long offset = ~0UL;
> +    unsigned int i;
> +
> +    if ( nr <= 1 )
> +        return false;
> +
> +    /* Calculate minimal offset between regions. */
> +    for ( i = 1; i < nr; i++ )
> +        offset = min(offset, ranges[i].base - ranges[i - 1].base);
> +
> +    /* Return early if offset is smaller than the minimum size. */
> +    if ( size >= offset )
> +        return false;

Comment and code are off by one with one another. I actually wonder whether, for
the scheme to be beneficial, there shouldn't be some threshold below which we
would also go without doing any compression.

> --- a/xen/include/xen/pdx.h
> +++ b/xen/include/xen/pdx.h
> @@ -65,6 +65,31 @@
>   * This scheme also holds for multiple regions, where HHHHHHH acts as
>   * the region identifier and LLLLLL fully contains the span of every
>   * region involved.
> + *
> + * ## PDX offset compression
> + *
> + * Alternative compression mechanism that relies on RAM ranges having a similar
> + * size and offset between them:
> + *
> + * ┌────────┬──────────┬────────┬──────────┐   ┌────────┬──────────┐
> + * │ RAM 0  │          │ RAM 1  │          │...│ RAM N  │          │
> + * ├────────┼──────────┼────────┴──────────┘   └────────┴──────────┘
> + * │<------>│          │
> + * │  size             │
> + * │<----------------->│
> + *         offset
> + *
> + * The compression removes the holes between RAM regions:
> + *
> + * ┌────────┬────────┐   ┌────────┐
> + * │ RAM 0  │ RAM 1  │...│ RAM N  │
> + * ├────────┼────────┘   └────────┘
> + * │<------>│
> + *    size
> + *
> + * The compressed index is calculated as:
> + *
> + * index = (pfn % offset) + ((pfn / offset) * size)
>   */

Would be nice imo if the presentation here wouldn't give the impression that
the offsets are all identical, and hence the compressed map ends up being
entirely without holes. In fact I can't help the impression that with enough
nodes (but otherwise the same properties, i.e. only node 0 being special) at
least the "fast" calculation will fail. Which in turn would be an argument
to keep the "slow" one.

In fact, the alternative approach we discussed - avoiding division, but
using a table of offsets - would seem to avoid such a weakness, because the
offsets can then vary (to some degree; it still needs to be possible to
easily determine the table indexes).

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 13:37:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 13:37:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019146.1395959 (Exim 4.92)
	(envelope-from )
	id 1uRsyW-0006EF-31; Wed, 18 Jun 2025 13:37:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019146.1395959; Wed, 18 Jun 2025 13:37: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 1uRsyV-0006E8-VP; Wed, 18 Jun 2025 13:37:11 +0000
Received: by outflank-mailman (input) for mailman id 1019146;
 Wed, 18 Jun 2025 13:37: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 1uRsyU-0006E2-DW
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 13:37:10 +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 548789f3-4c49-11f0-b894-0df219b8e170;
 Wed, 18 Jun 2025 15:37:08 +0200 (CEST)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3a52874d593so6652951f8f.0
 for ; Wed, 18 Jun 2025 06:37:08 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2365dea8ccbsm99555215ad.167.2025.06.18.06.37.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Jun 2025 06:37:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 548789f3-4c49-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750253828; x=1750858628; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=yJL88hOBVpsqrYLl/1QUiovMp1GO6402vxPEz45dK1g=;
        b=RPOfr7g+qRQs39NRxdZaHcxjHIgDktAwplWOPtZpkNqWs6sV4W+kHe+5mIZb7Pp9+9
         sD7GkUYmgYVxHlc7qbvMyKlhD8FkAbflFheUHsdXRt1kCuukd/UJbNiQ9Dbi0JDJ53R+
         lBBGoKQJEOnRb4NbC/g1c+n05BhtTJhhS/6TdJhcIBFrE+3cYYxeP1Yj0t7Uz9Ux8ZBc
         IfrglqQIufY+KK0pTx5luysaqcsMr2tdMmsZnkPnw/4jbgAtmqoiN3yQUa/fLpnaBHyA
         Mx9gWHT0JVqcYGAyEaI8wNxC9OXAwRlu5E4CIueCjvFbib/z3WSZOb0KceD7G/X2ZY/p
         rGPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750253828; x=1750858628;
        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=yJL88hOBVpsqrYLl/1QUiovMp1GO6402vxPEz45dK1g=;
        b=bH85xweZ0U74lHaPvuRZEmxWbCMBtaSpBR8QFBUIf6tBkpg6OnD94hfakwNe1SpzNe
         hDbJpR42msZgX20rX+G924KHZedMroEM6/SB44lsdfEQcdc6MKsMntvoCM+ym+CJhbED
         ynUKpnmhEKAAy+fbSxsQeEAHIFLExwghpBuOztYid1Z1y6CnfAHOA6eii7kPNhLm9c6l
         CmuYpmy+puzNClI/MW8tPTMMFUkPEOLl75MQ2oj7isDuNb+CnePcEG/orz8El9xt6vqD
         LwL1bA6e5yySvryfnaQm4dk9awe4cDKrNm8yeEnV1scOte7cpFl7FATeZKr1etBJdxcE
         5rlg==
X-Forwarded-Encrypted: i=1; AJvYcCXsUqx7rAuWJ9thnOZN+TtYkgYFruL9XxjBD5ZPhpUZPvTMODb3pvhslgOypzxQt4AodrhsH4MtQsQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz+HtFAL7VQ84Mis9k2H77QoPtawcEEa31ulfk3ch00gXkmsGpp
	W4B6Lb/1CRU5UfqytmNB5jR3pVe+DBVspLcvF8jc/3mjMfulwp9Vik78AI+1u9pDVw==
X-Gm-Gg: ASbGncvTDOB4QGCwEOdluzQfuO1ONowv3ITl+VTdQDJSBum4TRbMkOG5KtFlpTlHhEe
	jY90OjOBFDDApIcIBClxg5Dl2qW7isYVH6/ZJP8lv44DQXbPwfOCf1w3hEIKfOmz4ZoVV3qKO5d
	kZb1tKKZ7gpyVLaO9FmA5AAH2YAxwFJU2tF/ynp4Devksv3ckXFKGg2wnLrt3/cRfLJLkM8lWW1
	IBloiOIj5pmGjoDNE5+Rh7InGHy85/ztVIQmD4Cnb+hrDOCxuEULgiDbzQ19ix4iPXPKwBeYIn3
	7CP/iJ6VjI4RBhtP+67bDgQ0A+Vvt01o4AKGirRFwezamenPTt+kiDjeuSs/LtfjtxZ4xjJIpwl
	cEItLHZl991AalvHKzkLdLW1KNPx6rnwXUz6JXDbEKyu0GfM=
X-Google-Smtp-Source: AGHT+IGtnXsHNrQLVBD0bzaC27DHO/yUYI+KAwunWfaAD8JTmdRkAy1X1GOjG5L5jm3KfBhRdamuxg==
X-Received: by 2002:a5d:6f01:0:b0:3a4:d8f8:fba7 with SMTP id ffacd0b85a97d-3a572367c78mr16514388f8f.2.1750253827823;
        Wed, 18 Jun 2025 06:37:07 -0700 (PDT)
Message-ID: <2d8f85aa-af34-4f4c-b3ce-52640cb207f5@suse.com>
Date: Wed, 18 Jun 2025 15:36:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 8/8] pdx: introduce a command line option for offset
 compression
To: Roger Pau Monne 
Cc: Oleksii Kurochko ,
 Community Manager ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250611171636.5674-1-roger.pau@citrix.com>
 <20250611171636.5674-9-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: <20250611171636.5674-9-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 11.06.2025 19:16, Roger Pau Monne wrote:
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -2072,6 +2072,28 @@ for all of them (`true`), only for those subject to XPTI (`xpti`) or for
>  those not subject to XPTI (`no-xpti`). The feature is used only in case
>  INVPCID is supported and not disabled via `invpcid=false`.
>  
> +### pdx-compress
> +> `=  | auto | fast | slow`
> +
> +> Default: `auto`
> +
> +Only relevant when hypervisor is build with PFN PDX offset compression
> +`CONFIG_PDX_OFFSET_COMPRESSION`.

Which, however, the name of the command line option doesn't reflect at all.
Question is what your thoughts were towards what if another compression
method also wanted a command line control.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 13:53:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 13:53:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019163.1395968 (Exim 4.92)
	(envelope-from )
	id 1uRtDo-0000bE-9z; Wed, 18 Jun 2025 13:53:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019163.1395968; Wed, 18 Jun 2025 13: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 1uRtDo-0000b7-7L; Wed, 18 Jun 2025 13:53:00 +0000
Received: by outflank-mailman (input) for mailman id 1019163;
 Wed, 18 Jun 2025 13:52: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 1uRtDm-0000Yo-4H
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 13:52:58 +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 895896d8-4c4b-11f0-b894-0df219b8e170;
 Wed, 18 Jun 2025 15:52:56 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-4530921461aso60294375e9.0
 for ; Wed, 18 Jun 2025 06:52:56 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b2fe1643e9esm10980563a12.25.2025.06.18.06.52.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Jun 2025 06:52:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 895896d8-4c4b-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750254775; x=1750859575; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=uc5JZqp0KcBw5BZMhGtpho3x8L9wD59HzL+T1EuClLU=;
        b=D7HMieMwdwV1hHEE59kGLNbUCPraC0s0mF9LXtbf31/2fYYo6NQn3vTzOFOuVdIOHz
         2kTKtPfZliBNkmOmgtNjLmbEJ4IfEdTptPLYbnnSERn9s2YX05XO1VzIJ8EGFkZde0fC
         kbxfMM7kJaPxurX97966fD/Z7y+2psWS3NB1UFzashVgmSpsG5xTMTDgDAIlyucIo8zu
         ciIMWy2Pb4p3xja5IZl0NieXlvJkbSKxPm6ENxAfLYKD7wqmsE5nUQVFKFUsq/F4nNyN
         dF9JKvn3UFBmjhWWSCoE4RRBjjqBTgmXPmsFwjRH96G5e82hc+GbV+JkCLR05qVbXCHQ
         ID9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750254775; x=1750859575;
        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=uc5JZqp0KcBw5BZMhGtpho3x8L9wD59HzL+T1EuClLU=;
        b=lXz49UOxz9P/45b1C90LrGvak0Npiq4aypAGHBFDyn3XyMatB7aIkYn/RXaLEt+COU
         +PT2ZIlbbdvAm/+hpC3cPdScY59Y7tvpDsgcGo0Ik/3wZP1apeQ6WCEVGh5fsq81UFfd
         m96jz/qlPz8yCrhSPn0D77YqwiWrkKJ4zsL9P/Vy2hXntXKc4FYgrUbOQaRtbvvIp1Bk
         BirVXUWmdMM4nTaaf/9nF02PYWsQsdUbZJxpFGcy+1uq/GOaT4DkPAHlvgNpDaE8CBMu
         i3Ac77oGGb7IsafIGMBPKw1oX4ZYJhzXrkrBn1tAlDxklKa4xSbYuUWlcaAQZckHUmpe
         IKXQ==
X-Forwarded-Encrypted: i=1; AJvYcCX5XU7rCdv3SCieGAm7NzF8BjV3asl4X4v4efItSb1EFFTTvBK0QVDrKlDBGpNQSlRFOl3Nq1c21Ko=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywul+q6epa8vjial5QovRDIAevceQEfbeGRQmFR4UccAwZiDHth
	qS7TqZ//Y8CKp+UnNMgU7y+Qsx/F1WIKLxieXlvRe99vUT2yaM9nLIH6ColJqUY01Q==
X-Gm-Gg: ASbGncsb3Tms7nnKExO0hYQg5o8Ts7iTXMG+f0Vz/mdQt93gyFvM3/f2s466BJ/8eoG
	1Jx9vRk4hprut2YEa4EDyMIoiiTp8cS3kIdFUHPtYOg/CkmyJ4YwBLCrqJZJISJv7YWuIgLIrmx
	UHafBQAlbAaWYafHcJN19c/7cwdXyYIOrObTjsNX0XN1bhq+RVK5bQdIbSd1aG617P3VeseAgyl
	FEbhwwZ3MSurppKk0tXH9axIj2WKVgjqc1Hs9w75X9LkDhukuyMrrdPSTIGvJpOKm2lEjGtGiZr
	NwTiliBZPSm/MTzUq1YGjuudGhmgK92Y5Nz4pUAlfwc1arwvo4eIf1rOpTrBs7HUj//oh+0JtZ6
	tE0QaD7Xo5uixsYWuYm3CfiIEK3+IR79tEpHDUBqMUbiyn/EUbD3NuXrZKg==
X-Google-Smtp-Source: AGHT+IGRYtbnGOvhggfbKkeWFzYfUjp9wqSSFxhrMYvveqq79veznrPNtMTGZGIFjxip74NZIrQ8Pw==
X-Received: by 2002:a05:6000:1887:b0:3a4:e393:11e2 with SMTP id ffacd0b85a97d-3a5723a22d6mr15087661f8f.34.1750254775356;
        Wed, 18 Jun 2025 06:52:55 -0700 (PDT)
Message-ID: <669877f5-ef34-4552-9cfc-e097d40d444a@suse.com>
Date: Wed, 18 Jun 2025 15:52:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 1/8] vpci/header: Emulate extended capability list for
 dom0
To: Jiqian Chen 
Cc: Huang Rui , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , xen-devel@lists.xenproject.org
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-2-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: <20250612092942.1450344-2-Jiqian.Chen@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12.06.2025 11:29, Jiqian Chen wrote:
> --- a/xen/drivers/vpci/header.c
> +++ b/xen/drivers/vpci/header.c
> @@ -836,6 +836,42 @@ static int vpci_init_capability_list(struct pci_dev *pdev)
>                                    PCI_STATUS_RSVDZ_MASK);
>  }
>  
> +static int vpci_init_ext_capability_list(struct pci_dev *pdev)
> +{
> +    unsigned int pos = PCI_CFG_SPACE_SIZE;
> +
> +    if ( !is_hardware_domain(pdev->domain) )
> +        /* Extended capabilities read as zero, write ignore for guest */

s/guest/DomU/ ?

> +        return vpci_add_register(pdev->vpci, vpci_read_val, NULL,
> +                                 pos, 4, (void *)0);
> +
> +    while ( pos >= PCI_CFG_SPACE_SIZE )
> +    {
> +        uint32_t header = pci_conf_read32(pdev->sbdf, pos);
> +        int rc;
> +
> +        if ( !header )
> +            return 0;

Is this a valid check to make for anything other than the first read? And even
if valid for the first one, shouldn't that also go through ...

> +        rc = vpci_add_register(pdev->vpci, vpci_read_val, vpci_hw_write32,
> +                               pos, 4, (void *)(uintptr_t)header);

... here?

> +        if ( rc == -EEXIST )
> +        {
> +            printk(XENLOG_WARNING
> +                   "%pd %pp: overlap in extended cap list, offset %#x\n",
> +                   pdev->domain, &pdev->sbdf, pos);
> +            return 0;
> +        }
> +
> +        if ( rc )
> +            return rc;
> +
> +        pos = PCI_EXT_CAP_NEXT(header);
> +    }

As a more general remark - this is imo the kind of situation where using
do ... while() would be better.

> --- a/xen/drivers/vpci/vpci.c
> +++ b/xen/drivers/vpci/vpci.c
> @@ -267,6 +267,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);
> +}

Iirc we've been there before, yet I continue to wonder whether we're doing
ourselves any good in allowing writes to something that certainly better
wouldn't change. Even if we limit this to Dom0.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 14:05:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 14:05:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019173.1395979 (Exim 4.92)
	(envelope-from )
	id 1uRtPj-0002TN-G6; Wed, 18 Jun 2025 14:05:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019173.1395979; Wed, 18 Jun 2025 14:05:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRtPj-0002TG-Cv; Wed, 18 Jun 2025 14:05:19 +0000
Received: by outflank-mailman (input) for mailman id 1019173;
 Wed, 18 Jun 2025 14:05: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 1uRtPi-0002TA-9F
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 14:05:18 +0000
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com
 [2a00:1450:4864:20::12e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 426709c9-4c4d-11f0-b894-0df219b8e170;
 Wed, 18 Jun 2025 16:05:16 +0200 (CEST)
Received: by mail-lf1-x12e.google.com with SMTP id
 2adb3069b0e04-5534edc646dso7433374e87.1
 for ; Wed, 18 Jun 2025 07:05:15 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-748ed8a6491sm1179421b3a.1.2025.06.18.07.05.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Jun 2025 07:05:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 426709c9-4c4d-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750255515; x=1750860315; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=HrNauj7Dv/2e5ZxaVJfUMDwVxhzpC1WcBA/E+PqJi2A=;
        b=UoK8GZgrXR+UH2fpxWlhOcUQkLoMVrED0+KfnGrLQ7NJ6Z1bN6ImFb/KqRbSrqIj0m
         J6Kfg4WwNnyMF+UlyU1YT57zFRitji9NasFknITtOHHbSUm/FuNBPjiYeYCzcpe98nlJ
         REvWz67sUXklbydGhmxa2XlPEkGOf03ilJcRaPJvyNVrvIPBxsJEG3Z2UFH7ALJ9Idv/
         zaehhsJ6ov/8uP12JaVoiURINLgJKV9FQuK3AE6ZaXVaK54ov5tPo2aWWycLq8Auho3+
         Q6YUHaqeeMWSGVfK329vl7HAB80heFu447WHGzmCSdWvzq8q/cZIEoqZP4/bUOvLBCR0
         w0VQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750255515; x=1750860315;
        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=HrNauj7Dv/2e5ZxaVJfUMDwVxhzpC1WcBA/E+PqJi2A=;
        b=AC6mhVQOzLCdmTFqlvI9Re81OVeDP9e1xF7a52CW90mQ1sxGdkstunHpurxXqgGOtu
         LC5nNwqrRqdoonNs3P8lHzPaYt2Hg07SuoGFLEYxgbMSj4GF6CvZ+dhx9X4XeMwUVs5m
         FtMkh2TCI8bXvrOqKiuL0CVlscuow3EnoKn4myCQWDV8cDT8xK56P8nw5N0mWhOSckQq
         dP7SGM1Bp/2z3g6+4xyXSMJ7ftJ2ofvthFxjWX8kdFr5+9MeJ0gN/047KRJk7Fp/QVhs
         RKjHufVdCHz+H8jRyeuE/LHPTfyPXhIMZjg0o3vGITYHtNP2d9bQhSXosGeoEyCtUhDP
         X8lA==
X-Forwarded-Encrypted: i=1; AJvYcCVmGlK4TsPKHmgJWRjjWimRZdngtjQtLoJNYp9dLn9i3Za30xE3q7mdKMtkqwSueYfqA1Cdjl745A4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyeT6W54ntZGhpCl8MkJufxn5oJWcGvIm5GiLfOhqY3dXLcOfOE
	Ww3P8vzOQX9/ZqF0MgpfOSUs/MlDu/2MQbWJRa+zGnD3xGNrKv1XH98DD0g2lwPB0Q==
X-Gm-Gg: ASbGncv3owA3j3qcrtMFsJVwXGDqT4VoQP8dLs6IBm5F2pAzTyNbHMPU11vFmBA665q
	6qOnbtejE0nuileeve+qMKT7oM6V8ayOJPZ0kAMwvC+d/XLacxxacWctAzghs29HOOj5QNHsTuu
	0Y2vYN3YJ3f7Hwq0QYQCajXySwYepVETbuhB5IkbaTxCD5yMNIZtl96vYci8TNG76k9zmAugFeb
	IRNDRoRtk/j2KSutf2lVczDQpryNHRanZVKspV54Arflsau3QWTvJZEBSTdZBF57BwRwAwKQPlc
	erf+bB3Q39iE8Xel+/XICU5nU/jDRNBoLSFxnwPALYEbdmEP8guX4dX2SJw6728zkDtqo7w9STf
	wUxCw4Pt1WYOHYziGScryKMoRl6KbabLkS4SahA4JDev+NKY=
X-Google-Smtp-Source: AGHT+IGZWZ6TWBH05InKBCAkg1vMRsxZqMs9iWSHwf04GeVkAFeje1/SWFg7A6M/rlr0aqvV7DrV7A==
X-Received: by 2002:a05:6512:2344:b0:553:2e4e:cf74 with SMTP id 2adb3069b0e04-553b6f28380mr4829840e87.27.1750255514901;
        Wed, 18 Jun 2025 07:05:14 -0700 (PDT)
Message-ID: <516a3adc-320d-46ce-b235-8ef91469abcf@suse.com>
Date: Wed, 18 Jun 2025 16:05:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
To: Jiqian Chen 
Cc: Huang Rui , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-3-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: <20250612092942.1450344-3-Jiqian.Chen@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12.06.2025 11:29, Jiqian Chen wrote:
> --- a/xen/drivers/vpci/msix.c
> +++ b/xen/drivers/vpci/msix.c
> @@ -703,9 +703,13 @@ static int cf_check init_msix(struct pci_dev *pdev)
>      pdev->vpci->msix = msix;
>      list_add(&msix->next, &d->arch.hvm.msix_tables);
>  
> -    return 0;
> +    spin_lock(&pdev->vpci->lock);
> +    rc = vpci_make_msix_hole(pdev);
> +    spin_unlock(&pdev->vpci->lock);

If you add a call to vpci_make_msix_hole() here, doesn't it need (or at
least want) removing somewhere else? Otherwise maybe a code comment is
warranted next to the new call site?

> @@ -29,9 +30,22 @@ typedef int vpci_register_init_t(struct pci_dev *dev);
>   */
>  #define VPCI_MAX_VIRT_DEV       (PCI_SLOT(~0) + 1)
>  
> -#define REGISTER_VPCI_INIT(x, p)                \
> -  static vpci_register_init_t *const x##_entry  \
> -               __used_section(".data.vpci." p) = (x)
> +#define REGISTER_VPCI_CAPABILITY(cap, finit, fclean, ext) \
> +    static const vpci_capability_t finit##_t = { \
> +        .id = (cap), \
> +        .init = (finit), \
> +        .cleanup = (fclean), \
> +        .is_ext = (ext), \
> +    }; \
> +    static const vpci_capability_t *const finit##_entry  \
> +        __used_section(".data.rel.ro.vpci") = &finit##_t

Could you remind me why the extra level of indirection is necessary here?
That is, why can't .data.rel.ro.vpci be an array of vpci_capability_t?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 14:10:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 14:10:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019184.1395989 (Exim 4.92)
	(envelope-from )
	id 1uRtUI-0003Ab-1q; Wed, 18 Jun 2025 14:10:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019184.1395989; Wed, 18 Jun 2025 14:10: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 1uRtUH-0003A6-UV; Wed, 18 Jun 2025 14:10:01 +0000
Received: by outflank-mailman (input) for mailman id 1019184;
 Wed, 18 Jun 2025 14:10: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 1uRtUG-00032R-Fk
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 14:10:00 +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 eadc7465-4c4d-11f0-b894-0df219b8e170;
 Wed, 18 Jun 2025 16:09:58 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a57ae5cb17so2656319f8f.0
 for ; Wed, 18 Jun 2025 07:09:58 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2365deb0fb6sm99751705ad.141.2025.06.18.07.09.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Jun 2025 07:09:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: eadc7465-4c4d-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750255798; x=1750860598; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=OhT1zx6JccnBdWNMrHxFQ1QUZW/lQrxQ4Krw0e9okG8=;
        b=ffPzX6YLCAXaQX/C3MvubKpyiOlSxBCBuIJB8nsbNhn0elHi4g5fD9qfOvyIIybdc3
         GnGN1KlUP9n81aqU+zSoYOLz5t2FpAreTUqYdrWIoDcsb0etRu/2mu+KksPwsu0oSrpv
         JEkOWk06pG628bEYp8kkidNaN5oaDD+AkUFh/Cmtn0bxnJ0Wwp24+X9sVkIEcw0/SqHA
         QndjsU5W8zACpn94LT7cqKxVyxZiJFlQ/RMYhFbUcfXH32f6rTURZirWSxSEg/RbdmlO
         KNH3Ud3CYOKKxtx8DCMatTpg//FouYgT+31RDV+lxmstis1kVjAf0BgUgoxPjfXAKh36
         0wMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750255798; x=1750860598;
        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=OhT1zx6JccnBdWNMrHxFQ1QUZW/lQrxQ4Krw0e9okG8=;
        b=ajzHERbbBhmKCAgI2UIIxq7ExykAky78OsDjTzcxUSDgv5qOIYoLxMapkCjxItwjRN
         0b+ssfqP3bEezVPhkgUheDPQbCCDip+INNMTVSzk1kjYgNimJ4H/PjJQ3GULIGsygX9j
         gxy+v+z7yY4glhIySmm8JS9frn8trbkxgYoUyy6V7249hPZ0JKMusZ44xAz1t7XwBjfB
         hGG9+NXI00hEuEmcujFkykbhmr33Q0/tPz2O50Lzvrac1c0u81Gmz5FvO/VjAbilNTih
         B5Oci+m6nVBpKb4HZyxmKQ0ulbR4H31BQDAvBE713ZvyYhFT2v50GcolnCUzY+msAY2O
         /kvQ==
X-Forwarded-Encrypted: i=1; AJvYcCViL4z74oy8dSJKdi7Hl9IazBKzkbFkGw30BZ4liZ4+AopdbzYmBx/UDNsynV06q2y1NYbZSlW3GvU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwTEeLYh+7LdEUKPjWo9rcd2q2rSRILcyvDxRFtLw7UraCUlOob
	H0K0k2frNGcQKuUsO89AGq4yXe3ImLk53HI2ZQHzRiQ+gV5F8VvP0HV97zhbaH1sIw==
X-Gm-Gg: ASbGncvZWworD1ENGB9oQjfT6gT9bA5U/O8vIWvBT4ghy0KLaHKRCBZPHuVNaoFfgwr
	xspSxywuJQ7mosGZP0CQyt4BH483TAIAjj+xbM/hUqsyEFhDkr3K9p8JVRmLGTzPOo1jnYZrZUQ
	PFANOL7ruNllOyJGPfutvLCJ4oiEj/VjIlbtTUtt8BGpfgpeIQ3KR090M/3r6b55ZanjOT7PmGD
	jys/9Y1Vdtc0AaVtKxsv7K2g1s7mAyME9yRGd/L7rT5waHsfFl2/jTeD9lA7GPd1OraHWEVMPXe
	GBnTwDZENGjIIhiKzE7tqVuPPHAZbMchL8GhWsR8T1hE9PicXigfXE/yPYj/6BbWmzxIrhwrOZJ
	hkJoj82qkBfycFE/LTl59TtjZVzA2+IhZwHNIzpkyDodNwZH+bdJJF8pPhQ==
X-Google-Smtp-Source: AGHT+IHyFjCLMedXI0amUgisYJpJlE3OFtDzj4uxf623H4wD9c3jbg/mH9pLO3MbsP0b2Pwj91uqGw==
X-Received: by 2002:a5d:64ca:0:b0:3a3:6a9a:5ebf with SMTP id ffacd0b85a97d-3a5723a352dmr16818334f8f.20.1750255797893;
        Wed, 18 Jun 2025 07:09:57 -0700 (PDT)
Message-ID: <2708d242-1a11-4c2b-a3df-595b0bc23bfb@suse.com>
Date: Wed, 18 Jun 2025 16:09:50 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 3/8] vpci: Hide legacy capability when it fails to
 initialize
To: Jiqian Chen 
Cc: Huang Rui , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , xen-devel@lists.xenproject.org
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-4-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: <20250612092942.1450344-4-Jiqian.Chen@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12.06.2025 11:29, Jiqian Chen wrote:
> --- a/xen/drivers/vpci/vpci.c
> +++ b/xen/drivers/vpci/vpci.c
> @@ -83,6 +83,88 @@ static int assign_virtual_sbdf(struct pci_dev *pdev)
>  
>  #endif /* CONFIG_HAS_VPCI_GUEST_SUPPORT */
>  
> +static struct vpci_register *vpci_get_register(struct vpci *vpci,
> +                                               unsigned int offset,
> +                                               unsigned int size)
> +{
> +    struct vpci_register *r;
> +
> +    ASSERT(spin_is_locked(&vpci->lock));
> +
> +    list_for_each_entry ( r, &vpci->handlers, node )
> +    {
> +        if ( r->offset == offset && r->size == size )
> +            return r;
> +
> +        if ( offset <= r->offset )
> +            break;
> +    }
> +
> +    return NULL;
> +}
> +
> +static struct vpci_register *vpci_get_previous_cap_register(
> +    struct vpci *vpci, unsigned int offset)
> +{
> +    uint32_t next;
> +    struct vpci_register *r;
> +
> +    if ( offset < 0x40 )
> +    {
> +        ASSERT_UNREACHABLE();
> +        return NULL;
> +    }
> +
> +    for ( r = vpci_get_register(vpci, PCI_CAPABILITY_LIST, 1); r;
> +          r = next >= 0x40 ? vpci_get_register(vpci,
> +                                               next + PCI_CAP_LIST_NEXT, 1)
> +                           : NULL )
> +    {
> +        next = (uint32_t)(uintptr_t)r->private;
> +        ASSERT(next == (uintptr_t)r->private);
> +        if ( next == offset )
> +            break;
> +    }
> +
> +    return r;
> +}
> +
> +static int vpci_capability_hide(struct pci_dev *pdev, unsigned int cap)

I really only noticed it in the next patch, but the question applies equally
here: Any reason the first parameter isn't pointer-to-const?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 14:11:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 14:11:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019195.1395998 (Exim 4.92)
	(envelope-from )
	id 1uRtVv-0004dy-AY; Wed, 18 Jun 2025 14:11:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019195.1395998; Wed, 18 Jun 2025 14:11:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRtVv-0004dr-7s; Wed, 18 Jun 2025 14:11:43 +0000
Received: by outflank-mailman (input) for mailman id 1019195;
 Wed, 18 Jun 2025 14:11: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 1uRtVt-0004dD-CT
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 14:11:41 +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 1f198846-4c4e-11f0-b894-0df219b8e170;
 Wed, 18 Jun 2025 16:11:26 +0200 (CEST)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-45347d6cba3so11280055e9.0
 for ; Wed, 18 Jun 2025 07:11:26 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a568b2371bsm17158389f8f.70.2025.06.18.07.11.23
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 18 Jun 2025 07:11:23 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1f198846-4c4e-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750255886; x=1750860686; 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=T+D/J9O1NLio4YTbb/PkzggLIEPFuRsZgdPFbHBAqYc=;
        b=wKeTx0J4VvK2cm6ACNeGOu/s07ViRxCe/QpUXAd6tS784O2toQbPQwjxBtFS84/neE
         0adYWOccYNW+oTMQDFy1RNlk0z1o1U/HJjAuW23S3OcX+O5/0lKV5vq1TbonjU5KzNjc
         YzJB1gJirEgMpKQnQhPi0seLZAasZpyX/mpcg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750255886; x=1750860686;
        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=T+D/J9O1NLio4YTbb/PkzggLIEPFuRsZgdPFbHBAqYc=;
        b=FO8N6wnSybpHD9HKUQTkj+VJPE/irUKWmangSeoVHTVWYqUxuEukCPp7ZgOUlFcWlq
         cElcibyJ4xqIFtn8qY1PJFIjwh0S0uKnwPgtiKfzghistSWzDM1QVDMcBjddRtpZj5Qb
         jm49x3mRd3+tjm2jcJuP12LPlAMPPuvhUXFZTVWVI3c5W/86S2sn+v+/GWCSb4jUHyVm
         P0MvC7tqBa8+Y3oWsm37cNgw7p7HkA7/fX+ZAIgvyndI9rO4s9ifIiwWg/WxPPh5PSuq
         9GkXzfk92kMVL6tUgY1FrQ3iLcLIJ984x4fZNAzXHgJedY4LA8LzUW/fyi4JrM5uP1pO
         FGCw==
X-Forwarded-Encrypted: i=1; AJvYcCVwspgDgpS8whPfnifd8neJfNk0zBQVAcXxV2LCG+CeaxdK0RSM87zC2SmyjL5c/uGLDP48RjtN7NI=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxkryiz2v/Fxo+wAWY5axHVKllcxvJC49HZfGoF4MGLMXavUXP4
	JIUC2Ol3lI8VfYw+2rrK89ac5zr09XNbIoG5S22V5J8lLmx93iCo4DawcBP0aUi8MqM=
X-Gm-Gg: ASbGnctHh3RRw4gCz7C9I5p/xw9253p6tklQMnUqAMD5rGFyzLdrVeGyeWjHwtB0dhe
	MFflsH/eyTbTYEqDqRmwzC3TqHQlzZ0H5cURvZHkTyRcDnnQQr89jMEi95aMh+WeFPhwJoyGJ1D
	jsZn68RjFm4sOqf06DWkAc+bLwqjTbKLHFO96QKck5KaCmmvE6/K1l2CbDgtBCkB2WWKLtMwR6u
	/BDlxfzoS6tARqGmx4xn219l9HahIP/HzExLNuD5KdnhBwYr21kbp/cOjDIDEgR8hxqmec0/CpZ
	sx4+HQf2NgpqKOKNScNIqyg7tf8nnluMQC/uU7FiGMSLQ9cvAVJd4bDMXYW4N9HR6rixK/icUoa
	HDjFgfyu1I1Q7+vYyt4JKqAxV8UBq3vCZYs/jWy+PglAg4A==
X-Google-Smtp-Source: AGHT+IGTgMdhwjTWJh/W9J/dOM7d5EylSk5h5aRCf6iM6ib8VKtoeSAirUu9qX3Mf0Zz0qYBP6h1JQ==
X-Received: by 2002:a05:600c:4f43:b0:448:e8c0:c778 with SMTP id 5b1f17b1804b1-453514a1e54mr74522565e9.22.1750255884049;
        Wed, 18 Jun 2025 07:11:24 -0700 (PDT)
Date: Wed, 18 Jun 2025 16:11:22 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Anthony PERARD ,
	Andrew Cooper ,
	Michal Orzel , Julien Grall ,
	Stefano Stabellini ,
	Bertrand Marquis ,
	Volodymyr Babchuk ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 6/8] pdx: introduce a new compression algorithm based on
 offsets between regions
Message-ID: 
References: <20250611171636.5674-1-roger.pau@citrix.com>
 <20250611171636.5674-7-roger.pau@citrix.com>
 <4e8efcc9-9721-450b-b27c-2caac4aedfb7@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4e8efcc9-9721-450b-b27c-2caac4aedfb7@suse.com>

On Wed, Jun 18, 2025 at 03:02:34PM +0200, Jan Beulich wrote:
> On 11.06.2025 19:16, Roger Pau Monne wrote:
> > With the appearance of Intel Sierra Forest and Granite Rapids it's not
> > possible to get a production x86 host wit the following memory map:
> > 
> > SRAT: Node 0 PXM 0 [0000000000000000, 000000007fffffff]
> > SRAT: Node 0 PXM 0 [0000000100000000, 000000407fffffff]
> > SRAT: Node 1 PXM 1 [0000061e80000000, 0000065e7fffffff]
> > SRAT: Node 2 PXM 2 [00000c3e80000000, 00000c7e7fffffff]
> > SRAT: Node 3 PXM 3 [0000125e80000000, 0000129e7fffffff]
> 
> Looks like these aren't the numbers that the test harness uses. The main
> properties (relevant for the algorithms) look to be the same, though.

Yeah, seems like the report we got has two different memory setups,
one with 1TB, and one with 2TB of total RAM.  The layout however
(offsets) are the same.

> > ---
> > We can discuss whether we want both the fast and the slow variants.  The
> > slow (brute force) was added as a result of me playing with weird region
> > layouts where the fast one didn't manage to compress, or the resulting
> > coefficients had a poor compression ratio.  However at this point the
> > slow variant has only proven helpful in synthetic cases, I haven't (yet?)
> > seen a real host memory layout that would benefit from it.
> 
> I'm not convinced we need the slow variant right away. What exactly (if
> anything) is going to be wanted/needed on future hardware we'll only really
> know when such arrives. However, see also my comment on xen/pdx.h.

I've implemented the lookup table as you suggested, and I think that's
more efficient than the current div plus mod.  With the lookup table
implementation there's no longer a fast vs slow variants.

> > @@ -297,7 +309,223 @@ void __init pfn_pdx_compression_reset(void)
> >      pfn_pdx_hole_shift = 0;
> >  }
> >  
> > -#endif /* CONFIG_PDX_COMPRESSION */
> > +#elif defined(CONFIG_PDX_OFFSET_COMPRESSION) /* CONFIG_PDX_MASK_COMPRESSION */
> > +
> > +unsigned long __ro_after_init pdx_offset = ~0UL;
> > +unsigned long __ro_after_init pdx_size = ~0UL;
> > +
> > +static unsigned long __initdata top_pfn;
> > +
> > +bool pdx_is_region_compressible(paddr_t base, unsigned long npages)
> > +{
> > +    return !pdx_size ? true
> > +                     : (PFN_DOWN(base) % pdx_offset) + npages <= pdx_size;
> > +}
> > +
> > +STATIC bool __init pfn_offset_calculate_fast(unsigned long base)
> > +{
> > +    unsigned long size = max((1UL << MAX_ORDER), base);
> 
> Since pfn_pdx_compression_setup(), where "base" originally comes from, has no
> caller (yet), it's hard to follow what "base" is and why it would affect "size".

pfn_pdx_compression_setup() has existing callers from patch 4: "pdx:
provide a unified set of unit functions".

> > +    unsigned long offset = ~0UL;
> > +    unsigned int i;
> > +
> > +    if ( nr <= 1 )
> > +        return false;
> > +
> > +    /* Calculate minimal offset between regions. */
> > +    for ( i = 1; i < nr; i++ )
> > +        offset = min(offset, ranges[i].base - ranges[i - 1].base);
> > +
> > +    /* Return early if offset is smaller than the minimum size. */
> > +    if ( size >= offset )
> > +        return false;
> 
> Comment and code are off by one with one another. I actually wonder whether, for
> the scheme to be beneficial, there shouldn't be some threshold below which we
> would also go without doing any compression.

Yeah, I've wondered the same, but I didn't know where to put the
threshold.

> > --- a/xen/include/xen/pdx.h
> > +++ b/xen/include/xen/pdx.h
> > @@ -65,6 +65,31 @@
> >   * This scheme also holds for multiple regions, where HHHHHHH acts as
> >   * the region identifier and LLLLLL fully contains the span of every
> >   * region involved.
> > + *
> > + * ## PDX offset compression
> > + *
> > + * Alternative compression mechanism that relies on RAM ranges having a similar
> > + * size and offset between them:
> > + *
> > + * ┌────────┬──────────┬────────┬──────────┐   ┌────────┬──────────┐
> > + * │ RAM 0  │          │ RAM 1  │          │...│ RAM N  │          │
> > + * ├────────┼──────────┼────────┴──────────┘   └────────┴──────────┘
> > + * │<------>│          │
> > + * │  size             │
> > + * │<----------------->│
> > + *         offset
> > + *
> > + * The compression removes the holes between RAM regions:
> > + *
> > + * ┌────────┬────────┐   ┌────────┐
> > + * │ RAM 0  │ RAM 1  │...│ RAM N  │
> > + * ├────────┼────────┘   └────────┘
> > + * │<------>│
> > + *    size
> > + *
> > + * The compressed index is calculated as:
> > + *
> > + * index = (pfn % offset) + ((pfn / offset) * size)
> >   */
> 
> Would be nice imo if the presentation here wouldn't give the impression that
> the offsets are all identical, and hence the compressed map ends up being
> entirely without holes.

OK, I've made this too nice I guess.

> In fact I can't help the impression that with enough
> nodes (but otherwise the same properties, i.e. only node 0 being special) at
> least the "fast" calculation will fail. Which in turn would be an argument
> to keep the "slow" one.

It depends.  Fast calculation assumes the minimal offset and then just
adjusts the size.  If the offset is not the same between ranges this
leads to size being expanded to ensure the selected offset works with
all ranges.  If there are enough nodes, and spread enough it's
possible for the algorithm to converge in offset == size.

> In fact, the alternative approach we discussed - avoiding division, but
> using a table of offsets - would seem to avoid such a weakness, because the
> offsets can then vary (to some degree; it still needs to be possible to
> easily determine the table indexes).

Yeah, that's what I'm preparing to send.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 14:13:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 14:13:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019206.1396009 (Exim 4.92)
	(envelope-from )
	id 1uRtXA-00059e-K1; Wed, 18 Jun 2025 14:13:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019206.1396009; Wed, 18 Jun 2025 14: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 1uRtXA-00059X-HB; Wed, 18 Jun 2025 14:13:00 +0000
Received: by outflank-mailman (input) for mailman id 1019206;
 Wed, 18 Jun 2025 14:12: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 1uRtX8-00059I-OD
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 14:12:58 +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 5525d843-4c4e-11f0-b894-0df219b8e170;
 Wed, 18 Jun 2025 16:12:57 +0200 (CEST)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-451d6ade159so59096875e9.1
 for ; Wed, 18 Jun 2025 07:12:56 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-453424cbe40sm132939475e9.21.2025.06.18.07.12.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 18 Jun 2025 07:12:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5525d843-4c4e-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750255976; x=1750860776; 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=8e0YMqmnQhgZziqUpEQZoFJcgoBEqaAvlH6FlIkAf+w=;
        b=qzHr2XGEHczYkeIFDuaBuow5H1TDM3mk6YNWerTOgH/X48kr23JRIh1TWw+qdBDc6W
         PyafKXJesvYGfKpguz7dbQyDz1qwXMVLh1sM/UHEf3A7w1RQiswZLem/wqYqBBeprmNV
         tohc/dUxM0QxIkAuZwrScdGC5TbHgZOt+rqMk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750255976; x=1750860776;
        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=8e0YMqmnQhgZziqUpEQZoFJcgoBEqaAvlH6FlIkAf+w=;
        b=MmqPR0qlkLHq4hvt429H84p3az3hjZbs33sW9BY7JD8Jzp/53H7qAxaJuIcNay2LIW
         +s4TyZQp7zioFHWJ3/aiafprYqCDZVHSMyLwhuRzFVRY6zV5yT4S8DPINipIeZKp30v2
         vCMDENh9n71yr5NK9er14OIsJat0OrNvK4cAfafv98bS6/yA9mo7+JbABwW8JDlgdKej
         U5n4cnDjO3ULFiXu3lmJr/RX8/QOXRPx8N830VGypWFgXa99wYreF1wLwcXGjeSXUCEH
         NzTBC7GUYoth50NzGh9al2WaSC6VJaonU4S2hTM5DLgc6xr8TkMzPt4ijS8Szaj8K/kG
         XTug==
X-Forwarded-Encrypted: i=1; AJvYcCXRf7ZT3c3mrUUA9iUN6HKKWJi7bLjECk0VzJmG+/5pkps+k/7PKDfYA9PF9iuBgkKun7POEEKbYco=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy+xmtvCMbz2xhjMy8eGjt/CVmL7hetAALi6rvQ9iNkWbfDlYba
	IoVirMG1sP7SXchFZU7QDUe14ztQI6pWqwoDayIsDPMoVJ3kwhctkpyg/+EZXwoVSRE=
X-Gm-Gg: ASbGncudPS3/3ZIUmHbbc0HyW8QeDWbRUhIC0kiMDSK5VcbDYkPX1BfzJzwZJ81GT/a
	sUUt9BGZFMWgeh6W7w1UeEmVttVqPxt17AWObMmbknXTX5gxSztP1mtTHKFvQXxQhmZ4zaTi7yI
	OgQ35D+mmx+XWmEWjeWPEX964z8iRkF51hsFuklJXYvHlueolFrb6G9mg+jHXlfr64QTPp0P238
	nYZGc6znHiCar87l+6WcR1V70xoaUbAXEiw0uOzbv84sJXruyS8tRohb6kPkSHHq9Ujk3TCJ8RF
	AQbPVI2+K56MI3VzHGEu0Dwpelw9Y6g56R2RnWGsiMAj8ymyoAqOS2dj+v84JHvPfX7W78yUXp/
	Zxur2LfcpPDp02Fnc8DUnYfLwx6XEP/9GBXs=
X-Google-Smtp-Source: AGHT+IFKUkV/bCtr1wUwrOzQYoRtjXIta96Nq3d5QKhZmlFGVaFZs91jIJs/qRHybkwWjYE5h49loQ==
X-Received: by 2002:a05:600c:5253:b0:453:66f:b96e with SMTP id 5b1f17b1804b1-4534219a64fmr147021675e9.11.1750255976383;
        Wed, 18 Jun 2025 07:12:56 -0700 (PDT)
Date: Wed, 18 Jun 2025 16:12:55 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Oleksii Kurochko ,
	Community Manager ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 8/8] pdx: introduce a command line option for offset
 compression
Message-ID: 
References: <20250611171636.5674-1-roger.pau@citrix.com>
 <20250611171636.5674-9-roger.pau@citrix.com>
 <2d8f85aa-af34-4f4c-b3ce-52640cb207f5@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2d8f85aa-af34-4f4c-b3ce-52640cb207f5@suse.com>

On Wed, Jun 18, 2025 at 03:36:57PM +0200, Jan Beulich wrote:
> On 11.06.2025 19:16, Roger Pau Monne wrote:
> > --- a/docs/misc/xen-command-line.pandoc
> > +++ b/docs/misc/xen-command-line.pandoc
> > @@ -2072,6 +2072,28 @@ for all of them (`true`), only for those subject to XPTI (`xpti`) or for
> >  those not subject to XPTI (`no-xpti`). The feature is used only in case
> >  INVPCID is supported and not disabled via `invpcid=false`.
> >  
> > +### pdx-compress
> > +> `=  | auto | fast | slow`
> > +
> > +> Default: `auto`
> > +
> > +Only relevant when hypervisor is build with PFN PDX offset compression
> > +`CONFIG_PDX_OFFSET_COMPRESSION`.
> 
> Which, however, the name of the command line option doesn't reflect at all.
> Question is what your thoughts were towards what if another compression
> method also wanted a command line control.

This will become a boolean option that applies to all PDX
compressions: `pdx-compress = ` to enabled or disable PDX
compression.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 14:20:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 14:20:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019218.1396018 (Exim 4.92)
	(envelope-from )
	id 1uRtdw-0005qy-CH; Wed, 18 Jun 2025 14:20:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019218.1396018; Wed, 18 Jun 2025 14:20: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 1uRtdw-0005qr-9f; Wed, 18 Jun 2025 14:20:00 +0000
Received: by outflank-mailman (input) for mailman id 1019218;
 Wed, 18 Jun 2025 14:19: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 1uRtdv-0005ql-Lf
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 14:19:59 +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 4fc71f10-4c4f-11f0-b894-0df219b8e170;
 Wed, 18 Jun 2025 16:19:57 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3a589d99963so1699458f8f.1
 for ; Wed, 18 Jun 2025 07:19:57 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2365e0d0bc4sm100182125ad.243.2025.06.18.07.19.53
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Jun 2025 07:19:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4fc71f10-4c4f-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750256397; x=1750861197; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=jKA04hkWg40rxWLiApHLAhbT/IQ7ZTsGV2yPqcRpqTE=;
        b=B7WNl/a70980PL8a2hVhbFJazLC5oqjjHGWu6btrpu0WXDOwD88jDzPJHh2L2xHcRR
         VXnEVjd2PLOFjrUQAxv8kTg9DkzjSN8FgwGl2UCJ4gb+/YmKjWjTCxEAtVFzi30UG+vF
         pPmoV/oCNknX5E+R47N+u/BxSQi98zGaiWPIvv+1xiwyXA8Aw5Ndu3PWT2X5MQDFwy20
         rtYuSFVmFmtn40gwaKOqcMtdnVSL1wFQLE9qjQ3JKHJ/KC8YkSvf1LB87gFhaJIKqwPv
         8FNedKe9zZrwj8d93eBYWcRD+ruiPRGFjnZMOxoFOwyMRx5qcHXgcD34Ih8Aj5kiPK69
         9QFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750256397; x=1750861197;
        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=jKA04hkWg40rxWLiApHLAhbT/IQ7ZTsGV2yPqcRpqTE=;
        b=gRMTiXl89j87z/eBg46ZyM2CxVyij/+oeXe3RmgaLZ6FF3f4INJvEoDVSx9GaQy8el
         JOlW0/c9Q7zoepiZ8XlKvguytzev3XHBfLufRxi7bXJHAgBFwsIpCsmJTXoch5qoNjqt
         L3loW7Vz99gG31kA4eYafkb6z1vyNCNDW4XK7QYwaDQ/D2l6ACo/7fN6qm/r2qSOQj3i
         Ybbxz3z3rHAxj85MoTGynoghiNwyiVJhu8c2uwSz3aspD1dhlOf0x3X/1WGepLODUwLD
         unmOGOvFrtTnmnrHHaFNjNhccpjmTpheeMCr+gWQsh0Qn01h9260eYbjA+AD+Bchblef
         2jlQ==
X-Forwarded-Encrypted: i=1; AJvYcCWUxotMq/dZy9qgGgNcjk47lcker4CBoLMdOjCDqOJnhIl4TmZ+9mFrPPqx470G5c9NyJfmOZI/na8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywbl6brB/5+Ckzlq1kMFTQX4gChnA5qHwswSuF3sBFYcPZuqJa6
	qgeeIdFwTZdj4ICeyEbiVq6QkraH6jpQ/oaj5gtTuCyNaDju6WkZ9VPNxvhwcPgKpQ==
X-Gm-Gg: ASbGncuT/Azhf7rRpISEP3GzOFjK0i5092yEcjTrxo8IGdi1AUBPiliLiukCPKEeaDw
	zlq+OvUixZ5xYo9ArnkNxlk/gOSNsLz+mTZIpBbTGvtPFZKIl9XMyhgYYa0ZLFxyW73HPT/SMfz
	+oFqiyfqY5l1V2qG5Gy7ZoFo594Nxl3qHtdn5l/CLoP2PFxSBcCTnMhQtyn7cd/ib6H1/OqhKqt
	g2fZ0xTscQ08MxVMn3GL7uwqI40jo7RBtUp4X+9U1+jTpRF/SN5uh9uGS4xG87COoLs9Ddsv5hk
	bTtCgO+BHuqBCo9Ss1EpCZtnWVNTkbHAHcDGSHWl199uKpDaOCs8iykgnshIGbLquJ6Jv9TKCe7
	QkXmhM9K9YnO9vM4hb07oNYrPHxqG9bwm1oMfTu0JNuci9ts=
X-Google-Smtp-Source: AGHT+IGcg0W3NgZhAG14HkcKQ9nR2SvYsoXWHEYpLXyFV7obKihCegH3BKaUw24S2Xu1Cu0TsdvxUA==
X-Received: by 2002:a5d:64cb:0:b0:3a5:26fd:d450 with SMTP id ffacd0b85a97d-3a572e2dc2fmr14693628f8f.47.1750256396832;
        Wed, 18 Jun 2025 07:19:56 -0700 (PDT)
Message-ID: 
Date: Wed, 18 Jun 2025 16:19:49 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 3/8] vpci: Hide legacy capability when it fails to
 initialize
To: Jiqian Chen 
Cc: Huang Rui , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , xen-devel@lists.xenproject.org
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-4-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: <20250612092942.1450344-4-Jiqian.Chen@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12.06.2025 11:29, Jiqian Chen wrote:
> --- a/xen/drivers/vpci/vpci.c
> +++ b/xen/drivers/vpci/vpci.c
> @@ -83,6 +83,88 @@ static int assign_virtual_sbdf(struct pci_dev *pdev)
>  
>  #endif /* CONFIG_HAS_VPCI_GUEST_SUPPORT */
>  
> +static struct vpci_register *vpci_get_register(struct vpci *vpci,

Actually, even here (and then in all callers) the question arises why this
isn't pointer-to-const. I realize ...

> +                                               unsigned int offset,
> +                                               unsigned int size)
> +{
> +    struct vpci_register *r;

... this one may not want to be, as long as the function is required to
return pointer-to-non-const (assuming that property is actually required
anywhere).

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 14:27:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 14:27:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019224.1396028 (Exim 4.92)
	(envelope-from )
	id 1uRtlH-0007eS-3O; Wed, 18 Jun 2025 14:27:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019224.1396028; Wed, 18 Jun 2025 14:27:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRtlH-0007eL-0t; Wed, 18 Jun 2025 14:27:35 +0000
Received: by outflank-mailman (input) for mailman id 1019224;
 Wed, 18 Jun 2025 14:27:34 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uRtlG-0007eF-A8
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 14:27:34 +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 5f6a5ccd-4c50-11f0-a30a-13f23c93f187;
 Wed, 18 Jun 2025 16:27:33 +0200 (CEST)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3a365a6804eso5268711f8f.3
 for ; Wed, 18 Jun 2025 07:27:33 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2365dea903dsm100077235ad.158.2025.06.18.07.27.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Jun 2025 07:27:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5f6a5ccd-4c50-11f0-a30a-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750256852; x=1750861652; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=7gmVlrDR9sCAOkkXX3JtiVAQSKXhcXH/u9HopJyXKRc=;
        b=LwsKOTrjcfvS8ngLtsMMuKHiT+vqJKpcBjujYKxDbVv2bNQP9a8tP2Kh+0z7qfzVm9
         KCVDb/5+iDa4czy89ppYzf0Wi+0tGvgJWhZ2ZbxUVSeHpfY5Zij6nunCn2KUxu9X5104
         AITf6226g1ikdt5tHQxpyM31QacW06Xux97dYkozv72Krp3F3TScZpAIwuIyVj+se2W4
         EOQVnDn/j36Jw3p0Gq/Rah7xYplbWXLskStorlnVUqhbtQ124cKAJM3Hc5rPIgVdrhx3
         44Nw/wwb/3D7ZHhSNsCZCFWtAFnPgERfVOj7sxYpEcnYNElZnKPxM/tgirY6zlELcW7v
         I7GA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750256852; x=1750861652;
        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=7gmVlrDR9sCAOkkXX3JtiVAQSKXhcXH/u9HopJyXKRc=;
        b=FF3yxwRNBZFxu+h8uIqHAyJ3qDdeZ44FczO3adWe6D4PZk8QygOYDCzdDNJUp0wbSj
         FEAvmyirX819Em33B7cWeade9uPrFri86GKqLG/P5Ez0ANs92byOJR2O96jcXrzKPkmI
         LFMBu+nGLHn5dyD1+WSI9PdPikjD78DKMaY0GJolkbivqQ9q9Ev1A8okg30WcxuRdvlM
         eHwFUFdWQllBM4BHYNu/sYOG6Ho9aMvJ3nWlWacwH9O10KBDBCxdGTnutfrN5sU/1wW+
         4ZCAeqpkH4YT+3ovyOr+dU7uFjVXEEb+kbEP4ToB7eATI98lWdhYAo0vYsjYzIjbbzLK
         xcNQ==
X-Forwarded-Encrypted: i=1; AJvYcCWByW+OzmmzPaaGMm6JZwCtXCPcnKRLgnQmDdzk4KWEzIdRBszPBY6EjXIsF2Pzzftcqb0j2D1su/g=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxddIxEhL+hX/sR6aSiRWHQHA3T5axi4bHkh/B9QEp/FvQRSMVZ
	RXANWax1R5uuxGg2Qv84/bphj9sMiv8x3Vwqh3tTx0H+xHejrdxu5lX71dEAU7kDsA==
X-Gm-Gg: ASbGncu0TQod73I+cmkIzFEwLEPerQdLLpNtgqC8w/b7VbCKOEs3Im4mr+9mXi08P3n
	XWWiQvwaXImL+b3YVe4s7XM93HUFJbKRhDVpCdcYq+7WMB9N4VRv/F40PHdfnCnYgaYQf7zjflw
	tzWwZOxRzceuY924L2hWvCs6NeSkQr9+Qp5TaxPA7Nj579Cn9/P4VkLqS0tFnpbkR3taIpPFok5
	QZfQQRPdjJGR8r3l5Hh9GGnwRKQXTs/9oReCYmWKXU35E3s+2aSsmQbUD/DSm6gvLLwUqMncZQ6
	GnqCKKqy9TtVsJPvHW8b0A0WMRZnU/oyiaRvsecJneghcb7IoIk0putA7XIObYoPEo/D7X71LlY
	rAtnJA3d7SXInRNK8/Ywm3h/sM/mUV+88Epc/6++STwLgTak=
X-Google-Smtp-Source: AGHT+IGK0lI+zgB5Hcf+XR/zSLcglOJg6WfYsASlKFv0meGWnaCYIWeI50uTtYX/4HltGzSnAG5C6Q==
X-Received: by 2002:a5d:5f8d:0:b0:3a5:5270:a52c with SMTP id ffacd0b85a97d-3a57189727dmr15300531f8f.0.1750256852498;
        Wed, 18 Jun 2025 07:27:32 -0700 (PDT)
Message-ID: <816dd3fc-e6fc-40f6-b7c9-29d2411b52e5@suse.com>
Date: Wed, 18 Jun 2025 16:27:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 4/8] vpci: Hide extended capability when it fails to
 initialize
To: Jiqian Chen 
Cc: Huang Rui , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-5-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: <20250612092942.1450344-5-Jiqian.Chen@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12.06.2025 11:29, Jiqian Chen wrote:
> +static int vpci_ext_capability_hide(struct pci_dev *pdev, unsigned int cap)
> +{
> +    const unsigned int offset = pci_find_ext_capability(pdev->sbdf, cap);
> +    struct vpci_register *r, *prev_r;
> +    struct vpci *vpci = pdev->vpci;
> +    uint32_t header, pre_header;
> +
> +    if ( offset < PCI_CFG_SPACE_SIZE )
> +    {
> +        ASSERT_UNREACHABLE();
> +        return 0;
> +    }
> +
> +    spin_lock(&vpci->lock);
> +    r = vpci_get_register(vpci, offset, 4);
> +    if ( !r )
> +    {
> +        spin_unlock(&vpci->lock);
> +        return -ENODEV;
> +    }
> +
> +    header = (uint32_t)(uintptr_t)r->private;
> +    if ( offset == PCI_CFG_SPACE_SIZE )
> +    {
> +        if ( PCI_EXT_CAP_NEXT(header) <= PCI_CFG_SPACE_SIZE )
> +            r->private = (void *)(uintptr_t)0;
> +        else
> +            /*
> +             * The first extended capability (0x100) can not be removed from
> +             * the linked list, so instead mask its capability ID to return 0
> +             * and force OSes to skip it.
> +             */
> +            r->private = (void *)(uintptr_t)(header & ~PCI_EXT_CAP_ID(header));

Can we rely on OSes recognizing ID 0 as "just skip"? Since the size isn't encoded
in the header, there might be issues lurking here.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 14:34:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 14:34:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019232.1396039 (Exim 4.92)
	(envelope-from )
	id 1uRtrf-00012K-O6; Wed, 18 Jun 2025 14:34:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019232.1396039; Wed, 18 Jun 2025 14:34:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRtrf-00012C-L0; Wed, 18 Jun 2025 14:34:11 +0000
Received: by outflank-mailman (input) for mailman id 1019232;
 Wed, 18 Jun 2025 14:34: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 1uRtre-000125-76
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 14:34:10 +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 4ae04aaf-4c51-11f0-b894-0df219b8e170;
 Wed, 18 Jun 2025 16:34:08 +0200 (CEST)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-3a57c8e247cso3433952f8f.1
 for ; Wed, 18 Jun 2025 07:34:08 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-748900d0d90sm10991326b3a.155.2025.06.18.07.34.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Jun 2025 07:34:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4ae04aaf-4c51-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750257247; x=1750862047; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=c4ZDLYITV5axQdWqyesy+FnFzK6kGDsDGv7/1FtT6i8=;
        b=eB1KW7ym1bp0kwVMViUC9YerKYFCuD6giUqKszZcZp925Zu+UhCr36VipykOI4MssY
         XEuGPr5tLAS4BHbMqNjGzED3oaK5P/qxTw+7OhMX2epwuabLkhPfN5cYgptlp+e82DcF
         gLegNAByoe56Nz+Si8m9xRBdL8JSwDcpnT4PNRB6cXJrEjMFGzcMSbfEohxE1bBEWAYi
         /SjZZrazne37mDgeaMaW+65NTRPMVcwPonQZOjnoY3LUA8UcuOnynT87ewGzONC7lMkb
         D8ON+H6uHk9Hl2kG2g7FE7fMsnZ9/iJC8VTj5U0Hih6qThRGKpFT653OgFYgquIcI3hL
         U6SQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750257247; x=1750862047;
        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=c4ZDLYITV5axQdWqyesy+FnFzK6kGDsDGv7/1FtT6i8=;
        b=t/3Fi13rTzp2nDC+JvOqD4bftGDE4HJGxG8wXIkuHATP9yaqx76aFcnQT3cOlzVPdl
         Du7oo4CdV2Ly6zWkA7Qn/Sfu54fRO2XVo1mIvNyMMeRfgYLO8Zrqjbx6TS3x1TjWo1Vt
         L6tSLnJTvwO0QmsGp6q3NwbthFs1dJPrUOj5Fq6AO2LzMfeXXaOZ3jGcys0YL4+gGeG8
         tVvoQux/kVZXdGbyStq8d+uKENCF7CmN7gF0FAHJRTs7gMYQHo4k+NftleQybCH5PcA0
         F1jqwJLCtSDLPOERb7kVZCEdi0SEpbMWmZ58caWAhuPhYdj3dnAoTHgWrdJnvPrHPOqO
         RApw==
X-Forwarded-Encrypted: i=1; AJvYcCUqYrSRJX7bbNwO+c0y0HXlW4FZX+lgQo5QPFOzfjA+EdwJEq/LbTm95LOftYK/rssCbgQ5A6pTQfo=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxd0NZTcGY3UIymXj5rRNZfS2kjoJrrV4cOdta5325arjh+m5Ro
	Z98/D7s/R4q0y9N6iU2UJIyOhvLXZkQNlpG8qSn9E0sBSMJ9jsyeA9Yjolsjl+4edw==
X-Gm-Gg: ASbGncuS3bcM0pplA4WIGBf6ixb0L/066icqonuOTcuFssP2p2qTL5pNqXrUBKBVFTs
	Ch348uQMaYK1NZbyjV4RGzheCk/YLm9uIS7kVw3yLTMOnPCAsB5i23YrPAydVHmqupZl9hX+ChW
	HL8iASyc0ypIxFljprdgdQ5MoETmJU0KfHGrc8qG1D3JxW8ZYrrpNpZ0vQF9ZLI+9Wi3m39y5Us
	aDqHIaKDD2MGTPmbRXngTCabMrww5LRaEpln2r3n5ed7xSVXM/1+0sd2kjeB5KvZHte9qTNgUy4
	2vqxeBQSgDkDXKnOT93d3+qlAHjKs69zk4Al3NeQmqd+x32ox4c08KRA/S3DcjwnH0zYizbKyu/
	dLMyWI9hjGJNJajbm9CzQLP+5APZA8xVwk0R11l508nMH248=
X-Google-Smtp-Source: AGHT+IEmNlz4AiIPomR73q2O3fRFL52LbQLoV8CC5BH22cSwv+7v/BeMmE8uzC3tK3D1NuziqiAJuA==
X-Received: by 2002:a05:6000:1881:b0:3a4:e5fa:73f0 with SMTP id ffacd0b85a97d-3a572397846mr15649067f8f.20.1750257247535;
        Wed, 18 Jun 2025 07:34:07 -0700 (PDT)
Message-ID: <1634c18d-e54e-4105-8b30-6f3085bace22@suse.com>
Date: Wed, 18 Jun 2025 16:33:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
To: Jiqian Chen 
Cc: Huang Rui , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-3-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: <20250612092942.1450344-3-Jiqian.Chen@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12.06.2025 11:29, Jiqian Chen wrote:
> --- a/xen/include/xen/vpci.h
> +++ b/xen/include/xen/vpci.h
> @@ -13,11 +13,12 @@ typedef uint32_t vpci_read_t(const struct pci_dev *pdev, unsigned int reg,
>  typedef void vpci_write_t(const struct pci_dev *pdev, unsigned int reg,
>                            uint32_t val, void *data);
>  
> -typedef int vpci_register_init_t(struct pci_dev *dev);
> -
> -#define VPCI_PRIORITY_HIGH      "1"
> -#define VPCI_PRIORITY_MIDDLE    "5"
> -#define VPCI_PRIORITY_LOW       "9"
> +typedef struct {
> +    unsigned int id;
> +    bool is_ext;
> +    int (*init)(struct pci_dev *pdev);
> +    int (*cleanup)(struct pci_dev *pdev);

Is const really not possible to add to at least one of these two?

> +} vpci_capability_t;

As you have it here, ...

> @@ -29,9 +30,22 @@ typedef int vpci_register_init_t(struct pci_dev *dev);
>   */
>  #define VPCI_MAX_VIRT_DEV       (PCI_SLOT(~0) + 1)
>  
> -#define REGISTER_VPCI_INIT(x, p)                \
> -  static vpci_register_init_t *const x##_entry  \
> -               __used_section(".data.vpci." p) = (x)
> +#define REGISTER_VPCI_CAPABILITY(cap, finit, fclean, ext) \
> +    static const vpci_capability_t finit##_t = { \

... _t suffixes generally designate types. I don't think we should abuse
that suffix for an identifier of a variable.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 14:38:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 14:38:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019239.1396048 (Exim 4.92)
	(envelope-from )
	id 1uRtvT-0001bW-55; Wed, 18 Jun 2025 14:38:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019239.1396048; Wed, 18 Jun 2025 14: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 1uRtvT-0001bP-2O; Wed, 18 Jun 2025 14:38:07 +0000
Received: by outflank-mailman (input) for mailman id 1019239;
 Wed, 18 Jun 2025 14: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 1uRtvR-0001bJ-EJ
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 14:38:05 +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 d7a3723c-4c51-11f0-a30a-13f23c93f187;
 Wed, 18 Jun 2025 16:38:04 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a5123c1533so3993643f8f.2
 for ; Wed, 18 Jun 2025 07:38:04 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-74890083034sm11487602b3a.98.2025.06.18.07.38.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Jun 2025 07:38:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d7a3723c-4c51-11f0-a30a-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750257484; x=1750862284; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=nsNMYcv6w1MRQWT7aYneGzTuj1sM9ZBc2xY2fiJ8e2s=;
        b=Nv1BJbzKXVE9iwiZI1E0JJ3srpIccd4EZ2DZUACDq04Nz6zCpnC96uOQl1kH8Waqyd
         JjR0pTx+IKfN0w465VatEZj4SSM+FDkfyrW/DlsUOVfDKfaQSGNW8rn5/4ahGCvtBLgW
         ycuFKn6o5Q/u2pt2ZrodTNRIqKE/D/Kz8xEvGSikE6a0/bgRYZKW2EJ+P8ooFZ01KlqU
         qr8I6dZPnkp/KY9u3XWBHEYSfzUuBV5THF3REjgQpQsgZZ/FVdNfBasLzRsUoanrveSw
         YDofeqFVMAlBjuVxHNyX+6VqIzMMOllOv6hGVl/jgi3y1E0wmvvKQNoLKh4WbqUyddGA
         Y62g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750257484; x=1750862284;
        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=nsNMYcv6w1MRQWT7aYneGzTuj1sM9ZBc2xY2fiJ8e2s=;
        b=EzxLhqwJZlnhHqjMrlwf2S6SS0saj1z8iE+ewr6Wmy5+hn6WlSoSSSSrTa0kr4h1o5
         JmcCJuSkSvshMCGNjbU2oeR3KOv4s98lYt/IwxqYuFcFYYLPxo/XterpZ9xo08rDDhD3
         llQI5FJe8S/6Jg57JBeP7fVzZ0glwBjPFVr4pzddXzBbIBeGYYeIUfNh7/Td/mRLF39F
         LPQ7tikU2btvG+l8RjX7UhsP5dYFOS0HA33FmARsrbU7zblLGyllZLZWAXTK5TB2V4fk
         yyPdRb8dv95/dcdOVlYfRsJtUHRGVs94Y3F+hnm4SXzzDvFbGZvkdwpDCSXwWjrvdErs
         DT6w==
X-Forwarded-Encrypted: i=1; AJvYcCX/IeIh/m20EnuIRwlmvxsp+4g+93EJl3tsB1UixZ8QvaCjrFLI0fPxw1ssGMEwgbWaYODv+moz6h4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzj5FS8mC+KWMe5J9vzWpbxArod01rBhrCC+9IKT7XRYLJuImLN
	AZUZcQ6e+SgfCkT86bk+wvaVVwuqr8rdNnYPSKIGT+AHxnYvnmhRRL/JDypXbLANSA==
X-Gm-Gg: ASbGncvALWcgvkGY0q17CvWYtbWyUEjf1NmrXhbAm7jGCUQkJT+bq+WEIyeE45V0V29
	etWN28bxqKkk48AF+GDcw3hyWNCbKgawqyuYmIidipjbrZBtVRcX2Nab0ScYcSSq4rIGpPXzRFF
	8LjeudP7ExeMKQMKliCj12KgvP3idSjHhk2ZrxrPl9iTM+6F/jJhUhjzQTxXGLHsJ4/tyVtC4ng
	bJtmWBEgZG3/Qpu7sApIP5J0duBxBzt80BIyYhvNat5YWbMyeBwi8sdfYnyJIsnmXC6MXozNp4N
	m8HenGos77SGAfrCQzS3pmD6zj/gc8J7XM+sp1iiw5JhJJvm63bu5pQYeJddlnJZAczJrfwwW8W
	eEzrmCMv8voGfzZm781N0v/0A3x5fmPj1K0Z4J3+aNiOxJas=
X-Google-Smtp-Source: AGHT+IEhgZnmzcHZyRJ8kPmTw80neTVDcVDtf4qpqL5EEF0uCk6ybUZIleBz7lfauX1erIMG5UZglQ==
X-Received: by 2002:a05:6000:2705:b0:3a5:8a09:70b7 with SMTP id ffacd0b85a97d-3a58a18b882mr4164753f8f.38.1750257483722;
        Wed, 18 Jun 2025 07:38:03 -0700 (PDT)
Message-ID: <2d5a5abc-9fc6-4412-9a70-7b12ba46d80f@suse.com>
Date: Wed, 18 Jun 2025 16:37:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 7/8] vpci/msi: Free MSI resources when init_msi() fails
To: Jiqian Chen 
Cc: Huang Rui , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , xen-devel@lists.xenproject.org
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-8-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: <20250612092942.1450344-8-Jiqian.Chen@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12.06.2025 11:29, Jiqian Chen wrote:
> --- a/xen/drivers/vpci/msi.c
> +++ b/xen/drivers/vpci/msi.c
> @@ -193,6 +193,33 @@ static void cf_check mask_write(
>      msi->mask = val;
>  }
>  
> +static int cf_check cleanup_msi(struct pci_dev *pdev)
> +{
> +    int rc;
> +    unsigned int end, size;
> +    struct vpci *vpci = pdev->vpci;
> +    const unsigned int msi_pos = pdev->msi_pos;
> +    const unsigned int ctrl = msi_control_reg(msi_pos);
> +
> +    if ( !msi_pos || !vpci->msi )
> +        return 0;
> +
> +    if ( vpci->msi->masking )
> +        end = msi_pending_bits_reg(msi_pos, vpci->msi->address64);
> +    else
> +        end = msi_mask_bits_reg(msi_pos, vpci->msi->address64) - 2;
> +
> +    size = end - ctrl;
> +
> +    rc = vpci_remove_registers(vpci, ctrl, size);
> +    if ( rc )
> +        return rc;
> +
> +    XFREE(vpci->msi);
> +
> +    return vpci_add_register(pdev->vpci, vpci_hw_read16, NULL, ctrl, 2, NULL);

Why not use the local variable "vpci" here?

I also think this (re)adding warrants a comment, as to why we do this.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 14:45:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 14:45:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019250.1396058 (Exim 4.92)
	(envelope-from )
	id 1uRu2b-0003VR-V0; Wed, 18 Jun 2025 14:45:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019250.1396058; Wed, 18 Jun 2025 14:45: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 1uRu2b-0003VK-Rw; Wed, 18 Jun 2025 14:45:29 +0000
Received: by outflank-mailman (input) for mailman id 1019250;
 Wed, 18 Jun 2025 14:45: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 1uRu2a-0003VE-OE
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 14:45:28 +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 df50a249-4c52-11f0-b894-0df219b8e170;
 Wed, 18 Jun 2025 16:45:26 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a54836cb7fso5007284f8f.2
 for ; Wed, 18 Jun 2025 07:45:26 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3157a49efc3sm491909a91.0.2025.06.18.07.45.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Jun 2025 07:45:25 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: df50a249-4c52-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750257926; x=1750862726; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=+XASsST3cWO87tPgiOV+zhv1u4r6grC2HguwT9UrXTQ=;
        b=WywX2Bp4M7YYw/mJ8gehwMZgMM2mIn+19jSI2KgUgh0G2mf+jZgsLUtoKU1Zxc2AS0
         8CbSmUDktFQ12ha7QiyctkPXvp2HGsHN/tDRMKijVic2tkrGlv6bbEvyJxYJ3KmWT9IA
         jVS7SPqU5dD/7Ny2Oc7skdD75vsTX+7IoEV90SMXVPa1cqu6vqneA2N/xJcinLkPFj+T
         TBXU8NNADy9+NToO0a7yZrnYoKGPCNQuz6oWwxQv3GukINBY6bbJJxLbbbEaedt9NpPu
         izIqYsFKuD//7pOihFmexD2qA8v4+D2eZDTLfzfRTDpqOVI0NrXDSthm5OWjdaVY1DYI
         J4BA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750257926; x=1750862726;
        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=+XASsST3cWO87tPgiOV+zhv1u4r6grC2HguwT9UrXTQ=;
        b=AFJ/o4VZVKKx+nsBVvN7JQdyjiiXkg4ee56K+CH5byCNAjO/dPt8UBy4C/ZTwwdRxh
         ggdgGSIzolmnB//G2TyDQv11Avp5FC97tkgvpRwsoXw8I6lZyELH2DYUzObiJMsI4t7e
         h1sAcNfutuQCAoSJBXL1q1vM0OXdf5mfX4vBgS/X0s/zCEQ2c3UvIzQN1+i/ODrdVeif
         9a+y48KX5YagtFoWTKsx2XLCO93rZLwXZAr/vDQ33EgBkd8AchgUmBSAMq3KO7QETqNZ
         TKjJWWOBm59fDDCNLuaT5b7cqyFRvdiDICK8OTXDjqA9KIJkdF090wz3HDrFUphzzNfE
         lKrg==
X-Forwarded-Encrypted: i=1; AJvYcCVBLeN632G2udnYCyEbkDnNiDH+zjFjEiYQX8CaYPsGaXLzyPMwcNfSCdr4SHVQYMxMXyAdrvgwK9E=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzaCxlqJKwo5CrOICasizdUmQMrlNzFwmSWfp1O0H11tf5HzhQh
	vJpIOew2cadWNbUbGW1m8zmOjGzpNPLBc9HwJcvyTwzORhTyW24KapIhedJHLSCH5w==
X-Gm-Gg: ASbGncvg2BCZTLAeo4ibFIa2BD3v+JX1lnhi3RwKEGAi9euJBHUvkB6lq2uvG/vfrBC
	Y1EBSnZSawqfAzKUGpjILytLLNaHIllxO7CPjedetFnjtVGTvCYzohZHb8m0HMnHTnZ2FQhSywU
	fzOcaJ3Fd03NwtMxIdW7JnO/lwX3b8RbIllP7FtY5khjOqxbPw1EBNyaBt6NWx4ll+SAAVEoog7
	+W0DCrFiz1qe+YxGDPtul9bzb3oLEt+xZdZq/hS8heU/6YcwyqA7hKqVr51Aakjmkbpz+ZxaP8F
	uNePDAd8VBwKFt5V/yAN0cRaoSxkDAbSwtrmsSsF9YDBV4f7U/MW7JgSKA7eAM/1p+G4tm/5Uu4
	UOB5oB7naB2z63OtbYLg6xpezpgRBgLVXRXWsiuM5niBG5gA=
X-Google-Smtp-Source: AGHT+IGO1IxositLoD9YW2v3fdgVJtLbTsXN9S1jAIEiD3wvJuUdFV4spQhyXGfnbDZ5lna73EycJg==
X-Received: by 2002:a05:6000:2882:b0:3a4:e4ee:4ca9 with SMTP id ffacd0b85a97d-3a57237d8c8mr14133062f8f.23.1750257926005;
        Wed, 18 Jun 2025 07:45:26 -0700 (PDT)
Message-ID: <773c448a-d814-458f-ad83-e9740e724408@suse.com>
Date: Wed, 18 Jun 2025 16:45:18 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 7/8] vpci/msi: Free MSI resources when init_msi() fails
To: Jiqian Chen 
Cc: Huang Rui , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , xen-devel@lists.xenproject.org
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-8-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: <20250612092942.1450344-8-Jiqian.Chen@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12.06.2025 11:29, Jiqian Chen wrote:
> --- a/xen/drivers/vpci/msi.c
> +++ b/xen/drivers/vpci/msi.c
> @@ -193,6 +193,33 @@ static void cf_check mask_write(
>      msi->mask = val;
>  }
>  
> +static int cf_check cleanup_msi(struct pci_dev *pdev)
> +{
> +    int rc;
> +    unsigned int end, size;
> +    struct vpci *vpci = pdev->vpci;
> +    const unsigned int msi_pos = pdev->msi_pos;
> +    const unsigned int ctrl = msi_control_reg(msi_pos);
> +
> +    if ( !msi_pos || !vpci->msi )
> +        return 0;
> +
> +    if ( vpci->msi->masking )
> +        end = msi_pending_bits_reg(msi_pos, vpci->msi->address64);
> +    else
> +        end = msi_mask_bits_reg(msi_pos, vpci->msi->address64) - 2;
> +
> +    size = end - ctrl;
> +
> +    rc = vpci_remove_registers(vpci, ctrl, size);
> +    if ( rc )
> +        return rc;

This is a difficult one: It's not a good idea to simply return here, yet
at the same time the handling of the register we're unable to remove may
still require e.g. ...

> +    XFREE(vpci->msi);

... this. There may therefore be more work required, such that in the
end we're able to ...

> +    return vpci_add_register(pdev->vpci, vpci_hw_read16, NULL, ctrl, 2, NULL);

... try this at least on a best effort basis.

More generally: I don't think failure here (or in other .cleanup hook
functions) may go entirely silently.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 14:59:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 14:59:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019258.1396069 (Exim 4.92)
	(envelope-from )
	id 1uRuG9-0005O3-3t; Wed, 18 Jun 2025 14:59:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019258.1396069; Wed, 18 Jun 2025 14: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 1uRuG9-0005Nw-0w; Wed, 18 Jun 2025 14:59:29 +0000
Received: by outflank-mailman (input) for mailman id 1019258;
 Wed, 18 Jun 2025 14:59: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 1uRuG7-0005Nq-SM
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 14:59:27 +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 d3af2549-4c54-11f0-a30a-13f23c93f187;
 Wed, 18 Jun 2025 16:59:26 +0200 (CEST)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-453066fad06so53074845e9.2
 for ; Wed, 18 Jun 2025 07:59:26 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a568b5bfefsm16769594f8f.88.2025.06.18.07.59.24
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 18 Jun 2025 07:59:25 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d3af2549-4c54-11f0-a30a-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750258765; x=1750863565; 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=vUUuLeD/LYD1sOTdKCCCdJ/rDAMK4SysP+rz+njoEgo=;
        b=uLwgQ/oKjIkJ4g+7b7M1Ug1BKmSagVymHztZR1WgG+6S6WjUsNaHyW7PMnMTZj+12f
         Xux5GvhlaIGfFRve9w1P8FBSTbAWHDjr2yRFZMKbrngTO8cQ1OO1HBseWYxslMd+RtPm
         u7LS0F54TwIMs0AZhju4VgzsX6vkjrAIx+d8M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750258765; x=1750863565;
        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=vUUuLeD/LYD1sOTdKCCCdJ/rDAMK4SysP+rz+njoEgo=;
        b=hejgsvzsEQBly0SET3FPpjwbpIZX3cSgjTWaYobZgCGIhjvcLubkGQbJqOJ2LUGBDC
         MHlqthgh6FKtuLiZ8+37qsHn+s8mHt3GTtLQE/HSYZpkoefEOYgK7bmqv0BOvTRynU4D
         9yz/UwSDdypTbWpRl/CE9hORa5KuWUO+5xHjawUFf0epVYWLeYvKfXFefy7aq8s7yMO5
         utu6JoA4DZg4vCQfSF4qhQWLHUazsd6PtsmDySryYlVMOcB02FxlWN7gQyAUoAFGPj2L
         mbZrn/8sC38wGLuDRP6CB+bYELq1/vj3OtKfOjB5p0WquFFs9ct9Dv8uearDvmp5KSMj
         LRcg==
X-Gm-Message-State: AOJu0YxdIQVrkvX1LddkKQIFRRKCafCgJfYMQgYM9AFzC2Fnjj66ycVq
	GxBPh78+Hwq2t0ZgVyEHPOfFcTnUwXec8yz2KkT13F5DfvecYvmnmMBtlti/XSRG7M8=
X-Gm-Gg: ASbGncvvP6TyuQkbJp8cn7Jd1g5ncDDmnLHHQ5v/SfFYiwV60NqZAdHTbiCVVrdSz1g
	kqCiuEg/VZE0ttuCQgkuMJY8UUT2KnC18gnhxZm4MJukAIGL5prQREWcEXguNPjxVmoyl/mcDcR
	RC9eCGTA+tS0E7BSnki9tHlDe3J2b2++C3vVyLqxiCLp+I3bLE1LiUM02fSye4RIGmQNVeBrRmH
	HRg3Cxp7t4/81Wr6Vi0rbU2faER85ZjcMVgMO7BqDKhTvl8Ja5MSf9Tk7TZ8w3weUmySrIzYgM2
	rV/e4QSk6iFJEHlHcCQ79/Pw1AlSnaS3BFvvdn425Rh4V+PeQ/UZ2yUH6l5RofAybgBDdLb4cdc
	jpV2noQUezx7EBY4rH3WGsJJO9K6+V3IIU3I=
X-Google-Smtp-Source: AGHT+IHwDHgs/oxf0e8JR2hDlOXlXPSseXbZfiCiPJ07bxW4sz7ZF0cAlyLSBFD32UR0LJWOXJYTqA==
X-Received: by 2002:a05:6000:480b:b0:3a4:e6bb:2d32 with SMTP id ffacd0b85a97d-3a57237e13bmr14574174f8f.22.1750258765541;
        Wed, 18 Jun 2025 07:59:25 -0700 (PDT)
Date: Wed, 18 Jun 2025 16:59:24 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" ,
	Andrew Cooper ,
	Julien Grall ,
	Stefano Stabellini ,
	Anthony PERARD ,
	Michal Orzel 
Subject: Re: [PATCH] memory: arrange to conserve on DMA reservation
Message-ID: 
References: <6565e881-ec59-4db4-834a-f694bf1b9427@suse.com>
 
 <9b036f26-f275-48d0-9a33-7cef38b29f48@suse.com>
 
 <2969b5d8-5879-4674-8332-046898e17257@suse.com>
 
 
 
 <8f3f8815-a60d-4c8b-af2b-fc8ed5f9ba32@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <8f3f8815-a60d-4c8b-af2b-fc8ed5f9ba32@suse.com>

On Wed, Jun 18, 2025 at 02:04:12PM +0200, Jan Beulich wrote:
> On 16.06.2025 19:23, Roger Pau Monné wrote:
> > On Mon, Jun 16, 2025 at 06:02:07PM +0200, Jan Beulich wrote:
> >> On 16.06.2025 17:41, Roger Pau Monné wrote:
> >>> On Mon, Jun 16, 2025 at 05:20:45PM +0200, Jan Beulich wrote:
> >>>> On 16.06.2025 16:46, Roger Pau Monné wrote:
> >>>>> One question I have though, on systems with a low amount of memory
> >>>>> (let's say 8GB), does this lead to an increase in domain construction
> >>>>> time due to having to fallback to order 0 allocations when running out
> >>>>> of non-DMA memory?
> >>>>
> >>>> It'll likely be slower, yes, but I can't guesstimate by how much.
> >>>
> >>> Should there be some way to control this behavior then?  I'm mostly
> >>> thinking about client systems like Qubes where memory is likely
> >>> limited, and the extra slowness to create VMs could become
> >>> noticeable?
> >>
> >> What kind of control would you be thinking of here? Yet another command
> >> line option?
> > 
> > I guess that would be enough.  I think we need a way to resort to the
> > previous behavior if required,
> 
> Thinking about it, there already is "dma_bits=". Simply setting this low
> enough would have largely the same effect as yet another new command line
> option. Thoughts?
> 
> > and likely a CHANGELOG entry to notice the change.
> 
> Hmm, not sure here. This is too small imo, and really an implementation
> detail.

I think it's possible to have a noticeable effect for some use-cases,
so it should be listed on CHANGELOG in case users see divergence from
previous Xen versions.  That can given them a hint at what needs
adjusting.

It's not only the possible domain creation overhead: if the guest
being created is HVM with p2m, the resulting p2m will also be
shattered leading to worse guest performance.

> > Overall, would it be possible to only include the flag if we know
> > there's non-DMA memory available to allocate?  Otherwise we are
> > crippling allocation performance when there's only DMA memory left.
> 
> Imo trying to determine this would only make sense if the result can
> then be relied upon. To determine we'd need to obtain the heap lock,
> and we'd need to not drop it until after the allocation(s) were done.
> I think that's far away from being a realistic option.

Couldn't Xen do best effort?

A mismatch won't be fatal anyway.  Error cases: you set MEMF_no_dma and
there's no non-DMA memory to allocate from, in which case it's the
same that's unconditionally done.  Other possible failure is you don't
set non-DMA and there's still non-DMA memory that's not consumed,
which is the current behavior.  IMO it would be safer in terms of
behavior change to do:

if ( a->extent_order &&  )
   a->memflags |= MEMF_no_dma;

I think that's likely to be less intrusive and won't lead to system
malfunctions, even if strictly it's (kind of?) a TOCTOU race.

> > That also raises the question whether it's an acceptable trade-off to
> > possibly shatter p2m super pages (that could be used if allocating
> > from the DMA pool) at the expense of not allocating from the DMA pool
> > until there's non-DMA memory left.
> 
> This being an acceptable tradeoff is imo an implicit pre-condition of
> adding such a heuristic. For the system as a whole, exhausting special
> purpose memory is likely worse than some loss of performance. Plus as
> said above, people valuing performance more can reduce the "DMA pool".

That's an acceptable workaround, but it might be helpful to note this
in the commit message, as otherwise it will get lost in xen-devel.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 15:16:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 15:16:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019265.1396078 (Exim 4.92)
	(envelope-from )
	id 1uRuWK-0008QL-ED; Wed, 18 Jun 2025 15:16:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019265.1396078; Wed, 18 Jun 2025 15: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 1uRuWK-0008QE-Be; Wed, 18 Jun 2025 15:16:12 +0000
Received: by outflank-mailman (input) for mailman id 1019265;
 Wed, 18 Jun 2025 15:16: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 1uRuWJ-0008Q8-0K
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 15:16: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 28cc8cb7-4c57-11f0-a30a-13f23c93f187;
 Wed, 18 Jun 2025 17:16:08 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a57c8e247cso3471260f8f.1
 for ; Wed, 18 Jun 2025 08:16:08 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-748900b1d95sm11067857b3a.120.2025.06.18.08.16.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Jun 2025 08:16:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 28cc8cb7-4c57-11f0-a30a-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750259767; x=1750864567; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=FHmsySBBC46aeM4dE5bYOQxQJPC9oS9TIj1GtE606vM=;
        b=X3lErd4JhjuJQ7vMZYlKghmPEhrQSzk7PWUcLWZ4G9AC7FtFtzKt/8JMmle1116vYH
         xbb9K59ePVSJE7OYB/IQIK4X6S3TgpCjBkjA7/nRdrCHP767NZLyGcw4pNQFKcUflSBq
         SFylTiWoQJYIXLRelANkRWZ5FNA2jMMyKB/cvv7CSjENDV1TfjRzzbYpzoIq9FrV7mEr
         FrvKiauz1tafGiVaXbMlbitzovXY34OXkbYcZvZpXR/htmI44Z8TB9mltNdpgrCpInM8
         YzDKqCy3mB4RNW0fBpchJ8ikvzb/d3XPekZGxLqAOf2LaC9yUjR6gptaEn3JGZxXfbDi
         krsw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750259767; x=1750864567;
        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=FHmsySBBC46aeM4dE5bYOQxQJPC9oS9TIj1GtE606vM=;
        b=UQ4e91T9mmGNbu6tYypQ5G8hujy/iN6yNlNYmkGTaeGwrnNhXRLQA3qnf+vwJopqht
         mB5VGXzuCNYWUoXrtCcHD2R7kCprW85u0hyzTWGS+P/XHBw2bKWF0xgVS/KuFNxA/asw
         QjwmVio6EpSpzR1RLrshdcCwiwGWavshYVOxbxst1t2zzn/zyo572HxD8bIjIr1fWHvK
         iNCGXL5B62kXwnr+loEr1gZkZeks+bElMQKqvVdq4BDeP8M/mt7EiXhmA/pNKsH//N5x
         yWYYkLO4+3KcvrPs69hc5oxxl8czzood8vYwtULsGbXEnwcfn80ew6SKSAVk6ub15k12
         wMDg==
X-Forwarded-Encrypted: i=1; AJvYcCU9KsnD8JSlaSf60tD33fnY0Y15UrXc6xLgTXRzsYDfTj9HXB9OP8kVu+pg/0Cja09FXmwWb15YoKQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwYE/qrfRgrF1qLYf6+064dnzD9XSIxdvwMGkmltA4cx6x7V+BB
	QYLsmCYA7owO9j8ITnI+uRmQ0mG3+VWei5Aq0L+Nd7dTJmZYuK+7ZiBj/dfg7cT4hsbzs4PyzpR
	ObRs=
X-Gm-Gg: ASbGncuG9LcGUC8sqZb84HMKJhAAR2UyGvPMWuXzpkaYJ6IbV061D+No26pj8aTL1Fw
	273FrjQf8+2aBzyNsxe1cV4BE1zvRnghccIyVS5lvut9m0GR25yhBXgjG0amb6m9SCQChflzhe0
	mFsP8HYinSRJM1GbINlIzijfz4oURrMxWgV6bzej7biIFyL18A4M+mZO3yTin852NMmQ7mZDf13
	iWlTGVx0IpOLUWF70ZYZ52Lc2qBpT4zYcbCBEz76GlQb9wwwTrk3dHz52UwYl3Z/izoSkyFd/yB
	QEZiqgo3tBtsY5BSCx8V6jYuB76nsOpaJb6+YkSyDyH9upet/mQp92QR0y4+wKN04dNLP84KYDr
	nyEpusiao9DYnisc3wgSTEDTi9waejXSJfgsvzCWlKtaL0q/IBICdBmwDXw==
X-Google-Smtp-Source: AGHT+IEvzpGLTBCUzoiVYM6ZZTyeYWpJBXZYt6fYRrbNd/Ul/0arbZGgazDUQkPexLrypiyHSjGs3g==
X-Received: by 2002:a05:6000:2002:b0:3a5:25e4:264f with SMTP id ffacd0b85a97d-3a572e6ba0amr14537488f8f.31.1750259767356;
        Wed, 18 Jun 2025 08:16:07 -0700 (PDT)
Message-ID: <728ee92b-0e4f-4ccb-8c6e-54687bd75c62@suse.com>
Date: Wed, 18 Jun 2025 17:15:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 01/17] xen/riscv: implement sbi_remote_hfence_gvma()
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 10.06.2025 15:05, Oleksii Kurochko wrote:
> Instruct the remote harts to execute one or more HFENCE.GVMA instructions,
> covering the range of guest physical addresses between start_addr and
> start_addr + size for all the guests.

Here and in the code comment: Why "for all the guests"? Under what conditions
would you require such a broad (guest) TLB flush?

> --- a/xen/arch/riscv/sbi.c
> +++ b/xen/arch/riscv/sbi.c
> @@ -258,6 +258,15 @@ int sbi_remote_sfence_vma(const cpumask_t *cpu_mask, vaddr_t start,
>                        cpu_mask, start, size, 0, 0);
>  }
>  
> +int sbi_remote_hfence_gvma(const cpumask_t *cpu_mask, vaddr_t start,
> +                           size_t size)
> +{
> +    ASSERT(sbi_rfence);

As previously indicated, I question the usefulness of such assertions. If the
pointer is still NULL, ...

> +    return sbi_rfence(SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA,
> +                      cpu_mask, start, size, 0, 0);

... you'll crash here anyway (much like you will in a release build).

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 15:18:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 15:18:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019271.1396089 (Exim 4.92)
	(envelope-from )
	id 1uRuYL-0000Tx-PM; Wed, 18 Jun 2025 15:18:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019271.1396089; Wed, 18 Jun 2025 15: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 1uRuYL-0000Tq-MJ; Wed, 18 Jun 2025 15:18:17 +0000
Received: by outflank-mailman (input) for mailman id 1019271;
 Wed, 18 Jun 2025 15: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 1uRuYK-0000Tk-JO
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 15:18:16 +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 74db6b4b-4c57-11f0-a30a-13f23c93f187;
 Wed, 18 Jun 2025 17:18:15 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-450ccda1a6eso63331405e9.2
 for ; Wed, 18 Jun 2025 08:18:15 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a568b2ca65sm17308414f8f.77.2025.06.18.08.18.14
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 18 Jun 2025 08:18:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 74db6b4b-4c57-11f0-a30a-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750259895; x=1750864695; 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=7ntpbTrBDZCWO2gQg50I5OlZunvrht3kL0PIQzhroW8=;
        b=WUHU8Et4HwzeIhOybzPqdd6hm407hzg28yw3I9Lh1U675zyVVMPWOFaRcQfSoLK0v7
         hueHWwpATzYGoXLuy/9b6byOrhkkDhpbf96Yz7g0E6OfvNc3LnbevHLYIh7kiIeil5xU
         8wm0CiPaxHsYDlLkxHxquNMFFpXKkIQwkd6Wk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750259895; x=1750864695;
        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=7ntpbTrBDZCWO2gQg50I5OlZunvrht3kL0PIQzhroW8=;
        b=GIQ+tEEjlteKgtEQubNAVlC4FjF6wVO+lbO/WVat+HVeBeNJCPlNwQqVSeoSUfiKWg
         tFds7uYZjEYMVY5mr3R/CapPfRgl++nkuU2oaqlCwzz8vJxkLABCNjCak62AdjsbkE5G
         1iismTWDXQideXkrFvCS9QhdGnn/Tcu7CwjFA8ixp2UhfgrMSj25TNkZkHWFvFBPLmGw
         1fDVIXQaGubAL2z5G7p0QxGqR35R9Qe83dfa9lNPRlann731j6y4ZlW2CiYKNP5xZJ7P
         ruE/czyodr2MlmxUKJrEnm6rajkwm0JQW3o4gnfemEEiQbTzUGFfr5W+dbNiCom1PnyJ
         oK4A==
X-Gm-Message-State: AOJu0YzQ9SDTL+0XoagPedbu/HczlZ4YGojLo76YiG3fkXGRG47+st3U
	OxhLe35QTB/WakTxl+9nEs7M/OnSShVUi90b29wLczliaFeN0+rWbshsQCYzaTlQIjA=
X-Gm-Gg: ASbGncvUSubMJYSplmHzBugxGBrpMuyckStwQpMuD5tenBPOh59d1Z16eKzaL0+WkPx
	6XNOHsSPQQQRNIP0Cjbt3xKMznit+4J9eJ907iitqyd79JU1jVXzjPA7snTRt+5w/KjYfG1dgpB
	LLGtPU0AwV46Zv2oir49+WP7xaNzpA1DXstlyfqfQvCKwlrVDzKW2aIq5x/rCq7sdXDysAkOIMd
	ZlunVTQKAehyqwL1foMajLXkw6wNaCpmqMjgMXM25UQo/CdSf9y+nJ6YXoflUpRmxlHTGpZc6i+
	j68cJsYIpWIIgEQrFtR6C2s2AiDyqApPeGJBsV3v5CuH1M10t0nI3GwzR/TAWn4kMpkKPku3bAu
	BtumGvucHp4ULS4scy307yZzL4c1VyA==
X-Google-Smtp-Source: AGHT+IFu0LH4H9NtGHbcaIxfIU6bi7ybFxlWoWXVd8aIDKvrsRBJ0qjgdPEin96X2O3I6MhhiSwJhA==
X-Received: by 2002:a05:6000:2913:b0:3a3:71cb:f0bd with SMTP id ffacd0b85a97d-3a57237de18mr14871336f8f.23.1750259894884;
        Wed, 18 Jun 2025 08:18:14 -0700 (PDT)
Date: Wed, 18 Jun 2025 17:18:13 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: victorm.lira@amd.com
Cc: xen-devel@lists.xenproject.org,
	Nicola Vetrini ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini ,
	Federico Serafini ,
	Bertrand Marquis 
Subject: Re: [PATCH v2 3/3] xen/x86: add missing noreturn attributes
Message-ID: 
References: <20250606212712.1901838-1-victorm.lira@amd.com>
 <20250606212712.1901838-2-victorm.lira@amd.com>
 <20250606212712.1901838-3-victorm.lira@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250606212712.1901838-3-victorm.lira@amd.com>

On Fri, Jun 06, 2025 at 02:27:09PM -0700, victorm.lira@amd.com wrote:
> From: Nicola Vetrini 
> 
> The marked functions never return to their caller, but lack the
> `noreturn' attribute.
> 
> Functions that never return should be declared with a `noreturn'
> attribute.
> 
> The lack of `noreturn' causes a violation of MISRA C Rule 17.11 (not
> currently accepted in Xen), and also Rule 2.1: "A project shall not
> contain unreachable code". Depending on the compiler used and the
> compiler optimization used, the lack of `noreturn' might lead to the
> presence of unreachable code.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini 
> Signed-off-by: Victor Lira 

Acked-by: Roger Pau Monné 

One question below.

> ---
> Changes in v2:
> - improved commit message
> ---
> Cc: Andrew Cooper 
> Cc: Anthony PERARD 
> Cc: Michal Orzel 
> Cc: Jan Beulich 
> Cc: Julien Grall 
> Cc: Roger Pau Monné 
> Cc: Stefano Stabellini 
> Cc: Nicola Vetrini 
> Cc: Federico Serafini 
> Cc: Bertrand Marquis 
> ---
>  xen/arch/x86/cpu/mcheck/mce.c | 3 ++-
>  xen/arch/x86/efi/efi-boot.h   | 2 +-
>  xen/arch/x86/smp.c            | 2 +-
>  xen/arch/x86/traps.c          | 2 +-
>  xen/arch/x86/x86_64/traps.c   | 2 +-
>  5 files changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
> index 1c348e557d..79214ce56b 100644
> --- a/xen/arch/x86/cpu/mcheck/mce.c
> +++ b/xen/arch/x86/cpu/mcheck/mce.c
> @@ -79,7 +79,8 @@ static int __init cf_check mce_set_verbosity(const char *str)
>  custom_param("mce_verbosity", mce_set_verbosity);
> 
>  /* Handle unconfigured int18 (should never happen) */
> -static void cf_check unexpected_machine_check(const struct cpu_user_regs *regs)
> +static void noreturn cf_check
> +unexpected_machine_check(const struct cpu_user_regs *regs)
>  {
>      console_force_unlock();
>      printk("Unexpected Machine Check Exception\n");
> diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
> index 0ecf4ca53f..0194720003 100644
> --- a/xen/arch/x86/efi/efi-boot.h
> +++ b/xen/arch/x86/efi/efi-boot.h
> @@ -769,7 +769,7 @@ static void __init efi_arch_blexit(void)
>          efi_bs->FreePages(ucode.addr, PFN_UP(ucode.size));
>  }
> 
> -static void __init efi_arch_halt(void)
> +static void noreturn __init efi_arch_halt(void)
>  {
>      local_irq_disable();
>      for ( ; ; )
> diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c
> index 516dab5528..7936294f5f 100644
> --- a/xen/arch/x86/smp.c
> +++ b/xen/arch/x86/smp.c
> @@ -343,7 +343,7 @@ void __stop_this_cpu(void)
>      cpumask_clear_cpu(smp_processor_id(), &cpu_online_map);
>  }
> 
> -static void cf_check stop_this_cpu(void *dummy)
> +static void noreturn cf_check stop_this_cpu(void *dummy)
>  {
>      const bool *stop_aps = dummy;
> 
> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
> index 092c7e4197..34dc077cad 100644
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -805,7 +805,7 @@ void fatal_trap(const struct cpu_user_regs *regs, bool show_remote)
>            (regs->eflags & X86_EFLAGS_IF) ? "" : " IN INTERRUPT CONTEXT");
>  }
> 
> -void asmlinkage do_unhandled_trap(struct cpu_user_regs *regs)
> +void asmlinkage noreturn do_unhandled_trap(struct cpu_user_regs *regs)
>  {
>      fatal_trap(regs, false);
>  }
> diff --git a/xen/arch/x86/x86_64/traps.c b/xen/arch/x86/x86_64/traps.c
> index c77f304bb0..8460a4a1ae 100644
> --- a/xen/arch/x86/x86_64/traps.c
> +++ b/xen/arch/x86/x86_64/traps.c
> @@ -293,7 +293,7 @@ void show_page_walk(unsigned long addr)
>             l1_table_offset(addr), l1e_get_intpte(l1e), pfn);
>  }
> 
> -void asmlinkage do_double_fault(struct cpu_user_regs *regs)
> +void asmlinkage noreturn do_double_fault(struct cpu_user_regs *regs)

Does noreturn matter for functions called from assembly (asmlinkage
ones)?  In that case the hint is not useful for code generation, since
it's hand written assembly already?  (it's arguably useful for the
developer writing the code)

Might be worth mentioning in the commit message if the above is
accurate.  For example by adding to the commit message: "noreturn is
not relevant for functions called from assembly, but can be used as a
hint for the developers writing the code".

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 15:20:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 15:20:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019282.1396098 (Exim 4.92)
	(envelope-from )
	id 1uRuao-0002Et-A6; Wed, 18 Jun 2025 15:20:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019282.1396098; Wed, 18 Jun 2025 15:20: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 1uRuao-0002Em-77; Wed, 18 Jun 2025 15:20:50 +0000
Received: by outflank-mailman (input) for mailman id 1019282;
 Wed, 18 Jun 2025 15:20: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 1uRuam-0002Ec-R5
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 15:20:48 +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 cef8921c-4c57-11f0-b894-0df219b8e170;
 Wed, 18 Jun 2025 17:20:46 +0200 (CEST)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-4531e146a24so43827105e9.0
 for ; Wed, 18 Jun 2025 08:20:46 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2365d8a1924sm101425425ad.68.2025.06.18.08.20.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Jun 2025 08:20:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cef8921c-4c57-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750260046; x=1750864846; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=U9aQHwv7GQGiYyFRiLwD6wo2qIajZjWB85X+deMNlDE=;
        b=TVhp61Jg+Vv2XN82sld7StmSM7BlbNVKpt92Bqgn0m8lPSiynYKlUD8NKpbkmi1XfM
         hPYxCzI8SNV3Z8AL4+3oassZwxwlcLVoTe//1GoMAHy520YM7w9L0sQd8ljyQKJQ1APH
         Vc/1ZnBVA6JaCPVgLZE5JLjca7a9IylXxkXCpf7mG34iJcwcPGMe/keId4s29ax/2HAW
         aoZFmZF70+JsGw2gR4c5B0BAoOJx/v6nmgUItP1sUk6XWJRKEnJyCs3mKJEbvWlq7/kT
         YHHT+1flyoEonGwcm2pw27Nt3IdJVaRlBU7Nr4SJxQ8mYRdbZQN0E72r++lHNt6G75Z4
         uxcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750260046; x=1750864846;
        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=U9aQHwv7GQGiYyFRiLwD6wo2qIajZjWB85X+deMNlDE=;
        b=jb4+sJz7tvLd1hP9T3za77erreGdcxWvO+ZqCbbTLQALQSk7q5m2sG+H5XPhVYTM/1
         VpMnu946J5DAl+E4/FzGpBcy33jTjhLNiiMpqpttI9yYXmG2b6VBofWXfWjqbRjxs3lo
         kcIz34OJ/4rzeK1Pwwz4QRFH1SER2vPkOebt5U8AuL728j28AiUINNDPnzxmUZsK6mr0
         FHYnHKS/Bb2gkkzwLNs+glKof0vyu/r9/Ot6NrZGcket4Xns17ypHosy0O27wejtEBYh
         FwmdfPFWKXv39YWl2JSMZ/Fccwl+otBGB1Urh8g5svojdYlWvAdk2QRuIT30SgXWAZGs
         /vBA==
X-Forwarded-Encrypted: i=1; AJvYcCWye60kIBXULV9DFGd4fxu5+7OiJ41NpevgwlPZVC3SbWysT5NE5hnQJH+H5/UskxsVoPSqlh+n0P0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YykkVCCNaAl2vhATLvcTu9PX2hN26eUQBbC4KQ7ZK70tpsCQ47g
	d22CXZBgiZAcQ+a+gRJDXndC2LhDH4VykFvRvwt5Qq9P9lY7zlZ6SAhnmcqvXeROsg==
X-Gm-Gg: ASbGncvKyxx+jmfRfVOHFfIY+3mMngV4k96KHoc5fBtThkfnnp8ZARMWogCu6q9heuR
	1c+WOuLIO4vjrTTDSXMuEEsMf0h2XIaqfHtDkuQjEc9gzA2pO6wHCcA2wUB5z3PQLnzg6fyL6p8
	7hZb5wRBB3nYSnTm7otdAOpOY1QNgxMHn6YTVDLOgmxaCp3pBGjpdB0iBWoxEMI4XYAm6phwDuP
	ZGtDncdRSZFw2v6TI4ie14T26UUNOrS/0Ge8xEiHsPOdaZSTiesDO+ebeHaTf77hPQCHp97Ty/q
	XqX0atBB6yVN4OXimiwBLQ7tNlcbfGLgCYpww6WP34f/e5ISWW2KZmLx+XCaOFX75M+jZBFwAJA
	rDTTBcIFJALa0jGNpX9dGsQvXfAG6pQadkD7fuX0G8Qe5SkI=
X-Google-Smtp-Source: AGHT+IHhU75T7QHJ8zenbPXyxhwTzQZeO8sLkuhI8xA2YO5bM4f8xzf50Aq1rdM3PHENaQVacMCkHQ==
X-Received: by 2002:a05:6000:178a:b0:3a5:2cb5:63fa with SMTP id ffacd0b85a97d-3a57236654amr16217050f8f.2.1750260046167;
        Wed, 18 Jun 2025 08:20:46 -0700 (PDT)
Message-ID: <542a4f54-705d-4f4e-b155-13375561baac@suse.com>
Date: Wed, 18 Jun 2025 17:20:35 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 02/17] xen/riscv: introduce
 sbi_remote_hfence_gvma_vmid()
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: 
 <5c614593a1710c737f5509ebb165efd8f857df30.1749555949.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: <5c614593a1710c737f5509ebb165efd8f857df30.1749555949.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.06.2025 15:05, Oleksii Kurochko wrote:
> It instructs the remote harts to execute one or more HFENCE.GVMA instructions
> by making an SBI call, covering the range of guest physical addresses between
> start_addr and start_addr + size only for the given VMID.
> 
> This function call is only valid for harts implementing hypervisor extension.

We require H now, don't we? It's also odd to have this here, but not in patch 1.

> --- a/xen/arch/riscv/sbi.c
> +++ b/xen/arch/riscv/sbi.c
> @@ -267,6 +267,15 @@ int sbi_remote_hfence_gvma(const cpumask_t *cpu_mask, vaddr_t start,
>                        cpu_mask, start, size, 0, 0);
>  }
>  
> +int sbi_remote_hfence_gvma_vmid(const cpumask_t *cpu_mask, vaddr_t start,
> +                           size_t size, unsigned long vmid)
> +{
> +    ASSERT(sbi_rfence);
> +
> +    return sbi_rfence(SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA,
> +                      cpu_mask, start, size, vmid, 0);
> +}

sbi_remote_hfence_gvma() may want implementing in terms of this new function,
requiring the patches to be swapped. Provided (see comment there) that helper
is actually needed.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 15:46:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 15:46:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019297.1396109 (Exim 4.92)
	(envelope-from )
	id 1uRuzV-0005LT-7M; Wed, 18 Jun 2025 15:46:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019297.1396109; Wed, 18 Jun 2025 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 1uRuzV-0005LM-3I; Wed, 18 Jun 2025 15:46:21 +0000
Received: by outflank-mailman (input) for mailman id 1019297;
 Wed, 18 Jun 2025 15:46: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 1uRuzT-0005LG-QX
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 15:46:19 +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 5f4d4351-4c5b-11f0-b894-0df219b8e170;
 Wed, 18 Jun 2025 17:46:17 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3a54836cb7fso5065652f8f.2
 for ; Wed, 18 Jun 2025 08:46:17 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2365dea8d1asm101510285ad.162.2025.06.18.08.46.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Jun 2025 08:46:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5f4d4351-4c5b-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750261577; x=1750866377; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=mgGsg0NF5xME51m1y9/GzQbL7VFIrVp17bR5IjcRPl4=;
        b=CiTn6j2B37aCJnkTdNcuKW4EzJg0l4mdtro1jzfpDNw8fG8AgJmFflwpnIoM08mFEa
         sBVynD1pkN3N9TdZ9yyXdgeHjkWSpOOTYTdqfDoNvV+71AUch0cFOi4d4rOiG1HHrIll
         3h/fZIGO+G3n1/An7ac1lywCYpP4gScHQ3KwPv0ZcqXKx6RbzCdxUJCg6VEF81KEScy9
         NgHPpH1lSsjkchWINrDzfeOgQxZ1/P6mCjawwS09JnR9itnzhb/UcxqoFhrXPGxL3Ywi
         /Hh58/iPXHA5N5c5ipHnX1rSifXsTAJksCqPP7d1tb0H4yeETzvtCjKSx79wJSodQKmH
         DycA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750261577; x=1750866377;
        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=mgGsg0NF5xME51m1y9/GzQbL7VFIrVp17bR5IjcRPl4=;
        b=TFrE3DThr+Gz8pZq9uGhouSZp3COjq/whBd1HTfbpjAKDa1ofjZJF4rLJysQ4bLe1w
         dJYe1kjAPfMHnI6gC5XVUPGVjmPE+VlF/2EeR77INdBgxSPllByHzjUDxztMPB/NYD87
         Mhss9XnzSimiBgLDKXXGvUFgu/qgQjg/rhGRxvq1Ub+zFvEiMCpv3SIcEvDy8ji+EXuS
         RiTcEzsJK7HJjUqDsz/s43DOnzP1QZTzaL0JodpZ/GnAnFcPzz4iSFaOns7MNHf+2eq7
         bPsGdpHEE98LKtW1USXC8wKyRcoRLWZ29emNChdNkilnREqWxEOlTEngCa8oV+RYO6+3
         zcEQ==
X-Forwarded-Encrypted: i=1; AJvYcCX7VI1xBu48zv5+cM+E549wmD5MttON7PIFX7uMnxRvmBLwt+n0ihgtMnoXiNGLsnOWorNtysHhG5w=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyckHasFTJnspE0orAlqSvWSNJzJ9ZFffdB2M7EcVcZIJnFjuwE
	cMmdk8hA5hTHlSk0HrF+4QO7YXK/WhUtV5o2nPIyaMdASI1KFyAsGhTEyOKn8aJ2UQ==
X-Gm-Gg: ASbGnctR4OXKI7O+N28pdfm3qLo5jQ8wFN5QfCfcNlkecWKSqNpT8xyHxSnRLOP+s8z
	Dy/TY0/6tzeLUn2uprVApisGxq7du0hZWhcOD+Hs0c4atvB7xCT9L/I5dmuAnyrbq6kPWaPMLor
	IMctWAiBqMUbMdyAqAWsAbMA+zq1eXuNhZYagYRuk6BOlVw+fEGLUGtEpMx4cA+OAGH01GVttuk
	ZzVwmp/xq1MBCpiJ9LD11FfE58Z3XIFWZgBM/Eg7gydMMV5KfT0E5Uv8nWs9uF+JZhBPKz7TZlI
	DCACw8yEwa9IAKgQTKTw7M3IeJpGdlfd0lBV/Pn85eBjpS4k8Kzk6AdnqxXyyR8lk+HCpIiLFvj
	6DwZFlyfcNT39yEDBE0qWtXanuIETh0D/e8i76Sl8yyX/7Cc=
X-Google-Smtp-Source: AGHT+IE30eTrRhlGS98vnFpMbEQjgpopzdRsWKWpqz7bxJeUOi+sm+cdZlygVAU/cjHjhBtIwpDQTA==
X-Received: by 2002:a05:6000:2182:b0:3a5:8a68:b815 with SMTP id ffacd0b85a97d-3a58a68bb82mr5537217f8f.46.1750261576768;
        Wed, 18 Jun 2025 08:46:16 -0700 (PDT)
Message-ID: 
Date: Wed, 18 Jun 2025 17:46:05 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 03/17] xen/riscv: introduce guest domain's VMID
 allocation and manegement
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 10.06.2025 15:05, Oleksii Kurochko wrote:
> Implementation is based on Arm code with some minor changes:
>  - Re-define INVALID_VMID.
>  - Re-define MAX_VMID.
>  - Add TLB flushing when VMID is re-used.
> 
> Also, as a part of this path structure p2m_domain is introduced with
> vmid member inside it. It is necessary for VMID management functions.
> 
> Add a bitmap-based allocator to manage VMID space, supporting up to 127
> VMIDs on RV32 and 16,383 on RV64 platforms, in accordance with the
> architecture's hgatp VMID field (RV32 - 7 bit long, others - 14 bit long).
> 
> Reserve the highest VMID as INVALID_VMID to ensure it's not reused.

Why must that VMID not be (re)used? INVALID_VMID can be any value wider
than the hgatp.VMID field.

> --- a/xen/arch/riscv/Makefile
> +++ b/xen/arch/riscv/Makefile
> @@ -6,6 +6,7 @@ obj-y += intc.o
>  obj-y += irq.o
>  obj-y += mm.o
>  obj-y += pt.o
> +obj-y += p2m.o

Nit: Numbers typically sort ahead of letters.

> --- /dev/null
> +++ b/xen/arch/riscv/p2m.c
> @@ -0,0 +1,115 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +static spinlock_t vmid_alloc_lock = SPIN_LOCK_UNLOCKED;
> +
> +/*
> + * hgatp's VMID field is 7 or 14 bits. RV64 may support 14-bit VMID.
> + * Using a bitmap here limits us to 127 (2^7 - 1) or 16383 (2^14 - 1)
> + * concurrent domains.

Which is pretty limiting especially in the RV32 case. Hence why we don't
assign a permanent ID to VMs on x86, but rather manage IDs per-CPU (note:
not per-vCPU).

> The bitmap space will be allocated dynamically
> + * based on whether 7 or 14 bit VMIDs are supported.
> + */
> +static unsigned long *vmid_mask;
> +static unsigned long *vmid_flushing_needed;
> +
> +/*
> + * -2 here because:
> + *    - -1 is needed to get the maximal possible VMID

I don't follow this part.

> + *    - -1 is reserved for beinng used as INVALID_VMID

Whereas for this part - see above.

> + */
> +#ifdef CONFIG_RISCV_32
> +#define MAX_VMID (BIT(7, U) - 2)
> +#else

Better "#elif defined(CONFIG_RISCV_64)"?

> +#define MAX_VMID (BIT(14, U) - 2)
> +#endif
> +
> +/* Reserve the max possible VMID to be INVALID. */
> +#define INVALID_VMID (MAX_VMID + 1)
> +
> +void p2m_vmid_allocator_init(void)

__init

> +{
> +    /*
> +     * Allocate space for vmid_mask and vmid_flushing_needed
> +     * based on INVALID_VMID as it is the max possible VMID which just
> +     * was reserved to be INVALID_VMID.
> +     */
> +    vmid_mask = xvzalloc_array(unsigned long, BITS_TO_LONGS(INVALID_VMID));
> +    vmid_flushing_needed =
> +        xvzalloc_array(unsigned long, BITS_TO_LONGS(INVALID_VMID));

These both want to use MAX_VMID + 1; there's no logical connection here to
INVALID_VMID.

Furthermore don't you first need to determine how many bits hgatp.VMID actually
implements? The 7 and 14 bits respectively are maximum values only, after all.

VMIDLEN being permitted to be 0, how would you run more than one VM (e.g. Dom0)
on such a system?

> +    if ( !vmid_mask || !vmid_flushing_needed )
> +        panic("Could not allocate VMID bitmap space or VMID flushing map\n");
> +
> +    set_bit(INVALID_VMID, vmid_mask);

If (see above) this is really needed, __set_bit() please.

> +}
> +
> +int p2m_alloc_vmid(struct domain *d)

Looks like this can be static? (p2m_free_vmid() has no caller at all, so
it's not clear what use it is going to be.)

> +{
> +    struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +
> +    int rc, nr;

No need for the blank line between the (few) declarations?

> +    spin_lock(&vmid_alloc_lock);
> +
> +    nr = find_first_zero_bit(vmid_mask, MAX_VMID);

As per this nr wants to be unsigned int.

> +    ASSERT(nr != INVALID_VMID);
> +
> +    if ( nr == MAX_VMID )
> +    {
> +        rc = -EBUSY;
> +        printk(XENLOG_ERR "p2m.c: dom%d: VMID pool exhausted\n", d->domain_id);

Please use %pd.

> +        goto out;
> +    }
> +
> +    set_bit(nr, vmid_mask);

Since you do this under lock, even here __set_bit() ought to be sufficient.

> +    if ( test_bit(p2m->vmid, vmid_flushing_needed) )
> +    {
> +        clear_bit(p2m->vmid, vmid_flushing_needed);

And __clear_bit() here, or yet better use __test_and_clear_bit() in the if().

> +        sbi_remote_hfence_gvma_vmid(d->dirty_cpumask, 0, 0, p2m->vmid);

You're creating d; it cannot possibly have run on any CPU yet. IOW
d->dirty_cpumask will be reliably empty here. I think it would be hard to
avoid issuing the flush to all CPUs here in this scheme.

> +    }
> +
> +    p2m->vmid = nr;
> +
> +    rc = 0;
> +
> +out:

Nit: Style.

> +    spin_unlock(&vmid_alloc_lock);
> +    return rc;
> +}
> +
> +void p2m_free_vmid(struct domain *d)
> +{
> +    struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +
> +    spin_lock(&vmid_alloc_lock);
> +
> +    if ( p2m->vmid != INVALID_VMID )
> +    {
> +        clear_bit(p2m->vmid, vmid_mask);
> +        set_bit(p2m->vmid, vmid_flushing_needed);

Does this scheme really avoid any flushes (except near when the system is
about to go down)?

As to choice of functions - see above.

> +    }
> +
> +    spin_unlock(&vmid_alloc_lock);
> +}
> +
> +int p2m_init(struct domain *d)
> +{
> +    struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +    int rc;
> +
> +    p2m->vmid = INVALID_VMID;

Given the absence of callers of p2m_free_vmid() it's also not clear what use
this is.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 15:53:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 15:53:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019304.1396120 (Exim 4.92)
	(envelope-from )
	id 1uRv6d-00071m-V8; Wed, 18 Jun 2025 15:53:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019304.1396120; Wed, 18 Jun 2025 15: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 1uRv6d-00071f-QL; Wed, 18 Jun 2025 15:53:43 +0000
Received: by outflank-mailman (input) for mailman id 1019304;
 Wed, 18 Jun 2025 15:53: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 1uRv6d-00071Z-6H
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 15:53:43 +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 67e2f42d-4c5c-11f0-b894-0df219b8e170;
 Wed, 18 Jun 2025 17:53:41 +0200 (CEST)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-3a365a6804eso5357669f8f.3
 for ; Wed, 18 Jun 2025 08:53:41 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-748900b1e5csm11193358b3a.123.2025.06.18.08.53.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Jun 2025 08:53:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 67e2f42d-4c5c-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750262021; x=1750866821; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=9El53qRuOF1UsqpY70foUoN+jURn+S/fkmijssTagvs=;
        b=VP7QU+BO/XUQfRrTGEqmn4dYHrfE3d6HpJwgOBau+rMMGw5XjjQhp1uySbrQ4uYPAZ
         8TzW29o3Ya0baVvkbrZVH8iq9K97vFROBv0A7NneA2txsgrKboZ9mux5UgjvcYOIHVQs
         L7l8fcidcdFn2zAWLfc5yQkOiR9mn3BS340YiaQO+J7r3fkGoy71LPd6uzALEfdC9gMr
         OW51wUuo4prQapVjdVZB3vfeMiFHtKLH7U5OI4BmFx5lgLiO0/t95RgEGSYMu6YZ3BYD
         c0mgvAg2BTA9NkWFIe2iAPtW30fueIZ0ackwi/KvlSBr0TPPCCIOzyzxQtD0TVI8c6xU
         Y+7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750262021; x=1750866821;
        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=9El53qRuOF1UsqpY70foUoN+jURn+S/fkmijssTagvs=;
        b=OR+Zpoym/ISwMVwKMVvjhkcrVgizCo5tXM1p/566UoequeViBk8X02ziZ+kmj+cSdT
         n7+JElif0UZrbMeu/7RX3BM+Q5ij3UH1YmoFRxYwTnw7dUErmekkK+89ZW2koZEDPcga
         uqkmMsfJ8rc2NbEyOkkZxYCYmewQLEiQXzuuSHizbeAJQLxMQ5irNKF9kOwsoNrB4biS
         dONWIeOuu7WjB9OP5p8ToHgZs/nj1vuz7VnHKFP71hIjdueQxoqWwKOfzGij5NNZevIj
         83uOriv4K4XcbSyL8on7JleLC8HawG2GcUQspBwgIt30JIqBk/RvsEfvSJqUio+TEWfG
         L9UA==
X-Forwarded-Encrypted: i=1; AJvYcCVK42wJ0QkN7/eH7Jr86jd37++KPWUUgRXMuzbReM7U7avGl/ZPlaL/UgnuJx1ssqiXr21C+kYhLdU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzS6xSHfGc6cWHF8gSKAnX7jPKnxBLbTpLqQl40C+C9/uZTe10a
	8VMZ4iE/LiJKSbxzO1M5I/HR9z5P13sQ+/T/z3wjYwQzNAdIFevfPusFAO40b2jQSw==
X-Gm-Gg: ASbGncs4YZxSI5jxv2ulzJ9vPnrb8IPOEZOeVSUQf3aZAyLwMdaXLsSyBYWz5D1mG9L
	ZiRJ9l+RHuzoNryOr66Ox7gJ6w6gzBiRtebDhAgQR5WASoOP1Ea8w0sDwwZjk9mYWsWgbHBfl4K
	kYSHzdmz5tjrZ++yqxsmA70Cp+d5AHWWri9ZgqR7vrLbZ1JoKGmR8J5r8G7MJwG57YqfKYtqtrc
	ZSRNHsL5pbhwbnXyS58WL2gOuJWLAZPvrCN3XkE1ppbZpI3YR1kYR/Br/FoEId6c/0ebAnCF6yo
	e9/oMNHwA/V3hQmQnF5YAPC5XkgjbUrV7KA3aCg6Fm6xHg/K6Ydv2LFugl4zJaHogpklhm9vxKz
	RINuk4DqD16LYE7SvD9Sxp048Ggysbn2sM3oq9IX3+eodT6Y=
X-Google-Smtp-Source: AGHT+IFvi3CAzAG7OD+/uZVSUXiVgAyC8cOLFLOLf4djqqlW06wbRdOpOXz3Oip9dMsshSkinrDYxA==
X-Received: by 2002:a05:6000:2007:b0:3a5:25e0:1851 with SMTP id ffacd0b85a97d-3a5723660b5mr15194972f8f.7.1750262020698;
        Wed, 18 Jun 2025 08:53:40 -0700 (PDT)
Message-ID: <3bbc8962-eaaa-4ed0-bc21-757bdc6be49d@suse.com>
Date: Wed, 18 Jun 2025 17:53:29 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 04/17] xen/riscv: construct the P2M pages pool for
 guests
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 10.06.2025 15:05, Oleksii Kurochko wrote:
> @@ -18,10 +20,20 @@ struct arch_vcpu_io {
>  struct arch_vcpu {
>  };
>  
> +struct paging_domain {
> +    spinlock_t lock;
> +    /* Free P2M pages from the pre-allocated P2M pool */
> +    struct page_list_head p2m_freelist;
> +    /* Number of pages from the pre-allocated P2M pool */
> +    unsigned long p2m_total_pages;
> +};
> +
>  struct arch_domain {
>      struct hvm_domain hvm;
>  
>      struct p2m_domain p2m;
> +
> +    struct paging_domain paging;

With the separate structures, do you have plans to implement e.g. shadow paging?
Or some other paging mode beyond the basic one based on the H extension? If the
structures are to remain separate, may I suggest that you keep things properly
separated (no matter how e.g. Arm may have it) in terms of naming? I.e. no
single "p2m" inside struct paging_domain.

> @@ -105,6 +106,9 @@ int p2m_init(struct domain *d)
>      struct p2m_domain *p2m = p2m_get_hostp2m(d);
>      int rc;
>  
> +    spin_lock_init(&d->arch.paging.lock);
> +    INIT_PAGE_LIST_HEAD(&d->arch.paging.p2m_freelist);

If you want p2m and paging to be separate, you will want to put these in a new
paging_init().

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 16:08:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 16:08:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019311.1396129 (Exim 4.92)
	(envelope-from )
	id 1uRvL0-0000wj-3W; Wed, 18 Jun 2025 16:08:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019311.1396129; Wed, 18 Jun 2025 16:08:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRvL0-0000wc-0d; Wed, 18 Jun 2025 16:08:34 +0000
Received: by outflank-mailman (input) for mailman id 1019311;
 Wed, 18 Jun 2025 16: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 1uRvKz-0000wW-7U
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 16:08:33 +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 7572fa11-4c5e-11f0-b894-0df219b8e170;
 Wed, 18 Jun 2025 18:08:23 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3a365a6804eso5375932f8f.3
 for ; Wed, 18 Jun 2025 09:08:23 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-748900d2351sm11187078b3a.162.2025.06.18.09.08.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Jun 2025 09:08:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7572fa11-4c5e-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750262902; x=1750867702; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=has3YaGAUMCsALXIyrZHB9whbEV+eQu2rDdP/VC4DVo=;
        b=MJy7iUdy12/CxZDorTroOrK6bpOEpRczJ6QUk1lawTKsnw6Zph4OLyBDaxI0AggtTq
         /GHxDxPw2ZtfC+DBacQF3JAlQ0+SWVBMRo1yarKIAgu9QPLqLeNeKo0R0yUQKdHGF8sc
         zc9NxnxETD7VfXTMlErjGT5+66ru6hD5SqhPgUuVkYI73OQPEsw8t1rmq0STJgDPc+Fy
         bgZk/xXbnapI8SOjnzIa28WhLSi+YbwqFzm4MYtgvWqxxwsKaTaCG+ZubIdbCQFT7dhv
         I4mfD70vfd63CQgQSK+MDfBTs3ChtHlJN6PsEngegyVu2zCYeMhYaK8yJuxhEEuwEAFq
         DuLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750262902; x=1750867702;
        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=has3YaGAUMCsALXIyrZHB9whbEV+eQu2rDdP/VC4DVo=;
        b=HBGOrBUtRCylANuviacuPUyBmevdNXSNXkxymI9t6T/utzkOplfHLgBZqqzGQF96wX
         55vcTTjKvM0vaV9UEpnoW/Djlo9PsR/taINTwUdzgI1w8o48LvNJgKffRyMB/mVzWgG7
         6grv7YpYAPzk4FmkLepA/T+UM1jw8DrPCRq2l4dK6LT4bSmh8S3byZlcXPmfnKMyMK3H
         Pwch5Y1FkzwE0cDRjWff7iCsHv18jl1+Rl1wHk7L/45hMKAUfH5MGMKQicSGDKTtlHCF
         g1oSPHDP4ZQ5X/5ieNA244cfYHCpqHWH3YAJZqtp5EJCNPW7q71IAPVugxGPqOUnoKYx
         KS2A==
X-Forwarded-Encrypted: i=1; AJvYcCWwWoarmt60H2CZUgTmeCgVzmu3S5Qgb2D8Mbecz5ke+ChnlYd8iXLFfVLmok1pfOJ39dy/Nh4+XVM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwvxpfevR30QuShZSn0Rh1QdaVXhOBMwIRTeblTeDypya0rXLo1
	9aqVQA+SQ9KTmJCi7hGM+OMUFDdBsrNqyWABblzsL1afoM6Gmp/siaDaJCQv5cHwBQ==
X-Gm-Gg: ASbGnctTpsOjhr5KUiqu5XkAyD+PeKejn7mJqJ8OT3CrKnWLblS3laTnOqGR/n54U5u
	FE1yMoWDoddtFS6UdBJDW3LXNqUJlBGvGs3aAyCfK+5ZzVhPtw/T8UTO2zGRdv0eX39NmPNMg27
	b6vAQ168QFCRHxTisqmvkU4kAw7H8dauZtWxvOpuS1PbYEhNDxjOk8WWF6t0Ezyt1/ecrvNlfPh
	6QV+JaqAjsmQRKg0W1CSozlTIXp3NNXp7IDOfVEFiX1O/UJkFO7T4ca0eAS/QFiRLTlTNUiyzzf
	Re3xL7Xe4ztwLeYUh3U4MT8wAh/ZgcUBrUFS3zNqf/TzwNWO9bmE1J0h8s6rF1qcHXC/N+wkSBd
	inEdpWaKwW9zYBI0yHLJOOzVXpy5DB96LhQVlnQENY2z5dB0=
X-Google-Smtp-Source: AGHT+IHywG1KS1RsyNxqIAzMTl+oJ6gl6v8FFNdwpVMDcaMYqi730rUEUF0nqVTPVIJjSYp6Pp80wg==
X-Received: by 2002:a05:6000:2504:b0:3a3:7593:818b with SMTP id ffacd0b85a97d-3a572371e88mr15553428f8f.21.1750262902397;
        Wed, 18 Jun 2025 09:08:22 -0700 (PDT)
Message-ID: <5c61fd86-5c0e-481e-a5a9-6a53f2d78c36@suse.com>
Date: Wed, 18 Jun 2025 18:08:11 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 05/17] xen/riscv: introduce things necessary for p2m
 initialization
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: 
 <443cb3566a60dcb5d5440c72410ff6d76a010a58.1749555949.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: <443cb3566a60dcb5d5440c72410ff6d76a010a58.1749555949.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.06.2025 15:05, Oleksii Kurochko wrote:
> Introduce the following things:
> - Update p2m_domain structure, which describe per p2m-table state, with:
>   - lock to protect updates to p2m.
>   - pool with pages used to construct p2m.
>   - clean_pte which indicate if it is requires to clean the cache when
>     writing an entry.
>   - radix tree to store p2m type as PTE doesn't have enough free bits to
>     store type.
>   - default_access to store p2m access type for each page in the domain.
>   - back pointer to domain structure.
> - p2m_init() to initalize members introduced in p2m_domain structure.
> - Introudce p2m_write_lock() and p2m_is_write_locked().

What about the reader variant? If you don't need that, why not use a simple
spin lock?

> @@ -14,6 +18,29 @@
>  
>  /* Per-p2m-table state */
>  struct p2m_domain {
> +    /*
> +     * Lock that protects updates to the p2m.
> +     */
> +    rwlock_t lock;
> +
> +    /* Pages used to construct the p2m */
> +    struct page_list_head pages;
> +
> +    /* Indicate if it is required to clean the cache when writing an entry */
> +    bool clean_pte;
> +
> +    struct radix_tree_root p2m_type;

A field with a p2m_ prefix in a p2m struct? And is this tree really about
just a single "type"?

> +    /*
> +     * Default P2M access type for each page in the the domain: new pages,
> +     * swapped in pages, cleared pages, and pages that are ambiguously
> +     * retyped get this access type.  See definition of p2m_access_t.
> +     */
> +    p2m_access_t default_access;
> +
> +    /* Back pointer to domain */
> +    struct domain *domain;

This you may want to introduce earlier, to prefer passing around struct
p2m_domain * in / to P2M functions (which would benefit earlier patches
already, I think).

> --- a/xen/arch/riscv/p2m.c
> +++ b/xen/arch/riscv/p2m.c
> @@ -1,13 +1,46 @@
>  #include 
> +#include 
>  #include 
> +#include 
>  #include 
> +#include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
>  
> +#include 
>  #include 
>  #include 
>  
> +/*
> + * Force a synchronous P2M TLB flush.
> + *
> + * Must be called with the p2m lock held.
> + */
> +static void p2m_force_tlb_flush_sync(struct p2m_domain *p2m)
> +{
> +    struct domain *d = p2m->domain;
> +
> +    ASSERT(p2m_is_write_locked(p2m));
> +
> +    sbi_remote_hfence_gvma_vmid(d->dirty_cpumask, 0, 0, p2m->vmid);
> +}
> +
> +/* Unlock the flush and do a P2M TLB flush if necessary */
> +void p2m_write_unlock(struct p2m_domain *p2m)
> +{
> +    /*
> +     * The final flush is done with the P2M write lock taken to avoid
> +     * someone else modifying the P2M wbefore the TLB invalidation has
> +     * completed.
> +     */
> +    p2m_force_tlb_flush_sync(p2m);

The comment ahead of the function says "if necessary". Yet there's no
conditional here. I also question the need for a global flush in all
cases.

> @@ -109,8 +142,33 @@ int p2m_init(struct domain *d)
>      spin_lock_init(&d->arch.paging.lock);
>      INIT_PAGE_LIST_HEAD(&d->arch.paging.p2m_freelist);
>  
> +    rwlock_init(&p2m->lock);
> +    INIT_PAGE_LIST_HEAD(&p2m->pages);
> +
>      p2m->vmid = INVALID_VMID;
>  
> +    p2m->default_access = p2m_access_rwx;
> +
> +    radix_tree_init(&p2m->p2m_type);
> +
> +#ifdef CONFIG_HAS_PASSTHROUGH

Do you expect this to be conditionally selected on RISC-V?

> +    /*
> +     * Some IOMMUs don't support coherent PT walk. When the p2m is
> +     * shared with the CPU, Xen has to make sure that the PT changes have
> +     * reached the memory
> +     */
> +    p2m->clean_pte = is_iommu_enabled(d) &&
> +        !iommu_has_feature(d, IOMMU_FEAT_COHERENT_WALK);

The comment talks about shared page tables, yet you don't check whether
page table sharing is actually enabled for the domain.

> +#else
> +    p2m->clean_pte = false;

I hope the struct starts out zero-filled, in which case you wouldn't need
this.

> +#endif
> +
> +    /*
> +     * "Trivial" initialisation is now complete.  Set the backpointer so the
> +     * users of p2m could get an access to domain structure.
> +     */
> +    p2m->domain = d;

Better set this about the very first thing?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 16:16:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 16:16:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019323.1396139 (Exim 4.92)
	(envelope-from )
	id 1uRvSl-0002jh-Up; Wed, 18 Jun 2025 16:16:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019323.1396139; Wed, 18 Jun 2025 16:16: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 1uRvSl-0002jZ-RT; Wed, 18 Jun 2025 16:16:35 +0000
Received: by outflank-mailman (input) for mailman id 1019323;
 Wed, 18 Jun 2025 16:16: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 1uRvSj-0002jT-S6
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 16:16:34 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 985caeaf-4c5f-11f0-b894-0df219b8e170;
 Wed, 18 Jun 2025 18:16:31 +0200 (CEST)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 (Authenticated sender: nicola)
 by support.bugseng.com (Postfix) with ESMTPA id 1F8CB4EE95F1;
 Wed, 18 Jun 2025 18:16:30 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 985caeaf-4c5f-11f0-b894-0df219b8e170
Authentication-Results: bugseng.com; arc=none smtp.remote-ip=162.55.131.47
ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1750263390;
	b=efhYunlRD3B0b87+wZoT14BhLFBOVQkSP8hFgrf/6B53CcrvJjHo8Rw+gsQZuRA/xiqD
	 +E6TfUwD8klRetmFrcFfvQH515PSQkySKRfP+ayXXFuguUCF5yabQJcPeJGMK+UGKrfHr
	 hiRnq5aiJaC9NPPHDN1SgfBCfIAdbZkd3NQsUjtsb/bvhpFumUDabsvt7Ej78LkIgLAiX
	 5VtVWOvSxmVO6e3ZNpMzZYPSNg6JGtYs4JVsI/Emkd/jmdrvmYIfE1KFJrHHRNDyRcOP3
	 R8sFQY8SxXlMLJWdPzbhSboZetl7r1NjXNBjj3xsVxzTXJDxUFB2bGj6IAqCFI7lev5sX
	 XjPP5m0p/T7C3FaX/TkQgKE87xJ8hLyWH7VsIEVHlxQ8lfzMi1uRw5Xn6YSJbHE36Mv+7
	 2fjcd6goV+SHnkFCQSstIkS5E2zbzyjx+kKgIZBLrYrBJaqcrBKx0z1ANGbYE+rYizq97
	 ZLdff01knq+4gUssWLuEi9rS4fI9Vksz4y273ezlPTaPLgE+WA7YYAzC2QuRkEmeFkGxG
	 D/QY0+l2W+2/IKt0pDBF/s9t1jC+deYCL3zqsW79NXvi9Xz2KPqa6WkuaKK1aGcU+unAN
	 gqZ6NYvm63ARLBAYMCapsJ+2GIpcEp8zDkk9W42vjjZeAIQLyyEbZJ9UMvkocMs=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1750263390;
	h=DKIM-Signature:MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:
	 References:Message-ID:X-Sender:Organization:Content-Type:
	 Content-Transfer-Encoding;
	bh=v8dcxBpXxBY531kBItLi3DP5GNcZ4e9+6Ma8JQEhBDI=;
	b=Oxfp0reiEVuqDektEIAUwmSgjaNNla7zDEpQKnCiDq5pY1LbODDwCnQkR0Jc00nTGeue
	 r/hAtY+bpHtyT/xlT6IlQMyQi/QxgjxkmT7N9NMh3T587w1DRheW1g+U2GU9xG6QLl550
	 Gp8xcWc9guovtqI9lcYRxCuJEZ5F87ItgvUmRkPKDBiFSt2EYUQkb8wI1gStXB7jbRnAf
	 q+kRtpPluD8/4knpWJVkMg0zsOzwZcEhKv3iNcRChAjIrtzE8iBxQg3IlnHBLJqIz07oc
	 K9LXaoeSKtY/a6cvGMZgcH/e+shvWQZu1xaF6/k3+D8tqiPIi+8KGcdzN+mpICOXI8S1Z
	 7vHq7SmFYZuA5twgGcCH4ObrqIDu0sMmJJLTAKamnuXWkILxGQuoITCAGkzVzK1XqUedT
	 QHXX3yGECVPOE6syIE1qoNttQS2zmq604rlRGiN0laZRePsFonFhaNSv1arqMOeBv6bJA
	 38JPHtnAKbr/YW7969xOSq1sdlONqQlFyeG4lTtttcwXkMdb6tnA9WVHk/HrtL2nsVGjf
	 hijVM6xuj8YYysn82Sh+jFWe1TKK7K569S086jR7+bUpmzeqcW60ROKvbZN0r3XiUJzJZ
	 N22Wjd2EubYmjrLU5+NT6L+ucYTwhHkhl9WAhm4D6M5xh9nn+sOJQwkt0oRt4NQ=
ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1750263390; bh=9dCz/Nyb4D4ryKXLgcw28/cePNIrFqkCk8Xa7HTokGQ=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=Zq3crVlaW0vpJ57GRIzBBNF7rb72od9UpnTWTpj/I5TQ+giCEQ1ixB0Pb4AoSYkLL
	 UNKwFhCIDcbWwvptCuC8uCiA0CUSsalxe7ZJPW7G+YasIWQgoUKbMKB5o8VigYd3Di
	 s8jbeDRcNq1NkwQbjXJSE0eBVXWkdrXimeeg2nuSpx7RN1E+cUtHEyYAyLnLfkGl3B
	 mrc4jPLddnYm9w+3NoiqIYr7O4TcFrSSweJGTRC3EGLYvaHlrZfyYEdVxc1gipyflt
	 +J8KgWondYAl0XvrBBn6d+G4+eBdRNsVppL89HIWpQ9/i//UwkPuRRTo7ZO3XEhUGN
	 L1ksUmM4glYCQ==
MIME-Version: 1.0
Date: Wed, 18 Jun 2025 18:16:30 +0200
From: Nicola Vetrini 
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: victorm.lira@amd.com, xen-devel@lists.xenproject.org, Andrew Cooper
 , Anthony PERARD ,
 Michal Orzel , Jan Beulich , Julien
 Grall , Stefano Stabellini ,
 Federico Serafini , Bertrand Marquis
 
Subject: Re: [PATCH v2 3/3] xen/x86: add missing noreturn attributes
In-Reply-To: 
References: <20250606212712.1901838-1-victorm.lira@amd.com>
 <20250606212712.1901838-2-victorm.lira@amd.com>
 <20250606212712.1901838-3-victorm.lira@amd.com>
 
Message-ID: <220ccb5869914c44cc2b1f7a152ee933@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 2025-06-18 17:18, Roger Pau Monné wrote:
> On Fri, Jun 06, 2025 at 02:27:09PM -0700, victorm.lira@amd.com wrote:
>> From: Nicola Vetrini 
>> 
>> The marked functions never return to their caller, but lack the
>> `noreturn' attribute.
>> 
>> Functions that never return should be declared with a `noreturn'
>> attribute.
>> 
>> The lack of `noreturn' causes a violation of MISRA C Rule 17.11 (not
>> currently accepted in Xen), and also Rule 2.1: "A project shall not
>> contain unreachable code". Depending on the compiler used and the
>> compiler optimization used, the lack of `noreturn' might lead to the
>> presence of unreachable code.
>> 
>> No functional change.
>> 
>> Signed-off-by: Nicola Vetrini 
>> Signed-off-by: Victor Lira 
> 
> Acked-by: Roger Pau Monné 
> 
> One question below.
> 
>> ---
>> Changes in v2:
>> - improved commit message
>> ---
>> Cc: Andrew Cooper 
>> Cc: Anthony PERARD 
>> Cc: Michal Orzel 
>> Cc: Jan Beulich 
>> Cc: Julien Grall 
>> Cc: Roger Pau Monné 
>> Cc: Stefano Stabellini 
>> Cc: Nicola Vetrini 
>> Cc: Federico Serafini 
>> Cc: Bertrand Marquis 
>> ---
>>  xen/arch/x86/cpu/mcheck/mce.c | 3 ++-
>>  xen/arch/x86/efi/efi-boot.h   | 2 +-
>>  xen/arch/x86/smp.c            | 2 +-
>>  xen/arch/x86/traps.c          | 2 +-
>>  xen/arch/x86/x86_64/traps.c   | 2 +-
>>  5 files changed, 6 insertions(+), 5 deletions(-)
>> 
>> diff --git a/xen/arch/x86/cpu/mcheck/mce.c 
>> b/xen/arch/x86/cpu/mcheck/mce.c
>> index 1c348e557d..79214ce56b 100644
>> --- a/xen/arch/x86/cpu/mcheck/mce.c
>> +++ b/xen/arch/x86/cpu/mcheck/mce.c
>> @@ -79,7 +79,8 @@ static int __init cf_check mce_set_verbosity(const 
>> char *str)
>>  custom_param("mce_verbosity", mce_set_verbosity);
>> 
>>  /* Handle unconfigured int18 (should never happen) */
>> -static void cf_check unexpected_machine_check(const struct 
>> cpu_user_regs *regs)
>> +static void noreturn cf_check
>> +unexpected_machine_check(const struct cpu_user_regs *regs)
>>  {
>>      console_force_unlock();
>>      printk("Unexpected Machine Check Exception\n");
>> diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
>> index 0ecf4ca53f..0194720003 100644
>> --- a/xen/arch/x86/efi/efi-boot.h
>> +++ b/xen/arch/x86/efi/efi-boot.h
>> @@ -769,7 +769,7 @@ static void __init efi_arch_blexit(void)
>>          efi_bs->FreePages(ucode.addr, PFN_UP(ucode.size));
>>  }
>> 
>> -static void __init efi_arch_halt(void)
>> +static void noreturn __init efi_arch_halt(void)
>>  {
>>      local_irq_disable();
>>      for ( ; ; )
>> diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c
>> index 516dab5528..7936294f5f 100644
>> --- a/xen/arch/x86/smp.c
>> +++ b/xen/arch/x86/smp.c
>> @@ -343,7 +343,7 @@ void __stop_this_cpu(void)
>>      cpumask_clear_cpu(smp_processor_id(), &cpu_online_map);
>>  }
>> 
>> -static void cf_check stop_this_cpu(void *dummy)
>> +static void noreturn cf_check stop_this_cpu(void *dummy)
>>  {
>>      const bool *stop_aps = dummy;
>> 
>> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
>> index 092c7e4197..34dc077cad 100644
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -805,7 +805,7 @@ void fatal_trap(const struct cpu_user_regs *regs, 
>> bool show_remote)
>>            (regs->eflags & X86_EFLAGS_IF) ? "" : " IN INTERRUPT 
>> CONTEXT");
>>  }
>> 
>> -void asmlinkage do_unhandled_trap(struct cpu_user_regs *regs)
>> +void asmlinkage noreturn do_unhandled_trap(struct cpu_user_regs 
>> *regs)
>>  {
>>      fatal_trap(regs, false);
>>  }
>> diff --git a/xen/arch/x86/x86_64/traps.c b/xen/arch/x86/x86_64/traps.c
>> index c77f304bb0..8460a4a1ae 100644
>> --- a/xen/arch/x86/x86_64/traps.c
>> +++ b/xen/arch/x86/x86_64/traps.c
>> @@ -293,7 +293,7 @@ void show_page_walk(unsigned long addr)
>>             l1_table_offset(addr), l1e_get_intpte(l1e), pfn);
>>  }
>> 
>> -void asmlinkage do_double_fault(struct cpu_user_regs *regs)
>> +void asmlinkage noreturn do_double_fault(struct cpu_user_regs *regs)
> 
> Does noreturn matter for functions called from assembly (asmlinkage
> ones)?  In that case the hint is not useful for code generation, since
> it's hand written assembly already?  (it's arguably useful for the
> developer writing the code)
> 
> Might be worth mentioning in the commit message if the above is
> accurate.  For example by adding to the commit message: "noreturn is
> not relevant for functions called from assembly, but can be used as a
> hint for the developers writing the code".
> 

Yes, it is relevant because the rule considers only the single function, 
not the context where it is called (that is orders of magnitude more 
difficult to check automatically). For my part, I'm ok with your 
suggestion.

> Thanks, Roger.

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 17:26:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 17:26:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019361.1396150 (Exim 4.92)
	(envelope-from )
	id 1uRwXz-0003Gv-N1; Wed, 18 Jun 2025 17:26:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019361.1396150; Wed, 18 Jun 2025 17:26: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 1uRwXz-0003Go-I2; Wed, 18 Jun 2025 17:26:03 +0000
Received: by outflank-mailman (input) for mailman id 1019361;
 Wed, 18 Jun 2025 17:26: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 1uRwXy-0003Gi-25
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 17:26:02 +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 4cab4700-4c69-11f0-a30b-13f23c93f187;
 Wed, 18 Jun 2025 19:25:59 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3a54836cb7fso5149062f8f.2
 for ; Wed, 18 Jun 2025 10:25:59 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-4535ebd02basm3056645e9.39.2025.06.18.10.25.57
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 18 Jun 2025 10:25:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4cab4700-4c69-11f0-a30b-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750267558; x=1750872358; 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=DDgkxMYDVJTHvv5S/2KrkrBS+SQ+ZpLwE3G2lAfMf9A=;
        b=Bzp3sfhR6vZWeBtAJIQ84WfUj+HoAloWNq5Q2vybaCHEKoJAI74yo8bL90UuszxPBm
         XO+Kk5MFrSSTQ8qeXl53Ib9t+JP686rR+HnZ73BEpk3Je1QDvrQmxDj2Aruivz3XpEvA
         texQZnhJef0yRaQdGCcAej7jwJ0OllouIekqk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750267558; x=1750872358;
        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=DDgkxMYDVJTHvv5S/2KrkrBS+SQ+ZpLwE3G2lAfMf9A=;
        b=qZDIuVCIKK/f2Sj3TLnpmN1RCQTggz1mhbZD03KC4XbUdCG/fsFKQ3UKwN9pZbgBr5
         EGRFz/YCVcMxhvU9qIXmmqWZ7ddHAazea8XtazYihiUf9TNSX1Xiicc8/ry2rGKNtjOk
         7Qz/J42DKRTzWwiSWPEX0Uio6E5Lq5EaWy5KPASW3R8ljPZ+4yFlH21m0vQ+SB+01eZu
         D4y38Q9vsQjnzJWPDfqAZDkr8ylkYYNjjIX/2KhtHU4w7T5Tw1BLo0Af8pb30PdyPHIU
         N52xrIcb0KXE1P8nCWTALEX6GHKwYxkWl1uC+UE/G+TcmuWeYH/4xDXdLTihhyDu4gv6
         LbNw==
X-Forwarded-Encrypted: i=1; AJvYcCXgg5lKoWTry9TpMPYW9vb5R/l943GrkklssZAJNchv30Hv5G8R33Zc90w1+vfWw0V7C1hX0k6OG68=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxhOavvrlHZysLz+sVaUxvumcn2Ct5RnsjuhxvpPNec0FumyGqF
	Zil3/blUUu4TspZBJMpFNwkuACkmj29zzIkLnFXlA0YxRtN8X4U7tyvpOjtbexlqOfk=
X-Gm-Gg: ASbGncvMYvTl4a+VrdLcS1NimNPY5jFwV441RynjcHl2V9rAs7dZfu6jaLd3qTHR3Mz
	enxmIIKI3xZLSm7/jkDXW4RJOPLoPwVQXOLQIxBQ23zrCHEyiEVOfZNLxkzLZMaFGb0jw7gu55t
	Ad7tte4Au0NKBRUGf0WhX/ULt7ovmE8d6HHzxMxDksN9GZZYqaikkF9S9mLfQjz5lRJopQ0b9RU
	UBpYqt22IfY1VpheJ2dlqi4VotegerBvBOwR0afANEr/odW7I1NBs+rALBo5hWvwpuGal/gM0Yb
	CmQC+GHB4cOwKhMicrP8vgKQdH4MAKxZLfv2R570PtEWa4JSLibV1qm7IEUFPMtlNBSsWf4QQCR
	qezk7psWcO5ekc6TxmRvbF8K9sX7zJg+l5Qc=
X-Google-Smtp-Source: AGHT+IGJ2YL/u884wzR9OEfA/yUI8w1O0IM1F/GdgDMFeLDeq0CD8pqh/OfIkjCGIkvew/ukZO0kOg==
X-Received: by 2002:a05:6000:4006:b0:3a0:7d27:f076 with SMTP id ffacd0b85a97d-3a572367967mr17101692f8f.2.1750267558472;
        Wed, 18 Jun 2025 10:25:58 -0700 (PDT)
Date: Wed, 18 Jun 2025 19:25:57 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Nicola Vetrini 
Cc: victorm.lira@amd.com, xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini ,
	Federico Serafini ,
	Bertrand Marquis 
Subject: Re: [PATCH v2 3/3] xen/x86: add missing noreturn attributes
Message-ID: 
References: <20250606212712.1901838-1-victorm.lira@amd.com>
 <20250606212712.1901838-2-victorm.lira@amd.com>
 <20250606212712.1901838-3-victorm.lira@amd.com>
 
 <220ccb5869914c44cc2b1f7a152ee933@bugseng.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <220ccb5869914c44cc2b1f7a152ee933@bugseng.com>

On Wed, Jun 18, 2025 at 06:16:30PM +0200, Nicola Vetrini wrote:
> On 2025-06-18 17:18, Roger Pau Monné wrote:
> > On Fri, Jun 06, 2025 at 02:27:09PM -0700, victorm.lira@amd.com wrote:
> > > From: Nicola Vetrini 
> > > 
> > > The marked functions never return to their caller, but lack the
> > > `noreturn' attribute.
> > > 
> > > Functions that never return should be declared with a `noreturn'
> > > attribute.
> > > 
> > > The lack of `noreturn' causes a violation of MISRA C Rule 17.11 (not
> > > currently accepted in Xen), and also Rule 2.1: "A project shall not
> > > contain unreachable code". Depending on the compiler used and the
> > > compiler optimization used, the lack of `noreturn' might lead to the
> > > presence of unreachable code.
> > > 
> > > No functional change.
> > > 
> > > Signed-off-by: Nicola Vetrini 
> > > Signed-off-by: Victor Lira 
> > 
> > Acked-by: Roger Pau Monné 
> > 
> > One question below.
> > 
> > > ---
> > > Changes in v2:
> > > - improved commit message
> > > ---
> > > Cc: Andrew Cooper 
> > > Cc: Anthony PERARD 
> > > Cc: Michal Orzel 
> > > Cc: Jan Beulich 
> > > Cc: Julien Grall 
> > > Cc: Roger Pau Monné 
> > > Cc: Stefano Stabellini 
> > > Cc: Nicola Vetrini 
> > > Cc: Federico Serafini 
> > > Cc: Bertrand Marquis 
> > > ---
> > >  xen/arch/x86/cpu/mcheck/mce.c | 3 ++-
> > >  xen/arch/x86/efi/efi-boot.h   | 2 +-
> > >  xen/arch/x86/smp.c            | 2 +-
> > >  xen/arch/x86/traps.c          | 2 +-
> > >  xen/arch/x86/x86_64/traps.c   | 2 +-
> > >  5 files changed, 6 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/xen/arch/x86/cpu/mcheck/mce.c
> > > b/xen/arch/x86/cpu/mcheck/mce.c
> > > index 1c348e557d..79214ce56b 100644
> > > --- a/xen/arch/x86/cpu/mcheck/mce.c
> > > +++ b/xen/arch/x86/cpu/mcheck/mce.c
> > > @@ -79,7 +79,8 @@ static int __init cf_check mce_set_verbosity(const
> > > char *str)
> > >  custom_param("mce_verbosity", mce_set_verbosity);
> > > 
> > >  /* Handle unconfigured int18 (should never happen) */
> > > -static void cf_check unexpected_machine_check(const struct
> > > cpu_user_regs *regs)
> > > +static void noreturn cf_check
> > > +unexpected_machine_check(const struct cpu_user_regs *regs)
> > >  {
> > >      console_force_unlock();
> > >      printk("Unexpected Machine Check Exception\n");
> > > diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
> > > index 0ecf4ca53f..0194720003 100644
> > > --- a/xen/arch/x86/efi/efi-boot.h
> > > +++ b/xen/arch/x86/efi/efi-boot.h
> > > @@ -769,7 +769,7 @@ static void __init efi_arch_blexit(void)
> > >          efi_bs->FreePages(ucode.addr, PFN_UP(ucode.size));
> > >  }
> > > 
> > > -static void __init efi_arch_halt(void)
> > > +static void noreturn __init efi_arch_halt(void)
> > >  {
> > >      local_irq_disable();
> > >      for ( ; ; )
> > > diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c
> > > index 516dab5528..7936294f5f 100644
> > > --- a/xen/arch/x86/smp.c
> > > +++ b/xen/arch/x86/smp.c
> > > @@ -343,7 +343,7 @@ void __stop_this_cpu(void)
> > >      cpumask_clear_cpu(smp_processor_id(), &cpu_online_map);
> > >  }
> > > 
> > > -static void cf_check stop_this_cpu(void *dummy)
> > > +static void noreturn cf_check stop_this_cpu(void *dummy)
> > >  {
> > >      const bool *stop_aps = dummy;
> > > 
> > > diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
> > > index 092c7e4197..34dc077cad 100644
> > > --- a/xen/arch/x86/traps.c
> > > +++ b/xen/arch/x86/traps.c
> > > @@ -805,7 +805,7 @@ void fatal_trap(const struct cpu_user_regs
> > > *regs, bool show_remote)
> > >            (regs->eflags & X86_EFLAGS_IF) ? "" : " IN INTERRUPT
> > > CONTEXT");
> > >  }
> > > 
> > > -void asmlinkage do_unhandled_trap(struct cpu_user_regs *regs)
> > > +void asmlinkage noreturn do_unhandled_trap(struct cpu_user_regs
> > > *regs)
> > >  {
> > >      fatal_trap(regs, false);
> > >  }
> > > diff --git a/xen/arch/x86/x86_64/traps.c b/xen/arch/x86/x86_64/traps.c
> > > index c77f304bb0..8460a4a1ae 100644
> > > --- a/xen/arch/x86/x86_64/traps.c
> > > +++ b/xen/arch/x86/x86_64/traps.c
> > > @@ -293,7 +293,7 @@ void show_page_walk(unsigned long addr)
> > >             l1_table_offset(addr), l1e_get_intpte(l1e), pfn);
> > >  }
> > > 
> > > -void asmlinkage do_double_fault(struct cpu_user_regs *regs)
> > > +void asmlinkage noreturn do_double_fault(struct cpu_user_regs *regs)
> > 
> > Does noreturn matter for functions called from assembly (asmlinkage
> > ones)?  In that case the hint is not useful for code generation, since
> > it's hand written assembly already?  (it's arguably useful for the
> > developer writing the code)
> > 
> > Might be worth mentioning in the commit message if the above is
> > accurate.  For example by adding to the commit message: "noreturn is
> > not relevant for functions called from assembly, but can be used as a
> > hint for the developers writing the code".
> > 
> 
> Yes, it is relevant because the rule considers only the single function, not
> the context where it is called (that is orders of magnitude more difficult
> to check automatically). For my part, I'm ok with your suggestion.

Thanks, so if my understanding is correct the usage of the noreturn
attribute together with asmlinkage is only for the benefit of the
analysis tools, as from a code generation perspective it makes no
difference.

Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jun 18 17:32:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 17:32:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019368.1396159 (Exim 4.92)
	(envelope-from )
	id 1uRweJ-0004rN-8t; Wed, 18 Jun 2025 17:32:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019368.1396159; Wed, 18 Jun 2025 17: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 1uRweJ-0004rG-5h; Wed, 18 Jun 2025 17:32:35 +0000
Received: by outflank-mailman (input) for mailman id 1019368;
 Wed, 18 Jun 2025 17:32: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 1uRweI-0004rA-30
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 17:32:34 +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 36e03354-4c6a-11f0-a30b-13f23c93f187;
 Wed, 18 Jun 2025 19:32:32 +0200 (CEST)
Received: by mail-oi1-x22d.google.com with SMTP id
 5614622812f47-4067ac8f6cdso5082943b6e.2
 for ; Wed, 18 Jun 2025 10:32:32 -0700 (PDT)
Received: from localhost ([2603:8080:b800:f700:1b3b:c162:aefa:da1b])
 by smtp.gmail.com with ESMTPSA id
 5614622812f47-40a740c2484sm2410989b6e.13.2025.06.18.10.32.29
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 18 Jun 2025 10:32:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 36e03354-4c6a-11f0-a30b-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1750267951; x=1750872751; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:message-id:subject:cc
         :to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=JPaDHCf4QQfYtlFAEXP1n0ACjJsy8xyFFkSONW+4dVI=;
        b=fcoyYa5/vgLStJBGnfJQzsf080XXodxKAVM49xiYCaZnK6LO5HI0ogtMpnn5VlNFMd
         +5kaBmNTDnkXlkD++wvqsQ2Q2oqREOQg6CCPXpdCfp1vqcceF0OZqlPBU6l28Aa63dC+
         Ir3LhxB3RqXglRFa0jku34hcOYX5RWSs/c4IaE5XMjXo5Tj3AvktjybOXjBP1yphFQCq
         zRjm/IcYTTjFbq1vTW8pTtNWRPeDlNjE5pv+1smuESRCQaXkEtodZSNNxRgulLDHLpoK
         vRxJHDnldSN7BF3ZywXniOiHIvzP7mLpNNwaERd5RJcTjHuPA+G4qO/a+zQVZLhW99wF
         4udg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750267951; x=1750872751;
        h=in-reply-to:content-disposition:mime-version:message-id:subject:cc
         :to:from:date:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=JPaDHCf4QQfYtlFAEXP1n0ACjJsy8xyFFkSONW+4dVI=;
        b=LMyCeWCk6Rkxd9SMuQQUx5H2cM3Mf36AY0zmg+HsZJJEsRz12e//+e+Apx3rXWp27B
         SxEwgR7TT7ZzmHaVSgI7642TFks4v8eLbMmgLB3106HaHawEQoNGSiUZq3XXJesebLmj
         I3C4yhb7MZ3f+YI/9/1LLkGe7kgye5MNa2sV2qYi60HVvLrsICfmAV5doWNu0ewjXkSf
         RNwsgEpfqXUBoCHRd7EDGH2Ba92N5WDB6EljtC88dWIDQrn4tdgn3uPx3SNuE6kYmBDu
         o826KqsZWoIsA8iXkWOUpjar3SKgw6VbdVLBKunQvyaIy3T6+xQ1kZSBnqrYArjMIhwR
         JdvA==
X-Forwarded-Encrypted: i=1; AJvYcCWzHospFtjRMANgUGDPnluQlQeNhwQDL1tWv3AQogoKR0nidmdC6Lu7NogxhJsRDwtNa8XTmkHzdLw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YykAk6QUbd4M1+ut1UKf3mcL57/ln8Hf5g7/5dROSoCgzz766MO
	waoml8qeJTEBrsy0DA/2UVb/xBco2btnBONnOo4M3ph5DGjubztqcyJjlhGcqJC4rME=
X-Gm-Gg: ASbGnctpUR0L0AxNSni8im15r6cVtenryV1gCQmkLqBfJwobvmA/6K8XU5kX34Gm3KR
	8CSPzF7IQ9HYHw/DCZ22kkFwTOP0htCw/+AIpMO06+hPWhIMu75g6gjxunOulvlMfCc2kVCpygz
	rLmEkcnXiWo10jS1GHVvzG3bSfO0uTUJQQgRs2ZSZR/ior6GId1KuSDcxdral41e3pqlQDH2HH1
	S+X1uAJz20AEXbzhSi1Psko9DvuqFzZQVAvtDkaGh2CKVwGNyUfa/zhPfF83dOBxLmdBqdJTJYc
	J3nT9e7z9pRwufrtY/0OcIutUFeTop8hwqLcVFAMxT6+ZQYvxmrE9zaRLtUuwxQYISHEcw==
X-Google-Smtp-Source: AGHT+IEhmsXj/9aFuinmgp9fFM5zxL8AzdLs118MWezycsaLkbKoWiwnYgYHLgU6A9s7/1JQmPa7zA==
X-Received: by 2002:a05:6808:1523:b0:403:5150:c348 with SMTP id 5614622812f47-40a7c11902fmr11343414b6e.4.1750267951380;
        Wed, 18 Jun 2025 10:32:31 -0700 (PDT)
Date: Wed, 18 Jun 2025 20:32:28 +0300
From: Dan Carpenter 
To: oe-kbuild@lists.linux.dev, Alexander Gordeev ,
	Andrew Morton 
Cc: lkp@intel.com, oe-kbuild-all@lists.linux.dev,
	Linux Memory Management List ,
	linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org,
	xen-devel@lists.xenproject.org, linuxppc-dev@lists.ozlabs.org,
	linux-s390@vger.kernel.org, Hugh Dickins ,
	Nicholas Piggin ,
	Guenter Roeck , Juergen Gross ,
	Jeremy Fitzhardinge ,
	Ryan Roberts 
Subject: Re: [PATCH 2/6] mm: Lock kernel page tables before entering lazy MMU
 mode
Message-ID: <0be7d42e-5898-4b94-829b-59c661c2f07b@suswa.mountain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7bd3a45dbc375dc2c15cebae09cb2bb972d6039f.1749747752.git.agordeev@linux.ibm.com>

Hi Alexander,

kernel test robot noticed the following build warnings:

url:    https://github.com/intel-lab-lkp/linux/commits/Alexander-Gordeev/mm-Cleanup-apply_to_pte_range-routine/20250613-013835
base:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
patch link:    https://lore.kernel.org/r/7bd3a45dbc375dc2c15cebae09cb2bb972d6039f.1749747752.git.agordeev%40linux.ibm.com
patch subject: [PATCH 2/6] mm: Lock kernel page tables before entering lazy MMU mode
config: x86_64-randconfig-161-20250613 (https://download.01.org/0day-ci/archive/20250613/202506132017.T1l1l6ME-lkp@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Reported-by: Dan Carpenter 
| Closes: https://lore.kernel.org/r/202506132017.T1l1l6ME-lkp@intel.com/

smatch warnings:
mm/vmalloc.c:552 vmap_pages_pte_range() warn: inconsistent returns 'global &init_mm.page_table_lock'.

vim +552 mm/vmalloc.c

0a264884046f1ab Nicholas Piggin   2021-04-29  517  static int vmap_pages_pte_range(pmd_t *pmd, unsigned long addr,
2ba3e6947aed9bb Joerg Roedel      2020-06-01  518  		unsigned long end, pgprot_t prot, struct page **pages, int *nr,
2ba3e6947aed9bb Joerg Roedel      2020-06-01  519  		pgtbl_mod_mask *mask)
^1da177e4c3f415 Linus Torvalds    2005-04-16  520  {
^1da177e4c3f415 Linus Torvalds    2005-04-16  521  	pte_t *pte;
^1da177e4c3f415 Linus Torvalds    2005-04-16  522  
db64fe02258f150 Nicholas Piggin   2008-10-18  523  	/*
db64fe02258f150 Nicholas Piggin   2008-10-18  524  	 * nr is a running index into the array which helps higher level
db64fe02258f150 Nicholas Piggin   2008-10-18  525  	 * callers keep track of where we're up to.
db64fe02258f150 Nicholas Piggin   2008-10-18  526  	 */
db64fe02258f150 Nicholas Piggin   2008-10-18  527  
2ba3e6947aed9bb Joerg Roedel      2020-06-01  528  	pte = pte_alloc_kernel_track(pmd, addr, mask);
^1da177e4c3f415 Linus Torvalds    2005-04-16  529  	if (!pte)
^1da177e4c3f415 Linus Torvalds    2005-04-16  530  		return -ENOMEM;
44562c71e2cfc9e Ryan Roberts      2025-04-22  531  
dac0cc793368851 Alexander Gordeev 2025-06-12  532  	spin_lock(&init_mm.page_table_lock);
44562c71e2cfc9e Ryan Roberts      2025-04-22  533  	arch_enter_lazy_mmu_mode();
44562c71e2cfc9e Ryan Roberts      2025-04-22  534  
^1da177e4c3f415 Linus Torvalds    2005-04-16  535  	do {
db64fe02258f150 Nicholas Piggin   2008-10-18  536  		struct page *page = pages[*nr];
db64fe02258f150 Nicholas Piggin   2008-10-18  537  
c33c794828f2121 Ryan Roberts      2023-06-12  538  		if (WARN_ON(!pte_none(ptep_get(pte))))
db64fe02258f150 Nicholas Piggin   2008-10-18  539  			return -EBUSY;
db64fe02258f150 Nicholas Piggin   2008-10-18  540  		if (WARN_ON(!page))
^1da177e4c3f415 Linus Torvalds    2005-04-16  541  			return -ENOMEM;
4fcdcc12915c707 Yury Norov        2022-04-28  542  		if (WARN_ON(!pfn_valid(page_to_pfn(page))))
4fcdcc12915c707 Yury Norov        2022-04-28  543  			return -EINVAL;

These error paths don't unlock &init_mm.page_table_lock?

4fcdcc12915c707 Yury Norov        2022-04-28  544  
^1da177e4c3f415 Linus Torvalds    2005-04-16  545  		set_pte_at(&init_mm, addr, pte, mk_pte(page, prot));
db64fe02258f150 Nicholas Piggin   2008-10-18  546  		(*nr)++;
^1da177e4c3f415 Linus Torvalds    2005-04-16  547  	} while (pte++, addr += PAGE_SIZE, addr != end);
44562c71e2cfc9e Ryan Roberts      2025-04-22  548  
44562c71e2cfc9e Ryan Roberts      2025-04-22  549  	arch_leave_lazy_mmu_mode();
dac0cc793368851 Alexander Gordeev 2025-06-12  550  	spin_unlock(&init_mm.page_table_lock);
2ba3e6947aed9bb Joerg Roedel      2020-06-01  551  	*mask |= PGTBL_PTE_MODIFIED;
^1da177e4c3f415 Linus Torvalds    2005-04-16 @552  	return 0;
^1da177e4c3f415 Linus Torvalds    2005-04-16  553  }

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki



From xen-devel-bounces@lists.xenproject.org Wed Jun 18 18:46:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jun 2025 18:46:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019414.1396170 (Exim 4.92)
	(envelope-from )
	id 1uRxo4-0005Tk-Da; Wed, 18 Jun 2025 18:46:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019414.1396170; Wed, 18 Jun 2025 18:46:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uRxo4-0005Td-8w; Wed, 18 Jun 2025 18:46:44 +0000
Received: by outflank-mailman (input) for mailman id 1019414;
 Wed, 18 Jun 2025 18:46: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 1uRxo2-0005TX-Bw
 for xen-devel@lists.xenproject.org; Wed, 18 Jun 2025 18:46:42 +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 92b4bba5-4c74-11f0-a30b-13f23c93f187;
 Wed, 18 Jun 2025 20:46:41 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-451d3f72391so80843765e9.3
 for ; Wed, 18 Jun 2025 11:46:41 -0700 (PDT)
Received: from localhost.localdomain (253.226.6.51.dyn.plus.net.
 [51.6.226.253]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4535e97a908sm5006575e9.4.2025.06.18.11.46.39
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 18 Jun 2025 11:46:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 92b4bba5-4c74-11f0-a30b-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750272400; x=1750877200; 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=gcqH3k8zjSFrQGMmoyr07/3rVkK+y+EfDXKcgz6xL+Q=;
        b=bT25kaTqfo8heRjloKlrz2HJC+p+x69HRQSQh+vs+Vb1xYVJCUm58NmP/jtlTZs0Wz
         cosAqxMLGj4Z1LfaJOYUowU1CjmY8vHMsxERLPwwiRXoqe4Q+zaFFKoazxwgd5rgtneB
         dB/U69av2arKuPCcaqGPGF/MBmRpEUceIyKKA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750272400; x=1750877200;
        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=gcqH3k8zjSFrQGMmoyr07/3rVkK+y+EfDXKcgz6xL+Q=;
        b=X1mqymSginC4EcI5Iaz2LoxJjDIKw9ESQflzQMz62KO4ZwRDReZGuM3xfGxyL6MsUv
         Hm/Z8EhqbMpG6QEKcYFivuSaPQj6YiEqgSqeX653cxUjE8nc5jzXbyH+8U7At2kCY1Zd
         ohd29Zv0HZ0kBdr1PE432/MrgR2HAwSGx6hB4sOtiDCS80SQR1QFIIYuMT/gTaPBIYaZ
         h+fD5nK+4VQ/zoy8JmJtdlRK43lyFlUo2twvFnoJQwRXnB5OPkB+oOrz2BYtlyrLpwLh
         Dvm2wkgD4WYpF3JTx88FjBU0hwiykw8uegKdSbc//JgeBmRLDmY2X0l0+KIn8AacwpoA
         uDqQ==
X-Gm-Message-State: AOJu0Yyubpsw8zMvW6SjhZsKeIfzwyiFKQ898Ad0OnfDjHlOe05jHZmN
	b4U7dTA5lGQXgbbOAeWpVFD4oDEYxNLozuetPus9iHO902+zPnA7rklGpyBQv63DYEFOH7sC8se
	1NyCY/aNKYg==
X-Gm-Gg: ASbGncsBjvlqmuq/xw9WppM4fvqx1N+pBWrNP/WCUb5iPo0I0gZ05VWBfMZuGVV0VkS
	e9We2MOc8gFOYw2bsfTxRPVeaDOtzfOfNPbyZ5cH93eOFUtGWpbMCf35jzsmUE1Lgm6DBz1yQyO
	CyVUo+C7mqgoQBhPmC/V27ZHb99hd71ibeZIk8o3kCvKqviiJEsL/FMiQq1jMnxEUKACZE6L50Y
	UA4+IvcXyR7JI8QxeBdiU+FodZV0GTQkpvXWBtfET8+rGsOIwyntvA0qQ+qAkrCdwROSP+SYL80
	SyBNVO8/CgRUANvzvDpmGLVROw1hi/1+RE0z2ND6KqCZB3sfjWhMP/BRejKuixZ015xDkiZtLuo
	27yAWyxZGyDahAyJpTjaOgmvEKe5rlw==
X-Google-Smtp-Source: AGHT+IEc/jZxYa+Aek0eFvpZ+XrPQ7Hx6SKGW7SUdJoiaO8ulO/MqOd3iQjmyJJJPIOMpURg0t2aXg==
X-Received: by 2002:a05:600c:5490:b0:453:8a6:d8de with SMTP id 5b1f17b1804b1-4533ca5e5a3mr153635145e9.1.1750272400286;
        Wed, 18 Jun 2025 11:46:40 -0700 (PDT)
From: Frediano Ziglio 
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio ,
	"Daniel P. Smith" ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Jan Beulich 
Subject: [PATCH] xen/efi: Do not check kernel signature if it was embedded
Date: Wed, 18 Jun 2025 19:46:28 +0100
Message-ID: <20250618184631.15489-1-frediano.ziglio@cloud.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Using UKI it's possible to embed Linux kernel into xen.efi file.
In this case the signature for Secure Boot is applied to the
whole xen.efi, including the kernel.
So checking for specific signature for the kernel is not
needed.
In case Secure Boot is not enabled there's no reason to check
kernel signature.

Signed-off-by: Frediano Ziglio 
---
 xen/common/efi/boot.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index e39fbc3529..7077af3f5d 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -1291,6 +1291,7 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle,
     bool base_video = false;
     const char *option_str;
     bool use_cfg_file;
+    bool kernel_was_verified = false;
     int dt_modules_found;
 
     __set_bit(EFI_BOOT, &efi_flags);
@@ -1461,6 +1462,14 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle,
             read_file(dir_handle, s2w(&name), &kernel, option_str);
             efi_bs->FreePool(name.w);
         }
+        else
+        {
+            /*
+             * As kernel was embedded it was either verified for Secure Boot
+             * or Secure Boot is not enabled.
+             */
+            kernel_was_verified = true;
+        }
 
         if ( !read_section(loaded_image, L"ramdisk", &ramdisk, NULL) )
         {
@@ -1534,6 +1543,7 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle,
      * verify it.
      */
     if ( kernel.ptr &&
+         !kernel_was_verified &&
          !EFI_ERROR(efi_bs->LocateProtocol(&shim_lock_guid, NULL,
                                            (void **)&shim_lock)) &&
          (status = shim_lock->Verify(kernel.ptr, kernel.size)) != EFI_SUCCESS )
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 19 00:36:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 00:36:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019534.1396178 (Exim 4.92)
	(envelope-from )
	id 1uS3Gj-0004pz-TN; Thu, 19 Jun 2025 00:36:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019534.1396178; Thu, 19 Jun 2025 00:36: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 1uS3Gj-0004ps-Qj; Thu, 19 Jun 2025 00:36:41 +0000
Received: by outflank-mailman (input) for mailman id 1019534;
 Thu, 19 Jun 2025 00:36: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 1uS3Gi-0004pm-Tm
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 00:36:40 +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 753e74b0-4ca5-11f0-b894-0df219b8e170;
 Thu, 19 Jun 2025 02:36:37 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 152BF5C41E8;
 Thu, 19 Jun 2025 00:34:20 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 047C2C4CEE7;
 Thu, 19 Jun 2025 00:36: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: 753e74b0-4ca5-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750293396;
	bh=GRL6IyxbYn+drq4PaScVLwwlEPxmyfAbax+6VjUnLvE=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=GbwHEi0YywFcFr1NEbsLiKwj+BewRVizlC9W2K9sio3QrhIL778pSrIL8r2ryWzJO
	 hcNHNWyqvhfX4qbAekoSy8yjwbOcWEw+hURnpIfvEyYR2RCHqv+5Z+hQIpDVl0jLBv
	 xi2t2Zd6K0D0sac/kY2AxE1uf/e9x5em4jyPeSkXjDHlT/uOagFGwkmJkoerp6dgRO
	 BOXdt7BdzsgULkPOwLAEB8iopISkNdU3iL8vfEewx+Hql5226mf6+3Mf/u1Eas06fj
	 U7EJ9sqPbBllV3z6oiSRUTwOGG41RqiNf87cWkTjmPkD2A9to9CFxcE0uhUrf4Qvg4
	 Qe2B+g9evPeCA==
Date: Wed, 18 Jun 2025 17:36:33 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Stefano Stabellini , 
    Jason Andryuk , 
    Andrew Cooper , 
    Anthony PERARD , 
    Michal Orzel , Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    "Daniel P. Smith" , 
    xen-devel@lists.xenproject.org
Subject: Re: [PATCH 4/4] xsm/dummy: Allow hwdom SYSCTL_readconsole/physinfo
In-Reply-To: <5645e4dc-7598-414d-a2b5-39066401e9b3@suse.com>
Message-ID: 
References: <20250610225737.469690-1-jason.andryuk@amd.com> <20250610225737.469690-5-jason.andryuk@amd.com> <5f6d43da-2600-4c1c-9bcb-f13e8fce921e@suse.com>  
   <5645e4dc-7598-414d-a2b5-39066401e9b3@suse.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 Jun 2025, Jan Beulich wrote:
> On 17.06.2025 02:10, Stefano Stabellini wrote:
> > On Mon, 16 Jun 2025, Jan Beulich wrote:
> >> On 14.06.2025 00:51, Stefano Stabellini wrote:
> >>> On Wed, 11 Jun 2025, Jason Andryuk wrote:
> >>>> On 2025-06-11 09:27, Jan Beulich wrote:
> >>>>> On 11.06.2025 00:57, Jason Andryuk wrote:
> >>>>>> Allow the hwdom to access the console, and to access physical
> >>>>>> information about the system.
> >>>>>>
> >>>>>> xenconsoled can read Xen's dmesg.  If it's in hwdom, then that
> >>>>>> permission would be required.
> >>>>>
> >>>>> Why would xenconsoled run in the hardware domain? It's purely a software
> >>>>> construct, isn't it? As a daemon, putting it in the control domain may
> >>>>> make sense. Otherwise it probably ought to go in a service domain.
> >>>>
> >>>> My approach has been to transform dom0 into the hardware domain and add a new
> >>>> control domain.  xenconsoled was left running in the hardware domain.
> >>>
> >>> I think we should keep xenconsoled in the hardware domain because the
> >>> control domain should be just optional. (However, one could say that with
> >>> Denis' recent changes xenconsoled is also optional because one can use
> >>> console hypercalls or emulators (PL011, NS16550) for all DomUs.)
> >>>
> >>>
> >>>
> >>>> I suppose it could move.  Maybe that would be fine?  I haven't tried. The
> >>>> Hyperlaunch code populates the console grants to point at the hardware domain,
> >>>> and I just followed that.
> >>>>
> >>>> One aspect of why I left most things running in the Hardware domain was to not
> >>>> run things in the Control domain.  If Control is the highest privileged
> >>>> entity, we'd rather run software in lower privileged places. Especially
> >>>> something like xenconsoled which is receiving data from the domUs.
> >>>
> >>> Yes, I agree with Jason. It is a bad idea to run xenconsoled in the
> >>> Control Domain because the Control Domain is meant to be safe from
> >>> interference. We want to keep the number of potential vehicles for
> >>> interference down to a minimum and shared memory between Control Domain
> >>> and DomUs is certainly a vehicle for interference.
> >>
> >> As much as it is when xenconsoled runs in the hardware domain? Especially
> >> if the hardware domain is also running e.g. PV backends or qemu instances?
> > 
> > It looks like you are thinking of the possible
> > interference from the Hardware Domain to the Control Domain via
> > xenconsoled, correct?
> 
> More like interference with the system as a whole, which simply includes
> Control.
> 
> > If that is the case, good thinking. I can see that you have really
> > understood the essence of the problem we are trying to solve.
> > 
> > That is not an issue because the Control Domain shouldn't use PV
> > console. Instead, it should use the console hypercall, or the
> > PL011/NS16550 emulators in Xen.
> 
> Well. I think the underlying concept of Control Domain being highly
> privileged needs more general discussion. As indicated elsewhere, I
> didn't think disaggregation (whichever way done) would leave any
> domain with effectively full privilege. I wonder what others think.

Keep in mind that the threat model here is different from the
datacenter. 

But the Control Domain is optional. If the user doesn't want it, the
user can avoid it.

Even on a fully static system (no VM creation), it is convenient to have
a domain that can monitor the others and trigger domain reset (we are
reimplementing domain reboot to be more like a soft reset so that the VM
doesn't need to be destroyed and recreated). As an example, the Control
Domain could be used to monitor a non-safe domain such as Android,
detect an Android crash, and trigger an Android reboot.


From xen-devel-bounces@lists.xenproject.org Thu Jun 19 00:45:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 00:45:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019566.1396188 (Exim 4.92)
	(envelope-from )
	id 1uS3P3-0006YG-Mm; Thu, 19 Jun 2025 00:45:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019566.1396188; Thu, 19 Jun 2025 00: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 1uS3P3-0006Y9-K8; Thu, 19 Jun 2025 00:45:17 +0000
Received: by outflank-mailman (input) for mailman id 1019566;
 Thu, 19 Jun 2025 00:45: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 1uS3P2-0006Xf-Og
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 00:45:16 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a7507df2-4ca6-11f0-b894-0df219b8e170;
 Thu, 19 Jun 2025 02:45:11 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 06DB244CCA;
 Thu, 19 Jun 2025 00:45:10 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8C917C4CEEE;
 Thu, 19 Jun 2025 00:45:08 +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: a7507df2-4ca6-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750293909;
	bh=bf2XpZueSRCQ676UHYn21zyJoUeLPt3QVHoeLjWP5pI=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=mU5NRDZhHaCjjyZfSMFqknhrTpk8nnTee1+NHXYJioUjbmwU8GbZ/S2bokNkuIF84
	 dLZfxiWxYQ69mn9QQ5cLaUkHiHD6ORQv9tkauycv8QXyTwhzOMMP3zV1nLYfS3EGN+
	 ya6ysPxki7mqCVBtpSiMrd7/5BRZW4CkmgBMH688Yw3BNCneu6BNaS8vM0J6e095oK
	 XIIDOvqTxKNsja0Id0pmNiRmzl2voAMqZROzeRUijJwR+yPW//xmf3dfhsmjzcZwLX
	 I2/C9tdq4jTKIgZ0lsg7NSFkuPqPZRDSmEg85QTbbRsWFT2ZZJFP6ZsCz6NsWTw9B9
	 5sUNhUOBpumpg==
Date: Wed, 18 Jun 2025 17:45:07 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Stefano Stabellini , dmkhn@proton.me, 
    andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org, 
    michal.orzel@amd.com, roger.pau@citrix.com, dmukhin@ford.com, 
    xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 2/2] xen/console: unify printout behavior for UART
 emulators
In-Reply-To: <2f726960-4bdc-4996-b204-722c0253e2ab@suse.com>
Message-ID: 
References: <20250606201102.2414022-1-dmukhin@ford.com> <20250606201102.2414022-3-dmukhin@ford.com>   
    <2f726960-4bdc-4996-b204-722c0253e2ab@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 18 Jun 2025, Jan Beulich wrote:
> On 18.06.2025 02:39, Stefano Stabellini wrote:
> > On Thu, 12 Jun 2025, Jan Beulich wrote:
> >> On 11.06.2025 21:07, Stefano Stabellini wrote:
> >>> On Wed, 11 Jun 2025, Jan Beulich wrote:
> >>>> On 11.06.2025 02:07, dmkhn@proton.me wrote:
> >>>>> On Tue, Jun 10, 2025 at 10:21:40AM +0200, Jan Beulich wrote:
> >>>>>> On 06.06.2025 22:11, dmkhn@proton.me wrote:
> >>>>>>> From: Denis Mukhin 
> >>>>>>>
> >>>>>>> If virtual UART from domain X prints on the physical console, the behavior is
> >>>>>>> updated to (see [1]):
> >>>>>>> - console focus in domain X: do not prefix messages;
> >>>>>>> - no console focus in domain X: prefix all messages with "(dX)".
> >>>>>>
> >>>>>> While, as indicated (much) earlier, I can see why omitting the prefix
> >>>>>> may make sense for the domain having input focus, ...
> >>>>>>
> >>>>>>> --- a/xen/drivers/char/console.c
> >>>>>>> +++ b/xen/drivers/char/console.c
> >>>>>>> @@ -740,7 +740,17 @@ 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 */
> >>>>>>> +            char prefix[16] = "";
> >>>>>>> +            struct domain *consd;
> >>>>>>> +
> >>>>>>> +            consd = console_get_domain();
> >>>>>>> +            if ( consd != cd )
> >>>>>>> +                snprintf(prefix, sizeof(prefix), "(d%d) ", cd->domain_id);
> >>>>>>> +            console_put_domain(consd);
> >>>>>>> +
> >>>>>>>              nrspin_lock_irq(&console_lock);
> >>>>>>> +            if ( prefix[0] != '\0' )
> >>>>>>> +                console_send(prefix, strlen(prefix), flags);
> >>>>>>>              console_send(kbuf, kcount, flags);
> >>>>>>>              nrspin_unlock_irq(&console_lock);
> >>>>>>>          }
> >>>>>>
> >>>>>> ... this, aiui, is a behavioral change for the non-dom0less case, where
> >>>>>> Dom0 output will suddenly also gain the prefix. Which I don't think is
> >>>>>> wanted: Switching focus between Xen and Dom0 should remain unaffected
> >>>>>> in this regard.
> >>>>>
> >>>>> This change ensures that dom0 traces aren't mixed with domU traces when domU
> >>>>> has input focus, or with Xen traces when the administrator is in the diagnostic
> >>>>> console.
> >>>>
> >>>> That's what the description also tries to describe, yet I still regard it as
> >>>> a behavioral regression in (at least) the described scenario. The hardware
> >>>> domain presently not having (d0) prefixed to its output is deliberate imo,
> >>>> not accidental.
> >>>
> >>> If we only consider the classic dom0 and dom0less usage models, then
> >>> what you wrote makes perfect sense. In the classic dom0 case, it is best
> >>> for dom0 to have no prefix, which is the current behavior.
> >>>
> >>> However, things become more complex with dom0less. As we have discussed
> >>> previously, it has already become desirable on both ARM and x86 to align
> >>> on the same behavior. During our last discussion, the preference was to
> >>> add a '(d0)' prefix to clearly differentiate output from dom0 and other
> >>> domains.
> >>>
> >>> Up to now, we could easily detect the two different cases depending on
> >>> the boot configuration. The problem arises with Denis' patches, which
> >>> add the ability for dynamically created guests via `xl` to access an
> >>> emulated NS16550 UART that prints to the console. Because these guests
> >>> are created dynamically, it is not clear how we are going to handle
> >>> this case.
> >>
> >> Why would this be not clear? We already prefix their output with "(d)"
> >> when going the traditional way. The same would then apply to output
> >> coming through the emulated UART.
> >>
> >>> If we follow the dom0less preference, then we would need a '(d0)' prefix
> >>> for dom0. If we follow the classic dom0 model, then dom0 would remain
> >>> without a prefix, and the new domUs would have a prefix. This would
> >>> cause an inconsistency. However, this is what we have today on ARM with
> >>> dom0less.
> >>>
> >>> If Jan feels strongly that we should retain no prefix for the classic
> >>> dom0 case, which is understandable, then I believe the best course of
> >>> action would be to change our stance on dom0less on both ARM and x86 and
> >>> also use no prefix for dom0 in the dom0less case (which is the current
> >>> state on ARM).
> >>
> >> Leaving aside that "dom0 in the dom0less" ought to really be not-a-thing,
> >> I disagree. Present behavior of not prefixing the domain's output which
> >> has input focus continues to make sense. That requires Dom0 to have a
> >> prefix whenever it doesn't have input focus.
> > 
> > If I understood correctly I like your proposal. Let me rephrase it to
> > make sure we are aligned. You are suggesting that:
> > 
> > - domains without input focus will print with a (d) prefix
> > - the domain with input focus will print without a (d) prefix
> > - this applies to both DomUs and Dom0
> 
> Except in the non-dom0less case, at least up and until there's at least
> one other domain. I.e. I'd like to keep Dom0 boot output as it is today,
> regardless of the presence of e.g. "conswitch=".

In the non-dom0less case, since dom0 has focus, it would naturally be
without (d) prefix. Unless the user passes "conswitch=". Honestly, I
wouldn't special-case conswitch= that way and would prefer keep things
simple and consistent without corner cases. I don't think conswitch= is
so widely used that it is worth the complexity to special-case it.

I am not going to insist though.

 
> > - this applies to both predefined domains and also dynamic domains
> > 
> > I am OK with that. I believe this is not the current behavior on ARM but
> > I can appreciate the simple consistency of it.
> 


From xen-devel-bounces@lists.xenproject.org Thu Jun 19 02:30:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 02:30:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019599.1396211 (Exim 4.92)
	(envelope-from )
	id 1uS52C-00022U-3A; Thu, 19 Jun 2025 02:29:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019599.1396211; Thu, 19 Jun 2025 02:29: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 1uS52B-00022L-Uc; Thu, 19 Jun 2025 02:29:47 +0000
Received: by outflank-mailman (input) for mailman id 1019599;
 Thu, 19 Jun 2025 02:29: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 1uS52A-000229-1T
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 02:29:46 +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 40e9b4b2-4cb5-11f0-b894-0df219b8e170;
 Thu, 19 Jun 2025 04:29:42 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by PH7PR12MB6000.namprd12.prod.outlook.com (2603:10b6:510:1dc::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.28; Thu, 19 Jun
 2025 02:29: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.8835.027; Thu, 19 Jun 2025
 02:29: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: 40e9b4b2-4cb5-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ceTww7p5PN/pWFX5c2/q4kkoSJsCPUudYfjAe4qcoQxkkKk6b6lgPsZzXr7t8ulmZaPZ2U8WK0ESf/l1m+DirA0fuX6tkyJVojOwMwZH7v7vsvEH9EBI66vjshT0rf9yOSTRnlc00DFwc6pRYhMAD0u4Ep1NruUEL/ZA8nOCENA6sh3Mladd+y3WV+9PNS7QpxeUjVrJ0QHO/6GtTK6gHEGXu5YPLKoxJm0OaP73kU8VkityKsTxPBzS2oTtAZ1FYV4tf/AfjHMtPKGwSKd3BpQyYyS0FoAvJUwqTZueNGyE9XZ1ZCXxbwS+tQDrTaAJm2L16SNFaAswxCcLHNvX8A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=BlK9si+JYJ+M2ry0Oz6tLH4rxAx2vknZg8hY8BAJrTk=;
 b=JCJ9hs3sFyRY4SrgxESFAxElyUvJT0sdf9wTGAERmDnqN0FJLzp1f9mCSmLKAM0f+D19O2bc/BV07d7KiovrAzH61XkQpGgu6eqRNkD3uJZg51a1clpGWaXUd8pLwO4Cs39O8Jfr2nIsHtWmjPlnSGp7KMEpcfx24RVgukMigIMU/5VJMgzLZsjRe4fcco3EJRbfQSCAyaEdqWt505Ss8diNimDoch6E80eACcUGMmCvpjebo6HWvQ1Lhh/BJuERwTrr64tAAiMUZZh++NtOb2CT/OA18d5411k+skgBVRRTksgtJAv+GHqygYQX2lx9z4+h6b6dsOjrA/aEBHgX9Q==
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=BlK9si+JYJ+M2ry0Oz6tLH4rxAx2vknZg8hY8BAJrTk=;
 b=qEtcavQpqL0GkaJblKTbGZgfj3mKrxNDo53uVDCuwC1ljHkrPWAmMVIVWwZbnreaexfBP7x++bAO/TbnzScCeJQFTR9y1kQ098L5RAHtpVicdFHKfPiGB7MUCaNhzwuJliKRKvAFuQ+B+IJNV4ShsCuthADi8Io6Vpgr463nCUI=
From: "Chen, Jiqian" 
To: Jan Beulich , =?iso-8859-1?Q?Roger_Pau_Monn=E9?=
	
CC: "Huang, Ray" , "xen-devel@lists.xenproject.org"
	, "Chen, Jiqian" 
Subject: Re: [PATCH v6 1/8] vpci/header: Emulate extended capability list for
 dom0
Thread-Topic: [PATCH v6 1/8] vpci/header: Emulate extended capability list for
 dom0
Thread-Index: AQHb23yZHYwoBN0glE68BnOedByoqrQI+ZKAgAFXGYA=
Date: Thu, 19 Jun 2025 02:29:34 +0000
Message-ID:
 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-2-Jiqian.Chen@amd.com>
 <669877f5-ef34-4552-9cfc-e097d40d444a@suse.com>
In-Reply-To: <669877f5-ef34-4552-9cfc-e097d40d444a@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.8835.025)
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_|PH7PR12MB6000:EE_
x-ms-office365-filtering-correlation-id: 7adf9ba1-2bb8-4556-7990-08ddaed9215b
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?WzK8DGxgjBWtZHIukUttJx5EucWR/F0tWpp9x3s+zKwUX1GchjF2kGzLFf?=
 =?iso-8859-1?Q?+VwbQuzPS5dShCfo2UQKWCliO1BSp/wTskAI84mRxbFU8fnVnEqBr1ZMeU?=
 =?iso-8859-1?Q?Y6kwz+okgMfQRni2J+Z8Gp1Lh6mBqh6elPloXuDqRuQ0XTnDqncmiVfO+F?=
 =?iso-8859-1?Q?3qk7gQXl0K9a8mSxjTVLRYYaxqedj/47xW0ODBCJDd7vNNv+jwU//ySNJP?=
 =?iso-8859-1?Q?OoSM/rcQnBziapexYonmYA1tknQB6cdbpqbDQdbar7foIXViR3q6EZUvmv?=
 =?iso-8859-1?Q?2UpCKNncwI/ADYcu/04bliwS8M5kTWgyfLJFk+B2oK9LNSdFSfYaIH68NE?=
 =?iso-8859-1?Q?lqFJyYvyf+xpGmtSbwErgyWUVzl9dXFXeNrgQMqYVe5wTdLYPIpNRVB4LK?=
 =?iso-8859-1?Q?e0JoomH3R0xD7jBlIMooTkL6tFvyUfASPjOg4snxgi8HzrPZhMvWZ0L/b0?=
 =?iso-8859-1?Q?on8TWuCR6A6CnS5WdrJSsLN9o3uUNpvxJ8TamV/uRfmQ23+nPEdOP5M310?=
 =?iso-8859-1?Q?LCnUxweSnf/o7m7LhhlN9w86MCscu5Ce2kpkg/QFYWxpE0Du88y5Mi+Kpw?=
 =?iso-8859-1?Q?o2ApmL14+mTIjgPXEljc1ILhh/EpgDboZDn4Ad274BdAx8KkFZdtXbqfHI?=
 =?iso-8859-1?Q?Phn2Zm9NY6wJnZLIu1r1LtcLVr4NQmMRAdN8llNZgc26DdoLA+Y3FqeRRa?=
 =?iso-8859-1?Q?QqFdlwDoThvtvl0mGvpEe7KHQkhIoeheMdLsFED/iJodHqt+GRGsB4Ycu1?=
 =?iso-8859-1?Q?DFSoyXAuC2ynoY0ciSybkrfkNYXwGf5KpLIC0kCAimgUCqun8cKHiIDrtn?=
 =?iso-8859-1?Q?iBTbJblubazzVmZXTt762iZOSSqiMgF3N3YB3BCU5VphOQb3XTqlbi9Hus?=
 =?iso-8859-1?Q?BGW60jnBbEbaUhZICXbjYlgpfZt51EpOtdGswimA2DiJjUMwK5Y8OMMKcl?=
 =?iso-8859-1?Q?ARjWPPTrBwj2vKr+WpwHX2UD5y8tilIU0o5+ORRT+SB6NZwAThuG5yW2GI?=
 =?iso-8859-1?Q?HWNKl4FGZb5kpZjh6y2S/qAvSRiucdBicrIX+fVwa7oVyksBEvFAm2q0LZ?=
 =?iso-8859-1?Q?oM+W5a4UfIWNpZfdVbzjRlXO2HZDL6HlP19pS/NHqTgqb4IFydgVLCxA4J?=
 =?iso-8859-1?Q?mHc5QZU2rF8GjHgmAcwGG//BwU0j+xRCVDfOy9/+dOnanhk4Ju6V2WdWCO?=
 =?iso-8859-1?Q?uD3bgPtXZ7WMXmWHZRfpgakcGwedIXkCoA4GMmjbCF9RTlW8MqZ9TcFTGi?=
 =?iso-8859-1?Q?/NEB+d292cYDcMA2sICmPLMO44LbtWB3iQXDC2XYiheV949mtfFEOvDqWN?=
 =?iso-8859-1?Q?QbNuWkpf3w2gegX+g65S04kXMsztESOEhwBLq7GZYGmKSDhTVjSMHJ7Qvy?=
 =?iso-8859-1?Q?0RW1Q+olRnXKqDEB3vEW9Wv93xCt1K6DsBFXGfOBzsvw4UgDmGP35qZzeQ?=
 =?iso-8859-1?Q?htg6IHjzs5p9ExLiQuTBiIN118PLB/4aLP+uhKVMFUR2zXJ+gfpuSWJ6kS?=
 =?iso-8859-1?Q?avPVIeh2YLeljDwDot3nrszUeNEIq1+xX4t/GbzZ4eAw=3D=3D?=
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:
 =?iso-8859-1?Q?dukik8L3A4RNGHioRlUUTw8ifyUYEIJFq7OQdMp0lKnX0ivY7ZglG808z0?=
 =?iso-8859-1?Q?R0rn5BN5Bdq9GRKxRem1Ul5MZ4bFbI2cX9jAWQYUkM3qilLVg5uApbshpB?=
 =?iso-8859-1?Q?zUwl/vPQ+xmqy5WzA9IXP15ozc2BBZXrVxAg7rOlK/K0vpu5G9oW8+tPtL?=
 =?iso-8859-1?Q?FihdMlBJRhWjW62Uv1qyErvqGp49oqrQUUvm5Ajep68osbuoZpQaeOg9OA?=
 =?iso-8859-1?Q?UlvAWsYxlEFP7bVe0PRNufLg8VyIw6gk0vwBS9RhLOrHODIDIRtg6X2psq?=
 =?iso-8859-1?Q?Wk186MeY7VKMHHh/G+glZLCCMF0KY2kk8ft+Wipwp1zxfTmPw7JggQ2+JG?=
 =?iso-8859-1?Q?F3SIEtvUqZE87mfsW00xfuld48J5+LXYKeDV1Olj9APCuYQ2kX4Yj8hkGU?=
 =?iso-8859-1?Q?jqCDC7ouwpnLpV4xE3vlw7glg/pd3CLkIvNV7D3YseZALlmm+ZHFVtunmp?=
 =?iso-8859-1?Q?cGGygjFOGqHcwg2V7Hf+LakywiI2zNDwlTYJav+8orMzkYWD7fY9uDctxi?=
 =?iso-8859-1?Q?xZLOzj3cNHqdvehzz5ia5WFUtI86CNBs3viH3YCM1boPtYabPJJBZHEFhH?=
 =?iso-8859-1?Q?XXqk+f2kOEc5hViQ9bZgC3f73S/vPqOxudxV5+jeH2MG+Oo/JIwUpp7X9/?=
 =?iso-8859-1?Q?Ef+gaQcEjC5M50OWP9FMrl6czAVjQOYx6Og4fgX4GCa71Dkdu/NBsdxnOc?=
 =?iso-8859-1?Q?6cuyB/s6uZC0QziPlH6OF/JHxGB3uGru9XPuXmD+cu4dgD+VHYwM8pBgjE?=
 =?iso-8859-1?Q?3NiYWTA1uw1bUi0/mTcVuZHa71n1mSJBdLDF+IwAgfJf5obQXG6Xi3k9Gg?=
 =?iso-8859-1?Q?NVHU/cyXXVJN9XGsF/0OmfJStS/UUGLGQbeVlEfVwKQHbAzePqihP9DyHM?=
 =?iso-8859-1?Q?06ZcxyEqQGc1qZwLatJ8YbgT3dVCQ/mq9XP74wqgZy5+KZkiw8EDNGzyWP?=
 =?iso-8859-1?Q?v2LO+0BMR5j1wBdoOc7rWlWnIh7B1tdYBhXyiGC2rbSyTjR6TeF02WcHWW?=
 =?iso-8859-1?Q?5HcmnPbhQHgd/mWct4oGB0oVNrzjEXlBV6EmCGBHzsVVpeaaSMKPKtKMKg?=
 =?iso-8859-1?Q?pR5QMUM8mMnLmEnbwhRaThQqByibqQTGrRve/bkkHtH1hZwAVZgrmK2JRP?=
 =?iso-8859-1?Q?39EPP8cORFFAJcWif8oup0bPsAVtkjoczQLON6VHUQXN98AWqsFxbrdVlr?=
 =?iso-8859-1?Q?Qlq2C+LSAH7Xi1kFfBZ7YltFWa4raQjYFONl9fOpkVl9lSvY80YKOOkWBG?=
 =?iso-8859-1?Q?uvN4vHYGwlfW2ZQUj7usR0w9GHNuZQkUoT3/xISWdSnFDqe4LNLc4IPzj2?=
 =?iso-8859-1?Q?qm5H6jpNo3HdM1LXLog9w7eK+WdqPikAncAJx6n1xmOLvMkxOqnacvAdWM?=
 =?iso-8859-1?Q?8IMrw8/VUTghKw9Df/m5DVNny9Qd87g9Y/t4tzAVer7pHYzmJLf22h1wq7?=
 =?iso-8859-1?Q?7WAIXLqRv/1++L9bwC/fJcKpHmzrYE8SCY9oLCO8DFS8Yk5VWYAES7WOdQ?=
 =?iso-8859-1?Q?Rf+vKxcIkvJPXy3vaFTjiqWVdM9uwXtqUkDieBctQdtymuMi6nG8ElgjrO?=
 =?iso-8859-1?Q?/nHkUrjXUSlEnbJBVKEVExqXqnZRUvjC5V1TuCnhNAT2BwfQVnkz5buwwn?=
 =?iso-8859-1?Q?LKq1fAvL7IW2A=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <450DF7159EDC2448A4C853CC9B65BC21@amdcloud.onmicrosoft.com>
Content-Transfer-Encoding: quoted-printable
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: 7adf9ba1-2bb8-4556-7990-08ddaed9215b
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2025 02:29:34.6779
 (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: 9S4qA4VIpnmXjWl+fvUzhoZecrS0Q3em4xNqRq63goq2eo0pN3CeiZWfc6sj0p+/dSAi/dROR8zOv3mu59eoTg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6000

On 2025/6/18 21:52, Jan Beulich wrote:
> On 12.06.2025 11:29, Jiqian Chen wrote:
>> --- a/xen/drivers/vpci/header.c
>> +++ b/xen/drivers/vpci/header.c
>> @@ -836,6 +836,42 @@ static int vpci_init_capability_list(struct pci_dev=
 *pdev)
>>                                    PCI_STATUS_RSVDZ_MASK);
>>  }
>> =20
>> +static int vpci_init_ext_capability_list(struct pci_dev *pdev)
>> +{
>> +    unsigned int pos =3D PCI_CFG_SPACE_SIZE;
>> +
>> +    if ( !is_hardware_domain(pdev->domain) )
>> +        /* Extended capabilities read as zero, write ignore for guest *=
/
>=20
> s/guest/DomU/ ?
Will do.

>=20
>> +        return vpci_add_register(pdev->vpci, vpci_read_val, NULL,
>> +                                 pos, 4, (void *)0);
>> +
>> +    while ( pos >=3D PCI_CFG_SPACE_SIZE )
>> +    {
>> +        uint32_t header =3D pci_conf_read32(pdev->sbdf, pos);
>> +        int rc;
>> +
>> +        if ( !header )
>> +            return 0;
>=20
> Is this a valid check to make for anything other than the first read? And=
 even
> if valid for the first one, shouldn't that also go through ...
>=20
>> +        rc =3D vpci_add_register(pdev->vpci, vpci_read_val, vpci_hw_wri=
te32,
>> +                               pos, 4, (void *)(uintptr_t)header);
>=20
> ... here?
If header of first is zero. There is no need to add a register I think, sin=
ce the dom0 can read/write directly.

>=20
>> +        if ( rc =3D=3D -EEXIST )
>> +        {
>> +            printk(XENLOG_WARNING
>> +                   "%pd %pp: overlap in extended cap list, offset %#x\n=
",
>> +                   pdev->domain, &pdev->sbdf, pos);
>> +            return 0;
>> +        }
>> +
>> +        if ( rc )
>> +            return rc;
>> +
>> +        pos =3D PCI_EXT_CAP_NEXT(header);
>> +    }
>=20
> As a more general remark - this is imo the kind of situation where using
> do ... while() would be better.
>=20
>> --- a/xen/drivers/vpci/vpci.c
>> +++ b/xen/drivers/vpci/vpci.c
>> @@ -267,6 +267,12 @@ void cf_check vpci_hw_write16(
>>      pci_conf_write16(pdev->sbdf, reg, val);
>>  }
>> =20
>> +void cf_check vpci_hw_write32(
>> +    const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *d=
ata)
>> +{
>> +    pci_conf_write32(pdev->sbdf, reg, val);
>> +}
>=20
> Iirc we've been there before, yet I continue to wonder whether we're doin=
g
> ourselves any good in allowing writes to something that certainly better
> wouldn't change. Even if we limit this to Dom0.
I remember this was suggested by Roger in V2, since the Dom0 has no limitat=
ions to write the extended register.

>=20
> Jan

--=20
Best regards,
Jiqian Chen.


From xen-devel-bounces@lists.xenproject.org Thu Jun 19 06:15:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 06:15:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019690.1396221 (Exim 4.92)
	(envelope-from )
	id 1uS8Xw-0004Fq-2j; Thu, 19 Jun 2025 06:14:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019690.1396221; Thu, 19 Jun 2025 06:14:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uS8Xv-0004Fj-V9; Thu, 19 Jun 2025 06:14:47 +0000
Received: by outflank-mailman (input) for mailman id 1019690;
 Thu, 19 Jun 2025 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 1uS8Xu-0004FW-NI
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 06:14:46 +0000
Received: from NAM04-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam04on2061f.outbound.protection.outlook.com
 [2a01:111:f403:240a::61f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b09f8d9c-4cd4-11f0-b894-0df219b8e170;
 Thu, 19 Jun 2025 08:14:43 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by CY8PR12MB7436.namprd12.prod.outlook.com (2603:10b6:930:50::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Thu, 19 Jun
 2025 06:14:38 +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.8835.027; Thu, 19 Jun 2025
 06:14: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: b09f8d9c-4cd4-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=mihsqB1vWk+3wZE44ya0EpSyCUSMgevBhg9CluASWPg8YrRp4ZhUT79Hz1Oyql3jAQJ46rwxzORFaj8l7eEb3co42hCN+8jJl7bcW3tA5S6L1Au+0jxX4vetL1dqKTg9jCiOOngD8DNsj2L2bunRpAkw/HCWCauEFbVy6y5iRX8GzQw4ZEwyH6zj6zEQi5N768WK9ZuQipdJqHG1lsAVdxIMioS6rWfXYo6JqEPci7ZpuEdktPxuIJCEM4KQCWDv5poe2uSObMy3euANuwRXhbBF4JfBXsSpUcyrkMXzgpR4k30qc/DNpxVdaJk/9qHOc1QxGBC2iA/3QZm4r4mSxQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=o2r8Na2cNk1ynXA/naaI2cd0FLTjugwUwwl2Dhl4eFI=;
 b=gdPYGzvti1vMg5vp85GxrRx19sJKMtNQtQQHGC3waiXKPka80GdiSFa2s+uMoYSXNFJFNjqhnFR9u9GF/NkPeLIPvMJ1GApBmAyRwFDlXVmfaua/UdxDhLtIog40lQqfsQz110EbfrS/lIJXMFszqQCEll/7gGmIRWMY5TchtlMjtJqnOMgbePq25FqzwkFlIYIgEbpJ2aU5qLgWM5auqK06kQIjvl/EYt+MrGGtqYtMvulalMXReAp9FOh9jPYMVd2lOfdxv7CcZtsUSiAGATkeWyxVuQYOIomqCtqExc+EP5X0iRXGDISXS381Dai45RW49TWZ+SlAVQ7VzRPC+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=o2r8Na2cNk1ynXA/naaI2cd0FLTjugwUwwl2Dhl4eFI=;
 b=XGGM3DCz0cKZtDG0JLYY+rtgqWfVcfXChAWwiphGpNxjqbWRtX4PWs5f2lExquqEOqz24hVLOS923TqDbxA5w755ToxrN+TBWl6ohxaHsFf+XWdkfJFDNyvUc1KX2ByKlZkQM9LflSvu80DPxNKlkHxiRuMJ03lqQdsn0GnSexI=
From: "Chen, Jiqian" 
To: Jan Beulich 
CC: "Huang, Ray" , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Andrew Cooper , Anthony
 PERARD , "Orzel, Michal" ,
	Julien Grall , Stefano Stabellini ,
	"xen-devel@lists.xenproject.org" , "Chen,
 Jiqian" 
Subject: Re: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
Thread-Topic: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
Thread-Index: AQHb23yakGdVC9XxvEWnYcnp8zrTt7QJBRKAgAGLVIA=
Date: Thu, 19 Jun 2025 06:14:38 +0000
Message-ID:
 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-3-Jiqian.Chen@amd.com>
 <1634c18d-e54e-4105-8b30-6f3085bace22@suse.com>
In-Reply-To: <1634c18d-e54e-4105-8b30-6f3085bace22@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.8835.025)
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_|CY8PR12MB7436:EE_
x-ms-office365-filtering-correlation-id: a76c9afe-68f2-4fee-8156-08ddaef8922c
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?RzZhcGVISE1jQUFLQkhnNy9USmlTYjd6NFZsN2lxdk9VM1lNdVd2aFFIWmhu?=
 =?utf-8?B?enhtZmtyVHI0blVEbU5tQ2l0MzN0SHdSRHc2cGxJdnUxRzRjUjloRU8vYUlC?=
 =?utf-8?B?dE92eTBOektYOUlpMGJOYk5BZmg0UUZzUHRoUGdPZUE1b1F2TktiWmZTMks5?=
 =?utf-8?B?eGdZaUNKZGVnZktSWTMxcHFWNzlCYkc3dHpJV0JueTFiTGdZMXlITFNvSXE2?=
 =?utf-8?B?QXkwcGt5SUZEbFpIWjhibGdocjZ4M1RiT21TUFJQZDUrZ0hYdjdQMFpRL2FM?=
 =?utf-8?B?Szh2UFlPR1FpUkVnL3BsMGRCUFQveFI5clFqdENDZEJzKzkyYWMrVVJjVFFJ?=
 =?utf-8?B?TmdXQ1Q0RFR5RlNaT1F0bWlUbklFUU91NzU4RkR1M3Mva1o2WEZ6VDYvYVpa?=
 =?utf-8?B?TjNNYzVaam9FcDdlblFNdWcwblpPV0Y2eGUwTm9vWEdEb1A1bFlSaVp1alVs?=
 =?utf-8?B?UGZwVjJiRVh4VUJNYmtkYXhmbzZwUUlBNmR4VmhWK2RCZHRyTi9zaFBpcHJV?=
 =?utf-8?B?WFZLcU1hVjdmT3VOME5ZcTZKMlNqclRtRTIwMzh5dlhTYmcrWG03aVRhUk0y?=
 =?utf-8?B?WVRpVVFqY2xMME5VR21ZWmo4elIrSGpkT0dWWE1IZTJnUlFaWk8xRzhpYTla?=
 =?utf-8?B?SHJ3R2hBTXNtN2Zya3FtUS9lMSt6clBObDFza3NCdmhQTHZSNWl3RTllOER5?=
 =?utf-8?B?MjExMThTZzh3VUI2dythQ3ZFSDFkYm5oTnlWSjUwQnNER0xHUVpONnh3eTdE?=
 =?utf-8?B?K2JNSDRmSXROUmVTbUNtR25rcUxEK0JkQitUeVFFVkh6RVcxWkZCKytRSG8x?=
 =?utf-8?B?eHhsNGhiV2VoT3JRdm5YNk4rVkdHT2UxUFdYcDdlbkV3Um1oK3V0VVRZSWd5?=
 =?utf-8?B?QU5oYUpNM3RvdHkyRnRnK0xpRW11T1pqQkVYMDNQNWFoZURjWS9wQzBGYnhh?=
 =?utf-8?B?dmwxSmZBV25vSlYwWjRSVjlhaU1HTTI1bFBoeWVlZTdjM1JzTDN5YldGUklY?=
 =?utf-8?B?Q29nSWZVMTd1ZzBIem5zTVNXYkJLUmwvU2FtZ3JXN0Ficit2aGJWUWhZaTcv?=
 =?utf-8?B?azNZODNNcy9HZVhTNVBTVnJJWFhhejQ0VWxmb2tPSnYwanVIZmhSRWNpeW10?=
 =?utf-8?B?clc3NlJtREluV05WR3U5Yk9OM0xEWmt0bGJRY3RGeVFVYnZVRGh5bXpXVTkz?=
 =?utf-8?B?YkRYSGJEYVhDS0xZWUhBRGoyRVFvVC9FWGxEWTFSbVdHRktkUXJuRkwxOWdo?=
 =?utf-8?B?STZLV3dXdHlnK2pWdjJJRUNVK2pvMFNtVlhxRFlkaTQ4bTJId1AwalJhZHZ6?=
 =?utf-8?B?VmNyVUJNbmcra1ZxcTNucWd2T0M1eTJEaGd4NjdDUjcwN3Z1YkcrdG1ZU0x0?=
 =?utf-8?B?RnpPNGFsZnhKMVVWTEFlUmdLVUJBRE4xR1ZTU3JkSlZXMEhvQmZPTGlXUTky?=
 =?utf-8?B?TVNOSXA2Zytqc1JORnl4NWhjVWhKbjdwUmVOQUVvVzJOOFJvZk1hVDduN0lr?=
 =?utf-8?B?OVM1VFk0Zm44dHNOZURvWDlYRGM5cjhMeElXcDR0eFVTWW5mUmtTcEVkTlJZ?=
 =?utf-8?B?MnFzZDEvcWIyVDY0MFFjdC81RjN4cndXeEg4Mm8zY3MxVkxhTUlwVDFBVmlh?=
 =?utf-8?B?ajBDOWFPQmVUTVpKa3lBdWtxeFAxRW9zWFUzd1IxRjdKV2xDT3hmVDZoWlVr?=
 =?utf-8?B?bnhoQzB2R25xOHJyclhNZHhEVWNaUUdScXR2djZCNlFyMU1NVmJtbndMTFdi?=
 =?utf-8?B?MEdQcXJLSHhpQmd2OXQzZm13eXdoQ0xEYi9Gakt2T2FUUEQ2R1l4NE83N2dH?=
 =?utf-8?B?WUYvWEVkL1RGM1plekZvWkJLQnRzU3ZZS2oxUTFkSUpMa0NuOUl0RE1ReWE4?=
 =?utf-8?B?S2Z6eDV3UHYzWmdGRncrUFBaRFdrakNTWGxnVURXUXNnVUV2M045QTczVkVG?=
 =?utf-8?B?OGVWYUVRK1dLbXVQQlRxU3lEOUxJZ2FLOGVOTEI5QU1UaVRYeWs3TWVLUW1F?=
 =?utf-8?Q?TjUmaCDp6zEtXjsBaXm3JDYD39Jc3Q=3D?=
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?VHFsbE9xWENMczByamhJRzIyRStMR20xc1ZQL2JicFp0Y3o1d1dzb0JwSTlY?=
 =?utf-8?B?aDB2eXNJS1YrOGpTWkF3YjRzczRPS3VvZjBaN3BsRlF1QlpSb05IaUFhNDU5?=
 =?utf-8?B?YWZPZDRTNUNzN09Oazh3Z0hFSHp6WHBMMmNVZVRaM2ZJNWtLcFRIQUR6MWll?=
 =?utf-8?B?V0ZKbGUycDE3YUdTb1BlWGRGN2hCRTVxSjdJVVVrb01vRVZmN2k5UHNPVUtD?=
 =?utf-8?B?MXlmdkRiUTNpb21jL3g2UmJjV3hrNUcvQkE0YXBFS0RJbUNBSWd1UURQR3lF?=
 =?utf-8?B?WDk3T3VaSWkybVBDazJjVGNsVkp6TGx5cU1iZDVqYWhzcUQ1eU9ORlBHRUFy?=
 =?utf-8?B?U2ZTd3A0QkVidXZaQzFYKzdVNThHNjJ4YWZFWE5mYU5xSDE2WElPV0JVUXYx?=
 =?utf-8?B?dEVUNU9xdi82bThOWVR6RmZNY1Bvc3pVYmNHMGllSk1oV29BeEQvMnZ4NFln?=
 =?utf-8?B?L21KYThqOUM3Z3JmS1ZKbVU1ZVM4dVhaS1M4SzhlUnFKSVZBR0NRYm9EZFdE?=
 =?utf-8?B?MEVWZ2dGQk9WMmpjRnVDUFl2NGhhVWEvZ1dTM2ZMNGcwZm1jZGM3ODhYYlEx?=
 =?utf-8?B?RTI1ZW9uc3pKZ2NqWElNZnRYSTRobmRYTE9Bci91eHA1aGM5TDFuV2U3aU1j?=
 =?utf-8?B?V1FVK1N3SVhPa1diMXMzOVZNV3RHQ0tCdTFXRHpwZng1SFF2b3BlWmJDUWRW?=
 =?utf-8?B?VTRwSVl5U25oSE12TmlHWFo5R2g1cEJGT3hKZUVWTzJqcGQxYXAzRFlscklq?=
 =?utf-8?B?by9uWm02bXFwT0NJdmcyeTdFbUJxMGpGMnlCd0FtU0FlSFc5enR1emtwQUZ2?=
 =?utf-8?B?WlZxeWRGOUNJclBhaG0wSml5bXV3M1owaW5acys5UWt0ZW5RYkJpYnhISU5P?=
 =?utf-8?B?L1I4L1BmZEQyQlhkakVIcy9RUkF6OVRKbzUzK2hPd2Y5QXFLeEs3S3RWU3NU?=
 =?utf-8?B?M3ozd3hULytFcFVFd1pGaExLT2VldXdGdFJiYks2M2ZYVU5xUXNLdjlMOW5p?=
 =?utf-8?B?RjF2WDlrL2l6TXRCRWlNR1BHL0dhWFhWM3BXcW5iQ2VsUU9rMzQ2czRvaElU?=
 =?utf-8?B?bENWM2s1YVRxNGM5eE0xT0xmTEtNajdUYjVVWFMzMDdqbFNrZjkxcnd0Rnh6?=
 =?utf-8?B?TzA0YXBWcHJlQkQrTTAwa2EyRU1RSXhlRjFxbTloSFRKa2w4SlNNUFlra0Zj?=
 =?utf-8?B?UUVKQ3pxV0FxZnBqbnZxajZFY1krY3NyM0JpRlpyRGdHdE5MZE9QZkNqR1pB?=
 =?utf-8?B?dGVwaXlSYUNkSW4vL2dGdUVXeVI5b2RWS0w4Vk45N1RLNDE3ZUJhQ244Q1Jz?=
 =?utf-8?B?NjdEV0VWK29mVGdaenNnYnZ6VXpIMS95ODZLbzFHTWpTd0JJYW1MRWxkeUli?=
 =?utf-8?B?QWJYa0ZiVS9jc3RsS3UyN052VDM2U3o5b2lzT0NyTGZzNzVMWlpiOUpkaWNS?=
 =?utf-8?B?a3pHeDI3SERKMHFBeXdBNEFhc3ArOFRZejA1T3NHN25xZFJJZE5tWnFVZk04?=
 =?utf-8?B?RnZjL0ZJQUVhR1VvbisxY2svNjRBdDljZXJxQTVEeWVMQ0pCNWNJSGJYU01u?=
 =?utf-8?B?SWZ6Uzg1cUd4WEZ4cHNxU0JwWmlHUWlFWUNFaCtvZ3h1UDU3eUZ2VWxtVDA4?=
 =?utf-8?B?eTFyaTJ4ZTVRNUVRenI0U0JqSm13bUVOaGZLZU9HckR6RVdtYTU4cy9IRVBu?=
 =?utf-8?B?ekZrV3ZOY1lXY0VxRzRZMVR4RUV4QUZ0TW1kdUR1aDVRVEJtRzA0UDZ3UEhm?=
 =?utf-8?B?djdTdE1JQVVTWkxpVGlhK0lTOG84VjNiY2taeWFEeUZYQjd0WXI2eVg3WDJO?=
 =?utf-8?B?b2hiTU5RV1Uzck9xdTJKQjhrYnBBVDk0OUZreUNkUlVHRWFwT20rUkkreXFk?=
 =?utf-8?B?VXVzelZSRlBMQWhwNkNDd2N6V3IxOE54UWwrL3EvNFBlWGxuV0EzcWl1dDZ3?=
 =?utf-8?B?QllaM3FRZmQ0eEszTXNpWDRMNGt2NEhib0pkSUx4Vit6cWxSWnRRa3BIR0JG?=
 =?utf-8?B?VzRzTjMyejQ5ZnJqcW1uaWtEQVhMcVNPQjBLNDJDMWJYYlUyZXRMeU1aNE1V?=
 =?utf-8?B?bjhmaVppZmM5Yk9aYXVxMFlqSDJqanBZQzdVa2d2RTBIbjZCVWhiVW95Skh2?=
 =?utf-8?Q?8kh0=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <5E3D7E281AE512488196C34436807B8C@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: a76c9afe-68f2-4fee-8156-08ddaef8922c
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2025 06:14:38.3416
 (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: Yo2OuGgYb3yl5qVfwddnzfBgT0VpKzFcMJoAUnVMONZ74B8uFt/c28A1a59nPOkVwU+Cs+8In55+umSN3ayXyQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7436

T24gMjAyNS82LzE4IDIyOjMzLCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMTIuMDYuMjAyNSAx
MToyOSwgSmlxaWFuIENoZW4gd3JvdGU6DQo+PiAtLS0gYS94ZW4vaW5jbHVkZS94ZW4vdnBjaS5o
DQo+PiArKysgYi94ZW4vaW5jbHVkZS94ZW4vdnBjaS5oDQo+PiBAQCAtMTMsMTEgKzEzLDEyIEBA
IHR5cGVkZWYgdWludDMyX3QgdnBjaV9yZWFkX3QoY29uc3Qgc3RydWN0IHBjaV9kZXYgKnBkZXYs
IHVuc2lnbmVkIGludCByZWcsDQo+PiAgdHlwZWRlZiB2b2lkIHZwY2lfd3JpdGVfdChjb25zdCBz
dHJ1Y3QgcGNpX2RldiAqcGRldiwgdW5zaWduZWQgaW50IHJlZywNCj4+ICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHVpbnQzMl90IHZhbCwgdm9pZCAqZGF0YSk7DQo+PiAgDQo+PiAtdHlwZWRl
ZiBpbnQgdnBjaV9yZWdpc3Rlcl9pbml0X3Qoc3RydWN0IHBjaV9kZXYgKmRldik7DQo+PiAtDQo+
PiAtI2RlZmluZSBWUENJX1BSSU9SSVRZX0hJR0ggICAgICAiMSINCj4+IC0jZGVmaW5lIFZQQ0lf
UFJJT1JJVFlfTUlERExFICAgICI1Ig0KPj4gLSNkZWZpbmUgVlBDSV9QUklPUklUWV9MT1cgICAg
ICAgIjkiDQo+PiArdHlwZWRlZiBzdHJ1Y3Qgew0KPj4gKyAgICB1bnNpZ25lZCBpbnQgaWQ7DQo+
PiArICAgIGJvb2wgaXNfZXh0Ow0KPj4gKyAgICBpbnQgKCppbml0KShzdHJ1Y3QgcGNpX2RldiAq
cGRldik7DQo+PiArICAgIGludCAoKmNsZWFudXApKHN0cnVjdCBwY2lfZGV2ICpwZGV2KTsNCj4g
DQo+IElzIGNvbnN0IHJlYWxseSBub3QgcG9zc2libGUgdG8gYWRkIHRvIGF0IGxlYXN0IG9uZSBv
ZiB0aGVzZSB0d28/DQpXaWxsIGNoYW5nZSB0byBiZSA6DQoNCnR5cGVkZWYgc3RydWN0IHsNCiAg
ICB1bnNpZ25lZCBpbnQgaWQ7DQogICAgYm9vbCBpc19leHQ7DQogICAgaW50ICgqIGNvbnN0IGlu
aXQpKHN0cnVjdCBwY2lfZGV2ICpwZGV2KTsNCiAgICBpbnQgKCogY29uc3QgY2xlYW51cCkoc3Ry
dWN0IHBjaV9kZXYgKnBkZXYpOw0KfSB2cGNpX2NhcGFiaWxpdHlfdDsNCg0KPiANCj4+ICt9IHZw
Y2lfY2FwYWJpbGl0eV90Ow0KPiANCj4gQXMgeW91IGhhdmUgaXQgaGVyZSwgLi4uDQo+IA0KPj4g
QEAgLTI5LDkgKzMwLDIyIEBAIHR5cGVkZWYgaW50IHZwY2lfcmVnaXN0ZXJfaW5pdF90KHN0cnVj
dCBwY2lfZGV2ICpkZXYpOw0KPj4gICAqLw0KPj4gICNkZWZpbmUgVlBDSV9NQVhfVklSVF9ERVYg
ICAgICAgKFBDSV9TTE9UKH4wKSArIDEpDQo+PiAgDQo+PiAtI2RlZmluZSBSRUdJU1RFUl9WUENJ
X0lOSVQoeCwgcCkgICAgICAgICAgICAgICAgXA0KPj4gLSAgc3RhdGljIHZwY2lfcmVnaXN0ZXJf
aW5pdF90ICpjb25zdCB4IyNfZW50cnkgIFwNCj4+IC0gICAgICAgICAgICAgICBfX3VzZWRfc2Vj
dGlvbigiLmRhdGEudnBjaS4iIHApID0gKHgpDQo+PiArI2RlZmluZSBSRUdJU1RFUl9WUENJX0NB
UEFCSUxJVFkoY2FwLCBmaW5pdCwgZmNsZWFuLCBleHQpIFwNCj4+ICsgICAgc3RhdGljIGNvbnN0
IHZwY2lfY2FwYWJpbGl0eV90IGZpbml0IyNfdCA9IHsgXA0KPiANCj4gLi4uIF90IHN1ZmZpeGVz
IGdlbmVyYWxseSBkZXNpZ25hdGUgdHlwZXMuIEkgZG9uJ3QgdGhpbmsgd2Ugc2hvdWxkIGFidXNl
DQo+IHRoYXQgc3VmZml4IGZvciBhbiBpZGVudGlmaWVyIG9mIGEgdmFyaWFibGUuDQpXaGF0IGRv
IHlvdSB0aGluayBJIHNob3VsZCBjaGFuZ2UgdG8/DQoNCj4gDQo+IEphbg0KDQotLSANCkJlc3Qg
cmVnYXJkcywNCkppcWlhbiBDaGVuLg0K


From xen-devel-bounces@lists.xenproject.org Thu Jun 19 06:40:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 06:40:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019710.1396230 (Exim 4.92)
	(envelope-from )
	id 1uS8wK-0007FX-Vs; Thu, 19 Jun 2025 06:40:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019710.1396230; Thu, 19 Jun 2025 06:40: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 1uS8wK-0007FQ-T4; Thu, 19 Jun 2025 06:40:00 +0000
Received: by outflank-mailman (input) for mailman id 1019710;
 Thu, 19 Jun 2025 06:39: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 1uS8wJ-0007FK-Ay
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 06:39:59 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20611.outbound.protection.outlook.com
 [2a01:111:f403:2009::611])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 366f21e7-4cd8-11f0-b894-0df219b8e170;
 Thu, 19 Jun 2025 08:39:57 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by CYXPR12MB9339.namprd12.prod.outlook.com (2603:10b6:930:d5::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.22; Thu, 19 Jun
 2025 06:39:53 +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.8835.027; Thu, 19 Jun 2025
 06:39: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: 366f21e7-4cd8-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=SjslNtHXAnNdn5RnbfBjRgQ/Zw0MgRrhgOsRMazmbdrXg20uH3Vnag9vQ1vBIrxRNZYiGVncHYrk2osIDt3DjdpDoEuhvE3Cy0mULHiG520CbrQurTYi3Lv5I45qL0o/fiaDEZqcx4bxPbWDHFftOig7qsW33LJ/OeiSpjIy2iMTOTsNig0pY6C8NVMihTLbTDzoUbbTPsYs8X8mf2ZObm5w/aAoA+wn3oZNsA215HNgjzS6JqNMK5UTAW1ohDTNA397T67fKPjUqQLpISRkcNOa4Uwh+nCI/X09XeuHKVNlCsqLQw7j1ziRvwPsirZuLpnCe2L7MAQmdjCUYOy2ug==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=TinCgyJgQx2LIAq3YZrsGtujcBeI9O5N0bzvleJjHpY=;
 b=Q04krQCZzMvJbPVWNXJJ8tKFmWy2bDq9x/u8fM+QuaJv9jsV7GXCnTUpieKy5xp/yZ8JVa92H6WpYmGWAMPBoZtl1RttmmH3I2mxX/MBBcPrwXff0jyeN71MVl/Z/Np5AgDpjz+W9ecvb4bi8wDiyzCQ4v5MRuhK9Mai/+Czskz3DyIrSiw1aYW8kF5HsZtYnWcEWDsoFOcGhb+vnHgS0FjnkO/acWVXwTNLErTGs0W+Pt/P1qY/k/UVFsNSu4+JcFtTX5Gyp52BeGof8R4nDy6edDWYxIxTzGqtjMMZNsDPJa/b7GojMwpbBUQIo+QmBQs6IPKtE68v0nS292TzVg==
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=TinCgyJgQx2LIAq3YZrsGtujcBeI9O5N0bzvleJjHpY=;
 b=fVuJBzSxtWePsjFAkcZM+IamqxaS39sMhkEZnA3QYU92OugCH1Slf27ZJLyVjS2RauVgh0RgY1PHsiWn7o9YLrxsq/PM/zj9vRUhC2GEVW9vo7/5b25q7Ecm0REwOBmP+/3ZeM0V0JlZYeUy2rQ98lbx/MeGkrjXgNaDC78udxM=
From: "Chen, Jiqian" 
To: Jan Beulich 
CC: "Huang, Ray" , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Andrew Cooper , Anthony
 PERARD , "Orzel, Michal" ,
	Julien Grall , Stefano Stabellini ,
	"xen-devel@lists.xenproject.org" , "Chen,
 Jiqian" 
Subject: Re: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
Thread-Topic: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
Thread-Index: AQHb23yakGdVC9XxvEWnYcnp8zrTt7QI/QAAgAGa9QA=
Date: Thu, 19 Jun 2025 06:39:53 +0000
Message-ID:
 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-3-Jiqian.Chen@amd.com>
 <516a3adc-320d-46ce-b235-8ef91469abcf@suse.com>
In-Reply-To: <516a3adc-320d-46ce-b235-8ef91469abcf@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.8835.025)
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_|CYXPR12MB9339:EE_
x-ms-office365-filtering-correlation-id: 0a6c2497-4b88-4ac4-9e2d-08ddaefc1910
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?UE5EOVJ3VnFIUkR1TldGWXltOTlDbWROaEtvSW5sb05EMVJaeWJrUWwvSDl3?=
 =?utf-8?B?NGt3YzJzam1leDRlVElKOU1iZWVUREZLb3BVS29VMnZUdHg4dWhBbTJ5Y3pQ?=
 =?utf-8?B?Vjhxb282SkNlSFRTdVU3RXhhckcwR2FkNTJjcm81Y0R4M0FwK1Roa1N3Yjhh?=
 =?utf-8?B?WlN0aW1ZM1ZyVHdmOWRpN0x1ZHZWTUlGV3hodDlaMTE1Y0trby84ajdJNzdF?=
 =?utf-8?B?WmJnWkVPNkZIUyswanN0V3RXbEdxT1hCdVdua0wwSGtVQzJtVGprZzgvOTh2?=
 =?utf-8?B?ZlJpRFFDS21LVzVKMFE0RnNla1JDZXQwYk96TG9pRzZJTmZLVHV0RWRkcXpr?=
 =?utf-8?B?bEZzZnhsZmQ3K3NZQ0dGVER5RmdaZHBFSzBpMzY3cDRBcnZ4eDdPT25BdWpJ?=
 =?utf-8?B?WjVLS2ZFNjBiYjg5Q01qSWN2WnZJcVNVZVhqczY5T1ZVVkZER05TelVaT1h0?=
 =?utf-8?B?WXZla2p3ZWVhVklvckNwbHlKMXpzSWsyM0YrR09EdytRZkpwY3laUVRPM0FT?=
 =?utf-8?B?aXBCVDUvNjZURTc0dWJ0WVUyd2liUTU5Q2ZnclBtZkpqRUdkeGR6amFIanlr?=
 =?utf-8?B?RXcxMFJEQWJLd1dxQkZCazlJMDFraEZiTXZMd2drc01QN0dSdHNmTTNLZjNh?=
 =?utf-8?B?RzdBTjJmMk5raFlKUExUN2UxYmtoKytvd1RCa2VYTW5acXNyeEd4OWh2YkR4?=
 =?utf-8?B?YVc2Q2JoWDNSR3RZZnhaOEpHUzJxVWVoVXRmTXVzamdDNnMrMkhOeGpsY2g1?=
 =?utf-8?B?NW5UM3J5N0dVSEU2SGlBZ1N5Y2JYaHNRU2pqak93bVc5NDhGWlZYK29FRU9o?=
 =?utf-8?B?emJGbUV2S3dqVStSZExEbzBHWGFhNCtFUlhrVUtMNDlEZ1FDczdVaU9zWXAw?=
 =?utf-8?B?aWJTNEd5QmJmZVA1MHR0N1pZN2U0QmVkQmFMQ25JeDhzWG1UN09hMmsyUHdi?=
 =?utf-8?B?VCtMdW5yTW9mcnlSN3JQZEU0eEVpdnZYeDJsSWF2QmZ6d291U2VRdTBHR0th?=
 =?utf-8?B?ZkVyTHM3ejRVNnk3SEdBQ0o3YlBZNURTTDNCSW82bkdLWFF1RklhWmhRQ0lZ?=
 =?utf-8?B?YjUwRWEzbWZobVc3WHpGSE1BZVlYSUlkWFJkZlF0aS9vTGZEay9Uc1haU1RO?=
 =?utf-8?B?TzhrUWgrRTZVdklEV3k0eEdsS25lMG8zcGVMZ1ljZktOak9BN0Q5bjI0aVJ1?=
 =?utf-8?B?OUhTTG9FZVhIMW91TzJRYzhheVNmRksyTHdubHFiNG1KUmxvUWJSRzI2eVMy?=
 =?utf-8?B?YUlVTEtsUG93U1l0aGJxZW1tbUtqRTRFaThZVjdnRkJvRVRhT3RqN2xSY0Ri?=
 =?utf-8?B?dHFYQi9CaTJ0TzVtZEt6ZzVwVFhYa3ErNFpVbFFvOG9kRlNZOFRyWkRoaDN4?=
 =?utf-8?B?Slc4ZHV5N1FuaFJxc0ltZUsrLzdLY2hSNHlQUldSdU5CS0o4ZERYQTZ2ckhF?=
 =?utf-8?B?SmdKeFNybE00dHRSUTNxNEtBSmEwNUcyT05RZDlaQklXMlRWSmZDVDRkNkd6?=
 =?utf-8?B?RUtvUEFqUk0zMkJOY2NwOCtheEZFOWxUVkdNZ0JFR1ZjbnpoSkpFbndTVElt?=
 =?utf-8?B?UHBwdW52M2dVc1NndkVlSSs5OEt3TGRJL3Q2eW1FdGRRT0wvVDZPZ1JjSUl1?=
 =?utf-8?B?L3dudmpBTWRUN09wbjVJSTE4NFZ2Ulhxdy9BRlBFWkFJTUsrR0ZBcWIyMFRu?=
 =?utf-8?B?Lzl2bXMwSjgvc2FGQjRNQ3J3MjlrTjRrZlg1aEZDSU9Ya2MwMXArSE9NZy9K?=
 =?utf-8?B?WlBoVGJkN3lYUTZxTVZ5SXdvd1NNbG45akIyMkxSTUtxQmd3TURVMDFIdFZW?=
 =?utf-8?B?bFBDbjluYUhvSnJKZU1CeXFsTG04VDJjNUdXTjVTV2xJRngzK1UrUVB1TFJ0?=
 =?utf-8?B?dlIrYVdUMU9aSkpZRlZCUWlZRzdpYklZZ0xsUUZlNGhlZ2orakRSQ1FFTGpE?=
 =?utf-8?B?TmNBY3FtY0xlS0RFaFFaWndHL0RmT2pJQzBKVzVMTHFXRnFob3RMdmNkTGhG?=
 =?utf-8?Q?SPw1TvacLVVEhuH+oDBEYwF3hx8SOA=3D?=
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?a1JNWVdOSHo2a200UVI2N3NTU0lHK2JubVkzcFUyUTdDc3llWWU2OFl6V1M3?=
 =?utf-8?B?WE83UTBLaHNJK1dncjVOZHZ5b2FEcERiQzRkRkVFTXJ0M1Y4T2dVNldGMkF0?=
 =?utf-8?B?ODJSRkltdndySHZoWUhnTGFmUUR1NFF3TjFUZkZ1R25qdG8rU2ZYTFVGaUpO?=
 =?utf-8?B?SGVxK3VMK2JpbjBFek9PeXc2cjljRjg3cDdDVzY0bE95Q09LZWQyTnBiT0c4?=
 =?utf-8?B?YkI1bno3Ukg1YzdaVDlJdGtJaG52UWZKcnpQeFBZSVh2ZEdXb05NTXFSWThu?=
 =?utf-8?B?Q25wWWpURE5XcTNmc2FBRCtOeGE2Y3lCS3c4M2owcndLWlhhU1VrMy9rYzhu?=
 =?utf-8?B?TW1zY1Vmam16RENadmdlZjVJVitIdEUrQ2VlMTBadXNEREZHUDF4SDJSVVo1?=
 =?utf-8?B?Y1l6eWFPaHZhM3J3YUNxSnJ0ckRPTFh3R2IvY3Z6eWRaUGZHZWx0L2lMaUF6?=
 =?utf-8?B?d3pQMHJKVDNFQ3lCc3NQeEFLcXpBS0JRaFpXRElJTUEwT0JpZVBORDFtWXhy?=
 =?utf-8?B?UGRsY0xqWW0wQnBJUWdIeFY1QmdIcHZ5bG0zOXVqL0tMc2ovVlg2aENZRU1y?=
 =?utf-8?B?UUhMWUZ5ZGN5Y01TdVZkblFpd1E0MGk5ajFtVHJTTUcrb09iT0JsWENrNUJT?=
 =?utf-8?B?OW1GNnZUTzBocmFzS3NZa0RPaFN2Nk13ZVg0WXRuL0tCM08xUTYxeFA2MnVN?=
 =?utf-8?B?d3o3NUVOZkJqMTVZczBJdXZwR3QxVlJuc0RIQTJLQ2tWYXVmVHE1QTZPNkFT?=
 =?utf-8?B?b0hiOVA3dXlmWVdFaWtmUkNESnIwdk55c1lLUTRKM2g2NEt6eVhSUjBLMzBP?=
 =?utf-8?B?QmFIbUZzZHNTMndkTnVERVlsQm9BWjlTVzhaUjg3Ym8xZ3hYdXRjVG9jMXR6?=
 =?utf-8?B?dytNNzVURGpUdFdRNVNveDRvUUlub1JqSDNmYm9YNHdXeWg0ckxhNkNnS29v?=
 =?utf-8?B?ZEx6OHltZTB3SXl3d3Q3a3U3TlZOWlpQK29SWEtrdzBNQ0FtcUFmN3NqbVM2?=
 =?utf-8?B?YjFpUW9HQ2phY3pFa0tUT0tNbDJGME1kTHV1SG8wY1MxREdtZU5SbUk2Smtw?=
 =?utf-8?B?cEl6ZUNzcFZPVG5RdlZBSXJaaWozdHJjVURWSEV6Z1hWWUR1MTU4cUw4L0hD?=
 =?utf-8?B?VXlRUUtHQWZYY2pNc0tScFBzUDU0L0ozb3Z4TEE5ZFpXRGVIMStWMDhqQ0pT?=
 =?utf-8?B?T25SMTZkSW8vMXJpa1NTdjhQT3gySDZMNkhvR096am1KQnFiU28wMDRaWHpR?=
 =?utf-8?B?UGhITU5xRHB5UHF6bDhsbW9hZnhPbkhLNGJkdmJTVmJMTFUwbEl2Q3lGZnhX?=
 =?utf-8?B?SHZYSDNXY0txamVGRGtqRmJKSWpRUFJGM2RmRWsvTTJSOEdVSkIyMEVqalBW?=
 =?utf-8?B?em9PWVBSdlZ0QmtQS1N4OVRuRE80bVdRTkpjWmZBYkdXalV0Vkp3RTFIaFgw?=
 =?utf-8?B?eUVtRndYSm55SFIwcVdGZzhKRUs3RHo0NEczSTl6YWFmK0ZjbzVxS0xVZEEx?=
 =?utf-8?B?UnpsSnFnVVJyck81NWZ2UlBod2JkRGl2bjQ0eWZHVVpHVmVEdGxjV0lsN3B5?=
 =?utf-8?B?Ym5EU05lemR3L1VtR2c5dGZzWmlKR1RUMkh5UFNYWjVydG55cTJJSGI5Q0dW?=
 =?utf-8?B?RjU3bHg2SVZ6NmpUdzkxaklUanFIdlpwMVZWUkF5dVV1QWoxc1A4ZE9WUmN6?=
 =?utf-8?B?MmhGVzRtQWtXSmFmMEtRbG9YNy9aa2krK3BrUnJ5TG8wOW5SS01Sa2w0Y2Rx?=
 =?utf-8?B?R2p0UlN6c25ndStxOGZjK0cwL2d3TjdXNHBiZmhuZnVYaThab3NCdjRvUFRP?=
 =?utf-8?B?QTd6UmdqYzVEY2lJR0xPMXh4R1dmUXNxaGpPbFl5K3NJNDZMaGRPUDNsMm8r?=
 =?utf-8?B?WEN2OUFiUVFMdXVIV2pFcWJVZWNzZS9zWmFVUEdHN2YzVmJCeUxHNWYxZVVy?=
 =?utf-8?B?TmZUMWI3cURmWHhjVUp0aHZYNlZ0eG1HdzUyTk1tZHdvS1hpQ3RabVh5WUFJ?=
 =?utf-8?B?QlFqK3B2SGpFdE9welNOTlBFVENoNjBJUTNrTUs1NzAyTExvbGpVRzBUNnNV?=
 =?utf-8?B?NFVaYmo5V1djWW4zMm5OQjZDTkdBZzBNcEVwL2tmYURHZkhTSzhXLzF5V09Y?=
 =?utf-8?Q?yIPM=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <3C875BA41F799743ADDD353D7EC85EDF@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: 0a6c2497-4b88-4ac4-9e2d-08ddaefc1910
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2025 06:39:53.1953
 (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: swJfTocPid5U66/5XHJARHhw3QQhbg6Bd/baL93F8bm/WvOcMTQgXAsDo2Ekan64p41/sgKb3qgIpbuDEW8c+Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYXPR12MB9339

T24gMjAyNS82LzE4IDIyOjA1LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMTIuMDYuMjAyNSAx
MToyOSwgSmlxaWFuIENoZW4gd3JvdGU6DQo+PiAtLS0gYS94ZW4vZHJpdmVycy92cGNpL21zaXgu
Yw0KPj4gKysrIGIveGVuL2RyaXZlcnMvdnBjaS9tc2l4LmMNCj4+IEBAIC03MDMsOSArNzAzLDEz
IEBAIHN0YXRpYyBpbnQgY2ZfY2hlY2sgaW5pdF9tc2l4KHN0cnVjdCBwY2lfZGV2ICpwZGV2KQ0K
Pj4gICAgICBwZGV2LT52cGNpLT5tc2l4ID0gbXNpeDsNCj4+ICAgICAgbGlzdF9hZGQoJm1zaXgt
Pm5leHQsICZkLT5hcmNoLmh2bS5tc2l4X3RhYmxlcyk7DQo+PiAgDQo+PiAtICAgIHJldHVybiAw
Ow0KPj4gKyAgICBzcGluX2xvY2soJnBkZXYtPnZwY2ktPmxvY2spOw0KPj4gKyAgICByYyA9IHZw
Y2lfbWFrZV9tc2l4X2hvbGUocGRldik7DQo+PiArICAgIHNwaW5fdW5sb2NrKCZwZGV2LT52cGNp
LT5sb2NrKTsNCj4gDQo+IElmIHlvdSBhZGQgYSBjYWxsIHRvIHZwY2lfbWFrZV9tc2l4X2hvbGUo
KSBoZXJlLCBkb2Vzbid0IGl0IG5lZWQgKG9yIGF0DQo+IGxlYXN0IHdhbnQpIHJlbW92aW5nIHNv
bWV3aGVyZSBlbHNlPyBPdGhlcndpc2UgbWF5YmUgYSBjb2RlIGNvbW1lbnQgaXMNCj4gd2FycmFu
dGVkIG5leHQgdG8gdGhlIG5ldyBjYWxsIHNpdGU/DQpUaGUgcmVtb3Zpbmcgb3BlcmF0aW9uIGlu
IG1vZGlmeV9iYXJzKCkgYW5kIHZwY2lfZGVhc3NpZ25fZGV2aWNlKCkgaXMgbm90IGVub3VnaD8N
Cg0KPiANCj4+IEBAIC0yOSw5ICszMCwyMiBAQCB0eXBlZGVmIGludCB2cGNpX3JlZ2lzdGVyX2lu
aXRfdChzdHJ1Y3QgcGNpX2RldiAqZGV2KTsNCj4+ICAgKi8NCj4+ICAjZGVmaW5lIFZQQ0lfTUFY
X1ZJUlRfREVWICAgICAgIChQQ0lfU0xPVCh+MCkgKyAxKQ0KPj4gIA0KPj4gLSNkZWZpbmUgUkVH
SVNURVJfVlBDSV9JTklUKHgsIHApICAgICAgICAgICAgICAgIFwNCj4+IC0gIHN0YXRpYyB2cGNp
X3JlZ2lzdGVyX2luaXRfdCAqY29uc3QgeCMjX2VudHJ5ICBcDQo+PiAtICAgICAgICAgICAgICAg
X191c2VkX3NlY3Rpb24oIi5kYXRhLnZwY2kuIiBwKSA9ICh4KQ0KPj4gKyNkZWZpbmUgUkVHSVNU
RVJfVlBDSV9DQVBBQklMSVRZKGNhcCwgZmluaXQsIGZjbGVhbiwgZXh0KSBcDQo+PiArICAgIHN0
YXRpYyBjb25zdCB2cGNpX2NhcGFiaWxpdHlfdCBmaW5pdCMjX3QgPSB7IFwNCj4+ICsgICAgICAg
IC5pZCA9IChjYXApLCBcDQo+PiArICAgICAgICAuaW5pdCA9IChmaW5pdCksIFwNCj4+ICsgICAg
ICAgIC5jbGVhbnVwID0gKGZjbGVhbiksIFwNCj4+ICsgICAgICAgIC5pc19leHQgPSAoZXh0KSwg
XA0KPj4gKyAgICB9OyBcDQo+PiArICAgIHN0YXRpYyBjb25zdCB2cGNpX2NhcGFiaWxpdHlfdCAq
Y29uc3QgZmluaXQjI19lbnRyeSAgXA0KPj4gKyAgICAgICAgX191c2VkX3NlY3Rpb24oIi5kYXRh
LnJlbC5yby52cGNpIikgPSAmZmluaXQjI190DQo+IA0KPiBDb3VsZCB5b3UgcmVtaW5kIG1lIHdo
eSB0aGUgZXh0cmEgbGV2ZWwgb2YgaW5kaXJlY3Rpb24gaXMgbmVjZXNzYXJ5IGhlcmU/DQo+IFRo
YXQgaXMsIHdoeSBjYW4ndCAuZGF0YS5yZWwucm8udnBjaSBiZSBhbiBhcnJheSBvZiB2cGNpX2Nh
cGFiaWxpdHlfdD8NCllvdSBtZWFuIEkgc2hvdWxkIGNoYW5nZSB0byBiZToNCiNkZWZpbmUgUkVH
SVNURVJfVlBDSV9DQVBBQklMSVRZKGNhcCwgZmluaXQsIGZjbGVhbiwgZXh0KSBcDQogICAgc3Rh
dGljIGNvbnN0IHZwY2lfY2FwYWJpbGl0eV90IGZpbml0IyNfdCBcDQogICAgICAgIF9fdXNlZF9z
ZWN0aW9uKCIuZGF0YS5yZWwucm8udnBjaSIpID0geyBcDQogICAgICAgIC5pZCA9IChjYXApLCBc
DQogICAgICAgIC5pbml0ID0gKGZpbml0KSwgXA0KICAgICAgICAuY2xlYW51cCA9IChmY2xlYW4p
LCBcDQogICAgICAgIC5pc19leHQgPSAoZXh0KSwgXA0KICAgIH0NCg0KUmlnaHQ/DQoNCj4gDQo+
IEphbg0KDQotLSANCkJlc3QgcmVnYXJkcywNCkppcWlhbiBDaGVuLg0K


From xen-devel-bounces@lists.xenproject.org Thu Jun 19 06:43:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 06:43:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019720.1396240 (Exim 4.92)
	(envelope-from )
	id 1uS8zk-0000Rc-DB; Thu, 19 Jun 2025 06:43:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019720.1396240; Thu, 19 Jun 2025 06:43: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 1uS8zk-0000RV-AN; Thu, 19 Jun 2025 06:43:32 +0000
Received: by outflank-mailman (input) for mailman id 1019720;
 Thu, 19 Jun 2025 06:43: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 1uS8zj-0000RO-3O
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 06:43:31 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20614.outbound.protection.outlook.com
 [2a01:111:f403:2414::614])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b4ff71d5-4cd8-11f0-b894-0df219b8e170;
 Thu, 19 Jun 2025 08:43:29 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 SJ2PR12MB9244.namprd12.prod.outlook.com (2603:10b6:a03:574::19) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Thu, 19 Jun
 2025 06:43:25 +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.8835.027; Thu, 19 Jun 2025
 06:43: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: b4ff71d5-4cd8-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=KGw70z7erNUIoe3mKVpqMseyCC5Nk4+r+nK0B4Hk+qxbFyOwOBQn2s5leQSRi7FU2BIdCaiQqhC/HvOabOoOCOZhUIe0xcQzQFK4aTMkf4O7FU+5uR6cbjHgwl9xHZh/L549Iilcc6qnZUDZHZEYr4HWcvYFYSNDw6phjnPS8TZmYES/Tl+c9BvQNLXRnT4YW9Lra6hG5wIll/1+OHMlwdKp4hMY66daV9uLY0q/8+9CmoxwPLCYK2gjGBmObUE8GpAwnIWWPUfQut331kQ+vtUr0DDveIRsOMjX8ZfB2G20UFVIlo0EIEgCEG194H+Kaxl2Ag8wVPxhjuq+xoDlvw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=9cQfdXGWrWvKYP7dnRjl1AHQe9WtEoBo755K0lNV97w=;
 b=szV/IZParAXvuYfL45XJ+tv+0ZkZ/6r9VZl/yP1ObJcPsJf1MjtduQaafa1+vaFJ9ChZScWuaVC4E+sNCzn2wCJIzvpP0hFia+ETXtsJdmeEliu3MrfSsgij6EV05j4nEXt3iSRsK+ODYvOElsrLGIXqEUktcsMQ8mo6KgBXIVUrOneQnGj1aMLMSDuVn7sUM6mwNfiqfuNPWKD9JznqDuudpEujg8Dz061dDK07MtQXLdW3po9Ur+PKte2AmMdzBUN4g+NP2GAExcT6DFxD2XEbtAMg6fcihBrXlcOj7ALjvENN52pcleILHlHh8VATaj7jmI4ioSF3mtD9QsDvBQ==
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=9cQfdXGWrWvKYP7dnRjl1AHQe9WtEoBo755K0lNV97w=;
 b=iLWfUjPGqcjZKWgfqbnfFkbZ+Sqrmy6PsaK1sFIqBjLPGUrwJzl7FMyjXbwqJcYtU+2LUJXp8LOLmt9sM6dJVY0/QpZvzjJtKWm6tA7j9cAT8x9PIRG6oredNSXnbaFD0IwUsL1Pgy76V9/5TvsmtCIQwAbyg4TIqEfJWww7us4=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Andrew Cooper
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Anthony PERARD , "Orzel,
 Michal" , Julien Grall , Stefano
 Stabellini , "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v5 04/18] xen/cpufreq: introduce new sub-hypercall to
 propagate CPPC data
Thread-Topic: [PATCH v5 04/18] xen/cpufreq: introduce new sub-hypercall to
 propagate CPPC data
Thread-Index: AQHbzuQ+jriHLS/NnEiww9yxRz3NOrP+OOqAgAvzMpA=
Date: Thu, 19 Jun 2025 06:43:25 +0000
Message-ID:
 
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-5-Penny.Zheng@amd.com>
 <0de0ea5c-64c9-4ac8-8e76-750cb3036419@suse.com>
In-Reply-To: <0de0ea5c-64c9-4ac8-8e76-750cb3036419@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=True;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-06-19T06:43:16.0000000Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=3;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged
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_|SJ2PR12MB9244:EE_
x-ms-office365-filtering-correlation-id: c3be0b72-3bb4-456c-027d-08ddaefc978c
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?TVlTYnBLZ0lweGs5aFhGM0VYeTRDUFRJS1lBQ1JxcG1KSjhNWnZROEIwZXhh?=
 =?utf-8?B?QmJXNTFaalF2L0x4Um1CelFzL3g4L0VDSk5WcFJxcWR6aG5FUmwrY2RrSzFL?=
 =?utf-8?B?UnpGZTJtQWZJRWJkdlZ3STgwK2NKQVVha1Rxd3lYRjBaZWxoSGk3elJybWZU?=
 =?utf-8?B?dkJmMk44UWVhRXVPemlLMlozL1FnemVKeFM0TnYzU2Rybmc1L1BsbHpIM1lT?=
 =?utf-8?B?VUp4RDdWbVZTYmM2MC9ILzlxQ2RoYlIvckdqalFlSFQycmhtZS9pYUhtbG9j?=
 =?utf-8?B?VE1VSmN1UUFuU1VtTlhNZTBzTDFGeXZkTDJUeE1nMUFXVGM1TGxYV2hNMzNx?=
 =?utf-8?B?a05JY0hhdUp4bU5BYy9STndWSnFqRm5wL0gxcjJLRzNDUy9iOUtUT1FVNEN0?=
 =?utf-8?B?Y0N2VXVsUDljSDk2VnJ2K3pjU3RRSERHQ2kxR00wbUFCZHJOVDd2SHNrVXlV?=
 =?utf-8?B?Sk51OFVJRGdkTjJrc2wvY1padUdvSW9ZSy8xKzdIczY0ZFNMZVBYMDhraTNs?=
 =?utf-8?B?dlhLZjlRM244TFFrZkRVZVAvV2RzdVRYUU00WWxBTEhzeUdHeURFYmhtM1FZ?=
 =?utf-8?B?SlBDenZYZGw1ZXRiK0lrYmtPb3crc29tTGV0Zk9pYjFKNVFua05KbFYzOWdS?=
 =?utf-8?B?K2tJSHhSQ3c4bTg2Vy9UQWVTL3QwY3Njck5FM21vdXppUXNETUlZeDZ5QUVv?=
 =?utf-8?B?QzU3TzdMclVRTlQrYnFyV0Z2K3Bpb1owK1M2dDdYSmV3d3pQVit3bE9RR0Z2?=
 =?utf-8?B?NTZ2TFlncTd6LzN2dFdUV1N6Y2lKd24rL0Y3MWFNZTJ5RnlpNHl6MVJkMVRz?=
 =?utf-8?B?MWtmU2ZDRWxnZklRNE9iUkdtL1pqWlRTSXVDak1iSTNhRWhRZmk2NDl1WXJs?=
 =?utf-8?B?UzcyQ1ZHSjdPNTRESUc2UCtyMExKMkpxeGFqeEZMRlVhQURwa0dBaDNFVngw?=
 =?utf-8?B?Szlmd1NKQ3AwUmhHQWxaemF2M0NFVnFBNXo4NjN0SmdRQ2hKazZSS25GYlgy?=
 =?utf-8?B?YVlTbHNUK3dkSTFuWDR3K3p3Q0sydzZ3Q1d1TXdqT2NxbldkOC96cEtQZHNk?=
 =?utf-8?B?UnJlVXB1ODFkanhJeitXdVZ5TDR4bnArVDVYalJzazVRR1hJak93cXF4cFZZ?=
 =?utf-8?B?aVR5THBKZnVHTEJ4SGd5c0I4a1dBY2VRK1VKdFNsUU1kNi90dWVBY2NucmNy?=
 =?utf-8?B?UTVqdkF0OWxEWlBFNXRlZDJXNlREeXY1Q0gwWUt3MXlQeFlLQzV6VHZQL1pM?=
 =?utf-8?B?SXJqV29PY2JLOExLWEJKaEM5a2Q1ZHVKNnZhdWtEUEhPNkJCZm91U29FNUMy?=
 =?utf-8?B?YmJ6UktOcmJiMnFNV0lLZThXRVpteTM0S2htcEp6TEpIRUZrSkFjTDVzOHNB?=
 =?utf-8?B?K2grMUphbFhaU3F5anFNU1JNYjc2L28rWDVORjhoeUVSbmI0NDBsTWhRR1hR?=
 =?utf-8?B?NzBNT09lN1hRTy9MdXBYN2FIWGd6WUlCWm1aYTFQdHhwMDNmVXE2d3JTaDR1?=
 =?utf-8?B?ZzBnLy9NRDNwNnJYR3lUK0c3S04xKytyeFA1WFFrZk9xWmZXMnVhQmx6Mjdx?=
 =?utf-8?B?aXExNzEzb3ZEZkU0ODFjR1ZBcTB5WHFxbnpwK2ZFdysrS3VaZVd2dE1Cb0t0?=
 =?utf-8?B?Sk41cWZmaUorYVV0VUVHZ002MElCRHp1QzR2UUVXV3kvbDNkTVJMK2ZlZlpz?=
 =?utf-8?B?aDhrOU5XM1YwSEE2c2JDLy9nZWxTWlZsTWZ2Ky90QlUxVlEyNDV5b2kzbG4w?=
 =?utf-8?B?SklONHlTWjdDbFBUN29ubll3dnlWREo2ZU1KUEpxVEtTWEJTV2pWNHJ1Wnkz?=
 =?utf-8?B?MmxuMEo3WkZCbFRTSDNtdEcxYnhqWjJ2emVwaEZPcXVRYUpzNGU3R080N3ZR?=
 =?utf-8?B?SUtmUTZJRjFVRms4WC9vVmVPTEwwVEhVTEpGakt3TlVPeG9ESkErSGdLQ2cw?=
 =?utf-8?B?dXo1eE41WmpsRWJkVHYwRmhQSFd5RjVLZVhYNWIyeTdDOXFvRWlTSGhmY2lB?=
 =?utf-8?B?QllWeTFkZHN3PT0=?=
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?dkRpT0VHWU1tUmhCaVdKbzNLRWxSVDhFRURYblk5a1FQMVJMbWR4VlRMdkRi?=
 =?utf-8?B?V0U4NktIRFVkajJsOUw4ejZ0S1hXaGdBQ296WEZJdFY4VE5JTms2VDFUU1lL?=
 =?utf-8?B?UGVFN2pjUXpGMk4zU3VvdWExMk9qSzZhTGV0RUNFR0FRQzloak9iUmczczRo?=
 =?utf-8?B?cUR5QnlUTnNSREpYbTZUdGVuWHorZkZSdGV1Y3JuYzluczJFb1FRcHhkdXVq?=
 =?utf-8?B?dllRT1ZXbFpRNTkwNFYrdi9sMGt3eE5mUGVaUzVnOGNnZ1NwMVVrTmc3VUNr?=
 =?utf-8?B?YmFUSXorNkwycmxIbnlreXFVTnJ6am03OVg0TGFZeStxQVlOQmxURzhGU2Vy?=
 =?utf-8?B?a0NZRnRVNWM2QlpUREwyaElEelhScE5tWXJRZDVkaGJqZzdsSDJDcU9RU2xC?=
 =?utf-8?B?MXpaaFc3dTZIQmNLcnpFL244OFg1MGhTQjczUS9BcmlBOVR6QVlNSEVWZnlx?=
 =?utf-8?B?cWwzVTNaaWRFVGlOdmt2bEtNbTFydm5hUlpLWWlqR0tKUUlIb2tiL0xmbXpF?=
 =?utf-8?B?dk5zV1haUkhLOG5Gc3pYdUplSE9lYXhHbjQ3djlVWWNYc2MwUHdDcHhNQTNI?=
 =?utf-8?B?NW9ra05Eb25lS1lkV2pTdHJIbm1aZHZVTUlJMVE3SDhSb3FucWpsUkllTlBl?=
 =?utf-8?B?VUtvT3ZrS3pyTHVkOGhKcmpPQXdtYXpSLzdqUWIwcllaTkVqSkl6bzVnUWhu?=
 =?utf-8?B?MWRkYzNGUmQ2U1JVSjVJZ2xiVWg0N2RqdFd6Q0YyTXdzSkI3SitYV3FPWkpK?=
 =?utf-8?B?ZlNNcFk0TVpvVENKUzlJYUl3aHdzMitPWE1SeUljSVMxdi9xeEQ3WWx1VlZV?=
 =?utf-8?B?Slhac1ZhUDVtVkxEeVBjclhRV0ZTZHFUdmxDUkpXckhhRlNXRUIrTHYxaCsy?=
 =?utf-8?B?bkhyV0VUNlpvc0hrOTFFSHVyYjNHdldtc3dRc1dwWHNHQ0MvN0Y2aTMyMERP?=
 =?utf-8?B?YjNrckphQ05TYm9zL2U5cjRzQWQycHdDcWpNVWtNem9yQUI5Q2o1N1YrVjZI?=
 =?utf-8?B?citYSy9EYWo3dit3R3ZhcHIveGQ1dk02RHlNYmNNdjQzOWg0cncvU1ZVYThv?=
 =?utf-8?B?c2JQRjVMeTFZWkQ5ZDFwK0dvTkQ4SUk1c3FBOXo2QkpsNGFrYmRtV3NWTjVp?=
 =?utf-8?B?T3ZyaW43YytqU3lzcEdWb2lkV25ocWNBQktiWDhURW9OdFgvRy9SQ0RHNjM1?=
 =?utf-8?B?TTBpVGVKemU4S1VUTXJVUDBKRU41Q2tXZVJ4L215TzdHb0hLZ2c1ZTRtSVN2?=
 =?utf-8?B?T21zcTFHVDZoWFVxMGJNNm9QRmorclZ6NmlVOVdWc0VBM2prRmdkbEM1bXA3?=
 =?utf-8?B?Sm9iOWpkbFl4WThjbDBRRDhuRXlLMjFacnhCTHdvclg3eEV0SmlZeEdZQzlV?=
 =?utf-8?B?d3F2MG9lL293dlFaOHQyUGI0Tjh5UXA1bGxka3lvWWVjZGNneDRWeEFpSkFh?=
 =?utf-8?B?NFhSdndJZHVjK2JuRmpYell5d0E4Q2NKS09XME51QTRPTUNhSzI2MlBtM24z?=
 =?utf-8?B?WnNma08vRlQzMlNSVVFkZjFSZmhHRVkrY3cxOWNpZFNvS3NqMmVFZk10MGVv?=
 =?utf-8?B?cXJGVEhacXVuWmY4alVzTDMvTlhsT0x5UWNzTTdraHJjNDlUZXdnSklkZHl2?=
 =?utf-8?B?WlhxbkgxbWl6QWZ2V0kvV1hUU1hTOUQvanNVaGN6WjU4ZWpKQzBSS2dtdkFP?=
 =?utf-8?B?NmMwb0hnWGhqb1liZmwzdHBhZGFMOU1mUGJJWmNPUnBKTG4vajNlOFp3N1pv?=
 =?utf-8?B?c1NQY2lMMmtQdVRGNlhRM0RKMUJ0bjhoYm0wc2VMMjdZUEhTaWZuL0lTWWsr?=
 =?utf-8?B?R2hIdUVuQ2p2L1l1ZUl0V1B3ZXVPMm5sQlAyN2cxazFZTlNNK3V1Q29XQkJ2?=
 =?utf-8?B?SXMxMmduZG43RDhmREJpaWdpU3hQU1M0cVk1YnlKdjRrNnltc2FYbXlWMTNm?=
 =?utf-8?B?YUdSQmw3Q05Ua1Q1ai9KQjdoUUZzUHVqUDI5TCtZUUdXdU4zaStPZGpnVVBF?=
 =?utf-8?B?b01BRDl6WjBNc1JSOWFLU0tLVFFCaDdaUlBZQ0g2TkYrQ3VHS1JUVDdqb2lk?=
 =?utf-8?B?RjlYdTdaUUxnSTRocWtBMk1HOTlOMjJNc0U4YlR6VWNYNGJ5c1BaeVQybnBP?=
 =?utf-8?Q?L8Io=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: c3be0b72-3bb4-456c-027d-08ddaefc978c
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2025 06:43:25.3477
 (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: YHV0f7TqV8etxwZRKP1IviZar3ohO4nP1k6av4jq6+7X6v0omaDyZ6yo/4Lm2cIx7qgGTku8neqTnX1V1pidGA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB9244

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDEyLCAyMDI1
IDEyOjEwIEFNDQo+IFRvOiBQZW5ueSwgWmhlbmcgPHBlbm55LnpoZW5nQGFtZC5jb20+DQo+IENj
OiBIdWFuZywgUmF5IDxSYXkuSHVhbmdAYW1kLmNvbT47IEFuZHJldyBDb29wZXINCj4gPGFuZHJl
dy5jb29wZXIzQGNpdHJpeC5jb20+OyBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4
LmNvbT47DQo+IEFudGhvbnkgUEVSQVJEIDxhbnRob255LnBlcmFyZEB2YXRlcy50ZWNoPjsgT3J6
ZWwsIE1pY2hhbA0KPiA8TWljaGFsLk9yemVsQGFtZC5jb20+OyBKdWxpZW4gR3JhbGwgPGp1bGll
bkB4ZW4ub3JnPjsgU3RlZmFubyBTdGFiZWxsaW5pDQo+IDxzc3RhYmVsbGluaUBrZXJuZWwub3Jn
PjsgeGVuLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0gg
djUgMDQvMThdIHhlbi9jcHVmcmVxOiBpbnRyb2R1Y2UgbmV3IHN1Yi1oeXBlcmNhbGwgdG8NCj4g
cHJvcGFnYXRlIENQUEMgZGF0YQ0KPg0KPiBPbiAyNy4wNS4yMDI1IDEwOjQ4LCBQZW5ueSBaaGVu
ZyB3cm90ZToNCj4gPiBAQCAtNjM1LDYgKzY0MSwxMjQgQEAgb3V0Og0KPiA+IC0tLSBhL3hlbi9p
bmNsdWRlL3B1YmxpYy9wbGF0Zm9ybS5oDQo+ID4gKysrIGIveGVuL2luY2x1ZGUvcHVibGljL3Bs
YXRmb3JtLmgNCj4gPiBAQCAtMzYzLDYgKzM2Myw3IEBAIERFRklORV9YRU5fR1VFU1RfSEFORExF
KHhlbnBmX2dldGlkbGV0aW1lX3QpOw0KPiA+ICtzdHJ1Y3QgeGVuX3Byb2Nlc3Nvcl9jcHBjIHsN
Cj4gPiArICAgIHVpbnQ4X3QgZmxhZ3M7IC8qIGZsYWcgZm9yIENQUEMgc3ViIGluZm8gdHlwZSAq
Lw0KPg0KPiBBIGNvbW1vbiB3YXkgb2YgY29tbWVudGluZyBvbiBzdWNoIHdvdWxkIGJlIC8qIFhF
Tl9DUFBDXy4uLiAqLy4NCj4NCj4gSW4gYW55IGV2ZW50LCBoZXJlIGFuZCAuLi4NCj4NCj4gPiAr
ICAgIHVpbnQ4X3QgcGFkWzNdOyAvKiBwYWRkaW5nIGFuZCBtdXN0IGJlIHplcm8gKi8NCj4NCj4g
Li4uIGhlcmUgKGFuZCBvZiBjb3Vyc2UgYW55d2hlcmUgZWxzZSkgLSBwbGVhc2UgYWRoZXJlIHRv
IGRlc2lnbmF0ZWQgY29tbWVudA0KPiBzdHlsZS4NCj4NCg0KQXBhcnQgZnJvbSBDYXBpdGFsIGZv
ciB0aGUgZmlyc3QgbGV0dGVyLCBkbyBkZXNpZ25hdGVkIGNvbW1lbnQgc3R5bGUgaW5jbHVkZSBm
b3JtYXQgbGlrZTogSU4vT1VUOiB4eHg/DQoNCj4NCj4gSmFuDQo=


From xen-devel-bounces@lists.xenproject.org Thu Jun 19 07:27:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 07:27:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019759.1396251 (Exim 4.92)
	(envelope-from )
	id 1uS9fc-0005wx-GV; Thu, 19 Jun 2025 07:26:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019759.1396251; Thu, 19 Jun 2025 07:26: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 1uS9fc-0005wq-DR; Thu, 19 Jun 2025 07:26:48 +0000
Received: by outflank-mailman (input) for mailman id 1019759;
 Thu, 19 Jun 2025 07:26: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 1uS9fb-0005wk-6M
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 07:26:47 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20603.outbound.protection.outlook.com
 [2a01:111:f403:2009::603])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c0cafb0b-4cde-11f0-a30c-13f23c93f187;
 Thu, 19 Jun 2025 09:26:45 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by MW6PR12MB8913.namprd12.prod.outlook.com (2603:10b6:303:247::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.28; Thu, 19 Jun
 2025 07:26:41 +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.8835.027; Thu, 19 Jun 2025
 07:26: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: c0cafb0b-4cde-11f0-a30c-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=rrga4XHVaoDcsVfvNGjylfqDgPfeRxrO9ObTK+DaoiOMME0yDM8byxkXudj1EEaI2ooxDsVvNkPQstsgj2SWX2n/Mm0i9iEmin72AuXqfxbJx3yHQPzXagM1IT9+3tVKcGqtYu0TqLxBnHNkQ3eQj2SKQzVxS30h36yxQuZ5jjn3m0zJtANS6pCtxjy8rOB70ujFModsXBWTYjvjEV2d7PIputJ/cFGSA65Vyzjgh98pNmg4Z5EM3rSKP4k0dsIdSPyY34Q/B6tyPxE0Y+C0SjGsH5tk8k6b5Cpy+4b4u3UdOJws+d45Sv5Y/F78/Katu39aRFizPjy3JE2HMVBBuQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=s4VKaBeGdc86MRbLrlgOPvn3xfUD8EuxN664Q06HNaY=;
 b=v4LyvarjOhqrchmwexbWKdEZkhJz+0lhrVyeH+wEm+8IoElnWWMXqjwg9O0itIJ9Z9KdrIFqavsXp7rADzDH/VMS3JVCnLqQphfBa3qa8DEI9NJowMuPOB1Gewxpy1Bt/gFKjPlOOSD+IpLV86zPZ+5mzKSGVO0d5IbEtrZc+rZ2H7XxnypAAOoeopkKnjRohi0hOQ16zm3kNEHWdshLWHoqLnCIrCYLB607cVyV3Iq4XQmK6fWbfMD5J3mzHjBQxHBUNt7G3IJK/VQOihQFYiCp+u/SWDTtH0aYZf90/YtXUG2hP70avifWLQPNRajPQOG/pfAG1UM5SjO2XEQpPA==
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=s4VKaBeGdc86MRbLrlgOPvn3xfUD8EuxN664Q06HNaY=;
 b=G8RaFAo2qfqDTcFTZRLdYvYBY8MRmjlDpsmfvcGKbmMt9d1nqc4UociZtfN5ql8kPiR19Cpt4aENkrBmKNVWs30TPIWl5gdDyoWGLmygxQVQB5FIHjYtb9ijyTbSeVE9s6MqvPsyYCcXcq8NRbGfugO9863HAdB8v+LCCFrFaNQ=
From: "Chen, Jiqian" 
To: Jan Beulich 
CC: "Huang, Ray" , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, "xen-devel@lists.xenproject.org"
	, "Chen, Jiqian" 
Subject: Re: [PATCH v6 3/8] vpci: Hide legacy capability when it fails to
 initialize
Thread-Topic: [PATCH v6 3/8] vpci: Hide legacy capability when it fails to
 initialize
Thread-Index: AQHb23ydSLPIKyE480C9STMPmN1Rl7QI/lUAgAGnEoA=
Date: Thu, 19 Jun 2025 07:26:40 +0000
Message-ID:
 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-4-Jiqian.Chen@amd.com>
 <2708d242-1a11-4c2b-a3df-595b0bc23bfb@suse.com>
In-Reply-To: <2708d242-1a11-4c2b-a3df-595b0bc23bfb@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.8835.025)
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_|MW6PR12MB8913:EE_
x-ms-office365-filtering-correlation-id: 4d68c18f-b84f-463e-b6f3-08ddaf02a292
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?WFhwYytZM2gxeDMwVGJOdFJ5YWZSNm1oOG5Rbm9la21MbUQ4REF0ZVRxNU5N?=
 =?utf-8?B?WlpyUUo4QS9Db21XMWowdjVJYnF0V20rZkRSS1laczF4aXRtRmpNTFVManVH?=
 =?utf-8?B?WXJnMHF4RVY2amVYbk5Nc0MxcmRZajFWMkE4eWhOWVgrK2x1LzJtUmN5L1VM?=
 =?utf-8?B?WVhBMHB2YmNyWmY3bjQ1ajVETHZ2dHBTVWFIMU9lQld4YUN5a0pBL3ZUZjdl?=
 =?utf-8?B?b3dZMjFBQVNES0RGSUdWaU1jZVJ5QTdrMWRVemczQ0thRzJOWDg4QXMyc1RQ?=
 =?utf-8?B?M1doaDZ6NUk0eGdQdmswamxySENmbG95QTJwTk9TS1pET3pqZGRNUHZsWmFq?=
 =?utf-8?B?MXJNRmdGdUN0L25hQjNoNk5SUnB5MlB5NWFqZS8yQUMxdG4vREhoTWpNSTRL?=
 =?utf-8?B?TlBzenVxQzdnUDlFdzlIRHkyeldBYnNnTVQxcVZyNUJkMUxZSFNkU1JJRThK?=
 =?utf-8?B?SVlHbWpQRWFKL3VIM2o2a0FySTk0REtvYXBoa3YrWEkxNkFJNDAwYkFEa0ZQ?=
 =?utf-8?B?WWZSTmdTUHdNU1BXTzJ2blpLeTMyT0t3d21hMGR3anp2aTJ0a05RWGM2SkZM?=
 =?utf-8?B?ak84b2VYd3hEdkZUNnlhQTkxa2VvQWZIc1lUd1lpTC95WHh3bHZLcEdPamkr?=
 =?utf-8?B?VFltK3BEU3VvZzdrbU5LVklqNC8xeWxabGNaSXZNNm1la0owOVJjMkoySk94?=
 =?utf-8?B?dEV0VXZGdnpNQmZJd2Y2TXNmN3FSWjFmaTRaN2RETVdQR2c2bENndEo0YlZO?=
 =?utf-8?B?eUgxcGJYYWtBM3hkaTdqcEdTMWNiNlZHdTZuM2FJb3VhSERZNytzbVRVNGx3?=
 =?utf-8?B?WTdSMzAvUTY2RDRwTnNMcmZXL2xJa1BiREZwUnprd1JOS2dpZ0s2aFo5d3ZX?=
 =?utf-8?B?djdZVlo4R2JHSTNmbTlHNTc2bWhubkQrV01CSFA1N2lKdlkva3Z1UzBZK0Jp?=
 =?utf-8?B?elYyamJQWXh3V2lUZE9ZMktubVhHeXRva2p3YmdBaTRiT1FXc2RaVGFVWHc4?=
 =?utf-8?B?dzgwaHhCcm1QRW5ZU0tueGEyMEdybUFBVDdpMG9JdlROa05mTklQT2RuUXJq?=
 =?utf-8?B?djZ0UlBURnR0WEMxM0tzNWg1L3EyUmNxaWNsTU5JSnkxYzBFY3ZkMDFRTVU4?=
 =?utf-8?B?eUlaVWpvVWo4Q3o3b0NjV2ZYUm5kTDRMTnZYYU5HNnE4RVJRUW0xU0J1VlZG?=
 =?utf-8?B?dnVncWJ2b21BTE5XWHRSV0RoRlhxL00xaDNaOWIwRk02cUdmOEVwS3dPRzRN?=
 =?utf-8?B?aE9QZTQzQ1ZLdGRLM2ZOYzIxREE5RndWM3l1aXF3L2NwQ1BGSk90WThzUDRM?=
 =?utf-8?B?L25xVlRVMVBSZnFsUmNhZXBHeVRvdi9ZZFhJUk9jVGZkcHhhMHpJTnd2V29s?=
 =?utf-8?B?SzlvZS9SM1lPdG9tYTZralFHWE9QZ1hWV0dvdE5SQ3A5VktoMXNiQ1hUOElp?=
 =?utf-8?B?S3JsQS9ZSHdxdElPWGMyc1ltQkFnaHdWcjR2WjNLdWdXMEdzQkZ4TG8xNHZs?=
 =?utf-8?B?K0hEZ20zMEVpM05YVEZmYzZtQ3pwaU5YOU5jbmx3YzJwb1cySHRLempoeVFs?=
 =?utf-8?B?RG8vekdKUUxXSW5kZlRvd3dwWktjRk92RnBhSmNYcjQxdS9WLzRUcGhnZWZW?=
 =?utf-8?B?ckVUdHFUY1lpa2ZLcmVxV294Y0J2NWMzRUJPbUpUNVkxRTB3ZVhSLzRheHBS?=
 =?utf-8?B?ZGlPTzgydTdtYW1JYmVoUG9Jbzgwd0pZaDZKL2FCZDk3clZUQ1NTOHU3VUpn?=
 =?utf-8?B?WjNNWlQzbHlrdHI1MDdjdTNMK0NTVjI4N1hCVFcvckhObFhDMVEraWltY0hu?=
 =?utf-8?B?V3Q1TE1qMnpvTlg3NHRETTNIb3JvOThpMlUvQk9zQ1UxbDBDWGJEaU0wbzlh?=
 =?utf-8?B?cjMvTEZoVGh3czM0eFRyYW8wL3V3enVONzlZbUpOSG1MYWVhelpEcG1qa3kx?=
 =?utf-8?B?OFJOZ3M5cTdxM0tkWGlYbVlBYnBEeGRSRTczZFBOajBMYU5iZGlEZUV2OGxV?=
 =?utf-8?Q?puW2c/oycxZeqHE1z5pWJUfrGYUBK4=3D?=
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?ZFNFaVlTelpsZHJCYktYcmdNSDl1TkRMQUhFakw1OExqSEZxYzYrWjZMMmxK?=
 =?utf-8?B?cU00WUNkSnp2SWxpMHhNUGFYV0NlMTNMQkhUNFk4RjhwdHBaL2lnZkVyWXRO?=
 =?utf-8?B?T3lLRmhhK29pL2RIOGFXNW55QmY2TlQ5Yy9UTG9CQjQ5QUw4dmV4R2N4eUJ2?=
 =?utf-8?B?Ym1wcmE4NlI0c0k0M1ZubWFBZWo5MlZhUVVNYStkeXJ3aHVROTJHM3BxYzU1?=
 =?utf-8?B?d0JrL2FUSUdHbXN1SlZ6Z29LUVJ5VThOc1g2VkhremFGblMxSkNHd21nVWFz?=
 =?utf-8?B?cEk5L0p2QkRBS2Q2SStSNzJpUnEwQ2pvUEQ5UnA3aUYwcGRrOEUvcHBoMUFo?=
 =?utf-8?B?WkxIWGpmZkt0ZTczMU9SQURlZEl3eTRETnBTSkZncmhzbDdKTStpTUEwalJ0?=
 =?utf-8?B?Z1o5S1NXL09VUVZwaklDNTFrakhKT0s3YWEyekk4SC9velVOU2FTRUV2a2Vr?=
 =?utf-8?B?ajkyaENodzhGN0JLZE5KdElvR1JGSEVCVldsWHFhZkZPOExlbmVPUjlCNURn?=
 =?utf-8?B?RGdYaXpQTHVuMFFreFZnZlBkdkludmN6aHUwZHdqMDRCa2dsam9peTB4VlQv?=
 =?utf-8?B?dThic2x2WXdNekU5Qk5iOWhDRVlGOFdPOFdvdis0ZElHNFVNb05VTW5VWHBB?=
 =?utf-8?B?VEQ1ZXNobm95SEk5UXhKU210dWgxek9veWpocXVndkVpeXlZSVF6QjhvNlZo?=
 =?utf-8?B?amhialplVktzTFluWWZrZVpwbXNwcnlOWDFXdkEwbFNJZkhrcDlsM0lxU211?=
 =?utf-8?B?KzRWUkh3VnQ4MHpTZ2FmYmxCeitRcWNQb0pjTXNrNkhLOGxCQ0FkQXA5ek9y?=
 =?utf-8?B?NXlnRThHOWRhclZOVDlYbkE4YjBrcUNrdXVLa2xtakVGdFdQODRtb1k1WEkr?=
 =?utf-8?B?UnJ1TVhMWVZFWVdGNGd4VUd5czBZa29UY0JQb2ZGWnJ1STFCUzUrS3d5WEF0?=
 =?utf-8?B?ZENkOUs2UVc2TFhoMHlXTjVMMXg0ZERuaTVkcDlrRjhBVmVLTDl5NjhINmE2?=
 =?utf-8?B?NDJoRDFlRUc0YWJJMXJHYWZ5SllGdWxlRmU5ZkY2S2thOHFTZHFhNHBCTTJj?=
 =?utf-8?B?dUl5cEtMbUVtNTNMbDhuVk1yU0QyQ0VIK2RyaStQRUd0MkJ0MVZVYTAzRW1k?=
 =?utf-8?B?R1F4eGlNcTFRc3p4cmtZMitpcEJrSWw3YkZuSlkyUHhJK212TzFPTWh1NzJR?=
 =?utf-8?B?UEpRcjluelM2ejVVejF2aWxmdytqa2t2dlNMQjBnblJLQ09Kc2RhZC9sOFBB?=
 =?utf-8?B?dlQ3WkdNSHh3VWdON1B4YTJySHpBMTgzNmVIUzBlRlVHaklvT1YyVXBYb3ph?=
 =?utf-8?B?a21vOGpQUTdjNDJlZUNEUDhCQ3FCeFdZZVA1VFBicHNhTFgyZVlzWnJ2TXFk?=
 =?utf-8?B?ZDNaWU4wUVdmUjFCckFRVS9Sc2tNSW5mdWxhS3JtdGdpRW5Nck1Tek9NaWxK?=
 =?utf-8?B?KzQ3THppWkZ0VG9SQzBGZktFejdta0N0Y1hPYkxNWnZWN2tSZU5lSXcrSHQy?=
 =?utf-8?B?a2oyTm9jWlpQK00rVnR6WFNzMENnY3lRWmc5YlFzWEtPdjk0Y3lDbm9leFRv?=
 =?utf-8?B?UnMvTFR0K0Vaa0hkeDRITytSa3NGQlJiSjQrNDd6ZkJPMURIckxpcVlWSUcv?=
 =?utf-8?B?bUhtMnJGeDZWbmdGYW9TcmJEcjJ3TGhvOVVwRVNBZFhnVnRlbGdMYXUyVzU0?=
 =?utf-8?B?NVlTWC9kWVhtWHV3ODFrblVWSVR6L1Ivblg1cmlIUWZ2MXp4Tm9PL3o5Sklt?=
 =?utf-8?B?MWFiQSt2YXdybVVZS1VOUTQ4eitzMGFQNVZaUGhNQWJGMVowRHM5bnVtdEV0?=
 =?utf-8?B?cW8zZ2pGYTNTMktTOUMrb0FoT2h5ODBRQ1pUU0dCcUdkUGhvck5qMjd0RGtv?=
 =?utf-8?B?dDVGVGppckJNZlgvM3dmV2VGL3Q2QVJHL1FUT0k1YzV2NXY2QlFWcmgrMjRE?=
 =?utf-8?B?dmhlMXh1OFdDbjhJdnk0R3lFME9iYThTTzFFR0ZIcFhnSmpTRjJEV3JSaTBX?=
 =?utf-8?B?NUF6MVo0OE1KalJ2MnhqQXgvbi9NZTY4UHdrRFJqc1dtYVJIQVl4RkJqWEJj?=
 =?utf-8?B?YTRTQiswZXlFOWNhNU5LWFh3TE9HOC9rNGkwdVVTTXFxVkZaU2lOcFdJODF5?=
 =?utf-8?Q?PLTg=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <253095774D72644A83BE4B68165AD830@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: 4d68c18f-b84f-463e-b6f3-08ddaf02a292
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2025 07:26:40.8165
 (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: 7FQUKEG9bttdBz2kTn6mrEqthBoMWc+js/bePRjeoI09Uear2JeodTq6WBfLswj1Cgcycz5YxOb1L8kyauxj+A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW6PR12MB8913

T24gMjAyNS82LzE4IDIyOjA5LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMTIuMDYuMjAyNSAx
MToyOSwgSmlxaWFuIENoZW4gd3JvdGU6DQo+PiAtLS0gYS94ZW4vZHJpdmVycy92cGNpL3ZwY2ku
Yw0KPj4gKysrIGIveGVuL2RyaXZlcnMvdnBjaS92cGNpLmMNCj4+IEBAIC04Myw2ICs4Myw4OCBA
QCBzdGF0aWMgaW50IGFzc2lnbl92aXJ0dWFsX3NiZGYoc3RydWN0IHBjaV9kZXYgKnBkZXYpDQo+
PiAgDQo+PiAgI2VuZGlmIC8qIENPTkZJR19IQVNfVlBDSV9HVUVTVF9TVVBQT1JUICovDQo+PiAg
DQo+PiArc3RhdGljIHN0cnVjdCB2cGNpX3JlZ2lzdGVyICp2cGNpX2dldF9yZWdpc3RlcihzdHJ1
Y3QgdnBjaSAqdnBjaSwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHVuc2lnbmVkIGludCBvZmZzZXQsDQo+PiArICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBpbnQgc2l6ZSkNCj4+ICt7DQo+PiAr
ICAgIHN0cnVjdCB2cGNpX3JlZ2lzdGVyICpyOw0KPj4gKw0KPj4gKyAgICBBU1NFUlQoc3Bpbl9p
c19sb2NrZWQoJnZwY2ktPmxvY2spKTsNCj4+ICsNCj4+ICsgICAgbGlzdF9mb3JfZWFjaF9lbnRy
eSAoIHIsICZ2cGNpLT5oYW5kbGVycywgbm9kZSApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIGlm
ICggci0+b2Zmc2V0ID09IG9mZnNldCAmJiByLT5zaXplID09IHNpemUgKQ0KPj4gKyAgICAgICAg
ICAgIHJldHVybiByOw0KPj4gKw0KPj4gKyAgICAgICAgaWYgKCBvZmZzZXQgPD0gci0+b2Zmc2V0
ICkNCj4+ICsgICAgICAgICAgICBicmVhazsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICByZXR1
cm4gTlVMTDsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIHN0cnVjdCB2cGNpX3JlZ2lzdGVyICp2
cGNpX2dldF9wcmV2aW91c19jYXBfcmVnaXN0ZXIoDQo+PiArICAgIHN0cnVjdCB2cGNpICp2cGNp
LCB1bnNpZ25lZCBpbnQgb2Zmc2V0KQ0KPj4gK3sNCj4+ICsgICAgdWludDMyX3QgbmV4dDsNCj4+
ICsgICAgc3RydWN0IHZwY2lfcmVnaXN0ZXIgKnI7DQo+PiArDQo+PiArICAgIGlmICggb2Zmc2V0
IDwgMHg0MCApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIEFTU0VSVF9VTlJFQUNIQUJMRSgpOw0K
Pj4gKyAgICAgICAgcmV0dXJuIE5VTEw7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgZm9yICgg
ciA9IHZwY2lfZ2V0X3JlZ2lzdGVyKHZwY2ksIFBDSV9DQVBBQklMSVRZX0xJU1QsIDEpOyByOw0K
Pj4gKyAgICAgICAgICByID0gbmV4dCA+PSAweDQwID8gdnBjaV9nZXRfcmVnaXN0ZXIodnBjaSwN
Cj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5leHQg
KyBQQ0lfQ0FQX0xJU1RfTkVYVCwgMSkNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICA6
IE5VTEwgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBuZXh0ID0gKHVpbnQzMl90KSh1aW50cHRy
X3Qpci0+cHJpdmF0ZTsNCj4+ICsgICAgICAgIEFTU0VSVChuZXh0ID09ICh1aW50cHRyX3Qpci0+
cHJpdmF0ZSk7DQo+PiArICAgICAgICBpZiAoIG5leHQgPT0gb2Zmc2V0ICkNCj4+ICsgICAgICAg
ICAgICBicmVhazsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICByZXR1cm4gcjsNCj4+ICt9DQo+
PiArDQo+PiArc3RhdGljIGludCB2cGNpX2NhcGFiaWxpdHlfaGlkZShzdHJ1Y3QgcGNpX2RldiAq
cGRldiwgdW5zaWduZWQgaW50IGNhcCkNCj4gDQo+IEkgcmVhbGx5IG9ubHkgbm90aWNlZCBpdCBp
biB0aGUgbmV4dCBwYXRjaCwgYnV0IHRoZSBxdWVzdGlvbiBhcHBsaWVzIGVxdWFsbHkNCj4gaGVy
ZTogQW55IHJlYXNvbiB0aGUgZmlyc3QgcGFyYW1ldGVyIGlzbid0IHBvaW50ZXItdG8tY29uc3Q/
DQpXaWxsIGNoYW5nZSB0aGUgcGFyYW1ldGVycyB0byBiZSBjb25zdCBvZiBteSBuZXcgZnVuY3Rp
b25zIGluIHRoaXMgYW5kIG5leHQgcGF0Y2hlcy4NCg0KPiANCj4gSmFuDQoNCi0tIA0KQmVzdCBy
ZWdhcmRzLA0KSmlxaWFuIENoZW4uDQo=


From xen-devel-bounces@lists.xenproject.org Thu Jun 19 07:52:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 07:52:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019774.1396273 (Exim 4.92)
	(envelope-from )
	id 1uSA4C-0001m3-Jf; Thu, 19 Jun 2025 07:52:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019774.1396273; Thu, 19 Jun 2025 07:52:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSA4C-0001lw-Gv; Thu, 19 Jun 2025 07:52:12 +0000
Received: by outflank-mailman (input) for mailman id 1019774;
 Thu, 19 Jun 2025 07:52: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 1uSA4C-0001lq-29
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 07:52:12 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20625.outbound.protection.outlook.com
 [2a01:111:f403:2413::625])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4de5e4fe-4ce2-11f0-a30c-13f23c93f187;
 Thu, 19 Jun 2025 09:52:10 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 IA0PR12MB7700.namprd12.prod.outlook.com (2603:10b6:208:430::20) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Thu, 19 Jun
 2025 07:52:06 +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.8835.027; Thu, 19 Jun 2025
 07:52: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: 4de5e4fe-4ce2-11f0-a30c-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=hMXI8aaUINWHVWpNXWFVRd/gzbjzEEEQtGFLleGKreNLaphzYT3W9UMMv2HOPJYxqiJfa+HPheWvF30rrHCczu2LQao8pYzPIY4OZ9jCVHVCQDgPAvQEAG4hAAO3cdBO+9yICrTjkiuRVM86vJi2j7vjaq0+jiiusgrqshNU2VA5513bYCf0AvGP6W3Pn7ifkDlGQWEOhaEPS7tyXwiDrVkUQbgizOYZlD3m8ksB5hWQO+8dy4DQAMG55MKaktxknYcGHmohNj09H+ZBiWwFJvK3qVpxuWJ1xtREVjpNGMoivvUHMaWb1Ltn7SLQPIFTCNZGNulqlIQ6JRNuZn/rGw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=FiGHkcXSGFGRRShXVoDSJ7totaxv6WoEg6qrDeU4hZI=;
 b=POh5x8PraMUZrSQfv0AddSHVKWQlPR31D7IBoBXtWN2hv/NbVHDS+JQ1XCTCWIYQOB+LPBqCQHhoxgPR6QYWM1IPre37U4m5Zb+mM6sPk4vnmsVSgv+bZ3TlJHAW2v4bz1pzkAldmZFH2pyVoqW5PPmNfajaLu2drPQ84FFaqoVLC67+nEsLz6Sd19cu4i4Cd/toayD98bJpmeHmwRzp5ry7GvtH6VoQhIzYA5+mOjuj8ACFHclVN/wvHZRgFTWdcsKWTSi+JYxR4D6U7mrmU703ZUGj9fp9Zxi6pXIHRR0DHF7AADBJfHeHOtFS27H5AtlNigUPmd10BCnubRlq+Q==
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=FiGHkcXSGFGRRShXVoDSJ7totaxv6WoEg6qrDeU4hZI=;
 b=g0Jxhxkkx8a81fSveCkd0Fup/C5Oo3weETpNo1jjjZ3sxYVxbHYA/R9v5iKeiuJFf4nslD7YdhVRVwKCU7YnDGYME88i9Ic1K5B5PDko9L+h0TiaA30SiFLRh9GzaHegtAWZ3BX2YlLgkNX0j7/iCnVCkoxCAEFBtLQsTieeOPQ=
From: "Penny, Zheng" 
To: "xen-devel@lists.xenproject.org" , Jan
 Beulich , "Andryuk, Jason" 
CC: "Huang, Ray" , Jan Beulich 
Subject: RE: [PATCH v4 04/15] xen/cpufreq: refactor cmdline "cpufreq=xxx"
Thread-Topic: [PATCH v4 04/15] xen/cpufreq: refactor cmdline "cpufreq=xxx"
Thread-Index: AQHbrRCkbAdH8T2kS0OlR5huTdSxQbQKgmtQ
Date: Thu, 19 Jun 2025 07:52:05 +0000
Message-ID:
 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-5-Penny.Zheng@amd.com>
In-Reply-To: <20250414074056.3696888-5-Penny.Zheng@amd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=True;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-06-19T07:51:58.0000000Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=3;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged
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_|IA0PR12MB7700:EE_
x-ms-office365-filtering-correlation-id: 58080d38-acbd-4dda-53d7-08ddaf062fa3
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|376014|366016|1800799024|7053199007|38070700018;
x-microsoft-antispam-message-info:
 =?us-ascii?Q?MbBEDmDqXBNzjPPbXT66HzU/eUtZO8eLQ20odXNwrmZcgbCAdVEDh3wR/lTb?=
 =?us-ascii?Q?r87G9UpL1GEeUdYzOOrxwfX4LySzfqLM3m2X59U/WLmDkxd2Ct8NfsaYmIxo?=
 =?us-ascii?Q?qpdJTNS7eDWy5LeLgnoNlHjZGcBtEHEHD9PLt7g1YNboznS/MQ9D69jnD7im?=
 =?us-ascii?Q?90hgdo/33OTlac10TvEjpcM9LgMYfhAfnf48Ip7x/p2xHcUFUnaWZxveK816?=
 =?us-ascii?Q?EU1BZcrgI2v1QTEdF4JeqNumpfkrfMIJb124S58fKJZXS4dCSYbOpjdh+GNv?=
 =?us-ascii?Q?roqfvvblsZPdLbR2K4qxWhpInQoUn01CCAdq4kQZiY6xLdHbBIBf6nyM+Ylh?=
 =?us-ascii?Q?rmhhpUKtsTF6HgQ/5NSqDGmg/FrQwYaH/wbyED3MjNniArVRm0QtxFFwkBma?=
 =?us-ascii?Q?/6jGhPaCAc0IwxE5otRQEB9EyJEYO1/z94WvRV6MacojpUGiehDgysYpVix/?=
 =?us-ascii?Q?QN17TVqPqt8GIg7FyuA8VcmAKI2KK9hfoXKSrhW3pAJA/R+YbRG+KqhEpH72?=
 =?us-ascii?Q?2OFVXQ4pMITQblh5W52BpdLjGUtiJ2jgFQVyiwMA7lGu4zJav4ByZcxvGRd7?=
 =?us-ascii?Q?aH9FSC6GzbAE6s6M/kJsrUEsmEPo5jrxGvG7nm1Bban8qBxMsvlJXNS/+MaJ?=
 =?us-ascii?Q?vWSkkwxbnlKTeGJiNInLt1P0j26PTHXzm7yw053NH3IzSF+4ombbAqecTuqm?=
 =?us-ascii?Q?FEJAHV/RK9nLOkzGqLEKM5e9IABXk1lHfQH8h37ZqyA1vQLepysWxdl7iPyH?=
 =?us-ascii?Q?BOE3TGUIJ7K09EBVH0dQ4h90/v0LQAmlylu9dvmCqHEXej1bV0dPVl+goHxn?=
 =?us-ascii?Q?BqPREaq3b5I/3veC4cthOBrUlBlLuKzCWr+HkW8zp1cY/8P/IdehWjkHFehV?=
 =?us-ascii?Q?j9aQGKSi0CORXYtsL5sH9BTSnFn5NCue/0LxJvke+0VU0tyhiWhFkbscNZGd?=
 =?us-ascii?Q?SD91oX2cyQ5iavwHCyOG0D7c6V4qnXn4JL+wtFTfCeUVs5Wzqpgx52LMlSwn?=
 =?us-ascii?Q?XQqeot7/kgudsFH12lIq933JcWV0dVDzzs659zFKxTG/Hs2bWBxGlYfcDYRR?=
 =?us-ascii?Q?On4iRPjobozSEAaxP9o5Ng6gcrolreuqr5lbRrKTVWsYOJYVPdBTDXCT0/Ts?=
 =?us-ascii?Q?TiDkM61HRlPChPDb9mXyx57bpp1Za3EresGmA3wBWTranDk9qiL5OayfPG9s?=
 =?us-ascii?Q?QFxRM8DjeaZkP/X2B4rFxdMDeYv/98qASngS6ky0IXdOLhmklvgwRlfliqU3?=
 =?us-ascii?Q?wIdaLzPEgR+N7OPjhO7nb7mqWZF9IuSjTtDAhGgQo9cdODKJM92Vm4t8ZUsX?=
 =?us-ascii?Q?CUavPSN+w22A2eK5ha90DjsSqHK17QOSWw494CQKAl4xV0O+ZuMvo/Xeel/8?=
 =?us-ascii?Q?HE4nRfELp/KKVCUX3BNDXfAaSUiue5LDcr4Ms+pET6p5LpZ7isTk13JbzIWR?=
 =?us-ascii?Q?aHZvAn7j11ctOeIDtDZFPAZ3CoULL0Y50bOr3Meb1Cyam7iHdYvNIzK9XCGI?=
 =?us-ascii?Q?1mxPZVvMuw0KnEA=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)(376014)(366016)(1800799024)(7053199007)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?PdClTdNVDze5iRxob/ihaByLm4FaPmtrReGHP11yiM+uBwzR07L357mu8rnO?=
 =?us-ascii?Q?faZ4JsOP1qz6Kd+gxlndryf/pE8xZD94J1TcEXKi58OK5bnRibOrgAxYRBJo?=
 =?us-ascii?Q?h7880plrtiUU7KCo/DdeXbGXawjvvssr4Y4cGFY+RuV8qkyjffg8h2gD2yr2?=
 =?us-ascii?Q?95uvGRGIlyzciPYLCsauLWeO5aZLeaaSFfnmOdrbqXZTAsJYQWCs5Jd9CicK?=
 =?us-ascii?Q?G4a9swyxKtvImT4niU94HOqnt9RdhxN3AA+Q3GmjJOgPf+ykBghsb6lUkx6n?=
 =?us-ascii?Q?t4vjnWw59ILQkA2+NWfZxore6NnO9DABqyD7nbnuSR3qWg3nJe2i8UhkmgB2?=
 =?us-ascii?Q?fngHizv+P2CdTAtG+/+m17RGeckPRLnDsQf0oQx5ecgRr56ua+Y6I4e2vCj1?=
 =?us-ascii?Q?OrdzOCPRAUxCS3skQs9dE1AAbt/aMpIPu7vPCBCEdHGRsN/+dUU9gG20ehy2?=
 =?us-ascii?Q?oqe5C/kpxNY3ZxyDTdwtn1Ghbe1H/BzZ1uiJDvUC8xUYnkJUZoXD1YYWfxW4?=
 =?us-ascii?Q?EbWTQlBvuhJnjdJWomAbTVzrFyYXr1eaIZeJn7UE9Ndmy2lC1p6x/srjoAGW?=
 =?us-ascii?Q?f1aaOdppBuNGt4MmR9+OcMXJZLXaxMVpVqRIk41ftpYEyQn+Y3Bp9H10q9TX?=
 =?us-ascii?Q?WBdcLmXHmFN7zpLz/7FOtqlbsIrKSsF80KGRm+5dlThk5/vC2OWTFXZ5FJEu?=
 =?us-ascii?Q?BdFSIUYjPz0uSBo7sKOiVJwN0oNCtsOqeRcbC6+UsehFA2pCf6rtOpf0D/yp?=
 =?us-ascii?Q?PYJLAOBRX5OLuO7JmAAGvQts8Bb9ujY5ctaWrT0dL10HPac4WBM5dawp5wb2?=
 =?us-ascii?Q?lOVW3BI8wIskoewm/1mHtWgGBiG2ZFKQK+C+nbWkxoXbH0ej5911YanJKT1G?=
 =?us-ascii?Q?uZ9MDnFsruvxBEMjDHYitcRjOVsSk+1VBQUimqV4pdScoxfDjjUULQgPB6RN?=
 =?us-ascii?Q?izSv3O7Nzxxg5XM9nRvIxa77TCQ1GDm7mC1cOfpKEH63C++2BqJFiEV4ZCX3?=
 =?us-ascii?Q?kMrE7IqCLJQYTHwRNqNzxx+Zw5LCOAUTr3vP9sqT6gI703NO2mg5hKkUZunn?=
 =?us-ascii?Q?nbpYM5R19MUX72SpGJgNVD4jtjZo557ta7i9HlbK5qYSafPMy8HUDTsuEzAI?=
 =?us-ascii?Q?BIg04VgbHNK1o6q66jdX89tIYIQc/HHzpFSGXhkHwO2FLaucJGGzu1h0sWuD?=
 =?us-ascii?Q?AlafNqlDEi77YjadQTkxomcSYZSGnaYGBAshMe+ksvhO4qOGXjAr5+o8pE+i?=
 =?us-ascii?Q?uF1Ss6b6OIwMAVCwBNEczF26v9hks4jixSM/7gpOZmyX5y1WQFlGSPGVq/6s?=
 =?us-ascii?Q?A9io2uCLbPM5tdT/R/N2kQz76QfYmSb1dMc4Dv91lKdSiN8I9/ASiPcNqVCT?=
 =?us-ascii?Q?0NsZyD5f+WLT3TQQwVfS8OD4+aIvxqf/sC0/liRzBukaKwKI9t/4EsywhonS?=
 =?us-ascii?Q?2Vj8nfGFXdvAjxM4TIti74cOLDGJtzl5Y4rDH8L6MNIjaV3+73g+3xJ2w1+w?=
 =?us-ascii?Q?Vt0MFZmiTHvZEiGPcjjxssUkxAwy3+URKeH3Dnp1GJcQJN6MsqlOOqCCVxE7?=
 =?us-ascii?Q?AD9XBcC/CkHyCRccR7k=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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: 58080d38-acbd-4dda-53d7-08ddaf062fa3
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2025 07:52:06.0040
 (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: V+3Jrc2CgHNW0q4AqsgLJJnXTPkZ+m/QLGazRxmZS+xEPWFHxklFOD/qCMCh1kyeCTlwjkt7xgr4xgfAL5NoiA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB7700

[Public]

> -----Original Message-----
> From: Penny, Zheng 
> Sent: Monday, April 14, 2025 3:41 PM
> To: xen-devel@lists.xenproject.org
> Cc: Huang, Ray ; Penny, Zheng
> ; Jan Beulich 
> Subject: [PATCH v4 04/15] xen/cpufreq: refactor cmdline "cpufreq=3Dxxx"
>
> A helper function handle_cpufreq_cmdline() is introduced to tidy differen=
t handling
> pathes.
> We also add a new helper cpufreq_opts_contain() to ignore and warn user r=
edundant
> setting, like "cpufreq=3Dhwp;hwp;xen"
>
> Signed-off-by: Penny Zheng 
> ---
> v2 -> v3:
> - new commit
> ---
> v3 -> v4:
> - add one single helper to do the tidy work
> - ignore and warn user redundant setting
> ---
>  xen/drivers/cpufreq/cpufreq.c | 53 +++++++++++++++++++++++++++++------
>  1 file changed, 45 insertions(+), 8 deletions(-)
>
> diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.=
c index
> e01acc0c2d..79c6444116 100644
> --- a/xen/drivers/cpufreq/cpufreq.c
> +++ b/xen/drivers/cpufreq/cpufreq.c
> @@ -71,6 +71,49 @@ unsigned int __initdata cpufreq_xen_cnt =3D 1;
>
>  static int __init cpufreq_cmdline_parse(const char *s, const char *e);
>
> +static bool __init cpufreq_opts_contain(enum cpufreq_xen_opt option) {
> +    unsigned int count =3D cpufreq_xen_cnt;
> +
> +    while ( count )
> +    {
> +        if ( cpufreq_xen_opts[--count] =3D=3D option )
> +            return true;
> +    }
> +
> +    return false;
> +}
> +
> +static int __init handle_cpufreq_cmdline(enum cpufreq_xen_opt option) {
> +    int ret =3D 0;
> +
> +    if ( cpufreq_opts_contain(option) )
> +    {
> +        const char *cpufreq_opts_str[] =3D { "CPUFREQ_xen", "CPUFREQ_hwp=
"
> + };
> +
> +        printk(XENLOG_WARNING
> +               "Duplicate cpufreq driver option: %s",
> +               cpufreq_opts_str[option - 1]);
> +        return 0;
> +    }
> +
> +    cpufreq_controller =3D FREQCTL_xen;
> +    cpufreq_xen_opts[cpufreq_xen_cnt++] =3D option;
> +    switch ( option )
> +    {
> +    case CPUFREQ_hwp:
> +    case CPUFREQ_xen:
> +        xen_processor_pmbits |=3D XEN_PROCESSOR_PM_PX;
> +        break;
> +    default:
> +        ret =3D -EINVAL;

I'm thinking since handle_cpufreq_cmdline() is totally internal and has ver=
y few caller, maybe  ASSERT_UNREACHABLE() is more suitable. Then the functi=
on itself could become void return.

> +        break;
> +    }
> +
> +    return ret;
> +}
> +
>  static int __init cf_check setup_cpufreq_option(const char *str)  {
>      const char *arg =3D strpbrk(str, ",:;"); @@ -114,20 +157,14 @@ stati=
c int __init
> cf_check setup_cpufreq_option(const char *str)
>
>          if ( choice > 0 || !cmdline_strcmp(str, "xen") )
>          {
> -            xen_processor_pmbits |=3D XEN_PROCESSOR_PM_PX;
> -            cpufreq_controller =3D FREQCTL_xen;
> -            cpufreq_xen_opts[cpufreq_xen_cnt++] =3D CPUFREQ_xen;
> -            ret =3D 0;
> +            ret =3D handle_cpufreq_cmdline(CPUFREQ_xen);
>              if ( arg[0] && arg[1] )
>                  ret =3D cpufreq_cmdline_parse(arg + 1, end);
>          }
>          else if ( IS_ENABLED(CONFIG_INTEL) && choice < 0 &&
>                    !cmdline_strcmp(str, "hwp") )
>          {
> -            xen_processor_pmbits |=3D XEN_PROCESSOR_PM_PX;
> -            cpufreq_controller =3D FREQCTL_xen;
> -            cpufreq_xen_opts[cpufreq_xen_cnt++] =3D CPUFREQ_hwp;
> -            ret =3D 0;
> +            ret =3D handle_cpufreq_cmdline(CPUFREQ_hwp);
>              if ( arg[0] && arg[1] )
>                  ret =3D hwp_cmdline_parse(arg + 1, end);
>          }
> --
> 2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Jun 19 08:01:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 08:01:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019782.1396283 (Exim 4.92)
	(envelope-from )
	id 1uSACm-00041H-Gn; Thu, 19 Jun 2025 08:01:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019782.1396283; Thu, 19 Jun 2025 08:01: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 1uSACm-00041A-DL; Thu, 19 Jun 2025 08:01:04 +0000
Received: by outflank-mailman (input) for mailman id 1019782;
 Thu, 19 Jun 2025 08:01: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 1uSACl-000414-4j
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 08:01:03 +0000
Received: from NAM02-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam02on2061c.outbound.protection.outlook.com
 [2a01:111:f403:2405::61c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8a8c050e-4ce3-11f0-a30c-13f23c93f187;
 Thu, 19 Jun 2025 10:01:01 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 CH3PR12MB8510.namprd12.prod.outlook.com (2603:10b6:610:15b::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Thu, 19 Jun
 2025 08:00:57 +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.8835.027; Thu, 19 Jun 2025
 08:00: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: 8a8c050e-4ce3-11f0-a30c-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=taZgPzP7Y9O/tuEIrke3Xk7usHtYChTnc5EZjx/vmWv5FXwpHwV87z1tef7vv4/JmsDW4CUixpcdvXV+pDJSAj+G0mHxXJa1In3R5qZIAOOeO+i9erx88H07aUUndpVkKA/OMqQbgFDUdft6z8qnQIGEy2h5jz7wCAP72Dt4olUO7FZAvwzxbcLmMj6t8lX2OrnXH904kS9HkzUXYXX3OlXSo/KSTS2XO/sRe7wNdZAZeXj0efjZyjUC11+HxwqdlhD+Xr8B2Vc9uCd4dGJjWPK2c/revjQcgPeqayUnosIZ3wLXi4LhmeIkP+5rYRdb/+f8FLubCY95urSyN9hKKA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=7FEjwGJzYrfEAklclyCSkxTAP/bUHEyPFdkZtY9WdDI=;
 b=XXveS277N4oY9BqtvC21ZvYskuBcgs3ou4Si/N4EuXsGwhbS92bMNseu9vvChjs0PQzJg4gUrN/4Iz4pTd3V8d4sHeFKSphANsuIa4Q+a+HSifY39slYj0y+TYnMdzRXqH9fJNrPlSbbPBab7BozGLWYP18QY5CyEpc25+TUu/dXQhaLiKVES9dw3/271gdfXF3W+mLZCrzKzs3sch83cbfpvtl6DnTr7ROtVmz6c0Uo/5fIcbee6SyhjQcRJLBKGreRM+RTLfo4MCticEjkpMzTNFO5KXChsQ8ZJvMk7avMB1AX/FiXellMNImlsCtR9RgR4nSd9E+tm3oneYIuvA==
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=7FEjwGJzYrfEAklclyCSkxTAP/bUHEyPFdkZtY9WdDI=;
 b=W8U4VxmRsuWmMwhLfwVGHPE6PgV9IFOQ8yO6qowHMGeC34i/QCFxNw6MnAEcyp2+ybtDP/E+PRJG3Dh4xvegb2oxO3f+AqGeQooSh2AV7/wfF5ctksr02tRFNe1QG0aJRISMWjBQd1zy7v2hZ4SDg+oaEw0RRIRRnRQmFZg+Lso=
From: "Penny, Zheng" 
To: "xen-devel@lists.xenproject.org" , Jan
 Beulich , "Andryuk, Jason" 
CC: "Huang, Ray" , Jan Beulich 
Subject: RE: [PATCH v4 04/15] xen/cpufreq: refactor cmdline "cpufreq=xxx"
Thread-Topic: [PATCH v4 04/15] xen/cpufreq: refactor cmdline "cpufreq=xxx"
Thread-Index: AQHbrRCkbAdH8T2kS0OlR5huTdSxQbQKgmtQgAADmcA=
Date: Thu, 19 Jun 2025 08:00:57 +0000
Message-ID:
 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-5-Penny.Zheng@amd.com>
 
In-Reply-To:
 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=True;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-06-19T07:51:58.0000000Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=3;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged
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_|CH3PR12MB8510:EE_
x-ms-office365-filtering-correlation-id: d743af1d-1311-4b9d-7a41-08ddaf076c84
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|366016|376014|38070700018|7053199007;
x-microsoft-antispam-message-info:
 =?us-ascii?Q?16NWqRR+1XK/B8+xQurh6VHKsLNVADqyHTkx36EaMGa9OFSvWgx4xnp5Pyna?=
 =?us-ascii?Q?aqYK9+dOjeB64bV0ZEPjPT+/g/MWAOar3w2cMKruZq1q1q8kCwYKwcx4NG1W?=
 =?us-ascii?Q?Mmg/lG0TELwWZtqU0GwpvlMgyfrJSmvO/MEabbBIZd9jZTwIU0m6SJtP6xKI?=
 =?us-ascii?Q?Hl7LVo3ambIrTTJY+EUXwua0HjFwmdjWnC0sB57Q3wndonPSgLl0y8t8+QTo?=
 =?us-ascii?Q?Jm0NgzMj3rYkcEigQigvpc3ElPSWPud6Y/20W1ZI5SYAY96vi/hB2sMF/heC?=
 =?us-ascii?Q?uHLnpyx7wkq2SA7fTEgHb5Ljk0AOX99bq/nfuOV3s4T41r96Oc9CBwqw0UMI?=
 =?us-ascii?Q?is5qV9mFrAA3A7J5JXex6ol7k1gE1K9bXRQGp5hDxptRg8pv8KG0S6fSN8Ok?=
 =?us-ascii?Q?yPnfuA2OGX+p4TQw89uNWtviNNqvhQgBkLTq6vWdCT/h/EpoifovAEz7rfFu?=
 =?us-ascii?Q?p2DY7U8lXBSQTns7J8zOt+kbZHzaf1ldzmBM7r3xXb77YwXHwsYhBtwdSQXy?=
 =?us-ascii?Q?EiLj2MIJoKIfoDDzPHL/ec91W1uWTesHCBj9guQ6y1RVD4j0Z+9BpD//hfKq?=
 =?us-ascii?Q?U+jJucfiO2+xJn0ibOds+wnjA0+o4R+7uLPudFEmJo5IstU7cBfwrHleB5bc?=
 =?us-ascii?Q?VwLuu0dOYO+7hhJaY8TtuQfNFB3iK4tTt31p2ancsDDNosUWbpNm8kgcEDqj?=
 =?us-ascii?Q?SvIZR+wd6FUuAw/HRxupj5PPrz0wnxCxFtJcorBC/zBMGuYnVBDceJlVVxXr?=
 =?us-ascii?Q?CQsV4CEylT+yDKBmTZUxC0lExoCBCqRRqrS+TOT1wCuTcgj7Lb7hgysERfiE?=
 =?us-ascii?Q?ZJ15BH108KcTW2u5Qw5UVeyah0Gv2GJUmEueCdAfiuy5zGdg2r2j8UdFOri3?=
 =?us-ascii?Q?DFYT6NvrSHSrSI1pAoAutUmAMeiWQABfibmF+PfL05wT1JvNq4Eejf0bJjaO?=
 =?us-ascii?Q?RgkqbpUrXBcGGv2RxN+dI7d7fkNRwYrg1mvXxshqynh2xR6noC7foxYIommG?=
 =?us-ascii?Q?QB0PmKKxN3NDALfGi8Bx9KZ1sUaPwwkZ8tefvCdvnew5vvlgu1LjA+5od/fs?=
 =?us-ascii?Q?+G+JFXaE8jxBmxVOc+DH/8Cc0n0XOfFrYLZxrglSCZ5dEIG25DbZKvGkT+OF?=
 =?us-ascii?Q?swwTU6sP81U90B4HkdlXguLNYaLRGt27xWlhR3MU/4mQVF5S0inIDEVfBPag?=
 =?us-ascii?Q?PlED3yQ3IeykhSWQlS08jrG9CWUfLLAvJKCJtRi/CneMhqGG78oxnmDnmZzp?=
 =?us-ascii?Q?ag/fRnZNRV14jkpc/QiBP8dpDX7A5BarSMFukwREyPjy9xuuOCgnV0lJr+4B?=
 =?us-ascii?Q?89hovbvtQtqOV0SdhGt/XSIehNIlVJgUhysug8Z9Ka1pbOvkG6XxTdepJfRJ?=
 =?us-ascii?Q?y/KMRDwMvK5CMdIsaQhKHo5qOt7737CMtaDrPnbW/w8/bRJZstqeNw2sc+Oj?=
 =?us-ascii?Q?d12ifOmcJ5IEOfBfBCK713lzhU/F1GBjkkfIz+HKqanh3nRdYwviYRBEV4Y0?=
 =?us-ascii?Q?tT+dFgySTnUbHNs=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)(7053199007);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?bQizx2GgXE+ny44fKLHpMbEFaC5Bz0J/rr7UM3oXKE8ZRUUY6DSaLV5VhSlI?=
 =?us-ascii?Q?oROrS8RoP/zztnw7zxEopTEh+n9TzdDq4+xqoYCqm03W+lwM4Exfk37cf+Sw?=
 =?us-ascii?Q?D5uKNv3Ytlq6Zb7O/stOdsapRUbHlhB7X55KjXJSS0fLR3UKU8zL859Uim3Q?=
 =?us-ascii?Q?SLzB5QkF2e+mx4Q14I4t3JqU/QxWSf5k2rAmnxF6xIBpbIQsqit1tE5gl+SH?=
 =?us-ascii?Q?Ls7gF8YatZ0vLErgcldx7r6gQOKJfL50fww6DVyI+WhbWP8ZeuHbjr9ep1pM?=
 =?us-ascii?Q?yhGwVsDf0IlICRF7YbsAg4Knyy+3d9HK8By4T4ccvxU1+/3iso+F2y1nxwCm?=
 =?us-ascii?Q?ppJRLdN2Ql5k9WC949ruj0dOfScxtW/6lAMGHmf99+L/JN8Ch/ZZNK3qNGU5?=
 =?us-ascii?Q?ClTWNGGwkvyFdxqiRS8qnRfMZ7K/ArPGcRMweX/UzGHPw36opKPmKkzElrP4?=
 =?us-ascii?Q?iZJFv+wY2p2MV7YqlFjjSVBXHs6TN6L0sCpBXx7MM16kROMd83e4QoTAKgdL?=
 =?us-ascii?Q?tQ7bvAh9OLv3P8WObpP7f22kOFIIKaAscfnbR8xlcA6ANE7+TNr1qpKJ/vsK?=
 =?us-ascii?Q?kdHUE+N6M5lX7J76QI5ngYxsbM/53EdBPJ11KTBMpthuox/klnx2D720noBh?=
 =?us-ascii?Q?9FVFriiVdvDqoIWX4288hLiajacD4XTXbk9rJV/RXZGYPBrdLdW5OiK3/TiS?=
 =?us-ascii?Q?evgaPJN6dUXbl+fy5lczSKWu3gmzy5ky2c7SR7j3zzo54QfqoOFucQ6GF62z?=
 =?us-ascii?Q?+8aT+vAPg2pHX0yUUjctcZj/HJa1dKynuNFpJzK5fITWhDkkaL5xNyqJuEvw?=
 =?us-ascii?Q?TPjM/uMOY+hA3ufotQRC0kjHY0RoaG30M3fpmZ2VMhKcQZWCOchTFLENOxsp?=
 =?us-ascii?Q?tYaPoXlbTNW2nvUcdLSb3+5MHiHkkaBILSkshmL3slqX6XgisVXmsOocHA5a?=
 =?us-ascii?Q?eWuor3L2k3NNH+sJ/UYfAbntnYEaaE/u7FaRKEonQlAOCnkvCOExCFWBYIhY?=
 =?us-ascii?Q?VLR3cSWM2EauO9AalSls+cZk2/Uoc/3QLlGAPr3PT8aYAsp4HHxp3n6uzHgl?=
 =?us-ascii?Q?b90gD0e86MbOgqq0QDY7lBPOK2al5KqaGDR7L3Sh2Wb8T99MVknVXTBnxqFh?=
 =?us-ascii?Q?P309oMsujENgeVzMPffkjZA7NzavVvwXkfaad/z0I7a0j4l7nO35BHVi44Vd?=
 =?us-ascii?Q?uZu7xAWYu1IvCcPdnCMV93rucbTuMbdqNXe2U7amvYF4IW5xcYQzm6MWRvav?=
 =?us-ascii?Q?k7lHjCaAnFcEaePb5yrwnMSL4UAVZtWafL7cuISw3+ZFsHFIVorBcWz6xoLr?=
 =?us-ascii?Q?cHSSs01EN7BY9WqodMabbWxGYrj8c7GRnig5I1+AYxS3Gq4Wobvh7du/1MWB?=
 =?us-ascii?Q?UIa8YiQ9U1WXWcRQ2INRjrFxTkxXbPAy8reWjLA52Tn9tZW6nLhGYv2TPyNs?=
 =?us-ascii?Q?FJTXkT50LsWgNeUoYUVtr33a7NH8lpfffxS+36KirqHyA4huWVvtgsmfdjFR?=
 =?us-ascii?Q?Us+HZbumoeAqqVDhnE7EznhLxlWrmFnp/Z9X1H0nx+FdugPV7I2w+mQuuQs0?=
 =?us-ascii?Q?EJtpEBZmIY1mJlzd1A8=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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: d743af1d-1311-4b9d-7a41-08ddaf076c84
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2025 08:00:57.6103
 (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: nBzferEV9wuFlQFlhGxY/tDAJVCUNN2GjEq6Uaz4t7LJ6PybVnY5ai17V0pm9dBG4uNehOKP/6c2R/A/ifqyrw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8510

[Public]

> -----Original Message-----
> From: Penny, Zheng
> Sent: Thursday, June 19, 2025 3:52 PM
> To: xen-devel@lists.xenproject.org; Jan Beulich ; Andr=
yuk,
> Jason 
> Cc: Huang, Ray ; Jan Beulich 
> Subject: RE: [PATCH v4 04/15] xen/cpufreq: refactor cmdline "cpufreq=3Dxx=
x"
>
>
>
> > -----Original Message-----
> > From: Penny, Zheng 
> > Sent: Monday, April 14, 2025 3:41 PM
> > To: xen-devel@lists.xenproject.org
> > Cc: Huang, Ray ; Penny, Zheng
> > ; Jan Beulich 
> > Subject: [PATCH v4 04/15] xen/cpufreq: refactor cmdline "cpufreq=3Dxxx"
> >
> > A helper function handle_cpufreq_cmdline() is introduced to tidy
> > different handling pathes.
> > We also add a new helper cpufreq_opts_contain() to ignore and warn
> > user redundant setting, like "cpufreq=3Dhwp;hwp;xen"
> >
> > Signed-off-by: Penny Zheng 
> > ---
> > v2 -> v3:
> > - new commit
> > ---
> > v3 -> v4:
> > - add one single helper to do the tidy work
> > - ignore and warn user redundant setting
> > ---
> >  xen/drivers/cpufreq/cpufreq.c | 53
> > +++++++++++++++++++++++++++++------
> >  1 file changed, 45 insertions(+), 8 deletions(-)
> >
> > diff --git a/xen/drivers/cpufreq/cpufreq.c
> > b/xen/drivers/cpufreq/cpufreq.c index
> > e01acc0c2d..79c6444116 100644
> > --- a/xen/drivers/cpufreq/cpufreq.c
> > +++ b/xen/drivers/cpufreq/cpufreq.c
> > @@ -71,6 +71,49 @@ unsigned int __initdata cpufreq_xen_cnt =3D 1;
> >
> >  static int __init cpufreq_cmdline_parse(const char *s, const char
> > *e);
> >
> > +static bool __init cpufreq_opts_contain(enum cpufreq_xen_opt option) {
> > +    unsigned int count =3D cpufreq_xen_cnt;
> > +
> > +    while ( count )
> > +    {
> > +        if ( cpufreq_xen_opts[--count] =3D=3D option )
> > +            return true;
> > +    }
> > +
> > +    return false;
> > +}
> > +
> > +static int __init handle_cpufreq_cmdline(enum cpufreq_xen_opt option) =
{
> > +    int ret =3D 0;
> > +
> > +    if ( cpufreq_opts_contain(option) )
> > +    {
> > +        const char *cpufreq_opts_str[] =3D { "CPUFREQ_xen", "CPUFREQ_h=
wp"
> > + };
> > +
> > +        printk(XENLOG_WARNING
> > +               "Duplicate cpufreq driver option: %s",
> > +               cpufreq_opts_str[option - 1]);
> > +        return 0;
> > +    }
> > +
> > +    cpufreq_controller =3D FREQCTL_xen;
> > +    cpufreq_xen_opts[cpufreq_xen_cnt++] =3D option;
> > +    switch ( option )
> > +    {
> > +    case CPUFREQ_hwp:
> > +    case CPUFREQ_xen:
> > +        xen_processor_pmbits |=3D XEN_PROCESSOR_PM_PX;
> > +        break;
> > +    default:
> > +        ret =3D -EINVAL;
>
> I'm thinking since handle_cpufreq_cmdline() is totally internal and has v=
ery few
> caller, maybe  ASSERT_UNREACHABLE() is more suitable. Then the function i=
tself
> could become void return.

Sorry, forgot the release build. I'll add assert and stays with non-void re=
turn

>
> > +        break;
> > +    }
> > +
> > +    return ret;
> > +}
> > +
> >  static int __init cf_check setup_cpufreq_option(const char *str)  {
> >      const char *arg =3D strpbrk(str, ",:;"); @@ -114,20 +157,14 @@
> > static int __init cf_check setup_cpufreq_option(const char *str)
> >
> >          if ( choice > 0 || !cmdline_strcmp(str, "xen") )
> >          {
> > -            xen_processor_pmbits |=3D XEN_PROCESSOR_PM_PX;
> > -            cpufreq_controller =3D FREQCTL_xen;
> > -            cpufreq_xen_opts[cpufreq_xen_cnt++] =3D CPUFREQ_xen;
> > -            ret =3D 0;
> > +            ret =3D handle_cpufreq_cmdline(CPUFREQ_xen);
> >              if ( arg[0] && arg[1] )
> >                  ret =3D cpufreq_cmdline_parse(arg + 1, end);
> >          }
> >          else if ( IS_ENABLED(CONFIG_INTEL) && choice < 0 &&
> >                    !cmdline_strcmp(str, "hwp") )
> >          {
> > -            xen_processor_pmbits |=3D XEN_PROCESSOR_PM_PX;
> > -            cpufreq_controller =3D FREQCTL_xen;
> > -            cpufreq_xen_opts[cpufreq_xen_cnt++] =3D CPUFREQ_hwp;
> > -            ret =3D 0;
> > +            ret =3D handle_cpufreq_cmdline(CPUFREQ_hwp);
> >              if ( arg[0] && arg[1] )
> >                  ret =3D hwp_cmdline_parse(arg + 1, end);
> >          }
> > --
> > 2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Jun 19 08:01:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 08:01:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019788.1396293 (Exim 4.92)
	(envelope-from )
	id 1uSADa-0004UV-Q0; Thu, 19 Jun 2025 08:01:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019788.1396293; Thu, 19 Jun 2025 08:01:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSADa-0004UO-Li; Thu, 19 Jun 2025 08:01:54 +0000
Received: by outflank-mailman (input) for mailman id 1019788;
 Thu, 19 Jun 2025 08:01: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 1uSADZ-0004PD-7a
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 08:01:53 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20628.outbound.protection.outlook.com
 [2a01:111:f403:2417::628])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a77b3dc2-4ce3-11f0-b894-0df219b8e170;
 Thu, 19 Jun 2025 10:01:51 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by SA1PR12MB8859.namprd12.prod.outlook.com (2603:10b6:806:37c::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.28; Thu, 19 Jun
 2025 08:01:47 +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.8835.027; Thu, 19 Jun 2025
 08:01:47 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a77b3dc2-4ce3-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=M/b3UtQ45g2dmbUctY2HSDyMXdL5RRfAHfmdYFuTrLmiRn6at7RtNkkPO2vbxT68AdTctpVCyXe2cdiYcdSI9RPMsAmzbCuz3RT0kPp4GbNQbQRvZnwNOgR1jtaXErdnASAhbOFSY19AeRsv6HAjts7nUwr/WzTUz1kQf+/dG0wlhKT+LsKOSmZj9ozC5eoqpLURFkVM1hPHikHpoV0IY9p3YgcYEzFnzIildn1M7/3nR+aw/BxKxzme6RK5wGCWunAa4Pwghy5JgiqsxM0DaX4n8wypnR/0aJHk3aIsT5y4FpNFZ8wJZ/ppx7KAboapPnmWq0uOMcSU/VHNbktAxQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=zGBSG5Cv4iPoOUtagzQJJy3P/dyWB4ohs1B182hoTdo=;
 b=FbeRm/QngRuIWdOva1wlI4qmqBSPie6tczXzjhOPtaiQLjm7ntjY2q/SuGOugtuYJ//KaqdhUR72LfkhpWCURUGqwEYzJYjvXXnnCw6yyUO0vuCOnCriEAWZFKL+veXZIdbHtMZHyHN1q7wti+PBdc11P5FD+QbTQWtVRN/RdPPWiVX9g4f6nX/P3cURkgDK4wkDu8NhvtCu5kEnJiyrZX3stJb3tT9+U5I5mvk3o5LY0qLK2resEGZXktAVtgR52KQCvqSbVbXY7jw7VeDrO8p7E6eA0YheuUBjph5FPeLyaKCsduH7gxM1eilzRvxgCT4oJy+dR+l4WxCoqtEW4w==
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=zGBSG5Cv4iPoOUtagzQJJy3P/dyWB4ohs1B182hoTdo=;
 b=E5IBrpwadjWBdD/YxlLvMZhTS//K1riL3990y3NzDe7EOaaoMe/RAYEjr6cqViqFws/CtDGLZFilz+XgKsBeZrF6F0nIVv5ErWfxZqxh7lm7nk+x10I+tsEptZ1WBihKs5jicF7m7qICqKzwFH2SJ18xOYqj7D4uxnXMPOaiQQY=
From: "Chen, Jiqian" 
To: Jan Beulich 
CC: "Huang, Ray" , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, "xen-devel@lists.xenproject.org"
	, "Chen, Jiqian" 
Subject: Re: [PATCH v6 7/8] vpci/msi: Free MSI resources when init_msi() fails
Thread-Topic: [PATCH v6 7/8] vpci/msi: Free MSI resources when init_msi()
 fails
Thread-Index: AQHb23yeMT8YFCMR3kaLDqQP1+DTK7QJBi8AgAGktoA=
Date: Thu, 19 Jun 2025 08:01:47 +0000
Message-ID:
 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-8-Jiqian.Chen@amd.com>
 <2d5a5abc-9fc6-4412-9a70-7b12ba46d80f@suse.com>
In-Reply-To: <2d5a5abc-9fc6-4412-9a70-7b12ba46d80f@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.8835.025)
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_|SA1PR12MB8859:EE_
x-ms-office365-filtering-correlation-id: af6c3477-12f7-4f9f-c92d-08ddaf078a0c
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?OGNpbURTU1ZmYnJzcE5kamVzTDNQb1NYVmlPQXQxY3BOdXYvVklsMUY5Zkpm?=
 =?utf-8?B?VDZWaHcvaGFJUnpDb01nZUh6SldnMEoyQUMxalFtMGhUN25tWGQyMjZ0TFFl?=
 =?utf-8?B?b2J1OVJQVnVrbDZLcFZWMTBKQVFpMkFjSVhJQlhtZnB1UVlXT0wreEFyNVZz?=
 =?utf-8?B?TWVxZmRPMXNzem5abkVWSnU1aDNSMGpNYlArNUZRZGZMdEZVSUgyckovcTN6?=
 =?utf-8?B?eDRJb1V6ci9QL3NmQlg1ODhPZVFKRDNxVkRSUEtzRCtPL1BGYWhLNDlXRzZx?=
 =?utf-8?B?Z1FCSE5zQldlVU9DR0R2eXIyZ1NoejdxMGwxSUhwdUo0a3l0MHRTL2YzOElt?=
 =?utf-8?B?YnRtcndPNXNUWFZWbDlvZGdRSzlLQ0hzRmNxUGJvQStDTm1EOTlSVWhURUdw?=
 =?utf-8?B?dFZ4WGlZNHlyQTVoM0pqN2hHUlZ1ZWtFb2hIeHVoZ3YvdzhNaVRlWFJNbHdK?=
 =?utf-8?B?QjB5MDYzdEg5TUpSMUllR2VWRkVyL2Q1ZC9RV1RMSXR1Qk1XMFZUN3NIVzJY?=
 =?utf-8?B?MGY4WUZ1d3dRNXFJcklMYUJsakVsWmUyNnBxakFFaEtac1VIRW5UYUx0NGpw?=
 =?utf-8?B?UC9xb2RScVYrbjJwcFk2bTlqSlJvcms0UjBnclArTkZhTHFzRFdaTEYwRWdF?=
 =?utf-8?B?d0ZyN2FTU0ZuYVBpR3RINnd4RUsvZlp0QjUxV28yTVl0cnRVNUdTVm40RTMy?=
 =?utf-8?B?cHBxQitHSHdzakFZVytFS0JzRm0xUWgxWnlZaWR1d0ViMlora1p1dXg3dFpl?=
 =?utf-8?B?TFpMVVYwTXR1WW5SWm16VWhncmlpSzg3RnFLZmVsTyttd08xd3pDKy9YZTA5?=
 =?utf-8?B?SXoyQUx2bERpeXJhWGdnRklOaVZrS093VWx0d0cvNEttS0s3MWlwYWthU1Jv?=
 =?utf-8?B?Tmo0YnNQckhoQW1VSjhDZFMxOGd0SmtRc0xURVlCVjNieHF6TEtBUkVHMTh2?=
 =?utf-8?B?UVBabHJ3bkY0UFFBNTdic3dmaEVLQlBSRTBPaTZkSmRHTCttSnQ2Z0FBS3JB?=
 =?utf-8?B?YmRTRlZGZ2grNDJyM1FvRnNUYVE4SHVwS3dkZ2lER096Zkc4WUk3cU5FMER5?=
 =?utf-8?B?SWtKNFl1dmtKZjhabWZNMVEvbEcyTDdhcWpWSWZXMUloTDdQcEF6aXlqdndl?=
 =?utf-8?B?bzJsbnU3b1FBYjVtd2dGVis4NnRtNW9NWkJQY3h4RFRMY0NTcUUwZ1RONzh1?=
 =?utf-8?B?UytudlNuV2JSckJZNjFCS3hVSG1IM2dzVnJKdGduTE5QTnpvelRMSzVoT3hh?=
 =?utf-8?B?UzRDbXhXZzF2T1VaWUpkQitKcDFMdGFOWEtsQndrLy8zeTlhNXhLamRxVDFX?=
 =?utf-8?B?ekRmdlhJNXdxay80eG5QWjBMUDhQbjAzeFVpc3dQTjA0cmhRemFydk9LMThD?=
 =?utf-8?B?YWZoZXJNNlZoSkxyYTQrS2ZyM0o4a0oyd09ZZ0s3YjBWVmJCUXRldFhCOStm?=
 =?utf-8?B?ckF0ODB1SDZMWFN3TjVrVE9mV1FqdFI4N0R0UkhNL0Vkd1hja3k4Qmg3bWYx?=
 =?utf-8?B?VS9JamtuZnh4OXRzT21sTHJrUnkzQ0dsZ0poRTF0bGxUaEJEV21xa1ZoMDdr?=
 =?utf-8?B?dU5YWm5ndXVkOUc0ckhSa1FBYXNITTJQKzdEcnZzRHVDZXRxMjU4dEJtU3hD?=
 =?utf-8?B?SXJyREdWUHlqTWk1Sk04MXhlTGFqQlZ1VTZXUEFraWJpR2Q5bVRZTUczMTVY?=
 =?utf-8?B?UnlUWStuTlNTZVc5eU9LeTVJbmJxSzFzV01ScGxocXB1bjNISHhWWWdZZUV5?=
 =?utf-8?B?V3Z3alhFYlpOcEdrTEtHNWlNbGlBZXJ2ZUwzQnlWS2h2MDU4ZzBjVXFoeXVN?=
 =?utf-8?B?UVdyYWQ4Umt5OFQyVEtYWHczeEJVb3doU2tnbHNYdTY3WEZaUmc4YmNSeHJG?=
 =?utf-8?B?MnJNUEtqQVkvR2FPSjgvZ3plK0ExcFk1dHdwWFRwNHdpLytBUjl0d1VyYzhk?=
 =?utf-8?B?cWVzaEVFM0FNYjZCa1lCSjdpRFZHZzVkS3pkNGo3eCtIaDM2RXhualAwa1lF?=
 =?utf-8?Q?NQkmFgaehkF8WNFVJYqLDAF1v5OemU=3D?=
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?NkNIWmw2TW1vd0lLTlArUmJuSWFIOS9UOEFxOXE0eDhhSDJQTkJPaWYxZ0dy?=
 =?utf-8?B?WUR3Y1luNzI3YjBqSmlDYjVaUjNsSTAyU2tjTXZCSllBZTFQUDI1YlptZXM5?=
 =?utf-8?B?ZXhMbDlPT25BbkIwT240QXlCVWROLzhvcm1oVUxwS2pZL2Z2MENGSi9MZ1Ev?=
 =?utf-8?B?STVCNk9zbkh5MHl6TGxpbVRGOFNvZHFRa0xiakI0d2FFb1N5SG1PL2prWVRS?=
 =?utf-8?B?eFZVeWNNZFJTTWJGcjY1OHRVckZkSzZBT1JmcS8wRVpXdkQ3NnpOM2h0bnlZ?=
 =?utf-8?B?Y2xGNEQ1cWF3aDIxWm9FWFBsb3AyNUNsektJMmRKZHZkM2hCL0ZiQW1jWW9D?=
 =?utf-8?B?YldhbFpOYmZHRnA1VXpxRW9xS285SmdreEVvYWZCRERsdWdjQ2cyUUZGaWxL?=
 =?utf-8?B?WUU0Sk4zNDNhZHYrUEZ2QVNiN0x4RVF1VTFBbXpyTUVTaXB1cUMxeXgzU0dP?=
 =?utf-8?B?MmpLTE9UOGQ1blAwbHU3eGlvWUJOM25Oc3dydk1XbmRuVU11SDRldzQ4T3l2?=
 =?utf-8?B?YktDNzgvRCszYXFGSlE0ZGhrbUc1T1NudjVVTnJqWGNMVmk4OXF6SWtVbjJM?=
 =?utf-8?B?cnBtYUNLcG4wWjBQK3krUlZrcmtKMTRDVGJkY3hnRHY5eXYybVdCV3dZdmhI?=
 =?utf-8?B?cE8ra3JhZVVLNllzaDNZYVZUM0NYc0VGa0JndHp3a3hhbzdoQ3Iwc3NiVS9X?=
 =?utf-8?B?dVo5NmVSZkw3M2RVZUpTRnQ0cEI4Uml1RmhyMVdHMEgrZHFBQ2YzcHFlNHlz?=
 =?utf-8?B?M3BXRjlnWUdEZzBNemFKclNzOEdkQnkxRXBSWEJ5b1k1b0hueW1XZXpHVWJr?=
 =?utf-8?B?L0Q0ZnZMVDZINFlJWmlHbkJLalJVRlAxWGpZY2crdFYvZldkblNzWG9KZS9L?=
 =?utf-8?B?Y2d4MTAwdFhVVWswaFdSTlRqZ2gwYnNhM3lVclcvR21hT1c1QW9wTmd4ZExD?=
 =?utf-8?B?STVnT0RNUTZsa3QyZTkxSmlQWVpuUUJ6bWUyUExpK3V1TktoM3JITXgwdHNC?=
 =?utf-8?B?VkdkL2JZamhvQXdtTW1FUXM1Sys2NVQ5UnZZOXBDOWlUaENkSnZRMHBmWDlO?=
 =?utf-8?B?ZFZVODdyNXF3eG1nSXc4QmNqcVZucG1xd0xBaDBhN05zOGpPdDlMMGlTWDlp?=
 =?utf-8?B?ZEtWWHl4T1FHTDZoK2N1M2l3MkpJeGo5WHpBSWJxTGpUSStKaEo2aXZqOGd0?=
 =?utf-8?B?MGdSUko4M3o1WTdnTjdqRXJMdDhrWnpaQ29VMnFMQnFhVkVLUDltL0JHcW1P?=
 =?utf-8?B?ZDdjbnhoSW9rc3R0c2U0UzVFeWhNVVlKaUMwV0xhaENUMm5ZeEVTT2dSOEk2?=
 =?utf-8?B?cmRYdXFIVWVrcitWck9oUGc5SkFtOEVHRCtuSWpzeFpHOHkya3pjNDlmN21O?=
 =?utf-8?B?SnRObkV2RzVwN2ZRcTRoeW5PZ3cxd1dNWDVBRnBoU1FMUCtXcjljWUorT1p4?=
 =?utf-8?B?bzRtbnMxK2pxUXM5SFczNVJZckZGQTZLZWtZVzJOSEFyQ1FRalNHNythb1RQ?=
 =?utf-8?B?N2hsS0wzeVhzOGwxRXpsRzZkaXR2SXFudXY3alBVUzIvSEZpR2twMnQybTh1?=
 =?utf-8?B?Y2J2UE9TVkRuYldVOURYd0R2aFgrdG1obFp4YVVZdTZuRlNhSVduY0NSWWR2?=
 =?utf-8?B?cWJ3U3o4cllneDRKQWdlUXpncExSODhXSldKSEFLeVpReTdNUVlpQ2MzKy9X?=
 =?utf-8?B?amdLaW0rYnlET080MkVkb25hUmJ0aE1RQWVodUYxS3p0MmNaYlEvRzVYMnln?=
 =?utf-8?B?U1VnTW96QWtGZ3F5QWZFRi82ZW9yd29pNmdkZXFNVnIzMWY3MUgxSmJUL05n?=
 =?utf-8?B?aGZhYzVxMkRXZFdoZms5VmI1K2lySHh0TEhoRFJqQWowendTODhIQ0c2WFBJ?=
 =?utf-8?B?ZVVRWENlM3NFZ3dwNFFIdzZyVi9tZWJPNmNscVhLaVdhaEVhQUdmTUhQWHBm?=
 =?utf-8?B?Tmc3TUlXRzVZdG1HRVJKZGJTeWJPZTNvZzRreGg5TGpVTTc0aFhrbTRNNndB?=
 =?utf-8?B?OE1aYkVTSkwwdDlhbjlIcUIrdmdJM1BldTV0M3B3bDNlQktpSDRueGJseTh2?=
 =?utf-8?B?RHVNNkZnVlFzOXFSL0V1Z0tvVGQrMkpLVEVCVnFjZG5WaFQyY0s2T20zbWp2?=
 =?utf-8?Q?rG7M=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <59B240469752B342A22BEB2BDAC015B4@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: af6c3477-12f7-4f9f-c92d-08ddaf078a0c
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2025 08:01:47.1872
 (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: VzJ3vCJdm8lVek70LX4fnoWb4O4uLHDyIa451rs02XUYYUqc/7p/mkG09ZgM4I+p8B8exKl3bnHlGjhFnLmimg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB8859

T24gMjAyNS82LzE4IDIyOjM3LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMTIuMDYuMjAyNSAx
MToyOSwgSmlxaWFuIENoZW4gd3JvdGU6DQo+PiAtLS0gYS94ZW4vZHJpdmVycy92cGNpL21zaS5j
DQo+PiArKysgYi94ZW4vZHJpdmVycy92cGNpL21zaS5jDQo+PiBAQCAtMTkzLDYgKzE5MywzMyBA
QCBzdGF0aWMgdm9pZCBjZl9jaGVjayBtYXNrX3dyaXRlKA0KPj4gICAgICBtc2ktPm1hc2sgPSB2
YWw7DQo+PiAgfQ0KPj4gIA0KPj4gK3N0YXRpYyBpbnQgY2ZfY2hlY2sgY2xlYW51cF9tc2koc3Ry
dWN0IHBjaV9kZXYgKnBkZXYpDQo+PiArew0KPj4gKyAgICBpbnQgcmM7DQo+PiArICAgIHVuc2ln
bmVkIGludCBlbmQsIHNpemU7DQo+PiArICAgIHN0cnVjdCB2cGNpICp2cGNpID0gcGRldi0+dnBj
aTsNCj4+ICsgICAgY29uc3QgdW5zaWduZWQgaW50IG1zaV9wb3MgPSBwZGV2LT5tc2lfcG9zOw0K
Pj4gKyAgICBjb25zdCB1bnNpZ25lZCBpbnQgY3RybCA9IG1zaV9jb250cm9sX3JlZyhtc2lfcG9z
KTsNCj4+ICsNCj4+ICsgICAgaWYgKCAhbXNpX3BvcyB8fCAhdnBjaS0+bXNpICkNCj4+ICsgICAg
ICAgIHJldHVybiAwOw0KPj4gKw0KPj4gKyAgICBpZiAoIHZwY2ktPm1zaS0+bWFza2luZyApDQo+
PiArICAgICAgICBlbmQgPSBtc2lfcGVuZGluZ19iaXRzX3JlZyhtc2lfcG9zLCB2cGNpLT5tc2kt
PmFkZHJlc3M2NCk7DQo+PiArICAgIGVsc2UNCj4+ICsgICAgICAgIGVuZCA9IG1zaV9tYXNrX2Jp
dHNfcmVnKG1zaV9wb3MsIHZwY2ktPm1zaS0+YWRkcmVzczY0KSAtIDI7DQo+PiArDQo+PiArICAg
IHNpemUgPSBlbmQgLSBjdHJsOw0KPj4gKw0KPj4gKyAgICByYyA9IHZwY2lfcmVtb3ZlX3JlZ2lz
dGVycyh2cGNpLCBjdHJsLCBzaXplKTsNCj4+ICsgICAgaWYgKCByYyApDQo+PiArICAgICAgICBy
ZXR1cm4gcmM7DQo+PiArDQo+PiArICAgIFhGUkVFKHZwY2ktPm1zaSk7DQo+PiArDQo+PiArICAg
IHJldHVybiB2cGNpX2FkZF9yZWdpc3RlcihwZGV2LT52cGNpLCB2cGNpX2h3X3JlYWQxNiwgTlVM
TCwgY3RybCwgMiwgTlVMTCk7DQo+IA0KPiBXaHkgbm90IHVzZSB0aGUgbG9jYWwgdmFyaWFibGUg
InZwY2kiIGhlcmU/DQpUaGF0J3MgbXkgZmF1bHQsIHdpbGwgY2hhbmdlIGluIG5leHQgdmVyc2lv
bi4gQW5kIHRoZSBzYW1lIGluIG1zaXguYw0KDQo+IA0KPiBJIGFsc28gdGhpbmsgdGhpcyAocmUp
YWRkaW5nIHdhcnJhbnRzIGEgY29tbWVudCwgYXMgdG8gd2h5IHdlIGRvIHRoaXMuDQpJIHdyaXRl
IGEgZHJhZnQgYXMgYmVsb3csIGNvdWxkIHlvdSBoZWxwIHRvIG1vZGlmeT8NCiAgICAvKg0KICAg
ICAqIFRoZSBkcml2ZXIgbWF5IG5vdCB0cmF2ZXJzZSB0aGUgY2FwYWJpbGl0eSBsaXN0IGFuZCB0
aGluayBkZXZpY2UNCiAgICAgKiBzdXBwb3J0cyBNU0kgYnkgZGVmYXVsdC4gU28gaGVyZSBsZXQg
dGhlIGNvbnRyb2wgcmVnaXN0ZXIgb2YgTVNJDQogICAgICogYmUgUmVhZC1Pbmx5IGlzIHRvIGVu
c3VyZSBNU0kgZGlzYWJsZWQuDQogICAgICovDQoNCj4gDQo+IEphbg0KDQotLSANCkJlc3QgcmVn
YXJkcywNCkppcWlhbiBDaGVuLg0K


From xen-devel-bounces@lists.xenproject.org Thu Jun 19 08:44:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 08:44:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019809.1396303 (Exim 4.92)
	(envelope-from )
	id 1uSAsT-0001Vc-Vj; Thu, 19 Jun 2025 08:44:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019809.1396303; Thu, 19 Jun 2025 08:44:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSAsT-0001VV-Rz; Thu, 19 Jun 2025 08:44:09 +0000
Received: by outflank-mailman (input) for mailman id 1019809;
 Thu, 19 Jun 2025 08:44: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 1uSAsS-0001VP-MA
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 08:44:08 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20604.outbound.protection.outlook.com
 [2a01:111:f403:2415::604])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8db93ab4-4ce9-11f0-a30c-13f23c93f187;
 Thu, 19 Jun 2025 10:44:06 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 MW4PR12MB6873.namprd12.prod.outlook.com (2603:10b6:303:20c::17) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.41; Thu, 19 Jun
 2025 08:43:59 +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.8835.027; Thu, 19 Jun 2025
 08:43: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: 8db93ab4-4ce9-11f0-a30c-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=DuPL8cptkIyT2Y7VewB2MyWdwqwrffsLjFxGRb6img+V3FJH5pDCxKviMGnJ7TJENoL8OOtz2BCetacEO0Ms2s+vw76L/hjzlbggxHnZJhe0edyLZXB0otnCH3fAIxPExBhEPotM+bTfwxZrK2N1ZAdK6H3bqemeuOmiYxB5daQTNhNYaaa6zuk3dSFF2kznt20gAY2PbUFoZE9o+tIOIkxPO3uDvfM7BO2U2GCvvX48z+MhijmumsRX0y5mhoMW6N/Wq4LdaLm/CfR/l3T9pDI4+7jwJ5CgseoHDuWqeHTy7RuvPfXMhSoBxnVz3v7QuCzWhQJIlUw7cfYzcO0jTA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=DmK0jtN2SMcGMOlx7rLXibuUM6JCMQ8+QE0LkmBlqls=;
 b=EzXumRBteWT+y+jWYCzIaSWe+hHS802fxt8c9NunbAZrk3opsu+erZPaP1Rhl3SA0ZsE52Y6y63KC84w+9sql16TSiwn+U9FKNNghyzjlVYnw6LKbkAVHPS2eULX9WmHMae9sctRkVnukfbcwKRVEJiWfXa2tM0oSr+AylOVmKRt0kBT3AJiA7e4Bswz8QqrZBtdLZ0kWZBF56wQtccsIjZkl8VdsuFsLEIDQRjucoJpCrs310da4Ipwgqdrim73/z/FVrHJ6S5gx53Sr8EUskPPE+3og6eMvSjITqPNd1XNMr2IZSAF/IR6fuA+QaAPo4xktlz0YZONzBF7vdCz3Q==
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=DmK0jtN2SMcGMOlx7rLXibuUM6JCMQ8+QE0LkmBlqls=;
 b=nDUudoJ4IVtb1dNbV24XWZ2RVhLwJo290o9cuZHFaC4b/ecxkg9OHT9wsSx2Xs9OnR7S2zAZEYVh8D7ZsyCoCA1jvbTuHlDQ0GELyaFqxxG/weyRbiCLYlppoQiDMeKxY+iIfxMSbS25viPEmWpBqslrJK5u0v7n7VF5IuVOFUk=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Andrew Cooper
	, Anthony PERARD ,
	"Orzel, Michal" , Julien Grall ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano
 Stabellini , "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v5 06/18] xen/x86: introduce "cpufreq=amd-cppc" xen
 cmdline
Thread-Topic: [PATCH v5 06/18] xen/x86: introduce "cpufreq=amd-cppc" xen
 cmdline
Thread-Index: AQHbzuRARq8PSmkmBEm8nuMU3PtyjLP/b5OAgArbRUA=
Date: Thu, 19 Jun 2025 08:43:59 +0000
Message-ID:
 
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-7-Penny.Zheng@amd.com>
 <3edeeff2-5728-46cc-9436-01e5e3cf2bd3@suse.com>
In-Reply-To: <3edeeff2-5728-46cc-9436-01e5e3cf2bd3@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=True;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-06-19T08:43:18.0000000Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=3;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged
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_|MW4PR12MB6873:EE_
x-ms-office365-filtering-correlation-id: e5f8d3f8-2914-4450-ac86-08ddaf0d6f97
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?SFdOeTIwMTlxUWJCY0p0aGk2ampqUXZPS3NxeEpsaDY3WkF6UklZMHBVMkdk?=
 =?utf-8?B?djFsQU1pNWxVbWpwVDNKbVliQitYS0V2L0F2NmdTMVpiWHo1WGw0YVNhbzFF?=
 =?utf-8?B?MWNETFFLbEZ3U2RJVFl6UUxDekZrUy9zNzJMLy9RMTVkamdrc0dHcHN6dm5S?=
 =?utf-8?B?WUgyd2xMZHE0VkY1UWpJZlRlbXZBb3VlcG5BVkpsN0l1bGxtUEtlaHhkamZL?=
 =?utf-8?B?cnhwR044WXpwUzNybzA2Zmw1bSt0dDAyb0RSMDA0RlVuTzFSWHlSR0QvdXJh?=
 =?utf-8?B?TnJmV1VqWXU2OUxzYjVGTDZIalRCM0cwRXQvVTZBaG1NOHovYm92M3JOc2gy?=
 =?utf-8?B?bml3MlgrNXhoVVlhN2IyNzQ0QWs0cEphcHphWlA0YXZ4SDJyZy96N0FZNXdu?=
 =?utf-8?B?bGY4U0Voci9zZmE3ajRramJVOUZIQk1UYXJiNk81ZVBTMDBZZG41OHpDakNN?=
 =?utf-8?B?bXlRWEtPM2tGcDhBeEpSMmJNMHNoMmF2bVJvczJCU2JTOUs2Z04xZzlMTURi?=
 =?utf-8?B?eWlEUnRyZWVuZ0wrRzQ2b3N0QkRHRTlIRFQyTytPdGoraEpPK2p1MzJRZHNV?=
 =?utf-8?B?OERIdUdxOFgwTmYxbUFKNFZnQ2tPMGZwNVloTUlpRGFPREMzU2ZiSkc3VFQx?=
 =?utf-8?B?bEdLVVhyL3JuY3FrM0xjK1pTNjRzV3FkOGFFbHJIbHFmRzRHdnpsc0xCVmRt?=
 =?utf-8?B?a0NMYVA2aUxVWUI3NHNDWDlSMEFDM05rOVRXOE4zSXdNTnBUTkFvd0VGSHRE?=
 =?utf-8?B?Ynh3OTJEais4M3lYUmt3djh6Y1RGSjhwNmNqWDB1NHd4TWVzRkVKcGIvdkJE?=
 =?utf-8?B?Y3B6TG9KVENrd1hTVWhmU0xxUFVqN0JLVzloV3F0bmI4bHFsZWpkaTErVDJS?=
 =?utf-8?B?V1FONnU3NFlUNHA4YnNnWWg5Ym1zY1RWWnpndCtLRXNHWWpCdVozZWRmd09P?=
 =?utf-8?B?bEczOWVJWmNRMkY3RkJtMGdwZE9SOGhVeXgvcm5oSnpJbTJ3VlU2MjJKTEQ4?=
 =?utf-8?B?Y3RlWVVUWVY3ODBiNUZsSHNjNE5ERmc1N3F4MXF2dnNPT1prcXpCbkpSekxC?=
 =?utf-8?B?VUpYTm1FSlp6Y2diS09uMjFtZ1MyMEFnZ2hxeitSeEtjMVFEU2FId0V5V3dV?=
 =?utf-8?B?dmEzQ0VMMkNRNThVSC9LZXJ0Y2k3Z0pRMUlrbFQrL2lqUmZJY2NocjJUaVJk?=
 =?utf-8?B?R1o2bDkyQ2RKTXp1QjZSSjZYaDM4SFEvOUsxWFFGM0hhbzJYUEJ4VFF3Wmkx?=
 =?utf-8?B?d0xoS29rTHA3TjhsaXZjQXhlSXhTazkvNlpJQjFEeTV2TG5KbzNFZU1SVS9l?=
 =?utf-8?B?eEl1TGhNUlhKZlorSU0vTkNUaStBODJtY3U1RkJ6MGoxRExCUG02QWtoeUR0?=
 =?utf-8?B?eE5wZzA2YitXRjBWaVhVSkQrNUxTSDh0eC9WSGdMc2szQzRtaURMaU5nRWpo?=
 =?utf-8?B?c1FtenQ5cjRwZ0FEaVA5ajNXclcyUmlpV1BmcE1MUmF2RTg3Vm9KY2diZlRL?=
 =?utf-8?B?cFFVUHhYcHZuekFTdWJzUkhPMmErQlVvQ1RVTFE1SG1vVTZhR3g1bVgwSVJ1?=
 =?utf-8?B?ditRcjJTNm9FakQ3aERFM0dPUENtTE4rZm9kVmYwTVN6aTROSnF4TTB1RTk4?=
 =?utf-8?B?QUg5QmpJa2NMTWNicGp3VkpIUmJOZHpvd2RERWJOb250enFUKzdQMVBHZVVk?=
 =?utf-8?B?R3ltTTVNZ3d2czdLT0htaVF3d3JCMWhkalRwWEUxQzZ0NWsydVdJKzMvQjlm?=
 =?utf-8?B?S0VSZmIrT1c5Z0I0ZUtnQmxuTE9SQ2hhdytUV3VBK1kxcDlxa2cwSmpGVVp1?=
 =?utf-8?B?RUZGdUhyeWdyNFU0WFV6MVRwRWdsSVJ4TTl2ZEFCS3ArRFhRNGlheHdYZ3kr?=
 =?utf-8?B?d2N5SjZDSGFnUGJVamtKd2xUTzNTWXVjSml1ZHQ0TFNUQUVvalljUEhuSzJU?=
 =?utf-8?B?WjRDQXg2UmtwWk43NXV0TUpTRHlzNjhuU3RqYklBL0xaVEs0Kys4Y0dFR3Ex?=
 =?utf-8?Q?ybEgMQFJnFwoPmgmSa31Eymf7MhLWA=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)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?S1JLZlZGZmVXSFlIZVY4OThEYW1nMzBVS2Q4eU5DRjZHY2Q4a3JVVFBqZDUx?=
 =?utf-8?B?S0hmWFVGYUFqVVRsdjNYZExSNjZnS1d0cHVXSkllNFZkZ1J6aVZ2NWs1Zk4v?=
 =?utf-8?B?OUVzOFBRRnpqdC85TXBqUm8rTVhvZjZOTVMxOEFCZ3RMR1p3NkZaZ1pNSlJB?=
 =?utf-8?B?dm5xZlFMSFE4cG42M0NtYXYyZWMxd2xXcjdHTk1xNmcya3VhTy9jOVBBN09T?=
 =?utf-8?B?ZlVCaHdaS0JsS0VTd3BSOVpKOXB0WjBhYk9LMjlVdWFGaTQrME1lQThLMzBi?=
 =?utf-8?B?cnk2VDQzeHhSdndRR29lT21QY2gyNktiQUg4T2hBRERSQVZtbFNoZThRTTN4?=
 =?utf-8?B?WGx2Ym9HbXR0TS9nZkN1eWxSZjRzalBZK1M5U0psUkhRejA1UzVmeFhlRGlH?=
 =?utf-8?B?VGo1aEduZEtRbEtwTmRuQ2VPb1dCdURQNTkzUE1jOWxEUnIwUm56Qmx4ZUNE?=
 =?utf-8?B?djJvcE5qYTA5QnAvNzB5QXI5ei9SYlpQYklrZml5elk2WGJaQXJsaGg2cWFN?=
 =?utf-8?B?QmF4R3lhak03ZXp6OTByUTBobUc1NEF4aVJnRXdTYllpUEZ0VTRaWG5PUUJr?=
 =?utf-8?B?YnJmMXVKSmtubVRHL3VLaXI1SGtPQ0VEMDhGU2pvbDNiM3BBWnpzNExCb0tZ?=
 =?utf-8?B?My9TRHRyK3JIOVZPc0xpNEhacTNNQk42YXBZY2crTGZqbTV1aDNaTFF1ZTF6?=
 =?utf-8?B?QlBYUnhWbW1SSjY5bzdoSk1halkxaEFCdHo5SUNjc3lzcEJJQWxjc0pJS2tR?=
 =?utf-8?B?Y1pFSFNjQjVFSkdQa0JMZmN2TGxtQ3ovajl4cjFWOEhWbUEyNmhxcjBsa0tn?=
 =?utf-8?B?WVoyN2NqZFNsQnRtd2wxbVJFT1E1d1ZCWXF4VVpkTzh0WDJjTlhJRTBYalgz?=
 =?utf-8?B?RkszQ2VHZ0lyRFhoU1B2UGhhb0drT3A1WHlJcDNwZnJKaGZyRWREM1YrbXJy?=
 =?utf-8?B?blJ2MGUwTDFqS2xmay82ZWNCNWF1TjZyRlVLMVdwTVRqWUt0WFNXQmM1VmNL?=
 =?utf-8?B?QWVSVWtRM3dYdUxmcUUwSi9TWFAxQUszUmt6dS9nMVQ4U3ZXSG9BSzdCMnU2?=
 =?utf-8?B?QWZhZ3RlTFBTeVdhYWlnUGtIVlF4cE9WZDZRbTRvbUZiMkR2dkFHbVNyUXVw?=
 =?utf-8?B?a2tLd052SW1ZcVcyd20xaHJTQ2h0TlJsODhjRkNtK2RpNHI3QVR1aFNBdFc1?=
 =?utf-8?B?eGE1VWVSSFZTb1c0bVZBcHF4bnh0eWxZUkZmcTgzbERmSTJLSzYwZjlUUlor?=
 =?utf-8?B?eDhMRUZ5c1d5amxOQmtiSlprYm1Ob3U1ZjRncG11ZFBxMzhPdk9IYWY1UUho?=
 =?utf-8?B?eTkzUDN5SHNuS1BFUXM4WXZaeGluajM0MlpuVllJbURZWTR2QXozMXJyaWxm?=
 =?utf-8?B?SjRncTZjR0R4QzBOZVlrbWJGcmFQWkhXUkFYam5FbHZVaVZpUFZ5aEp0MlhV?=
 =?utf-8?B?cTF6MDYwK1NTemxvTUxrenl3QlZLZHhwN29Oemp1WVBjN2h5eTVTZnZvaUtm?=
 =?utf-8?B?SXVJdXlySEFPd3k4UU1TVHczVm1hQkswK2VwQUpBZWxHdDh5WWxCOWlJbXAv?=
 =?utf-8?B?S2R6VDlLd1ZYZTBLaGp2V1FiYUtHQ1IrR1BjN00ycmppWWR4a2ErYkFReTFs?=
 =?utf-8?B?QUhuVUxmbC90elcrUHFkWWdjRHYxSzRZZTNoNkI4Tno5UUpzSlJxcVVyZTFN?=
 =?utf-8?B?akZYYmtvajhBZTRnaFNFZTArUXZBREROZkJmdkV6RVUwK0QwVkhqYUwybVA4?=
 =?utf-8?B?UUhaUlFZV29SUkRXeGRWdTBCWjlwZVZSS1dMSXhCRU04SWJuZ1crcHMwTHZL?=
 =?utf-8?B?ek9vNUtHR2tRYTZzUVFva2tGendpVkt6aElVaWN1M29ObGFIODNWNDVTWTJ3?=
 =?utf-8?B?MHIwSWZwMnk3MlR3Y29UY2pzVmFyZDdoeEZiK1I4a3p2eUJTOEQ2ZjgzMXF4?=
 =?utf-8?B?aHo2dk8rSHQ4UUgvU2tHMC9QNE1ucmVpdFhLTndqVEFmSjZpVGY2YnlMZEU0?=
 =?utf-8?B?M0x6RVBiQkxqMW5nVkg5cElmS0xoS3VDa2ZlR2RFSDI5ckc1SUE3NXlFVnJV?=
 =?utf-8?B?TkNPdU5RcGVXVHVEYnhndFA1WVEyUEhOVmJFeDM1aS9qRnFWZXlyYm1CQmJy?=
 =?utf-8?Q?+Jw0=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: e5f8d3f8-2914-4450-ac86-08ddaf0d6f97
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2025 08:43:59.8032
 (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: vISSWZ4u6DrcTGuYeyM8L3xF6SG88hiSDlG++bLIpx3toR66twATq1OQYu6+cf/OO5AnGbS1Gs6zOaRObzHmxg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB6873

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDEyLCAyMDI1
IDY6NDIgUE0NCj4gVG86IFBlbm55LCBaaGVuZyA8cGVubnkuemhlbmdAYW1kLmNvbT4NCj4gQ2M6
IEh1YW5nLCBSYXkgPFJheS5IdWFuZ0BhbWQuY29tPjsgQW5kcmV3IENvb3Blcg0KPiA8YW5kcmV3
LmNvb3BlcjNAY2l0cml4LmNvbT47IEFudGhvbnkgUEVSQVJEIDxhbnRob255LnBlcmFyZEB2YXRl
cy50ZWNoPjsNCj4gT3J6ZWwsIE1pY2hhbCA8TWljaGFsLk9yemVsQGFtZC5jb20+OyBKdWxpZW4g
R3JhbGwgPGp1bGllbkB4ZW4ub3JnPjsgUm9nZXIgUGF1DQo+IE1vbm7DqSA8cm9nZXIucGF1QGNp
dHJpeC5jb20+OyBTdGVmYW5vIFN0YWJlbGxpbmkgPHNzdGFiZWxsaW5pQGtlcm5lbC5vcmc+OyB4
ZW4tDQo+IGRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0gg
djUgMDYvMThdIHhlbi94ODY6IGludHJvZHVjZSAiY3B1ZnJlcT1hbWQtY3BwYyIgeGVuDQo+IGNt
ZGxpbmUNCj4NCj4gT24gMjcuMDUuMjAyNSAxMDo0OCwgUGVubnkgWmhlbmcgd3JvdGU6DQo+ID4g
LS0tIGEveGVuL2FyY2gveDg2L3BsYXRmb3JtX2h5cGVyY2FsbC5jDQo+ID4gKysrIGIveGVuL2Fy
Y2gveDg2L3BsYXRmb3JtX2h5cGVyY2FsbC5jDQo+ID4gQEAgLTk0LDYgKzk1LDggQEAgc3RhdGlj
IGludCBfX2luaXQgaGFuZGxlX2NwdWZyZXFfY21kbGluZShlbnVtDQo+ID4gY3B1ZnJlcV94ZW5f
b3B0IG9wdGlvbikgIHsNCj4gPiAgICAgIGludCByZXQgPSAwOw0KPiA+DQo+ID4gKyAgICAvKiBE
byBub3Qgb2NjdXB5IGJpdHMgcmVzZXJ2ZWQgZm9yIHB1YmxpYyB4ZW4tcG0gKi8NCj4gPiArICAg
IEJVSUxEX0JVR19PTihNQVNLX0lOU1IoWEVOX1BST0NFU1NPUl9QTV9DUFBDLA0KPiBTSUZfUE1f
TUFTSykpOw0KPg0KPiBUaGlzIGxvb2tzIGxpa2UgYW4gYWJ1c2Ugb2YgTUFTS19JTlNSKCkuIFdo
eSBub3Qgc2ltcGx5DQo+DQo+ICAgICBCVUlMRF9CVUdfT04oWEVOX1BST0NFU1NPUl9QTV9DUFBD
ICYgU0lGX1BNX01BU0spOw0KPg0KPiA/DQoNCkJlY2F1c2UgaW4gU0lGX1BNX01BU0ssIGl0J3Mg
Yml0IDggdG8gMTUgcmVzZXJ2ZWQgZm9yIHhlbi1wbSBvcHRpb25zLA0KU2VlICINCiNkZWZpbmUg
U0lGX1BNX01BU0sgICAgICAgKDB4RkY8PDgpIC8qIHJlc2VydmUgMSBieXRlIGZvciB4ZW4tcG0g
b3B0aW9ucyAqLw0KIg0KU28gSSdtIHRyeWluZyB0byB1c2UgTUFTS19JTlNSKCkgdG8gZG8gdGhl
IG5lY2Vzc2FyeSByaWdodCBzaGlmdCAob3RoZXIgdGhhbiB1c2luZyA4IGRpcmVjdGx5LCBpbiBj
YXNlIFNJRl9QTV9NQVNLIGNoYW5nZXMgaW4gdGhlIGZ1dHVyZS4uLikNCg0KPg0KPiBKYW4NCg==


From xen-devel-bounces@lists.xenproject.org Thu Jun 19 09:53:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 09:53:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019854.1396312 (Exim 4.92)
	(envelope-from )
	id 1uSBxp-0001iw-PP; Thu, 19 Jun 2025 09:53:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019854.1396312; Thu, 19 Jun 2025 09:53:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSBxp-0001ip-Mh; Thu, 19 Jun 2025 09:53:45 +0000
Received: by outflank-mailman (input) for mailman id 1019854;
 Thu, 19 Jun 2025 09:53: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 1uSBxo-0001ij-Mi
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 09:53:44 +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 48701300-4cf3-11f0-b894-0df219b8e170;
 Thu, 19 Jun 2025 11:53:42 +0200 (CEST)
Received: by mail-lf1-x129.google.com with SMTP id
 2adb3069b0e04-54e7967cf67so543275e87.0
 for ; Thu, 19 Jun 2025 02:53:42 -0700 (PDT)
Received: from pc636 (host-95-203-1-180.mobileonline.telia.com. [95.203.1.180])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-553ac1367e9sm2541889e87.79.2025.06.19.02.53.39
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 19 Jun 2025 02:53:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 48701300-4cf3-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750326822; x=1750931622; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to;
        bh=8lxye2GX1z6QI+SRVMkfZEngbWK9B27pd3eBJcWGrlg=;
        b=AlJUrCvmcpeVtVNVJRWm5zS/8kr43qptmYm647x/9kwjMzKvHe7bvVh036C3cWdAWF
         c+LbyEEWIndCWcZ6wYEfNJJx1WrcgSO4HBb9wQOnxHZ4+7uUTRamQ1SFSH+cf0JmjyDg
         MBhAkAmGETDZ8xiW752HHB3KyloULxGhPvUCF8aLQwWIsAEAMU5br0jIZux9C6eEO1bo
         YZvmGIrxbkuvoSLzFVWiCfvXN83sW9AVwpXzyOZP2N11UJBBXg5htnzY1xc2APTvU4LA
         Y3ii8IZWgMYD5YTnHqc1zwHtAuhJ+iMA0l9zaewuMs6yHkBrkGsRYmQKb+bj6MHaw4+0
         3UdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750326822; x=1750931622;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=8lxye2GX1z6QI+SRVMkfZEngbWK9B27pd3eBJcWGrlg=;
        b=iw4lvt04ewSdmXTy1kYCZsC7wojW/5EUQO7TUOCqi7xDjyDilrvtPgWjHk3S5Fqr0i
         x20FcvoJRbsFucfzaZ56gymr87Hd8RlqRVkdICKVbeNwxTvb3npxhLbncKAylA8xPFNe
         c0CbSiP4vbY8cmbrqEthQ0UZ2af4X8wpNga+u4qs/QxNz7IVK5pw+Ksf06iYJuD1+n6C
         RV8nQog3A5hYUF1TKU50E+0P2Rbt7Naf/PNrhfQZ0wPmRrI/HgvB5Ijx14uBcnKGSns/
         OyZ33obOWqCqXDnIVnBKwPufUlABgvDILSaCW8Pd82sdv+/n3I6mkumbr3wW4LPP0Wlq
         ZpeA==
X-Forwarded-Encrypted: i=1; AJvYcCVhlkePdfWWYw3Fs9YrMFM+fwmzn1Qyr0DYoS5sZqYlDJnoPIpfLynoydSvwVEj8IPtFQ85SQtARDc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YypT/Oxv7cvkdy833tRv78TaUw0+ZeI1gfGH4t5UfFGjShSls3S
	oOWWXI6aeBImuDpVbRNbaBIKJmvUTc0IM/fG9Czx0fMqwZRyWhy8vjA4
X-Gm-Gg: ASbGnctSrvKjdHggprv1G7OqsvIt80eMK/a7r3zSApAH/Ct208qeJfV/EYycCwK0qjp
	+H7qTqk9hrRm4ZTO4H92MUjqGsO/eMc7JmnmG3U85t+arz9nNW3AzwJNMpBNcTVEu2FUQFbeZbe
	2uZLluxY31iE9EmAURfc1Jtmqqwlm26RQOHhz/P5l/5TYXiAHlQuB3GgtTJR8z4iyS5fa0eiVyB
	zWqp9Koj9bWLwtzrATm4QDYfJ42eIEVjkiGe7BtCLJUxKI7wqJBeWRtfJ6N+qGZ9ZNiNu5umgfU
	bLiIGPiihYaYRAr2wo95JhHYTujfpXcjZpVgFSTXvEFD3bfpnqrX/8jYh04xHdRAKYxy9fQanS2
	oO7ASVwV2hkY=
X-Google-Smtp-Source: AGHT+IEJV7RqZa9E1nD948cD6oSgemriE8btKJowGkw8tp48NbrB1jrcDoGclBvee7YrwcLZgS368g==
X-Received: by 2002:a05:6512:1049:b0:553:1f90:cca4 with SMTP id 2adb3069b0e04-553b6e74ae6mr5656846e87.13.1750326821436;
        Thu, 19 Jun 2025 02:53:41 -0700 (PDT)
From: Uladzislau Rezki 
X-Google-Original-From: Uladzislau Rezki 
Date: Thu, 19 Jun 2025 11:53:38 +0200
To: Dan Carpenter ,
	Alexander Gordeev ,
	Andrew Morton 
Cc: oe-kbuild@lists.linux.dev, Alexander Gordeev ,
	Andrew Morton , lkp@intel.com,
	oe-kbuild-all@lists.linux.dev,
	Linux Memory Management List ,
	linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org,
	xen-devel@lists.xenproject.org, linuxppc-dev@lists.ozlabs.org,
	linux-s390@vger.kernel.org, Hugh Dickins ,
	Nicholas Piggin ,
	Guenter Roeck , Juergen Gross ,
	Jeremy Fitzhardinge ,
	Ryan Roberts 
Subject: Re: [PATCH 2/6] mm: Lock kernel page tables before entering lazy MMU
 mode
Message-ID: 
References: <7bd3a45dbc375dc2c15cebae09cb2bb972d6039f.1749747752.git.agordeev@linux.ibm.com>
 <0be7d42e-5898-4b94-829b-59c661c2f07b@suswa.mountain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0be7d42e-5898-4b94-829b-59c661c2f07b@suswa.mountain>

On Wed, Jun 18, 2025 at 08:32:28PM +0300, Dan Carpenter wrote:
> Hi Alexander,
> 
> kernel test robot noticed the following build warnings:
> 
> url:    https://github.com/intel-lab-lkp/linux/commits/Alexander-Gordeev/mm-Cleanup-apply_to_pte_range-routine/20250613-013835
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
> patch link:    https://lore.kernel.org/r/7bd3a45dbc375dc2c15cebae09cb2bb972d6039f.1749747752.git.agordeev%40linux.ibm.com
> patch subject: [PATCH 2/6] mm: Lock kernel page tables before entering lazy MMU mode
> config: x86_64-randconfig-161-20250613 (https://download.01.org/0day-ci/archive/20250613/202506132017.T1l1l6ME-lkp@intel.com/config)
> compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot 
> | Reported-by: Dan Carpenter 
> | Closes: https://lore.kernel.org/r/202506132017.T1l1l6ME-lkp@intel.com/
> 
> smatch warnings:
> mm/vmalloc.c:552 vmap_pages_pte_range() warn: inconsistent returns 'global &init_mm.page_table_lock'.
> 
> vim +552 mm/vmalloc.c
> 
> 0a264884046f1ab Nicholas Piggin   2021-04-29  517  static int vmap_pages_pte_range(pmd_t *pmd, unsigned long addr,
> 2ba3e6947aed9bb Joerg Roedel      2020-06-01  518  		unsigned long end, pgprot_t prot, struct page **pages, int *nr,
> 2ba3e6947aed9bb Joerg Roedel      2020-06-01  519  		pgtbl_mod_mask *mask)
> ^1da177e4c3f415 Linus Torvalds    2005-04-16  520  {
> ^1da177e4c3f415 Linus Torvalds    2005-04-16  521  	pte_t *pte;
> ^1da177e4c3f415 Linus Torvalds    2005-04-16  522  
> db64fe02258f150 Nicholas Piggin   2008-10-18  523  	/*
> db64fe02258f150 Nicholas Piggin   2008-10-18  524  	 * nr is a running index into the array which helps higher level
> db64fe02258f150 Nicholas Piggin   2008-10-18  525  	 * callers keep track of where we're up to.
> db64fe02258f150 Nicholas Piggin   2008-10-18  526  	 */
> db64fe02258f150 Nicholas Piggin   2008-10-18  527  
> 2ba3e6947aed9bb Joerg Roedel      2020-06-01  528  	pte = pte_alloc_kernel_track(pmd, addr, mask);
> ^1da177e4c3f415 Linus Torvalds    2005-04-16  529  	if (!pte)
> ^1da177e4c3f415 Linus Torvalds    2005-04-16  530  		return -ENOMEM;
> 44562c71e2cfc9e Ryan Roberts      2025-04-22  531  
> dac0cc793368851 Alexander Gordeev 2025-06-12  532  	spin_lock(&init_mm.page_table_lock);
> 44562c71e2cfc9e Ryan Roberts      2025-04-22  533  	arch_enter_lazy_mmu_mode();
> 44562c71e2cfc9e Ryan Roberts      2025-04-22  534  
> ^1da177e4c3f415 Linus Torvalds    2005-04-16  535  	do {
> db64fe02258f150 Nicholas Piggin   2008-10-18  536  		struct page *page = pages[*nr];
> db64fe02258f150 Nicholas Piggin   2008-10-18  537  
> c33c794828f2121 Ryan Roberts      2023-06-12  538  		if (WARN_ON(!pte_none(ptep_get(pte))))
> db64fe02258f150 Nicholas Piggin   2008-10-18  539  			return -EBUSY;
> db64fe02258f150 Nicholas Piggin   2008-10-18  540  		if (WARN_ON(!page))
> ^1da177e4c3f415 Linus Torvalds    2005-04-16  541  			return -ENOMEM;
> 4fcdcc12915c707 Yury Norov        2022-04-28  542  		if (WARN_ON(!pfn_valid(page_to_pfn(page))))
> 4fcdcc12915c707 Yury Norov        2022-04-28  543  			return -EINVAL;
> 
> These error paths don't unlock &init_mm.page_table_lock?
> 
> 4fcdcc12915c707 Yury Norov        2022-04-28  544  
> ^1da177e4c3f415 Linus Torvalds    2005-04-16  545  		set_pte_at(&init_mm, addr, pte, mk_pte(page, prot));
> db64fe02258f150 Nicholas Piggin   2008-10-18  546  		(*nr)++;
> ^1da177e4c3f415 Linus Torvalds    2005-04-16  547  	} while (pte++, addr += PAGE_SIZE, addr != end);
> 44562c71e2cfc9e Ryan Roberts      2025-04-22  548  
> 44562c71e2cfc9e Ryan Roberts      2025-04-22  549  	arch_leave_lazy_mmu_mode();
> dac0cc793368851 Alexander Gordeev 2025-06-12  550  	spin_unlock(&init_mm.page_table_lock);
> 2ba3e6947aed9bb Joerg Roedel      2020-06-01  551  	*mask |= PGTBL_PTE_MODIFIED;
> ^1da177e4c3f415 Linus Torvalds    2005-04-16 @552  	return 0;
> ^1da177e4c3f415 Linus Torvalds    2005-04-16  553  }
> 
> -- 
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki
> 
> 
This patch introduce a huge performance degrade when testing this by
the test_vmalloc.sh performance tool. We return back to a single, not
serialized global spilock where we spend 90% of cycles:


+   91.01%     1.67%  [kernel]          [k] _raw_spin_lock
-   89.29%    89.25%  [kernel]          [k] native_queued_spin_lock_slowpath
     69.82% ret_from_fork_asm
      - ret_from_fork
         - 69.81% kthread
            - 69.66% test_func
               - 26.31% full_fit_alloc_test
                  - 19.11% __vmalloc_node_noprof
                     - __vmalloc_node_range_noprof
                        - 13.73% vmap_small_pages_range_noflush
                             _raw_spin_lock
                             native_queued_spin_lock_slowpath
                        - 5.38% __get_vm_area_node
                             alloc_vmap_area
                             _raw_spin_lock
                             native_queued_spin_lock_slowpath
                  - 13.32% vfree.part.0
                     - 13.31% remove_vm_area
                        - 13.27% __vunmap_range_noflush
                             _raw_spin_lock
                             native_queued_spin_lock_slowpath
               - 25.57% fix_size_alloc_test
                  - 22.59% __vmalloc_node_noprof
                     - __vmalloc_node_range_noprof
                        - 17.34% vmap_small_pages_range_noflush
                             _raw_spin_lock
                             native_queued_spin_lock_slowpath
                        - 5.25% __get_vm_area_node
                             alloc_vmap_area
                             _raw_spin_lock
                             native_queued_spin_lock_slowpath
                  - 11.59% vfree.part.0
                     - remove_vm_area
                        - 11.55% __vunmap_range_noflush
                             _raw_spin_lock
                             native_queued_spin_lock_slowpath
               - 17.78% long_busy_list_alloc_test
                  - 13.90% __vmalloc_node_noprof
                     - __vmalloc_node_range_noprof
                        - 9.95% vmap_small_pages_range_noflush
                             _raw_spin_lock


No, we can not take this patch.

--
Uladzislau Rezki


From xen-devel-bounces@lists.xenproject.org Thu Jun 19 10:53:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 10:53:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019872.1396322 (Exim 4.92)
	(envelope-from )
	id 1uSCtW-0001IS-R8; Thu, 19 Jun 2025 10:53:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019872.1396322; Thu, 19 Jun 2025 10: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 1uSCtW-0001IL-OW; Thu, 19 Jun 2025 10:53:22 +0000
Received: by outflank-mailman (input) for mailman id 1019872;
 Thu, 19 Jun 2025 10:53:21 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uSCtV-0001IF-Ar
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 10:53:21 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uSCtU-009XKb-1u;
 Thu, 19 Jun 2025 10:53:20 +0000
Received: from [2a02:8012:3a1:0:3dca:1b8d:78be:b4fc]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uSCtU-00Admh-0k;
 Thu, 19 Jun 2025 10:53: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=AzZT0l5Je7VzzDNfzVeDAbQ20fPO4ZcYYmO2GMPNJ2k=; b=R1s70RVIGg/cPCH47mOmrez8+Z
	WiJtlV+Vl7OGDrF9i/UBGr5Q3N+EUx6/Yf3wP1FGLZrYIhlfA02ZXy4VybjhQfPuqWfaND4qrv6rl
	K2oUFrMs2DGNSaHLuzw2HYqijCnWL2Wj/Ua1BxksnzSe8pCEHnbskKxLYp2ypzPf0FEo=;
Message-ID: <374ccb5b-8d43-4ac8-bef9-5fd3a4d5ca76@xen.org>
Date: Thu, 19 Jun 2025 11:53:18 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 3/3] arm/mpu: Enable read/write to protection regions
 for arm32
Content-Language: en-GB
To: Ayan Kumar Halder ,
 xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Luca Fancellu , Hari Limaye 
References: <20250617111251.1711553-1-ayan.kumar.halder@amd.com>
 <20250617111251.1711553-4-ayan.kumar.halder@amd.com>
From: Julien Grall 
In-Reply-To: <20250617111251.1711553-4-ayan.kumar.halder@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Ayan,

On 17/06/2025 12:12, Ayan Kumar Halder wrote:
> Define prepare_selector(), read_protection_region() and
> write_protection_region() for arm32. Also, define
> GENERATE_{READ/WRITE}_PR_REG_OTHERS to access MPU regions from 32 to 254.
> 
> Enable pr_{get/set}_{base/limit}(), region_is_valid() for arm32.
> Enable pr_of_addr() for arm32.
> 
> The maximum number of regions supported is 255 (which corresponds to the
> maximum value in HMPUIR).
> 
> Signed-off-by: Ayan Kumar Halder 

Acked-by: Julien Grall 

Cheers,

> ---
> Changes from :-
> 
> v1 - 1. Enable write_protection_region() for aarch32.
> 
> v2 - 1. Enable access to protection regions from 0 - 255.
> 
> v3 - 1. The maximum number of regions is 255. Thus, regions numbered 0 - 254
> are supported.
> 
> 2. prepare_selector() is modified to ensure HPRSELR is written when accessing
> any region beyond 31 and the current value differs from the region number to
> be accessed.
> 
>   xen/arch/arm/include/asm/mpu.h  |   2 -
>   xen/arch/arm/mpu/Makefile       |   1 +
>   xen/arch/arm/mpu/arm32/Makefile |   1 +
>   xen/arch/arm/mpu/arm32/mm.c     | 164 ++++++++++++++++++++++++++++++++
>   xen/arch/arm/mpu/mm.c           |   2 -
>   5 files changed, 166 insertions(+), 4 deletions(-)
>   create mode 100644 xen/arch/arm/mpu/arm32/Makefile
>   create mode 100644 xen/arch/arm/mpu/arm32/mm.c
> 
> diff --git a/xen/arch/arm/include/asm/mpu.h b/xen/arch/arm/include/asm/mpu.h
> index 8f06ddac0f..63560c613b 100644
> --- a/xen/arch/arm/include/asm/mpu.h
> +++ b/xen/arch/arm/include/asm/mpu.h
> @@ -25,7 +25,6 @@
>   
>   #ifndef __ASSEMBLY__
>   
> -#ifdef CONFIG_ARM_64
>   /*
>    * Set base address of MPU protection region.
>    *
> @@ -85,7 +84,6 @@ static inline bool region_is_valid(const pr_t *pr)
>   {
>       return pr->prlar.reg.en;
>   }
> -#endif /* CONFIG_ARM_64 */
>   
>   #endif /* __ASSEMBLY__ */
>   
> diff --git a/xen/arch/arm/mpu/Makefile b/xen/arch/arm/mpu/Makefile
> index 5ad15e93be..58c9b5b4e8 100644
> --- a/xen/arch/arm/mpu/Makefile
> +++ b/xen/arch/arm/mpu/Makefile
> @@ -1,4 +1,5 @@
>   obj-$(CONFIG_ARM_32) += domain-page.o
> +obj-$(CONFIG_ARM_32) += arm32/
>   obj-$(CONFIG_ARM_64) += arm64/
>   obj-y += mm.o
>   obj-y += p2m.o
> diff --git a/xen/arch/arm/mpu/arm32/Makefile b/xen/arch/arm/mpu/arm32/Makefile
> new file mode 100644
> index 0000000000..b18cec4836
> --- /dev/null
> +++ b/xen/arch/arm/mpu/arm32/Makefile
> @@ -0,0 +1 @@
> +obj-y += mm.o
> diff --git a/xen/arch/arm/mpu/arm32/mm.c b/xen/arch/arm/mpu/arm32/mm.c
> new file mode 100644
> index 0000000000..c0317a4ada
> --- /dev/null
> +++ b/xen/arch/arm/mpu/arm32/mm.c
> @@ -0,0 +1,164 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define GENERATE_WRITE_PR_REG_CASE(num, pr)               \
> +    case num:                                             \
> +    {                                                     \
> +        WRITE_SYSREG(pr->prbar.bits, HPRBAR##num);        \
> +        WRITE_SYSREG(pr->prlar.bits, HPRLAR##num);        \
> +        break;                                            \
> +    }
> +
> +#define GENERATE_WRITE_PR_REG_OTHERS(num, pr)             \
> +    case num:                                             \
> +    {                                                     \
> +        WRITE_SYSREG(pr->prbar.bits, HPRBAR);             \
> +        WRITE_SYSREG(pr->prlar.bits, HPRLAR);             \
> +        break;                                            \
> +    }
> +
> +#define GENERATE_READ_PR_REG_CASE(num, pr)                \
> +    case num:                                             \
> +    {                                                     \
> +        pr->prbar.bits = READ_SYSREG(HPRBAR##num);        \
> +        pr->prlar.bits = READ_SYSREG(HPRLAR##num);        \
> +        break;                                            \
> +    }
> +
> +#define GENERATE_READ_PR_REG_OTHERS(num, pr)              \
> +    case num:                                             \
> +    {                                                     \
> +        pr->prbar.bits = READ_SYSREG(HPRBAR);             \
> +        pr->prlar.bits = READ_SYSREG(HPRLAR);             \
> +        break;                                            \
> +    }
> +
> +/*
> + * Armv8-R supports direct access and indirect access to the MPU regions through
> + * registers:
> + *  - indirect access involves changing the MPU region selector, issuing an isb
> + *    barrier and accessing the selected region through specific registers
> + *  - direct access involves accessing specific registers that point to
> + *    specific MPU regions, without changing the selector, avoiding the use of
> + *    a barrier.
> + * For Arm32 the HPR{B,L}AR (for n=0..31) are used for direct access to the
> + * first 32 MPU regions.
> + * For MPU region numbered 32..254, one need to set the region number in HPRSELR,
> + * followed by configuring HPR{B,L}AR.
> + */
> +static void prepare_selector(uint8_t *sel)
> +{
> +    uint8_t cur_sel = *sel;
> +    /* The top 24 bits of HPRSELR are RES0. */
> +    uint8_t val = READ_SYSREG(HPRSELR) & 0xff;
> +
> +    if ( (cur_sel > 31) && (cur_sel != val) )
> +    {
> +        WRITE_SYSREG(cur_sel, HPRSELR);
> +        isb();
> +    }
> +}
> +
> +void read_protection_region(pr_t *pr_read, uint8_t sel)
> +{
> +    prepare_selector(&sel);
> +
> +    switch ( sel )
> +    {
> +        GENERATE_READ_PR_REG_CASE(0, pr_read);
> +        GENERATE_READ_PR_REG_CASE(1, pr_read);
> +        GENERATE_READ_PR_REG_CASE(2, pr_read);
> +        GENERATE_READ_PR_REG_CASE(3, pr_read);
> +        GENERATE_READ_PR_REG_CASE(4, pr_read);
> +        GENERATE_READ_PR_REG_CASE(5, pr_read);
> +        GENERATE_READ_PR_REG_CASE(6, pr_read);
> +        GENERATE_READ_PR_REG_CASE(7, pr_read);
> +        GENERATE_READ_PR_REG_CASE(8, pr_read);
> +        GENERATE_READ_PR_REG_CASE(9, pr_read);
> +        GENERATE_READ_PR_REG_CASE(10, pr_read);
> +        GENERATE_READ_PR_REG_CASE(11, pr_read);
> +        GENERATE_READ_PR_REG_CASE(12, pr_read);
> +        GENERATE_READ_PR_REG_CASE(13, pr_read);
> +        GENERATE_READ_PR_REG_CASE(14, pr_read);
> +        GENERATE_READ_PR_REG_CASE(15, pr_read);
> +        GENERATE_READ_PR_REG_CASE(16, pr_read);
> +        GENERATE_READ_PR_REG_CASE(17, pr_read);
> +        GENERATE_READ_PR_REG_CASE(18, pr_read);
> +        GENERATE_READ_PR_REG_CASE(19, pr_read);
> +        GENERATE_READ_PR_REG_CASE(20, pr_read);
> +        GENERATE_READ_PR_REG_CASE(21, pr_read);
> +        GENERATE_READ_PR_REG_CASE(22, pr_read);
> +        GENERATE_READ_PR_REG_CASE(23, pr_read);
> +        GENERATE_READ_PR_REG_CASE(24, pr_read);
> +        GENERATE_READ_PR_REG_CASE(25, pr_read);
> +        GENERATE_READ_PR_REG_CASE(26, pr_read);
> +        GENERATE_READ_PR_REG_CASE(27, pr_read);
> +        GENERATE_READ_PR_REG_CASE(28, pr_read);
> +        GENERATE_READ_PR_REG_CASE(29, pr_read);
> +        GENERATE_READ_PR_REG_CASE(30, pr_read);
> +        GENERATE_READ_PR_REG_CASE(31, pr_read);
> +        GENERATE_READ_PR_REG_OTHERS(32 ... 254, pr_read);
> +    default:
> +        BUG(); /* Can't happen */
> +        break;
> +    }
> +}
> +
> +void write_protection_region(const pr_t *pr_write, uint8_t sel)
> +{
> +    prepare_selector(&sel);
> +
> +    switch ( sel )
> +    {
> +        GENERATE_WRITE_PR_REG_CASE(0, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(1, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(2, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(3, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(4, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(5, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(6, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(7, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(8, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(9, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(10, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(11, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(12, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(13, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(14, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(15, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(16, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(17, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(18, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(19, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(20, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(21, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(22, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(23, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(24, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(25, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(26, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(27, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(28, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(29, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(30, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(31, pr_write);
> +        GENERATE_WRITE_PR_REG_OTHERS(32 ... 254, pr_write);
> +    default:
> +        BUG(); /* Can't happen */
> +        break;
> +    }
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
> index 7ab68fc8c7..ccfb37a67b 100644
> --- a/xen/arch/arm/mpu/mm.c
> +++ b/xen/arch/arm/mpu/mm.c
> @@ -39,7 +39,6 @@ static void __init __maybe_unused build_assertions(void)
>       BUILD_BUG_ON(PAGE_SIZE != SZ_4K);
>   }
>   
> -#ifdef CONFIG_ARM_64
>   pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags)
>   {
>       unsigned int attr_idx = PAGE_AI_MASK(flags);
> @@ -110,7 +109,6 @@ pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags)
>   
>       return region;
>   }
> -#endif /* CONFIG_ARM_64 */
>   
>   void __init setup_mm(void)
>   {

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Thu Jun 19 11:24:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 11:24:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019900.1396333 (Exim 4.92)
	(envelope-from )
	id 1uSDNW-0005ko-6j; Thu, 19 Jun 2025 11:24:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019900.1396333; Thu, 19 Jun 2025 11:24: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 1uSDNW-0005kh-3F; Thu, 19 Jun 2025 11:24:22 +0000
Received: by outflank-mailman (input) for mailman id 1019900;
 Thu, 19 Jun 2025 11:24: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 1uSDNU-0005kb-Bw
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 11:24:20 +0000
Received: from fout-a7-smtp.messagingengine.com
 (fout-a7-smtp.messagingengine.com [103.168.172.150])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ef755d65-4cff-11f0-b894-0df219b8e170;
 Thu, 19 Jun 2025 13:24:17 +0200 (CEST)
Received: from phl-compute-01.internal (phl-compute-01.phl.internal
 [10.202.2.41])
 by mailfout.phl.internal (Postfix) with ESMTP id 0254C1380645;
 Thu, 19 Jun 2025 07:24:16 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-01.internal (MEProxy); Thu, 19 Jun 2025 07:24:16 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 19 Jun 2025 07:24:14 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ef755d65-4cff-11f0-b894-0df219b8e170
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=1750332255; x=1750418655; bh=6Z
	9/mjif2iMkkUhK1vyWLAD+QEZ+bviX4PNajj4c42s=; b=Dgpab3/GOuMyX9/jSg
	F3FmaXxamBjqLIYewtOB6WABjs4BGVvVkaOZWL+4mfo5626KBmc8DOtFdvRt/ABB
	nR9TE1ZFGkSOhTeXwuZEZWH8AMPfzol/NH0OII3RoqT6QcjKxILINKMOS9WANaMJ
	gJcN2bGS1i5WDT4JoRfJS8sQ1N4M9oqQg4pAMyFEtGJ+sygKnxxh0zqrFf4M0O0m
	xFNWjdA30hzkZzLTTp/9IfalY8dz9NM/98+bNlqUEi7+BMFy6nuZ+HmdUMNvIc4T
	lSIs32B4BTga3DASCiw0au1OrrCuGyarr2umSg3NzRGfSYKeKE0t9YN9akYmkW1N
	2oUA==
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=1750332255; x=
	1750418655; bh=6Z9/mjif2iMkkUhK1vyWLAD+QEZ+bviX4PNajj4c42s=; b=O
	GV6uCShgtArJmrkRkGok5MwtYYtMo1JAbP7jyLFIAHtpM8yS82+CBctGjw9IUowF
	jj/oNQ27/Dt1s9rnps9nGjP8gCZHJOBEIgD8NBHQJGNQD8PMqiVl9WBOepxA01EO
	oEMXE8IOWGKjP9ZKIrP7zkGTFklu1NbYetarcX9rGhZfY07kVGthii9C8qVhnMba
	fB07vVj4OcQWnnonxRspksN+4XBthEHUJeEA1V2kOSoPvVx7yeYaMOnR1r7M3Qg3
	jVOi0MmHM7Wv01GuGMwoAhI1RLJ18BYxWLUbzD/CVuVDAV9RIJIS7uj6j0dFynWq
	0BHtDSAkdOl+MargT794g==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgdehfeelucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceurghi
    lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh
    epfffhvfevuffkgggtugesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcuofgrrhgt
    iiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvihhsihgslh
    gvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepjeehgfdvfffhffdv
    ffdvfeefueevgefgiedukeegveffteffhffggeehueejuedunecuffhomhgrihhnpehqvg
    hmuhdrohhrghdpghhithhhuhgsrdgtohhmpdhquhgsvghsqdhoshdrohhrghenucevlhhu
    shhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkh
    esihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopeeh
    pdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegurghvvgdrhhgrnhhsvghnsehlih
    hnuhigrdhinhhtvghlrdgtohhmpdhrtghpthhtoheplhhuthhosehkvghrnhgvlhdrohhr
    ghdprhgtphhtthhopehpvghtvghriiesihhnfhhrrgguvggrugdrohhrghdprhgtphhtth
    hopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdprhgt
    phhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrgh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Thu, 19 Jun 2025 13:24:13 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Dave Hansen ,
	Andy Lutomirski ,
	Peter Zijlstra 
Cc: xen-devel ,
	linux-kernel@vger.kernel.org
Subject: Xen PV dom0 "tried to execute NX-protected page" when running nested
 in KVM - 6.15 regression
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="C//JR/PbyCGvU4J9"
Content-Disposition: inline


--C//JR/PbyCGvU4J9
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 19 Jun 2025 13:24:13 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Dave Hansen ,
	Andy Lutomirski ,
	Peter Zijlstra 
Cc: xen-devel ,
	linux-kernel@vger.kernel.org
Subject: Xen PV dom0 "tried to execute NX-protected page" when running nested
 in KVM - 6.15 regression

Hi,

With Linux 6.15.2 I got a crash like below. It worked fine with Linux
6.14.11. Furthermore, the failure seems to be hardware-dependent. It
happens when running on Intel Core i9-13900H, but does not happen when
running on Intel Xeon E5-2620v4 (in both cases QEMU uses -cpu host).

The crash:
[    1.121608] ITS: Mitigation: Aligned branch/return thunks
[    1.122604] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point=
 registers'
[    1.123656] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[    1.124603] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[    1.125603] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[    1.126599] x86/fpu: Enabled xstate features 0x7, context size is 832 by=
tes, using 'compacted' format.
[    1.128391] kernel tried to execute NX-protected page - exploit attempt?=
 (uid: 0)
[    1.128391] kernel tried to execute NX-protected page - exploit attempt?=
 (uid: 0)
[    1.128391] BUG: unable to handle page fault for address: ffffffffc00007=
60
[    1.128391] #PF: supervisor instruction fetch in kernel mode
[    1.128391] #PF: error_code(0x0011) - permissions violation
[    1.128391] PGD 2433067 P4D 2433067 PUD 2435067 PMD 1002b7067 PTE 801000=
01002b6067
[    1.128391] Oops: Oops: 0011 [#1] SMP NOPTI
[    1.128391] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.15.2-1.qu=
bes.fc41.x86_64 #1 PREEMPT(full)=20
[    1.128391] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel=
-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014
[    1.128391] RIP: e030:0xffffffffc0000760
[    1.128391] Code: e0 cc ff e0 cc ff e0 cc cc cc cc cc cc cc cc cc cc cc =
cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  e0 cc ff e0 cc ff e0 cc ff e0 cc ff e0 cc ff e0 cc ff e0 cc ff
[    1.128391] RSP: e02b:ffffc90040003b60 EFLAGS: 00010002
[    1.128391] RAX: ffffffff80f02190 RBX: ffffffff834da1b5 RCX: 00000000fff=
fffff
[    1.128391] RDX: ffffc90040003b78 RSI: 0000000000000001 RDI: ffff8881002=
9f400
[    1.128391] RBP: ffffc90040003b78 R08: 0000000000000000 R09: 205d3139333=
83231
[    1.128391] R10: 0000000000000029 R11: 000000006e72656b R12: 00000000000=
0000a
[    1.128391] R13: ffffffff834da1b5 R14: 0000000000000000 R15: ffff8881002=
9f400
[    1.128391] FS:  0000000000000000(0000) GS:ffff8881fc9c8000(0000) knlGS:=
0000000000000000
[    1.128391] CS:  e030 DS: 0000 ES: 0000 CR0: 0000000080050033
[    1.128391] CR2: ffffffffc0000760 CR3: 000000000242e000 CR4: 00000000000=
50660
[    1.128391] Call Trace:
[    1.128391]  
[    1.128391]  ? vt_console_print+0x2e6/0x500
[    1.128391]  ? console_emit_next_record+0x110/0x1b0
[    1.128391]  ? console_flush_all+0x1d5/0x2a0
[    1.128391]  ? console_unlock+0x7c/0x140
[    1.128391]  ? vprintk_emit+0x278/0x2d0
[    1.128391]  ? _printk+0x6b/0x90
[    1.128391]  ? show_fault_oops+0x17c/0x1b0
[    1.128391]  ? page_fault_oops+0x11b/0x160
[    1.128391]  ? exc_page_fault+0x189/0x1a0
[    1.128391]  ? asm_exc_page_fault+0x26/0x30
[    1.128391]  ? __pfx_evtchn_fifo_clear_pending+0x10/0x10
[    1.128391]  ? handle_percpu_irq+0x30/0x60
[    1.128391]  ? generic_handle_irq+0x3c/0x60
[    1.128391]  ? __evtchn_fifo_handle_events+0x1df/0x2c0
[    1.128391]  ? xen_evtchn_do_upcall+0x6d/0xc0
[    1.128391]  ? __xen_pv_evtchn_do_upcall+0x26/0x40
[    1.128391]  ? xen_pv_evtchn_do_upcall+0x84/0xa0
[    1.128391]  
[    1.128391]  
[    1.128391]  ? exc_xen_hypervisor_callback+0x8/0x20
[    1.128391]  ? print_bpf_insn+0x322/0xb70
[    1.128391]  ? xen_save_fl_direct+0xf/0x20
[    1.128391]  ? text_poke_early+0x35/0xa0
[    1.128391]  ? print_bpf_insn+0x322/0xb70
[    1.128391]  ? apply_retpolines+0x1ad/0x1d0
[    1.128391]  ? print_bpf_insn+0x322/0xb70
[    1.128391]  ? print_bpf_insn+0x331/0xb70
[    1.128391]  ? print_bpf_insn+0x328/0xb70
[    1.128391]  ? alternative_instructions+0x56/0x200
[    1.128391]  ? arch_cpu_finalize_init+0x80/0x120
[    1.128391]  ? start_kernel+0x3f5/0x490
[    1.128391]  ? x86_64_start_reservations+0x24/0x30
[    1.128391]  ? xen_start_kernel+0x6d7/0x6f0
[    1.128391]  ? startup_xen+0x1b/0x20
[    1.128391]  
[    1.128391] Modules linked in:
[    1.128391] CR2: ffffffffc0000760
[    1.128391] ---[ end trace 0000000000000000 ]---
[    1.128391] RIP: e030:0xffffffffc0000760
[    1.128391] Code: e0 cc ff e0 cc ff e0 cc cc cc cc cc cc cc cc cc cc cc =
cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  e0 cc ff e0 cc ff e0 cc ff e0 cc ff e0 cc ff e0 cc ff e0 cc ff
[    1.128391] RSP: e02b:ffffc90040003b60 EFLAGS: 00010002
[    1.128391] RAX: ffffffff80f02190 RBX: ffffffff834da1b5 RCX: 00000000fff=
fffff
[    1.128391] RDX: ffffc90040003b78 RSI: 0000000000000001 RDI: ffff8881002=
9f400
[    1.128391] RBP: ffffc90040003b78 R08: 0000000000000000 R09: 205d3139333=
83231
[    1.128391] R10: 0000000000000029 R11: 000000006e72656b R12: 00000000000=
0000a
[    1.128391] R13: ffffffff834da1b5 R14: 0000000000000000 R15: ffff8881002=
9f400
[    1.128391] FS:  0000000000000000(0000) GS:ffff8881fc9c8000(0000) knlGS:=
0000000000000000
[    1.128391] CS:  e030 DS: 0000 ES: 0000 CR0: 0000000080050033
[    1.128391] CR2: ffffffffc0000760 CR3: 000000000242e000 CR4: 00000000000=
50660
[    1.128391] Kernel panic - not syncing: Fatal exception in interrupt

Full console log: https://gist.github.com/marmarek/7a4ad628c7bf76339aed79ff=
4478f8ea

Full QEMU command (if relevant) can be seen at https://openqa.qubes-os.org/=
tests/143860/logfile?filename=3Dautoinst-log.txt

At this point, I'm not even sure who to report it to... In an earlier
attempt I've got stack trace full of ext4 functions, which is unlikely
relevant (see revisions of the gist linked above). I'll try to bisect
this, but due to hardware-dependent nature it will take some time as I
have a bit limited access to that hardware.

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

--C//JR/PbyCGvU4J9
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmhT810ACgkQ24/THMrX
1yzzUgf6Av5gJw8K4okkye7Visd73CpLE89qp7hDSv68SJVgW2jsr16One3mWe6P
2jdd130SzYRE6MbdvM6Yoh0ciJdp+S2j0AT0Tkr5pFmNv/qGwd1hm1NFtq/fxnhS
JgYW7SVMu4dJPBm8PAqxgaktcJ/DjHsXGI2YqpBXd2xENxyPzjMc4ZdNPQrf9H+I
OOSIVYYGNNvPH2T3CSdAJ7whq8Ns8kN64NkjqsTjpKWXojKAkPLfsvneZcT8vT3s
hIcrrvRMYJdKXUNxN56CJPVOeI/eajqY6eo7QRf3vUq20QGShrdOMGhRSpva1qHH
4VSIfLhg/cMBJixR4xOjv4hYTXbn0w==
=cP1H
-----END PGP SIGNATURE-----

--C//JR/PbyCGvU4J9--


From xen-devel-bounces@lists.xenproject.org Thu Jun 19 11:31:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 11:31:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019918.1396344 (Exim 4.92)
	(envelope-from )
	id 1uSDUO-0007XH-UP; Thu, 19 Jun 2025 11:31:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019918.1396344; Thu, 19 Jun 2025 11:31: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 1uSDUO-0007XA-P9; Thu, 19 Jun 2025 11:31:28 +0000
Received: by outflank-mailman (input) for mailman id 1019918;
 Thu, 19 Jun 2025 11:31: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 1uSDUM-0007Wn-Tl
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 11:31:26 +0000
Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com
 [2a00:1450:4864:20::441])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ee0a10da-4d00-11f0-b894-0df219b8e170;
 Thu, 19 Jun 2025 13:31:23 +0200 (CEST)
Received: by mail-wr1-x441.google.com with SMTP id
 ffacd0b85a97d-3a50fc819f2so599513f8f.2
 for ; Thu, 19 Jun 2025 04:31:23 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a568b74313sm19471221f8f.96.2025.06.19.04.31.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 19 Jun 2025 04:31:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ee0a10da-4d00-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750332683; x=1750937483; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=5ehJkgAbyggEQYCYMmY956XgyfrGZO0hGxlzMuYgDhw=;
        b=ZhqGlx4PBduRJVpb8w1S73FGcy3FOAfoqy+udDKe/sx/eJlRFYc/KeIiE/l8q0349p
         kXFvnaK9bqASHbBzr0tqBayKMkxZmSfAqcLjWKHXG1W7HRgX6pcYDpCxD6D/fcm8w/oA
         I/vOZ+QrkpXwrHUPi56kq4HZY//irK7ldGXnw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750332683; x=1750937483;
        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=5ehJkgAbyggEQYCYMmY956XgyfrGZO0hGxlzMuYgDhw=;
        b=u9lm8TA13Pqs16FB/prAzGzIvm5XOdON6VQrZKISTqaDwTFK9PyrTR7hbvzqo1fdQ8
         7RDnhB7ZNuMytoU6OLPz5AlsgdJVwm3wVsstBN6ZLOUBoFJUQXMd9LgmE48FP+7g/6ht
         8oiI54HatQSiJyeBiju9Bf7s9JaTvqUvo/4CO267D5R/VO6EQsA7fJbNcCCdG2fI/LnR
         M+DnfGBnR669aY/2f9aOdU9Ghfq2ZCRYkJ/QF0ANjp+aQX8EgF+R40j77b8wDFzR481I
         CnvJhJ2ypkBxq0MeVShan24XV+SyIlgjSedo3YqG88l4BCngAQMb8UkOIHK9ptsesNGu
         eI2A==
X-Gm-Message-State: AOJu0YynXNfc4Sa9pUZRDHlcj74Ru3ctJ94I221m9du1TD9wYOR7w8ho
	HZBqhvusGRkUeHfcordOudR/WRa90Mujw76tjXszHe7POBM2mIRi2bOwB1j14xABBmY=
X-Gm-Gg: ASbGnct0L4SxBtLcp05M5296/M6bKaYLpp3ezNv7kqAgvdSsw+dHevnGJEPcJZ2qfTO
	wZEtrHdiWtkSw7aO68I+DoCM5IYy8GUlllj5GpcXnvILsKpG/hRpDyCVz6jgyI3abyOkCeGVPlQ
	EQpQpPlrlc4gOn4mUNeoIyejS3NNG+eEEjSEu4rRmZeBP+gH1sh587/tpInDMVWWct5BizjEito
	K9z7eXeg6OxCpnYxY7LtJWOT4AwLBt1TKjC5BQJ1gN7I1mpJHqVNFqZAfq9sucnJaNAtAgxcXvz
	840HKv2xg6cAn1IhGfche/Oy+cJmeP1C0tGsfvjc6H3WtGfHvg4IBFpZwWBmhkx3LA0zGUTXW85
	Kj2fp/BbDhHFgD0PVGn1BqHb3i3RZTgvmdpL+vA==
X-Google-Smtp-Source: AGHT+IGxkwun+ifyV59KufsXNv7Ckg+d7lxDOQOaYgTNfK2qaTapjjfUwlMwJunAE7mrRblG2Psqvg==
X-Received: by 2002:a05:6000:144d:b0:3a1:fe77:9e1d with SMTP id ffacd0b85a97d-3a5723a3aebmr18322608f8f.16.1750332683232;
        Thu, 19 Jun 2025 04:31:23 -0700 (PDT)
Message-ID: <2c24aca9-5e67-4c0f-b890-92a0ad8e1975@citrix.com>
Date: Thu, 19 Jun 2025 12:31:22 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Xen PV dom0 "tried to execute NX-protected page" when running
 nested in KVM - 6.15 regression
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , Dave Hansen
 , Andy Lutomirski ,
 Peter Zijlstra 
Cc: xen-devel , linux-kernel@vger.kernel.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: 8bit

On 19/06/2025 12:24 pm, Marek Marczykowski-Górecki wrote:
> Hi,
>
> With Linux 6.15.2 I got a crash like below. It worked fine with Linux
> 6.14.11. Furthermore, the failure seems to be hardware-dependent. It
> happens when running on Intel Core i9-13900H, but does not happen when
> running on Intel Xeon E5-2620v4 (in both cases QEMU uses -cpu host).

Yes, it's a known regression in Linux's ITS / CVE-2024-28956 patches.

https://lore.kernel.org/lkml/20250603111446.2609381-1-rppt@kernel.org/

It's hardware-dependent because so is Indirect Target Selection.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Jun 19 11:32:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 11:32:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019927.1396352 (Exim 4.92)
	(envelope-from )
	id 1uSDV0-0007zL-3N; Thu, 19 Jun 2025 11:32:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019927.1396352; Thu, 19 Jun 2025 11: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 1uSDV0-0007zE-0Y; Thu, 19 Jun 2025 11:32:06 +0000
Received: by outflank-mailman (input) for mailman id 1019927;
 Thu, 19 Jun 2025 11:32: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 1uSDUx-0007Mw-Mf
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 11:32:03 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on2060d.outbound.protection.outlook.com
 [2a01:111:f403:2414::60d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0474bbbb-4d01-11f0-a30c-13f23c93f187;
 Thu, 19 Jun 2025 13:32:02 +0200 (CEST)
Received: from MW4PR04CA0122.namprd04.prod.outlook.com (2603:10b6:303:84::7)
 by IA1PR12MB8189.namprd12.prod.outlook.com (2603:10b6:208:3f0::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.30; Thu, 19 Jun
 2025 11:31:57 +0000
Received: from SJ5PEPF000001F3.namprd05.prod.outlook.com
 (2603:10b6:303:84:cafe::30) by MW4PR04CA0122.outlook.office365.com
 (2603:10b6:303:84::7) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8857.25 via Frontend Transport; Thu,
 19 Jun 2025 11:31:57 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SJ5PEPF000001F3.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.8857.21 via Frontend Transport; Thu, 19 Jun 2025 11:31:56 +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 Jun
 2025 06:31:55 -0500
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 Jun 2025 06:31:54 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0474bbbb-4d01-11f0-a30c-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=A0UZHZf2gAPbF96u4ixmErxzCZ45bh0YEyHASc1j5hOym2RjGuIU1lZY1sRI2iFYROPaBOF/MIjdurnJI5v+EJI+sPsG2wB/clYYjAelBEKsjywjLoLUB3MslUgE9epGBE3yOvwAHz12O7xRWV1Ks7oCyeB4HpTcRJG8qAwmRtmjCZNLiD9C7hlYq+DeqgigAhg/DknxDssYjB2hfp7s4FS69rkaYg9CV0LOJcuTEPu9zVMAjyiholNn1aPYeqiHgmmMtMKCl1oVceUhYPY5Q9IKvslYuwgj4QnM03ogQ16aq2X20X34w+M+g5kqjxOIZJQBcYWwUz7JrM8176kmTg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=HooSTqeLCbJkoAt7mZmcyMQ5aEtx66wS1a/XY63qipo=;
 b=dWSzOC+Dv1xXi93ESJZjD9wWZp7MFpq2iclRwo2O9sDuK0nz6rroHuiLdFa5PGK7JJig5zvFp7Tu+2OdssRbC/0NQ4VULIhAf/17icvH2rZ30MsJs2dtiYFHIT3ujU8MUgOs6636+Kw04BHHXhNzT0c8XZhQhD1HmR5yDBEQU6Dnse64UZW3OLgTH24AQZjNhLC9rZQ76NjocOlMSMtu3fgPK9642IQdU6dhH3bqPPj/jP9WS4WpdgqtCWMyh+ezeLzM55305yllObTI3HUBfBgcez/Z4MBfF72weRnOhpdNLEkZhPgw9707a2nsP38/7sLKM+fGvkPq9mjZ+NHQ8w==
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=HooSTqeLCbJkoAt7mZmcyMQ5aEtx66wS1a/XY63qipo=;
 b=Q/fLnGG0rrpH1LskHYjEUq2A0lRZX58XcrgR7z42fJkJeC9RDarWFn+EkiN+VSb0kjShN4Ps2a0I/Z+xtyWaCwwDfXFzs7z3AdV6x1sax6AKnXnA0Q2FM3daoNi1tZWkWZjATBIbhN6OfHOGBv83oBslTOzRkSmNxq1OcT5IePY=
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: Ayan Kumar Halder , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" 
Subject: [PATCH v5 0/3] Enable R52 support for the first chunk of MPU support
Date: Thu, 19 Jun 2025 12:31:49 +0100
Message-ID: <20250619113152.2723066-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: SJ5PEPF000001F3:EE_|IA1PR12MB8189:EE_
X-MS-Office365-Filtering-Correlation-Id: 6f16f029-e071-485d-caf6-08ddaf24e5c4
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?Ws0WRsV+YAjTav9Pvmon2o/lj2DsMoipFHCS2l8j9NaKHoDWkK4C/acv9+Yj?=
 =?us-ascii?Q?r+pfIGOcK/LMhtZCunmz3LfluIHklUiI1MMOHZuP2JPpQw/HzZNDiGlHeW8E?=
 =?us-ascii?Q?sPc7pGz/5184FoXROgwjL/MzLZfG87S0Kz4svSxxhONkJdXI6oDtUMWXQsLE?=
 =?us-ascii?Q?qJfvvtJgns5uAK5ojFgfRu1t40fEi0rrjZUCjy+Bo2twCItiiCx00899M0s7?=
 =?us-ascii?Q?oL4KKiraDVc97eYv7eJK6xMMLejHZOFo7jy3JwvaZXiH+J+YqY3MQBrqDYED?=
 =?us-ascii?Q?oJ9gxfVGuZ0QFQh7CqmdLpz+hWCc1xSVHoXoiVH/yiEiP4ad2BR75bgQhKkb?=
 =?us-ascii?Q?S0pwejjNVenw7Ng0O72bUemmLiBXTaoDrutoxvZ+X7zDdL08YUcQUHeR0lpj?=
 =?us-ascii?Q?lWg7XR3cCd9pxIg8beVFyLDpiObdHnvLMXVR6hDng7AknG3DZ/QLs82o/1S6?=
 =?us-ascii?Q?ekiANm/+IFnifLiU1SKCFdau4uNDHZ7G637Lutb4JDMdbXSYaVMZVTwgsgOv?=
 =?us-ascii?Q?cAsQ4ccx7LbUXHyOhI2mYzOul2J8fYjDMpMMHyVatoiU+jGcmENKvqxn0Qg8?=
 =?us-ascii?Q?zaHaLFYvckoITbowAjMKkUjsNb/kZd8rHxbRb88/62NslDUxxSkljkkD/jqV?=
 =?us-ascii?Q?eNza5zCkbRu08BStY/+JiNjK9mcV3sAHPuwl/RggJWyzJW1GwDO0Mvyy8zMC?=
 =?us-ascii?Q?ILC3Qe+262ybyrPRqrR2QJW8Un9eefvFTfy1qGEakcqZYBwfji8hkbJtxD+u?=
 =?us-ascii?Q?DIoVoG7kpErUlKDM29M+yXcdaBGmnrbqwF2dX1hWTtDQm7g+W9jUkjmP2/ff?=
 =?us-ascii?Q?4EJTiTrktjOtuq2+bdKtZ+8/ctR+Eka1vEWkUQjXz4SPByTkgPBDO4jHTvvJ?=
 =?us-ascii?Q?mdLKOIA9h1IKhd11s7TNFy3aNJZR0L0YkLwuiAuMfehqYBtmx9JN+t8DkCsr?=
 =?us-ascii?Q?mRVbhioMyY6Yrf/M3iSGQaHZGvjXM7Eh+MMe7FOfWWUdQmSllw+wmwruBau7?=
 =?us-ascii?Q?LtfTltUaF/MmHsqlb64FOWoYi2QIgCdGsub/DzxeAOErr/wFcd0dVuYe1UJo?=
 =?us-ascii?Q?UYl5kkiU1PlCNi4sbhm3DL33Ra1o0XeytDCkQQxcbeRIVZlMOTULMJfGZEa9?=
 =?us-ascii?Q?Xe0KJ24yk6RmNhknDvBjlxY9ozlfgUJXOsvcgnhIiz9qhUak581bGZcmlRSj?=
 =?us-ascii?Q?m8d7/cIeEwEXNar5barq5eqLHowJWOd3SrYGbkPqHqOFLNZD8Uo+KgHbUG8n?=
 =?us-ascii?Q?3BfZgM1sziMgoWcYFNs2QM5mt3n1gv7hmWW0TxXMe6hZOIVtWbQHB+vWFFQ6?=
 =?us-ascii?Q?5RgPKOC+rTtq1RmHLKMuNbzV9obuxrH6OJAthqN72Y2n6tZSNU2wYFiyfkRa?=
 =?us-ascii?Q?Tdc7o+34t9junrLjIJ8bAP+f40S3VpFpxx55Mb2hlPumVjJ1ikKcFQbnqV4Y?=
 =?us-ascii?Q?lxCb1Q6U9TQBDsLzWb0AMpnCd2BPhBgu66RW7Q23oSvzpDWopIOszB4+EYMH?=
 =?us-ascii?Q?r5zZHLI95bpajF+88etSCTf/ce/h1RR7AA2o?=
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: 19 Jun 2025 11:31:56.3674
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 6f16f029-e071-485d-caf6-08ddaf24e5c4
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:
	SJ5PEPF000001F3.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB8189

Hi all,

This patch serie enables R52 support based on Luca's series.
"[PATCH v6 0/6] First chunk for Arm R82 and MPU support".

Changes from :-

v1 - Changes mentioned in individual patches

v2 - Split "arm/mpu: Provide access to the MPU region from the C code"
into 4 patches.

v3 - Patches 1,2 are merged. Patch 3 is dropped.

v4 - Add R-b, A-b, T-b tags to the individual patches.

Ayan Kumar Halder (3):
  arm/mpu: Move the functions to arm64 specific files
  arm/mpu: Define arm32 system registers
  arm/mpu: Enable read/write to protection regions for arm32

 xen/arch/arm/include/asm/mpu.h        |   2 -
 xen/arch/arm/include/asm/mpu/cpregs.h |  68 ++++++++++-
 xen/arch/arm/mpu/Makefile             |   2 +
 xen/arch/arm/mpu/arm32/Makefile       |   1 +
 xen/arch/arm/mpu/arm32/mm.c           | 164 ++++++++++++++++++++++++++
 xen/arch/arm/mpu/arm64/Makefile       |   1 +
 xen/arch/arm/mpu/arm64/mm.c           | 130 ++++++++++++++++++++
 xen/arch/arm/mpu/mm.c                 | 119 -------------------
 8 files changed, 365 insertions(+), 122 deletions(-)
 create mode 100644 xen/arch/arm/mpu/arm32/Makefile
 create mode 100644 xen/arch/arm/mpu/arm32/mm.c
 create mode 100644 xen/arch/arm/mpu/arm64/Makefile
 create mode 100644 xen/arch/arm/mpu/arm64/mm.c

-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Thu Jun 19 11:32:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 11:32:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019931.1396362 (Exim 4.92)
	(envelope-from )
	id 1uSDVE-0008My-Cq; Thu, 19 Jun 2025 11:32:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019931.1396362; Thu, 19 Jun 2025 11:32: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 1uSDVE-0008Mr-AG; Thu, 19 Jun 2025 11:32:20 +0000
Received: by outflank-mailman (input) for mailman id 1019931;
 Thu, 19 Jun 2025 11: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 1uSDVC-0008L0-R1
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 11:32:18 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20600.outbound.protection.outlook.com
 [2a01:111:f403:2412::600])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0c988dd9-4d01-11f0-b894-0df219b8e170;
 Thu, 19 Jun 2025 13:32:16 +0200 (CEST)
Received: from SJ0PR03CA0343.namprd03.prod.outlook.com (2603:10b6:a03:39c::18)
 by CH3PR12MB8260.namprd12.prod.outlook.com (2603:10b6:610:12a::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Thu, 19 Jun
 2025 11:32:10 +0000
Received: from SJ5PEPF000001F6.namprd05.prod.outlook.com
 (2603:10b6:a03:39c:cafe::66) by SJ0PR03CA0343.outlook.office365.com
 (2603:10b6:a03:39c::18) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.23 via Frontend Transport; Thu,
 19 Jun 2025 11:32:10 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SJ5PEPF000001F6.mail.protection.outlook.com (10.167.242.74) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8857.21 via Frontend Transport; Thu, 19 Jun 2025 11:32:09 +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, 19 Jun
 2025 06:32:09 -0500
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, 19 Jun
 2025 06:32:08 -0500
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 Jun 2025 06:32:07 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0c988dd9-4d01-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=LVpejLTpk9Pk3OI7SKChB54XbXn5saqZfe72wsdJG1hVxGb2iME6gfI9VEG1fPslqvI23a317DdmVH3pOCaJzPawnA9IS9WiTuYbeZBtQ3nOil9BHKZyjzWObpmPP0okwh27YcxTUN7inih33x50zvDp7b/YJsvcd3EfThHnBd7ELSz6Apjb3OfHTDvmUPxObOkx/GmgCsBZg+8zAwMhkzXvwBt2NxMZ1D8TfwLithByQDcsJjDVIzigYpOU3uu038oRSjg2SUKG4scWSZBOtT5tIhEDIVWwniwgDgrLCV4EmzTqsPE714NCrbq0jjTbac84Jq+FKUgU9mVlXPPssQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=5s4GGT52wwqQbVT7LJgFLwX9PKdeY1TSAVFmN+Or72k=;
 b=ZqRR5Iu4VLAJw8lKzioD98GKYZzHbn4imzkVRlWV9L0wAXw3MsI6lyB6V1GwhHRwasvDL6w1YCbFQ/95QxLfsxs4m0baphQjMxRVYwoSmvaDXxwC9qCQ/egV/NWpawNHH5DRYzqIRZgj10Jb7ieTLGLPElQc9JQDYAXvS9uQtbjgv6p6W0MJgP7qEWqitihHDS5138CIOxv9kbE/BskmkvUC98o8XOGsA8S9ULwo+pdTqzaCIfl3/5tLp7TTklG/+0AZBXEJndJ9SAQIt1ds4YSaCGqAT73GJRlWMF4nV7t2c1sHq6w3PocroVCI1tJjsLm3yo3KC0vT3tjV/CwFoA==
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=5s4GGT52wwqQbVT7LJgFLwX9PKdeY1TSAVFmN+Or72k=;
 b=LPdSqxLxrmXSAt2bQzJUqFuTApXMfan1jDOgwMfzI5k31bnFmO+5E5NKlsMW012AAi2yKDdoSUjNgKEB9om08W28e1yTPp614t5hbOmgX03CeIlEmisjjpu99EOaC6GmK9djzzL1JHQDttl2khEBTgo3d1fDA056pG5eByJcHHA=
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: Ayan Kumar Halder , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , Luca Fancellu 
Subject: [PATCH v5 1/3] arm/mpu: Move the functions to arm64 specific files
Date: Thu, 19 Jun 2025 12:31:50 +0100
Message-ID: <20250619113152.2723066-2-ayan.kumar.halder@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20250619113152.2723066-1-ayan.kumar.halder@amd.com>
References: <20250619113152.2723066-1-ayan.kumar.halder@amd.com>
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: SJ5PEPF000001F6:EE_|CH3PR12MB8260:EE_
X-MS-Office365-Filtering-Correlation-Id: f23a6ed7-7bb7-4356-b3ef-08ddaf24ed9f
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?5+IcqpWyURX2Tcye4Nos3A0IIQthw4saCVoPGQhJLYZHDixabITIGisE+nUD?=
 =?us-ascii?Q?JudPtK9kCn27LWhf5qd6UrA4WYmvhqFxDaxzKQQ4TPRX6kNlxMVaTuP9od/P?=
 =?us-ascii?Q?uOUUONHxXbJP4Ux+CiqAiibvoFlm4tXxbLKGo40mZD/tuZcvXf5F9F29RQsA?=
 =?us-ascii?Q?UHavO4gRBdSwjRIw/Ca5kt5Ax9b+ShmLMxMi252LYsmqXQuBEuHE7ycWklUP?=
 =?us-ascii?Q?oSMG1zU63y+xWgO/8vdESz9rPqHVg3Qb2PIkAiZz5oID05P2H1puDOrSaLud?=
 =?us-ascii?Q?YljPkKyGL/L3bZAgLzmxJJsvHm13SYrQY87NxQwo1vGuA+3W2xvcW46EFcXD?=
 =?us-ascii?Q?vUIl3wkVqNCBudnOv4TnzJaRxev161SEE03F1QjT9U764jk9HsqrvtJElNAM?=
 =?us-ascii?Q?SqfmFvzGAiGH3VxVz0uOuJ+EMCUsAykRMPAUE4bdZ1cQQ2X3f4ZYdAVv5eaX?=
 =?us-ascii?Q?O5Ys7DFz+kIbUXQ/KzW6vRrKi6ouWD9JD2infO/s9ZvJKpnKtV3YvIbyO7/W?=
 =?us-ascii?Q?B0jmcxFnhRKPyvfE0Qi/fAcZk+G0PLk3LkAnO8HBpYNeng6TqRox7SlHLVcW?=
 =?us-ascii?Q?fG8fYlwLlN9NkoHqta+MG7l+2+W77nizwQRNH/WATivgdyJhEpHrOxuHVrsj?=
 =?us-ascii?Q?9dDFHn9JEeVmsAq1coGwB8mubhmSgo2j3BYKYrQtAvefbGwxg3MM8G6Vq8PI?=
 =?us-ascii?Q?BK1k1OPLEq7rkK5LZ94gsWHo69AYLRwrD+0442NQ3vIP4AV3uxtDZsvIWJxO?=
 =?us-ascii?Q?ZwtWU1G7zzZ7Fl+V2MHUWMTJb86cYWWmptrQrfmjSMLUF172aS35qjMjKHqT?=
 =?us-ascii?Q?MCZK/Exa7ldbXoxOamzATdxKQqldvUdsTR/i62qHVt7UF+p2D7A0dd4/RXEf?=
 =?us-ascii?Q?yw2+Wsgm2cj7x/9ULegaUuReQb9WAcCsRXRwBNEENRGoGVROek7Mxjf1ePwM?=
 =?us-ascii?Q?MyGUMOoksO1+2MuE869vED2Ial1sB568jPNOPFY6+OOUBtVZgix7luTIPoJE?=
 =?us-ascii?Q?9R8RHg7aJu41m5RfeI+aHWyMmqte2fduo18gRK/eOos/+6hyLYHhJQ31+l2k?=
 =?us-ascii?Q?IDFYb2kHwDDKE9t9RDNzwtO4S/BYm3UDTj/v36bna8r40Z5bCeYadcfRpI9Y?=
 =?us-ascii?Q?fogPssCX5BwT3mEyPI4HwcfEQFCJmo+C0qAahchio3NPFzGzGhJuBPDQk4JO?=
 =?us-ascii?Q?WoF/LFuM1ORLcvdc/zS8Qvr0TPEsyI/p3OBdm888OHImuc8/PvYCDn1jt3rC?=
 =?us-ascii?Q?6IgMRF5xCuTJaOG8i0J8ytnlhWXfEoNxMFHwPFPAfqDfx/tabCJP+7PQ4Osm?=
 =?us-ascii?Q?c0r/lW4U0EUYx3FTkts/tbC8Ma/NoymlqHeWzTf4F5mv+N3Fal3MFXpedrqX?=
 =?us-ascii?Q?O4EwBFvXjj70fhF+jXHygQds1q+0PU7+4bkbkcQvLwTrRf0Q5zMgykdLT/Xs?=
 =?us-ascii?Q?j1llGywOzKWTZVpwtN9rGrOpDVNBLarCCNRPfWGt1mjeEw1c4MOY5TZpGFqA?=
 =?us-ascii?Q?APF47JyBIBofwoaMN0kKXXdi+gtSzxxu3glQ?=
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: 19 Jun 2025 11:32:09.5475
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f23a6ed7-7bb7-4356-b3ef-08ddaf24ed9f
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:
	SJ5PEPF000001F6.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8260

prepare_selector(), read_protection_region() and write_protection_region()
differ significantly between arm32 and arm64. Thus, move these functions
to their sub-arch specific folder.

Also the macro GENERATE_{WRITE/READ}_PR_REG_CASE are moved, in order to
keep them in the same file of their usage and improve readability.

Signed-off-by: Ayan Kumar Halder 
Reviewed-by: Luca Fancellu 
Acked-by: Michal Orzel 
---
Changes from -

v2 - New patch introduced in v3.

v3 - 1. Add Luca's R-b.

v4 - 1. Reorder entries in mpu/Makefile alphabetically.
2. Add Michal's A-b.

 xen/arch/arm/mpu/Makefile       |   1 +
 xen/arch/arm/mpu/arm64/Makefile |   1 +
 xen/arch/arm/mpu/arm64/mm.c     | 130 ++++++++++++++++++++++++++++++++
 xen/arch/arm/mpu/mm.c           | 117 ----------------------------
 4 files changed, 132 insertions(+), 117 deletions(-)
 create mode 100644 xen/arch/arm/mpu/arm64/Makefile
 create mode 100644 xen/arch/arm/mpu/arm64/mm.c

diff --git a/xen/arch/arm/mpu/Makefile b/xen/arch/arm/mpu/Makefile
index 808e3e2cb3..09326a5248 100644
--- a/xen/arch/arm/mpu/Makefile
+++ b/xen/arch/arm/mpu/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_ARM_64) += arm64/
 obj-$(CONFIG_ARM_32) += domain-page.o
 obj-y += mm.o
 obj-y += p2m.o
diff --git a/xen/arch/arm/mpu/arm64/Makefile b/xen/arch/arm/mpu/arm64/Makefile
new file mode 100644
index 0000000000..b18cec4836
--- /dev/null
+++ b/xen/arch/arm/mpu/arm64/Makefile
@@ -0,0 +1 @@
+obj-y += mm.o
diff --git a/xen/arch/arm/mpu/arm64/mm.c b/xen/arch/arm/mpu/arm64/mm.c
new file mode 100644
index 0000000000..ed643cad40
--- /dev/null
+++ b/xen/arch/arm/mpu/arm64/mm.c
@@ -0,0 +1,130 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * The following are needed for the cases: GENERATE_WRITE_PR_REG_CASE
+ * and GENERATE_READ_PR_REG_CASE with num==0
+ */
+#define PRBAR0_EL2 PRBAR_EL2
+#define PRLAR0_EL2 PRLAR_EL2
+
+#define PRBAR_EL2_(n)   PRBAR##n##_EL2
+#define PRLAR_EL2_(n)   PRLAR##n##_EL2
+
+#define GENERATE_WRITE_PR_REG_CASE(num, pr)                                 \
+    case num:                                                               \
+    {                                                                       \
+        WRITE_SYSREG(pr->prbar.bits & ~MPU_REGION_RES0, PRBAR_EL2_(num));   \
+        WRITE_SYSREG(pr->prlar.bits & ~MPU_REGION_RES0, PRLAR_EL2_(num));   \
+        break;                                                              \
+    }
+
+#define GENERATE_READ_PR_REG_CASE(num, pr)                      \
+    case num:                                                   \
+    {                                                           \
+        pr->prbar.bits = READ_SYSREG(PRBAR_EL2_(num));          \
+        pr->prlar.bits = READ_SYSREG(PRLAR_EL2_(num));          \
+        break;                                                  \
+    }
+
+/*
+ * Armv8-R supports direct access and indirect access to the MPU regions through
+ * registers:
+ *  - indirect access involves changing the MPU region selector, issuing an isb
+ *    barrier and accessing the selected region through specific registers
+ *  - direct access involves accessing specific registers that point to
+ *    specific MPU regions, without changing the selector, avoiding the use of
+ *    a barrier.
+ * For Arm64 the PR{B,L}AR_ELx (for n=0) and PR{B,L}AR_ELx (for n=1..15) are
+ * used for the direct access to the regions selected by
+ * PRSELR_EL2.REGION<7:4>:n, so 16 regions can be directly accessed when the
+ * selector is a multiple of 16, giving access to all the supported memory
+ * regions.
+ */
+static void prepare_selector(uint8_t *sel)
+{
+    uint8_t cur_sel = *sel;
+
+    /*
+     * {read,write}_protection_region works using the direct access to the 0..15
+     * regions, so in order to save the isb() overhead, change the PRSELR_EL2
+     * only when needed, so when the upper 4 bits of the selector will change.
+     */
+    cur_sel &= 0xF0U;
+    if ( READ_SYSREG(PRSELR_EL2) != cur_sel )
+    {
+        WRITE_SYSREG(cur_sel, PRSELR_EL2);
+        isb();
+    }
+    *sel &= 0xFU;
+}
+
+void read_protection_region(pr_t *pr_read, uint8_t sel)
+{
+    prepare_selector(&sel);
+
+    switch ( sel )
+    {
+        GENERATE_READ_PR_REG_CASE(0, pr_read);
+        GENERATE_READ_PR_REG_CASE(1, pr_read);
+        GENERATE_READ_PR_REG_CASE(2, pr_read);
+        GENERATE_READ_PR_REG_CASE(3, pr_read);
+        GENERATE_READ_PR_REG_CASE(4, pr_read);
+        GENERATE_READ_PR_REG_CASE(5, pr_read);
+        GENERATE_READ_PR_REG_CASE(6, pr_read);
+        GENERATE_READ_PR_REG_CASE(7, pr_read);
+        GENERATE_READ_PR_REG_CASE(8, pr_read);
+        GENERATE_READ_PR_REG_CASE(9, pr_read);
+        GENERATE_READ_PR_REG_CASE(10, pr_read);
+        GENERATE_READ_PR_REG_CASE(11, pr_read);
+        GENERATE_READ_PR_REG_CASE(12, pr_read);
+        GENERATE_READ_PR_REG_CASE(13, pr_read);
+        GENERATE_READ_PR_REG_CASE(14, pr_read);
+        GENERATE_READ_PR_REG_CASE(15, pr_read);
+    default:
+        BUG(); /* Can't happen */
+        break;
+    }
+}
+
+void write_protection_region(const pr_t *pr_write, uint8_t sel)
+{
+    prepare_selector(&sel);
+
+    switch ( sel )
+    {
+        GENERATE_WRITE_PR_REG_CASE(0, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(1, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(2, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(3, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(4, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(5, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(6, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(7, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(8, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(9, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(10, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(11, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(12, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(13, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(14, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(15, pr_write);
+    default:
+        BUG(); /* Can't happen */
+        break;
+    }
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
index 3d37beab57..7ab68fc8c7 100644
--- a/xen/arch/arm/mpu/mm.c
+++ b/xen/arch/arm/mpu/mm.c
@@ -29,35 +29,6 @@ DECLARE_BITMAP(xen_mpumap_mask, MAX_MPU_REGION_NR) \
 /* EL2 Xen MPU memory region mapping table. */
 pr_t __cacheline_aligned __section(".data") xen_mpumap[MAX_MPU_REGION_NR];
 
-#ifdef CONFIG_ARM_64
-/*
- * The following are needed for the cases: GENERATE_WRITE_PR_REG_CASE
- * and GENERATE_READ_PR_REG_CASE with num==0
- */
-#define PRBAR0_EL2 PRBAR_EL2
-#define PRLAR0_EL2 PRLAR_EL2
-
-#define PRBAR_EL2_(n)   PRBAR##n##_EL2
-#define PRLAR_EL2_(n)   PRLAR##n##_EL2
-
-#endif /* CONFIG_ARM_64 */
-
-#define GENERATE_WRITE_PR_REG_CASE(num, pr)                                 \
-    case num:                                                               \
-    {                                                                       \
-        WRITE_SYSREG(pr->prbar.bits & ~MPU_REGION_RES0, PRBAR_EL2_(num));   \
-        WRITE_SYSREG(pr->prlar.bits & ~MPU_REGION_RES0, PRLAR_EL2_(num));   \
-        break;                                                              \
-    }
-
-#define GENERATE_READ_PR_REG_CASE(num, pr)                      \
-    case num:                                                   \
-    {                                                           \
-        pr->prbar.bits = READ_SYSREG(PRBAR_EL2_(num));          \
-        pr->prlar.bits = READ_SYSREG(PRLAR_EL2_(num));          \
-        break;                                                  \
-    }
-
 static void __init __maybe_unused build_assertions(void)
 {
     /*
@@ -69,94 +40,6 @@ static void __init __maybe_unused build_assertions(void)
 }
 
 #ifdef CONFIG_ARM_64
-/*
- * Armv8-R supports direct access and indirect access to the MPU regions through
- * registers:
- *  - indirect access involves changing the MPU region selector, issuing an isb
- *    barrier and accessing the selected region through specific registers
- *  - direct access involves accessing specific registers that point to
- *    specific MPU regions, without changing the selector, avoiding the use of
- *    a barrier.
- * For Arm64 the PR{B,L}AR_ELx (for n=0) and PR{B,L}AR_ELx (for n=1..15) are
- * used for the direct access to the regions selected by
- * PRSELR_EL2.REGION<7:4>:n, so 16 regions can be directly accessed when the
- * selector is a multiple of 16, giving access to all the supported memory
- * regions.
- */
-static void prepare_selector(uint8_t *sel)
-{
-    uint8_t cur_sel = *sel;
-
-    /*
-     * {read,write}_protection_region works using the direct access to the 0..15
-     * regions, so in order to save the isb() overhead, change the PRSELR_EL2
-     * only when needed, so when the upper 4 bits of the selector will change.
-     */
-    cur_sel &= 0xF0U;
-    if ( READ_SYSREG(PRSELR_EL2) != cur_sel )
-    {
-        WRITE_SYSREG(cur_sel, PRSELR_EL2);
-        isb();
-    }
-    *sel &= 0xFU;
-}
-
-void read_protection_region(pr_t *pr_read, uint8_t sel)
-{
-    prepare_selector(&sel);
-
-    switch ( sel )
-    {
-        GENERATE_READ_PR_REG_CASE(0, pr_read);
-        GENERATE_READ_PR_REG_CASE(1, pr_read);
-        GENERATE_READ_PR_REG_CASE(2, pr_read);
-        GENERATE_READ_PR_REG_CASE(3, pr_read);
-        GENERATE_READ_PR_REG_CASE(4, pr_read);
-        GENERATE_READ_PR_REG_CASE(5, pr_read);
-        GENERATE_READ_PR_REG_CASE(6, pr_read);
-        GENERATE_READ_PR_REG_CASE(7, pr_read);
-        GENERATE_READ_PR_REG_CASE(8, pr_read);
-        GENERATE_READ_PR_REG_CASE(9, pr_read);
-        GENERATE_READ_PR_REG_CASE(10, pr_read);
-        GENERATE_READ_PR_REG_CASE(11, pr_read);
-        GENERATE_READ_PR_REG_CASE(12, pr_read);
-        GENERATE_READ_PR_REG_CASE(13, pr_read);
-        GENERATE_READ_PR_REG_CASE(14, pr_read);
-        GENERATE_READ_PR_REG_CASE(15, pr_read);
-    default:
-        BUG(); /* Can't happen */
-        break;
-    }
-}
-
-void write_protection_region(const pr_t *pr_write, uint8_t sel)
-{
-    prepare_selector(&sel);
-
-    switch ( sel )
-    {
-        GENERATE_WRITE_PR_REG_CASE(0, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(1, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(2, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(3, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(4, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(5, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(6, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(7, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(8, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(9, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(10, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(11, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(12, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(13, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(14, pr_write);
-        GENERATE_WRITE_PR_REG_CASE(15, pr_write);
-    default:
-        BUG(); /* Can't happen */
-        break;
-    }
-}
-
 pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags)
 {
     unsigned int attr_idx = PAGE_AI_MASK(flags);
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Thu Jun 19 11:32:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 11:32:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019938.1396373 (Exim 4.92)
	(envelope-from )
	id 1uSDVU-0000Qn-MG; Thu, 19 Jun 2025 11:32:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019938.1396373; Thu, 19 Jun 2025 11:32:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSDVU-0000Qg-IH; Thu, 19 Jun 2025 11:32:36 +0000
Received: by outflank-mailman (input) for mailman id 1019938;
 Thu, 19 Jun 2025 11:32:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uSDVT-0008L0-Er
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 11:32:35 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20605.outbound.protection.outlook.com
 [2a01:111:f403:2412::605])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 16e9a66b-4d01-11f0-b894-0df219b8e170;
 Thu, 19 Jun 2025 13:32:33 +0200 (CEST)
Received: from SJ0PR05CA0092.namprd05.prod.outlook.com (2603:10b6:a03:334::7)
 by LV2PR12MB5774.namprd12.prod.outlook.com (2603:10b6:408:17a::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.25; Thu, 19 Jun
 2025 11:32:24 +0000
Received: from SJ5PEPF000001F2.namprd05.prod.outlook.com
 (2603:10b6:a03:334:cafe::cc) by SJ0PR05CA0092.outlook.office365.com
 (2603:10b6:a03:334::7) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8880.12 via Frontend Transport; Thu,
 19 Jun 2025 11:32:24 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SJ5PEPF000001F2.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.8857.21 via Frontend Transport; Thu, 19 Jun 2025 11:32:23 +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 Jun
 2025 06:32:22 -0500
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 Jun 2025 06:32:21 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 16e9a66b-4d01-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=uHElf0clA2NTnbFKlbZPrXoh949TSIzFTVKk6Lh2teFotA4oIpweyJDbSfQeXh5n+A+IIcDjdYBH9X/fRh9Hu45c8qkBp4RV8R8n2E2lrrIzlsmycAfQ4fsnpHEGl5F99AzJV9d9xBUaOZ+qjdQy2plXkavIfY6EI0Sps//fJa9LRo17+RfXC5wHJM9Bb7dDhcJLX+Xhx1utoaN5NlTqEPAzaGfPz+dJEy2kKGawsplCcwUW7+ElQ0DxQDU6Bn3SFdLD9gVYSn8sFBzPshZHHLm/ckGWCyway0dl7JzDles3bk5IuU/9gjGOEuAJiQrwgSKGalDodz9HqVER1yNoFw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=E9GnvlPa7/ykuvq75UkRq8ccJA05rYoUW1y1TKX2t0s=;
 b=NxWsFz0OVCr5DLG+t70RVR2jQrWnz/MrV2Z24B3VgvMx8hqoCQ09DbD1njs3ognDCpgglmLWK7gRws2MjVWx9Ci4KrDrQ8WNYXb9df0Lc4y/GoavjglSBewXf+MoFuPWy2pr9znQhoHrIvtwITZNNOrFH/qqOgo3SVj9c0TJo0aPhLUAImRnmNlNuRzRWYTSvuvccmNRYU+DoXsL4nRQcdiZG2hkiRFu5FP6A33e2ehrBpI5k9Q2YG6OrAW8CAlwIVg0noZ/MEZGR+023IRRprzGjvLtsG3lnzpNZL5EIsOG0RYCgg/ZifCfxvYba+n88nTBu5Ef7qRkZXxG0egSmQ==
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=E9GnvlPa7/ykuvq75UkRq8ccJA05rYoUW1y1TKX2t0s=;
 b=Bh+fQWaSyNLZu8kjGuwc9wLucH7oOF5XgdKVJDbmiZ7vWhU6KXEogeHoycdceYnBLxUTUlPsHsLj+ydmnIIPStWAgyIvte7TfqB4egWdld53/x6e19aGr4stbM7lc+aPDK+Jp4PsDmOUMUlUs+UMEpgwlc3ohBbAKVRSY1PHoPc=
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: Ayan Kumar Halder , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , Hari Limaye 
Subject: [PATCH v5 2/3] arm/mpu: Define arm32 system registers
Date: Thu, 19 Jun 2025 12:31:51 +0100
Message-ID: <20250619113152.2723066-3-ayan.kumar.halder@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20250619113152.2723066-1-ayan.kumar.halder@amd.com>
References: <20250619113152.2723066-1-ayan.kumar.halder@amd.com>
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: SJ5PEPF000001F2:EE_|LV2PR12MB5774:EE_
X-MS-Office365-Filtering-Correlation-Id: f9a9b498-acf0-499d-9b47-08ddaf24f608
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?/qjRLZ8hzn1xHYeJlydLiPQYhbymBOFU1HqIu+ae950g8VUKpHHhS40PvCHr?=
 =?us-ascii?Q?jGHJeIn3F3+mOnczA/Ddp7zCc4H09C1UfUpunPTNq9N66lsNpuks6fFBAl22?=
 =?us-ascii?Q?AHH82q2vomlxjLg1V4kPAdpScm0/Fiq9kH4tXkw3cBRzfoMelgpG4NcDDEvV?=
 =?us-ascii?Q?7tSwHqrla7KkvxCt7wUyG2CtEDL76sQQ+PWgYnhtX5RnIo02u7lC16J41SfZ?=
 =?us-ascii?Q?uckMh/F608p1tNKktyvTCTBhItPXlPlwwR5xHuZr+dirXslONmbHfGE2hJ4F?=
 =?us-ascii?Q?YsfNJfGDZ8ifcyEm/sq2sWiOFh0x6UXtlzplHhfBU8R5XrS+dk2xu6yWBVNt?=
 =?us-ascii?Q?aeddksd7/q37pjSEvh6Q2pBy49dfgleHf8lF8xhUz9ul8DCfKL7ptphTmyTy?=
 =?us-ascii?Q?IrhUcRPSzFUxIircCkXDO1Jr+5YLE6bcEMjOKelLXgQ8XdWhlmTgWHfreAtB?=
 =?us-ascii?Q?8999F9f01hSdgvJlDpGLcSrFish9S7mNGYrSTR7GxsrTkj5Rw1oUxd77zZhP?=
 =?us-ascii?Q?DV//GldpuARzvzZiOOSRL/QjhNpJDFqwsfi7tmj99qj/LDMiYN+zU5VfE+k+?=
 =?us-ascii?Q?3e9HEh6EB7lzP+3gE33gwQ/6i6WbPrN9b7EV8WEhawiJZCE1zUdN8ZagLfox?=
 =?us-ascii?Q?Yur7r9U73qWtEqoouoZDRS4snPZl5G/aaIefK7/gpGCH06dtS02Vawkh3M3K?=
 =?us-ascii?Q?us1U24cLNLJncMCbwq6zCKsI4UW/h8Es1uSCuGq6OFwAOKL4lDeiXtnw1rr7?=
 =?us-ascii?Q?Ni7jl/J0wJ61hTqKq3yRGI/yaVNhMVHG07Jp+lEWfEXW5J1pg7jPK2IN2gmQ?=
 =?us-ascii?Q?oFCRtHbJuEwALvRNdslfusGpqeoXzLweSf7MraWNZlMHeZ9bFaiEKDoY4p1j?=
 =?us-ascii?Q?j0prQxMqRaPGV3Iobq6zCj87hY5yvotMkxeAjdDzwMM081AUtXFo58hdoG2b?=
 =?us-ascii?Q?IxSWJrRa8KsbbkycNBzOlQYFrQu1evuFACDG55/MzjsNO3DKFs+dbZSTSsB0?=
 =?us-ascii?Q?ddfKoH/uYXl21QnqKiA0ifdh7VROrSh826djGu3ZgjCZJmdJmBq792o32+rz?=
 =?us-ascii?Q?QRGRUrKvqr4hyz/ht1WJOhqENX94vxhu56HThKkZfMjutgC2cvtW54L+aqny?=
 =?us-ascii?Q?dxcsgBZxiNmXehFoI5B1yWG4nVKaAMP+mz8F3QfonYQ0xf7AVbPAepSLJ9FB?=
 =?us-ascii?Q?aEArMrjX15Eot8nxmN8z0oTEVI1IHjzOhScsrGtF7MTWTvXrC6puXGYib+78?=
 =?us-ascii?Q?L6IVf+8dRXhzhw35JcuEAM/91J1AVw7CQ8XxgZEe1bnVBJN+UNFNTwu6Y+Me?=
 =?us-ascii?Q?ARatk0CSfrZMfKsrpPw0VHkxCx50wl5g3Bn81HIhZeU/wTz98eYHFqTXO/vR?=
 =?us-ascii?Q?6i+ledz2DW/ZVLAGj32mgSv5Ki59hK7KWRzgf5DmhWdTuOjikp4j8myfRrBK?=
 =?us-ascii?Q?qwdvSjpA9RR2SubteqJXA72S+6YDZDxjBAJL3fG2XNF9AHspglqO2hkYfl8B?=
 =?us-ascii?Q?gy1dEtkl/sHgOLHj6gIYLgKC+I+gsJMQm7na?=
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: 19 Jun 2025 11:32:23.6569
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f9a9b498-acf0-499d-9b47-08ddaf24f608
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:
	SJ5PEPF000001F2.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV2PR12MB5774

Fix the definition for HPRLAR.
Define the base/limit address registers to access the first 32 protection
regions.

Signed-off-by: Ayan Kumar Halder 
Reviewed-by: Hari Limaye 
Acked-by: Michal Orzel 
---
Changes from :-

v2 - New patch introduced in v3 (Extracted from 
"arm/mpu: Provide access to the MPU region from the C code").

v3 - Add Hari's R-b.

v4 - Add Michal's A-b.

 xen/arch/arm/include/asm/mpu/cpregs.h | 68 ++++++++++++++++++++++++++-
 1 file changed, 67 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/include/asm/mpu/cpregs.h b/xen/arch/arm/include/asm/mpu/cpregs.h
index d5cd0e04d5..bb15e02df6 100644
--- a/xen/arch/arm/include/asm/mpu/cpregs.h
+++ b/xen/arch/arm/include/asm/mpu/cpregs.h
@@ -9,7 +9,73 @@
 /* CP15 CR6: MPU Protection Region Base/Limit/Select Address Register */
 #define HPRSELR         p15,4,c6,c2,1
 #define HPRBAR          p15,4,c6,c3,0
-#define HPRLAR          p15,4,c6,c8,1
+#define HPRLAR          p15,4,c6,c3,1
+
+/* CP15 CR6: MPU Protection Region Base/Limit Address Register */
+#define HPRBAR0         p15,4,c6,c8,0
+#define HPRLAR0         p15,4,c6,c8,1
+#define HPRBAR1         p15,4,c6,c8,4
+#define HPRLAR1         p15,4,c6,c8,5
+#define HPRBAR2         p15,4,c6,c9,0
+#define HPRLAR2         p15,4,c6,c9,1
+#define HPRBAR3         p15,4,c6,c9,4
+#define HPRLAR3         p15,4,c6,c9,5
+#define HPRBAR4         p15,4,c6,c10,0
+#define HPRLAR4         p15,4,c6,c10,1
+#define HPRBAR5         p15,4,c6,c10,4
+#define HPRLAR5         p15,4,c6,c10,5
+#define HPRBAR6         p15,4,c6,c11,0
+#define HPRLAR6         p15,4,c6,c11,1
+#define HPRBAR7         p15,4,c6,c11,4
+#define HPRLAR7         p15,4,c6,c11,5
+#define HPRBAR8         p15,4,c6,c12,0
+#define HPRLAR8         p15,4,c6,c12,1
+#define HPRBAR9         p15,4,c6,c12,4
+#define HPRLAR9         p15,4,c6,c12,5
+#define HPRBAR10        p15,4,c6,c13,0
+#define HPRLAR10        p15,4,c6,c13,1
+#define HPRBAR11        p15,4,c6,c13,4
+#define HPRLAR11        p15,4,c6,c13,5
+#define HPRBAR12        p15,4,c6,c14,0
+#define HPRLAR12        p15,4,c6,c14,1
+#define HPRBAR13        p15,4,c6,c14,4
+#define HPRLAR13        p15,4,c6,c14,5
+#define HPRBAR14        p15,4,c6,c15,0
+#define HPRLAR14        p15,4,c6,c15,1
+#define HPRBAR15        p15,4,c6,c15,4
+#define HPRLAR15        p15,4,c6,c15,5
+#define HPRBAR16        p15,5,c6,c8,0
+#define HPRLAR16        p15,5,c6,c8,1
+#define HPRBAR17        p15,5,c6,c8,4
+#define HPRLAR17        p15,5,c6,c8,5
+#define HPRBAR18        p15,5,c6,c9,0
+#define HPRLAR18        p15,5,c6,c9,1
+#define HPRBAR19        p15,5,c6,c9,4
+#define HPRLAR19        p15,5,c6,c9,5
+#define HPRBAR20        p15,5,c6,c10,0
+#define HPRLAR20        p15,5,c6,c10,1
+#define HPRBAR21        p15,5,c6,c10,4
+#define HPRLAR21        p15,5,c6,c10,5
+#define HPRBAR22        p15,5,c6,c11,0
+#define HPRLAR22        p15,5,c6,c11,1
+#define HPRBAR23        p15,5,c6,c11,4
+#define HPRLAR23        p15,5,c6,c11,5
+#define HPRBAR24        p15,5,c6,c12,0
+#define HPRLAR24        p15,5,c6,c12,1
+#define HPRBAR25        p15,5,c6,c12,4
+#define HPRLAR25        p15,5,c6,c12,5
+#define HPRBAR26        p15,5,c6,c13,0
+#define HPRLAR26        p15,5,c6,c13,1
+#define HPRBAR27        p15,5,c6,c13,4
+#define HPRLAR27        p15,5,c6,c13,5
+#define HPRBAR28        p15,5,c6,c14,0
+#define HPRLAR28        p15,5,c6,c14,1
+#define HPRBAR29        p15,5,c6,c14,4
+#define HPRLAR29        p15,5,c6,c14,5
+#define HPRBAR30        p15,5,c6,c15,0
+#define HPRLAR30        p15,5,c6,c15,1
+#define HPRBAR31        p15,5,c6,c15,4
+#define HPRLAR31        p15,5,c6,c15,5
 
 /* Aliases of AArch64 names for use in common code */
 #ifdef CONFIG_ARM_32
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Thu Jun 19 11:32:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 11:32:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019941.1396383 (Exim 4.92)
	(envelope-from )
	id 1uSDVY-0000jw-0B; Thu, 19 Jun 2025 11:32:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019941.1396383; Thu, 19 Jun 2025 11:32:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSDVX-0000jn-TL; Thu, 19 Jun 2025 11:32:39 +0000
Received: by outflank-mailman (input) for mailman id 1019941;
 Thu, 19 Jun 2025 11:32: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 1uSDVV-0008L0-ST
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 11:32:37 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20625.outbound.protection.outlook.com
 [2a01:111:f403:2414::625])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1881a05d-4d01-11f0-b894-0df219b8e170;
 Thu, 19 Jun 2025 13:32:36 +0200 (CEST)
Received: from BY3PR04CA0016.namprd04.prod.outlook.com (2603:10b6:a03:217::21)
 by PH8PR12MB6796.namprd12.prod.outlook.com (2603:10b6:510:1c7::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.30; Thu, 19 Jun
 2025 11:32:32 +0000
Received: from SJ5PEPF000001F1.namprd05.prod.outlook.com
 (2603:10b6:a03:217:cafe::7f) by BY3PR04CA0016.outlook.office365.com
 (2603:10b6:a03:217::21) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.31 via Frontend Transport; Thu,
 19 Jun 2025 11:32:32 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SJ5PEPF000001F1.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.8857.21 via Frontend Transport; Thu, 19 Jun 2025 11:32:32 +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 Jun
 2025 06:32:31 -0500
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 Jun 2025 06:32:30 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1881a05d-4d01-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=jdiuAyRW8siHbS28wu2yX4ZceP5Z/L4EMBbPC9WRe5J3dIGr9p57NfZ3bR8sutwJgbAQpd99+wOp5im3d4KnXsNg1xONohmR3zTBwGPDbHdRBlfxnA4gFdgzI1QO6z1+3cCBs9fFhV0Ib/cyu2GbNH0Wgyt2asGANcZ4zJfzqFmTtiaDmbhhemxagyO9chg7TSyTSBKzgmegDLWsMiXF2ltQnzi8Gv4TO7AyElNg2ldGYq+kMjuGbPAXkY3sIp1ns3Ti2vmSDJ0wSSXL5VYeWTpp4THjcbtTnYYFkOWBkw7iYfknOElWsmJ+UT2WeNaCM5GvCD1OlXo0234i9CoHUw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=FN6M6a/5MsbA0wVu/9z6XdbvAHDkqorSxg5xNPa8Obs=;
 b=RwTINB3n5IEdXCwQNVp19tg335HY6gNHusgP+9a/z5t931d2YiavPNhkVwUP6NI63MaPssSTOUz3o3drpCFvJ86tBrd7ar8RPJoRK7rLHDKKvCQOt5MQpo/czjVpQrakc+7618ea8/ZfLu/2hSYPvFCGR9Y+JLjVKeoahULfny10CI6dh8Ma4dZ5+1u4cWqBuNmbqfTZDC/0QucwwvGANkvyQ++9e9SD5kqJVD/JqqgqwHaT383PrbWs/DyMRfVRrM/LSApZsvdqcOIysQnyG3Uafi6+KrBqA1mbAaP/jGj1KngB+fI2443pSzpy4yGVLtBVnfFV5uCQP06oOqNI8w==
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=FN6M6a/5MsbA0wVu/9z6XdbvAHDkqorSxg5xNPa8Obs=;
 b=mwAiaABK7DtUGfoLJclHmezQfBsbVLeKx8+RS6zuw4O2yLdomY7zPNekYWKk7+8yP7yWBWOMtlbfwh2CpDXVru6j6sTvZOCWjZySE/DE343RTlLwAXqoMrDYF9Xom2z1AEIj5ye7G9wt5SCPZ3SSepXwA1k7DbYo1x+S6GPjnJI=
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: Ayan Kumar Halder , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , Luca Fancellu ,
	Hari Limaye , Julien Grall 
Subject: [PATCH v5 3/3] arm/mpu: Enable read/write to protection regions for arm32
Date: Thu, 19 Jun 2025 12:31:52 +0100
Message-ID: <20250619113152.2723066-4-ayan.kumar.halder@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20250619113152.2723066-1-ayan.kumar.halder@amd.com>
References: <20250619113152.2723066-1-ayan.kumar.halder@amd.com>
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: SJ5PEPF000001F1:EE_|PH8PR12MB6796:EE_
X-MS-Office365-Filtering-Correlation-Id: 77f2614b-c1a3-435c-cd2c-08ddaf24fb21
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:
	=?us-ascii?Q?YM9Ns7sRCPFogJ11wQ/GFOKVX4iwR4PJ/RISuQaQulKSl3dFpQ0Rpnq4EVH5?=
 =?us-ascii?Q?7vWCFDk7cNpY2rpjFNceBKV1Q6oX0qXTEKgaZPnuEitXDmN8iTx5FzKcIirl?=
 =?us-ascii?Q?P9MbH4p0ob+HF2IozDPL7PdBZvBm+BiXPnBcx9blLJEEflQvpsFi1/c38GWc?=
 =?us-ascii?Q?+s/ynMc+HEs2xdPpedwPxe9EcmxQaPjzjvilewGZguyOvakUaNdsCtiz06IR?=
 =?us-ascii?Q?4qs5xJO33UVN24iIHvul3qQtSlxmMx/p5mgmv1Fpz56CPgW+3Orn2CiKAlDY?=
 =?us-ascii?Q?fWhb9uPzFrzSowQQWYDlWKnpEobOlDFtEYWbtjlZf1u+3/cWPl/Ha3k5U+6f?=
 =?us-ascii?Q?+FeivTREOllvycqRjGcrWC+V8fkuEoEKmJQPX5WFpYZTrG4Gzlukx/MGm3+8?=
 =?us-ascii?Q?MWvHN4Os3OJojeOpf1g1B2iebPEHmqMDBenmOgkElPfj4cWyF5hSE1Ygt9X7?=
 =?us-ascii?Q?F8ZmDTwyuyufT9XGr0CB/qgTm4Z61PO0PVgVsCsBceBHCn7iZ//HUe/4AFlJ?=
 =?us-ascii?Q?Aa3yVxdXrwvqfGz/7cv1k9fk0UhJ9XkY6p6dAUvulW7g5pJPXORkrl9rWP4s?=
 =?us-ascii?Q?wOabUlAW8IjvppsQi+gwkZM462LGig6mY7xAkBFmfLMUEp6XZfrvgMHlmymb?=
 =?us-ascii?Q?53d6oycDT2neRAiN5KifRODFjnMmDoJxjOOCzmA/VHwo8KjtGyBdTFIsBf0N?=
 =?us-ascii?Q?qPcTCvkJXD30SWTUUs3C4E7yHB2BP6DurBT8nafKX/HKfDT+Llz09L+4Povb?=
 =?us-ascii?Q?aivaCIXuu4VOOpIk4YgsKjqN3sHboM2rJjJU4ZVVUOTAYvi9ltBq33/YX5E0?=
 =?us-ascii?Q?082CGbpKhdAapPR1Cbiz4aViLCP+w8og7aEtWCHw9j7qHTzlKQl2YBXD2KuU?=
 =?us-ascii?Q?AV2ZwOFKajtcJT0G+6BgcONIWFcwqOHFZ8bK5OfFmWNsnBJEE1+9+AZG/+z8?=
 =?us-ascii?Q?dJwNnyorNFQwOqkqOqBHHoqi4vLx+yZQDnzEqMiOWJj7BL/V2FpvFje178pj?=
 =?us-ascii?Q?J0IEQ5pP63XH8xfdN6XNdXpcM5Lb7tqx8BRJmRtmyc/8t9UIbR0tRPV1AD68?=
 =?us-ascii?Q?yqz+ezRVJ2Xo6twDjqmZIAYQsYV2kDNmTl/23dGz2jCZW10lMBKlIw4LA4yv?=
 =?us-ascii?Q?gRkm82OLVZFQ8lJaZ73XtV/kFYdsOTmyixtJ1u3Gu3nKv13pz8tk89Sb/eYS?=
 =?us-ascii?Q?PdW4V9hm8CoVNqU/yx6J0un0u0mxqr6kA0HZUOYCr0n6ztG5k3uIHm6S06b6?=
 =?us-ascii?Q?0SBih2fDU1Te7CbS2QjeXdU0VPAJQbX4swBHJ1mVMyB7Lmh0ue++Wm+FsUEo?=
 =?us-ascii?Q?ggYMxcdxlEcjujMe0FOy5snzD2fPruW4PGCamztD6zd02UHtJJpKA2VkrZMD?=
 =?us-ascii?Q?II+CtIyQqqiA0mFFOjpesPZnwynFZhTsgqLk9VgrjZiWwXcRFweIZ7fMdWLG?=
 =?us-ascii?Q?24CNOciA+JQ/unB+NAEMxuBvc69sgb5CbTFFuR1zAjapu4Wyk/wQazEeoXo4?=
 =?us-ascii?Q?l8JrmvRqiC4iTLv8l466Ptm0/Be5qaF6WN6N?=
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)(1800799024)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jun 2025 11:32:32.2103
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 77f2614b-c1a3-435c-cd2c-08ddaf24fb21
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:
	SJ5PEPF000001F1.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB6796

Define prepare_selector(), read_protection_region() and
write_protection_region() for arm32. Also, define
GENERATE_{READ/WRITE}_PR_REG_OTHERS to access MPU regions from 32 to 254.

Enable pr_{get/set}_{base/limit}(), region_is_valid() for arm32.
Enable pr_of_addr() for arm32.

The maximum number of regions supported is 255 (which corresponds to the
maximum value in HMPUIR).

Signed-off-by: Ayan Kumar Halder 
Reviewed-by: Luca Fancellu 
Reviewed-by: Hari Limaye 
Tested-by: Hari Limaye 
Acked-by: Julien Grall 
---
Changes from :-

v1 - 1. Enable write_protection_region() for aarch32.

v2 - 1. Enable access to protection regions from 0 - 255.

v3 - 1. The maximum number of regions is 255. Thus, regions numbered 0 - 254
are supported.

2. prepare_selector() is modified to ensure HPRSELR is written when accessing
any region beyond 31 and the current value differs from the region number to
be accessed.

v4 - 1. Add R-b, A-b and T-b.

 xen/arch/arm/include/asm/mpu.h  |   2 -
 xen/arch/arm/mpu/Makefile       |   1 +
 xen/arch/arm/mpu/arm32/Makefile |   1 +
 xen/arch/arm/mpu/arm32/mm.c     | 164 ++++++++++++++++++++++++++++++++
 xen/arch/arm/mpu/mm.c           |   2 -
 5 files changed, 166 insertions(+), 4 deletions(-)
 create mode 100644 xen/arch/arm/mpu/arm32/Makefile
 create mode 100644 xen/arch/arm/mpu/arm32/mm.c

diff --git a/xen/arch/arm/include/asm/mpu.h b/xen/arch/arm/include/asm/mpu.h
index 8f06ddac0f..63560c613b 100644
--- a/xen/arch/arm/include/asm/mpu.h
+++ b/xen/arch/arm/include/asm/mpu.h
@@ -25,7 +25,6 @@
 
 #ifndef __ASSEMBLY__
 
-#ifdef CONFIG_ARM_64
 /*
  * Set base address of MPU protection region.
  *
@@ -85,7 +84,6 @@ static inline bool region_is_valid(const pr_t *pr)
 {
     return pr->prlar.reg.en;
 }
-#endif /* CONFIG_ARM_64 */
 
 #endif /* __ASSEMBLY__ */
 
diff --git a/xen/arch/arm/mpu/Makefile b/xen/arch/arm/mpu/Makefile
index 09326a5248..50f8fe4326 100644
--- a/xen/arch/arm/mpu/Makefile
+++ b/xen/arch/arm/mpu/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_ARM_32) += arm32/
 obj-$(CONFIG_ARM_64) += arm64/
 obj-$(CONFIG_ARM_32) += domain-page.o
 obj-y += mm.o
diff --git a/xen/arch/arm/mpu/arm32/Makefile b/xen/arch/arm/mpu/arm32/Makefile
new file mode 100644
index 0000000000..b18cec4836
--- /dev/null
+++ b/xen/arch/arm/mpu/arm32/Makefile
@@ -0,0 +1 @@
+obj-y += mm.o
diff --git a/xen/arch/arm/mpu/arm32/mm.c b/xen/arch/arm/mpu/arm32/mm.c
new file mode 100644
index 0000000000..a4673c3511
--- /dev/null
+++ b/xen/arch/arm/mpu/arm32/mm.c
@@ -0,0 +1,164 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define GENERATE_WRITE_PR_REG_CASE(num, pr)               \
+    case num:                                             \
+    {                                                     \
+        WRITE_SYSREG(pr->prbar.bits, HPRBAR##num);        \
+        WRITE_SYSREG(pr->prlar.bits, HPRLAR##num);        \
+        break;                                            \
+    }
+
+#define GENERATE_WRITE_PR_REG_OTHERS(num, pr)             \
+    case num:                                             \
+    {                                                     \
+        WRITE_SYSREG(pr->prbar.bits, HPRBAR);             \
+        WRITE_SYSREG(pr->prlar.bits, HPRLAR);             \
+        break;                                            \
+    }
+
+#define GENERATE_READ_PR_REG_CASE(num, pr)                \
+    case num:                                             \
+    {                                                     \
+        pr->prbar.bits = READ_SYSREG(HPRBAR##num);        \
+        pr->prlar.bits = READ_SYSREG(HPRLAR##num);        \
+        break;                                            \
+    }
+
+#define GENERATE_READ_PR_REG_OTHERS(num, pr)              \
+    case num:                                             \
+    {                                                     \
+        pr->prbar.bits = READ_SYSREG(HPRBAR);             \
+        pr->prlar.bits = READ_SYSREG(HPRLAR);             \
+        break;                                            \
+    }
+
+/*
+ * Armv8-R supports direct access and indirect access to the MPU regions through
+ * registers:
+ *  - indirect access involves changing the MPU region selector, issuing an isb
+ *    barrier and accessing the selected region through specific registers
+ *  - direct access involves accessing specific registers that point to
+ *    specific MPU regions, without changing the selector, avoiding the use of
+ *    a barrier.
+ * For Arm32 the HPR{B,L}AR (for n=0..31) are used for direct access to the
+ * first 32 MPU regions.
+ * For MPU regions numbered 32..254, one needs to set the region number in
+ * HPRSELR, followed by configuring HPR{B,L}AR.
+ */
+static void prepare_selector(uint8_t *sel)
+{
+    uint8_t cur_sel = *sel;
+    /* The top 24 bits of HPRSELR are RES0. */
+    uint8_t val = READ_SYSREG(HPRSELR) & 0xff;
+
+    if ( (cur_sel > 31) && (cur_sel != val) )
+    {
+        WRITE_SYSREG(cur_sel, HPRSELR);
+        isb();
+    }
+}
+
+void read_protection_region(pr_t *pr_read, uint8_t sel)
+{
+    prepare_selector(&sel);
+
+    switch ( sel )
+    {
+        GENERATE_READ_PR_REG_CASE(0, pr_read);
+        GENERATE_READ_PR_REG_CASE(1, pr_read);
+        GENERATE_READ_PR_REG_CASE(2, pr_read);
+        GENERATE_READ_PR_REG_CASE(3, pr_read);
+        GENERATE_READ_PR_REG_CASE(4, pr_read);
+        GENERATE_READ_PR_REG_CASE(5, pr_read);
+        GENERATE_READ_PR_REG_CASE(6, pr_read);
+        GENERATE_READ_PR_REG_CASE(7, pr_read);
+        GENERATE_READ_PR_REG_CASE(8, pr_read);
+        GENERATE_READ_PR_REG_CASE(9, pr_read);
+        GENERATE_READ_PR_REG_CASE(10, pr_read);
+        GENERATE_READ_PR_REG_CASE(11, pr_read);
+        GENERATE_READ_PR_REG_CASE(12, pr_read);
+        GENERATE_READ_PR_REG_CASE(13, pr_read);
+        GENERATE_READ_PR_REG_CASE(14, pr_read);
+        GENERATE_READ_PR_REG_CASE(15, pr_read);
+        GENERATE_READ_PR_REG_CASE(16, pr_read);
+        GENERATE_READ_PR_REG_CASE(17, pr_read);
+        GENERATE_READ_PR_REG_CASE(18, pr_read);
+        GENERATE_READ_PR_REG_CASE(19, pr_read);
+        GENERATE_READ_PR_REG_CASE(20, pr_read);
+        GENERATE_READ_PR_REG_CASE(21, pr_read);
+        GENERATE_READ_PR_REG_CASE(22, pr_read);
+        GENERATE_READ_PR_REG_CASE(23, pr_read);
+        GENERATE_READ_PR_REG_CASE(24, pr_read);
+        GENERATE_READ_PR_REG_CASE(25, pr_read);
+        GENERATE_READ_PR_REG_CASE(26, pr_read);
+        GENERATE_READ_PR_REG_CASE(27, pr_read);
+        GENERATE_READ_PR_REG_CASE(28, pr_read);
+        GENERATE_READ_PR_REG_CASE(29, pr_read);
+        GENERATE_READ_PR_REG_CASE(30, pr_read);
+        GENERATE_READ_PR_REG_CASE(31, pr_read);
+        GENERATE_READ_PR_REG_OTHERS(32 ... 254, pr_read);
+    default:
+        BUG(); /* Can't happen */
+        break;
+    }
+}
+
+void write_protection_region(const pr_t *pr_write, uint8_t sel)
+{
+    prepare_selector(&sel);
+
+    switch ( sel )
+    {
+        GENERATE_WRITE_PR_REG_CASE(0, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(1, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(2, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(3, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(4, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(5, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(6, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(7, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(8, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(9, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(10, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(11, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(12, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(13, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(14, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(15, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(16, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(17, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(18, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(19, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(20, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(21, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(22, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(23, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(24, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(25, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(26, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(27, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(28, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(29, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(30, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(31, pr_write);
+        GENERATE_WRITE_PR_REG_OTHERS(32 ... 254, pr_write);
+    default:
+        BUG(); /* Can't happen */
+        break;
+    }
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
index 7ab68fc8c7..ccfb37a67b 100644
--- a/xen/arch/arm/mpu/mm.c
+++ b/xen/arch/arm/mpu/mm.c
@@ -39,7 +39,6 @@ static void __init __maybe_unused build_assertions(void)
     BUILD_BUG_ON(PAGE_SIZE != SZ_4K);
 }
 
-#ifdef CONFIG_ARM_64
 pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags)
 {
     unsigned int attr_idx = PAGE_AI_MASK(flags);
@@ -110,7 +109,6 @@ pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags)
 
     return region;
 }
-#endif /* CONFIG_ARM_64 */
 
 void __init setup_mm(void)
 {
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Thu Jun 19 11:38:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 11:38:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019959.1396406 (Exim 4.92)
	(envelope-from )
	id 1uSDax-00025k-RI; Thu, 19 Jun 2025 11:38:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019959.1396406; Thu, 19 Jun 2025 11: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 1uSDax-00025b-Oc; Thu, 19 Jun 2025 11:38:15 +0000
Received: by outflank-mailman (input) for mailman id 1019959;
 Thu, 19 Jun 2025 11:38: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 1uSDaw-00024Q-L0
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 11:38:14 +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 e20a718e-4d01-11f0-a30c-13f23c93f187;
 Thu, 19 Jun 2025 13:38:13 +0200 (CEST)
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 D41391F38D;
 Thu, 19 Jun 2025 11:38: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 97D23136CC;
 Thu, 19 Jun 2025 11:38: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 dzBmI6T2U2hdbgAAD6G6ig
 (envelope-from ); Thu, 19 Jun 2025 11:38: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: e20a718e-4d01-11f0-a30c-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750333093; 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=4NoXCUJ5pbRtKgxow6UIhaYz4x9FU3aA2ofy2y28z+k=;
	b=l3NDVSZyBXd6Z+VTJoUNcoN2B3WvjsNPdkRVRQWhFK0pJsWRHgzBwTcB13hmLzohRjUtzz
	2vsI2QNXOpX3C3v+AEz0p927igtaque4yFWjg/T6BhYygHc9v2PQ74FyIkUAN54oKzAiT1
	nvj+a39NlLYIbihX7Z4yoGtKU3gcxoo=
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750333092; 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=4NoXCUJ5pbRtKgxow6UIhaYz4x9FU3aA2ofy2y28z+k=;
	b=qa9mkXZ37DVz9h4UFXq4IYoSZ84vVmAkzx3WRHkjyOpeb3DwFAoujOwgiXpAlQFPvq/VMC
	Ic/GnQytzbBCPPITry52MQgVXAplLeAKZclI5lDAntSzhJgu3L1+Fb/A7coIbS2wSaCeVH
	tZrwMBPfphLUwjxdyDPqYSryCId414c=
From: Juergen Gross 
To: minios-devel@lists.xenproject.org,
	xen-devel@lists.xenproject.org
Cc: samuel.thibault@ens-lyon.org,
	Juergen Gross 
Subject: [MINI-OS PATCH 1/6] suspend: drop crazy pfn handling for PVH
Date: Thu, 19 Jun 2025 13:37:59 +0200
Message-ID: <20250619113804.32694-2-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250619113804.32694-1-jgross@suse.com>
References: <20250619113804.32694-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Flag: NO
X-Spam-Score: -6.80
X-Spamd-Result: default: False [-6.80 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[99.99%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-0.999];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	ARC_NA(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo]
X-Spam-Level: 

Suspend for PVH is doing some crazy stuff with the Xenstore and console
PFNs:

- In arch_pre_suspend() the PFNs are "translated" to MFNs, even if that
   translation is a nop.
- The result is stored via start_info_ptr, which points to a struct
  start_info only in case of PV mode.
- After resuming or a cancelled suspend, the PFNs are retrieved again
  and "translated".
- The "MFNs" are stored again via start_info_ptr, which is still not
  pointing at a struct start_info, and from where the data is never
  read again after that.

Drop all of that completely.

Signed-off-by: Juergen Gross 
---
 arch/x86/setup.c | 22 ----------------------
 1 file changed, 22 deletions(-)

diff --git a/arch/x86/setup.c b/arch/x86/setup.c
index b613083b..e30eb065 100644
--- a/arch/x86/setup.c
+++ b/arch/x86/setup.c
@@ -227,17 +227,6 @@ void arch_pre_suspend(void)
         virt_to_pfn(mfn_to_virt(start_info_ptr->store_mfn));
     start_info_ptr->console.domU.mfn =
         virt_to_pfn(mfn_to_virt(start_info_ptr->console.domU.mfn));
-#else
-    uint64_t store_v;
-    uint64_t console_v;
-
-    if( hvm_get_parameter(HVM_PARAM_STORE_PFN, &store_v) )
-        BUG();
-    start_info_ptr->store_mfn = store_v;
-
-    if( hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, &console_v) )
-        BUG();
-    start_info_ptr->console.domU.mfn = console_v;
 #endif
     unmap_shared_info();
 
@@ -262,17 +251,6 @@ void arch_post_suspend(int canceled)
     } else {
         memcpy(&start_info, start_info_ptr, sizeof(start_info_t));
     }
-#else
-    uint64_t store_v;
-    uint64_t console_v;
-
-    if (hvm_get_parameter(HVM_PARAM_STORE_PFN, &store_v))
-        BUG();
-    start_info_ptr->store_mfn = pfn_to_mfn(store_v);
-
-    if (hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, &console_v))
-        BUG();
-    start_info_ptr->console.domU.mfn = pfn_to_mfn(console_v);
 #endif
 
     HYPERVISOR_shared_info = map_shared_info((void*) start_info_ptr);
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 19 11:38:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 11:38:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019957.1396394 (Exim 4.92)
	(envelope-from )
	id 1uSDau-0001pD-KZ; Thu, 19 Jun 2025 11:38:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019957.1396394; Thu, 19 Jun 2025 11:38:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSDau-0001p6-GH; Thu, 19 Jun 2025 11:38:12 +0000
Received: by outflank-mailman (input) for mailman id 1019957;
 Thu, 19 Jun 2025 11: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 1uSDas-0001ot-Mf
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 11:38:10 +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 debb2229-4d01-11f0-b894-0df219b8e170;
 Thu, 19 Jun 2025 13:38:07 +0200 (CEST)
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 29D2421167;
 Thu, 19 Jun 2025 11:38:07 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id E7FAE136CC;
 Thu, 19 Jun 2025 11:38: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 y8a9Np72U2hVbgAAD6G6ig
 (envelope-from ); Thu, 19 Jun 2025 11:38: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: debb2229-4d01-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750333087; 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=fHu1G+O8pg228Mge4annxJlFqTCUB9Its+MVOrMgr5k=;
	b=cgREe0QHD/+lvL9hfMzJWOenrMciV0S97Sv1mW2XobOLy3ffugLwYKtTGyUKpaXAzm0Ho4
	4CTUEbB9hmpHGOH4GWCOthxYpx3b4ofL4GNtvFfO4Z9AFFZT+cX4+vsdo5yoBReZYfE5jZ
	VTU06wFAnB8NEqv5O9hUm8mwB7BPYTw=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750333087; 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=fHu1G+O8pg228Mge4annxJlFqTCUB9Its+MVOrMgr5k=;
	b=cgREe0QHD/+lvL9hfMzJWOenrMciV0S97Sv1mW2XobOLy3ffugLwYKtTGyUKpaXAzm0Ho4
	4CTUEbB9hmpHGOH4GWCOthxYpx3b4ofL4GNtvFfO4Z9AFFZT+cX4+vsdo5yoBReZYfE5jZ
	VTU06wFAnB8NEqv5O9hUm8mwB7BPYTw=
From: Juergen Gross 
To: minios-devel@lists.xenproject.org,
	xen-devel@lists.xenproject.org
Cc: samuel.thibault@ens-lyon.org,
	Juergen Gross 
Subject: [MINI-OS PATCH 0/6] hide struct start_info from PVH code
Date: Thu, 19 Jun 2025 13:37:58 +0200
Message-ID: <20250619113804.32694-1-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-2.80 / 50.00];
	BAYES_HAM(-3.00)[99.99%];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	MID_CONTAINS_FROM(1.00)[];
	R_MISSING_CHARSET(0.50)[];
	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_THREE(0.00)[4];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Level: 
X-Spam-Flag: NO
X-Spam-Score: -2.80

While working on xenstore-stubdom live update support I came across
some really unpleasant code using struct start_info even when running
in PVH mode.

Especially suspend/resume was doing some crazy stuff, including
overwriting the initial struct hvm_start_info partially.

This series is hiding struct start_info from PVH code. This didn't
result in any runtime error, but in future I'll need to access struct
hvm_start_info some time after boot, so I need to get that fixed.

Tested especially with xl suspend/resume and xl save/restore in PV and
in PVH mode.

Juergen Gross (6):
  suspend: drop crazy pfn handling for PVH
  setup: drop parameter from map_shared_info()
  x86/pv: remove global start_info
  console: drop parameter from get_console()
  xenbus: drop parameter from get_xenbus()
  x86/pv: make start_info_ptr PV-only

 arch/arm/setup.c     |  6 ++--
 arch/x86/setup.c     | 69 ++++++++++++--------------------------------
 console.c            | 10 +++----
 hypervisor.c         |  2 +-
 include/console.h    |  2 +-
 include/hypervisor.h | 14 ++-------
 include/xenbus.h     |  4 +--
 xenbus.c             | 13 ++++-----
 8 files changed, 39 insertions(+), 81 deletions(-)

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 19 11:38:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 11:38:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019962.1396426 (Exim 4.92)
	(envelope-from )
	id 1uSDb3-0002RP-Fa; Thu, 19 Jun 2025 11:38:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019962.1396426; Thu, 19 Jun 2025 11:38: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 1uSDb3-0002Qy-8Z; Thu, 19 Jun 2025 11:38:21 +0000
Received: by outflank-mailman (input) for mailman id 1019962;
 Thu, 19 Jun 2025 11:38: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 1uSDb2-0001ot-Bc
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 11:38:20 +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 e555dc00-4d01-11f0-b894-0df219b8e170;
 Thu, 19 Jun 2025 13:38:18 +0200 (CEST)
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 75DFA1F38D;
 Thu, 19 Jun 2025 11:38: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 45125136CC;
 Thu, 19 Jun 2025 11:38:18 +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 Xpc1D6r2U2hjbgAAD6G6ig
 (envelope-from ); Thu, 19 Jun 2025 11:38:18 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e555dc00-4d01-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750333098; 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=q7iU8G8KB8ff9iK1iRznz/sdoVaMREHLMXYxPjB0hj4=;
	b=JU0g8i4NjM0Qn9aAyZ4vguZqi6Ro4/zU7IWxryoabJw91KRD4dWnaGFMGyDS1ehQtHE5+U
	Oo2R2IWiB6rUjNam/KNqdt0PjB/P77sPfbF5bDAxeIaayXD601uc1BsYB+1k4Iiv1cdPLr
	eIpV7yRC0O/dontmnMW78PJEk4DE7Gg=
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750333098; 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=q7iU8G8KB8ff9iK1iRznz/sdoVaMREHLMXYxPjB0hj4=;
	b=JU0g8i4NjM0Qn9aAyZ4vguZqi6Ro4/zU7IWxryoabJw91KRD4dWnaGFMGyDS1ehQtHE5+U
	Oo2R2IWiB6rUjNam/KNqdt0PjB/P77sPfbF5bDAxeIaayXD601uc1BsYB+1k4Iiv1cdPLr
	eIpV7yRC0O/dontmnMW78PJEk4DE7Gg=
From: Juergen Gross 
To: minios-devel@lists.xenproject.org,
	xen-devel@lists.xenproject.org
Cc: samuel.thibault@ens-lyon.org,
	Juergen Gross 
Subject: [MINI-OS PATCH 2/6] setup: drop parameter from map_shared_info()
Date: Thu, 19 Jun 2025 13:38:00 +0200
Message-ID: <20250619113804.32694-3-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250619113804.32694-1-jgross@suse.com>
References: <20250619113804.32694-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-6.80 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[100.00%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-0.999];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	ARC_NA(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo]
X-Spam-Level: 
X-Spam-Flag: NO
X-Spam-Score: -6.80

The parameter of map_shared_info() is evaluated in PV mode only, and it
is always the pointer to the initial struct start_info from boot time.

By setting start_info_ptr a little bit earlier the PV variant of
map_shared_info() can just use start_info_ptr instead of a parameter.

Signed-off-by: Juergen Gross 
---
 arch/arm/setup.c     |  2 +-
 arch/x86/setup.c     | 12 ++++++------
 hypervisor.c         |  2 +-
 include/hypervisor.h |  2 +-
 4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm/setup.c b/arch/arm/setup.c
index 3d112fae..1bcfa689 100644
--- a/arch/arm/setup.c
+++ b/arch/arm/setup.c
@@ -38,7 +38,7 @@ void arch_init(void *dtb_pointer, uint32_t physical_offset)
     device_tree = dtb_pointer;
 
     /* Map shared_info page */
-    HYPERVISOR_shared_info = map_shared_info(NULL);
+    HYPERVISOR_shared_info = map_shared_info();
 
     get_console(NULL);
     get_xenbus(NULL);
diff --git a/arch/x86/setup.c b/arch/x86/setup.c
index e30eb065..1bdf9509 100644
--- a/arch/x86/setup.c
+++ b/arch/x86/setup.c
@@ -79,11 +79,10 @@ static inline void sse_init(void) {
 #ifdef CONFIG_PARAVIRT
 #define hpc_init()
 
-shared_info_t *map_shared_info(void *p)
+shared_info_t *map_shared_info(void)
 {
     int rc;
-    start_info_t *si = p;
-    unsigned long pa = si->shared_info;
+    unsigned long pa = start_info_ptr->shared_info;
 
     if ( (rc = HYPERVISOR_update_va_mapping((unsigned long)shared_info,
                                             __pte(pa | 7), UVMF_INVLPG)) )
@@ -185,6 +184,8 @@ arch_init(void *par)
 {
 	static char hello[] = "Bootstrapping...\n";
 
+	start_info_ptr = par;
+
 	hpc_init();
 	(void)HYPERVISOR_console_io(CONSOLEIO_write, strlen(hello), hello);
 
@@ -206,7 +207,7 @@ arch_init(void *par)
 	get_cmdline(par);
 
 	/* Grab the shared_info pointer and put it in a safe place. */
-	HYPERVISOR_shared_info = map_shared_info(par);
+	HYPERVISOR_shared_info = map_shared_info();
 
 	/* print out some useful information  */
 	print_start_of_day(par);
@@ -214,7 +215,6 @@ arch_init(void *par)
 #ifdef CONFIG_PARAVIRT
 	memcpy(&start_info, par, sizeof(start_info));
 #endif
-	start_info_ptr = (start_info_t *)par;
 
 	start_kernel();
 }
@@ -253,7 +253,7 @@ void arch_post_suspend(int canceled)
     }
 #endif
 
-    HYPERVISOR_shared_info = map_shared_info((void*) start_info_ptr);
+    HYPERVISOR_shared_info = map_shared_info();
 #ifndef CONFIG_PARAVIRT
     xen_callback_vector();
 #endif
diff --git a/hypervisor.c b/hypervisor.c
index ba535556..6476d658 100644
--- a/hypervisor.c
+++ b/hypervisor.c
@@ -65,7 +65,7 @@ int hvm_set_parameter(int idx, uint64_t value)
     return HYPERVISOR_hvm_op(HVMOP_set_param, &xhv);
 }
 
-shared_info_t *map_shared_info(void *p)
+shared_info_t *map_shared_info(void)
 {
     struct xen_add_to_physmap xatp;
 
diff --git a/include/hypervisor.h b/include/hypervisor.h
index b852a42a..aef142d1 100644
--- a/include/hypervisor.h
+++ b/include/hypervisor.h
@@ -42,7 +42,7 @@ extern union start_info_union start_info_union;
 int hvm_get_parameter(int idx, uint64_t *value);
 int hvm_set_parameter(int idx, uint64_t value);
 #endif
-shared_info_t *map_shared_info(void *p);
+shared_info_t *map_shared_info(void);
 void unmap_shared_info(void);
 void force_evtchn_callback(void);
 void do_hypervisor_callback(struct pt_regs *regs);
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 19 11:38:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 11:38:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019967.1396440 (Exim 4.92)
	(envelope-from )
	id 1uSDbA-0002vg-OD; Thu, 19 Jun 2025 11:38:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019967.1396440; Thu, 19 Jun 2025 11:38: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 1uSDbA-0002uD-IN; Thu, 19 Jun 2025 11:38:28 +0000
Received: by outflank-mailman (input) for mailman id 1019967;
 Thu, 19 Jun 2025 11:38: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 1uSDb8-0001ot-UR
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 11:38:26 +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 e8ad46f0-4d01-11f0-b894-0df219b8e170;
 Thu, 19 Jun 2025 13:38:24 +0200 (CEST)
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 2242D21167;
 Thu, 19 Jun 2025 11:38: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 E34FC136CC;
 Thu, 19 Jun 2025 11:38: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 GWO6Na/2U2hobgAAD6G6ig
 (envelope-from ); Thu, 19 Jun 2025 11:38: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: e8ad46f0-4d01-11f0-b894-0df219b8e170
Authentication-Results: smtp-out1.suse.de;
	none
From: Juergen Gross 
To: minios-devel@lists.xenproject.org,
	xen-devel@lists.xenproject.org
Cc: samuel.thibault@ens-lyon.org,
	Juergen Gross 
Subject: [MINI-OS PATCH 3/6] x86/pv: remove global start_info
Date: Thu, 19 Jun 2025 13:38:01 +0200
Message-ID: <20250619113804.32694-4-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250619113804.32694-1-jgross@suse.com>
References: <20250619113804.32694-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Spamd-Result: default: False [-4.00 / 50.00];
	REPLY(-4.00)[]
X-Rspamd-Queue-Id: 2242D21167
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Action: no action
X-Spam-Level: 
X-Spam-Flag: NO
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Score: -4.00

Add an extern declaration for start_info_ptr when running in PV mode
and use that instead of the copy held in start_info. This allows to
drop start_info.

Signed-off-by: Juergen Gross 
---
 arch/x86/setup.c     | 17 +----------------
 console.c            |  2 +-
 include/hypervisor.h | 12 ++----------
 xenbus.c             |  2 +-
 4 files changed, 5 insertions(+), 28 deletions(-)

diff --git a/arch/x86/setup.c b/arch/x86/setup.c
index 1bdf9509..4e2f0749 100644
--- a/arch/x86/setup.c
+++ b/arch/x86/setup.c
@@ -35,17 +35,8 @@
 #include 
 #include 
 
-#ifdef CONFIG_PARAVIRT
-/*
- * This structure contains start-of-day info, such as pagetable base pointer,
- * address of the shared_info structure, and things like that.
- */
-union start_info_union start_info_union;
-EXPORT_SYMBOL(start_info_union);
-#endif
-
 /*
- * This pointer holds a reference to the copy of the start_info struct.
+ * This pointer holds a reference to the start_info struct.
  */
 start_info_t *start_info_ptr;
 
@@ -212,10 +203,6 @@ arch_init(void *par)
 	/* print out some useful information  */
 	print_start_of_day(par);
 
-#ifdef CONFIG_PARAVIRT
-	memcpy(&start_info, par, sizeof(start_info));
-#endif
-
 	start_kernel();
 }
 
@@ -248,8 +235,6 @@ void arch_post_suspend(int canceled)
     if (canceled) {
         start_info_ptr->store_mfn = pfn_to_mfn(start_info_ptr->store_mfn);
         start_info_ptr->console.domU.mfn = pfn_to_mfn(start_info_ptr->console.domU.mfn);
-    } else {
-        memcpy(&start_info, start_info_ptr, sizeof(start_info_t));
     }
 #endif
 
diff --git a/console.c b/console.c
index 0107b685..a4c50371 100644
--- a/console.c
+++ b/console.c
@@ -411,7 +411,7 @@ void xencons_ring_resume(struct consfront_dev *dev)
     if ( dev )
     {
 #if CONFIG_PARAVIRT
-        get_console(&start_info);
+        get_console(start_info_ptr);
 #else
         get_console(0);
 #endif
diff --git a/include/hypervisor.h b/include/hypervisor.h
index aef142d1..f40bc8c3 100644
--- a/include/hypervisor.h
+++ b/include/hypervisor.h
@@ -28,16 +28,8 @@
 
 /* hypervisor.c */
 #ifdef CONFIG_PARAVIRT
-/*
- * a placeholder for the start of day information passed up from the hypervisor
- */
-union start_info_union
-{
-    start_info_t start_info;
-    char padding[512];
-};
-extern union start_info_union start_info_union;
-#define start_info (start_info_union.start_info)
+/* A pointer to the start of day information passed up from the hypervisor. */
+extern start_info_t *start_info_ptr;
 #else
 int hvm_get_parameter(int idx, uint64_t *value);
 int hvm_set_parameter(int idx, uint64_t value);
diff --git a/xenbus.c b/xenbus.c
index 686428a4..43fdebd7 100644
--- a/xenbus.c
+++ b/xenbus.c
@@ -469,7 +469,7 @@ void resume_xenbus(int canceled)
     struct xsd_sockmsg *rep;
 
 #ifdef CONFIG_PARAVIRT
-    get_xenbus(&start_info);
+    get_xenbus(start_info_ptr);
 #else
     get_xenbus(0);
 #endif
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 19 11:38:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 11:38:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1019971.1396449 (Exim 4.92)
	(envelope-from )
	id 1uSDbD-0003Km-V5; Thu, 19 Jun 2025 11:38:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1019971.1396449; Thu, 19 Jun 2025 11: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 1uSDbD-0003Kb-RW; Thu, 19 Jun 2025 11:38:31 +0000
Received: by outflank-mailman (input) for mailman id 1019971;
 Thu, 19 Jun 2025 11:38: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 1uSDbC-00024Q-Od
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 11:38:30 +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 ec22576f-4d01-11f0-a30c-13f23c93f187;
 Thu, 19 Jun 2025 13:38:30 +0200 (CEST)
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 C6D1021167;
 Thu, 19 Jun 2025 11:38: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 9369C136CC;
 Thu, 19 Jun 2025 11:38: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 2acoIrX2U2hsbgAAD6G6ig
 (envelope-from ); Thu, 19 Jun 2025 11:38: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: ec22576f-4d01-11f0-a30c-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750333109; 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=mAZCg+rbfuFhOY9Ie1hCPmXCmFyEVH0iN6dKrSsrr9A=;
	b=UlSupCBty164s4CUAm/vTsyKp/eEua2pc959kIgjS9STIlMOhCgls7fOQIwjGxTVg+3K3f
	7Pv5AWFTSkKUxRnj++U7ZO7jYFgdMsHtlAS4QOHcHDNoPGW9yoLCNolsOseKSg6JvewZ9K
	PkvbBdj+514ZuOehxhaa035Ex7muHHw=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750333109; 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=mAZCg+rbfuFhOY9Ie1hCPmXCmFyEVH0iN6dKrSsrr9A=;
	b=UlSupCBty164s4CUAm/vTsyKp/eEua2pc959kIgjS9STIlMOhCgls7fOQIwjGxTVg+3K3f
	7Pv5AWFTSkKUxRnj++U7ZO7jYFgdMsHtlAS4QOHcHDNoPGW9yoLCNolsOseKSg6JvewZ9K
	PkvbBdj+514ZuOehxhaa035Ex7muHHw=
From: Juergen Gross 
To: minios-devel@lists.xenproject.org,
	xen-devel@lists.xenproject.org
Cc: samuel.thibault@ens-lyon.org,
	Juergen Gross 
Subject: [MINI-OS PATCH 4/6] console: drop parameter from get_console()
Date: Thu, 19 Jun 2025 13:38:02 +0200
Message-ID: <20250619113804.32694-5-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250619113804.32694-1-jgross@suse.com>
References: <20250619113804.32694-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-6.80 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[100.00%];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	MID_CONTAINS_FROM(1.00)[];
	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_THREE(0.00)[4];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Level: 
X-Spam-Flag: NO
X-Spam-Score: -6.80

The parameter of get_console() is used only when running in PV mode,
and it always has the same value.

Drop the parameter and use start_info_ptr directly in the PV variant
of get_console().

Signed-off-by: Juergen Gross 
---
 arch/arm/setup.c  |  2 +-
 arch/x86/setup.c  |  2 +-
 console.c         | 10 +++++-----
 include/console.h |  2 +-
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/setup.c b/arch/arm/setup.c
index 1bcfa689..161d137d 100644
--- a/arch/arm/setup.c
+++ b/arch/arm/setup.c
@@ -40,7 +40,7 @@ void arch_init(void *dtb_pointer, uint32_t physical_offset)
     /* Map shared_info page */
     HYPERVISOR_shared_info = map_shared_info();
 
-    get_console(NULL);
+    get_console();
     get_xenbus(NULL);
 
     gic_init();
diff --git a/arch/x86/setup.c b/arch/x86/setup.c
index 4e2f0749..2b314aa2 100644
--- a/arch/x86/setup.c
+++ b/arch/x86/setup.c
@@ -193,7 +193,7 @@ arch_init(void *par)
 
 	/* WARN: don't do printk before here, it uses information from
 	   shared_info. Use xprintk instead. */
-	get_console(par);
+	get_console();
 	get_xenbus(par);
 	get_cmdline(par);
 
diff --git a/console.c b/console.c
index a4c50371..48c5be43 100644
--- a/console.c
+++ b/console.c
@@ -197,15 +197,15 @@ uint32_t console_evtchn;
 static struct consfront_dev* resume_xen_console(struct consfront_dev *dev);
 
 #ifdef CONFIG_PARAVIRT
-void get_console(void *p)
+void get_console(void)
 {
-    start_info_t *si = p;
+    start_info_t *si = start_info_ptr;
 
     console_ring = mfn_to_virt(si->console.domU.mfn);
     console_evtchn = si->console.domU.evtchn;
 }
 #else
-void get_console(void *p)
+void get_console(void)
 {
     uint64_t v = -1;
 
@@ -411,9 +411,9 @@ void xencons_ring_resume(struct consfront_dev *dev)
     if ( dev )
     {
 #if CONFIG_PARAVIRT
-        get_console(start_info_ptr);
+        get_console();
 #else
-        get_console(0);
+        get_console();
 #endif
         resume_xen_console(dev);
     }
diff --git a/include/console.h b/include/console.h
index d216d247..326e993b 100644
--- a/include/console.h
+++ b/include/console.h
@@ -76,7 +76,7 @@ void xprintk(const char *fmt, ...) __attribute__ ((format (printf, 1, 2)));
 void xencons_rx(char *buf, unsigned len, struct pt_regs *regs);
 void xencons_tx(void);
 
-void get_console(void *p);
+void get_console(void);
 void init_console(void);
 void console_print(struct consfront_dev *dev, const char *data, int length);
 void fini_consfront(struct consfront_dev *dev);
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 19 11:41:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 11:41:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020030.1396467 (Exim 4.92)
	(envelope-from )
	id 1uSDdr-00065P-GO; Thu, 19 Jun 2025 11:41:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020030.1396467; Thu, 19 Jun 2025 11:41:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSDdr-00065I-Cf; Thu, 19 Jun 2025 11:41:15 +0000
Received: by outflank-mailman (input) for mailman id 1020030;
 Thu, 19 Jun 2025 11:41: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 1uSDbJ-0001ot-BS
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 11:38:37 +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 ef7b71d0-4d01-11f0-b894-0df219b8e170;
 Thu, 19 Jun 2025 13:38:35 +0200 (CEST)
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 7CAAE1F38D;
 Thu, 19 Jun 2025 11:38: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 48108136CC;
 Thu, 19 Jun 2025 11:38: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 Mbp1D7v2U2h3bgAAD6G6ig
 (envelope-from ); Thu, 19 Jun 2025 11:38: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: ef7b71d0-4d01-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750333115; 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=eszOXMsGlkE+H8zrsAa6Rle4nZFAVUiFkelGTk1DgeI=;
	b=l5z/LV3TOCWcbEgfUI8RB3O/gLtmfV+XUy8xNe1+ny6/t1zBTJ6U2AUIkz6plJwGdJ9yml
	d+GcgeWtmuka2hE7W44+/msbobLK6FsbpkjyguP5tavYMIhjxgR09jOVgLLbk+4skMWmUz
	jDr8dhPls+hgLm2MekfH1PqhJ0ZLllc=
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750333115; 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=eszOXMsGlkE+H8zrsAa6Rle4nZFAVUiFkelGTk1DgeI=;
	b=l5z/LV3TOCWcbEgfUI8RB3O/gLtmfV+XUy8xNe1+ny6/t1zBTJ6U2AUIkz6plJwGdJ9yml
	d+GcgeWtmuka2hE7W44+/msbobLK6FsbpkjyguP5tavYMIhjxgR09jOVgLLbk+4skMWmUz
	jDr8dhPls+hgLm2MekfH1PqhJ0ZLllc=
From: Juergen Gross 
To: minios-devel@lists.xenproject.org,
	xen-devel@lists.xenproject.org
Cc: samuel.thibault@ens-lyon.org,
	Juergen Gross 
Subject: [MINI-OS PATCH 5/6] xenbus: drop parameter from get_xenbus()
Date: Thu, 19 Jun 2025 13:38:03 +0200
Message-ID: <20250619113804.32694-6-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250619113804.32694-1-jgross@suse.com>
References: <20250619113804.32694-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-6.80 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[100.00%];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	MID_CONTAINS_FROM(1.00)[];
	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_THREE(0.00)[4];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Level: 
X-Spam-Flag: NO
X-Spam-Score: -6.80

The parameter of get_xenbus() is used only when running in PV mode,
and it always has the same value.

Drop the parameter and use start_info_ptr directly in the PV variant
of get_xenbus().

Signed-off-by: Juergen Gross 
---
 arch/arm/setup.c |  2 +-
 arch/x86/setup.c |  2 +-
 include/xenbus.h |  4 ++--
 xenbus.c         | 13 +++++--------
 4 files changed, 9 insertions(+), 12 deletions(-)

diff --git a/arch/arm/setup.c b/arch/arm/setup.c
index 161d137d..e918a064 100644
--- a/arch/arm/setup.c
+++ b/arch/arm/setup.c
@@ -41,7 +41,7 @@ void arch_init(void *dtb_pointer, uint32_t physical_offset)
     HYPERVISOR_shared_info = map_shared_info();
 
     get_console();
-    get_xenbus(NULL);
+    get_xenbus();
 
     gic_init();
 
diff --git a/arch/x86/setup.c b/arch/x86/setup.c
index 2b314aa2..590f51a8 100644
--- a/arch/x86/setup.c
+++ b/arch/x86/setup.c
@@ -194,7 +194,7 @@ arch_init(void *par)
 	/* WARN: don't do printk before here, it uses information from
 	   shared_info. Use xprintk instead. */
 	get_console();
-	get_xenbus(par);
+	get_xenbus();
 	get_cmdline(par);
 
 	/* Grab the shared_info pointer and put it in a safe place. */
diff --git a/include/xenbus.h b/include/xenbus.h
index 542ee456..21da05e2 100644
--- a/include/xenbus.h
+++ b/include/xenbus.h
@@ -12,7 +12,7 @@ extern struct xenstore_domain_interface *xenstore_buf;
 
 /* Initialize the XenBus system. */
 void init_xenbus(void);
-void get_xenbus(void *p);
+void get_xenbus(void);
 #else
 #define xenbus_evtchn ~0
 #define xenstore_buf NULL
@@ -20,7 +20,7 @@ void get_xenbus(void *p);
 static inline void init_xenbus(void)
 {
 }
-static inline void get_xenbus(void *p)
+static inline void get_xenbus(void)
 {
 }
 #endif
diff --git a/xenbus.c b/xenbus.c
index 43fdebd7..8225ed4b 100644
--- a/xenbus.c
+++ b/xenbus.c
@@ -74,15 +74,15 @@ uint32_t xenbus_evtchn;
 EXPORT_SYMBOL(xenbus_evtchn);
 
 #ifdef CONFIG_PARAVIRT
-void get_xenbus(void *p)
+void get_xenbus(void)
 {
-    start_info_t *si = p;
+    start_info_t *si = start_info_ptr;
 
     xenbus_evtchn = si->store_evtchn;
     xenstore_buf = mfn_to_virt(si->store_mfn);
 }
 #else
-void get_xenbus(void *p)
+void get_xenbus(void)
 {
     uint64_t v;
 
@@ -468,11 +468,8 @@ void resume_xenbus(int canceled)
     struct write_req req[2];
     struct xsd_sockmsg *rep;
 
-#ifdef CONFIG_PARAVIRT
-    get_xenbus(start_info_ptr);
-#else
-    get_xenbus(0);
-#endif
+    get_xenbus();
+
     unmask_evtchn(xenbus_evtchn);
 
     if ( !canceled )
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 19 11:41:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 11:41:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020034.1396477 (Exim 4.92)
	(envelope-from )
	id 1uSDe0-0006UD-NW; Thu, 19 Jun 2025 11:41:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020034.1396477; Thu, 19 Jun 2025 11:41:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSDe0-0006U6-JS; Thu, 19 Jun 2025 11:41:24 +0000
Received: by outflank-mailman (input) for mailman id 1020034;
 Thu, 19 Jun 2025 11:41: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 1uSDbP-0001ot-W6
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 11:38: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 f2dcd4a2-4d01-11f0-b894-0df219b8e170;
 Thu, 19 Jun 2025 13:38:41 +0200 (CEST)
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 3E47121167;
 Thu, 19 Jun 2025 11:38: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 05CCA136CC;
 Thu, 19 Jun 2025 11:38: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 8Sf2OsD2U2iIbgAAD6G6ig
 (envelope-from ); Thu, 19 Jun 2025 11:38: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: f2dcd4a2-4d01-11f0-b894-0df219b8e170
Authentication-Results: smtp-out1.suse.de;
	none
From: Juergen Gross 
To: minios-devel@lists.xenproject.org,
	xen-devel@lists.xenproject.org
Cc: samuel.thibault@ens-lyon.org,
	Juergen Gross 
Subject: [MINI-OS PATCH 6/6] x86/pv: make start_info_ptr PV-only
Date: Thu, 19 Jun 2025 13:38:04 +0200
Message-ID: <20250619113804.32694-7-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250619113804.32694-1-jgross@suse.com>
References: <20250619113804.32694-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Spam-Level: 
X-Spamd-Result: default: False [-4.00 / 50.00];
	REPLY(-4.00)[]
X-Spam-Flag: NO
X-Rspamd-Queue-Id: 3E47121167
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Action: no action
X-Spam-Score: -4.00

Hide start_info_ptr via CONFIG_PARAVIRT in order to avoid accesses to
it form not PV specific code.

Signed-off-by: Juergen Gross 
---
 arch/x86/setup.c | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/arch/x86/setup.c b/arch/x86/setup.c
index 590f51a8..b3fc835a 100644
--- a/arch/x86/setup.c
+++ b/arch/x86/setup.c
@@ -35,11 +35,6 @@
 #include 
 #include 
 
-/*
- * This pointer holds a reference to the start_info struct.
- */
-start_info_t *start_info_ptr;
-
 /*
  * Shared page for communicating with the hypervisor.
  * Events flags go here, for example.
@@ -68,6 +63,11 @@ static inline void sse_init(void) {
 #endif
 
 #ifdef CONFIG_PARAVIRT
+/*
+ * This pointer holds a reference to the start_info struct.
+ */
+start_info_t *start_info_ptr;
+
 #define hpc_init()
 
 shared_info_t *map_shared_info(void)
@@ -175,7 +175,9 @@ arch_init(void *par)
 {
 	static char hello[] = "Bootstrapping...\n";
 
+#ifdef CONFIG_PARAVIRT
 	start_info_ptr = par;
+#endif
 
 	hpc_init();
 	(void)HYPERVISOR_console_io(CONSOLEIO_write, strlen(hello), hello);
@@ -226,7 +228,11 @@ int arch_suspend(void)
      * This hypercall returns 1 if the suspend
      * was cancelled and 0 if resuming in a new domain
      */
+#ifdef CONFIG_PARAVIRT
     return HYPERVISOR_suspend(virt_to_mfn(start_info_ptr));
+#else
+    return HYPERVISOR_suspend(0);
+#endif
 }
 
 void arch_post_suspend(int canceled)
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 19 11:42:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 11:42:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020065.1396491 (Exim 4.92)
	(envelope-from )
	id 1uSDfA-0007XT-51; Thu, 19 Jun 2025 11:42:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020065.1396491; Thu, 19 Jun 2025 11:42:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSDfA-0007XM-2P; Thu, 19 Jun 2025 11:42:36 +0000
Received: by outflank-mailman (input) for mailman id 1020065;
 Thu, 19 Jun 2025 11:42: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 1uSDf8-0007X1-T6
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 11:42:34 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20629.outbound.protection.outlook.com
 [2a01:111:f403:2412::629])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7bd1ef40-4d02-11f0-b894-0df219b8e170;
 Thu, 19 Jun 2025 13:42:32 +0200 (CEST)
Received: from SN7P220CA0024.NAMP220.PROD.OUTLOOK.COM (2603:10b6:806:123::29)
 by CH1PPF93AB4E694.namprd12.prod.outlook.com
 (2603:10b6:61f:fc00::61b) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.25; Thu, 19 Jun
 2025 11:42:27 +0000
Received: from SN1PEPF000252A4.namprd05.prod.outlook.com
 (2603:10b6:806:123:cafe::7a) by SN7P220CA0024.outlook.office365.com
 (2603:10b6:806:123::29) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.35 via Frontend Transport; Thu,
 19 Jun 2025 11:42:26 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF000252A4.mail.protection.outlook.com (10.167.242.11) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8857.21 via Frontend Transport; Thu, 19 Jun 2025 11:42:25 +0000
Received: from xcbagarciav01.xilinx.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, 19 Jun
 2025 06:42:24 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7bd1ef40-4d02-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=evNbsyADLA/XXN8TreMBZFMBMxpBxPwSRQJK6zSTzgtovQrQKDwCAV8T4ojmN0BQk7+AcRTY2LB3c0WIp5AcPYEbPYMGtkHl1pxFrEwPPEDEpE6zv7dYK+aVJcmT9MHJ0eAy8s1pquG7w71rKPwSzhDNWCSyh8fkpHtcjiGl2+thLpZeG8N4ID30xI51wKyvADj/tLaEt78xezx8ibsqK81NfspvkjLHu+V3yXIkN924+Z5F+GcNAzw3dHU1+3cnBy62dSHmULtHySpwTLSHaYDtXfVudS06dI0Zwu2speCmEhuvx7vhWp0PDfnIXJ3IOdtGjQX3kdBdHqVvURZDGg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=dR665VFbvpwICSNfqh1RtfMKzGOK1awE1bBpdQm4HdA=;
 b=XoRdmHTRMrmoxGYfgZViBtspdAoiSYZv5s32PHrpo9h6/S49kKPSKt507s2l7LxCyF2eceyYXzgRIHqdD3kTheqseujUqXW9/N1oCbCVvAp6Q76oPvgKMWPACYpa/TgbhFNH+roryZYHf8IU5kqVmVcpvLdVH12dPGSZiSAOqknZ9PEnPe4xEkh8YASV1WuuZTwXXkp7XjvCco3zgPMVL/T2Zlm3hWlUeyLg7d/HRSHycrn0RfoDAXNMA7qgwuUl2O2nFjdC9ApQPU7ba/LnIozfySBvDyOrMUHj69ZQWii77vBufNepperPZtdEIqxSy8tuaMoGIQQp/jtZNGhzIg==
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=dR665VFbvpwICSNfqh1RtfMKzGOK1awE1bBpdQm4HdA=;
 b=yGNh8wepHvAFSoOvLlGZtzQ9ujeo/98KkqYD87bElJcIPr/KJSLt13QYKYdSfMzVn1YytCSlCDwKLs59V2L36tcIPsy6n/0oXeBuldXvRkfkrKeWptUMSYCFN7+QMlOo2bVTvYyRtH9OWqRlp04nxMO+UWWE2R0Uw0/YiothuyE=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel 
Subject: [PATCH v3] xen/dt: Remove loop in dt_read_number()
Date: Thu, 19 Jun 2025 13:42:04 +0200
Message-ID: <20250619114206.1014-1-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: 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: SN1PEPF000252A4:EE_|CH1PPF93AB4E694:EE_
X-MS-Office365-Filtering-Correlation-Id: 594bc3d3-18ab-4d83-b702-08ddaf265cf3
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|376014|36860700013|13003099007;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?hpsQ/Xb5r38Lamg8SDBg/E3YokCuVo3rbGjz+LEtiP7frRuLpaHfLTOOFXvK?=
 =?us-ascii?Q?GBprAGGApyVHDso0qSt0L6kiSSnXQz/Xl0JkneKrQ8QVoRt7TrxITg5L6KRM?=
 =?us-ascii?Q?SsodtEWhiFTNVKc8ImlXj/MQ6whIYWhCa32FaWeE/tLHSfSIhxeRV4qHkVOW?=
 =?us-ascii?Q?R+CJeqNGoHwZE582yvVDqpzU86CUd/O+o59rP4ok2Y4a0zM9NMSFr6SXB+7r?=
 =?us-ascii?Q?1bWJIrrufOHDUMZDi2RQZAmnqEoR02xjFvKDFJLSIZfg3r4GazWEUvEgpNq3?=
 =?us-ascii?Q?A80JkVFfj7ps52oFnDw20z+ELwLY3Q1MTWVpBBlOcqwfjhLoYs/JQeykbu2N?=
 =?us-ascii?Q?R1BOG04qq21/k+YayP8zlkXjMCEbC7HY/kJI7F3EaDUT7tvlzXET0X2bMpWQ?=
 =?us-ascii?Q?AUvjxHiBPZ5Qf0V7/yLxss63GKIL2esyAS1nHwhJXUtlN8gk/rNMcUHb/mJF?=
 =?us-ascii?Q?NMC3upMpG2daQMojRIgRNzm/03HO87KnvkcSIH+ysZiDS+13NjWI1peMZSmd?=
 =?us-ascii?Q?vvEJOBkLr4GITOTanZ+dSBXRBsjihAJQthKt+i45r75n5+yi3WDqd61fpu6m?=
 =?us-ascii?Q?uOljm2Rafs3l76S4s7e2zFGylG73J9yaqR8vdQS9C+bRyVXs+yzORS4GXHJ1?=
 =?us-ascii?Q?m/JZRersXXIli/cVI+1yhPeN1Xnckuw/CkarS35nm8uErH4IRpy2Sg0stR5b?=
 =?us-ascii?Q?BRqnJVKnuVXhXewMWx2glyYIUMif7al9slSJZTL60QPXYmwEfH1xUTkhws11?=
 =?us-ascii?Q?KjTHYZJk2oKykqbUDZ//vtiwXslNqpKs/ebALrziPpGZ8wrj+XTADc7/hnrC?=
 =?us-ascii?Q?FViibV1sZPEZmpMPi0YpMBD5GImGAWOBjSG2F9pT/rBPJJHRUCH7RpI9Ew2U?=
 =?us-ascii?Q?mWCvwI+BJd46AgSRTsIjzvSkZRY/mTrJg9Kuf3kPy6yesgD3bdDtARQqcGSR?=
 =?us-ascii?Q?1MQlFsqTPcIVwhcrPvnFlkGW3So2ey2uWRHCnYvTuR2eRI1Ajeuv5ub7BeKr?=
 =?us-ascii?Q?+znpIiyjZ/wI1Pmoxf9YpBHV+I2JX6O+NsbssgByG3vO34nxV5mwyUNlg3Z0?=
 =?us-ascii?Q?LtHLoSGuzxQAGVDd5/2to/qwdN1vtuZgcdDNWnBk+tq+7uBLHdWirXgPxK7b?=
 =?us-ascii?Q?6mcxyi3wET3UZow8p/BUKA+biw8RW3qCFQWx5JXzGD6FzLa5RYmmwrg8e/8S?=
 =?us-ascii?Q?u8x5MuEaOnyIBV25w3usarocaczaB+vF5PuZNdfKBmwQXYjcO4SEGwGT/RSa?=
 =?us-ascii?Q?ihCB5tzNyOoiURkiRK0161h3KYUAny0WUViscz1vF3SHkMNN3lIdqhiv7Zs4?=
 =?us-ascii?Q?SjyLs+SkJe6qZqDRp3J1VE0f5ENaGjFCEfDGqWMRETTXitQO1tnDFRHkUVr8?=
 =?us-ascii?Q?DkVivL7EH0siTXKOs0QNSNZ/85ICFCgQ1KBBL4t7irox1KF+NJiHDXDEtBKr?=
 =?us-ascii?Q?egmbKLY2ljrZA6HwrdXjH12SC+3oVj0E24ssMzw4pfQ9f2/1aaGeTuWpdK9c?=
 =?us-ascii?Q?K5s+IAyiuAIurY6EbQoT6tRW4q5c2ZCKydo8?=
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)(13003099007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jun 2025 11:42:25.8921
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 594bc3d3-18ab-4d83-b702-08ddaf265cf3
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:
	SN1PEPF000252A4.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH1PPF93AB4E694

The DT spec declares only two number types for a property: u32 and u64,
as per Table 2.3 in Section 2.2.4. Remove unbounded loop and replace
with a switch statement. Default to a size of 1 cell in the nonsensical
size case, with a warning printed on the Xen console.

Suggested-by: Daniel P. Smith" 
Signed-off-by: Alejandro Vallejo 
---
If there's any #address-size > 2 out there at least we'll know in debug builds.
It's not like this function can cope with them either way.

I haven't tested things past CI.

pipeline: https://gitlab.com/xen-project/people/agvallejo/xen/-/pipelines/1876848415

v3:
  * s/WARNING/ERR
  * //-style comment to /**/-style comment
  * break after ASSERT_UNREACHABLE() to please MISRA
---
 xen/include/xen/device_tree.h | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 75017e4266..d2de7c3a13 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -261,10 +261,22 @@ void intc_dt_preinit(void);
 /* Helper to read a big number; size is in cells (not bytes) */
 static inline u64 dt_read_number(const __be32 *cell, int size)
 {
-    u64 r = 0;
+    u64 r = be32_to_cpu(*cell);
+
+    switch ( size )
+    {
+    case 1:
+        break;
+    case 2:
+        r = (r << 32) | be32_to_cpu(cell[1]);
+        break;
+    default:
+        /* Nonsensical size. default to 1 */
+        printk(XENLOG_ERR "dt_read_number(,%d) bad size\n", size);
+        ASSERT_UNREACHABLE();
+        break;
+    };
 
-    while ( size-- )
-        r = (r << 32) | be32_to_cpu(*(cell++));
     return r;
 }
 

base-commit: 22650d6054625be10172fe0c78b9cadd1a39bd63
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 19 12:01:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 12:01:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020083.1396501 (Exim 4.92)
	(envelope-from )
	id 1uSDxg-0002e0-Rt; Thu, 19 Jun 2025 12:01:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020083.1396501; Thu, 19 Jun 2025 12:01: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 1uSDxg-0002dt-OL; Thu, 19 Jun 2025 12:01:44 +0000
Received: by outflank-mailman (input) for mailman id 1020083;
 Thu, 19 Jun 2025 12:01: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 1uSDxg-0002dn-8Q
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 12:01:44 +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 2a803cc5-4d05-11f0-a30c-13f23c93f187;
 Thu, 19 Jun 2025 14:01:43 +0200 (CEST)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-605b9488c28so1145197a12.2
 for ; Thu, 19 Jun 2025 05:01:43 -0700 (PDT)
Received: from ?IPV6:2003:e5:872a:8800:5c7b:1ac1:4fa0:423b?
 (p200300e5872a88005c7b1ac14fa0423b.dip0.t-ipconnect.de.
 [2003:e5:872a:8800:5c7b:1ac1:4fa0:423b])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-adfd0720ab5sm823538066b.185.2025.06.19.05.01.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 19 Jun 2025 05:01:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2a803cc5-4d05-11f0-a30c-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750334503; x=1750939303; 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=mQWBFKCcIjI+2GHAUqIjc/JzGfVN0510KNIBphtLO/o=;
        b=GCrJ7xzUeHgfOomnF87W46D5o6Cv/bxBbcP3nITIL2+ViJ88aqVr1u1HQAJ+JT7HUt
         +hMexg/SNfxZsH73XHx8Z3Z7ggw+tmaB7TWTnEzgFgT18JsCRklPQs/Idy59xTcLk0Xw
         O+6vp9UJXGcra1SibmoRA8RppgreBY996dkjC/mdX3eWZUpEMbOq1ZTpmFCt5kj1b99Z
         x5kQBYHMo7gOrWaSrwOUYqdQ/FZsDuujQldTt42D1vddT4Hc6OdewZteWxmRqmds8MWX
         Y/1RGqXXNp7Oy7OWeZBN22FGAedK70FW0y+7SdUi0qquL+KCWJZIjG8zCoOnFuNpO0ML
         HdGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750334503; x=1750939303;
        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=mQWBFKCcIjI+2GHAUqIjc/JzGfVN0510KNIBphtLO/o=;
        b=Qf1/ecAdqliU7VWLdCjzzOzV8+TNSKiVvEsYpRQa4u/uiH9Bra/3t8jK7Z1ZitL3Bh
         +QqHrBlWorhyFswBDObo3TgDpI7mICkJoLae4TZiLVPRal4KLwqLj98NqBk1N2Ee/3au
         ypCLEW/JLhpSeF+gwVQ1YcwZXdwcUlVG6zBmFstn2qSuveknOcdXBiYyDgcw1uB1NYza
         RrgF+nfHMwRGpfcUz5t3FPNpYb6pQMjM2FCXDN6kVfBRMXC/rm65dHG42pxDIKHEnkgb
         Ak4eBwAUX4wwUgUUvHj7Lu3nQvVtXC95Q+haCJD4jwjL5cbd1ZZKSZz9QEowUnO34bzr
         WIMQ==
X-Forwarded-Encrypted: i=1; AJvYcCWb5d8JoYQxVY4XYACVkRVQpslBAng9YCv+rUaOzC2gSd779QMhCr7E/I5hvbW8K5WZuKde2WDGyM0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyaXo5zyMVrRV2APVVunX1dKARA3PLnWII/PBDo0J6/BVR99VFX
	r7mpkxPg2KaGkqXbrWr22R6KND5H4jQFLkeQte8cYFx1FUWVntE5hGkfV2qQZcElcro=
X-Gm-Gg: ASbGnctGg/4tlGhwSkkdaTJT6zao5KuvAod2gvwlKgG0dtSWQ9mseRyjYxDkE1yVPlM
	y883/sE6sBzcze2CqLaCl+6gPgtOVYvUIwngq46jGKUIPQRYZjRljftdEN4xYGPD1ilhLNxBKhZ
	dqtIRUwBEh7PVPLkuCSsprg2JUpX78BBBhV9yZzW+RzlkQ/dkITe2F+llPXdPLTKpJegzkYYPIY
	AQCJpwrKtJPWoOLB55jrEOPPuADSJ69mRvsrZVW+nQ7UiH8tFLZO9YzNF5ZtfMjpHQ4oMZwgmZH
	1MWD2ZY21CngdHCwSJmaeco1dIlbu41+GhVMTSNjRGFtu8VdImOKU9BF3pDsBQBrhiX0CbAArrs
	jKUNYTMP0y4QER+V564CfUJ9fzFIRBXrMYtgm5bNolyzQ0bDrj1FI60dJZRUKhxGP6Gca+Nc8JG
	ut/u1zvMqLePw=
X-Google-Smtp-Source: AGHT+IFAc7aaeyQR+u3Qp6ZZL9xjGS0gaH8Cw0VO5A8C8IUvcBemrixfTptopbsWKNVAAqY+ZncUOA==
X-Received: by 2002:a17:907:6e91:b0:ad5:c462:3f60 with SMTP id a640c23a62f3a-adfad325b26mr2166147366b.16.1750334502423;
        Thu, 19 Jun 2025 05:01:42 -0700 (PDT)
Message-ID: <0f535bed-f4d4-4565-8f21-b10070f793e8@suse.com>
Date: Thu, 19 Jun 2025 14:01:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/xenbus: fix W=1 build warning in xenbus_va_dev_error
 function
To: jiang.peng9@zte.com.cn
Cc: sstabellini@kernel.org, oleksandr_tyshchenko@epam.com,
 xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
 xu.xin16@zte.com.cn, yang.yang29@zte.com.cn
References: <20250618100153468I5faNUAhCdtMA01OuuTKC@zte.com.cn>
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: <20250618100153468I5faNUAhCdtMA01OuuTKC@zte.com.cn>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------pIbwnhlV2pr3af8slEfk65pC"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------pIbwnhlV2pr3af8slEfk65pC
Content-Type: multipart/mixed; boundary="------------9LoeFzoPI9I8CWJIybO0v1mD";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: jiang.peng9@zte.com.cn
Cc: sstabellini@kernel.org, oleksandr_tyshchenko@epam.com,
 xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
 xu.xin16@zte.com.cn, yang.yang29@zte.com.cn
Message-ID: <0f535bed-f4d4-4565-8f21-b10070f793e8@suse.com>
Subject: Re: [PATCH] xen/xenbus: fix W=1 build warning in xenbus_va_dev_error
 function
References: <20250618100153468I5faNUAhCdtMA01OuuTKC@zte.com.cn>
In-Reply-To: <20250618100153468I5faNUAhCdtMA01OuuTKC@zte.com.cn>

--------------9LoeFzoPI9I8CWJIybO0v1mD
Content-Type: multipart/mixed; boundary="------------SFR1VYhggWr44jaU2dH900x1"

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

T24gMTguMDYuMjUgMDQ6MDEsIGppYW5nLnBlbmc5QHp0ZS5jb20uY24gd3JvdGU6DQo+IEZy
b206IFBlbmcgSmlhbmcgPGppYW5nLnBlbmc5QHp0ZS5jb20uY24+DQo+IA0KPiANCj4gVGhp
cyBwYXRjaCBmaXhlcyBhIFc9MSBmb3JtYXQtc3RyaW5nIHdhcm5pbmcgcmVwb3J0ZWQgYnkg
R0NDIDEyLjMuMA0KPiANCj4gYnkgYW5ub3RhdGluZyB4ZW5idXNfc3dpdGNoX2ZhdGFsKCkg
YW5kIHhlbmJ1c192YV9kZXZfZXJyb3IoKQ0KPiANCj4gd2l0aCB0aGUgX19wcmludGYgYXR0
cmlidXRlLiBUaGUgYXR0cmlidXRlIGVuYWJsZXMgY29tcGlsZS10aW1lDQo+IA0KPiB2YWxp
ZGF0aW9uIG9mIHByaW50Zi1zdHlsZSBmb3JtYXQgc3RyaW5ncyBpbiB0aGVzZSBmdW5jdGlv
bnMuDQo+IA0KPiANCj4gVGhlIG9yaWdpbmFsIHdhcm5pbmcgdHJhY2U6DQo+IA0KPiBkcml2
ZXJzL3hlbi94ZW5idXMveGVuYnVzX2NsaWVudC5jOjMwNDo5OiB3YXJuaW5nOiBmdW5jdGlv
biANCj4gJ3hlbmJ1c192YV9kZXZfZXJyb3InIG1pZ2h0IGJlDQo+IA0KPiBhIGNhbmRpZGF0
ZSBmb3IgJ2dudV9wcmludGYnIGZvcm1hdCBhdHRyaWJ1dGUgWy1Xc3VnZ2VzdC1hdHRyaWJ1
dGU9Zm9ybWF0XQ0KPiANCj4gDQo+IFNpZ25lZC1vZmYtYnk6IFBlbmcgSmlhbmcgPGppYW5n
LnBlbmc5QHp0ZS5jb20uY24+DQoNCkknbSBmaW5lIHdpdGggdGhlIGNoYW5nZXMgYXMgc3Vj
aCwgYnV0IHBsZWFzZSBzZW5kIHRoZSBwYXRjaCBhcyBhDQpwbGFpbiB0ZXh0IGVtYWlsIChu
byBIVE1MKS4gT3RoZXJ3aXNlIEknbSBub3QgYWJsZSB0byBhcHBseSBpdC4NCg0KWW91IHNo
b3VsZCBsb29rIGludG8gRG9jdW1lbnRhdGlvbi9wcm9jZXNzL2VtYWlsLWNsaWVudHMucnN0
IGluIHRoZQ0Ka2VybmVsIHNvdXJjZSB0cmVlLg0KDQoNCkp1ZXJnZW4NCg==
--------------SFR1VYhggWr44jaU2dH900x1
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-----

--------------SFR1VYhggWr44jaU2dH900x1--

--------------9LoeFzoPI9I8CWJIybO0v1mD--

--------------pIbwnhlV2pr3af8slEfk65pC
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/Ey8FAmhT/CUFAwAAAAAACgkQsN6d1ii/Ey9e
iwgAjZ0P99yv3gxBPu4tRQ+wBr7DMe6QJn+0mYoOICGYadN7nb0dZ1ZpQfIxigE1OJ+T5801s+GU
mQtsqSo2xA6ZG7wP3wa/e498fMDxW2CXZjQNY41HkzdaSMI/K++Rm48Uf0vbhNcBWQ+0EaOnXtvP
VWY6tlDH6CTXyscvu3C6ft1Lc8m6l0SRjkLTgEIiMFXNZu78qiDeOd2LPRmDDBfAHih8Vq3XESo2
TkglfJtq3rlQjLYKKLO29vdTEM/56hYSGhln/9salr/EHlBJlVlOrKptbyskS21H6mLn2CA+Q6xU
gXwTIcVI4JkEO+XtltKLIVyflcFrvHDmzTWmirLQ2g==
=v/9o
-----END PGP SIGNATURE-----

--------------pIbwnhlV2pr3af8slEfk65pC--


From xen-devel-bounces@lists.xenproject.org Thu Jun 19 12:17:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 12:17:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020089.1396511 (Exim 4.92)
	(envelope-from )
	id 1uSECj-00055I-2Z; Thu, 19 Jun 2025 12:17:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020089.1396511; Thu, 19 Jun 2025 12:17: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 1uSECi-00055B-V6; Thu, 19 Jun 2025 12:17:16 +0000
Received: by outflank-mailman (input) for mailman id 1020089;
 Thu, 19 Jun 2025 12:17: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 1uSECh-000555-OI
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 12:17:15 +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 54e0caa4-4d07-11f0-a30c-13f23c93f187;
 Thu, 19 Jun 2025 14:17:14 +0200 (CEST)
Received: from phl-compute-07.internal (phl-compute-07.phl.internal
 [10.202.2.47])
 by mailfout.phl.internal (Postfix) with ESMTP id C6F40138048A;
 Thu, 19 Jun 2025 08:17:12 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-07.internal (MEProxy); Thu, 19 Jun 2025 08:17:12 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 19 Jun 2025 08:17:11 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 54e0caa4-4d07-11f0-a30c-13f23c93f187
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=1750335432;
	 x=1750421832; bh=8ndLJ3KjK4YwzNMs9dMFsK7lyQQzeJCPgfENcS+oFB0=; b=
	gL3Ux/B/ioAy7FUf4fYaFqfcdaMgZulqu9Tdo1y3XjLoLHoflldKXPo5uSFjKCyT
	ntuMuefrv7Zly8dCJYRyS+YtKVyaSamvsJvRqPJeaSBHpBSbqpoMP+muzrGumOrl
	1zWhxe4EkkVhVXhJsOnsBRqWF0qamQs+PL467jGjzuRUJ5I3kJ7PrfuS1hlmfU4M
	5WFDgVIgWWEH9s5EkHe7C7ehEyX6gwuOPYuga5HIsyOrNkpFn8Rvlaqm+qsAOLU9
	Peb79vuZW0/DePgyMFNb+qjS4639BdCtqhDiWtkpM8nHFxkRhP6CtxnK4guOIFUP
	ELWuWDFvamtlFsg2VNYMqw==
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=
	1750335432; x=1750421832; bh=8ndLJ3KjK4YwzNMs9dMFsK7lyQQzeJCPgfE
	NcS+oFB0=; b=Ru2qb2b1A5NhNSI+g0VLB9JV/RuK6sOrciOpe1PjtlWctw2NSvD
	Twzr8pVd2nmqfjL+szgzz6G9TzjRdQCTR0eoOjhbSoaCkdgxkUvIn3I/XD7mIqjg
	NNfZhx2yDzqfBrwqny0P8q1/AB6tHUgBsdA44/A0QPKooIIAVPHRkW2SIQlf04WN
	tIKOr9+jEZ7zX8rKgk+VRMA7/8h81uKlFapTpcx0Z/o7KP3FKjXJD7PvEx2eCvP9
	V2tlSC1JFS753LLIvk+d79YEsg3Q6wPth2wjjU1m4pWFgGyB/RGuPdKKpqLALTLl
	FDjeWccU11R64LRAv88BQd06Uwu6dYpyBEA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgdehhedtucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceurghi
    lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh
    epfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcuofgr
    rhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvihhsih
    gslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfduleetfeev
    hfefheeiteeliefhjefhleduveetteekveettddvgeeuteefjedunecuvehluhhsthgvrh
    fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhv
    ihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepgedpmhhoug
    gvpehsmhhtphhouhhtpdhrtghpthhtohepfhhrvgguihgrnhhordiiihhglhhiohestghl
    ohhuugdrtghomhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnph
    hrohhjvggtthdrohhrghdprhgtphhtthhopeguphhsmhhithhhsegrphgvrhhtuhhsshho
    lhhuthhiohhnshdrtghomhdprhgtphhtthhopehjsggvuhhlihgthhesshhushgvrdgtoh
    hm
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Thu, 19 Jun 2025 14:17:10 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Frediano Ziglio 
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" ,
	Jan Beulich 
Subject: Re: [PATCH] xen/efi: Do not check kernel signature if it was embedded
Message-ID: 
References: <20250618184631.15489-1-frediano.ziglio@cloud.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="wNBKY+LoGi8uoExl"
Content-Disposition: inline
In-Reply-To: <20250618184631.15489-1-frediano.ziglio@cloud.com>


--wNBKY+LoGi8uoExl
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 19 Jun 2025 14:17:10 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Frediano Ziglio 
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" ,
	Jan Beulich 
Subject: Re: [PATCH] xen/efi: Do not check kernel signature if it was embedded

On Wed, Jun 18, 2025 at 07:46:28PM +0100, Frediano Ziglio wrote:
> Using UKI it's possible to embed Linux kernel into xen.efi file.
> In this case the signature for Secure Boot is applied to the
> whole xen.efi, including the kernel.
> So checking for specific signature for the kernel is not
> needed.
> In case Secure Boot is not enabled there's no reason to check
> kernel signature.

The last sentence (here and in the comment below) seem to be unrelated
to this change - it's more about shim lock protocol being available,
which this patch doesn't change.
=20
> Signed-off-by: Frediano Ziglio 
> ---
>  xen/common/efi/boot.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>=20
> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> index e39fbc3529..7077af3f5d 100644
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -1291,6 +1291,7 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE Im=
ageHandle,
>      bool base_video =3D false;
>      const char *option_str;
>      bool use_cfg_file;
> +    bool kernel_was_verified =3D false;
>      int dt_modules_found;
> =20
>      __set_bit(EFI_BOOT, &efi_flags);
> @@ -1461,6 +1462,14 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE I=
mageHandle,
>              read_file(dir_handle, s2w(&name), &kernel, option_str);
>              efi_bs->FreePool(name.w);
>          }
> +        else
> +        {
> +            /*
> +             * As kernel was embedded it was either verified for Secure =
Boot
> +             * or Secure Boot is not enabled.
> +             */
> +            kernel_was_verified =3D true;
> +        }
> =20
>          if ( !read_section(loaded_image, L"ramdisk", &ramdisk, NULL) )
>          {
> @@ -1534,6 +1543,7 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE Im=
ageHandle,
>       * verify it.
>       */
>      if ( kernel.ptr &&
> +         !kernel_was_verified &&
>           !EFI_ERROR(efi_bs->LocateProtocol(&shim_lock_guid, NULL,
>                                             (void **)&shim_lock)) &&
>           (status =3D shim_lock->Verify(kernel.ptr, kernel.size)) !=3D EF=
I_SUCCESS )
> --=20
> 2.43.0
>=20

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

--wNBKY+LoGi8uoExl
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmhT/8YACgkQ24/THMrX
1yyTAQf/TGYthxmeBTFIJDcMkqYBFfZKP/INR+JfLPYM4VmxuPVxdT27DnJffMar
FZWykxDKZ+JcQ3nPCOEEf723ML91+mXMIFRjsQBDOdDmdBXZkesYg2edxTYx6wcb
yaQUQ9jqeryJ9Y7cI5BO5H0KSA9a3QQ7xOB4l2N1d8QV+C3BtrLOR4eP3hyrCwoS
B+7BdOJJX7z8CyDQzMT4dPIVlDVivmZR6kzm6H1egrgz6EUIHkAbz+pdWQLpp0Uq
sPTO6Rw/hHUvrRSjtvXVH7Hpjheo5ibw2N1vuNW2tF8DeGZ/cJOG6QISHr49d+Ss
bnuAAWKATLMPtgnbJ/5FRWK7TWuB7Q==
=4lba
-----END PGP SIGNATURE-----

--wNBKY+LoGi8uoExl--


From xen-devel-bounces@lists.xenproject.org Thu Jun 19 12:33:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 12:33:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020104.1396521 (Exim 4.92)
	(envelope-from )
	id 1uSESY-0008NP-C9; Thu, 19 Jun 2025 12:33:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020104.1396521; Thu, 19 Jun 2025 12:33:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSESY-0008NI-8g; Thu, 19 Jun 2025 12:33:38 +0000
Received: by outflank-mailman (input) for mailman id 1020104;
 Thu, 19 Jun 2025 12:33: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 1uSESW-0008NB-Ku
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 12:33:36 +0000
Received: from mail-oa1-x2d.google.com (mail-oa1-x2d.google.com
 [2001:4860:4864:20::2d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9d741fa8-4d09-11f0-a30c-13f23c93f187;
 Thu, 19 Jun 2025 14:33:34 +0200 (CEST)
Received: by mail-oa1-x2d.google.com with SMTP id
 586e51a60fabf-2d09d495c6cso173867fac.3
 for ; Thu, 19 Jun 2025 05:33:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9d741fa8-4d09-11f0-a30c-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750336413; x=1750941213; 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=WWlxgvF0Q3K/dkF6RTlL7Pv2byME2egFevB+nF/vBOA=;
        b=OM204pafLS3kmZvsjmwgHADAY8aEEhbo5oNPHFc0Qoz20pq9nYk5w9JINBm08+idT2
         YeZV9pQnK0nWT2naUqEqQ/bL8Bp4myXnQqhPvsQPe+nqfcBwO5pD4qDPyCsWidkkq2+J
         svWRnkSFZXQaP49Df9a3jIH9UidTjxOVoGPVM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750336413; x=1750941213;
        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=WWlxgvF0Q3K/dkF6RTlL7Pv2byME2egFevB+nF/vBOA=;
        b=isq+Eh6QapdkEkAkCkLLdw8WPXiplV/7gWAVF5rc6/HK9klMKbzuGz1jR98XSUZBAO
         gROWQIHWWp0Idtq64U4ZUHWUxzCqoMZwIi1l4p+34PQryO91XK015UyFjLD7+DwMefxN
         hVVBGC1thUrQ0/tRfDfMgIUcZfC2cTiszu1zUKmtSz83Ckojt4KwV1p56RF/ZGfrDoMr
         qrpjrcr1KLAohjL30X6InxKkI4wVJ3HFnbObDoSTMpQ5XJ0OUDXlq9eJ9Tgo3cGv3aLD
         YRNY8v+uYsyt6/BrFt2y6wRb4iPUWHhegT+4Y6McBjdLD/NbHB3/k2SVcjqkbaL8/48+
         LmbA==
X-Gm-Message-State: AOJu0YzhGICFA3QqBrZRUMM0jmnHDpv8t0c1A0b64Ma/5Fge3TTXXP4i
	L9WrOuSQmi8jPRZu0jbou5v84NT5oBpZsFloYH5sXsdodrVBCjTyJ2ECq4mb0VCscG49GEx//ij
	lRKexgoLhDB0Sftie0LtCjdUaRdGcYVWqLMUmGx4J9w==
X-Gm-Gg: ASbGncsWl+VP+lsQSchPxELGHo1VSb+V2warB4z6U7t0Y9kPIZ1EHE/r6BXE+nkoqWj
	O7NPeeeD2FhSbbQn36bQTkY1oSZx0F8PbtHsqINnAObKd3THD6l25knYw19iEHiWcYynU8kPTPT
	yzglpo5SNKI2DMz/uWHW73U1XAh/+Rgd0hrqOjZUQy
X-Google-Smtp-Source: AGHT+IErzX3qWIT3c1Qk1YGFeP2cdcTJQDk2QlkIreKgSk2921ua+MvlqcGby1PEuT5shey8DDLXrqwEphtluMw/pyw=
X-Received: by 2002:a05:6870:70a1:b0:2d4:ce45:6993 with SMTP id
 586e51a60fabf-2eaf08b7847mr12533156fac.30.1750336412919; Thu, 19 Jun 2025
 05:33:32 -0700 (PDT)
MIME-Version: 1.0
References: <20250618184631.15489-1-frediano.ziglio@cloud.com> 
In-Reply-To: 
From: Frediano Ziglio 
Date: Thu, 19 Jun 2025 13:33:20 +0100
X-Gm-Features: AX0GCFtz_Eh-mTsaf4U6f1-RoEIxDzkfz8yJUWJYg9UOC042JBtCodp0RW3oFzk
Message-ID: 
Subject: Re: [PATCH] xen/efi: Do not check kernel signature if it was embedded
To: =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= 
Cc: xen-devel@lists.xenproject.org, 
	"Daniel P. Smith" , Jan Beulich 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 19, 2025 at 1:17=E2=80=AFPM Marek Marczykowski-G=C3=B3recki
 wrote:
>
> On Wed, Jun 18, 2025 at 07:46:28PM +0100, Frediano Ziglio wrote:
> > Using UKI it's possible to embed Linux kernel into xen.efi file.
> > In this case the signature for Secure Boot is applied to the
> > whole xen.efi, including the kernel.
> > So checking for specific signature for the kernel is not
> > needed.
> > In case Secure Boot is not enabled there's no reason to check
> > kernel signature.
>
> The last sentence (here and in the comment below) seem to be unrelated
> to this change - it's more about shim lock protocol being available,
> which this patch doesn't change.
>

Should I just remove the sentence?
Beside that sentence, any issue with this change?

> > Signed-off-by: Frediano Ziglio 
> > ---
> >  xen/common/efi/boot.c | 10 ++++++++++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> > index e39fbc3529..7077af3f5d 100644
> > --- a/xen/common/efi/boot.c
> > +++ b/xen/common/efi/boot.c
> > @@ -1291,6 +1291,7 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE =
ImageHandle,
> >      bool base_video =3D false;
> >      const char *option_str;
> >      bool use_cfg_file;
> > +    bool kernel_was_verified =3D false;
> >      int dt_modules_found;
> >
> >      __set_bit(EFI_BOOT, &efi_flags);
> > @@ -1461,6 +1462,14 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE=
 ImageHandle,
> >              read_file(dir_handle, s2w(&name), &kernel, option_str);
> >              efi_bs->FreePool(name.w);
> >          }
> > +        else
> > +        {
> > +            /*
> > +             * As kernel was embedded it was either verified for Secur=
e Boot
> > +             * or Secure Boot is not enabled.
> > +             */
> > +            kernel_was_verified =3D true;
> > +        }
> >
> >          if ( !read_section(loaded_image, L"ramdisk", &ramdisk, NULL) )
> >          {
> > @@ -1534,6 +1543,7 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE =
ImageHandle,
> >       * verify it.
> >       */
> >      if ( kernel.ptr &&
> > +         !kernel_was_verified &&
> >           !EFI_ERROR(efi_bs->LocateProtocol(&shim_lock_guid, NULL,
> >                                             (void **)&shim_lock)) &&
> >           (status =3D shim_lock->Verify(kernel.ptr, kernel.size)) !=3D =
EFI_SUCCESS )
> > --
> > 2.43.0
> >
>
> --
> Best Regards,
> Marek Marczykowski-G=C3=B3recki
> Invisible Things Lab


From xen-devel-bounces@lists.xenproject.org Thu Jun 19 12:38:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 12:38:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020110.1396531 (Exim 4.92)
	(envelope-from )
	id 1uSEXN-0000VS-T7; Thu, 19 Jun 2025 12:38:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020110.1396531; Thu, 19 Jun 2025 12:38:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSEXN-0000VL-Pr; Thu, 19 Jun 2025 12:38:37 +0000
Received: by outflank-mailman (input) for mailman id 1020110;
 Thu, 19 Jun 2025 12:38: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 1uSEXM-0000VF-1b
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 12:38:36 +0000
Received: from fout-a7-smtp.messagingengine.com
 (fout-a7-smtp.messagingengine.com [103.168.172.150])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4f428b65-4d0a-11f0-b894-0df219b8e170;
 Thu, 19 Jun 2025 14:38:33 +0200 (CEST)
Received: from phl-compute-09.internal (phl-compute-09.phl.internal
 [10.202.2.49])
 by mailfout.phl.internal (Postfix) with ESMTP id DCBB0138063D;
 Thu, 19 Jun 2025 08:38:31 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-09.internal (MEProxy); Thu, 19 Jun 2025 08:38:31 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 19 Jun 2025 08:38:30 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4f428b65-4d0a-11f0-b894-0df219b8e170
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=1750336711;
	 x=1750423111; bh=i3dDU16VH1qm9YunVKeGTu3VLu9ufqqZNJtqnl6S8UE=; b=
	O0ZOEtl1Ivmo8TodqrL+2tzqnCsPtVexPaRmdGN7um4LbLt54etU/QovBINMdhfy
	JwuRXdd+ZqLKJ1BmRLYDu/vATOGXUu1qoQS6j/G7qMC979eHDh8hMsQ/ZUbosFms
	zDTl6pta+sBukJUOF1yJWak47TgkqANp21axKlhrTLPGu4WRyjsskuUevRFN6ZYw
	7WZK3WLSZCz8HrRGO1IcTYBsDzix0+qgXw43SitHkbyE2M+tWEtkLLpXuMqyTEfe
	BoZBxaSvonaYs8KcKkHmjSX6njKrcDtthZKafUoYj9wmOtHai5YRCeTG+hYRJF1g
	Ga6uL/0zMtPCD1dqYyppfA==
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=
	1750336711; x=1750423111; bh=i3dDU16VH1qm9YunVKeGTu3VLu9ufqqZNJt
	qnl6S8UE=; b=qCGuxXGcnht5xFxWXyUdq4XZFVMZfL7xYFh02Y+FvdoFThGFmBQ
	CXB9bXvv78IlGInhTSQhjtleCASf/KdCY3NPAUzkLiGN/rlBauKsuxDhxJf9BRAz
	Z22VXQyLMvrVvsUWabs55iqzLbnqCpSMxesq0jIxBnRchU2vQHnQ5oqR8M7uNVmD
	rMtZmFQCg9JYI4SWwGyWmcmXRR3e5OXYoCj8lf3JIqxkjHB6EzSws5eL4JH/CMOT
	nNE4i91ADfjXSrh92nQqE6ubBARY0iHKFVmG3b8vPdc+4/fIgdWiBr+/sjeflf/4
	+3YyHbX+ZIOMwVNCvMJov/p6Lyqplriklgg==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgdehheegucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceurghi
    lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh
    epfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcuofgr
    rhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvihhsih
    gslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfduleetfeev
    hfefheeiteeliefhjefhleduveetteekveettddvgeeuteefjedunecuvehluhhsthgvrh
    fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhv
    ihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepgedpmhhoug
    gvpehsmhhtphhouhhtpdhrtghpthhtohepfhhrvgguihgrnhhordiiihhglhhiohestghl
    ohhuugdrtghomhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnph
    hrohhjvggtthdrohhrghdprhgtphhtthhopeguphhsmhhithhhsegrphgvrhhtuhhsshho
    lhhuthhiohhnshdrtghomhdprhgtphhtthhopehjsggvuhhlihgthhesshhushgvrdgtoh
    hm
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Thu, 19 Jun 2025 14:38:28 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Frediano Ziglio 
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" ,
	Jan Beulich 
Subject: Re: [PATCH] xen/efi: Do not check kernel signature if it was embedded
Message-ID: 
References: <20250618184631.15489-1-frediano.ziglio@cloud.com>
 
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="lRmNHmQVmNrYtUO8"
Content-Disposition: inline
In-Reply-To: 


--lRmNHmQVmNrYtUO8
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 19 Jun 2025 14:38:28 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Frediano Ziglio 
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" ,
	Jan Beulich 
Subject: Re: [PATCH] xen/efi: Do not check kernel signature if it was embedded

On Thu, Jun 19, 2025 at 01:33:20PM +0100, Frediano Ziglio wrote:
> On Thu, Jun 19, 2025 at 1:17=E2=80=AFPM Marek Marczykowski-G=C3=B3recki
>  wrote:
> >
> > On Wed, Jun 18, 2025 at 07:46:28PM +0100, Frediano Ziglio wrote:
> > > Using UKI it's possible to embed Linux kernel into xen.efi file.
> > > In this case the signature for Secure Boot is applied to the
> > > whole xen.efi, including the kernel.
> > > So checking for specific signature for the kernel is not
> > > needed.
> > > In case Secure Boot is not enabled there's no reason to check
> > > kernel signature.
> >
> > The last sentence (here and in the comment below) seem to be unrelated
> > to this change - it's more about shim lock protocol being available,
> > which this patch doesn't change.
> >
>=20
> Should I just remove the sentence?

Yes, and reword the code comment a bit.

> Beside that sentence, any issue with this change?

Other than that it looks fine for me.

> > > Signed-off-by: Frediano Ziglio 
> > > ---
> > >  xen/common/efi/boot.c | 10 ++++++++++
> > >  1 file changed, 10 insertions(+)
> > >
> > > diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> > > index e39fbc3529..7077af3f5d 100644
> > > --- a/xen/common/efi/boot.c
> > > +++ b/xen/common/efi/boot.c
> > > @@ -1291,6 +1291,7 @@ void EFIAPI __init noreturn efi_start(EFI_HANDL=
E ImageHandle,
> > >      bool base_video =3D false;
> > >      const char *option_str;
> > >      bool use_cfg_file;
> > > +    bool kernel_was_verified =3D false;
> > >      int dt_modules_found;
> > >
> > >      __set_bit(EFI_BOOT, &efi_flags);
> > > @@ -1461,6 +1462,14 @@ void EFIAPI __init noreturn efi_start(EFI_HAND=
LE ImageHandle,
> > >              read_file(dir_handle, s2w(&name), &kernel, option_str);
> > >              efi_bs->FreePool(name.w);
> > >          }
> > > +        else
> > > +        {
> > > +            /*
> > > +             * As kernel was embedded it was either verified for Sec=
ure Boot
> > > +             * or Secure Boot is not enabled.
> > > +             */
> > > +            kernel_was_verified =3D true;
> > > +        }
> > >
> > >          if ( !read_section(loaded_image, L"ramdisk", &ramdisk, NULL)=
 )
> > >          {
> > > @@ -1534,6 +1543,7 @@ void EFIAPI __init noreturn efi_start(EFI_HANDL=
E ImageHandle,
> > >       * verify it.
> > >       */
> > >      if ( kernel.ptr &&
> > > +         !kernel_was_verified &&
> > >           !EFI_ERROR(efi_bs->LocateProtocol(&shim_lock_guid, NULL,
> > >                                             (void **)&shim_lock)) &&
> > >           (status =3D shim_lock->Verify(kernel.ptr, kernel.size)) !=
=3D EFI_SUCCESS )
> > > --
> > > 2.43.0
> > >
> >
> > --
> > Best Regards,
> > Marek Marczykowski-G=C3=B3recki
> > Invisible Things Lab

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

--lRmNHmQVmNrYtUO8
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmhUBMUACgkQ24/THMrX
1yyNGwf+O2tiuQ608dfnmha85GyWda/iwN227Opa3/QnWfUyyjAPPbgyrtvCVM1O
Ivk1AqrSj0vwUXHR4+AarWf31pcrsPoPHp5FwVbwDPKcO7tfBfAccBcY+8Px+kIN
wE/dyY1g817tAtvbRO+nCvgVqi93UwB6QW1k2EiRVgiDfjU/PxZFxTRpGCPm2vMw
Rehv11+NDKqO2dZPBEf5idPFNW8/2r6b13R3tQXeFSsBvCg83ITQPgYXd9fUQ5O9
s29VZzJV4WgD7+vNjrUN9w7/ZmU2+avbHeFtC2h+LZ4r8JX1tY+SQWhqqzRENo9F
DuFudQhNH4Aq5u9jbntagnENdD+p/w==
=c8jp
-----END PGP SIGNATURE-----

--lRmNHmQVmNrYtUO8--


From xen-devel-bounces@lists.xenproject.org Thu Jun 19 14:05:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 14:05:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020156.1396541 (Exim 4.92)
	(envelope-from )
	id 1uSFtg-00046z-0n; Thu, 19 Jun 2025 14:05:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020156.1396541; Thu, 19 Jun 2025 14: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 1uSFtf-00046s-U5; Thu, 19 Jun 2025 14:05:43 +0000
Received: by outflank-mailman (input) for mailman id 1020156;
 Thu, 19 Jun 2025 14:05: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 1uSFtf-00046m-3I
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 14:05:43 +0000
Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com
 [2607:f8b0:4864:20::329])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 78453b22-4d16-11f0-b894-0df219b8e170;
 Thu, 19 Jun 2025 16:05:35 +0200 (CEST)
Received: by mail-ot1-x329.google.com with SMTP id
 46e09a7af769-735b2699d5dso526557a34.0
 for ; Thu, 19 Jun 2025 07:05:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 78453b22-4d16-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750341934; x=1750946734; 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=0jpI+lBADGKSORsEOZSxUO6bJWTslJG2ZsdZncnEW8U=;
        b=fsSMt6EiQL8Qt/b7xmkkCd+yHKPYIoHXIhq3TjJWJ6gfmSAFcRQ1nkujcmRtlBnXjC
         HFddJLp+htKlFCcHLST0vtmPVrlygaLSxd6N7EDlkX1x3qqrfT3kIU5JBuwt4saH4uRo
         B8781/3H8ms+9DrPXQcsyNvMA/xGk56Xi/UBs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750341934; x=1750946734;
        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=0jpI+lBADGKSORsEOZSxUO6bJWTslJG2ZsdZncnEW8U=;
        b=qHYDUIn1W2sU5zG2DMmOt6879B1Gyw4nwN7vCG3+A2QwCA2S0WvAx71HPxKPckxKZC
         P9kYeB/HY8wIZFnilv/ulJUMdzhGoHwo4b9BEJ7TpXSjHZtQ9wBIoxCOrDpXfCzUfCLU
         i34sdeoqbDo0M7oH3DL5NqsdMx5T7zlT7xXQs3nbfjRuIAxGx2dRTcMabYcVUXhgUWiu
         Vdh6gofWibpmKjsd8fmJHFVxfP+NjJPuewH3lh+yaSuvNxiw+SXSsMb6GmXwhwwCbnIh
         bYVQO2qgJzmI+rdVwGv3ft8yP51e+4R/2U9fwKcCqnMG19/cFuqapB/E1DmYadt9RDMx
         ACGQ==
X-Forwarded-Encrypted: i=1; AJvYcCXfyPnXrndb+DC0QcfjWKtZXjxAlBOCq4liRj5TBykb+x0E73+gtTBUiRFMKOcZDOpwkVKbDAI5yQ0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyoXRSp/xu3wcJFSm7bPzAqwHm6TULayOEeqhxBdjxQSuEfM+m/
	vtsdpr8fPKja5kobKPzCVKbcAGnkemJY+4Gjt8ncea+RgmYedzCuVWccv0aIPNWhPZbv/epyhcW
	PXyGkTXqlSzITnOrG1sABFYv2DjpO/7jVT0ezduu3
X-Gm-Gg: ASbGnctF8/EhncGvlEDf9wlDbOiYILDjImyVtxIDxi/Y3g+AZBXgY7ot5JxXHDXNJJa
	cEt7tQVPcGor8CRyD+8kooi1q9/cXJNATlyZmv33czWpOtsfB7EQKpA8zeNZqmtOnyd/bToHQ+N
	v2KWD26qGxt70rR0Itxx4XydMD3k27tpQjOKu0uOepNw==
X-Google-Smtp-Source: AGHT+IF9DMx50fz5k856YqLJG2pQDkq+I75Pt4FQB6n7DN4pe70eUEwBKmgXiUuvDtesh7jb6qGNFWJ9lt7kKjlBNT8=
X-Received: by 2002:a05:6830:6c84:b0:73a:8a8a:5157 with SMTP id
 46e09a7af769-73a8a8a5a40mr733048a34.19.1750341934417; Thu, 19 Jun 2025
 07:05:34 -0700 (PDT)
MIME-Version: 1.0
References: <20250611235851.167385-1-andrew.cooper3@citrix.com>
 <5aad2d39-31e1-44c6-b167-a3275dc6b747@suse.com> 
In-Reply-To: 
From: Ross Lagerwall 
Date: Thu, 19 Jun 2025 15:05:21 +0100
X-Gm-Features: Ac12FXxUXIY_b9t-qw7RMZQgpeO47bNjQS7eaZkQX4XCmLE6Unl7VEIGAwg-kz0
Message-ID: 
Subject: Re: [PATCH] docs: UEFI Secure Boot security policy
To: Teddy Astie 
Cc: Jan Beulich , Andrew Cooper , 
	Anthony PERARD , Michal Orzel , 
	Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Stefano Stabellini , Juergen Gross , 
	=?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= , 
	Trammell Hudson , Frediano Ziglio , 
	Gerald Elder-Vass , Kevin Lampis , 
	Xen-devel , 
	Samuel Verschelde 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 12, 2025 at 1:21=E2=80=AFPM Teddy Astie  wrote:
>
> Le 12/06/2025 =C3=A0 12:08, Jan Beulich a =C3=A9crit :
> > On 12.06.2025 01:58, Andrew Cooper wrote:
> >> +
> >> +Lockdown Mode
> >> +^^^^^^^^^^^^^
> >> +
> >> +A mode which causes the enforcement of the properties necessary to co=
nform to
> >> +the Secure Boot specification.  Lockdown Mode is forced active when S=
ecure
> >> +Boot is active in the platform, but may be activated independently to=
o for
> >> +development purposes with the ``lockdown`` command line option.
> >> +
> >> +TODO
> >> +^^^^
> >> +
> >> + * Command Line
> >> + * Livepatching
> >> + * Kexec
> >> + * Userspace hypercalls
> >
> > What about Dom0 being able to access almost(?) all memory, including al=
l MMIO?
> > In this context, isn't iommu=3Ddom0-strict a requirement for SB (while =
that's
> > still not the default mode of operation for PV Dom0, despite me keeping=
 to
> > suggest that we ought to change that default)?
> >
>
> Unless I missed something, the kernel is not a part of the TCB in this
> Secure Boot model. But at some point, we definitely want to reduce the
> TCB to just Xen, and put a more limited trust on the control domains.
>
> Yet, the current plan of hardening the privcmd device is going to be
> very hard for sure.
>
> dom0-iommu=3Dstrict is a good mitigations in case untrusted parties of th=
e
> dom0 get direct access to a devices. However, as it is now, it implies a
> IOTLB flush for each grant mapping done, which severely impede PV
> performance (PV-IOMMU patches can help solving this performance problem
> though).
>

The dom0 kernel is part of the TCB since it controls the hardware (along
with Xen). This is covered by the paragrah starting "Privileged code
shall include Xen and the kernel(s) of the control and hardware
domain...".

Dom0 being able to access all memory including MMIO is fine as long as
it does not get exposed to userspace. In general, the existing Linux
kernel lockdown mode would cover this by blocking /dev/mem, access to
resources in sysfs, etc.

Ross


From xen-devel-bounces@lists.xenproject.org Thu Jun 19 14:17:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 14:17:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020162.1396550 (Exim 4.92)
	(envelope-from )
	id 1uSG4h-0005oc-Of; Thu, 19 Jun 2025 14:17:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020162.1396550; Thu, 19 Jun 2025 14:17:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSG4h-0005oV-M7; Thu, 19 Jun 2025 14:17:07 +0000
Received: by outflank-mailman (input) for mailman id 1020162;
 Thu, 19 Jun 2025 14:17: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 1uSG4g-0005oP-MM
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 14:17:06 +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 12d8c8df-4d18-11f0-b894-0df219b8e170;
 Thu, 19 Jun 2025 16:17:04 +0200 (CEST)
Received: by mail-oa1-x34.google.com with SMTP id
 586e51a60fabf-2e8f7ca7ca3so427860fac.2
 for ; Thu, 19 Jun 2025 07:17:04 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 12d8c8df-4d18-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750342623; x=1750947423; 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=3/VE80N0vYRpCgRaxRRg8M65kU0kSzEc2wthrdvj03c=;
        b=XEsMsQQ+3A7mkkQL3VjEYMeKryleGJ827GJ4jkG2KBrPhP/pIe0CL1KMTuqHdOldrT
         W7vcMFlMHoraDjwvdOoIvbNYUiy/oFeeKHXwy6tSokfoaoio67hJjqt6tb5ujEqMZg10
         NsZQh/ixFxcGzN7Mb0sjob1pf/JUAsbsB7sd8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750342623; x=1750947423;
        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=3/VE80N0vYRpCgRaxRRg8M65kU0kSzEc2wthrdvj03c=;
        b=rE1+Ii2FYz9MuqeZPYSWQeVuhaONe+V+soquAy0vtWmle1Ww2jXpCySofCJ/ql2ouh
         Rm7u+U0u7Kv3Ee+wMEkQlvQQTmErOUM3I/ZlUr866VeogPAOtJr9KMrba8YQx41n0zE0
         yHh8XVMuSgdtlTQ/XDVv9x9huMcsqiypB6X5aLsXtEYP5mX8UId7HoTkSUUmwONSshgQ
         f4rx5daCnGYFByRIpLm1XHYg9rXVIsYP7SjuUFwK0on3bA9kqHlOFkbxuPiAZoVZVlmd
         fvVCkWz3Yo5C+pWONultgE8bfwl02Hv0zyMu6mkpQmwmpgDMtjgKcHAB2XXh86i1rbjs
         XKwA==
X-Gm-Message-State: AOJu0YzgH/zP9mzZFHOz6VOEHXHRXhNNH8teyLy1tIooAIWlDJXAQ2du
	V/LqzjVYxxm/CNqppKNBVI9T5DItCeD78simMPRcXnXjYDFbqjg0rtBnHWOipaYks7jlRjpsWm/
	gHR3V5Gx23zZiGxSemMthGFUBkrj7HzukR8VJARAN
X-Gm-Gg: ASbGncv6kMxZVQ4EGjYALKml9iEg7DI7N/digIwiDJAm6NrjiWozK/KxwAQK/OpLVoQ
	BMjoEi9ydiMVeiYC36i1aK0cSkrhtw6iRYhTHuwlh5zzgYmukiIDZjB0miJztkdRB7cjxpRQ+Np
	NKbYTCt9K/akJk3sgNqBEPhR+mhWCh0Bm9NzMkigxYYw==
X-Google-Smtp-Source: AGHT+IGEMIlhEL6YQ2HmbALMvwV+xF3VBtajHqs4aHx30iNYN2NxUqfJ3xc6pmaY2/GWe+hiYncuVehIQT6gLVgV73Y=
X-Received: by 2002:a05:6871:647:b0:2c2:3ae9:5b9c with SMTP id
 586e51a60fabf-2eaf0464484mr13633766fac.2.1750342623223; Thu, 19 Jun 2025
 07:17:03 -0700 (PDT)
MIME-Version: 1.0
References: <20250611235851.167385-1-andrew.cooper3@citrix.com>
In-Reply-To: <20250611235851.167385-1-andrew.cooper3@citrix.com>
From: Ross Lagerwall 
Date: Thu, 19 Jun 2025 15:16:51 +0100
X-Gm-Features: Ac12FXyC8RqGw1phw9QTkSiE_GXduLqoofXH228KFzNtjkuJJa9EBZ__-Y6rvxM
Message-ID: 
Subject: Re: [PATCH] docs: UEFI Secure Boot security policy
To: Andrew Cooper 
Cc: Xen-devel , 
	Anthony PERARD , Michal Orzel , 
	Jan Beulich , Julien Grall , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Stefano Stabellini , security@xen.org, Juergen Gross , 
	=?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= , 
	Trammell Hudson , Frediano Ziglio , 
	Gerald Elder-Vass , Kevin Lampis 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 12, 2025 at 12:58=E2=80=AFAM Andrew Cooper
 wrote:
...
> +In Progress
> +-----------
> +
> +.. warning::
> +
> +   The following work is still in progress.  It is provisional, and not
> +   security supported yet.
> +
> +
> +Secure Boot Advanced Targeting
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +SBAT is a recovation scheme for Secure Boot enabled components, using a
> +generation based scheme.  See `Shim SBAT.md
> +`_ for full details.
> +
> +Upstream Xen provides the infrastructure to embed SBAT metadata in
> +``xen.efi``, but does not maintain a generation number itself.  Downstre=
ams
> +are expected to maintain their own generation numbers.
> +
> +
> +Lockdown Mode
> +^^^^^^^^^^^^^
> +
> +A mode which causes the enforcement of the properties necessary to confo=
rm to
> +the Secure Boot specification.  Lockdown Mode is forced active when Secu=
re
> +Boot is active in the platform, but may be activated independently too f=
or
> +development purposes with the ``lockdown`` command line option.
> +
> +TODO
> +^^^^
> +
> + * Command Line

These two are also in progress since they have had patch series posted:

> + * Livepatching
> + * Kexec

I think a section on PCI passthrough is also warranted. i.e. preventing mis=
use
of a device to exploit Secure Boot.

Ross


From xen-devel-bounces@lists.xenproject.org Thu Jun 19 14:24:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 14:24:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020174.1396561 (Exim 4.92)
	(envelope-from )
	id 1uSGBb-0007Un-Fs; Thu, 19 Jun 2025 14:24:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020174.1396561; Thu, 19 Jun 2025 14:24:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSGBb-0007Ug-C4; Thu, 19 Jun 2025 14:24:15 +0000
Received: by outflank-mailman (input) for mailman id 1020174;
 Thu, 19 Jun 2025 14:24: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 1uSGBa-0007Tk-Qq
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 14:24:14 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on20609.outbound.protection.outlook.com
 [2a01:111:f403:2407::609])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 126bb876-4d19-11f0-a30c-13f23c93f187;
 Thu, 19 Jun 2025 16:24:13 +0200 (CEST)
Received: from BN9PR03CA0788.namprd03.prod.outlook.com (2603:10b6:408:13f::13)
 by DS0PR12MB7608.namprd12.prod.outlook.com (2603:10b6:8:13b::11) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.30; Thu, 19 Jun
 2025 14:24:10 +0000
Received: from BN2PEPF0000449D.namprd02.prod.outlook.com
 (2603:10b6:408:13f:cafe::9b) by BN9PR03CA0788.outlook.office365.com
 (2603:10b6:408:13f::13) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8857.25 via Frontend Transport; Thu,
 19 Jun 2025 14:24:10 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN2PEPF0000449D.mail.protection.outlook.com (10.167.243.148) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8857.21 via Frontend Transport; Thu, 19 Jun 2025 14:24:10 +0000
Received: from localhost (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, 19 Jun
 2025 09:24:08 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 126bb876-4d19-11f0-a30c-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ZNF5nE/6TlbzHFuNmVvYLQH9IINrl6q8TSdCqE3Pjd5/j6PQltX3hAW8AT6cXhlZT9b9TvijgzwMfGlE4Gk1NDM5qtf8CoondaRh/YB3kkmefOgWjm5yJ4fwT97dqVGz2sfHc2G/UaHvUux83LdIrd/CfRHXWEDxfEdBb7/jRnk6jK+C/flAX0O+u3Di+nsO48l1w68VeMWYwLtywIN1MMu4/AC41Kjn/5jQA+tAcdhID4+IXhA5Nn5s+G9qpCYeEi1NSswAVSYdGN3/Yj8HKboiSAFNplaHeneH+KIALQeOvr8d2A+TGndWKU71O/YFRU/nOAPpbrFn1vNzJuSnrA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=uA57m571N628YCDf9fZF/OW+xl73AR9BKRui4ypZ3h0=;
 b=vHjeZoh2a6v8RI+pFt9t1ovdpeLKlBq6vi1ulfyuPeW7UVAkbBZWZNx4HxrjUMP688yuVIQZ8rrrsI2DKDL6Z/WTByWFiEByxA6jvPcyowEw4ONDnJCyTiAe5PB/Eec5258bjdgo/o3sNV9uTXAlnnf2qTc+uaJxoslrFXUFQ+7LybN2kibLdtINOqUhOftyKcosbYwyoyk0nZqjKI3dMdnY4hLCjfKYmpe7JtYwOeUSxnEDDMtUzYCOZxNVEBYSsXYpcmLxbR/Y01fcyrxdCVWjk9G2TK3JjA3VPSRUfv4wwYtXqwYmPmvCNalnr15JwZ3EOyEYNTSJ5Zpy1B5yCw==
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=uA57m571N628YCDf9fZF/OW+xl73AR9BKRui4ypZ3h0=;
 b=3nwlobvgGCu2zu+z/l30GDZEuXV8KVPEzLTWPWamL/8iBQxwGaBSfd44ZLHi7oIJ0V6ynswxAdvYRvBeYd0IAo9pwZ2wfbkIDnYNpWET4XFFkasy9R0lDO4Yz+89dbYoSth2o4Cfn5nNbPYHlpzng1hcqlimVIr15HgTHwE8Oi8=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 19 Jun 2025 16:24:07 +0200
Message-ID: 
CC: , Julien Grall , "Bertrand
 Marquis" , Michal Orzel ,
	"Daniel P. Smith" 
Subject: Re: [PATCH v3 08/14] xen/dt: Move bootfdt functions to
 xen/bootfdt.h
From: Alejandro Vallejo 
To: Stefano Stabellini 
X-Mailer: aerc 0.20.1
References: <20250613151612.754222-1-agarciav@amd.com>
 <20250613151612.754222-9-agarciav@amd.com>
 
In-Reply-To: 
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: BN2PEPF0000449D:EE_|DS0PR12MB7608:EE_
X-MS-Office365-Filtering-Correlation-Id: 39eef873-76b8-4a76-6a8c-08ddaf3cf527
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?eEtjVzdwRGVsaFBhcDdQUHZUWTd3RCtRTHNxL0V6bEZKeE1hNjJpbXRzQzBV?=
 =?utf-8?B?OFhxQ2x0WWFrc1FvOXRxN01ZVVJqNzV5UldHa3h4Ny9wWVpjRVBLYXEyYlR6?=
 =?utf-8?B?SGNHcTRWc2VKWXZwMi9jTEtoK0FZN0taQlpRSytwV0laWDRJdkJJQ0pmdnBD?=
 =?utf-8?B?KzdKTGlKS2tZcE5YOTVtTkZMWUFDaFVRQzg2VVYxZXphNmtIZWlqYmpZbUZN?=
 =?utf-8?B?YUlxbWJhQk1hOGxqOTRoT3FUZUtJanNHYWlaclpTdmhIcHlXallveHprU2NT?=
 =?utf-8?B?U2hyV2d5TXdqcGZXWm5mMlY0TDZFVytnMGxZZ1ZJK1UvMWp4Vzc0TUVuSExj?=
 =?utf-8?B?Szl3OWMyeGZkUW5EMU0vb3dWaThHK0I2Sm56cDFNNUdVWWYveUFYZS9NRmlw?=
 =?utf-8?B?UmFuVS9DazBRaktZZnRHek4xUU1ncWxBYXF5VENlOHE1bnIvSzBuUmJWMnFs?=
 =?utf-8?B?N0h6YXBiOCtEK1hHZWRqblVVYUhOamhmMmJDRE9ZOHBxb1FnRHBoRno1cmZt?=
 =?utf-8?B?Q25BMVU1OUgzOVVCeldTVkNmTHVHNTZwbXdrV2llTXdHVW1CdTR3WVFTVEZF?=
 =?utf-8?B?RGdDZkVQTmltcmZqYTRtVjdDbFl0dTNuTUFBSGNjelhqWGl3M1NlOEJuSkZh?=
 =?utf-8?B?YXVjRlJFMm1USG1xTm1LYmtFNTU2Lyt0d2REZUhsTTUwZU5mTTVQTk9iOHdU?=
 =?utf-8?B?cW9KNmYxZm9zbjhydzlUYWVvSUhkaCsvN2lxbm9mV0NzaitzWE5MaWhkanpD?=
 =?utf-8?B?UG5QYWltTS92aCtocG4wWTA5TU5obk9ja3pvbVdWaldjNHFvbEtFeWJDMlkr?=
 =?utf-8?B?eVJKcVp1b1pkUWY1aS9paXRRMi9GVlF5WFdhQ2VIUHRSWGx6Ujk0ZXpoZ3ph?=
 =?utf-8?B?cW9KZnYzOWtJSDRPK1FoT05jU1ZhejJESC9xV0Q0YVZmczBUakw2d2toRTlR?=
 =?utf-8?B?ZGhBbXE0SmdQZWl2Wmw0L2c2V3IyNE9hZUdGaWhBQTQvcEt4eXZkMWlKMUl0?=
 =?utf-8?B?blN2b29BTDV0SkJsMU1FQ3VnVWJ5TE9obkMrKytDc0NTQUNsdEZRZ1RITGxT?=
 =?utf-8?B?TUpPek0xVDhCTzR4ZWNzQlp5OTczOEZqaGg4N1p4Y3BEaUkrdUQybzZJQjFz?=
 =?utf-8?B?clJ6MXpUcGk5UDVqWjUvZHRwNERvVHU0VnNFY2wrdDMzYjl2NWRNbnIwOVVN?=
 =?utf-8?B?eU1qcGRCT0ZlN1R0MzNvRmtSaXlwOFQ3RGNkR0lWTjNWZnlTS3ZFWVNnc041?=
 =?utf-8?B?SVdJakljaEkxZXk0V2wxamtiTkowQ01MNHNMQWNKWjhacmZFWE5uZmI1WDc1?=
 =?utf-8?B?c3VRdWhpK081NGRNcGxjUTd0ZTAwS3MzVFhiYjFYTVBwSGxmT0RLc09uQWVG?=
 =?utf-8?B?NjEwS2VqNUpjNWhjTzJWcjFHekFiZ090VXJrR3NPWjI1emJGNm1QRFByMzQ5?=
 =?utf-8?B?NWVxbGRFNmdYU2RteUhIVEI1SkJVQUpFR0dXNHE0Zk9TTjlLZElIb1JzYjNt?=
 =?utf-8?B?M1hpV0E3NGJEanhKMGtHZXdZMTlLRlpYY1VwTm80QnZ5Sy9WZXVxdXAzQzgv?=
 =?utf-8?B?bHhHSVU3Vy9IMFhRSDhWUnRXRlBVVEtObWZ6UHZkK2RPN3cyNmRyTUlnT2or?=
 =?utf-8?B?Y09YWUpnc3ZMRkVRUWNwWUlpZzhMeWRxenJ1RTl3RWk1c01NN21nYlBnWmlG?=
 =?utf-8?B?NWNXNjVGQjhFeUM0TjUrd1V6ajE4UDRVMU1IVVh5Y05rV0VoRDcvSlFUUDBx?=
 =?utf-8?B?Sk1qc0RtS05oejJtbTliSWtwNXJhdDJSQWtQRWNSaHNNcE5YcEhiNjFQZGkv?=
 =?utf-8?B?dHQwbnJFRjVnUzI3VlNwSXk0dCtLQWZYdmFHWWtuNmNES1NwUU1OdzlkbEUy?=
 =?utf-8?B?ZVJUSndzaUNSWDVVRDl3dmc0WVlhME5Ma09vNm1Pc2RGN3dteWg4ZDk3b3dK?=
 =?utf-8?B?K2U4ekZpQzlJV1VZcnZqSSt6b3lqNnNPNjRlMHRUbkRmeXBXUmRoVDB4TG9W?=
 =?utf-8?B?VU4wRW9GR21DMUR6dExLMVMrQkQwLzRWV2s4TXluZ1g1b2xVc3FnTHd3NThp?=
 =?utf-8?Q?QUiEFp?=
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)(82310400026)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jun 2025 14:24:10.1951
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 39eef873-76b8-4a76-6a8c-08ddaf3cf527
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:
	BN2PEPF0000449D.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB7608

Hi,

On Sat Jun 14, 2025 at 3:16 AM CEST, Stefano Stabellini wrote:
> On Fri, 13 Jun 2025, Alejandro Vallejo wrote:
>> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree=
.h
>> index 75017e4266..0a22b1ba1d 100644
>> --- a/xen/include/xen/device_tree.h
>> +++ b/xen/include/xen/device_tree.h
>> @@ -10,6 +10,7 @@
>>  #ifndef __XEN_DEVICE_TREE_H__
>>  #define __XEN_DEVICE_TREE_H__
>> =20
>> +#include 
>>  #include 
>
> This should not be needed?

dt_read_number() is still needed in dt_read_paddr() in device_tree.h

I can move that helper too (makes sense, as it's strictly a wrapper) and
add includes in whatever .c files require it (tentatively it looks like onl=
y
static-evtchn.c. Then that include can be dropped.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Thu Jun 19 14:36:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 14:36:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020182.1396571 (Exim 4.92)
	(envelope-from )
	id 1uSGNn-0000s7-Hw; Thu, 19 Jun 2025 14:36:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020182.1396571; Thu, 19 Jun 2025 14:36:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSGNn-0000s0-E8; Thu, 19 Jun 2025 14:36:51 +0000
Received: by outflank-mailman (input) for mailman id 1020182;
 Thu, 19 Jun 2025 14:36: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 1uSGNl-0000rt-Tz
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 14:36:50 +0000
Received: from fout-a1-smtp.messagingengine.com
 (fout-a1-smtp.messagingengine.com [103.168.172.144])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d354e484-4d1a-11f0-a30c-13f23c93f187;
 Thu, 19 Jun 2025 16:36:46 +0200 (CEST)
Received: from phl-compute-05.internal (phl-compute-05.phl.internal
 [10.202.2.45])
 by mailfout.phl.internal (Postfix) with ESMTP id 418E01380628;
 Thu, 19 Jun 2025 10:36:45 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-05.internal (MEProxy); Thu, 19 Jun 2025 10:36:45 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 19 Jun 2025 10:36:41 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d354e484-4d1a-11f0-a30c-13f23c93f187
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=1750343805;
	 x=1750430205; bh=k4gc9Vfj9Tzpn+1TC/f+oKYAqWwRav+WpCaPjYpmFhM=; b=
	dsrDCnuAh7E8B5RAGlWxmv6+2EFTSXkYRoMMQo/+8feHXzHY5A8wHEU+ppeQ6f3/
	pWMMR9K2GQAawZBOA+MJweZ7QqPDHRSeA3XqO8+Tkei5iyhnh2mNoM+KI9mCSebE
	6e1OmykDuSfE32M2wg4jXxTOZ+G9SH9ZiT/HRtrJPKXAFAAnNjqxMx/cD8K2Moge
	1OhQUaVxkqIXmQ5yTMQsHzN2u0IDrB2OoNY1kDbB9KvjyFcW1T6q7nWOtZ7JjemD
	Tw35YCNnBMfAo3v1kiXBZe4J6c2Zf8lEhXYKpCgI+wHc//uTKwXkYCsPf6SjqVXL
	qKcXzwrfPzPf1H5DQs6h0g==
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=
	1750343805; x=1750430205; bh=k4gc9Vfj9Tzpn+1TC/f+oKYAqWwRav+WpCa
	PjYpmFhM=; b=d4VE4quk4WF1EBuKJBCsjETBkp8M4Cc7B2POqPboARt/YZLsuwr
	3fVIXalvwzQx4IUq0maCvvP3YdcITS2URhqWNpNQhINuS94Km7OgG2hgtU+F7i7K
	Kk7x3gAPuSlIMizVC4UV973NMU1qcRJi+AwvdoMh9T+urQZaLMTmu7jHTo3hl2g5
	SI1Gj6mjbXM090MlbvTbt/NWgLOUExN6v9kLVibvErO1lERmzUayzAgeN5jI19sj
	SNHejkHDGkv8Q3Udf1LeKTagBJt38/W0B0RK6M64ulO6I15Z6Zixrdes6RJWCL0u
	ooDZAPaVqPHzQkByDioK/AWnNju2acBiIZw==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgdehjeekucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceurghi
    lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh
    epfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcuofgr
    rhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvihhsih
    gslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfduleetfeev
    hfefheeiteeliefhjefhleduveetteekveettddvgeeuteefjedunecuvehluhhsthgvrh
    fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhv
    ihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepudehpdhmoh
    guvgepshhmthhpohhuthdprhgtphhtthhopehrohhsshdrlhgrghgvrhifrghllhestghl
    ohhuugdrtghomhdprhgtphhtthhopegrnhgurhgvfidrtghoohhpvghrfeestghithhrih
    igrdgtohhmpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhho
    jhgvtghtrdhorhhgpdhrtghpthhtoheprghnthhhohhnhidrphgvrhgrrhgusehvrghtvg
    hsrdhtvggthhdprhgtphhtthhopehmihgthhgrlhdrohhriigvlhesrghmugdrtghomhdp
    rhgtphhtthhopehjsggvuhhlihgthhesshhushgvrdgtohhmpdhrtghpthhtohepjhhulh
    hivghnseigvghnrdhorhhgpdhrtghpthhtoheprhhoghgvrhdrphgruhestghithhrihig
    rdgtohhmpdhrtghpthhtohepshhsthgrsggvlhhlihhniheskhgvrhhnvghlrdhorhhg
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Thu, 19 Jun 2025 16:36:39 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Ross Lagerwall 
Cc: Andrew Cooper ,
	Xen-devel ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Stefano Stabellini , security@xen.org,
	Juergen Gross , Trammell Hudson ,
	Frediano Ziglio ,
	Gerald Elder-Vass ,
	Kevin Lampis 
Subject: Re: [PATCH] docs: UEFI Secure Boot security policy
Message-ID: 
References: <20250611235851.167385-1-andrew.cooper3@citrix.com>
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="Z34HVkQTE1rMju7v"
Content-Disposition: inline
In-Reply-To: 


--Z34HVkQTE1rMju7v
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 19 Jun 2025 16:36:39 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Ross Lagerwall 
Cc: Andrew Cooper ,
	Xen-devel ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Stefano Stabellini , security@xen.org,
	Juergen Gross , Trammell Hudson ,
	Frediano Ziglio ,
	Gerald Elder-Vass ,
	Kevin Lampis 
Subject: Re: [PATCH] docs: UEFI Secure Boot security policy

On Thu, Jun 19, 2025 at 03:16:51PM +0100, Ross Lagerwall wrote:
> I think a section on PCI passthrough is also warranted. i.e. preventing m=
isuse
> of a device to exploit Secure Boot.

While I agree it makes sense, I wonder if it's in scope for UEFI
Secure Boot as defined by Microsoft? It may have implication for example
on PCI passthrough to a PV domains.

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

--Z34HVkQTE1rMju7v
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmhUIHcACgkQ24/THMrX
1yxBsggAl8f+YFmRk2e182AuP5LXtPSkMTv5tY6zV3FHNpNg5+4jsLhe5z1FjsE8
Cd8SC1GvHz+rCclKEFgqZ4+rN9nvkifr0B1aIET60skWiwPyKcEon/i62MpU8sgz
rp7gHffaANwTXxdwL6kopUnAxmyormW++jtq3qY2Mav0WJDOK3QcqIEU63d4qgM/
DcxarNCrcZzyIBIJH2mUfNZNb1VShmqbDRheTGHP4dtv7JnhKgm6HiHsc5V8GN6s
TMhIy0XgGdfFwRrpVQ5IHPk9YFuBz8gfBZz9rk9wrXBqpgWL3VKMT0MRF6gbFGJy
q0rfr2uh5hG+WaJ4MlY02YoxP9oNSw==
=0S5N
-----END PGP SIGNATURE-----

--Z34HVkQTE1rMju7v--


From xen-devel-bounces@lists.xenproject.org Thu Jun 19 16:15:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 16:15:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020227.1396601 (Exim 4.92)
	(envelope-from )
	id 1uSHv8-0006JC-3F; Thu, 19 Jun 2025 16:15:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020227.1396601; Thu, 19 Jun 2025 16:15: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 1uSHv8-0006J1-09; Thu, 19 Jun 2025 16:15:22 +0000
Received: by outflank-mailman (input) for mailman id 1020227;
 Thu, 19 Jun 2025 16:15: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 1uSHv6-0005oY-UE
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 16:15:21 +0000
Received: from AS8PR03CU001.outbound.protection.outlook.com
 (mail-westeuropeazlp170120005.outbound.protection.outlook.com
 [2a01:111:f403:c201::5])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9838584b-4d28-11f0-a30d-13f23c93f187;
 Thu, 19 Jun 2025 18:15:19 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by DB8PR03MB6332.eurprd03.prod.outlook.com (2603:10a6:10:13d::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.19; Thu, 19 Jun
 2025 16:15:17 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%4]) with mapi id 15.20.8835.023; Thu, 19 Jun 2025
 16:15: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: 9838584b-4d28-11f0-a30d-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=hJcrTbvG5o86t29qqUey1u6Dmey5Ru39Gpkjy0FFgsy/2ejFVy/ylsR+9Aj5mnaCo7Ejf4z/p8VYK38ikAOeVEhgJWXnSqCr/ACG9fJ11n0etYVzj20OdglVjExpNEDsh79r0WeLAGFIbcyioClIL6cPD0m8iEbdvC8woM3ZDf3t8q3gh1aeYvx49X7uy/vst+zrBhvyS+NVGUYS7XQeue6PIfTPtgFf89QPzPQOSvx6TjyAyukuLp9emtBrYNqQJYog76geTDoeRvZgAfFeB62Y8SVeuNdHv3mGhumPK6TT3GU4QtThbUJp8mLA27F5sG+BqWW+nJbdS7nutcpZUA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=soWgaQ0ooZX8YxfHuhShptK+TgLRKcailPF6TieLFls=;
 b=Ew9Mc94dvFY4vi9hXJxgj8rD+u+I0Ndlhv+yy4gfscZ9afj1Njby9nYCNSxFxEw2ty1+9ClLjtAtIDIzln7najltXimG98cFL0aY8tU0hX3wbHCmfSfwSUvIIrngnglg30MWvW+8ulp/3/LnAZhWKrJnsH/Ugx+GgpxzpiuEHa+vFuAmZ67kRemtUUqHNVpoh65zT7NkkbjRZowlFU4zD9Mp19wLPDQxJhg2DAW7ugO4EYj2efEB8eLZlw4iby1HpbHyrGUK4SPjvtmYLCIrEPj4QVtcH1qSCQAqEwlkQ2iExcuDYLvMZih9CwL0dQrCuTraTHYM3esdjDAoBk3s6A==
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=soWgaQ0ooZX8YxfHuhShptK+TgLRKcailPF6TieLFls=;
 b=iHrfzIkjTPont4ybkhRVG366nW/JHbk+UrTiwLTY++i/8DfZcWUuFA8aXkv4BU5ywznmrmAo0BOyfLj9hyb+Fyiq+KL0NFLfbewaTyVh7JTMRLhfXeAPG4BzQdHpBKwnfD4qGxPQtm7os8r+Vmrxan7ReatM8wbN76SEZcWSi62ECTtRGo7O1ECG4OHdJUwV2zlmmu6OtmWC6DN0/K1CJFDzQEUUPo8/3LxBdDP9jcOWromflM6dh1I2kCTPHh5NDOtW/cJgMCxNUQleMMJbt6CYeRq/JBex4X7NWxOLcsh++MlVzZawqsByG+FN2Qo+wFrBEXA9LVAcdRj+MsanLQ==
From: Oleksii Moisieiev 
To: Stefano Stabellini , Grygorii Strashko
	
CC: Bertrand Marquis ,
	"xen-devel@lists.xenproject.org" , Andrew
 Cooper , Anthony PERARD
	, Jan Beulich , Juergen Gross
	, Julien Grall , Michal Orzel
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Volodymyr Babchuk 
Subject: Re: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC
 multi-agent driver
Thread-Topic: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC
 multi-agent driver
Thread-Index: AQHbyNXPHUV4T01ZEEC9Uxm0LaLKHbPgqpIAgA7gjoCAEAkWgIAInBwAgAKos4A=
Date: Thu, 19 Jun 2025 16:15:17 +0000
Message-ID: <7a52e95e-f091-4294-ba72-d92eb8a2cc02@epam.com>
References: 
 <318044ae12f13b6b297b3f5fda577a1a6cd143da.1747669845.git.oleksii_moisieiev@epam.com>
 
 <04B1F737-5E6B-47C0-B2B9-74288C68E68A@arm.com>
 <50ff5d2b-bd17-4833-b497-0dda6f75964a@epam.com>
 
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: PAVPR03MB8946:EE_|DB8PR03MB6332:EE_
x-ms-office365-filtering-correlation-id: 89ee5cbd-d466-4824-6bae-08ddaf4c7b59
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|376014|366016|7416014|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?SjNpRVVuVWRpalcyL3ZTSjBMMWRNTU5zUWtJWGliSE0vUVVxdEtXTFBiRU5F?=
 =?utf-8?B?UzdaSjMxWDRpOVZhWVBJUi85elJZY0RYSTFTR1l2MmRIbXhIUFNYZWpFdHpE?=
 =?utf-8?B?eVJuTDAzK1l6UnF6dnJ6RE56eEJzVmxnK1FmVEJ6NWdjdjNJNzYrQmZlQUMr?=
 =?utf-8?B?NDgzbURCZGlUVC9HRTJic09FUWJNK0VUUWdCT1E4MHVLaFZ4TmdsaDQxOEtt?=
 =?utf-8?B?U0xKWGRmRUsvTmhmN1d3cndtV0ZyMW4yTTVjUE9yc0JzZ242cnBEazArYytp?=
 =?utf-8?B?U1kzSFkvU2hXSzNhcEk0S3lKMWhkTkNwMmNub0VMTlFoYTJrV0FiY2FoOEph?=
 =?utf-8?B?SldNVlRUc0ozcU1YN0E2N01ZZUhQZEN5OEpZaE9WMVE0Yjc4bmJHWndBTUZq?=
 =?utf-8?B?c3U1dEZUbmZCRUhoM0xOc21GOHBtVWpRYXhtZkdURUFVbjZmcURlWEIrN1cw?=
 =?utf-8?B?cENsRnNlMDBURVZybHBLNGNnV2RPRGRYUUpoZ3dsU3A1NDFxa050KzNYRlJI?=
 =?utf-8?B?T2JIais1K3l2bkx4Q3Y0bHJVcW9JdW5DY0d3c1BEeTVYeG9TOXcwZUQvelEr?=
 =?utf-8?B?NUUySTlJQ1dVQmpOaVdEWmdVNVN5UzQvb09TbTNnNnFaRy84eUZYTGo5MTBn?=
 =?utf-8?B?N3pGVjljNVpWdngvZ3hwTE5EWFpBSGkvRzlqTHdqd2ZIdFJsL1ZReVpFZC93?=
 =?utf-8?B?UFRETnRPOEoydVJQdWRJNWxXdUc3S3ZSZklLaVc4cnU3ZEVlZVVZajUrWmxN?=
 =?utf-8?B?YW0rb0tzbFRzdGRCVlZGVncvVDNyempDU3p3VytnVFhGMHlIb3VsWHJaUU1P?=
 =?utf-8?B?UGdEZjFkLzBLQlc3S0hyMWRSa3ZjYWdMcHZ4ZmtSRGU2V0RqWEVzR0FHdkRy?=
 =?utf-8?B?V3pHREIyVlV2OVplZXU3NGtxSFFpZHduczcvOXJSRXdUWXl6akhJYkhxSVgz?=
 =?utf-8?B?eDU4SktjRnpaNzdiUzc4K1Exa0ZnTm51MG0vNXc2ZFMveDU4dGlvdi83ZXp6?=
 =?utf-8?B?V0Z0OUh3ci9JNUFnZCs3SEJhQTlIR0RlbWtpVUFpc2gxMWdHWUF1OTNTV0N5?=
 =?utf-8?B?N28xcWNDSU02ZnZnOEliZFBLWnZEU2FIRTQ0MzdDVTZjN0kyOS82NXlqckJv?=
 =?utf-8?B?YnlSbUJwTjU0bGNBcUpiUHUwWmE1RElSNXFqaWJRenpJY3RwekdxWXhJZkQv?=
 =?utf-8?B?eEtHbGdkQlVuUTVQOFEzb1pQQXNjODlhTVVRdlU5dlZ1dmZqN0YwdGV2NjMw?=
 =?utf-8?B?T0kzY0lsV29BNTVjUHFCMGtPQlkyMWwrMUFRaytyWkw4dUNKaW1yY3YwRFlu?=
 =?utf-8?B?aEtXa01Hb2J3a0xaOTUxVmpvb2tzcGc5RlpSTm1kQWNHQ3RkWDd4Um0zMEpu?=
 =?utf-8?B?Sm1GalVkZnplNkVwbXpFaE9panpoek54RUhiaHM4aFUxemVWNzlnVGVJK0xU?=
 =?utf-8?B?bnBOdlQraWtFOUhSTTFUQml6cWttTlRWdys2bEdrUkdoMkluNFhJRzN5OFVh?=
 =?utf-8?B?N09TbUZBV2o0TjMvME9lanB1QUhidUtYWjlvNDZZSmJQSE9xTU9EYklCc0g3?=
 =?utf-8?B?RnhZVHRMOHY2UC9EWnR2V2g2ZVhhOWNSY0NVZnc3ZEFJbzlGRFR2bWxSV0hW?=
 =?utf-8?B?VWF6OXdXanZPYWo4L1FRVUQ5dXpISmZBYTlKOFhJczRsMFBtWlY4aXordXJh?=
 =?utf-8?B?cTVDQ3hZZlpLQkRpem1kajFoVWZDL2xJZkIyeER0bWNOUDc2Q1pKRldxSnJ3?=
 =?utf-8?B?dlBJSTUyMURXRW5oV1BZM0ZwWk1KZ1R5bGsyMGVIZkdaYWxnQkxac2g0QkND?=
 =?utf-8?B?L24xeldOejJpM0VSWnYwZzFvOStNaEI4cE0xWHFycEU1MCs5dHZvRHVKYlcw?=
 =?utf-8?B?VkZXbFZQcFIycnZucEtTZzZnRkpOeU83UGh0Q1JyVGU1WG1aaGkyejNubklP?=
 =?utf-8?B?NE9MSGcwMU5HV29MNzczYmtZYjNON0w1SHYzM2o4b0YwSVlwcWFzaU1NWVJy?=
 =?utf-8?B?MVpqREk1RHJ3PT0=?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7416014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?eDdGcVd5ZDN2Wi8wbW5veTdGVHJtaXZNT1dmMDhJUTlpR04xUlZTRk9aNkVP?=
 =?utf-8?B?dUdvcjB6S013aW5MMmszeHZYNjBCekJTWjNPSUNYcTZXTEk3YzVhd2k5NTdx?=
 =?utf-8?B?N3FkMEsyREdnWlduanZaOEh0bWRDMyt4cm8rTTdlUzJGUG1wN2xtUUpMOE5s?=
 =?utf-8?B?dzNWR3VVYnd6TlVCSGRRUFVDak50TGZnTUFHSUJDTGV0V1JnSXJnTTAxNWpk?=
 =?utf-8?B?Q0FzZzU4TldRdmFwR013ZFJwdVp4RzFjUHJjS0FrUnlmb1dvbHB5NkZXODRz?=
 =?utf-8?B?cEFWVkpzS0todkJQL25ORFVzNTY5VTkrNytPYmxydVEyQ2lxTHhnTGl0VGN2?=
 =?utf-8?B?MTlNZmExc1VocUxLSzJ1RCs0RVRlY2k4TEl3WmE2V2NWZXc1OVdMY253dDZp?=
 =?utf-8?B?RHl3MjRyY1NlTWxqTnREWVVSV2NrVUt3N1MvVkQ4U2dGWXlHRnlSc25VRnZi?=
 =?utf-8?B?eW5rd1B5WVVpci9CWTJhVlVNYy9rVE5yUHdTNEJlSC9TZUx4cjV4blhFSmk2?=
 =?utf-8?B?TmtSN0JON215TWlpRENhdmo3Z0I3RWVIdFZTU3VBRlR4OFl1T3I1cnFXby9W?=
 =?utf-8?B?enU4TUZ4czBHRkd2eFNrY1BvUmNDZFF5OHh4djZ2emlxTld2WG5Nek1STnlC?=
 =?utf-8?B?akhBS3JzalVLSExsUExGQ1pFU2N3d0s2WWdzd2h1eTVUazdGUjk2dFhPRGhG?=
 =?utf-8?B?SEcvTW1UZGZmT1BWeHFndThpb0JqT1ZaVkdsQy80WHduaDJGd2N4ME5HMzgr?=
 =?utf-8?B?L2E2VGhOWTU2MEwyd0ZsTlFTWC9PTk00UkZWS2FoK0l5U3ovNHNDcVU1TkRL?=
 =?utf-8?B?NDRjdDZ3RjFLM3JvVHk2WitTbXUwNDhEeW1ySmlWdjBOVzluYzdqRk5CSis3?=
 =?utf-8?B?ejFYc3JOcEE0bTJXVlg4aURYUURtUXNGTXlSWjFmcENJbDV1YnJtL2NMdkhI?=
 =?utf-8?B?azU5dnNoZ0dLNE9sU3MxV3BBT2VteTdhc29pUDdMMEMydjgrMk1DWGtDeUY4?=
 =?utf-8?B?dG9wWkdsR0NxOWJZOGVFNmc0T0UrZitpWXFtTnd1UGE0WjJhZ21lOVBIQzY3?=
 =?utf-8?B?bUFTMWpLVkJFVmNOWDRqQXlOazRYSEZyVGh2SDVRSnFlQTYwQXdibWtyaktG?=
 =?utf-8?B?MW5kZThzOHBUeTdIcHlabjdYUzF2N1NlcG1ZZVB5VUZyVEtNRWFuSGhlVStM?=
 =?utf-8?B?VmRqekJpYTlXWVFmdjdJZnZDTjZIeGxSY1AvdmNCS0c4RzVYTzl5QzEyNENT?=
 =?utf-8?B?S2hpb010S2crcm9iTHRuckN2MS9pUlRoeWdZVWlwVTlTcVNZYUhMaVVGN3lO?=
 =?utf-8?B?b1cwVVRKa3FoWmNTVzU5RUlaRWgyanpBSWRSUlJjRDRteDFIYVliOUhjUDIy?=
 =?utf-8?B?bVBzNGllaEt4dDVORHZKdC83VUlKTmxTRU5NcGNIc1RzTHludk1YQzlUSTkx?=
 =?utf-8?B?OU1pNXNFaVhNdUhQQ1BKSEJvMDRpRkErcTVBVEFoQ3p4YmNXUDZtcGt4R09i?=
 =?utf-8?B?RklDOTQ2VjFkT2xMbmg4aTdWVE5tdFBKdkJ0MWFUK1RPVG0xY0NpTmFadVVM?=
 =?utf-8?B?alVSWExIRDk3TGRNYkhQTnR3MWJINVF6UVZqUTZEQzFLM09pUUpOUHBLNmdh?=
 =?utf-8?B?NFk0MUoxZDJzbDZOVXIzQzR5TGtiTk40aUN2RHhHWnlUNGxrdkovOUd2cEVQ?=
 =?utf-8?B?Qm14blVBRzd2ZTE2VjlUemptYkExNHBFL3lFY2N5d2RKZW5XNkdyNWliak93?=
 =?utf-8?B?bm0vb1BYdUdEMnZjN091U3FrNmY1UjR4cUlKOHVNZ0tLbkUxdEpqK01sOVhT?=
 =?utf-8?B?cy9MVmhrZUl1L09WTjQ4VENpRWYxZXdmZDBiSnQra1pIeDdZejI0emFXcDlB?=
 =?utf-8?B?OUJhS21rdUk4RytQbkt0TWQvNHhXRllBRUo3WFk3UlhMcndLZE5sOHJVUVJw?=
 =?utf-8?B?cmxxYWcvWmkxdENqTk9QQ3FLaStDRjBjYTZZR0NTaEMzSTRzUTdOSDhPeFhp?=
 =?utf-8?B?eUppaWkxV2xwZklFTnpJRXNkZloydC9pQmcwa2xjNEdaUCt6Zm5OMUF0enAy?=
 =?utf-8?B?UGVpNVZzdkNPNDIweHVXa2J0VlFCV3B1VU9uRmpqN1k2YlFvdGJDS2dVWVJH?=
 =?utf-8?B?WXoxV2lCM2JBbWhucWlqYXZ1SExQUVFrelVuSkl5SDVpeHhSRWROODJrR3N1?=
 =?utf-8?B?ZEE9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <4CD99DDF422B474D87947127F2CFC6ED@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: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 89ee5cbd-d466-4824-6bae-08ddaf4c7b59
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2025 16:15:17.7998
 (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: Rlo+rk1aIAU4sjkNjZhAnwhXU81M/Vtu7YgzSgiNLGP3/51R/5ua0I0pV0++FZoFVvOBEDumaei4tstLESQ9CHqJ1QlGLvGBoxsqlkmmJGA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR03MB6332

DQpPbiAxOC8wNi8yMDI1IDAyOjM4LCBTdGVmYW5vIFN0YWJlbGxpbmkgd3JvdGU6DQo+IE9uIFRo
dSwgMTIgSnVuIDIwMjUsIEdyeWdvcmlpIFN0cmFzaGtvIHdyb3RlOg0KPj4gT24gMDIuMDYuMjUg
MTA6MTcsIEJlcnRyYW5kIE1hcnF1aXMgd3JvdGU6DQo+Pj4gSGkgU3RlZmFubyBhbmQgT2xla3Np
aSwNCj4+Pg0KPj4+PiBPbiAyMyBNYXkgMjAyNSwgYXQgMjI6MDYsIFN0ZWZhbm8gU3RhYmVsbGlu
aTxzc3RhYmVsbGluaUBrZXJuZWwub3JnPg0KPj4+PiB3cm90ZToNCj4+Pj4NCj4+Pj4gT25lIHF1
ZXN0aW9uIGZvciBCZXJ0cmFuZCBiZWxvdw0KPj4+Pg0KPj4+Pg0KPj4+PiBPbiBNb24sIDE5IE1h
eSAyMDI1LCBPbGVrc2lpIE1vaXNpZWlldiB3cm90ZToNCj4+Pj4+IFRoaXMgcGF0Y2ggaW50cm9k
dWNlcyBTQ0kgZHJpdmVyIHRvIHN1cHBvcnQgZm9yIEFSTSBFTDMgVHJ1c3RlZA0KPj4+Pj4gRmly
bXdhcmUtQQ0KPj4+Pj4gKFRGLUEpIHdoaWNoIHByb3ZpZGVzIFNDTUkgaW50ZXJmYWNlIHdpdGgg
bXVsdGktYWduZXQgc3VwcG9ydCwgYXMgc2hvd24NCj4+Pj4+IGJlbG93Lg0KPj4+Pj4NCj4+Pj4+
ICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4+Pj4+ICAg
IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4+Pj4+ICAgIHwg
RUwzIFRGLUEgU0NNSSAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4+Pj4+ICAgICstLS0t
LS0tKy0tKy0tLS0tLS0rLS0rLS0tLS0tLSstLSstLS0tLS0tKysNCj4+Pj4+ICAgIHxzaG1lbTAg
fCAgfHNobWVtMSB8ICB8c2htZW0yIHwgIHxzaG1lbVggfA0KPj4+Pj4gICAgKy0tLS0tKy0rICAr
LS0tKy0tLSsgICstLSstLS0tKyAgKy0tLSstLS0rDQo+Pj4+PiBzbWMtaWQwIHwgICAgICAgIHwg
ICAgICAgICB8ICAgICAgICAgICB8DQo+Pj4+PiBhZ2VudDAgIHwgICAgICAgIHwgICAgICAgICB8
ICAgICAgICAgICB8DQo+Pj4+PiAgICArLS0tLS12LS0tLS0tLS0rLS0tLS0tLS0tKy0tLS0tLS0t
LS0tKy0tLS0rDQo+Pj4+PiAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgfCAgICAgICAgICAg
fCAgICB8DQo+Pj4+PiAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgfCAgICAgICAgICAgfCAg
ICB8DQo+Pj4+PiAgICArLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0r
DQo+Pj4+PiAgICAgICAgICAgc21jLWlkMSB8ICBzbWMtaWQyfCAgICBzbWMtaWRYfA0KPj4+Pj4g
ICAgICAgICAgIGFnZW50MSAgfCAgYWdlbnQyIHwgICAgYWdlbnRYIHwNCj4+Pj4+ICAgICAgICAg
ICAgICAgICAgIHwgICAgICAgICB8ICAgICAgICAgICB8DQo+Pj4+PiAgICAgICAgICAgICAgKy0t
LS12LS0tKyAgKy0tdi0tLS0tKyAgKy0tdi0tLS0tKw0KPj4+Pj4gICAgICAgICAgICAgIHwgICAg
ICAgIHwgIHwgICAgICAgIHwgIHwgICAgICAgIHwNCj4+Pj4+ICAgICAgICAgICAgICB8IERvbTAg
ICB8ICB8IERvbTEgICB8ICB8IERvbVggICB8DQo+Pj4+PiAgICAgICAgICAgICAgfCAgICAgICAg
fCAgfCAgICAgICAgfCAgfCAgICAgICAgfA0KPj4+Pj4gICAgICAgICAgICAgIHwgICAgICAgIHwg
IHwgICAgICAgIHwgIHwgICAgICAgIHwNCj4+Pj4+ICAgICAgICAgICAgICArLS0tLS0tLS0rICAr
LS0tLS0tLS0rICArLS0tLS0tLS0rDQo+Pj4+Pg0KPj4+Pj4gVGhlIEVMMyBTQ01JIG11bHRpLWFn
ZW50IGZpcm13YXJlIGV4cGVjdGVkIHRvIHByb3ZpZGUgU0NNSSBTTUMvSFZDDQo+Pj4+PiBzaGFy
ZWQNCj4+Pj4+IG1lbW9yeSB0cmFuc3BvcnQgZm9yIGV2ZXJ5IEFnZW50IGluIHRoZSBzeXN0ZW0u
DQo+Pj4+Pg0KPj4+Pj4gVGhlIFNDTUkgQWdlbnQgdHJhbnNwb3J0IGNoYW5uZWwgZGVmaW5lZCBi
eSBwYWlyOg0KPj4+Pj4gLSBzbWMtaWQ6IFNNQy9IVkMgaWQgdXNlZCBmb3IgRG9vcmJlbGwNCj4+
Pj4+IC0gc2htZW06IHNoYXJlZCBtZW1vcnkgZm9yIG1lc3NhZ2VzIHRyYW5zZmVyLCBYZW4gcGFn
ZSBhbGlnbmVkLA0KPj4+Pj4gcDJtX21taW9fZGlyZWN0X25jLg0KPj4+Pj4NCj4+Pj4+IFRoZSBm
b2xsd29pbmcgU0NNSSBBZ2VudHMgZXhwZWN0ZWQgdG8gYmUgZGVmaW5lZCBieSBTQ01JIEZXIHRv
IGVuYWJsZQ0KPj4+Pj4gU0NNSQ0KPj4+Pj4gbXVsdGktYWdlbnQgZnVuY3Rpb25hbGl0eSB1bmRl
ciBYZW46DQo+Pj4+PiAtIFhlbiBtYW5lZ2VtZW50IGFnZW50OiB0cnVzdGVkIGFnZW50cyB0aGF0
IGFjY2Vzc2VzIHRvIHRoZSBCYXNlDQo+Pj4+PiBQcm90b2NvbA0KPj4+Pj4gY29tbWFuZHMgdG8g
Y29uZmlndXJlIGFnZW50IHNwZWNpZmljIHBlcm1pc3Npb25zDQo+Pj4+PiAtIE9TUE0gVk0gYWdl
bnRzOiBub24tdHJ1c3RlZCBhZ2VudCwgb25lIGZvciBlYWNoIEd1ZXN0IGRvbWFpbiB3aGljaCBp
cw0KPj4+Pj4gICAgYWxsb3dlZCBkaXJlY3QgSFcgYWNjZXNzLiBBdCBsZWFzdCBvbmUgT1NQTSBW
TSBhZ2VudCBoYXMgdG8gYmUNCj4+Pj4+IHByb3ZpZGVkDQo+Pj4+PiAgICBieSBGVyBpZiBIVyBp
cyBoYW5kbGVkIG9ubHkgYnkgRG9tMCBvciBEcml2ZXIgRG9tYWluLg0KPj4+Pj4NCj4+Pj4+IFRo
ZSBFTDMgU0NNSSBGVyBleHBlY3RlZCB0byBpbXBsZW1lbnQgZm9sbG93aW5nIEJhc2UgcHJvdG9j
b2wgbWVzc2FnZXM6DQo+Pj4+PiAtIEJBU0VfRElTQ09WRVJfQUdFTlQNCj4+Pj4+IC0gQkFTRV9S
RVNFVF9BR0VOVF9DT05GSUdVUkFUSU9OIChvcHRpb25hbCkNCj4+Pj4+IC0gQkFTRV9TRVRfREVW
SUNFX1BFUk1JU1NJT05TIChvcHRpb25hbCkNCj4+Pj4+DQo+Pj4+PiBUaGUgU0NJIFNDTUkgU01D
IG11bHRpLWFnZW50IGRyaXZlciBpbXBsZW1lbnRzIGZvbGxvd2luZyBmdW5jdGlvbmFsaXR5Og0K
Pj4+Pj4gLSBJdCdzIGluaXRpYWxpemVkIGJhc2VkIG9uIHRoZSBIb3N0IERUIFNDTUkgbm9kZSAo
b25seSBvbmUgU0NNSQ0KPj4+Pj4gaW50ZXJmYWNlDQo+Pj4+PiBpcyBzdXBwb3J0ZWQpIHdoaWNo
IGRlc2NyaWJlcyBYZW4gbWFuYWdlbWVudCBhZ2VudCBTQ01JIGludGVyZmFjZS4NCj4+Pj4+DQo+
Pj4+PiBzY21pX3NobV8wIDogc3JhbUA0N2ZmMDAwMCB7DQo+Pj4+PiAgICAgIGNvbXBhdGlibGUg
PSAiYXJtLHNjbWktc2htZW0iOw0KPj4+Pj4gICAgICByZWcgPSA8MHgwIDB4NDdmZjAwMDAgMHgw
IDB4MTAwMD47DQo+Pj4+PiB9Ow0KPj4+Pj4gZmlybXdhcmUgew0KPj4+Pj4gICAgICBzY21pOiBz
Y21pIHsNCj4+Pj4+ICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc21jIjsNCj4+Pj4+
ICAgICAgICAgIGFybSwgc21jIC0gaWQgPSA8MHg4MjAwMDAwMj47IC8vIFhlbiBtYW5lZ2VtZW50
IGFnZW50IHNtYy1pZA0KPj4+PiBzb21lIGV4dHJhIHNwYWNlcywgaXQgbWlnaHQgYmUgYSBjb3B5
L3Bhc3RlIGVycm9yDQo+Pj4+DQo+Pj4+DQo+Pj4+PiAgICAgICAgICBcI2FkZHJlc3MtY2VsbHMg
PSA8IDE+Ow0KPj4+Pj4gICAgICAgICAgXCNzaXplLWNlbGxzID0gPCAwPjsNCj4+Pj4+ICAgICAg
ICAgIFwjYWNjZXNzLWNvbnRyb2xsZXIgLSBjZWxscyA9IDwgMT47DQo+Pj4+PiAgICAgICAgICBz
aG1lbSA9IDwmc2NtaV9zaG1fMD47IC8vIFhlbiBtYW5lZ2VtZW50IGFnZW50IHNobWVtDQo+Pj4+
Pg0KPj4+Pj4gICAgICAgICAgcHJvdG9jb2xAWHsNCj4+Pj4+ICAgICAgICAgIH07DQo+Pj4+PiAg
ICAgIH07DQo+Pj4+PiB9Ow0KPj4+Pj4NCj4+Pj4+IC0gSXQgb2J0YWlucyBYZW4gc3BlY2lmaWMg
U0NNSSBBZ2VudCdzIGNvbmZpZ3VyYXRpb24gZnJvbSB0aGUgSG9zdCBEVCwNCj4+Pj4+IHByb2Jl
cyBBZ2VudHMgYW5kIGJ1aWxkIFNDTUkgQWdlbnRzIGxpc3Q7IFRoZSBBZ2VudHMgY29uZmlndXJh
dGlvbiBpcw0KPj4+Pj4gdGFrZW4gZnJvbToNCj4+Pj4+DQo+Pj4+PiBjaG9zZW4gew0KPj4+Pj4g
ICAgeGVuLHNjbWktc2Vjb25kYXJ5LWFnZW50cyA9IDwNCj4+Pj4+IDEgMHg4MjAwMDAwMyAmc2Nt
aV9zaG1fMQ0KPj4+Pj4gMiAweDgyMDAwMDA0ICZzY21pX3NobV8yDQo+Pj4+PiAzIDB4ODIwMDAw
MDUgJnNjbWlfc2htXzMNCj4+Pj4+IDQgMHg4MjAwMDAwNiAmc2NtaV9zaG1fND47DQo+Pj4+PiB9
DQo+Pj4+Pg0KPj4+Pj4gL3sNCj4+Pj4+IHNjbWlfc2htXzE6IHNyYW1ANDdmZjEwMDAgew0KPj4+
Pj4gY29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zaG1lbSI7DQo+Pj4+PiByZWcgPSA8MHgwIDB4NDdm
ZjEwMDAgMHgwIDB4MTAwMD47DQo+Pj4+PiB9Ow0KPj4+Pj4gc2NtaV9zaG1fMjogc3JhbUA0N2Zm
MjAwMCB7DQo+Pj4+PiBjb21wYXRpYmxlID0gImFybSxzY21pLXNobWVtIjsNCj4+Pj4+IHJlZyA9
IDwweDAgMHg0N2ZmMjAwMCAweDAgMHgxMDAwPjsNCj4+Pj4+IH07DQo+Pj4+PiBzY21pX3NobV8z
OiBzcmFtQDQ3ZmYzMDAwIHsNCj4+Pj4+IGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0K
Pj4+Pj4gcmVnID0gPDB4MCAweDQ3ZmYzMDAwIDB4MCAweDEwMDA+Ow0KPj4+Pj4gfTsNCj4+Pj4+
IH0NCj4+Pj4+ICAgIHdoZXJlIGZpcnN0IGl0ZW0gaXMgImFnZW50X2lkIiwgc2Vjb25kIC0gImFy
bSxzbWMtaWQiLCBhbmQgdGhpcmQgLQ0KPj4+Pj4gImFybSxzY21pLXNobWVtIiBmb3INCj4+Pj4+
ICAgIHRoaXMgYWdlbnRfaWQuDQo+Pj4+Pg0KPj4+Pj4gICAgTm90ZSB0aGF0IFhlbiBpcyB0aGUg
b25seSBvbmUgZW50cnkgaW4gdGhlIHN5c3RlbSB3aGljaCBuZWVkIHRvIGtub3cNCj4+Pj4+ICAg
IGFib3V0IFNDTUkgbXVsdGktYWdlbnQgc3VwcG9ydC4NCj4+Pj4+DQo+Pj4+PiAtIEl0IGltcGxl
bWVudHMgdGhlIFNDSSBzdWJzeXN0ZW0gaW50ZXJmYWNlIHJlcXVpcmVkIGZvciBjb25maWd1cmlu
ZyBhbmQNCj4+Pj4+IGVuYWJsaW5nIFNDTUkgZnVuY3Rpb25hbGl0eSBmb3IgRG9tMC9od2RvbSBh
bmQgR3Vlc3QgZG9tYWlucy4gVG8gZW5hYmxlDQo+Pj4+PiBTQ01JIGZ1bmN0aW9uYWxpdHkgZm9y
IGRvbWFpbiBpdCBoYXMgdG8gYmUgY29uZmlndXJlZCB3aXRoIHVuaXF1ZQ0KPj4+Pj4gc3VwcG9y
dGVkDQo+Pj4+PiBTQ01JIEFnZW50X2lkIGFuZCB1c2UgY29ycmVzcG9uZGluZyBTQ01JIFNNQy9I
VkMgc2hhcmVkIG1lbW9yeSB0cmFuc3BvcnQNCj4+Pj4+IFtzbWMtaWQsIHNobWVtXSBkZWZpbmVk
IGZvciB0aGlzIFNDTUkgQWdlbnRfaWQuDQo+Pj4+PiAtIE9uY2UgWGVuIGRvbWFpbiBpcyBjb25m
aWd1cmVkIGl0IGNhbiBjb21tdW5pY2F0ZSB3aXRoIEVMMyBTQ01JIEZXOg0KPj4+Pj4gICAgLS0g
emVyby1jb3B5LCB0aGUgZ3Vlc3QgZG9tYWluIHB1dHMgU0NNSSBtZXNzYWdlIGluIHNobWVtOw0K
Pj4+Pj4gICAgLS0gdGhlIGd1ZXN0IHRyaWdnZXJzIFNNQy9IVkMgZXhjZXB0aW9uIHdpdGggc21j
LWlkIChkb29yYmVsbCk7DQo+Pj4+PiAgICAtLSB0aGUgWGVuIGRyaXZlciBjYXRjaGVzIGV4Y2Vw
dGlvbiwgZG8gY2hlY2tzIGFuZCBzeW5jaHJvbm91c2x5DQo+Pj4+PiBmb3J3YXJkcw0KPj4+Pj4g
ICAgaXQgdG8gRUwzIEZXLg0KPj4+Pj4gLSB0aGUgWGVuIGRyaXZlciBzZW5kcyBCQVNFX1JFU0VU
X0FHRU5UX0NPTkZJR1VSQVRJT04gbWVzc2FnZSB0byBYZW4NCj4+Pj4+ICAgIG1hbmFnZW1lbnQg
YWdlbnQgY2hhbm5lbCBvbiBkb21haW4gZGVzdHJveSBldmVudC4gVGhpcyBhbGxvd3MgdG8gcmVz
ZXQNCj4+Pj4+ICAgIHJlc291cmNlcyB1c2VkIGJ5IGRvbWFpbiBhbmQgc28gaW1wbGVtZW50IHVz
ZS1jYXNlIGxpa2UgZG9tYWluIHJlYm9vdC4NCj4+Pj4+DQo+Pj4+PiBEb20wIEVuYWJsZSBTQ01J
IFNNQzoNCj4+Pj4+IC0gcGFzcyBkb20wX3NjbWlfYWdlbnRfaWQ9PGFnZW50X2lkPiBpbiBYZW4g
Y29tbWFuZCBsaW5lLiBpZiBub3QNCj4+Pj4+IHByb3ZpZGVkDQo+Pj4+PiAgICAgU0NNSSB3aWxs
IGJlIGRpc2FibGVkIGZvciBEb20wIGFuZCBhbGwgU0NNSSBub2RlcyByZW1vdmVkIGZyb20gRG9t
MA0KPj4+Pj4gRFQuDQo+Pj4+PiAgICAgVGhlIGRyaXZlciB1cGRhdGVzIERvbTAgRFQgU0NNSSBu
b2RlICJhcm0sc21jLWlkIiB2YWx1ZSBhbmQgZml4IHVwDQo+Pj4+PiBzaG1lbQ0KPj4+Pj4gICAg
IG5vZGUgYWNjb3JkaW5nIHRvIGFzc2lnbmVkIGFnZW50X2lkLg0KPj4+Pj4NCj4+Pj4+IEd1ZXN0
IGRvbWFpbnMgZW5hYmxlIFNDTUkgU01DOg0KPj4+Pj4gLSB4bC5jZmc6IGFkZCBjb25maWd1cmF0
aW9uIG9wdGlvbiBhcyBiZWxvdw0KPj4+Pj4NCj4+Pj4+ICAgICBhcm1fc2NpID0gInR5cGU9c2Nt
aV9zbWNfbXVsdGlhZ2VudCxhZ2VudF9pZD0yIg0KPj4+Pj4NCj4+Pj4+IC0geGwuY2ZnOiBlbmFi
bGUgYWNjZXNzIHRvIHRoZSAiYXJtLHNjbWktc2htZW0iIHdoaWNoIHNob3VsZCBjb3JyZXNwb25k
DQo+Pj4+PiBhc3NpZ25lZCBhZ2VudF9pZCBmb3INCj4+Pj4+ICAgICB0aGUgZG9tYWluLCBmb3Ig
ZXhhbXBsZToNCj4+Pj4+DQo+Pj4+PiBpb21lbSA9IFsNCj4+Pj4+ICAgICAgIjQ3ZmYyLDFAMjIw
MDEiLA0KPj4+Pj4gXQ0KPj4+PiBMb29raW5nIGF0IHRoZSBjb2RlIGFuZCB0aGUgY29uZmlndXJh
dGlvbiBvcHRpb25zLCBpdCBsb29rcyBsaWtlIGl0IGlzDQo+Pj4+IHBvc3NpYmxlIHRvIG1hcCBh
IHNjbWktc2htZW0gY2hhbm5lbCBhdCBhIGRpZmZlcmVudCBhZGRyZXNzIGZvciB0aGUNCj4+Pj4g
Z3Vlc3QuIEl0IHNlZW1zIGxpa2UgaXQgd291bGQgd29yay4gSXMgdGhhdCBjb3JyZWN0Pw0KPj4+
Pg0KPj4+Pg0KPj4+Pj4gLSBEVDogYWRkIFNDTUkgbm9kZXMgdG8gdGhlIERyaXZlciBkb21haW4g
cGFydGlhbCBkZXZpY2UgdHJlZSBhcyBpbiB0aGUNCj4+Pj4+IGJlbG93IGV4YW1wbGUuIFRoZSAi
YXJtLHNtYy1pZCIgc2hvdWxkIGNvcnJlc3BvbmQgYXNzaWduZWQgYWdlbnRfaWQgZm9yDQo+Pj4+
PiB0aGUgZG9tYWluOg0KPj4+Pj4NCj4+Pj4+IHBhc3N0aHJvdWdoIHsNCj4+Pj4+ICAgICBzY21p
X3NobV8wOiBzcmFtQDIyMDAxMDAwIHsNCj4+Pj4+ICAgICAgICAgY29tcGF0aWJsZSA9ICJhcm0s
c2NtaS1zaG1lbSI7DQo+Pj4+PiAgICAgICAgIHJlZyA9IDwweDAgMHgyMjAwMTAwMCAweDAgMHgx
MDAwPjsNCj4+Pj4+ICAgICB9Ow0KPj4+Pj4NCj4+Pj4+ICAgICBmaXJtd2FyZSB7DQo+Pj4+PiAg
ICAgICAgICBjb21wYXRpYmxlID0gInNpbXBsZS1idXMiOw0KPj4+Pj4gICAgICAgICAgICAgIHNj
bWk6IHNjbWkgew0KPj4+Pj4gICAgICAgICAgICAgICAgICBjb21wYXRpYmxlID0gImFybSxzY21p
LXNtYyI7DQo+Pj4+PiAgICAgICAgICAgICAgICAgIGFybSxzbWMtaWQgPSA8MHg4MjAwMDAwND47
DQo+Pj4+PiAgICAgICAgICAgICAgICAgIHNobWVtID0gPCZzY21pX3NobV8wPjsNCj4+Pj4+ICAg
ICAgICAgICAgICAgICAgLi4uDQo+Pj4+PiAgICAgICAgICAgICAgfQ0KPj4+Pj4gICAgICB9DQo+
Pj4+PiB9DQo+Pj4+Pg0KPj4+Pj4gU0NNSSAiNC4yLjEuMSBEZXZpY2Ugc3BlY2lmaWMgYWNjZXNz
IGNvbnRyb2wiDQo+Pj4+Pg0KPj4+Pj4gVGhlIFhFTiBTQ0kgU0NNSSBTTUMgbXVsdGktYWdlbnQg
ZHJpdmVyIHBlcmZvcm1zICJhY2Nlc3MtY29udHJvbGxlciINCj4+Pj4+IHByb3ZpZGVyIGZ1bmN0
aW9uDQo+Pj4+PiBpbiBjYXNlIEVMMyBTQ01JIEZXIGltcGxlbWVudHMgU0NNSSAiNC4yLjEuMSBE
ZXZpY2Ugc3BlY2lmaWMgYWNjZXNzDQo+Pj4+PiBjb250cm9sIiBhbmQgcHJvdmlkZXMgdGhlDQo+
Pj4+PiBCQVNFX1NFVF9ERVZJQ0VfUEVSTUlTU0lPTlMgY29tbWFuZCB0byBjb25maWd1cmUgdGhl
IGRldmljZXMgdGhhdCBhbg0KPj4+Pj4gYWdlbnRzIGhhdmUgYWNjZXNzIHRvLg0KPj4+Pj4gVGhl
IERUIFNDTUkgbm9kZSBzaG91bGQgIiNhY2Nlc3MtY29udHJvbGxlci1jZWxscz08MT4iIHByb3Bl
cnR5IGFuZCBEVA0KPj4+Pj4gZGV2aWNlcyBzaG91bGQgYmUgYm91bmQNCj4+Pj4+IHRvIHRoZSBY
ZW4gU0NNSS4NCj4+Pj4+DQo+Pj4+PiAmaTJjMSB7DQo+Pj4+PiBhY2Nlc3MtY29udHJvbGxlcnMg
PSA8JnNjbWkgMD47DQo+Pj4+PiB9Ow0KPj4+Pj4NCj4+Pj4+IFRoZSBEb20wIGFuZCBkb20wbGVz
cyBkb21haW5zIERUIGRldmljZXMgd2lsbCBiZSBwcm9jZXNzZWQgYXV0b21hdGljYWxseQ0KPj4+
Pj4gdGhyb3VnaA0KPj4+Pj4gc2NpX2Fzc2lnbl9kdF9kZXZpY2UoKSBjYWxsLCBidXQgdG8gYXNz
aWduIFNDTUkgZGV2aWNlcyBmcm9tIHRvb2xzdGFjaw0KPj4+Pj4gdGhlIHhsLmNmZzoiZHRkZXYi
IHByb3BlcnR5DQo+Pj4+PiBzaGVsbCBiZSB1c2VkOg0KPj4+Pj4NCj4+Pj4+IGR0ZGV2ID0gWw0K
Pj4+Pj4gICAgICAiL3NvYy9pMmNAZTY1MDgwMDAiLA0KPj4+Pj4gXQ0KPj4+Pj4NCj4+Pj4+IHhs
LmNmZzpkdGRldiB3aWxsIGNvbnRhaW4gYWxsIG5vZGVzIHdoaWNoIGFyZSB1bmRlciBTQ01JIG1h
bmFnZW1lbnQgKG5vdA0KPj4+Pj4gb25seSB0aG9zZSB3aGljaCBhcmUgYmVoaW5kIElPTU1VKS4N
Cj4+Pj4+DQo+Pj4+PiBbMV0NCj4+Pj4+IGh0dHBzOi8vd2ViLmdpdC5rZXJuZWwub3JnL3B1Yi9z
Y20vbGludXgva2VybmVsL2dpdC90b3J2YWxkcy9saW51eC5naXQvdHJlZS9Eb2N1bWVudGF0aW9u
L2RldmljZXRyZWUvYmluZGluZ3MvZmlybXdhcmUvYXJtLHNjbWkueWFtbA0KPj4+Pj4gWzJdDQo+
Pj4+PiBodHRwczovL3dlYi5naXQua2VybmVsLm9yZy9wdWIvc2NtL2xpbnV4L2tlcm5lbC9naXQv
dG9ydmFsZHMvbGludXguZ2l0L3RyZWUvRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdz
L2FjY2Vzcy1jb250cm9sbGVycy9hY2Nlc3MtY29udHJvbGxlcnMueWFtbA0KPj4+Pj4gU2lnbmVk
LW9mZi1ieTogT2xla3NpaSBNb2lzaWVpZXY8b2xla3NpaV9tb2lzaWVpZXZAZXBhbS5jb20+DQo+
Pj4+PiBTaWduZWQtb2ZmLWJ5OiBHcnlnb3JpaSBTdHJhc2hrbzxncnlnb3JpaV9zdHJhc2hrb0Bl
cGFtLmNvbT4NCj4+Pj4gVGhhbmtzIGZvciB0aGUgbG9uZyBleHBsYW5hdGlvbiwgZ3JlYXQgd29y
ayEgSSBhbSByZWFsbHkgbG9va2luZyBmb3J3YXJkDQo+Pj4+IHRvIGhhdmUgdGhpcyBmZWF0dXJl
IGluIHRoZSB0cmVlIHNvb24uDQo+Pj4+DQo+Pj4+DQo+Pj4+PiAtLS0NCj4+Pj4+DQo+Pj4+PiBD
aGFuZ2VzIGluIHY0Og0KPj4+Pj4gLSB0b29sc3RhY2sgY29tbWVudHMgZnJvbSBBbnRob255IFBF
UkFSRA0KPj4+Pj4gLSBhZGRlZCBkb20wbGVzcyBzdXBwb3J0DQo+Pj4+PiAtIGFkZGVkIGRvYyBm
b3IgInhlbixzY21pLXNlY29uZGFyeS1hZ2VudHMiDQo+Pj4+Pg0KPj4+Pj4gZG9jcy9tYW4veGwu
Y2ZnLjUucG9kLmluICAgICAgICAgICAgICAgICAgICB8ICAxMyArDQo+Pj4+PiBkb2NzL21pc2Mv
YXJtL2RldmljZS10cmVlL2Jvb3RpbmcudHh0ICAgICAgIHwgIDYwICsrDQo+Pj4+PiBkb2NzL21p
c2MveGVuLWNvbW1hbmQtbGluZS5wYW5kb2MgICAgICAgICAgIHwgICA5ICsNCj4+Pj4+IHRvb2xz
L2xpYnMvbGlnaHQvbGlieGxfYXJtLmMgICAgICAgICAgICAgICAgfCAgIDQgKw0KPj4+Pj4gdG9v
bHMvbGlicy9saWdodC9saWJ4bF90eXBlcy5pZGwgICAgICAgICAgICB8ICAgNCArLQ0KPj4+Pj4g
dG9vbHMveGwveGxfcGFyc2UuYyAgICAgICAgICAgICAgICAgICAgICAgICB8ICAxMiArDQo+Pj4+
PiB4ZW4vYXJjaC9hcm0vZG9tMGxlc3MtYnVpbGQuYyAgICAgICAgICAgICAgIHwgIDExICsNCj4+
Pj4+IHhlbi9hcmNoL2FybS9kb21haW5fYnVpbGQuYyAgICAgICAgICAgICAgICAgfCAgIDMgKy0N
Cj4+Pj4+IHhlbi9hcmNoL2FybS9maXJtd2FyZS9LY29uZmlnICAgICAgICAgICAgICAgfCAgMTEg
Kw0KPj4+Pj4geGVuL2FyY2gvYXJtL2Zpcm13YXJlL01ha2VmaWxlICAgICAgICAgICAgICB8ICAg
MSArDQo+Pj4+PiB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1wcm90by5oICAgICAgICAgIHwg
MTY0ICsrKysNCj4+Pj4+IHhlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNobWVtLmMgICAgICAg
ICAgfCAxNzMgKysrKw0KPj4+Pj4geGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktc2htZW0uaCAg
ICAgICAgICB8ICA0NSArDQo+Pj4+PiB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1zbWMtbXVs
dGlhZ2VudC5jIHwgODYwICsrKysrKysrKysrKysrKysrKysrDQo+Pj4+PiB4ZW4vaW5jbHVkZS9w
dWJsaWMvYXJjaC1hcm0uaCAgICAgICAgICAgICAgIHwgICAzICsNCj4+Pj4+IDE1IGZpbGVzIGNo
YW5nZWQsIDEzNzEgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkNCj4+Pj4+IGNyZWF0ZSBt
b2RlIDEwMDY0NCB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1wcm90by5oDQo+Pj4+PiBjcmVh
dGUgbW9kZSAxMDA2NDQgeGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktc2htZW0uYw0KPj4+Pj4g
Y3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNobWVtLmgNCj4+
Pj4+IGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1zbWMtbXVs
dGlhZ2VudC5jDQo+Pj4+Pg0KPj4+Pj4gZGlmZiAtLWdpdCBhL2RvY3MvbWFuL3hsLmNmZy41LnBv
ZC5pbiBiL2RvY3MvbWFuL3hsLmNmZy41LnBvZC5pbg0KPj4+Pj4gaW5kZXggMWNjZjUwYjhlYS4u
MzAyYzQ2ZDhiYyAxMDA2NDQNCj4+Pj4+IC0tLSBhL2RvY3MvbWFuL3hsLmNmZy41LnBvZC5pbg0K
Pj4+Pj4gKysrIGIvZG9jcy9tYW4veGwuY2ZnLjUucG9kLmluDQo+Pj4+PiBAQCAtMzEyMiw4ICsz
MTIyLDIxIEBAIHNpbmdsZSBTQ01JIE9TUE0gYWdlbnQgc3VwcG9ydC4NCj4+Pj4+IFNob3VsZCBi
ZSB1c2VkIHRvZ2V0aGVyIHdpdGggQjxkb20wX3NjbWlfc21jX3Bhc3N0aHJvdWdoPiBYZW4gY29t
bWFuZA0KPj4+Pj4gbGluZQ0KPj4+Pj4gb3B0aW9uLg0KPj4+Pj4NCj4+Pj4+ICs9aXRlbSBCPHNj
bWlfc21jX211bHRpYWdlbnQ+DQo+Pj4+PiArDQo+Pj4+PiArRW5hYmxlcyBBUk0gU0NNSSBTTUMg
bXVsdGktYWdlbnQgc3VwcG9ydCBmb3IgdGhlIGd1ZXN0IGJ5IGVuYWJsaW5nIFNDTUkNCj4+Pj4+
IG92ZXINCj4+Pj4+ICtTTUMgY2FsbHMgZm9yd2FyZGluZyBmcm9tIGRvbWFpbiB0byB0aGUgRUwz
IGZpcm13YXJlIChsaWtlIFRydXN0ZWQNCj4+Pj4+IEZpcm13YXJlLUEpDQo+Pj4+PiArd2l0aCBh
IG11bHRpIFNDTUkgT1NQTSBhZ2VudCBzdXBwb3J0LiBUaGUgU0NNSSBCPGFnZW50X2lkPiBzaG91
bGQgYmUNCj4+Pj4+ICtzcGVjaWZpZWQgZm9yIHRoZSBndWVzdC4NCj4+Pj4+ICsNCj4+Pj4+ID1i
YWNrDQo+Pj4+Pg0KPj4+Pj4gKz1pdGVtIEI8YWdlbnRfaWQ9TlVNQkVSPg0KPj4+Pj4gKw0KPj4+
Pj4gK1NwZWNpZmllcyBhIG5vbi16ZXJvIEFSTSBTQ0kgYWdlbnQgaWQgZm9yIHRoZSBndWVzdC4g
VGhpcyBvcHRpb24gaXMNCj4+Pj4+IG1hbmRhdG9yeQ0KPj4+Pj4gK2lmIHRoZSBTQ01JIFNNQyBz
dXBwb3J0IGlzIGVuYWJsZWQgZm9yIHRoZSBndWVzdC4gVGhlIGFnZW50IGlkcyBvZg0KPj4+Pj4g
ZG9tYWlucw0KPj4+Pj4gK2V4aXN0aW5nIG9uIGEgc2luZ2xlIGhvc3QgbXVzdCBiZSB1bmlxdWUg
YW5kIGluIHRoZSByYW5nZSBbMS4uMjU1XS4NCj4+Pj4+ICsNCj4+Pj4+ID1iYWNrDQo+Pj4+Pg0K
Pj4+Pj4gPWJhY2sNCj4+Pj4+IGRpZmYgLS1naXQgYS9kb2NzL21pc2MvYXJtL2RldmljZS10cmVl
L2Jvb3RpbmcudHh0DQo+Pj4+PiBiL2RvY3MvbWlzYy9hcm0vZGV2aWNlLXRyZWUvYm9vdGluZy50
eHQNCj4+Pj4+IGluZGV4IDg5NDNjMDQxNzMuLmM4OTIzYWI4YjIgMTAwNjQ0DQo+Pj4+PiAtLS0g
YS9kb2NzL21pc2MvYXJtL2RldmljZS10cmVlL2Jvb3RpbmcudHh0DQo+Pj4+PiArKysgYi9kb2Nz
L21pc2MvYXJtL2RldmljZS10cmVlL2Jvb3RpbmcudHh0DQo+Pj4+PiBAQCAtMjk2LDYgKzI5Niwy
MCBAQCB3aXRoIHRoZSBmb2xsb3dpbmcgcHJvcGVydGllczoNCj4+Pj4+ICAgICAgIFNob3VsZCBi
ZSB1c2VkIHRvZ2V0aGVyIHdpdGggZG9tMF9zY21pX3NtY19wYXNzdGhyb3VnaCBYZW4gY29tbWFu
ZA0KPj4+Pj4gbGluZQ0KPj4+Pj4gICAgICAgb3B0aW9uLg0KPj4+Pj4NCj4+Pj4+ICsgICAgLSAi
c2NtaV9zbWNfbXVsdGlhZ2VudCINCj4+Pj4+ICsNCj4+Pj4+ICsgICAgRW5hYmxlcyBBUk0gU0NN
SSBTTUMgbXVsdGktYWdlbnQgc3VwcG9ydCBmb3IgdGhlIGd1ZXN0IGJ5IGVuYWJsaW5nDQo+Pj4+
PiBTQ01JIG92ZXINCj4+Pj4+ICsgICAgU01DIGNhbGxzIGZvcndhcmRpbmcgZnJvbSBkb21haW4g
dG8gdGhlIEVMMyBmaXJtd2FyZSAobGlrZSBBUk0NCj4+Pj4+ICsgICAgVHJ1c3RlZCBGaXJtd2Fy
ZS1BKSB3aXRoIGEgbXVsdGkgU0NNSSBPU1BNIGFnZW50IHN1cHBvcnQuDQo+Pj4+PiArICAgIFRo
ZSBTQ01JIGFnZW50X2lkIHNob3VsZCBiZSBzcGVjaWZpZWQgZm9yIHRoZSBndWVzdCB3aXRoDQo+
Pj4+PiAieGVuLHNjaV9hZ2VudF9pZCINCj4+Pj4+ICsgICAgcHJvcGVydHkuDQo+Pj4+PiArDQo+
Pj4+PiArLSAieGVuLHNjaV9hZ2VudF9pZCINCj4+Pj4+ICsNCj4+Pj4+ICsgICAgU3BlY2lmaWVz
IGEgbm9uLXplcm8gQVJNIFNDSSBhZ2VudCBpZCBmb3IgdGhlIGd1ZXN0LiBUaGlzIG9wdGlvbiBp
cw0KPj4+Pj4gKyAgICBtYW5kYXRvcnkgaWYgdGhlIFNDTUkgU01DICJzY21pX3NtY19tdWx0aWFn
ZW50IiBzdXBwb3J0IGlzIGVuYWJsZWQNCj4+Pj4+IGZvcg0KPj4+Pj4gKyAgICB0aGUgZ3Vlc3Qu
IFRoZSBhZ2VudCBpZHMgb2YgZ3Vlc3QgbXVzdCBiZSB1bmlxdWUgYW5kIGluIHRoZSByYW5nZQ0K
Pj4+Pj4gWzEuLjI1NV0uDQo+Pj4+PiArDQo+Pj4+PiBVbmRlciB0aGUgInhlbixkb21haW4iIGNv
bXBhdGlibGUgbm9kZSwgb25lIG9yIG1vcmUgc3ViLW5vZGVzIGFyZSBwcmVzZW50IGZvciB0aGUg
RG9tVQ0KPj4+Pj4ga2VybmVsIGFuZCByYW1kaXNrLiBAQCAtNzY0LDMgKzc3OCw0OSBAQCBUaGUg
YXV0b21hdGljYWxseQ0KPj4+Pj4gYWxsb2NhdGVkIHN0YXRpYyBzaGFyZWQgbWVtb3J5IHdpbGwg
Z2V0IG1hcHBlZCBhdCAweDgwMDAwMDAwIGluDQo+Pj4+PiBEb21VMSBndWVzdCBwaHlzaWNhbCBh
ZGRyZXNzIHNwYWNlLCBhbmQgYXQgMHg5MDAwMDAwMCBpbiBEb21VMg0KPj4+Pj4gZ3Vlc3QgcGh5
c2ljYWwgYWRkcmVzcyBzcGFjZS4gRG9tVTEgaXMgZXhwbGljaXRseSBkZWZpbmVkIGFzIHRoZQ0K
Pj4+Pj4gb3duZXIgZG9tYWluLCBhbmQgRG9tVTIgaXMgdGhlIGJvcnJvd2VyIGRvbWFpbi4gKyAr
U0NNSSBTTUMNCj4+Pj4+IG11bHRpLWFnZW50IHN1cHBvcnQgKz09PT09PT09PT09PT09PT09PT09
PT09PT09PT0gKyArRm9yIGVuYWJsaW5nDQo+Pj4+PiB0aGUgQVJNIFNDTUkgU01DIG11bHRpLWFn
ZW50IHN1cHBvcnQgKGVuYWJsZWQgYnkNCj4+Pj4+IENPTkZJR19TQ01JX1NNQ19NQSkgK3RoZSBY
ZW4gc3BlY2lmaWMgU0NNSSBBZ2VudCdzIGNvbmZpZ3VyYXRpb24NCj4+Pj4+IHNoZWxsIGJlIHBy
b3ZpZGVkIGluIHRoZSBIb3N0IERUICthY2NvcmRpbmcgdG8gdGhlIFNDTUkgY29tcGxpYW50DQo+
Pj4+PiBFTDMgRmlybXdhcmUgc3BlY2lmaWNhdGlvbiB3aXRoICtBUk0gU01DL0hWQyB0cmFuc3Bv
cnQgdXNpbmcNCj4+Pj4+IHByb3BlcnR5ICJ4ZW4sc2NtaS1zZWNvbmRhcnktYWdlbnRzIiB1bmRl
cg0KPj4+Pj4gK3RoZSB0b3AtbGV2ZWwgImNob3NlbiIgbm9kZToNCj4+Pj4+ICsNCj4+Pj4+ICst
IHhlbixzY21pLXNlY29uZGFyeS1hZ2VudHMNCj4+Pj4+ICsNCj4+Pj4+ICsgICAgRGVmaW5lcyBh
IHNldCBvZiBTQ01JIGFnZW50cyBjb25maWd1cmF0aW9uIHN1cHBvcnRlZCBieSBTQ01JIEVMMyBG
Vw0KPj4+Pj4gYW5kDQo+Pj4+PiArICAgIGF2YWlsYWJsZSBmb3IgWGVuLiBFYWNoIEFnZW50IGRl
ZmluZWQgYXMgdHJpcGxlIGNvbnNpc3Rpbmcgb2Y6DQo+Pj4+PiArICAgIFNDTUkgYWdlbnRfaWQs
DQo+Pj4+PiArICAgIFNNQy9IVkMgZnVuY3Rpb25faWQgYXNzaWduZWQgZm9yIHRoZSBhZ2VudCB0
cmFuc3BvcnQNCj4+Pj4+ICgiYXJtLHNtYy1pZCIpLA0KPj4+Pj4gKyAgICBwaGFuZGxlIHRvIFND
TUkgU0hNIGFzc2lnbmVkIGZvciB0aGUgYWdlbnQgdHJhbnNwb3J0DQo+Pj4+PiAoImFybSxzY21p
LXNobWVtIikuDQo+Pj4+PiArDQo+Pj4+PiArQXMgYW4gZXhhbXBsZToNCj4+Pj4+ICsNCj4+Pj4+
ICtjaG9zZW4gew0KPj4+Pj4gKyAgICB4ZW4sc2NtaS1zZWNvbmRhcnktYWdlbnRzID0gPA0KPj4+
Pj4gKyAgICAgICAgMSAweDgyMDAwMDAzICZzY21pX3NobV8xDQo+Pj4+PiArICAgICAgICAyIDB4
ODIwMDAwMDQgJnNjbWlfc2htXzINCj4+Pj4+ICsgICAgICAgIDMgMHg4MjAwMDAwNSAmc2NtaV9z
aG1fMw0KPj4+Pj4gKyAgICAgICAgNCAweDgyMDAwMDA2ICZzY21pX3NobV80PjsNCj4+Pj4+ICt9
DQo+Pj4+IE5JVDogaXQgc2hvdWxkIGJlIH07DQo+Pj4+DQo+Pj4+IExvb2tpbmcgYXQgc2NtaV9w
cm9iZSwgY29sbGVjdF9hZ2VudHMsIGFuZCB0aGUgZm9sbG93aW5nIFNDTUkNCj4+Pj4gU0NNSV9C
QVNFX0RJU0NPVkVSX0FHRU5UIHJlcXVlc3QsIEkgd29uZGVyOiBkbyB3ZSBhY3R1YWxseSBuZWVk
IHRoaXMNCj4+Pj4gaW5mb3JtYXRpb24/DQo+Pj4+DQo+Pj4+IEl0IGxvb2tzIGxpa2Ugd2UgY2Fu
IGRpc2NvdmVyIHRoZSBhZ2VuZF9pZHMgZm9yIGV2ZXJ5IGNoYW5uZWwsIEkgZ3Vlc3MNCj4+Pj4g
d2hhdCB3ZSBuZWVkIHRvIGtub3cgaXMgdGhlIHNobWVtIGxvY2F0aW9uIGZvciBldmVyeSBjaGFu
bmVsPyBCdXQgdGhlDQo+Pj4+IGZ1bGwgbGlzdCBvZiBzaG1lbSBjaGFubmVsIGlzIGF2YWlsYWJs
ZSBiZWxvdyB0aGFua3MgdG8gdGhlIHNjbWktc2htZW0NCj4+Pj4gbm9kZXMuDQo+Pj4+DQo+Pj4+
IFNvLCB3ZSBoYXZlIHRoZSBsaXN0IG9mIHNjbWktc2htZW0gYW55d2F5LCBhbmQgd2UgY2FuIHBy
b2JlIHRoZQ0KPj4+PiBhZ2VudF9pZC4gVGhlIG9ubHkgcGFyYW1ldGVyIGxlZnQgaXMgdGhlIHNt
Y19pZC9mdW5jX2lkLg0KPj4+Pg0KPj4+PiBPciBtYXliZSBzbWNfaWQvZnVuY19pZCBjYW4gYmUg
Y2FsY3VsYXRlZCBmcm9tIGFnZW50X2lkPw0KPj4+Pg0KPj4+PiBJIGFtIGFza2luZyBtb3N0bHkg
YmVjYXVzZSBpZiBhIHVzZXIgaXMgc3VwcG9zZWQgdG8gYWRkIHRoaXMNCj4+Pj4geGVuLHNjbWkt
c2Vjb25kYXJ5LWFnZW50cyBwcm9wZXJ0eSwgd2hlcmUgYXJlIHRoZXkgc3VwcG9zZWQgdG8gZmlu
ZCB0aGUNCj4+Pj4gc21jX2lkL2Z1bmNfaWQgaW5mb3JtYXRpb24/DQo+Pj4+DQo+Pj4+IEl0IGlz
IGltcG9ydGFudCB0aGF0IHdlIHdyaXRlIGRvd24gaW4gdGhpcyBkb2N1bWVudCBob3cgdGhlIHVz
ZXIgaXMNCj4+Pj4gZXhwZWN0ZWQgdG8gZmluZCBvdXQgd2hhdCAxIGlzIDB4ODIwMDAwMDMgd2hp
Y2ggaXMgc2NtaV9zaG1fMS4NCj4+Pj4NCj4+Pj4NCj4+Pj4+ICsvew0KPj4+Pj4gKyAgICAgICAg
c2NtaV9zaG1fMTogc3JhbUA0N2ZmMTAwMCB7DQo+Pj4+PiArICAgICAgICAgICAgICAgIGNvbXBh
dGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0KPj4+Pj4gKyAgICAgICAgICAgICAgICByZWcgPSA8
MHgwIDB4NDdmZjEwMDAgMHgwIDB4MTAwMD47DQo+Pj4+PiArICAgICAgICB9Ow0KPj4+Pj4gKyAg
ICAgICAgc2NtaV9zaG1fMjogc3JhbUA0N2ZmMjAwMCB7DQo+Pj4+PiArICAgICAgICAgICAgICAg
IGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0KPj4+Pj4gKyAgICAgICAgICAgICAgICBy
ZWcgPSA8MHgwIDB4NDdmZjIwMDAgMHgwIDB4MTAwMD47DQo+Pj4+PiArICAgICAgICB9Ow0KPj4+
Pj4gKyAgICAgICAgc2NtaV9zaG1fMzogc3JhbUA0N2ZmMzAwMCB7DQo+Pj4+PiArICAgICAgICAg
ICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0KPj4+Pj4gKyAgICAgICAgICAg
ICAgICByZWcgPSA8MHgwIDB4NDdmZjMwMDAgMHgwIDB4MTAwMD47DQo+Pj4+PiArICAgICAgICB9
Ow0KPj4+Pj4gKyAgICAgICAgc2NtaV9zaG1fMzogc3JhbUA0N2ZmNDAwMCB7DQo+Pj4+PiArICAg
ICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0KPj4+Pj4gKyAgICAg
ICAgICAgICAgICByZWcgPSA8MHgwIDB4NDdmZjQwMDAgMHgwIDB4MTAwMD47DQo+Pj4+PiArICAg
ICAgICB9Ow0KPj4+PiBBcmUgdGhlc2Ugc2NtaV9zaG1fMSAtIHNjbWlfc2htXzMgdW5kZXIgdGhl
IHRvcCBsZXZlbCBkZXZpY2UgdHJlZSBub2RlPw0KPj4+PiBPciBhcmUgdW5kZXIgL2Zpcm13YXJl
PyBPciBhcmUgdGhleSB1bmRlciAvY2hvc2VuPw0KPj4+Pg0KPj4+PiBJIHRha2UgdGhleSBhcmUg
dW5kZXIgdGhlIHRvcCBsZXZlbCBub2RlIHRvZ2V0aGVyIHdpdGggc2NtaV9zaG1fMD8NCj4+Pj4N
Cj4+Pj4gQ2FuIHlvdSBwbGVhc2UgYWxzbyBjbGFyaWZ5IGluIHRoZSBkb2N1bWVudCBhcyB3ZWxs
Pw0KPj4+Pg0KPj4+Pg0KPj4+Pj4gK30NCj4+Pj4+IGRpZmYgLS1naXQgYS9kb2NzL21pc2MveGVu
LWNvbW1hbmQtbGluZS5wYW5kb2MNCj4+Pj4+IGIvZG9jcy9taXNjL3hlbi1jb21tYW5kLWxpbmUu
cGFuZG9jDQo+Pj4+PiBpbmRleCA4ZTUwZjZiN2M3Li5iYzNjNjRkNmVjIDEwMDY0NA0KPj4+Pj4g
LS0tIGEvZG9jcy9taXNjL3hlbi1jb21tYW5kLWxpbmUucGFuZG9jDQo+Pj4+PiArKysgYi9kb2Nz
L21pc2MveGVuLWNvbW1hbmQtbGluZS5wYW5kb2MNCj4+Pj4+IEBAIC0xMDkxLDYgKzEwOTEsMTUg
QEAgd2hpY2ggc2VydmVzIGFzIERyaXZlciBkb21haW4uIFRoZSBTQ01JIHdpbGwgYmUNCj4+Pj4+
IGRpc2FibGVkIGZvciBEb20wL2h3ZG9tIGFuZA0KPj4+Pj4gU0NNSSBub2RlcyByZW1vdmVkIGZy
b20gRG9tMC9od2RvbSBkZXZpY2UgdHJlZS4NCj4+Pj4+IChmb3IgZXhhbXBsZSwgdGhpbiBEb20w
IHdpdGggRHJpdmVyIGRvbWFpbiB1c2UtY2FzZSkuDQo+Pj4+Pg0KPj4+Pj4gKyMjIyBkb20wX3Nj
bWlfYWdlbnRfaWQgKEFSTSkNCj4+Pj4+ICs+IGA9IDxpbnRlZ2VyPmANCj4+Pj4+ICsNCj4+Pj4+
ICtUaGUgb3B0aW9uIGlzIGF2YWlsYWJsZSB3aGVuIGBDT05GSUdfU0NNSV9TTUNfTUFgIGlzIGNv
bXBpbGVkIGluLCBhbmQNCj4+Pj4+IGFsbG93cyB0bw0KPj4+Pj4gK2VuYWJsZSBTQ01JIGZ1bmN0
aW9uYWxpdHkgZm9yIERvbTAgYnkgc3BlY2lmeWluZyBhIG5vbi16ZXJvIEFSTSBTQ01JDQo+Pj4+
PiBhZ2VudCBpZC4NCj4+Pj4+ICtUaGUgU0NNSSB3aWxsIGJlIGRpc2FibGVkIGZvciBEb20wIGlm
IHRoaXMgb3B0aW9uIGlzIG5vdCBzcGVjaWZpZWQNCj4+Pj4+ICsoZm9yIGV4YW1wbGUsIHRoaW4g
RG9tMCBvciBkb20wbGVzcyB1c2UtY2FzZXMpLg0KPj4+Pj4gK1RoZSBhZ2VudCBpZHMgb2YgZG9t
YWlucyBleGlzdGluZyBvbiBhIHNpbmdsZSBob3N0IG11c3QgYmUgdW5pcXVlLg0KPj4+Pj4gKw0K
Pj4+Pj4gIyMjIGR0dWFydCAoQVJNKQ0KPj4+Pj4+IGA9IHBhdGggWzpvcHRpb25zXWANCj4+Pj4+
IGRpZmYgLS1naXQgYS90b29scy9saWJzL2xpZ2h0L2xpYnhsX2FybS5jIGIvdG9vbHMvbGlicy9s
aWdodC9saWJ4bF9hcm0uYw0KPj4+Pj4gaW5kZXggMjhiYTllYjc4Ny4uNzcxMmY1M2NkNCAxMDA2
NDQNCj4+Pj4+IC0tLSBhL3Rvb2xzL2xpYnMvbGlnaHQvbGlieGxfYXJtLmMNCj4+Pj4+ICsrKyBi
L3Rvb2xzL2xpYnMvbGlnaHQvbGlieGxfYXJtLmMNCj4+Pj4+IEBAIC0yMjksNiArMjI5LDEwIEBA
IGludCBsaWJ4bF9fYXJjaF9kb21haW5fcHJlcGFyZV9jb25maWcobGlieGxfX2djDQo+Pj4+PiAq
Z2MsDQo+Pj4+PiAgICAgICBjYXNlIExJQlhMX0FSTV9TQ0lfVFlQRV9TQ01JX1NNQzoNCj4+Pj4+
ICAgICAgICAgICBjb25maWctPmFyY2guYXJtX3NjaV90eXBlID0gWEVOX0RPTUNUTF9DT05GSUdf
QVJNX1NDSV9TQ01JX1NNQzsNCj4+Pj4+ICAgICAgICAgICBicmVhazsNCj4+Pj4+ICsgICAgY2Fz
ZSBMSUJYTF9BUk1fU0NJX1RZUEVfU0NNSV9TTUNfTVVMVElBR0VOVDoNCj4+Pj4+ICsgICAgICAg
IGNvbmZpZy0+YXJjaC5hcm1fc2NpX3R5cGUgPQ0KPj4+Pj4gWEVOX0RPTUNUTF9DT05GSUdfQVJN
X1NDSV9TQ01JX1NNQ19NQTsNCj4+Pj4+ICsgICAgICAgIGNvbmZpZy0+YXJjaC5hcm1fc2NpX2Fn
ZW50X2lkID0NCj4+Pj4+IGRfY29uZmlnLT5iX2luZm8uYXJjaF9hcm0uYXJtX3NjaS5hZ2VudF9p
ZDsNCj4+Pj4+ICsgICAgICAgIGJyZWFrOw0KPj4+Pj4gICAgICAgZGVmYXVsdDoNCj4+Pj4+ICAg
ICAgICAgICBMT0coRVJST1IsICJVbmtub3duIEFSTV9TQ0kgdHlwZSAlZCIsDQo+Pj4+PiAgICAg
ICAgICAgICAgIGRfY29uZmlnLT5iX2luZm8uYXJjaF9hcm0uYXJtX3NjaS50eXBlKTsNCj4+Pj4+
IGRpZmYgLS1naXQgYS90b29scy9saWJzL2xpZ2h0L2xpYnhsX3R5cGVzLmlkbA0KPj4+Pj4gYi90
b29scy9saWJzL2xpZ2h0L2xpYnhsX3R5cGVzLmlkbA0KPj4+Pj4gaW5kZXggYWEyMTkwYWI1Yi4u
MTFlMzFjZTc4NiAxMDA2NDQNCj4+Pj4+IC0tLSBhL3Rvb2xzL2xpYnMvbGlnaHQvbGlieGxfdHlw
ZXMuaWRsDQo+Pj4+PiArKysgYi90b29scy9saWJzL2xpZ2h0L2xpYnhsX3R5cGVzLmlkbA0KPj4+
Pj4gQEAgLTU1MywxMSArNTUzLDEzIEBAIGxpYnhsX3N2ZV90eXBlID0gRW51bWVyYXRpb24oInN2
ZV90eXBlIiwgWw0KPj4+Pj4NCj4+Pj4+IGxpYnhsX2FybV9zY2lfdHlwZSA9IEVudW1lcmF0aW9u
KCJhcm1fc2NpX3R5cGUiLCBbDQo+Pj4+PiAgICAgICAoMCwgIm5vbmUiKSwNCj4+Pj4+IC0gICAg
KDEsICJzY21pX3NtYyIpDQo+Pj4+PiArICAgICgxLCAic2NtaV9zbWMiKSwNCj4+Pj4+ICsgICAg
KDIsICJzY21pX3NtY19tdWx0aWFnZW50IikNCj4+Pj4+ICAgICAgIF0sIGluaXRfdmFsID0gIkxJ
QlhMX0FSTV9TQ0lfVFlQRV9OT05FIikNCj4+Pj4+DQo+Pj4+PiBsaWJ4bF9hcm1fc2NpID0gU3Ry
dWN0KCJhcm1fc2NpIiwgWw0KPj4+Pj4gICAgICAgKCJ0eXBlIiwgbGlieGxfYXJtX3NjaV90eXBl
KSwNCj4+Pj4+ICsgICAgKCJhZ2VudF9pZCIsIHVpbnQ4KQ0KPj4+Pj4gICAgICAgXSkNCj4+Pj4+
DQo+Pj4+PiBsaWJ4bF9yZG1fcmVzZXJ2ZSA9IFN0cnVjdCgicmRtX3Jlc2VydmUiLCBbDQo+Pj4+
PiBkaWZmIC0tZ2l0IGEvdG9vbHMveGwveGxfcGFyc2UuYyBiL3Rvb2xzL3hsL3hsX3BhcnNlLmMN
Cj4+Pj4+IGluZGV4IGJkMjJiZTlkMzMuLjgxYWEzNzk3ZTMgMTAwNjQ0DQo+Pj4+PiAtLS0gYS90
b29scy94bC94bF9wYXJzZS5jDQo+Pj4+PiArKysgYi90b29scy94bC94bF9wYXJzZS5jDQo+Pj4+
PiBAQCAtMTMwNiw2ICsxMzA2LDE4IEBAIHN0YXRpYyBpbnQgcGFyc2VfYXJtX3NjaV9jb25maWco
WExVX0NvbmZpZyAqY2ZnLA0KPj4+Pj4gbGlieGxfYXJtX3NjaSAqYXJtX3NjaSwNCj4+Pj4+ICAg
ICAgICAgICAgICAgfQ0KPj4+Pj4gICAgICAgICAgIH0NCj4+Pj4+DQo+Pj4+PiArICAgICAgICBp
ZiAoTUFUQ0hfT1BUSU9OKCJhZ2VudF9pZCIsIHB0ciwgb3BhcmcpKSB7DQo+Pj4+PiArICAgICAg
ICAgICAgdW5zaWduZWQgbG9uZyB2YWwgPSBwYXJzZV91bG9uZyhvcGFyZyk7DQo+Pj4+PiArDQo+
Pj4+PiArICAgICAgICAgICAgaWYgKCF2YWwgfHwgdmFsID4gMjU1KSB7DQo+Pj4+PiArICAgICAg
ICAgICAgICAgIGZwcmludGYoc3RkZXJyLCAiQW4gaW52YWxpZCBBUk1fU0NJIGFnZW50X2lkIHNw
ZWNpZmllZA0KPj4+Pj4gKCVsdSkuIFZhbGlkIHJhbmdlIFsxLi4yNTVdXG4iLA0KPj4+Pj4gKyAg
ICAgICAgICAgICAgICAgICAgICAgIHZhbCk7DQo+Pj4+PiArICAgICAgICAgICAgICAgIHJldCA9
IEVSUk9SX0lOVkFMOw0KPj4+Pj4gKyAgICAgICAgICAgICAgICBnb3RvIHBhcnNlX2Vycm9yOw0K
Pj4+Pj4gKyAgICAgICAgICAgIH0NCj4+Pj4+ICsgICAgICAgICAgICBhcm1fc2NpLT5hZ2VudF9p
ZCA9IHZhbDsNCj4+Pj4+ICsgICAgICAgIH0NCj4+Pj4+ICsNCj4+Pj4+ICAgICAgICAgICBwdHIg
PSBzdHJ0b2soTlVMTCwgIiwiKTsNCj4+Pj4+ICAgICAgIH0NCj4+Pj4+DQo+Pj4+PiBkaWZmIC0t
Z2l0IGEveGVuL2FyY2gvYXJtL2RvbTBsZXNzLWJ1aWxkLmMNCj4+Pj4+IGIveGVuL2FyY2gvYXJt
L2RvbTBsZXNzLWJ1aWxkLmMNCj4+Pj4+IGluZGV4IDBhMDBmMDNhMjUuLjQzZDIxZWI4ODkgMTAw
NjQ0DQo+Pj4+PiAtLS0gYS94ZW4vYXJjaC9hcm0vZG9tMGxlc3MtYnVpbGQuYw0KPj4+Pj4gKysr
IGIveGVuL2FyY2gvYXJtL2RvbTBsZXNzLWJ1aWxkLmMNCj4+Pj4+IEBAIC04MzUsNiArODM1LDE3
IEBAIGludCBfX2luaXQgZG9tdV9kdF9zY2lfcGFyc2Uoc3RydWN0IGR0X2RldmljZV9ub2RlDQo+
Pj4+PiAqbm9kZSwNCj4+Pj4+ICAgICAgICAgICBkX2NmZy0+YXJjaC5hcm1fc2NpX3R5cGUgPSBY
RU5fRE9NQ1RMX0NPTkZJR19BUk1fU0NJX05PTkU7DQo+Pj4+PiAgICAgICBlbHNlIGlmICggIXN0
cmNtcChzY2lfdHlwZSwgInNjbWlfc21jIikgKQ0KPj4+Pj4gICAgICAgICAgIGRfY2ZnLT5hcmNo
LmFybV9zY2lfdHlwZSA9IFhFTl9ET01DVExfQ09ORklHX0FSTV9TQ0lfU0NNSV9TTUM7DQo+Pj4+
PiArICAgIGVsc2UgaWYgKCAhc3RyY21wKHNjaV90eXBlLCAic2NtaV9zbWNfbXVsdGlhZ2VudCIp
ICkNCj4+Pj4+ICsgICAgew0KPj4+Pj4gKyAgICAgICAgdWludDMyX3QgYWdlbnRfaWQgPSAwOw0K
Pj4+Pj4gKw0KPj4+Pj4gKyAgICAgICAgaWYgKCAhZHRfcHJvcGVydHlfcmVhZF91MzIobm9kZSwg
InhlbixzY2lfYWdlbnRfaWQiLCAmYWdlbnRfaWQpDQo+Pj4+PiB8fA0KPj4+Pj4gKyAgICAgICAg
ICAgICAhYWdlbnRfaWQgKQ0KPj4+PiBzaG91bGRuJ3Qgd2UgY2hlY2sgdGhhdCBhZ2VudF9pZCA8
PSAyNTUgPw0KPj4+Pg0KPj4+Pg0KPj4+Pj4gKyAgICAgICAgICAgIHJldHVybiAtRUlOVkFMOw0K
Pj4+Pj4gKw0KPj4+Pj4gKyAgICAgICAgZF9jZmctPmFyY2guYXJtX3NjaV90eXBlID0NCj4+Pj4+
IFhFTl9ET01DVExfQ09ORklHX0FSTV9TQ0lfU0NNSV9TTUNfTUE7DQo+Pj4+PiArICAgICAgICBk
X2NmZy0+YXJjaC5hcm1fc2NpX2FnZW50X2lkID0gYWdlbnRfaWQ7DQo+Pj4+PiArICAgIH0NCj4+
Pj4+ICAgICAgIGVsc2UNCj4+Pj4+ICAgICAgIHsNCj4+Pj4+ICAgICAgICAgICBwcmludGsoWEVO
TE9HX0VSUiAieGVuLHNjaV90eXBlIGluIG5vdCB2YWxpZCAoJXMpIGZvciBkb21haW4NCj4+Pj4+
ICVzXG4iLA0KPj4+Pj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9kb21haW5fYnVpbGQuYyBi
L3hlbi9hcmNoL2FybS9kb21haW5fYnVpbGQuYw0KPj4+Pj4gaW5kZXggMzZkMjhiNTJhNC4uMGM5
Mjc0YTJiMyAxMDA2NDQNCj4+Pj4+IC0tLSBhL3hlbi9hcmNoL2FybS9kb21haW5fYnVpbGQuYw0K
Pj4+Pj4gKysrIGIveGVuL2FyY2gvYXJtL2RvbWFpbl9idWlsZC5jDQo+Pj4+PiBAQCAtNjE2LDcg
KzYxNiw4IEBAIHN0YXRpYyBpbnQgX19pbml0IHdyaXRlX3Byb3BlcnRpZXMoc3RydWN0IGRvbWFp
biAqZCwNCj4+Pj4+IHN0cnVjdCBrZXJuZWxfaW5mbyAqa2luZm8sDQo+Pj4+PiAgICAgICAgICAg
ICAgICAgICAgZHRfcHJvcGVydHlfbmFtZV9pc19lcXVhbChwcm9wLA0KPj4+Pj4gImxpbnV4LHVl
ZmktbW1hcC1zdGFydCIpIHx8DQo+Pj4+PiAgICAgICAgICAgICAgICAgICAgZHRfcHJvcGVydHlf
bmFtZV9pc19lcXVhbChwcm9wLA0KPj4+Pj4gImxpbnV4LHVlZmktbW1hcC1zaXplIikgfHwNCj4+
Pj4+ICAgICAgICAgICAgICAgICAgICBkdF9wcm9wZXJ0eV9uYW1lX2lzX2VxdWFsKHByb3AsDQo+
Pj4+PiAibGludXgsdWVmaS1tbWFwLWRlc2Mtc2l6ZSIpIHx8DQo+Pj4+PiAtICAgICAgICAgICAg
ICAgICBkdF9wcm9wZXJ0eV9uYW1lX2lzX2VxdWFsKHByb3AsDQo+Pj4+PiAibGludXgsdWVmaS1t
bWFwLWRlc2MtdmVyIikpDQo+Pj4+PiArICAgICAgICAgICAgICAgICBkdF9wcm9wZXJ0eV9uYW1l
X2lzX2VxdWFsKHByb3AsDQo+Pj4+PiAibGludXgsdWVmaS1tbWFwLWRlc2MtdmVyIikgfHwNCj4+
Pj4+ICsgICAgICAgICAgICAgICAgIGR0X3Byb3BlcnR5X25hbWVfaXNfZXF1YWwocHJvcCwNCj4+
Pj4+ICJ4ZW4sc2NtaS1zZWNvbmRhcnktYWdlbnRzIikgKQ0KPj4+Pj4gICAgICAgICAgICAgICAg
ICAgY29udGludWU7DQo+Pj4+Pg0KPj4+Pj4gICAgICAgICAgICAgICBpZiAoIGR0X3Byb3BlcnR5
X25hbWVfaXNfZXF1YWwocHJvcCwgInhlbixkb20wLWJvb3RhcmdzIikgKSBkaWZmIC0tZ2l0IGEv
eGVuL2FyY2gvYXJtL2Zpcm13YXJlL0tjb25maWcNCj4+Pj4+IGIveGVuL2FyY2gvYXJtL2Zpcm13
YXJlL0tjb25maWcgaW5kZXggNWM1ZjA4ODBjNC4uNmIwNTFjOGFkYQ0KPj4+Pj4gMTAwNjQ0IC0t
LSBhL3hlbi9hcmNoL2FybS9maXJtd2FyZS9LY29uZmlnICsrKw0KPj4+Pj4gYi94ZW4vYXJjaC9h
cm0vZmlybXdhcmUvS2NvbmZpZyBAQCAtMjksNiArMjksMTcgQEAgY29uZmlnIFNDTUlfU01DDQo+
Pj4+PiBkcml2ZXIgZG9tYWluLiBVc2Ugd2l0aCBFTDMgZmlybXdhcmUgd2hpY2ggc3VwcG9ydHMg
b25seSBzaW5nbGUNCj4+Pj4+IFNDTUkgT1NQTSBhZ2VudC4gK2NvbmZpZyBTQ01JX1NNQ19NQSAr
IGJvb2wgIkVuYWJsZSBBUk0gU0NNSSBTTUMgbXVsdGktYWdlbnQgZHJpdmVyIg0KPj4+Pj4gKyBz
ZWxlY3QgQVJNX1NDSQ0KPj4+Pj4gKyBoZWxwDQo+Pj4+PiArICAgRW5hYmxlcyBTQ01JIFNNQy9I
VkMgbXVsdGktYWdlbnQgaW4gWEVOIHRvIHBhc3MgU0NNSSByZXF1ZXN0cyBmcm9tDQo+Pj4+PiBE
b21haW5zDQo+Pj4+PiArICAgdG8gRUwzIGZpcm13YXJlIChURi1BKSB3aGljaCBzdXBwb3J0cyBt
dWx0aS1hZ2VudCBmZWF0dXJlLg0KPj4+Pj4gKyAgIFRoaXMgZmVhdHVyZSBhbGxvd3MgdG8gZW5h
YmxlIFNDTUkgcGVyIERvbWFpbiB1c2luZyB1bmlxdWUgU0NNSQ0KPj4+Pj4gYWdlbnRfaWQsDQo+
Pj4+PiArICAgc28gRG9tYWluIGlzIGlkZW50aWZpZWQgYnkgRUwzIGZpcm13YXJlIGFzIGFuIFND
TUkgQWdlbnQgYW5kIGNhbg0KPj4+Pj4gYWNjZXNzDQo+Pj4+PiArICAgYWxsb3dlZCBwbGF0Zm9y
bSByZXNvdXJjZXMgdGhyb3VnaCBkZWRpY2F0ZWQgU01DL0hWQyBTaGFyZWQgbWVtb3J5DQo+Pj4+
PiBiYXNlZA0KPj4+Pj4gKyAgIHRyYW5zcG9ydC4NCj4+Pj4+ICsNCj4+Pj4+IGVuZGNob2ljZQ0K
Pj4+Pj4NCj4+Pj4+IGVuZG1lbnUNCj4+Pj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vZmly
bXdhcmUvTWFrZWZpbGUNCj4+Pj4+IGIveGVuL2FyY2gvYXJtL2Zpcm13YXJlL01ha2VmaWxlDQo+
Pj4+PiBpbmRleCA3MWJkZWZjMjRhLi4zNzkyN2U2OTBlIDEwMDY0NA0KPj4+Pj4gLS0tIGEveGVu
L2FyY2gvYXJtL2Zpcm13YXJlL01ha2VmaWxlDQo+Pj4+PiArKysgYi94ZW4vYXJjaC9hcm0vZmly
bXdhcmUvTWFrZWZpbGUNCj4+Pj4+IEBAIC0xLDIgKzEsMyBAQA0KPj4+Pj4gb2JqLSQoQ09ORklH
X0FSTV9TQ0kpICs9IHNjaS5vDQo+Pj4+PiBvYmotJChDT05GSUdfU0NNSV9TTUMpICs9IHNjbWkt
c21jLm8NCj4+Pj4+ICtvYmotJChDT05GSUdfU0NNSV9TTUNfTUEpICs9IHNjbWktc2htZW0ubyBz
Y21pLXNtYy1tdWx0aWFnZW50Lm8NCj4+Pj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vZmly
bXdhcmUvc2NtaS1wcm90by5oDQo+Pj4+PiBiL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXBy
b3RvLmgNCj4+Pj4+IG5ldyBmaWxlIG1vZGUgMTAwNjQ0DQo+Pj4+PiBpbmRleCAwMDAwMDAwMDAw
Li4zZjRiOWM1ZDZiDQo+Pj4+PiAtLS0gL2Rldi9udWxsDQo+Pj4+PiArKysgYi94ZW4vYXJjaC9h
cm0vZmlybXdhcmUvc2NtaS1wcm90by5oDQo+Pj4+PiBAQCAtMCwwICsxLDE2NCBAQA0KPj4+Pj4g
Ky8qIFNQRFgtTGljZW5zZS1JZGVudGlmaWVyOiBHUEwtMi4wLW9ubHkgKi8NCj4+Pj4+ICsvKg0K
Pj4+Pj4gKyAqIEFybSBTeXN0ZW0gQ29udHJvbCBhbmQgTWFuYWdlbWVudCBJbnRlcmZhY2UgZGVm
aW5pdGlvbnMNCj4+Pj4+ICsgKiBWZXJzaW9uIDMuMCAoREVOMDA1NkMpDQo+Pj4+PiArICoNCj4+
Pj4+ICsgKiBDb3B5cmlnaHQgKGMpIDIwMjQgRVBBTSBTeXN0ZW1zDQo+Pj4+PiArICovDQo+Pj4+
PiArDQo+Pj4+PiArI2lmbmRlZiBYRU5fQVJDSF9BUk1fU0NJX1NDTUlfUFJPVE9fSF8NCj4+Pj4+
ICsjZGVmaW5lIFhFTl9BUkNIX0FSTV9TQ0lfU0NNSV9QUk9UT19IXw0KPj4+PiBOSVQ6IEFSTV9G
SVJNV0FSRV9TQ01JX1BST1RPX0gNCj4+Pj4NCj4+Pj4NCj4+Pj4+ICsjaW5jbHVkZSA8eGVuL3N0
ZGludC5oPg0KPj4+Pj4gKw0KPj4+Pj4gKyNkZWZpbmUgU0NNSV9TSE9SVF9OQU1FX01BWF9TSVpF
IDE2DQo+Pj4+PiArDQo+Pj4+PiArLyogU0NNSSBzdGF0dXMgY29kZXMuIFNlZSBzZWN0aW9uIDQu
MS40ICovDQo+Pj4+PiArI2RlZmluZSBTQ01JX1NVQ0NFU1MgICAgICAgICAgICAgIDANCj4+Pj4+
ICsjZGVmaW5lIFNDTUlfTk9UX1NVUFBPUlRFRCAgICAgICgtMSkNCj4+Pj4+ICsjZGVmaW5lIFND
TUlfSU5WQUxJRF9QQVJBTUVURVJTICgtMikNCj4+Pj4+ICsjZGVmaW5lIFNDTUlfREVOSUVEICAg
ICAgICAgICAgICgtMykNCj4+Pj4+ICsjZGVmaW5lIFNDTUlfTk9UX0ZPVU5EICAgICAgICAgICgt
NCkNCj4+Pj4+ICsjZGVmaW5lIFNDTUlfT1VUX09GX1JBTkdFICAgICAgICgtNSkNCj4+Pj4+ICsj
ZGVmaW5lIFNDTUlfQlVTWSAgICAgICAgICAgICAgICgtNikNCj4+Pj4+ICsjZGVmaW5lIFNDTUlf
Q09NTVNfRVJST1IgICAgICAgICgtNykNCj4+Pj4+ICsjZGVmaW5lIFNDTUlfR0VORVJJQ19FUlJP
UiAgICAgICgtOCkNCj4+Pj4+ICsjZGVmaW5lIFNDTUlfSEFSRFdBUkVfRVJST1IgICAgICgtOSkN
Cj4+Pj4+ICsjZGVmaW5lIFNDTUlfUFJPVE9DT0xfRVJST1IgICAgICgtMTApDQo+Pj4+PiArDQo+
Pj4+PiArLyogUHJvdG9jb2wgSURzICovDQo+Pj4+PiArI2RlZmluZSBTQ01JX0JBU0VfUFJPVE9D
T0wgMHgxMA0KPj4+Pj4gKw0KPj4+Pj4gKy8qIEJhc2UgcHJvdG9jb2wgbWVzc2FnZSBJRHMgKi8N
Cj4+Pj4+ICsjZGVmaW5lIFNDTUlfQkFTRV9QUk9UT0NPTF9WRVJTSU9OICAgICAgICAgICAgMHgw
DQo+Pj4+PiArI2RlZmluZSBTQ01JX0JBU0VfUFJPVE9DT0xfQVRUSUJVVEVTICAgICAgICAgIDB4
MQ0KPj4+Pj4gKyNkZWZpbmUgU0NNSV9CQVNFX1BST1RPQ09MX01FU1NBR0VfQVRUUklCVVRFUyAw
eDINCj4+Pj4+ICsjZGVmaW5lIFNDTUlfQkFTRV9ESVNDT1ZFUl9BR0VOVCAgICAgICAgICAgICAg
MHg3DQo+Pj4+PiArI2RlZmluZSBTQ01JX0JBU0VfU0VUX0RFVklDRV9QRVJNSVNTSU9OUyAgICAg
IDB4OQ0KPj4+Pj4gKyNkZWZpbmUgU0NNSV9CQVNFX1JFU0VUX0FHRU5UX0NPTkZJR1VSQVRJT04g
ICAweEINCj4+Pj4+ICsNCj4+Pj4+ICt0eXBlZGVmIHN0cnVjdCBzY21pX21zZ19oZWFkZXIgew0K
Pj4+Pj4gKyAgICB1aW50OF90IGlkOw0KPj4+Pj4gKyAgICB1aW50OF90IHR5cGU7DQo+Pj4+PiAr
ICAgIHVpbnQ4X3QgcHJvdG9jb2w7DQo+Pj4+PiArICAgIHVpbnQzMl90IHN0YXR1czsNCj4+Pj4+
ICt9IHNjbWlfbXNnX2hlYWRlcl90Ow0KPj4+Pj4gKw0KPj4+Pj4gKy8qIFRhYmxlIDIgTWVzc2Fn
ZSBoZWFkZXIgZm9ybWF0ICovDQo+Pj4+PiArI2RlZmluZSBTQ01JX0hEUl9JRCAgICBHRU5NQVNL
KDcsIDApDQo+Pj4+PiArI2RlZmluZSBTQ01JX0hEUl9UWVBFICBHRU5NQVNLKDksIDgpDQo+Pj4+
PiArI2RlZmluZSBTQ01JX0hEUl9QUk9UTyBHRU5NQVNLKDE3LCAxMCkNCj4+Pj4+ICsNCj4+Pj4+
ICsjZGVmaW5lIFNDTUlfRklFTERfR0VUKF9tYXNrLCBfcmVnKQ0KPj4+Pj4gXA0KPj4+Pj4gKyAg
ICAoKHR5cGVvZihfbWFzaykpKCgoX3JlZykgJiAoX21hc2spKSA+PiAoZmZzNjQoX21hc2spIC0g
MSkpKQ0KPj4+Pj4gKyNkZWZpbmUgU0NNSV9GSUVMRF9QUkVQKF9tYXNrLCBfdmFsKQ0KPj4+Pj4g
XA0KPj4+Pj4gKyAgICAoKCh0eXBlb2YoX21hc2spKShfdmFsKSA8PCAoZmZzNjQoX21hc2spIC0g
MSkpICYgKF9tYXNrKSkNCj4+Pj4+ICsNCj4+Pj4+ICtzdGF0aWMgaW5saW5lIHVpbnQzMl90IHBh
Y2tfc2NtaV9oZWFkZXIoc2NtaV9tc2dfaGVhZGVyX3QgKmhkcikNCj4+Pj4+ICt7DQo+Pj4+PiAr
ICAgIHJldHVybiBTQ01JX0ZJRUxEX1BSRVAoU0NNSV9IRFJfSUQsIGhkci0+aWQpIHwNCj4+Pj4+
ICsgICAgICAgICAgIFNDTUlfRklFTERfUFJFUChTQ01JX0hEUl9UWVBFLCBoZHItPnR5cGUpIHwN
Cj4+Pj4+ICsgICAgICAgICAgIFNDTUlfRklFTERfUFJFUChTQ01JX0hEUl9QUk9UTywgaGRyLT5w
cm90b2NvbCk7DQo+Pj4+PiArfQ0KPj4+Pj4gKw0KPj4+Pj4gK3N0YXRpYyBpbmxpbmUgdm9pZCB1
bnBhY2tfc2NtaV9oZWFkZXIodWludDMyX3QgbXNnX2hkciwNCj4+Pj4+IHNjbWlfbXNnX2hlYWRl
cl90ICpoZHIpDQo+Pj4+PiArew0KPj4+Pj4gKyAgICBoZHItPmlkID0gU0NNSV9GSUVMRF9HRVQo
U0NNSV9IRFJfSUQsIG1zZ19oZHIpOw0KPj4+Pj4gKyAgICBoZHItPnR5cGUgPSBTQ01JX0ZJRUxE
X0dFVChTQ01JX0hEUl9UWVBFLCBtc2dfaGRyKTsNCj4+Pj4+ICsgICAgaGRyLT5wcm90b2NvbCA9
IFNDTUlfRklFTERfR0VUKFNDTUlfSERSX1BST1RPLCBtc2dfaGRyKTsNCj4+Pj4+ICt9DQo+Pj4+
PiArDQo+Pj4+PiArc3RhdGljIGlubGluZSBpbnQgc2NtaV90b194ZW5fZXJybm8oaW50IHNjbWlf
c3RhdHVzKQ0KPj4+Pj4gK3sNCj4+Pj4+ICsgICAgaWYgKCBzY21pX3N0YXR1cyA9PSBTQ01JX1NV
Q0NFU1MgKQ0KPj4+Pj4gKyAgICAgICAgcmV0dXJuIDA7DQo+Pj4+PiArDQo+Pj4+PiArICAgIHN3
aXRjaCAoIHNjbWlfc3RhdHVzICkNCj4+Pj4+ICsgICAgew0KPj4+Pj4gKyAgICBjYXNlIFNDTUlf
Tk9UX1NVUFBPUlRFRDoNCj4+Pj4+ICsgICAgICAgIHJldHVybiAtRU9QTk9UU1VQUDsNCj4+Pj4+
ICsgICAgY2FzZSBTQ01JX0lOVkFMSURfUEFSQU1FVEVSUzoNCj4+Pj4+ICsgICAgICAgIHJldHVy
biAtRUlOVkFMOw0KPj4+Pj4gKyAgICBjYXNlIFNDTUlfREVOSUVEOg0KPj4+Pj4gKyAgICAgICAg
cmV0dXJuIC1FQUNDRVM7DQo+Pj4+PiArICAgIGNhc2UgU0NNSV9OT1RfRk9VTkQ6DQo+Pj4+PiAr
ICAgICAgICByZXR1cm4gLUVOT0VOVDsNCj4+Pj4+ICsgICAgY2FzZSBTQ01JX09VVF9PRl9SQU5H
RToNCj4+Pj4+ICsgICAgICAgIHJldHVybiAtRVJBTkdFOw0KPj4+Pj4gKyAgICBjYXNlIFNDTUlf
QlVTWToNCj4+Pj4+ICsgICAgICAgIHJldHVybiAtRUJVU1k7DQo+Pj4+PiArICAgIGNhc2UgU0NN
SV9DT01NU19FUlJPUjoNCj4+Pj4+ICsgICAgICAgIHJldHVybiAtRU5PVENPTk47DQo+Pj4+PiAr
ICAgIGNhc2UgU0NNSV9HRU5FUklDX0VSUk9SOg0KPj4+Pj4gKyAgICAgICAgcmV0dXJuIC1FSU87
DQo+Pj4+PiArICAgIGNhc2UgU0NNSV9IQVJEV0FSRV9FUlJPUjoNCj4+Pj4+ICsgICAgICAgIHJl
dHVybiAtRU5YSU87DQo+Pj4+PiArICAgIGNhc2UgU0NNSV9QUk9UT0NPTF9FUlJPUjoNCj4+Pj4+
ICsgICAgICAgIHJldHVybiAtRUJBRE1TRzsNCj4+Pj4+ICsgICAgZGVmYXVsdDoNCj4+Pj4+ICsg
ICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4+Pj4gKyAgICB9DQo+Pj4+PiArfQ0KPj4+Pj4gKw0K
Pj4+Pj4gKy8qIFBST1RPQ09MX1ZFUlNJT04gKi8NCj4+Pj4+ICsjZGVmaW5lIFNDTUlfVkVSU0lP
Tl9NSU5PUiBHRU5NQVNLKDE1LCAwKQ0KPj4+Pj4gKyNkZWZpbmUgU0NNSV9WRVJTSU9OX01BSk9S
IEdFTk1BU0soMzEsIDE2KQ0KPj4+Pj4gKw0KPj4+Pj4gK3N0cnVjdCBzY21pX21zZ19wcm90X3Zl
cnNpb25fcDJhIHsNCj4+Pj4+ICsgICAgdWludDMyX3QgdmVyc2lvbjsNCj4+Pj4+ICt9IF9fcGFj
a2VkOw0KPj4+Pj4gKw0KPj4+Pj4gKy8qIEJBU0UgUFJPVE9DT0xfQVRUUklCVVRFUyAqLw0KPj4+
Pj4gKyNkZWZpbmUgU0NNSV9CQVNFX0FUVFJfTlVNX1BST1RPIEdFTk1BU0soNywgMCkNCj4+Pj4+
ICsjZGVmaW5lIFNDTUlfQkFTRV9BVFRSX05VTV9BR0VOVCBHRU5NQVNLKDE1LCA4KQ0KPj4+Pj4g
Kw0KPj4+Pj4gK3N0cnVjdCBzY21pX21zZ19iYXNlX2F0dHJpYnV0ZXNfcDJhIHsNCj4+Pj4+ICsg
ICAgdWludDMyX3QgYXR0cmlidXRlczsNCj4+Pj4+ICt9IF9fcGFja2VkOw0KPj4+Pj4gKw0KPj4+
Pj4gKy8qDQo+Pj4+PiArICogQkFTRV9ESVNDT1ZFUl9BR0VOVA0KPj4+Pj4gKyAqLw0KPj4+Pj4g
KyNkZWZpbmUgU0NNSV9CQVNFX0FHRU5UX0lEX09XTiAweEZGRkZGRkZGDQo+Pj4+PiArDQo+Pj4+
PiArc3RydWN0IHNjbWlfbXNnX2Jhc2VfZGlzY292ZXJfYWdlbnRfYTJwIHsNCj4+Pj4+ICsgICAg
dWludDMyX3QgYWdlbnRfaWQ7DQo+Pj4+PiArfSBfX3BhY2tlZDsNCj4+Pj4+ICsNCj4+Pj4+ICtz
dHJ1Y3Qgc2NtaV9tc2dfYmFzZV9kaXNjb3Zlcl9hZ2VudF9wMmEgew0KPj4+Pj4gKyAgICB1aW50
MzJfdCBhZ2VudF9pZDsNCj4+Pj4+ICsgICAgY2hhciBuYW1lW1NDTUlfU0hPUlRfTkFNRV9NQVhf
U0laRV07DQo+Pj4+PiArfSBfX3BhY2tlZDsNCj4+Pj4+ICsNCj4+Pj4+ICsvKg0KPj4+Pj4gKyAq
IEJBU0VfU0VUX0RFVklDRV9QRVJNSVNTSU9OUw0KPj4+Pj4gKyAqLw0KPj4+Pj4gKyNkZWZpbmUg
U0NNSV9CQVNFX0RFVklDRV9BQ0NFU1NfQUxMT1cgICAgICAgICAgIEJJVCgwLCBVTCkNCj4+Pj4+
ICsNCj4+Pj4+ICtzdHJ1Y3Qgc2NtaV9tc2dfYmFzZV9zZXRfZGV2aWNlX3Blcm1pc3Npb25zX2Ey
cCB7DQo+Pj4+PiArICAgIHVpbnQzMl90IGFnZW50X2lkOw0KPj4+Pj4gKyAgICB1aW50MzJfdCBk
ZXZpY2VfaWQ7DQo+Pj4+PiArICAgIHVpbnQzMl90IGZsYWdzOw0KPj4+Pj4gK30gX19wYWNrZWQ7
DQo+Pj4+PiArDQo+Pj4+PiArLyoNCj4+Pj4+ICsgKiBCQVNFX1JFU0VUX0FHRU5UX0NPTkZJR1VS
QVRJT04NCj4+Pj4+ICsgKi8NCj4+Pj4+ICsjZGVmaW5lIFNDTUlfQkFTRV9BR0VOVF9QRVJNSVNT
SU9OU19SRVNFVCAgICAgICBCSVQoMCwgVUwpDQo+Pj4+PiArDQo+Pj4+PiArc3RydWN0IHNjbWlf
bXNnX2Jhc2VfcmVzZXRfYWdlbnRfY2ZnX2EycCB7DQo+Pj4+PiArICAgIHVpbnQzMl90IGFnZW50
X2lkOw0KPj4+Pj4gKyAgICB1aW50MzJfdCBmbGFnczsNCj4+Pj4+ICt9IF9fcGFja2VkOw0KPj4+
Pj4gKw0KPj4+Pj4gKyNlbmRpZiAvKiBYRU5fQVJDSF9BUk1fU0NJX1NDTUlfUFJPVE9fSF8gKi8N
Cj4+Pj4+ICsNCj4+Pj4+ICsvKg0KPj4+Pj4gKyAqIExvY2FsIHZhcmlhYmxlczoNCj4+Pj4+ICsg
KiBtb2RlOiBDDQo+Pj4+PiArICogYy1maWxlLXN0eWxlOiAiQlNEIg0KPj4+Pj4gKyAqIGMtYmFz
aWMtb2Zmc2V0OiA0DQo+Pj4+PiArICogdGFiLXdpZHRoOiA0DQo+Pj4+PiArICogaW5kZW50LXRh
YnMtbW9kZTogbmlsDQo+Pj4+PiArICogRW5kOg0KPj4+Pj4gKyAqLw0KPj4+Pj4gZGlmZiAtLWdp
dCBhL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNobWVtLmMNCj4+Pj4+IGIveGVuL2FyY2gv
YXJtL2Zpcm13YXJlL3NjbWktc2htZW0uYw0KPj4+Pj4gbmV3IGZpbGUgbW9kZSAxMDA2NDQNCj4+
Pj4+IGluZGV4IDAwMDAwMDAwMDAuLmRkNjEzZWUwYjUNCj4+Pj4+IC0tLSAvZGV2L251bGwNCj4+
Pj4+ICsrKyBiL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNobWVtLmMNCj4+Pj4+IEBAIC0w
LDAgKzEsMTczIEBADQo+Pj4+PiArLyogU1BEWC1MaWNlbnNlLUlkZW50aWZpZXI6IEdQTC0yLjAt
b25seSAqLw0KPj4+Pj4gKy8qDQo+Pj4+PiArICogU0NJIFNDTUkgbXVsdGktYWdlbnQgZHJpdmVy
LCB1c2luZyBTTUMvSFZDIHNobWVtIGFzIHRyYW5zcG9ydC4NCj4+Pj4+ICsgKg0KPj4+Pj4gKyAq
IE9sZWtzaWkgTW9pc2llaWV2PG9sZWtzaWlfbW9pc2llaWV2QGVwYW0uY29tPg0KPj4+Pj4gKyAq
IENvcHlyaWdodCAoYykgMjAyNSBFUEFNIFN5c3RlbXMNCj4+Pj4+ICsgKi8NCj4+Pj4+ICsvKiBT
UERYLUxpY2Vuc2UtSWRlbnRpZmllcjogR1BMLTIuMC1vbmx5ICovDQo+Pj4+PiArDQo+Pj4+PiAr
I2luY2x1ZGUgPGFzbS9pby5oPg0KPj4+Pj4gKyNpbmNsdWRlIDx4ZW4vZXJyLmg+DQo+Pj4+PiAr
DQo+Pj4+PiArI2luY2x1ZGUgInNjbWktcHJvdG8uaCINCj4+Pj4+ICsjaW5jbHVkZSAic2NtaS1z
aG1lbS5oIg0KPj4+PiBUaGlzIGNvZGUgaXMgd3JpdHRlbiBtb3JlIGdlbmVyaWNhbGx5IHRoYW4g
dGhlIGRlc2NyaXB0aW9uIGltcGxpZXMuIElmDQo+Pj4+IHdlIG9ubHkgd2FudCB0byBtYWtlIFNN
QyBjYWxscyB0byBURi1BIG9uIEVMMyBhbmQgZXhjaGFuZ2UgZGF0YSB3aXRoIGl0DQo+Pj4+IG92
ZXIgc2hhcmVkIG1lbW9yeSwgdGhlbiBJIHRoaW5rOg0KPj4+PiAtIHdlIGRvbid0IG5lZWQgdGhl
IF9faW9tZW0gdGFnLCBhcyB0aGVyZSBpcyBubyBNTUlPDQo+Pj4gYWdyZWUNCj4+Pg0KPj4+PiAt
IHdlIG9ubHkgbmVlZCBhIERNQiwgbm90IGEgRFNCIChyZWFkbCBhbmQgd3JpdGVsIGltcGx5IERT
QiwgdXNlIG9ubHkNCj4+Pj4gICAgcmVhZGxfcmVsYXhlZCBhbmQgd3JpdGVsX3JlbGF4ZWQpDQo+
Pj4gYWdyZWUNCj4+Pg0KPj4+PiBPbiB0aGUgb3RoZXIgaGFuZCwgaWYgd2UgYWxzbyB3YW50IHRv
IGhhbmRsZSB0aGUgY2FzZSB3aGVyZSB0aGUgU0NNSQ0KPj4+PiBzZXJ2ZXIgY291bGQgYmUgb24g
YSBzZXBhcmF0ZSBjby1wcm9jZXNzb3IsIHRoZW4gd2hhdCB0aGlzIGNvZGUgaXMgZG9pbmcNCj4+
Pj4gaXMgbm90IHN1ZmZpY2llbnQgYmVjYXVzZSB3ZSBhbHNvIG5lZWQgYSBkY2FjaGUgZmx1c2gs
IGluIGFkZGl0aW9uIHRvDQo+Pj4+IHRoZSBEU0IuDQo+Pj4+DQo+Pj4+IEJlcnRyYW5kLCBjYW4g
eW91IGRvdWJsZS1jaGVjaz8NCj4+PiBJZiB3ZSB3YW50IHRvIGhhbmRsZSBhIGNhc2Ugd2hlcmUg
dGhlIG1lbW9yeSBpcyBhY2Nlc3NpYmxlIHRvIGEgY29wcm9jZXNzb3INCj4+PiBidXQgdGhlcmUg
aXMgbm8gY2FjaGUgY29oZXJlbmN5LCB3ZSBuZWVkIHRvIGZsdXNoIHRoZSBkY2FjaGUgZGVmaW5p
dGVseS4NCj4+Pg0KPj4+IFNlZWluZyB0aGUgYW1vdW50IG9mIGRhdGEgaGVyZSwgSSBkbyBhZ3Jl
ZSB3aXRoIFN0ZWZhbm8gdGhhdCBpdCB3b3VsZCBiZSBhDQo+Pj4gZ29vZA0KPj4+IGlkZWEgdG8g
bWFrZSB0aGUgcHJvdmlzaW9uIHRvIGZsdXNoIHRoZSBkYXRhIGNhY2hlIGluIGFsbCBjYXNlcy4g
RXZlbiBpZiB0aGUNCj4+PiBkYXRhDQo+Pj4gaXMgYWNjZXNzZWQgYnkgYSBzZWN1cmUgcGFydGl0
aW9uIG9yIHRoZSBmaXJtd2FyZSBjb2hlcmVudGx5LCBmbHVzaGluZyBpbg0KPj4+IGFsbCBjYXNl
cw0KPj4+IHdvdWxkIGhhdmUgdmVyeSBsaW1pdGVkIHBlcmZvcm1hbmNlIGltcGFjdCBoZXJlLg0K
Pj4+DQo+Pj4gVGhlcmUgaXMgdGhlIG90aGVyIHNvbHV0aW9uIHRvIGhhdmUgc29tZSBraW5kIG9m
IHBhcmFtZXRlciB0byBzYXkgaWYgdGhlDQo+Pj4gYWNjZXNzb3INCj4+PiBoYXMgY29oZXJlbnQg
Y2FjaGUgYWNjZXNzIGJ1dCBJIGRvIG5vdCB0aGluayB0aGUgcGVyZm9ybWFuY2UgaW1wYWN0IGhl
cmUNCj4+PiB3b3VsZA0KPj4+IGp1c3RpZnkgc3VjaCBhIGNvbXBsZXhpdHkuDQo+Pj4NCj4+IFRo
ZSBTQ01JIHNobWVtIGV4cGVjdGVkIHRvIGJlIG1hcHBlZCBhcyBNVF9OT05fQ0FDSEVBQkxFIGlu
IGFsbCBjYXNlcy4NCj4gSXMgdGhhdCBwYXJ0IG9mIHRoZSBzcGVjPw0KDQpJdCdzIG5vdCBleGFj
dGx5LCBmb3Igc2hhcmVkIG1lbW9yeSB0cmFuc3BvcnQgdGhlcmUgYXJlIHRoZSBmb2xsb3dpbmcN
Cm5vdGVzIGluIERFTjAwNTZFIHNwZWM6DQoNCjUuMS4xIC0gIlRoZSBjYWxsZXIgbXVzdCBlbnN1
cmUgdGhlIGFwcHJvcHJpYXRlIG9yZGVyaW5nIG9mIG1lbW9yeQ0Kb3BlcmF0aW9ucyBzbyB0aGF0
IGFsbCB1cGRhdGVzIHRvIHRoZSBzaGFyZWQNCm1lbW9yeSBtdXN0IGJlIHZpc2libGUgdG8gdGhl
IGNhbGxlZSBiZWZvcmUgcmluZ2luZyB0aGUgZG9vcmJlbGwuDQpFcXVhbGx5LCB0aGUgY2FsbGVl
IG11c3QgZW5zdXJlIHRoYXQgYWxsDQpzaGFyZWQgbWVtb3J5IGNoYW5nZXMgYXJlIHZpc2libGUg
dG8gdGhlIGNhbGxlciBiZWZvcmUgdXBkYXRpbmcgdGhlIHN0YXR1cy4iDQoNCkFzIHdhcyBzdGF0
ZWQgYmVmb3JlLCBhbGwga25vd24gKHRvIHVzKSBTQ01JIGNsaWVudCBleHBlY3RpbmcgU0NNSSBz
aG1lbQ0KdG8gYmUgbWFwcGVkIGFzIE5PTi1DQUNIQUJMRS4NCg0KQnV0IHRoZSBTQ01JIHNwZWNp
ZmljYXRpb24gaW5jbHVkZXMgbWFwcGluZyBpbmZvcm1hdGlvbiBzcGVjaWZpY2FsbHkgZm9yDQpG
YXN0Q2hhbm5lbHMsIHNlbnNvcnMsIHBlcmZvcm1hbmNlLA0KDQphbmQgcG93ZXIgc2hhcmVkIG1l
bW9yeSAod2hpY2ggYXJlIG5vdCBjdXJyZW50bHkgc3VwcG9ydGVkIGluIFhlbi1TQ01JKToNCg0K
DQpERU4wMDU2LiA1LjMgRmFzdENoYW5uZWxzIG11c3QgYmUgbWFwcGVkIGFzIG5vbi1jYWNoZWQg
LSB3ZSBkb24ndCB1c2UgaXQNCmluIHhlbg0KDQo0LjcuNSBTZW5zb3IgVmFsdWVzIFNoYXJlZCBN
ZW1vcnkgLSAiVGhlIG1lbW9yeSBtdXN0IGJlIGFjY2Vzc2libGUgZnJvbQ0KdGhlIE5vbi1zZWN1
cmUgd29ybGQsIGFuZCBPU1BNIG11c3QgbWFwIGl0IGFzIG5vbi1jYWNoZWQgbm9ybWFsIG1lbW9y
eQ0Kb3IgZGV2aWNlIG1lbW9yeS4iDQoNCjQuNS41IFBlcmZvcm1hbmNlIGRvbWFpbiBzdGF0aXN0
aWNzIHNoYXJlZCBtZW1vcnkgcmVnaW9uIC0gInRoZSBzaGFyZWQNCm1lbW9yeSBtdXN0IGJlIGFj
Y2Vzc2libGUgZnJvbSB0aGUgTm9uLXNlY3VyZSB3b3JsZCBhbmQgbXVzdCBiZSBtYXBwZWQgYXMN
Cm5vbi1jYWNoZWQgbm9ybWFsIG1lbW9yeSBvciBkZXZpY2UgbWVtb3J5LiINCg0KNC4zLjQgKlBv
d2VyIHN0YXRlIHN0YXRpc3RpY3Mgc2hhcmVkIG1lbW9yeSByZWdpb24gLSAqVGhlIG1lbW9yeSBt
dXN0IGJlDQphY2Nlc3NpYmxlIGZyb20gdGhlIE5vbi1zZWN1cmUgd29ybGQsIGFuZCBPU1BNIG11
c3QgbWFwIGl0IGFzIG5vbi1jYWNoZWQNCm5vcm1hbCBtZW1vcnkgb3INCmRldmljZSBtZW1vcnkN
Cg0KDQo+PiBUaGUgTGludXggZG9lcyBkZXZtX2lvcmVtYXAoKSAtPiBpb3JlbWFwKCkgLT4NCj4+
IChBUk02NCkgIF9faW9yZW1hcCgoYWRkciksIChzaXplKSwgX19wZ3Byb3QoUFJPVF9ERVZJQ0Vf
bkduUkUpKQ0KPj4NCj4+IFRoZXJlIGlzIGFsc28gbm90ZSBpbiBkb2NzOg0KPj4gIistIHNobWVt
OiBzaGFyZWQgbWVtb3J5IGZvciBtZXNzYWdlcyB0cmFuc2ZlciwgKipYZW4gcGFnZSBhbGlnbmVk
Kiogd2l0aA0KPj4gbWFwcGluZ2BgcDJtX21taW9fZGlyZWN0X25jYGAuIg0KPj4NCj4+IEluIHRo
ZSBjYXNlIG9mIFNDUCAtIHRoZSBTQ01JIHNobWVtIGNhbiBiZSBhY3R1YWxseSBiZSBpbiBTUkFN
Lg0KPj4NCj4+IFNvLCBhcmUgeW91IHN1cmUgY2FjaGUgbWFuaXB1bGF0aW9ucyBhcmUgcmVxdWly
ZWQgaGVyZT8NCj4gTm8sIGlmIHRoZSBtZW1vcnkgaXMgbWFwcGVkIGFzIHVuY2FjaGVhYmxlIGV2
ZXJ5d2hlcmUgdGhlbiB0aGUgY2FjaGUNCj4gbWFuaXB1bGF0aW9ucyBhcmUgbm90IG5lZWRlZC4g
SG93ZXZlciwgd2UgcHJvYmFibHkgc3RpbGwgbmVlZCBhIGRzYi4NCj4NCj4gSSB1bmRlcnN0YW5k
IG5vdyB3aHkgdGhleSBkZWNpZGVkIHRvIHVzZSBfX21lbWNweV9mcm9taW8gaW4gTGludXg6IGl0
IGlzDQo+IG5vdCBNTUlPIGJ1dCB0aGV5IG5lZWRlZCBhIG1lbWNweSBmb2xsb3dlZCBieSBEU0Is
IHNvIHRoZXkgZGVjaWRlZCB0bw0KPiByZXVzZSB0aGUgZXhpc3RpbmcgTU1JTyBmdW5jdGlvbnMg
YWx0aG91Z2ggdGhlIGJ1ZmZlciBpcyBub3QgTU1JTy4NCj4NCj4gSW4gWGVuIEkgd291bGQgcHJl
ZmVyIHdlIGp1c3QgdXNlZCBtZW1jcHkgZm9sbG93ZWQgYnkgRFNCLiBUaGUgb3Bpbmlvbg0KPiBv
ZiBvdGhlciBtYWludGFpbmVycyBpcyB2ZXJ5IHdlbGNvbWUuDQoNCg0KSXQgc291bmRzIHJlYXNv
bmFibGUuIEkgY2FuIHVwZGF0ZSBpdCBhcyB0aGUgZm9sbG93aW5nLCBmb3IgZXhhbXBsZToNCg0K
YGBgDQoNCmRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1zaG1lbS5jDQpi
L3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNobWVtLmMNCmluZGV4IGRkNjEzZWUwYjUuLjI1
MmQ3MDYwOWMgMTAwNjQ0DQotLS0gYS94ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1zaG1lbS5j
DQorKysgYi94ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1zaG1lbS5jDQpAQCAtOTcsMTQgKzk3
LDE2IEBAIGludCBzaG1lbV9wdXRfbWVzc2FnZSh2b2xhdGlsZSBzdHJ1Y3QNCnNjbWlfc2hhcmVk
X21lbSBfX2lvbWVtICpzaG1lbSwNCiAgICAgIGlmICggcmV0ICkNCiAgICAgICAgICByZXR1cm4g
cmV0Ow0KDQotICAgIHdyaXRlbF9yZWxheGVkKDB4MCwgJnNobWVtLT5jaGFubmVsX3N0YXR1cyk7
DQorICAgIHNobWVtLT5jaGFubmVsX3N0YXR1cyA9IDB4MDsNCiAgICAgIC8qIFdyaXRpbmcgMHgw
IHJpZ2h0IG5vdywgYnV0ICJzaG1lbSJfRkxBR19JTlRSX0VOQUJMRUQgY2FuIGJlIHNldCAqLw0K
LSAgICB3cml0ZWxfcmVsYXhlZCgweDAsICZzaG1lbS0+ZmxhZ3MpOw0KLSAgICB3cml0ZWxfcmVs
YXhlZChzaXplb2Yoc2htZW0tPm1zZ19oZWFkZXIpICsgbGVuLCAmc2htZW0tPmxlbmd0aCk7DQot
ICAgIHdyaXRlbChwYWNrX3NjbWlfaGVhZGVyKGhkciksICZzaG1lbS0+bXNnX2hlYWRlcik7DQor
ICAgIHNobWVtLT5mbGFncyA9IDB4MDsNCisgICAgc2htZW0tPmxlbmd0aCA9IHNpemVvZihzaG1l
bS0+bXNnX2hlYWRlcikgKyBsZW47DQorICAgIHNobWVtLT5tc2dfaGVhZGVyID0gcGFja19zY21p
X2hlYWRlcihoZHIpOw0KDQogICAgICBpZiAoIGxlbiA+IDAgJiYgZGF0YSApDQotICAgICAgICBf
X21lbWNweV90b2lvKHNobWVtLT5tc2dfcGF5bG9hZCwgZGF0YSwgbGVuKTsNCisgICAgICAgIG1l
bWNweShzaG1lbS0+bXNnX3BheWxvYWQsIGRhdGEsIGxlbik7DQorDQorICAgIHdtYigpOw0KDQog
ICAgICByZXR1cm4gMDsNCiAgfQ0KQEAgLTE1Nyw3ICsxNTksOSBAQCBpbnQgc2htZW1fZ2V0X3Jl
c3BvbnNlKGNvbnN0IHZvbGF0aWxlIHN0cnVjdA0Kc2NtaV9zaGFyZWRfbWVtIF9faW9tZW0gKnNo
bWVtLA0KICAgICAgfQ0KDQogICAgICBpZiAoIHJlY3ZfbGVuID4gMCApDQotICAgICAgICBfX21l
bWNweV9mcm9taW8oZGF0YSwgc2htZW0tPm1zZ19wYXlsb2FkICsgcGFkLCByZWN2X2xlbik7DQor
ICAgICAgICBtZW1jcHkoZGF0YSwgc2htZW0tPm1zZ19wYXlsb2FkICsgcGFkLCByZWN2X2xlbik7
DQorDQorICAgIHJtYigpOw0KDQogICAgICByZXR1cm4gMDsNCiAgfQ0KDQpgYGANCg==


From xen-devel-bounces@lists.xenproject.org Thu Jun 19 16:15:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 16:15:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020225.1396581 (Exim 4.92)
	(envelope-from )
	id 1uSHuy-0005ol-F8; Thu, 19 Jun 2025 16:15:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020225.1396581; Thu, 19 Jun 2025 16:15: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 1uSHuy-0005oe-CB; Thu, 19 Jun 2025 16:15:12 +0000
Received: by outflank-mailman (input) for mailman id 1020225;
 Thu, 19 Jun 2025 16:15: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 1uSHuw-0005oY-6p
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 16:15:10 +0000
Received: from AS8PR04CU009.outbound.protection.outlook.com
 (mail-westeuropeazlp170110003.outbound.protection.outlook.com
 [2a01:111:f403:c201::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 914dcfb1-4d28-11f0-a30d-13f23c93f187;
 Thu, 19 Jun 2025 18:15:08 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by DB8PR03MB6332.eurprd03.prod.outlook.com (2603:10a6:10:13d::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.19; Thu, 19 Jun
 2025 16:15:04 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%4]) with mapi id 15.20.8835.023; Thu, 19 Jun 2025
 16:15: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: 914dcfb1-4d28-11f0-a30d-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=gVfFDr/wp9BFREYysapAGUmZQ1jYjFldRtVo7LUHd3Cbp0RtxykqBJdcibMrQrNOc+aD1w4RfLY4a9jU2nlvpE9DnykAls8tp5pfCCL/RI6OQ4zUCh1TlrEVbsdpRNC8cPHKeCfIk4K2kAc09EmArKYgcGSzzW5DkN7QZrPx0PAay9Is5U3J8g9GRK3tR+9O4KUjVTEvur9BvwIKCOZBX1BfXHsLdCZyfy9auHDfhOUJsYEYNBYsj2dX9Iv1mmR3oRY0/1EhZp8UwFQzbujFfIuNvoKtONfLlIaei2M3jwiO5WxHHtSVgAn/ilcpiK5LIY/5K6ZPTlVy3PRjpVdsUA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=dwL+K31ygkH5553KNK8FHBO7f16OZl/j33ruhuwd7EI=;
 b=VqFzJYv9gSr/Hpsk1c+EfnxkbYUZDMJFcXeQmJqH9BW4frRTyyQRPrmsE88J5ciOFVgV7a51tDvhKhQ8vHPcWgJ3YGq+/x3mN7n41AKgzFhdEo24J3yz1PSY001C1FHLTMxF2/6Hu7Zf/XlXOL7ZIriPB2obs+9l0kJG2ScLvlj1khf9NvxHHs4k0CNQtz57Wx1f5xG5lVL3h8mGtuQYK8/Qf1dEjU71DHCP6Ias7D3TOEr+3QG+Q35aqu5qTY7T67bwnRMQhevwqyunXzEs/oiAtCD45lCI8HTDIivKoaWd1RGSaFd7EE0vOuA+thc6aUpZuCDuor39zyLQFEgceA==
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=dwL+K31ygkH5553KNK8FHBO7f16OZl/j33ruhuwd7EI=;
 b=fFnb9X4uoKMGJJpzqFVLah+jOb26tZrcyukFkksmRuklbR1hbqT2klEwwujK8lWi66xEGqSmrIjzW8QoE9zsOJNVYVlhefRofnaIIO5LnQKPlVhGavqrE6pZ2CGcAfW4sO1wUBQD7wKZkiEprpMZuHFfeeJlS//Zof6E+xUL6quhiyiBAjJFsW36Sl79xPsROxtKKmWKbvNNw6LDFeRKK+w2dq1Ow1C+xVYJNGjrhscqKfJh00MTKYS2Kud0MTUP2R4bZlFsAXKt+nBY/0g6uRkzF3dhX0hUSq9q/u29lORn7U/Vt+25kiED/d6ykkqCy1q8lJFq6ALGk4eUrVvBTQ==
From: Oleksii Moisieiev 
To: Stefano Stabellini 
CC: "xen-devel@lists.xenproject.org" , Andrew
 Cooper , Anthony PERARD
	, Bertrand Marquis , Jan
 Beulich , Juergen Gross , Julien Grall
	, Michal Orzel ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Volodymyr
 Babchuk , Grygorii Strashko
	
Subject: Re: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC
 multi-agent driver
Thread-Topic: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC
 multi-agent driver
Thread-Index: AQHbyNXPHUV4T01ZEEC9Uxm0LaLKHbPgqpIAgB7nygCACJlwgIACrSiA
Date: Thu, 19 Jun 2025 16:15:04 +0000
Message-ID: <769aad0a-8bee-45c6-8c5c-35f9d47ed8ae@epam.com>
References: 
 <318044ae12f13b6b297b3f5fda577a1a6cd143da.1747669845.git.oleksii_moisieiev@epam.com>
 
 <6080ff71-2634-4269-8a63-fdafdf03f01b@epam.com>
 
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: PAVPR03MB8946:EE_|DB8PR03MB6332:EE_
x-ms-office365-filtering-correlation-id: bce938f2-2a83-4863-ba98-08ddaf4c7386
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|376014|366016|7416014|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?dzluK2lzWFRHMGdvbW5VRWpQM1lEMm1Cb1ZpVk84Tkk4UXd5TStvVlVhWmQw?=
 =?utf-8?B?K0JQOTQreXl2OWJnajQ3VkErTGNCb1hSUFIvNHdJZmdERkNDZ25mTmgreVQ5?=
 =?utf-8?B?dEkvb1Rsak94WmsydGtXNVZNZm8yY3VBbWh3ZjlqdENiQ004Z0ZTSjNYSG5z?=
 =?utf-8?B?bFhiei9OZWk1WFlFMnluVHBvdUJNdDZXaERNZExhKyt3VDFOREpFc3pGdUN6?=
 =?utf-8?B?Ly9uUVBvRGd0V292YTBjL2t0MHZxK2JxL1crLzdQNktla3VsUmZTbWQya1hu?=
 =?utf-8?B?T3V3elZzVGxUMnVNeW1vMER0Y1BLd0luMWFZTVU0bXdMRDFVanZZSzBXdGRZ?=
 =?utf-8?B?eEhXOE9qRTJrZHNXK3Y1dVVPNUVOZUZNWW9zN3I4VVQrOG1SZmovd3pselU1?=
 =?utf-8?B?bURHN1k0VTNScmVTeUNCN0IySm5OOUMvcFJucmZMQURJMkJxUXB2Wk1sSHlU?=
 =?utf-8?B?ME5QVjRjN1pTZ2dPM1UvQVAzYVlQR2hMdXU3OFZZdVMwcGRQaXhKVmhkdU03?=
 =?utf-8?B?TnlJdFVkVVpyVGczNE1yWFZjMHRRSVZpZEJvbG9CMWZjZkp1a3pBVU9xOHhk?=
 =?utf-8?B?a3J4OTM5N0NtZTdHelVzdXlGb0lsb3J3RDFlQXFOdFMxUjE4cmlUYkZ0WU1k?=
 =?utf-8?B?SmVOYzUzM2VNZ0pzTmlKZHJjK2pKcUplYjYzNlNzQmRUQUxSY1ZUeC8yT3ky?=
 =?utf-8?B?Zy85YjZpL24zNGNKb213TDRJeUI2cEJpMnBJSDVwS3d0RWgzU2MzeXc4Qkxn?=
 =?utf-8?B?K0pZRGZuRFhUcTNtQzIva0FLeksvS0NTYnB4Q1ZYaWQ0RnM5ZTc5djFRNXVS?=
 =?utf-8?B?QnJraCtKaHJLQWRIbjFqMEhZSmpPai9Fek1ZeS9scHBCSTAvNlhZTlB2SFgz?=
 =?utf-8?B?THllSnNkRnNVZFRvcHBpWTQ1Uy9MK2ZtVjVPUFJpZk9WVjJaeE11bGlocmJ3?=
 =?utf-8?B?N0RQQmlqckUzNmF1YU9JQnEwVDNvQm1NakFhS1B4TGxuclE0Z214bCtDRVNI?=
 =?utf-8?B?N1JCWC9yZE12d1MzT0h3b2RvU0NoeCt4eDAwZHo2MkdjUnNBT1FLK0pPMSt5?=
 =?utf-8?B?eFgvd0V4TjNZa1VYcEVHanJCK21xUndJbmhKQ1BvNFMyeVJhM283RGF5N1A5?=
 =?utf-8?B?WXh5eVRqdVY3MERWekp2RGIra0tYRG93STZZNFQ0c3c4UDR2Y25ZTFF1RlJi?=
 =?utf-8?B?dDlQbzdiMnRzenZTSzFVMVVjbEpjMGlTakJiVlN6QmZuMzVWb2lwRGRqZnZu?=
 =?utf-8?B?eHRlY0diZ2lMcU1YSzN5N2RFTTdOaVFqRzJWdWt0Wkp0eElIMnQ5OHQvMzMv?=
 =?utf-8?B?RkxFVmEwejAxb0M1YUpsTlBrV3lrK29xVmhNZ3lGaDd5WjFHT0dFTlVpOFFZ?=
 =?utf-8?B?YnF5ODRHSWQwY282Y3hEZDZ6aHpPYWFjeDVNcFFJbERwWVlYcC9UVVBWQUFw?=
 =?utf-8?B?dFlWNHByeW1oMmZ5UGFMMkI4Yi9UOFlJSk90ZGRZWEFoWHVSTFFPV0Z0RUdy?=
 =?utf-8?B?QURnME9URzdIUTdsU2dnUjZTNUVuWnFiK2hNT2FEeU5iejZ4OGxzZU5ObW9H?=
 =?utf-8?B?VU1TdXMrUW1JcXNUZGh5Um5Cdk9raTBMdWdZUFMrTEpJL1ZkanVxSmJkb1B1?=
 =?utf-8?B?VHlVbzkrdURpeHFhYnR1QjZOMHQrSVB3endSRWxLZlNoV2VaYUxiRTZMa0hX?=
 =?utf-8?B?clk2Tk5EMUgzYmVZdU9HU1VQZDltMFppSjN0am9TQmZ4Zi81TWRkWFl4SzdZ?=
 =?utf-8?B?UjFubGR0aGxqUDIxVVlmKzRDd2FGOVhmejdEVWJ3eEtGc2NMMFFqQWlhWURF?=
 =?utf-8?B?NllZZC9pYlN0bEMzSnpiNUpFLzRpakMrL0hjNHM2RmhSdkZIUnBWRTJab0p4?=
 =?utf-8?B?NHB5cUN3Tm40UzJzT0dEU2NKZTBjRU5RY2xFUmc3azZvZGpCUkhxWDI0dWEy?=
 =?utf-8?Q?C2MrE1LuseA=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7416014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?cDUxWmY0bmJzSllmeVkxOGxqbHJzR1p1UmFYN0g5bVNXQ042QTY3cmh3LzF5?=
 =?utf-8?B?OFc2VEFvWDZsVW42OUxqZUVWakxDQ1NDTk9DemVPcnU3cGM0c0ZPNDZRak9C?=
 =?utf-8?B?UXBpQTdOcXN3ZW9SR0dHSDZRVEp5bjRqRG00MjRCa0d5RDU2S0plcldNcno1?=
 =?utf-8?B?NktERHlGdDdEa0lPa2thekcweTlBY3J5RmRjRTNlNUZpbldQZUVkcEhYL1Qx?=
 =?utf-8?B?eFBIanZaYlJTazJuSXNFeTBpN0I5Sk9sZW9vaTg2U3pXT1VqNWQzZEpHVkdI?=
 =?utf-8?B?SkkxcStleXJXbVo1UnpxLzVDS0thZ2tGNkErQndTOHBOSTB3aXdtcVZHaGZp?=
 =?utf-8?B?VjdvMFJoOSt2NHRhT2NtQjR4QW9hLzRVL0pPZ0hMK0xjd2JPYkpUODQzYVBM?=
 =?utf-8?B?VXI4MnJFdjJVdFBsQVgreG45WVpPMUROaWFWN3NINGYxQkQraWJlRGtvUmUr?=
 =?utf-8?B?RTdScStrV0o3bXF5VTEvSmUrRkxxd05HWWExbkNpNUpkNXlzQm5iekZWMUlH?=
 =?utf-8?B?cVJZYWpjNWJyK2kzd01xOHN5SWdrbURwSWUxRGxpSkZXNzBiL0hkVmxtTDB5?=
 =?utf-8?B?YXJ0ZlpDKy9ET3FNb1dId0Fsa1UrYm9tSTRkcHNTM1lONFdNY3Y0SjFvbmYz?=
 =?utf-8?B?OWJZeEdXdnMwY2VVYjZuWWUwbmthSWswVURmM1JYSjNuMDcraFQxVXhXMWNF?=
 =?utf-8?B?UHpYcEJWRmJQQk9teGNndjFJQ3VaRnhHemNtblJoNnVHeTJCd1UvcEZiTGox?=
 =?utf-8?B?VmtzRE1vWjRKaFA2dCsxbHRpQ1U5VS8yRTEvcE9DejhrdUtjYm9Ec3NwQVlm?=
 =?utf-8?B?blAzWXF4a3VWaEIwdVdFazdJS1ZUUEdKeFlNUE9xMmQ5YXRUWXhBSVhzN0Z3?=
 =?utf-8?B?czU0RU91S01OaEREOHRkOEdhZWt0NUNCSTh1alZuVWp6MERqOFZCcXhobnZw?=
 =?utf-8?B?OXZ0aU45dURWQm83NXExdUU0S1k0eVVFYUtKdk5DQStSVEVuS1hTaDJEQnNS?=
 =?utf-8?B?R1BZQ3VPcituaGdQL3UwSzVnRmVGZzBRQW52QlA3bUQzOE1SM2FjNExySFF6?=
 =?utf-8?B?OEc4c1JUb1JLdCt4QVdPMmZQMW51dzNraXFPZ2l4YVNoZFFEek1GSzFLNlY4?=
 =?utf-8?B?VUVSbS9rRFpvUUY5am9VYmtNT01kdnNuZTdJUFdVQTg5WCs4N2wydW5HRytv?=
 =?utf-8?B?Z2J6amFWVU9RQ2s1RU9IVWJVZ2tsdmUydFZLalFUVDlGdi8xVE5iU2Z0LzRQ?=
 =?utf-8?B?eWh2dDB5ODhFNmk5WXNRQnp3RDFBRUpFUHNBSWRIN2JpeGVydUQzSTVoVmU1?=
 =?utf-8?B?ZzBocEJxTjdCRVZ5T0E3ajFCbnVQN0VhM2t6a0NhaWFKdXRCM0lveUlWaTBZ?=
 =?utf-8?B?b1lUWG04R3A4eDhVb0w4VWQ4Z1NvaWk2Rmw0MWtMUUkzU0dubTBzTFpOS3o3?=
 =?utf-8?B?RUFjd3hZMUtlWEFDbHJxMFI3V1hBdFNqcHNGclU4QzVsemt6cTlLdkRlV2p0?=
 =?utf-8?B?U2NVNFZlOTFjRGF2dTZGa2ljNHZBbTk4TEF0VzY5WHpvV2xKMTU1cFRQa1Jt?=
 =?utf-8?B?M0dBYVFNSmVBeEdHRjN1d2lxY3QydS8wN05GNGMyMDJsaEU3MDdvdXhqUDRD?=
 =?utf-8?B?WXJIR09lNDNHeVJ1cHNob1ZTa3FQVU8xa2YxOC9VZCtqL1RLb2QzRWdlS2tt?=
 =?utf-8?B?RVVDUjBLaEg2MkhIOTdNbHo1UUFodDBnZnIwN2E5ODByeW9TQm13YnZxNUFh?=
 =?utf-8?B?U0pkTFdndE9NZUdJZFp2Z1gyQjN1T20wdkxJWVhYRzdNc0JaU2E3b0lUKytL?=
 =?utf-8?B?RFVYaUFhbWwreVRRUHVlVXhwdGtnNkJ4aXpwcTNSNzdUZTVVeGNrdjk2VmJ4?=
 =?utf-8?B?N0tFMWc0Wk43cWxNQkhRZWhxZFJ3UlU1WTI1NUNUek9jVFp1ak4ranZQa3p0?=
 =?utf-8?B?R3c5dmtWUGFRNnFuM3VTTFFkbitjcVVzbHZsaW85OVB1WSs1NHlhbnh0QkVH?=
 =?utf-8?B?bUpiVFhzWDZxeFlNNE83YTJxbEY1eDMvcjFPNWp1Skk1aFdUMWVYMy80VGNI?=
 =?utf-8?B?UktoZVJjVG53Q3RHa1ZaMTJzTE9Nek9XdkJmdk5LZmI0OGI2dGU3b09uQkxk?=
 =?utf-8?B?dHBmSnFXdFRvaGtQeEVwZStPUWNVSFFoWkU5czBiZ2VQMTAwMGRIVlF4TVha?=
 =?utf-8?B?SlE9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <4352BBDC83682D4EA14B5A2319B373CB@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: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bce938f2-2a83-4863-ba98-08ddaf4c7386
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2025 16:15:04.6553
 (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: /sIRcx30wLir5iJtS3Y0YbB9tMfIz+8kvQzXYikBSgoXtHd7zRULnmm4FykzTRnntQBnrD0s7qKgQTnx3Y/E5U2CRuY8YLIdOzd7CwhLB2s=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR03MB6332

DQpPbiAxOC8wNi8yMDI1IDAyOjIyLCBTdGVmYW5vIFN0YWJlbGxpbmkgd3JvdGU6DQo+IE9uIFRo
dSwgMTIgSnVuIDIwMjUsIE9sZWtzaWkgTW9pc2llaWV2IHdyb3RlOg0KPj4gSGkgU3RlZmFubywN
Cj4+DQo+PiBJJ20gdmVyeSBzb3JyeSBmb3IgYSBsb25nIHNpbGVuY2UuIFBsZWFzZSBzZWUgbXkg
YW5zd2VycyBiZWxvdzoNCj4+DQo+Pg0KPj4gT24gMjMvMDUvMjAyNSAyMzowNiwgU3RlZmFubyBT
dGFiZWxsaW5pIHdyb3RlOg0KPj4+IE9uZSBxdWVzdGlvbiBmb3IgQmVydHJhbmQgYmVsb3cNCj4+
Pg0KPj4+DQo+Pj4gT24gTW9uLCAxOSBNYXkgMjAyNSwgT2xla3NpaSBNb2lzaWVpZXYgd3JvdGU6
DQo+Pj4+IFRoaXMgcGF0Y2ggaW50cm9kdWNlcyBTQ0kgZHJpdmVyIHRvIHN1cHBvcnQgZm9yIEFS
TSBFTDMgVHJ1c3RlZCBGaXJtd2FyZS1BDQo+Pj4+IChURi1BKSB3aGljaCBwcm92aWRlcyBTQ01J
IGludGVyZmFjZSB3aXRoIG11bHRpLWFnbmV0IHN1cHBvcnQsIGFzIHNob3duDQo+Pj4+IGJlbG93
Lg0KPj4+Pg0KPj4+PiAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tKw0KPj4+PiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
fA0KPj4+PiAgICAgfCBFTDMgVEYtQSBTQ01JICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K
Pj4+PiAgICAgKy0tLS0tLS0rLS0rLS0tLS0tLSstLSstLS0tLS0tKy0tKy0tLS0tLS0rKw0KPj4+
PiAgICAgfHNobWVtMCB8ICB8c2htZW0xIHwgIHxzaG1lbTIgfCAgfHNobWVtWCB8DQo+Pj4+ICAg
ICArLS0tLS0rLSsgICstLS0rLS0tKyAgKy0tKy0tLS0rICArLS0tKy0tLSsNCj4+Pj4gc21jLWlk
MCB8ICAgICAgICB8ICAgICAgICAgfCAgICAgICAgICAgfA0KPj4+PiBhZ2VudDAgIHwgICAgICAg
IHwgICAgICAgICB8ICAgICAgICAgICB8DQo+Pj4+ICAgICArLS0tLS12LS0tLS0tLS0rLS0tLS0t
LS0tKy0tLS0tLS0tLS0tKy0tLS0rDQo+Pj4+ICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAg
fCAgICAgICAgICAgfCAgICB8DQo+Pj4+ICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgfCAg
ICAgICAgICAgfCAgICB8DQo+Pj4+ICAgICArLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tKy0tLS0t
LS0tLS0tKy0tLS0rDQo+Pj4+ICAgICAgICAgICAgc21jLWlkMSB8ICBzbWMtaWQyfCAgICBzbWMt
aWRYfA0KPj4+PiAgICAgICAgICAgIGFnZW50MSAgfCAgYWdlbnQyIHwgICAgYWdlbnRYIHwNCj4+
Pj4gICAgICAgICAgICAgICAgICAgIHwgICAgICAgICB8ICAgICAgICAgICB8DQo+Pj4+ICAgICAg
ICAgICAgICAgKy0tLS12LS0tKyAgKy0tdi0tLS0tKyAgKy0tdi0tLS0tKw0KPj4+PiAgICAgICAg
ICAgICAgIHwgICAgICAgIHwgIHwgICAgICAgIHwgIHwgICAgICAgIHwNCj4+Pj4gICAgICAgICAg
ICAgICB8IERvbTAgICB8ICB8IERvbTEgICB8ICB8IERvbVggICB8DQo+Pj4+ICAgICAgICAgICAg
ICAgfCAgICAgICAgfCAgfCAgICAgICAgfCAgfCAgICAgICAgfA0KPj4+PiAgICAgICAgICAgICAg
IHwgICAgICAgIHwgIHwgICAgICAgIHwgIHwgICAgICAgIHwNCj4+Pj4gICAgICAgICAgICAgICAr
LS0tLS0tLS0rICArLS0tLS0tLS0rICArLS0tLS0tLS0rDQo+Pj4+DQo+Pj4+IFRoZSBFTDMgU0NN
SSBtdWx0aS1hZ2VudCBmaXJtd2FyZSBleHBlY3RlZCB0byBwcm92aWRlIFNDTUkgU01DL0hWQyBz
aGFyZWQNCj4+Pj4gbWVtb3J5IHRyYW5zcG9ydCBmb3IgZXZlcnkgQWdlbnQgaW4gdGhlIHN5c3Rl
bS4NCj4+Pj4NCj4+Pj4gVGhlIFNDTUkgQWdlbnQgdHJhbnNwb3J0IGNoYW5uZWwgZGVmaW5lZCBi
eSBwYWlyOg0KPj4+PiAgICAtIHNtYy1pZDogU01DL0hWQyBpZCB1c2VkIGZvciBEb29yYmVsbA0K
Pj4+PiAgICAtIHNobWVtOiBzaGFyZWQgbWVtb3J5IGZvciBtZXNzYWdlcyB0cmFuc2ZlciwgWGVu
IHBhZ2UgYWxpZ25lZCwNCj4+Pj4gICAgcDJtX21taW9fZGlyZWN0X25jLg0KPj4+Pg0KPj4+PiBU
aGUgZm9sbHdvaW5nIFNDTUkgQWdlbnRzIGV4cGVjdGVkIHRvIGJlIGRlZmluZWQgYnkgU0NNSSBG
VyB0byBlbmFibGUgU0NNSQ0KPj4+PiBtdWx0aS1hZ2VudCBmdW5jdGlvbmFsaXR5IHVuZGVyIFhl
bjoNCj4+Pj4gLSBYZW4gbWFuZWdlbWVudCBhZ2VudDogdHJ1c3RlZCBhZ2VudHMgdGhhdCBhY2Nl
c3NlcyB0byB0aGUgQmFzZSBQcm90b2NvbA0KPj4+PiBjb21tYW5kcyB0byBjb25maWd1cmUgYWdl
bnQgc3BlY2lmaWMgcGVybWlzc2lvbnMNCj4+Pj4gLSBPU1BNIFZNIGFnZW50czogbm9uLXRydXN0
ZWQgYWdlbnQsIG9uZSBmb3IgZWFjaCBHdWVzdCBkb21haW4gd2hpY2ggaXMNCj4+Pj4gICAgIGFs
bG93ZWQgZGlyZWN0IEhXIGFjY2Vzcy4gQXQgbGVhc3Qgb25lIE9TUE0gVk0gYWdlbnQgaGFzIHRv
IGJlIHByb3ZpZGVkDQo+Pj4+ICAgICBieSBGVyBpZiBIVyBpcyBoYW5kbGVkIG9ubHkgYnkgRG9t
MCBvciBEcml2ZXIgRG9tYWluLg0KPj4+Pg0KPj4+PiBUaGUgRUwzIFNDTUkgRlcgZXhwZWN0ZWQg
dG8gaW1wbGVtZW50IGZvbGxvd2luZyBCYXNlIHByb3RvY29sIG1lc3NhZ2VzOg0KPj4+PiAtIEJB
U0VfRElTQ09WRVJfQUdFTlQNCj4+Pj4gLSBCQVNFX1JFU0VUX0FHRU5UX0NPTkZJR1VSQVRJT04g
KG9wdGlvbmFsKQ0KPj4+PiAtIEJBU0VfU0VUX0RFVklDRV9QRVJNSVNTSU9OUyAob3B0aW9uYWwp
DQo+Pj4+DQo+Pj4+IFRoZSBTQ0kgU0NNSSBTTUMgbXVsdGktYWdlbnQgZHJpdmVyIGltcGxlbWVu
dHMgZm9sbG93aW5nIGZ1bmN0aW9uYWxpdHk6DQo+Pj4+IC0gSXQncyBpbml0aWFsaXplZCBiYXNl
ZCBvbiB0aGUgSG9zdCBEVCBTQ01JIG5vZGUgKG9ubHkgb25lIFNDTUkgaW50ZXJmYWNlDQo+Pj4+
IGlzIHN1cHBvcnRlZCkgd2hpY2ggZGVzY3JpYmVzIFhlbiBtYW5hZ2VtZW50IGFnZW50IFNDTUkg
aW50ZXJmYWNlLg0KPj4+Pg0KPj4+PiBzY21pX3NobV8wIDogc3JhbUA0N2ZmMDAwMCB7DQo+Pj4+
ICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0KPj4+PiAgICAgICByZWcgPSA8
MHgwIDB4NDdmZjAwMDAgMHgwIDB4MTAwMD47DQo+Pj4+IH07DQo+Pj4+IGZpcm13YXJlIHsNCj4+
Pj4gICAgICAgc2NtaTogc2NtaSB7DQo+Pj4+ICAgICAgICAgICBjb21wYXRpYmxlID0gImFybSxz
Y21pLXNtYyI7DQo+Pj4+ICAgICAgICAgICBhcm0sIHNtYyAtIGlkID0gPDB4ODIwMDAwMDI+OyAv
LyBYZW4gbWFuZWdlbWVudCBhZ2VudCBzbWMtaWQNCj4+PiBzb21lIGV4dHJhIHNwYWNlcywgaXQg
bWlnaHQgYmUgYSBjb3B5L3Bhc3RlIGVycm9yDQo+PiArDQo+Pj4+ICAgICAgICAgICBcI2FkZHJl
c3MtY2VsbHMgPSA8IDE+Ow0KPj4+PiAgICAgICAgICAgXCNzaXplLWNlbGxzID0gPCAwPjsNCj4+
Pj4gICAgICAgICAgIFwjYWNjZXNzLWNvbnRyb2xsZXIgLSBjZWxscyA9IDwgMT47DQo+Pj4+ICAg
ICAgICAgICBzaG1lbSA9IDwmc2NtaV9zaG1fMD47IC8vIFhlbiBtYW5lZ2VtZW50IGFnZW50IHNo
bWVtDQo+Pj4+DQo+Pj4+ICAgICAgICAgICBwcm90b2NvbEBYew0KPj4+PiAgICAgICAgICAgfTsN
Cj4+Pj4gICAgICAgfTsNCj4+Pj4gfTsNCj4+Pj4NCj4+Pj4gLSBJdCBvYnRhaW5zIFhlbiBzcGVj
aWZpYyBTQ01JIEFnZW50J3MgY29uZmlndXJhdGlvbiBmcm9tIHRoZSBIb3N0IERULA0KPj4+PiBw
cm9iZXMgQWdlbnRzIGFuZCBidWlsZCBTQ01JIEFnZW50cyBsaXN0OyBUaGUgQWdlbnRzIGNvbmZp
Z3VyYXRpb24gaXMgdGFrZW4gZnJvbToNCj4+Pj4NCj4+Pj4gY2hvc2VuIHsNCj4+Pj4gICAgIHhl
bixzY21pLXNlY29uZGFyeS1hZ2VudHMgPSA8DQo+Pj4+ICAgICAgICAgICAgICAgMSAweDgyMDAw
MDAzICZzY21pX3NobV8xDQo+Pj4+ICAgICAgICAgICAgICAgMiAweDgyMDAwMDA0ICZzY21pX3No
bV8yDQo+Pj4+ICAgICAgICAgICAgICAgMyAweDgyMDAwMDA1ICZzY21pX3NobV8zDQo+Pj4+ICAg
ICAgICAgICAgICAgNCAweDgyMDAwMDA2ICZzY21pX3NobV80PjsNCj4+Pj4gfQ0KPj4+Pg0KPj4+
PiAvew0KPj4+PiAgICAgICBzY21pX3NobV8xOiBzcmFtQDQ3ZmYxMDAwIHsNCj4+Pj4gICAgICAg
ICAgICAgICBjb21wYXRpYmxlID0gImFybSxzY21pLXNobWVtIjsNCj4+Pj4gICAgICAgICAgICAg
ICByZWcgPSA8MHgwIDB4NDdmZjEwMDAgMHgwIDB4MTAwMD47DQo+Pj4+ICAgICAgIH07DQo+Pj4+
ICAgICAgIHNjbWlfc2htXzI6IHNyYW1ANDdmZjIwMDAgew0KPj4+PiAgICAgICAgICAgICAgIGNv
bXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0KPj4+PiAgICAgICAgICAgICAgIHJlZyA9IDww
eDAgMHg0N2ZmMjAwMCAweDAgMHgxMDAwPjsNCj4+Pj4gICAgICAgfTsNCj4+Pj4gICAgICAgc2Nt
aV9zaG1fMzogc3JhbUA0N2ZmMzAwMCB7DQo+Pj4+ICAgICAgICAgICAgICAgY29tcGF0aWJsZSA9
ICJhcm0sc2NtaS1zaG1lbSI7DQo+Pj4+ICAgICAgICAgICAgICAgcmVnID0gPDB4MCAweDQ3ZmYz
MDAwIDB4MCAweDEwMDA+Ow0KPj4+PiAgICAgICB9Ow0KPj4+PiB9DQo+Pj4+ICAgICB3aGVyZSBm
aXJzdCBpdGVtIGlzICJhZ2VudF9pZCIsIHNlY29uZCAtICJhcm0sc21jLWlkIiwgYW5kIHRoaXJk
IC0gImFybSxzY21pLXNobWVtIiBmb3INCj4+Pj4gICAgIHRoaXMgYWdlbnRfaWQuDQo+Pj4+DQo+
Pj4+ICAgICBOb3RlIHRoYXQgWGVuIGlzIHRoZSBvbmx5IG9uZSBlbnRyeSBpbiB0aGUgc3lzdGVt
IHdoaWNoIG5lZWQgdG8ga25vdw0KPj4+PiAgICAgYWJvdXQgU0NNSSBtdWx0aS1hZ2VudCBzdXBw
b3J0Lg0KPj4+Pg0KPj4+PiAtIEl0IGltcGxlbWVudHMgdGhlIFNDSSBzdWJzeXN0ZW0gaW50ZXJm
YWNlIHJlcXVpcmVkIGZvciBjb25maWd1cmluZyBhbmQNCj4+Pj4gZW5hYmxpbmcgU0NNSSBmdW5j
dGlvbmFsaXR5IGZvciBEb20wL2h3ZG9tIGFuZCBHdWVzdCBkb21haW5zLiBUbyBlbmFibGUNCj4+
Pj4gU0NNSSBmdW5jdGlvbmFsaXR5IGZvciBkb21haW4gaXQgaGFzIHRvIGJlIGNvbmZpZ3VyZWQg
d2l0aCB1bmlxdWUgc3VwcG9ydGVkDQo+Pj4+IFNDTUkgQWdlbnRfaWQgYW5kIHVzZSBjb3JyZXNw
b25kaW5nIFNDTUkgU01DL0hWQyBzaGFyZWQgbWVtb3J5IHRyYW5zcG9ydA0KPj4+PiBbc21jLWlk
LCBzaG1lbV0gZGVmaW5lZCBmb3IgdGhpcyBTQ01JIEFnZW50X2lkLg0KPj4+PiAtIE9uY2UgWGVu
IGRvbWFpbiBpcyBjb25maWd1cmVkIGl0IGNhbiBjb21tdW5pY2F0ZSB3aXRoIEVMMyBTQ01JIEZX
Og0KPj4+PiAgICAgLS0gemVyby1jb3B5LCB0aGUgZ3Vlc3QgZG9tYWluIHB1dHMgU0NNSSBtZXNz
YWdlIGluIHNobWVtOw0KPj4+PiAgICAgLS0gdGhlIGd1ZXN0IHRyaWdnZXJzIFNNQy9IVkMgZXhj
ZXB0aW9uIHdpdGggc21jLWlkIChkb29yYmVsbCk7DQo+Pj4+ICAgICAtLSB0aGUgWGVuIGRyaXZl
ciBjYXRjaGVzIGV4Y2VwdGlvbiwgZG8gY2hlY2tzIGFuZCBzeW5jaHJvbm91c2x5IGZvcndhcmRz
DQo+Pj4+ICAgICBpdCB0byBFTDMgRlcuDQo+Pj4+IC0gdGhlIFhlbiBkcml2ZXIgc2VuZHMgQkFT
RV9SRVNFVF9BR0VOVF9DT05GSUdVUkFUSU9OIG1lc3NhZ2UgdG8gWGVuDQo+Pj4+ICAgICBtYW5h
Z2VtZW50IGFnZW50IGNoYW5uZWwgb24gZG9tYWluIGRlc3Ryb3kgZXZlbnQuIFRoaXMgYWxsb3dz
IHRvIHJlc2V0DQo+Pj4+ICAgICByZXNvdXJjZXMgdXNlZCBieSBkb21haW4gYW5kIHNvIGltcGxl
bWVudCB1c2UtY2FzZSBsaWtlIGRvbWFpbiByZWJvb3QuDQo+Pj4+DQo+Pj4+IERvbTAgRW5hYmxl
IFNDTUkgU01DOg0KPj4+PiAgICAtIHBhc3MgZG9tMF9zY21pX2FnZW50X2lkPTxhZ2VudF9pZD4g
aW4gWGVuIGNvbW1hbmQgbGluZS4gaWYgbm90IHByb3ZpZGVkDQo+Pj4+ICAgICAgU0NNSSB3aWxs
IGJlIGRpc2FibGVkIGZvciBEb20wIGFuZCBhbGwgU0NNSSBub2RlcyByZW1vdmVkIGZyb20gRG9t
MCBEVC4NCj4+Pj4gICAgICBUaGUgZHJpdmVyIHVwZGF0ZXMgRG9tMCBEVCBTQ01JIG5vZGUgImFy
bSxzbWMtaWQiIHZhbHVlIGFuZCBmaXggdXAgc2htZW0NCj4+Pj4gICAgICBub2RlIGFjY29yZGlu
ZyB0byBhc3NpZ25lZCBhZ2VudF9pZC4NCj4+Pj4NCj4+Pj4gR3Vlc3QgZG9tYWlucyBlbmFibGUg
U0NNSSBTTUM6DQo+Pj4+ICAgIC0geGwuY2ZnOiBhZGQgY29uZmlndXJhdGlvbiBvcHRpb24gYXMg
YmVsb3cNCj4+Pj4NCj4+Pj4gICAgICBhcm1fc2NpID0gInR5cGU9c2NtaV9zbWNfbXVsdGlhZ2Vu
dCxhZ2VudF9pZD0yIg0KPj4+Pg0KPj4+PiAgICAtIHhsLmNmZzogZW5hYmxlIGFjY2VzcyB0byB0
aGUgImFybSxzY21pLXNobWVtIiB3aGljaCBzaG91bGQgY29ycmVzcG9uZCBhc3NpZ25lZCBhZ2Vu
dF9pZCBmb3INCj4+Pj4gICAgICB0aGUgZG9tYWluLCBmb3IgZXhhbXBsZToNCj4+Pj4NCj4+Pj4g
aW9tZW0gPSBbDQo+Pj4+ICAgICAgICI0N2ZmMiwxQDIyMDAxIiwNCj4+Pj4gXQ0KPj4+IExvb2tp
bmcgYXQgdGhlIGNvZGUgYW5kIHRoZSBjb25maWd1cmF0aW9uIG9wdGlvbnMsIGl0IGxvb2tzIGxp
a2UgaXQgaXMNCj4+PiBwb3NzaWJsZSB0byBtYXAgYSBzY21pLXNobWVtIGNoYW5uZWwgYXQgYSBk
aWZmZXJlbnQgYWRkcmVzcyBmb3IgdGhlDQo+Pj4gZ3Vlc3QuIEl0IHNlZW1zIGxpa2UgaXQgd291
bGQgd29yay4gSXMgdGhhdCBjb3JyZWN0Pw0KPj4+DQo+PiBZZXMgaXQgd2lsbC4gaW4gb3VyIGNh
c2UgYWRkcmVzcyAyMjAwMTAwMCBzaG91bGQgYmUgdGhlIHNhdmUgYXMNCj4+IHNyYW1AMjIwMDEw
MDAgaW4gdGhlIGRvbWFpbiBkZXZpY2UtdHJlZS4NCj4+Pj4gICAgLSBEVDogYWRkIFNDTUkgbm9k
ZXMgdG8gdGhlIERyaXZlciBkb21haW4gcGFydGlhbCBkZXZpY2UgdHJlZSBhcyBpbiB0aGUNCj4+
Pj4gICAgYmVsb3cgZXhhbXBsZS4gVGhlICJhcm0sc21jLWlkIiBzaG91bGQgY29ycmVzcG9uZCBh
c3NpZ25lZCBhZ2VudF9pZCBmb3IgdGhlIGRvbWFpbjoNCj4+Pj4NCj4+Pj4gcGFzc3Rocm91Z2gg
ew0KPj4+PiAgICAgIHNjbWlfc2htXzA6IHNyYW1AMjIwMDEwMDAgew0KPj4+PiAgICAgICAgICBj
b21wYXRpYmxlID0gImFybSxzY21pLXNobWVtIjsNCj4+Pj4gICAgICAgICAgcmVnID0gPDB4MCAw
eDIyMDAxMDAwIDB4MCAweDEwMDA+Ow0KPj4+PiAgICAgIH07DQo+Pj4+DQo+Pj4+ICAgICAgZmly
bXdhcmUgew0KPj4+PiAgICAgICAgICAgY29tcGF0aWJsZSA9ICJzaW1wbGUtYnVzIjsNCj4+Pj4g
ICAgICAgICAgICAgICBzY21pOiBzY21pIHsNCj4+Pj4gICAgICAgICAgICAgICAgICAgY29tcGF0
aWJsZSA9ICJhcm0sc2NtaS1zbWMiOw0KPj4+PiAgICAgICAgICAgICAgICAgICBhcm0sc21jLWlk
ID0gPDB4ODIwMDAwMDQ+Ow0KPj4+PiAgICAgICAgICAgICAgICAgICBzaG1lbSA9IDwmc2NtaV9z
aG1fMD47DQo+Pj4+ICAgICAgICAgICAgICAgICAgIC4uLg0KPj4+PiAgICAgICAgICAgICAgIH0N
Cj4+Pj4gICAgICAgfQ0KPj4+PiB9DQo+Pj4+DQo+Pj4+IFNDTUkgIjQuMi4xLjEgRGV2aWNlIHNw
ZWNpZmljIGFjY2VzcyBjb250cm9sIg0KPj4+Pg0KPj4+PiBUaGUgWEVOIFNDSSBTQ01JIFNNQyBt
dWx0aS1hZ2VudCBkcml2ZXIgcGVyZm9ybXMgImFjY2Vzcy1jb250cm9sbGVyIiBwcm92aWRlciBm
dW5jdGlvbg0KPj4+PiBpbiBjYXNlIEVMMyBTQ01JIEZXIGltcGxlbWVudHMgU0NNSSAiNC4yLjEu
MSBEZXZpY2Ugc3BlY2lmaWMgYWNjZXNzIGNvbnRyb2wiIGFuZCBwcm92aWRlcyB0aGUNCj4+Pj4g
QkFTRV9TRVRfREVWSUNFX1BFUk1JU1NJT05TIGNvbW1hbmQgdG8gY29uZmlndXJlIHRoZSBkZXZp
Y2VzIHRoYXQgYW4gYWdlbnRzIGhhdmUgYWNjZXNzIHRvLg0KPj4+PiBUaGUgRFQgU0NNSSBub2Rl
IHNob3VsZCAiI2FjY2Vzcy1jb250cm9sbGVyLWNlbGxzPTwxPiIgcHJvcGVydHkgYW5kIERUIGRl
dmljZXMgc2hvdWxkIGJlIGJvdW5kDQo+Pj4+IHRvIHRoZSBYZW4gU0NNSS4NCj4+Pj4NCj4+Pj4g
JmkyYzEgew0KPj4+PiAgICAgICBhY2Nlc3MtY29udHJvbGxlcnMgPSA8JnNjbWkgMD47DQo+Pj4+
IH07DQo+Pj4+DQo+Pj4+IFRoZSBEb20wIGFuZCBkb20wbGVzcyBkb21haW5zIERUIGRldmljZXMg
d2lsbCBiZSBwcm9jZXNzZWQgYXV0b21hdGljYWxseSB0aHJvdWdoDQo+Pj4+IHNjaV9hc3NpZ25f
ZHRfZGV2aWNlKCkgY2FsbCwgYnV0IHRvIGFzc2lnbiBTQ01JIGRldmljZXMgZnJvbSB0b29sc3Rh
Y2sgdGhlIHhsLmNmZzoiZHRkZXYiIHByb3BlcnR5DQo+Pj4+IHNoZWxsIGJlIHVzZWQ6DQo+Pj4+
DQo+Pj4+IGR0ZGV2ID0gWw0KPj4+PiAgICAgICAiL3NvYy9pMmNAZTY1MDgwMDAiLA0KPj4+PiBd
DQo+Pj4+DQo+Pj4+IHhsLmNmZzpkdGRldiB3aWxsIGNvbnRhaW4gYWxsIG5vZGVzIHdoaWNoIGFy
ZSB1bmRlciBTQ01JIG1hbmFnZW1lbnQgKG5vdCBvbmx5IHRob3NlIHdoaWNoIGFyZSBiZWhpbmQg
SU9NTVUpLg0KPj4+Pg0KPj4+PiBbMV1odHRwczovL3dlYi5naXQua2VybmVsLm9yZy9wdWIvc2Nt
L2xpbnV4L2tlcm5lbC9naXQvdG9ydmFsZHMvbGludXguZ2l0L3RyZWUvRG9jdW1lbnRhdGlvbi9k
ZXZpY2V0cmVlL2JpbmRpbmdzL2Zpcm13YXJlL2FybSxzY21pLnlhbWwNCj4+Pj4gWzJdaHR0cHM6
Ly93ZWIuZ2l0Lmtlcm5lbC5vcmcvcHViL3NjbS9saW51eC9rZXJuZWwvZ2l0L3RvcnZhbGRzL2xp
bnV4LmdpdC90cmVlL0RvY3VtZW50YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncy9hY2Nlc3MtY29u
dHJvbGxlcnMvYWNjZXNzLWNvbnRyb2xsZXJzLnlhbWwNCj4+Pj4gU2lnbmVkLW9mZi1ieTogT2xl
a3NpaSBNb2lzaWVpZXY8b2xla3NpaV9tb2lzaWVpZXZAZXBhbS5jb20+DQo+Pj4+IFNpZ25lZC1v
ZmYtYnk6IEdyeWdvcmlpIFN0cmFzaGtvPGdyeWdvcmlpX3N0cmFzaGtvQGVwYW0uY29tPg0KPj4+
IFRoYW5rcyBmb3IgdGhlIGxvbmcgZXhwbGFuYXRpb24sIGdyZWF0IHdvcmshIEkgYW0gcmVhbGx5
IGxvb2tpbmcgZm9yd2FyZA0KPj4+IHRvIGhhdmUgdGhpcyBmZWF0dXJlIGluIHRoZSB0cmVlIHNv
b24uDQo+Pj4NCj4+Pg0KPj4+PiAtLS0NCj4+Pj4NCj4+Pj4gQ2hhbmdlcyBpbiB2NDoNCj4+Pj4g
LSB0b29sc3RhY2sgY29tbWVudHMgZnJvbSBBbnRob255IFBFUkFSRA0KPj4+PiAtIGFkZGVkIGRv
bTBsZXNzIHN1cHBvcnQNCj4+Pj4gLSBhZGRlZCBkb2MgZm9yICJ4ZW4sc2NtaS1zZWNvbmRhcnkt
YWdlbnRzIg0KPj4+Pg0KPj4+PiAgICBkb2NzL21hbi94bC5jZmcuNS5wb2QuaW4gICAgICAgICAg
ICAgICAgICAgIHwgIDEzICsNCj4+Pj4gICAgZG9jcy9taXNjL2FybS9kZXZpY2UtdHJlZS9ib290
aW5nLnR4dCAgICAgICB8ICA2MCArKw0KPj4+PiAgICBkb2NzL21pc2MveGVuLWNvbW1hbmQtbGlu
ZS5wYW5kb2MgICAgICAgICAgIHwgICA5ICsNCj4+Pj4gICAgdG9vbHMvbGlicy9saWdodC9saWJ4
bF9hcm0uYyAgICAgICAgICAgICAgICB8ICAgNCArDQo+Pj4+ICAgIHRvb2xzL2xpYnMvbGlnaHQv
bGlieGxfdHlwZXMuaWRsICAgICAgICAgICAgfCAgIDQgKy0NCj4+Pj4gICAgdG9vbHMveGwveGxf
cGFyc2UuYyAgICAgICAgICAgICAgICAgICAgICAgICB8ICAxMiArDQo+Pj4+ICAgIHhlbi9hcmNo
L2FybS9kb20wbGVzcy1idWlsZC5jICAgICAgICAgICAgICAgfCAgMTEgKw0KPj4+PiAgICB4ZW4v
YXJjaC9hcm0vZG9tYWluX2J1aWxkLmMgICAgICAgICAgICAgICAgIHwgICAzICstDQo+Pj4+ICAg
IHhlbi9hcmNoL2FybS9maXJtd2FyZS9LY29uZmlnICAgICAgICAgICAgICAgfCAgMTEgKw0KPj4+
PiAgICB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvTWFrZWZpbGUgICAgICAgICAgICAgIHwgICAxICsN
Cj4+Pj4gICAgeGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktcHJvdG8uaCAgICAgICAgICB8IDE2
NCArKysrDQo+Pj4+ICAgIHhlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNobWVtLmMgICAgICAg
ICAgfCAxNzMgKysrKw0KPj4+PiAgICB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1zaG1lbS5o
ICAgICAgICAgIHwgIDQ1ICsNCj4+Pj4gICAgeGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktc21j
LW11bHRpYWdlbnQuYyB8IDg2MCArKysrKysrKysrKysrKysrKysrKw0KPj4+PiAgICB4ZW4vaW5j
bHVkZS9wdWJsaWMvYXJjaC1hcm0uaCAgICAgICAgICAgICAgIHwgICAzICsNCj4+Pj4gICAgMTUg
ZmlsZXMgY2hhbmdlZCwgMTM3MSBpbnNlcnRpb25zKCspLCAyIGRlbGV0aW9ucygtKQ0KPj4+PiAg
ICBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktcHJvdG8uaA0K
Pj4+PiAgICBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktc2ht
ZW0uYw0KPj4+PiAgICBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2FyY2gvYXJtL2Zpcm13YXJlL3Nj
bWktc2htZW0uaA0KPj4+PiAgICBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2FyY2gvYXJtL2Zpcm13
YXJlL3NjbWktc21jLW11bHRpYWdlbnQuYw0KPj4+Pg0KPj4+PiBkaWZmIC0tZ2l0IGEvZG9jcy9t
YW4veGwuY2ZnLjUucG9kLmluIGIvZG9jcy9tYW4veGwuY2ZnLjUucG9kLmluDQo+Pj4+IGluZGV4
IDFjY2Y1MGI4ZWEuLjMwMmM0NmQ4YmMgMTAwNjQ0DQo+Pj4+IC0tLSBhL2RvY3MvbWFuL3hsLmNm
Zy41LnBvZC5pbg0KPj4+PiArKysgYi9kb2NzL21hbi94bC5jZmcuNS5wb2QuaW4NCj4+Pj4gQEAg
LTMxMjIsOCArMzEyMiwyMSBAQCBzaW5nbGUgU0NNSSBPU1BNIGFnZW50IHN1cHBvcnQuDQo+Pj4+
ICAgIFNob3VsZCBiZSB1c2VkIHRvZ2V0aGVyIHdpdGggQjxkb20wX3NjbWlfc21jX3Bhc3N0aHJv
dWdoPiBYZW4gY29tbWFuZCBsaW5lDQo+Pj4+ICAgIG9wdGlvbi4NCj4+Pj4NCj4+Pj4gKz1pdGVt
IEI8c2NtaV9zbWNfbXVsdGlhZ2VudD4NCj4+Pj4gKw0KPj4+PiArRW5hYmxlcyBBUk0gU0NNSSBT
TUMgbXVsdGktYWdlbnQgc3VwcG9ydCBmb3IgdGhlIGd1ZXN0IGJ5IGVuYWJsaW5nIFNDTUkgb3Zl
cg0KPj4+PiArU01DIGNhbGxzIGZvcndhcmRpbmcgZnJvbSBkb21haW4gdG8gdGhlIEVMMyBmaXJt
d2FyZSAobGlrZSBUcnVzdGVkIEZpcm13YXJlLUEpDQo+Pj4+ICt3aXRoIGEgbXVsdGkgU0NNSSBP
U1BNIGFnZW50IHN1cHBvcnQuIFRoZSBTQ01JIEI8YWdlbnRfaWQ+IHNob3VsZCBiZQ0KPj4+PiAr
c3BlY2lmaWVkIGZvciB0aGUgZ3Vlc3QuDQo+Pj4+ICsNCj4+Pj4gICAgPWJhY2sNCj4+Pj4NCj4+
Pj4gKz1pdGVtIEI8YWdlbnRfaWQ9TlVNQkVSPg0KPj4+PiArDQo+Pj4+ICtTcGVjaWZpZXMgYSBu
b24temVybyBBUk0gU0NJIGFnZW50IGlkIGZvciB0aGUgZ3Vlc3QuIFRoaXMgb3B0aW9uIGlzIG1h
bmRhdG9yeQ0KPj4+PiAraWYgdGhlIFNDTUkgU01DIHN1cHBvcnQgaXMgZW5hYmxlZCBmb3IgdGhl
IGd1ZXN0LiBUaGUgYWdlbnQgaWRzIG9mIGRvbWFpbnMNCj4+Pj4gK2V4aXN0aW5nIG9uIGEgc2lu
Z2xlIGhvc3QgbXVzdCBiZSB1bmlxdWUgYW5kIGluIHRoZSByYW5nZSBbMS4uMjU1XS4NCj4+Pj4g
Kw0KPj4+PiAgICA9YmFjaw0KPj4+Pg0KPj4+PiAgICA9YmFjaw0KPj4+PiBkaWZmIC0tZ2l0IGEv
ZG9jcy9taXNjL2FybS9kZXZpY2UtdHJlZS9ib290aW5nLnR4dCBiL2RvY3MvbWlzYy9hcm0vZGV2
aWNlLXRyZWUvYm9vdGluZy50eHQNCj4+Pj4gaW5kZXggODk0M2MwNDE3My4uYzg5MjNhYjhiMiAx
MDA2NDQNCj4+Pj4gLS0tIGEvZG9jcy9taXNjL2FybS9kZXZpY2UtdHJlZS9ib290aW5nLnR4dA0K
Pj4+PiArKysgYi9kb2NzL21pc2MvYXJtL2RldmljZS10cmVlL2Jvb3RpbmcudHh0DQo+Pj4+IEBA
IC0yOTYsNiArMjk2LDIwIEBAIHdpdGggdGhlIGZvbGxvd2luZyBwcm9wZXJ0aWVzOg0KPj4+PiAg
ICAgICAgU2hvdWxkIGJlIHVzZWQgdG9nZXRoZXIgd2l0aCBkb20wX3NjbWlfc21jX3Bhc3N0aHJv
dWdoIFhlbiBjb21tYW5kIGxpbmUNCj4+Pj4gICAgICAgIG9wdGlvbi4NCj4+Pj4NCj4+Pj4gKyAg
ICAtICJzY21pX3NtY19tdWx0aWFnZW50Ig0KPj4+PiArDQo+Pj4+ICsgICAgRW5hYmxlcyBBUk0g
U0NNSSBTTUMgbXVsdGktYWdlbnQgc3VwcG9ydCBmb3IgdGhlIGd1ZXN0IGJ5IGVuYWJsaW5nIFND
TUkgb3Zlcg0KPj4+PiArICAgIFNNQyBjYWxscyBmb3J3YXJkaW5nIGZyb20gZG9tYWluIHRvIHRo
ZSBFTDMgZmlybXdhcmUgKGxpa2UgQVJNDQo+Pj4+ICsgICAgVHJ1c3RlZCBGaXJtd2FyZS1BKSB3
aXRoIGEgbXVsdGkgU0NNSSBPU1BNIGFnZW50IHN1cHBvcnQuDQo+Pj4+ICsgICAgVGhlIFNDTUkg
YWdlbnRfaWQgc2hvdWxkIGJlIHNwZWNpZmllZCBmb3IgdGhlIGd1ZXN0IHdpdGggInhlbixzY2lf
YWdlbnRfaWQiDQo+Pj4+ICsgICAgcHJvcGVydHkuDQo+Pj4+ICsNCj4+Pj4gKy0gInhlbixzY2lf
YWdlbnRfaWQiDQo+Pj4+ICsNCj4+Pj4gKyAgICBTcGVjaWZpZXMgYSBub24temVybyBBUk0gU0NJ
IGFnZW50IGlkIGZvciB0aGUgZ3Vlc3QuIFRoaXMgb3B0aW9uIGlzDQo+Pj4+ICsgICAgbWFuZGF0
b3J5IGlmIHRoZSBTQ01JIFNNQyAic2NtaV9zbWNfbXVsdGlhZ2VudCIgc3VwcG9ydCBpcyBlbmFi
bGVkIGZvcg0KPj4+PiArICAgIHRoZSBndWVzdC4gVGhlIGFnZW50IGlkcyBvZiBndWVzdCBtdXN0
IGJlIHVuaXF1ZSBhbmQgaW4gdGhlIHJhbmdlIFsxLi4yNTVdLg0KPj4+PiArDQo+Pj4+ICAgIFVu
ZGVyIHRoZSAieGVuLGRvbWFpbiIgY29tcGF0aWJsZSBub2RlLCBvbmUgb3IgbW9yZSBzdWItbm9k
ZXMgYXJlIHByZXNlbnQNCj4+Pj4gICAgZm9yIHRoZSBEb21VIGtlcm5lbCBhbmQgcmFtZGlzay4N
Cj4+Pj4NCj4+Pj4gQEAgLTc2NCwzICs3NzgsNDkgQEAgVGhlIGF1dG9tYXRpY2FsbHkgYWxsb2Nh
dGVkIHN0YXRpYyBzaGFyZWQgbWVtb3J5IHdpbGwgZ2V0IG1hcHBlZCBhdA0KPj4+PiAgICAweDgw
MDAwMDAwIGluIERvbVUxIGd1ZXN0IHBoeXNpY2FsIGFkZHJlc3Mgc3BhY2UsIGFuZCBhdCAweDkw
MDAwMDAwIGluIERvbVUyDQo+Pj4+ICAgIGd1ZXN0IHBoeXNpY2FsIGFkZHJlc3Mgc3BhY2UuIERv
bVUxIGlzIGV4cGxpY2l0bHkgZGVmaW5lZCBhcyB0aGUgb3duZXIgZG9tYWluLA0KPj4+PiAgICBh
bmQgRG9tVTIgaXMgdGhlIGJvcnJvd2VyIGRvbWFpbi4NCj4+Pj4gKw0KPj4+PiArU0NNSSBTTUMg
bXVsdGktYWdlbnQgc3VwcG9ydA0KPj4+PiArPT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K
Pj4+PiArDQo+Pj4+ICtGb3IgZW5hYmxpbmcgdGhlIEFSTSBTQ01JIFNNQyBtdWx0aS1hZ2VudCBz
dXBwb3J0IChlbmFibGVkIGJ5IENPTkZJR19TQ01JX1NNQ19NQSkNCj4+Pj4gK3RoZSBYZW4gc3Bl
Y2lmaWMgU0NNSSBBZ2VudCdzIGNvbmZpZ3VyYXRpb24gc2hlbGwgYmUgcHJvdmlkZWQgaW4gdGhl
IEhvc3QgRFQNCj4+Pj4gK2FjY29yZGluZyB0byB0aGUgU0NNSSBjb21wbGlhbnQgRUwzIEZpcm13
YXJlIHNwZWNpZmljYXRpb24gd2l0aA0KPj4+PiArQVJNIFNNQy9IVkMgdHJhbnNwb3J0IHVzaW5n
IHByb3BlcnR5ICJ4ZW4sc2NtaS1zZWNvbmRhcnktYWdlbnRzIiB1bmRlcg0KPj4+PiArdGhlIHRv
cC1sZXZlbCAiY2hvc2VuIiBub2RlOg0KPj4+PiArDQo+Pj4+ICstIHhlbixzY21pLXNlY29uZGFy
eS1hZ2VudHMNCj4+Pj4gKw0KPj4+PiArICAgIERlZmluZXMgYSBzZXQgb2YgU0NNSSBhZ2VudHMg
Y29uZmlndXJhdGlvbiBzdXBwb3J0ZWQgYnkgU0NNSSBFTDMgRlcgYW5kDQo+Pj4+ICsgICAgYXZh
aWxhYmxlIGZvciBYZW4uIEVhY2ggQWdlbnQgZGVmaW5lZCBhcyB0cmlwbGUgY29uc2lzdGluZyBv
ZjoNCj4+Pj4gKyAgICBTQ01JIGFnZW50X2lkLA0KPj4+PiArICAgIFNNQy9IVkMgZnVuY3Rpb25f
aWQgYXNzaWduZWQgZm9yIHRoZSBhZ2VudCB0cmFuc3BvcnQgKCJhcm0sc21jLWlkIiksDQo+Pj4+
ICsgICAgcGhhbmRsZSB0byBTQ01JIFNITSBhc3NpZ25lZCBmb3IgdGhlIGFnZW50IHRyYW5zcG9y
dCAoImFybSxzY21pLXNobWVtIikuDQo+Pj4+ICsNCj4+Pj4gK0FzIGFuIGV4YW1wbGU6DQo+Pj4+
ICsNCj4+Pj4gK2Nob3NlbiB7DQo+Pj4+ICsgICAgeGVuLHNjbWktc2Vjb25kYXJ5LWFnZW50cyA9
IDwNCj4+Pj4gKyAgICAgICAgMSAweDgyMDAwMDAzICZzY21pX3NobV8xDQo+Pj4+ICsgICAgICAg
IDIgMHg4MjAwMDAwNCAmc2NtaV9zaG1fMg0KPj4+PiArICAgICAgICAzIDB4ODIwMDAwMDUgJnNj
bWlfc2htXzMNCj4+Pj4gKyAgICAgICAgNCAweDgyMDAwMDA2ICZzY21pX3NobV80PjsNCj4+Pj4g
K30NCj4+PiBOSVQ6IGl0IHNob3VsZCBiZSB9Ow0KPj4gKw0KPj4+IExvb2tpbmcgYXQgc2NtaV9w
cm9iZSwgY29sbGVjdF9hZ2VudHMsIGFuZCB0aGUgZm9sbG93aW5nIFNDTUkNCj4+PiBTQ01JX0JB
U0VfRElTQ09WRVJfQUdFTlQgcmVxdWVzdCwgSSB3b25kZXI6IGRvIHdlIGFjdHVhbGx5IG5lZWQg
dGhpcw0KPj4+IGluZm9ybWF0aW9uPw0KPj4+DQo+Pj4gSXQgbG9va3MgbGlrZSB3ZSBjYW4gZGlz
Y292ZXIgdGhlIGFnZW5kX2lkcyBmb3IgZXZlcnkgY2hhbm5lbCwgSSBndWVzcw0KPj4+IHdoYXQg
d2UgbmVlZCB0byBrbm93IGlzIHRoZSBzaG1lbSBsb2NhdGlvbiBmb3IgZXZlcnkgY2hhbm5lbD8g
QnV0IHRoZQ0KPj4+IGZ1bGwgbGlzdCBvZiBzaG1lbSBjaGFubmVsIGlzIGF2YWlsYWJsZSBiZWxv
dyB0aGFua3MgdG8gdGhlIHNjbWktc2htZW0NCj4+PiBub2Rlcy4NCj4+Pg0KPj4+IFNvLCB3ZSBo
YXZlIHRoZSBsaXN0IG9mIHNjbWktc2htZW0gYW55d2F5LCBhbmQgd2UgY2FuIHByb2JlIHRoZQ0K
Pj4+IGFnZW50X2lkLiBUaGUgb25seSBwYXJhbWV0ZXIgbGVmdCBpcyB0aGUgc21jX2lkL2Z1bmNf
aWQuDQo+Pj4NCj4+PiBPciBtYXliZSBzbWNfaWQvZnVuY19pZCBjYW4gYmUgY2FsY3VsYXRlZCBm
cm9tIGFnZW50X2lkPw0KPj4+DQo+Pj4gSSBhbSBhc2tpbmcgbW9zdGx5IGJlY2F1c2UgaWYgYSB1
c2VyIGlzIHN1cHBvc2VkIHRvIGFkZCB0aGlzDQo+Pj4geGVuLHNjbWktc2Vjb25kYXJ5LWFnZW50
cyBwcm9wZXJ0eSwgd2hlcmUgYXJlIHRoZXkgc3VwcG9zZWQgdG8gZmluZCB0aGUNCj4+PiBzbWNf
aWQvZnVuY19pZCBpbmZvcm1hdGlvbj8NCj4+Pg0KPj4+IEl0IGlzIGltcG9ydGFudCB0aGF0IHdl
IHdyaXRlIGRvd24gaW4gdGhpcyBkb2N1bWVudCBob3cgdGhlIHVzZXIgaXMNCj4+PiBleHBlY3Rl
ZCB0byBmaW5kIG91dCB3aGF0IDEgaXMgMHg4MjAwMDAwMyB3aGljaCBpcyBzY21pX3NobV8xLg0K
Pj4gVGhhdCdzIGEgdmVyeSBnb29kIHF1ZXN0aW9uISBUaGUgaXNzdWUgaGVyZSBpcyB0aGF0IHRo
ZXJlIGFyZSBubw0KPj4NCj4+IGV4cGxpY2l0IHJlcXVpcmVtZW50cyBkZWZpbmluZyB0aGUgcmVs
YXRpb25zaGlwIGJldHdlZW4gYWdlbnRfaWQgYW5kDQo+PiBmdW5jX2lkLg0KPj4NCj4+DQo+PiBG
b3IgZXhhbXBsZSwgaW4gQVJNLVRGLCBkaWZmZXJlbnQgaW1wbGVtZW50YXRpb25zIGNhbiB1c2Ug
ZGlmZmVyZW50DQo+PiBmdW5jX2lkcy4NCj4+DQo+PiBUbyBwcm92aWRlIGJldHRlciBmbGV4aWJp
bGl0eSwgd2UgZGVjaWRlZCB0byBzZXBhcmF0ZSBhZ2VudF9pZCBmcm9tIGZ1bmNfaWQuDQo+Pg0K
Pj4NCj4+IEN1cnJlbnRseSwgdGhlIFNDTUlfQkFTRV9ESVNDT1ZFUl9BR0VOVCBjYWxscyBmcm9t
IHRoZSBwcm9iZSBhcmUgaW50ZW5kZWQgdG8NCj4+DQo+PiB2ZXJpZnkgdGhhdCBhbGwgcmVnaXN0
ZXJlZCBhZ2VudHMgYXJlIHByZXNlbnQgYW5kIHRoYXQgdGhlIGNvbmZpZ3VyYXRpb24NCj4+IGlz
IGNvcnJlY3QuDQo+Pg0KPj4gSG93ZXZlciwgSSB1bmRlcnN0YW5kIHRoYXQgdGhpcyBhZGRpdGlv
bmFsIHZhbGlkYXRpb24gY291bGQgYmUgb3B0aW9uYWwNCj4+IHRvIHNhdmUgdHJhZmZpYy4NCj4+
DQo+Pg0KPj4gVG8gYWRkcmVzcyB0aGlzLCBJ4oCZbSBjb25zaWRlcmluZyBhZGRpbmcgYSBjb25m
aWd1cmF0aW9uIG9wdGlvbiwgc3VjaCBhcw0KPj4NCj4+IENPTkZJR19TQ01JX0FHRU5UX1ZBTElE
QVRJT04sIHdoaWNoIGNhbiBiZSBkaXNhYmxlZCB0byByZWR1Y2UgYm9vdCB0aW1lDQo+PiBpZiB0
aGlzDQo+Pg0KPj4gdmFsaWRhdGlvbiBpcyBub3QgbmVjZXNzYXJ5IGZvciBjZXJ0YWluIHVzZSBj
YXNlcy4NCj4+DQo+Pg0KPj4gTGFzdGx5LCBJ4oCZbGwgYmUgdXBkYXRpbmcgdGhlIGRvY3VtZW50
IHRvIGluY2x1ZGUgY2xlYXJlciBpbmZvcm1hdGlvbg0KPj4gYWJvdXQgdGhlDQo+Pg0KPj4gcmVs
YXRpb25zaGlwIGJldHdlZW4gZnVuY19pZCBhbmQgYWdlbnRfaWQgaW4gdGhlIHVwY29taW5nIHY1
Lg0KPg0KPiBUaGUga2V5IHBvaW50IGhlcmUgaXMgdG8gbWFrZSBpdCBlYXNpZXIgZm9yIHRoZSB1
c2VyLiBJZiB3ZSBjYW4gbWFrZQ0KPiBhZ2VudF9pZCBvciBmdW5jX2lkIG9wdGlvbmFsIGl0IHdv
dWxkIG1ha2UgdXNlcnMgbGl2ZXMgZWFzaWVyLg0KPg0KPiBBbHRlcm5hdGl2ZSwgb3IgaW4gYWRk
aXRpb24gdG8gdGhpcywgd2Ugc2hvdWxkIG1ha2UgdGhlIGRvY3MgYXMgY2xlYXIgYXMNCj4gcG9z
c2libGUgc28gdGhhdCBwZW9wbGUgY2FuIGZpZ3VyZSBpdCBvdXQgd2l0aG91dCBoYXZpbmcgdG8g
YXNrDQo+IHF1ZXN0aW9ucyBvbiB4ZW4tZGV2ZWwuDQo+DQo+DQoNCltPTSBBTlNXRVJdDQoNClND
TUlfQkFTRV9ESVNDT1ZFUl9BR0VOVCBtZXNzYWdlIHJlcXVpcmVzIGFnZW50X2lkLiBJIHRoaW5r
IHdlIGNhbiBjYWxjdWxhdGUNCg0KYWdlbnRfaWQgZnJvbSBmdW5jX2lkLCB0aGUgZG9jdW1lbnRh
dGlvbiB3aWxsIGxvb2sgbGlrZSB0aGlzOg0KDQpgYGANCg0KRm9yIGVuYWJsaW5nIHRoZSBBUk0g
U0NNSSBTTUMgbXVsdGktYWdlbnQgc3VwcG9ydCAoZW5hYmxlZCBieQ0KQ09ORklHX1NDTUlfU01D
X01BKQ0KdGhlIFhlbiBzcGVjaWZpYyBTQ01JIEFnZW50J3MgY29uZmlndXJhdGlvbiBzaGVsbCBi
ZSBwcm92aWRlZCBpbiB0aGUgSG9zdCBEVA0KYWNjb3JkaW5nIHRvIHRoZSBTQ01JIGNvbXBsaWFu
dCBFTDMgRmlybXdhcmUgc3BlY2lmaWNhdGlvbiB3aXRoDQpBUk0gU01DL0hWQyB0cmFuc3BvcnQg
dXNpbmcgcHJvcGVydHkgInhlbixzY21pLXNlY29uZGFyeS1hZ2VudHMiIHVuZGVyDQp0aGUgdG9w
LWxldmVsICJjaG9zZW4iIG5vZGU6DQoNCi0geGVuLHNjbWktc2Vjb25kYXJ5LWFnZW50cw0KDQog
ICAgIERlZmluZXMgYSBzZXQgb2YgU0NNSSBhZ2VudHMgY29uZmlndXJhdGlvbiBzdXBwb3J0ZWQg
YnkgU0NNSSBFTDMgRlcgYW5kDQogICAgIGF2YWlsYWJsZSBmb3IgWGVuLiBFYWNoIEFnZW50IGRl
ZmluZWQgYXMgdHJpcGxlIGNvbnNpc3Rpbmcgb2Y6DQogICAgIFNNQy9IVkMgZnVuY3Rpb25faWQg
YXNzaWduZWQgZm9yIHRoZSBhZ2VudCB0cmFuc3BvcnQgKCJhcm0sc21jLWlkIiksDQogICAgIHBo
YW5kbGUgdG8gU0NNSSBTSE0gYXNzaWduZWQgZm9yIHRoZSBhZ2VudCB0cmFuc3BvcnQNCigiYXJt
LHNjbWktc2htZW0iKSwNCg0KICAgICBTQ01JIGFnZW50X2lkIChvcHRpb25hbCkNCg0KQXMgYW4g
ZXhhbXBsZToNCg0KY2hvc2VuIHsNCiAgICAgeGVuLHNjbWktc2Vjb25kYXJ5LWFnZW50cyA9IDwN
CiAgICAgICAgIDB4ODIwMDAwMDMgJnNjbWlfc2htXzEgMQ0KICAgICAgICAgMHg4MjAwMDAwNCAm
c2NtaV9zaG1fMiAyDQogICAgICAgICAweDgyMDAwMDA1ICZzY21pX3NobV8zIDMNCiAgICAgICAg
IDB4ODIwMDAwMDYgJnNjbWlfc2htXzQgND47DQp9DQoNCm9yDQoNCmNob3NlbiB7DQogICAgIHhl
bixzY21pLXNlY29uZGFyeS1hZ2VudHMgPSA8DQogICAgICAgICAweDgyMDAwMDAzICZzY21pX3No
bV8xDQogICAgICAgICAweDgyMDAwMDA0ICZzY21pX3NobV8yDQogICAgICAgICAweDgyMDAwMDA1
ICZzY21pX3NobV8zDQogICAgICAgICAweDgyMDAwMDA2ICZzY21pX3NobV80PjsNCn0NCg0KSWYg
dGhlIG9wdGlvbmFsIHBhcmFtZXRlciBhZ2VudF9pZCBpcyBub3QgcHJvdmlkZWQsIHRoZW4gWGVu
IHdpbGwNCnJlcXVlc3QgYWdlbnRfaWQgZm9yIGVhY2ggcmVnaXN0ZXJlZA0KDQpjaGFubmVsIGZy
b20gdGhlIGZpcm13YXJlLg0KDQpUaGlzIHByb2NlZHVyZSByZXF1aXJlcyBzZW5kaW5nIEJBU0Vf
RElTQ09WRVJfQUdFTlQgdXNpbmcgZnVuY19pZCBhbmQNCnNobWVtIHJlZ2lvbiBmb3IgZWFjaA0K
DQpyZWdpc3RlcmVkIGFnZW50IGFuZCBkaXNjb3ZlciBpdCdzIGFnZW50X2lkLiBUaGlzIG9wZXJh
dGlvbiByZXF1aXJlcyBhbGwNCm1lbW9yeSByZXNlcnZlZCBmb3IgdGhlIGFnZW50cw0KDQp0byBi
ZSBtYXBwZWQgYW5kIHRoZW4gdW5tYXBwZWQgd2hpY2ggY2FuIGNhdXNlIGJvb3QgdGltZSBpbmNy
ZWFzaW5nLiBTbw0KaWYgYm9vdCB0aW1lIGlzIGltcG9ydGFudCBpdCBpcw0KDQpwcmVmZXJhYmxl
IHRvIHByb3ZpZGUgYWdlbnRfaW4gaW4gdGhlIGRldmljZS10cmVlLg0KDQpUaGVyZSBhcmUgc29t
ZSBjYXNlcyB3aGVuIFhlbiBtYXkgbm90IGhhdmUgYW4gYWNjZXNzIHRvIG90aGVyIGFnZW50DQpt
ZW1vcnksIGluY2x1ZGluZyBzY21pIHNobWVtIGR1ZSB0bw0KDQphIHZlcnkgc3RyaWN0IEZGSSBj
b25maWd1cmF0aW9uLiBJbiB0aGlzIGNhc2UgYWdlbnRfaWQgc2hvdWxkIGJlDQpwcm92aWRlZCBp
bnNpZGUgeGVtLHNjbWktc2Vjb25kYXJ5LWFnZW50cyBwYXJhbWV0ZXIuDQoNCmBgYA0KDQpXaGF0
IGRvIHlvdSB0aGluayBhYm91dCB0aGlzIGFwcHJvYWNoPw0KDQpJIHdpbGwgYWRkIGluZm9ybWF0
aW9uIGFib3V0IGFsbCBwb2ludCBpbnRvIHRoZSBkb2NzIGFuZCB3aWxsIHRyeSB0bw0KbWFrZSBp
dCBhcyBjbGVhciBhcyBwb3NzaWJsZS4NCg0KPj4+PiArL3sNCj4+Pj4gKyAgICAgICAgc2NtaV9z
aG1fMTogc3JhbUA0N2ZmMTAwMCB7DQo+Pj4+ICsgICAgICAgICAgICAgICAgY29tcGF0aWJsZSA9
ICJhcm0sc2NtaS1zaG1lbSI7DQo+Pj4+ICsgICAgICAgICAgICAgICAgcmVnID0gPDB4MCAweDQ3
ZmYxMDAwIDB4MCAweDEwMDA+Ow0KPj4+PiArICAgICAgICB9Ow0KPj4+PiArICAgICAgICBzY21p
X3NobV8yOiBzcmFtQDQ3ZmYyMDAwIHsNCj4+Pj4gKyAgICAgICAgICAgICAgICBjb21wYXRpYmxl
ID0gImFybSxzY21pLXNobWVtIjsNCj4+Pj4gKyAgICAgICAgICAgICAgICByZWcgPSA8MHgwIDB4
NDdmZjIwMDAgMHgwIDB4MTAwMD47DQo+Pj4+ICsgICAgICAgIH07DQo+Pj4+ICsgICAgICAgIHNj
bWlfc2htXzM6IHNyYW1ANDdmZjMwMDAgew0KPj4+PiArICAgICAgICAgICAgICAgIGNvbXBhdGli
bGUgPSAiYXJtLHNjbWktc2htZW0iOw0KPj4+PiArICAgICAgICAgICAgICAgIHJlZyA9IDwweDAg
MHg0N2ZmMzAwMCAweDAgMHgxMDAwPjsNCj4+Pj4gKyAgICAgICAgfTsNCj4+Pj4gKyAgICAgICAg
c2NtaV9zaG1fMzogc3JhbUA0N2ZmNDAwMCB7DQo+Pj4+ICsgICAgICAgICAgICAgICAgY29tcGF0
aWJsZSA9ICJhcm0sc2NtaS1zaG1lbSI7DQo+Pj4+ICsgICAgICAgICAgICAgICAgcmVnID0gPDB4
MCAweDQ3ZmY0MDAwIDB4MCAweDEwMDA+Ow0KPj4+PiArICAgICAgICB9Ow0KPj4+IEFyZSB0aGVz
ZSBzY21pX3NobV8xIC0gc2NtaV9zaG1fMyB1bmRlciB0aGUgdG9wIGxldmVsIGRldmljZSB0cmVl
IG5vZGU/DQo+Pj4gT3IgYXJlIHVuZGVyIC9maXJtd2FyZT8gT3IgYXJlIHRoZXkgdW5kZXIgL2No
b3Nlbj8NCj4+Pg0KPj4+IEkgdGFrZSB0aGV5IGFyZSB1bmRlciB0aGUgdG9wIGxldmVsIG5vZGUg
dG9nZXRoZXIgd2l0aCBzY21pX3NobV8wPw0KPj4+DQo+Pj4gQ2FuIHlvdSBwbGVhc2UgYWxzbyBj
bGFyaWZ5IGluIHRoZSBkb2N1bWVudCBhcyB3ZWxsPw0KPj4+DQo+Pj4NCj4+IGFsbCB0aGVzZSBu
b2RlcyBhcmUgb24gdGhlIHRvcCBsZXZlbCBvZiB0aGUgZGV2aWNlLXRyZWUuIEJ1dCB0aGVyZSBp
cyBubw0KPj4gc3BlY2lmaWMgcGxhY2UgZm9yIHRoZW0uDQo+Pg0KPj4gVGhleSBjb3VsZCBiZSBz
dWJub2RlcyB0byBzb21lIG1lbW9yeS1yZWdpb24gZm9yIGV4YW1wbGUuIEkgd2lsbCBjbGFyaWZ5
DQo+PiB0aGlzLg0KPj4NCj4+Pj4gK30NCj4+Pj4gZGlmZiAtLWdpdCBhL2RvY3MvbWlzYy94ZW4t
Y29tbWFuZC1saW5lLnBhbmRvYyBiL2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLnBhbmRvYw0K
Pj4+PiBpbmRleCA4ZTUwZjZiN2M3Li5iYzNjNjRkNmVjIDEwMDY0NA0KPj4+PiAtLS0gYS9kb2Nz
L21pc2MveGVuLWNvbW1hbmQtbGluZS5wYW5kb2MNCj4+Pj4gKysrIGIvZG9jcy9taXNjL3hlbi1j
b21tYW5kLWxpbmUucGFuZG9jDQo+Pj4+IEBAIC0xMDkxLDYgKzEwOTEsMTUgQEAgd2hpY2ggc2Vy
dmVzIGFzIERyaXZlciBkb21haW4uIFRoZSBTQ01JIHdpbGwgYmUgZGlzYWJsZWQgZm9yIERvbTAv
aHdkb20gYW5kDQo+Pj4+ICAgIFNDTUkgbm9kZXMgcmVtb3ZlZCBmcm9tIERvbTAvaHdkb20gZGV2
aWNlIHRyZWUuDQo+Pj4+ICAgIChmb3IgZXhhbXBsZSwgdGhpbiBEb20wIHdpdGggRHJpdmVyIGRv
bWFpbiB1c2UtY2FzZSkuDQo+Pj4+DQo+Pj4+ICsjIyMgZG9tMF9zY21pX2FnZW50X2lkIChBUk0p
DQo+Pj4+ICs+IGA9IDxpbnRlZ2VyPmANCj4+Pj4gKw0KPj4+PiArVGhlIG9wdGlvbiBpcyBhdmFp
bGFibGUgd2hlbiBgQ09ORklHX1NDTUlfU01DX01BYCBpcyBjb21waWxlZCBpbiwgYW5kIGFsbG93
cyB0bw0KPj4+PiArZW5hYmxlIFNDTUkgZnVuY3Rpb25hbGl0eSBmb3IgRG9tMCBieSBzcGVjaWZ5
aW5nIGEgbm9uLXplcm8gQVJNIFNDTUkgYWdlbnQgaWQuDQo+Pj4+ICtUaGUgU0NNSSB3aWxsIGJl
IGRpc2FibGVkIGZvciBEb20wIGlmIHRoaXMgb3B0aW9uIGlzIG5vdCBzcGVjaWZpZWQNCj4+Pj4g
Kyhmb3IgZXhhbXBsZSwgdGhpbiBEb20wIG9yIGRvbTBsZXNzIHVzZS1jYXNlcykuDQo+Pj4+ICtU
aGUgYWdlbnQgaWRzIG9mIGRvbWFpbnMgZXhpc3Rpbmcgb24gYSBzaW5nbGUgaG9zdCBtdXN0IGJl
IHVuaXF1ZS4NCj4+Pj4gKw0KPj4+PiAgICAjIyMgZHR1YXJ0IChBUk0pDQo+Pj4+ICAgID4gYD0g
cGF0aCBbOm9wdGlvbnNdYA0KPj4+Pg0KPj4+PiBkaWZmIC0tZ2l0IGEvdG9vbHMvbGlicy9saWdo
dC9saWJ4bF9hcm0uYyBiL3Rvb2xzL2xpYnMvbGlnaHQvbGlieGxfYXJtLmMNCj4+Pj4gaW5kZXgg
MjhiYTllYjc4Ny4uNzcxMmY1M2NkNCAxMDA2NDQNCj4+Pj4gLS0tIGEvdG9vbHMvbGlicy9saWdo
dC9saWJ4bF9hcm0uYw0KPj4+PiArKysgYi90b29scy9saWJzL2xpZ2h0L2xpYnhsX2FybS5jDQo+
Pj4+IEBAIC0yMjksNiArMjI5LDEwIEBAIGludCBsaWJ4bF9fYXJjaF9kb21haW5fcHJlcGFyZV9j
b25maWcobGlieGxfX2djICpnYywNCj4+Pj4gICAgICAgIGNhc2UgTElCWExfQVJNX1NDSV9UWVBF
X1NDTUlfU01DOg0KPj4+PiAgICAgICAgICAgIGNvbmZpZy0+YXJjaC5hcm1fc2NpX3R5cGUgPSBY
RU5fRE9NQ1RMX0NPTkZJR19BUk1fU0NJX1NDTUlfU01DOw0KPj4+PiAgICAgICAgICAgIGJyZWFr
Ow0KPj4+PiArICAgIGNhc2UgTElCWExfQVJNX1NDSV9UWVBFX1NDTUlfU01DX01VTFRJQUdFTlQ6
DQo+Pj4+ICsgICAgICAgIGNvbmZpZy0+YXJjaC5hcm1fc2NpX3R5cGUgPSBYRU5fRE9NQ1RMX0NP
TkZJR19BUk1fU0NJX1NDTUlfU01DX01BOw0KPj4+PiArICAgICAgICBjb25maWctPmFyY2guYXJt
X3NjaV9hZ2VudF9pZCA9IGRfY29uZmlnLT5iX2luZm8uYXJjaF9hcm0uYXJtX3NjaS5hZ2VudF9p
ZDsNCj4+Pj4gKyAgICAgICAgYnJlYWs7DQo+Pj4+ICAgICAgICBkZWZhdWx0Og0KPj4+PiAgICAg
ICAgICAgIExPRyhFUlJPUiwgIlVua25vd24gQVJNX1NDSSB0eXBlICVkIiwNCj4+Pj4gICAgICAg
ICAgICAgICAgZF9jb25maWctPmJfaW5mby5hcmNoX2FybS5hcm1fc2NpLnR5cGUpOw0KPj4+PiBk
aWZmIC0tZ2l0IGEvdG9vbHMvbGlicy9saWdodC9saWJ4bF90eXBlcy5pZGwgYi90b29scy9saWJz
L2xpZ2h0L2xpYnhsX3R5cGVzLmlkbA0KPj4+PiBpbmRleCBhYTIxOTBhYjViLi4xMWUzMWNlNzg2
IDEwMDY0NA0KPj4+PiAtLS0gYS90b29scy9saWJzL2xpZ2h0L2xpYnhsX3R5cGVzLmlkbA0KPj4+
PiArKysgYi90b29scy9saWJzL2xpZ2h0L2xpYnhsX3R5cGVzLmlkbA0KPj4+PiBAQCAtNTUzLDEx
ICs1NTMsMTMgQEAgbGlieGxfc3ZlX3R5cGUgPSBFbnVtZXJhdGlvbigic3ZlX3R5cGUiLCBbDQo+
Pj4+DQo+Pj4+ICAgIGxpYnhsX2FybV9zY2lfdHlwZSA9IEVudW1lcmF0aW9uKCJhcm1fc2NpX3R5
cGUiLCBbDQo+Pj4+ICAgICAgICAoMCwgIm5vbmUiKSwNCj4+Pj4gLSAgICAoMSwgInNjbWlfc21j
IikNCj4+Pj4gKyAgICAoMSwgInNjbWlfc21jIiksDQo+Pj4+ICsgICAgKDIsICJzY21pX3NtY19t
dWx0aWFnZW50IikNCj4+Pj4gICAgICAgIF0sIGluaXRfdmFsID0gIkxJQlhMX0FSTV9TQ0lfVFlQ
RV9OT05FIikNCj4+Pj4NCj4+Pj4gICAgbGlieGxfYXJtX3NjaSA9IFN0cnVjdCgiYXJtX3NjaSIs
IFsNCj4+Pj4gICAgICAgICgidHlwZSIsIGxpYnhsX2FybV9zY2lfdHlwZSksDQo+Pj4+ICsgICAg
KCJhZ2VudF9pZCIsIHVpbnQ4KQ0KPj4+PiAgICAgICAgXSkNCj4+Pj4NCj4+Pj4gICAgbGlieGxf
cmRtX3Jlc2VydmUgPSBTdHJ1Y3QoInJkbV9yZXNlcnZlIiwgWw0KPj4+PiBkaWZmIC0tZ2l0IGEv
dG9vbHMveGwveGxfcGFyc2UuYyBiL3Rvb2xzL3hsL3hsX3BhcnNlLmMNCj4+Pj4gaW5kZXggYmQy
MmJlOWQzMy4uODFhYTM3OTdlMyAxMDA2NDQNCj4+Pj4gLS0tIGEvdG9vbHMveGwveGxfcGFyc2Uu
Yw0KPj4+PiArKysgYi90b29scy94bC94bF9wYXJzZS5jDQo+Pj4+IEBAIC0xMzA2LDYgKzEzMDYs
MTggQEAgc3RhdGljIGludCBwYXJzZV9hcm1fc2NpX2NvbmZpZyhYTFVfQ29uZmlnICpjZmcsIGxp
YnhsX2FybV9zY2kgKmFybV9zY2ksDQo+Pj4+ICAgICAgICAgICAgICAgIH0NCj4+Pj4gICAgICAg
ICAgICB9DQo+Pj4+DQo+Pj4+ICsgICAgICAgIGlmIChNQVRDSF9PUFRJT04oImFnZW50X2lkIiwg
cHRyLCBvcGFyZykpIHsNCj4+Pj4gKyAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcgdmFsID0gcGFy
c2VfdWxvbmcob3BhcmcpOw0KPj4+PiArDQo+Pj4+ICsgICAgICAgICAgICBpZiAoIXZhbCB8fCB2
YWwgPiAyNTUpIHsNCj4+Pj4gKyAgICAgICAgICAgICAgICBmcHJpbnRmKHN0ZGVyciwgIkFuIGlu
dmFsaWQgQVJNX1NDSSBhZ2VudF9pZCBzcGVjaWZpZWQgKCVsdSkuIFZhbGlkIHJhbmdlIFsxLi4y
NTVdXG4iLA0KPj4+PiArICAgICAgICAgICAgICAgICAgICAgICAgdmFsKTsNCj4+Pj4gKyAgICAg
ICAgICAgICAgICByZXQgPSBFUlJPUl9JTlZBTDsNCj4+Pj4gKyAgICAgICAgICAgICAgICBnb3Rv
IHBhcnNlX2Vycm9yOw0KPj4+PiArICAgICAgICAgICAgfQ0KPj4+PiArICAgICAgICAgICAgYXJt
X3NjaS0+YWdlbnRfaWQgPSB2YWw7DQo+Pj4+ICsgICAgICAgIH0NCj4+Pj4gKw0KPj4+PiAgICAg
ICAgICAgIHB0ciA9IHN0cnRvayhOVUxMLCAiLCIpOw0KPj4+PiAgICAgICAgfQ0KPj4+Pg0KPj4+
PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2RvbTBsZXNzLWJ1aWxkLmMgYi94ZW4vYXJjaC9h
cm0vZG9tMGxlc3MtYnVpbGQuYw0KPj4+PiBpbmRleCAwYTAwZjAzYTI1Li40M2QyMWViODg5IDEw
MDY0NA0KPj4+PiAtLS0gYS94ZW4vYXJjaC9hcm0vZG9tMGxlc3MtYnVpbGQuYw0KPj4+PiArKysg
Yi94ZW4vYXJjaC9hcm0vZG9tMGxlc3MtYnVpbGQuYw0KPj4+PiBAQCAtODM1LDYgKzgzNSwxNyBA
QCBpbnQgX19pbml0IGRvbXVfZHRfc2NpX3BhcnNlKHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqbm9k
ZSwNCj4+Pj4gICAgICAgICAgICBkX2NmZy0+YXJjaC5hcm1fc2NpX3R5cGUgPSBYRU5fRE9NQ1RM
X0NPTkZJR19BUk1fU0NJX05PTkU7DQo+Pj4+ICAgICAgICBlbHNlIGlmICggIXN0cmNtcChzY2lf
dHlwZSwgInNjbWlfc21jIikgKQ0KPj4+PiAgICAgICAgICAgIGRfY2ZnLT5hcmNoLmFybV9zY2lf
dHlwZSA9IFhFTl9ET01DVExfQ09ORklHX0FSTV9TQ0lfU0NNSV9TTUM7DQo+Pj4+ICsgICAgZWxz
ZSBpZiAoICFzdHJjbXAoc2NpX3R5cGUsICJzY21pX3NtY19tdWx0aWFnZW50IikgKQ0KPj4+PiAr
ICAgIHsNCj4+Pj4gKyAgICAgICAgdWludDMyX3QgYWdlbnRfaWQgPSAwOw0KPj4+PiArDQo+Pj4+
ICsgICAgICAgIGlmICggIWR0X3Byb3BlcnR5X3JlYWRfdTMyKG5vZGUsICJ4ZW4sc2NpX2FnZW50
X2lkIiwgJmFnZW50X2lkKSB8fA0KPj4+PiArICAgICAgICAgICAgICFhZ2VudF9pZCApDQo+Pj4g
c2hvdWxkbid0IHdlIGNoZWNrIHRoYXQgYWdlbnRfaWQgPD0gMjU1ID8NCj4+IEkgc2VlIG5vIGxp
bWl0YXRpb24gYWJvdXQgbWF4IGFnZW50X2lkIGluIERFTjAwNTZFIGRvY3VtZW50LCBpdCdzIHVp
bnQzMl90Lg0KPj4NCj4+Pj4gKyAgICAgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4+PiArDQo+
Pj4+ICsgICAgICAgIGRfY2ZnLT5hcmNoLmFybV9zY2lfdHlwZSA9IFhFTl9ET01DVExfQ09ORklH
X0FSTV9TQ0lfU0NNSV9TTUNfTUE7DQo+Pj4+ICsgICAgICAgIGRfY2ZnLT5hcmNoLmFybV9zY2lf
YWdlbnRfaWQgPSBhZ2VudF9pZDsNCj4+Pj4gKyAgICB9DQo+Pj4+ICAgICAgICBlbHNlDQo+Pj4+
ICAgICAgICB7DQo+Pj4+ICAgICAgICAgICAgcHJpbnRrKFhFTkxPR19FUlIgInhlbixzY2lfdHlw
ZSBpbiBub3QgdmFsaWQgKCVzKSBmb3IgZG9tYWluICVzXG4iLA0KPj4+PiBkaWZmIC0tZ2l0IGEv
eGVuL2FyY2gvYXJtL2RvbWFpbl9idWlsZC5jIGIveGVuL2FyY2gvYXJtL2RvbWFpbl9idWlsZC5j
DQo+Pj4+IGluZGV4IDM2ZDI4YjUyYTQuLjBjOTI3NGEyYjMgMTAwNjQ0DQo+Pj4+IC0tLSBhL3hl
bi9hcmNoL2FybS9kb21haW5fYnVpbGQuYw0KPj4+PiArKysgYi94ZW4vYXJjaC9hcm0vZG9tYWlu
X2J1aWxkLmMNCj4+Pj4gQEAgLTYxNiw3ICs2MTYsOCBAQCBzdGF0aWMgaW50IF9faW5pdCB3cml0
ZV9wcm9wZXJ0aWVzKHN0cnVjdCBkb21haW4gKmQsIHN0cnVjdCBrZXJuZWxfaW5mbyAqa2luZm8s
DQo+Pj4+ICAgICAgICAgICAgICAgICAgICAgZHRfcHJvcGVydHlfbmFtZV9pc19lcXVhbChwcm9w
LCAibGludXgsdWVmaS1tbWFwLXN0YXJ0IikgfHwNCj4+Pj4gICAgICAgICAgICAgICAgICAgICBk
dF9wcm9wZXJ0eV9uYW1lX2lzX2VxdWFsKHByb3AsICJsaW51eCx1ZWZpLW1tYXAtc2l6ZSIpIHx8
DQo+Pj4+ICAgICAgICAgICAgICAgICAgICAgZHRfcHJvcGVydHlfbmFtZV9pc19lcXVhbChwcm9w
LCAibGludXgsdWVmaS1tbWFwLWRlc2Mtc2l6ZSIpIHx8DQo+Pj4+IC0gICAgICAgICAgICAgICAg
IGR0X3Byb3BlcnR5X25hbWVfaXNfZXF1YWwocHJvcCwgImxpbnV4LHVlZmktbW1hcC1kZXNjLXZl
ciIpKQ0KPj4+PiArICAgICAgICAgICAgICAgICBkdF9wcm9wZXJ0eV9uYW1lX2lzX2VxdWFsKHBy
b3AsICJsaW51eCx1ZWZpLW1tYXAtZGVzYy12ZXIiKSB8fA0KPj4+PiArICAgICAgICAgICAgICAg
ICBkdF9wcm9wZXJ0eV9uYW1lX2lzX2VxdWFsKHByb3AsICJ4ZW4sc2NtaS1zZWNvbmRhcnktYWdl
bnRzIikgKQ0KPj4+PiAgICAgICAgICAgICAgICAgICAgY29udGludWU7DQo+Pj4+DQo+Pj4+ICAg
ICAgICAgICAgICAgIGlmICggZHRfcHJvcGVydHlfbmFtZV9pc19lcXVhbChwcm9wLCAieGVuLGRv
bTAtYm9vdGFyZ3MiKSApIGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vZmlybXdhcmUvS2NvbmZp
Zw0KPj4+PiBiL3hlbi9hcmNoL2FybS9maXJtd2FyZS9LY29uZmlnIGluZGV4IDVjNWYwODgwYzQu
LjZiMDUxYzhhZGEgMTAwNjQ0DQo+Pj4+IC0tLSBhL3hlbi9hcmNoL2FybS9maXJtd2FyZS9LY29u
ZmlnICsrKw0KPj4+PiBiL3hlbi9hcmNoL2FybS9maXJtd2FyZS9LY29uZmlnIEBAIC0yOSw2ICsy
OSwxNyBAQCBjb25maWcgU0NNSV9TTUMNCj4+Pj4gZHJpdmVyIGRvbWFpbi4gVXNlIHdpdGggRUwz
IGZpcm13YXJlIHdoaWNoIHN1cHBvcnRzIG9ubHkgc2luZ2xlIFNDTUkNCj4+Pj4gT1NQTSBhZ2Vu
dC4gK2NvbmZpZyBTQ01JX1NNQ19NQSArIGJvb2wgIkVuYWJsZSBBUk0gU0NNSSBTTUMgbXVsdGkt
YWdlbnQgZHJpdmVyIg0KPj4+PiArICAgIHNlbGVjdCBBUk1fU0NJDQo+Pj4+ICsgICAgaGVscA0K
Pj4+PiArICAgICAgRW5hYmxlcyBTQ01JIFNNQy9IVkMgbXVsdGktYWdlbnQgaW4gWEVOIHRvIHBh
c3MgU0NNSSByZXF1ZXN0cyBmcm9tIERvbWFpbnMNCj4+Pj4gKyAgICAgIHRvIEVMMyBmaXJtd2Fy
ZSAoVEYtQSkgd2hpY2ggc3VwcG9ydHMgbXVsdGktYWdlbnQgZmVhdHVyZS4NCj4+Pj4gKyAgICAg
IFRoaXMgZmVhdHVyZSBhbGxvd3MgdG8gZW5hYmxlIFNDTUkgcGVyIERvbWFpbiB1c2luZyB1bmlx
dWUgU0NNSSBhZ2VudF9pZCwNCj4+Pj4gKyAgICAgIHNvIERvbWFpbiBpcyBpZGVudGlmaWVkIGJ5
IEVMMyBmaXJtd2FyZSBhcyBhbiBTQ01JIEFnZW50IGFuZCBjYW4gYWNjZXNzDQo+Pj4+ICsgICAg
ICBhbGxvd2VkIHBsYXRmb3JtIHJlc291cmNlcyB0aHJvdWdoIGRlZGljYXRlZCBTTUMvSFZDIFNo
YXJlZCBtZW1vcnkgYmFzZWQNCj4+Pj4gKyAgICAgIHRyYW5zcG9ydC4NCj4+Pj4gKw0KPj4+PiAg
ICBlbmRjaG9pY2UNCj4+Pj4NCj4+Pj4gICAgZW5kbWVudQ0KPj4+PiBkaWZmIC0tZ2l0IGEveGVu
L2FyY2gvYXJtL2Zpcm13YXJlL01ha2VmaWxlIGIveGVuL2FyY2gvYXJtL2Zpcm13YXJlL01ha2Vm
aWxlDQo+Pj4+IGluZGV4IDcxYmRlZmMyNGEuLjM3OTI3ZTY5MGUgMTAwNjQ0DQo+Pj4+IC0tLSBh
L3hlbi9hcmNoL2FybS9maXJtd2FyZS9NYWtlZmlsZQ0KPj4+PiArKysgYi94ZW4vYXJjaC9hcm0v
ZmlybXdhcmUvTWFrZWZpbGUNCj4+Pj4gQEAgLTEsMiArMSwzIEBADQo+Pj4+ICAgIG9iai0kKENP
TkZJR19BUk1fU0NJKSArPSBzY2kubw0KPj4+PiAgICBvYmotJChDT05GSUdfU0NNSV9TTUMpICs9
IHNjbWktc21jLm8NCj4+Pj4gK29iai0kKENPTkZJR19TQ01JX1NNQ19NQSkgKz0gc2NtaS1zaG1l
bS5vIHNjbWktc21jLW11bHRpYWdlbnQubw0KPj4+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJt
L2Zpcm13YXJlL3NjbWktcHJvdG8uaCBiL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXByb3Rv
LmgNCj4+Pj4gbmV3IGZpbGUgbW9kZSAxMDA2NDQNCj4+Pj4gaW5kZXggMDAwMDAwMDAwMC4uM2Y0
YjljNWQ2Yg0KPj4+PiAtLS0gL2Rldi9udWxsDQo+Pj4+ICsrKyBiL3hlbi9hcmNoL2FybS9maXJt
d2FyZS9zY21pLXByb3RvLmgNCj4+Pj4gQEAgLTAsMCArMSwxNjQgQEANCj4+Pj4gKy8qIFNQRFgt
TGljZW5zZS1JZGVudGlmaWVyOiBHUEwtMi4wLW9ubHkgKi8NCj4+Pj4gKy8qDQo+Pj4+ICsgKiBB
cm0gU3lzdGVtIENvbnRyb2wgYW5kIE1hbmFnZW1lbnQgSW50ZXJmYWNlIGRlZmluaXRpb25zDQo+
Pj4+ICsgKiBWZXJzaW9uIDMuMCAoREVOMDA1NkMpDQo+Pj4+ICsgKg0KPj4+PiArICogQ29weXJp
Z2h0IChjKSAyMDI0IEVQQU0gU3lzdGVtcw0KPj4+PiArICovDQo+Pj4+ICsNCj4+Pj4gKyNpZm5k
ZWYgWEVOX0FSQ0hfQVJNX1NDSV9TQ01JX1BST1RPX0hfDQo+Pj4+ICsjZGVmaW5lIFhFTl9BUkNI
X0FSTV9TQ0lfU0NNSV9QUk9UT19IXw0KPj4+IE5JVDogQVJNX0ZJUk1XQVJFX1NDTUlfUFJPVE9f
SA0KPj4gKw0KPj4+PiArI2luY2x1ZGUgPHhlbi9zdGRpbnQuaD4NCj4+Pj4gKw0KPj4+PiArI2Rl
ZmluZSBTQ01JX1NIT1JUX05BTUVfTUFYX1NJWkUgMTYNCj4+Pj4gKw0KPj4+PiArLyogU0NNSSBz
dGF0dXMgY29kZXMuIFNlZSBzZWN0aW9uIDQuMS40ICovDQo+Pj4+ICsjZGVmaW5lIFNDTUlfU1VD
Q0VTUyAgICAgICAgICAgICAgMA0KPj4+PiArI2RlZmluZSBTQ01JX05PVF9TVVBQT1JURUQgICAg
ICAoLTEpDQo+Pj4+ICsjZGVmaW5lIFNDTUlfSU5WQUxJRF9QQVJBTUVURVJTICgtMikNCj4+Pj4g
KyNkZWZpbmUgU0NNSV9ERU5JRUQgICAgICAgICAgICAgKC0zKQ0KPj4+PiArI2RlZmluZSBTQ01J
X05PVF9GT1VORCAgICAgICAgICAoLTQpDQo+Pj4+ICsjZGVmaW5lIFNDTUlfT1VUX09GX1JBTkdF
ICAgICAgICgtNSkNCj4+Pj4gKyNkZWZpbmUgU0NNSV9CVVNZICAgICAgICAgICAgICAgKC02KQ0K
Pj4+PiArI2RlZmluZSBTQ01JX0NPTU1TX0VSUk9SICAgICAgICAoLTcpDQo+Pj4+ICsjZGVmaW5l
IFNDTUlfR0VORVJJQ19FUlJPUiAgICAgICgtOCkNCj4+Pj4gKyNkZWZpbmUgU0NNSV9IQVJEV0FS
RV9FUlJPUiAgICAgKC05KQ0KPj4+PiArI2RlZmluZSBTQ01JX1BST1RPQ09MX0VSUk9SICAgICAo
LTEwKQ0KPj4+PiArDQo+Pj4+ICsvKiBQcm90b2NvbCBJRHMgKi8NCj4+Pj4gKyNkZWZpbmUgU0NN
SV9CQVNFX1BST1RPQ09MIDB4MTANCj4+Pj4gKw0KPj4+PiArLyogQmFzZSBwcm90b2NvbCBtZXNz
YWdlIElEcyAqLw0KPj4+PiArI2RlZmluZSBTQ01JX0JBU0VfUFJPVE9DT0xfVkVSU0lPTiAgICAg
ICAgICAgIDB4MA0KPj4+PiArI2RlZmluZSBTQ01JX0JBU0VfUFJPVE9DT0xfQVRUSUJVVEVTICAg
ICAgICAgIDB4MQ0KPj4+PiArI2RlZmluZSBTQ01JX0JBU0VfUFJPVE9DT0xfTUVTU0FHRV9BVFRS
SUJVVEVTIDB4Mg0KPj4+PiArI2RlZmluZSBTQ01JX0JBU0VfRElTQ09WRVJfQUdFTlQgICAgICAg
ICAgICAgIDB4Nw0KPj4+PiArI2RlZmluZSBTQ01JX0JBU0VfU0VUX0RFVklDRV9QRVJNSVNTSU9O
UyAgICAgIDB4OQ0KPj4+PiArI2RlZmluZSBTQ01JX0JBU0VfUkVTRVRfQUdFTlRfQ09ORklHVVJB
VElPTiAgIDB4Qg0KPj4+PiArDQo+Pj4+ICt0eXBlZGVmIHN0cnVjdCBzY21pX21zZ19oZWFkZXIg
ew0KPj4+PiArICAgIHVpbnQ4X3QgaWQ7DQo+Pj4+ICsgICAgdWludDhfdCB0eXBlOw0KPj4+PiAr
ICAgIHVpbnQ4X3QgcHJvdG9jb2w7DQo+Pj4+ICsgICAgdWludDMyX3Qgc3RhdHVzOw0KPj4+PiAr
fSBzY21pX21zZ19oZWFkZXJfdDsNCj4+Pj4gKw0KPj4+PiArLyogVGFibGUgMiBNZXNzYWdlIGhl
YWRlciBmb3JtYXQgKi8NCj4+Pj4gKyNkZWZpbmUgU0NNSV9IRFJfSUQgICAgR0VOTUFTSyg3LCAw
KQ0KPj4+PiArI2RlZmluZSBTQ01JX0hEUl9UWVBFICBHRU5NQVNLKDksIDgpDQo+Pj4+ICsjZGVm
aW5lIFNDTUlfSERSX1BST1RPIEdFTk1BU0soMTcsIDEwKQ0KPj4+PiArDQo+Pj4+ICsjZGVmaW5l
IFNDTUlfRklFTERfR0VUKF9tYXNrLCBfcmVnKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgXA0KPj4+PiArICAgICgodHlwZW9mKF9tYXNrKSkoKChfcmVnKSAmIChf
bWFzaykpID4+IChmZnM2NChfbWFzaykgLSAxKSkpDQo+Pj4+ICsjZGVmaW5lIFNDTUlfRklFTERf
UFJFUChfbWFzaywgX3ZhbCkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgXA0KPj4+PiArICAgICgoKHR5cGVvZihfbWFzaykpKF92YWwpIDw8IChmZnM2NChfbWFzaykg
LSAxKSkgJiAoX21hc2spKQ0KPj4+PiArDQo+Pj4+ICtzdGF0aWMgaW5saW5lIHVpbnQzMl90IHBh
Y2tfc2NtaV9oZWFkZXIoc2NtaV9tc2dfaGVhZGVyX3QgKmhkcikNCj4+Pj4gK3sNCj4+Pj4gKyAg
ICByZXR1cm4gU0NNSV9GSUVMRF9QUkVQKFNDTUlfSERSX0lELCBoZHItPmlkKSB8DQo+Pj4+ICsg
ICAgICAgICAgIFNDTUlfRklFTERfUFJFUChTQ01JX0hEUl9UWVBFLCBoZHItPnR5cGUpIHwNCj4+
Pj4gKyAgICAgICAgICAgU0NNSV9GSUVMRF9QUkVQKFNDTUlfSERSX1BST1RPLCBoZHItPnByb3Rv
Y29sKTsNCj4+Pj4gK30NCj4+Pj4gKw0KPj4+PiArc3RhdGljIGlubGluZSB2b2lkIHVucGFja19z
Y21pX2hlYWRlcih1aW50MzJfdCBtc2dfaGRyLCBzY21pX21zZ19oZWFkZXJfdCAqaGRyKQ0KPj4+
PiArew0KPj4+PiArICAgIGhkci0+aWQgPSBTQ01JX0ZJRUxEX0dFVChTQ01JX0hEUl9JRCwgbXNn
X2hkcik7DQo+Pj4+ICsgICAgaGRyLT50eXBlID0gU0NNSV9GSUVMRF9HRVQoU0NNSV9IRFJfVFlQ
RSwgbXNnX2hkcik7DQo+Pj4+ICsgICAgaGRyLT5wcm90b2NvbCA9IFNDTUlfRklFTERfR0VUKFND
TUlfSERSX1BST1RPLCBtc2dfaGRyKTsNCj4+Pj4gK30NCj4+Pj4gKw0KPj4+PiArc3RhdGljIGlu
bGluZSBpbnQgc2NtaV90b194ZW5fZXJybm8oaW50IHNjbWlfc3RhdHVzKQ0KPj4+PiArew0KPj4+
PiArICAgIGlmICggc2NtaV9zdGF0dXMgPT0gU0NNSV9TVUNDRVNTICkNCj4+Pj4gKyAgICAgICAg
cmV0dXJuIDA7DQo+Pj4+ICsNCj4+Pj4gKyAgICBzd2l0Y2ggKCBzY21pX3N0YXR1cyApDQo+Pj4+
ICsgICAgew0KPj4+PiArICAgIGNhc2UgU0NNSV9OT1RfU1VQUE9SVEVEOg0KPj4+PiArICAgICAg
ICByZXR1cm4gLUVPUE5PVFNVUFA7DQo+Pj4+ICsgICAgY2FzZSBTQ01JX0lOVkFMSURfUEFSQU1F
VEVSUzoNCj4+Pj4gKyAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+Pj4+ICsgICAgY2FzZSBTQ01J
X0RFTklFRDoNCj4+Pj4gKyAgICAgICAgcmV0dXJuIC1FQUNDRVM7DQo+Pj4+ICsgICAgY2FzZSBT
Q01JX05PVF9GT1VORDoNCj4+Pj4gKyAgICAgICAgcmV0dXJuIC1FTk9FTlQ7DQo+Pj4+ICsgICAg
Y2FzZSBTQ01JX09VVF9PRl9SQU5HRToNCj4+Pj4gKyAgICAgICAgcmV0dXJuIC1FUkFOR0U7DQo+
Pj4+ICsgICAgY2FzZSBTQ01JX0JVU1k6DQo+Pj4+ICsgICAgICAgIHJldHVybiAtRUJVU1k7DQo+
Pj4+ICsgICAgY2FzZSBTQ01JX0NPTU1TX0VSUk9SOg0KPj4+PiArICAgICAgICByZXR1cm4gLUVO
T1RDT05OOw0KPj4+PiArICAgIGNhc2UgU0NNSV9HRU5FUklDX0VSUk9SOg0KPj4+PiArICAgICAg
ICByZXR1cm4gLUVJTzsNCj4+Pj4gKyAgICBjYXNlIFNDTUlfSEFSRFdBUkVfRVJST1I6DQo+Pj4+
ICsgICAgICAgIHJldHVybiAtRU5YSU87DQo+Pj4+ICsgICAgY2FzZSBTQ01JX1BST1RPQ09MX0VS
Uk9SOg0KPj4+PiArICAgICAgICByZXR1cm4gLUVCQURNU0c7DQo+Pj4+ICsgICAgZGVmYXVsdDoN
Cj4+Pj4gKyAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+Pj4+ICsgICAgfQ0KPj4+PiArfQ0KPj4+
PiArDQo+Pj4+ICsvKiBQUk9UT0NPTF9WRVJTSU9OICovDQo+Pj4+ICsjZGVmaW5lIFNDTUlfVkVS
U0lPTl9NSU5PUiBHRU5NQVNLKDE1LCAwKQ0KPj4+PiArI2RlZmluZSBTQ01JX1ZFUlNJT05fTUFK
T1IgR0VOTUFTSygzMSwgMTYpDQo+Pj4+ICsNCj4+Pj4gK3N0cnVjdCBzY21pX21zZ19wcm90X3Zl
cnNpb25fcDJhIHsNCj4+Pj4gKyAgICB1aW50MzJfdCB2ZXJzaW9uOw0KPj4+PiArfSBfX3BhY2tl
ZDsNCj4+Pj4gKw0KPj4+PiArLyogQkFTRSBQUk9UT0NPTF9BVFRSSUJVVEVTICovDQo+Pj4+ICsj
ZGVmaW5lIFNDTUlfQkFTRV9BVFRSX05VTV9QUk9UTyBHRU5NQVNLKDcsIDApDQo+Pj4+ICsjZGVm
aW5lIFNDTUlfQkFTRV9BVFRSX05VTV9BR0VOVCBHRU5NQVNLKDE1LCA4KQ0KPj4+PiArDQo+Pj4+
ICtzdHJ1Y3Qgc2NtaV9tc2dfYmFzZV9hdHRyaWJ1dGVzX3AyYSB7DQo+Pj4+ICsgICAgdWludDMy
X3QgYXR0cmlidXRlczsNCj4+Pj4gK30gX19wYWNrZWQ7DQo+Pj4+ICsNCj4+Pj4gKy8qDQo+Pj4+
ICsgKiBCQVNFX0RJU0NPVkVSX0FHRU5UDQo+Pj4+ICsgKi8NCj4+Pj4gKyNkZWZpbmUgU0NNSV9C
QVNFX0FHRU5UX0lEX09XTiAweEZGRkZGRkZGDQo+Pj4+ICsNCj4+Pj4gK3N0cnVjdCBzY21pX21z
Z19iYXNlX2Rpc2NvdmVyX2FnZW50X2EycCB7DQo+Pj4+ICsgICAgdWludDMyX3QgYWdlbnRfaWQ7
DQo+Pj4+ICt9IF9fcGFja2VkOw0KPj4+PiArDQo+Pj4+ICtzdHJ1Y3Qgc2NtaV9tc2dfYmFzZV9k
aXNjb3Zlcl9hZ2VudF9wMmEgew0KPj4+PiArICAgIHVpbnQzMl90IGFnZW50X2lkOw0KPj4+PiAr
ICAgIGNoYXIgbmFtZVtTQ01JX1NIT1JUX05BTUVfTUFYX1NJWkVdOw0KPj4+PiArfSBfX3BhY2tl
ZDsNCj4+Pj4gKw0KPj4+PiArLyoNCj4+Pj4gKyAqIEJBU0VfU0VUX0RFVklDRV9QRVJNSVNTSU9O
Uw0KPj4+PiArICovDQo+Pj4+ICsjZGVmaW5lIFNDTUlfQkFTRV9ERVZJQ0VfQUNDRVNTX0FMTE9X
ICAgICAgICAgICBCSVQoMCwgVUwpDQo+Pj4+ICsNCj4+Pj4gK3N0cnVjdCBzY21pX21zZ19iYXNl
X3NldF9kZXZpY2VfcGVybWlzc2lvbnNfYTJwIHsNCj4+Pj4gKyAgICB1aW50MzJfdCBhZ2VudF9p
ZDsNCj4+Pj4gKyAgICB1aW50MzJfdCBkZXZpY2VfaWQ7DQo+Pj4+ICsgICAgdWludDMyX3QgZmxh
Z3M7DQo+Pj4+ICt9IF9fcGFja2VkOw0KPj4+PiArDQo+Pj4+ICsvKg0KPj4+PiArICogQkFTRV9S
RVNFVF9BR0VOVF9DT05GSUdVUkFUSU9ODQo+Pj4+ICsgKi8NCj4+Pj4gKyNkZWZpbmUgU0NNSV9C
QVNFX0FHRU5UX1BFUk1JU1NJT05TX1JFU0VUICAgICAgIEJJVCgwLCBVTCkNCj4+Pj4gKw0KPj4+
PiArc3RydWN0IHNjbWlfbXNnX2Jhc2VfcmVzZXRfYWdlbnRfY2ZnX2EycCB7DQo+Pj4+ICsgICAg
dWludDMyX3QgYWdlbnRfaWQ7DQo+Pj4+ICsgICAgdWludDMyX3QgZmxhZ3M7DQo+Pj4+ICt9IF9f
cGFja2VkOw0KPj4+PiArDQo+Pj4+ICsjZW5kaWYgLyogWEVOX0FSQ0hfQVJNX1NDSV9TQ01JX1BS
T1RPX0hfICovDQo+Pj4+ICsNCj4+Pj4gKy8qDQo+Pj4+ICsgKiBMb2NhbCB2YXJpYWJsZXM6DQo+
Pj4+ICsgKiBtb2RlOiBDDQo+Pj4+ICsgKiBjLWZpbGUtc3R5bGU6ICJCU0QiDQo+Pj4+ICsgKiBj
LWJhc2ljLW9mZnNldDogNA0KPj4+PiArICogdGFiLXdpZHRoOiA0DQo+Pj4+ICsgKiBpbmRlbnQt
dGFicy1tb2RlOiBuaWwNCj4+Pj4gKyAqIEVuZDoNCj4+Pj4gKyAqLw0KPj4+PiBkaWZmIC0tZ2l0
IGEveGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktc2htZW0uYyBiL3hlbi9hcmNoL2FybS9maXJt
d2FyZS9zY21pLXNobWVtLmMNCj4+Pj4gbmV3IGZpbGUgbW9kZSAxMDA2NDQNCj4+Pj4gaW5kZXgg
MDAwMDAwMDAwMC4uZGQ2MTNlZTBiNQ0KPj4+PiAtLS0gL2Rldi9udWxsDQo+Pj4+ICsrKyBiL3hl
bi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNobWVtLmMNCj4+Pj4gQEAgLTAsMCArMSwxNzMgQEAN
Cj4+Pj4gKy8qIFNQRFgtTGljZW5zZS1JZGVudGlmaWVyOiBHUEwtMi4wLW9ubHkgKi8NCj4+Pj4g
Ky8qDQo+Pj4+ICsgKiBTQ0kgU0NNSSBtdWx0aS1hZ2VudCBkcml2ZXIsIHVzaW5nIFNNQy9IVkMg
c2htZW0gYXMgdHJhbnNwb3J0Lg0KPj4+PiArICoNCj4+Pj4gKyAqIE9sZWtzaWkgTW9pc2llaWV2
PG9sZWtzaWlfbW9pc2llaWV2QGVwYW0uY29tPg0KPj4+PiArICogQ29weXJpZ2h0IChjKSAyMDI1
IEVQQU0gU3lzdGVtcw0KPj4+PiArICovDQo+Pj4+ICsvKiBTUERYLUxpY2Vuc2UtSWRlbnRpZmll
cjogR1BMLTIuMC1vbmx5ICovDQo+Pj4+ICsNCj4+Pj4gKyNpbmNsdWRlIDxhc20vaW8uaD4NCj4+
Pj4gKyNpbmNsdWRlIDx4ZW4vZXJyLmg+DQo+Pj4+ICsNCj4+Pj4gKyNpbmNsdWRlICJzY21pLXBy
b3RvLmgiDQo+Pj4+ICsjaW5jbHVkZSAic2NtaS1zaG1lbS5oIg0KPj4+IFRoaXMgY29kZSBpcyB3
cml0dGVuIG1vcmUgZ2VuZXJpY2FsbHkgdGhhbiB0aGUgZGVzY3JpcHRpb24gaW1wbGllcy4gSWYN
Cj4+PiB3ZSBvbmx5IHdhbnQgdG8gbWFrZSBTTUMgY2FsbHMgdG8gVEYtQSBvbiBFTDMgYW5kIGV4
Y2hhbmdlIGRhdGEgd2l0aCBpdA0KPj4+IG92ZXIgc2hhcmVkIG1lbW9yeSwgdGhlbiBJIHRoaW5r
Og0KPj4+IC0gd2UgZG9uJ3QgbmVlZCB0aGUgX19pb21lbSB0YWcsIGFzIHRoZXJlIGlzIG5vIE1N
SU8NCj4+PiAtIHdlIG9ubHkgbmVlZCBhIERNQiwgbm90IGEgRFNCIChyZWFkbCBhbmQgd3JpdGVs
IGltcGx5IERTQiwgdXNlIG9ubHkNCj4+PiAgICAgcmVhZGxfcmVsYXhlZCBhbmQgd3JpdGVsX3Jl
bGF4ZWQpDQo+Pj4NCj4+PiBPbiB0aGUgb3RoZXIgaGFuZCwgaWYgd2UgYWxzbyB3YW50IHRvIGhh
bmRsZSB0aGUgY2FzZSB3aGVyZSB0aGUgU0NNSQ0KPj4+IHNlcnZlciBjb3VsZCBiZSBvbiBhIHNl
cGFyYXRlIGNvLXByb2Nlc3NvciwgdGhlbiB3aGF0IHRoaXMgY29kZSBpcyBkb2luZw0KPj4+IGlz
IG5vdCBzdWZmaWNpZW50IGJlY2F1c2Ugd2UgYWxzbyBuZWVkIGEgZGNhY2hlIGZsdXNoLCBpbiBh
ZGRpdGlvbiB0bw0KPj4+IHRoZSBEU0IuDQo+Pj4NCj4+PiBCZXJ0cmFuZCwgY2FuIHlvdSBkb3Vi
bGUtY2hlY2s/DQo+Pj4NCj4+Pg0KPj4+PiArLyoNCj4+Pj4gKyAqIENvcHkgZGF0YSBmcm9tIElP
IG1lbW9yeSBzcGFjZSB0byAicmVhbCIgbWVtb3J5IHNwYWNlLg0KPj4+PiArICovDQo+Pj4+ICtz
dGF0aWMgdm9pZCBfX21lbWNweV9mcm9taW8odm9pZCAqdG8sIGNvbnN0IHZvbGF0aWxlIHZvaWQg
X19pb21lbSAqZnJvbSwNCj4+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBzaXplX3Qg
Y291bnQpDQo+Pj4+ICt7DQo+Pj4+ICsgICAgd2hpbGUgKCBjb3VudCAmJiAhSVNfQUxJR05FRCgo
dW5zaWduZWQgbG9uZylmcm9tLCA0KSApDQo+Pj4+ICsgICAgew0KPj4+PiArICAgICAgICAqKHU4
ICopdG8gPSByZWFkYl9yZWxheGVkKGZyb20pOw0KPj4+PiArICAgICAgICBmcm9tKys7DQo+Pj4+
ICsgICAgICAgIHRvKys7DQo+Pj4+ICsgICAgICAgIGNvdW50LS07DQo+Pj4+ICsgICAgfQ0KPj4+
PiArDQo+Pj4+ICsgICAgd2hpbGUgKCBjb3VudCA+PSA0ICkNCj4+Pj4gKyAgICB7DQo+Pj4+ICsg
ICAgICAgICoodTMyICopdG8gPSByZWFkbF9yZWxheGVkKGZyb20pOw0KPj4+PiArICAgICAgICBm
cm9tICs9IDQ7DQo+Pj4+ICsgICAgICAgIHRvICs9IDQ7DQo+Pj4+ICsgICAgICAgIGNvdW50IC09
IDQ7DQo+Pj4+ICsgICAgfQ0KPj4+PiArDQo+Pj4+ICsgICAgd2hpbGUgKCBjb3VudCApDQo+Pj4+
ICsgICAgew0KPj4+PiArICAgICAgICAqKHU4ICopdG8gPSByZWFkYl9yZWxheGVkKGZyb20pOw0K
Pj4+PiArICAgICAgICBmcm9tKys7DQo+Pj4+ICsgICAgICAgIHRvKys7DQo+Pj4+ICsgICAgICAg
IGNvdW50LS07DQo+Pj4+ICsgICAgfQ0KPj4+PiArfQ0KPj4+PiArDQo+Pj4+ICsvKg0KPj4+PiAr
ICogQ29weSBkYXRhIGZyb20gInJlYWwiIG1lbW9yeSBzcGFjZSB0byBJTyBtZW1vcnkgc3BhY2Uu
DQo+Pj4+ICsgKi8NCj4+Pj4gK3N0YXRpYyB2b2lkIF9fbWVtY3B5X3RvaW8odm9sYXRpbGUgdm9p
ZCBfX2lvbWVtICp0bywgY29uc3Qgdm9pZCAqZnJvbSwNCj4+Pj4gKyAgICAgICAgICAgICAgICAg
ICAgICAgICAgc2l6ZV90IGNvdW50KQ0KPj4+PiArew0KPj4+PiArICAgIHdoaWxlICggY291bnQg
JiYgIUlTX0FMSUdORUQoKHVuc2lnbmVkIGxvbmcpdG8sIDQpICkNCj4+Pj4gKyAgICB7DQo+Pj4+
ICsgICAgICAgIHdyaXRlYl9yZWxheGVkKCoodTggKilmcm9tLCB0byk7DQo+Pj4+ICsgICAgICAg
IGZyb20rKzsNCj4+Pj4gKyAgICAgICAgdG8rKzsNCj4+Pj4gKyAgICAgICAgY291bnQtLTsNCj4+
Pj4gKyAgICB9DQo+Pj4+ICsNCj4+Pj4gKyAgICB3aGlsZSAoIGNvdW50ID49IDQgKQ0KPj4+PiAr
ICAgIHsNCj4+Pj4gKyAgICAgICAgd3JpdGVsX3JlbGF4ZWQoKih1MzIgKilmcm9tLCB0byk7DQo+
Pj4+ICsgICAgICAgIGZyb20gKz0gNDsNCj4+Pj4gKyAgICAgICAgdG8gKz0gNDsNCj4+Pj4gKyAg
ICAgICAgY291bnQgLT0gNDsNCj4+Pj4gKyAgICB9DQo+Pj4+ICsNCj4+Pj4gKyAgICB3aGlsZSAo
IGNvdW50ICkNCj4+Pj4gKyAgICB7DQo+Pj4+ICsgICAgICAgIHdyaXRlYl9yZWxheGVkKCoodTgg
Kilmcm9tLCB0byk7DQo+Pj4+ICsgICAgICAgIGZyb20rKzsNCj4+Pj4gKyAgICAgICAgdG8rKzsN
Cj4+Pj4gKyAgICAgICAgY291bnQtLTsNCj4+Pj4gKyAgICB9DQo+Pj4+ICt9DQo+Pj4gSSBkb24n
dCB1bmRlcnN0YW5kIHdoeSB3ZSBuZWVkIF9fbWVtY3B5X2Zyb21pbyBhbmQgX19tZW1jcHlfdG9p
bzogY2FuJ3QNCj4+PiB3ZSB1c2UgYSBzaW1wbGUgbWVtY3B5Pw0KPj4gVGhpcyBhcHByb2FjaCB3
YXMgdXNlZCBiZWNhdXNlIHdlJ3JlIHRyeWluZyB0byBhY2Nlc3Mgc2hhcmVkIG1lbW9yeQ0KPj4g
YmV0d2VlbiB0d28gaW5kZXBlbmRlbnQgc3lzdGVtczoNCj4+DQo+PiBBcm0tVEYgYW5kIFhlbiBp
biBvdXIgY2FzZSB3aGljaCBwbGFjZXMgc29tZSBjaHVua3Mgb2YgZGF0YSB0byB0aGUgc2FtZQ0K
Pj4gbWVtb3J5LiBBbmQsIGFjY29yZGluZyB0byB0aGUgWzBdDQo+Pg0KPj4gYGBgDQo+Pg0KPj4g
U29tZSBkZXZpY2VzIChzdWNoIGFzIGZyYW1lYnVmZmVycykgd291bGQgbGlrZSB0byB1c2UgbGFy
Z2VyIHRyYW5zZmVycyB0aGFuDQo+PiA4IGJ5dGVzIGF0IGEgdGltZS4gRm9yIHRoZXNlIGRldmlj
ZXMsIHRoZSBtZW1jcHlfdG9pbygpLA0KPj4gbWVtY3B5X2Zyb21pbygpIGFuZCBtZW1zZXRfaW8o
KSBmdW5jdGlvbnMgYXJlDQo+PiBwcm92aWRlZC4gRG8gbm90IHVzZSBtZW1zZXQgb3IgbWVtY3B5
IG9uIElPIGFkZHJlc3NlczsgdGhleSBhcmUgbm90DQo+PiBndWFyYW50ZWVkIHRvIGNvcHkgZGF0
YSBpbiBvcmRlci4NCj4+DQo+PiBgYGANCj4+DQo+PiBBbHNvLCB0aGUgc2FtZSBhcHByb2FjaCB3
YXMgdXNlZCBieSBBcm0gdGVhbSB3aGVuIGludHJvZHVjaW5nIHNjbWkNCj4+IGRyaXZlciB0byB0
aGUgTGludXgga2VybmVsIFsxXQ0KPj4NCj4+DQo+PiBbMF06aHR0cHM6Ly93d3cua2VybmVsLm9y
Zy9kb2MvRG9jdW1lbnRhdGlvbi9kcml2ZXItYXBpL2RldmljZS1pby5yc3QNCj4+DQo+PiBbMV06
aHR0cHM6Ly9naXQuaWxpYW5hLmZ5aS9saW51eC9wYXRjaC8/aWQ9ZDUxNDFmMzdjNDJlMGI4MzM4
NjNmMTU3YWM0Y2VlMjAzYjJiYTNkMg0KPiBLZWVwIGluIG1pbmQgdGhhdCBbMF0gcmVmZXJzIHNw
ZWNpZmljYWxseSB0byBhY2Nlc3MgdG8gTU1JTyByZWdpb25zLiBJDQo+IGFzc3VtZSB0aGF0IHRo
ZSBTQ01JIHNoYXJlZCBidWZmZXJzIGFyZSBvbiBub3JtYWwgbWVtb3J5PyBSZWdhcmRpbmcgWzFd
LA0KPiBpdCBtYWtlcyBzZW5zZSBpZiBMaW51eCBpcyB0cnlpbmcgdG8gc3VwcG9ydCBzaGFyZWQg
bWVtb3J5IG92ZXIgTU1JTy4NCj4NCj4gTG9va2luZyBhdCBvbmUgb2YgeW91ciByZXBsaWVzIGJl
bG93LCBJIGFtIGd1ZXNzaW5nIHRoZSBtZW1vcnkgYnVmZmVycw0KPiBhcmUgYWN0dWFsbHkgaW4g
bm9ybWFsIG1lbW9yeSBidXQgdGhlIGlzc3VlIGlzIHRoYXQgVEYtQSBpcyBtYXBwaW5nIHRoZW0N
Cj4gYXMgdW5jYWNoZWFibGUuIElzIHRoYXQgY29ycmVjdD8NCj4NCj4gSW4gdGhhdCBjYXNlLCBJ
IHN0aWxsIGRvbid0IHVuZGVyc3RhbmQgd2h5IGEgc2ltcGxlIG1lbWNweSB3b3VsZCBub3QgYmUN
Cj4gc3VmZmljaWVudC4gQ2FuIHlvdSBjaGVjaz8NCj4NCj4gSWYgeWVzLCB0aGVuIGZvciBub3cg
SSB3b3VsZCBqdXN0IHNpbXBsaWZ5IGl0IGRvd24gdG8gbWVtY3B5LiBXaGVuDQo+IHNvbWVvbmUg
YWRkcyBzdXBwb3J0IGZvciBhbiBTQ01JIHNlcnZlciBlbHNld2hlcmUgd2UgY291bGQgbG9vayBp
bnRvDQo+IGFkZGluZyBhIG1vcmUgc29waGlzdGljYXRlZCBtZW1jcHkgYW5kIHdlIGNhbiBsb29r
IGF0IHRoZSBkZXRhaWxzIGF0DQo+IHRoYXQgcG9pbnQgaW4gdGltZS4gU3BlY2lmaWNhbGx5LCBJ
IGFtIG5vdCBjb252aW5jZWQgdGhhdCBtZW1jcHlfdG9pbw0KPiBhbmQgbWVtY3B5X2Zyb21pbyB3
b3VsZCB3b3JrIGlmIHRoZSBTQ01JIHNlcnZlciBpcyBvbiBhIHNlcGFyYXRlDQo+IG5vbi1jb2hl
cmVudCBtaWNyb2NvbnRyb2xsZXIuDQo+DQpBY2NvcmRpbmcgdG8gdGhlIFRGLUEgaW1wbGVtZW50
YXRpb24gIFNDTUkgbWVtb3J5DQoNCmlzIG1hcHBlZCB3aXRoIHRoZSAgZmxhZ3M6IE1UX0RFVklD
RSAobGlrZSBmb3IgIHN0bTMybXAxKSBvcg0KTVRfTk9OX0NBQ0hFQUJMRSAoZm9yIHJwaTMpDQoN
ClNvIHByb2JhYmx5IHlvdSdyZSByaWdodC4gSSB3aWxsIGNoZWNrIHdpdGggc2ltcGxlIG1lbWNw
eS4NCg0KPj4+PiArc3RhdGljIGlubGluZSBpbnQNCj4+Pj4gK3NobWVtX2NoYW5uZWxfaXNfZnJl
ZShjb25zdCB2b2xhdGlsZSBzdHJ1Y3Qgc2NtaV9zaGFyZWRfbWVtIF9faW9tZW0gKnNobWVtKQ0K
Pj4+PiArew0KPj4+PiArICAgIHJldHVybiAocmVhZGwoJnNobWVtLT5jaGFubmVsX3N0YXR1cykg
Jg0KPj4+PiArICAgICAgICAgICAgU0NNSV9TSE1FTV9DSEFOX1NUQVRfQ0hBTk5FTF9GUkVFKSA/
IDAgOiAtRUJVU1k7DQo+Pj4+ICt9DQo+Pj4+ICsNCj4+Pj4gK2ludCBzaG1lbV9wdXRfbWVzc2Fn
ZSh2b2xhdGlsZSBzdHJ1Y3Qgc2NtaV9zaGFyZWRfbWVtIF9faW9tZW0gKnNobWVtLA0KPj4+PiAr
ICAgICAgICAgICAgICAgICAgICAgIHNjbWlfbXNnX2hlYWRlcl90ICpoZHIsIHZvaWQgKmRhdGEs
IGludCBsZW4pDQo+Pj4+ICt7DQo+Pj4+ICsgICAgaW50IHJldDsNCj4+Pj4gKw0KPj4+PiArICAg
IGlmICggKGxlbiArIHNpemVvZihzaG1lbS0+bXNnX2hlYWRlcikpID4gU0NNSV9TSE1FTV9NQVBQ
RURfU0laRSApDQo+Pj4+ICsgICAgew0KPj4+PiArICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAi
c2NtaTogV3Jvbmcgc2l6ZSBvZiBzbWMgbWVzc2FnZS4gRGF0YSBpcyBpbnZhbGlkXG4iKTsNCj4+
Pj4gKyAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+Pj4+ICsgICAgfQ0KPj4+PiArDQo+Pj4+ICsg
ICAgcmV0ID0gc2htZW1fY2hhbm5lbF9pc19mcmVlKHNobWVtKTsNCj4+Pj4gKyAgICBpZiAoIHJl
dCApDQo+Pj4+ICsgICAgICAgIHJldHVybiByZXQ7DQo+Pj4+ICsNCj4+Pj4gKyAgICB3cml0ZWxf
cmVsYXhlZCgweDAsICZzaG1lbS0+Y2hhbm5lbF9zdGF0dXMpOw0KPj4+PiArICAgIC8qIFdyaXRp
bmcgMHgwIHJpZ2h0IG5vdywgYnV0ICJzaG1lbSJfRkxBR19JTlRSX0VOQUJMRUQgY2FuIGJlIHNl
dCAqLw0KPj4+PiArICAgIHdyaXRlbF9yZWxheGVkKDB4MCwgJnNobWVtLT5mbGFncyk7DQo+Pj4+
ICsgICAgd3JpdGVsX3JlbGF4ZWQoc2l6ZW9mKHNobWVtLT5tc2dfaGVhZGVyKSArIGxlbiwgJnNo
bWVtLT5sZW5ndGgpOw0KPj4+PiArICAgIHdyaXRlbChwYWNrX3NjbWlfaGVhZGVyKGhkciksICZz
aG1lbS0+bXNnX2hlYWRlcik7DQo+Pj4+ICsNCj4+Pj4gKyAgICBpZiAoIGxlbiA+IDAgJiYgZGF0
YSApDQo+Pj4+ICsgICAgICAgIF9fbWVtY3B5X3RvaW8oc2htZW0tPm1zZ19wYXlsb2FkLCBkYXRh
LCBsZW4pOw0KPj4+PiArDQo+Pj4+ICsgICAgcmV0dXJuIDA7DQo+Pj4+ICt9DQo+Pj4+ICsNCj4+
Pj4gK2ludCBzaG1lbV9nZXRfcmVzcG9uc2UoY29uc3Qgdm9sYXRpbGUgc3RydWN0IHNjbWlfc2hh
cmVkX21lbSBfX2lvbWVtICpzaG1lbSwNCj4+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgc2Nt
aV9tc2dfaGVhZGVyX3QgKmhkciwgdm9pZCAqZGF0YSwgaW50IGxlbikNCj4+Pj4gK3sNCj4+Pj4g
KyAgICBpbnQgcmVjdl9sZW47DQo+Pj4+ICsgICAgaW50IHJldDsNCj4+Pj4gKyAgICBpbnQgcGFk
ID0gc2l6ZW9mKGhkci0+c3RhdHVzKTsNCj4+Pj4gKw0KPj4+PiArICAgIGlmICggbGVuID49IFND
TUlfU0hNRU1fTUFQUEVEX1NJWkUgLSBzaXplb2Yoc2htZW0pICkNCj4+Pj4gKyAgICB7DQo+Pj4+
ICsgICAgICAgIHByaW50ayhYRU5MT0dfRVJSDQo+Pj4+ICsgICAgICAgICAgICAgICAic2NtaTog
V3Jvbmcgc2l6ZSBvZiBpbnB1dCBzbWMgbWVzc2FnZS4gRGF0YSBtYXkgYmUgaW52YWxpZFxuIik7
DQo+Pj4+ICsgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4+PiArICAgIH0NCj4+Pj4gKw0KPj4+
PiArICAgIHJldCA9IHNobWVtX2NoYW5uZWxfaXNfZnJlZShzaG1lbSk7DQo+Pj4+ICsgICAgaWYg
KCByZXQgKQ0KPj4+PiArICAgICAgICByZXR1cm4gcmV0Ow0KPj4+PiArDQo+Pj4+ICsgICAgcmVj
dl9sZW4gPSByZWFkbCgmc2htZW0tPmxlbmd0aCkgLSBzaXplb2Yoc2htZW0tPm1zZ19oZWFkZXIp
Ow0KPj4+PiArDQo+Pj4+ICsgICAgaWYgKCByZWN2X2xlbiA8IDAgKQ0KPj4+PiArICAgIHsNCj4+
Pj4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19FUlINCj4+Pj4gKyAgICAgICAgICAgICAgICJzY21p
OiBXcm9uZyBzaXplIG9mIHNtYyBtZXNzYWdlLiBEYXRhIG1heSBiZSBpbnZhbGlkXG4iKTsNCj4+
Pj4gKyAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+Pj4+ICsgICAgfQ0KPj4+PiArDQo+Pj4+ICsg
ICAgdW5wYWNrX3NjbWlfaGVhZGVyKHJlYWRsKCZzaG1lbS0+bXNnX2hlYWRlciksIGhkcik7DQo+
Pj4+ICsNCj4+Pj4gKyAgICBoZHItPnN0YXR1cyA9IHJlYWRsKCZzaG1lbS0+bXNnX3BheWxvYWQp
Ow0KPj4+PiArICAgIHJlY3ZfbGVuID0gcmVjdl9sZW4gPiBwYWQgPyByZWN2X2xlbiAtIHBhZCA6
IDA7DQo+Pj4+ICsNCj4+Pj4gKyAgICByZXQgPSBzY21pX3RvX3hlbl9lcnJubyhoZHItPnN0YXR1
cyk7DQo+Pj4+ICsgICAgaWYgKCByZXQgKQ0KPj4+PiArICAgIHsNCj4+Pj4gKyAgICAgICAgcHJp
bnRrKFhFTkxPR19ERUJVRyAic2NtaTogRXJyb3IgcmVjZWl2ZWQ6ICVkXG4iLCByZXQpOw0KPj4+
PiArICAgICAgICByZXR1cm4gcmV0Ow0KPj4+PiArICAgIH0NCj4+Pj4gKw0KPj4+PiArICAgIGlm
ICggcmVjdl9sZW4gPiBsZW4gKQ0KPj4+PiArICAgIHsNCj4+Pj4gKyAgICAgICAgcHJpbnRrKFhF
TkxPR19FUlINCj4+Pj4gKyAgICAgICAgICAgICAgICJzY21pOiBOb3QgZW5vdWdoIGJ1ZmZlciBm
b3IgbWVzc2FnZSAlZCwgZXhwZWN0aW5nICVkXG4iLA0KPj4+PiArICAgICAgICAgICAgICAgcmVj
dl9sZW4sIGxlbik7DQo+Pj4+ICsgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4+PiArICAgIH0N
Cj4+Pj4gKw0KPj4+PiArICAgIGlmICggcmVjdl9sZW4gPiAwICkNCj4+Pj4gKyAgICAgICAgX19t
ZW1jcHlfZnJvbWlvKGRhdGEsIHNobWVtLT5tc2dfcGF5bG9hZCArIHBhZCwgcmVjdl9sZW4pOw0K
Pj4+PiArDQo+Pj4+ICsgICAgcmV0dXJuIDA7DQo+Pj4+ICt9DQo+Pj4+ICsNCj4+Pj4gKy8qDQo+
Pj4+ICsgKiBMb2NhbCB2YXJpYWJsZXM6DQo+Pj4+ICsgKiBtb2RlOiBDDQo+Pj4+ICsgKiBjLWZp
bGUtc3R5bGU6ICJCU0QiDQo+Pj4+ICsgKiBjLWJhc2ljLW9mZnNldDogNA0KPj4+PiArICogdGFi
LXdpZHRoOiA0DQo+Pj4+ICsgKiBpbmRlbnQtdGFicy1tb2RlOiBuaWwNCj4+Pj4gKyAqIEVuZDoN
Cj4+Pj4gKyAqLw0KPj4+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWkt
c2htZW0uaCBiL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNobWVtLmgNCj4+Pj4gbmV3IGZp
bGUgbW9kZSAxMDA2NDQNCj4+Pj4gaW5kZXggMDAwMDAwMDAwMC4uMmY4ZTIzZmY3Ng0KPj4+PiAt
LS0gL2Rldi9udWxsDQo+Pj4+ICsrKyBiL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNobWVt
LmgNCj4+Pj4gQEAgLTAsMCArMSw0NSBAQA0KPj4+PiArLyogU1BEWC1MaWNlbnNlLUlkZW50aWZp
ZXI6IEdQTC0yLjAtb25seSAqLw0KPj4+PiArLyoNCj4+Pj4gKyAqIEFybSBTeXN0ZW0gQ29udHJv
bCBhbmQgTWFuYWdlbWVudCBJbnRlcmZhY2UgZGVmaW5pdGlvbnMNCj4+Pj4gKyAqIFZlcnNpb24g
My4wIChERU4wMDU2QykNCj4+Pj4gKyAqIFNoYXJlZCBNZW1vcnkgYmFzZWQgVHJhbnNwb3J0DQo+
Pj4+ICsgKg0KPj4+PiArICogQ29weXJpZ2h0IChjKSAyMDI0IEVQQU0gU3lzdGVtcw0KPj4+PiAr
ICovDQo+Pj4+ICsNCj4+Pj4gKyNpZm5kZWYgWEVOX0FSQ0hfQVJNX1NDSV9TQ01JX1NITUVNX0hf
DQo+Pj4+ICsjZGVmaW5lIFhFTl9BUkNIX0FSTV9TQ0lfU0NNSV9TSE1FTV9IXw0KPj4+IE5JVDog
QVJNX0ZJUk1XQVJFX1NDTUlfU0hNRU1fSA0KPj4+DQo+PiArDQo+Pj4+ICsjaW5jbHVkZSA8eGVu
L3N0ZGludC5oPg0KPj4+PiArDQo+Pj4+ICsjZGVmaW5lIFNDTUlfU0hNRU1fQ0hBTl9TVEFUX0NI
QU5ORUxfRlJFRSAgQklUKDAsIFVMKQ0KPj4+PiArI2RlZmluZSBTQ01JX1NITUVNX0NIQU5fU1RB
VF9DSEFOTkVMX0VSUk9SIEJJVCgxLCBVTCkNCj4+Pj4gKw0KPj4+PiArc3RydWN0IHNjbWlfc2hh
cmVkX21lbSB7DQo+Pj4+ICsgICAgdWludDMyX3QgcmVzZXJ2ZWQ7DQo+Pj4+ICsgICAgdWludDMy
X3QgY2hhbm5lbF9zdGF0dXM7DQo+Pj4+ICsgICAgdWludDMyX3QgcmVzZXJ2ZWQxWzJdOw0KPj4+
PiArICAgIHVpbnQzMl90IGZsYWdzOw0KPj4+PiArICAgIHVpbnQzMl90IGxlbmd0aDsNCj4+Pj4g
KyAgICB1aW50MzJfdCBtc2dfaGVhZGVyOw0KPj4+PiArICAgIHVpbnQ4X3QgbXNnX3BheWxvYWRb
XTsNCj4+Pj4gK307DQo+Pj4+ICsNCj4+Pj4gKyNkZWZpbmUgU0NNSV9TSE1FTV9NQVBQRURfU0la
RSBQQUdFX1NJWkUNCj4+Pj4gKw0KPj4+PiAraW50IHNobWVtX3B1dF9tZXNzYWdlKHZvbGF0aWxl
IHN0cnVjdCBzY21pX3NoYXJlZF9tZW0gX19pb21lbSAqc2htZW0sDQo+Pj4+ICsgICAgICAgICAg
ICAgICAgICAgICAgc2NtaV9tc2dfaGVhZGVyX3QgKmhkciwgdm9pZCAqZGF0YSwgaW50IGxlbik7
DQo+Pj4+ICsNCj4+Pj4gK2ludCBzaG1lbV9nZXRfcmVzcG9uc2UoY29uc3Qgdm9sYXRpbGUgc3Ry
dWN0IHNjbWlfc2hhcmVkX21lbSBfX2lvbWVtICpzaG1lbSwNCj4+Pj4gKyAgICAgICAgICAgICAg
ICAgICAgICAgc2NtaV9tc2dfaGVhZGVyX3QgKmhkciwgdm9pZCAqZGF0YSwgaW50IGxlbik7DQo+
Pj4+ICsjZW5kaWYgLyogWEVOX0FSQ0hfQVJNX1NDSV9TQ01JX1NITUVNX0hfICovDQo+Pj4+ICsN
Cj4+Pj4gKy8qDQo+Pj4+ICsgKiBMb2NhbCB2YXJpYWJsZXM6DQo+Pj4+ICsgKiBtb2RlOiBDDQo+
Pj4+ICsgKiBjLWZpbGUtc3R5bGU6ICJCU0QiDQo+Pj4+ICsgKiBjLWJhc2ljLW9mZnNldDogNA0K
Pj4+PiArICogdGFiLXdpZHRoOiA0DQo+Pj4+ICsgKiBpbmRlbnQtdGFicy1tb2RlOiBuaWwNCj4+
Pj4gKyAqIEVuZDoNCj4+Pj4gKyAqLw0KPj4+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2Zp
cm13YXJlL3NjbWktc21jLW11bHRpYWdlbnQuYyBiL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY21p
LXNtYy1tdWx0aWFnZW50LmMNCj4+Pj4gbmV3IGZpbGUgbW9kZSAxMDA2NDQNCj4+Pj4gaW5kZXgg
MDAwMDAwMDAwMC4uZTAyM2JjYTNhMQ0KPj4+PiAtLS0gL2Rldi9udWxsDQo+Pj4+ICsrKyBiL3hl
bi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNtYy1tdWx0aWFnZW50LmMNCj4+Pj4gQEAgLTAsMCAr
MSw4NjAgQEANCj4+Pj4gKy8qIFNQRFgtTGljZW5zZS1JZGVudGlmaWVyOiBHUEwtMi4wLW9ubHkg
Ki8NCj4+Pj4gKy8qDQo+Pj4+ICsgKiBTQ0kgU0NNSSBtdWx0aS1hZ2VudCBkcml2ZXIsIHVzaW5n
IFNNQy9IVkMgc2htZW0gYXMgdHJhbnNwb3J0Lg0KPj4+PiArICoNCj4+Pj4gKyAqIE9sZWtzaWkg
TW9pc2llaWV2PG9sZWtzaWlfbW9pc2llaWV2QGVwYW0uY29tPg0KPj4+PiArICogQ29weXJpZ2h0
IChjKSAyMDI1IEVQQU0gU3lzdGVtcw0KPj4+PiArICovDQo+Pj4+ICsNCj4+Pj4gKyNpbmNsdWRl
IDx4ZW4vYWNwaS5oPg0KPj4+PiArDQo+Pj4+ICsjaW5jbHVkZSA8eGVuL2RldmljZV90cmVlLmg+
DQo+Pj4+ICsjaW5jbHVkZSA8eGVuL2luaXQuaD4NCj4+Pj4gKyNpbmNsdWRlIDx4ZW4vaW9jYXAu
aD4NCj4+Pj4gKyNpbmNsdWRlIDx4ZW4vZXJyLmg+DQo+Pj4+ICsjaW5jbHVkZSA8eGVuL2xpYmZk
dC9saWJmZHQuaD4NCj4+Pj4gKyNpbmNsdWRlIDx4ZW4vcGFyYW0uaD4NCj4+Pj4gKyNpbmNsdWRl
IDx4ZW4vc2NoZWQuaD4NCj4+Pj4gKyNpbmNsdWRlIDx4ZW4vdm1hcC5oPg0KPj4+PiArDQo+Pj4+
ICsjaW5jbHVkZSA8YXNtL2Zpcm13YXJlL3NjaS5oPg0KPj4+PiArI2luY2x1ZGUgPGFzbS9zbWNj
Yy5oPg0KPj4+PiArDQo+Pj4+ICsjaW5jbHVkZSAic2NtaS1wcm90by5oIg0KPj4+PiArI2luY2x1
ZGUgInNjbWktc2htZW0uaCINCj4+Pj4gKw0KPj4+PiArI2RlZmluZSBTQ01JX0FHRU5UX0lEX0lO
VkFMSUQgMHhGRg0KPj4+PiArDQo+Pj4+ICtzdGF0aWMgdWludDhfdCBfX2luaXRkYXRhIG9wdF9k
b20wX3NjbWlfYWdlbnRfaWQgPSBTQ01JX0FHRU5UX0lEX0lOVkFMSUQ7DQo+Pj4+ICtpbnRlZ2Vy
X3BhcmFtKCJkb20wX3NjbWlfYWdlbnRfaWQiLCBvcHRfZG9tMF9zY21pX2FnZW50X2lkKTsNCj4+
Pj4gKw0KPj4+PiArI2RlZmluZSBTQ01JX1NFQ09OREFSWV9BR0VOVFMgInhlbixzY21pLXNlY29u
ZGFyeS1hZ2VudHMiDQo+Pj4+ICsNCj4+Pj4gKyNkZWZpbmUgSFlQX0NIQU5ORUwgMHgwDQo+Pj4+
ICsNCj4+Pj4gK3N0cnVjdCBzY21pX2NoYW5uZWwgew0KPj4+PiArICAgIHVpbnQzMl90IGFnZW50
X2lkOw0KPj4+PiArICAgIHVpbnQzMl90IGZ1bmNfaWQ7DQo+Pj4+ICsgICAgZG9taWRfdCBkb21h
aW5faWQ7DQo+Pj4+ICsgICAgdWludDY0X3QgcGFkZHI7DQo+Pj4+ICsgICAgdWludDY0X3QgbGVu
Ow0KPj4+PiArICAgIHN0cnVjdCBzY21pX3NoYXJlZF9tZW0gX19pb21lbSAqc2htZW07DQo+Pj4+
ICsgICAgc3BpbmxvY2tfdCBsb2NrOw0KPj4+PiArICAgIHN0cnVjdCBsaXN0X2hlYWQgbGlzdDsN
Cj4+Pj4gK307DQo+Pj4+ICsNCj4+Pj4gK3N0cnVjdCBzY21pX2RhdGEgew0KPj4+PiArICAgIHN0
cnVjdCBsaXN0X2hlYWQgY2hhbm5lbF9saXN0Ow0KPj4+PiArICAgIHNwaW5sb2NrX3QgY2hhbm5l
bF9saXN0X2xvY2s7DQo+Pj4+ICsgICAgdWludDMyX3QgZnVuY19pZDsNCj4+Pj4gKyAgICBib29s
IGluaXRpYWxpemVkOw0KPj4+PiArICAgIHVpbnQzMl90IHNobWVtX3BoYW5kbGU7DQo+Pj4+ICsg
ICAgc3RydWN0IGR0X2RldmljZV9ub2RlICpkdF9kZXY7DQo+Pj4+ICt9Ow0KPj4+PiArDQo+Pj4+
ICtzdGF0aWMgc3RydWN0IHNjbWlfZGF0YSBzY21pX2RhdGE7DQo+Pj4+ICsNCj4+Pj4gK3N0YXRp
YyBpbnQgc2VuZF9zbWNfbWVzc2FnZShzdHJ1Y3Qgc2NtaV9jaGFubmVsICpjaGFuX2luZm8sDQo+
Pj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2NtaV9tc2dfaGVhZGVyX3QgKmhkciwg
dm9pZCAqZGF0YSwgaW50IGxlbikNCj4+Pj4gK3sNCj4+Pj4gKyAgICBzdHJ1Y3QgYXJtX3NtY2Nj
X3JlcyByZXNwOw0KPj4+PiArICAgIGludCByZXQ7DQo+Pj4+ICsNCj4+Pj4gKyAgICByZXQgPSBz
aG1lbV9wdXRfbWVzc2FnZShjaGFuX2luZm8tPnNobWVtLCBoZHIsIGRhdGEsIGxlbik7DQo+Pj4+
ICsgICAgaWYgKCByZXQgKQ0KPj4+PiArICAgICAgICByZXR1cm4gcmV0Ow0KPj4+PiArDQo+Pj4+
ICsgICAgYXJtX3NtY2NjXzFfMV9zbWMoY2hhbl9pbmZvLT5mdW5jX2lkLCAwLCAwLCAwLCAwLCAw
LCAwLCAwLCAmcmVzcCk7DQo+Pj4+ICsNCj4+Pj4gKyAgICBpZiAoIHJlc3AuYTAgKQ0KPj4+PiAr
ICAgICAgICByZXR1cm4gLUVPUE5PVFNVUFA7DQo+Pj4gV2h5IGlmIHJlcG8uYTAgIT0gMCB0aGVu
IHdlIGFzc3VtZSAtRU9QTk9UU1VQUD8gSXMgdGhpcyBwYXJ0IG9mIHRoZSBTQ01JDQo+Pj4gc3Bl
Y2lmaWNhdGlvbj8NCj4+IFBsZWFzZSBzZWUgNy4xIG9mIFsxXS4gVGhlIGZvbGxvd2luZyBjb2Rl
cyBhcmUgc3VwcG9ydGVkIDoNCj4+DQo+PiAwIGZvciBzdWNjZXNzDQo+Pg0KPj4gLTEgYXMgbm90
X3N1cHBvcnRlZA0KPj4NCj4+IC0yIGFzIG5vdF9yZXF1aXJlZA0KPj4NCj4+IC0zIGFzIGludmFs
aWRfcGFyYW1ldGVyLg0KPj4NCj4+IEZvciBhbGwgbm9uLXplcm8gcmVzdWx0cyB3ZSBhc3N1bWUg
dGhhdCB0aGlzIGNhbGwgaXMgbm90IHN1cHBvcnRlZCBieQ0KPj4gc3lzdGVtIG9yIGhhcyBkaWZm
ZXJlbnQgcmV2aXNpb24NCj4+DQo+PiB3aGljaCB3ZSBhbHNvIGRvZXNuJ3Qgc3VwcG9ydC4NCj4g
Rm9yIC0xIGFuZCAtMiBtYWtlIHNlbnNlLiBJIGFtIGxlc3Mgc3VyZSBhYm91dCBjb252ZXJ0aW5n
IC0zIGludG8NCj4gLUVPUE5PVFNVUFAuIEJ1dCBJJ2xsIHRydXN0IHlvdXIganVkZ21lbnQuDQo+
DQpJIGFncmVlLCBJIHdpbGwgcmV0dXJuIC1FSU5WQUwgZm9yIC0zIHJldHVybiBjb2RlLg0KPj4g
WzFdIERFTjAwMjgNCj4+IGh0dHBzOi8vZG9jdW1lbnRhdGlvbi1zZXJ2aWNlLmFybS5jb20vc3Rh
dGljLzVmOGVkYWVmZjg2ZTE2NTE1Y2RiZTRjNg0KPj4+PiArICAgIHJldHVybiAwOw0KPj4+PiAr
fQ0KPj4+PiArDQo+Pj4+ICtzdGF0aWMgaW50IGRvX3NtY194ZmVyKHN0cnVjdCBzY21pX2NoYW5u
ZWwgKmNoYW5faW5mbywgc2NtaV9tc2dfaGVhZGVyX3QgKmhkciwNCj4+Pj4gKyAgICAgICAgICAg
ICAgICAgICAgICAgdm9pZCAqdHhfZGF0YSwgaW50IHR4X3NpemUsIHZvaWQgKnJ4X2RhdGEsIGlu
dCByeF9zaXplKQ0KPj4+PiArew0KPj4+PiArICAgIGludCByZXQgPSAwOw0KPj4+PiArDQo+Pj4+
ICsgICAgQVNTRVJUKGNoYW5faW5mbyAmJiBjaGFuX2luZm8tPnNobWVtKTsNCj4+Pj4gKw0KPj4+
PiArICAgIGlmICggIWhkciApDQo+Pj4+ICsgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4+PiAr
DQo+Pj4+ICsgICAgc3Bpbl9sb2NrKCZjaGFuX2luZm8tPmxvY2spOw0KPj4+PiArDQo+Pj4+ICsg
ICAgcHJpbnRrKFhFTkxPR19ERUJVRw0KPj4+PiArICAgICAgICAgICAic2NtaTogYWdlbnRfaWQg
PSAlZCBtc2dfaWQgPSAleCB0eXBlID0gJWQsIHByb3RvID0gJXhcbiIsDQo+Pj4+ICsgICAgICAg
ICAgIGNoYW5faW5mby0+YWdlbnRfaWQsIGhkci0+aWQsIGhkci0+dHlwZSwgaGRyLT5wcm90b2Nv
bCk7DQo+Pj4+ICsNCj4+Pj4gKyAgICByZXQgPSBzZW5kX3NtY19tZXNzYWdlKGNoYW5faW5mbywg
aGRyLCB0eF9kYXRhLCB0eF9zaXplKTsNCj4+Pj4gKyAgICBpZiAoIHJldCApDQo+Pj4+ICsgICAg
ICAgIGdvdG8gY2xlYW47DQo+Pj4+ICsNCj4+Pj4gKyAgICByZXQgPSBzaG1lbV9nZXRfcmVzcG9u
c2UoY2hhbl9pbmZvLT5zaG1lbSwgaGRyLCByeF9kYXRhLCByeF9zaXplKTsNCj4+Pj4gKw0KPj4+
PiArY2xlYW46DQo+Pj4+ICsgICAgcHJpbnRrKFhFTkxPR19ERUJVRw0KPj4+PiArICAgICAgICAg
ICAic2NtaTogZ2V0IHNtYyByZXNwb25zZSBhZ2VudF9pZCA9ICVkIG1zZ19pZCA9ICV4IHByb3Rv
ID0gJXggcmVzPSVkXG4iLA0KPj4+PiArICAgICAgICAgICBjaGFuX2luZm8tPmFnZW50X2lkLCBo
ZHItPmlkLCBoZHItPnByb3RvY29sLCByZXQpOw0KPj4+PiArDQo+Pj4+ICsgICAgc3Bpbl91bmxv
Y2soJmNoYW5faW5mby0+bG9jayk7DQo+Pj4+ICsNCj4+Pj4gKyAgICByZXR1cm4gcmV0Ow0KPj4+
PiArfQ0KPj4+PiArDQo+Pj4+ICtzdGF0aWMgc3RydWN0IHNjbWlfY2hhbm5lbCAqZ2V0X2NoYW5u
ZWxfYnlfaWQodWludDMyX3QgYWdlbnRfaWQpDQo+Pj4+ICt7DQo+Pj4+ICsgICAgc3RydWN0IHNj
bWlfY2hhbm5lbCAqY3VycjsNCj4+Pj4gKyAgICBib29sIGZvdW5kID0gZmFsc2U7DQo+Pj4+ICsN
Cj4+Pj4gKyAgICBzcGluX2xvY2soJnNjbWlfZGF0YS5jaGFubmVsX2xpc3RfbG9jayk7DQo+Pj4+
ICsgICAgbGlzdF9mb3JfZWFjaF9lbnRyeShjdXJyLCAmc2NtaV9kYXRhLmNoYW5uZWxfbGlzdCwg
bGlzdCkNCj4+Pj4gKyAgICB7DQo+Pj4+ICsgICAgICAgIGlmICggY3Vyci0+YWdlbnRfaWQgPT0g
YWdlbnRfaWQgKQ0KPj4+PiArICAgICAgICB7DQo+Pj4+ICsgICAgICAgICAgICBmb3VuZCA9IHRy
dWU7DQo+Pj4+ICsgICAgICAgICAgICBicmVhazsNCj4+Pj4gKyAgICAgICAgfQ0KPj4+PiArICAg
IH0NCj4+Pj4gKw0KPj4+PiArICAgIHNwaW5fdW5sb2NrKCZzY21pX2RhdGEuY2hhbm5lbF9saXN0
X2xvY2spOw0KPj4+PiArICAgIGlmICggZm91bmQgKQ0KPj4+PiArICAgICAgICByZXR1cm4gY3Vy
cjsNCj4+Pj4gKw0KPj4+PiArICAgIHJldHVybiBOVUxMOw0KPj4+PiArfQ0KPj4+PiArDQo+Pj4+
ICtzdGF0aWMgc3RydWN0IHNjbWlfY2hhbm5lbCAqYWNxdWlyZV9zY21pX2NoYW5uZWwoc3RydWN0
IGRvbWFpbiAqZCwNCj4+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICB1aW50MzJfdCBhZ2VudF9pZCkNCj4+Pj4gK3sNCj4+Pj4gKyAgICBzdHJ1Y3Qg
c2NtaV9jaGFubmVsICpjdXJyOw0KPj4+PiArICAgIHN0cnVjdCBzY21pX2NoYW5uZWwgKnJldCA9
IEVSUl9QVFIoLUVOT0VOVCk7DQo+Pj4+ICsNCj4+Pj4gKyAgICBzcGluX2xvY2soJnNjbWlfZGF0
YS5jaGFubmVsX2xpc3RfbG9jayk7DQo+Pj4+ICsgICAgbGlzdF9mb3JfZWFjaF9lbnRyeShjdXJy
LCAmc2NtaV9kYXRhLmNoYW5uZWxfbGlzdCwgbGlzdCkNCj4+Pj4gKyAgICB7DQo+Pj4+ICsgICAg
ICAgIGlmICggY3Vyci0+YWdlbnRfaWQgPT0gYWdlbnRfaWQgKQ0KPj4+PiArICAgICAgICB7DQo+
Pj4+ICsgICAgICAgICAgICBpZiAoIGN1cnItPmRvbWFpbl9pZCAhPSBET01JRF9JTlZBTElEICkN
Cj4+Pj4gKyAgICAgICAgICAgIHsNCj4+Pj4gKyAgICAgICAgICAgICAgICByZXQgPSBFUlJfUFRS
KC1FRVhJU1QpOw0KPj4+PiArICAgICAgICAgICAgICAgIGJyZWFrOw0KPj4+PiArICAgICAgICAg
ICAgfQ0KPj4+PiArDQo+Pj4+ICsgICAgICAgICAgICBjdXJyLT5kb21haW5faWQgPSBkLT5kb21h
aW5faWQ7DQo+Pj4+ICsgICAgICAgICAgICByZXQgPSBjdXJyOw0KPj4+PiArICAgICAgICAgICAg
YnJlYWs7DQo+Pj4+ICsgICAgICAgIH0NCj4+Pj4gKyAgICB9DQo+Pj4+ICsNCj4+Pj4gKyAgICBz
cGluX3VubG9jaygmc2NtaV9kYXRhLmNoYW5uZWxfbGlzdF9sb2NrKTsNCj4+Pj4gKw0KPj4+PiAr
ICAgIHJldHVybiByZXQ7DQo+Pj4+ICt9DQo+Pj4+ICsNCj4+Pj4gK3N0YXRpYyB2b2lkIHJlbGlu
cXVpc2hfc2NtaV9jaGFubmVsKHN0cnVjdCBzY21pX2NoYW5uZWwgKmNoYW5uZWwpDQo+Pj4+ICt7
DQo+Pj4+ICsgICAgQVNTRVJUKGNoYW5uZWwgIT0gTlVMTCk7DQo+Pj4+ICsNCj4+Pj4gKyAgICBz
cGluX2xvY2soJnNjbWlfZGF0YS5jaGFubmVsX2xpc3RfbG9jayk7DQo+Pj4+ICsgICAgY2hhbm5l
bC0+ZG9tYWluX2lkID0gRE9NSURfSU5WQUxJRDsNCj4+Pj4gKyAgICBzcGluX3VubG9jaygmc2Nt
aV9kYXRhLmNoYW5uZWxfbGlzdF9sb2NrKTsNCj4+Pj4gK30NCj4+Pj4gKw0KPj4+PiArc3RhdGlj
IGludCBtYXBfY2hhbm5lbF9tZW1vcnkoc3RydWN0IHNjbWlfY2hhbm5lbCAqY2hhbm5lbCkNCj4+
Pj4gK3sNCj4+Pj4gKyAgICBBU1NFUlQoY2hhbm5lbCAmJiBjaGFubmVsLT5wYWRkcik7DQo+Pj4+
ICsgICAgY2hhbm5lbC0+c2htZW0gPSBpb3JlbWFwX25vY2FjaGUoY2hhbm5lbC0+cGFkZHIsIFND
TUlfU0hNRU1fTUFQUEVEX1NJWkUpOw0KPj4+IGlvcmVtYXAgaXMgZm9yIE1NSU8sIGlmIHRoZXNl
IHNoYXJlZCBtZW1vcnkgY2hhbm5lbHMgYXJlIG9uIEREUiwgdGhlbiBpdA0KPj4+IHdvdWxkIG5v
dCBiZSB0aGUgcmlnaHQgY2FsbC4gQXJlIHRoZSAiYXJtLHNjbWktc2htZW0iIGFkZHJlc3MgcmFu
Z2VzDQo+Pj4gcGFydCBvZiB0aGUgbWVtb3J5IG5vZGUgcmFuZ2VzPyBPciBhcmUgdGhleSBjb21w
bGV0ZWx5IHNlcGFyYXRlPw0KPj4+DQo+Pj4gQWxzbywgd2h5IG5vY2FjaGU/IFdvdWxkbid0IHdl
IHdhbnQgaW9yZW1hcF9jYWNoZT8NCj4+Pg0KPj4gQ3VycmVudGx5LCB0aGV5IGFyZSBzZXBhcmF0
ZSBub2RlcyBidXQgY291bGQgcG90ZW50aWFsbHkgYmUgcGFydCBvZiB0aGUNCj4+ICJtZW1vcnkt
cmVnaW9uIi4NCj4+DQo+PiAgIEZyb20gd2hhdCBJIHNlZSBpbiB0aGUgTGludXgga2VybmVsLCBk
ZXZtX2lvcmVtYXAgaXMgYmVpbmcgdXNlZCB0byBtYXANCj4+IHRoZSBtZW1vcnkuDQo+Pg0KPj4g
Q291bGQgdGhlcmUgYmUgc29tZXRoaW5nIG1vcmUgdG8gdGhpcyBhcHByb2FjaD8NCj4+DQo+PiBb
MF06aHR0cHM6Ly9naXQuaWxpYW5hLmZ5aS9saW51eC9wYXRjaC8/aWQ9MWRjNjU1ODA2MmRhZGZh
YmQyZmIzYmQ4ODVmYTZlOTJlYzcxOTZmMg0KPiBJIGFtIGd1ZXNzaW5nIHRoYXQgVEYtQSBpcyBt
YXBwaW5nIG1lbW9yeSBhcyB1bmNhY2hlYWJsZSBzbyB3ZSBzaG91bGQgZG8NCj4gdGhlIHNhbWUg
aW4gWGVuLg0KQWdyZWUuDQo+Pj4+ICsgICAgaWYgKCAhY2hhbm5lbC0+c2htZW0gKQ0KPj4+PiAr
ICAgICAgICByZXR1cm4gLUVOT01FTTsNCj4+Pj4gKw0KPj4+PiArICAgIGNoYW5uZWwtPnNobWVt
LT5jaGFubmVsX3N0YXR1cyA9IFNDTUlfU0hNRU1fQ0hBTl9TVEFUX0NIQU5ORUxfRlJFRTsNCj4+
Pj4gKyAgICBwcmludGsoWEVOTE9HX0RFQlVHICJzY21pOiBHb3Qgc2htZW0gJWx4IGFmdGVyIHZt
YXAgJXBcbiIsIGNoYW5uZWwtPnBhZGRyLA0KPj4+PiArICAgICAgICAgICBjaGFubmVsLT5zaG1l
bSk7DQo+Pj4+ICsNCj4+Pj4gKyAgICByZXR1cm4gMDsNCj4+Pj4gK30NCj4+Pj4gKw0KPj4+PiAr
c3RhdGljIHZvaWQgdW5tYXBfY2hhbm5lbF9tZW1vcnkoc3RydWN0IHNjbWlfY2hhbm5lbCAqY2hh
bm5lbCkNCj4+Pj4gK3sNCj4+Pj4gKyAgICBBU1NFUlQoY2hhbm5lbCAmJiBjaGFubmVsLT5zaG1l
bSk7DQo+Pj4+ICsgICAgaW91bm1hcChjaGFubmVsLT5zaG1lbSk7DQo+Pj4+ICsgICAgY2hhbm5l
bC0+c2htZW0gPSBOVUxMOw0KPj4+PiArfQ0KPj4+PiArDQo+Pj4+ICtzdGF0aWMgc3RydWN0IHNj
bWlfY2hhbm5lbCAqc21jX2NyZWF0ZV9jaGFubmVsKHVpbnQzMl90IGFnZW50X2lkLA0KPj4+PiAr
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCBm
dW5jX2lkLCB1aW50NjRfdCBhZGRyKQ0KPj4+PiArew0KPj4+PiArICAgIHN0cnVjdCBzY21pX2No
YW5uZWwgKmNoYW5uZWw7DQo+Pj4+ICsNCj4+Pj4gKyAgICBjaGFubmVsID0gZ2V0X2NoYW5uZWxf
YnlfaWQoYWdlbnRfaWQpOw0KPj4+PiArICAgIGlmICggY2hhbm5lbCApDQo+Pj4+ICsgICAgICAg
IHJldHVybiBFUlJfUFRSKEVFWElTVCk7DQo+Pj4+ICsNCj4+Pj4gKyAgICBjaGFubmVsID0geG1h
bGxvYyhzdHJ1Y3Qgc2NtaV9jaGFubmVsKTsNCj4+Pj4gKyAgICBpZiAoICFjaGFubmVsICkNCj4+
Pj4gKyAgICAgICAgcmV0dXJuIEVSUl9QVFIoRU5PTUVNKTsNCj4+Pj4gKw0KPj4+PiArICAgIHNw
aW5fbG9ja19pbml0KCZjaGFubmVsLT5sb2NrKTsNCj4+Pj4gKyAgICBjaGFubmVsLT5hZ2VudF9p
ZCA9IGFnZW50X2lkOw0KPj4+PiArICAgIGNoYW5uZWwtPmZ1bmNfaWQgPSBmdW5jX2lkOw0KPj4+
PiArICAgIGNoYW5uZWwtPmRvbWFpbl9pZCA9IERPTUlEX0lOVkFMSUQ7DQo+Pj4+ICsgICAgY2hh
bm5lbC0+c2htZW0gPSBOVUxMOw0KPj4+PiArICAgIGNoYW5uZWwtPnBhZGRyID0gYWRkcjsNCj4+
Pj4gKyAgICBsaXN0X2FkZF90YWlsKCZjaGFubmVsLT5saXN0LCAmc2NtaV9kYXRhLmNoYW5uZWxf
bGlzdCk7DQo+Pj4+ICsgICAgcmV0dXJuIGNoYW5uZWw7DQo+Pj4+ICt9DQo+Pj4+ICsNCj4+Pj4g
K3N0YXRpYyB2b2lkIGZyZWVfY2hhbm5lbF9saXN0KHZvaWQpDQo+Pj4+ICt7DQo+Pj4+ICsgICAg
c3RydWN0IHNjbWlfY2hhbm5lbCAqY3VyciwgKl9jdXJyOw0KPj4+PiArDQo+Pj4+ICsgICAgbGlz
dF9mb3JfZWFjaF9lbnRyeV9zYWZlKGN1cnIsIF9jdXJyLCAmc2NtaV9kYXRhLmNoYW5uZWxfbGlz
dCwgbGlzdCkNCj4+Pj4gKyAgICB7DQo+Pj4+ICsgICAgICAgIGxpc3RfZGVsKCZjdXJyLT5saXN0
KTsNCj4+Pj4gKyAgICAgICAgeGZyZWUoY3Vycik7DQo+Pj4+ICsgICAgfQ0KPj4+PiArfQ0KPj4+
PiArDQo+Pj4+ICtzdGF0aWMgaW50IF9faW5pdA0KPj4+PiArc2NtaV9kdF9yZWFkX2h5cF9jaGFu
bmVsX2FkZHIoc3RydWN0IGR0X2RldmljZV9ub2RlICpzY21pX25vZGUsIHU2NCAqYWRkciwNCj4+
Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHU2NCAqc2l6ZSkNCj4+Pj4gK3sNCj4+
Pj4gKyAgICBzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKnNobWVtX25vZGU7DQo+Pj4+ICsgICAgY29u
c3QgX19iZTMyICpwcm9wOw0KPj4+PiArDQo+Pj4+ICsgICAgcHJvcCA9IGR0X2dldF9wcm9wZXJ0
eShzY21pX25vZGUsICJzaG1lbSIsIE5VTEwpOw0KPj4+PiArICAgIGlmICggIXByb3AgKQ0KPj4+
PiArICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+Pj4gKw0KPj4+PiArICAgIHNobWVtX25vZGUg
PSBkdF9maW5kX25vZGVfYnlfcGhhbmRsZShiZTMyX3RvX2NwdXAocHJvcCkpOw0KPj4+PiArICAg
IGlmICggSVNfRVJSX09SX05VTEwoc2htZW1fbm9kZSkgKQ0KPj4+PiArICAgIHsNCj4+Pj4gKyAg
ICAgICAgcHJpbnRrKFhFTkxPR19FUlINCj4+Pj4gKyAgICAgICAgICAgICAgICJzY21pOiBEZXZp
Y2UgdHJlZSBlcnJvciwgY2FuJ3QgcGFyc2UgcmVzZXJ2ZWQgbWVtb3J5ICVsZFxuIiwNCj4+Pj4g
KyAgICAgICAgICAgICAgIFBUUl9FUlIoc2htZW1fbm9kZSkpOw0KPj4+PiArICAgICAgICByZXR1
cm4gUFRSX0VSUihzaG1lbV9ub2RlKTsNCj4+Pj4gKyAgICB9DQo+Pj4+ICsNCj4+Pj4gKyAgICBy
ZXR1cm4gZHRfZGV2aWNlX2dldF9hZGRyZXNzKHNobWVtX25vZGUsIDAsIGFkZHIsIHNpemUpOw0K
Pj4+PiArfQ0KPj4+PiArDQo+Pj4+ICsvKg0KPj4+PiArICogSGFuZGxlIERvbTAgU0NNSSBzcGVj
aWZpYyBEVCBub2Rlcw0KPj4+PiArICoNCj4+Pj4gKyAqIE1ha2UgYSBkZWNpc2lvbiBvbiBjb3B5
aW5nIFNDTUkgc3BlY2lmaWMgbm9kZXMgaW50byBEb20wIGRldmljZSB0cmVlLg0KPj4+PiArICog
Rm9yIFNDTUkgbXVsdGktYWdlbnQgY2FzZToNCj4+Pj4gKyAqIC0gc2htZW0gbm9kZXMgd2lsbCBu
b3QgYmUgY29waWVkIGFuZCBnZW5lcmF0ZWQgaW5zdGVhZCBpZiBTQ01JDQo+Pj4+ICsgKiAgIGlz
IGVuYWJsZWQgZm9yIERvbTANCj4+Pj4gKyAqIC0gc2NtaSBub2RlIHdpbGwgYmUgY29waWVkIGlm
IFNDTUkgaXMgZW5hYmxlZCBmb3IgRG9tMA0KPj4+PiArICovDQo+Pj4+ICtzdGF0aWMgYm9vbCBz
Y21pX2R0X2hhbmRsZV9ub2RlKHN0cnVjdCBkb21haW4gKmQsIHN0cnVjdCBkdF9kZXZpY2Vfbm9k
ZSAqbm9kZSkNCj4+Pj4gK3sNCj4+Pj4gKyAgICBzdGF0aWMgY29uc3Qgc3RydWN0IGR0X2Rldmlj
ZV9tYXRjaCBza2lwX21hdGNoZXNbXSBfX2luaXRjb25zdCA9IHsNCj4+Pj4gKyAgICAgICAgRFRf
TUFUQ0hfQ09NUEFUSUJMRSgiYXJtLHNjbWktc2htZW0iKSwNCj4+Pj4gKyAgICAgICAgeyAvKiBz
ZW50aW5lbCAqLyB9LA0KPj4+PiArICAgIH07DQo+Pj4+ICsgICAgc3RhdGljIGNvbnN0IHN0cnVj
dCBkdF9kZXZpY2VfbWF0Y2ggc2NtaV9tYXRjaGVzW10gX19pbml0Y29uc3QgPSB7DQo+Pj4+ICsg
ICAgICAgIERUX01BVENIX1BBVEgoIi9maXJtd2FyZS9zY21pIiksDQo+Pj4+ICsgICAgICAgIHsg
Lyogc2VudGluZWwgKi8gfSwNCj4+Pj4gKyAgICB9Ow0KPj4+PiArDQo+Pj4+ICsgICAgaWYgKCAh
c2NtaV9kYXRhLmluaXRpYWxpemVkICkNCj4+Pj4gKyAgICAgICAgcmV0dXJuIGZhbHNlOw0KPj4+
PiArDQo+Pj4+ICsgICAgLyogYWx3YXlzIGRyb3Agc2htZW0gKi8NCj4+Pj4gKyAgICBpZiAoIGR0
X21hdGNoX25vZGUoc2tpcF9tYXRjaGVzLCBub2RlKSApDQo+Pj4+ICsgICAgew0KPj4+PiArICAg
ICAgICBkdF9kcHJpbnRrKCIgIFNraXAgc2NtaSBzaG1lbVxuIik7DQo+Pj4+ICsgICAgICAgIHJl
dHVybiB0cnVlOw0KPj4+PiArICAgIH0NCj4+Pj4gKw0KPj4+PiArICAgIC8qIGRyb3Agc2NtaSBp
ZiBub3QgZW5hYmxlZCAqLw0KPj4+PiArICAgIGlmICggZHRfbWF0Y2hfbm9kZShzY21pX21hdGNo
ZXMsIG5vZGUpICYmICFzY2lfZG9tYWluX2lzX2VuYWJsZWQoZCkgKQ0KPj4+PiArICAgIHsNCj4+
Pj4gKyAgICAgICAgZHRfZHByaW50aygiICBTa2lwIHNjbWkgbm9kZVxuIik7DQo+Pj4+ICsgICAg
ICAgIHJldHVybiB0cnVlOw0KPj4+PiArICAgIH0NCj4+Pj4gKw0KPj4+PiArICAgIHJldHVybiBm
YWxzZTsNCj4+Pj4gK30NCj4+Pj4gKw0KPj4+PiArLyoNCj4+Pj4gKyAqIEZpbmFsaXplIERvbTAg
U0NNSSBzcGVjaWZpYyBEVCBub2Rlcw0KPj4+PiArICoNCj4+Pj4gKyAqIGlmIFNDTUkgaXMgZW5h
YmxlZCBmb3IgRG9tMDoNCj4+Pj4gKyAqIC0gZ2VuZXJhdGUgc2htZW0gbm9kZQ0KPj4+PiArICog
LSBtYXAgU0NNSSBzaG1lbSBNTUlPIGludG8gRG9tMA0KPj4+PiArICovDQo+Pj4+ICtzdGF0aWMg
aW50IHNjbWlfZHRfZmluYWxpemUoc3RydWN0IGRvbWFpbiAqZCwgdm9pZCAqZmR0KQ0KPj4+PiAr
ew0KPj4+PiArICAgIF9fYmUzMiByZWdbR1VFU1RfUk9PVF9BRERSRVNTX0NFTExTICsgR1VFU1Rf
Uk9PVF9TSVpFX0NFTExTXTsNCj4+Pj4gKyAgICBzdHJ1Y3Qgc2NtaV9jaGFubmVsICpjaGFubmVs
Ow0KPj4+PiArICAgIGludCBub2Rlb2Zmc2V0Ow0KPj4+PiArICAgIF9fYmUzMiAqY2VsbHM7DQo+
Pj4+ICsgICAgX19iZTMyIHZhbDsNCj4+Pj4gKyAgICBjaGFyIGJ1Zls2NF07DQo+Pj4+ICsgICAg
aW50IHJlcywgcmM7DQo+Pj4+ICsNCj4+Pj4gKyAgICBpZiAoICFzY2lfZG9tYWluX2lzX2VuYWJs
ZWQoZCkgKQ0KPj4+PiArICAgICAgICByZXR1cm4gMDsNCj4+Pj4gKw0KPj4+PiArICAgIGNoYW5u
ZWwgPSBkLT5hcmNoLnNjaV9kYXRhOw0KPj4+PiArDQo+Pj4+ICsgICAgLyoNCj4+Pj4gKyAgICAg
KiBSZXBsYWNlICJhcm0sc21jLWlkIiB3aXRoIHByb3BlciB2YWx1ZSBhc3NpZ25lZCBmb3IgRG9t
MCBTQ01JIGNoYW5uZWwNCj4+Pj4gKyAgICAgKi8NCj4+Pj4gKyAgICBub2Rlb2Zmc2V0ID0gZmR0
X25vZGVfb2Zmc2V0X2J5X2NvbXBhdGlibGUoZmR0LCAtMSwgImFybSxzY21pLXNtYyIpOw0KPj4+
PiArICAgIGlmICggbm9kZW9mZnNldCA8IDAgKQ0KPj4+PiArICAgICAgICByZXR1cm4gLUVOT0RF
VjsNCj4+Pj4gKw0KPj4+PiArICAgIGNlbGxzID0gKF9fYmUzMiAqKSZ2YWw7DQo+Pj4+ICsgICAg
ZHRfc2V0X2NlbGwoJmNlbGxzLCAxLCBjaGFubmVsLT5mdW5jX2lkKTsNCj4+Pj4gKyAgICByZXMg
PSBmZHRfc2V0cHJvcF9pbnBsYWNlKGZkdCwgbm9kZW9mZnNldCwgImFybSxzbWMtaWQiLCAmdmFs
LCBzaXplb2YodmFsKSk7DQo+Pj4+ICsgICAgaWYgKCByZXMgKQ0KPj4+PiArICAgICAgICByZXR1
cm4gLUVJTlZBTDsNCj4+Pj4gKw0KPj4+IEFyZSB5b3Ugc3VyZSBpdCBpcyB3b3J0aCB0byBnbyB0
aHJvdWdoIGFsbCB0aGlzIHRyb3VibGUgdG8gbW9kaWZ5IEZEVCBpbg0KPj4+IHBsYWNlIHdoZW4g
d2UgY291bGQgc2ltcGx5IGdlbmVyYXRlIHRoZSBEVCBub2RlIGZyb20gc2NyYXRjaCBsaWtlIHdl
IGRvDQo+Pj4gZm9yIGV4YW1wbGUgZm9yIHRoZSBHSUM/IFRoaXMgc2VlbXMgdG8gYmUgbW9yZSBl
cnJvciBwcm9uZSBhcyB3ZWxsLiBJcw0KPj4+IGdlbmVyYXRpbmcgaXQgZnJvbSBzY3JhdGNoIGlz
IHJlYWxseSBkaWZmaWN1bHQ/IElmIGl0IGlzIGRpZmZpY3VsdCB0aGVuIE9LLg0KPj4+DQo+PiBJ
biB0aGUgbGFzdCBwYXRjaCBbMF0gb2YgdGhlIHNlcmllcywgdGhlcmUgaXMgYSBwcm9wb3NhbCB0
byBzZXBhcmF0ZQ0KPj4NCj4+ICAgIHRoZSBYZW4gcHJpdmlsZWdlZCBhZ2VudCBmcm9tIHRoZSBE
b20wIGFnZW50LiBUaGlzIGVsaW1pbmF0ZXMgdGhlDQo+Pg0KPj4gbmVlZCB0byBtb2RpZnkgdGhl
IFhlbiBEZXZpY2UgVHJlZSBCbG9iIChEVEIpLCB3aGljaCBpcyBhIHBvc2l0aXZlDQo+PiBpbXBy
b3ZlbWVudA0KPj4NCj4+IHNpbmNlIHRoZSBEb20wIGFnZW50IG5vZGUgaXMgYWxyZWFkeSBwcmVz
ZW50IGluIHRoZSBkZXZpY2UgdHJlZS4NCj4+DQo+PiBIb3dldmVyLCB0aGUgaXNzdWUgd2l0aCBT
Q01JIG5vZGUgZ2VuZXJhdGlvbiBsaWVzIGluIHRoZSBuZWVkIHRvIGhhbmRsZQ0KPj4NCj4+IHRo
ZSBsaXN0IG9mIHByb3RvY29scyB0aGF0IGFyZSBzdXBwb3J0ZWQgYWNyb3NzIHRoZSBzeXN0ZW0u
DQo+Pg0KPj4gSWYgd2Ugd2FudCB0byBnZW5lcmF0ZSB0aGUgU0NNSSBub2RlIGZvciBEb20wLCB3
ZSBuZWVkIHRvOg0KPj4NCj4+IENvcHkgdGhlc2UgcHJvdG9jb2xzIGZyb20gYSBjZW50cmFsaXpl
ZCBvciBwcmVkZWZpbmVkIHNvdXJjZS4NCj4+IFNldCB0aGUgY29ycmVjdCBwaGFuZGxlIGZvciBl
YWNoIHN1Ym5vZGUgd2l0aGluIHRoZSBTQ01JIG5vZGUsIGVuc3VyaW5nDQo+Pg0KPj4gYWNjdXJh
dGUgcmVwcmVzZW50YXRpb24gYW5kIGZ1bmN0aW9uYWxpdHkuDQo+PiBUaGlzIGV4dHJhIHN0ZXAg
b2YgbWFuYWdpbmcgdGhlIHByb3RvY29scyBhbmQgcGhhbmRsZXMgYWRkcw0KPj4NCj4+IGNvbXBs
ZXhpdHkgYnV0IGlzIG5lY2Vzc2FyeSBmb3IgZW5zdXJpbmcgcHJvcGVyIHN1cHBvcnQgZm9yIERv
bTAuDQo+Pg0KPj4gWzBdDQo+PiBodHRwczovL2xpc3RzLnhlbnByb2plY3Qub3JnL2FyY2hpdmVz
L2h0bWwveGVuLWRldmVsLzIwMjUtMDUvbXNnMDEwNDEuaHRtbA0KPiBJIHdhcyBvbmx5IGNvbW1l
bnRpbmcgdGhhdCByYXRoZXIgdGhhbiB0cnlpbmcgdG8gbW9kaWZ5IHRoZSBEVCBpbiBwbGFjZQ0K
PiB3ZSBjb3VsZCBjcmVhdGUgdGhlIG5vZGUgZm9yIERvbTAgZnJvbSBzY3JhdGNoIChhcnRpZmlj
aWFsbHkpLCBiYXNlZCBvbg0KPiBob3N0IERUIGluZm9ybWF0aW9uIGFzIHJlcXVpcmVkIChmZXRj
aGluZyBkYXRhIGZyb20gdGhlIGhvc3QgRFQgYXMNCj4gcmVxdWlyZWQgYW5kIGNvcHlpbmcgaXQg
dG8gdGhlIERvbTAgRFQpLg0KPg0KVGhlIHByb2JsZW0gaXMgdGhhdCBzY21pIG5vZGUsIGFwYXJ0
IGZyb20gdGhlIGRlZmF1bHQgcGFyYW1ldGVycyBoYXMgYQ0KbGlzdCBvZg0KDQpzdXBwb3J0ZWQg
cHJvdG9jb2xzIHdoaWNoIG1heSBiZSBkaWZmZXJlbnQgZm9yIFhlbiBhbmQgRG9tMCBzbyB0bw0K
Z2VuZXJhdGUgRG9tMCBub2RlDQoNCmZyb20gc2NyYXRjaCB3ZSBuZWVkIHRvIGNvcHkob3IgZXZl
biBnZW5lcmF0ZSkgdGhlc2Ugbm9kZXMgd2hpY2ggd2lsbA0KcmVxdWlyZSBjb21wbGV4IGltcGxl
bWVudGF0aW9uLg0KDQpJbiBjb250cmFyeSwgaWYgd2UgZ28gd2l0aCBpbXBsZW1lbnRhdGlvbiwg
cHJvcG9zZWQgaW4gdGhlIGxhc3QgcGF0Y2ggLQ0KdGhlbiB3ZSBjYW4gaGF2ZQ0KDQptb3JlIGNs
ZWFuZXIgWGVuIGRldmljZSB0cmVlLCB3aGljaCB3aWxsIGxvb2sgbGlrZSB0aGlzOg0KDQpgYGAN
Cg0KY2hvc2VuIHsNCg0KICAgICBzY21pX3hlbjogc2NtaSB7DQoNCiAgICAgICAgICAgYXJtLHNt
Yy1pZCA9IDwweDgyMDAwMDAyPjsNCg0KICAgICAgICAgICBzaG1lbT0gPCRzaG1fMD47DQoNCiAg
ICAgICAgICAuLi4gIyBubyBwcm90b2NvbHMgZGVzY3JpcHRpb24gaGVyZQ0KDQp9Ow0KDQpmaXJt
d2FyZSB7DQoNCiAgICBzY21pIHsNCg0KICAgICAgICAgICBhcm0sc21jLWlkID0gPDB4ODIwMDAw
MDM+Ow0KDQogICAgICAgICAgIHNobWVtPSA8JHNobV8xPjsNCg0KICAgICAgICAgICBwcm90b2Nv
bEBYew0KDQogICAgICAgICAgIH07DQoNCiAgICB9DQoNCn07DQoNCmBgYA0KDQpJbiB0aGlzIGNh
c2UsIHdlIGRvbuKAmXQgcHJvdmlkZSBhbnkgcHJvdG9jb2wgaW5mb3JtYXRpb24gZm9yIHRoZSBY
ZW4NCmFnZW50IGFuZCBpbnN0ZWFkIHNldCBwcm90b2NvbHMgZm9yIERvbTAuDQoNClRoaXMgZW5z
dXJlcyB0aGF0IGVhY2ggbm9kZSBoYXMgdGhlIGluZm9ybWF0aW9uIGl0IHJlcXVpcmVzLg0KDQo+
Pj4+ICsgICAgLyoNCj4+Pj4gKyAgICAgKiBBbGwgU0NNSSBzaG1lbSBub2RlcyBzaG91bGQgYmUg
cmVtb3ZlZCBmcm9tIERvbTAgRFQgYXQgdGhpcyBwb2ludCwgc28NCj4+Pj4gKyAgICAgKiB0aGUg
c2htZW0gbm9kZSBmb3IgRG9tMCBuZWVkIHRvIGJlIGdlbmVyYXRlZCBmcm9tIFNDTUkgY2hhbm5l
bCBhc3NpZ25lZA0KPj4+PiArICAgICAqIHRvIERvbTAuDQo+Pj4+ICsgICAgICogVGhlIG9yaWdp
bmFsIFNDTUkgc2htZW0gbm9kZSBmcm9tIHBsYXRmb3JtIERUIGlzIHVzZWQgYnkgWGVuIFNDTUkg
ZHJpdmVyDQo+Pj4+ICsgICAgICogaXRzZWxmIGFzIHByaXZpbGVnZWQgY2hhbm5lbCAoYWdlbnRf
aWQ9MCkgdG8gbWFuYWdlIG90aGVyIFNDTUkNCj4+Pj4gKyAgICAgKiBhZ2VudHMgKGRvbWFpbnMp
Lg0KPj4+PiArICAgICAqLw0KPj4+PiArICAgIHNucHJpbnRmKGJ1Ziwgc2l6ZW9mKGJ1ZiksICJz
Y21pLXNobWVtQCVseCIsIGNoYW5uZWwtPnBhZGRyKTsNCj4+Pj4gKw0KPj4+PiArICAgIHJlcyA9
IGZkdF9iZWdpbl9ub2RlKGZkdCwgYnVmKTsNCj4+Pj4gKyAgICBpZiAoIHJlcyApDQo+Pj4+ICsg
ICAgICAgIHJldHVybiByZXM7DQo+Pj4+ICsNCj4+Pj4gKyAgICByZXMgPSBmZHRfcHJvcGVydHlf
c3RyaW5nKGZkdCwgImNvbXBhdGlibGUiLCAiYXJtLHNjbWktc2htZW0iKTsNCj4+Pj4gKyAgICBp
ZiAoIHJlcyApDQo+Pj4+ICsgICAgICAgIHJldHVybiByZXM7DQo+Pj4+ICsNCj4+Pj4gKyAgICBj
ZWxscyA9ICZyZWdbMF07DQo+Pj4+ICsNCj4+Pj4gKyAgICBkdF9jaGlsZF9zZXRfcmFuZ2UoJmNl
bGxzLCBHVUVTVF9ST09UX0FERFJFU1NfQ0VMTFMsIEdVRVNUX1JPT1RfU0laRV9DRUxMUywNCj4+
Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgY2hhbm5lbC0+cGFkZHIsIFNDTUlfU0hNRU1fTUFQ
UEVEX1NJWkUpOw0KPj4+PiArDQo+Pj4+ICsgICAgcmVzID0gZmR0X3Byb3BlcnR5KGZkdCwgInJl
ZyIsIHJlZywgc2l6ZW9mKHJlZykpOw0KPj4+PiArICAgIGlmICggcmVzICkNCj4+Pj4gKyAgICAg
ICAgcmV0dXJuIHJlczsNCj4+Pj4gKw0KPj4+PiArICAgIHJlcyA9IGZkdF9wcm9wZXJ0eV9jZWxs
KGZkdCwgInBoYW5kbGUiLCBzY21pX2RhdGEuc2htZW1fcGhhbmRsZSk7DQo+Pj4+ICsgICAgaWYg
KCByZXMgKQ0KPj4+PiArICAgICAgICByZXR1cm4gcmVzOw0KPj4+PiArDQo+Pj4+ICsgICAgcmVz
ID0gZmR0X2VuZF9ub2RlKGZkdCk7DQo+Pj4+ICsgICAgaWYgKCByZXMgKQ0KPj4+PiArICAgICAg
ICByZXR1cm4gcmVzOw0KPj4+PiArDQo+Pj4+ICsgICAgLyoNCj4+Pj4gKyAgICAgKiBNYXAgU0NN
SSBzaG1lbSBpbnRvIERvbTAgaGVyZSBhcyBzaG1lbSBub2RlcyBhcmUgZXhjbHVkZWQgZnJvbQ0K
Pj4+PiArICAgICAqIGdlbmVyaWMgRG9tMCBEVCBwcm9jZXNzaW5nDQo+Pj4+ICsgICAgICovDQo+
Pj4+ICsgICAgcmVzID0gaW9tZW1fcGVybWl0X2FjY2VzcyhkLCBwYWRkcl90b19wZm4oY2hhbm5l
bC0+cGFkZHIpLA0KPj4+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGFkZHJfdG9f
cGZuKGNoYW5uZWwtPnBhZGRyICsNCj4+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBTQ01JX1NITUVNX01BUFBFRF9TSVpFIC0gMSkpOw0KPj4+PiArICAgIGlm
ICggcmVzICkNCj4+Pj4gKyAgICAgICAgcmV0dXJuIHJlczsNCj4+Pj4gKw0KPj4+PiArICAgIHJl
cyA9IG1hcF9yZWdpb25zX3AybXQoZCwgZ2FkZHJfdG9fZ2ZuKGNoYW5uZWwtPnBhZGRyKSwNCj4+
Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgIFBGTl9VUChTQ01JX1NITUVNX01BUFBFRF9T
SVpFKSwNCj4+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgIG1hZGRyX3RvX21mbihjaGFu
bmVsLT5wYWRkciksIHAybV9tbWlvX2RpcmVjdF9uYyk7DQo+Pj4+ICsgICAgaWYgKCByZXMgKQ0K
Pj4+PiArICAgIHsNCj4+Pj4gKyAgICAgICAgcmMgPSBpb21lbV9kZW55X2FjY2VzcyhkLCBwYWRk
cl90b19wZm4oY2hhbm5lbC0+cGFkZHIpLA0KPj4+PiArICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHBhZGRyX3RvX3BmbihjaGFubmVsLT5wYWRkciArDQo+Pj4+ICsgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNDTUlfU0hNRU1fTUFQUEVEX1NJWkUgLSAx
KSk7DQo+Pj4+ICsgICAgICAgIGlmICggcmMgKQ0KPj4+PiArICAgICAgICAgICAgcHJpbnRrKFhF
TkxPR19FUlIgInNjbWk6IFVuYWJsZSB0byBkZW55IGlvbWVtIGFjY2VzcyAsIGVyciA9ICVkXG4i
LA0KPj4+PiArICAgICAgICAgICAgICAgICAgIHJjKTsNCj4+Pj4gKyAgICB9DQo+Pj4+ICsNCj4+
Pj4gKyAgICByZXR1cm4gcmVzOw0KPj4+PiArfQ0KPj4+PiArDQo+Pj4+ICtzdGF0aWMgaW50IHNj
bWlfYXNzaWduX2RldmljZSh1aW50MzJfdCBhZ2VudF9pZCwgdWludDMyX3QgZGV2aWNlX2lkLA0K
Pj4+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZmxhZ3MpDQo+Pj4+
ICt7DQo+Pj4+ICsgICAgc3RydWN0IHNjbWlfbXNnX2Jhc2Vfc2V0X2RldmljZV9wZXJtaXNzaW9u
c19hMnAgdHg7DQo+Pj4+ICsgICAgc3RydWN0IHNjbWlfY2hhbm5lbCAqY2hhbm5lbDsNCj4+Pj4g
KyAgICBzY21pX21zZ19oZWFkZXJfdCBoZHI7DQo+Pj4+ICsgICAgaW50IHJldDsNCj4+Pj4gKw0K
Pj4+PiArICAgIGNoYW5uZWwgPSBnZXRfY2hhbm5lbF9ieV9pZChIWVBfQ0hBTk5FTCk7DQo+Pj4+
ICsgICAgaWYgKCAhY2hhbm5lbCApDQo+Pj4+ICsgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4+
PiArDQo+Pj4+ICsgICAgaGRyLmlkID0gU0NNSV9CQVNFX1NFVF9ERVZJQ0VfUEVSTUlTU0lPTlM7
DQo+Pj4+ICsgICAgaGRyLnR5cGUgPSAwOw0KPj4+PiArICAgIGhkci5wcm90b2NvbCA9IFNDTUlf
QkFTRV9QUk9UT0NPTDsNCj4+Pj4gKw0KPj4+PiArICAgIHR4LmFnZW50X2lkID0gYWdlbnRfaWQ7
DQo+Pj4+ICsgICAgdHguZGV2aWNlX2lkID0gZGV2aWNlX2lkOw0KPj4+PiArICAgIHR4LmZsYWdz
ID0gZmxhZ3M7DQo+Pj4+ICsNCj4+Pj4gKyAgICByZXQgPSBkb19zbWNfeGZlcihjaGFubmVsLCAm
aGRyLCAmdHgsIHNpemVvZih0eCksIE5VTEwsIDApOw0KPj4+PiArICAgIGlmICggcmV0ID09IC1F
T1BOT1RTVVBQICkNCj4+Pj4gKyAgICAgICAgcmV0dXJuIDA7DQo+Pj4gSXMgaXQgYWN0dWFsbHkg
T0sgdG8gcHJldGVuZCB0aGF0IGV2ZXJ5dGhpbmcgd29ya2VkIGlmIHRoZSByZXR1cm4gaXMNCj4+
PiAtRU9QTk9UU1VQUD8gSSBtZWFuIHRoYXQgaW4gdGhpcyBjYXNlIGNhbiB3ZSBhc3N1bWUgdGhh
dCB0aGUgZGV2aWNlIGlzDQo+Pj4gYWN0dWFsbHkgYXNzaWduZWQgYW55d2F5PyBXb3VsZG4ndCBm
b2xsb3cgdXAgU0NNSSBvcGVyYXRpb25zIG9uIHRoaXMNCj4+PiBkZXZpY2UgZmFpbD8NCj4+Pg0K
Pj4gSSB0aGluayB5b3UgcmlnaHQuIFdpbGwgZml4IGluIHY1DQo+Pj4+ICsgICAgcmV0dXJuIHJl
dDsNCj4+Pj4gK30NCj4+Pj4gKw0KPj4+PiArc3RhdGljIGludCBzY21pX2R0X2Fzc2lnbl9kZXZp
Y2Uoc3RydWN0IGRvbWFpbiAqZCwNCj4+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHN0cnVjdCBkdF9waGFuZGxlX2FyZ3MgKmFjX3NwZWMpDQo+Pj4+ICt7DQo+Pj4+ICsgICAg
c3RydWN0IHNjbWlfY2hhbm5lbCAqYWdlbnRfY2hhbm5lbDsNCj4+Pj4gKyAgICB1aW50MzJfdCBz
Y21pX2RldmljZV9pZCA9IGFjX3NwZWMtPmFyZ3NbMF07DQo+Pj4+ICsgICAgaW50IHJldDsNCj4+
Pj4gKw0KPj4+PiArICAgIGlmICggIWQtPmFyY2guc2NpX2RhdGEgKQ0KPj4+PiArICAgICAgICBy
ZXR1cm4gMDsNCj4+Pj4gKw0KPj4+PiArICAgIC8qIFRoZSBhY2Nlc3MtY29udHJvbGxlcnMgaXMg
c3BlY2lmaWVkIGZvciBEVCBkZXYsIGJ1dCBpdCdzIG5vdCBhIFNDTUkgKi8NCj4+Pj4gKyAgICBp
ZiAoIGFjX3NwZWMtPm5wICE9IHNjbWlfZGF0YS5kdF9kZXYgKQ0KPj4+PiArICAgICAgICByZXR1
cm4gMDsNCj4+PiBJIHdvbmRlciBpZiB0aGlzIHNob3VsZCBiZSBhbiBlcnJvcg0KPj4+DQo+PiBX
ZSBkb27igJl0IGV4cGVjdCB0aGUgRFQgbm9kZSBhY2Nlc3MtY29udHJvbGxlciB0byByZWx5IHNv
bGVseSBvbiBTQ01JLg0KPj4gVGhlcmVmb3JlLA0KPj4NCj4+IGlmIGEgRFQgbm9kZSBoYXMgYW4g
YWNjZXNzLWNvbnRyb2xsZXIgYnV0IGl04oCZcyBub3QgYXNzb2NpYXRlZCB3aXRoIFNDTUksDQo+
PiB3ZSBzaG91bGQgc2ltcGx5DQo+Pg0KPj4gaWdub3JlIHRoYXQgbm9kZSB3aXRob3V0IHJhaXNp
bmcgYW4gZXJyb3IuDQo+Pg0KPj4NCj4+IFRoYXTigJlzIG15IHVuZGVyc3RhbmRpbmcgb2YgdGhl
IHNpdHVhdGlvbi4NCj4gSSB1bmRlcnN0YW5kIHRoYXQsIGJ1dCBzaG91bGQgc2NtaV9kdF9hc3Np
Z25fZGV2aWNlIGJlIGNhbGxlZCBpbiBzdWNoIGFzDQo+IGEgY2FzZT8gSSBkaWRuJ3QgZ28gYmFj
ayBhbmQgbG9vayBhdCB0aGUgb3JpZ2luYWwgY29kZSBpbiB3cml0aW5nIHRoaXMNCj4gY29tbWVu
dC4NCg0KVGhpcyBmdW5jdGlvbiBpcyBwYXJ0IG9mIHRoZSBTQ0kgaW50ZXJmYWNlLiBJ4oCZdmUg
YWRkZWQgdGhpcyBjaGVjayBoZXJlDQp0byBhdm9pZCBjcmVhdGluZyBhbiBhZGRpdGlvbmFsIGZ1
bmN0aW9uDQoNCnNvbGVseSB0byB2ZXJpZnkgaWYgdGhlIGFjY2VzcyBjb250cm9sbGVyIG5vZGUg
aXMgYW4gU0NNSS1yZWxhdGVkIG5vZGUuDQoNCg0KQWRkaXRpb25hbGx5LCBvdGhlciBwb3RlbnRp
YWwgaW1wbGVtZW50YXRpb25zIG1pZ2h0IHVzZSB0aGVpciBvd24NCmJpbmRpbmdzLCB3aGljaCBj
b3VsZCBkaWZmZXIgZnJvbSB0aGUgb25lcw0KDQpjdXJyZW50bHkgdXNlZCBieSBTQ01JLg0KDQoN
Ck15IGFwcHJvYWNoIGlzIHRvIGhhdmUgYSBzaW5nbGUgZnVuY3Rpb24gdGhhdCBpbmNsdWRlcyBh
bGwgbmVjZXNzYXJ5DQpjaGVja3MgYmVmb3JlIHBlcmZvcm1pbmcgYW55IHJlYWwgd29yay4NCj4N
Cj4+Pj4gKyAgICBhZ2VudF9jaGFubmVsID0gZC0+YXJjaC5zY2lfZGF0YTsNCj4+Pj4gKw0KPj4+
PiArICAgIHNwaW5fbG9jaygmYWdlbnRfY2hhbm5lbC0+bG9jayk7DQo+Pj4+ICsNCj4+Pj4gKyAg
ICByZXQgPSBzY21pX2Fzc2lnbl9kZXZpY2UoYWdlbnRfY2hhbm5lbC0+YWdlbnRfaWQsIHNjbWlf
ZGV2aWNlX2lkLA0KPj4+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTQ01JX0JBU0Vf
REVWSUNFX0FDQ0VTU19BTExPVyk7DQo+Pj4+ICsgICAgaWYgKCByZXQgKQ0KPj4+PiArICAgIHsN
Cj4+Pj4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19FUlINCj4+Pj4gKyAgICAgICAgICAgICAgICJz
Y21pOiBjb3VsZCBub3QgYXNzaWduIGRldiBmb3IgJXBkIGFnZW50OiVkIGRldl9pZDoldSAoJWQp
IiwNCj4+Pj4gKyAgICAgICAgICAgICAgIGQsIGFnZW50X2NoYW5uZWwtPmFnZW50X2lkLCBzY21p
X2RldmljZV9pZCwgcmV0KTsNCj4+Pj4gKyAgICB9DQo+Pj4+ICsNCj4+Pj4gKyAgICBzcGluX3Vu
bG9jaygmYWdlbnRfY2hhbm5lbC0+bG9jayk7DQo+Pj4+ICsgICAgcmV0dXJuIHJldDsNCj4+Pj4g
K30NCj4+Pj4gKw0KPj4+PiArc3RhdGljIF9faW5pdCBpbnQgY29sbGVjdF9hZ2VudHMoc3RydWN0
IGR0X2RldmljZV9ub2RlICpzY21pX25vZGUpDQo+Pj4+ICt7DQo+Pj4+ICsgICAgY29uc3Qgc3Ry
dWN0IGR0X2RldmljZV9ub2RlICpjaG9zZW5fbm9kZTsNCj4+Pj4gKyAgICBjb25zdCBfX2JlMzIg
KnByb3A7DQo+Pj4+ICsgICAgdWludDMyX3QgbGVuLCBpOw0KPj4+PiArDQo+Pj4+ICsgICAgY2hv
c2VuX25vZGUgPSBkdF9maW5kX25vZGVfYnlfcGF0aCgiL2Nob3NlbiIpOw0KPj4+PiArICAgIGlm
ICggIWNob3Nlbl9ub2RlICkNCj4+Pj4gKyAgICB7DQo+Pj4+ICsgICAgICAgIHByaW50ayhYRU5M
T0dfRVJSICJzY21pOiBjaG9zZW4gbm9kZSBub3QgZm91bmRcbiIpOw0KPj4+PiArICAgICAgICBy
ZXR1cm4gLUVOT0VOVDsNCj4+Pj4gKyAgICB9DQo+Pj4+ICsNCj4+Pj4gKyAgICBwcm9wID0gZHRf
Z2V0X3Byb3BlcnR5KGNob3Nlbl9ub2RlLCBTQ01JX1NFQ09OREFSWV9BR0VOVFMsICZsZW4pOw0K
Pj4+PiArICAgIGlmICggIXByb3AgKQ0KPj4+PiArICAgIHsNCj4+Pj4gKyAgICAgICAgcHJpbnRr
KFhFTkxPR19XQVJOSU5HICJzY21pOiBObyAlcyBwcm9wZXJ0eSBmb3VuZFxuIiwNCj4+Pj4gKyAg
ICAgICAgICAgICAgIFNDTUlfU0VDT05EQVJZX0FHRU5UUyk7DQo+Pj4+ICsgICAgICAgIHJldHVy
biAtRU5PREVWOw0KPj4+PiArICAgIH0NCj4+Pj4gKw0KPj4+PiArICAgIGlmICggbGVuICUgKDMg
KiBzaXplb2YodWludDMyX3QpKSApDQo+Pj4+ICsgICAgew0KPj4+PiArICAgICAgICBwcmludGso
WEVOTE9HX0VSUiAic2NtaTogSW52YWxpZCBsZW5ndGggb2YgJXMgcHJvcGVydHk6ICVkXG4iLA0K
Pj4+PiArICAgICAgICAgICAgICAgU0NNSV9TRUNPTkRBUllfQUdFTlRTLCBsZW4pOw0KPj4+PiAr
ICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+Pj4gKyAgICB9DQo+Pj4+ICsNCj4+Pj4gKyAgICBm
b3IgKCBpID0gMDsgaSA8IGxlbiAvICgzICogc2l6ZW9mKHVpbnQzMl90KSk7IGkrKyApDQo+Pj4+
ICsgICAgew0KPj4+PiArICAgICAgICB1aW50MzJfdCBhZ2VudF9pZCA9IGJlMzJfdG9fY3B1KCpw
cm9wKyspOw0KPj4+PiArICAgICAgICB1aW50MzJfdCBzbWNfaWQgPSBiZTMyX3RvX2NwdSgqcHJv
cCsrKTsNCj4+Pj4gKyAgICAgICAgdWludDMyX3Qgc2htZW1fcGhhbmRsZSA9IGJlMzJfdG9fY3B1
KCpwcm9wKyspOw0KPj4+PiArICAgICAgICBzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKm5vZGUgPSBk
dF9maW5kX25vZGVfYnlfcGhhbmRsZShzaG1lbV9waGFuZGxlKTsNCj4+Pj4gKyAgICAgICAgdTY0
IGFkZHIsIHNpemU7DQo+Pj4+ICsgICAgICAgIGludCByZXQ7DQo+Pj4+ICsNCj4+Pj4gKyAgICAg
ICAgaWYgKCAhbm9kZSApDQo+Pj4+ICsgICAgICAgIHsNCj4+Pj4gKyAgICAgICAgICAgIHByaW50
ayhYRU5MT0dfRVJSICJzY21pOiBDb3VsZCBub3QgZmluZCBzaG1lbSBub2RlIGZvciBhZ2VudCAl
ZFxuIiwNCj4+Pj4gKyAgICAgICAgICAgICAgICAgICBhZ2VudF9pZCk7DQo+Pj4+ICsgICAgICAg
ICAgICByZXR1cm4gLUVJTlZBTDsNCj4+Pj4gKyAgICAgICAgfQ0KPj4+PiArDQo+Pj4+ICsgICAg
ICAgIHJldCA9IGR0X2RldmljZV9nZXRfYWRkcmVzcyhub2RlLCAwLCAmYWRkciwgJnNpemUpOw0K
Pj4+PiArICAgICAgICBpZiAoIHJldCApDQo+Pj4+ICsgICAgICAgIHsNCj4+Pj4gKyAgICAgICAg
ICAgIHByaW50ayhYRU5MT0dfRVJSDQo+Pj4+ICsgICAgICAgICAgICAgICAgICAgInNjbWk6IENv
dWxkIG5vdCByZWFkIHNobWVtIGFkZHJlc3MgZm9yIGFnZW50ICVkOiAlZCIsDQo+Pj4+ICsgICAg
ICAgICAgICAgICAgICAgYWdlbnRfaWQsIHJldCk7DQo+Pj4+ICsgICAgICAgICAgICByZXR1cm4g
cmV0Ow0KPj4+PiArICAgICAgICB9DQo+Pj4+ICsNCj4+Pj4gKyAgICAgICAgaWYgKCAhSVNfQUxJ
R05FRChzaXplLCBTQ01JX1NITUVNX01BUFBFRF9TSVpFKSApDQo+Pj4+ICsgICAgICAgIHsNCj4+
Pj4gKyAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJzY21pOiBzaG1lbSBtZW1vcnkgaXMg
bm90IGFsaWduZWRcbiIpOw0KPj4+PiArICAgICAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+Pj4+
ICsgICAgICAgIH0NCj4+Pj4gKw0KPj4+PiArICAgICAgICByZXQgPSBQVFJfUkVUKHNtY19jcmVh
dGVfY2hhbm5lbChhZ2VudF9pZCwgc21jX2lkLCBhZGRyKSk7DQo+Pj4+ICsgICAgICAgIGlmICgg
cmV0ICkNCj4+Pj4gKyAgICAgICAgew0KPj4+PiArICAgICAgICAgICAgcHJpbnRrKFhFTkxPR19F
UlIgInNjbWk6IENvdWxkIG5vdCBjcmVhdGUgY2hhbm5lbCBmb3IgYWdlbnQgJWQ6ICVkIiwNCj4+
Pj4gKyAgICAgICAgICAgICAgICAgICBhZ2VudF9pZCwgcmV0KTsNCj4+Pj4gKyAgICAgICAgICAg
IHJldHVybiByZXQ7DQo+Pj4+ICsgICAgICAgIH0NCj4+Pj4gKw0KPj4+PiArICAgICAgICBwcmlu
dGsoWEVOTE9HX0RFQlVHICJzY21pOiBBZ2VudCAlZCBTTUMgJVggYWRkciAlbHhcbiIsIGFnZW50
X2lkLA0KPj4+PiArICAgICAgICAgICAgICAgc21jX2lkLCBhZGRyKTsNCj4+Pj4gKyAgICB9DQo+
Pj4+ICsNCj4+Pj4gKyAgICByZXR1cm4gMDsNCj4+Pj4gK30NCj4+Pj4gKw0KPj4+PiArc3RhdGlj
IGludCBzY21pX2RvbWFpbl9pbml0KHN0cnVjdCBkb21haW4gKmQsDQo+Pj4+ICsgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfY3JlYXRlZG9tYWluICpjb25maWcp
DQo+Pj4+ICt7DQo+Pj4+ICsgICAgc3RydWN0IHNjbWlfY2hhbm5lbCAqY2hhbm5lbDsNCj4+Pj4g
KyAgICBpbnQgcmV0Ow0KPj4+PiArDQo+Pj4+ICsgICAgaWYgKCAhc2NtaV9kYXRhLmluaXRpYWxp
emVkICkNCj4+Pj4gKyAgICAgICAgcmV0dXJuIDA7DQo+Pj4+ICsNCj4+Pj4gKyAgICAvKg0KPj4+
PiArICAgICAqIFNwZWNpYWwgY2FzZSBmb3IgRG9tMCAtIHRoZSBTQ01JIHN1cHBvcnQgaXMgZW5h
YmxlZCBiYXNpbmcgb24NCj4+Pj4gKyAgICAgKiAiZG9tMF9zY2lfYWdlbnRfaWQiIFhlbiBjb21t
YW5kIGxpbmUgcGFyYW1ldGVyDQo+Pj4+ICsgICAgICovDQo+Pj4+ICsgICAgaWYgKCBpc19oYXJk
d2FyZV9kb21haW4oZCkgKQ0KPj4+PiArICAgIHsNCj4+Pj4gKyAgICAgICAgaWYgKCBvcHRfZG9t
MF9zY21pX2FnZW50X2lkICE9IFNDTUlfQUdFTlRfSURfSU5WQUxJRCApDQo+Pj4+ICsgICAgICAg
IHsNCj4+Pj4gKyAgICAgICAgICAgIGNvbmZpZy0+YXJjaC5hcm1fc2NpX3R5cGUgPSBYRU5fRE9N
Q1RMX0NPTkZJR19BUk1fU0NJX1NDTUlfU01DX01BOw0KPj4+PiArICAgICAgICAgICAgY29uZmln
LT5hcmNoLmFybV9zY2lfYWdlbnRfaWQgPSBvcHRfZG9tMF9zY21pX2FnZW50X2lkOw0KPj4+PiAr
ICAgICAgICB9DQo+Pj4+ICsgICAgICAgIGVsc2UNCj4+Pj4gKyAgICAgICAgICAgIGNvbmZpZy0+
YXJjaC5hcm1fc2NpX3R5cGUgPSBYRU5fRE9NQ1RMX0NPTkZJR19BUk1fU0NJX05PTkU7DQo+Pj4+
ICsgICAgfQ0KPj4+PiArDQo+Pj4+ICsgICAgaWYgKCBjb25maWctPmFyY2guYXJtX3NjaV90eXBl
ID09IFhFTl9ET01DVExfQ09ORklHX0FSTV9TQ0lfTk9ORSApDQo+Pj4+ICsgICAgICAgIHJldHVy
biAwOw0KPj4+PiArDQo+Pj4+ICsgICAgY2hhbm5lbCA9IGFjcXVpcmVfc2NtaV9jaGFubmVsKGQs
IGNvbmZpZy0+YXJjaC5hcm1fc2NpX2FnZW50X2lkKTsNCj4+Pj4gKyAgICBpZiAoIElTX0VSUihj
aGFubmVsKSApDQo+Pj4+ICsgICAgew0KPj4+PiArICAgICAgICBwcmludGsoWEVOTE9HX0VSUg0K
Pj4+PiArICAgICAgICAgICAgICAgInNjbWk6IEZhaWxlZCB0byBhY3F1aXJlIFNDTUkgY2hhbm5l
bCBmb3IgYWdlbnRfaWQgJXU6ICVsZFxuIiwNCj4+Pj4gKyAgICAgICAgICAgICAgIGNvbmZpZy0+
YXJjaC5hcm1fc2NpX2FnZW50X2lkLCBQVFJfRVJSKGNoYW5uZWwpKTsNCj4+Pj4gKyAgICAgICAg
cmV0dXJuIFBUUl9FUlIoY2hhbm5lbCk7DQo+Pj4+ICsgICAgfQ0KPj4+PiArDQo+Pj4+ICsgICAg
cHJpbnRrKFhFTkxPR19JTkZPDQo+Pj4+ICsgICAgICAgICAgICJzY21pOiBBY3F1aXJlIGNoYW5u
ZWwgaWQgPSAweCV4LCBkb21haW5faWQgPSAlZCBwYWRkciA9IDB4JWx4XG4iLA0KPj4+PiArICAg
ICAgICAgICBjaGFubmVsLT5hZ2VudF9pZCwgY2hhbm5lbC0+ZG9tYWluX2lkLCBjaGFubmVsLT5w
YWRkcik7DQo+Pj4+ICsNCj4+Pj4gKyAgICAvKg0KPj4+PiArICAgICAqIERvbTAgKGlmIHByZXNl
bnQpIG5lZWRzIHRvIGhhdmUgYW4gYWNjZXNzIHRvIHRoZSBndWVzdCBtZW1vcnkgcmFuZ2UNCj4+
Pj4gKyAgICAgKiB0byBzYXRpc2Z5IGlvbWVtX2FjY2Vzc19wZXJtaXR0ZWQoKSBjaGVjayBpbiBY
RU5fRE9NQ1RMX2lvbWVtX3Blcm1pc3Npb24NCj4+Pj4gKyAgICAgKiBkb21jdGwuDQo+Pj4gSWRl
YWxseSB0aGlzIHNob3VsZCBub3QgYmUgbmVlZGVkIGJ1dCBJIHVuZGVyc3RhbmQgd2UgZG9uJ3Qg
aGF2ZSBhbg0KPj4+IGVhc3kgc29sdXRpb24sIEkgdGhpbmsgd2UgY2FuIGdvIGFoZWFkIHdpdGgg
dGhpcyBmb3Igbm93Lg0KPj4+DQo+Pj4+ICsgICAgICovDQo+Pj4+ICsgICAgaWYgKCBoYXJkd2Fy
ZV9kb21haW4gJiYgIWlzX2hhcmR3YXJlX2RvbWFpbihkKSApDQo+Pj4+ICsgICAgew0KPj4+PiAr
ICAgICAgICByZXQgPSBpb21lbV9wZXJtaXRfYWNjZXNzKGhhcmR3YXJlX2RvbWFpbiwgcGFkZHJf
dG9fcGZuKGNoYW5uZWwtPnBhZGRyKSwNCj4+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBwYWRkcl90b19wZm4oY2hhbm5lbC0+cGFkZHIgKyBQQUdFX1NJWkUgLSAxKSk7DQo+
Pj4+ICsgICAgICAgIGlmICggcmV0ICkNCj4+Pj4gKyAgICAgICAgICAgIGdvdG8gZXJyb3I7DQo+
Pj4+ICsgICAgfQ0KPj4+PiArDQo+Pj4+ICsgICAgZC0+YXJjaC5zY2lfZGF0YSA9IGNoYW5uZWw7
DQo+Pj4+ICsgICAgZC0+YXJjaC5zY2lfZW5hYmxlZCA9IHRydWU7DQo+Pj4+ICsNCj4+Pj4gKyAg
ICByZXR1cm4gMDsNCj4+Pj4gKw0KPj4+PiArZXJyb3I6DQo+Pj4+ICsgICAgcmVsaW5xdWlzaF9z
Y21pX2NoYW5uZWwoY2hhbm5lbCk7DQo+Pj4+ICsgICAgcmV0dXJuIHJldDsNCj4+Pj4gK30NCj4+
Pj4gKw0KPj4+PiAraW50IHNjbWlfZG9tYWluX3Nhbml0aXNlX2NvbmZpZyhzdHJ1Y3QgeGVuX2Rv
bWN0bF9jcmVhdGVkb21haW4gKmNvbmZpZykNCj4+Pj4gK3sNCj4+Pj4gKyAgICBpZiAoIGNvbmZp
Zy0+YXJjaC5hcm1fc2NpX3R5cGUgIT0gWEVOX0RPTUNUTF9DT05GSUdfQVJNX1NDSV9OT05FICYm
DQo+Pj4+ICsgICAgICAgICBjb25maWctPmFyY2guYXJtX3NjaV90eXBlICE9IFhFTl9ET01DVExf
Q09ORklHX0FSTV9TQ0lfU0NNSV9TTUNfTUEgKQ0KPj4+PiArICAgIHsNCj4+Pj4gKyAgICAgICAg
ZHByaW50ayhYRU5MT0dfSU5GTywgInNjbWk6IFVuc3VwcG9ydGVkIEFSTV9TQ0kgdHlwZVxuIik7
DQo+Pj4+ICsgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4+PiArICAgIH0NCj4+Pj4gKyAgICBl
bHNlIGlmICggY29uZmlnLT5hcmNoLmFybV9zY2lfdHlwZSA9PQ0KPj4+PiArICAgICAgICAgICAg
ICBYRU5fRE9NQ1RMX0NPTkZJR19BUk1fU0NJX1NDTUlfU01DX01BICYmDQo+Pj4+ICsgICAgICAg
ICAgICAgIGNvbmZpZy0+YXJjaC5hcm1fc2NpX2FnZW50X2lkID09IDAgKQ0KPj4+PiArICAgIHsN
Cj4+Pj4gKyAgICAgICAgZHByaW50ayhYRU5MT0dfSU5GTywNCj4+Pj4gKyAgICAgICAgICAgICAg
ICAic2NtaTogQSB6ZXJvIEFSTSBTQ01JIGFnZW50X2lkIGlzIG5vdCBzdXBwb3J0ZWRcbiIpOw0K
Pj4+PiArICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+Pj4gKyAgICB9DQo+Pj4+ICsNCj4+Pj4g
KyAgICByZXR1cm4gMDsNCj4+Pj4gK30NCj4+Pj4gKw0KPj4+PiArc3RhdGljIGludCBzY21pX3Jl
bGlucXVpc2hfcmVzb3VyY2VzKHN0cnVjdCBkb21haW4gKmQpDQo+Pj4+ICt7DQo+Pj4+ICsgICAg
aW50IHJldDsNCj4+Pj4gKyAgICBzdHJ1Y3Qgc2NtaV9jaGFubmVsICpjaGFubmVsLCAqYWdlbnRf
Y2hhbm5lbDsNCj4+Pj4gKyAgICBzY21pX21zZ19oZWFkZXJfdCBoZHI7DQo+Pj4+ICsgICAgc3Ry
dWN0IHNjbWlfbXNnX2Jhc2VfcmVzZXRfYWdlbnRfY2ZnX2EycCB0eDsNCj4+Pj4gKw0KPj4+PiAr
ICAgIGlmICggIWQtPmFyY2guc2NpX2RhdGEgKQ0KPj4+PiArICAgICAgICByZXR1cm4gMDsNCj4+
Pj4gKw0KPj4+PiArICAgIGFnZW50X2NoYW5uZWwgPSBkLT5hcmNoLnNjaV9kYXRhOw0KPj4+PiAr
DQo+Pj4+ICsgICAgc3Bpbl9sb2NrKCZhZ2VudF9jaGFubmVsLT5sb2NrKTsNCj4+Pj4gKyAgICB0
eC5hZ2VudF9pZCA9IGFnZW50X2NoYW5uZWwtPmFnZW50X2lkOw0KPj4+PiArICAgIHNwaW5fdW5s
b2NrKCZhZ2VudF9jaGFubmVsLT5sb2NrKTsNCj4+Pj4gKw0KPj4+PiArICAgIGNoYW5uZWwgPSBn
ZXRfY2hhbm5lbF9ieV9pZChIWVBfQ0hBTk5FTCk7DQo+Pj4+ICsgICAgaWYgKCAhY2hhbm5lbCAp
DQo+Pj4+ICsgICAgew0KPj4+PiArICAgICAgICBwcmludGsoWEVOTE9HX0VSUg0KPj4+PiArICAg
ICAgICAgICAgICAgInNjbWk6IFVuYWJsZSB0byBnZXQgSHlwZXJ2aXNvciBzY21pIGNoYW5uZWwg
Zm9yIGRvbWFpbiAlZFxuIiwNCj4+Pj4gKyAgICAgICAgICAgICAgIGQtPmRvbWFpbl9pZCk7DQo+
Pj4+ICsgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4+PiArICAgIH0NCj4+Pj4gKw0KPj4+PiAr
ICAgIGhkci5pZCA9IFNDTUlfQkFTRV9SRVNFVF9BR0VOVF9DT05GSUdVUkFUSU9OOw0KPj4+PiAr
ICAgIGhkci50eXBlID0gMDsNCj4+Pj4gKyAgICBoZHIucHJvdG9jb2wgPSBTQ01JX0JBU0VfUFJP
VE9DT0w7DQo+Pj4+ICsNCj4+Pj4gKyAgICB0eC5mbGFncyA9IDA7DQo+Pj4+ICsNCj4+Pj4gKyAg
ICByZXQgPSBkb19zbWNfeGZlcihjaGFubmVsLCAmaGRyLCAmdHgsIHNpemVvZih0eCksIE5VTEws
IDApOw0KPj4+PiArICAgIGlmICggcmV0ID09IC1FT1BOT1RTVVBQICkNCj4+Pj4gKyAgICAgICAg
cmV0dXJuIDA7DQo+Pj4+ICsNCj4+Pj4gKyAgICByZXR1cm4gcmV0Ow0KPj4+PiArfQ0KPj4+PiAr
DQo+Pj4+ICtzdGF0aWMgdm9pZCBzY21pX2RvbWFpbl9kZXN0cm95KHN0cnVjdCBkb21haW4gKmQp
DQo+Pj4+ICt7DQo+Pj4+ICsgICAgc3RydWN0IHNjbWlfY2hhbm5lbCAqY2hhbm5lbDsNCj4+Pj4g
Kw0KPj4+PiArICAgIGlmICggIWQtPmFyY2guc2NpX2RhdGEgKQ0KPj4+PiArICAgICAgICByZXR1
cm47DQo+Pj4+ICsNCj4+Pj4gKyAgICBjaGFubmVsID0gZC0+YXJjaC5zY2lfZGF0YTsNCj4+Pj4g
KyAgICBzcGluX2xvY2soJmNoYW5uZWwtPmxvY2spOw0KPj4+PiArDQo+Pj4+ICsgICAgcmVsaW5x
dWlzaF9zY21pX2NoYW5uZWwoY2hhbm5lbCk7DQo+Pj4+ICsgICAgcHJpbnRrKFhFTkxPR19ERUJV
RyAic2NtaTogRnJlZSBkb21haW4gJWRcbiIsIGQtPmRvbWFpbl9pZCk7DQo+Pj4+ICsNCj4+Pj4g
KyAgICBkLT5hcmNoLnNjaV9kYXRhID0gTlVMTDsNCj4+Pj4gKyAgICBkLT5hcmNoLnNjaV9lbmFi
bGVkID0gdHJ1ZTsNCj4+Pj4gKw0KPj4+PiArICAgIHNwaW5fdW5sb2NrKCZjaGFubmVsLT5sb2Nr
KTsNCj4+Pj4gK30NCj4+Pj4gKw0KPj4+PiArc3RhdGljIGJvb2wgc2NtaV9oYW5kbGVfY2FsbChz
dHJ1Y3QgY3B1X3VzZXJfcmVncyAqcmVncykNCj4+Pj4gK3sNCj4+Pj4gKyAgICB1aW50MzJfdCBm
aWQgPSAodWludDMyX3QpZ2V0X3VzZXJfcmVnKHJlZ3MsIDApOw0KPj4+PiArICAgIHN0cnVjdCBz
Y21pX2NoYW5uZWwgKmFnZW50X2NoYW5uZWw7DQo+Pj4+ICsgICAgc3RydWN0IGRvbWFpbiAqZCA9
IGN1cnJlbnQtPmRvbWFpbjsNCj4+Pj4gKyAgICBzdHJ1Y3QgYXJtX3NtY2NjX3JlcyByZXNwOw0K
Pj4+PiArICAgIGJvb2wgcmVzID0gZmFsc2U7DQo+Pj4+ICsNCj4+Pj4gKyAgICBpZiAoICFzY2lf
ZG9tYWluX2lzX2VuYWJsZWQoZCkgKQ0KPj4+PiArICAgICAgICByZXR1cm4gZmFsc2U7DQo+Pj4+
ICsNCj4+Pj4gKyAgICBhZ2VudF9jaGFubmVsID0gZC0+YXJjaC5zY2lfZGF0YTsNCj4+Pj4gKyAg
ICBzcGluX2xvY2soJmFnZW50X2NoYW5uZWwtPmxvY2spOw0KPj4+PiArDQo+Pj4+ICsgICAgaWYg
KCBhZ2VudF9jaGFubmVsLT5mdW5jX2lkICE9IGZpZCApDQo+Pj4+ICsgICAgew0KPj4+PiArICAg
ICAgICByZXMgPSBmYWxzZTsNCj4+Pj4gKyAgICAgICAgZ290byB1bmxvY2s7DQo+Pj4+ICsgICAg
fQ0KPj4+PiArDQo+Pj4+ICsgICAgYXJtX3NtY2NjXzFfMV9zbWMoZmlkLA0KPj4+PiArICAgICAg
ICAgICAgICAgICAgICAgIGdldF91c2VyX3JlZyhyZWdzLCAxKSwNCj4+Pj4gKyAgICAgICAgICAg
ICAgICAgICAgICBnZXRfdXNlcl9yZWcocmVncywgMiksDQo+Pj4+ICsgICAgICAgICAgICAgICAg
ICAgICAgZ2V0X3VzZXJfcmVnKHJlZ3MsIDMpLA0KPj4+PiArICAgICAgICAgICAgICAgICAgICAg
IGdldF91c2VyX3JlZyhyZWdzLCA0KSwNCj4+Pj4gKyAgICAgICAgICAgICAgICAgICAgICBnZXRf
dXNlcl9yZWcocmVncywgNSksDQo+Pj4+ICsgICAgICAgICAgICAgICAgICAgICAgZ2V0X3VzZXJf
cmVnKHJlZ3MsIDYpLA0KPj4+PiArICAgICAgICAgICAgICAgICAgICAgIGdldF91c2VyX3JlZyhy
ZWdzLCA3KSwNCj4+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAmcmVzcCk7DQo+Pj4+ICsNCj4+
Pj4gKyAgICBzZXRfdXNlcl9yZWcocmVncywgMCwgcmVzcC5hMCk7DQo+Pj4+ICsgICAgc2V0X3Vz
ZXJfcmVnKHJlZ3MsIDEsIHJlc3AuYTEpOw0KPj4+PiArICAgIHNldF91c2VyX3JlZyhyZWdzLCAy
LCByZXNwLmEyKTsNCj4+Pj4gKyAgICBzZXRfdXNlcl9yZWcocmVncywgMywgcmVzcC5hMyk7DQo+
Pj4+ICsgICAgcmVzID0gdHJ1ZTsNCj4+Pj4gK3VubG9jazoNCj4+Pj4gKyAgICBzcGluX3VubG9j
aygmYWdlbnRfY2hhbm5lbC0+bG9jayk7DQo+Pj4+ICsNCj4+Pj4gKyAgICByZXR1cm4gcmVzOw0K
Pj4+PiArfQ0KPj4+PiArDQo+Pj4+ICtzdGF0aWMgY29uc3Qgc3RydWN0IHNjaV9tZWRpYXRvcl9v
cHMgc2NtaV9vcHMgPSB7DQo+Pj4+ICsgICAgLmRvbWFpbl9pbml0ID0gc2NtaV9kb21haW5faW5p
dCwNCj4+Pj4gKyAgICAuZG9tYWluX2Rlc3Ryb3kgPSBzY21pX2RvbWFpbl9kZXN0cm95LA0KPj4+
PiArICAgIC5yZWxpbnF1aXNoX3Jlc291cmNlcyA9IHNjbWlfcmVsaW5xdWlzaF9yZXNvdXJjZXMs
DQo+Pj4+ICsgICAgLmhhbmRsZV9jYWxsID0gc2NtaV9oYW5kbGVfY2FsbCwNCj4+Pj4gKyAgICAu
ZG9tMF9kdF9oYW5kbGVfbm9kZSA9IHNjbWlfZHRfaGFuZGxlX25vZGUsDQo+Pj4+ICsgICAgLmRv
bTBfZHRfZmluYWxpemUgPSBzY21pX2R0X2ZpbmFsaXplLA0KPj4+PiArICAgIC5kb21haW5fc2Fu
aXRpc2VfY29uZmlnID0gc2NtaV9kb21haW5fc2FuaXRpc2VfY29uZmlnLA0KPj4+PiArICAgIC5h
c3NpZ25fZHRfZGV2aWNlID0gc2NtaV9kdF9hc3NpZ25fZGV2aWNlLA0KPj4+PiArfTsNCj4+Pj4g
Kw0KPj4+PiArc3RhdGljIGludCBfX2luaXQgc2NtaV9jaGVja19zbWNjY192ZXIodm9pZCkNCj4+
Pj4gK3sNCj4+Pj4gKyAgICBpZiAoIHNtY2NjX3ZlciA8IEFSTV9TTUNDQ19WRVJTSU9OXzFfMSAp
DQo+Pj4+ICsgICAgew0KPj4+PiArICAgICAgICBwcmludGsoWEVOTE9HX1dBUk5JTkcNCj4+Pj4g
KyAgICAgICAgICAgICAgICJzY21pOiBObyBTTUNDQyAxLjEgc3VwcG9ydCwgU0NNSSBjYWxscyBm
b3J3YXJkaW5nIGRpc2FibGVkXG4iKTsNCj4+Pj4gKyAgICAgICAgcmV0dXJuIC1FTk9TWVM7DQo+
Pj4+ICsgICAgfQ0KPj4+PiArDQo+Pj4+ICsgICAgcmV0dXJuIDA7DQo+Pj4+ICt9DQo+Pj4+ICsN
Cj4+Pj4gK3N0YXRpYyBfX2luaXQgaW50IHNjbWlfcHJvYmUoc3RydWN0IGR0X2RldmljZV9ub2Rl
ICpzY21pX25vZGUsIGNvbnN0IHZvaWQgKmRhdGEpDQo+Pj4+ICt7DQo+Pj4+ICsgICAgdTY0IGFk
ZHIsIHNpemU7DQo+Pj4+ICsgICAgaW50IHJldCwgaTsNCj4+Pj4gKyAgICBzdHJ1Y3Qgc2NtaV9j
aGFubmVsICpjaGFubmVsLCAqYWdlbnRfY2hhbm5lbDsNCj4+Pj4gKyAgICBpbnQgbl9hZ2VudHM7
DQo+Pj4+ICsgICAgc2NtaV9tc2dfaGVhZGVyX3QgaGRyOw0KPj4+PiArICAgIHN0cnVjdCBzY21p
X21zZ19iYXNlX2F0dHJpYnV0ZXNfcDJhIHJ4Ow0KPj4+PiArDQo+Pj4+ICsgICAgQVNTRVJUKHNj
bWlfbm9kZSAhPSBOVUxMKTsNCj4+Pj4gKw0KPj4+PiArICAgIElOSVRfTElTVF9IRUFEKCZzY21p
X2RhdGEuY2hhbm5lbF9saXN0KTsNCj4+Pj4gKyAgICBzcGluX2xvY2tfaW5pdCgmc2NtaV9kYXRh
LmNoYW5uZWxfbGlzdF9sb2NrKTsNCj4+Pj4gKw0KPj4+PiArICAgIGlmICggIWFjcGlfZGlzYWJs
ZWQgKQ0KPj4+PiArICAgIHsNCj4+Pj4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19XQVJOSU5HICJz
Y21pOiBpcyBub3Qgc3VwcG9ydGVkIHdoZW4gdXNpbmcgQUNQSVxuIik7DQo+Pj4+ICsgICAgICAg
IHJldHVybiAtRUlOVkFMOw0KPj4+PiArICAgIH0NCj4+Pj4gKw0KPj4+PiArICAgIHJldCA9IHNj
bWlfY2hlY2tfc21jY2NfdmVyKCk7DQo+Pj4+ICsgICAgaWYgKCByZXQgKQ0KPj4+PiArICAgICAg
ICByZXR1cm4gcmV0Ow0KPj4+PiArDQo+Pj4+ICsgICAgaWYgKCAhZHRfcHJvcGVydHlfcmVhZF91
MzIoc2NtaV9ub2RlLCAiYXJtLHNtYy1pZCIsICZzY21pX2RhdGEuZnVuY19pZCkgKQ0KPj4+PiAr
ICAgIHsNCj4+Pj4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19FUlIgInNjbWk6IHVuYWJsZSB0byBy
ZWFkIHNtYy1pZCBmcm9tIERUXG4iKTsNCj4+Pj4gKyAgICAgICAgcmV0dXJuIC1FTk9FTlQ7DQo+
Pj4+ICsgICAgfQ0KPj4+PiArDQo+Pj4+ICsgICAgLyogc2F2ZSBzaG1lbSBwaGFuZGxlIGFuZCBy
ZS11c2UgaXQgZnJvIERvbTAgRFQgc2htZW0gbm9kZSAqLw0KPj4+PiArICAgIGlmICggIWR0X3By
b3BlcnR5X3JlYWRfdTMyKHNjbWlfbm9kZSwgInNobWVtIiwgJnNjbWlfZGF0YS5zaG1lbV9waGFu
ZGxlKSApDQo+Pj4+ICsgICAgew0KPj4+PiArICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAic2Nt
aTogdW5hYmxlIHRvIHJlYWQgc2htZW0gcGhhbmRsZSBmcm9tIERUXG4iKTsNCj4+Pj4gKyAgICAg
ICAgcmV0dXJuIC1FTk9FTlQ7DQo+Pj4+ICsgICAgfQ0KPj4+PiArDQo+Pj4+ICsgICAgcmV0ID0g
c2NtaV9kdF9yZWFkX2h5cF9jaGFubmVsX2FkZHIoc2NtaV9ub2RlLCAmYWRkciwgJnNpemUpOw0K
Pj4+PiArICAgIGlmICggSVNfRVJSX1ZBTFVFKHJldCkgKQ0KPj4+PiArICAgICAgICByZXR1cm4g
LUVOT0VOVDsNCj4+Pj4gKw0KPj4+PiArICAgIGlmICggIUlTX0FMSUdORUQoc2l6ZSwgU0NNSV9T
SE1FTV9NQVBQRURfU0laRSkgKQ0KPj4+PiArICAgIHsNCj4+Pj4gKyAgICAgICAgcHJpbnRrKFhF
TkxPR19FUlIgInNjbWk6IHNobWVtIG1lbW9yeSBpcyBub3QgYWxpZ25lZFxuIik7DQo+Pj4+ICsg
ICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4+PiArICAgIH0NCj4+Pj4gKw0KPj4+PiArICAgIHNj
bWlfZGF0YS5kdF9kZXYgPSBzY21pX25vZGU7DQo+Pj4+ICsNCj4+Pj4gKyAgICBjaGFubmVsID0g
c21jX2NyZWF0ZV9jaGFubmVsKEhZUF9DSEFOTkVMLCBzY21pX2RhdGEuZnVuY19pZCwgYWRkcik7
DQo+Pj4+ICsgICAgaWYgKCBJU19FUlIoY2hhbm5lbCkgKQ0KPj4+PiArICAgICAgICBnb3RvIG91
dDsNCj4+Pj4gKw0KPj4+PiArICAgIHJldCA9IG1hcF9jaGFubmVsX21lbW9yeShjaGFubmVsKTsN
Cj4+Pj4gKyAgICBpZiAoIHJldCApDQo+Pj4+ICsgICAgICAgIGdvdG8gb3V0Ow0KPj4+PiArDQo+
Pj4+ICsgICAgY2hhbm5lbC0+ZG9tYWluX2lkID0gRE9NSURfWEVOOw0KPj4+PiArDQo+Pj4+ICsg
ICAgaGRyLmlkID0gU0NNSV9CQVNFX1BST1RPQ09MX0FUVElCVVRFUzsNCj4+Pj4gKyAgICBoZHIu
dHlwZSA9IDA7DQo+Pj4+ICsgICAgaGRyLnByb3RvY29sID0gU0NNSV9CQVNFX1BST1RPQ09MOw0K
Pj4+PiArDQo+Pj4+ICsgICAgcmV0ID0gZG9fc21jX3hmZXIoY2hhbm5lbCwgJmhkciwgTlVMTCwg
MCwgJnJ4LCBzaXplb2YocngpKTsNCj4+Pj4gKyAgICBpZiAoIHJldCApDQo+Pj4+ICsgICAgICAg
IGdvdG8gZXJyb3I7DQo+Pj4+ICsNCj4+Pj4gKyAgICBuX2FnZW50cyA9IFNDTUlfRklFTERfR0VU
KFNDTUlfQkFTRV9BVFRSX05VTV9BR0VOVCwgcnguYXR0cmlidXRlcyk7DQo+Pj4+ICsgICAgcHJp
bnRrKFhFTkxPR19ERUJVRyAic2NtaTogR290IGFnZW50IGNvdW50ICVkXG4iLCBuX2FnZW50cyk7
DQo+Pj4+ICsNCj4+Pj4gKyAgICByZXQgPSBjb2xsZWN0X2FnZW50cyhzY21pX25vZGUpOw0KPj4+
PiArICAgIGlmICggcmV0ICkNCj4+Pj4gKyAgICAgICAgZ290byBlcnJvcjsNCj4+Pj4gKw0KPj4+
PiArICAgIGkgPSAxOw0KPj4+PiArDQo+Pj4+ICsgICAgbGlzdF9mb3JfZWFjaF9lbnRyeShhZ2Vu
dF9jaGFubmVsLCAmc2NtaV9kYXRhLmNoYW5uZWxfbGlzdCwgbGlzdCkNCj4+Pj4gKyAgICB7DQo+
Pj4+ICsgICAgICAgIHN0cnVjdCBzY21pX21zZ19iYXNlX2Rpc2NvdmVyX2FnZW50X3AyYSBkYV9y
eDsNCj4+Pj4gKyAgICAgICAgc3RydWN0IHNjbWlfbXNnX2Jhc2VfZGlzY292ZXJfYWdlbnRfYTJw
IGRhX3R4Ow0KPj4+PiArDQo+Pj4+ICsgICAgICAgIHJldCA9IG1hcF9jaGFubmVsX21lbW9yeShh
Z2VudF9jaGFubmVsKTsNCj4+Pj4gKyAgICAgICAgaWYgKCByZXQgKQ0KPj4+PiArICAgICAgICAg
ICAgZ290byBlcnJvcjsNCj4+Pj4gKw0KPj4+PiArICAgICAgICBoZHIuaWQgPSBTQ01JX0JBU0Vf
RElTQ09WRVJfQUdFTlQ7DQo+Pj4+ICsgICAgICAgIGhkci50eXBlID0gMDsNCj4+Pj4gKyAgICAg
ICAgaGRyLnByb3RvY29sID0gU0NNSV9CQVNFX1BST1RPQ09MOw0KPj4+PiArDQo+Pj4+ICsgICAg
ICAgIGRhX3R4LmFnZW50X2lkID0gYWdlbnRfY2hhbm5lbC0+YWdlbnRfaWQ7DQo+Pj4+ICsNCj4+
Pj4gKyAgICAgICAgcmV0ID0gZG9fc21jX3hmZXIoYWdlbnRfY2hhbm5lbCwgJmhkciwgJmRhX3R4
LCBzaXplb2YoZGFfdHgpLCAmZGFfcngsDQo+Pj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAg
IHNpemVvZihkYV9yeCkpOw0KPj4+PiArICAgICAgICBpZiAoIGFnZW50X2NoYW5uZWwtPmRvbWFp
bl9pZCAhPSBET01JRF9YRU4gKQ0KPj4+PiArICAgICAgICAgICAgdW5tYXBfY2hhbm5lbF9tZW1v
cnkoYWdlbnRfY2hhbm5lbCk7DQo+Pj4+ICsgICAgICAgIGlmICggcmV0ICkNCj4+Pj4gKyAgICAg
ICAgICAgIGdvdG8gZXJyb3I7DQo+Pj4+ICsNCj4+Pj4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19E
RUJVRyAiaWQ9MHgleCBuYW1lPSVzXG4iLCBkYV9yeC5hZ2VudF9pZCwgZGFfcngubmFtZSk7DQo+
Pj4+ICsNCj4+Pj4gKyAgICAgICAgYWdlbnRfY2hhbm5lbC0+YWdlbnRfaWQgPSBkYV9yeC5hZ2Vu
dF9pZDsNCj4+PiBJdCBpcyBPSyB0byBzZXQgYWdlbnRfY2hhbm5lbC0+YWdlbnRfaWQgdG8gdGhl
IHZhbHVlIHByb3ZpZGVkIGJ5IHRoZQ0KPj4+IFNDTUkgc2VydmVyLCBidXQgaWYgd2UgYXJlIGFs
c28gdGFraW5nIHRoZSBhZ2VudF9jaGFubmVsLT5hZ2VudF9pZCB2YWx1ZQ0KPj4+IGZyb20gdGhl
IHVzZXIgdmlhIGRldmljZSB0cmVlLCBzaG91bGRuJ3Qgd2UgdGhyb3cgYW4gZXJyb3IgaWYgdGhl
cmUgaXMgYQ0KPj4+IG1pc21hdGNoPw0KPj4+DQo+Pj4gT3IgZXZlbiBiZXR0ZXI6IGNhbiB3ZSBh
dm9pZCB0YWtpbmcgdGhlIHZhbHVlIHZpYSBkZXZpY2UgdHJlZSB0byBtYWtlIGl0DQo+Pj4gZWFz
aWVyIHRvIGNvbmZpZ3VyZT8NCj4+Pg0KPj4gSSBwbGFuIHRvIGRyb3AgdGhlIGxhc3QgbGluZSwg
YXMgdGhlcmXigJlzIG5vIG5lZWQgdG8gb3ZlcndyaXRlIGFnZW50X2lkLg0KPj4NCj4+IEhvd2V2
ZXIsIHdlIGNhbm5vdCBhdm9pZCBvYnRhaW5pbmcgYWdlbnRfaWQgZnJvbSB0aGUgZGV2aWNlIHRy
ZWUgYmVjYXVzZSwNCj4+DQo+PiBhY2NvcmRpbmcgdG8gc2VjdGlvbiA0LjIuMi45IFswXSwgYW4g
YWdlbnQgY2FuIG9ubHkgYmUgZGlzY292ZXJlZCBieSBpdHMNCj4+IGFnZW50X2lkIGluDQo+Pg0K
Pj4gYSBwcml2aWxlZ2VkIGRvbWFpbi4gQWx0ZXJuYXRpdmVseSwgZWFjaCBhZ2VudCBjYW4gb2J0
YWluIGl0cyBvd24gSUQgYnkNCj4+IHByb3ZpZGluZw0KPj4NCj4+IDB4RkZGRkZGRkYgYXMgYWdl
bnRfaWQgYW5kIHVzaW5nIGl0cyBvd24gY2hhbm5lbC4NCj4gVGhhdCB3b3VsZCBiZSBncmVhdCEg
QW55dGhpbmcgdG8gcmVkdWNlIHRoZSBudW1iZXIgb2YgcmVxdWlyZWQgKG5vdA0KPiBvcHRpb25h
bCkgY29uZmlndXJhdGlvbiBvcHRpb25zLg0KDQpQbGVhc2Ugc2VlIG15IGNvbW1lbnQgYWJvdmUu
IEkndmUgbWFya2VkIGl0IHdpdGggW09NIEFOU1dFUl0gc28geW91IGNhbg0KZWFzaWx5IGZpbmQg
aXQuDQoNCg==


From xen-devel-bounces@lists.xenproject.org Thu Jun 19 16:15:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 16:15:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020226.1396591 (Exim 4.92)
	(envelope-from )
	id 1uSHv0-00062a-Rl; Thu, 19 Jun 2025 16:15:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020226.1396591; Thu, 19 Jun 2025 16:15:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSHv0-00062T-Ox; Thu, 19 Jun 2025 16:15:14 +0000
Received: by outflank-mailman (input) for mailman id 1020226;
 Thu, 19 Jun 2025 16:15: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 1uSHuz-0005oY-TK
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 16:15:14 +0000
Received: from AS8PR04CU009.outbound.protection.outlook.com
 (mail-westeuropeazlp170110003.outbound.protection.outlook.com
 [2a01:111:f403:c201::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 94539424-4d28-11f0-a30d-13f23c93f187;
 Thu, 19 Jun 2025 18:15:13 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by DB8PR03MB6332.eurprd03.prod.outlook.com (2603:10a6:10:13d::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.19; Thu, 19 Jun
 2025 16:15:11 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%4]) with mapi id 15.20.8835.023; Thu, 19 Jun 2025
 16:15: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: 94539424-4d28-11f0-a30d-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=xSJQp3epuVIw24B9ZSlpuO3Wp5ElxVYJjQJQonL/THD/R2Zjx9mtxff7FDMFl2ERltRjoF43B90BcnDCMHyvqCVYWV/hXLbAqihtAGtNL4hMf4tIiUelfEgMeuIipFXSTZxOV5Fn16MpGnR8okYXSd21l8oPfJJImGAilqDLnJuzs9KydLcGM3RLCGW69u7//6sSixBpI8UXCf3rQflrV7MfpXpvJdVQs0QNwjOmF5r2x2zUvMP9/7/Zz9fOiOFuiO1YvCnRBQyAG8lw230+XJf+whExDy5teMW9wOrO/VMe4fSO1m0siqAE5mgMFSMs+Uc/YuGxdGA+lqZANMYIbA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=36ygOKn1fs4Ks6C9wABZwae93nvr1THSprN+hd8Q+zc=;
 b=FbwVIkcUpfFan8HGE/uIPHTGXxmlpc2l+6M53/kRhZf5EwBulF6lr95q5p7puJvztn3umUQB9WOFIyunwzNxFovQ7o4xNLq5igs6oRpoNHGuvXTCDayK9qQN29KhxY5tZyNGQxfxQHfDZ7BXC2r4Ah11GZDlVZ0z2wbqU1nZw5WAkPmX/nZAc8TJW50ep7D2xFtcgNKJxmckSnKSO0MFbkQT0IpsNjH59XIANqdZaDCivVmVybLAzpN2GMDPZ1Gq9CUIreJSMud46DjApLQQYsdUF9sZ78CMQhi3rghpM/ypp3pVlVCkUGF5D2joDJNsPyQMzYmeOa+G8RYs3N3Fdw==
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=36ygOKn1fs4Ks6C9wABZwae93nvr1THSprN+hd8Q+zc=;
 b=MuLqIcmh0cxMJAJKcF8r842pjP2VyPuFv8AquMSo11LYZ7SE/UMJUcirD/Z4KSJRQ/25is59EbydkJK1TZfWL0Z6R+skhVTDzvEAKJSSMi9MOUTfpKDn0YCPTsjYF8+n83l7ZXKrg4tYef5JeOjWv8/luzNcPFsV9aHpMQt3VW1zX8K3Bya+gs6FPJFUZKBJT6wwkPNK4BLY3eZGwI7TFtx5UkgsU5pXyJD/FpOQhl2goNoGkvl/aH7M7+oUunzq44njQficYNDfbtg120supKunoVx0Q33pUB4jBJOmnudS6nuijh2Pze9fN3MEwtS14g5902HjX0AFFBdeBJeUwg==
From: Oleksii Moisieiev 
To: Stefano Stabellini 
CC: "xen-devel@lists.xenproject.org" , Andrew
 Cooper , Anthony PERARD
	, Bertrand Marquis , Jan
 Beulich , Juergen Gross , Julien Grall
	, Michal Orzel ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Volodymyr
 Babchuk , Grygorii Strashko
	
Subject: Re: [RFC PATCH v4 5/8] xen/domctl: extend XEN_DOMCTL_assign_device to
 handle not only iommu
Thread-Topic: [RFC PATCH v4 5/8] xen/domctl: extend XEN_DOMCTL_assign_device
 to handle not only iommu
Thread-Index: AQHbyNXPDXt2FT3RV02cltfdm/Dd7rPdzmiAgCG+LgCACKrsAIACoXoA
Date: Thu, 19 Jun 2025 16:15:10 +0000
Message-ID: <1780646c-cb6f-4508-86c8-a573fbc09f6a@epam.com>
References: 
 <4f58bf9c47c40413ee9250c4cd21458382aac857.1747669845.git.oleksii_moisieiev@epam.com>
 
 
 
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: PAVPR03MB8946:EE_|DB8PR03MB6332:EE_
x-ms-office365-filtering-correlation-id: 5217f67d-5c3e-469f-b60c-08ddaf4c774e
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|376014|366016|7416014|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?YlZEbTUwN0UvWWNBYVlSQUlZeUt5RDcxVFArRXhTaE90ODZiUk9aZXZxUzcy?=
 =?utf-8?B?N1Q4UW1IRnNHWU9EUHdwRXhKOGM4STdickpISHM3WmtVazI1U3Vjd0RsSW05?=
 =?utf-8?B?akdIaG1OdHlHNDlCMEZQYmJPQnBnanhuYUlkVThMSTRTNVhnM1BlMTNGWU9h?=
 =?utf-8?B?OE9raTVybWdOZVJvSjdoVmVuYW9KbjBwNTVUSHd5ZFhSclF5TGdMU09RcDdJ?=
 =?utf-8?B?bGdrRm4zaEpqTVhDVFNNbnBBU2NKWlQ4Wko3SEJrakRSeXpoSnl0d3RYQm1H?=
 =?utf-8?B?Y0MvZVM4MWtIK3pFTHUveUJFTjVrN3FSS3k0NHdXUXJ4RUNTOERTRnE0K1Fu?=
 =?utf-8?B?SlpOVWVJMXp0SXNDTm8zMHZkMDhhckN6VnRLTTFHVndkdm9vWUdob21aTDZj?=
 =?utf-8?B?eUFhWDFiWVhhTWgyek15SW5hYmY0RGJHOCthZGNWUXViRmhrdzdRbC9aa0oz?=
 =?utf-8?B?SktqeGwxWWIxREFJTitEQXJpN0hXdUZ0cWk3R1U4VExNVllybmx1dnpVa0NV?=
 =?utf-8?B?bzNnbWZFeXFjRDV1TXhIb0xaQ0ZsSi9wZ1FTUmd5RjFRTlBjOTdGa0NwZHg0?=
 =?utf-8?B?NnpiYTFYc2dDa2NaY1grb0VEU0NhSmZIMmJ0UUYxYmF0VFZOV2R1K3VtYktq?=
 =?utf-8?B?aDl2bXF4WERGNFFqbWNWRWZJUTg5aTM2TFg4aUFkckJsbWlZNjZVMWc3UzVQ?=
 =?utf-8?B?VmtzQ0ViSk4yK2ZTQ1VvUm14UjJOYjNzOWlydGJ2OTRaZUVCS1lrMmZJUjBG?=
 =?utf-8?B?bHpWYnNmNEptTDNJeEcyT3dScTU0aURUYktNS1Uvek5XQnpQQUFIK0x5Kzc4?=
 =?utf-8?B?cDBzZXcyZk4wNzdSRkYzSHcydm9QcWdBRERDaEM1cktIS25JVkU1dHdlRjJH?=
 =?utf-8?B?ajF0ekVrRTFFUFRkUWVDZmNNaWM5NWd3NU5HWGlRWU8rcTR4LzlYaDFxQmoz?=
 =?utf-8?B?a1ZrUkNXVGdGMSsrVW96ZkhXbGFnQ2dKWmVEWWhhYnROV0QvU0hMTVZhdllG?=
 =?utf-8?B?eGVNOE1GQ2RDQmNmVit2eWMzV3picnQyWGQwNUxEanVVUS9MSDQ0SkR1eXky?=
 =?utf-8?B?MDkyWm5vK2FpU1FxcStLcVl2WXBqL2s4djdZT2pWZG9odTRhblhHRXlmTDlz?=
 =?utf-8?B?ZlpNWUs4Zkw4WTVKQ29YdHZKcUM0UVVBNWRJNzZFVTFpMXMzalF3bkoxemNY?=
 =?utf-8?B?eUp2NGZtbFJUVXRGdjlHWUVmcnRqYW8xWHRvMEplaktDNG1UZzg2RVZnZnZS?=
 =?utf-8?B?MUVIQVlVelM3WEZPZFI2VUVvV01DMGk2T0dYelFieHI3TFRrNUoybzlSdEtZ?=
 =?utf-8?B?bk92aDNPZ1luT3Nvc055Y0R0WDhXQS82Y0tWSHdNS1FmTXRDNHpBVVZIdVox?=
 =?utf-8?B?R3A1eFJVd1dBK1Y0S1UrSzFyMmZ6UjQ3UllMWW9QcXBRRlBobFBGdHNmTTZM?=
 =?utf-8?B?ZVJaamw3ZmFKU1RFeWxlQ2lZZGpwdS9peitBKzRvdGtiMHVKRW9ucVAwNTlv?=
 =?utf-8?B?RGVPOFJlWFBhU0MvUVZqbTh4UWV1TE55enRua0tjMkV6QVB3ZnEzUE5CWEli?=
 =?utf-8?B?Q2xkQUlOTVpmckl3ZmhtalE3dUJUUzRFRDZhYkhhTm1YbTlnRVlCQVNuUHZk?=
 =?utf-8?B?UmdXZWFzSG1aYk5NRkNuWExtVDVSN05YWi9XK0tyOVBPMzhmVlVTN1NGM044?=
 =?utf-8?B?cVk5alJqRmFEamREcks2TkRURnlXTmlQMEN1UkdvUnFySjZySyttV1RBN2hZ?=
 =?utf-8?B?SHEzZHVuYTBVK01mU1ArMFVTcEkwaG9zNEE4WUV6YzNPdkxZU2I5NVp5aDNm?=
 =?utf-8?B?aFNXTFJiTzM1QnN5NzE5bHBlTWR3THZQWW93Sm9vOUZIYmpTdlRmbWNVblEx?=
 =?utf-8?B?bVlmeTlxSFNVbFJJS0d3WWNsRmNTVHpvOC95b3d1Q2FCMERYRmxuak1pSEJM?=
 =?utf-8?B?WnhHZ25XaHc3QUxOcmhUWXEyMWg3S2ozTlM5aHJQYUxsZUdzdW93L29tMStY?=
 =?utf-8?Q?DwYoB2/7KF37m+vq2hLceCEwgQGItA=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7416014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?SFpiaXZ3NlNwYnI4dXVwandMNW1HczZGZFlYeWlKNExWektpbGUzUHRkdlg2?=
 =?utf-8?B?YWVqdXJ3cFl3SUFlVkQzTW1zMVdkc3VqeFBERjdYR1J5NGRPaXd2cytUWWk4?=
 =?utf-8?B?T3hlY01KblM1WThhVjJRbU9ld0ErTmd6VVRCUG14YXJJTExmSE5MV3RkcFQr?=
 =?utf-8?B?R2MzTHlLaUQvRG9zdlFOTDdJV2hzVFkxYTMvQWRBeDRQWnplM2FzZk40OUk3?=
 =?utf-8?B?Y3RldTFXNUlrbG1XelR1L21VR01NUW9UdjE0bVVYL0p2SnlCOEc3M0dYVnd2?=
 =?utf-8?B?TmswY3dWTnRkZCt5blBlQThVbUN5T2UwTVd5cW5rVTZsWEYzM1VUejJsVlBp?=
 =?utf-8?B?U1FmdVBlUk9oUnl2VzRMM0dDdXJvVDJic3J3Rm4rSC90eHQ0NUgrdXdTSDIw?=
 =?utf-8?B?Y1RpVEVBWjc1ckFxMHRpMUphdXBXMEo5blBSaUd5UG9xNVFsd2txNHgxWlM4?=
 =?utf-8?B?VlUvNkJMZHRVMVRDemYwd1hReUtYY1lESGJ6VXdqYlNkZGFRVjB5cHVGREtC?=
 =?utf-8?B?Yk5aMVRaZkN0TDNEc1FRTENOUFRwUys2bXpEQjBoSUdSQ0pHU2UrOUdaSHYv?=
 =?utf-8?B?YjdjNjJ4SDJBWVJRTnFMM3h3MnAwN1Y3NEpCYngrbUo5ajdDbURRcnVCMm9a?=
 =?utf-8?B?eU02ZndnMW80UVc3UzMzM2tNMGt6RmRIVVY5c0J0b0xwTU04ckFnRVlRL1dX?=
 =?utf-8?B?cERPa2ZjYVhUckd4cTBwVVphUy9SL21JTFVva3I3YUZ4dm5ucTUzWVFobGxy?=
 =?utf-8?B?cUc5Qys0U3RRWG5GOE1UemJ0S3d3ZU9FMGt6dFdTTlc2UWVia1VWMnRBbWJ0?=
 =?utf-8?B?bzlVZ01NVzFOL0RpZHlBWW1PWjJ2RDFKdU1ZbE5uZmg3QndJd2krd2dJZjRt?=
 =?utf-8?B?c3ZQNGw5M1JiRGhMZXUrVTVoMllEOTE0WThpUDFuVndleFlpcHg3VklHaEhH?=
 =?utf-8?B?MGc4a3dueWVMZ2xhcTRHQXNUeks4NmVJSmNDejVWRllKNjRqbWhyUXQ2N3lz?=
 =?utf-8?B?NmJLMHFmSWtDTk9tZ2o4YVdhdGJxZ09IYlBrWWdBRFZnNHY5bHF2QXU0OFVx?=
 =?utf-8?B?eXZ1dzVZNVB5SFR6LzAxc0E2S2RBZzd2aUhyTUhRQU15SVA5UmxZS3FTdHMx?=
 =?utf-8?B?MmprbWQzaWRYSVEvMDdNUmxXdklYZE9HZjZmbUhsb1BOUkFqamR0OGk3RkIv?=
 =?utf-8?B?WVQvMk5QTWJiYzVVUCsveWNTdC9wNzVRUlRlWlBtaEExRzRjN0NYNUFGTkFH?=
 =?utf-8?B?Z2l1ZHBhS0N4dWpiY1JLeVVJM3cvWkw4ZHFSeDArNHN6QnRwWmNVaXZnU2d2?=
 =?utf-8?B?ZzZwZWdQdjQrK1ZhSnoxQVUxSXp2OUV2cThMTm5lUWhYZGhORUc3REMxajB4?=
 =?utf-8?B?dTF3ejMwNFlldm5ra0xXM0pYU3ZNRk8vNTR4RjNpWFFLcTd3QUNYdk81UFFY?=
 =?utf-8?B?SUUzSDRNQVFzYngyK0pVMUFKbnZ2ZmZwV2wzY0VxMGRwc1Z4YkZHZ3RlMytB?=
 =?utf-8?B?ZXdJWWl3UCtQbUFKUHUwamdZY3pVOVNqUWFpYXpFWWFubEQxeHdvNi9TK1R2?=
 =?utf-8?B?QW8zcGZyQlZWczErZllaeFpYTnNDZSs0UFNRbGhWUS84bmdLR0Z0TWhuYnNm?=
 =?utf-8?B?eWJrNGZTQi95WGY4YWxrUmUxYXNMaFpFUnMyb01PUFdnT1o4WHZNTDNoUEdV?=
 =?utf-8?B?bGVyVVBmbDBTMGs2R1g2azEzYVBpdXhOL3I1SVpubjY3RCtQVnRPNGtOWWJm?=
 =?utf-8?B?Tk9kbWhSQnIza2ZVWkxNQk9kTnJkbS9MakxnZCtRNXpjdldUczEwRmtMamhH?=
 =?utf-8?B?SHNYVHRqWlBobFVnWFYyRUdHMzVZcW9WRTd5ZDNCU2F3ZStLRTZGdlgzQno1?=
 =?utf-8?B?VkRKbEpEMmtLNXRXS0VqYjVVWHZsQVJQWkdETTk4bHd5UGRKTm81YTNNNVRh?=
 =?utf-8?B?YzBqMVhQNVhiYTVNYWJvcUh2WEN2YmExb3Z1UDNwcVk0UDFUZjJtODlTRG5X?=
 =?utf-8?B?NTV5cnZaQTVEUnRQQU1QMUg5T1FMYU00eXlGbERRUEM5QnducjhTbU9wdER5?=
 =?utf-8?B?RThHY0RLRHd0dXp1YWVXVndzSnhsV0xEbjVKcHRPampxcG9wclFndDZ3Wk5K?=
 =?utf-8?B?SjRIV1ZFWVhuVkZ4dmpPalN3MmxocDFxYTZiU0RiUUh2enRkWmMybmRJWW1T?=
 =?utf-8?B?L3c9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <661CB46FCFB4464AB8662B7ABED2323A@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: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5217f67d-5c3e-469f-b60c-08ddaf4c774e
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2025 16:15:11.0048
 (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: Ix2hL8uDMMaz2Psyz05YKRKruOtSyOH2yn7RckBAvv1UhWj67x99ChZADIwkJJDvVxoaKeVGKCB+THvJ9cdLTm6kjyPiaZn1yQMNudVm2L4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR03MB6332

DQpPbiAxOC8wNi8yMDI1IDAzOjA0LCBTdGVmYW5vIFN0YWJlbGxpbmkgd3JvdGU6DQo+IE9uIFRo
dSwgMTIgSnVuIDIwMjUsIE9sZWtzaWkgTW9pc2llaWV2IHdyb3RlOg0KPj4gSGkgU3RlZmFubywN
Cj4+DQo+PiBJJ20gdmVyeSBzb3JyeSBmb3IgYSBsb25nIHNpbGVuY2UuIFBsZWFzZSBzZWUgbXkg
YW5zd2VycyBiZWxvdzoNCj4+DQo+PiBPbiAyMi8wNS8yMDI1IDAzOjI1LCBTdGVmYW5vIFN0YWJl
bGxpbmkgd3JvdGU6DQo+Pj4gT24gTW9uLCAxOSBNYXkgMjAyNSwgT2xla3NpaSBNb2lzaWVpZXYg
d3JvdGU6DQo+Pj4+IEZyb206IEdyeWdvcmlpIFN0cmFzaGtvPGdyeWdvcmlpX3N0cmFzaGtvQGVw
YW0uY29tPg0KPj4+Pg0KPj4+PiBBZGQgY2hhaW5lZCBoYW5kbGluZyBvZiBhc3NpZ25lZCBEVCBk
ZXZpY2VzIHRvIHN1cHBvcnQgYWNjZXNzLWNvbnRyb2xsZXINCj4+Pj4gZnVuY3Rpb25hbGl0eSB0
aHJvdWdoIFNDSSBmcmFtZXdvcmssIHNvIERUIGRldmljZSBhc3NpZ24gcmVxdWVzdCBjYW4gYmUN
Cj4+Pj4gcGFzc2VkIHRvIEZXIGZvciBwcm9jZXNzaW5nIGFuZCBlbmFibGluZyBWTSBhY2Nlc3Mg
dG8gcmVxdWVzdGVkIGRldmljZQ0KPj4+PiAoZm9yIGV4YW1wbGUsIGRldmljZSBwb3dlciBtYW5h
Z2VtZW50IHRocm91Z2ggRlcgaW50ZXJmYWNlIGxpa2UgU0NNSSkuDQo+Pj4+DQo+Pj4+IFRoZSBT
Q0kgYWNjZXNzLWNvbnRyb2xsZXIgRFQgZGV2aWNlIHByb2Nlc3NpbmcgaXMgY2hhaW5lZCBhZnRl
ciBJT01NVQ0KPj4+PiBwcm9jZXNzaW5nIGFuZCBleHBlY3RlZCB0byBiZSBleGVjdXRlZCBmb3Ig
YW55IERUIGRldmljZSByZWdhcmRsZXNzIG9mIGl0cw0KPj4+PiBwcm90ZWN0aW9uIGJ5IElPTU1V
IChvciBpZiBJT01NVSBpcyBkaXNhYmxlZCkuDQo+Pj4+DQo+Pj4+IFRoaXMgYWxsb3dzIHRvIHBh
c3Mgbm90IG9ubHkgSU9NTVUgcHJvdGVjdGVkIERUIGRldmljZSB0aHJvdWdoDQo+Pj4+IHhsLmNm
ZzoiZHRkZXYiIHByb3BlcnR5IGZvciBwcm9jZXNzaW5nOg0KPj4+Pg0KPj4+PiBkdGRldiA9IFsN
Cj4+Pj4gICAgICAgIi9zb2MvdmlkZW9AZTZlZjAwMDAiLCA8LSBJT01NVSBwcm90ZWN0ZWQgZGV2
aWNlDQo+Pj4+ICAgICAgICIvc29jL2kyY0BlNjUwODAwMCIsIDwtIG5vdCBJT01NVSBwcm90ZWN0
ZWQgZGV2aWNlDQo+Pj4+IF0NCj4+Pj4NCj4+Pj4gVGhlIGNoYW5nZSBpcyBkb25lIGluIHR3byBw
YXJ0czoNCj4+Pj4gMSkgdXBkYXRlIGlvbW11X2RvX2R0X2RvbWN0bCgpIHRvIGNoZWNrIGZvciBk
dF9kZXZpY2VfaXNfcHJvdGVjdGVkKCkgYW5kDQo+Pj4+IG5vdCBmYWlsIGlmIERUIGRldmljZSBp
cyBub3QgcHJvdGVjdGVkIGJ5IElPTU1VDQo+Pj4+IDIpIGFkZCBjaGFpbmVkIGNhbGwgdG8gc2Np
X2RvX2RvbWN0bCgpIGluIGRvX2RvbWN0bCgpDQo+Pj4+DQo+Pj4+IFNpZ25lZC1vZmYtYnk6IEdy
eWdvcmlpIFN0cmFzaGtvPGdyeWdvcmlpX3N0cmFzaGtvQGVwYW0uY29tPg0KPj4+PiBTaWduZWQt
b2ZmLWJ5OiBPbGVrc2lpIE1vaXNpZWlldjxvbGVrc2lpX21vaXNpZWlldkBlcGFtLmNvbT4NCj4+
Pj4gLS0tDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+ICAgIHhlbi9hcmNoL2FybS9maXJtd2FyZS9z
Y2kuYyAgICAgICAgICAgICB8IDM3ICsrKysrKysrKysrKysrKysrKysrKysrKysNCj4+Pj4gICAg
eGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2Zpcm13YXJlL3NjaS5oIHwgMTQgKysrKysrKysrKw0K
Pj4+PiAgICB4ZW4vY29tbW9uL2RvbWN0bC5jICAgICAgICAgICAgICAgICAgICAgfCAxOSArKysr
KysrKysrKysrDQo+Pj4+ICAgIHhlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2RldmljZV90cmVlLmMg
ICB8ICA2ICsrKysNCj4+Pj4gICAgNCBmaWxlcyBjaGFuZ2VkLCA3NiBpbnNlcnRpb25zKCspDQo+
Pj4+DQo+Pj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NpLmMgYi94ZW4v
YXJjaC9hcm0vZmlybXdhcmUvc2NpLmMNCj4+Pj4gaW5kZXggZTE1MjJlMTBlMi4uOGVmZDU0MWM0
ZiAxMDA2NDQNCj4+Pj4gLS0tIGEveGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjaS5jDQo+Pj4+ICsr
KyBiL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY2kuYw0KPj4+PiBAQCAtMTI2LDYgKzEyNiw0MyBA
QCBpbnQgc2NpX2Fzc2lnbl9kdF9kZXZpY2Uoc3RydWN0IGRvbWFpbiAqZCwgc3RydWN0IGR0X2Rl
dmljZV9ub2RlICpkZXYpDQo+Pj4+ICAgICAgICByZXR1cm4gMDsNCj4+Pj4gICAgfQ0KPj4+PiAg
ICANCj4+Pj4gK2ludCBzY2lfZG9fZG9tY3RsKHN0cnVjdCB4ZW5fZG9tY3RsICpkb21jdGwsIHN0
cnVjdCBkb21haW4gKmQsDQo+Pj4+ICsgICAgICAgICAgICAgICAgICBYRU5fR1VFU1RfSEFORExF
X1BBUkFNKHhlbl9kb21jdGxfdCkgdV9kb21jdGwpDQo+Pj4+ICt7DQo+Pj4+ICsgICAgc3RydWN0
IGR0X2RldmljZV9ub2RlICpkZXY7DQo+Pj4+ICsgICAgaW50IHJldCA9IDA7DQo+Pj4+ICsNCj4+
Pj4gKyAgICBzd2l0Y2ggKCBkb21jdGwtPmNtZCApDQo+Pj4+ICsgICAgew0KPj4+PiArICAgIGNh
c2UgWEVOX0RPTUNUTF9hc3NpZ25fZGV2aWNlOg0KPj4+PiArICAgICAgICByZXQgPSAtRU9QTk9U
U1VQUDsNCj4+PiBBcmUgeW91IHN1cmUgLUVPUE5PVFNVUFAgaXMgdGhlIHJpZ2h0IGVycm9yIGNv
ZGUgZm9yIHRoZSAzIGNoZWNrcyBiZWxvdz8NCj4+IFRoZSAtRU9QTk9UU1VQUCBjb2RlIGlzIHVz
ZWQgYmVjYXVzZSB0aGlzIGlzIHBhcnQgb2YgYSBjaGFpbmVkIGNhbGwgYWZ0ZXINCj4+IGlvbW11
X2RvX2RvbWN0bCwgYXMgc3RhdGVkIGluIHhlbi9jb21tb24vZG9tY3RsLmM6ODU5LiBUaGUNCj4+
IFhFTl9ET01DVExfYXNzaWduX2RldmljZQ0KPj4gY2FsbCBpcyBleHBlY3RlZCB0byBoYW5kbGUg
YW55IERUIGRldmljZSwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIHRoZSBEVA0KPj4gZGV2aWNlIGlz
DQo+PiBwcm90ZWN0ZWQgYnkgYW4gSU9NTVUgb3IgaWYgdGhlIElPTU1VIGlzIGRpc2FibGVkLg0K
Pj4gVGhlIGZvbGxvd2luZyBjYXNlcyBhcmUgY29uc2lkZXJlZDoNCj4+DQo+PiAxLiBJT01NVSBQ
cm90ZWN0ZWQgRGV2aWNlIChTdWNjZXNzKQ0KPj4NCj4+IElmIHRoZSBkZXZpY2UgaXMgcHJvdGVj
dGVkIGJ5IHRoZSBJT01NVSBhbmQgaW9tbXVfZG9fZG9tY3RsIHJldHVybnMgMCwNCj4+IHdlIGNv
bnRpbnVlDQo+PiBwcm9jZXNzaW5nIHRoZSBEVCBkZXZpY2UgYnkgY2FsbGluZyBzY2lfZG9fZG9t
Y3RsLg0KPj4NCj4+IDIuIElPTU1VIERpc2FibGVkICgtRU9QTk9UU1VQUCBmcm9tIGlvbW11X2Rv
X2RvbWN0bCkNCj4+DQo+PiBJZiBpb21tdV9kb19kb21jdGwgcmV0dXJucyAtRU9QTk9UU1VQUCwg
aW5kaWNhdGluZyB0aGF0IHRoZSBJT01NVSBpcw0KPj4gZGlzYWJsZWQsDQo+PiB3ZSBzdGlsbCBw
cm9jZWVkIHRvIGNhbGwgc2NpX2RvX2RvbWN0bC4NCj4gT0sgdGhpcyBtYWtlcyBzZW5zZS4gIEkg
dGhpbmsgaXQgaXMgT0sgdG8gaGF2ZSBhIHNwZWNpYWwgZXJyb3IgY29kZSB0bw0KPiBzYXkgInRo
ZSBJT01NVSBpcyBkaXNhYmxlZCIgYnV0IEkgZG9uJ3Qga25vdyBpZiBpdCBpcyBhIGdvb2QgaWRl
YSB0byB0cnkNCj4gdG8gdXNlIC1FT1BOT1RTVVBQIGZvciB0aGF0LiAtRU9QTk9UU1VQUCBjb3Vs
ZCBtZWFuIGEgaHlwZXJ2aXNvcg0KPiBjb25maWd1cmF0aW9uIHdpdGggZG9tY3RsIGRpc2FibGVk
LCBmb3IgaW5zdGFuY2UuDQo+DQo+IEl0IG1pZ2h0IGJlIHdpc2VyIHRvIHVzZSBhIGRpZmZlcmVu
dCBlcnJvciBjb2RlLiBNYXliZSBFTk9FTlQ/DQo+DQpJIHNlZSB0aGF0IGluIHRoZSBmb2xsb3dp
bmcgY29tbWl0Og0KDQo3MWU2MTdhNmI4ICh1c2UgaXNfaW9tbXVfZW5hYmxlZCgpIHdoZXJlIGFw
cHJvcHJpYXRlLi4uLCAyMDE5LTA5LTE3KQ0KDQotRU5PU1lTIHJldHVybiBjb2RlIHdhcyBjaGFu
Z2VkIHRvIC1FT1BOT1RTVVBQIGluIGlvbW11X2RvX2RvbWN0bC4NCg0KSXQncyBub3QgY2xlYXIg
dG8gbWUgd2h5IHRoaXMgd2FzIGRvbmUgZnJvbSB0aGUgY29tbWl0IGRlc2NyaXB0aW9uLg0KDQpN
YXliZSB3ZSBzaG91bGQgYWRkIGNvbW1pdCBhdXRob3I/DQoNCj4+IDMuIEVycm9yIGZyb20gaW9t
bXVfZG9fZG9tY3RsIChGYWlsIFN0YXRlKQ0KPj4NCj4+IElmIGlvbW11X2RvX2RvbWN0bCByZXR1
cm5zIGFueSBlcnJvciwgdGhlIHN5c3RlbSBlbnRlcnMgYSBmYWlsIHN0YXRlLCBhbmQNCj4+IHNj
aV9kb19kb21jdGwgaXMgbm90IGNhbGxlZC4NCj4+DQo+PiA0LiAtRU9QTk9UU1VQUCBmcm9tIHNj
aV9kb19kb21jdGwNCj4+DQo+PiBJZiBzY2lfZG9fZG9tY3RsIHJldHVybnMgLUVPUE5PVFNVUFAs
IHRoaXMgaW5kaWNhdGVzIG9uZSBvZiB0aGUgZm9sbG93aW5nOg0KPj4gLSBUaGUgcHJvdmlkZWQg
ZGV2aWNlIGlzIG5vdCBhIERUIGRldmljZS4NCj4+IC0gVGhlcmUgaXMgbm8gY3VyX21lZGlhdG9y
IGF2YWlsYWJsZSAoaW5kaWNhdGluZyB0aGF0IHRoZSBTQ0kgc3Vic3lzdGVtDQo+PiBpcyBlbmFi
bGVkDQo+PiBpbiB0aGUgY29uZmlndXJhdGlvbiwgYnV0IG5vIG1lZGlhdG9yIHdhcyBwcm92aWRl
ZCkuDQo+PiAtIFRoZSBjdXJyZW50IG1lZGlhdG9yIGRvZXMgbm90IHN1cHBvcnQgYXNzaWduX2R0
X2RldmljZSAodGhpcyBpcw0KPj4gZXhwZWN0ZWQgdG8gYmUgY2hhbmdlZDsNCj4+IHNlZSBiZWxv
dyBmb3IgZGV0YWlscykuDQo+PiBJbiB0aGlzIGNhc2UsIC1FT1BOT1RTVVBQIGlzIHJldHVybmVk
IGJ1dCB3aWxsIGJlIGlnbm9yZWQsIGFuZCB0aGUNCj4+IG9yaWdpbmFsIHJldHVybiB2YWx1ZSBm
cm9tIGlvbW11X2RvX2RvbWN0bCB3aWxsIGJlIHVzZWQgYXMgdGhlIGZpbmFsIHJlc3VsdC4NCj4g
U2FtZSBjb21tZW50IGFzIGJlZm9yZS4gV2UgbmVlZCB0byBiZSBjYXJlZnVsIG5vdCBjb25mdXNl
IHRoaXMgY2FzZSB5b3UNCj4gZGVzY3JpYmVkIHdpdGggb3RoZXIgY2FzZXMgd2hlcmUgc2NpX2Rv
X2RvbWN0bCBpcyBzaW1wbHkgbm90DQo+IGltcGxlbWVudGVkLg0KPg0KSSB3YXMgdHJ5aW5nIHRv
IG1pbWljIGlvbW11X2RvX2RvbWN0bCBsb2dpYy4uLg0KPj4gNS4gUmV0dXJuIENvZGUgZnJvbSBz
Y2lfZG9fZG9tY3RsDQo+Pg0KPj4gSWYgc2NpX2RvX2RvbWN0bCByZXR1cm5zIDAgKHN1Y2Nlc3Mp
IG9yIGFuIGVycm9yIGNvZGUgKGZhaWx1cmUpLA0KPj4gdGhlIHJldHVybiB2YWx1ZSBmcm9tIGlv
bW11X2RvX2RvbWN0bCBpcyBvdmVycmlkZGVuLCBhbmQgdGhlIHJlc3VsdCBmcm9tDQo+PiBzY2lf
ZG9fZG9tY3RsIGlzIHJldHVybmVkLg0KPj4gTm90ZTogLUVPUE5PVFNVUFAgZnJvbSBpb21tdV9k
b19kb21jdGwgd2lsbCBhbHNvIGJlIG92ZXJyaWRkZW4gc2luY2UNCj4+IHN0ZXAgMiB3YXMgc3Vj
Y2Vzc2Z1bGx5IGNvbXBsZXRlZCAob3IgZmFpbGVkKS4NCj4+Pj4gKyAgICAgICAgaWYgKCBkb21j
dGwtPnUuYXNzaWduX2RldmljZS5kZXYgIT0gWEVOX0RPTUNUTF9ERVZfRFQgKQ0KPj4+PiArICAg
ICAgICAgICAgYnJlYWs7DQo+Pj4gdGhpcyBvbmUNCj4+Pg0KPj4+PiArICAgICAgICBpZiAoICFj
dXJfbWVkaWF0b3IgKQ0KPj4+PiArICAgICAgICAgICAgYnJlYWs7DQo+Pj4gdGhpcyBvbmUNCj4+
Pg0KPj4+PiArICAgICAgICBpZiAoICFjdXJfbWVkaWF0b3ItPmFzc2lnbl9kdF9kZXZpY2UgKQ0K
Pj4+PiArICAgICAgICAgICAgYnJlYWs7DQo+Pj4gYW5kIGFsc28gdGhpcyBvbmU/IEl0IHNlZW1z
IG1vcmUgbGlrZSBhbiAtRUlOVkFMIGFzIHRoZSBjYWxsZXIgdXNlZCBhDQo+Pj4gd3JvbmcgcGFy
YW1ldGVyPw0KPj4gSSB0aGluayB5b3UgYXJlIHJpZ2h0IHRoYXQgdGhpcyBjYXNlIHNob3VsZCBy
ZXR1cm4gLUVJTlZBTCBiZWNhdXNlIHdlDQo+PiBzaG91bGQgZmFpbCBpZiBtZWRpYXRvcg0KPj4N
Cj4+IHdpdGhvdXQgaW1wbGVtZW50ZWQgbWFuZGF0b3J5IGZlYXR1cmVzIHdhcyBwcm92aWRlZC4g
V2lsbCBiZSBmaXhlZC4NCj4+DQo+Pj4+ICsgICAgICAgIHJldCA9IGR0X2ZpbmRfbm9kZV9ieV9n
cGF0aChkb21jdGwtPnUuYXNzaWduX2RldmljZS51LmR0LnBhdGgsDQo+Pj4+ICsgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBkb21jdGwtPnUuYXNzaWduX2RldmljZS51LmR0LnNp
emUsICZkZXYpOw0KPj4+PiArICAgICAgICBpZiAoIHJldCApDQo+Pj4+ICsgICAgICAgICAgICBy
ZXR1cm4gcmV0Ow0KPj4+PiArDQo+Pj4+ICsgICAgICAgIHJldCA9IHNjaV9hc3NpZ25fZHRfZGV2
aWNlKGQsIGRldik7DQo+Pj4+ICsgICAgICAgIGlmICggcmV0ICkNCj4+Pj4gKyAgICAgICAgICAg
IGJyZWFrOw0KPj4+PiArDQo+Pj4+ICsgICAgICAgIGJyZWFrOw0KPj4+PiArICAgIGRlZmF1bHQ6
DQo+Pj4+ICsgICAgICAgIC8qIGRvIG5vdCBmYWlsIGhlcmUgYXMgY2FsbCBpcyBjaGFpbmVkIHdp
dGggaW9tbXUgaGFuZGxpbmcgKi8NCj4+PiBJdCBsb29rcyBsaWtlIHRoaXMgc2hvdWxkIGJlIGFu
IGVycm9yDQo+Pj4NCj4+Pg0KPj4+PiArICAgICAgICBicmVhazsNCj4+Pj4gKyAgICB9DQo+Pj4+
ICsNCj4+Pj4gKyAgICByZXR1cm4gcmV0Ow0KPj4+PiArfQ0KPj4+PiArDQo+Pj4+ICAgIHN0YXRp
YyBpbnQgX19pbml0IHNjaV9pbml0KHZvaWQpDQo+Pj4+ICAgIHsNCj4+Pj4gICAgICAgIHN0cnVj
dCBkdF9kZXZpY2Vfbm9kZSAqbnA7DQo+Pj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vaW5j
bHVkZS9hc20vZmlybXdhcmUvc2NpLmggYi94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vZmlybXdh
cmUvc2NpLmgNCj4+Pj4gaW5kZXggNzFmYjU0ODUyZS4uYjhkMWJjOGE2MiAxMDA2NDQNCj4+Pj4g
LS0tIGEveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2Zpcm13YXJlL3NjaS5oDQo+Pj4+ICsrKyBi
L3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9maXJtd2FyZS9zY2kuaA0KPj4+PiBAQCAtMTQ2LDYg
KzE0NiwxNCBAQCBpbnQgc2NpX2R0X2ZpbmFsaXplKHN0cnVjdCBkb21haW4gKmQsIHZvaWQgKmZk
dCk7DQo+Pj4+ICAgICAqIGNvbnRyb2wiIGZ1bmN0aW9uYWxpdHkuDQo+Pj4+ICAgICAqLw0KPj4+
PiAgICBpbnQgc2NpX2Fzc2lnbl9kdF9kZXZpY2Uoc3RydWN0IGRvbWFpbiAqZCwgc3RydWN0IGR0
X2RldmljZV9ub2RlICpkZXYpOw0KPj4+PiArDQo+Pj4+ICsvKg0KPj4+PiArICogU0NJIGRvbWN0
bCBoYW5kbGVyDQo+Pj4+ICsgKg0KPj4+PiArICogT25seSBYRU5fRE9NQ1RMX2Fzc2lnbl9kZXZp
Y2UgaXMgaGFuZGxlZCBmb3Igbm93Lg0KPj4+PiArICovDQo+Pj4+ICtpbnQgc2NpX2RvX2RvbWN0
bChzdHJ1Y3QgeGVuX2RvbWN0bCAqZG9tY3RsLCBzdHJ1Y3QgZG9tYWluICpkLA0KPj4+PiArICAg
ICAgICAgICAgICAgICAgWEVOX0dVRVNUX0hBTkRMRV9QQVJBTSh4ZW5fZG9tY3RsX3QpIHVfZG9t
Y3RsKTsNCj4+Pj4gICAgI2Vsc2UNCj4+Pj4gICAgDQo+Pj4+ICAgIHN0YXRpYyBpbmxpbmUgYm9v
bCBzY2lfZG9tYWluX2lzX2VuYWJsZWQoc3RydWN0IGRvbWFpbiAqZCkNCj4+Pj4gQEAgLTE5NSw2
ICsyMDMsMTIgQEAgc3RhdGljIGlubGluZSBpbnQgc2NpX2Fzc2lnbl9kdF9kZXZpY2Uoc3RydWN0
IGRvbWFpbiAqZCwNCj4+Pj4gICAgICAgIHJldHVybiAwOw0KPj4+PiAgICB9DQo+Pj4+ICAgIA0K
Pj4+PiArc3RhdGljIGlubGluZSBpbnQgc2NpX2RvX2RvbWN0bChzdHJ1Y3QgeGVuX2RvbWN0bCAq
ZG9tY3RsLCBzdHJ1Y3QgZG9tYWluICpkLA0KPj4+PiArICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBYRU5fR1VFU1RfSEFORExFX1BBUkFNKHhlbl9kb21jdGxfdCkgdV9kb21jdGwpDQo+
Pj4+ICt7DQo+Pj4+ICsgICAgcmV0dXJuIDA7DQo+Pj4+ICt9DQo+Pj4+ICsNCj4+Pj4gICAgI2Vu
ZGlmIC8qIENPTkZJR19BUk1fU0NJICovDQo+Pj4+ICAgIA0KPj4+PiAgICAjZW5kaWYgLyogX19B
U01fQVJNX1NDSV9IICovDQo+Pj4+IGRpZmYgLS1naXQgYS94ZW4vY29tbW9uL2RvbWN0bC5jIGIv
eGVuL2NvbW1vbi9kb21jdGwuYw0KPj4+PiBpbmRleCAwNWFiYjU4MWEwLi5hNzRlZTkyMDY3IDEw
MDY0NA0KPj4+PiAtLS0gYS94ZW4vY29tbW9uL2RvbWN0bC5jDQo+Pj4+ICsrKyBiL3hlbi9jb21t
b24vZG9tY3RsLmMNCj4+Pj4gQEAgLTI3LDYgKzI3LDcgQEANCj4+Pj4gICAgI2luY2x1ZGUgPHhl
bi92bV9ldmVudC5oPg0KPj4+PiAgICAjaW5jbHVkZSA8eGVuL21vbml0b3IuaD4NCj4+Pj4gICAg
I2luY2x1ZGUgPGFzbS9jdXJyZW50Lmg+DQo+Pj4+ICsjaW5jbHVkZSA8YXNtL2Zpcm13YXJlL3Nj
aS5oPg0KPj4+PiAgICAjaW5jbHVkZSA8YXNtL2lycS5oPg0KPj4+PiAgICAjaW5jbHVkZSA8YXNt
L3BhZ2UuaD4NCj4+Pj4gICAgI2luY2x1ZGUgPGFzbS9wMm0uaD4NCj4+Pj4gQEAgLTg1MSw2ICs4
NTIsMjQgQEAgbG9uZyBkb19kb21jdGwoWEVOX0dVRVNUX0hBTkRMRV9QQVJBTSh4ZW5fZG9tY3Rs
X3QpIHVfZG9tY3RsKQ0KPj4+PiAgICAgICAgY2FzZSBYRU5fRE9NQ1RMX2RlYXNzaWduX2Rldmlj
ZToNCj4+Pj4gICAgICAgIGNhc2UgWEVOX0RPTUNUTF9nZXRfZGV2aWNlX2dyb3VwOg0KPj4+PiAg
ICAgICAgICAgIHJldCA9IGlvbW11X2RvX2RvbWN0bChvcCwgZCwgdV9kb21jdGwpOw0KPj4+PiAr
DQo+Pj4+ICsgICAgICAgIGlmICggIXJldCB8fCByZXQgPT0gLUVPUE5PVFNVUFAgKQ0KPj4+IEl0
IGlzIGJldHRlciB0byBpbnZlcnQgdGhlIGNoZWNrOg0KPj4+DQo+Pj4gaWYgKCByZXQgPCAwICYm
IHJldCAhPSAtRU9QTk9UU1VQUCApDQo+Pj4gICAgICAgcmV0dXJuIHJldDsNCj4+ICsNCj4+Pj4g
KyAgICAgICAgew0KPj4+PiArICAgICAgICAgICAgaW50IHJldDE7DQo+Pj4+ICsgICAgICAgICAg
ICAvKg0KPj4+PiArICAgICAgICAgICAgICogQWRkIGNoYWluZWQgaGFuZGxpbmcgb2YgYXNzaWdu
ZWQgRFQgZGV2aWNlcyB0byBzdXBwb3J0DQo+Pj4+ICsgICAgICAgICAgICAgKiBhY2Nlc3MtY29u
dHJvbGxlciBmdW5jdGlvbmFsaXR5IHRocm91Z2ggU0NJIGZyYW1ld29yaywgc28NCj4+Pj4gKyAg
ICAgICAgICAgICAqIERUIGRldmljZSBhc3NpZ24gcmVxdWVzdCBjYW4gYmUgcGFzc2VkIHRvIEZX
IGZvciBwcm9jZXNzaW5nIGFuZA0KPj4+PiArICAgICAgICAgICAgICogZW5hYmxpbmcgVk0gYWNj
ZXNzIHRvIHJlcXVlc3RlZCBkZXZpY2UuDQo+Pj4+ICsgICAgICAgICAgICAgKiBUaGUgYWNjZXNz
LWNvbnRyb2xsZXIgRFQgZGV2aWNlIHByb2Nlc3NpbmcgaXMgY2hhaW5lZCBhZnRlciBJT01NVQ0K
Pj4+PiArICAgICAgICAgICAgICogcHJvY2Vzc2luZyBhbmQgZXhwZWN0ZWQgdG8gYmUgZXhlY3V0
ZWQgZm9yIGFueSBEVCBkZXZpY2UNCj4+Pj4gKyAgICAgICAgICAgICAqIHJlZ2FyZGxlc3MgaWYg
RFQgZGV2aWNlIGlzIHByb3RlY3RlZCBieSBJT01NVSBvciBub3QgKG9yIElPTU1VDQo+Pj4+ICsg
ICAgICAgICAgICAgKiBpcyBkaXNhYmxlZCkuDQo+Pj4+ICsgICAgICAgICAgICAgKi8NCj4+Pj4g
KyAgICAgICAgICAgIHJldDEgPSBzY2lfZG9fZG9tY3RsKG9wLCBkLCB1X2RvbWN0bCk7DQo+Pj4+
ICsgICAgICAgICAgICBpZiAoIHJldDEgIT0gLUVPUE5PVFNVUFAgKQ0KPj4+PiArICAgICAgICAg
ICAgICAgIHJldCA9IHJldDE7DQo+Pj4+ICsgICAgICAgIH0NCj4+Pj4gICAgICAgICAgICBicmVh
azsNCj4+Pj4gICAgDQo+Pj4+ICAgICAgICBjYXNlIFhFTl9ET01DVExfZ2V0X3BhZ2luZ19tZW1w
b29sX3NpemU6DQo+Pj4+IGRpZmYgLS1naXQgYS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9kZXZp
Y2VfdHJlZS5jIGIveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvZGV2aWNlX3RyZWUuYw0KPj4+PiBp
bmRleCAwNzVmYjI1YTM3Li4yNjI0NzY3ZTUxIDEwMDY0NA0KPj4+PiAtLS0gYS94ZW4vZHJpdmVy
cy9wYXNzdGhyb3VnaC9kZXZpY2VfdHJlZS5jDQo+Pj4+ICsrKyBiL3hlbi9kcml2ZXJzL3Bhc3N0
aHJvdWdoL2RldmljZV90cmVlLmMNCj4+Pj4gQEAgLTMxOCw2ICszMTgsMTIgQEAgaW50IGlvbW11
X2RvX2R0X2RvbWN0bChzdHJ1Y3QgeGVuX2RvbWN0bCAqZG9tY3RsLCBzdHJ1Y3QgZG9tYWluICpk
LA0KPj4+PiAgICAgICAgICAgICAgICBicmVhazsNCj4+Pj4gICAgICAgICAgICB9DQo+Pj4+ICAg
IA0KPj4+PiArICAgICAgICBpZiAoICFkdF9kZXZpY2VfaXNfcHJvdGVjdGVkKGRldikgKQ0KPj4+
PiArICAgICAgICB7DQo+Pj4+ICsgICAgICAgICAgICByZXQgPSAwOw0KPj4+PiArICAgICAgICAg
ICAgYnJlYWs7DQo+Pj4+ICsgICAgICAgIH0NCj4+PiBJIGFtIGNvbmNlcm5lZCBhYm91dCB0aGlz
OiBwcmV2aW91c2x5IHdlIHdvdWxkIGNhbGwNCj4+PiBpb21tdV9hc3NpZ25fZHRfZGV2aWNlIGFu
ZCB0aGUgc2FtZSBjaGVjayBhdCB0aGUgYmVnaW5uaW5nIG9mDQo+Pj4gaW9tbXVfYXNzaWduX2R0
X2RldmljZSB3b3VsZCByZXR1cm4gLUVJTlZBTC4gTm93IGl0IGlzIGEgc3VjY2Vzcy4NCj4+Pg0K
Pj4+IEkgYW0gbm90IHN1cmUgdGhpcyBpcyBhcHByb3ByaWF0ZS4gSSB3b25kZXIgaWYgaW5zdGVh
ZCB3ZSBzaG91bGQ6DQo+Pj4NCj4+PiAtIHJlbW92ZSB0aGlzIGNodW5rIGZyb20gdGhlIHBhdGNo
DQo+Pj4gLSBjaGFuZ2UgdGhlIHJldHVybiBlcnJvciBmb3IgIWR0X2RldmljZV9pc19wcm90ZWN0
ZWQgYXQgdGhlIHRvcCBvZg0KPj4+ICAgICBpb21tdV9hc3NpZ25fZHRfZGV2aWNlIGZyb20gLUVJ
TlZBTCB0byAtRU9QTk9UU1VQUA0KPj4+IC0gdGhpcyB3b3VsZCBmYWxsIGludG8gdGhlIHNhbWUg
cmV0ICE9IC1FT1BOT1RTVVBQIGNoZWNrIGFmdGVyDQo+Pj4gICAgIGlvbW11X2RvX2RvbWN0bA0K
Pj4gVGhhdCdzIGEgZ29vZCBwb2ludC4gSSB0aGluayB3ZSBzaG91bGQgZG8gdGhlIHNhbWUgZm9y
DQo+Pg0KPj4gICA+IGlmICggIWlzX2lvbW11X2VuYWJsZWQoZCkgKQ0KPj4NCj4+ICAgPsKgIHJl
dHVybiAtRUlOVkFMOw0KPj4NCj4+IGJlY2F1c2UgaW4gdGhpcyBjYXNlIHdlIHNob3VsZCBwcm9j
ZXNzIHNjaSBhcyB3ZWxsLiBJIHdpbGwgZG8gdGhlIGNoYW5nZQ0KPj4NCj4+Pj4gICAgICAgICAg
ICByZXQgPSBpb21tdV9hc3NpZ25fZHRfZGV2aWNlKGQsIGRldik7DQo+Pj4+ICAgIA0KPj4+PiAg
ICAgICAgICAgIGlmICggcmV0ICkNCj4+Pj4gLS0gDQo+Pj4+IDIuMzQuMQ0KPj4+ID4=


From xen-devel-bounces@lists.xenproject.org Thu Jun 19 16:15:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 16:15:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020230.1396611 (Exim 4.92)
	(envelope-from )
	id 1uSHvD-0006cl-EV; Thu, 19 Jun 2025 16:15:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020230.1396611; Thu, 19 Jun 2025 16:15:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSHvD-0006ce-BU; Thu, 19 Jun 2025 16:15:27 +0000
Received: by outflank-mailman (input) for mailman id 1020230;
 Thu, 19 Jun 2025 16:15: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 1uSHvC-0006Y7-Dx
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 16:15:26 +0000
Received: from DUZPR83CU001.outbound.protection.outlook.com
 (mail-northeuropeazlp170120005.outbound.protection.outlook.com
 [2a01:111:f403:c200::5])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9b33afbc-4d28-11f0-b894-0df219b8e170;
 Thu, 19 Jun 2025 18:15:24 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by DB8PR03MB6332.eurprd03.prod.outlook.com (2603:10a6:10:13d::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.19; Thu, 19 Jun
 2025 16:15:23 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%4]) with mapi id 15.20.8835.023; Thu, 19 Jun 2025
 16:15: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: 9b33afbc-4d28-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=iUtleWIMJunxzb2gll2lZX+5YembUD1SLaQeCvJ93Zli0lJ4Tfh2K6Oi7sXKoI6zhZjwPRx/I6azJjQQeDpTooNfr/POLlaLC6XLu8HCkZH90WVdMKNEsATEJMYeeAYNsKWYbPZsOz95nwbtdRH+U/lXA+7WqhXnFQ6WgeWrlfEyZvFoUchJ5QZxlZngZsIirxtG1C8GxzREsAta03ERPsFsmV99T1WggWyifrYrJCCuPPN7s1TcveIObhrFRpDCtypg5Ve7I5khXKU+zIKuX3OhR+1lf+VtQQHCCSR3uddKjpixpW3Xbf7ugQyKkjVha9LmSu95pFQ3dmRKndMKLQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=kI/Nmo844c8oyPMspD+qZrhIsz5Mb9I6X+9a0KxvvF0=;
 b=mW9GEMgwNWNztiadbwtmWIHa/rAnolDf4lz6JnUD0jgauQgDvElekGMg99EBYQojv+zV9OBbVGjVIbOKLtPlBL4d7lnuleUJaCMmTIXBo6zsyod4S10Owz5h3RzuN7CoRLo6dl+TmHjlxNzbFFtrfbL2bbNkAfQCxcoLA16KpwN/15EZeb/KlF5yNsy681STnICeIuubTRUOFLDByNIp8fJ0h98NnxP3EWnKQvXWFWdoUPRCHcM879Cx1tDAV4Pm7LKEBTL/pN5+axpAX5AHDm8L7UxkG73iy3GbK3TtSPeQEHzcdj9qYenUy4FqH1nutOf0NVG/mFqoh56YlMpBFw==
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=kI/Nmo844c8oyPMspD+qZrhIsz5Mb9I6X+9a0KxvvF0=;
 b=V68j+A65RORFteYf3olbkXZQIBJM2y7jUVVeBftgY7FGoRnPtuxb7LQBu88C8b+A5IRelczMGe7fTEl66UYFcEKZtFDco5eJ8abJav2JvVqm7S6L7ILLby0hEWTqkiYdRfnO9YwMDVH5mPOqHk5944OAeZ+4O4kxYEsUjt2RhGgRVYqPYSg4A4tTUKwWBMaU/US0QBNAT3K70ii1E+Jgi3VC7e/TJzjZZC0Hy4r3SlwtKDYBh0oWeRepDuF5eBadX1xBH5LTXhkOkEzsbwsWeKCBiSrH3fiRo1fEn4QjPiAxIET6Faot5T6fXwUTgbwCqP/0fsTb4zEZBQWgsW3wbQ==
From: Oleksii Moisieiev 
To: Julien Grall , Stefano Stabellini
	, Grygorii Strashko 
CC: Bertrand Marquis ,
	"xen-devel@lists.xenproject.org" , Andrew
 Cooper , Anthony PERARD
	, Jan Beulich , Juergen Gross
	, Michal Orzel ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Volodymyr
 Babchuk 
Subject: Re: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC
 multi-agent driver
Thread-Topic: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC
 multi-agent driver
Thread-Index:
 AQHbyNXPHUV4T01ZEEC9Uxm0LaLKHbPgqpIAgA7gjoCAEAkWgIAInBwAgACBoICAAicZAA==
Date: Thu, 19 Jun 2025 16:15:23 +0000
Message-ID: <90d57a47-56e6-4ddb-83fd-c5b5ee612d21@epam.com>
References: 
 <318044ae12f13b6b297b3f5fda577a1a6cd143da.1747669845.git.oleksii_moisieiev@epam.com>
 
 <04B1F737-5E6B-47C0-B2B9-74288C68E68A@arm.com>
 <50ff5d2b-bd17-4833-b497-0dda6f75964a@epam.com>
 
 <538e4b45-74e7-4992-a9e2-7678756f7612@xen.org>
In-Reply-To: <538e4b45-74e7-4992-a9e2-7678756f7612@xen.org>
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: PAVPR03MB8946:EE_|DB8PR03MB6332:EE_
x-ms-office365-filtering-correlation-id: 58169c75-ae35-41f3-4ef3-08ddaf4c7e73
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|376014|366016|7416014|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?bXVocGZxei9YWmoxOTR4WTl4b0hUMWt5eTZCaW56VUU3RmN6bENsUjB3VGRW?=
 =?utf-8?B?VlpYUUxUTWFWWncxRm1OYVk5bUZiMitENHZrMi9nN295azhWNDVnN2NtODNR?=
 =?utf-8?B?RHVTS1I3OWZDWHR5VThRYms5bnZTby8ySHU1bENRZmRRVDI1Mmc2RnRLYU13?=
 =?utf-8?B?V1paQllWNXdSOEVWbzdRaHdFenJFUlNKajUvWWpWWDV0SkJwWWRlQldIZUxt?=
 =?utf-8?B?WmZjQkszdlc5anA4dlV1bFJGRGt3Y1B0TUhSYlB2SzZpSTFGTEo3bWtnVkdu?=
 =?utf-8?B?aUFrTm0rTFh2Tkp4V2g1b2M2Sy9rTHNkcnc2ejc1NkFBaWV0bGMyTW11R056?=
 =?utf-8?B?NjZ3Smx2Vkw4KzZDUHJvYlQrRFB2YmJuWFprRzdoUVFTZGQwaDZaYjZST3I3?=
 =?utf-8?B?YVYveXRCbUdaVnJ2TEFwUW1EaExJbDhxenNVdk5Td2t2QU9zSllhNFNXbndP?=
 =?utf-8?B?S0pqTWcyT1FQakQvRnJsdHRiYXc2Zm5ORzJ2L0JlZkRIWE96bEFya1BlL0w3?=
 =?utf-8?B?Yi9HZDRSWVBBcitneUFTV3NCOEFPOUl4Mng4bUNqNVFmblFVRklJTlpQUHdD?=
 =?utf-8?B?RGFERXpzNGlaNHRNWDN4R2tXNjhUeUNHVHVNV1poWjRwcmFPTitOTmhSOSsz?=
 =?utf-8?B?QUFFNlJwbnJwZEE3SEFBZ3VIb2lReDNYYWVPQmRrVklsWUtFQnMvb29zSHNK?=
 =?utf-8?B?dHVhTTk5TlJwbmdTK0hGWHRZeldMVmZ5NWZ1eUZLK0JJMHZXOFNUNTZDY0Uw?=
 =?utf-8?B?OWw5eXkzTlVsMGRHUU42ZHVaZEVkMGhIRUthWm1NaTJJRzlkYmlZRUtiRGlV?=
 =?utf-8?B?K0k1dUpIb1hnRUdJdENPazB6dWFwNUo4R2R6YjNhWGZFa1FTN0laZjBwTkxE?=
 =?utf-8?B?RXdlVmJBdEhsYkpFK01sTW1xUU92RDJrb1hNYmhtd0YrRHhndm5BSzRSbGow?=
 =?utf-8?B?VmgvQjdlTWs0Uk4wSGVHOHpLNVNEc05IdWoycVNQNjQ1ZHg3R2tmKzY0L0sz?=
 =?utf-8?B?NWQzVFRxYWNoZG1OR09hZDgydjVEUlV0OU14b1paQlY4RXM0c3RoejNPS242?=
 =?utf-8?B?dEpCY0NaNW95STJJZHFoRkhZdlo4QThLcTAwMXhWWXRBODZaZENGSk9leHVC?=
 =?utf-8?B?dEREUDV3ZWxqY0NiSHVvbjcwQUNOZGhBZmxHNTIxMFAwVnNtbGF1WklRYjZl?=
 =?utf-8?B?eDdES1JXTi9rWFVHU3lpYU1hbEZmMWZwZEFxUjV6YTVxbEZoZ1dWcHRTNlVx?=
 =?utf-8?B?d09QNDk2dHZBZFBaRk9ja0dockhBK3hUbTZFTUZxUlJwSHlES2M1NlU5TU9I?=
 =?utf-8?B?RnZGNWFZemdxT3BnNzJPVGREQXRXN2drYVdPZHJCWjB3UEhHb1B6K1gyTkZL?=
 =?utf-8?B?VTJzVVBTbVJoQ2ZPUnloQWNET1ozcThZMlYwRXZJK2o0cDYvbk5EWkMwZHRm?=
 =?utf-8?B?bDA0bTBHSXduSjJPbTk2WUVwd3R2bXAxeDVRWk5KRjBTbWVRME93ZEFURlZ6?=
 =?utf-8?B?ak4xOEd4UDRUR3V5bzlScXUzK21BVlowdlRXYmxkelIrWGdtMXVYa3RmWmNY?=
 =?utf-8?B?emhBSFRiTjRNMUJpSDNSWkJldzVxYWRNOEMxUmZUSUo5V1dpL0h6V0taTXg2?=
 =?utf-8?B?MDlDc3ZnaHJGTGpvUktSUHMwaWlvTk9iN1FGVFJ1R2JmTVhjYy9SQ043MlFY?=
 =?utf-8?B?Qkcvd2JpTmNQM2VjbFdqQllDMzhVcW5CWHIwVUI3K0pHamNobGN2Z0p4NnVp?=
 =?utf-8?B?S3dkeEdCVFVzS0pOY3Q5SGZ4aStwZXhzbVNMM2U1KzMwT2kwQklSUVJTVm1q?=
 =?utf-8?B?UzRzSHJlUTVKdXNKcGJrc25GQ2ZCZGRMRDk0NFVGaFA4R2NwNTRSY0UyeTRv?=
 =?utf-8?B?d2lrbmhMM3U1cmhraWNCd0hDRC8yVm5GNTA0ZHVSbjR6bVZiRk1yaEoycGVN?=
 =?utf-8?B?MzVYL2RCMWdJRmlyS0ZlRHRibk13YTNkUFVGc0l0MEgveldDQ0dzaS9JSnhC?=
 =?utf-8?Q?zbG/jh0jNTFcn1cCFeqOMBG/CyfUWQ=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7416014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?R2hPVksydk4yTVBZazBJdG1ocGNOSjlpMjM2UDQ2SmRNVk9PTGhodTJLZjYw?=
 =?utf-8?B?cUpmUGM0SW1CQ0lqMzhsbVducXluTFhLbWc5aGxLRWwybXJnMTc3bUI4NkxN?=
 =?utf-8?B?SFNhdW9Db2c4OE5JNVNxL0REN2IxdVJGRXEwaEluRXF1NTdMVk43ZnBCellC?=
 =?utf-8?B?NzkvTGx4d3oyTTBoVi9CelRPRUZGbHNoSExWNSszQWl1N09UbU81M2RoK1hu?=
 =?utf-8?B?R1MxOHN0dVFETXBKb0xKaTlKK0VsTEZnM2d3amljeEN0RnJpVDVTVmFpQ2tT?=
 =?utf-8?B?WUUwb2M5WVpMWUsyRFA2TE5Ma1dKZ09Pd0xyRU1WWlJjdmQ1RWdmdVNPTThi?=
 =?utf-8?B?ekNmYTVha1Yraldxd0xxdG1YbyswTjE2TEw4clU0N0x0cEhTU1RJRUh4WUdk?=
 =?utf-8?B?TzhZRTk5OWJISlU5NHZYNkYyNDUwNHpBUUZCK0tGYmNaejUxNi9sWDNnQXBG?=
 =?utf-8?B?amhQR3E4cWxxV01UM0ZMUkpWZWJQb0c3TXNpRXI0cU9SVDhPaVVnN0FUWWJX?=
 =?utf-8?B?TXJrUE9US1A0WmpkZDFQa1FvZ3hvT0pwTVR6S3NxRWY2ZDAvS3NoemJlL0Jp?=
 =?utf-8?B?YVIweTQwTXJTZWVUVk1qMEFRTy9KSTRDWGdVbzhBcEpTYzFuQ0pNN2ZEUnZK?=
 =?utf-8?B?MkgzeU9pRloyTHUrR3MwNWk2UGYrVXhicDhjSDJnYkhlWDJ5dWxsektISTBq?=
 =?utf-8?B?ZExiT21NTVltKy9vZnA2SlI1aXpqbGJMT2lBNXBSQ3U0UWR3VFJ1czBqd1Yw?=
 =?utf-8?B?UVovakVIcEtHY29tUTlSc01WN09rM3dIVExVdDJwQXp4WGlUcUVBcmxmdHVy?=
 =?utf-8?B?RDlhY0pUQlk1bm5BUTQwQUFIbE10clZqNGdHSnE0MG9OK0lxRTZwN0FiUHRn?=
 =?utf-8?B?L3hRR1pybm1tLzNXR2J6Q0h3MVU2UjNvejVlWUUydHJYZkJKdVkzYkZTM1Fj?=
 =?utf-8?B?ZlhlbUN4T0FsdUtob2JTcUdFZVhCZzZMUm5LUTFxZTVqWTd4d1NIdzBWMU5X?=
 =?utf-8?B?djBDRUxZMzBkYWVZZTNBR1NoeUZveVpyUCt1NDl4RVJYRFB3Q0hrdlUyQnFJ?=
 =?utf-8?B?bW53TDkrTjN1QXEwdnJFRDFYaGRTdXpmWWMvcXhZNzBpTE85RjB5QTNsVlEw?=
 =?utf-8?B?VkZJZjBybnorWk5VQTJ6elBiLzYydkh5YVZCNXVwcFBmem0yaUxBOUY2a1l1?=
 =?utf-8?B?aURrbXJleEFqMnpOUnRyVnZCZzVGelhHdVZ4OUNNWGM1NFU3RmRkTHZFMWJQ?=
 =?utf-8?B?Z2phbndmbDJxUnhlRmJzaGozODl4eXluZzRETTlpeVRVZEpzcHcxUFh2UjFt?=
 =?utf-8?B?MmQ5bzVCbGhzSUU0RHpKNXRnWXNCOWRJMEhVNVpvckE4TFllZCtqVC85Njk1?=
 =?utf-8?B?ajNjQ0ZEaG5UOW1KVHVpNmdnZUlRTWVTVGt1SWhlS0xEZ3J1OG1RYWxORG96?=
 =?utf-8?B?UXduVzJMY3RaYXFyZDBnUzUyZlRKbTZvcDYweTMzNEVxY0NaVGdnZ2FLVDBI?=
 =?utf-8?B?eFBYMURWYXBxWXVHNmoxQWkyeDREcmZkSjF2akQwNjJBMWU1UEJUZmtIWlV4?=
 =?utf-8?B?NHZYWGl2MXpjRU0vY2UzYkl4S0JTZC9xdkVUTVh0Wk9PKzViU3ZVcVJDYkhv?=
 =?utf-8?B?cGt1UEhCTUlnNkNjRmk3dC9aeHlELzlhNGpuMG9ObkdEdFRZcVBUTU1aZ3ZB?=
 =?utf-8?B?VEEvd0xoM3dTU0h5ekxxU29UeC92MDlVK2JaQVVkWEtaa0lWaWFyZWFmNDNO?=
 =?utf-8?B?eVdJSnpLZ2ZqamJGdlVaamlvOEdEcGlIcDJTSDREbmVLU1hLeXBiNFNyNG9y?=
 =?utf-8?B?RHRLRDQ5Ukhmc045aFR6R1VJNzhFdlVGYThaMHluMlN3Y0MwQi9XUzVlbnlQ?=
 =?utf-8?B?VHg1OFM1VDVHczZTaC9hNVRYSGVSSEJaaTRvVGhDb29rU2g1MTE2VnFzOXZa?=
 =?utf-8?B?MmllWktpVXJJRjdzaW9HV0hQTjhOUEU0RGlsS1pHWjRldFFwT01YOGhMRU5r?=
 =?utf-8?B?OU5TNmloVXBiVE5xY0QvNjhOd0U5QXlNM2RVTTcreW5hRGl0NGRGOUNsYmxy?=
 =?utf-8?B?QUdOVCtneW9hd01WeVNTYnVrUUNzazROOHNaZ1M3SGJIVGI4aHJ1cGNIMFAr?=
 =?utf-8?B?SXhOS1dVVzlDTU1yQTk2d0xjWnZYM1RCQ2RZcHk5WldFcFd0c0lLYVdYRmpw?=
 =?utf-8?B?TGc9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <230546A7EC04AC4ABF0A42DAA97E15B9@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: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 58169c75-ae35-41f3-4ef3-08ddaf4c7e73
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2025 16:15:23.0214
 (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: 6XAYXgs+G1BI35hz904jcuSY6v0yikuZRvWtD6zz1S5d4HfUTPD3cF8yvVlNb7p3uqkkVXbieLqeyc9b6gjx5pK/QXzK/zZ9DfYVtf7jTzw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR03MB6332

DQpPbiAxOC8wNi8yMDI1IDEwOjIyLCBKdWxpZW4gR3JhbGwgd3JvdGU6DQo+IEhpLA0KPg0KPiBP
biAxOC8wNi8yMDI1IDAwOjM4LCBTdGVmYW5vIFN0YWJlbGxpbmkgd3JvdGU6DQo+PiBPbiBUaHUs
IDEyIEp1biAyMDI1LCBHcnlnb3JpaSBTdHJhc2hrbyB3cm90ZToNCj4+PiBPbiAwMi4wNi4yNSAx
MDoxNywgQmVydHJhbmQgTWFycXVpcyB3cm90ZToNCj4+Pj4+IE9uIHRoZSBvdGhlciBoYW5kLCBp
ZiB3ZSBhbHNvIHdhbnQgdG8gaGFuZGxlIHRoZSBjYXNlIHdoZXJlIHRoZSBTQ01JDQo+Pj4+PiBz
ZXJ2ZXIgY291bGQgYmUgb24gYSBzZXBhcmF0ZSBjby1wcm9jZXNzb3IsIHRoZW4gd2hhdCB0aGlz
IGNvZGUgaXMgDQo+Pj4+PiBkb2luZw0KPj4+Pj4gaXMgbm90IHN1ZmZpY2llbnQgYmVjYXVzZSB3
ZSBhbHNvIG5lZWQgYSBkY2FjaGUgZmx1c2gsIGluIGFkZGl0aW9uIHRvDQo+Pj4+PiB0aGUgRFNC
Lg0KPj4+Pj4NCj4+Pj4+IEJlcnRyYW5kLCBjYW4geW91IGRvdWJsZS1jaGVjaz8NCj4+Pj4NCj4+
Pj4gSWYgd2Ugd2FudCB0byBoYW5kbGUgYSBjYXNlIHdoZXJlIHRoZSBtZW1vcnkgaXMgYWNjZXNz
aWJsZSB0byBhIA0KPj4+PiBjb3Byb2Nlc3Nvcg0KPj4+PiBidXQgdGhlcmUgaXMgbm8gY2FjaGUg
Y29oZXJlbmN5LCB3ZSBuZWVkIHRvIGZsdXNoIHRoZSBkY2FjaGUgDQo+Pj4+IGRlZmluaXRlbHku
DQo+Pj4+DQo+Pj4+IFNlZWluZyB0aGUgYW1vdW50IG9mIGRhdGEgaGVyZSwgSSBkbyBhZ3JlZSB3
aXRoIFN0ZWZhbm8gdGhhdCBpdCANCj4+Pj4gd291bGQgYmUgYQ0KPj4+PiBnb29kDQo+Pj4+IGlk
ZWEgdG8gbWFrZSB0aGUgcHJvdmlzaW9uIHRvIGZsdXNoIHRoZSBkYXRhIGNhY2hlIGluIGFsbCBj
YXNlcy4gDQo+Pj4+IEV2ZW4gaWYgdGhlDQo+Pj4+IGRhdGENCj4+Pj4gaXMgYWNjZXNzZWQgYnkg
YSBzZWN1cmUgcGFydGl0aW9uIG9yIHRoZSBmaXJtd2FyZSBjb2hlcmVudGx5LCANCj4+Pj4gZmx1
c2hpbmcgaW4NCj4+Pj4gYWxsIGNhc2VzDQo+Pj4+IHdvdWxkIGhhdmUgdmVyeSBsaW1pdGVkIHBl
cmZvcm1hbmNlIGltcGFjdCBoZXJlLg0KPj4+Pg0KPj4+PiBUaGVyZSBpcyB0aGUgb3RoZXIgc29s
dXRpb24gdG8gaGF2ZSBzb21lIGtpbmQgb2YgcGFyYW1ldGVyIHRvIHNheSANCj4+Pj4gaWYgdGhl
DQo+Pj4+IGFjY2Vzc29yDQo+Pj4+IGhhcyBjb2hlcmVudCBjYWNoZSBhY2Nlc3MgYnV0IEkgZG8g
bm90IHRoaW5rIHRoZSBwZXJmb3JtYW5jZSBpbXBhY3QgDQo+Pj4+IGhlcmUNCj4+Pj4gd291bGQN
Cj4+Pj4ganVzdGlmeSBzdWNoIGEgY29tcGxleGl0eS4NCj4+Pj4NCj4+PiBUaGUgU0NNSSBzaG1l
bSBleHBlY3RlZCB0byBiZSBtYXBwZWQgYXMgTVRfTk9OX0NBQ0hFQUJMRSBpbiBhbGwgY2FzZXMu
DQo+DQo+IEkgY2FuJ3QgZmluZCBNVF9OT05fQ0FDSEVBQkxFIGFueXdoZXJlIGluIFhlbiBvciBM
aW51eC4gTXkgDQo+IGludGVycHJldGF0aW9uIGlzIHRoYXQgdGhlIG1lbW9yeSBhdHRyaWJ1dGUg
d291bGQgYmUgbm9ybWFsIG1lbW9yeSBub24gDQo+IGNhY2hlYWJsZS4gSG93ZXZlciwgdGhpcyBk
b2Vzbid0IGFkZCB1cCB3aXRoIC4uLg0KPg0KU29ycnkgZm9yIHRoZSBjb25mdXNpb24uIFRoaXMg
ZGVmaW5lIHdhcyB0YWtlbiBmcm9tIFRGLUEgYW5kIGl0IGlzIHRoZSANCnNhbWUgYXMgWGVuIE1U
X05PUk1BTF9OQy4NCg0KVGhlIG1haW4gaWRlYSB3YXMgdG8gbWVudGlvbiB0aGF0IG1lbW9yeSBp
cyBub25fY2FjaGFibGUuDQoNCj4+PiBUaGUgTGludXggZG9lcyBkZXZtX2lvcmVtYXAoKSAtPiBp
b3JlbWFwKCkgLT4NCj4+PiAoQVJNNjQpwqAgX19pb3JlbWFwKChhZGRyKSwgKHNpemUpLCBfX3Bn
cHJvdChQUk9UX0RFVklDRV9uR25SRSkpDQo+DQo+IC4uLiB0aGlzIGxpbmUuIFRoaXMgaXMgZGV2
aWNlIG5HblJFIHdoaWNoIGlzIGEgbG90IG1vcmUgcmVzdHJpY3RpdmUgDQo+IChmb3IgaW5zdGFu
Y2UgaXQgZG9lc24ndCBhbGxvdyB1bmFsaWduZWQgYWNjZXNzKS4NCj4NCkluIFhlbiBzY21pIG1l
bW9yeSBpcyBtYXBwZWQgdXNpbmcgaW9yZW1hcF9ub2NhY2hlIHdoaWNoIGlzIG1hcHBlZCBhcyAN
Ck1UX0RFVklDRV9uR25SRSAoc2FtZSBhcyBsaW51eCkuDQoNCkluIFRGLUEgU0NNSSBzaGFyZWQg
bWVtb3J5IGlzIG1hcHBlZCBhcyBNVF9ERVZJQ0UgKHdoaWNoIGlzIA0KbkduUkU6wqBNQUlSX0RF
Vl9uR25SRSkuDQoNCkFnYWluLCBzb3JyeSBmb3IgdGhlIGNvbmZ1c2lvbi4NCg0KPj4+DQo+Pj4g
VGhlcmUgaXMgYWxzbyBub3RlIGluIGRvY3M6DQo+Pj4gIistIHNobWVtOiBzaGFyZWQgbWVtb3J5
IGZvciBtZXNzYWdlcyB0cmFuc2ZlciwgKipYZW4gcGFnZSBhbGlnbmVkKiogDQo+Pj4gd2l0aA0K
Pj4+IG1hcHBpbmdgYHAybV9tbWlvX2RpcmVjdF9uY2BgLiINCj4+Pg0KPj4+IEluIHRoZSBjYXNl
IG9mIFNDUCAtIHRoZSBTQ01JIHNobWVtIGNhbiBiZSBhY3R1YWxseSBiZSBpbiBTUkFNLg0KPj4+
DQo+Pj4gU28sIGFyZSB5b3Ugc3VyZSBjYWNoZSBtYW5pcHVsYXRpb25zIGFyZSByZXF1aXJlZCBo
ZXJlPw0KPj4NCj4+IE5vLCBpZiB0aGUgbWVtb3J5IGlzIG1hcHBlZCBhcyB1bmNhY2hlYWJsZSBl
dmVyeXdoZXJlIHRoZW4gdGhlIGNhY2hlDQo+PiBtYW5pcHVsYXRpb25zIGFyZSBub3QgbmVlZGVk
LiBIb3dldmVyLCB3ZSBwcm9iYWJseSBzdGlsbCBuZWVkIGEgZHNiLg0KPj4NCj4+IEkgdW5kZXJz
dGFuZCBub3cgd2h5IHRoZXkgZGVjaWRlZCB0byB1c2UgX19tZW1jcHlfZnJvbWlvIGluIExpbnV4
OiBpdCBpcw0KPj4gbm90IE1NSU8gYnV0IHRoZXkgbmVlZGVkIGEgbWVtY3B5IGZvbGxvd2VkIGJ5
IERTQiwgc28gdGhleSBkZWNpZGVkIHRvDQo+PiByZXVzZSB0aGUgZXhpc3RpbmcgTU1JTyBmdW5j
dGlvbnMgYWx0aG91Z2ggdGhlIGJ1ZmZlciBpcyBub3QgTU1JTy4NCj4NCj4gRnJvbSBteSB1bmRl
cnN0YW5kaW5nLCBtZW1jcHlfZnJvbWlvKCkgaXMgbm90IGp1c3QgYSBtZW1wY3koKSArIGRzYi4g
DQo+IEl0IGFsc28gZ3VhcmFudGVlcyB0aGUgYWNjZXNzIHdpbGwgYmUgYWxpZ25lZCAodGhpcyBp
cyBub3QgZ3VhcmFudGVlIA0KPiBieSBvdXIgbWVtY3B5KCkpLg0KPg0KIEZyb20gbXkgdW5kZXJz
dGFuZGluZyBMaW51eCB1c2luZyBtZW1jcHlfZnJvbWlvKCkgYmVjYXVzZSBtZW1jcHkgDQpmdW5j
dGlvbiBpcyBoaWdobHkNCg0Kb3B0aW1pemVkIGluIGxpbnV4IGFuZCB3aWxsIHByb2R1Y2UgZXhj
ZXB0aW9uLGFuZCBsb29raW5nIGludG8gdGhlIA0KbWVtY3B5IGltcGxlbWVudGF0aW9uDQoNCmlu
IFhlbiAoeGVuL2FyY2gvYXJtL2FybTY0L2xpYi9tZW1jcHkuUykgSSdtIG5vdCBzdXJlIGlmIGl0
IGNhbiBiZSB1c2VkIA0KaW5zdGVhZCBvZiBtZW1jcHlfZnJvbWlvLiBDb3VsZCB5b3UgcGxlYXNl
IGFkdmlzZSBob3cgdG8gcHJvY2VlZD8NCg0KDQo+IE5vdyB0aGUgcXVlc3Rpb24gaXMgd2h5IGRv
ZXMgTGludXggbWFwIHRoZSByZWdpb24gRGV2aWNlIG5HblJFIGJ1dCB3ZSANCj4gYXJlIG1hcHBp
bmcgbm9uLWNhY2hlYWJsZT8NCj4NCj4gQ2hlZXJzLA0KPg0KQWdhaW4gc29ycnkgZm9yIHRoZSBj
b25mdXNpb24sIHdlJ3JlIG1hcHBpbmcgYXMgTVRfREVWSUNFX25HblJFIGluIFhlbiANCihwbGVh
c2Ugc2VlIGFib3ZlKS4=


From xen-devel-bounces@lists.xenproject.org Thu Jun 19 16:15:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 16:15:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020234.1396621 (Exim 4.92)
	(envelope-from )
	id 1uSHvN-00077r-M9; Thu, 19 Jun 2025 16:15:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020234.1396621; Thu, 19 Jun 2025 16:15: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 1uSHvN-00077i-IL; Thu, 19 Jun 2025 16:15:37 +0000
Received: by outflank-mailman (input) for mailman id 1020234;
 Thu, 19 Jun 2025 16:15: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 1uSHvL-0005oY-RS
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 16:15:36 +0000
Received: from AS8PR04CU009.outbound.protection.outlook.com
 (mail-westeuropeazlp170110003.outbound.protection.outlook.com
 [2a01:111:f403:c201::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a14cdaa4-4d28-11f0-a30d-13f23c93f187;
 Thu, 19 Jun 2025 18:15:35 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by DB8PR03MB6332.eurprd03.prod.outlook.com (2603:10a6:10:13d::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.19; Thu, 19 Jun
 2025 16:15:32 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%4]) with mapi id 15.20.8835.023; Thu, 19 Jun 2025
 16:15: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: a14cdaa4-4d28-11f0-a30d-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lPFU3R5fXMqaC+fYRE4+FY9Omuvz0slikOv7BmLQ88uTBgU4j7dDzrLkpxipt8nzpzf3u4Q/BeyRKSCOB0nB4SrZ5GnN2UocdrB3rYZbkOIh7q+c1kwzMjLxNHgORkeRqURhOHsbl1JBvVnKG8o8HkEJuNmQra0Mq0xMF+/D3WlJlX46DGOUZeULda//9XNdMY9jl2eOROvOillr5ZxPFTeeP2rRjHXIvXgKRrRiM6pi/kn+Ox+wkwpZheI4Q0QrC9++E44K1kaLHWAoppGhn+RjtAMnX5eny+myWih3l2zL/muVjRbLu9su1eep99ixcPA8uQtuenK1cZ46g2NUZQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=M+3kgEizlxDgC2r2aBmdZ7JgxAabh2ad18/Xn+ENOsA=;
 b=KCaLMWg0FJ5YnwcbNi9P6Mxv4EV4/9KbzeIwisu3a0prKw2VWRri4g5eGXhtkQ+QcI9sS56OvwMS8Zr7Ktckz6t4B4CwSffClMWoVS3dBVHPtIEV0Xu1MJ0vuBHootROyMj6wQpGSGwUQLvNMeD3eFnfHR2w1qMP3UHDea23USc/dxQ+NDNkVUrpSIpSUtFAxMbAFjK5YsQRjZVOEIGvo5zo0ZPufmkry4rFGyn2oAbZ8qRurCNvNtMhUzmdrBumlb1eedrLtDjMxk3Ks7lRQCEGwmhiFY+2hWgL9MDurdBHKFo8SvBvs6O9W8X5rx0xjCQhnqCaKamO3+Zv9HbRyw==
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=M+3kgEizlxDgC2r2aBmdZ7JgxAabh2ad18/Xn+ENOsA=;
 b=tLO4bp1IRt+kl2kPo8wFRtbNfyzB7W7t1BOcgTqIdgmhYoipRN1UY25PVg+hZz/9mcz8FfxkpSyTZhMJ6YRroO0kjfpLOEtzgu3ao2yVkeiHZ9jZVfcI9yPaKVeUZJgMe28bY14GGwRtBst1ODSwJAN/1B6nLYIyAIJA3hlE2dmb0iTVvGfvupd95XN0fPVjidJAhksQ/1MOe5NJLGE6MNJ3njRroPJl0jKgXzeTQvv/DTJsYHYjGTvY8zc7l/04eU/j1JCOBAPLYZD6OaPDOzof4z797OShFk/j+S8zVl2REaXtNyKgFpfSyHGrltIWAeKZ88t+bG9xInq6XhdzDA==
From: Oleksii Moisieiev 
To: Stefano Stabellini 
CC: "xen-devel@lists.xenproject.org" , Andrew
 Cooper , Anthony PERARD
	, Bertrand Marquis , Jan
 Beulich , Juergen Gross , Julien Grall
	, Michal Orzel ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Volodymyr
 Babchuk , Grygorii Strashko
	
Subject: Re: [RFC PATCH v4 8/8] docs: armproposa: l to add separate SCMI node
 for Xen agent
Thread-Topic: [RFC PATCH v4 8/8] docs: armproposa: l to add separate SCMI node
 for Xen agent
Thread-Index: AQHb4TVhOpwmaSC7dkC7oLLOKyrbeg==
Date: Thu, 19 Jun 2025 16:15:32 +0000
Message-ID: 
References: 
 <3f7e1e99f5d1018064f3c4825aff16bd487cf558.1747669845.git.oleksii_moisieiev@epam.com>
 
 
 
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: PAVPR03MB8946:EE_|DB8PR03MB6332:EE_
x-ms-office365-filtering-correlation-id: eb978ca7-31a3-4ce4-f9f4-08ddaf4c843b
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|376014|366016|7416014|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?R01qS0lMalB5bU5EWkYwY1dhZUlYeTQ4ZHdCcWFoRkkxcEUvZzN2OTlUQzc1?=
 =?utf-8?B?aHRjTGVYNVphRUZOakVlZVppMUpFYWN3MmZlMlhUVjBKSE1UMnhuZVRCV1Rk?=
 =?utf-8?B?dklkZnFvREZDdFNXcVhJNVJZeFpLQ0RGNDBITUtjM3UrVnNNWEduVzcvRXA2?=
 =?utf-8?B?M2VzVm9mVGpiOWxVSkdaQjZiNnFwd1FzTEVQNFdsVGZ4R015Y0FHdnI3aEJk?=
 =?utf-8?B?UXBjbGloRktiVGRGbU1RbU5VN0MrN3pQandSYi9uL25oNi9oQU5kaXJpRmxv?=
 =?utf-8?B?cTYxRlQxR1F6SFJMdWlmcDlORUFzTmZEU1ExMm1pU21uWk5CNXZTS2U5R3Ev?=
 =?utf-8?B?eDh4eEw1Sk1oOVFsRjNRSFdRSEZCT0RtNzRBZXlWenJ4WTR3ZW1SeUNxdkxh?=
 =?utf-8?B?cEpxMHV3MnI1OHBoSEhrSlJJRmhHbDhZNWtENTVJUHhWeitKUndZVm1ZYXNH?=
 =?utf-8?B?M05iSG9ycTFDa0VaVFI2SEczV3hldDVVQ0d6Q25rQ0xZOXZoTGZzd3RhSVFk?=
 =?utf-8?B?djJYOHhUV2UxR2ZvV3Q2aXd4T2pLS1FzNENlQUx4dlRBQmFQVE1TMFEwSFBu?=
 =?utf-8?B?eEEvdHZnTFl6VVdNc1F0amRJejROTkpkY3VSLzhteTFBaE5YL0N6WEtPTUVr?=
 =?utf-8?B?cnRqMmFLZGVVTGZVK005bU50UXM4Ym1neU5lT0xna3l0djFRVEJLRVV1bUpU?=
 =?utf-8?B?ZDBIcjhxdWc5akFUM1dGV0lvRjBXSE9qSjRSS0RHRXh3VDJUWSs5Z2lTM2p2?=
 =?utf-8?B?emJyRWVHZjZTaGFKRUxtMExUVnZiN0YrbWRzR3VEU1dsSVg4TFZqMllYUk9L?=
 =?utf-8?B?MjBySUo4VEVTYUY4dS83M25Jc0tYT1JtYk1YRkZhWkNXWkdMZGJhOFdWVUdl?=
 =?utf-8?B?SmJ5b1lqOVlPWmNqY21PaUlTYjM1VnVRRU9rdk9NUW5Ga2pqTXRoZW11bFJl?=
 =?utf-8?B?QytUNE9yejE4UUhOU3VGdi9uMDNIK2tieng0bW9xSVlsMllJUUtvMnZGZ0gr?=
 =?utf-8?B?MjNMamlXQisrWmw4and4UnZ3WFFRclJMalNXa3pYOWx5bVd4M3d5Sndjc3pa?=
 =?utf-8?B?MmhyYS9uZi83R3M4ckt0OU1MK2laZGF1akd4cDVseUo4ZFFZNVdHYllQYlow?=
 =?utf-8?B?QjlpVGkrQ1dsMXdsQXVnVlJOWGxYZ3dOc1FyQWFxczNQdndMUmJndzFFeGlo?=
 =?utf-8?B?TlRkamZaTzlDL3NBK21ObDB0M1ByWXVmR0ltSVZyWVlQcGMwQ0lFRHVZai9Y?=
 =?utf-8?B?dFMySzRvYzNQTTN5R3JVb2V6dDdVMFhoK1NYNUxleHFCT1d3SGJFMVJ3QXlk?=
 =?utf-8?B?bHNlNjBjTFYzeU1JT3RJRXlQbWgzS1JzSGY3MDREbFM1bzB4V2VGT0VyenJj?=
 =?utf-8?B?MktlY25nK2d1UmtuUUVLYW9yQ0Q5TjRCSStOMU5yRlFHRXR0UDF6eXNOeU5a?=
 =?utf-8?B?VHVaOE9mZ2Z2VzhLeGEyM1hkNnBUV0wxdHNLVVJaN05BN3oyaHBrbjQrWjlC?=
 =?utf-8?B?VGRtTGtkR2UwYmxPUC9TRk5DcGRIMXY0eitJQ1NzbFh1QmpEWW0zZDJQMitq?=
 =?utf-8?B?WUphaS8ybTJlczh5NUhtU1V4VnJEZmx0aVFiRG5KWExPVkp6aHdHME5pQ2tU?=
 =?utf-8?B?bUh4WitxQU9Ob29CUkZzM3dLSWxLMk13amdLdmx5alNyMzZKMWprN3hNa0NM?=
 =?utf-8?B?eElsTzhYTGNJK0IrVnE3amtxcE9ubm1GNGRlMWNZR2xtendkTm1BbzZoSm45?=
 =?utf-8?B?WlVxM0RMU1crcnBaR25lb05sbU1qZUwyTnFmRVJPOXhvS0pSR1dKYmV1M0hk?=
 =?utf-8?B?bERDamEvcTk2SDRvSEZ1cjV2ak5YMVN0WXBIN2Z4anZRR2dLSWl4SHNmdTJP?=
 =?utf-8?B?bk1RV1dIZWtmRDQydW55VFV3MXRnVmo3VEtNWUZMV3c4dE9LSmJ4QklsT0Z3?=
 =?utf-8?B?eEtWdEdKcmdmMGdCQjZRTm8wTGFrdXVqTHFNT3FhZ3Vmdk5jeDQ5bW1TVnNC?=
 =?utf-8?B?K2FnRXpaYnVBPT0=?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7416014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?clM3bWZ6aGNOL0FsZlVJaU1VRml2dVdzendFUGJKZ0ZzTmhheFJIeUo4Qnpq?=
 =?utf-8?B?TkdiZTBjWjlnbnMrc1Q2K2gzd3d5citieXRDOFZVcGQ2YWdrazhZM25wMjdl?=
 =?utf-8?B?dDZBUmVZaVlIblVxRmZwNXdPSHR4bjFFTkw2ZVRIc3Bsb0ZDQ0FMN2J2TGtr?=
 =?utf-8?B?SnlOeTY5dmU5bzVoZ3dUbG9MeTg4cENnVVNhTmRWUHFOd3ljR2JXeEFiemtE?=
 =?utf-8?B?UTRaSkZ2UllMejhVMUJJdm1Sa0tXc0RLTlljZ3RlT1hxNEZTZjNya0paWVI2?=
 =?utf-8?B?enRFR0ROZ2YyUTJuRURxUlBwV280QjZYY0VmVkFIM2lZdWxxNzRXb0Q5RVE2?=
 =?utf-8?B?OUJKNERCc2U4aDBIOEs3dk56KzlwVHRsRmpJSERabGtTWTdQVzFqZXNTM0lo?=
 =?utf-8?B?UjJZZ2dGMXhLcTRtNFR2Y2VDUW5JaUtXdmpDTnI4REVjdERtZWlkTzQ0bEdt?=
 =?utf-8?B?NmxwRWJCSjVRQlJBK0RVS2FiQlJ0WXozbnM3M2J6dHlYbCtqQ0NQRlZ3SUY2?=
 =?utf-8?B?NWduUWNnWjhlQm16TUM3MzVsVVRjU0ZDMURVZFFDWFBRK05mZ3hqRUxzNk5F?=
 =?utf-8?B?aFhRV1J5U0RQRW82UEl5V2YxOFdnUndxcGU2NkU3bW95ckhVc3d2azRCYWV2?=
 =?utf-8?B?VDRTSnhNRDBibGx6RHRZbVFWMFNoYWJUY2tuSVVHb3pTOHhYbEdIVml6a29w?=
 =?utf-8?B?NzlCN3I2Y2ZVd1VmRUZOZGFwTmFKYmVyVytDMEhQRFI1MnZmQzBUQXU1WDVv?=
 =?utf-8?B?d2VacDkybGdSd0Fia1NQaGZVMEdsTGZQa1pYbDB2MCtnOStFVk9FWDdTUDFQ?=
 =?utf-8?B?MjdYalM1ejBmQXJNUkY0V3NKK0Y1TDBwbVd4MHdMbml5amsvcExKWXVDNHVI?=
 =?utf-8?B?RFFNeEZFeHRuZXJldEhSNnNldjBOa0JxS1pnZHVXcjBLcXg0TldBZXN3SC8y?=
 =?utf-8?B?SFpOY1RSNzhUS1R6OEx5dTMzTnNuRnRwTWMxdW1YS1RvZGtldTNvWWlTbWV1?=
 =?utf-8?B?bmNrRHdGdXUxQ09EVWxzeDBLcmMxMUc5blByTzJ5RDIxUUc1U0dSMGNPeXZo?=
 =?utf-8?B?YVdBUEt2UnpPUkppdnk4WTJyVEFTaE5uY0lUN1dxdzJDRmRGNHFxNjFHSk43?=
 =?utf-8?B?c3FaY0IyZFBSaTVMenJCK0JnUDFVd2Nwb05sYjhlbzhJTWhESng0blduOE1Q?=
 =?utf-8?B?RXJEanl3TFYvdzdiT2lXaWxRQkEvWW15cTdwVFd1YXVPRFN1N0lRb2E1a0Ri?=
 =?utf-8?B?WFRNalpOZ21XNmRYRmt1MVhsTE5iaElWdGl5UDc2bC8rWFJnK2JBVXlaaVYx?=
 =?utf-8?B?bVc4TG5RUjVRSVVvV0RBOUF0eVVvaE1UeEQvQlZwZEhIdm50KzU1VUllRjZv?=
 =?utf-8?B?MEh1SFIrajkwWGthZDdtNkVLcHpkc3hVUXdkNjB3RW1Xd28wVkN3ZHhJcy9E?=
 =?utf-8?B?ekFZMTZaaS90VDNtS0UzTDZSU2lPOTh3eUw1TWpLc3FNWUpNZjFwamdyUTlZ?=
 =?utf-8?B?d3l1RjhaZVEvZlZTeHpCS1FEaDgwYURlcFMwRWJCd1NDUW8wbkwzY3ZFVFAw?=
 =?utf-8?B?ZFc5RGxVVDdnWUJzdEFOellDN3NOQzhUTkdiaGNCM0twNG54WkFUUGZkemZQ?=
 =?utf-8?B?LytXbHFmNVpxajRLSDlaL0FDd1BuRkJuTk1LczBVZ3RYZWNKK1lmM1l5RUh1?=
 =?utf-8?B?TWpTSjJtQmJpUDV4WTNiRHkrenpzUTI2d1dPNkdUVm9PMXRwTHUwaVVSSXIw?=
 =?utf-8?B?Y0hZSGJaZFBUdHJ6aG1JRXlPYk42M1d1UHFvaWQyS1lzNUtIK1ZrbHRXUU1N?=
 =?utf-8?B?Z3FZaXliYXpsTU9ONVQwcDNHL2JhQnVhWFFXTStjdUxhWkRmQjUydnBkWUdW?=
 =?utf-8?B?ZkNEY0IvNDZ2YXU1UkNtVDJUR3FOUUFGb2lzeHNEeWt3SkcwR2pqOXhKQzR6?=
 =?utf-8?B?TGRaTFc2SUpWWGJQM1BLdlpFY2JIR0draGlDVGVFTE1OYUY4ZUpYTWppS0RG?=
 =?utf-8?B?cHUwa3oyQkNBaWZzaUc4OWQ0Mm9PQitocVN3eThpNDRFSEY4RDB0TWlaS3Yx?=
 =?utf-8?B?R0VvVjNPcWdpOG1ZbUVQY1V2dTA1K1RMazFkdHlkVjdPenBSSW9vWlRDTVNV?=
 =?utf-8?B?bU9QVFNnNHpNWGlEYWcwTWhLMHd4a0JZMklRd2w1anNUOXRwLzRpV3RDMnBY?=
 =?utf-8?B?dlE9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <2A7516175C15704EBDFF83D2A10DFCBD@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: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: eb978ca7-31a3-4ce4-f9f4-08ddaf4c843b
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2025 16:15:32.6981
 (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: nDPRkbTQd+YlRjZe6490jW/Vd5cp5RvgBpdukgWGjQmwiPvpIx4o71Yir/iBnCT+6XqRcdnC/1mD52mTqUp4MxbBhNPLYrQNwcSqUAfn20E=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR03MB6332

DQpPbiAxOC8wNi8yMDI1IDAzOjM1LCBTdGVmYW5vIFN0YWJlbGxpbmkgd3JvdGU6DQo+IE9uIFRo
dSwgMTIgSnVuIDIwMjUsIE9sZWtzaWkgTW9pc2llaWV2IHdyb3RlOg0KPj4gT24gMjMvMDUvMjAy
NSAyMzoxOSwgU3RlZmFubyBTdGFiZWxsaW5pIHdyb3RlOg0KPj4+IE9uIE1vbiwgMTkgTWF5IDIw
MjUsIE9sZWtzaWkgTW9pc2llaWV2IHdyb3RlOg0KPj4+PiBGcm9tOiBHcnlnb3JpaSBTdHJhc2hr
bzxncnlnb3JpaV9zdHJhc2hrb0BlcGFtLmNvbT4NCj4+Pj4NCj4+Pj4gUHJvcG9zYWwgZGVzY3Jp
cHRpb24gdG8gYWRkIHNlcGFyYXRlIFNDTUkgRFQgbm9kZSBmb3IgWGVuIG1hbmFnZW1lbnQgYWdl
bnQNCj4+Pj4gdW5kZXIgImNob3NlbiIgb3IgeGVuLWNvbmZpZyBub2RlLCBsaWtlIEh5cGVybGF1
bmNoICJ4ZW4sY29uZmlnIi4NCj4+PiBJIHRoaW5rIGl0IGlzIE9LIHRvIHBsYWNlIGEgbGFyZ2Vy
ICJ4ZW4sY29uZmlnIiBub2RlIHVuZGVyIC9jaG9zZW4gd2l0aA0KPj4+IG1vcmUgaW5mb3JtYXRp
b24gZm9yIFhlbiB0byBzZXR1cCBTQ01JIG1vcmUgZWFzaWx5Lg0KPj4+DQo+Pj4NCj4+Pj4gVGhp
cyBwcm9wb3NhbCBpbnRyb2R1Y2VzIGEgbmV3IGFwcHJvYWNoIHRvIHRoZSBYZW4gbXVsdGktZG9t
YWluDQo+Pj4+IGNvbmZpZ3VyYXRpb24sIHdoZXJlIGFsbCBYZW4tc3BlY2lmaWMgY29uZmlndXJh
dGlvbiBoYXMgYmVlbiBtb3ZlZA0KPj4+PiB1bmRlciB0aGUgIi9jaG9zZW4iIG5vZGUuIFRoaXMg
cmVxdWlyZXMgbGVzcyBEb20wIGRldmljZSB0cmVlDQo+Pj4+IG1hbmlwdWxhdGlvbiBhbmQgaXNv
bGF0ZXMgWGVuIGNvbmZpZ3VyYXRpb24gZnJvbSBkb21haW4gY29uZmlndXJhdGlvbi4NCj4+Pj4N
Cj4+Pj4gVGhpcyBhcHByb2FjaCBwcm92aWRlcyB0aGUgZm9sbG93aW5nIGRldmljZSB0cmVlIChE
VCkgcGFyYW1ldGVyczoNCj4+Pj4NCj4+Pj4gLSAieGVuLHNjbWktc2Vjb25kYXJ5LWFnZW50cyI6
IEEgWGVuLXNwZWNpZmljIHBhcmFtZXRlciB1bmRlciB0aGUNCj4+Pj4gIi9jaG9zZW4iIG5vZGUs
IHdoaWNoIGRlc2NyaWJlcyB0aGUgU0NNSSBhZ2VudCBjb25maWd1cmF0aW9uIGZvcg0KPj4+PiB0
aGUgZG9tYWlucy4NCj4+Pj4gLSB0aGUgU0NNSSBjb25maWd1cmF0aW9uIGZvciBYZW4gKHByaXZp
bGVnZWQgYWdlbnQpIGFuZCB0aGUgc2hhcmVkDQo+Pj4+IG1lbW9yeSBjb25maWd1cmF0aW9uIGZv
ciBhbGwgYWdlbnRzIGFyZSBwcm92aWRlZCB1bmRlciB0aGUgIi9jaG9zZW4iDQo+Pj4+IG5vZGUg
YW5kIGFyZSB1c2VkIHN0cmljdGx5IGJ5IFhlbiBmb3IgaXRzIGluaXRpYWwgY29uZmlndXJhdGlv
bi4NCj4+Pj4gLSB0aGUgc2NtaV9zaG0gYW5kIFNDTUkgY29uZmlndXJhdGlvbiBmb3IgRG9tMCBh
cmUgcGxhY2VkIGluIHRoZQ0KPj4+PiAiL2Zpcm13YXJlL3NjbWkiIG5vZGUgc28gdGhhdCB0aGV5
IGNhbiBiZSBtb3ZlZCB0byBEb20wIHdpdGhvdXQNCj4+Pj4gYW55IGNoYW5nZXMuDQo+Pj4gSXNu
J3QgdGhlIFNDTUkgY29uZmlndXJhdGlvbiBwcmVzZW50IGluIC9maXJtd2FyZS9zY21pIHJlZmVy
cmluZyB0byB0aGUNCj4+PiBwcml2aWxlZ2VkIGFnZW50PTAgbWVhbnQgdG8gYmUgdXNlZCBieSBY
ZW4/DQo+Pj4NCj4+PiBJIGNlcnRhaW5seSBzZWUgYmVuZWZpdHMgaW4gc2ltcGxpZnlpbmcgdGhl
IGNvbmZpZ3VyYXRpb24gYW5kIGVzcGVjaWFsbHkNCj4+PiByZWR1Y2luZyB0aGUgYW1vdW50IG9m
IGNoYW5nZXMgYSB1c2VyIG1pZ2h0IGhhdmUgdG8gbWFrZSBvbiB0aGUNCj4+PiB1bmRlcmx5aW5n
IGRldmljZSB0cmVlLCBidXQgaWYgdGhlIHVzZXIgbmVlZHMgdG8gY2hhbmdlIC9maXJtd2FyZS9z
Y21pDQo+Pj4gd2l0aCB0aGUgRG9tMCBpbmZvcm1hdGlvbiwgaXQgc2VlbXMgbW9yZSBkYW5nZXJv
dXMgYW5kIGVycm9yIHByb25lIHRoYW4NCj4+PiB0aGUgcHJldmlvdXMgYXBwcm9hY2guDQo+Pj4N
Cj4+IFRoZSBpZGVhIGlzIHRvIG1vdmUgdGhlIHByaXZpbGVnZWQgYWdlbnQ9MCBjb25maWd1cmF0
aW9uIHRvIHRoZSAvY2hvc2VuDQo+PiBub2RlIGFuZA0KPj4NCj4+IGFzc2lnbiBhZ2VudD0xIHRv
IHRoZSBEb20wIG5vZGUgdW5kZXIgL2Zpcm13YXJlL3NjbWkuDQo+Pg0KPj4gQmVuZWZpdHMgb2Yg
VGhpcyBBcHByb2FjaDoNCj4+IC0gTm8gTW9kaWZpY2F0aW9uIG9mIHRoZSBYZW4gRFQgTm9kZSBS
ZXF1aXJlZA0KPj4NCj4+ICAgwqDCoMKgIFRoaXMgZWxpbWluYXRlcyB0aGUgbmVlZCB0byBtb2Rp
ZnkgdGhlIFhlbiBEZXZpY2UgVHJlZSAoRFQpIG5vZGUNCj4+IGJlZm9yZSBjcmVhdGluZyBEb20w
IGluDQo+Pg0KPj4gICDCoMKgwqAgb3JkZXIgdG8gc2V0IHRoZSBjb3JyZWN0IHNoYXJlZCBtZW1v
cnkgKHNobWVtKS4NCj4+DQo+PiAtQ29uc2lzdGVudCBTQ01JIENvbmZpZ3VyYXRpb24gRm9ybWF0
DQo+Pg0KPj4gICDCoCBUaGUgRG9tMCBEVCB3aWxsIGhhdmUgdGhlIHNhbWUgU0NNSSBjb25maWd1
cmF0aW9uIGZvcm1hdCBhcyBvdGhlcg0KPj4gZG9tYWlucywgc2ltcGxpZnlpbmcgdGhlDQo+Pg0K
Pj4gICDCoCBvdmVyYWxsIGNvbmZpZ3VyYXRpb24gcHJvY2Vzcy4NCj4+DQo+PiAtIFVuaWZpZWQg
U0NNSSBDb25maWd1cmF0aW9uIE1ldGhvZA0KPj4NCj4+ICAgwqDCoCBUaGVyZSB3aWxsIG5vIGxv
bmdlciBiZSBhIG5lZWQgdG8gdXNlIGEgZGlmZmVyZW50IGFwcHJvYWNoIGZvciBTQ01JDQo+PiBj
b25maWd1cmF0aW9uIGluIERvbTANCj4+DQo+PiAgIMKgIGNvbXBhcmVkIHRvIG90aGVyIGRvbWFp
bnMuDQo+Pg0KPj4gLSBTZXBhcmF0aW9uIEJldHdlZW4gRG9tMCBhbmQgUHJpdmlsZWdlZCBOb2Rl
DQo+Pg0KPj4gICDCoMKgwqDCoMKgIFRoaXMgcHJvdmlkZXMgYSBjbGVhciBzZXBhcmF0aW9uIGJl
dHdlZW4gdGhlIERvbTAgbm9kZSBhbmQgdGhlDQo+PiBwcml2aWxlZ2VkIG5vZGUuDQo+Pg0KPj4g
ICDCoMKgwqDCoMKgIEZvciBleGFtcGxlOg0KPj4gICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIElm
IERvbTAgb25seSByZXF1aXJlcyB0aGUgY2xvY2sgcHJvdG9jb2wsIGJ1dCB0aGUgWGVuIFNDTUkN
Cj4+IGNvbmZpZ3VyYXRpb24gcmVxdWlyZXMgYWRkaXRpb25hbCBwcm90b2NvbHMsDQo+Pg0KPj4g
ICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHRoaXMgYXBwcm9hY2ggYWxsb3dzIERvbTAgdG8gcmVj
ZWl2ZSBvbmx5IHRoZSBuZWNlc3NhcnkNCj4+IHByb3RvY29sIGNvbmZpZ3VyYXRpb24uDQo+IEkg
ZG9uJ3QgdGhpbmsgdGhpcyBpcyBhIGdvb2QgaWRlYSBiZWNhdXNlIHdlIGVuZCB1cCBjb25mdXNp
bmcgdGhlIGRhdGENCj4gZm9yIFhlbiBhbmQgdGhlIGRhdGEgZm9yIHRoZSBEb21Vcy9Eb20wIGlu
IHRoZSBob3N0IGRldmljZSB0cmVlLg0KPg0KPiBJIHRoaW5rIHdlIHNob3VsZCBmb2xsb3cgdGhl
c2UgdmVyeSBzaW1wbGUgZ3VpZGVsaW5lczoNCj4NCj4gLSBUaGUgaG9zdCBEVEIgKHRoZSBEVEIg
Z2l2ZW4gdG8gWGVuIGF0IGJvb3QpIHNob3VsZCBiZSB0aGUgc2FtZSBmb3IgWGVuDQo+ICAgIGFu
ZCBmb3IgTGludXggYmFyZW1ldGFsIChubyBLVk0pLCB3aXRoIHRoZSBleGNlcHRpb24gb2YgdGhl
IGRhdGEgdW5kZXINCj4gICAgdGhlIC9jaG9zZW4gbm9kZQ0KPg0KPiAtIFdlIGNhbiBwbGFjZSBY
ZW4gc3BlY2lmaWMgY29uZmlndXJhdGlvbnMgdW5kZXIgdGhlIC9jaG9zZW4gbm9kZSBpbiB0aGUN
Cj4gICAgaG9zdCBEVEIsIGJvdGggWGVuIGh5cGVydmlzb3IgY29uZmlndXJhdGlvbiBhbmQgYWxz
byBEb20wL0RvbVUNCj4gICAgY29uZmlndXJhdGlvbnMNCj4NCj4gVGhpcyB3YXksIHRoZSBob3N0
IGluZm9ybWF0aW9uIHJlbWFpbnMgZ2VuZXJpYyBhbmQgdGhlIGNvbmZpZ3VyYXRpb24gZm9yDQo+
IFhlbiB0aGUgZG9tVXMvRG9tMCBpcyBrZXB0IGNsZWFybHkgc2VwYXJhdGUgZnJvbSB0aGUgcmVz
dC4gSSBkb24ndA0KPiB0aGluayB3ZSBjYW4gYnJlYWsgdGhlc2UgdHdvIGFzc3VtcHRpb25zIGJ1
dCB3ZSBoYXZlIG1vcmUgZnJlZWRvbSB3aXRoDQo+IHRoZSByZXN0Lg0KPg0KPiBJZiB3ZSBzdGFy
dCB3aXRoIHRoZXNlIHR3byBzaW1wbGUgYXNzdW1wdGlvbnMsIGhlcmUgYXJlIHRoZQ0KPiBjb25z
ZXF1ZW5jZXM6DQo+DQo+IC0gZGF0YSB1bmRlciAvZmlybXdhcmUvc2NtaSBzaG91bGQgYmUgdGhl
IHNhbWUgZm9yIFhlbiBhbmQgYmFyZW1ldGFsDQo+ICAgIExpbnV4LCBpZGVhbGx5IGl0IHdvdWxk
IGRlc2NyaWJlIFhlbidzIGFnZW50MCBjaGFubmVsIGluIGJvdGggY2FzZXMNCg0KQWNjb3JkaW5n
IHRvIHRoZSBwcm9wb3NhbDoNClRoZSBkYXRhIHVuZGVyIHRoZSBIb3N0IERUIC9maXJtd2FyZS9z
Y21pIG5vZGUgd2lsbCBhbHdheXMgcG9pbnQgdG8gdGhlIA0KZGVmYXVsdCBPU1BNIGFnZW50LCB3
aGljaCB3aWxsIHJlbWFpbg0KDQp0aGUgc2FtZSAoc21jLWlkIGFuZCBzaG1lbSkgZm9yIGJvdGgg
dGhlIEJTUCBjYXNlIChubyBYZW4pIGFuZCB0aGUgWGVuIA0KY2FzZSAoRG9tMCBkb21haW4pLg0K
DQpNZWFud2hpbGUsIHRoZSBYZW4gbWFuYWdlbWVudCBhZ2VudCdzIFNDTUkgbm9kZSBhbmQgY29u
ZmlndXJhdGlvbiBhcmUgDQpleHBlY3RlZCB0byBiZSBwbGFjZWQgdW5kZXIgL2Nob3Nlbi4NCg0K
VGhpcyBhcHByb2FjaCBlbnN1cmVzIHRoYXQgdGhlIEhvc3QgRFQgcmVtYWlucyBhcyB1bmNoYW5n
ZWQgYXMgcG9zc2libGUuDQoNCkN1cnJlbnRseToNCg0KVGhlIEhvc3QgRFQgL2Zpcm13YXJlL3Nj
bWkgbm9kZSByZXF1aXJlcyBtb2RpZmljYXRpb24gdG8gcG9pbnQgdG8gdGhlIA0KWGVuIG1hbmFn
ZW1lbnQgYWdlbnQgYnkgY2hhbmdpbmcNCg0KdGhlIHNtYy1pZCBhbmQgc2htZW0gdmFsdWVzLg0K
DQpBdCBib290IHRpbWUsIGR1cmluZyBEb20wIGNyZWF0aW9uLCB0aGUgU0NNSSBtdWx0aS1hZ2Vu
dCBkcml2ZXIgcmV2ZXJ0cyANCnRoZXNlIGNoYW5nZXMuDQoNCj4gLSBXZSBjYW4gYWRkIGFzIG1h
bnkgbm9kZXMgYXMgd2UgbGlrZSB1bmRlciAvY2hvc2VuLCBpbmNsdWRpbmcgYQ0KPiAgICB4ZW4s
Y29uZmlnIG5vZGUgYW5kIGFsc28gYWRkaXRpb25hbCBub2RlcyBmb3IgdGhlIGRvbWFpbnMgY29u
ZmlnDQo+DQo+IC0gV2UgY2FuIGRlZmluZSB0aGUgbmV3IG5vZGVzIHVuZGVyIC9jaG9zZW4gdG8g
YmUgYXMgc2ltcGxlIGFzIHBvc3NpYmxlDQo+ICAgIGZvciB0aGUgdXNlciB0byBjb25maWd1cmUg
dGhlbSwgd2hpbGUgYWxzbyB0cnlpbmcgdG8gbWluaW1pemUNCj4gICAgY29tcGxleGl0eSBpbiBY
ZW4gaW4gdGVybXMgb2YgRFQgbWFuaXB1bGF0aW9ucw0KPg0KPg0KPg0KPiBJZiB0aGUgWGVuIFND
TUkgY29uZmlndXJhdGlvbiBkYXRhIGNhbm5vdCBiZSB0aGUgc2FtZSBhcyB0aGUgTGludXgNCj4g
YmFyZW1ldGFsIFNDTUkgY29uZmlndXJhdGlvbiAoaS5lLiAvZmlybXdhcmUvc2NtaSBoYXMgdG8g
YmUgZGlmZmVyZW50IGluDQo+IHRoZSB0d28gY2FzZXMpIEkgd291bGQgc3RpbGwgc3VnZ2VzdCB0
byBhdm9pZCBtb2RpZnlpbmcgL2Zpcm13YXJlL3NjbWkNCj4gZm9yIFhlbiBhbmQgaW5zdGVhZCBw
cm92aWRlIHRoZSBYZW4gY29uZmlndXJhdGlvbiB1bmRlciAvY2hvc2VuLiBJdCBpcw0KPiBpbXBv
cnRhbnQgdG8ga2VlcCBldmVyeXRoaW5nIGluIHRoZSBob3N0IERUQiAoZXhjZXB0IC9jaG9zZW4p
IHRoZSBzYW1lDQo+IGJldHdlZW4gTGludXggYmFyZW1ldGFsIGFuZCBYZW4uDQo+DQo+IEhvd2V2
ZXIsIHdlIGNhbiBhZGQgYSBuZXcgbm9kZSBzaW1pbGFyIHRvIC9maXJtd2FyZS9zY21pIHVuZGVy
IC9jaG9zZW4NCj4gc3BlY2lmaWNhbGx5IGZvciBYZW4sIHN1Y2ggYXMgL2Nob3Nlbi94ZW4tY29u
ZmlnL3NjbWkNCj4NCj4gVGhlIERvbTAgY29uZmlndXJhdGlvbiBjYW5ub3QgYmUgZXhwZWN0ZWQg
dG8gYmUgdW5kZXIgL2Zpcm13YXJlL3NjbWkuDQo+IEhvd2V2ZXIsIGl0IGNvdWxkIGFsc28gYmUg
ZGVmaW5lZCB1bmRlciAvY2hvc2VuLg0KDQpOby4gVGhlIGlkZWEgaXMgdG8ga2VlcCBpdCBhbmQg
cHJvdmlkZSB1bmNoYW5nZWQsIGJ1dCB3aXRoIHBvc3NpYmlsaXR5IA0KdG8gImRpc2FibGUgU0NN
SSBmb3IgRG9tMCINCi0gbm93IHdpdGggWGVuIGJvb3RhcmcgcGFyYW1ldGVyLg0KPiBLZWVwIGlu
IG1pbmQgdGhhdCB0aGUgbW9yZSB3ZSBhZGQgdG8gL2Nob3NlbiB0aGUgbW9yZSBkaWZmaWN1bHQg
aXQgd2lsbA0KPiBiZSBmb3IgdGhlIHVzZXIgdG8gY29uZmlndXJlIHRoZSBzeXN0ZW0uIEkgdGhp
bmsgd2Ugc2hvdWxkIHBsYW4gYWhlYWQgdG8NCj4gaGF2ZSBJbWFnZUJ1aWxkZXIgYmUgYWJsZSB0
byBnZW5lcmF0ZSB0aGUgRFQgbm9kZXMgdW5kZXIgL2Nob3NlbiBmb3IgWGVuDQo+IHN0YXJ0aW5n
IGZyb20gdGhlIHNpbXBsZXN0IHBvc3NpYmxlIGNvbmZpZ3VyYXRpb24gZm9ybWF0IHByb3ZpZGVk
IGJ5IHRoZQ0KPiB1c2VyLiBUaGUgbW9yZSBjb21wbGV4IGFuZCByaWNoIGFyZSB0aGUgZGV2aWNl
IHRyZWUgbm9kZXMgdW5kZXIgL2Nob3NlbiwNCj4gdGhlIG1vcmUgaW1wb3J0YW50IGlzIHRoZSBk
b2N1bWVudGF0aW9uIGFuZCBJbWFnZUJ1aWxkZXIgc3VwcG9ydCBmb3IgaXQuDQo+DQo+DQpSZWdh
cmRpbmcgYWxsIHRoZSBvdGhlciBwb2ludHMgeW914oCZdmUgbWVudGlvbmVkIOKAkyB0aGlzIGlz
IGV4YWN0bHkgd2hhdCANCndlIGFyZSB0cnlpbmcgdG8gYWNoaWV2ZQ0KDQp3aXRoIHRoaXMgcHJv
cG9zYWwuDQoNCldlIGFyZSBwcm9wb3NpbmcgdGhlIGZvbGxvd2luZyBjaGFuZ2VzIHRvIHRoZSBh
cHByb2FjaCBzbyB0aGF0IGFsbCANCnJlcXVpcmVtZW50cyBhcmUgbWV0LCBhbmQgdGhlDQoNClhl
biBkZXZpY2UgdHJlZSAoRFQpIHdpbGwgcmVtYWluIHRoZSBzYW1lIGFzIHRoZSBIb3N0IFBsYXRm
b3JtIERUIChCU1AgDQpMaW51eCksIGV4Y2VwdCBmb3IgdGhlIC9jaG9zZW4gbm9kZToNCg0KYGBg
DQoNCiDCoMKgwqAgL3sNCg0KIMKgwqDCoMKgwqDCoMKgIGNob3NlbiB7DQogwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoCAuLi4NCg0KIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgLy8gWGVuIFNDTUkgbWFu
YWdlbWVudCBjaGFubmVsDQogwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBzY21pX3NobV94ZW4gOiBz
cmFtQDQ3ZmYxMDAwIHsNCiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgY29tcGF0aWJs
ZSA9ICJhcm0sc2NtaS1zaG1lbSI7DQogwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHJl
ZyA9IDwweDAgMHg0N2ZmMTAwMCAweDAgMHgxMDAwPjsNCiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
IH07DQoNCiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHNjbWlfeGVuOiBzY21pIHsNCiDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgY29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zbWMiOw0KIMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBhcm0sc21jLWlkID0gPDB4ODIwMDAwMDM+OyA8
LS0tIFhlbiBtYW5lZ2VtZW50IGFnZW50IHNtYy1pZA0KIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoCAjYWRkcmVzcy1jZWxscyA9IDwgMT47DQogwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgICNzaXplLWNlbGxzID0gPCAwPjsNCiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqAgI2FjY2Vzcy1jb250cm9sbGVyLWNlbGxzID0gPCAxPjsNCiDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqAgc2htZW0gPSA8JnNjbWlfc2htX3hlbj47IDwtLS0gWGVuIG1hbmVnZW1lbnQg
YWdlbnQgc2htZW0NCiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIH07DQoNCiDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgIC8vIFNDTUkgbXVsdGktYWdlbnQgY29uZmlndXJhdGlvbg0KIMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqAgc2NtaV9zaG1fMjogc3JhbUA0N2ZmMjAwMCB7DQogwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgY29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zaG1lbSI7DQog
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgcmVnID0gPDB4MCAweDQ3ZmYy
MDAwIDB4MCAweDEwMDA+Ow0KIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfTsNCiDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgIHNjbWlfc2htXzM6IHNyYW1ANDdmZjMwMDAgew0KIMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0K
IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHJlZyA9IDwweDAgMHg0N2Zm
MzAwMCAweDAgMHgxMDAwPjsNCiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIH07DQogwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoCBzY21pX3NobV80OiBzcmFtQDQ3ZmY0MDAwIHsNCiDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBjb21wYXRpYmxlID0gImFybSxzY21pLXNobWVtIjsN
CiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCByZWcgPSA8MHgwIDB4NDdm
ZjQwMDAgMHgwIDB4MTAwMD47DQogwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB9Ow0KDQogwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoCB4ZW4sc2NtaS1zZWNvbmRhcnktYWdlbnRzID0gPA0KIMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgMHg4MjAwMDAwMiAmc2NtaV9z
aG3CoMKgIDENCiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
IDB4ODIwMDAwMDQgJnNjbWlfc2htXzIgMg0KIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqAgMHg4MjAwMDAwNSAmc2NtaV9zaG1fMyAzDQogwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAweDgyMDAwMDA2ICZzY21pX3NobV80
IDQ+Ow0KIMKgwqDCoMKgwqDCoMKgIH07DQoNCiDCoMKgwqDCoMKgwqDCoCAvLyBIb3N0IFNDTUkg
T1NQTSBjaGFubmVsIC0gcHJvdmlkZWQgdG8gdGhlIERvbTAgYXMgaXMgaWYgU0NNSSANCmVuYWJs
ZWQgZm9yIGl0IChzYW1lIGFkZHJlc3MgYXMgSG9zdCBQbGF0Zm9ybSBEVCkNCiDCoMKgwqDCoMKg
wqDCoCBzY21pX3NobTogc3JhbUA0N2ZmMDAwMCB7DQogwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0KIMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoCByZWcgPSA8MHgwIDB4NDdmZjAwMDAgMHgwIDB4MTAwMD47DQogwqDCoMKg
wqDCoMKgwqAgfTsNCg0KIMKgwqDCoMKgwqDCoMKgIGZpcm13YXJlIHsgPC0tIHRoZSBiZWxvdyBj
b25maWd1cmF0aW9uIGlzIHRoZSBzYW1lIGFzIEhvc3QgDQpQbGF0Zm9ybSBEVCBhbmQgd2lsbCBi
ZSBwYXNzZWQgdG8gRG9tMA0KIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgc2NtaTogc2NtaSB7DQog
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc21j
IjsNCiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgYXJtLHNtYy1pZCA9IDwweDgyMDAw
MDAyPjsgPC0tLSBIb3N0IE9TUE0gYWdlbnQgc21jLWlkIA0Kd2hpY2ggaXMgdGhlIHNhbWUgYXMg
aW4gSG9zdCBQbGF0Zm9ybSBEVA0KIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAjYWRk
cmVzcy1jZWxscyA9IDwgMT47DQogwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICNzaXpl
LWNlbGxzID0gPCAwPjsNCiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgc2htZW0gPSA8
JnNjbWlfc2htPjsgPC0tLSBIb3N0IE9TUE0gYWdlbnQgc2htZW0gKHNhbWUgDQphZGRyZXNzIGFz
IEhvc3QgUGxhdGZvcm0gRFQpDQoNCiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgcHJv
dG9jb2xAWHsNCiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfTsNCiDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgIH07DQogwqDCoMKgwqDCoMKgwqAgfTsNCiDCoMKgwqAgfQ0KDQpgYGANCg0K
Pj4+PiBUaGlzIGNvbmZpZ3VyYXRpb24gYWxsb3dzIHRoZSB1c2Ugb2YgWGVuLXNwZWNpZmljIG5v
ZGVzIHRvIHByb3ZpZGUNCj4+Pj4gaW5mb3JtYXRpb24gc3RyaWN0bHkgbmVlZGVkIGJ5IFhlbiB3
aGlsZSB1c2luZyB0aGUgZGVmYXVsdCBTQ01JDQo+Pj4+IGNvbmZpZ3VyYXRpb24gZm9yIERvbTAg
YW5kIG90aGVyIGRvbWFpbnMuIEFzIGEgcmVzdWx0LCBubyBhZGRpdGlvbmFsDQo+Pj4+IGJpbmRp
bmdzIG5lZWQgdG8gYmUgaW50cm9kdWNlZCB0byB0aGUgZGV2aWNlIHRyZWUuDQo+Pj4gVGhpcyBp
cyBub3QgYWN0dWFsbHkgaW1wbGVtZW50ZWQgYnkgdGhpcyBwYXRjaCBzZXJpZXMsIHJpZ2h0Pw0K
Pj4gSXQgaXMgbm90LiBKdXN0IHBvc3RlZCB0aGlzIGRvY3VtZW50IGFzIGEgcHJvcG9zYWwuDQo+
Pj4+IFNpZ25lZC1vZmYtYnk6IEdyeWdvcmlpIFN0cmFzaGtvPGdyeWdvcmlpX3N0cmFzaGtvQGVw
YW0uY29tPg0KPj4+PiBTaWduZWQtb2ZmLWJ5OiBPbGVrc2lpIE1vaXNpZWlldjxvbGVrc2lpX21v
aXNpZWlldkBlcGFtLmNvbT4NCj4+Pj4gLS0tDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+ICAgIC4u
Li9hcm0vZmlybXdhcmUvYXJtLXNjbWktcHJvcG9zYWwucnN0ICAgICAgICB8IDIyNCArKysrKysr
KysrKysrKysrKysNCj4+Pj4gICAgMSBmaWxlIGNoYW5nZWQsIDIyNCBpbnNlcnRpb25zKCspDQo+
Pj4+ICAgIGNyZWF0ZSBtb2RlIDEwMDY0NCBkb2NzL2h5cGVydmlzb3ItZ3VpZGUvYXJtL2Zpcm13
YXJlL2FybS1zY21pLXByb3Bvc2FsLnJzdA0KPj4+Pg0KPj4+PiBkaWZmIC0tZ2l0IGEvZG9jcy9o
eXBlcnZpc29yLWd1aWRlL2FybS9maXJtd2FyZS9hcm0tc2NtaS1wcm9wb3NhbC5yc3QgYi9kb2Nz
L2h5cGVydmlzb3ItZ3VpZGUvYXJtL2Zpcm13YXJlL2FybS1zY21pLXByb3Bvc2FsLnJzdA0KPj4+
PiBuZXcgZmlsZSBtb2RlIDEwMDY0NA0KPj4+PiBpbmRleCAwMDAwMDAwMDAwLi5mY2MyZWQyYjY1
DQo+Pj4+IC0tLSAvZGV2L251bGwNCj4+Pj4gKysrIGIvZG9jcy9oeXBlcnZpc29yLWd1aWRlL2Fy
bS9maXJtd2FyZS9hcm0tc2NtaS1wcm9wb3NhbC5yc3QNCj4+Pj4gQEAgLTAsMCArMSwyMjQgQEAN
Cj4+Pj4gKw0KPj4+PiArUHJvcG9zYWwgZm9yIFNDTUkgbXVsdGktYWdlbnQgZHJpdmVyIGJpbmRp
bmdzDQo+Pj4+ICs9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N
Cj4+Pj4gKw0KPj4+PiArTm93IHRoZSBYZW4gY29uZmlndXJhdGlvbiBmb3IgU0NNSSBtdWx0aS1h
Z2VudCBzdXBwb3J0IGlzIGRvbmUgaW4gYSBiaXQgY29tcGxpY2F0ZWQgd2F5LCBlc3BlY2lhbGx5
DQo+Pj4+ICtmcm9tIFNDTUkgbXVsdGktYWdlbnQgZHJpdmVyIGluaXRpYWxpemF0aW9uIGFuZCBE
b20wIERUIG1hbmlwdWxhdGlvbiBwb2ludCBvZiB2aWV3Lg0KPj4+PiArQWxzbyBpdCBkb2VzIG5v
dCB0YWtlIGludG8gYWNjb3VudCBmdXR1cmUgcmVxdWlyZW1lbnRzIHRvIHN1cHBvcnQgU0NQIFND
TUkgRlcuDQo+Pj4+ICsNCj4+Pj4gK1RvIGVuYWJsZSBTQ01JIG11bHRpLWFnZW50IHVzZXIgbmVl
ZDoNCj4+Pj4gKw0KPj4+PiArKiB0YWtlIGhvc3QgRFQgd2l0aCBiYXNpYyBTQ01JIGVuYWJsZWQN
Cj4+Pj4gKyogYWRkIFNDTUkgc2hhcmVkLW1lbW9yeSBub2RlcyBmb3IgYWxsIGFnZW50cw0KPj4+
PiArKiB1cGRhdGUgU0NNSSBub2RlIHRvIHBvaW50IG9uIFNDTUkgWGVuIG1hbmFnZW1lbnQgY2hh
bm5lbCAoYGBbc21jLWlkLCBzaG1lbV1gYCkNCj4+Pj4gKyogYWRkICJ4ZW4sc2NtaS1zZWNvbmRh
cnktYWdlbnRzIiBwcm9wZXJ0eSB0byB0aGUgIlxjaG9zZW4iIG5vZGUNCj4+Pj4gKw0KPj4+PiAr
Li4gY29kZTo6DQo+Pj4+ICsNCj4+Pj4gKyAgIGNob3NlbiB7DQo+Pj4+ICsgICAgICB4ZW4sc2Nt
aS1zZWNvbmRhcnktYWdlbnRzID0gPA0KPj4+PiArICAgICAgICAgICAgICAgICAgICAxIDB4ODIw
MDAwMDMgJnNjbWlfc2htXzENCj4+Pj4gKyAgICAgICAgICAgICAgICAgICAgMiAweDgyMDAwMDA0
ICZzY21pX3NobV8yDQo+Pj4+ICsgICAgICAgICAgICAgICAgICAgIDMgMHg4MjAwMDAwNSAmc2Nt
aV9zaG1fMw0KPj4+PiArICAgICAgICAgICAgICAgICAgICA0IDB4ODIwMDAwMDYgJnNjbWlfc2ht
XzQ+Ow0KPj4+PiArICAgIH0NCj4+Pj4gKw0KPj4+PiArICAgIC97DQo+Pj4+ICsgICAgICAgICAg
ICAvLyBTQ01JIHNoYXJlZC1tZW1vcnkgbm9kZXMgZm9yIGFsbCBhZ2VudHMNCj4+Pj4gKyAgICAg
ICAgICAgIHNjbWlfc2htXzAgOiBzcmFtQDQ3ZmYwMDAwIHsNCj4+Pj4gKyAgICAgICAgICAgICAg
ICBjb21wYXRpYmxlID0gImFybSxzY21pLXNobWVtIjsNCj4+Pj4gKyAgICAgICAgICAgICAgICBy
ZWcgPSA8MHgwIDB4NDdmZjAwMDAgMHgwIDB4MTAwMD47DQo+Pj4+ICsgICAgICAgICAgICB9Ow0K
Pj4+PiArICAgICAgICAgICAgc2NtaV9zaG1fMTogc3JhbUA0N2ZmMTAwMCB7DQo+Pj4+ICsgICAg
ICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0KPj4+PiArICAg
ICAgICAgICAgICAgICAgICByZWcgPSA8MHgwIDB4NDdmZjEwMDAgMHgwIDB4MTAwMD47DQo+Pj4+
ICsgICAgICAgICAgICB9Ow0KPj4+PiArICAgICAgICAgICAgc2NtaV9zaG1fMjogc3JhbUA0N2Zm
MjAwMCB7DQo+Pj4+ICsgICAgICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWkt
c2htZW0iOw0KPj4+PiArICAgICAgICAgICAgICAgICAgICByZWcgPSA8MHgwIDB4NDdmZjIwMDAg
MHgwIDB4MTAwMD47DQo+Pj4+ICsgICAgICAgICAgICB9Ow0KPj4+PiArICAgICAgICAgICAgc2Nt
aV9zaG1fMzogc3JhbUA0N2ZmMzAwMCB7DQo+Pj4+ICsgICAgICAgICAgICAgICAgICAgIGNvbXBh
dGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0KPj4+PiArICAgICAgICAgICAgICAgICAgICByZWcg
PSA8MHgwIDB4NDdmZjMwMDAgMHgwIDB4MTAwMD47DQo+Pj4+ICsgICAgICAgICAgICB9Ow0KPj4+
PiArICAgICAgICAgICAgc2NtaV9zaG1fNDogc3JhbUA0N2ZmNDAwMCB7DQo+Pj4+ICsgICAgICAg
ICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0KPj4+PiArICAgICAg
ICAgICAgICAgICAgICByZWcgPSA8MHgwIDB4NDdmZjQwMDAgMHgwIDB4MTAwMD47DQo+Pj4+ICsg
ICAgICAgICAgICB9Ow0KPj4+PiArDQo+Pj4+ICsgICAgICAgICAgICBmaXJtd2FyZSB7DQo+Pj4+
ICsgICAgICAgICAgICAgICAgc2NtaTogc2NtaSB7DQo+Pj4+ICsgICAgICAgICAgICAgICAgICAg
IGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc21jIjsNCj4+Pj4gKyAgICAgICAgICAgICAgICAgICAg
YXJtLCBzbWMgLSBpZCA9IDwweDgyMDAwMDAyPjsgPC0tLSBYZW4gbWFuYWdlbWVudCBhZ2VudCBj
aGFubmVsICJzbWMtaWQiDQo+Pj4+ICsgICAgICAgICAgICAgICAgICAgICNhZGRyZXNzLWNlbGxz
ID0gPCAxPjsNCj4+Pj4gKyAgICAgICAgICAgICAgICAgICAgI3NpemUtY2VsbHMgPSA8IDA+Ow0K
Pj4+PiArICAgICAgICAgICAgICAgICAgICAjYWNjZXNzLWNvbnRyb2xsZXItY2VsbHMgPSA8IDE+
Ow0KPj4+PiArICAgICAgICAgICAgICAgICAgICBzaG1lbSA9IDwmc2NtaV9zaG1fMD47IDwtLS0g
WGVuIG1hbmFnZW1lbnQgYWdlbnQgY2hhbm5lbCAic2htZW0iDQo+Pj4+ICsNCj4+Pj4gKyAgICAg
ICAgICAgICAgICAgICAgcHJvdG9jb2xAWHsNCj4+Pj4gKyAgICAgICAgICAgICAgICAgICAgfTsN
Cj4+Pj4gKyAgICAgICAgICAgICAgICB9Ow0KPj4+PiArICAgICAgICAgICAgfTsNCj4+Pj4gKyAg
ICB9DQo+Pj4+ICsNCj4+Pj4gK0ltcG9ydGFudCB0aGluZyB0byBub3RlIGlzIHRoYXQgYWxsIGlu
Zm9ybWF0aW9uIGFib3V0IG11bHRpLWNoYW5uZWwgc3VwcG9ydCBpcyBzdHJpY3RseSBYZW4gc3Bl
Y2lmaWMuDQo+Pj4+ICsNCj4+Pj4gK0R1cmluZyBpbml0aWFsaXphdGlvbiB0aGUgU0NNSSBtdWx0
aS1hZ2VudCBkcml2ZXIgdXNlcyBIb3N0IERUIFNDTUkgbm9kZSBhbmQNCj4+Pj4gKyJ4ZW4sc2Nt
aS1zZWNvbmRhcnktYWdlbnRzIiBwcm9wZXJ0eSB0byBpbml0IGl0c2VsZiBhbmQgdGhlbiwgZHVy
aW5nIERvbTAgY3JlYXRpb24sIG1hbmlwdWxhdGVzDQo+Pj4+ICtEb20wIERUIHRvIHJlbW92ZSBY
ZW4gc3BlY2lmaWMgU0NNSSBpbmZvIGFuZCB1cGRhdGUgZG9tMCBTQ01JIG5vZGVzIHdpdGggRG9t
MCBTQ01JIGFnZW50IHNwZWNpZmljDQo+Pj4+ICtpbmZvcm1hdGlvbi4NCj4+Pj4gKw0KPj4+PiAr
VGhlcmUgYXJlIHR3byBuZWdhdGl2ZSBwb2ludHM6DQo+Pj4+ICsNCj4+Pj4gKzEpIERvdWJsZSBE
VCBtb2RpZmljYXRpb24gLSBvbmUgaXMgdXNlciB0byBzZXQgdXAgU0NNSSBYZW4gc3VwcG9ydCBp
biBIb3N0IERULCBzZWNvbmQgLQ0KPj4+PiArICAgRG9tMCBEVCBtYW5pcHVsYXRpb24uDQo+Pj4+
ICsyKSBJbiBjYXNlIG9mIGZ1dHVyZSBzdXBwb3J0IG9mIG1haWxib3ggc2hhcmVkLW1lbW9yeSB0
cmFuc3BvcnQgdGhlcmUgY291bGQgYmUgdXAgdG8gNCBtYWlsYm94ZXMgYW5kDQo+Pj4+ICsgICB1
cCB0byAyIHNoYXJlZC1tZW1vcmllcyBwZXIgU0NNSSBhZ2VudCBjaGFubmVsLg0KPj4+PiArDQo+
Pj4+ICtIZW5jZSBTQ01JIG11bHRpLWFnZW50IHN1cHBvcnQgaXMgWGVuIHNwZWNpZmljIGtub3ds
ZWRnZSB0aGVyZSBpcyBhIHByb3Bvc2FsIHRvIGFkZCBpdCBhcyBYZW4NCj4+Pj4gK3NwZWNpZmlj
IERUIGRlZmluaXRpb25zIGFuZCBzbyBtaW5pbWl6ZSBIb3N0IGFuZCBEb20wIERUIG1hbmlwdWxh
dGlvbnMuDQo+Pj4+ICtUaG9zZSBkZWZpbml0aW9ucyBjYW4gYmUgYWRkZWQgaW4gIi9jaG9zZW4i
IG9yLCBpZGVhbGx5LCBpbiAieGVuLGNvbmZpZyIgbm9kZSAobGlrZSBpbiBIeXBlcmxhdW5jaCBk
ZXNpZ24pLg0KPj4+PiArDQo+Pj4+ICtUaGUgU0NNSSBiaW5kaW5nIHN0YXlzIGdlbmVyaWMsIGp1
c3QgdHdvIFNDTUkgbm9kZXMgZGVmaW5lZCAtIG9uZSBmb3IgWGVuIG1hbmFnZW1lbnQgY2hhbm5l
bCBhbmQNCj4+Pj4gK29uZSBmb3IgSG9zdCBEb20wIE9TUE0uDQo+Pj4+ICsNCj4+Pj4gK0V4YW1w
bGUgb2YgdXNpbmcgImNob3NlbiIgZm9yIGNvbmZpZ3VyYXRpb246DQo+Pj4+ICsNCj4+Pj4gKy4u
IGNvZGU6Og0KPj4+PiArDQo+Pj4+ICsgICAgL3sNCj4+Pj4gKw0KPj4+PiArICAgICAgICBjaG9z
ZW4gew0KPj4+PiArICAgICAgICAgICAgLi4uDQo+Pj4+ICsNCj4+Pj4gKyAgICAgICAgICAgIC8v
IFhlbiBTQ01JIG1hbmFnZW1lbnQgY2hhbm5lbA0KPj4+PiArICAgICAgICAgICAgc2NtaV9zaG1f
MCA6IHNyYW1ANDdmZjAwMDAgew0KPj4+PiArICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAi
YXJtLHNjbWktc2htZW0iOw0KPj4+PiArICAgICAgICAgICAgICAgIHJlZyA9IDwweDAgMHg0N2Zm
MDAwMCAweDAgMHgxMDAwPjsNCj4+Pj4gKyAgICAgICAgICAgIH07DQo+Pj4+ICsgICAgICAgICAg
ICBzY21pX3hlbjogc2NtaSB7DQo+Pj4+ICsgICAgICAgICAgICAgICAgY29tcGF0aWJsZSA9ICJh
cm0sc2NtaS1zbWMiOw0KPj4+PiArICAgICAgICAgICAgICAgIGFybSxzbWMtaWQgPSA8MHg4MjAw
MDAwMj47IDwtLS0gWGVuIG1hbmVnZW1lbnQgYWdlbnQgc21jLWlkDQo+Pj4+ICsgICAgICAgICAg
ICAgICAgI2FkZHJlc3MtY2VsbHMgPSA8IDE+Ow0KPj4+PiArICAgICAgICAgICAgICAgICNzaXpl
LWNlbGxzID0gPCAwPjsNCj4+Pj4gKyAgICAgICAgICAgICAgICAjYWNjZXNzLWNvbnRyb2xsZXIt
Y2VsbHMgPSA8IDE+Ow0KPj4+PiArICAgICAgICAgICAgICAgIHNobWVtID0gPCZzY21pX3NobV8w
PjsgPC0tLSBYZW4gbWFuZWdlbWVudCBhZ2VudCBzaG1lbQ0KPj4+PiArICAgICAgICAgICAgfTsN
Cj4+Pj4gKw0KPj4+PiArICAgICAgICAgICAgLy8gU0NNSSBtdWx0aS1hZ2VudCBjb25maWd1cmF0
aW9uDQo+Pj4+ICsgICAgICAgICAgICBzY21pX3NobV8yOiBzcmFtQDQ3ZmYyMDAwIHsNCj4+Pj4g
KyAgICAgICAgICAgICAgICAgICAgY29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zaG1lbSI7DQo+Pj4+
ICsgICAgICAgICAgICAgICAgICAgIHJlZyA9IDwweDAgMHg0N2ZmMjAwMCAweDAgMHgxMDAwPjsN
Cj4+Pj4gKyAgICAgICAgICAgIH07DQo+Pj4+ICsgICAgICAgICAgICBzY21pX3NobV8zOiBzcmFt
QDQ3ZmYzMDAwIHsNCj4+Pj4gKyAgICAgICAgICAgICAgICAgICAgY29tcGF0aWJsZSA9ICJhcm0s
c2NtaS1zaG1lbSI7DQo+Pj4+ICsgICAgICAgICAgICAgICAgICAgIHJlZyA9IDwweDAgMHg0N2Zm
MzAwMCAweDAgMHgxMDAwPjsNCj4+Pj4gKyAgICAgICAgICAgIH07DQo+Pj4+ICsgICAgICAgICAg
ICBzY21pX3NobV80OiBzcmFtQDQ3ZmY0MDAwIHsNCj4+Pj4gKyAgICAgICAgICAgICAgICAgICAg
Y29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zaG1lbSI7DQo+Pj4+ICsgICAgICAgICAgICAgICAgICAg
IHJlZyA9IDwweDAgMHg0N2ZmNDAwMCAweDAgMHgxMDAwPjsNCj4+Pj4gKyAgICAgICAgICAgIH07
DQo+Pj4+ICsgICAgICAgICAgICB4ZW4sc2NtaS1zZWNvbmRhcnktYWdlbnRzID0gPA0KPj4+PiAr
ICAgICAgICAgICAgICAgICAgICAgICAgMSAweDgyMDAwMDAzICZzY21pX3NobQ0KPj4+PiArICAg
ICAgICAgICAgICAgICAgICAgICAgMiAweDgyMDAwMDA0ICZzY21pX3NobV8yDQo+Pj4+ICsgICAg
ICAgICAgICAgICAgICAgICAgICAzIDB4ODIwMDAwMDUgJnNjbWlfc2htXzMNCj4+Pj4gKyAgICAg
ICAgICAgICAgICAgICAgICAgIDQgMHg4MjAwMDAwNiAmc2NtaV9zaG1fND47DQo+Pj4+ICsgICAg
ICAgIH07DQo+Pj4+ICsNCj4+Pj4gKyAgICAgICAgLy8gSG9zdCBTQ01JIE9TUE0gY2hhbm5lbCAt
IHByb3ZpZGVkIHRvIHRoZSBEb20wIGFzIGlzIGlmIFNDTUkgZW5hYmxlZCBmb3IgaXQNCj4+Pj4g
KyAgICAgICAgc2NtaV9zaG06IHNyYW1ANDdmZjEwMDAgew0KPj4+PiArICAgICAgICAgICAgICAg
IGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0KPj4+PiArICAgICAgICAgICAgICAgIHJl
ZyA9IDwweDAgMHg0N2ZmMTAwMCAweDAgMHgxMDAwPjsNCj4+Pj4gKyAgICAgICAgfTsNCj4+Pj4g
Kw0KPj4+PiArICAgICAgICBmaXJtd2FyZSB7DQo+Pj4+ICsgICAgICAgICAgICBzY21pOiBzY21p
IHsNCj4+Pj4gKyAgICAgICAgICAgICAgICBjb21wYXRpYmxlID0gImFybSxzY21pLXNtYyI7DQo+
Pj4+ICsgICAgICAgICAgICAgICAgYXJtLHNtYy1pZCA9IDwweDgyMDAwMDAzPjsgPC0tLSBIb3N0
IE9TUE0gYWdlbnQgc21jLWlkDQo+Pj4+ICsgICAgICAgICAgICAgICAgI2FkZHJlc3MtY2VsbHMg
PSA8IDE+Ow0KPj4+PiArICAgICAgICAgICAgICAgICNzaXplLWNlbGxzID0gPCAwPjsNCj4+Pj4g
KyAgICAgICAgICAgICAgICBzaG1lbSA9IDwmc2NtaV9zaG0+OyA8LS0tIEhvc3QgT1NQTSBhZ2Vu
dCBzaG1lbQ0KPj4+IEJ5IE9TUE0geW91IG1lYW4gRG9tMCBhbmQgbm90IFhlbj8gU28gdGhpcyBp
cyBhIGNoYW5nZSBjb21wYXJlZCB0byBhDQo+Pj4gZGV2aWNlIHRyZWUgZm9yIGJhcmVtZXRhbCBM
aW51eCB3aXRob3V0IFhlbj8NCk9TUE0gaXMgT1MgaW4gZ2VuZXJhbCwgZm9yIGV4YW1wbGUgTGlu
dXguDQo+Pj4gTGV0IG1lIGFzayB0aGUgc2FtZSBxdWVzdGlvbiBkaWZmZXJlbnRseS4gSW4gdGhl
IGNhc2Ugb2YgYmFyZW1hdGFsIExpbnV4DQo+Pj4gd2l0aG91dCBYZW4gKG5vIEtWTSksIHdoYXQg
d291bGQgTGludXggc2VlIHVuZGVyIC9maXJtd2FyZS9zY21pIGFzDQo+Pj4gc21jLWlkIGFuZCBz
aG1lbT8gVGhlIHNhbWUgYXMgdGhlIG9uZSB0aGF0IFhlbiB3b3VsZCB1c2UgZm9yIGl0c2VsZj8g
T3INCj4+PiB0aGUgc2FtZSBhcyB0aGUgb25lcyB0aGF0IERvbTAgd291bGQgdXNlIHdoZW4gWGVu
IGlzIHByZXNlbnQ/DQo+PiBJZiB0aGlzIERUIGlzIHVzZWQgd2l0aCB0aGUgYmFyZW1ldGFsIExp
bnV4IC0gdGhlbiB0aGUgTGludXggS2VybmVsIHdpbGwNCj4+DQo+PiBzZWUgRG9tMCAic21jLWlk
IiBhbmQgInNobWVuIiB1bmRlciAvZmlybXdhcmUvc2NtaS4NCj4+DQo+Pj4+ICsgICAgICAgICAg
ICAgICAgcHJvdG9jb2xAWHsNCj4+Pj4gKyAgICAgICAgICAgICAgICB9Ow0KPj4+PiArICAgICAg
ICAgICAgfTsNCj4+Pj4gKyAgICAgICAgfTsNCj4+Pj4gKyAgICB9DQo+Pj4+ICsNCj4+Pj4gKw0K
Pj4+PiArSW4gdGhlIGFib3ZlIGNhc2U6DQo+Pj4+ICsNCj4+Pj4gKzEpIFhlbiBTQ01JIG11bHRp
LWFnZW50IGNhbiBiZSBwcm9iZWQgd2l0aCBEVCBjb25maWd1cmF0aW9uIGZyb20gImNob3NlbiIg
KG9yIHNwZWNpYWwgInhlbixjb25maWciKQ0KPj4+PiArICAgbm9kZSBhbmQgYWxsIFhlbiByZWxh
dGVkIG5vZGVzIGNhbiBiZSBlYXNpbHkgZHJvcHBlZCBmcm9tIERvbTAgRFQuDQo+Pj4+ICsyKSBI
b3N0IFNDTUkgT1NQTSBjaGFubmVsIERUIG5vZGVzIGNhbiBiZSBjb3BpZWQgdG8gRG9tMCBEVCB3
aXRob3V0IGNoYW5nZXMgaWYgU0NNSSBlbmFibGVkIGZvciBpdC4NCj4+Pj4gKzMpIEZ1dHVyZSBz
dXBwb3J0IGZvciBtYWlsYm94IHNoYXJlZC1tZW1vcnkgdHJhbnNwb3J0IChTQ1AgU0NNSSBGVykg
Y2FuIGJlIHNpbXBsaWZpZWQgYXMgbm8gbW9yZQ0KPj4+PiArICAgbWFuaXB1bGF0aW9uIHJlcXVp
cmVkIHdpdGggRG9tMCBTQ01JICJhcm0sc21jLWlkIiBhbmQgInNobWVtIiBEVCBwcm9wZXJ0aWVz
Lg0KPj4+IFllcywgSSBjYW4gc2VlIHRoZSBiZW5lZml0IGlmIHdlIGNhbiBhcnJhbmdlIGl0IHNv
IHRoYXQgdGhlIHVuZGVybHlpbmcNCj4+PiBob3N0IGRldmljZSB0cmVlIGlzIHRoZSBzYW1lIHRo
YXQgTGludXggd291bGQgdXNlIGJhcmVtZXRhbC4gQW5kIGFsbCB0aGUNCj4+PiBleHRyYSBjb25m
aWd1cmF0aW9uIGlzIHBsYWNlZCB1bmRlciAvY2hvc2VuIGluICJ4ZW4sY29uZmlnIiBub2RlIG9y
DQo+Pj4gc2ltaWxhci4gSSB3b3VsZCBwcm9iYWJseSBjYWxsIGl0ICJ4ZW4sc2NtaSIuDQo+PiBQ
ZXJzb25hbGx5LCBJIHdvdWxkIGtlZXAgInhlbixjb25maWciIGFzIGl0IGxlYXZlcyByb29tIHRv
IGFkZCBhZGRpdGlvbmFsDQo+Pg0KPj4gY29uZmlndXJhdGlvbiBub2RlcyBpbiB0aGUgZnV0dXJl
Lg0KPj4NCj4+Pj4gK0V4YW1wbGUgb2YgdXNpbmcgInhlbixjb25maWciIGZvciBjb25maWd1cmF0
aW9uOg0KPj4+PiArDQo+Pj4+ICsuLiBjb2RlOjoNCj4+Pj4gKw0KPj4+PiArICAgIGh5cGVydmlz
b3Igew0KPj4+PiArICAgICAgICBjb21wYXRpYmxlID0g4oCcaHlwZXJ2aXNvcix4ZW7igJ0NCj4+
Pj4gKw0KPj4+PiArICAgICAgICAvLyBDb25maWd1cmF0aW9uIGNvbnRhaW5lcg0KPj4+PiArICAg
ICAgICBjb25maWcgew0KPj4+PiArICAgICAgICAgICAgY29tcGF0aWJsZSA9ICJ4ZW4sY29uZmln
IjsNCj4+Pj4gKyAgICAgICAgICAgIC4uLg0KPj4+PiArDQo+Pj4+ICsgICAgICAgICAgICAvLyBY
ZW4gU0NNSSBtYW5hZ2VtZW50IGNoYW5uZWwNCj4+Pj4gKyAgICAgICAgICAgIHNjbWlfc2htXzAg
OiBzcmFtQDQ3ZmYwMDAwIHsNCj4+Pj4gKyAgICAgICAgICAgICAgICBjb21wYXRpYmxlID0gImFy
bSxzY21pLXNobWVtIjsNCj4+Pj4gKyAgICAgICAgICAgICAgICByZWcgPSA8MHgwIDB4NDdmZjAw
MDAgMHgwIDB4MTAwMD47DQo+Pj4+ICsgICAgICAgICAgICB9Ow0KPj4+PiArICAgICAgICAgICAg
c2NtaV94ZW46IHNjbWkgew0KPj4+PiArICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJt
LHNjbWktc21jIjsNCj4+Pj4gKyAgICAgICAgICAgICAgICBhcm0sc21jLWlkID0gPDB4ODIwMDAw
MDI+OyA8LS0tIFhlbiBtYW5lZ2VtZW50IGFnZW50IHNtYy1pZA0KPj4+PiArICAgICAgICAgICAg
ICAgICNhZGRyZXNzLWNlbGxzID0gPCAxPjsNCj4+Pj4gKyAgICAgICAgICAgICAgICAjc2l6ZS1j
ZWxscyA9IDwgMD47DQo+Pj4+ICsgICAgICAgICAgICAgICAgI2FjY2Vzcy1jb250cm9sbGVyLWNl
bGxzID0gPCAxPjsNCj4+Pj4gKyAgICAgICAgICAgICAgICBzaG1lbSA9IDwmc2NtaV9zaG1fMD47
IDwtLS0gWGVuIG1hbmVnZW1lbnQgYWdlbnQgc2htZW0NCj4+Pj4gKyAgICAgICAgICAgIH07DQo+
Pj4+ICsNCj4+Pj4gKyAgICAgICAgICAgIC8vIFNDTUkgbXVsdGktYWdlbnQgY29uZmlndXJhdGlv
bg0KPj4+PiArICAgICAgICAgICAgc2NtaV9zaG1fMjogc3JhbUA0N2ZmMjAwMCB7DQo+Pj4+ICsg
ICAgICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0KPj4+PiAr
ICAgICAgICAgICAgICAgICAgICByZWcgPSA8MHgwIDB4NDdmZjIwMDAgMHgwIDB4MTAwMD47DQo+
Pj4+ICsgICAgICAgICAgICB9Ow0KPj4+PiArICAgICAgICAgICAgc2NtaV9zaG1fMzogc3JhbUA0
N2ZmMzAwMCB7DQo+Pj4+ICsgICAgICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNj
bWktc2htZW0iOw0KPj4+PiArICAgICAgICAgICAgICAgICAgICByZWcgPSA8MHgwIDB4NDdmZjMw
MDAgMHgwIDB4MTAwMD47DQo+Pj4+ICsgICAgICAgICAgICB9Ow0KPj4+PiArICAgICAgICAgICAg
c2NtaV9zaG1fNDogc3JhbUA0N2ZmNDAwMCB7DQo+Pj4+ICsgICAgICAgICAgICAgICAgICAgIGNv
bXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0KPj4+PiArICAgICAgICAgICAgICAgICAgICBy
ZWcgPSA8MHgwIDB4NDdmZjQwMDAgMHgwIDB4MTAwMD47DQo+Pj4+ICsgICAgICAgICAgICB9Ow0K
Pj4+PiArICAgICAgICAgICAgeGVuLHNjbWktc2Vjb25kYXJ5LWFnZW50cyA9IDwNCj4+Pj4gKyAg
ICAgICAgICAgICAgICAgICAgICAgIDEgMHg4MjAwMDAwMyAmc2NtaV9zaG0NCj4+Pj4gKyAgICAg
ICAgICAgICAgICAgICAgICAgIDIgMHg4MjAwMDAwNCAmc2NtaV9zaG1fMg0KPj4+PiArICAgICAg
ICAgICAgICAgICAgICAgICAgMyAweDgyMDAwMDA1ICZzY21pX3NobV8zDQo+Pj4+ICsgICAgICAg
ICAgICAgICAgICAgICAgICA0IDB4ODIwMDAwMDYgJnNjbWlfc2htXzQ+Ow0KPj4+PiArICAgICAg
ICB9Ow0KPj4+PiArICAgIH07DQo+Pj4+ICsNCj4+Pj4gKyAgICAvew0KPj4+PiArICAgICAgICAv
LyBIb3N0IFNDTUkgT1NQTSBjaGFubmVsIC0gcHJvdmlkZWQgdG8gdGhlIERvbTAgYXMgaXMgaWYg
U0NNSSBlbmFibGVkIGZvciBpdA0KPj4+PiArICAgICAgICBzY21pX3NobTogc3JhbUA0N2ZmMTAw
MCB7DQo+Pj4+ICsgICAgICAgICAgICAgICAgY29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zaG1lbSI7
DQo+Pj4+ICsgICAgICAgICAgICAgICAgcmVnID0gPDB4MCAweDQ3ZmYxMDAwIDB4MCAweDEwMDA+
Ow0KPj4+PiArICAgICAgICB9Ow0KPj4+PiArDQo+Pj4+ICsgICAgICAgIGZpcm13YXJlIHsNCj4+
Pj4gKyAgICAgICAgICAgIHNjbWk6IHNjbWkgew0KPj4+PiArICAgICAgICAgICAgICAgIGNvbXBh
dGlibGUgPSAiYXJtLHNjbWktc21jIjsNCj4+Pj4gKyAgICAgICAgICAgICAgICBhcm0sc21jLWlk
ID0gPDB4ODIwMDAwMDM+OyA8LS0tIEhvc3QgT1NQTSBhZ2VudCBzbWMtaWQNCj4+Pj4gKyAgICAg
ICAgICAgICAgICAjYWRkcmVzcy1jZWxscyA9IDwgMT47DQo+Pj4+ICsgICAgICAgICAgICAgICAg
I3NpemUtY2VsbHMgPSA8IDA+Ow0KPj4+PiArICAgICAgICAgICAgICAgIHNobWVtID0gPCZzY21p
X3NobT47IDwtLS0gSG9zdCBPU1BNIGFnZW50IHNobWVtDQo+Pj4+ICsNCj4+Pj4gKyAgICAgICAg
ICAgICAgICBwcm90b2NvbEBYew0KPj4+PiArICAgICAgICAgICAgICAgIH07DQo+Pj4+ICsgICAg
ICAgICAgICB9Ow0KPj4+PiArICAgICAgICB9Ow0KPj4+PiArICAgIH0NCj4+Pj4gLS0gDQo+Pj4+
IDIuMzQuMQ==


From xen-devel-bounces@lists.xenproject.org Thu Jun 19 16:15:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 16:15:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020237.1396631 (Exim 4.92)
	(envelope-from )
	id 1uSHvS-0007Yz-2g; Thu, 19 Jun 2025 16:15:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020237.1396631; Thu, 19 Jun 2025 16:15: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 1uSHvR-0007Ym-UZ; Thu, 19 Jun 2025 16:15:41 +0000
Received: by outflank-mailman (input) for mailman id 1020237;
 Thu, 19 Jun 2025 16:15: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 1uSHvP-0005oY-Li
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 16:15:39 +0000
Received: from AS8PR03CU001.outbound.protection.outlook.com
 (mail-westeuropeazlp170120005.outbound.protection.outlook.com
 [2a01:111:f403:c201::5])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a3c9bf61-4d28-11f0-a30d-13f23c93f187;
 Thu, 19 Jun 2025 18:15:39 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by DB8PR03MB6332.eurprd03.prod.outlook.com (2603:10a6:10:13d::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.19; Thu, 19 Jun
 2025 16:15:38 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%4]) with mapi id 15.20.8835.023; Thu, 19 Jun 2025
 16:15: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: a3c9bf61-4d28-11f0-a30d-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=bH0UugQPi0fTFzbb27m/DLPrDlGmId62FGqmtaQVV2rIGA5dLFA21QCQ7XetBhcpEP8IZCX15kO35+7ocn5bt8Bs/x4YZX9rabARBXT5SwRwmB/u43+hhg/l7OGyjDKJ2TDlA2Vf/TSP0nHVLt9k0VOrVb69m6M5D2KRHy64LLm5Y0JtWSV0U0ctXuadOS+uZOgn5lk4lLdYVy/LVx4gfGmyVe58PRu4hlKP/aR/6gFQzF3m6ERUSimLdnJ7CqS5x2+51CS0hsgoY1RE+O5km7x1YGl/0EpJH5+whMaT5JWm9Hi/x/2k03qMqa0aRWXORfnKV8nPxj4yTTtpo9O3Hw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=lflLdOipEqmnCKZZXZjjMTogz5yfqVOI6aOdNSsd2Ss=;
 b=keByeEA1pb1zy/zMP2pyfo+Kgw8Zkklvhxqcakr0MCAqOzIo3+xCeA7Z4mPhcW5rGEV799tmdTaeGBY05+a9Edt3xo7GQEbqqnRpxZ1BYdxx3DovQTU80ihm57+T/U6lc3lLprt0DXLUj0Ac47kembLmTtmFjH+mBQcFiWyfESmDMCGC4QxK+leJQL67RCTDBm6XTNdi+7De+CUzzIBbDCsb3Pe94XbUn2uuEuCF9wfmtfrgPlw7nFebA6PTw1jOBoTaDc1Mj3vjM6TpdbsLaYTeprOl8Z6ZOA/JnVGhZTKVZ/cAnldGWInXM5cb2NbfeLw69aR0Ksc5iLVha5eEMg==
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=lflLdOipEqmnCKZZXZjjMTogz5yfqVOI6aOdNSsd2Ss=;
 b=hp2ZtG+ZSuFZr47W+mFi1jUZ0/1sK0OiJjP8L0t4angHwT6ywHLELIhLY/NANQIILctqqABHgs2IttMn7g9Qw0FaisD9RXPavW4gqvz/TFJMlLvSt5BTQqBTcl7vvXpJ0NniAeQrqji3qgYUkscHu1wGlRCqWcEVCYjUI+aPRkxLrqGr9QxzWwbebqQgEO+7yXCJKRorG/TvdO1UICTgRF4GppnIOoGhFQRfiqNb0z3gV71ytBj5MOlyfL8YmpYI8m/kGkXonwP5epzBeqH86O8dF378JfL6LPGrAUkTB0hNjAa2gYwtqGr2ULacXXN3tz0miV+PdDZ7r3giraLAhQ==
From: Oleksii Moisieiev 
To: Julien Grall , "xen-devel@lists.xenproject.org"
	
CC: Andrew Cooper , Anthony PERARD
	, Bertrand Marquis , Jan
 Beulich , Juergen Gross , Michal Orzel
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Stefano Stabellini ,
	Volodymyr Babchuk , Grygorii Strashko
	
Subject: Re: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC
 multi-agent driver
Thread-Topic: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC
 multi-agent driver
Thread-Index: AQHbyNXPHUV4T01ZEEC9Uxm0LaLKHbQIs5qAgAIlg4A=
Date: Thu, 19 Jun 2025 16:15:37 +0000
Message-ID: <2a98353b-a28b-4935-af26-80dc11d3862d@epam.com>
References: 
 <318044ae12f13b6b297b3f5fda577a1a6cd143da.1747669845.git.oleksii_moisieiev@epam.com>
 <13d95459-ea77-46ea-84e4-cccece4cd496@xen.org>
In-Reply-To: <13d95459-ea77-46ea-84e4-cccece4cd496@xen.org>
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: PAVPR03MB8946:EE_|DB8PR03MB6332:EE_
x-ms-office365-filtering-correlation-id: aa67015d-a214-4571-35e9-08ddaf4c8754
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|376014|366016|7416014|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?bzNLYVZZaXVEVFNTS2xZVzJJTThyMHZYS0xNOFQ4aHJTNUEvM0dmbWhoS0Nu?=
 =?utf-8?B?WGZmY01kK2I1K3FRRGFTMURKcHRDb2FYbGVPL3lxYlVIMVVPV3lyZ2ttZUVp?=
 =?utf-8?B?NEZNYURWRktxTHRrdCtkRVZYajVyN3Z0Rm9Ucm5mbmtRMW5SMVBydDRRWkdP?=
 =?utf-8?B?aFRhYXlFUWt1TFJrK012VUhIWGgwMGMxLzhtSHBMRzFKMjQ4WWtkc3ZYMXlX?=
 =?utf-8?B?bzFqQnNWZ2tTNzdIb053VGU1QWRTY254dVB4WHZpcHl1NHgvWWR2YTdPYXpi?=
 =?utf-8?B?YWVmRHl6cFhYZGVvdXpsd3hYUkRRZ29WdUJNcnBZNjdaazRHVzJJeEswL3hn?=
 =?utf-8?B?WXE3TXhzSU42VW5DQk1JSUZJbUNFM2xCNlhZT1FTdlh6WFBFQy9tbkZPUVh6?=
 =?utf-8?B?S2trSGdZRjdqaVpRcW9QaGEzam5qWGtLMTdMODY0WnZTUEtFcW9leXp6MHEz?=
 =?utf-8?B?aE01WWg4aVMvSlVSekcvWGhOQ2ZPZ3c4YVdRcS9hYjFLT0t5QjJOMk5hLytT?=
 =?utf-8?B?M2UwSW9heStwMGJzQ2RFc0FXeUxJVUxnSmFraWFZT1VRZU83UWMrUkpXTSs3?=
 =?utf-8?B?NUU1anByNGlqeWtIc0FGMWMwUXRybXowa3VtbUl5dGJscHFlaGFRNVlwZk5L?=
 =?utf-8?B?ZlQ4bUlMczBEUEZiNkYvWHR4bVFJN0cwVE85QTlHUThzQjVpVzRmVWRMSUhp?=
 =?utf-8?B?UEhFSTBlOE1jaERMcmlibldBTG4wdVNGSkRMWDFQK1k1blNHeThORXhTS1Nz?=
 =?utf-8?B?OEMvbjIrTjEyK3dqS0k0YWMrYUE5c2RMeG1wS1h2SExRMUVtSlRSNXk1bG44?=
 =?utf-8?B?eDlmd2Jib0FJRnd3Z2dBWFdMeGVFSnZnMzhJanZDalI3aGQrZzUvMjdPcWFQ?=
 =?utf-8?B?WHR2SlN5VU9wOFA0aXVMUkpnS2F0STJ1SlVDWGZ0bHIvWnZUa213c2IzQ1RR?=
 =?utf-8?B?WjZkRnlqNFo3dWJUVHBJbklvTDFVaDM0TTJLWVEzVk9meVR4RGJZZStIcEpl?=
 =?utf-8?B?ekJxaXNkWnMxZXNRSG1pTXRQd1pGK3RsRUFjdENiZ0hxSG9kYTc3WTRBcGhF?=
 =?utf-8?B?UU1BUXh2WlFxeHRwNmo1TDRFZkJjRU1CcGtheWRMUmZXdEdPN1B3bFZQb0Rj?=
 =?utf-8?B?YWY1N3NNQ0IrRFRNTm5RclJrblV3VUtkOTFUZDZhMkl5cmNTdWpoWWhWa0I1?=
 =?utf-8?B?d2RGUlNpRWVVdTNsQnJPTTNUNmp1ejMzaE5JaTVmNi9yamVtR25tZTE2Qys5?=
 =?utf-8?B?OWZNdFhvenRsVHFXaFpyQ2JwamRKc2VLTGN6RWFnVVBGeFRxRjhnKzVObTJO?=
 =?utf-8?B?V1l2TjBhTUU1UDcyTWRUTG9leDVLU1dBT0dSTG1PWG5GYi92a3k4cEpUclow?=
 =?utf-8?B?Sis4d1pObTBFVUNIM2NVUWYxRFFZeTBrVFRjY2x2OW1CYnZnMmFyZFhCVTQx?=
 =?utf-8?B?ODRCTnZCT0tFUUsrTUZ3Y0FYNDMrU3hhcTFXMWMyNm83MkpINTRlQS9uR01Z?=
 =?utf-8?B?TG9xd2ZmSGtFNnNPaHBteHdMdGE4WXNXbVQ0TkN1bkJJbnNUcm9GbkszelBJ?=
 =?utf-8?B?N0VQZjVtRjMydGdEK2IycGE1OFlFQUREZHF5bjBKTlBHY0RMV0F3aFZxNDh4?=
 =?utf-8?B?K0h1TG9vZldLbW5uK1NFYk80OHF1Mzl5aWVNRWdkaDNoRWc4RWpIVEpYMERl?=
 =?utf-8?B?bXMvT1JQTVQzTXRFMGQ0RlExdHVnaXE5UEhLa0dNV0k0dGJKelNFMUZQcEVy?=
 =?utf-8?B?elBUbG00RlpkcFl2YTFpY0hTMWMzbmZUbk91RTh5VlhVZVNmeHdxWEZJWWFC?=
 =?utf-8?B?eWVtRjA5N3Q0eGlSMjRsUEdPMmVjN3J3dXJjc1liNzhLUVRwK3dwUUlHNE5V?=
 =?utf-8?B?V3M4ZC8reDZnazhiRlM2L3k4UDhVREVLeHUrVUtJTy9yTnFKWU1nUHhwbUpG?=
 =?utf-8?B?dUlRRUJoZnZ6Zkd3Y3dZMEZ2eGZQSG53MXhvZ0I4ZkxxSXBMZk9HREVwWjZU?=
 =?utf-8?Q?Ba/o08aF0NEQV9XD64fb4Ae/jTzTss=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7416014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?cmZGSUxQL3A0TFZyTEQwRm1kUmV4RjRBYXp1K0c5SGpMRFU4RUlWbGtuTlhO?=
 =?utf-8?B?QzloSlBuT3hOcjNLYUZ0OFlpdFBhM1NzZm1NOVc1enRkYlVLNkxmbS9Zck1V?=
 =?utf-8?B?YUtmSGlqYktBRnpuUGtGZUJNdDIzbTZ6TTZtc1R6NVpmYkU2WUdFY2xjK3J1?=
 =?utf-8?B?Z0czNldVZXdrUXRYQm1lVUp5MTVWN3p2dXdRTVdxdG9uTWlTSG01ZURhM0I1?=
 =?utf-8?B?L1ZrdU1ZZlVEMEU5ZUVPeisrWjl1U3BmTDh6Q25jL3I1NjFad1orRkVUWU5k?=
 =?utf-8?B?UzFVOWRwVW52YktvYXgrMUs4bWdpWS9ISE5zdklGVzFwMEtNNmJKNzN4MnJY?=
 =?utf-8?B?Q0t4cDllWSt5b0x5MUdkVVQxcEx2cFh6RTRvRytBSmNuaUNycndGckdLOHVM?=
 =?utf-8?B?WS9hakI1bG5rc2I0VTBRRmlPSzAxU3VLdnFrOUJrcVltMzRQcUVYWDZWYWJr?=
 =?utf-8?B?N1Yvdlk3QmpZbkNxZlIzVVRhUE9BTm13bkd0OG1HbmJzSkdIYk1jT0g1dUhF?=
 =?utf-8?B?ME9zcXBLaXVBNStGc0xyZ0F4OGhGZHgrbEhFeC80YURBSVB0Q0E1MkhNZEky?=
 =?utf-8?B?NzM1SHhQOXZxcnNCbUVLczhSUWVoak0rNTFzMXgvVUNjRGtHWmJBYXpEUnBJ?=
 =?utf-8?B?ckZxVmRka284VkRDSHdzMk13dzhZK0hXRlAxYXFTbGJKd1drQ2tiRXlsbXVT?=
 =?utf-8?B?aG9pVVJxRTRHVUNZY1p2OFpQNWx6UVBZS1R4aEV2T05sMFp4TUpCLzNkQWZZ?=
 =?utf-8?B?RzQ0TVN0NmE0bGlDTk9rSTlnc2srbUJkcE9VM0ZIN0tnWlh5UWtGeHRwb2FI?=
 =?utf-8?B?dTg1QVV6Y240Si9MKzQ4cGgrS1M1UkVEZUtrdy93eUd5VHdnbHFOZ0ZPOVR4?=
 =?utf-8?B?ZWh6SFUvc2FIb1JTZ0RYeUNvSmpRRGREZjlSaXZKN3hsdmxlelVNSWZQU2R0?=
 =?utf-8?B?dGZyK0xQUWczMmpydmlHaXJWWHFZL29ONmdHWjluNzZqTFdXRStyN3ZIMmtV?=
 =?utf-8?B?dVJoL1BuZ0tDOXhNV1QyRElTUFFaR3NkSmJSN0xHU3FDYkx6cENKc2ovVUN0?=
 =?utf-8?B?QjRtWHdiOFE1QjI5VnczL1dxR3BURks3T1FlK0J2a0svT1lieE1iaWZhNFdl?=
 =?utf-8?B?L1JrQVFKZnNCelA1UUEzSWdxVGYrTkRFME5ZbGdjUXRwUnJ5RGZDZHZsaDI4?=
 =?utf-8?B?RG9zK3NxMmVTalowdWIyRnFJdWlkZldjVHBDa3Z5Z0ZubjdMYVdnV0ZHbTBB?=
 =?utf-8?B?alk4YTJJQWxXTTBDSzI5TnVHbGtTOFl6UnNvMTRNVkZQNElqcjYxWUhKK3JQ?=
 =?utf-8?B?S0dkdGwzNGVKM0FGMTErSHVVdWpNY2QzSGdBMGNoQ0RRTkIzb2Z2M25BWndh?=
 =?utf-8?B?VGljS2I3S3JmLytLZDBBQ1B4YnJ3L243UFFhMTh5NVloQWhHZWRjOTlTdUxv?=
 =?utf-8?B?QU1GV2JBejdxbmtNZjdNanNhcFV5aE5HdlltYi9VUDMzWGNYYmlRK2hVQjlu?=
 =?utf-8?B?cDRCaEJFZXArL251aGxRR1ZnQXE5SG0rTWQ4RVMrdy8xd3pwZm4rbG5KUDZh?=
 =?utf-8?B?T2UvU29yMHNEZ0dpdW1mNXJ4TlFqMVFDYXdpNng1NUZPYllseDFmd3R5Vnlm?=
 =?utf-8?B?Z1Fya2kwNGlmVFFwNjJKb3hOSTVIQ2thcVBWNkF0L1JiVTZrWG13clptSVFs?=
 =?utf-8?B?M3NEVnVKbGRudW9SYW9UN0o4SkRaeHR1c1VGNE5ocjF1eWN2Z3lRTTh3Zm9k?=
 =?utf-8?B?bDRHdVp2dTAwWnVjZ3cwM0Rac01qaHpTV2t3d3F3MFRnN2xwYkdtSm9UZ2Vs?=
 =?utf-8?B?T2N3UDdDTitKMFFxNE40cXJiMTk2Zm9vNXpzSzhpcjJsTzRRcW9IYkVGMExv?=
 =?utf-8?B?cXFIeFViS0dKSG8xRzBRS01SVkdaeFJ0KzloNFp3MEt5MjRXam5YcjNrNVl4?=
 =?utf-8?B?bmNGVEYzY0psR0g4R2h5UUhNM0lkU0cvNzkzeTVEQmUyMERRalZLWEMwTHR5?=
 =?utf-8?B?eGt0QXl5K0ZEd2FUeVBxeUxyQkRxcFJGekVHV3JrSVF6VHptalExR0pFM2NG?=
 =?utf-8?B?OFA4NG43NkNiZmwxUXNjdkFycUJZelVOcm1hRGY3MEF0MlozdGc1bVMxVWRn?=
 =?utf-8?B?L2l6Q1R6TXB1aHROTkZGVzd6NFVNNzI3aUliUXJjeDNUalpXTXdTa3FKWVdM?=
 =?utf-8?B?cHc9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: aa67015d-a214-4571-35e9-08ddaf4c8754
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2025 16:15:37.9060
 (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: vMhyXLvGwjboSr1pk+ejUNOWVvu6y8m+70OiYduFhDL0urpffPpVi9W/eP8lsVh4KMmVSwdkLxwpRJLez6AZ3G+mb6BTO98hX/Dfqny2fuk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR03MB6332

DQpPbiAxOC8wNi8yMDI1IDEwOjI4LCBKdWxpZW4gR3JhbGwgd3JvdGU6DQo+IEhpIE9sZWtzaWks
DQo+DQo+IE9uIDE5LzA1LzIwMjUgMTY6NTAsIE9sZWtzaWkgTW9pc2llaWV2IHdyb3RlOg0KPj4g
VGhpcyBwYXRjaCBpbnRyb2R1Y2VzIFNDSSBkcml2ZXIgdG8gc3VwcG9ydCBmb3IgQVJNIEVMMyBU
cnVzdGVkIA0KPj4gRmlybXdhcmUtQQ0KPj4gKFRGLUEpIHdoaWNoIHByb3ZpZGVzIFNDTUkgaW50
ZXJmYWNlIHdpdGggbXVsdGktYWduZXQgc3VwcG9ydCwgYXMgc2hvd24NCj4NCj4gcy9tdWx0aS1h
Z25ldC9tdWx0aS1hZ2VudC8NCj4NCndpbGwgZml4Lg0KPj4gYmVsb3cuDQo+Pg0KPj4gwqDCoCAr
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+PiDCoMKgIHzCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoCB8DQo+PiDCoMKgIHwgRUwzIFRGLUEgU0NNScKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfA0KPj4gwqDCoCArLS0t
LS0tLSstLSstLS0tLS0tKy0tKy0tLS0tLS0rLS0rLS0tLS0tLSsrDQo+PiDCoMKgIHxzaG1lbTAg
fMKgIHxzaG1lbTEgfMKgIHxzaG1lbTIgfMKgIHxzaG1lbVggfA0KPj4gwqDCoCArLS0tLS0rLSvC
oCArLS0tKy0tLSvCoCArLS0rLS0tLSvCoCArLS0tKy0tLSsNCj4+IHNtYy1pZDAgfMKgwqDCoMKg
wqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoCB8DQo+PiBhZ2Vu
dDDCoCB8wqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDC
oMKgIHwNCj4+IMKgwqAgKy0tLS0tdi0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0t
Kw0KPj4gwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqAg
fMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqAgfA0KPj4gwqDCoCB8wqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKg
wqAgfA0KPj4gwqDCoCArLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0r
DQo+PiDCoMKgwqDCoMKgwqDCoMKgwqAgc21jLWlkMSB8wqAgc21jLWlkMnzCoMKgwqAgc21jLWlk
WHwNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCBhZ2VudDHCoCB8wqAgYWdlbnQyIHzCoMKgwqAgYWdl
bnRYIHwNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDC
oMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oCArLS0tLXYtLS0rwqAgKy0tdi0tLS0tK8KgICstLXYtLS0tLSsNCj4+IMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqAgfMKgIHzCoMKgwqDCoMKgwqDCoCB8wqAgfMKgwqDC
oMKgwqDCoMKgIHwNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8IERvbTDCoMKgIHzCoCB8
IERvbTHCoMKgIHzCoCB8IERvbVjCoMKgIHwNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8
wqDCoMKgwqDCoMKgwqAgfMKgIHzCoMKgwqDCoMKgwqDCoCB8wqAgfMKgwqDCoMKgwqDCoMKgIHwN
Cj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqAgfMKgIHzCoMKgwqDC
oMKgwqDCoCB8wqAgfMKgwqDCoMKgwqDCoMKgIHwNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oCArLS0tLS0tLS0rwqAgKy0tLS0tLS0tK8KgICstLS0tLS0tLSsNCj4+DQo+PiBUaGUgRUwzIFND
TUkgbXVsdGktYWdlbnQgZmlybXdhcmUgZXhwZWN0ZWQgdG8gcHJvdmlkZSBTQ01JIFNNQy9IVkMg
DQo+PiBzaGFyZWQNCj4+IG1lbW9yeSB0cmFuc3BvcnQgZm9yIGV2ZXJ5IEFnZW50IGluIHRoZSBz
eXN0ZW0uDQo+Pg0KPj4gVGhlIFNDTUkgQWdlbnQgdHJhbnNwb3J0IGNoYW5uZWwgZGVmaW5lZCBi
eSBwYWlyOg0KPj4gwqAgLSBzbWMtaWQ6IFNNQy9IVkMgaWQgdXNlZCBmb3IgRG9vcmJlbGwNCj4+
IMKgIC0gc2htZW06IHNoYXJlZCBtZW1vcnkgZm9yIG1lc3NhZ2VzIHRyYW5zZmVyLCBYZW4gcGFn
ZSBhbGlnbmVkLA0KPj4gwqAgcDJtX21taW9fZGlyZWN0X25jLg0KPg0KPiBJdCBpcyBub3QgY2xl
YXIgd2h5IHdlIG5lbnRpb24gWGVuIHBhZ2UgYWxpZ25lZCBhbmQgDQo+IHAybV9tbWlvX2RpcmVj
dF9uYy4gSXMgdGhpcyBtdWx0aS1hZ2VudCBwcm90b2NvbCB0aWVkIHRvIFhlbj8NCj4NClhlbiBh
bGxvd3MgbWFwcGluZyBvbmx5IHBhZ2UgYWxpZ25lZCBjaHVua3MgYmV0d2VlbiBkb21haW5zLiBD
dXJyZW50IA0KaW1wbGVtZW50YXRpb24gc3VwcG9ydHMgb25seSBwYWdlLWFsaWduZWQgY2h1bmtz
Lg0KDQpUaGlzIG1lYW5zIHRoYXQgd2Ugc3VwcG9ydCBvbmx5IG9uZSBjaGFubmVsIHBlciBwYWdl
LCB3aGVyZSB0aGUgc2hhcmVkIA0KbWVtb3J5IHN0YXJ0cyBhdCB0aGUgYmVnaW5uaW5nIG9mIHRo
ZSBwYWdlLg0KDQoNCj4gVGhhdCBzYWlkLi4uIHAybV9tbWlvX2RpcmVjdF9uYyBpcyBhIHR5cGUg
dXNlZCBpbiB0aGUgc3RhZ2UgMiANCj4gcGFnZS10YWJsZXMgdG8gaW5kaWNhdGUgaG93IHdlIHJl
c3RyaWN0IGFjY2VzcyBmcm9tIHRoZSBkb21haW4uDQo+DQo+IFRoZSByZXN1bHRpbmcgbWVtb3J5
IGF0dHJpYnV0ZSB3aWxsIGJlIGEgY29tYmluYXRpb24gb2Ygc3RhZ2UtMSArIA0KPiBzdGFnZS0y
LiBJbiB0aGUgZnV0dXJlLCB3ZSBtYXkgZGVjaWRlIHRvIHVzZSBGV0Igd2hpY2ggd2lsbCBhbGxv
dyBYZW4gDQo+IHRvIGZvcmNlIGEgc3BlY2lmaWMgbWVtb3J5IGF0dHJpYnV0ZS4NCj4NCj4gVGhp
cyBpcyBhbHNvIHB1cmVseSBpbnRlcm5hbCBkZWNpc2lvbi4gSW4gdGhlIGRvY3VtZW50YXRpb24s
IHlvdSANCj4gc2hvdWxkIHNwZWxsIG91dCB0aGUgbWVtb3J5IGF0dHJpYnV0ZSB0aGF0IHNob3Vs
ZCBiZSB1c2VkLiBGcm9tIHRoZSANCj4gZGlzY3Vzc2lvbiBvbiB0aGlzIHBhdGNoLCBpdCBpcyBz
dGlsbCB1bmNsZWFyIHdoZXRoZXIgdGhlIHJlZ2lvbiANCj4gc2hvdWxkIGJlIG1hcHBlZCBhcyBE
ZXZpY2UgbkduUkUgb3Igbm9ybWFsIG1lbW9yeSBub24tY2FjaGVhYmwuDQo+DQo+IENoZWVycywN
Cj4NCkkgd2lsbCByZXdvcmQgdGhpcyB0byBleHBsaWNpdGx5IG1lbnRpb24gdGhlIGNvcnJlY3Qg
bWVtb3J5IGF0dHJpYnV0ZS4NCg0KRG9jdW1lbnRhdGlvbiB3aWxsIGJlIHVwZGF0ZWQuDQoNCg0K


From xen-devel-bounces@lists.xenproject.org Thu Jun 19 19:51:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 19:51:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020353.1396641 (Exim 4.92)
	(envelope-from )
	id 1uSLHh-0001BC-Hr; Thu, 19 Jun 2025 19:50:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020353.1396641; Thu, 19 Jun 2025 19: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 1uSLHh-0001B5-Eq; Thu, 19 Jun 2025 19:50:53 +0000
Received: by outflank-mailman (input) for mailman id 1020353;
 Thu, 19 Jun 2025 19:50: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 1uSLHg-0001Az-1V
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 19:50:52 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b3039c6c-4d46-11f0-a30d-13f23c93f187;
 Thu, 19 Jun 2025 21:50:50 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id CBC174ABED;
 Thu, 19 Jun 2025 19:50:48 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id AD1CBC4CEEA;
 Thu, 19 Jun 2025 19:50:47 +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: b3039c6c-4d46-11f0-a30d-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750362648;
	bh=acloxf4CADeKhC5LIwKdP81HPfEUkNlm0QXPNvuJq+0=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=JZiuFVLixLZBW/H9abA75XhatkV5HFPq5cBAzz56E+Sn7zo0MA65Cxce+p51rbe4D
	 MlL+iE/NqvaaQ8mRkf0JXl8ZdSspFYJN4qPbXWBjrg0Z1Q492sRWCWaPkpWbHrsQ1n
	 RM0wZDwpyMs+bdY7VCQTXifAVu2Z75LFtqVJA+tuk8w0HiQhFLxqyXSch+3s8YI3Aj
	 AdbOv0zLOVlHtgY4GgISVJ6sh/qTeHNfEFX4Z5dcnXqm7GJ3IaEcOAKLxZutFjLZSR
	 pexX9SfMUpRXTbEZDmMWP9L2FexvXvE6Fptkm1yr9S60SoikYx0KjxqM9CQ3Qj+dAf
	 DEkHEMWEkKuJQ==
Date: Thu, 19 Jun 2025 12:50:46 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: Stefano Stabellini , 
    xen-devel@lists.xenproject.org, Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    "Daniel P. Smith" 
Subject: Re: [PATCH v3 08/14] xen/dt: Move bootfdt functions to
 xen/bootfdt.h
In-Reply-To: 
Message-ID: 
References: <20250613151612.754222-1-agarciav@amd.com> <20250613151612.754222-9-agarciav@amd.com>  
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Thu, 19 Jun 2025, Alejandro Vallejo wrote:
> Hi,
> 
> On Sat Jun 14, 2025 at 3:16 AM CEST, Stefano Stabellini wrote:
> > On Fri, 13 Jun 2025, Alejandro Vallejo wrote:
> >> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> >> index 75017e4266..0a22b1ba1d 100644
> >> --- a/xen/include/xen/device_tree.h
> >> +++ b/xen/include/xen/device_tree.h
> >> @@ -10,6 +10,7 @@
> >>  #ifndef __XEN_DEVICE_TREE_H__
> >>  #define __XEN_DEVICE_TREE_H__
> >>  
> >> +#include 
> >>  #include 
> >
> > This should not be needed?
> 
> dt_read_number() is still needed in dt_read_paddr() in device_tree.h
> 
> I can move that helper too (makes sense, as it's strictly a wrapper) and
> add includes in whatever .c files require it (tentatively it looks like only
> static-evtchn.c. Then that include can be dropped.

Procede as you think is best. I thought it was unneeded by code
inspection, then I tried to remove it and Xen compiled okay. So I wrote
that comment. If it is needed it is also OK to keep it.


From xen-devel-bounces@lists.xenproject.org Thu Jun 19 19:56:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 19:56:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020360.1396651 (Exim 4.92)
	(envelope-from )
	id 1uSLMy-0001kt-4o; Thu, 19 Jun 2025 19:56:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020360.1396651; Thu, 19 Jun 2025 19:56: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 1uSLMy-0001km-1H; Thu, 19 Jun 2025 19:56:20 +0000
Received: by outflank-mailman (input) for mailman id 1020360;
 Thu, 19 Jun 2025 19:56: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 1uSLMw-0001kg-PL
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 19:56:18 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 758dc98b-4d47-11f0-b894-0df219b8e170;
 Thu, 19 Jun 2025 21:56:16 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 583A161132;
 Thu, 19 Jun 2025 19:56:15 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id E2501C4CEEA;
 Thu, 19 Jun 2025 19:56: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: 758dc98b-4d47-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750362975;
	bh=I4WpJOSXLuM/a+zlpTdJgDBH7ww+V9/bs5xZ0+Ebs+c=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=NJSnlbPlXWerqM6C9sPPLCLJJqMD85W4mtrIrpruG9Vb+QzNAvfFuCqh9Ogwy8zRS
	 3IZMIG80ifa0AvuWfIWblQ34rSB2uvVCq2vcfr4hFGuXDOyVJGlgchtrMuoq4DU3ih
	 TR1H3tiLTGOB2wGDVnWBOb4vaCgQ2Jxx/Tv6yes5oRRh8h6ey0+Jy7LDCQDUa3W47P
	 PFAEyVGx1uDaAiwfxZxaf5Z2DxWocozcOvqKvSPAX/yxtnlm+UqD2HdZ9uzUQ9TKk5
	 idrNrFqYhBVpdaGYX7uYXmv8NuG88Jogxz5xvTLMxrZUlWzhJsnoHDCH2gzPp5hxyv
	 z6aXsIcLuvorQ==
Date: Thu, 19 Jun 2025 12:56:12 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
cc: Ross Lagerwall , 
    Andrew Cooper , 
    Xen-devel , 
    Anthony PERARD , 
    Michal Orzel , Jan Beulich , 
    Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini , security@xen.org, 
    Juergen Gross , Trammell Hudson , 
    Frediano Ziglio , 
    Gerald Elder-Vass , 
    Kevin Lampis 
Subject: Re: [PATCH] docs: UEFI Secure Boot security policy
In-Reply-To: 
Message-ID: 
References: <20250611235851.167385-1-andrew.cooper3@citrix.com>  
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-492911436-1750362975=:1780597"

  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-492911436-1750362975=:1780597
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Thu, 19 Jun 2025, Marek Marczykowski-Górecki wrote:
> On Thu, Jun 19, 2025 at 03:16:51PM +0100, Ross Lagerwall wrote:
> > I think a section on PCI passthrough is also warranted. i.e. preventing misuse
> > of a device to exploit Secure Boot.
> 
> While I agree it makes sense, I wonder if it's in scope for UEFI
> Secure Boot as defined by Microsoft? It may have implication for example
> on PCI passthrough to a PV domains.

If we bring DomUs into the discussion, then I think we need to make a
distinction between predefined DomUs, which could have signatures
verified by Secure Boot (such as Dom0 and hyperlaunch/dom0less guests),
and other dynamically created DomUs which could be fetched from the
network and potentially started without signature verification or prior
knowledge.
--8323329-492911436-1750362975=:1780597--


From xen-devel-bounces@lists.xenproject.org Thu Jun 19 22:06:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jun 2025 22:06:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020417.1396661 (Exim 4.92)
	(envelope-from )
	id 1uSNOm-0008RN-EE; Thu, 19 Jun 2025 22:06:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020417.1396661; Thu, 19 Jun 2025 22:06:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSNOm-0008RG-Ah; Thu, 19 Jun 2025 22:06:20 +0000
Received: by outflank-mailman (input) for mailman id 1020417;
 Thu, 19 Jun 2025 22:06: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 1uSNOk-0008R7-Ea
 for xen-devel@lists.xenproject.org; Thu, 19 Jun 2025 22:06:18 +0000
Received: from fout-b3-smtp.messagingengine.com
 (fout-b3-smtp.messagingengine.com [202.12.124.146])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9dfd9caa-4d59-11f0-a30d-13f23c93f187;
 Fri, 20 Jun 2025 00:06:15 +0200 (CEST)
Received: from phl-compute-09.internal (phl-compute-09.phl.internal
 [10.202.2.49])
 by mailfout.stl.internal (Postfix) with ESMTP id 0CFCE114015A;
 Thu, 19 Jun 2025 18:06:14 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-09.internal (MEProxy); Thu, 19 Jun 2025 18:06:14 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 19 Jun 2025 18:06:10 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9dfd9caa-4d59-11f0-a30d-13f23c93f187
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=1750370773;
	 x=1750457173; bh=Lv2aLhehMFrCKH2lEb418lD3GyPQa1J2fbKakXPnBlo=; b=
	LVWSeOfL56fD0cl/tH73lFRaAUdOxLRxMuZe2p1sofK67MMd8jQykEHBkGVSbj2f
	EMHamrM7CuyIK1gJDw9ot/b3lgPNSxQlaMbvK4mHLKP1SotK/paooYr5pcVUuVjp
	xifJQ8gTlM0H7qUK0BzSJhw8Ae2u+TJMddh0O/Ld4sB/zK0yIInWe59nOpub4Bh8
	KZwjN24bYqVs8rRQLH04q7WlydfOWpimbLO8MmnMDDFB6Kf0GFtPRjZ0kwqYrOOW
	04H843nAzgc8R1CPYZ+Dlag1jp0ZTUu/Yrc2XDn/OVU6UsdA5+UlfY6XBGX2cv8H
	GVJP7IZiEUZER7pSwZB1XA==
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=
	1750370773; x=1750457173; bh=Lv2aLhehMFrCKH2lEb418lD3GyPQa1J2fbK
	akXPnBlo=; b=RbL1Vj7QkD2eLXCRCm4i07ZVbqwAbYigYSWb1alPwu6frRv/lRK
	AsxslWzlW550aCeBlIBTCtlruPXu7qHWBf8UqrB29C0hqViLQp3Wagzei+5auFgT
	iZnXoFgzoDg7T92aUD7QAPHwYCzN7gHJttUNTUjbUcPeOeYeOeVOZKPKQ6upirt/
	fAHqxzwoGIVkYP91P339M2DE/vFgL+LHrcnxm47jXYnCTm+AlIcOgtUukIjDIIt5
	Typd0StKcaaDNoQF60va9LjSbADlFI8TYJuUqOBtsbYJKUXSDcMZtJRTlOlnOSXC
	Y81Uo1Fflvtf6IMMyKWVYC0I/vOGUQPJBqA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgdeiieejucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceurghi
    lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh
    epfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcuofgr
    rhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvihhsih
    gslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfduleetfeev
    hfefheeiteeliefhjefhleduveetteekveettddvgeeuteefjedunecuvehluhhsthgvrh
    fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhv
    ihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepudehpdhmoh
    guvgepshhmthhpohhuthdprhgtphhtthhopehsshhtrggsvghllhhinhhisehkvghrnhgv
    lhdrohhrghdprhgtphhtthhopehrohhsshdrlhgrghgvrhifrghllhestghlohhuugdrtg
    homhdprhgtphhtthhopegrnhgurhgvfidrtghoohhpvghrfeestghithhrihigrdgtohhm
    pdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrd
    horhhgpdhrtghpthhtoheprghnthhhohhnhidrphgvrhgrrhgusehvrghtvghsrdhtvggt
    hhdprhgtphhtthhopehmihgthhgrlhdrohhriigvlhesrghmugdrtghomhdprhgtphhtth
    hopehjsggvuhhlihgthhesshhushgvrdgtohhmpdhrtghpthhtohepjhhulhhivghnseig
    vghnrdhorhhgpdhrtghpthhtoheprhhoghgvrhdrphgruhestghithhrihigrdgtohhm
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Fri, 20 Jun 2025 00:06:08 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Stefano Stabellini 
Cc: Ross Lagerwall ,
	Andrew Cooper ,
	Xen-devel ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	security@xen.org, Juergen Gross ,
	Trammell Hudson ,
	Frediano Ziglio ,
	Gerald Elder-Vass ,
	Kevin Lampis 
Subject: Re: [PATCH] docs: UEFI Secure Boot security policy
Message-ID: 
References: <20250611235851.167385-1-andrew.cooper3@citrix.com>
 
 
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="GZrqIEL+8NgpQS55"
Content-Disposition: inline
In-Reply-To: 


--GZrqIEL+8NgpQS55
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Fri, 20 Jun 2025 00:06:08 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Stefano Stabellini 
Cc: Ross Lagerwall ,
	Andrew Cooper ,
	Xen-devel ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	security@xen.org, Juergen Gross ,
	Trammell Hudson ,
	Frediano Ziglio ,
	Gerald Elder-Vass ,
	Kevin Lampis 
Subject: Re: [PATCH] docs: UEFI Secure Boot security policy

On Thu, Jun 19, 2025 at 12:56:12PM -0700, Stefano Stabellini wrote:
> On Thu, 19 Jun 2025, Marek Marczykowski-G=C3=B3recki wrote:
> > On Thu, Jun 19, 2025 at 03:16:51PM +0100, Ross Lagerwall wrote:
> > > I think a section on PCI passthrough is also warranted. i.e. preventi=
ng misuse
> > > of a device to exploit Secure Boot.
> >=20
> > While I agree it makes sense, I wonder if it's in scope for UEFI
> > Secure Boot as defined by Microsoft? It may have implication for example
> > on PCI passthrough to a PV domains.
>=20
> If we bring DomUs into the discussion, then I think we need to make a
> distinction between predefined DomUs, which could have signatures
> verified by Secure Boot (such as Dom0 and hyperlaunch/dom0less guests),
> and other dynamically created DomUs which could be fetched from the
> network and potentially started without signature verification or prior
> knowledge.

I think it's mostly not about what's running inside domU, but what such
domU has access to. The obvious part is enforcing IOMMU configuration so
that domU cannot use a PCI device as a proxy to modify hypervisor (or
dom0) code. But there may be more subtleties like access to specific
devices (HECI? SPI?).
Anyway, lets figure out first _if_ we need to do something about this
topic, and only then worry how.

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

--GZrqIEL+8NgpQS55
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmhUidAACgkQ24/THMrX
1yy22wf/b2wtFSSYA6Wt+PTLYpYQS1Xemzob98nMgG+elbiydA0My9XEDtITxu7B
q4OA27+PaOdINBcBjYkeV1ABYTicScjyFSFFQHsW5si8ftZ33tqqLyeA75wVBcq3
KPPDjuLpNLE57JvauXiXcKUxge/jJOvN7FxLRZRDvt+qQxpoWQqr8mC3A/vWtMGF
BU+UzPmrHRASFFmDS14P/umR4vqIRY5HIzs3fk4cb7Sl/QBSRk9kSsh3zkslGyRp
I0S5JTRnK/2jtXPh+SogS5rPCdHfzam0TxAWT7YzpMA52nmLYNEK9XCyxcd15M5x
z19DLoDzT885vNmnuWMN6LL2lxRwLw==
=gZag
-----END PGP SIGNATURE-----

--GZrqIEL+8NgpQS55--


From xen-devel-bounces@lists.xenproject.org Fri Jun 20 00:36:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 00:36:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020463.1396670 (Exim 4.92)
	(envelope-from )
	id 1uSPk1-0001Ta-5E; Fri, 20 Jun 2025 00:36:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020463.1396670; Fri, 20 Jun 2025 00:36:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSPk1-0001TT-2U; Fri, 20 Jun 2025 00:36:25 +0000
Received: by outflank-mailman (input) for mailman id 1020463;
 Fri, 20 Jun 2025 00:36:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uSPjz-0001TN-8e
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 00:36:23 +0000
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [160.30.148.35])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 92bc29be-4d6e-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 02:36:18 +0200 (CEST)
Received: from mse-fl2.zte.com.cn (unknown [10.5.228.133])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by mxhk.zte.com.cn (FangMail) with ESMTPS id 4bNdnR5NBzz8RVF5;
 Fri, 20 Jun 2025 08:36:11 +0800 (CST)
Received: from xaxapp02.zte.com.cn ([10.88.97.241])
 by mse-fl2.zte.com.cn with SMTP id 55K0ZNLI087195;
 Fri, 20 Jun 2025 08:35:23 +0800 (+08)
 (envelope-from jiang.peng9@zte.com.cn)
Received: from mapi (xaxapp02[null]) by mapi (Zmail) with MAPI id mid31;
 Fri, 20 Jun 2025 08:35:24 +0800 (CST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 92bc29be-4d6e-11f0-b894-0df219b8e170
Date: Fri, 20 Jun 2025 08:35:24 +0800 (CST)
X-Zmail-TransId: 2afa6854acccffffffffe61-b190f
X-Mailer: Zmail v1.0
Message-ID: <20250620083524585H-Y-shkbXkJSd-9if1hTB@zte.com.cn>
In-Reply-To: <0f535bed-f4d4-4565-8f21-b10070f793e8@suse.com>
References: 20250618100153468I5faNUAhCdtMA01OuuTKC@zte.com.cn,0f535bed-f4d4-4565-8f21-b10070f793e8@suse.com
Mime-Version: 1.0
From: 
To: 
Cc: , ,
        , ,
        , 
Subject: =?UTF-8?B?UmU6IFtQQVRDSF0geGVuL3hlbmJ1czogZml4IFc9MSBidWlsZCB3YXJuaW5nIGluIHhlbmJ1c192YV9kZXZfZXJyb3IgZnVuY3Rpb24=?=
Content-Type: text/plain;
	charset="UTF-8"
X-MAIL:mse-fl2.zte.com.cn 55K0ZNLI087195
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 6854ACFB.003/4bNdnR5NBzz8RVF5

> I'm fine with the changes as such, but please send the patch as a
> plain text email (no HTML). Otherwise I'm not able to apply it.
>
> You should look into Documentation/process/email-clients.rst in the
> kernel source tree.

My sincere apologies for the HTML format issue. Thank you for your patience and for pointing me to the email guidelines  - I truly appreciate the guidance.
I'll resend the patch immediately as a plain text email to ensure it can be properly applied.

Thank you again for your understanding and for taking the time to review this.

Best regards
Peng


From xen-devel-bounces@lists.xenproject.org Fri Jun 20 00:42:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 00:42:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020470.1396681 (Exim 4.92)
	(envelope-from )
	id 1uSPpX-000311-Ny; Fri, 20 Jun 2025 00:42:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020470.1396681; Fri, 20 Jun 2025 00:42: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 1uSPpX-00030u-LL; Fri, 20 Jun 2025 00:42:07 +0000
Received: by outflank-mailman (input) for mailman id 1020470;
 Fri, 20 Jun 2025 00:42: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 1uSPpW-00030o-BB
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 00:42:06 +0000
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [160.30.148.34])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 617035be-4d6f-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 02:42:04 +0200 (CEST)
Received: from mse-fl2.zte.com.cn (unknown [10.5.228.133])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by mxhk.zte.com.cn (FangMail) with ESMTPS id 4bNdw70kn4z5DXWg;
 Fri, 20 Jun 2025 08:41:59 +0800 (CST)
Received: from xaxapp05.zte.com.cn ([10.99.98.109])
 by mse-fl2.zte.com.cn with SMTP id 55K0f4Ic094365;
 Fri, 20 Jun 2025 08:41:04 +0800 (+08)
 (envelope-from jiang.peng9@zte.com.cn)
Received: from mapi (xaxapp05[null]) by mapi (Zmail) with MAPI id mid31;
 Fri, 20 Jun 2025 08:41:04 +0800 (CST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 617035be-4d6f-11f0-b894-0df219b8e170
Date: Fri, 20 Jun 2025 08:41:04 +0800 (CST)
X-Zmail-TransId: 2afc6854ae20ffffffffd83-7c389
X-Mailer: Zmail v1.0
Message-ID: <20250620084104786r5xoR16_AmYZMJLnno3_Q@zte.com.cn>
In-Reply-To: <0f535bed-f4d4-4565-8f21-b10070f793e8@suse.com>
References: 20250618100153468I5faNUAhCdtMA01OuuTKC@zte.com.cn,0f535bed-f4d4-4565-8f21-b10070f793e8@suse.com
Mime-Version: 1.0
From: 
To: 
Cc: , ,
        , ,
        , 
Subject: =?UTF-8?B?UmU6IFtQQVRDSCB2Ml0geGVuL3hlbmJ1czogZml4IFc9MSBidWlsZCB3YXJuaW5nIGluIHhlbmJ1c192YV9kZXZfZXJyb3IgZnVuY3Rpb24=?=
Content-Type: text/plain;
	charset="UTF-8"
X-MAIL:mse-fl2.zte.com.cn 55K0f4Ic094365
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 6854AE57.000/4bNdw70kn4z5DXWg

From: Peng Jiang 

This patch fixes a W=1 format-string warning reported by GCC 12.3.0
by annotating xenbus_switch_fatal() and xenbus_va_dev_error()
with the __printf attribute. The attribute enables compile-time
validation of printf-style format strings in these functions.

The original warning trace:
drivers/xen/xenbus/xenbus_client.c:304:9: warning: function 'xenbus_va_dev_error' might be
a candidate for 'gnu_printf' format attribute [-Wsuggest-attribute=format]

Signed-off-by: Peng Jiang 
---
 drivers/xen/xenbus/xenbus_client.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index 51b3124b0d56..e73ec225d4a6 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -202,6 +202,7 @@ int xenbus_watch_pathfmt(struct xenbus_device *dev,
 }
 EXPORT_SYMBOL_GPL(xenbus_watch_pathfmt);

+__printf(4, 5)
 static void xenbus_switch_fatal(struct xenbus_device *, int, int,
                                const char *, ...);

@@ -287,6 +288,7 @@ int xenbus_frontend_closed(struct xenbus_device *dev)
 }
 EXPORT_SYMBOL_GPL(xenbus_frontend_closed);

+__printf(3, 0)
 static void xenbus_va_dev_error(struct xenbus_device *dev, int err,
                                const char *fmt, va_list ap)
 {
-- 
2.25.1


From xen-devel-bounces@lists.xenproject.org Fri Jun 20 05:55:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 05:55:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020547.1396691 (Exim 4.92)
	(envelope-from )
	id 1uSUj1-0004Lr-A1; Fri, 20 Jun 2025 05:55:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020547.1396691; Fri, 20 Jun 2025 05:55:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSUj1-0004Lj-51; Fri, 20 Jun 2025 05:55:43 +0000
Received: by outflank-mailman (input) for mailman id 1020547;
 Fri, 20 Jun 2025 05:55: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 1uSUiz-0004Ld-IZ
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 05:55:41 +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 31424b9e-4d9b-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 07:55:39 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3a582e09144so956514f8f.1
 for ; Thu, 19 Jun 2025 22:55:39 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-7490a628156sm1196238b3a.103.2025.06.19.22.55.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 19 Jun 2025 22:55:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 31424b9e-4d9b-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750398939; x=1751003739; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=huFiJS4prfytDKetwX3HkCXZJNR5J6F0RiYxcK507vY=;
        b=UQ1MQDPWiKMCKnM1veokR//ecRmecp2rEYh/OewS80xPEm/nkt4CHHCA+fkzZn6MCX
         rdKBk2HbArDLe5T8EwjIcyrYtYuDcVY52EutyZbtodgVJdDnaqA991c7aEWjJMdacd/l
         8xEASPpooMFcBIXjF/vBP/eRGqV7Q/v1F6D9ZWyPLl+m7XmJt/o81h3vFZwrpAl2DJW3
         9HYD0lOzBM75Ch2din4dujUECctnFD/zim2FPdRjyYj71g1t/F0zBcS2xr0r3Cpq9OL1
         N/v3T98qxhxzkANFMou9WFRP0P6tkGhFrnAIGwm1UMbhvEsTeqxKPumH4JLxXTyT9+zd
         e0PQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750398939; x=1751003739;
        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=huFiJS4prfytDKetwX3HkCXZJNR5J6F0RiYxcK507vY=;
        b=cMuoDegKO7xB5Pvor6TWlZlKhcRqTtFdZlMn77fBFh94a/hfqZXNBvbuPtaa1/g2Uk
         1WUmB/orccwU2iqjgQCHS/Qcpsky6wMDv8FLm+ginqqZowRrMiCbiKxetXiFIkSYCqpK
         7NM2IgYfkmIbofccL9PJD+A1gHKEgCGlTBu/UAb4qL8/nQilyrB904U+gSA1BFq4ksGe
         92j/+34mrBVNZA3S8SE7XRMocWtzNmcQUZ1o8cIfhEOcHXZSeFrYAhjTjPqMPydz+Uvq
         8JhLxWCQM8Qhau2O14hS0dsYS4J8M4pUtGQ6GTKjqGzssiiZZezJAX9opnSxUWB6/U/U
         4rtQ==
X-Forwarded-Encrypted: i=1; AJvYcCVLoHjwJRpg1vrgoclCJIbl+MOdJIU5phU8G3HkqOYfKR3p1G5xW6NoJ89hws0uTIcgyaKGFHnOuoI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxKCAPNeK5xP7VfZmUigyTMfMemcLOH/dXnmPBYSnrB874kG7aP
	Mhu6DDI8sG4k26OgI3/rJ+7cs2B6W159t77KIaU3I664CA6MzsIJkCm6l79R/oNRkA==
X-Gm-Gg: ASbGnculB/3ehloNG4yrGkRdFBFkva87vEkgo1ZzznNX6YcAOgzAKYJtG/jYzPr8dhc
	7hPtyO5dBCMvCmaNX2BKCfwVjqeDhgp4lpqtcQ3TPAlfcB7Y+R+2ORuPKN2GfBycYAwAvaikYZf
	nIPKYv5ogqnXhR8qGV2xSieGzwIE2fQCSRmRs755PGNxeEbXJY3W+P/gGragv7NbJcDlEsvZk9O
	qT2Ll/UmOcCOfBGhFWRiNhgQQuSv8eFzqFVByETyfIfFuqY2Pq3Qu4nbsfN7JS3o2zoHLQyxY4Y
	86HGz9kRCaxLwPWLFI9XGluYWnHBV5nq1bmcEzI8cqolDU/RsfZ7BA1YDAx6Z01W2SOuH2wiOGZ
	rQ0YUN3yOclCRwGXe7pfMrEPt11ICFVyvIWBQwfWwi5W6tL8=
X-Google-Smtp-Source: AGHT+IElxzQcXrnQeDkhcQ6jmrx5M+2pbPw6DdODZHtfEjPbPr0AvzsVyTKsilX4TZ+e+ew3a9fqOg==
X-Received: by 2002:a05:6000:248a:b0:3a4:f5f6:b4ab with SMTP id ffacd0b85a97d-3a6d13044dfmr954468f8f.30.1750398938871;
        Thu, 19 Jun 2025 22:55:38 -0700 (PDT)
Message-ID: <3f0a1d9f-51e6-4203-ba49-5f346640e43e@suse.com>
Date: Fri, 20 Jun 2025 07:55:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 04/18] xen/cpufreq: introduce new sub-hypercall to
 propagate CPPC data
To: "Penny, Zheng" 
Cc: "Huang, Ray" ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 "Orzel, Michal" , Julien Grall ,
 Stefano Stabellini ,
 "xen-devel@lists.xenproject.org" 
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-5-Penny.Zheng@amd.com>
 <0de0ea5c-64c9-4ac8-8e76-750cb3036419@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.06.2025 08:43, Penny, Zheng wrote:
> [Public]
> 
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Thursday, June 12, 2025 12:10 AM
>> To: Penny, Zheng 
>> Cc: Huang, Ray ; Andrew Cooper
>> ; Roger Pau Monné ;
>> Anthony PERARD ; Orzel, Michal
>> ; Julien Grall ; Stefano Stabellini
>> ; xen-devel@lists.xenproject.org
>> Subject: Re: [PATCH v5 04/18] xen/cpufreq: introduce new sub-hypercall to
>> propagate CPPC data
>>
>> On 27.05.2025 10:48, Penny Zheng wrote:
>>> @@ -635,6 +641,124 @@ out:
>>> --- a/xen/include/public/platform.h
>>> +++ b/xen/include/public/platform.h
>>> @@ -363,6 +363,7 @@ DEFINE_XEN_GUEST_HANDLE(xenpf_getidletime_t);
>>> +struct xen_processor_cppc {
>>> +    uint8_t flags; /* flag for CPPC sub info type */
>>
>> A common way of commenting on such would be /* XEN_CPPC_... */.
>>
>> In any event, here and ...
>>
>>> +    uint8_t pad[3]; /* padding and must be zero */
>>
>> ... here (and of course anywhere else) - please adhere to designated comment
>> style.
> 
> Apart from Capital for the first letter, do designated comment style include
> format like: IN/OUT: xxx?

Comment style applies everywhere; the IN/OUT annotations in public headers are
generally desirable to have imo, yet for a padding field I'm not quite seeing
a need for such (if the caller passes in zeroes, the field will stay zeroed
unless the hypervisor actively altered the contents; IOW such fields simply
need to be zero at all times).

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jun 20 06:01:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 06:01:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020554.1396700 (Exim 4.92)
	(envelope-from )
	id 1uSUom-00060X-Ph; Fri, 20 Jun 2025 06:01:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020554.1396700; Fri, 20 Jun 2025 06:01:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSUom-00060Q-Mu; Fri, 20 Jun 2025 06:01:40 +0000
Received: by outflank-mailman (input) for mailman id 1020554;
 Fri, 20 Jun 2025 06:01: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 1uSUol-00060K-Kl
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 06:01:39 +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 0637daa1-4d9c-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 08:01:36 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3a50956e5d3so1197342f8f.1
 for ; Thu, 19 Jun 2025 23:01:37 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-7490a46b071sm1206158b3a.33.2025.06.19.23.01.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 19 Jun 2025 23:01:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0637daa1-4d9c-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750399296; x=1751004096; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=4XxbcB49y/2OkJdJbJfvewYz5lPjPV7Fj2tZ9BgYDYs=;
        b=CMWb8Jm0leR97Kw4Da+B0B3K5+WJfoTVS9rK75DAIJE9W4B66c19fu/TzMEwCp1Fnc
         WG3CEXIuPdIpgUdX+41xip2FNcQktpx5r/Qjr5FCy5jKzTQPg1bEsSNJGM5cXoTinp/r
         pNPdMAx41+Asc3I+erruHpFenApI/1ykhmaFxxOC2fVKdx98N22iZbw7YUz09TAdHrhQ
         lfMVvSSO1sE0tOyoqk7E3hDvWzK2XajkAnMkw0t3qW4U8fdHtKwzuRSh88semdltbB5/
         ZZvbK886FYve8RCR91Dvx8cscTLfLVxN168wfSj6PPeXvgyH9x+imXTqPfZe1phK/BPT
         uZyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750399296; x=1751004096;
        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=4XxbcB49y/2OkJdJbJfvewYz5lPjPV7Fj2tZ9BgYDYs=;
        b=CvoJuasvaKEesIxT2IbdECriKUUULvT6350y3OhURjZaMEvZabF+ghJhsEkw23054+
         eXm/q/Vw+U/bzriUX/8UtEUdgGkHGnR/HG69osyPbRgJtm541lU7+Z43dqP0KGnl3faL
         ICPrddudVDVhQvik8IBj4w273UihXOJSSf/6SYxjPAURvM08EWIyoC+gGRDm1E9F4sLI
         Dq8gkYX4nie/lXSv2Ks4zge62iiPK6YPJ8lbNWd4svQf34o9TSq5/iEYAZi+G+CdfrjX
         wvnvDL+wd3rXaNifFrEwxfC5XkzpStoyq+5xwAqQiR30HZILwH5BQMZd/CozVUU7acbm
         uccw==
X-Forwarded-Encrypted: i=1; AJvYcCVhziMaQptUqQ7zFRvw9X4Q7a+e/47dFsbScjPo/foA1SAedxLq1mFfB6j8NrqvLIn7lnuE982UP6I=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw+7cB9AgTcn9mj+PhBUCaOYcEJDP6J6hRbasfIiwJ8jvI7+i5V
	uXDXRcVOjbXJ+s1DRjIG03LNKYruM+HlEt8BMNVEh6r5LEV3VXOguuG6CniI/RVQUg==
X-Gm-Gg: ASbGncvL31BnVwTWJSQS0TaCSiPQRABUsImb6Yg+Qzdw666SIDVFLf4jQm/2jonP2BC
	bknIQKJ9DZk0gIf6o5HWaZoSP70GgDa/mpinQyWAjETSA27Np5W080astVZGw6L9fuTSB93RNO4
	VZ3igILiimwfMA2zRdVMdg6odygF6bdwrZK8VuglosK5/ZrFynmGtnSH7kUDiL/kwrpmYiKM9ab
	4zCJOMrDNM+A6hP20xlo+OwVrGtej1St5uFWue1Gayl3co62ldaJfpMhSvQg9hHBfoqZNtYj6cA
	UKlYU3fm7pAeuMcwaQonWJNheq02AWiGFJbuu/TWZW0lv4SYKrClz3WHBhMUzh6CjtF80rbHm4V
	ycTVT8BiI83bJwwhT5K69Hnfw4KCgHn3cadzIl+Ahmqa/96I=
X-Google-Smtp-Source: AGHT+IHrUed61YY+nAbuKwCu3tWSiHvtsgLBZ1N73VasCzFqopCeuSMx8vFnbY+bIHRdRvXzjv8KZg==
X-Received: by 2002:adf:9c8c:0:b0:3a4:f7af:db9c with SMTP id ffacd0b85a97d-3a6d1318226mr994551f8f.59.1750399296119;
        Thu, 19 Jun 2025 23:01:36 -0700 (PDT)
Message-ID: 
Date: Fri, 20 Jun 2025 08:01:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 06/18] xen/x86: introduce "cpufreq=amd-cppc" xen
 cmdline
To: "Penny, Zheng" 
Cc: "Huang, Ray" ,
 Andrew Cooper ,
 Anthony PERARD ,
 "Orzel, Michal" , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 "xen-devel@lists.xenproject.org" 
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
 <20250527084833.338427-7-Penny.Zheng@amd.com>
 <3edeeff2-5728-46cc-9436-01e5e3cf2bd3@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.06.2025 10:43, Penny, Zheng wrote:
> [Public]
> 
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Thursday, June 12, 2025 6:42 PM
>> To: Penny, Zheng 
>> Cc: Huang, Ray ; Andrew Cooper
>> ; Anthony PERARD ;
>> Orzel, Michal ; Julien Grall ; Roger Pau
>> Monné ; Stefano Stabellini ; xen-
>> devel@lists.xenproject.org
>> Subject: Re: [PATCH v5 06/18] xen/x86: introduce "cpufreq=amd-cppc" xen
>> cmdline
>>
>> On 27.05.2025 10:48, Penny Zheng wrote:
>>> --- a/xen/arch/x86/platform_hypercall.c
>>> +++ b/xen/arch/x86/platform_hypercall.c
>>> @@ -94,6 +95,8 @@ static int __init handle_cpufreq_cmdline(enum
>>> cpufreq_xen_opt option)  {
>>>      int ret = 0;
>>>
>>> +    /* Do not occupy bits reserved for public xen-pm */
>>> +    BUILD_BUG_ON(MASK_INSR(XEN_PROCESSOR_PM_CPPC,
>> SIF_PM_MASK));
>>
>> This looks like an abuse of MASK_INSR(). Why not simply
>>
>>     BUILD_BUG_ON(XEN_PROCESSOR_PM_CPPC & SIF_PM_MASK);
>>
>> ?
> 
> Because in SIF_PM_MASK, it's bit 8 to 15 reserved for xen-pm options,
> See "
> #define SIF_PM_MASK       (0xFF<<8) /* reserve 1 byte for xen-pm options */
> "
> So I'm trying to use MASK_INSR() to do the necessary right shift (other than using 8 directly, in case SIF_PM_MASK changes in the future...)

Oh, right, so my replacement suggestion was wrong. But XEN_PROCESSOR_PM_CPPC
isn't contained within the 8 bits. MASK_INSR() could conceivably have a
(debug) check that the passed value actually fits the mask.

     BUILD_BUG_ON(XEN_PROCESSOR_PM_CPPC & MASK_EXTR(~0, SIF_PM_MASK));

?

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jun 20 06:05:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 06:05:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020563.1396711 (Exim 4.92)
	(envelope-from )
	id 1uSUsa-0006a8-AF; Fri, 20 Jun 2025 06:05:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020563.1396711; Fri, 20 Jun 2025 06:05: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 1uSUsa-0006a1-6S; Fri, 20 Jun 2025 06:05:36 +0000
Received: by outflank-mailman (input) for mailman id 1020563;
 Fri, 20 Jun 2025 06:05: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 1uSUsY-0006Zk-3i
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 06:05:34 +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 92ed04a3-4d9c-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 08:05:32 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3a4f71831abso1230233f8f.3
 for ; Thu, 19 Jun 2025 23:05:32 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3159df71ec2sm973411a91.6.2025.06.19.23.05.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 19 Jun 2025 23:05:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 92ed04a3-4d9c-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750399532; x=1751004332; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Gkd41WsjguVOu2NBDtKwFOEZdFlvEA2btEl/Afg5iyw=;
        b=e0GTSXgb+q4QUuAEkKTmjQd68oVe8B0QEi39SIpmXVAnWQAE9Y9hSYD6Eo5YsKTOgo
         bY56NHcUESun6qQZlknvfwS8SFmyr7l9RMl/tQ1hBIzf+jBkOHzwJwYvF5SUtsbXj1ji
         cIu4231Rds/nirJZvM8lisLCttJKRThzFe6nfUcZhjH1bzZr07UqMMShkmC8cTYjxc7b
         b5OvSxab287V4NzkifIHZADwTUo7Kf1UbfS6ueUUhdjpDuJK3KE4Bb8U3APkgaQROGI5
         Bpv/lzjrpzofWrmZKxID2GLSRUVenrWinqCPb4CWMqFu6OacOMng1Wzw5hRO/DbLcHIL
         xODA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750399532; x=1751004332;
        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=Gkd41WsjguVOu2NBDtKwFOEZdFlvEA2btEl/Afg5iyw=;
        b=vqYqwetEevaTDtDF+e7bOYFjLXmKVN0gyLynJ/gabKTrLVq126Fmqq1KTveGs60/xq
         wQFgMKB1wmrCMQWwzW3ZlMJ6SV8WwC9PteqqvjHQ0SObIZu6rP39whM23Rc0i0cZjVqN
         AD9HskjelljNphYIJETO9aSC0x8Qq7W945B0zGs/V4vV2Jm5iTasSsGeD8cYFWRlc+c8
         uze5EN9x+4E41OgRoV9JU+VkgLgPDlwZIv+MbDGBpsPU7ZVv6VqmeiJTZasxzGq5lb8d
         rIJSVlu6zXHY0P54PrSDBx521AL0MNifihgEVcI1/eIALWc3X+B5AmB5qM0LUCqU3IXH
         uC2A==
X-Forwarded-Encrypted: i=1; AJvYcCVKKvoY0ISZf5e1lkyUksSYnie0nirUQwB2ID50usPqyzmXYaHpxgn+DJElFQt5DGbwnA/5+VEv2gA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzdrgT68yG3cdYPkcUkvJ8qlB17LkNiirnZZJ8mpi+Ol70mWumU
	+SdxbPNxqUydE9YiLYMfWMVWhxOhuaOe059Wv9p+fvEeDLmsHZaU6+hGZxNT72cI8w==
X-Gm-Gg: ASbGncuL1fsWEoRJS+ijPkYKI3su5fGuJ9w1+bBDXmLnHDacXVg8br9RdX6bIY4bT+J
	kvSnbA98908fygV4IRNAQbTeYFrO0GbLP2SszK+4jolExuBD/7ey3sL955QkR5navMHel+5A6VB
	wof5C1xTUKghtUS66VQ0kb5ZBVIYb7L7nq1gVm8poHw9skwt54rb1w63z9DNW0RztQl9mUtfXSy
	w7Qm5T3hf8l3zKiX2ZK2pMMcQDsdLfI0woLb6DGd/Xc/AqtFJ0rDsH2Ss94w3wTgoPfgWOw6rmn
	cXuqx/ExxeTiIu6nHr5Mk0wvXy/XsYQgKpFUnQc4DDKM0qXVQrULuqWhsaGU59gPRxOXcqY5Q0D
	KvXedXoVW1VzgQQYNNMlAQT16XCwrXvLvv2Mj950qF16S8zs=
X-Google-Smtp-Source: AGHT+IHalWilCAQ8KI+kC57rKAF8fU8rIBDI3WLdoZh2xD1PCb6NaIWRHG9wUL1G72Rd+QxXM+sr2A==
X-Received: by 2002:a05:6000:41d2:b0:3a4:d994:be4b with SMTP id ffacd0b85a97d-3a6d12c4551mr1076200f8f.1.1750399531847;
        Thu, 19 Jun 2025 23:05:31 -0700 (PDT)
Message-ID: <88bb4934-014b-4710-9e81-5697255cc626@suse.com>
Date: Fri, 20 Jun 2025 08:05:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 4/4] xsm/dummy: Allow hwdom SYSCTL_readconsole/physinfo
To: Stefano Stabellini 
Cc: Jason Andryuk ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org
References: <20250610225737.469690-1-jason.andryuk@amd.com>
 <20250610225737.469690-5-jason.andryuk@amd.com>
 <5f6d43da-2600-4c1c-9bcb-f13e8fce921e@suse.com>
 
 
 
 
 <5645e4dc-7598-414d-a2b5-39066401e9b3@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 19.06.2025 02:36, Stefano Stabellini wrote:
> On Tue, 17 Jun 2025, Jan Beulich wrote:
>> On 17.06.2025 02:10, Stefano Stabellini wrote:
>>> On Mon, 16 Jun 2025, Jan Beulich wrote:
>>>> On 14.06.2025 00:51, Stefano Stabellini wrote:
>>>>> On Wed, 11 Jun 2025, Jason Andryuk wrote:
>>>>>> On 2025-06-11 09:27, Jan Beulich wrote:
>>>>>>> On 11.06.2025 00:57, Jason Andryuk wrote:
>>>>>>>> Allow the hwdom to access the console, and to access physical
>>>>>>>> information about the system.
>>>>>>>>
>>>>>>>> xenconsoled can read Xen's dmesg.  If it's in hwdom, then that
>>>>>>>> permission would be required.
>>>>>>>
>>>>>>> Why would xenconsoled run in the hardware domain? It's purely a software
>>>>>>> construct, isn't it? As a daemon, putting it in the control domain may
>>>>>>> make sense. Otherwise it probably ought to go in a service domain.
>>>>>>
>>>>>> My approach has been to transform dom0 into the hardware domain and add a new
>>>>>> control domain.  xenconsoled was left running in the hardware domain.
>>>>>
>>>>> I think we should keep xenconsoled in the hardware domain because the
>>>>> control domain should be just optional. (However, one could say that with
>>>>> Denis' recent changes xenconsoled is also optional because one can use
>>>>> console hypercalls or emulators (PL011, NS16550) for all DomUs.)
>>>>>
>>>>>
>>>>>
>>>>>> I suppose it could move.  Maybe that would be fine?  I haven't tried. The
>>>>>> Hyperlaunch code populates the console grants to point at the hardware domain,
>>>>>> and I just followed that.
>>>>>>
>>>>>> One aspect of why I left most things running in the Hardware domain was to not
>>>>>> run things in the Control domain.  If Control is the highest privileged
>>>>>> entity, we'd rather run software in lower privileged places. Especially
>>>>>> something like xenconsoled which is receiving data from the domUs.
>>>>>
>>>>> Yes, I agree with Jason. It is a bad idea to run xenconsoled in the
>>>>> Control Domain because the Control Domain is meant to be safe from
>>>>> interference. We want to keep the number of potential vehicles for
>>>>> interference down to a minimum and shared memory between Control Domain
>>>>> and DomUs is certainly a vehicle for interference.
>>>>
>>>> As much as it is when xenconsoled runs in the hardware domain? Especially
>>>> if the hardware domain is also running e.g. PV backends or qemu instances?
>>>
>>> It looks like you are thinking of the possible
>>> interference from the Hardware Domain to the Control Domain via
>>> xenconsoled, correct?
>>
>> More like interference with the system as a whole, which simply includes
>> Control.
>>
>>> If that is the case, good thinking. I can see that you have really
>>> understood the essence of the problem we are trying to solve.
>>>
>>> That is not an issue because the Control Domain shouldn't use PV
>>> console. Instead, it should use the console hypercall, or the
>>> PL011/NS16550 emulators in Xen.
>>
>> Well. I think the underlying concept of Control Domain being highly
>> privileged needs more general discussion. As indicated elsewhere, I
>> didn't think disaggregation (whichever way done) would leave any
>> domain with effectively full privilege. I wonder what others think.
> 
> Keep in mind that the threat model here is different from the
> datacenter. 
> 
> But the Control Domain is optional. If the user doesn't want it, the
> user can avoid it.
> 
> Even on a fully static system (no VM creation), it is convenient to have
> a domain that can monitor the others and trigger domain reset (we are
> reimplementing domain reboot to be more like a soft reset so that the VM
> doesn't need to be destroyed and recreated).

Suggesting that in such an environment Control should have no permission
to create domains. This would avoid various threats, including e.g.
massive amounts of dynamic memory allocation.

> As an example, the Control
> Domain could be used to monitor a non-safe domain such as Android,
> detect an Android crash, and trigger an Android reboot.

Yet at the same time it would have to be prevented from interfering with
any of the critical domains.

Altogether this doesn't sound like "highest privilege" to me then.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jun 20 06:07:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 06:07:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020577.1396721 (Exim 4.92)
	(envelope-from )
	id 1uSUuN-0007AO-Mu; Fri, 20 Jun 2025 06:07:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020577.1396721; Fri, 20 Jun 2025 06:07:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSUuN-0007AH-Jm; Fri, 20 Jun 2025 06:07:27 +0000
Received: by outflank-mailman (input) for mailman id 1020577;
 Fri, 20 Jun 2025 06:07: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 1uSUuN-0007AB-3q
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 06:07:27 +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 d60bf187-4d9c-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 08:07:25 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3a57c8e247cso1278612f8f.1
 for ; Thu, 19 Jun 2025 23:07:25 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d86518b2sm9481185ad.152.2025.06.19.23.07.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 19 Jun 2025 23:07:23 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d60bf187-4d9c-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750399644; x=1751004444; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=SA1FPn6AKM8E0dtTkAunz+/79tKrkDFOEgS2rFJshjo=;
        b=GZxo+J0fTeD+Mc+6X4oNOsBAjKG7RyFouNauhO6Jy+Xg511a0WPeVUn1hEaS2iErv3
         tMJTdJJzYPd0tg0sM6fZHYG3lrYqHDCkQMhym/eGojLWSjkZV8o7rEaCSqAW2wtVLXpX
         5bzV76oIDnEnUyxmPsLa/Sq1so0i3J4F+8n4ZQ6zIHJonSxyc7tQvWdv8/IJsdv0J7rE
         Otx6uZ7RepoRRWyNCQxs9tucnzgB7TwDCg0sc5R7ZkigyNNhOk7QUUNa8NGhUEdi8Tm9
         s6ylnNIFcrBjsFuf/Zl319OS0Fxd2vJ6GXTusTKbTzVROaomMOFg/XsNkvema9SYr+FG
         vEnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750399644; x=1751004444;
        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=SA1FPn6AKM8E0dtTkAunz+/79tKrkDFOEgS2rFJshjo=;
        b=s182HMhaAxpswEzfDNyuHtJXbxYgIibOctbev5HeYFYePHaDXpP5yje8Ds7m8Il62A
         3fu1SMFzm67uOyNZAt+H2I0lsEQ5ni8VaMM4JR5Bq2JRQBOgtDeDPiEo6tYtGEvDe5iw
         4nfvefPWz3XNS6WEHjjAAODIJ6Dt5mkbtjFaPsYG0QBUKQh4zvAHjyKKvuBc9vygejB1
         JIq1V1GTa+KzLXLmD+HwbhgyJoePiRoT9/o0IqnQg1OZDmfjcUsdDuKzoeLskprq8DL6
         WdWhFpi/6sd0CwI9pFoiZNKLdZKABtJxW2YJ3PDhmfsN9j7esx2v7zjz8epUedlSkHD1
         SxnQ==
X-Forwarded-Encrypted: i=1; AJvYcCVXxYoNiKFTyWLDdBL6iJnzPXUCmV6pbviFpOgmW0Ud+Y56LjID6qY0bd8FZzFQ0oLsXyzW9zhNNQA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy3e+2/G+K8jZXrFBm0m8FWYVjMco4sTXFTTEEfYVAA09J7d3jo
	MTN4gBYOGiJGa4yDUysa32NGhwK8808hkecANil80VId6f1B6hPQ6AI+k3Ayo+nF4w==
X-Gm-Gg: ASbGncshA23m0Am9uEnXa4FYQkZ2ts8NT82Vt0IJ+XR4x2GjLcQbsTJWFx6xfftzx/6
	Q4/ywGjN05O21iyHBpxS7Cisuds1x80/kcQfunEC0JOsxzO0rBjZNWE0ZPga/x/aamclyTr3GMx
	6fqmn/LBXSRcVXRIq47piy6xCJprvwytL7U7ZLZYef21wN5yaaDiXxBo5uiYHzxNv3GvfheELmD
	AAT6SjXso6WaUUkP/LonWmqte0clPHflyK02zEQcy8sUGpCwssNwG9uuyx5V13d+4Ek7hVvQD0g
	wHS5AaHc6LU6QGVbC6kycyM4dkCASnKjNwljrcDp+IF2bG1Ea5GgxhEVqHSfDNjUdgKLNlRGnFO
	XcjtoDzvhyM6NUlRmDaazXj7caG6P5GRe4GjnXTSFEDDUZKk=
X-Google-Smtp-Source: AGHT+IHSx8XGwumblfyI4FHK6xe9nojpydZbH66fLatZ2pTtVaSux5TljF7AuyH+q7fipfIj64gU/w==
X-Received: by 2002:a05:6000:290d:b0:3a5:2848:2445 with SMTP id ffacd0b85a97d-3a6d12e3666mr1054832f8f.16.1750399644313;
        Thu, 19 Jun 2025 23:07:24 -0700 (PDT)
Message-ID: <15db8155-3d3d-41e9-92be-957067a34e5f@suse.com>
Date: Fri, 20 Jun 2025 08:07:13 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/2] xen/console: unify printout behavior for UART
 emulators
To: Stefano Stabellini 
Cc: dmkhn@proton.me, andrew.cooper3@citrix.com, anthony.perard@vates.tech,
 julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com,
 dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250606201102.2414022-1-dmukhin@ford.com>
 <20250606201102.2414022-3-dmukhin@ford.com>
  
 
 
 
 
 <2f726960-4bdc-4996-b204-722c0253e2ab@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 19.06.2025 02:45, Stefano Stabellini wrote:
> On Wed, 18 Jun 2025, Jan Beulich wrote:
>> On 18.06.2025 02:39, Stefano Stabellini wrote:
>>> On Thu, 12 Jun 2025, Jan Beulich wrote:
>>>> On 11.06.2025 21:07, Stefano Stabellini wrote:
>>>>> On Wed, 11 Jun 2025, Jan Beulich wrote:
>>>>>> On 11.06.2025 02:07, dmkhn@proton.me wrote:
>>>>>>> On Tue, Jun 10, 2025 at 10:21:40AM +0200, Jan Beulich wrote:
>>>>>>>> On 06.06.2025 22:11, dmkhn@proton.me wrote:
>>>>>>>>> From: Denis Mukhin 
>>>>>>>>>
>>>>>>>>> If virtual UART from domain X prints on the physical console, the behavior is
>>>>>>>>> updated to (see [1]):
>>>>>>>>> - console focus in domain X: do not prefix messages;
>>>>>>>>> - no console focus in domain X: prefix all messages with "(dX)".
>>>>>>>>
>>>>>>>> While, as indicated (much) earlier, I can see why omitting the prefix
>>>>>>>> may make sense for the domain having input focus, ...
>>>>>>>>
>>>>>>>>> --- a/xen/drivers/char/console.c
>>>>>>>>> +++ b/xen/drivers/char/console.c
>>>>>>>>> @@ -740,7 +740,17 @@ 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 */
>>>>>>>>> +            char prefix[16] = "";
>>>>>>>>> +            struct domain *consd;
>>>>>>>>> +
>>>>>>>>> +            consd = console_get_domain();
>>>>>>>>> +            if ( consd != cd )
>>>>>>>>> +                snprintf(prefix, sizeof(prefix), "(d%d) ", cd->domain_id);
>>>>>>>>> +            console_put_domain(consd);
>>>>>>>>> +
>>>>>>>>>              nrspin_lock_irq(&console_lock);
>>>>>>>>> +            if ( prefix[0] != '\0' )
>>>>>>>>> +                console_send(prefix, strlen(prefix), flags);
>>>>>>>>>              console_send(kbuf, kcount, flags);
>>>>>>>>>              nrspin_unlock_irq(&console_lock);
>>>>>>>>>          }
>>>>>>>>
>>>>>>>> ... this, aiui, is a behavioral change for the non-dom0less case, where
>>>>>>>> Dom0 output will suddenly also gain the prefix. Which I don't think is
>>>>>>>> wanted: Switching focus between Xen and Dom0 should remain unaffected
>>>>>>>> in this regard.
>>>>>>>
>>>>>>> This change ensures that dom0 traces aren't mixed with domU traces when domU
>>>>>>> has input focus, or with Xen traces when the administrator is in the diagnostic
>>>>>>> console.
>>>>>>
>>>>>> That's what the description also tries to describe, yet I still regard it as
>>>>>> a behavioral regression in (at least) the described scenario. The hardware
>>>>>> domain presently not having (d0) prefixed to its output is deliberate imo,
>>>>>> not accidental.
>>>>>
>>>>> If we only consider the classic dom0 and dom0less usage models, then
>>>>> what you wrote makes perfect sense. In the classic dom0 case, it is best
>>>>> for dom0 to have no prefix, which is the current behavior.
>>>>>
>>>>> However, things become more complex with dom0less. As we have discussed
>>>>> previously, it has already become desirable on both ARM and x86 to align
>>>>> on the same behavior. During our last discussion, the preference was to
>>>>> add a '(d0)' prefix to clearly differentiate output from dom0 and other
>>>>> domains.
>>>>>
>>>>> Up to now, we could easily detect the two different cases depending on
>>>>> the boot configuration. The problem arises with Denis' patches, which
>>>>> add the ability for dynamically created guests via `xl` to access an
>>>>> emulated NS16550 UART that prints to the console. Because these guests
>>>>> are created dynamically, it is not clear how we are going to handle
>>>>> this case.
>>>>
>>>> Why would this be not clear? We already prefix their output with "(d)"
>>>> when going the traditional way. The same would then apply to output
>>>> coming through the emulated UART.
>>>>
>>>>> If we follow the dom0less preference, then we would need a '(d0)' prefix
>>>>> for dom0. If we follow the classic dom0 model, then dom0 would remain
>>>>> without a prefix, and the new domUs would have a prefix. This would
>>>>> cause an inconsistency. However, this is what we have today on ARM with
>>>>> dom0less.
>>>>>
>>>>> If Jan feels strongly that we should retain no prefix for the classic
>>>>> dom0 case, which is understandable, then I believe the best course of
>>>>> action would be to change our stance on dom0less on both ARM and x86 and
>>>>> also use no prefix for dom0 in the dom0less case (which is the current
>>>>> state on ARM).
>>>>
>>>> Leaving aside that "dom0 in the dom0less" ought to really be not-a-thing,
>>>> I disagree. Present behavior of not prefixing the domain's output which
>>>> has input focus continues to make sense. That requires Dom0 to have a
>>>> prefix whenever it doesn't have input focus.
>>>
>>> If I understood correctly I like your proposal. Let me rephrase it to
>>> make sure we are aligned. You are suggesting that:
>>>
>>> - domains without input focus will print with a (d) prefix
>>> - the domain with input focus will print without a (d) prefix
>>> - this applies to both DomUs and Dom0
>>
>> Except in the non-dom0less case, at least up and until there's at least
>> one other domain. I.e. I'd like to keep Dom0 boot output as it is today,
>> regardless of the presence of e.g. "conswitch=".
> 
> In the non-dom0less case, since dom0 has focus, it would naturally be
> without (d) prefix. Unless the user passes "conswitch=". Honestly, I
> wouldn't special-case conswitch= that way and would prefer keep things
> simple and consistent without corner cases. I don't think conswitch= is
> so widely used that it is worth the complexity to special-case it.

Widely used or not - _I_ use it all the time in debug configs where serial
is available.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jun 20 06:17:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 06:17:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020600.1396731 (Exim 4.92)
	(envelope-from )
	id 1uSV3q-0000Vz-I3; Fri, 20 Jun 2025 06:17:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020600.1396731; Fri, 20 Jun 2025 06: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 1uSV3q-0000Vs-Es; Fri, 20 Jun 2025 06:17:14 +0000
Received: by outflank-mailman (input) for mailman id 1020600;
 Fri, 20 Jun 2025 06: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 1uSV3p-0000Vm-8T
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 06:17:13 +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 336ea476-4d9e-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 08:17:11 +0200 (CEST)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3a4f379662cso1315509f8f.0
 for ; Thu, 19 Jun 2025 23:17:11 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3158a226fe4sm3395639a91.2.2025.06.19.23.17.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 19 Jun 2025 23:17:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 336ea476-4d9e-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750400231; x=1751005031; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=E+IpF9D+V6/NZPnUseyfSOmXd8So1XbMkvzT9T24fh0=;
        b=MSdeSqFPz+HsYqvB7zeDEp+5q8XDEB6Zb8e5Eq2/X4Tmwkvr8Jwo4CMD1jq6X6JZhq
         jLjrsXbAIQ4Flb/7+Aqa85fsBIBJQB3dqbEdjCEGsDmS2TihGn6nBSB98Vh41NtfG/7i
         nuByoHrZOqLpkUo6XS3gFicAtNtqhq4RAGCe0vI8QNA4wklpnTqGbHqQvKOFolsM0g+q
         NFTlT2yYBjWrpj9LKW7+3Fnjfbl8rSne6f2j+aLndlf15kRbSHW69xE2qAweTvTF5sGn
         lICCWUnnwTngErhTfgaF/QLd2ua6C18RkoBrBzj4WK53fpUFOOct6xZgl74xcgs++ty6
         pxYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750400231; x=1751005031;
        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=E+IpF9D+V6/NZPnUseyfSOmXd8So1XbMkvzT9T24fh0=;
        b=Ud6RotS/c9srcuTzWIFTJj04+Ro8ZLV0hPT8+Kd7d9K9vW/OQD8GORxDEQcsdjUAYq
         2uauvFpA8uedMHRRp7rgVQPF+dLxehwTmwviTDUOTwKD3S1F37gssKKr5sgULk2U0/WB
         70Twji+hK3rnfT1orBYSwGH6IPlDU+a8rUjOk5EerX0PafXHdAisNW5cmTrQNe41GB4O
         1slxnOio7S8qaNKsLQGeXvFbUEywR32AtS3Z9rdpreTlEtQxfBTTP+bkCtgORQ0DRgcQ
         VxkQUur7nDPy7G9jnQ2tuYQ8stoiwXDd8VIPj26JLxAIdGbXh7wbac8KOk2TYmRL0Ljd
         ucDw==
X-Forwarded-Encrypted: i=1; AJvYcCUrRsnzdjLcL9da6EFsgtV/b6ONRo+xdtoKmN2GjZlCG6uIwmJH2JNbbpc/YMI01lC6eVbD/wwgZic=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzQfWAOZNSj7rBRUi2UMjAxfxjCbTCcXUBSv8PqzbdPSmCEyOTV
	Y/V2WOp7r9nCxsUyDscMToKGsPLVd8qIDk9Vlud/q4gpvvmf5m/UY//aMx/YKMUPqw==
X-Gm-Gg: ASbGncvIlIY+Om66QwMaSxFpK0mGXOd9U6ZrOKppu8ftk8xUpLF5zOOpkopKjSwrnuq
	FoGjR21vSNoJB1BnvP1CCYPYNCJimSFA83PwFzExL5cGWJcaEZnj4Rje/8pfCjuUueX+6uchLao
	Ngf0xl1e3rZtUZ3K8A6H/icmwjCyaii3O4PIugMsOFitABftYX8wOUAREyCnmRv8/NcFbSc3wRL
	Z5yrtpskyDY5bHnujlLGRzT/1qFEqm6F1ihZqz2mUBGEbq0D11qQ6VlJpncGd1dFxkXAyJs/Ixy
	e3Y+zRfbdCDNW10mI7wIRu/Byv5cbXVOOxtMlClqNN/zqDW1dk7kRidtQEcOiflvdb41PKLhyN+
	8TAX6bf6WZGiMcO50yvGqXU8XTiGpUBTfKRtwW5rd5mSsQIc=
X-Google-Smtp-Source: AGHT+IFanpRNy+HD3R36kIiiHYC0C5zePnvN7u+bgA4Yc7+wQNXWjh+wHq8h55G6LRmLUIqv5T4xSg==
X-Received: by 2002:a05:6000:2002:b0:3a5:783f:528a with SMTP id ffacd0b85a97d-3a6d12fc180mr1229789f8f.59.1750400230608;
        Thu, 19 Jun 2025 23:17:10 -0700 (PDT)
Message-ID: <1d0fc483-d008-4745-8e27-0a2f6fab6b0d@suse.com>
Date: Fri, 20 Jun 2025 08:16:59 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/3] xen/x86: add missing noreturn attributes
To: Nicola Vetrini ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: victorm.lira@amd.com, xen-devel@lists.xenproject.org,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini ,
 Federico Serafini ,
 Bertrand Marquis 
References: <20250606212712.1901838-1-victorm.lira@amd.com>
 <20250606212712.1901838-2-victorm.lira@amd.com>
 <20250606212712.1901838-3-victorm.lira@amd.com>
 
 <220ccb5869914c44cc2b1f7a152ee933@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: <220ccb5869914c44cc2b1f7a152ee933@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 18.06.2025 18:16, Nicola Vetrini wrote:
> On 2025-06-18 17:18, Roger Pau Monné wrote:
>> On Fri, Jun 06, 2025 at 02:27:09PM -0700, victorm.lira@amd.com wrote:
>>> --- a/xen/arch/x86/traps.c
>>> +++ b/xen/arch/x86/traps.c
>>> @@ -805,7 +805,7 @@ void fatal_trap(const struct cpu_user_regs *regs, 
>>> bool show_remote)
>>>            (regs->eflags & X86_EFLAGS_IF) ? "" : " IN INTERRUPT 
>>> CONTEXT");
>>>  }
>>>
>>> -void asmlinkage do_unhandled_trap(struct cpu_user_regs *regs)
>>> +void asmlinkage noreturn do_unhandled_trap(struct cpu_user_regs 
>>> *regs)
>>>  {
>>>      fatal_trap(regs, false);
>>>  }
>>> diff --git a/xen/arch/x86/x86_64/traps.c b/xen/arch/x86/x86_64/traps.c
>>> index c77f304bb0..8460a4a1ae 100644
>>> --- a/xen/arch/x86/x86_64/traps.c
>>> +++ b/xen/arch/x86/x86_64/traps.c
>>> @@ -293,7 +293,7 @@ void show_page_walk(unsigned long addr)
>>>             l1_table_offset(addr), l1e_get_intpte(l1e), pfn);
>>>  }
>>>
>>> -void asmlinkage do_double_fault(struct cpu_user_regs *regs)
>>> +void asmlinkage noreturn do_double_fault(struct cpu_user_regs *regs)
>>
>> Does noreturn matter for functions called from assembly (asmlinkage
>> ones)?  In that case the hint is not useful for code generation, since
>> it's hand written assembly already?  (it's arguably useful for the
>> developer writing the code)
>>
>> Might be worth mentioning in the commit message if the above is
>> accurate.  For example by adding to the commit message: "noreturn is
>> not relevant for functions called from assembly, but can be used as a
>> hint for the developers writing the code".
> 
> Yes, it is relevant because the rule considers only the single function, 
> not the context where it is called (that is orders of magnitude more 
> difficult to check automatically). For my part, I'm ok with your 
> suggestion.

Right. In fact for non-static functions the attribute normally would go
on the declaration. The need to have it on the definition in the two
cases above is an aspect that may also want to go into the amended
description.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jun 20 06:23:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 06:23:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020607.1396740 (Exim 4.92)
	(envelope-from )
	id 1uSV9P-0002DI-4W; Fri, 20 Jun 2025 06:22:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020607.1396740; Fri, 20 Jun 2025 06: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 1uSV9P-0002DB-1w; Fri, 20 Jun 2025 06:22:59 +0000
Received: by outflank-mailman (input) for mailman id 1020607;
 Fri, 20 Jun 2025 06:22: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 1uSV9N-0002D5-M6
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 06:22:57 +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 0145306a-4d9f-11f0-a30e-13f23c93f187;
 Fri, 20 Jun 2025 08:22:56 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a548a73ff2so1405425f8f.0
 for ; Thu, 19 Jun 2025 23:22:56 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b31f119b988sm744239a12.21.2025.06.19.23.22.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 19 Jun 2025 23:22:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0145306a-4d9f-11f0-a30e-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750400576; x=1751005376; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=5vAMJHh3DqteArOUjowHhR/kL9HILOdSFZS1lUXWRy8=;
        b=hCeDtX6hLw21YFuosdKXBqrPX0dCV/5cHmRq7/Nv7OdNTST88CsfCkHPSRyriOMgPJ
         XCRXXA77ZY3Whi0JBicr4xxT4C1hs7e6Q8S74jlMf58Yn5fFtoLFNzOjjOUyFMJkDmlE
         blobQY5yweO1KS+VNzTn+WfVhWGPjfXSioKBvYAh25701yNhOfoDE+iQk9VZ75WUlIEI
         CBziwKEzfJARXflxL6rTQ0w+WP9reRnT8E6QHReXLtF1/Y7b3LVA46HyUUhCmBefHpt1
         YuCD8p3iscKCKLggmpvDFaIQNv7uxUxx8TLsULcDzlfBIVPdYrXI9gxsTAJoePdZTwr5
         jtVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750400576; x=1751005376;
        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=5vAMJHh3DqteArOUjowHhR/kL9HILOdSFZS1lUXWRy8=;
        b=tYJU0AIzxreUc8nJtq+uhSl6TZpduXWNoIhtdAr0OmJTtkJM38h/H7OskefFYrs7s0
         FGjHiuhqW0GuA9buSEODfUMhOzFlq5Otqr9WbOmB2tb5ZtrK/Xgo4UbiUftEy6/DeQzW
         ec5w9LRToqxkoUdNpivMdVic3k/9/IeKC79Ni3ic6o/fd1OEBl7yz2iZAbuEHqJu6aP7
         k9uKupyW4JKQKAnP715IWnUmM/xNZSwPqAEwEOnRQIhmaelygu7cJwhECD7CiCmnO0Yb
         xfh9uQA3sNpn1ix3Nq2yBIUwmpE0rXGARWyhHukuML5wU39LHv6byXS5XNJ8OcpR2juS
         luDg==
X-Forwarded-Encrypted: i=1; AJvYcCWPGwfr/2WD8Kr62o76V6EmHDfyNr21+D0rrnkPEVOm6R62oXGaKZ1n50SsMrB8LOO4mh/kxXmLrds=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx/9SDg3TaVhcWuVC1awnk+RKejcOA6xK8bRrRu8ztfMpaulk6t
	6vIuNohHf/rQPxaOyRBlsYheFRedHwzq46IY/r0Dy1C50A7hNVmssGvDN1bCEyZSnQ==
X-Gm-Gg: ASbGnctsxm1u+vILqheMxCdallzeosHS4fFgC1vQGnuxMMhtmJ/i1IsSC+IuRvGcucF
	u+fV8Wtq0qbnJFBlfhxlw+EJKjtttWafWVBLGnPpnWg9+rNme7Ao/kdF88ieU5FsxTJrQVV6kQO
	/p7eimMQmPQRBHLqFxn54GaRfzDsnovEN0aGmK2ppviAQSNdc06JXRw1/L/F5a9PjneM5lxefIR
	bi3VTzBvgNJMuzsc9+xSC/GO8pEqv4n9PYEwePw6rrQL87vRjtjn8vC2ZBKp67YGvcPn129RGKW
	TDW2syLX+nvSwJkV5M47R4bnrvVZHgkqrf/UjCPvIEmbvFBYDVSedMshWSzVlULO40BAFRiRQpc
	QEAAQU0rUAollkGpUMzXsXp244Rqh2FAcR+GzgZEKfmqN7/Q=
X-Google-Smtp-Source: AGHT+IFWV5HC8kn8yafrqxyqyjHN6p21MH4b9dpu4eLTKaXujtIwoaZBH1KKPBvyogE58DudbwOkwA==
X-Received: by 2002:a05:6000:4011:b0:3a4:ebc2:d6ec with SMTP id ffacd0b85a97d-3a6d12c1651mr1320446f8f.14.1750400575783;
        Thu, 19 Jun 2025 23:22:55 -0700 (PDT)
Message-ID: <618e1896-2f1d-4727-83d7-76b60b011c81@suse.com>
Date: Fri, 20 Jun 2025 08:22:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/efi: Do not check kernel signature if it was embedded
To: Frediano Ziglio 
Cc: "Daniel P. Smith" ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , xen-devel@lists.xenproject.org
References: <20250618184631.15489-1-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: <20250618184631.15489-1-frediano.ziglio@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 18.06.2025 20:46, Frediano Ziglio wrote:
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -1291,6 +1291,7 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle,
>      bool base_video = false;
>      const char *option_str;
>      bool use_cfg_file;
> +    bool kernel_was_verified = false;

May I suggest to drop the "was" infix from the variable name? The name is imo
as clear without it.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jun 20 06:29:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 06:29:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020619.1396751 (Exim 4.92)
	(envelope-from )
	id 1uSVFq-0002p2-QL; Fri, 20 Jun 2025 06:29:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020619.1396751; Fri, 20 Jun 2025 06:29:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSVFq-0002ov-Mf; Fri, 20 Jun 2025 06:29:38 +0000
Received: by outflank-mailman (input) for mailman id 1020619;
 Fri, 20 Jun 2025 06:29: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 1uSVFo-0002op-UZ
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 06:29:36 +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 ee959c23-4d9f-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 08:29:35 +0200 (CEST)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-43edecbfb46so10015045e9.0
 for ; Thu, 19 Jun 2025 23:29:35 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d839354esm10255805ad.16.2025.06.19.23.29.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 19 Jun 2025 23:29:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ee959c23-4d9f-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750400974; x=1751005774; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=DgadeZNAxD0955FkP7AFMe33exEJcRa7Txep6KPv6M4=;
        b=NvbCqR/G8Q8VVeeHeLx4tg26rgzf6NzJqyQZci5RE1vqJp2UkcTjIlQUyQ5RBcdyul
         uL+r6A4d3N9R0yQruXQIhZGbvPqkgJEtgPeGL+xt4jPSlANqnw71tPnUhpq9E+SYhSa7
         Q91KvAnsmgGCapPeOsPKag7px4euro2+eJlu+pXI/c3PjbV2TUJ799xaGydk4uKtnIwm
         MWd7QbIO3SJfJTxhue02n0glHbWiKNu0UpEyQD4l6qRic5zx9xKIIdu/PO3U1Q3GJy/X
         Tl9rgLVYUWr3SHEp3+mZbrg/xNRlSiKOvvOXgLVH069NM7sn1k3TbgsjtvPKjWDwHtkH
         0x1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750400974; x=1751005774;
        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=DgadeZNAxD0955FkP7AFMe33exEJcRa7Txep6KPv6M4=;
        b=qZdtg6t8kzoPmQq2yf7Vi/fE5xC5edcQB/mKlfTtkdwI+gZE0A4mrq/FQEyXXvdhuu
         sQdcTSch5LKr43nYcw6wLe7TyYWIeXlWgeLT4aDxtBdkGDTSQGvCNHz3HLdqvrRWI7Rg
         iAhFtaTQjFD2d71qV6sWXb4q7bkCU1mYLLxvvQTh3pqacbmFjI2LlcJ01c7lRXqKMtgV
         D4fytQi+qx4xoLhzDMOwBKCllpUhr3EQB/3TeTjqP/0SP8oPXGQ5B55Q17jn1ZOHMesU
         efTBIaLpk5fDnToOZpnx41OBL79AF6aysy6Nzgpyd1ZzjhLpO/LIzNJhG26IKWa96zvM
         ehXg==
X-Forwarded-Encrypted: i=1; AJvYcCW7EVl2MKxscURELVV2z0Wvosrm8y0hVyUX4QJ6TaT+VJHnup8W+PCODcNxkT9SrHwsZ39bN+Lh2rQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzFOUryZAtcvKfZfP8IQefU22hv6C0u9xov0PZJGAzNSY3Fgywt
	U2ou0GS8/EeQ/xdA3UihRg4RMVUSulukGcJxFfg3IG2SOdAhOtwdoy4qUHfEecDsSg==
X-Gm-Gg: ASbGncvSJiJb93vZKiXfV6JaY4Bw/zlR1JchB0+wqP+7bI/kuWmC5YrVNe+H/dIt53n
	JaV7/mCdgfCuULiX4kuk0qLEmOlFSYXrW6gb4KyNbh9puaPio3WwPbhCqr2yOmkaCfU6pvq8pj0
	lNMUZ6oBIzQSvavgo0xGr6TtLyF60AgqN7xTHzEN3UDk/D601KuV7ZWXsQnuyutpemxMfv1EXDw
	tDD3H1X3ZoCYIUUKOy4p4w72d7kNEMn03Bw12viN2YX0isRWn1LZCuruy3TO+gjKR6RcZ9ag5eX
	bq4YOXkQUsK+nxP+dgE7NZtfyBlZ4el7nwGBDU1dmnbr70eSE3KLzdun1Ku8WRSAk8ZK3LlrxMO
	U3XxoCPTEs52++ltEu1AkugIBG5G80fGggkIICIOYOobCOb4=
X-Google-Smtp-Source: AGHT+IEhngcvAsDe/hd+YVUI9NQX1BqWiBl5gTE8KcFqgFQZpDFOPQHaxZp7YxVNexuse3oGOHwvTw==
X-Received: by 2002:a5d:5f52:0:b0:3a4:eac6:e320 with SMTP id ffacd0b85a97d-3a6d1191018mr1185678f8f.3.1750400974043;
        Thu, 19 Jun 2025 23:29:34 -0700 (PDT)
Message-ID: 
Date: Fri, 20 Jun 2025 08:29:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 1/8] vpci/header: Emulate extended capability list for
 dom0
To: "Chen, Jiqian" ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: "Huang, Ray" ,
 "xen-devel@lists.xenproject.org" 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-2-Jiqian.Chen@amd.com>
 <669877f5-ef34-4552-9cfc-e097d40d444a@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 19.06.2025 04:29, Chen, Jiqian wrote:
> On 2025/6/18 21:52, Jan Beulich wrote:
>> On 12.06.2025 11:29, Jiqian Chen wrote:
>>> --- a/xen/drivers/vpci/header.c
>>> +++ b/xen/drivers/vpci/header.c
>>> @@ -836,6 +836,42 @@ static int vpci_init_capability_list(struct pci_dev *pdev)
>>>                                    PCI_STATUS_RSVDZ_MASK);
>>>  }
>>>  
>>> +static int vpci_init_ext_capability_list(struct pci_dev *pdev)
>>> +{
>>> +    unsigned int pos = PCI_CFG_SPACE_SIZE;
>>> +
>>> +    if ( !is_hardware_domain(pdev->domain) )
>>> +        /* Extended capabilities read as zero, write ignore for guest */
>>
>> s/guest/DomU/ ?
> Will do.
> 
>>
>>> +        return vpci_add_register(pdev->vpci, vpci_read_val, NULL,
>>> +                                 pos, 4, (void *)0);
>>> +
>>> +    while ( pos >= PCI_CFG_SPACE_SIZE )
>>> +    {
>>> +        uint32_t header = pci_conf_read32(pdev->sbdf, pos);
>>> +        int rc;
>>> +
>>> +        if ( !header )
>>> +            return 0;
>>
>> Is this a valid check to make for anything other than the first read? And even
>> if valid for the first one, shouldn't that also go through ...
>>
>>> +        rc = vpci_add_register(pdev->vpci, vpci_read_val, vpci_hw_write32,
>>> +                               pos, 4, (void *)(uintptr_t)header);
>>
>> ... here?
> If header of first is zero. There is no need to add a register I think, since the dom0 can read/write directly.

Well, my remark of course did go along with that further down. Plus I wonder
why the entire field being zero is special, but the field holding, say,
0x00010000 isn't. Yes, the spec calls out zeroes in all fields specially,
yet at the same time it does say nothing about certain other special values.

Jan

>>> --- a/xen/drivers/vpci/vpci.c
>>> +++ b/xen/drivers/vpci/vpci.c
>>> @@ -267,6 +267,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);
>>> +}
>>
>> Iirc we've been there before, yet I continue to wonder whether we're doing
>> ourselves any good in allowing writes to something that certainly better
>> wouldn't change. Even if we limit this to Dom0.
> I remember this was suggested by Roger in V2, since the Dom0 has no limitations to write the extended register.
> 
>>
>> Jan
> 



From xen-devel-bounces@lists.xenproject.org Fri Jun 20 06:35:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 06:35:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020630.1396760 (Exim 4.92)
	(envelope-from )
	id 1uSVL8-0004d3-GE; Fri, 20 Jun 2025 06:35:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020630.1396760; Fri, 20 Jun 2025 06:35:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSVL8-0004cw-Df; Fri, 20 Jun 2025 06:35:06 +0000
Received: by outflank-mailman (input) for mailman id 1020630;
 Fri, 20 Jun 2025 06:35: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 1uSVL7-0004cq-F3
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 06:35:05 +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 b2fd7cd4-4da0-11f0-a30e-13f23c93f187;
 Fri, 20 Jun 2025 08:35:04 +0200 (CEST)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-451d7b50815so11363305e9.2
 for ; Thu, 19 Jun 2025 23:35:04 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3158a31c6aesm3426677a91.41.2025.06.19.23.34.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 19 Jun 2025 23:35:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b2fd7cd4-4da0-11f0-a30e-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750401304; x=1751006104; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=wQCjG2G3mI5bncwzhBpJO9RhJHacW2+zmZ/+vnKm3rY=;
        b=dGUZjSNOr1P1QYNGpgFmEYGFGQUlMds/4/AUQGVl2bSshWLoa5yRDGlHUSQxuG+st3
         D/sIqd+rRd9AFgboeNHDim9PjECGpCrgTvHCVLtgRWyP9QhqyYphVRhLKLhlwUdeFBvh
         niMU9riF/dtqZndXtF/EAMvJEu+do805Mp7y8sBjV5QDbW3ialWO3tne9iU2m/QO5FlK
         xNrRqOxME4GI6CQN/cJl2ZrHz3HdVT4Ro0ofHOOqxY5gE4vyRbeH2t8ABuNGbDtQB5Gw
         QvNd+j1QLo2UnJL/epj2aq0+elFlIb1nhYrAiSb71mnRLXCb4RsMBaf+W4ZAZyhVqxFb
         e3+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750401304; x=1751006104;
        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=wQCjG2G3mI5bncwzhBpJO9RhJHacW2+zmZ/+vnKm3rY=;
        b=hOHitwFUTm89f90nXqGIaLf8Z+EG4BKuA/Fz+c4wS3A3hSvcaowVbY2Wb2tR6C70T/
         naXEGBaz0D1mlOUcxLWME6StxXTl7O+Crv5t9dTe1eF+0cCj1db5WTNJd2XX1YljNtDU
         xnTaeiqh692oqzph0ycTTfTMI/f/oxrYWsjet645qQLj8FYhc6Rkn1RyTGQPNteU+Obv
         38S8TJiVHJDJ97BHR8qMbb3eRl9VMotAx1adjp+55lV5238CmK5LNb8rsqKWO8I809q3
         vlwZRR9lz8RZH/Sw598I3SGM2p7/AvnciQ0hcb72VphMI8HreVtxPcdTs2ckG9Co7uoR
         JpNg==
X-Forwarded-Encrypted: i=1; AJvYcCXrJ0rCHQ5R9kEvVMawGUpIiyPAYNxew1JNemmlJ0qDIGlhv0ub68cADXeyVy4ltTnNJFe/TQbKvYE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywq7Z3i986c7o73seoINnlTQWN4kviAdkQnVMLtWp2cpyD5j4Ru
	fqf6Y47sDzTLMBv50SeVnPkw9Hx39xV9eDRvdFZH46trc4N9r4ApDY/1KVSJPxYJLg==
X-Gm-Gg: ASbGncthHG5mwnIDL9q6G+KLwUXcY1Kun1qghBYN/h+LIYmcVu24PwZkACz9MayJfLC
	NkYpGoAmkoIXFLLDXpX2Zg3pRsg7HFm2ZrMbqiejvLVkEPBxLdSShENxd3qcm0h8gSEAjcGwjRG
	ayO1CJTsbTEbv5Ah3hLrdJUEryqpsf55pHPBAuUVG51of3W/pGsNy1f+xa9IVy1TQck0od4jONV
	Yq3EjW1/cZzJy59CeyB5wdmbBgLv29EJue6BHUk0ukNw/ptgJSYZkfnq8/6FRsTE03biUbkVIMC
	8c7Mw022W94BVXQ5n/xlzbrh+okeQ6bh03rOUstc0tV0WB3u6u/Xvy+2A1RMRW8/Ku9LY4XQYkz
	uIpTKCtKFIfcxXv6fxO2xpy26Sib1fbCWRddV1ZnnioQQD1E=
X-Google-Smtp-Source: AGHT+IF6p6vbQS9bwn7AUlIPDyKRazrAhEt9S9NC0XeU5J2L5hYNh5VQNs+6t4f7B/PsZDkjXlCbVQ==
X-Received: by 2002:a5d:5f52:0:b0:3a5:39d7:5d5d with SMTP id ffacd0b85a97d-3a6d12d52bamr1088561f8f.36.1750401303615;
        Thu, 19 Jun 2025 23:35:03 -0700 (PDT)
Message-ID: <23293ec5-7466-400c-87a4-1482577b91fa@suse.com>
Date: Fri, 20 Jun 2025 08:34:53 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
To: "Chen, Jiqian" 
Cc: "Huang, Ray" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Andrew Cooper ,
 Anthony PERARD ,
 "Orzel, Michal" , Julien Grall ,
 Stefano Stabellini ,
 "xen-devel@lists.xenproject.org" 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-3-Jiqian.Chen@amd.com>
 <1634c18d-e54e-4105-8b30-6f3085bace22@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 19.06.2025 08:14, Chen, Jiqian wrote:
> On 2025/6/18 22:33, Jan Beulich wrote:
>> On 12.06.2025 11:29, Jiqian Chen wrote:
>>> --- a/xen/include/xen/vpci.h
>>> +++ b/xen/include/xen/vpci.h
>>> @@ -13,11 +13,12 @@ typedef uint32_t vpci_read_t(const struct pci_dev *pdev, unsigned int reg,
>>>  typedef void vpci_write_t(const struct pci_dev *pdev, unsigned int reg,
>>>                            uint32_t val, void *data);
>>>  
>>> -typedef int vpci_register_init_t(struct pci_dev *dev);
>>> -
>>> -#define VPCI_PRIORITY_HIGH      "1"
>>> -#define VPCI_PRIORITY_MIDDLE    "5"
>>> -#define VPCI_PRIORITY_LOW       "9"
>>> +typedef struct {
>>> +    unsigned int id;
>>> +    bool is_ext;
>>> +    int (*init)(struct pci_dev *pdev);
>>> +    int (*cleanup)(struct pci_dev *pdev);
>>
>> Is const really not possible to add to at least one of these two?
> Will change to be :
> 
> typedef struct {
>     unsigned int id;
>     bool is_ext;
>     int (* const init)(struct pci_dev *pdev);
>     int (* const cleanup)(struct pci_dev *pdev);
> } vpci_capability_t;

Ehm, no. The question was for the two function (pointer) parameters. "const"
on struct fields themselves can be useful, too, but for an entirely different
purpose.

>>> +} vpci_capability_t;
>>
>> As you have it here, ...
>>
>>> @@ -29,9 +30,22 @@ typedef int vpci_register_init_t(struct pci_dev *dev);
>>>   */
>>>  #define VPCI_MAX_VIRT_DEV       (PCI_SLOT(~0) + 1)
>>>  
>>> -#define REGISTER_VPCI_INIT(x, p)                \
>>> -  static vpci_register_init_t *const x##_entry  \
>>> -               __used_section(".data.vpci." p) = (x)
>>> +#define REGISTER_VPCI_CAPABILITY(cap, finit, fclean, ext) \
>>> +    static const vpci_capability_t finit##_t = { \
>>
>> ... _t suffixes generally designate types. I don't think we should abuse
>> that suffix for an identifier of a variable.
> What do you think I should change to?

Well, if you take my other advice, this question won't need answering, as
then you only need the ..._entry one.

Btw, noticing only now - why is it finit that's used to derive the identifier?
With that, it could as well be fclean (leaving aside the fact that that's
optional). Imo the name would better be derived from cap, and it would better
also reflect the purpose of the variable.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jun 20 06:38:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 06:38:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020637.1396771 (Exim 4.92)
	(envelope-from )
	id 1uSVOH-0005A0-VX; Fri, 20 Jun 2025 06:38:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020637.1396771; Fri, 20 Jun 2025 06:38: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 1uSVOH-00059t-S2; Fri, 20 Jun 2025 06:38:21 +0000
Received: by outflank-mailman (input) for mailman id 1020637;
 Fri, 20 Jun 2025 06:38: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 1uSVOH-00059n-5o
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 06:38:21 +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 26b41bc3-4da1-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 08:38:18 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3a54700a46eso878144f8f.1
 for ; Thu, 19 Jun 2025 23:38:18 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d86d563fsm10184215ad.207.2025.06.19.23.38.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 19 Jun 2025 23:38:17 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 26b41bc3-4da1-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750401498; x=1751006298; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=wBOh/2+Jjzkd4ISRnkwtmCajaQZSIGEi1SerSNTWDS8=;
        b=AKGHAzf5tMoDYVABMg5w9AGd5GKRmh+gBR2QHmTZJzjYIbg9x+9cNECULCObhkDW5o
         Vi95y5fTBU3tO9qFAXA1lpWpw3GDejOaV4bdF7eGWHkq4w2Hai5IypeQUQHr+kVCj/OQ
         4eDIfSWJYCSnq9JGmAIESzTBWbUoZCo8N+jZRLgGx2Dne0nzt3v5s7F8ZDu+N2N0/Ax+
         Y/AHGZ72kGyxmHwH9hmLCYu48q/u1rt72wjU6HcaOSM8DEJVxxLlYMpYFrBy4gYwCrAe
         sub1Pvu/tlaQwZ9MeLcVZA7Ha635CZdt9KxdWluFpj9IYWAO9ItV1CnaQdEJjPRQx/KH
         gc7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750401498; x=1751006298;
        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=wBOh/2+Jjzkd4ISRnkwtmCajaQZSIGEi1SerSNTWDS8=;
        b=BwTCDsXBidgsw2L6WOWUKPEJYiLk1wx9Eqb3s2tLorX39S360wjKQ1Y01WdExuVteI
         bFRdPGh69lKpe8f7wku8eknFO3d5tAvbHp3DOT/HZ9ZErDvwLFz9kq0CedtvcZHKkoeD
         EVdxKUEYBY1uPdo/yp7Lu7XBXUlKCwPOR6OIxQkBW4LpsXl7F5rQhAvGAWgPw8CSL9M8
         TFubAWRiuMW/jggYx9nG+P4FDbGRsbk3a3VC5whWRQsrWxR+wWvZJ/NdusDo0AZic5B2
         Ka4Bqee34wJ8+ZVn/BMf6YWgjU9Jm1v85vIoYcQKpbebUpKuORlF+349002K5TRyazX/
         t7Fw==
X-Forwarded-Encrypted: i=1; AJvYcCX2rpx9IEqxV+B9nc8hNyH56vzjLzT6FH7OpsiHnFBMG8WoO5eJ1YAbFWEjaEG/Vh0jEoMtpVTM76E=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw7d7XA3dduUSLP0rm4bvhKMWyQsK8oB5kdh82dRbnpXxEUqGSS
	G7vtT5PwQonkbvjZtoQiPIeYnVNhWlcpeV4PYO/L5MUxiJBqY4AvaBQYdwsptZDxBQ==
X-Gm-Gg: ASbGncuLtQ1b0IWS/q/mwxEtwUuIeXC63joj0uLhx/t8NVSn5gX42p0tdB7Blk5bACM
	N4JV2D5cjeY8SN7KmP1O2I6hXB3AXCoIntJaWiLTwlxaXlmMEa3TpTSwk5wykYpdA6Htpz7rfld
	WhTTfqdkawV8bYPvZmC+amCTGsZfziGtVovdFcaulrZTXRIxCETBFV/qkscTeAIrbInkxdgqRwV
	6La0igAqfethuv7sabjElX6g1ZASWfeuGCPL3YtODIRU6XFsLD/dYo+bzt/argK3XDDhNpuXnAh
	FiX+h1o8lAi8XZNCORaqYv9anI91TrBM5tYlPEavR3xnivIDlZnF9FPMiD4I36Vg5cLLxsTVqRl
	QtWnCipWAVJ+/aSjrICmUkuKN2E8nNZpTOipfF7lA92/f4E4=
X-Google-Smtp-Source: AGHT+IHXGpYUKw3rchKSykoSrSr4v2aJlmWKceyYja3tkRmE2AI9qQ9Sa2kE5a1kClvuiAfLHO8w+Q==
X-Received: by 2002:a05:6000:4107:b0:3a6:c95c:36c5 with SMTP id ffacd0b85a97d-3a6d1329bfamr976084f8f.40.1750401497801;
        Thu, 19 Jun 2025 23:38:17 -0700 (PDT)
Message-ID: <227df6d3-a2c3-4576-bde9-d8057c378e7a@suse.com>
Date: Fri, 20 Jun 2025 08:38:07 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
To: "Chen, Jiqian" 
Cc: "Huang, Ray" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Andrew Cooper ,
 Anthony PERARD ,
 "Orzel, Michal" , Julien Grall ,
 Stefano Stabellini ,
 "xen-devel@lists.xenproject.org" 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-3-Jiqian.Chen@amd.com>
 <516a3adc-320d-46ce-b235-8ef91469abcf@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 19.06.2025 08:39, Chen, Jiqian wrote:
> On 2025/6/18 22:05, Jan Beulich wrote:
>> On 12.06.2025 11:29, Jiqian Chen wrote:
>>> --- a/xen/drivers/vpci/msix.c
>>> +++ b/xen/drivers/vpci/msix.c
>>> @@ -703,9 +703,13 @@ static int cf_check init_msix(struct pci_dev *pdev)
>>>      pdev->vpci->msix = msix;
>>>      list_add(&msix->next, &d->arch.hvm.msix_tables);
>>>  
>>> -    return 0;
>>> +    spin_lock(&pdev->vpci->lock);
>>> +    rc = vpci_make_msix_hole(pdev);
>>> +    spin_unlock(&pdev->vpci->lock);
>>
>> If you add a call to vpci_make_msix_hole() here, doesn't it need (or at
>> least want) removing somewhere else? Otherwise maybe a code comment is
>> warranted next to the new call site?
> The removing operation in modify_bars() and vpci_deassign_device() is not enough?

I fear I don't understand this reply of yours. Which suggests that the patch
description may want extending as to this part of the change.

>>> @@ -29,9 +30,22 @@ typedef int vpci_register_init_t(struct pci_dev *dev);
>>>   */
>>>  #define VPCI_MAX_VIRT_DEV       (PCI_SLOT(~0) + 1)
>>>  
>>> -#define REGISTER_VPCI_INIT(x, p)                \
>>> -  static vpci_register_init_t *const x##_entry  \
>>> -               __used_section(".data.vpci." p) = (x)
>>> +#define REGISTER_VPCI_CAPABILITY(cap, finit, fclean, ext) \
>>> +    static const vpci_capability_t finit##_t = { \
>>> +        .id = (cap), \
>>> +        .init = (finit), \
>>> +        .cleanup = (fclean), \
>>> +        .is_ext = (ext), \
>>> +    }; \
>>> +    static const vpci_capability_t *const finit##_entry  \
>>> +        __used_section(".data.rel.ro.vpci") = &finit##_t
>>
>> Could you remind me why the extra level of indirection is necessary here?
>> That is, why can't .data.rel.ro.vpci be an array of vpci_capability_t?
> You mean I should change to be:
> #define REGISTER_VPCI_CAPABILITY(cap, finit, fclean, ext) \
>     static const vpci_capability_t finit##_t \
>         __used_section(".data.rel.ro.vpci") = { \
>         .id = (cap), \
>         .init = (finit), \
>         .cleanup = (fclean), \
>         .is_ext = (ext), \
>     }
> 
> Right?

Yes, subject to the earlier comments on the identifier choice.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jun 20 08:26:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 08:26:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020666.1396781 (Exim 4.92)
	(envelope-from )
	id 1uSX4j-0002J9-De; Fri, 20 Jun 2025 08:26:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020666.1396781; Fri, 20 Jun 2025 08:26: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 1uSX4j-0002J2-AP; Fri, 20 Jun 2025 08:26:17 +0000
Received: by outflank-mailman (input) for mailman id 1020666;
 Fri, 20 Jun 2025 08:26: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 1uSX4h-0002Iv-RO
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 08:26:15 +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 3b0ece3b-4db0-11f0-a30e-13f23c93f187;
 Fri, 20 Jun 2025 10:26:15 +0200 (CEST)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-453636fa0ceso8075195e9.3
 for ; Fri, 20 Jun 2025 01:26:15 -0700 (PDT)
Received: from localhost.localdomain (253.226.6.51.dyn.plus.net.
 [51.6.226.253]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4536470903asm17516405e9.40.2025.06.20.01.26.13
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 20 Jun 2025 01:26:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3b0ece3b-4db0-11f0-a30e-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750407974; x=1751012774; 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=UjZNOjvnDdhZuqYQVv8oT1CNUTyKY9t4hbuL5uen0oU=;
        b=i8tuQx0sjY/z8k8K9zhHJ+r+dsorQZo+QLGZSOFR+TH7S4erOxJX9BUZHI1k2cP4qy
         otZjqYsP2dD+FTbIQXfkGIDTK7/qyNj4gW+02BwRSlcyLX6Ru/vit/KV6ZW3KTCrHLyV
         eTGa4MgL8nHecPANShV01t0zgctgxznNQ0o7k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750407974; x=1751012774;
        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=UjZNOjvnDdhZuqYQVv8oT1CNUTyKY9t4hbuL5uen0oU=;
        b=YwB3ZSd3fYLNxk+lOWy+2BsYeym/lA51P72EaDOIPDTDJfh5UPX1ioTgk5wkLlxG50
         esUd/XczbaGs/s6zCsQGl7HPPcVmM1U4gDNgJNf75Bmr6OvAwaS9CSZ8okac+kbA/B7H
         1owuxvKdqbwXsrgpgqZzUSxR+AW0IsXM2jQaSSuJgChBDnIQt1kx3Bh0PD0nWdaCzZDg
         J1T685AyaylxlSW4NkFMyyOa5Q5MABK2gLvp8vqi8tUx858EbGifiwSKPPNfGVRONxyn
         cm6fkjhbUDEYPL7uci7KyGn6Sjo8qr+tY9F4trV+P4m/sT9SWej6fWelKgicu6xb+FQ/
         FPXQ==
X-Gm-Message-State: AOJu0YxrgVXtxV35TdRivjq9Ca6z0maXCQneXaYSkzA9vIcjDfiQrA1f
	GiJ6yXePsMNcybpJA++VMo1VG7fdueOEcB+gn5E0EArcnsmcTVC/Mp9I8oNLXkwdNpZV92xGY6f
	a51ph8WqcAg==
X-Gm-Gg: ASbGncvmFYPdW7a7mKp7i5+m4FqU3sgz8P+/WaEMpodvhzUqFRFRUrjiWdUSB0wY3rV
	dylLEK0VmWPP0LogFErqcdxarJcj9xzVUzNDBfntx0431UwjGjd8uNZp0XcHaZ9YxgmCxc3Soiv
	B72wj4LswSu1ahsKio/vI6C6IBWCjtlNVhCEhwRuWAuUPE/izTpVG3r8H9AOZ4MquQZYPJof+Ho
	Rh7OpSolDi7VML5U7yU0QqGJfrGpGYiKEjjL4S2E+fmDqixGWc+feauRqaMsxxOreD8QSp5gkuM
	Q/pFZuDlVyygmtJBntnnUtK444J8Y19yBMgm95tXrnlMBP+qbXtMlrbPXzzeFT4enJPB2hZ/eYK
	dw9PhnswSmHsnP+VJnviCyi6IptxQLArJZyKB/rFr
X-Google-Smtp-Source: AGHT+IG5+s3IydQtINiHAo5GNuBxPt3wGj7yk6vQo3wU4SlKEvnPrKRLccBPWc4olibOdeiQhyNGHw==
X-Received: by 2002:a05:600c:3b9a:b0:43a:b0ac:b10c with SMTP id 5b1f17b1804b1-453659ec136mr14011085e9.26.1750407974117;
        Fri, 20 Jun 2025 01:26:14 -0700 (PDT)
From: Frediano Ziglio 
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio ,
	"Daniel P. Smith" ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Jan Beulich 
Subject: [PATCH v2] xen/efi: Do not check kernel signature if it was embedded
Date: Fri, 20 Jun 2025 09:26:05 +0100
Message-ID: <20250620082607.46568-1-frediano.ziglio@cloud.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Using UKI it's possible to embed Linux kernel into xen.efi file.
In this case the signature for Secure Boot is applied to the
whole xen.efi, including the kernel.
So checking for specific signature for the kernel is not
needed.

Signed-off-by: Frediano Ziglio 
---
Changes since v1:
- updated commit message and code comment;
- renamed kernel_was_verified to kernel_verified.
---
 xen/common/efi/boot.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index e39fbc3529..fb3b120982 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -1291,6 +1291,7 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle,
     bool base_video = false;
     const char *option_str;
     bool use_cfg_file;
+    bool kernel_verified = false;
     int dt_modules_found;
 
     __set_bit(EFI_BOOT, &efi_flags);
@@ -1461,6 +1462,11 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle,
             read_file(dir_handle, s2w(&name), &kernel, option_str);
             efi_bs->FreePool(name.w);
         }
+        else
+        {
+            /* Kernel was embedded so Xen signature includes it. */
+            kernel_verified = true;
+        }
 
         if ( !read_section(loaded_image, L"ramdisk", &ramdisk, NULL) )
         {
@@ -1534,6 +1540,7 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle,
      * verify it.
      */
     if ( kernel.ptr &&
+         !kernel_verified &&
          !EFI_ERROR(efi_bs->LocateProtocol(&shim_lock_guid, NULL,
                                            (void **)&shim_lock)) &&
          (status = shim_lock->Verify(kernel.ptr, kernel.size)) != EFI_SUCCESS )
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 20 09:40:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 09:40:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020694.1396815 (Exim 4.92)
	(envelope-from )
	id 1uSYEG-0003TO-R6; Fri, 20 Jun 2025 09:40:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020694.1396815; Fri, 20 Jun 2025 09: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 1uSYEG-0003TH-OQ; Fri, 20 Jun 2025 09:40:12 +0000
Received: by outflank-mailman (input) for mailman id 1020694;
 Fri, 20 Jun 2025 09: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 1uSYEF-0003TB-Gh
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 09:40:11 +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 871eaa94-4dba-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 11:39:57 +0200 (CEST)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-451d54214adso12155665e9.3
 for ; Fri, 20 Jun 2025 02:39:57 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a6d0f1d868sm1548901f8f.44.2025.06.20.02.39.56
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 20 Jun 2025 02:39:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 871eaa94-4dba-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750412397; x=1751017197; 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=mxDIJUE+HPxU05Xg/Wr+29VEXI+BUKdLDuT6Res18Jo=;
        b=qAd9cdVR6otGPAxCptLuldMiTJEHXpf5S4cMm2YQ/EyWgCxZPUG1SKcaqmh/VwbTtm
         RvXD7MmIB2amqXQhymda6SMKxRANg4qBsGXZ6IAh4m005CyktjctZ7Bs1bbWw2CDmbBE
         /zWzSJODjedUsAyVn1nv8JyA0gq/ScFkakYrA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750412397; x=1751017197;
        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=mxDIJUE+HPxU05Xg/Wr+29VEXI+BUKdLDuT6Res18Jo=;
        b=QxM9OoLlRrIzscz3R3YBWifAIemw4A0m+/aTjvZo7g0h71hg+mJVZ2YF3pg2p+adFA
         M9mx+iBb24GtHN6W3nDT9i9bQxxj8qdsQqPU06zJ8BVOJ3cNebue467Zt5NA9Jli3w6x
         kQOymoJSx4NVGLNIrpw0y7exfDA3Kh+M/cjugxx3ehtPKq8fnuABaEUyi/C561NpnJpa
         Bi1x3s8NFDlQNePCRWO/d6HX8sQ5GpsPcX+e+4FSByYClj3s3ghULjbR/2aP3gwxxF3z
         2N768Bt87+btuTWiVAhHFVr+OND7TBQO6js4gK0ykLEDfqeGm9mYZf6FKmCXhOM0oqCB
         32OQ==
X-Gm-Message-State: AOJu0Yy5Hdwu6cAVLObniO5IiKS4JaSiiZTiu2x1oysL0FMOKy5u9EFO
	8g9XVm9adAGc3ouea0DOgedOscbegcybxql5dKUNYEEtpRliGKeSbWbUV7ArmsTb0Y0=
X-Gm-Gg: ASbGncsm1OT9i1tnAl/toFvi7cBah1zYTMPM/VnJ0SeBFwHaD/2oqHQ6rcbSxBLQxGG
	m74vOHR6tzNZYzkZwPkof85hhZfeal+ogAkMy5dTV6F/idoVQmoFHAuyz2KEsmFnpG5JvV8CqkE
	Jv74XV+IUA3lUUiP6wkgpq5AldYOzTtnZNCmFJYtrPL7Sf7MScVD7M2x0Zt0x3GsIwBM9Bh+aFu
	KB7ZxAGapEkSISmQard4rBhaxXVzgSYluz1PS4tlhYvFkuQU3s78d0eY0x9j4fERcQ6CUbW2nfO
	pC2/Dm8TF0sICYwk+StmPLPYweupPdk8+hMsgWqHHIfOXLVUuQWyXWuWrd+Jr2eplPe5ukVur0G
	8kQzMlOzXYQk8hhDjzxCz7DUuwHylB7podlc=
X-Google-Smtp-Source: AGHT+IFNQjCMGC+87ag7PggR5a5KN6bdjVRcXDLEo4UUQo2z0AkyH6XXKVmMTU3XkSVRnw6bWG5vmA==
X-Received: by 2002:a05:6000:2486:b0:3a5:2beb:7493 with SMTP id ffacd0b85a97d-3a6d12fb300mr1664987f8f.9.1750412396924;
        Fri, 20 Jun 2025 02:39:56 -0700 (PDT)
Date: Fri, 20 Jun 2025 11:39:55 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Ross Lagerwall 
Cc: xen-devel@lists.xenproject.org, Kevin Lampis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v3 2/5] livepatch: Embed public key in Xen
Message-ID: 
References: <20250602133639.2871212-1-ross.lagerwall@citrix.com>
 <20250602133639.2871212-3-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250602133639.2871212-3-ross.lagerwall@citrix.com>

On Mon, Jun 02, 2025 at 02:36:34PM +0100, Ross Lagerwall wrote:
> From: Kevin Lampis 
> 
> Make it possible to embed a public key in Xen to be used when verifying
> live patch payloads. Inclusion of the public key is optional.
> 
> To avoid needing to include a DER / X.509 parser in the hypervisor, the
> public key is unpacked at build time and included in a form that is
> convenient for the hypervisor to consume. This is different approach
> from that used by Linux which embeds the entire X.509 certificate and
> builds in a parser for it.
> 
> A suitable key can be created using openssl:
> 
> openssl req -x509 -newkey rsa:2048 -keyout priv.pem -out pub.pem \
>     -sha256 -days 3650 -nodes \
>     -subj "/C=XX/ST=StateName/L=CityName/O=CompanyName/OU=CompanySectionName/CN=CommonNameOrHostname"
> openssl x509 -inform PEM -in pub.pem -outform PEM -pubkey -nocert -out verify_key.pem
> 
> Signed-off-by: Kevin Lampis 
> Signed-off-by: Ross Lagerwall 
> ---
> 
> In v3:
> 
> * Drop unnecessary condition in Makefile
> * Use dashes instead of underscores
> * Drop section placement annotation on declaration
> * Clarify endianness of embedded key
> 
>  xen/common/Kconfig          | 18 +++++++++++++++++
>  xen/crypto/Makefile         | 11 ++++++++++
>  xen/include/xen/livepatch.h |  5 +++++
>  xen/tools/extract-key.py    | 40 +++++++++++++++++++++++++++++++++++++
>  4 files changed, 74 insertions(+)
>  create mode 100755 xen/tools/extract-key.py
> 
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index 0951d4c2f286..74673078202a 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -472,6 +472,24 @@ config LIVEPATCH
>  
>  	  If unsure, say Y.
>  
> +config PAYLOAD_VERIFY
> +	bool "Verify signed LivePatch payloads"
> +	depends on LIVEPATCH
> +	select CRYPTO
> +	help
> +	  Verify signed LivePatch payloads using an RSA public key built
> +	  into the Xen hypervisor. Selecting this option requires a
> +	  public key in PEM format to be available for embedding during
> +	  the build.
> +
> +config PAYLOAD_VERIFY_KEY
> +	string "File name of public key used to verify payloads"
> +	default "verify_key.pem"
> +	depends on PAYLOAD_VERIFY
> +	help
> +	  The file name of an RSA public key in PEM format to be used for
> +	  verifying signed LivePatch payloads.

I think this is likely to break the randconfig testing that we do in
Gitlab CI, as randconfig could select PAYLOAD_VERIFY, but there will
be no key included, and hence the build will fail?

Ideally Gitlab CI would need to be adjusted to provide such key so the
build doesn't fail.  I think it could be provided unconditionally to
simplify the logic, if the option is not selected the file will simply
be ignored.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jun 20 09:43:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 09:43:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020705.1396825 (Exim 4.92)
	(envelope-from )
	id 1uSYH0-00048a-BF; Fri, 20 Jun 2025 09:43:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020705.1396825; Fri, 20 Jun 2025 09:43: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 1uSYH0-00048T-8L; Fri, 20 Jun 2025 09:43:02 +0000
Received: by outflank-mailman (input) for mailman id 1020705;
 Fri, 20 Jun 2025 09:43:00 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uSYGy-00048G-Fo
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 09:43:00 +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 f2de7b12-4dba-11f0-a30e-13f23c93f187;
 Fri, 20 Jun 2025 11:42:59 +0200 (CEST)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-441ab63a415so17913055e9.3
 for ; Fri, 20 Jun 2025 02:42:58 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a6d0f187a5sm1605871f8f.34.2025.06.20.02.42.57
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 20 Jun 2025 02:42:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f2de7b12-4dba-11f0-a30e-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750412578; x=1751017378; 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=ubgPFVvM/Tg7diMc2XsBHckJiKaFKiS5Yk0XvSz32Bk=;
        b=su8vHC8syx4Dn4LgMscycgAw0tNAdn8qbgBYd1A4eCgBjnfvg9pPvxopE/Q24So6Au
         YIfOT+KQbgRTRd4G1y7NsWnZUEhbPUGyxu51oop/JFsqZ3yRkgde5WbjjP2bEaIC9sQ5
         0fJ9Y1Nk19PmyuKHaD05u40Grb2QMI4ci2zYk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750412578; x=1751017378;
        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=ubgPFVvM/Tg7diMc2XsBHckJiKaFKiS5Yk0XvSz32Bk=;
        b=OJUkqA6xoFz1IhEYjNMuC9jlLVRb2A9HD/1Z7DzX0bAZ8ixar/CURuHRDp9FaHItzu
         Edd/ctMkJJdckANx6qKzXAy9lDagSX2MjPWR7GE/TRsGU0jramRowu7ZR7CBUFR+W5t4
         RcrxXG6FbyzY4ex4IUgK6+/TWL0yLs964thtmYgN2Vx6VTh8uDZHQoIDNWEiRJJOcYaE
         f17abbBdMhG7Si+5ZfbIGp+P09QYCZkQ/yQYZdYSVKIuGi56MGp/Maj7+5lJDQ9nS6uU
         ssTZTESScLvXhyJslcXywGmHbsUmZBk+fnlnVe44OiTc4TVFmAirU/CSyq2hfxptLl/S
         smWg==
X-Forwarded-Encrypted: i=1; AJvYcCWXYpujjf+szppF0RTg2yt2YW68DSvr+lTfEwZN6P6zRuh1FUGw7N5ju22DRRNAzgdqWGLD4ajrxXQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzzjzSVnxS/R03GpU1nkQkIG/QduIN5HCdP/uSfYCx8VjCcd4vZ
	xFhjrf9JCK61nMVuw21tcQ0a3hxWStQG3/d81taPFj11jCCP6uPM7unRcqt70t20QZk=
X-Gm-Gg: ASbGncvlqtpcwblnSKw6lClE1ztCSPAdPoiPXEBQViFCDMFRpHE2nkw61Wuv35uNmb4
	5yg4KtigZeJXAVseNOdQAGJQjaqNnY19535tayHzbLDFL5jxfUHkmJid5zQPVbfXqKLOyA1VLwJ
	07QssTsQniXbcXu/izYghi2vtdLVUTH+iwMWCtmI3XsqqJ6jpgnFgj8MUU4D/Z/rVEfl74u5vXs
	YdZKQOZrFiFM76UXhOGjd1WloqFenjneG50KiLbTuxF1FP5euBzx52hXdxpNrHbqwK7eF1tFeIF
	IxisvOTjjva8Za9o02akemIKWvnfAt5yIhCFoFlci0ZKlLvRgrpXO4AQDuzNC21Rvxwb6lPgKPX
	j9UL+8VQXU/XHn4PJVqXdn5oKBZ5kOsEVHVU=
X-Google-Smtp-Source: AGHT+IHxGiSQTF4nGFpmZXcydeDzicyLo2kanFzs2Bk/ZKVVUEunGk0iI/pWKxvMEv6XusvK1dZ/HQ==
X-Received: by 2002:a05:600c:5026:b0:450:b240:aaab with SMTP id 5b1f17b1804b1-453654cb3d9mr18736515e9.8.1750412577741;
        Fri, 20 Jun 2025 02:42:57 -0700 (PDT)
Date: Fri, 20 Jun 2025 11:42:56 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Ross Lagerwall ,
	Kevin Lampis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 2/5] livepatch: Embed public key in Xen
Message-ID: 
References: <20250602133639.2871212-1-ross.lagerwall@citrix.com>
 <20250602133639.2871212-3-ross.lagerwall@citrix.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 

On Thu, Jun 05, 2025 at 01:19:00PM +0200, Jan Beulich wrote:
> On 02.06.2025 15:36, Ross Lagerwall wrote:
> > From: Kevin Lampis 
> > 
> > Make it possible to embed a public key in Xen to be used when verifying
> > live patch payloads. Inclusion of the public key is optional.
> > 
> > To avoid needing to include a DER / X.509 parser in the hypervisor, the
> > public key is unpacked at build time and included in a form that is
> > convenient for the hypervisor to consume. This is different approach
> > from that used by Linux which embeds the entire X.509 certificate and
> > builds in a parser for it.
> > 
> > A suitable key can be created using openssl:
> > 
> > openssl req -x509 -newkey rsa:2048 -keyout priv.pem -out pub.pem \
> >     -sha256 -days 3650 -nodes \
> >     -subj "/C=XX/ST=StateName/L=CityName/O=CompanyName/OU=CompanySectionName/CN=CommonNameOrHostname"
> > openssl x509 -inform PEM -in pub.pem -outform PEM -pubkey -nocert -out verify_key.pem
> > 
> > Signed-off-by: Kevin Lampis 
> > Signed-off-by: Ross Lagerwall 
> 
> While reviewing patch 4 it occurred to me: Why embed the key? Can't this
> be specified as (another) boot module?

Then the key itself will need to be signed, and it's extra churn that
we would need to verify at boot.  I'm not opposed to being able to
load the key as a module, but it seems reasonable to also bundle one
in Xen.  If there's interest in passing one as a module it could
always be implemented as a separate feature.  IMO: I don't see both
approaches as being incompatible with each other.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jun 20 09:50:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 09:50:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020712.1396835 (Exim 4.92)
	(envelope-from )
	id 1uSYNh-0004kd-0A; Fri, 20 Jun 2025 09:49:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020712.1396835; Fri, 20 Jun 2025 09:49: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 1uSYNg-0004kW-TP; Fri, 20 Jun 2025 09:49:56 +0000
Received: by outflank-mailman (input) for mailman id 1020712;
 Fri, 20 Jun 2025 09:49: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 1uSYNg-0004kQ-Lo
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 09:49:56 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id ea705291-4dbb-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 11:49:54 +0200 (CEST)
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 9FF34176A;
 Fri, 20 Jun 2025 02:49:33 -0700 (PDT)
Received: from PWQ0QT7DJ1.arm.com (unknown [10.57.67.38])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1BB813F673;
 Fri, 20 Jun 2025 02:49:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ea705291-4dbb-11f0-b894-0df219b8e170
From: Hari Limaye 
To: xen-devel@lists.xenproject.org
Cc: luca.fancellu@arm.com,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH 0/6] Second series for R82 MPU Support
Date: Fri, 20 Jun 2025 10:49:18 +0100
Message-ID: 
X-Mailer: git-send-email 2.42.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Hi all,

This series is the second set of patches in the ongoing work to
introduce support for MPU systems and Cortex R82 in Xen.

The patches in this series implement the necessary logic to map and
unmap the Device Tree Blob in the early stages of the boot process.

Cheers,
Hari

Luca Fancellu (4):
  arm/mpu: Find MPU region by range
  xen/arm: Introduce flags_has_rwx helper
  arm/mpu: Implement early_fdt_map support in MPU systems
  arm/mpu: Implement remove_early_mappings for MPU systems

Penny Zheng (2):
  arm/mpu: Populate a new region in Xen MPU mapping table
  arm/mpu: Destroy an existing entry in Xen MPU memory mapping table

 xen/arch/arm/include/asm/mm.h         |   2 +
 xen/arch/arm/include/asm/mpu.h        |   2 +
 xen/arch/arm/include/asm/mpu/cpregs.h |   4 +
 xen/arch/arm/include/asm/mpu/mm.h     |  41 +++++
 xen/arch/arm/mm.c                     |  15 ++
 xen/arch/arm/mmu/pt.c                 |   9 +-
 xen/arch/arm/mpu/mm.c                 | 229 ++++++++++++++++++++++++++
 xen/arch/arm/mpu/setup.c              |  83 +++++++++-
 8 files changed, 374 insertions(+), 11 deletions(-)

-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Jun 20 09:50:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 09:50:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020714.1396845 (Exim 4.92)
	(envelope-from )
	id 1uSYNs-0005xr-5t; Fri, 20 Jun 2025 09:50:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020714.1396845; Fri, 20 Jun 2025 09:50: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 1uSYNs-0005xh-35; Fri, 20 Jun 2025 09:50:08 +0000
Received: by outflank-mailman (input) for mailman id 1020714;
 Fri, 20 Jun 2025 09:50: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 1uSYNr-0004kQ-AX
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 09:50:07 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id f15d5528-4dbb-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 11:50:05 +0200 (CEST)
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 3C10C1A25;
 Fri, 20 Jun 2025 02:49:45 -0700 (PDT)
Received: from PWQ0QT7DJ1.arm.com (unknown [10.57.67.38])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 998D63F673;
 Fri, 20 Jun 2025 02:50:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f15d5528-4dbb-11f0-b894-0df219b8e170
From: Hari Limaye 
To: xen-devel@lists.xenproject.org
Cc: luca.fancellu@arm.com,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH 1/6] arm/mpu: Find MPU region by range
Date: Fri, 20 Jun 2025 10:49:19 +0100
Message-ID: 
X-Mailer: git-send-email 2.42.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Luca Fancellu 

Implement a function to find the index of a MPU region
in the xen_mpumap MPU region array.

Signed-off-by: Luca Fancellu 
Signed-off-by: Hari Limaye 
---
 xen/arch/arm/include/asm/mpu/mm.h | 29 ++++++++++++++
 xen/arch/arm/mpu/mm.c             | 66 +++++++++++++++++++++++++++++++
 2 files changed, 95 insertions(+)

diff --git a/xen/arch/arm/include/asm/mpu/mm.h b/xen/arch/arm/include/asm/mpu/mm.h
index a7f970b465..a0f0d86d4a 100644
--- a/xen/arch/arm/include/asm/mpu/mm.h
+++ b/xen/arch/arm/include/asm/mpu/mm.h
@@ -10,6 +10,13 @@
 #include 
 #include 
 
+#define MPUMAP_REGION_OVERLAP      -1
+#define MPUMAP_REGION_NOTFOUND      0
+#define MPUMAP_REGION_FOUND         1
+#define MPUMAP_REGION_INCLUSIVE     2
+
+#define INVALID_REGION_IDX     0xFFU
+
 extern struct page_info *frame_table;
 
 extern uint8_t max_mpu_regions;
@@ -75,6 +82,28 @@ void write_protection_region(const pr_t *pr_write, uint8_t sel);
  */
 pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags);
 
+/*
+ * Checks whether a given memory range is present in the provided table of
+ * MPU protection regions.
+ *
+ * @param table         Array of pr_t protection regions.
+ * @param r_regions     Number of elements in `table`.
+ * @param base          Start of the memory region to be checked (inclusive).
+ * @param limit         End of the memory region to be checked (exclusive).
+ * @param index         Set to the index of the region if an exact or inclusive
+ *                      match is found, and INVALID_REGION otherwise.
+ * @return: Return code indicating the result of the search:
+ *          MPUMAP_REGION_NOTFOUND: no part of the range is present in #table
+ *          MPUMAP_REGION_FOUND: found an exact match in #table
+ *          MPUMAP_REGION_INCLUSIVE: found an inclusive match in #table
+ *          MPUMAP_REGION_OVERLAP: found an overlap with a mapping in #table
+ *
+ * Note: make sure that the range [#base, #limit) refers to the half-open
+ * interval inclusive of #base and exclusive of #limit.
+ */
+int mpumap_contain_region(pr_t *table, uint8_t nr_regions, paddr_t base,
+                          paddr_t limit, uint8_t *index);
+
 #endif /* __ARM_MPU_MM_H__ */
 
 /*
diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
index ccfb37a67b..15197339b1 100644
--- a/xen/arch/arm/mpu/mm.c
+++ b/xen/arch/arm/mpu/mm.c
@@ -12,6 +12,18 @@
 #include 
 #include 
 
+#ifdef NDEBUG
+static inline void __attribute__ ((__format__ (__printf__, 1, 2)))
+region_printk(const char *fmt, ...) {}
+#else /* !NDEBUG */
+#define region_printk(fmt, args...)         \
+    do                                      \
+    {                                       \
+        dprintk(XENLOG_ERR, fmt, ## args);  \
+        WARN();                             \
+    } while (0)
+#endif /* NDEBUG */
+
 struct page_info *frame_table;
 
 /* Maximum number of supported MPU memory regions by the EL2 MPU. */
@@ -110,6 +122,60 @@ pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags)
     return region;
 }
 
+int mpumap_contain_region(pr_t *table, uint8_t nr_regions, paddr_t base,
+                          paddr_t limit, uint8_t *index)
+{
+    uint8_t i = 0, _index;
+
+    /* Allow index to be NULL */
+    index = index ? index : &_index;
+
+    /* Inside mpumap_contain_region check for inclusive range */
+    limit = limit - 1;
+
+    *index = INVALID_REGION_IDX;
+
+    if ( limit < base )
+    {
+        region_printk("Base address 0x%"PRIpaddr" must be smaller than limit address 0x%"PRIpaddr"\n",
+                      base, limit);
+        return -EINVAL;
+    }
+
+    for ( ; i < nr_regions; i++ )
+    {
+        paddr_t iter_base = pr_get_base(&table[i]);
+        paddr_t iter_limit = pr_get_limit(&table[i]);
+
+        /* Found an exact valid match */
+        if ( (iter_base == base) && (iter_limit == limit) &&
+             region_is_valid(&table[i]) )
+        {
+            *index = i;
+            return MPUMAP_REGION_FOUND;
+        }
+
+        /* No overlapping */
+        if ( (iter_limit < base) || (iter_base > limit) )
+            continue;
+
+        /* Inclusive and valid */
+        if ( (base >= iter_base) && (limit <= iter_limit) &&
+             region_is_valid(&table[i]) )
+        {
+            *index = i;
+            return MPUMAP_REGION_INCLUSIVE;
+        }
+
+        /* Overlap */
+        region_printk("Range 0x%"PRIpaddr" - 0x%"PRIpaddr" overlaps with the existing region 0x%"PRIpaddr" - 0x%"PRIpaddr"\n",
+                      base, limit + 1, iter_base, iter_limit + 1);
+        return MPUMAP_REGION_OVERLAP;
+    }
+
+    return MPUMAP_REGION_NOTFOUND;
+}
+
 void __init setup_mm(void)
 {
     BUG_ON("unimplemented");
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Jun 20 09:50:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 09:50:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020715.1396855 (Exim 4.92)
	(envelope-from )
	id 1uSYNx-0006Kv-Cm; Fri, 20 Jun 2025 09:50:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020715.1396855; Fri, 20 Jun 2025 09:50:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSYNx-0006Ki-9y; Fri, 20 Jun 2025 09:50:13 +0000
Received: by outflank-mailman (input) for mailman id 1020715;
 Fri, 20 Jun 2025 09:50: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 1uSYNw-0006II-4O
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 09:50:12 +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 f4820272-4dbb-11f0-a30e-13f23c93f187;
 Fri, 20 Jun 2025 11:50:10 +0200 (CEST)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-60794c43101so2396373a12.1
 for ; Fri, 20 Jun 2025 02:50:10 -0700 (PDT)
Received: from ?IPV6:2003:e5:872a:8800:5c7b:1ac1:4fa0:423b?
 (p200300e5872a88005c7b1ac14fa0423b.dip0.t-ipconnect.de.
 [2003:e5:872a:8800:5c7b:1ac1:4fa0:423b])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ae05420a5fasm134077666b.181.2025.06.20.02.50.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 20 Jun 2025 02:50:09 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f4820272-4dbb-11f0-a30e-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750413010; x=1751017810; 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=Wu2XdBLUTD/JkCBRH0B2g43bjtpoBodRhTuNrAEojDs=;
        b=NwNPxIl0VMKLBil1ETMBDGjF2VPVzoEM/f5rXvg9FeUdvxfwMWl4uHVfLSELQhX+oU
         U+THTBVabxKDwVDRB378qD5uy98IEo58q9eYBK09MTpLnUDt3n7DxyvQV3p0C6ey9HEA
         Il1pUtikn5Yl5hmHbZkAAwejzazihf+htN5DLB69Mc7rbBcDBi98nEjTwGJWjDzKGWVf
         OavRattlQqu21MTuWZkwCA/A2Xqu/wP+8JmTInLSV55k4Wcucwsg3AiFcBU2L2hdzFc8
         e51g4y4Jynq81Az0npAT7oJza4tVf9TmxfwwWWW7iTQuWQMoZ1fp32iU1DyifVxqmP1m
         hCwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750413010; x=1751017810;
        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=Wu2XdBLUTD/JkCBRH0B2g43bjtpoBodRhTuNrAEojDs=;
        b=XDR2JhG/KqeOKACyVs1R/xYwxQi/aBcnWVkM9+gKQPDVL3HpReN+08bTOKsmnekv6S
         8agpDh6YgvA7tbhXLYQbcqFTR1ZjNYDqQqBmPXIR+eINtsRrSS9AUz8Ys4MziIWKjO+n
         hT7NSyswB6TnfBxWXeIxpXaEv619PLf28CysFOSrYzrXUTfV0eFhAY9Hdtcl4J2TNSB7
         m7lG1iJOir2MJ7LVH4GSuNG/6oes7IhFsI/C/js/oH7SpTjpL13ShTbFxGhCCZ2sojoI
         lpO4fufBEmbCu8NkGaTRCrdkrAOtsJSip+ItK5iLVRnzXb10c3f61C3BDUMQcZQ6Q4iN
         uRpg==
X-Forwarded-Encrypted: i=1; AJvYcCXQOUuX8iwy8ZAOo9M+I+4WpnlYQzFehiZy8TloZYqeQndC//R7MBODqiRgywZQKHmnZOSW99E3P58=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxwIjQlHUlg+k0F1WhC09Kz9W70Ot/KMENjrD/eO0n6nODeRDa1
	t4jr73f9vwBeRuLzc81gBpT2iHYF4LpazUKg751BkIvEDQ1861WKRkzh8FMeWzOXKdg=
X-Gm-Gg: ASbGncuq80gV/OvmJhp6NLjfpPWb+0zq1TN99nt53G+aKLSAorZiRUSHp6LFsdouK+M
	EXQM05T13jugSKGSUfs9GgGV3pc+ZbR/B1HINstVLzHjoQj75Jaj5Cbegd75yH6LpHwvuSkzrmm
	YFuyHgeq/DBQ89HMJZDAPezkYZVumiT0dxp0YxU0C9FYOw2hAZarnb31NLN7gyi5/te+0vZBl8Z
	P1TO3M3CH9isVMyNmcu6TvFXbQN1VjUtRo+Cdh7VOCvefs6czlshkueZXo3gsbCiBoQwBovzB9A
	I/1uzTkh1u0AVufTz7QQu+SbuO6h3soj8+GX87mHcFZxO4LngBDUymSlAxYDNleOWz6bjp8arb9
	FgaEkdXcLGkawk/HYdOb8gjHjN9g9OtQHNDTdTNXpksmzn2EUjg99Hy/H+0FxfmoFoY62x/yP2l
	a2Ao8SRzCO3ww=
X-Google-Smtp-Source: AGHT+IE6QNgq8N9m77mGWq1gslHyy5HrK0GB1Ws3zGc0uZ4W4vHoZEm0zIfPwbc6t8mh1lUzVD5LqQ==
X-Received: by 2002:a17:906:6a1a:b0:ad2:1cd6:aacf with SMTP id a640c23a62f3a-ae057c0d793mr190191466b.47.1750413009954;
        Fri, 20 Jun 2025 02:50:09 -0700 (PDT)
Message-ID: <62eb6d8a-7759-46b1-b06b-e7c6bc4f9a11@suse.com>
Date: Fri, 20 Jun 2025 11:50:08 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen/xenbus: fix W=1 build warning in
 xenbus_va_dev_error function
To: jiang.peng9@zte.com.cn
Cc: sstabellini@kernel.org, oleksandr_tyshchenko@epam.com,
 xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
 xu.xin16@zte.com.cn, yang.yang29@zte.com.cn
References: <20250620084104786r5xoR16_AmYZMJLnno3_Q@zte.com.cn>
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: <20250620084104786r5xoR16_AmYZMJLnno3_Q@zte.com.cn>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------NtA1j85D0sd5rJotB6iLDmbT"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------NtA1j85D0sd5rJotB6iLDmbT
Content-Type: multipart/mixed; boundary="------------kdp5ScXAbPSzFIR8UvMpL0pR";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: jiang.peng9@zte.com.cn
Cc: sstabellini@kernel.org, oleksandr_tyshchenko@epam.com,
 xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
 xu.xin16@zte.com.cn, yang.yang29@zte.com.cn
Message-ID: <62eb6d8a-7759-46b1-b06b-e7c6bc4f9a11@suse.com>
Subject: Re: [PATCH v2] xen/xenbus: fix W=1 build warning in
 xenbus_va_dev_error function
References: <20250620084104786r5xoR16_AmYZMJLnno3_Q@zte.com.cn>
In-Reply-To: <20250620084104786r5xoR16_AmYZMJLnno3_Q@zte.com.cn>

--------------kdp5ScXAbPSzFIR8UvMpL0pR
Content-Type: multipart/mixed; boundary="------------c3s8ua8KPaJdFvjCgEcsQum8"

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

T24gMjAuMDYuMjUgMDI6NDEsIGppYW5nLnBlbmc5QHp0ZS5jb20uY24gd3JvdGU6DQo+IEZy
b206IFBlbmcgSmlhbmcgPGppYW5nLnBlbmc5QHp0ZS5jb20uY24+DQo+IA0KPiBUaGlzIHBh
dGNoIGZpeGVzIGEgVz0xIGZvcm1hdC1zdHJpbmcgd2FybmluZyByZXBvcnRlZCBieSBHQ0Mg
MTIuMy4wDQo+IGJ5IGFubm90YXRpbmcgeGVuYnVzX3N3aXRjaF9mYXRhbCgpIGFuZCB4ZW5i
dXNfdmFfZGV2X2Vycm9yKCkNCj4gd2l0aCB0aGUgX19wcmludGYgYXR0cmlidXRlLiBUaGUg
YXR0cmlidXRlIGVuYWJsZXMgY29tcGlsZS10aW1lDQo+IHZhbGlkYXRpb24gb2YgcHJpbnRm
LXN0eWxlIGZvcm1hdCBzdHJpbmdzIGluIHRoZXNlIGZ1bmN0aW9ucy4NCj4gDQo+IFRoZSBv
cmlnaW5hbCB3YXJuaW5nIHRyYWNlOg0KPiBkcml2ZXJzL3hlbi94ZW5idXMveGVuYnVzX2Ns
aWVudC5jOjMwNDo5OiB3YXJuaW5nOiBmdW5jdGlvbiAneGVuYnVzX3ZhX2Rldl9lcnJvcicg
bWlnaHQgYmUNCj4gYSBjYW5kaWRhdGUgZm9yICdnbnVfcHJpbnRmJyBmb3JtYXQgYXR0cmli
dXRlIFstV3N1Z2dlc3QtYXR0cmlidXRlPWZvcm1hdF0NCj4gDQo+IFNpZ25lZC1vZmYtYnk6
IFBlbmcgSmlhbmcgPGppYW5nLnBlbmc5QHp0ZS5jb20uY24+DQoNClJldmlld2VkLWJ5OiBK
dWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+DQoNCg0KSnVlcmdlbg0KDQpQUzogTmV4
dCB0aW1lIHBsZWFzZSBkb24ndCBzZW5kIGFub3RoZXIgdmVyc2lvbiBvZiBhIHBhdGNoIGFz
IGEgcmVwbHksDQogICAgIGJ1dCBhcyBhIG5ldyBlbWFpbCB0aHJlYWQuDQo=
--------------c3s8ua8KPaJdFvjCgEcsQum8
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-----

--------------c3s8ua8KPaJdFvjCgEcsQum8--

--------------kdp5ScXAbPSzFIR8UvMpL0pR--

--------------NtA1j85D0sd5rJotB6iLDmbT
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/Ey8FAmhVLtAFAwAAAAAACgkQsN6d1ii/Ey+m
Pwf+PgPfDUz9sPAG3hxG59OF6zm7TCAsLq/a2lQ6ShXfeqzPjSH7dZOm51VYCkVQKWGwSLCaVI0t
cXqIRRVob/0zQn+jIu4irFcRuwRTl4UJZwy/EZ2vcVr8GuJimL/DtEXwCDvkVQm/9mA4PhGBApJB
9zIxZ+Efmvz1f2v3EjfFhAXd8b5Hf2ihy05HneYT9yOEhOgyU4d/rBFuxwOKQi3rW1SHnIMaXpYy
VSmKHDBwM1/S4BmO0pdg4XXGj19M0cNAkinONkHcS38vWxUEnmj745ebXGZen0zhWSFutrVeKw3o
IGbHDMye78JRKcp22J+Du2HyDMii+4UKW+AiOW+MGQ==
=KDQS
-----END PGP SIGNATURE-----

--------------NtA1j85D0sd5rJotB6iLDmbT--


From xen-devel-bounces@lists.xenproject.org Fri Jun 20 09:50:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 09:50:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020734.1396865 (Exim 4.92)
	(envelope-from )
	id 1uSYOU-0007LR-RD; Fri, 20 Jun 2025 09:50:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020734.1396865; Fri, 20 Jun 2025 09:50: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 1uSYOU-0007LI-OD; Fri, 20 Jun 2025 09:50:46 +0000
Received: by outflank-mailman (input) for mailman id 1020734;
 Fri, 20 Jun 2025 09:50: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 1uSYOT-0004kQ-AR
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 09:50:45 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id 0823130f-4dbc-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 11:50:43 +0200 (CEST)
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 78CB1176A;
 Fri, 20 Jun 2025 02:50:23 -0700 (PDT)
Received: from PWQ0QT7DJ1.arm.com (unknown [10.57.67.38])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E96063F673;
 Fri, 20 Jun 2025 02:50:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0823130f-4dbc-11f0-b894-0df219b8e170
From: Hari Limaye 
To: xen-devel@lists.xenproject.org
Cc: luca.fancellu@arm.com,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH 2/6] xen/arm: Introduce flags_has_rwx helper
Date: Fri, 20 Jun 2025 10:49:20 +0100
Message-ID: 
X-Mailer: git-send-email 2.42.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Luca Fancellu 

Introduce flags_has_rwx() function that will check if a
mapping is both writable and executable when modifying
or update the mapping.

This check was already present in pt.c but since it will
be used also for MPU system, it's wrapped into a function
now.

Signed-off-by: Luca Fancellu 
---
 xen/arch/arm/include/asm/mm.h |  2 ++
 xen/arch/arm/mm.c             | 15 +++++++++++++++
 xen/arch/arm/mmu/pt.c         |  9 +--------
 3 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/mm.h
index 011bc1fd30..9daaa96d93 100644
--- a/xen/arch/arm/include/asm/mm.h
+++ b/xen/arch/arm/include/asm/mm.h
@@ -192,6 +192,8 @@ extern unsigned long frametable_base_pdx;
 
 /* Boot-time pagetable setup */
 extern void setup_pagetables(void);
+/* Check that the mapping flag has no W and X together */
+extern bool flags_has_rwx(unsigned int flags);
 /* Map FDT in boot pagetable */
 extern void *early_fdt_map(paddr_t fdt_paddr);
 /* Remove early mappings */
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 0613c19169..c2da1e3a05 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -24,6 +24,21 @@
 
 unsigned long frametable_base_pdx __read_mostly;
 
+bool flags_has_rwx(unsigned int flags)
+{
+    /*
+     * The hardware was configured to forbid mapping both writeable and
+     * executable.
+     * When modifying/creating mapping (i.e _PAGE_PRESENT is set),
+     * prevent any update if this happen.
+     */
+    if ( (flags & _PAGE_PRESENT) && !PAGE_RO_MASK(flags) &&
+         !PAGE_XN_MASK(flags) )
+        return true;
+    else
+        return false;
+}
+
 void flush_page_to_ram(unsigned long mfn, bool sync_icache)
 {
     void *v = map_domain_page(_mfn(mfn));
diff --git a/xen/arch/arm/mmu/pt.c b/xen/arch/arm/mmu/pt.c
index 4726e713ef..621b47dbf5 100644
--- a/xen/arch/arm/mmu/pt.c
+++ b/xen/arch/arm/mmu/pt.c
@@ -610,14 +610,7 @@ static int xen_pt_update(unsigned long virt,
      */
     const mfn_t root = maddr_to_mfn(READ_SYSREG64(TTBR0_EL2));
 
-    /*
-     * The hardware was configured to forbid mapping both writeable and
-     * executable.
-     * When modifying/creating mapping (i.e _PAGE_PRESENT is set),
-     * prevent any update if this happen.
-     */
-    if ( (flags & _PAGE_PRESENT) && !PAGE_RO_MASK(flags) &&
-         !PAGE_XN_MASK(flags) )
+    if ( flags_has_rwx(flags) )
     {
         mm_printk("Mappings should not be both Writeable and Executable.\n");
         return -EINVAL;
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Jun 20 09:51:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 09:51:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020737.1396875 (Exim 4.92)
	(envelope-from )
	id 1uSYOl-0007nU-2x; Fri, 20 Jun 2025 09:51:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020737.1396875; Fri, 20 Jun 2025 09:51:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSYOk-0007nM-Vz; Fri, 20 Jun 2025 09:51:02 +0000
Received: by outflank-mailman (input) for mailman id 1020737;
 Fri, 20 Jun 2025 09:51: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 1uSYOj-0004kQ-55
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 09:51:01 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id 11716f90-4dbc-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 11:50:59 +0200 (CEST)
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 19E34176A;
 Fri, 20 Jun 2025 02:50:39 -0700 (PDT)
Received: from PWQ0QT7DJ1.arm.com (unknown [10.57.67.38])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2A5FA3F673;
 Fri, 20 Jun 2025 02:50:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 11716f90-4dbc-11f0-b894-0df219b8e170
From: Hari Limaye 
To: xen-devel@lists.xenproject.org
Cc: luca.fancellu@arm.com,
	Penny Zheng ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Penny Zheng ,
	Wei Chen 
Subject: [PATCH 3/6] arm/mpu: Populate a new region in Xen MPU mapping table
Date: Fri, 20 Jun 2025 10:49:21 +0100
Message-ID: <840ec219278c2fcb4f8592303eb671b5271b0a95.1750411205.git.hari.limaye@arm.com>
X-Mailer: git-send-email 2.42.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Penny Zheng 

Introduce map_pages_to_xen() that is implemented using a new helper,
xen_mpumap_update(), which is responsible for updating Xen MPU memory
mapping table(xen_mpumap), including creating a new entry, updating
or destroying an existing one, it is equivalent to xen_pt_update in MMU.

This commit only implements populating a new entry in Xen MPU memory mapping
table(xen_mpumap).

Signed-off-by: Penny Zheng 
Signed-off-by: Wei Chen 
Signed-off-by: Luca Fancellu 
Signed-off-by: Hari Limaye 
---
 xen/arch/arm/include/asm/mpu/mm.h | 12 ++++
 xen/arch/arm/mpu/mm.c             | 96 +++++++++++++++++++++++++++++++
 2 files changed, 108 insertions(+)

diff --git a/xen/arch/arm/include/asm/mpu/mm.h b/xen/arch/arm/include/asm/mpu/mm.h
index a0f0d86d4a..f0f41db210 100644
--- a/xen/arch/arm/include/asm/mpu/mm.h
+++ b/xen/arch/arm/include/asm/mpu/mm.h
@@ -64,6 +64,7 @@ static inline void context_sync_mpu(void)
  * The following API requires context_sync_mpu() after being used to modify MPU
  * regions:
  *  - write_protection_region
+ *  - xen_mpumap_update
  */
 
 /* Reads the MPU region (into @pr_read) with index @sel from the HW */
@@ -72,6 +73,17 @@ void read_protection_region(pr_t *pr_read, uint8_t sel);
 /* Writes the MPU region (from @pr_write) with index @sel to the HW */
 void write_protection_region(const pr_t *pr_write, uint8_t sel);
 
+/*
+ * Maps an address range into the MPU data structure and updates the HW.
+ * Equivalent to xen_pt_update in an MMU system.
+ *
+ * @param base      Base address of the range to map (inclusive).
+ * @param limit     Limit address of the range to map (exclusive).
+ * @param flags     Flags for the memory range to map.
+ * @return          0 on success, negative on error.
+ */
+int xen_mpumap_update(paddr_t base, paddr_t limit, unsigned int flags);
+
 /*
  * Creates a pr_t structure describing a protection region.
  *
diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
index 15197339b1..1de28d2120 100644
--- a/xen/arch/arm/mpu/mm.c
+++ b/xen/arch/arm/mpu/mm.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -41,6 +42,8 @@ DECLARE_BITMAP(xen_mpumap_mask, MAX_MPU_REGION_NR) \
 /* EL2 Xen MPU memory region mapping table. */
 pr_t __cacheline_aligned __section(".data") xen_mpumap[MAX_MPU_REGION_NR];
 
+static DEFINE_SPINLOCK(xen_mpumap_lock);
+
 static void __init __maybe_unused build_assertions(void)
 {
     /*
@@ -176,6 +179,99 @@ int mpumap_contain_region(pr_t *table, uint8_t nr_regions, paddr_t base,
     return MPUMAP_REGION_NOTFOUND;
 }
 
+/*
+ * Allocate a new free EL2 MPU memory region, based on bitmap xen_mpumap_mask.
+ * @param idx   Set to the index of the allocated EL2 MPU region on success.
+ * @return      0 on success, otherwise -ENOENT on failure.
+ */
+static int xen_mpumap_alloc_entry(uint8_t *idx)
+{
+    ASSERT(spin_is_locked(&xen_mpumap_lock));
+
+    *idx = find_first_zero_bit(xen_mpumap_mask, max_mpu_regions);
+    if ( *idx == max_mpu_regions )
+    {
+        printk(XENLOG_ERR "mpu: EL2 MPU memory region mapping pool exhausted\n");
+        return -ENOENT;
+    }
+
+    set_bit(*idx, xen_mpumap_mask);
+    return 0;
+}
+
+/*
+ * Update the entry in the MPU memory region mapping table (xen_mpumap) for the
+ * given memory range and flags, creating one if none exists.
+ *
+ * @param base  Base address (inclusive).
+ * @param limit Limit address (exclusive).
+ * @param flags Region attributes (a combination of PAGE_HYPERVISOR_XXX)
+ * @return      0 on success, otherwise negative on error.
+ */
+static int xen_mpumap_update_entry(paddr_t base, paddr_t limit,
+                                   unsigned int flags)
+{
+    uint8_t idx;
+    int rc;
+
+    ASSERT(spin_is_locked(&xen_mpumap_lock));
+
+    rc = mpumap_contain_region(xen_mpumap, max_mpu_regions, base, limit, &idx);
+    if ( (rc < 0) || (rc > MPUMAP_REGION_NOTFOUND) )
+        return -EINVAL;
+
+    /* We are inserting a mapping => Create new region. */
+    if ( flags & _PAGE_PRESENT )
+    {
+        rc = xen_mpumap_alloc_entry(&idx);
+        if ( rc )
+            return -ENOENT;
+
+        xen_mpumap[idx] = pr_of_addr(base, limit, flags);
+
+        write_protection_region(&xen_mpumap[idx], idx);
+    }
+
+    return 0;
+}
+
+int xen_mpumap_update(paddr_t base, paddr_t limit, unsigned int flags)
+{
+    int rc;
+
+    if ( flags_has_rwx(flags) )
+    {
+        region_printk("Mappings should not be both Writeable and Executable\n");
+        return -EINVAL;
+    }
+
+    if ( !IS_ALIGNED(base, PAGE_SIZE) || !IS_ALIGNED(limit, PAGE_SIZE) )
+    {
+        region_printk("base address 0x%"PRIpaddr", or limit address 0x%"PRIpaddr" is not page aligned\n",
+                      base, limit);
+        return -EINVAL;
+    }
+
+    spin_lock(&xen_mpumap_lock);
+
+    rc = xen_mpumap_update_entry(base, limit, flags);
+
+    spin_unlock(&xen_mpumap_lock);
+
+    return rc;
+}
+
+int map_pages_to_xen(unsigned long virt, mfn_t mfn, unsigned long nr_mfns,
+                     unsigned int flags)
+{
+    int rc = xen_mpumap_update(mfn_to_maddr(mfn),
+                               mfn_to_maddr(mfn_add(mfn, nr_mfns)), flags);
+    if ( !rc )
+        context_sync_mpu();
+
+    return rc;
+}
+
 void __init setup_mm(void)
 {
     BUG_ON("unimplemented");
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Jun 20 09:51:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 09:51:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020742.1396885 (Exim 4.92)
	(envelope-from )
	id 1uSYOt-00086l-9J; Fri, 20 Jun 2025 09:51:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020742.1396885; Fri, 20 Jun 2025 09:51: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 1uSYOt-00086c-67; Fri, 20 Jun 2025 09:51:11 +0000
Received: by outflank-mailman (input) for mailman id 1020742;
 Fri, 20 Jun 2025 09:51: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 1uSYOs-00082H-CC
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 09:51:10 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 165ed3ea-4dbc-11f0-a30e-13f23c93f187;
 Fri, 20 Jun 2025 11:51:07 +0200 (CEST)
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 4EC0E176A;
 Fri, 20 Jun 2025 02:50:47 -0700 (PDT)
Received: from PWQ0QT7DJ1.arm.com (unknown [10.57.67.38])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BFE243F673;
 Fri, 20 Jun 2025 02:51:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 165ed3ea-4dbc-11f0-a30e-13f23c93f187
From: Hari Limaye 
To: xen-devel@lists.xenproject.org
Cc: luca.fancellu@arm.com,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH 5/6] arm/mpu: Implement early_fdt_map support in MPU systems
Date: Fri, 20 Jun 2025 10:49:23 +0100
Message-ID: 
X-Mailer: git-send-email 2.42.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Luca Fancellu 

Implement the function early_fdt_map(), which is responsible for mapping
the Device Tree Blob in the early stages of the boot process, for MPU
systems.

We make use of the map_pages_to_xen() and destroy_xen_mappings() APIs.
In particular the latter function is necessary in the case that the
initial mapping of the fdt_header is insufficient to cover the entire
DTB, as we must destroy and then remap the region due to the APIs no
providing support for extending the size of an existing region.

Signed-off-by: Luca Fancellu 
Signed-off-by: Hari Limaye 
---
 xen/arch/arm/mpu/setup.c | 74 ++++++++++++++++++++++++++++++++++++++--
 1 file changed, 72 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/mpu/setup.c b/xen/arch/arm/mpu/setup.c
index b4da77003f..ab00cb944b 100644
--- a/xen/arch/arm/mpu/setup.c
+++ b/xen/arch/arm/mpu/setup.c
@@ -1,17 +1,87 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
+#include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 
+static paddr_t __initdata mapped_fdt_paddr = INVALID_PADDR;
+static paddr_t __initdata mapped_fdt_limit = INVALID_PADDR;
+
 void __init setup_pagetables(void) {}
 
 void * __init early_fdt_map(paddr_t fdt_paddr)
 {
-    BUG_ON("unimplemented");
-    return NULL;
+    /* Map at least a page containing the DTB address, exclusive range */
+    paddr_t base = round_pgdown(fdt_paddr);
+    paddr_t limit = round_pgup(fdt_paddr + sizeof(struct fdt_header));
+    unsigned int flags = PAGE_HYPERVISOR_RO;
+    void *fdt_virt = (void *)fdt_paddr; /* virt == paddr for MPU */
+    int rc;
+    unsigned long nr_mfns;
+
+    /*
+     * Check whether the physical FDT address is set and meets the minimum
+     * alignment requirement. Since we are relying on MIN_FDT_ALIGN to be at
+     * least 8 bytes so that we always access the magic and size fields
+     * of the FDT header after mapping the first chunk, double check if
+     * that is indeed the case.
+     */
+    BUILD_BUG_ON(MIN_FDT_ALIGN < 8);
+    if ( !fdt_paddr || fdt_paddr % MIN_FDT_ALIGN )
+        return NULL;
+
+    /* DTB starting at this address has already been mapped. */
+    if ( mapped_fdt_paddr == fdt_paddr )
+        return fdt_virt;
+
+    /*
+     * DTB starting at a different address has been mapped, so destroy this
+     * before continuing.
+     */
+    if ( mapped_fdt_paddr != INVALID_PADDR )
+    {
+        rc = destroy_xen_mappings(round_pgdown(mapped_fdt_paddr),
+                                  mapped_fdt_limit);
+        if ( rc )
+            panic("Unable to unmap existing device-tree.\n");
+    }
+
+    nr_mfns = (limit - base) >> PAGE_SHIFT;
+
+    rc = map_pages_to_xen(base, maddr_to_mfn(base), nr_mfns, flags);
+    if ( rc )
+        panic("Unable to map the device-tree.\n");
+
+    mapped_fdt_paddr = fdt_paddr;
+    mapped_fdt_limit = limit;
+
+    if ( fdt_magic(fdt_virt) != FDT_MAGIC )
+        return NULL;
+
+    limit = round_pgup(fdt_paddr + fdt_totalsize(fdt_virt));
+
+    /* If the mapped range is not enough, map the rest of the DTB. */
+    if ( limit > mapped_fdt_limit )
+    {
+        rc = destroy_xen_mappings(base, mapped_fdt_limit);
+        if ( rc )
+            panic("Unable to unmap the device-tree header.\n");
+
+        nr_mfns = (limit - base) >> PAGE_SHIFT;
+
+        rc = map_pages_to_xen(base, maddr_to_mfn(base), nr_mfns, flags);
+        if ( rc )
+            panic("Unable to map the device-tree.\n");
+
+        mapped_fdt_limit = limit;
+    }
+
+    return fdt_virt;
 }
 
 /*
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Jun 20 09:51:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 09:51:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020743.1396895 (Exim 4.92)
	(envelope-from )
	id 1uSYOv-0008NS-G3; Fri, 20 Jun 2025 09:51:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020743.1396895; Fri, 20 Jun 2025 09: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 1uSYOv-0008NJ-CI; Fri, 20 Jun 2025 09:51:13 +0000
Received: by outflank-mailman (input) for mailman id 1020743;
 Fri, 20 Jun 2025 09:51: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 1uSYOu-00082H-Ur
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 09: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 193fb1e8-4dbc-11f0-a30e-13f23c93f187;
 Fri, 20 Jun 2025 11:51:12 +0200 (CEST)
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 2D589176A;
 Fri, 20 Jun 2025 02:50:52 -0700 (PDT)
Received: from PWQ0QT7DJ1.arm.com (unknown [10.57.67.38])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9D68D3F673;
 Fri, 20 Jun 2025 02:51:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 193fb1e8-4dbc-11f0-a30e-13f23c93f187
From: Hari Limaye 
To: xen-devel@lists.xenproject.org
Cc: luca.fancellu@arm.com,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH 6/6] arm/mpu: Implement remove_early_mappings for MPU systems
Date: Fri, 20 Jun 2025 10:49:24 +0100
Message-ID: <9a8b831cc6ff25b03c7ffab6a5c79e653496aa4f.1750411205.git.hari.limaye@arm.com>
X-Mailer: git-send-email 2.42.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Luca Fancellu 

Implement remove_early_mappings for MPU systems.

Signed-off-by: Luca Fancellu 
Signed-off-by: Hari Limaye 
---
 xen/arch/arm/mpu/setup.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/mpu/setup.c b/xen/arch/arm/mpu/setup.c
index ab00cb944b..5928b534d5 100644
--- a/xen/arch/arm/mpu/setup.c
+++ b/xen/arch/arm/mpu/setup.c
@@ -97,7 +97,14 @@ void __init copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
 
 void __init remove_early_mappings(void)
 {
-    BUG_ON("unimplemented");
+    int rc;
+
+    if ( mapped_fdt_paddr == INVALID_PADDR )
+        return;
+
+    rc = destroy_xen_mappings(round_pgdown(mapped_fdt_paddr), mapped_fdt_limit);
+    if ( rc )
+        panic("Unable to unmap the device-tree.\n");
 }
 
 /*
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Jun 20 09:54:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 09:54:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020760.1396904 (Exim 4.92)
	(envelope-from )
	id 1uSYRd-00013E-T4; Fri, 20 Jun 2025 09:54:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020760.1396904; Fri, 20 Jun 2025 09:54: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 1uSYRd-000137-QH; Fri, 20 Jun 2025 09:54:01 +0000
Received: by outflank-mailman (input) for mailman id 1020760;
 Fri, 20 Jun 2025 09:54: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 1uSYRc-00012y-Nv
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 09:54:00 +0000
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com
 [2a00:1450:4864:20::330])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7c74cc09-4dbc-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 11:53:58 +0200 (CEST)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-451ebd3d149so10273735e9.2
 for ; Fri, 20 Jun 2025 02:53:58 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a6d1189977sm1543148f8f.82.2025.06.20.02.53.57
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 20 Jun 2025 02:53:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7c74cc09-4dbc-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750413238; x=1751018038; 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=6sTuUUBWSSYBoqV1/4Ia/RrBVDTs9rH4NkrSo0YdX5A=;
        b=eYRNoUWRBfnQhVi4wQedPe0OJFek2VLFy1vPwJts9fcAMFnUvc7molLWOhbf1ZRnW8
         NBU3SvxbCeHJD7Dxvh9qaF/acxNURrqb2zGa3msUDOCxG3sO2oHtEkWr1rvBGEnWL5zh
         20+jHX/xd+4VR89R/FnAMqWFWUE33XwLjRGjQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750413238; x=1751018038;
        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=6sTuUUBWSSYBoqV1/4Ia/RrBVDTs9rH4NkrSo0YdX5A=;
        b=q58iixQx39Phhdfdve9X+M1z2I7qODYWhMWRhTTcYSSO4LfhHKXJ1L5pKRlvKmsNCx
         n6YOVPdaJqxRshYcXSBzu7j8yWMiYng2v88Sm5LupQWcxSjQaApVZyuaYSxrmgM9Tl7B
         ShfcXOthVSrMUKittTCD3gQdkLztfvSLvlqueStPzBhECH6iPkK7iTVpHp52e4M33FvH
         nd7M5h4SLt+k3frYKAPE6FJoV7BYi0qb/uiMwRTuMViPyeLcoWiVwIZVjR8FLaA7Jtxi
         RIA+uJ6ADm8+2sycLQw2Ik4v+93QLjXj34ZbNEQehw57rg0PMEsMbRFRAfkWBxIauyYM
         gS1w==
X-Gm-Message-State: AOJu0YwJ/d0BcBcma3K7td18gPDqiGmuH0Jw+jEOdVXcykEtKyMby5D3
	Mr2y4xTKwQzPykl6Sw72EWdlRFyDmo8U3K61SenDdy45yuFxiaE85QpkBEzgIu0HQfs=
X-Gm-Gg: ASbGncvr1U0i7ajgpb5ymRyWSlzI4VF9Id/bEnJ/3Dr4wWTFcDsxbcTc/Pg93DXnf4h
	Y6VxkwcA9zyJLMGMZ/jsYvW3Ac70tgHzG5yKRB7kuNAZNm/Ywe6daq7fkHOTICqNELHDGj9xlps
	F++qSxEiuwjelWPorRib3HwyvMGi8Q+YElgKbaEetG0Q37pF5G+kdmRjIo/GgE3rCrF2xRgnKCc
	06PdSys9O2Z7H7x/ScZ9J4jexw63NF41sQrEc9b/l3lddlmaWee4Sf6uR1QCAgn6h0mXZdfq0Pv
	jVeP/8l+GZc6zon8TN7R4c3zPag9ZdwakI9luHiK/al4KRTIp7jCTKh/CWcgAPEXp1fzxPX/cRF
	C1rINaA1lhR9ChAfnxiF+C5NcCQzqb0dXChY=
X-Google-Smtp-Source: AGHT+IHsn/onSdo+ti11S55Rsqb8gQVLZ+uzY/M5CyPBMQPEjr1LY8qDv4e9i7DrW7Ar3aZ6tPEZzg==
X-Received: by 2002:a05:6000:2890:b0:3a4:d4e5:498a with SMTP id ffacd0b85a97d-3a6d130d49cmr1678680f8f.42.1750413238078;
        Fri, 20 Jun 2025 02:53:58 -0700 (PDT)
Date: Fri, 20 Jun 2025 11:53:56 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Ross Lagerwall 
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v3 3/5] crypto: Add RSA support
Message-ID: 
References: <20250602133639.2871212-1-ross.lagerwall@citrix.com>
 <20250602133639.2871212-4-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250602133639.2871212-4-ross.lagerwall@citrix.com>

On Mon, Jun 02, 2025 at 02:36:35PM +0100, Ross Lagerwall wrote:
> In preparation for adding support for livepatch signing, add support for
> RSA crypto.
> 
> The RSA code is extracted from Nettle at tag nettle_3.2_release_20160128
> (https://git.lysator.liu.se/nettle/nettle).
> 
> The MPI code is extracted from Linux at commit eef0df6a5953 (lib/mpi/*).
> 
> Signed-off-by: Ross Lagerwall 
> ---
> 
> In v3:
> 
> * Move mpi.c to lib
> * Fix header guard name
> 
>  xen/crypto/Makefile   |    1 +
>  xen/crypto/rsa.c      |  196 +++++
>  xen/include/xen/mpi.h |   68 ++
>  xen/include/xen/rsa.h |   74 ++
>  xen/lib/Makefile      |    1 +
>  xen/lib/mpi.c         | 1729 +++++++++++++++++++++++++++++++++++++++++

Just FTAOD: all the functions imported in mpi.c are used I think?  So
that we don't introduce unreachable code.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jun 20 10:01:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 10:01:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020772.1396916 (Exim 4.92)
	(envelope-from )
	id 1uSYZ0-0002sL-On; Fri, 20 Jun 2025 10:01:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020772.1396916; Fri, 20 Jun 2025 10:01:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSYZ0-0002sE-Kx; Fri, 20 Jun 2025 10:01:38 +0000
Received: by outflank-mailman (input) for mailman id 1020772;
 Fri, 20 Jun 2025 10:01:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uSYOn-0004kQ-GN
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 09:51:05 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id 1414d8ae-4dbc-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 11:51:03 +0200 (CEST)
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 81B11176A;
 Fri, 20 Jun 2025 02:50:43 -0700 (PDT)
Received: from PWQ0QT7DJ1.arm.com (unknown [10.57.67.38])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8FD223F673;
 Fri, 20 Jun 2025 02:51:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1414d8ae-4dbc-11f0-b894-0df219b8e170
From: Hari Limaye 
To: xen-devel@lists.xenproject.org
Cc: luca.fancellu@arm.com,
	Penny Zheng ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Penny Zheng ,
	Wei Chen 
Subject: [PATCH 4/6] arm/mpu: Destroy an existing entry in Xen MPU memory mapping table
Date: Fri, 20 Jun 2025 10:49:22 +0100
Message-ID: <95cc28af74339ea617081f3935123e38a53cc657.1750411205.git.hari.limaye@arm.com>
X-Mailer: git-send-email 2.42.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Penny Zheng 

This commit expands xen_mpumap_update/xen_mpumap_update_entry to include
destroying an existing entry.

We define a new helper "disable_mpu_region_from_index" to disable the MPU
region based on index. If region is within [0, 31], we could quickly
disable the MPU region through PRENR_EL2 which provides direct access to the
PRLAR_EL2.EN bits of EL2 MPU regions.

Rignt now, we only support destroying a *WHOLE* MPU memory region,
part-region removing is not supported, as in worst case, it will
leave two fragments behind.

Signed-off-by: Penny Zheng 
Signed-off-by: Wei Chen 
Signed-off-by: Luca Fancellu 
Signed-off-by: Hari Limaye 
---
 xen/arch/arm/include/asm/mpu.h        |  2 +
 xen/arch/arm/include/asm/mpu/cpregs.h |  4 ++
 xen/arch/arm/mpu/mm.c                 | 71 ++++++++++++++++++++++++++-
 3 files changed, 75 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/include/asm/mpu.h b/xen/arch/arm/include/asm/mpu.h
index 63560c613b..5053edaf63 100644
--- a/xen/arch/arm/include/asm/mpu.h
+++ b/xen/arch/arm/include/asm/mpu.h
@@ -23,6 +23,8 @@
 #define NUM_MPU_REGIONS_MASK    (NUM_MPU_REGIONS - 1)
 #define MAX_MPU_REGION_NR       NUM_MPU_REGIONS_MASK
 
+#define PRENR_MASK  GENMASK(31, 0)
+
 #ifndef __ASSEMBLY__
 
 /*
diff --git a/xen/arch/arm/include/asm/mpu/cpregs.h b/xen/arch/arm/include/asm/mpu/cpregs.h
index bb15e02df6..9f3b32acd7 100644
--- a/xen/arch/arm/include/asm/mpu/cpregs.h
+++ b/xen/arch/arm/include/asm/mpu/cpregs.h
@@ -6,6 +6,9 @@
 /* CP15 CR0: MPU Type Register */
 #define HMPUIR          p15,4,c0,c0,4
 
+/* CP15 CR6: Protection Region Enable Register */
+#define HPRENR          p15,4,c6,c1,1
+
 /* CP15 CR6: MPU Protection Region Base/Limit/Select Address Register */
 #define HPRSELR         p15,4,c6,c2,1
 #define HPRBAR          p15,4,c6,c3,0
@@ -82,6 +85,7 @@
 /* Alphabetically... */
 #define MPUIR_EL2       HMPUIR
 #define PRBAR_EL2       HPRBAR
+#define PRENR_EL2       HPRENR
 #define PRLAR_EL2       HPRLAR
 #define PRSELR_EL2      HPRSELR
 #endif /* CONFIG_ARM_32 */
diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
index 1de28d2120..23230936f7 100644
--- a/xen/arch/arm/mpu/mm.c
+++ b/xen/arch/arm/mpu/mm.c
@@ -199,6 +199,42 @@ static int xen_mpumap_alloc_entry(uint8_t *idx)
     return 0;
 }
 
+/*
+ * Disable and remove an MPU region from the data structure and MPU registers.
+ *
+ * @param index Index of the MPU region to be disabled.
+ */
+static void disable_mpu_region_from_index(uint8_t index)
+{
+    ASSERT(spin_is_locked(&xen_mpumap_lock));
+    ASSERT(index != INVALID_REGION_IDX);
+
+    if ( !region_is_valid(&xen_mpumap[index]) )
+    {
+        printk(XENLOG_WARNING
+               "mpu: MPU memory region[%u] is already disabled\n", index);
+        return;
+    }
+
+    /* Zeroing the region will also zero the region enable */
+    memset(&xen_mpumap[index], 0, sizeof(pr_t));
+    clear_bit(index, xen_mpumap_mask);
+
+    /*
+     * Both Armv8-R AArch64 and AArch32 have direct access to the enable bit for
+     * MPU regions numbered from 0 to 31.
+     */
+    if ( (index & PRENR_MASK) != 0 )
+    {
+        /* Clear respective bit */
+        uint64_t val = READ_SYSREG(PRENR_EL2) & (~(1UL << index));
+
+        WRITE_SYSREG(val, PRENR_EL2);
+    }
+    else
+        write_protection_region(&xen_mpumap[index], index);
+}
+
 /*
  * Update the entry in the MPU memory region mapping table (xen_mpumap) for the
  * given memory range and flags, creating one if none exists.
@@ -217,11 +253,11 @@ static int xen_mpumap_update_entry(paddr_t base, paddr_t limit,
     ASSERT(spin_is_locked(&xen_mpumap_lock));
 
     rc = mpumap_contain_region(xen_mpumap, max_mpu_regions, base, limit, &idx);
-    if ( (rc < 0) || (rc > MPUMAP_REGION_NOTFOUND) )
+    if ( rc < 0 )
         return -EINVAL;
 
     /* We are inserting a mapping => Create new region. */
-    if ( flags & _PAGE_PRESENT )
+    if ( (flags & _PAGE_PRESENT) && (MPUMAP_REGION_NOTFOUND == rc) )
     {
         rc = xen_mpumap_alloc_entry(&idx);
         if ( rc )
@@ -232,6 +268,22 @@ static int xen_mpumap_update_entry(paddr_t base, paddr_t limit,
         write_protection_region(&xen_mpumap[idx], idx);
     }
 
+    if ( !(flags & _PAGE_PRESENT) && (rc >= MPUMAP_REGION_FOUND) )
+    {
+        /*
+         * Currently, we only support destroying a *WHOLE* MPU memory region,
+         * part-region removing is not supported, as in worst case, it will
+         * leave two fragments behind.
+         */
+        if ( MPUMAP_REGION_INCLUSIVE == rc )
+        {
+            region_printk("mpu: part-region removing is not supported\n");
+            return -EINVAL;
+        }
+
+        disable_mpu_region_from_index(idx);
+    }
+
     return 0;
 }
 
@@ -261,6 +313,21 @@ int xen_mpumap_update(paddr_t base, paddr_t limit, unsigned int flags)
     return rc;
 }
 
+int destroy_xen_mappings(unsigned long s, unsigned long e)
+{
+    int rc;
+
+    ASSERT(IS_ALIGNED(s, PAGE_SIZE));
+    ASSERT(IS_ALIGNED(e, PAGE_SIZE));
+    ASSERT(s <= e);
+
+    rc = xen_mpumap_update(virt_to_maddr(s), virt_to_maddr(e), 0);
+    if ( !rc )
+        context_sync_mpu();
+
+    return rc;
+}
+
 int map_pages_to_xen(unsigned long virt, mfn_t mfn, unsigned long nr_mfns,
                      unsigned int flags)
 {
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Jun 20 10:09:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 10:09:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020791.1396925 (Exim 4.92)
	(envelope-from )
	id 1uSYgh-0003bs-Jq; Fri, 20 Jun 2025 10:09:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020791.1396925; Fri, 20 Jun 2025 10:09: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 1uSYgh-0003bl-H5; Fri, 20 Jun 2025 10:09:35 +0000
Received: by outflank-mailman (input) for mailman id 1020791;
 Fri, 20 Jun 2025 10:09: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 1uSYgg-0003bd-08
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 10:09:34 +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 a8e6e693-4dbe-11f0-a30e-13f23c93f187;
 Fri, 20 Jun 2025 12:09:32 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3a54690d369so1478045f8f.3
 for ; Fri, 20 Jun 2025 03:09:32 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d8393440sm14805875ad.35.2025.06.20.03.09.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 20 Jun 2025 03:09:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a8e6e693-4dbe-11f0-a30e-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750414172; x=1751018972; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=MHFjjp58C1aLxjsSShGWca7HgWMpQZBZEd413SZsb9I=;
        b=SZZUSUVHL7D/7EWZKG1W10BnW+xm0jCWhP/ZgTaVmJopnz1xvbQfKhiSMsLBH0znBA
         kIWdaIjkl6c8iIKDJBZWcO6wIuTlaWM7Ax/zIw41inyQdJq/zWOnQhOAa4qem7Qzz9sv
         XW0rbtVGVBWd4yTIvCY6qaFcCRE4cUtVL3iYxrLNWchLAhZrItxzh+IIiIQlAHnlG0II
         7sSb6Hc6Y5/lvPI0DHkBqk9Ye+HgQ66QUjEiB2uCTwSf1raNh7deypKYE4W0Vz8Nw6GO
         Vzt8C20wixsvoHffWlFt7m/BvIFOxkUrtXuHFA3kq4RkCtRl0WdUr9OCCUV3OnRR2GEy
         zGfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750414172; x=1751018972;
        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=MHFjjp58C1aLxjsSShGWca7HgWMpQZBZEd413SZsb9I=;
        b=pgAmoOu+oCcfpGTIt1aEBcphteO+6dX49iFVxV5Jh7A7Uy0GSGk2FriqYsP8Vs6CyK
         QQr0NqxtFLxzgbcfU0ocsvMS1F8d1H/awBFQJZnkRSfDKOxcpsCPg+9aGT2xTbzWsTwa
         kFesldXnGb0+BlP0Xd1KChaV6puK2f+84bg9d8KO3k+1KqIu9oezB94zycPbS30YVIBr
         TurDtTByq1OR+t9y/5274MbRSS/G/6jjyTmHbty+cbw9JimnYOjPQ/zS2wBQDeWwY1f3
         f7FeN5oLCNj9ld62HrdBCTGF8TTvPSOuBJeG+ARLmvNPtMR0L1j1+z8DVLC0rCbizMLy
         rLZg==
X-Gm-Message-State: AOJu0YyIK0H9E+bHCkXFx3Nw6zCJwAdLYeiiVWkgAMEbOoEQ4fkjwO5N
	VuNeQUYmVXvyjzmOt3tsV456OjV4STUOoRdQ/M1RdVQO31X8f9TywVCYDWZfA+A0zg==
X-Gm-Gg: ASbGncumyFZ2/Kd9zWdkMiEkESIkUDf3tchruINp2zDhBlw1L4dHodQRm1OxArA+c2p
	sOYYg2tv2mURWlFfjjsHOMHI1FfCfUkUCqIVRPf1KhzJfDQccjkyKj2FKmqpnS+CJHVUkpPsoeY
	1nUMyZO8IbRYJ6C4qzzF85P5z+mtHLrXBGkPn/BlR0QJVXdCRElir0OdEyA1fLWkUZjyoeqDTfq
	sj0/EvAFIPYHc3Ifb6q2/wd3FEDmQmCXQa7nuFmR8K7GkR/4+bbksf6k9CorywHIuMIMwAy92Xn
	+ec92z+qf9PLpRmJ33bHruwJ1DG4U4GA4TZbd6Pikd2vjqIaak5PANaCp5n03aYKPlcjhsRA3gw
	jk44vtX8Niw8qd5oPjE8n4Ogda2pvDLOUpz01eGCDDbnbfBU=
X-Google-Smtp-Source: AGHT+IFHqAXql+eP8VW9VtWR93m1D0EEyRjgW29xhKR/PddbQ3vNRyyqJI3p32EbfyF9oeCNHogtbw==
X-Received: by 2002:a05:6000:1447:b0:3a4:f6fe:5244 with SMTP id ffacd0b85a97d-3a6d128a3dcmr1753914f8f.12.1750414171639;
        Fri, 20 Jun 2025 03:09:31 -0700 (PDT)
Message-ID: 
Date: Fri, 20 Jun 2025 12:09:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/5] livepatch: Embed public key in Xen
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Ross Lagerwall 
Cc: xen-devel@lists.xenproject.org, Kevin Lampis ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini 
References: <20250602133639.2871212-1-ross.lagerwall@citrix.com>
 <20250602133639.2871212-3-ross.lagerwall@citrix.com>
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 20.06.2025 11:39, Roger Pau Monné wrote:
> On Mon, Jun 02, 2025 at 02:36:34PM +0100, Ross Lagerwall wrote:
>> From: Kevin Lampis 
>>
>> Make it possible to embed a public key in Xen to be used when verifying
>> live patch payloads. Inclusion of the public key is optional.
>>
>> To avoid needing to include a DER / X.509 parser in the hypervisor, the
>> public key is unpacked at build time and included in a form that is
>> convenient for the hypervisor to consume. This is different approach
>> from that used by Linux which embeds the entire X.509 certificate and
>> builds in a parser for it.
>>
>> A suitable key can be created using openssl:
>>
>> openssl req -x509 -newkey rsa:2048 -keyout priv.pem -out pub.pem \
>>     -sha256 -days 3650 -nodes \
>>     -subj "/C=XX/ST=StateName/L=CityName/O=CompanyName/OU=CompanySectionName/CN=CommonNameOrHostname"
>> openssl x509 -inform PEM -in pub.pem -outform PEM -pubkey -nocert -out verify_key.pem
>>
>> Signed-off-by: Kevin Lampis 
>> Signed-off-by: Ross Lagerwall 
>> ---
>>
>> In v3:
>>
>> * Drop unnecessary condition in Makefile
>> * Use dashes instead of underscores
>> * Drop section placement annotation on declaration
>> * Clarify endianness of embedded key
>>
>>  xen/common/Kconfig          | 18 +++++++++++++++++
>>  xen/crypto/Makefile         | 11 ++++++++++
>>  xen/include/xen/livepatch.h |  5 +++++
>>  xen/tools/extract-key.py    | 40 +++++++++++++++++++++++++++++++++++++
>>  4 files changed, 74 insertions(+)
>>  create mode 100755 xen/tools/extract-key.py
>>
>> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
>> index 0951d4c2f286..74673078202a 100644
>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
>> @@ -472,6 +472,24 @@ config LIVEPATCH
>>  
>>  	  If unsure, say Y.
>>  
>> +config PAYLOAD_VERIFY
>> +	bool "Verify signed LivePatch payloads"
>> +	depends on LIVEPATCH
>> +	select CRYPTO
>> +	help
>> +	  Verify signed LivePatch payloads using an RSA public key built
>> +	  into the Xen hypervisor. Selecting this option requires a
>> +	  public key in PEM format to be available for embedding during
>> +	  the build.
>> +
>> +config PAYLOAD_VERIFY_KEY
>> +	string "File name of public key used to verify payloads"
>> +	default "verify_key.pem"
>> +	depends on PAYLOAD_VERIFY
>> +	help
>> +	  The file name of an RSA public key in PEM format to be used for
>> +	  verifying signed LivePatch payloads.
> 
> I think this is likely to break the randconfig testing that we do in
> Gitlab CI, as randconfig could select PAYLOAD_VERIFY, but there will
> be no key included, and hence the build will fail?
> 
> Ideally Gitlab CI would need to be adjusted to provide such key so the
> build doesn't fail.  I think it could be provided unconditionally to
> simplify the logic, if the option is not selected the file will simply
> be ignored.

Alternatively the two options could be folded, the default being the
empty string meaning "no payload verification". I don't think randconfig
can sensibly make up random strings ...

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jun 20 10:31:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 10:31:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020803.1396935 (Exim 4.92)
	(envelope-from )
	id 1uSZ1i-0007fE-9e; Fri, 20 Jun 2025 10:31:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020803.1396935; Fri, 20 Jun 2025 10:31: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 1uSZ1i-0007f7-6i; Fri, 20 Jun 2025 10:31:18 +0000
Received: by outflank-mailman (input) for mailman id 1020803;
 Fri, 20 Jun 2025 10:31: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 1uSZ1h-0007f1-SP
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 10:31:17 +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 b28761be-4dc1-11f0-a30e-13f23c93f187;
 Fri, 20 Jun 2025 12:31:16 +0200 (CEST)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-450ccda1a6eso15164925e9.2
 for ; Fri, 20 Jun 2025 03:31:16 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-4535eac8e19sm54523785e9.21.2025.06.20.03.31.15
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 20 Jun 2025 03:31:15 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b28761be-4dc1-11f0-a30e-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750415476; x=1751020276; 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=0Zu2JUyMtVf4W61pXTxOrDQ/5q2YnhtKq7a8USSKDZs=;
        b=kbRFVpxyfWPljtuTDJduwNpXcAAokxTdTJ5OcmNo+o9snM58xu0dT9bmBWiJIvKbCY
         QaRTDVdKSzJoGbUvcNoZVZuN74pPiFQBy0MD4RCVLUv12jh5otJc4A30g8/+JwJL1Qvq
         iYfGvbCOE0z07tECXrLnufI7HaUs9T1eySGfc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750415476; x=1751020276;
        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=0Zu2JUyMtVf4W61pXTxOrDQ/5q2YnhtKq7a8USSKDZs=;
        b=q/C0W7ZYMYE7obkZyk+pVsgc50y/gAQIfTeUmsdK6/QERLrXHhlDYOH6QbyFkeM596
         4aJWELFNKzfdXvqXivx+MaEM7HVLLHWN4ZzVNkNJ90o6YSf/YpNYSHmB+1jvfAGSmRjn
         59wzKOvRe1EFA7gBpesYDurpU3w94UAp5ecIg3HyVRau9lr7s8MObXt6csojlJ2nEbNW
         7Xz/JnIbMrDmcG1O44PahQQpuVLlBb3VT1umKPwkHidvgYNppZl/dolNhOAc/y3cC/Z2
         i9ViXF4A2bMRqt1C+GyKXi6T7LOdU5OFy2ccs8rv81T5Zi/MV0mwJem9k5XVbwij/AuH
         w2OA==
X-Gm-Message-State: AOJu0YxaZID2yh1n6si752ldJkY7nXCLwKMPd8uMjKm9Oki4smePk+2G
	NrrDtnjnEyotYAPeMG03OELZ4I0ysGHy9tFzwLKREJ8k9LIcsOTjsesxwKfjlPmpnmQ=
X-Gm-Gg: ASbGnctzyohq62sJECXSg3au/SMcPRVgE0EcH+zfNzCsYeDE2LYkDQeOh3VgpKsU1ly
	G+0vgFntG/b+4XQm4D1U7llNRZbBRhHYQbJ3x0NL5SiytqAS3OsotFZzM/QPW40S/ZYXXZa6fLL
	wvt+P4LAzXu/tR0eQEfRRy9bDVQrqCffw9Kfcv8OXOJ7q+MAYgNW8bzlKnBwCGFi03EaXzpD/2N
	/JEcuk/nZoyyAGmQf+J+WT5lFn2hQkly3WWIROI+IGMx7riJoX4hAy7xAysoM4BrR0C04kU8TAX
	VXpWEKEVsEwhvnboSdJtmQGbnu/1ZHGAMmQ0kY+QcSI3JPCaVQh6Ty65r2RuCpwQvKK3Ov7KsPx
	68VDy1dQDI2EmmyIWp9o4HTs0KCkIRQ==
X-Google-Smtp-Source: AGHT+IEzeDSOLbShiPaJpgwwCdMMxx81y4RPsn8wh8l2SUxKq2E7MgBxcUUJa4mtdDW4U+bu1XCI5Q==
X-Received: by 2002:a05:600c:8905:b0:450:cabd:b4a9 with SMTP id 5b1f17b1804b1-45365a051a2mr16694785e9.29.1750415476182;
        Fri, 20 Jun 2025 03:31:16 -0700 (PDT)
Date: Fri, 20 Jun 2025 12:31:14 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Ross Lagerwall 
Cc: xen-devel@lists.xenproject.org,
	Jennifer Herbert 
Subject: Re: [PATCH v3 5/5] livepatch: Verify livepatch signatures
Message-ID: 
References: <20250602133639.2871212-1-ross.lagerwall@citrix.com>
 <20250602133639.2871212-6-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250602133639.2871212-6-ross.lagerwall@citrix.com>

On Mon, Jun 02, 2025 at 02:36:37PM +0100, Ross Lagerwall wrote:
> From: Jennifer Herbert 
> 
> Verify livepatch signatures against the embedded public key in Xen.
> Failing to verify does not prevent the livepatch from being loaded.
> In future, this will be changed for certain cases (e.g. when Secure Boot
> is enabled).
> 
> Signed-off-by: Jennifer Herbert 
> Signed-off-by: Ross Lagerwall 
> ---
> 
> In v3:
> 
> * Minor style fixes
> 
>  xen/common/livepatch.c          | 103 ++++++++++++++++++++++++++++++++
>  xen/common/livepatch_elf.c      |  55 +++++++++++++++++
>  xen/include/xen/livepatch.h     |  10 ++++
>  xen/include/xen/livepatch_elf.h |  18 ++++++
>  4 files changed, 186 insertions(+)
> 
> diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
> index 92d1d342d872..56a3d125483f 100644
> --- a/xen/common/livepatch.c
> +++ b/xen/common/livepatch.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -525,6 +526,106 @@ static int check_xen_buildid(const struct livepatch_elf *elf)
>      return 0;
>  }
>  
> +#ifdef CONFIG_PAYLOAD_VERIFY
> +static int check_rsa_sha256_signature(void *data, size_t datalen,
> +                                      void *sig, uint32_t siglen)

I think both data and sig could be const here?

> +{
> +    struct sha2_256_state hash;
> +    MPI s;
> +    int rc;
> +
> +    s = mpi_read_raw_data(sig, siglen);
> +    if ( !s )
> +    {
> +        printk(XENLOG_ERR LIVEPATCH "Failed to mpi_read_raw_data\n");
> +        return -ENOMEM;
> +    }
> +
> +    sha2_256_init(&hash);
> +    sha2_256_update(&hash, data, datalen);
> +
> +    rc = rsa_sha256_verify(&builtin_payload_key, &hash, s);
> +    if ( rc )
> +        printk(XENLOG_ERR LIVEPATCH "rsa_sha256_verify failed: %d\n", rc);
> +
> +    mpi_free(s);
> +
> +    return rc;
> +}
> +#endif
> +
> +static int check_signature(const struct livepatch_elf *elf, void *raw,
> +                           size_t size)
> +{
> +#ifdef CONFIG_PAYLOAD_VERIFY
> +#define MAX_SIG_NOTE_SIZE 1024
> +    static const char notename[] = "Xen";
> +    void *sig;
> +    livepatch_elf_note note;
> +    int rc;
> +
> +    rc = livepatch_elf_note_by_names(elf, ELF_XEN_SIGNATURE, notename, -1,
> +                                     ¬e);
> +    if ( rc )
> +    {
> +        dprintk(XENLOG_DEBUG, LIVEPATCH "%s: Signature not present\n",
> +                elf->name);
> +        return rc;
> +    }
> +
> +    /* We expect only one signature, find a second is an error! */
> +    rc = livepatch_elf_next_note_by_name(notename, -1, ¬e);
> +    if ( rc != -ENOENT )
> +    {
> +        if ( rc )
> +        {
> +            printk(XENLOG_ERR LIVEPATCH
> +                   "Error while checking for notes! err = %d\n", rc);
> +            return rc;
> +        }
> +        else
> +        {
> +            printk(XENLOG_ERR LIVEPATCH
> +                   "Error, found second signature note! There can be only one!\n");

FWIW, it's a nit, but I think there are too many exclamation marks in
the error message above:

"Error, multiple signatures found\n"

Would be better.

I'm also wondering, would it make sense to allow multiple signatures
to be present?  I guess not because livepatches are built for specific
Xen binaries, and then we know exactly which key is embedded there.  A
livepatch would never apply to two different builds with different
keys.

> +            return -EINVAL;
> +        }
> +    }
> +
> +    if ( SIGNATURE_VERSION(note.type) != LIVEPATCH_SIGNATURE_VERSION ||
> +         SIGNATURE_ALGORITHM(note.type) != SIGNATURE_ALGORITHM_RSA ||
> +         SIGNATURE_HASH(note.type) != SIGNATURE_HASH_SHA256 )
> +    {
> +        printk(XENLOG_ERR LIVEPATCH
> +               "Unsupported signature type: v:%u, a:%u, h:%u\n",
> +               SIGNATURE_VERSION(note.type), SIGNATURE_ALGORITHM(note.type),
> +               SIGNATURE_HASH(note.type));
> +        return -EINVAL;
> +    }
> +
> +    if ( note.size == 0 || note.size >= MAX_SIG_NOTE_SIZE )
> +    {
> +        printk(XENLOG_ERR LIVEPATCH "Invalid signature note size: %u\n",
> +               note.size);
> +        return -EINVAL;
> +    }
> +
> +    sig = xmalloc_bytes(note.size);
> +    if ( !sig )
> +        return -ENOMEM;
> +
> +    memcpy(sig, note.data, note.size);
> +
> +    /* Remove signature from data, as can't be verified with it. */
> +    memset((void *)note.data, 0, note.size);
> +    rc = check_rsa_sha256_signature(raw, size, sig, note.size);
> +
> +    xfree(sig);
> +    return rc;
> +#else
> +    return -EINVAL;

EOPNOTSUPP would be more accurate here.

> +#endif
> +}
> +
>  static int check_special_sections(const struct livepatch_elf *elf)
>  {
>      unsigned int i;
> @@ -1162,6 +1263,8 @@ static int load_payload_data(struct payload *payload, void *raw, size_t len)
>      if ( rc )
>         goto out;
>  
> +    check_signature(&elf, raw, len);

Wouldn't it make more sense to unconditionally fail here if
CONFIG_PAYLOAD_VERIFY is enabled and signature verification fails?

IOW: if you built an hypervisor with PAYLOAD_VERIFY enabled signature
verification needs to be enforced.

> +
>      rc = move_payload(payload, &elf);
>      if ( rc )
>          goto out;
> diff --git a/xen/common/livepatch_elf.c b/xen/common/livepatch_elf.c
> index 25ce1bd5a0ad..b27c4524611d 100644
> --- a/xen/common/livepatch_elf.c
> +++ b/xen/common/livepatch_elf.c
> @@ -23,6 +23,61 @@ livepatch_elf_sec_by_name(const struct livepatch_elf *elf,
>      return NULL;
>  }
>  
> +int livepatch_elf_note_by_names(const struct livepatch_elf *elf,
> +                                const char *sec_name, const char *note_name,
> +                                const unsigned int type,
> +                                livepatch_elf_note *note)
> +{
> +     const struct livepatch_elf_sec *sec = livepatch_elf_sec_by_name(elf,
> +                                                                     sec_name);
> +     if ( !sec )
> +           return -ENOENT;
> +
> +     note->end = sec->addr + sec->sec->sh_size;
> +     note->next = sec->addr;
> +
> +     return livepatch_elf_next_note_by_name(note_name, type, note);
> +}
> +
> +int livepatch_elf_next_note_by_name(const char *note_name,
> +                                    const unsigned int type,
> +                                    livepatch_elf_note *note)
> +{
> +     const Elf_Note *pkd_note = note->next;
> +     size_t notenamelen = strlen(note_name) + 1;
> +     size_t note_hd_size;
> +     size_t note_size;
> +     size_t remaining;
> +
> +     while ( (void *)pkd_note < note->end )
> +     {
> +

Stray newline?

remaining and note_hd_size can be defined inside of the loop to reduce
the scope.

> +         remaining = note->end - (void *)pkd_note;
> +         if ( remaining < sizeof(livepatch_elf_note) )
> +             return -EINVAL;
> +
> +         note_hd_size = sizeof(Elf_Note) + ((pkd_note->namesz + 3) & ~0x3);
> +         note_size = note_hd_size + ((pkd_note->descsz + 3) & ~0x3);

Could be have a macro or similar for this ((x + 3) & ~0x3)
manipulation?

> +         if ( remaining < note_size )
> +             return -EINVAL;

ENOSPC might be less ambiguous than EINVAL for both the above?

> +
> +         if ( notenamelen == pkd_note->namesz &&
> +              !memcmp(note_name, (const void *) pkd_note + sizeof(Elf_Note),
> +                      notenamelen) &&
> +              (type == -1 || pkd_note->type == type) )
> +         {
> +             note->size = pkd_note->descsz;
> +             note->type = pkd_note->type;
> +             note->data = (void *)pkd_note + note_hd_size;
> +             note->next = (void *)pkd_note + note_size;
> +             return 0;
> +         }
> +         pkd_note = (void *)pkd_note + note_size;
> +     }

It's a nit, but I would write this as a for loop, as it's clearer then
the index advance:

for ( pkd_note = note->next; (void *)pkd_note < note->end;
      pkd_note = (void *)pkd_note + note_size )
{
...

> +
> +     return -ENOENT;
> +}
> +
>  static int elf_verify_strtab(const struct livepatch_elf_sec *sec)
>  {
>      const Elf_Shdr *s;
> diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h
> index 52f90cbed45b..12206ce3b2b8 100644
> --- a/xen/include/xen/livepatch.h
> +++ b/xen/include/xen/livepatch.h
> @@ -38,6 +38,7 @@ struct xen_sysctl_livepatch_op;
>  #define ELF_LIVEPATCH_DEPENDS     ".livepatch.depends"
>  #define ELF_LIVEPATCH_XEN_DEPENDS ".livepatch.xen_depends"
>  #define ELF_BUILD_ID_NOTE         ".note.gnu.build-id"
> +#define ELF_XEN_SIGNATURE         ".note.Xen.signature"
>  #define ELF_LIVEPATCH_LOAD_HOOKS      ".livepatch.hooks.load"
>  #define ELF_LIVEPATCH_UNLOAD_HOOKS    ".livepatch.hooks.unload"
>  #define ELF_LIVEPATCH_PREAPPLY_HOOK   ".livepatch.hooks.preapply"
> @@ -49,6 +50,15 @@ struct xen_sysctl_livepatch_op;
>  /* Arbitrary limit for payload size and .bss section size. */
>  #define LIVEPATCH_MAX_SIZE     MB(2)
>  
> +#define SIGNATURE_VERSION(type) ((type) & 0xffff)
> +#define LIVEPATCH_SIGNATURE_VERSION 1
> +
> +#define SIGNATURE_ALGORITHM(type) (((type) >> 16) & 0xff)
> +#define SIGNATURE_ALGORITHM_RSA 0
> +
> +#define SIGNATURE_HASH(type) (((type) >> 24) & 0xff)
> +#define SIGNATURE_HASH_SHA256 0

You could possibly use MASK_EXTR() for the macros above?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jun 20 10:31:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 10:31:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020805.1396945 (Exim 4.92)
	(envelope-from )
	id 1uSZ1w-0007x6-Gh; Fri, 20 Jun 2025 10:31:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020805.1396945; Fri, 20 Jun 2025 10: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 1uSZ1w-0007wz-DT; Fri, 20 Jun 2025 10:31:32 +0000
Received: by outflank-mailman (input) for mailman id 1020805;
 Fri, 20 Jun 2025 10: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 1uSZ1v-0007f1-CS
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 10:31:31 +0000
Received: from rein-hpcbdc09 (unknown [1.6.89.6])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b90f4a70-4dc1-11f0-a30e-13f23c93f187;
 Fri, 20 Jun 2025 12:31:29 +0200 (CEST)
Received: by rein-hpcbdc09 (Postfix, from userid 1000)
 id 5C96880C0884; Fri, 20 Jun 2025 16:01:26 +0530 (IST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b90f4a70-4dc1-11f0-a30e-13f23c93f187
From: Jahan Murudi 
To: xen-devel@lists.xenproject.org
Cc: Jahan Murudi ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH] xen/arm: Enhance IPMMU-VMSA driver robustness and debug output
Date: Fri, 20 Jun 2025 16:01:23 +0530
Message-Id: <20250620103123.2174529-1-jahan.murudi.zg@renesas.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

- Fix typo in source comment ("you can found" -> "which can be found").
- Add dsb(sy) after IMCTR write to ensure flush is complete before polling.
- Add dev_info() log in ipmmu_device_reset() to indicate the number of disabled contexts.

These changes improve memory operation ordering, code readability, and runtime traceability
for IPMMU on R-Car Gen3/Gen4 SoCs

Signed-off-by: Jahan Murudi 
---
 xen/drivers/passthrough/arm/ipmmu-vmsa.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/passthrough/arm/ipmmu-vmsa.c b/xen/drivers/passthrough/arm/ipmmu-vmsa.c
index d828d9cf6a..dac0dd6d46 100644
--- a/xen/drivers/passthrough/arm/ipmmu-vmsa.c
+++ b/xen/drivers/passthrough/arm/ipmmu-vmsa.c
@@ -13,7 +13,7 @@
  *
  * Based on Linux's IPMMU-VMSA driver from Renesas BSP:
  *    drivers/iommu/ipmmu-vmsa.c
- * you can found at:
+ * which can be found at:
  *    url: git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git
  *    branch: v4.14.75-ltsi/rcar-3.9.6
  *    commit: e206eb5b81a60e64c35fbc3a999b1a0db2b98044
@@ -433,6 +433,8 @@ static void ipmmu_tlb_invalidate(struct ipmmu_vmsa_domain *domain)
     data |= IMCTR_FLUSH;
     ipmmu_ctx_write_all(domain, IMCTR, data);
 
+    /* Force IMCTR write to complete before polling to avoid false completion check. */
+    dsb(sy);
     ipmmu_tlb_sync(domain);
 }
 
@@ -780,6 +782,8 @@ static void ipmmu_device_reset(struct ipmmu_vmsa_device *mmu)
     /* Disable all contexts. */
     for ( i = 0; i < mmu->num_ctx; ++i )
         ipmmu_ctx_write(mmu, i, IMCTR, 0);
+
+    dev_info(mmu->dev, "Reset completed, disabled %u contexts\n", mmu->num_ctx);
 }
 
 /* R-Car Gen3/Gen4 SoCs product and cut information. */
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Jun 20 10:33:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 10:33:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020817.1396956 (Exim 4.92)
	(envelope-from )
	id 1uSZ3q-0000FJ-SF; Fri, 20 Jun 2025 10:33:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020817.1396956; Fri, 20 Jun 2025 10: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 1uSZ3q-0000FC-OE; Fri, 20 Jun 2025 10:33:30 +0000
Received: by outflank-mailman (input) for mailman id 1020817;
 Fri, 20 Jun 2025 10:33: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 1uSZ3p-0000F6-K0
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 10:33:29 +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 01299a33-4dc2-11f0-a30e-13f23c93f187;
 Fri, 20 Jun 2025 12:33:28 +0200 (CEST)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-45348bff79fso19325045e9.2
 for ; Fri, 20 Jun 2025 03:33:28 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-453646fd816sm20791325e9.24.2025.06.20.03.33.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 20 Jun 2025 03:33:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 01299a33-4dc2-11f0-a30e-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750415608; x=1751020408; 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=WpBWZi53WDfZleXq1qmgrCIdkQnOQoPAV/yzUadBfo8=;
        b=PMCC2zdikX3+c6lDLIqaCg6JPPF3OwE0bkvwCf70r70lIOxKpvEQYbCt5+1uxnKbCB
         Sq95OeXE5LwgDr6Eu7alEVl9UYqeNCkpYNHB5Y86OQqF2D7idKSqwFnc5AaXwSyWZxHY
         aLAv5XTTcDyg67ADmCbdlQjnCAnduAdLAj4dY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750415608; x=1751020408;
        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=WpBWZi53WDfZleXq1qmgrCIdkQnOQoPAV/yzUadBfo8=;
        b=h3EKjN9ijTPaSS+Bh5lsB2109nELDD7JrwJ3bZF+NBHLUR6pDLyzI5gov84o5Kljm8
         4VVXFi6mYpwtoEJ2IVf4Fha/Ugjd7D7ZyDFMjkrK9CPwUqgWM8/cckz/kHY1iKVTY0hw
         JMHNj6Ijwk+RlZC79hg04JeUMAs3meQFNXHQZr5Ib4pdnhK72JEioT/UB/8sMfIGhzqp
         8FkBeNjgVHO1vaoqqmps1P7MYtG6dgMpIyfV+OiASXj2xXP2nUOX8obrTCI7fq8G9N5X
         J8r+cNEQxdAfcNoviB8nXWkPTi52vt/nh46jpsw/Fe8cHhUTFp6bWRbSE5G6ysNoKimn
         CZWg==
X-Forwarded-Encrypted: i=1; AJvYcCWVgSoga62lQ5+5yhqNVXoCZzIWZs4DV4+sRMVZ1C6cPfmNG+kFfOdmliMhpF80d61IHyIzc8qv+Mw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxd/FpeHW9y1j0YEUySeWfpLCMJnu+iJl+JWcUWqzN1VppvLd1s
	Pz2uAY3iHdbEzelMvDBEloK7MvyClA5ZZs0a/EfuTzsz/Z+jGnskc+gGky0s+BiiQBU=
X-Gm-Gg: ASbGncsaC4BsOR4BfZwSBbf1pp79hCSZlOAXGWjztO+dAOZ8LHpFNYKXSgXMfGv2RjD
	O1vIcG7TiPVVk/V3GiFQifPuDPam4BFP+hLXH3B4LCQG08bREV6py2915BxRoVyru+Z2Mbc/Czf
	ewbD8FQBmeKk8gcy8jJbvoyaUNwsX0gjD+EVHou0dSr5w+wgZSN0m769tK7XML5ebP1u/BUdoGl
	10f3qyex3rb4TAfAXYfUI+A1vRyKONlozem7XWbA1rHU4i1Uwo2C7FvMVbeDDBfBkTKMm9FAik1
	KzhIdR5NUbVxqv6xUN/40UwhqzNzlDHzLGsZXCGPi/xnTQwdL0nAr/JHx78Iubkehu//BhfrzIm
	QFf/AaA8YOufZQfbTbtSBMa765LC+4w==
X-Google-Smtp-Source: AGHT+IH0oFbwqe0ayHOh6UMaufWW2rI3lrnR6GsZoXszDkGBkKF6CpmwzLaDmFtKDqA7NGK7SgRyzA==
X-Received: by 2002:a05:600c:64cd:b0:453:6146:1172 with SMTP id 5b1f17b1804b1-453659b67femr22854825e9.3.1750415608217;
        Fri, 20 Jun 2025 03:33:28 -0700 (PDT)
Date: Fri, 20 Jun 2025 12:33:26 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Ross Lagerwall ,
	xen-devel@lists.xenproject.org,
	Kevin Lampis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v3 2/5] livepatch: Embed public key in Xen
Message-ID: 
References: <20250602133639.2871212-1-ross.lagerwall@citrix.com>
 <20250602133639.2871212-3-ross.lagerwall@citrix.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Fri, Jun 20, 2025 at 12:09:21PM +0200, Jan Beulich wrote:
> On 20.06.2025 11:39, Roger Pau Monné wrote:
> > On Mon, Jun 02, 2025 at 02:36:34PM +0100, Ross Lagerwall wrote:
> >> From: Kevin Lampis 
> >>
> >> Make it possible to embed a public key in Xen to be used when verifying
> >> live patch payloads. Inclusion of the public key is optional.
> >>
> >> To avoid needing to include a DER / X.509 parser in the hypervisor, the
> >> public key is unpacked at build time and included in a form that is
> >> convenient for the hypervisor to consume. This is different approach
> >> from that used by Linux which embeds the entire X.509 certificate and
> >> builds in a parser for it.
> >>
> >> A suitable key can be created using openssl:
> >>
> >> openssl req -x509 -newkey rsa:2048 -keyout priv.pem -out pub.pem \
> >>     -sha256 -days 3650 -nodes \
> >>     -subj "/C=XX/ST=StateName/L=CityName/O=CompanyName/OU=CompanySectionName/CN=CommonNameOrHostname"
> >> openssl x509 -inform PEM -in pub.pem -outform PEM -pubkey -nocert -out verify_key.pem
> >>
> >> Signed-off-by: Kevin Lampis 
> >> Signed-off-by: Ross Lagerwall 
> >> ---
> >>
> >> In v3:
> >>
> >> * Drop unnecessary condition in Makefile
> >> * Use dashes instead of underscores
> >> * Drop section placement annotation on declaration
> >> * Clarify endianness of embedded key
> >>
> >>  xen/common/Kconfig          | 18 +++++++++++++++++
> >>  xen/crypto/Makefile         | 11 ++++++++++
> >>  xen/include/xen/livepatch.h |  5 +++++
> >>  xen/tools/extract-key.py    | 40 +++++++++++++++++++++++++++++++++++++
> >>  4 files changed, 74 insertions(+)
> >>  create mode 100755 xen/tools/extract-key.py
> >>
> >> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> >> index 0951d4c2f286..74673078202a 100644
> >> --- a/xen/common/Kconfig
> >> +++ b/xen/common/Kconfig
> >> @@ -472,6 +472,24 @@ config LIVEPATCH
> >>  
> >>  	  If unsure, say Y.
> >>  
> >> +config PAYLOAD_VERIFY
> >> +	bool "Verify signed LivePatch payloads"
> >> +	depends on LIVEPATCH
> >> +	select CRYPTO
> >> +	help
> >> +	  Verify signed LivePatch payloads using an RSA public key built
> >> +	  into the Xen hypervisor. Selecting this option requires a
> >> +	  public key in PEM format to be available for embedding during
> >> +	  the build.
> >> +
> >> +config PAYLOAD_VERIFY_KEY
> >> +	string "File name of public key used to verify payloads"
> >> +	default "verify_key.pem"
> >> +	depends on PAYLOAD_VERIFY
> >> +	help
> >> +	  The file name of an RSA public key in PEM format to be used for
> >> +	  verifying signed LivePatch payloads.
> > 
> > I think this is likely to break the randconfig testing that we do in
> > Gitlab CI, as randconfig could select PAYLOAD_VERIFY, but there will
> > be no key included, and hence the build will fail?
> > 
> > Ideally Gitlab CI would need to be adjusted to provide such key so the
> > build doesn't fail.  I think it could be provided unconditionally to
> > simplify the logic, if the option is not selected the file will simply
> > be ignored.
> 
> Alternatively the two options could be folded, the default being the
> empty string meaning "no payload verification". I don't think randconfig
> can sensibly make up random strings ...

Could be an option.  Not sure if the menu interface would then look a
bit weird.  IMO it's a nicer UI to enable the option and then get
asked for the cert to use rather than bundling everything in a single
string-like option.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jun 20 11:11:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 11:11:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020851.1397028 (Exim 4.92)
	(envelope-from )
	id 1uSZes-0006w3-3Y; Fri, 20 Jun 2025 11:11:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020851.1397028; Fri, 20 Jun 2025 11: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 1uSZer-0006uZ-RG; Fri, 20 Jun 2025 11:11:45 +0000
Received: by outflank-mailman (input) for mailman id 1020851;
 Fri, 20 Jun 2025 11:11: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 1uSZeq-0005XV-Am
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 11:11:44 +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 5845fd68-4dc7-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 13:11:42 +0200 (CEST)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-450cf0120cdso14038345e9.2
 for ; Fri, 20 Jun 2025 04:11:42 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-453646cb672sm22375835e9.6.2025.06.20.04.11.40
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 20 Jun 2025 04:11:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5845fd68-4dc7-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750417901; x=1751022701; darn=lists.xenproject.org;
        h=content-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=EsCxSro0G0kDL5DT8H/ufk+WFItshO7wcFGLxBzt6rg=;
        b=WslG60dSTAlpK/m9Gfqx+bNg7qSCGbMcECr955Ie1K7wsrghP4WypS/DHH3bPuG2OO
         e9jfSjBg+EEQ3Uacnx0JRu0OMfqqHb6Xen/tJExruFzmuhC4IfTkyE3KwSdYv5nkb9S1
         LSlFwoPBfEBAGLd0GBc/TCh4qW7YXsXuOGI9w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750417901; x=1751022701;
        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=EsCxSro0G0kDL5DT8H/ufk+WFItshO7wcFGLxBzt6rg=;
        b=UcMOsb1kKyyUHax7hmNHM2zeLu+v/4NELclmYTCk4Zm4duyXMadxxcnefNuKBnOr1f
         SMD5IsxsNng2QB8VTi2VbBq2hZpaciw5sEgKI1isJZqql7XXqrVpzMpVrFw1ZLKI3dj1
         AnctFyKoYIFXXgxuZsQn0PVozLBntUoPvbRjOr9dbKrG7bFeZC/WFQhgTOxs4hPea01a
         jnuLW8AkbGAYBbsVDCFm3SjCbd9VDGjW8zKkkJkcNm7qRKQDqiwrMxK82ugS9Sddcu3W
         q8iFp5OJbIhSOlfmauExtiEq1Hllyho1DzddBlOyGya8rIJ5/GvecbmlJIfbMqmK2d/N
         LLig==
X-Gm-Message-State: AOJu0YyvPtE3eK+LN1Ab7+q2TWnRONicQvxqxrA0fWuoofr53mhmQXn7
	somxHL1GlnZiWwQGA2clu3930YDDJL8JH13GVi5Nim5KCcsqbdM2TGhycvu4woAGMP3vOKVK8W2
	ItAH9
X-Gm-Gg: ASbGncs0XGwI6afLLoVSsq0PfwdL/8K6gGqJMcrgpDbRYkZY6fr5L4tQSSQUTrx4Pn4
	g/ZAFwrbWd4KcevKHCVUo7e4/kU77oQDo+Vh9PaRYgOTucYHvXtOl5Acr9hNSt81hjV448TR79W
	j2fJPvOTEnJWc/w9w4l6lzo6PW/xn96SQ2z2jeaDheOSJgvCA+vBCqTyHKLHZUmPx0WIL5YHnov
	b7HRDkijCzS9D1ic1GwIFYYg4h1Ur6Jkh6Mio+xA65iy1GpKxvYej9SE0eq/ru/AmVEU4quSDkB
	OLwX4lQvJ/oSDN9Go/z+1VNDORstox/KvdS1AtAD6zO3t9HN6KQMIrpGuUUru+C2dZVXmcsd8Es
	nCYik+gmlEy6vhKpkTxh2L++6NhdISg==
X-Google-Smtp-Source: AGHT+IF6i1WhfFMFyhSmrPUes6Q3jZ77HAhhSPCYQfxYrKJeXFhYKfQou/CrlO18cgXG6ohBKLxNiA==
X-Received: by 2002:a5d:64cc:0:b0:3a5:26fd:d450 with SMTP id ffacd0b85a97d-3a6d12eb3dfmr1939933f8f.47.1750417901384;
        Fri, 20 Jun 2025 04:11:41 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Anthony PERARD ,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH v2 6/8] test/pdx: add PDX compression unit tests
Date: Fri, 20 Jun 2025 13:11:28 +0200
Message-ID: <20250620111130.29057-7-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250620111130.29057-1-roger.pau@citrix.com>
References: <20250620111130.29057-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Introduce a set of unit tests for PDX compression.  The unit tests contains
both real and crafted memory maps that are then compressed using the
selected PDX algorithm.  Note the build system for the unit tests has been
done in a way to support adding new compression algorithms easily.  That
requires generating a new test-pdx- executable that's build with
the selected PDX compression enabled.

Currently the only generated executable is test-pdx-mask that tests PDX
mask compression.

Signed-off-by: Roger Pau Monné 
---
Changes since v1:
 - New in this version (partially pulled out from a different patch).
---
 tools/tests/Makefile       |   1 +
 tools/tests/pdx/.gitignore |   2 +
 tools/tests/pdx/Makefile   |  48 ++++++++
 tools/tests/pdx/harness.h  |  89 +++++++++++++++
 tools/tests/pdx/test-pdx.c | 220 +++++++++++++++++++++++++++++++++++++
 xen/common/pdx.c           |   4 +
 6 files changed, 364 insertions(+)
 create mode 100644 tools/tests/pdx/.gitignore
 create mode 100644 tools/tests/pdx/Makefile
 create mode 100644 tools/tests/pdx/harness.h
 create mode 100644 tools/tests/pdx/test-pdx.c

diff --git a/tools/tests/Makefile b/tools/tests/Makefile
index 36928676a666..97ba2a13894d 100644
--- a/tools/tests/Makefile
+++ b/tools/tests/Makefile
@@ -9,6 +9,7 @@ ifneq ($(clang),y)
 SUBDIRS-$(CONFIG_X86) += x86_emulator
 endif
 SUBDIRS-y += xenstore
+SUBDIRS-y += pdx
 SUBDIRS-y += rangeset
 SUBDIRS-y += vpci
 SUBDIRS-y += paging-mempool
diff --git a/tools/tests/pdx/.gitignore b/tools/tests/pdx/.gitignore
new file mode 100644
index 000000000000..a32c7db4de79
--- /dev/null
+++ b/tools/tests/pdx/.gitignore
@@ -0,0 +1,2 @@
+/pdx.h
+/test-pdx-mask
diff --git a/tools/tests/pdx/Makefile b/tools/tests/pdx/Makefile
new file mode 100644
index 000000000000..99867b71c438
--- /dev/null
+++ b/tools/tests/pdx/Makefile
@@ -0,0 +1,48 @@
+XEN_ROOT=$(CURDIR)/../../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+TARGETS := test-pdx-mask
+
+.PHONY: all
+all: $(TARGETS)
+
+.PHONY: run
+run: $(TARGETS)
+ifeq ($(CC),$(HOSTCC))
+	for test in $? ; do \
+		./$$test ;  \
+	done
+else
+	$(warning HOSTCC != CC, will not run test)
+endif
+
+.PHONY: clean
+clean:
+	$(RM) -- *.o $(TARGETS) $(DEPS_RM) pdx.c pdx.h
+
+.PHONY: distclean
+distclean: clean
+	$(RM) -- *~
+
+.PHONY: install
+install: all
+	$(INSTALL_DIR) $(DESTDIR)$(LIBEXEC)/tests
+	$(INSTALL_PROG) $(TARGETS) $(DESTDIR)$(LIBEXEC)/tests
+
+.PHONY: uninstall
+uninstall:
+	$(RM) -- $(patsubst %,$(DESTDIR)$(LIBEXEC)/tests/%,$(TARGETS))
+
+pdx.h: $(XEN_ROOT)/xen/include/xen/pdx.h
+	sed -E -e '/^#[[:space:]]?include/d' <$< >$@
+
+CFLAGS += -D__XEN_TOOLS__
+CFLAGS += $(APPEND_CFLAGS)
+CFLAGS += $(CFLAGS_xeninclude)
+
+test-pdx-mask: CFLAGS += -DCONFIG_PDX_MASK_COMPRESSION
+
+test-pdx-%: test-pdx.c pdx.h
+	$(CC) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_$*.o) -o $@ $< $(APPEND_CFLAGS)
+
+-include $(DEPS_INCLUDE)
diff --git a/tools/tests/pdx/harness.h b/tools/tests/pdx/harness.h
new file mode 100644
index 000000000000..64ec09f5e281
--- /dev/null
+++ b/tools/tests/pdx/harness.h
@@ -0,0 +1,89 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Unit tests for PDX compression.
+ *
+ * Copyright (C) 2025 Cloud Software Group
+ */
+
+#ifndef _TEST_HARNESS_
+#define _TEST_HARNESS_
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define __init
+#define __initdata
+#define __ro_after_init
+#define cf_check
+
+#define printk printf
+#define XENLOG_INFO
+#define XENLOG_DEBUG
+#define XENLOG_WARNING
+#define KERN_INFO
+
+#define BITS_PER_LONG (sizeof(unsigned long) * 8)
+
+#define PAGE_SHIFT    12
+/* Some libcs define PAGE_SIZE in limits.h. */
+#undef  PAGE_SIZE
+#define PAGE_SIZE     (1 << PAGE_SHIFT)
+#define MAX_ORDER     18 /* 2 * PAGETABLE_ORDER (9) */
+
+#define PFN_DOWN(x)   ((x) >> PAGE_SHIFT)
+#define PFN_UP(x)     (((x) + PAGE_SIZE-1) >> PAGE_SHIFT)
+
+#define pfn_to_paddr(pfn) ((paddr_t)(pfn) << PAGE_SHIFT)
+#define paddr_to_pfn(pa)  ((unsigned long)((pa) >> PAGE_SHIFT))
+
+#define MAX_RANGES 8
+#define MAX_PFN_RANGES MAX_RANGES
+
+#define ASSERT assert
+
+#define CONFIG_DEBUG
+
+static inline unsigned int find_next(
+    const unsigned long *addr, unsigned int size, unsigned int off, bool value)
+{
+    unsigned int i;
+
+    ASSERT(size <= BITS_PER_LONG);
+
+    for ( i = off; i < size; i++ )
+        if ( !!(*addr & (1UL << i)) == value )
+            return i;
+
+    return size;
+}
+
+#define find_next_zero_bit(a, s, o) find_next(a, s, o, false)
+#define find_next_bit(a, s, o)      find_next(a, s, o, true)
+
+#define boolean_param(name, func)
+
+#define pdx_to_pfn pdx_to_pfn_xlate
+#define pfn_to_pdx pfn_to_pdx_xlate
+#define maddr_to_directmapoff maddr_to_directmapoff_xlate
+#define directmapoff_to_maddr directmapoff_to_maddr_xlate
+
+typedef uint64_t paddr_t;
+
+#include "pdx.h"
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/tests/pdx/test-pdx.c b/tools/tests/pdx/test-pdx.c
new file mode 100644
index 000000000000..b717cae00711
--- /dev/null
+++ b/tools/tests/pdx/test-pdx.c
@@ -0,0 +1,220 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Unit tests for PDX compression.
+ *
+ * Copyright (C) 2025 Cloud Software Group
+ */
+
+#include "harness.h"
+
+#include "../../xen/common/pdx.c"
+
+struct range {
+    /* Ranges are defined as [start, end). */
+    unsigned long start, end;
+};
+
+static void print_ranges(const struct range *r)
+{
+    unsigned int i;
+
+    printf("Ranges:\n");
+
+    for ( i = 0; i < MAX_RANGES; i++ )
+    {
+        if ( !r[i].start && !r[i].end )
+            break;
+
+        printf(" %013lx-%013lx\n", r[i].start, r[i].end);
+    }
+}
+
+int main(int argc, char **argv)
+{
+    static const struct {
+        struct range ranges[MAX_RANGES];
+        bool compress;
+    } tests[] = {
+#ifdef __LP64__
+        /*
+         * Only for targets where unsigned long is 64bits, otherwise compiler
+         * will complain about truncation from 'long long' -> 'long' conversion.
+         *
+         * Real memory map from a 4s Intel GNR.  Not compressible using PDX
+         * mask compression.
+         */
+        {
+            .ranges = {
+                { .start =           0,   .end =     0x80000UL },
+                { .start =   0x0100000UL, .end =   0x8080000UL },
+                { .start =  0x63e80000UL, .end =  0x6be80000UL },
+                { .start =  0xc7e80000UL, .end =  0xcfe80000UL },
+                { .start = 0x12be80000UL, .end = 0x133e80000UL },
+            },
+            .compress = false,
+        },
+        /* Simple hole. */
+        {
+            .ranges = {
+                { .start =                                                 0,
+                  .end   =                            (1UL << MAX_ORDER) * 1 },
+                { .start = (1UL << (MAX_ORDER * 2)) |                      0,
+                  .end   = (1UL << (MAX_ORDER * 2)) | (1UL << MAX_ORDER) * 1 },
+            },
+            .compress = true,
+        },
+        /* Simple hole, unsorted ranges. */
+        {
+            .ranges = {
+                { .start = (1UL << (MAX_ORDER * 2)) |                      0,
+                  .end   = (1UL << (MAX_ORDER * 2)) | (1UL << MAX_ORDER) * 1 },
+                { .start =                                                 0,
+                  .end   =                            (1UL << MAX_ORDER) * 1 },
+            },
+            .compress = true,
+        },
+        /* PDX compression, 2 ranges covered by the lower mask. */
+        {
+            .ranges = {
+                { .start =                    0,
+                  .end   = (1 << MAX_ORDER) * 1 },
+                { .start = (1 << MAX_ORDER) * 2,
+                  .end   = (1 << MAX_ORDER) * 3 },
+                { .start = (1 << MAX_ORDER) * 20,
+                  .end   = (1 << MAX_ORDER) * 22 },
+            },
+            .compress = true,
+        },
+        /* Single range not starting at 0. */
+        {
+            .ranges = {
+                { .start = (1 << MAX_ORDER) * 10,
+                  .end   = (1 << MAX_ORDER) * 11 },
+            },
+            .compress = true,
+        },
+        /* Resulting PDX region size leads to no compression. */
+        {
+            .ranges = {
+                { .start =                    0,
+                  .end   = (1 << MAX_ORDER) * 1 },
+                { .start = (1 << MAX_ORDER) * 2,
+                  .end   = (1 << MAX_ORDER) * 3 },
+                { .start = (1 << MAX_ORDER) * 4,
+                  .end   = (1 << MAX_ORDER) * 7 },
+                { .start = (1 << MAX_ORDER) * 8,
+                  .end   = (1 << MAX_ORDER) * 12 },
+            },
+            .compress = false,
+        },
+#endif
+        /* 2-node 2GB per-node QEMU layout. */
+        {
+            .ranges = {
+                { .start =        0,   .end =  0x80000UL },
+                { .start = 0x100000UL, .end = 0x180000UL },
+            },
+            .compress = true,
+        },
+        /* Not compressible, smaller than MAX_ORDER. */
+        {
+            .ranges = {
+                { .start =     0,   .end =     1   },
+                { .start = 0x100UL, .end = 0x101UL },
+            },
+            .compress = false,
+        },
+        /* Compressible, requires adjusting size to (1 << MAX_ORDER). */
+        {
+            .ranges = {
+                { .start =        0,   .end =        1   },
+                { .start = 0x100000UL, .end = 0x100001UL },
+            },
+            .compress = true,
+        },
+        /* 2s Intel CLX with contiguous ranges, no compression. */
+        {
+            .ranges = {
+                { .start =        0  , .end =  0x180000UL },
+                { .start = 0x180000UL, .end = 0x3040000UL },
+            },
+            .compress = false,
+        },
+    };
+    int ret_code = EXIT_SUCCESS;
+
+    for ( unsigned int i = 0 ; i < ARRAY_SIZE(tests); i++ )
+    {
+        unsigned int j;
+
+        pfn_pdx_compression_reset();
+
+        for ( j = 0; j < ARRAY_SIZE(tests[i].ranges); j++ )
+        {
+            unsigned long size = tests[i].ranges[j].end -
+                                 tests[i].ranges[j].start;
+
+            if ( !tests[i].ranges[j].start && !tests[i].ranges[j].end )
+                break;
+
+            pfn_pdx_add_region(tests[i].ranges[j].start << PAGE_SHIFT,
+                               size << PAGE_SHIFT);
+        }
+
+        if ( pfn_pdx_compression_setup(0) != tests[i].compress )
+        {
+            printf("PFN compression diverge, expected %scompressible\n",
+                   tests[i].compress ? "" : "un");
+            print_ranges(tests[i].ranges);
+
+            ret_code = EXIT_FAILURE;
+            continue;
+        }
+
+        if ( !tests[i].compress )
+            continue;
+
+        for ( j = 0; j < ARRAY_SIZE(tests[i].ranges); j++ )
+        {
+            unsigned long start = tests[i].ranges[j].start;
+            unsigned long end = tests[i].ranges[j].end;
+
+            if ( !start && !end )
+                break;
+
+            if ( !pdx_is_region_compressible(start << PAGE_SHIFT, 1) ||
+                 !pdx_is_region_compressible((end - 1) << PAGE_SHIFT, 1) )
+            {
+                printf(
+    "PFN compression invalid, pages %#lx and %#lx should be compressible\n",
+                       start, end - 1);
+                print_ranges(tests[i].ranges);
+                ret_code = EXIT_FAILURE;
+            }
+
+            if ( start != pdx_to_pfn(pfn_to_pdx(start)) ||
+                 end - 1 != pdx_to_pfn(pfn_to_pdx(end - 1)) )
+            {
+                printf("Compression is not bi-directional:\n");
+                printf(" PFN %#lx -> PDX %#lx -> PFN %#lx\n",
+                       start, pfn_to_pdx(start), pdx_to_pfn(pfn_to_pdx(start)));
+                printf(" PFN %#lx -> PDX %#lx -> PFN %#lx\n",
+                       end - 1, pfn_to_pdx(end - 1),
+                       pdx_to_pfn(pfn_to_pdx(end - 1)));
+                print_ranges(tests[i].ranges);
+                ret_code = EXIT_FAILURE;
+            }
+        }
+    }
+
+    return ret_code;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/common/pdx.c b/xen/common/pdx.c
index 86e2dc7c6bb6..5cfec591f993 100644
--- a/xen/common/pdx.c
+++ b/xen/common/pdx.c
@@ -15,6 +15,8 @@
  * along with this program; If not, see .
  */
 
+/* Trim content when built for the test harness. */
+#ifdef __XEN__
 #include 
 #include 
 #include 
@@ -57,6 +59,8 @@ void set_pdx_range(unsigned long smfn, unsigned long emfn)
         __set_bit(idx, pdx_group_valid);
 }
 
+#endif /* __XEN__ */
+
 #ifndef CONFIG_PDX_NONE
 
 #ifdef CONFIG_X86
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 20 11:11:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 11:11:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020850.1397021 (Exim 4.92)
	(envelope-from )
	id 1uSZer-0006lP-HV; Fri, 20 Jun 2025 11:11:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020850.1397021; Fri, 20 Jun 2025 11:11: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 1uSZer-0006kj-B7; Fri, 20 Jun 2025 11:11:45 +0000
Received: by outflank-mailman (input) for mailman id 1020850;
 Fri, 20 Jun 2025 11:11: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 1uSZep-0005XW-V1
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 11:11:43 +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 58f86d06-4dc7-11f0-a30e-13f23c93f187;
 Fri, 20 Jun 2025 13:11:43 +0200 (CEST)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-451d41e1ad1so13059695e9.1
 for ; Fri, 20 Jun 2025 04:11:43 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-453646cb57fsm22346425e9.1.2025.06.20.04.11.42
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 20 Jun 2025 04:11:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 58f86d06-4dc7-11f0-a30e-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750417903; x=1751022703; darn=lists.xenproject.org;
        h=content-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=wldT8/hJRoQr9+P0tngsgZ2ttRe5059NLBS5IaMdmu4=;
        b=UlQkcyCgzs/MRDx+r6F69Aq3z1GbQzWX6PrJsRxbcwEYYpx1hKaA/UCYfPEMkiEto0
         z8Ud59mpKsxH3DsJ6VXaAyA6AadPehNelyapm7Z1VXRySGOXiwc8onkLOGM0814xUCLX
         G3LTlbdEPvyTL6SwELlQGsc58RalCCjGOgaro=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750417903; x=1751022703;
        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=wldT8/hJRoQr9+P0tngsgZ2ttRe5059NLBS5IaMdmu4=;
        b=aXQKJ3Ap7H/Uj19d4A/BN2diOUsozVa64gGC2jy3uSyQHSif1Fk5kVh0NIpQZcQPMZ
         BcsbbmvqKABGx7zR7CphkrKfc/bxxv4PzeULgC8lbKRSSx052pJt9hQscvQEZl3IBAbe
         z/eq9UiLVAQZ8ikIlpEq0NidICrQJ1u83/r3yBsea+oHUGa51LldZ9uMJZdFDfWG44Dg
         4SBGgfJRXtwDyr9r1wUNGtsBPfnMINOT1hSBPOtHadQ9wEAqSYgPcZipodJMZUP8+jF3
         bNG0it0cQaKDR068S4Jpw13azSxayMhpZFBPXH/39hczuUk7iEDSfmqODqebNaetYYIH
         Dwhg==
X-Gm-Message-State: AOJu0YwD/0OL/+vsMz+agfKT6n8HSh65yucakFTHsk7nKS3+DDEyEed4
	U7pybLqWq3Ge4Kt7aaJsGN7bYaQoPDSeymr8lwn1wztv7w0W92dUmxkEHsdDCh7+KJKPcqA/jRb
	b/CmK
X-Gm-Gg: ASbGncu+SPmmhj3bnbE4Wvb5y0YGgFkwla1XpX+SdLWh5fBXi9lWby0hp9YHb9Zipib
	i0suybdH4k4TfPm1mTtSPW6l0nM2GFW9WZAiwi0sSjzyDi5zEK2bIMEXJg4EJWtirWy+KvE9A9W
	E5zmpjvXEJHHskx/+HWX+nQuUjFMpuLU0iTrwH8Yy/MZ2CzUbOQ9PN50tIq81Yr1pyRrbNaJDXy
	b7j3mauad+HURx0oM67/7rO3p5j5eLk+eBhgBE6i+qNSsD+ci90igSPrBGLiDJ6wQMSR3wZehfs
	1sZ6r/doHPN/96hWLMgvcnOTX/1h9rHDY9Oy/F/GwASsCraaXiYniwMGvey/RVCiZTBUJKP2qHj
	k2+1DPeXrOOyx9qMrRZ+84jH+9ke8JA==
X-Google-Smtp-Source: AGHT+IHJiQ62hFFpGk1dacP+iqYl/Dmt8h7STK8m9XWPRJGoeBlj0alEIF5MZ6oahkw+8FizzIXZgA==
X-Received: by 2002:a05:6000:2807:b0:3a5:232c:6976 with SMTP id ffacd0b85a97d-3a6d12e3a8fmr1412325f8f.44.1750417902622;
        Fri, 20 Jun 2025 04:11:42 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH v2 7/8] pdx: move some helpers in preparation for new compression
Date: Fri, 20 Jun 2025 13:11:29 +0200
Message-ID: <20250620111130.29057-8-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250620111130.29057-1-roger.pau@citrix.com>
References: <20250620111130.29057-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Move fill_mask(), pdx_region_mask() and pdx_init_mask() to the
!CONFIG_PDX_NONE section in preparation of them also being used by a newly
added PDX compression.

No functional change intended.

Signed-off-by: Roger Pau Monné 
---
git is not very helpful when generating the diff here, and it ends up
moving everything around the functions instead of the functions themselves.
---
 xen/common/pdx.c | 118 +++++++++++++++++++++++------------------------
 1 file changed, 59 insertions(+), 59 deletions(-)

diff --git a/xen/common/pdx.c b/xen/common/pdx.c
index 5cfec591f993..d5e469baffe2 100644
--- a/xen/common/pdx.c
+++ b/xen/common/pdx.c
@@ -101,59 +101,6 @@ void __init pfn_pdx_add_region(paddr_t base, paddr_t size)
     ranges[nr_ranges++].size = PFN_UP(base + size) - PFN_DOWN(base);
 }
 
-#endif /* !CONFIG_PDX_NONE */
-
-#ifdef CONFIG_PDX_MASK_COMPRESSION
-
-/*
- * Diagram to make sense of the following variables. The masks and shifts
- * are done on mfn values in order to convert to/from pdx:
- *
- *                      pfn_hole_mask
- *                      pfn_pdx_hole_shift (mask bitsize)
- *                      |
- *                 |---------|
- *                 |         |
- *                 V         V
- *         --------------------------
- *         |HHHHHHH|000000000|LLLLLL| <--- mfn
- *         --------------------------
- *         ^       ^         ^      ^
- *         |       |         |------|
- *         |       |             |
- *         |       |             pfn_pdx_bottom_mask
- *         |       |
- *         |-------|
- *             |
- *             pfn_top_mask
- *
- * ma_{top,va_bottom}_mask is simply a shifted pfn_{top,pdx_bottom}_mask,
- * where ma_top_mask has zeroes shifted in while ma_va_bottom_mask has
- * ones.
- */
-
-/** Mask for the lower non-compressible bits of an mfn */
-unsigned long __ro_after_init pfn_pdx_bottom_mask = ~0UL;
-
-/** Mask for the lower non-compressible bits of an maddr or vaddr */
-unsigned long __ro_after_init ma_va_bottom_mask = ~0UL;
-
-/** Mask for the higher non-compressible bits of an mfn */
-unsigned long __ro_after_init pfn_top_mask = 0;
-
-/** Mask for the higher non-compressible bits of an maddr or vaddr */
-unsigned long __ro_after_init ma_top_mask = 0;
-
-/**
- * Mask for a pdx compression bit slice.
- *
- *  Invariant: valid(mfn) implies (mfn & pfn_hole_mask) == 0
- */
-unsigned long __ro_after_init pfn_hole_mask = 0;
-
-/** Number of bits of the "compressible" bit slice of an mfn */
-unsigned int __ro_after_init pfn_pdx_hole_shift = 0;
-
 /* Sets all bits from the most-significant 1-bit down to the LSB */
 static uint64_t fill_mask(uint64_t mask)
 {
@@ -196,12 +143,6 @@ static uint64_t pdx_region_mask(uint64_t base, uint64_t len)
     return fill_mask(base ^ (base + len - 1));
 }
 
-bool pdx_is_region_compressible(paddr_t base, unsigned long npages)
-{
-    return !(paddr_to_pfn(base) & pfn_hole_mask) &&
-           !(pdx_region_mask(base, npages * PAGE_SIZE) & ~ma_va_bottom_mask);
-}
-
 /**
  * Creates the mask to start from when calculating non-compressible bits
  *
@@ -219,6 +160,65 @@ static uint64_t __init pdx_init_mask(uint64_t base_addr)
                          (uint64_t)1 << (MAX_ORDER + PAGE_SHIFT)) - 1);
 }
 
+#endif /* !CONFIG_PDX_NONE */
+
+#ifdef CONFIG_PDX_MASK_COMPRESSION
+
+/*
+ * Diagram to make sense of the following variables. The masks and shifts
+ * are done on mfn values in order to convert to/from pdx:
+ *
+ *                      pfn_hole_mask
+ *                      pfn_pdx_hole_shift (mask bitsize)
+ *                      |
+ *                 |---------|
+ *                 |         |
+ *                 V         V
+ *         --------------------------
+ *         |HHHHHHH|000000000|LLLLLL| <--- mfn
+ *         --------------------------
+ *         ^       ^         ^      ^
+ *         |       |         |------|
+ *         |       |             |
+ *         |       |             pfn_pdx_bottom_mask
+ *         |       |
+ *         |-------|
+ *             |
+ *             pfn_top_mask
+ *
+ * ma_{top,va_bottom}_mask is simply a shifted pfn_{top,pdx_bottom}_mask,
+ * where ma_top_mask has zeroes shifted in while ma_va_bottom_mask has
+ * ones.
+ */
+
+/** Mask for the lower non-compressible bits of an mfn */
+unsigned long __ro_after_init pfn_pdx_bottom_mask = ~0UL;
+
+/** Mask for the lower non-compressible bits of an maddr or vaddr */
+unsigned long __ro_after_init ma_va_bottom_mask = ~0UL;
+
+/** Mask for the higher non-compressible bits of an mfn */
+unsigned long __ro_after_init pfn_top_mask = 0;
+
+/** Mask for the higher non-compressible bits of an maddr or vaddr */
+unsigned long __ro_after_init ma_top_mask = 0;
+
+/**
+ * Mask for a pdx compression bit slice.
+ *
+ *  Invariant: valid(mfn) implies (mfn & pfn_hole_mask) == 0
+ */
+unsigned long __ro_after_init pfn_hole_mask = 0;
+
+/** Number of bits of the "compressible" bit slice of an mfn */
+unsigned int __ro_after_init pfn_pdx_hole_shift = 0;
+
+bool pdx_is_region_compressible(paddr_t base, unsigned long npages)
+{
+    return !(paddr_to_pfn(base) & pfn_hole_mask) &&
+           !(pdx_region_mask(base, npages * PAGE_SIZE) & ~ma_va_bottom_mask);
+}
+
 bool __init pfn_pdx_compression_setup(paddr_t base)
 {
     unsigned int i, j, bottom_shift = 0, hole_shift = 0;
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 20 11:11:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 11:11:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020847.1396988 (Exim 4.92)
	(envelope-from )
	id 1uSZen-0005vR-Iy; Fri, 20 Jun 2025 11:11:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020847.1396988; Fri, 20 Jun 2025 11:11: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 1uSZen-0005vC-CD; Fri, 20 Jun 2025 11:11:41 +0000
Received: by outflank-mailman (input) for mailman id 1020847;
 Fri, 20 Jun 2025 11:11: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 1uSZem-0005XV-JK
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 11:11:40 +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 55fac604-4dc7-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 13:11:38 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-453066fad06so10939205e9.2
 for ; Fri, 20 Jun 2025 04:11:38 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a6d2236452sm1507187f8f.59.2025.06.20.04.11.36
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 20 Jun 2025 04:11:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 55fac604-4dc7-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750417898; x=1751022698; darn=lists.xenproject.org;
        h=content-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=EfCl0bVnbKZAPh4wG7ZBEoxiS0taRAfJCBHz8dGUrQQ=;
        b=S6zgN7YOfpB3RhCy6Icso9EgPQtjspRHxG6c09gX/glxvX4L2wP88QZ3S9v2wxaQvw
         TExx0POaUQ9dsm9WeAvPchp17c770+KhAvm/VNQhMg6cUPGeB0N7bG0R7WaVU5jkqHao
         gAiJogVnWV7TaOWvNZ+qoY9EFCyV8SRzzDQS8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750417898; x=1751022698;
        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=EfCl0bVnbKZAPh4wG7ZBEoxiS0taRAfJCBHz8dGUrQQ=;
        b=dKr8HutL+ZuP0qRGZRtPZ1DC8dNhQ8VAUJqaEdGYdO/fvL3ZuPL8WochO2ArWTQfeG
         Xd9Ybec6XmbfAN5k297r8ewWJYZi0enxDVTj1G/tMOgrM0ZVpCkbC9JXblUH5dWC3M4y
         rgs+ipxDwWlnEptXcz8UpcWSoWBXMRONjsKfDgj59uHc1gMEgD+z0Hbd9TH89tkrozHG
         XhcIK3RPdzHrIP0UD3BBwofL4MoWZqnApksTqyDQUCtdF7sbzOhrV+tsM3WQ13vldzV4
         /F3mI+mUBjZVaivqVcAUj1OqXEJwEA2b/6WiOeZHweV85Tm7ad2CSFj8OHQzBiVIjSDo
         92NQ==
X-Gm-Message-State: AOJu0Yz82QEkUxPa7aoodrqj38lND0ajcTlBTtRcl+41S/kM5OKr9STU
	GRz7drvlnRkX65/xuhEiu7aQp3Sg20CPf5To9YNkxq5O/xsu0QS1wpHrwt0LOD30LETx7ZnmMUA
	ZIlb/
X-Gm-Gg: ASbGncu5F/lhQIu78Zqxwi57l5g8ESludafV+DXffsU/yaj3ZeSY30fugT6tzMBF638
	ZJxwnV0Aqia092iGQrcX3Tb0qSYBbbjl4YkkZn9isaMa1KyVx0MXUsUupc7EdgD2xRyJVMd1O4m
	Tx7T/9Bk7tzO2Rb9eFbM5BIcgI9Ugud/k5am9WFvWMJB88i4LnINk/x4nA4Em/jUhBXKgW8vqn6
	koxVfPwCu7+EKzTjtRPDmycZP+ph53k3xTe1jrwQUvkCpJ0MSLjyydq7RU0EtHZuxXHgyVszf2j
	FmCccb7mbpYYdQY/ApXf+vZTL/zGDyfIwhcfzV+rXt3DF6fjgvq5ML+KKnZyyTF5GswCjsIsoow
	QlLPs/pGQVfz7uFgwlnTTTo/f6vTQ9A==
X-Google-Smtp-Source: AGHT+IE/yCA3Rc2UNsyEtwRt8BYVm1vUP2PBgdDehSFU1I5t56tvb56e9J9NOCFbp6RRn4HBRjbN9g==
X-Received: by 2002:a05:600c:820e:b0:43c:e478:889 with SMTP id 5b1f17b1804b1-4536478ecd2mr26387755e9.0.1750417897603;
        Fri, 20 Jun 2025 04:11:37 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Andrew Cooper ,
	Anthony PERARD ,
	Jan Beulich 
Subject: [PATCH v2 3/8] pdx: provide a unified set of unit functions
Date: Fri, 20 Jun 2025 13:11:25 +0200
Message-ID: <20250620111130.29057-4-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250620111130.29057-1-roger.pau@citrix.com>
References: <20250620111130.29057-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The current setup (pdx_init_mask() and pdx_region_mask()) and init
(pfn_pdx_hole_setup()) PDX compression functions are tailored to the
existing PDX compression algorithm.

In preparation for introducing a new compression algorithm convert the
setup and init functions to more generic interfaces that aren't tied to the
compression in-use.  To accomplish this introduce a function that registers
all the PFN RAM ranges, plus an init function.

This has the downside of requiring a static array to store such ranges
ahead of being processed by the setup function, however it's the only way
to pass all the possible information to the different compression setup
functions without using per-compression specific setup functions.
Per-arch compression setup also need to be adjusted to use the new
interface.  There's a slight ordering adjustment, in that after PDX
compression setup the caller will check whether all the RAM regions are
properly covered by the newly setup compression, otherwise compression is
disabled by resetting to the initial values.

No functional change intended in the resulting PDX compression values.

Signed-off-by: Roger Pau Monné 
---
Changes since v1:
 - s/nr/nr_ranges/
---
 xen/arch/arm/setup.c  |  34 ++++++------
 xen/arch/x86/srat.c   |  28 ++++++----
 xen/common/pdx.c      | 122 ++++++++++++++++++++++++++++++++++++------
 xen/include/xen/pdx.h |  73 +++++++++----------------
 4 files changed, 166 insertions(+), 91 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index ed72317af3c5..c9ad6bbab6a2 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -255,6 +255,10 @@ void __init init_pdx(void)
 {
     const struct membanks *mem = bootinfo_get_mem();
     paddr_t bank_start, bank_size, bank_end;
+    unsigned int bank;
+
+    for ( bank = 0 ; bank < mem->nr_banks; bank++ )
+        pfn_pdx_add_region(mem->bank[bank].start, mem->bank[bank].size);
 
     /*
      * Arm does not have any restrictions on the bits to compress. Pass 0 to
@@ -263,28 +267,24 @@ void __init init_pdx(void)
      * If the logic changes in pfn_pdx_hole_setup we might have to
      * update this function too.
      */
-    uint64_t mask = pdx_init_mask(0x0);
-    int bank;
+    pfn_pdx_compression_setup(0);
 
     for ( bank = 0 ; bank < mem->nr_banks; bank++ )
     {
-        bank_start = mem->bank[bank].start;
-        bank_size = mem->bank[bank].size;
-
-        mask |= bank_start | pdx_region_mask(bank_start, bank_size);
-    }
-
-    for ( bank = 0 ; bank < mem->nr_banks; bank++ )
-    {
-        bank_start = mem->bank[bank].start;
-        bank_size = mem->bank[bank].size;
-
-        if (~mask & pdx_region_mask(bank_start, bank_size))
-            mask = 0;
+        if ( !pdx_is_region_compressible(mem->bank[bank].start,
+                 PFN_UP(mem->bank[bank].start + mem->bank[bank].size) -
+                 PFN_DOWN(mem->bank[bank].start)) )
+        {
+            pfn_pdx_compression_reset();
+            printk(XENLOG_WARNING
+                   "PFN compression disabled, RAM region [%#" PRIpaddr ", %#"
+                   PRIpaddr "] not covered\n",
+                   mem->bank[bank].start,
+                   mem->bank[bank].start + mem->bank[bank].size - 1);
+            break;
+        }
     }
 
-    pfn_pdx_hole_setup(mask >> PAGE_SHIFT);
-
     for ( bank = 0 ; bank < mem->nr_banks; bank++ )
     {
         bank_start = mem->bank[bank].start;
diff --git a/xen/arch/x86/srat.c b/xen/arch/x86/srat.c
index 688f410287d4..2a678e744e7c 100644
--- a/xen/arch/x86/srat.c
+++ b/xen/arch/x86/srat.c
@@ -261,8 +261,6 @@ acpi_numa_memory_affinity_init(const struct acpi_srat_mem_affinity *ma)
 
 void __init acpi_numa_arch_fixup(void) {}
 
-static uint64_t __initdata srat_region_mask;
-
 static int __init cf_check srat_parse_region(
     struct acpi_subtable_header *header, const unsigned long end)
 {
@@ -282,15 +280,13 @@ static int __init cf_check srat_parse_region(
 		printk(KERN_INFO "SRAT: %013"PRIx64"-%013"PRIx64"\n",
 		       ma->base_address, ma->base_address + ma->length - 1);
 
-	srat_region_mask |= ma->base_address |
-			    pdx_region_mask(ma->base_address, ma->length);
+	pfn_pdx_add_region(ma->base_address, ma->length);
 
 	return 0;
 }
 
 void __init srat_parse_regions(paddr_t addr)
 {
-	u64 mask;
 	unsigned int i;
 
 	if (acpi_disabled || acpi_numa < 0 ||
@@ -299,19 +295,29 @@ void __init srat_parse_regions(paddr_t addr)
 
 	/* Set "PXM" as early as feasible. */
 	numa_fw_nid_name = "PXM";
-	srat_region_mask = pdx_init_mask(addr);
 	acpi_table_parse_srat(ACPI_SRAT_TYPE_MEMORY_AFFINITY,
 			      srat_parse_region, 0);
 
-	for (mask = srat_region_mask, i = 0; mask && i < e820.nr_map; i++) {
+	pfn_pdx_compression_setup(addr);
+
+	/* Ensure all RAM ranges in the e820 are covered. */
+	for (i = 0; i < e820.nr_map; i++) {
 		if (e820.map[i].type != E820_RAM)
 			continue;
 
-		if (~mask & pdx_region_mask(e820.map[i].addr, e820.map[i].size))
-			mask = 0;
+		if (!pdx_is_region_compressible(e820.map[i].addr,
+		    PFN_UP(e820.map[i].addr + e820.map[i].size) -
+		    PFN_DOWN(e820.map[i].addr)))
+		{
+			pfn_pdx_compression_reset();
+			printk(XENLOG_WARNING
+			       "PFN compression disabled, RAM region [%#" PRIx64
+			       ", %#" PRIx64 "] not covered\n",
+			       e820.map[i].addr,
+			       e820.map[i].addr + e820.map[i].size - 1);
+			return;
+		}
 	}
-
-	pfn_pdx_hole_setup(mask >> PAGE_SHIFT);
 }
 
 unsigned int numa_node_to_arch_nid(nodeid_t n)
diff --git a/xen/common/pdx.c b/xen/common/pdx.c
index 00aa7e43006d..6f488366e5a9 100644
--- a/xen/common/pdx.c
+++ b/xen/common/pdx.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /**
@@ -55,6 +56,44 @@ void set_pdx_range(unsigned long smfn, unsigned long emfn)
         __set_bit(idx, pdx_group_valid);
 }
 
+#ifndef CONFIG_PDX_NONE
+
+#ifdef CONFIG_X86
+# include 
+# define MAX_PFN_RANGES E820MAX
+#elif defined(CONFIG_HAS_DEVICE_TREE)
+# include 
+# define MAX_PFN_RANGES NR_MEM_BANKS
+#endif
+
+#ifndef MAX_PFN_RANGES
+# error "Missing architecture maximum number of RAM ranges"
+#endif
+
+/* Generic PFN compression helpers. */
+static struct pfn_range {
+    unsigned long base, size;
+} ranges[MAX_PFN_RANGES] __initdata;
+static unsigned int __initdata nr_ranges;
+
+void __init pfn_pdx_add_region(paddr_t base, paddr_t size)
+{
+    if ( !size )
+        return;
+
+    if ( nr_ranges >= ARRAY_SIZE(ranges) )
+    {
+        ASSERT((nr_ranges + 1) > nr_ranges);
+        nr_ranges++;
+        return;
+    }
+
+    ranges[nr_ranges].base = PFN_DOWN(base);
+    ranges[nr_ranges++].size = PFN_UP(base + size) - PFN_DOWN(base);
+}
+
+#endif /* !CONFIG_PDX_NONE */
+
 #ifdef CONFIG_PDX_MASK_COMPRESSION
 
 /*
@@ -115,20 +154,25 @@ static uint64_t fill_mask(uint64_t mask)
     return mask;
 }
 
-bool pdx_is_region_compressible(paddr_t base, unsigned long npages)
-{
-    return !(paddr_to_pfn(base) & pfn_hole_mask) &&
-           !(pdx_region_mask(base, npages * PAGE_SIZE) & ~ma_va_bottom_mask);
-}
-
-/* We don't want to compress the low MAX_ORDER bits of the addresses. */
-uint64_t __init pdx_init_mask(uint64_t base_addr)
-{
-    return fill_mask(max(base_addr,
-                         (uint64_t)1 << (MAX_ORDER + PAGE_SHIFT)) - 1);
-}
-
-uint64_t pdx_region_mask(uint64_t base, uint64_t len)
+/**
+ * Calculates a mask covering "moving" bits of all addresses of a region
+ *
+ * The i-th bit of the mask must be set if there's 2 different addresses
+ * in the region that have different j-th bits. where j >= i.
+ *
+ * e.g:
+ *       base=0x1B00000000
+ *   len+base=0x1B00042000
+ *
+ *   ought to return 0x000007FFFF, which implies that every bit position
+ *   with a zero in the mask remains unchanged in every address of the
+ *   region.
+ *
+ * @param base Base address of the region
+ * @param len  Size in octets of the region
+ * @return Mask of moving bits at the bottom of all the region addresses
+ */
+static uint64_t pdx_region_mask(uint64_t base, uint64_t len)
 {
     /*
      * We say a bit "moves" in a range if there exist 2 addresses in that
@@ -143,9 +187,45 @@ uint64_t pdx_region_mask(uint64_t base, uint64_t len)
     return fill_mask(base ^ (base + len - 1));
 }
 
-void __init pfn_pdx_hole_setup(unsigned long mask)
+bool pdx_is_region_compressible(paddr_t base, unsigned long npages)
+{
+    return !(paddr_to_pfn(base) & pfn_hole_mask) &&
+           !(pdx_region_mask(base, npages * PAGE_SIZE) & ~ma_va_bottom_mask);
+}
+
+/**
+ * Creates the mask to start from when calculating non-compressible bits
+ *
+ * This function is intimately related to pdx_region_mask(), and together
+ * they are meant to calculate the mask of non-compressible bits given the
+ * current memory map.
+ *
+ * @param base_addr Address of the first maddr in the system
+ * @return An integer of the form 2^n - 1
+ */
+static uint64_t __init pdx_init_mask(uint64_t base_addr)
+{
+    return fill_mask(max(base_addr,
+                         /* Don't compress the low MAX_ORDER bits. */
+                         (uint64_t)1 << (MAX_ORDER + PAGE_SHIFT)) - 1);
+}
+
+void __init pfn_pdx_compression_setup(paddr_t base)
 {
     unsigned int i, j, bottom_shift = 0, hole_shift = 0;
+    unsigned long mask = pdx_init_mask(base) >> PAGE_SHIFT;
+
+    if ( nr_ranges > ARRAY_SIZE(ranges) )
+    {
+        printk(XENLOG_WARNING
+               "Too many PFN ranges (%u > %zu), not attempting PFN compression\n",
+               nr_ranges, ARRAY_SIZE(ranges));
+        return;
+    }
+
+    for ( i = 0; i < nr_ranges; i++ )
+        mask |= ranges[i].base |
+                pdx_region_mask(ranges[i].base, ranges[i].size);
 
     /*
      * We skip the first MAX_ORDER bits, as we never want to compress them.
@@ -184,6 +264,18 @@ void __init pfn_pdx_hole_setup(unsigned long mask)
     ma_top_mask         = pfn_top_mask << PAGE_SHIFT;
 }
 
+void __init pfn_pdx_compression_reset(void)
+{
+    pfn_pdx_bottom_mask = ~0UL;
+    ma_va_bottom_mask = ~0UL;
+    pfn_top_mask = 0;
+    ma_top_mask = 0;
+    pfn_hole_mask = 0;
+    pfn_pdx_hole_shift = 0;
+
+    nr_ranges = 0;
+}
+
 #endif /* CONFIG_PDX_COMPRESSION */
 
 /*
diff --git a/xen/include/xen/pdx.h b/xen/include/xen/pdx.h
index 8e373cac8b87..10153da98bf1 100644
--- a/xen/include/xen/pdx.h
+++ b/xen/include/xen/pdx.h
@@ -108,38 +108,6 @@ extern unsigned int pfn_pdx_hole_shift;
 extern unsigned long pfn_hole_mask;
 extern unsigned long pfn_top_mask, ma_top_mask;
 
-/**
- * Calculates a mask covering "moving" bits of all addresses of a region
- *
- * The i-th bit of the mask must be set if there's 2 different addresses
- * in the region that have different j-th bits. where j >= i.
- *
- * e.g:
- *       base=0x1B00000000
- *   len+base=0x1B00042000
- *
- *   ought to return 0x000007FFFF, which implies that every bit position
- *   with a zero in the mask remains unchanged in every address of the
- *   region.
- *
- * @param base Base address of the region
- * @param len  Size in octets of the region
- * @return Mask of moving bits at the bottom of all the region addresses
- */
-uint64_t pdx_region_mask(uint64_t base, uint64_t len);
-
-/**
- * Creates the mask to start from when calculating non-compressible bits
- *
- * This function is intimately related to pdx_region_mask(), and together
- * they are meant to calculate the mask of non-compressible bits given the
- * current memory map.
- *
- * @param base_addr Address of the first maddr in the system
- * @return An integer of the form 2^n - 1
- */
-uint64_t pdx_init_mask(uint64_t base_addr);
-
 /**
  * Map pfn to its corresponding pdx
  *
@@ -189,17 +157,6 @@ static inline paddr_t directmapoff_to_maddr(unsigned long offset)
             (offset & ma_va_bottom_mask));
 }
 
-/**
- * Initializes global variables with information about the compressible
- * range of the current memory regions.
- *
- * @param mask This mask is the biggest pdx_mask of every region in the
- *             system ORed with all base addresses of every region in the
- *             system. This results in a mask where every zero in a bit
- *             position marks a potentially compressible bit.
- */
-void pfn_pdx_hole_setup(unsigned long mask);
-
 #endif /* CONFIG_PDX_MASK_COMPRESSION */
 
 #ifdef CONFIG_PDX_NONE
@@ -220,17 +177,15 @@ static inline bool pdx_is_region_compressible(paddr_t base,
     return true;
 }
 
-static inline uint64_t pdx_init_mask(uint64_t base_addr)
+static inline void pfn_pdx_add_region(paddr_t base, paddr_t size)
 {
-    return 0;
 }
 
-static inline uint64_t pdx_region_mask(uint64_t base, uint64_t len)
+static inline void pfn_pdx_compression_setup(paddr_t base)
 {
-    return 0;
 }
 
-static inline void pfn_pdx_hole_setup(unsigned long mask)
+static inline void pfn_pdx_compression_reset(void)
 {
 }
 
@@ -247,6 +202,28 @@ static inline void pfn_pdx_hole_setup(unsigned long mask)
  */
 bool pdx_is_region_compressible(paddr_t base, unsigned long npages);
 
+/**
+ * Register a RAM region with the PFN compression logic.
+ *
+ * @param base Start of the region in bytes.
+ * @param size Length of the region in bytes.
+ */
+void pfn_pdx_add_region(paddr_t base, paddr_t size);
+
+/**
+ * Initializes global variables with information about the compressible
+ * range of the current memory regions.
+ *
+ * @param base address to start compression from.
+ */
+void pfn_pdx_compression_setup(paddr_t base);
+
+/**
+ * Reset the global variables to it's default values, thus disabling PFN
+ * compression.
+ */
+void pfn_pdx_compression_reset(void);
+
 #endif /* !CONFIG_PDX_NONE */
 #endif /* __XEN_PDX_H__ */
 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 20 11:11:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 11:11:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020848.1397005 (Exim 4.92)
	(envelope-from )
	id 1uSZeo-0006R8-UF; Fri, 20 Jun 2025 11:11:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020848.1397005; Fri, 20 Jun 2025 11:11: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 1uSZeo-0006Qt-Qb; Fri, 20 Jun 2025 11:11:42 +0000
Received: by outflank-mailman (input) for mailman id 1020848;
 Fri, 20 Jun 2025 11:11: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 1uSZen-0005XV-EN
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 11:11:41 +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 56b05a14-4dc7-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 13:11:39 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a50956e5d3so1410693f8f.1
 for ; Fri, 20 Jun 2025 04:11:39 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a6d0f104bbsm1785278f8f.4.2025.06.20.04.11.38
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 20 Jun 2025 04:11:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 56b05a14-4dc7-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750417899; x=1751022699; darn=lists.xenproject.org;
        h=content-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=m8xArolHoZlQzAD7nGBeNXqPQFb+qxrfyquO2phQrQ8=;
        b=bQulBgTPf8YW3t9+6K7nhXx5cWMiPZ52zPeqsT7ivdaBKOxbnSVc8nnvjYdRbQc063
         ZchXXkdB2xm/8Z6uv9det2mPFik7ejpx5AIX6IuoOkB2D8TDIq0nJkg0NLzzvi7QlCS6
         UTFBXkNTtzOxGxTyaNq+kMIciOT5ZI5USg9hg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750417899; x=1751022699;
        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=m8xArolHoZlQzAD7nGBeNXqPQFb+qxrfyquO2phQrQ8=;
        b=lsFSaUTG6Yx/4NapZyBFbX+tv3B6MpnKNazvUBXUWKmpMdjVI3p+6KIr4O6gkXImxB
         t609EqYCTOnPjjN+ya9pAyCL2Mu7JEWjYUFhvTyJxc8ETSCjTFF1rlO+CX0x4S9ByKAO
         NRGFl0CU1ehII4ap7mHh+mlp7AsjYLVsJx95/QhpWpXitt3O63WAPG48abEeeEIal493
         LUWsl542WqULm0253mZd+NWdgENcecZud4w3q2DZ3wQ41mArlEeqThai7jaa0lZE0+XJ
         Y7Nj6+Q7aiBLfPpK0/3jE1ZjrD9LQdvaDEiW+HlNKCtK47T2w2R2bIwxIbH6JlbCrc4a
         iNfA==
X-Gm-Message-State: AOJu0YzGIkSe7tsGAMjmoxgdIxhSH98KwqSAWaWCPDf6qAwciWMASRxD
	lgHIqdAdoOHe5wwfamvZs/MRIgdvCMsWSCE2h6aLMc23RRNkdVhbr8nP9PO0egA0/WZ/T8mTN0D
	2Eoyo
X-Gm-Gg: ASbGnct8IHwBSyhahC1eHm8TW0MUjz915AmP8lzBWmJ9tNF2akKnIB3y23N+tx+DYph
	NpAponotEk3LyAk2VMqol0WuK/DI2WN1G+qflzhFUn1aZzOT1fpHpOm3VdJj2YbrS/RadmNX8GS
	xsdXTG6Ubp1rlTz1njT7d37YuySgZ5At40vzS3YuJv4ecSB0Q0lB3sRPDa2kJhbD+chT36cNMHG
	wnjEWfjnXHpYgdlc+zz+ADUz3f5vIqjiGHS2wnpFGbSTa7jjBOUhewB74LaOOc9VevSfc0J0729
	TXF9gpXVnmkGaCUqsU+cD14zvS4g63ORUlHnZl1CnsrcbeAN5PHqI7Njit40lrSvDqEe6SibKag
	VusR+9UtpjkDD+B3otM1hkIuCpTCVjgTdT2QBpH/O
X-Google-Smtp-Source: AGHT+IFC3F/vZggfelvDlDElhNOdJ82GWozuNVzqytLAEaS0nI24HNALkgoj2kiO6E3Bf9w3uOgVWQ==
X-Received: by 2002:a5d:5f4b:0:b0:3a1:fe77:9e1d with SMTP id ffacd0b85a97d-3a6d12c1848mr2047618f8f.16.1750417898844;
        Fri, 20 Jun 2025 04:11:38 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v2 4/8] pdx: introduce command line compression toggle
Date: Fri, 20 Jun 2025 13:11:26 +0200
Message-ID: <20250620111130.29057-5-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250620111130.29057-1-roger.pau@citrix.com>
References: <20250620111130.29057-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Introduce a command line option to allow disabling PDX compression.  The
disabling is done by turning pfn_pdx_add_region() into a no-op, so when
attempting to initialize the selected compression algorithm the array of
ranges to compress is empty.

Signed-off-by: Roger Pau Monné 
---
Changes since v1:
 - New in this version.
---
 docs/misc/xen-command-line.pandoc |  9 +++++++++
 xen/common/pdx.c                  | 10 +++++++++-
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index b0eadd2c5d58..c747a326be86 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -2072,6 +2072,15 @@ for all of them (`true`), only for those subject to XPTI (`xpti`) or for
 those not subject to XPTI (`no-xpti`). The feature is used only in case
 INVPCID is supported and not disabled via `invpcid=false`.
 
+### pdx-compress
+> `= `
+
+> Default: `true` if CONFIG_PDX_NONE is unset
+
+Only relevant when the hypervisor is build with PFN PDX compression. Controls
+whether Xen will engage in PFN compression.  The algorithm used for PFN
+compression is selected at build time from Kconfig.
+
 ### ple_gap
 > `= `
 
diff --git a/xen/common/pdx.c b/xen/common/pdx.c
index 6f488366e5a9..8c107676da59 100644
--- a/xen/common/pdx.c
+++ b/xen/common/pdx.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -76,9 +77,13 @@ static struct pfn_range {
 } ranges[MAX_PFN_RANGES] __initdata;
 static unsigned int __initdata nr_ranges;
 
+static bool __initdata pdx_compress = true;
+boolean_param("pdx-compress", pdx_compress);
+
 void __init pfn_pdx_add_region(paddr_t base, paddr_t size)
 {
-    if ( !size )
+    /* Without ranges there's no PFN compression. */
+    if ( !size || !pdx_compress )
         return;
 
     if ( nr_ranges >= ARRAY_SIZE(ranges) )
@@ -215,6 +220,9 @@ void __init pfn_pdx_compression_setup(paddr_t base)
     unsigned int i, j, bottom_shift = 0, hole_shift = 0;
     unsigned long mask = pdx_init_mask(base) >> PAGE_SHIFT;
 
+    if ( !nr_ranges )
+        return;
+
     if ( nr_ranges > ARRAY_SIZE(ranges) )
     {
         printk(XENLOG_WARNING
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 20 11:11:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 11:11:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020844.1396965 (Exim 4.92)
	(envelope-from )
	id 1uSZel-0005Xo-OD; Fri, 20 Jun 2025 11:11:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020844.1396965; Fri, 20 Jun 2025 11:11: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 1uSZel-0005Xh-L0; Fri, 20 Jun 2025 11:11:39 +0000
Received: by outflank-mailman (input) for mailman id 1020844;
 Fri, 20 Jun 2025 11:11: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 1uSZek-0005XV-AG
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 11:11:38 +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 548d64f5-4dc7-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 13:11:36 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-43ea40a6e98so19883375e9.1
 for ; Fri, 20 Jun 2025 04:11:36 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a6d0f18215sm1745673f8f.29.2025.06.20.04.11.34
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 20 Jun 2025 04:11:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 548d64f5-4dc7-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750417895; x=1751022695; darn=lists.xenproject.org;
        h=content-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=zxbjBN87wnj0AUXMvgpO31kjAgExGSkQK2SRaU2awvM=;
        b=F4WW8zMa2sNxMiNbWZ93+M+ZG2Q2ni2wuLtPOYkBsi5M/JkSjwn0/H8GnZvg8zfksx
         b+qrpXKuWXSrcJvGoI5pxRyeuwOXU95374bFdVYNJ5n+kLy+ycL2wCbLSZUXEI6npurh
         Fz11vSE0adPSVTB4fnGCd0Me+CX0kiyPwHx/o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750417895; x=1751022695;
        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=zxbjBN87wnj0AUXMvgpO31kjAgExGSkQK2SRaU2awvM=;
        b=nWbpLs84TDQOpiMlzKhijNqv+2k8CjzntPRiCylTo19Vpm0krgEEH53RNyPYbUl2/C
         bohxwvvTuVRgPk01/k6VL8ul4Aci4cDShZxBnZqvfg62qlflZtstfA6Mug0czahZrWRH
         dtuxAsh7pE7RXS+57GsX7Ffcm8L/e+OfFCvt//B4i5sMIEZIjIwOqX40eThEtKAdJnJH
         PsYJjDFWkEhm4dSVBTfxGL80BSW9TXiTpy4uULSCSd/JwOnv01m0H2gEEOP6562TKoFV
         GsJJ5FH7GaKzDitWtea3Rivi50tKPpklF/CWo5k8B/00AOcsXqukjkuZYBEXYd0tCdql
         Wofw==
X-Gm-Message-State: AOJu0YzZtLIEMO39yafehOtGB8XvzxVHpXm4h3eP85I1NE8WgAe07Ge6
	gDzNnpq9j/s92VhRuU2Z64zb3JgpiLzDtxRKWLkUhlBhfsV5u1V0C0tGc+PABnl8gyiyJ2oaC1r
	9pZLB
X-Gm-Gg: ASbGnctU0P3Nf1hqSlORuUH+sr8kH6CiXtlzcjWP2UYj1852Luu/IrQ3LCiJiK+W0El
	C5pLVJvomx2KS5IwUuXsQiH2StblmVOF3Tjjl+beE1lvPe4IGsSRcN8ay0R9L+/NZs6mUZZuygM
	18/YRGFJvbGejpckXrw10rp9g5kK7FX+xeHW86zXkgbSwE44jybBSTrqhpPf86IDOHtNRK61S0z
	z1OWr0oYqMdohOhhZmsvcaFXKJC96qdpYoDS0vZ+NRKBr9L7ENTn821m56mNKcTDkCNqRbzbyke
	iPSQUU1TV2dJlxr5bvNL56T6uYIxC/b7G516eYqiy34/2rOj3uwNZ7Z+/Zyydm5b2GUPP4DRTZC
	qWMVEiil4I+SmJcneRo4wHo9hbphHHg==
X-Google-Smtp-Source: AGHT+IHIHPRlAOwa/O+aSU6bCJZbLczlcEvaLpUOCx3IIEZT5rimkIyoz4ISU2abc5Fd+dvjKFczNg==
X-Received: by 2002:a05:600c:4747:b0:43d:300f:fa1d with SMTP id 5b1f17b1804b1-453659c0c2fmr24473355e9.31.1750417895165;
        Fri, 20 Jun 2025 04:11:35 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH v2 1/8] x86/pdx: simplify calculation of domain struct allocation boundary
Date: Fri, 20 Jun 2025 13:11:23 +0200
Message-ID: <20250620111130.29057-2-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250620111130.29057-1-roger.pau@citrix.com>
References: <20250620111130.29057-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

When not using CONFIG_BIGMEM there are some restrictions in the address
width for allocations of the domain structure, as it's PDX truncated to 32
bits it's stashed into page_info structure for domain allocated pages.

The current logic to calculate this limit is based on the internals of the
PDX compression used, which is not strictly required.  Instead simplify the
logic to rely on the existing PDX to PFN conversion helpers used elsewhere.

This has the added benefit of allowing alternative PDX compression
algorithms to be implemented without requiring to change the calculation of
the domain structure allocation boundary.

As a side effect introduce pdx_to_paddr() conversion macro and use it.

Signed-off-by: Roger Pau Monné 
---
Changes since v1:
 - Use sizeof_field().
 - Introduce and use pdx_to_paddr().
 - Add comment.
---
 xen/arch/x86/domain.c | 40 +++++++++++-----------------------------
 xen/include/xen/pdx.h |  1 +
 2 files changed, 12 insertions(+), 29 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index d025befe3d8e..14a0f6dda791 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -461,30 +461,6 @@ void domain_cpu_policy_changed(struct domain *d)
     }
 }
 
-#if !defined(CONFIG_BIGMEM) && defined(CONFIG_PDX_COMPRESSION)
-/*
- * The hole may be at or above the 44-bit boundary, so we need to determine
- * the total bit count until reaching 32 significant (not squashed out) bits
- * in PFN representations.
- * Note that the way "bits" gets initialized/updated/bounds-checked guarantees
- * that the function will never return zero, and hence will never be called
- * more than once (which is important due to it being deliberately placed in
- * .init.text).
- */
-static unsigned int __init noinline _domain_struct_bits(void)
-{
-    unsigned int bits = 32 + PAGE_SHIFT;
-    unsigned int sig = hweight32(~pfn_hole_mask);
-    unsigned int mask = pfn_hole_mask >> 32;
-
-    for ( ; bits < BITS_PER_LONG && sig < 32; ++bits, mask >>= 1 )
-        if ( !(mask & 1) )
-            ++sig;
-
-    return bits;
-}
-#endif
-
 struct domain *alloc_domain_struct(void)
 {
     struct domain *d;
@@ -498,14 +474,20 @@ struct domain *alloc_domain_struct(void)
      * On systems with CONFIG_BIGMEM there's no packing, and so there's no
      * such restriction.
      */
-#if defined(CONFIG_BIGMEM) || !defined(CONFIG_PDX_COMPRESSION)
-    const unsigned int bits = IS_ENABLED(CONFIG_BIGMEM) ? 0 :
-                                                          32 + PAGE_SHIFT;
+#if defined(CONFIG_BIGMEM)
+    const unsigned int bits = 0;
 #else
-    static unsigned int __read_mostly bits;
+    static unsigned int __ro_after_init bits;
 
     if ( unlikely(!bits) )
-         bits = _domain_struct_bits();
+         /*
+          * Get the width for the next pfn, and unconditionally subtract one
+          * from it to ensure the used width will not allocate past the PDX
+          * field limit.
+          */
+         bits = flsl(pdx_to_paddr(1UL << (sizeof_field(struct page_info,
+                                                       v.inuse._domain) * 8)))
+                - 1;
 #endif
 
     BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
diff --git a/xen/include/xen/pdx.h b/xen/include/xen/pdx.h
index 9faeea3ac9f2..c1423d64a95b 100644
--- a/xen/include/xen/pdx.h
+++ b/xen/include/xen/pdx.h
@@ -99,6 +99,7 @@ bool __mfn_valid(unsigned long mfn);
 #define pdx_to_mfn(pdx) _mfn(pdx_to_pfn(pdx))
 
 #define paddr_to_pdx(pa) pfn_to_pdx(paddr_to_pfn(pa))
+#define pdx_to_paddr(px) pfn_to_paddr(pdx_to_pfn(px))
 
 #ifdef CONFIG_PDX_COMPRESSION
 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 20 11:11:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 11:11:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020846.1396979 (Exim 4.92)
	(envelope-from )
	id 1uSZen-0005oL-66; Fri, 20 Jun 2025 11:11:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020846.1396979; Fri, 20 Jun 2025 11:11: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 1uSZen-0005n7-1z; Fri, 20 Jun 2025 11:11:41 +0000
Received: by outflank-mailman (input) for mailman id 1020846;
 Fri, 20 Jun 2025 11:11: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 1uSZem-0005XW-HP
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 11:11:40 +0000
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com
 [2a00:1450:4864:20::336])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 53db68ae-4dc7-11f0-a30e-13f23c93f187;
 Fri, 20 Jun 2025 13:11:35 +0200 (CEST)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-442e9c00bf4so14076945e9.3
 for ; Fri, 20 Jun 2025 04:11:35 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-4535eac92c6sm55738645e9.22.2025.06.20.04.11.33
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 20 Jun 2025 04:11:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 53db68ae-4dc7-11f0-a30e-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750417894; x=1751022694; 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=cbSr8BZq+3XZdqzq/joJODJPefZlSpOFkrBuMBBZYHg=;
        b=pWH57ykMGbHy5o5r+biYW4+ot4hV0ifkG/0yGuRpaRJvMkU5Oa6GzuKGnDsuF85BPS
         smLTrUTNb5Muz2oZ6Ayq+MaPQ48r3rRdIEs/JWd2u+ng+LTz2qYy/0ieHhsupI32/eHR
         H44KG17gcPcBHj6vFi+V9jZMtsmhgrDx5HjvQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750417894; x=1751022694;
        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=cbSr8BZq+3XZdqzq/joJODJPefZlSpOFkrBuMBBZYHg=;
        b=s/zbPrldpVSl6JYsvEDa1jpsikxxe30Pk8uM7h21PYhM0+IivluMI7OixU+c+wjbtC
         t83MmEnuZ2wtmOrLC7jr/z0grdGPCEEmCyGSoKFnjuUAt5I7hn3SJ+Y6cn7oWo4Lrl1y
         lp9DeLeUVAgzCLWic85rYLTrbdeEGUu9hIRrF4vd6OB+GTIPVXOgNkkC5i+3a5CWKiVr
         w+ppYGUepkHIu9TRCa27P+qedjD23MfljcR6CPjME4ru7qTEm25Ua2Udt5WprPvgasS9
         y8Q52+g4kI1Nd3ycCavA/GOWxSOmSbXSkU4s8swmBf/nA2BTusMv7k22DBz+9f9rUIRZ
         gw+Q==
X-Gm-Message-State: AOJu0Yw2dshc7f3VFXbnktmO73vSuRezlGfsEOXTtgfxHnFXJut7Q4RP
	SYqc9wLjCJbxPnb/g7WRQSU1gxBIIjcZJKgsU0gLI2/kcBsn1j8E2Carywh0NOeTXKlueGKzQ0x
	zFWTj
X-Gm-Gg: ASbGnctPwvHVp6KnlETfJm4xWjXdDxP68hxkYFwb0vXFIae23RllDfB9Pbg3RN/Zjp7
	10bwEBUYUU3C3hqjIVr6FrUsGE35BvfBv8GRD9GtNTlG5fCGBCB8uMtU3fyC+3Fyp1Q7gyqn0VA
	fuWgIhEWrEcxJ9fGkdEtL7quhsrk0mnyeITk9ydvpdWCAqI77kXBiKa8f/xT8x0iedxqh7+2SiV
	dQzITjxUEJZ0AiUKRlY/uQ9OH+Zo0eSNKMLTPCFZ7fLkoyFJ+P/Eoty/DKIVG8kzzlDXjs8xrch
	I+WA/WuN1lLI2jElsU6CJB/1yWLXy80HJ+Zau6lSecMh88+bKpLT2ecp0XLSFt7Hj/8SGPuKeis
	qKenMNz/Q9FxT7kDFoT55jL0wv5C/EQ==
X-Google-Smtp-Source: AGHT+IHlaMyVJD2ny8QeL6lFPDknqP7u5lBmZibHUGYT5RKLYCVOrOnAE62aoEM7W+lLZbpUT5WQ+Q==
X-Received: by 2002:a05:600c:840f:b0:442:dc6f:7a21 with SMTP id 5b1f17b1804b1-453653cf3b8mr21225735e9.3.1750417893931;
        Fri, 20 Jun 2025 04:11:33 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	Stefano Stabellini ,
	Bertrand Marquis ,
	Volodymyr Babchuk ,
	Shawn Anastasio ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Oleksii Kurochko ,
	Community Manager 
Subject: [PATCH v2 0/8] pdx: introduce a new compression algorithm
Date: Fri, 20 Jun 2025 13:11:22 +0200
Message-ID: <20250620111130.29057-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hello,

This series implements a new PDX compression algorithm to cope with the
spare memory maps found on the Intel Sapphire/Granite Rapids.

Patches 1 to 7 prepare the existing code to make it easier to introduce
a new PDX compression, including generalizing the initialization and
setup functions and adding a unit test for PDX compression.

Patch 8 introduce the new compression.  The new compression is only
enabled by default on x86, other architectures are left with their
previous defaults.

Thanks, Roger.

Roger Pau Monne (8):
  x86/pdx: simplify calculation of domain struct allocation boundary
  kconfig: turn PDX compression into a choice
  pdx: provide a unified set of unit functions
  pdx: introduce command line compression toggle
  pdx: allow per-arch optimization of PDX conversion helpers
  test/pdx: add PDX compression unit tests
  pdx: move some helpers in preparation for new compression
  pdx: introduce a new compression algorithm based on region offsets

 CHANGELOG.md                           |   3 +
 docs/misc/xen-command-line.pandoc      |   9 +
 tools/tests/Makefile                   |   1 +
 tools/tests/pdx/.gitignore             |   3 +
 tools/tests/pdx/Makefile               |  49 ++++
 tools/tests/pdx/harness.h              |  99 +++++++
 tools/tests/pdx/test-pdx.c             | 224 +++++++++++++++
 xen/arch/arm/include/asm/Makefile      |   1 +
 xen/arch/arm/setup.c                   |  34 +--
 xen/arch/ppc/include/asm/Makefile      |   1 +
 xen/arch/riscv/include/asm/Makefile    |   1 +
 xen/arch/x86/domain.c                  |  40 +--
 xen/arch/x86/include/asm/cpufeatures.h |   1 +
 xen/arch/x86/include/asm/pdx.h         |  75 +++++
 xen/arch/x86/srat.c                    |  30 +-
 xen/common/Kconfig                     |  37 ++-
 xen/common/pdx.c                       | 379 ++++++++++++++++++++++---
 xen/include/asm-generic/pdx.h          |  24 ++
 xen/include/xen/pdx.h                  | 201 +++++++++----
 19 files changed, 1056 insertions(+), 156 deletions(-)
 create mode 100644 tools/tests/pdx/.gitignore
 create mode 100644 tools/tests/pdx/Makefile
 create mode 100644 tools/tests/pdx/harness.h
 create mode 100644 tools/tests/pdx/test-pdx.c
 create mode 100644 xen/arch/x86/include/asm/pdx.h
 create mode 100644 xen/include/asm-generic/pdx.h

-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 20 11:11:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 11:11:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020845.1396974 (Exim 4.92)
	(envelope-from )
	id 1uSZem-0005lS-UD; Fri, 20 Jun 2025 11:11:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020845.1396974; Fri, 20 Jun 2025 11: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 1uSZem-0005lK-R9; Fri, 20 Jun 2025 11:11:40 +0000
Received: by outflank-mailman (input) for mailman id 1020845;
 Fri, 20 Jun 2025 11:11: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 1uSZek-0005XW-Ow
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 11:11:38 +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 553e7198-4dc7-11f0-a30e-13f23c93f187;
 Fri, 20 Jun 2025 13:11:37 +0200 (CEST)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3a4f71831abso1460179f8f.3
 for ; Fri, 20 Jun 2025 04:11:37 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a6d0f1d1bbsm1771319f8f.41.2025.06.20.04.11.35
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 20 Jun 2025 04:11:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 553e7198-4dc7-11f0-a30e-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750417896; x=1751022696; darn=lists.xenproject.org;
        h=content-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=uXLi+ILPXh/BGa4CWHzGZodhu1oUday7zbZjpBMD9ug=;
        b=OV+N26tRC/hfZpn8XC708vr2ZDbYzVmnDz7jty9MlDnHbq5K+3PaG4bxUjM0wQbfLe
         8MlXX5YcmFOOwJdWQLPYqmVuNgw2JMWbhL+7qoOe9HLhzkBsp8yKeMVsOIooheeIfCef
         JPk5mhE0Ru6dYwHSLLLrYSdwto3d68I9UCUK0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750417896; x=1751022696;
        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=uXLi+ILPXh/BGa4CWHzGZodhu1oUday7zbZjpBMD9ug=;
        b=i0PIdlSmoybvRb6jpjTJFUvJ26UcIpdO4NmY0UnmNiGyrg3jM80/XZ3CirjHiUd5z0
         ffWP/Kq4Q2aRIWQt3/8WVqQ2tPR5XElM8VXu10UWfc7N+1cYWt0Fdw1OVnO/ovVfADed
         0g8Cy69P+/EyV4dnuaYcfJ8lYyo6uKPzvtB4LWG/mFERPIsBI8uAVwQ1QuOSobrnHYm1
         gasEZJyY2oD4x3XgtAifRp7ZfYCapA+yWILfPO2Di8wNU+YYMMT3NoAvSm/erKmEMPNM
         cmvA9mo+c7ObpP/QftDrZasiXJxSJn+lxNm2vm3sl4NlCGIgv/MA9y3kvkjpl6eiIx77
         oczA==
X-Gm-Message-State: AOJu0Yyg5mK5T2veEiF8f1y6zrvAjFpV3PajorivqnF2kQL084ApMBcR
	iWrYbOibWQKAgaJGgRqE3oH752Q/RFFrawG7pWJC3YnpNpFFH+LRQ1lIsSADKjXSocwL2Sp+nBd
	IMmJZ
X-Gm-Gg: ASbGncsCGJJQxtEObOsQKzVTKMW7FmCd802qrQt/y4V8NFO8QRlrH27qRNlmu7UY5Lg
	XA5BDwOC+VYntSNC8AmQSgwR+yLz+/h/O02N+J766c0FBQXAUbbR3D6ex0d9iEwEqINvMhk7rZH
	XiXtr9AOi/yQz06cG2X96w4psgJSyAWlgnz81UX6j7OQMMkbLtmgDNGLYUFudCV10XdwbKRY08W
	Dfq8JJ0ga8DzqrB8mmoKSaAeJyd40aC+7NrFEEqW6caKQFf8s+/zkFBAYWhv/Sxze0hhzsweDpq
	ee+YY75+tOdgrMeMfWBLG39IJNGKS5ELj33Rp5M7bHyf+g2IctnmTEd5HxteWxaw4tsUZnONzp6
	baHi5VSMsD78O99lY6Z/hSDWkIf849L4ehjCGxMJh
X-Google-Smtp-Source: AGHT+IG/dnMiX0uON1aC6uVJjxGOv669cfHteECQ1MNzB7CXV9EWo1d+70NpW6ec5RvrconHLky93g==
X-Received: by 2002:a05:6000:2308:b0:3a4:e6c6:b8bf with SMTP id ffacd0b85a97d-3a6d1325a45mr2054719f8f.52.1750417896284;
        Fri, 20 Jun 2025 04:11:36 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH v2 2/8] kconfig: turn PDX compression into a choice
Date: Fri, 20 Jun 2025 13:11:24 +0200
Message-ID: <20250620111130.29057-3-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250620111130.29057-1-roger.pau@citrix.com>
References: <20250620111130.29057-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Rename the current CONFIG_PDX_COMPRESSION to CONFIG_PDX_MASK_COMPRESSION,
and make it part of the PDX compression choice block, in preparation for
adding further PDX compression algorithms.

No functional change intended as the PDX compression defaults should still
be the same for all architectures, however the choice block cannot be
protected under EXPERT and still have a default choice being
unconditionally selected.  As a result, the new "PDX (Page inDeX)
compression" item will be unconditionally visible in Kconfig.

As part of this preparation work to introduce new PDX compressions, adjust
some of the comments on pdx.h to note they apply to a specific PDX
compression.  Also shuffle function prototypes and dummy implementations
around to make it easier to introduce a new PDX compression.  Note all
PDX compression implementations are expected to provide a
pdx_is_region_compressible() that takes the same set of arguments.

Signed-off-by: Roger Pau Monné 
Acked-by: Jan Beulich 
---
 xen/common/Kconfig    | 18 +++++++++++++++---
 xen/common/pdx.c      |  4 ++--
 xen/include/xen/pdx.h | 32 +++++++++++++++++++-------------
 3 files changed, 36 insertions(+), 18 deletions(-)

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 867710134ae5..de3e01d6320e 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -52,9 +52,10 @@ config EVTCHN_FIFO
 
 	  If unsure, say Y.
 
-config PDX_COMPRESSION
-	bool "PDX (Page inDeX) compression" if EXPERT && !X86 && !RISCV
-	default ARM || PPC
+choice
+	prompt "PDX (Page inDeX) compression"
+	default PDX_MASK_COMPRESSION if !X86 && !RISCV
+	default PDX_NONE
 	help
 	  PDX compression is a technique designed to reduce the memory
 	  overhead of physical memory management on platforms with sparse RAM
@@ -67,6 +68,17 @@ config PDX_COMPRESSION
 	  If your platform does not have sparse RAM banks, do not enable PDX
 	  compression.
 
+config PDX_MASK_COMPRESSION
+	bool "Mask compression"
+	help
+	  Compression relying on all RAM addresses sharing a zeroed bit region.
+
+config PDX_NONE
+	bool "None"
+	help
+	  No compression
+endchoice
+
 config ALTERNATIVE_CALL
 	bool
 
diff --git a/xen/common/pdx.c b/xen/common/pdx.c
index b8384e6189df..00aa7e43006d 100644
--- a/xen/common/pdx.c
+++ b/xen/common/pdx.c
@@ -34,7 +34,7 @@ bool __mfn_valid(unsigned long mfn)
 {
     bool invalid = mfn >= max_page;
 
-#ifdef CONFIG_PDX_COMPRESSION
+#ifdef CONFIG_PDX_MASK_COMPRESSION
     invalid |= mfn & pfn_hole_mask;
 #endif
 
@@ -55,7 +55,7 @@ void set_pdx_range(unsigned long smfn, unsigned long emfn)
         __set_bit(idx, pdx_group_valid);
 }
 
-#ifdef CONFIG_PDX_COMPRESSION
+#ifdef CONFIG_PDX_MASK_COMPRESSION
 
 /*
  * Diagram to make sense of the following variables. The masks and shifts
diff --git a/xen/include/xen/pdx.h b/xen/include/xen/pdx.h
index c1423d64a95b..8e373cac8b87 100644
--- a/xen/include/xen/pdx.h
+++ b/xen/include/xen/pdx.h
@@ -25,7 +25,7 @@
  * this by keeping a bitmap of the ranges in the frame table containing
  * invalid entries and not allocating backing memory for them.
  *
- * ## PDX compression
+ * ## PDX mask compression
  *
  * This is a technique to avoid wasting memory on machines known to have
  * split their machine address space in several big discontinuous and highly
@@ -101,22 +101,13 @@ bool __mfn_valid(unsigned long mfn);
 #define paddr_to_pdx(pa) pfn_to_pdx(paddr_to_pfn(pa))
 #define pdx_to_paddr(px) pfn_to_paddr(pdx_to_pfn(px))
 
-#ifdef CONFIG_PDX_COMPRESSION
+#ifdef CONFIG_PDX_MASK_COMPRESSION
 
 extern unsigned long pfn_pdx_bottom_mask, ma_va_bottom_mask;
 extern unsigned int pfn_pdx_hole_shift;
 extern unsigned long pfn_hole_mask;
 extern unsigned long pfn_top_mask, ma_top_mask;
 
-/**
- * Validate a region's compatibility with the current compression runtime
- *
- * @param base Base address of the region
- * @param npages Number of PAGE_SIZE-sized pages in the region
- * @return True iff the region can be used with the current compression
- */
-bool pdx_is_region_compressible(paddr_t base, unsigned long npages);
-
 /**
  * Calculates a mask covering "moving" bits of all addresses of a region
  *
@@ -209,7 +200,9 @@ static inline paddr_t directmapoff_to_maddr(unsigned long offset)
  */
 void pfn_pdx_hole_setup(unsigned long mask);
 
-#else /* !CONFIG_PDX_COMPRESSION */
+#endif /* CONFIG_PDX_MASK_COMPRESSION */
+
+#ifdef CONFIG_PDX_NONE
 
 /* Without PDX compression we can skip some computations */
 
@@ -241,7 +234,20 @@ static inline void pfn_pdx_hole_setup(unsigned long mask)
 {
 }
 
-#endif /* CONFIG_PDX_COMPRESSION */
+#else /* !CONFIG_PDX_NONE */
+
+/* Shared functions implemented by all PDX compressions. */
+
+/**
+ * Validate a region's compatibility with the current compression runtime
+ *
+ * @param base Base address of the region
+ * @param npages Number of PAGE_SIZE-sized pages in the region
+ * @return True iff the region can be used with the current compression
+ */
+bool pdx_is_region_compressible(paddr_t base, unsigned long npages);
+
+#endif /* !CONFIG_PDX_NONE */
 #endif /* __XEN_PDX_H__ */
 
 /*
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 20 11:11:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 11:11:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020849.1397015 (Exim 4.92)
	(envelope-from )
	id 1uSZer-0006hq-5A; Fri, 20 Jun 2025 11:11:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020849.1397015; Fri, 20 Jun 2025 11:11: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 1uSZer-0006hf-1c; Fri, 20 Jun 2025 11:11:45 +0000
Received: by outflank-mailman (input) for mailman id 1020849;
 Fri, 20 Jun 2025 11:11: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 1uSZeo-0005XV-UG
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 11:11:43 +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 576c161c-4dc7-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 13:11:41 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a522224582so820948f8f.3
 for ; Fri, 20 Jun 2025 04:11:41 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a6d1187e5fsm1749428f8f.70.2025.06.20.04.11.39
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 20 Jun 2025 04:11:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 576c161c-4dc7-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750417900; x=1751022700; darn=lists.xenproject.org;
        h=content-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=/5KdETCTr6PRNgEhyxor0tMVyilA2Hq7p2nHUt2X0SU=;
        b=bQTySAe75cQhFYfIOVxCKef84TVSNnDzsg79dYEzLqJsf7wmKSwDjYN5tSWBhjZwpU
         3PyNNhqo3vyyvxpZhD9tUadSk27y/p8i+5bTnE0z3lNO8WWMwhoXOPaNpETAQnqTtQLL
         yo5dygwMgpRUWxAyuAsVszPmXbxK7cfbgEtH4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750417900; x=1751022700;
        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=/5KdETCTr6PRNgEhyxor0tMVyilA2Hq7p2nHUt2X0SU=;
        b=EOyZazomngFAdVGrQ1cGTJ2IAK7jSS0qyn5pxbgIRXGaUZaaQNg1jc34OnHfuOIEQy
         7b7MPZfHQiNvFiQ3w61UFrnFEbua9xZAkOVW3M3ij53HstXe+et9SR0UHKvhj6uUOfYF
         quAk3J6RK3mKNY8Dnsdi+2qEhCZC2Z3wbLAZSjig+pPjCUqHTt1yRnDtpWhklE72o22n
         mhTewlycX4Makngxt9oOePDmx5uHK/hIpj7+6i7IY98NYrv5/1NWTtfzBCANyDVhixbW
         m++MRzWE67yTYa70Krv92A/vYeQMC+BSttEnPjiRm/alskMkDMqozc9qXkwtDK1ezgHg
         lE6Q==
X-Gm-Message-State: AOJu0YzCVK2jhlGdzZqeye3EMmTyyp8tfPG7Q01uqFvJuQRVvsZ+Qd2K
	Ykom7GP7SmjfAPWci8MzuBAzhLiNGpcc9PX2puldu3v1vbt2zSeNMM/7b0apYNSDr55VGClG6T0
	23pwl
X-Gm-Gg: ASbGncvfvuBIXZORmT+mala+q1kEQ8w1//iXTy7my3Qa5YZSeHUkUHxzjotrTnM8Rmh
	yrZv3C+jFP+vb9ys9sIuyq992yyZmTp1BvR9qoOAj9BbGVY9dxR9+/AJtmi7IpnTMv2wyZsBSEv
	EMgZcKqgQDzWCmpCh77POmqJJ9kItR1lAPRzBb9Ti2Uj2zXlYT8t5g4IWrvaSezeFVPIANuXcVI
	Ly7f6fzosnuUzJqNiIXwCUonJN1XcyDlD3FIZQm7M03g9lBE1cAjabZyMdXhiElL0sIcMp0bh6n
	vsGLi4sKhTfnIc25fSEFYXd6lE2NHWXYV1lSsvjLnNVqiTbM5fnESU+NP18R3Hw9GhRacSXSMbF
	+GGfEFvbpm99uTYnSogHPBikmN74MFA==
X-Google-Smtp-Source: AGHT+IEcdioiZeMRZJQMd51MKKnDuVxbVQwjb1BqB5XRm7Ridt6pmpEChfDT9rjV/RtK5h+Nxc1I+g==
X-Received: by 2002:a05:6000:4903:b0:3a4:dcb0:a5f with SMTP id ffacd0b85a97d-3a6d12a21d6mr2102448f8f.16.1750417900065;
        Fri, 20 Jun 2025 04:11:40 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Andrew Cooper ,
	Anthony PERARD ,
	Jan Beulich ,
	Shawn Anastasio ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Oleksii Kurochko 
Subject: [PATCH v2 5/8] pdx: allow per-arch optimization of PDX conversion helpers
Date: Fri, 20 Jun 2025 13:11:27 +0200
Message-ID: <20250620111130.29057-6-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250620111130.29057-1-roger.pau@citrix.com>
References: <20250620111130.29057-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

There are four performance critical PDX conversion helpers that do the PFN
to/from PDX and the physical addresses to/from directmap offsets
translations.

In the absence of an active PDX compression, those functions would still do
the calculations needed, just to return the same input value as no
translation is in place and hence PFN and PDX spaces are identity mapped.

To reduce the overhead of having to do the pointless calculations allow
architectures to implement the translation helpers in a per-arch header.
Rename the existing conversion functions to add a trailing _xlate suffix,
so that the per-arch headers can define the non suffixed versions.

Currently only x86 implements meaningful custom handlers to short circuit
the translation when not active, using asm goto.  Other architectures use a
generic header that maps the non-xlate to the xlate variants to keep the
previous behavior.

Signed-off-by: Roger Pau Monné 
---
Changes since v1:
 - Pull return out of OPTIMIZE_PDX macro.
 - undef OPTIMIZE_PDX.
---
Would it make sense to move the x86 implementation to the common pdx.h
header and let architectures define PDX_ASM_GOTO_SKIP instead?
---
 xen/arch/arm/include/asm/Makefile      |  1 +
 xen/arch/ppc/include/asm/Makefile      |  1 +
 xen/arch/riscv/include/asm/Makefile    |  1 +
 xen/arch/x86/include/asm/cpufeatures.h |  1 +
 xen/arch/x86/include/asm/pdx.h         | 75 ++++++++++++++++++++++++++
 xen/arch/x86/srat.c                    |  6 ++-
 xen/common/pdx.c                       | 10 ++--
 xen/include/asm-generic/pdx.h          | 24 +++++++++
 xen/include/xen/pdx.h                  | 22 +++++---
 9 files changed, 130 insertions(+), 11 deletions(-)
 create mode 100644 xen/arch/x86/include/asm/pdx.h
 create mode 100644 xen/include/asm-generic/pdx.h

diff --git a/xen/arch/arm/include/asm/Makefile b/xen/arch/arm/include/asm/Makefile
index 87c882142148..6283307cb0c4 100644
--- a/xen/arch/arm/include/asm/Makefile
+++ b/xen/arch/arm/include/asm/Makefile
@@ -6,6 +6,7 @@ generic-y += hardirq.h
 generic-y += iocap.h
 generic-y += irq-dt.h
 generic-y += paging.h
+generic-y += pdx.h
 generic-y += percpu.h
 generic-y += random.h
 generic-y += softirq.h
diff --git a/xen/arch/ppc/include/asm/Makefile b/xen/arch/ppc/include/asm/Makefile
index c989a7f89b34..0ad45133baac 100644
--- a/xen/arch/ppc/include/asm/Makefile
+++ b/xen/arch/ppc/include/asm/Makefile
@@ -6,6 +6,7 @@ generic-y += hardirq.h
 generic-y += hypercall.h
 generic-y += iocap.h
 generic-y += paging.h
+generic-y += pdx.h
 generic-y += percpu.h
 generic-y += perfc_defn.h
 generic-y += random.h
diff --git a/xen/arch/riscv/include/asm/Makefile b/xen/arch/riscv/include/asm/Makefile
index bfdf186c682f..de04daf68df3 100644
--- a/xen/arch/riscv/include/asm/Makefile
+++ b/xen/arch/riscv/include/asm/Makefile
@@ -7,6 +7,7 @@ generic-y += hypercall.h
 generic-y += iocap.h
 generic-y += irq-dt.h
 generic-y += paging.h
+generic-y += pdx.h
 generic-y += percpu.h
 generic-y += perfc_defn.h
 generic-y += random.h
diff --git a/xen/arch/x86/include/asm/cpufeatures.h b/xen/arch/x86/include/asm/cpufeatures.h
index 9e3ed21c026d..85e1a6f0a055 100644
--- a/xen/arch/x86/include/asm/cpufeatures.h
+++ b/xen/arch/x86/include/asm/cpufeatures.h
@@ -43,6 +43,7 @@ XEN_CPUFEATURE(XEN_IBT,           X86_SYNTH(27)) /* Xen uses CET Indirect Branch
 XEN_CPUFEATURE(IBPB_ENTRY_PV,     X86_SYNTH(28)) /* MSR_PRED_CMD used by Xen for PV */
 XEN_CPUFEATURE(IBPB_ENTRY_HVM,    X86_SYNTH(29)) /* MSR_PRED_CMD used by Xen for HVM */
 XEN_CPUFEATURE(USE_VMCALL,        X86_SYNTH(30)) /* Use VMCALL instead of VMMCALL */
+XEN_CPUFEATURE(PDX_COMPRESSION,   X86_SYNTH(31)) /* PDX compression */
 
 /* Bug words follow the synthetic words. */
 #define X86_NR_BUG 1
diff --git a/xen/arch/x86/include/asm/pdx.h b/xen/arch/x86/include/asm/pdx.h
new file mode 100644
index 000000000000..b09b44ceaf4a
--- /dev/null
+++ b/xen/arch/x86/include/asm/pdx.h
@@ -0,0 +1,75 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef X86_PDX_H
+#define X86_PDX_H
+
+#ifndef CONFIG_PDX_NONE
+
+#include 
+
+/*
+ * Introduce a macro to avoid repeating the same asm goto block in each helper.
+ * Note the macro is strictly tied to the code in the helpers.
+ */
+#define PDX_ASM_GOTO_SKIP                           \
+    asm_inline goto (                               \
+        ALTERNATIVE(                                \
+            "",                                     \
+            "jmp %l[skip]",                         \
+            ALT_NOT(X86_FEATURE_PDX_COMPRESSION))   \
+        : : : : skip )
+
+static inline unsigned long pfn_to_pdx(unsigned long pfn)
+{
+    PDX_ASM_GOTO_SKIP;
+
+    return pfn_to_pdx_xlate(pfn);
+
+ skip:
+    return pfn;
+}
+
+static inline unsigned long pdx_to_pfn(unsigned long pdx)
+{
+    PDX_ASM_GOTO_SKIP;
+
+    return pdx_to_pfn_xlate(pdx);
+
+ skip:
+    return pdx;
+}
+
+static inline unsigned long maddr_to_directmapoff(paddr_t ma)
+{
+    PDX_ASM_GOTO_SKIP;
+
+    return maddr_to_directmapoff_xlate(ma);
+
+ skip:
+    return ma;
+}
+
+static inline paddr_t directmapoff_to_maddr(unsigned long offset)
+{
+    PDX_ASM_GOTO_SKIP;
+
+    return directmapoff_to_maddr_xlate(offset);
+
+ skip:
+    return offset;
+}
+
+#undef PDX_ASM_GOTO_SKIP
+
+#endif /* !CONFIG_PDX_NONE */
+
+#endif /* X86_PDX_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/x86/srat.c b/xen/arch/x86/srat.c
index 2a678e744e7c..516db1b5bfa8 100644
--- a/xen/arch/x86/srat.c
+++ b/xen/arch/x86/srat.c
@@ -298,7 +298,8 @@ void __init srat_parse_regions(paddr_t addr)
 	acpi_table_parse_srat(ACPI_SRAT_TYPE_MEMORY_AFFINITY,
 			      srat_parse_region, 0);
 
-	pfn_pdx_compression_setup(addr);
+	if (!pfn_pdx_compression_setup(addr))
+		return;
 
 	/* Ensure all RAM ranges in the e820 are covered. */
 	for (i = 0; i < e820.nr_map; i++) {
@@ -318,6 +319,9 @@ void __init srat_parse_regions(paddr_t addr)
 			return;
 		}
 	}
+
+	/* If we got this far compression is working as expected. */
+	setup_force_cpu_cap(X86_FEATURE_PDX_COMPRESSION);
 }
 
 unsigned int numa_node_to_arch_nid(nodeid_t n)
diff --git a/xen/common/pdx.c b/xen/common/pdx.c
index 8c107676da59..86e2dc7c6bb6 100644
--- a/xen/common/pdx.c
+++ b/xen/common/pdx.c
@@ -215,20 +215,20 @@ static uint64_t __init pdx_init_mask(uint64_t base_addr)
                          (uint64_t)1 << (MAX_ORDER + PAGE_SHIFT)) - 1);
 }
 
-void __init pfn_pdx_compression_setup(paddr_t base)
+bool __init pfn_pdx_compression_setup(paddr_t base)
 {
     unsigned int i, j, bottom_shift = 0, hole_shift = 0;
     unsigned long mask = pdx_init_mask(base) >> PAGE_SHIFT;
 
     if ( !nr_ranges )
-        return;
+        return false;
 
     if ( nr_ranges > ARRAY_SIZE(ranges) )
     {
         printk(XENLOG_WARNING
                "Too many PFN ranges (%u > %zu), not attempting PFN compression\n",
                nr_ranges, ARRAY_SIZE(ranges));
-        return;
+        return false;
     }
 
     for ( i = 0; i < nr_ranges; i++ )
@@ -259,7 +259,7 @@ void __init pfn_pdx_compression_setup(paddr_t base)
         }
     }
     if ( !hole_shift )
-        return;
+        return false;
 
     printk(KERN_INFO "PFN compression on bits %u...%u\n",
            bottom_shift, bottom_shift + hole_shift - 1);
@@ -270,6 +270,8 @@ void __init pfn_pdx_compression_setup(paddr_t base)
     pfn_hole_mask       = ((1UL << hole_shift) - 1) << bottom_shift;
     pfn_top_mask        = ~(pfn_pdx_bottom_mask | pfn_hole_mask);
     ma_top_mask         = pfn_top_mask << PAGE_SHIFT;
+
+    return true;
 }
 
 void __init pfn_pdx_compression_reset(void)
diff --git a/xen/include/asm-generic/pdx.h b/xen/include/asm-generic/pdx.h
new file mode 100644
index 000000000000..4dea2b97c3e5
--- /dev/null
+++ b/xen/include/asm-generic/pdx.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef GENERIC_PDX_H
+#define GENERIC_PDX_H
+
+#ifndef CONFIG_PDX_NONE
+
+#define pdx_to_pfn pdx_to_pfn_xlate
+#define pfn_to_pdx pfn_to_pdx_xlate
+#define maddr_to_directmapoff maddr_to_directmapoff_xlate
+#define directmapoff_to_maddr directmapoff_to_maddr_xlate
+
+#endif /* !CONFIG_PDX_NONE */
+
+#endif /* GENERIC_PDX_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/pdx.h b/xen/include/xen/pdx.h
index 10153da98bf1..91fc32370f21 100644
--- a/xen/include/xen/pdx.h
+++ b/xen/include/xen/pdx.h
@@ -114,7 +114,7 @@ extern unsigned long pfn_top_mask, ma_top_mask;
  * @param pfn Frame number
  * @return Obtained pdx after compressing the pfn
  */
-static inline unsigned long pfn_to_pdx(unsigned long pfn)
+static inline unsigned long pfn_to_pdx_xlate(unsigned long pfn)
 {
     return (pfn & pfn_pdx_bottom_mask) |
            ((pfn & pfn_top_mask) >> pfn_pdx_hole_shift);
@@ -126,7 +126,7 @@ static inline unsigned long pfn_to_pdx(unsigned long pfn)
  * @param pdx Page index
  * @return Obtained pfn after decompressing the pdx
  */
-static inline unsigned long pdx_to_pfn(unsigned long pdx)
+static inline unsigned long pdx_to_pfn_xlate(unsigned long pdx)
 {
     return (pdx & pfn_pdx_bottom_mask) |
            ((pdx << pfn_pdx_hole_shift) & pfn_top_mask);
@@ -139,7 +139,7 @@ static inline unsigned long pdx_to_pfn(unsigned long pdx)
  * @return Offset on the direct map where that
  *         machine address can be accessed
  */
-static inline unsigned long maddr_to_directmapoff(paddr_t ma)
+static inline unsigned long maddr_to_directmapoff_xlate(paddr_t ma)
 {
     return (((ma & ma_top_mask) >> pfn_pdx_hole_shift) |
             (ma & ma_va_bottom_mask));
@@ -151,7 +151,7 @@ static inline unsigned long maddr_to_directmapoff(paddr_t ma)
  * @param offset Offset into the direct map
  * @return Corresponding machine address of that virtual location
  */
-static inline paddr_t directmapoff_to_maddr(unsigned long offset)
+static inline paddr_t directmapoff_to_maddr_xlate(unsigned long offset)
 {
     return ((((paddr_t)offset << pfn_pdx_hole_shift) & ma_top_mask) |
             (offset & ma_va_bottom_mask));
@@ -159,6 +159,14 @@ static inline paddr_t directmapoff_to_maddr(unsigned long offset)
 
 #endif /* CONFIG_PDX_MASK_COMPRESSION */
 
+/*
+ * Allow each architecture to define it's (possibly optimized) versions of the
+ * translation functions.
+ *
+ * Do not use _xlate suffixed functions, always use the non _xlate variants.
+ */
+#include 
+
 #ifdef CONFIG_PDX_NONE
 
 /* Without PDX compression we can skip some computations */
@@ -181,8 +189,9 @@ static inline void pfn_pdx_add_region(paddr_t base, paddr_t size)
 {
 }
 
-static inline void pfn_pdx_compression_setup(paddr_t base)
+static inline bool pfn_pdx_compression_setup(paddr_t base)
 {
+    return false;
 }
 
 static inline void pfn_pdx_compression_reset(void)
@@ -215,8 +224,9 @@ void pfn_pdx_add_region(paddr_t base, paddr_t size);
  * range of the current memory regions.
  *
  * @param base address to start compression from.
+ * @return True if PDX compression has been enabled.
  */
-void pfn_pdx_compression_setup(paddr_t base);
+bool pfn_pdx_compression_setup(paddr_t base);
 
 /**
  * Reset the global variables to it's default values, thus disabling PFN
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 20 11:11:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 11:11:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020852.1397046 (Exim 4.92)
	(envelope-from )
	id 1uSZev-0007Xa-CN; Fri, 20 Jun 2025 11:11:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020852.1397046; Fri, 20 Jun 2025 11: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 1uSZev-0007XI-5P; Fri, 20 Jun 2025 11:11:49 +0000
Received: by outflank-mailman (input) for mailman id 1020852;
 Fri, 20 Jun 2025 11:11: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 1uSZet-0005XV-Ac
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 11:11:47 +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 59dcd9af-4dc7-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 13:11:45 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-450ce3a2dd5so16034065e9.3
 for ; Fri, 20 Jun 2025 04:11:45 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a6d117bf84sm1799740f8f.52.2025.06.20.04.11.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 20 Jun 2025 04:11:43 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 59dcd9af-4dc7-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750417904; x=1751022704; darn=lists.xenproject.org;
        h=content-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=0EppsXevlN8t9Gr9z9XeGe/QocwyvsD0c3ipo1S2G3o=;
        b=v77PPkKLFkd0FhahMzY5fthx3M7oJbuzU/TQfe94GYFS4V0woo5yb8AmhHD11n0SzH
         bGi9yQDfv6uXSJfVDjXfkIcT1Oh/uZYFCwpUEpwOjy4RUCW8pYxHZqyXo/7s7mOpYebr
         HpeiIDpy/EZnXPhS4zVNqiBVUcqwxRTLuFp4I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750417904; x=1751022704;
        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=0EppsXevlN8t9Gr9z9XeGe/QocwyvsD0c3ipo1S2G3o=;
        b=KhnyY+ehv8PckgFv1DWt+shU5oEzxiv3hvw0vkU98OtYlAa5WX8emx7NO28H/mc4Ei
         Nir3v9lKsLkgqRvwkGePzInVm36oZ0fbwToaM7JJT9i7WorPnkqMhM8vaP9om8O168HY
         LgABqOKamuuWQVZW6b926FZm9PAnd7v+CiBeqb14mbV8mHnPYoVoFLX5QkpAp2HjdkPs
         dz0ZZyEcBr3Qe6TnyPjl59yaP9kVj+sQk3uF75TdMIHQBtpVw0OTdBhoR4jJRXmamLhr
         uQARdGfCo4SOecGsvgwQiDU2P55mSKAW4hVrk9K9ojINW7JSFVEDT271Mvq6AeqsUuQj
         Yw1g==
X-Gm-Message-State: AOJu0YyaF1YzMZiYaMuvPWIDuxtfsJDQYDO4oWOenQklAfzYJSE2FcJJ
	z1TOXJP2T07Gr4cV6wUt6LwsOx7MgF2CfbXdN3uS9qBfLDGQLEzXrbqbGzHaCvFdJAHNC6duC+i
	HiU4F
X-Gm-Gg: ASbGncsuIUuy/IvmyxMJapMO+VtgU5wByEKnAQ8Prktt3PYM7Toa2QHRXlsRHZRqU5G
	ZlET22tSwO5Gh6xTGmVe77cq7la36T1agX3jejBb26Sf215wYJMnyq4jdvdMpF/ir4ijskPdo8j
	G3NrOWsNx/1K2IIZh0+TKzKUNdfLBc91AnwRu0aS1jJNCgQe5nWb5HPMX8FlmR8Dx6VGsjr/e42
	H0GloT4a0HK5GdJ3tKOUBl+EzVEqVwgAzIYgue/9ETfRyRZRG2dF5aoqsrOABmRgb4txhC6AkNf
	QufmwEi81byuQO2j/IuUgAixoENSSsw3AFADU0+VM4PWL7EZDvSWmiIuFFUi+GmJ9XKldWvAzek
	hr8qobRLZSjWC4vZ/0tXOqeR/g7N5Xg==
X-Google-Smtp-Source: AGHT+IHH4E8k77+piYjiOuRyGh86QQCIMgfRjfInHrK0vvRWK5fzMQEJ5BPi30ToGUQQYUL1Mv4DEg==
X-Received: by 2002:a05:6000:4203:b0:3a4:fea6:d49f with SMTP id ffacd0b85a97d-3a6d12eb49emr1750944f8f.49.1750417903822;
        Fri, 20 Jun 2025 04:11:43 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Oleksii Kurochko ,
	Community Manager ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH v2 8/8] pdx: introduce a new compression algorithm based on region offsets
Date: Fri, 20 Jun 2025 13:11:30 +0200
Message-ID: <20250620111130.29057-9-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250620111130.29057-1-roger.pau@citrix.com>
References: <20250620111130.29057-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

With the appearance of Intel Sierra Forest and Granite Rapids it's now
possible to get a production x86 host with the following memory map:

SRAT: Node 0 PXM 0 [0000000000000000, 000000007fffffff]
SRAT: Node 0 PXM 0 [0000000100000000, 000000807fffffff]
SRAT: Node 1 PXM 1 [0000063e80000000, 000006be7fffffff]
SRAT: Node 2 PXM 2 [00000c7e80000000, 00000cfe7fffffff]
SRAT: Node 3 PXM 3 [000012be80000000, 0000133e7fffffff]

This is from a four socket Granite Rapids system, with each node having
512GB of memory.  The total amount of RAM on the system is 2TB, but without
enabling CONFIG_BIGMEM the last range is not accessible, as it's above the
16TB boundary covered by the frame table. Sierra Forest and Granite Rapids
are socket compatible, however Sierra Forest only supports 2 socket
configurations, while Granite Rapids can go up to 8 sockets.

Note that while the memory map is very sparse, it couldn't be compressed
using the current PDX_MASK compression algorithm, which relies on all
ranges having a shared zeroed region of bits that can be removed.

The memory map presented above has the property of all regions being
similarly spaced between each other, and all having also a similar size.
Use a lookup table to store the offsets to translate from/to PFN and PDX
spaces.  Such table is indexed based on the input PFN or PDX to translated.
The example PFN layout about would get compressed using the following:

PFN compression using PFN lookup table shift 29 and PDX region size 0x10000000
 range 0 [0000000000000, 0x0000807ffff] PFN IDX  0 : 0000000000000
 range 1 [0x00063e80000, 0x0006be7ffff] PFN IDX  3 : 0x00053e80000
 range 2 [0x000c7e80000, 0x000cfe7ffff] PFN IDX  6 : 0x000a7e80000
 range 3 [0x0012be80000, 0x00133e7ffff] PFN IDX  9 : 0x000fbe80000

Note how the tow ranges belonging to node 0 get merged into a single PDX
region by the compression algorithm.

The default size of lookup tables currently set in Kconfig is 64 entries,
and the example memory map consumes 10 entries.  Such memory map is from a
4 socket Granite Rapids host, which in theory supports up to 8 sockets
according to Intel documentation.  Assuming the layout of a 8 socket system
is similar to the 4 socket one, it would require 21 lookup table entries to
support it, way below the current default of 64 entries.

The valid range of lookup table size is currently restricted from 1 to 512
elements in Kconfig.

Unused lookup table entries are set to all ones (~0UL), so that we can
detect whether a pfn or pdx is valid just by checking whether its
translation is bi-directional.  The saturated offsets will prevent the
translation from being bidirectional if the lookup table entry is not
valid.

Introduce __init_or_pdx_mask and use it on some shared functions between
PDX mask and offset compression, as otherwise some code becomes unreachable
after boot if PDX offset compression is used.  Mark the code as __init in
that case, so it's pruned after boot.

Signed-off-by: Roger Pau Monné 
---
Changes since v1:
 - Use a lookup table with the offsets.
 - Split the adding of the test to a pre-patch.
 - Amend diagram to also show possible padding after compression.
---
 CHANGELOG.md               |   3 +
 tools/tests/pdx/.gitignore |   1 +
 tools/tests/pdx/Makefile   |   3 +-
 tools/tests/pdx/harness.h  |  10 ++
 tools/tests/pdx/test-pdx.c |   4 +
 xen/common/Kconfig         |  21 +++-
 xen/common/pdx.c           | 209 ++++++++++++++++++++++++++++++++++++-
 xen/include/xen/pdx.h      |  85 ++++++++++++++-
 8 files changed, 330 insertions(+), 6 deletions(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 5f31ca08fe3f..7023820b38c1 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -20,6 +20,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
      grant table or foreign memory.
 
 ### Added
+ - Introduce new PDX compression algorithm to cope with Intel Sapphire and
+   Granite Rapids having sparse memory maps.
+
  - On x86:
    - Option to attempt to fixup p2m page-faults on PVH dom0.
    - Resizable BARs is supported for PVH dom0.
diff --git a/tools/tests/pdx/.gitignore b/tools/tests/pdx/.gitignore
index a32c7db4de79..1202a531a7fd 100644
--- a/tools/tests/pdx/.gitignore
+++ b/tools/tests/pdx/.gitignore
@@ -1,2 +1,3 @@
 /pdx.h
 /test-pdx-mask
+/test-pdx-offset
diff --git a/tools/tests/pdx/Makefile b/tools/tests/pdx/Makefile
index 99867b71c438..ba1724bb6616 100644
--- a/tools/tests/pdx/Makefile
+++ b/tools/tests/pdx/Makefile
@@ -1,7 +1,7 @@
 XEN_ROOT=$(CURDIR)/../../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-TARGETS := test-pdx-mask
+TARGETS := test-pdx-mask test-pdx-offset
 
 .PHONY: all
 all: $(TARGETS)
@@ -41,6 +41,7 @@ CFLAGS += $(APPEND_CFLAGS)
 CFLAGS += $(CFLAGS_xeninclude)
 
 test-pdx-mask: CFLAGS += -DCONFIG_PDX_MASK_COMPRESSION
+test-pdx-offset: CFLAGS += -DCONFIG_PDX_OFFSET_COMPRESSION
 
 test-pdx-%: test-pdx.c pdx.h
 	$(CC) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_$*.o) -o $@ $< $(APPEND_CFLAGS)
diff --git a/tools/tests/pdx/harness.h b/tools/tests/pdx/harness.h
index 64ec09f5e281..c58a6f27ad03 100644
--- a/tools/tests/pdx/harness.h
+++ b/tools/tests/pdx/harness.h
@@ -44,8 +44,10 @@
 
 #define MAX_RANGES 8
 #define MAX_PFN_RANGES MAX_RANGES
+#define CONFIG_PDX_OFFSET_TLB_ORDER 6
 
 #define ASSERT assert
+#define ASSERT_UNREACHABLE() assert(0);
 
 #define CONFIG_DEBUG
 
@@ -66,6 +68,8 @@ static inline unsigned int find_next(
 #define find_next_zero_bit(a, s, o) find_next(a, s, o, false)
 #define find_next_bit(a, s, o)      find_next(a, s, o, true)
 
+#define flsl(x) ((x) ? BITS_PER_LONG - __builtin_clzl(x) : 0)
+
 #define boolean_param(name, func)
 
 #define pdx_to_pfn pdx_to_pfn_xlate
@@ -75,6 +79,12 @@ static inline unsigned int find_next(
 
 typedef uint64_t paddr_t;
 
+#define sort(elem, nr, size, cmp, swp) {                                \
+    /* Consume swp() so compiler doesn't complain it's unused. */       \
+    (void)swp;                                                          \
+    qsort(elem, nr, size, cmp);                                         \
+}
+
 #include "pdx.h"
 
 #endif
diff --git a/tools/tests/pdx/test-pdx.c b/tools/tests/pdx/test-pdx.c
index b717cae00711..5041228a383c 100644
--- a/tools/tests/pdx/test-pdx.c
+++ b/tools/tests/pdx/test-pdx.c
@@ -51,7 +51,11 @@ int main(int argc, char **argv)
                 { .start =  0xc7e80000UL, .end =  0xcfe80000UL },
                 { .start = 0x12be80000UL, .end = 0x133e80000UL },
             },
+#ifdef CONFIG_PDX_OFFSET_COMPRESSION
+            .compress = true,
+#else
             .compress = false,
+#endif
         },
         /* Simple hole. */
         {
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index de3e01d6320e..6d49ef535f0c 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -54,7 +54,8 @@ config EVTCHN_FIFO
 
 choice
 	prompt "PDX (Page inDeX) compression"
-	default PDX_MASK_COMPRESSION if !X86 && !RISCV
+	default PDX_OFFSET_COMPRESSION if X86
+	default PDX_MASK_COMPRESSION if !RISCV
 	default PDX_NONE
 	help
 	  PDX compression is a technique designed to reduce the memory
@@ -73,12 +74,30 @@ config PDX_MASK_COMPRESSION
 	help
 	  Compression relying on all RAM addresses sharing a zeroed bit region.
 
+config PDX_OFFSET_COMPRESSION
+	bool "Offset compression"
+	help
+	  Compression relying on size and distance between RAM regions being
+	  compressible using an offset lookup table.
+
 config PDX_NONE
 	bool "None"
 	help
 	  No compression
 endchoice
 
+config PDX_OFFSET_TLB_ORDER
+	int "PDX offset compression lookup table order" if EXPERT
+	depends on PDX_OFFSET_COMPRESSION
+	default 6
+	range 0 9
+	help
+	  Order of the PFN to PDX and PDX to PFN translation lookup tables.
+	  Number of table entries is calculated as 2^N.
+
+	  Size of the tables can be adjusted from 1 entry (order 0) to 512
+	  entries (order 9).
+
 config ALTERNATIVE_CALL
 	bool
 
diff --git a/xen/common/pdx.c b/xen/common/pdx.c
index d5e469baffe2..ff3534122c72 100644
--- a/xen/common/pdx.c
+++ b/xen/common/pdx.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
  * Maximum (non-inclusive) usable pdx. Must be
@@ -40,6 +41,8 @@ bool __mfn_valid(unsigned long mfn)
 
 #ifdef CONFIG_PDX_MASK_COMPRESSION
     invalid |= mfn & pfn_hole_mask;
+#elif defined(CONFIG_PDX_OFFSET_COMPRESSION)
+    invalid |= mfn ^ pdx_to_pfn(pfn_to_pdx(mfn));
 #endif
 
     if ( unlikely(evaluate_nospec(invalid)) )
@@ -75,6 +78,13 @@ void set_pdx_range(unsigned long smfn, unsigned long emfn)
 # error "Missing architecture maximum number of RAM ranges"
 #endif
 
+/* Some functions should be init when not using PDX mask compression. */
+#ifndef CONFIG_PDX_MASK_COMPRESSION
+# define __init_or_pdx_mask __init
+#else
+# define __init_or_pdx_mask
+#endif
+
 /* Generic PFN compression helpers. */
 static struct pfn_range {
     unsigned long base, size;
@@ -102,7 +112,7 @@ void __init pfn_pdx_add_region(paddr_t base, paddr_t size)
 }
 
 /* Sets all bits from the most-significant 1-bit down to the LSB */
-static uint64_t fill_mask(uint64_t mask)
+static uint64_t __init_or_pdx_mask fill_mask(uint64_t mask)
 {
     while (mask & (mask + 1))
         mask |= mask + 1;
@@ -128,7 +138,7 @@ static uint64_t fill_mask(uint64_t mask)
  * @param len  Size in octets of the region
  * @return Mask of moving bits at the bottom of all the region addresses
  */
-static uint64_t pdx_region_mask(uint64_t base, uint64_t len)
+static uint64_t __init_or_pdx_mask pdx_region_mask(uint64_t base, uint64_t len)
 {
     /*
      * We say a bit "moves" in a range if there exist 2 addresses in that
@@ -290,7 +300,200 @@ void __init pfn_pdx_compression_reset(void)
     nr_ranges = 0;
 }
 
-#endif /* CONFIG_PDX_COMPRESSION */
+#elif defined(CONFIG_PDX_OFFSET_COMPRESSION) /* CONFIG_PDX_MASK_COMPRESSION */
+
+unsigned long __ro_after_init pfn_pdx_lookup[CONFIG_PDX_NR_LOOKUP];
+unsigned int __ro_after_init pfn_index_shift;
+
+unsigned long __ro_after_init pdx_pfn_lookup[CONFIG_PDX_NR_LOOKUP];
+unsigned int __ro_after_init pdx_index_shift;
+
+bool pdx_is_region_compressible(paddr_t base, unsigned long npages)
+{
+    unsigned long pfn = PFN_DOWN(base);
+
+    return pdx_to_pfn(pfn_to_pdx(pfn) + npages - 1) == (pfn + npages - 1);
+}
+
+static int __init cf_check cmp_node(const void *a, const void *b)
+{
+    const struct pfn_range *l = a;
+    const struct pfn_range *r = b;
+
+    if ( l->base > r->base )
+        return 1;
+    if ( l->base < r->base )
+        return -1;
+
+    return 0;
+}
+
+static void __init cf_check swp_node(void *a, void *b, size_t size)
+{
+    struct pfn_range *l = a;
+    struct pfn_range *r = b;
+    struct pfn_range tmp = *l;
+
+    *l = *r;
+    *r = tmp;
+}
+
+static bool __init pfn_offset_sanitize_ranges(void)
+{
+    unsigned int i = 0;
+
+    if ( nr_ranges == 1 )
+    {
+        ASSERT(PFN_TBL_IDX_VALID(ranges[0].base));
+        ASSERT(PFN_TBL_IDX(ranges[0].base) ==
+               PFN_TBL_IDX(ranges[0].base + ranges[0].size - 1));
+        return true;
+    }
+
+    /* Sort nodes by start address. */
+    sort(ranges, nr_ranges, sizeof(struct pfn_range), cmp_node, swp_node);
+
+    /* Sanitize and merge ranges if possible. */
+    while ( i + 1 < nr_ranges )
+    {
+        /* No overlap between ranges. */
+        if ( ranges[i].base + ranges[i].size > ranges[i + 1].base )
+        {
+            printk(XENLOG_WARNING
+"Invalid ranges for PDX compression: [%#lx, %#lx] overlaps [%#lx, %#lx]\n",
+                   ranges[i].base, ranges[i].base + ranges[i].size - 1,
+                   ranges[i + 1].base,
+                   ranges[i + 1].base + ranges[i + 1].size - 1);
+            return false;
+        }
+
+        /* Ensure lookup indexes don't overflow table size. */
+        if ( !PFN_TBL_IDX_VALID(ranges[i].base) ||
+             !PFN_TBL_IDX_VALID(ranges[i].base + ranges[i].size - 1) ||
+             !PFN_TBL_IDX_VALID(ranges[i + 1].base) ||
+             !PFN_TBL_IDX_VALID(ranges[i + 1].base + ranges[i + 1].size - 1) )
+            return false;
+
+        /*
+         * Ensure ranges [start, end] use the same offset table index.  Should
+         * be guaranteed by the logic that calculates the pfn shift.
+         */
+        if ( PFN_TBL_IDX(ranges[i].base) !=
+             PFN_TBL_IDX(ranges[i].base + ranges[i].size - 1) ||
+             PFN_TBL_IDX(ranges[i + 1].base) !=
+             PFN_TBL_IDX(ranges[i + 1].base + ranges[i + 1].size - 1) )
+        {
+            ASSERT_UNREACHABLE();
+            return false;
+        }
+
+        if ( PFN_TBL_IDX(ranges[i].base) != PFN_TBL_IDX(ranges[i + 1].base) )
+        {
+            i++;
+            continue;
+        }
+
+        /* Merge ranges with the same table index. */
+        ranges[i].size = ranges[i + 1].base + ranges[i + 1].size -
+                         ranges[i].base;
+        memmove(&ranges[i + 1], &ranges[i + 2],
+                (nr_ranges - (i + 2)) * sizeof(ranges[0]));
+        nr_ranges--;
+    }
+
+    return true;
+}
+
+bool __init pfn_pdx_compression_setup(paddr_t base)
+{
+    unsigned long size = 0, mask = PFN_DOWN(pdx_init_mask(base));
+    unsigned int i;
+
+    if ( !nr_ranges )
+        return false;
+
+    if ( nr_ranges > ARRAY_SIZE(ranges) )
+    {
+        printk(XENLOG_WARNING
+               "Too many PFN ranges (%u > %zu), not attempting PFN compression\n",
+               nr_ranges, ARRAY_SIZE(ranges));
+        return false;
+    }
+
+    for ( i = 0; i < nr_ranges; i++ )
+        mask |= pdx_region_mask(ranges[i].base, ranges[i].size);
+
+    pfn_index_shift = flsl(mask);
+
+    /*
+     * Increase the shift as much as possible, removing bits that are equal in
+     * all regions, as this allows the usage of smaller indexes, and in turn
+     * smaller lookup tables.
+     */
+    for ( pfn_index_shift = flsl(mask); pfn_index_shift < sizeof(mask) * 8 - 1;
+          pfn_index_shift++ )
+    {
+        const unsigned long bit = ranges[0].base & (1UL << pfn_index_shift);
+
+        for ( i = 1; i < nr_ranges; i++ )
+            if ( bit != (ranges[i].base & (1UL << pfn_index_shift)) )
+                break;
+        if ( i != nr_ranges )
+            break;
+    }
+
+    /* Sort and sanitize ranges. */
+    if ( !pfn_offset_sanitize_ranges() )
+        return false;
+
+    /* Calculate PDX region size. */
+    for ( i = 0; i < nr_ranges; i++ )
+        size = max(size, ranges[i].size);
+
+    mask = PFN_DOWN(pdx_init_mask(size << PAGE_SHIFT));
+    pdx_index_shift = flsl(mask);
+
+    /* Avoid compression if there's no gain. */
+    if ( (mask + 1) * (nr_ranges - 1) >= ranges[nr_ranges - 1].base )
+        return false;
+
+    /* Poison all lookup table entries ahead of setting them. */
+    memset(pfn_pdx_lookup, ~0, sizeof(pfn_pdx_lookup));
+    memset(pdx_pfn_lookup, ~0, sizeof(pfn_pdx_lookup));
+
+    for ( i = 0; i < nr_ranges; i++ )
+    {
+        unsigned int idx = PFN_TBL_IDX(ranges[i].base);
+
+        pfn_pdx_lookup[idx] = ranges[i].base - (mask + 1) * i;
+        pdx_pfn_lookup[i] = pfn_pdx_lookup[idx];
+    }
+
+    printk(XENLOG_INFO
+           "PFN compression using PFN lookup table shift %u and PDX region size %#lx\n",
+           pfn_index_shift, mask + 1);
+
+    for ( i = 0; i < nr_ranges; i++ )
+        printk(XENLOG_DEBUG
+               " range %u [%#013lx, %#013lx] PFN IDX %3lu : %#013lx\n",
+               i, ranges[i].base, ranges[i].base + ranges[i].size - 1,
+               PFN_TBL_IDX(ranges[i].base),
+               pfn_pdx_lookup[PFN_TBL_IDX(ranges[i].base)]);
+
+    return true;
+}
+
+void __init pfn_pdx_compression_reset(void)
+{
+    memset(pfn_pdx_lookup, 0, sizeof(pfn_pdx_lookup));
+    memset(pdx_pfn_lookup, 0, sizeof(pfn_pdx_lookup));
+    pfn_index_shift = 0;
+    pdx_index_shift = 0;
+
+    nr_ranges = 0;
+}
+
+#endif /* CONFIG_PDX_OFFSET_COMPRESSION */
 
 /*
  * Local variables:
diff --git a/xen/include/xen/pdx.h b/xen/include/xen/pdx.h
index 91fc32370f21..450e07de2764 100644
--- a/xen/include/xen/pdx.h
+++ b/xen/include/xen/pdx.h
@@ -65,6 +65,43 @@
  * This scheme also holds for multiple regions, where HHHHHHH acts as
  * the region identifier and LLLLLL fully contains the span of every
  * region involved.
+ *
+ * ## PDX offset compression
+ *
+ * Alternative compression mechanism that relies on RAM ranges having a similar
+ * size and offset between them:
+ *
+ * PFN address space:
+ * ┌────────┬──────────┬────────┬──────────┐   ┌────────┬──────────┐
+ * │ RAM 0  │          │ RAM 1  │          │...│ RAM N  │          │
+ * ├────────┼──────────┼────────┴──────────┘   └────────┴──────────┘
+ * │<------>│          │
+ * │  size             │
+ * │<----------------->│
+ *         offset
+ *
+ * The compression reduces the holes between RAM regions:
+ *
+ * PDX address space:
+ * ┌────────┬───┬────────┬───┐   ┌─┬────────┐
+ * │ RAM 0  │   │ RAM 1  │   │...│ │ RAM N  │
+ * ├────────┴───┼────────┴───┘   └─┴────────┘
+ * │<---------->│
+ *   pdx region size
+ *
+ * The offsets to convert from PFN to PDX and from PDX to PFN are stored in a
+ * pair of lookup tables, and the index into those tables to find the offset
+ * for each PFN or PDX is obtained by shifting the to be translated address by
+ * a specific value calculated at boot:
+ *
+ * pdx = pfn - pfn_lookup_table[pfn >> pfn_shift]
+ * pfn = pdx + pdx_lookup_table[pdx >> pdx_shift]
+ *
+ * This compression requires the PFN ranges to contain a non-equal most
+ * significant part that's smaller than the lookup table size, so that a valid
+ * shift value can be found to differentiate between PFN regions.  The setup
+ * algorithm might merge otherwise separate PFN ranges to use the same lookup
+ * table entry.
  */
 
 extern unsigned long max_pdx;
@@ -157,7 +194,53 @@ static inline paddr_t directmapoff_to_maddr_xlate(unsigned long offset)
             (offset & ma_va_bottom_mask));
 }
 
-#endif /* CONFIG_PDX_MASK_COMPRESSION */
+#elif defined(CONFIG_PDX_OFFSET_COMPRESSION) /* CONFIG_PDX_MASK_COMPRESSION */
+
+#include 
+
+#define CONFIG_PDX_NR_LOOKUP (1UL << CONFIG_PDX_OFFSET_TLB_ORDER)
+#define PDX_TBL_MASK (CONFIG_PDX_NR_LOOKUP - 1)
+
+#define PFN_TBL_IDX_VALID(pfn) \
+    !(((pfn) >> pfn_index_shift) & ~PDX_TBL_MASK)
+
+#define PFN_TBL_IDX(pfn) \
+    (((pfn) >> pfn_index_shift) & PDX_TBL_MASK)
+#define PDX_TBL_IDX(pdx) \
+    (((pdx) >> pdx_index_shift) & PDX_TBL_MASK)
+#define MADDR_TBL_IDX(ma) \
+    (((ma) >> (pfn_index_shift + PAGE_SHIFT)) & PDX_TBL_MASK)
+#define DMAPOFF_TBL_IDX(off) \
+    (((off) >> (pdx_index_shift + PAGE_SHIFT)) & PDX_TBL_MASK)
+
+extern unsigned long pfn_pdx_lookup[];
+extern unsigned int pfn_index_shift;
+
+extern unsigned long pdx_pfn_lookup[];
+extern unsigned int pdx_index_shift;
+
+static inline unsigned long pfn_to_pdx_xlate(unsigned long pfn)
+{
+    return pfn - pfn_pdx_lookup[PFN_TBL_IDX(pfn)];
+}
+
+static inline unsigned long pdx_to_pfn_xlate(unsigned long pdx)
+{
+    return pdx + pdx_pfn_lookup[PDX_TBL_IDX(pdx)];
+}
+
+static inline unsigned long maddr_to_directmapoff_xlate(paddr_t ma)
+{
+    return ma - ((paddr_t)pfn_pdx_lookup[MADDR_TBL_IDX(ma)] << PAGE_SHIFT);
+}
+
+static inline paddr_t directmapoff_to_maddr_xlate(unsigned long offset)
+{
+    return offset + ((paddr_t)pdx_pfn_lookup[DMAPOFF_TBL_IDX(offset)] <<
+                     PAGE_SHIFT);
+}
+
+#endif /* CONFIG_PDX_OFFSET_COMPRESSION */
 
 /*
  * Allow each architecture to define it's (possibly optimized) versions of the
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 20 13:00:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 13:00:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020954.1397055 (Exim 4.92)
	(envelope-from )
	id 1uSbM2-0006vs-4H; Fri, 20 Jun 2025 13:00:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020954.1397055; Fri, 20 Jun 2025 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 1uSbM2-0006vl-1M; Fri, 20 Jun 2025 13:00:26 +0000
Received: by outflank-mailman (input) for mailman id 1020954;
 Fri, 20 Jun 2025 13:00: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 1uSbM0-0006vV-OQ
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 13:00:24 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on2062f.outbound.protection.outlook.com
 [2a01:111:f403:2408::62f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 84128779-4dd6-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 15:00:20 +0200 (CEST)
Received: from MN2PR16CA0043.namprd16.prod.outlook.com (2603:10b6:208:234::12)
 by CH2PR12MB9459.namprd12.prod.outlook.com (2603:10b6:610:27d::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Fri, 20 Jun
 2025 13:00:14 +0000
Received: from BL6PEPF0001AB54.namprd02.prod.outlook.com
 (2603:10b6:208:234:cafe::8c) by MN2PR16CA0043.outlook.office365.com
 (2603:10b6:208:234::12) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.29 via Frontend Transport; Fri,
 20 Jun 2025 13:00:14 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BL6PEPF0001AB54.mail.protection.outlook.com (10.167.241.6) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8857.21 via Frontend Transport; Fri, 20 Jun 2025 13:00:14 +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, 20 Jun
 2025 08:00:10 -0500
Received: from [172.17.97.97] (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 Jun 2025 08:00:09 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 84128779-4dd6-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ERRdO/D6ZDABXMC5oYonkjy12dulvRUNxsyH6JkpxgtipP7TzGpwNXDRy3XoDvS3L4k1p5fGsGTIfLHe0f9+dxNC2g0j7CEj/OMBjdbLOXGyTOvRCnf67sbaGRKpazR9uENcng8UElqERNP4ne2DO/30pniOCA7h9A1IVbOAOQ7Bz5lmi7mVKrIOW9xDLSo2g5R4KmwMZveyN5tiHrnmyA1j1qjLnvUg75OWmWJFHlCzOoH5a6T7odCf5OVMQqylw3ZD2L+Hbtgbyon3V1XmC+svgt+YfcF+tzbECF1XZIi5i4/z/MSVdWP8BBPa7zIEzHGa+DUhSqhDUPrZkR/j8Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=HFWo2kARnIabNYCUDf7d1lYOMUzhvQzbPZe1X1Ey7J4=;
 b=h/qgB9LlZZR0rKt2A8FZ5QfIxI/G5AT4xKWv0dV0B3JErWcS1G4Qq6mftxV6rvaqgqCj9Xe7knqpLlLNk09oZm9/CGXSo/UBVa+LKWE5SwI/KIHmKxK8QAG0763hNIdN+qbnkEPU2C1Vz65ag9beKY0HSoisoi62j2qc1c3GIUo4DvEsIIZwjLB3NQMdcaVKnAyuplTjdi5bRjksQMnaHPGWvPyNMzHbPSY76RbAcGg3uiizPd6mlHvBcww9CgHOKxjvA4wEvPB7XSdWXCeC/a3oq7P15IiOGgINsnIahTd49RFLWQ7wyNkZghQg0EqglIoXwvHa07lu9p3uhZlb+Q==
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=HFWo2kARnIabNYCUDf7d1lYOMUzhvQzbPZe1X1Ey7J4=;
 b=eyMpiV8HPirRImxzhxOERqQn606D4VvwPyusmnRXl5t2U8re5giJjIkFlIqIxc/nZmovbnfs0UIC0ahIOtoBZcjDvc32sohQqN7D/dvBqS/sDoA+h0ECONvD3Ta7SJ00Jy/VDQn8l2z8nrFLpNMWrrBePtoGynvbSoUpiauBylA=
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: <54316ade-83ad-4a34-8211-13b6947a1423@amd.com>
Date: Fri, 20 Jun 2025 09:00:17 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [MINI-OS PATCH v2 02/12] Mini-OS: add final kexec stage
To: Juergen Gross , ,
	
CC: 
References: <20250616084619.11112-1-jgross@suse.com>
 <20250616084619.11112-3-jgross@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <20250616084619.11112-3-jgross@suse.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: BL6PEPF0001AB54:EE_|CH2PR12MB9459:EE_
X-MS-Office365-Filtering-Correlation-Id: 2f16aa3d-3507-4601-588d-08ddaffa6623
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|36860700013|376014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?eEVKTlNtZTNGMjQ4Vk1wNEN1dXRQNTJyUlNZYXNyVnVrU3pZdHpQNjRFSGJX?=
 =?utf-8?B?RzVRNkU3Ly9Pek1qUkpTcGFaTkdkUnRKYk11eEdXRElJekp1ck40NE1KZEM5?=
 =?utf-8?B?UTdHbFVmNk5rNXV1SEFseVlSOVJrWEduNFlQR2VJL1JGN0ZzY3VFNHBCMGFp?=
 =?utf-8?B?M05DVnpBZm4zZVg2VTc2SGw3YzJtbUdHMWJrc0xaczFFazdpUHRvSXY5MFo5?=
 =?utf-8?B?eU5mSS92aDU0R0YvY1Q4NFlYVXZrRDJGZEJuRk5Od0U3M1pNZ0FmeFRkSkU3?=
 =?utf-8?B?b3FCd3B5V29nU2psajVXMW5oSlRwVFlrUHc1TDZkY3N3NGdnTGdUVjFWVk96?=
 =?utf-8?B?Ui9kR1c5MzZ6eFdVNVZFaDBpOXVhUXc2ekdEWUlKazJqTncvbzBqN3NpcTFp?=
 =?utf-8?B?YkdZbnBPZ25iMndCMGE3blEwa2pucUtNaDBPZW5YZ0hhbjdGRzNBWXA5UmU1?=
 =?utf-8?B?RENKTmVyZ3JCbit0S0JDbit4bjBldUJKMS8wWkZ4TUZiNE5tbTVwNit5RkI0?=
 =?utf-8?B?eElZN0JvaFVieVhOdFd2bnNLRVlUVjBBMm5qZlVWWGp2VGRiY3FWREw4OGdE?=
 =?utf-8?B?cnpzaGJJM3pMcEF0L0pkNzBnTGx3VDBhNk4wSHdnQmNFa01tc3gyZEdsNU9z?=
 =?utf-8?B?VGZjN21YM3NTY3VKbmQwa2ZFOWxCVklTWXJzNXBsVEROTlNhYXlDR3FxQVg0?=
 =?utf-8?B?bGJQQUp5WHRzamdvSXY5K3U0dnN4NDFUZUdYR1VQbDNidENITWJhR1FLMzlZ?=
 =?utf-8?B?QTVlQk1TZ3E3cHlpY1BuZEdpQ0lSRHRSb2FoV0hMelRtdmF5ekZQaUJiUDUv?=
 =?utf-8?B?ZkxIMGp4ZUQ3UFJROHo2bVNMcmJUTUlQckZCWXlaMEVkMGpsY3NraXMzckl0?=
 =?utf-8?B?dDZmYmlVK1JsWncxNjRUbHh3VHhNRTVtWDV4aWZlRFJMcGlzNjQ4OStZek81?=
 =?utf-8?B?d0RaZlAzb09EazRTVDFpdmVFUU8zSlYzeVJiV2J2VHVNWkd1L2Z4ZVJaWTZG?=
 =?utf-8?B?U3kxYTFab21RUVdhL05ONlFxZzgxa1VqSFBXeW1RZDNLR04rTlpEcHRpK0JP?=
 =?utf-8?B?ZTNQL2dkd0ZzOU5hTVRKdGNaZTBTZ3hqT0RYUlhkZXIxQnlnN2lUNUNwcXU4?=
 =?utf-8?B?OCs2aERiR2gxQVNFaE83YVdoSXdYS3FaSHM0c1FDVTBPYXNIZUxkL0l5aEd2?=
 =?utf-8?B?L21DUmowTG9yd0g5WmtyNWtZUXRRWlJta3M2QXRqOXpLRFJEOXUzczE3NDRm?=
 =?utf-8?B?SDZsWDJCU1ErcERHTVlUNTJicFg2cDB0QldaMkE3ZDRKUlE4cE5PZ1JnNUh5?=
 =?utf-8?B?OGRqRVJpb08zNjNhRmpEWDZpMUhKZVF4N3ByUmZ2bVpEV0Y1UEpaeEJad29Y?=
 =?utf-8?B?VnJZYjhTNmg1R3lvM0xZdCs5UW5KTFZWeisxUitHWmdpYVRhWjNSY0VheVNF?=
 =?utf-8?B?aFRVZGlyeFhpOXlEM3NJWEphK1pkOVcwRGYvZWNGaXNYelBFNWpwdWk0NkR6?=
 =?utf-8?B?L2EwZlNBNnBtcEpjZVBOWldhV0c2MWdGdldQcGNXWlVHa01tNGlaaHduV2U0?=
 =?utf-8?B?N1A3V2JTR0daVzRGUzlhUVhkSkoxaWtxSjhhS2pMVlBMdXJ6ZE90OTE3QXBa?=
 =?utf-8?B?ZUd2ZDFZSDJjdU5MZWdoYkEycGEwb3pLdE85NjhrZ1NRSm1tbmJXY3MwQU1y?=
 =?utf-8?B?SWp4eTlUWEJPTkk0N0VwVmtUS2VNMjhhWUZJYWxwNVBaQW1VNXNkSGlRajdM?=
 =?utf-8?B?djJ4SHVlcVFabDRuelVVaXlZZDBCWlZ3MjhKREpPZVh3QS82Q2hFRk8yNSsw?=
 =?utf-8?B?NWs4bWFuZzZ4Qkw0RlZlakIvRFEzTDdRSVNzL0REUWlVdWwrNk0zN2UxdVFC?=
 =?utf-8?B?ZXZzVFFpaStOeG01b1M2MnJlVTMyb0FUS0RGNXhnWWJEMTgxMGwvSWZlai9y?=
 =?utf-8?B?YnFuNWRjVlVvODdSeXJwTFJxdEFNWTEyS1VZYStZdll5SlVPSnhwS3kwRDNn?=
 =?utf-8?B?Y0tRbnZzYVJ6cHpIcE5TUWhQS1FtcVptUEVsVDF5M3JkVU41dWhtTWY1dFIw?=
 =?utf-8?Q?yt95UW?=
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)(82310400026)(36860700013)(376014)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jun 2025 13:00:14.6303
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 2f16aa3d-3507-4601-588d-08ddaffa6623
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:
	BL6PEPF0001AB54.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB9459

On 2025-06-16 04:46, Juergen Gross wrote:
> Add the code and data definitions of the final kexec stage.
> 
> Put the code and related data into a dedicated section in order to be
> able to copy it to another location. For this reason there must be no
> absolute relocations being used in the code or data.
> 
> Being functionally related, add a function for adding a final kexec
> action.
> 
> Signed-off-by: Juergen Gross 

Reviewed-by: Jason Andryuk 

Thanks,
Jason


From xen-devel-bounces@lists.xenproject.org Fri Jun 20 13:01:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 13:01:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1020960.1397071 (Exim 4.92)
	(envelope-from )
	id 1uSbN1-0007Rt-Iz; Fri, 20 Jun 2025 13:01:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1020960.1397071; Fri, 20 Jun 2025 13:01: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 1uSbN1-0007Rc-Dz; Fri, 20 Jun 2025 13:01:27 +0000
Received: by outflank-mailman (input) for mailman id 1020960;
 Fri, 20 Jun 2025 13:01: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 1uSbN0-0007Qw-Fo
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 13:01:26 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on2062a.outbound.protection.outlook.com
 [2a01:111:f403:200a::62a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id aa253e0c-4dd6-11f0-a30e-13f23c93f187;
 Fri, 20 Jun 2025 15:01:24 +0200 (CEST)
Received: from MN0P221CA0014.NAMP221.PROD.OUTLOOK.COM (2603:10b6:208:52a::34)
 by SA3PR12MB8440.namprd12.prod.outlook.com (2603:10b6:806:2f8::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.27; Fri, 20 Jun
 2025 13:01:18 +0000
Received: from BL6PEPF0001AB52.namprd02.prod.outlook.com
 (2603:10b6:208:52a:cafe::26) by MN0P221CA0014.outlook.office365.com
 (2603:10b6:208:52a::34) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8857.26 via Frontend Transport; Fri,
 20 Jun 2025 13:01:18 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BL6PEPF0001AB52.mail.protection.outlook.com (10.167.241.4) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8857.21 via Frontend Transport; Fri, 20 Jun 2025 13:01:18 +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 Jun
 2025 08:01:18 -0500
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 Jun
 2025 08:01:17 -0500
Received: from [172.17.97.97] (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 Jun 2025 08:01:17 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: aa253e0c-4dd6-11f0-a30e-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=W4Pmv9NTqGvBPZvgxRITC0B3WfJdjKrHRQeXJqSP9oZyuXjVqY/LX1xkXcOhb6OQOXDIMkY281gHCMWyETEKmnpfJOh4tv3HmufBOSRCY/Y6vvjhhbaJclvjfBl6KZ+X5sIrdK4+q9UkXXcAny6FaaVXmmSpXOl2A4Os4MjfK5XGOgmB+puG3+XlG7zZnLka76d8QP8xGN0nkm1aYGG421QWJzAeiybUOgxDezkGqT61fV7DZASKPSDcqR94NOlwzpDw9oL9PoUew5/oVJnIo9mUZfKfG28sVThoz9YXdog8NS6DIrJUvtPkcEFtrzPGWPhDfjGg3rhhhJbCtZpfiA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=2gYEWxgGIBDB1QfElst6qClQ/szbg3vVVoG0vci7qjI=;
 b=HlibnWt2sO7OGanUtXWvcq0fCICzrE8KfVaTdtzIBkzJyfXJ7VFJT8/AVwoyFiP3Kuz4jCDYfTFXTOecNtZpheJs5nKkkg/5mRq7h2q7CZz/QRTQC8eCHmXZSaYIHYkf5D8aQTRg6nJGVefVqdqaqgyJO51gWadVp83i1WFOJUlt+KnXstbxLeBKkoheIWIIVXhptbMp4MwJ4g5T9S5k2HP7hWGKUZqNH91mGc16dFiKY9B4iewBum3XHjgQp280zM3/h89Yx8X4HkRbJdE9mTvaiKz71d/GUIYXqPrinyl/oh2gcdM/EHYQBCRisD1y/adPynlaygk0BdwtgRIOSA==
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=2gYEWxgGIBDB1QfElst6qClQ/szbg3vVVoG0vci7qjI=;
 b=WTaxcYVmJBVz/C9vdqjY+d1bfGGkJoLUW3xaC8v9lyEeRqGgOpp8CjfJvgQWTUdz6bO6QqbKyr9SltBOz2mqwn/Yqy9jsN5SGFp01TWRd+zoigYDFkrDY8PTN2j8O/AgYBfffm1AJllASMqMF3jZ6s60u6IltCck1kv/Smlys1Q=
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: <3ff67738-5590-4dce-b2e5-6a627281062a@amd.com>
Date: Fri, 20 Jun 2025 09:01:26 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [MINI-OS PATCH v2 12/12] mini-os: kexec: do the final kexec step
To: Juergen Gross , ,
	
CC: 
References: <20250616084619.11112-1-jgross@suse.com>
 <20250616084619.11112-13-jgross@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <20250616084619.11112-13-jgross@suse.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL6PEPF0001AB52:EE_|SA3PR12MB8440:EE_
X-MS-Office365-Filtering-Correlation-Id: 9dca5c95-6085-4ea6-2423-08ddaffa8c36
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|82310400026|36860700013|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?T0Jndm5RdElseS9FR2xVQVp0VWRJNkRUZVU4czk3M1QySERRcWpickh2YTBQ?=
 =?utf-8?B?LytUSE1RbnQvMUtyZUZrYXRBWVZQd1VtTkFRMkNVS3dJTHNMYythUFRCdTd5?=
 =?utf-8?B?c1NxeGJpMkFMMzRXSUFPTTFhMGZTSmRWdjZ4OGJDTHpmcW1hSnVON3E5NUhZ?=
 =?utf-8?B?TjllazdoVVVtVWhGc2M4VmlUd3pCVThsUHNuallxSFBldGJVaFNKOWhwZTRR?=
 =?utf-8?B?a0RTdWhiNXlwa3UwcFNOSFF3SDBZcWhYL3c1UGIzK2dNR2ZodHI3M2VzOHVG?=
 =?utf-8?B?MmtnaG1MOGpIc0ljZDQ2SmZRaGhvYXEyWVNrenRhN3FSaEZVYkt0dHNuVCsz?=
 =?utf-8?B?TEJKNmF2YWVua2phSldFSkdzTHpOWXk5SUZhOW5UcEZ3ZkFYZlhnQ1lkMWd6?=
 =?utf-8?B?ZGpIL3I3MG9kTzBjV2tIZGJQSXcydnRHcDJpNUhCamM4UDloVktaWGRHQWhH?=
 =?utf-8?B?UGVlVFlFMTB1cm9GNVNJNnI2NytGVDBEOVYvZzFBb2ZLbDMvRStGbHhDcGRZ?=
 =?utf-8?B?akZGQy9XZjJ6dmFsbTFPZEZQKzdVN052aVg5Qk9hdmpjc0ptNXpqUmw2Wmhh?=
 =?utf-8?B?cDZXSjRQVy80MytVUkxwNmU2MTRLR2NFZExPQWxoNzZVR1p4K1VFUmdnczkw?=
 =?utf-8?B?OW8zbndQTWFlTGN0U2RwWXQwZG1iemlTNFVTckdLN3hYRlpINjFRUklMeG55?=
 =?utf-8?B?UzM5ZTdQdFBFeVNtVmtwemRVTzJCK3BtQ05pUUZ2KzlBUnB6UXowQXNTRGpM?=
 =?utf-8?B?SkVlYUxnNHZla2VwMzVlRVBjVXZ0SXZXM0t5cVdScWdIRXczU2EzK0RaM3p3?=
 =?utf-8?B?WGxrSldUR2NVWmdxUzRoVWt2QTNsc0padk82YU1CU1AyQXhVVXp0UmljejI4?=
 =?utf-8?B?RENUMVVLaXY1WXc1YzJJMVNIb2RWRjYraWVrVnlWVkZEWmxnTGpNY04rdUN0?=
 =?utf-8?B?MllXRFNNbnB1bEF3VzQ5NlBZbmJHT0MrcUZOeElsanhuQXFncE0yeHk4Zjhl?=
 =?utf-8?B?UThzc1l3VHZwd1d2ekpQSlFtT1dJb3ZNMEJlYTNHbmpoalMzNlZ1YnE1TUxy?=
 =?utf-8?B?Vm1OOUtEdzBvN3UyT0wzdzlmRUdyQ29jT1pEeGZueU9ZL1VuUEQ3QzhIb3I5?=
 =?utf-8?B?WThvTTNFaHBXMmNGdkprZUZDOUUveTlNaS9EWUNTZ3NoQ1o1Y1VLemI5dWZH?=
 =?utf-8?B?TVQreVRJSzVOREEzNlZTYVVjMXp6dk1HanJDWEZJdDZ0NmJ6aTB2ZDMzTnJz?=
 =?utf-8?B?dDBRLzNYeHNkNlZvdVpTTlFjNERZNHdBYXl2TUVIdWQ4MzZQck9Lc0t2d2lm?=
 =?utf-8?B?SFhxcjVNdy9ybVZzRDMrYUIwWGNaYTF1WHRVMEpXS1RZUnVoczVEYXJwTGhF?=
 =?utf-8?B?WUxpeTd2SEI3M3JNVEZ1dk05L3d6YXBOQ0VqWUpJbmora3I4SmpLQnNDOGJn?=
 =?utf-8?B?dFBkeUp4VWxkN3FwcXFDRnJaQi9rTDRWYkVmcHJZYndRdGY4RWh5U00vbFg2?=
 =?utf-8?B?dnNxSXpsbzlHSDhGNjMwazBHdFlBMlZIL0FWVUhNRjJqc2tIeWJKRkM4Qmwr?=
 =?utf-8?B?RmgyMGF1aWl2M1BRSzJMMUhXQWlWVDY4V09mbmNUckdQV0Z0bGVwMUxsUm9Y?=
 =?utf-8?B?MFp3REg1WWMxcTQ2YnJONFBHV3I2eHNmM0dyeTBFcmY2TXhyRXVDOWc5QnRh?=
 =?utf-8?B?dlRDNGFhbGg2S1BhWWJvWVJXWkcwVHZiR3JFRmJnVzMzOWY3dTFCNmJrVW03?=
 =?utf-8?B?Vzl2V211TlQ5S3ovRmFQa1UrZlZSYnlGbE94ejZZZk43QXphaGFxTzlCUWg5?=
 =?utf-8?B?dFlQV1FoTmlQTitsTjdtb3pST1lNMkpya0VBQkJPc3N2SU5ncFl5b2hkRmdY?=
 =?utf-8?B?b0NYNStIeC9Sb2tSdVAzdnpZK0diZUxwb0EybnJNY0lwN1U2T2l3aEVjSW9i?=
 =?utf-8?B?ajhYelY4dWZKdXQ0S040VnZiMmJaTnNGQzQyR280S2xWRUhROVlMVisxeGU3?=
 =?utf-8?B?a0NUTTc4c3BUbU16S0xuODdzZkM0eGMyUlg1UzBpaXZHTzJMcmpIQUk2ZEpr?=
 =?utf-8?Q?w8xrts?=
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)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jun 2025 13:01:18.5065
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9dca5c95-6085-4ea6-2423-08ddaffa8c36
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:
	BL6PEPF0001AB52.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR12MB8440

On 2025-06-16 04:46, Juergen Gross wrote:
> With all kexec preparations done, activate the new kernel.
> 
> Signed-off-by: Juergen Gross 

Reviewed-by: Jason Andryuk 

Thanks,
Jason


From xen-devel-bounces@lists.xenproject.org Fri Jun 20 16:12:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 16:12:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021012.1397083 (Exim 4.92)
	(envelope-from )
	id 1uSeLj-0004x9-GV; Fri, 20 Jun 2025 16:12:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021012.1397083; Fri, 20 Jun 2025 16:12: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 1uSeLj-0004x2-Da; Fri, 20 Jun 2025 16:12:19 +0000
Received: by outflank-mailman (input) for mailman id 1021012;
 Fri, 20 Jun 2025 16:12: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 1uSeLi-0004wu-Cg
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 16:12:18 +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 52db65da-4df1-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 18:12:12 +0200 (CEST)
Received: by mail-oa1-x34.google.com with SMTP id
 586e51a60fabf-2ea08399ec8so1309305fac.1
 for ; Fri, 20 Jun 2025 09:12:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 52db65da-4df1-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750435931; x=1751040731; 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=uQnYi48SbPgTUZy1iwUnuMTnzmPhOqN6A19iIBg6Tp8=;
        b=s68oPtnYfnT+3Y1dxvPPTHKMhd/VMuED0D8jKZ8tKX3x3+Hb1ld2/xer7myr2S8qZS
         IEu2dxTetsem0deXqcE9pCipwTQY9kNab9II4T4cOgeY0xChRz5jDRhVji8/OZaP0mKQ
         2xFcsBtp1GVe2KZ5vHfxcuos/0e3A+taMBslU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750435931; x=1751040731;
        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=uQnYi48SbPgTUZy1iwUnuMTnzmPhOqN6A19iIBg6Tp8=;
        b=cTxieLJ0gRhBfOvFALtnWPdI6TT5ljK2UHmXKgfRcSlGTDOQXo8dQHXhE0UAfQAVUd
         ZPdNfZTJMVLSPKvNQkT6fN6pKVysCqAXakRPjytHHIkD2oSYtfzB0mnwMV+Sfnksp47k
         qihuwekEvxSu1wGON3qXJk40aqgCUqFIwCT5WPgERWfvMH20RhCDY0paZYSUZqMQMRTy
         aGBtHdjbkQwjjrWK3as/cKrZ9qh3TQ9d195AqLhpKfGpdS/ZitnY9lcxeVY7amA3zf/e
         1Soq5kXroHw6OjrAoBmrk+nfdthFRI3lftZ+Fxrq9n3ox12RK99W0iWMe/hOhxZRfGJz
         fbfg==
X-Gm-Message-State: AOJu0YxRy8dMmGQ0Pkz26Q5jDfWjI4Q/KPkVSVystIThjyaMYERYyQVY
	v+UexhC+BqHvTRfj4XS0wwfxI69dibg1R6Ak4ldMv7nwng9p/IXKAlD+Me/vudXILn2uWFlqQ7K
	KaFdO9uItel+7oiOqr3tPZLu7JVa1NbEnsTuuvs4Z
X-Gm-Gg: ASbGnctg9Pp2PlXoTIDgYxyTo2/I0fdN4MjwcgEIzV9O7NSqC0sc9Ekp476Ht0/0JrF
	ohIHl8Z4G7CyhFKxMu6LhWF0qJbAUI3XNCSuBIDwtZj231G68ZFxvG9qBbF2XcdAuoMabOH/zN5
	pw0rPRhhZ9sVlNakwjHxvEIX664vCER9BsuRySG+oQQA==
X-Google-Smtp-Source: AGHT+IG98u6JftdOQce9nuZLXviIxdbEoYNaWMmlttdvwQmyqCf0IZVD06mokX22Vw+3yE7LtqGfQSAYFPdes/5d6xU=
X-Received: by 2002:a05:6870:238c:b0:2c2:dfbb:2dbd with SMTP id
 586e51a60fabf-2eeda55fb5emr2291770fac.8.1750435931456; Fri, 20 Jun 2025
 09:12:11 -0700 (PDT)
MIME-Version: 1.0
References: <20250602133639.2871212-1-ross.lagerwall@citrix.com>
 <20250602133639.2871212-4-ross.lagerwall@citrix.com> 
In-Reply-To: 
From: Ross Lagerwall 
Date: Fri, 20 Jun 2025 17:11:59 +0100
X-Gm-Features: Ac12FXw-5omNZZwA0W9s4TLR80CH9YMIvJbtYQ57aZZ0NW-sv-u_S7lE2w04plo
Message-ID: 
Subject: Re: [PATCH v3 3/5] crypto: Add RSA support
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: xen-devel@lists.xenproject.org, Andrew Cooper , 
	Anthony PERARD , Michal Orzel , 
	Jan Beulich , Julien Grall , 
	Stefano Stabellini 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 20, 2025 at 10:53=E2=80=AFAM Roger Pau Monn=C3=A9  wrote:
>
> On Mon, Jun 02, 2025 at 02:36:35PM +0100, Ross Lagerwall wrote:
> > In preparation for adding support for livepatch signing, add support fo=
r
> > RSA crypto.
> >
> > The RSA code is extracted from Nettle at tag nettle_3.2_release_2016012=
8
> > (https://git.lysator.liu.se/nettle/nettle).
> >
> > The MPI code is extracted from Linux at commit eef0df6a5953 (lib/mpi/*)=
.
> >
> > Signed-off-by: Ross Lagerwall 
> > ---
> >
> > In v3:
> >
> > * Move mpi.c to lib
> > * Fix header guard name
> >
> >  xen/crypto/Makefile   |    1 +
> >  xen/crypto/rsa.c      |  196 +++++
> >  xen/include/xen/mpi.h |   68 ++
> >  xen/include/xen/rsa.h |   74 ++
> >  xen/lib/Makefile      |    1 +
> >  xen/lib/mpi.c         | 1729 +++++++++++++++++++++++++++++++++++++++++
>
> Just FTAOD: all the functions imported in mpi.c are used I think?  So
> that we don't introduce unreachable code.
>

Yes, everything included here is used by the end of the patch series.

Ross


From xen-devel-bounces@lists.xenproject.org Fri Jun 20 16:50:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 16:50:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021049.1397093 (Exim 4.92)
	(envelope-from )
	id 1uSewW-0001Vl-98; Fri, 20 Jun 2025 16:50:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021049.1397093; Fri, 20 Jun 2025 16:50: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 1uSewW-0001Ve-6O; Fri, 20 Jun 2025 16:50:20 +0000
Received: by outflank-mailman (input) for mailman id 1021049;
 Fri, 20 Jun 2025 16: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 1uSewU-0001VY-Qe
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 16:50:18 +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 a4ac5cca-4df6-11f0-a30e-13f23c93f187;
 Fri, 20 Jun 2025 18:50:17 +0200 (CEST)
Received: by mail-ot1-x32c.google.com with SMTP id
 46e09a7af769-735a9e65471so1352018a34.1
 for ; Fri, 20 Jun 2025 09:50:17 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a4ac5cca-4df6-11f0-a30e-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750438216; x=1751043016; 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=5HEQFGKNlvnV0WWWe+o2xBNWZHoaIv+2Wj2ukolubR4=;
        b=BT5wDAqO/uuxuRd7/4AwEE24YhevFg2J9kbfjRAFWNkoIaQAFNgB8jvaoNcyanzGqA
         aUZqA/PBtJoo91eJ2oMKeWB5c0C64K0rxfHHgcI8+BwFtOBRvXZ0YWvacceGKZhYfhgI
         cGFjrWNDn0rczB6muJmxlR2RvOk4WlIuFZdUQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750438216; x=1751043016;
        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=5HEQFGKNlvnV0WWWe+o2xBNWZHoaIv+2Wj2ukolubR4=;
        b=dCkvZ77BjAqalGeQ04W96uX0Xeim5x0VyhZqqf/Enz3OR1VcWXVoPhlVyR8g2oB+q2
         yYiKWPnMtwFfBzQae8yZ1DC+rLHHLElIHhfS0oC/X9hS99D+ndTXn/meCd/w7Qqd1b9K
         12Q9svYRx3HHU1a8JhT52X+kY82DdP0NE2YTjSFbu6MXStUDQSpvSp5F4d551hNvy261
         pCI8pNfgp6vaQk+QjeYDgVJOxGG5IrYLNPsFz2g8RgeRHE+Ahe6ZJnztRYocqWSdEaBF
         twFHWdo56b5nf6jfUfLuQoVcQgT/RR9uu99ub5Dxi1D3e/elB4RnDfYWfA75Eiif5PZ4
         Uq5Q==
X-Gm-Message-State: AOJu0YzbVBtPFuaPdvCJV/ek0hNqmaUlE0s8TZpFtABSUxgk8WNLAxv2
	ANW9KeB/MY5J/aThy/wcImMJHDuTnyz/QKo+YwUlSCbNneUU9wbw/u/s0da++cRmrhwdzUbTcgN
	aoAi9aCcp06O1xfOnO47xpP3GDj6GE19AKsgwvpZN
X-Gm-Gg: ASbGncu2TDknQ+yC0ZCM7UBEwXuzkW6USn1WVBA0YZZUGXqs5L9wYoQW4joUBuD9TeI
	PaN3TN3y8rFYx8r8T8JmyJ35NILTdsgR77Wt/yEV1DNZHbhv5VWl0mhgH3TVbRBxXp2AO04ad21
	2iWt/EIwuIvQ5LPxX+uIQDgxyOoYx956oj2thqWxAiwQ==
X-Google-Smtp-Source: AGHT+IErRfGjIiVPjVRJ4pLvOCxkMsfFKO8Qu1Gz1bCsphQVU47jSbcqm04sk7ACue/CLY7vpT9SPZu+l0MKlJSsPJI=
X-Received: by 2002:a05:6871:2109:b0:2bc:6933:4a9f with SMTP id
 586e51a60fabf-2eeee4dab69mr2416712fac.25.1750438216132; Fri, 20 Jun 2025
 09:50:16 -0700 (PDT)
MIME-Version: 1.0
References: <20250602133639.2871212-1-ross.lagerwall@citrix.com>
 <20250602133639.2871212-6-ross.lagerwall@citrix.com> 
In-Reply-To: 
From: Ross Lagerwall 
Date: Fri, 20 Jun 2025 17:50:03 +0100
X-Gm-Features: Ac12FXzoMzHZeEJY_80h4ToJuAOXkENN-PTXRc7FOsZs2OIWW-M-QnGPuhnOqDQ
Message-ID: 
Subject: Re: [PATCH v3 5/5] livepatch: Verify livepatch signatures
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 20, 2025 at 11:31=E2=80=AFAM Roger Pau Monn=C3=A9  wrote:
>
> On Mon, Jun 02, 2025 at 02:36:37PM +0100, Ross Lagerwall wrote:
> > From: Jennifer Herbert 
> >
> > Verify livepatch signatures against the embedded public key in Xen.
> > Failing to verify does not prevent the livepatch from being loaded.
> > In future, this will be changed for certain cases (e.g. when Secure Boo=
t
> > is enabled).
> >
> > Signed-off-by: Jennifer Herbert 
> > Signed-off-by: Ross Lagerwall 
> > ---
> >
> > In v3:
> >
> > * Minor style fixes
> >
> >  xen/common/livepatch.c          | 103 ++++++++++++++++++++++++++++++++
> >  xen/common/livepatch_elf.c      |  55 +++++++++++++++++
> >  xen/include/xen/livepatch.h     |  10 ++++
> >  xen/include/xen/livepatch_elf.h |  18 ++++++
> >  4 files changed, 186 insertions(+)
> >
> > diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
> > index 92d1d342d872..56a3d125483f 100644
> > --- a/xen/common/livepatch.c
> > +++ b/xen/common/livepatch.c
> > @@ -14,6 +14,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -525,6 +526,106 @@ static int check_xen_buildid(const struct livepat=
ch_elf *elf)
> >      return 0;
> >  }
> >
> > +#ifdef CONFIG_PAYLOAD_VERIFY
> > +static int check_rsa_sha256_signature(void *data, size_t datalen,
> > +                                      void *sig, uint32_t siglen)
>
> I think both data and sig could be const here?
>
> > +{
> > +    struct sha2_256_state hash;
> > +    MPI s;
> > +    int rc;
> > +
> > +    s =3D mpi_read_raw_data(sig, siglen);
> > +    if ( !s )
> > +    {
> > +        printk(XENLOG_ERR LIVEPATCH "Failed to mpi_read_raw_data\n");
> > +        return -ENOMEM;
> > +    }
> > +
> > +    sha2_256_init(&hash);
> > +    sha2_256_update(&hash, data, datalen);
> > +
> > +    rc =3D rsa_sha256_verify(&builtin_payload_key, &hash, s);
> > +    if ( rc )
> > +        printk(XENLOG_ERR LIVEPATCH "rsa_sha256_verify failed: %d\n", =
rc);
> > +
> > +    mpi_free(s);
> > +
> > +    return rc;
> > +}
> > +#endif
> > +
> > +static int check_signature(const struct livepatch_elf *elf, void *raw,
> > +                           size_t size)
> > +{
> > +#ifdef CONFIG_PAYLOAD_VERIFY
> > +#define MAX_SIG_NOTE_SIZE 1024
> > +    static const char notename[] =3D "Xen";
> > +    void *sig;
> > +    livepatch_elf_note note;
> > +    int rc;
> > +
> > +    rc =3D livepatch_elf_note_by_names(elf, ELF_XEN_SIGNATURE, notenam=
e, -1,
> > +                                     ¬e);
> > +    if ( rc )
> > +    {
> > +        dprintk(XENLOG_DEBUG, LIVEPATCH "%s: Signature not present\n",
> > +                elf->name);
> > +        return rc;
> > +    }
> > +
> > +    /* We expect only one signature, find a second is an error! */
> > +    rc =3D livepatch_elf_next_note_by_name(notename, -1, ¬e);
> > +    if ( rc !=3D -ENOENT )
> > +    {
> > +        if ( rc )
> > +        {
> > +            printk(XENLOG_ERR LIVEPATCH
> > +                   "Error while checking for notes! err =3D %d\n", rc)=
;
> > +            return rc;
> > +        }
> > +        else
> > +        {
> > +            printk(XENLOG_ERR LIVEPATCH
> > +                   "Error, found second signature note! There can be o=
nly one!\n");
>
> FWIW, it's a nit, but I think there are too many exclamation marks in
> the error message above:
>
> "Error, multiple signatures found\n"
>
> Would be better.
>
> I'm also wondering, would it make sense to allow multiple signatures
> to be present?  I guess not because livepatches are built for specific
> Xen binaries, and then we know exactly which key is embedded there.  A
> livepatch would never apply to two different builds with different
> keys.

I agree that while it could be possible, I don't really see a valid use
for it.  This restriction could be relaxed in future if it is deemed
useful.

>
> > +            return -EINVAL;
> > +        }
> > +    }
> > +
> > +    if ( SIGNATURE_VERSION(note.type) !=3D LIVEPATCH_SIGNATURE_VERSION=
 ||
> > +         SIGNATURE_ALGORITHM(note.type) !=3D SIGNATURE_ALGORITHM_RSA |=
|
> > +         SIGNATURE_HASH(note.type) !=3D SIGNATURE_HASH_SHA256 )
> > +    {
> > +        printk(XENLOG_ERR LIVEPATCH
> > +               "Unsupported signature type: v:%u, a:%u, h:%u\n",
> > +               SIGNATURE_VERSION(note.type), SIGNATURE_ALGORITHM(note.=
type),
> > +               SIGNATURE_HASH(note.type));
> > +        return -EINVAL;
> > +    }
> > +
> > +    if ( note.size =3D=3D 0 || note.size >=3D MAX_SIG_NOTE_SIZE )
> > +    {
> > +        printk(XENLOG_ERR LIVEPATCH "Invalid signature note size: %u\n=
",
> > +               note.size);
> > +        return -EINVAL;
> > +    }
> > +
> > +    sig =3D xmalloc_bytes(note.size);
> > +    if ( !sig )
> > +        return -ENOMEM;
> > +
> > +    memcpy(sig, note.data, note.size);
> > +
> > +    /* Remove signature from data, as can't be verified with it. */
> > +    memset((void *)note.data, 0, note.size);
> > +    rc =3D check_rsa_sha256_signature(raw, size, sig, note.size);
> > +
> > +    xfree(sig);
> > +    return rc;
> > +#else
> > +    return -EINVAL;
>
> EOPNOTSUPP would be more accurate here.
>
> > +#endif
> > +}
> > +
> >  static int check_special_sections(const struct livepatch_elf *elf)
> >  {
> >      unsigned int i;
> > @@ -1162,6 +1263,8 @@ static int load_payload_data(struct payload *payl=
oad, void *raw, size_t len)
> >      if ( rc )
> >         goto out;
> >
> > +    check_signature(&elf, raw, len);
>
> Wouldn't it make more sense to unconditionally fail here if
> CONFIG_PAYLOAD_VERIFY is enabled and signature verification fails?
>
> IOW: if you built an hypervisor with PAYLOAD_VERIFY enabled signature
> verification needs to be enforced.

As per the commit message, this doesn't actually enforce anything yet.
The intention is to tie signature enforcement to lockdown mode once
those patches have been merged.

Ross


From xen-devel-bounces@lists.xenproject.org Fri Jun 20 17:00:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 17:00:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021060.1397102 (Exim 4.92)
	(envelope-from )
	id 1uSf6T-0003Gi-67; Fri, 20 Jun 2025 17:00:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021060.1397102; Fri, 20 Jun 2025 17:00:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSf6T-0003Gb-3a; Fri, 20 Jun 2025 17:00:37 +0000
Received: by outflank-mailman (input) for mailman id 1021060;
 Fri, 20 Jun 2025 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 1uSf6S-0003GV-65
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 17:00:36 +0000
Received: from mail-oo1-xc36.google.com (mail-oo1-xc36.google.com
 [2607:f8b0:4864:20::c36])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 147fd478-4df8-11f0-a30e-13f23c93f187;
 Fri, 20 Jun 2025 19:00:34 +0200 (CEST)
Received: by mail-oo1-xc36.google.com with SMTP id
 006d021491bc7-6113f0cafb2so1101460eaf.1
 for ; Fri, 20 Jun 2025 10:00:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 147fd478-4df8-11f0-a30e-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750438833; x=1751043633; 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=vmA8q2HSTt0O1pZWJDOkj+lG0+NdHR/1w4qwRJYIHUQ=;
        b=Uc+P+YC38E1ZY1wuRxxaswHJh1TiYHpO7dSYg2Pb9vMMbpBDZZv/D71SBbvy8nV3yv
         U3eBebjRICB5QPPtvGeiI2mq6j2kHwKhuQG4QvTButSJH5lbGfTHyD7vEQ1drbVaI0pO
         k7apRcFkU5TIB96jfgnikHHvTVtsRCa8vihRc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750438833; x=1751043633;
        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=vmA8q2HSTt0O1pZWJDOkj+lG0+NdHR/1w4qwRJYIHUQ=;
        b=eC1g1FFmrU2rpHg/FMUcRcNUiASJ2szX7A31UequXQbxdpdd4m/nl9R8vc6l8D/7Ic
         aRRIqdobC11SKxfopvoM6gh6iy6eBqOJvCBwB37weT1AEz3YCNZWvFvmREdKuLFTTNFz
         6J5Djd1uLLkgx10aiYGQk4nbyMLl0Mk2+iSBvpKwaYHBcYxfARoFMPxCR0hjQukcVEAZ
         qa3K7Mt0zHvXQ0cg85suEb5CuimSzTN738kSi8eMeT/nR7sWNb4/Ksq1voAct3dNzis/
         p4sNZVvV1VawqiaZnzMP85SUYsTk35iauKRe/QIiyuF2lVSzEwZcIAdcxoWSLXRdsQ3r
         ew1g==
X-Forwarded-Encrypted: i=1; AJvYcCWYH8HzGZAQBowTxjgc4vCjh9Ij14BLxImeCO0V1QZwH6svreNCB08ANuXew2KsFlZWAwYtnNcDIb0=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw3e93KKU0nt3qzipAY+BeFkWMg0uJxczpVye7gqKA66/lIxwdA
	GLeCDy/pa22y80YA/SE9On/LrA7IrkFxi89WPVrLLyZMdztKVf5Y1mLBY8OsW+eZSfvj6WUpSH6
	i7AJzgLyNUo0XxoTazJEls7q7CCrqp/mW8WHy9LJe
X-Gm-Gg: ASbGnctdkx4CVjbAAgNwrBl92GTqGy22isJ4lVcZDl/riZRGBhQZYTFSJq8WJpbITNZ
	d0CI6eyW16cKiT/pkIw6jT8fSTiPrZmWJHOpjLb14xE7cmKw8oI4+hcZ0KWuaKveTjprNjHHjFd
	NomudH3bUEbB6yfpGADAo01dxp4dfOXD4MtpNoZopmjQ==
X-Google-Smtp-Source: AGHT+IEUtPl9HKw8cqKp9NBPRb+KHV77FeuCB3lS+kWOTzRbJxvrragzeaMkakBpfTdQgKnLGHF7K/NZwiWY1t0dc+k=
X-Received: by 2002:a05:6820:308a:b0:610:ee96:eca9 with SMTP id
 006d021491bc7-6115ba821c9mr2188417eaf.8.1750438833374; Fri, 20 Jun 2025
 10:00:33 -0700 (PDT)
MIME-Version: 1.0
References: <20250611235851.167385-1-andrew.cooper3@citrix.com>
 
  
 
In-Reply-To: 
From: Ross Lagerwall 
Date: Fri, 20 Jun 2025 18:00:21 +0100
X-Gm-Features: Ac12FXy4r9uMRa5jx6SQcWkIJwgDTm6ay4jALFTLfx_wKwLlWtCaddOICDUUvs8
Message-ID: 
Subject: Re: [PATCH] docs: UEFI Secure Boot security policy
To: =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= 
Cc: Stefano Stabellini , Andrew Cooper , 
	Xen-devel , Anthony PERARD , 
	Michal Orzel , Jan Beulich , Julien Grall , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , security@xen.org, 
	Juergen Gross , Trammell Hudson , 
	Frediano Ziglio , Gerald Elder-Vass , 
	Kevin Lampis 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 19, 2025 at 11:06=E2=80=AFPM Marek Marczykowski-G=C3=B3recki
 wrote:
>
> On Thu, Jun 19, 2025 at 12:56:12PM -0700, Stefano Stabellini wrote:
> > On Thu, 19 Jun 2025, Marek Marczykowski-G=C3=B3recki wrote:
> > > On Thu, Jun 19, 2025 at 03:16:51PM +0100, Ross Lagerwall wrote:
> > > > I think a section on PCI passthrough is also warranted. i.e. preven=
ting misuse
> > > > of a device to exploit Secure Boot.
> > >
> > > While I agree it makes sense, I wonder if it's in scope for UEFI
> > > Secure Boot as defined by Microsoft? It may have implication for exam=
ple
> > > on PCI passthrough to a PV domains.
> >
> > If we bring DomUs into the discussion, then I think we need to make a
> > distinction between predefined DomUs, which could have signatures
> > verified by Secure Boot (such as Dom0 and hyperlaunch/dom0less guests),
> > and other dynamically created DomUs which could be fetched from the
> > network and potentially started without signature verification or prior
> > knowledge.
>
> I think it's mostly not about what's running inside domU, but what such
> domU has access to. The obvious part is enforcing IOMMU configuration so
> that domU cannot use a PCI device as a proxy to modify hypervisor (or
> dom0) code. But there may be more subtleties like access to specific
> devices (HECI? SPI?).
> Anyway, lets figure out first _if_ we need to do something about this
> topic, and only then worry how.
>

As far as I know, Microsoft haven't specified requirements to this level
of detail. However, if userspace can break the Secure Boot principles
laid out above using a (spec compliant) PCI device to write memory, then
I don't see why it would be any different to a Secure Boot compromise
using the CPU to write memory. Linux prevents direct access to PCI
devices when lockdown mode is enabled, presumably to prevent these kinds
of attacks.

Ross


From xen-devel-bounces@lists.xenproject.org Fri Jun 20 18:29:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 18:29:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021075.1397112 (Exim 4.92)
	(envelope-from )
	id 1uSgUn-00057Q-CQ; Fri, 20 Jun 2025 18:29:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021075.1397112; Fri, 20 Jun 2025 18:29:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSgUn-00057J-9i; Fri, 20 Jun 2025 18:29:49 +0000
Received: by outflank-mailman (input) for mailman id 1021075;
 Fri, 20 Jun 2025 18:29:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uSgUl-000575-EI
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 18:29:47 +0000
Received: from NAM04-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam04on20601.outbound.protection.outlook.com
 [2a01:111:f403:2409::601])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 889ce7d7-4e04-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 20:29:44 +0200 (CEST)
Received: from BN9P220CA0005.NAMP220.PROD.OUTLOOK.COM (2603:10b6:408:13e::10)
 by PH0PR12MB5646.namprd12.prod.outlook.com (2603:10b6:510:143::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Fri, 20 Jun
 2025 18:29:38 +0000
Received: from BN1PEPF00006000.namprd05.prod.outlook.com
 (2603:10b6:408:13e:cafe::e6) by BN9P220CA0005.outlook.office365.com
 (2603:10b6:408:13e::10) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8857.25 via Frontend Transport; Fri,
 20 Jun 2025 18:29:38 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN1PEPF00006000.mail.protection.outlook.com (10.167.243.232) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8857.21 via Frontend Transport; Fri, 20 Jun 2025 18:29:37 +0000
Received: from xcbagarciav01.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; Fri, 20 Jun
 2025 13:29:23 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 889ce7d7-4e04-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=C0vbTfTdG1V4X2kTObTb3NviD60N1QMlGsAMybLkT0eS80GUvQ5jEuv/qREV9vUn1EIqyGQC09oZhsuuqxmxaCcaGMHThgGncbOEcaDWIsUnzp5iTtTq8Ds+rIZJ7VlIFxsUsECD/pwn14ELOBMZCVrIfeYe3cP/gGEFmAeMfio4tl4ybIQhwe9tmQiYL4JGJXzYrcqVp1ITg+IDyC+Lq/5xj79ruFE//pA0oOHVZvjrWkTnWeAAYOVfnAmbjYkziK5m4vQ+TfRZjUFXPubFKsf3H+NN0nAhdHn+q2qjtoJcMkBxDxAiBs9XeYpW1GVAqSJCA4mSRDs1mG8WGCmaHQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=/WCPtX5aykBfff8wM+NoZNcSXbB+qXgxtxCOTOC2Unc=;
 b=ExzzLoncj5k1/Vg1iUdfNFo0YE/XaZtdubDdtAwhYfo1B2Mp2gTGcV1QlSjlqe41tSlgtNiRB5RIMYHSADrOScjXk0TpKOeQPplooXgD9oTeFOWCQZL1sf/RUPd1BXjh7nskJl+UagTYf22ompnog2Y7r3y6JdiaFM+d/oLt6hKGX+Fp/0T1DastR3+6oZYa44Li7Dzkf/iFBi+UICurL98Zbd7T5uCaFMtXSggY0NyNf1DwLmulN5JLX3wP4TGMmZ3c+sA658zbWYIZUNJYIFwzZXEjXTKzpXsTQP5luIqPadP8fifBOUAng0BTwHBr7xsnmx/PKtBCBh3ZEcXe8A==
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=/WCPtX5aykBfff8wM+NoZNcSXbB+qXgxtxCOTOC2Unc=;
 b=ZKbjkOkKewZcn0wFR2FQ6QDm6vn0JUoOEaMyH1FN82GHJY83s6uBMjpD19xLnltihehzXdZf6YwnuxLaaGcqbSDS0zrbFkzc0VfmI/LKyrBSi+QmuBGFAYZ9KGxKpxY4bbnARAUiJFSjy9UoX6q0qEnRMikQoudrofNUpuxSiQQ=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , "Julien
 Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Stefano Stabellini ,
	"Bertrand Marquis" , Volodymyr Babchuk
	, "Daniel P. Smith"
	, Alistair Francis ,
	Bob Eshleman , Connor Davis ,
	Oleksii Kurochko , Dario Faggioli
	, Juergen Gross , George Dunlap
	, Shawn Anastasio ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
	
Subject: [PATCH v4 00/12] Allow x86 to unflatten DTs
Date: Fri, 20 Jun 2025 20:28:46 +0200
Message-ID: <20250620182859.23378-1-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: 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: BN1PEPF00006000:EE_|PH0PR12MB5646:EE_
X-MS-Office365-Filtering-Correlation-Id: 6092b0f7-811d-414f-9479-08ddb02869bb
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?yFQiATZUSysdwC+udDoQCA0o7gOyuiTgMhoIcWCKZwADYE92Cygh/b45sCF3?=
 =?us-ascii?Q?4U4136u7Z6ly+b3RqNTufyKAkV0GSuZcpFw70iljUMklXGIlD9yDfYrRUZbi?=
 =?us-ascii?Q?9iunA6M/iU6mYSTce3wF5//TDuglV7IRkLrHU6qulyZcIsClY4AXnEKzt97J?=
 =?us-ascii?Q?bCamCp1Y4Z+RltktCpk0o+EvjBar9DefgiC/uWvJI9f4UKjcs60aDw20ougY?=
 =?us-ascii?Q?UD2tpnGWFbUbfyYDzAN1Ra4Rp54HcNeE/YdKYlgvf8z3s4t7DXLGEkB9FV02?=
 =?us-ascii?Q?5q2GeYjDSLhe/qlF2tFOMNWh84Sc/pBon8WRLAwbd1Y2Xw7e9O7OWYEziqCN?=
 =?us-ascii?Q?TCa/FYWp17dvbSDbeK1u+UPe7k44QzDShb8Mgsgo/T1tQl9ew7xffCi2a1gb?=
 =?us-ascii?Q?BCMQC2gZoeU/gMSMlqLWoKH4GivXDKphGZGlj3uTxcB3HzVTPpO2TOh7uIFi?=
 =?us-ascii?Q?YtODp7n8xGc2TVEihzTz6kx76nETAYN8zm0l1fAyu43kdQQSXEqpvXvliqj7?=
 =?us-ascii?Q?zAHW2dQW20EnNTapinvc3sP/ZN/FAySVxvxFuLqUrZEgHV3GBKLEaPE+mVgF?=
 =?us-ascii?Q?Iun6o9Yp8l8Qqgl596J/SUNzqxg6r6FuoGYRGXPVd3n4+hiZQBJALy17GkRv?=
 =?us-ascii?Q?smT2ptcdwIjwAzDTgKMYDBTEkIoipt2b/JdLukLVKVgiQqKRf9VQ8EXGjNca?=
 =?us-ascii?Q?j0tKd6BD7aD5Z6sGwOgiZxf2riYmWEmDPcEWmHISMSro3Qe6cONKGjJj+27w?=
 =?us-ascii?Q?g3YJYNEH6GWBf79DILBMj6W5sXLO/Llbreg9L6Gm8yeuzPnVd0QJJC1uIHvX?=
 =?us-ascii?Q?mxQ/C18Epk4j5HXff5PPYLmfltvsriFmhu+t0gnllyxUvXOSext7xWLaWomo?=
 =?us-ascii?Q?qU2+ELfhrxZpFr6HCAApExEy6qfLd7NmBCeU/w019vy2NXfNYLCD938A9HSn?=
 =?us-ascii?Q?KCSYc53ongKuSyM2zAqHerVAkl4VJ1R8OmJgEnXr9mObLgPaxjaYEBn1awDZ?=
 =?us-ascii?Q?rKzTYj+GylMgZIfS6Jy7TVPiTVDPbz+YhjP0QqfF37UepbVXmY1CE+RtC7sB?=
 =?us-ascii?Q?INKSH8VmTNF349h1tQyK3rtLGp1ingIUEjM3pxxIZPjLJuYFDARDDnu6T+9i?=
 =?us-ascii?Q?5g3kUBedcQpqoVwLjQ9+mGc+TwH6JXZN+JCWORc6kBoSXzOeCdbHd9EfhPta?=
 =?us-ascii?Q?QgzoR5aU6C8UsPpKcrG/LlWOWKrXFarT6EvIRDxEX01F4wROEpgz/Eii+zsQ?=
 =?us-ascii?Q?dFP7ui8xd7fvTIcwMRmspeDPidpweeO2MzJXVkLPsNKxCjVQZOCUFR765+qT?=
 =?us-ascii?Q?7rrKnK0JJiqgNA97mR5AX0A2KTvBSVTNIBc/M4yeukCsTFua0L5ih5IDwDPg?=
 =?us-ascii?Q?YT2ILM1bcHGmV8MU7L/4sl91pc3zV8XJRVTkFPXvDeVgcSMArAwsfb2dTcMM?=
 =?us-ascii?Q?v0Iv0cIuFL267UHVqGgDg/TBFb88gT4B2X/2KLslYGVl3ItAQQAr7A=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)(1800799024)(36860700013)(82310400026)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jun 2025 18:29:37.5133
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 6092b0f7-811d-414f-9479-08ddb02869bb
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:
	BN1PEPF00006000.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB5646

pipeline:  https://gitlab.com/xen-project/people/agvallejo/xen/-/pipelines/1880819044

Hi,

There are minor adjustments throughout based on feedback, and I've also dropped
the patch that allowed x86 to just pick DOM0LESS_BOOT right now until the rest
of the changes to boot a single-dom0 DTB go in. Biggest changes are regarding
some confusion with Kconfig.

The idea is to segregate DT processing in two. A basic one, and a full-fledged
one. The former would be currently used exclusively by x86, based on the fact
that it does not need to discover devices in the DT, while the later would
remain largely the same for every other Xen port, because they need all of it
anyway for their own boot procedures.

v3 used CONFIG_HAS_DEVICE_TREE as such a discriminator of a full-fledged DT
parsing logic. The idea behind v4 is:

  * HAS_DEVICE_TREE is renamed to HAS_DEVICE_TREE_DISCOVERY, to clearly show
    the new interpretation that this Kconfig option exists for platforms that
    discover devices via DTs.
  * DOM0LESS_BOOT stops requiring HAS_DEVICE_TREE, so x86 can pick it
  * DOM0LESS_BOOT starts allowing compiling a subset of common/device-tree/

Looked at in a different light:

  Full DT support: HAS_DEVICE_TREE_DISCOVERY
  Basic DT support: DOM0LESS_BOOT || HAS_DEVICE_TREE_DISCOVERY
  No DT support: !DOM0LESS_BOOT && !HAS_DEVICE_TREE_DISCOVERY

And in table form FTAOD:

          | HAS_DEVICE_TREE_DISCOVERY | DOM0LESS_BOOT |   Description    |
    ------+---------------------------+---------------+------------------+
          |                           |       y       | Basic DT support |
      x86 +            n              +---------------+------------------+
          |                           |       n       |    No DT support |
    ------+---------------------------+---------------+------------------+
      arm |                           |               |                  |
    ------+                           |               |                  |
    riscv |            y              |      y/n      | Full DT support  |
    ------+                           |               |                  |
      ppc |                           |               |                  |
    ------+---------------------------+---------------+------------------+

Note that HAS_DOM0LESS stays around to hide DOM0LESS_BOOT from ports that
don't support dom0less yet (all but arm, atm).

Previous versions
=================

v3: https://lore.kernel.org/xen-devel/20250613151612.754222-1-agarciav@amd.com/
v2: https://lore.kernel.org/xen-devel/20250605194810.2782031-1-agarciav@amd.com/
v1: https://lore.kernel.org/xen-devel/20250530120242.39398-1-agarciav@amd.com/

Original cover letter
=====================

This is the aftermath of this discussion:

  https://lore.kernel.org/xen-devel/DA1WWRUQLCAG.ZTVR1HXJ85V0@amd.com/https://lore.kernel.org/xen-devel/DA1WWRUQLCAG.ZTVR1HXJ85V0@amd.com/

It's a first round of cleanup and preparation to have a much easier time
later when integrating dom0less boot into hyperlaunch.

The refactor on device-tree/ is _fine_ by I'm open to other suggestions
to achieve the same thing. In particular, after this series x86 can
unflatten the DT host device tree when it has CONFIG_DOM0LESS_BOOT set,
which enables the builder to use factored-out functions from
dom0less-build.c (not done here).

The diffstat is deceptive because I renamed a large file and then
created a new file with the same name. There aren't that many LoC
changes.

Alejandro Vallejo (12):
  CODING_STYLE: Custom type names must be snake-cased by word.
  xen: Rename bootmodule{,s} to boot_module{,s}
  x86: Replace arch-specific boot_module with common one
  xen: Refactor kernel_info to have a header like boot_domain
  x86: Replace arch-specific boot_domain with the common one
  xen/dt: Move bootfdt functions to xen/bootfdt.h
  xen/dt: Move bootinfo functions to a new bootinfo.h
  xen/dt: Rename bootfdt.c -> bootinfo-fdt.c
  xen/dt: Extract helper to map nodes to module kinds
  xen: Rename CONFIG_HAS_DEVICE_TREE to CONFIG_HAS_DEVICE_TREE_DISCOVERY
  xen/dt: ifdef out DEV_DT-related bits from device_tree.{c,h}
  xen/dt: Remove DOM0LESS_BOOT's requirement on
    HAS_DEVICE_TREE_DISCOVERY

 CODING_STYLE                            |   6 +
 xen/Kconfig.debug                       |   2 +-
 xen/arch/arm/Kconfig                    |   2 +-
 xen/arch/arm/dom0less-build.c           |   8 +-
 xen/arch/arm/domain_build.c             |  21 +-
 xen/arch/arm/efi/efi-boot.h             |   6 +-
 xen/arch/arm/include/asm/setup.h        |   2 +-
 xen/arch/arm/kernel.c                   |  10 +-
 xen/arch/arm/llc-coloring.c             |   8 +-
 xen/arch/arm/mmu/setup.c                |  10 +-
 xen/arch/arm/setup.c                    |  11 +-
 xen/arch/ppc/Kconfig                    |   2 +-
 xen/arch/riscv/Kconfig                  |   2 +-
 xen/arch/riscv/cpufeature.c             |   1 +
 xen/arch/riscv/mm.c                     |   2 +-
 xen/arch/riscv/setup.c                  |   2 +-
 xen/arch/riscv/smpboot.c                |   1 +
 xen/arch/x86/cpu/microcode/core.c       |   7 +-
 xen/arch/x86/hvm/dom0_build.c           |   8 +-
 xen/arch/x86/include/asm/boot-domain.h  |  33 --
 xen/arch/x86/include/asm/bootfdt.h      |  56 ++
 xen/arch/x86/include/asm/bootinfo.h     |  57 +--
 xen/arch/x86/pv/dom0_build.c            |   6 +-
 xen/arch/x86/setup.c                    |  55 +-
 xen/common/Kconfig                      |   7 +-
 xen/common/Makefile                     |   5 +-
 xen/common/device-tree/Makefile         |   7 +-
 xen/common/device-tree/bootfdt.c        | 654 ++----------------------
 xen/common/device-tree/bootinfo-fdt.c   | 583 +++++++++++++++++++++
 xen/common/device-tree/bootinfo.c       |  54 +-
 xen/common/device-tree/device-tree.c    |   3 +
 xen/common/device-tree/dom0less-build.c |  45 +-
 xen/common/device-tree/domain-build.c   |  22 +-
 xen/common/device-tree/kernel.c         |  30 +-
 xen/common/device-tree/static-evtchn.c  |   1 +
 xen/common/device.c                     |   4 +-
 xen/common/efi/boot.c                   |   2 +-
 xen/common/sched/Kconfig                |   2 +-
 xen/common/sched/boot-cpupool.c         |   1 +
 xen/drivers/char/ns16550.c              |   6 +-
 xen/drivers/passthrough/Makefile        |   2 +-
 xen/drivers/passthrough/iommu.c         |   2 +-
 xen/include/asm-generic/device.h        |  10 +-
 xen/include/xen/bootfdt.h               | 306 ++++-------
 xen/include/xen/bootinfo.h              | 213 ++++++++
 xen/include/xen/device_tree.h           |  70 +--
 xen/include/xen/fdt-domain-build.h      |   2 +-
 xen/include/xen/fdt-kernel.h            |  12 +-
 xen/include/xen/iommu.h                 |   8 +-
 xen/include/xsm/dummy.h                 |   4 +-
 xen/include/xsm/xsm.h                   |  12 +-
 xen/xsm/dummy.c                         |   2 +-
 xen/xsm/flask/hooks.c                   |   6 +-
 xen/xsm/xsm_core.c                      |   4 +-
 xen/xsm/xsm_policy.c                    |   8 +-
 55 files changed, 1228 insertions(+), 1177 deletions(-)
 delete mode 100644 xen/arch/x86/include/asm/boot-domain.h
 create mode 100644 xen/arch/x86/include/asm/bootfdt.h
 create mode 100644 xen/common/device-tree/bootinfo-fdt.c
 create mode 100644 xen/include/xen/bootinfo.h


base-commit: 12d72d032e169082308efb9d44b9964ef9fa4340
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 20 18:29:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 18:29:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021077.1397122 (Exim 4.92)
	(envelope-from )
	id 1uSgUp-0005L5-JX; Fri, 20 Jun 2025 18:29:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021077.1397122; Fri, 20 Jun 2025 18: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 1uSgUp-0005Ky-Gr; Fri, 20 Jun 2025 18:29:51 +0000
Received: by outflank-mailman (input) for mailman id 1021077;
 Fri, 20 Jun 2025 18:29:50 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uSgUo-00057I-8r
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 18:29:50 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20628.outbound.protection.outlook.com
 [2a01:111:f403:2413::628])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8c076d95-4e04-11f0-a30e-13f23c93f187;
 Fri, 20 Jun 2025 20:29:49 +0200 (CEST)
Received: from BN9P220CA0011.NAMP220.PROD.OUTLOOK.COM (2603:10b6:408:13e::16)
 by SA1PR12MB6703.namprd12.prod.outlook.com (2603:10b6:806:253::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.35; Fri, 20 Jun
 2025 18:29:45 +0000
Received: from BN1PEPF00006000.namprd05.prod.outlook.com
 (2603:10b6:408:13e:cafe::17) by BN9P220CA0011.outlook.office365.com
 (2603:10b6:408:13e::16) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8857.25 via Frontend Transport; Fri,
 20 Jun 2025 18:29:43 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN1PEPF00006000.mail.protection.outlook.com (10.167.243.232) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8857.21 via Frontend Transport; Fri, 20 Jun 2025 18:29:43 +0000
Received: from xcbagarciav01.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; Fri, 20 Jun
 2025 13:29:37 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8c076d95-4e04-11f0-a30e-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=qJUMJR8PPmBlmzzCRfdrCD4OMLk8cXTLh4X7Rcjib82138YQbfWGuHXw6JxISWFjA343rUOHTTVC5T1NDuppqF5moXrRf6VLHIRHWNoXYTPLUSzNHG4w/OhXFMic2JdHbdCYg4WCM584oQ3uBkdXf5mYDr40SEdOD/pQKqRaC3bBiElo6UkJrYDzE53RjIiCu8BTKCVm1C1XTZKp03Tv5D2zVlfXXKlxFYNLMbp8HJsQ+1Cfc0czQBZBYDLMyPnwvjPrhuCw6HBACA6wd2nHzqaaCWLS0evi2+M/7IqvL5rSRF21lY93s17jmrP5hRO/LiGo+oUbWoi+Onz8xckmdw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=qPIMmLTlV3KNkR+uQ9J8eRat1nufRPKVw3tSoa4EpJs=;
 b=hx3dmwh0B94GCsWUcB5awv8UJyrDZ7DaOX/S6iWn+bcRWSF8X7LQGBW3Dlg70pcGAoh0P+gdlxbjpYeof2nF6hBWTs6edujWKSLb/7FxcrdG7ISBT7WK4jXmobd2KLMdebAg9d1kev0fTn09Y6MO7ogF7QleyGcOhgHl0ujpXSrFOJL45REdfJZ7Qm2tYLSiUZXFRsAkWS5omscXD69XUz+ob1vXkau2kYVfao/II8RweGFgg6J94FdsYNBEfQTKsG8In77MQU6NPfU53dlGRg2uIRiCplEN7axHYPnzl7Vs5yUOYTkn1ddFAQFtG0SutctqlhP7Lr/usTRXprrXAg==
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=qPIMmLTlV3KNkR+uQ9J8eRat1nufRPKVw3tSoa4EpJs=;
 b=e7vwp0y0V10T+N2WciXi9jsiPyJxgoA5pVkVdlHMxflFt9871+JrzFcBXyHwlqUQATy0kgzOSSHM422JtFPVPThBPUOR6ifn0EFj0lhECMU6C93zg4mGb7wtXDm3vmlrq+KWeviyVy8wBHGQrszjylkf2UkikL7e8MKh0wEih3Q=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , "Julien
 Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Stefano Stabellini 
Subject: [PATCH v4 01/12] CODING_STYLE: Custom type names must be snake-cased by word.
Date: Fri, 20 Jun 2025 20:28:47 +0200
Message-ID: <20250620182859.23378-2-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250620182859.23378-1-agarciav@amd.com>
References: <20250620182859.23378-1-agarciav@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: BN1PEPF00006000:EE_|SA1PR12MB6703:EE_
X-MS-Office365-Filtering-Correlation-Id: 45b4271b-7e38-4012-db89-08ddb0286d91
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?wS+9PJyOWceFqQHOVQ7Ztf5t7khxF02zCSQHr0Bg7e+Patz31e/FNvKNBbR6?=
 =?us-ascii?Q?OcI8n/GVEvlRsBwsu4y9KnBgc6yGT0NeEn6lIKdJh5d1DWMD+axCmYNNY6r1?=
 =?us-ascii?Q?ErI4yPjaMDAE3oIrYPTiaE1eSgB4+E/7lvdWvb24QbZM1btdw6Gr7mPNqFSr?=
 =?us-ascii?Q?hgc16VsGjHgiIut0n3/IJcxvFWxkDUf6E5xoOFxw+fDi+fnqRuUbALQbMFf0?=
 =?us-ascii?Q?C5gbef6+qwhYxuZh7qr2T/p3OlWwjLEB7/y7AsO1f390TmoTaki5nyfsEUno?=
 =?us-ascii?Q?kV4NP1bZ3Mydy8+gagWpC4/fIx6V1hOw2bpgKgy2hnAbUdJ8J+pIdpR7RnQQ?=
 =?us-ascii?Q?TQf4k58z2dWXbAlAmkfkP5BQyH7BNt5HRpVk3Hq4xFesqFUuzTynP9RM08li?=
 =?us-ascii?Q?CqzLOTnphmz+QidCkCSJkMjhw1nA3acWCYWXJAhUZHVolB06jwHFKNUSje2L?=
 =?us-ascii?Q?fBdSubw+SyHc7OdYYFCAd+YIMNe1w3tCI8kHOigKPo4bZSEhrE7re74F4sz2?=
 =?us-ascii?Q?L92SUNGug6SL//PyohzOxA3ue4x9oAYIwwpf0MTfxKEG8TFLrwNa76IWeL+9?=
 =?us-ascii?Q?/zVQGqI/oH7cG9hobs3/KtjnYChxOaO635JDCki1w4RUqzuDgpuVs/bMR6LI?=
 =?us-ascii?Q?4zDCY5cgtirTUCIwn0I7lzDkMTiA3N8NNxiRI2uQ5cwsVuwvSygJwh/JE//2?=
 =?us-ascii?Q?wUM1fN46m47o6SuxZxXLJPi/WsjH8xRJMq7AhfXyMeST52vPI2n7lvrjbxnC?=
 =?us-ascii?Q?rSkDyJnvmRbDbrGTZih+9EPtbSKThFIyHyUwY/VoOYvH9rfZzNX0h3T+tGpx?=
 =?us-ascii?Q?H8W7GW4mcrWNQZnLvhv78BdMMvhJLrU51oZYUbnpm34RzrK9W6xKSUPFL2dz?=
 =?us-ascii?Q?tTuGiD2jZdvGTpd187j+ZEM541ampuNthQ4BtJvs6SkdcQUquU8ZjDFM3s68?=
 =?us-ascii?Q?qZ3ahf2+v/1ogfAm0Wsih9GjqR1f83ZPD1iO7Eh+2KiU5ztzZGmgI1m95vk1?=
 =?us-ascii?Q?gXrFcLnIccQzuR/9uN/MoQcEDDQdxAtypJxipWAKNYNAkGbCC9U76/ZFkywr?=
 =?us-ascii?Q?21Fq9vYTE3/C0LL+3Kw4IE2cdgrhkdHY0tDJJ6Zci9pESpUwhMCTOi2PByQJ?=
 =?us-ascii?Q?WIMS7VvisOOc1HoCG10V/uq9c8n2JBq2vySrhFCfcXtaBsXkw+d6XGAwNwfA?=
 =?us-ascii?Q?1NDR2gyxZAYSuZkMDJJpRIcBIOI6GVQcEArZAHuz4xGNniM9vZFxGHZ7AlHO?=
 =?us-ascii?Q?zjkgbVs18h8E0EwlYva1MgYy9q8/41vIpgY8/5VjAarqGzTi2YsnNB5H0lub?=
 =?us-ascii?Q?rgC5uVkSVLTDoVpEU+CzZRWLalJZFif+QtLMYeCUhzayT06a/VXNFQtA59Rf?=
 =?us-ascii?Q?PPDVMFkzPRbkOun1SCNjW+mlyEK5N5vFtiNM4iT/d1GJIDqWMqjRPyf0cY5C?=
 =?us-ascii?Q?GJjvkt2HJ3IHe+7P/eHWAlSyY5lvVWMeaUBTBHjnzUeIKUf9mrOmg12m2k59?=
 =?us-ascii?Q?7idJxy/wu1SnrlvBU1HIXPFyIOlM1vmM/maT?=
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: 20 Jun 2025 18:29:43.9512
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 45b4271b-7e38-4012-db89-08ddb0286d91
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:
	BN1PEPF00006000.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB6703

There's the unwritten convention in x86 of splitting type names using
underscores. Add such convention to the CODINNG_STYLE to make it
common and less unwritten.

Signed-off-by: Alejandro Vallejo 
---
v4:
  * Move new paragraph into a new "Identifiers" section
---
 CODING_STYLE | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/CODING_STYLE b/CODING_STYLE
index 5644f1697f..7bf3848444 100644
--- a/CODING_STYLE
+++ b/CODING_STYLE
@@ -113,6 +113,12 @@ Braces should be omitted for blocks with a single statement. e.g.,
 if ( condition )
     single_statement();
 
+Identifiers
+-----------
+
+When giving names to identifiers (variables, functions, constants...), separate
+words using underscores (for example, use "my_foo" instead of "myfoo").
+
 Types
 -----
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 20 18:30:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 18:30:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021082.1397133 (Exim 4.92)
	(envelope-from )
	id 1uSgV0-0005sY-Vm; Fri, 20 Jun 2025 18:30:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021082.1397133; Fri, 20 Jun 2025 18:30: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 1uSgV0-0005sD-ST; Fri, 20 Jun 2025 18:30:02 +0000
Received: by outflank-mailman (input) for mailman id 1021082;
 Fri, 20 Jun 2025 18:30: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 1uSgUz-00057I-TH
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 18:30:02 +0000
Received: from NAM02-SN1-obe.outbound.protection.outlook.com
 (mail-sn1nam02on2061e.outbound.protection.outlook.com
 [2a01:111:f403:2406::61e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 90d3be23-4e04-11f0-a30e-13f23c93f187;
 Fri, 20 Jun 2025 20:29:57 +0200 (CEST)
Received: from BL6PEPF00016417.NAMP222.PROD.OUTLOOK.COM
 (2603:10b6:22e:400:0:1004:0:5) by SN7PR12MB7227.namprd12.prod.outlook.com
 (2603:10b6:806:2aa::18) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.28; Fri, 20 Jun
 2025 18:29:53 +0000
Received: from BN1PEPF00005FFD.namprd05.prod.outlook.com
 (2a01:111:f403:c803::2) by BL6PEPF00016417.outlook.office365.com
 (2603:1036:903:4::a) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8857.25 via Frontend Transport; Fri,
 20 Jun 2025 18:29:53 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN1PEPF00005FFD.mail.protection.outlook.com (10.167.243.229) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8857.21 via Frontend Transport; Fri, 20 Jun 2025 18:29:52 +0000
Received: from xcbagarciav01.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; Fri, 20 Jun
 2025 13:29:44 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 90d3be23-4e04-11f0-a30e-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=JnkJWWZvK0S8x1phXZ/FVznDQQudmQY3DY6f0NZ96dzVibGehnw5s8STzZmiaPGlX8HAArHFxoUEllCk1BzNt6ZchEBJwf+cb0h3bymBMMlLKhE2G4YPqxGS6vCQ9saRNA+hARaMzcd0Gq8XzWK6LMdKy+BNpuWzHZNyfUSCFpY9pODjOeLmqzr8hJJBxg3WW6uzsCTSw4BlyzuNtTV4I15rtoZH8duvz/jGMG82ndQQA6xyZLbJkyr0JoSpBLAGNAyL4Do4jLm+T61YpkA6cyA64TXohVI0isWBiP0pfreZsKCCuONeoZ95FE4f1VQPA7beucjfaeEue3ltE56/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=p44M7RzHGXTyxxIkCh7v0gyMVi75uj2BQ3nBpbpii4U=;
 b=K+aZpKz4kX4kXlNNGD2FtB6/ppGOZcfzN/RHN+Masej8iZHde7HUqY2FfX87K94GIrtZ7f5Mo5DrCFzmn4geOruNC+azpXKJjmoekncjqzAJtimIWVBBOpdnYU5GMsiXR0Pm4RorGFftwS17uqofx53m3wOR/CELSYn659mIzHs1VHCvJyUEw6L3f48fVfxAqF13IvOa6z+crizHMgWKjaGBXuLFmfnxQ6n09p1r8oP1TB6BOiRs+cFRKOhobzUlCaCgl/+bpt5LF18UKvnMm3qB+uFABAGPZvFgVQBOpmvzKVQBrtlCMwCiw6SZmnOgQUP1sE/ZY8CM5Xgfv5pHjw==
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=p44M7RzHGXTyxxIkCh7v0gyMVi75uj2BQ3nBpbpii4U=;
 b=IvknDJyBIEZqnTHaG8QVIKijYh8J5GbNRKuj6Qj/B/EuTb7E7xyl+mNohELVaLvHX+Tt4tEaLKq6teQU4cbwt2AsQ5IWx2+v/AvYCt+TgN08wgoYgWEOf9Qgijph8rSkDn+kEgpOZR3MO2gtyLhhMDhodvLzgbIogGf1JmDXwkU=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , Andrew Cooper
	, Anthony PERARD , "Jan
 Beulich" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, "Daniel P. Smith" 
Subject: [PATCH v4 02/12] xen: Rename bootmodule{,s} to boot_module{,s}
Date: Fri, 20 Jun 2025 20:28:48 +0200
Message-ID: <20250620182859.23378-3-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250620182859.23378-1-agarciav@amd.com>
References: <20250620182859.23378-1-agarciav@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: BN1PEPF00005FFD:EE_|SN7PR12MB7227:EE_
X-MS-Office365-Filtering-Correlation-Id: 67fbfb97-3f0f-4e56-2078-08ddb02872cf
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|7416014|376014|1800799024|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?FJrMlR6NWbsUdP4XnMREuiiza4C58+PIFGAD8r4sMQ6nouQetgM3Xu2No7iK?=
 =?us-ascii?Q?vJ5+uRiGwq/PUpgx9N4lh0GHbGcNBRQ0TGFQZpY5/5Vn4XfYn9UifN3g67H0?=
 =?us-ascii?Q?YsjyYgUZ1P5zzXOTm6J3EthWrCsk9vP9quafTttYD/X7EFMj6a63x7OCbRrS?=
 =?us-ascii?Q?Mfl0JjNTiM3nON/gfy0R/YmbPx+znKV0vgkFz23LL+fNR1+MLvE8YMF7JBJh?=
 =?us-ascii?Q?SI4ekZT7kiBzDb0+K2yd7r1n37/MFlYkx2o2mN8lIivdDAALiwop1Zmz2Wd8?=
 =?us-ascii?Q?21w5AVNhUhu/8jp4E1D2VmzbyH1PgIb+y8dR1vyIgH4Z1mDQjjEOsUZf+/UE?=
 =?us-ascii?Q?WHPXWC2p5OWEOulhN1yhW/XxNbkXJJJ2PyCjvRROqgmvPBR3mD2BesKVMn7D?=
 =?us-ascii?Q?u30XAewiERmpuATImKtARY2G75cmR1FCdCEag94ORkOIauddJt2+hhpC6csh?=
 =?us-ascii?Q?mCaEI+cE5dILnvRhs0ijs0kDPojr2xLhFnTFPOy8A3FOjwBR5Kn4V17c250n?=
 =?us-ascii?Q?3tmIG3lxoRzGtqKWIL6dbSCj3SIQFmqcotgCr/nqvf8FREVziA+hR8ssGKUl?=
 =?us-ascii?Q?r5B/ZACRvA8mIUUiY7I8Jcq/3BnvdnseggJECcAE36beLG0RAtUQEb8Zreqz?=
 =?us-ascii?Q?BK7A9Zbh2+cSdIrpT4sqN+janMmzrztrQ3HBzHCHmacNAAJ91Fn57rkSkCrr?=
 =?us-ascii?Q?muXuW8GDT5nRUl4Y7GJB/UlpvzyMRlB28OtOtnTE+GRDcj2ZF5johrRzh1sA?=
 =?us-ascii?Q?cLWr+7nuIajeCeZNki+FbgUZyuc5FmzyAhkgijqvtJvod0wxNJ7XPC9yU7bi?=
 =?us-ascii?Q?0qTTkmRy4zRxI/X9B4GuTgwVxZk0j/h1rwE6Y19u+od4kH2nebnQwW4Z/C+H?=
 =?us-ascii?Q?W4j+ed8tO5hfsDIUhlG5G7cJlRyE1yPSD0dnA/M7xI7AlOCh6BSJNrOJQ1A6?=
 =?us-ascii?Q?pE4KhBHylgvbyUsnVk8mu2Lr3EcP6Kwa/dyBabMVWnc94cURtnXAlF0PzpKU?=
 =?us-ascii?Q?C4EKANDUDH71q28Ooqa0/rIY3tnTE3lIAiZ5f4oUzhRA5QX0XpgTZKkx2Z/e?=
 =?us-ascii?Q?XyH6KYYGETwk2jDhUEyz6CK18jl2xGVIEbI7+SUeBInNPomP4wCswLEe5B/K?=
 =?us-ascii?Q?hmPFU3EF4mlPNAsafioAcdpAZvLy13awvn9vUp7PwIB9+TK7NcpUWZTQuxRu?=
 =?us-ascii?Q?p9PKGu0cLp+cS1DBMcSvuJbXWvYWNpH9HML750MOdLoHl4tXL3mFnfnHQbaR?=
 =?us-ascii?Q?FlEb89OddeBSbaqB4fGWDB74gtKD6qMbeQVvMVsXk7X0YI6Abt/X8ijrw5MM?=
 =?us-ascii?Q?J3SfFv3zljPS+5SB2J1c2D6maqFwzYg8VhMfRyk/Yu8lhg9Xa206XZut3vVB?=
 =?us-ascii?Q?K48KabOPJlydwjV0RnQq7lA4sUQri+9B7ae5+NkEDBKznyFHQDnbK/3sh8EW?=
 =?us-ascii?Q?Ks92cg87W+awLyHQA7X19qdz4D+IrJy5VN1S1wf6TgvA2HDA/+TaJsQ+2JoB?=
 =?us-ascii?Q?AgPDA57sPys+hDVwvkdDG/sM+cT+yZpHGu9d?=
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)(7416014)(376014)(1800799024)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jun 2025 18:29:52.7415
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 67fbfb97-3f0f-4e56-2078-08ddb02872cf
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:
	BN1PEPF00005FFD.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7227

... in alignment with the new coding style on word splitting for type
names.

This aligns its name with the largely duplicate boot_module struct
in x86. While there's no equivalent to "struct bootmodules" in x86,
changing one and not the other is just confusing. Same with various
comments and function names.

Rather than making a long subfield name even longer, remove the
_bootmodule suffix in the kernel, initrd and dtb subfields.

Not a functional change.

Signed-off-by: Alejandro Vallejo 
Reviewed-by: Stefano Stabellini 
Acked-By: Daniel P. Smith 
---
 xen/arch/arm/domain_build.c             |  4 +-
 xen/arch/arm/efi/efi-boot.h             |  6 +--
 xen/arch/arm/kernel.c                   |  4 +-
 xen/arch/arm/llc-coloring.c             |  8 ++--
 xen/arch/arm/mmu/setup.c                | 10 ++---
 xen/arch/arm/setup.c                    | 10 ++---
 xen/common/device-tree/bootfdt.c        |  4 +-
 xen/common/device-tree/bootinfo.c       | 52 ++++++++++++-------------
 xen/common/device-tree/dom0less-build.c | 25 ++++++------
 xen/common/device-tree/domain-build.c   |  2 +-
 xen/common/device-tree/kernel.c         | 22 +++++------
 xen/include/xen/bootfdt.h               | 26 ++++++-------
 xen/include/xen/fdt-kernel.h            |  7 ++--
 xen/xsm/xsm_policy.c                    |  2 +-
 14 files changed, 90 insertions(+), 92 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 4ff161887e..3f5c7c2e5a 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -579,7 +579,7 @@ static int __init write_properties(struct domain *d, struct kernel_info *kinfo,
 
     if ( dt_node_path_is_equal(node, "/chosen") )
     {
-        const struct bootmodule *initrd = kinfo->initrd_bootmodule;
+        const struct boot_module *initrd = kinfo->initrd;
 
         if ( bootargs )
         {
@@ -1517,7 +1517,7 @@ int __init make_chosen_node(const struct kernel_info *kinfo)
 {
     int res;
     const char *bootargs = NULL;
-    const struct bootmodule *initrd = kinfo->initrd_bootmodule;
+    const struct boot_module *initrd = kinfo->initrd;
     void *fdt = kinfo->fdt;
 
     dt_dprintk("Create chosen node\n");
diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
index ee80560e13..faabe5a6a8 100644
--- a/xen/arch/arm/efi/efi-boot.h
+++ b/xen/arch/arm/efi/efi-boot.h
@@ -20,7 +20,7 @@ typedef struct {
 } module_info;
 
 /*
- * Binaries will be translated into bootmodules, the maximum number for them is
+ * Binaries will be translated into boot_modules, the maximum number for them is
  * MAX_MODULES where we should remove a unit for Xen and one for Xen DTB
  */
 #define MAX_UEFI_MODULES (MAX_MODULES - 2)
@@ -602,9 +602,9 @@ static void __init efi_arch_handle_module(const struct file *file,
 
     /*
      * modules_available is decremented here because for each dom0 file added
-     * from the configuration file, there will be an additional bootmodule,
+     * from the configuration file, there will be an additional boot_module,
      * so the number of available slots will be decremented because there is a
-     * maximum amount of bootmodules that can be loaded.
+     * maximum amount of boot_modules that can be loaded.
      */
     modules_available--;
 }
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index cb1efb19e7..e734ec5c1e 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -46,7 +46,7 @@ static void __init place_modules(struct kernel_info *info,
                                  paddr_t kernbase, paddr_t kernend)
 {
     /* Align DTB and initrd size to 2Mb. Linux only requires 4 byte alignment */
-    const struct bootmodule *mod = info->initrd_bootmodule;
+    const struct boot_module *mod = info->initrd;
     const struct membanks *mem = kernel_info_get_mem(info);
     const paddr_t initrd_len = ROUNDUP(mod ? mod->size : 0, MB(2));
     const paddr_t dtb_len = ROUNDUP(fdt_totalsize(info->fdt), MB(2));
@@ -175,7 +175,7 @@ static void __init kernel_zimage_load(struct kernel_info *info)
  * Check if the image is a uImage and setup kernel_info
  */
 int __init kernel_uimage_probe(struct kernel_info *info,
-                               struct bootmodule *mod)
+                               struct boot_module *mod)
 {
     struct {
         __be32 magic;   /* Image Header Magic Number */
diff --git a/xen/arch/arm/llc-coloring.c b/xen/arch/arm/llc-coloring.c
index 99ac10b610..6f78817c57 100644
--- a/xen/arch/arm/llc-coloring.c
+++ b/xen/arch/arm/llc-coloring.c
@@ -123,12 +123,12 @@ static paddr_t __init xen_colored_map_size(void)
 
 void __init arch_llc_coloring_init(void)
 {
-    struct bootmodule *xen_bootmodule = boot_module_find_by_kind(BOOTMOD_XEN);
+    struct boot_module *xen_boot_module = boot_module_find_by_kind(BOOTMOD_XEN);
 
-    BUG_ON(!xen_bootmodule);
+    BUG_ON(!xen_boot_module);
 
-    xen_bootmodule->size = xen_colored_map_size();
-    xen_bootmodule->start = get_xen_paddr(xen_bootmodule->size);
+    xen_boot_module->size = xen_colored_map_size();
+    xen_boot_module->start = get_xen_paddr(xen_boot_module->size);
 }
 
 /*
diff --git a/xen/arch/arm/mmu/setup.c b/xen/arch/arm/mmu/setup.c
index 30afe97781..eb8ed19ca1 100644
--- a/xen/arch/arm/mmu/setup.c
+++ b/xen/arch/arm/mmu/setup.c
@@ -246,7 +246,7 @@ paddr_t __init consider_modules(paddr_t s, paddr_t e,
 #ifdef CONFIG_STATIC_SHM
     const struct membanks *shmem = bootinfo_get_shmem();
 #endif
-    const struct bootmodules *mi = &bootinfo.modules;
+    const struct boot_modules *mi = &bootinfo.modules;
     int i;
     int nr;
 
@@ -273,8 +273,8 @@ paddr_t __init consider_modules(paddr_t s, paddr_t e,
     }
 
     /*
-     * i is the current bootmodule we are evaluating, across all
-     * possible kinds of bootmodules.
+     * i is the current boot_module we are evaluating, across all
+     * possible kinds of boot_modules.
      *
      * When retrieving the corresponding reserved-memory addresses, we
      * need to index the reserved_mem bank starting from 0, and only counting
@@ -328,8 +328,8 @@ 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;
+    struct boot_module *xen_boot_module = boot_module_find_by_kind(BOOTMOD_XEN);
+    mfn_t start_mfn = maddr_to_mfn(xen_boot_module->start), mfn;
 
     for_each_xen_colored_mfn ( start_mfn, mfn, i )
     {
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index ed72317af3..58acc2d0d4 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -206,11 +206,11 @@ static void __init processor_id(void)
 
 void __init discard_initial_modules(void)
 {
-    struct bootmodules *mi = &bootinfo.modules;
+    struct boot_modules *mi = &bootinfo.modules;
     int i;
 
     /*
-     * When using static heap feature, don't give bootmodules memory back to
+     * When using static heap feature, don't give boot_modules memory back to
      * the heap allocator
      */
     if ( using_static_heap )
@@ -303,7 +303,7 @@ void asmlinkage __init start_xen(unsigned long fdt_paddr)
 {
     size_t fdt_size;
     const char *cmdline;
-    struct bootmodule *xen_bootmodule;
+    struct boot_module *xen_boot_module;
     struct domain *d;
     int rc, i;
 
@@ -327,10 +327,10 @@ void asmlinkage __init start_xen(unsigned long fdt_paddr)
               fdt_paddr);
 
     /* Register Xen's load address as a boot module. */
-    xen_bootmodule = add_boot_module(BOOTMOD_XEN,
+    xen_boot_module = add_boot_module(BOOTMOD_XEN,
                              virt_to_maddr(_start),
                              (paddr_t)(uintptr_t)(_end - _start), false);
-    BUG_ON(!xen_bootmodule);
+    BUG_ON(!xen_boot_module);
 
     fdt_size = boot_fdt_info(device_tree_flattened, fdt_paddr);
 
diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
index 9daea06e57..39334d6205 100644
--- a/xen/common/device-tree/bootfdt.c
+++ b/xen/common/device-tree/bootfdt.c
@@ -314,7 +314,7 @@ static void __init process_multiboot_node(const void *fdt, int node,
     static int __initdata kind_guess = 0;
     const struct fdt_property *prop;
     const __be32 *cell;
-    bootmodule_kind kind;
+    boot_module_kind kind;
     paddr_t start, size;
     int len;
     /* sizeof("/chosen/") + DT_MAX_NAME + '/' + DT_MAX_NAME + '/0' => 92 */
@@ -518,7 +518,7 @@ static void __init early_print_info(void)
 {
     const struct membanks *mi = bootinfo_get_mem();
     const struct membanks *mem_resv = bootinfo_get_reserved_mem();
-    struct bootmodules *mods = &bootinfo.modules;
+    struct boot_modules *mods = &bootinfo.modules;
     struct bootcmdlines *cmds = &bootinfo.cmdlines;
     unsigned int i;
 
diff --git a/xen/common/device-tree/bootinfo.c b/xen/common/device-tree/bootinfo.c
index 717cfa0962..2a27d1318b 100644
--- a/xen/common/device-tree/bootinfo.c
+++ b/xen/common/device-tree/bootinfo.c
@@ -21,7 +21,7 @@
 
 struct bootinfo __initdata bootinfo = BOOTINFO_INIT;
 
-const char * __init boot_module_kind_as_string(bootmodule_kind kind)
+const char * __init boot_module_kind_as_string(boot_module_kind kind)
 {
     switch ( kind )
     {
@@ -49,7 +49,7 @@ static void __init dt_unreserved_regions(paddr_t s, paddr_t e,
     unsigned int i;
 
     /*
-     * i is the current bootmodule we are evaluating across all possible
+     * i is the current boot_module we are evaluating across all possible
      * kinds.
      */
     for ( i = first; i < reserved_mem->nr_banks; i++ )
@@ -143,18 +143,18 @@ static bool __init meminfo_overlap_check(const struct membanks *mem,
  * TODO: '*_end' could be 0 if the module/region is at the end of the physical
  * address space. This is for now not handled as it requires more rework.
  */
-static bool __init bootmodules_overlap_check(struct bootmodules *bootmodules,
-                                             paddr_t region_start,
-                                             paddr_t region_size)
+static bool __init boot_modules_overlap_check(struct boot_modules *boot_modules,
+                                              paddr_t region_start,
+                                              paddr_t region_size)
 {
     paddr_t mod_start = INVALID_PADDR, mod_end = 0;
     paddr_t region_end = region_start + region_size;
-    unsigned int i, mod_num = bootmodules->nr_mods;
+    unsigned int i, mod_num = boot_modules->nr_mods;
 
     for ( i = 0; i < mod_num; i++ )
     {
-        mod_start = bootmodules->module[i].start;
-        mod_end = mod_start + bootmodules->module[i].size;
+        mod_start = boot_modules->module[i].start;
+        mod_end = mod_start + boot_modules->module[i].size;
 
         if ( region_end <= mod_start || region_start >= mod_end )
             continue;
@@ -210,20 +210,20 @@ bool __init check_reserved_regions_overlap(paddr_t region_start,
                                    allow_memreserve_overlap) )
             return true;
 
-    /* Check if input region is overlapping with bootmodules */
-    if ( bootmodules_overlap_check(&bootinfo.modules,
-                                   region_start, region_size) )
+    /* Check if input region is overlapping with boot_modules */
+    if ( boot_modules_overlap_check(&bootinfo.modules,
+                                    region_start, region_size) )
         return true;
 
     return false;
 }
 
-struct bootmodule __init *add_boot_module(bootmodule_kind kind,
-                                          paddr_t start, paddr_t size,
-                                          bool domU)
+struct boot_module __init *add_boot_module(boot_module_kind kind,
+                                           paddr_t start, paddr_t size,
+                                           bool domU)
 {
-    struct bootmodules *mods = &bootinfo.modules;
-    struct bootmodule *mod;
+    struct boot_modules *mods = &bootinfo.modules;
+    struct boot_module *mod;
     unsigned int i;
 
     if ( mods->nr_mods == MAX_MODULES )
@@ -266,10 +266,10 @@ struct bootmodule __init *add_boot_module(bootmodule_kind kind,
  * XSM, DTB) or Dom0 modules. This is not suitable for looking up guest
  * modules.
  */
-struct bootmodule * __init boot_module_find_by_kind(bootmodule_kind kind)
+struct boot_module * __init boot_module_find_by_kind(boot_module_kind kind)
 {
-    struct bootmodules *mods = &bootinfo.modules;
-    struct bootmodule *mod;
+    struct boot_modules *mods = &bootinfo.modules;
+    struct boot_module *mod;
     int i;
     for (i = 0 ; i < mods->nr_mods ; i++ )
     {
@@ -281,7 +281,7 @@ struct bootmodule * __init boot_module_find_by_kind(bootmodule_kind kind)
 }
 
 void __init add_boot_cmdline(const char *name, const char *cmdline,
-                             bootmodule_kind kind, paddr_t start, bool domU)
+                             boot_module_kind kind, paddr_t start, bool domU)
 {
     struct bootcmdlines *cmds = &bootinfo.cmdlines;
     struct bootcmdline *cmd;
@@ -310,7 +310,7 @@ void __init add_boot_cmdline(const char *name, const char *cmdline,
  * XSM, DTB) or Dom0 modules. This is not suitable for looking up guest
  * modules.
  */
-struct bootcmdline * __init boot_cmdline_find_by_kind(bootmodule_kind kind)
+struct bootcmdline * __init boot_cmdline_find_by_kind(boot_module_kind kind)
 {
     struct bootcmdlines *cmds = &bootinfo.cmdlines;
     struct bootcmdline *cmd;
@@ -340,11 +340,11 @@ struct bootcmdline * __init boot_cmdline_find_by_name(const char *name)
     return NULL;
 }
 
-struct bootmodule * __init boot_module_find_by_addr_and_kind(bootmodule_kind kind,
-                                                             paddr_t start)
+struct boot_module * __init boot_module_find_by_addr_and_kind(
+    boot_module_kind kind, paddr_t start)
 {
-    struct bootmodules *mods = &bootinfo.modules;
-    struct bootmodule *mod;
+    struct boot_modules *mods = &bootinfo.modules;
+    struct boot_module *mod;
     unsigned int i;
 
     for (i = 0 ; i < mods->nr_mods ; i++ )
@@ -366,7 +366,7 @@ struct bootmodule * __init boot_module_find_by_addr_and_kind(bootmodule_kind kin
  */
 static paddr_t __init next_module(paddr_t s, paddr_t *end)
 {
-    struct bootmodules *mi = &bootinfo.modules;
+    struct boot_modules *mi = &bootinfo.modules;
     paddr_t lowest = ~(paddr_t)0;
     int i;
 
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
index 3d503c6973..221b875a2f 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -44,13 +44,13 @@ void __init set_xs_domain(struct domain *d)
 
 bool __init is_dom0less_mode(void)
 {
-    struct bootmodules *mods = &bootinfo.modules;
-    struct bootmodule *mod;
+    struct boot_modules *mods = &bootinfo.modules;
+    struct boot_module *mod;
     unsigned int i;
     bool dom0found = false;
     bool domUfound = false;
 
-    /* Look into the bootmodules */
+    /* Look into the boot_modules */
     for ( i = 0 ; i < mods->nr_mods ; i++ )
     {
         mod = &mods->module[i];
@@ -374,18 +374,17 @@ static int __init check_partial_fdt(void *pfdt, size_t size)
     return 0;
 }
 
-static int __init domain_handle_dtb_bootmodule(struct domain *d,
-                                               struct kernel_info *kinfo)
+static int __init domain_handle_dtb_boot_module(struct domain *d,
+                                                struct kernel_info *kinfo)
 {
     void *pfdt;
     int res, node_next;
 
-    pfdt = ioremap_cache(kinfo->dtb_bootmodule->start,
-                         kinfo->dtb_bootmodule->size);
+    pfdt = ioremap_cache(kinfo->dtb->start, kinfo->dtb->size);
     if ( pfdt == NULL )
         return -EFAULT;
 
-    res = check_partial_fdt(pfdt, kinfo->dtb_bootmodule->size);
+    res = check_partial_fdt(pfdt, kinfo->dtb->size);
     if ( res < 0 )
         goto out;
 
@@ -459,8 +458,8 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
     sizecells = GUEST_ROOT_SIZE_CELLS;
 
     /* Account for domU passthrough DT size */
-    if ( kinfo->dtb_bootmodule )
-        fdt_size += kinfo->dtb_bootmodule->size;
+    if ( kinfo->dtb )
+        fdt_size += kinfo->dtb->size;
 
     /* Cap to max DT size if needed */
     fdt_size = min(fdt_size, SZ_2M);
@@ -507,13 +506,13 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
         goto err;
 
     /*
-     * domain_handle_dtb_bootmodule has to be called before the rest of
+     * domain_handle_dtb_boot_module has to be called before the rest of
      * the device tree is generated because it depends on the value of
      * the field phandle_intc.
      */
-    if ( kinfo->dtb_bootmodule )
+    if ( kinfo->dtb )
     {
-        ret = domain_handle_dtb_bootmodule(d, kinfo);
+        ret = domain_handle_dtb_boot_module(d, kinfo);
         if ( ret )
             goto err;
     }
diff --git a/xen/common/device-tree/domain-build.c b/xen/common/device-tree/domain-build.c
index 99ea81198a..cd01a8b4bc 100644
--- a/xen/common/device-tree/domain-build.c
+++ b/xen/common/device-tree/domain-build.c
@@ -352,7 +352,7 @@ void __init dtb_load(struct kernel_info *kinfo,
 void __init initrd_load(struct kernel_info *kinfo,
                         copy_to_guest_phys_cb copy_to_guest)
 {
-    const struct bootmodule *mod = kinfo->initrd_bootmodule;
+    const struct boot_module *mod = kinfo->initrd;
     paddr_t load_addr = kinfo->initrd_paddr;
     paddr_t paddr, len;
     int node;
diff --git a/xen/common/device-tree/kernel.c b/xen/common/device-tree/kernel.c
index cb04cd9d50..e1b22dc1c7 100644
--- a/xen/common/device-tree/kernel.c
+++ b/xen/common/device-tree/kernel.c
@@ -21,7 +21,7 @@ static uint32_t __init output_length(char *image, unsigned long image_len)
     return *(uint32_t *)&image[image_len - 4];
 }
 
-int __init kernel_decompress(struct bootmodule *mod, uint32_t offset)
+int __init kernel_decompress(struct boot_module *mod, uint32_t offset)
 {
     char *output, *input;
     char magic[2];
@@ -92,7 +92,7 @@ int __init kernel_decompress(struct bootmodule *mod, uint32_t offset)
         free_domheap_page(pages + i);
 
     /*
-     * When using static heap feature, don't give bootmodules memory back to
+     * When using static heap feature, don't give boot_modules memory back to
      * the heap allocator
      */
     if ( using_static_heap )
@@ -118,7 +118,7 @@ int __init kernel_decompress(struct bootmodule *mod, uint32_t offset)
 int __init kernel_probe(struct kernel_info *info,
                         const struct dt_device_node *domain)
 {
-    struct bootmodule *mod = NULL;
+    struct boot_module *mod = NULL;
     struct bootcmdline *cmd = NULL;
     struct dt_device_node *node;
     u64 kernel_addr, initrd_addr, dtb_addr, size;
@@ -140,8 +140,8 @@ int __init kernel_probe(struct kernel_info *info,
 
         mod = boot_module_find_by_kind(BOOTMOD_KERNEL);
 
-        info->kernel_bootmodule = mod;
-        info->initrd_bootmodule = boot_module_find_by_kind(BOOTMOD_RAMDISK);
+        info->kernel = mod;
+        info->initrd = boot_module_find_by_kind(BOOTMOD_RAMDISK);
 
         cmd = boot_cmdline_find_by_kind(BOOTMOD_KERNEL);
         if ( cmd )
@@ -162,7 +162,7 @@ int __init kernel_probe(struct kernel_info *info,
                 dt_get_range(&val, node, &kernel_addr, &size);
                 mod = boot_module_find_by_addr_and_kind(
                         BOOTMOD_KERNEL, kernel_addr);
-                info->kernel_bootmodule = mod;
+                info->kernel = mod;
             }
             else if ( dt_device_is_compatible(node, "multiboot,ramdisk") )
             {
@@ -171,7 +171,7 @@ int __init kernel_probe(struct kernel_info *info,
 
                 val = dt_get_property(node, "reg", &len);
                 dt_get_range(&val, node, &initrd_addr, &size);
-                info->initrd_bootmodule = boot_module_find_by_addr_and_kind(
+                info->initrd = boot_module_find_by_addr_and_kind(
                         BOOTMOD_RAMDISK, initrd_addr);
             }
             else if ( dt_device_is_compatible(node, "multiboot,device-tree") )
@@ -183,7 +183,7 @@ int __init kernel_probe(struct kernel_info *info,
                 if ( val == NULL )
                     continue;
                 dt_get_range(&val, node, &dtb_addr, &size);
-                info->dtb_bootmodule = boot_module_find_by_addr_and_kind(
+                info->dtb = boot_module_find_by_addr_and_kind(
                         BOOTMOD_GUEST_DTB, dtb_addr);
             }
             else
@@ -201,10 +201,10 @@ int __init kernel_probe(struct kernel_info *info,
     }
 
     printk("Loading %pd kernel from boot module @ %"PRIpaddr"\n",
-           info->d, info->kernel_bootmodule->start);
-    if ( info->initrd_bootmodule )
+           info->d, info->kernel->start);
+    if ( info->initrd )
         printk("Loading ramdisk from boot module @ %"PRIpaddr"\n",
-               info->initrd_bootmodule->start);
+               info->initrd->start);
 
     /*
      * uImage isn't really used nowadays thereby leave kernel_uimage_probe()
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index ff40f3078e..236b456dd2 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -23,7 +23,7 @@ typedef enum {
     BOOTMOD_GUEST_DTB,
     BOOTMOD_MICROCODE,
     BOOTMOD_UNKNOWN
-}  bootmodule_kind;
+}  boot_module_kind;
 
 enum membank_type {
     /*
@@ -103,8 +103,8 @@ struct shared_meminfo {
  * initrd to be compatible with all versions of the multiboot spec.
  */
 #define BOOTMOD_MAX_CMDLINE 1024
-struct bootmodule {
-    bootmodule_kind kind;
+struct boot_module {
+    boot_module_kind kind;
     bool domU;
     paddr_t start;
     paddr_t size;
@@ -113,16 +113,16 @@ struct bootmodule {
 /* DT_MAX_NAME is the node name max length according the DT spec */
 #define DT_MAX_NAME 41
 struct bootcmdline {
-    bootmodule_kind kind;
+    boot_module_kind kind;
     bool domU;
     paddr_t start;
     char dt_name[DT_MAX_NAME];
     char cmdline[BOOTMOD_MAX_CMDLINE];
 };
 
-struct bootmodules {
+struct boot_modules {
     int nr_mods;
-    struct bootmodule module[MAX_MODULES];
+    struct boot_module module[MAX_MODULES];
 };
 
 struct bootcmdlines {
@@ -134,7 +134,7 @@ struct bootinfo {
     struct meminfo mem;
     /* The reserved regions are only used when booting using Device-Tree */
     struct meminfo reserved_mem;
-    struct bootmodules modules;
+    struct boot_modules modules;
     struct bootcmdlines cmdlines;
 #ifdef CONFIG_ACPI
     struct meminfo acpi;
@@ -176,16 +176,16 @@ bool check_reserved_regions_overlap(paddr_t region_start,
                                     paddr_t region_size,
                                     bool allow_memreserve_overlap);
 
-struct bootmodule *add_boot_module(bootmodule_kind kind,
+struct boot_module *add_boot_module(boot_module_kind kind,
                                    paddr_t start, paddr_t size, bool domU);
-struct bootmodule *boot_module_find_by_kind(bootmodule_kind kind);
-struct bootmodule * boot_module_find_by_addr_and_kind(bootmodule_kind kind,
+struct boot_module *boot_module_find_by_kind(boot_module_kind kind);
+struct boot_module * boot_module_find_by_addr_and_kind(boot_module_kind kind,
                                                              paddr_t start);
 void add_boot_cmdline(const char *name, const char *cmdline,
-                      bootmodule_kind kind, paddr_t start, bool domU);
-struct bootcmdline *boot_cmdline_find_by_kind(bootmodule_kind kind);
+                      boot_module_kind kind, paddr_t start, bool domU);
+struct bootcmdline *boot_cmdline_find_by_kind(boot_module_kind kind);
 struct bootcmdline * boot_cmdline_find_by_name(const char *name);
-const char *boot_module_kind_as_string(bootmodule_kind kind);
+const char *boot_module_kind_as_string(boot_module_kind kind);
 
 void populate_boot_allocator(void);
 
diff --git a/xen/include/xen/fdt-kernel.h b/xen/include/xen/fdt-kernel.h
index 1939c3ebf7..12a0b42d17 100644
--- a/xen/include/xen/fdt-kernel.h
+++ b/xen/include/xen/fdt-kernel.h
@@ -34,7 +34,7 @@ struct kernel_info {
     paddr_t gnttab_size;
 
     /* boot blob load addresses */
-    const struct bootmodule *kernel_bootmodule, *initrd_bootmodule, *dtb_bootmodule;
+    const struct boot_module *kernel, *initrd, *dtb;
     const char* cmdline;
     paddr_t dtb_paddr;
     paddr_t initrd_paddr;
@@ -121,7 +121,7 @@ int kernel_probe(struct kernel_info *info, const struct dt_device_node *domain);
  */
 void kernel_load(struct kernel_info *info);
 
-int kernel_decompress(struct bootmodule *mod, uint32_t offset);
+int kernel_decompress(struct boot_module *mod, uint32_t offset);
 
 int kernel_zimage_probe(struct kernel_info *info, paddr_t addr, paddr_t size);
 
@@ -130,8 +130,7 @@ int kernel_zimage_probe(struct kernel_info *info, paddr_t addr, paddr_t size);
  * call here just for compatability with Arm code.
  */
 #ifdef CONFIG_ARM
-struct bootmodule;
-int kernel_uimage_probe(struct kernel_info *info, struct bootmodule *mod);
+int kernel_uimage_probe(struct kernel_info *info, struct boot_module *mod);
 #endif
 
 #endif /* __XEN_FDT_KERNEL_H__ */
diff --git a/xen/xsm/xsm_policy.c b/xen/xsm/xsm_policy.c
index 7f70d860bd..1f88b4fc5a 100644
--- a/xen/xsm/xsm_policy.c
+++ b/xen/xsm/xsm_policy.c
@@ -68,7 +68,7 @@ int __init xsm_multiboot_policy_init(
 #ifdef CONFIG_HAS_DEVICE_TREE
 int __init xsm_dt_policy_init(void **policy_buffer, size_t *policy_size)
 {
-    struct bootmodule *mod = boot_module_find_by_kind(BOOTMOD_XSM);
+    struct boot_module *mod = boot_module_find_by_kind(BOOTMOD_XSM);
     paddr_t paddr, len;
 
     if ( !mod || !mod->size )
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 20 18:30:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 18:30:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021083.1397143 (Exim 4.92)
	(envelope-from )
	id 1uSgV8-00070H-Aq; Fri, 20 Jun 2025 18:30:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021083.1397143; Fri, 20 Jun 2025 18:30: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 1uSgV8-000705-85; Fri, 20 Jun 2025 18:30:10 +0000
Received: by outflank-mailman (input) for mailman id 1021083;
 Fri, 20 Jun 2025 18:30: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 1uSgV6-000575-Df
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 18:30:08 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20621.outbound.protection.outlook.com
 [2a01:111:f403:2009::621])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 95dd5fe3-4e04-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 20:30:06 +0200 (CEST)
Received: from BN9P220CA0025.NAMP220.PROD.OUTLOOK.COM (2603:10b6:408:13e::30)
 by SN7PR12MB7955.namprd12.prod.outlook.com (2603:10b6:806:34d::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.35; Fri, 20 Jun
 2025 18:30:01 +0000
Received: from BN1PEPF00006000.namprd05.prod.outlook.com
 (2603:10b6:408:13e:cafe::d0) by BN9P220CA0025.outlook.office365.com
 (2603:10b6:408:13e::30) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8857.25 via Frontend Transport; Fri,
 20 Jun 2025 18:30:01 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN1PEPF00006000.mail.protection.outlook.com (10.167.243.232) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8857.21 via Frontend Transport; Fri, 20 Jun 2025 18:30:01 +0000
Received: from xcbagarciav01.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; Fri, 20 Jun
 2025 13:29:53 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 95dd5fe3-4e04-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=fTRGKuLA8nGR+TJdFyb+LASmshns7tAbneqgXtmoFFDRWCPjKs+lwEWeTJrE4q+rwecsghkOsbEdZ93d0iB9H7fAb3UbmFxinmXokZXxi0NbkHenVIaW8lSs7Smc2RKUuEvC1a4R6pHBqaNkeWLp5C6V6wJkg7tHfmMOHCEeSEDkPLC/pDRi4VIc9L/FT1w6D+xojTE5T/vlhmGabqljjxKcVMflNgpGQ1sYVbBYFo/bkosZfxm9wvVlMfu15Ax2V8lSXVAc37agE1C/5+3RDeRST113LLH5LiHWKjhdcBhKUSO6sCtGX8RTplVnPVrdP+bjWgjZn2o6B82Uc8vcbA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=JJP/7zFzGccQJ1DD4IZ+lMNNJUGQ+1vPwz1sxHunn6s=;
 b=R+MS2htwA7ktuplGmMEsz5Czs1k3/ZiNOjsSa3hjMrmT/6ke1bz7GKzdCo2GPWDq4F6VPD6LUSOENLsD8vgRwf0PhEF3ySV9VqqFIj+OESpUcaD6TAOKvTMxcb+YVB5MI3v8WKC0o4yoHJWkywHBmVKZEtOC2Pdx15olEuw4v8gIjeA9dU7U6jRl1lX+u62zeyVRLpU4/K8YiSSFJv2U9Ce4IPtmaSB3jZpVezx5OfDQgZOIxO85KbYpOfz30NVQODvOrmMrMMBbWCULAPs2CLsLZ5+T7nes4HJKjWwWZwpRL8GU5mef2Qw+js5UnWDl8O/wyHPI2CdtcWP5Wwyqcw==
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=JJP/7zFzGccQJ1DD4IZ+lMNNJUGQ+1vPwz1sxHunn6s=;
 b=isOpt0ZU4dINwrGb19QntkP0bIJwxcOLKRP0bSDfSpilzMnx1zsxQ7BOsXXhq/Ac3CxpPIe66La9SL0tqnwRCb0mnplJImz/KGNOH/jshQV2An7y9nqPu8J6nIprHaeI3LPi9oVxOywnZWRR8EbRXHoii47mkvij8ovMMdUnpXc=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Stefano
 Stabellini" , Julien Grall ,
	"Bertrand Marquis" , Michal Orzel
	, "Daniel P. Smith" 
Subject: [PATCH v4 03/12] x86: Replace arch-specific boot_module with common one
Date: Fri, 20 Jun 2025 20:28:49 +0200
Message-ID: <20250620182859.23378-4-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250620182859.23378-1-agarciav@amd.com>
References: <20250620182859.23378-1-agarciav@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: BN1PEPF00006000:EE_|SN7PR12MB7955:EE_
X-MS-Office365-Filtering-Correlation-Id: 93289895-068c-4a1c-f5ce-08ddb028782e
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:
	=?us-ascii?Q?88fty3px2g/A3fcoUS2CTQQtrm8hGnakXUYvd2/fHfEWu01vY0BrqqTMXzW2?=
 =?us-ascii?Q?EEVYJBVhxzz1nHyY2LJNYUaS/Q4YQsWTTlr7FbQ/dhjPNu2zCruN2/2g68QU?=
 =?us-ascii?Q?IkohVM0ZHVsWBlRIf5WZNdN8THj/IeMAv5PhOOejZDi/JTGcKdVzeOEmyd/u?=
 =?us-ascii?Q?eL5vGhqkN0oI3BwN6VIO9K8c3kDI+xrlJKedteYYstxkDQaDy+GQIoHBJukM?=
 =?us-ascii?Q?J17aguOv6MOCEDtNKurWhUlU+llH5LoVZmHd1MoMVO3i5UNEOhb49jlJ+/Gn?=
 =?us-ascii?Q?c2lOpQAefwCJYJg9Ab6IOwTSR2etHhagRFYMzV8F+oFucZrI1Yi6RixWE1+e?=
 =?us-ascii?Q?XeUuc6lqvkxmYVE8aCrFRPjFNYurgFQ3g3CFsvmc+SHBkbDtruJ3nvrca4He?=
 =?us-ascii?Q?qJzFSk+EYQFAReH8CBJ+XiQjv+hoq//jhHvqkxUO940N9R5oiqZPU2hxQ4gc?=
 =?us-ascii?Q?WjqU4jphH6EMxHLBIKO0fwAkWSKHRDC9RD1FL57kvg+PGlKN8Q09Va8UN/aY?=
 =?us-ascii?Q?q/jCsbBB1z54J5b7sMAJTd9Tv3wMWKQEznF68X/A8J9CMiXJYX3iIZ7kmJ98?=
 =?us-ascii?Q?zr97mPHARrbzXNRIkMdJEuBkZzt9bLEjg/ysvBKvuIYHlJ3O2zImLneLoJZv?=
 =?us-ascii?Q?POscwEeE41LhlZSCgS+yx8kmMoYnR1bU2m43afSZil8KC8YqkYUWvibpqa5T?=
 =?us-ascii?Q?RI+FIvvqkfJZZWF624/dXogAAsdd1KBGbhsv8Gnvmtqi1/Es/7zLfVyVXJIQ?=
 =?us-ascii?Q?Fp0HIUMsn3nIjnX6s6VTvPWTk0Mm2uggQwSA2pGVR55kMixjlbXCU6QObWWs?=
 =?us-ascii?Q?ZAOM1ybXBTOwRaHLg+/V5Ou1yaAsj2198sckglHSEqYPxY4L/JpquB3WEOpK?=
 =?us-ascii?Q?2iiSNp2WZe4GcXBC7nKV1SGMb2YBpv2AEVR7Fu6tHJhHd6i92b3lWrScltBw?=
 =?us-ascii?Q?4yYremGVhSNlOlH7TIZb8sIrYTYuvhQmQvMO+tKReqIueOIZs4qZL93k4TYU?=
 =?us-ascii?Q?oQPvnJ5Cb1tCnQOqL1qMDr0N83ujQbV9mHbCJW6YwaoQ8EkHHwAqkZ/puZrq?=
 =?us-ascii?Q?Z9r68z4D7OkX637D5YKa5K6IGI2Ay+pcipXKcneDWEDk9bD+F2uUhwWcK5ZL?=
 =?us-ascii?Q?YH9YGLq+0GvfL9Oo3xYwEtvUL4kRQ8OrLDBSu0iYcY9cF8D2SBOVes+ghD5T?=
 =?us-ascii?Q?xH8f+AtS07/jiz+qrJxvdzkf07bOOLnwXAUQkA0MUFgITpI5+zEXuao/vuJf?=
 =?us-ascii?Q?EkZ2zjK5sNWaL2fAPfu5Ix3ET8dUqDusgdy9EZ9W1cRhnvum+7MJqvANNRlc?=
 =?us-ascii?Q?QhJm52mggg0IqRBABJuuNxdNQ+mLglc+PfvmkItjnldTa18dOqIqQ5qY7VOk?=
 =?us-ascii?Q?LwGKWV7B4NlNt7UwHvdOq796StTLMDw5uxz4QSHka9g738di0rQ8cvkkJyn+?=
 =?us-ascii?Q?9FQxDXRZ0J7X4btqYTKnJzgTaAL5xdTH8VgYsRyZPuQXUz+D+txPchOs/kgP?=
 =?us-ascii?Q?++C6TTYUMWG8iZlXyXQsCzjloMJmBsuXzXWA?=
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)(82310400026)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jun 2025 18:30:01.7572
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 93289895-068c-4a1c-f5ce-08ddb028782e
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:
	BN1PEPF00006000.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7955

These types resemble each other very closely in layout and intent,
and with "struct boot_module" already in common code it makes perfect
sense to merge them. In order to do so, add an arch-specific area for
x86-specific tidbits, and rename identical fields with conflicting
names.

No functional change intended.

Signed-off-by: Alejandro Vallejo 
---
 xen/arch/x86/cpu/microcode/core.c   |  7 ++--
 xen/arch/x86/hvm/dom0_build.c       |  6 ++--
 xen/arch/x86/include/asm/bootfdt.h  | 50 ++++++++++++++++++++++++++
 xen/arch/x86/include/asm/bootinfo.h | 56 +++--------------------------
 xen/arch/x86/pv/dom0_build.c        |  4 +--
 xen/arch/x86/setup.c                | 43 +++++++++++-----------
 xen/include/xen/bootfdt.h           |  8 +++++
 xen/xsm/xsm_policy.c                |  2 +-
 8 files changed, 93 insertions(+), 83 deletions(-)
 create mode 100644 xen/arch/x86/include/asm/bootfdt.h

diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c
index 34a94cd25b..816e9bfe40 100644
--- a/xen/arch/x86/cpu/microcode/core.c
+++ b/xen/arch/x86/cpu/microcode/core.c
@@ -764,8 +764,7 @@ static int __init early_microcode_load(struct boot_info *bi)
             struct cpio_data cd;
 
             /* Search anything unclaimed or likely to be a CPIO archive. */
-            if ( bm->type != BOOTMOD_UNKNOWN &&
-                 bm->type != BOOTMOD_RAMDISK )
+            if ( bm->kind != BOOTMOD_UNKNOWN && bm->kind != BOOTMOD_RAMDISK )
                 continue;
 
             size = bm->size;
@@ -815,12 +814,12 @@ static int __init early_microcode_load(struct boot_info *bi)
             return -ENODEV;
         }
 
-        if ( bi->mods[idx].type != BOOTMOD_UNKNOWN )
+        if ( bi->mods[idx].kind != BOOTMOD_UNKNOWN )
         {
             printk(XENLOG_WARNING "Microcode: Chosen module %d already used\n", idx);
             return -ENODEV;
         }
-        bi->mods[idx].type = BOOTMOD_MICROCODE;
+        bi->mods[idx].kind = BOOTMOD_MICROCODE;
 
         size = bi->mods[idx].size;
         data = bootstrap_map_bm(&bi->mods[idx]);
diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index a038e58c11..2bb8ef355c 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -650,7 +650,7 @@ static int __init pvh_load_kernel(
     struct boot_module *image = bd->kernel;
     struct boot_module *initrd = bd->module;
     void *image_base = bootstrap_map_bm(image);
-    void *image_start = image_base + image->headroom;
+    void *image_start = image_base + image->arch.headroom;
     unsigned long image_len = image->size;
     unsigned long initrd_len = initrd ? initrd->size : 0;
     size_t cmdline_len = bd->cmdline ? strlen(bd->cmdline) + 1 : 0;
@@ -721,9 +721,9 @@ static int __init pvh_load_kernel(
     {
         size_t initrd_space = elf_round_up(&elf, initrd_len);
 
-        if ( initrd->cmdline_pa )
+        if ( initrd->arch.cmdline_pa )
         {
-            initrd_cmdline = __va(initrd->cmdline_pa);
+            initrd_cmdline = __va(initrd->arch.cmdline_pa);
             if ( !*initrd_cmdline )
                 initrd_cmdline = NULL;
         }
diff --git a/xen/arch/x86/include/asm/bootfdt.h b/xen/arch/x86/include/asm/bootfdt.h
new file mode 100644
index 0000000000..a4c4bf30b9
--- /dev/null
+++ b/xen/arch/x86/include/asm/bootfdt.h
@@ -0,0 +1,50 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef X86_BOOTFDT_H
+#define X86_BOOTFDT_H
+
+#include 
+
+struct arch_boot_module
+{
+    /*
+     * Module State Flags:
+     *   relocated:   indicates module has been relocated in memory.
+     *   released:    indicates module's pages have been freed.
+     */
+    bool relocated:1;
+    bool released:1;
+
+    /*
+     * A boot module may need decompressing by Xen.  Headroom is an estimate of
+     * the additional space required to decompress the module.
+     *
+     * Headroom is accounted for at the start of the module.  Decompressing is
+     * done in-place with input=start, output=start-headroom, expecting the
+     * pointers to become equal (give or take some rounding) when decompression
+     * is complete.
+     *
+     * Memory layout at boot:
+     *
+     *               start ----+
+     *                         v
+     *   |<-----headroom------>|<------size------->|
+     *                         +-------------------+
+     *                         | Compressed Module |
+     *   +---------------------+-------------------+
+     *   |           Decompressed Module           |
+     *   +-----------------------------------------+
+     */
+    unsigned long headroom;
+    paddr_t cmdline_pa;
+};
+
+#endif /* X86_BOOTFDT_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/bootinfo.h b/xen/arch/x86/include/asm/bootinfo.h
index 3afc214c17..d33b100e04 100644
--- a/xen/arch/x86/include/asm/bootinfo.h
+++ b/xen/arch/x86/include/asm/bootinfo.h
@@ -8,6 +8,7 @@
 #ifndef X86_BOOTINFO_H
 #define X86_BOOTINFO_H
 
+#include 
 #include 
 #include 
 #include 
@@ -19,55 +20,6 @@
 /* Max number of boot domains that Xen can construct */
 #define MAX_NR_BOOTDOMS 1
 
-/* Boot module binary type / purpose */
-enum bootmod_type {
-    BOOTMOD_UNKNOWN,
-    BOOTMOD_XEN,
-    BOOTMOD_KERNEL,
-    BOOTMOD_RAMDISK,
-    BOOTMOD_MICROCODE,
-    BOOTMOD_XSM_POLICY,
-};
-
-struct boot_module {
-    enum bootmod_type type;
-
-    /*
-     * Module State Flags:
-     *   relocated: indicates module has been relocated in memory.
-     *   released:  indicates module's pages have been freed.
-     */
-    bool relocated:1;
-    bool released:1;
-
-    /*
-     * A boot module may need decompressing by Xen.  Headroom is an estimate of
-     * the additional space required to decompress the module.
-     *
-     * Headroom is accounted for at the start of the module.  Decompressing is
-     * done in-place with input=start, output=start-headroom, expecting the
-     * pointers to become equal (give or take some rounding) when decompression
-     * is complete.
-     *
-     * Memory layout at boot:
-     *
-     *               start ----+
-     *                         v
-     *   |<-----headroom------>|<------size------->|
-     *                         +-------------------+
-     *                         | Compressed Module |
-     *   +---------------------+-------------------+
-     *   |           Decompressed Module           |
-     *   +-----------------------------------------+
-     */
-    unsigned long headroom;
-
-    paddr_t cmdline_pa;
-
-    paddr_t start;
-    size_t size;
-};
-
 /*
  * Xen internal representation of information provided by the
  * bootloader/environment, or derived from the information.
@@ -94,16 +46,16 @@ struct boot_info {
  *      Failure - a value greater than MAX_NR_BOOTMODS
  */
 static inline unsigned int __init next_boot_module_index(
-    const struct boot_info *bi, enum bootmod_type t, unsigned int start)
+    const struct boot_info *bi, boot_module_kind k, unsigned int start)
 {
     unsigned int i;
 
-    if ( t == BOOTMOD_XEN )
+    if ( k == BOOTMOD_XEN )
         return bi->nr_modules;
 
     for ( i = start; i < bi->nr_modules; i++ )
     {
-        if ( bi->mods[i].type == t )
+        if ( bi->mods[i].kind == k )
             return i;
     }
 
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index e1b78d47c2..a4b5362357 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -422,7 +422,7 @@ static int __init dom0_construct(const struct boot_domain *bd)
 
     image_base = bootstrap_map_bm(image);
     image_len = image->size;
-    image_start = image_base + image->headroom;
+    image_start = image_base + image->arch.headroom;
 
     d->max_pages = ~0U;
 
@@ -659,7 +659,7 @@ static int __init dom0_construct(const struct boot_domain *bd)
              * pages. Tell the boot_module handling that we've freed it, so the
              * memory is left alone.
              */
-            initrd->released = true;
+            initrd->arch.released = true;
         }
 
         iommu_memory_setup(d, "initrd", mfn_to_page(_mfn(initrd_mfn)),
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index f32efa7c60..4f34bbe688 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -303,7 +303,7 @@ struct boot_info __initdata xen_boot_info = {
      *
      * The extra entry exists to be able to add the Xen image as a module.
      */
-    .mods = { [0 ... MAX_NR_BOOTMODS] = { .type = BOOTMOD_UNKNOWN } },
+    .mods = { [0 ... MAX_NR_BOOTMODS] = { .kind = BOOTMOD_UNKNOWN } },
 };
 
 static struct boot_info *__init multiboot_fill_boot_info(
@@ -338,7 +338,7 @@ static struct boot_info *__init multiboot_fill_boot_info(
      */
     for ( i = 0; i < MAX_NR_BOOTMODS && i < bi->nr_modules; i++ )
     {
-        bi->mods[i].cmdline_pa = mods[i].string;
+        bi->mods[i].arch.cmdline_pa = mods[i].string;
 
         if ( efi_enabled(EFI_LOADER) )
         {
@@ -361,7 +361,7 @@ 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;
+    bi->mods[i].kind = BOOTMOD_XEN;
 
     return bi;
 }
@@ -388,11 +388,11 @@ unsigned long __init initial_images_nrpages(nodeid_t node)
 
 void __init release_boot_module(struct boot_module *bm)
 {
-    ASSERT(!bm->released);
+    ASSERT(!bm->arch.released);
 
     init_domheap_pages(bm->start, bm->start + PAGE_ALIGN(bm->size));
 
-    bm->released = true;
+    bm->arch.released = true;
 }
 
 void __init free_boot_modules(void)
@@ -402,7 +402,7 @@ void __init free_boot_modules(void)
 
     for ( i = 0; i < bi->nr_modules; ++i )
     {
-        if ( bi->mods[i].released )
+        if ( bi->mods[i].arch.released )
             continue;
 
         release_boot_module(&bi->mods[i]);
@@ -997,8 +997,8 @@ static size_t __init domain_cmdline_size(const struct boot_info *bi,
 {
     size_t s = 0;
 
-    if ( bd->kernel->cmdline_pa )
-        s += strlen(__va(bd->kernel->cmdline_pa));
+    if ( bd->kernel->arch.cmdline_pa )
+        s += strlen(__va(bd->kernel->arch.cmdline_pa));
 
     if ( bi->kextra )
         s += strlen(bi->kextra);
@@ -1062,9 +1062,10 @@ 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->arch.cmdline_pa )
             strlcpy(cmdline,
-                    cmdline_cook(__va(bd->kernel->cmdline_pa), bi->loader),
+                    cmdline_cook(__va(bd->kernel->arch.cmdline_pa),
+                                 bi->loader),
                     cmdline_size);
 
         if ( bi->kextra )
@@ -1086,7 +1087,7 @@ static struct domain *__init create_dom0(struct boot_info *bi)
             strlcat(cmdline, " acpi=", cmdline_size);
             strlcat(cmdline, acpi_param, cmdline_size);
         }
-        bd->kernel->cmdline_pa = 0;
+        bd->kernel->arch.cmdline_pa = 0;
         bd->cmdline = cmdline;
     }
 
@@ -1299,7 +1300,7 @@ void asmlinkage __init noreturn __start_xen(void)
     }
 
     /* Dom0 kernel is always first */
-    bi->mods[0].type = BOOTMOD_KERNEL;
+    bi->mods[0].kind = BOOTMOD_KERNEL;
     bi->domains[0].kernel = &bi->mods[0];
 
     if ( pvh_boot )
@@ -1483,7 +1484,7 @@ void asmlinkage __init noreturn __start_xen(void)
         xen->size  = __2M_rwdata_end - _stext;
     }
 
-    bi->mods[0].headroom =
+    bi->mods[0].arch.headroom =
         bzimage_headroom(bootstrap_map_bm(&bi->mods[0]), bi->mods[0].size);
     bootstrap_unmap();
 
@@ -1565,9 +1566,9 @@ void asmlinkage __init noreturn __start_xen(void)
         for ( j = bi->nr_modules - 1; j >= 0; j-- )
         {
             struct boot_module *bm = &bi->mods[j];
-            unsigned long size = PAGE_ALIGN(bm->headroom + bm->size);
+            unsigned long size = PAGE_ALIGN(bm->arch.headroom + bm->size);
 
-            if ( bm->relocated )
+            if ( bm->arch.relocated )
                 continue;
 
             /* Don't overlap with other modules (or Xen itself). */
@@ -1577,12 +1578,12 @@ void asmlinkage __init noreturn __start_xen(void)
             if ( highmem_start && end > highmem_start )
                 continue;
 
-            if ( s < end && (bm->headroom || (end - size) > bm->start) )
+            if ( s < end && (bm->arch.headroom || (end - size) > bm->start) )
             {
-                move_memory(end - size + bm->headroom, bm->start, bm->size);
+                move_memory(end - size + bm->arch.headroom, bm->start, bm->size);
                 bm->start = (end - size);
-                bm->size += bm->headroom;
-                bm->relocated = true;
+                bm->size += bm->arch.headroom;
+                bm->arch.relocated = true;
             }
         }
 
@@ -1608,7 +1609,7 @@ void asmlinkage __init noreturn __start_xen(void)
 #endif
     }
 
-    if ( bi->mods[0].headroom && !bi->mods[0].relocated )
+    if ( bi->mods[0].arch.headroom && !bi->mods[0].arch.relocated )
         panic("Not enough memory to relocate the dom0 kernel image\n");
     for ( i = 0; i < bi->nr_modules; ++i )
     {
@@ -2166,7 +2167,7 @@ void asmlinkage __init noreturn __start_xen(void)
     initrdidx = first_boot_module_index(bi, BOOTMOD_UNKNOWN);
     if ( initrdidx < MAX_NR_BOOTMODS )
     {
-        bi->mods[initrdidx].type = BOOTMOD_RAMDISK;
+        bi->mods[initrdidx].kind = BOOTMOD_RAMDISK;
         bi->domains[0].module = &bi->mods[initrdidx];
         if ( first_boot_module_index(bi, BOOTMOD_UNKNOWN) < MAX_NR_BOOTMODS )
             printk(XENLOG_WARNING
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index 236b456dd2..854e7f1ed9 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -7,6 +7,10 @@
 #include 
 #include 
 
+#if __has_include()
+#include 
+#endif
+
 #define MIN_FDT_ALIGN 8
 
 #define NR_MEM_BANKS 256
@@ -108,6 +112,10 @@ struct boot_module {
     bool domU;
     paddr_t start;
     paddr_t size;
+
+#if __has_include()
+    struct arch_boot_module arch;
+#endif
 };
 
 /* DT_MAX_NAME is the node name max length according the DT spec */
diff --git a/xen/xsm/xsm_policy.c b/xen/xsm/xsm_policy.c
index 1f88b4fc5a..1b4030edb4 100644
--- a/xen/xsm/xsm_policy.c
+++ b/xen/xsm/xsm_policy.c
@@ -53,7 +53,7 @@ int __init xsm_multiboot_policy_init(
             printk("Policy len %#lx, start at %p.\n",
                    _policy_len,_policy_start);
 
-            bm->type = BOOTMOD_XSM_POLICY;
+            bm->kind = BOOTMOD_XSM;
             break;
 
         }
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 20 18:30:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 18:30:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021092.1397153 (Exim 4.92)
	(envelope-from )
	id 1uSgVG-0007Te-KQ; Fri, 20 Jun 2025 18:30:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021092.1397153; Fri, 20 Jun 2025 18: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 1uSgVG-0007TV-Gm; Fri, 20 Jun 2025 18:30:18 +0000
Received: by outflank-mailman (input) for mailman id 1021092;
 Fri, 20 Jun 2025 18:30: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 1uSgVE-00057I-PU
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 18:30:16 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20624.outbound.protection.outlook.com
 [2a01:111:f403:2416::624])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9b394206-4e04-11f0-a30e-13f23c93f187;
 Fri, 20 Jun 2025 20:30:15 +0200 (CEST)
Received: from BN8PR03CA0024.namprd03.prod.outlook.com (2603:10b6:408:94::37)
 by PH7PR12MB6393.namprd12.prod.outlook.com (2603:10b6:510:1ff::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.38; Fri, 20 Jun
 2025 18:30:11 +0000
Received: from BN1PEPF00006002.namprd05.prod.outlook.com
 (2603:10b6:408:94:cafe::9) by BN8PR03CA0024.outlook.office365.com
 (2603:10b6:408:94::37) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8857.25 via Frontend Transport; Fri,
 20 Jun 2025 18:30:11 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN1PEPF00006002.mail.protection.outlook.com (10.167.243.234) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8857.21 via Frontend Transport; Fri, 20 Jun 2025 18:30:10 +0000
Received: from xcbagarciav01.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; Fri, 20 Jun
 2025 13:30:01 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9b394206-4e04-11f0-a30e-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=LKqbXYmxlwYOpv+aef1UraqpyNZK87VJ4V8I+7uCGlOH4+KWCy8FlosWg/BlYE7abA5WujSacOjVa4+cM3FseZWYZJfp3P2PR7f7gwFeo8HnoxpUEhTzBU4GgVl9lQDAA+SSIqTBWMQwLVUHYmk4fnWY1KzFX0Y4VEgKG71qgMDkqRVBHFyioaEweHyxgtcifWJKjXtO0MVBsRsjUhs0WrBnLC/WTC4vA6kVZej2wdzdbXw04xsTFP8MMD6WLsVZ0ZLfVbQsds5KSmCsVg3gE5rlTocFJwTopI+3FfwDG7drUHdMxqCTiR/2fFnw5y+G4T34tWrEtc5PNDgxiOYHdw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ud/TQIZp2ue4dBTHWbX6XL/bQtyUjvSVs/0Ir1+e1is=;
 b=yvRRsqEgA5MkNs9cMizPVRQnHCzDdBP8dCpzMt0MnIblVGVai89n1k2J1wC4z8W3gJa2xNM0AAaUqDiMbXa4QM8E9pO5T7pIr5SoR8r9bOQVf/t9LrFuLq9MoDRAeEAf8dHni82H6KiL7hT95efF4q5ud7Q8gzryS71ya6Df1mNTh/OrppONSlo8YJMRjlI09ROw56PzsDA/5SW3aeG6YpCjubElauR8zWZVrd+HB06G0QghZoL+yjkOG63/AVgWh7LlcXBzG5rqDMKmsFNB7LNwcUTIRqFCLBV3GQ0WVrDZUGPta2S+bEvIXKhM+nlfY0v5flpBgqx72jjRKUmLgQ==
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=ud/TQIZp2ue4dBTHWbX6XL/bQtyUjvSVs/0Ir1+e1is=;
 b=I5mCXNhl6PdASNCcc2dLD+jznwKbGMa3B8krJFwrVdhq3y9N7KG2FjOT3d5SclNgPC5DH/9zsjtlfrpFahQbR033G9ioOEplxdSQX9JEmlGMehsBk0ZWga7ZkenUVHB/FUA5qZSRvoOHWwPavlGTKwkBnIC2ZMAxaoU7VGmNyyw=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , 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 v4 04/12] xen: Refactor kernel_info to have a header like boot_domain
Date: Fri, 20 Jun 2025 20:28:50 +0200
Message-ID: <20250620182859.23378-5-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250620182859.23378-1-agarciav@amd.com>
References: <20250620182859.23378-1-agarciav@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: BN1PEPF00006002:EE_|PH7PR12MB6393:EE_
X-MS-Office365-Filtering-Correlation-Id: 29b0441e-caff-4b66-8a63-08ddb0287d7c
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?OwwH5J7/PeCQ5KieHIarabJKIWRl8qIrJ/Hqf6qIYoGv5i86CM9NnwvA0Bwx?=
 =?us-ascii?Q?76ifsJf53M2YgvCDjk6WntxYZ52jrj7t/jRckpQqnzMwd8zhyYbFcxdTwiGZ?=
 =?us-ascii?Q?Dx2F5hbb/PdCW3jpggsvJGySX36YnvUSp0CqrqTzU1pFRV5WKx/XIPh7zt3R?=
 =?us-ascii?Q?T45g8cqG9f0h9WVbapY5Cf5xKahPgRa0fV0hiHQyi4Wto+O8CYI28BPHy3/L?=
 =?us-ascii?Q?pd3lv9I7NcWXhxXSXwmN0p3R3Fho32f8edOYOA5Ln3pLBH3jtQfuZN/cuhDx?=
 =?us-ascii?Q?qI6BZ32oBHvuYyn28iGGqtELoOWXfNBjb9XB7D3SJQ0g6iR0DqHnaaF6q3Kl?=
 =?us-ascii?Q?x9Bjg+HoR1P29HQS8RQn/fQ+5kG/dVl6VGVbCu5dXRbeU+nDUU2kIryoYGG4?=
 =?us-ascii?Q?eXy9DSPx1IX+iTzszjarfYQFcTVNXIH0imIW+urtdrarxuJkzVQKxwCPmWAi?=
 =?us-ascii?Q?lElH/yqSKJ/rTbnaImrRgwiNsTgwj6amVIGyUXA91y7UcTc+U2uxiOFxOpjP?=
 =?us-ascii?Q?gpn8nmy0TYRyQFFzH5ZkkFAWEj1+Qls76MJft8h6DobbUhDOuRNs1oim6RFG?=
 =?us-ascii?Q?+d6c0yelB0vHygZSSIGOqmCiZoXNxRWzDKX8DE1U+WSsmReZRK7AVB2Tbut9?=
 =?us-ascii?Q?m0IHLJPzneYEls8LUsCpPNNCdrrQXEHhsC6Trih3tCOMl41ABLWVjeFMcFbU?=
 =?us-ascii?Q?2JpzIWaDcVWa41Nbp2Ec0V03H0Wx5MqGrkhi/EITN7W2nanpQT3OpHH6paca?=
 =?us-ascii?Q?uBLJctYvfsMEYkarxT3z+GnLSqntSvwfQP8vGG7GsrQ3LG0xUlgDd8CVZ3gi?=
 =?us-ascii?Q?9Fk5jd/QySpbkv8zEqUyFg/AjZrdP7l7fZI351Nv/nqDMEgL8R3k5TOe/6h0?=
 =?us-ascii?Q?lKnY+RdIeDoZmqzvci3E5iBGo5qRV3B9YDtyHnXhw5T06T7p2ku64QgQqBL9?=
 =?us-ascii?Q?ug4K0UZ9wcA5TiE1n0RMHATehW8NHydzYhP3LiIGqSo7ETRWLeXl857+PyJ5?=
 =?us-ascii?Q?wUZNlN0TLife9NJCYMEbLcvSatjPd81HBPW1TH+fj323rCP4qgMYqgfQKRXM?=
 =?us-ascii?Q?zF5QAYV3cmaE0Vtcg9ypyzbptABd2ZN7YOSX6xsEtw5fyAl4y7f+dGBcV46y?=
 =?us-ascii?Q?JJD/ucQ467xe7b2C02cWdR5GG3C64hFUuLh7klTCSrXQkENjGRTJzHQkG0jY?=
 =?us-ascii?Q?ve04SvA8CYwg52giaL+77hHqbdY/O1e5GSnnpaRs9pV8fYA+d5sRHJW7qJ/q?=
 =?us-ascii?Q?ZmhEUjpam5H4txOlURnsXuwTljP5xrr/gjLVaOhH2QpI7UUPueKcQHf7VhZW?=
 =?us-ascii?Q?hUAgPVSkci36EGiWaODo9iC63E+NWvIWyN0aEdyw5s8QBCnFYSxRyI8Zwfbr?=
 =?us-ascii?Q?QBKBcCVyx0rvH39UdV/pjloBEeynCPfvdaHmgWzFRLO2UcweeXZ+4+/XFvbn?=
 =?us-ascii?Q?DSaVJ6lPqHH/NfU+5t+SUZwXYaMdJvwNXHws9ZlxQ0zn6z1j2qWqzTLQl8DB?=
 =?us-ascii?Q?omUpIspK9vK+zKHIVDcNNtXdxfQTvbEtRRmn?=
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: 20 Jun 2025 18:30:10.6550
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 29b0441e-caff-4b66-8a63-08ddb0287d7c
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:
	BN1PEPF00006002.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6393

Create a struct header within kernel_info with the contents common to
kernel_info and boot_domain, and define that header in common code. This enables
x86 to use that header as-is and drop x86's boot_domain.

Not a functional change.

Signed-off-by: Alejandro Vallejo 
Reviewed-by: Stefano Stabellini 
---
 xen/arch/arm/dom0less-build.c           |  8 ++++----
 xen/arch/arm/domain_build.c             | 20 ++++++++++----------
 xen/arch/arm/kernel.c                   |  8 ++++----
 xen/common/device-tree/dom0less-build.c | 18 +++++++++---------
 xen/common/device-tree/domain-build.c   | 20 ++++++++++----------
 xen/common/device-tree/kernel.c         | 20 ++++++++++----------
 xen/include/xen/bootfdt.h               | 10 ++++++++++
 xen/include/xen/fdt-kernel.h            |  5 ++---
 8 files changed, 59 insertions(+), 50 deletions(-)

diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index 4b285cff5e..08e8424030 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -32,7 +32,7 @@ static int __init make_gicv2_domU_node(struct kernel_info *kinfo)
     int res = 0;
     __be32 reg[(GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS) * 2];
     __be32 *cells;
-    const struct domain *d = kinfo->d;
+    const struct domain *d = kinfo->hdr.d;
 
     res = domain_fdt_begin_node(fdt, "interrupt-controller",
                                 vgic_dist_base(&d->arch.vgic));
@@ -85,7 +85,7 @@ static int __init make_gicv3_domU_node(struct kernel_info *kinfo)
     void *fdt = kinfo->fdt;
     int res = 0;
     __be32 *reg, *cells;
-    const struct domain *d = kinfo->d;
+    const struct domain *d = kinfo->hdr.d;
     unsigned int i, len = 0;
 
     res = domain_fdt_begin_node(fdt, "interrupt-controller",
@@ -152,7 +152,7 @@ static int __init make_gicv3_domU_node(struct kernel_info *kinfo)
 
 int __init make_intc_domU_node(struct kernel_info *kinfo)
 {
-    switch ( kinfo->d->arch.vgic.version )
+    switch ( kinfo->hdr.d->arch.vgic.version )
     {
 #ifdef CONFIG_GICV3
     case GIC_V3:
@@ -175,7 +175,7 @@ static int __init make_vpl011_uart_node(struct kernel_info *kinfo)
     gic_interrupt_t intr;
     __be32 reg[GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS];
     __be32 *cells;
-    struct domain *d = kinfo->d;
+    struct domain *d = kinfo->hdr.d;
 
     res = domain_fdt_begin_node(fdt, "sbsa-uart", d->arch.vpl011.base_addr);
     if ( res )
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 3f5c7c2e5a..fb577f816f 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -464,8 +464,8 @@ static int __init write_properties(struct domain *d, struct kernel_info *kinfo,
     int had_dom0_bootargs = 0;
     struct dt_device_node *iommu_node;
 
-    if ( kinfo->cmdline && kinfo->cmdline[0] )
-        bootargs = &kinfo->cmdline[0];
+    if ( kinfo->hdr.cmdline && kinfo->hdr.cmdline[0] )
+        bootargs = &kinfo->hdr.cmdline[0];
 
     /*
      * We always skip the IOMMU device when creating DT for hwdom if there is
@@ -579,7 +579,7 @@ static int __init write_properties(struct domain *d, struct kernel_info *kinfo,
 
     if ( dt_node_path_is_equal(node, "/chosen") )
     {
-        const struct boot_module *initrd = kinfo->initrd;
+        const struct boot_module *initrd = kinfo->hdr.initrd;
 
         if ( bootargs )
         {
@@ -1456,7 +1456,7 @@ int __init make_timer_node(const struct kernel_info *kinfo)
     if ( res )
         return res;
 
-    if ( !is_64bit_domain(kinfo->d) )
+    if ( !is_64bit_domain(kinfo->hdr.d) )
         res = fdt_property_string(fdt, "compatible", "arm,armv7-timer");
     else
         res = fdt_property_string(fdt, "compatible", "arm,armv8-timer");
@@ -1468,7 +1468,7 @@ int __init make_timer_node(const struct kernel_info *kinfo)
      * It always exposes an active-low level-sensitive interrupt.
      */
 
-    if ( is_hardware_domain(kinfo->d) )
+    if ( is_hardware_domain(kinfo->hdr.d) )
     {
         irq[TIMER_PHYS_SECURE_PPI] = timer_get_irq(TIMER_PHYS_SECURE_PPI);
         irq[TIMER_PHYS_NONSECURE_PPI] =
@@ -1517,7 +1517,7 @@ int __init make_chosen_node(const struct kernel_info *kinfo)
 {
     int res;
     const char *bootargs = NULL;
-    const struct boot_module *initrd = kinfo->initrd;
+    const struct boot_module *initrd = kinfo->hdr.initrd;
     void *fdt = kinfo->fdt;
 
     dt_dprintk("Create chosen node\n");
@@ -1525,9 +1525,9 @@ int __init make_chosen_node(const struct kernel_info *kinfo)
     if ( res )
         return res;
 
-    if ( kinfo->cmdline && kinfo->cmdline[0] )
+    if ( kinfo->hdr.cmdline && kinfo->hdr.cmdline[0] )
     {
-        bootargs = &kinfo->cmdline[0];
+        bootargs = &kinfo->hdr.cmdline[0];
         res = fdt_property(fdt, "bootargs", bootargs, strlen(bootargs) + 1);
         if ( res )
            return res;
@@ -1976,7 +1976,7 @@ static int __init construct_dom0(struct domain *d)
     d->max_pages = dom0_mem >> PAGE_SHIFT;
 
     kinfo.unassigned_mem = dom0_mem;
-    kinfo.d = d;
+    kinfo.hdr.d = d;
 
     rc = kernel_probe(&kinfo, NULL);
     if ( rc < 0 )
@@ -1988,7 +1988,7 @@ static int __init construct_dom0(struct domain *d)
 int __init construct_hwdom(struct kernel_info *kinfo,
                            const struct dt_device_node *node)
 {
-    struct domain *d = kinfo->d;
+    struct domain *d = kinfo->hdr.d;
     int rc;
 
     iommu_hwdom_init(d);
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index e734ec5c1e..10e5dcad5e 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -46,7 +46,7 @@ static void __init place_modules(struct kernel_info *info,
                                  paddr_t kernbase, paddr_t kernend)
 {
     /* Align DTB and initrd size to 2Mb. Linux only requires 4 byte alignment */
-    const struct boot_module *mod = info->initrd;
+    const struct boot_module *mod = info->hdr.initrd;
     const struct membanks *mem = kernel_info_get_mem(info);
     const paddr_t initrd_len = ROUNDUP(mod ? mod->size : 0, MB(2));
     const paddr_t dtb_len = ROUNDUP(fdt_totalsize(info->fdt), MB(2));
@@ -152,12 +152,12 @@ static void __init kernel_zimage_load(struct kernel_info *info)
 
     kernel = ioremap_wc(paddr, len);
     if ( !kernel )
-        panic("Unable to map the %pd kernel\n", info->d);
+        panic("Unable to map the %pd kernel\n", info->hdr.d);
 
-    rc = copy_to_guest_phys_flush_dcache(info->d, load_addr,
+    rc = copy_to_guest_phys_flush_dcache(info->hdr.d, load_addr,
                                          kernel, len);
     if ( rc != 0 )
-        panic("Unable to copy the kernel in the %pd memory\n", info->d);
+        panic("Unable to copy the kernel in the %pd memory\n", info->hdr.d);
 
     iounmap(kernel);
 }
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
index 221b875a2f..e321747175 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -167,18 +167,18 @@ static int __init handle_passthrough_prop(struct kernel_info *kinfo,
             return -EINVAL;
         }
 
-        res = iomem_permit_access(kinfo->d, paddr_to_pfn(mstart),
+        res = iomem_permit_access(kinfo->hdr.d, paddr_to_pfn(mstart),
                                   paddr_to_pfn(PAGE_ALIGN(mstart + size - 1)));
         if ( res )
         {
             printk(XENLOG_ERR "Unable to permit to dom%d access to"
                    " 0x%"PRIpaddr" - 0x%"PRIpaddr"\n",
-                   kinfo->d->domain_id,
+                   kinfo->hdr.d->domain_id,
                    mstart & PAGE_MASK, PAGE_ALIGN(mstart + size) - 1);
             return res;
         }
 
-        res = map_regions_p2mt(kinfo->d,
+        res = map_regions_p2mt(kinfo->hdr.d,
                                gaddr_to_gfn(gstart),
                                PFN_DOWN(size),
                                maddr_to_mfn(mstart),
@@ -217,7 +217,7 @@ static int __init handle_passthrough_prop(struct kernel_info *kinfo,
         return -EINVAL;
     }
 
-    res = map_device_irqs_to_domain(kinfo->d, node, true, NULL);
+    res = map_device_irqs_to_domain(kinfo->hdr.d, node, true, NULL);
     if ( res < 0 )
         return res;
 
@@ -229,7 +229,7 @@ static int __init handle_passthrough_prop(struct kernel_info *kinfo,
     if ( xen_force && !dt_device_is_protected(node) )
         return 0;
 
-    return iommu_assign_dt_device(kinfo->d, node);
+    return iommu_assign_dt_device(kinfo->hdr.d, node);
 }
 
 static int __init handle_prop_pfdt(struct kernel_info *kinfo,
@@ -296,14 +296,14 @@ static int __init handle_prop_pfdt(struct kernel_info *kinfo,
                                       address_cells, size_cells);
         if ( res < 0 )
         {
-            printk(XENLOG_ERR "Failed to assign device to %pd\n", kinfo->d);
+            printk(XENLOG_ERR "Failed to assign device to %pd\n", kinfo->hdr.d);
             return res;
         }
     }
     else if ( (xen_path && !xen_reg) || (xen_reg && !xen_path && !xen_force) )
     {
         printk(XENLOG_ERR "xen,reg or xen,path missing for %pd\n",
-               kinfo->d);
+               kinfo->hdr.d);
         return -EINVAL;
     }
 
@@ -605,7 +605,7 @@ static int __init alloc_xenstore_page(struct domain *d)
 
 static int __init alloc_xenstore_params(struct kernel_info *kinfo)
 {
-    struct domain *d = kinfo->d;
+    struct domain *d = kinfo->hdr.d;
     int rc = 0;
 
 #ifdef CONFIG_HVM
@@ -773,7 +773,7 @@ static int __init construct_domU(struct domain *d,
 
     d->max_pages = ((paddr_t)mem * SZ_1K) >> PAGE_SHIFT;
 
-    kinfo.d = d;
+    kinfo.hdr.d = d;
 
     rc = kernel_probe(&kinfo, node);
     if ( rc < 0 )
diff --git a/xen/common/device-tree/domain-build.c b/xen/common/device-tree/domain-build.c
index cd01a8b4bc..51182d10ef 100644
--- a/xen/common/device-tree/domain-build.c
+++ b/xen/common/device-tree/domain-build.c
@@ -76,7 +76,7 @@ bool __init allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn,
                                  paddr_t tot_size)
 {
     struct membanks *mem = kernel_info_get_mem(kinfo);
-    struct domain *d = kinfo->d;
+    struct domain *d = kinfo->hdr.d;
     struct membank *bank;
 
     /*
@@ -170,7 +170,7 @@ int __init find_unallocated_memory(const struct kernel_info *kinfo,
     unsigned int i, j;
     int res;
 
-    ASSERT(domain_use_host_layout(kinfo->d));
+    ASSERT(domain_use_host_layout(kinfo->hdr.d));
 
     unalloc_mem = rangeset_new(NULL, NULL, 0);
     if ( !unalloc_mem )
@@ -336,23 +336,23 @@ void __init dtb_load(struct kernel_info *kinfo,
     unsigned long left;
 
     printk("Loading %pd DTB to 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
-           kinfo->d, kinfo->dtb_paddr,
+           kinfo->hdr.d, kinfo->dtb_paddr,
            kinfo->dtb_paddr + fdt_totalsize(kinfo->fdt));
 
-    left = copy_to_guest(kinfo->d, kinfo->dtb_paddr,
+    left = copy_to_guest(kinfo->hdr.d, kinfo->dtb_paddr,
                          kinfo->fdt,
                          fdt_totalsize(kinfo->fdt));
 
     if ( left != 0 )
         panic("Unable to copy the DTB to %pd memory (left = %lu bytes)\n",
-              kinfo->d, left);
+              kinfo->hdr.d, left);
     xfree(kinfo->fdt);
 }
 
 void __init initrd_load(struct kernel_info *kinfo,
                         copy_to_guest_phys_cb copy_to_guest)
 {
-    const struct boot_module *mod = kinfo->initrd;
+    const struct boot_module *mod = kinfo->hdr.initrd;
     paddr_t load_addr = kinfo->initrd_paddr;
     paddr_t paddr, len;
     int node;
@@ -368,7 +368,7 @@ void __init initrd_load(struct kernel_info *kinfo,
     len = mod->size;
 
     printk("Loading %pd initrd from %"PRIpaddr" to 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
-           kinfo->d, paddr, load_addr, load_addr + len);
+           kinfo->hdr.d, paddr, load_addr, load_addr + len);
 
     /* Fix up linux,initrd-start and linux,initrd-end in /chosen */
     node = fdt_path_offset(kinfo->fdt, "/chosen");
@@ -391,12 +391,12 @@ void __init initrd_load(struct kernel_info *kinfo,
 
     initrd = ioremap_wc(paddr, len);
     if ( !initrd )
-        panic("Unable to map the %pd initrd\n", kinfo->d);
+        panic("Unable to map the %pd initrd\n", kinfo->hdr.d);
 
-    res = copy_to_guest(kinfo->d, load_addr,
+    res = copy_to_guest(kinfo->hdr.d, load_addr,
                         initrd, len);
     if ( res != 0 )
-        panic("Unable to copy the initrd in the %pd memory\n", kinfo->d);
+        panic("Unable to copy the initrd in the %pd memory\n", kinfo->hdr.d);
 
     iounmap(initrd);
 }
diff --git a/xen/common/device-tree/kernel.c b/xen/common/device-tree/kernel.c
index e1b22dc1c7..7a00768e6b 100644
--- a/xen/common/device-tree/kernel.c
+++ b/xen/common/device-tree/kernel.c
@@ -136,16 +136,16 @@ int __init kernel_probe(struct kernel_info *info,
     /* domain is NULL only for the hardware domain */
     if ( domain == NULL )
     {
-        ASSERT(is_hardware_domain(info->d));
+        ASSERT(is_hardware_domain(info->hdr.d));
 
         mod = boot_module_find_by_kind(BOOTMOD_KERNEL);
 
-        info->kernel = mod;
-        info->initrd = boot_module_find_by_kind(BOOTMOD_RAMDISK);
+        info->hdr.kernel = mod;
+        info->hdr.initrd = boot_module_find_by_kind(BOOTMOD_RAMDISK);
 
         cmd = boot_cmdline_find_by_kind(BOOTMOD_KERNEL);
         if ( cmd )
-            info->cmdline = &cmd->cmdline[0];
+            info->hdr.cmdline = &cmd->cmdline[0];
     }
     else
     {
@@ -162,7 +162,7 @@ int __init kernel_probe(struct kernel_info *info,
                 dt_get_range(&val, node, &kernel_addr, &size);
                 mod = boot_module_find_by_addr_and_kind(
                         BOOTMOD_KERNEL, kernel_addr);
-                info->kernel = mod;
+                info->hdr.kernel = mod;
             }
             else if ( dt_device_is_compatible(node, "multiboot,ramdisk") )
             {
@@ -171,7 +171,7 @@ int __init kernel_probe(struct kernel_info *info,
 
                 val = dt_get_property(node, "reg", &len);
                 dt_get_range(&val, node, &initrd_addr, &size);
-                info->initrd = boot_module_find_by_addr_and_kind(
+                info->hdr.initrd = boot_module_find_by_addr_and_kind(
                         BOOTMOD_RAMDISK, initrd_addr);
             }
             else if ( dt_device_is_compatible(node, "multiboot,device-tree") )
@@ -192,7 +192,7 @@ int __init kernel_probe(struct kernel_info *info,
         name = dt_node_name(domain);
         cmd = boot_cmdline_find_by_name(name);
         if ( cmd )
-            info->cmdline = &cmd->cmdline[0];
+            info->hdr.cmdline = &cmd->cmdline[0];
     }
     if ( !mod || !mod->size )
     {
@@ -201,10 +201,10 @@ int __init kernel_probe(struct kernel_info *info,
     }
 
     printk("Loading %pd kernel from boot module @ %"PRIpaddr"\n",
-           info->d, info->kernel->start);
-    if ( info->initrd )
+           info->hdr.d, info->hdr.kernel->start);
+    if ( info->hdr.initrd )
         printk("Loading ramdisk from boot module @ %"PRIpaddr"\n",
-               info->initrd->start);
+               info->hdr.initrd->start);
 
     /*
      * uImage isn't really used nowadays thereby leave kernel_uimage_probe()
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index 854e7f1ed9..be0abe30ef 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -100,6 +100,16 @@ struct shared_meminfo {
     struct shmem_membank_extra extra[NR_SHMEM_BANKS];
 };
 
+
+struct boot_domain {
+    struct domain *d;
+
+    struct boot_module *kernel;
+    struct boot_module *initrd;
+
+    const char* cmdline;
+};
+
 /*
  * The domU flag is set for kernels and ramdisks of "xen,domain" nodes.
  * The purpose of the domU flag is to avoid getting confused in
diff --git a/xen/include/xen/fdt-kernel.h b/xen/include/xen/fdt-kernel.h
index 12a0b42d17..fee8eac1db 100644
--- a/xen/include/xen/fdt-kernel.h
+++ b/xen/include/xen/fdt-kernel.h
@@ -16,7 +16,7 @@
 #endif
 
 struct kernel_info {
-    struct domain *d;
+    struct boot_domain hdr;
 
     void *fdt; /* flat device tree */
     paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
@@ -34,8 +34,7 @@ struct kernel_info {
     paddr_t gnttab_size;
 
     /* boot blob load addresses */
-    const struct boot_module *kernel, *initrd, *dtb;
-    const char* cmdline;
+    const struct boot_module *dtb;
     paddr_t dtb_paddr;
     paddr_t initrd_paddr;
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 20 18:30:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 18:30:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021098.1397163 (Exim 4.92)
	(envelope-from )
	id 1uSgVP-0007yB-0G; Fri, 20 Jun 2025 18:30:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021098.1397163; Fri, 20 Jun 2025 18: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 1uSgVO-0007y2-TM; Fri, 20 Jun 2025 18:30:26 +0000
Received: by outflank-mailman (input) for mailman id 1021098;
 Fri, 20 Jun 2025 18:30: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 1uSgVN-000575-Mp
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 18:30:25 +0000
Received: from NAM04-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam04on20600.outbound.protection.outlook.com
 [2a01:111:f403:240a::600])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a049c974-4e04-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 20:30:24 +0200 (CEST)
Received: from BL6PEPF0001641E.NAMP222.PROD.OUTLOOK.COM
 (2603:10b6:22e:400:0:1004:0:e) by SJ0PR12MB6965.namprd12.prod.outlook.com
 (2603:10b6:a03:448::18) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.28; Fri, 20 Jun
 2025 18:30:18 +0000
Received: from BN1PEPF00005FFD.namprd05.prod.outlook.com
 (2a01:111:f403:c803::2) by BL6PEPF0001641E.outlook.office365.com
 (2603:1036:903:4::a) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8857.25 via Frontend Transport; Fri,
 20 Jun 2025 18:30:18 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN1PEPF00005FFD.mail.protection.outlook.com (10.167.243.229) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8857.21 via Frontend Transport; Fri, 20 Jun 2025 18:30:18 +0000
Received: from xcbagarciav01.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; Fri, 20 Jun
 2025 13:30:10 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a049c974-4e04-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ZZcgzibemFh2EUQ3ui18kppj2ztf349xn7nNTryhtQxnBl0EnhU2Cv4+4iYhjPVK9OyG6lIZLCk8f4VFb6d3QKXcOIPKh+TP/W4GsIYYBfm3isgzfv28nbugdYT/R1EVFRuD0x7Pi3GzhFK5oV2Hv2iiZcF5AVLd6DQbZYsaqWcSPqeDmvg1gC9yhF2fXImrJXhuJpd+lRUzV1Ds8dgwAiTFnOya+r1beTqbSp7sDauxDRMOBRIpLfO5X/UN2cHhpLJ+Avfg2NU7QY3epWQlYJCVcmbshH1JOZe3TjKUTriKYIHwb8TG8jfHZIYYLrN83hq52X4XJX3Ijq6nlghWLA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=p9ZiP25AT0NUU0OB8svKEcTwDIsiPq7Hv28Amb3Kek8=;
 b=d4Hdp5WSEMXRJ8nKngItZ6USAn1TneqoDMB0EA1DFPMKVc+RAX/e8OMCy5BDC9CSGwEdz9RPiZOaO0BBEkf+3YLBLpbc/jln3yKQZCyCCojIf3yd3pHfWsYplTB1fZl4r3Ir/KEsaIyDeiFGlECGU149KElVrYRFEAFOZG/wAzsJHz9y/vu4B7xuyvcHErItD/AAqFCArKq/OmwIs1xq9+gnlzJYs2JLBqWJS7bAzIP6ilGpTAcgvi4Adi9XbMC36mLkL6xcgYC3Tg0pKfSQsjZZcY/MDvVk8J3tAMjWGh3uSVFMK5Dr2VF6zvm8fjW3feh0EjSsKE7ppnmrSsKmZg==
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=p9ZiP25AT0NUU0OB8svKEcTwDIsiPq7Hv28Amb3Kek8=;
 b=lA0Hpj77mOMmqte2e2olZQWORDHxS90q1YN9HOIu6J3Kjld19QY/WeOtcaDe0EmR8jAgpLfs+OtMGThU1aJLIxTS6bQ+2Gq+11/K4x17jemez3Lk7DKxvfyLkcBB9bN6OpEdR/YaGnxJtkPCLY7m3MD06OCWqvJmm1y+ES3CE+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=SATLEXMB04.amd.com; pr=C
From: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Stefano
 Stabellini" , Julien Grall ,
	"Bertrand Marquis" , Michal Orzel
	
Subject: [PATCH v4 05/12] x86: Replace arch-specific boot_domain with the common one
Date: Fri, 20 Jun 2025 20:28:51 +0200
Message-ID: <20250620182859.23378-6-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250620182859.23378-1-agarciav@amd.com>
References: <20250620182859.23378-1-agarciav@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: BN1PEPF00005FFD:EE_|SJ0PR12MB6965:EE_
X-MS-Office365-Filtering-Correlation-Id: 9d58d30b-e508-4837-f066-08ddb02881ed
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?FZIIrzxyJfAEmfyHoJLMD53c0t0uG8/svPD/Ji/rlDdFBcWDTXc2SiGiUGOX?=
 =?us-ascii?Q?qPxzHePxVi42Ccl1hFoUpTIxlOW7dKasHLnU/HFqvGHlvWanWQ6I4Qn2fhbL?=
 =?us-ascii?Q?bOuEdUvA8qKI8BOcKVCYkIGIv622mPbrm/6QxB0w+XMmuw9kFNX11uMmdILt?=
 =?us-ascii?Q?2EndQ1hdwO9idmlkze4PKrWOeNGPOJ22yBzdOPEIayUYvS4T0UCCHPRoAUO2?=
 =?us-ascii?Q?8cVYvPQwPr2xJi9E+y+O0IDi8i3UxDthmSQ3Ef1WwqgJ93LLbIrxsMxRpdoJ?=
 =?us-ascii?Q?tDDuaWRHNQnCWMhFPXM6A5cx5vLD+iVLXVQe88GYkxEzBX/30WMHbiMX1Vbi?=
 =?us-ascii?Q?q8TfWJkvf8+7GzZccatUrYUWmnXxuZoBhhkg3UYCi94ULJ/x3xzwOQzt8SBx?=
 =?us-ascii?Q?rLr/P+AIOcPfZPlFw6WUVAgpUc0+2wjF3Y4PfOZac4qJUZQoHhcfwG0YVOqy?=
 =?us-ascii?Q?pMxRGLjdxT0JHaZrUmXiOhPaof3TepWOTC69unJF/4o7OzIb2GUCsljWpX9M?=
 =?us-ascii?Q?8YVXCWxMz1zcXu6a/DklNAQlwROL+X3aScv3i9Wel81JgIUMU6NBJrs44p+X?=
 =?us-ascii?Q?2ofd7GMfHT2zQqIigb0YzpDiwh2avA+RDHVm92vNNu5Ju5Qy6cWaN56LKQ35?=
 =?us-ascii?Q?PXDxlSNQvC9GkmA7TQSYFL1U41gUnRXQWf06hijt3PcD5mvfUlMmIM7+35AO?=
 =?us-ascii?Q?0KHotc43ei+dFwc/62qq5Oaeqw+kAKSkOmzyy/enYj60i5eW/M8xGjtZ5n0/?=
 =?us-ascii?Q?cdbyA3D1LfWVfmN4JmyjcrGDmmz99PtwZT7hKjWhv1cD87ADUlfGup4WK3gb?=
 =?us-ascii?Q?4qwFS7hd8qlrI9l/vnORkkwVtvstSfs3YoVtK8fXzjXczi9qvm8Fp2EuHWfp?=
 =?us-ascii?Q?1NF8UFOdHO3BeNNcGyekiG+G6zGWUu3NSHrPVzuoWCiZP0Shi18c8BKL30ki?=
 =?us-ascii?Q?Aan04xTPd3Pwhiww65Ii4Xe7zDBlDzbdOJOWOcl0ERWIzYNLipbaUL5gzDs7?=
 =?us-ascii?Q?nM0p7FV9soE4jzG951yNkj7yu0WXEbb9pOXVudJeB+Dp1xCgSRZeoLLyHEv+?=
 =?us-ascii?Q?YoWMAChwXuxgi6SU/qnqGL/41fpUX3eourYJfFN/1e/QzgvtukfsZT6zEmPY?=
 =?us-ascii?Q?VLMNbuvJ5Xnw8Lma40ZDEjPo0XV6PLEv47TwWpAJegtzJUxhbJ1tsEN10lbY?=
 =?us-ascii?Q?wQZLUhce03Y+BHZRzwCPrBfF/B23bphKEWOGX2qWb0cO9lAiLRHJyfs3KXNU?=
 =?us-ascii?Q?jf5sK8oW9UJrm3mhS5kHbtmd38TxiyfNMqyij08CLxQ4xz8XY/rvwWMNfeaP?=
 =?us-ascii?Q?C7tHP4LSYN6dDHUu2wVYqyQTaNzFJAFnYj6qzne6lJPPFJ1bwJBVDuX6TOJ2?=
 =?us-ascii?Q?XQcQ+Js+hP3fnffCJlz4Y6hli+qCTEhO/BP8fhmclknPSg5qTt2xNuiW+c3t?=
 =?us-ascii?Q?Ly3wUGp3sTyMovyR/GpXgonw0n2HywKG4qUZ/tc/hgPqwfyLzOwX/IJ19aG0?=
 =?us-ascii?Q?aIyl4FmZm/O8au1Q02ev+ZbQubJbBrxAz1vu?=
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: 20 Jun 2025 18:30:18.1106
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9d58d30b-e508-4837-f066-08ddb02881ed
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:
	BN1PEPF00005FFD.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB6965

Add the single arch-specific field in an "arch" subfield defined in
asm/bootfdt.h.

No functional change intended.

Signed-off-by: Alejandro Vallejo 
Reviewed-by: Stefano Stabellini 
---
 xen/arch/x86/hvm/dom0_build.c          |  2 +-
 xen/arch/x86/include/asm/boot-domain.h | 33 --------------------------
 xen/arch/x86/include/asm/bootfdt.h     |  6 +++++
 xen/arch/x86/include/asm/bootinfo.h    |  1 -
 xen/arch/x86/pv/dom0_build.c           |  2 +-
 xen/arch/x86/setup.c                   | 12 ++++++----
 xen/include/xen/bootfdt.h              |  4 ++++
 7 files changed, 19 insertions(+), 41 deletions(-)
 delete mode 100644 xen/arch/x86/include/asm/boot-domain.h

diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 2bb8ef355c..8d2734f2b5 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -648,7 +648,7 @@ static int __init pvh_load_kernel(
 {
     struct domain *d = bd->d;
     struct boot_module *image = bd->kernel;
-    struct boot_module *initrd = bd->module;
+    struct boot_module *initrd = bd->initrd;
     void *image_base = bootstrap_map_bm(image);
     void *image_start = image_base + image->arch.headroom;
     unsigned long image_len = image->size;
diff --git a/xen/arch/x86/include/asm/boot-domain.h b/xen/arch/x86/include/asm/boot-domain.h
deleted file mode 100644
index d7c6042e25..0000000000
--- a/xen/arch/x86/include/asm/boot-domain.h
+++ /dev/null
@@ -1,33 +0,0 @@
-/* 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__
-
-#include 
-
-struct boot_domain {
-    domid_t domid;
-
-    struct boot_module *kernel;
-    struct boot_module *module;
-    const char *cmdline;
-
-    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/bootfdt.h b/xen/arch/x86/include/asm/bootfdt.h
index a4c4bf30b9..c21dbe961b 100644
--- a/xen/arch/x86/include/asm/bootfdt.h
+++ b/xen/arch/x86/include/asm/bootfdt.h
@@ -3,6 +3,12 @@
 #define X86_BOOTFDT_H
 
 #include 
+#include 
+
+struct arch_boot_domain
+{
+    domid_t domid;
+};
 
 struct arch_boot_module
 {
diff --git a/xen/arch/x86/include/asm/bootinfo.h b/xen/arch/x86/include/asm/bootinfo.h
index d33b100e04..4f2cc5906e 100644
--- a/xen/arch/x86/include/asm/bootinfo.h
+++ b/xen/arch/x86/include/asm/bootinfo.h
@@ -12,7 +12,6 @@
 #include 
 #include 
 #include 
-#include 
 
 /* Max number of boot modules a bootloader can provide in addition to Xen */
 #define MAX_NR_BOOTMODS 63
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index a4b5362357..c37bea9454 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -375,7 +375,7 @@ static int __init dom0_construct(const struct boot_domain *bd)
     struct vcpu *v = d->vcpu[0];
 
     struct boot_module *image = bd->kernel;
-    struct boot_module *initrd = bd->module;
+    struct boot_module *initrd = bd->initrd;
     void *image_base;
     unsigned long image_len;
     void *image_start;
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 4f34bbe688..a9560ac619 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -297,7 +297,9 @@ static const char *cmdline_cook(const char *p, const char *loader_name);
 struct boot_info __initdata xen_boot_info = {
     .loader = "unknown",
     .cmdline = "",
-    .domains = { [0 ... MAX_NR_BOOTDOMS - 1] = { .domid = DOMID_INVALID } },
+    .domains = { [0 ... MAX_NR_BOOTDOMS - 1] = {
+        .arch.domid = DOMID_INVALID
+    }},
     /*
      * There's a MAX_NR_BOOTMODS-th entry in the array. It's not off by one.
      *
@@ -1045,11 +1047,11 @@ 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();
-    d = domain_create(bd->domid, &dom0_cfg,
+    bd->arch.domid = get_initial_domain_id();
+    d = domain_create(bd->arch.domid, &dom0_cfg,
                       pv_shim ? 0 : CDF_privileged | CDF_hardware);
     if ( IS_ERR(d) )
-        panic("Error creating d%u: %ld\n", bd->domid, PTR_ERR(d));
+        panic("Error creating d%u: %ld\n", bd->arch.domid, PTR_ERR(d));
 
     init_dom0_cpuid_policy(d);
 
@@ -2168,7 +2170,7 @@ void asmlinkage __init noreturn __start_xen(void)
     if ( initrdidx < MAX_NR_BOOTMODS )
     {
         bi->mods[initrdidx].kind = BOOTMOD_RAMDISK;
-        bi->domains[0].module = &bi->mods[initrdidx];
+        bi->domains[0].initrd = &bi->mods[initrdidx];
         if ( first_boot_module_index(bi, BOOTMOD_UNKNOWN) < MAX_NR_BOOTMODS )
             printk(XENLOG_WARNING
                    "Multiple initrd candidates, picking module #%u\n",
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index be0abe30ef..8ea52290b7 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -108,6 +108,10 @@ struct boot_domain {
     struct boot_module *initrd;
 
     const char* cmdline;
+
+#if __has_include()
+    struct arch_boot_domain arch;
+#endif
 };
 
 /*
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 20 18:30:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 18:30:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021107.1397173 (Exim 4.92)
	(envelope-from )
	id 1uSgVb-0000OU-Cp; Fri, 20 Jun 2025 18:30:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021107.1397173; Fri, 20 Jun 2025 18: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 1uSgVb-0000OI-6q; Fri, 20 Jun 2025 18:30:39 +0000
Received: by outflank-mailman (input) for mailman id 1021107;
 Fri, 20 Jun 2025 18:30: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 1uSgVU-000575-8F
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 18:30:32 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20617.outbound.protection.outlook.com
 [2a01:111:f403:2416::617])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a3fe9f29-4e04-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 20:30:30 +0200 (CEST)
Received: from BN8PR03CA0016.namprd03.prod.outlook.com (2603:10b6:408:94::29)
 by DS0PR12MB9057.namprd12.prod.outlook.com (2603:10b6:8:c7::20) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.21; Fri, 20 Jun
 2025 18:30:26 +0000
Received: from BN1PEPF00006002.namprd05.prod.outlook.com
 (2603:10b6:408:94:cafe::49) by BN8PR03CA0016.outlook.office365.com
 (2603:10b6:408:94::29) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8857.25 via Frontend Transport; Fri,
 20 Jun 2025 18:30:26 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN1PEPF00006002.mail.protection.outlook.com (10.167.243.234) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8857.21 via Frontend Transport; Fri, 20 Jun 2025 18:30:25 +0000
Received: from xcbagarciav01.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; Fri, 20 Jun
 2025 13:30:17 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a3fe9f29-4e04-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=gXldZLee1suRU5jPqXf4Q+TmB1c8NjCZxFoTPzvG2khV8h9pEOgYp9HGo4cD+kwKWxUegU++mumDigmmifUsSzdnaS+sNAOMV3a4rzroXNAOiAlKaZjR/UHFS1qJTZ+9Gwotr+wOeqB6aPDkhvRhE/lkCyjgOCoR2/zP42iuhOJBryTXPph9OMtdvUlquPFe++B4NuOcSAZ997gJciGakcjsVytBSrUIpber/akBebVZhOL8P3AUc+tAR5PHw3ITSb9qiVYiGn2ZUNrIJmYSgDeVXr7BXDhGQ+nWczVmue62cUA3m8R/54vZ+05hLFMLmzU8Dv+rcGXoJky2xL/CfA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=27UTwRuwh14+8Le/U5yX2jQE9IYhU3yQMi8KNRacHYY=;
 b=U9QO40nnpnBlbyTGWG/pkeGkv6OMY7gRnvJor38pxq13K1ZUH1foULYL+NJbG9WrzsVxN5jx9/53rqC57LfD/Cr3eQT4vJ1LSGohq3dKH3pEfvUslHe1DmMbjfZfdE9YazAiyo4RHvGfh8NXyqh/ZTaIxSOF4H8ryY4dY3F9izdeRB0TypQX/lKMHFj/OfCey6Mx/WahfW4/aKsA6WuihxRJND5leUfvC/MOHmES1bFS+GSpzDZKgsIuJqba3lo4/tKZfJ31MTC9yuNOttvqhCAkC6FUwFCvmFQ9CGBN4BSvvshZozr4kJfBdhyad+EhIo+eMn2RtqvEwcfmpPfm6g==
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=27UTwRuwh14+8Le/U5yX2jQE9IYhU3yQMi8KNRacHYY=;
 b=4vgJ11auWFSQYmNt2gXJD6zU64hQL0hgvnIUGFoMaLOC7kjPyKcIXgpbDnE8+Emnbjo3UGMoGtndgkOy1famll9/jIYbCr3bD9Wob9qnD2jb4n8+xxIgs3Vie6zqz48CxX8DI/uJjROc1ALFaiWEAYvxR9aPHqHMGc/DbPZZmBo=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Alistair Francis
	, Bob Eshleman , "Connor
 Davis" , Oleksii Kurochko
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Dario Faggioli ,
	Juergen Gross , George Dunlap 
Subject: [PATCH v4 06/12] xen/dt: Move bootfdt functions to xen/bootfdt.h
Date: Fri, 20 Jun 2025 20:28:52 +0200
Message-ID: <20250620182859.23378-7-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250620182859.23378-1-agarciav@amd.com>
References: <20250620182859.23378-1-agarciav@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: BN1PEPF00006002:EE_|DS0PR12MB9057:EE_
X-MS-Office365-Filtering-Correlation-Id: 86c131b1-033c-40d4-75ec-08ddb028869e
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|7416014|36860700013|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?SQwtzao/b9j9QlAjCf7PwVPQTCuO0eaM+NmOgGu6Q7DEJ/124Kfbf8n9lhOA?=
 =?us-ascii?Q?SrNFUHjb/qgrK2GcBSr92fCRxj18wqMDg6Qw14GdxP7mcV5Ju8tRc1a45oNt?=
 =?us-ascii?Q?S6yaScEaXe4lcy/29YjnZWz5BRh4k4rSs7Zs7XCsvtLe9mWrTDcTJ1U0mOKR?=
 =?us-ascii?Q?RB06YrY/5vtbeMP1MJzE2ASBRG168BmtWx9iucSW3YX9M8JSwbPxuOXrsjXE?=
 =?us-ascii?Q?LTjJuRZ1MoJzf1d9/2Odyt098JZyYZrUURBCsrTTCgKIpzCzJwGZWygE3hxz?=
 =?us-ascii?Q?x7JYMHF/DwLZW7nWQIFPeoAg3MLrf/5k171C/Us0RfcbaCmQqtS391afaQcu?=
 =?us-ascii?Q?pM1yaLkOYRPj5vAlVtVnRJaFoE80LCLnOBOufJQT+v/moJ/sDN0TPH/UoViC?=
 =?us-ascii?Q?KVzK2SywPuePdB+JWphg0KpphdKMXmCR5nIX4u18Hgb+Aj1RVOFCiHR5DKjE?=
 =?us-ascii?Q?CmAXxC5/5i53UKAzXHtmleAUmf2tZGtsszkeyAjTcDnUT9Y0vDJ6IH+H8nqn?=
 =?us-ascii?Q?c531ePIT3k9WfTSByazCEwZ5FKZluhhEUQzmcjy5W/Xuh7fU33Ee44PQWwDh?=
 =?us-ascii?Q?WOaSKNPNh3JZn1epGBwboEBZM92we1X3P6qGmzXDf26v7oHIHbWD2U+kOAio?=
 =?us-ascii?Q?+2e3uMHKeqecDBN1mTXS4dJ24MZgbcy5chaFrM74d4v7qFHaJDJ00JkAxosa?=
 =?us-ascii?Q?j1q+d8wNSbMZttCdAHcYhi0P43y7a8AEfkhTPuYBSxF+H23lDS7Wegq7ySbu?=
 =?us-ascii?Q?R1n4vLbxvqvGkzCCpxOfnlm+TTr6aJ6fdq9pPqMuGqD81clP8hLUAQoKn6tI?=
 =?us-ascii?Q?YPF7cxXm0COTFttUA7sDuk+MWHSCZ7yqmvRt4LpKNkjccE7sQyDNog8jF8/W?=
 =?us-ascii?Q?UYYnvfSw3zpqv07f1VgcdTtVknKqmRJy/MEek8i2n8zLZe2ojdc2rVqEuLPv?=
 =?us-ascii?Q?9oeP+GkTAIpluZgk4Sjv29nsJpxSgSaMWcu/hICCFVxmpEowBypBuryj1Nx0?=
 =?us-ascii?Q?bFeYrxJ0iZ9ReZe5MuvWwIXa9M7hSXqwiVovbQi5n19xOCG6H/BH0bI74mZ0?=
 =?us-ascii?Q?cv+xc+AN53I5q17sCIxqUv5yVfUmVpuORO/PcRJ0y/LnEl0xxHbY3dNM9UDw?=
 =?us-ascii?Q?bNB9t6IQSKhvYTDSOaeeUTPSfGalwoFjOPxA6FFBSeJmpcMDaRv0oT8OQUl7?=
 =?us-ascii?Q?bXt7ZuVPFmNic2lMOLmQmkix5X44LK+Yh/tq+SFfspgykfWCwZDhCADHtS0f?=
 =?us-ascii?Q?fm4AyOaizp95nXG9ZdPiw48vcAjRi9sHCn9tQDAhwb++Z4+NNbx5iyBhDg9c?=
 =?us-ascii?Q?tKDtoEzbmzVysamZUbfXLRDWT3BDLVWzA8detR0zrfciMAqjH6R5b+DGbcQe?=
 =?us-ascii?Q?yM7bW/1YcQ9K4nCWleLVP5PJpvEMPSnObcs13wW/Zb4ZZNlElINJN2PKNTDO?=
 =?us-ascii?Q?7RB1bIIhlSldynAK76qhZSTwszZ3MY/smhiv0mSfulECaY3M3gFXfhaChFeM?=
 =?us-ascii?Q?N+JorQvNHhTS8fEfF3bPIE3ly6z39QhBwW0D?=
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)(7416014)(36860700013)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jun 2025 18:30:25.9769
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 86c131b1-033c-40d4-75ec-08ddb028869e
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:
	BN1PEPF00006002.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB9057

Part of an unpicking process to extract bootfdt contents independent of bootinfo
to a separate file for x86 to take.

Move functions required for early FDT parsing from device_tree.h and arm's
setup.h onto bootfdt.h

Declaration motion only. Not a functional change.

Signed-off-by: Alejandro Vallejo 
---
v4:
  * Remove bootfdt.h include from device_tree.h
    (move dt_read_paddr and fix up
     static-evtchn.c +
     device-tree.c +
     boot-cpupool.c +
     riscv/smpboot.c +
     riscv/cpufeature.c)
---
 xen/arch/riscv/cpufeature.c            |  1 +
 xen/arch/riscv/smpboot.c               |  1 +
 xen/common/device-tree/device-tree.c   |  1 +
 xen/common/device-tree/static-evtchn.c |  1 +
 xen/common/sched/boot-cpupool.c        |  1 +
 xen/include/xen/bootfdt.h              | 91 ++++++++++++++++++++++++++
 xen/include/xen/device_tree.h          | 66 -------------------
 7 files changed, 96 insertions(+), 66 deletions(-)

diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c
index b7d5ec6580..b846a106a3 100644
--- a/xen/arch/riscv/cpufeature.c
+++ b/xen/arch/riscv/cpufeature.c
@@ -8,6 +8,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/riscv/smpboot.c b/xen/arch/riscv/smpboot.c
index 470f6d1311..3b8bf98e20 100644
--- a/xen/arch/riscv/smpboot.c
+++ b/xen/arch/riscv/smpboot.c
@@ -1,3 +1,4 @@
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/device-tree/device-tree.c b/xen/common/device-tree/device-tree.c
index 886e6c7712..725ff71646 100644
--- a/xen/common/device-tree/device-tree.c
+++ b/xen/common/device-tree/device-tree.c
@@ -7,6 +7,7 @@
  * benh@kernel.crashing.org
  */
 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/device-tree/static-evtchn.c b/xen/common/device-tree/static-evtchn.c
index 8b82e6b3d8..88342b44a1 100644
--- a/xen/common/device-tree/static-evtchn.c
+++ b/xen/common/device-tree/static-evtchn.c
@@ -1,5 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
+#include 
 #include 
 #include 
 
diff --git a/xen/common/sched/boot-cpupool.c b/xen/common/sched/boot-cpupool.c
index 641f3495cb..03be73efdd 100644
--- a/xen/common/sched/boot-cpupool.c
+++ b/xen/common/sched/boot-cpupool.c
@@ -7,6 +7,7 @@
  * Copyright (C) 2022 Arm Ltd.
  */
 
+#include 
 #include 
 #include 
 
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index 8ea52290b7..0846317f30 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -2,8 +2,11 @@
 #ifndef XEN_BOOTFDT_H
 #define XEN_BOOTFDT_H
 
+#include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -16,8 +19,80 @@
 #define NR_MEM_BANKS 256
 #define NR_SHMEM_BANKS 32
 
+/* Default #address and #size cells */
+#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
+#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
+
 #define MAX_MODULES 32 /* Current maximum useful modules */
 
+#define DEVICE_TREE_MAX_DEPTH 16
+
+/* Helper to read a big number; size is in cells (not bytes) */
+static inline u64 dt_read_number(const __be32 *cell, int size)
+{
+    u64 r = 0;
+
+    while ( size-- )
+        r = (r << 32) | be32_to_cpu(*(cell++));
+    return r;
+}
+
+/* Wrapper for dt_read_number() to return paddr_t (instead of uint64_t) */
+static inline paddr_t dt_read_paddr(const __be32 *cell, int size)
+{
+    uint64_t dt_r;
+    paddr_t r;
+
+    /*
+     * dt_read_number will return uint64_t whereas paddr_t may not be 64-bit.
+     * Thus, there is an implicit cast from uint64_t to paddr_t.
+     */
+    dt_r = dt_read_number(cell, size);
+
+    if ( dt_r != (paddr_t)dt_r )
+    {
+        printk("Physical address greater than max width supported\n");
+        WARN();
+    }
+
+    /*
+     * Xen will truncate the address/size if it is greater than the maximum
+     * supported width and it will give an appropriate warning.
+     */
+    r = dt_r;
+
+    return r;
+}
+
+static inline u64 dt_next_cell(int s, const __be32 **cellp)
+{
+    const __be32 *p = *cellp;
+
+    *cellp = p + s;
+    return dt_read_number(p, s);
+}
+
+typedef int (*device_tree_node_func)(const void *fdt,
+                                     int node, const char *name, int depth,
+                                     u32 address_cells, u32 size_cells,
+                                     void *data);
+
+/**
+ * device_tree_for_each_node - iterate over all device tree sub-nodes
+ * @fdt: flat device tree.
+ * @node: parent node to start the search from
+ * @func: function to call for each sub-node.
+ * @data: data to pass to @func.
+ *
+ * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
+ *
+ * Returns 0 if all nodes were iterated over successfully.  If @func
+ * returns a value different from 0, that value is returned immediately.
+ */
+int device_tree_for_each_node(const void *fdt, int node,
+                              device_tree_node_func func,
+                              void *data);
+
 typedef enum {
     BOOTMOD_XEN,
     BOOTMOD_FDT,
@@ -260,4 +335,20 @@ static inline struct membanks *membanks_xzalloc(unsigned int nr,
     return banks;
 }
 
+/*
+ * Interpret the property `prop_name` of `node` as a u32.
+ *
+ * Returns the property value on success; otherwise returns `dflt`.
+ */
+u32 device_tree_get_u32(const void *fdt, int node,
+                        const char *prop_name, u32 dflt);
+
+/*
+ * Interpret the property `prop_name` of `node` as a "reg".
+ *
+ * Returns outputs in `start` and `size`.
+ */
+void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
+                         uint32_t size_cells, paddr_t *start, paddr_t *size);
+
 #endif /* XEN_BOOTFDT_H */
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 75017e4266..b6d16756fc 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -22,8 +22,6 @@
 #include 
 #include 
 
-#define DEVICE_TREE_MAX_DEPTH 16
-
 /*
  * Struct used for matching a device
  */
@@ -164,17 +162,8 @@ struct dt_raw_irq {
     u32 specifier[DT_MAX_IRQ_SPEC];
 };
 
-typedef int (*device_tree_node_func)(const void *fdt,
-                                     int node, const char *name, int depth,
-                                     u32 address_cells, u32 size_cells,
-                                     void *data);
-
 extern const void *device_tree_flattened;
 
-int device_tree_for_each_node(const void *fdt, int node,
-                              device_tree_node_func func,
-                              void *data);
-
 /**
  * dt_unflatten_host_device_tree - Unflatten the host device tree
  *
@@ -245,10 +234,6 @@ void intc_dt_preinit(void);
 #define dt_node_cmp(s1, s2) strcasecmp((s1), (s2))
 #define dt_compat_cmp(s1, s2) strcasecmp((s1), (s2))
 
-/* Default #address and #size cells */
-#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
-#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
-
 #define dt_for_each_property_node(dn, pp)                   \
     for ( pp = (dn)->properties; (pp) != NULL; pp = (pp)->next )
 
@@ -258,43 +243,6 @@ void intc_dt_preinit(void);
 #define dt_for_each_child_node(dt, dn)                      \
     for ( dn = (dt)->child; (dn) != NULL; dn = (dn)->sibling )
 
-/* Helper to read a big number; size is in cells (not bytes) */
-static inline u64 dt_read_number(const __be32 *cell, int size)
-{
-    u64 r = 0;
-
-    while ( size-- )
-        r = (r << 32) | be32_to_cpu(*(cell++));
-    return r;
-}
-
-/* Wrapper for dt_read_number() to return paddr_t (instead of uint64_t) */
-static inline paddr_t dt_read_paddr(const __be32 *cell, int size)
-{
-    uint64_t dt_r;
-    paddr_t r;
-
-    /*
-     * dt_read_number will return uint64_t whereas paddr_t may not be 64-bit.
-     * Thus, there is an implicit cast from uint64_t to paddr_t.
-     */
-    dt_r = dt_read_number(cell, size);
-
-    if ( dt_r != (paddr_t)dt_r )
-    {
-        printk("Physical address greater than max width supported\n");
-        WARN();
-    }
-
-    /*
-     * Xen will truncate the address/size if it is greater than the maximum
-     * supported width and it will give an appropriate warning.
-     */
-    r = dt_r;
-
-    return r;
-}
-
 /* Helper to convert a number of cells to bytes */
 static inline int dt_cells_to_size(int size)
 {
@@ -307,14 +255,6 @@ static inline int dt_size_to_cells(int bytes)
     return (bytes / sizeof(u32));
 }
 
-static inline u64 dt_next_cell(int s, const __be32 **cellp)
-{
-    const __be32 *p = *cellp;
-
-    *cellp = p + s;
-    return dt_read_number(p, s);
-}
-
 static inline const char *dt_node_full_name(const struct dt_device_node *np)
 {
     return (np && np->full_name) ? np->full_name : "";
@@ -949,12 +889,6 @@ int dt_get_pci_domain_nr(struct dt_device_node *node);
 
 struct dt_device_node *dt_find_node_by_phandle(dt_phandle handle);
 
-void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
-                         uint32_t size_cells, paddr_t *start, paddr_t *size);
-
-u32 device_tree_get_u32(const void *fdt, int node,
-                        const char *prop_name, u32 dflt);
-
 #ifdef CONFIG_DEVICE_TREE_DEBUG
 #define dt_dprintk(fmt, args...)  \
     printk(XENLOG_DEBUG fmt, ## args)
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 20 18:40:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 18:40:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021138.1397182 (Exim 4.92)
	(envelope-from )
	id 1uSgfH-0002j1-DU; Fri, 20 Jun 2025 18:40:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021138.1397182; Fri, 20 Jun 2025 18:40: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 1uSgfH-0002iu-Ao; Fri, 20 Jun 2025 18:40:39 +0000
Received: by outflank-mailman (input) for mailman id 1021138;
 Fri, 20 Jun 2025 18:40: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 1uSgVs-000575-2O
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 18:30:56 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20630.outbound.protection.outlook.com
 [2a01:111:f403:2412::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b09974c4-4e04-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 20:30:51 +0200 (CEST)
Received: from BN9PR03CA0769.namprd03.prod.outlook.com (2603:10b6:408:13a::24)
 by PH0PR12MB5647.namprd12.prod.outlook.com (2603:10b6:510:144::5)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.28; Fri, 20 Jun
 2025 18:30:43 +0000
Received: from BN1PEPF00005FFE.namprd05.prod.outlook.com
 (2603:10b6:408:13a:cafe::1f) by BN9PR03CA0769.outlook.office365.com
 (2603:10b6:408:13a::24) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8857.26 via Frontend Transport; Fri,
 20 Jun 2025 18:30:42 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN1PEPF00005FFE.mail.protection.outlook.com (10.167.243.230) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8857.21 via Frontend Transport; Fri, 20 Jun 2025 18:30:42 +0000
Received: from xcbagarciav01.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; Fri, 20 Jun
 2025 13:30:35 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b09974c4-4e04-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=BpzkX+GzIlvQ8kk6ON9FxhVrT7MI/G7z/GSK46jiX7Z/5h6QCNsgkrbaUCaX/0Zks/fT+AwN+xylMommu054qLIJMbKScaFSz4HfmfuMrh6VFkr6iqsFBE59t4ZJ6fUTjsboYmTxbWTXPZB/+++pEaJPCJB41SR50SghybwGdGS6lLpISeXwoVyEtez534EGqBPPslqLhLweOKMAT+7JLjkFMSQdo/n+YZrif1MUH/fw+OhY2qEfLIAgXPEMlkmLL0JHoz2JdRvE7EW+DVpYWnvPdbeC1G3NV9IC3gW7B+CLUG8Do7MaKAMvEUbxQhWS5hukH/LCqUVDES+Fj8dM9Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=EZ8mPV20eg3UxX25KPokn65IJOL0jNvmLs3RF/kL5p8=;
 b=xNI7sdB/YKrlLqedKWvKWm2BPVHx8wGvEhdGmSirTJBGpi5EFvBlZzoqTdh0XltPjGaNFu4lxPIB86XHnboE9WNuJx6Gr89wIsD5PVySXjspD0SBjlagq4UB4LSVfVTT04RU7EMYYEdVFITwotcjXk0Ii1bxmf4PAID5DZYuPnELCHWProIu8acLyZsPtOYffDgcTxGukRH5FlaO7V2N9pt4i8MerHqwm2MZhFq3Uf3ioNbL7TKCqA8udLg2iWHgv70OE1hyE4Uc8ZyZSas9Ri4cwiC67ZUg2V7zS5r4aQYxAkXnIQ2Lo9qBjMR9FipqYm9UUbzEsRG9JqP0pxl5ZA==
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=EZ8mPV20eg3UxX25KPokn65IJOL0jNvmLs3RF/kL5p8=;
 b=t8pVMdqkVMasl6d7C/RRUcOqZnKf4r66EuE08XN0zDy78QsimkTYzKpszSrT1ST3rwOzIkwxd7Mh1Gupv98qZWYUZXj1GldSez7ti2bV8NpldBbcIJ9Ns1+oDmq0p/405Ni3UWXigdM5iOeU0ncN63w4RFlEyqK6eQrsQyXs0H8=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Daniel P.
 Smith" 
Subject: [PATCH v4 08/12] xen/dt: Rename bootfdt.c -> bootinfo-fdt.c
Date: Fri, 20 Jun 2025 20:28:54 +0200
Message-ID: <20250620182859.23378-9-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250620182859.23378-1-agarciav@amd.com>
References: <20250620182859.23378-1-agarciav@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: BN1PEPF00005FFE:EE_|PH0PR12MB5647:EE_
X-MS-Office365-Filtering-Correlation-Id: 30c02afa-27c5-433c-2dbc-08ddb0289066
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:
	=?us-ascii?Q?+HIfRooqYYRoPuf9cWp5met9PTSLaBgwKB5nHG7jINHEGGViqykfq7e38Buw?=
 =?us-ascii?Q?FEP5YYm5wWP7uIoY0Rnw6GhOLq0JaW4k+DPwRNVMk16DYxWeawJCBKbhC39W?=
 =?us-ascii?Q?TfdhS1VCVwMCwapj8HtQUiSCNyaZrchRhkJ0xqehnNDmiGeg+UBJ7rvBZzYG?=
 =?us-ascii?Q?kkO6a6IOPEcVMV3iaunn+25U01ukXjUBy3xZ7I7ODc5ZYDluOdD/SBrkky6X?=
 =?us-ascii?Q?otJxJ142n8Fy8Iv8D9zipWXetBBQnTJ3KmVkIkqgczKF5Qb3PXsxkmxfzfuF?=
 =?us-ascii?Q?aO7CMPnky3pLuPM/LipJguCbTVWpl0Nrc8L2hRSfvVOOYtWxqRtxXVHU5pOo?=
 =?us-ascii?Q?2RhZtsWmyBXpl43Gt1qtZmXdcQ3Zh9chTnvFXJ5VO2cvoyzWWlUTcLsKxpSe?=
 =?us-ascii?Q?w175t6LaVjz0O51xZJD+IeL69gqwPg0/uIhPr4pmkSTfsGQ878/J7K/3Hf5a?=
 =?us-ascii?Q?pYuvljwzTaH+241LBnvZ3z56QaL/Nqo2KoMbFdwyUPzuLwybW+TjuSqRXNCA?=
 =?us-ascii?Q?LllkMmjWUjSr+Dye3lXfTsye6ntliqSD12D8T/g9IiB4hyLF2RrAzAg2dqjs?=
 =?us-ascii?Q?cwuFdHpyZExhNkidGJ5FpNL119P/DvFcHhvwGrBAU1VE+Qr5NmYR8A08hYcF?=
 =?us-ascii?Q?o+3hEdyO0lPbm8YQmpL/z35L4jZHdeH5F+YLsIXGsztz8RkEpCx69AoNAyMx?=
 =?us-ascii?Q?XPxgrkLLR7IEYTKkBT8Us3i2kuJLn1lkq7yoQfe68InuJGWLYP3de46rYZmk?=
 =?us-ascii?Q?VTXT7yZjm8l9FVWxuQdBYpy+sf7NLANVkupDkKexQ9NCnj540614usWnKxFg?=
 =?us-ascii?Q?J85h/3im6Ey8y2NyZItLTtZ/WEqpGnbSkPSAqJBurk3Glmxlk2MREUVcmQ/1?=
 =?us-ascii?Q?0TL3cSh60sRFQObmxcRZ1qGGCWCZKShxkKGLUD0jb2T7I8izBvwGTDiby/l/?=
 =?us-ascii?Q?9R52dpM8i1+6Cu8eW5YTRyYiKZ7JgkITYY2yV9mh0pl3h1+X4au5VsLp8AWy?=
 =?us-ascii?Q?n0zDHF4OcYY/5ae3LS1egW21bIRk26GnBGpxjwA0U7HCZ16p/zDbgjd4+QfI?=
 =?us-ascii?Q?xUKKJX4PG3/+v4NdmwMIXmedyrvG61VkSQ3rHYGdcqauHFuuUIPKfwQCtPHD?=
 =?us-ascii?Q?hD3UnxXFGZw28HISVRnVxHPoDcF+o/RjrDVnKWFQ08AwXCMuSq9fFxb62wp7?=
 =?us-ascii?Q?DfX+0HGTAm6B3pGo2QS2SSte8cfrlM/mb7KAua9A5U3oc1H1OLYcW9ZVwjge?=
 =?us-ascii?Q?ndCUjY9bD0ynQxV+cRUNMV3ZVNBqmZEj+PqXQF2NmL5K0Wtmet5TmAHC50No?=
 =?us-ascii?Q?sts259TqUBsRzXPzl+vvkKswVK+w8AajrjYpokjpyCJ+rr8jLtAFD77GxeVW?=
 =?us-ascii?Q?sNCNRjYpqfYUKA/+19HJDuFbr2WrjKf7BBOz4wWQs5m6uX9QTk+Qzrr7MPoC?=
 =?us-ascii?Q?zfOCFP8GfpwEp94FEmlhBjN+uCN+CnUO9OkeKfJ88r6n8ydyqSWOkR6bbzDb?=
 =?us-ascii?Q?vlla6SCT0CscFzVBgEftdyRECF7PRTXfLupk?=
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)(82310400026)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jun 2025 18:30:42.3852
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 30c02afa-27c5-433c-2dbc-08ddb0289066
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:
	BN1PEPF00005FFE.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB5647

This file will eventually contain bootfdt helpers that make heavy use of
bootinfo. To simplify git history do the rename here explicitly. A later
patch extracts bootinfo-independent helpers into bootfdt.c.

Doing so here would needlessly pollute the diffs.

Not a functional change.

Signed-off-by: Alejandro Vallejo 
Reviewed-by: Stefano Stabellini 
---
 xen/common/device-tree/Makefile       |   1 +
 xen/common/device-tree/bootfdt.c      | 646 +-------------------------
 xen/common/device-tree/bootinfo-fdt.c | 597 ++++++++++++++++++++++++
 3 files changed, 619 insertions(+), 625 deletions(-)
 create mode 100644 xen/common/device-tree/bootinfo-fdt.c

diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
index 13127296cb..8abc069c4b 100644
--- a/xen/common/device-tree/Makefile
+++ b/xen/common/device-tree/Makefile
@@ -1,4 +1,5 @@
 obj-y += bootfdt.init.o
+obj-y += bootinfo-fdt.init.o
 obj-y += bootinfo.init.o
 obj-y += device-tree.o
 obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.init.o
diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
index 1848478e82..0d8d9ea357 100644
--- a/xen/common/device-tree/bootfdt.c
+++ b/xen/common/device-tree/bootfdt.c
@@ -1,206 +1,8 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
-/*
- * Early Device Tree
- *
- * Copyright (C) 2012-2014 Citrix Systems, Inc.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
+#include 
+#include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-static void __init __maybe_unused build_assertions(void)
-{
-    /*
-     * Check that no padding is between struct membanks "bank" flexible array
-     * member and struct meminfo "bank" member
-     */
-    BUILD_BUG_ON((offsetof(struct membanks, bank) !=
-                 offsetof(struct meminfo, bank)));
-    /* Ensure "struct membanks" and "struct membank" are equally aligned */
-    BUILD_BUG_ON(alignof(struct membanks) != alignof(struct membank));
-}
-
-static bool __init device_tree_node_is_available(const void *fdt, int node)
-{
-    const char *status;
-    int len;
-
-    status = fdt_getprop(fdt, node, "status", &len);
-    if ( !status )
-        return true;
-
-    if ( len > 0 )
-    {
-        if ( !strcmp(status, "ok") || !strcmp(status, "okay") )
-            return true;
-    }
-
-    return false;
-}
-
-static bool __init device_tree_node_matches(const void *fdt, int node,
-                                            const char *match)
-{
-    const char *name;
-    size_t match_len;
-
-    name = fdt_get_name(fdt, node, NULL);
-    match_len = strlen(match);
-
-    /* Match both "match" and "match@..." patterns but not
-       "match-foo". */
-    return strncmp(name, match, match_len) == 0
-        && (name[match_len] == '@' || name[match_len] == '\0');
-}
-
-static bool __init device_tree_node_compatible(const void *fdt, int node,
-                                               const char *match)
-{
-    int len, l;
-    const void *prop;
-
-    prop = fdt_getprop(fdt, node, "compatible", &len);
-    if ( prop == NULL )
-        return false;
-
-    while ( len > 0 ) {
-        if ( !dt_compat_cmp(prop, match) )
-            return true;
-        l = strlen(prop) + 1;
-        prop += l;
-        len -= l;
-    }
-
-    return false;
-}
-
-/*
- * Check if a node is a proper /memory node according to Devicetree
- * Specification v0.4, chapter 3.4.
- */
-static bool __init device_tree_is_memory_node(const void *fdt, int node,
-                                              int depth)
-{
-    const char *type;
-    int len;
-
-    if ( depth != 1 )
-        return false;
-
-    if ( !device_tree_node_matches(fdt, node, "memory") )
-        return false;
-
-    type = fdt_getprop(fdt, node, "device_type", &len);
-    if ( !type )
-        return false;
-
-    if ( (len <= strlen("memory")) || strcmp(type, "memory") )
-        return false;
-
-    return true;
-}
-
-void __init device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
-                                uint32_t size_cells, paddr_t *start,
-                                paddr_t *size)
-{
-    uint64_t dt_start, dt_size;
-
-    /*
-     * dt_next_cell will return uint64_t whereas paddr_t may not be 64-bit.
-     * Thus, there is an implicit cast from uint64_t to paddr_t.
-     */
-    dt_start = dt_next_cell(address_cells, cell);
-    dt_size = dt_next_cell(size_cells, cell);
-
-    if ( dt_start != (paddr_t)dt_start )
-    {
-        printk("Physical address greater than max width supported\n");
-        WARN();
-    }
-
-    if ( dt_size != (paddr_t)dt_size )
-    {
-        printk("Physical size greater than max width supported\n");
-        WARN();
-    }
-
-    /*
-     * Xen will truncate the address/size if it is greater than the maximum
-     * supported width and it will give an appropriate warning.
-     */
-    *start = dt_start;
-    *size = dt_size;
-}
-
-static int __init device_tree_get_meminfo(const void *fdt, int node,
-                                          const char *prop_name,
-                                          u32 address_cells, u32 size_cells,
-                                          struct membanks *mem,
-                                          enum membank_type type)
-{
-    const struct fdt_property *prop;
-    unsigned int i, banks;
-    const __be32 *cell;
-    u32 reg_cells = address_cells + size_cells;
-    paddr_t start, size;
-
-    if ( !device_tree_node_is_available(fdt, node) )
-        return 0;
-
-    if ( address_cells < 1 || size_cells < 1 )
-    {
-        printk("fdt: property `%s': invalid #address-cells or #size-cells",
-               prop_name);
-        return -EINVAL;
-    }
-
-    prop = fdt_get_property(fdt, node, prop_name, NULL);
-    if ( !prop )
-        return -ENOENT;
-
-    cell = (const __be32 *)prop->data;
-    banks = fdt32_to_cpu(prop->len) / (reg_cells * sizeof (u32));
-
-    for ( i = 0; i < banks && mem->nr_banks < mem->max_banks; i++ )
-    {
-        device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
-        /*
-         * Some valid device trees, such as those generated by OpenPOWER
-         * skiboot firmware, expose all reserved memory regions in the
-         * FDT memory reservation block AND in the reserved-memory node which
-         * has already been parsed. Thus, any matching overlaps in the
-         * reserved_mem banks should be ignored.
-         */
-        if ( mem == bootinfo_get_reserved_mem() &&
-             check_reserved_regions_overlap(start, size, true) )
-            return -EINVAL;
-        /* Some DT may describe empty bank, ignore them */
-        if ( !size )
-            continue;
-        mem->bank[mem->nr_banks].start = start;
-        mem->bank[mem->nr_banks].size = size;
-        mem->bank[mem->nr_banks].type = type;
-        mem->nr_banks++;
-    }
-
-    if ( i < banks )
-    {
-        printk("Warning: Max number of supported memory regions reached.\n");
-        return -ENOSPC;
-    }
-
-    return 0;
-}
+#include 
 
 u32 __init device_tree_get_u32(const void *fdt, int node,
                                const char *prop_name, u32 dflt)
@@ -214,18 +16,6 @@ u32 __init device_tree_get_u32(const void *fdt, int node,
     return fdt32_to_cpu(*(uint32_t*)prop->data);
 }
 
-/**
- * device_tree_for_each_node - iterate over all device tree sub-nodes
- * @fdt: flat device tree.
- * @node: parent node to start the search from
- * @func: function to call for each sub-node.
- * @data: data to pass to @func.
- *
- * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
- *
- * Returns 0 if all nodes were iterated over successfully.  If @func
- * returns a value different from 0, that value is returned immediately.
- */
 int __init device_tree_for_each_node(const void *fdt, int node,
                                      device_tree_node_func func,
                                      void *data)
@@ -273,429 +63,35 @@ int __init device_tree_for_each_node(const void *fdt, int node,
     return 0;
 }
 
-static int __init process_memory_node(const void *fdt, int node,
-                                      const char *name, int depth,
-                                      u32 address_cells, u32 size_cells,
-                                      struct membanks *mem)
-{
-    return device_tree_get_meminfo(fdt, node, "reg", address_cells, size_cells,
-                                   mem, MEMBANK_DEFAULT);
-}
-
-static int __init process_reserved_memory_node(const void *fdt, int node,
-                                               const char *name, int depth,
-                                               u32 address_cells,
-                                               u32 size_cells,
-                                               void *data)
-{
-    int rc = process_memory_node(fdt, node, name, depth, address_cells,
-                                 size_cells, data);
-
-    if ( rc == -ENOSPC )
-        panic("Max number of supported reserved-memory regions reached.\n");
-    else if ( rc != -ENOENT )
-        return rc;
-    return 0;
-}
-
-static int __init process_reserved_memory(const void *fdt, int node,
-                                          const char *name, int depth,
-                                          u32 address_cells, u32 size_cells)
-{
-    return device_tree_for_each_node(fdt, node,
-                                     process_reserved_memory_node,
-                                     bootinfo_get_reserved_mem());
-}
-
-static void __init process_multiboot_node(const void *fdt, int node,
-                                          const char *name,
-                                          u32 address_cells, u32 size_cells)
-{
-    static int __initdata kind_guess = 0;
-    const struct fdt_property *prop;
-    const __be32 *cell;
-    boot_module_kind kind;
-    paddr_t start, size;
-    int len;
-    /* sizeof("/chosen/") + DT_MAX_NAME + '/' + DT_MAX_NAME + '/0' => 92 */
-    char path[92];
-    int parent_node, ret;
-    bool domU;
-
-    parent_node = fdt_parent_offset(fdt, node);
-    ASSERT(parent_node >= 0);
-
-    /* Check that the node is under "/chosen" (first 7 chars of path) */
-    ret = fdt_get_path(fdt, node, path, sizeof (path));
-    if ( ret != 0 || strncmp(path, "/chosen", 7) )
-        return;
-
-    prop = fdt_get_property(fdt, node, "reg", &len);
-    if ( !prop )
-        panic("node %s missing `reg' property\n", name);
-
-    if ( len < dt_cells_to_size(address_cells + size_cells) )
-        panic("fdt: node `%s': `reg` property length is too short\n",
-                    name);
-
-    cell = (const __be32 *)prop->data;
-    device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
-
-    if ( fdt_node_check_compatible(fdt, node, "xen,linux-zimage") == 0 ||
-         fdt_node_check_compatible(fdt, node, "multiboot,kernel") == 0 )
-        kind = BOOTMOD_KERNEL;
-    else if ( fdt_node_check_compatible(fdt, node, "xen,linux-initrd") == 0 ||
-              fdt_node_check_compatible(fdt, node, "multiboot,ramdisk") == 0 )
-        kind = BOOTMOD_RAMDISK;
-    else if ( fdt_node_check_compatible(fdt, node, "xen,xsm-policy") == 0 )
-        kind = BOOTMOD_XSM;
-    else if ( fdt_node_check_compatible(fdt, node, "multiboot,device-tree") == 0 )
-        kind = BOOTMOD_GUEST_DTB;
-    else if ( fdt_node_check_compatible(fdt, node, "multiboot,microcode") == 0 )
-        kind = BOOTMOD_MICROCODE;
-    else
-        kind = BOOTMOD_UNKNOWN;
-
-    /**
-     * Guess the kind of these first two unknowns respectively:
-     * (1) The first unknown must be kernel.
-     * (2) Detect the XSM Magic from the 2nd unknown:
-     *     a. If it's XSM, set the kind as XSM, and that also means we
-     *     won't load ramdisk;
-     *     b. if it's not XSM, set the kind as ramdisk.
-     *     So if user want to load ramdisk, it must be the 2nd unknown.
-     * We also detect the XSM Magic for the following unknowns,
-     * then set its kind according to the return value of has_xsm_magic.
-     */
-    if ( kind == BOOTMOD_UNKNOWN )
-    {
-        switch ( kind_guess++ )
-        {
-        case 0: kind = BOOTMOD_KERNEL; break;
-        case 1: kind = BOOTMOD_RAMDISK; break;
-        default: break;
-        }
-        if ( kind_guess > 1 && has_xsm_magic(start) )
-            kind = BOOTMOD_XSM;
-    }
-
-    domU = fdt_node_check_compatible(fdt, parent_node, "xen,domain") == 0;
-    add_boot_module(kind, start, size, domU);
-
-    prop = fdt_get_property(fdt, node, "bootargs", &len);
-    if ( !prop )
-        return;
-    add_boot_cmdline(fdt_get_name(fdt, parent_node, &len), prop->data,
-                     kind, start, domU);
-}
-
-static int __init process_chosen_node(const void *fdt, int node,
-                                      const char *name,
-                                      u32 address_cells, u32 size_cells)
-{
-    const struct fdt_property *prop;
-    paddr_t start, end;
-    int len;
-
-    if ( fdt_get_property(fdt, node, "xen,static-heap", NULL) )
-    {
-        int rc;
-
-        printk("Checking for static heap in /chosen\n");
-
-        rc = device_tree_get_meminfo(fdt, node, "xen,static-heap",
-                                     address_cells, size_cells,
-                                     bootinfo_get_reserved_mem(),
-                                     MEMBANK_STATIC_HEAP);
-        if ( rc )
-            return rc;
-
-        using_static_heap = true;
-    }
-
-    printk("Checking for initrd in /chosen\n");
-
-    prop = fdt_get_property(fdt, node, "linux,initrd-start", &len);
-    if ( !prop )
-        /* No initrd present. */
-        return 0;
-    if ( len != sizeof(u32) && len != sizeof(u64) )
-    {
-        printk("linux,initrd-start property has invalid length %d\n", len);
-        return -EINVAL;
-    }
-    start = dt_read_paddr((const void *)&prop->data, dt_size_to_cells(len));
-
-    prop = fdt_get_property(fdt, node, "linux,initrd-end", &len);
-    if ( !prop )
-    {
-        printk("linux,initrd-end not present but -start was\n");
-        return -EINVAL;
-    }
-    if ( len != sizeof(u32) && len != sizeof(u64) )
-    {
-        printk("linux,initrd-end property has invalid length %d\n", len);
-        return -EINVAL;
-    }
-    end = dt_read_paddr((const void *)&prop->data, dt_size_to_cells(len));
-
-    if ( start >= end )
-    {
-        printk("linux,initrd limits invalid: %"PRIpaddr" >= %"PRIpaddr"\n",
-                  start, end);
-        return -EINVAL;
-    }
-
-    printk("Initrd %"PRIpaddr"-%"PRIpaddr"\n", start, end - 1);
-
-    add_boot_module(BOOTMOD_RAMDISK, start, end-start, false);
-
-    return 0;
-}
-
-static int __init process_domain_node(const void *fdt, int node,
-                                      const char *name,
-                                      u32 address_cells, u32 size_cells)
-{
-    const struct fdt_property *prop;
-
-    printk("Checking for \"xen,static-mem\" in domain node\n");
-
-    prop = fdt_get_property(fdt, node, "xen,static-mem", NULL);
-    if ( !prop )
-        /* No "xen,static-mem" present. */
-        return 0;
-
-    return device_tree_get_meminfo(fdt, node, "xen,static-mem", address_cells,
-                                   size_cells, bootinfo_get_reserved_mem(),
-                                   MEMBANK_STATIC_DOMAIN);
-}
-
-#ifndef CONFIG_STATIC_SHM
-static inline int process_shm_node(const void *fdt, int node,
-                                   uint32_t address_cells, uint32_t size_cells)
-{
-    printk("CONFIG_STATIC_SHM must be enabled for parsing static shared"
-            " memory nodes\n");
-    return -EINVAL;
-}
-#endif
-
-static int __init early_scan_node(const void *fdt,
-                                  int node, const char *name, int depth,
-                                  u32 address_cells, u32 size_cells,
-                                  void *data)
+void __init device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
+                                uint32_t size_cells, paddr_t *start,
+                                paddr_t *size)
 {
-    int rc = 0;
+    uint64_t dt_start, dt_size;
 
     /*
-     * If Xen has been booted via UEFI, the memory banks are
-     * populated. So we should skip the parsing.
+     * dt_next_cell will return uint64_t whereas paddr_t may not be 64-bit.
+     * Thus, there is an implicit cast from uint64_t to paddr_t.
      */
-    if ( !efi_enabled(EFI_BOOT) &&
-         device_tree_is_memory_node(fdt, node, depth) )
-        rc = process_memory_node(fdt, node, name, depth,
-                                 address_cells, size_cells, bootinfo_get_mem());
-    else if ( depth == 1 && !dt_node_cmp(name, "reserved-memory") )
-        rc = process_reserved_memory(fdt, node, name, depth,
-                                     address_cells, size_cells);
-    else if ( depth <= 3 && (device_tree_node_compatible(fdt, node, "xen,multiboot-module" ) ||
-              device_tree_node_compatible(fdt, node, "multiboot,module" )))
-        process_multiboot_node(fdt, node, name, address_cells, size_cells);
-    else if ( depth == 1 && device_tree_node_matches(fdt, node, "chosen") )
-        rc = process_chosen_node(fdt, node, name, address_cells, size_cells);
-    else if ( depth == 2 && device_tree_node_compatible(fdt, node, "xen,domain") )
-        rc = process_domain_node(fdt, node, name, address_cells, size_cells);
-    else if ( depth <= 3 && device_tree_node_compatible(fdt, node, "xen,domain-shared-memory-v1") )
-        rc = process_shm_node(fdt, node, address_cells, size_cells);
-
-    if ( rc < 0 )
-        printk("fdt: node `%s': parsing failed\n", name);
-    return rc;
-}
-
-static void __init early_print_info(void)
-{
-    const struct membanks *mi = bootinfo_get_mem();
-    const struct membanks *mem_resv = bootinfo_get_reserved_mem();
-    struct boot_modules *mods = &bootinfo.modules;
-    struct bootcmdlines *cmds = &bootinfo.cmdlines;
-    unsigned int i;
-
-    for ( i = 0; i < mi->nr_banks; i++ )
-        printk("RAM: %"PRIpaddr" - %"PRIpaddr"\n",
-                mi->bank[i].start,
-                mi->bank[i].start + mi->bank[i].size - 1);
-    printk("\n");
-    for ( i = 0 ; i < mods->nr_mods; i++ )
-        printk("MODULE[%d]: %"PRIpaddr" - %"PRIpaddr" %-12s\n",
-                i,
-                mods->module[i].start,
-                mods->module[i].start + mods->module[i].size - 1,
-                boot_module_kind_as_string(mods->module[i].kind));
-
-    for ( i = 0; i < mem_resv->nr_banks; i++ )
-    {
-        printk(" RESVD[%u]: %"PRIpaddr" - %"PRIpaddr"\n", i,
-               mem_resv->bank[i].start,
-               mem_resv->bank[i].start + mem_resv->bank[i].size - 1);
-    }
-#ifdef CONFIG_STATIC_SHM
-    early_print_info_shmem();
-#endif
-    printk("\n");
-    for ( i = 0 ; i < cmds->nr_mods; i++ )
-        printk("CMDLINE[%"PRIpaddr"]:%s %s\n", cmds->cmdline[i].start,
-               cmds->cmdline[i].dt_name,
-               &cmds->cmdline[i].cmdline[0]);
-    printk("\n");
-}
-
-/* This function assumes that memory regions are not overlapped */
-static int __init cmp_memory_node(const void *key, const void *elem)
-{
-    const struct membank *handler0 = key;
-    const struct membank *handler1 = elem;
-
-    if ( handler0->start < handler1->start )
-        return -1;
-
-    if ( handler0->start >= (handler1->start + handler1->size) )
-        return 1;
-
-    return 0;
-}
-
-static void __init swap_memory_node(void *_a, void *_b, size_t size)
-{
-    struct membank *a = _a, *b = _b;
-
-    SWAP(*a, *b);
-}
-
-/**
- * boot_fdt_info - initialize bootinfo from a DTB
- * @fdt: flattened device tree binary
- *
- * Returns the size of the DTB.
- */
-size_t __init boot_fdt_info(const void *fdt, paddr_t paddr)
-{
-    struct membanks *reserved_mem = bootinfo_get_reserved_mem();
-    struct membanks *mem = bootinfo_get_mem();
-    unsigned int i;
-    int nr_rsvd;
-    int ret;
-
-    ret = fdt_check_header(fdt);
-    if ( ret < 0 )
-        panic("No valid device tree\n");
-
-    add_boot_module(BOOTMOD_FDT, paddr, fdt_totalsize(fdt), false);
-
-    nr_rsvd = fdt_num_mem_rsv(fdt);
-    if ( nr_rsvd < 0 )
-        panic("Parsing FDT memory reserve map failed (%d)\n", nr_rsvd);
+    dt_start = dt_next_cell(address_cells, cell);
+    dt_size = dt_next_cell(size_cells, cell);
 
-    for ( i = 0; i < nr_rsvd; i++ )
+    if ( dt_start != (paddr_t)dt_start )
     {
-        struct membank *bank;
-        paddr_t s, sz;
-
-        if ( fdt_get_mem_rsv_paddr(device_tree_flattened, i, &s, &sz) < 0 )
-            continue;
-
-        if ( reserved_mem->nr_banks < reserved_mem->max_banks )
-        {
-            bank = &reserved_mem->bank[reserved_mem->nr_banks];
-            bank->start = s;
-            bank->size = sz;
-            bank->type = MEMBANK_FDT_RESVMEM;
-            reserved_mem->nr_banks++;
-        }
-        else
-            panic("Cannot allocate reserved memory bank\n");
+        printk("Physical address greater than max width supported\n");
+        WARN();
     }
 
-    ret = device_tree_for_each_node(fdt, 0, early_scan_node, NULL);
-    if ( ret )
-        panic("Early FDT parsing failed (%d)\n", ret);
-
-    /*
-     * On Arm64 setup_directmap_mappings() expects to be called with the lowest
-     * bank in memory first. There is no requirement that the DT will provide
-     * the banks sorted in ascending order. So sort them through.
-     */
-    sort(mem->bank, mem->nr_banks, sizeof(struct membank),
-         cmp_memory_node, swap_memory_node);
-
-    early_print_info();
-
-    return fdt_totalsize(fdt);
-}
-
-const __init char *boot_fdt_cmdline(const void *fdt)
-{
-    int node;
-    const struct fdt_property *prop;
-
-    node = fdt_path_offset(fdt, "/chosen");
-    if ( node < 0 )
-        return NULL;
-
-    prop = fdt_get_property(fdt, node, "xen,xen-bootargs", NULL);
-    if ( prop == NULL )
+    if ( dt_size != (paddr_t)dt_size )
     {
-        struct bootcmdline *dom0_cmdline =
-            boot_cmdline_find_by_kind(BOOTMOD_KERNEL);
-
-        if (fdt_get_property(fdt, node, "xen,dom0-bootargs", NULL) ||
-            ( dom0_cmdline && dom0_cmdline->cmdline[0] ) )
-            prop = fdt_get_property(fdt, node, "bootargs", NULL);
+        printk("Physical size greater than max width supported\n");
+        WARN();
     }
-    if ( prop == NULL )
-        return NULL;
-
-    return prop->data;
-}
 
-/*
- * Wrapper to convert physical address from paddr_t to uint64_t and
- * invoke fdt_begin_node(). This is required as the physical address
- * provided as part of node name should not contain any leading
- * zeroes. Thus, one should use PRIx64 (instead of PRIpaddr) to append
- * unit (which contains the physical address) with name to generate a
- * node name.
- */
-int __init domain_fdt_begin_node(void *fdt, const char *name, uint64_t unit)
-{
     /*
-     * The size of the buffer to hold the longest possible string (i.e.
-     * interrupt-controller@ + a 64-bit number + \0).
+     * Xen will truncate the address/size if it is greater than the maximum
+     * supported width and it will give an appropriate warning.
      */
-    char buf[38];
-    int ret;
-
-    /* ePAPR 3.4 */
-    ret = snprintf(buf, sizeof(buf), "%s@%"PRIx64, name, unit);
-
-    if ( ret >= sizeof(buf) )
-    {
-        printk(XENLOG_ERR
-               "Insufficient buffer. Minimum size required is %d\n",
-               (ret + 1));
-
-        return -FDT_ERR_TRUNCATED;
-    }
-
-    return fdt_begin_node(fdt, buf);
+    *start = dt_start;
+    *size = dt_size;
 }
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/common/device-tree/bootinfo-fdt.c b/xen/common/device-tree/bootinfo-fdt.c
new file mode 100644
index 0000000000..16036472f3
--- /dev/null
+++ b/xen/common/device-tree/bootinfo-fdt.c
@@ -0,0 +1,597 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Early Device Tree with bootinfo hooks
+ *
+ * Copyright (C) 2012-2014 Citrix Systems, Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static void __init __maybe_unused build_assertions(void)
+{
+    /*
+     * Check that no padding is between struct membanks "bank" flexible array
+     * member and struct meminfo "bank" member
+     */
+    BUILD_BUG_ON((offsetof(struct membanks, bank) !=
+                 offsetof(struct meminfo, bank)));
+    /* Ensure "struct membanks" and "struct membank" are equally aligned */
+    BUILD_BUG_ON(alignof(struct membanks) != alignof(struct membank));
+}
+
+static bool __init device_tree_node_is_available(const void *fdt, int node)
+{
+    const char *status;
+    int len;
+
+    status = fdt_getprop(fdt, node, "status", &len);
+    if ( !status )
+        return true;
+
+    if ( len > 0 )
+    {
+        if ( !strcmp(status, "ok") || !strcmp(status, "okay") )
+            return true;
+    }
+
+    return false;
+}
+
+static bool __init device_tree_node_matches(const void *fdt, int node,
+                                            const char *match)
+{
+    const char *name;
+    size_t match_len;
+
+    name = fdt_get_name(fdt, node, NULL);
+    match_len = strlen(match);
+
+    /* Match both "match" and "match@..." patterns but not
+       "match-foo". */
+    return strncmp(name, match, match_len) == 0
+        && (name[match_len] == '@' || name[match_len] == '\0');
+}
+
+static bool __init device_tree_node_compatible(const void *fdt, int node,
+                                               const char *match)
+{
+    int len, l;
+    const void *prop;
+
+    prop = fdt_getprop(fdt, node, "compatible", &len);
+    if ( prop == NULL )
+        return false;
+
+    while ( len > 0 ) {
+        if ( !dt_compat_cmp(prop, match) )
+            return true;
+        l = strlen(prop) + 1;
+        prop += l;
+        len -= l;
+    }
+
+    return false;
+}
+
+/*
+ * Check if a node is a proper /memory node according to Devicetree
+ * Specification v0.4, chapter 3.4.
+ */
+static bool __init device_tree_is_memory_node(const void *fdt, int node,
+                                              int depth)
+{
+    const char *type;
+    int len;
+
+    if ( depth != 1 )
+        return false;
+
+    if ( !device_tree_node_matches(fdt, node, "memory") )
+        return false;
+
+    type = fdt_getprop(fdt, node, "device_type", &len);
+    if ( !type )
+        return false;
+
+    if ( (len <= strlen("memory")) || strcmp(type, "memory") )
+        return false;
+
+    return true;
+}
+
+static int __init device_tree_get_meminfo(const void *fdt, int node,
+                                          const char *prop_name,
+                                          u32 address_cells, u32 size_cells,
+                                          struct membanks *mem,
+                                          enum membank_type type)
+{
+    const struct fdt_property *prop;
+    unsigned int i, banks;
+    const __be32 *cell;
+    u32 reg_cells = address_cells + size_cells;
+    paddr_t start, size;
+
+    if ( !device_tree_node_is_available(fdt, node) )
+        return 0;
+
+    if ( address_cells < 1 || size_cells < 1 )
+    {
+        printk("fdt: property `%s': invalid #address-cells or #size-cells",
+               prop_name);
+        return -EINVAL;
+    }
+
+    prop = fdt_get_property(fdt, node, prop_name, NULL);
+    if ( !prop )
+        return -ENOENT;
+
+    cell = (const __be32 *)prop->data;
+    banks = fdt32_to_cpu(prop->len) / (reg_cells * sizeof (u32));
+
+    for ( i = 0; i < banks && mem->nr_banks < mem->max_banks; i++ )
+    {
+        device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
+        /*
+         * Some valid device trees, such as those generated by OpenPOWER
+         * skiboot firmware, expose all reserved memory regions in the
+         * FDT memory reservation block AND in the reserved-memory node which
+         * has already been parsed. Thus, any matching overlaps in the
+         * reserved_mem banks should be ignored.
+         */
+        if ( mem == bootinfo_get_reserved_mem() &&
+             check_reserved_regions_overlap(start, size, true) )
+            return -EINVAL;
+        /* Some DT may describe empty bank, ignore them */
+        if ( !size )
+            continue;
+        mem->bank[mem->nr_banks].start = start;
+        mem->bank[mem->nr_banks].size = size;
+        mem->bank[mem->nr_banks].type = type;
+        mem->nr_banks++;
+    }
+
+    if ( i < banks )
+    {
+        printk("Warning: Max number of supported memory regions reached.\n");
+        return -ENOSPC;
+    }
+
+    return 0;
+}
+
+static int __init process_memory_node(const void *fdt, int node,
+                                      const char *name, int depth,
+                                      u32 address_cells, u32 size_cells,
+                                      struct membanks *mem)
+{
+    return device_tree_get_meminfo(fdt, node, "reg", address_cells, size_cells,
+                                   mem, MEMBANK_DEFAULT);
+}
+
+static int __init process_reserved_memory_node(const void *fdt, int node,
+                                               const char *name, int depth,
+                                               u32 address_cells,
+                                               u32 size_cells,
+                                               void *data)
+{
+    int rc = process_memory_node(fdt, node, name, depth, address_cells,
+                                 size_cells, data);
+
+    if ( rc == -ENOSPC )
+        panic("Max number of supported reserved-memory regions reached.\n");
+    else if ( rc != -ENOENT )
+        return rc;
+    return 0;
+}
+
+static int __init process_reserved_memory(const void *fdt, int node,
+                                          const char *name, int depth,
+                                          u32 address_cells, u32 size_cells)
+{
+    return device_tree_for_each_node(fdt, node,
+                                     process_reserved_memory_node,
+                                     bootinfo_get_reserved_mem());
+}
+
+static void __init process_multiboot_node(const void *fdt, int node,
+                                          const char *name,
+                                          u32 address_cells, u32 size_cells)
+{
+    static int __initdata kind_guess = 0;
+    const struct fdt_property *prop;
+    const __be32 *cell;
+    boot_module_kind kind;
+    paddr_t start, size;
+    int len;
+    /* sizeof("/chosen/") + DT_MAX_NAME + '/' + DT_MAX_NAME + '/0' => 92 */
+    char path[92];
+    int parent_node, ret;
+    bool domU;
+
+    parent_node = fdt_parent_offset(fdt, node);
+    ASSERT(parent_node >= 0);
+
+    /* Check that the node is under "/chosen" (first 7 chars of path) */
+    ret = fdt_get_path(fdt, node, path, sizeof (path));
+    if ( ret != 0 || strncmp(path, "/chosen", 7) )
+        return;
+
+    prop = fdt_get_property(fdt, node, "reg", &len);
+    if ( !prop )
+        panic("node %s missing `reg' property\n", name);
+
+    if ( len < dt_cells_to_size(address_cells + size_cells) )
+        panic("fdt: node `%s': `reg` property length is too short\n",
+                    name);
+
+    cell = (const __be32 *)prop->data;
+    device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
+
+    if ( fdt_node_check_compatible(fdt, node, "xen,linux-zimage") == 0 ||
+         fdt_node_check_compatible(fdt, node, "multiboot,kernel") == 0 )
+        kind = BOOTMOD_KERNEL;
+    else if ( fdt_node_check_compatible(fdt, node, "xen,linux-initrd") == 0 ||
+              fdt_node_check_compatible(fdt, node, "multiboot,ramdisk") == 0 )
+        kind = BOOTMOD_RAMDISK;
+    else if ( fdt_node_check_compatible(fdt, node, "xen,xsm-policy") == 0 )
+        kind = BOOTMOD_XSM;
+    else if ( fdt_node_check_compatible(fdt, node, "multiboot,device-tree") == 0 )
+        kind = BOOTMOD_GUEST_DTB;
+    else if ( fdt_node_check_compatible(fdt, node, "multiboot,microcode") == 0 )
+        kind = BOOTMOD_MICROCODE;
+    else
+        kind = BOOTMOD_UNKNOWN;
+
+    /**
+     * Guess the kind of these first two unknowns respectively:
+     * (1) The first unknown must be kernel.
+     * (2) Detect the XSM Magic from the 2nd unknown:
+     *     a. If it's XSM, set the kind as XSM, and that also means we
+     *     won't load ramdisk;
+     *     b. if it's not XSM, set the kind as ramdisk.
+     *     So if user want to load ramdisk, it must be the 2nd unknown.
+     * We also detect the XSM Magic for the following unknowns,
+     * then set its kind according to the return value of has_xsm_magic.
+     */
+    if ( kind == BOOTMOD_UNKNOWN )
+    {
+        switch ( kind_guess++ )
+        {
+        case 0: kind = BOOTMOD_KERNEL; break;
+        case 1: kind = BOOTMOD_RAMDISK; break;
+        default: break;
+        }
+        if ( kind_guess > 1 && has_xsm_magic(start) )
+            kind = BOOTMOD_XSM;
+    }
+
+    domU = fdt_node_check_compatible(fdt, parent_node, "xen,domain") == 0;
+    add_boot_module(kind, start, size, domU);
+
+    prop = fdt_get_property(fdt, node, "bootargs", &len);
+    if ( !prop )
+        return;
+    add_boot_cmdline(fdt_get_name(fdt, parent_node, &len), prop->data,
+                     kind, start, domU);
+}
+
+static int __init process_chosen_node(const void *fdt, int node,
+                                      const char *name,
+                                      u32 address_cells, u32 size_cells)
+{
+    const struct fdt_property *prop;
+    paddr_t start, end;
+    int len;
+
+    if ( fdt_get_property(fdt, node, "xen,static-heap", NULL) )
+    {
+        int rc;
+
+        printk("Checking for static heap in /chosen\n");
+
+        rc = device_tree_get_meminfo(fdt, node, "xen,static-heap",
+                                     address_cells, size_cells,
+                                     bootinfo_get_reserved_mem(),
+                                     MEMBANK_STATIC_HEAP);
+        if ( rc )
+            return rc;
+
+        using_static_heap = true;
+    }
+
+    printk("Checking for initrd in /chosen\n");
+
+    prop = fdt_get_property(fdt, node, "linux,initrd-start", &len);
+    if ( !prop )
+        /* No initrd present. */
+        return 0;
+    if ( len != sizeof(u32) && len != sizeof(u64) )
+    {
+        printk("linux,initrd-start property has invalid length %d\n", len);
+        return -EINVAL;
+    }
+    start = dt_read_paddr((const void *)&prop->data, dt_size_to_cells(len));
+
+    prop = fdt_get_property(fdt, node, "linux,initrd-end", &len);
+    if ( !prop )
+    {
+        printk("linux,initrd-end not present but -start was\n");
+        return -EINVAL;
+    }
+    if ( len != sizeof(u32) && len != sizeof(u64) )
+    {
+        printk("linux,initrd-end property has invalid length %d\n", len);
+        return -EINVAL;
+    }
+    end = dt_read_paddr((const void *)&prop->data, dt_size_to_cells(len));
+
+    if ( start >= end )
+    {
+        printk("linux,initrd limits invalid: %"PRIpaddr" >= %"PRIpaddr"\n",
+                  start, end);
+        return -EINVAL;
+    }
+
+    printk("Initrd %"PRIpaddr"-%"PRIpaddr"\n", start, end - 1);
+
+    add_boot_module(BOOTMOD_RAMDISK, start, end-start, false);
+
+    return 0;
+}
+
+static int __init process_domain_node(const void *fdt, int node,
+                                      const char *name,
+                                      u32 address_cells, u32 size_cells)
+{
+    const struct fdt_property *prop;
+
+    printk("Checking for \"xen,static-mem\" in domain node\n");
+
+    prop = fdt_get_property(fdt, node, "xen,static-mem", NULL);
+    if ( !prop )
+        /* No "xen,static-mem" present. */
+        return 0;
+
+    return device_tree_get_meminfo(fdt, node, "xen,static-mem", address_cells,
+                                   size_cells, bootinfo_get_reserved_mem(),
+                                   MEMBANK_STATIC_DOMAIN);
+}
+
+#ifndef CONFIG_STATIC_SHM
+static inline int process_shm_node(const void *fdt, int node,
+                                   uint32_t address_cells, uint32_t size_cells)
+{
+    printk("CONFIG_STATIC_SHM must be enabled for parsing static shared"
+            " memory nodes\n");
+    return -EINVAL;
+}
+#endif
+
+static int __init early_scan_node(const void *fdt,
+                                  int node, const char *name, int depth,
+                                  u32 address_cells, u32 size_cells,
+                                  void *data)
+{
+    int rc = 0;
+
+    /*
+     * If Xen has been booted via UEFI, the memory banks are
+     * populated. So we should skip the parsing.
+     */
+    if ( !efi_enabled(EFI_BOOT) &&
+         device_tree_is_memory_node(fdt, node, depth) )
+        rc = process_memory_node(fdt, node, name, depth,
+                                 address_cells, size_cells, bootinfo_get_mem());
+    else if ( depth == 1 && !dt_node_cmp(name, "reserved-memory") )
+        rc = process_reserved_memory(fdt, node, name, depth,
+                                     address_cells, size_cells);
+    else if ( depth <= 3 && (device_tree_node_compatible(fdt, node, "xen,multiboot-module" ) ||
+              device_tree_node_compatible(fdt, node, "multiboot,module" )))
+        process_multiboot_node(fdt, node, name, address_cells, size_cells);
+    else if ( depth == 1 && device_tree_node_matches(fdt, node, "chosen") )
+        rc = process_chosen_node(fdt, node, name, address_cells, size_cells);
+    else if ( depth == 2 && device_tree_node_compatible(fdt, node, "xen,domain") )
+        rc = process_domain_node(fdt, node, name, address_cells, size_cells);
+    else if ( depth <= 3 && device_tree_node_compatible(fdt, node, "xen,domain-shared-memory-v1") )
+        rc = process_shm_node(fdt, node, address_cells, size_cells);
+
+    if ( rc < 0 )
+        printk("fdt: node `%s': parsing failed\n", name);
+    return rc;
+}
+
+static void __init early_print_info(void)
+{
+    const struct membanks *mi = bootinfo_get_mem();
+    const struct membanks *mem_resv = bootinfo_get_reserved_mem();
+    struct boot_modules *mods = &bootinfo.modules;
+    struct bootcmdlines *cmds = &bootinfo.cmdlines;
+    unsigned int i;
+
+    for ( i = 0; i < mi->nr_banks; i++ )
+        printk("RAM: %"PRIpaddr" - %"PRIpaddr"\n",
+                mi->bank[i].start,
+                mi->bank[i].start + mi->bank[i].size - 1);
+    printk("\n");
+    for ( i = 0 ; i < mods->nr_mods; i++ )
+        printk("MODULE[%d]: %"PRIpaddr" - %"PRIpaddr" %-12s\n",
+                i,
+                mods->module[i].start,
+                mods->module[i].start + mods->module[i].size - 1,
+                boot_module_kind_as_string(mods->module[i].kind));
+
+    for ( i = 0; i < mem_resv->nr_banks; i++ )
+    {
+        printk(" RESVD[%u]: %"PRIpaddr" - %"PRIpaddr"\n", i,
+               mem_resv->bank[i].start,
+               mem_resv->bank[i].start + mem_resv->bank[i].size - 1);
+    }
+#ifdef CONFIG_STATIC_SHM
+    early_print_info_shmem();
+#endif
+    printk("\n");
+    for ( i = 0 ; i < cmds->nr_mods; i++ )
+        printk("CMDLINE[%"PRIpaddr"]:%s %s\n", cmds->cmdline[i].start,
+               cmds->cmdline[i].dt_name,
+               &cmds->cmdline[i].cmdline[0]);
+    printk("\n");
+}
+
+/* This function assumes that memory regions are not overlapped */
+static int __init cmp_memory_node(const void *key, const void *elem)
+{
+    const struct membank *handler0 = key;
+    const struct membank *handler1 = elem;
+
+    if ( handler0->start < handler1->start )
+        return -1;
+
+    if ( handler0->start >= (handler1->start + handler1->size) )
+        return 1;
+
+    return 0;
+}
+
+static void __init swap_memory_node(void *_a, void *_b, size_t size)
+{
+    struct membank *a = _a, *b = _b;
+
+    SWAP(*a, *b);
+}
+
+/**
+ * boot_fdt_info - initialize bootinfo from a DTB
+ * @fdt: flattened device tree binary
+ *
+ * Returns the size of the DTB.
+ */
+size_t __init boot_fdt_info(const void *fdt, paddr_t paddr)
+{
+    struct membanks *reserved_mem = bootinfo_get_reserved_mem();
+    struct membanks *mem = bootinfo_get_mem();
+    unsigned int i;
+    int nr_rsvd;
+    int ret;
+
+    ret = fdt_check_header(fdt);
+    if ( ret < 0 )
+        panic("No valid device tree\n");
+
+    add_boot_module(BOOTMOD_FDT, paddr, fdt_totalsize(fdt), false);
+
+    nr_rsvd = fdt_num_mem_rsv(fdt);
+    if ( nr_rsvd < 0 )
+        panic("Parsing FDT memory reserve map failed (%d)\n", nr_rsvd);
+
+    for ( i = 0; i < nr_rsvd; i++ )
+    {
+        struct membank *bank;
+        paddr_t s, sz;
+
+        if ( fdt_get_mem_rsv_paddr(device_tree_flattened, i, &s, &sz) < 0 )
+            continue;
+
+        if ( reserved_mem->nr_banks < reserved_mem->max_banks )
+        {
+            bank = &reserved_mem->bank[reserved_mem->nr_banks];
+            bank->start = s;
+            bank->size = sz;
+            bank->type = MEMBANK_FDT_RESVMEM;
+            reserved_mem->nr_banks++;
+        }
+        else
+            panic("Cannot allocate reserved memory bank\n");
+    }
+
+    ret = device_tree_for_each_node(fdt, 0, early_scan_node, NULL);
+    if ( ret )
+        panic("Early FDT parsing failed (%d)\n", ret);
+
+    /*
+     * On Arm64 setup_directmap_mappings() expects to be called with the lowest
+     * bank in memory first. There is no requirement that the DT will provide
+     * the banks sorted in ascending order. So sort them through.
+     */
+    sort(mem->bank, mem->nr_banks, sizeof(struct membank),
+         cmp_memory_node, swap_memory_node);
+
+    early_print_info();
+
+    return fdt_totalsize(fdt);
+}
+
+const __init char *boot_fdt_cmdline(const void *fdt)
+{
+    int node;
+    const struct fdt_property *prop;
+
+    node = fdt_path_offset(fdt, "/chosen");
+    if ( node < 0 )
+        return NULL;
+
+    prop = fdt_get_property(fdt, node, "xen,xen-bootargs", NULL);
+    if ( prop == NULL )
+    {
+        struct bootcmdline *dom0_cmdline =
+            boot_cmdline_find_by_kind(BOOTMOD_KERNEL);
+
+        if (fdt_get_property(fdt, node, "xen,dom0-bootargs", NULL) ||
+            ( dom0_cmdline && dom0_cmdline->cmdline[0] ) )
+            prop = fdt_get_property(fdt, node, "bootargs", NULL);
+    }
+    if ( prop == NULL )
+        return NULL;
+
+    return prop->data;
+}
+
+/*
+ * Wrapper to convert physical address from paddr_t to uint64_t and
+ * invoke fdt_begin_node(). This is required as the physical address
+ * provided as part of node name should not contain any leading
+ * zeroes. Thus, one should use PRIx64 (instead of PRIpaddr) to append
+ * unit (which contains the physical address) with name to generate a
+ * node name.
+ */
+int __init domain_fdt_begin_node(void *fdt, const char *name, uint64_t unit)
+{
+    /*
+     * The size of the buffer to hold the longest possible string (i.e.
+     * interrupt-controller@ + a 64-bit number + \0).
+     */
+    char buf[38];
+    int ret;
+
+    /* ePAPR 3.4 */
+    ret = snprintf(buf, sizeof(buf), "%s@%"PRIx64, name, unit);
+
+    if ( ret >= sizeof(buf) )
+    {
+        printk(XENLOG_ERR
+               "Insufficient buffer. Minimum size required is %d\n",
+               (ret + 1));
+
+        return -FDT_ERR_TRUNCATED;
+    }
+
+    return fdt_begin_node(fdt, buf);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 20 18:40:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 18:40:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021141.1397193 (Exim 4.92)
	(envelope-from )
	id 1uSgfU-000369-Qw; Fri, 20 Jun 2025 18:40:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021141.1397193; Fri, 20 Jun 2025 18:40: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 1uSgfU-000360-Nh; Fri, 20 Jun 2025 18:40:52 +0000
Received: by outflank-mailman (input) for mailman id 1021141;
 Fri, 20 Jun 2025 18:40: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 1uSgW2-000575-A1
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 18:31:06 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20627.outbound.protection.outlook.com
 [2a01:111:f403:2414::627])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b880e9b9-4e04-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 20:31:04 +0200 (CEST)
Received: from BN9P220CA0002.NAMP220.PROD.OUTLOOK.COM (2603:10b6:408:13e::7)
 by SJ2PR12MB8831.namprd12.prod.outlook.com (2603:10b6:a03:4d0::15) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.35; Fri, 20 Jun
 2025 18:31:00 +0000
Received: from BN1PEPF00006001.namprd05.prod.outlook.com
 (2603:10b6:408:13e:cafe::ac) by BN9P220CA0002.outlook.office365.com
 (2603:10b6:408:13e::7) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8857.25 via Frontend Transport; Fri,
 20 Jun 2025 18:30:59 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN1PEPF00006001.mail.protection.outlook.com (10.167.243.233) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8857.21 via Frontend Transport; Fri, 20 Jun 2025 18:30:59 +0000
Received: from xcbagarciav01.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; Fri, 20 Jun
 2025 13:30:47 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b880e9b9-4e04-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=mozxrJBD4h806OxtW9OKjLve39slNB6SyZyg/dPERlNW7V5jhRlvDtkbjrdunxqXCedE1tVYENyACVagFJeLBCcM/NTMhMNOiS5sSAlmFhyhxWB6tVh4W9fRuRrgHyOYUtKDV6s/fyFclXl4UhykOdnJYV73bgXKHHK8EvehrQQ3/4yQ3SFvhhA5BIrirntn+BKBCmfbEjrQjvov5ZvHYV+RqHQj5/0TRSQPc/VdBGdoPg2lrkeSo44eRCpbmN5gevcnhgilnng5/hKUOx8SS9wBG9QahgPtFdpj2GIVEbfcNBNvfDctTSyEPEyTE3ncxwnXVSDHbiLgF6WuwoLBsw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=A32bMUto8OiFkZ1KkrsMiha7h5Dnym+pId15RGk2+9o=;
 b=wk35lImRWRVdtFVGzQehcpbiWy/FUyt2bSbYCJGxX4W3beybRuLaZXrTTlE1uQXKMDDPCdGYJw1G9xjawkyXe6qoUPXZ1XGOYLsnYMBgi8Ng+pMwMsUORWzbFMMjA9zPVEDynzeoRldU8psSyTsojwRdn083TCu+Vuz/ukTuV8l68PM3sYbXyPpA++scytgCv6tsK4uBUkfGmptUa97eOqUqt4h4uY+yhL/xxSTiq6AxMaLQWB4NbSYOJDephSVKX1sygzfYX0gnuMW7I/s8Cxz1e+E1TmIpY55dkb1+k3ygxlDq0QpUkQz2LiEXpfIOpHseXxaSKS+D+h5OvOUYpQ==
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=A32bMUto8OiFkZ1KkrsMiha7h5Dnym+pId15RGk2+9o=;
 b=WslG99NBfGR/mi9A3QHWERZfwNjFzgJm8LTT+nS/doAlaS0s60cbLyCOTyQeaPvNxA66LOqXhXbXn+nkL6bMtgKJhiraf0W6WrRLLZmf/Tx2pg2IWo1LtRnWT6QgCdGeD5298RVSZymaXHG575gSV4dYKgB9+ynJxUbrv9GyHnY=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , "Julien
 Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Stefano Stabellini ,
	"Bertrand Marquis" , Volodymyr Babchuk
	, Shawn Anastasio
	, Alistair Francis
	, Bob Eshleman , "Connor
 Davis" , Oleksii Kurochko
	, "Daniel P. Smith"
	, =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
	, Dario Faggioli ,
	Juergen Gross , George Dunlap 
Subject: [PATCH v4 10/12] xen: Rename CONFIG_HAS_DEVICE_TREE to CONFIG_HAS_DEVICE_TREE_DISCOVERY
Date: Fri, 20 Jun 2025 20:28:56 +0200
Message-ID: <20250620182859.23378-11-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250620182859.23378-1-agarciav@amd.com>
References: <20250620182859.23378-1-agarciav@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: BN1PEPF00006001:EE_|SJ2PR12MB8831:EE_
X-MS-Office365-Filtering-Correlation-Id: 8e779e40-3b20-45e6-e1b9-08ddb0289a9c
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|36860700013|7416014|82310400026|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?dhSB5tap1s11sJOUrHMp0sckU/ioFXl3DoOZmxWrZ5icsDlmFxb8my/QNpxl?=
 =?us-ascii?Q?rWIWaN3YyBCMSzFI48mqKZMN0mMPHpO5AiIsXsIe9pW6Tafi8lQAadjEnK2X?=
 =?us-ascii?Q?jo9MKQHvP7pThB/oP14hWmnPEZTAsvNXEBHifaJNzVc/YUqfPPuaIyglWMLo?=
 =?us-ascii?Q?UGxzIkkdsOKsWXpO7HfzvwlPx7bBM0vHWYtxjHEXI42Ifep0FmIj/doIIyiN?=
 =?us-ascii?Q?/lUjlszqSJTjskfTEexV8zH8yino4GdDEmqQeG0d9IqXZKHzyll+KvN/YnSU?=
 =?us-ascii?Q?+4nYwX8p/wYsH+yJg6Xaamuu/PkoO270+q1ISe+nxudIvzsr4p/7YOV5qaKN?=
 =?us-ascii?Q?t8uxBhAU0MV98iwXHp+XqGG/GbIgVsV8rG0ju2PIwIQqesuEjjdpLYhhf3XX?=
 =?us-ascii?Q?ebDXFIHimcKlOGaeAXPF2vN7W4TDzg+AlpyAfvDvv7+sIh/5O0NxmmPvjhfa?=
 =?us-ascii?Q?V9SkIHpNf/geVQoxBxYQdoQoFGNgf813rlM/EPscedndzhl2+2zqxPn3BY2C?=
 =?us-ascii?Q?xULPoPE+UK4aldjikNLkum0ubfd9iEHSUS0hnNa2+4j9oRcTS4mKPQIefY08?=
 =?us-ascii?Q?FSTHs5DHydeRWsb/DZko1AYeuhT3IRBK37J0VKfB9uyPqea5TmuaNqKf0IaN?=
 =?us-ascii?Q?AkBTGVJk/aMcpc4g4hxXmfsXkCwXuxhhnq1L9NwTyWABPF8JkrsVeY1SvKeh?=
 =?us-ascii?Q?cxXrAKU6vYdMqTfr7chBAZOUWgriyAw0/VeIOfDB9KD26uoEr6zzL7Jvc+Dq?=
 =?us-ascii?Q?5y9DjD2lEpv3XwTCNS807M15Tbfl8qofXowbtgqvMIDD1n/zsN/e7RPQGbd1?=
 =?us-ascii?Q?1TSEhgILVpd2bo0CSXXdaXKH2UXfnySiFX8zXYblQ5SClPcQrFzp/IRv3H9e?=
 =?us-ascii?Q?j5wqNID3zxO0K9NxHCaPzvrLagmkz2BPCbhZsH3G5TzJLSFZnqtW7bc8UITy?=
 =?us-ascii?Q?tQohckZAQNM4pdDEgF+tryV5Lh9kGanPDCnSk3+/QxtJR0SgPgP5CKZ/oi/I?=
 =?us-ascii?Q?T7e9pfU6/g8k/9h01152nwHnLEbFm8/L2otZSGKARebl5mSTts+2v4MxQEiU?=
 =?us-ascii?Q?Rp4vqk30ELvKwZJp5PlltK/hOVebphhjEeFZ9ftZ7FS9p5EEHaKnAkPWy6v5?=
 =?us-ascii?Q?HbOR5xXCpvxbOOE+YtLy77RFSVgdTJgZ8hXMLUilL9n8MEKwsMrZKMhqH/1b?=
 =?us-ascii?Q?6mkrq/UB1sAJUNu31/MSpSMv0oO1vDsSceJmJfrU3Vn2j7NnrMfg+E3k7etl?=
 =?us-ascii?Q?7r54vrSIl4GEE2CucQLzdn+tyAmXP7lW7g106Re2qKoUZs+mxmPI6TJSD+fG?=
 =?us-ascii?Q?6H2e9iUNbvQtArSyioi0A4PZTHDY3V6GcFkcwVSLwnChkVeLfVqN7dEziWzm?=
 =?us-ascii?Q?n9CVBH3Mn7isIyuJW93tdkYXuaFH9+JPqZculZMQwbNBOec7/7AhrUJ79IAU?=
 =?us-ascii?Q?ZBI+4jb+lGqWY8ey6zwS1O2Vw13Ig5B6x0TrfHJcPgW4NBTXMhOkb29wWR8N?=
 =?us-ascii?Q?9uEmTYE+BVLSfL+DUPPR2s6EH95f6zh9UYaF?=
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)(7416014)(82310400026)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jun 2025 18:30:59.5119
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 8e779e40-3b20-45e6-e1b9-08ddb0289a9c
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:
	BN1PEPF00006001.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB8831

Moving forward the idea is for there to be:
  1. Basic DT support: used by dom0less/hyperlaunch.
  2. Full DT support: used for device discovery and HW setup.

Rename HAS_DEVICE_TREE to HAS_DEVICE_TREE_DISCOVERY to describe (2), while
DOM0LESS_BOOT is left to describe (1).

Signed-off-by: Alejandro Vallejo 
---
 xen/Kconfig.debug                |  2 +-
 xen/arch/arm/Kconfig             |  2 +-
 xen/arch/ppc/Kconfig             |  2 +-
 xen/arch/riscv/Kconfig           |  2 +-
 xen/common/Kconfig               |  6 +++---
 xen/common/Makefile              |  4 ++--
 xen/common/device.c              |  4 ++--
 xen/common/efi/boot.c            |  2 +-
 xen/common/sched/Kconfig         |  2 +-
 xen/drivers/char/ns16550.c       |  6 +++---
 xen/drivers/passthrough/Makefile |  2 +-
 xen/drivers/passthrough/iommu.c  |  2 +-
 xen/include/asm-generic/device.h | 10 +++++-----
 xen/include/xen/iommu.h          |  8 ++++----
 xen/include/xsm/dummy.h          |  4 ++--
 xen/include/xsm/xsm.h            | 12 ++++++------
 xen/xsm/dummy.c                  |  2 +-
 xen/xsm/flask/hooks.c            |  6 +++---
 xen/xsm/xsm_core.c               |  4 ++--
 xen/xsm/xsm_policy.c             |  4 ++--
 20 files changed, 43 insertions(+), 43 deletions(-)

diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index d14093017e..9192d593a7 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -92,7 +92,7 @@ config VERBOSE_DEBUG
 
 config DEVICE_TREE_DEBUG
 	bool "Device tree debug messages"
-	depends on HAS_DEVICE_TREE
+	depends on HAS_DEVICE_TREE_DISCOVERY
 	help
 	  Device tree parsing and DOM0 device tree building messages are
 	  logged in the Xen ring buffer.
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 3f25da3ca5..74b16f7167 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -15,7 +15,7 @@ config ARM
 	select FUNCTION_ALIGNMENT_4B
 	select GENERIC_UART_INIT
 	select HAS_ALTERNATIVE if HAS_VMAP
-	select HAS_DEVICE_TREE
+	select HAS_DEVICE_TREE_DISCOVERY
 	select HAS_DOM0LESS
 	select HAS_GRANT_CACHE_FLUSH if GRANT_TABLE
 	select HAS_STACK_PROTECTOR
diff --git a/xen/arch/ppc/Kconfig b/xen/arch/ppc/Kconfig
index 917f5d53a6..5bedf6055e 100644
--- a/xen/arch/ppc/Kconfig
+++ b/xen/arch/ppc/Kconfig
@@ -1,7 +1,7 @@
 config PPC
 	def_bool y
 	select FUNCTION_ALIGNMENT_4B
-	select HAS_DEVICE_TREE
+	select HAS_DEVICE_TREE_DISCOVERY
 	select HAS_UBSAN
 	select HAS_VMAP
 
diff --git a/xen/arch/riscv/Kconfig b/xen/arch/riscv/Kconfig
index 62c5b7ba34..8fd3c314ea 100644
--- a/xen/arch/riscv/Kconfig
+++ b/xen/arch/riscv/Kconfig
@@ -2,7 +2,7 @@ config RISCV
 	def_bool y
 	select FUNCTION_ALIGNMENT_16B
 	select GENERIC_BUG_FRAME
-	select HAS_DEVICE_TREE
+	select HAS_DEVICE_TREE_DISCOVERY
 	select HAS_PMAP
 	select HAS_UBSAN
 	select HAS_VMAP
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 867710134a..6294cd7939 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -14,7 +14,7 @@ config CORE_PARKING
 
 config DOM0LESS_BOOT
 	bool "Dom0less boot support" if EXPERT
-	depends on HAS_DOM0LESS && HAS_DEVICE_TREE && DOMAIN_BUILD_HELPERS
+	depends on HAS_DOM0LESS && HAS_DEVICE_TREE_DISCOVERY && DOMAIN_BUILD_HELPERS
 	default y
 	help
 	  Dom0less boot support enables Xen to create and start domU guests during
@@ -85,7 +85,7 @@ config HAS_ALTERNATIVE
 config HAS_COMPAT
 	bool
 
-config HAS_DEVICE_TREE
+config HAS_DEVICE_TREE_DISCOVERY
 	bool
 	select LIBFDT
 
@@ -553,7 +553,7 @@ config DOM0_MEM
 
 config DTB_FILE
 	string "Absolute path to device tree blob"
-	depends on HAS_DEVICE_TREE
+	depends on HAS_DEVICE_TREE_DISCOVERY
 	help
 	  When using a bootloader that has no device tree support or when there
 	  is no bootloader at all, use this option to specify the absolute path
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 98f0873056..d541fbcf49 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -6,9 +6,9 @@ obj-$(CONFIG_HYPFS_CONFIG) += config_data.o
 obj-$(CONFIG_CORE_PARKING) += core_parking.o
 obj-y += cpu.o
 obj-$(CONFIG_DEBUG_TRACE) += debugtrace.o
-obj-$(CONFIG_HAS_DEVICE_TREE) += device.o
+obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += device.o
 obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) += device.o
-obj-$(CONFIG_HAS_DEVICE_TREE) += device-tree/
+obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += device-tree/
 obj-$(CONFIG_IOREQ_SERVER) += dm.o
 obj-y += domain.o
 obj-y += event_2l.o
diff --git a/xen/common/device.c b/xen/common/device.c
index 33e0d58f2f..0c0afad49f 100644
--- a/xen/common/device.c
+++ b/xen/common/device.c
@@ -11,7 +11,7 @@
 
 #include 
 
-#ifdef CONFIG_HAS_DEVICE_TREE
+#ifdef CONFIG_HAS_DEVICE_TREE_DISCOVERY
 
 extern const struct device_desc _sdevice[], _edevice[];
 
@@ -56,7 +56,7 @@ enum device_class device_get_class(const struct dt_device_node *dev)
     return DEVICE_UNKNOWN;
 }
 
-#endif
+#endif /* CONFIG_HAS_DEVICE_TREE_DISCOVERY */
 
 #ifdef CONFIG_ACPI
 
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index e39fbc3529..0ead1381c8 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -601,7 +601,7 @@ static int __init __maybe_unused set_color(uint32_t mask, int bpp,
    return max(*pos + *sz, bpp);
 }
 
-#ifndef CONFIG_HAS_DEVICE_TREE
+#ifndef CONFIG_HAS_DEVICE_TREE_DISCOVERY
 static int __init efi_check_dt_boot(const EFI_LOADED_IMAGE *loaded_image)
 {
     return 0;
diff --git a/xen/common/sched/Kconfig b/xen/common/sched/Kconfig
index 18ca1ce7ab..1fb622e6cf 100644
--- a/xen/common/sched/Kconfig
+++ b/xen/common/sched/Kconfig
@@ -67,7 +67,7 @@ endmenu
 
 config BOOT_TIME_CPUPOOLS
 	bool "Create cpupools at boot time"
-	depends on HAS_DEVICE_TREE
+	depends on HAS_DEVICE_TREE_DISCOVERY
 	help
 	  Creates cpupools during boot time and assigns cpus to them. Cpupools
 	  options can be specified in the device tree.
diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index eaeb0e09d0..b060e502f3 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -34,7 +34,7 @@
 #include 
 #include 
 #include 
-#ifdef CONFIG_HAS_DEVICE_TREE
+#ifdef CONFIG_HAS_DEVICE_TREE_DISCOVERY
 #include 
 #endif
 #ifdef CONFIG_X86
@@ -1754,7 +1754,7 @@ void __init ns16550_init(int index, struct ns16550_defaults *defaults)
 
 #endif /* CONFIG_X86 */
 
-#ifdef CONFIG_HAS_DEVICE_TREE
+#ifdef CONFIG_HAS_DEVICE_TREE_DISCOVERY
 static int __init ns16550_uart_dt_init(struct dt_device_node *dev,
                                        const void *data)
 {
@@ -1833,7 +1833,7 @@ DT_DEVICE_START(ns16550, "NS16550 UART", DEVICE_SERIAL)
         .init = ns16550_uart_dt_init,
 DT_DEVICE_END
 
-#endif /* HAS_DEVICE_TREE */
+#endif /* HAS_DEVICE_TREE_DISCOVERY */
 
 #if defined(CONFIG_ACPI) && defined(CONFIG_ARM)
 #include 
diff --git a/xen/drivers/passthrough/Makefile b/xen/drivers/passthrough/Makefile
index a1621540b7..eb4aeafb42 100644
--- a/xen/drivers/passthrough/Makefile
+++ b/xen/drivers/passthrough/Makefile
@@ -5,6 +5,6 @@ obj-$(CONFIG_ARM) += arm/
 
 obj-y += iommu.o
 obj-$(CONFIG_HAS_PCI) += pci.o
-obj-$(CONFIG_HAS_DEVICE_TREE) += device_tree.o
+obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += device_tree.o
 obj-$(CONFIG_HAS_PCI) += ats.o
 obj-$(CONFIG_HAS_PCI_MSI) += msi.o
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 16aad86973..c9425d6971 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -638,7 +638,7 @@ int iommu_do_domctl(
     ret = iommu_do_pci_domctl(domctl, d, u_domctl);
 #endif
 
-#ifdef CONFIG_HAS_DEVICE_TREE
+#ifdef CONFIG_HAS_DEVICE_TREE_DISCOVERY
     if ( ret == -ENODEV )
         ret = iommu_do_dt_domctl(domctl, d, u_domctl);
 #endif
diff --git a/xen/include/asm-generic/device.h b/xen/include/asm-generic/device.h
index 1acd1ba1d8..3bd97e33c5 100644
--- a/xen/include/asm-generic/device.h
+++ b/xen/include/asm-generic/device.h
@@ -6,7 +6,7 @@
 
 enum device_type
 {
-#ifdef CONFIG_HAS_DEVICE_TREE
+#ifdef CONFIG_HAS_DEVICE_TREE_DISCOVERY
     DEV_DT,
 #endif
     DEV_PCI
@@ -26,7 +26,7 @@ enum device_class
 struct device
 {
     enum device_type type;
-#ifdef CONFIG_HAS_DEVICE_TREE
+#ifdef CONFIG_HAS_DEVICE_TREE_DISCOVERY
     struct dt_device_node *of_node; /* Used by drivers imported from Linux */
 #endif
 #ifdef CONFIG_HAS_PASSTHROUGH
@@ -37,7 +37,7 @@ struct device
 
 typedef struct device device_t;
 
-#ifdef CONFIG_HAS_DEVICE_TREE
+#ifdef CONFIG_HAS_DEVICE_TREE_DISCOVERY
 
 #include 
 
@@ -87,9 +87,9 @@ struct device_desc {
     int (*init)(struct dt_device_node *dev, const void *data);
 };
 
-#else /* !CONFIG_HAS_DEVICE_TREE */
+#else /* !CONFIG_HAS_DEVICE_TREE_DISCOVERY */
 #define dev_is_dt(dev) ((void)(dev), false)
-#endif /* CONFIG_HAS_DEVICE_TREE */
+#endif /* CONFIG_HAS_DEVICE_TREE_DISCOVERY */
 
 #define dev_is_pci(dev) ((dev)->type == DEV_PCI)
 
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 832775754b..5483840645 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -230,7 +230,7 @@ struct msi_msg;
 #define PT_IRQ_TIME_OUT MILLISECS(8)
 #endif /* HAS_PCI */
 
-#ifdef CONFIG_HAS_DEVICE_TREE
+#ifdef CONFIG_HAS_DEVICE_TREE_DISCOVERY
 #include 
 
 #ifdef CONFIG_HAS_PASSTHROUGH
@@ -288,7 +288,7 @@ static inline int iommu_release_dt_devices(struct domain *d)
 
 #endif /* HAS_PASSTHROUGH */
 
-#endif /* HAS_DEVICE_TREE */
+#endif /* HAS_DEVICE_TREE_DISCOVERY */
 
 struct page_info;
 
@@ -355,7 +355,7 @@ struct iommu_ops {
     int (*get_reserved_device_memory)(iommu_grdm_t *func, void *ctxt);
     void (*dump_page_tables)(struct domain *d);
 
-#ifdef CONFIG_HAS_DEVICE_TREE
+#ifdef CONFIG_HAS_DEVICE_TREE_DISCOVERY
     /*
      * All IOMMU drivers which support generic IOMMU DT bindings should use
      * this callback. This is a way for the framework to provide the driver
@@ -403,7 +403,7 @@ struct domain_iommu {
     /* iommu_ops */
     const struct iommu_ops *platform_ops;
 
-#ifdef CONFIG_HAS_DEVICE_TREE
+#ifdef CONFIG_HAS_DEVICE_TREE_DISCOVERY
     /* List of DT devices assigned to this domain */
     struct list_head dt_devices;
 #endif
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 9227205fcd..12792c3a43 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -423,7 +423,7 @@ static XSM_INLINE int cf_check xsm_deassign_device(
 
 #endif /* HAS_PASSTHROUGH && HAS_PCI */
 
-#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_DEVICE_TREE)
+#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_DEVICE_TREE_DISCOVERY)
 static XSM_INLINE int cf_check xsm_assign_dtdevice(
     XSM_DEFAULT_ARG struct domain *d, const char *dtpath)
 {
@@ -438,7 +438,7 @@ static XSM_INLINE int cf_check xsm_deassign_dtdevice(
     return xsm_default_action(action, current->domain, d);
 }
 
-#endif /* HAS_PASSTHROUGH && HAS_DEVICE_TREE */
+#endif /* HAS_PASSTHROUGH && HAS_DEVICE_TREE_DISCOVERY */
 
 static XSM_INLINE int cf_check xsm_resource_plug_core(XSM_DEFAULT_VOID)
 {
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 24acc16125..abeb4b04ad 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -125,7 +125,7 @@ struct xsm_ops {
     int (*deassign_device)(struct domain *d, uint32_t machine_bdf);
 #endif
 
-#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_DEVICE_TREE)
+#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_DEVICE_TREE_DISCOVERY)
     int (*assign_dtdevice)(struct domain *d, const char *dtpath);
     int (*deassign_dtdevice)(struct domain *d, const char *dtpath);
 #endif
@@ -535,7 +535,7 @@ static inline int xsm_deassign_device(
 }
 #endif /* HAS_PASSTHROUGH && HAS_PCI) */
 
-#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_DEVICE_TREE)
+#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_DEVICE_TREE_DISCOVERY)
 static inline int xsm_assign_dtdevice(
     xsm_default_t def, struct domain *d, const char *dtpath)
 {
@@ -548,7 +548,7 @@ static inline int xsm_deassign_dtdevice(
     return alternative_call(xsm_ops.deassign_dtdevice, d, dtpath);
 }
 
-#endif /* HAS_PASSTHROUGH && HAS_DEVICE_TREE */
+#endif /* HAS_PASSTHROUGH && HAS_DEVICE_TREE_DISCOVERY */
 
 static inline int xsm_resource_plug_pci(xsm_default_t def, uint32_t machine_bdf)
 {
@@ -789,7 +789,7 @@ int xsm_multiboot_policy_init(
     struct boot_info *bi, void **policy_buffer, size_t *policy_size);
 #endif
 
-#ifdef CONFIG_HAS_DEVICE_TREE
+#ifdef CONFIG_HAS_DEVICE_TREE_DISCOVERY
 /*
  * Initialize XSM
  *
@@ -839,7 +839,7 @@ static inline int xsm_multiboot_init(struct boot_info *bi)
 }
 #endif
 
-#ifdef CONFIG_HAS_DEVICE_TREE
+#ifdef CONFIG_HAS_DEVICE_TREE_DISCOVERY
 static inline int xsm_dt_init(void)
 {
     return 0;
@@ -849,7 +849,7 @@ static inline bool has_xsm_magic(paddr_t start)
 {
     return false;
 }
-#endif /* CONFIG_HAS_DEVICE_TREE */
+#endif /* CONFIG_HAS_DEVICE_TREE_DISCOVERY */
 
 #endif /* CONFIG_XSM */
 
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 93fbfc43cc..7f67683839 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -81,7 +81,7 @@ static const struct xsm_ops __initconst_cf_clobber dummy_ops = {
     .deassign_device               = xsm_deassign_device,
 #endif
 
-#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_DEVICE_TREE)
+#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_DEVICE_TREE_DISCOVERY)
     .assign_dtdevice               = xsm_assign_dtdevice,
     .deassign_dtdevice             = xsm_deassign_dtdevice,
 #endif
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 6a53487ea4..78bad6e56b 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1456,7 +1456,7 @@ static int cf_check flask_deassign_device(
 }
 #endif /* HAS_PASSTHROUGH && HAS_PCI */
 
-#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_DEVICE_TREE)
+#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_DEVICE_TREE_DISCOVERY)
 static int flask_test_assign_dtdevice(const char *dtpath)
 {
     uint32_t rsid;
@@ -1517,7 +1517,7 @@ static int cf_check flask_deassign_dtdevice(
     return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__REMOVE_DEVICE,
                                 NULL);
 }
-#endif /* HAS_PASSTHROUGH && HAS_DEVICE_TREE */
+#endif /* HAS_PASSTHROUGH && HAS_DEVICE_TREE_DISCOVERY */
 
 static int cf_check flask_platform_op(uint32_t op)
 {
@@ -1981,7 +1981,7 @@ static const struct xsm_ops __initconst_cf_clobber flask_ops = {
     .deassign_device = flask_deassign_device,
 #endif
 
-#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_DEVICE_TREE)
+#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_DEVICE_TREE_DISCOVERY)
     .assign_dtdevice = flask_assign_dtdevice,
     .deassign_dtdevice = flask_deassign_dtdevice,
 #endif
diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c
index f255fb63bf..b7e864a874 100644
--- a/xen/xsm/xsm_core.c
+++ b/xen/xsm/xsm_core.c
@@ -25,7 +25,7 @@
 #include 
 #endif
 
-#ifdef CONFIG_HAS_DEVICE_TREE
+#ifdef CONFIG_HAS_DEVICE_TREE_DISCOVERY
 #include 
 #endif
 
@@ -166,7 +166,7 @@ int __init xsm_multiboot_init(struct boot_info *bi)
 }
 #endif
 
-#ifdef CONFIG_HAS_DEVICE_TREE
+#ifdef CONFIG_HAS_DEVICE_TREE_DISCOVERY
 int __init xsm_dt_init(void)
 {
     int ret = 0;
diff --git a/xen/xsm/xsm_policy.c b/xen/xsm/xsm_policy.c
index 1b4030edb4..3f04375347 100644
--- a/xen/xsm/xsm_policy.c
+++ b/xen/xsm/xsm_policy.c
@@ -24,7 +24,7 @@
 #include 
 #endif
 #include 
-#ifdef CONFIG_HAS_DEVICE_TREE
+#ifdef CONFIG_HAS_DEVICE_TREE_DISCOVERY
 # include 
 # include 
 #endif
@@ -65,7 +65,7 @@ int __init xsm_multiboot_policy_init(
 }
 #endif
 
-#ifdef CONFIG_HAS_DEVICE_TREE
+#ifdef CONFIG_HAS_DEVICE_TREE_DISCOVERY
 int __init xsm_dt_policy_init(void **policy_buffer, size_t *policy_size)
 {
     struct boot_module *mod = boot_module_find_by_kind(BOOTMOD_XSM);
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 20 18:41:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 18:41:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021147.1397203 (Exim 4.92)
	(envelope-from )
	id 1uSgfi-0003bH-2v; Fri, 20 Jun 2025 18:41:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021147.1397203; Fri, 20 Jun 2025 18:41: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 1uSgfh-0003bA-Vz; Fri, 20 Jun 2025 18:41:05 +0000
Received: by outflank-mailman (input) for mailman id 1021147;
 Fri, 20 Jun 2025 18:41: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 1uSgW7-000575-0O
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 18:31:11 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20613.outbound.protection.outlook.com
 [2a01:111:f403:2418::613])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bb8539aa-4e04-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 20:31:09 +0200 (CEST)
Received: from BN9PR03CA0764.namprd03.prod.outlook.com (2603:10b6:408:13a::19)
 by SA3PR12MB9130.namprd12.prod.outlook.com (2603:10b6:806:37f::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.30; Fri, 20 Jun
 2025 18:31:06 +0000
Received: from BN1PEPF00005FFE.namprd05.prod.outlook.com
 (2603:10b6:408:13a:cafe::6c) by BN9PR03CA0764.outlook.office365.com
 (2603:10b6:408:13a::19) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8857.25 via Frontend Transport; Fri,
 20 Jun 2025 18:31:06 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN1PEPF00005FFE.mail.protection.outlook.com (10.167.243.230) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8857.21 via Frontend Transport; Fri, 20 Jun 2025 18:31:06 +0000
Received: from xcbagarciav01.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; Fri, 20 Jun
 2025 13:30:59 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bb8539aa-4e04-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=kMhqa1kTIYCf4NzWImT5JpH49AqwHqfKfygSxTixuJF3OK3syOg6QcCXEEBRhHDlNBmy0+LWoaDG87tQUl4C++3oJHq/JiM0k4ZH3u6KwBYNFIpa6z9kT35mvUMTBsE1KF7zJcLBDdBv5F323Ha6mLzUOZWzBwyBs8lc/+GIPjPwenOWh/vrHoCboinaDtajr3KKGo2QVsm1I0V0W+JgW4gZBmWEv410O9tH9nf1che0ai67CeOEoeywca8esPhhxpAdJnQG8plcVE9VltbQbolvARVKpdNw7Pul0sUdyotZeVJq0pgc2COo9hJfsWhA6yrdK5g2Tam4zRN1eypTpA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=snID8HzNzcBZgNFX9WTQWN+pDYAdWe59wYWpzaONW8Y=;
 b=kATa3HSdtbpe8kH6R54jP8YlQUMXmiHHi7amhjo17I6GetDaC6ffHP+//zW4Q7padOWQ6FUms3BbEhFsWfoy3Td389AmnicIRieDzdeQuxNgGmsuNmr7LCtwmdii7Co9n6SIvPFvy1+YrbXHv9zazI5ba4Mt/qE6MlXkxuoAvX/QmNbhiTrw+gq7pEnyl9gmBJonl+toOdcrAsP3TKD13gkL+dAovgFhA/0wIVVe37f2bIcpuj/N+OdDq78XD6t/dDFtuOU5r1xGgYMdpz/JGcupkeALdqnyJc4n2yBBHMmn8yP1zuNT7BtbGpkwzw8g/izomcPUCjv/pxlv2n7qGQ==
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=snID8HzNzcBZgNFX9WTQWN+pDYAdWe59wYWpzaONW8Y=;
 b=LI1JO43DhjthShNzR2/bHOnfgF/imP8KpPPuCGpWvKtc45sXYR5Sovd1cNX2pCG5J6HPKdxU4o2QM4W17JuZ4wycQamY7YEOtNE3j2jMwGxc4P4AzZWgx4bwbR7mcnScOH/c6qBUGmLuv4KPI0mD2wDcMo+tyrQ3PpzH8hdKO/8=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel 
Subject: [PATCH v4 11/12] xen/dt: ifdef out DEV_DT-related bits from device_tree.{c,h}
Date: Fri, 20 Jun 2025 20:28:57 +0200
Message-ID: <20250620182859.23378-12-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250620182859.23378-1-agarciav@amd.com>
References: <20250620182859.23378-1-agarciav@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: BN1PEPF00005FFE:EE_|SA3PR12MB9130:EE_
X-MS-Office365-Filtering-Correlation-Id: 2ce9a183-c907-4f46-5cf8-08ddb0289e97
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?TfBK87mEFmQtlBvOFCb0Q5j94IKmNtlgARgfkKbTNQIzzTJX4a+vacDscdnL?=
 =?us-ascii?Q?2u3mw0Ux6SVMtzL8HkaFXq9rBoB2oAt5668hET1AQmS7e2u3bfP996odCcyx?=
 =?us-ascii?Q?9idS+umbhswHRXWzqXdHd/bxGyZlnJTPeQQJDRX+4nVFDyplOMaeRYxVdFQr?=
 =?us-ascii?Q?sFod2OkVuGlyShKVJ3XEPIOYXExTsrCWVptvLFHtQqWnLwYS/HExXDWamQum?=
 =?us-ascii?Q?ksHiomdVbNRATKM9fYa7ninLBuVtOXPaQD3Iun7AKsrsPWUy6Wt6h4MnmSdP?=
 =?us-ascii?Q?z5HdsoLKQ1j3vrb1VmGFz5kh+veeFDzZW+wYh9VvHd8OMiDPwR1j6hBidt7G?=
 =?us-ascii?Q?sc3irhczOr34BE5P+RH3hny5C3vEVmmdA6IT7NVABJ0EnK3fF4sM90l7wvi1?=
 =?us-ascii?Q?HDWD779Vj7PYj7/KDQfqveWL29qVKZXKxwRerLxU9FVfKXPvBQ8D0e+Pwfjs?=
 =?us-ascii?Q?orj18Xamw3NkF2t1rkDsSxEnj04y/CBA5N7k9Tk09j0QGzR144LRgEfV+oUc?=
 =?us-ascii?Q?B6PvfgNbuoKKy8gLGxgrpMRF1XvxXzVwn9Z0OYmW9sAnydMButJ6BELQbXRP?=
 =?us-ascii?Q?wYW+ZaBbc01umpPRA+ir9qNCUxhU81uuRq0E9JJfevKtDhPh2QfC5j9Dt8tU?=
 =?us-ascii?Q?d2Ty+VXBaYoBD0SHcbz+Bub3bNJL6n5wsTv4hMxhV2F8FRo/Jkql5I9e5rzM?=
 =?us-ascii?Q?J7dJLh6w8AImC2a01mrZrqTjNo0OIY9o+/s8wQlDBJHrHlbTmZ9htJXRN0N6?=
 =?us-ascii?Q?VqfWe/UecKl+DdGjZXEwy3WNuJmmfpkYiqa2uRK1o4Qu4NJYaGhb89VQ09Hm?=
 =?us-ascii?Q?n/cVcWnGcqEJAh8n1u8EW2abUBS/LVGITP22aypwG0PcYxof/GC/0oLVnw3D?=
 =?us-ascii?Q?JnLEM15AJnmVZTjMVkIxm/rbff3S5XtlQ8kTsWd/nByZdwDBaomZ/scdWgMw?=
 =?us-ascii?Q?3iZKdRIvj0OMPDdzgWvXIzU8RrdAhpy3fIECQILqbszjPgxrdQNt4eCUuJaA?=
 =?us-ascii?Q?tprWWphLb4J4sddHcM2v5WynsZ0hzRSBPoy82nAazD8uSDXo4mYhZErg8glG?=
 =?us-ascii?Q?5DXPKKq3PtUvoyfbFu/Bp8piXcDZ/wUih9GjJuG0i7Km5iFHc/Uy8MQJXOyL?=
 =?us-ascii?Q?luy5hHbr2tEoWw3meDaTpqUBGijZ38d/sU5p40Na6yrdYRuAoPkdtI+m/y6S?=
 =?us-ascii?Q?RuvpQo4fXvxbsq+C93b4kJazoNZvsGiao/CaJvm3PBYSysuLiRpM8mDQMfgk?=
 =?us-ascii?Q?rinVj3YV9v/dW1X51w0DQq9D8Mig3GIbx09mj+mlhAcPlreo/YlJWELEU1Ee?=
 =?us-ascii?Q?9Pii/w6/NKuxv/BpKM54Zks0ZuCe7ESvT3RtZutZvfc0brPOvEAYgMoVQhFz?=
 =?us-ascii?Q?WeuOvzOmWnGhkj494uiPyN1jAbEKgZ+aof4fNNxvRVtNiW/yH0MDSQgYY82c?=
 =?us-ascii?Q?vO13gh2sh8ILDZhQP113ZmeIkoQtYHjTJzX6Kzb5tZaFMhXxIJWxiUU/Xg3g?=
 =?us-ascii?Q?pGl3STkqJnins4O/l7193l9nhU10gMc8mJF1?=
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: 20 Jun 2025 18:31:06.1177
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 2ce9a183-c907-4f46-5cf8-08ddb0289e97
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:
	BN1PEPF00005FFE.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR12MB9130

device-tree.c stops requiring CONFIG_HAS_DEVICE_TREE_DISCOVERY and may
function with DOM0LESS_BOOT.

Without this, there's a clash with x86's definition of device_t. Because
x86 doesn't discover devices in the DT it can simply skip the code
to do so during the unflattening phase.

Not a functional change on architectures that currently use these files,
as they already select CONFIG_HAS_DEVICE_TREE_DISCOVERY.

Signed-off-by: Alejandro Vallejo 
---
 xen/common/device-tree/device-tree.c | 2 ++
 xen/include/xen/device_tree.h        | 4 ++++
 2 files changed, 6 insertions(+)

diff --git a/xen/common/device-tree/device-tree.c b/xen/common/device-tree/device-tree.c
index 725ff71646..741e2ce585 100644
--- a/xen/common/device-tree/device-tree.c
+++ b/xen/common/device-tree/device-tree.c
@@ -2029,9 +2029,11 @@ static unsigned long unflatten_dt_node(const void *fdt,
             ((char *)pp->value)[sz - 1] = 0;
             dt_dprintk("fixed up name for %s -> %s\n", pathp,
                        (char *)pp->value);
+#ifdef CONFIG_HAS_DEVICE_TREE_DISCOVERY
             /* Generic device initialization */
             np->dev.type = DEV_DT;
             np->dev.of_node = np;
+#endif /* CONFIG_HAS_DEVICE_TREE_DISCOVERY */
         }
     }
     if ( allnextpp )
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index b6d16756fc..ace7fc3274 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -108,9 +108,12 @@ struct dt_device_node {
      */
     struct list_head domain_list;
 
+#ifdef CONFIG_HAS_DEVICE_TREE_DISCOVERY
     struct device dev;
+#endif /* CONFIG_HAS_DEVICE_TREE_DISCOVERY */
 };
 
+#ifdef CONFIG_HAS_DEVICE_TREE_DISCOVERY
 #define dt_to_dev(dt_node)  (&(dt_node)->dev)
 
 static inline struct dt_device_node *dev_to_dt(struct device *dev)
@@ -119,6 +122,7 @@ static inline struct dt_device_node *dev_to_dt(struct device *dev)
 
     return container_of(dev, struct dt_device_node, dev);
 }
+#endif /* CONFIG_HAS_DEVICE_TREE_DISCOVERY */
 
 #define MAX_PHANDLE_ARGS 16
 struct dt_phandle_args {
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 20 18:41:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 18:41:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021150.1397213 (Exim 4.92)
	(envelope-from )
	id 1uSgfm-00041Z-E3; Fri, 20 Jun 2025 18:41:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021150.1397213; Fri, 20 Jun 2025 18:41: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 1uSgfm-00040m-A2; Fri, 20 Jun 2025 18:41:10 +0000
Received: by outflank-mailman (input) for mailman id 1021150;
 Fri, 20 Jun 2025 18:41: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 1uSgVe-00057I-Ka
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 18:30:42 +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 ab178746-4e04-11f0-a30e-13f23c93f187;
 Fri, 20 Jun 2025 20:30:41 +0200 (CEST)
Received: from BN1PR14CA0024.namprd14.prod.outlook.com (2603:10b6:408:e3::29)
 by DS0PR12MB7533.namprd12.prod.outlook.com (2603:10b6:8:132::19) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.35; Fri, 20 Jun
 2025 18:30:35 +0000
Received: from BN1PEPF00005FFD.namprd05.prod.outlook.com
 (2603:10b6:408:e3:cafe::17) by BN1PR14CA0024.outlook.office365.com
 (2603:10b6:408:e3::29) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8857.25 via Frontend Transport; Fri,
 20 Jun 2025 18:30:35 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN1PEPF00005FFD.mail.protection.outlook.com (10.167.243.229) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8857.21 via Frontend Transport; Fri, 20 Jun 2025 18:30:35 +0000
Received: from xcbagarciav01.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; Fri, 20 Jun
 2025 13:30:26 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ab178746-4e04-11f0-a30e-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=BZpmjO+Jf7rMoiom6E1ZkrlOnt7o6ixKdV9wnBmEVCxfe5GRXx8zQRUIKmBNeDoXnZ8L7r2R29QbecyWyzlY0OhtOaXXZ0xg6r5GOGTqHIMxnqZWjtj34SKYi/8YgCe/K4f0aQ8/Y33u95iggrUxdWDKYi+R2SjprFA44lrV39qpDIJS+VrxCUDVsusYgEz1FPyEiInwGDu33+XIIdWxwD75vunSVXD3dNebZGlVb+PZzAdN22EfW8UCSSPKCaZAZomRpHW9+lwAVUVzJMRrVTokebgjLUdgg6nR2Wcvpv6fGS02N2WNawdB2vGexVT0+ba0eQ7k+YEbdk67YbfO4Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=/7py0bQBo16Si/KjYQcTanGTQKRE2T2hwTwQgY2DPHQ=;
 b=pnmSZziiSmCKMnZuyP//htyVDi4I1jUdwRFUy6Detm8vN72YqFLo5oYd5na17CyPfRd9dT8GIxgb2FAaWCK2EyfwO4l2ZHo7iyagKHKyc0IPvGvrE1IZ8cy6p/3dKB6lR1yCr4n7/c/L+A9aTwLjbeHFwpFdRDoMVntzcJ6tuoafYIHJsDAPI3TOaiZq7/XplaiHw/jiO7T4NxFSdaNJwLBWL+4G6v+JEjCYPmfDUKgZv9bwWI7GEAIaYT0yNP+B6TiV3MYS5ixYEmL1VbHk9sxOzUqL6uApaDU+glG5mQ7PAGvr75vH1vxqF0fRGmGt8in+EuNaUgMCUSWIZHgLYA==
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=/7py0bQBo16Si/KjYQcTanGTQKRE2T2hwTwQgY2DPHQ=;
 b=UbLL6PH+HXEMqjdu0Ldi+TT3FYg5+vE9I95f+Yz0+2WqKGjaKPIb0835/aV877WpGO5dOyYaKhGaCBflNNue7tOfM0U2YyALHWcPsLxWwa97ttpWVl4ZAPBUB/kshz5vKaCEfH7RbHsH8G9crC6dTu0jNpybrDymhIspj2uwW88=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , 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 
Subject: [PATCH v4 07/12] xen/dt: Move bootinfo functions to a new bootinfo.h
Date: Fri, 20 Jun 2025 20:28:53 +0200
Message-ID: <20250620182859.23378-8-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250620182859.23378-1-agarciav@amd.com>
References: <20250620182859.23378-1-agarciav@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: BN1PEPF00005FFD:EE_|DS0PR12MB7533:EE_
X-MS-Office365-Filtering-Correlation-Id: 392694c6-6cdb-465c-11cf-08ddb0288c43
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|82310400026|7416014|376014|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?Is4FzcyOgkal7AIRyc2RH4JzTWYxvs+Bi8doAslcjEh40FZerm7IB82LqWtX?=
 =?us-ascii?Q?hMADqXU5Ach0BzDTBFJanPuoutk44asAdEzi9JC7xD5h2aCwuk+Wnqs5pm1U?=
 =?us-ascii?Q?L6CK+zY0A3kFNl3Y3x8Cr5P6GQsgwYSY54XS+ZOQaDFgBH3NsqfGWNHVJtJ8?=
 =?us-ascii?Q?OLxB9bzEavbubnN75QR+TBC0sP11P/VzoYlpsrnAWeYwHVABmzQWQ0mGO0oP?=
 =?us-ascii?Q?NjWutlMHY7Awjyhdhyi/cDpec4i1gl5f27el7bK/d2XrVC4i7+GS/7MZt1CW?=
 =?us-ascii?Q?dSILrPhqhHLHUVma29tGEnpzFGDaNiCgv0oFWBCgZOb2sJqs4W43ih6oqoTL?=
 =?us-ascii?Q?8U7l4bv3VY2DA12AocdJC9ispD7hJIRZ57pTjnt7v+m00VPgMvu+odI4kLSY?=
 =?us-ascii?Q?fsVHnBirrgySviYWYMOWocb0S94ApagiaD/Idh7akKjWZhh4QcfG5tTfaFrU?=
 =?us-ascii?Q?6QA9tMJ9RvDPGddrJgzGW4U0+G57bvillrn7j9Ubyx/zP7QvNamxN6sCarEk?=
 =?us-ascii?Q?pZAVxHkP/t6C/LyvJq4nR0sPScCfuJYQ43OrEERf9PN0PzC89i4HmJjJ6zng?=
 =?us-ascii?Q?Gobx8/43GeHat+RfwAjw/oPYM+Oh4iBj37fmcI3sr3HRfBOJJEwhVMsANdlZ?=
 =?us-ascii?Q?dADEY3n2ThZ42qqbgybl/3rdVGWCHHe/LjT7Dgu2F0XXpEWsjEQiB/3g6YJZ?=
 =?us-ascii?Q?+ldvGkL4PS20i7IxCsWrk/oGD/KWfiiN6A0EgQgsiRsmJ/9SmsE6Lmi8CNHs?=
 =?us-ascii?Q?7Ve8MSkYlwO44vQnLJNWf/Zl90yvGrpikcMI5+KhhTb5K4ST2klF9f8v7iKS?=
 =?us-ascii?Q?8dxSYSw+rxOMfQGSrNeKd36Wz8JPP7Ut9jJozpj/UansO4Lny8sq6YlhApjR?=
 =?us-ascii?Q?Umix20kIHC2RReOiL83gM/IQ2BQRPC+Jpmiu54L4KfEvkpFATBWdT7vSVem7?=
 =?us-ascii?Q?K9YXpLlH2qJo+3VbFId1DSh1QnnTArz8hR839sIeyeJswtYpPzNdkDC0qko/?=
 =?us-ascii?Q?+0WXXpEgniBXA8J9BJR78qm4mro7PF+hoTg6nIUCf6CTko7Mnzt2NqCeO05D?=
 =?us-ascii?Q?qXn4V5BzswbijCZlIZh1wpGJW6z4Sl5XVKo4Y/UpXlwe6inTAvzNY32z4g20?=
 =?us-ascii?Q?pjvzoy4L30zC9PDibTZubyT+5gKsdlGL701IIIRrLSf2rf8l705I897JJo7/?=
 =?us-ascii?Q?DGzYFNnDOpw+G17SBnBnGAeQr/wuut+iQ4pKN3594JVO+2kFWTt7gx6/udFW?=
 =?us-ascii?Q?q0J+jRzSrdS0oODkiNohWtIr30RAxKYDmyv7EyiuxqA+BGKjt3ys9i2xJgAa?=
 =?us-ascii?Q?51tShAwYE1jQeMiH3FYzAUO9IEL/9dEf9EbNGAf5m3MYp0OJKPX8JdE5kwEz?=
 =?us-ascii?Q?/FDmKEKktecINfZghGQ/oJkjlsDSUjXkVyXdZ4jqBqkxJ/qoXrkj3+sR+UQ6?=
 =?us-ascii?Q?9DSNegNtR35L4l5fwR5vG4+hnQ1ymJyYuIyTxHdFc0DJAp1QNgy4/RYPlszG?=
 =?us-ascii?Q?j1nN0cj2NzPn2iOymF3VdNgwORikk9KdqfNV?=
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)(7416014)(376014)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jun 2025 18:30:35.4445
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 392694c6-6cdb-465c-11cf-08ddb0288c43
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:
	BN1PEPF00005FFD.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB7533

Part of an unpicking process to extract bootfdt contents independent of
bootinfo to a separate file for x86 to take.

With this, bootfdt.h can be cleanly included from x86. A later patch
extracts the definitions so the functions may be called too.

Not a functional change.

Signed-off-by: Alejandro Vallejo 
Reviewed-by: Stefano Stabellini 
---
v4:
  * Replace bootfdt.h in arm/setup.h with bootinfo.h
---
 xen/arch/arm/domain_build.c             |   1 +
 xen/arch/arm/include/asm/setup.h        |   2 +-
 xen/arch/arm/setup.c                    |   1 +
 xen/arch/riscv/mm.c                     |   2 +-
 xen/arch/riscv/setup.c                  |   2 +-
 xen/common/device-tree/bootfdt.c        |   2 +-
 xen/common/device-tree/bootinfo.c       |   2 +-
 xen/common/device-tree/dom0less-build.c |   2 +-
 xen/common/device-tree/domain-build.c   |   2 +-
 xen/common/device-tree/kernel.c         |   2 +-
 xen/include/xen/bootfdt.h               | 208 -----------------------
 xen/include/xen/bootinfo.h              | 213 ++++++++++++++++++++++++
 xen/include/xen/fdt-domain-build.h      |   2 +-
 xen/include/xen/fdt-kernel.h            |   2 +-
 14 files changed, 225 insertions(+), 218 deletions(-)
 create mode 100644 xen/include/xen/bootinfo.h

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index fb577f816f..822f7430bd 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1,5 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
index 2b58549c1a..418b7d53b5 100644
--- a/xen/arch/arm/include/asm/setup.h
+++ b/xen/arch/arm/include/asm/setup.h
@@ -3,7 +3,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #if defined(CONFIG_MMU)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 58acc2d0d4..28fe1de3e2 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -8,6 +8,7 @@
  * Copyright (c) 2011 Citrix Systems.
  */
 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
index 774ea42f2d..1ef015f179 100644
--- a/xen/arch/riscv/mm.c
+++ b/xen/arch/riscv/mm.c
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 8bcd19218d..3e99e2e194 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -2,7 +2,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
index 39334d6205..1848478e82 100644
--- a/xen/common/device-tree/bootfdt.c
+++ b/xen/common/device-tree/bootfdt.c
@@ -5,7 +5,7 @@
  * Copyright (C) 2012-2014 Citrix Systems, Inc.
  */
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/device-tree/bootinfo.c b/xen/common/device-tree/bootinfo.c
index 2a27d1318b..00a43fb358 100644
--- a/xen/common/device-tree/bootinfo.c
+++ b/xen/common/device-tree/bootinfo.c
@@ -10,7 +10,7 @@
  */
 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
index e321747175..4413b17aac 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/device-tree/domain-build.c b/xen/common/device-tree/domain-build.c
index 51182d10ef..b97206c917 100644
--- a/xen/common/device-tree/domain-build.c
+++ b/xen/common/device-tree/domain-build.c
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/device-tree/kernel.c b/xen/common/device-tree/kernel.c
index 7a00768e6b..7f73520388 100644
--- a/xen/common/device-tree/kernel.c
+++ b/xen/common/device-tree/kernel.c
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index 0846317f30..ad6b11cb6d 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -5,10 +5,7 @@
 #include 
 #include 
 #include 
-#include 
 #include 
-#include 
-#include 
 
 #if __has_include()
 #include 
@@ -16,15 +13,10 @@
 
 #define MIN_FDT_ALIGN 8
 
-#define NR_MEM_BANKS 256
-#define NR_SHMEM_BANKS 32
-
 /* Default #address and #size cells */
 #define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
 #define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
 
-#define MAX_MODULES 32 /* Current maximum useful modules */
-
 #define DEVICE_TREE_MAX_DEPTH 16
 
 /* Helper to read a big number; size is in cells (not bytes) */
@@ -104,78 +96,6 @@ typedef enum {
     BOOTMOD_UNKNOWN
 }  boot_module_kind;
 
-enum membank_type {
-    /*
-     * The MEMBANK_DEFAULT type refers to either reserved memory for the
-     * device/firmware (when the bank is in 'reserved_mem') or any RAM (when
-     * the bank is in 'mem').
-     */
-    MEMBANK_DEFAULT,
-    /*
-     * The MEMBANK_STATIC_DOMAIN type is used to indicate whether the memory
-     * bank is bound to a static Xen domain. It is only valid when the bank
-     * is in reserved_mem.
-     */
-    MEMBANK_STATIC_DOMAIN,
-    /*
-     * The MEMBANK_STATIC_HEAP type is used to indicate whether the memory
-     * bank is reserved as static heap. It is only valid when the bank is
-     * in reserved_mem.
-     */
-    MEMBANK_STATIC_HEAP,
-    /*
-     * The MEMBANK_FDT_RESVMEM type is used to indicate whether the memory
-     * bank is from the FDT reserve map.
-     */
-    MEMBANK_FDT_RESVMEM,
-};
-
-enum region_type {
-    MEMORY,
-    RESERVED_MEMORY,
-    STATIC_SHARED_MEMORY
-};
-
-/* Indicates the maximum number of characters(\0 included) for shm_id */
-#define MAX_SHM_ID_LENGTH 16
-
-struct shmem_membank_extra {
-    char shm_id[MAX_SHM_ID_LENGTH];
-    unsigned int nr_shm_borrowers;
-};
-
-struct membank {
-    paddr_t start;
-    paddr_t size;
-    union {
-        enum membank_type type;
-#ifdef CONFIG_STATIC_SHM
-        struct shmem_membank_extra *shmem_extra;
-#endif
-    };
-};
-
-struct membanks {
-    __struct_group(membanks_hdr, common, ,
-        unsigned int nr_banks;
-        unsigned int max_banks;
-        enum region_type type;
-    );
-    struct membank bank[];
-};
-
-struct meminfo {
-    struct membanks_hdr common;
-    struct membank bank[NR_MEM_BANKS];
-};
-
-struct shared_meminfo {
-    struct membanks_hdr common;
-    struct membank bank[NR_SHMEM_BANKS];
-    struct shmem_membank_extra extra[NR_SHMEM_BANKS];
-};
-
-
 struct boot_domain {
     struct domain *d;
 
@@ -207,134 +127,6 @@ struct boot_module {
 #endif
 };
 
-/* DT_MAX_NAME is the node name max length according the DT spec */
-#define DT_MAX_NAME 41
-struct bootcmdline {
-    boot_module_kind kind;
-    bool domU;
-    paddr_t start;
-    char dt_name[DT_MAX_NAME];
-    char cmdline[BOOTMOD_MAX_CMDLINE];
-};
-
-struct boot_modules {
-    int nr_mods;
-    struct boot_module module[MAX_MODULES];
-};
-
-struct bootcmdlines {
-    unsigned int nr_mods;
-    struct bootcmdline cmdline[MAX_MODULES];
-};
-
-struct bootinfo {
-    struct meminfo mem;
-    /* The reserved regions are only used when booting using Device-Tree */
-    struct meminfo reserved_mem;
-    struct boot_modules modules;
-    struct bootcmdlines cmdlines;
-#ifdef CONFIG_ACPI
-    struct meminfo acpi;
-#endif
-#ifdef CONFIG_STATIC_SHM
-    struct shared_meminfo shmem;
-#endif
-};
-
-#ifdef CONFIG_ACPI
-#define BOOTINFO_ACPI_INIT                          \
-    .acpi.common.max_banks = NR_MEM_BANKS,          \
-    .acpi.common.type = MEMORY,
-#else
-#define BOOTINFO_ACPI_INIT
-#endif
-
-#ifdef CONFIG_STATIC_SHM
-#define BOOTINFO_SHMEM_INIT                         \
-    .shmem.common.max_banks = NR_SHMEM_BANKS,       \
-    .shmem.common.type = STATIC_SHARED_MEMORY,
-#else
-#define BOOTINFO_SHMEM_INIT
-#endif
-
-#define BOOTINFO_INIT                               \
-{                                                   \
-    .mem.common.max_banks = NR_MEM_BANKS,           \
-    .mem.common.type = MEMORY,                      \
-    .reserved_mem.common.max_banks = NR_MEM_BANKS,  \
-    .reserved_mem.common.type = RESERVED_MEMORY,    \
-    BOOTINFO_ACPI_INIT                              \
-    BOOTINFO_SHMEM_INIT                             \
-}
-
-extern struct bootinfo bootinfo;
-
-bool check_reserved_regions_overlap(paddr_t region_start,
-                                    paddr_t region_size,
-                                    bool allow_memreserve_overlap);
-
-struct boot_module *add_boot_module(boot_module_kind kind,
-                                   paddr_t start, paddr_t size, bool domU);
-struct boot_module *boot_module_find_by_kind(boot_module_kind kind);
-struct boot_module * boot_module_find_by_addr_and_kind(boot_module_kind kind,
-                                                             paddr_t start);
-void add_boot_cmdline(const char *name, const char *cmdline,
-                      boot_module_kind kind, paddr_t start, bool domU);
-struct bootcmdline *boot_cmdline_find_by_kind(boot_module_kind kind);
-struct bootcmdline * boot_cmdline_find_by_name(const char *name);
-const char *boot_module_kind_as_string(boot_module_kind kind);
-
-void populate_boot_allocator(void);
-
-size_t boot_fdt_info(const void *fdt, paddr_t paddr);
-
-const char *boot_fdt_cmdline(const void *fdt);
-int domain_fdt_begin_node(void *fdt, const char *name, uint64_t unit);
-
-static inline struct membanks *bootinfo_get_reserved_mem(void)
-{
-    return container_of(&bootinfo.reserved_mem.common, struct membanks, common);
-}
-
-static inline struct membanks *bootinfo_get_mem(void)
-{
-    return container_of(&bootinfo.mem.common, struct membanks, common);
-}
-
-#ifdef CONFIG_ACPI
-static inline struct membanks *bootinfo_get_acpi(void)
-{
-    return container_of(&bootinfo.acpi.common, struct membanks, common);
-}
-#endif
-
-#ifdef CONFIG_STATIC_SHM
-static inline struct membanks *bootinfo_get_shmem(void)
-{
-    return container_of(&bootinfo.shmem.common, struct membanks, common);
-}
-
-static inline struct shmem_membank_extra *bootinfo_get_shmem_extra(void)
-{
-    return bootinfo.shmem.extra;
-}
-#endif
-
-static inline struct membanks *membanks_xzalloc(unsigned int nr,
-                                                enum region_type type)
-{
-    struct membanks *banks = xzalloc_flex_struct(struct membanks, bank, nr);
-
-    if ( !banks )
-        goto out;
-
-    banks->max_banks = nr;
-    banks->type = type;
-
- out:
-    return banks;
-}
-
 /*
  * Interpret the property `prop_name` of `node` as a u32.
  *
diff --git a/xen/include/xen/bootinfo.h b/xen/include/xen/bootinfo.h
new file mode 100644
index 0000000000..f834f19571
--- /dev/null
+++ b/xen/include/xen/bootinfo.h
@@ -0,0 +1,213 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef XEN_BOOTINFO_H
+#define XEN_BOOTINFO_H
+
+#include 
+#include 
+#include 
+#include 
+
+#define NR_MEM_BANKS 256
+#define NR_SHMEM_BANKS 32
+
+#define MAX_MODULES 32 /* Current maximum useful modules */
+
+enum membank_type {
+    /*
+     * The MEMBANK_DEFAULT type refers to either reserved memory for the
+     * device/firmware (when the bank is in 'reserved_mem') or any RAM (when
+     * the bank is in 'mem').
+     */
+    MEMBANK_DEFAULT,
+    /*
+     * The MEMBANK_STATIC_DOMAIN type is used to indicate whether the memory
+     * bank is bound to a static Xen domain. It is only valid when the bank
+     * is in reserved_mem.
+     */
+    MEMBANK_STATIC_DOMAIN,
+    /*
+     * The MEMBANK_STATIC_HEAP type is used to indicate whether the memory
+     * bank is reserved as static heap. It is only valid when the bank is
+     * in reserved_mem.
+     */
+    MEMBANK_STATIC_HEAP,
+    /*
+     * The MEMBANK_FDT_RESVMEM type is used to indicate whether the memory
+     * bank is from the FDT reserve map.
+     */
+    MEMBANK_FDT_RESVMEM,
+};
+
+enum region_type {
+    MEMORY,
+    RESERVED_MEMORY,
+    STATIC_SHARED_MEMORY
+};
+
+/* Indicates the maximum number of characters(\0 included) for shm_id */
+#define MAX_SHM_ID_LENGTH 16
+
+struct shmem_membank_extra {
+    char shm_id[MAX_SHM_ID_LENGTH];
+    unsigned int nr_shm_borrowers;
+};
+
+struct membank {
+    paddr_t start;
+    paddr_t size;
+    union {
+        enum membank_type type;
+#ifdef CONFIG_STATIC_SHM
+        struct shmem_membank_extra *shmem_extra;
+#endif
+    };
+};
+
+struct membanks {
+    __struct_group(membanks_hdr, common, ,
+        unsigned int nr_banks;
+        unsigned int max_banks;
+        enum region_type type;
+    );
+    struct membank bank[];
+};
+
+struct meminfo {
+    struct membanks_hdr common;
+    struct membank bank[NR_MEM_BANKS];
+};
+
+struct shared_meminfo {
+    struct membanks_hdr common;
+    struct membank bank[NR_SHMEM_BANKS];
+    struct shmem_membank_extra extra[NR_SHMEM_BANKS];
+};
+
+/* DT_MAX_NAME is the node name max length according the DT spec */
+#define DT_MAX_NAME 41
+struct bootcmdline {
+    boot_module_kind kind;
+    bool domU;
+    paddr_t start;
+    char dt_name[DT_MAX_NAME];
+    char cmdline[BOOTMOD_MAX_CMDLINE];
+};
+
+struct boot_modules {
+    int nr_mods;
+    struct boot_module module[MAX_MODULES];
+};
+
+struct bootcmdlines {
+    unsigned int nr_mods;
+    struct bootcmdline cmdline[MAX_MODULES];
+};
+
+struct bootinfo {
+    struct meminfo mem;
+    /* The reserved regions are only used when booting using Device-Tree */
+    struct meminfo reserved_mem;
+    struct boot_modules modules;
+    struct bootcmdlines cmdlines;
+#ifdef CONFIG_ACPI
+    struct meminfo acpi;
+#endif
+#ifdef CONFIG_STATIC_SHM
+    struct shared_meminfo shmem;
+#endif
+};
+
+#ifdef CONFIG_ACPI
+#define BOOTINFO_ACPI_INIT                          \
+    .acpi.common.max_banks = NR_MEM_BANKS,          \
+    .acpi.common.type = MEMORY,
+#else
+#define BOOTINFO_ACPI_INIT
+#endif
+
+#ifdef CONFIG_STATIC_SHM
+#define BOOTINFO_SHMEM_INIT                         \
+    .shmem.common.max_banks = NR_SHMEM_BANKS,       \
+    .shmem.common.type = STATIC_SHARED_MEMORY,
+#else
+#define BOOTINFO_SHMEM_INIT
+#endif
+
+#define BOOTINFO_INIT                               \
+{                                                   \
+    .mem.common.max_banks = NR_MEM_BANKS,           \
+    .mem.common.type = MEMORY,                      \
+    .reserved_mem.common.max_banks = NR_MEM_BANKS,  \
+    .reserved_mem.common.type = RESERVED_MEMORY,    \
+    BOOTINFO_ACPI_INIT                              \
+    BOOTINFO_SHMEM_INIT                             \
+}
+
+extern struct bootinfo bootinfo;
+
+bool check_reserved_regions_overlap(paddr_t region_start,
+                                    paddr_t region_size,
+                                    bool allow_memreserve_overlap);
+
+struct boot_module *add_boot_module(boot_module_kind kind,
+                                    paddr_t start, paddr_t size, bool domU);
+struct boot_module *boot_module_find_by_kind(boot_module_kind kind);
+struct boot_module * boot_module_find_by_addr_and_kind(boot_module_kind kind,
+                                                             paddr_t start);
+void add_boot_cmdline(const char *name, const char *cmdline,
+                      boot_module_kind kind, paddr_t start, bool domU);
+struct bootcmdline *boot_cmdline_find_by_kind(boot_module_kind kind);
+struct bootcmdline * boot_cmdline_find_by_name(const char *name);
+const char *boot_module_kind_as_string(boot_module_kind kind);
+
+void populate_boot_allocator(void);
+
+size_t boot_fdt_info(const void *fdt, paddr_t paddr);
+const char *boot_fdt_cmdline(const void *fdt);
+int domain_fdt_begin_node(void *fdt, const char *name, uint64_t unit);
+
+static inline struct membanks *bootinfo_get_reserved_mem(void)
+{
+    return container_of(&bootinfo.reserved_mem.common, struct membanks, common);
+}
+
+static inline struct membanks *bootinfo_get_mem(void)
+{
+    return container_of(&bootinfo.mem.common, struct membanks, common);
+}
+
+#ifdef CONFIG_ACPI
+static inline struct membanks *bootinfo_get_acpi(void)
+{
+    return container_of(&bootinfo.acpi.common, struct membanks, common);
+}
+#endif
+
+#ifdef CONFIG_STATIC_SHM
+static inline struct membanks *bootinfo_get_shmem(void)
+{
+    return container_of(&bootinfo.shmem.common, struct membanks, common);
+}
+
+static inline struct shmem_membank_extra *bootinfo_get_shmem_extra(void)
+{
+    return bootinfo.shmem.extra;
+}
+#endif
+
+static inline struct membanks *membanks_xzalloc(unsigned int nr,
+                                                enum region_type type)
+{
+    struct membanks *banks = xzalloc_flex_struct(struct membanks, bank, nr);
+
+    if ( !banks )
+        goto out;
+
+    banks->max_banks = nr;
+    banks->type = type;
+
+ out:
+    return banks;
+}
+
+#endif /* XEN_BOOTINFO_H */
diff --git a/xen/include/xen/fdt-domain-build.h b/xen/include/xen/fdt-domain-build.h
index 45981dbec0..60565fdbf9 100644
--- a/xen/include/xen/fdt-domain-build.h
+++ b/xen/include/xen/fdt-domain-build.h
@@ -3,7 +3,7 @@
 #ifndef __XEN_FDT_DOMAIN_BUILD_H__
 #define __XEN_FDT_DOMAIN_BUILD_H__
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/include/xen/fdt-kernel.h b/xen/include/xen/fdt-kernel.h
index fee8eac1db..ee29aad9fe 100644
--- a/xen/include/xen/fdt-kernel.h
+++ b/xen/include/xen/fdt-kernel.h
@@ -7,7 +7,7 @@
 #ifndef __XEN_FDT_KERNEL_H__
 #define __XEN_FDT_KERNEL_H__
 
-#include 
+#include 
 #include 
 #include 
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 20 18:41:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 18:41:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021174.1397223 (Exim 4.92)
	(envelope-from )
	id 1uSggE-00051i-MI; Fri, 20 Jun 2025 18:41:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021174.1397223; Fri, 20 Jun 2025 18: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 1uSggE-00051a-J7; Fri, 20 Jun 2025 18:41:38 +0000
Received: by outflank-mailman (input) for mailman id 1021174;
 Fri, 20 Jun 2025 18: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 1uSgVo-00057I-K3
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 18:30:52 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20621.outbound.protection.outlook.com
 [2a01:111:f403:2417::621])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b10e5d76-4e04-11f0-a30e-13f23c93f187;
 Fri, 20 Jun 2025 20:30:51 +0200 (CEST)
Received: from BL6PEPF00016417.NAMP222.PROD.OUTLOOK.COM
 (2603:10b6:22e:400:0:1004:0:5) by SA5PPF7F0CA3746.namprd12.prod.outlook.com
 (2603:10b6:80f:fc04::8d1) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.19; Fri, 20 Jun
 2025 18:30:48 +0000
Received: from BN1PEPF00006003.namprd05.prod.outlook.com
 (2a01:111:f403:c803::2) by BL6PEPF00016417.outlook.office365.com
 (2603:1036:903:4::a) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8857.25 via Frontend Transport; Fri,
 20 Jun 2025 18:30:48 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN1PEPF00006003.mail.protection.outlook.com (10.167.243.235) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8857.21 via Frontend Transport; Fri, 20 Jun 2025 18:30:47 +0000
Received: from xcbagarciav01.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; Fri, 20 Jun
 2025 13:30:42 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b10e5d76-4e04-11f0-a30e-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=yt7F4NUrK2PgTV2Ogp6d5jWn56vnSYITZGWqe+s4xbIGfj5+jKpQGNOJxRUKM1MPtDvtYskyPRWonaOWzMxm6HYCqyLWsNm4f4/9nQWTdgyEpW2C7lQK9/SCZy53/ubMf5Ntagxq2We60GxoRxnkPSEM7mlWmgHEa6+fzybC4/nLCnzWoMLBkY0AJJ20ywjP0B22sZUrSd+avvgknfGXpSLo9b2W4e5UO60JbR1kAuyXxEgfYVzGC0hTUuRofeemWqxbISbRam6zP3ME5HveN4A41HvKhgWWFOGXQWAAg/3hHzgIRq+t4NTPWIO67hASS+UZNa7P3YJdniV0Q9Gvsw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=zd2eubkDW8FKsjdHvMt4efYEdWC1FtbTeDT9SBTH9xo=;
 b=f2S/4OLuR6h5Le3rnxbw+eaXkzJg0CYjMpWOn2y1LXnzV9R7DPfl0aNFGMyqIp3KrfUMuYzZd9SKC5zmtqMs4uJBIJo8BVMfo2fH+2VDxTLTPnj1Y6c/HeTdQjE8qTBTuU91HbAFNkrPNzpVXI10sfzTLN7lc+46RlXG2HqSF1Allmtr16Xgki/L5of/ctLEzvKvUXkhUvH+ALNoZhMDjsc2vEHYyCP9IafQ67D8C0l/ruKcktdYuAXylBXnP2vjeHDl6DZRg+14UTFSfbPAMoRXsBhjARxz3vXgd9HDy7DiaYQjPvsaMzFLt1PR84zJYPcPM01t5gSGfsVAmsaI2A==
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=zd2eubkDW8FKsjdHvMt4efYEdWC1FtbTeDT9SBTH9xo=;
 b=HvwJiDg6PS+XYyVDiC8oSW8nNY4y/6MEc54gweh7JoqQDLAjvAutA/CuhDIKxGB178MT6POS1gkWB133eCsHvSoAq0XWyJ7DgALZzeXdLIol5e4ljlBFHBs36NU23DMU0a77kynNwHxP3sVg1M1nF7VqcJIps9DES0G2Aphtt6A=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Daniel P.
 Smith" 
Subject: [PATCH v4 09/12] xen/dt: Extract helper to map nodes to module kinds
Date: Fri, 20 Jun 2025 20:28:55 +0200
Message-ID: <20250620182859.23378-10-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250620182859.23378-1-agarciav@amd.com>
References: <20250620182859.23378-1-agarciav@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: BN1PEPF00006003:EE_|SA5PPF7F0CA3746:EE_
X-MS-Office365-Filtering-Correlation-Id: c98714fb-3854-458a-ceba-08ddb0289390
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?kAn1nGtAdoV1lEH9OrbMqZt2G8nHN4YmUg/E4+43ldQqmMiQ72nUzR+FKCO9?=
 =?us-ascii?Q?4p2ztTubI8CryB8Yyjt89YUfAXoKqZohbhlByAh5CuyR2B2MrVjIYALLOkfb?=
 =?us-ascii?Q?sEQbXHck4GCUOgZ6uaaZgfY85fVGG/lmZbWOHBM+FOJBE/bt/JXgKA0m1JsW?=
 =?us-ascii?Q?tmm5JniB4YGJWRYKXyq31D6eJr9KAvUvggoIR1y1MDtq0OHDVD1jHvh0Dt4m?=
 =?us-ascii?Q?Mw0DsGJNw0Xg8lzREo4hvOGb29Q5X9mlr8eKNVF9/BZY8MsKp2Raz/7Bg9+J?=
 =?us-ascii?Q?L4k6/Yu7SKDh0UTYbV6mFC3cMuQMSm81XUSMPgjeIaPPBkqUU+e/LWra8pf5?=
 =?us-ascii?Q?ddd7iGM3JeJ1EAQfLQEXVOvYquoJBjx3Pqxm3I0B6wZkB1MtYodTZ3obS3ga?=
 =?us-ascii?Q?gm9/yuYgK9kepOXABWz+/bbkr4whNgwAgzW31RehpRJojspP57ADj3Icb1SL?=
 =?us-ascii?Q?IWWKqJ5u6dhfQl7Eql8ID8PMYKC2k50O4vnFjlNW0mUdGpeaW1JcKx/wIE8G?=
 =?us-ascii?Q?4c/dwIM9ND4aaUgu7MjzhHgVRBEWw3W1PCHY1nEOcqy3QWFtdtThKC5PzkzL?=
 =?us-ascii?Q?C7Dt2ewqfe7T7/op6+GZ/5NUIXMnHRKMFC8eGfyOcPDIvtpjjeDNbW/w7BlM?=
 =?us-ascii?Q?exs4hayYSfanmGhaonyzwVSdvt1thFxeTFDo6uJSEXI7Gy0do2MbJubuUSCf?=
 =?us-ascii?Q?Jatq6dO62VUX0oO5goXzASMAmShACKvhnOuEgC7+yGAaRGE8ZJGGNhTWoZsI?=
 =?us-ascii?Q?lxP90B5lq7WgaW6Wl8cOIq3g3nIq7YcWN2RmtRVoUD4mD5Wx6etrEtkvv+th?=
 =?us-ascii?Q?bbyG5RHKW4BP4JQmKBjJEcIWphw4dSyjLsw4Ys++2Nk0s9it921GngVvNEIh?=
 =?us-ascii?Q?5YDVL4HMIvSmdFEnWIjgRpAQHDJPKuF6tYjhuQZx4jEXu6w0H2xBArSVyYny?=
 =?us-ascii?Q?beDKIvPoEYyLGsLeXGFYiu8x/mt0hx0klh49yXHIY/xqE+qTPXj8oLwMCdkm?=
 =?us-ascii?Q?qVzlu5OmQux7F+UQXsWiiR68KrP2WjaBu0KBegnMD2lkdlkT7lIEPAv6FIya?=
 =?us-ascii?Q?JL9MFq16odjU9eoY36xDuDpFwRhgd16coAIzvjAbMALtqEVdYixyYBpSP9af?=
 =?us-ascii?Q?HJW37+GNtNK5iLCPfvW08gjWTFiMJ+aSaOV9PvoxDOxY6RFDWwVwG3rQTXDw?=
 =?us-ascii?Q?unpHdlsbXuQD7X7j+jrMrIGrqTRK/X1wsnjZRVU/Ycd6Vh+wM1JuGXfTPW1p?=
 =?us-ascii?Q?uF6C21W/zCuynHqBZnt3RXN8zK+UZhfSU8qW60RPfll0FowCdlESXVLBFV5I?=
 =?us-ascii?Q?OLuyQKWBY2DrFaEvcn00HywbLZ0lD2rnA3CPCEVIzJ8mAaf4ueddfPG+iqE+?=
 =?us-ascii?Q?qvglx+hXMSoGIock53ORojAV2ftuaV4nYuGVZzQUUJN6QAIW2m+qCOfjtftc?=
 =?us-ascii?Q?sryycK/gf0Y1UNoRdRPu2qoU3j61LB34JpQQh8qoSbzKZRlp/1BHehjSLpPJ?=
 =?us-ascii?Q?l0jBgQCyIqpxjARsryK0XTuxSFvU/GpeIM0W?=
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: 20 Jun 2025 18:30:47.6984
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c98714fb-3854-458a-ceba-08ddb0289390
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:
	BN1PEPF00006003.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA5PPF7F0CA3746

This will be required later by x86 code in order to do early identification
of boot modules when booting off a DTB.

Not a functional change.

Signed-off-by: Alejandro Vallejo 
Reviewed-by: Stefano Stabellini 
---
 xen/common/device-tree/bootfdt.c      | 18 ++++++++++++++++++
 xen/common/device-tree/bootinfo-fdt.c | 16 +---------------
 xen/include/xen/bootfdt.h             |  7 +++++++
 3 files changed, 26 insertions(+), 15 deletions(-)

diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
index 0d8d9ea357..8218c0a10b 100644
--- a/xen/common/device-tree/bootfdt.c
+++ b/xen/common/device-tree/bootfdt.c
@@ -4,6 +4,24 @@
 #include 
 #include 
 
+boot_module_kind __init fdt_node_to_kind(const void *fdt, int node)
+{
+    if ( fdt_node_check_compatible(fdt, node, "xen,linux-zimage") == 0 ||
+         fdt_node_check_compatible(fdt, node, "multiboot,kernel") == 0 )
+        return BOOTMOD_KERNEL;
+    if ( fdt_node_check_compatible(fdt, node, "xen,linux-initrd") == 0 ||
+         fdt_node_check_compatible(fdt, node, "multiboot,ramdisk") == 0 )
+        return BOOTMOD_RAMDISK;
+    if ( fdt_node_check_compatible(fdt, node, "xen,xsm-policy") == 0 )
+        return BOOTMOD_XSM;
+    if ( fdt_node_check_compatible(fdt, node, "multiboot,device-tree") == 0 )
+        return BOOTMOD_GUEST_DTB;
+    if ( fdt_node_check_compatible(fdt, node, "multiboot,microcode") == 0 )
+        return BOOTMOD_MICROCODE;
+
+    return BOOTMOD_UNKNOWN;
+}
+
 u32 __init device_tree_get_u32(const void *fdt, int node,
                                const char *prop_name, u32 dflt)
 {
diff --git a/xen/common/device-tree/bootinfo-fdt.c b/xen/common/device-tree/bootinfo-fdt.c
index 16036472f3..9b426c0a98 100644
--- a/xen/common/device-tree/bootinfo-fdt.c
+++ b/xen/common/device-tree/bootinfo-fdt.c
@@ -236,21 +236,7 @@ static void __init process_multiboot_node(const void *fdt, int node,
 
     cell = (const __be32 *)prop->data;
     device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
-
-    if ( fdt_node_check_compatible(fdt, node, "xen,linux-zimage") == 0 ||
-         fdt_node_check_compatible(fdt, node, "multiboot,kernel") == 0 )
-        kind = BOOTMOD_KERNEL;
-    else if ( fdt_node_check_compatible(fdt, node, "xen,linux-initrd") == 0 ||
-              fdt_node_check_compatible(fdt, node, "multiboot,ramdisk") == 0 )
-        kind = BOOTMOD_RAMDISK;
-    else if ( fdt_node_check_compatible(fdt, node, "xen,xsm-policy") == 0 )
-        kind = BOOTMOD_XSM;
-    else if ( fdt_node_check_compatible(fdt, node, "multiboot,device-tree") == 0 )
-        kind = BOOTMOD_GUEST_DTB;
-    else if ( fdt_node_check_compatible(fdt, node, "multiboot,microcode") == 0 )
-        kind = BOOTMOD_MICROCODE;
-    else
-        kind = BOOTMOD_UNKNOWN;
+    kind = fdt_node_to_kind(fdt, node);
 
     /**
      * Guess the kind of these first two unknowns respectively:
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index ad6b11cb6d..bc5fc995b0 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -143,4 +143,11 @@ u32 device_tree_get_u32(const void *fdt, int node,
 void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
                          uint32_t size_cells, paddr_t *start, paddr_t *size);
 
+/*
+ * Probe an FDT node thought to be a boot module to identify its kind.
+ *
+ * If correctly identified, returns the detected kind, otherwise BOOTMOD_UNKNOWN
+ */
+boot_module_kind fdt_node_to_kind(const void *fdt, int node);
+
 #endif /* XEN_BOOTFDT_H */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 20 18:41:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 18:41:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021175.1397228 (Exim 4.92)
	(envelope-from )
	id 1uSggF-000557-12; Fri, 20 Jun 2025 18:41:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021175.1397228; Fri, 20 Jun 2025 18: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 1uSggE-00054L-RE; Fri, 20 Jun 2025 18:41:38 +0000
Received: by outflank-mailman (input) for mailman id 1021175;
 Fri, 20 Jun 2025 18: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 1uSgWB-00057I-Dx
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 18:31:15 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on20610.outbound.protection.outlook.com
 [2a01:111:f403:2407::610])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bef0dc77-4e04-11f0-a30e-13f23c93f187;
 Fri, 20 Jun 2025 20:31:14 +0200 (CEST)
Received: from BLAPR05CA0003.namprd05.prod.outlook.com (2603:10b6:208:36e::10)
 by PH7PR12MB5831.namprd12.prod.outlook.com (2603:10b6:510:1d6::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Fri, 20 Jun
 2025 18:31:11 +0000
Received: from BN1PEPF00005FFF.namprd05.prod.outlook.com
 (2603:10b6:208:36e:cafe::e1) by BLAPR05CA0003.outlook.office365.com
 (2603:10b6:208:36e::10) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8880.13 via Frontend Transport; Fri,
 20 Jun 2025 18:31:10 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN1PEPF00005FFF.mail.protection.outlook.com (10.167.243.231) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8857.21 via Frontend Transport; Fri, 20 Jun 2025 18:31:10 +0000
Received: from xcbagarciav01.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; Fri, 20 Jun
 2025 13:31:04 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bef0dc77-4e04-11f0-a30e-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=iOuYhSWJzkdOQCjpsYOTL/Z4TtVTCF/m6u4Qs+T8DlNUNxXfkEu+QSyn9TwVYZUw3BTsLFqS5pynogxh+sYfIYX9FQRyoRyoYLFPlsJBD6eUdjsLzJi7xDPL9OKIQbHkg4B/+Httlyj7YVmZes4w5/vRYV+d1B9ts+hfcqvPi0EL6nqWo41X5HWgfb67kqkgWfrV6B6cwhlAXNSTmLEiPfha57XRarGROvdPXToEYPydHS0FdUshSf3HOa0lEA+rbfhdCbXUqTGOU6uG80ge5bFeZlHomqIxEQ2c3oQfNvw+meZuqNBDnQ/xpJ4Bhc1P4th0/tS1mqmJxhldpzhtsg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=WdFpjspBLXF09Dh8dXIg7wVUrR+4cy9u7XozgkJTdVo=;
 b=N8XLJsehOvwA0GFGe5oZn76SwEzxfsTBr98X+OAVVa5LUhNmeCRWYWxMI+VhjI8PHscUzoiicrkgajOHuXqKC7L2SPbT0CTaUOExj3etAtDLMY6Dx/AMfvgRsztDzKs9Ucr9i33kM9TgcEv9eHuIIVF45UtkNjNtCrrV//RWKa+1M6vUHfAG/AzInTDAcGcqmIksc8yytuWNwR9tTQuLiuMWfNxp/3lV7jab3jlJLajMIa32Nlkyybu5iiYlkVQ/eMnecD05TncFRv1rEeOZ10iu4m4TPFdj9cEdtUBvPLKHcwVPUOxv/frSJZViwUlplbay48HiPiKQ5zBTr2Lo8A==
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=WdFpjspBLXF09Dh8dXIg7wVUrR+4cy9u7XozgkJTdVo=;
 b=dB/ORJh1r3S35LnQ3ffHLEGTCkaqAMXWfqW4eWfEx8ik/LauvYGkEBacAnW1S3m5aKtsc29/dYFifw4jFAg7AhvpKTbAXiZTmoIMCNQeQYdCkhyYeliezGVj58Qt3NQeHPr4h54JQanp1eIM/grMSciQQWP9/gIXvpb4hidDfRg=
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: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , 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 12/12] xen/dt: Remove DOM0LESS_BOOT's requirement on HAS_DEVICE_TREE_DISCOVERY
Date: Fri, 20 Jun 2025 20:28:58 +0200
Message-ID: <20250620182859.23378-13-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250620182859.23378-1-agarciav@amd.com>
References: <20250620182859.23378-1-agarciav@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: BN1PEPF00005FFF:EE_|PH7PR12MB5831:EE_
X-MS-Office365-Filtering-Correlation-Id: fe7486d6-ee33-4b5c-1034-08ddb028a155
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?ky2oK1WFKZBB83Xj4T617U2yS2c+uZYcT0dXbxo+YohCBeLdsopT9S55F28q?=
 =?us-ascii?Q?RMLMWOhltWgUuXLrUra3uf6OC0JVjCWhF22x7FuHLfVsrxkv87BGnphikGKY?=
 =?us-ascii?Q?W7E+PF1bSxTSjLnDh1fGeAQBB74eXO5By005wv2tERYJxilb2/5qOm9XJsLL?=
 =?us-ascii?Q?bUZXFSuczP0yxl6/BYOzHEdT5MreFHqOVdfKQ//9uicS6GgrUlZeZaHpeuDk?=
 =?us-ascii?Q?I8C2f6mfa/+x3fQ6bB4ppyxD2caGZ5yHFZQ7nT2fnLSm+NBFvgrwYBWx0b2D?=
 =?us-ascii?Q?dVmMVrTEFh5RudEpxf2qHw68y9CocStr+xq+yeLTVP4lJ62hRRUPEr2PBr+T?=
 =?us-ascii?Q?RVlVWg4jWC9PJD5kjXj5KmWQqGkFd+fMtd+i/AtqQnYtAoecrSRD2TQ6STRE?=
 =?us-ascii?Q?h5xzS2pV9pt3u7FyhoFet1xKeFSWa3zvhGdw7qhS+wHJwF6ahk2o/N6ksUZc?=
 =?us-ascii?Q?1SIKCVJkBZIaGt/Tns06vH60wo68fd8V0wnwCcm9hTDdwhPVnx+VDXV52gm9?=
 =?us-ascii?Q?Njq0RKK460oC75pSIN/xBm7SmeRUbyUAS1Cid474vyYKFn7xqGVxXvFHp3Lt?=
 =?us-ascii?Q?YM/lL18dDpoz8Gw1YrF0jx9rGXU62EldfRj3uLoQLfi7sNd9PFWYZK8EpKu9?=
 =?us-ascii?Q?7vV6zsZ8mjcSlq7Hz07OLgnYo32Ww/Ww1N/qnX3XkbHQHhSEPtTH2m+6sz5z?=
 =?us-ascii?Q?LHsDjf/LV7DhuFcYtgwNjHvDMy4l+nKkwU6T5L3koVljKOhpNNaPCKl94ecJ?=
 =?us-ascii?Q?59Hr39M+UXJl/omsk8szdV9iBAhLoyND0XSx7JnqavR5OcHh4PPO7Pr/sYpj?=
 =?us-ascii?Q?rHjCLRBrzF3elDNjrplzDo9fcSMN0E053CnjTdcukqOSYOOrjXflQ3otDgWi?=
 =?us-ascii?Q?jrwr2/0GnAAPqLeLI87qduexLGeWqkdQmtzj033yq/Frva+eYvjb8TCkTSrM?=
 =?us-ascii?Q?rzhpGn8yQpoZLp9AGXA2rab+9SxUsRZMIk41WQ5B2JdFYEcRw5lQwl6SzJr2?=
 =?us-ascii?Q?80XUNFuu+c9w2lFWc756gXohTI+0Ahs5b/5CRxUJxfDXYHuBqwVTLPgG+L5V?=
 =?us-ascii?Q?6uJLB03mgFcm5J0csdKir6TWJ8sNlQi+dVaGgd8+mohvPfLjnLY70whf43Td?=
 =?us-ascii?Q?EZNyzlNCszMx/s6QuUgNZI8RrazH/4AFSJt1Dbmsw9rF20o+VHJTX42NMFbQ?=
 =?us-ascii?Q?JXE1IABBTJ+0vruRJ8+lyvTcYLwaRmLU4x2V9rhYobf1jbECEJ8zTlDhjBYA?=
 =?us-ascii?Q?ma7ds4zEvlqu/dP34IctN7qGWkwshmcSFWIGROCdEaqF1roHw9U4MHwvlffP?=
 =?us-ascii?Q?XSvmZhwVZ5RdHa7+7/97wUlfPGs05BaNOnW24SVBJaUhPSm+MosjEOJkSOY+?=
 =?us-ascii?Q?NMkJncfpzT6O9OWpZjyFGK27raNVIc0xNAPjlKnuxKBWjsqmAbL1n4r3F7qm?=
 =?us-ascii?Q?ezzU1lxUrA6PktVBo5Qu4q8NWImz1iL0QRc5R14M90Uu2aaQ3+ckgrnZZr8F?=
 =?us-ascii?Q?eWTayfeaNlg+fL/2HuJ5Oo8ZEgIDh5MLEu0g?=
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: 20 Jun 2025 18:31:10.7951
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: fe7486d6-ee33-4b5c-1034-08ddb028a155
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:
	BN1PEPF00005FFF.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB5831

This effectively means that DOM0LESS_BOOT on platforms without
HAS_DEVICE_TREE_DISCOVERY (i.e: x86) acts as a selector for a
stripped-down version of DT code.

Signed-off-by: Alejandro Vallejo 
---
 xen/Kconfig.debug               | 2 +-
 xen/common/Kconfig              | 3 ++-
 xen/common/Makefile             | 1 +
 xen/common/device-tree/Makefile | 8 ++++----
 4 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index 9192d593a7..89b0af53a2 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -92,7 +92,7 @@ config VERBOSE_DEBUG
 
 config DEVICE_TREE_DEBUG
 	bool "Device tree debug messages"
-	depends on HAS_DEVICE_TREE_DISCOVERY
+	depends on DOM0LESS_BOOT || HAS_DEVICE_TREE_DISCOVERY
 	help
 	  Device tree parsing and DOM0 device tree building messages are
 	  logged in the Xen ring buffer.
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 6294cd7939..1ac28a4e78 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -14,7 +14,8 @@ config CORE_PARKING
 
 config DOM0LESS_BOOT
 	bool "Dom0less boot support" if EXPERT
-	depends on HAS_DOM0LESS && HAS_DEVICE_TREE_DISCOVERY && DOMAIN_BUILD_HELPERS
+	select LIBFDT
+	depends on HAS_DOM0LESS && DOMAIN_BUILD_HELPERS
 	default y
 	help
 	  Dom0less boot support enables Xen to create and start domU guests during
diff --git a/xen/common/Makefile b/xen/common/Makefile
index d541fbcf49..19d6ff7a90 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_DEBUG_TRACE) += debugtrace.o
 obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += device.o
 obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) += device.o
 obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += device-tree/
+obj-$(CONFIG_DOM0LESS_BOOT) += device-tree/
 obj-$(CONFIG_IOREQ_SERVER) += dm.o
 obj-y += domain.o
 obj-y += event_2l.o
diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
index 8abc069c4b..4a10b0508f 100644
--- a/xen/common/device-tree/Makefile
+++ b/xen/common/device-tree/Makefile
@@ -1,11 +1,11 @@
 obj-y += bootfdt.init.o
-obj-y += bootinfo-fdt.init.o
-obj-y += bootinfo.init.o
-obj-y += device-tree.o
+obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += bootinfo-fdt.init.o
+obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += bootinfo.init.o
+obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += device-tree.o
 obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.init.o
 obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.init.o
 obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o
-obj-y += intc.o
+obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += intc.o
 obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o
 obj-$(CONFIG_STATIC_EVTCHN) += static-evtchn.init.o
 obj-$(CONFIG_STATIC_MEMORY) += static-memory.init.o
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Jun 20 20:22:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 20:22:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021227.1397244 (Exim 4.92)
	(envelope-from )
	id 1uSiFd-0002MB-3L; Fri, 20 Jun 2025 20:22:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021227.1397244; Fri, 20 Jun 2025 20:22:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSiFc-0002M4-V9; Fri, 20 Jun 2025 20:22:16 +0000
Received: by outflank-mailman (input) for mailman id 1021227;
 Fri, 20 Jun 2025 20:22: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 1uSiFb-0002Ly-Jr
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 20:22:15 +0000
Received: from fout-b1-smtp.messagingengine.com
 (fout-b1-smtp.messagingengine.com [202.12.124.144])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3fd161e1-4e14-11f0-a30e-13f23c93f187;
 Fri, 20 Jun 2025 22:22:13 +0200 (CEST)
Received: from phl-compute-03.internal (phl-compute-03.phl.internal
 [10.202.2.43])
 by mailfout.stl.internal (Postfix) with ESMTP id C5B65114016B;
 Fri, 20 Jun 2025 16:22:11 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-03.internal (MEProxy); Fri, 20 Jun 2025 16:22:11 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
 20 Jun 2025 16:22:10 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3fd161e1-4e14-11f0-a30e-13f23c93f187
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=1750450931;
	 x=1750537331; bh=O+zynp0pdZUX2uRkaZCP/6YKtinfqYmyWggqGO1iuis=; b=
	DHfYHHKeMfe/J4u1Tnn6FP2PSe4ytCD86gBQb7iWY1nWG3Zr/gs6K++GMQDsTVUQ
	WnX+Kq39oO5mKA7Gbcl/hrxpCOFJG8AKWl9SrV+7WsIqK4SkLpxRJUWofHK2yKHw
	o1TC2nWDPgWgEbqunnCnWlYZL4dWP28sf8HFvdzPbD7hRxg2B4Stf2iJI+cBkMvx
	EyIK48CkE3iCIMPlqAMbxNE5CFJcq+E4qEoNOH7qmaVNxNb79N3EX1lrzDCQBY0Q
	YZTHvtbzL6h2tACpfdbdB5pwzDvyvo8KLqN/P6TE/afHKAZzXe5cNfhyhj+4oKGF
	v3HBcJw3e99woVlbd4e7Og==
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=
	1750450931; x=1750537331; bh=O+zynp0pdZUX2uRkaZCP/6YKtinfqYmyWgg
	qGO1iuis=; b=UcrnEppZefpoZxROW/1N+pkCItAE9tZS/dw8rnheMLS9NygD/Zn
	xljlMXrOdqb0VouYpxtoPrwlT3Ub3NPdXqAkhu7Ofp60B1Yh0um+pCl6b64jHdyJ
	m46PWM0zoLg6XgVENGw8aqpEXTDKuO/0J994nED0jR2kJeT5yS+Uj69mY1OQpJb5
	9Qo6IwvqrY5zECSR8XQK1ZKZqNSTytpkDEySMe39ggQbv6004LUv5rrmy35S90jP
	rBJK0bvLnLtC1oyaFx2Dd5//Q6/4qf1Bn92LrArIOkTqJF2Kc2Y48Bqft+SAWN4G
	JSC5/w1ucW84iBSzLpWVIbDp3j+oWb56aJg==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgdelfeegucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceurghi
    lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh
    epfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcuofgr
    rhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvihhsih
    gslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfduleetfeev
    hfefheeiteeliefhjefhleduveetteekveettddvgeeuteefjedunecuvehluhhsthgvrh
    fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhv
    ihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepgedpmhhoug
    gvpehsmhhtphhouhhtpdhrtghpthhtohepfhhrvgguihgrnhhordiiihhglhhiohestghl
    ohhuugdrtghomhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnph
    hrohhjvggtthdrohhrghdprhgtphhtthhopeguphhsmhhithhhsegrphgvrhhtuhhsshho
    lhhuthhiohhnshdrtghomhdprhgtphhtthhopehjsggvuhhlihgthhesshhushgvrdgtoh
    hm
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Fri, 20 Jun 2025 22:22:08 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Frediano Ziglio 
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" ,
	Jan Beulich 
Subject: Re: [PATCH v2] xen/efi: Do not check kernel signature if it was
 embedded
Message-ID: 
References: <20250620082607.46568-1-frediano.ziglio@cloud.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="bUNgetm3bXjgP54g"
Content-Disposition: inline
In-Reply-To: <20250620082607.46568-1-frediano.ziglio@cloud.com>


--bUNgetm3bXjgP54g
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Fri, 20 Jun 2025 22:22:08 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Frediano Ziglio 
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" ,
	Jan Beulich 
Subject: Re: [PATCH v2] xen/efi: Do not check kernel signature if it was
 embedded

On Fri, Jun 20, 2025 at 09:26:05AM +0100, Frediano Ziglio wrote:
> Using UKI it's possible to embed Linux kernel into xen.efi file.
> In this case the signature for Secure Boot is applied to the
> whole xen.efi, including the kernel.
> So checking for specific signature for the kernel is not
> needed.
>=20
> Signed-off-by: Frediano Ziglio 

Reviewed-by: Marek Marczykowski-G=C3=B3recki 

> ---
> Changes since v1:
> - updated commit message and code comment;
> - renamed kernel_was_verified to kernel_verified.
> ---
>  xen/common/efi/boot.c | 7 +++++++
>  1 file changed, 7 insertions(+)
>=20
> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> index e39fbc3529..fb3b120982 100644
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -1291,6 +1291,7 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE Im=
ageHandle,
>      bool base_video =3D false;
>      const char *option_str;
>      bool use_cfg_file;
> +    bool kernel_verified =3D false;
>      int dt_modules_found;
> =20
>      __set_bit(EFI_BOOT, &efi_flags);
> @@ -1461,6 +1462,11 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE I=
mageHandle,
>              read_file(dir_handle, s2w(&name), &kernel, option_str);
>              efi_bs->FreePool(name.w);
>          }
> +        else
> +        {
> +            /* Kernel was embedded so Xen signature includes it. */
> +            kernel_verified =3D true;
> +        }
> =20
>          if ( !read_section(loaded_image, L"ramdisk", &ramdisk, NULL) )
>          {
> @@ -1534,6 +1540,7 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE Im=
ageHandle,
>       * verify it.
>       */
>      if ( kernel.ptr &&
> +         !kernel_verified &&
>           !EFI_ERROR(efi_bs->LocateProtocol(&shim_lock_guid, NULL,
>                                             (void **)&shim_lock)) &&
>           (status =3D shim_lock->Verify(kernel.ptr, kernel.size)) !=3D EF=
I_SUCCESS )
> --=20
> 2.43.0
>=20

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

--bUNgetm3bXjgP54g
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmhVwvAACgkQ24/THMrX
1yz7Zgf/Va3Xk12l+3h+nMERVgB4qCa+oTuIHSqOZUYz3oBrQf7ObEtM54Y1JnQL
EutXpWZb5VXrL5x1/BOuavnIE10gqMbH2YXcYUabXRVR5kfwP0Y3Cx75jGZ8D5GL
9EVHT+CV78QZsE0+gFQnZFo/Gq4+Kot8uBhQIH2FFR3RHwm0FfYS81ix9jyNhiYX
flXljPLOyErAKDOhp4uw0/LzCDkj4pc9jgyHtP8MA9ewb9467owy17V+PDqgjg4C
/XAMYdUBfl/Y/0oEBHnQFFvcCghTeLNb68fUhUCKTn7uxArsmDO/xCwV362xOonN
PvA9YX3PgdjbyOsbCu9H7yjs1Ekkbw==
=YZF8
-----END PGP SIGNATURE-----

--bUNgetm3bXjgP54g--


From xen-devel-bounces@lists.xenproject.org Fri Jun 20 20:34:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 20:34:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021240.1397253 (Exim 4.92)
	(envelope-from )
	id 1uSiRL-00040O-4D; Fri, 20 Jun 2025 20:34:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021240.1397253; Fri, 20 Jun 2025 20:34:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSiRK-00040H-WA; Fri, 20 Jun 2025 20:34:22 +0000
Received: by outflank-mailman (input) for mailman id 1021240;
 Fri, 20 Jun 2025 20:34: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 1uSiRJ-00040B-V3
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 20:34:21 +0000
Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com
 [2a00:1450:4864:20::442])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f1f05186-4e15-11f0-a30e-13f23c93f187;
 Fri, 20 Jun 2025 22:34:21 +0200 (CEST)
Received: by mail-wr1-x442.google.com with SMTP id
 ffacd0b85a97d-3a375e72473so1073704f8f.0
 for ; Fri, 20 Jun 2025 13:34:21 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4535eac8e19sm68534725e9.21.2025.06.20.13.34.19
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 20 Jun 2025 13:34:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f1f05186-4e15-11f0-a30e-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750451660; x=1751056460; 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=O8OwyQKlXUOhtdxWYAXgewhFCfX/X/eqeQc/qXnB0Xo=;
        b=cBkKHAumkfxmNTCoPnY6vcibP3jPBR1NtZl+JYFchDWbpvsg0CdJeA1JByIjXbJIf9
         cgHEyVNnKihHIDxUVu6y4kr6jsS02rdvd+ob9bjuAwWPvp1vnE4YYfDeMOFoMp7z1uVu
         zU/7RXGqBV9WIypIglqCngaSbyEeRVBctmSQk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750451660; x=1751056460;
        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=O8OwyQKlXUOhtdxWYAXgewhFCfX/X/eqeQc/qXnB0Xo=;
        b=RPJwXZRAZbv+qOljUS7my+0PRx/oee4D/2YijSVBbBj7OhrMInutgrZcoIlC5FqMxb
         c5DSeTi+3+y1rcWY5m7sqEvpmMnjDp2TjOZEl4BCoQ8aVx2Fn/HUzzYe6fwVN2cuU70j
         SZtVVpZGO1+Xn6pGr9iE2AX3uVN1tA3aPf/hT9LqfVA9JJMqU4kIpYEXbmHRSGxuEKwM
         pUwiMNHasbInUq/M1R6cg174zOBhfxGAh38aIyDb4cNgASe3YTMI9dZlzWVen/NN2r8d
         kJZrUrbvqe9IQXIOZ6PmJ95f5AGcYO0XhZE7TgbjVbAwcc8RYsmNcY/N4JehuyRurwah
         YJGw==
X-Gm-Message-State: AOJu0YwD/hZj5/2cTkomnN7c5ykwCGdgBWIDG4yaAzjviBU8LSBjG+Vr
	C0SxL2qI4xhXnZShsKWPigx0Ym+56DUo+/cFj1Ifar684uPtcp7w5dKvsF8BC6Tk5qBJ2pJIwvS
	MHfGamwewDQ==
X-Gm-Gg: ASbGnctrkkGS1R7JQsetDV/oh/+PLgwC5LjiYdgEQV7U7g4iiq0YsJ+sPQF5xmCtjno
	YFNgscG/JKbEtMTdYqd5tfqGQlZUbpoddw/JY5jQtNOKv4pmgko3Uj94WyM/xXazLq4d4lju64B
	0Vjs9zSOBQsIra2tnFxrByge2AD0jGuOeoRGB6Cz8sZ5hOllaXPBNBvwTzhZfGAAqXjq4sOFmI9
	ZFThIK/z76MPBgCgogudyXMUikXfkrxIR2l+urtZG1wRKLgovhrDdqqmtVR/Vk1FV4o6EST96od
	ijLl/Jy1dlUauYHitt/ZB50gdolSPdKYaHLVDDUOr3eR2iJNQv8TWU4Yzba2nu+lptjYsCVW4rK
	H58AISkMr5hUhthxoU+xxcdKR3fid3eIdiNU=
X-Google-Smtp-Source: AGHT+IHmtFEy00wmjm4f0JoWOXd805D5FeimdEflY1MZdxYnsOKesAC4ZA9CSuejLCf7Ycra814D5w==
X-Received: by 2002:a05:6000:1a85:b0:3a4:dc80:b932 with SMTP id ffacd0b85a97d-3a6d1193dfbmr3216021f8f.8.1750451660185;
        Fri, 20 Jun 2025 13:34:20 -0700 (PDT)
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 
Subject: [PATCH] docs: Introduce a default .readthedocs.yaml
Date: Fri, 20 Jun 2025 21:34:18 +0100
Message-Id: <20250620203418.42526-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

Read The Docs now requires a configuration file, which is awkward when using
RTD to render proposed changes on the list.

Provide the minimal configuration file possible, sacrificing all
reproducibility in order to hopefully not need to touch it moving forwards.

Signed-off-by: Andrew Cooper 
---
CC: Anthony PERARD 
CC: Michal Orzel 
CC: Jan Beulich 
CC: Julien Grall 
CC: Roger Pau Monné 
CC: Stefano Stabellini 

Notably, I've figured out how to get back to using rtd-theme:

  https://andrewcoop-xen.readthedocs.io/en/docs-secureboot/admin-guide/uefi-secure-boot.html

and without needing a separate docs/requirements.txt file in the tree too.
---
 .readthedocs.yaml | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 .readthedocs.yaml

diff --git a/.readthedocs.yaml b/.readthedocs.yaml
new file mode 100644
index 000000000000..d3aff7662ebf
--- /dev/null
+++ b/.readthedocs.yaml
@@ -0,0 +1,18 @@
+# Read the Docs configuration file for Sphinx projects
+# See https://docs.readthedocs.io/en/stable/config-file/v2.html for details
+
+version: 2
+
+build:
+  os: ubuntu-lts-latest
+
+  tools:
+    python: "latest"
+
+  jobs:
+    post_install:
+      # Instead of needing a separate requirements.txt
+      - python -m pip install --upgrade --no-cache-dir sphinx-rtd-theme
+
+sphinx:
+  configuration: docs/conf.py
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Fri Jun 20 21:36:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 21:36:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021264.1397263 (Exim 4.92)
	(envelope-from )
	id 1uSjPf-000305-FZ; Fri, 20 Jun 2025 21:36:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021264.1397263; Fri, 20 Jun 2025 21:36: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 1uSjPf-0002zy-CH; Fri, 20 Jun 2025 21:36:43 +0000
Received: by outflank-mailman (input) for mailman id 1021264;
 Fri, 20 Jun 2025 21:36: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 1uSjPd-0002zn-CC
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 21:36:41 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20616.outbound.protection.outlook.com
 [2a01:111:f403:2415::616])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a3944b38-4e1e-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 23:36:37 +0200 (CEST)
Received: from CH3P220CA0013.NAMP220.PROD.OUTLOOK.COM (2603:10b6:610:1e8::12)
 by DM6PR12MB4155.namprd12.prod.outlook.com (2603:10b6:5:221::15) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.30; Fri, 20 Jun
 2025 21:36:29 +0000
Received: from CH3PEPF0000000F.namprd04.prod.outlook.com
 (2603:10b6:610:1e8:cafe::18) by CH3P220CA0013.outlook.office365.com
 (2603:10b6:610:1e8::12) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8857.26 via Frontend Transport; Fri,
 20 Jun 2025 21:36:29 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CH3PEPF0000000F.mail.protection.outlook.com (10.167.244.40) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8857.21 via Frontend Transport; Fri, 20 Jun 2025 21:36:29 +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; Fri, 20 Jun
 2025 16:36:29 -0500
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; Fri, 20 Jun
 2025 16:36:28 -0500
Received: from [172.17.97.97] (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 Jun 2025 16:36:28 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a3944b38-4e1e-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=kJXY3t4QEv96ozd69IHWVzWGSHNaHl033706gQVPDWekXEdq5rjXo4nCJHthyPgPw3gcIfBZTBvOzS6KfZFISItqZrrvu/3/sNLA7MbVwI0GQ6VIcBEW9KYp1iSbZ7ERlvkCee2pOySzB/71oIkltUCCDm4DJbY3mpiuT6p4STweSxrM0QBSAinSo3WPuHQUWRj5C+6v3B2JjhoJxyhO6E4FG+y9DYj5iC5nE3mf+9ropgn7xY3xLfWmTSntwEipqna9PvugDLjqPUPqrzOF8VGN3WF5gwcmSM3ZO21ul8u27owyVI4fvom57XuluktOQhyj4TIFjFJZzzHEQLuLdg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=8CPsrEbMQLXOUUqeM2LQ9iP8HdATRM5wn0XASA4Dh1g=;
 b=CwLo2/Kexq8KZjIwOmTSKCcR842t7KrVSBVlNi4dwsnwQwtB8OdRF6mocswMW5lKjIPii2cKodqGu07zGhFpydgM+Q2J7CnQTUb0jDwQftBong20p3NM8UnRzVUJM/rb6mG3cS7pooX0yEYieax8kkee6fGKoCjJRkG1Oh10hkqOPs+LPPXN1ac7GEVCvI4XqaXUcRGoe8Jzqyhl3DvVMkJO+M7FulaKhvu/gJvFS4nmffKYpc7PWFGxZL8d6sQS6k3ZAcYnZfn+mYj6ApnxXV6Lqk5B+tghWM7nP5aD1hEwMus6GK/tS7hzGNq6upjSeywdf8OjSZYhnzjFnTDKlA==
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=8CPsrEbMQLXOUUqeM2LQ9iP8HdATRM5wn0XASA4Dh1g=;
 b=YGTAKSeoLrlA7YMgG6bOGSM3CNCbmrWa1vp4edpOY57uJRRP9Zom19ybU/f8riycqKBL2upVehLewXN4gg9zSTWGeGYLG8OgvHL9vEXFtO68Y90khgRxVtVW8/2DrYKIUanZZZ44V4upPmS/4dtQcJXgEkzk4u/TFBjsq4yImWw=
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: <5f1b32cf-73b1-4077-8bc6-f97b8ecd8082@amd.com>
Date: Fri, 20 Jun 2025 17:36:36 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [MINI-OS PATCH 1/6] suspend: drop crazy pfn handling for PVH
To: Juergen Gross , ,
	
CC: 
References: <20250619113804.32694-1-jgross@suse.com>
 <20250619113804.32694-2-jgross@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <20250619113804.32694-2-jgross@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: CH3PEPF0000000F:EE_|DM6PR12MB4155:EE_
X-MS-Office365-Filtering-Correlation-Id: c931f501-c159-4e5f-7f7d-08ddb0428491
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?TWNRNzFpU3FmOEMyNUxubFNhaGpHT21YWmZiY0c3eThqcndwU3R1OVRLWTFa?=
 =?utf-8?B?V3RlZlFFTkt1NXBoRnRzQlpUdis3L3pNT1czMVpIVzc4blJMVjFNeHFvY2Vp?=
 =?utf-8?B?MEh4MitwSTN6eTRqYXpVYzYxTnlGSStORDZiNjhPeHhZTXNKNit3blpMM3BI?=
 =?utf-8?B?Ujk2SDhZVnExeG96cllVVXRCZnNSZUVueTVnWVpha1lpbndJYngwMzIxZkRv?=
 =?utf-8?B?T2dSM2k5S2FiUEFXdU1SL1BBRjVoWFlLbmk4QUhWZzZodkxpTDBXZ0U4Nklv?=
 =?utf-8?B?aHRHWmJoWXdrNjgzR0xLaWdETXdOcmF5bW4yZVE5SzZUMURRZzYxTDVNWWto?=
 =?utf-8?B?cEdZWThNMkQ4Wi8zUU5IL1RkTlZDUWxxSDZCS1MxR010eDlMSUFFa245MzRw?=
 =?utf-8?B?SVF0eGQwTkpNUDZnQ0xnd2tXMFMvblRHQlNQbzUvd2xXWlFGUHdyTkg2SmlW?=
 =?utf-8?B?WVBQT0N5MDhxdFRNQURIVDd3Mm44R2Q5c0FUdXZaVUtyMklTNXV0aHcwUjZl?=
 =?utf-8?B?T2lsbXl4MHJWZVZnUHh5N2ZCbFRnaVhjcm1WNk5VdzQrRXFFZEtWSGpqLzI4?=
 =?utf-8?B?UlEzRjBmZlYzRHF1R1RpMTQrUHQ4emNpMEEvRmtTc0VZejNoUy93cU80V2I4?=
 =?utf-8?B?WE5Xcm5oUEtYS0J4UzFocEFWRFQ2Zy9IMU5PaE5lTVNuVnhjeFltc0trT0FV?=
 =?utf-8?B?cE5IUWFrY256QUJuaWVjTUpYV1E2UUNIVmZPYkpLVWhLWFRtdlJzZWhkWFVO?=
 =?utf-8?B?WTNQWTR3eG5aQmNFYXBGYWZvUUVRcHpvWUZ3UmdmdWtRRktvTXFLRnNHbHpR?=
 =?utf-8?B?cjJoWk5NanRDOGpIRGlXenNtaXR6akxEWEhUSHlFWHJScms5YUxab1k2VW9F?=
 =?utf-8?B?dGMvUlEzL2Rha2hMQlpsNlVwR0pxd3RLY3hkRXg5SllmS3V4WHNOaU1LWDly?=
 =?utf-8?B?ZzFiYy9nUVBFMzhoTDlOYitvWEhDRE16K0R6VnBUMEFjcXRQWEN1VE16K2hW?=
 =?utf-8?B?WjZ3RWNabXVOU0dlMThOSG83REJRZGJrTlFiQzVIc0N0ZGdsZU96NkhsMm9q?=
 =?utf-8?B?c3g2Z05aYUJjV1R1V3EwalQvQ0Yza1RFaUhnSHhWVFZBeWZRN2swU0NmbmdD?=
 =?utf-8?B?Y01DQWN6WWlVWlBKaUgwOWZmNXdKZGMxUEIzblhyVzdZcE1xVjNBZkJQeGhI?=
 =?utf-8?B?aXk1eEVMK0JuQkx0YVMxZ1VUdmo4OGtiZUd5MXJvRHNNNUVhOUppcTgzMzU4?=
 =?utf-8?B?Vlh0MTR4U2IvT29oYTJ0S2p5OGVpV1NyQml5SGVwS1c3QVFzTTIrbGJGNE5P?=
 =?utf-8?B?K1kzN3pvT3A5Q1NxMEE1d050VTEwNm9mZ1VGTGhtcmFJcEN6WS81MWtTa3ls?=
 =?utf-8?B?dHRHYk1DYWtsZG1RYkh5YnROeEdrOFI3b3VnNU45VVZmZDRjWENyeUhVSWFI?=
 =?utf-8?B?aGdlWFRnNUtHU01rdHFKUGhORjkxRk1rV3pQQTFhT04zRUE5RE1xbTVWVjlw?=
 =?utf-8?B?TU9SeTB2UndscEdsN0pDUmZxNEIxYVZmcUw1VzFLUUYzbXpWMTg0SW13WmxL?=
 =?utf-8?B?RWpPWUlpRVVkL3lKL3VrMi94aVVLbzhYMnRZb1FYdzdGbldlRHZ2cmdlZHZN?=
 =?utf-8?B?YVZDZ05KTDJvZmlCK0phOEZLNFc1WjB5VU5OVTNBOFBtY3owbmh6WjBmTlN1?=
 =?utf-8?B?MnhLaDY5TVlNT05IVDZVZC9TUURIR0F4YUdGalJvTlphSWtPOXorcExzVzVD?=
 =?utf-8?B?cm9vTXUxc0xVTkR4YXVqaTN2bWhCTDNBS3MyeXA0RFE3d1E1d0JlUXdXNzNL?=
 =?utf-8?B?SzhjeFl1Sm1qM1J4TU1tQmY2SHJYNldMNHhHUS95MndFeGc3TkFoODVjQlEy?=
 =?utf-8?B?LytkaHFGNHdsT1U1bzBkMWcrdmhyY09KSUltL1lKN1NOMTlHSDFEWHFpY1hC?=
 =?utf-8?B?RSt6OSs1dTV0REtOTTQ0TkJFclFMTmhZVTM3ak91TVB2MUdlTVFHS2NwdUFK?=
 =?utf-8?B?QkpGdHFvMlNPNkl0WXczeDBpYkZxV2dESzNaeU5UQmVxRjc5Y1p2RUF5MVg0?=
 =?utf-8?Q?ta4lCg?=
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: 20 Jun 2025 21:36:29.4390
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c931f501-c159-4e5f-7f7d-08ddb0428491
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:
	CH3PEPF0000000F.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4155

On 2025-06-19 07:37, Juergen Gross wrote:
> Suspend for PVH is doing some crazy stuff with the Xenstore and console
> PFNs:
> 
> - In arch_pre_suspend() the PFNs are "translated" to MFNs, even if that
>     translation is a nop.
> - The result is stored via start_info_ptr, which points to a struct
>    start_info only in case of PV mode.
> - After resuming or a cancelled suspend, the PFNs are retrieved again
>    and "translated".
> - The "MFNs" are stored again via start_info_ptr, which is still not
>    pointing at a struct start_info, and from where the data is never
>    read again after that.
> 
> Drop all of that completely.
>
> Signed-off-by: Juergen Gross 

start_info_ptr points at an hvm_start_info.  Assuming I counted 
properly, accessing ->console/store is writing past the end of the struct.

Reviewed-by: Jason Andryuk 


From xen-devel-bounces@lists.xenproject.org Fri Jun 20 21:38:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 21:38:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021281.1397281 (Exim 4.92)
	(envelope-from )
	id 1uSjRZ-0003f5-2y; Fri, 20 Jun 2025 21:38:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021281.1397281; Fri, 20 Jun 2025 21:38:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSjRY-0003ey-VW; Fri, 20 Jun 2025 21:38:40 +0000
Received: by outflank-mailman (input) for mailman id 1021281;
 Fri, 20 Jun 2025 21:38: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 1uSjRX-0003cm-MT
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 21:38:39 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20623.outbound.protection.outlook.com
 [2a01:111:f403:200a::623])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ebc11b05-4e1e-11f0-a30e-13f23c93f187;
 Fri, 20 Jun 2025 23:38:37 +0200 (CEST)
Received: from SJ0PR05CA0086.namprd05.prod.outlook.com (2603:10b6:a03:332::31)
 by CY1PR12MB9626.namprd12.prod.outlook.com (2603:10b6:930:106::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.21; Fri, 20 Jun
 2025 21:38:29 +0000
Received: from SJ5PEPF000001CD.namprd05.prod.outlook.com
 (2603:10b6:a03:332:cafe::12) by SJ0PR05CA0086.outlook.office365.com
 (2603:10b6:a03:332::31) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8835.25 via Frontend Transport; Fri,
 20 Jun 2025 21:38:29 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ5PEPF000001CD.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.8857.21 via Frontend Transport; Fri, 20 Jun 2025 21:38:29 +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 Jun
 2025 16:38:28 -0500
Received: from [172.17.97.97] (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 Jun 2025 16:38:27 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ebc11b05-4e1e-11f0-a30e-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=E2LeMd2MotBGCqgjddSFOrKtAPggS3uhr0Bn2+J+skfyxIBWQoH3FOddAkne3eGuW+w5b6RWiYpQ2AJ0i6NqLCHkOgBVRJJvrP+kp4QgNs4bWt7hxMS5iwJ/7t7pmPsCl+QknQ+louK31CXufWnRjLmnrSH3n7yzXOy434PqVpjRjkF/ObXuYIHmgpALK7amAyDTOVB2LTXQA2u2BBXGzN3sE23ENITCYBDnDYNnNxsQ4Y4mMPPK2Ja1TpggS8jvcboaN1Rjwp7eEfTyPa/nsnjN1FXhYkbm0TDXuU0gt2WhrSC698N8RKyAIjPD+PqXFCKgn9mYRH2tWm2phkMUOA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=HmXWvIjVpphAD0tyUXrdGPKbfnf9wBxPfP67f4xpYTE=;
 b=xC+mErukiBtX+EcFzr9PsJtCaEuK8lR2KUl+Gsp6TWxLLEPOmZMpmA59Q71S5qtrRCqGF8G994c+HhVhxmSibON9YaMTJm0bgC1W38tGBhDD8MtK73fPd29kTicx3JpTDHLuYzsZigksUd/KBhDuik3mUaLdWRuhLgTftx4kFjZG3Msc3dWmgZWK2N2GAYcf3xqeVB8NrK1kFR2Mf1ZQuIHbBhPNRVgMT+NOwQtQSYjgez5Jdzx3hOftHOh1jlIHMDdcGGyftAcwT+wGo0GCyy6l7YqX1YWI7bWcrK39xP8ydh681Negk5FbT9m/I1Q/XRlrFSomZTSwlG+XX+uHkQ==
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=HmXWvIjVpphAD0tyUXrdGPKbfnf9wBxPfP67f4xpYTE=;
 b=hE6L7NJ68Rgagjxcck58qbpH16k06CovDEFGeDTudpCrydQUpUMW3r/gy9ClwDbbollN2FkZUApkcS2ytZA+EN2XV4DEQ5DwKUADfvRksCRngtnQvU7vRv/K2Y8pvOCqRX2HCmffWVWRi2Z58WpHCthVob6hum42Kb/DeQWRzik=
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 Jun 2025 17:38:36 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [MINI-OS PATCH 2/6] setup: drop parameter from map_shared_info()
To: Juergen Gross , ,
	
CC: 
References: <20250619113804.32694-1-jgross@suse.com>
 <20250619113804.32694-3-jgross@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <20250619113804.32694-3-jgross@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: SJ5PEPF000001CD:EE_|CY1PR12MB9626:EE_
X-MS-Office365-Filtering-Correlation-Id: 36775c8f-fc67-4824-ca3e-08ddb042cbea
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|376014|82310400026|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?U1NDRkNlSjBtQU5SbE1Kd29HcElTazVsMHhCTVZ2WFpvRTl4Y3lYOGtNQ0Fw?=
 =?utf-8?B?S0tBbkp6bEIyV3kzc2Q4LzNnQkl5Y3FFOWJMRUV2Mkl3K2gxMkJtTmJHZVhx?=
 =?utf-8?B?YkpYbU1uQVgycVlOS09zZFU4NXBvQzBTL0pZaGhkdmNzTHhYcEx3RE12elpH?=
 =?utf-8?B?dCtDU3dENjNJTDBEVzhYdHFkdGlVSkNtbmxzSjJxdzY3anZ6VFVTSzRMUnZ6?=
 =?utf-8?B?RTVENUpoaTNYVmcxc1dTbUtZL3RHZDNWeEFuQnZaZVJxdi94cVVacGc2VGFH?=
 =?utf-8?B?QkpHWG8wVDRyaUcwVjVib2tsZnh5ZWdsdGlBUFNmUGVCTjc1UE1TVEc2dEhJ?=
 =?utf-8?B?TDYzRlhndFNZdzl4YWpwUWw3akREWTFqTG93K3g4OG9vWGhOcDl4T2FNZkI0?=
 =?utf-8?B?R0FJQXEza2pVL0VUblhRRUxPZ3llQitlUHllU3ZHOFdyTXNyQzJxb1FLaUpJ?=
 =?utf-8?B?L0lVNS9DNlF0aTg3N1RQcjNPUkM3RHl0cU5FaGJVMDBIZXJkMGlhSC9pSE1X?=
 =?utf-8?B?SlJCaXdLNVRsUE9CWXl4OW42MVpwWXpuaXVsbHZEanl0UWRvb3IvcTJNdnNr?=
 =?utf-8?B?QUJOU20yL2FTZWhWQzByaWc4cGIvdytpOEJ4dHJkdXRnRExCRmNnL1kwbnZI?=
 =?utf-8?B?NmsxSUJXQmtHMy9lcWZINUMvQytrcklDSStpb3VsNmlTQitTOUU3ZDVPQjEz?=
 =?utf-8?B?VittZjJtdkxzSU1OVHUxOGV3MUZ3bUZyQmYydVczdjYxdFFZUmZrNitYU3VG?=
 =?utf-8?B?cENhS3dPRG1FbGt3R3N5dG00Nit5VUZPM2UzQ1g0alVabERMYWJFMjh4QW9T?=
 =?utf-8?B?QzdpaU1JNGtNNHh0UTZONTJHeGZZY2JtNDdsdDhjdGR3M1dJSWZocU10WWFI?=
 =?utf-8?B?R0U1UlpMbDN5K3VYdkJXSDI3YWY3dURYRHlST0ErYlpuVThEcVF3RHlkZElE?=
 =?utf-8?B?UjRIMnU1V0FQSzRRZ1AvTXBPOVplUFNta3h4NFpOR0RrQnlsaVA3RXl3MlZE?=
 =?utf-8?B?anArTFlKRXV3MVNLTDZBVDBwSW5yM2xZN3FuN2ZvZ2lCcDRud21aRWNIM0ZJ?=
 =?utf-8?B?S2NPNnNram10bUV0amRTd1RZUmwzWURGKzdEejZ3V0s2c1IzcUk3R2Z0SGFC?=
 =?utf-8?B?VnprRXRBN2hQWHNRUE5lVnZOQVJJNTdFRXRtWVc1bC9mSkhkTTQxV1E4WE8z?=
 =?utf-8?B?emFFaUtTWVY3bXpWTlVmOTFKWEFjZGlNVnlmRGZjTVhCQlBmcHJaSFRsK0dO?=
 =?utf-8?B?N0lmRFZXV2xnYVRtL3hhNWk5K1lLQld2VmsrcXJqb1VhK3AzKzVJM3NEdUp0?=
 =?utf-8?B?YzhrVkRpNGdTT0lxb3ZkbWVQVUF0R05XUm5SbGlrN0twemFZUEUwNUhHcVFP?=
 =?utf-8?B?eS9TQVo1N00xOFhCbDRBMGtjQ1IvUU8xL203T1I3Qm80VFFDUkdSNHdSMnY4?=
 =?utf-8?B?YjRHREx1NXF4VkkyWGdSU05Rem94RUFqeko1aUkxSEZob0Z1VEowUWl6MVU3?=
 =?utf-8?B?STJZUEJYdWxEdGsreE93aDg1TzFrcXVjRzBnQ2hVY1YwclFLR3ZXci8zZWR1?=
 =?utf-8?B?YkZTdE1UTnhuUW5CNnlTaFJ1QzdiblFSWlV4eDZqS01vdVI4d2gyMDJNT3d6?=
 =?utf-8?B?cGJnWUFJanNTd3hudFZ5NGhaVVdnSW9RcFg1K0xlOFBPcjBzU0FrRk5xMndJ?=
 =?utf-8?B?cC80dUk1dnM0Q3hZSXBvSWVXUmJkellqNmNNRWhQdngwOFJSL2d0ejdzSW1o?=
 =?utf-8?B?RE0zQXRQd1FRcnNEYjRPUXJHSWVTTXdsTUVVQlFJZnVtYXF1SlZqUUwvQUNU?=
 =?utf-8?B?ZHJwNjh3bjlqbWdwSXRzdGd3R2xrV3FxUzBXZEY3NnV1SmN5c3d2czFUZWJo?=
 =?utf-8?B?Nm0vT2N3WUg1L0p2MW5QTWVac1NrSDdkWUdrV3BRNEtUUmh3NU1kYUwveGJS?=
 =?utf-8?B?V2tQbGRyWXdGZjhjOEcrZHM2aFpkOUpoSWxyZ2JNZ2VsZTB1bytyUlMwd3BZ?=
 =?utf-8?B?RSsyeUxMOTcxSlJ0cHFRRVloWHJ4NjlBRDlnMm90dlZhcVlXSGJZMjYrNXUv?=
 =?utf-8?Q?MoniTb?=
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)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jun 2025 21:38:29.0631
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 36775c8f-fc67-4824-ca3e-08ddb042cbea
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:
	SJ5PEPF000001CD.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR12MB9626

On 2025-06-19 07:38, Juergen Gross wrote:
> The parameter of map_shared_info() is evaluated in PV mode only, and it
> is always the pointer to the initial struct start_info from boot time.
> 
> By setting start_info_ptr a little bit earlier the PV variant of
> map_shared_info() can just use start_info_ptr instead of a parameter.
> 
> Signed-off-by: Juergen Gross 
> ---

> diff --git a/arch/x86/setup.c b/arch/x86/setup.c
> index e30eb065..1bdf9509 100644
> --- a/arch/x86/setup.c
> +++ b/arch/x86/setup.c

> @@ -185,6 +184,8 @@ arch_init(void *par)
>   {
>   	static char hello[] = "Bootstrapping...\n";
>   
> +	start_info_ptr = par;

Should start_info_ptr only be set for CONFIG_PARAVIRT?

Oh, patch 6 does that.  Strangely, patch 3 and 6 are not in my inbox.

Reviewed-by: Jason Andryuk 

Regards,
Jason

> +
>   	hpc_init();
>   	(void)HYPERVISOR_console_io(CONSOLEIO_write, strlen(hello), hello);
>   


From xen-devel-bounces@lists.xenproject.org Fri Jun 20 21:40:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 21:40:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021295.1397295 (Exim 4.92)
	(envelope-from )
	id 1uSjTh-0005Kj-EG; Fri, 20 Jun 2025 21:40:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021295.1397295; Fri, 20 Jun 2025 21:40:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSjTh-0005Kc-BJ; Fri, 20 Jun 2025 21:40:53 +0000
Received: by outflank-mailman (input) for mailman id 1021295;
 Fri, 20 Jun 2025 21:40: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 1uSjTg-0005Ia-CO
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 21:40:52 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on2060e.outbound.protection.outlook.com
 [2a01:111:f403:2412::60e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 399cec86-4e1f-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 23:40:48 +0200 (CEST)
Received: from BL1PR13CA0136.namprd13.prod.outlook.com (2603:10b6:208:2bb::21)
 by CH2PR12MB4152.namprd12.prod.outlook.com (2603:10b6:610:a7::8) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.35; Fri, 20 Jun
 2025 21:40:42 +0000
Received: from BL02EPF0002992E.namprd02.prod.outlook.com
 (2603:10b6:208:2bb:cafe::52) by BL1PR13CA0136.outlook.office365.com
 (2603:10b6:208:2bb::21) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8880.13 via Frontend Transport; Fri,
 20 Jun 2025 21:40:42 +0000
Received: from SATLEXMB03.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.8857.21 via Frontend Transport; Fri, 20 Jun 2025 21:40:42 +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 Jun
 2025 16:40:42 -0500
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 Jun
 2025 16:40:41 -0500
Received: from [172.17.97.97] (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 Jun 2025 16:40:41 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 399cec86-4e1f-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=WRZxb++AfVxufMreH2idUjCte/y0EAVeGPTUfdtZ4xPsMLGmUxQqGDW5pvmiy2+UgTrAQ9JR+fRVniAIq+izHBBXwvcryR0sHPBp7ccsQBf/IkmWs++rp7ChRRGy62Lhc+fTBhd7U6jQ2eaQhBgbw3m8ezhZWCVrOOwBcF1y2UuS6hf7Y5U83mue9X8MpnH+29Fi61vgdLgSQrj/CRAWkBLiunxbBHhUbynOQf1eWzbXKrnRBfou9kcPR36Pw5O8nk4Ck4//XsT5ErSPwphyB26YF8MOEtBNhl8I6zjcm5ke2Eb9fycY2PxEkAV8gtRU0k1ydqttDVn0iVg8ZwomWg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=HaOQMQM8R53Pq1SuAJVh1uVYlk0x0GL+r2bS6G96ydw=;
 b=BiRSubHFukJhMYzGxuocKxUgqPog+VF4/NHJD7zZLIVrGmzuN1kc0a6tvpNK1s6HN7wpLHmmhfAMamKmbVBSycuUZcPRnUNhcj/E6Rt45lFV6yu1SgWBtptUBQEvPVlRK2Qgh9Zq/YleBqEgUfMuc7fJqXLEuBRZVISRKOf7Ee/rG3OJ/BkBd+RO4C9PUw+5oU3ckqLOJqYGxeCidpbd/rvjI+C3DjQ+vwAycyWEhhh2UCHHAX2J/P4qZx0NhiBDUdy6hYaSPPDC/s38ILKvwAW8qFsYlccdvthwc+gitJOZucRBE4JNEwPOkPZnyJg/w9zpkiANr0j1TPysqysC5g==
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=HaOQMQM8R53Pq1SuAJVh1uVYlk0x0GL+r2bS6G96ydw=;
 b=MDuTSXXI/EQsSBadlC6Bpy9sVRhoiuqPvYmlg0eIebqtD8RkFH86ld6pe5C43hOz8P2Ld4xxnFBOjBwCnhSpZk7lZEGylv4rOD0n/N8VHzHB8cqUKHuqb8jdFYd02AMw5Xvw02V60xdBodO53yuljbhSmFZg/ubVGGte8SzozTo=
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: <13137084-a62e-489e-9521-9092bd570bf0@amd.com>
Date: Fri, 20 Jun 2025 17:40:44 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [MINI-OS PATCH 3/6] x86/pv: remove global start_info
To: Juergen Gross , ,
	
CC: 
References: <20250619113804.32694-1-jgross@suse.com>
 <20250619113804.32694-4-jgross@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <20250619113804.32694-4-jgross@suse.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL02EPF0002992E:EE_|CH2PR12MB4152:EE_
X-MS-Office365-Filtering-Correlation-Id: c1100c64-8b26-46aa-3766-08ddb0431b51
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|1800799024|376014|36860700013|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?MFpoSFoxOWxiSG9VRk9kYk50WEhUc0NrdWxKWi83L3ROOHZuWVpMWENEMXpI?=
 =?utf-8?B?ZGR0S2JkS2UvL2dTKy8vNnljTDJMU3FnVUdUeEROR1cwaUNMNGJrOWhhTXFW?=
 =?utf-8?B?SzFSblAxNlNqbGh6cVNmRHVTN05ENjVmK1F1R3FYdVp4Wm9PdnhUaUNOK1ZG?=
 =?utf-8?B?Q1ZqOWxDMGV5ZGhKTUR5VGh6TlpJclorajJPMG1IWnVCNXF0aFk1eS91OHIv?=
 =?utf-8?B?MjlUaW1CdGxDcXp4cGNCRzVRM3hYS25mTVpoMS9KOXJzYU1DbVRMWjAvL3pE?=
 =?utf-8?B?eklES0l5bTVaU0lhN0x3bkhnVWZuZm1iV0N2MjRXYko4dEhlbUd2bUpKSjhj?=
 =?utf-8?B?a2YwM1ozUjYwOUVSNEFRbzlMMURQekZsb21iZjVJZXV5VWlGODNpRU9wVisr?=
 =?utf-8?B?SlI5ODBwQ2hyTU01dTNyZXZXOVBhRndWdmFCYTI2RnlhZXMwSFQxT2VZWWFD?=
 =?utf-8?B?SDhzMVhtMkpNK2F5SHBzdHZRdldGN1NtMVRRc09MODZUOVVmQjZibklNSjZw?=
 =?utf-8?B?aTZzNGxIZTdvandUajN5bk9DaFlJNkl1bitPdkszQUF2TFBKNGtibDJ5RzR6?=
 =?utf-8?B?Q0xOUEQra25abDRVNDhpOFl5cHo2amJnZG5vL3dISEdPSkdwYnhZc2piWmpi?=
 =?utf-8?B?dUVKUkZsNHhDRTIyM3NkVit6dXljaGxuRllvR2pEMHp2cDNGMDRhamxJaito?=
 =?utf-8?B?ZERibG1hQndwR2pjLzdiMHcwMWZBNTdxZkRkYnlVL0xRcElkemRpUmgwWmha?=
 =?utf-8?B?M2FKOGVuM3o1QTVuU2cya1VydnhTMXk4WkJ5VjJ0L1RWWmE1aTFRSVlSRVVy?=
 =?utf-8?B?b0xtZ3E1MVlIY3VnOTJhd25CSHo3SU54SlFwSzNoYTdUS2VLNTZDVkVvcktY?=
 =?utf-8?B?YWNuODlPVWw2NkFkZjFEclBmVDRaamNjcW5aNmFJK0U5b2hhaTlhSzNpQnQ5?=
 =?utf-8?B?YzNjSXdMTFBOY0MwQXc1bDNtRVI3ajNNeHpMa2tkbUdmZnQxWStrRldDbTQ3?=
 =?utf-8?B?UnFBbWZ5Y3FNdk1CT0IwTjhCRDN6MjV4KzFFYzgwWC9ONlFFUnFlK3p1K0Vr?=
 =?utf-8?B?M1Z0Q0NwaWU5dWxpNk43ZzJUUjZ6b1o5b3VBeXVhVFdETkJjSzBEbUFsVkNh?=
 =?utf-8?B?LzZPcytqbVNxdUFlYWtaVmszRjM0Q1ZQNEc0dzNpVGREM1V1K04rYi9NbmVW?=
 =?utf-8?B?SkpQdXpSdHZmcnQ5VGIvVU16OVN1MWVvZkJudGtGVzZzMnl4OHB0Mk91UUVR?=
 =?utf-8?B?dnJxSGFjT3orNWNsc0RUcm5OdzFjZDU3YWRuOHpjSnB2b0xSY0lic3FaMzlr?=
 =?utf-8?B?ak9EUXl2THE3aiswOFRHUFN5VUxqTFYzclk2bXBmd1pxdFFKcXFMWDcwNTVH?=
 =?utf-8?B?NG0xUG1TZnY0YkhLZi9heGgvYlZqekp3MDA0RUdwTUVkMGN4bDNLUytERzBa?=
 =?utf-8?B?ditJMDVsTXZvR3ZaQTloVisxVkU3a1dkVW9SSDcwKzdIUDljMnJNV2tPRU03?=
 =?utf-8?B?eHVxOHE3SmNlcHVFQWNseDRzZ1NIWkpUZUpjOTcwbGFwN0VzZU5UY2padDFF?=
 =?utf-8?B?cFhOWHh4V2YybWE5cjVmaVpoS3hMVXJ5WUdxbzB4ZVJ1RjZOVXlRZFlNRUtv?=
 =?utf-8?B?TVZNOGwrQXc3MHVJVGRud1I3bXdoM3I5VjMySlZWT2R1MXBmWDU1aXMyUlVP?=
 =?utf-8?B?NFJHZFFtZHZZM0EydW00Qkw4bmxxNVRPeSt1dnVBR1lUT0dvMFhxYUh4MC9w?=
 =?utf-8?B?VWpiY1VvVXNaOC92Rmw1VlhWemNrUnR4Yi9NREhCZHZvV0JDYkxKY0dPVWxl?=
 =?utf-8?B?TFVmUFE3NTdQaFNqZ1d6V3BuaDM2MUdWS0hsWjVqRVpOR3JjdnZncVFkdTRl?=
 =?utf-8?B?MTJYYVBZNkNPbU1TUXlhTytFVzMyN1Y0YkpxU29FLzFpSHVWYU44OXkxSEdQ?=
 =?utf-8?B?OCtmYW5mVys4dytxMEVxZzJGczRNbk9kYzZpcHFzUncyRkNkWVpUV3kwaDJH?=
 =?utf-8?B?WlM3ZWpKaE43MG5DaXdnMU5WMGtWNjlJWXNLN0xRTnc1WWR4ZXFJYnhrTGQy?=
 =?utf-8?Q?VPgEVx?=
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)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jun 2025 21:40:42.3656
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c1100c64-8b26-46aa-3766-08ddb0431b51
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:
	BL02EPF0002992E.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4152

On 2025-06-19 07:38, Juergen Gross wrote:
> Add an extern declaration for start_info_ptr when running in PV mode
> and use that instead of the copy held in start_info. This allows to
> drop start_info.
> 
> Signed-off-by: Juergen Gross 

Reviewed-by: Jason Andryuk 


From xen-devel-bounces@lists.xenproject.org Fri Jun 20 21:41:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 21:41:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021307.1397309 (Exim 4.92)
	(envelope-from )
	id 1uSjUQ-0005sg-P9; Fri, 20 Jun 2025 21:41:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021307.1397309; Fri, 20 Jun 2025 21: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 1uSjUQ-0005sZ-Lp; Fri, 20 Jun 2025 21:41:38 +0000
Received: by outflank-mailman (input) for mailman id 1021307;
 Fri, 20 Jun 2025 21:41: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 1uSjUP-0005Ia-GI
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 21:41:37 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on2062a.outbound.protection.outlook.com
 [2a01:111:f403:2415::62a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 550febba-4e1f-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 23:41:33 +0200 (CEST)
Received: from BN8PR07CA0034.namprd07.prod.outlook.com (2603:10b6:408:ac::47)
 by SN7PR12MB8789.namprd12.prod.outlook.com (2603:10b6:806:34b::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Fri, 20 Jun
 2025 21:41:29 +0000
Received: from BL02EPF00029927.namprd02.prod.outlook.com
 (2603:10b6:408:ac:cafe::65) by BN8PR07CA0034.outlook.office365.com
 (2603:10b6:408:ac::47) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8857.25 via Frontend Transport; Fri,
 20 Jun 2025 21:41:28 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BL02EPF00029927.mail.protection.outlook.com (10.167.249.52) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8857.21 via Frontend Transport; Fri, 20 Jun 2025 21:41:28 +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, 20 Jun
 2025 16:41:28 -0500
Received: from [172.17.97.97] (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 Jun 2025 16:41:28 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 550febba-4e1f-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=PbTtYgG68ctedPap1NpxqGcpiDpzti0UaU8rUdUKXAx1d74peks02lMC/R0mu42aTcMCiWXtll0aTU6fbOmMJmuO+WrvAat3XGTqIDYionhYRw+2oU6NDZLLYWNqEvhMk3KOEt6YytRKIJx05TV4ky64mxBRCGz0/YABr6+hFHi81SXyDaZlVxyJLszwOV3lpAP1NqdMGQQEXvMnXUVgcR54ZjjcigwjWsvS+GQEX0GKAoghw6eatB1DX+O3ScFS4noJAYzg5CDzoMrADwf0U8Za6dTUuYi6Lrl/cfspf+cgWYfgZd/m9b1EV1HCVFkI0bgzySALJDX9507VHKXdEg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=lnWtiEgKIUpWLHi4r9fsJLbrakgE873JK2R6onI6AZk=;
 b=kJDYCua13aLLVjvR2uZk6p0TeJjs0z2g6I+xzAfgkmSGebvK9W8SCDwRmvLFZICL8fkviYDtEgVz+NF9NYGNNv98Vnd1n5VoAXqQuyQZs6A7pxdxHTMmv1FNNRHquYw7ygzXziCNtYi2zY3TMIKrXtWGnSppEn09cY8vGVgEtSeSISNFdQnWdklj8kU21R++YXY2CVGfcCBqKUbI7jXnhyFPsbq7WSNaY/IvbmwJHh7YOb5pcHYzXoYssduNj0jq6nuwznUi64ye4/SOdey6ylxL8+a7uY2VN0HHgghc7NcLdzBdpWrpzBtCQlCXKffEbm0+c7scdgu8wdU9p7gLZQ==
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=lnWtiEgKIUpWLHi4r9fsJLbrakgE873JK2R6onI6AZk=;
 b=u4DXy4A3RPZGJCYMFI2jYUTmhTGar+uEk/LTJauxTxNf3VXNoAdl7+LHfDgRA209TiFLdvPs6t3cF/12JQ5uyenlW2FG0g+cVdEMZhK28+P60yF0Di9lO7f9RE2sRu7qkVVCRTM2lwCx8RoHNuha89wY0m7qsBU3bjqAf49sP5I=
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: <20d2338a-015c-47f0-b341-d561e0ca1005@amd.com>
Date: Fri, 20 Jun 2025 17:41:36 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [MINI-OS PATCH 4/6] console: drop parameter from get_console()
To: Juergen Gross , ,
	
CC: 
References: <20250619113804.32694-1-jgross@suse.com>
 <20250619113804.32694-5-jgross@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <20250619113804.32694-5-jgross@suse.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: BL02EPF00029927:EE_|SN7PR12MB8789:EE_
X-MS-Office365-Filtering-Correlation-Id: 7bd6b741-8939-4cea-091d-08ddb04336fe
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|376014|36860700013|1800799024|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?U01SV2dmSENGcU5EN2c2Z0xYb05EQTBid2VrUHNVWWJZSkRyS2JieW9RVEZ4?=
 =?utf-8?B?MDE1TFhuRVM3dFA3dDNzV1dha0wvYkFZTjNSb0pjcFhySU80Wk5ZWjkwa2NZ?=
 =?utf-8?B?V0VUWUNLRWZWR2Z3WUE4d2J3SHgvVmYwZWNtaHZpR0pUUmswNmp2YzJTREcy?=
 =?utf-8?B?K1FwdjUyWURYYW1ZUjd1U0FjR1dDWnY2OGw2UnNjd3dvTzd0bFNydEdLcHNZ?=
 =?utf-8?B?S3c1VUdCd1pzMmlYQkwwUEQyWkpWa016UlJ5dW02R1ZuM0ZOeWFTcEFMVGdy?=
 =?utf-8?B?TEh5dHlaZlE1d1FCNjJtaXhUZ3l1Q3FjQ3Nna1dGWDVRV25mRGhjaGVkZVJY?=
 =?utf-8?B?TkRWMWNmcWE3Rnc4UU85dkU5YzhybXZqZ1J5UFhZUVNaRmJ2RkxiZ0lhSmJF?=
 =?utf-8?B?Y1JvU3F0eGc4OG5zc3cycmZOMXkydzR1R0EwWStodHJXQU5rNExDcE9va25V?=
 =?utf-8?B?RDRIbGNsdFZ4MVc4bTFvTXlTa3ZQZktpTkZPdS9KUzJ2bUtGU0NjVHgwNnZq?=
 =?utf-8?B?M2tnWWhsYXlpUlhoWGE2NGdJQW5leHZvWHFkcE1TQldZNHlyT2xCUGc2djE4?=
 =?utf-8?B?VWcrOFYxdHlHai9PNWxVQXEwK1JzSUprbTNPbHdpTmw5dVpld1d3VjhlRXA2?=
 =?utf-8?B?SXRUOVFMT3RNTGJibWVVNFpLZkNsZlM3SGFNMW1sa1J4NWFPa254WlNTSmhU?=
 =?utf-8?B?VFFxZjBwdklEWTNyYlJrdXl4UjlXMGd0VDZUaVNLVUpFUDBTSkh0cHJGWXgr?=
 =?utf-8?B?ZGV3dDhVQlphSTRKci9HT2djbDFtcEtJLzNKVjU0cDc2QXkvelFTQW9nbTE1?=
 =?utf-8?B?MStKclEyQUFLeVIyUDBvMDRMbS9xdVNmalBzMGlLWmF2K2VlZDlVMUVEbmtJ?=
 =?utf-8?B?d2NVcHNrd0hyeStFcW5vQi9Ic1ZwMHVNRTNlQWs5RUtNaGlPOHRyUHlZVWwr?=
 =?utf-8?B?NVUzRkdWTG1GUnNxRzBwK2dPYVlHYkd1OS9pSVNxeFBhdWkyYXdJUm9HeXNK?=
 =?utf-8?B?cWxsNDYwc3lwNlYxT3dNdk5SZ2w3SXpmdEZwekQxU0Y0dTBhOUUrRDhLcUZJ?=
 =?utf-8?B?c0paMEtYd2k5UVFpRHErNG5mTnRMeFU0TnA2Z2hWMkRjYXZCcWo2WkZjWUFz?=
 =?utf-8?B?dU5vZjJVOTZabWVoelpidEd1VlZUejBWSUVWeFNDSEtlcnlnK1E4Vk5PNXRP?=
 =?utf-8?B?ODFtN2hWRVEwZnJFMzRzdWNUN24vL1Z1dEFiRmN6djlwZE5TTnZYVDNFSVpN?=
 =?utf-8?B?aVJDcEhOTnFacGt3MzlGQVdsTHoyYmVwN0N2ekl2U0FEWW5MaGxqdW9CUEFS?=
 =?utf-8?B?M1R3YmpweWliNWtrYWJjTVBPMSswcTgzY2pacTFISDZ0d2g1Z3FrUTZ2ZjlY?=
 =?utf-8?B?NGxLcVN5RDUyenJMbjgrM1llNFFJWXhOUCtFblAveVJYOUZTK0pEdWU5N2Zr?=
 =?utf-8?B?UGhMcDkzTzJxbGxTTU5EaE5FV0NobnZEYlVIS1VXTEJBc0N0VnZaZmhMSkRi?=
 =?utf-8?B?bk5hSmlFQ3NIMHRFSHVLZEtnaEtza21XR0tlcFhmRjJxeWs5UTBHdU9EMGMr?=
 =?utf-8?B?bXd3MTZiK04wdHh4eURocTExaFJBTUdrVHhPR2FTUmtwbnAvMFo5NkV4U2xC?=
 =?utf-8?B?ZVdwQ0dzZWNveGZFeUlWcmZEb1QrK3hYdEFobE1JQzVYTGtudGxXOTlVdTZ5?=
 =?utf-8?B?ZXFLMEpSTkE5Qzd6SzdSU1oxQ2FjR3RMMFByaUxzcGEvZkVVdGhtc3VscEtQ?=
 =?utf-8?B?QVZ3VEM0ajlNSm8xa1JESVBZb01hUUM0bTBiSVZRWGxRWnBoTi93bVJVcS81?=
 =?utf-8?B?ZVg2WWZzdU1BeEtTUFlRbzBleGFMdktUU1lUd2JlSzBzSm5HWitYYzhadkVu?=
 =?utf-8?B?R3hTNHJ4M2pUVUhMSXJMV01hbWlMYVR0NXRUcEN6dVFtdUo1a2FiWnZKWTRO?=
 =?utf-8?B?dWRPdDI1U2xEUy9SNGdQaEJHTi9nSDJFTndaNkF3YlN1Zmk3TmN1OHcwTGYv?=
 =?utf-8?B?RjM1RU9idTJqUVcxYTA0ek1BQ1lSKy83RjAzTGpOUktDOFFlUEhDMjJVSVpn?=
 =?utf-8?Q?iP9yNB?=
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)(36860700013)(1800799024)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jun 2025 21:41:28.7970
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7bd6b741-8939-4cea-091d-08ddb04336fe
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:
	BL02EPF00029927.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB8789

On 2025-06-19 07:38, Juergen Gross wrote:
> The parameter of get_console() is used only when running in PV mode,
> and it always has the same value.
> 
> Drop the parameter and use start_info_ptr directly in the PV variant
> of get_console().
> 
> Signed-off-by: Juergen Gross 

Reviewed-by: Jason Andryuk 


From xen-devel-bounces@lists.xenproject.org Fri Jun 20 21:42:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 21:42:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021318.1397319 (Exim 4.92)
	(envelope-from )
	id 1uSjV5-0006Pf-1b; Fri, 20 Jun 2025 21:42:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021318.1397319; Fri, 20 Jun 2025 21: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 1uSjV4-0006PY-Uq; Fri, 20 Jun 2025 21:42:18 +0000
Received: by outflank-mailman (input) for mailman id 1021318;
 Fri, 20 Jun 2025 21:42: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 1uSjV3-0005Ia-92
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 21:42:17 +0000
Received: from NAM02-SN1-obe.outbound.protection.outlook.com
 (mail-sn1nam02on20608.outbound.protection.outlook.com
 [2a01:111:f403:2406::608])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6d227d1b-4e1f-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 23:42:14 +0200 (CEST)
Received: from SJ0PR03CA0088.namprd03.prod.outlook.com (2603:10b6:a03:331::33)
 by LV3PR12MB9265.namprd12.prod.outlook.com (2603:10b6:408:215::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.25; Fri, 20 Jun
 2025 21:42:09 +0000
Received: from SJ5PEPF000001CE.namprd05.prod.outlook.com
 (2603:10b6:a03:331:cafe::21) by SJ0PR03CA0088.outlook.office365.com
 (2603:10b6:a03:331::33) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8857.25 via Frontend Transport; Fri,
 20 Jun 2025 21:42:09 +0000
Received: from SATLEXMB04.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.8857.21 via Frontend Transport; Fri, 20 Jun 2025 21:42:08 +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, 20 Jun
 2025 16:42:08 -0500
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 Jun
 2025 16:42:08 -0500
Received: from [172.17.97.97] (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 Jun 2025 16:42:08 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6d227d1b-4e1f-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=v4hNrikggmoD0dyyIg8hvXWXKIQt/4Nn7DJWQ9RLHkse/cspz1pFeV1tSxp958KzFXsplYLJ+yv5zhvYtebTbXyOgiLZLTDzVA3IeGW2LIGwv8AACKKOiUmiOxPi/qn8IB58xSlerASh+SqnCJge0TCyn3/ZFJRZqOeSdJuCQcAGVrsz85H54xeKWCaIlmHlrSGi5OpqdL8fkD8EdXSg79nxXVd8EmBokT3kYl4H8meEdagxtXewpEboJnEl5ATvSQV2cZBIMOQCVj6e4fb5wLhV5QbkU3UpAb2yjfwmqGEXmaL5jdz410rka2avhaMpJEncFA5rXPm9NzxdczB5YA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=A9zDJO6/fOEV7xX/ZIsWH1ryc7bzxtbx+F6ex67VRlQ=;
 b=p8AIVf+i6N5lqH4Zlq3Ows2TgWewVXyS5/JoxKHR6q3nrA9E5U1X5VLOlQ18VY4tYdqiueUd0mZFue6Ze2DWa5QMXmh9lN5WwDQHbrjJdvz71p2YXZvFN3PQzr187Mtjt0agaCniJcnvjcG4Y1dL8MMHvnGMZrALBPuNiKAvfgpQKpNVGY78DZEfgdcyUK/pElm6ZVSuvRYh9hx3RBIXk5sbFA3Z3KIIbN5BHnVbf7AsvIYUR/5Dkruy4k2k8wgYZNh3axN+7/HUDjD/TPt8yja92wE/mCwB3Nv27cVTHJwjAi94d97NlGppUWkQ2loMa2B8jrznpncSyyZkhOzs9g==
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=A9zDJO6/fOEV7xX/ZIsWH1ryc7bzxtbx+F6ex67VRlQ=;
 b=V7I1PIzp/HDdR5qMQBE8THb++sSkNt8yzOTAUZjBEkpDHE6dbsQCfWnrEli3a+NdJxWY7ZyCxFpLvFM1X9Z86CV28S+UqfB2qFRnnwFRQcR0D4YSeeSdO9WF4Wqobdvb8+7HLWTaOclxPbonnHwMQ66ifMD/GKGF9aZKoqUZlEY=
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: <8f208946-a69c-4e9d-af92-5a6278b01418@amd.com>
Date: Fri, 20 Jun 2025 17:42:16 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [MINI-OS PATCH 5/6] xenbus: drop parameter from get_xenbus()
To: Juergen Gross , ,
	
CC: 
References: <20250619113804.32694-1-jgross@suse.com>
 <20250619113804.32694-6-jgross@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <20250619113804.32694-6-jgross@suse.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001CE:EE_|LV3PR12MB9265:EE_
X-MS-Office365-Filtering-Correlation-Id: 13c15c7c-aefc-416d-9ada-08ddb0434ef8
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|376014|36860700013|1800799024|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?OXYxb3pHOUdYWTMrVnFka1lYTS81WlR5MVlvblNDOHVxalFaQ0NaZ2ZHWHpr?=
 =?utf-8?B?L3VJTkpxSmhkSlVWOHlnTElTRGJtdkJKelUyanhVY3hSQnVidHZ4d0JhSFhU?=
 =?utf-8?B?SVFiQmlTUTJabnJFOVhNSXFjUWNiMm5LQWtZdEJSRGtZNUNVTis0S1FIcUwy?=
 =?utf-8?B?UkxnbXhxSUVFcWFYY0g5NFhJS0ZtRGY3NTRCYW5mcm16RUhabkZLZTIrLzdP?=
 =?utf-8?B?RFhUYlY1dXhmS2QzTDdtdk9JdHJ5bG0wYmEyMkhmOUw4UlhOS3NUUkMwY0NP?=
 =?utf-8?B?RmJRelE0cVY1SGhkZGt4Q3pjWDdGN0w5WlNvaWRGSEVHblNkcnpNMlVTWXYr?=
 =?utf-8?B?VllRTytNK2VNVVFXdURjNlZvblZTSkF1M3U3UHlZSkVBV0hBeWJMSFlLYWNI?=
 =?utf-8?B?YkZDQWJUUjU3NWpRUmJyM0lEUVFHK0tkUEJaTWR5UjFaV3k5MzIrMHJuNklh?=
 =?utf-8?B?eUJCRmNxUzZSSC9weXl2MW0zaWNqR1dkc3NaM3JVekFieUphQi9NS1QxdW1h?=
 =?utf-8?B?VUpsOWRxcHBGYVh3YkZmYkFlK2s0UDduSG5mSTJaZFNaeUMybDBldHgwcHNl?=
 =?utf-8?B?STZWTmNveDFwMG5uT3Z4UjZsdHFoa2g1cFQveFlQY0NIaXVhc21PcXcwWk9l?=
 =?utf-8?B?TkQxN0UyRHl6UjJYcHRKYisvUHhvSm52cllwWkRubER3a01kcURxOGlRYWp1?=
 =?utf-8?B?RHl5WDF5eSszeVNpSFBXMC90a0RkU1l1cE0zU2FoN2FQRm5PbXpqMGRUT0Na?=
 =?utf-8?B?SCtidFhQNEszeGUwcWJ3RGtFWDMrNElGQVEwS0NEc25yWWxnSkpyUVZvbnBo?=
 =?utf-8?B?TjdBVUViTmg0RjFuZmNLbGRGSi9EeFdvblZ6R1NwamNrWVZ6S1lGRllTcXAv?=
 =?utf-8?B?SlNoM01vSnFJOXZ5MkMxTnI2Rm9say8xbTRhU0RwTW9ScWFZdVlwU1FrQjNz?=
 =?utf-8?B?eWx6dHkwbEpXV2N0Z2lFZFZkZ2pLaGdlQ3c0b2J1MWhiSHVKWDdNY3I0RDJ1?=
 =?utf-8?B?WmJheVJ1ZENoZExVaStGU1FUZzN1K3p3SjZEK0xVOGxnVzhhK0ZVeHN0RFNI?=
 =?utf-8?B?bGowSmJCck56VHkvVFJwU0dKeEdzc3pLQnRCNWhHcHdUdFJkUEowVGZUdldp?=
 =?utf-8?B?c3RBRWluTlpXWnVrbjVMTjE0V0FnWFQ5bEc0NkJhdlFpY3EwNGx1R2ZNQ2ZY?=
 =?utf-8?B?SGJZb0h4Vk5RclIxOThpb0l1dVhwbENYbjNLZEgzNnN1WWVRam1YK1J2Uysy?=
 =?utf-8?B?MDZ1RnpWWEZSbnZvd1BxOXREUnFySWN5bEs0VnZmSjZ4a3RzOGEzcUd1N0N3?=
 =?utf-8?B?elBZanNpM1U3aTRQQkVDemsxMnpUdUNyWnhheDB6OUlmdk5PODFUbXp2TERZ?=
 =?utf-8?B?VHBySncvalFKdElFSEdZQi9vSTlpTnQ1bzUyQ0YxemllOG5UWHhYMEVpSlFX?=
 =?utf-8?B?M0FTZzY2WWs5NGI5bUV5ajdJWVBEcFRTa0RZNERBOHZBYmVUWkJ3aVZBTzFh?=
 =?utf-8?B?NzRrNjU0VGNSRXFROEV5UTJLbUlEd0FrUXhZYm45ekJHUk9rdS9EU3E1U3Av?=
 =?utf-8?B?bnlKS0hleDF3VitVUmthR2ZDVlNab1RjT1ZLQ2ZmUlpPN0xrdkZBU0N2a3dF?=
 =?utf-8?B?NkRqTjhpUkN3YTNqcEk5OVMvUERFUktkazNnUVpUT2RNMU1Jb2FpcVVUWXhK?=
 =?utf-8?B?blA3S3gvUFJyKys4allnMldlYWJzVzhDblFmOXZ3NEcyeVdLQVhmZGF6ZGhX?=
 =?utf-8?B?ZllkVFU5ejYzOFNqUmpkNjI5eXNjdmd0RnFnTU1UWTJyMHE3SXZnM21VSWpW?=
 =?utf-8?B?UUxadzFQb1Z3clgwc1VEV2ppMDJnRSs3Z09HMFRBQ2dPZmovNDRpTUxOb3lw?=
 =?utf-8?B?N1F0Nyt6bllJQlVuUWcxU0tnU3BlVTcza1NmWTEzT0tsTmZxRm9YMzc1aEl2?=
 =?utf-8?B?YmFwc0tWUEpHM2Nzd3RzWEtUbTNKMTBEb1VyeHd4bngwYktUTnBMcDFjRUE0?=
 =?utf-8?B?NDFvNWZqNFFKY3BjdVBsWFVtMWxrNkpYMUVaK1VubnBWNUwwREwzMVVzbzY1?=
 =?utf-8?Q?aupmUY?=
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)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jun 2025 21:42:08.9330
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 13c15c7c-aefc-416d-9ada-08ddb0434ef8
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:
	SJ5PEPF000001CE.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR12MB9265

On 2025-06-19 07:38, Juergen Gross wrote:
> The parameter of get_xenbus() is used only when running in PV mode,
> and it always has the same value.
> 
> Drop the parameter and use start_info_ptr directly in the PV variant
> of get_xenbus().
> 
> Signed-off-by: Juergen Gross 

Reviewed-by: Jason Andryuk 


From xen-devel-bounces@lists.xenproject.org Fri Jun 20 21:43:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jun 2025 21:43:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021334.1397336 (Exim 4.92)
	(envelope-from )
	id 1uSjWE-00075U-J3; Fri, 20 Jun 2025 21:43:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021334.1397336; Fri, 20 Jun 2025 21: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 1uSjWE-000757-FP; Fri, 20 Jun 2025 21:43:30 +0000
Received: by outflank-mailman (input) for mailman id 1021334;
 Fri, 20 Jun 2025 21: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 1uSjWD-000746-Q2
 for xen-devel@lists.xenproject.org; Fri, 20 Jun 2025 21:43:29 +0000
Received: from NAM04-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam04on20625.outbound.protection.outlook.com
 [2a01:111:f403:2409::625])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 977061af-4e1f-11f0-b894-0df219b8e170;
 Fri, 20 Jun 2025 23:43:25 +0200 (CEST)
Received: from PH7P221CA0007.NAMP221.PROD.OUTLOOK.COM (2603:10b6:510:32a::10)
 by DS7PR12MB5720.namprd12.prod.outlook.com (2603:10b6:8:73::21) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.25; Fri, 20 Jun
 2025 21:43:21 +0000
Received: from SJ1PEPF00002321.namprd03.prod.outlook.com
 (2603:10b6:510:32a:cafe::a1) by PH7P221CA0007.outlook.office365.com
 (2603:10b6:510:32a::10) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8857.26 via Frontend Transport; Fri,
 20 Jun 2025 21:43:20 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SJ1PEPF00002321.mail.protection.outlook.com (10.167.242.91) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8857.21 via Frontend Transport; Fri, 20 Jun 2025 21:43:20 +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, 20 Jun
 2025 16:43:19 -0500
Received: from [172.17.97.97] (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 Jun 2025 16:43:19 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 977061af-4e1f-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=U2ZokDvg9a1mpPHBlXMjXQkqPk2ZWcIGOHO7dLpm+CwRCmlQPGgjIGszXbNKAHtyi0TgnJGnN+QFSQCyBbPQIM/t9BHW1QUG0x2XAPcfkFSlhZiUbw2gYYC3MhtiKyyEuxeRN/SkSjEJoSPkPS5fWYDUz+J2pd5dIVpsnCz2VWMtXqJ/ddvjKPtbskFJpEd/lo90nEEiHfElwgXWDrO8kuL28S0zBl3B8V5c3JFmWCogBO9DFMyusj2A+bO+wIxnh4HaWHnZOQK2yIOy51XdJH0wOURzC1eWi5vrkUuoAk6zmKC2U49dy05KuXc4iCKRJdB89GMcLcUe3oGbLQt3sw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=YQvmOxN6quxI4kKQL9VOnr5Rqa+cO8pgNIkGfJ9G88U=;
 b=vKZn4D4P2CDFvjTBeReQZyB1/9Dw6GB4TEfMFe1GMuNlSAOSIHNlRhDNoyIxNaCQEYRNJWOAe43PJYvQXeT9wYPH0i05nv8dxTaSt71EeMbMF5AtuXcIopKnRvYdug2y4ndGaH2UFG+L0oX4KH/shCDS6ERcZppc8mc8k+LVvOg5CnB2wNpTktBxn6SD/aC8TZXxAfqsH7HDc0U8K8/qcdH2xRpYfsILrmnpxuY8CXyIqWJoEfj1JvldkjUSIIJaFclZHL91HTDJGWgs0djizswQ1GX6YrAAGqVrbWpjiod0RUCu0ki2BrJQ9oY45j49d9jb0/ZVBwVSZKyX2X6n5w==
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=YQvmOxN6quxI4kKQL9VOnr5Rqa+cO8pgNIkGfJ9G88U=;
 b=XqOsnzforKYaCOrf42UXxFok3WuuszREhzNDLxz1Z2c/1qB78l8aWKRev+QZWt1LrSUlrMk9+NpPasjBC5LrO/B84vm3wCog8rhULilBGYgCVzyv4ri/n3dAQB2/OXo1zj15Qmv4J4LSTwp3hQ7+oI6f4rgTiBplwzLur7T+6z4=
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, 20 Jun 2025 17:43:27 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [MINI-OS PATCH 6/6] x86/pv: make start_info_ptr PV-only
To: Juergen Gross , ,
	
CC: 
References: <20250619113804.32694-1-jgross@suse.com>
 <20250619113804.32694-7-jgross@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <20250619113804.32694-7-jgross@suse.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: SJ1PEPF00002321:EE_|DS7PR12MB5720:EE_
X-MS-Office365-Filtering-Correlation-Id: f10dddd1-7ba3-491b-0d48-08ddb0437996
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?eHRXamtDRmkrQ3dhNllmaW1ZdklFM3B0VVdwRnJraEZkZnNFK3V0Mmo3RW9G?=
 =?utf-8?B?M0hEbmEyZjlndXhvazY4cURaVUl1NHVNYzNwSzJBcFhWN0hLbUVqZXczRXRv?=
 =?utf-8?B?Wmp0ZzZOeHNWTDhGeVcxRWYxTERMZG9lNUJTWGdCN1hkVmZuUk5Pc1ltd21U?=
 =?utf-8?B?dWNzUGVKd25BcU9YT2F5ZTMrTVZkNFN3aWUzRFpjRGZEMEpud1lQZ0RicG16?=
 =?utf-8?B?VENkWHpQMnBnNVFUWEpNMGc1MGVPRVBQRUlwKzNsY1NCSGFGTzhIVHdFMFNO?=
 =?utf-8?B?aGd1TUNTdEZRNGN6WE9Nd3RtRHZVc2lCMDVkdlRrNWRRS2lCMWw3N2N1Nm9l?=
 =?utf-8?B?eUNuLzFVOUR6VFZheHU3cXVCZytWa0t1NmVwSkJRREFMSW9qUjRvcm5Yd3Qr?=
 =?utf-8?B?MEFJUU42d1dpbEJWZnUweityUGdvR2ZIK3FtSkNCQ0VscDI3MHo0R01JRXoy?=
 =?utf-8?B?MGVORjFES01RRGFyYi9jZEF4VytSOVlCc0dHS2c1UElQcThUc24wRmYvQ1dw?=
 =?utf-8?B?U1RvOFVHa0VwRktPdkFsWUV2OGxyYnhYeVBXUVdGYzBlaTdxWXV1eXp5RE5B?=
 =?utf-8?B?dnBMVFp0Vkd6bXI2VGIzN2hNRDVjcW54YXRzMWhyWFNZeUlna2FGWHZKN3di?=
 =?utf-8?B?cnVKWWFYM2FTSkJHTTUvSys5bDR3SkkybTVhcjdjN3JISW9tR1JVWlFFZnZm?=
 =?utf-8?B?enBIemdvOFpNTE55bVRld3RSVzVkaXQvT3gvN0xmeXpJVGh5RDUzWVZ1R3lz?=
 =?utf-8?B?YmN6SzRzRjNvM0EyL0J0ajFIMDZCTXVxMGI4Z3N2WEhpQzI2ZXFxZVYxUVhI?=
 =?utf-8?B?SHpzMFF6NDdaOHU2SkdqcWRGVndXcUFmYTEyVVpXbS82bkxmdDJPbXFOSmRl?=
 =?utf-8?B?NXJkeFUyaUpwTEZZUmg4WldpMlA1bnhqS0crUUp5ZkNyclRBTVhRYURuN2pR?=
 =?utf-8?B?KzEzUjRHMEkwUnJtWi9TSTY0emlxVWp3N1poNzlvVkJ2WTc5d1V6dFBEMUcr?=
 =?utf-8?B?SjdTK0N2MEJzRlFNWUp4Y05FczFSWms5dXVDa3ZXU0RaMDZDREtmeTlxZUFM?=
 =?utf-8?B?K2JleXFSN3lpSmhVVk9ZeGp4MGY4SGNzVWU1dTJLcmlsTzIwcmZIck12Z1dm?=
 =?utf-8?B?b01UMzliRXVlaWMvVFo1ZlpTeE1BNlNYejIveEtnTWxSeEtndEFTRDdZY240?=
 =?utf-8?B?ZVVISkhaNjYwRXo5WGF5YS9kcHowQm8zakxCaUZYU2ROSjBaYkxWYU4zMG93?=
 =?utf-8?B?OEpUMmtBdm9zbzlPbmxQbTVITWhBa2FFMVhZZENUMkQ4TFhOTU5aTy9HTkF6?=
 =?utf-8?B?UWI4MllUb0daTG5naFBpUVdvWXZDRFgraDUxdzk1ZUZ3OVlMM1JIT3BudlFi?=
 =?utf-8?B?TUVoTG1MeHo2NTFmbjRvdUhHU3QzQlpqSWFvMzd2TVlBUC9wZWdmT21HM1pO?=
 =?utf-8?B?TmcwTTFQaitvTWNQVk93TW9BdEdEbE9vSVpNTEVMdzVFRlUyVEdJTEVrcW9j?=
 =?utf-8?B?QXpJOHJ4SlBvTXlTU1FDMVhTeUhQa2lFT20zcFhvb0hIallCU0JSMThlbnQ5?=
 =?utf-8?B?SlFpOTBMQVJIekZocWxXZEN0OFFUMmxHZ2ZEUjMrRjlReEk0ZStKdUtzQzJJ?=
 =?utf-8?B?dU5UNS9xNVlFVG1UanJqR0JHdGZxUVRxajk0RGFMM3RnMHI4OUwzQ2RLTXlO?=
 =?utf-8?B?SUdYOFAvL3FuYzlST2ltTnBycVpwWkJHSmg3UG1XNmVUYm83YTBZTWdQcEV3?=
 =?utf-8?B?Zkw4Rm1pcmZKc2d2a3d6NjZMNDBUdWN3OWk2TzZEQnVQWWxsTlU4a3BpaGhu?=
 =?utf-8?B?RVVUanovblZwQmtsSWxWTmlSb05iRlZjcjFGeW9qNkF5Vk9iN0F6clJNOTIv?=
 =?utf-8?B?MHg3bC9lYXNWSmJFdEkwemV0NXMxbTZ5MVZEZXBVZFJGZnZxdTNha0pqekJh?=
 =?utf-8?B?Smd4Vnpva1FIVER2RFQrbzlsZ3RBeDFlZTQ5Tm55UjF0VjhlKzVRVkR6cHdp?=
 =?utf-8?B?MHJ6akZJb20yeUVqOEI1MzFDZmRCem5mYlNIdjJPdGN4Z1Mwd1lBaU81TlJx?=
 =?utf-8?Q?EYMaye?=
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: 20 Jun 2025 21:43:20.4307
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f10dddd1-7ba3-491b-0d48-08ddb0437996
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:
	SJ1PEPF00002321.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB5720

On 2025-06-19 07:38, Juergen Gross wrote:
> Hide start_info_ptr via CONFIG_PARAVIRT in order to avoid accesses to
> it form not PV specific code.
> 
> Signed-off-by: Juergen Gross 

Reviewed-by: Jason Andryuk 


From xen-devel-bounces@lists.xenproject.org Sat Jun 21 00:42:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jun 2025 00:42:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021373.1397347 (Exim 4.92)
	(envelope-from )
	id 1uSmJ2-0003kb-2m; Sat, 21 Jun 2025 00:42:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021373.1397347; Sat, 21 Jun 2025 00: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 1uSmJ1-0003kU-WF; Sat, 21 Jun 2025 00:42:04 +0000
Received: by outflank-mailman (input) for mailman id 1021373;
 Sat, 21 Jun 2025 00:42: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 1uSmJ1-0003kO-B1
 for xen-devel@lists.xenproject.org; Sat, 21 Jun 2025 00:42:03 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8b06a486-4e38-11f0-a30e-13f23c93f187;
 Sat, 21 Jun 2025 02:42:01 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 40E586155F;
 Sat, 21 Jun 2025 00:42:00 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 79E64C4CEE3;
 Sat, 21 Jun 2025 00:41:58 +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: 8b06a486-4e38-11f0-a30e-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750466519;
	bh=57mlEAzT3c33HgDwikKJAIlCcWjSiKIow6H8UX7mSUE=;
	h=Date:From:To:cc:Subject:From;
	b=Zy+DgxhRlN6KsZBlwjBczuspMa/Mm/dC5YF5XdFoNokWTy4AD9lOFLy9z5bvOQaol
	 SUf2ayB4Qc+jPavSOLseckYsrVRp4sYpV+aoZsgs0FFEHv15dkKxQPvZJDtQ+wNxDC
	 U1uH7mYpsKgavKW4M2ndaEkVxKnddV2567Se/sY+NCHCDgBRjQR5EpGZx2TgLeEGcQ
	 gXhbd0kZl8fJ8eupAm6tKwlsM7AHEOWV20Hf+U3OJ4mI9dXJf1O+WGyvzuZKGhKxVV
	 SaTPzklTyujesIqnrBG0N4eX4/v1LHVJySh//HYXtGEKQOVVGrFlUP6UyIdYBbJ6fW
	 0MHzsCn3bAilg==
Date: Fri, 20 Jun 2025 17:41:55 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: xen-devel@lists.xenproject.org
cc: sstabellini@kernel.org, jason.andryuk@amd.com, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    Andrew Cooper , 
    Anthony PERARD , 
    Jan Beulich , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , ayankuma@amd.com
Subject: hardware domain and control domain separation
Message-ID: 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

Hi all,

Regarding hardware domain and control domain separation, Ayan sent to
xen-devel an architecture specification (a design document) that I wrote
previously about the topic. This is written as safety document so it is
using a language and structure specific for that. However, it contains
much of the explanation needed on the topic:

https://lore.kernel.org/xen-devel/20250304183115.2509666-1-ayan.kumar.halder@amd.com/

If you take Virtio and PV drivers aside, the conceptual model is very
simple. I suggest we start from there, also because deployments without
Virtio/PV drivers are indeed possible. Often in mixed-criticality
environments device sharing is absent or very limited.

When we bring Virtio and PV drivers into the picture, things get more
complex. One simple mental model is that they are only allowed between
Unsafe VMs, because we cannot guarantee that neither the protocols nor
the widely adopted implementations are entirely free from interference.
So, Virtio (and PV drivers) between Unsafe VMs are OK, but Safe VMs
should be left alone.

There are lots of extra details in the document about the problems of
freedom from interference and Virtio. I wrote those details to explain why
Virtio between Safe and Unsafe VMs cannot be expected to work without
modifications today (people will ask for this, this way we'll have the
answers ready). I also wrote those details so that if someone wanted to
do an analysis on this topic and potentially deploy an entirely written
from scratch Virtio driver-protocol-backend implementation, they would
have a starting point for their investigation.

Cheers,

Stefano


From xen-devel-bounces@lists.xenproject.org Sat Jun 21 00:47:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jun 2025 00:47:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021381.1397358 (Exim 4.92)
	(envelope-from )
	id 1uSmOG-0004Jw-ND; Sat, 21 Jun 2025 00:47:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021381.1397358; Sat, 21 Jun 2025 00:47:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSmOG-0004Jp-J7; Sat, 21 Jun 2025 00:47:28 +0000
Received: by outflank-mailman (input) for mailman id 1021381;
 Sat, 21 Jun 2025 00:47: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 1uSmOF-0004Jj-96
 for xen-devel@lists.xenproject.org; Sat, 21 Jun 2025 00:47:27 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4bdfcbc7-4e39-11f0-a30e-13f23c93f187;
 Sat, 21 Jun 2025 02:47:25 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id C827743E3D;
 Sat, 21 Jun 2025 00:47:23 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id DD2ABC4CEE3;
 Sat, 21 Jun 2025 00:47: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: 4bdfcbc7-4e39-11f0-a30e-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750466843;
	bh=eNyfj4HcVVfJwlfA5ckj0FD7tOgstwB1mZA2xwOFq+I=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=XCWr4CH06RlWP2Iy0mCZ2GZQT+IUQrne3JcBC4OKXA06Ph7rSw/0iooGL5Fy3irfz
	 VWdnYNA3FEb0hGBAxedFw1glpwCzTaXOypU+8TNuSExMXb3IXgrbcIOdONQVIkxEXD
	 Oren2ElSPedS6Q4FanIqJoi2+tZCBU8iIw6xYaFSh4ovMpbFbMsXaSKktWhsN8QrU4
	 KVFhouEaLaryLgk+lYL1l3w47XDsO7Zet87wHzlTQa3qczDSavzSKvp/bhl6N3sOEp
	 E7e4XfnBmYUpLJbhet8Kp2CxitJG3ukX6QP6vsWBCtKLJId5zqLYnWXJEkEgY4Mjpp
	 rWG0DMj+9jv2Q==
Date: Fri, 20 Jun 2025 17:47:22 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel 
Subject: Re: [PATCH v3] xen/dt: Remove loop in dt_read_number()
In-Reply-To: <20250619114206.1014-1-agarciav@amd.com>
Message-ID: 
References: <20250619114206.1014-1-agarciav@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Thu, 19 Jun 2025, Alejandro Vallejo wrote:
> The DT spec declares only two number types for a property: u32 and u64,
> as per Table 2.3 in Section 2.2.4. Remove unbounded loop and replace
> with a switch statement. Default to a size of 1 cell in the nonsensical
> size case, with a warning printed on the Xen console.
> 
> Suggested-by: Daniel P. Smith" 
> Signed-off-by: Alejandro Vallejo 

Reviewed-by: Stefano Stabellini 


> ---
> If there's any #address-size > 2 out there at least we'll know in debug builds.
> It's not like this function can cope with them either way.
> 
> I haven't tested things past CI.
> 
> pipeline: https://gitlab.com/xen-project/people/agvallejo/xen/-/pipelines/1876848415
> 
> v3:
>   * s/WARNING/ERR
>   * //-style comment to /**/-style comment
>   * break after ASSERT_UNREACHABLE() to please MISRA
> ---
>  xen/include/xen/device_tree.h | 18 +++++++++++++++---
>  1 file changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> index 75017e4266..d2de7c3a13 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -261,10 +261,22 @@ void intc_dt_preinit(void);
>  /* Helper to read a big number; size is in cells (not bytes) */
>  static inline u64 dt_read_number(const __be32 *cell, int size)
>  {
> -    u64 r = 0;
> +    u64 r = be32_to_cpu(*cell);
> +
> +    switch ( size )
> +    {
> +    case 1:
> +        break;
> +    case 2:
> +        r = (r << 32) | be32_to_cpu(cell[1]);
> +        break;
> +    default:
> +        /* Nonsensical size. default to 1 */
> +        printk(XENLOG_ERR "dt_read_number(,%d) bad size\n", size);
> +        ASSERT_UNREACHABLE();
> +        break;
> +    };
>  
> -    while ( size-- )
> -        r = (r << 32) | be32_to_cpu(*(cell++));
>      return r;
>  }
>  
> 
> base-commit: 22650d6054625be10172fe0c78b9cadd1a39bd63
> -- 
> 2.43.0
> 


From xen-devel-bounces@lists.xenproject.org Sat Jun 21 00:53:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jun 2025 00:53:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021388.1397367 (Exim 4.92)
	(envelope-from )
	id 1uSmTf-0005x3-86; Sat, 21 Jun 2025 00:53:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021388.1397367; Sat, 21 Jun 2025 00:53:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSmTf-0005ww-54; Sat, 21 Jun 2025 00:53:03 +0000
Received: by outflank-mailman (input) for mailman id 1021388;
 Sat, 21 Jun 2025 00:53: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 1uSmTd-0005wq-Iw
 for xen-devel@lists.xenproject.org; Sat, 21 Jun 2025 00:53:01 +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 131ca110-4e3a-11f0-a30e-13f23c93f187;
 Sat, 21 Jun 2025 02:52:59 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 7A2DE5C48FD;
 Sat, 21 Jun 2025 00:50:41 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 36CAEC4CEE3;
 Sat, 21 Jun 2025 00:52:56 +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: 131ca110-4e3a-11f0-a30e-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750467177;
	bh=/RT3Wy8NWkW1jUYQKwjPaq+W+PxF5lgGKEs1nu7uYXE=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=bSDh/MG7NlUNQrnghjYaTdVSO/hxEcXJfZESQDP6Dw4fcNvbAyYavmEJa4YFa6zxL
	 NrOv2uTzj5wvvWSe6/6saSHRGhbZqxUHYjTFMZkQUB1p4iB4+16DlSSf7Flm93MPCf
	 ij+cxu3+eqBWvvUzde2kONarSBpqVTTf7W8iMn1luuCfTzvp/uWPXkdtlvpcCTQjYj
	 l3GpnMxRHWwSBmcvdlTPGEX+qfnFZx12zqPBcyr01k7NJ1VvEami0QI4U0LVnh4UnQ
	 cFDgxdLdrc6b4X9LoP/6/LfpigX+QRj2WFT5WbEoyEUXXfZ1mX6E0tp0HBrlELuW6O
	 jDsRxytdHHvJQ==
Date: Fri, 20 Jun 2025 17:52:54 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Stefano Stabellini , dmkhn@proton.me, 
    andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org, 
    michal.orzel@amd.com, roger.pau@citrix.com, dmukhin@ford.com, 
    xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 2/2] xen/console: unify printout behavior for UART
 emulators
In-Reply-To: <15db8155-3d3d-41e9-92be-957067a34e5f@suse.com>
Message-ID: 
References: <20250606201102.2414022-1-dmukhin@ford.com> <20250606201102.2414022-3-dmukhin@ford.com>   
    <2f726960-4bdc-4996-b204-722c0253e2ab@suse.com>
  <15db8155-3d3d-41e9-92be-957067a34e5f@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 20 Jun 2025, Jan Beulich wrote:
> On 19.06.2025 02:45, Stefano Stabellini wrote:
> > On Wed, 18 Jun 2025, Jan Beulich wrote:
> >> On 18.06.2025 02:39, Stefano Stabellini wrote:
> >>> On Thu, 12 Jun 2025, Jan Beulich wrote:
> >>>> On 11.06.2025 21:07, Stefano Stabellini wrote:
> >>>>> On Wed, 11 Jun 2025, Jan Beulich wrote:
> >>>>>> On 11.06.2025 02:07, dmkhn@proton.me wrote:
> >>>>>>> On Tue, Jun 10, 2025 at 10:21:40AM +0200, Jan Beulich wrote:
> >>>>>>>> On 06.06.2025 22:11, dmkhn@proton.me wrote:
> >>>>>>>>> From: Denis Mukhin 
> >>>>>>>>>
> >>>>>>>>> If virtual UART from domain X prints on the physical console, the behavior is
> >>>>>>>>> updated to (see [1]):
> >>>>>>>>> - console focus in domain X: do not prefix messages;
> >>>>>>>>> - no console focus in domain X: prefix all messages with "(dX)".
> >>>>>>>>
> >>>>>>>> While, as indicated (much) earlier, I can see why omitting the prefix
> >>>>>>>> may make sense for the domain having input focus, ...
> >>>>>>>>
> >>>>>>>>> --- a/xen/drivers/char/console.c
> >>>>>>>>> +++ b/xen/drivers/char/console.c
> >>>>>>>>> @@ -740,7 +740,17 @@ 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 */
> >>>>>>>>> +            char prefix[16] = "";
> >>>>>>>>> +            struct domain *consd;
> >>>>>>>>> +
> >>>>>>>>> +            consd = console_get_domain();
> >>>>>>>>> +            if ( consd != cd )
> >>>>>>>>> +                snprintf(prefix, sizeof(prefix), "(d%d) ", cd->domain_id);
> >>>>>>>>> +            console_put_domain(consd);
> >>>>>>>>> +
> >>>>>>>>>              nrspin_lock_irq(&console_lock);
> >>>>>>>>> +            if ( prefix[0] != '\0' )
> >>>>>>>>> +                console_send(prefix, strlen(prefix), flags);
> >>>>>>>>>              console_send(kbuf, kcount, flags);
> >>>>>>>>>              nrspin_unlock_irq(&console_lock);
> >>>>>>>>>          }
> >>>>>>>>
> >>>>>>>> ... this, aiui, is a behavioral change for the non-dom0less case, where
> >>>>>>>> Dom0 output will suddenly also gain the prefix. Which I don't think is
> >>>>>>>> wanted: Switching focus between Xen and Dom0 should remain unaffected
> >>>>>>>> in this regard.
> >>>>>>>
> >>>>>>> This change ensures that dom0 traces aren't mixed with domU traces when domU
> >>>>>>> has input focus, or with Xen traces when the administrator is in the diagnostic
> >>>>>>> console.
> >>>>>>
> >>>>>> That's what the description also tries to describe, yet I still regard it as
> >>>>>> a behavioral regression in (at least) the described scenario. The hardware
> >>>>>> domain presently not having (d0) prefixed to its output is deliberate imo,
> >>>>>> not accidental.
> >>>>>
> >>>>> If we only consider the classic dom0 and dom0less usage models, then
> >>>>> what you wrote makes perfect sense. In the classic dom0 case, it is best
> >>>>> for dom0 to have no prefix, which is the current behavior.
> >>>>>
> >>>>> However, things become more complex with dom0less. As we have discussed
> >>>>> previously, it has already become desirable on both ARM and x86 to align
> >>>>> on the same behavior. During our last discussion, the preference was to
> >>>>> add a '(d0)' prefix to clearly differentiate output from dom0 and other
> >>>>> domains.
> >>>>>
> >>>>> Up to now, we could easily detect the two different cases depending on
> >>>>> the boot configuration. The problem arises with Denis' patches, which
> >>>>> add the ability for dynamically created guests via `xl` to access an
> >>>>> emulated NS16550 UART that prints to the console. Because these guests
> >>>>> are created dynamically, it is not clear how we are going to handle
> >>>>> this case.
> >>>>
> >>>> Why would this be not clear? We already prefix their output with "(d)"
> >>>> when going the traditional way. The same would then apply to output
> >>>> coming through the emulated UART.
> >>>>
> >>>>> If we follow the dom0less preference, then we would need a '(d0)' prefix
> >>>>> for dom0. If we follow the classic dom0 model, then dom0 would remain
> >>>>> without a prefix, and the new domUs would have a prefix. This would
> >>>>> cause an inconsistency. However, this is what we have today on ARM with
> >>>>> dom0less.
> >>>>>
> >>>>> If Jan feels strongly that we should retain no prefix for the classic
> >>>>> dom0 case, which is understandable, then I believe the best course of
> >>>>> action would be to change our stance on dom0less on both ARM and x86 and
> >>>>> also use no prefix for dom0 in the dom0less case (which is the current
> >>>>> state on ARM).
> >>>>
> >>>> Leaving aside that "dom0 in the dom0less" ought to really be not-a-thing,
> >>>> I disagree. Present behavior of not prefixing the domain's output which
> >>>> has input focus continues to make sense. That requires Dom0 to have a
> >>>> prefix whenever it doesn't have input focus.
> >>>
> >>> If I understood correctly I like your proposal. Let me rephrase it to
> >>> make sure we are aligned. You are suggesting that:
> >>>
> >>> - domains without input focus will print with a (d) prefix
> >>> - the domain with input focus will print without a (d) prefix
> >>> - this applies to both DomUs and Dom0
> >>
> >> Except in the non-dom0less case, at least up and until there's at least
> >> one other domain. I.e. I'd like to keep Dom0 boot output as it is today,
> >> regardless of the presence of e.g. "conswitch=".
> > 
> > In the non-dom0less case, since dom0 has focus, it would naturally be
> > without (d) prefix. Unless the user passes "conswitch=". Honestly, I
> > wouldn't special-case conswitch= that way and would prefer keep things
> > simple and consistent without corner cases. I don't think conswitch= is
> > so widely used that it is worth the complexity to special-case it.
> 
> Widely used or not - _I_ use it all the time in debug configs where serial
> is available.

Fair enough and your usage is really important for the project. At the
same time you know exactly what's going on so you wouldn't be confused
by the presence or absence of a (d0) prefix.

The main issue is when less familiar users try Xen, or less familiar
developers go through the Xen source code to learn from it.

I would optimize this choice to make it simpler for users and to make
the code simpler. Your use-case is really important as well, but I would
trust you to understand what's going on either way, with or without the
(d0) prefix.

I won't insist though.

Cheers,

Stefano


From xen-devel-bounces@lists.xenproject.org Sat Jun 21 01:06:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jun 2025 01:06:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021395.1397376 (Exim 4.92)
	(envelope-from )
	id 1uSmgT-00070t-AL; Sat, 21 Jun 2025 01:06:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021395.1397376; Sat, 21 Jun 2025 01:06: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 1uSmgT-00070m-7i; Sat, 21 Jun 2025 01:06:17 +0000
Received: by outflank-mailman (input) for mailman id 1021395;
 Sat, 21 Jun 2025 01:06: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 1uSmgR-00070e-DJ
 for xen-devel@lists.xenproject.org; Sat, 21 Jun 2025 01:06:15 +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 e73fe4b8-4e3b-11f0-b894-0df219b8e170;
 Sat, 21 Jun 2025 03:06:04 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id F27AB5C56EA;
 Sat, 21 Jun 2025 01:03:46 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id D511EC4CEE3;
 Sat, 21 Jun 2025 01:06:01 +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: e73fe4b8-4e3b-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750467962;
	bh=XMhJwcMpOfwDdKs8fPV20xLIC4S4uNzOdGEzpMeBmTE=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=iBC4VmT5jTVH+kKpkrw09XyCcflWewCaMhUndzErpEoY6ZsPzeM9yfpnODDhuw/Yh
	 6kRsniFGdqecPMhgGSt+QhLmOQkR5+FfCbUB5QcbNv5aYDA8+GR9w46l9HvG4SecGO
	 9JRy0Ykn6PjuuVDZRc9FZ2SXPQ0ok2679iORtJoz4Mv8O/eOauLx32+z+4yIb8otji
	 grmo4aUJe3S8uyFDM+owgfMK0EMj9I2Ulu1MRGbt0xPZ5eamiXeKiFZPoD8ml3rCUe
	 lz7TngUdvta+YKK3+SJMCMEIoG7l3y4o2eAZ1l8Uty1+g4/RF6t2JZSwS9VjHxL1k0
	 ILjV3ZRczJKJA==
Date: Fri, 20 Jun 2025 18:06:00 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
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 
Subject: Re: [PATCH v4 01/12] CODING_STYLE: Custom type names must be
 snake-cased by word.
In-Reply-To: <20250620182859.23378-2-agarciav@amd.com>
Message-ID: 
References: <20250620182859.23378-1-agarciav@amd.com> <20250620182859.23378-2-agarciav@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 20 Jun 2025, Alejandro Vallejo wrote:
> There's the unwritten convention in x86 of splitting type names using
> underscores. Add such convention to the CODINNG_STYLE to make it
> common and less unwritten.
> 
> Signed-off-by: Alejandro Vallejo 

Acked-by: Stefano Stabellini 

> ---
> v4:
>   * Move new paragraph into a new "Identifiers" section
> ---
>  CODING_STYLE | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/CODING_STYLE b/CODING_STYLE
> index 5644f1697f..7bf3848444 100644
> --- a/CODING_STYLE
> +++ b/CODING_STYLE
> @@ -113,6 +113,12 @@ Braces should be omitted for blocks with a single statement. e.g.,
>  if ( condition )
>      single_statement();
>  
> +Identifiers
> +-----------
> +
> +When giving names to identifiers (variables, functions, constants...), separate
> +words using underscores (for example, use "my_foo" instead of "myfoo").
> +
>  Types
>  -----
>  
> -- 
> 2.43.0
> 


From xen-devel-bounces@lists.xenproject.org Sat Jun 21 01:12:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jun 2025 01:12:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021406.1397392 (Exim 4.92)
	(envelope-from )
	id 1uSmmn-0000Pr-57; Sat, 21 Jun 2025 01:12:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021406.1397392; Sat, 21 Jun 2025 01:12: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 1uSmmn-0000Pk-1D; Sat, 21 Jun 2025 01:12:49 +0000
Received: by outflank-mailman (input) for mailman id 1021406;
 Sat, 21 Jun 2025 01:12: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 1uSmml-0000PY-Pv
 for xen-devel@lists.xenproject.org; Sat, 21 Jun 2025 01:12: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 d1b41ac5-4e3c-11f0-a30e-13f23c93f187;
 Sat, 21 Jun 2025 03:12:38 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 847DA5C54B1;
 Sat, 21 Jun 2025 01:10:20 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 26708C4CEE3;
 Sat, 21 Jun 2025 01:12:35 +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: d1b41ac5-4e3c-11f0-a30e-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750468356;
	bh=F+V4eG2IqR+REYm7zD75FLb9J+diHbCF/rbj8Ioxmfc=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=Kw3CxhjKvqvKnOB5VpzuNbgnnhMqayUtjAQtQxESOe/HPbBvB4qdBIOl9AiKsLvNu
	 fSdx0c07K1uh9R5+gGf9CFitUoTruSR/QFVy/z4wxWP8QitGEvfRBEfmAtVz+Dh78R
	 V9jwl9GXiHywIQLixROL+aw8YRmqmcgpzV0CsBRBpMXSb51UTAQCOVCLACDn68t5z1
	 6mnXwETNhJVhz91N6j4gj1KT1sjO/klpPMkSo3Sh3/jWYrdkkSmlXKBYvWKhf9YIdc
	 clyjDAQx8XJWWFMA/V+qBV51V3XCEtkkAXWix84rUA85PishWPyPjgObiJ/fnLQxvK
	 dl4I/ZRrZhL+Q==
Date: Fri, 20 Jun 2025 18:12:34 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: xen-devel@lists.xenproject.org, Jan Beulich , 
    Andrew Cooper , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    "Daniel P. Smith" 
Subject: Re: [PATCH v4 03/12] x86: Replace arch-specific boot_module with
 common one
In-Reply-To: <20250620182859.23378-4-agarciav@amd.com>
Message-ID: 
References: <20250620182859.23378-1-agarciav@amd.com> <20250620182859.23378-4-agarciav@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 20 Jun 2025, Alejandro Vallejo wrote:
> These types resemble each other very closely in layout and intent,
> and with "struct boot_module" already in common code it makes perfect
> sense to merge them. In order to do so, add an arch-specific area for
> x86-specific tidbits, and rename identical fields with conflicting
> names.
> 
> No functional change intended.
> 
> Signed-off-by: Alejandro Vallejo 

Reviewed-by: Stefano Stabellini 



From xen-devel-bounces@lists.xenproject.org Sat Jun 21 01:20:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jun 2025 01:20:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021412.1397401 (Exim 4.92)
	(envelope-from )
	id 1uSmua-00026Z-R3; Sat, 21 Jun 2025 01:20:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021412.1397401; Sat, 21 Jun 2025 01: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 1uSmua-00026S-OB; Sat, 21 Jun 2025 01:20:52 +0000
Received: by outflank-mailman (input) for mailman id 1021412;
 Sat, 21 Jun 2025 01:20: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 1uSmuZ-00026M-P9
 for xen-devel@lists.xenproject.org; Sat, 21 Jun 2025 01:20: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 f675163d-4e3d-11f0-a30e-13f23c93f187;
 Sat, 21 Jun 2025 03:20:49 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 963E35C697A;
 Sat, 21 Jun 2025 01:18:31 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id F2F00C4CEE3;
 Sat, 21 Jun 2025 01:20:45 +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: f675163d-4e3d-11f0-a30e-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750468847;
	bh=N/nbsujw+3kQq1xM04ZJE47bDz1RNUPYc9dI3AIt14U=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=QvzZjQULjoaBLUKOkvCJEAtbf6BfCBZWVDOsOc16eDmBsMGf2LAChBSxXUz2ZTm0x
	 y2Z0l0n9maY5FM0FKN19pKjFL7fnU0Jxo3iAUTIXqejIWwWE7cWk+bbVj7uGtX2aia
	 AoYiq9i6AceeU9ZmpJNY9n7++gAe0RBvpnGHuwxxGNFjRBAaarYpDsWrveX+wzxhv2
	 jRQW6tuUTeW0u0Dt8XlVVCn3yQBsexK7RXbXkpHR0TkNHkWCKSGciTS3hI1yduot2B
	 5mXDCjgORbYhjayaLa/LHznXMJRlCwd8mXJ/Io3fvKWc4hFW/5IroCDb7XbjKPdQb7
	 Dn20d6INGdtYw==
Date: Fri, 20 Jun 2025 18:20:45 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: xen-devel@lists.xenproject.org, 
    Alistair Francis , 
    Bob Eshleman , 
    Connor Davis , 
    Oleksii Kurochko , 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , Dario Faggioli , 
    Juergen Gross , George Dunlap 
Subject: Re: [PATCH v4 06/12] xen/dt: Move bootfdt functions to
 xen/bootfdt.h
In-Reply-To: <20250620182859.23378-7-agarciav@amd.com>
Message-ID: 
References: <20250620182859.23378-1-agarciav@amd.com> <20250620182859.23378-7-agarciav@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 20 Jun 2025, Alejandro Vallejo wrote:
> Part of an unpicking process to extract bootfdt contents independent of bootinfo
> to a separate file for x86 to take.
> 
> Move functions required for early FDT parsing from device_tree.h and arm's
> setup.h onto bootfdt.h
> 
> Declaration motion only. Not a functional change.
> 
> Signed-off-by: Alejandro Vallejo 
> ---
> v4:
>   * Remove bootfdt.h include from device_tree.h
>     (move dt_read_paddr and fix up
>      static-evtchn.c +
>      device-tree.c +
>      boot-cpupool.c +
>      riscv/smpboot.c +
>      riscv/cpufeature.c)
> ---
>  xen/arch/riscv/cpufeature.c            |  1 +
>  xen/arch/riscv/smpboot.c               |  1 +
>  xen/common/device-tree/device-tree.c   |  1 +
>  xen/common/device-tree/static-evtchn.c |  1 +
>  xen/common/sched/boot-cpupool.c        |  1 +
>  xen/include/xen/bootfdt.h              | 91 ++++++++++++++++++++++++++
>  xen/include/xen/device_tree.h          | 66 -------------------
>  7 files changed, 96 insertions(+), 66 deletions(-)
> 
> diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c
> index b7d5ec6580..b846a106a3 100644
> --- a/xen/arch/riscv/cpufeature.c
> +++ b/xen/arch/riscv/cpufeature.c
> @@ -8,6 +8,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/xen/arch/riscv/smpboot.c b/xen/arch/riscv/smpboot.c
> index 470f6d1311..3b8bf98e20 100644
> --- a/xen/arch/riscv/smpboot.c
> +++ b/xen/arch/riscv/smpboot.c
> @@ -1,3 +1,4 @@
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/xen/common/device-tree/device-tree.c b/xen/common/device-tree/device-tree.c
> index 886e6c7712..725ff71646 100644
> --- a/xen/common/device-tree/device-tree.c
> +++ b/xen/common/device-tree/device-tree.c
> @@ -7,6 +7,7 @@
>   * benh@kernel.crashing.org
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/xen/common/device-tree/static-evtchn.c b/xen/common/device-tree/static-evtchn.c
> index 8b82e6b3d8..88342b44a1 100644
> --- a/xen/common/device-tree/static-evtchn.c
> +++ b/xen/common/device-tree/static-evtchn.c
> @@ -1,5 +1,6 @@
>  /* SPDX-License-Identifier: GPL-2.0-only */
>  
> +#include 
>  #include 
>  #include 
>  
> diff --git a/xen/common/sched/boot-cpupool.c b/xen/common/sched/boot-cpupool.c
> index 641f3495cb..03be73efdd 100644
> --- a/xen/common/sched/boot-cpupool.c
> +++ b/xen/common/sched/boot-cpupool.c
> @@ -7,6 +7,7 @@
>   * Copyright (C) 2022 Arm Ltd.
>   */
>  
> +#include 
>  #include 
>  #include 
>  
> diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
> index 8ea52290b7..0846317f30 100644
> --- a/xen/include/xen/bootfdt.h
> +++ b/xen/include/xen/bootfdt.h
> @@ -2,8 +2,11 @@
>  #ifndef XEN_BOOTFDT_H
>  #define XEN_BOOTFDT_H
>  
> +#include 
> +#include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -16,8 +19,80 @@
>  #define NR_MEM_BANKS 256
>  #define NR_SHMEM_BANKS 32
>  
> +/* Default #address and #size cells */
> +#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
> +#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
> +
>  #define MAX_MODULES 32 /* Current maximum useful modules */
>  
> +#define DEVICE_TREE_MAX_DEPTH 16
> +
> +/* Helper to read a big number; size is in cells (not bytes) */
> +static inline u64 dt_read_number(const __be32 *cell, int size)
> +{
> +    u64 r = 0;
> +
> +    while ( size-- )
> +        r = (r << 32) | be32_to_cpu(*(cell++));
> +    return r;
> +}
> +
> +/* Wrapper for dt_read_number() to return paddr_t (instead of uint64_t) */
> +static inline paddr_t dt_read_paddr(const __be32 *cell, int size)
> +{
> +    uint64_t dt_r;
> +    paddr_t r;
> +
> +    /*
> +     * dt_read_number will return uint64_t whereas paddr_t may not be 64-bit.
> +     * Thus, there is an implicit cast from uint64_t to paddr_t.
> +     */
> +    dt_r = dt_read_number(cell, size);
> +
> +    if ( dt_r != (paddr_t)dt_r )
> +    {
> +        printk("Physical address greater than max width supported\n");
> +        WARN();
> +    }
> +
> +    /*
> +     * Xen will truncate the address/size if it is greater than the maximum
> +     * supported width and it will give an appropriate warning.
> +     */
> +    r = dt_r;
> +
> +    return r;
> +}
> +
> +static inline u64 dt_next_cell(int s, const __be32 **cellp)
> +{
> +    const __be32 *p = *cellp;
> +
> +    *cellp = p + s;
> +    return dt_read_number(p, s);
> +}
> +
> +typedef int (*device_tree_node_func)(const void *fdt,
> +                                     int node, const char *name, int depth,
> +                                     u32 address_cells, u32 size_cells,
> +                                     void *data);
> +
> +/**
> + * device_tree_for_each_node - iterate over all device tree sub-nodes
> + * @fdt: flat device tree.
> + * @node: parent node to start the search from
> + * @func: function to call for each sub-node.
> + * @data: data to pass to @func.
> + *
> + * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
> + *
> + * Returns 0 if all nodes were iterated over successfully.  If @func
> + * returns a value different from 0, that value is returned immediately.
> + */
> +int device_tree_for_each_node(const void *fdt, int node,
> +                              device_tree_node_func func,
> +                              void *data);
> +
>  typedef enum {
>      BOOTMOD_XEN,
>      BOOTMOD_FDT,
> @@ -260,4 +335,20 @@ static inline struct membanks *membanks_xzalloc(unsigned int nr,
>      return banks;
>  }
>  
> +/*
> + * Interpret the property `prop_name` of `node` as a u32.
> + *
> + * Returns the property value on success; otherwise returns `dflt`.
> + */
> +u32 device_tree_get_u32(const void *fdt, int node,
> +                        const char *prop_name, u32 dflt);
> +
> +/*
> + * Interpret the property `prop_name` of `node` as a "reg".
> + *
> + * Returns outputs in `start` and `size`.
> + */
> +void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
> +                         uint32_t size_cells, paddr_t *start, paddr_t *size);
> +
>  #endif /* XEN_BOOTFDT_H */
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> index 75017e4266..b6d16756fc 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -22,8 +22,6 @@
>  #include 
>  #include 
>  
> -#define DEVICE_TREE_MAX_DEPTH 16
> -
>  /*
>   * Struct used for matching a device
>   */
> @@ -164,17 +162,8 @@ struct dt_raw_irq {
>      u32 specifier[DT_MAX_IRQ_SPEC];
>  };
>  
> -typedef int (*device_tree_node_func)(const void *fdt,
> -                                     int node, const char *name, int depth,
> -                                     u32 address_cells, u32 size_cells,
> -                                     void *data);
> -
>  extern const void *device_tree_flattened;
>  
> -int device_tree_for_each_node(const void *fdt, int node,
> -                              device_tree_node_func func,
> -                              void *data);
> -
>  /**
>   * dt_unflatten_host_device_tree - Unflatten the host device tree
>   *
> @@ -245,10 +234,6 @@ void intc_dt_preinit(void);
>  #define dt_node_cmp(s1, s2) strcasecmp((s1), (s2))
>  #define dt_compat_cmp(s1, s2) strcasecmp((s1), (s2))
>  
> -/* Default #address and #size cells */
> -#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
> -#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
> -
>  #define dt_for_each_property_node(dn, pp)                   \
>      for ( pp = (dn)->properties; (pp) != NULL; pp = (pp)->next )
>  
> @@ -258,43 +243,6 @@ void intc_dt_preinit(void);
>  #define dt_for_each_child_node(dt, dn)                      \
>      for ( dn = (dt)->child; (dn) != NULL; dn = (dn)->sibling )
>  
> -/* Helper to read a big number; size is in cells (not bytes) */
> -static inline u64 dt_read_number(const __be32 *cell, int size)
> -{
> -    u64 r = 0;
> -
> -    while ( size-- )
> -        r = (r << 32) | be32_to_cpu(*(cell++));
> -    return r;
> -}

I committed your other patch so this doesn't apply any longer.

Other than that:

Reviewed-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Sat Jun 21 01:25:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jun 2025 01:25:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021419.1397411 (Exim 4.92)
	(envelope-from )
	id 1uSmyu-0002lK-B1; Sat, 21 Jun 2025 01:25:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021419.1397411; Sat, 21 Jun 2025 01:25: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 1uSmyu-0002lD-7c; Sat, 21 Jun 2025 01:25:20 +0000
Received: by outflank-mailman (input) for mailman id 1021419;
 Sat, 21 Jun 2025 01:25: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 1uSmys-0002l7-T4
 for xen-devel@lists.xenproject.org; Sat, 21 Jun 2025 01:25:18 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 95b8b40c-4e3e-11f0-b894-0df219b8e170;
 Sat, 21 Jun 2025 03:25:16 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 0CABC4A30D;
 Sat, 21 Jun 2025 01:25:15 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 82C93C4CEE3;
 Sat, 21 Jun 2025 01:25: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: 95b8b40c-4e3e-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750469114;
	bh=dbLRfmy/B/+nlOeWoqyXelG/0Ds1TdixPIfOFAx/GgE=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=QF1aF2iAy0RKWnB59E6zlF71aFfY6iSyLcPa7uQge+gZAfwLQj5hRZHLl2JCmZrTx
	 5JtRbfFISGRWKiSXyGyJzGcZ3PaO0PFOUpXtdQ5CoZTkZsOJHcJYWs3X5lcSk5HkVw
	 DaqywLFvca2vaJ0Tl298GdBTjZ+WYv6IeVtjqjfiMaDli3xTmzjDzLeWnli2S763ep
	 IeaQLufqVsjtxrlM2qPrcyWAgdcy1OyxXo6DwmidulQ+0k/U1ShrUtx2wZZsFHH1IR
	 9/fpWrUR8qkiPrGRjsVGPc+YNTJTjnZ3wu2hRMw9AFyb4+ndYYAk70CW424rcvkeGy
	 CKu5Vef+1n3Bw==
Date: Fri, 20 Jun 2025 18:25:10 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
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 , 
    Bertrand Marquis , 
    Volodymyr Babchuk , 
    Shawn Anastasio , 
    Alistair Francis , 
    Bob Eshleman , 
    Connor Davis , 
    Oleksii Kurochko , 
    "Daniel P. Smith" , 
    =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , 
    Dario Faggioli , Juergen Gross , 
    George Dunlap 
Subject: Re: [PATCH v4 10/12] xen: Rename CONFIG_HAS_DEVICE_TREE to
 CONFIG_HAS_DEVICE_TREE_DISCOVERY
In-Reply-To: <20250620182859.23378-11-agarciav@amd.com>
Message-ID: 
References: <20250620182859.23378-1-agarciav@amd.com> <20250620182859.23378-11-agarciav@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 20 Jun 2025, Alejandro Vallejo wrote:
> Moving forward the idea is for there to be:
>   1. Basic DT support: used by dom0less/hyperlaunch.
>   2. Full DT support: used for device discovery and HW setup.
> 
> Rename HAS_DEVICE_TREE to HAS_DEVICE_TREE_DISCOVERY to describe (2), while
> DOM0LESS_BOOT is left to describe (1).
> 
> Signed-off-by: Alejandro Vallejo 

This patch is a plain HAS_DEVICE_TREE -> HAS_DEVICE_TREE_DISCOVERY
search and replace. It looks consistent and correct.

I am not sure others will be happy with the name DOM0LESS_BOOT for (1)
but if not the part of the commit message mentioning DOM0LESS_BOOT
should be changed. Aside from that:

Reviewed-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Sat Jun 21 01:27:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jun 2025 01:27:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021427.1397421 (Exim 4.92)
	(envelope-from )
	id 1uSn1B-0003He-Mp; Sat, 21 Jun 2025 01:27:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021427.1397421; Sat, 21 Jun 2025 01:27: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 1uSn1B-0003HX-J0; Sat, 21 Jun 2025 01:27:41 +0000
Received: by outflank-mailman (input) for mailman id 1021427;
 Sat, 21 Jun 2025 01:27: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 1uSn1A-0003HR-8O
 for xen-devel@lists.xenproject.org; Sat, 21 Jun 2025 01:27:40 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ea4f0060-4e3e-11f0-b894-0df219b8e170;
 Sat, 21 Jun 2025 03:27:38 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 213266155F;
 Sat, 21 Jun 2025 01:27:37 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id A2EA4C4CEE3;
 Sat, 21 Jun 2025 01:27:35 +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: ea4f0060-4e3e-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750469256;
	bh=qz3aKe3XCaGcdU/ia8Vj+Al/SgLZ9sMMG88japCP4zs=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=EMv2npJbf4NTxJ3oEnhm4j8wqBCIQ851zqLewDPv6rbwqCE95/hRjnfvd22WBGJ/4
	 ScQu1hxV3VSFmoJCA/YKw1HkKRzcGXQeIXr49ax21qZjBv4NyXHQkxO1CRqqSihGBS
	 zXPHOacuLVhWVqS5ITCsIua6IlCr+NB4ICDC2F6RImqH2YAeAFqt2cyCT3LexURT+q
	 DCsO9brQ+7VTwojyonldWNTmRETN0p0O+9s+bL9pSsArEbyO2Ojk11SotR0OSDvSTm
	 TK6axJmLZdz2VNPopVi7sZOkj4SQ5Z3CpK7/C6PXstStlMW9ZpvSW5GBEKjhHuypai
	 y5AqRvAQLTSoA==
Date: Fri, 20 Jun 2025 18:27:34 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel 
Subject: Re: [PATCH v4 11/12] xen/dt: ifdef out DEV_DT-related bits from
 device_tree.{c,h}
In-Reply-To: <20250620182859.23378-12-agarciav@amd.com>
Message-ID: 
References: <20250620182859.23378-1-agarciav@amd.com> <20250620182859.23378-12-agarciav@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 20 Jun 2025, Alejandro Vallejo wrote:
> device-tree.c stops requiring CONFIG_HAS_DEVICE_TREE_DISCOVERY and may
> function with DOM0LESS_BOOT.
> 
> Without this, there's a clash with x86's definition of device_t. Because
> x86 doesn't discover devices in the DT it can simply skip the code
> to do so during the unflattening phase.
> 
> Not a functional change on architectures that currently use these files,
> as they already select CONFIG_HAS_DEVICE_TREE_DISCOVERY.
> 
> Signed-off-by: Alejandro Vallejo 

Same comment about renaming DOM0LESS_BOOT from this commit message if
there is a decision to rename that option. Other than that:

Reviewed-by: Stefano Stabellini 



From xen-devel-bounces@lists.xenproject.org Sat Jun 21 01:45:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jun 2025 01:45:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021436.1397430 (Exim 4.92)
	(envelope-from )
	id 1uSnIe-0006Rv-3N; Sat, 21 Jun 2025 01:45:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021436.1397430; Sat, 21 Jun 2025 01:45: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 1uSnIe-0006Ro-0m; Sat, 21 Jun 2025 01:45:44 +0000
Received: by outflank-mailman (input) for mailman id 1021436;
 Sat, 21 Jun 2025 01:45: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 1uSnIc-0006Ri-Vy
 for xen-devel@lists.xenproject.org; Sat, 21 Jun 2025 01:45:42 +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 6e8b83ea-4e41-11f0-b894-0df219b8e170;
 Sat, 21 Jun 2025 03:45:39 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 229CA5C4B0E;
 Sat, 21 Jun 2025 01:43:21 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id D8205C4CEE3;
 Sat, 21 Jun 2025 01:45:35 +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: 6e8b83ea-4e41-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750470337;
	bh=B05BnrrnHkToI2xcJNO3aBbCs9U0bPLSSbH1/6h83is=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=FBGfSFl2Owv60UpdS5wtUkZcsRJXak2aVrYDqkyZDkZUMXY7525A4LfimSf7HxuwI
	 4sWr85SelienwDUKL6uul8lVpDkhqTdNPG/RDNTAi5l5PR9V2aYf+3xKS/dlTzfGus
	 wr8fPPK4L8euXSdtcMPknsjo0o7UlL+ambY2kGMJ+awSgCKvRCozYLtxRDF+fKA9FN
	 VmvYc30IasJwaJR4gPd0fSiXhDPHyJGU36LSG7Mh35t0zRzQ/yfspYz4zcT+4FFGwD
	 Ozg1jB2kCkpitArDgTe45t26hErK3SD536ptlrAwvH6+mgOg44IQZAz9IRjWDry/Ru
	 fV1iO+2A2wx5A==
Date: Fri, 20 Jun 2025 18:45:35 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
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 , 
    Bertrand Marquis 
Subject: Re: [PATCH v4 12/12] xen/dt: Remove DOM0LESS_BOOT's requirement on
 HAS_DEVICE_TREE_DISCOVERY
In-Reply-To: <20250620182859.23378-13-agarciav@amd.com>
Message-ID: 
References: <20250620182859.23378-1-agarciav@amd.com> <20250620182859.23378-13-agarciav@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 20 Jun 2025, Alejandro Vallejo wrote:
> This effectively means that DOM0LESS_BOOT on platforms without
> HAS_DEVICE_TREE_DISCOVERY (i.e: x86) acts as a selector for a
> stripped-down version of DT code.
> 
> Signed-off-by: Alejandro Vallejo 

This is so much better than before. Thank you and all the reviewers for
making the integration so much smoother. This patch is so much simpler
and readable compared to before.

I think we need to plan for renaming DOM0LESS_BOOT into something
better, such as PREDEFINED_DOMS, but I would keep it as a separate
patch in any case. So I think this is OK for now.

Reviewed-by: Stefano Stabellini 


> ---
>  xen/Kconfig.debug               | 2 +-
>  xen/common/Kconfig              | 3 ++-
>  xen/common/Makefile             | 1 +
>  xen/common/device-tree/Makefile | 8 ++++----
>  4 files changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
> index 9192d593a7..89b0af53a2 100644
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -92,7 +92,7 @@ config VERBOSE_DEBUG
>  
>  config DEVICE_TREE_DEBUG
>  	bool "Device tree debug messages"
> -	depends on HAS_DEVICE_TREE_DISCOVERY
> +	depends on DOM0LESS_BOOT || HAS_DEVICE_TREE_DISCOVERY
>  	help
>  	  Device tree parsing and DOM0 device tree building messages are
>  	  logged in the Xen ring buffer.
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index 6294cd7939..1ac28a4e78 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -14,7 +14,8 @@ config CORE_PARKING
>  
>  config DOM0LESS_BOOT
>  	bool "Dom0less boot support" if EXPERT
> -	depends on HAS_DOM0LESS && HAS_DEVICE_TREE_DISCOVERY && DOMAIN_BUILD_HELPERS
> +	select LIBFDT
> +	depends on HAS_DOM0LESS && DOMAIN_BUILD_HELPERS
>  	default y
>  	help
>  	  Dom0less boot support enables Xen to create and start domU guests during
> diff --git a/xen/common/Makefile b/xen/common/Makefile
> index d541fbcf49..19d6ff7a90 100644
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_DEBUG_TRACE) += debugtrace.o
>  obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += device.o
>  obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) += device.o
>  obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += device-tree/
> +obj-$(CONFIG_DOM0LESS_BOOT) += device-tree/

nice trick


>  obj-$(CONFIG_IOREQ_SERVER) += dm.o
>  obj-y += domain.o
>  obj-y += event_2l.o
> diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
> index 8abc069c4b..4a10b0508f 100644
> --- a/xen/common/device-tree/Makefile
> +++ b/xen/common/device-tree/Makefile
> @@ -1,11 +1,11 @@
>  obj-y += bootfdt.init.o
> -obj-y += bootinfo-fdt.init.o
> -obj-y += bootinfo.init.o
> -obj-y += device-tree.o
> +obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += bootinfo-fdt.init.o
> +obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += bootinfo.init.o
> +obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += device-tree.o
>  obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.init.o
>  obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.init.o
>  obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o
> -obj-y += intc.o
> +obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += intc.o
>  obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o
>  obj-$(CONFIG_STATIC_EVTCHN) += static-evtchn.init.o
>  obj-$(CONFIG_STATIC_MEMORY) += static-memory.init.o
> -- 
> 2.43.0
> 


From xen-devel-bounces@lists.xenproject.org Sat Jun 21 02:19:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jun 2025 02:19:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021450.1397440 (Exim 4.92)
	(envelope-from )
	id 1uSnpL-0002db-CP; Sat, 21 Jun 2025 02:19:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021450.1397440; Sat, 21 Jun 2025 02: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 1uSnpL-0002dU-9o; Sat, 21 Jun 2025 02:19:31 +0000
Received: by outflank-mailman (input) for mailman id 1021450;
 Sat, 21 Jun 2025 02:19: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 1uSnpJ-0002dO-Es
 for xen-devel@lists.xenproject.org; Sat, 21 Jun 2025 02:19:29 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 27c51b54-4e46-11f0-a30e-13f23c93f187;
 Sat, 21 Jun 2025 04:19:28 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 510214A0BE;
 Sat, 21 Jun 2025 02:19:26 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id C8BABC4CEE3;
 Sat, 21 Jun 2025 02:19: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: 27c51b54-4e46-11f0-a30e-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750472366;
	bh=qpB0eX6OiG47uvWk38PB3wFb+Yl6Pl2e/pBL7MRG1fM=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=RK1qLPa7Y1rhMwlNkyfNUC4qqe1pytWiUNjlHq4Lw6UMhZhh6TWTeTnjV2OZyBVzf
	 My8qelpART+DN2irNhreRHLTZoHqP3ykXdmGWMetouOmh1F63FdFOFKOPYwBHjeMhO
	 E2jMPDGifjXcnwXFUCMSTFLWm0QHVfXH2BS4RvsmukQ4kMsw+WOEqpU1I2PgEfVnY4
	 SkiWvlAl9iZQ0sAVVxzSgYFfcu8L2fuhDhEOCZkxuGulsxbVIu5LV8CrkizI+nqCoJ
	 ORNA54/vzq2H7woLQiv5UXI1qXnLIWu2Enr/uOpPauCLscCeqQ2wBEDxPZzEi3cZyu
	 ampeZCyfu07tQ==
Date: Fri, 20 Jun 2025 19:19:24 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Stefano Stabellini , 
    Andrew Cooper , 
    Stefano Stabellini , michal.orzel@amd.com, 
    julien@xen.org, roger.pau@citrix.com, bertrand.marquis@arm.com, 
    federico.serafini@bugseng.com, Nicola Vetrini , 
    xen-devel@lists.xenproject.org
Subject: Re: [PATCH v4] automation/eclair: update configuration of D4.10
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 Jun 2025, Jan Beulich wrote:
> On 06.06.2025 23:04, Stefano Stabellini wrote:
> > --- a/xen/arch/x86/include/asm/cpufeatures.h
> > +++ b/xen/arch/x86/include/asm/cpufeatures.h
> > @@ -1,6 +1,6 @@
> > -/*
> > - * Explicitly intended for multiple inclusion.
> > - */
> > +/* This file is intended to be included multiple times. */
> 
> While I can see that this may indeed be needed, ...
> 
> > +/*#ifndef X86_CPUFEATURES_H */
> > +/*#define X86_CPUFEATURES_H */
> 
> ... I wonder what this is about. Sorry, I didn't spot this as a change
> in v3. If it's needed, these comments want to be well formed (have a
> space between * and #).

Without it, ECLAIR throws other violations. But I can fix the lack of a
space.


> Beyond this - why is this header ending up different from e.g.
> public/errno.h, where a SAF-8 comment is used?

Because SAF-8 is meant to be used on top of an #ifndef and there is no
#ifndef here


From xen-devel-bounces@lists.xenproject.org Sat Jun 21 02:19:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jun 2025 02:19:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021452.1397452 (Exim 4.92)
	(envelope-from )
	id 1uSnpT-0002tb-Ns; Sat, 21 Jun 2025 02:19:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021452.1397452; Sat, 21 Jun 2025 02: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 1uSnpT-0002tU-JV; Sat, 21 Jun 2025 02:19:39 +0000
Received: by outflank-mailman (input) for mailman id 1021452;
 Sat, 21 Jun 2025 02:19: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 1uSnpT-0002dO-0P
 for xen-devel@lists.xenproject.org; Sat, 21 Jun 2025 02:19:39 +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 2e0fe434-4e46-11f0-a30e-13f23c93f187;
 Sat, 21 Jun 2025 04:19:38 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 0C420A52B16;
 Sat, 21 Jun 2025 02:19:37 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 50DFAC4CEE3;
 Sat, 21 Jun 2025 02:19:35 +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: 2e0fe434-4e46-11f0-a30e-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750472376;
	bh=Wz1f7HTwfM3ntleW5jOAnAJ9Lp3g2P5VeneREbh3MTc=;
	h=Date:From:To:cc:Subject:From;
	b=VWR6sIm/vnyih+h0XZzL3xPdHUVmCgkB7keQecyC1j544ixv03YR1zfTmEYgZAVuB
	 22caeFWnaKQhBax5zqgwI3KxccmiKsv2nU9/LD8JVgLB57rsdqTPn7qfWHl3+GFPi3
	 tBAzlYtSXnEAUw+Ruk/s8jt4HwtQRTtCM7hZQseiYgVlKeChhZEwrT/PpVwTESc6hY
	 ikx6yolI8naAWzr+Ip50klMKWlhiiWkSjpAvRkLl2cQfaZohFO9EAwg/abs8N/pbtl
	 Ui4O5kpHOK6H8DzobRSuSQwAcxJhdc0WunTs4ajyIjjP0lUzxdwrg37SewZWPGFySq
	 hNwI9PTmt/0YQ==
Date: Fri, 20 Jun 2025 19:19:34 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: xen-devel@lists.xenproject.org
cc: Andrew Cooper , 
    Stefano Stabellini , michal.orzel@amd.com, 
    jbeulich@suse.com, julien@xen.org, roger.pau@citrix.com, 
    sstabellini@kernel.org, bertrand.marquis@arm.com, 
    federico.serafini@bugseng.com, Nicola Vetrini 
Subject: [PATCH v5] automation/eclair: update configuration of D4.10
Message-ID: 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

MISRA C Directive 4.10 states that "Precautions shall be taken in order
to prevent the contents of a header file being included more than
once".

Add a SAF tag to the existing comment on top of cpufeatures.h.
Add a header inclusion guard to compile.h.

Update ECLAIR configuration to:
- extend existing deviation to other comments explicitly saying a file
  is intended for multiple inclusion;
- extend existing deviation to other autogenerated files;
- tag the guidelines as clean.

Update deviations.rst accordingly.

Signed-off-by: Federico Serafini 
Signed-off-by: Stefano Stabellini 
---
Changes in v5:
- add missing spaces in in-code comment
---
 automation/eclair_analysis/ECLAIR/deviations.ecl | 11 +++++++----
 automation/eclair_analysis/ECLAIR/tagging.ecl    |  1 +
 docs/misra/deviations.rst                        | 12 ++++++++++++
 xen/arch/x86/include/asm/cpufeatures.h           |  8 +++++---
 xen/include/xen/compile.h.in                     |  3 +++
 xen/tools/process-banner.sed                     |  5 +++++
 6 files changed, 33 insertions(+), 7 deletions(-)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index 9c67358d46..3b5bc87e1d 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -72,11 +72,14 @@ they are not instances of commented-out code."
 -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."
+-doc_begin="Files that are intended to be included more than once (and have
+a comment that says this explicitly) do not need to conform to the directive."
 -config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* This file is intended to be 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$)))"}
+-config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* Generated file, do not edit! \\*/$, begin-3...begin-2))"}
+-doc_end
+
+-doc_begin="Autogenerated files that do not need to conform to the directive."
+-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
diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl b/automation/eclair_analysis/ECLAIR/tagging.ecl
index f9da5d5f4d..b95f07feb0 100644
--- a/automation/eclair_analysis/ECLAIR/tagging.ecl
+++ b/automation/eclair_analysis/ECLAIR/tagging.ecl
@@ -23,6 +23,7 @@
 "MC3A2.D1.1||
 MC3A2.D2.1||
 MC3A2.D4.1||
+MC3A2.D4.10||
 MC3A2.D4.11||
 MC3A2.D4.14||
 MC3A2.R1.1||
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index fe0b1e10a2..63caa8f4a2 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -30,6 +30,18 @@ Deviations related to MISRA C:2012 Directives:
        not to add an additional encapsulation layer.
      - Tagged as `deliberate` for ECLAIR.
 
+   * - D4.10
+     - Files that are intended to be included more than once (and have
+       a comment that says this explicitly) do not need to conform to the
+       directive.
+     - Tagged as `safe` for ECLAIR.
+
+   * - D4.10
+     - There are autogenerated files that do not need to comply to the
+       directive.
+     - Tagged as `safe` for ECLAIR. Such files are:
+        - xen/include/generated/autoconf.h
+
    * - D4.10
      - Including multiple times a .c file is safe because every function or data item
        it defines would in (the common case) be already defined.
diff --git a/xen/arch/x86/include/asm/cpufeatures.h b/xen/arch/x86/include/asm/cpufeatures.h
index 9e3ed21c02..69041219cb 100644
--- a/xen/arch/x86/include/asm/cpufeatures.h
+++ b/xen/arch/x86/include/asm/cpufeatures.h
@@ -1,6 +1,6 @@
-/*
- * Explicitly intended for multiple inclusion.
- */
+/* This file is intended to be included multiple times. */
+/* #ifndef X86_CPUFEATURES_H */
+/* #define X86_CPUFEATURES_H */
 
 #include 
 
@@ -63,3 +63,5 @@ XEN_CPUFEATURE(USE_VMCALL,        X86_SYNTH(30)) /* Use VMCALL instead of VMMCAL
 
 /* Total number of capability words, inc synth and bug words. */
 #define NCAPINTS (FSCAPINTS + X86_NR_SYNTH + X86_NR_BUG) /* N 32-bit words worth of info */
+
+/* #endif X86_CPUFEATURES_H */
diff --git a/xen/include/xen/compile.h.in b/xen/include/xen/compile.h.in
index 3151d1e7d1..9206341ba6 100644
--- a/xen/include/xen/compile.h.in
+++ b/xen/include/xen/compile.h.in
@@ -1,3 +1,6 @@
+#ifndef XEN_COMPILE_H
+#define XEN_COMPILE_H
+
 #define XEN_COMPILE_DATE	"@@date@@"
 #define XEN_COMPILE_TIME	"@@time@@"
 #define XEN_COMPILE_BY		"@@whoami@@"
diff --git a/xen/tools/process-banner.sed b/xen/tools/process-banner.sed
index 56c76558bc..4cf3f9a116 100755
--- a/xen/tools/process-banner.sed
+++ b/xen/tools/process-banner.sed
@@ -12,3 +12,8 @@ s_(.*)_"\1\\n"_
 
 # Trailing \ on all but the final line.
 $!s_$_ \\_
+
+# Append closing header guard
+$a\
+\
+#endif /* XEN_COMPILE_H */
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Sat Jun 21 02:25:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jun 2025 02:25:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021468.1397460 (Exim 4.92)
	(envelope-from )
	id 1uSnvK-0004pl-9x; Sat, 21 Jun 2025 02:25:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021468.1397460; Sat, 21 Jun 2025 02:25: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 1uSnvK-0004pe-6p; Sat, 21 Jun 2025 02:25:42 +0000
Received: by outflank-mailman (input) for mailman id 1021468;
 Sat, 21 Jun 2025 02:25: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 1uSnvJ-0004pY-Bm
 for xen-devel@lists.xenproject.org; Sat, 21 Jun 2025 02:25:41 +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 0517c80c-4e47-11f0-b894-0df219b8e170;
 Sat, 21 Jun 2025 04:25:39 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 1F4585C5D11;
 Sat, 21 Jun 2025 02:23:21 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3480CC4CEE3;
 Sat, 21 Jun 2025 02:25: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: 0517c80c-4e47-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750472737;
	bh=E0I3cDBuaGzunWRonMSO2bSU5K+/DeNDlCffYG/TFdw=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=POjT8q8/xixdwwDuLXZuIJ89IpIw2CkQoFOixa9V8K0Z2pEEoZV9Tpw6xAOUVG2Xx
	 vnVGH1S2HG9uQOE71dtDA7EbVnUwp0lQLXDxr8M1FRVTiY5DTKVxx3fJ7h/jnjJU5+
	 rndHHUac/rgJU/fw/ht0g+TtVf0aCIRkf4uHyOd7lMEITr68dy4h3m3n81yq5o86U2
	 XAcyG8QE/QzObqHxsDyGv9ooXDqrCA0TWylWDv2iOmC4bmDVlISi5Cz39J/IoFXmHt
	 DCNuSd6W5NxdjZJLDpJBvDsrApSTUyUVaWczkCu6M0Lxg9RBoY2ew6VwJvgBc7v1aR
	 yDu1jUKgugC2Q==
Date: Fri, 20 Jun 2025 19:25:35 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Stefano Stabellini , 
    Nicola Vetrini , 
    Stefano Stabellini , 
    Andrew Cooper , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Alessandro Zucchelli , 
    xen-devel@lists.xenproject.org, federico.serafini@bugseng.com
Subject: Re: [PATCH] x86: remove memcmp calls non-compliant with Rule
 21.16.
In-Reply-To: <315e605d-2da6-4df5-b791-b3f59e0ff6d4@suse.com>
Message-ID: 
References: <20250604233537.2892206-1-stefano.stabellini@amd.com>   <13ad335c1868bcc02e2dc0a8da521f6d@bugseng.com>
  <315e605d-2da6-4df5-b791-b3f59e0ff6d4@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Tue, 10 Jun 2025, Jan Beulich wrote:
> On 06.06.2025 22:49, Stefano Stabellini wrote:
> > On Fri, 6 Jun 2025, Nicola Vetrini wrote:
> >>>>> Signed-off-by: Alessandro Zucchelli 
> >>>>
> >>>> Missing your own S-o-b.
> >>>>
> >>>> Also (nit) may I ask that you drop the full stop from the patch subject?
> >>>
> >>> I'll add the S-o-B and fix the subject
> >>>
> >>>
> >>>>> --- a/xen/arch/x86/dmi_scan.c
> >>>>> +++ b/xen/arch/x86/dmi_scan.c
> >>>>> @@ -233,7 +233,7 @@ void __init dmi_efi_get_table(const void *smbios,
> >>>> const void *smbios3)
> >>>>>  	const struct smbios_eps *eps = smbios;
> >>>>>  	const struct smbios3_eps *eps3 = smbios3;
> >>>>>
> >>>>> -	if (eps3 && memcmp(eps3->anchor, "_SM3_", 5) == 0 &&
> >>>>> +	if (eps3 && strncmp(eps3->anchor, "_SM3_", 5) == 0 &&
> >>>>
> >>>> Unlike the last example given in the doc, this does not pose the risk of
> >>>> false "not equal" returns. Considering there's no example there exactly
> >>>> matching this situation, I'm not convinced a change is actually needed.
> >>>> (Applies to all other changes here, too.)
> >>>
> >>> If we consider string literals "pointer types", then I think you are
> >>> right that this would fall under what is permitted by 21.16. Nicola,
> >>> what do you think?
> >>>
> >>
> >> While I agree that the result of the comparison is correct either way in these
> >> cases, the rule is written to be simple to apply (i.e., not limited only to
> >> those cases that may differ), and in particular in the rationale it is
> >> indicated that using memcmp to compare string *may* indicate a mistake. As
> >> written above, deviating the string literal comparisons is an option, which
> >> can be justified with efficiency concerns, but it goes a bit against the
> >> rationale of the rule itself.
> > 
> > Also looking at Andrew's reply, it seems that the preference is to
> > deviate string literals. The change to docs/misra/rules.rst is easy
> > enough, but I am not sure how to make the corresponding change to
> > analysis.ecl.
> > 
> > diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
> > index e1c26030e8..56b6e351df 100644
> > --- a/docs/misra/rules.rst
> > +++ b/docs/misra/rules.rst
> > @@ -813,7 +813,7 @@ maintainers if you want to suggest a change.
> >         shall point to either a pointer type, an essentially signed type,
> >         an essentially unsigned type, an essentially Boolean type or an
> >         essentially enum type
> > -     - void* arguments are allowed
> > +     - void* and string literals arguments are allowed
> 
> Yet as per my earlier reply: This would go too far, wouldn't it?

You are suggesting:

"void* arguments are allowed. string literals arguments are allowed when
the last argument passed for the comparison is equal to the size of the
string."

Please suggest another wording if you prefer. From an ECLAIR
perspective, I don't know if we can be so selective, and maybe we just
need to allow any string literal as argument, in addition to void*.

Nicola, would you be able to provide an ECLAIR configuration that would
allow string literals as arguments? Is that supported by ECLAIR?
this?


From xen-devel-bounces@lists.xenproject.org Sat Jun 21 05:11:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jun 2025 05:11:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021496.1397479 (Exim 4.92)
	(envelope-from )
	id 1uSqVI-0007w8-Nn; Sat, 21 Jun 2025 05:11:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021496.1397479; Sat, 21 Jun 2025 05: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 1uSqVI-0007w1-Jl; Sat, 21 Jun 2025 05:11:00 +0000
Received: by outflank-mailman (input) for mailman id 1021496;
 Sat, 21 Jun 2025 05:10:58 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uSqVG-0007vv-HS
 for xen-devel@lists.xenproject.org; Sat, 21 Jun 2025 05:10:58 +0000
Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com
 [2607:f8b0:4864:20::732])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1c362f37-4e5e-11f0-a30e-13f23c93f187;
 Sat, 21 Jun 2025 07:10:56 +0200 (CEST)
Received: by mail-qk1-x732.google.com with SMTP id
 af79cd13be357-7d20f79a00dso362636785a.0
 for ; Fri, 20 Jun 2025 22:10:56 -0700 (PDT)
Received: from [10.138.10.6] ([89.187.178.201])
 by smtp.gmail.com with ESMTPSA id
 6a1803df08f44-6fd093decf0sm19914626d6.16.2025.06.20.22.10.53
 for 
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 20 Jun 2025 22:10:53 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1c362f37-4e5e-11f0-a30e-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750482655; x=1751087455; darn=lists.xenproject.org;
        h=in-reply-to:subject:autocrypt:from:content-language:references:to
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=bRGAj/y103D2lRCHG6ytCb2oeTTdg2OSAmLx277qoD8=;
        b=J12lhZzgMANQoINOvrcFVwnwMn5ZGYO8zQl0uOuuwRyDBuAvItL6WNgs6z+dfHgxej
         GVTcVXmhpeg3pEl7mMS70wFV06j4KTgsu/SL3BNcLStwOn9hj1WMPHCY1IeeQvX88oQ7
         icv2dCV+NBo0lEwb3CzwOEXDmKvwsWYYGmB0oA7Wj8dQw1Rue8xINpCLnUKyaOF+wtnf
         6I2fG4VjSAy8wVm0MWDy9rooyRyBjtNKVU480y3/5eGi1gfRoZMUQGSFzyigXTYbBBis
         duNynEDznxWVN2rpi7uz/hiCnLKf4xXM4plMAvHK4ukkeWHQbSSlzwaX3Snvh4/42KuY
         8cmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750482655; x=1751087455;
        h=in-reply-to:subject:autocrypt:from:content-language:references:to
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=bRGAj/y103D2lRCHG6ytCb2oeTTdg2OSAmLx277qoD8=;
        b=ojxYgSSJZXZtPDI+sRmf1hFgg5tp3XxRP0DObMFxtkcS7b7DF9bajCwN885pNzQbBy
         /WJiquHDI40uZ969kbEz0gnsk9WPraiWt0MUOoLwnLJ6WQ1flXwBt2nDykEe07MWJeNW
         YFJTZKYtHcVswYlaI4ZF0xV0Pd4eOsmXpEnzFQXIu1tfh4ovN++M8QSJUHhPkMaMa3p4
         CiFmxk+Bgk7bbvP+bboW90qhYNLDMudL3xWj9cgZjBCyWdWZHQa7HF48WTTPzeIYqyHe
         ULCqvBWSzvG63Mi6GUbaMvNwEXyCY6+7MTNiwKGL4IxnJ2rQEqfVJH3e/KYdUBHCrV6v
         Ja4Q==
X-Gm-Message-State: AOJu0YxF8JO7/hSRvBbbJFI+BG9uzndyTLgCwz5siqmtXgxWcHwhGACy
	SSEBZWKtGczin57/Z8apJo6y6zRCAT/EG8zMGDzxuMUMgSSUgmNUvTEWpBIZag==
X-Gm-Gg: ASbGncsT8bEF5JVoFJdoJK1ceStbbXqD3or2Ee000rHrL6mVzbrzuBjohpza+14T44O
	CXyStjST++lOhe8Xq53dIYxa+kPGCRkJOw/hhi1fWvQ5GVW4lXIxNNvQ55FGGLOvogfNgLCcbll
	2iwepQvto/FhhkAgGUc+FweQvgZY9BInqPWNhLVvU1FKamcis7QYZTUzBBDQel2g7i5/fV2lian
	noPBbsvLnaXkDuv+RSb8KUqPvCGviAU90nTbPutQTaZgYZr19ixsHqjZ2o8bfIiF76zsGswCO+y
	hTN93fGPGBhj1US3wO8SZ3jqfB7KslnKLbxZ4Rc9WINJxOmvLCt7/iSpANHLVcfNaVqPRi58L3L
	zHQ==
X-Google-Smtp-Source: AGHT+IEXqHadApJy2RvlCv5yhItYX/l+t5IlSBKM0tgLms4k+9n34A9Fu/BRmTcl2FTXxvrkWPSlOQ==
X-Received: by 2002:a05:620a:3186:b0:7d2:1684:2429 with SMTP id af79cd13be357-7d3f9929b9cmr777027785a.31.1750482654642;
        Fri, 20 Jun 2025 22:10:54 -0700 (PDT)
Message-ID: 
Date: Sat, 21 Jun 2025 01:10:39 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: xen-devel@lists.xenproject.org
References: 
Content-Language: en-US
From: Demi Marie Obenour 
Autocrypt: addr=demiobenour@gmail.com; keydata=
 xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49yB+l2nipd
 aq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYfbWpr/si88QKgyGSV
 Z7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/UorR+FaSuVwT7rqzGrTlscnT
 DlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7MMPCJwI8JpPlBedRpe9tfVyfu3euTPLPx
 wcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9Hzx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR
 6h3nBc3eyuZ+q62HS1pJ5EvUT1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl
 5FMWo8TCniHynNXsBtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2
 Bkg1b//r6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nSm9BBff0N
 m0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQABzTxEZW1pIE1hcmll
 IE9iZW5vdXIgKGxvdmVyIG9mIGNvZGluZykgPGRlbWlvYmVub3VyQGdtYWlsLmNvbT7CwXgE
 EwECACIFAlp+A0oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELKItV//nCLBhr8Q
 AK/xrb4wyi71xII2hkFBpT59ObLN+32FQT7R3lbZRjVFjc6yMUjOb1H/hJVxx+yo5gsSj5LS
 9AwggioUSrcUKldfA/PKKai2mzTlUDxTcF3vKx6iMXKA6AqwAw4B57ZEJoMM6egm57TV19kz
 PMc879NV2nc6+elaKl+/kbVeD3qvBuEwsTe2Do3HAAdrfUG/j9erwIk6gha/Hp9yZlCnPTX+
 VK+xifQqt8RtMqS5R/S8z0msJMI/ajNU03kFjOpqrYziv6OZLJ5cuKb3bZU5aoaRQRDzkFIR
 6aqtFLTohTo20QywXwRa39uFaOT/0YMpNyel0kdOszFOykTEGI2u+kja35g9TkH90kkBTG+a
 EWttIht0Hy6YFmwjcAxisSakBuHnHuMSOiyRQLu43ej2+mDWgItLZ48Mu0C3IG1seeQDjEYP
 tqvyZ6bGkf2Vj+L6wLoLLIhRZxQOedqArIk/Sb2SzQYuxN44IDRt+3ZcDqsPppoKcxSyd1Ny
 2tpvjYJXlfKmOYLhTWs8nwlAlSHX/c/jz/ywwf7eSvGknToo1Y0VpRtoxMaKW1nvH0OeCSVJ
 itfRP7YbiRVc2aNqWPCSgtqHAuVraBRbAFLKh9d2rKFB3BmynTUpc1BQLJP8+D5oNyb8Ts4x
 Xd3iV/uD8JLGJfYZIR7oGWFLP4uZ3tkneDfYzsFNBFp+A0oBEAC9ynZI9LU+uJkMeEJeJyQ/
 8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd8xD57ue0eB47bcJv
 VqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPpI4gfUbVEIEQuqdqQyO4GAe+M
 kD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalql1/iSyv1WYeC1OAs+2BLOAT2NEggSiVO
 txEfgewsQtCWi8H1SoirakIfo45Hz0tk/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJ
 riwoaRIS8N2C8/nEM53jb1sH0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcN
 fRAIUrNlatj9TxwivQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6
 dCxN0GNAORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
 rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog2LNtcyCj
 kTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZAgrrnNz0iZG2DVx46
 x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJELKItV//nCLBwNIP/AiIHE8b
 oIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwjjVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGj
 gn0TPtsGzelyQHipaUzEyrsceUGWYoKXYyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8fr
 RHnJdBcjf112PzQSdKC6kqU0Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2
 E0rW4tBtDAn2HkT9uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHM
 OBvy3EhzfAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
 Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVssZ/rYZ9+5
 1yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aWemLLszcYz/u3XnbO
 vUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPthZlDnTnOT+C+OTsh8+m5tos8
 HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E
 +MYSfkEjBz0E8CLOcAw7JIwAaeBT
Subject: Re: hardware domain and control domain separation
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------lI6zHVtu2Xp4iwErzZz4EIIC"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------lI6zHVtu2Xp4iwErzZz4EIIC
Content-Type: multipart/mixed; boundary="------------y1sXtTckdOlnGH7gHmzjVEpq";
 protected-headers="v1"
From: Demi Marie Obenour 
To: xen-devel@lists.xenproject.org
Message-ID: 
Subject: Re: hardware domain and control domain separation
References: 
In-Reply-To: 

--------------y1sXtTckdOlnGH7gHmzjVEpq
Content-Type: multipart/mixed; boundary="------------BysvO2aRltQ97UpQmUVohNoZ"

--------------BysvO2aRltQ97UpQmUVohNoZ
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 6/20/25 20:41, Stefano Stabellini wrote:
> Hi all,
>=20
> Regarding hardware domain and control domain separation, Ayan sent to
> xen-devel an architecture specification (a design document) that I wrot=
e
> previously about the topic. This is written as safety document so it is=

> using a language and structure specific for that. However, it contains
> much of the explanation needed on the topic:
>=20
> https://lore.kernel.org/xen-devel/20250304183115.2509666-1-ayan.kumar.h=
alder@amd.com/
>=20
> If you take Virtio and PV drivers aside, the conceptual model is very
> simple. I suggest we start from there, also because deployments without=

> Virtio/PV drivers are indeed possible. Often in mixed-criticality
> environments device sharing is absent or very limited.

That's why I was so surprised that Xen was needed at all, instead of a
microhypervisor being used.  It makes a more sense once the need to run
existing Unsafe VMs and the desire for an existing ecosystem is
considered.

> When we bring Virtio and PV drivers into the picture, things get more
> complex. One simple mental model is that they are only allowed between
> Unsafe VMs, because we cannot guarantee that neither the protocols nor
> the widely adopted implementations are entirely free from interference.=

> So, Virtio (and PV drivers) between Unsafe VMs are OK, but Safe VMs
> should be left alone.
>=20
> There are lots of extra details in the document about the problems of
> freedom from interference and Virtio. I wrote those details to explain =
why
> Virtio between Safe and Unsafe VMs cannot be expected to work without
> modifications today (people will ask for this, this way we'll have the
> answers ready). I also wrote those details so that if someone wanted to=

> do an analysis on this topic and potentially deploy an entirely written=

> from scratch Virtio driver-protocol-backend implementation, they would
> have a starting point for their investigation.
What are the ways in which the ring buffer setup is bad?

It's worth noting that grants are only applicable for situations where
the shared memory is allocated by the frontend.  They are not applicable
when the shared memory is (of necessity) allocated by the backend, as
happens in virtio-GPU with blob objects and virtio-FS with DAX.  These
are not currently supported by Xen and should not be relevant to
safety-critical workloads.  Interference is inherent to these protocols
as the backend-allocated memory is pageable by the backend and so the
backend can force the frontend to take a blocking page fault at any
time it accesses the memory.  This is not a preferred configuration and
will only be needed due to Linux kernel memory management limitations.
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
--------------BysvO2aRltQ97UpQmUVohNoZ
Content-Type: application/pgp-keys; name="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

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

xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49y
B+l2nipdaq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYf
bWpr/si88QKgyGSVZ7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/
UorR+FaSuVwT7rqzGrTlscnTDlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7M
MPCJwI8JpPlBedRpe9tfVyfu3euTPLPxwcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9H
zx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR6h3nBc3eyuZ+q62HS1pJ5EvU
T1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl5FMWo8TCniHynNXs
BtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2Bkg1b//r
6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nS
m9BBff0Nm0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQAB
zTxEZW1pIE9iZW5vdXIgKElUTCBFbWFpbCBLZXkpIDxhdGhlbmFAaW52aXNpYmxl
dGhpbmdzbGFiLmNvbT7CwY4EEwEIADgWIQR2h02fEza6IlkHHHGyiLVf/5wiwQUC
X6YJvQIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRCyiLVf/5wiwWRhD/0Y
R+YYC5Kduv/2LBgQJIygMsFiRHbR4+tWXuTFqgrxxFSlMktZ6gQrQCWe38WnOXkB
oY6n/5lSJdfnuGd2UagZ/9dkaGMUkqt+5WshLFly4BnP7pSsWReKgMP7etRTwn3S
zk1OwFx2lzY1EnnconPLfPBc6rWG2moA6l0WX+3WNR1B1ndqpl2hPSjT2jUCBWDV
rGOUSX7r5f1WgtBeNYnEXPBCUUM51pFGESmfHIXQrqFDA7nBNiIVFDJTmQzuEqIy
Jl67pKNgooij5mKzRhFKHfjLRAH4mmWZlB9UjDStAfFBAoDFHwd1HL5VQCNQdqEc
/9lZDApqWuCPadZN+pGouqLysesIYsNxUhJ7dtWOWHl0vs7/3qkWmWun/2uOJMQh
ra2u8nA9g91FbOobWqjrDd6x3ZJoGQf4zLqjmn/P514gb697788e573WN/MpQ5XI
Fl7aM2d6/GJiq6LC9T2gSUW4rbPBiqOCeiUx7Kd/sVm41p9TOA7fEG4bYddCfDsN
xaQJH6VRK3NOuBUGeL+iQEVF5Xs6Yp+U+jwvv2M5Lel3EqAYo5xXTx4ls0xaxDCu
fudcAh8CMMqx3fguSb7Mi31WlnZpk0fDuWQVNKyDP7lYpwc4nCCGNKCj622ZSocH
AcQmX28L8pJdLYacv9pU3jPy4fHcQYvmTavTqowGnM08RGVtaSBNYXJpZSBPYmVu
b3VyIChsb3ZlciBvZiBjb2RpbmcpIDxkZW1pb2Jlbm91ckBnbWFpbC5jb20+wsF4
BBMBAgAiBQJafgNKAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCyiLVf
/5wiwYa/EACv8a2+MMou9cSCNoZBQaU+fTmyzft9hUE+0d5W2UY1RY3OsjFIzm9R
/4SVccfsqOYLEo+S0vQMIIIqFEq3FCpXXwPzyimotps05VA8U3Bd7yseojFygOgK
sAMOAee2RCaDDOnoJue01dfZMzzHPO/TVdp3OvnpWipfv5G1Xg96rwbhMLE3tg6N
xwAHa31Bv4/Xq8CJOoIWvx6fcmZQpz01/lSvsYn0KrfEbTKkuUf0vM9JrCTCP2oz
VNN5BYzqaq2M4r+jmSyeXLim922VOWqGkUEQ85BSEemqrRS06IU6NtEMsF8EWt/b
hWjk/9GDKTcnpdJHTrMxTspExBiNrvpI2t+YPU5B/dJJAUxvmhFrbSIbdB8umBZs
I3AMYrEmpAbh5x7jEjoskUC7uN3o9vpg1oCLS2ePDLtAtyBtbHnkA4xGD7ar8mem
xpH9lY/i+sC6CyyIUWcUDnnagKyJP0m9ks0GLsTeOCA0bft2XA6rD6aaCnMUsndT
ctrab42CV5XypjmC4U1rPJ8JQJUh1/3P48/8sMH+3krxpJ06KNWNFaUbaMTGiltZ
7x9DngklSYrX0T+2G4kVXNmjaljwkoLahwLla2gUWwBSyofXdqyhQdwZsp01KXNQ
UCyT/Pg+aDcm/E7OMV3d4lf7g/CSxiX2GSEe6BlhSz+Lmd7ZJ3g32M1ARGVtaSBN
YXJpZSBPYmVub3VyIChJVEwgRW1haWwgS2V5KSA8ZGVtaUBpbnZpc2libGV0aGlu
Z3NsYWIuY29tPsLBjgQTAQgAOBYhBHaHTZ8TNroiWQcccbKItV//nCLBBQJgOEV+
AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJELKItV//nCLBKwoP/1WSnFdv
SAD0g7fD0WlF+oi7ISFT7oqJnchFLOwVHK4Jg0e4hGn1ekWsF3Ha5tFLh4V/7UUu
obYJpTfBAA2CckspYBqLtKGjFxcaqjjpO1I2W/jeNELVtSYuCOZICjdNGw2Hl9yH
KRZiBkqc9u8lQcHDZKq4LIpVJj6ZQV/nxttDX90ax2No1nLLQXFbr5wb465LAPpU
lXwunYDij7xJGye+VUASQh9datye6orZYuJvNo8Tr3mAQxxkfR46LzWgxFCPEAZJ
5P56Nc0IMHdJZj0Uc9+1jxERhOGppp5jlLgYGK7faGB/jTV6LaRQ4Ad+xiqokDWp
mUOZsmA+bMbtPfYjDZBz5mlyHcIRKIFpE1l3Y8F7PhJuzzMUKkJi90CYakCV4x/a
Zs4pzk5E96c2VQx01RIEJ7fzHF7lwFdtfTS4YsLtAbQFsKayqwkGcVv2B1AHeqdo
TMX+cgDvjd1ZganGlWA8Sv9RkNSMchn1hMuTwERTyFTr2dKPnQdA1F480+jUap41
ClXgn227WkCIMrNhQGNyJsnwyzi5wS8rBVRQ3BOTMyvGM07j3axUOYaejEpg7wKi
wTPZGLGH1sz5GljD/916v5+v2xLbOo5606j9dWf5/tAhbPuqrQgWv41wuKDi+dDD
EKkODF7DHes8No+QcHTDyETMn1RYm7t0RKR4zsFNBFp+A0oBEAC9ynZI9LU+uJkM
eEJeJyQ/8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd
8xD57ue0eB47bcJvVqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPp
I4gfUbVEIEQuqdqQyO4GAe+MkD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalq
l1/iSyv1WYeC1OAs+2BLOAT2NEggSiVOtxEfgewsQtCWi8H1SoirakIfo45Hz0tk
/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJriwoaRIS8N2C8/nEM53jb1sH
0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcNfRAIUrNlatj9Txwi
vQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6dCxN0GNA
ORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog
2LNtcyCjkTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZA
grrnNz0iZG2DVx46x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJ
ELKItV//nCLBwNIP/AiIHE8boIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwj
jVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGjgn0TPtsGzelyQHipaUzEyrsceUGWYoKX
YyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8frRHnJdBcjf112PzQSdKC6kqU0
Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2E0rW4tBtDAn2HkT9
uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHMOBvy3Ehz
fAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVss
Z/rYZ9+51yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aW
emLLszcYz/u3XnbOvUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPt
hZlDnTnOT+C+OTsh8+m5tos8HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj
6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E+MYSfkEjBz0E8CLOcAw7JIwAaeBTzsFN
BGbyLVgBEACqClxh50hmBepTSVlan6EBq3OAoxhrAhWZYEwN78k+ENhK68KhqC5R
IsHzlL7QHW1gmfVBQZ63GnWiraM6wOJqFTL4ZWvRslga9u28FJ5XyK860mZLgYhK
9BzoUk4s+dat9jVUbq6LpQ1Ot5I9vrdzo2p1jtQ8h9WCIiFxSYy8s8pZ3hHh5T64
GIj1m/kY7lG3VIdUgoNiREGf/iOMjUFjwwE9ZoJ26j9p7p1U+TkKeF6wgswEB1T3
J8KCAtvmRtqJDq558IU5jhg5fgN+xHB8cgvUWulgK9FIF9oFxcuxtaf/juhHWKMO
RtL0bHfNdXoBdpUDZE+mLBUAxF6KSsRrvx6AQyJs7VjgXJDtQVWvH0PUmTrEswgb
49nNU+dLLZQAZagxqnZ9Dp5l6GqaGZCHERJcLmdY/EmMzSf5YazJ6c0vO8rdW27M
kn73qcWAplQn5mOXaqbfzWkAUPyUXppuRHfrjxTDz3GyJJVOeMmMrTxH4uCaGpOX
Z8tN6829J1roGw4oKDRUQsaBAeEDqizXMPRc+6U9vI5FXzbAsb+8lKW65G7JWHym
YPOGUt2hK4DdTA1PmVo0DxH00eWWeKxqvmGyX+Dhcg+5e191rPsMRGsDlH6KihI6
+3JIuc0y6ngdjcp6aalbuvPIGFrCRx3tnRtNc7He6cBWQoH9RPwluwARAQABwsOs
BBgBCgAgFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmbyLVgCGwICQAkQsoi1X/+c
IsHBdCAEGQEKAB0WIQSilC2pUlbVp66j3+yzNoc6synyUwUCZvItWAAKCRCzNoc6
synyU85gD/0T1QDtPhovkGwoqv4jUbEMMvpeYQf+oWgm/TjWPeLwdjl7AtY0G9Ml
ZoyGniYkoHi37Gnn/ShLT3B5vtyI58ap2+SSa8SnGftdAKRLiWFWCiAEklm9FRk8
N3hwxhmSFF1KR/AIDS4g+HIsZn7YEMubBSgLlZZ9zHl4O4vwuXlREBEW97iL/FSt
VownU2V39t7PtFvGZNk+DJH7eLO3jmNRYB0PL4JOyyda3NH/J92iwrFmjFWWmmWb
/Xz8l9DIs+Z59pRCVTTwbBEZhcUc7rVMCcIYL+q1WxBG2e6lMn15OQJ5WfiE6E0I
sGirAEDnXWx92JNGx5l+mMpdpsWhBZ5iGTtttZesibNkQfd48/eCgFi4cxJUC4PT
UQwfD9AMgzwSTGJrkI5XGy+XqxwOjL8UA0iIrtTpMh49zw46uV6kwFQCgkf32jZM
OLwLTNSzclbnA7GRd8tKwezQ/XqeK3dal2n+cOr+o+Eka7yGmGWNUqFbIe8cjj9T
JeF3mgOCmZOwMI+wIcQYRSf+e5VTMO6TNWH5BI3vqeHSt7HkYuPlHT0pGum88d4a
pWqhulH4rUhEMtirX1hYx8Q4HlUOQqLtxzmwOYWkhl1C+yPObAvUDNiHCLf9w28n
uihgEkzHt9J4VKYulyJM9fe3ENcyU6rpXD7iANQqcr87ogKXFxknZ97uEACvSucc
RbnnAgRqZ7GDzgoBerJ2zrmhLkeREZ08iz1zze1JgyW3HEwdr2UbyAuqvSADCSUU
GN0vtQHsPzWl8onRc7lOPqPDF8OO+UfN9NAfA4wl3QyChD1GXl9rwKQOkbvdlYFV
UFx9u86LNi4ssTmU8p9NtHIGpz1SYMVYNoYy9NU7EVqypGMguDCL7gJt6GUmA0sw
p+YCroXiwL2BJ7RwRqTpgQuFL1gShkA17D5jK4mDPEetq1d8kz9rQYvAR/sTKBsR
ImC3xSfn8zpWoNTTB6lnwyP5Ng1bu6esS7+SpYprFTe7ZqGZF6xhvBPf1Ldi9UAm
U2xPN1/eeWxEa2kusidmFKPmN8lcT4miiAvwGxEnY7Oww9CgZlUB+LP4dl5VPjEt
sFeAhrgxLdpVTjPRRwTd9VQF3/XYl83j5wySIQKIPXgT3sG3ngAhDhC8I8GpM36r
8WJJ3x2yVzyJUbBPO0GBhWE2xPNIfhxVoU4cGGhpFqz7dPKSTRDGq++MrFgKKGpI
ZwT3CPTSSKc7ySndEXWkOYArDIdtyxdE1p5/c3aoz4utzUU7NDHQ+vVIwlnZSMiZ
jek2IJP3SZ+COOIHCVxpUaZ4lnzWT4eDqABhMLpIzw6NmGfg+kLBJhouqz81WITr
EtJuZYM5blWncBOJCoWMnBEcTEo/viU3GgcVRw=3D=3D
=3Dx94R
-----END PGP PUBLIC KEY BLOCK-----

--------------BysvO2aRltQ97UpQmUVohNoZ--

--------------y1sXtTckdOlnGH7gHmzjVEpq--

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

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

iQIzBAEBCAAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmhWPtgACgkQszaHOrMp
8lNObhAAlJ+t5d2MV/qjfB2+WgqFYaeIIf3zVS1CVP3h9ofAA7PNlQbggR9zBPWQ
CP6MpyUIaDYtm2lMcA51VR+i4rlo0OmaFdd8kL8xBC+n/9I8keBTvmSyShM2aUzr
pXJWUo3YhDDy2Nlhf4cLVouATWrnEuQenmt4Oe+c6TgHXuWCDRcGMgWr/b4a9OzD
2Phc+W6f7y6HHktzCC7FECqkd2vshmfkJVVnHoOVeEQuLc6gqBfUw0EIuiutLZxk
WIR9qOfhyHHb+0nb404nqgZvOLswmco/LqMJjvkHC87Y+BOGp8vE2uh46s10Mj1B
6PYy3hajhuosTj9ACdrGgEElXmvkDvhnFPtCJIaMnD2at1aNrrboDcJHupB754+p
3MVRG9YUTOH/OTou7ivKiuYAaJgWV3ySn7joC7cjzRLataXxM7zt3hs4jBcRyGTv
WyTWgD6zc8v/J/uzmEzFGVbW/tk0yAKOHq6+8VFODn9EF/uoXaYaGsqu6kCTJVY8
2XYGnCFoQKvZbdsU9yHWbYztkCR/DqJFMrSALQ/PPWX5SdfpyYMS6whSGhiRlhF1
+1vXDzcvJOLh3xqlZ9UtCBtnu+d53ItzMczFM7OllUjBDp0IQE9Ynhlid8JVOFd+
t90U7B8PvlVwZqLQ9lHqDb9hVUhYGAPu0pYIlFyvnPjL1jySr7c=
=YTk0
-----END PGP SIGNATURE-----

--------------lI6zHVtu2Xp4iwErzZz4EIIC--


From xen-devel-bounces@lists.xenproject.org Sat Jun 21 06:11:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jun 2025 06:11:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021514.1397489 (Exim 4.92)
	(envelope-from )
	id 1uSrS3-0006rh-2V; Sat, 21 Jun 2025 06:11:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021514.1397489; Sat, 21 Jun 2025 06:11:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uSrS2-0006ra-W8; Sat, 21 Jun 2025 06:11:42 +0000
Received: by outflank-mailman (input) for mailman id 1021514;
 Sat, 21 Jun 2025 06: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 1uSrS2-0006rU-0M
 for xen-devel@lists.xenproject.org; Sat, 21 Jun 2025 06:11:42 +0000
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [160.30.148.35])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 94fd8409-4e66-11f0-b894-0df219b8e170;
 Sat, 21 Jun 2025 08:11:37 +0200 (CEST)
Received: from mse-fl1.zte.com.cn (unknown [10.5.228.132])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by mxhk.zte.com.cn (FangMail) with ESMTPS id 4bPP9r0htLz8R044;
 Sat, 21 Jun 2025 14:11:28 +0800 (CST)
Received: from xaxapp02.zte.com.cn ([10.88.97.241])
 by mse-fl1.zte.com.cn with SMTP id 55L6BE2X044176;
 Sat, 21 Jun 2025 14:11:14 +0800 (+08)
 (envelope-from jiang.peng9@zte.com.cn)
Received: from mapi (xaxapp01[null]) by mapi (Zmail) with MAPI id mid31;
 Sat, 21 Jun 2025 14:11:16 +0800 (CST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 94fd8409-4e66-11f0-b894-0df219b8e170
Date: Sat, 21 Jun 2025 14:11:16 +0800 (CST)
X-Zmail-TransId: 2af968564d04ffffffffda0-110f6
X-Mailer: Zmail v1.0
Message-ID: <20250621141116690-r2XBDvxlTEKKmLkptW3g@zte.com.cn>
In-Reply-To: <62eb6d8a-7759-46b1-b06b-e7c6bc4f9a11@suse.com>
References: 20250620084104786r5xoR16_AmYZMJLnno3_Q@zte.com.cn,62eb6d8a-7759-46b1-b06b-e7c6bc4f9a11@suse.com
Mime-Version: 1.0
From: 
To: 
Cc: , ,
        , ,
        , 
Subject: =?UTF-8?B?UmU6IFtQQVRDSCB2Ml0geGVuL3hlbmJ1czogZml4IFc9MSBidWlsZCB3YXJuaW5nIGluIHhlbmJ1c192YV9kZXZfZXJyb3IgZnVuY3Rpb24=?=
Content-Type: text/plain;
	charset="UTF-8"
X-MAIL:mse-fl1.zte.com.cn 55L6BE2X044176
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 68564D10.000/4bPP9r0htLz8R044

> PS: Next time please don't send another version of a patch as a reply,
>      but as a new email thread.

Got it! New threads for future patches - thanks for the heads up.Sorry for any inconvenience caused, 
and thanks again for your patience with a newcomer like me.

Best regards
Peng


From xen-devel-bounces@lists.xenproject.org Sat Jun 21 09:58:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jun 2025 09:58:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021547.1397499 (Exim 4.92)
	(envelope-from )
	id 1uSuzN-0006zY-Br; Sat, 21 Jun 2025 09:58:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021547.1397499; Sat, 21 Jun 2025 09: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 1uSuzN-0006zG-6U; Sat, 21 Jun 2025 09:58:21 +0000
Received: by outflank-mailman (input) for mailman id 1021547;
 Sat, 21 Jun 2025 09:58: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 1uSuzL-0006z7-7E
 for xen-devel@lists.xenproject.org; Sat, 21 Jun 2025 09:58:19 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3fd7e9d8-4e86-11f0-b894-0df219b8e170;
 Sat, 21 Jun 2025 11:58:15 +0200 (CEST)
Received: from nico.tail79467d.ts.net (unknown [46.228.253.214])
 (Authenticated sender: nicola)
 by support.bugseng.com (Postfix) with ESMTPSA id 5F2294EE7BD6;
 Sat, 21 Jun 2025 11:58:12 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3fd7e9d8-4e86-11f0-b894-0df219b8e170
Authentication-Results: bugseng.com; arc=none smtp.remote-ip=46.228.253.214
ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1750499894;
	b=ptiyWAR0f5LcQyHKM6LGbCcUF2JywoM8ZfUA/66KmAatpvcL2OQeY0H9H8t3qbWnbb2L
	 hKDRgsk5ADephf3Fjv16nIerXLJ0ISXRqwpGCy5zbUqOfhRtCJ5Lqn2rmZ+llSIdlObSe
	 KJEBrNZwPdqcqfeqS4ZeBxukK2ITlr+mGMAF7VgHMMHtDuz6FRJ5rl+invX+pvxD6Zpm0
	 fP5wHdCIqPwjA6IqVpxuI84zP1j/dU2Iaz5z7zVPx+kkDWj3Wq3s/BLzSeadc+RNpNF1F
	 YyEr12HrqyZii4nVPsbXIVg+xKi6hwT4u8p2ZLVl/9B0XTfBSTd+1PiIlouSaeIlqMDVF
	 BvyFkS2hjiordl1F4OxB4pfcwzXBrTMFB3+MbMbaWZMdQ/5XHeekfPQJMN9Wtj9iccWvL
	 4rUkOJ+q3x3dE5rEQMSsgpQMw/a7mZiajlWXdr2ZaYzq23bw8HveXxyVggG4Qig6L4yOK
	 jHxBUvlKtiFTGym8WYF3SDP1+q+Q0vqV70ALSsLuXNXeEpbON5/1uN3Kf6i+r340qTqsY
	 VtOAofKmB8/vcMygqCaWIGOnJ59pqwkxkYt75K1W76zf3cL55QaHtIfrZsMsyCJe+bApC
	 45Tz1JU9eNsSAtuaj9PKtkM355wWY9xp8+UiwbvPTwO5zkQxQ5fhCWXqqd6c+Aw=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1750499894;
	h=DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer:
	 MIME-Version:Content-Transfer-Encoding;
	bh=OFSOmi8snwtzjR1JiY+zoRSsRqb/PHEtC2Dj2pBIVmY=;
	b=qURVONWblprb3cBbFc6x5HirHGCj3/jkozlxVnQiTZOwmMP1uuyIy1vY8hitH77J7MFd
	 48iajO4CgQ+2kKfp02hvbWH5LzdYPU+uSSyV3MNRcW6xIrtgfFPBUC+j6ll14T6ZmtqMX
	 dhnEa5TMHpOxCHKrM2mmwrIlXxyfoTGxCGWOMUPEeVfDJi3Odrap7TqK/fdHXl2HJebcm
	 rdlKxORv5i+Ju18/a/V8NDohhfIp1FjAhswGLAai8Kd2yweD3V6u6J+ucAJbQi/EKFwYP
	 Qi0kREgVgL6SBPrfOztqLmPKrUC8EET+A1hOji9KpaIBtGm8Sz2bJf3+WgMI9GuaNKQ2z
	 AbJMp5NSPnFSahHplRnF740t5boxYFsj89KHff2K8dbX3qQLhEQ5O3SVpFQGk6O099Qm8
	 hNc7LKiG7VXz5atclpMEVojsVDdMpYHqeIioowh8ibxntUyYPpDnehmXzCwxER9tAFvIR
	 Su+Pr6P6rPgAH7BX0vWe7sAhuDb4qb1vs88bjD9sijuAl6RDSBhtzjoHTiAvhcVGX5c9u
	 PqyL6j3b6SJ8UOQf7WxZvCHltfIyhSKrBZ6yxHX7gM49Mi/FF96n8q4Pw+q8A2KgUOiWb
	 uO8bXQNSP33T/DaD8j42uyIymNkUkj3F670BJDSrnqx6V00jDrghVKe+m5Ap5zQ=
ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=46.228.253.214
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1750499894; bh=Fz1qUwXURQRnqQxAGnDuD4Twc2/+DOttlbQ6xdIUBMk=;
	h=From:To:Cc:Subject:Date:From;
	b=SeQEnea/1dxF3wEw71yr3uC6qGX63VjiFMqsY+UvVCU+3UtFO7hvFr+mBo5Y32lNq
	 qgrlA9s4kpdSiL8KU5OWcVLft20zrmGVsJiUkJHpSSx8+/25PZxzXULnY7T6ia1HqX
	 iBVBxaETnQLvL67Zg1+cSKV5SfAnQymrzfLvDCJ3SuHSbtays8+CtX/x3TARpOVDY+
	 7V7njQ9+q/m7Ljyro8NdbxWcKJxO6GkAQ/o+EKjeUqmL8DKIUJKV4JOi0OnqnLUbb/
	 IYIH6ZwnHM8OnjBrcr77du7j24yfJWsVKeN4+oCWhC4EDHk8PByRcS2X7wHpw8CS0W
	 kV2Gd4Bl1dkwA==
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 ,
	Andrew Cooper ,
	Anthony PERARD ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [XEN PATCH] xen: fix header guard generation for asm-generic headers
Date: Sat, 21 Jun 2025 11:58:08 +0200
Message-ID: 
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Dashes were wrongly not translated into underscores, thus generating
an unexpected guard identifier.

Fixes: ee79f378311b ("xen: add header guards to generated asm generic headers")
Signed-off-by: Nicola Vetrini 
---
 xen/scripts/Makefile.asm-generic | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/scripts/Makefile.asm-generic b/xen/scripts/Makefile.asm-generic
index b0828018080d..f6850758c54b 100644
--- a/xen/scripts/Makefile.asm-generic
+++ b/xen/scripts/Makefile.asm-generic
@@ -34,7 +34,7 @@ unwanted    := $(filter-out $(generic-y) $(generated-y),$(old-headers))
 quiet_cmd_wrap = WRAP    $@
       cmd_wrap = \
 	arch=$$(echo $@ | sed -n 's:.*arch/\([^/]*\)/.*:\1:p' | tr a-z A-Z); \
-	upper=$$(echo $*.h | tr a-z A-Z | tr '/.' '__'); \
+	upper=$$(echo $*.h | tr a-z A-Z | tr '/.-' '__'); \
 	echo "\#ifndef $${arch}_GENERIC_$${upper}" > $@.new; \
 	echo "\#define $${arch}_GENERIC_$${upper}" >> $@.new; \
 	echo "\#include " >> $@.new; \
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Sat Jun 21 14:30:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jun 2025 14:30:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021587.1397509 (Exim 4.92)
	(envelope-from )
	id 1uSzEU-0004zZ-Lg; Sat, 21 Jun 2025 14:30:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021587.1397509; Sat, 21 Jun 2025 14:30: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 1uSzEU-0004zS-Ih; Sat, 21 Jun 2025 14:30:14 +0000
Received: by outflank-mailman (input) for mailman id 1021587;
 Sat, 21 Jun 2025 14: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 1uSyzJ-0002tA-1Q
 for xen-devel@lists.xenproject.org; Sat, 21 Jun 2025 14:14:34 +0000
Received: from OS0P286CU011.outbound.protection.outlook.com
 (mail-japanwestazlp170100001.outbound.protection.outlook.com
 [2a01:111:f403:c406::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 089199ea-4eaa-11f0-b894-0df219b8e170;
 Sat, 21 Jun 2025 16:14:26 +0200 (CEST)
Received: from OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:10d::7)
 by OS9P286MB4122.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:2d4::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8880.14; Sat, 21 Jun
 2025 14:14:17 +0000
Received: from OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
 ([fe80::80f1:db56:4a11:3f7a]) by OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
 ([fe80::80f1:db56:4a11:3f7a%5]) with mapi id 15.20.8857.022; Sat, 21 Jun 2025
 14: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: 089199ea-4eaa-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=COW1xDwgiRrATilH8LwSqebecGB3N6IJk8Z/9KTBDV3l1tI+l7nq2s7WEkD2ESzqyQf5DlzmOgf8HO+6+ARGQyla+bAZFdzRi9Md3bT/CSJPc3GuioX4eLOGrdC4bU5XKkFyJfK1iHfaKaCAWhRIvZUgSo/B4obkqx3rj4ADcO3R9jcyj3l2t7x/fxI4TxN5sEtC9KJhUjbIgMVPzclphoWyPRxsZ+qCF3ssm7TVXw2g0YWLXDQDDNa1DBySCwBbZcD49zgyz8plSnjOcc57weU+IHk4b8TlFgSm4lTEeN1mxZc5tqAlcj5xiOwJE8FKBGmxtECw0nYn3k3OHoJmag==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=J9+f5/bj/zZHwsLt9rViwjBEk07emcS5iCST2DIr8n0=;
 b=yDJinfrrSkY0YHPlY3cQznJW4uhTNJZ8h4q/MQ7zuQ3BnqaqP9YanpyjGqljDleCB7I0jYs68vQQyMJC8mkpdE1ZxQio5+9COUyY4P+R79wFF+Wx7PbpuMVzOKdiZlc8PxVVAUEs/TvBpmSOuiYyy0K5ADY3I5bk8Zo4iQtlx3yPiBwKWPFp3nAz1ko+gKhR9yjOUDj8M4rQnadUnbkWxTLNDhHtKdcsjSMEcYUY2Y0ybdUNprRKY9Y+W+tBbUSeYBdwhLFaY6Yw2lpiJkFxR+4htd3Xgs+6cQsD+c0YvikS40Xs545WUeHb3l16eMEEQPWXpIjy2qWOaNk25RsPEA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=valinux.co.jp; dmarc=pass action=none
 header.from=valinux.co.jp; dkim=pass header.d=valinux.co.jp; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valinux.co.jp;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=J9+f5/bj/zZHwsLt9rViwjBEk07emcS5iCST2DIr8n0=;
 b=aS7D7BK4q6vYNvrYOqhWGH/7odobQFG8KjL0n43eVnJM/cAfxWELLnAENpG+SlLvdHhXwobKly6VGuk137W/En1dOSrsdaU7iZsTAovC3fvhEq1mMZLv8QRkYv8krP+uuwzk3wR7N9LM3IIy6LLA9VDmOXDeTcWTKFyOAOfE4/M=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=valinux.co.jp;
From: Koichiro Den 
To: xen-devel@lists.xenproject.org
Cc: dfaggioli@suse.com,
	jgross@suse.com,
	gwd@xenproject.org
Subject: [PATCH] xen/credit2: factor in previous active unit's credit in csched2_runtime()
Date: Sat, 21 Jun 2025 23:14:11 +0900
Message-ID: <20250621141411.890250-1-den@valinux.co.jp>
X-Mailer: git-send-email 2.48.1
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: TY4P301CA0032.JPNP301.PROD.OUTLOOK.COM
 (2603:1096:405:2be::10) To OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
 (2603:1096:604:10d::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: OS3P286MB0979:EE_|OS9P286MB4122:EE_
X-MS-Office365-Filtering-Correlation-Id: e83cec10-a134-4e24-43ef-08ddb0cde81f
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|10070799003|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?Q/ZsOZq0PKQ1PIMMhivzoJRKS/Al5D1fuv7S+sz+BxbFdYFCkrz4Y6RVA6XS?=
 =?us-ascii?Q?PZcL5zV1INogytnWi+zakUng0nP81yp8zeZLu69VWaPRKPus/DZHTcS6Ga5h?=
 =?us-ascii?Q?xQn/kgCV/ZJNV2Mk6MQLOevdJzryzk6Vkm1UjxAifmUgOItXgmbNJveqqO9s?=
 =?us-ascii?Q?JUr78yzeE6oxljpcrTgZbv2oo35EICapsabVaT9K3EGPgn5nKJaR2U7Ffw4K?=
 =?us-ascii?Q?6hvD2wC+LMN5GyqI56WPtqqkC7HV+iPZ7cdqCpivnB/qQ+nish+jx0NbCVRC?=
 =?us-ascii?Q?tYXQtMZ8yl9V42/uHXOjLjE8Ov4dU6o+WJKyJL37nQNrOD+r0wicOgXYTMwW?=
 =?us-ascii?Q?QPDqX7iLBtsHUztbOoa9HvM47N/rcaLCWshgsAda/pAtYCpeme9mkQXPS8sn?=
 =?us-ascii?Q?tBHNcK8xxVmWRaJlwpd+Qp8Uf6gm1ZxUZW/DsTvtNBsev3cxxp2iENKjlkKj?=
 =?us-ascii?Q?osZVDzZ33BY5yjMIPLdthUs5+rbrT97naC4igIC4LZVtsZg2/zQKEb+pfeBI?=
 =?us-ascii?Q?YkF1KH8a0jX0Lr6jtbIEnvVDqOCYcQuOcjdvNJaYYyC/zl495faKwprr0OZb?=
 =?us-ascii?Q?7OK7/iMXoXxh48hZrXNgN8I0j+KmIlfQ8o5D6cdPLq84Sg1ouyOUNStAtrIB?=
 =?us-ascii?Q?CIeuezEMBmpJia6Kmv0WkkJBE7UBqieLgxf8a5Uq0R2k23U/IPGzATXAQwc6?=
 =?us-ascii?Q?ONtF4kwsbXOQqifmvU+Ail1oB6lgsKC3PrXhOfggLTWdbpj+FE7y/9xhsVOu?=
 =?us-ascii?Q?EE0YO1pOFJpFC22LY0Om/T3w8q86z3VqdGS3kkE9S1Lpnzl8N3kfVYKCCsgR?=
 =?us-ascii?Q?7Z3SsArgDY6hlkoJH8+373pjxdtMIAoSXqGZmTUjkmiSTHwUMQCRv7diZgsb?=
 =?us-ascii?Q?/G3klkJLCIDilC/z1ZZs+PosolKQZOUik5jpeALHa9gz3Ucoo/THfRffX2Bu?=
 =?us-ascii?Q?PGhtKeQ3H3oCk8cDVDcnqo6B94RG59rrUlJMXUFnROYj5YDttfbf2JMQn47j?=
 =?us-ascii?Q?LTDrgxM/co0KA0BzsmhZXLkfdut9MEP4/GCS1dCdd0y6gJtgcugaHhYcMgZ1?=
 =?us-ascii?Q?He3dutSjQ7UWNdJz/tEPa5BDzL1ZU8cKdis1vcUFvWz9H6AgwT846W1P8LZp?=
 =?us-ascii?Q?HYde0WP5QQma8JK1EbJXVsHr/IGVmue/oLfsUexLuttzdFBk4i4psE0brfH0?=
 =?us-ascii?Q?2KySck8i9VjQImFHMQtufsCxtpq/6EqSjwxHxEQkhTMxR+6cLPB6gL+wjlGW?=
 =?us-ascii?Q?GujGviKrOap4KpiiRmDGp+KWZV3a/O+QAkERu1Y2CsXVBCN2qPQgI33RXaL+?=
 =?us-ascii?Q?ovFNeAlgT9wKKozu4ExA8olfFQSm6a0HIYex+e/TbeCjuUO2YDdSa8dAzpFj?=
 =?us-ascii?Q?tTOqcyaADm4+1Gn01DpkJX2z2TddxsdPU8gIOF/jw71wROQ0y6UaDN5doMl9?=
 =?us-ascii?Q?WsN3oi10s4A=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(10070799003)(1800799024);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?gpVOV1ibsZ1j9RG+L5T/+02lGukg6BbrlY3RKCtjK+nn0273xy87CfKrEiJd?=
 =?us-ascii?Q?S76XspqLoOtDx5BuCioqeTeiufj16Kvd6TJO4bOOrDJr0eiy3u0ys5Yqrc93?=
 =?us-ascii?Q?SQpqp4EzoeKpNAM8VTMlWHSKjVZ/6g0F+wEdAYK+vq83a2w9ZbuMV8o827R6?=
 =?us-ascii?Q?bruPB8mBSTsHw5zgFVWiqnasxhS4itxY5QVrXlXRgkH1kxQM2OXAXCVI3gaX?=
 =?us-ascii?Q?9hjdKQCChMP1Y3vNh9rGf46WaHmZzgZmAfRhjnjpQ7pbJLbbZJJlnlJH6i2n?=
 =?us-ascii?Q?f/punuQ1+J11FCqwgdopMMq55EGhE0bp5yDwGgJacA+O+paz7VZikTmJyvqJ?=
 =?us-ascii?Q?wxhgcnP0GNOesjja2MlCs6DSdra7m5ndABWx0RvlLldfFq/Rx1clBZCbdOwd?=
 =?us-ascii?Q?us/6wlA0CR/IlVYYr9A51MdAUGJlCAq1Q6UILtsYKot9nqKEhSLbDdQg9Hm8?=
 =?us-ascii?Q?x1fdNROJCAdaMgfCgFWOWs6mdwMSBNIEnFmFTG3RXbRZR5gNeqP7OFOFgeLL?=
 =?us-ascii?Q?G5/v9j0qjnR7XRtwq2eyX6hDTQbWfvzIgdeUJWfvgKWrDQ8o9uXGUTJ0j7ov?=
 =?us-ascii?Q?SYCWLMlhEJfYAAuyl/y1lJFZBBTZquJw/uWEM+eJTJw46J+uBpUWSqOLSdea?=
 =?us-ascii?Q?dcqbZcZywFWa3ajLHpf7ufCY+IHBdYIyvuN/y6kgVYtLxUTVCfeh8W3oSWBr?=
 =?us-ascii?Q?Hg3x89AmGbKgBaI3SfzdnVnxkFQ+cF6WAE/etnmjk8Sae4mYV2o4m1RAPvm5?=
 =?us-ascii?Q?AF2JF6nc97nMDp14JvKy7GknzDWN/MKyoaIdyt5pkU6mqcid2m3HsH7ue8+n?=
 =?us-ascii?Q?Dd02h8Mfyn/TX5Hpu6feFZDh5sH++euXQCpp3EEmPNGsuYX+iueV8OFTwrgN?=
 =?us-ascii?Q?1gz9YwaHNFWAUIMwQfyH7SGxuMZMcqBlsj4kwAjrouCQbNL4bc0EygPLEUy6?=
 =?us-ascii?Q?uD9zgmSr5ulqC/O0kMthu5uJb1DWbv2TRNookKaPu7D8dTtUv4znpD3QkdYW?=
 =?us-ascii?Q?GP2DeaVlGaKeV+SPeQ4KKpS4ZmbCKpL7CIZi5z3hIXT93j9/RC2qiRolTRIp?=
 =?us-ascii?Q?VjLUCCVj0TkZgngz5Z/pmSeQI0C9ZH/baQ8/jdSvjAiauCiS0wpDmS+eJ5dL?=
 =?us-ascii?Q?VIwlF7tCGkkE6OLheatL63fYduVFyunJqTmhKU7ezuqu+gXYtYWnMAw5Fkmz?=
 =?us-ascii?Q?DLKlmy5QoGFtEQVuT8AM+n6ugXvf8V4ro6L9l/bcrgbbTIl8gsZl3lTFIGwZ?=
 =?us-ascii?Q?uLUMse9p29hIAp0gLjpiFPY7otd6Dq5dW6Svm5gTe7f2LFOAmPvo2TjmaZMM?=
 =?us-ascii?Q?q+oXZ7FjrGQkEdu04KdETrcX2Ey5RO/sNjyHSgxU0MSunJjTrF0TPG+kpTJg?=
 =?us-ascii?Q?x60FuSp1RVH3BmmUiw8m94LuUMg/oOB/LK+6va9EeBbE9t+ONJ2QXC5CZJ/n?=
 =?us-ascii?Q?bdP3n7KI0TFL17WQ6ofLCzmaJ+d4qk6dOpAtRLDNLI5Wwq+YFixAXWlO4gPX?=
 =?us-ascii?Q?RqW6wrkTJz9p0h9fgw8e27T6vzKCm1fVLjGEpQGxO/yFY+meEcWTMX3lYCbA?=
 =?us-ascii?Q?ooRzwK5Ff2l2eD1MsJeUdWuFZKp6/lgrSHb4kkoBZcBljTqvFwiehEeVVVWi?=
 =?us-ascii?Q?nS8wqBNHOuHHMqaFBbWgvGc=3D?=
X-OriginatorOrg: valinux.co.jp
X-MS-Exchange-CrossTenant-Network-Message-Id: e83cec10-a134-4e24-43ef-08ddb0cde81f
X-MS-Exchange-CrossTenant-AuthSource: OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jun 2025 14:14:16.7226
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 7a57bee8-f73d-4c5f-a4f7-d72c91c8c111
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: V5Iwl3eM3CdzU4/5ENCjP6imnkX6cEo5IBDaV9NwgBzYb6jWZs2NbfQc21fSC4D3XZkmYRR7jBvoYORKKVQXvQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS9P286MB4122

When a running unit is about to be scheduled out due to a competing unit
with the highest remaining credit, the residual credit of the previous
unit is currently ignored in csched2_runtime() because it hasn't yet
been reinserted into the runqueue.

As a result, two equally weighted, busy units can often each be granted
almost the maximum possible runtime (i.e. consuming CSCHED2_CREDIT_INIT
in one shot) when only those two are active. In broad strokes two units
switch back and forth every 10ms (CSCHED2_MAX_TIMER). In contrast, when
more than two busy units are competing, such coarse runtime allocations
are rarely seen, since at least one active unit remains in the runqueue.

To ensure consistent behavior, have csched2_runtime() take into account
the previous unit's latest credit when it still can/wants to run.

Signed-off-by: Koichiro Den 
---
 xen/common/sched/credit2.c | 28 +++++++++++++++++++++-------
 1 file changed, 21 insertions(+), 7 deletions(-)

diff --git a/xen/common/sched/credit2.c b/xen/common/sched/credit2.c
index 0a83f237259f..0b74fa3c5d0b 100644
--- a/xen/common/sched/credit2.c
+++ b/xen/common/sched/credit2.c
@@ -3278,13 +3278,14 @@ csched2_unit_remove(const struct scheduler *ops, struct sched_unit *unit)
 /* How long should we let this unit run for? */
 static s_time_t
 csched2_runtime(const struct scheduler *ops, int cpu,
-                struct csched2_unit *snext, s_time_t now)
+                struct csched2_unit *snext, s_time_t now, int inflight_credit)
 {
     s_time_t time, min_time;
     int rt_credit; /* Proposed runtime measured in credits */
     struct csched2_runqueue_data *rqd = c2rqd(cpu);
     struct list_head *runq = &rqd->runq;
     const struct csched2_private *prv = csched2_priv(ops);
+    int swait_credit = 0;
 
     /*
      * If we're idle, just stay so. Others (or external events)
@@ -3320,17 +3321,21 @@ csched2_runtime(const struct scheduler *ops, int cpu,
     /*
      * 2) If there's someone waiting whose credit is positive,
      *    run until your credit ~= his.
+     *    Note that this someone might be the one who was just
+     *    running and is about to be placed back on the runqueue.
      */
     if ( ! list_empty(runq) )
     {
         struct csched2_unit *swait = runq_elem(runq->next);
 
-        if ( ! is_idle_unit(swait->unit)
-             && swait->credit > 0 )
-        {
-            rt_credit = snext->credit - swait->credit;
-        }
+        if ( !is_idle_unit(swait->unit) && swait->credit > 0 )
+            swait_credit = swait->credit;
     }
+    if ( swait_credit < inflight_credit )
+        swait_credit = inflight_credit;
+
+    if ( swait_credit > 0 )
+        rt_credit = snext->credit - swait_credit;
 
     /*
      * The next guy on the runqueue may actually have a higher credit,
@@ -3582,6 +3587,7 @@ static void cf_check csched2_schedule(
     struct csched2_runqueue_data *rqd;
     struct csched2_unit * const scurr = csched2_unit(currunit);
     struct csched2_unit *snext = NULL;
+    int inflight_credit = 0;
     bool tickled;
     bool migrated = false;
 
@@ -3716,6 +3722,13 @@ static void cf_check csched2_schedule(
             balance_load(ops, sched_cpu, now);
         }
 
+        /*
+         * This must occur after the potential credit reset above,
+         * otherwise it would capture a negative credit.
+         */
+        if ( test_bit(__CSFLAG_delayed_runq_add, &scurr->flags) )
+            inflight_credit = scurr->credit;
+
         snext->start_time = now;
         snext->tickled_cpu = -1;
 
@@ -3756,7 +3769,8 @@ static void cf_check csched2_schedule(
     /*
      * Return task to run next...
      */
-    currunit->next_time = csched2_runtime(ops, sched_cpu, snext, now);
+    currunit->next_time = csched2_runtime(ops, sched_cpu, snext, now,
+                                          inflight_credit);
     currunit->next_task = snext->unit;
     snext->unit->migrated = migrated;
 
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Sat Jun 21 14:39:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jun 2025 14:39:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021599.1397520 (Exim 4.92)
	(envelope-from )
	id 1uSzNZ-0005fh-Eo; Sat, 21 Jun 2025 14:39:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021599.1397520; Sat, 21 Jun 2025 14: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 1uSzNZ-0005fa-9y; Sat, 21 Jun 2025 14:39:37 +0000
Received: by outflank-mailman (input) for mailman id 1021599;
 Sat, 21 Jun 2025 14: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 1uSzNX-0005fU-F4
 for xen-devel@lists.xenproject.org; Sat, 21 Jun 2025 14:39:36 +0000
Received: from gw4.antarean.org (gw4.antarean.org [136.144.238.64])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id 8bdbaa62-4ead-11f0-b894-0df219b8e170;
 Sat, 21 Jun 2025 16:39:33 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
 by gw4.antarean.org (Postfix) with ESMTP id 4bPcS46gdZzNnCS
 for ; Sat, 21 Jun 2025 16:39:32 +0200 (CEST)
Received: from gw4.antarean.org ([127.0.0.1])
 by localhost (gw4.antarean.org [127.0.0.1]) (amavis, port 10024) with ESMTP
 id e8aScyt8RL1V for ;
 Sat, 21 Jun 2025 16:39:32 +0200 (CEST)
Received: from mailstore1.adm.antarean.org (localhost [127.0.0.1])
 by gw4.antarean.org (Postfix) with ESMTP id 4bPcS43vp0zNkdZ
 for ; Sat, 21 Jun 2025 16:39:32 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
 by mailstore1.adm.antarean.org (Postfix) with ESMTP id 4bPcS434Txz1G
 for ; Sat, 21 Jun 2025 14:39:32 +0000 (UTC)
Received: from mailstore1.adm.antarean.org ([127.0.0.1])
 by localhost (mailstore1.adm.antarean.org [127.0.0.1]) (amavis, port 10024)
 with ESMTP id qOKc3lwMqd28 for ;
 Sat, 21 Jun 2025 14:39:32 +0000 (UTC)
Received: from persephone.localnet (persephone.adm.antarean.org [10.55.16.48])
 (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 mailstore1.adm.antarean.org (Postfix) with ESMTPS id 4bPcS40BHsz17
 for ; Sat, 21 Jun 2025 14:39: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: 8bdbaa62-4ead-11f0-b894-0df219b8e170
X-Virus-Scanned: amavis at antarean.org
X-Virus-Scanned: amavis at antarean.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=antarean.org;
	s=default; t=1750516772;
	bh=BOfW3GpKIf/U0nZqm9q2J+6mX9tIalYI/xyewp3VoBo=;
	h=From:To:Subject:Date:In-Reply-To:References;
	b=ND/Rz1zsZghHiks8kNzIxo3S8GVGCZVt6HkAX1gcXIAhvUHYvoA4NhDhj38LKhkqn
	 srg4bgoDxTdlBUy74MRwGwv2Q5xZfZcXTPGh3sxhLTDFQ/aPWi4RrkszUKixs/uChw
	 FKL8/e5PTPlw4IYcO9JyQ4CiBiQj2hvSLHidLTBY=
From: "J. Roeleveld" 
To: xen-devel@lists.xenproject.org
Subject:
 xen_pciback: error enabling MSI-X / MSI for guest -- WAS: Re: Kernel panic
 when passing through 2 identical PCI devices
Date: Sat, 21 Jun 2025 16:39:31 +0200
Message-ID: <4683544.LvFx2qVVIh@persephone>
In-Reply-To: <2226691.irdbgypaU6@persephone>
References: <2226691.irdbgypaU6@persephone>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="utf-8"

Hi all,

I managed to get past the kernel panic (sort of) by doing the following:

1) Ensure system is fully OFF before booting. A reset/reboot will cause these 
errors.

2) Fix the BIOS config to ensure the PCI-ports are split correctly. If anyone 
has a Supermicro board and gets errors about PCI-slots not getting full speed 
let me know.

Not entirely convinced the 2nd was part of the cause, but that's ok.

I now, however, get a new error message in the Domain0 dmesg:
pciback : xen_map irq failed -28 for  domain
pciback : error enabling MSI-X for guest : err -28!

For the NVMe devices, I get these twice, with the 2nd time complaining about 
MSI (without the -X)

I feel there is something missing in my kernel-config and/or domain config.
If anyone can point me at what needs to be enabled/disabled or suggestions on 
what I can try?

Many many thanks in advance,

Joost







From xen-devel-bounces@lists.xenproject.org Sat Jun 21 15:12:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jun 2025 15:12:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021613.1397549 (Exim 4.92)
	(envelope-from )
	id 1uSztF-0002ji-Bt; Sat, 21 Jun 2025 15:12:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021613.1397549; Sat, 21 Jun 2025 15:12: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 1uSztF-0002jY-91; Sat, 21 Jun 2025 15:12:21 +0000
Received: by outflank-mailman (input) for mailman id 1021613;
 Sat, 21 Jun 2025 15:12: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 1uSztD-0002Hn-PT
 for xen-devel@lists.xenproject.org; Sat, 21 Jun 2025 15:12:19 +0000
Received: from OS0P286CU011.outbound.protection.outlook.com
 (mail-japanwestazlp170100001.outbound.protection.outlook.com
 [2a01:111:f403:c406::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1f7344c5-4eb2-11f0-a30e-13f23c93f187;
 Sat, 21 Jun 2025 17:12:18 +0200 (CEST)
Received: from OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:10d::7)
 by TYWP286MB3033.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:2fd::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.22; Sat, 21 Jun
 2025 15:12:07 +0000
Received: from OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
 ([fe80::80f1:db56:4a11:3f7a]) by OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
 ([fe80::80f1:db56:4a11:3f7a%5]) with mapi id 15.20.8857.022; Sat, 21 Jun 2025
 15:12: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: 1f7344c5-4eb2-11f0-a30e-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=icUGjXtiuEIQWDs7ZNQTRC6lj0pAS8KSXQCkYoJpRFURr+DdxMFVgc8Hw3uxNp28Ow2Q7CBsCUEctZ5L7VqU42CTC5Ox0FJwSwY93D6jbfWg0/Avy5ibbTG/P03VBusyFUzWzW57PeuwZ8vgqDXa+qljXXHzjo/sEYu0yuEeoSNjkfF+ZHca3l2mGXnfWZxmtdA8hd8+kv+T4WvB+g3hA7PQ/YFfimjpJa23RBBRVCgScULS5Ma70ARxwrbRiSlr3HA3f99tWxjIM4aFAvvxQJR1CVpqNRnM4CwuykoGnq13vfczvel55Qj6KMJdqzZpIiM4grUxBlXiEduAf6kqhA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=+MTRKS4LIBD1d3y/wd6/073T7aCD7eLmJnu+IO21Bv4=;
 b=V4JBInPtutYT1hH0Zh8F0UngZgK8MKOn+Ld2Ux3SFqV8X/lHqL8zyb1ps80bbfmwpYmLDrmUXxPaEzZqh/9e8moBi0rRaTcDMxrbJDPxT0KQjoj7KdWXNLlcMCRYrqczZYgopXOtjga0uplP1g2wG5qzUKrPzRWnJPL76hiWvNMecGJqtnyLE358AOs5uPxoghuA27q/a6aq2WAui+1h3Dzc2qGIGu+iwNUx+q7y0jRnbJBKhTJG3h63rXRmRc4IC1+KJDBz+io6zW0yDJu6+m2c8H+C82Kp3X6SPOenTR5POpjh/nqy09aAO8ppjNKHL6CnYA0I3OxH/HT19NKXTg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=valinux.co.jp; dmarc=pass action=none
 header.from=valinux.co.jp; dkim=pass header.d=valinux.co.jp; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valinux.co.jp;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=+MTRKS4LIBD1d3y/wd6/073T7aCD7eLmJnu+IO21Bv4=;
 b=e31T/2WIHtpVeVu5G4RwnqwsTfYuj+cSct5VYNJnWr3d9ORTGFhMDMlXsupEnAp9Xmw56m4rMWvpQ3aP5oSj+qmKEVVL5KvA+Fo/kdi+HFC9htzGhshPhuKwx3cYOti0LzWu3PTvUoP15w79OEe5jJkS7RupJPNdkgw5xbtUD0c=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=valinux.co.jp;
From: Koichiro Den 
To: xen-devel@lists.xenproject.org
Cc: Koichiro Den ,
	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: [RFC PATCH 0/4] arm: Implement ARM DEN 0057A PV time interface
Date: Sun, 22 Jun 2025 00:11:57 +0900
Message-ID: <20250621151201.896719-1-den@valinux.co.jp>
X-Mailer: git-send-email 2.48.1
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: TY4P286CA0014.JPNP286.PROD.OUTLOOK.COM
 (2603:1096:405:26d::8) To OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
 (2603:1096:604:10d::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: OS3P286MB0979:EE_|TYWP286MB3033:EE_
X-MS-Office365-Filtering-Correlation-Id: 08ef7678-0d11-4c3a-eaa2-08ddb0d5fbd8
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|7416014|376014|366016|10070799003;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?PLfFKqjtlNgzpIoK81PjBlkgF2a4nWrDvS17wGyIFOmp6tHHr2H9pYr5qTSL?=
 =?us-ascii?Q?qHA52GtVe1IlGLyl39vhc8FMnh45J/3jJ7PHMH1t2TxkqBETE1Jrkbin8NH5?=
 =?us-ascii?Q?fj85MxZN2wXC5+vYSpNATHEGfYmAHQwvOuKJshz0ZhcnrbXGJtGzi+oS7JkJ?=
 =?us-ascii?Q?oJWYiJYDn/kOG3pdrXpN6AKLlfVh0OZ/NaW9pgmOLE2FBQoe5xc4qzyt6LAT?=
 =?us-ascii?Q?9Q2ExUq/HZIktf5uZHaNIe0VIecrtAZPTY/pkBe0fUnQ/OydtSvIHAwhZM63?=
 =?us-ascii?Q?0fzDyxMlookbEUnM3L/APSnVFV6+VLruF6Zdkxn2Rb8EatOBN1TGFT5aF2Ns?=
 =?us-ascii?Q?UOeRd2mK/hQdbb0AMRdSew6GzLmYh3uT98qricBfPZn5OnIi++sJMp7zSDsz?=
 =?us-ascii?Q?KJUqOs8YNOxL7j4tchkun1oCPkpTpjxFhy8ZQEkSDi/e7T9x6H2U2oU70s2z?=
 =?us-ascii?Q?2Q73EonCBptPUtnBOVuj1bXk0XmxDYtq29/SMCZQ286qieha63zUQS6h0ndP?=
 =?us-ascii?Q?sAe48ARUx8VaWpJ277TuBRMAslPosPMLez0Ft1RzN7PWDX2Aw0Zy0WuJp6S9?=
 =?us-ascii?Q?7ET0Ffr0K9MN4OPYaxQpyPaxRK60ffDuNgPOv/N9QpBl7+ziaVu9TP5crku8?=
 =?us-ascii?Q?0/xMGxFYa54+Ym0ru0qHhg8ASFNvz5fyH4bxJx4R9r85TjJGd2AjbaS9TUdy?=
 =?us-ascii?Q?sBH8yWvD4kXm5Gf9ex9qLB2zm2CkTfrHWHsTq8AFfhUXE+lbr3TZ7kzGUsBi?=
 =?us-ascii?Q?ZFuyb+PTbMfFHJsAMY8To+I9trSylLjySJ12vPXQMjebsG7N1lUPevfe5UKy?=
 =?us-ascii?Q?wkBQEEy4fBFgY4GAmnWAw3dWM1YrSBd5UuyUi7WDLqBfBRDVd4YZei3dAT0N?=
 =?us-ascii?Q?IJFMcIRuWK3f55j9NxsQFJbz81cIEfi4iGu+v+ZWVl5KDsF5iFrXQg1s28ct?=
 =?us-ascii?Q?deqPtOtQ2PsEdaS2swxz3zNwRI1BDgJS8KRU20rTilspFHzptqvcLw7P+DaO?=
 =?us-ascii?Q?+bUWnRU5eqleboRrl91eaSpfdlT3mvQqzJYOS/w0V9Dx8MdxFnkKAsdX3Oo1?=
 =?us-ascii?Q?RFIH+XXpMyZ2sldtU3APppO4XKr0WHySPqUkEAPgkihPMP3SIO3CZdsaIegj?=
 =?us-ascii?Q?0anoPYweEEFL40gRr/rHWUYi3mhR4pCGBHy3OXOQ5LjNVRUJ0+pj4HtrUT6J?=
 =?us-ascii?Q?k5M9ut2U1OMIl5HG42s/05UGnDpGBRqQlRaguBditvVb3zmqk5RDyoV/jw/e?=
 =?us-ascii?Q?mcQVB2iyYPaaHxI3G0Z7ZjKHB9d+I3/F7YRRrV9ZvAQRLIva1zMzEmGN/tw5?=
 =?us-ascii?Q?XZg66tVAHy0etUSAV+mDXX0lNYdflLph9etVfUF8wjYhasUInqUX4Gfi5W6Y?=
 =?us-ascii?Q?dk9Dv0o2nWlNz4e8e1/GBHbLK014y1mxR/P3dH+b3WnN48SYT56vbQZFwY8h?=
 =?us-ascii?Q?9qKw2U8ptK8=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(366016)(10070799003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?jo2KcngFHMU/2deAFH1jSCU4PaO4K3h+SHRt8SVtT+T4L5yQs+hlmXIVa8vq?=
 =?us-ascii?Q?Dwx0ZXLLnwb+hUeHviiy4Krz4c3BMuLTe6NiY2/jvFgEXoPzrzmsJirrzllM?=
 =?us-ascii?Q?txTnv10mwvAL4V8np3GK4qZjzqfjZeiVQmULHSQDpzcj6xGjuZOMTkFsMwDB?=
 =?us-ascii?Q?VeyVVoDsnNZwXKNa1FXQBfWMVbkweA+sYzQxcv44L+b8qhgllGgBWj+pQ1RL?=
 =?us-ascii?Q?rUnXA4ygTnq34OPcgElLb+VH/qly+U6ug1IITX/8GsLrfO/cylftp+MUEKE1?=
 =?us-ascii?Q?AsToxKLY6K6EfXOZ+xqpadhhP6flzjg6f1QkIbY1m79DDmZnsFr5X5B80kSf?=
 =?us-ascii?Q?FNn5pS7+p9YPFAvuMmqyakYIjQ1j6KdXaJ77HuoPjPn6qUBR2YWRrUURP9P3?=
 =?us-ascii?Q?/5UXakyGcfnfSgfg4nC/seU7x8XWO3SyTnxLpOSo4/4FNNFM8M7Awlixi862?=
 =?us-ascii?Q?fhTKA5vf1ozAB1LbCgkT2r+Iufs/IATLLoXT2Y0zq90s3BjY/5i2UkoFcbfB?=
 =?us-ascii?Q?EGLdPDAhaFoHaajucjEPNBgHSF4u9WYsRHuLikn44nIWndyNK51LRP0x9GkQ?=
 =?us-ascii?Q?gTBM8tlxgk54//c+YBTSzgOigSZ8N/A+FMdzpAishmW2xesUEc/0wgnRQT4v?=
 =?us-ascii?Q?ZHNl3mY3fuECBGIp9YSY/tusk3JsKm/ribf/HlSpFS1VmUWxDsy57A9MYbf3?=
 =?us-ascii?Q?FZtlXYm8njsSwTBbV4Fwg82Js0+UXBiQYaXpf4dKxj940PCiRhZxvrikcoLm?=
 =?us-ascii?Q?51Nkh3XXUQ4/vWh/uRj/DOT8W3r4melhXdQGbYOf3BBlxbUCewIfqccK/dos?=
 =?us-ascii?Q?9kfIWo2kBQmBGzfctFy3pXFBgeBTzDM6f4nxFDeYMxxUkWW7BYHHRIxpimED?=
 =?us-ascii?Q?bzsPK5VNaxq7Yd+UgzZV0ifQ1LdI0m3gP3VcPuXyAm98BJe2ImFUg16xGF4j?=
 =?us-ascii?Q?0GwxMDm3DpL32WvOergVQLdvkwgcKh1r4z+4Ed1wuGoZya+GcRXl2Ge9HTYz?=
 =?us-ascii?Q?wyEj5Sg2wi0jUHIFYkQKtLIjd64dfsNPFMv9rNz4Dz5z613R2Y9MD9rvj5jo?=
 =?us-ascii?Q?qmj7bsDbg67jLbIJf4sxkoobPqF1COvsZuUV2HE8VkwKV12enEYFXoJHGYgM?=
 =?us-ascii?Q?YoBR391qR9wIlYJRWFBsFch56KTcf2QjlTBGIT1XfANw2vcdAZmA6SnNjhSk?=
 =?us-ascii?Q?zX+9ZJJrnD85NGQgQYva8iFx0+kpXwD+nW8EptLyT0VtoPjAdqBpXQnIPKah?=
 =?us-ascii?Q?+b4LMtzX7Hcnguo/XmBXxGV5Vi0s/8+mSu7+cIt95XVEQYgDHK5sWVY9W1dv?=
 =?us-ascii?Q?3+slYkE8sj5Prkc3Wmz0Sj44yEd7+N9O2Hiebq4TVQIJWfvFteEeCFv7OjkV?=
 =?us-ascii?Q?D14Pw65ggpo8SMgaEtc2bqKjavIrYjmxrLDjW6VUWnNqYHRb59dFfdY1BwtR?=
 =?us-ascii?Q?U2WBai3f+vQ6QA95T/jvsZJhmdpCWKUHH4o8p5RyzOaOQn6NWxa9M5pKHbxn?=
 =?us-ascii?Q?0755Qn+Kh9ketmsLadzPQ+USKkMzqdlKjNctYD95EzQjHOjzEMoemWNTxAAR?=
 =?us-ascii?Q?Gi2xc7COsBALdTOGuPhgoYVu0+ESZ9R7AXA5T7i1wMxdVa1elftwwc+Rsm6T?=
 =?us-ascii?Q?wpDPgKbcaBDUFIEPH0UgEEw=3D?=
X-OriginatorOrg: valinux.co.jp
X-MS-Exchange-CrossTenant-Network-Message-Id: 08ef7678-0d11-4c3a-eaa2-08ddb0d5fbd8
X-MS-Exchange-CrossTenant-AuthSource: OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jun 2025 15:12:05.7608
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 7a57bee8-f73d-4c5f-a4f7-d72c91c8c111
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: tMq9d9E6YakirFZJySXyUdu97s865kG9jePhk/rXBY36dUEwAYWY3cDuLX907Sfy9u2tS5qm1cCdIDF/vd7CZA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYWP286MB3033

This series proposes the standard PV time implementation as per ARM DEN 0057A.
The first three commits are preparatory work, where no functional changes are
intended.

The motivation:

  The VCPUOP_register_runstate_memory_area hypercall is still actively
  used, e.g., in the Linux arm64. When KPTI is enabled, the area was not
  registered from the beginning due to the VA not always being valid. In
  such cases, Linux could fall back to using the standard PV time interface
  (ARM DEN 0057A), but this interface has not been implemented in Xen for
  arm64.

  Meanwhile, the VCPUOP_register_runstate_phys_area was introduced, though
  it's unclear whether this would be used in Linux arm64, nor when it will
  be prevalent amongst every possible downstream domain Linux variant even
  if so. And of course Linux is not an only option for the Xen arm64.

  Therefore, implementing the standard way of sharing PV time may be
  generically beneficial, reducing reliance on specially crafted
  hypercalls, the usage of which by guest VMs is not always guaranteed.
  Note that the PV_TIME_ST interface communicates with IPA (GPA), not GVA.


Koichiro Den (4):
  xen/arm: Add wrapper find_unused_regions
  xen/arm: Move make_hypervisor_node()
  xen/arm: Move make_resv_memory_node()
  xen/arm: Implement standard PV time interface as per ARM DEN 0057A

 xen/arch/arm/domain.c                   |  30 +++++
 xen/arch/arm/domain_build.c             | 168 +++++++++++++++++++++---
 xen/arch/arm/include/asm/domain.h       |  17 +++
 xen/arch/arm/include/asm/smccc.h        |  12 ++
 xen/arch/arm/vsmc.c                     |  38 ++++++
 xen/common/device-tree/dom0less-build.c |   2 +-
 xen/common/device-tree/static-shmem.c   |  40 ------
 xen/include/xen/fdt-domain-build.h      |   2 +
 xen/include/xen/static-shmem.h          |   9 --
 9 files changed, 248 insertions(+), 70 deletions(-)

-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Sat Jun 21 15:12:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jun 2025 15:12:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021612.1397534 (Exim 4.92)
	(envelope-from )
	id 1uSztE-0002Jt-5C; Sat, 21 Jun 2025 15:12:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021612.1397534; Sat, 21 Jun 2025 15:12: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 1uSztD-0002JS-VC; Sat, 21 Jun 2025 15:12:19 +0000
Received: by outflank-mailman (input) for mailman id 1021612;
 Sat, 21 Jun 2025 15:12: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 1uSztD-0002Hn-1Q
 for xen-devel@lists.xenproject.org; Sat, 21 Jun 2025 15:12:19 +0000
Received: from OS0P286CU011.outbound.protection.outlook.com
 (mail-japanwestazlp170100001.outbound.protection.outlook.com
 [2a01:111:f403:c406::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1ee9fc84-4eb2-11f0-a30e-13f23c93f187;
 Sat, 21 Jun 2025 17:12:18 +0200 (CEST)
Received: from OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:10d::7)
 by TYWP286MB3033.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:2fd::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.22; Sat, 21 Jun
 2025 15:12:09 +0000
Received: from OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
 ([fe80::80f1:db56:4a11:3f7a]) by OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
 ([fe80::80f1:db56:4a11:3f7a%5]) with mapi id 15.20.8857.022; Sat, 21 Jun 2025
 15:12: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: 1ee9fc84-4eb2-11f0-a30e-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=E1BxLef7LVRWI6ip8AZdslSIgOJwKd9CyRVy54r3S0HT2611z56a3YOYYmKpeNi3AJXUc5tMJhIUDXZq2EVt4GYkMhB//ntuJ4r3LQwzg0g+RO/6wLWBO1bZZlxvCIPN2CjDa85Dn8Rko/U8KkTKjiDu08iyWhMxR0cfutQPSps9VKSRZ1EB42THbhvvEdDV/RxrZ5c8q7H1I3sRojXGX1uAhK2GU0VFR0E7eFWec65Ryl3WFIk951oC8Im1BmV+/6JpAATamHM6I+xJbgwjc9HBUHvvwq74huLjdPC7FOg0k0giQMob4Rbe/ZhHjbaSkiWl2e0ekbDF55kcs+V4Hw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ZzEqMguDXik+OUbkQR4RTQfJmvwdGVxoIrMJVs4Ffn0=;
 b=o9UxXJ/2qRKq9Cb9bG94NUB87nl/G302ZWytSEfw4BXvPHRLbY55hDCeo2o/Kg5NjBTeIhH/tBoy59pXf9nBtSbb4cf71pmSFWvdpXy52saRgaADpkf2+9QB1OGdc3aY/BZLdd+bD+F2T0dDcWo7a8ml7HWivMd55CdpstKpjJ517oWsBRDX8k7rxuKa3Nk8LWSbul73HV36GrgJLEcWK99127URX3es/gYR9+0h3AMr8X2aW9yXUlZx/mb5Vjv/iDCEk8mznf8pVQ2uy7GpS6B2sWwsf6ilnlwggAKkMTzO1tr06Wp+GFFQDI3GRBNo7U/0FKruvEf+g+moOQTc8Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=valinux.co.jp; dmarc=pass action=none
 header.from=valinux.co.jp; dkim=pass header.d=valinux.co.jp; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valinux.co.jp;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ZzEqMguDXik+OUbkQR4RTQfJmvwdGVxoIrMJVs4Ffn0=;
 b=LVmtatB5pLtahgirZJp961Vo+zoNCfEZKikw1x+NEsv3M/5RM9bWnqdv+4PzOk20tTOVwj3YBRC2JLjXjwVJnAoiDuYVEgY7KChNwY287itMgXMjbZGIEJKQqXrSRd+4sZzhzI6CSBvGRDGqSY8ZBZW78i2RMJ8aM3c8XXNF5RU=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=valinux.co.jp;
From: Koichiro Den 
To: xen-devel@lists.xenproject.org
Cc: Koichiro Den ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [RFC PATCH 2/4] xen/arm: Move make_hypervisor_node()
Date: Sun, 22 Jun 2025 00:11:59 +0900
Message-ID: <20250621151201.896719-3-den@valinux.co.jp>
X-Mailer: git-send-email 2.48.1
In-Reply-To: <20250621151201.896719-1-den@valinux.co.jp>
References: <20250621151201.896719-1-den@valinux.co.jp>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: TY4P301CA0019.JPNP301.PROD.OUTLOOK.COM
 (2603:1096:405:2b1::13) To OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
 (2603:1096:604:10d::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: OS3P286MB0979:EE_|TYWP286MB3033:EE_
X-MS-Office365-Filtering-Correlation-Id: da6b9d95-a852-42ee-72e8-08ddb0d5fe49
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016|10070799003;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?QJgK6wI1IR4fvJwKOm95Yc7Ao7egDdTqhCnvD72QfloD3N5s8OnWekWOxthT?=
 =?us-ascii?Q?OIdQyUiPgsu8ze6ess4m4yrn//JOgVdMXnVLpyER4EjKE5YGXdDyBqxyz3qe?=
 =?us-ascii?Q?xCyCe2qkPSJvmJWlvmcXiYgcXXDKiGmpXSU0IWGcqopToq4Uggm2uwMM2tom?=
 =?us-ascii?Q?Y40r0DnEZYbKyXadn2JWc7MJ6Z3SWGCLqX/0WE0XKNCkNbxtkwkAZZtcFXum?=
 =?us-ascii?Q?wIV4mVOFGy9oQo863kAtSrePXk6PY5UuEKNQCO17d7A9YBJSgLCpAKpOZNog?=
 =?us-ascii?Q?HJAncLRhj/0ar2ImEc7Jp251FNIwdJ68aNkG/6TtNiafZpELf3yNPfQ4rxn+?=
 =?us-ascii?Q?4+p7tWLY6/QKOcxZe/kiQuCWysDsyTiR+whSSnZZt26qzKKeE4TdEfRLOKyt?=
 =?us-ascii?Q?LhkBDKJG7yVtYdwhHrhoeMkfSwuLPB0HO05A2svJnkyr2txKFcxxqMirjtE2?=
 =?us-ascii?Q?wPf7WdbhElHu4yQ1wtXl5FI10tYFmTr+Wt1ZngWe+Z2LEOTOYriUHFwmmcwm?=
 =?us-ascii?Q?dJnq3sdkD5Kyr0h4mxqPqZXsxhAknlgNdM/g4OsQSHiQOSiAVkCDd33A8zcX?=
 =?us-ascii?Q?pRKAMUgJVh/i+RbseNQ6z/1payh5xLJo9l6g1i+udSGP7kbxpXNfRP+k+iys?=
 =?us-ascii?Q?0wATX/x1ANzIP+uubu9KifJgu27JBHOuKG52xyb9MEGYp+qSi1e78H9jQkU3?=
 =?us-ascii?Q?Q6tm/qo3P3CV00OUt4EJ60Z4h3oK/3SM6ADjOzV1yEPV0YGLb8s5OOeieKsO?=
 =?us-ascii?Q?t0eZYt6dnbKc4l0QD5QmOSpVE+HSmoECctgSZgYa7AnKEWANw8IyvELD3j7u?=
 =?us-ascii?Q?C5Ya/6vLtXwUaa/mDhZBZ0sAXq+/5QkNBBCYktwZ3GXtCct7s78oJ7R/H5fC?=
 =?us-ascii?Q?ff3GPbp7bb0OSnDkCWbqQL5eK9hQf8MlP8OYrl70QFbZY0Va09PokcvKIsdP?=
 =?us-ascii?Q?CG4hUlZl30Ru/8Mmx7TzXpPWU0dp2jDYkuoXh3hCKUClJk0o9IpUzuBItOjp?=
 =?us-ascii?Q?o8jQ1IFmXLCnGqDrodXJQKRxw0RivDB6Kks+ZlHAemCx2rA2pUTEJDLAUHwJ?=
 =?us-ascii?Q?8QW+KY7UkCrsndtEg89QWkrNohJvA+/CosHbHkC3HeUAWr6tQ0cWueHSDCtc?=
 =?us-ascii?Q?f5nSx2X6VH09vu4XZYeR85/Io6YhKrNi4WNrJTiWPSDJhwGIztqhG2P3+PUv?=
 =?us-ascii?Q?X75sQ60VeOwZt42cNDBqbvdeTCmueuceaAyxY2vM7kxEH9KBQJ2f+SqdGEqZ?=
 =?us-ascii?Q?35WEc77NFoCTPe+/LC/+VPrREVjapJOFNrfo2o7BQVMXhleU4AZeLx7ms1jD?=
 =?us-ascii?Q?NO/w74KX/h4IQ/WlYW/L3Qi0hBATcXrXrzlYaZHOF43i2lju1+YgkxL5G2VL?=
 =?us-ascii?Q?bop/cKweOXiF1OosupBXfUBqLwXRmTwxjHhdNTrfQpdyfrjRNyM7vDNV2ZLO?=
 =?us-ascii?Q?IBpWk6u1rZ4=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(10070799003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?NRnZaDRJ2tSFy/mQHnIp9yKMHEctB3ZMOcesXJEALSXrMYHQl5SeYvJS2aQq?=
 =?us-ascii?Q?Al17Dkcc+pzQx3a04a4r2kthIZ6AqHUWGMGNrJXwO3YLnBf9/6abkWHf4AY3?=
 =?us-ascii?Q?PZCMbnAk8vNC2VmIAEx1yRJhs+J+EsEQ8Y+UriUPNMNXjsxjpU/JVm1MnpUF?=
 =?us-ascii?Q?yBy/6n7cqS9YFAWbd5Epw0nnLFDJ9x9XBa5bvPHm6Qx/04Qdn44D8nwBa60E?=
 =?us-ascii?Q?wosLm/U6c4eInvIPIyCEx+7TSIc9EnDMZtPG05SveNPX4TqKRwGXh5+5XykB?=
 =?us-ascii?Q?5AeaDL43Lxx3k7M5t9Rrv/gtErQsalvvJYPmLtxCv5UOivLFnmZNadHvyQAv?=
 =?us-ascii?Q?tRnQBw/lTavvk1KFr7aBvWBj3We9OxLnUXUGNgFpx0U29pm1FdfvJGWCfckz?=
 =?us-ascii?Q?SQTzvtARX1HY+zNbNdQlipBNWqxVqR47+zRzXtRdIjBq6ULGq03iPpJgGiDI?=
 =?us-ascii?Q?FxYiv27YG+7nyaWjm0FP8MEDiywrD0fYb3alslyp04xpGPHuHUICFSHrOg2T?=
 =?us-ascii?Q?ns4YHGwMv3NGe8tLl79zCtOSIPreQ06ShlSMDy9iBpoM/2EMw8ZBCHiXZyuO?=
 =?us-ascii?Q?iq6kwJ+s6qaIh1AFCEukPiGVg6lH2jErNovvI5idmS4Eg9O589immhnvTak7?=
 =?us-ascii?Q?AvkFsDGxmbC1OVcw6q0nfFr3/LQwPayk7xWHgUnWdpUGGlUNGovGVKJZs6lZ?=
 =?us-ascii?Q?+xOdVoMJ1xIEpLVt7EiuTXb+oVLcFhLTexxaH0mIuY+y7PmFpum5TTDvZX7q?=
 =?us-ascii?Q?KIy0ESiNqylRmsR/k5oLhdJ7m3uDxwlCjwUN9Of9i+8/rKMKarVgArEMuEfg?=
 =?us-ascii?Q?NuSX+hvG3UVxlaUbGbDNeZSw/O27saXxgLvQtQ0akJ1YacNNa9EJJExxhlKb?=
 =?us-ascii?Q?T97IyFHdlbc5uwGhPeSdW4B4vfhWOeCZxVONKpA8jni/frXe1NH4yR9hcvRu?=
 =?us-ascii?Q?21jszU7jssrvaISAl9eo5HU9samXyB0KLaH4aEAU0y+d2LyDqRL7TUbjORVi?=
 =?us-ascii?Q?+Q2O/YOQufnnoq8zhL/umhTvdJBVHKCB/DNbQO3mXNNZx0Oeornn5MSLymm8?=
 =?us-ascii?Q?m4+54ivGFeIHSZz9khAZeRf0tmHOUCmOMbcO8+WlcbJBzSOWO0EME6Ef3gba?=
 =?us-ascii?Q?nQWVi75wpzEIGBWz/7a/QiAHqkuDzKsmd0EVkR3yydZeeIeIxsVQvumhTK5w?=
 =?us-ascii?Q?EFRBM1sh82RUjVxtknoiCHs8V8dnhi5A2YAeyMPd3X1Y4VNKGrBICI1sJHUh?=
 =?us-ascii?Q?L9anPM6iIHAysHNnG3Shar5SwoArnYfn308fx/bmydgcalm6lwg7RBCK1kqe?=
 =?us-ascii?Q?F3IaM//SqTkLzhh9E9vj90zL4dnLmXYhFQvvlVC0O+H59kCtnE7Pv8Lun9dW?=
 =?us-ascii?Q?ULyG+QxW4uB8w1exc0d5Dsa2xXPO3uy4jT5w/ZBXMGJghGpgAWQgpXZykOeo?=
 =?us-ascii?Q?jmbWnVUCBp6knOX53e7/tgIEUnHTy0w2h+ZYoWpKDQIIx6ofOI17H14WDP2V?=
 =?us-ascii?Q?9b/35MCryd3lj5QNZsf1PsCGWTBMZbZ7Y8V1RZs8pNnYfnm108XEZbzbhC+a?=
 =?us-ascii?Q?0PuqTNCLMnNEDW1sKEEBO0m5FAqOuVoSJqq1xishnIaVEl+S/rqJ0NLeIdJp?=
 =?us-ascii?Q?ApmScpFfVhrovAhgrDZCnZo=3D?=
X-OriginatorOrg: valinux.co.jp
X-MS-Exchange-CrossTenant-Network-Message-Id: da6b9d95-a852-42ee-72e8-08ddb0d5fe49
X-MS-Exchange-CrossTenant-AuthSource: OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jun 2025 15:12:09.8013
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 7a57bee8-f73d-4c5f-a4f7-d72c91c8c111
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 1+RqEPMuLtsqsyPR9gpuwLjqf8vUO6IHPXM/xt2CqWJP1BFNR9J0YVqWS/W2KoZTWrG630luhW7CR++rrkx+sw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYWP286MB3033

Even though make_hypervisor_node() does not rely on the /reserved-memory
instantiation when calling find_unused_regions() (the wrapper introduced
in the previous commit), the next but one commit will use it for PV time
shared regions, in addition to the existing extended regions.

Move it as a prerequisite for the commit after next.

No functional changes intended.

Signed-off-by: Koichiro Den 
---
 xen/arch/arm/domain_build.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 9d44b6fa9470..967ca6f375ca 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1725,14 +1725,6 @@ static int __init handle_node(struct domain *d, struct kernel_info *kinfo,
          */
         evtchn_allocate(d);
 
-        /*
-         * The hypervisor node should always be created after all nodes
-         * from the host DT have been parsed.
-         */
-        res = make_hypervisor_node(d, kinfo, addrcells, sizecells);
-        if ( res )
-            return res;
-
         res = make_psci_node(kinfo->fdt);
         if ( res )
             return res;
@@ -1763,6 +1755,14 @@ static int __init handle_node(struct domain *d, struct kernel_info *kinfo,
             if ( res )
                 return res;
         }
+
+        /*
+         * The hypervisor node should always be created after all nodes
+         * from the host DT have been parsed.
+         */
+        res = make_hypervisor_node(d, kinfo, addrcells, sizecells);
+        if ( res )
+            return res;
     }
 
     res = fdt_end_node(kinfo->fdt);
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Sat Jun 21 15:12:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jun 2025 15:12:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021611.1397529 (Exim 4.92)
	(envelope-from )
	id 1uSztD-0002I7-RT; Sat, 21 Jun 2025 15:12:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021611.1397529; Sat, 21 Jun 2025 15:12: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 1uSztD-0002I0-OZ; Sat, 21 Jun 2025 15:12:19 +0000
Received: by outflank-mailman (input) for mailman id 1021611;
 Sat, 21 Jun 2025 15:12: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 1uSztC-0002Hn-3m
 for xen-devel@lists.xenproject.org; Sat, 21 Jun 2025 15:12:18 +0000
Received: from OS0P286CU011.outbound.protection.outlook.com
 (mail-japanwestazlp170100001.outbound.protection.outlook.com
 [2a01:111:f403:c406::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1bd21c5f-4eb2-11f0-a30e-13f23c93f187;
 Sat, 21 Jun 2025 17:12:14 +0200 (CEST)
Received: from OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:10d::7)
 by TYWP286MB3033.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:2fd::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.22; Sat, 21 Jun
 2025 15:12:07 +0000
Received: from OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
 ([fe80::80f1:db56:4a11:3f7a]) by OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
 ([fe80::80f1:db56:4a11:3f7a%5]) with mapi id 15.20.8857.022; Sat, 21 Jun 2025
 15:12: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: 1bd21c5f-4eb2-11f0-a30e-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=KguUZnrCkJU2Pmyn5JFZUL7C8Z6hQ59F0DPy+psbGRWSX+d9AOXcBc/DTMGwiEZZN3Q0T1qT5lOgt4nfDUdWREnTbyODX/9LGy5oAOEUR95tvTFv5SjMcEF0A4dntEhfVMYYIFXX1JrNqbxe8ihnODqdaf59Z6G28bF1/IgzjAMDRRkr/TV+6qZkaeRtNB7trJA10oXcLBPWc2NJLfzrWF+6Orv3avgPN70VqZaDIiqog/v1QZ08i/G01wgy1pRh80iQuPsnfGUOCx9IxrUDLXRSR04z6rsaYaCbPCwhDr+BnUKCvAuDmMGNwfyydqN2f6+jj2lQsOsZ5Am7vyzMSQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=bk8C0BSlJhA6mVNaKbWnyvdYNwVgYQD2+aecmXqoNGU=;
 b=mMY8G9Jf6rDourwNJG6ROT4/HqOC9rcWnFLplOartW3HwJWaNGTYPOljddJNMOhAnp8QSuA/p6gyvhxlWXs6oxDo/cXQcNZsnVOuHRK3cHXU8wJJhEhSvDiniyNrQLEw06GGOD9xXsdcsUSjkpHnnt76RcPF2Lt6/LYE4j4ZiyKHyWP2+DmUyaTJZiWehiXunAO3SJAfGmUEyAxWc15qqXdAtcyy3thGFPzN/xbTuUrqm8dwOJVQf3SzxUyv7Ix+sN4m1yPrcP3ObJbYzFgsTlbHIrKt30jc90vgaiGX9pCZC2YL0n2RNyw67GtEO+N5jd+KiDTQtS9J++IstAIfqA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=valinux.co.jp; dmarc=pass action=none
 header.from=valinux.co.jp; dkim=pass header.d=valinux.co.jp; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valinux.co.jp;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=bk8C0BSlJhA6mVNaKbWnyvdYNwVgYQD2+aecmXqoNGU=;
 b=b7EK1mj2lJ2IMoydMn0UArjGmac3utkNmla9wyHJ/KZ1Jkj/MIClokLelqW1p9w9E06mURUnhCZF7d9VQtAF/M0aqRdrJIzB0YZkoWqdFuKVLgh/d+ytJLVSUZGXXxiJXkCWQfsxULLETnByiq5YA90SIKEONVzvveMQMsKq4QI=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=valinux.co.jp;
From: Koichiro Den 
To: xen-devel@lists.xenproject.org
Cc: Koichiro Den ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [RFC PATCH 1/4] xen/arm: Add wrapper find_unused_regions
Date: Sun, 22 Jun 2025 00:11:58 +0900
Message-ID: <20250621151201.896719-2-den@valinux.co.jp>
X-Mailer: git-send-email 2.48.1
In-Reply-To: <20250621151201.896719-1-den@valinux.co.jp>
References: <20250621151201.896719-1-den@valinux.co.jp>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: TYCP286CA0262.JPNP286.PROD.OUTLOOK.COM
 (2603:1096:400:455::9) To OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
 (2603:1096:604:10d::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: OS3P286MB0979:EE_|TYWP286MB3033:EE_
X-MS-Office365-Filtering-Correlation-Id: 598004ac-2d1b-4ce9-4c2b-08ddb0d5fcf5
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016|10070799003;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?hYZa2VR8eggyGubTiP/rXdN+CJrZ8x0nEFAJ/KrSlE7Mg9fSJiilaxw6+E0g?=
 =?us-ascii?Q?L9CE7tx/YkA77cjBHTL5hZrM7DxSoJ1aY/bSkxcKH7fJAfyb9GGHsSyahF4t?=
 =?us-ascii?Q?1dPQ0nqtDSXqZu/GXkNGhDGONbO0PHUcu/cCDzaw7WRNTyAb4fR1LTSCAboI?=
 =?us-ascii?Q?YalyutWM3a70zELrJ7JeR+uctUBPf94oD62+2NpulghGZNTcmAbsYzBAGwzC?=
 =?us-ascii?Q?aEJ4+VJKpLGcAZ2R297hHvigq++E+WRxddmQTiJKM6hB64vcot5+7KL7XuxH?=
 =?us-ascii?Q?WFfzZ7DC003y92dcjZKpP032qFg6ZG2yeIJx6qHLMrnrZl6L5tl4QCW+u6JD?=
 =?us-ascii?Q?4WCbVq0SKzmGIocao/s/ocxZdlZN0ODVsmC99c1zMT4EioFpJnReyvPTSbCy?=
 =?us-ascii?Q?rMfX2ztrsnJtEnY1xHsx7z6TpyRaai/GQ6Ttr7mgDYmrYO7RXXJNYiqC5YIt?=
 =?us-ascii?Q?VCY4XSpOJL9RGQkRx69IWvP2N+eIP2eD4F4FuqlBDFiJEC4fW8fGEiALiCAb?=
 =?us-ascii?Q?X/M3PyRdKDHGfqJGHyY00JelZMYJ9wcdju3EdNoYCP6ja2R3vqiaU9GG5bQv?=
 =?us-ascii?Q?0kMDwqYz29gmq+GGgykGtr62yQhdSx3HB8fj3s0aivssIeTwrULveSuSTrXa?=
 =?us-ascii?Q?hlITB9nqP5c3Sfv3YAhbDa5U6SUA0QzsKBYTKzjRFlHgBcFY8Lr0SXQ0IjgW?=
 =?us-ascii?Q?hb3d2v6o8Wb4fkhUpWF0H//Y9ChgzRlvmJ0aAJ10pVAbZSYcv7RZL8RHmtKO?=
 =?us-ascii?Q?uFunlxj7wWqTg/GrvcbzZQAuHUj1eNj1by4MHNrpj5CFlRySL/WXMDm0rx8y?=
 =?us-ascii?Q?vISLVHJEqGi5jtgsYPliRS2f/3p8C/21tnP/d8fGjx+NkOsc3IFs1yJX+k5x?=
 =?us-ascii?Q?vPcSFLdf69OycAci/aV9SIT4ZHDlc4pA6XW4MAAoJ7koi3hbCROr5ZqFxtEP?=
 =?us-ascii?Q?7Ky8hGRtQtqQaQ8egqVIosqCGxnY9ZPfcuAtt+ehEtKDSfVB28Qqi0m0OUys?=
 =?us-ascii?Q?9OuFtdbMan+0ATMzf6SLQBAzC3XHqqvzZcMfgz2n0cSlu47Kn8OK8irzJztD?=
 =?us-ascii?Q?W0+F+cxq8/fQ1AguGn5jY3yKMfP6SkcMl8i2h6rf7UyOMOvBTxgk6bWB+jgS?=
 =?us-ascii?Q?W8ko5tqavAdM4uiWuHJV25VWK2R3s6RH/sGuFd0lz2iwJNccDsFq7yzpcx80?=
 =?us-ascii?Q?BM5yaUVTlodajFc+FZQLj2Z67ZzZtCiuVK/Jws+t5ZpcJAFuRYWmEBA9T8pl?=
 =?us-ascii?Q?cAJELZTZuVCyZbb4QdGPJ1WtmoBX7I87EG+sVV6TgFwilhU+9LBqpoq/Pbry?=
 =?us-ascii?Q?XRiKE5DEaExXwJ9QgsiDfNJNWAq4FUtYAxkVIrqWgvC1Bjxw1POQFtknKCRW?=
 =?us-ascii?Q?uGXjudAX4bTY8B4O2gBrIJBstLkLnlfiOv7Gv0RPJVbBd2exFV8eKnHiLKqS?=
 =?us-ascii?Q?zhR5WG4SKCU=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(10070799003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?AIw95+sX2Yv8cUnz0TPhicMCk4M80OHcZSOXCk+Q+655HTQk0lO3QOqmzK5Z?=
 =?us-ascii?Q?C4Rv6j8bg8KgyMldIXIjlwzN28u9isWlyVwIFGdGrMfKaz5iVWWpwcuyCUvy?=
 =?us-ascii?Q?C32GWW240T0YvRD518gHwqjy3S/6+lhbL/AJtUNDKJU5h7k1uucU6lVbbOh3?=
 =?us-ascii?Q?ujFVwbQBMnSCFe/vS0fBYbK94joTDD9NfFi1FmnHSouVtKTfg3pNaS9RvMSw?=
 =?us-ascii?Q?nk9BJaF6VCRFV09hWVjSQ0nYdLLaoogSRc/K7cJh4aqNPUh87ndK7UHT82M7?=
 =?us-ascii?Q?E13H4xYNEfEaH2cyD4U99visALQke9Jf0UhyY6KwvNW3q1yT/4rfFwxA6UgE?=
 =?us-ascii?Q?anRus1L1ny88epBYhDbfSdanvtX5rVecsTu6Nl02WZAnIMvE2M5jYoYpRB8S?=
 =?us-ascii?Q?sBE2Mhbz0iddrATacJHnExdEzIxLRFqJOXdlnlH7FN9WohGtb42e0AxlO0cb?=
 =?us-ascii?Q?dkS7Q7llnZk1iAifFz18GIcvPOzmkWuBkLBJlEToj1sQRvevKoQgDFVuMCGw?=
 =?us-ascii?Q?rD7A7Rf3mzSjIRwjiO2l5FA4/GMfmpMacF5AxB71wurDR65uVuOBs8VOKvEk?=
 =?us-ascii?Q?kCIMPR27nH/Uwwu6nABpgQ/tBdId5S2Zic6OoHCi1svZQ3UV9spsmCxHrrL6?=
 =?us-ascii?Q?arRx/cLHE+NUt9pnPu+UsIjlmDDBwx2K6w5ywyaNuHGCHFwSEirzU/zBRU2W?=
 =?us-ascii?Q?ZGolxvCMgtJnm6BlZ0H2vxsRdMCItSg7buDeEtcfuuJ1BpUwg1RaXK/BUXV3?=
 =?us-ascii?Q?rVLyIefHWD+Eq874ty08Pqz4zEXfKEYYX5KtrPafYvjhQyZ9nSV2j3TfF7rO?=
 =?us-ascii?Q?QIHf8+84Fc9YD5yMUWIVr0X5LonIibGS8giknyAaNIwqcrLWbv0h/m6ZfK2s?=
 =?us-ascii?Q?rpfz6BtZ1Qnqb2kJ5DlRDQlXHg1rTXI4kAtIdy4eA3Hd6ANbaSFLGT/QjO23?=
 =?us-ascii?Q?djUcFAzaf72OWC7gp7C1J+m2ci9iQtxQQf2HV0QebTC+uZMSViYHpAGOoF7U?=
 =?us-ascii?Q?aSwtw7L7okazkVCP6PbrdCZLs6R7FqUq+k3fZLLhowOKcx6k2nqEoeUFytyt?=
 =?us-ascii?Q?OBd8rNjcp3u1VbQ1B4VVuk6Q2W/JnSHYUVwqbmHPBOewsfVe96jpQrfWzQoL?=
 =?us-ascii?Q?vM+BI7950P12CGp3oOfP7LZvn4k3rTq86fL01v0HBx94Hg4b2SjBn3n9NJGI?=
 =?us-ascii?Q?ylvvqWI3NK/5Vm7xuAAGanQhdOhImgKEQRfI9BnqybmD1cactsqY4pAyfbZ2?=
 =?us-ascii?Q?O1X/7EdXeMZ83z2A1swOn20PSsrFepMPd2d2DHBnSawCNGgrClAZ/QeIcrnx?=
 =?us-ascii?Q?UX6FyDSrr2Sk+SIVTs1a+59pSL7d/CbQl/2qbRb2/6hrwt8Spj7UzHVWI32Z?=
 =?us-ascii?Q?IVldxiJiQWI+db1TORy87sDkmrgBJc4P1sICnrmfLNajzEfC8wMktwMDYWip?=
 =?us-ascii?Q?dT242mbZ4oCzkc3/5oEYEra+y779jcJ2Fv5iRgIoOKEb2dEdpQ2lF2PSR2ps?=
 =?us-ascii?Q?8UiG9r0Z45+khYhnWvS8i5U0vFopjVeiboQtTX2xaT/aXTexBT2mF7o1XLrB?=
 =?us-ascii?Q?HbAr+VU592WQQyNN2t1hymI+6FF86KocbvoghwbDIVJCHa9VVdvc18vnWNh4?=
 =?us-ascii?Q?84O3Jx/EJYTotDjpdajUEcU=3D?=
X-OriginatorOrg: valinux.co.jp
X-MS-Exchange-CrossTenant-Network-Message-Id: 598004ac-2d1b-4ce9-4c2b-08ddb0d5fcf5
X-MS-Exchange-CrossTenant-AuthSource: OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jun 2025 15:12:07.5667
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 7a57bee8-f73d-4c5f-a4f7-d72c91c8c111
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 9VCKy2RaDT21t+8BXMRe1zadlt45pf6d2btyAeyK4sZhzVxRnsJ7O6E1SEufQSmsFzRhp5p01p4PNPcTTf9pNw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYWP286MB3033

This is preparatory work for the upcoming commits that implement the
standard PV time interface (ARM DEN 0057A).

No functional changes intended.

Signed-off-by: Koichiro Den 
---
 xen/arch/arm/domain_build.c | 29 ++++++++++++++++++-----------
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 4ff161887ec3..9d44b6fa9470 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1070,6 +1070,23 @@ static int __init find_host_extended_regions(const struct kernel_info *kinfo,
     return res;
 }
 
+static int __init find_unused_regions(struct domain *d,
+                                      const struct kernel_info *kinfo,
+                                      struct membanks *ext_regions)
+{
+    if ( domain_use_host_layout(d) )
+    {
+        if ( !is_iommu_enabled(d) )
+            return find_host_extended_regions(kinfo, ext_regions);
+        else
+            return find_memory_holes(kinfo, ext_regions);
+    }
+    else
+    {
+        return find_domU_holes(kinfo, ext_regions);
+    }
+}
+
 int __init make_hypervisor_node(struct domain *d,
                                 const struct kernel_info *kinfo,
                                 int addrcells, int sizecells)
@@ -1121,17 +1138,7 @@ int __init make_hypervisor_node(struct domain *d,
         if ( !ext_regions )
             return -ENOMEM;
 
-        if ( domain_use_host_layout(d) )
-        {
-            if ( !is_iommu_enabled(d) )
-                res = find_host_extended_regions(kinfo, ext_regions);
-            else
-                res = find_memory_holes(kinfo, ext_regions);
-        }
-        else
-        {
-            res = find_domU_holes(kinfo, ext_regions);
-        }
+        res = find_unused_regions(d, kinfo, ext_regions);
 
         if ( res )
             printk(XENLOG_WARNING "%pd: failed to allocate extended regions\n",
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Sat Jun 21 15:12:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jun 2025 15:12:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021614.1397555 (Exim 4.92)
	(envelope-from )
	id 1uSztF-0002my-P4; Sat, 21 Jun 2025 15:12:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021614.1397555; Sat, 21 Jun 2025 15:12: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 1uSztF-0002mk-HD; Sat, 21 Jun 2025 15:12:21 +0000
Received: by outflank-mailman (input) for mailman id 1021614;
 Sat, 21 Jun 2025 15:12: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 1uSztE-0002Hn-PU
 for xen-devel@lists.xenproject.org; Sat, 21 Jun 2025 15:12:20 +0000
Received: from OS0P286CU011.outbound.protection.outlook.com
 (mail-japanwestazlp170100001.outbound.protection.outlook.com
 [2a01:111:f403:c406::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1feb7d58-4eb2-11f0-a30e-13f23c93f187;
 Sat, 21 Jun 2025 17:12:19 +0200 (CEST)
Received: from OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:10d::7)
 by TYWP286MB3033.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:2fd::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.22; Sat, 21 Jun
 2025 15:12:11 +0000
Received: from OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
 ([fe80::80f1:db56:4a11:3f7a]) by OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
 ([fe80::80f1:db56:4a11:3f7a%5]) with mapi id 15.20.8857.022; Sat, 21 Jun 2025
 15:12: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: 1feb7d58-4eb2-11f0-a30e-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=w1Ht5usY0rN1H9cP9zns7rKOh+sfwSGpPrAP0wRMW5srBwyRY9k4Xx5SWwfsXyjCdmO92pVP/rm1z6EBQgLSitsKLcBukVtIysafoqafQRlAZj0E8zTxy9VKI14f5srJm49ri/PiolWZFSz1mOhA0JSBrqcyeXGyCK8lhF3uToZHRT2tvCryxkW28SVbVOAHjg18gNneTRUSH5J/lkxWhX3Iri9bWHna0HoROkJDpMFNfYT2MUUKtY6fsgex87g/FkP5jyAXzKEeBEL+NvhbSrQ1Tcoo13z2Ln1rW/xe3qB7QAf6wrvh9DsYz6phCoqDKjoS2jM+yP0HWVje1sgB+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=myCouYTkzXt1wRSFj6GnnII8PQIOCzOShhCCRH3V1mo=;
 b=YVqmDsdxka+V5/UT7JhFv8ki0Yi3TfqPlH87Bqp3r25WmFdxfyL4xA1aw0cXnQcrKtNYeRYF+9WJvybQ4Q2TaNNth+KlLgK2en+18xGAgwmz5l54AU53+ZiqBfKqXeZGAUKiSHUyM7//MVOaH8/wiToNfUy8YFjO/W+49mHXL8tIExITC/oAytmmrULFzY2wd0kZsmmFauMLaXZ8qvgAP0wGjtfeWYb5y1c7o+q33vPPkv6KZ5gromEbmmVgjpUUygpm++i4yfmrfDyrIwmS/xWw8Nex+XArmc7ePjUpj0pHYR6x9IAlJcn/XhnVs9BcxpF+mTgR0Wn4d/X+6X9p0A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=valinux.co.jp; dmarc=pass action=none
 header.from=valinux.co.jp; dkim=pass header.d=valinux.co.jp; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valinux.co.jp;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=myCouYTkzXt1wRSFj6GnnII8PQIOCzOShhCCRH3V1mo=;
 b=hGfvc59LO+eiofgyxLRGFGc4sXFncGuKyy6QeKznd5wX4Ih5KRjCszEpOLKTSUx8y5so1WJOYfiwxQRunBhrSYSBBbASPi7jy7QMwxmqO+YCeMzY9mgmPl8lXZ4SibYyBqY09QH9sSOEcjjrTnEbR9tdVdw43+BRcwb+LyxClKU=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=valinux.co.jp;
From: Koichiro Den 
To: xen-devel@lists.xenproject.org
Cc: Koichiro Den ,
	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: [RFC PATCH 3/4] xen/arm: Move make_resv_memory_node()
Date: Sun, 22 Jun 2025 00:12:00 +0900
Message-ID: <20250621151201.896719-4-den@valinux.co.jp>
X-Mailer: git-send-email 2.48.1
In-Reply-To: <20250621151201.896719-1-den@valinux.co.jp>
References: <20250621151201.896719-1-den@valinux.co.jp>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: TYCP286CA0321.JPNP286.PROD.OUTLOOK.COM
 (2603:1096:400:3b7::14) To OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
 (2603:1096:604:10d::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: OS3P286MB0979:EE_|TYWP286MB3033:EE_
X-MS-Office365-Filtering-Correlation-Id: a57fd3f5-b97b-4109-512c-08ddb0d5ff62
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|7416014|376014|366016|10070799003;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?gzmwhQrfVE8tavuIWQH4k5LvHMLFFOqLu4VH7tcX2Lxo/zC+NVSXTeeyYy+u?=
 =?us-ascii?Q?CzQcWxwxr+tPd+r7a3ct13mhcJNhzl2yrjJe76MR53SH98B+28LWGkWwu6/J?=
 =?us-ascii?Q?QcXaeAyAWA0XJZekcXz+Jm8WIOzDTOAjD+lbFKks3RKVf/1raM3EjsXdXI59?=
 =?us-ascii?Q?2kfALtkKwu+PyrIy+1Jglawdl9Hepo3sCnc63K2m1XEWSOq+MnSXTn3GUISt?=
 =?us-ascii?Q?1OEdT+nhNDmOKSwFl0SldWETkZl/qaeP6uCr5rnWDJqsD3zr24DCT+BsC4uC?=
 =?us-ascii?Q?PtRMTdlnbQGSu3re2YzkbPf+BUWi8f++v8Tu9dMd+CAeGhh2AxNM6EK4EOmn?=
 =?us-ascii?Q?IA92QU8pf+rPqetjuEsVkuidsc7DpBMqPbDE38be6PXaTThoqhfZLhY5mK9U?=
 =?us-ascii?Q?WLmNUjDtueND5yEb8aMN2vV1vSk8fBG42eDv3FIdOD//sJ52C4ctI34UgdsV?=
 =?us-ascii?Q?EvRYRF2yILh8fIbrF6rWlSKSILw2YiCiMRyXwEiX7DTlJeiMqYizpYCSFnLV?=
 =?us-ascii?Q?zddpveoHQdmAxZyyChXn4SFbWRRuEi1YiOlJxOl1jj4UNGdzpu8DMYPZfwr2?=
 =?us-ascii?Q?E55V+9AeebGVGbwSEomG/QT23pGeRC2fMxemPZ+4SwAk1mRBHk//8xkH9IHS?=
 =?us-ascii?Q?GJJQ2DLCxtiO1zpGvSvm0gxKYJUvnw2yfqeraoPux3KazPsEcP9SUVSgbBkQ?=
 =?us-ascii?Q?p/akzn9lShr15Y3ahTdJuGB7xOtg7kSnBqvUmyVt/tbF5MOEt6cUCf9g6jCW?=
 =?us-ascii?Q?oqgZHBGrnrZymMKt0zRPwlnG+rtBHUB1bSnvYJuH34LFdGTh6tOa4J5EbWLU?=
 =?us-ascii?Q?khpwSAEUe+snxlZ7YvXGuEpHRLSDOu+dvKw/hly++OxdIe5h5Qhlz01sw8zN?=
 =?us-ascii?Q?7rB7pAJDfBrMBesZp1Dkmu+3v7b2SizxUIu/kxZ5SWU1SCWwSrv4UNr69rbX?=
 =?us-ascii?Q?4efdbHqQGrWkYxdMXtiKwv/R9bG9gDb8uTa/CqpRIdZmeoCCE0+K86YRviXx?=
 =?us-ascii?Q?L01sBP589X/OXkCtrkHckdv+xwvPsfz09AuiLK3aDGF0lew9qYybhd/blnWk?=
 =?us-ascii?Q?huK1sDYPUqAsgke87OYtaWb8uCDXw7ZJ7c3Pl68vXfsoCS/3diqNO2qeWfQY?=
 =?us-ascii?Q?sncStlnNx8zLGyz0v/arG0mIUPAeZQjCv41VFiZBiWHiwIdupCIYf08sem9w?=
 =?us-ascii?Q?IlNYAOk7xw+lhp74XD6fvAiAdwT1hgOYT9+JB0TuWHltBm77IFgdrH5NJrcN?=
 =?us-ascii?Q?JPVDIunrEBdj/Zkkp4Sk9af1cE+1uJPdFb9A/jXX9Z0voAf4i6T9L3AA6jeh?=
 =?us-ascii?Q?JfoNY2uQVxmYHPqP8aqHoZUFBT/x6JaTbX3Zzfawtupf3T1z0iwEWijT1IMX?=
 =?us-ascii?Q?N9aISg1cSUFyIa7hcRaz/7FYW1rumcfvgYZT81UGwoVImA288eprLyPiBEgU?=
 =?us-ascii?Q?SB3LTVSi7Qg=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(366016)(10070799003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?ryOf2l6xJDJZG1AsjS6qGWGqvDFWZu1myoMpCalf45Co8VbR+rbJp6HC3HG+?=
 =?us-ascii?Q?BmhvbITJQ7/Y3ticGe+1FGj7unZPj1CW/8RjX2xoA0OsAZWzR+Gkf1yFM9Fq?=
 =?us-ascii?Q?BRCec+svICyk/sNNuoGpZq7Chq4paZt8Xz7hDrbmPQeTdznm1qCcBYWVlGzh?=
 =?us-ascii?Q?N4WuCidRSqXcqELSmg3Fqo23VJTa4OhRFYzn0JgzXjRZFg4BHEjf9n5ffh8K?=
 =?us-ascii?Q?iVUCRya/IqgEQc2jCxZWe6FmgO+runp3J+BIZdzDplmgm3mtUXiYccW407CS?=
 =?us-ascii?Q?Q59V7kR14HsSYUWb+IQbTdbH9R/wgYgVVFnk2+RfTe/IS+v9gAZpR3IDB6mC?=
 =?us-ascii?Q?uybbh3NuL8fxsMHb5zJ1Vw7AwWazy6Su5G/XozAQQl7PZVEuGbUT0TMe+CTa?=
 =?us-ascii?Q?DR+NBW/D0KcnnXaQyaC9ucu9DSXZUGvxuttqU59fgSii4PzSwFz8Re+FwAPB?=
 =?us-ascii?Q?A/aBVt27rb8EAcbR9VcZR4Vy3kz4b9WCNUGzfnqLirAwl0SBWGzHTkGlwP+t?=
 =?us-ascii?Q?eQeGKtsbx075Osr6LuHn4ggYSbNXjgZFTFvUYtxMJ+FNtqIL1idIXIIkjJb2?=
 =?us-ascii?Q?1TBjURjvQJSHW9nyeX/RIQe6NwEAiDRXa5HXd7M3SBMWwO5r5PYcCkKrMnep?=
 =?us-ascii?Q?Oz4/ikElNTj//EVuLzTDmidaAalnyA4Gd7TlkvtgY7G+4ax3G27x/1G1DC2Q?=
 =?us-ascii?Q?kIndqPjhlvUWZ46E8JYCn3O7Ka+Dufqr/zB7bYkcEiCsnQJOVFgjfEP3Hmom?=
 =?us-ascii?Q?RPC3OgJkPclE7FPxW4bRjbi1P6kIgk3Gf/S2hv9ipv6It6Vl3NtiKjICUsQb?=
 =?us-ascii?Q?9oQRsLxb98dotJhIbdQviIQc3d4ZCTC6BMwfgn9DjOuDkoAoscHF/mVtnIA5?=
 =?us-ascii?Q?b7C6goXdtwHbME+BXK/2Hf9xsq4f6K80m4xMkLCvS9ZCNIm/NaNaYq+wN7rd?=
 =?us-ascii?Q?A6R9rz2CHNiS3zRA0J/JNXXkO/xzbSGUoEInpVSD3aAI2wE8SyYEjrujY5xm?=
 =?us-ascii?Q?sWO1b0aIQ4CCxQV7Yk846hVKNM8M0vE5yAV6MsJbRWj8dhe1Ph2DAmu7GjAw?=
 =?us-ascii?Q?mC4CRgsqdaoQC3uA8K/i5B6T8VEq9grxN6ed/4MWVKgkvoB1fbZ2ueRrUA1I?=
 =?us-ascii?Q?YZEzyNaaYTbKky3JBAYTcZQJOO9BI7zQl51bEAeZOlB8xpxqTPmhq/pEm4cr?=
 =?us-ascii?Q?/iCYFo7xqFR2j0XAuGUzV537RsGOzX4Tl4vT+tDubFotR9u6CV91mDa4w9A0?=
 =?us-ascii?Q?nhhvASxcyHR6gJWQd2iW4T35McwipaZyR/g2SaqIRHKug//B597XLWXUBdeF?=
 =?us-ascii?Q?STVeVxdMzlwTd/Aqxii8JRMqlcPOfq+jMEV8llRlXCWOs8OpDSoBniIi18y/?=
 =?us-ascii?Q?j1l4LgyN/YbrAz4bcW9n5OScoAMdDfRA+nQ5EPDidChYIgD4/E9RLFuuCam4?=
 =?us-ascii?Q?Ae4ssYjCSClITSPrUq3qna+mLBPW2Mlv90/HrKrLhu+FF1m4+yVyZdQ71dth?=
 =?us-ascii?Q?mfRmiHnFO4NYKTDB8R7WHTwuUbz5RekEVCxSbO2vla0U7pL6LtMpHMjzS8mL?=
 =?us-ascii?Q?FxuOpmJoY/6jZU9t/PqDoKViIMMOwFEmcHi7z0dM4Hth2tsAs5oJPKV5TDf5?=
 =?us-ascii?Q?nxanPLdgyw2XBKBsvqbL5w8=3D?=
X-OriginatorOrg: valinux.co.jp
X-MS-Exchange-CrossTenant-Network-Message-Id: a57fd3f5-b97b-4109-512c-08ddb0d5ff62
X-MS-Exchange-CrossTenant-AuthSource: OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jun 2025 15:12:11.6450
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 7a57bee8-f73d-4c5f-a4f7-d72c91c8c111
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 4GgMlkH1B8Wn1JW35d0KBe5eD/uWUJrTBj8pGOY1ScufIlWaHNmkdJKvlLV+PYh2jIceaR4U6/1WQaQq0t18mg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYWP286MB3033

The /reserved-memory node is inherently not specific to static-shmem. In
the next commit, child nodes will be added under /reserved-memory for
the stolen time shared memory regions.

No functional changes intended.

Signed-off-by: Koichiro Den 
---
 xen/arch/arm/domain_build.c           | 40 +++++++++++++++++++++++++++
 xen/common/device-tree/static-shmem.c | 40 ---------------------------
 xen/include/xen/fdt-domain-build.h    |  2 ++
 xen/include/xen/static-shmem.h        |  9 ------
 4 files changed, 42 insertions(+), 49 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 967ca6f375ca..85b6909e2b0e 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1561,6 +1561,46 @@ int __init make_chosen_node(const struct kernel_info *kinfo)
     return res;
 }
 
+int __init make_resv_memory_node(const struct kernel_info *kinfo, int addrcells,
+                                 int sizecells)
+{
+    const struct membanks *mem = kernel_info_get_shm_mem_const(kinfo);
+    void *fdt = kinfo->fdt;
+    int res = 0;
+    /* Placeholder for reserved-memory\0 */
+    const char resvbuf[16] = "reserved-memory";
+
+    if ( mem->nr_banks == 0 )
+        /* No shared memory provided. */
+        return 0;
+
+    dt_dprintk("Create reserved-memory node\n");
+
+    res = fdt_begin_node(fdt, resvbuf);
+    if ( res )
+        return res;
+
+    res = fdt_property(fdt, "ranges", NULL, 0);
+    if ( res )
+        return res;
+
+    res = fdt_property_cell(fdt, "#address-cells", addrcells);
+    if ( res )
+        return res;
+
+    res = fdt_property_cell(fdt, "#size-cells", sizecells);
+    if ( res )
+        return res;
+
+    res = make_shm_resv_memory_node(kinfo, addrcells, sizecells);
+    if ( res )
+        return res;
+
+    res = fdt_end_node(fdt);
+
+    return res;
+}
+
 static int __init handle_node(struct domain *d, struct kernel_info *kinfo,
                               struct dt_device_node *node,
                               p2m_type_t p2mt)
diff --git a/xen/common/device-tree/static-shmem.c b/xen/common/device-tree/static-shmem.c
index 8023c0a484c1..7eede97fa25d 100644
--- a/xen/common/device-tree/static-shmem.c
+++ b/xen/common/device-tree/static-shmem.c
@@ -730,46 +730,6 @@ int __init process_shm_node(const void *fdt, int node, uint32_t address_cells,
     return 0;
 }
 
-int __init make_resv_memory_node(const struct kernel_info *kinfo, int addrcells,
-                                 int sizecells)
-{
-    const struct membanks *mem = kernel_info_get_shm_mem_const(kinfo);
-    void *fdt = kinfo->fdt;
-    int res = 0;
-    /* Placeholder for reserved-memory\0 */
-    const char resvbuf[16] = "reserved-memory";
-
-    if ( mem->nr_banks == 0 )
-        /* No shared memory provided. */
-        return 0;
-
-    dt_dprintk("Create reserved-memory node\n");
-
-    res = fdt_begin_node(fdt, resvbuf);
-    if ( res )
-        return res;
-
-    res = fdt_property(fdt, "ranges", NULL, 0);
-    if ( res )
-        return res;
-
-    res = fdt_property_cell(fdt, "#address-cells", addrcells);
-    if ( res )
-        return res;
-
-    res = fdt_property_cell(fdt, "#size-cells", sizecells);
-    if ( res )
-        return res;
-
-    res = make_shm_resv_memory_node(kinfo, addrcells, sizecells);
-    if ( res )
-        return res;
-
-    res = fdt_end_node(fdt);
-
-    return res;
-}
-
 void __init early_print_info_shmem(void)
 {
     const struct membanks *shmem = bootinfo_get_shmem();
diff --git a/xen/include/xen/fdt-domain-build.h b/xen/include/xen/fdt-domain-build.h
index 45981dbec0b8..e9418857e386 100644
--- a/xen/include/xen/fdt-domain-build.h
+++ b/xen/include/xen/fdt-domain-build.h
@@ -25,6 +25,8 @@ int construct_domain(struct domain *d, struct kernel_info *kinfo);
 int construct_hwdom(struct kernel_info *kinfo,
                     const struct dt_device_node *node);
 int make_chosen_node(const struct kernel_info *kinfo);
+int make_resv_memory_node(const struct kernel_info *kinfo,
+                          int addrcells, int sizecells);
 int make_cpus_node(const struct domain *d, void *fdt);
 int make_hypervisor_node(struct domain *d, const struct kernel_info *kinfo,
                          int addrcells, int sizecells);
diff --git a/xen/include/xen/static-shmem.h b/xen/include/xen/static-shmem.h
index 76a49869126c..4afa9107de5d 100644
--- a/xen/include/xen/static-shmem.h
+++ b/xen/include/xen/static-shmem.h
@@ -11,9 +11,6 @@
 /* Worst case /memory node reg element: (addrcells + sizecells) */
 #define DT_MEM_NODE_REG_RANGE_SIZE ((NR_MEM_BANKS + NR_SHMEM_BANKS) * 4)
 
-int make_resv_memory_node(const struct kernel_info *kinfo, int addrcells,
-                          int sizecells);
-
 int process_shm(struct domain *d, struct kernel_info *kinfo,
                 const struct dt_device_node *node);
 
@@ -50,12 +47,6 @@ kernel_info_get_shm_mem_const(const struct kernel_info *kinfo)
 /* Worst case /memory node reg element: (addrcells + sizecells) */
 #define DT_MEM_NODE_REG_RANGE_SIZE (NR_MEM_BANKS * 4)
 
-static inline int make_resv_memory_node(const struct kernel_info *kinfo,
-                                        int addrcells, int sizecells)
-{
-    return 0;
-}
-
 static inline int process_shm(struct domain *d, struct kernel_info *kinfo,
                               const struct dt_device_node *node)
 {
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Sat Jun 21 15:12:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jun 2025 15:12:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021615.1397569 (Exim 4.92)
	(envelope-from )
	id 1uSztG-0003BA-Ty; Sat, 21 Jun 2025 15:12:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021615.1397569; Sat, 21 Jun 2025 15:12: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 1uSztG-0003AM-QF; Sat, 21 Jun 2025 15:12:22 +0000
Received: by outflank-mailman (input) for mailman id 1021615;
 Sat, 21 Jun 2025 15:12: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 1uSztF-0002Hn-Pp
 for xen-devel@lists.xenproject.org; Sat, 21 Jun 2025 15:12:21 +0000
Received: from OS0P286CU011.outbound.protection.outlook.com
 (mail-japanwestazlp170100001.outbound.protection.outlook.com
 [2a01:111:f403:c406::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 20735cc8-4eb2-11f0-a30e-13f23c93f187;
 Sat, 21 Jun 2025 17:12:20 +0200 (CEST)
Received: from OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:10d::7)
 by TYWP286MB3033.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:2fd::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.22; Sat, 21 Jun
 2025 15:12:13 +0000
Received: from OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
 ([fe80::80f1:db56:4a11:3f7a]) by OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
 ([fe80::80f1:db56:4a11:3f7a%5]) with mapi id 15.20.8857.022; Sat, 21 Jun 2025
 15:12: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: 20735cc8-4eb2-11f0-a30e-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=hpAygUs7+ALrwr/3UVsCwCPNBGUJ4eXZsw1vN2YEwBE7w/exvCP8+nC9NymKaS1NUYAKyrKlOyLgWkt+QLgVx+7i99nQD/ws2hfdIuJFGQJdInmaiJbl/hO4LfFUKdOq3KUFIo0BtvYR7VRiTiA2Ajz0YMPZddwB6qk5vfoVekcqdiSdtMeXFa0Z6sD4byIfProlhmLehazGieyN6vz8wXm5lhWjanJKu3hPRyW9wq9BGYWHxmIYeBTHh/JFb4B/ACIypBAkHDImUTLVLm6qOSYkF+GjgNA1BpECyGG5wIp8OqsexigraPZ6KoMN/lA1OpytZIxsWKBGuylUn1dpjg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=7kqMEJ798ZMvRUHDoDgvFJRcUZEDqjdXngUvsN8djbY=;
 b=tXeJWrJxttA0g6ALNuSOmLwicLMFL+oSPVL3cJD7JPk9siCKQxu7KFwRzQEkUPSZWhiF7/Zorojcsy7bzFNdcN2nejXa6Ylfj1cEJ71tQbyeCu8wcL/WaR+BPZkbsAGCcnwQ+kT3B3MTsBXRxdEnyv+C8T3G75xVEO3ZSTtH+FKMva2w5/Q12CZZogkfym3wJDiXycVD8lfbR/oAOAtTaisRme6/9dUYnUikbtzekWJtmA/5CnlGcp96AdLr130Q1Z5OyEajmWPvJlDk2hQdLix366m6ybmE09aw3USJMFz8PFNyNDHmb/fH2ZbQ59plAkkCWpAs2mkx4DctkAaATw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=valinux.co.jp; dmarc=pass action=none
 header.from=valinux.co.jp; dkim=pass header.d=valinux.co.jp; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valinux.co.jp;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=7kqMEJ798ZMvRUHDoDgvFJRcUZEDqjdXngUvsN8djbY=;
 b=Q3RdmJGLQybMX6+xAn6vcXM1aO7eveUs1MFdkqVUx5P3u32u57meBZt9pVnDRffR6yad+kSoBoI1MmP5K9tqtKgavjykZL5hEgbQrcH/QXDnI0YR3NTTF0bxrKXWMRoSlKW/+S2ANVd3j0hky9qbjT+6kUOgN/RU6NbBvmjzSCk=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=valinux.co.jp;
From: Koichiro Den 
To: xen-devel@lists.xenproject.org
Cc: Koichiro Den ,
	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: [RFC PATCH 4/4] xen/arm: Implement standard PV time interface as per ARM DEN 0057A
Date: Sun, 22 Jun 2025 00:12:01 +0900
Message-ID: <20250621151201.896719-5-den@valinux.co.jp>
X-Mailer: git-send-email 2.48.1
In-Reply-To: <20250621151201.896719-1-den@valinux.co.jp>
References: <20250621151201.896719-1-den@valinux.co.jp>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: TYCP286CA0323.JPNP286.PROD.OUTLOOK.COM
 (2603:1096:400:3b7::15) To OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
 (2603:1096:604:10d::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: OS3P286MB0979:EE_|TYWP286MB3033:EE_
X-MS-Office365-Filtering-Correlation-Id: 1a938403-aad8-4871-d792-08ddb0d6003f
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|7416014|376014|366016|10070799003;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?vzkc4W1n96iPSPmHu0T2IBfGCd/cfo4Cox3ZYy9nAdwQG6Ajls9zkR00SLV3?=
 =?us-ascii?Q?0CjjZuGH6fApLi1B1vJH+bsBnVXkDQjeA2QEdTSirIXednBD4ricOUyoFwWV?=
 =?us-ascii?Q?+DIidno53tZbaTI4A5YIHOLGln7Gbj2ZBiAJmF2w6USjpAuM5Sfa3FdPoGLF?=
 =?us-ascii?Q?BBiYgPC/Y7V3iqvHoNFXnx22DojRIXNZoHBHpY6/44qWBtNBji4u80i9lo0n?=
 =?us-ascii?Q?hd27QTZAaggjzW1aeRmkIHI9TzFhLz3UNE7MBfkSePijsVh/repLhGRI++4z?=
 =?us-ascii?Q?Ya2PvJiR3UTrCdygXEhSA95Y3ysRpTazHfIv5KkMSAIEoIxXmzwhX7TsZITY?=
 =?us-ascii?Q?7d0qS2yGE4DvQVM3jmSHbYokHx9o1THKYAbSjXKCDyw8Q5L9nxQY59a5awbA?=
 =?us-ascii?Q?CiPwRaRJaIYoNtHlBHMl4buFhmjy7EVdVYaRolS8d6TSGjHvP+Hta+1DipQW?=
 =?us-ascii?Q?RPPmTaOLispxkZroOqi5uMowsh9yzMOPNEg6CB3kC6oZVOwY4eSeiH6mpaGi?=
 =?us-ascii?Q?l+Ha4XZUqfhb+RTYKi47k5iKbYNGvFpA3rTehhR2vWSzRemm8+WOtdVGYEJh?=
 =?us-ascii?Q?/GA4L3rYEnwW87DFJZM9J8+QyaY72J0xhdfJMvezeZTqGsC29Uf2r3hvboZJ?=
 =?us-ascii?Q?safUSJT+ogaXqQb1l6yIGCFMbDqKVIEC/MMcnEPksvZPFfQXn3l1Xo0mDhAb?=
 =?us-ascii?Q?fYVBXRTOTILX2IL6TpjAeoC94f+/b5kyyufpwf8+vbrbw0eRRN89LXzaQeRt?=
 =?us-ascii?Q?cnqCXyu2t25gwfZOwCzGyNnDKx3/P0dtsm5jWi7OonByoWmBMpxmEIem9hgv?=
 =?us-ascii?Q?lKP5rl42ogwfKB2IdG0PKf0s+tvZLigPIZVzQMcCaH1XeiWDfIsT6w9rdnfI?=
 =?us-ascii?Q?ZO01Hr8oTAHXd0smL09IEgat+2EUjf0tSn0vCS8MxIW/XsPdR4CXn95rSHTc?=
 =?us-ascii?Q?X8n5XYwIXuw0UdpWbws9ulbVoX035QlrvgwLRCWayWj2jbFfA9U1xoQazn1m?=
 =?us-ascii?Q?OYx3QoGCaLGkyV0r4HtAcq9Uxws/xR8vUvjnL8NVUibOsoJln0olBgqLD44m?=
 =?us-ascii?Q?2C178zvfFHvL8vVPUm5wid2/Y/IvB3kzy0WuIBBF3yLI0hUIWUvkH4jt739M?=
 =?us-ascii?Q?SwSFkQcIva1ZMMhbArOb2i0XTT7MYvIVv0Smr7phsVLEdyAJd5gm4oqf2jQa?=
 =?us-ascii?Q?2IqxNapxqynJ2/P939FTyGnzxQl+yKO0+183nUJCuieM+IoBJP+9TMGApKah?=
 =?us-ascii?Q?ADKjALR48v6VvZpIegHvTHCJyDdmkwjkoozml31Km3Rji4bP3oE+UV5NCNBH?=
 =?us-ascii?Q?f9xXNzGwF0fHEnuV2BmlB9A0MkbdhPp6TJym9VTySGLN7Ok/gvk3qStX/cKj?=
 =?us-ascii?Q?rWCW2+j6c3ej4E48PknNgN8hF2+uXHkbonbfQ1vWR50dUHCLaGrr3jzy1zQr?=
 =?us-ascii?Q?tGgCc4E7rTs=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(366016)(10070799003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?nyhrxn+omUJIBGCn0LCJcB6g1l5JhYeMgDTj82wkOhdzmAm3VTfmGgEMlD85?=
 =?us-ascii?Q?Gu559R5MJUgWZfqHMz7kRQZeL/iX4MyuNx1YHU2rejLmLrH2YZuUYh7N84NI?=
 =?us-ascii?Q?ICyI6XFmiq3WaRxjWuWqWxGcRnjvR+BGJz8DNrGj3qZhFRPdsZNBGkvwZM6o?=
 =?us-ascii?Q?2p5xzEp7sn4srXs5H+z/KQVuEDuMK1jGFU51uSNeN2NUkp3tKPxuLZnB7+4P?=
 =?us-ascii?Q?UXJxcguTIl6loGMXnoN8F8KH3wbZl4z9Mcf6sxcc1X+OlkY2JH2Dntthk8VZ?=
 =?us-ascii?Q?8f9UB5k1DHUNFv3v2QEHTPXQexgac3nBByrok67Lk4Tl9mrn0DjBBVKeBgWp?=
 =?us-ascii?Q?q9Vlccxmncq/tYOJ0n0ehiLwKfOc4Sc8yvDey1VG6hioxD/OsGdzG96cUTdk?=
 =?us-ascii?Q?SXtgMIDZCfBfO6ha20CcfcpIGPVmx4Av74P/+sPUr1uLG+ZMgc6+4OjAj/nh?=
 =?us-ascii?Q?izhaU04Y1wyxNdA3dTDEhinDBy4jDMAQaIraVKjNDNQWI3Y/kI45tejjX8L8?=
 =?us-ascii?Q?NGMtglhmK3H0BA52YQ41TMitIrMqzmJn2MmWI4B2nlypm9jGnre+IrKc/kZt?=
 =?us-ascii?Q?tbkTewLSlbwOjKxos4KwNLeZngpGzAm4EPjquid1LKPjDzLyBOcKlUWOylF9?=
 =?us-ascii?Q?FUQ18SwNRFi0ZKqIPkyBRmb9oIMMGum+F8IehxEiMP5OC+o9zb3tWfka+Eki?=
 =?us-ascii?Q?NOIyr/mDEZKJ4QIl63V1iP+kCyKEoegqvEKOvn036Y/pUSP1YOEPKzvHG/fL?=
 =?us-ascii?Q?2AWwWt8rBLZOAFqdHnD+CjaKmVAIedp79akXCzW/SHPE5Hg06Ep9GfPqfIRm?=
 =?us-ascii?Q?57pG/wVdzfLSfg40fAX3mZec2uu0muIgJ9GlDQfJFzjS3I8OjB5C8GwDsnRW?=
 =?us-ascii?Q?poBzf+8TIvISUwtJY2DEeNFg0CvvW25ZvI+VZXE2Rtsvq1UtKFkMgdchgZ+T?=
 =?us-ascii?Q?hVqz0btYch78HKG5MJ9b5I6lLhCRnOQ9A0anldqGbJGMlT7mjsDm64rhojEv?=
 =?us-ascii?Q?fye1M/n43eBo8U1lKNZHkeAuYcVYG61xC6HetjVWB69fANMJX3gPlNPkan3i?=
 =?us-ascii?Q?oYTDg/yaTqsF+yXMB9KeDUWWrd+Lp6ozKUHIwXyzM8vulGLLBk4mv2RV+S+z?=
 =?us-ascii?Q?tt8WTvSugaORYmTq9xu8+gMAR5/+t2vGMpHxXN8dlfE0mkBvl49/+lHw1G3P?=
 =?us-ascii?Q?Bjqu1gUUlg6uzs4Zkb9pmPoNH5CW6I1X+aZQZ+WwHnppu/Oxxj4Z2Ff0DOgk?=
 =?us-ascii?Q?KvyigeMTjK+gwT57+dAtuPwJXOMUpOThRSGbJ9O3GIdKKQB2KSvWorCo4K2t?=
 =?us-ascii?Q?oTCcmA4qOEldlkrBnoi5ERBI3Bn5UcBVQ1uEeJ2UZ7KzXGm/zkroDL5wgceZ?=
 =?us-ascii?Q?TI7BdAHn4Uyajrs6HsYxXWmwIyAVZUhM9knqLJwqEy3VLMfXA7g5P5+JwTuP?=
 =?us-ascii?Q?boSnsOVWhdjdQwhr4W0/+ZFte3l2DFb2UvjQd31IeF265LaQkSfr/X9L/E5X?=
 =?us-ascii?Q?iLLW7vgHrmqzuqeYxz+ETmoB+IQK347G4YcLBOIqbRxh/8IPQMncWhPPAGNd?=
 =?us-ascii?Q?hWY/j1ezCt1DvxxOR818xIXAq7USTwOsfTi4kpogpIeygO3jzeATTaewIc/q?=
 =?us-ascii?Q?NsHM3jZ/S5inhTFEDZ+WfkY=3D?=
X-OriginatorOrg: valinux.co.jp
X-MS-Exchange-CrossTenant-Network-Message-Id: 1a938403-aad8-4871-d792-08ddb0d6003f
X-MS-Exchange-CrossTenant-AuthSource: OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jun 2025 15:12:13.1167
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 7a57bee8-f73d-4c5f-a4f7-d72c91c8c111
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: XlRNmv7RDB/9eGjQGmVsGBFhPWgD72etZyodBWuhDBJQx4a1+Ikdl+KXUuctf6kgEFGSDuggaHyW+Hiq2YXA+A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYWP286MB3033

The VCPUOP_register_runstate_memory_area hypercall is still actively
used, e.g., in the Linux arm64 codebase. When KPTI is enabled, the area
was not registered from the beginning due to the VA not always being
valid. In such cases, Linux falls back to using the standard PV time
interface (ARM DEN 0057A), but this interface has not been implemented
in Xen for ARM64 (until this commit).

The VCPUOP_register_runstate_phys_area was introduced, though it's
unclear whether this would be used in Linux arm64 and when it will be
prevalent amongst every possible downstream domain Linux variant. And of
course Linux is not an only option for the Xen arm64 domains.

Therefore, implementing the standard way of sharing PV time is
generically beneficial, avoiding reliance on specially crafted
hypercalls, the usage of which by guest VMs is not always guaranteed.
Note that the PV_TIME_ST interface communicates with IPA (GPA), not GVA.

Add the PV time interface according to ARM DEN 0057A.

Signed-off-by: Koichiro Den 
---
 xen/arch/arm/domain.c                   | 30 +++++++++
 xen/arch/arm/domain_build.c             | 87 ++++++++++++++++++++++++-
 xen/arch/arm/include/asm/domain.h       | 17 +++++
 xen/arch/arm/include/asm/smccc.h        | 12 ++++
 xen/arch/arm/vsmc.c                     | 38 +++++++++++
 xen/common/device-tree/dom0less-build.c |  2 +-
 xen/include/xen/fdt-domain-build.h      |  2 +-
 7 files changed, 183 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index be58a23dd725..e895e4111f1b 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -277,6 +277,18 @@ static void ctxt_switch_to(struct vcpu *n)
     WRITE_SYSREG(n->arch.mdcr_el2, MDCR_EL2);
 }
 
+static void update_stolen_time(struct vcpu *n)
+{
+    uint64_t tot_stolen;
+
+    if ( is_idle_vcpu(current) )
+        return;
+
+    tot_stolen = n->runstate.time[RUNSTATE_runnable] +
+                 n->runstate.time[RUNSTATE_offline];
+    write_atomic(&n->arch.pv_time_region->stolen_time, tot_stolen);
+}
+
 static void schedule_tail(struct vcpu *prev)
 {
     ASSERT(prev != current);
@@ -291,6 +303,8 @@ static void schedule_tail(struct vcpu *prev)
 
     update_runstate_area(current);
 
+    update_stolen_time(current);
+
     /* Ensure that the vcpu has an up-to-date time base. */
     update_vcpu_system_time(current);
 }
@@ -586,6 +600,8 @@ int arch_vcpu_create(struct vcpu *v)
     if ( get_ssbd_state() == ARM_SSBD_RUNTIME )
         v->arch.cpu_info->flags |= CPUINFO_WORKAROUND_2_FLAG;
 
+    v->arch.pv_time_region = &v->domain->arch.pv_time_regions[v->vcpu_id];
+
     return rc;
 
 fail:
@@ -707,6 +723,7 @@ int arch_domain_create(struct domain *d,
                        unsigned int flags)
 {
     unsigned int count = 0;
+    int order;
     int rc;
 
     BUILD_BUG_ON(GUEST_MAX_VCPUS < MAX_VIRT_CPUS);
@@ -791,6 +808,19 @@ int arch_domain_create(struct domain *d,
     d->arch.sve_vl = config->arch.sve_vl;
 #endif
 
+    /*
+     * Preallocate the stolen time shared memory regions for all the
+     * possible vCPUs.
+     */
+    order = get_order_from_bytes(d->max_vcpus * sizeof(struct pv_time_region));
+    d->arch.pv_time_regions_gfn = INVALID_GFN;
+    d->arch.pv_time_regions = alloc_xenheap_pages(order, 0);
+    if ( !d->arch.pv_time_regions ) {
+        rc = -ENOMEM;
+        goto fail;
+    }
+    memset(d->arch.pv_time_regions, 0, PAGE_SIZE << order);
+
     return 0;
 
 fail:
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 85b6909e2b0e..1c51b53d9c6b 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1561,8 +1561,80 @@ int __init make_chosen_node(const struct kernel_info *kinfo)
     return res;
 }
 
-int __init make_resv_memory_node(const struct kernel_info *kinfo, int addrcells,
-                                 int sizecells)
+int __init make_pv_time_resv_memory_node(struct domain *d,
+                                         const struct kernel_info *kinfo,
+                                         int addrcells, int sizecells)
+{
+    __be32 reg[GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS];
+    unsigned int len = (addrcells + sizecells) * sizeof(__be32);
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    struct membanks *unused_banks = NULL;
+    void *fdt = kinfo->fdt;
+    unsigned regions_len;
+    gfn_t pv_time_gfn;
+    mfn_t pv_time_mfn;
+    paddr_t aligned;
+    paddr_t avail;
+    __be32 *cells;
+    int res;
+    int i;
+
+    /* Find unused regions */
+    regions_len = PAGE_ALIGN(d->max_vcpus * 64);
+    unused_banks = membanks_xzalloc(NR_MEM_BANKS, MEMORY);
+    if ( !unused_banks )
+        return -ENOMEM;
+
+    res = find_unused_regions(d, kinfo, unused_banks);
+    if ( res ) {
+        printk(XENLOG_WARNING "%pd: failed to find unused regions\n", d);
+        goto fail;
+    }
+    for ( i = 0; i < unused_banks->nr_banks; i++ ) {
+        const struct membank *bank = &unused_banks->bank[i];
+        aligned = PAGE_ALIGN(bank->start);
+        avail = bank->size - (aligned - bank->start);
+        if ( avail >= regions_len )
+            break;
+    }
+    if ( i == unused_banks->nr_banks ) {
+        res = -ENOSPC;
+        goto fail;
+    }
+
+    /* Insert P2M entry */
+    pv_time_mfn = virt_to_mfn(d->arch.pv_time_regions);
+    pv_time_gfn = gaddr_to_gfn(aligned);
+    p2m_write_lock(p2m);
+    res = p2m_set_entry(p2m, pv_time_gfn, regions_len / PAGE_SIZE,
+                        pv_time_mfn, p2m_ram_rw, p2m_access_r);
+    p2m_write_unlock(p2m);
+    if ( res ) {
+        printk(XENLOG_WARNING "%pd: failed to set P2M entry for PV_TIME\n", d);
+        goto fail;
+    }
+    d->arch.pv_time_regions_gfn = pv_time_gfn;
+
+    /* Reserve the selected GFN */
+    res = domain_fdt_begin_node(fdt, "pv-time", gfn_x(pv_time_gfn));
+    if ( res )
+        goto fail;
+
+    cells = reg;
+    dt_child_set_range(&cells, addrcells, sizecells, gfn_x(pv_time_gfn), regions_len);
+    res = fdt_property(fdt, "reg", reg, len);
+    if ( res )
+        goto fail;
+
+    res = fdt_end_node(fdt);
+
+  fail:
+    xfree(unused_banks);
+    return res;
+}
+
+int __init make_resv_memory_node(struct domain *d, const struct kernel_info *kinfo,
+                                 int addrcells, int sizecells)
 {
     const struct membanks *mem = kernel_info_get_shm_mem_const(kinfo);
     void *fdt = kinfo->fdt;
@@ -1596,6 +1668,10 @@ int __init make_resv_memory_node(const struct kernel_info *kinfo, int addrcells,
     if ( res )
         return res;
 
+    res = make_pv_time_resv_memory_node(d, kinfo, addrcells, sizecells);
+    if ( res )
+        return res;
+
     res = fdt_end_node(fdt);
 
     return res;
@@ -1744,6 +1820,11 @@ static int __init handle_node(struct domain *d, struct kernel_info *kinfo,
                                         dt_n_size_cells(node));
         if ( res )
             return res;
+
+        res = make_pv_time_resv_memory_node(d, kinfo, dt_n_addr_cells(node),
+                                            dt_n_size_cells(node));
+        if ( res )
+            return res;
     }
 
     for ( child = node->child; child != NULL; child = child->sibling )
@@ -1791,7 +1872,7 @@ static int __init handle_node(struct domain *d, struct kernel_info *kinfo,
 
         if ( !res_mem_node_found )
         {
-            res = make_resv_memory_node(kinfo, addrcells, sizecells);
+            res = make_resv_memory_node(d, kinfo, addrcells, sizecells);
             if ( res )
                 return res;
         }
diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/domain.h
index a3487ca71303..c231c45fe40f 100644
--- a/xen/arch/arm/include/asm/domain.h
+++ b/xen/arch/arm/include/asm/domain.h
@@ -59,6 +59,18 @@ struct paging_domain {
     unsigned long p2m_total_pages;
 };
 
+/* Stolen time shared memory region (ARM DEN 0057A.b) */
+struct pv_time_region {
+    /* This field must be 0 as per ARM DEN 0057A.b */
+    uint32_t revision;
+
+    /* This field must be 0 as per ARM DEN 0057A.b */
+    uint32_t attribute;
+
+    /* Total stolen time in nanoseconds */
+    uint64_t stolen_time;
+} __aligned(64);
+
 struct arch_domain
 {
 #ifdef CONFIG_ARM_64
@@ -121,6 +133,9 @@ struct arch_domain
     void *tee;
 #endif
 
+    struct pv_time_region *pv_time_regions;
+    gfn_t pv_time_regions_gfn;
+
 }  __cacheline_aligned;
 
 struct arch_vcpu
@@ -243,6 +258,8 @@ struct arch_vcpu
      */
     bool need_flush_to_ram;
 
+    struct pv_time_region *pv_time_region;
+
 }  __cacheline_aligned;
 
 void vcpu_show_registers(struct vcpu *v);
diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/asm/smccc.h
index a289c48b7ffd..6207ac74b715 100644
--- a/xen/arch/arm/include/asm/smccc.h
+++ b/xen/arch/arm/include/asm/smccc.h
@@ -380,6 +380,18 @@ void arm_smccc_1_2_smc(const struct arm_smccc_1_2_regs *args,
                        ARM_SMCCC_OWNER_ARCH,        \
                        0x3FFF)
 
+#define ARM_SMCCC_HYP_PV_TIME_FEATURES              \
+    ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL,         \
+                       ARM_SMCCC_CONV_64,           \
+                       ARM_SMCCC_OWNER_HYPERVISOR,  \
+                       0x20)
+
+#define ARM_SMCCC_HYP_PV_TIME_ST                    \
+    ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL,         \
+                       ARM_SMCCC_CONV_64,           \
+                       ARM_SMCCC_OWNER_HYPERVISOR,  \
+                       0x21)
+
 /* SMCCC error codes */
 #define ARM_SMCCC_NOT_REQUIRED          (-2)
 #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION  (-1)
diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index 6081f14ed0c1..1e2fbc1a62b4 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -127,6 +128,10 @@ static bool handle_arch(struct cpu_user_regs *regs)
             if ( cpus_have_cap(ARM_WORKAROUND_BHB_SMCC_3) )
                 ret = ARM_SMCCC_SUCCESS;
             break;
+        case ARM_SMCCC_HYP_PV_TIME_FEATURES:
+            if ( !gfn_eq(current->domain->arch.pv_time_regions_gfn, INVALID_GFN) )
+                ret = ARM_SMCCC_SUCCESS;
+            break;
         }
 
         set_user_reg(regs, 0, ret);
@@ -162,6 +167,35 @@ static bool handle_arch(struct cpu_user_regs *regs)
     return false;
 }
 
+static bool fill_pv_time_features(struct cpu_user_regs *regs)
+{
+    uint32_t arch_func_id = get_user_reg(regs, 1);
+    int ret = ARM_SMCCC_NOT_SUPPORTED;
+
+    if ( arch_func_id == ARM_SMCCC_HYP_PV_TIME_ST &&
+         !gfn_eq(current->domain->arch.pv_time_regions_gfn, INVALID_GFN) )
+        ret = ARM_SMCCC_SUCCESS;
+
+    set_user_reg(regs, 0, ret);
+
+    return true;
+}
+
+static bool fill_pv_time_st(struct cpu_user_regs *regs)
+{
+    register_t ret = ARM_SMCCC_NOT_SUPPORTED;
+    paddr_t gaddr;
+
+    if ( !gfn_eq(current->domain->arch.pv_time_regions_gfn, INVALID_GFN) )
+    {
+        gaddr = gfn_to_gaddr(current->domain->arch.pv_time_regions_gfn);
+        ret = gaddr + current->vcpu_id * sizeof(struct pv_time_region);
+    }
+
+    set_user_reg(regs, 0, ret);
+    return true;
+}
+
 /* SMCCC interface for hypervisor. Tell about itself. */
 static bool handle_hypervisor(struct cpu_user_regs *regs)
 {
@@ -176,6 +210,10 @@ static bool handle_hypervisor(struct cpu_user_regs *regs)
     case ARM_SMCCC_REVISION_FID(HYPERVISOR):
         return fill_revision(regs, XEN_SMCCC_MAJOR_REVISION,
                              XEN_SMCCC_MINOR_REVISION);
+    case ARM_SMCCC_HYP_PV_TIME_FEATURES:
+        return fill_pv_time_features(regs);
+    case ARM_SMCCC_HYP_PV_TIME_ST:
+        return fill_pv_time_st(regs);
     default:
         return false;
     }
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
index 3d503c697337..fa31b1733388 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -502,7 +502,7 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
     if ( ret )
         goto err;
 
-    ret = make_resv_memory_node(kinfo, addrcells, sizecells);
+    ret = make_resv_memory_node(d, kinfo, addrcells, sizecells);
     if ( ret )
         goto err;
 
diff --git a/xen/include/xen/fdt-domain-build.h b/xen/include/xen/fdt-domain-build.h
index e9418857e386..645e7d0a54aa 100644
--- a/xen/include/xen/fdt-domain-build.h
+++ b/xen/include/xen/fdt-domain-build.h
@@ -25,7 +25,7 @@ int construct_domain(struct domain *d, struct kernel_info *kinfo);
 int construct_hwdom(struct kernel_info *kinfo,
                     const struct dt_device_node *node);
 int make_chosen_node(const struct kernel_info *kinfo);
-int make_resv_memory_node(const struct kernel_info *kinfo,
+int make_resv_memory_node(struct domain *d, const struct kernel_info *kinfo,
                           int addrcells, int sizecells);
 int make_cpus_node(const struct domain *d, void *fdt);
 int make_hypervisor_node(struct domain *d, const struct kernel_info *kinfo,
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Sat Jun 21 17:56:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jun 2025 17:56:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021669.1397579 (Exim 4.92)
	(envelope-from )
	id 1uT2Rn-0007R6-AI; Sat, 21 Jun 2025 17:56:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021669.1397579; Sat, 21 Jun 2025 17:56:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uT2Rn-0007Qx-79; Sat, 21 Jun 2025 17:56:11 +0000
Received: by outflank-mailman (input) for mailman id 1021669;
 Sat, 21 Jun 2025 17:56: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 1uT2Rm-0007Qr-KU
 for xen-devel@lists.xenproject.org; Sat, 21 Jun 2025 17:56:10 +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 fd63cf21-4ec8-11f0-a30e-13f23c93f187;
 Sat, 21 Jun 2025 19:56:01 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id C1D2C5C35B1;
 Sat, 21 Jun 2025 17:53:42 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4D0CFC4CEE7;
 Sat, 21 Jun 2025 17:55: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: fd63cf21-4ec8-11f0-a30e-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750528559;
	bh=cbKij5rY8MqKV2pBio60lHHafYTeUqHLsxJliWIT4Y8=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=IspJ/srRtwRmE5u0Zh0bjKhPS+OUakGIBeg8c1HNiNN1JZAnz/y0449Dng5O8rGET
	 C9jDsJaRNZfOQ1ffkFTaDYdtB3+zNebPV4tl10dnkhvUs/CB1xGtB0ncQ6V4GXJe0P
	 FgxG9msWEoeErTWOL0Jdt1TwlEZ0GnPBQdWXKrqKilHiD5PNwPOYejS1IhxspUIr/+
	 suREoqDlL2i+16Hanezcb1PAqs7p1Rb41OSLX+i7wrvvpDwrSWdyvJfqvhu2ZZuD6z
	 sUUUfFtJlBlbk6jP6h+rVA1a3CB3v3XY7Kfjm6HMutdL9K0iqZPUxnifUeB4X61B6y
	 EaLqoxm4S1Bow==
Date: Sat, 21 Jun 2025 10:55:56 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
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, Andrew Cooper , 
    Anthony PERARD , 
    Jan Beulich , Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Subject: Re: [XEN PATCH] xen: fix header guard generation for asm-generic
 headers
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 Sat, 21 Jun 2025, Nicola Vetrini wrote:
> Dashes were wrongly not translated into underscores, thus generating
> an unexpected guard identifier.
> 
> Fixes: ee79f378311b ("xen: add header guards to generated asm generic headers")
> Signed-off-by: Nicola Vetrini 


Thank you so much for the quick fix!!

Reviewed-by: Stefano Stabellini 



> ---
>  xen/scripts/Makefile.asm-generic | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/scripts/Makefile.asm-generic b/xen/scripts/Makefile.asm-generic
> index b0828018080d..f6850758c54b 100644
> --- a/xen/scripts/Makefile.asm-generic
> +++ b/xen/scripts/Makefile.asm-generic
> @@ -34,7 +34,7 @@ unwanted    := $(filter-out $(generic-y) $(generated-y),$(old-headers))
>  quiet_cmd_wrap = WRAP    $@
>        cmd_wrap = \
>  	arch=$$(echo $@ | sed -n 's:.*arch/\([^/]*\)/.*:\1:p' | tr a-z A-Z); \
> -	upper=$$(echo $*.h | tr a-z A-Z | tr '/.' '__'); \
> +	upper=$$(echo $*.h | tr a-z A-Z | tr '/.-' '__'); \
>  	echo "\#ifndef $${arch}_GENERIC_$${upper}" > $@.new; \
>  	echo "\#define $${arch}_GENERIC_$${upper}" >> $@.new; \
>  	echo "\#include " >> $@.new; \
> -- 
> 2.43.0
> 


From xen-devel-bounces@lists.xenproject.org Sun Jun 22 10:08:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Jun 2025 10:08:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021803.1397593 (Exim 4.92)
	(envelope-from )
	id 1uTHcQ-0007CQ-SH; Sun, 22 Jun 2025 10:08:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021803.1397593; Sun, 22 Jun 2025 10:08: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 1uTHcQ-0007CF-Mi; Sun, 22 Jun 2025 10:08:10 +0000
Received: by outflank-mailman (input) for mailman id 1021803;
 Sun, 22 Jun 2025 10:08: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 1uTHcN-0007C9-K5
 for xen-devel@lists.xenproject.org; Sun, 22 Jun 2025 10:08:08 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c90921aa-4f50-11f0-a30f-13f23c93f187;
 Sun, 22 Jun 2025 12:08:04 +0200 (CEST)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 (Authenticated sender: nicola)
 by support.bugseng.com (Postfix) with ESMTPA id D20F74EE3C22;
 Sun, 22 Jun 2025 12:08:02 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c90921aa-4f50-11f0-a30f-13f23c93f187
Authentication-Results: bugseng.com; arc=none smtp.remote-ip=162.55.131.47
ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1750586883;
	b=RglfcUx7jio9bmDANlcYRLZGO8+4v2TEiNgGHGZBCl1zrqYcen5PrA2pnfEUJeVAdX8Z
	 otK+4aQgvMoVLcBP+c7y0Yv8UKpNq/4iqNxR8aYSl4Zti6oGAnKenu/aviWr7X1SecEZW
	 ariPqNBpl8MLXSOjUb4aB85eHM4Bsu+/TpF5Ty0mZCZW8Atn7L7ZVg2nqHiPg8NPk2KmU
	 7UQJ/wpPNA1GIIJ93hpQXX3VEoPZXuc5Z/s5m4sXkejh90SAaJdQpuazBX/hlKbtVk6eL
	 Lo/GbJn+b+IsPF6Xj5vKCVzBZZpBoNgyhWDzSQRFw2oNgfefqS0U1Hi9kIEFIjaRtuCe7
	 PscXrBfOzNFBvSKIzaYr4XEI4mb8pP+LgN+pTODzOx9wHbhXDUCyZ9uCIB2YffBAjLFFV
	 vsmUBOxpQNCSvbyKR1sDPfY79l2uzYVLl3iu+oerrROm8gZzpelnzL/dJ+enESwFZolk7
	 Aznx0nwtV27eNlGJJ/cSRGyZC6TCRI97SZJnWr1RQ5cjizNUqew5AsQuT+UDyk9GoXM9U
	 HoDJvrjyonxP7sL0jiibOSEEtLlMLacALrdAPJ48aecVKzpxGbJlW9eD+jdCcQrebDbxL
	 rkfter9W9dGnmbUTbpSPSuO8RGpjwG3GsAgEaZ8DW7Q9OuVc5PWfCFCsj1L+b/c=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1750586883;
	h=DKIM-Signature:MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:
	 References:Message-ID:X-Sender:Organization:Content-Type:
	 Content-Transfer-Encoding;
	bh=jslcUOeICWODILH+OG6zwDsEGVQ8qCFR+XzV7l7lBfw=;
	b=H1CrQvDTEB7FwkStX5Wf5XGCHq/DmiYB2ZEWHlIojosFsmqhkASamL9uhe8knl3IXfNc
	 KTvhp4zhO1PZq9SvGPiauk4vjsH8ejNFkRIHyj9MbM8uqOm989kS5JksR4H40een64Up3
	 v0SYxuk8WnGlizKtdR6IendN1lj9Hfa1TjiJsVgfPknefpadbJbCjaGgfmsk2B7yA1x9h
	 BvqlV/oOUtFSQaINfRWPMsRy49c8ze6wbP5OnGVy1864S9QrDbph9P9aZF36aKMaxUtjG
	 WwE4ksEWNr+1KzNOfZtv/AfthzaAikxwS2iZGLyPqDmb9h1uN+Ycj8QsorF6oYikyBvub
	 RbgoHowK5UnYZy6MxHkb0gpxzpkgsBcY+Zl+3FPxGyoij4F+VlLKMt+KeL3NKyYM6PiJS
	 rGn/1z6dQUar6MNurG7QFdc5+aIjXPRm54NAsLdySSvjeG4WRnLjEg4hxwT5sAXn5sPCA
	 6TenSXrOlCX968gBtgjDy/O/m1JHI3sd0sl59T7AZR6LibBRjZhf1j96GPwo1iUHyRE2i
	 GziV9+2v/Y96Ed6jIZV/xKzU+ZlgDexfz+f3lYb7Plt9q++OMYilBovruKkFB08FG2iNZ
	 VII70nTubS1EDpIsdR9AFyONf+2IkOXCEiOrw0dk0u5F5yEFcoKVQzLYX0OJXwY=
ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1750586883; bh=YbKtVsMz4n/LtFJEa7gZzap5Od2cYSSMsHqPWLCn+dc=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=ajhPkMa8I6LQu9SZm4Yqc5jLqD6g0ngVomVXZc0xXHyLNHILf4PfPEunZnusuIe2J
	 mOmVF2xjdLTwfmMqTgT87AlxNfdidiJkiEV82JcRttewKRvM3NaZYz5rJoYvD5fbMO
	 5qG1EJoAjCyKb9KGUs8haJyHkEnEN7Sff3bsc/S1uAlRmg6nFiSVUVVB9BSXaS4dz7
	 g7yfWI6TQzOUhVMC+/FW0/PPN4Wki49xHRQr8jdHfpsAS3dXInRnfU6xFUZvyRit62
	 zbb2+P13Y6Xq4NUYtYWn0tC/qlm0qynPDKcg6Ko9bjvXQ0YkoSRBvAQ4AmgFhR7ipn
	 zZQjyculLf8lg==
MIME-Version: 1.0
Date: Sun, 22 Jun 2025 12:08:02 +0200
From: Nicola Vetrini 
To: Stefano Stabellini 
Cc: xen-devel@lists.xenproject.org, Andrew Cooper
 , Stefano Stabellini
 , michal.orzel@amd.com, jbeulich@suse.com,
 julien@xen.org, roger.pau@citrix.com, bertrand.marquis@arm.com,
 federico.serafini@bugseng.com
Subject: Re: [PATCH v5] automation/eclair: update configuration of D4.10
In-Reply-To: 
References: 
Message-ID: 
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 2025-06-21 04:19, Stefano Stabellini wrote:
> MISRA C Directive 4.10 states that "Precautions shall be taken in order
> to prevent the contents of a header file being included more than
> once".
> 
> Add a SAF tag to the existing comment on top of cpufeatures.h.

You say this, but technically the comment is not a SAF comment, just a 
regular one that is interpreted to tailor the guideline.

> Add a header inclusion guard to compile.h.
> 
> Update ECLAIR configuration to:
> - extend existing deviation to other comments explicitly saying a file
>   is intended for multiple inclusion;
> - extend existing deviation to other autogenerated files;
> - tag the guidelines as clean.
> 
> Update deviations.rst accordingly.
> 
> Signed-off-by: Federico Serafini 
> Signed-off-by: Stefano Stabellini 
> ---
> Changes in v5:
> - add missing spaces in in-code comment
> ---
>  automation/eclair_analysis/ECLAIR/deviations.ecl | 11 +++++++----
>  automation/eclair_analysis/ECLAIR/tagging.ecl    |  1 +
>  docs/misra/deviations.rst                        | 12 ++++++++++++
>  xen/arch/x86/include/asm/cpufeatures.h           |  8 +++++---
>  xen/include/xen/compile.h.in                     |  3 +++
>  xen/tools/process-banner.sed                     |  5 +++++
>  6 files changed, 33 insertions(+), 7 deletions(-)
> 
> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl 
> b/automation/eclair_analysis/ECLAIR/deviations.ecl
> index 9c67358d46..3b5bc87e1d 100644
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -72,11 +72,14 @@ they are not instances of commented-out code."
>  -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."
> +-doc_begin="Files that are intended to be included more than once (and 
> have
> +a comment that says this explicitly) do not need to conform to the 
> directive."
>  -config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* This file 
> is intended to be included multiple times\\. \\*/$, begin-4))"}

[1] Here

> --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$)))"}
> +-config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* Generated 
> file, do not edit! \\*/$, begin-3...begin-2))"}
> +-doc_end
> +
> +-doc_begin="Autogenerated files that do not need to conform to the 
> directive."
> +-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
> diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl 
> b/automation/eclair_analysis/ECLAIR/tagging.ecl
> index f9da5d5f4d..b95f07feb0 100644
> --- a/automation/eclair_analysis/ECLAIR/tagging.ecl
> +++ b/automation/eclair_analysis/ECLAIR/tagging.ecl
> @@ -23,6 +23,7 @@
>  "MC3A2.D1.1||
>  MC3A2.D2.1||
>  MC3A2.D4.1||
> +MC3A2.D4.10||
>  MC3A2.D4.11||
>  MC3A2.D4.14||
>  MC3A2.R1.1||
> diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
> index fe0b1e10a2..63caa8f4a2 100644
> --- a/docs/misra/deviations.rst
> +++ b/docs/misra/deviations.rst
> @@ -30,6 +30,18 @@ Deviations related to MISRA C:2012 Directives:
>         not to add an additional encapsulation layer.
>       - Tagged as `deliberate` for ECLAIR.
> 
> +   * - D4.10
> +     - Files that are intended to be included more than once (and have
> +       a comment that says this explicitly) do not need to conform to 
> the
> +       directive.
> +     - Tagged as `safe` for ECLAIR.
> +
> +   * - D4.10
> +     - There are autogenerated files that do not need to comply to the
> +       directive.
> +     - Tagged as `safe` for ECLAIR. Such files are:
> +        - xen/include/generated/autoconf.h
> +
>     * - D4.10
>       - Including multiple times a .c file is safe because every 
> function or data item
>         it defines would in (the common case) be already defined.
> diff --git a/xen/arch/x86/include/asm/cpufeatures.h 
> b/xen/arch/x86/include/asm/cpufeatures.h
> index 9e3ed21c02..69041219cb 100644
> --- a/xen/arch/x86/include/asm/cpufeatures.h
> +++ b/xen/arch/x86/include/asm/cpufeatures.h
> @@ -1,6 +1,6 @@
> -/*
> - * Explicitly intended for multiple inclusion.
> - */
> +/* This file is intended to be included multiple times. */
> +/* #ifndef X86_CPUFEATURES_H */
> +/* #define X86_CPUFEATURES_H */
> 

Are these two lines really needed? I may be mistaken, but I think the 
violation's first location would be the #include below with a comment a 
couple of lines above captured by the config at the top [1]. @Federico 
thoughts?

>  #include 
> 
> @@ -63,3 +63,5 @@ XEN_CPUFEATURE(USE_VMCALL,        X86_SYNTH(30)) /* 
> Use VMCALL instead of VMMCAL
> 
>  /* Total number of capability words, inc synth and bug words. */
>  #define NCAPINTS (FSCAPINTS + X86_NR_SYNTH + X86_NR_BUG) /* N 32-bit 
> words worth of info */
> +
> +/* #endif X86_CPUFEATURES_H */
> diff --git a/xen/include/xen/compile.h.in 
> b/xen/include/xen/compile.h.in
> index 3151d1e7d1..9206341ba6 100644
> --- a/xen/include/xen/compile.h.in
> +++ b/xen/include/xen/compile.h.in
> @@ -1,3 +1,6 @@
> +#ifndef XEN_COMPILE_H
> +#define XEN_COMPILE_H
> +
>  #define XEN_COMPILE_DATE	"@@date@@"
>  #define XEN_COMPILE_TIME	"@@time@@"
>  #define XEN_COMPILE_BY		"@@whoami@@"
> diff --git a/xen/tools/process-banner.sed 
> b/xen/tools/process-banner.sed
> index 56c76558bc..4cf3f9a116 100755
> --- a/xen/tools/process-banner.sed
> +++ b/xen/tools/process-banner.sed
> @@ -12,3 +12,8 @@ s_(.*)_"\1\\n"_
> 
>  # Trailing \ on all but the final line.
>  $!s_$_ \\_
> +
> +# Append closing header guard
> +$a\
> +\
> +#endif /* XEN_COMPILE_H */

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253


From xen-devel-bounces@lists.xenproject.org Sun Jun 22 20:59:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Jun 2025 20:59:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021885.1397611 (Exim 4.92)
	(envelope-from )
	id 1uTRmD-0004BW-NR; Sun, 22 Jun 2025 20:58:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021885.1397611; Sun, 22 Jun 2025 20: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 1uTRmD-0004BK-Ht; Sun, 22 Jun 2025 20:58:57 +0000
Received: by outflank-mailman (input) for mailman id 1021885;
 Sun, 22 Jun 2025 20:58: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 1uTRmC-0004BE-0k
 for xen-devel@lists.xenproject.org; Sun, 22 Jun 2025 20:58:56 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org
 [2600:3c0a:e001:78e:0:1991:8:25])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ad52ffad-4fab-11f0-a30f-13f23c93f187;
 Sun, 22 Jun 2025 22:58:42 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id D3F6F4A5D2;
 Sun, 22 Jun 2025 20:58:40 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 627F9C4CEED;
 Sun, 22 Jun 2025 20:58: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: ad52ffad-4fab-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750625920;
	bh=N0tAVaVD4hZ8TVCPJmV8ViCmyPnYB5quhS1kLeigx6M=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=HUfbamC0JtLsdkUTi6DKZ/X7Qrbh+Xch/aLD5D5QOcZo0myziScVHUMEwSq84eAmR
	 ahK71OfCvjJrEU31jFeBbNOHDgM8zZHFZAFtS9XtOE4RhzhKmFnBSGzHCJuVDhR5DO
	 BGE2xkxfsbKTtQZJHojxwI1xR8teZUFzE/DlrG3+vrF6qFrnN4eeXeiSC+692Tjjq5
	 bFawLRAhEJrwgo/WcIemXsQ4pVO8QnJSSBaKF7E2h1ERo4Ix0fVSUBa0kH29gHSAIR
	 KPDSUo2PFNv0c8DBK0AmWYLDQSkTVDZ/ZksrF8/XBjZlNDSnAF+FrSkqo9aErBT6Ev
	 Ds4b4xqYIekGw==
Date: Sun, 22 Jun 2025 13:58:35 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Nicola Vetrini 
cc: Stefano Stabellini , 
    xen-devel@lists.xenproject.org, Andrew Cooper , 
    Stefano Stabellini , michal.orzel@amd.com, 
    jbeulich@suse.com, julien@xen.org, roger.pau@citrix.com, 
    bertrand.marquis@arm.com, federico.serafini@bugseng.com
Subject: Re: [PATCH v5] automation/eclair: update configuration of D4.10
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 Sun, 22 Jun 2025, Nicola Vetrini wrote:
> On 2025-06-21 04:19, Stefano Stabellini wrote:
> > MISRA C Directive 4.10 states that "Precautions shall be taken in order
> > to prevent the contents of a header file being included more than
> > once".
> > 
> > Add a SAF tag to the existing comment on top of cpufeatures.h.
> 
> You say this, but technically the comment is not a SAF comment, just a regular
> one that is interpreted to tailor the guideline.

No, that is a mistake in the commit message. It should be changed.


> > Add a header inclusion guard to compile.h.
> > 
> > Update ECLAIR configuration to:
> > - extend existing deviation to other comments explicitly saying a file
> >   is intended for multiple inclusion;
> > - extend existing deviation to other autogenerated files;
> > - tag the guidelines as clean.
> > 
> > Update deviations.rst accordingly.
> > 
> > Signed-off-by: Federico Serafini 
> > Signed-off-by: Stefano Stabellini 
> > ---
> > Changes in v5:
> > - add missing spaces in in-code comment
> > ---
> >  automation/eclair_analysis/ECLAIR/deviations.ecl | 11 +++++++----
> >  automation/eclair_analysis/ECLAIR/tagging.ecl    |  1 +
> >  docs/misra/deviations.rst                        | 12 ++++++++++++
> >  xen/arch/x86/include/asm/cpufeatures.h           |  8 +++++---
> >  xen/include/xen/compile.h.in                     |  3 +++
> >  xen/tools/process-banner.sed                     |  5 +++++
> >  6 files changed, 33 insertions(+), 7 deletions(-)
> > 
> > diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl
> > b/automation/eclair_analysis/ECLAIR/deviations.ecl
> > index 9c67358d46..3b5bc87e1d 100644
> > --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> > +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> > @@ -72,11 +72,14 @@ they are not instances of commented-out code."
> >  -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."
> > +-doc_begin="Files that are intended to be included more than once (and have
> > +a comment that says this explicitly) do not need to conform to the
> > directive."
> >  -config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* This file is
> > intended to be included multiple times\\. \\*/$, begin-4))"}
> 
> [1] Here
> 
> > --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$)))"}
> > +-config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* Generated file,
> > do not edit! \\*/$, begin-3...begin-2))"}
> > +-doc_end
> > +
> > +-doc_begin="Autogenerated files that do not need to conform to the
> > directive."
> > +-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
> > diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl
> > b/automation/eclair_analysis/ECLAIR/tagging.ecl
> > index f9da5d5f4d..b95f07feb0 100644
> > --- a/automation/eclair_analysis/ECLAIR/tagging.ecl
> > +++ b/automation/eclair_analysis/ECLAIR/tagging.ecl
> > @@ -23,6 +23,7 @@
> >  "MC3A2.D1.1||
> >  MC3A2.D2.1||
> >  MC3A2.D4.1||
> > +MC3A2.D4.10||
> >  MC3A2.D4.11||
> >  MC3A2.D4.14||
> >  MC3A2.R1.1||
> > diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
> > index fe0b1e10a2..63caa8f4a2 100644
> > --- a/docs/misra/deviations.rst
> > +++ b/docs/misra/deviations.rst
> > @@ -30,6 +30,18 @@ Deviations related to MISRA C:2012 Directives:
> >         not to add an additional encapsulation layer.
> >       - Tagged as `deliberate` for ECLAIR.
> > 
> > +   * - D4.10
> > +     - Files that are intended to be included more than once (and have
> > +       a comment that says this explicitly) do not need to conform to the
> > +       directive.
> > +     - Tagged as `safe` for ECLAIR.
> > +
> > +   * - D4.10
> > +     - There are autogenerated files that do not need to comply to the
> > +       directive.
> > +     - Tagged as `safe` for ECLAIR. Such files are:
> > +        - xen/include/generated/autoconf.h
> > +
> >     * - D4.10
> >       - Including multiple times a .c file is safe because every function or
> > data item
> >         it defines would in (the common case) be already defined.
> > diff --git a/xen/arch/x86/include/asm/cpufeatures.h
> > b/xen/arch/x86/include/asm/cpufeatures.h
> > index 9e3ed21c02..69041219cb 100644
> > --- a/xen/arch/x86/include/asm/cpufeatures.h
> > +++ b/xen/arch/x86/include/asm/cpufeatures.h
> > @@ -1,6 +1,6 @@
> > -/*
> > - * Explicitly intended for multiple inclusion.
> > - */
> > +/* This file is intended to be included multiple times. */
> > +/* #ifndef X86_CPUFEATURES_H */
> > +/* #define X86_CPUFEATURES_H */
> > 
> 
> Are these two lines really needed? I may be mistaken, but I think the
> violation's first location would be the #include below with a comment a couple
> of lines above captured by the config at the top [1]. @Federico thoughts?

Without these 2 lines, ECLAIR complains about the following:

#include 
       ^
 MC3A2.D4.10non-compliant start of header file


https://gitlab.com/xen-project/people/sstabellini/xen/-/jobs/10420715821

https://saas.eclairit.com:3787/fs/var/local/eclair/xen-project.ecdf/xen-project/people/sstabellini/xen/ECLAIR_normal/ppp3/X86_64/10420715821/PROJECT.ecd;/sources/xen/arch/x86/include/asm/cpufeatures.h.html#R1_1{%22select%22:true,%22selection%22:{%22hiddenAreaKinds%22:[],%22hiddenSubareaKinds%22:[],%22show%22:false,%22selector%22:{%22enabled%22:true,%22negated%22:true,%22kind%22:0,%22domain%22:%22kind%22,%22inputs%22:[{%22enabled%22:true,%22text%22:%22violation%22}]}}}



From xen-devel-bounces@lists.xenproject.org Sun Jun 22 21:31:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Jun 2025 21:31:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021900.1397620 (Exim 4.92)
	(envelope-from )
	id 1uTSH9-0000gs-RQ; Sun, 22 Jun 2025 21:30:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021900.1397620; Sun, 22 Jun 2025 21: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 1uTSH9-0000gl-Ol; Sun, 22 Jun 2025 21:30:55 +0000
Received: by outflank-mailman (input) for mailman id 1021900;
 Sun, 22 Jun 2025 21:30:54 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uTSH8-0000gf-M5
 for xen-devel@lists.xenproject.org; Sun, 22 Jun 2025 21:30:54 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org
 [2600:3c04:e001:324:0:1991:8:25])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2b60e598-4fb0-11f0-a30f-13f23c93f187;
 Sun, 22 Jun 2025 23:30:51 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 0FAA660052;
 Sun, 22 Jun 2025 21:30:50 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id A7683C4CEE3;
 Sun, 22 Jun 2025 21:30:47 +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: 2b60e598-4fb0-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750627849;
	bh=1WHOrDmxX+S1gNKbRkBpiy7iIDp48xtuOEDupSqobM4=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=iRIik7bKG8mJzo+hrcx5IoM2c7eVDVEKHC5+SQzD1TKcYx9MoHqxAPPWcjQz9RLtN
	 VvO0oYydDVJQlybAShjw/MT+pduBYIXtTUoXCDeqePktxG1uR6gQkwp0FMkuveWpyb
	 o/CGbpHluranEg1JlaIO1kCBDPAZwJYaJuM0J7DMtkSvvuc5tHIiPakKfL8p0uvtOT
	 04vZJ9GhxaiX0ddhVEQ+/Ro2P6xpk96jX0mvK6TXjqKjSeTFVvhpcsu9tm5TxqH5PT
	 ail4EpJqCWbm2apJloWeM0aB5K3JBE9bspqDjbREhHblxkbK2pGTbF/OBgz7hM9Wsx
	 zaaNThSFvH1/A==
Date: Sun, 22 Jun 2025 14:30:46 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Oleksii Moisieiev , jbeulich@suse.com, 
    roger.pau@citrix.com
cc: Stefano Stabellini , 
    "xen-devel@lists.xenproject.org" , 
    Andrew Cooper , 
    Anthony PERARD , 
    Bertrand Marquis , 
    Juergen Gross , Julien Grall , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    Grygorii Strashko 
Subject: Re: [RFC PATCH v4 5/8] xen/domctl: extend XEN_DOMCTL_assign_device
 to handle not only iommu
In-Reply-To: <1780646c-cb6f-4508-86c8-a573fbc09f6a@epam.com>
Message-ID: 
References:  <4f58bf9c47c40413ee9250c4cd21458382aac857.1747669845.git.oleksii_moisieiev@epam.com>  
  <1780646c-cb6f-4508-86c8-a573fbc09f6a@epam.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Thu, 19 Jun 2025, Oleksii Moisieiev wrote:
> On 18/06/2025 03:04, Stefano Stabellini wrote:
> > On Thu, 12 Jun 2025, Oleksii Moisieiev wrote:
> >> Hi Stefano,
> >>
> >> I'm very sorry for a long silence. Please see my answers below:
> >>
> >> On 22/05/2025 03:25, Stefano Stabellini wrote:
> >>> On Mon, 19 May 2025, Oleksii Moisieiev wrote:
> >>>> From: Grygorii Strashko
> >>>>
> >>>> Add chained handling of assigned DT devices to support access-controller
> >>>> functionality through SCI framework, so DT device assign request can be
> >>>> passed to FW for processing and enabling VM access to requested device
> >>>> (for example, device power management through FW interface like SCMI).
> >>>>
> >>>> The SCI access-controller DT device processing is chained after IOMMU
> >>>> processing and expected to be executed for any DT device regardless of its
> >>>> protection by IOMMU (or if IOMMU is disabled).
> >>>>
> >>>> This allows to pass not only IOMMU protected DT device through
> >>>> xl.cfg:"dtdev" property for processing:
> >>>>
> >>>> dtdev = [
> >>>>       "/soc/video@e6ef0000", <- IOMMU protected device
> >>>>       "/soc/i2c@e6508000", <- not IOMMU protected device
> >>>> ]
> >>>>
> >>>> The change is done in two parts:
> >>>> 1) update iommu_do_dt_domctl() to check for dt_device_is_protected() and
> >>>> not fail if DT device is not protected by IOMMU
> >>>> 2) add chained call to sci_do_domctl() in do_domctl()
> >>>>
> >>>> Signed-off-by: Grygorii Strashko
> >>>> Signed-off-by: Oleksii Moisieiev
> >>>> ---
> >>>>
> >>>>
> >>>>
> >>>>    xen/arch/arm/firmware/sci.c             | 37 +++++++++++++++++++++++++
> >>>>    xen/arch/arm/include/asm/firmware/sci.h | 14 ++++++++++
> >>>>    xen/common/domctl.c                     | 19 +++++++++++++
> >>>>    xen/drivers/passthrough/device_tree.c   |  6 ++++
> >>>>    4 files changed, 76 insertions(+)
> >>>>
> >>>> diff --git a/xen/arch/arm/firmware/sci.c b/xen/arch/arm/firmware/sci.c
> >>>> index e1522e10e2..8efd541c4f 100644
> >>>> --- a/xen/arch/arm/firmware/sci.c
> >>>> +++ b/xen/arch/arm/firmware/sci.c
> >>>> @@ -126,6 +126,43 @@ int sci_assign_dt_device(struct domain *d, struct dt_device_node *dev)
> >>>>        return 0;
> >>>>    }
> >>>>    
> >>>> +int sci_do_domctl(struct xen_domctl *domctl, struct domain *d,
> >>>> +                  XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
> >>>> +{
> >>>> +    struct dt_device_node *dev;
> >>>> +    int ret = 0;
> >>>> +
> >>>> +    switch ( domctl->cmd )
> >>>> +    {
> >>>> +    case XEN_DOMCTL_assign_device:
> >>>> +        ret = -EOPNOTSUPP;
> >>> Are you sure -EOPNOTSUPP is the right error code for the 3 checks below?
> >> The -EOPNOTSUPP code is used because this is part of a chained call after
> >> iommu_do_domctl, as stated in xen/common/domctl.c:859. The
> >> XEN_DOMCTL_assign_device
> >> call is expected to handle any DT device, regardless of whether the DT
> >> device is
> >> protected by an IOMMU or if the IOMMU is disabled.
> >> The following cases are considered:
> >>
> >> 1. IOMMU Protected Device (Success)
> >>
> >> If the device is protected by the IOMMU and iommu_do_domctl returns 0,
> >> we continue
> >> processing the DT device by calling sci_do_domctl.
> >>
> >> 2. IOMMU Disabled (-EOPNOTSUPP from iommu_do_domctl)
> >>
> >> If iommu_do_domctl returns -EOPNOTSUPP, indicating that the IOMMU is
> >> disabled,
> >> we still proceed to call sci_do_domctl.
> > OK this makes sense.  I think it is OK to have a special error code to
> > say "the IOMMU is disabled" but I don't know if it is a good idea to try
> > to use -EOPNOTSUPP for that. -EOPNOTSUPP could mean a hypervisor
> > configuration with domctl disabled, for instance.
> >
> > It might be wiser to use a different error code. Maybe ENOENT?
> >
> I see that in the following commit:
> 
> 71e617a6b8 (use is_iommu_enabled() where appropriate..., 2019-09-17)
> 
> -ENOSYS return code was changed to -EOPNOTSUPP in iommu_do_domctl.
> 
> It's not clear to me why this was done from the commit description.
> 
> Maybe we should add commit author?

Roger and Jan might know


From xen-devel-bounces@lists.xenproject.org Sun Jun 22 21:50:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Jun 2025 21:50:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021907.1397630 (Exim 4.92)
	(envelope-from )
	id 1uTSaM-0003SY-CX; Sun, 22 Jun 2025 21:50:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021907.1397630; Sun, 22 Jun 2025 21:50: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 1uTSaM-0003SR-9x; Sun, 22 Jun 2025 21:50:46 +0000
Received: by outflank-mailman (input) for mailman id 1021907;
 Sun, 22 Jun 2025 21:50: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 1uTSaL-0003SL-2V
 for xen-devel@lists.xenproject.org; Sun, 22 Jun 2025 21:50:45 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f0d00838-4fb2-11f0-b894-0df219b8e170;
 Sun, 22 Jun 2025 23:50:42 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 8CA3660EDF;
 Sun, 22 Jun 2025 21:50:40 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8E358C4CEE3;
 Sun, 22 Jun 2025 21:50: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: f0d00838-4fb2-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750629040;
	bh=w2eqZtNz3Hb/uDhj7Xf+kXbPo60Zn2SLlh+4f3k3GEc=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=NxcEixXyXz5dNH2YUXuOyLc76sVKAyNzU750MO7RQR9xkvfOd2TjVLe1yKu8LT3uN
	 5lu83niOGKFBBmLwzfdecn3wgioWSFB5jPWn2fyhr30HhIRvLKsZVLbFipXlUJTeWo
	 vx2lYsm3vKEY8PIfWAW4WMz6PDUqqDomRWw4CCFK0MlloUddSwXAIMo7WN7FrP79iu
	 x8GoWiZzAhxZygIJA3Tyhtq6P4lMw9dQaGYhOx54OnyEvB7mgxZZqiu1XYoGMnwRfE
	 x5tncbuKLnJ9oactmfMKtmWt90samr4rZZwQ07/KO5qDvaqaG3NyngvONWa22S9RJJ
	 0r1FW7Qnlrc8A==
Date: Sun, 22 Jun 2025 14:50:37 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Oleksii Moisieiev 
cc: Julien Grall , Stefano Stabellini , 
    Grygorii Strashko , 
    Bertrand Marquis , 
    "xen-devel@lists.xenproject.org" , 
    Andrew Cooper , 
    Anthony PERARD , 
    Jan Beulich , Juergen Gross , 
    Michal Orzel , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Volodymyr Babchuk 
Subject: Re: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC
 multi-agent driver
In-Reply-To: <90d57a47-56e6-4ddb-83fd-c5b5ee612d21@epam.com>
Message-ID: 
References:  <318044ae12f13b6b297b3f5fda577a1a6cd143da.1747669845.git.oleksii_moisieiev@epam.com>  <04B1F737-5E6B-47C0-B2B9-74288C68E68A@arm.com>
 <50ff5d2b-bd17-4833-b497-0dda6f75964a@epam.com>  <538e4b45-74e7-4992-a9e2-7678756f7612@xen.org> <90d57a47-56e6-4ddb-83fd-c5b5ee612d21@epam.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-1219214540-1750628947=:8066"
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-1219214540-1750628947=:8066
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: 8BIT
Content-ID: 

On Thu, 19 Jun 2025, Oleksii Moisieiev wrote:
> On 18/06/2025 10:22, Julien Grall wrote:
> > Hi,
> >
> > On 18/06/2025 00:38, Stefano Stabellini wrote:
> >> On Thu, 12 Jun 2025, Grygorii Strashko wrote:
> >>> On 02.06.25 10:17, Bertrand Marquis wrote:
> >>>>> On the other hand, if we also want to handle the case where the SCMI
> >>>>> server could be on a separate co-processor, then what this code is 
> >>>>> doing
> >>>>> is not sufficient because we also need a dcache flush, in addition to
> >>>>> the DSB.
> >>>>>
> >>>>> Bertrand, can you double-check?
> >>>>
> >>>> If we want to handle a case where the memory is accessible to a 
> >>>> coprocessor
> >>>> but there is no cache coherency, we need to flush the dcache 
> >>>> definitely.
> >>>>
> >>>> Seeing the amount of data here, I do agree with Stefano that it 
> >>>> would be a
> >>>> good
> >>>> idea to make the provision to flush the data cache in all cases. 
> >>>> Even if the
> >>>> data
> >>>> is accessed by a secure partition or the firmware coherently, 
> >>>> flushing in
> >>>> all cases
> >>>> would have very limited performance impact here.
> >>>>
> >>>> There is the other solution to have some kind of parameter to say 
> >>>> if the
> >>>> accessor
> >>>> has coherent cache access but I do not think the performance impact 
> >>>> here
> >>>> would
> >>>> justify such a complexity.
> >>>>
> >>> The SCMI shmem expected to be mapped as MT_NON_CACHEABLE in all cases.
> >
> > I can't find MT_NON_CACHEABLE anywhere in Xen or Linux. My 
> > interpretation is that the memory attribute would be normal memory non 
> > cacheable. However, this doesn't add up with ...
> >
> Sorry for the confusion. This define was taken from TF-A and it is the 
> same as Xen MT_NORMAL_NC.
> 
> The main idea was to mention that memory is non_cachable.
> 
> >>> The Linux does devm_ioremap() -> ioremap() ->
> >>> (ARM64)  __ioremap((addr), (size), __pgprot(PROT_DEVICE_nGnRE))
> >
> > ... this line. This is device nGnRE which is a lot more restrictive 
> > (for instance it doesn't allow unaligned access).
> >
> In Xen scmi memory is mapped using ioremap_nocache which is mapped as 
> MT_DEVICE_nGnRE (same as linux).
> 
> In TF-A SCMI shared memory is mapped as MT_DEVICE (which is 
> nGnRE: MAIR_DEV_nGnRE).
> 
> Again, sorry for the confusion.
> 
> >>>
> >>> There is also note in docs:
> >>> "+- shmem: shared memory for messages transfer, **Xen page aligned** 
> >>> with
> >>> mapping``p2m_mmio_direct_nc``."
> >>>
> >>> In the case of SCP - the SCMI shmem can be actually be in SRAM.
> >>>
> >>> So, are you sure cache manipulations are required here?
> >>
> >> No, if the memory is mapped as uncacheable everywhere then the cache
> >> manipulations are not needed. However, we probably still need a dsb.
> >>
> >> I understand now why they decided to use __memcpy_fromio in Linux: it is
> >> not MMIO but they needed a memcpy followed by DSB, so they decided to
> >> reuse the existing MMIO functions although the buffer is not MMIO.
> >
> > From my understanding, memcpy_fromio() is not just a mempcy() + dsb. 
> > It also guarantees the access will be aligned (this is not guarantee 
> > by our memcpy()).
> >
>  From my understanding Linux using memcpy_fromio() because memcpy 
> function is highly
> 
> optimized in linux and will produce exception,and looking into the 
> memcpy implementation
> 
> in Xen (xen/arch/arm/arm64/lib/memcpy.S) I'm not sure if it can be used 
> instead of memcpy_fromio. Could you please advise how to proceed?

If we map the memory in Xen as normal memory non-cacheable, then for
sure we should be able to use the regular memcpy plus a DSB at the end.
That's because unaligned accesses are allowed.

On the other hand, if we map the memory in Xen as device memory, then we
need to be careful about alignment.

Looking at xen/arch/arm/arm64/lib/memcpy.S, it seems to me that:
- it uses aligned accesses for size >= 16 bytes
- for size < 16 bytes, accesses might be unaligned depending on the
  alignment of the start address
- the start address, assuming it is the shared memory start address, is
  4K aligned, so we should be fine?

So it seems to me that we should be OK with using the regular memcpy
(plus a DSB at the end). It would be good for someone else to confirm.
--8323329-1219214540-1750628947=:8066--


From xen-devel-bounces@lists.xenproject.org Sun Jun 22 21:58:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Jun 2025 21:58:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021914.1397641 (Exim 4.92)
	(envelope-from )
	id 1uTShS-00044d-2d; Sun, 22 Jun 2025 21:58:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021914.1397641; Sun, 22 Jun 2025 21: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 1uTShR-00044W-Vh; Sun, 22 Jun 2025 21:58:05 +0000
Received: by outflank-mailman (input) for mailman id 1021914;
 Sun, 22 Jun 2025 21: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 1uTShQ-00044Q-Kt
 for xen-devel@lists.xenproject.org; Sun, 22 Jun 2025 21:58:04 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f75c381a-4fb3-11f0-b894-0df219b8e170;
 Sun, 22 Jun 2025 23:58:02 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id D524760052;
 Sun, 22 Jun 2025 21:58:00 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id BC1B4C4CEE3;
 Sun, 22 Jun 2025 21:57:58 +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: f75c381a-4fb3-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750629480;
	bh=nx9S8aKRlmqpd0gqbwBjwEtzKb50thPuQXZaHCOn0o0=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=WXubS/Bk7RKBEV6FqDG3FNf02tYNnHaDyIFg2XnXc/LhsXkZ+gDOcjSHhrTgenRPz
	 MQPZfQrX2/QaXMx4DGgIjnMv/7X4nngY5LX0FT8ecRdUC+wFlgCMrHOq1tVeG7DKWe
	 z92sl/GwSArHW6YF6Z7L2EQ8b6VKmi8+mwI38V+USugRFYVkiZdEkZgggpS4iZnfDv
	 Pjpw5/xTvprgvXjM8cSOie2Odw+mbtZcG/A4Ey3X52ilN/eniQkxF82IVSBEhzUKXb
	 TE/9M9DALBzJb+JUXl/foxiO09+PrhCGwEJZuJPfxgOovyr9uf5p8odldofghJFTCb
	 NWru7BX8h1qYQ==
Date: Sun, 22 Jun 2025 14:57:57 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Oleksii Moisieiev 
cc: Stefano Stabellini , 
    "xen-devel@lists.xenproject.org" , 
    Andrew Cooper , 
    Anthony PERARD , 
    Bertrand Marquis , 
    Jan Beulich , Juergen Gross , 
    Julien Grall , Michal Orzel , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Volodymyr Babchuk , 
    Grygorii Strashko 
Subject: Re: [RFC PATCH v4 8/8] docs: armproposa: l to add separate SCMI node
 for Xen agent
In-Reply-To: 
Message-ID: 
References:  <3f7e1e99f5d1018064f3c4825aff16bd487cf558.1747669845.git.oleksii_moisieiev@epam.com>  
  
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-1007122159-1750629204=:8066"
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-1007122159-1750629204=:8066
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: 8BIT
Content-ID: 

On Thu, 19 Jun 2025, Oleksii Moisieiev wrote:
> On 18/06/2025 03:35, Stefano Stabellini wrote:
> > On Thu, 12 Jun 2025, Oleksii Moisieiev wrote:
> >> On 23/05/2025 23:19, Stefano Stabellini wrote:
> >>> On Mon, 19 May 2025, Oleksii Moisieiev wrote:
> >>>> From: Grygorii Strashko
> >>>>
> >>>> Proposal description to add separate SCMI DT node for Xen management agent
> >>>> under "chosen" or xen-config node, like Hyperlaunch "xen,config".
> >>> I think it is OK to place a larger "xen,config" node under /chosen with
> >>> more information for Xen to setup SCMI more easily.
> >>>
> >>>
> >>>> This proposal introduces a new approach to the Xen multi-domain
> >>>> configuration, where all Xen-specific configuration has been moved
> >>>> under the "/chosen" node. This requires less Dom0 device tree
> >>>> manipulation and isolates Xen configuration from domain configuration.
> >>>>
> >>>> This approach provides the following device tree (DT) parameters:
> >>>>
> >>>> - "xen,scmi-secondary-agents": A Xen-specific parameter under the
> >>>> "/chosen" node, which describes the SCMI agent configuration for
> >>>> the domains.
> >>>> - the SCMI configuration for Xen (privileged agent) and the shared
> >>>> memory configuration for all agents are provided under the "/chosen"
> >>>> node and are used strictly by Xen for its initial configuration.
> >>>> - the scmi_shm and SCMI configuration for Dom0 are placed in the
> >>>> "/firmware/scmi" node so that they can be moved to Dom0 without
> >>>> any changes.
> >>> Isn't the SCMI configuration present in /firmware/scmi referring to the
> >>> privileged agent=0 meant to be used by Xen?
> >>>
> >>> I certainly see benefits in simplifying the configuration and especially
> >>> reducing the amount of changes a user might have to make on the
> >>> underlying device tree, but if the user needs to change /firmware/scmi
> >>> with the Dom0 information, it seems more dangerous and error prone than
> >>> the previous approach.
> >>>
> >> The idea is to move the privileged agent=0 configuration to the /chosen
> >> node and
> >>
> >> assign agent=1 to the Dom0 node under /firmware/scmi.
> >>
> >> Benefits of This Approach:
> >> - No Modification of the Xen DT Node Required
> >>
> >>       This eliminates the need to modify the Xen Device Tree (DT) node
> >> before creating Dom0 in
> >>
> >>       order to set the correct shared memory (shmem).
> >>
> >> -Consistent SCMI Configuration Format
> >>
> >>     The Dom0 DT will have the same SCMI configuration format as other
> >> domains, simplifying the
> >>
> >>     overall configuration process.
> >>
> >> - Unified SCMI Configuration Method
> >>
> >>      There will no longer be a need to use a different approach for SCMI
> >> configuration in Dom0
> >>
> >>     compared to other domains.
> >>
> >> - Separation Between Dom0 and Privileged Node
> >>
> >>         This provides a clear separation between the Dom0 node and the
> >> privileged node.
> >>
> >>         For example:
> >>               If Dom0 only requires the clock protocol, but the Xen SCMI
> >> configuration requires additional protocols,
> >>
> >>               this approach allows Dom0 to receive only the necessary
> >> protocol configuration.
> > I don't think this is a good idea because we end up confusing the data
> > for Xen and the data for the DomUs/Dom0 in the host device tree.
> >
> > I think we should follow these very simple guidelines:
> >
> > - The host DTB (the DTB given to Xen at boot) should be the same for Xen
> >    and for Linux baremetal (no KVM), with the exception of the data under
> >    the /chosen node
> >
> > - We can place Xen specific configurations under the /chosen node in the
> >    host DTB, both Xen hypervisor configuration and also Dom0/DomU
> >    configurations
> >
> > This way, the host information remains generic and the configuration for
> > Xen the domUs/Dom0 is kept clearly separate from the rest. I don't
> > think we can break these two assumptions but we have more freedom with
> > the rest.
> >
> > If we start with these two simple assumptions, here are the
> > consequences:
> >
> > - data under /firmware/scmi should be the same for Xen and baremetal
> >    Linux, ideally it would describe Xen's agent0 channel in both cases
> 
> According to the proposal:
> The data under the Host DT /firmware/scmi node will always point to the 
> default OSPM agent, which will remain
> 
> the same (smc-id and shmem) for both the BSP case (no Xen) and the Xen 
> case (Dom0 domain).
> 
> Meanwhile, the Xen management agent's SCMI node and configuration are 
> expected to be placed under /chosen.
> 
> This approach ensures that the Host DT remains as unchanged as possible.

Yes, my main point is that all the device tree information, except for
what is under /chosen, should be left unchanged between the BSP case (no
Xen) and the Xen case.

We have freedom to decide:
- the information we put under /chosen and how to interpret it
- how to use the information under /firmware/scmi when Xen is present


> Currently:
> 
> The Host DT /firmware/scmi node requires modification to point to the 
> Xen management agent by changing
> 
> the smc-id and shmem values.

I don't think we should require changes to /firmware/scmi in the host DT
when Xen is present.

Often, people don't know when or if Xen is present at the time the
Device Tree is generated. So it is best to avoid modification (outside
of /chosen).


> At boot time, during Dom0 creation, the SCMI multi-agent driver reverts 
> these changes.
>
>
> > - We can add as many nodes as we like under /chosen, including a
> >    xen,config node and also additional nodes for the domains config
> >
> > - We can define the new nodes under /chosen to be as simple as possible
> >    for the user to configure them, while also trying to minimize
> >    complexity in Xen in terms of DT manipulations
> >
> >
> >
> > If the Xen SCMI configuration data cannot be the same as the Linux
> > baremetal SCMI configuration (i.e. /firmware/scmi has to be different in
> > the two cases) I would still suggest to avoid modifying /firmware/scmi
> > for Xen and instead provide the Xen configuration under /chosen. It is
> > important to keep everything in the host DTB (except /chosen) the same
> > between Linux baremetal and Xen.
> >
> > However, we can add a new node similar to /firmware/scmi under /chosen
> > specifically for Xen, such as /chosen/xen-config/scmi
> >
> > The Dom0 configuration cannot be expected to be under /firmware/scmi.
> > However, it could also be defined under /chosen.
> 
> No. The idea is to keep it and provide unchanged, but with possibility 
> to "disable SCMI for Dom0"
> - now with Xen bootarg parameter.
> > Keep in mind that the more we add to /chosen the more difficult it will
> > be for the user to configure the system. I think we should plan ahead to
> > have ImageBuilder be able to generate the DT nodes under /chosen for Xen
> > starting from the simplest possible configuration format provided by the
> > user. The more complex and rich are the device tree nodes under /chosen,
> > the more important is the documentation and ImageBuilder support for it.
> >
> >
> Regarding all the other points you’ve mentioned – this is exactly what 
> we are trying to achieve
> 
> with this proposal.

OK good


> We are proposing the following changes to the approach so that all 
> requirements are met, and the
> 
> Xen device tree (DT) will remain the same as the Host Platform DT (BSP 
> Linux), except for the /chosen node:
> 
> ```
> 
>      /{
> 
>          chosen {
>              ...
> 
>              // Xen SCMI management channel
>              scmi_shm_xen : sram@47ff1000 {
>                  compatible = "arm,scmi-shmem";
>                  reg = <0x0 0x47ff1000 0x0 0x1000>;
>              };
> 
>              scmi_xen: scmi {
>                  compatible = "arm,scmi-smc";
>                  arm,smc-id = <0x82000003>; <--- Xen manegement agent smc-id
>                  #address-cells = < 1>;
>                  #size-cells = < 0>;
>                  #access-controller-cells = < 1>;
>                  shmem = <&scmi_shm_xen>; <--- Xen manegement agent shmem
>              };
> 
>              // SCMI multi-agent configuration
>              scmi_shm_2: sram@47ff2000 {
>                      compatible = "arm,scmi-shmem";
>                      reg = <0x0 0x47ff2000 0x0 0x1000>;
>              };
>              scmi_shm_3: sram@47ff3000 {
>                      compatible = "arm,scmi-shmem";
>                      reg = <0x0 0x47ff3000 0x0 0x1000>;
>              };
>              scmi_shm_4: sram@47ff4000 {
>                      compatible = "arm,scmi-shmem";
>                      reg = <0x0 0x47ff4000 0x0 0x1000>;
>              };
> 
>              xen,scmi-secondary-agents = <
>                          0x82000002 &scmi_shm   1
>                          0x82000004 &scmi_shm_2 2
>                          0x82000005 &scmi_shm_3 3
>                          0x82000006 &scmi_shm_4 4>;
>          };
> 
>          // Host SCMI OSPM channel - provided to the Dom0 as is if SCMI 
> enabled for it (same address as Host Platform DT)
>          scmi_shm: sram@47ff0000 {
>                  compatible = "arm,scmi-shmem";
>                  reg = <0x0 0x47ff0000 0x0 0x1000>;
>          };
> 
>          firmware { <-- the below configuration is the same as Host 
> Platform DT and will be passed to Dom0
>              scmi: scmi {
>                  compatible = "arm,scmi-smc";
>                  arm,smc-id = <0x82000002>; <--- Host OSPM agent smc-id 
> which is the same as in Host Platform DT
>                  #address-cells = < 1>;
>                  #size-cells = < 0>;
>                  shmem = <&scmi_shm>; <--- Host OSPM agent shmem (same 
> address as Host Platform DT)
> 
>                  protocol@X{
>                  };
>              };
>          };
>      }
> 
> ```

I think this is OK, thank you!


> >>>> This configuration allows the use of Xen-specific nodes to provide
> >>>> information strictly needed by Xen while using the default SCMI
> >>>> configuration for Dom0 and other domains. As a result, no additional
> >>>> bindings need to be introduced to the device tree.
> >>> This is not actually implemented by this patch series, right?
> >> It is not. Just posted this document as a proposal.
> >>>> Signed-off-by: Grygorii Strashko
> >>>> Signed-off-by: Oleksii Moisieiev
> >>>> ---
> >>>>
> >>>>
> >>>>
> >>>>    .../arm/firmware/arm-scmi-proposal.rst        | 224 ++++++++++++++++++
> >>>>    1 file changed, 224 insertions(+)
> >>>>    create mode 100644 docs/hypervisor-guide/arm/firmware/arm-scmi-proposal.rst
> >>>>
> >>>> diff --git a/docs/hypervisor-guide/arm/firmware/arm-scmi-proposal.rst b/docs/hypervisor-guide/arm/firmware/arm-scmi-proposal.rst
> >>>> new file mode 100644
> >>>> index 0000000000..fcc2ed2b65
> >>>> --- /dev/null
> >>>> +++ b/docs/hypervisor-guide/arm/firmware/arm-scmi-proposal.rst
> >>>> @@ -0,0 +1,224 @@
> >>>> +
> >>>> +Proposal for SCMI multi-agent driver bindings
> >>>> +=============================================
> >>>> +
> >>>> +Now the Xen configuration for SCMI multi-agent support is done in a bit complicated way, especially
> >>>> +from SCMI multi-agent driver initialization and Dom0 DT manipulation point of view.
> >>>> +Also it does not take into account future requirements to support SCP SCMI FW.
> >>>> +
> >>>> +To enable SCMI multi-agent user need:
> >>>> +
> >>>> +* take host DT with basic SCMI enabled
> >>>> +* add SCMI shared-memory nodes for all agents
> >>>> +* update SCMI node to point on SCMI Xen management channel (``[smc-id, shmem]``)
> >>>> +* add "xen,scmi-secondary-agents" property to the "\chosen" node
> >>>> +
> >>>> +.. code::
> >>>> +
> >>>> +   chosen {
> >>>> +      xen,scmi-secondary-agents = <
> >>>> +                    1 0x82000003 &scmi_shm_1
> >>>> +                    2 0x82000004 &scmi_shm_2
> >>>> +                    3 0x82000005 &scmi_shm_3
> >>>> +                    4 0x82000006 &scmi_shm_4>;
> >>>> +    }
> >>>> +
> >>>> +    /{
> >>>> +            // SCMI shared-memory nodes for all agents
> >>>> +            scmi_shm_0 : sram@47ff0000 {
> >>>> +                compatible = "arm,scmi-shmem";
> >>>> +                reg = <0x0 0x47ff0000 0x0 0x1000>;
> >>>> +            };
> >>>> +            scmi_shm_1: sram@47ff1000 {
> >>>> +                    compatible = "arm,scmi-shmem";
> >>>> +                    reg = <0x0 0x47ff1000 0x0 0x1000>;
> >>>> +            };
> >>>> +            scmi_shm_2: sram@47ff2000 {
> >>>> +                    compatible = "arm,scmi-shmem";
> >>>> +                    reg = <0x0 0x47ff2000 0x0 0x1000>;
> >>>> +            };
> >>>> +            scmi_shm_3: sram@47ff3000 {
> >>>> +                    compatible = "arm,scmi-shmem";
> >>>> +                    reg = <0x0 0x47ff3000 0x0 0x1000>;
> >>>> +            };
> >>>> +            scmi_shm_4: sram@47ff4000 {
> >>>> +                    compatible = "arm,scmi-shmem";
> >>>> +                    reg = <0x0 0x47ff4000 0x0 0x1000>;
> >>>> +            };
> >>>> +
> >>>> +            firmware {
> >>>> +                scmi: scmi {
> >>>> +                    compatible = "arm,scmi-smc";
> >>>> +                    arm, smc - id = <0x82000002>; <--- Xen management agent channel "smc-id"
> >>>> +                    #address-cells = < 1>;
> >>>> +                    #size-cells = < 0>;
> >>>> +                    #access-controller-cells = < 1>;
> >>>> +                    shmem = <&scmi_shm_0>; <--- Xen management agent channel "shmem"
> >>>> +
> >>>> +                    protocol@X{
> >>>> +                    };
> >>>> +                };
> >>>> +            };
> >>>> +    }
> >>>> +
> >>>> +Important thing to note is that all information about multi-channel support is strictly Xen specific.
> >>>> +
> >>>> +During initialization the SCMI multi-agent driver uses Host DT SCMI node and
> >>>> +"xen,scmi-secondary-agents" property to init itself and then, during Dom0 creation, manipulates
> >>>> +Dom0 DT to remove Xen specific SCMI info and update dom0 SCMI nodes with Dom0 SCMI agent specific
> >>>> +information.
> >>>> +
> >>>> +There are two negative points:
> >>>> +
> >>>> +1) Double DT modification - one is user to set up SCMI Xen support in Host DT, second -
> >>>> +   Dom0 DT manipulation.
> >>>> +2) In case of future support of mailbox shared-memory transport there could be up to 4 mailboxes and
> >>>> +   up to 2 shared-memories per SCMI agent channel.
> >>>> +
> >>>> +Hence SCMI multi-agent support is Xen specific knowledge there is a proposal to add it as Xen
> >>>> +specific DT definitions and so minimize Host and Dom0 DT manipulations.
> >>>> +Those definitions can be added in "/chosen" or, ideally, in "xen,config" node (like in Hyperlaunch design).
> >>>> +
> >>>> +The SCMI binding stays generic, just two SCMI nodes defined - one for Xen management channel and
> >>>> +one for Host Dom0 OSPM.
> >>>> +
> >>>> +Example of using "chosen" for configuration:
> >>>> +
> >>>> +.. code::
> >>>> +
> >>>> +    /{
> >>>> +
> >>>> +        chosen {
> >>>> +            ...
> >>>> +
> >>>> +            // Xen SCMI management channel
> >>>> +            scmi_shm_0 : sram@47ff0000 {
> >>>> +                compatible = "arm,scmi-shmem";
> >>>> +                reg = <0x0 0x47ff0000 0x0 0x1000>;
> >>>> +            };
> >>>> +            scmi_xen: scmi {
> >>>> +                compatible = "arm,scmi-smc";
> >>>> +                arm,smc-id = <0x82000002>; <--- Xen manegement agent smc-id
> >>>> +                #address-cells = < 1>;
> >>>> +                #size-cells = < 0>;
> >>>> +                #access-controller-cells = < 1>;
> >>>> +                shmem = <&scmi_shm_0>; <--- Xen manegement agent shmem
> >>>> +            };
> >>>> +
> >>>> +            // SCMI multi-agent configuration
> >>>> +            scmi_shm_2: sram@47ff2000 {
> >>>> +                    compatible = "arm,scmi-shmem";
> >>>> +                    reg = <0x0 0x47ff2000 0x0 0x1000>;
> >>>> +            };
> >>>> +            scmi_shm_3: sram@47ff3000 {
> >>>> +                    compatible = "arm,scmi-shmem";
> >>>> +                    reg = <0x0 0x47ff3000 0x0 0x1000>;
> >>>> +            };
> >>>> +            scmi_shm_4: sram@47ff4000 {
> >>>> +                    compatible = "arm,scmi-shmem";
> >>>> +                    reg = <0x0 0x47ff4000 0x0 0x1000>;
> >>>> +            };
> >>>> +            xen,scmi-secondary-agents = <
> >>>> +                        1 0x82000003 &scmi_shm
> >>>> +                        2 0x82000004 &scmi_shm_2
> >>>> +                        3 0x82000005 &scmi_shm_3
> >>>> +                        4 0x82000006 &scmi_shm_4>;
> >>>> +        };
> >>>> +
> >>>> +        // Host SCMI OSPM channel - provided to the Dom0 as is if SCMI enabled for it
> >>>> +        scmi_shm: sram@47ff1000 {
> >>>> +                compatible = "arm,scmi-shmem";
> >>>> +                reg = <0x0 0x47ff1000 0x0 0x1000>;
> >>>> +        };
> >>>> +
> >>>> +        firmware {
> >>>> +            scmi: scmi {
> >>>> +                compatible = "arm,scmi-smc";
> >>>> +                arm,smc-id = <0x82000003>; <--- Host OSPM agent smc-id
> >>>> +                #address-cells = < 1>;
> >>>> +                #size-cells = < 0>;
> >>>> +                shmem = <&scmi_shm>; <--- Host OSPM agent shmem
> >>> By OSPM you mean Dom0 and not Xen? So this is a change compared to a
> >>> device tree for baremetal Linux without Xen?
> OSPM is OS in general, for example Linux.
> >>> Let me ask the same question differently. In the case of barematal Linux
> >>> without Xen (no KVM), what would Linux see under /firmware/scmi as
> >>> smc-id and shmem? The same as the one that Xen would use for itself? Or
> >>> the same as the ones that Dom0 would use when Xen is present?
> >> If this DT is used with the baremetal Linux - then the Linux Kernel will
> >>
> >> see Dom0 "smc-id" and "shmen" under /firmware/scmi.
> >>
> >>>> +                protocol@X{
> >>>> +                };
> >>>> +            };
> >>>> +        };
> >>>> +    }
> >>>> +
> >>>> +
> >>>> +In the above case:
> >>>> +
> >>>> +1) Xen SCMI multi-agent can be probed with DT configuration from "chosen" (or special "xen,config")
> >>>> +   node and all Xen related nodes can be easily dropped from Dom0 DT.
> >>>> +2) Host SCMI OSPM channel DT nodes can be copied to Dom0 DT without changes if SCMI enabled for it.
> >>>> +3) Future support for mailbox shared-memory transport (SCP SCMI FW) can be simplified as no more
> >>>> +   manipulation required with Dom0 SCMI "arm,smc-id" and "shmem" DT properties.
> >>> Yes, I can see the benefit if we can arrange it so that the underlying
> >>> host device tree is the same that Linux would use baremetal. And all the
> >>> extra configuration is placed under /chosen in "xen,config" node or
> >>> similar. I would probably call it "xen,scmi".
> >> Personally, I would keep "xen,config" as it leaves room to add additional
> >>
> >> configuration nodes in the future.
> >>
> >>>> +Example of using "xen,config" for configuration:
> >>>> +
> >>>> +.. code::
> >>>> +
> >>>> +    hypervisor {
> >>>> +        compatible = “hypervisor,xen”
> >>>> +
> >>>> +        // Configuration container
> >>>> +        config {
> >>>> +            compatible = "xen,config";
> >>>> +            ...
> >>>> +
> >>>> +            // Xen SCMI management channel
> >>>> +            scmi_shm_0 : sram@47ff0000 {
> >>>> +                compatible = "arm,scmi-shmem";
> >>>> +                reg = <0x0 0x47ff0000 0x0 0x1000>;
> >>>> +            };
> >>>> +            scmi_xen: scmi {
> >>>> +                compatible = "arm,scmi-smc";
> >>>> +                arm,smc-id = <0x82000002>; <--- Xen manegement agent smc-id
> >>>> +                #address-cells = < 1>;
> >>>> +                #size-cells = < 0>;
> >>>> +                #access-controller-cells = < 1>;
> >>>> +                shmem = <&scmi_shm_0>; <--- Xen manegement agent shmem
> >>>> +            };
> >>>> +
> >>>> +            // SCMI multi-agent configuration
> >>>> +            scmi_shm_2: sram@47ff2000 {
> >>>> +                    compatible = "arm,scmi-shmem";
> >>>> +                    reg = <0x0 0x47ff2000 0x0 0x1000>;
> >>>> +            };
> >>>> +            scmi_shm_3: sram@47ff3000 {
> >>>> +                    compatible = "arm,scmi-shmem";
> >>>> +                    reg = <0x0 0x47ff3000 0x0 0x1000>;
> >>>> +            };
> >>>> +            scmi_shm_4: sram@47ff4000 {
> >>>> +                    compatible = "arm,scmi-shmem";
> >>>> +                    reg = <0x0 0x47ff4000 0x0 0x1000>;
> >>>> +            };
> >>>> +            xen,scmi-secondary-agents = <
> >>>> +                        1 0x82000003 &scmi_shm
> >>>> +                        2 0x82000004 &scmi_shm_2
> >>>> +                        3 0x82000005 &scmi_shm_3
> >>>> +                        4 0x82000006 &scmi_shm_4>;
> >>>> +        };
> >>>> +    };
> >>>> +
> >>>> +    /{
> >>>> +        // Host SCMI OSPM channel - provided to the Dom0 as is if SCMI enabled for it
> >>>> +        scmi_shm: sram@47ff1000 {
> >>>> +                compatible = "arm,scmi-shmem";
> >>>> +                reg = <0x0 0x47ff1000 0x0 0x1000>;
> >>>> +        };
> >>>> +
> >>>> +        firmware {
> >>>> +            scmi: scmi {
> >>>> +                compatible = "arm,scmi-smc";
> >>>> +                arm,smc-id = <0x82000003>; <--- Host OSPM agent smc-id
> >>>> +                #address-cells = < 1>;
> >>>> +                #size-cells = < 0>;
> >>>> +                shmem = <&scmi_shm>; <--- Host OSPM agent shmem
> >>>> +
> >>>> +                protocol@X{
> >>>> +                };
> >>>> +            };
> >>>> +        };
> >>>> +    }
> >>>> -- 
> >>>> 2.34.1
--8323329-1007122159-1750629204=:8066--


From xen-devel-bounces@lists.xenproject.org Sun Jun 22 22:16:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Jun 2025 22:16:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021926.1397651 (Exim 4.92)
	(envelope-from )
	id 1uTSyd-0006z6-KX; Sun, 22 Jun 2025 22:15:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021926.1397651; Sun, 22 Jun 2025 22:15: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 1uTSyd-0006yz-G4; Sun, 22 Jun 2025 22:15:51 +0000
Received: by outflank-mailman (input) for mailman id 1021926;
 Sun, 22 Jun 2025 22:15: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 1uTSyc-0006yd-6f
 for xen-devel@lists.xenproject.org; Sun, 22 Jun 2025 22:15:50 +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 730cd617-4fb6-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 00:15:48 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 5D5F3A4F04B;
 Sun, 22 Jun 2025 22:15:47 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id F3FAFC4CEE3;
 Sun, 22 Jun 2025 22:15: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: 730cd617-4fb6-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750630546;
	bh=un3rS6+QpSEEAK1ytKfjON0SkjC6hH8RLOHA7nRnglk=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=WSH9aW18nEjaK1qpJe6jUCCG90jFkGSEc8ZTi2AE09iK5Gh7sZfIx440keoYdTkAQ
	 UvzcqvOtX9op3eUVA6t4JkMihjkyFOfZK5bISlHSKR6VfCtrsYDm9t/overDbB+BwS
	 B8MYF9CV5R/7aNJPRC9A6QTYHtiYEaRF/zg9edzvg6REgAOPiD5be9FAbswgEK5WJK
	 JzSVuRCXir8F7w22LG3MSe3qoBfCT6KmfvtOw2ibOKkVzZpLouur1mxwJNWyN6SrAl
	 Af6KKESxNyLKYduCWhApByDcyPnHYYoQVAaUw6PCDLPUXSIkCceqZ0VjVMejT01zwu
	 VvEElQHM1jKxQ==
Date: Sun, 22 Jun 2025 15:15:43 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Oleksii Moisieiev 
cc: Stefano Stabellini , 
    "xen-devel@lists.xenproject.org" , 
    Andrew Cooper , 
    Anthony PERARD , 
    Bertrand Marquis , 
    Jan Beulich , Juergen Gross , 
    Julien Grall , Michal Orzel , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Volodymyr Babchuk , 
    Grygorii Strashko 
Subject: Re: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC
 multi-agent driver
In-Reply-To: <769aad0a-8bee-45c6-8c5c-35f9d47ed8ae@epam.com>
Message-ID: 
References:  <318044ae12f13b6b297b3f5fda577a1a6cd143da.1747669845.git.oleksii_moisieiev@epam.com>  <6080ff71-2634-4269-8a63-fdafdf03f01b@epam.com>
  <769aad0a-8bee-45c6-8c5c-35f9d47ed8ae@epam.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-1278577597-1750628131=:8066"
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-1278577597-1750628131=:8066
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: 8BIT
Content-ID: 

On Thu, 19 Jun 2025, Oleksii Moisieiev wrote:
> On 18/06/2025 02:22, Stefano Stabellini wrote:
> > On Thu, 12 Jun 2025, Oleksii Moisieiev wrote:
> >> Hi Stefano,
> >>
> >> I'm very sorry for a long silence. Please see my answers below:
> >>
> >>
> >> On 23/05/2025 23:06, Stefano Stabellini wrote:
> >>> One question for Bertrand below
> >>>
> >>>
> >>> On Mon, 19 May 2025, Oleksii Moisieiev wrote:
> >>>> This patch introduces SCI driver to support for ARM EL3 Trusted Firmware-A
> >>>> (TF-A) which provides SCMI interface with multi-agnet support, as shown
> >>>> below.
> >>>>
> >>>>     +-----------------------------------------+
> >>>>     |                                         |
> >>>>     | EL3 TF-A SCMI                           |
> >>>>     +-------+--+-------+--+-------+--+-------++
> >>>>     |shmem0 |  |shmem1 |  |shmem2 |  |shmemX |
> >>>>     +-----+-+  +---+---+  +--+----+  +---+---+
> >>>> smc-id0 |        |         |           |
> >>>> agent0  |        |         |           |
> >>>>     +-----v--------+---------+-----------+----+
> >>>>     |              |         |           |    |
> >>>>     |              |         |           |    |
> >>>>     +--------------+---------+-----------+----+
> >>>>            smc-id1 |  smc-id2|    smc-idX|
> >>>>            agent1  |  agent2 |    agentX |
> >>>>                    |         |           |
> >>>>               +----v---+  +--v-----+  +--v-----+
> >>>>               |        |  |        |  |        |
> >>>>               | Dom0   |  | Dom1   |  | DomX   |
> >>>>               |        |  |        |  |        |
> >>>>               |        |  |        |  |        |
> >>>>               +--------+  +--------+  +--------+
> >>>>
> >>>> The EL3 SCMI multi-agent firmware expected to provide SCMI SMC/HVC shared
> >>>> memory transport for every Agent in the system.
> >>>>
> >>>> The SCMI Agent transport channel defined by pair:
> >>>>    - smc-id: SMC/HVC id used for Doorbell
> >>>>    - shmem: shared memory for messages transfer, Xen page aligned,
> >>>>    p2m_mmio_direct_nc.
> >>>>
> >>>> The follwoing SCMI Agents expected to be defined by SCMI FW to enable SCMI
> >>>> multi-agent functionality under Xen:
> >>>> - Xen manegement agent: trusted agents that accesses to the Base Protocol
> >>>> commands to configure agent specific permissions
> >>>> - OSPM VM agents: non-trusted agent, one for each Guest domain which is
> >>>>     allowed direct HW access. At least one OSPM VM agent has to be provided
> >>>>     by FW if HW is handled only by Dom0 or Driver Domain.
> >>>>
> >>>> The EL3 SCMI FW expected to implement following Base protocol messages:
> >>>> - BASE_DISCOVER_AGENT
> >>>> - BASE_RESET_AGENT_CONFIGURATION (optional)
> >>>> - BASE_SET_DEVICE_PERMISSIONS (optional)
> >>>>
> >>>> The SCI SCMI SMC multi-agent driver implements following functionality:
> >>>> - It's initialized based on the Host DT SCMI node (only one SCMI interface
> >>>> is supported) which describes Xen management agent SCMI interface.
> >>>>
> >>>> scmi_shm_0 : sram@47ff0000 {
> >>>>       compatible = "arm,scmi-shmem";
> >>>>       reg = <0x0 0x47ff0000 0x0 0x1000>;
> >>>> };
> >>>> firmware {
> >>>>       scmi: scmi {
> >>>>           compatible = "arm,scmi-smc";
> >>>>           arm, smc - id = <0x82000002>; // Xen manegement agent smc-id
> >>> some extra spaces, it might be a copy/paste error
> >> +
> >>>>           \#address-cells = < 1>;
> >>>>           \#size-cells = < 0>;
> >>>>           \#access-controller - cells = < 1>;
> >>>>           shmem = <&scmi_shm_0>; // Xen manegement agent shmem
> >>>>
> >>>>           protocol@X{
> >>>>           };
> >>>>       };
> >>>> };
> >>>>
> >>>> - It obtains Xen specific SCMI Agent's configuration from the Host DT,
> >>>> probes Agents and build SCMI Agents list; The Agents configuration is taken from:
> >>>>
> >>>> chosen {
> >>>>     xen,scmi-secondary-agents = <
> >>>>               1 0x82000003 &scmi_shm_1
> >>>>               2 0x82000004 &scmi_shm_2
> >>>>               3 0x82000005 &scmi_shm_3
> >>>>               4 0x82000006 &scmi_shm_4>;
> >>>> }
> >>>>
> >>>> /{
> >>>>       scmi_shm_1: sram@47ff1000 {
> >>>>               compatible = "arm,scmi-shmem";
> >>>>               reg = <0x0 0x47ff1000 0x0 0x1000>;
> >>>>       };
> >>>>       scmi_shm_2: sram@47ff2000 {
> >>>>               compatible = "arm,scmi-shmem";
> >>>>               reg = <0x0 0x47ff2000 0x0 0x1000>;
> >>>>       };
> >>>>       scmi_shm_3: sram@47ff3000 {
> >>>>               compatible = "arm,scmi-shmem";
> >>>>               reg = <0x0 0x47ff3000 0x0 0x1000>;
> >>>>       };
> >>>> }
> >>>>     where first item is "agent_id", second - "arm,smc-id", and third - "arm,scmi-shmem" for
> >>>>     this agent_id.
> >>>>
> >>>>     Note that Xen is the only one entry in the system which need to know
> >>>>     about SCMI multi-agent support.
> >>>>
> >>>> - It implements the SCI subsystem interface required for configuring and
> >>>> enabling SCMI functionality for Dom0/hwdom and Guest domains. To enable
> >>>> SCMI functionality for domain it has to be configured with unique supported
> >>>> SCMI Agent_id and use corresponding SCMI SMC/HVC shared memory transport
> >>>> [smc-id, shmem] defined for this SCMI Agent_id.
> >>>> - Once Xen domain is configured it can communicate with EL3 SCMI FW:
> >>>>     -- zero-copy, the guest domain puts SCMI message in shmem;
> >>>>     -- the guest triggers SMC/HVC exception with smc-id (doorbell);
> >>>>     -- the Xen driver catches exception, do checks and synchronously forwards
> >>>>     it to EL3 FW.
> >>>> - the Xen driver sends BASE_RESET_AGENT_CONFIGURATION message to Xen
> >>>>     management agent channel on domain destroy event. This allows to reset
> >>>>     resources used by domain and so implement use-case like domain reboot.
> >>>>
> >>>> Dom0 Enable SCMI SMC:
> >>>>    - pass dom0_scmi_agent_id= in Xen command line. if not provided
> >>>>      SCMI will be disabled for Dom0 and all SCMI nodes removed from Dom0 DT.
> >>>>      The driver updates Dom0 DT SCMI node "arm,smc-id" value and fix up shmem
> >>>>      node according to assigned agent_id.
> >>>>
> >>>> Guest domains enable SCMI SMC:
> >>>>    - xl.cfg: add configuration option as below
> >>>>
> >>>>      arm_sci = "type=scmi_smc_multiagent,agent_id=2"
> >>>>
> >>>>    - xl.cfg: enable access to the "arm,scmi-shmem" which should correspond assigned agent_id for
> >>>>      the domain, for example:
> >>>>
> >>>> iomem = [
> >>>>       "47ff2,1@22001",
> >>>> ]
> >>> Looking at the code and the configuration options, it looks like it is
> >>> possible to map a scmi-shmem channel at a different address for the
> >>> guest. It seems like it would work. Is that correct?
> >>>
> >> Yes it will. in our case address 22001000 should be the save as
> >> sram@22001000 in the domain device-tree.
> >>>>    - DT: add SCMI nodes to the Driver domain partial device tree as in the
> >>>>    below example. The "arm,smc-id" should correspond assigned agent_id for the domain:
> >>>>
> >>>> passthrough {
> >>>>      scmi_shm_0: sram@22001000 {
> >>>>          compatible = "arm,scmi-shmem";
> >>>>          reg = <0x0 0x22001000 0x0 0x1000>;
> >>>>      };
> >>>>
> >>>>      firmware {
> >>>>           compatible = "simple-bus";
> >>>>               scmi: scmi {
> >>>>                   compatible = "arm,scmi-smc";
> >>>>                   arm,smc-id = <0x82000004>;
> >>>>                   shmem = <&scmi_shm_0>;
> >>>>                   ...
> >>>>               }
> >>>>       }
> >>>> }
> >>>>
> >>>> SCMI "4.2.1.1 Device specific access control"
> >>>>
> >>>> The XEN SCI SCMI SMC multi-agent driver performs "access-controller" provider function
> >>>> in case EL3 SCMI FW implements SCMI "4.2.1.1 Device specific access control" and provides the
> >>>> BASE_SET_DEVICE_PERMISSIONS command to configure the devices that an agents have access to.
> >>>> The DT SCMI node should "#access-controller-cells=<1>" property and DT devices should be bound
> >>>> to the Xen SCMI.
> >>>>
> >>>> &i2c1 {
> >>>>       access-controllers = <&scmi 0>;
> >>>> };
> >>>>
> >>>> The Dom0 and dom0less domains DT devices will be processed automatically through
> >>>> sci_assign_dt_device() call, but to assign SCMI devices from toolstack the xl.cfg:"dtdev" property
> >>>> shell be used:
> >>>>
> >>>> dtdev = [
> >>>>       "/soc/i2c@e6508000",
> >>>> ]
> >>>>
> >>>> xl.cfg:dtdev will contain all nodes which are under SCMI management (not only those which are behind IOMMU).
> >>>>
> >>>> [1]https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> >>>> [2]https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/access-controllers/access-controllers.yaml
> >>>> Signed-off-by: Oleksii Moisieiev
> >>>> Signed-off-by: Grygorii Strashko
> >>> Thanks for the long explanation, great work! I am really looking forward
> >>> to have this feature in the tree soon.
> >>>
> >>>
> >>>> ---
> >>>>
> >>>> Changes in v4:
> >>>> - toolstack comments from Anthony PERARD
> >>>> - added dom0less support
> >>>> - added doc for "xen,scmi-secondary-agents"
> >>>>
> >>>>    docs/man/xl.cfg.5.pod.in                    |  13 +
> >>>>    docs/misc/arm/device-tree/booting.txt       |  60 ++
> >>>>    docs/misc/xen-command-line.pandoc           |   9 +
> >>>>    tools/libs/light/libxl_arm.c                |   4 +
> >>>>    tools/libs/light/libxl_types.idl            |   4 +-
> >>>>    tools/xl/xl_parse.c                         |  12 +
> >>>>    xen/arch/arm/dom0less-build.c               |  11 +
> >>>>    xen/arch/arm/domain_build.c                 |   3 +-
> >>>>    xen/arch/arm/firmware/Kconfig               |  11 +
> >>>>    xen/arch/arm/firmware/Makefile              |   1 +
> >>>>    xen/arch/arm/firmware/scmi-proto.h          | 164 ++++
> >>>>    xen/arch/arm/firmware/scmi-shmem.c          | 173 ++++
> >>>>    xen/arch/arm/firmware/scmi-shmem.h          |  45 +
> >>>>    xen/arch/arm/firmware/scmi-smc-multiagent.c | 860 ++++++++++++++++++++
> >>>>    xen/include/public/arch-arm.h               |   3 +
> >>>>    15 files changed, 1371 insertions(+), 2 deletions(-)
> >>>>    create mode 100644 xen/arch/arm/firmware/scmi-proto.h
> >>>>    create mode 100644 xen/arch/arm/firmware/scmi-shmem.c
> >>>>    create mode 100644 xen/arch/arm/firmware/scmi-shmem.h
> >>>>    create mode 100644 xen/arch/arm/firmware/scmi-smc-multiagent.c
> >>>>
> >>>> diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> >>>> index 1ccf50b8ea..302c46d8bc 100644
> >>>> --- a/docs/man/xl.cfg.5.pod.in
> >>>> +++ b/docs/man/xl.cfg.5.pod.in
> >>>> @@ -3122,8 +3122,21 @@ single SCMI OSPM agent support.
> >>>>    Should be used together with B Xen command line
> >>>>    option.
> >>>>
> >>>> +=item B
> >>>> +
> >>>> +Enables ARM SCMI SMC multi-agent support for the guest by enabling SCMI over
> >>>> +SMC calls forwarding from domain to the EL3 firmware (like Trusted Firmware-A)
> >>>> +with a multi SCMI OSPM agent support. The SCMI B should be
> >>>> +specified for the guest.
> >>>> +
> >>>>    =back
> >>>>
> >>>> +=item B
> >>>> +
> >>>> +Specifies a non-zero ARM SCI agent id for the guest. This option is mandatory
> >>>> +if the SCMI SMC support is enabled for the guest. The agent ids of domains
> >>>> +existing on a single host must be unique and in the range [1..255].
> >>>> +
> >>>>    =back
> >>>>
> >>>>    =back
> >>>> diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
> >>>> index 8943c04173..c8923ab8b2 100644
> >>>> --- a/docs/misc/arm/device-tree/booting.txt
> >>>> +++ b/docs/misc/arm/device-tree/booting.txt
> >>>> @@ -296,6 +296,20 @@ with the following properties:
> >>>>        Should be used together with dom0_scmi_smc_passthrough Xen command line
> >>>>        option.
> >>>>
> >>>> +    - "scmi_smc_multiagent"
> >>>> +
> >>>> +    Enables ARM SCMI SMC multi-agent support for the guest by enabling SCMI over
> >>>> +    SMC calls forwarding from domain to the EL3 firmware (like ARM
> >>>> +    Trusted Firmware-A) with a multi SCMI OSPM agent support.
> >>>> +    The SCMI agent_id should be specified for the guest with "xen,sci_agent_id"
> >>>> +    property.
> >>>> +
> >>>> +- "xen,sci_agent_id"
> >>>> +
> >>>> +    Specifies a non-zero ARM SCI agent id for the guest. This option is
> >>>> +    mandatory if the SCMI SMC "scmi_smc_multiagent" support is enabled for
> >>>> +    the guest. The agent ids of guest must be unique and in the range [1..255].
> >>>> +
> >>>>    Under the "xen,domain" compatible node, one or more sub-nodes are present
> >>>>    for the DomU kernel and ramdisk.
> >>>>
> >>>> @@ -764,3 +778,49 @@ The automatically allocated static shared memory will get mapped at
> >>>>    0x80000000 in DomU1 guest physical address space, and at 0x90000000 in DomU2
> >>>>    guest physical address space. DomU1 is explicitly defined as the owner domain,
> >>>>    and DomU2 is the borrower domain.
> >>>> +
> >>>> +SCMI SMC multi-agent support
> >>>> +============================
> >>>> +
> >>>> +For enabling the ARM SCMI SMC multi-agent support (enabled by CONFIG_SCMI_SMC_MA)
> >>>> +the Xen specific SCMI Agent's configuration shell be provided in the Host DT
> >>>> +according to the SCMI compliant EL3 Firmware specification with
> >>>> +ARM SMC/HVC transport using property "xen,scmi-secondary-agents" under
> >>>> +the top-level "chosen" node:
> >>>> +
> >>>> +- xen,scmi-secondary-agents
> >>>> +
> >>>> +    Defines a set of SCMI agents configuration supported by SCMI EL3 FW and
> >>>> +    available for Xen. Each Agent defined as triple consisting of:
> >>>> +    SCMI agent_id,
> >>>> +    SMC/HVC function_id assigned for the agent transport ("arm,smc-id"),
> >>>> +    phandle to SCMI SHM assigned for the agent transport ("arm,scmi-shmem").
> >>>> +
> >>>> +As an example:
> >>>> +
> >>>> +chosen {
> >>>> +    xen,scmi-secondary-agents = <
> >>>> +        1 0x82000003 &scmi_shm_1
> >>>> +        2 0x82000004 &scmi_shm_2
> >>>> +        3 0x82000005 &scmi_shm_3
> >>>> +        4 0x82000006 &scmi_shm_4>;
> >>>> +}
> >>> NIT: it should be };
> >> +
> >>> Looking at scmi_probe, collect_agents, and the following SCMI
> >>> SCMI_BASE_DISCOVER_AGENT request, I wonder: do we actually need this
> >>> information?
> >>>
> >>> It looks like we can discover the agend_ids for every channel, I guess
> >>> what we need to know is the shmem location for every channel? But the
> >>> full list of shmem channel is available below thanks to the scmi-shmem
> >>> nodes.
> >>>
> >>> So, we have the list of scmi-shmem anyway, and we can probe the
> >>> agent_id. The only parameter left is the smc_id/func_id.
> >>>
> >>> Or maybe smc_id/func_id can be calculated from agent_id?
> >>>
> >>> I am asking mostly because if a user is supposed to add this
> >>> xen,scmi-secondary-agents property, where are they supposed to find the
> >>> smc_id/func_id information?
> >>>
> >>> It is important that we write down in this document how the user is
> >>> expected to find out what 1 is 0x82000003 which is scmi_shm_1.
> >> That's a very good question! The issue here is that there are no
> >>
> >> explicit requirements defining the relationship between agent_id and
> >> func_id.
> >>
> >>
> >> For example, in ARM-TF, different implementations can use different
> >> func_ids.
> >>
> >> To provide better flexibility, we decided to separate agent_id from func_id.
> >>
> >>
> >> Currently, the SCMI_BASE_DISCOVER_AGENT calls from the probe are intended to
> >>
> >> verify that all registered agents are present and that the configuration
> >> is correct.
> >>
> >> However, I understand that this additional validation could be optional
> >> to save traffic.
> >>
> >>
> >> To address this, I’m considering adding a configuration option, such as
> >>
> >> CONFIG_SCMI_AGENT_VALIDATION, which can be disabled to reduce boot time
> >> if this
> >>
> >> validation is not necessary for certain use cases.
> >>
> >>
> >> Lastly, I’ll be updating the document to include clearer information
> >> about the
> >>
> >> relationship between func_id and agent_id in the upcoming v5.
> >
> > The key point here is to make it easier for the user. If we can make
> > agent_id or func_id optional it would make users lives easier.
> >
> > Alternative, or in addition to this, we should make the docs as clear as
> > possible so that people can figure it out without having to ask
> > questions on xen-devel.
> >
> >
> 
> [OM ANSWER]
> 
> SCMI_BASE_DISCOVER_AGENT message requires agent_id. I think we can calculate
> 
> agent_id from func_id, the documentation will look like this:
> 
> ```
> 
> For enabling the ARM SCMI SMC multi-agent support (enabled by
> CONFIG_SCMI_SMC_MA)
> the Xen specific SCMI Agent's configuration shell be provided in the Host DT
> according to the SCMI compliant EL3 Firmware specification with
> ARM SMC/HVC transport using property "xen,scmi-secondary-agents" under
> the top-level "chosen" node:
> 
> - xen,scmi-secondary-agents
> 
>      Defines a set of SCMI agents configuration supported by SCMI EL3 FW and
>      available for Xen. Each Agent defined as triple consisting of:
>      SMC/HVC function_id assigned for the agent transport ("arm,smc-id"),
>      phandle to SCMI SHM assigned for the agent transport
> ("arm,scmi-shmem"),
> 
>      SCMI agent_id (optional)
> 
> As an example:
> 
> chosen {
>      xen,scmi-secondary-agents = <
>          0x82000003 &scmi_shm_1 1
>          0x82000004 &scmi_shm_2 2
>          0x82000005 &scmi_shm_3 3
>          0x82000006 &scmi_shm_4 4>;
> }
> 
> or
> 
> chosen {
>      xen,scmi-secondary-agents = <
>          0x82000003 &scmi_shm_1
>          0x82000004 &scmi_shm_2
>          0x82000005 &scmi_shm_3
>          0x82000006 &scmi_shm_4>;
> }
> 
> If the optional parameter agent_id is not provided, then Xen will
> request agent_id for each registered
> 
> channel from the firmware.
> 
> This procedure requires sending BASE_DISCOVER_AGENT using func_id and
> shmem region for each
> 
> registered agent and discover it's agent_id. This operation requires all
> memory reserved for the agents
> 
> to be mapped and then unmapped which can cause boot time increasing. So
> if boot time is important it is
> 
> preferable to provide agent_in in the device-tree.
> 
> There are some cases when Xen may not have an access to other agent
> memory, including scmi shmem due to
> 
> a very strict FFI configuration. In this case agent_id should be
> provided inside xem,scmi-secondary-agents parameter.
> 
> ```
> 
> What do you think about this approach?

This is better, thank you!


> I will add information about all point into the docs and will try to
> make it as clear as possible.

[...]


> >>> I don't understand why we need __memcpy_fromio and __memcpy_toio: can't
> >>> we use a simple memcpy?
> >> This approach was used because we're trying to access shared memory
> >> between two independent systems:
> >>
> >> Arm-TF and Xen in our case which places some chunks of data to the same
> >> memory. And, according to the [0]
> >>
> >> ```
> >>
> >> Some devices (such as framebuffers) would like to use larger transfers than
> >> 8 bytes at a time. For these devices, the memcpy_toio(),
> >> memcpy_fromio() and memset_io() functions are
> >> provided. Do not use memset or memcpy on IO addresses; they are not
> >> guaranteed to copy data in order.
> >>
> >> ```
> >>
> >> Also, the same approach was used by Arm team when introducing scmi
> >> driver to the Linux kernel [1]
> >>
> >>
> >> [0]:https://www.kernel.org/doc/Documentation/driver-api/device-io.rst
> >>
> >> [1]:https://git.iliana.fyi/linux/patch/?id=d5141f37c42e0b833863f157ac4cee203b2ba3d2
> > Keep in mind that [0] refers specifically to access to MMIO regions. I
> > assume that the SCMI shared buffers are on normal memory? Regarding [1],
> > it makes sense if Linux is trying to support shared memory over MMIO.
> >
> > Looking at one of your replies below, I am guessing the memory buffers
> > are actually in normal memory but the issue is that TF-A is mapping them
> > as uncacheable. Is that correct?
> >
> > In that case, I still don't understand why a simple memcpy would not be
> > sufficient. Can you check?
> >
> > If yes, then for now I would just simplify it down to memcpy. When
> > someone adds support for an SCMI server elsewhere we could look into
> > adding a more sophisticated memcpy and we can look at the details at
> > that point in time. Specifically, I am not convinced that memcpy_toio
> > and memcpy_fromio would work if the SCMI server is on a separate
> > non-coherent microcontroller.
> >
> According to the TF-A implementation  SCMI memory
> 
> is mapped with the  flags: MT_DEVICE (like for  stm32mp1) or
> MT_NON_CACHEABLE (for rpi3)
> 
> So probably you're right. I will check with simple memcpy.

There is a difference between MT_DEVICE and MT_NON_CACHEABLE: as far as
I know MT_DEVICE requires aligned accesses while MT_NON_CACHEABLE does
not.

However, as I wrote in the other email, if I am not mistaken the current
implementation of memcpy might work well for us anyway. (To be
confirmed.)

[...]


> >>> Are you sure it is worth to go through all this trouble to modify FDT in
> >>> place when we could simply generate the DT node from scratch like we do
> >>> for example for the GIC? This seems to be more error prone as well. Is
> >>> generating it from scratch is really difficult? If it is difficult then OK.
> >>>
> >> In the last patch [0] of the series, there is a proposal to separate
> >>
> >>    the Xen privileged agent from the Dom0 agent. This eliminates the
> >>
> >> need to modify the Xen Device Tree Blob (DTB), which is a positive
> >> improvement
> >>
> >> since the Dom0 agent node is already present in the device tree.
> >>
> >> However, the issue with SCMI node generation lies in the need to handle
> >>
> >> the list of protocols that are supported across the system.
> >>
> >> If we want to generate the SCMI node for Dom0, we need to:
> >>
> >> Copy these protocols from a centralized or predefined source.
> >> Set the correct phandle for each subnode within the SCMI node, ensuring
> >>
> >> accurate representation and functionality.
> >> This extra step of managing the protocols and phandles adds
> >>
> >> complexity but is necessary for ensuring proper support for Dom0.
> >>
> >> [0]
> >> https://lists.xenproject.org/archives/html/xen-devel/2025-05/msg01041.html
> > I was only commenting that rather than trying to modify the DT in place
> > we could create the node for Dom0 from scratch (artificially), based on
> > host DT information as required (fetching data from the host DT as
> > required and copying it to the Dom0 DT).
> >
> The problem is that scmi node, apart from the default parameters has a
> list of
> 
> supported protocols which may be different for Xen and Dom0 so to
> generate Dom0 node
> 
> from scratch we need to copy(or even generate) these nodes which will
> require complex implementation.
> 
> In contrary, if we go with implementation, proposed in the last patch -
> then we can have
> 
> more cleaner Xen device tree, which will look like this:
> 
> ```
> 
> chosen {
> 
>      scmi_xen: scmi {
> 
>            arm,smc-id = <0x82000002>;
> 
>            shmem= <$shm_0>;
> 
>           ... # no protocols description here
> 
> };
> 
> firmware {
> 
>     scmi {
> 
>            arm,smc-id = <0x82000003>;
> 
>            shmem= <$shm_1>;
> 
>            protocol@X{
> 
>            };
> 
>     }
> 
> };
> 
> ```
> 
> In this case, we don’t provide any protocol information for the Xen
> agent and instead set protocols for Dom0.
> 
> This ensures that each node has the information it requires.

Leaving aside how we generate the device tree nodes for Dom0, which is
of minor importance, we have two potentially conflicting goals:

1) no Xen-specific changes to Device Tree outside of /chosen
2) When Xen is present, Xen should be the one using the information in the Host Device Tree

With 1), I mean that the Host Device Tree, outside of the /chosen node,
should be the same for the BSP (no Xen) and for Xen. That is because it
should describe the platform, no matter the software running on it. Also
at the time the Device Tree is generated, often it is not known if Xen
will be running on the platform or not.

With 2) I meant that ideally when Xen is present, Xen should be the one
to use the information under /firmware/scmi, because Xen is the
principal SCMI client. Then Xen would generate somehow the SCMI device
tree nodes for Dom0 and the DomUs.

1) is more important than 2).

>From what you wrote, it looks like the SCMI device tree nodes are
different between Linux baremetal and Xen. If /firmware/scmi describes
what Linux baremetal should use, then it would work for Linux baremetal
but it would *not* work for Xen's own SCMI connection. Is that correct?

If that is the case, that is unfortunate. We need to compromise on 2).

I would keep /firmware/scmi as the one used by Linux baremetal because I
think we should uphold 1) above all else.

Then the Xen SCMI nodes could be placed under /chosen. This is less than
ideal because /chosen should contain Xen/Linux configurations, not
firmware interfaces. But it is the best we can do in a difficult
situation.

I think that whether the Dom0 device tree nodes are artificially
generated by Xen, or copied from the Host Device Tree somewhere, it
matters less.
--8323329-1278577597-1750628131=:8066--


From xen-devel-bounces@lists.xenproject.org Sun Jun 22 23:04:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Jun 2025 23:04:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021941.1397661 (Exim 4.92)
	(envelope-from )
	id 1uTTjo-0004ks-2V; Sun, 22 Jun 2025 23:04:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021941.1397661; Sun, 22 Jun 2025 23: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 1uTTjn-0004kl-Ve; Sun, 22 Jun 2025 23:04:35 +0000
Received: by outflank-mailman (input) for mailman id 1021941;
 Sun, 22 Jun 2025 23: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 1uTTjm-0004ic-92
 for xen-devel@lists.xenproject.org; Sun, 22 Jun 2025 23:04:34 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org
 [2600:3c04:e001:324:0:1991:8:25])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 41a39857-4fbd-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 01:04:32 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 1D02B60EDF;
 Sun, 22 Jun 2025 23:04:31 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id B9CCDC4CEE3;
 Sun, 22 Jun 2025 23:04:29 +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: 41a39857-4fbd-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750633470;
	bh=VxBS3YBVl2lQfbRgEpxjvNAy68EXRFshaJhYYyIECps=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=AqsutOrcSHtBql9ytOXT201lNtnvZnfmBJBzgHvbMI1SFe3JJFOWxPc7AI6wkB0/F
	 YomvYiamPGNLVGG1ajsdP6bFUMTgnamg7qCmxPr7Yvh675rZNgfDDJOiH4d1iSsjJX
	 989hGd9zEqPRhwDCm8bfM0Yd0+LZZ2Q7obRU/LBLBjK4e9X54MGgGxS/sA1TurdxIT
	 UA3taqp63i2eW4EldKC+GRadp3um7EIrb4JvioRvDb4Xby7sbxnikrWFseskptaXxn
	 Ug4tvhzJjkPdxwi9QX3Tvkig1lRozezI2jMj1ngG+/SBm692FgR2f6KA+rUZUEXujn
	 MVU+MHNKSgN5Q==
Date: Sun, 22 Jun 2025 16:04:28 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Andrew Cooper 
cc: Xen-devel , 
    Anthony PERARD , 
    Michal Orzel , Jan Beulich , 
    Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini 
Subject: Re: [PATCH] docs: Introduce a default .readthedocs.yaml
In-Reply-To: <20250620203418.42526-1-andrew.cooper3@citrix.com>
Message-ID: 
References: <20250620203418.42526-1-andrew.cooper3@citrix.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1543293752-1750633470=:8066"

  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-1543293752-1750633470=:8066
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Fri, 20 Jun 2025, Andrew Cooper wrote:
> Read The Docs now requires a configuration file, which is awkward when using
> RTD to render proposed changes on the list.
> 
> Provide the minimal configuration file possible, sacrificing all
> reproducibility in order to hopefully not need to touch it moving forwards.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Stefano Stabellini 


> ---
> CC: Anthony PERARD 
> CC: Michal Orzel 
> CC: Jan Beulich 
> CC: Julien Grall 
> CC: Roger Pau Monné 
> CC: Stefano Stabellini 
> 
> Notably, I've figured out how to get back to using rtd-theme:
> 
>   https://andrewcoop-xen.readthedocs.io/en/docs-secureboot/admin-guide/uefi-secure-boot.html
> 
> and without needing a separate docs/requirements.txt file in the tree too.
> ---
>  .readthedocs.yaml | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
>  create mode 100644 .readthedocs.yaml
> 
> diff --git a/.readthedocs.yaml b/.readthedocs.yaml
> new file mode 100644
> index 000000000000..d3aff7662ebf
> --- /dev/null
> +++ b/.readthedocs.yaml
> @@ -0,0 +1,18 @@
> +# Read the Docs configuration file for Sphinx projects
> +# See https://docs.readthedocs.io/en/stable/config-file/v2.html for details
> +
> +version: 2
> +
> +build:
> +  os: ubuntu-lts-latest
> +
> +  tools:
> +    python: "latest"
> +
> +  jobs:
> +    post_install:
> +      # Instead of needing a separate requirements.txt
> +      - python -m pip install --upgrade --no-cache-dir sphinx-rtd-theme
> +
> +sphinx:
> +  configuration: docs/conf.py
> -- 
> 2.39.5
> 
--8323329-1543293752-1750633470=:8066--


From xen-devel-bounces@lists.xenproject.org Sun Jun 22 23:12:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Jun 2025 23:12:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021952.1397671 (Exim 4.92)
	(envelope-from )
	id 1uTTrL-0006Q4-TJ; Sun, 22 Jun 2025 23:12:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021952.1397671; Sun, 22 Jun 2025 23:12: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 1uTTrL-0006Px-Pz; Sun, 22 Jun 2025 23:12:23 +0000
Received: by outflank-mailman (input) for mailman id 1021952;
 Sun, 22 Jun 2025 23:12: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 1uTTrK-0006Pr-Nx
 for xen-devel@lists.xenproject.org; Sun, 22 Jun 2025 23:12:22 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 587bec60-4fbe-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 01:12:20 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id D30D543F46;
 Sun, 22 Jun 2025 23:12:18 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2F620C4CEE3;
 Sun, 22 Jun 2025 23:12:17 +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: 587bec60-4fbe-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750633938;
	bh=ftw3Nnyp+J/D1Ry3KAIg1f+d2yn7R+AUvj3Rjiit4JE=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=hX2tWnHpfCqSzchZ/8exjgKntV02/xPrJLIvaJv1Y0sGM3ZBZZpuf/9ibcpYSmNo2
	 XxpQxgnznTIWkRHWKtDQsn30TCvv3H77kEL6Ovw6i8YUqcdFwA7fyff8NbVfztlh9H
	 IVpHJhHMLoKEXijc0BHsiX/gdvbu8ivtSiBN5nJLxa/d1mEvtz9X4X+/Dcvwzb2BYa
	 YepvfHzyk7I3TIT1u73rCFbJw/Vpp4QEWooqltGXC8Og9hVNSmZBpK1S8CbC8MYQox
	 PpdLC2GuL+LNGsau75uGTQbB2BAZROEg+33x6X0mXAD0XtpDr9tLshe+pRsOSu/kED
	 HaOP0yAb+58yg==
Date: Sun, 22 Jun 2025 16:12:15 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Koichiro Den 
cc: xen-devel@lists.xenproject.org, 
    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: [RFC PATCH 3/4] xen/arm: Move make_resv_memory_node()
In-Reply-To: <20250621151201.896719-4-den@valinux.co.jp>
Message-ID: 
References: <20250621151201.896719-1-den@valinux.co.jp> <20250621151201.896719-4-den@valinux.co.jp>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-513018135-1750633744=:8066"
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-513018135-1750633744=:8066
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: 8BIT
Content-ID: 

On Sun, 22 Jun 2025, Koichiro Den wrote:
> The /reserved-memory node is inherently not specific to static-shmem. In
> the next commit, child nodes will be added under /reserved-memory for
> the stolen time shared memory regions.
> 
> No functional changes intended.
> 
> Signed-off-by: Koichiro Den 

This causes a build failure when CONFIG_STATIC_SHM is missing.

arch/arm/domain_build.c: In function ‘make_resv_memory_node’:
arch/arm/domain_build.c:1567:34: error: implicit declaration of function ‘kernel_info_get_shm_mem_const’; did you mean ‘kernel_info_get_mem_const’? [-Werror=implicit-function-declaration]
 1567 |     const struct membanks *mem = kernel_info_get_shm_mem_const(kinfo);
      |                                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                  kernel_info_get_mem_const
arch/arm/domain_build.c:1567:34: error: nested extern declaration of ‘kernel_info_get_shm_mem_const’ [-Werror=nested-externs]
arch/arm/domain_build.c:1567:34: error: initialization of ‘const struct membanks *’ from ‘int’ makes pointer from integer without a cast [-Werror=int-conversion]



> ---
>  xen/arch/arm/domain_build.c           | 40 +++++++++++++++++++++++++++
>  xen/common/device-tree/static-shmem.c | 40 ---------------------------
>  xen/include/xen/fdt-domain-build.h    |  2 ++
>  xen/include/xen/static-shmem.h        |  9 ------
>  4 files changed, 42 insertions(+), 49 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 967ca6f375ca..85b6909e2b0e 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1561,6 +1561,46 @@ int __init make_chosen_node(const struct kernel_info *kinfo)
>      return res;
>  }
>  
> +int __init make_resv_memory_node(const struct kernel_info *kinfo, int addrcells,
> +                                 int sizecells)
> +{
> +    const struct membanks *mem = kernel_info_get_shm_mem_const(kinfo);
> +    void *fdt = kinfo->fdt;
> +    int res = 0;
> +    /* Placeholder for reserved-memory\0 */
> +    const char resvbuf[16] = "reserved-memory";
> +
> +    if ( mem->nr_banks == 0 )
> +        /* No shared memory provided. */
> +        return 0;
> +
> +    dt_dprintk("Create reserved-memory node\n");
> +
> +    res = fdt_begin_node(fdt, resvbuf);
> +    if ( res )
> +        return res;
> +
> +    res = fdt_property(fdt, "ranges", NULL, 0);
> +    if ( res )
> +        return res;
> +
> +    res = fdt_property_cell(fdt, "#address-cells", addrcells);
> +    if ( res )
> +        return res;
> +
> +    res = fdt_property_cell(fdt, "#size-cells", sizecells);
> +    if ( res )
> +        return res;
> +
> +    res = make_shm_resv_memory_node(kinfo, addrcells, sizecells);
> +    if ( res )
> +        return res;
> +
> +    res = fdt_end_node(fdt);
> +
> +    return res;
> +}
> +
>  static int __init handle_node(struct domain *d, struct kernel_info *kinfo,
>                                struct dt_device_node *node,
>                                p2m_type_t p2mt)
> diff --git a/xen/common/device-tree/static-shmem.c b/xen/common/device-tree/static-shmem.c
> index 8023c0a484c1..7eede97fa25d 100644
> --- a/xen/common/device-tree/static-shmem.c
> +++ b/xen/common/device-tree/static-shmem.c
> @@ -730,46 +730,6 @@ int __init process_shm_node(const void *fdt, int node, uint32_t address_cells,
>      return 0;
>  }
>  
> -int __init make_resv_memory_node(const struct kernel_info *kinfo, int addrcells,
> -                                 int sizecells)
> -{
> -    const struct membanks *mem = kernel_info_get_shm_mem_const(kinfo);
> -    void *fdt = kinfo->fdt;
> -    int res = 0;
> -    /* Placeholder for reserved-memory\0 */
> -    const char resvbuf[16] = "reserved-memory";
> -
> -    if ( mem->nr_banks == 0 )
> -        /* No shared memory provided. */
> -        return 0;
> -
> -    dt_dprintk("Create reserved-memory node\n");
> -
> -    res = fdt_begin_node(fdt, resvbuf);
> -    if ( res )
> -        return res;
> -
> -    res = fdt_property(fdt, "ranges", NULL, 0);
> -    if ( res )
> -        return res;
> -
> -    res = fdt_property_cell(fdt, "#address-cells", addrcells);
> -    if ( res )
> -        return res;
> -
> -    res = fdt_property_cell(fdt, "#size-cells", sizecells);
> -    if ( res )
> -        return res;
> -
> -    res = make_shm_resv_memory_node(kinfo, addrcells, sizecells);
> -    if ( res )
> -        return res;
> -
> -    res = fdt_end_node(fdt);
> -
> -    return res;
> -}
> -
>  void __init early_print_info_shmem(void)
>  {
>      const struct membanks *shmem = bootinfo_get_shmem();
> diff --git a/xen/include/xen/fdt-domain-build.h b/xen/include/xen/fdt-domain-build.h
> index 45981dbec0b8..e9418857e386 100644
> --- a/xen/include/xen/fdt-domain-build.h
> +++ b/xen/include/xen/fdt-domain-build.h
> @@ -25,6 +25,8 @@ int construct_domain(struct domain *d, struct kernel_info *kinfo);
>  int construct_hwdom(struct kernel_info *kinfo,
>                      const struct dt_device_node *node);
>  int make_chosen_node(const struct kernel_info *kinfo);
> +int make_resv_memory_node(const struct kernel_info *kinfo,
> +                          int addrcells, int sizecells);
>  int make_cpus_node(const struct domain *d, void *fdt);
>  int make_hypervisor_node(struct domain *d, const struct kernel_info *kinfo,
>                           int addrcells, int sizecells);
> diff --git a/xen/include/xen/static-shmem.h b/xen/include/xen/static-shmem.h
> index 76a49869126c..4afa9107de5d 100644
> --- a/xen/include/xen/static-shmem.h
> +++ b/xen/include/xen/static-shmem.h
> @@ -11,9 +11,6 @@
>  /* Worst case /memory node reg element: (addrcells + sizecells) */
>  #define DT_MEM_NODE_REG_RANGE_SIZE ((NR_MEM_BANKS + NR_SHMEM_BANKS) * 4)
>  
> -int make_resv_memory_node(const struct kernel_info *kinfo, int addrcells,
> -                          int sizecells);
> -
>  int process_shm(struct domain *d, struct kernel_info *kinfo,
>                  const struct dt_device_node *node);
>  
> @@ -50,12 +47,6 @@ kernel_info_get_shm_mem_const(const struct kernel_info *kinfo)
>  /* Worst case /memory node reg element: (addrcells + sizecells) */
>  #define DT_MEM_NODE_REG_RANGE_SIZE (NR_MEM_BANKS * 4)
>  
> -static inline int make_resv_memory_node(const struct kernel_info *kinfo,
> -                                        int addrcells, int sizecells)
> -{
> -    return 0;
> -}
> -
>  static inline int process_shm(struct domain *d, struct kernel_info *kinfo,
>                                const struct dt_device_node *node)
>  {
> -- 
> 2.48.1
> 
--8323329-513018135-1750633744=:8066--


From xen-devel-bounces@lists.xenproject.org Sun Jun 22 23:27:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Jun 2025 23:27:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021961.1397681 (Exim 4.92)
	(envelope-from )
	id 1uTU5P-00089E-1t; Sun, 22 Jun 2025 23:26:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021961.1397681; Sun, 22 Jun 2025 23:26: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 1uTU5O-000897-VO; Sun, 22 Jun 2025 23:26:54 +0000
Received: by outflank-mailman (input) for mailman id 1021961;
 Sun, 22 Jun 2025 23:26: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 1uTU5O-000891-7J
 for xen-devel@lists.xenproject.org; Sun, 22 Jun 2025 23:26: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 604f7e2f-4fc0-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 01:26:52 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id E7F6EA4051C;
 Sun, 22 Jun 2025 23:26:50 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2CBAAC4CEE3;
 Sun, 22 Jun 2025 23:26: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: 604f7e2f-4fc0-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750634810;
	bh=ILtXhClwxoT9nUN+jADhH2hlhodqWENmBlZlzZ0o/FI=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=W0o30gyd9kzvz1jCzU64nIzEMdsBhLa26syPChVmmE3xwFxfXnmyy4DKyYPXftKPx
	 pJl6rTL4PkwvqE86mg/8w/HV8p4YO8Fj+7auCLPPzLSNvDX9Np1lhiObraYsX3MfZ7
	 H9rrwEnEuoRtJ8jIcr8DEFiq8sIMGjGxor9JJ2frYOeriSWN3EWikotYa3pD0LwtdJ
	 pu1HkH2UZjtThV+WSP/o78m5q+g/fp79XupXa/01/oCsA53NDEwlnysduDdoggrSpW
	 F/Y6DOpMTgurBMOpT4Y75Ba3tKe6Xo610xeDanc+xvms0FMK4uU/tvSYoMEr+R8eeF
	 sYsDPGYlKFmBg==
Date: Sun, 22 Jun 2025 16:26:47 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Koichiro Den 
cc: xen-devel@lists.xenproject.org, 
    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: [RFC PATCH 4/4] xen/arm: Implement standard PV time interface
 as per ARM DEN 0057A
In-Reply-To: <20250621151201.896719-5-den@valinux.co.jp>
Message-ID: 
References: <20250621151201.896719-1-den@valinux.co.jp> <20250621151201.896719-5-den@valinux.co.jp>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Sun, 22 Jun 2025, Koichiro Den wrote:
> The VCPUOP_register_runstate_memory_area hypercall is still actively
> used, e.g., in the Linux arm64 codebase. When KPTI is enabled, the area
> was not registered from the beginning due to the VA not always being
> valid. In such cases, Linux falls back to using the standard PV time
> interface (ARM DEN 0057A), but this interface has not been implemented
> in Xen for ARM64 (until this commit).
> 
> The VCPUOP_register_runstate_phys_area was introduced, though it's
> unclear whether this would be used in Linux arm64 and when it will be
> prevalent amongst every possible downstream domain Linux variant. And of
> course Linux is not an only option for the Xen arm64 domains.
> 
> Therefore, implementing the standard way of sharing PV time is
> generically beneficial, avoiding reliance on specially crafted
> hypercalls, the usage of which by guest VMs is not always guaranteed.
> Note that the PV_TIME_ST interface communicates with IPA (GPA), not GVA.
> 
> Add the PV time interface according to ARM DEN 0057A.
> 
> Signed-off-by: Koichiro Den 
> ---
>  xen/arch/arm/domain.c                   | 30 +++++++++
>  xen/arch/arm/domain_build.c             | 87 ++++++++++++++++++++++++-
>  xen/arch/arm/include/asm/domain.h       | 17 +++++
>  xen/arch/arm/include/asm/smccc.h        | 12 ++++
>  xen/arch/arm/vsmc.c                     | 38 +++++++++++
>  xen/common/device-tree/dom0less-build.c |  2 +-
>  xen/include/xen/fdt-domain-build.h      |  2 +-
>  7 files changed, 183 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index be58a23dd725..e895e4111f1b 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -277,6 +277,18 @@ static void ctxt_switch_to(struct vcpu *n)
>      WRITE_SYSREG(n->arch.mdcr_el2, MDCR_EL2);
>  }
>  
> +static void update_stolen_time(struct vcpu *n)
> +{
> +    uint64_t tot_stolen;
> +
> +    if ( is_idle_vcpu(current) )
> +        return;
> +
> +    tot_stolen = n->runstate.time[RUNSTATE_runnable] +
> +                 n->runstate.time[RUNSTATE_offline];
> +    write_atomic(&n->arch.pv_time_region->stolen_time, tot_stolen);
> +}
> +
>  static void schedule_tail(struct vcpu *prev)
>  {
>      ASSERT(prev != current);
> @@ -291,6 +303,8 @@ static void schedule_tail(struct vcpu *prev)
>  
>      update_runstate_area(current);
>  
> +    update_stolen_time(current);
> +
>      /* Ensure that the vcpu has an up-to-date time base. */
>      update_vcpu_system_time(current);
>  }
> @@ -586,6 +600,8 @@ int arch_vcpu_create(struct vcpu *v)
>      if ( get_ssbd_state() == ARM_SSBD_RUNTIME )
>          v->arch.cpu_info->flags |= CPUINFO_WORKAROUND_2_FLAG;
>  
> +    v->arch.pv_time_region = &v->domain->arch.pv_time_regions[v->vcpu_id];
> +
>      return rc;
>  
>  fail:
> @@ -707,6 +723,7 @@ int arch_domain_create(struct domain *d,
>                         unsigned int flags)
>  {
>      unsigned int count = 0;
> +    int order;

unsigned int


>      int rc;
>  
>      BUILD_BUG_ON(GUEST_MAX_VCPUS < MAX_VIRT_CPUS);
> @@ -791,6 +808,19 @@ int arch_domain_create(struct domain *d,
>      d->arch.sve_vl = config->arch.sve_vl;
>  #endif
>  
> +    /*
> +     * Preallocate the stolen time shared memory regions for all the
> +     * possible vCPUs.
> +     */
> +    order = get_order_from_bytes(d->max_vcpus * sizeof(struct pv_time_region));
> +    d->arch.pv_time_regions_gfn = INVALID_GFN;
> +    d->arch.pv_time_regions = alloc_xenheap_pages(order, 0);
> +    if ( !d->arch.pv_time_regions ) {
> +        rc = -ENOMEM;
> +        goto fail;
> +    }
> +    memset(d->arch.pv_time_regions, 0, PAGE_SIZE << order);
> +
>      return 0;
>  
>  fail:
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 85b6909e2b0e..1c51b53d9c6b 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1561,8 +1561,80 @@ int __init make_chosen_node(const struct kernel_info *kinfo)
>      return res;
>  }
>  
> -int __init make_resv_memory_node(const struct kernel_info *kinfo, int addrcells,
> -                                 int sizecells)
> +int __init make_pv_time_resv_memory_node(struct domain *d,
> +                                         const struct kernel_info *kinfo,
> +                                         int addrcells, int sizecells)
> +{
> +    __be32 reg[GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS];
> +    unsigned int len = (addrcells + sizecells) * sizeof(__be32);
> +    struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +    struct membanks *unused_banks = NULL;
> +    void *fdt = kinfo->fdt;
> +    unsigned regions_len;
> +    gfn_t pv_time_gfn;
> +    mfn_t pv_time_mfn;
> +    paddr_t aligned;
> +    paddr_t avail;
> +    __be32 *cells;
> +    int res;
> +    int i;

unsigned int i


> +    /* Find unused regions */
> +    regions_len = PAGE_ALIGN(d->max_vcpus * 64);
> +    unused_banks = membanks_xzalloc(NR_MEM_BANKS, MEMORY);
> +    if ( !unused_banks )
> +        return -ENOMEM;
> +
> +    res = find_unused_regions(d, kinfo, unused_banks);
> +    if ( res ) {
> +        printk(XENLOG_WARNING "%pd: failed to find unused regions\n", d);
> +        goto fail;
> +    }
> +    for ( i = 0; i < unused_banks->nr_banks; i++ ) {
> +        const struct membank *bank = &unused_banks->bank[i];
> +        aligned = PAGE_ALIGN(bank->start);
> +        avail = bank->size - (aligned - bank->start);
> +        if ( avail >= regions_len )
> +            break;
> +    }
> +    if ( i == unused_banks->nr_banks ) {
> +        res = -ENOSPC;
> +        goto fail;
> +    }
> +
> +    /* Insert P2M entry */
> +    pv_time_mfn = virt_to_mfn(d->arch.pv_time_regions);
> +    pv_time_gfn = gaddr_to_gfn(aligned);
> +    p2m_write_lock(p2m);
> +    res = p2m_set_entry(p2m, pv_time_gfn, regions_len / PAGE_SIZE,

PFN_DOW


> +                        pv_time_mfn, p2m_ram_rw, p2m_access_r);
> +    p2m_write_unlock(p2m);
> +    if ( res ) {
> +        printk(XENLOG_WARNING "%pd: failed to set P2M entry for PV_TIME\n", d);
> +        goto fail;
> +    }
> +    d->arch.pv_time_regions_gfn = pv_time_gfn;
> +
> +    /* Reserve the selected GFN */
> +    res = domain_fdt_begin_node(fdt, "pv-time", gfn_x(pv_time_gfn));
> +    if ( res )
> +        goto fail;
> +
> +    cells = reg;
> +    dt_child_set_range(&cells, addrcells, sizecells, gfn_x(pv_time_gfn), regions_len);
> +    res = fdt_property(fdt, "reg", reg, len);
> +    if ( res )
> +        goto fail;
> +
> +    res = fdt_end_node(fdt);
> +
> +  fail:
> +    xfree(unused_banks);
> +    return res;
> +}
> +
> +int __init make_resv_memory_node(struct domain *d, const struct kernel_info *kinfo,
> +                                 int addrcells, int sizecells)
>  {
>      const struct membanks *mem = kernel_info_get_shm_mem_const(kinfo);
>      void *fdt = kinfo->fdt;
> @@ -1596,6 +1668,10 @@ int __init make_resv_memory_node(const struct kernel_info *kinfo, int addrcells,
>      if ( res )
>          return res;
>  
> +    res = make_pv_time_resv_memory_node(d, kinfo, addrcells, sizecells);
> +    if ( res )
> +        return res;
> +
>      res = fdt_end_node(fdt);
>  
>      return res;
> @@ -1744,6 +1820,11 @@ static int __init handle_node(struct domain *d, struct kernel_info *kinfo,
>                                          dt_n_size_cells(node));
>          if ( res )
>              return res;
> +
> +        res = make_pv_time_resv_memory_node(d, kinfo, dt_n_addr_cells(node),
> +                                            dt_n_size_cells(node));
> +        if ( res )
> +            return res;
>      }
>  
>      for ( child = node->child; child != NULL; child = child->sibling )
> @@ -1791,7 +1872,7 @@ static int __init handle_node(struct domain *d, struct kernel_info *kinfo,
>  
>          if ( !res_mem_node_found )
>          {
> -            res = make_resv_memory_node(kinfo, addrcells, sizecells);
> +            res = make_resv_memory_node(d, kinfo, addrcells, sizecells);
>              if ( res )
>                  return res;
>          }
> diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/domain.h
> index a3487ca71303..c231c45fe40f 100644
> --- a/xen/arch/arm/include/asm/domain.h
> +++ b/xen/arch/arm/include/asm/domain.h
> @@ -59,6 +59,18 @@ struct paging_domain {
>      unsigned long p2m_total_pages;
>  };
>  
> +/* Stolen time shared memory region (ARM DEN 0057A.b) */
> +struct pv_time_region {
> +    /* This field must be 0 as per ARM DEN 0057A.b */
> +    uint32_t revision;
> +
> +    /* This field must be 0 as per ARM DEN 0057A.b */
> +    uint32_t attribute;
> +
> +    /* Total stolen time in nanoseconds */
> +    uint64_t stolen_time;
> +} __aligned(64);
> +
>  struct arch_domain
>  {
>  #ifdef CONFIG_ARM_64
> @@ -121,6 +133,9 @@ struct arch_domain
>      void *tee;
>  #endif
>  
> +    struct pv_time_region *pv_time_regions;
> +    gfn_t pv_time_regions_gfn;
> +
>  }  __cacheline_aligned;
>  
>  struct arch_vcpu
> @@ -243,6 +258,8 @@ struct arch_vcpu
>       */
>      bool need_flush_to_ram;
>  
> +    struct pv_time_region *pv_time_region;
> +
>  }  __cacheline_aligned;
>  
>  void vcpu_show_registers(struct vcpu *v);
> diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/asm/smccc.h
> index a289c48b7ffd..6207ac74b715 100644
> --- a/xen/arch/arm/include/asm/smccc.h
> +++ b/xen/arch/arm/include/asm/smccc.h
> @@ -380,6 +380,18 @@ void arm_smccc_1_2_smc(const struct arm_smccc_1_2_regs *args,
>                         ARM_SMCCC_OWNER_ARCH,        \
>                         0x3FFF)
>  
> +#define ARM_SMCCC_HYP_PV_TIME_FEATURES              \
> +    ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL,         \
> +                       ARM_SMCCC_CONV_64,           \
> +                       ARM_SMCCC_OWNER_HYPERVISOR,  \
> +                       0x20)
> +
> +#define ARM_SMCCC_HYP_PV_TIME_ST                    \
> +    ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL,         \
> +                       ARM_SMCCC_CONV_64,           \
> +                       ARM_SMCCC_OWNER_HYPERVISOR,  \
> +                       0x21)
> +
>  /* SMCCC error codes */
>  #define ARM_SMCCC_NOT_REQUIRED          (-2)
>  #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION  (-1)
> diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
> index 6081f14ed0c1..1e2fbc1a62b4 100644
> --- a/xen/arch/arm/vsmc.c
> +++ b/xen/arch/arm/vsmc.c
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -127,6 +128,10 @@ static bool handle_arch(struct cpu_user_regs *regs)
>              if ( cpus_have_cap(ARM_WORKAROUND_BHB_SMCC_3) )
>                  ret = ARM_SMCCC_SUCCESS;
>              break;
> +        case ARM_SMCCC_HYP_PV_TIME_FEATURES:
> +            if ( !gfn_eq(current->domain->arch.pv_time_regions_gfn, INVALID_GFN) )
> +                ret = ARM_SMCCC_SUCCESS;
> +            break;
>          }
>  
>          set_user_reg(regs, 0, ret);
> @@ -162,6 +167,35 @@ static bool handle_arch(struct cpu_user_regs *regs)
>      return false;
>  }
>  
> +static bool fill_pv_time_features(struct cpu_user_regs *regs)
> +{
> +    uint32_t arch_func_id = get_user_reg(regs, 1);
> +    int ret = ARM_SMCCC_NOT_SUPPORTED;
> +
> +    if ( arch_func_id == ARM_SMCCC_HYP_PV_TIME_ST &&
> +         !gfn_eq(current->domain->arch.pv_time_regions_gfn, INVALID_GFN) )
> +        ret = ARM_SMCCC_SUCCESS;
> +
> +    set_user_reg(regs, 0, ret);
> +
> +    return true;
> +}
> +
> +static bool fill_pv_time_st(struct cpu_user_regs *regs)
> +{
> +    register_t ret = ARM_SMCCC_NOT_SUPPORTED;
> +    paddr_t gaddr;
> +
> +    if ( !gfn_eq(current->domain->arch.pv_time_regions_gfn, INVALID_GFN) )
> +    {
> +        gaddr = gfn_to_gaddr(current->domain->arch.pv_time_regions_gfn);
> +        ret = gaddr + current->vcpu_id * sizeof(struct pv_time_region);
> +    }
> +
> +    set_user_reg(regs, 0, ret);
> +    return true;
> +}
> +
>  /* SMCCC interface for hypervisor. Tell about itself. */
>  static bool handle_hypervisor(struct cpu_user_regs *regs)
>  {
> @@ -176,6 +210,10 @@ static bool handle_hypervisor(struct cpu_user_regs *regs)
>      case ARM_SMCCC_REVISION_FID(HYPERVISOR):
>          return fill_revision(regs, XEN_SMCCC_MAJOR_REVISION,
>                               XEN_SMCCC_MINOR_REVISION);
> +    case ARM_SMCCC_HYP_PV_TIME_FEATURES:
> +        return fill_pv_time_features(regs);
> +    case ARM_SMCCC_HYP_PV_TIME_ST:
> +        return fill_pv_time_st(regs);

This file is common across 32-bit and 64-bit guests. Looking at the
implementation of fill_pv_time_st, which returns a 64-bit address on a
potentially 32-bit register, it looks like this interface is only meant
for 64-bit guests?

If so, then we should have a check here and return "not supported" for
32-bit callers.


>      default:
>          return false;
>      }
> diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
> index 3d503c697337..fa31b1733388 100644
> --- a/xen/common/device-tree/dom0less-build.c
> +++ b/xen/common/device-tree/dom0less-build.c
> @@ -502,7 +502,7 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
>      if ( ret )
>          goto err;
>  
> -    ret = make_resv_memory_node(kinfo, addrcells, sizecells);
> +    ret = make_resv_memory_node(d, kinfo, addrcells, sizecells);
>      if ( ret )
>          goto err;
>  
> diff --git a/xen/include/xen/fdt-domain-build.h b/xen/include/xen/fdt-domain-build.h
> index e9418857e386..645e7d0a54aa 100644
> --- a/xen/include/xen/fdt-domain-build.h
> +++ b/xen/include/xen/fdt-domain-build.h
> @@ -25,7 +25,7 @@ int construct_domain(struct domain *d, struct kernel_info *kinfo);
>  int construct_hwdom(struct kernel_info *kinfo,
>                      const struct dt_device_node *node);
>  int make_chosen_node(const struct kernel_info *kinfo);
> -int make_resv_memory_node(const struct kernel_info *kinfo,
> +int make_resv_memory_node(struct domain *d, const struct kernel_info *kinfo,
>                            int addrcells, int sizecells);
>  int make_cpus_node(const struct domain *d, void *fdt);
>  int make_hypervisor_node(struct domain *d, const struct kernel_info *kinfo,
> -- 
> 2.48.1
> 


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 01:16:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 01:16:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021977.1397691 (Exim 4.92)
	(envelope-from )
	id 1uTVnd-00041k-1N; Mon, 23 Jun 2025 01:16:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021977.1397691; Mon, 23 Jun 2025 01:16: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 1uTVnc-00041d-To; Mon, 23 Jun 2025 01:16:40 +0000
Received: by outflank-mailman (input) for mailman id 1021977;
 Mon, 23 Jun 2025 01:16: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 1uTVna-00041X-Gt
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 01:16:39 +0000
Received: from mail-10628.protonmail.ch (mail-10628.protonmail.ch
 [79.135.106.28]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b4a98339-4fcf-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 03:16:35 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b4a98339-4fcf-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1750641394; x=1750900594;
	bh=PMAd4zFxcXv5vGZUSDMj0BvN3PyFw2OdCgQnVuQcNh0=;
	h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
	 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector;
	b=mhtiPvKs4CuQXBO9Ueh+xug38LpA8Me19CNUKoB8nOHtLSHwJVlkeVCpKBsU3EtUX
	 jXwVfKL1hQjnKaBkc8yjjEvQmrIfLtKh7zgUsrgbYsqUF25wdDOj2OT8p5p49PesWC
	 1A14oq42f1Egab+4G3qpM3taOzvY69/FLDWD2cP2rl4MG0lw2jm64PBgHEaK2fjBFM
	 Bdc7SNaddOBEw0rf9oJgQCt178F7fYSvQX1uEeUU//s/YuGOi58JUhxuh+2sZKo13h
	 946SoGElXoIcfqWxPrLp+zAUeL1PGVlOAJZn4O/qk5YemJu4dcu7zi66wpDwmre96k
	 opcbEM5aK1NYA==
Date: Mon, 23 Jun 2025 01:16:28 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v1] xen/domain: fix memory leak in domain_create()
Message-ID: <20250623011514.173367-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: afa7b6199ee8a1cf08082bdff2dc07f5930bfacf
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Fix potential memory leak in domain_create() in late hardware domain case.

Fixes: b959f3b820f5 ("xen: introduce hardware domain create flag")
Signed-off-by: Denis Mukhin 
---
I think that no memory allocation is required before performing late hwdom
checks (ID range and hwdom existance).

Looks like sanitise_domain_config() could better fit for performing such
configuration checks.

Alternatively, hardware_domid range could be checked via custom parser
instead of code in domain_create() and then hwdom existance can be moved
before alloc_domain_struct().

Thoughts?
---
 xen/common/domain.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 2f6b0af50dd3..5ad1ac872798 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -825,7 +825,10 @@ struct domain *domain_create(domid_t domid,
=20
         /* late_hwdom is only allowed for dom0. */
         if ( hardware_domain && hardware_domain->domain_id )
+        {
+            free_domain_struct(d);
             return ERR_PTR(-EINVAL);
+        }
=20
         old_hwdom =3D hardware_domain;
         hardware_domain =3D d;
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Mon Jun 23 01:34:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 01:34:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1021989.1397701 (Exim 4.92)
	(envelope-from )
	id 1uTW50-0006xS-Gg; Mon, 23 Jun 2025 01:34:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1021989.1397701; Mon, 23 Jun 2025 01:34:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTW50-0006xL-Dw; Mon, 23 Jun 2025 01:34:38 +0000
Received: by outflank-mailman (input) for mailman id 1021989;
 Mon, 23 Jun 2025 01:34: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 1uTW4z-0006xF-EU
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 01:34:37 +0000
Received: from mail-10628.protonmail.ch (mail-10628.protonmail.ch
 [79.135.106.28]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 37eda73a-4fd2-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 03:34:35 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 37eda73a-4fd2-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1750642473; x=1750901673;
	bh=McCYuwAalEKxynNEPuCPOFPsq1xeYHW/pDy3ENrirhQ=;
	h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
	 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector;
	b=gLVoOxJ3grPfNs5qER7YhPYCH6p9SWRTaQ+h3xBHsRxjBm8HR0x8wuFP8N258O/yi
	 iqJzRGx1e+94mjFO2poV5Pyfsr4TxjrM/EGlz8IpKapmxYHp/o2gSHnu0uZU4xB2KY
	 6ugNCXHSZ2tJBEygivyrajds/pWXVZ/JDdqv4Itu0bgjCUg2wnJ8/SFzefzzC3Km/E
	 ylNOFGorBOhkF/cOb/BhthGI5kFDF8bKUpJiFWNmnGH9oGD7PtdEp32WP7zNhAcnHb
	 WzZ5ds4DgYMNJky5MIhD2Jpo+KF78bm+VTEgCkLuxPJwkpu58igIQxrxJENyLKs2+K
	 Ta6Ayl6bpT2qg==
Date: Mon, 23 Jun 2025 01:34:26 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v3] xen/console: introduce domain_console struct
Message-ID: <20250623013406.174027-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 0c34475fa538f8363cb3a6bdb6e3bf01df10b076
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Introduce domain_console for grouping data structures used for integrating
domain's diagnostic console with Xen's console driver.

Group all pbuf-related data structures under domain_console. Rename the mov=
ed
fields to plain .buf, .idx and .lock names, since all uses of the fields ar=
e
touched.

Bump the domain console buffer size to the closest power of 2 (256) and
rename the symbol to DOMAIN_CONSOLE_BUF_SIZE.

Finally, update the domain_console allocation and initialization code.

No functional change.

Signed-off-by: Denis Mukhin 
---
Changes since v2:
- fixed domain_console definition
- dropped changes under CONFIG_VERBOSE_DEBUG
- fixed domain_console allocation/initilization in domain_create()
- switched hvm_print_line() to use `d` for domain pointer

Link to v2: https://lore.kernel.org/r/20250617012713.57074-1-dmukhin@ford.c=
om
---
 xen/arch/arm/vpl011.c      |  2 +-
 xen/arch/x86/hvm/hvm.c     | 17 +++++++++--------
 xen/arch/x86/pv/shim.c     |  2 +-
 xen/common/domain.c        | 19 +++++++++----------
 xen/drivers/char/console.c | 22 ++++++++++++----------
 xen/include/xen/sched.h    | 25 +++++++++++++++----------
 6 files changed, 47 insertions(+), 40 deletions(-)

diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 2b6f2a09bca6..f4a840da10c5 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -713,7 +713,7 @@ int domain_vpl011_init(struct domain *d, struct vpl011_=
init_info *info)
     }
     else
     {
-        d->console.input_allowed =3D true;
+        d->console->input_allowed =3D true;
         vpl011->backend_in_domain =3D false;
=20
         vpl011->backend.xen =3D xzalloc(struct vpl011_xen_backend);
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 056360d5fe50..7d599eab73f2 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -559,7 +559,8 @@ void hvm_do_resume(struct vcpu *v)
 static int cf_check hvm_print_line(
     int dir, unsigned int port, unsigned int bytes, uint32_t *val)
 {
-    struct domain *cd =3D current->domain;
+    const struct domain *d =3D current->domain;
+    struct domain_console *cons =3D d->console;
     char c =3D *val;
=20
     ASSERT(bytes =3D=3D 1 && port =3D=3D XEN_HVM_DEBUGCONS_IOPORT);
@@ -571,16 +572,16 @@ static int cf_check hvm_print_line(
     if ( !is_console_printable(c) )
         return X86EMUL_OKAY;
=20
-    spin_lock(&cd->pbuf_lock);
+    spin_lock(&cons->lock);
     if ( c !=3D '\n' )
-        cd->pbuf[cd->pbuf_idx++] =3D c;
-    if ( (cd->pbuf_idx =3D=3D (DOMAIN_PBUF_SIZE - 1)) || (c =3D=3D '\n') )
+        cons->buf[cons->idx++] =3D c;
+    if ( (cons->idx =3D=3D (DOMAIN_CONSOLE_BUF_SIZE - 1)) || (c =3D=3D '\n=
') )
     {
-        cd->pbuf[cd->pbuf_idx] =3D '\0';
-        guest_printk(cd, XENLOG_G_DEBUG "%s\n", cd->pbuf);
-        cd->pbuf_idx =3D 0;
+        cons->buf[cons->idx] =3D '\0';
+        guest_printk(d, XENLOG_G_DEBUG "%s\n", cons->buf);
+        cons->idx =3D 0;
     }
-    spin_unlock(&cd->pbuf_lock);
+    spin_unlock(&cons->lock);
=20
     return X86EMUL_OKAY;
 }
diff --git a/xen/arch/x86/pv/shim.c b/xen/arch/x86/pv/shim.c
index bc2a7dd5fae5..bd29c53a2d34 100644
--- a/xen/arch/x86/pv/shim.c
+++ b/xen/arch/x86/pv/shim.c
@@ -239,7 +239,7 @@ void __init pv_shim_setup_dom(struct domain *d, l4_pgen=
try_t *l4start,
      */
     d->max_pages =3D domain_tot_pages(d);
=20
-    d->console.input_allowed =3D true;
+    d->console->input_allowed =3D true;
 }
=20
 static void write_start_info(struct domain *d)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 434d32901b1b..2f6b0af50dd3 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -669,7 +669,7 @@ static void _domain_destroy(struct domain *d)
     BUG_ON(!d->is_dying);
     BUG_ON(atomic_read(&d->refcnt) !=3D DOMAIN_DESTROYED);
=20
-    xfree(d->pbuf);
+    xfree(d->console);
=20
     argo_destroy(d);
=20
@@ -832,8 +832,6 @@ struct domain *domain_create(domid_t domid,
         flags |=3D CDF_hardware;
         if ( old_hwdom )
             old_hwdom->cdf &=3D ~CDF_hardware;
-
-        d->console.input_allowed =3D true;
     }
=20
     /* Holding CDF_* internal flags. */
@@ -863,8 +861,6 @@ struct domain *domain_create(domid_t domid,
     spin_lock_init(&d->shutdown_lock);
     d->shutdown_code =3D SHUTDOWN_CODE_INVALID;
=20
-    spin_lock_init(&d->pbuf_lock);
-
     rwlock_init(&d->vnuma_rwlock);
=20
 #ifdef CONFIG_HAS_PCI
@@ -874,6 +870,14 @@ struct domain *domain_create(domid_t domid,
=20
     /* All error paths can depend on the above setup. */
=20
+    err =3D -ENOMEM;
+    d->console =3D xvzalloc(typeof(*d->console));
+    if ( !d->console )
+        goto fail;
+
+    spin_lock_init(&d->console->lock);
+    d->console->input_allowed =3D is_hardware_domain(d);
+
     /*
      * Allocate d->vcpu[] and set ->max_vcpus up early.  Various per-domai=
n
      * resources want to be sized based on max_vcpus.
@@ -956,11 +960,6 @@ struct domain *domain_create(domid_t domid,
     if ( (err =3D argo_init(d)) !=3D 0 )
         goto fail;
=20
-    err =3D -ENOMEM;
-    d->pbuf =3D xzalloc_array(char, DOMAIN_PBUF_SIZE);
-    if ( !d->pbuf )
-        goto fail;
-
     if ( (err =3D sched_init_domain(d, config->cpupool_id)) !=3D 0 )
         goto fail;
=20
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 5d3681b16aee..5188ee761dd2 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -524,7 +524,7 @@ struct domain *console_get_domain(void)
     if ( !d )
         return NULL;
=20
-    if ( d->console.input_allowed )
+    if ( d->console->input_allowed )
         return d;
=20
     rcu_unlock_domain(d);
@@ -567,7 +567,7 @@ static void console_switch_input(void)
         {
             rcu_unlock_domain(d);
=20
-            if ( !d->console.input_allowed )
+            if ( !d->console->input_allowed )
                 continue;
=20
             console_rx =3D next_rx;
@@ -757,6 +757,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(=
char) buffer,
         else
         {
             char *kin =3D kbuf, *kout =3D kbuf, c;
+            struct domain_console *cons =3D cd->console;
=20
             /* Strip non-printable characters */
             do
@@ -769,22 +770,23 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARA=
M(char) buffer,
             } while ( --kcount > 0 );
=20
             *kout =3D '\0';
-            spin_lock(&cd->pbuf_lock);
+            spin_lock(&cons->lock);
             kcount =3D kin - kbuf;
             if ( c !=3D '\n' &&
-                 (cd->pbuf_idx + (kout - kbuf) < (DOMAIN_PBUF_SIZE - 1)) )
+                 cons->idx + kout - kbuf < DOMAIN_CONSOLE_BUF_SIZE - 1 )
             {
                 /* buffer the output until a newline */
-                memcpy(cd->pbuf + cd->pbuf_idx, kbuf, kout - kbuf);
-                cd->pbuf_idx +=3D (kout - kbuf);
+                memcpy(cons->buf + cons->idx, kbuf, kout - kbuf);
+                cons->idx +=3D (kout - kbuf);
             }
             else
             {
-                cd->pbuf[cd->pbuf_idx] =3D '\0';
-                guest_printk(cd, XENLOG_G_DEBUG "%s%s\n", cd->pbuf, kbuf);
-                cd->pbuf_idx =3D 0;
+                cons->buf[cons->idx] =3D '\0';
+                guest_printk(cd,
+                             XENLOG_G_DEBUG "%s%s\n", cons->buf, kbuf);
+                cons->idx =3D 0;
             }
-            spin_unlock(&cd->pbuf_lock);
+            spin_unlock(&cons->lock);
         }
=20
         guest_handle_add_offset(buffer, kcount);
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index fe53d4fab7ba..252f0e8c4aa8 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -371,6 +371,20 @@ struct evtchn_port_ops;
=20
 #define MAX_NR_IOREQ_SERVERS 8
=20
+/* Arbitrary value. */
+#define DOMAIN_CONSOLE_BUF_SIZE 256
+
+/* Domain console settings. */
+struct domain_console {
+    /* hvm_print_line() and guest_console_write() logging. */
+    char buf[DOMAIN_CONSOLE_BUF_SIZE];
+    unsigned int idx;
+    spinlock_t lock;
+
+    /* Permission to take ownership of the physical console input. */
+    bool input_allowed;
+};
+
 struct domain
 {
     domid_t          domain_id;
@@ -562,12 +576,6 @@ struct domain
     /* Control-plane tools handle for this domain. */
     xen_domain_handle_t handle;
=20
-    /* hvm_print_line() and guest_console_write() logging. */
-#define DOMAIN_PBUF_SIZE 200
-    char       *pbuf;
-    unsigned int pbuf_idx;
-    spinlock_t  pbuf_lock;
-
     /* OProfile support. */
     struct xenoprof *xenoprof;
=20
@@ -653,10 +661,7 @@ struct domain
 #endif
=20
     /* Console settings. */
-    struct {
-        /* Permission to take ownership of the physical console input. */
-        bool input_allowed;
-    } console;
+    struct domain_console *console;
 } __aligned(PAGE_SIZE);
=20
 static inline struct page_list_head *page_to_list(
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Mon Jun 23 06:13:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 06:13:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022018.1397711 (Exim 4.92)
	(envelope-from )
	id 1uTaQG-0006AW-6l; Mon, 23 Jun 2025 06:12:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022018.1397711; Mon, 23 Jun 2025 06:12: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 1uTaQG-0006AO-38; Mon, 23 Jun 2025 06:12:52 +0000
Received: by outflank-mailman (input) for mailman id 1022018;
 Mon, 23 Jun 2025 06:12: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 1uTaQF-0006AI-4D
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 06:12:51 +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 16ea9c2e-4ff9-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 08:12:50 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3a6e2d85705so168677f8f.0
 for ; Sun, 22 Jun 2025 23:12:50 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-7490a46b4b8sm7439971b3a.35.2025.06.22.23.12.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 22 Jun 2025 23:12:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 16ea9c2e-4ff9-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750659169; x=1751263969; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=W+e7PbS0xL0ZkoMd+hTJob2mF7PjjnL2U3ZAld/qhOk=;
        b=YJza+IipvuA8CLvc9A50m9PhjjHn35BY5ckwjRnqz0ZB3VqNEtNIkInCwFu9HDovtB
         oiFTwjI984l+9cstBLAnrYoNIiT7OWpJ8WaOfSdbp3PyfEaIszdNTnnT5Aog7z55zoo4
         zFkcj5BSdIRI+B56J/3ewYWI+UJzDl6mY6fG9EPy0wcP0RYZYoB+Z7ouklCG5ISY0Xbh
         AVk+qnQMSfhG5wNHSwWCvXfb45mf2hzViXDo8XN9frKumTIdhqKpqjiLW0ym5130wBUv
         ezId3r2p5D9jv1X3dbY5eD0ipXgC22qsldHgqzg230RSYBWxMhMykC0+mmQQUk+D4rVq
         aVGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750659169; x=1751263969;
        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=W+e7PbS0xL0ZkoMd+hTJob2mF7PjjnL2U3ZAld/qhOk=;
        b=OKje670ssBhtRPS1FTlD6oj6MI5y2uaxKJ21ZRKOMXnfJqkbfSMoCDpz+Pa6+M1X0u
         HkyJaDF97ilsBc5gmVs6LcEXbxoJFsZe/GtX/NUDnHPPWZuZ2TmlhFbTrv5a82jmjwFa
         Sw4KkO+gWxLl6Y4/BXHUMmRqCyfrMxDYU3vIhMjAMtBnOCdAkqHenz+U+kLLITo1Eepb
         AeBIbWr8oH+d+J7YsnI5MkQJM1Hb9EvA3OFZ3V1JHU3zhCA7Sv2Ct+jNbUwqZvAzzqA+
         0Se6oksnBa3Lr0MI/87FIJzKW54uHuWNdDMiGEXq1nrx6zn8FW5D9n3Hb6rY5mR6bzRK
         NPTg==
X-Forwarded-Encrypted: i=1; AJvYcCUblxTBcRRMguSz7/F2zAe8l0GWuGJVILP+UlTlBghJ/EyHhIqEr43b2nKRaULlaif3JsGU2uzMC6I=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxyWDvWBZugv91VFY9m2qvP/tEpexFP15wbCLFiQHrbGq6Ry285
	SY6WxYYX4oY7kI2/gDc2gyODwDR5sajzO1Sf6ByGfiw7/IwaNlutYXMrnrg/d5TSDw==
X-Gm-Gg: ASbGnctcQyI5MUclh67U9gWy61JI6JYR2N8UWpbY4I4IXvuuKMeeGIdIALELBVJX+k1
	qq7gfZcHTmSwwegadZIyhgZKA77mdplrDj9RNNxzy44IapNiiEDG5ZpgEWbCMN3wpCpG0fWpjG5
	yGICdCOXn45I6ZcdPJy/1AAMKpJP3bOI3iYh2ODTVirkGQoIsxJxtzVFlCaevLAjKAxL0SJU/BH
	5s2anAacOHvUm2XAS05oq0p9hrfAWEkbGBBoSI7QgfMy5NBHaHo11PDd1gsXxztzRO9qm4pZW+Y
	6GMRHRldOunappR2SxbHwIKhL8XIh0UamKq9sOEbmmwRjrqxo88sImTYwGnIB8K+IHOJ75gqapC
	Vh0xC+z38v4Lu5rVzeggmLw/D7UfB6kGqIkZvrf6ZbAVxN7c=
X-Google-Smtp-Source: AGHT+IEfzzlKrEThxIDoeqQJTSjexInT8XU+p5eecG1+jrsJFPE0yo88kjVmh/EkyZaQ6oY7CPoLUA==
X-Received: by 2002:a05:6000:144d:b0:3a5:26fd:d46f with SMTP id ffacd0b85a97d-3a6d12da03fmr8087747f8f.32.1750659169364;
        Sun, 22 Jun 2025 23:12:49 -0700 (PDT)
Message-ID: 
Date: Mon, 23 Jun 2025 08:12:40 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4] automation/eclair: update configuration of D4.10
To: Stefano Stabellini 
Cc: Andrew Cooper ,
 Stefano Stabellini , michal.orzel@amd.com,
 julien@xen.org, roger.pau@citrix.com, bertrand.marquis@arm.com,
 federico.serafini@bugseng.com, Nicola Vetrini ,
 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 21.06.2025 04:19, Stefano Stabellini wrote:
> On Tue, 10 Jun 2025, Jan Beulich wrote:
>> On 06.06.2025 23:04, Stefano Stabellini wrote:
>>> --- a/xen/arch/x86/include/asm/cpufeatures.h
>>> +++ b/xen/arch/x86/include/asm/cpufeatures.h
>>> @@ -1,6 +1,6 @@
>>> -/*
>>> - * Explicitly intended for multiple inclusion.
>>> - */
>>> +/* This file is intended to be included multiple times. */
>>
>> While I can see that this may indeed be needed, ...
>>
>>> +/*#ifndef X86_CPUFEATURES_H */
>>> +/*#define X86_CPUFEATURES_H */
>>
>> ... I wonder what this is about. Sorry, I didn't spot this as a change
>> in v3. If it's needed, these comments want to be well formed (have a
>> space between * and #).
> 
> Without it, ECLAIR throws other violations. But I can fix the lack of a
> space.

So the original comment that was there didn't serve its purpose?

>> Beyond this - why is this header ending up different from e.g.
>> public/errno.h, where a SAF-8 comment is used?
> 
> Because SAF-8 is meant to be used on top of an #ifndef and there is no
> #ifndef here

How can that be? SAF-8 is specifically to cover for the lack of a guard,
i.e. typically the lack of any (respective) #ifndef. SAF-8's description
also says nothing along these lines. And then it looks to be possible to
add some #ifndef here, e.g. checking NCAPINTS. Just that the #endif would
need to come early, and another #ifndef would then be wanted at about 2/3
of the file.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 06:15:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 06:15:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022025.1397722 (Exim 4.92)
	(envelope-from )
	id 1uTaSp-0006hP-Jb; Mon, 23 Jun 2025 06:15:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022025.1397722; Mon, 23 Jun 2025 06:15:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTaSp-0006hI-FB; Mon, 23 Jun 2025 06:15:31 +0000
Received: by outflank-mailman (input) for mailman id 1022025;
 Mon, 23 Jun 2025 06:15: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 1uTaSo-0006hC-FL
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 06:15:30 +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 75faa03a-4ff9-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 08:15:29 +0200 (CEST)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-453426170b6so28017705e9.1
 for ; Sun, 22 Jun 2025 23:15:29 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d860a36dsm74164405ad.126.2025.06.22.23.15.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 22 Jun 2025 23:15:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 75faa03a-4ff9-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750659329; x=1751264129; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=i/66+BbyWZjipRIbTVLUqDpjpWtyUCNphjAJTGprYlo=;
        b=RIOCe5DRoQnGlq0mX3H4FfPHl5aVhMfDiMwus2qhwUK9G2i6uVKzq7bVX/oyg9Szh2
         7rVON//+3eyF9FGqvSo4WVLoU0ijM5G1M7+Al0/rG1NOeS4y2ZtKbYFeXyaAuCgG3hTn
         jifemAu9p7XbwmDMO8f1HfMfJh9Z32Ztg+yvJx1xET8l0DTqXRPaY+FPDeRFaE7U2TcO
         8IwjWBwkDOG0z12SL5v+TT5RDiFg+vLZ8Fchx7c2hoCY++9z+KzwgQ0F5sCb5UIcK/bC
         kDC9nDcAMuCn0GAxDNeSxXFTpZeMXyTSzyv4vJdHlyg/pi3RDXu01Rx5LrpnkeRGGX+a
         +yvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750659329; x=1751264129;
        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=i/66+BbyWZjipRIbTVLUqDpjpWtyUCNphjAJTGprYlo=;
        b=OJHpSO2hRwm4z9edbbZnw1zn6ZziEsQLPchEsxJeXB6UNIfKazEkMOUc3f3Twg/eH3
         s+ClmcUe07Qmgy6Z9ZT5q1TL61TeIgYyseaqoJiE5qAdR+D0bzoafwjpZ4H056HLRAX2
         Do081ht5Ql7CqPrNIFYwU+9WHuKpX4nzlprcQjpTnVrfRsoEsY6dxHB06dzOSSbbJnIC
         yRnF3X+tB9RBLZNG8dg+eWemOoG/PQI3dszRRXJKPflwtIgovlyVshTBHLqsN2CCzYzq
         FWY8Y616k5jz8TQaZcLaJ5TevVNeOf9KhFQw/Eio+vSLBjH2/AdGRmsvkzznQywMaC9v
         Djwg==
X-Gm-Message-State: AOJu0YyqGWfEJ2hqB86JhFJE2wTSPl0tuANX40RyCuRsCSK98AvL2kTQ
	qDs/g0dOHI1UMBMpmps1Z3rxLtIJ9pnU5zHT21JOUmEIGQGngXv1v9tykeqoSozVYA==
X-Gm-Gg: ASbGncsG67CP6E/UB1cXnGglRtSupWJqrPWTmRBcINBdNFBYPHva9J7L7tQjh8dty84
	73Z+g1gVcUix/oprwDDCGQyuWMG53cvehWz5x1W1DKDOvM6qf4kSTlVn/RZ4Y0/cGO4Lk5zlrDH
	Il95/SgZJ+7KaN5R4Q35q6axujapRgHQSLHoeJTPPI3O9UlvhWDpBPjoL9MMBbkV+1qLb1HNdea
	2vxVClW8tl4hTfRUATImqF0ZTNXVjNzmwpFG3dZZyFYONOAi/6xW6rVl9Vzuxy3Tr2Uvvmo/7M9
	VHcUKnpcb5EewujHHHU/BCesMwTzxofuzmZ+vJyuFP2N2yxQwQG9Vd/CHdp620ZaI/aQNCM8apZ
	48qiZQXFYaSWE+kGFnGtP7nT6LMYdQbpKh/tTDHJmmOkDV3c=
X-Google-Smtp-Source: AGHT+IEaRdMTfOBX+25bv97ZJPuzThBsvceXHBR6L+/Vj1YKHrsvfl6X0ocxqJhQwF0AZyLWE9en7g==
X-Received: by 2002:a05:6000:1ac9:b0:3a6:daff:9e5 with SMTP id ffacd0b85a97d-3a6daff0b13mr3157062f8f.7.1750659328838;
        Sun, 22 Jun 2025 23:15:28 -0700 (PDT)
Message-ID: 
Date: Mon, 23 Jun 2025 08:15:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5] automation/eclair: update configuration of D4.10
To: Stefano Stabellini ,
 Nicola Vetrini 
Cc: xen-devel@lists.xenproject.org, Andrew Cooper
 , Stefano Stabellini
 , michal.orzel@amd.com, julien@xen.org,
 roger.pau@citrix.com, bertrand.marquis@arm.com, federico.serafini@bugseng.com
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 22.06.2025 22:58, Stefano Stabellini wrote:
> On Sun, 22 Jun 2025, Nicola Vetrini wrote:
>> On 2025-06-21 04:19, Stefano Stabellini wrote:
>>> --- a/xen/arch/x86/include/asm/cpufeatures.h
>>> +++ b/xen/arch/x86/include/asm/cpufeatures.h
>>> @@ -1,6 +1,6 @@
>>> -/*
>>> - * Explicitly intended for multiple inclusion.
>>> - */
>>> +/* This file is intended to be included multiple times. */
>>> +/* #ifndef X86_CPUFEATURES_H */
>>> +/* #define X86_CPUFEATURES_H */
>>>
>>
>> Are these two lines really needed? I may be mistaken, but I think the
>> violation's first location would be the #include below with a comment a couple
>> of lines above captured by the config at the top [1]. @Federico thoughts?
> 
> Without these 2 lines, ECLAIR complains about the following:
> 
> #include 
>        ^
>  MC3A2.D4.10non-compliant start of header file

And that's where hence a SAF-8 comment cold be placed, I would think.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 07:11:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 07:11:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022032.1397731 (Exim 4.92)
	(envelope-from )
	id 1uTbKz-0005dk-CS; Mon, 23 Jun 2025 07:11:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022032.1397731; Mon, 23 Jun 2025 07:11: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 1uTbKz-0005dd-8F; Mon, 23 Jun 2025 07:11:29 +0000
Received: by outflank-mailman (input) for mailman id 1022032;
 Mon, 23 Jun 2025 07:11: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 1uTbKy-0005dX-B3
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 07:11:28 +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 46ca174e-5001-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 09:11:26 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a57ae5cb17so2080608f8f.0
 for ; Mon, 23 Jun 2025 00:11:26 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-7490a2f467esm7428530b3a.0.2025.06.23.00.11.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 00:11:25 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 46ca174e-5001-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750662686; x=1751267486; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Zol6nRtAy4BAAD2ESaZwpEMoPdOolbgmSqeZRix3N60=;
        b=Qz7kTRofgmzP6DjmpmXMlPtJLWnCR7oRACMG5c1qMGaEwSKusDN3u9U+4D4CGOkNqf
         6ktJKczVBmHiPS7gtKO7Eta16tcwgH+Xa/WmE9LZio8N1vyI8z3kj5mFIwUHyvx0ZS54
         O614SAL18uq04GKGu4hdV4nStSQvBB0jiu4bbYwE1ejiKYRSRfcFK3po2zg4jQ7G8Py5
         5CivXs/QR8OHofrSnC8yP6sDGgpd9Jy8ffblXJQevVFYvnF4c4gKvw0cHB+INlNHBJ/c
         lzvodu28U+feaJx44PYp1sCWlbgjNG1u5DFZ8Z3/OLgGuDs9gojwEC38+eaxx/Z0oSzT
         /xAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750662686; x=1751267486;
        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=Zol6nRtAy4BAAD2ESaZwpEMoPdOolbgmSqeZRix3N60=;
        b=b6shsqXjysKuidQRGs4+EMF20aYnYdAX3qf3FEFq7fiXkpRZJ8BB16vCwlpsBG9EiS
         3v+9FcPrHrqiijF53R1WIxVc+pG6mCm0m2nlnQcSH1SX/GoAcKpoT0wr1mmqbOuz+em0
         yd9xg6exlwI4q/t8n6bmD/Kgcc+Egcayi9xNN5dci1UxqJu0qwAkas2pfMFYSCZavoVp
         6bHzGhYbafAqpF8tWc1P8RNUZ87YqEacz6MfTfIhB+crLVbAgLuHMhqHsktGiQWQH5HJ
         C5T9+qxJMBlvHILtNbrBmlCyoajNjsuTniat50cSSDlYxiCVVDmk24dDj+fhwN6vz4N+
         u9IA==
X-Forwarded-Encrypted: i=1; AJvYcCWO9I1dnvWeCjuWkOyOcTm8kKjMB4fYJjroOsKayLiODTQIli/lY9H6LFI1MPMY00V/yCTssIow7CQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyclX//8gz+k6HSia4Hi/wEcQ/X/jaH1FQHrEEy2BxHwUwgKxTw
	nXfd33rg5gWX84BPQx2sqVjLjulx3giYcv2QvricPlCLd92ec9m7DmZtUWLrS6evZ6mXqzqZMzZ
	HuIo=
X-Gm-Gg: ASbGncsqcLiXNqHKypweZjMQ/7+zie/iJbPGeGkhsJbhv7QqjuwWriGv0zz7ypfjk+F
	16EVnaKh9EJjKSkAe7hxE0b3QvLtRntywLN6sRsBDUIN1GXahb/qBkxtTfuqyTjko7z8CHydKzJ
	EmhWTg6tIEsLHwCNs1MnD1ImBVjtNyk47Z21LoHSUDR7+0rCxrROYxg/zT5zfMJMFWqsO/ye1gT
	3qbfRObThpud+ePKERt2f7gS+PVO670+FZuVVQV8jXkQnQDJmJc+SbaGBjg4VN1tJit/9rRMkq6
	EyOWGkVPt25MyHvXkATjEEW4tdi3dOsBKZ+6xrjdDQTE4dhES40knKYmF/aNBPiYTphrRFhz09B
	l9SJFSuV6/RrcRnI2ymDKkK2cJN/ieo4f/jRnA+d1UnHdseI=
X-Google-Smtp-Source: AGHT+IGvmoBtxC48yYndYKupMReu3K/DEErbg1TXNxQVtFfTxCf7vmv+PtWzT/7a+XGyF+fLago8/Q==
X-Received: by 2002:a05:6000:471e:b0:3a4:dfc2:bb60 with SMTP id ffacd0b85a97d-3a6d12a9a5amr6825098f8f.26.1750662685638;
        Mon, 23 Jun 2025 00:11:25 -0700 (PDT)
Message-ID: <818cd2f3-705f-4190-85c4-d9df26edc95b@suse.com>
Date: Mon, 23 Jun 2025 09:11:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86: remove memcmp calls non-compliant with Rule 21.16.
To: Stefano Stabellini 
Cc: Nicola Vetrini ,
 Stefano Stabellini ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Alessandro Zucchelli ,
 xen-devel@lists.xenproject.org, federico.serafini@bugseng.com
References: <20250604233537.2892206-1-stefano.stabellini@amd.com>
 
 
 <13ad335c1868bcc02e2dc0a8da521f6d@bugseng.com>
 
 <315e605d-2da6-4df5-b791-b3f59e0ff6d4@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 21.06.2025 04:25, Stefano Stabellini wrote:
> On Tue, 10 Jun 2025, Jan Beulich wrote:
>> On 06.06.2025 22:49, Stefano Stabellini wrote:
>>> On Fri, 6 Jun 2025, Nicola Vetrini wrote:
>>>>>>> Signed-off-by: Alessandro Zucchelli 
>>>>>>
>>>>>> Missing your own S-o-b.
>>>>>>
>>>>>> Also (nit) may I ask that you drop the full stop from the patch subject?
>>>>>
>>>>> I'll add the S-o-B and fix the subject
>>>>>
>>>>>
>>>>>>> --- a/xen/arch/x86/dmi_scan.c
>>>>>>> +++ b/xen/arch/x86/dmi_scan.c
>>>>>>> @@ -233,7 +233,7 @@ void __init dmi_efi_get_table(const void *smbios,
>>>>>> const void *smbios3)
>>>>>>>  	const struct smbios_eps *eps = smbios;
>>>>>>>  	const struct smbios3_eps *eps3 = smbios3;
>>>>>>>
>>>>>>> -	if (eps3 && memcmp(eps3->anchor, "_SM3_", 5) == 0 &&
>>>>>>> +	if (eps3 && strncmp(eps3->anchor, "_SM3_", 5) == 0 &&
>>>>>>
>>>>>> Unlike the last example given in the doc, this does not pose the risk of
>>>>>> false "not equal" returns. Considering there's no example there exactly
>>>>>> matching this situation, I'm not convinced a change is actually needed.
>>>>>> (Applies to all other changes here, too.)
>>>>>
>>>>> If we consider string literals "pointer types", then I think you are
>>>>> right that this would fall under what is permitted by 21.16. Nicola,
>>>>> what do you think?
>>>>>
>>>>
>>>> While I agree that the result of the comparison is correct either way in these
>>>> cases, the rule is written to be simple to apply (i.e., not limited only to
>>>> those cases that may differ), and in particular in the rationale it is
>>>> indicated that using memcmp to compare string *may* indicate a mistake. As
>>>> written above, deviating the string literal comparisons is an option, which
>>>> can be justified with efficiency concerns, but it goes a bit against the
>>>> rationale of the rule itself.
>>>
>>> Also looking at Andrew's reply, it seems that the preference is to
>>> deviate string literals. The change to docs/misra/rules.rst is easy
>>> enough, but I am not sure how to make the corresponding change to
>>> analysis.ecl.
>>>
>>> diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
>>> index e1c26030e8..56b6e351df 100644
>>> --- a/docs/misra/rules.rst
>>> +++ b/docs/misra/rules.rst
>>> @@ -813,7 +813,7 @@ maintainers if you want to suggest a change.
>>>         shall point to either a pointer type, an essentially signed type,
>>>         an essentially unsigned type, an essentially Boolean type or an
>>>         essentially enum type
>>> -     - void* arguments are allowed
>>> +     - void* and string literals arguments are allowed
>>
>> Yet as per my earlier reply: This would go too far, wouldn't it?
> 
> You are suggesting:
> 
> "void* arguments are allowed. string literals arguments are allowed when
> the last argument passed for the comparison is equal to the size of the
> string."
> 
> Please suggest another wording if you prefer.

Just some marginal change:

"void* arguments are allowed. string literal arguments are allowed when
 the last argument passed for the comparison is less or equal to the size
 of the string."

Without the "less than" part I expect we'd run into issues when certain
signatures are checked. The size of the string literal includes the nul
terminator, whereas signatures typically don't.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 07:15:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 07:15:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022043.1397740 (Exim 4.92)
	(envelope-from )
	id 1uTbPB-0006GD-U0; Mon, 23 Jun 2025 07:15:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022043.1397740; Mon, 23 Jun 2025 07:15:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTbPB-0006G6-RE; Mon, 23 Jun 2025 07:15:49 +0000
Received: by outflank-mailman (input) for mailman id 1022043;
 Mon, 23 Jun 2025 07: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 1uTbPA-0006G0-DZ
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 07:15:48 +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 e147ef18-5001-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 09:15:45 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-451d3f72391so34852245e9.3
 for ; Mon, 23 Jun 2025 00:15:45 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b31f12427c2sm6097095a12.49.2025.06.23.00.15.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 00:15:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e147ef18-5001-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750662945; x=1751267745; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=bBIR3xUA+7/nSy30seLjIpM9vSgQ8LCuYIcpBh0C6tw=;
        b=gONz4CxTwPhinUIzLMT5hnKFOuAlQZNGhuEeOV3NgQ/c9dsPShh7c+Hxv47moBgmNm
         oS+WiHWf9+7lFy/b6R+u96CObVMqbUsCjKnVmbqmI1DTDQ+DicN1BREQC8YMNYwohTHl
         QsXgZM9BRYPy7NAUV4kVi0zO5Cl1Yz1LnDIC5AmcWQHxBl6fXaHQUh8aviPmrJz1pGyV
         Jop7VB5VRjoNQnVKe03zbvw6UvB/S/aGdwEpJTMq1us2ldX2dmvdSgIdN+qd0TlVEWGe
         y0LePCXqo/wpR4DLY2w+9v7E7X/Ln+vM+dvURYx2xwajmHvQPZoiF3x1nMhxmswppmRU
         YLuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750662945; x=1751267745;
        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=bBIR3xUA+7/nSy30seLjIpM9vSgQ8LCuYIcpBh0C6tw=;
        b=G+IyKY9szQ0mj6rsR0G2miwyxwGyGZrvoUDu7odIBvzD2qnfo2q3FwGWFaDN2pEHuP
         rA4mEIhPX3Zgki7HrnLjXK6swDa2Y7BeSgS2l7JJRca0pJSbW/QXywiOdvTNsYCVX0Ap
         oiu+Uq0BbT+a6b9poDbXXIQSK+EKm0fcESsT64L1tpPa8UkMP34K03af3mbweJzcl+7z
         e11AEl+WlGsob6K7ak0bZv1JdSBGdN3jzs8uZMHwtm6XiFAutaCaU0YdYNFHp7PvDTCR
         /uKKVsUpGzfWG3z1hKUcgYLMOSx6YibrhEBHYrVhAwcaAo6sUK09YGW2Pehv+nrozRSN
         bizA==
X-Gm-Message-State: AOJu0YwaHyMfB9x/QjYbm6NkfJu8ZW115kXNkfMcapl87wSRtstnbTrL
	tXVWG6MS/QIbeFSBpBBwu32BFcn7w1yVGF8qSYP4mILHUxHw3qz99Q1B7b0gXBtEag==
X-Gm-Gg: ASbGncsv76xpbDWEautxZVxntQuV/zIbaL9ZrhP0w1Jp+8U3lVmLfqOMWu0yWzUZdjf
	XNjP30ZmeuUnJTTW1V2maBp+6p5W74vOJh3lcjnX9cEHqGgzDIlEFpLUlNjg2kJNzxcYGUlme6k
	cyDxi/iyDr85OwJPSBhpO03qWwsIiB5PtDZwT66vv25rdcWpJEvmV0C3RwPu3bGgYzE3OAr2d38
	zSHrx3DwC7CQQzdZmdxM2DhnWjbiBO8Ri768lPKcGseLDKWaERfe0XGcGHpbOo2/ILTFIHY0bEC
	P6Gz9uce132SixQvaCobd3JTZgkwv20gMExsNqyUGpcGF0OkN/hwY7v3JBcfyHWqGH55CwLaygt
	tZ2Ua2uiVMQqPlGPkKUh+JRcPfZ+OLcpqxIL5q9naOCkzi0eqiwynNbUlEA==
X-Google-Smtp-Source: AGHT+IFOz/KE3WvZXGS4BJb8mKO63jtiUF54GGZjHM/KM5vhq8Bf+0XSsy1e6WpFfTbyaCDj5P2+oQ==
X-Received: by 2002:a05:6000:2907:b0:399:6dd9:9f40 with SMTP id ffacd0b85a97d-3a6d12c43dbmr9858409f8f.9.1750662944784;
        Mon, 23 Jun 2025 00:15:44 -0700 (PDT)
Message-ID: <1e116116-ddf7-4640-9809-2502203abe46@suse.com>
Date: Mon, 23 Jun 2025 09:15:35 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v4 5/8] xen/domctl: extend XEN_DOMCTL_assign_device to
 handle not only iommu
To: Oleksii Moisieiev 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper ,
 Anthony PERARD ,
 Bertrand Marquis , Juergen Gross
 , Julien Grall ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Volodymyr Babchuk ,
 Grygorii Strashko ,
 Stefano Stabellini 
References: 
 <4f58bf9c47c40413ee9250c4cd21458382aac857.1747669845.git.oleksii_moisieiev@epam.com>
 
 
 
 <1780646c-cb6f-4508-86c8-a573fbc09f6a@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: <1780646c-cb6f-4508-86c8-a573fbc09f6a@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.06.2025 18:15, Oleksii Moisieiev wrote:
> 
> On 18/06/2025 03:04, Stefano Stabellini wrote:
>> On Thu, 12 Jun 2025, Oleksii Moisieiev wrote:
>>> Hi Stefano,
>>>
>>> I'm very sorry for a long silence. Please see my answers below:
>>>
>>> On 22/05/2025 03:25, Stefano Stabellini wrote:
>>>> On Mon, 19 May 2025, Oleksii Moisieiev wrote:
>>>>> From: Grygorii Strashko
>>>>>
>>>>> Add chained handling of assigned DT devices to support access-controller
>>>>> functionality through SCI framework, so DT device assign request can be
>>>>> passed to FW for processing and enabling VM access to requested device
>>>>> (for example, device power management through FW interface like SCMI).
>>>>>
>>>>> The SCI access-controller DT device processing is chained after IOMMU
>>>>> processing and expected to be executed for any DT device regardless of its
>>>>> protection by IOMMU (or if IOMMU is disabled).
>>>>>
>>>>> This allows to pass not only IOMMU protected DT device through
>>>>> xl.cfg:"dtdev" property for processing:
>>>>>
>>>>> dtdev = [
>>>>>       "/soc/video@e6ef0000", <- IOMMU protected device
>>>>>       "/soc/i2c@e6508000", <- not IOMMU protected device
>>>>> ]
>>>>>
>>>>> The change is done in two parts:
>>>>> 1) update iommu_do_dt_domctl() to check for dt_device_is_protected() and
>>>>> not fail if DT device is not protected by IOMMU
>>>>> 2) add chained call to sci_do_domctl() in do_domctl()
>>>>>
>>>>> Signed-off-by: Grygorii Strashko
>>>>> Signed-off-by: Oleksii Moisieiev
>>>>> ---
>>>>>
>>>>>
>>>>>
>>>>>    xen/arch/arm/firmware/sci.c             | 37 +++++++++++++++++++++++++
>>>>>    xen/arch/arm/include/asm/firmware/sci.h | 14 ++++++++++
>>>>>    xen/common/domctl.c                     | 19 +++++++++++++
>>>>>    xen/drivers/passthrough/device_tree.c   |  6 ++++
>>>>>    4 files changed, 76 insertions(+)
>>>>>
>>>>> diff --git a/xen/arch/arm/firmware/sci.c b/xen/arch/arm/firmware/sci.c
>>>>> index e1522e10e2..8efd541c4f 100644
>>>>> --- a/xen/arch/arm/firmware/sci.c
>>>>> +++ b/xen/arch/arm/firmware/sci.c
>>>>> @@ -126,6 +126,43 @@ int sci_assign_dt_device(struct domain *d, struct dt_device_node *dev)
>>>>>        return 0;
>>>>>    }
>>>>>    
>>>>> +int sci_do_domctl(struct xen_domctl *domctl, struct domain *d,
>>>>> +                  XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
>>>>> +{
>>>>> +    struct dt_device_node *dev;
>>>>> +    int ret = 0;
>>>>> +
>>>>> +    switch ( domctl->cmd )
>>>>> +    {
>>>>> +    case XEN_DOMCTL_assign_device:
>>>>> +        ret = -EOPNOTSUPP;
>>>> Are you sure -EOPNOTSUPP is the right error code for the 3 checks below?
>>> The -EOPNOTSUPP code is used because this is part of a chained call after
>>> iommu_do_domctl, as stated in xen/common/domctl.c:859. The
>>> XEN_DOMCTL_assign_device
>>> call is expected to handle any DT device, regardless of whether the DT
>>> device is
>>> protected by an IOMMU or if the IOMMU is disabled.
>>> The following cases are considered:
>>>
>>> 1. IOMMU Protected Device (Success)
>>>
>>> If the device is protected by the IOMMU and iommu_do_domctl returns 0,
>>> we continue
>>> processing the DT device by calling sci_do_domctl.
>>>
>>> 2. IOMMU Disabled (-EOPNOTSUPP from iommu_do_domctl)
>>>
>>> If iommu_do_domctl returns -EOPNOTSUPP, indicating that the IOMMU is
>>> disabled,
>>> we still proceed to call sci_do_domctl.
>> OK this makes sense.  I think it is OK to have a special error code to
>> say "the IOMMU is disabled" but I don't know if it is a good idea to try
>> to use -EOPNOTSUPP for that. -EOPNOTSUPP could mean a hypervisor
>> configuration with domctl disabled, for instance.
>>
>> It might be wiser to use a different error code. Maybe ENOENT?
>>
> I see that in the following commit:
> 
> 71e617a6b8 (use is_iommu_enabled() where appropriate..., 2019-09-17)
> 
> -ENOSYS return code was changed to -EOPNOTSUPP in iommu_do_domctl.
> 
> It's not clear to me why this was done from the commit description.

This has been discussed many times elsewhere. Many of our ENOSYS uses are
simply wrong. ENOSYS has very limited applicability: Unavailability of a
top-level hypercall (originally: syscall).

> Maybe we should add commit author?

You might, but Paul hasn't been active in Xen for quite some time now.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 07:26:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 07:26:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022050.1397751 (Exim 4.92)
	(envelope-from )
	id 1uTbZ2-0007ux-Nj; Mon, 23 Jun 2025 07:26:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022050.1397751; Mon, 23 Jun 2025 07:26: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 1uTbZ2-0007uq-L4; Mon, 23 Jun 2025 07:26:00 +0000
Received: by outflank-mailman (input) for mailman id 1022050;
 Mon, 23 Jun 2025 07:25: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 1uTbZ0-0007uk-V0
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 07:25:59 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on20609.outbound.protection.outlook.com
 [2a01:111:f403:2407::609])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4cd34663-5003-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 09:25:56 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 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.8857.25; Mon, 23 Jun
 2025 07:25:52 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8857.026; Mon, 23 Jun 2025
 07:25: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: 4cd34663-5003-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=HzA04K424lka1oquFfBW2T/m6eQOk5i55rzQg6lK7vWaDad/v+NxutLd7Mn4AfMd2To+hhmN+YAQQH4wCL5DWZxlWk68t74rHbDH7JcXZZCSwSkztywZ+y8c6RoFmALaHoxHxrVi7Md/nYQkicJkACQVeMWPDf6ApLWVo0sfjJCSw2ys+B/JTQsHAPvewmltvLa48Mn0JJ29M7aYLz1+IM29cB3r2hJ4EVSJuK6O4IZV6I8Hzbr0KBZIeZY+Ma4DD5V57wZygFg4VLXxGHINuWxpUK4pQAKC4xREbG6qQqcZJlS1seMwGaawwwn0kdKVplLVwau7g7VB75GERYW3gA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=xQ8K5CW1iSp6wsw3fww2lA0NxfyiVxbhq2O0EC8zilU=;
 b=w3Qch6CSNaUGz32+XodX8lGFctrdYwANAHDodX/yJiJsD5E7eLMyng0Rq2sHUZMpgETNOSW5pkxMbh6hyJqZS0v2bL8+2CKplLzjH9P/2yeAyMbOhNXTmV1umX6F5j+EfXtcyaY1d4CnKODuo2bUIELdPRF19DoCMhGtqWArz6YkNKgC1AQZRo7YywtqOLbuiv0RoPEdABEMs891tM6ZpHDJbdR8LPRlJ1kkWcLD4/3udRsX8ZGfKF0s9EqBGzes+oMA+G2l5RdiPizXdfKjQUtYEhVAqsVphKm0KXB87wCqsudaFYcFRW4RXwQP2XEUA47sc/0x/HVAAadVRvHlIw==
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=xQ8K5CW1iSp6wsw3fww2lA0NxfyiVxbhq2O0EC8zilU=;
 b=EG+eYDDzxQARSRiXTvjG74FigC0GvE2w1Ur2wypXuhtS1pgdpz8+GlMSIgpv68yCgEZ7SySxnoumLivS3BBrLcdcJhUl9VKBQmlOyzdZoP11rPOxmQFlwt+8U/AO7NDDJMgX3dCr0O4ZWIbmUbHpwzOCX80j4G6nvJfF0ROZyBg=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <445c5594-a003-4cd8-aa46-8544c0543b1c@amd.com>
Date: Mon, 23 Jun 2025 09:25:48 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/arm: Enhance IPMMU-VMSA driver robustness and debug
 output
To: Jahan Murudi , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250620103123.2174529-1-jahan.murudi.zg@renesas.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250620103123.2174529-1-jahan.murudi.zg@renesas.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: AS9PR05CA0266.eurprd05.prod.outlook.com
 (2603:10a6:20b:493::7) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|PH7PR12MB6562:EE_
X-MS-Office365-Filtering-Correlation-Id: 6665f1fd-ecd7-464d-5a8c-08ddb2272edd
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?R3J4ajBYWitHUis1dllPZmJtdjBya0pHbDRRTG5Rd2oyM0VTY0tFM0F2QUZ1?=
 =?utf-8?B?UENiQ21lWk4vUHNOeWxxWEJYMVZDRjVEV05LemMycGhhMUlidEdvUVJydW9r?=
 =?utf-8?B?Nll3Z2FuNEJicG9PTGZoWHVhVUdqYkVrZzBiWm8rd2V1MjREVCthWTdoOFZu?=
 =?utf-8?B?NHE0MmVsN2pvOVBYbDc3MFZHa0xtUm1QL3hqOFJqQzliZnZhZ3pjeENmekJk?=
 =?utf-8?B?ZU56R0JRU09YbEZ6YkczZU81bnpXYjRvbW9SU2x4VENXRkRsQlhiYzZ3MDlP?=
 =?utf-8?B?WVN5WU5ZT1VJQ0tCeE9QZTU4M2NmWldTVEI2aU5acldzdXhQTWVtWi80TlM4?=
 =?utf-8?B?NkdPZkV6SUc0djBPbkJsSW1KVW1kV05DSVMzb3pDVjd1SVY3MHdCbFhUNmRa?=
 =?utf-8?B?TTBwU0J4V3h1dGlRbmE3NHBDRHU1NDRGbVpGQTBuSFdJTWRZblRpOC9qdHhk?=
 =?utf-8?B?Q21QdTA5RVpCUEZld1ExcHNkNEYrYzJ3dEZrRGp4OTZvTEtJY09sMkpaUVZK?=
 =?utf-8?B?NVRyeWIrWWd1eERPVDdtZ21hcUExQm15TUcwdFRlRk1GWkdpMlg2YlhUbmpp?=
 =?utf-8?B?eUgrN2puZy9aMWY5bHJQSVUvZExmOUhHdWVvMzczTUpDOUtzK3dpVlYzbmhK?=
 =?utf-8?B?d0F4K0RzVXFXOGJDOE4rT1ZacjFxVUNzSkNTdGNrdERTWit2TWZiYU5hc1No?=
 =?utf-8?B?b3hIK2VDakFWNjUxdG5MN1pwa2pBWGdSMUxXVnVRdVJrTE5vcXlFMjBaZW9l?=
 =?utf-8?B?OVMxN0RXdzdBcmlDbGhlaVVXM2JIZ1lKWkl4aHJOdlZlYlhzQmVHTFZiMnpF?=
 =?utf-8?B?c0ZFN1JabDBxV1BIdjc3RlVEcktZclRrK2hDVW53bi9mWkhGRko1TnFTaVFS?=
 =?utf-8?B?U3FzdTdNYXpYMG1MNUpGQ3FUVTFHREJEYlhlZEhKejU4dmxNeVdWYUoycmww?=
 =?utf-8?B?SE9Ib1piYkdrclVUL3VYRmo4RWc3Z3Jpclk5OHJSUXZCcVlYWW1ZdXYwN2Rh?=
 =?utf-8?B?VjBvSE8xVVVqb1h6Q2FUeDdSbFRkSERFSzFYbVhMRmoyMU1yaU9IdDRRaHRV?=
 =?utf-8?B?Vyt2UStwVHdpa3RFb0NQL2JLRnNyN2V6Y0ozRWluNUpENmxkRDEzZ3l0VVNp?=
 =?utf-8?B?VDEwTXhRcS9ERlUzNWFtTWJSb2NlRmduSmVnR2FpYU5Ta3RMbVRsWEdBc2Iw?=
 =?utf-8?B?OWFoWEpJNHJTT1BmOGVCUVZ5YTVoeVgvejNtQlBHWW1sRFdEeXBHaTltNkM0?=
 =?utf-8?B?OHBNSEZjWXNJZFpUZjNwOUVhRG96M05ZVUhHcjM0OHhJbzZXN2pGRGl4SENR?=
 =?utf-8?B?TnVvaTdFMDE4LzlwVElFckhQbHBiTWJnUCt3N2packVBWmJ2V1loYzA4RUhU?=
 =?utf-8?B?dzV2ZVJ6NnowVmp6N1I2bjZvM2svK040cHY4bW5ManUrR0RMaUNHMHNmOTJW?=
 =?utf-8?B?OGF5ZUh0U0FJYWQwSFRwS3NTTTQzU2ZkNjZqald6TG96STVjQm42VnFDOXJZ?=
 =?utf-8?B?cFc3ejVGVFNNNW9QZnhSY0RCZVZYdG1tcjRVSmNZbnl6VmhRTEFJVGt5RUJQ?=
 =?utf-8?B?Vm15QnpPVWpCaDI5QWs1bnZRSENVaWQ5bnRvc2h2QW5xWmwwcXpoSGtkbXR4?=
 =?utf-8?B?UlRFNG1jTFZJMG4yUFdaRytia2MwZ0EzVGJPd1V5aUIvRWovQjdFeldvaFd4?=
 =?utf-8?B?b2w2OW41KzZUZFYwSHpsVDdzcWVMT1h2WmRCU2lNaU1OVXZSSDlpTWZISXVr?=
 =?utf-8?B?bS9sTTJRckxiYnRzRm82cldVakdMSjRybU40bVUvZW1LZWhqdGRLTnc3Njhs?=
 =?utf-8?B?Qis4NTgxb09xLytvZVhLUnpPbFpES2lBWVBJUWNlYy9RQVd2dG80WGlJc253?=
 =?utf-8?B?c1JuR0M2dGRSWnkwNElqQnViS3RjYnB6Rk4vbUN4OE1WU1ZDMFZZcTdDaXYv?=
 =?utf-8?Q?H7KPwXCu08c=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?cks4eS9BdUJLZkRoSjZTaFdvL1NON2pxd1hhYXNXRlhrM0NIOWkySTFCQUdt?=
 =?utf-8?B?S0ZGQjl1T0MvWUtLV1NwMjNjb3NZREdsWGpSYWhVcnZXcWF4N1BWMEQ4MFox?=
 =?utf-8?B?Tmt0by9KK1dxcmF0M2xnUHhiQmFhbVVPeUs2U3d0OCtzL0tTeC9zTmczK3hR?=
 =?utf-8?B?bmNQcnMvSFBmRTFFbWlhM1hRN1NMdU5FZ1pZakg1SFcyalZFU1hFakMzUldC?=
 =?utf-8?B?T2YrbGJKb1Y3dFpZVkY1cUp0NXl1c1VCN3JKNUErUjdJandIaE1jdGN5dlRH?=
 =?utf-8?B?VWRoa2VGdW0wUUFFTnh3NGlIdnE2ZGwwcmNCcHZ4bmRBT1drclJCYk81a25M?=
 =?utf-8?B?Q1YxYXMvVDFzVUl3UEpNMlU1bEFGSjJ1UFhiaHNMa1A3dU9URDUwVm80bUxp?=
 =?utf-8?B?QXh0SElDS2xmRUI1WWd2aDNaS0pYcTBFNHI5Y0o5Ym5vUDFjSTBkMDNrRTBR?=
 =?utf-8?B?SlZ0WlJiYU1HS0VSRDJ5Zi9neUhBZjN4QWRsUC9abDM3WmdnYVFZcTJSZHov?=
 =?utf-8?B?VmRNV3FkVmtITDlLZU5RZE8xS1ZPdy9xNXA3bktoOC80YmZYbjlDd1VyN242?=
 =?utf-8?B?YkZieWh6S2o4MW05U2d3NW1kbS9MOHFMaUhsTGtMbVhNOWVvMU1KUlhUUnFF?=
 =?utf-8?B?dnpGSHNtQ1Jic2tqTXZoeVRYL3VlQmJMdWdwcjZTWmQxZlB3cC9TL09tWURx?=
 =?utf-8?B?YTdWQllFdHhJSEVDTGZGUFkzeDdETFRKUHNJWUpKbXdMYnU3bTVXdzRMT3B3?=
 =?utf-8?B?bDlGYlgyMDZ6NUNQYjRMOUNieTJuZm5rdzRPM3hieEV3cGJ1c0d5M3E2ZXpX?=
 =?utf-8?B?V2tzRDZ2eVJ2RFU4M0piMlNQczFUNHNnYVdNdDZaMUpCY3BNOXowcUhtTWhQ?=
 =?utf-8?B?ZDhnRHFuMTVCek11a1BJMGpOa2tCdktyaVU0dURSc3huT0RwcmcrREZwb1hW?=
 =?utf-8?B?Q3gzaFVHRHU5QmFad3YzaWI4RG5FRnlWVUtLa2VSUU1FZzcxd29wczRNaWlF?=
 =?utf-8?B?MDIxSFE4UXpOZ1RQRU0xWG5VVDhMaXowamJuVEhYWndlR1ZPcGNWTDhBRzQx?=
 =?utf-8?B?ZTM4OXlNVWM2OVZFUXh4aHI0TkJHVDZiVXRxOUlmWWd2NWFCMm1WOTRFQU1C?=
 =?utf-8?B?WDh6dkpEbzFLeHBQbWc5NUk0U1h2bGt6cGZFK2hJVEYwRFlQTkcyVDZSNDdV?=
 =?utf-8?B?MUgydk95dGRHKzhPM1E1NjlkWUhSZkRnSDR0OTMxeTJHcFVCd0F1V0V3OWIx?=
 =?utf-8?B?cmE4UkRXSWM1NU9peDFySG5iOWhPWkcxVHUwbkJrZURkR00yL2p5bUZHQTVI?=
 =?utf-8?B?NG0wZ3lEZE1uOTJCbHdVN2VtdGJvQnVRT05HVlp4S01saTNHbW5QQ1U3aFZj?=
 =?utf-8?B?bXRsak9PbHFqVnpBdHlEZmIwMGZaOGlQdG81RzBKN0ZpL21GdE5lLys0RDBO?=
 =?utf-8?B?V21mUnRhZEJLQ25Fd1B5N1A5ZFliY3RqdElKVFlXTXFheWpJeXc0dEEzVnVs?=
 =?utf-8?B?c1ZnM2QzVVZLbFVDTDFQNUxsUUdtd3Y0VVBOYzZRK1FISk9WZURHK0ppZHJo?=
 =?utf-8?B?U2hWSjlLWUpoU29udituMWt4RmszWWlQTUxkaWdJQVNjTCtOdUpaRTVoRmsx?=
 =?utf-8?B?dCtaUTVYLzBOZVR0ck5KYjc0ZHg5cVJ4K2c4NS80d3JDRCtrTUhzL2JMMXVW?=
 =?utf-8?B?WEFlaTJZUHZVelpJeXViTFdkREswRlVGa0Q1MCtBNjJGSHl3WUlpMTB4bTZ6?=
 =?utf-8?B?cjNZL1pmZEl0Nmo1dWE4WlhtdGJOeWR4NUd1K0c1YTlnNnlQdkdSZDB0Q2Ny?=
 =?utf-8?B?bDFWSjcrV0V0czVzUmc3cmhjSFp1MzJMUHdDbEVtSEhubDF2OVdveDk3RTJS?=
 =?utf-8?B?Q2RzUTZaMVNCYzhMV1ltaDE4d2VaS05yczlWRm9ZdlNuNXBUUkcyZHBnS055?=
 =?utf-8?B?Yk1DMGxwT3hmZFRhRWwwVFhHVHpEYTRpOTBtS3FPZ3A4d2JlZ3FDTlBQVEly?=
 =?utf-8?B?L3lXYW9mSGNtWUc3M2lqSXI0V2p3VU5Vdlgzcjlkd0xYeHRFeUo0OGtKcVhW?=
 =?utf-8?B?YzR5VEprb2ErNklFUThuWEJ4QXFMcUtEZUNxVkFlb2svSExlSEFoYWl2Sm83?=
 =?utf-8?Q?sGbA=3D?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6665f1fd-ecd7-464d-5a8c-08ddb2272edd
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jun 2025 07:25:51.8161
 (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: yBmuH9s5lQ+yfZYrXvPGTgj6MhassJ8SbjTLV50dVDgFfg7E9nNT2hWvzUH98D4Q
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6562



On 20/06/2025 12:31, Jahan Murudi wrote:
> - Fix typo in source comment ("you can found" -> "which can be found").
> - Add dsb(sy) after IMCTR write to ensure flush is complete before polling.
> - Add dev_info() log in ipmmu_device_reset() to indicate the number of disabled contexts.
> 
> These changes improve memory operation ordering, code readability, and runtime traceability
> for IPMMU on R-Car Gen3/Gen4 SoCs
> 
> Signed-off-by: Jahan Murudi 
Acked-by: Michal Orzel 

> ---
>  xen/drivers/passthrough/arm/ipmmu-vmsa.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/drivers/passthrough/arm/ipmmu-vmsa.c b/xen/drivers/passthrough/arm/ipmmu-vmsa.c
> index d828d9cf6a..dac0dd6d46 100644
> --- a/xen/drivers/passthrough/arm/ipmmu-vmsa.c
> +++ b/xen/drivers/passthrough/arm/ipmmu-vmsa.c
> @@ -13,7 +13,7 @@
>   *
>   * Based on Linux's IPMMU-VMSA driver from Renesas BSP:
>   *    drivers/iommu/ipmmu-vmsa.c
> - * you can found at:
> + * which can be found at:
>   *    url: git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git
>   *    branch: v4.14.75-ltsi/rcar-3.9.6
>   *    commit: e206eb5b81a60e64c35fbc3a999b1a0db2b98044
> @@ -433,6 +433,8 @@ static void ipmmu_tlb_invalidate(struct ipmmu_vmsa_domain *domain)
>      data |= IMCTR_FLUSH;
>      ipmmu_ctx_write_all(domain, IMCTR, data);
>  
> +    /* Force IMCTR write to complete before polling to avoid false completion check. */
> +    dsb(sy);
Any clue why Linux (mainline) does not do that?

~Michal



From xen-devel-bounces@lists.xenproject.org Mon Jun 23 07:28:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 07:28:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022057.1397761 (Exim 4.92)
	(envelope-from )
	id 1uTbbk-0008R8-4d; Mon, 23 Jun 2025 07:28:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022057.1397761; Mon, 23 Jun 2025 07:28:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTbbk-0008R1-1a; Mon, 23 Jun 2025 07:28:48 +0000
Received: by outflank-mailman (input) for mailman id 1022057;
 Mon, 23 Jun 2025 07:28: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 1uTbbi-0008Qu-Bb
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 07:28:46 +0000
Received: from PA4PR04CU001.outbound.protection.outlook.com
 (mail-francecentralazlp170130007.outbound.protection.outlook.com
 [2a01:111:f403:c20a::7])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a971695c-5003-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 09:28:30 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by AS8PR03MB7733.eurprd03.prod.outlook.com (2603:10a6:20b:403::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.29; Mon, 23 Jun
 2025 07:28:26 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%4]) with mapi id 15.20.8857.026; Mon, 23 Jun 2025
 07: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: a971695c-5003-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=NWia61va8fUwwOk7bkVVGp9r574Dsh+xg5Cd+uVRTlydKMFg6+qmSHb9wN3egfWoQa8aoY5YlA0ec50nFWJgzuihAcb3Meczm5sCjmml/287WH+TEMVQT19j1RzWEiFA2QIOgx1CA9OzVOzd4wo1kcm4oKuAwuvirTyfYVWKoImwaJY/pQguPU//flCPS1jOODsyfPUcioyL1jsFeXvJ11isIwk+dhvlfOhKYgyPMTeEVxAck5oJMYHMKN5c9f3DSkrXWtWXmoRubigA6R0iPsSMMNTNCio0dwG3zSsI6P6e1vjuYkz76XVhyU3O8+kHfIZ2cYFxxyAA0zv3GtEnOg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=PjwyexvGQRekSgV4AhLeTrC3O2F1+TG4VA9dU2Rk5uI=;
 b=BsvYV9MHnD0/nvOC8/T9eiRMmPs6XGHnia6uKVKsVBIIHaqIORmWQ6dCCrzNImvqf2Pso2MwIkaf88pr8NAWMZS/KLDW4TGW30RNvudC8OZXJBHVF17RuovguwxiQf1TM/+JF8HifSdg6gcmx27Qixz994UPi+FqRTKSikeqNY7YrC7RR9BeTArH4nF/6F9qO1goWHAn6c5ac+Nw7UFPtArUquKy1PLLI9uZl4TweaQEXnFfBEyCIzf2nFfCUhWKJfPodcqkncDA4peQJctj7ztSyDiuL8ZqTzAY1JsGhFrBxilrQ1LWoiGwq12XEr4qrP7PcS6e6ISLiMTscK3Klg==
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=PjwyexvGQRekSgV4AhLeTrC3O2F1+TG4VA9dU2Rk5uI=;
 b=jznT4tvdFZPvTUfvUveVQpMUQDDkSL9WjuElHx+O3QKcrn9Cfb1ChZbGrArIfCkSBzGsZi0PTOnhCUGo1bCb/Bms9wk8IYs9GpUIoOISpsL3ek7pd86HuAXeL4Uy7MmGaAyYs/qRF+wTwF7VEjnJYU7UVv3WuGaPoUHhtbop5PT4tBaTwzQHPrZMuNNznGy0QV10GJYv25PlTQrgci0WyUHg2zoZXDmyVyA4c7elSr+G+LUIHhGYLKLaXEWIfW5m1toYW1iK7lmH6p5lsA671uANVL33DailXU/VBvjOZxjR6z2Ob69+f9kMZA9XbeC73el9LZMFn4VY4H/SkbQDmQ==
From: Oleksii Moisieiev 
To: Jan Beulich 
CC: "xen-devel@lists.xenproject.org" , Andrew
 Cooper , Anthony PERARD
	, Bertrand Marquis ,
	Juergen Gross , Julien Grall , Michal Orzel
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Volodymyr Babchuk ,
	Grygorii Strashko , Stefano Stabellini
	, "paul.durrant@citrix.com" 
Subject: Re: [RFC PATCH v4 5/8] xen/domctl: extend XEN_DOMCTL_assign_device to
 handle not only iommu
Thread-Topic: [RFC PATCH v4 5/8] xen/domctl: extend XEN_DOMCTL_assign_device
 to handle not only iommu
Thread-Index:
 AQHbyNXPDXt2FT3RV02cltfdm/Dd7rPdzmiAgCG+LgCACKrsAIACoXoAgAWykoCAAAOUAA==
Date: Mon, 23 Jun 2025 07:28:26 +0000
Message-ID: 
References: 
 <4f58bf9c47c40413ee9250c4cd21458382aac857.1747669845.git.oleksii_moisieiev@epam.com>
 
 
 
 <1780646c-cb6f-4508-86c8-a573fbc09f6a@epam.com>
 <1e116116-ddf7-4640-9809-2502203abe46@suse.com>
In-Reply-To: <1e116116-ddf7-4640-9809-2502203abe46@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB8946:EE_|AS8PR03MB7733:EE_
x-ms-office365-filtering-correlation-id: a2f987c1-7a64-48da-066c-08ddb2278b12
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?Mkx4aksrT1FuV0VDRVBpVXpmR2Q3Q3dkL2xoSjNKc0lGeXdoaWdKL1ArcVpq?=
 =?utf-8?B?bkxWdXI1R2ZOTHFaWkw5TENoaDkrc2c5UUFQREx0eTAxQ3ZYRTRSUG4vZUJN?=
 =?utf-8?B?NmkwQ0orZFFlYjZvZEhMYW13UHducFliaHBCUHBUWDByN3BvT0o3M1RLRURx?=
 =?utf-8?B?a2NvQXlHeWo1ZGltTWhrSEl1TVBVMSswemQrRHBvR01yZTdhZFREa1lONGNR?=
 =?utf-8?B?YklmL3l1K1dTYWVRRFNxYzI4c2U3d1dGVUFOcVBqYVNFS1ZXa2Noa29Qb1pE?=
 =?utf-8?B?bTRXYk1XTkNpdjBoQnVqc3VrdzFGUThmdER0TGkxUE9WOWhCWSs4ZEIwNGlv?=
 =?utf-8?B?eHVud3VpSWluQVFJWmUwQ1l5Nm5OV2tHRFI4Q0pTWTJDbkpmc3lUV2phQlp0?=
 =?utf-8?B?WDRMRzUwZWdzZm9BUmdETkRXRXNRbEt5aUdxWWI3UTBCbHVvaDRIeTdLNk9C?=
 =?utf-8?B?aWc4V203U1BLYlhaMis2dk5vd09GcGhTYUlyWjNIL2k4MFU0aHRnaFlVR3pC?=
 =?utf-8?B?ZGVBV29WUjhTRi96WHB0dDJ2cmNMYlhjUlpIWWliTXg2bXVsUUlBNDNCQXhn?=
 =?utf-8?B?NzRDa2g3YVV1dzgwV3VyWjc3MVZDNUFCSENSVnVOQWMwY0VzRmY2Y0dNWjJK?=
 =?utf-8?B?aUFhOEhxTFFUOUFkT01BdVNwbStmbk5ha21mRGZNUXdwZnN2UVJEaEJaaGs5?=
 =?utf-8?B?czBvUnNTdW1DRDZpQ2RYSWp1TEg5N2RjeTJxdHhHMzVyZGJhN1FuWFo5RERT?=
 =?utf-8?B?UTdpTGZhbm1QZEEzOTRmMGZTUmtNR2lEU0hJZWk5emZtWkVPVWVZRzJTa2JE?=
 =?utf-8?B?RFh2Rnl1aW0xK3BSMExCT2krWXdwcStQNGRqeWlFaVNrYUU1VDUyN3BDb2hx?=
 =?utf-8?B?R0xyT2NLN0duUC93ZWc0OTJFcTlHNHViWkhnenMzSndVWTRTQkdyZndEUTky?=
 =?utf-8?B?eU92bVlmQktIdUduM3g2R3ZHWmhEdXdtcDZ1WXZib2s4SnpBL2xYUS95OFhy?=
 =?utf-8?B?Z3lOQW0wOFFySDZoRlQ4bW5qdGI2bVR5V1BhaDNCTzIwNHYwdDBEd3ZKa2E3?=
 =?utf-8?B?cUllWFB3N01PcUtieHJoL3I3QjRwSXdpdTJkd3orclZCZzdSZ1JjSXdxMTZ5?=
 =?utf-8?B?NkowWktsSitGeFlZR0hZQ2xxelloR2lObkhPdSt6cm5HbDk3QTlEZUdYbjBD?=
 =?utf-8?B?WmFxTGlpY1NxOTE1Yzh4NmNoeXFFSGI1WTIwNkQyTVlNa0hDcjlWUlFqaWVq?=
 =?utf-8?B?dVBVUng3TEZhTmVDMHQwd29aUHQwZUdOdWlGMzU0RXlZR0U5K3dkOUdRbTJu?=
 =?utf-8?B?MTZvZXVsRWdsWmd1cnhGWDJlM3lXRjM1eFBndnRQVmtQdlNiTXZweXVpMUo3?=
 =?utf-8?B?andSZjlmRWdMNTZlWk9BRXJjQVFmWlVyN0pZUFNJdElhckhkdUV3bnphRTB3?=
 =?utf-8?B?UE5hU2xyK0ptb3Q2cXJITk9qVG1MV05LQWtpc0lEYi81N1hpVTA4a2duTjRq?=
 =?utf-8?B?eDRwSGZma05TZ1RXenF2UUFQNTVrKzhpRThvUXVRN0NxOGpjemJNcGR5VGpo?=
 =?utf-8?B?SHozQndzL1dLa3RWRmFtNENjYlF5QXJrS0twOU5sY1RWYTV6VU5hTHdSeGhz?=
 =?utf-8?B?a3ZGRWMrS3FuTERNc3hPWnFQbExnVERIZmhzb3hXeFEzOU5wQUxkTm55SEI4?=
 =?utf-8?B?cWtFUnUrQmQ3UHgzU0ViK3czT1VmRXhoUTY3cmxsQ2hPT1U3cjFTOG00Y3pr?=
 =?utf-8?B?YWhSUTBPakRWTExuM0RBQ2lRbnFCUUw1TXE0QXBzSlZBTitYanZNYzBoUUV0?=
 =?utf-8?B?V1VZTit3bWtzU3ZuSHp0WGpTS2VtKzNQKzVTTDhFUVoxV0tmQmdLQzlXYWww?=
 =?utf-8?B?eVptVzUzVnFCZmVVWXkzRlpCNGpZZFk1dUtONjJDb1REcTlkaWhOdHU0d3VQ?=
 =?utf-8?B?Mkt3RXJVRmlVQkw2TkthSnRGQ29ZN3Y4dGNmSjBTd2x1ZVVTWkN1WXB5c2t1?=
 =?utf-8?Q?pTZ4GJ0clEBIEhJpvXwgBVW2c2N9Z4=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.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?d1RwUFQ1RmR1VEdUVVFPS01XN0lHUFJvNkxjU3Fqb1JQbC9pd0h3VDhDVVFF?=
 =?utf-8?B?eURzcjZwRnB6dnV5MkV3R0pINlpaOTBkK1ZaclBJYXNlYmN5OUluWnptaHhj?=
 =?utf-8?B?MHhQb21hMFc0SEVCVzhEd0QzYWlFMEZvN0pPQW1zZjd3akhNdHdSWWI2emFs?=
 =?utf-8?B?eGNRWGJySis0OWNMWmxXeFZ0RnJodHJjM2JsVEdRKzMxTWxaVzdldmZVb0I5?=
 =?utf-8?B?c1JHc3NUalRyaC8rR0xrZ3F4NHBiNTN2TGhPUVJIcjlJcmVrd205TU0wS1FT?=
 =?utf-8?B?Y0J3SXdRK1o0Vi9MMlBMZjJOejVEbUZyOXVQUXNzZ0k4dUNFZ3RwWWoxbjg0?=
 =?utf-8?B?UkRDSXJNc2d2ejYvcmU1cVYrK1VSWUVXdWJwQ2JjTC9PUjRpNkNYQkJoQTFO?=
 =?utf-8?B?UmcyU3l2cTJEaGdKTU9VMzQ1QXNISnU2Q0RLVWEyOExJSnFIaTFEVE1LR2JU?=
 =?utf-8?B?UUptUmNSc3NjMEZXSUQwWW1vd0VXcnEzd21aVjFnazhMQy9nU2VCK0tQcHBl?=
 =?utf-8?B?bjFwZmNaWmRwT2tHS0w3by82ZWxXMTJKZi9PNWUvUHptbjRCcEVOdUE3ZkJC?=
 =?utf-8?B?MlBtL0Vxc0pwNUVkRitucTVWNE5aZ3VmTlFjN3krUkRKaXRHVW9pQjlOUk1X?=
 =?utf-8?B?K0ZkeTB5dGJuSVgxY3VLTUt4am9JKzBkL01TOFdHdFBicmcvOE5FME8rY3JE?=
 =?utf-8?B?RDNubXJGcUIvTTBuTlN5dWM3U0xldlJQYituU2IzRUVKZXd1V1ZGbEhCTnRy?=
 =?utf-8?B?UjJOMEJScFI2eXl4VkRXUnNmekZKR2VGdjhHWUpGTW1hNU9MZm40blgvTita?=
 =?utf-8?B?cTA2TjdBT3ZnUXpINmM5U0xmeWgwM1FKdklzd05kT0s5Wjl3WXI1MU40V0Qx?=
 =?utf-8?B?TGtSSUZKZ0V2VEVkR1o3M1Q0OE9NSVlycTd3cE52dnRGaXB1TDZUVC9Lalkx?=
 =?utf-8?B?QjhDcTkvOHRhUVZic2FaK2I3eTNvbHBNejBibzJZY1JYM2gvZHZhWmREcm5E?=
 =?utf-8?B?YnlGTFZoL29idDc0Q2htbm5CeFB1cVlUSWQ4VWZWZFNFQmJuckpES1AwM2d3?=
 =?utf-8?B?blczcmdOUTd4V0JSeit5TVFQVXVNa3A0TVBaYm5SS3F5UDBTYmlVME9zU2s4?=
 =?utf-8?B?dUpKckc4SkQxc1NMbS9lVG5WeHZFWS9JaTl6UUJ0NFo1MGFPbE4xb3V1K3RZ?=
 =?utf-8?B?OXAwOC9MS21Bb09UMVFoYXRZb3hYZTFDOU9ZYnhpTDZQajZEdmo4bGU3MEZU?=
 =?utf-8?B?MWJSaHdqMno4VzlxU09TKzgxWjhWNXJpY1BNdG9WZkE1UE5OaGxBTkxmdTc1?=
 =?utf-8?B?T3B3UldGMjkyU3ZtSkRGaE5vclpGMHpEeGpqR3czMmhveVNEVE1uVFpsN0ZH?=
 =?utf-8?B?YjB2c0V4WFh4N21BNkFSQnFpRUZ3V0sxR0x6RTNYSkpVUk5jZllabUhhM1FU?=
 =?utf-8?B?M2s4aTV4NVQrRDVxTXV2azhnaUJmMHhhRGp2bEFtWDMyaXMxbDlqTk1ieDY5?=
 =?utf-8?B?WEdQb1o5eW5TZHNoZitJY3ZmQTY1SjZxQlcwSGpSU2dSV2lBSDB3dWFCY3FH?=
 =?utf-8?B?cHpLOVpYd0k1OW1wNm94THlVS1kwaElDUjdDOEI2WVR3d1AvRENSVVhQWGh2?=
 =?utf-8?B?TVNZdEkybmc0SlhkTlM4M0YwOWNtY05QeDJtZTNoTXFFa0x1YlM2Z1VNY1BG?=
 =?utf-8?B?Y2JHOGltK2E5bmNBQnRaRCtMTCtCWVdBQk51TXd2dng4ZGRzdkRGbHdYSVFP?=
 =?utf-8?B?ZUZOM2dlaGI2aVZsdnZ3K25Fb25ueWxxTVRSRGtxRXRRNEdSNFhGdWRtUG95?=
 =?utf-8?B?VEw5U3JpcldHTktrdTdGdU1sbFZVS04vbnJOZ0o0RHRkTVJvbHUyL205Tk8x?=
 =?utf-8?B?M0tOTHJXMHdZUGRWRERCNThBMkVsYVNaKzJtOG9YUGo4K2JsRW1OenpnaTlK?=
 =?utf-8?B?TlQzbFpDUjZhWkt0QnlXZ1ZKU2JRQzk1RzYxNkJvNGFLR2hTYVU2Njd2NzNt?=
 =?utf-8?B?dnhjNzhGMzlMaWp4Q21icklLMVUrMkVTb21ySVFWTVhvTTJFNGtDeHdtbWV3?=
 =?utf-8?B?d28zeFVwRWZQVTVzZXRuVGpLeHdPR3hyQkFxNURmNHEyMjFocFNwZGx0OXR0?=
 =?utf-8?B?UDJDMTRIcDQzbHVRMHUvMnFraEY2c2lzamVuSGpzR1VVck9hc0FRN0d5TklN?=
 =?utf-8?B?c1E9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <887EEF663D091F4E9F931F6D4D6565B7@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: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a2f987c1-7a64-48da-066c-08ddb2278b12
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2025 07:28:26.2703
 (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: BMnd0phA7flgpXznwHeDS76BTHRWi/TB2bvMLb2E4MoTe1POgy0M69eZ5121AsbtBXqzb0hrDLt2wPMFxpKwbLOsqm49dqtzzT18ZO6xRm8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7733

QWRkaW5nIFBhdWwgdG8gdGhlIGNvbnZlcnNhdGlvbi4NCg0KDQpPbiAyMy8wNi8yMDI1IDEwOjE1
LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMTkuMDYuMjAyNSAxODoxNSwgT2xla3NpaSBNb2lz
aWVpZXYgd3JvdGU6DQo+PiBPbiAxOC8wNi8yMDI1IDAzOjA0LCBTdGVmYW5vIFN0YWJlbGxpbmkg
d3JvdGU6DQo+Pj4gT24gVGh1LCAxMiBKdW4gMjAyNSwgT2xla3NpaSBNb2lzaWVpZXYgd3JvdGU6
DQo+Pj4+IEhpIFN0ZWZhbm8sDQo+Pj4+DQo+Pj4+IEknbSB2ZXJ5IHNvcnJ5IGZvciBhIGxvbmcg
c2lsZW5jZS4gUGxlYXNlIHNlZSBteSBhbnN3ZXJzIGJlbG93Og0KPj4+Pg0KPj4+PiBPbiAyMi8w
NS8yMDI1IDAzOjI1LCBTdGVmYW5vIFN0YWJlbGxpbmkgd3JvdGU6DQo+Pj4+PiBPbiBNb24sIDE5
IE1heSAyMDI1LCBPbGVrc2lpIE1vaXNpZWlldiB3cm90ZToNCj4+Pj4+PiBGcm9tOiBHcnlnb3Jp
aSBTdHJhc2hrbzxncnlnb3JpaV9zdHJhc2hrb0BlcGFtLmNvbT4NCj4+Pj4+Pg0KPj4+Pj4+IEFk
ZCBjaGFpbmVkIGhhbmRsaW5nIG9mIGFzc2lnbmVkIERUIGRldmljZXMgdG8gc3VwcG9ydCBhY2Nl
c3MtY29udHJvbGxlcg0KPj4+Pj4+IGZ1bmN0aW9uYWxpdHkgdGhyb3VnaCBTQ0kgZnJhbWV3b3Jr
LCBzbyBEVCBkZXZpY2UgYXNzaWduIHJlcXVlc3QgY2FuIGJlDQo+Pj4+Pj4gcGFzc2VkIHRvIEZX
IGZvciBwcm9jZXNzaW5nIGFuZCBlbmFibGluZyBWTSBhY2Nlc3MgdG8gcmVxdWVzdGVkIGRldmlj
ZQ0KPj4+Pj4+IChmb3IgZXhhbXBsZSwgZGV2aWNlIHBvd2VyIG1hbmFnZW1lbnQgdGhyb3VnaCBG
VyBpbnRlcmZhY2UgbGlrZSBTQ01JKS4NCj4+Pj4+Pg0KPj4+Pj4+IFRoZSBTQ0kgYWNjZXNzLWNv
bnRyb2xsZXIgRFQgZGV2aWNlIHByb2Nlc3NpbmcgaXMgY2hhaW5lZCBhZnRlciBJT01NVQ0KPj4+
Pj4+IHByb2Nlc3NpbmcgYW5kIGV4cGVjdGVkIHRvIGJlIGV4ZWN1dGVkIGZvciBhbnkgRFQgZGV2
aWNlIHJlZ2FyZGxlc3Mgb2YgaXRzDQo+Pj4+Pj4gcHJvdGVjdGlvbiBieSBJT01NVSAob3IgaWYg
SU9NTVUgaXMgZGlzYWJsZWQpLg0KPj4+Pj4+DQo+Pj4+Pj4gVGhpcyBhbGxvd3MgdG8gcGFzcyBu
b3Qgb25seSBJT01NVSBwcm90ZWN0ZWQgRFQgZGV2aWNlIHRocm91Z2gNCj4+Pj4+PiB4bC5jZmc6
ImR0ZGV2IiBwcm9wZXJ0eSBmb3IgcHJvY2Vzc2luZzoNCj4+Pj4+Pg0KPj4+Pj4+IGR0ZGV2ID0g
Ww0KPj4+Pj4+ICAgICAgICAiL3NvYy92aWRlb0BlNmVmMDAwMCIsIDwtIElPTU1VIHByb3RlY3Rl
ZCBkZXZpY2UNCj4+Pj4+PiAgICAgICAgIi9zb2MvaTJjQGU2NTA4MDAwIiwgPC0gbm90IElPTU1V
IHByb3RlY3RlZCBkZXZpY2UNCj4+Pj4+PiBdDQo+Pj4+Pj4NCj4+Pj4+PiBUaGUgY2hhbmdlIGlz
IGRvbmUgaW4gdHdvIHBhcnRzOg0KPj4+Pj4+IDEpIHVwZGF0ZSBpb21tdV9kb19kdF9kb21jdGwo
KSB0byBjaGVjayBmb3IgZHRfZGV2aWNlX2lzX3Byb3RlY3RlZCgpIGFuZA0KPj4+Pj4+IG5vdCBm
YWlsIGlmIERUIGRldmljZSBpcyBub3QgcHJvdGVjdGVkIGJ5IElPTU1VDQo+Pj4+Pj4gMikgYWRk
IGNoYWluZWQgY2FsbCB0byBzY2lfZG9fZG9tY3RsKCkgaW4gZG9fZG9tY3RsKCkNCj4+Pj4+Pg0K
Pj4+Pj4+IFNpZ25lZC1vZmYtYnk6IEdyeWdvcmlpIFN0cmFzaGtvPGdyeWdvcmlpX3N0cmFzaGtv
QGVwYW0uY29tPg0KPj4+Pj4+IFNpZ25lZC1vZmYtYnk6IE9sZWtzaWkgTW9pc2llaWV2PG9sZWtz
aWlfbW9pc2llaWV2QGVwYW0uY29tPg0KPj4+Pj4+IC0tLQ0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+
Pg0KPj4+Pj4+ICAgICB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NpLmMgICAgICAgICAgICAgfCAz
NyArKysrKysrKysrKysrKysrKysrKysrKysrDQo+Pj4+Pj4gICAgIHhlbi9hcmNoL2FybS9pbmNs
dWRlL2FzbS9maXJtd2FyZS9zY2kuaCB8IDE0ICsrKysrKysrKysNCj4+Pj4+PiAgICAgeGVuL2Nv
bW1vbi9kb21jdGwuYyAgICAgICAgICAgICAgICAgICAgIHwgMTkgKysrKysrKysrKysrKw0KPj4+
Pj4+ICAgICB4ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9kZXZpY2VfdHJlZS5jICAgfCAgNiArKysr
DQo+Pj4+Pj4gICAgIDQgZmlsZXMgY2hhbmdlZCwgNzYgaW5zZXJ0aW9ucygrKQ0KPj4+Pj4+DQo+
Pj4+Pj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY2kuYyBiL3hlbi9hcmNo
L2FybS9maXJtd2FyZS9zY2kuYw0KPj4+Pj4+IGluZGV4IGUxNTIyZTEwZTIuLjhlZmQ1NDFjNGYg
MTAwNjQ0DQo+Pj4+Pj4gLS0tIGEveGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjaS5jDQo+Pj4+Pj4g
KysrIGIveGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjaS5jDQo+Pj4+Pj4gQEAgLTEyNiw2ICsxMjYs
NDMgQEAgaW50IHNjaV9hc3NpZ25fZHRfZGV2aWNlKHN0cnVjdCBkb21haW4gKmQsIHN0cnVjdCBk
dF9kZXZpY2Vfbm9kZSAqZGV2KQ0KPj4+Pj4+ICAgICAgICAgcmV0dXJuIDA7DQo+Pj4+Pj4gICAg
IH0NCj4+Pj4+PiAgICAgDQo+Pj4+Pj4gK2ludCBzY2lfZG9fZG9tY3RsKHN0cnVjdCB4ZW5fZG9t
Y3RsICpkb21jdGwsIHN0cnVjdCBkb21haW4gKmQsDQo+Pj4+Pj4gKyAgICAgICAgICAgICAgICAg
IFhFTl9HVUVTVF9IQU5ETEVfUEFSQU0oeGVuX2RvbWN0bF90KSB1X2RvbWN0bCkNCj4+Pj4+PiAr
ew0KPj4+Pj4+ICsgICAgc3RydWN0IGR0X2RldmljZV9ub2RlICpkZXY7DQo+Pj4+Pj4gKyAgICBp
bnQgcmV0ID0gMDsNCj4+Pj4+PiArDQo+Pj4+Pj4gKyAgICBzd2l0Y2ggKCBkb21jdGwtPmNtZCAp
DQo+Pj4+Pj4gKyAgICB7DQo+Pj4+Pj4gKyAgICBjYXNlIFhFTl9ET01DVExfYXNzaWduX2Rldmlj
ZToNCj4+Pj4+PiArICAgICAgICByZXQgPSAtRU9QTk9UU1VQUDsNCj4+Pj4+IEFyZSB5b3Ugc3Vy
ZSAtRU9QTk9UU1VQUCBpcyB0aGUgcmlnaHQgZXJyb3IgY29kZSBmb3IgdGhlIDMgY2hlY2tzIGJl
bG93Pw0KPj4+PiBUaGUgLUVPUE5PVFNVUFAgY29kZSBpcyB1c2VkIGJlY2F1c2UgdGhpcyBpcyBw
YXJ0IG9mIGEgY2hhaW5lZCBjYWxsIGFmdGVyDQo+Pj4+IGlvbW11X2RvX2RvbWN0bCwgYXMgc3Rh
dGVkIGluIHhlbi9jb21tb24vZG9tY3RsLmM6ODU5LiBUaGUNCj4+Pj4gWEVOX0RPTUNUTF9hc3Np
Z25fZGV2aWNlDQo+Pj4+IGNhbGwgaXMgZXhwZWN0ZWQgdG8gaGFuZGxlIGFueSBEVCBkZXZpY2Us
IHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciB0aGUgRFQNCj4+Pj4gZGV2aWNlIGlzDQo+Pj4+IHByb3Rl
Y3RlZCBieSBhbiBJT01NVSBvciBpZiB0aGUgSU9NTVUgaXMgZGlzYWJsZWQuDQo+Pj4+IFRoZSBm
b2xsb3dpbmcgY2FzZXMgYXJlIGNvbnNpZGVyZWQ6DQo+Pj4+DQo+Pj4+IDEuIElPTU1VIFByb3Rl
Y3RlZCBEZXZpY2UgKFN1Y2Nlc3MpDQo+Pj4+DQo+Pj4+IElmIHRoZSBkZXZpY2UgaXMgcHJvdGVj
dGVkIGJ5IHRoZSBJT01NVSBhbmQgaW9tbXVfZG9fZG9tY3RsIHJldHVybnMgMCwNCj4+Pj4gd2Ug
Y29udGludWUNCj4+Pj4gcHJvY2Vzc2luZyB0aGUgRFQgZGV2aWNlIGJ5IGNhbGxpbmcgc2NpX2Rv
X2RvbWN0bC4NCj4+Pj4NCj4+Pj4gMi4gSU9NTVUgRGlzYWJsZWQgKC1FT1BOT1RTVVBQIGZyb20g
aW9tbXVfZG9fZG9tY3RsKQ0KPj4+Pg0KPj4+PiBJZiBpb21tdV9kb19kb21jdGwgcmV0dXJucyAt
RU9QTk9UU1VQUCwgaW5kaWNhdGluZyB0aGF0IHRoZSBJT01NVSBpcw0KPj4+PiBkaXNhYmxlZCwN
Cj4+Pj4gd2Ugc3RpbGwgcHJvY2VlZCB0byBjYWxsIHNjaV9kb19kb21jdGwuDQo+Pj4gT0sgdGhp
cyBtYWtlcyBzZW5zZS4gIEkgdGhpbmsgaXQgaXMgT0sgdG8gaGF2ZSBhIHNwZWNpYWwgZXJyb3Ig
Y29kZSB0bw0KPj4+IHNheSAidGhlIElPTU1VIGlzIGRpc2FibGVkIiBidXQgSSBkb24ndCBrbm93
IGlmIGl0IGlzIGEgZ29vZCBpZGVhIHRvIHRyeQ0KPj4+IHRvIHVzZSAtRU9QTk9UU1VQUCBmb3Ig
dGhhdC4gLUVPUE5PVFNVUFAgY291bGQgbWVhbiBhIGh5cGVydmlzb3INCj4+PiBjb25maWd1cmF0
aW9uIHdpdGggZG9tY3RsIGRpc2FibGVkLCBmb3IgaW5zdGFuY2UuDQo+Pj4NCj4+PiBJdCBtaWdo
dCBiZSB3aXNlciB0byB1c2UgYSBkaWZmZXJlbnQgZXJyb3IgY29kZS4gTWF5YmUgRU5PRU5UPw0K
Pj4+DQo+PiBJIHNlZSB0aGF0IGluIHRoZSBmb2xsb3dpbmcgY29tbWl0Og0KPj4NCj4+IDcxZTYx
N2E2YjggKHVzZSBpc19pb21tdV9lbmFibGVkKCkgd2hlcmUgYXBwcm9wcmlhdGUuLi4sIDIwMTkt
MDktMTcpDQo+Pg0KPj4gLUVOT1NZUyByZXR1cm4gY29kZSB3YXMgY2hhbmdlZCB0byAtRU9QTk9U
U1VQUCBpbiBpb21tdV9kb19kb21jdGwuDQo+Pg0KPj4gSXQncyBub3QgY2xlYXIgdG8gbWUgd2h5
IHRoaXMgd2FzIGRvbmUgZnJvbSB0aGUgY29tbWl0IGRlc2NyaXB0aW9uLg0KPiBUaGlzIGhhcyBi
ZWVuIGRpc2N1c3NlZCBtYW55IHRpbWVzIGVsc2V3aGVyZS4gTWFueSBvZiBvdXIgRU5PU1lTIHVz
ZXMgYXJlDQo+IHNpbXBseSB3cm9uZy4gRU5PU1lTIGhhcyB2ZXJ5IGxpbWl0ZWQgYXBwbGljYWJp
bGl0eTogVW5hdmFpbGFiaWxpdHkgb2YgYQ0KPiB0b3AtbGV2ZWwgaHlwZXJjYWxsIChvcmlnaW5h
bGx5OiBzeXNjYWxsKS4NCj4NCj4+IE1heWJlIHdlIHNob3VsZCBhZGQgY29tbWl0IGF1dGhvcj8N
Cj4gWW91IG1pZ2h0LCBidXQgUGF1bCBoYXNuJ3QgYmVlbiBhY3RpdmUgaW4gWGVuIGZvciBxdWl0
ZSBzb21lIHRpbWUgbm93Lg0KPg0KPiBKYW4=


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 07:29:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 07:29:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022058.1397771 (Exim 4.92)
	(envelope-from )
	id 1uTbbw-0000J0-GX; Mon, 23 Jun 2025 07:29:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022058.1397771; Mon, 23 Jun 2025 07: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 1uTbbw-0000It-Cl; Mon, 23 Jun 2025 07:29:00 +0000
Received: by outflank-mailman (input) for mailman id 1022058;
 Mon, 23 Jun 2025 07: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 1uTbbv-0000IR-Rf
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 07:28:59 +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 ba336759-5003-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 09:28:58 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-450cb2ddd46so22030835e9.2
 for ; Mon, 23 Jun 2025 00:28:58 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d866b000sm75748105ad.162.2025.06.23.00.28.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 00:28:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ba336759-5003-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750663738; x=1751268538; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=FKprFUdM6IgTUjz1r6uxx+U1WT7rXdRqVRpmno0Jr3Y=;
        b=Nzg58kop9syWXmQMgxHi+xX3fiyfY0jtt6J3Z++iGnDzMyy8OYhXTTXKoDnOZB8gM9
         WlZ9vI4qkGEDy3pv+rLCksHK9ZHcBYgULkTxPo8djNosp8A4C4wdEoe64lBUuB4hZVni
         UW1VnhRksRZlkQe4Jbro/vSqXIDQD/ZcjAke7fdFCWcHbRf4iHFuW/B34M29yF/7OqP6
         gEELl3MCjrLD6WMF+vlKOfq4EshSCNMo5t9q1eZTDK7QkjUnCF2kD73do34TKW+bVNdJ
         OUI89HqYaORSSEtA2vwBUUjeaS4Xh782y71zvpI5pJP7c/bDEkAY2/v4L2kJXtr+2uRv
         1TQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750663738; x=1751268538;
        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=FKprFUdM6IgTUjz1r6uxx+U1WT7rXdRqVRpmno0Jr3Y=;
        b=n/NleP5+/0YV8AXjAYlBzTMVUByMgakYDOeKIFy6aQy8SXfs6XooZ87YTUnjAqQtDp
         PewpNaUXDOo/bxKC3C1ukJneg2l1nkClHiYVcou4Kb0ssB6dHUEGv6R/Aco698dkQ2qN
         aNAYVtzw9xHjnTojOp7yMSYTZdEVeS+OlD54elimxva3aBHMMKspK44OMYVxWIFAhPEm
         j+IUjqZCrLmKMxBRQaZGUfuTlM/2D56dO8tDrmHD1YE+JEOQ0V4mqtiq/0j6+j7gnJFZ
         gMHFCfRKCGv8muvToYGf9bD6eLHw74qAQOYleT1Iuxkqdptu1eSFDxjGcaiN6mCrfae4
         e4yQ==
X-Gm-Message-State: AOJu0YxSZSaqGmbh9zbr2rbWBWXjRn/JYGKuWlG6uqRfRFaNLCtJmR1Y
	I0hfE2V+dZIJHtgZ6Tu72ewhRhLFS13euMmLJo6IXO43VQGI3lq7iCmcjn8J8SsexQ==
X-Gm-Gg: ASbGncvlwlnLFb/dsZtXeI5i/4IPrSGdel+AZmfNIBL6VVpB1DNI3msJPtrUm/mivaU
	RE/wCUPgEzrGAB9bgyD6KAdTrT5rNQKbihiPmy4tt2iulTjKHUuYv8fAE6+bmXoXd7dLozC9esQ
	CabG+aFP5sNu2GqYuR6M2pLGsNtqxUskGlj+miUu83FPoQ2Vxw4Bp+NDdiGN5iaOum1lnIdbeXC
	Wx1oXouypPXDM1p5ySic2KNW7tZt4SBqWcucursI2bUC5sEuK+BQAucln/6jtAP91yrJgqeTeCw
	ZJ2eRCtskKVEZg4G8y1loM9Z1DYudMdir0f0xgmxrK89EssmecGCGT35k2ru1Y8FepJ/vY/ysL2
	wjL0+8w2gVvBtQ/iM6FKWGxAJhLyj1oFk1GDaZfq57VdCTvk=
X-Google-Smtp-Source: AGHT+IE5jmjLiBDOIwcw9q8r7r0ttaD3T+WkcSIJ7OJEJFFmHqPbbY8gHmI+KtifPXlvoTl6r0Zh/w==
X-Received: by 2002:a05:6000:2004:b0:3a4:f50b:ca2 with SMTP id ffacd0b85a97d-3a6d12fae98mr7976206f8f.8.1750663738269;
        Mon, 23 Jun 2025 00:28:58 -0700 (PDT)
Message-ID: <21e3389a-dfcc-43a6-858f-ea1da4321655@suse.com>
Date: Mon, 23 Jun 2025 09:28:50 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 3/5] crypto: Add RSA support
To: Ross Lagerwall 
Cc: xen-devel@lists.xenproject.org, Andrew Cooper
 , Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20250602133639.2871212-1-ross.lagerwall@citrix.com>
 <20250602133639.2871212-4-ross.lagerwall@citrix.com>
 
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 20.06.2025 18:11, Ross Lagerwall wrote:
> On Fri, Jun 20, 2025 at 10:53 AM Roger Pau Monné  wrote:
>>
>> On Mon, Jun 02, 2025 at 02:36:35PM +0100, Ross Lagerwall wrote:
>>> In preparation for adding support for livepatch signing, add support for
>>> RSA crypto.
>>>
>>> The RSA code is extracted from Nettle at tag nettle_3.2_release_20160128
>>> (https://git.lysator.liu.se/nettle/nettle).
>>>
>>> The MPI code is extracted from Linux at commit eef0df6a5953 (lib/mpi/*).
>>>
>>> Signed-off-by: Ross Lagerwall 
>>> ---
>>>
>>> In v3:
>>>
>>> * Move mpi.c to lib
>>> * Fix header guard name
>>>
>>>  xen/crypto/Makefile   |    1 +
>>>  xen/crypto/rsa.c      |  196 +++++
>>>  xen/include/xen/mpi.h |   68 ++
>>>  xen/include/xen/rsa.h |   74 ++
>>>  xen/lib/Makefile      |    1 +
>>>  xen/lib/mpi.c         | 1729 +++++++++++++++++++++++++++++++++++++++++
>>
>> Just FTAOD: all the functions imported in mpi.c are used I think?  So
>> that we don't introduce unreachable code.
> 
> Yes, everything included here is used by the end of the patch series.

What about intermediate state? It's conceivable that such a series might go
in piecemeal ...

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 07:31:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 07:31:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022074.1397780 (Exim 4.92)
	(envelope-from )
	id 1uTbe8-00027N-T2; Mon, 23 Jun 2025 07:31:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022074.1397780; Mon, 23 Jun 2025 07:31: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 1uTbe8-00027G-QB; Mon, 23 Jun 2025 07:31:16 +0000
Received: by outflank-mailman (input) for mailman id 1022074;
 Mon, 23 Jun 2025 07:31: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 1uTbe7-000279-Dz
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 07:31:15 +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 0a6d2537-5004-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 09:31:13 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a50fc7ac4dso2054825f8f.0
 for ; Mon, 23 Jun 2025 00:31:13 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d87294adsm75540245ad.237.2025.06.23.00.31.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 00:31:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0a6d2537-5004-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750663873; x=1751268673; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=DBVR7jFGMlN2CBKgSQucJ5PrkC2gFAITtdVWqnTBVlQ=;
        b=EDPiRGsdzrkfikE/KWkV682Iy/dtcpqXyyPzzqUcWS/9EMqoGIYiR24EAXBMvPZtjs
         aNoDU7SAyQAQtbQjMs6aec6aw2puNNo57Rkf5G1+OTnVyw/CH0h1XJTf5mLem4/IbXlq
         Q+h1gwHljIAlGk29OQPUunhToYMVm1klN4e8t0V4XdpNMlA+ONKvaGXA/EKQRqOKFyqX
         wp2+gGLtLlF2OSLPKT+QeWGnuZ9Wpr/8yuND+dZPvmsxEoLCEOTs3cuM2RK4knSGuKGu
         jZnilcODjxOUp7CCPP/vrJI/qpxoYmm3z5qihO0k9yH1Hm9mY2JrcK62gXUAP+U6j0MH
         HkHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750663873; x=1751268673;
        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=DBVR7jFGMlN2CBKgSQucJ5PrkC2gFAITtdVWqnTBVlQ=;
        b=RO6/pRXNfBgnHiczzhSHKrxJMGXQfctV4220kmmzNh3lINugTJc3yp0Xgrd5GrPj/V
         tqbce+UAEy16KhKX2Cq4R1+foghw+S4Nvi59MGJgC1oTMmS/jA0hoSTh5oa2U+LZU1ab
         GRasdbgN2qNY7kQMLVCr9opoSI7MjAsyTXgp1TlqUOPrtLeN3hHoIz0clLKoUStidIx/
         tql6sFJjYnBd2Kd1oMZtPcoXvphqbReb1Jf/Wa9X9JsDGLOq37otejkfE6LZQuzkIsUp
         LBmdIYE4U27nLzjf/JoO7l8Tj7ib8JUadp2VVicneD5Ua8cbzl7dT0tJtSbhHJullpwY
         O9kA==
X-Forwarded-Encrypted: i=1; AJvYcCWezh8/a9EykXePXbh6p+TSLOjKvfdJ2GCxDZJGvHR9ea3dFXxvvg3bTZ5f6Eo8pCB2cmcszFd2QoA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyYcKulc8+dtYRodxqwXQLxrMkTEi5FSQW7NkJPak+UsK2QJoV4
	lwtz4uu/AfnfGPJud7YdThPOSmkTpkL1qrinmwcsT2E9IP31KiA8v/uAkzsBp0JsUw==
X-Gm-Gg: ASbGncu8zCI0dY+jP/Z6ALiN7YVHuyItNt3hgvSkAdz1Gi8e9m34smy38ilsJlgFeqj
	LxNBN3BeP5xDOUVuzUsMf2D//5FotHGJZ6YNawWtZN83YPNVDbhSMl3yoTQpDalnpgmiUmDvYba
	Cy0kM2SFA4KoxvAkx9P3mzVOyH79i7cqMDivzyGbYBbi/+gvzqPaJ/kyr9TwwAT+7LpLMxksG3Q
	HybReacIL6bleanSAs1lm2jn82KYUtQe0SnjtGpPmo7Ua/7AFvivSZMlEuY/oQ52uGToCHwWOcb
	9qK+C6+8Wy2shmYpmIynls2bnosHs8OEwjuvt2gpHRJeGKD2dYgovougpbAJAuidKEuE5S4wNBZ
	BCxXEYtx/ZRsQdqgD4mm/Wc3QZNlhDrJRB/g5SiU4lNI/aos=
X-Google-Smtp-Source: AGHT+IHKwBaPQM48DfcKm24ZJOpVp28PCZMUNkbxZ0FFrlMreIORvW2s6E08Y/3p5DNGmJsQoj4xXQ==
X-Received: by 2002:a05:6000:25f8:b0:3a5:52cc:346e with SMTP id ffacd0b85a97d-3a6d12fb46emr8304537f8f.6.1750663872938;
        Mon, 23 Jun 2025 00:31:12 -0700 (PDT)
Message-ID: 
Date: Mon, 23 Jun 2025 09:31:05 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 01/12] CODING_STYLE: Custom type names must be
 snake-cased by word.
To: Alejandro Vallejo 
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: <20250620182859.23378-1-agarciav@amd.com>
 <20250620182859.23378-2-agarciav@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: <20250620182859.23378-2-agarciav@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 20.06.2025 20:28, Alejandro Vallejo wrote:
> There's the unwritten convention in x86 of splitting type names using
> underscores. Add such convention to the CODINNG_STYLE to make it
> common and less unwritten.

Just curious: How does x86 come into play here? Xen inherited this un-
written rule from Linux, afaict.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 07:40:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 07:40:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022080.1397791 (Exim 4.92)
	(envelope-from )
	id 1uTbmm-0003os-OA; Mon, 23 Jun 2025 07:40:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022080.1397791; Mon, 23 Jun 2025 07: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 1uTbmm-0003ol-Kw; Mon, 23 Jun 2025 07:40:12 +0000
Received: by outflank-mailman (input) for mailman id 1022080;
 Mon, 23 Jun 2025 07: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 1uTbml-0003of-D0
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 07:40:11 +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 47f864a1-5005-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 09:40:06 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-450cfb790f7so27618735e9.0
 for ; Mon, 23 Jun 2025 00:40:06 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d8640c61sm78285515ad.141.2025.06.23.00.39.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 00:40:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 47f864a1-5005-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750664406; x=1751269206; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=iYDGgVU5TbBCRp/ft5iGMCvr6kD9RNtfXSBetMQZjK4=;
        b=V4GCPa1flyDcAi46Z7Q3DyfUkS2qCh3gyfFM8QTgoCZBaoIrmM4BapCnlztHJCys1O
         98qBcX4DMTNyvazILHYIzni/zMqC9NZoDgf3df48v2jhnGE7RDfcKjtxS4NNZGeQN6Y9
         /wJ37EPyiC/9v59KVICty93ZW/Divfmxo+YFlg9vQoJzsjB+MHivmCTIsY2sOJbXXwFw
         BbACVLp5GbUfmb5/sZQ2F+h0rNA8WuXPn4eG7E9k83m9peNq333o3Mh69q3OWSWRlYx/
         qGIEM8GrfGRYMagggoAgRts0PDtOlN6TMCc9uN1g6eRPd5VI27OKq53J0k6uvPxfWwFG
         +Leg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750664406; x=1751269206;
        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=iYDGgVU5TbBCRp/ft5iGMCvr6kD9RNtfXSBetMQZjK4=;
        b=LvH2AC7J8VKb9aFKg4kzER6alVpmxJMMvJETVh6sA7sVtqwlSO2s2oNDPwq+80p5Of
         GxW8C53K0UlzxYCSMZxO0T/apg6XfgkqTEWZxDAMMBA5mxWW28rORnnhYsMSHTiGCfIv
         4kqPz8eexygoYCp+Dc9zX3ebGTEY+LcvMzfsBGhtwIz06M2r/HXESz5OUbIkuNO1tBDV
         lcDFhbR6DJcEAaGfY1n/ZB1UhIDnmtPb0fsgNLeEsdFWEvzZq0owOfjBdTqUn4lUnCN1
         dVlfHNzHTEf1x67/AkDnXKXiQ9pKkwszhTUX+7/8zmxDRe03cMaKCFpKNAJWXuudFvl5
         6g6g==
X-Forwarded-Encrypted: i=1; AJvYcCXvChbnTog88CgVaMM1y8LeTET35ZeuqRMb9azZ7gz8vqr0qA1FBSLhHLbTPkWgh9ryZKJp7sE7oPU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyiGzWNir7Gg3b3w1dGiR6CDPI7AmS4BDeEhdJGkqosQbWl55yv
	VYzjRoVm0/Fm+brxDJaep5PY0rkF2RFpm5YOaZmszozmJBaQrtQjjIkiel69eU1tVA==
X-Gm-Gg: ASbGncuOnslyX5SRHH/RjgWq3xZYtCt7TYwlSPIbw1qQ9dyKaITuwPkPw+pNYG2yq7C
	OBq81uDUZVuuqQsjEL8dIfQiRIEZY9nkz718Va4F50RZ3aYiVNaYHs7HLn5Vq4cISJlkmbimUyz
	j3Hh8wXCrcHDQY1XEixe5S6TG8JsgwaQ2z3b3sAWoLQl+PSxZhuhCMEBjfWoUSE+j4+vnqoLdGk
	gRcSDiaVhlAxf9qvsGBOo88egFKwyoS8Ioz3CJFZIOoS6d4FkgaClJP8OS7G+kj8B3v7bSODy1f
	+CluMnRfsD08QKiW/bB+xkf4913xv//VdEeIPVPcYyBThpGrDuuKO5XEqFKfTUupk+5s1hazKVz
	4bLxka3ffoUDleIXK64Le8iJ87cdU2L/+zXWrWuNptui7lv8=
X-Google-Smtp-Source: AGHT+IEFHB7ALrnPs1u381bLELz6gKDA5/XQ1iZfQ6vXAUoAWpkElxowF6ubDRjaepSRZlEr5tj5sQ==
X-Received: by 2002:a05:6000:2504:b0:3a4:f9e7:2796 with SMTP id ffacd0b85a97d-3a6d12fb64emr10832193f8f.35.1750664405563;
        Mon, 23 Jun 2025 00:40:05 -0700 (PDT)
Message-ID: <490ee7bf-cb10-43e3-9416-9a68e7529b96@suse.com>
Date: Mon, 23 Jun 2025 09:39:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 10/12] xen: Rename CONFIG_HAS_DEVICE_TREE to
 CONFIG_HAS_DEVICE_TREE_DISCOVERY
To: Alejandro Vallejo 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk ,
 Shawn Anastasio ,
 Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Oleksii Kurochko ,
 "Daniel P. Smith" ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , Dario Faggioli ,
 Juergen Gross , George Dunlap ,
 xen-devel@lists.xenproject.org
References: <20250620182859.23378-1-agarciav@amd.com>
 <20250620182859.23378-11-agarciav@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: <20250620182859.23378-11-agarciav@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 20.06.2025 20:28, Alejandro Vallejo wrote:
> Moving forward the idea is for there to be:
>   1. Basic DT support: used by dom0less/hyperlaunch.
>   2. Full DT support: used for device discovery and HW setup.
> 
> Rename HAS_DEVICE_TREE to HAS_DEVICE_TREE_DISCOVERY to describe (2), while
> DOM0LESS_BOOT is left to describe (1).

Considering hyperlaunch this feels wrong to me. Did you consider splitting
HAS_DEVICE_TREE into HAS_DEVICE_TREE_PARSE and HAS_DEVICE_TREE_DISCOVERY,
as I suggested on the committers call? You weren't there, but Stefano said
he was taking notes.

> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -14,7 +14,7 @@ config CORE_PARKING
>  
>  config DOM0LESS_BOOT
>  	bool "Dom0less boot support" if EXPERT
> -	depends on HAS_DOM0LESS && HAS_DEVICE_TREE && DOMAIN_BUILD_HELPERS
> +	depends on HAS_DOM0LESS && HAS_DEVICE_TREE_DISCOVERY && DOMAIN_BUILD_HELPERS
>  	default y
>  	help
>  	  Dom0less boot support enables Xen to create and start domU guests during
> @@ -85,7 +85,7 @@ config HAS_ALTERNATIVE
>  config HAS_COMPAT
>  	bool
>  
> -config HAS_DEVICE_TREE
> +config HAS_DEVICE_TREE_DISCOVERY
>  	bool
>  	select LIBFDT

This select imo ought to move to HAS_DEVICE_TREE_PARSE, unless I misunderstand
what LIBFDT covers.

> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -6,9 +6,9 @@ obj-$(CONFIG_HYPFS_CONFIG) += config_data.o
>  obj-$(CONFIG_CORE_PARKING) += core_parking.o
>  obj-y += cpu.o
>  obj-$(CONFIG_DEBUG_TRACE) += debugtrace.o
> -obj-$(CONFIG_HAS_DEVICE_TREE) += device.o
> +obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += device.o
>  obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) += device.o
> -obj-$(CONFIG_HAS_DEVICE_TREE) += device-tree/
> +obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += device-tree/

Here I'm less certain - is everything in that subdir truly "discovery" related?

> --- a/xen/common/sched/Kconfig
> +++ b/xen/common/sched/Kconfig
> @@ -67,7 +67,7 @@ endmenu
>  
>  config BOOT_TIME_CPUPOOLS
>  	bool "Create cpupools at boot time"
> -	depends on HAS_DEVICE_TREE
> +	depends on HAS_DEVICE_TREE_DISCOVERY
>  	help
>  	  Creates cpupools during boot time and assigns cpus to them. Cpupools
>  	  options can be specified in the device tree.

This similarly looks wrong to me. Whether to create CPU pools is purely a
Xen-internal software thing, isn't it?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 07:41:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 07:41:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022087.1397801 (Exim 4.92)
	(envelope-from )
	id 1uTboP-0004Zk-2M; Mon, 23 Jun 2025 07:41:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022087.1397801; Mon, 23 Jun 2025 07: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 1uTboO-0004Zd-VN; Mon, 23 Jun 2025 07:41:52 +0000
Received: by outflank-mailman (input) for mailman id 1022087;
 Mon, 23 Jun 2025 07:41: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 1uTboN-0004ZV-Ku
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 07:41:51 +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 85961fc6-5005-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 09:41:49 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a51481a598so1959365f8f.3
 for ; Mon, 23 Jun 2025 00:41:49 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d83ce31asm75397495ad.63.2025.06.23.00.41.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 00:41:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 85961fc6-5005-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750664509; x=1751269309; 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=XMdWL9Tv7PcuHNqz3JjNNm8rkUET8PY00BOKBsqoT8k=;
        b=fVCstzFEemoCwyF79byaUTsr5pBcgxc1ugtSLrovrFC65Tq2bWFaYLPiMG3rhB+jaH
         07O4C5mC8PxmELVSfkkMxaZ7TlId5ifkltTiP0T8NHCLBlhnBUud3Y19teViDSAuH143
         qTgwwoMsaWZ/R3NCjMQ7HQztiwaTEuQddsgj9fIl8obtbEdAYaoJH3cIyhCTjFnshvJx
         Cp422t8CaYOb2IZAGRq9qLuvf/BM1TLZbljx0D1XxRcRevjxA3xw1NjvsRqs/YFr7yj2
         Yq56hfSL/U3IQ2Q9F86X2QA0ZATeER9KRWhggeDUR/jLJoS/piXz8IIFmgFTgehGrhcs
         f2Rw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750664509; x=1751269309;
        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=XMdWL9Tv7PcuHNqz3JjNNm8rkUET8PY00BOKBsqoT8k=;
        b=OJ86rjwvJLsm7UD2Js4dOt8z8Q5C8A1Kh7vjhW/23TN1z1jGX9nLqI/nw+ChNzuYsI
         3K8NeVEqX2mb1O4yEmOquhjNgTlj2K0Y+VM3AA0geDTiSeoJRHKpK9RIFm8QO8jdWetR
         tUDiEgBrihjGhdugCHv4vkmX+GbvjqCBEmfL0E7zulCjxxVedm7F9gKs3ppfi8YuZM/w
         uTPdlxpT5EUEId13GC3HO/ytOpUtakl7FzYv9kQX0L8BIuDLiypbbEArbgC8C5WnBpga
         wPMvU3XGa9jPTVlP5oicPnIyPDWB/nCR2mJYHyLVixA25Pe+AIn0QRc5uPwC9CBW+7Cb
         suEw==
X-Forwarded-Encrypted: i=1; AJvYcCUaFq5qVSn1nDLKmPWVFR35oBNZpoMg4qP8jXAKPH3SM/OKQcEKIoR6eDTCGFL0WNY5rhmE3t4AJME=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx1SEI9Egl6bOe+8LghGGcRReXSOa4nkOLbraqBXwhp04GLVBly
	Y2fudBrp6zvjFUnc3QwsbLnJJ00s+MOsUZlM4/+x5uP0x9xgRmb6NSBmzhudi9oB7Q==
X-Gm-Gg: ASbGncu0ufU4DQlfOa1h2K8AtUhLW4Wpx8ShXJqsD7M/GYqT4409c3sMt/09B5/DUSV
	FH4rPN5ACJILSZ/SsYy6aSTtoVckbUJD9oQtTbP+Kqr8h1XOqxtwt82DrUC5WC2gisjpnF8ueSq
	nxJPxb9BzLMwP8cmakJK0yaL0099aEKzq6+tKeekF4NUPLFEmy860X+rj1LygjjVmSfzAE7j6Pu
	qiZUTY+5CSSVnHh4rmb3qTDkRBbtt+a8rjknzm6LKIvGbBzSwu7bvfMiloo6SLsoSk5dOCbhxvq
	Db7T0DRLKZ1JgpGieEoVpPlfzL8zzivgfzHi45udmPeW1cXLABEI1uxdH2vAh3AyetnguY1OBkJ
	RQN/AcaaXwkyclTp5YKf94Jv9C0xOO78agB92BfxhE9uPPDA=
X-Google-Smtp-Source: AGHT+IHKDFHSBai0nQOILkTNK0wT8hZPlceFu4La8gFOdigynT63tBXGi3leavrt1tZMikW6RjBHPg==
X-Received: by 2002:a05:6000:2890:b0:3a4:d4e5:498a with SMTP id ffacd0b85a97d-3a6d130d49cmr9387770f8f.42.1750664509017;
        Mon, 23 Jun 2025 00:41:49 -0700 (PDT)
Message-ID: <9c3803ff-0ae4-40fd-8bc5-aa4bab4d5264@suse.com>
Date: Mon, 23 Jun 2025 09:41:35 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 10/12] xen: Rename CONFIG_HAS_DEVICE_TREE to
 CONFIG_HAS_DEVICE_TREE_DISCOVERY
From: Jan Beulich 
To: Alejandro Vallejo 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk ,
 Shawn Anastasio ,
 Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Oleksii Kurochko ,
 "Daniel P. Smith" ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , Dario Faggioli ,
 Juergen Gross , George Dunlap ,
 xen-devel@lists.xenproject.org
References: <20250620182859.23378-1-agarciav@amd.com>
 <20250620182859.23378-11-agarciav@amd.com>
 <490ee7bf-cb10-43e3-9416-9a68e7529b96@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: <490ee7bf-cb10-43e3-9416-9a68e7529b96@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 23.06.2025 09:39, Jan Beulich wrote:
> On 20.06.2025 20:28, Alejandro Vallejo wrote:
>> Moving forward the idea is for there to be:
>>   1. Basic DT support: used by dom0less/hyperlaunch.
>>   2. Full DT support: used for device discovery and HW setup.
>>
>> Rename HAS_DEVICE_TREE to HAS_DEVICE_TREE_DISCOVERY to describe (2), while
>> DOM0LESS_BOOT is left to describe (1).
> 
> Considering hyperlaunch this feels wrong to me. Did you consider splitting
> HAS_DEVICE_TREE into HAS_DEVICE_TREE_PARSE and HAS_DEVICE_TREE_DISCOVERY,
> as I suggested on the committers call? You weren't there, but Stefano said
> he was taking notes.

Oh, ftaod: I wouldn't insist on the _PARSING suffix. Having HAS_DEVICE_TREE
and HAS_DEVICE_TREE_DISCOVERY (with the latter selecting the former) would
be equally fine with me.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 07:44:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 07:44:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022098.1397811 (Exim 4.92)
	(envelope-from )
	id 1uTbrJ-0005CM-Ic; Mon, 23 Jun 2025 07:44:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022098.1397811; Mon, 23 Jun 2025 07:44: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 1uTbrJ-0005CF-Fd; Mon, 23 Jun 2025 07:44:53 +0000
Received: by outflank-mailman (input) for mailman id 1022098;
 Mon, 23 Jun 2025 07:44: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 1uTbrI-0005C9-UM
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 07:44:52 +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 ed82e2e4-5005-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 09:44:44 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a365a6804eso2040844f8f.3
 for ; Mon, 23 Jun 2025 00:44:43 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d8673d1asm77030375ad.172.2025.06.23.00.44.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 00:44:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ed82e2e4-5005-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750664683; x=1751269483; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=1Pc10lhOrmmJANx4DJ1lM5+pLLzbiArb9KyfJUHnyJI=;
        b=Y1jV+oVTlH5iNaA8jXFpSHAPNDeK14KEH86xe1DtkbLYsZ51SZ9uvzdAjMEItXwBIH
         dAnbkvGrBDyOSWqNn2eS3aHEyJXs05og+a1h0i8elw6bjhIChV8H1pufoeZYLD/9Sslx
         wddTQ2AC8us740Ouqlwt6obD4jL6O5rHnKU83txE/yGtSAeh0/3HFMscMTJYuhYfuse3
         oq/IpEbLBc/w0khdoVbG6MnjyjYwJqNZoZZPkTYk/ac3+WaGdUoNVyXVifN1WkLPzDGg
         q8w8e6/MCRjTkZBWraKVf9tK6ufNdfJIJA1CRm98y2loXD00U/Ss1Rva27ptVT50wvaI
         tHLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750664683; x=1751269483;
        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=1Pc10lhOrmmJANx4DJ1lM5+pLLzbiArb9KyfJUHnyJI=;
        b=mJ5yZsbX/BShxAVSWKLp2x8M8zL9V9tt+9WUd+LXPVqj0rK9IWEYfD1eQpW86vU3KO
         MM7YHGMQn3X1JA2wvxG1aFGJVEP3znIlJhHjpK5CX8N3SoaIJoB1GkJXUb7G9MX8cXZT
         O/zYt2N6KPzN5lRAvPGufik9/vHYHYBYa2nByllpWetJHyhFqSRzX/GgYXFIggZOmdmd
         nVQm32uqE0CfEx9z7mCyRES9BIIsq5zPhChClC6Nb5D5LuP0COqxONVtxlnkxw7Hr7fC
         EjtNr8vW1NuelaXNptVcOV2Y3fvLrXJA/6s072g2maJ5wyrkzi/bciAFKADF9i9EWTnA
         YPlg==
X-Forwarded-Encrypted: i=1; AJvYcCXHtFk2QegPuG1msHPe4h8R2e/buUocx7n5GolG0YmpdTv/CA0FgXj2QlimkuZRXnnFsfutbgzfMMI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwUuKh8Mxow0dPFVmvgCqaaXewy005buVVDMOuwBRokc/bRUTmq
	yWELbLZ5+Qy7JpBO7ZOSWVLn50ITJ4seHIorqo7+fBzoSler3Akh3A1Zja5K/AQbpQ==
X-Gm-Gg: ASbGncsLAQWMrERMv64jiJxu4uT3/WC7VxOY/GnFDXwReQnwhmxXl8zRhnJVpV0h2ki
	23k1S1KiWW/FeIN1EmLAwXLtu5Na1T7RHbW8aeKzVoWt1YF5SJKkTpMnhZaaycts41nXRDOkGXy
	k+eXrf8JCcqpxiESteBdl/cr0XpP3L+FBev0WCZmhvsQumpvHO0962cH77NKiIYx/ejPh205pX1
	+fk3Q4IXwQzhCXk3uNh0AFzr2qcI5kLINwzXpVEXqwFTLLWNF1OiFXsKzp3z4Qi2mugQ2xcvLbA
	L/fJ+wtfvUfriAtLZ3CG8l/OyEOxoAHhqeqKDwtq1Y+eXiwdfVlB6B3ljqWJq0za7706qC+QNoY
	V0fDrK3rUiO2qXXRBTiFyYYJltm/G+x+h9g5+kwm713IaTig=
X-Google-Smtp-Source: AGHT+IGRMvaZ7IQgV0B9zgCHnTqCKyFse5ZmlU7i2T/yx8vqY31nI9oGd034icazSRu3QSh27cYr6A==
X-Received: by 2002:a05:6000:645:b0:3a5:2cf3:d6af with SMTP id ffacd0b85a97d-3a6d1329be4mr8799083f8f.45.1750664683441;
        Mon, 23 Jun 2025 00:44:43 -0700 (PDT)
Message-ID: 
Date: Mon, 23 Jun 2025 09:44:36 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 11/12] xen/dt: ifdef out DEV_DT-related bits from
 device_tree.{c,h}
To: Alejandro Vallejo 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel , xen-devel@lists.xenproject.org
References: <20250620182859.23378-1-agarciav@amd.com>
 <20250620182859.23378-12-agarciav@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: <20250620182859.23378-12-agarciav@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 20.06.2025 20:28, Alejandro Vallejo wrote:
> device-tree.c stops requiring CONFIG_HAS_DEVICE_TREE_DISCOVERY and may
> function with DOM0LESS_BOOT.
> 
> Without this, there's a clash with x86's definition of device_t. Because
> x86 doesn't discover devices in the DT it can simply skip the code
> to do so during the unflattening phase.
> 
> Not a functional change on architectures that currently use these files,
> as they already select CONFIG_HAS_DEVICE_TREE_DISCOVERY.
> 
> Signed-off-by: Alejandro Vallejo 
> ---
>  xen/common/device-tree/device-tree.c | 2 ++
>  xen/include/xen/device_tree.h        | 4 ++++
>  2 files changed, 6 insertions(+)
> 
> diff --git a/xen/common/device-tree/device-tree.c b/xen/common/device-tree/device-tree.c
> index 725ff71646..741e2ce585 100644
> --- a/xen/common/device-tree/device-tree.c
> +++ b/xen/common/device-tree/device-tree.c
> @@ -2029,9 +2029,11 @@ static unsigned long unflatten_dt_node(const void *fdt,
>              ((char *)pp->value)[sz - 1] = 0;
>              dt_dprintk("fixed up name for %s -> %s\n", pathp,
>                         (char *)pp->value);
> +#ifdef CONFIG_HAS_DEVICE_TREE_DISCOVERY
>              /* Generic device initialization */
>              np->dev.type = DEV_DT;
>              np->dev.of_node = np;
> +#endif /* CONFIG_HAS_DEVICE_TREE_DISCOVERY */
>          }
>      }

Without something said to that effect in the description, this contradicts

obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += device-tree/

that the previous patch put in place, and that only the subsequent patch
will further change.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 07:51:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 07:51:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022106.1397821 (Exim 4.92)
	(envelope-from )
	id 1uTbxR-0006uL-73; Mon, 23 Jun 2025 07:51:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022106.1397821; Mon, 23 Jun 2025 07: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 1uTbxR-0006uE-3s; Mon, 23 Jun 2025 07:51:13 +0000
Received: by outflank-mailman (input) for mailman id 1022106;
 Mon, 23 Jun 2025 07: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 1uTbxP-0006u8-Vg
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 07:51:11 +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 d4274aa4-5006-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 09:51:10 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3a525eee2e3so2294023f8f.2
 for ; Mon, 23 Jun 2025 00:51:10 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b31f12427b7sm6135694a12.40.2025.06.23.00.51.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 00:51:09 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d4274aa4-5006-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750665070; x=1751269870; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=XZHgxBpXcEMvVWNTABkZuLYDSb3cu+uGVt7hzEMxwUs=;
        b=Vll0KrIKknplmvDCY7Fn2FVV1cYMdOkDZJxy2vySHgrCc5DUDy550GOe1p0aN3quYr
         rnYeXISy6TE6kb+7xTGVQi2aR/GEMKQ25g4NJemfwnHecjq/Im/1HtMrN8hMjw4t0ajc
         16avx5SVGNiOaWrTEO+jAdfcNgkd8OVbomcoemaIjn7Ntvhlc2iwEeRCAI4osd9sUE6g
         gzSq0YQ+ZB1ZtcQVw4D2K10FFwZjBxPuIgQwhEFeVmUycaIauKVzj8qUcoqp+X66vc23
         0Sr6iJehUSkBCOmY8VhhdtAvoOAAxmknk/oDDtGciMrLoT+CEmVKsp3Y/wnHuMHPFZyP
         L4zA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750665070; x=1751269870;
        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=XZHgxBpXcEMvVWNTABkZuLYDSb3cu+uGVt7hzEMxwUs=;
        b=Blet5nmCdDjDHztt4PnGuucZvyD8KUCac5mk0FqEAr9xVbm6Mt2zgCXqtHCM+ULzzO
         1J/hHJFmnJ0/59dJkoay0U5RQ3PSVa+9afDyhheUBUjS/BNgTwGsd7wSBr5eNws3YmjZ
         /ZwatkruEcNc//kFEYvbeT0FGc3M/g8a72m8oVWsDD/s38gRJB5s7M0Z9+Eb5eyez4u2
         T/zOHDl19pS3OEQGBcws+yP/z7gPIWhbE2Yro9/jy3skjs1HK+akzr+UXX0v3m0a9Pqt
         Kgnaa/S18bL3zItjFY8+4Aw8aGNyh2guCGjCx7sGDR+H9yl0VIt0aQEig2g6AewO9XZN
         F1Dg==
X-Forwarded-Encrypted: i=1; AJvYcCUXQFt8lE6YGxCGnSJ9UvlMY8DosIe36zZ5qvSmK2q8ng884j+yiI3NMKNSQlt4gJkxQLCBY+9h2/c=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzXTN+UnYFQYxF/JvKTADaVa8KbNZs0oWB/5x+1nUGWD8/j2G+o
	eNIT++CYjhYvee5yHxjC4SQmUqJGL7n93yB2z1IiXiI6renOA+c6UWYVKTckrjFrrw==
X-Gm-Gg: ASbGncvaMMNmS9YB7RkpqLWYAopp3NMRhu57lDCX9MeoAA2kLPXsy93fpuLsN7f1wpa
	/ccDd/81rm3cq9AByTc/BwMlcfQ2Hg7EdYH2TboHAUzimWmUTS1zECpwcJt8Pnyk9L2K0EKUGEX
	0/0u1RPstOqTR8CXKlBOrTGeZDf9QiuePlRI1gG6nsp8kWwv0u0wayxwP3WLWWOepPxvhgbi1Gs
	QSwSAHS2s4ZwDg1Vo3HcQ5CjTvdjvcoUuaDgHBa1XR3ITNsW7juDZrQzjEG2//elL+UcbzcYLej
	+7LN2cgBF6qesS3oO9CUgw2UL0Ho9CnLl5iAyd14tcJGazf1Lyf1m7FsznlLiuD5l5UtSxTBAf5
	ZS89Jtdu7BNdtWj2t0umjj1pnXFEpq8kl7TDPHAWKjHtJsnk=
X-Google-Smtp-Source: AGHT+IGUoTC5etA49PQl/efxrUmJsHjWn6kFCyERT1AKGQldkEL3aQH+SSXWKrQ02NvuEjwijtc+7w==
X-Received: by 2002:a05:6000:387:b0:3a5:2848:2e78 with SMTP id ffacd0b85a97d-3a6d12d90cbmr10202286f8f.28.1750665070285;
        Mon, 23 Jun 2025 00:51:10 -0700 (PDT)
Message-ID: <45b33975-be79-40eb-a860-ca3eb71443b0@suse.com>
Date: Mon, 23 Jun 2025 09:51:01 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH] xen: fix header guard generation for asm-generic
 headers
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 ,
 Anthony PERARD , Julien Grall ,
 =?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 21.06.2025 11:58, Nicola Vetrini wrote:
> Dashes were wrongly not translated into underscores, thus generating
> an unexpected guard identifier.
> 
> Fixes: ee79f378311b ("xen: add header guards to generated asm generic headers")
> Signed-off-by: Nicola Vetrini 
> ---
>  xen/scripts/Makefile.asm-generic | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/scripts/Makefile.asm-generic b/xen/scripts/Makefile.asm-generic
> index b0828018080d..f6850758c54b 100644
> --- a/xen/scripts/Makefile.asm-generic
> +++ b/xen/scripts/Makefile.asm-generic
> @@ -34,7 +34,7 @@ unwanted    := $(filter-out $(generic-y) $(generated-y),$(old-headers))
>  quiet_cmd_wrap = WRAP    $@
>        cmd_wrap = \
>  	arch=$$(echo $@ | sed -n 's:.*arch/\([^/]*\)/.*:\1:p' | tr a-z A-Z); \
> -	upper=$$(echo $*.h | tr a-z A-Z | tr '/.' '__'); \
> +	upper=$$(echo $*.h | tr a-z A-Z | tr '/.-' '__'); \

Aiui the other argument also needs to change, to '___'. While some tr implementations
may cope, the spec is quite clear:

"When the -d option is not specified:

    Each input character found in the array specified by string1 shall be replaced by the character in the same relative position in the array specified by string2. When the array specified by string2 is shorter that the one specified by string1, the results are unspecified."

Easy enough to adjust while committing, I suppose.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 07:55:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 07:55:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022114.1397831 (Exim 4.92)
	(envelope-from )
	id 1uTc1x-0007aF-Nf; Mon, 23 Jun 2025 07:55:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022114.1397831; Mon, 23 Jun 2025 07:55: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 1uTc1x-0007a8-Kc; Mon, 23 Jun 2025 07:55:53 +0000
Received: by outflank-mailman (input) for mailman id 1022114;
 Mon, 23 Jun 2025 07:55: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 1uTc1w-0007a2-H3
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 07:55:52 +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 7b7ae3c6-5007-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 09:55:51 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3a6cd1a6fecso3318164f8f.3
 for ; Mon, 23 Jun 2025 00:55:51 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b31f126c50asm6172381a12.78.2025.06.23.00.55.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 00:55:50 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7b7ae3c6-5007-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750665351; x=1751270151; 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=shnXoTgJcSWO/SHvv//18LlP9kpBfxHM1Pisu9ULKK4=;
        b=Qjl/hqktL/MAUBdYeMC9cDqb6Kx28GgeFxZHk748642eJO8fLwbJBjxNGByTTmYWme
         E0dG4Y/4H/bB6eivDhXKznZEzFPRHUK3yra8VJWpEDgmeIyZ5JprL8dG+hfGOB31kzMn
         k6j3+K8jEkPZb7D7ag5sHdGG/nqm68kw0GnSP+FIIWAowUFvcArRko8XbU5ebgJO5bll
         Ac/MBmco8KE2lppG3FF4v6vtoqt/mTAo2UgAm4FUOlZfa2HOSYMCQ9IYMI/qjNbA9g9r
         2R7Mo5rGMeGdG8UjMCpLF5BPHQrcUxCyEBhtkVP1OtkuoSSPSgryvNN6bRa+cw0zF65N
         kVpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750665351; x=1751270151;
        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=shnXoTgJcSWO/SHvv//18LlP9kpBfxHM1Pisu9ULKK4=;
        b=vIRjB9WDr0vIOXYakjv5ZvBgZUvZW3uxMgjn/Ui6/3ON539stv347ydAdShwrSVDfM
         p9VPEUmqFQSnKbRmWBtat/o1oE58GTiHODTBXTOABM7Csjo5M1E6U/WhuowDfWY8Q//L
         a8/P2uMldqgdGjdbXY45pYCZ0Z4+yvl6wJRxx1XY8TdDw5oZEILwP5HiRjsuaT1lYWU/
         eUdFFXx67fWFVl2Nz7NYaMnvzZ32AER16PZ4ynPVRwDp3UxN4odFPzeYPOpV4Ya+HSTi
         niVlmSAIFiTCXXvi/HcKjOLsrCZA0dQLx8/jXDzLJRgLlAZUp9cXW0mUJl33BMJVbqCu
         aNEw==
X-Gm-Message-State: AOJu0YwnRSodizH70vDJpRWDufcP198Sd6Wb/wXDQkVEuQ7UgbLPoHTy
	O0GpChvKPQnhfQQZuoU43HV05jBlN2QSA9SkSO0w1H0ge9hJm9+6jfRB10v5m6Ya7F8c4mQT//q
	LMXE=
X-Gm-Gg: ASbGncuofqZ4JmYaIW9mORKBheTALckn6+ADW5s8bJn4YXxMyCTwomXPNotuNl2fNZY
	aS+SQ4/S7Fk9Mw7NeJ036cENvs054SnD8b5O/k42nYn3uF1o9sRvqz3BD4Ov+sDl7oV9v6mAPyp
	1QFFxcRuoTYAUN1nimj0JRPTJKgxdWNK7fqJzT+/edScPG618gnultnb8eHnISQ/CbWuDF2D6+O
	Ez7h/iYyyRYpNitkVbstA8X5ljghhusZerRiniS7oqGIEFmvrW/Lueoue0i4awR4Lpfe5cmmT4I
	4WmN3aR1mmMVzBW7IYEp2B7H3+i66QEzBUHrlFFsLPjvHTAzwb9bDDMW4nr63Yyiv05WcK3T0sg
	5frwt0VCg4WIxE0MEefHLsXDHQ52QyrsgyHT6IJV5t9YEsK4=
X-Google-Smtp-Source: AGHT+IFeahiijg1SzPOtbaEhjPkLimTBa579c/GDJ5SGg5kZrdWNo/8bFtRev5ockOPI5l4FTbWRLQ==
X-Received: by 2002:adf:e182:0:b0:3a4:f50a:bd5f with SMTP id ffacd0b85a97d-3a6d12fc18bmr9275637f8f.31.1750665351024;
        Mon, 23 Jun 2025 00:55:51 -0700 (PDT)
Message-ID: <0d1cdd47-8fc2-4aa4-8c78-32f2ef2cc524@suse.com>
Date: Mon, 23 Jun 2025 09:55:46 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: xen_pciback: error enabling MSI-X / MSI for guest -- WAS: Re:
 Kernel panic when passing through 2 identical PCI devices
To: "J. Roeleveld" 
References: <2226691.irdbgypaU6@persephone> <4683544.LvFx2qVVIh@persephone>
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: <4683544.LvFx2qVVIh@persephone>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.06.2025 16:39, J. Roeleveld wrote:
> I managed to get past the kernel panic (sort of) by doing the following:
> 
> 1) Ensure system is fully OFF before booting. A reset/reboot will cause these 
> errors.
> 
> 2) Fix the BIOS config to ensure the PCI-ports are split correctly. If anyone 
> has a Supermicro board and gets errors about PCI-slots not getting full speed 
> let me know.
> 
> Not entirely convinced the 2nd was part of the cause, but that's ok.
> 
> I now, however, get a new error message in the Domain0 dmesg:
> pciback : xen_map irq failed -28 for  domain
> pciback : error enabling MSI-X for guest : err -28!
> 
> For the NVMe devices, I get these twice, with the 2nd time complaining about 
> MSI (without the -X)
> 
> I feel there is something missing in my kernel-config and/or domain config.
> If anyone can point me at what needs to be enabled/disabled or suggestions on 
> what I can try?

The default number of extra IRQs the guest may (have) set up may be too small.
You may need to make use of Xen's extra_guest_irqs= command line option.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 08:03:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 08:03:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022121.1397840 (Exim 4.92)
	(envelope-from )
	id 1uTc8r-0001Vk-F8; Mon, 23 Jun 2025 08:03:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022121.1397840; Mon, 23 Jun 2025 08: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 1uTc8r-0001Vd-Cc; Mon, 23 Jun 2025 08:03:01 +0000
Received: by outflank-mailman (input) for mailman id 1022121;
 Mon, 23 Jun 2025 08:02:59 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uTc8p-0001VX-Mg
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 08:02:59 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uTc8o-00G9Iz-2N;
 Mon, 23 Jun 2025 08:02:58 +0000
Received: from [2a02:8012:3a1:0:bd17:6d03:6e6c:1c7e]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uTc8o-00EPUt-1a;
 Mon, 23 Jun 2025 08:02: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=P07+I6otFC4SHhPg8wKtFmmoRpUD0ra2oZ4NPG/04C4=; b=sxD9u3FQPG5Yrby0ufy7T7FmGY
	zmsaG0XpAZC12blNSoQJPGaF5cGNsgj7d6xM8us3wIGH3J39LJz3An5VTmTcjzXB4rv/3WVu7oqCI
	vxqc3NxC+BJnUCRMSjaBAE2swSdmnaf7a3s3m4N4OpkWr8Cgrig/ymgZ35ziEFZ8Zr0o=;
Message-ID: <3468bb57-3178-460b-8fb2-3ce106475319@xen.org>
Date: Mon, 23 Jun 2025 09:02:56 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v4 8/8] docs: armproposa: l to add separate SCMI node
 for Xen agent
Content-Language: en-GB
To: Stefano Stabellini ,
 Oleksii Moisieiev 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper ,
 Anthony PERARD ,
 Bertrand Marquis , Jan Beulich
 , Juergen Gross ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Volodymyr Babchuk ,
 Grygorii Strashko 
References: 
 <3f7e1e99f5d1018064f3c4825aff16bd487cf558.1747669845.git.oleksii_moisieiev@epam.com>
 
 
 
 
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Stefano and Oleksii,

Let me start with a bit of process. This is discussion is getting fairly 
difficult to follow.... Can you please trim unrelevant bits when replying?

On 22/06/2025 22:57, Stefano Stabellini wrote:
> On Thu, 19 Jun 2025, Oleksii Moisieiev wrote:
>> On 18/06/2025 03:35, Stefano Stabellini wrote:
>>> On Thu, 12 Jun 2025, Oleksii Moisieiev wrote:
>>>> On 23/05/2025 23:19, Stefano Stabellini wrote:
>>>>> On Mon, 19 May 2025, Oleksii Moisieiev wrote:
>>>>>> From: Grygorii Strashko
>> the same (smc-id and shmem) for both the BSP case (no Xen) and the Xen
>> case (Dom0 domain).
>>
>> Meanwhile, the Xen management agent's SCMI node and configuration are
>> expected to be placed under /chosen.
>>
>> This approach ensures that the Host DT remains as unchanged as possible.
> 
> Yes, my main point is that all the device tree information, except for
> what is under /chosen, should be left unchanged between the BSP case (no
> Xen) and the Xen case.
> 
> We have freedom to decide:
> - the information we put under /chosen and how to interpret it
> - how to use the information under /firmware/scmi when Xen is present
> 
> 
>> Currently:
>>
>> The Host DT /firmware/scmi node requires modification to point to the
>> Xen management agent by changing
>>
>> the smc-id and shmem values.
> 
> I don't think we should require changes to /firmware/scmi in the host DT
> when Xen is present.
> 
> Often, people don't know when or if Xen is present at the time the
> Device Tree is generated. So it is best to avoid modification (outside
> of /chosen).

I am probably missing something. But it looks like TF-A requires to 
suport multi-agent so Xen can use it. Am I correct?

Furthermore, I can't tell why the multi-agent support is Xen specific. 
Surely, you may want something similar with other hypervisors? If not, 
then my next question is why does Xen needs to do things differently?

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Mon Jun 23 08:06:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 08:06:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022128.1397851 (Exim 4.92)
	(envelope-from )
	id 1uTcCM-00024M-Tp; Mon, 23 Jun 2025 08:06:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022128.1397851; Mon, 23 Jun 2025 08:06:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTcCM-00024F-Qr; Mon, 23 Jun 2025 08:06:38 +0000
Received: by outflank-mailman (input) for mailman id 1022128;
 Mon, 23 Jun 2025 08:06:37 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uTcCL-000249-7H
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 08:06:37 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uTcCK-00G9Nw-1q;
 Mon, 23 Jun 2025 08:06:36 +0000
Received: from [2a02:8012:3a1:0:bd17:6d03:6e6c:1c7e]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uTcCK-00EPaz-1K;
 Mon, 23 Jun 2025 08:06: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=fD9RY0HINj/jfBcakbkQDkzaJqNfM60M0bB058HMl+Q=; b=fvnVX2R02mxpAKy2xlCkKQ8FXr
	YvLgHNdETEb9jjyP3TmAK1OQ2KAhJ4gFURPTg9r9WN7hCJcat3kZ4F5Iwtgkaojr3cxWRzWrDsyzg
	e/sHIqji2Iz6eunhkBCmW1jrgTYW20OGknpVX258BZNIzNatetwZiBAbS9YwdJZUFz0k=;
Message-ID: 
Date: Mon, 23 Jun 2025 09:06:32 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC
 multi-agent driver
Content-Language: en-GB
To: Stefano Stabellini ,
 Oleksii Moisieiev 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper ,
 Anthony PERARD ,
 Bertrand Marquis , Jan Beulich
 , Juergen Gross ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Volodymyr Babchuk ,
 Grygorii Strashko 
References: 
 <318044ae12f13b6b297b3f5fda577a1a6cd143da.1747669845.git.oleksii_moisieiev@epam.com>
 
 <6080ff71-2634-4269-8a63-fdafdf03f01b@epam.com>
 
 <769aad0a-8bee-45c6-8c5c-35f9d47ed8ae@epam.com>
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Stefano,

On 22/06/2025 23:15, Stefano Stabellini wrote:
> On Thu, 19 Jun 2025, Oleksii Moisieiev wrote:
>> On 18/06/2025 02:22, Stefano Stabellini wrote:
>>> On Thu, 12 Jun 2025, Oleksii Moisieiev wrote:
>>>> [1]:https://git.iliana.fyi/linux/patch/?id=d5141f37c42e0b833863f157ac4cee203b2ba3d2
>>> Keep in mind that [0] refers specifically to access to MMIO regions. I
>>> assume that the SCMI shared buffers are on normal memory? Regarding [1],
>>> it makes sense if Linux is trying to support shared memory over MMIO.
>>>
>>> Looking at one of your replies below, I am guessing the memory buffers
>>> are actually in normal memory but the issue is that TF-A is mapping them
>>> as uncacheable. Is that correct?
>>>
>>> In that case, I still don't understand why a simple memcpy would not be
>>> sufficient. Can you check?
>>>
>>> If yes, then for now I would just simplify it down to memcpy. When
>>> someone adds support for an SCMI server elsewhere we could look into
>>> adding a more sophisticated memcpy and we can look at the details at
>>> that point in time. Specifically, I am not convinced that memcpy_toio
>>> and memcpy_fromio would work if the SCMI server is on a separate
>>> non-coherent microcontroller.
>>>
>> According to the TF-A implementation  SCMI memory
>>
>> is mapped with the  flags: MT_DEVICE (like for  stm32mp1) or
>> MT_NON_CACHEABLE (for rpi3)
>>
>> So probably you're right. I will check with simple memcpy.
> 
> There is a difference between MT_DEVICE and MT_NON_CACHEABLE: as far as
> I know MT_DEVICE requires aligned accesses while MT_NON_CACHEABLE does
> not.
> 
> However, as I wrote in the other email, if I am not mistaken the current
> implementation of memcpy might work well for us anyway. (To be
> confirmed.)

I am not entirely sure what exactly you want to confirm. I have already 
mentioned several time that our memcpy() on arm64 is using unaligned 
access. So it can't be used for copying data to/from device memory area.

Are you looking for a different things?

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Mon Jun 23 08:10:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 08:10:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022139.1397861 (Exim 4.92)
	(envelope-from )
	id 1uTcFh-0003O7-Fj; Mon, 23 Jun 2025 08:10:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022139.1397861; Mon, 23 Jun 2025 08:10:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTcFh-0003Ne-Cf; Mon, 23 Jun 2025 08:10:05 +0000
Received: by outflank-mailman (input) for mailman id 1022139;
 Mon, 23 Jun 2025 08:10: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 1uTcFg-0003Cp-Nt
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 08:10:04 +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 76c7fdbb-5009-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 10:10:02 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3a54700a46eso2093590f8f.1
 for ; Mon, 23 Jun 2025 01:10:02 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3158a23e5a0sm9972089a91.17.2025.06.23.01.09.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 01:10:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 76c7fdbb-5009-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750666202; x=1751271002; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=wIvth/LkYASs0SP2vzU6Ex55Ua7kWIEVPCg6pSuBGes=;
        b=SrZE2uhMDAWCB5otCrQxA67jbG6XrOMZe1YNrqBHz3gfYMyK7+KoM95EapNE2rHVco
         H7qaz3AfDPTdPHO/ihxeb27fFmQK/MV17byTOKvZkLXTcb85YNgHkkRejXyf1aPReBvo
         ixP/nbqDZcL4VxgFY+bN3z9yfd1t9WWXAUCsH5Ss+sMNkBa7jiusFis0uSRBmr2Bm+8I
         0YASdPiZ3SgHpEm8X4uC341eCTDnS2uRetQsafgt41n4q/MjsBK7VWKczKiL9+PGPlvG
         qSpAclQGWMe6uyHq3PTqFyOQyKpIV74TGy6/vZX6wf5l3KCBbYAmpglAaTrL+2/CnBvd
         /SQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750666202; x=1751271002;
        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=wIvth/LkYASs0SP2vzU6Ex55Ua7kWIEVPCg6pSuBGes=;
        b=DqB/6DnbqRYg7ZutZeHFuBLYGJy08IwtW0QgHIVjmoQfWngAg4XP3/ZV8kJ6/Xtw13
         bMm++0S927YLGxabgHmCMOJUYgp4gM/McZ3ZzoaEL4m3Fcpk4GGQAyygAjqZBu832Kh7
         EStthHsdQ51+6nL6mv4Xei3s88uSMk1tyNrBxuWnGV/SF73XKxe2ykj5etXqr11GSPv5
         WsyTEheqxJsGVs8QqOAPqvHWD+VOtDXvEI3llgdrdv9O8QfwxzyDLsBkUqjKAW1XmbeU
         qauWoEHZ29Mwse/w0aYSlPo+xFQoUZ/xedww42SgFKnsOlm7VnMuXweAI45iIXbtGOGI
         7b4Q==
X-Forwarded-Encrypted: i=1; AJvYcCVSsObiSUubksMfc4eeZ8aBwOskHmU3jXrofVW0AN5E9nUJZ8SNWSI47Iw4OAfUVqUMteGoiEiNBaA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxJwImI97J8rRDAZGX6tEeWRx6Fdj5Kzp4ff+t+i9bx3g/wbGFX
	pzq49RUZ06w/EUHl5dxcxl1jBXXCfLg8AfQOjWpqUQvCyAd+FOG586dLBsqOVTsC/g==
X-Gm-Gg: ASbGncsbWOMx+JXfDou187oU4RXm4FGgAkHAOc5Nbprd5BgIBGSugt8PyaG6bNzNlwu
	u+mX+FIyrXNjqM9kfr38rLI3p7+v6IntTooiRcm+jbnElFPdwCbQygSZKOTL9Yz4MMptd+s7tP7
	DbqvGDCw43cJIbTJTMYyiaVDYHdg924cV5krf5okdHe/WlLQ3+P4r/5ASkA8SRshgE99WO7lTzs
	jJ+z2oTadZW0oZITvtRF2W3uhGeDsVILnF9vhB2KJZeg+QekMtgwLtRJ6b3M9REtkgQYXhmhy2w
	o7eAcgC0WFHaM8/QWvENgN306zOkz/OO0WEtBeYmLRq19Gmb0meN5f95rVw7JzIirBLxP+VS849
	qOa7T76Oabxt3vejN4spNLnmIpnbf98IkwMnC2RucDmWzRDmZVfBJupcVEA==
X-Google-Smtp-Source: AGHT+IH/Sc+Q5z7sDiHNCD5/p8I7yNoP4hSQeKajRwUxWupQNUS6x8akf9qAqgY1/gd+NV2V9M7/Xg==
X-Received: by 2002:a05:6000:25ca:b0:3a4:d6ed:8df8 with SMTP id ffacd0b85a97d-3a6d1329a17mr9394561f8f.39.1750666202128;
        Mon, 23 Jun 2025 01:10:02 -0700 (PDT)
Message-ID: 
Date: Mon, 23 Jun 2025 10:09:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1] xen/domain: fix memory leak in domain_create()
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org,
 dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250623011514.173367-1-dmukhin@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: <20250623011514.173367-1-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 23.06.2025 03:16, dmkhn@proton.me wrote:
> From: Denis Mukhin 
> 
> Fix potential memory leak in domain_create() in late hardware domain case.
> 
> Fixes: b959f3b820f5 ("xen: introduce hardware domain create flag")
> Signed-off-by: Denis Mukhin 

Reviewed-by: Jan Beulich 

It may be relevant to mention that we still can't very well use "goto fail"
on this error path, as insufficient struct initialization was done just yet.

What we may want to consider is to move down the get_unique_id() invocation.
It's not the end of the world to lose one, but that may better be avoided
when we easily can.

> ---
> I think that no memory allocation is required before performing late hwdom
> checks (ID range and hwdom existance).
> 
> Looks like sanitise_domain_config() could better fit for performing such
> configuration checks.
> 
> Alternatively, hardware_domid range could be checked via custom parser
> instead of code in domain_create() and then hwdom existance can be moved
> before alloc_domain_struct().
> 
> Thoughts?

Keeping related things together is the other desire we commonly have.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 08:10:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 08:10:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022144.1397871 (Exim 4.92)
	(envelope-from )
	id 1uTcGL-00049Z-Nk; Mon, 23 Jun 2025 08:10:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022144.1397871; Mon, 23 Jun 2025 08:10: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 1uTcGL-00049S-Kd; Mon, 23 Jun 2025 08:10:45 +0000
Received: by outflank-mailman (input) for mailman id 1022144;
 Mon, 23 Jun 2025 08:10:44 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uTcGK-00049F-Hi
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 08:10:44 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uTcGH-00G9TQ-2d;
 Mon, 23 Jun 2025 08:10:41 +0000
Received: from [2a02:8012:3a1:0:bd17:6d03:6e6c:1c7e]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uTcGH-00EPgv-1z;
 Mon, 23 Jun 2025 08:10: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" 
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=krBuP0IdZM306p3T4ltfVgSHjY9Q40+rNCfzXEpjTEg=; b=W7eXribMkNQLxXQxcfR393iT3F
	GHvTrqGmn3Ax0n/iQI0OSxWQga4LGSzR/tA7DFqJOD/sC6OLqfepFNKd23azvXr4t7BGAflJV0GO8
	8RekWKaoedRAnwCz21AREST0CUF/3J1YynEkDWPqCZF5v0Puh6dyGWInB/IA3s0gTXnY=;
Message-ID: <6810fc4a-eab3-4b03-a009-b4f359a4e886@xen.org>
Date: Mon, 23 Jun 2025 09:10:38 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH 4/4] xen/arm: Implement standard PV time interface as
 per ARM DEN 0057A
Content-Language: en-GB
To: Stefano Stabellini ,
 Koichiro Den 
Cc: xen-devel@lists.xenproject.org,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20250621151201.896719-1-den@valinux.co.jp>
 <20250621151201.896719-5-den@valinux.co.jp>
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Stefano,

On 23/06/2025 00:26, Stefano Stabellini wrote:
> On Sun, 22 Jun 2025, Koichiro Den wrote:
  > If so, then we should have a check here and return "not supported" for
> 32-bit callers.

We already have a generic check to confirm 32-bit domain are not using 
the 64-bit convention. See [1]. So no need for a per-call one.

Cheers,

[1] 
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/arm/vsmc.c;h=6081f14ed0c195306029c5aba7309bee44193fa4;hb=HEAD#l272

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Mon Jun 23 08:21:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 08:21:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022154.1397880 (Exim 4.92)
	(envelope-from )
	id 1uTcQA-0006Hx-JJ; Mon, 23 Jun 2025 08:20:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022154.1397880; Mon, 23 Jun 2025 08: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 1uTcQA-0006Hq-Ga; Mon, 23 Jun 2025 08:20:54 +0000
Received: by outflank-mailman (input) for mailman id 1022154;
 Mon, 23 Jun 2025 08:20: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 1uTcQ9-0006GM-1y
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 08:20:53 +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 f350bf3b-500a-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 10:20:41 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3a582e09144so2313194f8f.1
 for ; Mon, 23 Jun 2025 01:20:41 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3159df71c4bsm7354868a91.2.2025.06.23.01.20.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 01:20:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f350bf3b-500a-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750666840; x=1751271640; 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=bAIMvD61wph0ZIV+5MeDvox+/jllPfWb/wMgyKZjCpk=;
        b=XCdLG9Cvnf4hFz6VI1RxnKwksHC5si4i3ByokLra6nfQiar5TeJ19Ifo01peIiFuM6
         ZPpOnFQF8/s4ZrQuFKWoI56IhBolIdT7PZIFUKyK8WM5zfNyJGNAmp/cw+W8bfOG2/FJ
         kNFUM91YCKVnZrZHcW6ZVBZdKjYulOjaaaCLYKYfOVB5WAwb7kCQ2KCPlki6uy6322cp
         hbPAaSfcselSCbKCxiQ2ZqWIG4iKN7ziKLoG7wYHYxXAs8Y1GBJawQTqVOuBrn5U/Gbl
         JaaHNo0wInlAYBKx3/dAwEMxOlSapO8JllBCJyidCkDCfz04B/jJTgAUL2m45AZxfVHF
         +EQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750666840; x=1751271640;
        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=bAIMvD61wph0ZIV+5MeDvox+/jllPfWb/wMgyKZjCpk=;
        b=lm89uZei8r3t+apX60lDPJL3VVcq4Oph2d+9ibDLLvzQlc68YR8O0OTgbl3xiD2KIA
         RFNuvNKlXWrva/iiKjawEKlWG0nR6JFKWArxOmASROqCrJOm7EaEGJwlPGFNJLQKyzUf
         1IHj4W3lOjBxR7iewLTruaE75jlrZ1aQdN6qWz9O6UFqdJvIlD0jmYbE1N18MF9rYQ+B
         fOmZ1WpTWZyAIImMM+qcM4AuqXRiAEYBcjsQVnEjyoxaKQb8V+oTFbBGGj3CM2t7cCZZ
         BqtHUN3o5K7YquTsROenRL2F4Vqm7KMPyESpnSGmZHyrcv9HteElmezNuIC68X6izbQR
         pzaQ==
X-Forwarded-Encrypted: i=1; AJvYcCUL02/Br47k4vweKZ8jmnCIPVWh+mXWf8VI0fTBC+9/nFZPmrmenou8/GJBj5aQjQAYUlisVKWYLZE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwHL6WeV60GLhgIb6JGdwy5uEcZUEUD4zT5F55Hv5P1vTuYQC/3
	mPByv0fehrCe1+gleBD6pVeV+zVbAf3nE6wlnglKhaXwAKJtHFQa7j5gSnn86DpuDQ==
X-Gm-Gg: ASbGncvHw4zWCTF+zT/fHG+4rISuGkVRLsPcfihSSCerMaysO2RNSbjFJ9XfkyNkNty
	mYqMRSzGkDFiDitVeCn9IukhFW89dRm88o8U3GdfCA4b5+v3dilHehIahVxJfYF4AsdYaaWx/er
	R/lqFreWdnxOWb06qb8fpUG2nDLERGrjU3aQuUFqhITjgJ3WNJ8KIk3PX76b7qeSfnZADoxp+HC
	D7GZ+Ny0fwvrOlpMHdMoGXf9enKPizWIsZvTjTpJ7pH/XG8qA5ZOIRt2c34//RHhbP7Sge/Mtgu
	KvuhwGLNl5QQPEH/VqTj8semtVRO6hJhLwSJWV/iKNbz69wj5P3owDD2dI/DFlEC9H4uLg+jpAC
	sMqUPkv03+x3ZN28/DnhWWAon/Rfx7f5TzTd7MannEHRRE9o=
X-Google-Smtp-Source: AGHT+IHdpkwP+uxGdZkNpklxpM9Ih8cnjGSuleeOKKG4oA7ElN0AiV/5YfyGhWoeuhsXcCRGMbj8Bg==
X-Received: by 2002:a05:6000:4186:b0:3a4:dd16:a26d with SMTP id ffacd0b85a97d-3a6d1307670mr8547616f8f.38.1750666840469;
        Mon, 23 Jun 2025 01:20:40 -0700 (PDT)
Message-ID: <28e3a8bf-79c4-42d4-a0e6-9458ee31f24f@suse.com>
Date: Mon, 23 Jun 2025 10:20:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH] xen: fix header guard generation for asm-generic
 headers
From: Jan Beulich 
To: Nicola Vetrini , sstabellini@kernel.org
Cc: michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 Andrew Cooper ,
 Anthony PERARD , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: 
 <45b33975-be79-40eb-a860-ca3eb71443b0@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: <45b33975-be79-40eb-a860-ca3eb71443b0@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 23.06.2025 09:51, Jan Beulich wrote:
> On 21.06.2025 11:58, Nicola Vetrini wrote:
>> Dashes were wrongly not translated into underscores, thus generating
>> an unexpected guard identifier.
>>
>> Fixes: ee79f378311b ("xen: add header guards to generated asm generic headers")
>> Signed-off-by: Nicola Vetrini 
>> ---
>>  xen/scripts/Makefile.asm-generic | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/xen/scripts/Makefile.asm-generic b/xen/scripts/Makefile.asm-generic
>> index b0828018080d..f6850758c54b 100644
>> --- a/xen/scripts/Makefile.asm-generic
>> +++ b/xen/scripts/Makefile.asm-generic
>> @@ -34,7 +34,7 @@ unwanted    := $(filter-out $(generic-y) $(generated-y),$(old-headers))
>>  quiet_cmd_wrap = WRAP    $@
>>        cmd_wrap = \
>>  	arch=$$(echo $@ | sed -n 's:.*arch/\([^/]*\)/.*:\1:p' | tr a-z A-Z); \
>> -	upper=$$(echo $*.h | tr a-z A-Z | tr '/.' '__'); \
>> +	upper=$$(echo $*.h | tr a-z A-Z | tr '/.-' '__'); \
> 
> Aiui the other argument also needs to change, to '___'. While some tr implementations
> may cope, the spec is quite clear:
> 
> "When the -d option is not specified:
> 
>     Each input character found in the array specified by string1 shall be replaced by the character in the same relative position in the array specified by string2. When the array specified by string2 is shorter that the one specified by string1, the results are unspecified."
> 
> Easy enough to adjust while committing, I suppose.

Except that I notice that this was committed already. Will require another
fixup then, I expect.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 08:41:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 08:41:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022167.1397890 (Exim 4.92)
	(envelope-from )
	id 1uTcjr-00011c-3u; Mon, 23 Jun 2025 08:41:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022167.1397890; Mon, 23 Jun 2025 08:41:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTcjr-00011V-1G; Mon, 23 Jun 2025 08:41:15 +0000
Received: by outflank-mailman (input) for mailman id 1022167;
 Mon, 23 Jun 2025 08:41: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 1uTcjp-000110-6w
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 08:41:13 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d07e5bc4-500d-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 10:41:11 +0200 (CEST)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 (Authenticated sender: nicola)
 by support.bugseng.com (Postfix) with ESMTPA id 62D964EE3C25;
 Mon, 23 Jun 2025 10:41:10 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d07e5bc4-500d-11f0-b894-0df219b8e170
Authentication-Results: bugseng.com; arc=none smtp.remote-ip=162.55.131.47
ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1750668070;
	b=yyDuwEjhnt6FWDqwURyYe7SuaRiJ0ofqEBIeeV89l+PR9Ad3T6nHHtHgXG6ie8l/EafS
	 mUBjbOhygvrQiLDhnnrlbsXEbYjmy3QhqbubbmzGSOc5itTY/UHhBcEjySAY8u7s2VN8d
	 G2CGKGhSO14+ZIVRvNTIgjrCxCLyp64e/KXQCNJIHfmeS7mqmeJRvs+gZ7dQDrCVNn1er
	 NsEvv8l5/voVc3QmnuuUY5HDWqeO+xmbkQyUXhfhE0zshxc277nIKrQh1Y08007HBQ79t
	 8EUCfSc7LVXHRYrX2PWPp2jZa6fbFtNPhWgKwfcG1xMmgjLNwrv1P5p2XVhoEvV6DU8HE
	 kPDt0hixmIOTlfD6dyXqNb21/0rKEQyOSuRl46MZ28y3E3I6K5lyuO9qetyvmz7N2bBLz
	 AqDOJbFDk5K3DO0oFnSzNhWYbCe+NAQD8NzCRn1UldEmNkDJVftbvC9jljRnYkBYOxBH0
	 jD1so1dWKjSQVDz4D1mETtWi8tvFczeM/dtHkbHPiyMOt4JzASG+hZfP/dUAX5NHp1Chq
	 unYxo7u88rGA0LurZqSI6+5qOLQBqpAwafLMXLXR0WKQ2gmFv2vaxA/1HsUOH3xT/Dp7+
	 w6J03vQOhMkX831YK3DiSFeYGLjTRHsC3kJviBf0CqbRmjv4Nux4f0TmwJ8kjGg=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1750668070;
	h=DKIM-Signature:MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:
	 References:Message-ID:X-Sender:Organization:Content-Type:
	 Content-Transfer-Encoding;
	bh=Apxn1EwW5jUNFbwowZsf2yZNLKfqblG8Xvr0MqKrexM=;
	b=qGpfBxsjahKv7eXIbiswfat7AhKOcKHPQGYRl+jUJ3/Xjp3a3Phe4jh1oLz02d2/DCMK
	 9eXHTYMw4d7FPuDlg7fcQiml6QwD+hsUWLNbZ/OPM1D7dGSjlfJW+mAhzABpJ5qArbUBX
	 dGIve+SxBSM9tPaieaibx/DjZ/XIKFjUNJTwjW3pp+uVWbymkwD1Y6EXxlipkuSUWy+4d
	 GAUsTPZj57xHP409Sdh60zi+JB1V5otHMT3qwdEZrveQKLpmcrcBZV7Zci4RZfL9NKdQf
	 gOcIq7z2clQCUWrBV35kZwvyWV2Cub4SJnDqFIx5gnn0v2K74SQuTNTg1sO26U2PBRg3s
	 6nfTia28vcp7IUQyykbEoWYF8weFbNaxg7FTQad4ORpJ8hBJUH7t9bziWRcwOr20shuOe
	 Qco7o/1Ryg9zO60hul4LqBl7YiNXgnRAp0M9Co78ChSZDmWQD5lg+VinNd6AfIFaGQnsH
	 qmDOEowcinRHJqf4tVC1JJoqVrC6h9XmwhUickGjWuWa0i9J58Rd9txFyJTnnyAk1HqwR
	 9b/YfFTGJqXK22/pY/Sw25nNB1r0tYNc1+M3zdrDqNEovG4HMuK3v/spTpu9532O5CfSZ
	 6KfXJQ+22IiLD3h2FEzAj21nLlw2ANPEZ63gNUiuIA+tbNmZvjkPAGSCZH4jeEg=
ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1750668070; bh=9ZpZGRb7kJKM8VCPDfRcaOmkVU1+1v98pMqRVe4UENM=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=Od8P2yepdU5i87q4VuFxk1v53IIj/AnxWzjx/BEkOabQjKr2KE8sG/vEvJK3kFdCe
	 zB+YfpnlvNY/xMkCB0R7Z10K83SC2oVKM9JrEH+9tPxCFKME/gtdzeHmte1OTQLTyz
	 RIAUcJkUiuYRBQc1/aTa3RbxVMTx5f+io3yBog3buITvVWdxfydhJnAp9/ACifn1wL
	 rS9qbgZFoe57hUk9PGMghqAlG4l3LbvIXXBrOCdDNG/lT/ECfEL8CqrfivyGVqTHIF
	 PVrDA7jDZn1AgD+Dr4sV0kEwgFI/vb8hFAEqHoCeYXUqyhBD5BLM0yMwpNw6Fv751L
	 V2r9QsWuYN6lg==
MIME-Version: 1.0
Date: Mon, 23 Jun 2025 10:41:10 +0200
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
 , Anthony PERARD ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH] xen: fix header guard generation for asm-generic
 headers
In-Reply-To: <28e3a8bf-79c4-42d4-a0e6-9458ee31f24f@suse.com>
References: 
 <45b33975-be79-40eb-a860-ca3eb71443b0@suse.com>
 <28e3a8bf-79c4-42d4-a0e6-9458ee31f24f@suse.com>
Message-ID: <9ef5220c5a3bcb8957cef2a9ccbc3e7b@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 2025-06-23 10:20, Jan Beulich wrote:
> On 23.06.2025 09:51, Jan Beulich wrote:
>> On 21.06.2025 11:58, Nicola Vetrini wrote:
>>> Dashes were wrongly not translated into underscores, thus generating
>>> an unexpected guard identifier.
>>> 
>>> Fixes: ee79f378311b ("xen: add header guards to generated asm generic 
>>> headers")
>>> Signed-off-by: Nicola Vetrini 
>>> ---
>>>  xen/scripts/Makefile.asm-generic | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>> 
>>> diff --git a/xen/scripts/Makefile.asm-generic 
>>> b/xen/scripts/Makefile.asm-generic
>>> index b0828018080d..f6850758c54b 100644
>>> --- a/xen/scripts/Makefile.asm-generic
>>> +++ b/xen/scripts/Makefile.asm-generic
>>> @@ -34,7 +34,7 @@ unwanted    := $(filter-out $(generic-y) 
>>> $(generated-y),$(old-headers))
>>>  quiet_cmd_wrap = WRAP    $@
>>>        cmd_wrap = \
>>>  	arch=$$(echo $@ | sed -n 's:.*arch/\([^/]*\)/.*:\1:p' | tr a-z 
>>> A-Z); \
>>> -	upper=$$(echo $*.h | tr a-z A-Z | tr '/.' '__'); \
>>> +	upper=$$(echo $*.h | tr a-z A-Z | tr '/.-' '__'); \
>> 
>> Aiui the other argument also needs to change, to '___'. While some tr 
>> implementations
>> may cope, the spec is quite clear:
>> 
>> "When the -d option is not specified:
>> 
>>     Each input character found in the array specified by string1 shall 
>> be replaced by the character in the same relative position in the 
>> array specified by string2. When the array specified by string2 is 
>> shorter that the one specified by string1, the results are 
>> unspecified."
>> 
>> Easy enough to adjust while committing, I suppose.
> 
> Except that I notice that this was committed already. Will require 
> another
> fixup then, I expect.
> 
> Jan

My bad, GNU tr seems to cope just fine (i tested running on all Xen 
headers) but another fixup is in order.

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 08:41:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 08:41:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022173.1397901 (Exim 4.92)
	(envelope-from )
	id 1uTckT-0001UC-By; Mon, 23 Jun 2025 08:41:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022173.1397901; Mon, 23 Jun 2025 08: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 1uTckT-0001U3-94; Mon, 23 Jun 2025 08:41:53 +0000
Received: by outflank-mailman (input) for mailman id 1022173;
 Mon, 23 Jun 2025 08:41:52 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uTckS-0001Tx-8c
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 08:41:52 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uTckR-00GA45-16;
 Mon, 23 Jun 2025 08:41:51 +0000
Received: from [2a02:8012:3a1:0:bd17:6d03:6e6c:1c7e]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uTckQ-00ER50-24;
 Mon, 23 Jun 2025 08: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" 
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=Lce3v2lnLDSzHOgj5m5InyIrlRGAMBDn6RG4aQB3Ogs=; b=aUr/H5QDjZ7e1nKsZWMIsiP/PO
	J5/KFdmTOKaEbzTKVAkUwEdAhT1L4lqZYe8i7gMzvPVA786HS57VBlKZ20qoLieuJNkfufINZMIm0
	TvcnGOEUqQxcpns3/TcBdn1awWeJ/fzoU/Sl6LUhVoS0hb/ANABNXOfwwro7dYrkaB6o=;
Message-ID: <21cbc79b-2209-42ef-8085-81c41e8e697b@xen.org>
Date: Mon, 23 Jun 2025 09:41:47 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH 4/4] xen/arm: Implement standard PV time interface as
 per ARM DEN 0057A
Content-Language: en-GB
To: Koichiro Den , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20250621151201.896719-1-den@valinux.co.jp>
 <20250621151201.896719-5-den@valinux.co.jp>
From: Julien Grall 
In-Reply-To: <20250621151201.896719-5-den@valinux.co.jp>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Koichiro,

I haven't checked all the details. I will mainly comment on the Xen 
internals.

On 21/06/2025 16:12, Koichiro Den wrote:
> The VCPUOP_register_runstate_memory_area hypercall is still actively
> used, e.g., in the Linux arm64 codebase. When KPTI is enabled, the area
> was not registered from the beginning due to the VA not always being
> valid. In such cases, Linux falls back to using the standard PV time
> interface (ARM DEN 0057A), but this interface has not been implemented
> in Xen for ARM64 (until this commit).
> 
> The VCPUOP_register_runstate_phys_area was introduced, though it's
> unclear whether this would be used in Linux arm64 and when it will be
> prevalent amongst every possible downstream domain Linux variant. And of
> course Linux is not an only option for the Xen arm64 domains.
> 
> Therefore, implementing the standard way of sharing PV time is
> generically beneficial, avoiding reliance on specially crafted
> hypercalls, the usage of which by guest VMs is not always guaranteed.
> Note that the PV_TIME_ST interface communicates with IPA (GPA), not GVA.
> 
> Add the PV time interface according to ARM DEN 0057A.
> 
> Signed-off-by: Koichiro Den 
> ---
>   xen/arch/arm/domain.c                   | 30 +++++++++
>   xen/arch/arm/domain_build.c             | 87 ++++++++++++++++++++++++-
>   xen/arch/arm/include/asm/domain.h       | 17 +++++
>   xen/arch/arm/include/asm/smccc.h        | 12 ++++
>   xen/arch/arm/vsmc.c                     | 38 +++++++++++
>   xen/common/device-tree/dom0less-build.c |  2 +-
>   xen/include/xen/fdt-domain-build.h      |  2 +-
>   7 files changed, 183 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index be58a23dd725..e895e4111f1b 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -277,6 +277,18 @@ static void ctxt_switch_to(struct vcpu *n)
>       WRITE_SYSREG(n->arch.mdcr_el2, MDCR_EL2);
>   }
>   
> +static void update_stolen_time(struct vcpu *n)
> +{
> +    uint64_t tot_stolen;
> +
> +    if ( is_idle_vcpu(current) )
> +        return;
> +
> +    tot_stolen = n->runstate.time[RUNSTATE_runnable] +
> +                 n->runstate.time[RUNSTATE_offline];
> +    write_atomic(&n->arch.pv_time_region->stolen_time, tot_stolen);
> +}
> +
>   static void schedule_tail(struct vcpu *prev)
>   {
>       ASSERT(prev != current);
> @@ -291,6 +303,8 @@ static void schedule_tail(struct vcpu *prev)
>   
>       update_runstate_area(current);
>   
> +    update_stolen_time(current);
> +
>       /* Ensure that the vcpu has an up-to-date time base. */
>       update_vcpu_system_time(current);
>   }
> @@ -586,6 +600,8 @@ int arch_vcpu_create(struct vcpu *v)
>       if ( get_ssbd_state() == ARM_SSBD_RUNTIME )
>           v->arch.cpu_info->flags |= CPUINFO_WORKAROUND_2_FLAG;
>   
> +    v->arch.pv_time_region = &v->domain->arch.pv_time_regions[v->vcpu_id];
> +
>       return rc;
>   
>   fail:
> @@ -707,6 +723,7 @@ int arch_domain_create(struct domain *d,
>                          unsigned int flags)
>   {
>       unsigned int count = 0;
> +    int order;
>       int rc;
>   
>       BUILD_BUG_ON(GUEST_MAX_VCPUS < MAX_VIRT_CPUS);
> @@ -791,6 +808,19 @@ int arch_domain_create(struct domain *d,
>       d->arch.sve_vl = config->arch.sve_vl;
>   #endif
>   
> +    /*
> +     * Preallocate the stolen time shared memory regions for all the
> +     * possible vCPUs.
> +     */
> +    order = get_order_from_bytes(d->max_vcpus * sizeof(struct pv_time_region));

As this is an order, we could end up to waste memory fairly quickly. So 
we should try to free the unused pages from the order. That said, the 
maximum number of virtual CPUs we currently support is 128. If I am not 
mistaken, this could fit in 2 4KB pages. So I would also be ok with a 
BUILD_BUG_ON(MAX_VIRT_CPUS <= 128) and we defer this work.

> +    d->arch.pv_time_regions_gfn = INVALID_GFN;

Does this mean PV time is optional? If so, shouldn't we allocate the 
memory conditionally?

Also, looking at the code below, you seem to cater domains created via 
dom0less but not from the toolstack. I think both should be supported 
for the PV time.

Lastly, you probably only want to allocate the memory for 64-bit domain 
as this is unusable for 32-bit domains.

> +    d->arch.pv_time_regions = alloc_xenheap_pages(order, 0);
 > +    if ( !d->arch.pv_time_regions ) {> +        rc = -ENOMEM;
> +        goto fail;
> +    }
> +    memset(d->arch.pv_time_regions, 0, PAGE_SIZE << order);
 > +>       return 0;
>   
>   fail:
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 85b6909e2b0e..1c51b53d9c6b 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1561,8 +1561,80 @@ int __init make_chosen_node(const struct kernel_info *kinfo)
>       return res;
>   }
>   
> -int __init make_resv_memory_node(const struct kernel_info *kinfo, int addrcells,
> -                                 int sizecells)
> +int __init make_pv_time_resv_memory_node(struct domain *d,
> +                                         const struct kernel_info *kinfo,
> +                                         int addrcells, int sizecells)
> +{
> +    __be32 reg[GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS];
> +    unsigned int len = (addrcells + sizecells) * sizeof(__be32);
> +    struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +    struct membanks *unused_banks = NULL;
> +    void *fdt = kinfo->fdt;
> +    unsigned regions_len;
> +    gfn_t pv_time_gfn;
> +    mfn_t pv_time_mfn;
> +    paddr_t aligned;
> +    paddr_t avail;
> +    __be32 *cells;
> +    int res;
> +    int i;
> +
> +    /* Find unused regions */
> +    regions_len = PAGE_ALIGN(d->max_vcpus * 64);

I would be best to avoid hardcoding the size of the region and use the 
size of struct pv_time_region.

> +    unused_banks = membanks_xzalloc(NR_MEM_BANKS, MEMORY);
> +    if ( !unused_banks )
> +        return -ENOMEM;
> +
> +    res = find_unused_regions(d, kinfo, unused_banks);
> +    if ( res ) {
> +        printk(XENLOG_WARNING "%pd: failed to find unused regions\n", d);
> +        goto fail;
> +    }
> +    for ( i = 0; i < unused_banks->nr_banks; i++ ) {
> +        const struct membank *bank = &unused_banks->bank[i];
> +        aligned = PAGE_ALIGN(bank->start);
> +        avail = bank->size - (aligned - bank->start);
> +        if ( avail >= regions_len )
> +            break;
> +    }
> +    if ( i == unused_banks->nr_banks ) {
> +        res = -ENOSPC;
> +        goto fail;
> +    }
> +
> +    /* Insert P2M entry */
> +    pv_time_mfn = virt_to_mfn(d->arch.pv_time_regions);
> +    pv_time_gfn = gaddr_to_gfn(aligned);
> +    p2m_write_lock(p2m);
> +    res = p2m_set_entry(p2m, pv_time_gfn, regions_len / PAGE_SIZE,
> +                        pv_time_mfn, p2m_ram_rw, p2m_access_r);

p2m_access_* are used for restricting temporarily permission by 
memaccess. So on a data abort, we will call p2m_mem_access_check() which 
will then forward the fault to the memaccess agent.

If you want to restrict permission forever, then you need to use a 
different p2m_type_t. In this case, I am guessing you want p2m_ram_ro.

[...]

> diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/domain.h
> index a3487ca71303..c231c45fe40f 100644
> --- a/xen/arch/arm/include/asm/domain.h
> +++ b/xen/arch/arm/include/asm/domain.h
> @@ -59,6 +59,18 @@ struct paging_domain {
>       unsigned long p2m_total_pages;
>   };
>   
> +/* Stolen time shared memory region (ARM DEN 0057A.b) */
> +struct pv_time_region {
> +    /* This field must be 0 as per ARM DEN 0057A.b */
> +    uint32_t revision;
> +
> +    /* This field must be 0 as per ARM DEN 0057A.b */
> +    uint32_t attribute;
> +
> +    /* Total stolen time in nanoseconds */
> +    uint64_t stolen_time;
> +} __aligned(64);
> +
>   struct arch_domain
>   {
>   #ifdef CONFIG_ARM_64
> @@ -121,6 +133,9 @@ struct arch_domain
>       void *tee;
>   #endif
>   
> +    struct pv_time_region *pv_time_regions;
> +    gfn_t pv_time_regions_gfn;

Given the feature is 32-bit specific, shouldn't the field be protected 
with #define CONFIG_ARM_32?

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Mon Jun 23 08:45:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 08:45:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022193.1397942 (Exim 4.92)
	(envelope-from )
	id 1uTcnj-0002Ra-A2; Mon, 23 Jun 2025 08:45:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022193.1397942; Mon, 23 Jun 2025 08:45: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 1uTcnj-0002RT-6z; Mon, 23 Jun 2025 08:45:15 +0000
Received: by outflank-mailman (input) for mailman id 1022193;
 Mon, 23 Jun 2025 08:45: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 1uTcni-0002Pm-16
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 08:45:14 +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 6090c9d3-500e-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 10:45:13 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a52874d593so3862068f8f.0
 for ; Mon, 23 Jun 2025 01:45:13 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d8393741sm76769495ad.15.2025.06.23.01.45.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 01:45:11 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6090c9d3-500e-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750668312; x=1751273112; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=SQl2C1NqFLO06v8hScJ65RQV3iDSd7aA7Kk8jBlIKDY=;
        b=buUegGkb0d2X0AxuYQYLATwX09fxsuoWpX/NsSmuj40VQDAtKUJifwCSNMEjq0LnhA
         hfdL3/8JZuqJMpyEHAa/iOnVYDiCvhE6k33OvDemvJgML1iHiJBh00s+YjT8m8lDj/rI
         WBUrKg8QzD7a76fn+gyZ/RlPQAn+ZzyV9Df98piyF/mzTts/N/ML6OBnYNus66VQRgiu
         VrF7Q+lDkShLDBtXA766dQ5IAgTkTu8AuqumcF75ysNtqcgyzVpBRf+Ci48zKsKs/rxy
         Juej03jyLkSJ9hbf9ZsWlZ+xaGWutTryL1Kc5RSVzj52vl1YGElZo4NPX+6afoX3nQGF
         BaFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750668312; x=1751273112;
        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=SQl2C1NqFLO06v8hScJ65RQV3iDSd7aA7Kk8jBlIKDY=;
        b=qy+PBFhSE/sJayJWIx3v5CLcaLP1jlc02bBljtYphE5KjzaKw0y9VYHA2NDyMDG4TY
         p/cM5BzxgxqTHETOoAjF9nr2WEvjpisor8Jj3rOSzYdsJvwWmMulP7PRN+J+4f7cwJyI
         blNAcNYQ0FLSIa3knSC+G4o3OkEPOr0qiqka+AIHXNgoB13aFEUGfg/Yo2F4kP7+OOzD
         nSYhXQoqbTYOjXDgqopWCB0NqgehF7CBRKhYEgV5Rgvvdv4gq5w2fYsSfS86BVg9Vi/9
         Voe+/Cv5V+/rTGPmA+96fi/e7anp/Cw1V8NwEgui44Ka6ioIcIlTt+Owxdh/p+Hv5tMq
         o0Tg==
X-Forwarded-Encrypted: i=1; AJvYcCXu7wCShq8l1bs5mA+S3sIBJpirUkRHOcgkr1lY0F6uUGXvBXPhj29F9fiJxWEn/5IAUD+/s4jL1/M=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx8A3nArmdWQKVXGoipkntjAyIxF68FOtS3SkRyaxPuVWaXZQiC
	luWNSX3ACt1FKJaOdxpjH3fE7RKPmzUC7VPQGOZt9hWEQhdMum9a3TF+WCDC0m7qNA==
X-Gm-Gg: ASbGncs6CDMGAvzs6+X/YxJh63+tPb6WO0zRaAbFCByeraIJptk93UU332NGToACN5q
	StBzYqdPaIUE62XO4uqjIpUCiE17OtCEdAeZywpOLySspntF94yP1q958lSx+rtZm6JUgXp9auJ
	4hfhhL+ptQ83o76r8gH4AQ1TXkm6yNUJh4wdhzPGxf4L3VxHKTkn70NXNekuypp7X8Q2f6GsG4O
	xCv4qSDDReoZzCGWOdVcls8HHKOseqN4/XLxn+YIAYJ+X5FoBzWS2HdwXJDmA+PU0zYIDymhiT7
	KKWMAfz97r5nDaHWNlV4ALYd1Cp1jmq+ivASdoqOum4e1058I+IbP/zj32tu2yAyYVxuXJDcb+/
	r9ZGqS1KuNbH1mTg7O6Yh8jkibQZRu6pTFi2gH95sWW+gUo8=
X-Google-Smtp-Source: AGHT+IGWWzEaCzUeuOCScwd87LR0sonjqern3BliBl2w+EXIXh9ahDMEn378NA47WiLD1TF3kVKDkQ==
X-Received: by 2002:a05:6000:26d2:b0:3a5:2cf3:d6ab with SMTP id ffacd0b85a97d-3a6d130ef38mr9138024f8f.39.1750668312335;
        Mon, 23 Jun 2025 01:45:12 -0700 (PDT)
Message-ID: <00495ca3-55f1-422b-9839-aa54ec42a129@suse.com>
Date: Mon, 23 Jun 2025 10:45:05 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [MINI-OS PATCH 0/6] hide struct start_info from PVH code
To: Juergen Gross 
Cc: samuel.thibault@ens-lyon.org, minios-devel@lists.xenproject.org,
 xen-devel@lists.xenproject.org
References: <20250619113804.32694-1-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: <20250619113804.32694-1-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.06.2025 13:37, Juergen Gross wrote:
> While working on xenstore-stubdom live update support I came across
> some really unpleasant code using struct start_info even when running
> in PVH mode.
> 
> Especially suspend/resume was doing some crazy stuff, including
> overwriting the initial struct hvm_start_info partially.
> 
> This series is hiding struct start_info from PVH code. This didn't
> result in any runtime error, but in future I'll need to access struct
> hvm_start_info some time after boot, so I need to get that fixed.
> 
> Tested especially with xl suspend/resume and xl save/restore in PV and
> in PVH mode.
> 
> Juergen Gross (6):
>   suspend: drop crazy pfn handling for PVH
>   setup: drop parameter from map_shared_info()
>   x86/pv: remove global start_info
>   console: drop parameter from get_console()
>   xenbus: drop parameter from get_xenbus()
>   x86/pv: make start_info_ptr PV-only

Before I even try: Does this series interfere in any way with the kexec one,
and hence may need re-basing on top of that (which I've pushed a minute ago)?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 08:48:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 08:48:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022211.1397977 (Exim 4.92)
	(envelope-from )
	id 1uTcqZ-0003Eg-VC; Mon, 23 Jun 2025 08:48:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022211.1397977; Mon, 23 Jun 2025 08:48: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 1uTcqZ-0003EZ-Rf; Mon, 23 Jun 2025 08:48:11 +0000
Received: by outflank-mailman (input) for mailman id 1022211;
 Mon, 23 Jun 2025 08:48: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 1uTcqY-0003CS-05
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 08:48:10 +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 c8a0c223-500e-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 10:48:07 +0200 (CEST)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-453608ed113so34079935e9.0
 for ; Mon, 23 Jun 2025 01:48:07 -0700 (PDT)
Received: from ?IPV6:2003:e5:8746:1a00:ff67:e633:2aa8:93ba?
 (p200300e587461a00ff67e6332aa893ba.dip0.t-ipconnect.de.
 [2003:e5:8746:1a00:ff67:e633:2aa8:93ba])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45365af83easm97427295e9.25.2025.06.23.01.48.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 01:48:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c8a0c223-500e-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750668487; x=1751273287; 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=NXvOq4cMPULULEMsjTN205cI8aIH9nff3JOcVEFn04k=;
        b=GoTARdDglQt3G6rMDvNWANM8Z1acDQqfnpSXUkXhq1oK10z/8hHmlUxbg4AIPLIW1s
         ls1iT23ktbhKUrYuZigtlYyOsN2ZZgYT33eLN9oaVlJhR7DMobUbm0RfZBUw2iGWaI8n
         TYu5AFTF1E015qaFz8VENabFVqI1GMIX5EoF2JGvCr3gwhnHIJlx4lZx5VBd81ZLvCR4
         vgX3H7tmYtlFKxxDMqIvEBOjRKN94Mk3LQ5h/vy4EPerTSQOLpS3wKnPZP2ZdEPHuEWa
         x+UR132B+Td88V8kqChOenAe/wt54FwDMGlJJWpQd85nU9/JdYWgN5ZYRlrd+KnTYoIo
         9Teg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750668487; x=1751273287;
        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=NXvOq4cMPULULEMsjTN205cI8aIH9nff3JOcVEFn04k=;
        b=FpAwXVkqY8bPNtI7j2hDw/b4xW4RUpC3Jbyx180P7gxcRDmLI6nIkwtvjohYy1fJpU
         Do4uBLNPlEzcaP2Y7YUKF7ZA/tcdVPTLvOsQ2Y1uOnZbDsnReetVeUiJVG5ezFy72L89
         UUzkuB+7uiqqtfj19b+93eeE/UY7NQfPEi+aVfxBE3ot8TSSRtKvId4Wi5DFmjqe04mU
         qqgYF5DjIrVT/s/jDK5ck2NeT44cocoGsVKCQjwPbaPPjiHDFmiKzR0akNj13vrJCVyG
         eXIrxo+hdN1fAhO0XdOfSRFCYOm25qYDbB+w+dXwRl0YLpvEysmXvnVZ1M3lwtUj6GMi
         rvzQ==
X-Forwarded-Encrypted: i=1; AJvYcCVPkVN+Y899P8YxgSG0vbmkyPlkT9BVv+P/QppkrZdsOJRQWDLdfny9kbqceWORinFWy0Rq6jZG8+k=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzRGbBtANlFRWGEGhoBBgvse9Lm28+xmQoQZ+jlz4mOhDFGIcsU
	E9MZDgLz7lmDm0eUNcMruAZWE/4d8N2czS+sARWin3UFs65tfRglsXYGx04EI5pWKCQ=
X-Gm-Gg: ASbGnctpN0MnZpYAO3u9+E7GrGTG/b76wv1ZO2/AIBiDlzLUEg2KMJtWA0BGKvhHADa
	XLSkxv6PsliT0N/Htb8KsOE7lOCoVUrsCmmkQSRW9urvLNph5CtORWnPmbhenDU10cXv1QTT1Mh
	KTb0ouH+KTrDMp3LkmOtSJ7+ojdwAnij2jG6/hUYJXAxsd9Zvg6QNIML13TduluH/YcKOF4DkSF
	wLxrL0/4l/apdRDBGND26DomcV++M0QyhT4W5XFR/dkpMNmP+vu3c5synUGc80Gdt65JjuWicUt
	aYadnaUbbAJVQDxg+bpeP2LKd/N0aFUFhx0lTnM/UpOeXK4KDQnqbzzW/TecBF/D9nEjixXDOEJ
	or9GVh9JEM3u/W0gHdHX8H+1lHu8AdIA/4lHvNqMGy+MgYEmhwrFKdauxm317Nqd1PPu5GP/OJC
	ENZsIumAqgXW0=
X-Google-Smtp-Source: AGHT+IFllvis6BqL2cIxJTR1xgSGIlzoCAIRAtCNJL2/Yp8WJIBoMDSRc3EF5GS2MU7XCpF3+/e3KA==
X-Received: by 2002:a05:600c:3542:b0:453:5fde:fb5b with SMTP id 5b1f17b1804b1-453659eea05mr98184685e9.19.1750668486822;
        Mon, 23 Jun 2025 01:48:06 -0700 (PDT)
Message-ID: <169ca556-0082-4885-bc41-2aa0a61d33b8@suse.com>
Date: Mon, 23 Jun 2025 10:48:05 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [MINI-OS PATCH 0/6] hide struct start_info from PVH code
To: Jan Beulich 
Cc: samuel.thibault@ens-lyon.org, minios-devel@lists.xenproject.org,
 xen-devel@lists.xenproject.org
References: <20250619113804.32694-1-jgross@suse.com>
 <00495ca3-55f1-422b-9839-aa54ec42a129@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: <00495ca3-55f1-422b-9839-aa54ec42a129@suse.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------dlbn0Pnb42asKOsf1yWYSuYk"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------dlbn0Pnb42asKOsf1yWYSuYk
Content-Type: multipart/mixed; boundary="------------JY1QJSAeC6Dw0xcCXSFBht2V";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Jan Beulich 
Cc: samuel.thibault@ens-lyon.org, minios-devel@lists.xenproject.org,
 xen-devel@lists.xenproject.org
Message-ID: <169ca556-0082-4885-bc41-2aa0a61d33b8@suse.com>
Subject: Re: [MINI-OS PATCH 0/6] hide struct start_info from PVH code
References: <20250619113804.32694-1-jgross@suse.com>
 <00495ca3-55f1-422b-9839-aa54ec42a129@suse.com>
In-Reply-To: <00495ca3-55f1-422b-9839-aa54ec42a129@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=

--------------JY1QJSAeC6Dw0xcCXSFBht2V
Content-Type: multipart/mixed; boundary="------------mrluI7AjAKXjH176hi71uL4c"

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

T24gMjMuMDYuMjUgMTA6NDUsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAxOS4wNi4yMDI1
IDEzOjM3LCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPj4gV2hpbGUgd29ya2luZyBvbiB4ZW5z
dG9yZS1zdHViZG9tIGxpdmUgdXBkYXRlIHN1cHBvcnQgSSBjYW1lIGFjcm9zcw0KPj4gc29t
ZSByZWFsbHkgdW5wbGVhc2FudCBjb2RlIHVzaW5nIHN0cnVjdCBzdGFydF9pbmZvIGV2ZW4g
d2hlbiBydW5uaW5nDQo+PiBpbiBQVkggbW9kZS4NCj4+DQo+PiBFc3BlY2lhbGx5IHN1c3Bl
bmQvcmVzdW1lIHdhcyBkb2luZyBzb21lIGNyYXp5IHN0dWZmLCBpbmNsdWRpbmcNCj4+IG92
ZXJ3cml0aW5nIHRoZSBpbml0aWFsIHN0cnVjdCBodm1fc3RhcnRfaW5mbyBwYXJ0aWFsbHku
DQo+Pg0KPj4gVGhpcyBzZXJpZXMgaXMgaGlkaW5nIHN0cnVjdCBzdGFydF9pbmZvIGZyb20g
UFZIIGNvZGUuIFRoaXMgZGlkbid0DQo+PiByZXN1bHQgaW4gYW55IHJ1bnRpbWUgZXJyb3Is
IGJ1dCBpbiBmdXR1cmUgSSdsbCBuZWVkIHRvIGFjY2VzcyBzdHJ1Y3QNCj4+IGh2bV9zdGFy
dF9pbmZvIHNvbWUgdGltZSBhZnRlciBib290LCBzbyBJIG5lZWQgdG8gZ2V0IHRoYXQgZml4
ZWQuDQo+Pg0KPj4gVGVzdGVkIGVzcGVjaWFsbHkgd2l0aCB4bCBzdXNwZW5kL3Jlc3VtZSBh
bmQgeGwgc2F2ZS9yZXN0b3JlIGluIFBWIGFuZA0KPj4gaW4gUFZIIG1vZGUuDQo+Pg0KPj4g
SnVlcmdlbiBHcm9zcyAoNik6DQo+PiAgICBzdXNwZW5kOiBkcm9wIGNyYXp5IHBmbiBoYW5k
bGluZyBmb3IgUFZIDQo+PiAgICBzZXR1cDogZHJvcCBwYXJhbWV0ZXIgZnJvbSBtYXBfc2hh
cmVkX2luZm8oKQ0KPj4gICAgeDg2L3B2OiByZW1vdmUgZ2xvYmFsIHN0YXJ0X2luZm8NCj4+
ICAgIGNvbnNvbGU6IGRyb3AgcGFyYW1ldGVyIGZyb20gZ2V0X2NvbnNvbGUoKQ0KPj4gICAg
eGVuYnVzOiBkcm9wIHBhcmFtZXRlciBmcm9tIGdldF94ZW5idXMoKQ0KPj4gICAgeDg2L3B2
OiBtYWtlIHN0YXJ0X2luZm9fcHRyIFBWLW9ubHkNCj4gDQo+IEJlZm9yZSBJIGV2ZW4gdHJ5
OiBEb2VzIHRoaXMgc2VyaWVzIGludGVyZmVyZSBpbiBhbnkgd2F5IHdpdGggdGhlIGtleGVj
IG9uZSwNCj4gYW5kIGhlbmNlIG1heSBuZWVkIHJlLWJhc2luZyBvbiB0b3Agb2YgdGhhdCAo
d2hpY2ggSSd2ZSBwdXNoZWQgYSBtaW51dGUgYWdvKT8NCg0KSSdtIG5vdCBhd2FyZSBvZiBh
bnkgcG9zc2libGUgY29uZmxpY3QuDQoNCg0KSnVlcmdlbg0K
--------------mrluI7AjAKXjH176hi71uL4c
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-----

--------------mrluI7AjAKXjH176hi71uL4c--

--------------JY1QJSAeC6Dw0xcCXSFBht2V--

--------------dlbn0Pnb42asKOsf1yWYSuYk
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/Ey8FAmhZFMUFAwAAAAAACgkQsN6d1ii/Ey+C
Vwf8DWzJllBPIxuydOg7UQYXy3Ly+UsQtqzvldp6JxxOYAm+lRNWoYNxkzaG03LSl6wmz/J9EYTS
meM1U1PvBohR0kBQGycaBJXb6Sf9+s9oULBdzyjUcv/GUuNU/68CKtVLOV2CrhfE7xfkRh0gU77U
Ox/EWJJj3T1shb9uaELgAStDiS5GSF39FHZcmPYMNQBSFg0VOUBXxZlDQDmcAB6ZG+8C611VfxVq
jeiXe8VX4Ek64JRzMZ4Zhpw+r/KRKo3Qfo7twHEErSbkmFo3WrL+TC2JaFLwF5NlL7OrgcxW0uUE
GLy6ocGpiQFkEGDH6si7Mi9cjTOAHasfkOmxnTMa7w==
=ftjf
-----END PGP SIGNATURE-----

--------------dlbn0Pnb42asKOsf1yWYSuYk--


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 09:34:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 09:34:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022231.1398003 (Exim 4.92)
	(envelope-from )
	id 1uTdZX-0001wh-IW; Mon, 23 Jun 2025 09:34:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022231.1398003; Mon, 23 Jun 2025 09: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 1uTdZX-0001wa-FN; Mon, 23 Jun 2025 09:34:39 +0000
Received: by outflank-mailman (input) for mailman id 1022231;
 Mon, 23 Jun 2025 09: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 1uTdZW-0001wU-9o
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 09:34:38 +0000
Received: from mail134-21.atl141.mandrillapp.com
 (mail134-21.atl141.mandrillapp.com [198.2.134.21])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 46566fe8-5015-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 11:34:36 +0200 (CEST)
Received: from pmta10.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail134-21.atl141.mandrillapp.com (Mailchimp) with ESMTP id
 4bQjbG4c41z1XLKX6
 for ; Mon, 23 Jun 2025 09:34:34 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 86199166e7834da7b4ec58d0830bf01d; Mon, 23 Jun 2025 09:34: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: 46566fe8-5015-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1750671274; x=1750941274;
	bh=P4fhwE3VYXnDsfELkjXjUkb3uj5MC1QamYNAuLU3HiI=;
	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=xa/bEEPlcjcIiWZ2ygq3E+4bw6Jc+NPgJdwOnradV3NdAvHJMaYYS8cagNexuOQAX
	 i0fguebEoGaOHuyYihXQKDP6Y2C+DLhPnDGpeQbHLySoV6fZk2Wg8USycq7SRSx/li
	 fYLvqT2rZNdNPccXI4JnkH9VjXL52Z4nra82msAEGw9cc2OkB+RT7k1v2V+cyZUMqx
	 od52VvTYcxZG6HYogiCEqjqZfxyBX+doLX+4PFY8wm3We0QUghFux8BE7WOl6L1vRJ
	 3X6zhkwPeDys5GmS3C1jx0ogym+utI6Oqmdc1fHvK4LUe1nrpIrGrbeOPTyWg0hDjk
	 HQHzmQUaC7jLw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1750671274; x=1750931774; i=yann.sionneau@vates.tech;
	bh=P4fhwE3VYXnDsfELkjXjUkb3uj5MC1QamYNAuLU3HiI=;
	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=FGBD35AtflttdwUbCcusgIvo5Hva5sdUYQ2zzBkXDv0GIvO7Vod9nBfyMboUj1DZ3
	 WYggiS761sFZD+YnANl55o3PLxLuEoZWwB6UGv3PcjhJW/Yj0P1lxn74AMy07Oa1D1
	 bXNv7yuufE6RNX9clvG6Vn9LhqVpa8fnVM8KJJXvBNZx/xUlEvfhAs5GO5RJ6jqaQd
	 /dNbJEQ0WiHtEhCNgLzKt9zHQB++GpSpqdA1phG5PY7Hpwhc0XK0rHlowbJIbPhP4K
	 pKEFB6PMAGf9uVxAStdDgj7v0Cx6+WneqbNARJtqg0RHpoHt6unHcjA0c7wXkxTgXo
	 6+byRUJi8YZrA==
From: "Yann Sionneau" 
Subject: =?utf-8?Q?Re:=20[PATCH=20v1]=20xen:=20fusa:=20arch=5Fspecs:=20Definition=20of=20the=20Virtual=20Machines'=20roles?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1750671273964
Message-Id: 
To: xen-devel@lists.xenproject.org
References: <20250304183115.2509666-1-ayan.kumar.halder@amd.com>
In-Reply-To: <20250304183115.2509666-1-ayan.kumar.halder@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.86199166e7834da7b4ec58d0830bf01d?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250623:md
Date: Mon, 23 Jun 2025 09:34:34 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Hi Ayan, Stefano,

This doc looks nice overall!

However I do think that maybe the role part should be separate from all 
the explanations about virtio.

I would say virtio deserves its own page.

Also, I'm curious what "FFI" is.

Thanks!

Regards,

Yann

On 3/4/25 19:31, Ayan Kumar Halder wrote:
> From: Stefano Stabellini 
>
> Define "Hardware Domain", "Control Domain", "DomUs", "SafeVMs" and
> "UnsafeVMs".
>
> Explain the limitations that VirtIO introduces and the way they affect
> the defined roles.
>
> Signed-off-by: Stefano Stabellini 
> Signed-off-by: Ayan Kumar Halder 
> ---
>   docs/fusa/arch_specs/roles.rst | 200 +++++++++++++++++++++++++++++++++
>   docs/fusa/index.rst            |   1 +
>   2 files changed, 201 insertions(+)
>   create mode 100644 docs/fusa/arch_specs/roles.rst
>
> diff --git a/docs/fusa/arch_specs/roles.rst b/docs/fusa/arch_specs/roles.rst
> new file mode 100644
> index 0000000000..0b3fe821c3
> --- /dev/null
> +++ b/docs/fusa/arch_specs/roles.rst
> @@ -0,0 +1,200 @@
> +===============================
> +Xen Domain Roles and Privileges
> +===============================
> +
> +Roles
> +=====
> +
> +We define the following roles that Xen domains can have:
> +- Hardware Domain
> +- Control Domain
> +- DomU
> +
> +In addition, we classify domains based on the criticality of the tasks
> +they perform:
> +- SafeVM
> +- UnSafeVM
> +
> +DomU
> +----
> +
> +A DomU is a regular domain without extra privileges to perform
> +operations that affect other domains or the entire platform. A DomU is
> +therefore unprivileged and can only affect itself.
> +
> +Hardware Domain
> +---------------
> +
> +The Hardware Domain is a domain that has direct access to all hardware
> +peripherals by default, except for those controlled by Xen (CPU, MMU,
> +IOMMU, Interrupt Controller, Timers, UART). Hardware resources can be
> +directly assigned to other domains ("passthrough"), but the default is
> +that they get assigned to the Hardware Domain. As such, there can only
> +be one Hardware Domain in the system. The Hardware Domain is not
> +privileged: it cannot perform operations that affect other domains or
> +the entire platform.
> +
> +In cases where VirtIO is used to share access to physical devices among
> +multiple domains, the Hardware Domain requires some limited privileges
> +to run the VirtIO backends.
> +
> +Control Domain
> +--------------
> +
> +The Control Domain has full privileges over the system. As such, it can
> +perform privileged operations, typically implemented as hypercalls, that
> +affect other domains and even the entire platform, such as platform
> +reboot. There can only be one Control Domain in the system. A
> +non-exhaustive list of these operations follows:
> +
> +- Reboot other domains
> +- Reboot and shutdown the platform
> +- Suspend/resume other domains
> +- Pause/unpause other domains
> +
> +The Control Domain is optional.
> +
> +SafeVMs and UnSafeVMs
> +---------------------
> +
> +A SafeVM is a domain running a safety-critical task. An UnsafeVM is a
> +domain running non-safety-critical software only. No safety-critical
> +tasks are running in the UnsafeVM.
> +
> +The Control Domain must be a SafeVM because the Control Domain has
> +enough privileges to affect the entire system.
> +
> +Without VirtIO (see below), both the Hardware Domain and DomUs can be
> +SafeVMs or UnsafeVMs. There are no restrictions. For example, the
> +following configuration is compatible with safety:
> +
> +- Hardware Domain: UnsafeVM
> +- 2x DomU: SafeVMs
> +- 2x DomU: UnsafeVMs
> +
> +Privileges
> +==========
> +
> +Full Privileges
> +---------------
> +
> +A domain with full privileges has unrestricted access to all services
> +provided by Xen, including the ability to perform operations that impact
> +other VMs and the entire platform. Only one domain holds these full
> +privileges: the Control Domain.
> +
> +Unprivileged
> +------------
> +
> +An Unprivileged domain lacks special access rights, allowing it to
> +perform only operations that affect itself without impacting other
> +domains. For example, an Unprivileged domain cannot map the memory of
> +another domain.
> +
> +VirtIO Privileges
> +-----------------
> +
> +Domains running VirtIO backends, such as QEMU, require specific
> +privileges over domains with VirtIO frontends to enable proper
> +functionality. For instance, they need permission to map the memory of
> +the domain with the VirtIO frontend. These additional privileges are
> +necessary for standard VirtIO operation but can be removed when using
> +the VirtIO extensions described in the VirtIO chapter. This is the list
> +of VirtIO privileges:
> +- mapping memory of VirtIO frontend domains (foreign map hypercall)
> +- device model hypercalls targeting VirtIO frontend domains
> +
> +VirtIO
> +======
> +
> +VirtIO is a specification and set of drivers to share a physical device
> +among multiple domains. For example, assuming the Hardware Domain has
> +access to an Ethernet device, VirtIO provides a way for the Hardware
> +Domain to allow one or more DomUs to access the Ethernet device.
> +
> +VirtIO is based on a frontend/backend architecture: the frontend is a
> +driver similar to a regular Ethernet device driver (using Ethernet as an
> +example), running in the DomU. The backend is a "proxy" driver running
> +in the same domain as the device driver and have direct access to the
> +device. That domain is typically the Hardware Domain because it is the
> +default domain for hardware assignment, but it is also possible to run
> +VirtIO backends in other domains, provided they have been configured with
> +passthrough access to a physical device. These other domains are called
> +"Driver Domains," and the limitations discussed in the context of VirtIO
> +for the Hardware Domain also apply to Driver Domains.
> +
> +There are multiple issues in VirtIO that affect freedom from
> +interference, so deploying VirtIO introduces limits on the configuration
> +regarding what domains can run safety-critical workloads.
> +
> +It is important to note that VirtIO is not the only way for domains to
> +communicate with each other. Specifically, there are other protocols
> +such as Argo and plain shared memory that do not have the same
> +interference concerns.
> +
> +FFI: Shared Memory and Interrupts
> +---------------------------------
> +
> +All VirtIO protocols are based on ring buffers over shared memory,
> +called "VirtQueues." Although there are well-known methods to set up
> +ring buffers over shared memory that are free from interference, in
> +practice, the existing VirtIO specification and current frontend/backend
> +driver implementations do not follow these best practices. Thus, the
> +ring buffers over shared memory can be a source of interference.
> +
> +Given the current state of the VirtIO specification and drivers, it is
> +recommended that both VirtIO frontends and backends run in UnsafeVMs
> +only. This way, SafeVMs will not be affected by interference caused by
> +VirtIO protocols.
> +
> +As ring buffers exist over memory shared between domains, it is the
> +domains' responsibility to ensure they are safe. This is outside of
> +Xen's responsibility, and out of scope for this document.
> +
> +FFI: Memory Mappings
> +--------------------
> +
> +VirtIO expects the backend to access ("map") arbitrary memory addresses
> +passed by the frontend. In other words, the backend needs to map any
> +memory of the frontend, which is a privileged operation in Xen.
> +
> +Xen implements a Xen-specific extension to VirtIO to address this issue:
> +"VirtIO with Grants."
> +
> +Xen has a feature called the "grant table" that guests can use to
> +voluntarily share individual memory pages with other domains. This way,
> +the backend does not need the privilege to map any memory page of the
> +domain running the frontend, as the frontend whitelists pages for the
> +backend to access.
> +
> +Unless "VirtIO with Grants" is used, to enable VirtIO, a domain with
> +VirtIO backends (the Hardware Domain or a Driver Domain) is given the
> +extra privilege of being able to map any memory of domains with VirtIO
> +frontends.  As this is a source of interference, only UnsafeVMs can run
> +VirtIO frontends without "VirtIO with Grants".
> +
> +FFI: Synchronous Emulation
> +--------------------------
> +
> +VirtIO expects certain operations to be synchronous: the frontend
> +virtual CPU requesting the operation is fully blocked until the backend
> +completes the operation. If the backend does nothing, the frontend vCPU
> +remains blocked. This is a source of interference.
> +
> +When VirtIO is enabled, the domain with the backends (Hardware Domain or
> +Driver Domain) implements these synchronous operations for domains
> +running VirtIO frontends.
> +
> +Xen implements a Xen-specific extensions to VirtIO to address this
> +issue: "non-blocking VirtIO." Two extra virtio-pci registers are
> +provided, allowing the frontend to perform non-blocking operations. By
> +using the two Xen-specific non-blocking registers, the frontend virtual
> +CPU doesn't have to block while waiting for the backend to complete the
> +operations.
> +
> +Unless "non-blocking VirtIO" is used, to enable VirtIO, a domain with
> +VirtIO backends (the Hardware Domain or a Driver Domain) is given the
> +extra privilege of being able to implement these synchronous operations
> +for domains running VirtIO frontends. As this is a source of
> +interference, only UnsafeVMs can run VirtIO frontends without
> +"non-blocking VirtIO."
> diff --git a/docs/fusa/index.rst b/docs/fusa/index.rst
> index 5f1e8acfc4..9d989f5105 100644
> --- a/docs/fusa/index.rst
> +++ b/docs/fusa/index.rst
> @@ -7,3 +7,4 @@ Functional Safety documentation
>      :maxdepth: 2
>   
>      reqs/index
> +   arch_specs/roles


Yann Sionneau | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Mon Jun 23 10:52:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 10:52:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022257.1398034 (Exim 4.92)
	(envelope-from )
	id 1uTemJ-000378-1c; Mon, 23 Jun 2025 10:51:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022257.1398034; Mon, 23 Jun 2025 10: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 1uTemI-000371-Uo; Mon, 23 Jun 2025 10:51:54 +0000
Received: by outflank-mailman (input) for mailman id 1022257;
 Mon, 23 Jun 2025 10:51: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 1uTemH-00036v-E3
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 10:51:53 +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 1210dea6-5020-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 12:51:52 +0200 (CEST)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-453749aef9eso3038785e9.3
 for ; Mon, 23 Jun 2025 03:51:52 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4536470826fsm105212285e9.36.2025.06.23.03.51.50
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 23 Jun 2025 03:51:50 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1210dea6-5020-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750675911; x=1751280711; 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=IlvYb91cgDr4GHwfAoyZqj6N5z7hr/Meexea8FojqKc=;
        b=LFSroIxKBGLUjJukOLJTycpsc/Y8jM2BkCfiT5N4pLmclIwBnk6bAB2qHgK7Ox3LzD
         lEP3MkolimRkFXwtFU2e2PeeuW3EkC4nW1n3Dy8uX5lIB3AHNfwyKNKdrzcCHf9Uu6oQ
         DW4/WS8uBeC9ldYHbj17KK1Qx+8H1HB7Q4jkg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750675911; x=1751280711;
        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=IlvYb91cgDr4GHwfAoyZqj6N5z7hr/Meexea8FojqKc=;
        b=UeLJEKrn8t8YD35FctzQydJgq0qMax5UToMKaHGogZGYw9wkHwFvcJSB2Xr6eB+iJm
         ZSVRCQ9DRqY7oQ0OnL/T8E7sv05znAv0aceWe9JYLDGIMvZ9PjEGtVXh/hHye1hCWYL7
         tGpaVi7WuBU0F0GF7S7uMw/4yLijQrGg2UPPHMijdwXW+VgSfU5Y3KtztGmzuQFpRaQ3
         d4ZKGRyxT80Pv9Si4/digbYITyCxHucwctcpqVs/VDMqaGkyOTGjmtjls0PHKSHQVYQB
         waPh4ULUvWc/fZ24X6BtIvU6/67FB04mJO+s/MoYkq/3AQxfUhTgSEF5Z9EvmuibqNoG
         AAVw==
X-Gm-Message-State: AOJu0YzsApAqdZkFeH5iuI/P3APiNhm8volM0InObGo2ihwtGJ3h0k50
	JRVfNI1BO71n7iPEWSZHsgECroB6VwgUR9m+BO0LtylWH10hay++L/CiLsNpG4yucvefK5VzGOF
	pjBh9M0nq6A==
X-Gm-Gg: ASbGncvQqDf8LqV0CkN6mp29YK7seJrQbLQO2fdD7+WVtCh6MVwECGYcMv+gmUtsTMd
	U/V8khUW9ZNUpUq88hHvH4XtZwy44tad/o2iJ82xWLsjyBcMlEDrjxzDUvNyW1ddwozjDbYLDE4
	Ku1x6CBdXBYad4v3RAdYKX7PedDLv2WXTVKsTOAaJLVw1lKjR60qIE5UGm5F8DAykwv4qFc1sWT
	Hr5yrfpwNuOPmrpHRvtU7btdcW/J8Z77JYySt5TXIzc/4gstzrNAdo6UwPOCd0qHW0pqSP/ZpZ1
	+GFfi6tMr3eWk68StttKiqzq2P7zUfuqXYDl/q2rc5kJDC9oh2ES1WzN/tJ1RS4E5eY0VvuiV/I
	kDzYuEdd2Uk2LFGUdgn091lwCQp5DubLBFX0=
X-Google-Smtp-Source: AGHT+IGPRkwfpTQDvR8QsATLmwjtiTL68IFkiP/8w3mzHm4XpkLJQk0nGn4YGwGi5Pq3m9u3LsVY2w==
X-Received: by 2002:a05:600c:1d02:b0:445:49e:796b with SMTP id 5b1f17b1804b1-453658bac72mr107450615e9.17.1750675911360;
        Mon, 23 Jun 2025 03:51:51 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH] x86/svm: Revert 1->true conversion in svm_asid_handle_vmrun()
Date: Mon, 23 Jun 2025 11:51:48 +0100
Message-Id: <20250623105148.90321-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 is literally ASID 1, not a boolean configuration.

Fixes: 2f09f797ba43 ("x86/svm: Drop the suffix _guest from vmcb bit")
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
---
 xen/arch/x86/hvm/svm/asid.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/svm/asid.c b/xen/arch/x86/hvm/svm/asid.c
index 7977a8e86b53..d5f70f8848be 100644
--- a/xen/arch/x86/hvm/svm/asid.c
+++ b/xen/arch/x86/hvm/svm/asid.c
@@ -37,7 +37,7 @@ void svm_asid_handle_vmrun(void)
     /* ASID 0 indicates that ASIDs are disabled. */
     if ( p_asid->asid == 0 )
     {
-        vmcb_set_asid(vmcb, true);
+        vmcb_set_asid(vmcb, 1);
         vmcb->tlb_control =
             cpu_has_svm_flushbyasid ? TLB_CTRL_FLUSH_ASID : TLB_CTRL_FLUSH_ALL;
         return;

base-commit: cc7394164633e75fb61d52565f75271e0b7f1236
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Jun 23 11:10:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 11:10:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022264.1398044 (Exim 4.92)
	(envelope-from )
	id 1uTf4K-0005pg-Hm; Mon, 23 Jun 2025 11:10:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022264.1398044; Mon, 23 Jun 2025 11:10: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 1uTf4K-0005pZ-EF; Mon, 23 Jun 2025 11:10:32 +0000
Received: by outflank-mailman (input) for mailman id 1022264;
 Mon, 23 Jun 2025 11:10: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 1uTf4H-0005pT-Ae
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 11:10:30 +0000
Received: from gw4.antarean.org (gw4.antarean.org [136.144.238.64])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id aa737a05-5022-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 13:10:26 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
 by gw4.antarean.org (Postfix) with ESMTP id 4bQljt4BXWzNn9l;
 Mon, 23 Jun 2025 13:10:26 +0200 (CEST)
Received: from gw4.antarean.org ([127.0.0.1])
 by localhost (gw4.antarean.org [127.0.0.1]) (amavis, port 10024) with ESMTP
 id IzGkHA0Hwnur; Mon, 23 Jun 2025 13:10:26 +0200 (CEST)
Received: from mailstore1.adm.antarean.org (localhost [127.0.0.1])
 by gw4.antarean.org (Postfix) with ESMTP id 4bQljt1FHdzNkdZ;
 Mon, 23 Jun 2025 13:10:26 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
 by mailstore1.adm.antarean.org (Postfix) with ESMTP id 4bQljt0DFQz1G;
 Mon, 23 Jun 2025 11:10:26 +0000 (UTC)
Received: from mailstore1.adm.antarean.org ([127.0.0.1])
 by localhost (mailstore1.adm.antarean.org [127.0.0.1]) (amavis, port 10024)
 with ESMTP id oWbBwcdQgtxp; Mon, 23 Jun 2025 11:10:25 +0000 (UTC)
Received: from persephone.localnet (persephone.adm.antarean.org [10.55.16.48])
 (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 mailstore1.adm.antarean.org (Postfix) with ESMTPS id 4bQljs2HxNz17;
 Mon, 23 Jun 2025 11:10: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: aa737a05-5022-11f0-b894-0df219b8e170
X-Virus-Scanned: amavis at antarean.org
X-Virus-Scanned: amavis at antarean.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=antarean.org;
	s=default; t=1750677025;
	bh=Vkzz8YAkBcCkAawxdb2sUw9O6vSH29rA/svc/XGMyh0=;
	h=From:To:Subject:Date:In-Reply-To:References;
	b=Gc57AdjIvF7XF+vXKE3PvzN6/LD7XuxmpLhJPpkgX7tyV6Zasr86Ow+Mqn4H6gMNZ
	 PYSHsNDy16e6VoaO33ho82YHY9DnwBICGzx8J/ZHhTQ3RHPx18gcChlqDK0Se80pMh
	 Pq2aWS12oEoiZqqR4UEb5sFuDyKbmBdGGBEOZTyA=
From: "J. Roeleveld" 
To: xen-devel@lists.xenproject.org, Jan Beulich 
Subject:
 Re: xen_pciback: error enabling MSI-X / MSI for guest -- WAS: Re: Kernel
 panic when passing through 2 identical PCI devices
Date: Mon, 23 Jun 2025 13:10:25 +0200
Message-ID: <13792333.uLZWGnKmhe@persephone>
In-Reply-To: <0d1cdd47-8fc2-4aa4-8c78-32f2ef2cc524@suse.com>
References:
 <2226691.irdbgypaU6@persephone> <4683544.LvFx2qVVIh@persephone>
 <0d1cdd47-8fc2-4aa4-8c78-32f2ef2cc524@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="utf-8"

On Monday, 23 June 2025 09:55:46 CEST Jan Beulich wrote:
> On 21.06.2025 16:39, J. Roeleveld wrote:
> > I managed to get past the kernel panic (sort of) by doing the following:
> > 
> > 1) Ensure system is fully OFF before booting. A reset/reboot will cause
> > these errors.
> > 
> > 2) Fix the BIOS config to ensure the PCI-ports are split correctly. If
> > anyone has a Supermicro board and gets errors about PCI-slots not getting
> > full speed let me know.
> > 
> > Not entirely convinced the 2nd was part of the cause, but that's ok.
> > 
> > I now, however, get a new error message in the Domain0 dmesg:
> > pciback : xen_map irq failed -28 for  domain
> > pciback : error enabling MSI-X for guest : err -28!
> > 
> > For the NVMe devices, I get these twice, with the 2nd time complaining
> > about MSI (without the -X)
> > 
> > I feel there is something missing in my kernel-config and/or domain
> > config.
> > If anyone can point me at what needs to be enabled/disabled or suggestions
> > on what I can try?
> 
> The default number of extra IRQs the guest may (have) set up may be too
> small. You may need to make use of Xen's extra_guest_irqs= command line
> option.

I spent the entire weekend searching for possible causes/hints/things to try.
That setting was one I had found some time ago (I think for MSI/MSI-X issues) 
and it's currently set to:
extra_guest_irqs=768,1024

Not sure if it makes sense to increase this further?

# For completeness, the Xen commandline is:
dom0_mem=24576M,max:24576M dom0_max_vcpus=4 dom0_vcpus_pin 
gnttab_max_frames=512 sched=credit console=vga extra_guest_irqs=768,1024 
iommu=verbose

# The kernel commandline is:
kernel=gentoo-6.12.21.efi dozfs root=ZFS=zhost/host/root by=id elevator=noop 
logo.nologo triggers=zfs quiet refresh softlevel=prexen nomodeset 
nfs.callback_tcpport=32764 lockd.nlm_udpport=32768 lockd.nlm_tcpport=32768 
xen-pciback.hide=(83:00.0)(84:00.0)(85:00.0)(86:00.0) xen-
pciback.passthrough=1

If there is anything I am missing or should be doing differently, please let me 
know.

As said, I spent the entire weekend search with google and duckduckgo (ddg 
seems to return more relevant results, but also has few results with similar 
error message that are more recent then 6+ years). Here are what I found out 
so far:

== 1) NVMe errors in dmesg:

I noticed that, even when working, the NVMe drivers show issues with "MSI-X" )
(only showing 1 of the 2, the other has the same messages):
[    7.742006] nvme nvme0: pci function 0000:84:00.0
[    7.742158] nvme 0000:84:00.0: Xen PCI mapped GSI56 to IRQ59
[    7.752907] nvme nvme0: D3 entry latency set to 8 seconds
[    8.003806] nvme nvme0: allocated 64 MiB host memory buffer.
[    8.038746] nvme 0000:84:00.0: enable msix get err ffffff8e
[    8.038756] nvme 0000:84:00.0: Xen PCI frontend error: -114!
[    8.048849] nvme nvme0: 1/0/0 default/read/poll queues
[    8.106017]  nvme0n1: p1 p2 p3 p4

I have been unable to find what " enable msix get err ffffff8e " and " Xen PCI 
frontend error: -114! " actually mean.

These messages show up on a "working" environment. This is with kernel 6.12.21 
and Xen 4.18.4_pre1

== 2) A BIOS setting where default differs from general recommendation by 
Supermicro:
- Setting " MMIO High Size " is set to 256GB. Recommendation I see is to set 
this to 1024GB.
Note: The server has 368 GB ram, so does make sense. I will be changing this 
setting during my next chance to do further testing.

== 3) IOMMU seems enabled, apart from 2 items:
(XEN) Intel VT-d iommu 0 supported page sizes: 4kB, 2MB, 1GB
(XEN) Intel VT-d iommu 1 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 not enabled.  <---
(XEN) Intel VT-d Shared EPT tables enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Interrupt remapping enabled

The 2 marked lines say "not enabled", if I understand all the different 
documentation correctly, this is not an issue. Please let me know if I am 
mistaken.

== 4) "nr_irqs" (and this is making me wonder if the "extra_guest_irqs" is 
actually used

In the Dmesg on the host I see:
[    2.328651] NR_IRQS: 8448, nr_irqs: 1024, preallocated irqs: 16

On the VM/Domain I see:
[    3.673555] NR_IRQS: 4352, nr_irqs: 80, preallocated irqs: 0

The number on the host matches.
The number in the Domain does not.

The specific domain is always the 2nd that is started.




From xen-devel-bounces@lists.xenproject.org Mon Jun 23 11:23:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 11:23:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022271.1398054 (Exim 4.92)
	(envelope-from )
	id 1uTfGZ-0007dH-J6; Mon, 23 Jun 2025 11:23:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022271.1398054; Mon, 23 Jun 2025 11:23: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 1uTfGZ-0007dA-GB; Mon, 23 Jun 2025 11:23:11 +0000
Received: by outflank-mailman (input) for mailman id 1022271;
 Mon, 23 Jun 2025 11:23: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 1uTfGX-0007d4-ED
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 11:23:09 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on2061e.outbound.protection.outlook.com
 [2a01:111:f403:2415::61e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6ea58bd1-5024-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 13:23:06 +0200 (CEST)
Received: from BN9PR03CA0638.namprd03.prod.outlook.com (2603:10b6:408:13b::13)
 by SJ2PR12MB7963.namprd12.prod.outlook.com (2603:10b6:a03:4c1::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.26; Mon, 23 Jun
 2025 11:23:02 +0000
Received: from BL02EPF0001A0F9.namprd03.prod.outlook.com
 (2603:10b6:408:13b:cafe::34) by BN9PR03CA0638.outlook.office365.com
 (2603:10b6:408:13b::13) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8857.29 via Frontend Transport; Mon,
 23 Jun 2025 11:23:02 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL02EPF0001A0F9.mail.protection.outlook.com (10.167.242.100) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8880.14 via Frontend Transport; Mon, 23 Jun 2025 11:23:02 +0000
Received: from localhost (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, 23 Jun
 2025 06:22:59 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6ea58bd1-5024-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=nliAKXjxOJN5tz3OiPyj0odVCeiIZD4g4MiCGCAz6PFZ+e/YUqZE63QRtqc/B1dnaij51AnHmoqmSbrhUDuDxJnLahXtwpfZuwzL3uW1G7MkgX7GznHTEvTOWJnsEGpQ4gPw1qlM7WvGh75rYj24z2Icam5Ao7iZ8JF1ivwLo4IFXbjNy8mOhuQM8NZ2viWZ+H8+QI1RYHwwMxMiKtE3HpufZVJ6Rcx4VxPB6ctJgbsSZAiRjE51dgWYZSEjxSLqZ+LMJdDI/i9yid/L5M5qPf4ZhlFj6ZoK0ozLadr9T+QRPUiZJGWYWHcXsNn6AvDr1j3Udu8oQ8UGvNa3nhoJPg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Ut4r8p5VsxymoBUaFizgbO9ZOLJYX33QqtnhIfB7hqI=;
 b=kzsXgtlQciE0J6ZLwiDfwj0SzhLRHbqTzlGqLqnrm6vFCtQvVqM+sTzKO9UKxV14OhBMF/yNsJ8tpLwHRJ2Fihs+nMXEY2qJ90wWggD9jqkpA3KYD99DiVPKnvHa59QBfT1+oazvQugH25MOzAUpxh5Dxq5zg4Y4PASxH9Vggh47cmIka+gwsdiH5HQOz8cMD62MB+biBRf7x2EtLxxpjzH9Arg43tiuiPu8yfWWrNOG1oT0cfxHoj72frHkHJBlbjbjHNSaaTF9m6y+440unLAENLbhKCVcnPa1xjCaWRbBh04JoKXiw9nderuKXH6juyBK79gwosVrOVbLg6A0/g==
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=Ut4r8p5VsxymoBUaFizgbO9ZOLJYX33QqtnhIfB7hqI=;
 b=MqPw49FkjuCUXErK2pwheVhnS8CvKk/PkT7yYUrQ8Ml4mtB2gjt+i4/ocdOWNaZd+QDmL2JQyYCkflBxe6eJVwSpSycewa0q9tIELKlHg6LHzg7iXtOleCickrh1paCEm3zup0kvgxL0n8hoCUz5P2160oAqjiy/zBkTMSmNQBs=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 23 Jun 2025 13:22:59 +0200
Message-ID: 
CC: Andrew Cooper , Anthony PERARD
	, Michal Orzel , "Julien
 Grall" , =?utf-8?q?Roger_Pau_Monn=C3=A9?=
	, Stefano Stabellini ,
	
Subject: Re: [PATCH v4 01/12] CODING_STYLE: Custom type names must be
 snake-cased by word.
From: Alejandro Vallejo 
To: Jan Beulich 
X-Mailer: aerc 0.20.1
References: <20250620182859.23378-1-agarciav@amd.com>
 <20250620182859.23378-2-agarciav@amd.com>
 
In-Reply-To: 
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: BL02EPF0001A0F9:EE_|SJ2PR12MB7963:EE_
X-MS-Office365-Filtering-Correlation-Id: 5992f3ff-b6a2-435b-7448-08ddb24850dd
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?ODBydXhrU3o1YS9iZG8wUlJCcXNtSXZheHFnMnZwMDdJOXhGOTBJeW5KVlR4?=
 =?utf-8?B?Si9MSXBwOEJjSXJ4WEdxUHM4cTBvSU5mZnhSQWpMVDJKMzdWSzJSRDBLSDdZ?=
 =?utf-8?B?eExCRlBseGljdWtVVUc2bkgyTm9peFNwKzkxdzlhanZyb0g0UEw1Z3VRcXh5?=
 =?utf-8?B?UWJZdCtwTlR0Sy9DZ1A5RVdpd2lKeVA1UUhST0dLZFd2YmlLakMybUV0cjVP?=
 =?utf-8?B?bVh2UCs1UEhmV1kzcmZaNXg2bXArOGVGZTJoOEFBTG9WVGdONnU5dk1DZVV5?=
 =?utf-8?B?TTJqY0N5L2lWOEl0NGVGY01UcUpsV1JJUVprVW9ZbmV1UmswckV5ZmFQVWVC?=
 =?utf-8?B?WjJFWTJpRVUrNkNCK1pSbmFqdG9tOCtoOUlnQ3lKd0xPZ01ydGFVN1MxcTJZ?=
 =?utf-8?B?VnBSazQrNmZ0dHdWQ0l1Tmx6alBwbWlMcDZjYnJrZ3NieC9qTjRLa3ZTV1Mv?=
 =?utf-8?B?dmFCTDdJMUZqYk1Vcm9ndEpiVnVIRCtjUmxRR0M5c0IxVmQ3RWJhUWRLd1dO?=
 =?utf-8?B?dDZ0VUJpdU9ISXB3eWNseEQwVEowa3RzaklGa1ZVTHFkVzEyYkR4dXgrVXRK?=
 =?utf-8?B?QWJrZzloaHB1bitMckNVR3c4ZmZlQUtmZjd3RnhVTnZXWWk1VzdSVHZ3TE1O?=
 =?utf-8?B?WklBQUdpVktadFQ2SDF0ZTBZZnlHcUZXcEtYRHIvU1dYUHA3RlZCWDNNbDR2?=
 =?utf-8?B?VmFuRjAyWVdZalJjVFE2OFRibHozclVDVkFkemRZQWpXdGJUN0V1LzNZVSs1?=
 =?utf-8?B?bnp4eSs0cmozaTJaYnhhOU5FdVBCcVF5a01FaVlLSzRLeW45b1N6WVdRc3Qz?=
 =?utf-8?B?Z2VMZEJROWM3N3NvaldYWHNWWW1hWlBCSUY4TmtkbVdMT1REMDlXNXE0bS9y?=
 =?utf-8?B?bVROVG8wUWJIWEVSUExkbFNvZXRxanlDTVFVcjloS01nNW1Ea1NjZEFLajFs?=
 =?utf-8?B?N1RYZTRKRGgyM2tVamJmTkI1eEQ0dFVaUmZBNDRsSFZvQmdrUVc1OENMZTNE?=
 =?utf-8?B?SHBjWmIxcGZCSEFWcDNLdmpsS3NJQWYwYXVvdkYyd1pTZEtWanlBdDRZYjhR?=
 =?utf-8?B?TkYvb2pUcTN4L3VqZWpzdmM3U2pSeUZhRGppN2MwYVNJZGtmSVdvMnhXbk1t?=
 =?utf-8?B?L3dlZ3U2SEE4cDRGV1lnZGlTa2xiVXkwK2dIL0x4MjRwUHZkSytUbk5tV3lS?=
 =?utf-8?B?cXVUa2VCemxxNEhhK24vNlJaMFFWOXpsRG9mK3ZzeXNrWk9TeUw3K01pTTRY?=
 =?utf-8?B?N0JKQWtuSnE4NktzcU1RQWM1TWZ6RjNSYkhoQ1I2NGdXMDBOYktja01YWXlx?=
 =?utf-8?B?SWg5TlRJdXlESWEwUWprR0x1eXNvaHVqK05la1dmL1Y0N0pGU0h1ajhmOVdI?=
 =?utf-8?B?Y2Jmam5hc1NBRXN0R1hoUFV3R1BHZXU3bGkxOUMrZkI2ZUFsMmJLL0tKeXNm?=
 =?utf-8?B?emVIWkFLNFoxN3ZMa2NUT1NPdS8rS1JmYkJoN1lrWlhRL0tTVVVRYTJMTlln?=
 =?utf-8?B?UnUwelJOWWZVRWVNMEJVUm9MTHZ5RlhwbmtHaXArOVJTN25WZzYxemZuajZE?=
 =?utf-8?B?UzVXTDZUUnF3UUdoc2g1MGNKTHd5eGxoa1BXajBjN2NmNG4vS1pSaUtnd0xP?=
 =?utf-8?B?TjZ1VFdaUVZNSzQyc3lmVlJYa2xxTURocWlhS1lVdlpGVzRTVEFqOEV6ZkEy?=
 =?utf-8?B?ZmZvUTdCRlJSbmRqQkM1V05uMzZIeGNuV2FXem1qM1Q0TlRsM1dyck5qUkx2?=
 =?utf-8?B?NDhPdEFOUmZOdzBXTUVyRTYvcXRTQUpaK2NQMERvdHFFZDBmaEVNMGlBYUNL?=
 =?utf-8?B?UmQ4c2tmL0hTWlc3bjE3TisvU3R0RDZlQkFTdHpiZ3Naam5JdTZUS2duODhx?=
 =?utf-8?B?QzU1Skx2WmsyT25BbGljYVIzMlRoc1hDdlEwMks1UG1uSm1Uakc4V1MzS2Ey?=
 =?utf-8?B?MTIvWjljZ094T3hZN3laVG5BRmJTcjRwWDFuVVAxYkJNdW11akNpUlh6NVBi?=
 =?utf-8?B?Unk1dnpjRkFQODVHZzRuVmk1V210WXBMYjl6V3l1OU4wSjU5dXBMTGZvTHdI?=
 =?utf-8?Q?ZH1ypa?=
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: 23 Jun 2025 11:23:02.0129
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5992f3ff-b6a2-435b-7448-08ddb24850dd
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:
	BL02EPF0001A0F9.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB7963

On Mon Jun 23, 2025 at 9:31 AM CEST, Jan Beulich wrote:
> On 20.06.2025 20:28, Alejandro Vallejo wrote:
>> There's the unwritten convention in x86 of splitting type names using
>> underscores. Add such convention to the CODINNG_STYLE to make it
>> common and less unwritten.
>
> Just curious: How does x86 come into play here? Xen inherited this un-
> written rule from Linux, afaict.
>
> Jan

x86 follows the rule far more strictly than other Xen ports. Even in Linux =
it's
not uncommon to see some words stashed together because they represent a si=
ngle
concept. e.g: "bootmode", "bootram", "bootmod", "bootaddr", etc. Some of th=
em
inherited by Xen itself, like "softirq".

But I digress. I mentioned x86 because it's the most traceable use of the r=
ule
as written in CODING_STYLE in this patch.  When or why you decided to do so=
 is
another matter entirely which I very definitely do not know.

If you feel the commit message should be something else, I'm happy for it t=
o be
such something else.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 11:59:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 11:59:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022279.1398063 (Exim 4.92)
	(envelope-from )
	id 1uTfpg-0003KC-90; Mon, 23 Jun 2025 11:59:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022279.1398063; Mon, 23 Jun 2025 11:59: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 1uTfpg-0003K5-6E; Mon, 23 Jun 2025 11:59:28 +0000
Received: by outflank-mailman (input) for mailman id 1022279;
 Mon, 23 Jun 2025 11:59: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 1uTfpf-0003Jz-Ar
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 11:59:27 +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 8201ace6-5029-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 13:59:25 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3a54700a463so2217862f8f.1
 for ; Mon, 23 Jun 2025 04:59:25 -0700 (PDT)
Received: from [192.168.69.167] (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a6d128cf7asm9177773f8f.100.2025.06.23.04.59.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 04:59:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8201ace6-5029-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1750679965; x=1751284765; 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=ZNl0GNUoL+pUzh6aZuBV7rBwC2JelgKVfHJY1PQe040=;
        b=gA95ZJ8vDdAHuoHobuijCq8C36W5UJft03I22kMwyhf7hUWf7UWON/zY1iKXXXV8Ml
         sriNKruOaKlrj4n8qiiDOjlp4YRBxeSK4nxtZ5eQBAvKTTFbMeMrFue9kbkChYdWVeCB
         Uzo5F67Ztlclo8Z60qCi81bZHb2phyGIYs/CB5w672inB5IjvF6LoUJMX2adg6EKAfFR
         /1NUIGcVX8J5zJz7vblDwwezNp+xyUmgPhXw9BD4J3rxCmTgNLayh7qEIH2zwHggMNdq
         x3eNjCmFpqfBmEhorD3GVHfyMWCvAc+TYhGpd31wMoEBwJBWipsmLPed2Ft444SThxNe
         aZTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750679965; x=1751284765;
        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=ZNl0GNUoL+pUzh6aZuBV7rBwC2JelgKVfHJY1PQe040=;
        b=ZEuRUhkjmSbO9gys1x32EkhI9hBanAIsrnb/fE2RkwCKkYLobqdmNR9E83xkiCmIMF
         Zzd9zRm7nal+JalbVhtvbcmw79H8+Yb0XOMJr4YolRC1O4ldNDXs21WLJP5mXDhw0/JR
         dMhGjsVxXOHKLVVHRvwccUIIi8+vw49MqpeVWrytIfMnsjBrOj6MKN7QwAMKMP/hHDVL
         vQbayAxOyW1vtc5BYIKcMdzqG/Vkzz/apMuEfnWq7yaKUXR5LlOhzI03pkr39lO4ss2l
         NQ7Jyd5469Oh5KzYv0WqqggeG63Nr6LEfsbpSRYfp/FT/4y30+Z7ElQkNKmS3t1tckOA
         B4Gw==
X-Forwarded-Encrypted: i=1; AJvYcCXo3bUScpo5ANwh+LNZmNKq2jiUOkuNVNIbqM2qDHIzZnIRyeLqUMvMuFcIeWAaGzi9sVKEkuogURc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwymbXKvQ6UTj8Pk/D9TZg1A3xxWu5jBdNsIuM3HzHknHwjFFlO
	/PkMDiC1FqYLUz7zL/SBdet0xTLeEZbBgRrN+yPfxElzAHDb33334lkjh9A4JasxPxY=
X-Gm-Gg: ASbGncubpSjv4IKZjLJyi5Zu1tjngL0P2A4YOYlGODCMDwea7l1dtG8hRCxIAycL3rc
	y5b+m4Ew0YqEHbodt3h7MQ80/YoBRJ6Ne80kqzApW5FErMhlxnzYJdFgsm52QfQ8AJzi2/QazCe
	CwoSaIniKUD6wdVGtBrsgdOUtQy0AL4os8hDEnQofwthQ80xTfOq1An5Q1YocldV6/hhWasHTD4
	RFwSU8N9nWhA3DyUfcOJ2+1m503AjkE8AKog3wpOdH4EtFtMHEk+rgLvlnBVGZ71fnDLMGNxTDc
	AdYFQp5Y/RtrHRoLYwkllSjVuDMXTfj/DJH/mW6jkZUKyh1niJ5DE5VnvRb3+mCuT11CPUiarrn
	mCZ0aPA3Dlodx1k4ptBXt6Xj1apBkxxIs74kZHDQT
X-Google-Smtp-Source: AGHT+IHOxtkdXSM3EMBB+rtXAYT6HLDRhKe1XTMmCY2e3R+6NO7I2w8zqwom52rHbrwAtgyuUqWVsQ==
X-Received: by 2002:a05:6000:2010:b0:3a3:598f:5a97 with SMTP id ffacd0b85a97d-3a6d2799df4mr8969438f8f.9.1750679964791;
        Mon, 23 Jun 2025 04:59:24 -0700 (PDT)
Message-ID: 
Date: Mon, 23 Jun 2025 13:59:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 23/26] tests/functional: Restrict nexted Aarch64 Xen
 test to TCG
To: Thomas Huth , qemu-devel@nongnu.org,
 "open list:X86 Xen CPUs" ,
 David Woodhouse 
Cc: Leif Lindholm ,
 Richard Henderson ,
 Radoslaw Biernacki , Alexander Graf ,
 Paolo Bonzini ,
 =?UTF-8?Q?Marc-Andr=C3=A9_Lureau?= ,
 Phil Dennis-Jordan , =?UTF-8?Q?Alex_Benn=C3=A9e?=
 , Bernhard Beschow ,
 Cleber Rosa , Peter Maydell ,
 Cameron Esfahani , kvm@vger.kernel.org,
 qemu-arm@nongnu.org, Eric Auger ,
 =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= ,
 Roman Bolshakov , John Snow 
References: <20250620130709.31073-1-philmd@linaro.org>
 <20250620130709.31073-24-philmd@linaro.org>
 <497fc7b1-dfd2-49ad-938c-47fca1153590@redhat.com>
Content-Language: en-US
From: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= 
In-Reply-To: <497fc7b1-dfd2-49ad-938c-47fca1153590@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 23/6/25 10:11, Thomas Huth wrote:
> On 20/06/2025 15.07, Philippe Mathieu-Daudé wrote:
>> On macOS this test fails:
>>
>>    qemu-system-aarch64: mach-virt: HVF does not support providing 
>> Virtualization extensions to the guest CPU
>>
>> Signed-off-by: Philippe Mathieu-Daudé 
>> ---
>>   tests/functional/test_aarch64_xen.py | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/tests/functional/test_aarch64_xen.py b/tests/functional/ 
>> test_aarch64_xen.py
>> index 339904221b0..261d796540d 100755
>> --- a/tests/functional/test_aarch64_xen.py
>> +++ b/tests/functional/test_aarch64_xen.py
>> @@ -33,6 +33,7 @@ def launch_xen(self, xen_path):
>>           """
>>           Launch Xen with a dom0 guest kernel
>>           """
>> +        self.require_accelerator("tcg") # virtualization=on
> 
> What about kvm (or xen) as accelerator? Would that work?

IIUC this tests boots a nested Xen guest running at Aarch64 EL2,
and at this point we can only run EL2/EL3 on TCG. HVF and KVM
can not for now (we are working on it).

I don't know if Xen can accelerate EL2, it would need support for
such hardware (like the Apple Silicon M4). Cc'ing Xen folks to
figure it out.


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 12:05:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 12:05:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022295.1398074 (Exim 4.92)
	(envelope-from )
	id 1uTfvh-00056B-4m; Mon, 23 Jun 2025 12:05:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022295.1398074; Mon, 23 Jun 2025 12:05:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTfvh-000563-0p; Mon, 23 Jun 2025 12:05:41 +0000
Received: by outflank-mailman (input) for mailman id 1022295;
 Mon, 23 Jun 2025 12:05: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 1uTfvf-00055w-CP
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 12:05:39 +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 5fb0b458-502a-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 14:05:37 +0200 (CEST)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3a4f72cba73so3333191f8f.1
 for ; Mon, 23 Jun 2025 05:05:37 -0700 (PDT)
Received: from [192.168.69.167] (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4535e97a908sm142235035e9.4.2025.06.23.05.05.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 05:05:36 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5fb0b458-502a-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1750680337; x=1751285137; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:content-language:references
         :cc:to:from:subject:user-agent:mime-version:date:message-id:from:to
         :cc:subject:date:message-id:reply-to;
        bh=LhVmC7Ptr86082iSVP3tCUv3mxHNuSnJ7XLqXn+lKmI=;
        b=ERxREUfOUSpiWnO3iKlP6ylC3dm2Vg8Hj27uaZSIM4uzqo35fvHSB+/rfs1v8z6eK/
         jZBCRIr/lUqY0oxAKnwvRXC51oa5WEo6eSCne2NTir3mv4rb1pBY1Typ7n2bwBVcTU+S
         OHnCIoPL/3pijgfbvWPwjv2ySrYHTGtIVZNSJxjwNfoMylqs/U9HjA6fcZz8YJ6aElRV
         KVM4sWtSfZdgsk6Ah2sry7847gWgF6f9QHYT6u1OC19a86sNBAaEgDERrOW8TE/fgzF+
         6/Ji4nwgaUOoW/S/hDyqgxgRpzIoeJilrQ0qtR66GgtVyq2+ha8Ns7ay8JV6Qk9hJYRS
         kOcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750680337; x=1751285137;
        h=content-transfer-encoding:in-reply-to: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=LhVmC7Ptr86082iSVP3tCUv3mxHNuSnJ7XLqXn+lKmI=;
        b=I0fpUNrtA5CT2BBMTm1YUulHrZoHEIbsoCSEzN/J3oQ1iltWhEPZgZtTUd69ebNHyM
         5nhf5RFaBzEWhJqhQ3ylK2qR7q+7Ge8jPd8MHxGGPABV/Es79VFJoCejn33J345D3/V5
         fvL5t2V/vLXllvVGImicLbf7xvW2X1c1ba/nPSfwLa9zQrSdRtFVhWoNd7VQwE63RG+/
         U66Q4RMrC+yxLlu5S2F2SEGjv3WRcP+2YCnVGf3Ezys8e+lV0oqt6TkEmNMh72evIVFV
         JwOlmU79JteSibz2ILvi+ueF/GV3Tfh5977d+Er5igfmV6cKTi2QtOlOCVWRVhcBZxxJ
         a5Wg==
X-Forwarded-Encrypted: i=1; AJvYcCXRbLvvR+pLKj2eh9abr1Pt7I+cJ3Z25fBD4Y5YihbHYj0LFBkdxGAvNSBRB8O6eHf//P/mcoBZeJk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwfG3vdDUcJ1frdzcM/U9XMdK2MmEVFT18AsFbbHk+a+fqxXufS
	+UVqIxiIU3ojlgGIH7h6OeAmcZMC0l/KVdVjZKM3vHoim70ZL/NaK1CZ6Yga+sdsxKo=
X-Gm-Gg: ASbGnctuHqO7smyioc21P4eXZdKvZUh6y1+rkt8zsPU/a7UY5GS/fGOviBj5HVl4zxB
	6nHs037xCYbGfZiTH9GfYPuEdMw4lZ+U2Qy/q1ezOIV8JXLvsc6QlLclykwjBQ44SQK+qy+mIn1
	HQ6gPCzrsu2mmsARY4EurgMKXuVUmyOkJ6gVP0rX9igVHknKeO67uue/ngQ3t4VmfRta4brT7R+
	Hwtrtq5JnhjCz8jCvEOM110lw+B/Getfo36beucpNXZrXFJxCIwvdySdhtBY9pgfsGjMNs2U3Wc
	wL2d5grSvNAyGnw+WnKweQFv3Fv7KWWQX00MppwrdWc3MwJKWfq8F2Ryh5GdiBj/8kAZUQ6R22+
	8yLcSNU/svmTD8Uwimjykccbsjwlw0w==
X-Google-Smtp-Source: AGHT+IFqbtwF21H6pWk34kjB74g+vaQ792b2mQtfrzzfV/L7m1oPbaWH1vPXMofzQKaBoxU+8UO20g==
X-Received: by 2002:a5d:5f93:0:b0:3a4:e238:6496 with SMTP id ffacd0b85a97d-3a6d27e17c2mr9044838f8f.18.1750680336753;
        Mon, 23 Jun 2025 05:05:36 -0700 (PDT)
Message-ID: <424c91ee-f5cb-40a1-b1bd-3f0648ae83f5@linaro.org>
Date: Mon, 23 Jun 2025 14:05:35 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 23/26] tests/functional: Restrict nexted Aarch64 Xen
 test to TCG
From: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= 
To: Thomas Huth , qemu-devel@nongnu.org,
 "open list:X86 Xen CPUs" ,
 David Woodhouse 
Cc: Leif Lindholm ,
 Richard Henderson ,
 Radoslaw Biernacki , Alexander Graf ,
 Paolo Bonzini ,
 =?UTF-8?Q?Marc-Andr=C3=A9_Lureau?= ,
 Phil Dennis-Jordan , =?UTF-8?Q?Alex_Benn=C3=A9e?=
 , Bernhard Beschow ,
 Cleber Rosa , Peter Maydell ,
 Cameron Esfahani , kvm@vger.kernel.org,
 qemu-arm@nongnu.org, Eric Auger ,
 =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= ,
 Roman Bolshakov , John Snow 
References: <20250620130709.31073-1-philmd@linaro.org>
 <20250620130709.31073-24-philmd@linaro.org>
 <497fc7b1-dfd2-49ad-938c-47fca1153590@redhat.com>
 
Content-Language: en-US
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 23/6/25 13:59, Philippe Mathieu-Daudé wrote:
> On 23/6/25 10:11, Thomas Huth wrote:
>> On 20/06/2025 15.07, Philippe Mathieu-Daudé wrote:
>>> On macOS this test fails:
>>>
>>>    qemu-system-aarch64: mach-virt: HVF does not support providing 
>>> Virtualization extensions to the guest CPU
>>>
>>> Signed-off-by: Philippe Mathieu-Daudé 
>>> ---
>>>   tests/functional/test_aarch64_xen.py | 1 +
>>>   1 file changed, 1 insertion(+)
>>>
>>> diff --git a/tests/functional/test_aarch64_xen.py b/tests/functional/ 
>>> test_aarch64_xen.py
>>> index 339904221b0..261d796540d 100755
>>> --- a/tests/functional/test_aarch64_xen.py
>>> +++ b/tests/functional/test_aarch64_xen.py
>>> @@ -33,6 +33,7 @@ def launch_xen(self, xen_path):
>>>           """
>>>           Launch Xen with a dom0 guest kernel
>>>           """
>>> +        self.require_accelerator("tcg") # virtualization=on
>>
>> What about kvm (or xen) as accelerator? Would that work?
> 
> IIUC this tests boots a nested Xen guest running at Aarch64 EL2,
> and at this point we can only run EL2/EL3 on TCG. HVF and KVM
> can not for now (we are working on it).

I'll update the description with:

   Currently QEMU only support accelerating EL0 and EL1, so features
   requiring EL2 (like virtualization) or EL3 must be emulated with TCG.

> I don't know if Xen can accelerate EL2, it would need support for
> such hardware (like the Apple Silicon M4). Cc'ing Xen folks to
> figure it out.



From xen-devel-bounces@lists.xenproject.org Mon Jun 23 12:42:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 12:42:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022306.1398083 (Exim 4.92)
	(envelope-from )
	id 1uTgUu-0001hl-OO; Mon, 23 Jun 2025 12:42:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022306.1398083; Mon, 23 Jun 2025 12: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 1uTgUu-0001he-Ls; Mon, 23 Jun 2025 12:42:04 +0000
Received: by outflank-mailman (input) for mailman id 1022306;
 Mon, 23 Jun 2025 12:42: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 1uTgUt-0001gy-EB
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 12:42:03 +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 75d7241f-502f-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 14:42:02 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3a54690d369so3436012f8f.3
 for ; Mon, 23 Jun 2025 05:42:02 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d8607c96sm82320775ad.138.2025.06.23.05.41.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 05:42:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 75d7241f-502f-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750682521; x=1751287321; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=BQMklvxnDFYP/W2MAanmrFjxA79m9bWrYTbcIqMyaNA=;
        b=I3I6Rkn5mTHddrTzwRuI19xn+uIT2j1hKkDOGWzOLTJcpkRAtfS95mHAypucROXUPL
         FXY8x8Kf82NbH/zxKd1Yr7WzhPILNUFKTliIps1vT3d+K2jujF/Jy1I1ek0rf+4D5n/k
         w9y5f8H+SdR00JGk18cFCsU47YO5YjARlsgEZSeIQI3xZn6zvBI1e8vrhrIL2o7v/eD2
         HsBqJ76Cx0IzhfRBG2tCUEXmsz3dBJ2Juzd2KZsd97x8jRe31do1BI7stNAiUpmXBH5X
         GYE7Ae3uohmjKRHC3avqZHZ5/1tYi/H+YJMgmq1PBIZ0+KJuOVZgDrBfTdJDqlaxishR
         RuSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750682521; x=1751287321;
        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=BQMklvxnDFYP/W2MAanmrFjxA79m9bWrYTbcIqMyaNA=;
        b=ZP1kF1DMBr2RlfQWFIdAu4dnr8cLJcaYDtcs/A0V7e19XqyFhmZ94ByXcZ7/M3x+cA
         P06auYczpjnRSp/7roOaV6CMd5SR0UKN47/GfVbyVSucQ5Tum3ujgTeru4lhe2BddKiq
         vP7PX+mV0wzfqddSNAeheTvXhsDE10uMDRrDzFr6weDQNAE5QuTqBUvlXt7n6eNTqno3
         ad5fPiu/7juP9a8DOp/zHKy4hhdDQ7NTiRMesApndQ/YhbQ28+TQDAIjvOvhE4SR7ii0
         TIufaIRba1sLBRf9A8msTrfaZJACQlKhr+KFgXsg2ZsySG+HuBEQ3atB5nCRNrBbH1vn
         Waiw==
X-Forwarded-Encrypted: i=1; AJvYcCX2LP2N10LU833H90/0kPD8Cjb9JF++h1qMHtHXCkBoLcrf9QBpHuJyZ9jQK0AqPV02HkXbFUw7OB0=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx3Rkusi2FuqPQ2VXnU8Ye0H8wfwn7D0LQ/nkFxkHBYRsA0jVQ+
	1pot8UMq+WuLD5nHNzxis7y5JlRyXoopAEJ3c6nqer5ej1K5zdmRZgCol3wNCezNsg==
X-Gm-Gg: ASbGnctImKWKfF7nUT4iOHqe14OXRnQw4zZNwt9t7v1FnEVTPGQVAXWPCzp7sQRHCkN
	kJRAA5Ujjcx/eRO+v+a+xcz7aRzL5xEZA0mTl6lItanQ7DJxVK7tss4q3UaRQvYv4HyvlIn5m6A
	WXJt3IO6kSttP/hafhJgk18tklZsbnSe3thcfa5Z40PIvkRDgFjRZT7zaJKXiR8+AEhwmgAWe7O
	2lHo/LPGN9hhE3LpcOPnMPtQfG4Uxf82u9oWKvPi2+VJHj8+c951Y2fLnvWgzENfAllyLLwjUbG
	rChKryvjv0lpWnNnSJMs00eBB7iIhi6AwxCSsY227zk+cDugWhSQvjjiBSnUk+PXZOHMS+S1mTa
	6EHPAA7Tajaj6yH1oJiYZu2R6SRMdVAmmeJRGz0W/hQAL6Gw=
X-Google-Smtp-Source: AGHT+IG52pRJ6sXRzr8uSwIUvFrRs+VDqNa5ufeX6YmscjpVBOYnAh4xJy2ehLbZBdNvSftA1G2/Vg==
X-Received: by 2002:a05:6000:2507:b0:3a4:f038:af74 with SMTP id ffacd0b85a97d-3a6d12ebae4mr9047563f8f.51.1750682521315;
        Mon, 23 Jun 2025 05:42:01 -0700 (PDT)
Message-ID: <59cff82d-bb29-4938-a786-6272a3d828a0@suse.com>
Date: Mon, 23 Jun 2025 14:41:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/svm: Revert 1->true conversion in
 svm_asid_handle_vmrun()
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20250623105148.90321-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: <20250623105148.90321-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 23.06.2025 12:51, Andrew Cooper wrote:
> This is literally ASID 1, not a boolean configuration.
> 
> Fixes: 2f09f797ba43 ("x86/svm: Drop the suffix _guest from vmcb bit")
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Mon Jun 23 13:09:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 13:09:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022317.1398094 (Exim 4.92)
	(envelope-from )
	id 1uTgvd-0004fO-UI; Mon, 23 Jun 2025 13:09:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022317.1398094; Mon, 23 Jun 2025 13:09:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTgvd-0004fH-Qc; Mon, 23 Jun 2025 13:09:41 +0000
Received: by outflank-mailman (input) for mailman id 1022317;
 Mon, 23 Jun 2025 13:09: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 1uTgvd-0004f8-I5
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 13:09:41 +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 526b5ee2-5033-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 15:09:40 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3a5123c1533so2082811f8f.2
 for ; Mon, 23 Jun 2025 06:09:40 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-7490a46b772sm8338306b3a.32.2025.06.23.06.09.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 06:09:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 526b5ee2-5033-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750684180; x=1751288980; 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=YBxeT3GbhLxQPHz0x8af+1sCrRfYL0uwQy7qx+Qh/RM=;
        b=IEdQGS11g5MkJwNhOC59//th6eWUUp9uzZB4DeydBdFC/xZY9ByI+YoL6KZNMM1ug9
         +cgv/zlhL6zIPlm+ixM6Du7vDmh4cBcCRrgVy4HX5N9YtAXzJkDZQ5daYWFRI8vS0Al6
         2ZHw9+EpDjC0558iyU0mAmeTm6tXkh5yx74yn/7pWnwF3qBI0USR82aHbJHZMsOy/joJ
         CidbJZEhqv5HJ1jkj/4Ko2YTD4wlLCg5Db9k7G6yme+AkEzczDAPqpkqYLwAXpRneDBC
         qt3xO5q5gVw97Bjrs+nPjybjE3UrmYVGLszbURiNWzjjbcF/8mbQL+47LOKk7GfqItBH
         uVTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750684180; x=1751288980;
        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=YBxeT3GbhLxQPHz0x8af+1sCrRfYL0uwQy7qx+Qh/RM=;
        b=EMtjT6dJUllr7dvtDhwLs118bhIbDAXxF6B5UW2/QNlPgmhFSOJnd/FLgOSW+MSwfN
         cNn6h/Jn2q+1OoR+bTJ1exTLlxoAQ7nxh/7h623Xa0G1igtX2psvwpuvJ2dU+DvDb860
         dVZlLm7jmIZ7C4C3SUkmC9XiBN9oiTm8vrhJ1J0dAEl2lmsluoXqq17JGrN4AyPePC7o
         JfhAm4ZYIFtQxYI2SH8pTec5HkCEYmQ4BC5sQwy8W5pHQ/EvwP//c0TAbFpoA9YSP3I9
         BD65tIash7JTc5nzw/r6lwJ8Tb14DMZfIEFmKy/wJcmr0JoI1Avzsx2V/fn8G8ssDMEb
         5FGw==
X-Gm-Message-State: AOJu0YxjoYQOdK++hZTp6WNpy/qt3IkkYsjE7sefeK3qLIAvLHqNQm81
	H400K77aMIkuV/8mjBMB5+LzAlDUDgwuw8Up0n+xLhp5nRv4wiF+6SfR4083lP/rfqbcEgCkGC6
	9gXE=
X-Gm-Gg: ASbGncsBaQuFOQ+lUnNOqnxOXYFkNtzI0mMdeyE51vafKS6nEQKChwBQvbdEC++s7FH
	djx4xHE1qxitWLZJI2VZs1l8dimZrfO62jMSQulwDqbAhGh5cuoYJsxUzvfbTUtR2s1RiHMbn/q
	xE2gRw91iKI4TL7dDDOrhSOWUXsD6EzbHBOeoiYe0XcvY3QWMLtRLgmZlhhR6CJ+i8FXGnY3bmc
	155mtweAxAmuAJOmV+PhpYvt47VZWMPwTd20wOXBUmUQp15uJTBPcTM7pMlel/OntU6obq57D0t
	1+ZDUZW8dzBsBZrSwKCvkvKdGMcwijWrZGSsT32pgMkIlKAuBkKgpstsMQtunTaSru9TzBHVnT5
	7WGG2l5ge0sZtRJHndpeUexmioxRx/XpfyHA1Vp83I/wec7o=
X-Google-Smtp-Source: AGHT+IHRiXe3CO8RAI+EmBkwi/4uAuhE2IhnKlcOxjGLSJ0E/67jo30qwNJKrjNEQ0qq5vVIOT8a2w==
X-Received: by 2002:a5d:5850:0:b0:3a5:14e1:d9ec with SMTP id ffacd0b85a97d-3a6d12e6386mr9861355f8f.51.1750684179863;
        Mon, 23 Jun 2025 06:09:39 -0700 (PDT)
Message-ID: <039413d6-9204-4d45-b953-e786b30a1695@suse.com>
Date: Mon, 23 Jun 2025 15:09:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: xen_pciback: error enabling MSI-X / MSI for guest -- WAS: Re:
 Kernel panic when passing through 2 identical PCI devices
To: "J. Roeleveld" 
References: <2226691.irdbgypaU6@persephone> <4683544.LvFx2qVVIh@persephone>
 <0d1cdd47-8fc2-4aa4-8c78-32f2ef2cc524@suse.com>
 <13792333.uLZWGnKmhe@persephone>
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: <13792333.uLZWGnKmhe@persephone>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 23.06.2025 13:10, J. Roeleveld wrote:
> On Monday, 23 June 2025 09:55:46 CEST Jan Beulich wrote:
>> On 21.06.2025 16:39, J. Roeleveld wrote:
>>> I managed to get past the kernel panic (sort of) by doing the following:
>>>
>>> 1) Ensure system is fully OFF before booting. A reset/reboot will cause
>>> these errors.
>>>
>>> 2) Fix the BIOS config to ensure the PCI-ports are split correctly. If
>>> anyone has a Supermicro board and gets errors about PCI-slots not getting
>>> full speed let me know.
>>>
>>> Not entirely convinced the 2nd was part of the cause, but that's ok.
>>>
>>> I now, however, get a new error message in the Domain0 dmesg:
>>> pciback : xen_map irq failed -28 for  domain
>>> pciback : error enabling MSI-X for guest : err -28!
>>>
>>> For the NVMe devices, I get these twice, with the 2nd time complaining
>>> about MSI (without the -X)
>>>
>>> I feel there is something missing in my kernel-config and/or domain
>>> config.
>>> If anyone can point me at what needs to be enabled/disabled or suggestions
>>> on what I can try?
>>
>> The default number of extra IRQs the guest may (have) set up may be too
>> small. You may need to make use of Xen's extra_guest_irqs= command line
>> option.
> 
> I spent the entire weekend searching for possible causes/hints/things to try.
> That setting was one I had found some time ago (I think for MSI/MSI-X issues) 
> and it's currently set to:
> extra_guest_irqs=768,1024
> 
> Not sure if it makes sense to increase this further?

Seems unlikely, but you know how many interrupts the device(s) may have.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 13:12:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 13:12:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022322.1398104 (Exim 4.92)
	(envelope-from )
	id 1uTgy4-0006CE-8v; Mon, 23 Jun 2025 13:12:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022322.1398104; Mon, 23 Jun 2025 13:12: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 1uTgy4-0006C7-60; Mon, 23 Jun 2025 13:12:12 +0000
Received: by outflank-mailman (input) for mailman id 1022322;
 Mon, 23 Jun 2025 13:12: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 1uTgy2-0006Bz-Vj
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 13:12:11 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on2060c.outbound.protection.outlook.com
 [2a01:111:f403:2408::60c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a5ffc7a8-5033-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 15:12:01 +0200 (CEST)
Received: from SJ0PR05CA0009.namprd05.prod.outlook.com (2603:10b6:a03:33b::14)
 by LV3PR12MB9234.namprd12.prod.outlook.com (2603:10b6:408:1a0::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.21; Mon, 23 Jun
 2025 13:11:56 +0000
Received: from SJ1PEPF000023CE.namprd02.prod.outlook.com
 (2603:10b6:a03:33b:cafe::55) by SJ0PR05CA0009.outlook.office365.com
 (2603:10b6:a03:33b::14) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8880.16 via Frontend Transport; Mon,
 23 Jun 2025 13:11:56 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ1PEPF000023CE.mail.protection.outlook.com (10.167.244.10) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8880.14 via Frontend Transport; Mon, 23 Jun 2025 13:11:56 +0000
Received: from localhost (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, 23 Jun
 2025 08:11:52 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a5ffc7a8-5033-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=jzvruU7S2Jmj2HGic6maz/fPFXS8AIWR/ijP0AmcMLT3FGz6xrLS3lZUNwRVX3mGDb241ozsfkMQUS0btdr8JtaVk0yxkm+By+znOGctbMhmff00Ay1CezBGMeNt9FsFdlbjJtXxdDWZ57wW+VoL/Fp1uZTfgOCNp8idmnl5mSvHCaL96yrtBiakf90cdGKK5su9NQeAcy/eRZ6L75vNUGwEzxZVw2ASg8InnTYRQgVouhjPHk2lFfijUWqnLkFiCRT9HDRv7tF34Mo4+BkoSXO1/Q9OjlrtPz06/1r05nQsxcAexLwGQck/+iKFZmya9ilEUaMzHIEQmVPfkihgFg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=w8eHeTfqHMNf5Ka4MMWXDpQbPfJva5UEjppPrs3seo8=;
 b=E/AkvMHW9xykNwXERgb53DXWUo+aiNc/EILB0Nq2cS/PKeAsvtKbIHb3e0CDAsLZhnGYVEy+gO1cth9A0ACZ46Ly8htu8WoqAtGpqZ6KI9rmDZJ/g7UrjWbf3LRbOt+VAx4pEwTor7W5Hf82Awh5jMCzeACgccYYN3n6+nWSfGVnK4gUKcjEyI2ZcCAbmHEursjjIvdQuYTyZAth2w850/kcmqeaAXXZywLJN+iS2ehLNRf1oWrcm4sPGtxBYKEa2ZD4MDH0rc+fPCHN8ZdB2D/lt3bqBebuFgD2jZkuUAEz+kTK0lDNUBheXHvYVPb+RsVNz8xoGuq3Gl9p/PztSg==
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=w8eHeTfqHMNf5Ka4MMWXDpQbPfJva5UEjppPrs3seo8=;
 b=U7qWro2Xwp+R+o+DJmPaYSZPa65oe39IUx1e1UlbovfYU5XP+QpV9nJsAnrvpaqjiYGa64PgaFwcYBDrlVRTi5ja1GSExbYB841/Rydv/sQnzf8CS9gYuGFllaI+AgD3VN1c7/X3xccXCcN7SGM9N7ZhWuiekpLZQD6UZ6XLY6Y=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 23 Jun 2025 15:11:50 +0200
Message-ID: 
CC: Andrew Cooper , Anthony PERARD
	, Michal Orzel , "Julien
 Grall" , =?utf-8?q?Roger_Pau_Monn=C3=A9?=
	, Stefano Stabellini ,
	"Bertrand Marquis" , Volodymyr Babchuk
	, Shawn Anastasio
	, Alistair Francis
	, Bob Eshleman , "Connor
 Davis" , Oleksii Kurochko
	, "Daniel P. Smith"
	, =?utf-8?q?Marek_Marczykowski-G=C3=B3recki?=
	, Dario Faggioli ,
	Juergen Gross , George Dunlap ,
	
Subject: Re: [PATCH v4 10/12] xen: Rename CONFIG_HAS_DEVICE_TREE to
 CONFIG_HAS_DEVICE_TREE_DISCOVERY
From: Alejandro Vallejo 
To: Jan Beulich 
X-Mailer: aerc 0.20.1
References: <20250620182859.23378-1-agarciav@amd.com>
 <20250620182859.23378-11-agarciav@amd.com>
 <490ee7bf-cb10-43e3-9416-9a68e7529b96@suse.com>
In-Reply-To: <490ee7bf-cb10-43e3-9416-9a68e7529b96@suse.com>
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: SJ1PEPF000023CE:EE_|LV3PR12MB9234:EE_
X-MS-Office365-Filtering-Correlation-Id: ffce3b22-77ce-4733-5ddc-08ddb2578790
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700013|82310400026|7416014|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?WGE5WmdhZlJ3eXVhb0k0V3dQTksxTXU0MUVneEt1SUhVUFJwdTBGNHNBU2Ro?=
 =?utf-8?B?Uytmcml5akpvV3M1TEllNFNMNmhOZ0EyL3pwbC9HMlVWQnhtemxUTW9UeXQv?=
 =?utf-8?B?K3E3V3M3bTZkZUFHaG1ObFk2enFyK1ptMWozdFVhaWtPU2FmanlhRGd4dHkz?=
 =?utf-8?B?SGUyYnZMTlh4T0JnRDYrUnRoRkxFZG1GMlB6YytPanJKZ2p6Y1RCYmdOb3Mz?=
 =?utf-8?B?aDR3aHFBVDYwZU04T3hkUjk0UXpMNnhiTzZPR0pkWnlyaFpiU0VJejNQV0ZD?=
 =?utf-8?B?NzFKamRZN1Y3b3dwVjlWdkZ4V0UwdjkvcnB3YiszVjZsZURDWVkxeVVFNUF3?=
 =?utf-8?B?SWlQZm1hTTVndlZCRGlSR2w5Y29xSUUwUTFzOXNEaU92QUIzZVlkS21iQ0NI?=
 =?utf-8?B?L2QvUldIek9qR1pHekpqbVpuMlY2bmRpcUMzMXMzT1kxRWpnQUFBSTBXK1By?=
 =?utf-8?B?aStDbG4wS0NJcWFIT2xSWDFWZTVPb0ViLzJXS0Rpc1ZjRVRuSmMwcXRYYTBx?=
 =?utf-8?B?OUdiajQ5TC85VHAxTU1IamliN01jQytlaDNyMzdQQzdtNWNNWHI5Y29kamor?=
 =?utf-8?B?N3FERzRZWEwwZTR0SDRFYmo5L3loRGpBNW5UUGUxNVBMZWE3YkY2NkFnN0t5?=
 =?utf-8?B?NzQ1bWJtczlNb2Vtalp0UDFkN3l5cXdFMVNiK3JjeFF2VEJ1Y2tOVTRLOGxu?=
 =?utf-8?B?ZEdpYXI2TE8zeWhydlovT29Ld0hqdnp0YzNjM0wvVDlsVXBrb0FROERqeUFE?=
 =?utf-8?B?a2xrNUNiRUhIMW1RdUsxaVJRQ2dXdGYvU21lOGFZSWtMUnlVOWw4TnhJaE1j?=
 =?utf-8?B?SC9LODJjV3lSZW9WeHA4UWt2VHpKeUhnZU5hRzIyZ3BBNCtTTnFVd01xMkhw?=
 =?utf-8?B?RUM0SUM1bjRDbHVmTWlPYXI3RUp2R3FvR3NTMkhLdWk4cFRBamVEUHBla0lL?=
 =?utf-8?B?QW5kN1BlMWtjTStVNk9aTDJxM1RuRUxOODU5OWZVd21VNFA4YmhaT0oyTUpU?=
 =?utf-8?B?aTN0cXhTem1DTkpYazhjOG8rWjZ6V0tJcnJBQlJrdmEzMER4RkgxWHRJRFox?=
 =?utf-8?B?QnE4TGUwSUhGaFJQL2RqTXh4aDRoTkViWm84bWQ3SkRRV1JDcmFhY0NVN0JP?=
 =?utf-8?B?MG1wNW83ZUZ1dy9EZkhaZXBNVnNEM1dHN2pidVJxaWkxelB0dnhORUI2bXFS?=
 =?utf-8?B?NDkzd3dBdU1DT0JGN0FRTVR3M3l1SnNycHQ1WTZVVzNmUGd1Y0VHSThDWVNj?=
 =?utf-8?B?OTZtRnZ2dmlEcUNWZHN3N0VlRGFmeWllZnpKaVZMcEdZMVhHUGJ0Q3JTZlla?=
 =?utf-8?B?MVFhWGpOM050TE9Ha2poRUEwSS9ScDltcVlFRHFkcUhxcThvYjdDeEU2M2do?=
 =?utf-8?B?RXVpYWp6NHdERWNWOXgzR01hdzBiQ0Yvd0toakdFQUxHd0pmUHc5YmVCVUNs?=
 =?utf-8?B?NWhoMTlrUmgrYUlWcGRwOXo5VWQxTWYvdDMxbFFKMnhkd0dkNlRubmVFWC9B?=
 =?utf-8?B?MnFXT0xmZ05Md2NsdFRkTGNXYVJUWTMwcjNUSVlvWVozR21hdVU5dFByTTBP?=
 =?utf-8?B?enB1b0ZyQUdDUnVESmkvN1h5VkVlSEtNaWpVTHBHeGRSWWhkN2QvSXo1ZmtG?=
 =?utf-8?B?NGY4dENMNnFmU3hlazZTWkNaMEozdzNqVVd2d0JDaFVUUDZpVjR2VWJEakQ4?=
 =?utf-8?B?MXNFMGYrNzRLZGQzRUVKZ2lNTGNIVEV5UTdETHloOUI5VTdLeVltWUE5amR5?=
 =?utf-8?B?MkRtdHFHU1N5U2ZrZGJGcEQrVnpwOWZjOGdTNjFadUxuZ01jOFk1SjZJYXpl?=
 =?utf-8?B?OHVuZDdTaS9FN2VYL0Q2Z3RNY1hVdmxkRnc1TVNWcDRjRm5TVHBrTmFLM1ZQ?=
 =?utf-8?B?MlB5dUJkQmlhYmQrVVo3THI3L2FpYnpDaitoVS91VUttWmVIMGIvMjBhVks5?=
 =?utf-8?B?NkxvZkJSMUR5Y0R6NWRyckxQbDNobi80U1lWek01SlI4VUsyS0pPUUxoMWty?=
 =?utf-8?B?MGJzd0dWdUVRcEVjZ0p2MmxDTHNmSzA1dWhRTW03Mjlta2o1U0JkSXVpcmJ0?=
 =?utf-8?Q?uq/8Lk?=
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)(7416014)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jun 2025 13:11:56.1424
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ffce3b22-77ce-4733-5ddc-08ddb2578790
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:
	SJ1PEPF000023CE.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR12MB9234

On Mon Jun 23, 2025 at 9:39 AM CEST, Jan Beulich wrote:
> On 20.06.2025 20:28, Alejandro Vallejo wrote:
>> Moving forward the idea is for there to be:
>>   1. Basic DT support: used by dom0less/hyperlaunch.
>>   2. Full DT support: used for device discovery and HW setup.
>>=20
>> Rename HAS_DEVICE_TREE to HAS_DEVICE_TREE_DISCOVERY to describe (2), whi=
le
>> DOM0LESS_BOOT is left to describe (1).
>
> Considering hyperlaunch this feels wrong to me. Did you consider splittin=
g
> HAS_DEVICE_TREE into HAS_DEVICE_TREE_PARSE and HAS_DEVICE_TREE_DISCOVERY,
> as I suggested on the committers call? You weren't there, but Stefano sai=
d
> he was taking notes.

Some might've been lost is transit, I admit. I don't remember hearing about
a HAS_DEVICE_TREE_PARSE, but it might've very well been me being spotty whe=
n
syncing with Stefano.

Having a special HAS_DEVICE_TREE_PARSE doesn't seem very helpful, as every
arch would have it set. I'd definitely like for the "enable support to boot
several predefined domains from DTB descriptions" to be a single option for=
 both
dom0less and hyperlaunch. And be selectable rather than unconditionally sel=
ected
And ideally move towards a future in which both dom0less and hyperlaunch ar=
e one
and the same.

I can do an early rename s/HAS_DOM0LESS/HAS_PREDEFINED_DOMAINS and s/
DOM0LESS_BOOT/BOOT_PREDEFINED_DOMAINS/ if that helps. I was waiting to do s=
o
until x86 gains the ability to boot off a DTB to avoid having help messages
describing things not yet on the tree.

>
>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
>> @@ -14,7 +14,7 @@ config CORE_PARKING
>> =20
>>  config DOM0LESS_BOOT
>>  	bool "Dom0less boot support" if EXPERT
>> -	depends on HAS_DOM0LESS && HAS_DEVICE_TREE && DOMAIN_BUILD_HELPERS
>> +	depends on HAS_DOM0LESS && HAS_DEVICE_TREE_DISCOVERY && DOMAIN_BUILD_H=
ELPERS
>>  	default y
>>  	help
>>  	  Dom0less boot support enables Xen to create and start domU guests du=
ring
>> @@ -85,7 +85,7 @@ config HAS_ALTERNATIVE
>>  config HAS_COMPAT
>>  	bool
>> =20
>> -config HAS_DEVICE_TREE
>> +config HAS_DEVICE_TREE_DISCOVERY
>>  	bool
>>  	select LIBFDT
>
> This select imo ought to move to HAS_DEVICE_TREE_PARSE, unless I misunder=
stand
> what LIBFDT covers.

Doing so would preclude compiling it out on x86 when hyperlaunch is not the=
re.
LIBFDT is very much essential on arm/riscv/ppc, but not so on x86.

>
>> --- a/xen/common/Makefile
>> +++ b/xen/common/Makefile
>> @@ -6,9 +6,9 @@ obj-$(CONFIG_HYPFS_CONFIG) +=3D config_data.o
>>  obj-$(CONFIG_CORE_PARKING) +=3D core_parking.o
>>  obj-y +=3D cpu.o
>>  obj-$(CONFIG_DEBUG_TRACE) +=3D debugtrace.o
>> -obj-$(CONFIG_HAS_DEVICE_TREE) +=3D device.o
>> +obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) +=3D device.o
>>  obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) +=3D device.o
>> -obj-$(CONFIG_HAS_DEVICE_TREE) +=3D device-tree/
>> +obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) +=3D device-tree/
>
> Here I'm less certain - is everything in that subdir truly "discovery" re=
lated?

The non-discovery related parts are quite entangled with the discovery ones=
. In
time, I'll want to move an untangled dom0less/hyperlaunch subset onto a sep=
arate
predef-doms/ folder iff all of it starts using LIBFDT rather than unflatten=
ed
DTs, but that's a future endavour.

There's also all of bootinfo, which is not discovery related, but is used A=
TM
exclusively by arches doing discovery.

>
>> --- a/xen/common/sched/Kconfig
>> +++ b/xen/common/sched/Kconfig
>> @@ -67,7 +67,7 @@ endmenu
>> =20
>>  config BOOT_TIME_CPUPOOLS
>>  	bool "Create cpupools at boot time"
>> -	depends on HAS_DEVICE_TREE
>> +	depends on HAS_DEVICE_TREE_DISCOVERY
>>  	help
>>  	  Creates cpupools during boot time and assigns cpus to them. Cpupools
>>  	  options can be specified in the device tree.
>
> This similarly looks wrong to me. Whether to create CPU pools is purely a
> Xen-internal software thing, isn't it?
>
> Jan

In principle, it should be HAS_DOM0LESS and likely will be later when I hoo=
k it
for x86. I was waiting for x86 needing such a change to use the binding. Wo=
uld
you rather have the change done now?

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 13:19:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 13:19:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022335.1398113 (Exim 4.92)
	(envelope-from )
	id 1uTh4j-0006rh-0l; Mon, 23 Jun 2025 13:19:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022335.1398113; Mon, 23 Jun 2025 13:19:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTh4i-0006ra-Tx; Mon, 23 Jun 2025 13:19:04 +0000
Received: by outflank-mailman (input) for mailman id 1022335;
 Mon, 23 Jun 2025 13:19: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 1uTh4h-0006rU-WD
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 13:19:04 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on2062c.outbound.protection.outlook.com
 [2a01:111:f403:2009::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a019fe53-5034-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 15:19:01 +0200 (CEST)
Received: from DS2PEPF00004564.namprd21.prod.outlook.com
 (2603:10b6:f:fc00::51c) by SJ2PR12MB8064.namprd12.prod.outlook.com
 (2603:10b6:a03:4cc::17) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.28; Mon, 23 Jun
 2025 13:18:56 +0000
Received: from DS1PEPF0001709C.namprd05.prod.outlook.com
 (2603:10b6:2c:400:0:1007:0:a) by DS2PEPF00004564.outlook.office365.com
 (2603:10b6:f:fc00::51c) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8901.4 via Frontend Transport; Mon,
 23 Jun 2025 13:18:55 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 DS1PEPF0001709C.mail.protection.outlook.com (10.167.18.106) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8880.14 via Frontend Transport; Mon, 23 Jun 2025 13:18:55 +0000
Received: from localhost (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, 23 Jun
 2025 08:18:53 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a019fe53-5034-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lRFhouuOxxg9HrmTHYocf62CQmGsPzYtYkVm78SuG1HdLNnJR5Sw1/v6T3JQkHL0qEkoCdzCkMFU9mYGUo0arX+duKZBZsH43rjN0HnpHHIg4wKv2jKQuwcOJSuEr5PJJdUZL8nP2K2eEOBnhbdaQ8KiSGaMJL83yNC4Q2Gg4kpUgCILe3PdWuQcdkaG3+JXf6IXMC1As46G1tY5akqOVRH7bU3cLHdr9PA0bRj+ePUzhB7h8TAatem1ChPekduai+TksUcJTESaKgniewCNPTEa1SDk/B0HIVsJks/ox2FcGVGPDUMt9levgvSBSa+xxWq9GiP+2FXaely348yutw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=PhZT9PUfZYV50C7KkICGq/MzwGt9MACt4eHQPw+CGfY=;
 b=t8myiLZI2OhHf/O0/HFLybg9ub+uzdNWftsPRExReoNOXywRm9OJwlS1l43He4/1Ch2yYWqoxXUOu8KGWOArpO3UHkfxd1kRDMx3olVyZBQWaM64czeS2z2sf/Wg14yQ0ndSolKofXQz0bBp3qF6M/AfmbVNKH5oMxFAw4OGhUJ6GcwKmdqqfbyrvGV5bEthGrbKz3Tz4jlwl4tdJLwD+q5yvNrLKfDBbWLSJDYwbEZQ/SkL0OxSz/hShzKDig81noY8gt1A/VGJ3EZzRxpIrYZW0VY7bKVTlQ3E7Lw+ercGtfMBhjC4HU+d+rCxzJ/thvOqWmedekjljObg+a+qIw==
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=PhZT9PUfZYV50C7KkICGq/MzwGt9MACt4eHQPw+CGfY=;
 b=Rrv5Vn1vPmolr7RNgsDo14AWgLUMNExPiPPWu56qMY2QqXTc1qu9om+NTOBzl4fcvDvZPUzOFadTROptzyeQFmDVU/QTbtVFYurUVUYJweoBqJM5fq8FGltzGjRj9wyxW0p7k+izUsO18NLpZMeR0BOMiuQ735itnqShbgbR2II=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 23 Jun 2025 15:18:52 +0200
Message-ID: 
CC: Stefano Stabellini , Julien Grall
	, Bertrand Marquis , Michal Orzel
	, 
Subject: Re: [PATCH v4 11/12] xen/dt: ifdef out DEV_DT-related bits from
 device_tree.{c,h}
From: Alejandro Vallejo 
To: Jan Beulich 
X-Mailer: aerc 0.20.1
References: <20250620182859.23378-1-agarciav@amd.com>
 <20250620182859.23378-12-agarciav@amd.com>
 
In-Reply-To: 
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: DS1PEPF0001709C:EE_|SJ2PR12MB8064:EE_
X-MS-Office365-Filtering-Correlation-Id: 98ea0aa6-8e9f-487e-cae2-08ddb2588189
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?SlY5MXpVWUpINm12R1RYVHh6SE9tNWpSNXZVMG1Xd2tWRnBWbnhmdHdOMUd0?=
 =?utf-8?B?TmtZbW1mNFd0TXhmZWZXSW9Nd09jVGFNcFl3eCtXUHBvUnRWcDRNZFNmZHBS?=
 =?utf-8?B?bVRWZm0wU0ZCN2RZY2Ura2pzTHl5M3ZLUUVxWElBeHFpKzJaY3RCM1NFL1Iw?=
 =?utf-8?B?cXY1VkpLdjVuNzdvQ3JQaSthUkJWUnJEMS9ORUpsOFFJS1RMV2RoZVhrS3h4?=
 =?utf-8?B?eUpKb2hIbU1hdy9PMXRMNGNFVVhrRFVFdGRHeWptZE1qQnZuRDFycGNHeUtO?=
 =?utf-8?B?MDZWOWRXRGRTVGFDd1V4M3JmSmF1RnBReFBhWGFBaGphb0NTZjNTbXRYSjRI?=
 =?utf-8?B?UkxwSkQxTDY5a2ZNTnhiblB1Zm1jWm1ibHc2TVIyYjJLaVhIcUY5L1Q4bURS?=
 =?utf-8?B?TENEUVVwMDNabTh4UjJiWE0wQUdKT2llajdDWGs4SkVMakRYb3BoeVhkM1R4?=
 =?utf-8?B?V3NaVW5JMnVqR0w5eVBYQUJkRGErcUtnVUcyMkhGdWNlc0Q5aDNmZzBJMlNP?=
 =?utf-8?B?VGx1eFRsTnU2eEZhTDVMUmhUL01NTXBpeWJNRi9kR3UxMHBTcEhCVG9FMU50?=
 =?utf-8?B?WnpqbkdidXJkTmNQNzNmK0t6YWs1U1p5ZVduWVp3U091cUNNNFhLMmFjc0tE?=
 =?utf-8?B?ZkVRQmNLaFI1RDcyVFRITzFrVWVnVTNhUGJKQVM1UzR4YXplbGh3eUxaWVd6?=
 =?utf-8?B?czdrUmxVS09oM2daMFgxbXhtdVdqSEpRbnAzSkNDeGw4NFBQMXZ0dTArTUEy?=
 =?utf-8?B?NXBJeFkvMmh0NDlqbmlPRkFZelp1SzkxV0Y3T081Ni9PNE10cU0veVZyZlB5?=
 =?utf-8?B?eDI4bjRQUmQ3dUFtU2ZIbTdTYjV1K1FENVVzU1l3dU5zR21Ca1BzcitIZzNh?=
 =?utf-8?B?dnRDWkI5WUUwZ3pEbkJtU2NCZkhHQ3ozd1R1QVpjMzl2ZHFpOXljMm1kbGRH?=
 =?utf-8?B?UVVHRGN5cW9nemVGWXlLZy91NDVTKzAyWUJHZmxRczhuaDY1UlY0STFVRWxG?=
 =?utf-8?B?OHpQY2RVbDR2b3Y3aDdHTlJOemRVcTN1Y2lUbHdnakNtL0dCOGJIN3BiOHhp?=
 =?utf-8?B?K3JERmhyWm0xZExTNGUrQnpaeTQ3WDZrdkpqc1gwRXRNTzU0cWc1NUFFLzRV?=
 =?utf-8?B?aEF3ekZ3OTllR3luSmdTbVpPL21URkthQzhlQXE3aDl5S0FhVUY2Y3hJVS8y?=
 =?utf-8?B?R3lhazBoM21DV05lZGRYUno1WHNQcDBPbTB1RW9oamdOYW5HSmNoSTJGNmlX?=
 =?utf-8?B?UGlJVE16bG9jVzdReG9YUHhvWHBnWjZvNUJWOGhOeXl2c2U3R1Q1bGk4Q3o0?=
 =?utf-8?B?RFNac2RTMGM4aWxLUk1JTTZUb2dBdnZMYmo4V2ZmZlV0YVdaalNYb2I2UGhT?=
 =?utf-8?B?Y1VEUGJNNnV0Y2JoOHFkL0lTYVg5dFFGaUZ4TVNrMWhlQWlyTk8wMGZqVlJp?=
 =?utf-8?B?ZlZ3azBCQ2NyM1FnWEt3NmFvRkVhc3RIY2poZTc3WVczZTRWbWQ4MlpNZm03?=
 =?utf-8?B?RXV0YnR1UVptZVJvaTNOWFo4OWhWWTJJZDg4MUViMFF4a29lZGFEdkJnSFNN?=
 =?utf-8?B?Z0FpNzVObU1zZDFsSjhoSkVCY1hDVTUzak8zUjVnLzltUHJMZXJDOXlPNEZs?=
 =?utf-8?B?N2RidElVbWV1UzJVeTRWbFJuN2JFWk1aOVgzcmduWG81bnc3OHNsd25ycWp3?=
 =?utf-8?B?WllXMjYzRjA3eVFQQ3hvYk1COXcxTDR4N09nb2w5WDFpNzBaOHZBeWR4MkJu?=
 =?utf-8?B?QTRjcjZkM21LTTVpL1M4SjIzS3d0eWM0Z1g1dmtjaHB0UjY5UDEzLzArVUVP?=
 =?utf-8?B?RGhRbGlHYXJIaFAxbm1wMWRFNzlkNUpTTUhMV3A1TzBER3Z6Qis1K2FiaG5G?=
 =?utf-8?B?Sk0yZGYwVW40a25rK1Rrb1RoMXhHOUpxcC9EQ3Q2UUJUMklGNjNqSk5hS2M1?=
 =?utf-8?B?ZFR2dlg0YVA1RDJaQkhnRm9wbVFYNkZFTGRORkYwODVsRlMxOTZCSXBoMkkx?=
 =?utf-8?B?Nk5OamhxY3VHejBESk9wMk54US9BVnZGM3QrY1BRUDluOUxoSmFDS3hXbDZp?=
 =?utf-8?Q?jLgYgI?=
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: 23 Jun 2025 13:18:55.5883
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 98ea0aa6-8e9f-487e-cae2-08ddb2588189
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:
	DS1PEPF0001709C.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB8064

On Mon Jun 23, 2025 at 9:44 AM CEST, Jan Beulich wrote:
> On 20.06.2025 20:28, Alejandro Vallejo wrote:
>> device-tree.c stops requiring CONFIG_HAS_DEVICE_TREE_DISCOVERY and may
>> function with DOM0LESS_BOOT.
>>=20
>> Without this, there's a clash with x86's definition of device_t. Because
>> x86 doesn't discover devices in the DT it can simply skip the code
>> to do so during the unflattening phase.
>>=20
>> Not a functional change on architectures that currently use these files,
>> as they already select CONFIG_HAS_DEVICE_TREE_DISCOVERY.
>>=20
>> Signed-off-by: Alejandro Vallejo 
>> ---
>>  xen/common/device-tree/device-tree.c | 2 ++
>>  xen/include/xen/device_tree.h        | 4 ++++
>>  2 files changed, 6 insertions(+)
>>=20
>> diff --git a/xen/common/device-tree/device-tree.c b/xen/common/device-tr=
ee/device-tree.c
>> index 725ff71646..741e2ce585 100644
>> --- a/xen/common/device-tree/device-tree.c
>> +++ b/xen/common/device-tree/device-tree.c
>> @@ -2029,9 +2029,11 @@ static unsigned long unflatten_dt_node(const void=
 *fdt,
>>              ((char *)pp->value)[sz - 1] =3D 0;
>>              dt_dprintk("fixed up name for %s -> %s\n", pathp,
>>                         (char *)pp->value);
>> +#ifdef CONFIG_HAS_DEVICE_TREE_DISCOVERY
>>              /* Generic device initialization */
>>              np->dev.type =3D DEV_DT;
>>              np->dev.of_node =3D np;
>> +#endif /* CONFIG_HAS_DEVICE_TREE_DISCOVERY */
>>          }
>>      }
>
> Without something said to that effect in the description, this contradict=
s
>
> obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) +=3D device-tree/
>
> that the previous patch put in place, and that only the subsequent patch
> will further change.
>
> Jan

Would replacing the last paragraph of the commit message with...

  Not a functional change because the whole file is gated by
  CONFIG_HAS_DEVICE_TREE_DISCOVERY already. A later patch allows the file t=
o be
  usable without it, for which this ifdefs are a prerequisite.

... help?

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 13:34:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 13:34:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022342.1398123 (Exim 4.92)
	(envelope-from )
	id 1uThJH-0001Is-7P; Mon, 23 Jun 2025 13:34:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022342.1398123; Mon, 23 Jun 2025 13:34: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 1uThJH-0001Il-4V; Mon, 23 Jun 2025 13:34:07 +0000
Received: by outflank-mailman (input) for mailman id 1022342;
 Mon, 23 Jun 2025 13:34: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 1uThJF-0001If-NY
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 13:34:05 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20609.outbound.protection.outlook.com
 [2a01:111:f403:2412::609])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b9356fa8-5036-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 15:34:03 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by CH0PR12MB8463.namprd12.prod.outlook.com (2603:10b6:610:187::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.19; Mon, 23 Jun
 2025 13:33:59 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8857.026; Mon, 23 Jun 2025
 13:33: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: b9356fa8-5036-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=zO/sbyY/x7Aln4V/bEDWbuoZSaEMu1w+qitv4OhXpd9jzTlZEIQ/0Fj4sQmgP6pHr8nlXOC8A6pucO/EvP70eQytj/a0lyjvjNGXJnk7XwCh4JN/g/roLaTu41nJym+fbi6FDonb5W7Eme+ksiVpWnOWvFbsK1qobfbAPqQguKHw082R4+QjkOLIz9gQ0ong6GJ5b2zcwaQ+CNjvTDRHIQTO39m5KfSrVL3bHgEe4T7EczHtdNUbwoq04OEIDNk0xwIucXFYjck3C2SUSImDzCNwEcH1tPrYnJXeiNdjCNrDCWAXqRVZExJKKKpykjvgG/hVfZKUPApvan14zq+Elw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=DFQWjcBCXw26hRC1ZWrkugATZ5VlbiL7Md2ju5lP1T0=;
 b=negXJ1Xxq/K6OE1FWIst1MvDnLxWCa2BwTGTsl3QHnXtk6A/mbo4W0Uy8EbRA81srZ6sKMf5Ijv+6Hbcu107RQwpY8PMPyfJS3dLTTAeB5dWJ07dpN27WicIsSL02ZeyfzFDg4ExQONl8lBa01Xdw1Gtqf/gm8bGOOtsY0qHHsocNEuwa44Ak9AoGpXftzAR0dX17+zI8Jbf35jonQX+QcIrXG9wWh6cwK5RqbSO7kGdfaq2Pz/9dr06CHpl2dcpdp5GxmwaopHshQK0RqbK1aPSKmWHMUoDJGflJ2JlTimr3Bd8XzLxZiz8mW9dMnqrkj6/K+pyRYBSmks4Y7AxeA==
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=DFQWjcBCXw26hRC1ZWrkugATZ5VlbiL7Md2ju5lP1T0=;
 b=eXAsOGkew3eeEdv9Stj8niyOEiDMdn7XTXtViQe/l7OJkDI3iL0zv6qsY+UojfIQiEBklT18f1PlhYPvt7Cvn34zKcnGQKfFkPTmfAh6rbq0xzNmIE70tf4kL1CMfOLZMhljmObi1S4Nzn8RCbmIwtXmtjGXozhm+Sk3N0A06d4=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Mon, 23 Jun 2025 15:33:55 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH 1/4] xen/arm: Add wrapper find_unused_regions
To: Koichiro Den , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250621151201.896719-1-den@valinux.co.jp>
 <20250621151201.896719-2-den@valinux.co.jp>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250621151201.896719-2-den@valinux.co.jp>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR3P281CA0143.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:95::6) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|CH0PR12MB8463:EE_
X-MS-Office365-Filtering-Correlation-Id: a98e60cb-49d3-479b-c689-08ddb25a9c00
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?MmZBeHR3ajZLbkR4bnBTTHZoTlNHYytDbU81QkFsbVhERmdUc1k3eEF0UGlk?=
 =?utf-8?B?QWc3Nkh1aXRCOUt1SEZXTjFvU2h2WEhCSXVQTmRpTUtGbmE5WFNEbjhESzZh?=
 =?utf-8?B?aWp5cGhONDdSUjJZU1VDM2p4LzUza0plQUgxbWs1b0x0NFRTbW9GeFFOVUZF?=
 =?utf-8?B?U2cvQlBZbHI1SlBlWDQ1VzNSdXBxUTBDczZPNWVRaTJYSlRLZHEwdFcrQnVk?=
 =?utf-8?B?b3ByOG4rd0RWMTZQUCswSnRFTE16dW5hTDJveFd6TGJGQmxsMVZLUG5ZQm5o?=
 =?utf-8?B?dFpzZlJxZFd3YmhrYlhVZzNLZHAySDlrYmdPM2Q1aGlsaVh0VFowVTVwaVZU?=
 =?utf-8?B?d2dNR21zN1VsSUs2bHlpc1VmVDgxNXc3MEZqbW81UGVobmRWZnNTNjlnUzRa?=
 =?utf-8?B?SFdJMHhCaFFMNjBNZmx5a2NOOFo0K2JldVpLMWVOdmMvaFBGc1JzM056Y0Ra?=
 =?utf-8?B?UEVJNWVuRHNoTEFraTRiUlBUdlhaYzhSeHVob3g3RVRIblJWaXYxVm1RcTMr?=
 =?utf-8?B?blBBMGVWeFVMT0hXbkxPbVpoeVJjclhmbm9XVlRkMjEvMzcrZXZ1RHRZSzlw?=
 =?utf-8?B?TGdlaHA3OXpMdGRpWk5tcCtZZnJuZkU5T216K29CbWRMNHU4VC9zeXpuM0JP?=
 =?utf-8?B?bjU0bVZVMnlwVUpERnp0ZWJ1Rjg1L1hXbExoYnZxWEdQbW9WVnd2WmIwZkhL?=
 =?utf-8?B?T1pVK2NIVjhWVzlsYlZFazIrbnZmamRTd1JTa2ZLd0RCTFlyeFJxdWpRZktO?=
 =?utf-8?B?elRLQTRnSzUwdHVBR2RWMHlQbkxaN29PbEM1RzlNSHRFUEh0ZWtRV2h4eGdU?=
 =?utf-8?B?M2pHMjR1VE1JTWNWbWhqNDJaT3ZQMHhpN0NOMEJpM2pxZndEa1huUUxnd0xQ?=
 =?utf-8?B?Wm4wUHlRTitBLzk5a08rZmhOYkZCVWJlR0RUT1lRTEhFbHhJK245ZnBvRkpO?=
 =?utf-8?B?ZFM5ZUphYW1jOXM5NjFXRUhoU2NGZGtVN1JYcTdzS2RPczRKY0t3bVA4c2l2?=
 =?utf-8?B?YzVNYnpycXpSRE9LaG9RajRCTm9Nb0tSVlJndzMxOTZXdVQ1NHh2OFliTTBq?=
 =?utf-8?B?TzBSNFRKZ0FXbmhIL1NUbVg1T053elV1c2NiWUVEWlBzaVBEdGRXYm44WVg1?=
 =?utf-8?B?WFhKYVpuTDNaUFo2RW9Ba21YMFhsTGw0Y1M1MHYwNmhlMlFOUU1QMUdrbUo2?=
 =?utf-8?B?WUF2SUc4R0ZSVWxkRWRCdXpaSndUOTAveTk2b2huOWZXYURaZ1lYajB0Y1c5?=
 =?utf-8?B?UGw0MllFYTBNSHpNVnJFU1M3aUpuNzdrV1I4ajRLaEo1bUN5TVRKek43c3Jn?=
 =?utf-8?B?VTk3TkNLeElpeWJSbVVqRElhNjFpWFdpampGTjl5VVB0Qm5RaGs3SlMwTFc4?=
 =?utf-8?B?MkVZNUhUSjd6Rmo1TXdrU3RmM0g3WEExemtjMnl3czhYMVpDaHZsUU42U2ZN?=
 =?utf-8?B?NSt0dWdzbUZkbmlJbHFGT3MrcnQvay8xWUxFbE9uVGpReGovYUpMbGFmMXRL?=
 =?utf-8?B?Z2NmS25nS3hPaXIrb0VyK21LdWpwb3h4UkR6cStCOGZWSEE4NnVOYTZCTWU5?=
 =?utf-8?B?VSs2ZER1SzRQWWtYUFZBYnZmNTBOL1VaUklCZE95YkdPRUhUWHdrOFJvNUd6?=
 =?utf-8?B?czVkRVdXbFFUR0EwZWRWWiswellTUStENUgwSDNaTkhJNmdHbFFNTWpDSCt4?=
 =?utf-8?B?UXl6NGExQ014bmkvZndlUCtqSWEzS0VGMGYzdTdURnVKYVg5K3RoNjFBRWFs?=
 =?utf-8?B?NmhMNVpmQ3RraC91Y2tIdy9BZ3d4bjVoUkxqOCt3dTdrR1drYTR0eHRidDZy?=
 =?utf-8?B?WExxSWZaR1llN3htdWxzREJhTW14NEh5U1NZalFDS2R3WWNQdkxZa05Qci9W?=
 =?utf-8?B?SUNRYWpzaFZ4MWZIRXl3ampCNGFiazBVOUg5RWZxUDZ6ZVMvYTNaU1QvT3Bu?=
 =?utf-8?Q?iq2UIz/iCHc=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?NE1qTmpGY3JINkdCVWo2MTRxUzg1eldEOHFLZFBzaTZ0UDVDMEtwNFd6ZlND?=
 =?utf-8?B?dUxiRGlYRmVlQllXVnQ0N0dkSzFhQWpvcU1lSTFER0NjdHRGUk9ObU90NUpj?=
 =?utf-8?B?YjlieWZIMEdxRFVFUmZRT1htSzA3RFhYeFprbFpnZlVBSkZ0TUxRNHdFVTl1?=
 =?utf-8?B?dUNxWFhoNjdkODkwcVJjNjlEdi9FVjU3V3N5MGFkdUZvSEI2dkhFMnBiWVI4?=
 =?utf-8?B?RW1vS2EvSFVoMmFQRXd5OVhMcXF2N1Y0aVZuOGlKU1N4ZTZiSmtXcjBLRW5r?=
 =?utf-8?B?STJiU2JwRzVPcHN0c0tBQTEzUGV6Tkd4VjkyWGhncjI5eGJDcjNPNEovOXUx?=
 =?utf-8?B?aVdoeHk5aDJxTFhBUUU5MHZlbVVZZkFwNGk1dHpBWWFYb09UQ05BRm9MTXhT?=
 =?utf-8?B?bWM4MTVQc2puVlVXVVpDWTRBK3VEU3gxZWs5djYyQXRJenYyc05VZkZ2Z2hL?=
 =?utf-8?B?OThyNlRJRm9wdk5CdWdrZ3ZyaldLTzZiaGx2STdDNGJPcEE2MkFsdGdrZk10?=
 =?utf-8?B?OHJTdHpPT0R6Mzh4UTVWRFA0dnlmaUgvOWtWU1FwM2h4SFRGallhWHh4ZmFN?=
 =?utf-8?B?VEFRbXRmQnVsZVFxOXQ1YTdMS1J0TVByZzlWRXh4Vzg4azRnSWZwVVEvd083?=
 =?utf-8?B?U3JsN2xSRTh2SUt3NlRicFlscjFSRUNneC9ZQ1NuSHNIanB6WFhJWVU3MzFF?=
 =?utf-8?B?WWNLVytFVUdqb1NjTmxUUmRDNlQ4dVVxNjNKTWlrdS9OMCtaVW9Ya0MrNWUz?=
 =?utf-8?B?S1Fpdldwb1RSbXlCVDNkamUxb1N1TXQrcFY4UjEwVGdiU3UyK2dkM1JMNUdJ?=
 =?utf-8?B?ZjJENW5uTTdUcldWWU1kaWJ4dXN6Z1dTT3pDbE8vTUdOWTRWMGQ0dTF1angz?=
 =?utf-8?B?bkFxWENKRlYvc2xza2JXQkgvZHVJZ0kxT0VSdzVrd1h1alVSeUNsUXF0WTAz?=
 =?utf-8?B?NmlydG9NbVJPeER3aHN6SHIwQUhUVGxJYUwwRTg1R2xRT3BJc0l5cFFEeGF4?=
 =?utf-8?B?cFRKQjBSREN4ZHBVOTNBY3VpMkdlSGZIWGlwWFV0Y0w4N0Q3MEo2SnlxZzk1?=
 =?utf-8?B?eElpZTBJbUtLMUg5WnNwRi81aEE0Y0M4UVlkQTNMdkhOVTZZVUhPQStKaUZ4?=
 =?utf-8?B?Wm9SVTJkZTRwRHFrSVZTclBOeFpXbGt6ckpORFpkMThyMVBqSFhCbm9sSksy?=
 =?utf-8?B?SkM5V1k5YUxxbTZPN2p1TThhMUh4bTNDbVZHNGpQaXhmQ1FESTh3WDVJclp1?=
 =?utf-8?B?d2NZSW9RRjFxUEwyd0x6M0tya051T29jazVnOXkvNFdGN28zK0RLSXNEM3V3?=
 =?utf-8?B?aHVWODBFNEZlZUVkbFAxa0VUS1lzMTF6MU5mRjhiWlZwRjlsQitrSDcvVm5z?=
 =?utf-8?B?cWNpNzg5M0lzSnVYM3FBdGhvZ2s5ak9yR2Y5M25La0ljWUJzVytFc0g1Z3B6?=
 =?utf-8?B?QTZ1STBUcTBiaVdLOE5YQkZyNW9PUXJpWXpTUnE5UHRjbGY2ZDRuREV0Z21u?=
 =?utf-8?B?N2EraDNmTEZNc0dGMUwxZTlXV2JnZ0t0a0duZzFQZEM0cVFKSEgwZmJaT0xq?=
 =?utf-8?B?MGFXZ1BVSDdhNURqdTZvdndPY0lVU3lrcjg1RU1QaUJFSy9zcWhDNDZncGdT?=
 =?utf-8?B?bC9PdjVzenlkZ3hZM1djeDh1RTVudlZjaUlaS1o4TVhlYzlIY2ZjdkoyODVv?=
 =?utf-8?B?dWNWY1BiUGF1dTVmclBoVWx1OXdBMXo3Zk5idldiNHMzUUtVZnRGWTBNMWVT?=
 =?utf-8?B?NlR3UHNETnlFQWFHYzhBQkNuY0N3SDR3RDF1TFByaW9SekNhZGtocExyZ3Zl?=
 =?utf-8?B?VnJhaWFyOHM3NFZ2em9CQisrVzE5Ri9hZXVpUmxIYVJRbWhMdW1PMG4vb2pX?=
 =?utf-8?B?NW5DQVgrSEd1Tk16cVlSQ2oyMjBNd0RRUXZhYTJXR1FhR1BlY0g2SmlUWEpi?=
 =?utf-8?B?KzBLQXdZcVlZdktCRjFSNjd2aXZIZisyaTFySS9VeGlDSDQ4SXliTUY3MWY0?=
 =?utf-8?B?RWpqa1loMDFXd3hwMzkrbkxBaWcxRmdyczR3aHlLZ1NSYXV1dkNiSndHeWo1?=
 =?utf-8?B?K2FUWXA0Rkxsd2xVWkcraG0vS2hPb2Q1em9oelBRZVZTNmtvUWZ0RGNrMlVU?=
 =?utf-8?Q?0VZU=3D?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a98e60cb-49d3-479b-c689-08ddb25a9c00
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jun 2025 13:33:59.3064
 (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: aaBLkQH5wjVqOBcZBS6XWn53hL3RvD1R4NgRMJbmGluQZ2xlT5Lt0mg3AcoJRMn2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR12MB8463



On 21/06/2025 17:11, Koichiro Den wrote:
> This is preparatory work for the upcoming commits that implement the
> standard PV time interface (ARM DEN 0057A).
I personally don't find such messages useful. If at all, reasoning should be
given first and then this message could appear.

> 
> No functional changes intended.
> 
> Signed-off-by: Koichiro Den 
> ---
>  xen/arch/arm/domain_build.c | 29 ++++++++++++++++++-----------
>  1 file changed, 18 insertions(+), 11 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 4ff161887ec3..9d44b6fa9470 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1070,6 +1070,23 @@ static int __init find_host_extended_regions(const struct kernel_info *kinfo,
>      return res;
>  }
>  
> +static int __init find_unused_regions(struct domain *d,
> +                                      const struct kernel_info *kinfo,
Let's not propagate unjustified (IMO) behavior of passing both domain and kinfo
pointers. The latter contains the domain member and therefore is sufficient as
argument.

> +                                      struct membanks *ext_regions)
> +{
> +    if ( domain_use_host_layout(d) )
> +    {
> +        if ( !is_iommu_enabled(d) )
> +            return find_host_extended_regions(kinfo, ext_regions);
> +        else
> +            return find_memory_holes(kinfo, ext_regions);
> +    }
> +    else
> +    {
You can take opportunity to drop unneeded braces

Otherwise, LGTM.

~Michal



From xen-devel-bounces@lists.xenproject.org Mon Jun 23 13:40:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 13:40:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022349.1398133 (Exim 4.92)
	(envelope-from )
	id 1uThPh-0002ro-SS; Mon, 23 Jun 2025 13:40:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022349.1398133; Mon, 23 Jun 2025 13:40: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 1uThPh-0002rh-Py; Mon, 23 Jun 2025 13:40:45 +0000
Received: by outflank-mailman (input) for mailman id 1022349;
 Mon, 23 Jun 2025 13:40: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 1uThPf-0002rb-Pe
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 13:40:43 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on2060a.outbound.protection.outlook.com
 [2a01:111:f403:2414::60a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a7ac38db-5037-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 15:40:42 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by DS0PR12MB9345.namprd12.prod.outlook.com (2603:10b6:8:1a9::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.25; Mon, 23 Jun
 2025 13:40:38 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8857.026; Mon, 23 Jun 2025
 13:40: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: a7ac38db-5037-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=xTPCB+nYaFTGcrx2s5uYEVOnZ5sbp1/IWB8NzHdLNRV0b4EFS1Uf4EC7hitB17e0ftZbmQyzQXHmSOCljQSwPLugx+goDw+eAPdhCMGUalrzABKw/m/9UPzyRko3f+ldnJlqFgRlLELNSXSu88DU3Tq5LJN9cJCVH2SaHfJ8D5rqARyfBR6jzB9F+Vpo+pDEk9RCLgUHYTu1uC/tQenC1Fi+AHzf8htP0yafzmYx83ul3qQJELF753hJCpom5dp0WW5ER5/kDBw4QrEwizRBq7ltSlJ03CuQl3FKiFo6avTzshBkUrL0v4mATlKRWPno7+FvEp3bFhWFB19y2wBQpA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Ac2p6PoWZHUM3Ak080aYAAP/+ZaNy8jHvKiAwMtGhe0=;
 b=vY694uFDeoZgaQHC09EP4960GDtT2ttDN4RRQ/9hnVCDnnImrjW6F71A1J9ldmUSd2XmRAKMgJlDFOjJrPwJNnagNYHxA+o9M8WMgjWEKFRVC61KE3a5s3StlSOQ1TZuWQXbWA9ItbKl4ZOyAuwX6EueAr+lCziOK1iqento/CL3/YAi1wLonwhElLdKazaRRKcUWc2l+duPpVyb5U/E4UKzhGIJpoRAPt54agNSpuuPHc4UGs1TkZxgadZFUTYGdTZCaQiHtTeJr7YLsEKuLhHrVyvKEZ0MbGmphB0HSfkXdezk9/Tp7qrCnPX8Cpj9ZCvGUW9KR2V4MiCOGrD6lg==
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=Ac2p6PoWZHUM3Ak080aYAAP/+ZaNy8jHvKiAwMtGhe0=;
 b=r1KsahY/rZYIuc0wwciKyDYwQ7yVL1QRjtW1PWckpM+VwfpymemUDdawDkMFaVemctKUx8PM8QBCRnGZd6+ob4GJcUQxsJUzAwME6DRMMJYry9/PmYAp3Iv8YSPnSpo13yvuNZ74Fbb7d4l8aWw0P3AKyu0Mbo2uJ2PkeIWFK0Q=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <8e6ed078-9ab9-4f6d-91f4-cbeb74f2c5fd@amd.com>
Date: Mon, 23 Jun 2025 15:40:24 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH 2/4] xen/arm: Move make_hypervisor_node()
To: Koichiro Den , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250621151201.896719-1-den@valinux.co.jp>
 <20250621151201.896719-3-den@valinux.co.jp>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250621151201.896719-3-den@valinux.co.jp>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: CY5PR17CA0059.namprd17.prod.outlook.com
 (2603:10b6:930:12::23) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|DS0PR12MB9345:EE_
X-MS-Office365-Filtering-Correlation-Id: 097bfeda-a6bd-4c83-b901-08ddb25b8a2f
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?Qk4yNzdQd2dRT1R2a3hFUnBlQlRrT1BoTzBOWGpmVFJuQW1CeUROQWxCbnVH?=
 =?utf-8?B?S1AyNEVXWFhWNnRQMWZXa0hxU2NYWWJDQzB6NHZaOXFJWmM0bDVhbWQ3Q1l0?=
 =?utf-8?B?V2xNVFlVNC9tWmJCRUJWb0JseHkrSnZSdEtDYnlFeXFPaFlXWm0rcFJmbVlH?=
 =?utf-8?B?Z2JiUDdocUdmRzd2UDFxT1habTZhbkdrdnU3U1h5MVg5SUhtdDRWcmZhUU5l?=
 =?utf-8?B?eG9nYmdIZTVYMmlEcFRHcys3UDhrdnN1VG9QMzhuUmdMUEhyWVdWRFczR1U4?=
 =?utf-8?B?ajNVMU8xNFhValFteUR2NFpOdWRDczlPaEx3S0dOSXJrdjl1c01oWnMySnU2?=
 =?utf-8?B?SGVBUFMwTFdZQnRaczZJMHk1YXVtTVBrT1ZRSE80eUJEQUNFNFp3dDBRVllu?=
 =?utf-8?B?Sis1ZzNKMmhNeVU4N2FkK0VjTkdybjl5SHNZaXpzUFVxcTBKcU5ybXU3aFhB?=
 =?utf-8?B?Vi9yZVVXUjVxWkNwL2tCM0lwZFpjQ2ZLQysvOVdqaFNwT3pxVFdQODA1SFky?=
 =?utf-8?B?bWcxUHlPejBaVE1CUVlDTEVoNjMzVm1rVlpHRXBiWXp3NC96ZVg1T0J6ZEpk?=
 =?utf-8?B?NHdVT1lZNEtkM0d5dE9iRjJ0c2lTaHZiL3RYSEpWN1ZraE1OV25sdGZRREpj?=
 =?utf-8?B?c1BNUGRISW1MSDV6YUVTZ2hTN2MvQ2dnM3hYRDBGSW80VGFEaTRxejNvb0Ju?=
 =?utf-8?B?ZFM1bUZKMjlpbk5NVWlUdVhvbzZlSDRoWEVzT2pFTEpLNHQzYU9FeXVUbGg2?=
 =?utf-8?B?bEZlVFRsU2o2S1c0ajlrUU9ROWNBS2xPakVKZHg5K1NkU2VoOU1MemQ2bk1i?=
 =?utf-8?B?NUg0aER4em5KNkc4L214Ni84YnovTS9WVEh4d2JPWUgySkhsSmFGQzVuMGE5?=
 =?utf-8?B?ZThpc0txMXZkUCtxdUlQaXUzMFlzL3ZkUHZ4WFBxUy9tK2Y0Q0xtWmhkV0E5?=
 =?utf-8?B?V3YrdmtpTmpONEN5V0xyaE1CcU05Zzdpbm1qSm9ESHBTT1ZVWGs4ZTdZemVk?=
 =?utf-8?B?K3BVcnlYYTJPdEl1elpvQmVhc1BRU2lEM1ZCN0Vaak9VZXFOUHpCOEgrc2pu?=
 =?utf-8?B?S2tHdEtFSWZxK3Rld0ZIdmdiOW9odnRtSnJTSHljUllhM09hcEJ0Q2VYdUF2?=
 =?utf-8?B?dE05TUxNeUJXSURSa1Fpc3E1L2JMbXpMeFhEc3FPdmx0OFpWRVg0RTY3dzRa?=
 =?utf-8?B?QkdVbnREL3lFdTFqYWIwRkY3bzlIL3UybGhFeTdXNmU0WXd5SDRpaTVqWjVI?=
 =?utf-8?B?dzZ5SG44eThqRHJTR2NoVmVUeTU0aW1sU3l2aGFHV2VGb3ZJdnlyVEhFMHpH?=
 =?utf-8?B?WjZ6WmZZQm9HZ0NwS0FGTDNLUmRzUExoTjgrNktpdDZlcjkrZER3djA1aEpC?=
 =?utf-8?B?M0pKVXdYM3VEelFlU0tmQTB1MXhIUmJDL1BuRElvTUpPOGl5T25YcjZkNXM3?=
 =?utf-8?B?L2lOSUluQWpJUEJrNDN3Y0dWVUpMdnNydzF1eXZBQWRTMmhPNlhjMnR4YTdO?=
 =?utf-8?B?QzU5OHQrTnNQNzh2TTFkclZlUktNelRKRjR6MldTdVhzajR1MENRQ3hOY29z?=
 =?utf-8?B?V0VodURPTGE4U2IzbkFJcHRpY0owblBIOXRtU1ZMZjV4Sk5EQ2UyWXFtZkhm?=
 =?utf-8?B?SVhXekdGcXFMTUhTRjBWVnJKSmQ3c2NUMHdXRFZ1LzZCWEpSUFZ6bXR0RERo?=
 =?utf-8?B?alliaG15TUhwNmFzYVhTTFdJL1FHVGk2ZGZTRnlRa0NNZ0dac2NRYVBzVXBI?=
 =?utf-8?B?c24xN2hlOGNhc3d6Y3VBdWRBWFdDaWdtM2xrWGFJYTJKVCt0ZjBEWi94VGN5?=
 =?utf-8?B?WlFwdVVGV2F0cjQ0bHRIZmpPcS80K0w4OWwzWlFZaDQrN0tuMUxqK0pYVzZj?=
 =?utf-8?B?cXJzSXlBLzN3Zm9vMHlOTU5vdGVPTTdpaTlYWjJ2bGhVVHlGbjEwSmtRd1hn?=
 =?utf-8?Q?WnDk7C6KBjw=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?eUhiMjg5TlBVaHpXNEhWcG8rV0hYL2ovME56VFlHMU1GbjViV05YRHJKYzN0?=
 =?utf-8?B?WVFxUC94VXlKM3B5ZG43MG1qaE01S2l5bmJMdEhmMk9NUUxvcmFmMDNSdEVj?=
 =?utf-8?B?RTV6WU1LMUJzQzhVWE96c1BpZEhGUTFZejNjRU5YM0xyclE4NmJHTkU5ZlBJ?=
 =?utf-8?B?a29wanhxY3pkRTF6V3N5QXUrUExYek9WOERKVGoyb25lOC8zRmlLZEZtZkFa?=
 =?utf-8?B?UTduYUI1M2ZHQkQvQnZXRkV3KzhqekZMTTM4ME0yaHhkV0hCcXZ3WWloVk1P?=
 =?utf-8?B?K2xJeFdRdVMvZWxwa3dqb3phU1pxZWpEbW05SEdsSkE5elRxdHBBZVRhZGJQ?=
 =?utf-8?B?VXJ6UTBlU2RtVTREYzEwOTUwWUs2UHJJTk1JblcyNFRkU293cWgyWnVQQmU5?=
 =?utf-8?B?WlVnWDUxeFNkKzJCMGlYWlBBQmFIUkpxMUk2S0IyU3oxZnN0TStJamt2Y2da?=
 =?utf-8?B?Tk5McVd2T2JQemp0VnhUTkU4cFZXeFVnTE1aUG0yRlhBblFudGtVUk5GeE8y?=
 =?utf-8?B?N3pNdEJqT3BqQ0RiZ3MxZXpuaEZpL0NCS05KREdLUjhndXlsWE5TMlpkcERp?=
 =?utf-8?B?eWVrWEw4VGt0a0tNWVh5cHE4WEQ0OFVHaDBmRyt2bXlkbmRuZ3phSWh5RTRU?=
 =?utf-8?B?b3owYU5pUUtmbUliNE9Da1hHMncrZWVQUWJTVWdEcW1WdlNaQ2trMm4wTkZC?=
 =?utf-8?B?Sk02V1RiWmJxWjBkWEw1MGova0F5NGdGWWNYaUl6dE9RbE4wOVJqQVV2RVd5?=
 =?utf-8?B?dlE1dy9OZ0c4OHdyNmxrcUJ6bHZ4MEUzbE9jeWErRzM2OGYyUHJ3cFNzV05S?=
 =?utf-8?B?RUxiaGkzYWpUSUpCV29XaEpLZ1l3enF1bTJGTTdmNDVQVHNicGx2T0l0RUNP?=
 =?utf-8?B?L3k0MEN3bVN6WC9XR2c1UmIxVE9ucEFVekFNd3JoM1BQem1OUXhsMXdlRTd4?=
 =?utf-8?B?VHBaRmp1MUhoWGNQR2p1SS9kaU1rZ1NEUVhVaCt1amVhWTl2ZHVzL1RJWVUv?=
 =?utf-8?B?TW4rN0VVbXZUcm0yVDZ0MGd0TkJTM011Q0o5a1prNTN5OHRIQnhwRXltcE81?=
 =?utf-8?B?WURMbFMyajNXZU9GMzViRERndlFJdkNNTEd1RGs2dTBqVis1bEdEN29zZGh3?=
 =?utf-8?B?cml3aE1DL2lJbWNrVEFZVC9XYXRXd2hMbTFEaXNEZm1OS0hOdVZ2ZDJXRWo5?=
 =?utf-8?B?NDBlTXZ3YktJdjJDa2g4Y2RXNmsxWWp5M2l0TGRsT0JqNXJNK2NGcldPTGpn?=
 =?utf-8?B?VDdXQm5ScGdYQ2RsN3BlNXhqUEw0dnJnK09IaS94UlFsSFM2NnhiZGhQUG5K?=
 =?utf-8?B?aGlMb1BwWk1yRk5PVFNFZDZ0SFVocHIwWDB4OUFqOE53R0daR0hzdzFXazdK?=
 =?utf-8?B?ZGlBNGhqZWhhRmdRSFhjLzNhZVcxK1dmcktqenY4Y1p4VHFCU3hXNzN0Z2dP?=
 =?utf-8?B?bm1NUUp2YzNKd1J2KzdSYlNQYXFhWnVDbmdQcytyTWdHYVM2WXp1cGlJT2pr?=
 =?utf-8?B?MkN5NDFPWVdKZ2w4M3pOekZnT1FwTTBvaDM1L0xqQWJrcGUxYzVZOStQaVF2?=
 =?utf-8?B?bFBrMjIvOWxTWTdsVWQreEk0dWtuUk9LZldLa215L05tbXMxR2VtaktHQkRR?=
 =?utf-8?B?Tyt4R0FiNjA4b2lNeWFBWmZqeXk0TDE4RFNMUGhzQWFXT0RMbE9OS2NoUk5V?=
 =?utf-8?B?YW5hNlJ1d1RaUGRwT3NZVGVaRWtITzY3Y1Y5bVFVRHAvS09xS3FwQzBDMyti?=
 =?utf-8?B?b2NvRFZ3a05HWW9MUklGSGk1R3BnWnhiZFd4bVNRcDBEMmVtSDdnQnJDdFdD?=
 =?utf-8?B?WHpVbHZhN28xOHVSbVdBdHNwQnA1U2RZNUY2blloc3BHVGlCcDJIM0R6cFZ2?=
 =?utf-8?B?aEJiMTQ5Rkw2VUJtbGk0bTEyTWJNMkhzQjdZRWxLOVloNTBsSjdCQXR6VzY4?=
 =?utf-8?B?anA2TEdjSWlWdWVaUXUrY25ubTRJUmFmQW9ockNGSWFuL0ppQmtUQ0p6a09k?=
 =?utf-8?B?QTZCWE15alFFRXpYQ1dqMHF4S0dQZHUvOERNQ1ZuUnh1cFZlM09HVWd5Y3BK?=
 =?utf-8?B?T0hqdmY3dDRpOFVONVo4eTJyT2RMSWFUbyt4a2VYK24vdDhlVk5zMUZkbDRH?=
 =?utf-8?Q?wUcc=3D?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 097bfeda-a6bd-4c83-b901-08ddb25b8a2f
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jun 2025 13:40:38.8291
 (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: /1InwAzCE9b2HrJyyzhtXQMH4xUQ4lof6RkMtvmYBSwTiDV7/UciYySkmsGCAnC0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB9345



On 21/06/2025 17:11, Koichiro Den wrote:
> Even though make_hypervisor_node() does not rely on the /reserved-memory
> instantiation when calling find_unused_regions() (the wrapper introduced
> in the previous commit), the next but one commit will use it for PV time
Unless for specific reasons, you should not rely on which commit gets committed
first. Hypothetically there could be a different patch committed between this
and the next one in your series. That's why it's not a good practice to mention
order of commits in the commit message.

> shared regions, in addition to the existing extended regions.
> 
> Move it as a prerequisite for the commit after next.
This one is particularly not useful.

> 
> No functional changes intended.
> 
> Signed-off-by: Koichiro Den 

Other than that, LGTM.

~Michal



From xen-devel-bounces@lists.xenproject.org Mon Jun 23 13:44:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 13:44:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022359.1398143 (Exim 4.92)
	(envelope-from )
	id 1uThTU-0003dd-Em; Mon, 23 Jun 2025 13:44:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022359.1398143; Mon, 23 Jun 2025 13:44:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uThTU-0003dW-CD; Mon, 23 Jun 2025 13:44:40 +0000
Received: by outflank-mailman (input) for mailman id 1022359;
 Mon, 23 Jun 2025 13:44:39 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uThTT-0003dQ-DS
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 13:44:39 +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 3480c216-5038-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 15:44:38 +0200 (CEST)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-43edecbfb46so28823135e9.0
 for ; Mon, 23 Jun 2025 06:44:37 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b31f118ecb2sm6827425a12.11.2025.06.23.06.44.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 06:44:36 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3480c216-5038-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750686277; x=1751291077; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=LQPecrdmbgZ25c522j1wyItnkdmk25j+WVLoG09o1pQ=;
        b=Gyq3tPXB4JHf01B2Qf9fM9an9HbdncRU5cdqCYtBK8GaFo5gSj/X2heXaNcCWWwIr8
         /pyTB0HOZexvvrbjBlxkEbiZ5x32JVNFyXYeKcbGYPa6XbWJ6HZNsY8fRMbGBLyaUmsh
         S37pk0Z32uiiXs6U7aY1eoecu8h+hiF6dIzIi/IgtQCDDKBgHwQJxDhOdfhK8nBkr+D5
         2EE8306iOQfv3yIwQ/4T5QOXlMBK0s9JDJhLPrAZA6PADZXC1AevNBx5biUqpxpwRka4
         r4aRWpGJuzIbqgkcjcdVzlf7CBvKCzYdeLvW3LUQuVmDMQWkw5Wu0ONCCdiYDwNisdTc
         +xQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750686277; x=1751291077;
        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=LQPecrdmbgZ25c522j1wyItnkdmk25j+WVLoG09o1pQ=;
        b=OPFlup+d50Hr5RqRkoBGPbFaQoxV34jxutXFImkHOjPT3VAGKq97TE2qSQ7ST0yLRd
         izUc4jkSiGEVi/SI21SOWxttjZOzNHTt+5agG79WBRh6f4u/N9Epcgmt7kpuOYtqfTiR
         q1DIoYEH0LtMZ3wgsu460beUrkO3EXh85SuWpL7rujgJtIIObMXSH2mXuUE8EJ8xZC5/
         XRzfzehxzp68u5EubTyYLHIHhgPYScSLeveDM/N7STG5oFeHicW1s8OIiJNnJM3+WNpB
         iEe9IiQj1ldP8WA44HK+nRGBHfjBw/YtTx18R2XqJeYbdnczc64jMzWruOXca8q4byVK
         RZ7A==
X-Forwarded-Encrypted: i=1; AJvYcCVtjy/lUH6WtZZ2PjXgyIhxMDf8t5l1Gw+5sRRETKiEkv7vlssssLDRS+JlgnZ2TJ6c+akx7/WjzlA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx9aVf3tloLhPLyAXnOHjTVPoJq6nxcccqqiNickuSdEOD8evKr
	PxtNRKCenGoJ2xmU64p9r1weJooArlJSr8ry86c/+2iG3OcQQbPTf6jnmcaXfQerow==
X-Gm-Gg: ASbGncu+cEDEGqTGPMh7GJrYBUhuU+VX3c+H+HTFh9xMso6izKcJfi5e7nUykPNrcQZ
	AG1ORvqWy4s2PFMiGQ8lGPVz+FPeDxGJaJ7/g1NLPARGbvJdp3Eqdvx9qCws2LQpm7M/bXEw1z9
	reKhD/mU7Yu9FFTlTVdrP/ZFyViDX0DiAEsPvoiCdlQ82X0mFlsDpVZCP+hznJUHCHpP6QoGis/
	rUn44sSjzax86wP5WmLly3fFkysmYUazsaewichhaC7istByyvO6ifuY2CI9qDxr4hhpk4k1sQv
	jCN/QPuCY9m55tIL+FfiAkknqbSlzM906cRxrR9qp7cIxLCDRQ22pqXFW/5LolRi+p1WOFlc+Af
	3ViWFyh2D7SHO7Kv7aYErQXXUqrOSw+xuubf4/M6DZutoTBgTw74285u34g==
X-Google-Smtp-Source: AGHT+IFhBt14bJfQcmQAoN78AIKYry2UwRWPE8zdvNZkBiSC33sz5PvDOopRiYm/Nx5DO6r413CqGg==
X-Received: by 2002:a05:6000:480f:b0:3a4:da87:3a73 with SMTP id ffacd0b85a97d-3a6d12dee06mr8007138f8f.42.1750686277206;
        Mon, 23 Jun 2025 06:44:37 -0700 (PDT)
Message-ID: <1fc40753-727e-408c-940e-07f3efe1ef48@suse.com>
Date: Mon, 23 Jun 2025 15:44:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 10/12] xen: Rename CONFIG_HAS_DEVICE_TREE to
 CONFIG_HAS_DEVICE_TREE_DISCOVERY
To: Alejandro Vallejo 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk ,
 Shawn Anastasio ,
 Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Oleksii Kurochko ,
 "Daniel P. Smith" ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , Dario Faggioli ,
 Juergen Gross , George Dunlap ,
 xen-devel@lists.xenproject.org
References: <20250620182859.23378-1-agarciav@amd.com>
 <20250620182859.23378-11-agarciav@amd.com>
 <490ee7bf-cb10-43e3-9416-9a68e7529b96@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 23.06.2025 15:11, Alejandro Vallejo wrote:
> On Mon Jun 23, 2025 at 9:39 AM CEST, Jan Beulich wrote:
>> On 20.06.2025 20:28, Alejandro Vallejo wrote:
>>> Moving forward the idea is for there to be:
>>>   1. Basic DT support: used by dom0less/hyperlaunch.
>>>   2. Full DT support: used for device discovery and HW setup.
>>>
>>> Rename HAS_DEVICE_TREE to HAS_DEVICE_TREE_DISCOVERY to describe (2), while
>>> DOM0LESS_BOOT is left to describe (1).
>>
>> Considering hyperlaunch this feels wrong to me. Did you consider splitting
>> HAS_DEVICE_TREE into HAS_DEVICE_TREE_PARSE and HAS_DEVICE_TREE_DISCOVERY,
>> as I suggested on the committers call? You weren't there, but Stefano said
>> he was taking notes.
> 
> Some might've been lost is transit, I admit. I don't remember hearing about
> a HAS_DEVICE_TREE_PARSE, but it might've very well been me being spotty when
> syncing with Stefano.
> 
> Having a special HAS_DEVICE_TREE_PARSE doesn't seem very helpful, as every
> arch would have it set.

Hmm, yes, we don't want or need that. But then what's option 1 about? That
shouldn't be "described" by DOM0LESS_BOOT.

> I'd definitely like for the "enable support to boot
> several predefined domains from DTB descriptions" to be a single option for both
> dom0less and hyperlaunch. And be selectable rather than unconditionally selected
> And ideally move towards a future in which both dom0less and hyperlaunch are one
> and the same.
> 
> I can do an early rename s/HAS_DOM0LESS/HAS_PREDEFINED_DOMAINS and s/
> DOM0LESS_BOOT/BOOT_PREDEFINED_DOMAINS/ if that helps. I was waiting to do so
> until x86 gains the ability to boot off a DTB to avoid having help messages
> describing things not yet on the tree.

I have to admit that it's not clear to me if that would help. As you say, on
x86 that's not a thing just yet. What I think we need to aim for is to not
leave the tree in a state that's more confusing than anything else. Even if
later (which may be much later) things would get tidied again.

>>> --- a/xen/common/Kconfig
>>> +++ b/xen/common/Kconfig
>>> @@ -14,7 +14,7 @@ config CORE_PARKING
>>>  
>>>  config DOM0LESS_BOOT
>>>  	bool "Dom0less boot support" if EXPERT
>>> -	depends on HAS_DOM0LESS && HAS_DEVICE_TREE && DOMAIN_BUILD_HELPERS
>>> +	depends on HAS_DOM0LESS && HAS_DEVICE_TREE_DISCOVERY && DOMAIN_BUILD_HELPERS
>>>  	default y
>>>  	help
>>>  	  Dom0less boot support enables Xen to create and start domU guests during
>>> @@ -85,7 +85,7 @@ config HAS_ALTERNATIVE
>>>  config HAS_COMPAT
>>>  	bool
>>>  
>>> -config HAS_DEVICE_TREE
>>> +config HAS_DEVICE_TREE_DISCOVERY
>>>  	bool
>>>  	select LIBFDT
>>
>> This select imo ought to move to HAS_DEVICE_TREE_PARSE, unless I misunderstand
>> what LIBFDT covers.
> 
> Doing so would preclude compiling it out on x86 when hyperlaunch is not there.
> LIBFDT is very much essential on arm/riscv/ppc, but not so on x86.

Okay, but _something_ has to select that on x86 as well, once hyperlaunch is
going to need it.

>>> --- a/xen/common/sched/Kconfig
>>> +++ b/xen/common/sched/Kconfig
>>> @@ -67,7 +67,7 @@ endmenu
>>>  
>>>  config BOOT_TIME_CPUPOOLS
>>>  	bool "Create cpupools at boot time"
>>> -	depends on HAS_DEVICE_TREE
>>> +	depends on HAS_DEVICE_TREE_DISCOVERY
>>>  	help
>>>  	  Creates cpupools during boot time and assigns cpus to them. Cpupools
>>>  	  options can be specified in the device tree.
>>
>> This similarly looks wrong to me. Whether to create CPU pools is purely a
>> Xen-internal software thing, isn't it?
> 
> In principle, it should be HAS_DOM0LESS and likely will be later when I hook it
> for x86. I was waiting for x86 needing such a change to use the binding. Would
> you rather have the change done now?

See above - my main concern isn't with what is introduced early or later, but
what the overall (intermediate and final) state of the tree is going to be.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 13:46:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 13:46:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022366.1398153 (Exim 4.92)
	(envelope-from )
	id 1uThUp-00049D-OU; Mon, 23 Jun 2025 13:46:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022366.1398153; Mon, 23 Jun 2025 13:46: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 1uThUp-000496-Lt; Mon, 23 Jun 2025 13:46:03 +0000
Received: by outflank-mailman (input) for mailman id 1022366;
 Mon, 23 Jun 2025 13:46: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 1uThUp-00048y-0V
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 13:46:03 +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 661cb234-5038-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 15:46:01 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3a6e2d85705so508813f8f.0
 for ; Mon, 23 Jun 2025 06:46:01 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3159df71ea8sm8975409a91.7.2025.06.23.06.45.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 06:45:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 661cb234-5038-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750686360; x=1751291160; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=gjB7LXNA11ANRGLY6mxcZIWZHspd3cLci/CHRCIPqC0=;
        b=eIpDJOFDCS0wgwpznZpq95KKc/HtsKOj4rJkmkkDOod/ugUGzhazVboT2uzpspkEYU
         t27EVvm7UV8azFPdMmnX6+nBjmo3nq0ZVALl9xk5VSXSMeakRFrg3AzT4Vw61HhQGoxt
         /lMb+K18N1o3amJNJB4xrGeikfXR7FDLGYfptAuXvAbwQsyJwcU5UDbCu+xGygbRWzUI
         +lzdgWDDIykBU4cO/C1JgkFfuIQtQPvisI8ZJgpwpXxl1hupPM8VDSXWPRQ+eD1QT8FE
         hgTVaJ2Sq4+c4x0UnHIXk9QCdZ11n+gKsOE7lYgQjR0RpLjf6+4Z6Gxb/q3keCxRUCgA
         LW7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750686360; x=1751291160;
        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=gjB7LXNA11ANRGLY6mxcZIWZHspd3cLci/CHRCIPqC0=;
        b=iNHC+zz09Ziid+Adfv7aUUExysfAAK/jXjLSBFWmx9AuPzpV0diH/Suej9FmyfYILG
         F03oNcGoiUIanF+Hgb9Z5j+OzhVpomI0lh1uzDKnffsop5VLuiRKwdP9MqNAa0CbpuFh
         gMeHRNOmNDMG21DHf5wO534v0aBExytoK7/8cvKAnyAIvnlIQTBTRMrDCIt306fa/muN
         HYy4XuyOp1rKGobcS1luXY9KV2jJrXJj2h7OyWOOPsYIAIfJg1H86GYKd5PayEOo0TmW
         KiOmn3vrFhvBFNJtk2Y9EKibvn+srOhNK4crd3kD8BRYpve4mkkCcPvcEihPtlmR93BT
         mUZQ==
X-Forwarded-Encrypted: i=1; AJvYcCUAEjXG+clQhYRUQhzh7BX9Wj9QDeWISMfepNJXp9HGzcfV5thaGvdoRlWcWLCn4cSQxaHM+nm+ILs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzKLut+F9qypQ5009oUWl4qyPmzihdaYP66QvIlXNpSlkvs53rc
	8O+XRoQCm2+omFl3b+sAoaV7Ge+1+4g0DhNL2jgahuXRPW7yOM+WUwH3TZus62SJ9Q==
X-Gm-Gg: ASbGncsv0FgBc1op8S7KJDD5shVEdoTh0l5saV32lIbOSgq27pstduBnUf+HiNu4hm+
	vDsSWP3nkQasYAAw/EES8UPIXEFnvCbbygXWyjuiPfLEcfm11esaIGQ6wgSWTHea8ABM0IRs8+W
	6byOD8mV0AOrqSozULV9PXKHkcw65Hz2xvoJUpww2jT71Fz0JTRy0XgkhTxXltLiRelFG3fIp5h
	BVXivwFqsZodRZvtRXTwP1QfylReu7+DIB1hPHtonWtl1eQTAKpsQFkKcRxLkpj4SJyRgjaVa+0
	RfOdTTpzA4xkDONXDOCH6DUl4Dljn0HGz2vqJC6BR0slmIpiZqqadXsi4pwIAfKLvQ+GrYDA9j+
	bS5DlC2YbkmSxVV65x5jcf3uDfkSZr+5JrOYnZpT+O2tu9Pg=
X-Google-Smtp-Source: AGHT+IFx76gsozdaKi6xjmh/Nqqv2oX3gQsULzt9gRpwwJp/FB2dcXYZNh/9y6RJvhlUo6mKFxaBVQ==
X-Received: by 2002:a05:6000:461e:b0:3a5:2949:6c31 with SMTP id ffacd0b85a97d-3a6d12e1a29mr8976507f8f.42.1750686360564;
        Mon, 23 Jun 2025 06:46:00 -0700 (PDT)
Message-ID: 
Date: Mon, 23 Jun 2025 15:45:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 11/12] xen/dt: ifdef out DEV_DT-related bits from
 device_tree.{c,h}
To: Alejandro Vallejo 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel , xen-devel@lists.xenproject.org
References: <20250620182859.23378-1-agarciav@amd.com>
 <20250620182859.23378-12-agarciav@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 23.06.2025 15:18, Alejandro Vallejo wrote:
> On Mon Jun 23, 2025 at 9:44 AM CEST, Jan Beulich wrote:
>> On 20.06.2025 20:28, Alejandro Vallejo wrote:
>>> device-tree.c stops requiring CONFIG_HAS_DEVICE_TREE_DISCOVERY and may
>>> function with DOM0LESS_BOOT.
>>>
>>> Without this, there's a clash with x86's definition of device_t. Because
>>> x86 doesn't discover devices in the DT it can simply skip the code
>>> to do so during the unflattening phase.
>>>
>>> Not a functional change on architectures that currently use these files,
>>> as they already select CONFIG_HAS_DEVICE_TREE_DISCOVERY.
>>>
>>> Signed-off-by: Alejandro Vallejo 
>>> ---
>>>  xen/common/device-tree/device-tree.c | 2 ++
>>>  xen/include/xen/device_tree.h        | 4 ++++
>>>  2 files changed, 6 insertions(+)
>>>
>>> diff --git a/xen/common/device-tree/device-tree.c b/xen/common/device-tree/device-tree.c
>>> index 725ff71646..741e2ce585 100644
>>> --- a/xen/common/device-tree/device-tree.c
>>> +++ b/xen/common/device-tree/device-tree.c
>>> @@ -2029,9 +2029,11 @@ static unsigned long unflatten_dt_node(const void *fdt,
>>>              ((char *)pp->value)[sz - 1] = 0;
>>>              dt_dprintk("fixed up name for %s -> %s\n", pathp,
>>>                         (char *)pp->value);
>>> +#ifdef CONFIG_HAS_DEVICE_TREE_DISCOVERY
>>>              /* Generic device initialization */
>>>              np->dev.type = DEV_DT;
>>>              np->dev.of_node = np;
>>> +#endif /* CONFIG_HAS_DEVICE_TREE_DISCOVERY */
>>>          }
>>>      }
>>
>> Without something said to that effect in the description, this contradicts
>>
>> obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += device-tree/
>>
>> that the previous patch put in place, and that only the subsequent patch
>> will further change.
>>
>> Jan
> 
> Would replacing the last paragraph of the commit message with...
> 
>   Not a functional change because the whole file is gated by
>   CONFIG_HAS_DEVICE_TREE_DISCOVERY already. A later patch allows the file to be
>   usable without it, for which this ifdefs are a prerequisite.
> 
> ... help?

Yes, afaic.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 13:47:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 13:47:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022372.1398163 (Exim 4.92)
	(envelope-from )
	id 1uThVo-0004eP-1g; Mon, 23 Jun 2025 13:47:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022372.1398163; Mon, 23 Jun 2025 13:47: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 1uThVn-0004eI-VN; Mon, 23 Jun 2025 13:47:03 +0000
Received: by outflank-mailman (input) for mailman id 1022372;
 Mon, 23 Jun 2025 13:47: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 1uThVn-00048y-1n
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 13:47:03 +0000
Received: from fhigh-a4-smtp.messagingengine.com
 (fhigh-a4-smtp.messagingengine.com [103.168.172.155])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 893a86a0-5038-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 15:47:00 +0200 (CEST)
Received: from phl-compute-05.internal (phl-compute-05.phl.internal
 [10.202.2.45])
 by mailfhigh.phl.internal (Postfix) with ESMTP id 6CAF61140123;
 Mon, 23 Jun 2025 09:46:59 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-05.internal (MEProxy); Mon, 23 Jun 2025 09:46:59 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 23 Jun 2025 09:46:58 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 893a86a0-5038-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:message-id:mime-version:reply-to:subject:subject:to:to; s=fm1;
	 t=1750686419; x=1750772819; bh=6lArJVya6sMHXsEjN3PqQO2uV8GEcc8U
	gEN6bG492KY=; b=km6pCW1oQfx6Gvcb4NFDr9IhzGys2kPmrJgq1BiP/zS0xyI5
	tBc35IGnRFLKFeXjDRI6BFNKLJ6TXjxvhCi5eblC2YPSHGj5OWQOgnuZf5c5EQdU
	UpnYvbt/3hEduPFMaZTqb05o6XdECtgWssF5+H0nICR3qS1IEHiKQpGFJs8yecgQ
	5muE8nx9+tadMuHdleHQIEcU7mj0yypnX0pysTp8e222yG4kTg1F4gPcEbVZ/DA6
	hF2W7gVnDdQrbXqlBucjAn1WbESVrbKXe+aqP3lnKFUGYJGLMlABGR8+/MMBDVnc
	5AtHyiAMhvrQXS2/4m6DKz5Qk2ylpL2Npio15Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:message-id:mime-version:reply-to:subject
	:subject:to:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
	fm1; t=1750686419; x=1750772819; bh=6lArJVya6sMHXsEjN3PqQO2uV8GE
	cc8UgEN6bG492KY=; b=JrJqIp5XmdEZ4jeL9B6uFBzYwYCngVc5ztBlCz61jDVu
	Xzb/CWeRs+L74h1ioOlDI9HdUMtokkiuI0jnhkFt03Bup8tx+Twysmg5ysD0klsW
	E4dQDIxTYx9Dt+qqevOCq207bj7ijvZJ3Wje4j4b6jAnsZ9oU1Mwl6swWih0z95a
	VS+NARq5PefWr2NIXjWnkV+nQjQPNcb78LKVokH7fjukh/q+39UDlPhmUr5XxlHp
	OPbptVGZhMhJ40XyKZfTyMrRwARexKypbOmjx0pijP3VJejfIKhv1avaJvMH+KE8
	44qs7MbvK/glXdwg93hxSwF9MyawqZwpmc4l88rLcw==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgddujedukecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpefhvfevufffkffogggtgfesthekredtredtjeenucfhrhhomhepofgrrhgvkhcuofgr
    rhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvihhsih
    gslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepjeeufefhleei
    keegfedtgfeiueeghfduteejtefhfeevheffjefhieeggfejkeelnecuffhomhgrihhnpe
    hgihhtlhgrsgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgr
    ihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrd
    gtohhmpdhnsggprhgtphhtthhopeehpdhmohguvgepshhmthhpohhuthdprhgtphhtthho
    peigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdprhgtph
    htthhopegrnhgurhgvfidrtghoohhpvghrfeestghithhrihigrdgtohhmpdhrtghpthht
    ohepshhsthgrsggvlhhlihhniheskhgvrhhnvghlrdhorhhgpdhrtghpthhtoheprhhogh
    gvrhdrphgruhestghithhrihigrdgtohhmpdhrtghpthhtohepmhgrrhhmrghrvghksehi
    nhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
	Stefano Stabellini ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
Subject: [PATCH test-artifacts v1 0/5] Changes for building arbitrary Linux branch and for hw12 runner
Date: Mon, 23 Jun 2025 15:46:19 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This series is necessary for the other one sent in a moment.

Technically, the last patch isn't strictly required, but it eases debugging.

Green pipeline: https://gitlab.com/xen-project/people/marmarek/test-artifacts/-/pipelines/1881057399

Marek Marczykowski-Górecki (5):
  Add linux-6.12.34-x86_64
  Enable CONFIG_USB_RTL8152 in kernel for hw12 runner
  Include git in the ARM64 build container too
  Support building arbitrary Linux branch/tag/commit
  Setup ssh access to test systems

 .gitlab-ci.yml                            | 28 ++++++++++++++++++++++++-
 images/alpine/3.18-arm64-build.dockerfile |  1 +-
 scripts/alpine-rootfs.sh                  |  4 +++-
 scripts/build-linux.sh                    | 19 +++++++++++-----
 4 files changed, 47 insertions(+), 5 deletions(-)

base-commit: d7434697deec41ddf31a2f3d189dee75d4d2486f
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 13:47:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 13:47:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022373.1398174 (Exim 4.92)
	(envelope-from )
	id 1uThVr-0004tO-9D; Mon, 23 Jun 2025 13:47:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022373.1398174; Mon, 23 Jun 2025 13:47:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uThVr-0004tE-6O; Mon, 23 Jun 2025 13:47:07 +0000
Received: by outflank-mailman (input) for mailman id 1022373;
 Mon, 23 Jun 2025 13:47: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 1uThVp-0004sG-Ch
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 13:47:05 +0000
Received: from fhigh-a4-smtp.messagingengine.com
 (fhigh-a4-smtp.messagingengine.com [103.168.172.155])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8ab1b2ec-5038-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 15:47:03 +0200 (CEST)
Received: from phl-compute-11.internal (phl-compute-11.phl.internal
 [10.202.2.51])
 by mailfhigh.phl.internal (Postfix) with ESMTP id 3711511400F0;
 Mon, 23 Jun 2025 09:47:02 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-11.internal (MEProxy); Mon, 23 Jun 2025 09:47:02 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 23 Jun 2025 09:47:00 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8ab1b2ec-5038-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm1; t=1750686422; x=1750772822; bh=rd3USSJTOQ
	GgPaA3MkEgLhgVn41dCK5xgFAB+vXgTXw=; b=QXtXyH/kHx8bMeJDMBI40SfKFK
	bdo45hv+dvfWJLa78uhmz5Npa7Le+zv3tKFmfVKJ2LYfHO69mAXWfmdYQcqxNqGf
	4C0eNBk16lmWQ2wCGRcExoc6zqcnOP5qvSH7H2kuXWtbOGzuefCTEJVkDkbuSuLZ
	2mVoBqWSTYET6X38NtTz16tEFX+XE/uqhM7FZPPltxizBpqFJv5UrM11jrqmswxV
	ruZv/c6Cxn6xs+uyx/JH2tB6PEyRH/dEvSo6ysfLatI96N2r7BpR2Fz5TAo6nkwK
	+qdRHhvg9HltBuwYhrs34KPScB+um8ek/M322LRQHx/TF2k/bNe3t11NKoqw==
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=1750686422; x=
	1750772822; bh=rd3USSJTOQGgPaA3MkEgLhgVn41dCK5xgFAB+vXgTXw=; b=p
	KfWRAzkLU7xqYc9tsiMPtzPcavCKln7+2oL6Z1Ao5saLqbd/z7v1DCrYQXF7EeYh
	B01+bpzKVWdM7dnIEYEcNEWsyEci4Ea64czXnzyXaBYgYJsjWC6l5MBxhmnolWxZ
	4d9f6BoXY6wypsOXyHmI7uy8AvJt9a0Fc4xAJ6yiggIjdM6xUpcGmcRNW8rblXcD
	3E6uNuaM9k6hLFfwElAN5TsqgFsilTI+9iS/ELbcVkSRj4AH296nRt52Mo7RNbNc
	XeENN8+jGswnBtWRLUCtZMPU1k5TOxOwwMqxkNnZ01mXraVO9qMuj9QPRNvixdr/
	x9trkJmGP6GDqIvLxKDhg==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgddujedukecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpefhvfevufffkffojghfgggtgfesthekredtredtjeenucfhrhhomhepofgrrhgvkhcu
    ofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvih
    hsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepffeitdeg
    veffteelvdeghffhvefghfefkeelheeujeejgedvvdfgffejuedtvdelnecuffhomhgrih
    hnpehkvghrnhgvlhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhep
    mhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrg
    gsrdgtohhmpdhnsggprhgtphhtthhopeehpdhmohguvgepshhmthhpohhuthdprhgtphht
    thhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdprh
    gtphhtthhopegrnhgurhgvfidrtghoohhpvghrfeestghithhrihigrdgtohhmpdhrtghp
    thhtohepshhsthgrsggvlhhlihhniheskhgvrhhnvghlrdhorhhgpdhrtghpthhtoheprh
    hoghgvrhdrphgruhestghithhrihigrdgtohhmpdhrtghpthhtohepmhgrrhhmrghrvghk
    sehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
	Stefano Stabellini ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
Subject: [PATCH test-artifacts v1 2/5] Enable CONFIG_USB_RTL8152 in kernel for hw12 runner
Date: Mon, 23 Jun 2025 15:46:21 +0200
Message-ID: <8c97ac17c41e53c15e769f28d537faa01a0b2e6a.1750684376.git-series.marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

It uses this USB network interface.

Signed-off-by: Marek Marczykowski-Górecki 
---
This was posted before at https://lore.kernel.org/xen-devel/20250411203336.585215-1-marmarek@invisiblethingslab.com/
---
 scripts/build-linux.sh | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/build-linux.sh b/scripts/build-linux.sh
index 441b872..cf0e744 100755
--- a/scripts/build-linux.sh
+++ b/scripts/build-linux.sh
@@ -32,6 +32,7 @@ case $UNAME in
             | grep 'XEN' \
             | grep '=m' \
             | sed 's/=m/=y/g' >> .config
+        ./scripts/config --enable USB_RTL8152
         ;;
 
     aarch64)
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 13:47:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 13:47:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022374.1398181 (Exim 4.92)
	(envelope-from )
	id 1uThVr-0004wa-Ni; Mon, 23 Jun 2025 13:47:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022374.1398181; Mon, 23 Jun 2025 13:47:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uThVr-0004vk-Dr; Mon, 23 Jun 2025 13:47:07 +0000
Received: by outflank-mailman (input) for mailman id 1022374;
 Mon, 23 Jun 2025 13:47: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 1uThVp-00048y-PT
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 13:47:05 +0000
Received: from fhigh-a4-smtp.messagingengine.com
 (fhigh-a4-smtp.messagingengine.com [103.168.172.155])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8b71d67c-5038-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 15:47:04 +0200 (CEST)
Received: from phl-compute-05.internal (phl-compute-05.phl.internal
 [10.202.2.45])
 by mailfhigh.phl.internal (Postfix) with ESMTP id 77B3911400D0;
 Mon, 23 Jun 2025 09:47:03 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-05.internal (MEProxy); Mon, 23 Jun 2025 09:47:03 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 23 Jun 2025 09:47:02 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8b71d67c-5038-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm1; t=1750686423; x=1750772823; bh=QG8dKhrWvv
	GTlwDVn3FIfWbEGXxs8coS0YgMvQyIRtw=; b=G0xRUjr67l4K1kKxfKcKVGA93o
	nC8RLgsNqeNfWuafpdMY0zHNR+fy3g+LGD4W2T1A7obSs9rlnR1t/7zRYnp0Vbeb
	ybmITzQi25DxjugE6MWtQdtm9CJMclgLGwsq4SQ72JlPq8rGrdPFv7ihbM0x3zUF
	7koGCoNwsE63PnakPHefBiOrSJJB0Ia8njH5Gs68QR5vE7qxrXdB83D7yT3wRVHL
	3N1KaX5C+luKqmC6zqyR67mzJCM/+5xmiyVrpBcev+wywa6m8M6Qjbxi+T09HC67
	kT8YSSmZSkOOudK7RDBhcovlayzjJIAggL/2/JRhwKZIgQZqbwGRr8COxq5Q==
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=1750686423; x=
	1750772823; bh=QG8dKhrWvvGTlwDVn3FIfWbEGXxs8coS0YgMvQyIRtw=; b=H
	lnvA2s6EeqpjNoF73Qjv2lGmfVPqWKUMVjCzplk67Cmt1bZzD/EcFPOBa0QRjl+6
	scyEBq2gRKmVNvGXgWu6aGvUBpYPSs84lMRWeHOpaNJ/QG599vqhvethDGVMw9LY
	poh/Gzvx5TrVras8eL9i5hfjRT6K4D53pCkECHaRNRKJZ9wVF1ndz9AXf/8mZtnu
	s2Q2+FvmxhdkHs2OX7sdnuIETVs6SQSL5FgOa68hgOIGSZ+GBQslKVLhb39MkytE
	JpVKz9mso2iBwT9ebDjaeIHs1Rv0/wdq6rJ1ROT4TRxgkId0ef1pml+07qBTqkbm
	tKb2jhRd3FpYH61FBtpBg==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgddujedukecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpefhvfevufffkffojghfgggtgfesthekredtredtjeenucfhrhhomhepofgrrhgvkhcu
    ofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvih
    hsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfeuudeh
    gfdvfeehhedujeehfeduveeugefhkefhheelgeevudetueeiudfggfffnecuvehluhhsth
    gvrhfuihiivgepudenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehi
    nhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohephedpmh
    houggvpehsmhhtphhouhhtpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdr
    gigvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtoheprghnughrvgifrdgtohhophgvrh
    efsegtihhtrhhigidrtghomhdprhgtphhtthhopehsshhtrggsvghllhhinhhisehkvghr
    nhgvlhdrohhrghdprhgtphhtthhopehrohhgvghrrdhprghusegtihhtrhhigidrtghomh
    dprhgtphhtthhopehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggs
    rdgtohhm
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
	Stefano Stabellini ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
Subject: [PATCH test-artifacts v1 3/5] Include git in the ARM64 build container too
Date: Mon, 23 Jun 2025 15:46:22 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

It will be used for fetching some Linux versions.

Signed-off-by: Marek Marczykowski-Górecki 
---
 images/alpine/3.18-arm64-build.dockerfile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/images/alpine/3.18-arm64-build.dockerfile b/images/alpine/3.18-arm64-build.dockerfile
index 25a8dbd..38464c9 100644
--- a/images/alpine/3.18-arm64-build.dockerfile
+++ b/images/alpine/3.18-arm64-build.dockerfile
@@ -14,6 +14,7 @@ RUN <
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 13:47:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022375.1398187 (Exim 4.92)
	(envelope-from )
	id 1uThVs-00056S-4f; Mon, 23 Jun 2025 13:47:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022375.1398187; Mon, 23 Jun 2025 13:47: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 1uThVr-00054H-VX; Mon, 23 Jun 2025 13:47:07 +0000
Received: by outflank-mailman (input) for mailman id 1022375;
 Mon, 23 Jun 2025 13:47: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 1uThVr-00048y-1K
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 13:47:07 +0000
Received: from fhigh-a4-smtp.messagingengine.com
 (fhigh-a4-smtp.messagingengine.com [103.168.172.155])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8c31b0be-5038-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 15:47:05 +0200 (CEST)
Received: from phl-compute-06.internal (phl-compute-06.phl.internal
 [10.202.2.46])
 by mailfhigh.phl.internal (Postfix) with ESMTP id B706A11400B4;
 Mon, 23 Jun 2025 09:47:04 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-06.internal (MEProxy); Mon, 23 Jun 2025 09:47:04 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 23 Jun 2025 09:47:03 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8c31b0be-5038-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm1; t=1750686424; x=1750772824; bh=Q0IYK2X499
	honc0Q7bdViPVpqyeoLI8UjaNIqKckVK8=; b=c7wS3OZK9BWyYsudEoJP9xW96/
	kHdR5w38c6RdeM1b+rejugMGAMLkVnzmn1WFCp22Ho4TSzFdqreJBN2xNEYCHlzV
	vEHLKp2xiAh9BQxVoCWDLJafUFWazewwg1zTvv7tdscFXKSKwioS7mzsT3qiAW9F
	qUbtzf6oB5vWZcv8B4zb9fYW2n+rP7dmhCrJ3Bkbm61sBV+Qe28rAjXtFhDkBnRd
	6pNl4oT+dINW0nMZ6A4sg9bbn2t8kYwzvlWm0FmQ+nSPcYds4/plvMfXQBqDmc/8
	r4qeSMoi633SthhNRnTxMLC1If8+Ny11ulPVo6S17dflH9J5CsKJJrlNBtuQ==
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=1750686424; x=
	1750772824; bh=Q0IYK2X499honc0Q7bdViPVpqyeoLI8UjaNIqKckVK8=; b=U
	ptr+fXdF9J0qPRVnWDDTZzeaNtFLpCnkptT9HxIV5XvkIaKuFI04yyztS8fpkbA1
	Lcm9XXdZw2fooS1UH9Nn8XpOq2bDQEcp3x4vMEW+RM4+rxZVDKP30rXP86KddGxV
	dUKFsI2P5DCZHvh+qNzUvViAf63eX4YQOzBzKGj4QANdH2T64XbiPF4dqhl5WTcm
	sSFbUQ5JgCIqFbM6Y73lekzKrJriqwzvn/PwOetvDwo1aAUeVVxTDyvXdqCVBv/b
	LP/ZJsIS80GEXIEstGl/4gR0RrlMjcXjvxY80gp2WLcDIelVPPpuAh0/c1c0xnxA
	NJH1K+Jo14KIKURP6HL5Q==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgddujedukecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpefhvfevufffkffojghfgggtgfesthekredtredtjeenucfhrhhomhepofgrrhgvkhcu
    ofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvih
    hsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfelgffg
    ueffgeejudehieegteeugeefkeejtefghfdvieffieeijefgudeikeegnecuffhomhgrih
    hnpehgihhtlhgrsgdrtghomhdpkhgvrhhnvghlrdhorhhgnecuvehluhhsthgvrhfuihii
    vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhvihhsih
    gslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohephedpmhhouggvpehs
    mhhtphhouhhtpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprh
    hojhgvtghtrdhorhhgpdhrtghpthhtoheprghnughrvgifrdgtohhophgvrhefsegtihht
    rhhigidrtghomhdprhgtphhtthhopehsshhtrggsvghllhhinhhisehkvghrnhgvlhdroh
    hrghdprhgtphhtthhopehrohhgvghrrdhprghusegtihhtrhhigidrtghomhdprhgtphht
    thhopehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhm
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
	Stefano Stabellini ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
Subject: [PATCH test-artifacts v1 4/5] Support building arbitrary Linux branch/tag/commit
Date: Mon, 23 Jun 2025 15:46:23 +0200
Message-ID: <7bd5b5d88d6229e5d85396ed18ac654a6f8a59ab.1750684376.git-series.marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

If LINUX_URL is set, fetch LINUX_VERSION from there. Go with "git
init" + "git fetch" instead of "git clone" to support any of
branch/tag/commit.

This also defines optional linux-git-* jobs which will build the thing
if LINUX_GIT_VERSION and LINUX_GIT_URL variables are provided for the
pipeline.

Signed-off-by: Marek Marczykowski-Górecki 
---
The script variable and job variable need to have different names, so a
pipeline variable won't override it for all jobs. While LINUX_VERSION /
LINUX_GIT_VERSION is IMO okay, I'm not very happy about LINUX_URL /
LINUX_GIT_URL. Any better ideas?
---
 .gitlab-ci.yml         | 22 ++++++++++++++++++++++
 scripts/build-linux.sh | 18 +++++++++++++-----
 2 files changed, 35 insertions(+), 5 deletions(-)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index ad44fb4..60af072 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -1,5 +1,9 @@
 variables:
   REGISTRY: registry.gitlab.com/xen-project/hardware/test-artifacts
+  LINUX_GIT_VERSION:
+    description: "branch/tag/commit for the linux-git jobs"
+  LINUX_GIT_URL:
+    description: "git url for the linux-git jobs"
 
 stages:
   - build
@@ -46,6 +50,15 @@ linux-6.6.86-arm64:
   variables:
     LINUX_VERSION: 6.6.86
 
+linux-git-arm64:
+  extends: .arm64-artifacts
+  script: ./scripts/build-linux.sh
+  variables:
+    LINUX_VERSION: $LINUX_GIT_VERSION
+    LINUX_URL: $LINUX_GIT_URL
+  rules:
+  - if: $LINUX_GIT_VERSION && $LINUX_GIT_URL
+
 #
 # x86_64 artifacts
 #
@@ -70,6 +83,15 @@ linux-6.12.34-x86_64:
   variables:
     LINUX_VERSION: 6.12.34
 
+linux-git-x86_64:
+  extends: .x86_64-artifacts
+  script: ./scripts/build-linux.sh
+  variables:
+    LINUX_VERSION: $LINUX_GIT_VERSION
+    LINUX_URL: $LINUX_GIT_URL
+  rules:
+  - if: $LINUX_GIT_VERSION && $LINUX_GIT_URL
+
 microcode-x86:
   extends: .x86_64-artifacts
   script: ./scripts/x86-microcode.sh
diff --git a/scripts/build-linux.sh b/scripts/build-linux.sh
index cf0e744..1fc96d1 100755
--- a/scripts/build-linux.sh
+++ b/scripts/build-linux.sh
@@ -12,11 +12,19 @@ COPYDIR="${WORKDIR}/binaries"
 UNAME=$(uname -m)
 
 # Build Linux
-MAJOR=${LINUX_VERSION%%.*}
-curl -fsSLO \
-    https://cdn.kernel.org/pub/linux/kernel/v"${MAJOR}".x/linux-"${LINUX_VERSION}".tar.xz
-tar xf linux-"${LINUX_VERSION}".tar.xz
-cd linux-"${LINUX_VERSION}"
+if [[ -n "${LINUX_URL}" ]]; then
+    mkdir linux
+    cd linux
+    git init
+    git fetch --depth=1 "${LINUX_URL}" "${LINUX_VERSION}"
+    git checkout FETCH_HEAD
+else
+    MAJOR=${LINUX_VERSION%%.*}
+    curl -fsSLO \
+        https://cdn.kernel.org/pub/linux/kernel/v"${MAJOR}".x/linux-"${LINUX_VERSION}".tar.xz
+    tar xf linux-"${LINUX_VERSION}".tar.xz
+    cd linux-"${LINUX_VERSION}"
+fi
 
 make defconfig
 ./scripts/config --enable BRIDGE
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 13:47:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 13:47:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022376.1398204 (Exim 4.92)
	(envelope-from )
	id 1uThVt-0005YX-Eh; Mon, 23 Jun 2025 13:47:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022376.1398204; Mon, 23 Jun 2025 13:47:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uThVt-0005Xa-7r; Mon, 23 Jun 2025 13:47:09 +0000
Received: by outflank-mailman (input) for mailman id 1022376;
 Mon, 23 Jun 2025 13:47: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 1uThVr-0004sG-R3
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 13:47:07 +0000
Received: from fout-a3-smtp.messagingengine.com
 (fout-a3-smtp.messagingengine.com [103.168.172.146])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8cff6737-5038-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 15:47:07 +0200 (CEST)
Received: from phl-compute-09.internal (phl-compute-09.phl.internal
 [10.202.2.49])
 by mailfout.phl.internal (Postfix) with ESMTP id 15AFE13807C4;
 Mon, 23 Jun 2025 09:47:06 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-09.internal (MEProxy); Mon, 23 Jun 2025 09:47:06 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 23 Jun 2025 09:47:04 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8cff6737-5038-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm1; t=1750686426; x=1750772826; bh=o8VgD6a057
	VNjsnHartaX+IMFYG5/NjtSB5DTQtrThg=; b=kVMrrhGZUonqkg9BkLaWTh36Mk
	+T5RRSacCflydJAosdLcm+UpRFJ1qjyQ4dI3HVi3XDvI5uQjbv/eZ6tISiLYR9WO
	7Etp3B55qqax4+0JuC8aNGHDwGlwmL9hIYloYafqpJxCcWe+q4VjCiuVq+zwXl8Z
	EAGmhzpQBNkojo+MJbP2a7Dz9ZC1Ujti2in8fVfWJTT7QcknRM4MUa+NvBBZwqCt
	LKFAnw6FXZY8ttoDOvwCib3/IPdCNUYNCArNnWaVtnqSazhMWo8j41mBCY0vCaCc
	MhV3mNuFyyV5+rulErnqjPX6fQe/OYjmER7Xpan69jnXi6m8R7LPmOXjh1DQ==
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=1750686426; x=
	1750772826; bh=o8VgD6a057VNjsnHartaX+IMFYG5/NjtSB5DTQtrThg=; b=V
	hrFO3icLA/H0g/99mNdap6/ZZLybSoBn0zQ+c+BgwW/Ri6TS7mR0u7kTnvDp5g2q
	HKbP0TcDnFsv8w72V4lAKlo415eGPRXiczF4kUHIBoaf9OrKNiiZbEfgAK7LZmIy
	qa3+TzdubPiAXG91JmhMJxJdkAJAqutMCN8Vfc8vcn/BMkuynBIrFuB1QQ4pxD3b
	nIzolHfWmqNU2VOTHr56fQs5L/OkBhdbtK+SvJKR2VeVn6HqBF5hp4lJJRQWgWeu
	rin+HLI5z2aSJfI8QQ9NduhvnjFWQYFTvVua1d0YIVJo3e0Nwgqle4fQ/8LLm9Fd
	OhttBQV0N7G/lt4OF9J4A==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgddujedukecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpefhvfevufffkffojghfgggtgfesthekredtredtjeenucfhrhhomhepofgrrhgvkhcu
    ofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvih
    hsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfeuudeh
    gfdvfeehhedujeehfeduveeugefhkefhheelgeevudetueeiudfggfffnecuvehluhhsth
    gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehi
    nhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohephedpmh
    houggvpehsmhhtphhouhhtpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdr
    gigvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtoheprghnughrvgifrdgtohhophgvrh
    efsegtihhtrhhigidrtghomhdprhgtphhtthhopehsshhtrggsvghllhhinhhisehkvghr
    nhgvlhdrohhrghdprhgtphhtthhopehrohhgvghrrdhprghusegtihhtrhhigidrtghomh
    dprhgtphhtthhopehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggs
    rdgtohhm
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
	Stefano Stabellini ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
Subject: [PATCH test-artifacts v1 5/5] Setup ssh access to test systems
Date: Mon, 23 Jun 2025 15:46:24 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

For this add also bridge package, so xenbr0 can be configured with
/etc/network/interfaces.
This allows extracting more logs out of the test system.

Signed-off-by: Marek Marczykowski-Górecki 
---
This enables passwordless root login. It's okay for qubes runners, as
they are isolated (even from each other). Is that okay in other places
too?
---
 scripts/alpine-rootfs.sh | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/scripts/alpine-rootfs.sh b/scripts/alpine-rootfs.sh
index c999b89..632609b 100755
--- a/scripts/alpine-rootfs.sh
+++ b/scripts/alpine-rootfs.sh
@@ -10,6 +10,8 @@ apk --no-cache upgrade
 
 PKGS=(
     # System
+    bridge
+    dropbear
     libgcc
     openrc
     udev
@@ -62,6 +64,7 @@ rc-update add loopback sysinit
 rc-update add bootmisc boot
 rc-update add devfs sysinit
 rc-update add dmesg sysinit
+rc-update add dropbear boot
 rc-update add hostname boot
 rc-update add hwclock boot
 rc-update add hwdrivers sysinit
@@ -74,6 +77,7 @@ echo "ttyS0" >> /etc/securetty
 echo "hvc0" >> /etc/securetty
 echo "ttyS0::respawn:/sbin/getty -L ttyS0 115200 vt100" >> /etc/inittab
 echo "hvc0::respawn:/sbin/getty -L hvc0 115200 vt100" >> /etc/inittab
+echo "DROPBEAR_OPTS=\"-B -R\"" >> /etc/conf.d/dropbear
 echo "rc_verbose=yes" >> /etc/rc.conf
 echo > /etc/modules
 passwd -d "root" root
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 13:47:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 13:47:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022379.1398214 (Exim 4.92)
	(envelope-from )
	id 1uThVz-00061w-M1; Mon, 23 Jun 2025 13:47:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022379.1398214; Mon, 23 Jun 2025 13: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 1uThVz-00061l-Hw; Mon, 23 Jun 2025 13:47:15 +0000
Received: by outflank-mailman (input) for mailman id 1022379;
 Mon, 23 Jun 2025 13:47: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 1uThVx-00048y-KW
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 13:47:13 +0000
Received: from fhigh-a4-smtp.messagingengine.com
 (fhigh-a4-smtp.messagingengine.com [103.168.172.155])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 89cabbf1-5038-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 15:47:01 +0200 (CEST)
Received: from phl-compute-05.internal (phl-compute-05.phl.internal
 [10.202.2.45])
 by mailfhigh.phl.internal (Postfix) with ESMTP id AF2E91140111;
 Mon, 23 Jun 2025 09:47:00 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-05.internal (MEProxy); Mon, 23 Jun 2025 09:47:00 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 23 Jun 2025 09:46:59 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 89cabbf1-5038-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm1; t=1750686420; x=1750772820; bh=rMfuOb3zWq
	f2Otrwcg1PxJw2zLi1cC9pyVwVASV78Ow=; b=mcCeIaY2mUYZPIrCFKOELknLJe
	I7QFn0tls3/hxV1qEMwzlpXR7qvc2ZrdEPGva7l3w+qEyTQOEphHZC8eV6nMR0En
	4V+U4ObpFutJ+XQhb4pFU+8BjtHMBoJoiPFBPXZIgdaIdMH9KI070Jo1AX4C0XqI
	VK39q9alEooQjLPzK7sakm1qu7XdQ739rusTlvi8GXCH9n4GNOzE3vmjcbg82ZWY
	XP6f2372NRxKys5kLpa2Bo4ifSzwApbXaEhHKzEHlExo31lx3HWfkP7lPTLoy8ac
	621NxYqxzpxz5TiTYwlXTsgQwG8K18jxrN3r1sp8MBdHr5PhdWjMDJLYmVHA==
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=1750686420; x=
	1750772820; bh=rMfuOb3zWqf2Otrwcg1PxJw2zLi1cC9pyVwVASV78Ow=; b=R
	kFRfIDbdARJAa4kDNHrz+2N/OCVl7emFTDElEBMEttrH96ShUQm1qwTF/Fe1R3zy
	YRwSbwWdSS6s3Q73MwEvL2KAOpDwUzVtVXPjjuzVa5LnwNASy2XPgI/K2VnhTTIb
	HGOxCnAM6AzQdtcEsmdjdb+ZwicujVnU7TDrAq2d/lNh992C6MsVnYqCsNVAw/ff
	GhGYIFC1i4LS/UY9pr3xsHJ16Fw+0RaTEay4HKGaomDC+r7eT/UDQsqJeVA7WAyn
	kBSPGAZ92jcrOy+ENRSbsdtTi/bfFK7WpZZdLeeMNTCsyk1iUYjf4PkKJLglPFKA
	9VK0CNxcoDvCjNmDALlmA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgddujedukecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpefhvfevufffkffojghfgggtgfesthekredtredtjeenucfhrhhomhepofgrrhgvkhcu
    ofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvih
    hsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfeuudeh
    gfdvfeehhedujeehfeduveeugefhkefhheelgeevudetueeiudfggfffnecuvehluhhsth
    gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehi
    nhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohephedpmh
    houggvpehsmhhtphhouhhtpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdr
    gigvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtoheprghnughrvgifrdgtohhophgvrh
    efsegtihhtrhhigidrtghomhdprhgtphhtthhopehsshhtrggsvghllhhinhhisehkvghr
    nhgvlhdrohhrghdprhgtphhtthhopehrohhgvghrrdhprghusegtihhtrhhigidrtghomh
    dprhgtphhtthhopehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggs
    rdgtohhm
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
	Stefano Stabellini ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
Subject: [PATCH test-artifacts v1 1/5] Add linux-6.12.34-x86_64
Date: Mon, 23 Jun 2025 15:46:20 +0200
Message-ID: <0a3e893e5fe133dc710d11a31006ba4f2c1b0cbe.1750684376.git-series.marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This is necessary for new Zen4 runner.
Do not include Argo module in this build, as it isn't compatible with
6.12 yet.

Signed-off-by: Marek Marczykowski-Górecki 
---
 .gitlab-ci.yml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index c698612..ad44fb4 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -64,6 +64,12 @@ linux-6.6.56-x86_64:
     ARGO_SHA: "cf73819cacc945baca1a7421e5836d1bd481739b"
     ARGOEXEC_SHA: "d900429f6640acc6f68a3d3a4c945d7da60625d8"
 
+linux-6.12.34-x86_64:
+  extends: .x86_64-artifacts
+  script: ./scripts/build-linux.sh
+  variables:
+    LINUX_VERSION: 6.12.34
+
 microcode-x86:
   extends: .x86_64-artifacts
   script: ./scripts/x86-microcode.sh
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 13:50:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 13:50:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022410.1398224 (Exim 4.92)
	(envelope-from )
	id 1uThZL-0000M3-4j; Mon, 23 Jun 2025 13:50:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022410.1398224; Mon, 23 Jun 2025 13:50:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uThZL-0000Lw-1x; Mon, 23 Jun 2025 13:50:43 +0000
Received: by outflank-mailman (input) for mailman id 1022410;
 Mon, 23 Jun 2025 13:50: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 1uThWM-0004sG-AW
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 13:47:38 +0000
Received: from fout-a3-smtp.messagingengine.com
 (fout-a3-smtp.messagingengine.com [103.168.172.146])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9f70dfc4-5038-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 15:47:37 +0200 (CEST)
Received: from phl-compute-02.internal (phl-compute-02.phl.internal
 [10.202.2.42])
 by mailfout.phl.internal (Postfix) with ESMTP id 089EF138082B;
 Mon, 23 Jun 2025 09:47:37 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-02.internal (MEProxy); Mon, 23 Jun 2025 09:47:37 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 23 Jun 2025 09:47:36 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9f70dfc4-5038-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:message-id:mime-version:reply-to:subject:subject:to:to; s=fm1;
	 t=1750686457; x=1750772857; bh=pEfttlFJVn71WFrJPgQWz5RphtFBKEVS
	T45Ebzr0+cQ=; b=hZfRdJlmPDt5b5tAlam2Ar0IseeMTCmgK6I6lb/geXg9JukE
	WFLul8xt3APjFQEhwUDBckZtlk7o9Ey6v7tYdkTrY0WepCxF1WyNqZSHASmvmGSf
	6wSbD4UF76Yc4VQQiMBq+XROALZsOOrDlUHPzwhIwsK4LvRxp6ztg5JiW58+BL8B
	sKiHk5NNVlTRMW3dGxQe+OBRfmrZK4libcwPGWor5YnGPHS/9t5LNynswOOpTLi4
	FQhS9+gG7LCP3Jorkw0XMksgOTpC3zi4rDdHxCkBJWvKBdqPnl5TUoMtMcJc0F2X
	VQgGVmu8LMwbmaq4brDpYec6kdr129SYfXPqvg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:message-id:mime-version:reply-to:subject
	:subject:to:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
	fm1; t=1750686457; x=1750772857; bh=pEfttlFJVn71WFrJPgQWz5RphtFB
	KEVST45Ebzr0+cQ=; b=p6SU85ERBH4KCXKZ9GI0AXVqO480wUD71wgeQYoW83da
	cc112e45ywzgwAxfEEk/6zAGXJsnVt2x97Zm3liJdm81hXK0rmz+NgADlTjHFCQG
	qVawFkXPvd/Mx1kPijHA1T0NLZ0v+iud49RBZGYIccPHh4EQwVNLf+fp17RFZfrd
	uvSQcpgN5a8HqFw29ACn18oE2EPHVzN3LlHM+hOPrdN1eWut1Psg8SjI2WgfmCjy
	GHK/cU3+tsEfHcOulfYx1uBKJsuFU6EueZEvnhl1cuzJMCeb/xjNti8CDsIA7Lss
	4Az4e7+gVF3WTYTFrQsXaXnT+NvtSCFW6xkMbUT/hA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgddujedukecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecunecujfgurhephffvvefufffkofggtgfgsehtkeertdertd
    ejnecuhfhrohhmpeforghrvghkucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcu
    oehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenuc
    ggtffrrghtthgvrhhnpeejueefhfelieekgeeftdfgieeugefhudetjeethfefveehffej
    hfeigefgjeekleenucffohhmrghinhepghhithhlrggsrdgtohhmnecuvehluhhsthgvrh
    fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhv
    ihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepvddpmhhoug
    gvpehsmhhtphhouhhtpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigv
    nhhprhhojhgvtghtrdhorhhgpdhrtghpthhtohepmhgrrhhmrghrvghksehinhhvihhsih
    gslhgvthhhihhnghhslhgrsgdrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
Subject: [PATCH v1 0/6] Add infrastructure for testing arbitrary Linux branch, and one more runner
Date: Mon, 23 Jun 2025 15:47:09 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This series implements testing arbitrary Linux branch, based on pipeline
variables. The idea is to setup schedule running a pipeline for few selected
branches (some of the Linux stable branches? linux-next? Linus's master
branch?) The SELECTED_JOBS_ONLY variable can be used to exclude most of the
build jobs in those pipelines.

This series is combined with adding hw12 runner, as it needs a newer kernel
anyway, so putting it together avoids merge conflict. There are also few minor
CI improvements collected along the way.

Pipeline:
https://gitlab.com/xen-project/people/marmarek/xen/-/pipelines/1882799125

Marek Marczykowski-Górecki (6):
  CI: Switch x86 tests to 6.12.34 kernel
  CI: add AMD Zen 4 HW runner
  CI: upload tests-junit.xml as a normal artifact too
  CI: make test-artifacts branch/job customizable
  CI: use Alpine's network setup
  [DO NOT MERGE] CI: example how to use ssh to extract logs

 .gitlab-ci.yml                     |  9 ++++-
 automation/gitlab-ci/test.yaml     | 65 +++++++++++++++++++++++++++++--
 automation/scripts/qubes-x86-64.sh | 22 +++++-----
 3 files changed, 81 insertions(+), 15 deletions(-)

base-commit: cc7394164633e75fb61d52565f75271e0b7f1236
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 13:50:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 13:50:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022411.1398234 (Exim 4.92)
	(envelope-from )
	id 1uThZN-0000fk-DC; Mon, 23 Jun 2025 13:50:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022411.1398234; Mon, 23 Jun 2025 13:50:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uThZN-0000fd-AZ; Mon, 23 Jun 2025 13:50:45 +0000
Received: by outflank-mailman (input) for mailman id 1022411;
 Mon, 23 Jun 2025 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 1uThWN-0004sG-K9
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 13:47:39 +0000
Received: from fout-a3-smtp.messagingengine.com
 (fout-a3-smtp.messagingengine.com [103.168.172.146])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a0370650-5038-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 15:47:39 +0200 (CEST)
Received: from phl-compute-09.internal (phl-compute-09.phl.internal
 [10.202.2.49])
 by mailfout.phl.internal (Postfix) with ESMTP id 46303138082B;
 Mon, 23 Jun 2025 09:47:38 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-09.internal (MEProxy); Mon, 23 Jun 2025 09:47:38 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 23 Jun 2025 09:47:37 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a0370650-5038-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm1; t=1750686458; x=1750772858; bh=N9MD8Mvw6f
	t7X7ieLTItulxJ3A0QGL2tSAmCCfyuQa4=; b=kXGFTVTqZ8w4MQA6G6i1+dbc8b
	Eh4Ir+2CRc6ewSVfhS8anJIMwDs12smDyUQYG0fuQJ/YLdme4MZ10lAuceG6oe/W
	JhvajcMOAWF7FVTyRGPTENsNJFxExjF069lpaKIcUgHWu5MoUP9A1QZBzPhuJW68
	/gf55yaNpRs21+N9gLSH/iFCjIcpnMibuCcZmDtfVLutwO98+FzuR5KjBV0YHmAn
	rbx9tHXLWjBOr02gso6YwqlMRLpLHEan0kADU0mvtqfyR5rN+vmaOcL/7H3elgbE
	XQwVRSG/cB+U3Ri6XpGqu0/tuHhwvv7BzWMb6xmVl7CY19mYifEfZtqlFFPw==
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=1750686458; x=
	1750772858; bh=N9MD8Mvw6ft7X7ieLTItulxJ3A0QGL2tSAmCCfyuQa4=; b=P
	vMeL3dMGXUOwKSlI/tqZpA9wLaDFKpmbhIIGRCbUoRbC91COahJ+lxup6QCXt3fK
	l/bLhkzvnO4223mYjMfqheaoJ9aCBc2/ZaOdYErqim+BZfFo1q/xomjWb1Bl06db
	nt8QxO5D6WYW12E1WkWYOiAIvjMiml8f3uuTMBKRoxncRPh993pbk7tOFVtZyfjI
	CbyaNnM55Fb1Gy2l4osBcPfSYMUQE2011al2iUX6CpP3JBKB0R0giGKmoFwqBOz9
	7Mj0UGuryh9AvH9cukDbHFksvpqPFYL2HIVtue/naZUqkbLgNmkV8JrBwX2URYLw
	vEr8r1urQYe8u3DA2e90g==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgddujedukecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpefhvfevufffkffojghfgggtgfesthekredtredtjeenucfhrhhomhepofgrrhgvkhcu
    ofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvih
    hsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepffeitdeg
    veffteelvdeghffhvefghfefkeelheeujeejgedvvdfgffejuedtvdelnecuffhomhgrih
    hnpehkvghrnhgvlhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhep
    mhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrg
    gsrdgtohhmpdhnsggprhgtphhtthhopeegpdhmohguvgepshhmthhpohhuthdprhgtphht
    thhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdprh
    gtphhtthhopehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgt
    ohhmpdhrtghpthhtoheptggrrhguohgvsegtrghrughovgdrtghomhdprhgtphhtthhope
    hsshhtrggsvghllhhinhhisehkvghrnhgvlhdrohhrgh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Doug Goldstein ,
	Stefano Stabellini 
Subject: [PATCH v1 1/6] CI: Switch x86 tests to 6.12.34 kernel
Date: Mon, 23 Jun 2025 15:47:10 +0200
Message-ID: <56c63be504a72b689591b1888970fc5d340d0649.1750686195.git-series.marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This is necessary for the upcoming Zen4 runner.

Signed-off-by: Marek Marczykowski-Górecki 
---
Previous version posted in https://lore.kernel.org/xen-devel/cover.7da1777882774486a13e6f39ff4a2096f6b7901e.1744028549.git-series.marmarek@invisiblethingslab.com/T/#u (but actual patch didn't make it into the ML, as it contained dockerfile change...)
---
 automation/gitlab-ci/test.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
index 842cecf71382..1b88ee5c3be7 100644
--- a/automation/gitlab-ci/test.yaml
+++ b/automation/gitlab-ci/test.yaml
@@ -21,7 +21,7 @@
 
 .x86-64-test-needs: &x86-64-test-needs
   - project: xen-project/hardware/test-artifacts
-    job: linux-6.6.56-x86_64
+    job: linux-6.12.34-x86_64
     ref: master
   - project: xen-project/hardware/test-artifacts
     job: alpine-3.18-x86_64-rootfs
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 13:51:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 13:51:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022419.1398243 (Exim 4.92)
	(envelope-from )
	id 1uThZi-0001WZ-Lv; Mon, 23 Jun 2025 13:51:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022419.1398243; Mon, 23 Jun 2025 13:51:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uThZi-0001WS-Ig; Mon, 23 Jun 2025 13:51:06 +0000
Received: by outflank-mailman (input) for mailman id 1022419;
 Mon, 23 Jun 2025 13:51: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 1uThWT-00048y-Jk
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 13:47:45 +0000
Received: from fhigh-a4-smtp.messagingengine.com
 (fhigh-a4-smtp.messagingengine.com [103.168.172.155])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a332b7c6-5038-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 15:47:44 +0200 (CEST)
Received: from phl-compute-01.internal (phl-compute-01.phl.internal
 [10.202.2.41])
 by mailfhigh.phl.internal (Postfix) with ESMTP id 540961140116;
 Mon, 23 Jun 2025 09:47:43 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-01.internal (MEProxy); Mon, 23 Jun 2025 09:47:43 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 23 Jun 2025 09:47:42 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a332b7c6-5038-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm1; t=1750686463; x=1750772863; bh=9XIkvx7Zeg
	GJbUPHIjWIHAcZyOUIf+gSu0BR8Znt0MU=; b=Jv0XOW2f1uvk9g3nBGyuS3cgCI
	9Hck2RBqBnWvINcyrDcpMpqsI+ODcmoQfw+cq4JOUPXXDiejQ/iPlzxAiDpvfQXP
	yh2TaV1A9PuKoIlKKpeE9ctEEtBbKD+3cgYoLqdFIxwyCXRyFolQttX4vaaU5/YB
	mLl0q7Of55hbe1dxTYJGfmnICrRtId5It0cYWKtoNrrPYqfYr77rGCpKgeZS7eLo
	/SYGRCSlyeEqOrFL7TAbaBWwK4exeYyU/WhmEPiXT8l0icy3ZxpbIJEGuKG5uxzU
	yFqC205sCxUWCIb7E2O/G8/DVT2SLUOwSh8LNlvX6pgTcATmW9K+WCPDeW1A==
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=1750686463; x=
	1750772863; bh=9XIkvx7ZegGJbUPHIjWIHAcZyOUIf+gSu0BR8Znt0MU=; b=d
	ki96eBK3q28a2UC1a6D1JLsiVcQV4Rr7Od/JyC7AkVwP0fD0G0qLK3M5+snQgOLU
	K+d4mLJym2+UwZj9x1Ub82sFHYp8f2WoRs5wCn17b5kHg+8f3UG6GR/En6DgeP4N
	eYNQ9L6wKsU9mLavcphgzHasOzovS7jW5gsJgwJAWoaIreIVgKibP7Km+K0taZMZ
	qe8JXjfLzS2479OneA5KgGIm26mFlMuq8R6i2oTrZrSeF2kGL4IqVDtuAngvDx1Z
	GriFApbhGXE6+fYVkbOAQRknKLyoQgnkDWvCCCYmjT8ehB4J2n/urnmf4dz/d+1i
	dRIfE1DGQuxRotykg3kmA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgddujedukecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpefhvfevufffkffojghfgggtgfesthekredtredtjeenucfhrhhomhepofgrrhgvkhcu
    ofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvih
    hsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfeuudeh
    gfdvfeehhedujeehfeduveeugefhkefhheelgeevudetueeiudfggfffnecuvehluhhsth
    gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehi
    nhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepgedpmh
    houggvpehsmhhtphhouhhtpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdr
    gigvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtohepmhgrrhhmrghrvghksehinhhvih
    hsihgslhgvthhhihhnghhslhgrsgdrtghomhdprhgtphhtthhopegtrghrughovgestggr
    rhguohgvrdgtohhmpdhrtghpthhtohepshhsthgrsggvlhhlihhniheskhgvrhhnvghlrd
    horhhg
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Doug Goldstein ,
	Stefano Stabellini 
Subject: [PATCH v1 5/6] CI: use Alpine's network setup
Date: Mon, 23 Jun 2025 15:47:14 +0200
Message-ID: <041efab43d46d82553fb156ae7f01cd7d7ace2fe.1750686195.git-series.marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This allows Alpine startup script to properly handle service
dependencies - necessary for starting dropbear ssh server.
For the latter, always take the IP address from DHCP, in addition to the
test-local one.

Signed-off-by: Marek Marczykowski-Górecki 
---
 automation/scripts/qubes-x86-64.sh | 20 +++++++++-----------
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qubes-x86-64.sh
index 2750d24eba17..cf040a29856b 100755
--- a/automation/scripts/qubes-x86-64.sh
+++ b/automation/scripts/qubes-x86-64.sh
@@ -214,25 +214,23 @@ cat "${dom0_rootfs_parts[@]}" > binaries/dom0-rootfs.cpio.gz
 # test-local configuration
 mkdir -p rootfs
 cd rootfs
-mkdir -p boot etc/local.d root
+mkdir -p boot etc/local.d root etc/network
 cp -a ../automation/scripts/run-tools-tests root/
 
+echo "
+auto xenbr0
+iface xenbr0 inet dhcp
+    bridge-ports eth0
+    bridge-stp 0
+    up ip a a 192.168.0.1/24 dev \$IFACE
+" > etc/network/interfaces
+
 echo "#!/bin/bash
 
 bash /etc/init.d/xencommons start
 
-brctl addbr xenbr0
-brctl addif xenbr0 eth0
-ifconfig eth0 up
-ifconfig xenbr0 up
-ifconfig xenbr0 192.168.0.1
-
 " > etc/local.d/xen.start
 
-if [ -n "$retrieve_xml" ]; then
-    echo "timeout 30s udhcpc -i xenbr0" >> etc/local.d/xen.start
-fi
-
 if [ -n "$domU_check" ]; then
     echo "
 # get domU console content into test log
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 13:51:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 13:51:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022430.1398255 (Exim 4.92)
	(envelope-from )
	id 1uThZu-000232-U4; Mon, 23 Jun 2025 13:51:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022430.1398255; Mon, 23 Jun 2025 13: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 1uThZu-00022v-Q4; Mon, 23 Jun 2025 13:51:18 +0000
Received: by outflank-mailman (input) for mailman id 1022430;
 Mon, 23 Jun 2025 13:51: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 1uThWR-00048y-3u
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 13:47:43 +0000
Received: from fhigh-a4-smtp.messagingengine.com
 (fhigh-a4-smtp.messagingengine.com [103.168.172.155])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a1b77b1c-5038-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 15:47:41 +0200 (CEST)
Received: from phl-compute-04.internal (phl-compute-04.phl.internal
 [10.202.2.44])
 by mailfhigh.phl.internal (Postfix) with ESMTP id D190511401A3;
 Mon, 23 Jun 2025 09:47:40 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-04.internal (MEProxy); Mon, 23 Jun 2025 09:47:40 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 23 Jun 2025 09:47:39 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a1b77b1c-5038-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm1; t=1750686460; x=1750772860; bh=aD3ow6S5dt
	waOUDKDHpJxMSWCeAGUGRzl6OblX2n4jc=; b=J02puwvHlegt/ferO6+arj+bDW
	0xKAbdFdu9L2MAp12qdEfv3G8TURHvzOmi8sqWKqFlb6xq8Fyd5gm5PzmQK+ebhb
	WDTjTiEPsS4/WSbbyhQKcBc3ZVtTjetsb2Iq8yn/kBD99PWp5JAopmiSVJVw78H/
	FIKFXRWAfWjfpi7I5/AkNiymtqOxQHDzZd4NApVGPfewpFBzGugTztfpqlk45Bwn
	lpmlREkv7FHBNdcKhhlGQaAXdt3VFB1+hFuQnE8xlO3lJTSJQ2u8haQwfQKc8OFs
	o3/Dknc88gv1p4jjEqafDTF5ndL+3JBSNxblSvzahliaEJ3e+5R0TMz2Gkxg==
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=1750686460; x=
	1750772860; bh=aD3ow6S5dtwaOUDKDHpJxMSWCeAGUGRzl6OblX2n4jc=; b=c
	CAT9HGN3VhY2ulaEOE3rJdSJzbhwZWuXjMEKxERL9WErT9wotl64Ifr+zpIKXBHl
	eVGU6uA3XgP/UJcCcgJr1anACiMyqgQzFxmXyWd/sovnhPVjQJX34EGVp61v995C
	ZVlsWK7z8Zto2W6COJcQLQkbZ1cOMHofcChaeJeySCDWW9aj9XLfF5bqF6K2T1KV
	NI5DRZRTebTiZLKGhesrNZ8jlvY3x3wU6QN/Ni09E6mtbI3tnhjAL5jtCWq40RbZ
	BPrNiZtExp23cE9ktQ/oLphOecY95WmLUglTHuSN/CTGim5woDqYu/r35x5FRrFd
	U8I7UTUe8MA9DvPaj1ycA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgddujedukecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpefhvfevufffkffojghfgggtgfesthekredtredtjeenucfhrhhomhepofgrrhgvkhcu
    ofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvih
    hsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfeuudeh
    gfdvfeehhedujeehfeduveeugefhkefhheelgeevudetueeiudfggfffnecuvehluhhsth
    gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehi
    nhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepgedpmh
    houggvpehsmhhtphhouhhtpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdr
    gigvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtohepmhgrrhhmrghrvghksehinhhvih
    hsihgslhgvthhhihhnghhslhgrsgdrtghomhdprhgtphhtthhopegtrghrughovgestggr
    rhguohgvrdgtohhmpdhrtghpthhtohepshhsthgrsggvlhhlihhniheskhgvrhhnvghlrd
    horhhg
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Doug Goldstein ,
	Stefano Stabellini 
Subject: [PATCH v1 3/6] CI: upload tests-junit.xml as a normal artifact too
Date: Mon, 23 Jun 2025 15:47:12 +0200
Message-ID: <84bdfa33c8382080bb78fbf3a0b46e4dfd6b9187.1750686195.git-series.marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This allows checking the file if gitlab can't parse it for some reason.

Signed-off-by: Marek Marczykowski-Górecki 
---
 automation/gitlab-ci/test.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
index a9d871cf72ad..dc08488e76f4 100644
--- a/automation/gitlab-ci/test.yaml
+++ b/automation/gitlab-ci/test.yaml
@@ -155,6 +155,7 @@
     paths:
       - smoke.serial
       - '*.log'
+      - tests-junit.xml
     when: always
   rules:
     - if: $SELECTED_JOBS_ONLY && $CI_JOB_NAME =~ $SELECTED_JOBS_ONLY
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 13:51:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 13:51:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022431.1398260 (Exim 4.92)
	(envelope-from )
	id 1uThZv-00026a-6r; Mon, 23 Jun 2025 13:51:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022431.1398260; Mon, 23 Jun 2025 13: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 1uThZv-000266-23; Mon, 23 Jun 2025 13:51:19 +0000
Received: by outflank-mailman (input) for mailman id 1022431;
 Mon, 23 Jun 2025 13:51: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 1uThWU-00048y-VA
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 13:47:46 +0000
Received: from fhigh-a4-smtp.messagingengine.com
 (fhigh-a4-smtp.messagingengine.com [103.168.172.155])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a3fbc67a-5038-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 15:47:45 +0200 (CEST)
Received: from phl-compute-06.internal (phl-compute-06.phl.internal
 [10.202.2.46])
 by mailfhigh.phl.internal (Postfix) with ESMTP id 97AB311400CA;
 Mon, 23 Jun 2025 09:47:44 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-06.internal (MEProxy); Mon, 23 Jun 2025 09:47:44 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 23 Jun 2025 09:47:43 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a3fbc67a-5038-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	: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=1750686464; x=1750772864; bh=sZVLbSs4nB7LGE4gIMwQS
	1mLqB9TPuKDluXnxQTuE1U=; b=l6w+jpG8tdiGF1lkw6B4vcYw+qY91X6FycNLI
	qRFDybkAXJFo1UQkNjCoVCGQRHRM4D5/XqYnO+fsmefjY42nhEIk1bkAdHd0IZsI
	wfaobgB9PhAwMX3c6djvUJs+kxL55fW31UmhidCtjTXFJtgtydB9OQYP3rAJSRIt
	VczNbTMxh8Ke29PxyKo7oQ2415bYHinSxzdS+VQHavrZ1CfcT0pu7XRHVGl8koFB
	e+Ol2StrNIBXkfz+Yvcbn6rZAJ8lpaF0NxzAKPwgqWHcOlAzCgC+uzSbyrNskm5m
	e4i4959k3sxBqv/SOJYPZw50SDm11tmEGRhQVleCH7vTfLpog==
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: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=1750686464; x=1750772864; bh=s
	ZVLbSs4nB7LGE4gIMwQS1mLqB9TPuKDluXnxQTuE1U=; b=f2XR2UrTAdhWCSWnH
	VuKIpRx/vEoW7cKfcoH1860qH7GM3jL9gBzZysC+vL3WxY6MMvwWfC+vQH91uG5j
	2InOvwxKR6rt4qvqBgA5Hq1EwRLVAyyXPL7I77cGHmtRTlk8yNL9OYd1HPeOgaCL
	+am5Bu7lJH9itMY2Wao8Mk2oxQvouzs3p+dhA8fB6QPCGTIEJ/e2UM8PSJXYZ4LT
	HUjHcm4c2T1Tyl0vPE8kiKy3Ziq28QLk4T0Abh3D3yNL0fMjinqcpynDeMZms5mC
	PLfsHcogBKpvaliY05Yz2EVS8MaFCWgJa/00daAnfI9wR012osERNJLRwv5AJ8iP
	MAzuw==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgddujedukecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpefhvfevufffkffojghfggfgsedtkeertdertdejnecuhfhrohhmpeforghrvghkucfo
    rghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhish
    hisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpeevleejfeeh
    vddvvdeiveefjefgtefhuedtjeetveeuffejgeekvedttdehhffgtdenucevlhhushhtvg
    hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhn
    vhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopeegpdhmoh
    guvgepshhmthhpohhuthdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdig
    vghnphhrohhjvggtthdrohhrghdprhgtphhtthhopehmrghrmhgrrhgvkhesihhnvhhish
    hisghlvghthhhinhhgshhlrggsrdgtohhmpdhrtghpthhtoheptggrrhguohgvsegtrghr
    ughovgdrtghomhdprhgtphhtthhopehsshhtrggsvghllhhinhhisehkvghrnhgvlhdroh
    hrgh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Doug Goldstein ,
	Stefano Stabellini 
Subject: [PATCH v1 6/6] [DO NOT MERGE] CI: example how to use ssh to extract logs
Date: Mon, 23 Jun 2025 15:47:15 +0200
Message-ID: <9e10434c1e5ff6edb53b9efc65485247ad450f0c.1750686195.git-series.marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

---
 automation/scripts/qubes-x86-64.sh | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qubes-x86-64.sh
index cf040a29856b..944d0c6d383f 100755
--- a/automation/scripts/qubes-x86-64.sh
+++ b/automation/scripts/qubes-x86-64.sh
@@ -292,6 +292,8 @@ export TEST_LOG="smoke.serial"
 export TEST_TIMEOUT="$timeout"
 ./automation/scripts/console.exp | sed 's/\r\+$//'
 TEST_RESULT=$?
+ssh -o StrictHostKeyChecking=no root@$SUT_ADDR xl dmesg || :
+ssh -o StrictHostKeyChecking=no root@$SUT_ADDR dmesg || :
 
 if [ -n "$retrieve_xml" ]; then
     nc -w 10 "$SUT_ADDR" 8080 > tests-junit.xml 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 13:51:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022433.1398273 (Exim 4.92)
	(envelope-from )
	id 1uThZy-0002b6-FD; Mon, 23 Jun 2025 13:51:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022433.1398273; Mon, 23 Jun 2025 13:51: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 1uThZy-0002av-Bs; Mon, 23 Jun 2025 13:51:22 +0000
Received: by outflank-mailman (input) for mailman id 1022433;
 Mon, 23 Jun 2025 13: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 1uThWP-0004sG-0c
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 13:47:41 +0000
Received: from fhigh-a4-smtp.messagingengine.com
 (fhigh-a4-smtp.messagingengine.com [103.168.172.155])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a1043072-5038-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 15:47:40 +0200 (CEST)
Received: from phl-compute-08.internal (phl-compute-08.phl.internal
 [10.202.2.48])
 by mailfhigh.phl.internal (Postfix) with ESMTP id A547D114015A;
 Mon, 23 Jun 2025 09:47:39 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-08.internal (MEProxy); Mon, 23 Jun 2025 09:47:39 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 23 Jun 2025 09:47:38 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a1043072-5038-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm1; t=1750686459; x=1750772859; bh=U6TR5I9wcC
	fnv1sKQpBd62+VqvdLWnBwgNaz4GebnSI=; b=YJo9CxzEEqAsmupJmRAmP6IOiP
	aJujjDW63kCGaElzWbDpTlYlDy+JEFXZ8hDWCZFvdyrqHbWQs2LUqBK9ABLmpFH1
	ggeSAOGr3h+YbmjHwwfPz3gFFoim+paGqWcPqOTNJhG3CRqFGQoeyaYhEyNZiWgt
	VH0mRqseVlamiM0AeDLl4bA6QvUAol3FbbvF/wPSdZZVgxnKHrF8zJTWLVF5xPuJ
	t84wg5bb8lL596Lx+Y/EgIg+YfSX75mhz0qJ3LNzNZ9fRKRaNdKV2q/5q02PcVt3
	VGdbeaVwSOEFwyVjPrvCzePjbS9PDWmxwFZOe6GxMflbnswhSzlQddjlt6lw==
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=1750686459; x=
	1750772859; bh=U6TR5I9wcCfnv1sKQpBd62+VqvdLWnBwgNaz4GebnSI=; b=o
	C3q3MEfcXd8q22lWBBy6iR8MHfR9iDxRvhA1jjWD/o+/lU6+OJnjwn1ED3HbjtD3
	fq26ajnjk2OLJPk/jg9WPUvdDAcERGvWJB0Mqo9T5Zf74zIS4k3K3cI6nR/OVFFw
	ZqMP6p6L/eb2acIoOxSbKg++JdLviBfAL66nX7NjBzzpFubWa7n5VWD2zg1bEnLT
	uZk6pRCXUZsaj4y6WkBj4+9DlTkY0PG3kYQGOxtSqz55XMx3qTYNnoqD7XJlWwfm
	i9f5xF20ItLJCJzdvikVMg7TOyR0KyK4lQwWlTY8j7tTcKL7so92q6SStrKsZSd7
	S6FhXFtLxTKWaIrKDxZtQ==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgddujedukecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpefhvfevufffkffojghfgggtgfesthekredtredtjeenucfhrhhomhepofgrrhgvkhcu
    ofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvih
    hsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepffeitdeg
    veffteelvdeghffhvefghfefkeelheeujeejgedvvdfgffejuedtvdelnecuffhomhgrih
    hnpehkvghrnhgvlhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhep
    mhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrg
    gsrdgtohhmpdhnsggprhgtphhtthhopeegpdhmohguvgepshhmthhpohhuthdprhgtphht
    thhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdprh
    gtphhtthhopehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgt
    ohhmpdhrtghpthhtohepshhsthgrsggvlhhlihhniheskhgvrhhnvghlrdhorhhgpdhrtg
    hpthhtoheptggrrhguohgvsegtrghrughovgdrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Stefano Stabellini ,
	Doug Goldstein 
Subject: [PATCH v1 2/6] CI: add AMD Zen 4 HW runner
Date: Mon, 23 Jun 2025 15:47:11 +0200
Message-ID: <57ddf8058a966d98e3fbfa923de567553ea712c0.1750686195.git-series.marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This is AMD Ryzen 5 7640U in Framework Laptop AMD.
It has several things different than the other runners.
First of all, the console is using XHCI debug capability.
And then, this system doesn't have normal wired ethernet. But is has one
on USB, and this one is used for booting. For this, enable
CONFIG_USB_RTL8152 in the Linux build.

Include some basic tests, plus PCI passthrough.

This machine doesn't support S3. S0ix pretends to be working with
Qubes's dom0 (kernel + userspace), but it hangs on suspend with Alpine
used in test. But even when it doesn't hang, it doesn't really reach
deep sleep, so skip this test for now here.

Signed-off-by: Marek Marczykowski-Górecki 
Reviewed-by: Stefano Stabellini 
---
Previous version posted at https://lore.kernel.org/xen-devel/cover.7da1777882774486a13e6f39ff4a2096f6b7901e.1744028549.git-series.marmarek@invisiblethingslab.com/T/#u
Unchanged since then.
---
 automation/gitlab-ci/test.yaml | 56 +++++++++++++++++++++++++++++++++++-
 1 file changed, 56 insertions(+)

diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
index 1b88ee5c3be7..a9d871cf72ad 100644
--- a/automation/gitlab-ci/test.yaml
+++ b/automation/gitlab-ci/test.yaml
@@ -197,6 +197,16 @@
   tags:
     - qubes-hw11
 
+.zen4-x86-64:
+  extends: .adl-x86-64
+  variables:
+    PCIDEV: "c3:00.4"
+    PCIDEV_INTR: "MSI-X"
+    CONSOLE_OPTS: "console=xhci dbgp=xhci@pcic1:00.3,share=yes"
+    SUT_ADDR: test-12.testnet
+  tags:
+    - qubes-hw12
+
 # Test jobs
 build-each-commit-gcc:
   extends: .test-jobs-common
@@ -488,6 +498,52 @@ zen3p-tools-tests-pvh-x86-64-gcc-debug:
     - *x86-64-test-needs
     - alpine-3.18-gcc-debug
 
+zen4-smoke-x86-64-gcc-debug:
+  extends: .zen4-x86-64
+  script:
+    - ./automation/scripts/qubes-x86-64.sh dom0pv 2>&1 | tee ${LOGFILE}
+  needs:
+    - *x86-64-test-needs
+    - alpine-3.18-gcc-debug
+
+zen4-smoke-x86-64-dom0pvh gcc-debug:
+  extends: .zen4-x86-64
+  script:
+    - ./automation/scripts/qubes-x86-64.sh dom0pvh 2>&1 | tee ${LOGFILE}
+  needs:
+    - *x86-64-test-needs
+    - alpine-3.18-gcc-debug
+
+zen4-pci-hvm-x86-64-gcc-debug:
+  extends: .zen4-x86-64
+  script:
+    - ./automation/scripts/qubes-x86-64.sh pci-hvm 2>&1 | tee ${LOGFILE}
+  needs:
+    - *x86-64-test-needs
+    - alpine-3.18-gcc-debug
+
+zen4-tools-tests-pv-x86-64-gcc-debug:
+  extends: .zen4-x86-64
+  script:
+    - ./automation/scripts/qubes-x86-64.sh tools-tests-pv 2>&1 | tee ${LOGFILE}
+  artifacts:
+    reports:
+      junit: tests-junit.xml
+  needs:
+    - *x86-64-test-needs
+    - alpine-3.18-gcc-debug
+
+zen4-tools-tests-pvh-x86-64-gcc-debug:
+  extends: .zen4-x86-64
+  script:
+    - ./automation/scripts/qubes-x86-64.sh tools-tests-pvh 2>&1 | tee ${LOGFILE}
+  artifacts:
+    reports:
+      junit: tests-junit.xml
+  needs:
+    - *x86-64-test-needs
+    - alpine-3.18-gcc-debug
+
 qemu-smoke-dom0-arm64-gcc:
   extends: .qemu-arm64
   script:
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 13:51:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 13:51:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022435.1398283 (Exim 4.92)
	(envelope-from )
	id 1uThZz-0002tS-Sl; Mon, 23 Jun 2025 13:51:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022435.1398283; Mon, 23 Jun 2025 13: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 1uThZz-0002tF-Ph; Mon, 23 Jun 2025 13:51:23 +0000
Received: by outflank-mailman (input) for mailman id 1022435;
 Mon, 23 Jun 2025 13: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 1uThWR-0004sG-Hr
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 13:47:43 +0000
Received: from fout-a3-smtp.messagingengine.com
 (fout-a3-smtp.messagingengine.com [103.168.172.146])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a278ca05-5038-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 15:47:42 +0200 (CEST)
Received: from phl-compute-08.internal (phl-compute-08.phl.internal
 [10.202.2.48])
 by mailfout.phl.internal (Postfix) with ESMTP id 1D40613805FF;
 Mon, 23 Jun 2025 09:47:42 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-08.internal (MEProxy); Mon, 23 Jun 2025 09:47:42 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 23 Jun 2025 09:47:41 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a278ca05-5038-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm1; t=1750686462; x=1750772862; bh=VguRMJhpxw
	xq/YO8TuwoUJYN3PnY9OBoKFJfvWdIwJY=; b=FO4LfyRYsrbYasRaQe+6igoUdc
	VSdS3uUQACGtkNEXBZ5P6nvHgrUZ4KcV/Blqp3Xin1G70kwxtMJ+u06DtV0nsxJd
	FgUe0j2ELdYHjTrOx4Bq/JJUMUUqjwSWywBCj0ZGSzbHwCNrx1DyCwnL5PqocMoO
	xwmMSrQ+iXhN5DI9MtG/lhI70nd8qHa0vVW9SrFCOcTsJZUqbOw1WZzeksOWylrn
	uBVW+t3ibPzAGKKlyYXEMdgUWlHeOnnzSANT7SfQ6G1eblPB+hNWVEYDVr1iwP5u
	DbC//VXk19cCYFdic1tI/BEolLLlvQmIMXHfhE0cFYI4ddlaBGd4CxpzEtGg==
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=1750686462; x=
	1750772862; bh=VguRMJhpxwxq/YO8TuwoUJYN3PnY9OBoKFJfvWdIwJY=; b=i
	fP3VImKvFyZ0iWdLJ1VPH6+3JJjFeJjpltU3aXBc1VNy2RMnxfQcq2j14ezysiRu
	khrmEpk8t3srE5QS+tEHdz9ETPjLbQKZ+DbVN46sFtZINcfSg6qXIqYvi8A9HD3f
	qgZFKJvHDRoK7MoACDHay6r6mLfDCVyVAE6n5bDkNKctW7AKnpYyCpGkNI2woZ0D
	YvPfhDPOfZc4RuWzikJXCXVrC3wu3gQUMeEIvDGIrn0FFNxM87kQ4QqaBiklaelB
	q/NLnlXsXNp14Uv4MtXGX5OUef3+OJC54hGqw3DA3Y82FlVLqfRN64Hr9ZS9HMY7
	ZIiGE8mmQEU2Aq5gvOI6g==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgddujedukecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpefhvfevufffkffojghfgggtgfesthekredtredtjeenucfhrhhomhepofgrrhgvkhcu
    ofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvih
    hsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepleeftdef
    gfffgffhvefhhedvieelheehffeukeeiteeffffhteeggffgjedugfegnecuffhomhgrih
    hnpehgihhtlhgrsgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhep
    mhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrg
    gsrdgtohhmpdhnsggprhgtphhtthhopeegpdhmohguvgepshhmthhpohhuthdprhgtphht
    thhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdprh
    gtphhtthhopehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgt
    ohhmpdhrtghpthhtoheptggrrhguohgvsegtrghrughovgdrtghomhdprhgtphhtthhope
    hsshhtrggsvghllhhinhhisehkvghrnhgvlhdrohhrgh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Doug Goldstein ,
	Stefano Stabellini 
Subject: [PATCH v1 4/6] CI: make test-artifacts branch/job customizable
Date: Mon, 23 Jun 2025 15:47:13 +0200
Message-ID: <7c032d51b6183888cb0fcb71662b452fd9cb5a20.1750686195.git-series.marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Allow choosing which artifacts branch and job to use for Linux. This
allows running the same tests for different Linux versions, without
duplicating a lot of yaml sections.

Signed-off-by: Marek Marczykowski-Górecki 
---
I have considered common LINUX_JOB and then add architecture suffix, but
even now X86 and ARM use different jobs, so I made them separate.
---
 .gitlab-ci.yml                 |  9 +++++++++
 automation/gitlab-ci/test.yaml |  8 ++++----
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 7974ac4e82bc..c1d92dc485e7 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -2,6 +2,15 @@ variables:
   XEN_REGISTRY: registry.gitlab.com/xen-project/xen
   SELECTED_JOBS_ONLY:
     description: "Regex to select only some jobs, must be enclosed with /. For example /job1|job2/"
+  LINUX_ARTIFACTS_BRANCH:
+    description: "Branch in test-artifacts to use for Linux"
+    value: master
+  LINUX_JOB_X86_64:
+    description: "Job name in test-artifacts to use for Linux x86_64"
+    value: linux-6.12.34-x86_64
+  LINUX_JOB_ARM64:
+    description: "Job name in test-artifacts to use for Linux arm64"
+    value: linux-6.6.86-arm64
 
 workflow:
   name: "$CI_PIPELINE_SCHEDULE_DESCRIPTION"
diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
index dc08488e76f4..9fd66fb6138d 100644
--- a/automation/gitlab-ci/test.yaml
+++ b/automation/gitlab-ci/test.yaml
@@ -9,8 +9,8 @@
 
 .arm64-test-needs: &arm64-test-needs
   - project: xen-project/hardware/test-artifacts
-    job: linux-6.6.86-arm64
-    ref: master
+    job: $LINUX_JOB_ARM64
+    ref: $LINUX_ARTIFACTS_BRANCH
   - project: xen-project/hardware/test-artifacts
     job: alpine-3.18-arm64-rootfs
     ref: master
@@ -21,8 +21,8 @@
 
 .x86-64-test-needs: &x86-64-test-needs
   - project: xen-project/hardware/test-artifacts
-    job: linux-6.12.34-x86_64
-    ref: master
+    job: $LINUX_JOB_X86_64
+    ref: $LINUX_ARTIFACTS_BRANCH
   - project: xen-project/hardware/test-artifacts
     job: alpine-3.18-x86_64-rootfs
     ref: master
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 13:56:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 13:56:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022467.1398294 (Exim 4.92)
	(envelope-from )
	id 1uTheW-0004ZD-HD; Mon, 23 Jun 2025 13:56:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022467.1398294; Mon, 23 Jun 2025 13:56: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 1uTheW-0004Z6-C9; Mon, 23 Jun 2025 13:56:04 +0000
Received: by outflank-mailman (input) for mailman id 1022467;
 Mon, 23 Jun 2025 13:56: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 1uTheV-0004Z0-4C
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 13:56:03 +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 cc44cc2a-5039-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 15:56:02 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3a4e742dc97so3116671f8f.0
 for ; Mon, 23 Jun 2025 06:56:02 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4535e741b43sm147930355e9.0.2025.06.23.06.56.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 06:56:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cc44cc2a-5039-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750686961; x=1751291761; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=XqUSitsWp2pgteXZh00gKZ4QeO/aJjEcSFPz25bEpNA=;
        b=fEWmEv6vrU9t4VlawfEk53TfEr8/bGMQyWzTLoP9UIcaWvViBj8V6tSfDrshuNRp3L
         vJ3t4+kS7UF8YkNhGwZ9ASHxsW4+qvg0PEm7uVBjSuz1a/VTwNPKhVlDH9xurlAQGZ2F
         eIK1FVL6nlDltzLUWab8zTVLGX2nsar6qVC7g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750686961; x=1751291761;
        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=XqUSitsWp2pgteXZh00gKZ4QeO/aJjEcSFPz25bEpNA=;
        b=hoywiwcvGp0NaQz5xo8VqN+3TxAatnUdCH4EpHdRoUt4EHP0nKJPokVSQDD36ogQi3
         1ccA3K9sJm8dDZLM4i/Rphrhn+j4fkQG3cR4NigpcPx+hoakqc9G9Ar/Zt864THIrqZh
         aw4wpCNES0MhrExSnh7SmyhtCrTvaasx1BC5PFh9fVQOweK6swfwuOm4a2HP2jNZ9pV7
         xv261iEg9GiU5cMk35hNqM48KEz/r3PdZ2j0f53GX1mXA3woicO3qNztf4DcOBcehWGf
         ac3DA6cVt/CTuk3cQpWAUsT5wybdqcdzfVZuCloLNwRksX1yq71S/RYVrW5GHlxW+GLb
         KoMw==
X-Forwarded-Encrypted: i=1; AJvYcCWtg2oZAoLAj+kIV+/qdDBmS1iZQx1K52cYyZrPZsweK6IR4iM0VliBcG55uPlYt99GGKIj+l8ClnM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzqMgG/KgURi+UcbBfBo3+vuuH01B7KaNQJKAhAxNNYlOhZZk34
	CKn3PqdFzeaOS6sdImav07T2yxfhfr2iWc/kbE6FYTngJbypnvr3NAPTb5iTjgL8xQeWtdhQa0k
	89/AtfDzY6A==
X-Gm-Gg: ASbGncutCLeY+TqAuna38tmQkiBMfw9VfH/R+J7ZfN23iY0CSVEhcfUmlyOKt5An1Z7
	aGO64CSyp5nmyZjxQJC6XnQ0H5rLpolR/ZOprgoEdLy23D1RrY7KSTSLx2hn7JnlbAwwXbd7DYa
	w3rZ0nKV6AkFA8TYgs47ATmz5+/V4TGWvp7ajX1MyNaxlxH+lHa+QfmVOYDpDT4vM7NhnoRLJLE
	tr82Zb1ryer1EOyDGGXto7ed1gzIKT/fBEf3ZYBVw1IveIV8JwbvvDJzuUnRu1vZpRlWhHC4e/C
	L3ptL0N/cUME5h0dXHq3BTWECKRsfl8WYH8XHj44DRrjh2w3yrFWOxCo57gMV7ThwuAUeC5v8zT
	c/KFNq39HG8OoUGlj4CeBZN9mqEQqbuqGhMd1kA==
X-Google-Smtp-Source: AGHT+IES/BbpeOXvlZ4HaHFPdFSD6d09ypUhq1RpZp7cppTo2Iyh9/Iym6WFaPLQR99v84OJxRVJUQ==
X-Received: by 2002:a05:6000:d82:b0:3a5:271e:c684 with SMTP id ffacd0b85a97d-3a6d27ef37cmr8355325f8f.24.1750686961408;
        Mon, 23 Jun 2025 06:56:01 -0700 (PDT)
Message-ID: 
Date: Mon, 23 Jun 2025 14:56:00 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH test-artifacts v1 5/5] Setup ssh access to test systems
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
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 23/06/2025 2:46 pm, Marek Marczykowski-Górecki wrote:
> For this add also bridge package, so xenbr0 can be configured with
> /etc/network/interfaces.
> This allows extracting more logs out of the test system.
>
> Signed-off-by: Marek Marczykowski-Górecki 
> ---
> This enables passwordless root login. It's okay for qubes runners, as
> they are isolated (even from each other). Is that okay in other places
> too?

It's potentially a problem on a corporate network.

Can't we have each job generate a random password an insert it via the
dom0-rootfs overlay?

Or alternatively have the runner drop a public key in
/root/.ssh/authorised_keys ?

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 13:56:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 13:56:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022473.1398305 (Exim 4.92)
	(envelope-from )
	id 1uThfF-00052R-PC; Mon, 23 Jun 2025 13:56:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022473.1398305; Mon, 23 Jun 2025 13:56:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uThfF-00052K-K9; Mon, 23 Jun 2025 13:56:49 +0000
Received: by outflank-mailman (input) for mailman id 1022473;
 Mon, 23 Jun 2025 13:56: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 1uThfE-0004Z0-9J
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 13:56:48 +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 e791368a-5039-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 15:56:47 +0200 (CEST)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-451d54214adso28035445e9.3
 for ; Mon, 23 Jun 2025 06:56:47 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4536fefd2b4sm54221675e9.36.2025.06.23.06.56.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 06:56:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e791368a-5039-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750687007; x=1751291807; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=MYS/cFtMb+2a377AesoCZUHocGnwD5rZIpXKOgRdkQo=;
        b=OVRKAWa/cGV/6woHHsaILWAttCD2L+ctyn3wm+THJ95vFpswhh+ANzVKPRHMWsRY9J
         w+w0hE5dB9ypMZuo9zIH6PYJ1sx/FG9rgKqoC/EJ2/TCCBIWhT8zqdnC4S4/NX25w0KO
         KNAiaWePcfk94UKP07NiVtw3sJvwnYyr7mfd4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750687007; x=1751291807;
        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=MYS/cFtMb+2a377AesoCZUHocGnwD5rZIpXKOgRdkQo=;
        b=m0isi92LcGffg0G5j5ZYypI1MBLfXwz4+OjbnKbTmSfsguAKzR6v0UPNgXCCXdPoMS
         d4G0eiNg7yhmI3C5me0czrHbE9nNo5OlKytwRzJvgGIBIGxEbKqu3lWkTvN3FSJl8+8e
         dtc2ujl5pMP5p+hnxvdhFdhcMXwlK7RB5v3ngtHELO+OSpy4PkK5Q6U6UOpC/VJYaali
         S/AJoGDwqHFvHh8WpaDpr0hBKQElxG75sxvKmpaEbZE03eSJBmthHUbVVe/JHEbPIWNi
         4uVeggVdA1fqdBlric77mBlrfgmaeYjIQP0J90ayG0V0SIXLlwh0SG78PN4Py+l+2Yf3
         qH4g==
X-Forwarded-Encrypted: i=1; AJvYcCXPRQvVgv5L+I+UCajK9jlxyQY6H1ToIYzYUUHy/lGEdRpK1M0vAbdLU2UBRUSt4xk0ON+gPfgoRdo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzAMVE+RugQEOUgSU6R1vwUYVUBpgiQS2E/HVSGXDEVtATZ9tUz
	ES2mZ7cJ+0/ljKH08HQ1u7hYjoSwPD0VYJ13vUUk+cPGN2bdPDkhgSMxV2bGM1MJMhs=
X-Gm-Gg: ASbGncugD5oyLYQlTYmcwU2g7e9GSE6FRdv+qFqVA2U0435cL3JWz8IXlC+j5Zyn7cV
	+f1zAYIc+O7QRuMByZrYeUpjQopUWRFeMjfuIJyHRdcPgJ46EVQvYMiizcVJRxFY4A7VB1nROr+
	ZNmkhgHUio+28+XAyPaMrJqT5Hwz5CCtGr3lKWhjCcCJiqTwVjC+2UtbLpuyRV60bNg/433jbpL
	rNWFKhyCTINBzGvRQtD+hWNmyf+WmXB7QAAfxXHQm4/rnelRBrqWuV/E0tvgBLkFLNKipOuzUmB
	VgRAIc6Yg/hMlBWB/DK1/nJG4uzggLr4Jcz7VQ2EE52+esAj2c+7CvavOur9fTuBC6kWZtIIFXW
	cUN186mA9r++AY3eGQ/O8lhczDIU=
X-Google-Smtp-Source: AGHT+IHA/PoK6iWBQ/zI0QzbvhAnp+0CLEm7O/CWQlY3O5m1fx+1TvuA6h2d62f9uxHn1T84vsFC3A==
X-Received: by 2002:a05:600c:c48e:b0:442:c993:6f94 with SMTP id 5b1f17b1804b1-453659c58d6mr119371305e9.12.1750687007181;
        Mon, 23 Jun 2025 06:56:47 -0700 (PDT)
Message-ID: 
Date: Mon, 23 Jun 2025 14:56:46 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH test-artifacts v1 1/5] Add linux-6.12.34-x86_64
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: 
 <0a3e893e5fe133dc710d11a31006ba4f2c1b0cbe.1750684376.git-series.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: <0a3e893e5fe133dc710d11a31006ba4f2c1b0cbe.1750684376.git-series.marmarek@invisiblethingslab.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 23/06/2025 2:46 pm, Marek Marczykowski-Górecki wrote:
> This is necessary for new Zen4 runner.
> Do not include Argo module in this build, as it isn't compatible with
> 6.12 yet.
>
> Signed-off-by: Marek Marczykowski-Górecki 

Acked-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 13:57:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 13:57:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022478.1398313 (Exim 4.92)
	(envelope-from )
	id 1uThfi-0005VX-UG; Mon, 23 Jun 2025 13:57:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022478.1398313; Mon, 23 Jun 2025 13:57: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 1uThfi-0005VQ-Rh; Mon, 23 Jun 2025 13:57:18 +0000
Received: by outflank-mailman (input) for mailman id 1022478;
 Mon, 23 Jun 2025 13:57: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 1uThfi-0005JB-Bb
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 13:57:18 +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 f700ba07-5039-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 15:57:13 +0200 (CEST)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-451e2f0d9c2so27743835e9.1
 for ; Mon, 23 Jun 2025 06:57:13 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4535e97adf3sm143994475e9.8.2025.06.23.06.57.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 06:57:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f700ba07-5039-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750687033; x=1751291833; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=AwvKD5lXHtHsqlwOmCf5TSohJch8GLLCJydovtcct8o=;
        b=b3GVB9VoZFWH5+AE7/2pY/NE+Y264DWB2jNEqXNWLFUZ83GToKY6c4P69EPJ9w3nie
         VKZAxYb7Bso/lz3970VKTxWJNVS2tRln+ZvzEQJiehFeDgNVhutP5cSBedK+vrk1HDs2
         bboc+QEdfgUQXoCrv7VIhp0flGDZZJYwv/wIU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750687033; x=1751291833;
        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=AwvKD5lXHtHsqlwOmCf5TSohJch8GLLCJydovtcct8o=;
        b=bYHh9r9DG6ldmYLhuXDeo5qzbrzp2HsAC+HZwflUZt3JFzCFa0+Ya9x17znbIPA8K9
         AvBCQjaQPuzW9DCd9ymYYBZVvpzOAdNeWQEHdJbVXmOhq8FYx9OQ5LUI0laB05dRuOi7
         FQrRCDhFcuzPnfWkkV4PcBeEUQh57tsoRMrQhP6HVEpPj2yI4hDJvoWTt4kzDS+hEb/O
         WxYCbsmBuPmFwWxwJz7dJRN+wLxLQ5VjixC+KVV6fzO2Nlb1Epsl63KVeNDJ+2MUZnAf
         eGL28bg1mtqnds3zQv5v8CDF3Y+7Uo9yZB4OdEN2o19VGDpn6cdQAx5TdlFlhMGPJz8h
         d3Aw==
X-Forwarded-Encrypted: i=1; AJvYcCUEqfocUpZDt43kdfLfFL/sTQGDFA1b8oVTTh1SsvWkg3cE2nhDuo+DvC/qwkM2MbxdjjZflAr5mbA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxxUQFD3f+uQ31nwHBh6FnvWvrq5Fh86xiX2qLR3NgJnJOl7J0l
	BD6lVW08ReWbHxW4sKxC2L+4mLNDhKqunh2/dSHKg+IK7C5oWJvCeK6Tw049ujPB00I=
X-Gm-Gg: ASbGncvxHAqK264AYdA1Vb00GhWscX7NDs1xmGS2uyvBC/OVRgCTBo/9FfhZzwpDQYq
	tGX61TxTAwGD0/RLE9XD/bMzykPxcAraUmhxftfy4XlE5yL/MqqxLLxFuMxpyotnneH0wafJYWM
	Wkml8yk+1wisHFAlLnGEfH/NImDrDj2lYl8GxN6Es2MIEQTcFWR5aKh6Q5ErRPzyOfqlSls7LBW
	wxE0Zc8YNwMQQZUOMW6xrVsCmbtNwpmn9SC65E4XjEtljd2+VSJOWoMLcBROgXym494M4sHYHrc
	n+//M3gXGbMb4+u7o30HsohMJoX3BawG4asZ1GO7yGuVevIi9TaoFlPe0xMOVQBsNejnzrnOwQx
	DPExqUjFZXf5pvN0btb3esOI/9yg=
X-Google-Smtp-Source: AGHT+IHD28wzuZDbqCwZjnVoP3b0lLWv5woZjBHNk75iaWgswuMay7oAp8/DhNCOnihQT6LpAZsQBg==
X-Received: by 2002:a05:600c:a20a:b0:43d:174:2668 with SMTP id 5b1f17b1804b1-45365dd57d3mr61245965e9.0.1750687033122;
        Mon, 23 Jun 2025 06:57:13 -0700 (PDT)
Message-ID: <9cf513c5-7a16-48e7-8560-4ff0214e7836@citrix.com>
Date: Mon, 23 Jun 2025 14:57:12 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH test-artifacts v1 2/5] Enable CONFIG_USB_RTL8152 in kernel
 for hw12 runner
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: 
 <8c97ac17c41e53c15e769f28d537faa01a0b2e6a.1750684376.git-series.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: <8c97ac17c41e53c15e769f28d537faa01a0b2e6a.1750684376.git-series.marmarek@invisiblethingslab.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 23/06/2025 2:46 pm, Marek Marczykowski-Górecki wrote:
> It uses this USB network interface.
>
> Signed-off-by: Marek Marczykowski-Górecki 

Acked-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 14:03:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 14:03:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022489.1398324 (Exim 4.92)
	(envelope-from )
	id 1uThlI-0007Lb-Jk; Mon, 23 Jun 2025 14:03:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022489.1398324; Mon, 23 Jun 2025 14:03: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 1uThlI-0007LU-H0; Mon, 23 Jun 2025 14:03:04 +0000
Received: by outflank-mailman (input) for mailman id 1022489;
 Mon, 23 Jun 2025 14:03: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 1uThlH-0007LO-7i
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 14:03:03 +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 c6e42eb9-503a-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 16:03:02 +0200 (CEST)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-450dd065828so30748405e9.2
 for ; Mon, 23 Jun 2025 07:03:02 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a6d118821csm9468366f8f.77.2025.06.23.07.02.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 07:02:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c6e42eb9-503a-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750687382; x=1751292182; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=+GfyvvRlZnon/atfL8f1B6ci1RizMmbWQjcySWDNKAU=;
        b=YBiqlssCEj7H4J34n87VIqKDPrCotyiJ24aTxLuLUCrV/nF0Lp6pZQe4qE6oNrYOQu
         PooFFJ3eB7eUuBzP6TPDbBwt+KBP2iH8wEiu5AAlJnXgBSgasXJq8cBMSX+vXcjYUM2F
         rqb8Kxw8U8uKOZl2it+UOiS7Jady0NojvAXGY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750687382; x=1751292182;
        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=+GfyvvRlZnon/atfL8f1B6ci1RizMmbWQjcySWDNKAU=;
        b=eZh10goNV0vS/ygUnjOrWyLhaKbEJbPmnJGFrI1dpRGV2dzn1ekWA9ofgH2j6OhB71
         5ZJGqZzJXslErFR9BSFQ++f+HSvXRBX5tpu1bqpxQjscjXu2x/VYNsnfro74E2sk5FBY
         u7XD9G5Iag1fojBsYhhn3QRyp8TiKVgSiHZXSJWaUu/ldgWEicEn8mKQEHW+MZ8gnEZt
         O/ndEzkO254putOtSLPlVpbpLgHYoHf8EJwEPOT5jt/Izx5Vhu0PPcb5tpp983gj1E/R
         JYUQlTWCzGNlxgexzq2fu4ZjGaGmyKoQ10j2dZXxZ/Viq5CDnGf98hGEnoqmoa7ze+Gl
         i/jA==
X-Forwarded-Encrypted: i=1; AJvYcCV/sVg09DIl7/8c2U78/mPh9jS1jiJ6E2GKp5UqNflDBylGIp4eSHrLK8/zlLET+mTuclTI4tZLizA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyCE2PBjDXm5pVYvgMvNzcJU6xFgZLh5C4B+/yoGR54idYAIMEL
	ioURAKPhDB9htq+m9oH+D21o3OfL1ahLJa+cftncJIKKeWeStgh/PUPxdfmzlEl4ulI=
X-Gm-Gg: ASbGncsc9jpXhwa6m06mK8itgMYlUTyBpbttx1rRZnmQ1RbhM6UaWRDwltMoonjc5+e
	BX/5KPIfw9kiQ7xI4zCRLuX8Tzf2txyULdmWbUfGtZ/rHelhXBllgPl5di1cMwkTdoCEiHEwU1w
	iYJoCssw19hzRY2zsV/diBH5hLrKrlyl7C9AzJtJFxPzWyueVIPBjsz3UAUdW65/opdXapVGa5O
	9rBftSZ2PHaS817GibwZndquqxJcutVfG7NVXZpQm5P66GF0523PmoT4Cl48/S7L/iKV93lgo0q
	xwAjGnotdcx5zR7c9iOf9WNNQKmQLq8P0DEJ0Hapx7J83JvbfTrWvXPtGbTsat/P6j9mU+9eENh
	4YOZuwgnncTO5PdsqyYbWAYMU4dwW9UOXhbkxWQ==
X-Google-Smtp-Source: AGHT+IFFguP2Vkcx/0h6r3YnrfqXHuKJJFLpFm6saQnSAMaB7M5l456eLHQerJYSj89Sof732dV+YA==
X-Received: by 2002:a05:600c:c48e:b0:453:697:6f30 with SMTP id 5b1f17b1804b1-453659c414dmr88679675e9.32.1750687380179;
        Mon, 23 Jun 2025 07:03:00 -0700 (PDT)
Message-ID: 
Date: Mon, 23 Jun 2025 15:02:59 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH test-artifacts v1 3/5] Include git in the ARM64 build
 container too
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
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 23/06/2025 2:46 pm, Marek Marczykowski-Górecki wrote:
> It will be used for fetching some Linux versions.
>
> Signed-off-by: Marek Marczykowski-Górecki 

Acked-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 14:16:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 14:16:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022501.1398334 (Exim 4.92)
	(envelope-from )
	id 1uThxk-0002O8-MO; Mon, 23 Jun 2025 14:15:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022501.1398334; Mon, 23 Jun 2025 14:15: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 1uThxk-0002O1-It; Mon, 23 Jun 2025 14:15:56 +0000
Received: by outflank-mailman (input) for mailman id 1022501;
 Mon, 23 Jun 2025 14:15: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 1uThxj-0002Nv-8U
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 14:15:55 +0000
Received: from fout-a3-smtp.messagingengine.com
 (fout-a3-smtp.messagingengine.com [103.168.172.146])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 91d6d1ad-503c-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 16:15:53 +0200 (CEST)
Received: from phl-compute-04.internal (phl-compute-04.phl.internal
 [10.202.2.44])
 by mailfout.phl.internal (Postfix) with ESMTP id DF9B8138043D;
 Mon, 23 Jun 2025 10:15:51 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-04.internal (MEProxy); Mon, 23 Jun 2025 10:15:51 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 23 Jun 2025 10:15:50 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 91d6d1ad-503c-11f0-b894-0df219b8e170
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=1750688151;
	 x=1750774551; bh=qns6fN0fK2/ObDf94R9rZadp1F7Ip6+JKqr5aJYdcLI=; b=
	SoX0/KcxUtYaw5awb6WvtnB8AVkbFKj5nVrrkw4x1jiP17kkNxlcIWIs8D9vMHjI
	WBvAumUxTdI7Od/sEr9JzgLjiSqbOzdAq/4J03KDpSb/SyuTpFyDII7yvOTsS/Yv
	7IWDzAof6nWR0K6B+SmlEAgDD+5wGmDh0Yq7vXuyBXhTDF8eA9+l2ulTLNjkvlTv
	v+V9JjApebVJB5DUWnc1RQK+BeLvuRzj8J3p+MYWrO+IXd4yxvtJh26BpvjaQUFj
	QfIQ1x6VfobwWHN64b3qaUKLvJs2/D/B5ryVyTAkjSUt0f8bQ1h0ltpKLBu/RtKa
	JwijIq9fSosTV1ZREUamFA==
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=
	1750688151; x=1750774551; bh=qns6fN0fK2/ObDf94R9rZadp1F7Ip6+JKqr
	5aJYdcLI=; b=S72KPoEOTCqVsgwB6+VuJCxZV1easrN52HpCeL7m5JSXpi4KVVi
	xv6Qb7OV41zxKm5PPHAJ19TvazYKCQre/AH0VksP8Mk3TI3VRcr9dgE3VMWDrdi8
	W3MLTy0GajBvtAgVemOAwQAGtohD+tR22X5z8D5hgIVDcYKK/NmL0j0wDq0sDP+m
	b7MdXjwncke88ayHyz8tsZSev8L+fU2hf5bH37WesbkagWaAj1m/DOzGFKhDNxgQ
	3K0P2wEONBiHQNvcbyBhUtyBJ/iu/GenYamt/VhcBaTD6/LEgUVCrEfa/9SS/2PL
	2v4YCVnYlapFP4G877CZIriKgnhmGzWEEJQ==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgddujedvgecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghkucfo
    rghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhish
    hisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefgudelteef
    vefhfeehieetleeihfejhfeludevteetkeevtedtvdegueetfeejudenucevlhhushhtvg
    hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhn
    vhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopeegpdhmoh
    guvgepshhmthhpohhuthdprhgtphhtthhopegrnhgurhgvfidrtghoohhpvghrfeestghi
    thhrihigrdgtohhmpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnh
    hprhhojhgvtghtrdhorhhgpdhrtghpthhtohepshhsthgrsggvlhhlihhniheskhgvrhhn
    vghlrdhorhhgpdhrtghpthhtoheprhhoghgvrhdrphgruhestghithhrihigrdgtohhm
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Mon, 23 Jun 2025 16:15:48 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Andrew Cooper 
Cc: xen-devel@lists.xenproject.org,
	Stefano Stabellini ,
	Roger Pau =?utf-8?B?TW9ubsOp?= 
Subject: Re: [PATCH test-artifacts v1 5/5] Setup ssh access to test systems
Message-ID: 
References: 
 
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="mfA8UifdhOeM+qRB"
Content-Disposition: inline
In-Reply-To: 


--mfA8UifdhOeM+qRB
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Mon, 23 Jun 2025 16:15:48 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Andrew Cooper 
Cc: xen-devel@lists.xenproject.org,
	Stefano Stabellini ,
	Roger Pau =?utf-8?B?TW9ubsOp?= 
Subject: Re: [PATCH test-artifacts v1 5/5] Setup ssh access to test systems

On Mon, Jun 23, 2025 at 02:56:00PM +0100, Andrew Cooper wrote:
> On 23/06/2025 2:46 pm, Marek Marczykowski-G=C3=B3recki wrote:
> > For this add also bridge package, so xenbr0 can be configured with
> > /etc/network/interfaces.
> > This allows extracting more logs out of the test system.
> >
> > Signed-off-by: Marek Marczykowski-G=C3=B3recki 
> > ---
> > This enables passwordless root login. It's okay for qubes runners, as
> > they are isolated (even from each other). Is that okay in other places
> > too?
>=20
> It's potentially a problem on a corporate network.
>=20
> Can't we have each job generate a random password an insert it via the
> dom0-rootfs overlay?
>=20
> Or alternatively have the runner drop a public key in
> /root/.ssh/authorised_keys ?

That can work, yes. And is preferred to a password, as easier to do
non-interactively.

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

--mfA8UifdhOeM+qRB
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmhZYZQACgkQ24/THMrX
1yyAOwgAlIdXdb5K+YCy3hIBc9JQ8vPnGKTBcB9MvCH+IjOwj+zU/pE4UgmCgGJ6
ONBDnfHLaDpYGsRzJiimOvwlhRUFxxy4Lx3UlgEPFVYO2lNDSaiOAKaOar+e8CWK
ZpxsQ0OR807hN7KmMiqaHRBh28Epj5bH8VsCC1YzTmz0izOo4rUY7RNtV3fxenEd
G+x3Y11UaqWylO9YLG5xO1CecSlGT33hrQWJ9PpCydLG/oNxvgDVLCm4n/tn7TWe
F3xA2cCju7GWIM2Vzkdv8ohOsgsvGy0TECHx/JqThT3Zc1a0pLEUEYY9oqMx9ACp
bfJxDa408b5yf8F8RBTHD2uoyWekIA==
=9GN4
-----END PGP SIGNATURE-----

--mfA8UifdhOeM+qRB--


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 14:20:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 14:20:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022507.1398344 (Exim 4.92)
	(envelope-from )
	id 1uTi1n-0003ml-58; Mon, 23 Jun 2025 14:20:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022507.1398344; Mon, 23 Jun 2025 14: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 1uTi1n-0003me-12; Mon, 23 Jun 2025 14:20:07 +0000
Received: by outflank-mailman (input) for mailman id 1022507;
 Mon, 23 Jun 2025 14:20: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 1uTi1l-0003c9-BE
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 14:20:05 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20629.outbound.protection.outlook.com
 [2a01:111:f403:2414::629])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 26f2d795-503d-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 16:20:03 +0200 (CEST)
Received: from MN2PR22CA0015.namprd22.prod.outlook.com (2603:10b6:208:238::20)
 by BL3PR12MB6596.namprd12.prod.outlook.com (2603:10b6:208:38f::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.20; Mon, 23 Jun
 2025 14:19:58 +0000
Received: from BL6PEPF0001AB4E.namprd04.prod.outlook.com
 (2603:10b6:208:238:cafe::e6) by MN2PR22CA0015.outlook.office365.com
 (2603:10b6:208:238::20) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8857.29 via Frontend Transport; Mon,
 23 Jun 2025 14:19:58 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL6PEPF0001AB4E.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.8880.14 via Frontend Transport; Mon, 23 Jun 2025 14:19:57 +0000
Received: from localhost (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, 23 Jun
 2025 09:19:54 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 26f2d795-503d-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=jSpugDQufXYTmpaB3am3478tbLy5usbKjOYAMwm2MTFthJLegRBF4LpI7bnLWm401mtXq1NTRBtAHEeD7URDQCCHeFQ06PocnsQ8sWgDSeEljJZ38eHKQIE4rNmG9LSdi7+YQfl6ZKXnzn8LhDe1zof9c6mr6TOLqtQITMT3n9Wh4hHxZbXbXVOsr+qFyt7vq7uruJHmm7Ex+koXkBLP91+1bEcg+7E5ltG0xsBMxUvMBjFqJJEYITf2VlEeA8eeCT28PzI83TsoWPoyiEaTAM1QWd5bzQaKTWV8DxAGLdlPUdJUZUv59vOgTMR38ZehS9kIssVpPF08RxN5K/tkYA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=IH/a4bxTGQA/TIIFCANhDHmItca1Aj/QEbIkhNz4sf8=;
 b=JO4DubX3WH45zmYqo743JC9Pd+zdDDyi+oLw8KSSJ8scBwYYQ6hlnPmtBQ4z6cKIQOvLQNjrgNc6bQOt92NTPM93gFfVTRp41gY6D/t2F4UIfjnctL2HhHLyQFz/AS1grtV6KhI7zvfDRhxNzDxIoWEWwwijn5mvzp02OHNbWlKCsxzSPrV0voYme/8oJElbvXMVtuZz/rcTkifbtVEoKNTDMBRAGl1O5IVykpaxjQavIS4e7XDh6o4LwMe61vNTSCdBh/kQI/uxcXppu0dtCfHxGBdBqssOWKDmxHxbgH5HScwzcp9kHcPAJUDkelutqJxeVyBeGn14UIzKppsK+w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=IH/a4bxTGQA/TIIFCANhDHmItca1Aj/QEbIkhNz4sf8=;
 b=gRV1Zvml748zSZb1hV3yn9UeoJ3Wc5Jhq2f9lk4nAHZWwlY+3BJ0W83YCxa9+7sKTTJx6hE6W5s7rjgR/PvXW0vlEDOktIQdBfTi9uxMB1Y2ola9d3uq4XYanFVFseililX0YtzgRtDhuyMwl/Gay8rd8uge/XbfcjJp6rAe8Ow=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 23 Jun 2025 16:19:53 +0200
Message-ID: 
CC: Andrew Cooper , Anthony PERARD
	, Michal Orzel , "Julien
 Grall" , =?utf-8?q?Roger_Pau_Monn=C3=A9?=
	, Stefano Stabellini ,
	"Bertrand Marquis" , Volodymyr Babchuk
	, Shawn Anastasio
	, Alistair Francis
	, Bob Eshleman , "Connor
 Davis" , Oleksii Kurochko
	, "Daniel P. Smith"
	, =?utf-8?q?Marek_Marczykowski-G=C3=B3recki?=
	, Dario Faggioli ,
	Juergen Gross , George Dunlap ,
	
Subject: Re: [PATCH v4 10/12] xen: Rename CONFIG_HAS_DEVICE_TREE to
 CONFIG_HAS_DEVICE_TREE_DISCOVERY
From: Alejandro Vallejo 
To: Jan Beulich 
X-Mailer: aerc 0.20.1
References: <20250620182859.23378-1-agarciav@amd.com>
 <20250620182859.23378-11-agarciav@amd.com>
 <490ee7bf-cb10-43e3-9416-9a68e7529b96@suse.com>
 
 <1fc40753-727e-408c-940e-07f3efe1ef48@suse.com>
In-Reply-To: <1fc40753-727e-408c-940e-07f3efe1ef48@suse.com>
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: BL6PEPF0001AB4E:EE_|BL3PR12MB6596:EE_
X-MS-Office365-Filtering-Correlation-Id: c92b77ce-e379-42d0-793a-08ddb261087b
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|82310400026|7416014|376014|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?V3oyUEtPZ0VjclFVbG9qcXl1YzFtWnltbFN2R011V0RyaW1qa2ZURzJqQkpk?=
 =?utf-8?B?UnVXNmZzQmJ1VTVkV3NHNUxFUGRIeTFjUHBwUjUvSGxWVFQ2NkhRZ1FpWTho?=
 =?utf-8?B?MGpHSTY3Mll2Y0tNVER3amJuRlI4N1BBa21BZUVXbi80MkQyQ0NEcllTQlJo?=
 =?utf-8?B?aDRscXdCSG9aaGxjZ3NtNEpMUms0OThSQmhyVWx0MHpBVTlrZ2NaZ09reTVD?=
 =?utf-8?B?MUxoNkR6L3BqN0VsYzhqeGN1bEdaMVB5eW1XK2gxc1FrclVqN2xuS21KUVF5?=
 =?utf-8?B?WVpxMCs2dEpld2NIZ3VjZUpCRWRLaWd0cjI3R3NSUnR5WHcvakFLOWlBNi9p?=
 =?utf-8?B?TjZKUEh5eFJkT3E2V1NWK3ZzVVVHcUxQdTh5dTVjVVBQdnVROCtEa1hZb2do?=
 =?utf-8?B?d2QvQkduVjNEbU5rb0VCZzhyQTNUcFJMQ1QxcWw0ZGxiTUNwR0VWTmJTWnUr?=
 =?utf-8?B?b254OG5vYTBTbTd5YW1sWFh1YjF1RDRXK0JMQTZZWDVKNjFEYzlGYXBRYUxP?=
 =?utf-8?B?OFlWNzBoYWRsaEk0Ry9Ndno0WnB3a3djbzZMM3kyN3ZLNGlndHV4MCtGYyt4?=
 =?utf-8?B?eWZ5cE84dTVTemFGci94RVhzY25hUldVOWwxNHBleWpPdk96V1c4VXZNV01G?=
 =?utf-8?B?bEN2dDBsTzc5V3IwSEpzYmtzQjhoUFVsRG1BRjg3eXp0KzdoNFE0UFpCL0lu?=
 =?utf-8?B?VWRxMXJDSkhKY0lRVHNUanluVmtianFkbTBndlozcnlOYnZDc3FTdkNTb2ZL?=
 =?utf-8?B?WHN6ajdSRjBrREJMbU9CazZKY3h2YkFSVlFJMG9rRXhyd2plZU55YXJybE9Q?=
 =?utf-8?B?NlZwZHNmV2hUOWhQSFVCckZZT3pESS90emFiMDhVcXdGM2hEMWNDZEx0d1VG?=
 =?utf-8?B?QUIvcFZGTllWZld0eWxBaXNra1hZNmRxam14cTU3d0dDRWxUSGJGTjlRRzJL?=
 =?utf-8?B?anc3c0poajJ1ZTlFcHhidVJxS2VDYmIybSt5azRSQ09TQzU1VlR6QzNxM0x5?=
 =?utf-8?B?OFRDYktkblgwcUVubHNOWDVNcE1tQUJpamMrenNJZzRoKzAxWG9CV0lBVjA1?=
 =?utf-8?B?c0lUQXk0b1dzSXJXendwa3pzRjdoZ0U5aXIwSDdVMERqdlJwR3diaUFDVzQx?=
 =?utf-8?B?ZjFtam1VS080VU5Cai9XUlZLd3ZXRjAxbTQ4VEpMRDA3eXBxek9za1Q5TDF4?=
 =?utf-8?B?TVh4OHdtdVk4VEZiVlFKRUM5UXJaYjF1TWdjTGNjZXBlbGlTM08vWTZibmJ2?=
 =?utf-8?B?TFdTbENVUVNQTDN0dnBKSkEzOTRzejhjek5JVUpJUlZuWVdJTy9vQ1ZIMGx1?=
 =?utf-8?B?bGVsOHBZS2FNd2pGWndINzNsQ1RGTmI5UW9JM2RiczJMNUhOd0tlNndxd0NU?=
 =?utf-8?B?bGhrckNrMTZJL2tZemNwL2tYdzNpRkxzc2o4VFJ6ajVaRUtjMVpZMXhoWk44?=
 =?utf-8?B?bG5pZlU3Zm9zbTNhRjNoVnVPUklDN3JoWTRFeFk0WGwvT1IvT0FHU2E4bEJD?=
 =?utf-8?B?VnFvbVNZTWc0WmtkT3V5emtmQ2wySFpZNXh3cnJTT1ZEK2dyK3o2Y0REaWll?=
 =?utf-8?B?bEU3N2tiR3A2TWV5dVVOSzJiVk1rUG1WU2I5T0dqM2NSRU8zZzZ1cnJ3ckZO?=
 =?utf-8?B?Qm81MlUrVm5vb1dBZVRtY3dCM1BwOUdqY2RZdkxxK3oyRUxRTjd2V25NNDgr?=
 =?utf-8?B?eDdxRERLQjdFMmdKYlY0T2dESnFaZ1VxTkpTZFlFcEloQlk1bzNXZzc5eDJ2?=
 =?utf-8?B?S3FnaFM4UnV0TW00b0JNNnNwUEZaVkNpRlN3WGpKRW8wbFZWMmxKYmVxZ1FT?=
 =?utf-8?B?UEhZZndDS21SUEFoOVZXRVBiQjJOdmhKVU1Jem5oUUZoR2ZVUUxqREZDNXZB?=
 =?utf-8?B?eGJaNFlWQXdLVExTd2lVSEpDVjh1ZE5YZkVPV2VsNXYreFRsT1ltbDdIckp4?=
 =?utf-8?B?ZGsrSEgzNlpXeDFKS3NGUURIUVZBendkMFgrbkxwQzNrUHNVNERaMmlkNG5N?=
 =?utf-8?B?a3RhaUJpZm1kZ2NQcU8zY1pKeTBhY1V0ZjNhUHBkR1p2QUF2bHV3WXVSRzZX?=
 =?utf-8?Q?EQGZOU?=
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)(7416014)(376014)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jun 2025 14:19:57.9934
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c92b77ce-e379-42d0-793a-08ddb261087b
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:
	BL6PEPF0001AB4E.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL3PR12MB6596

On Mon Jun 23, 2025 at 3:44 PM CEST, Jan Beulich wrote:
> On 23.06.2025 15:11, Alejandro Vallejo wrote:
>> On Mon Jun 23, 2025 at 9:39 AM CEST, Jan Beulich wrote:
>>> On 20.06.2025 20:28, Alejandro Vallejo wrote:
>>>> Moving forward the idea is for there to be:
>>>>   1. Basic DT support: used by dom0less/hyperlaunch.
>>>>   2. Full DT support: used for device discovery and HW setup.
>>>>
>>>> Rename HAS_DEVICE_TREE to HAS_DEVICE_TREE_DISCOVERY to describe (2), w=
hile
>>>> DOM0LESS_BOOT is left to describe (1).
>>>
>>> Considering hyperlaunch this feels wrong to me. Did you consider splitt=
ing
>>> HAS_DEVICE_TREE into HAS_DEVICE_TREE_PARSE and HAS_DEVICE_TREE_DISCOVER=
Y,
>>> as I suggested on the committers call? You weren't there, but Stefano s=
aid
>>> he was taking notes.
>>=20
>> Some might've been lost is transit, I admit. I don't remember hearing ab=
out
>> a HAS_DEVICE_TREE_PARSE, but it might've very well been me being spotty =
when
>> syncing with Stefano.
>>=20
>> Having a special HAS_DEVICE_TREE_PARSE doesn't seem very helpful, as eve=
ry
>> arch would have it set.
>
> Hmm, yes, we don't want or need that. But then what's option 1 about? Tha=
t
> shouldn't be "described" by DOM0LESS_BOOT.

It's about x86 using device_tree/ for hyperlaunch. x86 is the single user t=
hat
doesn't need (2) at all. In the x86 case the same selector that picks =20

>
>> I'd definitely like for the "enable support to boot
>> several predefined domains from DTB descriptions" to be a single option =
for both
>> dom0less and hyperlaunch. And be selectable rather than unconditionally =
selected
>> And ideally move towards a future in which both dom0less and hyperlaunch=
 are one
>> and the same.
>>=20
>> I can do an early rename s/HAS_DOM0LESS/HAS_PREDEFINED_DOMAINS and s/
>> DOM0LESS_BOOT/BOOT_PREDEFINED_DOMAINS/ if that helps. I was waiting to d=
o so
>> until x86 gains the ability to boot off a DTB to avoid having help messa=
ges
>> describing things not yet on the tree.
>
> I have to admit that it's not clear to me if that would help. As you say,=
 on
> x86 that's not a thing just yet. What I think we need to aim for is to no=
t
> leave the tree in a state that's more confusing than anything else. Even =
if
> later (which may be much later) things would get tidied again.

Ok, how about turning it on its head? Seems like we're in agreement with
HAS_DEVICE_TREE_DISCOVERY for Full DT support. There could be a DEVICE_TREE=
_PARSE
(no HAS_) that's selected by HAS_DEVICE_TREE_DISCOVERY and DOM0LESS_BOOT. T=
his
allows x86 to deselect it by not picking DOM0LESS_BOOT.

Note that x86 cannot select DOM0LESS_BOOT yet, but that's how it'd compile-=
in
hyperlaunch. In the meantime, the tree depends on DEVICE_TREE_PARSE instead=
 and
device_tree/ is gated by DEVICE_TREE_PARSE only.

Sounds better?

>
>>>> --- a/xen/common/Kconfig
>>>> +++ b/xen/common/Kconfig
>>>> @@ -14,7 +14,7 @@ config CORE_PARKING
>>>> =20
>>>>  config DOM0LESS_BOOT
>>>>  	bool "Dom0less boot support" if EXPERT
>>>> -	depends on HAS_DOM0LESS && HAS_DEVICE_TREE && DOMAIN_BUILD_HELPERS
>>>> +	depends on HAS_DOM0LESS && HAS_DEVICE_TREE_DISCOVERY && DOMAIN_BUILD=
_HELPERS
>>>>  	default y
>>>>  	help
>>>>  	  Dom0less boot support enables Xen to create and start domU guests =
during
>>>> @@ -85,7 +85,7 @@ config HAS_ALTERNATIVE
>>>>  config HAS_COMPAT
>>>>  	bool
>>>> =20
>>>> -config HAS_DEVICE_TREE
>>>> +config HAS_DEVICE_TREE_DISCOVERY
>>>>  	bool
>>>>  	select LIBFDT
>>>
>>> This select imo ought to move to HAS_DEVICE_TREE_PARSE, unless I misund=
erstand
>>> what LIBFDT covers.
>>=20
>> Doing so would preclude compiling it out on x86 when hyperlaunch is not =
there.
>> LIBFDT is very much essential on arm/riscv/ppc, but not so on x86.
>
> Okay, but _something_ has to select that on x86 as well, once hyperlaunch=
 is
> going to need it.

DOM0LESS_BOOT would do so once required. In the proposal above that'd be se=
lected
by DEVICE_TREE_PARSE, which would be selected by DOM0LESS_BOOT.

>
>>>> --- a/xen/common/sched/Kconfig
>>>> +++ b/xen/common/sched/Kconfig
>>>> @@ -67,7 +67,7 @@ endmenu
>>>> =20
>>>>  config BOOT_TIME_CPUPOOLS
>>>>  	bool "Create cpupools at boot time"
>>>> -	depends on HAS_DEVICE_TREE
>>>> +	depends on HAS_DEVICE_TREE_DISCOVERY
>>>>  	help
>>>>  	  Creates cpupools during boot time and assigns cpus to them. Cpupoo=
ls
>>>>  	  options can be specified in the device tree.
>>>
>>> This similarly looks wrong to me. Whether to create CPU pools is purely=
 a
>>> Xen-internal software thing, isn't it?
>>=20
>> In principle, it should be HAS_DOM0LESS and likely will be later when I =
hook it
>> for x86. I was waiting for x86 needing such a change to use the binding.=
 Would
>> you rather have the change done now?
>
> See above - my main concern isn't with what is introduced early or later,=
 but
> what the overall (intermediate and final) state of the tree is going to b=
e.
>
> Jan

I think this latest proposal addresses the concern. Let me know what you th=
ink.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 14:27:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 14:27:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022519.1398354 (Exim 4.92)
	(envelope-from )
	id 1uTi8d-0005Q0-U5; Mon, 23 Jun 2025 14:27:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022519.1398354; Mon, 23 Jun 2025 14:27: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 1uTi8d-0005Pt-Qg; Mon, 23 Jun 2025 14:27:11 +0000
Received: by outflank-mailman (input) for mailman id 1022519;
 Mon, 23 Jun 2025 14:27: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 1uTi8c-0005Pn-2K
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 14:27:10 +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 246c111a-503e-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 16:27:07 +0200 (CEST)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-3a57ae5cb17so2371081f8f.0
 for ; Mon, 23 Jun 2025 07:27:07 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-7490a68b082sm8806349b3a.149.2025.06.23.07.26.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 07:27:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 246c111a-503e-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750688827; x=1751293627; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=sasGtQsEsftue0w/QTUuMq1R1x2QMQPh3s4lYZtHf8A=;
        b=VaPxZtYG8PHoZXQ2HTLIPi0ReDWa8WeWB4cBvouCJQ+YAYYzY/8m7S/ByeeNYv5CMY
         baDNNRxbe8mMSfYh6J5+05cS/WIH7wS+mYgWMQgVBL9hh1OnPyLYFKqAJ6colUSDH1jN
         pvDhLTjR02ZDMreDMAu6flNUVhi9ySoTRvP3nviN3/Tkw+7FOOrhXongrKbVqjbSn20/
         YuqXfs6+IOX7wSs3pQdHL3vDe/eo99d9GefkF18C9fjAMbBbepFQsUWDzU5ySrr9usPY
         I52fu3UL3qod+xnK1kv64eDh5LAzP4/ejewW77HAL2FBog5CBK89+Mh+boO5xwRFYn56
         17pg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750688827; x=1751293627;
        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=sasGtQsEsftue0w/QTUuMq1R1x2QMQPh3s4lYZtHf8A=;
        b=roRSf9HMPkMG9On9BbaFqrfl+FSnze5UQ04skfLO1kmc7lJ16M8+j3du7c4rmXZuCW
         KZnhzPxmJN4AjvhVDiukl6Bjaw6fF7xx5FY7wp1RJgq3FeT23ByojjUVIxum9bLOZfcz
         xWO9Ax/Yhh/7LR6gxsB6mHS+Qpd++Tw3PfyMIHH7cUuU3cX2qu/u9DXPMkdQmwVUWKfl
         LVJPD2zrJlWbHhm5VhulOf7IAVj6uhC3FvkVh0Vuq2MsmJTWE8IWMdnBIoleBrmRMdWt
         yd7awGSfKmRbcm6II+IWBcfwgj6tEry1ugwItT5mZWszrQrh1TWDwxnLQU/BZLTjy+h6
         9epA==
X-Forwarded-Encrypted: i=1; AJvYcCUzMMWG87IvfYm5C+txZrMdZ5cMTmu23OXeqGCUSsyILPSHJ+NsByncg8OqXA4BOW4ysG471lnuDUE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyWdCUkqz1LWbfCgWKoLqgNjiWRM9J2ipE0Ir9U38dYyJrJPZr8
	cDSCctdrSmpgPw4NFBynRo9dnEx1bJMcrAChu2JOpUxDQGdJauZexGJOmvyz3SpeAA==
X-Gm-Gg: ASbGncsESYZQp/LdEscd2eq0CB6b0zzdkaysCv6KHVccd6y5YTwpTC66jPGEwmzIlOi
	6e/MF2LVPaJuIonwIn+4kBmqJCouXR0CmiGjVAL8bnvAZIxuEnnn4WT0g/M6qeJ87GsEJ3dKJZ4
	j8riDedd8oJgqpqbP/ENzOt3jqWtbXoTAaeA2gsHtxB/ko63Af9S16Q+D05di5D07ozGNXoSjqL
	Vk3pGjQzL2gd2xULjbhlUnzBXEZ4Vs7mcMhaOD6ksW4FcDHdblgCjyWNGopj+27cN2ZMA+JMaPV
	dETZJP0eM2GhDhBy3y6k7/eLgbNbYDE7ogBdlOYDFs8NsIQ0jNZhObz9zuYf3dXzyMoluFWfUpS
	KpELm/FVos0j3v400TyB5jZuHRQuwN87awfuUHIoKMnfYqhc=
X-Google-Smtp-Source: AGHT+IFvQw6f59hCuSlteSqwAQw3tKzbu14WChjSYyghVcMoK/U0vaetPa9QPrMpDH+rwLHHDPKs3Q==
X-Received: by 2002:a05:6000:2889:b0:3a4:f00b:69b6 with SMTP id ffacd0b85a97d-3a6d12e6912mr10768972f8f.54.1750688827146;
        Mon, 23 Jun 2025 07:27:07 -0700 (PDT)
Message-ID: 
Date: Mon, 23 Jun 2025 16:26:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 10/12] xen: Rename CONFIG_HAS_DEVICE_TREE to
 CONFIG_HAS_DEVICE_TREE_DISCOVERY
To: Alejandro Vallejo 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk ,
 Shawn Anastasio ,
 Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Oleksii Kurochko ,
 "Daniel P. Smith" ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , Dario Faggioli ,
 Juergen Gross , George Dunlap ,
 xen-devel@lists.xenproject.org
References: <20250620182859.23378-1-agarciav@amd.com>
 <20250620182859.23378-11-agarciav@amd.com>
 <490ee7bf-cb10-43e3-9416-9a68e7529b96@suse.com>
 
 <1fc40753-727e-408c-940e-07f3efe1ef48@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 23.06.2025 16:19, Alejandro Vallejo wrote:
> On Mon Jun 23, 2025 at 3:44 PM CEST, Jan Beulich wrote:
>> On 23.06.2025 15:11, Alejandro Vallejo wrote:
>>> On Mon Jun 23, 2025 at 9:39 AM CEST, Jan Beulich wrote:
>>>> On 20.06.2025 20:28, Alejandro Vallejo wrote:
>>>>> Moving forward the idea is for there to be:
>>>>>   1. Basic DT support: used by dom0less/hyperlaunch.
>>>>>   2. Full DT support: used for device discovery and HW setup.
>>>>>
>>>>> Rename HAS_DEVICE_TREE to HAS_DEVICE_TREE_DISCOVERY to describe (2), while
>>>>> DOM0LESS_BOOT is left to describe (1).
>>>>
>>>> Considering hyperlaunch this feels wrong to me. Did you consider splitting
>>>> HAS_DEVICE_TREE into HAS_DEVICE_TREE_PARSE and HAS_DEVICE_TREE_DISCOVERY,
>>>> as I suggested on the committers call? You weren't there, but Stefano said
>>>> he was taking notes.
>>>
>>> Some might've been lost is transit, I admit. I don't remember hearing about
>>> a HAS_DEVICE_TREE_PARSE, but it might've very well been me being spotty when
>>> syncing with Stefano.
>>>
>>> Having a special HAS_DEVICE_TREE_PARSE doesn't seem very helpful, as every
>>> arch would have it set.
>>
>> Hmm, yes, we don't want or need that. But then what's option 1 about? That
>> shouldn't be "described" by DOM0LESS_BOOT.
> 
> It's about x86 using device_tree/ for hyperlaunch. x86 is the single user that
> doesn't need (2) at all. In the x86 case the same selector that picks  
> 
>>
>>> I'd definitely like for the "enable support to boot
>>> several predefined domains from DTB descriptions" to be a single option for both
>>> dom0less and hyperlaunch. And be selectable rather than unconditionally selected
>>> And ideally move towards a future in which both dom0less and hyperlaunch are one
>>> and the same.
>>>
>>> I can do an early rename s/HAS_DOM0LESS/HAS_PREDEFINED_DOMAINS and s/
>>> DOM0LESS_BOOT/BOOT_PREDEFINED_DOMAINS/ if that helps. I was waiting to do so
>>> until x86 gains the ability to boot off a DTB to avoid having help messages
>>> describing things not yet on the tree.
>>
>> I have to admit that it's not clear to me if that would help. As you say, on
>> x86 that's not a thing just yet. What I think we need to aim for is to not
>> leave the tree in a state that's more confusing than anything else. Even if
>> later (which may be much later) things would get tidied again.
> 
> Ok, how about turning it on its head? Seems like we're in agreement with
> HAS_DEVICE_TREE_DISCOVERY for Full DT support. There could be a DEVICE_TREE_PARSE
> (no HAS_) that's selected by HAS_DEVICE_TREE_DISCOVERY and DOM0LESS_BOOT. This
> allows x86 to deselect it by not picking DOM0LESS_BOOT.
> 
> Note that x86 cannot select DOM0LESS_BOOT yet, but that's how it'd compile-in
> hyperlaunch. In the meantime, the tree depends on DEVICE_TREE_PARSE instead and
> device_tree/ is gated by DEVICE_TREE_PARSE only.
> 
> Sounds better?

Yes. Except that in the last sentence of the previous paragraph: What's "the
tree"? And in device_tree/ wouldn't we end up with unreachable code on x86
this way (the parts that are needed only by DEVICE_TREE_DISCOVERY)?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 14:31:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 14:31:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022526.1398364 (Exim 4.92)
	(envelope-from )
	id 1uTiCW-0006ws-DR; Mon, 23 Jun 2025 14:31:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022526.1398364; Mon, 23 Jun 2025 14:31:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTiCW-0006wl-Ab; Mon, 23 Jun 2025 14:31:12 +0000
Received: by outflank-mailman (input) for mailman id 1022526;
 Mon, 23 Jun 2025 14:31:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uTiCV-0006wf-EM
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 14:31:11 +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 b472b13b-503e-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 16:31:09 +0200 (CEST)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-ade5b8aab41so890550466b.0
 for ; Mon, 23 Jun 2025 07:31:09 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ae054083c87sm712594066b.89.2025.06.23.07.31.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 07:31:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b472b13b-503e-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750689069; x=1751293869; 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=bXMOrPWTU/o+DCEqk62seDI9irkUb2xOGAhRsca1Lz8=;
        b=ZXsbOFZNyQAxf/WCVQRIkUzeKUQeQDsJQ0WUAhUNPxCsRscFzACiKy9i4quNguolYO
         oINdTDK94+kobC+aAbrv22GO9DCjWjfyfP/bVJJBecf6bSE83gP178+EdZPW3bjkm0fa
         9L3D6yX6mjJJf4J9UuzWfpk1oUkrvkEhHhACSkjQhbSkYrN0xNta36/gr2hcCPQByY9W
         iWhLTiQh8mtG8V0m1ZiIdNWkSCNYFHYIefUfKjBX+dE8kHWN4wUt/wkKHenNcenV1CjQ
         hR6WCt88259oJYgPwEO8fD8uFyVdB7NcNDUvuwLn2yoBSOiyqoe5Pw+ZF7boXeqhamvi
         737A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750689069; x=1751293869;
        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=bXMOrPWTU/o+DCEqk62seDI9irkUb2xOGAhRsca1Lz8=;
        b=jWMIdUKYGGJhgabSpO9zJvEQBPl9hdH2KcCV6FJAagO7VylVCmS3y+FUyuj/Fe3Cuq
         flpk20NGpULkEAPb+9Uv4fNrLEyPHkMpzJIyejUFOvoegCMH2MuCM4QYtl7in03U1lug
         AsbJArE4CILD4o7c4lvlAxe40F7nbLqVMctwKdLDvrYFfr9PXsxaSQLBIKvtKft9r8OZ
         0h0UIia2lrYLvUnjjSc5rTw7GokyQudO2bWhsoMiDMGsLEhJEBBE8Zwh/vFKJ77CFcZ2
         stRUnY7r3iMrKVVIEL9cjnfyLwE6Pn86VY9DhGCy6l2hixSUS5wRkv7QZE8F99Zd/fPY
         Te9Q==
X-Forwarded-Encrypted: i=1; AJvYcCVgYAam2mNgmISEhs9vP4sBNzqoumzwvb9NsGCa2i8MbNXbp4NgNaC0Eycf/JZgQMD7IF9ruDZJwE8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyC/knkgtpjOl/t9TsCJx2PmTPn88snKt461CAcJZ8xRSNO8S64
	bwSmovlzgKbAn66l8WKlsx0Uywai/3OZMtULcOIwz++kIfzqEs3rd+99
X-Gm-Gg: ASbGnct3hVFH29WoTHG9Kb5A6wA324ldsO8zQ/V2Mi1vAjhDOLI7sbCRDa7Qp2b4/mQ
	AYbY9Ww634ZP7WhJ9k8/ITn6+VdeTPMNHySpAcD3TWOkX/ojdkIXLA2tl6l3B1bL5rSH1FSqSgB
	xKid3mWk1hOyM1DRKBZ1/1kENP8tNBN2MmTRJUsJjM+U82NtoQHpA8nbBsP/Px66ITdwZOf+egy
	HLR9VYB2nF2MivI5WdIfw0q7kluk2nPkfXuXNF+Pb4hqlPNCI/yVDFmRfFZoNXB4ZsJYYlaa1wp
	6lq7QEQz8OvYM2M76eaDbQGgGgXikIEzHvTYG9jtFmO0fFVuwXLTAuzY5di3V1o0vh3JLbvP1ZK
	QmsfUCCu17k475Fsa5OPsAYOIwFDKTTSSnmvtVoereqXqcQ==
X-Google-Smtp-Source: AGHT+IGVaAPXwRJJGNRjIX6xLs6j6gEwx6uuugUZBalDARDYJtZI8KiLk3p+VTjeZTB19xV4WYpIpA==
X-Received: by 2002:a17:906:c10f:b0:ae0:a353:223a with SMTP id a640c23a62f3a-ae0a3534ca5mr53469566b.7.1750689068447;
        Mon, 23 Jun 2025 07:31:08 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------UnS0Rv1O8TFjlHLv3WAIGagw"
Message-ID: <80460b90-ffb9-44e9-83ba-0f81b3b05e92@gmail.com>
Date: Mon, 23 Jun 2025 16:31:07 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 01/17] xen/riscv: implement sbi_remote_hfence_gvma()
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: 
 
 <728ee92b-0e4f-4ccb-8c6e-54687bd75c62@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <728ee92b-0e4f-4ccb-8c6e-54687bd75c62@suse.com>

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


On 6/18/25 5:15 PM, Jan Beulich wrote:
> On 10.06.2025 15:05, Oleksii Kurochko wrote:
>> Instruct the remote harts to execute one or more HFENCE.GVMA instructions,
>> covering the range of guest physical addresses between start_addr and
>> start_addr + size for all the guests.
> Here and in the code comment: Why "for all the guests"? Under what conditions
> would you require such a broad (guest) TLB flush?

Originally, it came from Andrew reply:
```
TLB flushing needs to happen for each pCPU which potentially has cached
a mapping.

In other arches, this is tracked by d->dirty_cpumask which is the bitmap
of pCPUs where this domain is scheduled.

CPUs need to flush their TLBs before removing themselves from
d->dirty_cpumask, which is typically done during context switch, but it
means that to flush the P2M, you only need to IPI a subset of CPUs.
```

But specifically this function was introduced to work in case no VMID support
as we can't distinguish which TLB entries belong to which domain. As a result,
we have no choice but to flush the entire TLB to avoid incorrect translations.

However, this patch may no longer be necessary, as VMID support has been
introduced and|sbi_remote_hfence_gvma_vmid()| will be used instead.

>
>> --- a/xen/arch/riscv/sbi.c
>> +++ b/xen/arch/riscv/sbi.c
>> @@ -258,6 +258,15 @@ int sbi_remote_sfence_vma(const cpumask_t *cpu_mask, vaddr_t start,
>>                         cpu_mask, start, size, 0, 0);
>>   }
>>   
>> +int sbi_remote_hfence_gvma(const cpumask_t *cpu_mask, vaddr_t start,
>> +                           size_t size)
>> +{
>> +    ASSERT(sbi_rfence);
> As previously indicated, I question the usefulness of such assertions. If the
> pointer is still NULL, ...
>
>> +    return sbi_rfence(SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA,
>> +                      cpu_mask, start, size, 0, 0);
> ... you'll crash here anyway (much like you will in a release build).

I will drop ASSERT() for rfence functions.

Thanks.

~ Oleksii

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



  
    
  
  
    

    
    
    
    
    On 6/18/25 5:15 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 10.06.2025 15:05, Oleksii Kurochko wrote:

    
      
    
        
    Instruct the remote harts to execute one or more HFENCE.GVMA instructions,
covering the range of guest physical addresses between start_addr and
start_addr + size for all the guests.

    
      
    
      
    Here and in the code comment: Why "for all the guests"? Under what conditions
would you require such a broad (guest) TLB flush?
    
    
    
    
    Originally, it came from Andrew reply:
```
TLB flushing needs to happen for each pCPU which potentially has cached
a mapping.

In other arches, this is tracked by d->dirty_cpumask which is the bitmap
of pCPUs where this domain is scheduled.

CPUs need to flush their TLBs before removing themselves from
d->dirty_cpumask, which is typically done during context switch, but it
means that to flush the P2M, you only need to IPI a subset of CPUs.
```

But specifically this function was introduced to work in case no VMID support
as we can't distinguish which TLB entries belong to which domain. As a result,
we have no choice but to flush the entire TLB to avoid incorrect translations.
    
    
    However, this patch may no longer be necessary, as VMID support has been
introduced and sbi_remote_hfence_gvma_vmid() will be used instead.
    
    
    
    
    
      
    

    
      
    
        
    --- a/xen/arch/riscv/sbi.c
+++ b/xen/arch/riscv/sbi.c
@@ -258,6 +258,15 @@ int sbi_remote_sfence_vma(const cpumask_t *cpu_mask, vaddr_t start,
                       cpu_mask, start, size, 0, 0);
 }
 
+int sbi_remote_hfence_gvma(const cpumask_t *cpu_mask, vaddr_t start,
+                           size_t size)
+{
+    ASSERT(sbi_rfence);

    
      
    
      
    As previously indicated, I question the usefulness of such assertions. If the
pointer is still NULL, ...


    
      
    
        
    +    return sbi_rfence(SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA,
+                      cpu_mask, start, size, 0, 0);

    
      
    
      
    ... you'll crash here anyway (much like you will in a release build).
    
    
    
    
    I will drop ASSERT() for rfence functions.

Thanks.

~ Oleksii
    
  


--------------UnS0Rv1O8TFjlHLv3WAIGagw--


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 14:38:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 14:38:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022533.1398374 (Exim 4.92)
	(envelope-from )
	id 1uTiJb-0008LP-4O; Mon, 23 Jun 2025 14:38:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022533.1398374; Mon, 23 Jun 2025 14: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 1uTiJb-0008LI-1B; Mon, 23 Jun 2025 14:38:31 +0000
Received: by outflank-mailman (input) for mailman id 1022533;
 Mon, 23 Jun 2025 14: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 1uTiJa-0008LC-4V
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 14:38:30 +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 b9b99d70-503f-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 16:38:27 +0200 (CEST)
Received: by mail-ed1-x52d.google.com with SMTP id
 4fb4d7f45d1cf-60c01b983b6so285573a12.0
 for ; Mon, 23 Jun 2025 07:38:27 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-60a185449d5sm6150815a12.28.2025.06.23.07.38.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 07:38:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b9b99d70-503f-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750689507; x=1751294307; 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=ikbqEetpJuXeRpYBkQaHYywfRLiTbOC9Is/q48ZU/Q8=;
        b=UgxomK4EcgsbIyJ611ccKEpOXDlefAvTOCbtapoKC0hcpZLS35RbVnrIjKCTPt+RB3
         Ran1ZFOTklobbwvQbdC13nYCpxTHoEHGgrs7+CZ8IsSerLqlj2ldYkGV4XTlQwm4Rel0
         u66RUECHBJQaaPla5DcdrZ2As6DNMYOoO74uEyAJ+nkgANWRDNP7S95bXRUQ5J5hdRIO
         gKOpTKOTHFRD96treQtm7x/RiwgbPUdVEXzIem7TsXbon0XwisDPupqxinLIDo0Nupcx
         1+252dUrjXgt9xlE27BOONZF3/95Jkma0enkXWrXVwOp6IzqwhYajUtwfmMJ7phs9Pn2
         slOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750689507; x=1751294307;
        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=ikbqEetpJuXeRpYBkQaHYywfRLiTbOC9Is/q48ZU/Q8=;
        b=Gk4feT527O7+u87sbgzHQGtUDH4n+HWffnp1vvub8wV0mPn/hkMBlLGOlly0C5CiOS
         PhTL2RFajVPQuOn5xU06wet2xaboUv7m/zBXz1OzW/AZPCkaTGDEPjzsP6ky8jlplHop
         sjjuOcwDYytq5TVJ+0+02zpxmGkCE3ArwegDL+DdFBK5YgEKeThVTnfCN3JNkjHQWoie
         ztPyBufgFRZyiMrQw/eS1cbo28XeQQVcCFvuAizlWa3GfKZNyopyGJZoxEKIs7CYhR8u
         yW2vmWhHsYKSGQ8i1W91JpyQ3b1lHJTw77IKVJijjC68fDFS18BbgyBBevc57W6h3ocx
         cUuQ==
X-Forwarded-Encrypted: i=1; AJvYcCUSlbYeHX7Q/Aolb04vcv555j09671pggti0HFQ0ctlZAs+sfbBQ2X0gPJM60CGH1EvNtW1/l6Fr6c=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx3ozJlnLhGL8/FzHpPOlFI3un7b5P928MAR+QhbDAzeidQaokh
	tDVM/gVcVdRvCQ3CbEI1Lr4tANCGxZa/LgG3VA8S+iKJ0BLYWQF2NqVG2bCInQ==
X-Gm-Gg: ASbGnctlW4jMRRMdMb7RK8A6YdYPv2b3kziLANUE2ZvedcWDQpPPvw9mmpbTyB+je88
	Vd29TiQOlThKJ/R+aM8SZI/eagUc6fhKDWRMU3bUkJIQTXLiNmV3VXKkxJB9bPnOccHVvsb9kIz
	rLbXGYwN+SQFSuClfgVrFtsAYLi8O0Uw8j96+f2IospAq3noKDl+w4Vb7S/+WreepbD+c4QYGE/
	HxcY62MntgMXyA5+qutygOyOtIVkmgapsQcBczYOkCl0GkVMALIT8GW0Ws1auGza4poAN/gzFeA
	+SThHif0S5LbF9Twwea35UY1VswN8Q0cQPJ3+wLzZXK9LjbAkTKc4oP54AEXJKDdTBri/qrOLgw
	furtiHdGt3eiytEqDTIFz5Oz5QNZsxP6Or3M=
X-Google-Smtp-Source: AGHT+IFMjXfSG/5K2lLeZfcSQHldZMt3wa0gfgMKdM9D8WWg2UFwcexbQ7l2XVhcaIhkQNTuInn4yA==
X-Received: by 2002:a05:6402:27cc:b0:608:477d:2b65 with SMTP id 4fb4d7f45d1cf-60a2409480bmr10985517a12.15.1750689507105;
        Mon, 23 Jun 2025 07:38:27 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------DZEaixMA40TFnmdeEXmlCTAk"
Message-ID: <5bc59f3e-d41c-48cc-9be6-c2918c9dc465@gmail.com>
Date: Mon, 23 Jun 2025 16:38:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 02/17] xen/riscv: introduce
 sbi_remote_hfence_gvma_vmid()
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: 
 <5c614593a1710c737f5509ebb165efd8f857df30.1749555949.git.oleksii.kurochko@gmail.com>
 <542a4f54-705d-4f4e-b155-13375561baac@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <542a4f54-705d-4f4e-b155-13375561baac@suse.com>

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


On 6/18/25 5:20 PM, Jan Beulich wrote:
> On 10.06.2025 15:05, Oleksii Kurochko wrote:
>> It instructs the remote harts to execute one or more HFENCE.GVMA instructions
>> by making an SBI call, covering the range of guest physical addresses between
>> start_addr and start_addr + size only for the given VMID.
>>
>> This function call is only valid for harts implementing hypervisor extension.
> We require H now, don't we? It's also odd to have this here, but not in patch 1.

Yes, we required it. I will drop this part from the commit message and the comment
above declaration of sbi_remote_hfence_gvma_vmid().

>
>> --- a/xen/arch/riscv/sbi.c
>> +++ b/xen/arch/riscv/sbi.c
>> @@ -267,6 +267,15 @@ int sbi_remote_hfence_gvma(const cpumask_t *cpu_mask, vaddr_t start,
>>                         cpu_mask, start, size, 0, 0);
>>   }
>>   
>> +int sbi_remote_hfence_gvma_vmid(const cpumask_t *cpu_mask, vaddr_t start,
>> +                           size_t size, unsigned long vmid)
>> +{
>> +    ASSERT(sbi_rfence);
>> +
>> +    return sbi_rfence(SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA,
>> +                      cpu_mask, start, size, vmid, 0);
>> +}
> sbi_remote_hfence_gvma() may want implementing in terms of this new function,
> requiring the patches to be swapped. Provided (see comment there) that helper
> is actually needed.

It makes sense.
But it seems like there is no need for sbi_remote_hfence_gvma() as we have VMID introduced.

~ Oleksii

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



  
    
  
  
    

    
    
    
    
    On 6/18/25 5:20 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 10.06.2025 15:05, Oleksii Kurochko wrote:

    
      
    
        
    It instructs the remote harts to execute one or more HFENCE.GVMA instructions
by making an SBI call, covering the range of guest physical addresses between
start_addr and start_addr + size only for the given VMID.

This function call is only valid for harts implementing hypervisor extension.

    
      
    
      
    We require H now, don't we? It's also odd to have this here, but not in patch 1.
    
    
    
    
    Yes, we required it. I will drop this part from the commit message and the comment
above declaration of sbi_remote_hfence_gvma_vmid().


    
    
    
      
    

    
      
    
        
    --- a/xen/arch/riscv/sbi.c
+++ b/xen/arch/riscv/sbi.c
@@ -267,6 +267,15 @@ int sbi_remote_hfence_gvma(const cpumask_t *cpu_mask, vaddr_t start,
                       cpu_mask, start, size, 0, 0);
 }
 
+int sbi_remote_hfence_gvma_vmid(const cpumask_t *cpu_mask, vaddr_t start,
+                           size_t size, unsigned long vmid)
+{
+    ASSERT(sbi_rfence);
+
+    return sbi_rfence(SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA,
+                      cpu_mask, start, size, vmid, 0);
+}

    
      
    
      
    sbi_remote_hfence_gvma() may want implementing in terms of this new function,
requiring the patches to be swapped. Provided (see comment there) that helper
is actually needed.
    
    
    
    
    It makes sense.
But it seems like there is no need for sbi_remote_hfence_gvma() as we have VMID introduced.

    
    
    ~ Oleksii

    
  


--------------DZEaixMA40TFnmdeEXmlCTAk--


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 14:39:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 14:39:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022540.1398384 (Exim 4.92)
	(envelope-from )
	id 1uTiKL-0000O5-D8; Mon, 23 Jun 2025 14:39:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022540.1398384; Mon, 23 Jun 2025 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 1uTiKL-0000Ny-9x; Mon, 23 Jun 2025 14:39:17 +0000
Received: by outflank-mailman (input) for mailman id 1022540;
 Mon, 23 Jun 2025 14:39: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 1uTiKJ-0000No-Uj
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 14:39:15 +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 d5662ad0-503f-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 16:39:14 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3a54700a46eso2390140f8f.1
 for ; Mon, 23 Jun 2025 07:39:14 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b31f119f124sm8178499a12.32.2025.06.23.07.39.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 07:39:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d5662ad0-503f-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750689554; x=1751294354; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=XD+oT9x3mct9Hqqk3TA0A1N/gtRTla4B0dmhwOlBLng=;
        b=GVWfrHoDJds8K2p0bHtXG7UA3DIo3t0Qz8vsjYC985wxV9d4KbS2b8HAf7jMQ050og
         LzHv4QIYIZIvHyWPQCfaiKOBfQ2RJ5XRct3jo5bdOMCcYTgNV6r8sUr2o8mnMG/+ZApO
         3fUb5lmT9nxy68UnASddlGzNV6r4PqpiTTFygxKgci+tsRioIOrUzQ/tYxmaKxlfXhpw
         553IqsqBOoOb2OzuzWuBx6VwWZvB4sXrwpMgrEk9noMFyLTRIr9/hdVlRFdmEMCBpXIP
         x/youUs9fz96RVRSv/9EitW/8YlHb5bm00Mby0QY65LlAYdAUfHOT4qvcXqwMKbP0BAe
         VB/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750689554; x=1751294354;
        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=XD+oT9x3mct9Hqqk3TA0A1N/gtRTla4B0dmhwOlBLng=;
        b=AWR1Ut452qdSi0Yue5k/5V+3A/w4PqKM/1IQXOxhFekxYqw3yrARENp7Yd1U+9jUmp
         yASrIgLHcYIDPUlqLB3MR2TyR8x/qlNkXBPIXa4OYEk4dDjExEe20ffq3OvBwzMmXHyx
         +eFvzpvDNMeSQOnWDferIGS4sgQziSlEFDS0ILaY8w3tTNcVdwaKTGwufWersVy8XTWq
         Z+y6LkpMCstfOU2W1sFahFtZt60i1cs3ulplXtTOEgxTgJwh0kO1vIQb7S3CU4tCnJYR
         xeL94174zMNBbdHwTcOK0awRFHDB6rAroE/u9NZhSDydjSKPRDiiuk/ms9BDncpKMsrG
         GNnQ==
X-Forwarded-Encrypted: i=1; AJvYcCXtqIKjf5x7oKhSn5Ib4zKwhvN28m0gOvgfY7equG0rGEk+bGoS/KxomyxFuBJX7xwSmeF2g6jLOQg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwKV0BJtto91xYUGc0xH6PaCq2BD/uhZW7lxJKrSRg9r69vPINL
	DRKmtab/5Y+WCluXwlCNTxrzp8GED3jj71GeHnM4VMxdWdBOccvgSBEbj7Wh7Lpczg==
X-Gm-Gg: ASbGncuo8hpIZIhtN9fip84XMm7g/yK5+WYg6wye0GXWhU5rFt20GhtOmyn+JILS2dm
	oJRzIYoXeB799SVLd75Xz8XHZwWw3dq7Hinqk85A9t9e5IQaVHiGT/IUfaRHodJAhx+YD+oSHq+
	0fQPj/9e3WrIJeGcP6IQobIrt6QY79k6j5Ba5MluDxt5Ilam8L9eRwp1JFYn7Gr8yjJv78DfXlP
	zrCMzu4QItgWlxpVOjdIHlvneJzl8v+4jyv49JL+2LnB6vNdDNPbRno0BAlDsKbQQGU62YB9sBF
	QZBf1C088w4neXnUEztHGQN/DnBVBiYAFhcp4+DHhd3ZJn7Yf3zS6JSE+Cj6ihd0t/LG6JNsdaZ
	FLfKofkAuFXfm3W3168Bmu8UmAMIS7qjE+EfgdaB/VYJ1MY+N0Z5uGOYhWg==
X-Google-Smtp-Source: AGHT+IFtvNieIQxzEUJKmlC3oJvG03h7dqurBJ9owRG2bLzPhRX7z/2HfHGxpQH6UInADmHxivCjug==
X-Received: by 2002:a05:6000:4284:b0:3a4:e844:745d with SMTP id ffacd0b85a97d-3a6d13315c2mr11268301f8f.56.1750689553896;
        Mon, 23 Jun 2025 07:39:13 -0700 (PDT)
Message-ID: <670d4fa7-fc94-465d-a174-a73fedd1ee9f@suse.com>
Date: Mon, 23 Jun 2025 16:39:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 01/17] xen/riscv: implement sbi_remote_hfence_gvma()
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: 
 
 <728ee92b-0e4f-4ccb-8c6e-54687bd75c62@suse.com>
 <80460b90-ffb9-44e9-83ba-0f81b3b05e92@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: <80460b90-ffb9-44e9-83ba-0f81b3b05e92@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 23.06.2025 16:31, Oleksii Kurochko wrote:
> On 6/18/25 5:15 PM, Jan Beulich wrote:
>> On 10.06.2025 15:05, Oleksii Kurochko wrote:
>>> Instruct the remote harts to execute one or more HFENCE.GVMA instructions,
>>> covering the range of guest physical addresses between start_addr and
>>> start_addr + size for all the guests.
>> Here and in the code comment: Why "for all the guests"? Under what conditions
>> would you require such a broad (guest) TLB flush?
> 
> Originally, it came from Andrew reply:
> ```
> TLB flushing needs to happen for each pCPU which potentially has cached
> a mapping.
> 
> In other arches, this is tracked by d->dirty_cpumask which is the bitmap
> of pCPUs where this domain is scheduled.
> 
> CPUs need to flush their TLBs before removing themselves from
> d->dirty_cpumask, which is typically done during context switch, but it
> means that to flush the P2M, you only need to IPI a subset of CPUs.
> ```

Hmm, but the word "guest" doesn't even appear there. "Each pCPU" isn't quite
the same as "all guests".

> But specifically this function was introduced to work in case no VMID support
> as we can't distinguish which TLB entries belong to which domain. As a result,
> we have no choice but to flush the entire TLB to avoid incorrect translations.
> 
> However, this patch may no longer be necessary, as VMID support has been
> introduced and|sbi_remote_hfence_gvma_vmid()| will be used instead.

Good.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 14:45:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 14:45:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022555.1398394 (Exim 4.92)
	(envelope-from )
	id 1uTiQ6-0002pr-4M; Mon, 23 Jun 2025 14:45:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022555.1398394; Mon, 23 Jun 2025 14:45:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTiQ6-0002pk-1L; Mon, 23 Jun 2025 14:45:14 +0000
Received: by outflank-mailman (input) for mailman id 1022555;
 Mon, 23 Jun 2025 14:45: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 1uTiQ4-0002pT-7e
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 14:45:12 +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 aa470a5d-5040-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 16:45:11 +0200 (CEST)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-6097d144923so8900186a12.1
 for ; Mon, 23 Jun 2025 07:45:11 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-60a1851450bsm6121075a12.12.2025.06.23.07.45.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 07:45:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: aa470a5d-5040-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750689911; x=1751294711; 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=Z8OARxFXaAZOGHE4HIwnYDbeHEw746xM/NbyncgeQf0=;
        b=D8verOVCes/cpQQzoOL+q5iMs1Ayui8Mb/1rbLVMguV2TzlsbruuiS9GMLVP9hdkn7
         fzBQwOWHcFTBShVAEOBrKMZvqs8hz5AVKdAoszJBergRu8ZszWljCckaHmEz1KeVgCMX
         CM8yKQVkWpw7yeS3FMdvuCaz602QumayCwNkF/G1jRmyzj8E8y4OGVWYjlsHi4riKom5
         EBqmADv6MoRjPx1Kr6BO5iooM1qYPR7QmYrmIFxaTdo5SQCqFxEtQPSH1iXoNNQhJs5v
         pxO6ORl3oVUAz9XQm2nMaLSBswu4VaGPXsx3aCLt0g6A7VTbzBAI1SHx8BIe26nfan3/
         FpRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750689911; x=1751294711;
        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=Z8OARxFXaAZOGHE4HIwnYDbeHEw746xM/NbyncgeQf0=;
        b=ZlZ1jZRXA1NcxuRNM2OGLAbftQPBQZirlCZ6tUYlbpiWK0Rbb/GxF2dhr8Wt9+WPJu
         Av0/0hsUyqWjwz2q3GQNV28OuVEBKcu/ASLqGplW4Ietj23SjNVD/qAGAC3I08SPuek1
         U/RtMWDkMQC6S+V/Dx12vVzTBzO1ZbiczD80mS053s/IbgsvNXVv9FOJ1FHSAimGEj6T
         NNH+fR4NhjkJKB1qTAcI23L5Vhx78AOgXYq1LvS+hQPByBWV/k0FpiLt/UEl4hx+gbG4
         w0Kfn4pf1Oi8LUCzOfgxoYzTAH2aWtQ7DHRjVAb4WqBbDfM6Tsi90XO7ot+H8XWYv6vu
         hwVQ==
X-Forwarded-Encrypted: i=1; AJvYcCXv5XzHZMsMhCWbeoyKRXz1JQPjEMVAXeKiPV865Y7rJRRky8zGHxiCH/529YDYyVEeP8tjmiugfDg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywp52zJkVgDABHzoMFdQWHpumpsJy98L6X3WhIg03WxPFMnIiqK
	3XzrqHK8iHDm5UbqoUJmNqq4oa2VDk+V6dH3D0MmBBeg9M5pp7tu0Yp7
X-Gm-Gg: ASbGnctueUV0lwH1n6dopT7z30VbsFPxQdkpqqqNeN/3LYb2+TAJp5uaq/aYLhDm+m/
	b5Iq/40KMvH2BM1Ig3YnisfG1cTp5L7splPHz4KF1Wf1au6g8mPMQCPrCIlQ9+1cxWN/93kChtr
	TkwKxs1GFIidzRUnFa/RQGLWCEFpan0eSif49OIAI/SaQAUOU8JMPbqFzNrkt7b9+925iaWKTLk
	bH58RFKKEwWSpJnUpy4YhmuRcHhjT/zICVHF/ml3hFnAOtrOQ6v9to7yjOVkemm9qfps3Bw6tiU
	pwyZ9Uh9bklA6ln7+PnhSjFdmiu3q/al4K68FNjKP8BfQGj3R8GdrWr973RBwpNntkHkv1bidpg
	IaNdn+gdfG+dZVbhDLy4/IAhfnuI2qV3VM6HkP6CTQWsglg==
X-Google-Smtp-Source: AGHT+IHlS0PbwCxtlw5YrovyaR5gQHhuC6TrDS+2DXZZTzCApLxQBYylImldlK4ryVj3/544NrTTew==
X-Received: by 2002:a05:6402:1e91:b0:601:470b:6d47 with SMTP id 4fb4d7f45d1cf-60a20a5117cmr11676721a12.1.1750689910831;
        Mon, 23 Jun 2025 07:45:10 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------FmYPHNJ7TC5xAYSZIiWQsbRZ"
Message-ID: <29ad0416-d42c-4d78-8aff-28e892d2510f@gmail.com>
Date: Mon, 23 Jun 2025 16:45:09 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 01/17] xen/riscv: implement sbi_remote_hfence_gvma()
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: 
 
 <728ee92b-0e4f-4ccb-8c6e-54687bd75c62@suse.com>
 <80460b90-ffb9-44e9-83ba-0f81b3b05e92@gmail.com>
 <670d4fa7-fc94-465d-a174-a73fedd1ee9f@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <670d4fa7-fc94-465d-a174-a73fedd1ee9f@suse.com>

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


On 6/23/25 4:39 PM, Jan Beulich wrote:
> On 23.06.2025 16:31, Oleksii Kurochko wrote:
>> On 6/18/25 5:15 PM, Jan Beulich wrote:
>>> On 10.06.2025 15:05, Oleksii Kurochko wrote:
>>>> Instruct the remote harts to execute one or more HFENCE.GVMA instructions,
>>>> covering the range of guest physical addresses between start_addr and
>>>> start_addr + size for all the guests.
>>> Here and in the code comment: Why "for all the guests"? Under what conditions
>>> would you require such a broad (guest) TLB flush?
>> Originally, it came from Andrew reply:
>> ```
>> TLB flushing needs to happen for each pCPU which potentially has cached
>> a mapping.
>>
>> In other arches, this is tracked by d->dirty_cpumask which is the bitmap
>> of pCPUs where this domain is scheduled.
>>
>> CPUs need to flush their TLBs before removing themselves from
>> d->dirty_cpumask, which is typically done during context switch, but it
>> means that to flush the P2M, you only need to IPI a subset of CPUs.
>> ```
> Hmm, but the word "guest" doesn't even appear there. "Each pCPU" isn't quite
> the same as "all guests".

Agree, it is just what SBI spec wording that...

pCPU here it is the first argument of sbi_remote_hfence_gvma(unsigned long hart_mask, ...)

It is even more confusing as based on explaantion if RISC-V priv spec., hfence.gvma it is
used to flush G-stage (stage-2) TLB and hfence.vvma it is VS-stage (stage-1) TLB flush.

~ Oleksii

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



  
    
  
  
    

    
    
    
    
    On 6/23/25 4:39 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 23.06.2025 16:31, Oleksii Kurochko wrote:

    
      
    
        
    On 6/18/25 5:15 PM, Jan Beulich wrote:

    
        
    
          
    On 10.06.2025 15:05, Oleksii Kurochko wrote:

    
          
    
            
    Instruct the remote harts to execute one or more HFENCE.GVMA instructions,
covering the range of guest physical addresses between start_addr and
start_addr + size for all the guests.

    
          
    
          
    Here and in the code comment: Why "for all the guests"? Under what conditions
would you require such a broad (guest) TLB flush?

    
        
    
        
    Originally, it came from Andrew reply:
```
TLB flushing needs to happen for each pCPU which potentially has cached
a mapping.

In other arches, this is tracked by d->dirty_cpumask which is the bitmap
of pCPUs where this domain is scheduled.

CPUs need to flush their TLBs before removing themselves from
d->dirty_cpumask, which is typically done during context switch, but it
means that to flush the P2M, you only need to IPI a subset of CPUs.
```

    
      
    
      
    Hmm, but the word "guest" doesn't even appear there. "Each pCPU" isn't quite
the same as "all guests".
    
    
    
    
    Agree, it is just what SBI spec wording that...

pCPU here it is the first argument of sbi_remote_hfence_gvma(unsigned long hart_mask, ...)

It is even more confusing as based on explaantion if RISC-V priv spec., hfence.gvma it is
used to flush G-stage (stage-2) TLB and hfence.vvma it is VS-stage (stage-1) TLB flush.

~ Oleksii


    
  


--------------FmYPHNJ7TC5xAYSZIiWQsbRZ--


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 15:10:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 15:10:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022566.1398403 (Exim 4.92)
	(envelope-from )
	id 1uTioa-0007Yi-VG; Mon, 23 Jun 2025 15:10:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022566.1398403; Mon, 23 Jun 2025 15:10: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 1uTioa-0007Yb-Sh; Mon, 23 Jun 2025 15:10:32 +0000
Received: by outflank-mailman (input) for mailman id 1022566;
 Mon, 23 Jun 2025 15:10: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 1uTioZ-0007YV-FP
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 15:10:31 +0000
Received: from NAM04-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam04on20613.outbound.protection.outlook.com
 [2a01:111:f403:2409::613])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 325e0eea-5044-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 17:10:29 +0200 (CEST)
Received: from BN0PR08CA0010.namprd08.prod.outlook.com (2603:10b6:408:142::11)
 by DS7PR12MB9526.namprd12.prod.outlook.com (2603:10b6:8:251::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.28; Mon, 23 Jun
 2025 15:10:26 +0000
Received: from BN3PEPF0000B06B.namprd21.prod.outlook.com
 (2603:10b6:408:142:cafe::96) by BN0PR08CA0010.outlook.office365.com
 (2603:10b6:408:142::11) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8857.30 via Frontend Transport; Mon,
 23 Jun 2025 15:10:25 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN3PEPF0000B06B.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.8901.1 via Frontend Transport; Mon, 23 Jun 2025 15:10:25 +0000
Received: from localhost (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, 23 Jun
 2025 10:10:22 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 325e0eea-5044-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=PVzLFh1VYTuRnmo5uaRQMe5GRCmTMa2sOJv7a7qGrmHzlLh3O1feKtaBm0c5uIZRD2Mjj9GLJ2dncwlQyv6pTUML0nFeZxl2kt4BydLcL3j6MEQb5MIRQ6Egqv0eKjMBVC3KXT9Rc4Z5fRxLsX2XmXZhupdibUbB6IjO7xbmjtCWl3qyopH7NWXoQaVAcatBQoEX8SrZrIe5v1shf9PwSRvmRQwSnI82BT9TrCm4QS/ICMKsMUQmomSG4lFi7kOvuuNA1mfwIKjEgKfzMOWFooFZ0YsHJDFMr+LlN44keg4Mm5uZgFC2pIMgmVj8t3SymZjsgAL8D5sNm9m4vNj58w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=zqAf6hbSoWeQD5mlTjoRJtxg5ng4Zi6N36njYr0gjKE=;
 b=ErXH8fAKJpR9Vt3mY/yafPznxGhaDBD7MxQDQyOKIc98wdpFkmyEDQTgCGx5sVVCePlyUlRBxY3O6yQfqsGZFHViXTTUl4lFp2cDFDecBXIQ9kVJGjqQXVbUV10EbQJzPIY9sNFeRly0Khv3psy0xw7xrc3sAc+tvqKxPQ/HEEKWjQGkiOm/wYx2CD9WH72YXbbTuysBpJ6f5j4w6T5F+EFOnXgwbHmzCOvkg8v7d1pDGLNSUHHFQt3NIpUpAqWkgXSQuVXey/Quj9/OWO3IU8xZ9j8L3lhLLVShv4UOebJj+9c/GfBj4StB/DJG+4l7Hi722k7d80up7JlCkCWLHw==
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=zqAf6hbSoWeQD5mlTjoRJtxg5ng4Zi6N36njYr0gjKE=;
 b=kAnE8xEIGZdel5PIOJ56sJRCtL84S1mxxpsRkbUGOzv0Fm0ETmlh80nKhyzOHmH9tTEQXC2VM9YDbQ4sFKJHmMmVQh/82k2uem740flwiY++QL4Kk28ZgWUTocHfMdhLL9FyQNKDDAvgNxXrsRL/YPen2nVdhxufOM+xT8faWTA=
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
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 23 Jun 2025 17:10:20 +0200
Message-ID: 
CC: Andrew Cooper , Anthony PERARD
	, Michal Orzel , "Julien
 Grall" , =?utf-8?q?Roger_Pau_Monn=C3=A9?=
	, Stefano Stabellini ,
	"Bertrand Marquis" , Volodymyr Babchuk
	, Shawn Anastasio
	, Alistair Francis
	, Bob Eshleman , "Connor
 Davis" , Oleksii Kurochko
	, "Daniel P. Smith"
	, =?utf-8?q?Marek_Marczykowski-G=C3=B3recki?=
	, Dario Faggioli ,
	Juergen Gross , George Dunlap ,
	
Subject: Re: [PATCH v4 10/12] xen: Rename CONFIG_HAS_DEVICE_TREE to
 CONFIG_HAS_DEVICE_TREE_DISCOVERY
From: Alejandro Vallejo 
To: Jan Beulich 
X-Mailer: aerc 0.20.1
References: <20250620182859.23378-1-agarciav@amd.com>
 <20250620182859.23378-11-agarciav@amd.com>
 <490ee7bf-cb10-43e3-9416-9a68e7529b96@suse.com>
 
 <1fc40753-727e-408c-940e-07f3efe1ef48@suse.com>
 
 
In-Reply-To: 
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: BN3PEPF0000B06B:EE_|DS7PR12MB9526:EE_
X-MS-Office365-Filtering-Correlation-Id: 702f293c-8a20-47a9-7dd6-08ddb26814fd
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|376014|7416014|36860700013|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?djErbjdyTk5OSm1wUkpZeEtJa0xNeC85dEgvVEtld0RROW1rTUk2dFYwMjRs?=
 =?utf-8?B?cGhVNVgrMWxCRjVHaW5yUFkyWExacHh1elhObW50MzRvQWZDVVFTVlZKU0F3?=
 =?utf-8?B?ejhKN1pVWmxjU3NYazBPT0pLUkx2N2JZZXFXMWJ2bERBZHZ1RVd5UCthcHVm?=
 =?utf-8?B?L3p5WFQzNHNUMWxSZXRJcDYxT25uc1Yzc2Y4ajZiK0dIaTZucitCZUkxNEtJ?=
 =?utf-8?B?eDBNTUxremFpYi8vSlVXR2hzN0RaV2RwR01aUHZmNHZZOXlOSXVLWmh3QVQy?=
 =?utf-8?B?NFlrZFV5bzd2ek1pTzJTWWt1UlE2RkM4T0RkdzVud2RCY1o4ZlYyaDR0Mldj?=
 =?utf-8?B?RXlrV04xaWYzRkI3VE9HNWZZVmI3dzdvODlMb2RMWUxsNHFPNWFhMTVWWFFN?=
 =?utf-8?B?blM3Z2piSE85eExGVmZYYWhRdFlHcWMxWkRKZVdKSVNaeXFCVzVEY3JLT3pn?=
 =?utf-8?B?NHpNMUJtTHRGWEQ0bkhmZXpxMlJ6RlJ4NVZRZ0c4eHdDMEJoQ1hlcGF2WFYw?=
 =?utf-8?B?SW1QTnZHRnRjZ3l1TzhzalRmZzdzME1nVWZqSTBOQjhLdTMxd3FRUWNxejVR?=
 =?utf-8?B?ODQ5ZnljVStwdzZPZmp4Yng0SU9KMlJoR2ZiZkorN1BIbHltZGZVa3UyVUF2?=
 =?utf-8?B?NFJWQytIRzdoUHo0TDdpek5JcEhrQVVZTE9aWW5vd0czK2ZJMGxEaWlyaXFw?=
 =?utf-8?B?VnZZVXZrWXJuaHhzR2dweHhmUnlneDRjL2lLYzkyYkZyMHdrRmxZUzNRMFha?=
 =?utf-8?B?eUQ5dWVJcmFtbjY5bjBmYTZUQUJpdUk4YnRKbGNJSDhhWjlRTTN0NTR1Qjhk?=
 =?utf-8?B?SXh4OXVtTk53a1U2ZUtldlhhQlI3ZlEzWThvQXZKaUVLRHRiTmxEdWJYUkM2?=
 =?utf-8?B?bnlLdUVSRW9tNGxzanUwcFlFSTUrcjAwYTU0ZEZzKzlERGZhcFd0cmpXZ3Rj?=
 =?utf-8?B?K0sxK21lRlFtN0NIcTdvdERWd3kyczdpL1lXMnhoSk4rRjdZSDR0SVdvdUNm?=
 =?utf-8?B?b2VqdGxlVHQ5UkZzbHlRcC8wQ3NWaVlkeHZYSWxOSk5XMnJKU0hLUFNXdjd5?=
 =?utf-8?B?czQ3dDB5TXhTSHZXU25NS3JLTC9qQlprVlEyQzJiTjNEdFJJYS9ZZUgzSGFv?=
 =?utf-8?B?amptdWJWT0JlZ2EzMTlXeU5yUm0xOTdWTkkxWm9KeEozQURhK0ZTOUg3MGE2?=
 =?utf-8?B?dnYwSytOczg0RGpsbjc4Y0J0Y3B6QkFPSlVLbGlQUzYwdnkrTTNXWUd5Y1VD?=
 =?utf-8?B?L2JMNEVKa25VQW8wbmFDY0dqVWxqMU1SdWxwRHUvaDdGRDFKTUtsSGRtVE0z?=
 =?utf-8?B?eTBDM1VWRHlyQU9JYThEV3hXSjRHbzJCTFljVTRRN3J3MUw0d0lWeko4cHlC?=
 =?utf-8?B?aU9LZmRoREhiNjNud0hZUDNqdndNTUFJOHo1Yk5NdFVnQkgrNVRhOVVuNVNh?=
 =?utf-8?B?NVhwWXV1U2lQRVVHVnRWWGVXMGZpRXZ1SnRnc2Q5RkU1SHYwdWFpR1lQdWV6?=
 =?utf-8?B?OTdFOEZZR2I1TGU3dlF5Z0szK1FsTy9wVzA3YzJma0FiUXpwY3JweDVnc09M?=
 =?utf-8?B?bGVkSGdXTTVWWDhiWFBycWNSaXl1NDdETU96Rzl6WTFHNU1yU3dkWXExV1hP?=
 =?utf-8?B?VWR6TEdPMC9pdHMxNWJrMVZFTmlwQlFLTkZZVmxUV3JhU2UySUVFNW0wRU0r?=
 =?utf-8?B?cVo0aVRlUUlmZlc2bEtCemI1czNqRjFBVVo4djFpOEI1WVJUVFdqekM3Rm1z?=
 =?utf-8?B?LzFONjRHN3FoM2ZwMHptSlY2L3RlN1doTUpROUZOY2pVYUF2TSsxcWg2WVl3?=
 =?utf-8?B?NXJidVZEWXo2UjR5b1RTQzlWdE10ZzExMVNpSFdaT3RZQlJWZ0hzNmZsZEk4?=
 =?utf-8?B?emZsUTVDWmZERzZ1WnR5L1dRMEFxNVBuSlpjVXFpUlVRTThyNlBMdWxFZVR0?=
 =?utf-8?B?amJJd1VRdVBhN0F3bFlreDY4UGc5Ly8rQktNSGwxRElBWTM3N1ZQb3pKTEx4?=
 =?utf-8?B?U0t1VStENTV1T2VXL0svd25sMUhQN3JlUTcrczAyQ2J1K3QyTE9SUlNGTUZt?=
 =?utf-8?Q?puMyN2?=
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)(7416014)(36860700013)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jun 2025 15:10:25.4545
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 702f293c-8a20-47a9-7dd6-08ddb26814fd
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:
	BN3PEPF0000B06B.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB9526

On Mon Jun 23, 2025 at 4:26 PM CEST, Jan Beulich wrote:
> On 23.06.2025 16:19, Alejandro Vallejo wrote:
>> On Mon Jun 23, 2025 at 3:44 PM CEST, Jan Beulich wrote:
>>> On 23.06.2025 15:11, Alejandro Vallejo wrote:
>>>> On Mon Jun 23, 2025 at 9:39 AM CEST, Jan Beulich wrote:
>>>>> On 20.06.2025 20:28, Alejandro Vallejo wrote:
>>>>>> Moving forward the idea is for there to be:
>>>>>>   1. Basic DT support: used by dom0less/hyperlaunch.
>>>>>>   2. Full DT support: used for device discovery and HW setup.
>>>>>>
>>>>>> Rename HAS_DEVICE_TREE to HAS_DEVICE_TREE_DISCOVERY to describe (2),=
 while
>>>>>> DOM0LESS_BOOT is left to describe (1).
>>>>>
>>>>> Considering hyperlaunch this feels wrong to me. Did you consider spli=
tting
>>>>> HAS_DEVICE_TREE into HAS_DEVICE_TREE_PARSE and HAS_DEVICE_TREE_DISCOV=
ERY,
>>>>> as I suggested on the committers call? You weren't there, but Stefano=
 said
>>>>> he was taking notes.
>>>>
>>>> Some might've been lost is transit, I admit. I don't remember hearing =
about
>>>> a HAS_DEVICE_TREE_PARSE, but it might've very well been me being spott=
y when
>>>> syncing with Stefano.
>>>>
>>>> Having a special HAS_DEVICE_TREE_PARSE doesn't seem very helpful, as e=
very
>>>> arch would have it set.
>>>
>>> Hmm, yes, we don't want or need that. But then what's option 1 about? T=
hat
>>> shouldn't be "described" by DOM0LESS_BOOT.
>>=20
>> It's about x86 using device_tree/ for hyperlaunch. x86 is the single use=
r that
>> doesn't need (2) at all. In the x86 case the same selector that picks =
=20
>>=20
>>>
>>>> I'd definitely like for the "enable support to boot
>>>> several predefined domains from DTB descriptions" to be a single optio=
n for both
>>>> dom0less and hyperlaunch. And be selectable rather than unconditionall=
y selected
>>>> And ideally move towards a future in which both dom0less and hyperlaun=
ch are one
>>>> and the same.
>>>>
>>>> I can do an early rename s/HAS_DOM0LESS/HAS_PREDEFINED_DOMAINS and s/
>>>> DOM0LESS_BOOT/BOOT_PREDEFINED_DOMAINS/ if that helps. I was waiting to=
 do so
>>>> until x86 gains the ability to boot off a DTB to avoid having help mes=
sages
>>>> describing things not yet on the tree.
>>>
>>> I have to admit that it's not clear to me if that would help. As you sa=
y, on
>>> x86 that's not a thing just yet. What I think we need to aim for is to =
not
>>> leave the tree in a state that's more confusing than anything else. Eve=
n if
>>> later (which may be much later) things would get tidied again.
>>=20
>> Ok, how about turning it on its head? Seems like we're in agreement with
>> HAS_DEVICE_TREE_DISCOVERY for Full DT support. There could be a DEVICE_T=
REE_PARSE
>> (no HAS_) that's selected by HAS_DEVICE_TREE_DISCOVERY and DOM0LESS_BOOT=
. This
>> allows x86 to deselect it by not picking DOM0LESS_BOOT.
>>=20
>> Note that x86 cannot select DOM0LESS_BOOT yet, but that's how it'd compi=
le-in
>> hyperlaunch. In the meantime, the tree depends on DEVICE_TREE_PARSE inst=
ead and
>> device_tree/ is gated by DEVICE_TREE_PARSE only.
>>=20
>> Sounds better?
>
> Yes. Except that in the last sentence of the previous paragraph: What's "=
the
> tree"?

By "the tree", I meant the hypervisor tree. I just mean that Kconfig would =
use
DEVICEC_TREE_PARSE for selection purposes and the code would ifdef based on
DEVICE_TREE_PARSE rather than DOM0LESS_BOOT rather than using the latter as=
 a
proxy. =20

> And in device_tree/ wouldn't we end up with unreachable code on x86
> this way (the parts that are needed only by HAS_DEVICE_TREE_DISCOVERY)?

They'd be compiled-out, just as they are now gated on HAS_DEVICE_TREE_DISCO=
VERY on
this patch. device-tree/ as a whole would be gated by DEVICE_TREE_PARSE, an=
d each
individual file inside might optionally be gated by stronger options.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 15:44:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 15:44:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022592.1398414 (Exim 4.92)
	(envelope-from )
	id 1uTjLg-0003bT-Dy; Mon, 23 Jun 2025 15:44:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022592.1398414; Mon, 23 Jun 2025 15:44:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTjLg-0003bM-9q; Mon, 23 Jun 2025 15:44:44 +0000
Received: by outflank-mailman (input) for mailman id 1022592;
 Mon, 23 Jun 2025 15:44:43 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uTjLf-0003bG-KP
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 15:44:43 +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 f8666439-5048-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 17:44:38 +0200 (CEST)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3a6d77b43c9so1966533f8f.3
 for ; Mon, 23 Jun 2025 08:44:38 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d83d5c97sm88299045ad.70.2025.06.23.08.44.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 08:44:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f8666439-5048-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750693478; x=1751298278; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=PzmKB9FqvuYJAQpxWWb5Ye8EaU8SnNUPVvnPtQNZGGw=;
        b=TAyn7pFQCEH9XKftFRQODds0FtQZsmFWZNpy6gAbZJTDvt1naBt/+owaMx54bPISV4
         E1a/A+auUrrRtJCE6dhcFlGoBKMvDistxJaMIDSdyJDtRf+9U/jv/mYCUJEejdveP6RQ
         2H+GsQYXZazub7l8j162JemwL3fOEvEgTdojZavGqM3j4oPC+Tx0dhMQ903ZbPriHBDX
         XRvAnwL/lUinpjmOeTr9CAymWgkWwZk+eZ9RgARrPKYgFlOxy8O0Ik3yjid7K9LC8RcG
         yKxOXHOKjqERuCYWcSghxUEtyqj4sDnaqPfBVc4pJLYmJnIN6KkVSEe+htNItegEL810
         CVqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750693478; x=1751298278;
        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=PzmKB9FqvuYJAQpxWWb5Ye8EaU8SnNUPVvnPtQNZGGw=;
        b=nylH2Zm6MQiK0GKWbqL6BRgNXpYHzardv2s07PgioEfIO2Np1fPxoBLqHw7bT82Wgp
         G87XgIVQaLsAnaaHY72ujtepLugdaWg5EmOvyMypOkuMrB/Lm5Z+Y7t6hbaDaydVkm5+
         emo3eIWMR0zYCnEPtNMKwZq1XL+lMPNLe/XOEUuzEmPeGzAqTUmKgs2t533QgIaFkRal
         8uitAiAwzdnFJ6nfu/OSAbkhTK3G+7AW8kNWBIcIpZbc5lebMZLgyX7O4UsPSZGlD5+T
         dhuvxcGaqAtxyQZxnKGzmVe3YwU3qRwkG0+6p5dRcBBYWeQFYDzwAeNtd2dAQLXfwZrO
         G+SQ==
X-Forwarded-Encrypted: i=1; AJvYcCW9jIjixs+EYzZ/UtMTXMwSVhL9TbEXci2WATA1V+WfshkBdjeEWABMFtBZB93om844oa3A4C6Aovs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyfDhRvDswdUSBP5M+PR/w/MwdyT7jyE/U4x7d31wpFh5u6kB+o
	pYExDaLNIrkTAuGw5SmLZc5N1tthtniQ3KToInlNYmTTQq/YoTCcMK4+WOjHDZq6Hw==
X-Gm-Gg: ASbGnctLb4ITohLcm8mKOsTpd3dOpZPYCyWVHwCmSz/OtddoZ24T5AOoCBWaQb1W+Nr
	+cQeXI058AjFF+emzBzXmT7qj9ELwW9Jh5/da3tNOJnA8y9yjgz8e7JdIVDa+I3ESl0ZEkHgbSq
	wvKq/1hru+q47rawsmASCVYULIKV4I/noqgB9eU5NLGUR1Br1lIhFBDXmm/HQD1VCCem9z2rV35
	mRXSEwhRpExABtjEaBV1GtBSKaFmslmQnQt29MNd5WT3mb1A5lWu2FZ6pTvgA1OC8mPLcDy1Y5Z
	5TUfrukhXKzSz0yd/YFbRP9mu7Ji2NRULlRp+42g8rIr1Gm7p3lhu53omeACBOi62sJU0wbj9S5
	ubqkfzg/ENE1wThd0jcdvdXVEdmvN/BR4+t8Zld3CB3Wph4c=
X-Google-Smtp-Source: AGHT+IFo4RUFA9ErJGxCuOwMUNf0MmoWw0FwFQIKmY5zIRTegZiPA89HlPDzTmSyTXFKF3BC7XZstQ==
X-Received: by 2002:a05:6000:41c5:b0:3a0:a0d1:1131 with SMTP id ffacd0b85a97d-3a6d12c4483mr10535674f8f.7.1750693477888;
        Mon, 23 Jun 2025 08:44:37 -0700 (PDT)
Message-ID: <942a6178-0fe7-468e-8e45-ea255fd20680@suse.com>
Date: Mon, 23 Jun 2025 17:44:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: hardware domain and control domain separation
To: Stefano Stabellini 
Cc: jason.andryuk@amd.com, Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Andrew Cooper ,
 Anthony PERARD ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , ayankuma@amd.com,
 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 21.06.2025 02:41, Stefano Stabellini wrote:
> Regarding hardware domain and control domain separation, Ayan sent to
> xen-devel an architecture specification (a design document) that I wrote
> previously about the topic. This is written as safety document so it is
> using a language and structure specific for that. However, it contains
> much of the explanation needed on the topic:
> 
> https://lore.kernel.org/xen-devel/20250304183115.2509666-1-ayan.kumar.halder@amd.com/

Yet even there the line between Hardware and Control is already blurred
imo. Take "Reboot and shutdown the platform", for example. It seems
pretty likely that Hardware has ways to achieve that without involving
a hypercall. You can also see that (kind of) connection in the
hypervisor itself: The special handling of a domain shutting down is
in hwdom_shutdown(), with the call to it keyed to is_hardware_domain()
(as is to be expected from the function's name).

Furthermore there it is (again) assumed that Control has full privileges.
I did mention before that I'm not convinced any domain, in a
disaggregated setup, would need to have (nor should have) full privilege.

Also a more fundamental question I was wondering about: If Control had
full privilege, nothing else in the system ought to be able to interfere
with it. Yet then how does that domain communicate with the outside
world? It can't have PV or Virtio drivers after all. And even if its
sole communication channel was a UART, Hardware would likely be able to
interfere.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 16:10:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 16:10:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022604.1398424 (Exim 4.92)
	(envelope-from )
	id 1uTjkI-00082h-BP; Mon, 23 Jun 2025 16:10:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022604.1398424; Mon, 23 Jun 2025 16:10: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 1uTjkI-00082a-8O; Mon, 23 Jun 2025 16:10:10 +0000
Received: by outflank-mailman (input) for mailman id 1022604;
 Mon, 23 Jun 2025 16: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 1uTjkG-00082U-WD
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 16:10:09 +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 874fbf5b-504c-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 18:10:06 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a54700a46eso2463119f8f.1
 for ; Mon, 23 Jun 2025 09:10:06 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-7490a627464sm8635569b3a.88.2025.06.23.09.10.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 09:10:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 874fbf5b-504c-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750695006; x=1751299806; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=uePKkPU2TXujvE8O8ZTBeYsDZJqCErT8Vmq5w/Qluww=;
        b=IsFqif3EKkhv5HUmXX4rY9UoWKFCh7omNXdBZbaVhOVC6eFQi05r7C+nPolVTRNmCe
         A+TFN5STTLAkIOSmjWoB+mabHp5kn6bSHt2MT342hJag1mxrLrrZcgTIrKwgHN7ljVQr
         Y5SDCwtgH3WaFFm2692z5xlW84TIe8Q+VWk+311Xma1vpZPHZqdtPp2cpQlM+lno2+DR
         QtDKpaPRqk/hEoh+FNC8WnivJM1OmFbTziZ7JnTShZlFGgg4OBr8gf5zsukAdqAsqEdZ
         W7i3KohNKirrjSOq43w5MxeqX8aEdxYE66ZnCIzi018372jsZ/moQnYVYP2jx7/WabVu
         b/BA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750695006; x=1751299806;
        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=uePKkPU2TXujvE8O8ZTBeYsDZJqCErT8Vmq5w/Qluww=;
        b=c3TrV2bWIMJkVREMEV2cBnybATHrXdY15p9IVJ70suLR28sDxOiFJcGGkafHEJKtsY
         kK+bwyeMvZsM0scsBL4+V/Y9I1xPQJGy6z206QubCvYt89qMMLgCVh/UKBOUoTxPhHii
         5x6nSDQKN5Y+TEzScFrA+O3KSmjCiGHo7XW61aGPgC8mYxvJeUBXKJRUlkizKk+z5uOc
         4WTm9zF2SdREkTQASfxEocW1Vl3E3jjsBId3waWsQ9HNT3ggHgaLQc/4fruCnQHpk/pu
         j+eOnNvpcG0VBJKl6AP7TYftnKGD4MX8qh5wjlrn76K1Ka/VWBSywVT79b42Cqs1nR9M
         UEKA==
X-Forwarded-Encrypted: i=1; AJvYcCU2whrGLNtE7LLqujh8E5ChvoCHbvVYWb3nL4NgyZ1oIRNV2Dl9csXTODf+i3pW3a2bwIwtlzgvfrw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw5Q4nWSgXk9I5Znjab3eeL0f2ehuXhveN0v5+lp83FTflJ+V0T
	jL0oLSqQtc88TWUhMphCDMJ16p/k+wmW4+9F7hm5Tfy3soOTgny6A86L7w1XrvsM1Q==
X-Gm-Gg: ASbGncuA+QCGXja4SWEJXuwaddXSXTFHYdxqCV8qqZek81eYbOK7IjVaf7NYuqRWIAj
	LN+gKPshZPcVQCmlcsXLKb7FrM+uPWABzmP/4CaSqSyu25e5oBg+TOfTQi1fnmaHF0dg4sHsdrx
	FhWzqbSFA2/5NgZaeJnfjGeyKB21Bj+347QBS2Yhr+NKSWw0o9k4p/TLbIFfIbwNWZ3rGjvfhM9
	VA5RTyzfsRnluYOfVJ8NXJPYFVYSS7ogQE6ypRJNTdpB5CZhw4E+MissgWSKaGK2XyNg7eWc4Ru
	7uN2lRU9KvA3wMHB4mjlcxkMIO6yYOC1NMQUkmL5BTr/AQYJPAJcrlUamTmUKr69rrbZKXaQlvC
	637zjUAE9PcI5PTca6MLazrqQxukcezGg0fjyoMBkEcEM69s=
X-Google-Smtp-Source: AGHT+IHbg0ri65Vc5qpnkhvnGmrcY3za+gxMlDYNfPLvnOY7k8F4pwkmwztgBSZl7V0wp7OVAD5fWw==
X-Received: by 2002:a05:6000:25ca:b0:3a3:621a:d3c5 with SMTP id ffacd0b85a97d-3a6d1301e71mr10140162f8f.19.1750695006091;
        Mon, 23 Jun 2025 09:10:06 -0700 (PDT)
Message-ID: 
Date: Mon, 23 Jun 2025 18:09:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] xen/console: introduce domain_console struct
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org,
 dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250623013406.174027-1-dmukhin@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: <20250623013406.174027-1-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 23.06.2025 03:34, dmkhn@proton.me wrote:
> @@ -769,22 +770,23 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer,
>              } while ( --kcount > 0 );
>  
>              *kout = '\0';
> -            spin_lock(&cd->pbuf_lock);
> +            spin_lock(&cons->lock);
>              kcount = kin - kbuf;
>              if ( c != '\n' &&
> -                 (cd->pbuf_idx + (kout - kbuf) < (DOMAIN_PBUF_SIZE - 1)) )
> +                 cons->idx + kout - kbuf < DOMAIN_CONSOLE_BUF_SIZE - 1 )

The dropping of the parentheses around the pointer subtraction is
problematic: You open up UB opportunities this way, as evaluation order
changes. We had UBSAN trip up on similar constructs already in the past.

>              {
>                  /* buffer the output until a newline */
> -                memcpy(cd->pbuf + cd->pbuf_idx, kbuf, kout - kbuf);
> -                cd->pbuf_idx += (kout - kbuf);
> +                memcpy(cons->buf + cons->idx, kbuf, kout - kbuf);
> +                cons->idx += (kout - kbuf);

Here, otoh, the parentheses could be dropped while touching the line.

>              }
>              else
>              {
> -                cd->pbuf[cd->pbuf_idx] = '\0';
> -                guest_printk(cd, XENLOG_G_DEBUG "%s%s\n", cd->pbuf, kbuf);
> -                cd->pbuf_idx = 0;
> +                cons->buf[cons->idx] = '\0';
> +                guest_printk(cd,
> +                             XENLOG_G_DEBUG "%s%s\n", cons->buf, kbuf);

There's no need to wrap lines here, is there?

> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -371,6 +371,20 @@ struct evtchn_port_ops;
>  
>  #define MAX_NR_IOREQ_SERVERS 8
>  
> +/* Arbitrary value. */
> +#define DOMAIN_CONSOLE_BUF_SIZE 256

Nit: The value isn't entirely arbitrary.

> +/* Domain console settings. */
> +struct domain_console {
> +    /* hvm_print_line() and guest_console_write() logging. */
> +    char buf[DOMAIN_CONSOLE_BUF_SIZE];

This placement will negatively affect code generation on at least x86.
I did suggest putting the array at the end, for this very reason.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 18:28:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 18:28:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022622.1398433 (Exim 4.92)
	(envelope-from )
	id 1uTltY-000697-LQ; Mon, 23 Jun 2025 18:27:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022622.1398433; Mon, 23 Jun 2025 18:27: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 1uTltY-000690-Ii; Mon, 23 Jun 2025 18:27:52 +0000
Received: by outflank-mailman (input) for mailman id 1022622;
 Mon, 23 Jun 2025 18:27: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 1uTltW-00068u-JZ
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 18:27:51 +0000
Received: from mail-10630.protonmail.ch (mail-10630.protonmail.ch
 [79.135.106.30]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c2c2bbdf-505f-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 20:27:47 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c2c2bbdf-505f-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1750703264; x=1750962464;
	bh=+EgYvJibe3fChy+oI7fx70GpQB08CAfQ06lu+ZUzrDU=;
	h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
	 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector;
	b=e/id+MeTsa32WsvE0VBVwnozDC9fwJIiWINhYSLBaf6nq3A3+mawoEQaacMge6Qbs
	 dtPBUfQjDCVT2vOJ8CNNu4EIInopco/cuVZs17S8G0Ht4ntCZ0xEXskJ8ew9uZkUhp
	 A2q0rUaqHzT5K84I7sT//R/d41dRilnAKzeQQ+uM2/xYUnnxsaKgiEzsqPtP6SwfmX
	 KaHg0G3WGF0bmsoZ8c+b/eFViqP30WAbiI+csD/bjMTJh30fDdgIljSg6qliYfXJRh
	 F12i+psSoteaM55ke35lpu6vCgO8+QPxRG2vKnaXr0pXwYs6wCT0VxY6zdIHd4CiGW
	 exV7gq1QGaSdA==
Date: Mon, 23 Jun 2025 18:27:35 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v10 0/3] xen/domain: domain ID allocation
Message-ID: <20250623182721.194238-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 4d95f183545ea17b86075e894038abb81b812375
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Patch 1 introduces new domid_{alloc,free} calls.
Patch 2 adjusts create_dom0() messages (use %pd).
Patch 3 replaces open-coded domain ID 0 with get_initial_domain_id() where
possible.

Link to v9: https://lore.kernel.org/all/20250528225030.2652166-2-dmukhin@fo=
rd.com/
Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/1=
883539583

Denis Mukhin (3):
  xen/domain: unify domain ID allocation
  xen/domain: update create_dom0() messages
  xen/domain: use get_initial_domain_id() instead of open-coded 0

 xen/arch/arm/domain_build.c             | 15 +++--
 xen/arch/x86/setup.c                    | 11 ++--
 xen/common/device-tree/dom0less-build.c | 17 +++---
 xen/common/domain.c                     | 79 ++++++++++++++++++++++++-
 xen/common/domctl.c                     | 42 ++-----------
 xen/include/xen/domain.h                |  3 +
 6 files changed, 110 insertions(+), 57 deletions(-)

--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Mon Jun 23 18:28:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 18:28:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022624.1398444 (Exim 4.92)
	(envelope-from )
	id 1uTltp-0006R9-SU; Mon, 23 Jun 2025 18:28:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022624.1398444; Mon, 23 Jun 2025 18:28: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 1uTltp-0006R2-PH; Mon, 23 Jun 2025 18:28:09 +0000
Received: by outflank-mailman (input) for mailman id 1022624;
 Mon, 23 Jun 2025 18:28: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 1uTlto-00068u-1e
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 18:28:08 +0000
Received: from mail-10630.protonmail.ch (mail-10630.protonmail.ch
 [79.135.106.30]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cee38958-505f-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 20:28:07 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cee38958-505f-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1750703286; x=1750962486;
	bh=UkTM0QT8ZgoZN9K96tEgWBupK+Zqg6ED8nILkPgW1Hw=;
	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;
	b=ekM5XLHqEqpnfVuS2tJoJMLeYZ3J0jxon4qTV8orjW6CrR9CSxuI5AwhBo+OXD/mG
	 QJqD/MQifjZP/PE6AjskyCYLoxFj04VM5ZuEmfIodrzmqVPwm1nkl2ogUNZdVMiIUO
	 YNAQ0/kHFdFZicmZVW7lZ62FW2+NcCBqThCnwlgxnh9SYBSUd16J1FAyTSyRdQfN6H
	 e2KGBbT5vBmLwSf8TrJ5YgNDscdUebI9BfgyWqgbH2DdZUIV9xAslOmqcWEGw6rmGV
	 HVLuRBAJRLwkPOHqjAhHxoP6Rtd6Zm3k2ujJFGIJ8M9xqA2jlnH6mDw2lsc2S8Jwn/
	 +uAEhAlWbN/kw==
Date: Mon, 23 Jun 2025 18:28:01 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v10 1/3] xen/domain: unify domain ID allocation
Message-ID: <20250623182721.194238-2-dmukhin@ford.com>
In-Reply-To: <20250623182721.194238-1-dmukhin@ford.com>
References: <20250623182721.194238-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 9d97cf73f5ad68b5742ab157ab71251a5bb64d18
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Currently, there are two different domain ID allocation implementations:

  1) Sequential IDs allocation in dom0less Arm code based on max_init_domid=
;

  2) Sequential IDs allocation in XEN_DOMCTL_createdomain; does not use
     max_init_domid (both Arm and x86).

The domain ID allocation covers dom0 or late hwdom, predefined domains,
post-boot domains, excluding Xen system domains (domid >=3D
DOMID_FIRST_RESERVED).

It makes sense to have a common helper code for such task across architectu=
res
(Arm and x86) and between dom0less / toolstack domU allocation.

Note, fixing dependency on max_init_domid is out of scope of this patch.

Wrap the domain ID allocation as an arch-independent function domid_alloc()=
 in
common/domain.c based on the bitmap.

Allocation algorithm:
- If an explicit domain ID is provided, verify its availability and use it =
if
  ID is not used;
- If DOMID_INVALID is provided, search the range [1..DOMID_FIRST_RESERVED-1=
],
  starting from the last used ID. IDs are not wrapped around in dom0less ca=
se.
  Implementation guarantees that two consecutive calls will never return th=
e
  same ID. ID#0 is reserved for the first boot domain (currently, dom0) and
  excluded from allocation range.

Remove is_free_domid() helper as it is not needed now.

No functional change intended.

Signed-off-by: Denis Mukhin 
---
Changes from v9:
- dropped unrelated message formatting from create_dom0()
- no wraparound of IDs in dom0less case
- fixed ID#0 treatment

Link to v9: https://lore.kernel.org/r/20250528225030.2652166-2-dmukhin@ford=
.com
---
 xen/arch/arm/domain_build.c             |  7 ++-
 xen/arch/x86/setup.c                    |  7 ++-
 xen/common/device-tree/dom0less-build.c | 17 +++---
 xen/common/domain.c                     | 75 +++++++++++++++++++++++++
 xen/common/domctl.c                     | 42 ++------------
 xen/include/xen/domain.h                |  3 +
 6 files changed, 102 insertions(+), 49 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 4ff161887ec3..9fa5143eb98c 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2049,6 +2049,7 @@ void __init create_dom0(void)
         .grant_opts =3D XEN_DOMCTL_GRANT_version(opt_gnttab_max_version),
     };
     unsigned int flags =3D CDF_privileged | CDF_hardware;
+    domid_t domid;
     int rc;
=20
     /* The vGIC for DOM0 is exactly emulating the hardware GIC */
@@ -2073,7 +2074,11 @@ void __init create_dom0(void)
     if ( !llc_coloring_enabled )
         flags |=3D CDF_directmap;
=20
-    dom0 =3D domain_create(0, &dom0_cfg, flags);
+    domid =3D domid_alloc(0);
+    if ( domid =3D=3D DOMID_INVALID )
+        panic("Error allocating domain ID 0\n");
+
+    dom0 =3D domain_create(domid, &dom0_cfg, flags);
     if ( IS_ERR(dom0) )
         panic("Error creating domain 0 (rc =3D %ld)\n", PTR_ERR(dom0));
=20
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index f32efa7c6045..7adb92d78a18 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1044,8 +1044,11 @@ static struct domain *__init create_dom0(struct boot=
_info *bi)
     if ( iommu_enabled )
         dom0_cfg.flags |=3D XEN_DOMCTL_CDF_iommu;
=20
-    /* Create initial domain.  Not d0 for pvshim. */
-    bd->domid =3D get_initial_domain_id();
+    /* Allocate initial domain ID.  Not d0 for pvshim. */
+    bd->domid =3D domid_alloc(get_initial_domain_id());
+    if ( bd->domid =3D=3D DOMID_INVALID )
+        panic("Error allocating domain ID %d\n", get_initial_domain_id());
+
     d =3D domain_create(bd->domid, &dom0_cfg,
                       pv_shim ? 0 : CDF_privileged | CDF_hardware);
     if ( IS_ERR(d) )
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tr=
ee/dom0less-build.c
index 3d503c697337..576fdfa6a19a 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -839,15 +839,13 @@ void __init create_domUs(void)
         struct xen_domctl_createdomain d_cfg =3D {0};
         unsigned int flags =3D 0U;
         bool has_dtb =3D false;
+        domid_t domid;
         uint32_t val;
         int rc;
=20
         if ( !dt_device_is_compatible(node, "xen,domain") )
             continue;
=20
-        if ( (max_init_domid + 1) >=3D DOMID_FIRST_RESERVED )
-            panic("No more domain IDs available\n");
-
         d_cfg.max_evtchn_port =3D 1023;
         d_cfg.max_grant_frames =3D -1;
         d_cfg.max_maptrack_frames =3D -1;
@@ -965,12 +963,13 @@ void __init create_domUs(void)
=20
         arch_create_domUs(node, &d_cfg, flags);
=20
-        /*
-         * The variable max_init_domid is initialized with zero, so here i=
t's
-         * very important to use the pre-increment operator to call
-         * domain_create() with a domid > 0. (domid =3D=3D 0 is reserved f=
or Dom0)
-         */
-        d =3D domain_create(++max_init_domid, &d_cfg, flags);
+        domid =3D domid_alloc(DOMID_INVALID);
+        if ( domid =3D=3D DOMID_INVALID )
+            panic("Error allocating ID for domain %s\n", dt_node_name(node=
));
+        if ( max_init_domid < domid )
+            max_init_domid =3D domid;
+
+        d =3D domain_create(domid, &d_cfg, flags);
         if ( IS_ERR(d) )
             panic("Error creating domain %s (rc =3D %ld)\n",
                   dt_node_name(node), PTR_ERR(d));
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 434d32901b1b..be022c720b13 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -66,6 +66,14 @@ DEFINE_RCU_READ_LOCK(domlist_read_lock);
 static struct domain *domain_hash[DOMAIN_HASH_SIZE];
 struct domain *domain_list;
=20
+/*
+ * Domain ID allocator.
+ * Covers dom0 or late hwdom, predefined domains, post-boot domains; exclu=
des
+ * Xen system domains (ID >=3D DOMID_FIRST_RESERVED).
+ */
+static DEFINE_SPINLOCK(domid_lock);
+static DECLARE_BITMAP(domid_bitmap, DOMID_FIRST_RESERVED);
+
 /*
  * Insert a domain into the domlist/hash.  This allows the domain to be lo=
oked
  * up by domid, and therefore to be the subject of hypercalls/etc.
@@ -1452,6 +1460,8 @@ void domain_destroy(struct domain *d)
=20
     TRACE_TIME(TRC_DOM0_DOM_REM, d->domain_id);
=20
+    domid_free(d->domain_id);
+
     /* Remove from the domlist/hash. */
     domlist_remove(d);
=20
@@ -2433,6 +2443,71 @@ void thaw_domains(void)
     rcu_read_unlock(&domlist_read_lock);
 }
=20
+domid_t domid_alloc(domid_t domid)
+{
+    static domid_t domid_last;
+
+    spin_lock(&domid_lock);
+
+    /* Exact match. */
+    if ( domid < DOMID_FIRST_RESERVED )
+    {
+        if ( __test_and_set_bit(domid, domid_bitmap) )
+            domid =3D DOMID_INVALID;
+    }
+    /*
+     * Exhaustive search.
+     *
+     * Domain ID#0 is reserved for the first boot domain (e.g. control dom=
ain)
+     * and excluded from allocation.
+     *
+     * In dom0less build, domains are not dynamically destroyed, so there'=
s no
+     * need to do a wraparound of the IDs.
+     */
+#ifdef CONFIG_DOM0LESS_BOOT
+    else if ( domid_last + 1 >=3D DOMID_FIRST_RESERVED )
+    {
+        domid =3D DOMID_INVALID;
+    }
+#endif
+    else
+    {
+        domid =3D find_next_zero_bit(domid_bitmap,
+                                   DOMID_FIRST_RESERVED,
+                                   domid_last + 1);
+#ifdef CONFIG_DOM0LESS_BOOT
+        if ( domid =3D=3D DOMID_FIRST_RESERVED )
+            domid =3D find_next_zero_bit(domid_bitmap,
+                                       DOMID_FIRST_RESERVED,
+                                       1);
+#endif
+
+        if ( domid < DOMID_FIRST_RESERVED )
+        {
+            __set_bit(domid, domid_bitmap);
+            domid_last =3D domid;
+        }
+        else
+        {
+            domid =3D DOMID_INVALID;
+        }
+    }
+
+    spin_unlock(&domid_lock);
+
+    return domid;
+}
+
+void domid_free(domid_t domid)
+{
+    if ( domid < DOMID_FIRST_RESERVED )
+    {
+        spin_lock(&domid_lock);
+        __clear_bit(domid, domid_bitmap);
+        spin_unlock(&domid_lock);
+    }
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index bfe2e1f9f057..8ef0c147c9b0 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -49,20 +49,6 @@ static int xenctl_bitmap_to_nodemask(nodemask_t *nodemas=
k,
                                    MAX_NUMNODES);
 }
=20
-static inline int is_free_domid(domid_t dom)
-{
-    struct domain *d;
-
-    if ( dom >=3D DOMID_FIRST_RESERVED )
-        return 0;
-
-    if ( (d =3D rcu_lock_domain_by_id(dom)) =3D=3D NULL )
-        return 1;
-
-    rcu_unlock_domain(d);
-    return 0;
-}
-
 void getdomaininfo(struct domain *d, struct xen_domctl_getdomaininfo *info=
)
 {
     struct vcpu *v;
@@ -421,36 +407,18 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u=
_domctl)
=20
     case XEN_DOMCTL_createdomain:
     {
-        domid_t        dom;
-        static domid_t rover =3D 0;
+        domid_t domid =3D domid_alloc(op->domain);
=20
-        dom =3D op->domain;
-        if ( (dom > 0) && (dom < DOMID_FIRST_RESERVED) )
+        if ( domid =3D=3D DOMID_INVALID )
         {
             ret =3D -EEXIST;
-            if ( !is_free_domid(dom) )
-                break;
-        }
-        else
-        {
-            for ( dom =3D rover + 1; dom !=3D rover; dom++ )
-            {
-                if ( dom =3D=3D DOMID_FIRST_RESERVED )
-                    dom =3D 1;
-                if ( is_free_domid(dom) )
-                    break;
-            }
-
-            ret =3D -ENOMEM;
-            if ( dom =3D=3D rover )
-                break;
-
-            rover =3D dom;
+            break;
         }
=20
-        d =3D domain_create(dom, &op->u.createdomain, false);
+        d =3D domain_create(domid, &op->u.createdomain, false);
         if ( IS_ERR(d) )
         {
+            domid_free(domid);
             ret =3D PTR_ERR(d);
             d =3D NULL;
             break;
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index e10baf2615fd..8aab05ae93c8 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -38,6 +38,9 @@ void arch_get_domain_info(const struct domain *d,
=20
 domid_t get_initial_domain_id(void);
=20
+domid_t domid_alloc(domid_t domid);
+void domid_free(domid_t domid);
+
 /* CDF_* constant. Internal flags for domain creation. */
 /* Is this a privileged domain? */
 #define CDF_privileged           (1U << 0)
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Mon Jun 23 18:28:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 18:28:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022625.1398454 (Exim 4.92)
	(envelope-from )
	id 1uTlts-0006g7-4j; Mon, 23 Jun 2025 18:28:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022625.1398454; Mon, 23 Jun 2025 18:28: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 1uTlts-0006g0-0N; Mon, 23 Jun 2025 18:28:12 +0000
Received: by outflank-mailman (input) for mailman id 1022625;
 Mon, 23 Jun 2025 18:28: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 1uTltr-00068u-0n
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 18:28:11 +0000
Received: from mail-10629.protonmail.ch (mail-10629.protonmail.ch
 [79.135.106.29]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d0bbcd0a-505f-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 20:28:10 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d0bbcd0a-505f-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1750703288; x=1750962488;
	bh=koB+Pvq4aT3GTen+IwSnn3j1ioEvBKt7OHrxH//L4u4=;
	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;
	b=Jvj2FO94Cl2vBjFve4VcxT1V0yJH3hS/oFzeBDzl1Ks8lnOncEC0r0cIVeKX6N2bQ
	 oHp4aXnLF8hpx71cMGaw6cXWJtVAsz631q+JCSBhSgw1BR64bXwUXZ3GDTOqkkALo/
	 rDiu3FWgBojnjwHpsn7qjAI9Hu21fS++UPnFhw1zNXCXzM/lur4mhOt9C/HzI76CCV
	 D9Wi5eWM6YtiIlRwJwqN28KBCx5q3kxwxqi5zTzHOwOixPGVEGmZlkHfNjk8Fcp51c
	 3ufyjRktJVZfbTXYZBacNydSIt6sXL0P1wSYPtSATGot2Ti+EvGYgWnNaqql6K94+H
	 ejkvzw+BsY3/A==
Date: Mon, 23 Jun 2025 18:28:06 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v10 2/3] xen/domain: update create_dom0() messages
Message-ID: <20250623182721.194238-3-dmukhin@ford.com>
In-Reply-To: <20250623182721.194238-1-dmukhin@ford.com>
References: <20250623182721.194238-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: dd797a6c066bda0250210592555991ff73fdfe6b
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Use %pd for domain identification in error/panic messages in create_dom0().

No functional change.

Signed-off-by: Denis Mukhin 
---
Changes since v9:
- new patch
---
 xen/arch/arm/domain_build.c | 8 ++++----
 xen/arch/x86/setup.c        | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 9fa5143eb98c..b59b56636920 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2080,17 +2080,17 @@ void __init create_dom0(void)
=20
     dom0 =3D domain_create(domid, &dom0_cfg, flags);
     if ( IS_ERR(dom0) )
-        panic("Error creating domain 0 (rc =3D %ld)\n", PTR_ERR(dom0));
+        panic("Error creating d%d (rc =3D %ld)\n", domid, PTR_ERR(dom0));
=20
     if ( llc_coloring_enabled && (rc =3D dom0_set_llc_colors(dom0)) )
-        panic("Error initializing LLC coloring for domain 0 (rc =3D %d)\n"=
, rc);
+        panic("Error initializing LLC coloring for %pd (rc =3D %d)\n", dom=
0, rc);
=20
     if ( alloc_dom0_vcpu0(dom0) =3D=3D NULL )
-        panic("Error creating domain 0 vcpu0\n");
+        panic("Error creating %pdv0\n", dom0);
=20
     rc =3D construct_dom0(dom0);
     if ( rc )
-        panic("Could not set up DOM0 guest OS (rc =3D %d)\n", rc);
+        panic("Could not set up guest OS for %pd (rc =3D %d)\n", dom0, rc)=
;
=20
     set_xs_domain(dom0);
 }
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 7adb92d78a18..28bcfd1861d4 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1080,7 +1080,7 @@ static struct domain *__init create_dom0(struct boot_=
info *bi)
=20
         if ( (strlen(acpi_param) =3D=3D 0) && acpi_disabled )
         {
-            printk("ACPI is disabled, notifying Domain 0 (acpi=3Doff)\n");
+            printk("ACPI is disabled, notifying %pd (acpi=3Doff)\n", d);
             safe_strcpy(acpi_param, "off");
         }
=20
@@ -1095,7 +1095,7 @@ static struct domain *__init create_dom0(struct boot_=
info *bi)
=20
     bd->d =3D d;
     if ( construct_dom0(bd) !=3D 0 )
-        panic("Could not construct domain 0\n");
+        panic("Could not construct %pd\n", d);
=20
     bd->cmdline =3D NULL;
     xfree(cmdline);
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Mon Jun 23 18:28:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 18:28:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022628.1398464 (Exim 4.92)
	(envelope-from )
	id 1uTlu2-00077Q-As; Mon, 23 Jun 2025 18:28:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022628.1398464; Mon, 23 Jun 2025 18:28: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 1uTlu2-00077J-7f; Mon, 23 Jun 2025 18:28:22 +0000
Received: by outflank-mailman (input) for mailman id 1022628;
 Mon, 23 Jun 2025 18:28: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 1uTlu1-00074l-1R
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 18:28:21 +0000
Received: from mail-10631.protonmail.ch (mail-10631.protonmail.ch
 [79.135.106.31]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d5d8047c-505f-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 20:28:19 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d5d8047c-505f-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1750703297; x=1750962497;
	bh=Udhc20tlUIA4sPslsaWRUlqBtQkVoUUerUSlsQ1uvRs=;
	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;
	b=YmYPxPJxI+WHS+wxEciq03oQLrKtZG9i34qbOUQSCwRnimQenTwCQf+Iy6GhaujSU
	 mYSpFXtxKXSQYHjL+g3/h5YOCWk3tuQ6VYIURvA6vYEMjYzsEXglgTSsUqQo2RZOzb
	 s4wbn2+SR2T7r+D/79SOpLIF3uuvr8GGrKaWMKi+yW+XKBUtFR5UfJ3xhDaz+kZPNr
	 xPMCfc7ElW8xzkiziJR74Za1qahTt8UrvLmQFm11rhpc5MRWxEeliXPDyIoE2AbKUE
	 Vj/UKyDsNPPviSlVf6bYXrmPREh3yPbqCsScm2QZ9XToR8vwvIykEydY1VjbFZ7bAF
	 CdwZFB6I+xfig==
Date: Mon, 23 Jun 2025 18:28:12 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v10 3/3] xen/domain: use get_initial_domain_id() instead of open-coded 0
Message-ID: <20250623182721.194238-4-dmukhin@ford.com>
In-Reply-To: <20250623182721.194238-1-dmukhin@ford.com>
References: <20250623182721.194238-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 6d9b981d706e86ad449e201c8684fa2999e4884c
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Remove the open-coded domain ID 0 and replace it with a call to
get_initial_domain_id().

Signed-off-by: Denis Mukhin 
---
Changes since v9:
- new patch
---
 xen/arch/arm/domain_build.c | 4 ++--
 xen/common/domain.c         | 6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index b59b56636920..b525d78c608f 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2074,9 +2074,9 @@ void __init create_dom0(void)
     if ( !llc_coloring_enabled )
         flags |=3D CDF_directmap;
=20
-    domid =3D domid_alloc(0);
+    domid =3D domid_alloc(get_initial_domain_id());
     if ( domid =3D=3D DOMID_INVALID )
-        panic("Error allocating domain ID 0\n");
+        panic("Error allocating domain ID %d\n", get_initial_domain_id());
=20
     dom0 =3D domain_create(domid, &dom0_cfg, flags);
     if ( IS_ERR(dom0) )
diff --git a/xen/common/domain.c b/xen/common/domain.c
index be022c720b13..27575b4610e3 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -492,7 +492,7 @@ static int late_hwdom_init(struct domain *d)
     struct domain *dom0;
     int rv;
=20
-    if ( d !=3D hardware_domain || d->domain_id =3D=3D 0 )
+    if ( d !=3D hardware_domain || d->domain_id =3D=3D get_initial_domain_=
id() )
         return 0;
=20
     rv =3D xsm_init_hardware_domain(XSM_HOOK, d);
@@ -501,7 +501,7 @@ static int late_hwdom_init(struct domain *d)
=20
     printk("Initialising hardware domain %d\n", hardware_domid);
=20
-    dom0 =3D rcu_lock_domain_by_id(0);
+    dom0 =3D rcu_lock_domain_by_id(get_initial_domain_id());
     ASSERT(dom0 !=3D NULL);
     /*
      * Hardware resource ranges for domain 0 have been set up from
@@ -2479,7 +2479,7 @@ domid_t domid_alloc(domid_t domid)
         if ( domid =3D=3D DOMID_FIRST_RESERVED )
             domid =3D find_next_zero_bit(domid_bitmap,
                                        DOMID_FIRST_RESERVED,
-                                       1);
+                                       get_initial_domain_id() + 1);
 #endif
=20
         if ( domid < DOMID_FIRST_RESERVED )
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Mon Jun 23 18:29:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 18:29:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022652.1398474 (Exim 4.92)
	(envelope-from )
	id 1uTlun-00088d-Pu; Mon, 23 Jun 2025 18:29:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022652.1398474; Mon, 23 Jun 2025 18:29:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTlun-00088V-Mp; Mon, 23 Jun 2025 18:29:09 +0000
Received: by outflank-mailman (input) for mailman id 1022652;
 Mon, 23 Jun 2025 18:29: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 1uTlum-00074l-Dc
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 18:29:08 +0000
Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com
 [2607:f8b0:4864:20::830])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f211d5e6-505f-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 20:29:06 +0200 (CEST)
Received: by mail-qt1-x830.google.com with SMTP id
 d75a77b69052e-4a56cc0def0so77158081cf.3
 for ; Mon, 23 Jun 2025 11:29:06 -0700 (PDT)
Received: from [10.138.10.6] ([89.187.178.201])
 by smtp.gmail.com with ESMTPSA id
 d75a77b69052e-4a779d6a110sm41342241cf.23.2025.06.23.11.29.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 11:29:04 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f211d5e6-505f-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750703346; x=1751308146; 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=dv76SpzBQ0HkAszC6EPjpWhikjh4DRTPWMdPYRzhil8=;
        b=Mk0cBOA1InpRjaZ8M/CfJPlP6c/EB6AdnDUdw1IcteIUAqu7UUtgUZ1aQIqZW1rQcu
         tl2XLjs+lf0/hKYxRgvSg8+t9tlp4sYDtCvWRrlWdSFI22oSZtVtSrwJxYXAQuKuLNsi
         LyxnsU51VZ69pu4wstJuw6BAOwVVhVjzP/o6ruAB/9RiUP5J3WblwJzvXJe7BZHVNJN3
         AfU9IfsWX7Kds/Sazri80OUlozzU/LsEqEw/i1/HC/25f86Jk3nWzFiq+llv9xiPJK8I
         b9RlIl4qbW/Bisiq75r7/4PNHWY0uhJSYF+B+ileLAaVxHJr0UMR8irThN4KFgfIMgNb
         Zm5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750703346; x=1751308146;
        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=dv76SpzBQ0HkAszC6EPjpWhikjh4DRTPWMdPYRzhil8=;
        b=HSisUXlbyuVMlyo13mRCchlHw7MTv4wSTZIgUbOTtX5hvo/ejWSj4C0lP113q9O9/l
         4Za+pZY0vrtvRd7xLKW0vLXaEoRIDbnrtFf8chz5ZO7Sn+5SWYnQfAaNszSKSt0Unnqx
         2S8ArO0N2sfpUZfU+FWqPPX7OEoTATZZhfsjqRpDlRAUiNvinttW8/+uXjvq90FW48ni
         ETKzvq/rLeO9283g54julRnx8O61s8TRcGw5xjbUVHQgh0/RoBysrOmvtEPYKAd9a7au
         9OAB3MuLi/LMHwOOuRqENc7CCQWiiC1aDdfX3elXHiH+6InZoz2TCasLMNgNOTbeNi8m
         Y8wg==
X-Forwarded-Encrypted: i=1; AJvYcCX2mJ1oT6h6GZkRWF9RKmzhaFEP1VI2nx0ofZtsz2TY2MT8NqAMjwKwSezHSt8SJamyvck1/bA/7xQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw1xVqM5YUyalulbDtBIlKk44vys//lQucWBDA2VkphT7+PsBfI
	mTd2qfja4fQLTat2S3ptskxuPL0fc20SnEoWVLoOe4tF7GVB1xi9JPqp
X-Gm-Gg: ASbGncvrHt9JkYTq1fxDVhOeplWgR7SdgDaG36mPfHq99JfrYKpXTsecWauNa69I50h
	hg7BXSLYyJyusCDZRjUXpIwUzGT1vlXMlFijo+j0tHoLjcAgtuBGFj3/63NMjGaSywXNjF0Dwgo
	7vjirNqO+EVbmNL0X3ELKqPf+sN27439jCO0T9DX4RQKgHuobbIXXXuO1PzOntxbR6i2JzGd9SC
	fQpPwnbF5zt218KiOy9jCn2clf31KCafCq20MHrzDF0pwsc1KiJAL1kedrwsJBaT2dJ/7OXwDy3
	BCEQ20iriQhjYqqaV3nVRdBJ8b8GmwwrSmQcSbmDACQDJrPNiIYerGNS6fPbgXqU5qw=
X-Google-Smtp-Source: AGHT+IFDxJjWk1sOdZj2ww4Pn9fI9RS74vJkJqHGfkaqJWVaLK3tLgywuFYgoCuY722zB6yfdpAsJw==
X-Received: by 2002:a05:622a:5597:b0:4a4:4bdc:8b1 with SMTP id d75a77b69052e-4a77a20c018mr231352691cf.19.1750703345510;
        Mon, 23 Jun 2025 11:29:05 -0700 (PDT)
Message-ID: 
Date: Mon, 23 Jun 2025 14:28:47 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 6/6] [DO NOT MERGE] CI: example how to use ssh to
 extract logs
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , xen-devel@lists.xenproject.org
Cc: Doug Goldstein ,
 Stefano Stabellini 
References: 
 <9e10434c1e5ff6edb53b9efc65485247ad450f0c.1750686195.git-series.marmarek@invisiblethingslab.com>
Content-Language: en-US
From: Demi Marie Obenour 
Autocrypt: addr=demiobenour@gmail.com; keydata=
 xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49yB+l2nipd
 aq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYfbWpr/si88QKgyGSV
 Z7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/UorR+FaSuVwT7rqzGrTlscnT
 DlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7MMPCJwI8JpPlBedRpe9tfVyfu3euTPLPx
 wcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9Hzx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR
 6h3nBc3eyuZ+q62HS1pJ5EvUT1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl
 5FMWo8TCniHynNXsBtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2
 Bkg1b//r6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nSm9BBff0N
 m0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQABzTxEZW1pIE1hcmll
 IE9iZW5vdXIgKGxvdmVyIG9mIGNvZGluZykgPGRlbWlvYmVub3VyQGdtYWlsLmNvbT7CwXgE
 EwECACIFAlp+A0oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELKItV//nCLBhr8Q
 AK/xrb4wyi71xII2hkFBpT59ObLN+32FQT7R3lbZRjVFjc6yMUjOb1H/hJVxx+yo5gsSj5LS
 9AwggioUSrcUKldfA/PKKai2mzTlUDxTcF3vKx6iMXKA6AqwAw4B57ZEJoMM6egm57TV19kz
 PMc879NV2nc6+elaKl+/kbVeD3qvBuEwsTe2Do3HAAdrfUG/j9erwIk6gha/Hp9yZlCnPTX+
 VK+xifQqt8RtMqS5R/S8z0msJMI/ajNU03kFjOpqrYziv6OZLJ5cuKb3bZU5aoaRQRDzkFIR
 6aqtFLTohTo20QywXwRa39uFaOT/0YMpNyel0kdOszFOykTEGI2u+kja35g9TkH90kkBTG+a
 EWttIht0Hy6YFmwjcAxisSakBuHnHuMSOiyRQLu43ej2+mDWgItLZ48Mu0C3IG1seeQDjEYP
 tqvyZ6bGkf2Vj+L6wLoLLIhRZxQOedqArIk/Sb2SzQYuxN44IDRt+3ZcDqsPppoKcxSyd1Ny
 2tpvjYJXlfKmOYLhTWs8nwlAlSHX/c/jz/ywwf7eSvGknToo1Y0VpRtoxMaKW1nvH0OeCSVJ
 itfRP7YbiRVc2aNqWPCSgtqHAuVraBRbAFLKh9d2rKFB3BmynTUpc1BQLJP8+D5oNyb8Ts4x
 Xd3iV/uD8JLGJfYZIR7oGWFLP4uZ3tkneDfYzsFNBFp+A0oBEAC9ynZI9LU+uJkMeEJeJyQ/
 8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd8xD57ue0eB47bcJv
 VqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPpI4gfUbVEIEQuqdqQyO4GAe+M
 kD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalql1/iSyv1WYeC1OAs+2BLOAT2NEggSiVO
 txEfgewsQtCWi8H1SoirakIfo45Hz0tk/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJ
 riwoaRIS8N2C8/nEM53jb1sH0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcN
 fRAIUrNlatj9TxwivQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6
 dCxN0GNAORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
 rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog2LNtcyCj
 kTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZAgrrnNz0iZG2DVx46
 x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJELKItV//nCLBwNIP/AiIHE8b
 oIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwjjVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGj
 gn0TPtsGzelyQHipaUzEyrsceUGWYoKXYyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8fr
 RHnJdBcjf112PzQSdKC6kqU0Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2
 E0rW4tBtDAn2HkT9uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHM
 OBvy3EhzfAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
 Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVssZ/rYZ9+5
 1yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aWemLLszcYz/u3XnbO
 vUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPthZlDnTnOT+C+OTsh8+m5tos8
 HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E
 +MYSfkEjBz0E8CLOcAw7JIwAaeBT
In-Reply-To: <9e10434c1e5ff6edb53b9efc65485247ad450f0c.1750686195.git-series.marmarek@invisiblethingslab.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------WeV2ZwFqccgT6tPxvoI3t0V8"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------WeV2ZwFqccgT6tPxvoI3t0V8
Content-Type: multipart/mixed; boundary="------------TEV0uS6ZTjX2hMLUFbFVNXXI";
 protected-headers="v1"
From: Demi Marie Obenour 
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , xen-devel@lists.xenproject.org
Cc: Doug Goldstein ,
 Stefano Stabellini 
Message-ID: 
Subject: Re: [PATCH v1 6/6] [DO NOT MERGE] CI: example how to use ssh to
 extract logs
References: 
 <9e10434c1e5ff6edb53b9efc65485247ad450f0c.1750686195.git-series.marmarek@invisiblethingslab.com>
In-Reply-To: <9e10434c1e5ff6edb53b9efc65485247ad450f0c.1750686195.git-series.marmarek@invisiblethingslab.com>
Autocrypt-Gossip: addr=marmarek@invisiblethingslab.com; keydata=
 xsBNBE5j9EwBCACbYHjxDrxFAY3n1x9KBFvjzkG1qFSTVBnH4vpD/5Na4sZq4uDDMUCjivrm
 MzbWYaivYj96BygdOiw7PWxYrhuW0b2WYOeGudZyApgFz42g458s78EciuhgfuWBlxr8dOEN
 /9ueVFHcvtZmDbHhMVPcQ0O7gwh0JmwkOsf7P7WAfYXsQlhO/EBRrNXR0Je+GEpYADhRktxX
 h1d3Iz+oKYuwHioLX8ovoAT4+peOuecWUSpUWebpDbTR5i7NRP3PIblB4KzWJa2kh/f3mx4v
 SRGnHn+BfX42xSe0X7Ktl4Xf+KNq9Wkcjk2CZP57hV2v4pO0ZUOXD7IhlZtnfNj67WjdABEB
 AAHNPU1hcmVrIE1hcmN6eWtvd3NraS1Hw7NyZWNraSA8bWFybWFyZWtAaW52aXNpYmxldGhp
 bmdzbGFiLmNvbT7CwHoEEwEIACQCGwMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AFAll+l7cC
 GQEACgkQ24/THMrX1yw6kAgAiKiUhzAPXZj5ndqiQDl8u8PUK34SupLzYNMJOCBw5Wh+CPHe
 XYlQUwfULWxmzjiWCzzWDx2X/ONsYdRGKDKMqG5srOSWe1IYXv00MEutGsK+m/hmC5mqi/97
 DVNZ1VtKj5WW79IsI0/7ueHsQYNNrXyOfZvKsRE8VIUJ0tNfLFDFlNpq9jONuF+GviMWxrA5
 FoVaGmjh63xC0fOQYqhP2v8dbYS4B6bO5NZKI2cTHb9Li2iY0e7wIoNgvqgtR3Iv2U2Ry0yL
 D3mNQhwyxcWChexlymjfqLEZwKqaIOo57HOpt7OA+bMg6MvkdUTjNWf2GE6fqCcALjcToJ3L
 NDc1KM7ATQROY/RMAQgAtRWgUZ5mOy+c/qzmiVnxqDkiOJjmnIh3Pn+OqCtjcrTyPI9eVc06
 uH30Jkco0soLiG/UgwVw4XwBlm95j9n6TSUms4mPBh1YiR1hBjsjYwn8zp/Ue9xWk1N6E14H
 aj55GxmS2H3YIlOXfQLr0X3RHsmKixTOKyisrYlJu71FmettDFV7CgMXy1Bc1LbAE08asvAS
 ShHFdRiRRtkuVHvY/Ebq9L54kOxtlI6ahrflMcT0YCMON5oe4GgQRh3p2uy+d/LS2bgRcQST
 IebErj8x0lM271f97GvxV/ypHo7XVIDI5FX1u31Agzx3HQr035GHt4HV4/GVCz+V4xt4BonB
 tQARAQABwsBfBBgBAgAJBQJOY/RMAhsMAAoJENuP0xzK19cs5MgH/jWLXil2Ud4TdtWnBxc+
 2/QZZk2JCssc1PgWNzvH5wH7U+8lGSlUK8ZMOqrrF8C5rX0+xEn7deSrsZChIOnUFo8rhCZK
 y/mBV+FhkMj24FZZ0n8w3eF4KF2t68Pt+AvMjxQHwxAMdf3QftgQhD0qYkt/28eedUQ+jwz6
 kipc4qUQmqTEViQRPa3WAnKgNDQUDUwNruzthfGvHUjllf7zbPI8gkbARM0KlTkLikc9u+Ni
 VMbJTiGPB7YHyw2MIPq1n+mhSPAyXE6CVBnYkonQ7P3SLZssxC3PIarV+DTU68umQB3pfrfF
 7hMcAY5csWrK9/x/Zz4RUfgN6Q3HLrSp9UQ=

--------------TEV0uS6ZTjX2hMLUFbFVNXXI
Content-Type: multipart/mixed; boundary="------------8rbXiEl40Om1Jovt0eXEYfVB"

--------------8rbXiEl40Om1Jovt0eXEYfVB
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 6/23/25 09:47, Marek Marczykowski-G=C3=B3recki wrote:
> ---
>  automation/scripts/qubes-x86-64.sh | 2 ++
>  1 file changed, 2 insertions(+)
>=20
> diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qu=
bes-x86-64.sh
> index cf040a29856b..944d0c6d383f 100755
> --- a/automation/scripts/qubes-x86-64.sh
> +++ b/automation/scripts/qubes-x86-64.sh
> @@ -292,6 +292,8 @@ export TEST_LOG=3D"smoke.serial"
>  export TEST_TIMEOUT=3D"$timeout"
>  ./automation/scripts/console.exp | sed 's/\r\+$//'
>  TEST_RESULT=3D$?
> +ssh -o StrictHostKeyChecking=3Dno root@$SUT_ADDR xl dmesg || :
> +ssh -o StrictHostKeyChecking=3Dno root@$SUT_ADDR dmesg || :
> =20
>  if [ -n "$retrieve_xml" ]; then
>      nc -w 10 "$SUT_ADDR" 8080 > tests-junit.xml 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 18:30:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022658.1398484 (Exim 4.92)
	(envelope-from )
	id 1uTlvw-0001G2-3B; Mon, 23 Jun 2025 18:30:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022658.1398484; Mon, 23 Jun 2025 18:30: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 1uTlvw-0001Fv-0Q; Mon, 23 Jun 2025 18:30:20 +0000
Received: by outflank-mailman (input) for mailman id 1022658;
 Mon, 23 Jun 2025 18:30: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 1uTlvu-0001Fe-Bj
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 18:30:18 +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 1b2ea087-5060-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 20:30:16 +0200 (CEST)
Received: from phl-compute-04.internal (phl-compute-04.phl.internal
 [10.202.2.44])
 by mailfhigh.phl.internal (Postfix) with ESMTP id A999011400AE;
 Mon, 23 Jun 2025 14:30:14 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-04.internal (MEProxy); Mon, 23 Jun 2025 14:30:14 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 23 Jun 2025 14:30:12 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1b2ea087-5060-11f0-a30f-13f23c93f187
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=1750703414;
	 x=1750789814; bh=E3bRoNuZGOJy/HI43AZj5Rp3HQXU2s9gtOa4Vv+hssQ=; b=
	AKq6cFI1KwafdGStPjLxqePu9cCWqUeHdmK8YTAnMsQXdMnGsDWgp2xaiXEWUBIT
	AnNBWH42mcgzeexIQ72edFZ4b5j838FXL/DoirJVyJncM1tSAYTYhRK0a3um/551
	YtobB+bNUrMJ+nxVh6v0/z5tPIa5GiDs8pDBgxjg1qbXBiwdj/QUTSFfd+9sohwb
	NWWqJtlFHgrpEDfSGLZqgTI0mhoaHZwfGMNuMzFkeFpg+TLeSx57XLMb0931kArq
	iY0dMCeuYkGCMIeBWfSQqvQpp56RTWB+QUpBYzEVYUyHVe3Khpzn5iBobDnBssGA
	eajlDee2ylRZL+Mj3CNq0Q==
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=
	1750703414; x=1750789814; bh=E3bRoNuZGOJy/HI43AZj5Rp3HQXU2s9gtOa
	4Vv+hssQ=; b=PHR2Y8IG60NR95txhZSXAawBgVE5v2lDT10G28WMcrJ/szsk6Z5
	7IRXhOeyhcgZWNf2qHqKsrRyAJIhPkmdGNnfQvVgnl3FB1r01K1P4/JemypG7PA/
	ruD6ZWT0JLmzUmHJx7nq7NccHs8aXMZJuPSC9rGQrPE8NZwTlF2hxEUXflIz2x/Y
	+y+urYrCgfOnJ0yl0zMnSMg112fiuolssi1goQo3iS6rnOZAFycSoSkxifWEEmXZ
	wTQNsLPEEB9nAugidwT6L9flqWJoqe0MlNpGnFtGyPUuAWAYudDndSGruuJAba7/
	2GnSDwpIcJiLPWdV3N/SLqk6x5jtv6p8VeQ==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgddujeejhecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghkucfo
    rghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhish
    hisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefgudelteef
    vefhfeehieetleeihfejhfeludevteetkeevtedtvdegueetfeejudenucevlhhushhtvg
    hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhn
    vhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopeegpdhmoh
    guvgepshhmthhpohhuthdprhgtphhtthhopeguvghmihhosggvnhhouhhrsehgmhgrihhl
    rdgtohhmpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojh
    gvtghtrdhorhhgpdhrtghpthhtoheptggrrhguohgvsegtrghrughovgdrtghomhdprhgt
    phhtthhopehsshhtrggsvghllhhinhhisehkvghrnhgvlhdrohhrgh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Mon, 23 Jun 2025 20:30:10 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Demi Marie Obenour 
Cc: xen-devel@lists.xenproject.org, Doug Goldstein ,
	Stefano Stabellini 
Subject: Re: [PATCH v1 6/6] [DO NOT MERGE] CI: example how to use ssh to
 extract logs
Message-ID: 
References: 
 <9e10434c1e5ff6edb53b9efc65485247ad450f0c.1750686195.git-series.marmarek@invisiblethingslab.com>
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="MDfU9KBrhBB5OY8I"
Content-Disposition: inline
In-Reply-To: 


--MDfU9KBrhBB5OY8I
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Mon, 23 Jun 2025 20:30:10 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Demi Marie Obenour 
Cc: xen-devel@lists.xenproject.org, Doug Goldstein ,
	Stefano Stabellini 
Subject: Re: [PATCH v1 6/6] [DO NOT MERGE] CI: example how to use ssh to
 extract logs

On Mon, Jun 23, 2025 at 02:28:47PM -0400, Demi Marie Obenour wrote:
> On 6/23/25 09:47, Marek Marczykowski-G=C3=B3recki wrote:
> > ---
> >  automation/scripts/qubes-x86-64.sh | 2 ++
> >  1 file changed, 2 insertions(+)
> >=20
> > diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qu=
bes-x86-64.sh
> > index cf040a29856b..944d0c6d383f 100755
> > --- a/automation/scripts/qubes-x86-64.sh
> > +++ b/automation/scripts/qubes-x86-64.sh
> > @@ -292,6 +292,8 @@ export TEST_LOG=3D"smoke.serial"
> >  export TEST_TIMEOUT=3D"$timeout"
> >  ./automation/scripts/console.exp | sed 's/\r\+$//'
> >  TEST_RESULT=3D$?
> > +ssh -o StrictHostKeyChecking=3Dno root@$SUT_ADDR xl dmesg || :
> > +ssh -o StrictHostKeyChecking=3Dno root@$SUT_ADDR dmesg || :
> > =20
> >  if [ -n "$retrieve_xml" ]; then
> >      nc -w 10 "$SUT_ADDR" 8080 > tests-junit.xml =20
> StrictHostKeyChecking=3Dno is generally a bad idea.
> Is there a better option?

It doesn't matter here. It's simply more convenient than a netcat that
is used few lines below.

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

--MDfU9KBrhBB5OY8I
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmhZnTIACgkQ24/THMrX
1yzFlQf/dDb641HgVU4oV3nHSDITRM+OfFvC/Up5L3QgaHyQAJkdkvIafcWjRFB/
i1ABKkgvNcJJRntVYNrxVZlm7mMqA2HvvuYmZfzhfVemWlRpskIuIzWQrtR1NiYz
onfTeol10CvCOa/1HaxTT5w/iJcyJKVO9SsupvS0dijF02Vr7IssVXOe/Dtd5dXB
sXghqYVeJkoFUuieKXxIdBYyDZutGl4jngWGXJ/mQTPTbjdgEwgkmB4wFA1xBn4V
PS0WuQrz09UmECDFtCGmaMiARfEeYEX3e4v2wMLwcss2Vv4tb7GWsU2+SLs5Cxv8
YOt07COGcMbYKrkT9tK2zYQh11rrfQ==
=YGTk
-----END PGP SIGNATURE-----

--MDfU9KBrhBB5OY8I--


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 18:54:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 18:54:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022673.1398494 (Exim 4.92)
	(envelope-from )
	id 1uTmIw-0004ik-TN; Mon, 23 Jun 2025 18:54:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022673.1398494; Mon, 23 Jun 2025 18:54: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 1uTmIw-0004id-Pl; Mon, 23 Jun 2025 18:54:06 +0000
Received: by outflank-mailman (input) for mailman id 1022673;
 Mon, 23 Jun 2025 18:54: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 1uTmIv-0004iX-Bg
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 18:54:05 +0000
Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com
 [2607:f8b0:4864:20::731])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6c359c8a-5063-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 20:54:00 +0200 (CEST)
Received: by mail-qk1-x731.google.com with SMTP id
 af79cd13be357-7d20451c016so300349785a.1
 for ; Mon, 23 Jun 2025 11:54:00 -0700 (PDT)
Received: from [10.138.10.6] ([89.187.178.201])
 by smtp.gmail.com with ESMTPSA id
 d75a77b69052e-4a779d4e5d5sm41755931cf.7.2025.06.23.11.53.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 11:53:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6c359c8a-5063-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750704839; x=1751309639; darn=lists.xenproject.org;
        h=in-reply-to:subject:autocrypt:from:content-language:references:cc
         :to:user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=HewC7ampC45H1vlDhUQt/vKa0GWj6w7Jso+kotaXJ30=;
        b=YSdP0oUT1NPo5qr+CbPtt2wQIKWDM6tguF1W1pKzb8noUkQ3VvGsb95Y9FQHWKuAYg
         xO3lOXkBLDtSo4udpcfJArMgEDZt4l0zgkre/Ehz6V1wXMdHGTrSCJn2qeLqo5aLyZCt
         3Mp2TUV6msp+cFOioAw1sZ+nkBzsw+yX/maON8rBXYyxJtltPjfv2SQrHRL1MhDNlNK+
         pPzbwm2aK+Ga9xjbo0vaaVrOeafqaFRyIE8KZVE1wYXtmMj+1Sc4bU3JQs98Ivnrwwck
         TDqQY/ovG07Vf1LtVdRMO+uIPezRNiq/4XxjBcp6n4L/9c1PpL+a0T5efpii+yDxGC/j
         syWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750704839; x=1751309639;
        h=in-reply-to:subject:autocrypt:from:content-language:references:cc
         :to:user-agent:mime-version:date:message-id:x-gm-message-state:from
         :to:cc:subject:date:message-id:reply-to;
        bh=HewC7ampC45H1vlDhUQt/vKa0GWj6w7Jso+kotaXJ30=;
        b=aEJ6xzrhIlNP0g9cFuoyxpBSxso53t8wsa2RhFeeLcjuVWT5n80Ir/hQA3bW32cgga
         VwmCwIhhfUInCYx5g09D22u/NN7K3Mb2dl1A/EPcvu8Er7mzzgTzt4wsEi+yJRRnO3ME
         WmtKov7hjflNPkmQrNEuO9sLP0IQg5CLX+VcThPZQzMnLTCRf+lnInASfqEKElj/LmOb
         qRa3QDNXrIR3xSOOybT1K+udkk0ItlqcyDc4WTBzL+g4OcsuGxI03h+9FS+RDCYfflfG
         P1hkJDW49lmha2g22U4NEIWpP6pkuSiMVuW9COY71TVvgGjv2XKd5exl8OYEH5traZoP
         xrIQ==
X-Forwarded-Encrypted: i=1; AJvYcCUjeWem7ycj9n4kwf2Ac8TwhacftJLFKis3J3D53NCLb0hcj39Gto8jZ+R/uFR4EtxUM2BU6EZaGUQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxfowOXVHcUuH0FtXj37X1gK1Srq6GrDYvN6Sng4JOtxnY1Gphq
	/x68zIqBA6FFgkDfFWlsA42xFhxZFuf/r3yXAYK+yEh+m26E408xAu55
X-Gm-Gg: ASbGncveIMP/7j8DISnX/2rP5uv2xHhsOaiptiATwRGng9fgKlTPcPjo9qKzXMgBJhq
	JxZN4NagolP2txOJ0w5BsHAsRy4b3JlYsRJPETEHyt8Cvmuac713yiqcE74Bf6mh3wjZCOgQayc
	ufo1wtgNEGK7+dnKVnVGJcA+wswlgM2kh55Boz2rvTnVUfvp0KjlfU3Gzfna14ti+dtBqiHLisV
	14CWCP6L2gvpzpZhC5mIAXkA4UDZ8kKPWit/LbkXYxTJK/3o2qafWqdo72VNyc4CndgC5GyL0B8
	G/uiclG1r1pTDHAFen8NxHaWdm+rL5oQO0llzzV0+X7op+7Ic+XG+Mp+rscDGCFyaQc=
X-Google-Smtp-Source: AGHT+IHoZ0yR3533qD8yA8h3J8033PoWxUXp3fif6MrbEBTKumG38XQd5r+oEA8UVuEDtGHKFnNwqQ==
X-Received: by 2002:ac8:5a06:0:b0:4a4:3766:3180 with SMTP id d75a77b69052e-4a77a296452mr209098891cf.47.1750704838836;
        Mon, 23 Jun 2025 11:53:58 -0700 (PDT)
Message-ID: 
Date: Mon, 23 Jun 2025 14:53:52 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Jan Beulich ,
 Stefano Stabellini 
Cc: jason.andryuk@amd.com, Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Andrew Cooper ,
 Anthony PERARD ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , ayankuma@amd.com,
 xen-devel@lists.xenproject.org
References: 
 <942a6178-0fe7-468e-8e45-ea255fd20680@suse.com>
Content-Language: en-US
From: Demi Marie Obenour 
Autocrypt: addr=demiobenour@gmail.com; keydata=
 xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49yB+l2nipd
 aq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYfbWpr/si88QKgyGSV
 Z7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/UorR+FaSuVwT7rqzGrTlscnT
 DlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7MMPCJwI8JpPlBedRpe9tfVyfu3euTPLPx
 wcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9Hzx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR
 6h3nBc3eyuZ+q62HS1pJ5EvUT1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl
 5FMWo8TCniHynNXsBtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2
 Bkg1b//r6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nSm9BBff0N
 m0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQABzTxEZW1pIE1hcmll
 IE9iZW5vdXIgKGxvdmVyIG9mIGNvZGluZykgPGRlbWlvYmVub3VyQGdtYWlsLmNvbT7CwXgE
 EwECACIFAlp+A0oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELKItV//nCLBhr8Q
 AK/xrb4wyi71xII2hkFBpT59ObLN+32FQT7R3lbZRjVFjc6yMUjOb1H/hJVxx+yo5gsSj5LS
 9AwggioUSrcUKldfA/PKKai2mzTlUDxTcF3vKx6iMXKA6AqwAw4B57ZEJoMM6egm57TV19kz
 PMc879NV2nc6+elaKl+/kbVeD3qvBuEwsTe2Do3HAAdrfUG/j9erwIk6gha/Hp9yZlCnPTX+
 VK+xifQqt8RtMqS5R/S8z0msJMI/ajNU03kFjOpqrYziv6OZLJ5cuKb3bZU5aoaRQRDzkFIR
 6aqtFLTohTo20QywXwRa39uFaOT/0YMpNyel0kdOszFOykTEGI2u+kja35g9TkH90kkBTG+a
 EWttIht0Hy6YFmwjcAxisSakBuHnHuMSOiyRQLu43ej2+mDWgItLZ48Mu0C3IG1seeQDjEYP
 tqvyZ6bGkf2Vj+L6wLoLLIhRZxQOedqArIk/Sb2SzQYuxN44IDRt+3ZcDqsPppoKcxSyd1Ny
 2tpvjYJXlfKmOYLhTWs8nwlAlSHX/c/jz/ywwf7eSvGknToo1Y0VpRtoxMaKW1nvH0OeCSVJ
 itfRP7YbiRVc2aNqWPCSgtqHAuVraBRbAFLKh9d2rKFB3BmynTUpc1BQLJP8+D5oNyb8Ts4x
 Xd3iV/uD8JLGJfYZIR7oGWFLP4uZ3tkneDfYzsFNBFp+A0oBEAC9ynZI9LU+uJkMeEJeJyQ/
 8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd8xD57ue0eB47bcJv
 VqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPpI4gfUbVEIEQuqdqQyO4GAe+M
 kD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalql1/iSyv1WYeC1OAs+2BLOAT2NEggSiVO
 txEfgewsQtCWi8H1SoirakIfo45Hz0tk/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJ
 riwoaRIS8N2C8/nEM53jb1sH0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcN
 fRAIUrNlatj9TxwivQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6
 dCxN0GNAORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
 rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog2LNtcyCj
 kTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZAgrrnNz0iZG2DVx46
 x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJELKItV//nCLBwNIP/AiIHE8b
 oIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwjjVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGj
 gn0TPtsGzelyQHipaUzEyrsceUGWYoKXYyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8fr
 RHnJdBcjf112PzQSdKC6kqU0Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2
 E0rW4tBtDAn2HkT9uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHM
 OBvy3EhzfAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
 Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVssZ/rYZ9+5
 1yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aWemLLszcYz/u3XnbO
 vUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPthZlDnTnOT+C+OTsh8+m5tos8
 HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E
 +MYSfkEjBz0E8CLOcAw7JIwAaeBT
Subject: Re: hardware domain and control domain separation
In-Reply-To: <942a6178-0fe7-468e-8e45-ea255fd20680@suse.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------3zFVJtC0yXjcRmxkso0gS855"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------3zFVJtC0yXjcRmxkso0gS855
Content-Type: multipart/mixed; boundary="------------PP076Jjqoyam0fN0zUwJrfuQ";
 protected-headers="v1"
From: Demi Marie Obenour 
To: Jan Beulich ,
 Stefano Stabellini 
Cc: jason.andryuk@amd.com, Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Andrew Cooper ,
 Anthony PERARD ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , ayankuma@amd.com,
 xen-devel@lists.xenproject.org
Message-ID: 
Subject: Re: hardware domain and control domain separation
References: 
 <942a6178-0fe7-468e-8e45-ea255fd20680@suse.com>
In-Reply-To: <942a6178-0fe7-468e-8e45-ea255fd20680@suse.com>

--------------PP076Jjqoyam0fN0zUwJrfuQ
Content-Type: multipart/mixed; boundary="------------hu4dHJp0aJciW0hsdjPLcjBq"

--------------hu4dHJp0aJciW0hsdjPLcjBq
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 6/23/25 11:44, Jan Beulich wrote:
> On 21.06.2025 02:41, Stefano Stabellini wrote:
>> Regarding hardware domain and control domain separation, Ayan sent to
>> xen-devel an architecture specification (a design document) that I wro=
te
>> previously about the topic. This is written as safety document so it i=
s
>> using a language and structure specific for that. However, it contains=

>> much of the explanation needed on the topic:
>>
>> https://lore.kernel.org/xen-devel/20250304183115.2509666-1-ayan.kumar.=
halder@amd.com/
>=20
> Yet even there the line between Hardware and Control is already blurred=

> imo. Take "Reboot and shutdown the platform", for example. It seems
> pretty likely that Hardware has ways to achieve that without involving
> a hypercall. You can also see that (kind of) connection in the
> hypervisor itself: The special handling of a domain shutting down is
> in hwdom_shutdown(), with the call to it keyed to is_hardware_domain()
> (as is to be expected from the function's name).
>=20
> Furthermore there it is (again) assumed that Control has full privilege=
s.
> I did mention before that I'm not convinced any domain, in a
> disaggregated setup, would need to have (nor should have) full privileg=
e.
>=20
> Also a more fundamental question I was wondering about: If Control had
> full privilege, nothing else in the system ought to be able to interfer=
e
> with it. Yet then how does that domain communicate with the outside
> world? It can't have PV or Virtio drivers after all. And even if its
> sole communication channel was a UART, Hardware would likely be able to=

> interfere.
I expect that in safety certified or fully disaggregated setups, even the=

hardware domain only gets an allowlist of devices, MMIO, and I/O ports.
If an I/O resource could be abused, it is either assigned to a Safe domai=
n
or is simply not used at all.  This is going to be very platform-specific=
=2E

If any devices assigned to Unsafe domains are not reset along with
the CPU for long enough or have persistent state that survives reset,
protection against early boot DMA attacks is needed.  This means that
the IOMMU must be on at or before DMA is possible.  It also means that
device assignment needs to be based on full PCI paths.
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
--------------hu4dHJp0aJciW0hsdjPLcjBq
Content-Type: application/pgp-keys; name="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

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

xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49y
B+l2nipdaq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYf
bWpr/si88QKgyGSVZ7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/
UorR+FaSuVwT7rqzGrTlscnTDlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7M
MPCJwI8JpPlBedRpe9tfVyfu3euTPLPxwcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9H
zx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR6h3nBc3eyuZ+q62HS1pJ5EvU
T1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl5FMWo8TCniHynNXs
BtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2Bkg1b//r
6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nS
m9BBff0Nm0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQAB
zTxEZW1pIE9iZW5vdXIgKElUTCBFbWFpbCBLZXkpIDxhdGhlbmFAaW52aXNpYmxl
dGhpbmdzbGFiLmNvbT7CwY4EEwEIADgWIQR2h02fEza6IlkHHHGyiLVf/5wiwQUC
X6YJvQIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRCyiLVf/5wiwWRhD/0Y
R+YYC5Kduv/2LBgQJIygMsFiRHbR4+tWXuTFqgrxxFSlMktZ6gQrQCWe38WnOXkB
oY6n/5lSJdfnuGd2UagZ/9dkaGMUkqt+5WshLFly4BnP7pSsWReKgMP7etRTwn3S
zk1OwFx2lzY1EnnconPLfPBc6rWG2moA6l0WX+3WNR1B1ndqpl2hPSjT2jUCBWDV
rGOUSX7r5f1WgtBeNYnEXPBCUUM51pFGESmfHIXQrqFDA7nBNiIVFDJTmQzuEqIy
Jl67pKNgooij5mKzRhFKHfjLRAH4mmWZlB9UjDStAfFBAoDFHwd1HL5VQCNQdqEc
/9lZDApqWuCPadZN+pGouqLysesIYsNxUhJ7dtWOWHl0vs7/3qkWmWun/2uOJMQh
ra2u8nA9g91FbOobWqjrDd6x3ZJoGQf4zLqjmn/P514gb697788e573WN/MpQ5XI
Fl7aM2d6/GJiq6LC9T2gSUW4rbPBiqOCeiUx7Kd/sVm41p9TOA7fEG4bYddCfDsN
xaQJH6VRK3NOuBUGeL+iQEVF5Xs6Yp+U+jwvv2M5Lel3EqAYo5xXTx4ls0xaxDCu
fudcAh8CMMqx3fguSb7Mi31WlnZpk0fDuWQVNKyDP7lYpwc4nCCGNKCj622ZSocH
AcQmX28L8pJdLYacv9pU3jPy4fHcQYvmTavTqowGnM08RGVtaSBNYXJpZSBPYmVu
b3VyIChsb3ZlciBvZiBjb2RpbmcpIDxkZW1pb2Jlbm91ckBnbWFpbC5jb20+wsF4
BBMBAgAiBQJafgNKAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCyiLVf
/5wiwYa/EACv8a2+MMou9cSCNoZBQaU+fTmyzft9hUE+0d5W2UY1RY3OsjFIzm9R
/4SVccfsqOYLEo+S0vQMIIIqFEq3FCpXXwPzyimotps05VA8U3Bd7yseojFygOgK
sAMOAee2RCaDDOnoJue01dfZMzzHPO/TVdp3OvnpWipfv5G1Xg96rwbhMLE3tg6N
xwAHa31Bv4/Xq8CJOoIWvx6fcmZQpz01/lSvsYn0KrfEbTKkuUf0vM9JrCTCP2oz
VNN5BYzqaq2M4r+jmSyeXLim922VOWqGkUEQ85BSEemqrRS06IU6NtEMsF8EWt/b
hWjk/9GDKTcnpdJHTrMxTspExBiNrvpI2t+YPU5B/dJJAUxvmhFrbSIbdB8umBZs
I3AMYrEmpAbh5x7jEjoskUC7uN3o9vpg1oCLS2ePDLtAtyBtbHnkA4xGD7ar8mem
xpH9lY/i+sC6CyyIUWcUDnnagKyJP0m9ks0GLsTeOCA0bft2XA6rD6aaCnMUsndT
ctrab42CV5XypjmC4U1rPJ8JQJUh1/3P48/8sMH+3krxpJ06KNWNFaUbaMTGiltZ
7x9DngklSYrX0T+2G4kVXNmjaljwkoLahwLla2gUWwBSyofXdqyhQdwZsp01KXNQ
UCyT/Pg+aDcm/E7OMV3d4lf7g/CSxiX2GSEe6BlhSz+Lmd7ZJ3g32M1ARGVtaSBN
YXJpZSBPYmVub3VyIChJVEwgRW1haWwgS2V5KSA8ZGVtaUBpbnZpc2libGV0aGlu
Z3NsYWIuY29tPsLBjgQTAQgAOBYhBHaHTZ8TNroiWQcccbKItV//nCLBBQJgOEV+
AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJELKItV//nCLBKwoP/1WSnFdv
SAD0g7fD0WlF+oi7ISFT7oqJnchFLOwVHK4Jg0e4hGn1ekWsF3Ha5tFLh4V/7UUu
obYJpTfBAA2CckspYBqLtKGjFxcaqjjpO1I2W/jeNELVtSYuCOZICjdNGw2Hl9yH
KRZiBkqc9u8lQcHDZKq4LIpVJj6ZQV/nxttDX90ax2No1nLLQXFbr5wb465LAPpU
lXwunYDij7xJGye+VUASQh9datye6orZYuJvNo8Tr3mAQxxkfR46LzWgxFCPEAZJ
5P56Nc0IMHdJZj0Uc9+1jxERhOGppp5jlLgYGK7faGB/jTV6LaRQ4Ad+xiqokDWp
mUOZsmA+bMbtPfYjDZBz5mlyHcIRKIFpE1l3Y8F7PhJuzzMUKkJi90CYakCV4x/a
Zs4pzk5E96c2VQx01RIEJ7fzHF7lwFdtfTS4YsLtAbQFsKayqwkGcVv2B1AHeqdo
TMX+cgDvjd1ZganGlWA8Sv9RkNSMchn1hMuTwERTyFTr2dKPnQdA1F480+jUap41
ClXgn227WkCIMrNhQGNyJsnwyzi5wS8rBVRQ3BOTMyvGM07j3axUOYaejEpg7wKi
wTPZGLGH1sz5GljD/916v5+v2xLbOo5606j9dWf5/tAhbPuqrQgWv41wuKDi+dDD
EKkODF7DHes8No+QcHTDyETMn1RYm7t0RKR4zsFNBFp+A0oBEAC9ynZI9LU+uJkM
eEJeJyQ/8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd
8xD57ue0eB47bcJvVqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPp
I4gfUbVEIEQuqdqQyO4GAe+MkD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalq
l1/iSyv1WYeC1OAs+2BLOAT2NEggSiVOtxEfgewsQtCWi8H1SoirakIfo45Hz0tk
/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJriwoaRIS8N2C8/nEM53jb1sH
0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcNfRAIUrNlatj9Txwi
vQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6dCxN0GNA
ORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog
2LNtcyCjkTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZA
grrnNz0iZG2DVx46x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJ
ELKItV//nCLBwNIP/AiIHE8boIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwj
jVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGjgn0TPtsGzelyQHipaUzEyrsceUGWYoKX
YyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8frRHnJdBcjf112PzQSdKC6kqU0
Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2E0rW4tBtDAn2HkT9
uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHMOBvy3Ehz
fAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVss
Z/rYZ9+51yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aW
emLLszcYz/u3XnbOvUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPt
hZlDnTnOT+C+OTsh8+m5tos8HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj
6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E+MYSfkEjBz0E8CLOcAw7JIwAaeBTzsFN
BGbyLVgBEACqClxh50hmBepTSVlan6EBq3OAoxhrAhWZYEwN78k+ENhK68KhqC5R
IsHzlL7QHW1gmfVBQZ63GnWiraM6wOJqFTL4ZWvRslga9u28FJ5XyK860mZLgYhK
9BzoUk4s+dat9jVUbq6LpQ1Ot5I9vrdzo2p1jtQ8h9WCIiFxSYy8s8pZ3hHh5T64
GIj1m/kY7lG3VIdUgoNiREGf/iOMjUFjwwE9ZoJ26j9p7p1U+TkKeF6wgswEB1T3
J8KCAtvmRtqJDq558IU5jhg5fgN+xHB8cgvUWulgK9FIF9oFxcuxtaf/juhHWKMO
RtL0bHfNdXoBdpUDZE+mLBUAxF6KSsRrvx6AQyJs7VjgXJDtQVWvH0PUmTrEswgb
49nNU+dLLZQAZagxqnZ9Dp5l6GqaGZCHERJcLmdY/EmMzSf5YazJ6c0vO8rdW27M
kn73qcWAplQn5mOXaqbfzWkAUPyUXppuRHfrjxTDz3GyJJVOeMmMrTxH4uCaGpOX
Z8tN6829J1roGw4oKDRUQsaBAeEDqizXMPRc+6U9vI5FXzbAsb+8lKW65G7JWHym
YPOGUt2hK4DdTA1PmVo0DxH00eWWeKxqvmGyX+Dhcg+5e191rPsMRGsDlH6KihI6
+3JIuc0y6ngdjcp6aalbuvPIGFrCRx3tnRtNc7He6cBWQoH9RPwluwARAQABwsOs
BBgBCgAgFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmbyLVgCGwICQAkQsoi1X/+c
IsHBdCAEGQEKAB0WIQSilC2pUlbVp66j3+yzNoc6synyUwUCZvItWAAKCRCzNoc6
synyU85gD/0T1QDtPhovkGwoqv4jUbEMMvpeYQf+oWgm/TjWPeLwdjl7AtY0G9Ml
ZoyGniYkoHi37Gnn/ShLT3B5vtyI58ap2+SSa8SnGftdAKRLiWFWCiAEklm9FRk8
N3hwxhmSFF1KR/AIDS4g+HIsZn7YEMubBSgLlZZ9zHl4O4vwuXlREBEW97iL/FSt
VownU2V39t7PtFvGZNk+DJH7eLO3jmNRYB0PL4JOyyda3NH/J92iwrFmjFWWmmWb
/Xz8l9DIs+Z59pRCVTTwbBEZhcUc7rVMCcIYL+q1WxBG2e6lMn15OQJ5WfiE6E0I
sGirAEDnXWx92JNGx5l+mMpdpsWhBZ5iGTtttZesibNkQfd48/eCgFi4cxJUC4PT
UQwfD9AMgzwSTGJrkI5XGy+XqxwOjL8UA0iIrtTpMh49zw46uV6kwFQCgkf32jZM
OLwLTNSzclbnA7GRd8tKwezQ/XqeK3dal2n+cOr+o+Eka7yGmGWNUqFbIe8cjj9T
JeF3mgOCmZOwMI+wIcQYRSf+e5VTMO6TNWH5BI3vqeHSt7HkYuPlHT0pGum88d4a
pWqhulH4rUhEMtirX1hYx8Q4HlUOQqLtxzmwOYWkhl1C+yPObAvUDNiHCLf9w28n
uihgEkzHt9J4VKYulyJM9fe3ENcyU6rpXD7iANQqcr87ogKXFxknZ97uEACvSucc
RbnnAgRqZ7GDzgoBerJ2zrmhLkeREZ08iz1zze1JgyW3HEwdr2UbyAuqvSADCSUU
GN0vtQHsPzWl8onRc7lOPqPDF8OO+UfN9NAfA4wl3QyChD1GXl9rwKQOkbvdlYFV
UFx9u86LNi4ssTmU8p9NtHIGpz1SYMVYNoYy9NU7EVqypGMguDCL7gJt6GUmA0sw
p+YCroXiwL2BJ7RwRqTpgQuFL1gShkA17D5jK4mDPEetq1d8kz9rQYvAR/sTKBsR
ImC3xSfn8zpWoNTTB6lnwyP5Ng1bu6esS7+SpYprFTe7ZqGZF6xhvBPf1Ldi9UAm
U2xPN1/eeWxEa2kusidmFKPmN8lcT4miiAvwGxEnY7Oww9CgZlUB+LP4dl5VPjEt
sFeAhrgxLdpVTjPRRwTd9VQF3/XYl83j5wySIQKIPXgT3sG3ngAhDhC8I8GpM36r
8WJJ3x2yVzyJUbBPO0GBhWE2xPNIfhxVoU4cGGhpFqz7dPKSTRDGq++MrFgKKGpI
ZwT3CPTSSKc7ySndEXWkOYArDIdtyxdE1p5/c3aoz4utzUU7NDHQ+vVIwlnZSMiZ
jek2IJP3SZ+COOIHCVxpUaZ4lnzWT4eDqABhMLpIzw6NmGfg+kLBJhouqz81WITr
EtJuZYM5blWncBOJCoWMnBEcTEo/viU3GgcVRw=3D=3D
=3Dx94R
-----END PGP PUBLIC KEY BLOCK-----

--------------hu4dHJp0aJciW0hsdjPLcjBq--

--------------PP076Jjqoyam0fN0zUwJrfuQ--

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

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

iQIzBAEBCAAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmhZosEACgkQszaHOrMp
8lMUZg//RcDVlLvIjnR+EVWU5xAFyYKYm1KlpKcw+TbvJN89PrXtuw+Mfozv0XSd
WElTA1jgvCAcC7qIPQFtDToi2fnqbrqQiAdJwKJ0SHnFk//JmVCx2JOI6pkrAorA
23CQY2aezpzQ33uNxUkSp88smXRob5dtOEdvmBWebwWZRQGiYLNypdsgUs2NikNb
wxeE4Zas7SDp4jBad4UniN12oN08I0Ib7dgpqt/X/yCFCDAY+pajGVYSpMc7X3Mp
Z/timJlTeovErLyw1ireagh/IpQ6/RSVoWLicS+Ul+Odf0/yOXH1fbh7/at3W7av
tOSi7lZBnEdgzCwJOohiF4qgkYRXn4t1Utei4PwBOQPxJ2FtpL7SJYhZhkp7ZqPS
730dKBUlcfb/mLruFEcm4se3oK/Y8/j4FkfO1/weoBkW2Zzwyrc9LP2gQuId8RPF
DJH8z5s3j+OYbRo3yyMqiGpOKKWDvyA7LN+yYbF14pYZoLRjdjZwBgURAPorh3UD
2WZKxH4xexoNsLH2dMMHalumYXZBnyxO/DgOVWwwygl0Afpxbi2xw1mvTysfI04r
DR41yG8uSbyIU02rpBxDt2lvzxqX9uy4/s+aqavtO+Hg11o6sqROzwFIhnDr4vC3
u7omXz7dbXp86v8bch2746vww/CtVGVkpsDt7EltKwaLITv1jNY=
=cqdN
-----END PGP SIGNATURE-----

--------------3zFVJtC0yXjcRmxkso0gS855--


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 19:28:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 19:28:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022686.1398503 (Exim 4.92)
	(envelope-from )
	id 1uTmpr-0000oE-Fb; Mon, 23 Jun 2025 19:28:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022686.1398503; Mon, 23 Jun 2025 19:28: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 1uTmpr-0000o7-Bg; Mon, 23 Jun 2025 19:28:07 +0000
Received: by outflank-mailman (input) for mailman id 1022686;
 Mon, 23 Jun 2025 19:28: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 1uTmpq-0000nz-24
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 19:28:06 +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 2e5fafb7-5068-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 21:28:04 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id E379FA50FBD;
 Mon, 23 Jun 2025 19:28:02 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id EC4F8C4CEEA;
 Mon, 23 Jun 2025 19:28:00 +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: 2e5fafb7-5068-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750706882;
	bh=yaTv82ruYVXXGw3XXS9+P0APmG9iIBnUe8I4yBZ358U=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=pO8Y/fp1AkYlAD+63/tA26Is8soRiQxZUUjdvgqOnQHywkNtgONmsxm3cyweBihdX
	 +LuWojuw1ZfnyPLKHxoCzfmxyn2NSYA7jJsLBRaslxUYBkTP46+m7Iam3SYe5jI31J
	 aqLJc5qADgZ7Mv6e01hViibAOEd2wRyblHYzVhV0df/55zi0dJLc0GTp9UGdNq0lMv
	 RCNqPnnpKgsfRPhLNHP/WxPIuGKbBrtDi2t6gFdYHKzS11sUpJIj+0EEBe3/8Lwygw
	 I2gjMPy9WubLjUeyVxZoM+XSX3bAe+AKAKc6O0uAgaUJkClFDd35Jlau+ealGe7icI
	 X0lL97QTjHZ3g==
Date: Mon, 23 Jun 2025 12:27:58 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Julien Grall 
cc: Stefano Stabellini , 
    Oleksii Moisieiev , 
    "xen-devel@lists.xenproject.org" , 
    Andrew Cooper , 
    Anthony PERARD , 
    Bertrand Marquis , 
    Jan Beulich , Juergen Gross , 
    Michal Orzel , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Volodymyr Babchuk , 
    Grygorii Strashko 
Subject: Re: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC
 multi-agent driver
In-Reply-To: 
Message-ID: 
References:  <318044ae12f13b6b297b3f5fda577a1a6cd143da.1747669845.git.oleksii_moisieiev@epam.com>  <6080ff71-2634-4269-8a63-fdafdf03f01b@epam.com>
  <769aad0a-8bee-45c6-8c5c-35f9d47ed8ae@epam.com>  
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 23 Jun 2025, Julien Grall wrote:
> Hi Stefano,
> 
> On 22/06/2025 23:15, Stefano Stabellini wrote:
> > On Thu, 19 Jun 2025, Oleksii Moisieiev wrote:
> > > On 18/06/2025 02:22, Stefano Stabellini wrote:
> > > > On Thu, 12 Jun 2025, Oleksii Moisieiev wrote:
> > > > > [1]:https://git.iliana.fyi/linux/patch/?id=d5141f37c42e0b833863f157ac4cee203b2ba3d2
> > > > Keep in mind that [0] refers specifically to access to MMIO regions. I
> > > > assume that the SCMI shared buffers are on normal memory? Regarding [1],
> > > > it makes sense if Linux is trying to support shared memory over MMIO.
> > > > 
> > > > Looking at one of your replies below, I am guessing the memory buffers
> > > > are actually in normal memory but the issue is that TF-A is mapping them
> > > > as uncacheable. Is that correct?
> > > > 
> > > > In that case, I still don't understand why a simple memcpy would not be
> > > > sufficient. Can you check?
> > > > 
> > > > If yes, then for now I would just simplify it down to memcpy. When
> > > > someone adds support for an SCMI server elsewhere we could look into
> > > > adding a more sophisticated memcpy and we can look at the details at
> > > > that point in time. Specifically, I am not convinced that memcpy_toio
> > > > and memcpy_fromio would work if the SCMI server is on a separate
> > > > non-coherent microcontroller.
> > > > 
> > > According to the TF-A implementation  SCMI memory
> > > 
> > > is mapped with the  flags: MT_DEVICE (like for  stm32mp1) or
> > > MT_NON_CACHEABLE (for rpi3)
> > > 
> > > So probably you're right. I will check with simple memcpy.
> > 
> > There is a difference between MT_DEVICE and MT_NON_CACHEABLE: as far as
> > I know MT_DEVICE requires aligned accesses while MT_NON_CACHEABLE does
> > not.
> > 
> > However, as I wrote in the other email, if I am not mistaken the current
> > implementation of memcpy might work well for us anyway. (To be
> > confirmed.)
> 
> I am not entirely sure what exactly you want to confirm. I have already
> mentioned several time that our memcpy() on arm64 is using unaligned access.
> So it can't be used for copying data to/from device memory area.

I wrote it more clearly here:
https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2506221438250.8066@ubuntu-linux-20-04-desktop/

Assuming that the address passed to memcpy is 4K aligned, then it seems
to me that our memcpy implementation is using only aligned accesses.


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 20:18:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 20:18:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022695.1398513 (Exim 4.92)
	(envelope-from )
	id 1uTncK-0007Fm-QT; Mon, 23 Jun 2025 20:18:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022695.1398513; Mon, 23 Jun 2025 20:18: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 1uTncK-0007Ff-NW; Mon, 23 Jun 2025 20:18:12 +0000
Received: by outflank-mailman (input) for mailman id 1022695;
 Mon, 23 Jun 2025 20:18: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 1uTncJ-0007FZ-95
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 20:18:11 +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 2b625aac-506f-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 22:18:04 +0200 (CEST)
Received: by mail-lf1-x12c.google.com with SMTP id
 2adb3069b0e04-54e7967cf67so4402833e87.0
 for ; Mon, 23 Jun 2025 13:18:04 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-553e41446e2sm1539738e87.32.2025.06.23.13.18.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 13:18:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2b625aac-506f-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750709884; x=1751314684; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Epfw7tQNZp8pq/U1v10JyXOvAvYpQMAD1f8ZMHoTIy4=;
        b=FkVQgZGbBvWrorRCfyEXiLDxhJYt0L2jlHskGd50SNqN9s62wWSSrwqVuMW0RJNlS4
         ve6QAzuPYnE8mtcBlgQcbRSrFgvM0pTv+q4oJ5NVgNRh0UxRs6aeuJdJUtNjzwCMrZP9
         AzKtMDejpitHQTeWgFQKnse+NwVp0+i+Gtwhg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750709884; x=1751314684;
        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=Epfw7tQNZp8pq/U1v10JyXOvAvYpQMAD1f8ZMHoTIy4=;
        b=oHqG1N/tsJZxRPvtYrEnPnZPn4TClhpXZpAFeCvuXhIeu82m5iwRcSiUuO49Xx0orm
         PiYbYfoY4XqW7FO0SWuUXek3p4DC6HFfOHEPYC+ihe3ZWxUr3uzqyfw7eBcQ19QB2QVg
         ZJSBGJlwsFvWTL/+A1jmbJI39cTPeLQVMLbhORiwF8Pu0zmAp/8ESzOMzMLqv/OcUHs2
         m1nbouHSWeQGySZ0H6/MnusxEIc2R1oJrBclFcgvNoL9Ks05uITlzO2DFH1bxqodAmzO
         7N9aHpwxKfF0Mmdm4nqD1Kchxy54x8RByn4AnHo/ELoX7Y/PvvOcHLfk0TPNwy4S3ZWL
         ueIQ==
X-Forwarded-Encrypted: i=1; AJvYcCX51+56EM6jyKb1eluLWpgQT8J4zqjfqpW8/l2PnnNaXi+jcKvSKnAc22QRK6Obo4TKTX58RChpOVM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxrGVZJw+X4Jdh53EvGwejJUA0kztICsCPO7Vb8VoiN1uXgSBBL
	yVsvHLdvxVD9zU6GcdjLigaqXoGb0PtqHkLv0hgkgR6A9rkPuEyNsI3mwOtm9TJi3H4=
X-Gm-Gg: ASbGncu3MU9Lq9RoanTqoXYPyuQ/XsMnC5GU4THOqlLwB+m0fYgQKr1uAnVXAkMVyMe
	GDiis4BUorcnSovuEZ53eXOJfWPlh4klNFI4z6bEgNl41+dugvP6mybkzcJxBLoVRZNKdq7IhsK
	2CF7mEmJ6PMBBkkaX9xNybBVyio/jk+7PvQjvHt1nR5rl9g7yN8HTjOSaOZsGekBcGmemzYHh//
	38Gf4vwNXKEOn35nHvvykI9TmGtE8e68oPEeERQFBxg/RKh0j4MqVnJBX3GyeQSkYaMZMuzDPaS
	dBSzvTKdyc+szv4RlwkD2difiJspLuAhS8Z4rH18ODS1lFVD7v+zQmDK6oNTv433JM8ZxQh5WqB
	WhBj+wLvLzQ/utUH8MtIp7Ty3LCk=
X-Google-Smtp-Source: AGHT+IF10pPXK2pZ2V5G9shULD7WrROLmjPEHd6V0buVzUM/vaIaPWqBDmHR0GOvxJEs47ozbhtZiQ==
X-Received: by 2002:a05:6512:2313:b0:553:d910:933d with SMTP id 2adb3069b0e04-553e3d10f94mr3842779e87.48.1750709884178;
        Mon, 23 Jun 2025 13:18:04 -0700 (PDT)
Message-ID: <6690e6cc-60e8-4258-af80-1c8a56e76cb1@citrix.com>
Date: Mon, 23 Jun 2025 21:18:02 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/3] x86/EFI: Fix detection of buildid
To: Jan Beulich 
Cc: Ross Lagerwall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 "Daniel P . Smith" ,
 Xen-devel 
References: <20250605111638.2869914-1-andrew.cooper3@citrix.com>
 <20250605111638.2869914-2-andrew.cooper3@citrix.com>
 <0a314400-126a-4c2a-b36c-dda61bb0b751@suse.com>
 
 <4d1f1b70-e309-453b-bae6-e066d49a417a@suse.com>
 <9200277c-aa8e-4fd9-ab6a-f9e106114f54@citrix.com>
 <6eaf2b27-969a-4326-9726-8b6e0994e006@suse.com>
 <3f9c5a18-2ea1-4e2d-80a0-773abc3598ae@citrix.com>
 
 
 <134c69c8-ccff-475c-8bf7-241ec4805754@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: <134c69c8-ccff-475c-8bf7-241ec4805754@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 16/06/2025 7:27 am, Jan Beulich wrote:
> To expand on my earlier suggestion (ab)using the "efi" global: With
> the linker script having this
>
> #ifdef EFI
>   .reloc ALIGN(4) : {
>     __base_relocs_start = .;
>     *(.reloc)
>     __base_relocs_end = .;
>   }
> #elif defined(XEN_BUILD_EFI)
>   /*
>    * Due to the way EFI support is currently implemented, these two symbols
>    * need to be defined.  Their precise values shouldn't matter (the consuming
>    * function doesn't get called), but to be on the safe side both values would
>    * better match.  Of course the need to be reachable by the relocations
>    * referencing them.
>    */
>   PROVIDE(__base_relocs_start = .);
>   PROVIDE(__base_relocs_end = .);
> #else
>   efi = .;
> #endif
>
> where only the #if applies to xen.efi, can't we (ab)use the combination of the
> other two symbols here to decide between xen.efi vs xen.gz?
> __base_relocs_{start,efi} won't possibly be equal for xen.efi, except in an
> extremely theoretical situation (and we could cover for that case by an ASSERT
> in the linker script). Pseudo code:
>
> #ifdef XEN_BUILD_EFI
>     if ( __base_relocs_start != __base_relocs_end )
>     {
>         ...
>     }
> #endif
>
> IOW that #if could simply replace the CONFIG_X86 one that's there right now.

That's horrifying.  Also you can't include efi-boot.h to get the
declarations.

But given that you are adamant that the (...) in there containing a
CodeView check is unacceptable to have, why does wrapping it in yet
another conditional make it ok?

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 20:21:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 20:21:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022702.1398524 (Exim 4.92)
	(envelope-from )
	id 1uTnfJ-0000NI-7B; Mon, 23 Jun 2025 20:21:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022702.1398524; Mon, 23 Jun 2025 20:21:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTnfJ-0000NB-4i; Mon, 23 Jun 2025 20:21:17 +0000
Received: by outflank-mailman (input) for mailman id 1022702;
 Mon, 23 Jun 2025 20:21: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 1uTnfG-0000N4-L0
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 20:21:15 +0000
Received: from mail-10629.protonmail.ch (mail-10629.protonmail.ch
 [79.135.106.29]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 93d170ab-506f-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 22:21:00 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 93d170ab-506f-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1750710057; x=1750969257;
	bh=T9inq/XSN2DWZM4Kc+bdOMNRsH/efgLHoMLXIewQ1bg=;
	h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
	 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector;
	b=SJIJR4srlOYkNfAq3iFawrD5PxXdbq3NmCTQ+4VvxrHW+7NdVhq1mHDwutrZ0tgWW
	 FseGoiCL2zHFNaMeQf9GZ4ijMVqlYqetDSRXeBksY8Fqw6qm9j6MF1RDL1KuhdIrlc
	 0NHxbkZyW20jtJt9LYcKNUEomHxnvKW+ONSMv/dl/voUz++u9RMXX4j+6biuA1Fetq
	 6vg7wNEY+F27TXFVZpSEy2blzTo4xivqRYizlfiyAZSVrWuXWsTFkrjo+YwxBqCcl7
	 MFW4cGCNE0eoIADhxlyrcNhnYwwuPebqsBKh/0FaBprdyxbd/gXMIjNJgWH3AkJBj4
	 3QpLAcZ+nLldQ==
Date: Mon, 23 Jun 2025 20:20:51 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v4] xen/console: introduce domain_console struct
Message-ID: <20250623202030.208655-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 1b2a7f7fd487e12186a1e50abb329cfbc30b4ab0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Introduce domain_console for grouping data structures used for integrating
domain's diagnostic console with Xen's console driver.

Group all pbuf-related data structures under domain_console. Rename the mov=
ed
fields to plain .buf, .idx and .lock names, since all uses of the fields ar=
e
touched.

Bump the domain console buffer size to the closest power of 2 (256) and
rename the symbol to DOMAIN_CONSOLE_BUF_SIZE.

Finally, update the domain_console allocation and initialization code.

No functional change.

Signed-off-by: Denis Mukhin 
---
Changes since v3:
- parentheses fixup in guest_console_write()
- move buf to the end of domain_console
- formatting changes
- extended comments

Link to v3: https://lore.kernel.org/all/20250623013406.174027-1-dmukhin@for=
d.com/
---
 xen/arch/arm/vpl011.c      |  2 +-
 xen/arch/x86/hvm/hvm.c     | 17 +++++++++--------
 xen/arch/x86/pv/shim.c     |  2 +-
 xen/common/domain.c        | 19 +++++++++----------
 xen/drivers/char/console.c | 21 +++++++++++----------
 xen/include/xen/sched.h    | 30 ++++++++++++++++++++----------
 6 files changed, 51 insertions(+), 40 deletions(-)

diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 2b6f2a09bca6..f4a840da10c5 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -713,7 +713,7 @@ int domain_vpl011_init(struct domain *d, struct vpl011_=
init_info *info)
     }
     else
     {
-        d->console.input_allowed =3D true;
+        d->console->input_allowed =3D true;
         vpl011->backend_in_domain =3D false;
=20
         vpl011->backend.xen =3D xzalloc(struct vpl011_xen_backend);
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 056360d5fe50..7d599eab73f2 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -559,7 +559,8 @@ void hvm_do_resume(struct vcpu *v)
 static int cf_check hvm_print_line(
     int dir, unsigned int port, unsigned int bytes, uint32_t *val)
 {
-    struct domain *cd =3D current->domain;
+    const struct domain *d =3D current->domain;
+    struct domain_console *cons =3D d->console;
     char c =3D *val;
=20
     ASSERT(bytes =3D=3D 1 && port =3D=3D XEN_HVM_DEBUGCONS_IOPORT);
@@ -571,16 +572,16 @@ static int cf_check hvm_print_line(
     if ( !is_console_printable(c) )
         return X86EMUL_OKAY;
=20
-    spin_lock(&cd->pbuf_lock);
+    spin_lock(&cons->lock);
     if ( c !=3D '\n' )
-        cd->pbuf[cd->pbuf_idx++] =3D c;
-    if ( (cd->pbuf_idx =3D=3D (DOMAIN_PBUF_SIZE - 1)) || (c =3D=3D '\n') )
+        cons->buf[cons->idx++] =3D c;
+    if ( (cons->idx =3D=3D (DOMAIN_CONSOLE_BUF_SIZE - 1)) || (c =3D=3D '\n=
') )
     {
-        cd->pbuf[cd->pbuf_idx] =3D '\0';
-        guest_printk(cd, XENLOG_G_DEBUG "%s\n", cd->pbuf);
-        cd->pbuf_idx =3D 0;
+        cons->buf[cons->idx] =3D '\0';
+        guest_printk(d, XENLOG_G_DEBUG "%s\n", cons->buf);
+        cons->idx =3D 0;
     }
-    spin_unlock(&cd->pbuf_lock);
+    spin_unlock(&cons->lock);
=20
     return X86EMUL_OKAY;
 }
diff --git a/xen/arch/x86/pv/shim.c b/xen/arch/x86/pv/shim.c
index bc2a7dd5fae5..bd29c53a2d34 100644
--- a/xen/arch/x86/pv/shim.c
+++ b/xen/arch/x86/pv/shim.c
@@ -239,7 +239,7 @@ void __init pv_shim_setup_dom(struct domain *d, l4_pgen=
try_t *l4start,
      */
     d->max_pages =3D domain_tot_pages(d);
=20
-    d->console.input_allowed =3D true;
+    d->console->input_allowed =3D true;
 }
=20
 static void write_start_info(struct domain *d)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 8c8f70347a91..5ad1ac872798 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -669,7 +669,7 @@ static void _domain_destroy(struct domain *d)
     BUG_ON(!d->is_dying);
     BUG_ON(atomic_read(&d->refcnt) !=3D DOMAIN_DESTROYED);
=20
-    xfree(d->pbuf);
+    xfree(d->console);
=20
     argo_destroy(d);
=20
@@ -835,8 +835,6 @@ struct domain *domain_create(domid_t domid,
         flags |=3D CDF_hardware;
         if ( old_hwdom )
             old_hwdom->cdf &=3D ~CDF_hardware;
-
-        d->console.input_allowed =3D true;
     }
=20
     /* Holding CDF_* internal flags. */
@@ -866,8 +864,6 @@ struct domain *domain_create(domid_t domid,
     spin_lock_init(&d->shutdown_lock);
     d->shutdown_code =3D SHUTDOWN_CODE_INVALID;
=20
-    spin_lock_init(&d->pbuf_lock);
-
     rwlock_init(&d->vnuma_rwlock);
=20
 #ifdef CONFIG_HAS_PCI
@@ -877,6 +873,14 @@ struct domain *domain_create(domid_t domid,
=20
     /* All error paths can depend on the above setup. */
=20
+    err =3D -ENOMEM;
+    d->console =3D xvzalloc(typeof(*d->console));
+    if ( !d->console )
+        goto fail;
+
+    spin_lock_init(&d->console->lock);
+    d->console->input_allowed =3D is_hardware_domain(d);
+
     /*
      * Allocate d->vcpu[] and set ->max_vcpus up early.  Various per-domai=
n
      * resources want to be sized based on max_vcpus.
@@ -959,11 +963,6 @@ struct domain *domain_create(domid_t domid,
     if ( (err =3D argo_init(d)) !=3D 0 )
         goto fail;
=20
-    err =3D -ENOMEM;
-    d->pbuf =3D xzalloc_array(char, DOMAIN_PBUF_SIZE);
-    if ( !d->pbuf )
-        goto fail;
-
     if ( (err =3D sched_init_domain(d, config->cpupool_id)) !=3D 0 )
         goto fail;
=20
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 5d3681b16aee..a894dc6dc3b2 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -524,7 +524,7 @@ struct domain *console_get_domain(void)
     if ( !d )
         return NULL;
=20
-    if ( d->console.input_allowed )
+    if ( d->console->input_allowed )
         return d;
=20
     rcu_unlock_domain(d);
@@ -567,7 +567,7 @@ static void console_switch_input(void)
         {
             rcu_unlock_domain(d);
=20
-            if ( !d->console.input_allowed )
+            if ( !d->console->input_allowed )
                 continue;
=20
             console_rx =3D next_rx;
@@ -757,6 +757,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(=
char) buffer,
         else
         {
             char *kin =3D kbuf, *kout =3D kbuf, c;
+            struct domain_console *cons =3D cd->console;
=20
             /* Strip non-printable characters */
             do
@@ -769,22 +770,22 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARA=
M(char) buffer,
             } while ( --kcount > 0 );
=20
             *kout =3D '\0';
-            spin_lock(&cd->pbuf_lock);
+            spin_lock(&cons->lock);
             kcount =3D kin - kbuf;
             if ( c !=3D '\n' &&
-                 (cd->pbuf_idx + (kout - kbuf) < (DOMAIN_PBUF_SIZE - 1)) )
+                 (cons->idx + (kout - kbuf) < (DOMAIN_CONSOLE_BUF_SIZE - 1=
)) )
             {
                 /* buffer the output until a newline */
-                memcpy(cd->pbuf + cd->pbuf_idx, kbuf, kout - kbuf);
-                cd->pbuf_idx +=3D (kout - kbuf);
+                memcpy(cons->buf + cons->idx, kbuf, kout - kbuf);
+                cons->idx +=3D kout - kbuf;
             }
             else
             {
-                cd->pbuf[cd->pbuf_idx] =3D '\0';
-                guest_printk(cd, XENLOG_G_DEBUG "%s%s\n", cd->pbuf, kbuf);
-                cd->pbuf_idx =3D 0;
+                cons->buf[cons->idx] =3D '\0';
+                guest_printk(cd, XENLOG_G_DEBUG "%s%s\n", cons->buf, kbuf)=
;
+                cons->idx =3D 0;
             }
-            spin_unlock(&cd->pbuf_lock);
+            spin_unlock(&cons->lock);
         }
=20
         guest_handle_add_offset(buffer, kcount);
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index fe53d4fab7ba..3c74dc71fe5e 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -371,6 +371,25 @@ struct evtchn_port_ops;
=20
 #define MAX_NR_IOREQ_SERVERS 8
=20
+/*
+ * Arbitrary value.
+ * The buffer is part of the dynamically-allocated data structure, using a=
n
+ * even multiple of a cache line size may help to optimize the allocation
+ * overhead.
+ */
+#define DOMAIN_CONSOLE_BUF_SIZE 256
+
+/* Domain console settings. */
+struct domain_console {
+    /* Permission to take ownership of the physical console input. */
+    bool input_allowed;
+
+    /* hvm_print_line() and guest_console_write() logging. */
+    spinlock_t lock;
+    unsigned int idx;
+    char buf[DOMAIN_CONSOLE_BUF_SIZE];
+};
+
 struct domain
 {
     domid_t          domain_id;
@@ -562,12 +581,6 @@ struct domain
     /* Control-plane tools handle for this domain. */
     xen_domain_handle_t handle;
=20
-    /* hvm_print_line() and guest_console_write() logging. */
-#define DOMAIN_PBUF_SIZE 200
-    char       *pbuf;
-    unsigned int pbuf_idx;
-    spinlock_t  pbuf_lock;
-
     /* OProfile support. */
     struct xenoprof *xenoprof;
=20
@@ -653,10 +666,7 @@ struct domain
 #endif
=20
     /* Console settings. */
-    struct {
-        /* Permission to take ownership of the physical console input. */
-        bool input_allowed;
-    } console;
+    struct domain_console *console;
 } __aligned(PAGE_SIZE);
=20
 static inline struct page_list_head *page_to_list(
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Mon Jun 23 20:39:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 20:39:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022710.1398534 (Exim 4.92)
	(envelope-from )
	id 1uTnwI-00026K-KG; Mon, 23 Jun 2025 20:38:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022710.1398534; Mon, 23 Jun 2025 20:38: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 1uTnwI-00026D-H7; Mon, 23 Jun 2025 20:38:50 +0000
Received: by outflank-mailman (input) for mailman id 1022710;
 Mon, 23 Jun 2025 20:38:48 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uTnwG-000267-RT
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 20:38:48 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uTnwF-00GOnc-2O;
 Mon, 23 Jun 2025 20:38:47 +0000
Received: from [2a02:8012:3a1:0:fd5d:2703:c772:3074]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uTnwF-00FJBZ-1R;
 Mon, 23 Jun 2025 20:38:47 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
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=vSSI8v/6cKDAw0CxA+ZkPePwOfUQY8m9Sj3nQVam7rU=; b=wJC8tXDlgvS4CcDZRJNfnw0Q6g
	Zy+Z8Ui/zIjDTUmgOkcTr4VXKLDiEjHP0bph0+kD3cmvUWYL1AvvcywjYSOisLZSUwcLyjqRQg0b6
	5/2bTK26lafbFJb4GwfSjfaFrlSnxjp8shGJlaoI6cx/ZyyrUysKUD2Mdj/puRJcIS6A=;
Message-ID: <562748f1-13f5-4e84-a761-f251c6e0296a@xen.org>
Date: Mon, 23 Jun 2025 21:38:44 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC
 multi-agent driver
Content-Language: en-GB
To: Stefano Stabellini 
Cc: Oleksii Moisieiev ,
 "xen-devel@lists.xenproject.org" ,
 Andrew Cooper ,
 Anthony PERARD ,
 Bertrand Marquis , Jan Beulich
 , Juergen Gross ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Volodymyr Babchuk ,
 Grygorii Strashko 
References: 
 <318044ae12f13b6b297b3f5fda577a1a6cd143da.1747669845.git.oleksii_moisieiev@epam.com>
 
 <6080ff71-2634-4269-8a63-fdafdf03f01b@epam.com>
 
 <769aad0a-8bee-45c6-8c5c-35f9d47ed8ae@epam.com>
 
 
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Stefano,

On 23/06/2025 20:27, Stefano Stabellini wrote:
> On Mon, 23 Jun 2025, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 22/06/2025 23:15, Stefano Stabellini wrote:
>>> On Thu, 19 Jun 2025, Oleksii Moisieiev wrote:
>>>> On 18/06/2025 02:22, Stefano Stabellini wrote:
>>>>> On Thu, 12 Jun 2025, Oleksii Moisieiev wrote:
>>>>>> [1]:https://git.iliana.fyi/linux/patch/?id=d5141f37c42e0b833863f157ac4cee203b2ba3d2
>>>>> Keep in mind that [0] refers specifically to access to MMIO regions. I
>>>>> assume that the SCMI shared buffers are on normal memory? Regarding [1],
>>>>> it makes sense if Linux is trying to support shared memory over MMIO.
>>>>>
>>>>> Looking at one of your replies below, I am guessing the memory buffers
>>>>> are actually in normal memory but the issue is that TF-A is mapping them
>>>>> as uncacheable. Is that correct?
>>>>>
>>>>> In that case, I still don't understand why a simple memcpy would not be
>>>>> sufficient. Can you check?
>>>>>
>>>>> If yes, then for now I would just simplify it down to memcpy. When
>>>>> someone adds support for an SCMI server elsewhere we could look into
>>>>> adding a more sophisticated memcpy and we can look at the details at
>>>>> that point in time. Specifically, I am not convinced that memcpy_toio
>>>>> and memcpy_fromio would work if the SCMI server is on a separate
>>>>> non-coherent microcontroller.
>>>>>
>>>> According to the TF-A implementation  SCMI memory
>>>>
>>>> is mapped with the  flags: MT_DEVICE (like for  stm32mp1) or
>>>> MT_NON_CACHEABLE (for rpi3)
>>>>
>>>> So probably you're right. I will check with simple memcpy.
>>>
>>> There is a difference between MT_DEVICE and MT_NON_CACHEABLE: as far as
>>> I know MT_DEVICE requires aligned accesses while MT_NON_CACHEABLE does
>>> not.
>>>
>>> However, as I wrote in the other email, if I am not mistaken the current
>>> implementation of memcpy might work well for us anyway. (To be
>>> confirmed.)
>>
>> I am not entirely sure what exactly you want to confirm. I have already
>> mentioned several time that our memcpy() on arm64 is using unaligned access.
>> So it can't be used for copying data to/from device memory area.
> 
> I wrote it more clearly here:
> https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2506221438250.8066@ubuntu-linux-20-04-desktop/

Ah I missed that e-mail!

> 
> Assuming that the address passed to memcpy is 4K aligned, then it seems
> to me that our memcpy implementation is using only aligned accesses.

I didn't look at the mempcy() in details. But even if what you say is 
true, it seems to be me this will be very fragile because we would assume:
  * the addresses passed are always 4KB (I could not easily confirm it)
  * the mempcy implementation will not change (I see Linux has updated 
theirs in 2020 but we never did it...).

I can't think of a compiel time check that would help to confirm any 
assumptions above will always hold true.

I also don't see what we would gain with implementing memcpy_toio() with 
mempcy(). Maybe you can remind what's your concern with that?

So right now, I feel Oleksii approach is the best.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Mon Jun 23 20:43:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 20:43:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022721.1398544 (Exim 4.92)
	(envelope-from )
	id 1uTo0S-0003lb-8K; Mon, 23 Jun 2025 20:43:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022721.1398544; Mon, 23 Jun 2025 20:43: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 1uTo0S-0003lU-4X; Mon, 23 Jun 2025 20:43:08 +0000
Received: by outflank-mailman (input) for mailman id 1022721;
 Mon, 23 Jun 2025 20:43: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 1uTo0R-0003lO-7E
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 20:43:07 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a8dfb845-5072-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 22:43:04 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 235FA4A2F7;
 Mon, 23 Jun 2025 20:43:03 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 497DBC4CEEA;
 Mon, 23 Jun 2025 20:43:01 +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: a8dfb845-5072-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750711383;
	bh=28b3mtpisUy5LBEkImrgQd0QeK6aEbksBe5GD74T3tg=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=tXrjveR7uMgB+8WBiwOHh2WWGJj7RIzEhZ5O1m9rpiBx4BzM15CNgcNQjNkQMSg4r
	 IrJkUpet0LJa15O58XD8O4tdqvGOqhGoaekLfxq7jHJpkgLv0cyra5+E0deTNIWgdI
	 T6BSCSOHJb9RrORPvC+UJp/QAgH+m2OoTLHwtMTYOuolxYMRITlwAczg1twF7+ZNkg
	 n3d7UVjmjfokQjpTFXnlQNx32AbsGIafm18skl6SlnAt6EDYECUpqmXqGsxdlDXtyG
	 rpiNP03+Fn6PWl8lnEi7tULDlWPjrfCxVplSEklSt0Im4SLiuHMDWf4vlNdjv5C3nF
	 4VlaeuEmvoSLA==
Date: Mon, 23 Jun 2025 13:42:59 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Julien Grall 
cc: Stefano Stabellini , 
    Oleksii Moisieiev , 
    "xen-devel@lists.xenproject.org" , 
    Andrew Cooper , 
    Anthony PERARD , 
    Bertrand Marquis , 
    Jan Beulich , Juergen Gross , 
    Michal Orzel , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Volodymyr Babchuk , 
    Grygorii Strashko 
Subject: Re: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC
 multi-agent driver
In-Reply-To: <562748f1-13f5-4e84-a761-f251c6e0296a@xen.org>
Message-ID: 
References:  <318044ae12f13b6b297b3f5fda577a1a6cd143da.1747669845.git.oleksii_moisieiev@epam.com>  <6080ff71-2634-4269-8a63-fdafdf03f01b@epam.com>
  <769aad0a-8bee-45c6-8c5c-35f9d47ed8ae@epam.com>  
  <562748f1-13f5-4e84-a761-f251c6e0296a@xen.org>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 23 Jun 2025, Julien Grall wrote:
> Hi Stefano,
> 
> On 23/06/2025 20:27, Stefano Stabellini wrote:
> > On Mon, 23 Jun 2025, Julien Grall wrote:
> > > Hi Stefano,
> > > 
> > > On 22/06/2025 23:15, Stefano Stabellini wrote:
> > > > On Thu, 19 Jun 2025, Oleksii Moisieiev wrote:
> > > > > On 18/06/2025 02:22, Stefano Stabellini wrote:
> > > > > > On Thu, 12 Jun 2025, Oleksii Moisieiev wrote:
> > > > > > > [1]:https://git.iliana.fyi/linux/patch/?id=d5141f37c42e0b833863f157ac4cee203b2ba3d2
> > > > > > Keep in mind that [0] refers specifically to access to MMIO regions.
> > > > > > I
> > > > > > assume that the SCMI shared buffers are on normal memory? Regarding
> > > > > > [1],
> > > > > > it makes sense if Linux is trying to support shared memory over
> > > > > > MMIO.
> > > > > > 
> > > > > > Looking at one of your replies below, I am guessing the memory
> > > > > > buffers
> > > > > > are actually in normal memory but the issue is that TF-A is mapping
> > > > > > them
> > > > > > as uncacheable. Is that correct?
> > > > > > 
> > > > > > In that case, I still don't understand why a simple memcpy would not
> > > > > > be
> > > > > > sufficient. Can you check?
> > > > > > 
> > > > > > If yes, then for now I would just simplify it down to memcpy. When
> > > > > > someone adds support for an SCMI server elsewhere we could look into
> > > > > > adding a more sophisticated memcpy and we can look at the details at
> > > > > > that point in time. Specifically, I am not convinced that
> > > > > > memcpy_toio
> > > > > > and memcpy_fromio would work if the SCMI server is on a separate
> > > > > > non-coherent microcontroller.
> > > > > > 
> > > > > According to the TF-A implementation  SCMI memory
> > > > > 
> > > > > is mapped with the  flags: MT_DEVICE (like for  stm32mp1) or
> > > > > MT_NON_CACHEABLE (for rpi3)
> > > > > 
> > > > > So probably you're right. I will check with simple memcpy.
> > > > 
> > > > There is a difference between MT_DEVICE and MT_NON_CACHEABLE: as far as
> > > > I know MT_DEVICE requires aligned accesses while MT_NON_CACHEABLE does
> > > > not.
> > > > 
> > > > However, as I wrote in the other email, if I am not mistaken the current
> > > > implementation of memcpy might work well for us anyway. (To be
> > > > confirmed.)
> > > 
> > > I am not entirely sure what exactly you want to confirm. I have already
> > > mentioned several time that our memcpy() on arm64 is using unaligned
> > > access.
> > > So it can't be used for copying data to/from device memory area.
> > 
> > I wrote it more clearly here:
> > https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2506221438250.8066@ubuntu-linux-20-04-desktop/
> 
> Ah I missed that e-mail!
> 
> > 
> > Assuming that the address passed to memcpy is 4K aligned, then it seems
> > to me that our memcpy implementation is using only aligned accesses.
> 
> I didn't look at the mempcy() in details. But even if what you say is true, it
> seems to be me this will be very fragile because we would assume:
>  * the addresses passed are always 4KB (I could not easily confirm it)
>  * the mempcy implementation will not change (I see Linux has updated theirs
> in 2020 but we never did it...).
> 
> I can't think of a compiel time check that would help to confirm any
> assumptions above will always hold true.
> 
> I also don't see what we would gain with implementing memcpy_toio() with
> mempcy(). Maybe you can remind what's your concern with that?
> 
> So right now, I feel Oleksii approach is the best.

OK fair enough :-)

I was trying to avoid introducing two functions that seemed unnecessary.
If we go with Oleksii's approach, where do you think memcpy_toio()
should be added? Oleksii added them to the scmi file, maybe we want to
add them in a more generic location?


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 20:45:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 20:45:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022728.1398553 (Exim 4.92)
	(envelope-from )
	id 1uTo2U-0004JV-J3; Mon, 23 Jun 2025 20:45:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022728.1398553; Mon, 23 Jun 2025 20:45:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTo2U-0004JO-GT; Mon, 23 Jun 2025 20:45:14 +0000
Received: by outflank-mailman (input) for mailman id 1022728;
 Mon, 23 Jun 2025 20:45: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 1uTo2T-0004JI-J5
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 20:45:13 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f50d6e3c-5072-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 22:45:12 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 5B1CC4A5D9;
 Mon, 23 Jun 2025 20:45:11 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 812CEC4CEED;
 Mon, 23 Jun 2025 20:45: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: f50d6e3c-5072-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750711511;
	bh=RDPZHFICfod1F+Yjy8WvWC56PpTydfZoTb2k1h3xG0w=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=t9hjHXf1jnYL6B6gFtPuyzY8v9TnwUgiOucuvTh3ci3sHQRp0VVAuQ3+ERQbx8HC/
	 9qCjAj5a5ILsOO7FL+WSFf8xZeWL3a9140dOX5xBMV75erKt0z0k1HTCgZpslQ2ZmH
	 NVdsqE2GQ/d4rqEip/lmb0/WyvAXIsbGo4DlkG16mggEyGBDfRCbvtUW0lDc2w6Dhm
	 CQjcEQ+EJvQtp/0O3cBTmtYibXyWOB1Rm31FAIWAVZSJjbUvSJ9p5gD6XUy7iIOLEK
	 ie4yIWJn15+caWeBLc9yIHHZ0eVp1xJUFWwrMsuQH38WXJqVkSpZwJk9UDC8Z0zRgd
	 nLI9ygJve2CQw==
Date: Mon, 23 Jun 2025 13:45:09 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Andrew Cooper 
cc: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , 
    xen-devel@lists.xenproject.org, 
    Stefano Stabellini , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Subject: Re: [PATCH test-artifacts v1 1/5] Add linux-6.12.34-x86_64
In-Reply-To: 
Message-ID: 
References:  <0a3e893e5fe133dc710d11a31006ba4f2c1b0cbe.1750684376.git-series.marmarek@invisiblethingslab.com>
 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-935472679-1750711511=:8066"

  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-935472679-1750711511=:8066
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Mon, 23 Jun 2025, Andrew Cooper wrote:
> On 23/06/2025 2:46 pm, Marek Marczykowski-Górecki wrote:
> > This is necessary for new Zen4 runner.
> > Do not include Argo module in this build, as it isn't compatible with
> > 6.12 yet.
> >
> > Signed-off-by: Marek Marczykowski-Górecki 
> 
> Acked-by: Andrew Cooper 

Acked-by: Stefano Stabellini 
--8323329-935472679-1750711511=:8066--


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 20:45:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 20:45:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022732.1398565 (Exim 4.92)
	(envelope-from )
	id 1uTo2t-0004jX-Rz; Mon, 23 Jun 2025 20:45:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022732.1398565; Mon, 23 Jun 2025 20: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 1uTo2t-0004jQ-NN; Mon, 23 Jun 2025 20:45:39 +0000
Received: by outflank-mailman (input) for mailman id 1022732;
 Mon, 23 Jun 2025 20:45: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 1uTo2s-0004bG-Hd
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 20:45:38 +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 03d769ec-5073-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 22:45:37 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 0A76EA51262;
 Mon, 23 Jun 2025 20:45:36 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id E8675C4CEEA;
 Mon, 23 Jun 2025 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: 03d769ec-5073-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750711535;
	bh=DUPFoBciQgT5BPaFcfzLa2hOM85X8bQ7TmXxlETZ/Eg=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=Ei23kj74VQn9zdHUuP4HxAXvtBvjt749wqUXroO5WOIMI2X2KB+A0cdAyEja0swG8
	 s1pHNlL/2qA+kojKFOxj62yhNhyFxy6GNOsENGIfW6bRh1ksVcRffIYieRyp0tk1zv
	 k97HicvMVLLBz7kU4bbUPCQZiXZHGcdbFzAxnHLySzI3A6zf7FRuuHKI/yS7VyPZJd
	 qPuDf+r/xRmow6xAgVGFhw3L/QNGnmKgl/UORg7G7dpglDcYGzBn+9/JGNN6MMYZJW
	 0S3AtL4IYT87avFYjW7UZisCT0m1xqElBaNVbeWgDKH6Ke6NauFKGorNFIA3ojXwym
	 2FNDNrq7/0FSA==
Date: Mon, 23 Jun 2025 13:45:33 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Andrew Cooper 
cc: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , 
    xen-devel@lists.xenproject.org, 
    Stefano Stabellini , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Subject: Re: [PATCH test-artifacts v1 2/5] Enable CONFIG_USB_RTL8152 in kernel
 for hw12 runner
In-Reply-To: <9cf513c5-7a16-48e7-8560-4ff0214e7836@citrix.com>
Message-ID: 
References:  <8c97ac17c41e53c15e769f28d537faa01a0b2e6a.1750684376.git-series.marmarek@invisiblethingslab.com>
 <9cf513c5-7a16-48e7-8560-4ff0214e7836@citrix.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1650126933-1750711535=:8066"

  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-1650126933-1750711535=:8066
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Mon, 23 Jun 2025, Andrew Cooper wrote:
> On 23/06/2025 2:46 pm, Marek Marczykowski-Górecki wrote:
> > It uses this USB network interface.
> >
> > Signed-off-by: Marek Marczykowski-Górecki 
> 
> Acked-by: Andrew Cooper 

Acked-by: Stefano Stabellini 
--8323329-1650126933-1750711535=:8066--


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 20:46:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 20:46:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022738.1398573 (Exim 4.92)
	(envelope-from )
	id 1uTo3H-0005EV-1A; Mon, 23 Jun 2025 20:46:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022738.1398573; Mon, 23 Jun 2025 20:46: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 1uTo3G-0005EO-Ui; Mon, 23 Jun 2025 20:46:02 +0000
Received: by outflank-mailman (input) for mailman id 1022738;
 Mon, 23 Jun 2025 20:46: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 1uTo3F-0004JI-TS
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 20:46: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 1214e229-5073-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 22:46:01 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id EF3E55C62B1;
 Mon, 23 Jun 2025 20:43:42 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6ED31C4CEEA;
 Mon, 23 Jun 2025 20:45:58 +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: 1214e229-5073-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750711559;
	bh=dzoPn6nbN1OcgVRzESyhwetwmEWU74/v/n2v3td19Gw=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=tzgZalSNH5/vYcTXE9jjFYzobirIKftObMrzzOqVZKJC6mEC2JvYd4GcdahS8elbD
	 9Hm97ZG+t6cKyvqDiDYwqdcJNJdcnS84q4ZpD7Bw2dUgjKD1mX1cjdt0T8R5XsJZ2P
	 yX8p64QAbDewg3p3poTWSDMgRo1Tc0O4Sgd2GrUzzCSrcKQ7Xm41JGpKgieq81JLd+
	 xs263wdwpttnEdc03g+mFm04hiKMSFHFbyCSQpOkAVVJLQc0yefNBLnGhTt5le1tz7
	 o/3KaF8cObjS4ZGpEtFiXrwHXS0HlRM3WstSHu0DzD5VYYxGo7sNerq4OT1TlNr6Gh
	 sXLo2xQrlOarw==
Date: Mon, 23 Jun 2025 13:45:57 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Andrew Cooper 
cc: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , 
    xen-devel@lists.xenproject.org, 
    Stefano Stabellini , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Subject: Re: [PATCH test-artifacts v1 3/5] Include git in the ARM64 build
 container too
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-1551293496-1750711559=:8066"

  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-1551293496-1750711559=:8066
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Mon, 23 Jun 2025, Andrew Cooper wrote:
> On 23/06/2025 2:46 pm, Marek Marczykowski-Górecki wrote:
> > It will be used for fetching some Linux versions.
> >
> > Signed-off-by: Marek Marczykowski-Górecki 
> 
> Acked-by: Andrew Cooper 

Acked-by: Stefano Stabellini 
--8323329-1551293496-1750711559=:8066--


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 20:51:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 20:51:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022746.1398583 (Exim 4.92)
	(envelope-from )
	id 1uTo86-0006y2-Ie; Mon, 23 Jun 2025 20:51:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022746.1398583; Mon, 23 Jun 2025 20:51:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTo86-0006xv-G8; Mon, 23 Jun 2025 20:51:02 +0000
Received: by outflank-mailman (input) for mailman id 1022746;
 Mon, 23 Jun 2025 20:51: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 1uTo85-0006xp-9Z
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 20:51:01 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org
 [2600:3c0a:e001:78e:0:1991:8:25])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c36943ba-5073-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 22:50:58 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 1996E43562;
 Mon, 23 Jun 2025 20:50:57 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 43EC8C4CEEA;
 Mon, 23 Jun 2025 20:50:56 +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: c36943ba-5073-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750711856;
	bh=2r0TtgD3LFnzLpbwy4L6qEk26dWvgzXcRvPBhGu0Rlk=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=FhkXc397HA7d1D4OiXnWRUYD4qwEoFq28yIdKv0bQL+IesvMzkdjSibsUUMIzX4CF
	 QwO5U6nhvN9CWXwHoSckPJPQ/IEpkzCnwP+gLQjnk29oNVHGxJ6L7+Cv3cAIqkQZFQ
	 nQsqe9oPq649P/JawlB7KVlnd7pM9p3Qwb+ZWwtgQts6BnfN5562J0ACPrc4nuSN65
	 azRqtlRtEV2Ji4SBmuc2pLupZ+tv6Csbm4uY+doJwsxXDwZerwqIm1QK9u0jN3KdGf
	 lMaMiKO/S/DiHbIvnf1LsBeVjaQhXg9GCL4glqaeZRHarodzHRniR0gL3+KfarKTdO
	 tQvOmRxvuVmDw==
Date: Mon, 23 Jun 2025 13:50:54 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
cc: Andrew Cooper , xen-devel@lists.xenproject.org, 
    Stefano Stabellini , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Subject: Re: [PATCH test-artifacts v1 5/5] Setup ssh access to test systems
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-1643038626-1750711856=:8066"

  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-1643038626-1750711856=:8066
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Mon, 23 Jun 2025, Marek Marczykowski-Górecki wrote:
> On Mon, Jun 23, 2025 at 02:56:00PM +0100, Andrew Cooper wrote:
> > On 23/06/2025 2:46 pm, Marek Marczykowski-Górecki wrote:
> > > For this add also bridge package, so xenbr0 can be configured with
> > > /etc/network/interfaces.
> > > This allows extracting more logs out of the test system.
> > >
> > > Signed-off-by: Marek Marczykowski-Górecki 
> > > ---
> > > This enables passwordless root login. It's okay for qubes runners, as
> > > they are isolated (even from each other). Is that okay in other places
> > > too?
> > 
> > It's potentially a problem on a corporate network.
> > 
> > Can't we have each job generate a random password an insert it via the
> > dom0-rootfs overlay?
> > 
> > Or alternatively have the runner drop a public key in
> > /root/.ssh/authorised_keys ?
> 
> That can work, yes. And is preferred to a password, as easier to do
> non-interactively.

+1
--8323329-1643038626-1750711856=:8066--


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 20:54:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 20:54:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022752.1398593 (Exim 4.92)
	(envelope-from )
	id 1uToBX-0007fd-0N; Mon, 23 Jun 2025 20:54:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022752.1398593; Mon, 23 Jun 2025 20: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 1uToBW-0007fW-UB; Mon, 23 Jun 2025 20:54:34 +0000
Received: by outflank-mailman (input) for mailman id 1022752;
 Mon, 23 Jun 2025 20:54: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 1uToBW-0007fQ-F5
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 20:54:34 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 43684e37-5074-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 22:54:33 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id CA2BE61427;
 Mon, 23 Jun 2025 20:54:31 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id DA099C4CEEA;
 Mon, 23 Jun 2025 20:54: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: 43684e37-5074-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750712071;
	bh=FmQEeAO8+7XrfV2q4N6Vt/AhnT49JbtKC2oq733aN/s=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=HhJti348302/vncd8V0MmKTuw9f08dDUXenRengvLzWMW3+jG9F3OAb7KxhI9PrWl
	 tiJMzhVx3WukDgvebiIYB/zicUgv3/dPkw6XrwAfDbZfe/T35mq1ofcKpLF7BJLc24
	 MkFQRPMiZKzwYo9oHHjCZ0o6opnYDN+Dpef847XaoRGIYEHNR+tCn9akOdwqgRfjWs
	 iXWqfscIAgUHh9gD9FtTNoajJ37Yq30gGnUq/5DbfG7lGYw9RH1NRFaQLlX+yZ1Y0b
	 alMYHINe4Sv2SEp0cOjkEeMFJgaoOZofhK8Iyqx9uS9GrHNZNJe3XvBIU8MtaUC+8j
	 2pp8Bt5AZFa+Q==
Date: Mon, 23 Jun 2025 13:54:29 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
cc: xen-devel@lists.xenproject.org, Doug Goldstein , 
    Stefano Stabellini 
Subject: Re: [PATCH v1 1/6] CI: Switch x86 tests to 6.12.34 kernel
In-Reply-To: <56c63be504a72b689591b1888970fc5d340d0649.1750686195.git-series.marmarek@invisiblethingslab.com>
Message-ID: 
References:  <56c63be504a72b689591b1888970fc5d340d0649.1750686195.git-series.marmarek@invisiblethingslab.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1647492510-1750712071=:8066"

  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-1647492510-1750712071=:8066
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Mon, 23 Jun 2025, Marek Marczykowski-Górecki wrote:
> This is necessary for the upcoming Zen4 runner.
> 
> Signed-off-by: Marek Marczykowski-Górecki 

Acked-by: Stefano Stabellini 


> ---
> Previous version posted in https://lore.kernel.org/xen-devel/cover.7da1777882774486a13e6f39ff4a2096f6b7901e.1744028549.git-series.marmarek@invisiblethingslab.com/T/#u (but actual patch didn't make it into the ML, as it contained dockerfile change...)
> ---
>  automation/gitlab-ci/test.yaml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
> index 842cecf71382..1b88ee5c3be7 100644
> --- a/automation/gitlab-ci/test.yaml
> +++ b/automation/gitlab-ci/test.yaml
> @@ -21,7 +21,7 @@
>  
>  .x86-64-test-needs: &x86-64-test-needs
>    - project: xen-project/hardware/test-artifacts
> -    job: linux-6.6.56-x86_64
> +    job: linux-6.12.34-x86_64
>      ref: master
>    - project: xen-project/hardware/test-artifacts
>      job: alpine-3.18-x86_64-rootfs
> -- 
> git-series 0.9.1
> 
--8323329-1647492510-1750712071=:8066--


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 20:57:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 20:57:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022759.1398603 (Exim 4.92)
	(envelope-from )
	id 1uToEA-0008CN-DG; Mon, 23 Jun 2025 20:57:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022759.1398603; Mon, 23 Jun 2025 20:57: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 1uToEA-0008CF-A9; Mon, 23 Jun 2025 20:57:18 +0000
Received: by outflank-mailman (input) for mailman id 1022759;
 Mon, 23 Jun 2025 20:57: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 1uToE9-0008C8-5E
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 20:57:17 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a22887b0-5074-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 22:57:12 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 4CD7661549;
 Mon, 23 Jun 2025 20:57:11 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 19603C4CEED;
 Mon, 23 Jun 2025 20:57:09 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a22887b0-5074-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750712231;
	bh=XRmvCv4E2+eRUFPw+yjBMhAhnb630wPHTMDalSv+ol8=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=Orv18A4RdReAZrWtzVBVium265dkfKE8cNyKrYSHsrbOLjhAGCcFRLQO3Nk20EhnT
	 JgMYQnPwpS/g7jsA06DQ6UivLjEsJMkKR5QnjTzTa4hVDiFI4xQmjq6S9TCRy3gET2
	 7TMVYighVXUxyON9rX4HqYDU9vTcV3ghI2CW+iSv1V3YV2p/KH9C7G43y4Iut8vZye
	 z6a5i7KpGV0OiRC/6Vj1udHmIpr65OOYLiczN8x/lk6KbNDcy8HC4mnLv9+Bba9au9
	 1O0EeBXKNLdgqeh8/4HsNIfhnekaMKpKZo7W3jah2MA3oQ2wiYl22pC+TovObBImvf
	 ID+4L/scx6EKw==
Date: Mon, 23 Jun 2025 13:57:08 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
cc: xen-devel@lists.xenproject.org, Doug Goldstein , 
    Stefano Stabellini 
Subject: Re: [PATCH v1 3/6] CI: upload tests-junit.xml as a normal artifact
 too
In-Reply-To: <84bdfa33c8382080bb78fbf3a0b46e4dfd6b9187.1750686195.git-series.marmarek@invisiblethingslab.com>
Message-ID: 
References:  <84bdfa33c8382080bb78fbf3a0b46e4dfd6b9187.1750686195.git-series.marmarek@invisiblethingslab.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1020017787-1750712230=:8066"

  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-1020017787-1750712230=:8066
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Mon, 23 Jun 2025, Marek Marczykowski-Górecki wrote:
> This allows checking the file if gitlab can't parse it for some reason.
> 
> Signed-off-by: Marek Marczykowski-Górecki 

Acked-by: Stefano Stabellini 


> ---
>  automation/gitlab-ci/test.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
> index a9d871cf72ad..dc08488e76f4 100644
> --- a/automation/gitlab-ci/test.yaml
> +++ b/automation/gitlab-ci/test.yaml
> @@ -155,6 +155,7 @@
>      paths:
>        - smoke.serial
>        - '*.log'
> +      - tests-junit.xml
>      when: always
>    rules:
>      - if: $SELECTED_JOBS_ONLY && $CI_JOB_NAME =~ $SELECTED_JOBS_ONLY
> -- 
> git-series 0.9.1
> 
--8323329-1020017787-1750712230=:8066--


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 20:58:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 20:58:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022769.1398614 (Exim 4.92)
	(envelope-from )
	id 1uToF8-0000K0-Pf; Mon, 23 Jun 2025 20:58:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022769.1398614; Mon, 23 Jun 2025 20:58:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uToF8-0000Jt-N1; Mon, 23 Jun 2025 20:58:18 +0000
Received: by outflank-mailman (input) for mailman id 1022769;
 Mon, 23 Jun 2025 20:58: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 1uToF7-0008C8-Hx
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 20:58:17 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c832c920-5074-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 22:58:16 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 26A9D6114F;
 Mon, 23 Jun 2025 20:58:15 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 45A30C4CEEA;
 Mon, 23 Jun 2025 20:58:14 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c832c920-5074-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750712294;
	bh=htdm7+A0ZLRUwUfY40C8qJbNYASLp3zRKuWhGO6Gmt8=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=RNlhDsSZCilltfjCZeW2L3NM0fRTV0aRvwC98IBzb31YJEF+7qY+q022ntkuJ1WE3
	 3DEiWjEhWLs/8kXhiNRh14Y0Nw2nWQF+92KvzxvUFVYdh6xw6G6WyJWwvEHhgVpzZD
	 3y0Z9Ov5ty2xOzb59n67V8dWbhrzExh5iCB6j4jd0E+VcFXTcqap90C0gq0OuJ2bSY
	 VqFeQxFMLTtJ+QI0OweHuVLu2VWDkZYNoA0zEHwA5wIbrw76E0a8zNpq8wDmttn03w
	 97zOycfKPPnE/ONGXqyrvv3jZ1vJi+dNF8ThFvn9rz/IJaNlcrhxZ3Ps05LI4R9XIX
	 aVxg4cc1V2MsQ==
Date: Mon, 23 Jun 2025 13:58:12 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
cc: xen-devel@lists.xenproject.org, Doug Goldstein , 
    Stefano Stabellini 
Subject: Re: [PATCH v1 5/6] CI: use Alpine's network setup
In-Reply-To: <041efab43d46d82553fb156ae7f01cd7d7ace2fe.1750686195.git-series.marmarek@invisiblethingslab.com>
Message-ID: 
References:  <041efab43d46d82553fb156ae7f01cd7d7ace2fe.1750686195.git-series.marmarek@invisiblethingslab.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-218181069-1750712294=:8066"

  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-218181069-1750712294=:8066
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Mon, 23 Jun 2025, Marek Marczykowski-Górecki wrote:
> This allows Alpine startup script to properly handle service
> dependencies - necessary for starting dropbear ssh server.
> For the latter, always take the IP address from DHCP, in addition to the
> test-local one.
> 
> Signed-off-by: Marek Marczykowski-Górecki 

Acked-by: Stefano Stabellini 


> ---
>  automation/scripts/qubes-x86-64.sh | 20 +++++++++-----------
>  1 file changed, 9 insertions(+), 11 deletions(-)
> 
> diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qubes-x86-64.sh
> index 2750d24eba17..cf040a29856b 100755
> --- a/automation/scripts/qubes-x86-64.sh
> +++ b/automation/scripts/qubes-x86-64.sh
> @@ -214,25 +214,23 @@ cat "${dom0_rootfs_parts[@]}" > binaries/dom0-rootfs.cpio.gz
>  # test-local configuration
>  mkdir -p rootfs
>  cd rootfs
> -mkdir -p boot etc/local.d root
> +mkdir -p boot etc/local.d root etc/network
>  cp -a ../automation/scripts/run-tools-tests root/
>  
> +echo "
> +auto xenbr0
> +iface xenbr0 inet dhcp
> +    bridge-ports eth0
> +    bridge-stp 0
> +    up ip a a 192.168.0.1/24 dev \$IFACE
> +" > etc/network/interfaces
> +
>  echo "#!/bin/bash
>  
>  bash /etc/init.d/xencommons start
>  
> -brctl addbr xenbr0
> -brctl addif xenbr0 eth0
> -ifconfig eth0 up
> -ifconfig xenbr0 up
> -ifconfig xenbr0 192.168.0.1
> -
>  " > etc/local.d/xen.start
>  
> -if [ -n "$retrieve_xml" ]; then
> -    echo "timeout 30s udhcpc -i xenbr0" >> etc/local.d/xen.start
> -fi
> -
>  if [ -n "$domU_check" ]; then
>      echo "
>  # get domU console content into test log
> -- 
> git-series 0.9.1
> 
--8323329-218181069-1750712294=:8066--


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 20:58:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 20:58:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022775.1398625 (Exim 4.92)
	(envelope-from )
	id 1uToFZ-0000m8-3K; Mon, 23 Jun 2025 20:58:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022775.1398625; Mon, 23 Jun 2025 20:58:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uToFY-0000m1-Up; Mon, 23 Jun 2025 20:58:44 +0000
Received: by outflank-mailman (input) for mailman id 1022775;
 Mon, 23 Jun 2025 20:58:43 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uToFX-0000bA-2j
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 20:58:43 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d7fddd25-5074-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 22:58:42 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id A245A6114F;
 Mon, 23 Jun 2025 20:58:41 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id C808CC4CEEA;
 Mon, 23 Jun 2025 20:58: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: d7fddd25-5074-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750712321;
	bh=zO5RyXJKC6tJtnyZUNUZd6Ly40jn/cN8Mwyaq460avU=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=JH5xScjifOvxpmcKgn/PnuSa/oPcdsgp9TGTxPTPIWbzVUv8ONvAXkPoJ5iHcwGi7
	 /vWUzIB7357j3RvE4bQ9M5O3uRMJiaIMFcYhVKfP1bIRB/GkN58MXxGxjvF6h/Eh5n
	 JcElSAkUVsb5vu/2qst6hTxqMuyXXgqpfzQsLYtMdeJk8FFwL0ZdsFg7jQYGzRIqNK
	 ugO7nSJnQkoZm5DaSy0MY/le9arpnVnnvFRZOAqxOH/Vij3ISBf4Q12GM6rIJZkhZT
	 t1Ar51G53XmAVjIOYTzODHPbo7XKDSDd02uFEOvF0rY08RCgCluOG74P4H6CfIBQPg
	 fcHRUmTecM82A==
Date: Mon, 23 Jun 2025 13:58:39 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
cc: xen-devel@lists.xenproject.org, Doug Goldstein , 
    Stefano Stabellini 
Subject: Re: [PATCH v1 6/6] [DO NOT MERGE] CI: example how to use ssh to
 extract logs
In-Reply-To: <9e10434c1e5ff6edb53b9efc65485247ad450f0c.1750686195.git-series.marmarek@invisiblethingslab.com>
Message-ID: 
References:  <9e10434c1e5ff6edb53b9efc65485247ad450f0c.1750686195.git-series.marmarek@invisiblethingslab.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-910698808-1750712321=:8066"

  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-910698808-1750712321=:8066
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

Nice!

On Mon, 23 Jun 2025, Marek Marczykowski-Górecki wrote:
> ---
>  automation/scripts/qubes-x86-64.sh | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qubes-x86-64.sh
> index cf040a29856b..944d0c6d383f 100755
> --- a/automation/scripts/qubes-x86-64.sh
> +++ b/automation/scripts/qubes-x86-64.sh
> @@ -292,6 +292,8 @@ export TEST_LOG="smoke.serial"
>  export TEST_TIMEOUT="$timeout"
>  ./automation/scripts/console.exp | sed 's/\r\+$//'
>  TEST_RESULT=$?
> +ssh -o StrictHostKeyChecking=no root@$SUT_ADDR xl dmesg || :
> +ssh -o StrictHostKeyChecking=no root@$SUT_ADDR dmesg || :
>  
>  if [ -n "$retrieve_xml" ]; then
>      nc -w 10 "$SUT_ADDR" 8080 > tests-junit.xml  -- 
> git-series 0.9.1
> 
--8323329-910698808-1750712321=:8066--


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 21:01:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 21:01:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022783.1398635 (Exim 4.92)
	(envelope-from )
	id 1uToHt-0002Xa-F8; Mon, 23 Jun 2025 21:01:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022783.1398635; Mon, 23 Jun 2025 21:01:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uToHt-0002XT-9c; Mon, 23 Jun 2025 21:01:09 +0000
Received: by outflank-mailman (input) for mailman id 1022783;
 Mon, 23 Jun 2025 21:01: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 1uToHr-0002Ul-Ig
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 21:01:07 +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 2d1c7044-5075-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 23:01:05 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 40BB4A511AC;
 Mon, 23 Jun 2025 21:01:04 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2C11FC4CEEA;
 Mon, 23 Jun 2025 21:01:03 +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: 2d1c7044-5075-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750712463;
	bh=TI5M1EWn92XiHs7vKyT+lgsIAD4kCP1khSAsNuRgyT4=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=M4nN/83eBeS4ibw/P60WSAbnc8fNn2GGIybaYADHG+78HwrPx6wsiPc7n8Z74V1tL
	 9bA9WNsrg6a8dEr8C/geJJq02gzyYl+tE4xr83e927pK2C4aMI47t0/qTc+v1gXZLZ
	 UM8Dh8Iw++4DJZTF4tVBXSbfi6C4MP99YRcsLNuM5FomhyoIvUrs+3wOer1qi1+d8U
	 id1jMaT1RPyxVnJzypu2rmMxQAhyqSnQa6klJlL6jBmFaDUYy+tvPBvAqYX8mVdjEm
	 P/q5QtKDt0NbBnftLoCeLM2tqqQXlp6aVsc0sz0qMdnFEMdp0lPNbOfu/S4miOclQ8
	 tCgbnt3QJ/47A==
Date: Mon, 23 Jun 2025 14:01:01 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
cc: xen-devel@lists.xenproject.org, Andrew Cooper , 
    Stefano Stabellini , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Subject: Re: [PATCH test-artifacts v1 4/5] Support building arbitrary Linux
 branch/tag/commit
In-Reply-To: <7bd5b5d88d6229e5d85396ed18ac654a6f8a59ab.1750684376.git-series.marmarek@invisiblethingslab.com>
Message-ID: 
References:  <7bd5b5d88d6229e5d85396ed18ac654a6f8a59ab.1750684376.git-series.marmarek@invisiblethingslab.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-1126707912-1750711983=:8066"
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-1126707912-1750711983=:8066
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: 8BIT
Content-ID: 

On Mon, 23 Jun 2025, Marek Marczykowski-Górecki wrote:
> If LINUX_URL is set, fetch LINUX_VERSION from there. Go with "git
> init" + "git fetch" instead of "git clone" to support any of
> branch/tag/commit.
> 
> This also defines optional linux-git-* jobs which will build the thing
> if LINUX_GIT_VERSION and LINUX_GIT_URL variables are provided for the
> pipeline.
> 
> Signed-off-by: Marek Marczykowski-Górecki 
> ---
> The script variable and job variable need to have different names, so a
> pipeline variable won't override it for all jobs. While LINUX_VERSION /
> LINUX_GIT_VERSION is IMO okay, I'm not very happy about LINUX_URL /
> LINUX_GIT_URL. Any better ideas?

I understand the usefulness of these two jobs for testing purposes (I
mean personal testing during development, not the CI-loop) and based on
that alone I would accept this.

However, I thought I would mention that for personal testing purposes
these 2 jobs don't actually need to be part of the master branch. The
person could add them to their own branch and git push.

That said, I am not opposed to having them in the tree for convenience.

I can also see you are using the two variables in your xen.git patch
series. Is that idea that it would allow for a much wider Linux versions
testing? If we are going to only test one version, this is not required.


> ---
>  .gitlab-ci.yml         | 22 ++++++++++++++++++++++
>  scripts/build-linux.sh | 18 +++++++++++++-----
>  2 files changed, 35 insertions(+), 5 deletions(-)
> 
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index ad44fb4..60af072 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -1,5 +1,9 @@
>  variables:
>    REGISTRY: registry.gitlab.com/xen-project/hardware/test-artifacts
> +  LINUX_GIT_VERSION:
> +    description: "branch/tag/commit for the linux-git jobs"
> +  LINUX_GIT_URL:
> +    description: "git url for the linux-git jobs"
>  
>  stages:
>    - build
> @@ -46,6 +50,15 @@ linux-6.6.86-arm64:
>    variables:
>      LINUX_VERSION: 6.6.86
>  
> +linux-git-arm64:
> +  extends: .arm64-artifacts
> +  script: ./scripts/build-linux.sh
> +  variables:
> +    LINUX_VERSION: $LINUX_GIT_VERSION
> +    LINUX_URL: $LINUX_GIT_URL
> +  rules:
> +  - if: $LINUX_GIT_VERSION && $LINUX_GIT_URL
> +
>  #
>  # x86_64 artifacts
>  #
> @@ -70,6 +83,15 @@ linux-6.12.34-x86_64:
>    variables:
>      LINUX_VERSION: 6.12.34
>  
> +linux-git-x86_64:
> +  extends: .x86_64-artifacts
> +  script: ./scripts/build-linux.sh
> +  variables:
> +    LINUX_VERSION: $LINUX_GIT_VERSION
> +    LINUX_URL: $LINUX_GIT_URL
> +  rules:
> +  - if: $LINUX_GIT_VERSION && $LINUX_GIT_URL
> +
>  microcode-x86:
>    extends: .x86_64-artifacts
>    script: ./scripts/x86-microcode.sh
> diff --git a/scripts/build-linux.sh b/scripts/build-linux.sh
> index cf0e744..1fc96d1 100755
> --- a/scripts/build-linux.sh
> +++ b/scripts/build-linux.sh
> @@ -12,11 +12,19 @@ COPYDIR="${WORKDIR}/binaries"
>  UNAME=$(uname -m)
>  
>  # Build Linux
> -MAJOR=${LINUX_VERSION%%.*}
> -curl -fsSLO \
> -    https://cdn.kernel.org/pub/linux/kernel/v"${MAJOR}".x/linux-"${LINUX_VERSION}".tar.xz
> -tar xf linux-"${LINUX_VERSION}".tar.xz
> -cd linux-"${LINUX_VERSION}"
> +if [[ -n "${LINUX_URL}" ]]; then
> +    mkdir linux
> +    cd linux
> +    git init
> +    git fetch --depth=1 "${LINUX_URL}" "${LINUX_VERSION}"
> +    git checkout FETCH_HEAD
> +else
> +    MAJOR=${LINUX_VERSION%%.*}
> +    curl -fsSLO \
> +        https://cdn.kernel.org/pub/linux/kernel/v"${MAJOR}".x/linux-"${LINUX_VERSION}".tar.xz
> +    tar xf linux-"${LINUX_VERSION}".tar.xz
> +    cd linux-"${LINUX_VERSION}"
> +fi
>  
>  make defconfig
>  ./scripts/config --enable BRIDGE
> -- 
> git-series 0.9.1
> 
--8323329-1126707912-1750711983=:8066--


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 21:04:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 21:04:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022793.1398645 (Exim 4.92)
	(envelope-from )
	id 1uToLQ-0003FK-S9; Mon, 23 Jun 2025 21:04:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022793.1398645; Mon, 23 Jun 2025 21: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 1uToLQ-0003FD-No; Mon, 23 Jun 2025 21:04:48 +0000
Received: by outflank-mailman (input) for mailman id 1022793;
 Mon, 23 Jun 2025 21:04: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 1uToLP-0003Cs-JA
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 21:04: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 b060f71e-5075-11f0-b894-0df219b8e170;
 Mon, 23 Jun 2025 23:04:45 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 50E5D5C60A7;
 Mon, 23 Jun 2025 21:02:27 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id DE2D3C4CEEA;
 Mon, 23 Jun 2025 21:04:42 +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: b060f71e-5075-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750712683;
	bh=rVtQ+7ddAI6kxOwHm4oEsw9E8n8kJvwJDJRS9Pya++Y=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=axzmXxkTxEpmhY2p7sUpscStRgp3siMWefptcle9wRJ+LdKwTf2vEDoRc+gNzIVt4
	 +wA8lE//Gf55pWiFfQ67vUy37k1CYFhZwufoKWePF9n0ijh0D9RGsAFv33kYUNdQg5
	 xYco4rV2l7IeUKW7i2hPHa0dhuTmP0UuL1NoJ3MUoiJFos+s7y57Uz1rsSh7HDLRx7
	 mibC07EhEJe3dGDZenc/Neqb99ghZfDuRkEVWGRrdD83HrFaEHtTV+0i8oZphv8n3z
	 yeCnYLBnH2eMXLdYawJlL55hIpb/ZZ2/S9THSiQgUH8I4xqWkZqbsI/b1MAK1uoL2g
	 cBMp4tdO4iFzA==
Date: Mon, 23 Jun 2025 14:04:36 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
cc: xen-devel@lists.xenproject.org, Doug Goldstein , 
    Stefano Stabellini 
Subject: Re: [PATCH v1 4/6] CI: make test-artifacts branch/job customizable
In-Reply-To: <7c032d51b6183888cb0fcb71662b452fd9cb5a20.1750686195.git-series.marmarek@invisiblethingslab.com>
Message-ID: 
References:  <7c032d51b6183888cb0fcb71662b452fd9cb5a20.1750686195.git-series.marmarek@invisiblethingslab.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-1045390089-1750712508=:8066"
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-1045390089-1750712508=:8066
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: 8BIT
Content-ID: 

On Mon, 23 Jun 2025, Marek Marczykowski-Górecki wrote:
> Allow choosing which artifacts branch and job to use for Linux. This
> allows running the same tests for different Linux versions, without
> duplicating a lot of yaml sections.

I just sent this reply:
https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2506231351060.8066@ubuntu-linux-20-04-desktop/

You are answering my question: the goal is to allow much wider Linux
versions testing? Because if not, I don't think there is much of a
benefit.

Do you envision a bunch of jobs in automation/gitlab-ci/test.yaml that
play with different LINUX_JOB_X86_64 / LINUX_JOB_ARM64 ? If so, we would
need the corresponding jobs in test-artifacts.


> Signed-off-by: Marek Marczykowski-Górecki 
> ---
> I have considered common LINUX_JOB and then add architecture suffix, but
> even now X86 and ARM use different jobs, so I made them separate.
> ---
>  .gitlab-ci.yml                 |  9 +++++++++
>  automation/gitlab-ci/test.yaml |  8 ++++----
>  2 files changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index 7974ac4e82bc..c1d92dc485e7 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -2,6 +2,15 @@ variables:
>    XEN_REGISTRY: registry.gitlab.com/xen-project/xen
>    SELECTED_JOBS_ONLY:
>      description: "Regex to select only some jobs, must be enclosed with /. For example /job1|job2/"
> +  LINUX_ARTIFACTS_BRANCH:
> +    description: "Branch in test-artifacts to use for Linux"
> +    value: master
> +  LINUX_JOB_X86_64:
> +    description: "Job name in test-artifacts to use for Linux x86_64"
> +    value: linux-6.12.34-x86_64
> +  LINUX_JOB_ARM64:
> +    description: "Job name in test-artifacts to use for Linux arm64"
> +    value: linux-6.6.86-arm64
>  
>  workflow:
>    name: "$CI_PIPELINE_SCHEDULE_DESCRIPTION"
> diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
> index dc08488e76f4..9fd66fb6138d 100644
> --- a/automation/gitlab-ci/test.yaml
> +++ b/automation/gitlab-ci/test.yaml
> @@ -9,8 +9,8 @@
>  
>  .arm64-test-needs: &arm64-test-needs
>    - project: xen-project/hardware/test-artifacts
> -    job: linux-6.6.86-arm64
> -    ref: master
> +    job: $LINUX_JOB_ARM64
> +    ref: $LINUX_ARTIFACTS_BRANCH
>    - project: xen-project/hardware/test-artifacts
>      job: alpine-3.18-arm64-rootfs
>      ref: master
> @@ -21,8 +21,8 @@
>  
>  .x86-64-test-needs: &x86-64-test-needs
>    - project: xen-project/hardware/test-artifacts
> -    job: linux-6.12.34-x86_64
> -    ref: master
> +    job: $LINUX_JOB_X86_64
> +    ref: $LINUX_ARTIFACTS_BRANCH
>    - project: xen-project/hardware/test-artifacts
>      job: alpine-3.18-x86_64-rootfs
>      ref: master
> -- 
> git-series 0.9.1
> 
--8323329-1045390089-1750712508=:8066--


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 21:30:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 21:30:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022803.1398653 (Exim 4.92)
	(envelope-from )
	id 1uTokB-0007Z0-PS; Mon, 23 Jun 2025 21:30:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022803.1398653; Mon, 23 Jun 2025 21:30: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 1uTokB-0007Yt-Mt; Mon, 23 Jun 2025 21:30:23 +0000
Received: by outflank-mailman (input) for mailman id 1022803;
 Mon, 23 Jun 2025 21: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 1uTokA-0007Yn-8f
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 21:30:22 +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 42b0e397-5079-11f0-a30f-13f23c93f187;
 Mon, 23 Jun 2025 23:30:19 +0200 (CEST)
Received: from phl-compute-06.internal (phl-compute-06.phl.internal
 [10.202.2.46])
 by mailfhigh.stl.internal (Postfix) with ESMTP id 4F5D57A0081;
 Mon, 23 Jun 2025 17:30:18 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-06.internal (MEProxy); Mon, 23 Jun 2025 17:30:18 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 23 Jun 2025 17:30:16 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 42b0e397-5079-11f0-a30f-13f23c93f187
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=1750714218;
	 x=1750800618; bh=ZT4Gj0OcXUjMt7e2JG9WKuEXZFrHqlaBtM4crmsHJLk=; b=
	Xyr+cEDcMiFq9nBwHruLfoiNYDlg/LfztLqpYIPTKspGI8FB2b0i5h55mUdM3cQ/
	av2UjnByhPLq8vrMGYc5hxbf3Bm+EwZHIh/bWr6iOvLdgqN74IZeKL1bIO3gxAvy
	Q+Jlqt8zPjXB9ApgLnsSiQK5CJvjLTDN2cNSBeVE7mq/tWUulyLXcZEl9m3HmAvQ
	+5TmeKEH37S2xb4mbJKU/qtLhqE23xjM6XyhRQ2yyOe5lwjtBSPsCUy/PSOD5JaF
	emkFbMUE0Y6C+Inr5F+k0+Py6ALUvkA3NAeHlPQ3NSTuHFDpY32wd61i8k+HmF+l
	Lu8XRMEqvsEgFxvIT2qUTQ==
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=
	1750714218; x=1750800618; bh=ZT4Gj0OcXUjMt7e2JG9WKuEXZFrHqlaBtM4
	crmsHJLk=; b=rEk5DHNZ2cdHlWtT/swipaJJ4WtKLkxEMKtMQYqAfIpaLYu0gH7
	XRAvMxmd0ya8nBV+VlbV1/4uq/0xeBjFL1LoGElcuTVbO8oA5FyMFzy8ALBRXNI9
	b8uvIdCDFgYiZTYA7fkI/P9XB3S8OCGXL1NZLlV1GNdEq0wPz9eYYNqVUoRQzYVE
	VHzBSI0RoHK4YR/KCvWxspLjPBnKYZ0niHPlMx+OHK1OKWyK7L+yj5Q3ijZdA4D7
	nXTvepIXtIX1fUsL0REnsw73cJJYC2g0bnea2jRcS44gyKRnBufv+WOHVUoSopgt
	HdP+4edttMqW2B3IDwIuxLbanGLG01N7qLA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgddukedutdcutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpeffhffvvefukfhfgggtuggjsehgtdorredttdejnecuhfhrohhmpeforghrvghkucfo
    rghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhish
    hisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpeefveevfffg
    heettdejhfevleegieekvdduueejfeejuedvleekieejudeludehheenucffohhmrghinh
    epkhgvrhhnvghlrdhorhhgpdhgihhtlhgrsgdrtghomhenucevlhhushhtvghrufhiiigv
    pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhisg
    hlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopeefpdhmohguvgepshhm
    thhpohhuthdprhgtphhtthhopehsshhtrggsvghllhhinhhisehkvghrnhgvlhdrohhrgh
    dprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdr
    ohhrghdprhgtphhtthhopegtrghrughovgestggrrhguohgvrdgtohhm
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Mon, 23 Jun 2025 23:30:14 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Stefano Stabellini 
Cc: xen-devel@lists.xenproject.org, Doug Goldstein 
Subject: Re: [PATCH v1 4/6] CI: make test-artifacts branch/job customizable
Message-ID: 
References: 
 <7c032d51b6183888cb0fcb71662b452fd9cb5a20.1750686195.git-series.marmarek@invisiblethingslab.com>
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="N8cwctjf6Esz6SM1"
Content-Disposition: inline
In-Reply-To: 


--N8cwctjf6Esz6SM1
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Mon, 23 Jun 2025 23:30:14 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Stefano Stabellini 
Cc: xen-devel@lists.xenproject.org, Doug Goldstein 
Subject: Re: [PATCH v1 4/6] CI: make test-artifacts branch/job customizable

On Mon, Jun 23, 2025 at 02:04:36PM -0700, Stefano Stabellini wrote:
> On Mon, 23 Jun 2025, Marek Marczykowski-G=C3=B3recki wrote:
> > Allow choosing which artifacts branch and job to use for Linux. This
> > allows running the same tests for different Linux versions, without
> > duplicating a lot of yaml sections.
>=20
> I just sent this reply:
> https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2506231351060.8066@=
ubuntu-linux-20-04-desktop/
>=20
> You are answering my question: the goal is to allow much wider Linux
> versions testing? Because if not, I don't think there is much of a
> benefit.

Yes, the goal is to get wider Linux versions testing, including some
select "staging" Linux branches, not only frozen tags.

> Do you envision a bunch of jobs in automation/gitlab-ci/test.yaml that
> play with different LINUX_JOB_X86_64 / LINUX_JOB_ARM64 ? If so, we would
> need the corresponding jobs in test-artifacts.

See the cover letter (in which I forgot to CC you...).
The idea is to have separate pipelines (via a schedule) to test
different Linux branches, and each of them would select what Linux
branch is tested using those variables. For the LINUX_JOB_* variables it
would be mostly selecting between "frozen" Linux tag (for Xen standard
pipeline) and the "arbitrary git branch" one (for different Linux
versions). And then in the test-artifacts repo it can be either by
adding more jobs (as you suggests here), or more branches (all equal to
master) - each having a pipelines with different
LINUX_GIT_VERSION/LINUX_GIT_URL. In the latter case,
LINUX_ARTIFACTS_BRANCH would select which Linux build to use (+
LINUX_JOB_* set to linux-git-*).


> > Signed-off-by: Marek Marczykowski-G=C3=B3recki 
> > ---
> > I have considered common LINUX_JOB and then add architecture suffix, but
> > even now X86 and ARM use different jobs, so I made them separate.
> > ---
> >  .gitlab-ci.yml                 |  9 +++++++++
> >  automation/gitlab-ci/test.yaml |  8 ++++----
> >  2 files changed, 13 insertions(+), 4 deletions(-)
> >=20
> > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> > index 7974ac4e82bc..c1d92dc485e7 100644
> > --- a/.gitlab-ci.yml
> > +++ b/.gitlab-ci.yml
> > @@ -2,6 +2,15 @@ variables:
> >    XEN_REGISTRY: registry.gitlab.com/xen-project/xen
> >    SELECTED_JOBS_ONLY:
> >      description: "Regex to select only some jobs, must be enclosed wit=
h /. For example /job1|job2/"
> > +  LINUX_ARTIFACTS_BRANCH:
> > +    description: "Branch in test-artifacts to use for Linux"
> > +    value: master
> > +  LINUX_JOB_X86_64:
> > +    description: "Job name in test-artifacts to use for Linux x86_64"
> > +    value: linux-6.12.34-x86_64
> > +  LINUX_JOB_ARM64:
> > +    description: "Job name in test-artifacts to use for Linux arm64"
> > +    value: linux-6.6.86-arm64
> > =20
> >  workflow:
> >    name: "$CI_PIPELINE_SCHEDULE_DESCRIPTION"
> > diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test=
=2Eyaml
> > index dc08488e76f4..9fd66fb6138d 100644
> > --- a/automation/gitlab-ci/test.yaml
> > +++ b/automation/gitlab-ci/test.yaml
> > @@ -9,8 +9,8 @@
> > =20
> >  .arm64-test-needs: &arm64-test-needs
> >    - project: xen-project/hardware/test-artifacts
> > -    job: linux-6.6.86-arm64
> > -    ref: master
> > +    job: $LINUX_JOB_ARM64
> > +    ref: $LINUX_ARTIFACTS_BRANCH
> >    - project: xen-project/hardware/test-artifacts
> >      job: alpine-3.18-arm64-rootfs
> >      ref: master
> > @@ -21,8 +21,8 @@
> > =20
> >  .x86-64-test-needs: &x86-64-test-needs
> >    - project: xen-project/hardware/test-artifacts
> > -    job: linux-6.12.34-x86_64
> > -    ref: master
> > +    job: $LINUX_JOB_X86_64
> > +    ref: $LINUX_ARTIFACTS_BRANCH
> >    - project: xen-project/hardware/test-artifacts
> >      job: alpine-3.18-x86_64-rootfs
> >      ref: master
> > --=20
> > git-series 0.9.1
> >=20


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

--N8cwctjf6Esz6SM1
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmhZx2cACgkQ24/THMrX
1yzMuAf/S+dw+6Mw6ytv0FlWYc9Kth5SCdKNJaq+MCYplK3TlV6KHa6ZyC0sDNNI
0KBSb4t6pyRR4Ieo7Kg/V0vYOV3xM3prslDpynBfIkxN7DSoAdaYYb4V/u+bidya
EzwpF4TmP761GXLSW+klxfEKha4qZV2jHzgdGoPdKm0hKGt1ctWZSgNR7YaIOXvJ
0Gv54EWd6WaR3dfPsjmHWmfVZ4OfyagC35UvnGbyCUjCXGqBQ6IHx8Mpskz1qbp0
JvpBXMYb0/8os+kQve9j+yNuLqhj99BwZGKl3QOLz1Yki+UQPulML93WjjSB8JZb
YNaWore/VUvEhgVAC9Ts6P43zAlMGQ==
=Dq3w
-----END PGP SIGNATURE-----

--N8cwctjf6Esz6SM1--


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 21:58:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 21:58:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022815.1398663 (Exim 4.92)
	(envelope-from )
	id 1uTpB5-0002OQ-1F; Mon, 23 Jun 2025 21:58:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022815.1398663; Mon, 23 Jun 2025 21:58: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 1uTpB4-0002OJ-Uw; Mon, 23 Jun 2025 21:58:10 +0000
Received: by outflank-mailman (input) for mailman id 1022815;
 Mon, 23 Jun 2025 21:58:09 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uTpB3-0002OD-Nf
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 21:58:09 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uTpB2-00GQL9-2O;
 Mon, 23 Jun 2025 21:58:08 +0000
Received: from [2a02:8012:3a1:0:fd5d:2703:c772:3074]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uTpB2-00FSDb-18;
 Mon, 23 Jun 2025 21:58: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=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=Qr2jrepojhY/uQjzxUaSl6uv1zmR++D21c/ZvinaiK0=; b=66bMVuwkbZG1v8s3MUEOgUg68t
	U9cl6TkghAdmzFhn4ALZk8kvRR3veUxeY8pQE1amABj4hCf3ULADXEW48QAPeaL6SAcIqw7AA0rxU
	0ZUDPR3bV5uRfYJ/nAq88FCZxOqEjS89XXw491Q5C/nW05uooRtxKWoQ5jud/oJhn6wQ=;
Message-ID: 
Date: Mon, 23 Jun 2025 22:58:04 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC
 multi-agent driver
Content-Language: en-GB
To: Stefano Stabellini 
Cc: Oleksii Moisieiev ,
 "xen-devel@lists.xenproject.org" ,
 Andrew Cooper ,
 Anthony PERARD ,
 Bertrand Marquis , Jan Beulich
 , Juergen Gross ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Volodymyr Babchuk ,
 Grygorii Strashko 
References: 
 <318044ae12f13b6b297b3f5fda577a1a6cd143da.1747669845.git.oleksii_moisieiev@epam.com>
 
 <6080ff71-2634-4269-8a63-fdafdf03f01b@epam.com>
 
 <769aad0a-8bee-45c6-8c5c-35f9d47ed8ae@epam.com>
 
 
 
 <562748f1-13f5-4e84-a761-f251c6e0296a@xen.org>
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Stefano,

On 23/06/2025 21:42, Stefano Stabellini wrote:
> I was trying to avoid introducing two functions that seemed unnecessary.
> If we go with Oleksii's approach, where do you think memcpy_toio()
> should be added? Oleksii added them to the scmi file, maybe we want to
> add them in a more generic location?

As this is a generic implementation, I would consider to impkement it in 
xen/lib/.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Mon Jun 23 22:20:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 22:20:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022823.1398674 (Exim 4.92)
	(envelope-from )
	id 1uTpWB-0005Jt-Jl; Mon, 23 Jun 2025 22:19:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022823.1398674; Mon, 23 Jun 2025 22:19:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTpWB-0005Jm-Gx; Mon, 23 Jun 2025 22:19:59 +0000
Received: by outflank-mailman (input) for mailman id 1022823;
 Mon, 23 Jun 2025 22:19: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 1uTpWA-0005Jf-4g
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 22:19:58 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20602.outbound.protection.outlook.com
 [2a01:111:f403:2413::602])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2f5a6484-5080-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 00:19:55 +0200 (CEST)
Received: from MW4PR04CA0057.namprd04.prod.outlook.com (2603:10b6:303:6a::32)
 by CH2PR12MB4261.namprd12.prod.outlook.com (2603:10b6:610:a9::8) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.30; Mon, 23 Jun
 2025 22:19:46 +0000
Received: from CO1PEPF000042A8.namprd03.prod.outlook.com
 (2603:10b6:303:6a:cafe::2b) by MW4PR04CA0057.outlook.office365.com
 (2603:10b6:303:6a::32) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8857.29 via Frontend Transport; Mon,
 23 Jun 2025 22:19:46 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CO1PEPF000042A8.mail.protection.outlook.com (10.167.243.37) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8880.14 via Frontend Transport; Mon, 23 Jun 2025 22:19:46 +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 Jun
 2025 17:19:44 -0500
Received: from [172.29.43.193] (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 Jun 2025 17:19:43 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2f5a6484-5080-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=cl6fjI8TSVNOZ9D7zcLCyX0VV7/tb64jJKdwFlmy74tkX+QJqlhkq7/v13IpyvuK7x+teb55tABU/jKEnOvKWAf0Mj9sG5GH6Y5EATCsvZrVQQstfoHUQt2iPkkBqDMFn8uGS97oBpMnqJUYQ9qmbUWFhjfUtIAkWX7KueTTxVRRKn43HbrPa40T0Sc/Zb9oiEldLy8ZIXRdOYmzr45MGwQ3YtL9l7F7Bz4q9iKJBLBj1G2E8tmPKEF53WBEz2tu4u+SYUcbpF/+hvVxmPReoqISMUajb9WXfV0D6HLqsaPV4yBRFYUmD1II9UnXwo68hwt5J3A3wzV0xRY2Z5FHBg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=rt0UPu+S261Zn1+GKpqfNJa+/PTYivDgXJFkd0z5YsQ=;
 b=XBR1lsyh6qQnw5cgje+UVhYy7eSRB+8ezjtnPdvNw4SFpZQuW9YEF/43y2s7LW1tkhVIQnV5Cpb2pJOshQDfTGwNcLS9Xh/rnjXeXOG81PS/nmhjYhTmbF5gie+9fyUyGNaJ/4ztOnPZcQTwQZmzn7FiV8wstrpN0P91dLIG1uT59y3JvavHKAByzPSPI0JtYH5RQ78qY/vOZlG5rmryn0q/j8lL6xamXtUxnHR3dpXje9LLseywoFyaPnxa+HMMxYveUX5zw0+5poFWvdtW+N3fzPGOUSdcXDw6alV0dzqFwGYQ7wtva2pImnzorSidTbw0uqPKbpBuTYoL6u5Qwg==
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=rt0UPu+S261Zn1+GKpqfNJa+/PTYivDgXJFkd0z5YsQ=;
 b=FW5QfYXur/8wDDPiUVN6yNTucWY757woMN5lQUlU2FIeMnzSxAoT7iDNY8TcVxycBb1UYwcL9lxyl5v1j8YpFlkOT0HSJGolIdIgZOm0QmFWLDcaWVxo91bcNZSHaJv8IwiEMLKdJoqm2evWTNkgpcGPrfhy7CB/Qhr4YNyZ3Dc=
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, 23 Jun 2025 18:17:14 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 1/7] x86: suppress ERMS for internal use when
 MISC_ENABLE.FAST_STRING is clear
To: Jan Beulich , "xen-devel@lists.xenproject.org"
	
CC: Andrew Cooper ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: 
 
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 (SATLEXMB03.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PEPF000042A8:EE_|CH2PR12MB4261:EE_
X-MS-Office365-Filtering-Correlation-Id: be7c3f6c-607f-412d-ec29-08ddb2a40f96
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?RXM1dnhHWGpsdHpHbnNtOWlvWVluTngvNHJaR1BHMWpWdkJqTnVTMW51d09i?=
 =?utf-8?B?cG4xbjExUjg5WmFDdmQ3T3daZk5IVEdNSk5XR3dFaGkrK3RXaUZ6K3Qzd21M?=
 =?utf-8?B?QVpzNFA2dSs2ejJZL0FhVXNJWkFJaE5tT0FDcEQzUjdEZTFMc1J2dzFJVWND?=
 =?utf-8?B?NXBkTXhFaWMwVFJxb1phMEptRVY4M0FwRTRreWJrWU9GbHBRaWNWMGdZU0p2?=
 =?utf-8?B?cGtJVTVOeGpmY2kzelVHcUJLUmhUT1I4Z2ZOSjJWbmhRQ0NJek5yVFowRHZw?=
 =?utf-8?B?QUgvVXlXOFJMejFKQy9vUEcvRUM1dXdmSmMyREhzSUtVWS9jWEZwV3lINjBn?=
 =?utf-8?B?ZXdaNk1YM2owRGYxSEFOWWY2Yk9JaG10VmpjTEhkRnFYYmZ2bklVRjQxcmw2?=
 =?utf-8?B?cjBDL3NjWE9QNEtWUm5xQTBqdk84dzduTklsdmZPUkpmU3V3OURUVmJ0Y2Fy?=
 =?utf-8?B?WHo2WUNZQ210ZmRYclFKMk1vS2N1UmFJeDZHZy9nb2w2QVZuTnRCM2k1TFl3?=
 =?utf-8?B?MUloWU1jb2RMQ1d2Qm1LNjBQWkpZd0MrVThxRmhMcDRqMkE0UGhnSTNGby9S?=
 =?utf-8?B?ZStaaGZ5MGl0cCsvV2xWeHlPa0R4L0pERHB2SUZLWmVoN2tGQUpTS09zRDZZ?=
 =?utf-8?B?RzNSVklKNHlYWFFhSWpkaHVBdC9Rd2pnbG9mMGh5WnkrOGdQMGxrTFJ6SmNO?=
 =?utf-8?B?d1pnS2l2SHBvM25NUDVpemhTbnZudThxeXRUdGFyQVl6RXN0VVAvTGRmdlcr?=
 =?utf-8?B?SVhGQkUvV0hPaDdmTUJnL1lJSmk2OGQwaEd0YXJkaWpJYkp3dHl4TlFMd3ly?=
 =?utf-8?B?QWR0WmlHdGE2d1hlR3l0c1RyUHRKbE9BdStpNVJYZ2VndlNRdi85c01HWWc3?=
 =?utf-8?B?Wjk2L3VJay9VL0pPWlF5Wi9mWC9BZnpIaWlsWEJESm43dVZaaGxmN00yOWxT?=
 =?utf-8?B?Sm9lMnFWWmFzbmZDR3o3Q2hTRFFrVTB2aHdpZDREVHdpdUtiV1AxbHJMMzFp?=
 =?utf-8?B?bDZGbFZxTkN5TmJzOVcvYUhESDErMnhXVUN5TG9LOEtDWFVFM0NiV2x1Vjhz?=
 =?utf-8?B?bnJodzJ6UHNPQUZKTTluKzhYdlVhVFdldzZKVHZzMGtBclZ6RkVvVTRDcnYw?=
 =?utf-8?B?NzFSM21OWEhCOUpmcmVYSXhaUUpGN29NV0xNd2kvQ1RlbTdFTzRkSHRZc0Q4?=
 =?utf-8?B?a3hlaGd4aVp6U1RuR0pWU0srRFAwREs4NUNCYlV6c1NVTEZWZktCU3J5UjJX?=
 =?utf-8?B?UkhtZHYvUUZLM2NEZ0FQS3htc0lGWkpNQ3FQUDZtQTJ6bHdreG5HeThaZndv?=
 =?utf-8?B?ZUJLN3ZKYUZ3THlwbjJ3ZE51cWhLcCtBZnFYcWNmR0pDakxDZzRRT0RRM1dM?=
 =?utf-8?B?V2hhRitDQW9EbkxEaCtsK2ZoQlZLL3lXK2QrVFcwd2VhNFBWR1ZRSmZQVEh2?=
 =?utf-8?B?M1k5ME1RWkVtcjUxZkRZNEdsU3JLZUl4M01LcVJ1eTlLbGlhRVRMTVM3ZS9C?=
 =?utf-8?B?V2dzM0pmT0I0ejlzZmJ3NTl3enRWMmZGU010b0dGUXlGbVgraU1lTnhYRVJC?=
 =?utf-8?B?NXlyQTNlMkhvcjJTS0o4YlR2UDJqakFCVk80c2lnMW0rK2lMZ1hnNGk0YWtM?=
 =?utf-8?B?ampSS0IyRHBobE5SR3RUd1FqUGJNTncrNC8xUXViME5kU2RPaldDbTBnWU9U?=
 =?utf-8?B?dGpydFJ5NGpzOHhlOWRBcjVpMllzbFByV2FlUjgwYktrOWNwWXVPZi80RXpC?=
 =?utf-8?B?eU5IdW9Uem9zdmo2VnhCdC9YQUxna3pRZktIM0hVSjl1M2VlMlBJeFA0bjc5?=
 =?utf-8?B?ZnRLSG1CZTZjdWlrbWJBTStQdDh1OWZtYW1McnRiVFRvdElLc2N6MldlMzZK?=
 =?utf-8?B?NzJVV3pSNHJ4cFBCbzQrWFUrbTVGRldBd1Y0cHRqejJkS3JrYXA3WnQ1RVZZ?=
 =?utf-8?B?R1JYZ2xRbXp3aE5pY2NiU3BwUS95UFhVNCszd1UyNHNxN1RTTWpLekQ2UXRl?=
 =?utf-8?B?Z2ZodzFUYnFpTFpCSFpUSXVBeWFXNG9mMnhIWTNFQk1kVkJ5USsyUXJTd2x5?=
 =?utf-8?Q?XJtwCu?=
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)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jun 2025 22:19:46.1066
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: be7c3f6c-607f-412d-ec29-08ddb2a40f96
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:
	CO1PEPF000042A8.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4261

On 2025-06-16 08:59, Jan Beulich wrote:
> Before we start actually adjusting behavior when ERMS is available,
> follow Linux commit 161ec53c702c ("x86, mem, intel: Initialize Enhanced
> REP MOVSB/STOSB") and zap the CPUID-derived feature flag when the MSR
> bit is clear. Don't extend the artificial clearing to guest view,
> though: Guests can take their own decision in this regard, as they can
> read (most of) MISC_ENABLE.
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Jason Andryuk 


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 22:20:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 22:20:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022829.1398683 (Exim 4.92)
	(envelope-from )
	id 1uTpX7-0006oq-Rp; Mon, 23 Jun 2025 22:20:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022829.1398683; Mon, 23 Jun 2025 22:20: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 1uTpX7-0006oj-Or; Mon, 23 Jun 2025 22:20:57 +0000
Received: by outflank-mailman (input) for mailman id 1022829;
 Mon, 23 Jun 2025 22:20: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 1uTpX6-0006WR-01
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 22:20:56 +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 540297a6-5080-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 00:20:54 +0200 (CEST)
Received: from BYAPR05CA0071.namprd05.prod.outlook.com (2603:10b6:a03:74::48)
 by CH3PR12MB7689.namprd12.prod.outlook.com (2603:10b6:610:14d::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.28; Mon, 23 Jun
 2025 22:20:51 +0000
Received: from CO1PEPF000042AB.namprd03.prod.outlook.com
 (2603:10b6:a03:74:cafe::b3) by BYAPR05CA0071.outlook.office365.com
 (2603:10b6:a03:74::48) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8880.15 via Frontend Transport; Mon,
 23 Jun 2025 22:20:50 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CO1PEPF000042AB.mail.protection.outlook.com (10.167.243.40) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8880.14 via Frontend Transport; Mon, 23 Jun 2025 22:20:50 +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, 23 Jun
 2025 17:20:49 -0500
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, 23 Jun
 2025 17:20:47 -0500
Received: from [172.29.43.193] (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 Jun 2025 17:20:47 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 540297a6-5080-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=elVzQVN2TQuq9y2Vvj2wDx6OEHA9miYe7Asn3IVnPsv7X2t7FX3KFYbupwUQb7IjBxj8+aYyhZSaAJqg9wpJp9JuanGMEhn4/63nFcgTGXsqIOxm1VX/kJc+aQARfRG1tBpq69qUCG+TyOFJhblYeFClKr0U/YqBBDKL9oaEUqzuJfuHVUzoKam0f1ubauSPurV+zZYjVSLD31J/fFnEXyCj3XsS5N/6Cm2uPyUcFA/IQVyS8K14N1INophYNWVk8QFksl93aubH1Gu5i11QvFHkINIjiqgzpG6sWLUGNuTqs5Dmp7XoboTfRec7SP8vJSFtZrC3KQSGwGFfdx8mxQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ii1fNGp6HNiLb19C5vR+Zl3rPUSVUG7ABdOEVMMEFp0=;
 b=GsZ8siyBsU9YyPq0g/gPXwZzPbuEIrxABwEMqccCTYPvG5JIFE1faueL2mHfG+myqkfjO/C2C2ID3g3rlZRuixuKOVSVfDvAC/tgLgwluEFgjQbPA5zIwBbFdh0rXfIK19ubqD/dqdsX9/yq5vvRQm5iEYrBY66AXUjrxId3+RMhUq0JZ4xExn0x8QLSWLxRfvyL5YAJYVVoaiUPi4kFOCLGBxBHavg1M1ngnoFY4F/2H9YJSADJg0KvS/CmLva4QSd9gRjC1ydjurc7VHtnmvF2E3jEdeAV09YddrtrZcE9whAr/bf/HekJczGv++DpaqnSwhQyuTQMVoDsY0gCcw==
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=ii1fNGp6HNiLb19C5vR+Zl3rPUSVUG7ABdOEVMMEFp0=;
 b=TJA9CyAnQw6d45kjiJ0hDf0WZ3MV5pAZfM7IGaSz4xzIHzemJEsty9f+qvjfm0lHfGptNuYFFqrpSxcNDq0qMUkRmLneKgPeXos5r7zRLhBf+o1CHckGZCWfD4VjZycqc/Rie5x2CM5KKLF74TGOmvz8Tu0f7w7yuK9DNUcCiwA=
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, 23 Jun 2025 18:18:18 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 2/7] x86/alternatives: serialize after (self-)modifying
 code
To: Jan Beulich , "xen-devel@lists.xenproject.org"
	
CC: Andrew Cooper ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: 
 <658802b4-1847-455d-98ad-244d97fddc5e@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <658802b4-1847-455d-98ad-244d97fddc5e@suse.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PEPF000042AB:EE_|CH3PR12MB7689:EE_
X-MS-Office365-Filtering-Correlation-Id: f165f09c-03dc-4a77-4cae-08ddb2a435f9
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|376014|82310400026|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?TmxwaGR0RENiWFhYQy9BUkZFRG56Q2ZHRU5WME1tUG5IRXd2SjVjcUJzMnZn?=
 =?utf-8?B?dllNNTBGR1M4bU90aENCLzNCQXA0cUNUVEdGYzJRMkRnNjRmWDJLbjhHbUds?=
 =?utf-8?B?RnVZLzlqWDE1L3R6ZXlhT3phQmFqSVJTanFSTkhhNExqU1BTdkJYeWZlV2hl?=
 =?utf-8?B?UUJMMytxQk1pWVdkVk5iVXBZTm1KbVhZQ2V5M0gwQlN2dm9US0hkd0J0RU9o?=
 =?utf-8?B?T3c2MXIzUiszVlR5SXYwNVZqZDF4Z1crNXU4UngvZ2ZFNWNMVng2N3E2dW9X?=
 =?utf-8?B?UFZjTU1hZzFnL0p2Q29xM1AweldkY253VDVhZnNYZXBVMFpYRlJSTS80RUxI?=
 =?utf-8?B?MVhLcGJ3YUtTNGVaSGNaSkxYSXlPMVRldmU2eFNnMlkxOGdMNk1raFBmLzdi?=
 =?utf-8?B?blUwTEloMW5kRUVkRmlPVk5FRW5ObnluZVRWQk1XdDRDM0NRdnlVdWw3Qnp5?=
 =?utf-8?B?MlRBQWVhdVNPMXFGUEdlWndpd0dRbExJTDFVUGFhbTZzMzJXaktNbEkvb3A0?=
 =?utf-8?B?MHRONWtBb0Nrc3QxZXNYMnM5QmdtUnArL1BvdzUxR0tjcWpTakVYQUJubG4z?=
 =?utf-8?B?YUZqSmNwUy9uMUFYUkoxT2tUOTdCdjZHVXFaK084b1FNMXB4RUZjaEs0QnIz?=
 =?utf-8?B?anlmczZoeDdZc1JsejZGc2hTSG1NOW1FZFBmZGgvUTFPUlBCVjdPMkQyajI3?=
 =?utf-8?B?SEhmYnptcGFWSlBrT28rUnZ2RE9mbW5rOUZOVksxeUE2b2lwemtSWkc1UVd2?=
 =?utf-8?B?V2ZzU05qMEh6eVFUbFRZS3lCUkV3WTY0aG5hYXFIUVZCd3FUcWtPTUNKSGFh?=
 =?utf-8?B?bXIvVm5IenJZVHpMU0xla09ucFd6Tkh6OWZSNjY3UTNwdmg0UHVZM1NadC9a?=
 =?utf-8?B?UlVuTTRzUjdHb1BwWU1mTmk3YWVwTDNXL3BLSWV5Y2dyK2VmUHFzZmNnbmhB?=
 =?utf-8?B?aHllQllrcXJTYXZBaDdzc1gyQUlhLzVabVAzS2d4RWRMU01aajFrMG96OFo3?=
 =?utf-8?B?MmZ1OE9CMUZYNUkrL2xmbzlsNHQvRkZxVE82U2VrRm50WXlJSTVBTUI0TkIx?=
 =?utf-8?B?dGpvN3RuT1k0UTJlb3ZxQy9SdXd4ZXFPQ1k3S2IwTTBZTXFzSHNJeTEyYkdX?=
 =?utf-8?B?MDBTMmd3Unp6UW5mV0R3RWtEM1FtY0FsOU91anFLS2pQc0NiNGlPK05lY2t0?=
 =?utf-8?B?SGFoeEtRNzJCWThHYWtLNjNPeHpCSUZPRytGSXlIb2JBNy9OV3VLUWF3bjZQ?=
 =?utf-8?B?Z2t1UGQrVmN5R1RleWU5bGNvWUREMEdjWVlidjQvaVI0V2tSZDVQNlRLQ09S?=
 =?utf-8?B?Ukc5RXZPWWxTN2xtOG0va0Z3Q2NFMHBXbzVJNVZVeVFGdnRVdkdaRmRjc0RK?=
 =?utf-8?B?NlhvTXNOeE9xbUE5OW5DOTdsbjlyUGZLMTc2S2drSXZ4enRZWFRDQUpWWFJk?=
 =?utf-8?B?MVRkWVh5d3A3NnUzaHptZ3NwelBqN2J2YytOVnF2NW1xZ3dzalRNMEFvYms3?=
 =?utf-8?B?dklLVWpQT0xGWExzQ3ZHbzM0aDJlbzFqWG9haG9qREFzQStCNUx1UDNYYVhB?=
 =?utf-8?B?STBxY1owMUhka3JGWjhuMHhOVkQ4VS94RGJoS0swRkIrSmZYdTZUbHc0dEw1?=
 =?utf-8?B?ak5yaU9DSjF1ZnhFWmdBY1IxMVhJRHJBRkpXYTZFR0wrQWlXSWlkdG14TG5Y?=
 =?utf-8?B?SEU2ZXlYdGthV1E5SEg4Q2lNemJLT0xMNjdyWEhuTFZSSWRlaldXdnhHMVVM?=
 =?utf-8?B?YmREeUY1bEpxRzB5blZsbGpmcFdwR29hYVZFamRyVVp1cnlpQ2VTQWM1SXNv?=
 =?utf-8?B?Z0Y4UXpFRzlaWFFVK2FpcUIwYkZZdHRYQll6bGFGYUIrVGJRL3JTckExZEdh?=
 =?utf-8?B?Uk1sZ2JWMFdhRURJWndRWTE5YmU5TXl4N0hicXR5NGRhVVY1eDJlVldpMWEx?=
 =?utf-8?B?QkIrQXMrUnNTaTJ6Q25FbVVabStYNFcybkdtQWRkb3pMdS9jZHZNa0dIaXdq?=
 =?utf-8?B?VWpKanM0Tk43V3lSY01nZWh4VGZnV0tDS3lyNiswQjlKZTgvUzRlNktVUGg5?=
 =?utf-8?Q?sjC+oI?=
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)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jun 2025 22:20:50.5050
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f165f09c-03dc-4a77-4cae-08ddb2a435f9
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:
	CO1PEPF000042AB.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB7689

On 2025-06-16 08:59, Jan Beulich wrote:
> While supposedly safe via enforcing a control flow change when modifying
> already prefetched code, it may not really be. Afaik a request is
> pending to drop the first of the two options in the SDM's "Handling
> Self- and Cross-Modifying Code" section (still present there as of
> version 087). Insert a serializing instruction there, and remove the
> "noinline" in exchange.
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Jason Andryuk 


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 22:21:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 22:21:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022834.1398694 (Exim 4.92)
	(envelope-from )
	id 1uTpXU-0007Gs-3C; Mon, 23 Jun 2025 22:21:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022834.1398694; Mon, 23 Jun 2025 22:21: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 1uTpXU-0007Gj-0I; Mon, 23 Jun 2025 22:21:20 +0000
Received: by outflank-mailman (input) for mailman id 1022834;
 Mon, 23 Jun 2025 22:21: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 1uTpXS-00077v-Ob
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 22:21:18 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20621.outbound.protection.outlook.com
 [2a01:111:f403:2408::621])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 60aacdb5-5080-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 00:21:16 +0200 (CEST)
Received: from CH2PR15CA0014.namprd15.prod.outlook.com (2603:10b6:610:51::24)
 by SA1PR12MB6896.namprd12.prod.outlook.com (2603:10b6:806:24f::5)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.28; Mon, 23 Jun
 2025 22:21:10 +0000
Received: from DS2PEPF0000343A.namprd02.prod.outlook.com
 (2603:10b6:610:51:cafe::f0) by CH2PR15CA0014.outlook.office365.com
 (2603:10b6:610:51::24) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8857.28 via Frontend Transport; Mon,
 23 Jun 2025 22:21:09 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 DS2PEPF0000343A.mail.protection.outlook.com (10.167.18.37) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8880.14 via Frontend Transport; Mon, 23 Jun 2025 22:21:09 +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, 23 Jun
 2025 17:21:03 -0500
Received: from [172.29.43.193] (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 Jun 2025 17:21:03 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 60aacdb5-5080-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=o/v6yYXMESkN0ConGFWF8vreuyCv3Zdnz7TaDdKHUkm2VYWmQOJQ9m/m+sYJ1oaHvd0gdeL3OBFgiZ04kXsWd+Y1nVu/tCEyFWlhsjQuE7+6elSEqDCPHwMpsvx9pW2xyDqyHnRwBRzV1dIzWc6Go8Y6CQht8MK0JL1R+0ti5lRP0OJ9jBBdwZaSW5UG+SkJU1mgbo0icWBDRF/ACVZCR7Zx1EQ4iRDOWYZXb5k9so0duhz/oXV4RNqqo+ilrSQzfQ0uIJOkqwIZFG6w45B8BsV9MzRo2FUSLI20kf6QdiO5fGOHJ5NnnRY5oYBV1V8g0EtXwojmkgN2IEPymAaQpw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=mB6Vy5XF5HQ0c+7yK3aoA/i6dYI0TsGVFvh/gqBdrpc=;
 b=YlO4SUqQ01eVLn4BB3QhpPx1JwscoGUZLUctenSAQAvA5v5VMKRDpvD3sEQosxTNkmm1sJM9kdJoxmRGknQglSiYgT9lY53PN0HCF/nXV6s5LIKRda0kTAOGRWXwpjQMXr23/9fEZXrnIyiUTgDe6Q6QEeJ2v4Q13/zgr2V/SPBIfLVMafT2VDDIIJh7ZEdoniSHG0ptE7Q3g/2LZ6Ok8esmGg8W/viah6cADks3n4cfdCzwpndxFd4sYtQnn5QOYVTAJyVXIUjUWd000y2ztRcxQAGWHF9HOvFXFoL7xW24ckIoBHuCtLpMtTmtICGVu3WRS4wbKTnHyeQh6U6RBQ==
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=mB6Vy5XF5HQ0c+7yK3aoA/i6dYI0TsGVFvh/gqBdrpc=;
 b=MEJf2FDUbIv99DqHIr13hSt81z6tzAHTLtnN0HssrIloT9eY8Hj6vfSQCnhhHPQPuaFPyjoqyziPuWXyJ0QFX+w+IviNQLn0Iq7kpyj9FulzIsE3UthzWmll2vRu+IV7dJW8E5t0Eo3K8ZOl+7bhXNp9HLhfYajHbkCIEldcE4Y=
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: <5d64794a-2e2d-439e-8067-b0edf2c3f0f9@amd.com>
Date: Mon, 23 Jun 2025 18:18:34 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 3/7] x86: re-work memset()
To: Jan Beulich , "xen-devel@lists.xenproject.org"
	
CC: Andrew Cooper ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: 
 
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: DS2PEPF0000343A:EE_|SA1PR12MB6896:EE_
X-MS-Office365-Filtering-Correlation-Id: 7867c7a2-07be-497e-2842-08ddb2a4414c
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|36860700013|82310400026|1800799024|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?ZktlWHo3d2JiU2JDcDdIMHZSY1JYODRlOXBsTERSL0g5UXZMQ1pSK1hqbmF3?=
 =?utf-8?B?eUxyRzVrL1NFenpwL3FFL1h0KzNUZnkwYkxPT2FzbmV4am9PTnFJa0o1L3cr?=
 =?utf-8?B?NDg1Zyt6T3pnbndMWkJBWTR5c1pXT1hEWm5sS2MwaVBQMmFOWEE1U1Q5QmVs?=
 =?utf-8?B?Sk1NeUVkUEVTSEcweGk1Q2w5L0V0anpUOElyc0dTZitLUEM0QVdGaWNhTDhJ?=
 =?utf-8?B?a2tLYUduZnl1NUdXOEJ6Nm5PTjFNQjBkVkZHZENUZ3l5SGZ6SG1yMjk0eHNT?=
 =?utf-8?B?S3pPVFJ3dWhod25MK3RSMitxS1JuSUJYUEdhTVpTY28vM0RnY2JTbUNkT1A4?=
 =?utf-8?B?M0tjSXEvNXRyRDlEUDZ4UTNjclg4RTBIa20veDl5ZGZmLzlMMXlua1czMm5t?=
 =?utf-8?B?eHdRYnlRbGVHNDVnalFLQlBYTkxEelFIU2J3dVFCZnZoUjlKSUhxOEZzZ2FT?=
 =?utf-8?B?dHJOZnQyVFNpL1pjYUsyZTgrMlpSOGU0YXIxbnBNbHA1UnZ6ODRncFhLYjYr?=
 =?utf-8?B?bXQ0Z0NlUEx6S1FkUitKcXI4cTViWWNTU2tWLzJWeG9oak9tSWhveWN4cUdP?=
 =?utf-8?B?YnRqMzFQNnl6WkJOQlZVL0RlWGlkUjQ3akxNeE5aQ1UzMzB2ZXdIYVNBVWFn?=
 =?utf-8?B?WnRiVnBRdFNzdGQybXprZngzUnBlUjlCczZxbDh1Z2Y3c1YyL29nV3pnclh0?=
 =?utf-8?B?Q1h1K0UrMHZBTDFqT3ZEYld5WUliOFkyT3hQSE5WVTJGVUJoS0UxTFdjOEFZ?=
 =?utf-8?B?ZzZaSkpwWXVlTElScDJ2Sy9ZL0ppNklPTVlvM0xlcFZxbEpPait4SmlualQv?=
 =?utf-8?B?NExnU1dlb0pFTzZ0Qzk5L3pWenMxTU5Tbis0MnBZd0NUajZBQmNDV0piV1VI?=
 =?utf-8?B?bXBKRjVUSDA4aStWaTB1SnN6SU1LWDZFQXZFWFhrZXF2OHRQaTRSc1lhSjdL?=
 =?utf-8?B?c3ArblF2S3pXblFmS1N0Nzllb0RxWUd0WWVYNnJlbStzOWZ2ZmFtWjBhZU9E?=
 =?utf-8?B?Mmh6SzNLS3U5RTRrT1NDTXZmQ25yWW9SQVBWTWEwYk1aUWJXOTg4TnZTRENV?=
 =?utf-8?B?ODkzbXArdjZDT0g5TnlFU3Z0ZUpFbXdHNFZWZzNrNGlsS0l4c05ZRmQvcG5a?=
 =?utf-8?B?c0hKa21vSmNWQ3NNajk3VE1MRHVJUHNuRjZyR0ZzOVlQMHo4SEw0UnlPaW90?=
 =?utf-8?B?djQvTkE4Y3pXaUc5bGplZnZQdkpGMTJCK3ZwcTZrV2kyTit1M2FoaThlNFZo?=
 =?utf-8?B?WjZaZ3d0TGU5ZzJlczVBby9xQzQyTVVQV0hxK3o0NW5yVjZVU3lnUkZSNWhn?=
 =?utf-8?B?bldualBjaWxWckQzWnVOKzlSWlZtY2ZTMU9XMWdHQloxdDF6UWlVTHlSUjdV?=
 =?utf-8?B?VnZRWXNuU2w0M0tZU1hPMFU2QmxPdWtpdG5zamJpclBlbFhnTi95Q2h3WTMw?=
 =?utf-8?B?c0hzTUlBRXdJQ0NuTTEzNEt4dStXWjdadFRVWmJxMmllaEFac3VWb3drUkZ3?=
 =?utf-8?B?amVjcWxBWXQrblMzdS9ZY0hnN1lVQjlaanhGV2FGdEZGM25INjVjWDA0WEp4?=
 =?utf-8?B?ODhNbmJzaldPajg2K2JISFNER0xPYlEwWlRFb0dzdGN1MmcxdkYydWtaYUhI?=
 =?utf-8?B?U3FiTjUrSFJrY0NkZGRER3VKVVZ3dUZoYzF0N2UzQzRvd3BIR3VidXFheXA5?=
 =?utf-8?B?MlduVlh6d1ZpbHlpclRuNURhTEtzSlBvU2V3U3oxN3pIR0xmL0ppWW5WcXdX?=
 =?utf-8?B?RkM2c3dXTTcxcExlblB0bmNVNjB5OGFSRDh5Y2VzQ2wxT0NYQzJ0OFVYcTht?=
 =?utf-8?B?RWttSy9id0gwWGlFdnFVK0ptOFYxemNTcys1UjFLd3FLNk5EU0RpNnNlYk9j?=
 =?utf-8?B?c1VoYWh1S3ZjTlY2VGMrVy9NOVBhNTdZTGJDS0VhbCtzWi9TaTEydVVQa3hQ?=
 =?utf-8?B?eXhSR0h2UUFWcXFaZ1NvQTBkVkVKcHlXUGtGM3AvSmplZkZJYkpWQkNmU0ZK?=
 =?utf-8?B?Q1pSSi9GV1ZYSjlXd3JKemo1Q2FFT1g4SnFxQUwyUG4xa044b3FGajFFZGs4?=
 =?utf-8?Q?4VWLUX?=
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)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jun 2025 22:21:09.5573
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7867c7a2-07be-497e-2842-08ddb2a4414c
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:
	DS2PEPF0000343A.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB6896

On 2025-06-16 09:00, Jan Beulich wrote:
> Move the function to its own assembly file. Having it in C just for the
> entire body to be an asm() isn't really helpful. Then have two flavors:
> A "basic" version using qword steps for the bulk of the operation, and an
> ERMS version for modern hardware, to be substituted in via alternatives
> patching.
> 
> For RET to be usable in an alternative's replacement code, extend the
> CALL/JMP patching to cover the case of "JMP __x86_return_thunk" coming
> last in replacement code.
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Jason Andryuk 


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 22:52:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 22:52:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022847.1398703 (Exim 4.92)
	(envelope-from )
	id 1uTq1A-00030m-EY; Mon, 23 Jun 2025 22:52:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022847.1398703; Mon, 23 Jun 2025 22:52: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 1uTq1A-00030f-BZ; Mon, 23 Jun 2025 22:52:00 +0000
Received: by outflank-mailman (input) for mailman id 1022847;
 Mon, 23 Jun 2025 22:51: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 1uTq18-00030Y-Qn
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 22:51:58 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a90a20cf-5084-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 00:51:55 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 24BE761F1C;
 Mon, 23 Jun 2025 22:51:54 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id E0984C4CEEA;
 Mon, 23 Jun 2025 22:51:51 +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: a90a20cf-5084-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750719113;
	bh=bTKWkkJclPge7Z+oSdCWTmWZgtgDgQBko/k7ot9OALo=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=cVg4q0jWmZMfnwt/RrI4bKF6cVVGat1RVctp/Uzjz5lFtrIPrK3RIRXQtUS97q1v4
	 udlx/Xyhr9MbXVAUjmYQS6+au0r4q0qjH8FuDAIUEvIyHtuBmZWwLLKo1pUefVtD9J
	 1XEFoOC4upheGsXiKJlmTJYcFIf9uPqD9KoIfabqWNFdwx0DCKlyMCAJ+2Hjmqw9m2
	 q7KQ9+8NO+Ofbwj1gD1XSXhUYYQsrAhHTRbV+p3eW1G7n/91UgWhw3FwxFSJWVKZ8F
	 8Hf81pZNVyWDqCKkzMdfPYHwdTsKXWkwwwBLJ10HkcqwupVLQnXSTVHA/ExnrqtfR8
	 WIMXgJRukJTGw==
Date: Mon, 23 Jun 2025 15:51:50 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: jbeulich@suse.com
cc: Stefano Stabellini , jason.andryuk@amd.com, 
    Julien Grall , Bertrand Marquis , 
    Michal Orzel , 
    Andrew Cooper , 
    Anthony PERARD , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , ayankuma@amd.com, 
    xen-devel@lists.xenproject.org, demiobenour@gmail.com
Subject: Re: hardware domain and control domain separation
In-Reply-To: 
Message-ID: 
References:  <942a6178-0fe7-468e-8e45-ea255fd20680@suse.com> 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

I am replying out of order hopefully to make things easier to follow.

On Mon, 23 Jun 2025, Demi Marie Obenour wrote:
> On 6/23/25 11:44, Jan Beulich wrote:
> > On 21.06.2025 02:41, Stefano Stabellini wrote:
> >> Regarding hardware domain and control domain separation, Ayan sent to
> >> xen-devel an architecture specification (a design document) that I wrote
> >> previously about the topic. This is written as safety document so it is
> >> using a language and structure specific for that. However, it contains
> >> much of the explanation needed on the topic:
> >>
> >> https://lore.kernel.org/xen-devel/20250304183115.2509666-1-ayan.kumar.halder@amd.com/
> > 
> > Yet even there the line between Hardware and Control is already blurred
> > imo. Take "Reboot and shutdown the platform", for example. It seems
> > pretty likely that Hardware has ways to achieve that without involving
> > a hypercall.

That is not correct. We have all encountered similar issues with servers
and other boards we have worked on, and I have had comparable
experiences as well. However, such issues cannot happen on silicon
designed for safety-critical environments.


> I expect that in safety certified or fully disaggregated setups, even the
> hardware domain only gets an allowlist of devices, MMIO, and I/O ports.
> If an I/O resource could be abused, it is either assigned to a Safe domain
> or is simply not used at all.  This is going to be very platform-specific.

That's right.


> > Furthermore there it is (again) assumed that Control has full privileges.
> > I did mention before that I'm not convinced any domain, in a
> > disaggregated setup, would need to have (nor should have) full privilege.

Thinking more about this and also thanks to Jan's comments, I realized
that "the Control Domain has full privileges" is an oversimplification.
The main role of the Control Domain is to monitor other domains and
trigger a platform-wide reboot when necessary. As such, it is probably
not a good idea to describe it as "full privilege" because in reality it
doesn't create/destroy VMs, and doesn't do other operations that would
be part of the "full privilege" concept of Xen.

The Control Domain needs to be able to trigger a platform-wide reboot,
platform-wide shutdown, and platform-wide suspend. That is pretty much
it. I think I need to update the document I linked to explain this.


> > You can also see that (kind of) connection in the
> > hypervisor itself: The special handling of a domain shutting down is
> > in hwdom_shutdown(), with the call to it keyed to is_hardware_domain()
> > (as is to be expected from the function's name).

This is an important detail. As wrote above, maybe we don't actually
need the Control Domain to do anything else or need any extra
privileges, but the Control Domain needs to be able to trigger a
platform-wide reboot. We might have to change this check.


> > Also a more fundamental question I was wondering about: If Control had
> > full privilege, nothing else in the system ought to be able to interfere
> > with it. Yet then how does that domain communicate with the outside
> > world? It can't have PV or Virtio drivers after all. And even if its
> > sole communication channel was a UART, Hardware would likely be able to
> > interfere.

There are well-established methods for implementing domain-to-domain
communication that are free from interference, such as using carefully
defined rings on static shared memory. I believe one of these techniques
involves placing the indexes on separate pages and mapping them
read-only from one of the two domains.


From xen-devel-bounces@lists.xenproject.org Mon Jun 23 23:46:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jun 2025 23:46:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022858.1398714 (Exim 4.92)
	(envelope-from )
	id 1uTqri-0000lX-7b; Mon, 23 Jun 2025 23:46:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022858.1398714; Mon, 23 Jun 2025 23:46: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 1uTqri-0000lQ-4s; Mon, 23 Jun 2025 23:46:18 +0000
Received: by outflank-mailman (input) for mailman id 1022858;
 Mon, 23 Jun 2025 23:46: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 1uTqrg-0000lK-FZ
 for xen-devel@lists.xenproject.org; Mon, 23 Jun 2025 23:46:16 +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 37d401bc-508c-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 01:46:02 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 926265C5D54;
 Mon, 23 Jun 2025 23:43:43 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id AB553C4CEEA;
 Mon, 23 Jun 2025 23:45:58 +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: 37d401bc-508c-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750722359;
	bh=3BTFfLfGn5OuY5t/PSSuT86s2TgeHkTuuV4slV83vyY=;
	h=Date:From:To:cc:Subject:From;
	b=l7B4N3fC+ibv8i3i9b3PudMM7ok7YOSv8xLQYG6WKUWjZiEEy+jIJnHYveKHKslkv
	 4cgwwIuptjvcDaI1spoFYxhEtP68/w8/xPQrpj1S4qu4cZbhG2erkYDRhkjzZXd+ns
	 voc/eHXpGNRSuAdyMF+3r44cHuAjQYbrNMgExJJGjVly1q95Cv63KSgbvANHxOVny2
	 jm8Nu/T3nhDYLdRKREyYwtkXaheqlZKUWLBzmltyvulghM8/cbakwfXo+eNVa3QR/3
	 y0mDa3NUtCLxJY37U+/w97Rx2KIm+df25CgHZuCZqdQsDQK2gOmb8L4HTRu+t+QdoX
	 zuRIla2ZAYYyA==
Date: Mon, 23 Jun 2025 16:45:57 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: xen-devel@lists.xenproject.org
cc: sstabellini@kernel.org, andrew.cooper3@citrix.com, michal.orzel@amd.com, 
    jbeulich@suse.com, julien@xen.org, roger.pau@citrix.com, 
    Bertrand Marquis 
Subject: [PATCH] docs/misra/rules.rst: allow string literals with memcmp
Message-ID: 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

Rule 21.16 is about the types of arguments allowed for memcpy. Add
string literals to the allow-list under specific conditions.

Suggested-by: Jan Beulich 
Signed-off-by: Stefano Stabellini 

diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
index e1c26030e8..3e014a6298 100644
--- a/docs/misra/rules.rst
+++ b/docs/misra/rules.rst
@@ -813,7 +813,9 @@ maintainers if you want to suggest a change.
        shall point to either a pointer type, an essentially signed type,
        an essentially unsigned type, an essentially Boolean type or an
        essentially enum type
-     - void* arguments are allowed
+     - void* arguments are allowed. string literal arguments are allowed
+       when the last argument passed for the comparison is less or equal
+       to the size of the string.
 
    * - `Rule 21.17 `_
      - Mandatory


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 00:20:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 00:20:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022869.1398730 (Exim 4.92)
	(envelope-from )
	id 1uTrOz-0006Fj-UB; Tue, 24 Jun 2025 00:20:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022869.1398730; Tue, 24 Jun 2025 00:20: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 1uTrOz-0006FI-Pd; Tue, 24 Jun 2025 00:20:41 +0000
Received: by outflank-mailman (input) for mailman id 1022869;
 Tue, 24 Jun 2025 00:20: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 1uTrOx-0006CC-Qk
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 00:20:39 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20628.outbound.protection.outlook.com
 [2a01:111:f403:2413::628])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0ac0f783-5091-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 02:20:34 +0200 (CEST)
Received: from BN0PR04CA0150.namprd04.prod.outlook.com (2603:10b6:408:ed::35)
 by MW5PR12MB5683.namprd12.prod.outlook.com (2603:10b6:303:1a0::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.29; Tue, 24 Jun
 2025 00:20:28 +0000
Received: from BN2PEPF000044A4.namprd02.prod.outlook.com
 (2603:10b6:408:ed:cafe::b5) by BN0PR04CA0150.outlook.office365.com
 (2603:10b6:408:ed::35) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8857.30 via Frontend Transport; Tue,
 24 Jun 2025 00:20:28 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN2PEPF000044A4.mail.protection.outlook.com (10.167.243.155) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8880.14 via Frontend Transport; Tue, 24 Jun 2025 00:20:28 +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 Jun
 2025 19:20:27 -0500
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, 23 Jun
 2025 19:20:26 -0500
Received: from xsjvictlira50.xilinx.com (10.180.168.240) 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 via Frontend
 Transport; Mon, 23 Jun 2025 19:20:25 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0ac0f783-5091-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Zm57fYIqWU7EIN/Le5C2pjhQ1y9RCGdtyTeG/lH3xu92zIgiUMDyLeCmTlVCVU1tDobpOMU6Qy+UZWW3Fu3+/mLm8AxT7sdaCeXmFe28YsTJHnx4T3E5BVercDQfSzNM0fBYuLnu3tn9sR0bE7pFiJm1h7L+69vbaBys8tQYNK81mvg18o6tC94DGO7Pbr9mp1x+WJUns5QVS5P7FxmvpJTroYnQjVOZBXQRVTJP2ZQpCFbdoiPTnQg6y1quoy56jT+9ttJ+cPx8lXDnGFng8zn6I6yQySAH5EN9YJI1yeg4em2KXDTQTlx1FhZLa6dslk11yEt2DWp0tARMce5feQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=bSJwW2j+84BVU86M+ey7G1OUCwpFZObGFbhbZ90payg=;
 b=xlxNEGllzfXi+o22IWVSEOk3dMHmKyKAXH+cBJVKXDOFlGCcQS34aYf48dxFJwsSSIgjDTqZfGcsRG/w73vRazerP+d28gzkMUMM+TKGnDaB5T5UY6MqDwaudZxdb6pBLaX5DBliHMt332quXRhUj40GxC4RGW19gBYVUqwElu/Lm3dLV7eyQZSWezzKBFgKwypy9fCOjgHSqDFZmt8QsYNjlneM+M98oQGiGBXqSlwBMyueCAXJV4vKH8AEcdzxFZRdNGKomeWzxQBa3FAZfGmkfKwoOLDUcFaIkID3CSZiV4GsOqVDeOixoXsXq6ZF0VMVNB2SU7V3QSyDrOWduA==
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=bSJwW2j+84BVU86M+ey7G1OUCwpFZObGFbhbZ90payg=;
 b=QjxXmO3FDCMApFF8jgAK7td/Mul3aey0SVPZlROrlRfaQ0Um4ISjrsFDHpp+walfvjfO4GvqxhEDr42QHJcoVkdi9v5WsTY7pV4yCRact3UPQDKcJjmHzLVS2lcRbC+AWDMo5Xde5gqe+29qAPRn8XcSpyxr+SckXGeWbD5hczw=
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: 
To: 
CC: Nicola Vetrini , Victor Lira
	, Andrew Cooper , "Anthony
 PERARD" , Michal Orzel , Jan
 Beulich , Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=83=C2=A9?= , "Stefano
 Stabellini" , Federico Serafini
	, Bertrand Marquis 
Subject: [PATCH 1/2] xen/arm: address violations of Rule 11.3
Date: Mon, 23 Jun 2025 17:20:14 -0700
Message-ID: <20250624002018.4121819-1-victorm.lira@amd.com>
X-Mailer: git-send-email 2.47.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB05.amd.com: victorm.lira@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF000044A4:EE_|MW5PR12MB5683:EE_
X-MS-Office365-Filtering-Correlation-Id: 94754749-4ffa-4916-cb5f-08ddb2b4ec14
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|376014|7416014|36860700013|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?c0c0T0l6RDhERHpUcEJtaDQzZk1VV2NOczRBL0NCMTZsb3NyTnF1TnBWYmpr?=
 =?utf-8?B?VnVQVFVqN211WG5jQVB6TVFPTmE1TXhEQzQzNjZKUlAzTDIxV1RvT3lIVWhy?=
 =?utf-8?B?M1BhUGVidlZ2ekx6UWZlbnN1SmJySGRpSldPdXBtNFk0V2hibWc1L29IaU12?=
 =?utf-8?B?K1NFYVdpMDVmcFN0TmNSNisvYko2VVBvREdWWldZaDZCL2pMdUR2WUd3dkgy?=
 =?utf-8?B?Vy8wajV2bVdLMmpINGhKWS9UMFlBWkFRTkhPYmhnZjdDakV5dVloNUNWNUc2?=
 =?utf-8?B?UFBZWWFCYklsQ3VrejJXYjZEaEFabVNHSVpuTWxtWEF0TTR1djgzOG9SR3hO?=
 =?utf-8?B?OXl1NWUveUdBUVBpd1dvVVBFS1BWRW54Yk9UN2ZxcHdpZHJSMy9TS3lhSVdT?=
 =?utf-8?B?NHpMaHowSHg5N1d2b0dNb0d6SXJpeHZrZ1IrS1hWQjkzRjhtdkRXV05mME9W?=
 =?utf-8?B?RVNmYXhndTlLaTVRWnIwNGxlRWx0OE9YMU4zQnQwT0ExeWxoTklpNDdNQkRE?=
 =?utf-8?B?R0pXcm9xcDQ5Y2VuWndnR3M0dDlGL0ZwV1VIWmtFcGVjYUxiQnZHZFUvRzRw?=
 =?utf-8?B?Qk1udnBvSnpSdnFBSkRHY003cCtKMmYwQkdhcCtqUGxrZkFYRkhUYjhNNGVZ?=
 =?utf-8?B?cHJad3dQV2h4OHEvM2tOMDBhUE90NUkwc3B1M3hkNVFzUzVMSDM1clR3RFhm?=
 =?utf-8?B?V3RDYmFEQkFqbXlJTkV6NTZjZXRZYUhzb3BjZFpaMXUvSitTbklNRjBnWHo0?=
 =?utf-8?B?Zk8wMW4wZXZkOUlTMmlzZWlvcWtjaG10amkxR0xJZ0FrMDBUdG9BM2tsTERV?=
 =?utf-8?B?dDdXZUFlTkwzMHk0ODYrNGRCMzJYZTM4anJ1S1MvUHpmSFIxc0FIdVdLZzRZ?=
 =?utf-8?B?SXphVFBvUS9KMW9tSElQdWhqRjRYTXVqZlI1dmJocnU0cjZSckxMK2tkbStP?=
 =?utf-8?B?MFdZaEVRSFBtZHZBMXBTb0JxeFVkQ1Rvb3ArS3BsK1dnWUpPMWo0cUFJdWR2?=
 =?utf-8?B?blorNlFVRE56ZHVUb0xxamtnK21mZGRkZ3g1NHY5ZmEvcXdKZUNZZmozMXRH?=
 =?utf-8?B?bTdHMWg2TlRLMDlCandRZ2kwWHMvMEFHRjRxeHJaeWZ3SUhmZ1RjdjE4ZW5F?=
 =?utf-8?B?SW5USk5sSE04c1l6N3M4UXhVZGZ6VUJ2aThVVEEwQjJqWllPZ0VEajV5UGJQ?=
 =?utf-8?B?clZOeE4rS3BzZ1liaTFoMzZLSkFPcU5RUkRaMkQ1clBiWVQvVk9iYlJNcnJZ?=
 =?utf-8?B?YTVDRWlUTUF4UEZ0bmNXWkdYL2JTQWp4akh0eXplb0wxQ2NHOTMwR3g3c2VD?=
 =?utf-8?B?NFk1eFRGcVlGVFlkMVZJQjY5SG80Q3Zqd00xTkZZSXZCSktkZHhHb29IVUxy?=
 =?utf-8?B?clA0NlBkU2ZTeDlzSXpwODBJalVBcXlMOTRKOC9XTkJxbXQ4Rm13WU85MEE3?=
 =?utf-8?B?NnBQd3RUa0RhTjNzSjlYTUlCLzZNcGsyKzkyQ0dSVDBKRWtMb1J4SkRMZjM3?=
 =?utf-8?B?TlI3UlpkR1ZpS0F0L2FQZzhRWG5tMWlVZkVvUVgwM3RvWGFQQ1FpNnRyQ2Iv?=
 =?utf-8?B?NkJpUGlWU3hyWnN5NUMyWk1mclJHUE52aFdTUlJ1MWd1dmZJWkVkbkx2dytj?=
 =?utf-8?B?Tkl0c0N2eitkUk1lRTZRYlpqTU5LbGNGbHZaNEsxNStJRmxHc2lhOFgxN3Bk?=
 =?utf-8?B?d2tEVTFtYW5Ldmk4bkkvUUp3RjkvbHVMbVNFVlZXK1JLTWdDK3BaOThUK0sx?=
 =?utf-8?B?dExqMXlpZjJQUlh2eGtrNHU1SkgzMlFSd2VENmVWbm0zWDBMYkZJVnhqQk5x?=
 =?utf-8?B?cENLYWx6Nk5yVHdlK2lWTWZqNjFuMTF1azZWU0NQVEN2K0pmK1BmejRwSkN3?=
 =?utf-8?B?d1A5RjVlZFhVQmF4UURYbThITUZQSzV6UjFJT1Z2enNoZW45NGNTdnk1QUdM?=
 =?utf-8?B?OGFnZkVhS0RwYi9lUjVGQUhkVVltKzZMVTBtTW5FMVE2M3JHM1pyUlY5Qk5Q?=
 =?utf-8?B?aTc4UHpxV2hocjlLd2IzSXA0a2dXeHRuKy9PdmlLRitMYmVMQ1FmREtsaENB?=
 =?utf-8?Q?0ICx6l?=
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)(7416014)(36860700013)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jun 2025 00:20:28.0698
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 94754749-4ffa-4916-cb5f-08ddb2b4ec14
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:
	BN2PEPF000044A4.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW5PR12MB5683

From: Nicola Vetrini 

Use {get,put}_unaligned_t to ensure that reads and writes are
safe to perform even on potentially misaligned pointers.

Signed-off-by: Nicola Vetrini 
Signed-off-by: Victor Lira 
---
Cc: Andrew Cooper 
Cc: Anthony PERARD 
Cc: Michal Orzel 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Roger Pau Monné 
Cc: Stefano Stabellini 
Cc: Nicola Vetrini 
Cc: Federico Serafini 
Cc: Bertrand Marquis 
---
 xen/arch/arm/efi/efi-boot.h      | 9 +++++----
 xen/common/device-tree/bootfdt.c | 3 ++-
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
index ee80560e13..12dbb6961f 100644
--- a/xen/arch/arm/efi/efi-boot.h
+++ b/xen/arch/arm/efi/efi-boot.h
@@ -9,6 +9,7 @@

 #include 
 #include 
+#include 
 #include 
 #include 

@@ -85,7 +86,7 @@ static int __init setup_chosen_node(void *fdt, int *addr_cells, int *size_cells)
         *addr_cells = 2;
     }
     else
-        *addr_cells = fdt32_to_cpu(*((uint32_t *)prop->data));
+        *addr_cells = fdt32_to_cpu(get_unaligned_t(uint32_t, prop->data));

     prop = fdt_get_property(fdt, node, "#size-cells", &len);
     if ( !prop )
@@ -96,7 +97,7 @@ static int __init setup_chosen_node(void *fdt, int *addr_cells, int *size_cells)
         *size_cells = 2;
     }
     else
-        *size_cells = fdt32_to_cpu(*((uint32_t *)prop->data));
+        *size_cells = fdt32_to_cpu(get_unaligned_t(uint32_t, prop->data));

     /*
      * Make sure ranges is empty if it exists, otherwise create empty ranges
@@ -824,7 +825,7 @@ static int __init handle_dom0less_domain_node(const EFI_LOADED_IMAGE *loaded_ima
         return ERROR_MISSING_DT_PROPERTY;
     }

-    addr_cells = fdt32_to_cpu(*((uint32_t *)prop->data));
+    addr_cells = fdt32_to_cpu(get_unaligned_t(uint32_t, prop->data));

     prop = fdt_get_property(fdt_efi, domain_node, "#size-cells", &len);
     if ( !prop )
@@ -833,7 +834,7 @@ static int __init handle_dom0less_domain_node(const EFI_LOADED_IMAGE *loaded_ima
         return ERROR_MISSING_DT_PROPERTY;
     }

-    size_cells = fdt32_to_cpu(*((uint32_t *)prop->data));
+    size_cells = fdt32_to_cpu(get_unaligned_t(uint32_t, prop->data));

     /* Check for nodes compatible with multiboot,module inside this node */
     for ( module_node = fdt_first_subnode(fdt_efi, domain_node);
diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
index 529c91e603..9f255027ea 100644
--- a/xen/common/device-tree/bootfdt.c
+++ b/xen/common/device-tree/bootfdt.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #ifdef CONFIG_STATIC_SHM
@@ -213,7 +214,7 @@ u32 __init device_tree_get_u32(const void *fdt, int node,
     if ( !prop || prop->len < sizeof(u32) )
         return dflt;

-    return fdt32_to_cpu(*(uint32_t*)prop->data);
+    return fdt32_to_cpu(get_unaligned_t(uint32_t, prop->data));
 }

 /**
--
2.25.1


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 00:20:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 00:20:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022868.1398724 (Exim 4.92)
	(envelope-from )
	id 1uTrOz-0006CU-LE; Tue, 24 Jun 2025 00:20:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022868.1398724; Tue, 24 Jun 2025 00:20: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 1uTrOz-0006CN-Hm; Tue, 24 Jun 2025 00:20:41 +0000
Received: by outflank-mailman (input) for mailman id 1022868;
 Tue, 24 Jun 2025 00:20: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 1uTrOx-0006CC-4I
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 00:20:39 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20612.outbound.protection.outlook.com
 [2a01:111:f403:2009::612])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0c6f857c-5091-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 02:20:36 +0200 (CEST)
Received: from BN0PR04CA0125.namprd04.prod.outlook.com (2603:10b6:408:ed::10)
 by CY3PR12MB9653.namprd12.prod.outlook.com (2603:10b6:930:ff::5) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.25; Tue, 24 Jun
 2025 00:20:31 +0000
Received: from BN2PEPF000044A4.namprd02.prod.outlook.com
 (2603:10b6:408:ed:cafe::fb) by BN0PR04CA0125.outlook.office365.com
 (2603:10b6:408:ed::10) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8857.30 via Frontend Transport; Tue,
 24 Jun 2025 00:20:30 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN2PEPF000044A4.mail.protection.outlook.com (10.167.243.155) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8880.14 via Frontend Transport; Tue, 24 Jun 2025 00:20:30 +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, 23 Jun
 2025 19:20:30 -0500
Received: from xsjvictlira50.xilinx.com (10.180.168.240) 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 via Frontend
 Transport; Mon, 23 Jun 2025 19:20:29 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0c6f857c-5091-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=BFhSRqPbdYwNsMLopKaXtnMOmDEHpz7nuH5d00K9AS9re7WMpdyTdtazNUzPJDFN+FMwdhbkMl4Sw9Ic7x5JZaIbCXjq+fycw+y+QKb09rMKYW8ATPtiI5rr29tAsA2RMbEjJbw94nCOYN/CxOMsHD/1phz3PEvULTt9qh7Lo4EEmFzjMen3dkLwc09S3yShvb6JwH0tS4vxI33SS0GV/2iZk7BM38raJmAofhKE0bDLsMaB2AUYsNucisYgBxDOynq1JjhBMK5/nHQWS8KpzbfvmTaC8nDYN9sKPICIwrf4V5DKAv5MDLet3grVQmbSTIMk26btkhi9stgIex6V4w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=nIkRL+KmS9tOBKdPslWRWd6541u4H2gTXTX/zlKIRfg=;
 b=ahX68Ba2Dm2hYFicJMGAVA7EQPQ+klOzohDubbOhajIy1XbfhMwLhz31j42657H4N+mTwBjM+ktgFi31O8ltPUZFr+HZrlkir9PzHIu7Mnpl12fFh3pUtqEmGCq3oCZJQ1YNFf4sl9vlWChb5K5sNM8kiWUV7GxasMHTkjCYEJb/mi3Mmlfyu6fszkvyNmQXs1PnKjhsfwLe1ydhL9p1LzXxH8fFjS37f1syMEruABc3loZ2SPuWDNFplqBNhIxvLPjA3z6gzvfVowiRlJb1NKISFUSHgfwVfe8x2xriGy8cCNMu/HGrsavN2Spj4sA33vwQ7SV4jJFtl4zmRne5Aw==
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=nIkRL+KmS9tOBKdPslWRWd6541u4H2gTXTX/zlKIRfg=;
 b=OTpXPmAJBT6UXEYknrT6y00fSgXuZqJvtPbWBLS696P1qLjBmerrfbZsKWxGyivEm0RZFXsuWkgo94l5Mi6THRFMq7G8YNtbHYjG7Wuj7KFeilO5gMXA1oDQ7r8rM5PJtYye/Gemu4tSf8WCiPYkqIryVdr7BZ/cewn10ykJSOg=
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: 
To: 
CC: Nicola Vetrini , Victor Lira
	, Andrew Cooper , "Anthony
 PERARD" , Michal Orzel ,
	"Jan Beulich" , Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=83=C2=A9?= , "Stefano
 Stabellini" , Federico Serafini
	, Bertrand Marquis 
Subject: [PATCH 2/2] xen/x86: address violations of Rule 11.3
Date: Mon, 23 Jun 2025 17:20:15 -0700
Message-ID: <20250624002018.4121819-2-victorm.lira@amd.com>
X-Mailer: git-send-email 2.47.0
In-Reply-To: <20250624002018.4121819-1-victorm.lira@amd.com>
References: <20250624002018.4121819-1-victorm.lira@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB04.amd.com: victorm.lira@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF000044A4:EE_|CY3PR12MB9653:EE_
X-MS-Office365-Filtering-Correlation-Id: 4f3b51e4-ad1e-4e74-b495-08ddb2b4edc5
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|7416014|1800799024|36860700013|376014|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?Wkk2Q2pRSWFxNmRxWUdZQmNKZEhkaTBDVTNPa0RCd3VkeDhGaGxQcXE0MEFm?=
 =?utf-8?B?WWNxQlloZjdyU1N6REtycjN1aDJrK2tMbE1qTHdrd0xRbkR3SXBiWmJFWnlV?=
 =?utf-8?B?TUg0aENnN1RrZmtQTkhZMGQ5YUNxU3FRUXBsdDBDbjZqQ29TMU5jMm5HZEZF?=
 =?utf-8?B?YnpEVFoyUXIxWU9yQWlpVjU3ZFZLRW9ySVZveVRER0lCci8rVXpxY3pKcEY4?=
 =?utf-8?B?U0ZJS1BiNzNENHBCWkordVZUZC9qcTRjWHB4V1B5Z3dOV1NsVHlBaDRpekFi?=
 =?utf-8?B?M1VPcmErMkVPMVVuTG1HWUhPWjdQS21QNlh6QlI1S285VlBwU08wSFF1YXd5?=
 =?utf-8?B?WUZNS1hsT1ZkUktsWkJrajR6V1lZazJwMG42NlFFT0FxTlp0VUM1NWdNV25q?=
 =?utf-8?B?NWpRRXQ5WitpWko0TzVXTThaUU1jUm9vVkF3VHAyaWhhVjMvTHoxY0hyMFJI?=
 =?utf-8?B?S28vY2JYVEVJMHRQSmZrY3dWMnh3dDdsRm5RazU2UzZHK1ZEakxBWVQwWnZ5?=
 =?utf-8?B?M3MrY21hZHdzK20zaTI3dytpZCsrbVU5UkdqWEl0bkg3b1FJTlFBVlR6Mk9R?=
 =?utf-8?B?RldEMm1nZTNFRjhwdm9aM2VhbzFMcGovR1J5bnVNZXYwakZNNlJzRWV5TExN?=
 =?utf-8?B?YlM0d1ZSNjR3MGZod3pHMUU0ZkZmMFgyRE0zL2hrOWxpZHVOVzlSZlY4OUJu?=
 =?utf-8?B?UHdSaGhVUXExTGtySktvYm0wSU5lbVBjUHJDaXhUUWhYU2NlbCswUjlMZHo4?=
 =?utf-8?B?N2RFQ09YV2xUY0k5TER6bi9mVHZteDlESVFST2ZZQXJwb0N3VGRncmZLSUZQ?=
 =?utf-8?B?MVRsOXI5QXNHSEM5eTNVNklXdlVUVC9JbDZZZW93ajdqZTZ2VVBhN1hCWUxj?=
 =?utf-8?B?dXBvUUtSNkcwOXh2dWdodFc4eHhzZmx4WU5oSkJVaDZsQXpPK1Ewdk9uQkp3?=
 =?utf-8?B?N296bW5GL3FOYUJEbU9iRkU0NnJiSSs1Q1I0SUVUcVNYcHFjTU0xMUN3dzJj?=
 =?utf-8?B?WG5UQS83Z2V5YWNtMjE4SGhUR0dQNnh5Ym5UUDV2TEZQdFdEZzNkODRINjd4?=
 =?utf-8?B?ZXpPY1NFbEg0c0liY21mSjZ0T0g5cVFQcW1RMnBOd25Edk1SVG1xdWxhaStJ?=
 =?utf-8?B?R0dwUXdFNnJPUjRLNEs2V2J2cTkxNE8zc1pueWNPYXVOZGJhQ3ZDeWxCa05j?=
 =?utf-8?B?cS9nNHZPb2RxeTZqOHZUdDRiZVNieDFXRHAxbTdQVHZJZC8xV2hCU2Mzbkln?=
 =?utf-8?B?K1NkVGw3WSswbE9BYkEyMnl5Ums3a1hPTWhaWGtISCtrSHVsRkkvMHRJd2Zu?=
 =?utf-8?B?NHhvR2xLUjAxSUxjajdOWGtFak04UXFrNHpuQUFNYXJveU5WaTZVZWllRCs1?=
 =?utf-8?B?ZFpTTjlubld3MEZtZEtINXUxUVROczR5b3R3ZjVqcVZmUy9IbUJsT09VTFN3?=
 =?utf-8?B?RjNURjJ5UEUvblpzL2M5cHRtblQyUGRoTkhUYzZQSDA5eUs3L0JIWlVOS0JN?=
 =?utf-8?B?aDVZM0dxWTJ5QUlwU1dGTG9TcUpjVVJjMGp5NWdEc1lJSThzdjd4MWMyWWdY?=
 =?utf-8?B?MDdkQStLdUpRVkROQU96TDZpVEtNZUJ6ZFVPOGNBczgxdEJZM0lpMGM5bDVK?=
 =?utf-8?B?enRNQnY2MjJHVjEzZEtwTHlTaUpGeUF4TkZCRjhNVTVmOUYzMUpqeXhyK2sy?=
 =?utf-8?B?Wm5ONDlzSXJ6cm9RK29ySmZLaHZMa3loVXprMkdCVUVDSGliTGs2aGkzVVl5?=
 =?utf-8?B?bTN0RjBLcXZyNEJIdmZKa3ZwL01OK0xxNkY4NDQ5aE13ZlZDaUdRc0R5cTZl?=
 =?utf-8?B?ejBvK1RoUXNZSnEzZnU0c3M0QjdtRUNIbFBUaGVaSTJRb3BzU09SWVhTZGdo?=
 =?utf-8?B?TE9hMXFVRFIzVHc4TG1jMlMzeXR4Ym1YVFRMbVFXK0JaRUR3Yk45b09JZzVv?=
 =?utf-8?B?dHdtV0JDd0FuWWJQL1NtZ2V3aVEzVUVieFpic2hUdFFGcjlFUGdKMEYvZEt5?=
 =?utf-8?B?WCtnSTZCbDdSYlBmdEx4dG5SbUo5U2xBclh6L1lwSGF6MDZjQXByVklmaGhV?=
 =?utf-8?Q?EA7rhX?=
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)(376014)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jun 2025 00:20:30.9063
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 4f3b51e4-ad1e-4e74-b495-08ddb2b4edc5
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:
	BN2PEPF000044A4.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY3PR12MB9653

From: Nicola Vetrini 

Use {get,put}_unaligned_t to ensure that reads and writes are
safe to perform even on potentially misaligned pointers.

Signed-off-by: Nicola Vetrini 
Signed-off-by: Victor Lira 
---
Cc: Andrew Cooper 
Cc: Anthony PERARD 
Cc: Michal Orzel 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Roger Pau Monné 
Cc: Stefano Stabellini 
Cc: Nicola Vetrini 
Cc: Federico Serafini 
Cc: Bertrand Marquis 
---
 xen/arch/x86/alternative.c               | 12 ++++++++----
 xen/arch/x86/hvm/emulate.c               |  8 ++++----
 xen/arch/x86/include/asm/hvm/vlapic.h    |  5 +++--
 xen/arch/x86/setup.c                     |  2 +-
 xen/drivers/passthrough/amd/iommu_init.c |  2 +-
 5 files changed, 17 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/alternative.c b/xen/arch/x86/alternative.c
index d4fe56b3da..200cf2e44c 100644
--- a/xen/arch/x86/alternative.c
+++ b/xen/arch/x86/alternative.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 

 #define MAX_PATCH_LEN (255-1)

@@ -168,7 +169,7 @@ void *place_ret(void *ptr)
         BUG_ON((int32_t)disp != disp);

         *p++ = 0xe9;
-        *(int32_t *)p = disp;
+        put_unaligned_t(int32_t, disp, p);
         p += 4;
     }
     else
@@ -345,8 +346,11 @@ static int init_or_livepatch _apply_alternatives(struct alt_instr *start,

         /* 0xe8/0xe9 are relative branches; fix the offset. */
         if ( a->repl_len >= 5 && (*buf & 0xfe) == 0xe8 )
-            *(int32_t *)(buf + 1) += repl - orig;
+        {
+            int32_t val = get_unaligned_t(int32_t, buf + 1);

+            put_unaligned_t(int32_t, val + repl - orig, buf + 1);
+        }
         a->priv = 1;

         add_nops(buf + a->repl_len, total_len - a->repl_len);
@@ -388,7 +392,7 @@ static int init_or_livepatch apply_alt_calls(
             return -EINVAL;
         }

-        disp = *(int32_t *)(orig + 2);
+        disp = get_unaligned_t(int32_t, orig + 2);
         dest = *(const void **)(orig + 6 + disp);

         if ( dest )
@@ -420,7 +424,7 @@ static int init_or_livepatch apply_alt_calls(

             buf[0] = 0x2e;
             buf[1] = 0xe8;
-            *(int32_t *)(buf + 2) = disp;
+            put_unaligned_t(int32_t, disp, buf + 2);
         }
         else
         {
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 91f004d233..3b644eed12 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -68,17 +68,17 @@ static void hvmtrace_io_assist(const ioreq_t *p)
     else
         event = p->dir ? TRC_HVM_IOPORT_READ : TRC_HVM_IOPORT_WRITE;

-    *(uint64_t *)buffer = p->addr;
-    size = (p->addr != (u32)p->addr) ? 8 : 4;
+    put_unaligned_t(uint64_t, p->addr, buffer);
+    size = (p->addr != (uint32_t)p->addr) ? 8 : 4;
     if ( size == 8 )
         event |= TRC_64_FLAG;

     if ( !p->data_is_ptr )
     {
         if ( size == 4 )
-            *(uint32_t *)&buffer[size] = p->data;
+            put_unaligned_t(uint32_t, p->data, &buffer[size]);
         else
-            *(uint64_t *)&buffer[size] = p->data;
+            put_unaligned_t(uint64_t, p->data, &buffer[size]);
         size *= 2;
     }

diff --git a/xen/arch/x86/include/asm/hvm/vlapic.h b/xen/arch/x86/include/asm/hvm/vlapic.h
index c388551198..c7a26c0a0f 100644
--- a/xen/arch/x86/include/asm/hvm/vlapic.h
+++ b/xen/arch/x86/include/asm/hvm/vlapic.h
@@ -10,6 +10,7 @@
 #define __ASM_X86_HVM_VLAPIC_H__

 #include 
+#include 
 #include 

 #define vcpu_vlapic(x)   (&(x)->arch.hvm.vlapic)
@@ -85,13 +86,13 @@ struct vlapic {
 static inline uint32_t vlapic_get_reg(const struct vlapic *vlapic,
                                       uint32_t reg)
 {
-    return *((uint32_t *)(&vlapic->regs->data[reg]));
+    return get_unaligned_t(uint32_t, &vlapic->regs->data[reg]);
 }

 static inline void vlapic_set_reg(
     struct vlapic *vlapic, uint32_t reg, uint32_t val)
 {
-    *((uint32_t *)(&vlapic->regs->data[reg])) = val;
+    put_unaligned_t(uint32_t, val, &vlapic->regs->data[reg]);
 }

 void vlapic_reg_write(struct vcpu *v, unsigned int reg, uint32_t val);
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 1f5cb67bd0..5919e94f5b 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1249,7 +1249,7 @@ void asmlinkage __init noreturn __start_xen(void)
                (caps & 2) ? " V2" : "",
                !(caps & 3) ? " none" : "");
         printk("EDID transfer time: %d seconds\n", caps >> 8);
-        if ( *(u32 *)bootsym(boot_edid_info) == 0x13131313 )
+        if ( get_unaligned_t(u32, bootsym(boot_edid_info)) == 0x13131313 )
         {
             printk(" EDID info not retrieved because ");
             if ( !(caps & 3) )
diff --git a/xen/drivers/passthrough/amd/iommu_init.c b/xen/drivers/passthrough/amd/iommu_init.c
index bb25b55c85..c00aa64983 100644
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -562,7 +562,7 @@ static void cf_check parse_event_log_entry(struct amd_iommu *iommu, u32 entry[])
         unsigned int device_id = MASK_EXTR(entry[0], IOMMU_EVENT_DEVICE_ID_MASK);
         unsigned int domain_id = MASK_EXTR(entry[1], IOMMU_EVENT_DOMAIN_ID_MASK);
         unsigned int flags = MASK_EXTR(entry[1], IOMMU_EVENT_FLAGS_MASK);
-        uint64_t addr = *(uint64_t *)(entry + 2);
+        uint64_t addr = get_unaligned_t(uint64_t, entry + 2);

         printk(XENLOG_ERR "AMD-Vi: %s: %pp d%u addr %016"PRIx64
                " flags %#x%s%s%s%s%s%s%s%s%s%s\n",
--
2.25.1


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 01:19:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 01:19:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022888.1398754 (Exim 4.92)
	(envelope-from )
	id 1uTsKD-00045V-6l; Tue, 24 Jun 2025 01:19:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022888.1398754; Tue, 24 Jun 2025 01:19:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTsKD-00045O-3A; Tue, 24 Jun 2025 01:19:49 +0000
Received: by outflank-mailman (input) for mailman id 1022888;
 Tue, 24 Jun 2025 01:19:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uTsKB-0003pS-IS
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 01:19:47 +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 500d667e-5099-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 03:19:46 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 6A8D25C5950;
 Tue, 24 Jun 2025 01:17:28 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 33B38C4CEEA;
 Tue, 24 Jun 2025 01:19: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: 500d667e-5099-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750727984;
	bh=Hq68I0LS81yX+Fc1eZmZhZhvuYiv6kH1IOhUOIDZEMY=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=V8wpRvDglveMfO2QoRRvIIw6GOdLT7mmWlPam8E1UmMgMiTNSE3++zgPNwsXzhuRh
	 cHh5Pp42zAElY3TvKabPU7J8B4QH1avIfukDTYSmv+SEzn1l1RfGXW502ZFwp6CApp
	 eq5MIhEjcIwsX3qFcn07LfFf2nRtbjP0UrunwnvRJAV2TI8/mUE5w8ZVwoIOwyV0O0
	 DP2QluFcABzhTW8K5cZ+zAd6lTs7yKVCTK/BPmsTtdSl2zWvIA84y5yidjzRYV1GDn
	 qz2mnRwoq4hY+nXWAkjVAehtAF4qHCwf0Za+9fBqvgleQJQ8ToKGPgQ8JSV+Dre/U/
	 TADL15VEQyuYQ==
Date: Mon, 23 Jun 2025 18:19:42 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Stefano Stabellini , 
    Nicola Vetrini , 
    xen-devel@lists.xenproject.org, Andrew Cooper , 
    Stefano Stabellini , michal.orzel@amd.com, 
    julien@xen.org, roger.pau@citrix.com, bertrand.marquis@arm.com, 
    federico.serafini@bugseng.com
Subject: Re: [PATCH v5] automation/eclair: update configuration of D4.10
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 Mon, 23 Jun 2025, Jan Beulich wrote:
> On 22.06.2025 22:58, Stefano Stabellini wrote:
> > On Sun, 22 Jun 2025, Nicola Vetrini wrote:
> >> On 2025-06-21 04:19, Stefano Stabellini wrote:
> >>> --- a/xen/arch/x86/include/asm/cpufeatures.h
> >>> +++ b/xen/arch/x86/include/asm/cpufeatures.h
> >>> @@ -1,6 +1,6 @@
> >>> -/*
> >>> - * Explicitly intended for multiple inclusion.
> >>> - */
> >>> +/* This file is intended to be included multiple times. */
> >>> +/* #ifndef X86_CPUFEATURES_H */
> >>> +/* #define X86_CPUFEATURES_H */
> >>>
> >>
> >> Are these two lines really needed? I may be mistaken, but I think the
> >> violation's first location would be the #include below with a comment a couple
> >> of lines above captured by the config at the top [1]. @Federico thoughts?
> > 
> > Without these 2 lines, ECLAIR complains about the following:
> > 
> > #include 
> >        ^
> >  MC3A2.D4.10non-compliant start of header file
> 
> And that's where hence a SAF-8 comment cold be placed, I would think.

You are right, I tried it and it works


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 01:19:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 01:19:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022887.1398743 (Exim 4.92)
	(envelope-from )
	id 1uTsK2-0003pf-VF; Tue, 24 Jun 2025 01:19:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022887.1398743; Tue, 24 Jun 2025 01:19:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTsK2-0003pY-Si; Tue, 24 Jun 2025 01:19:38 +0000
Received: by outflank-mailman (input) for mailman id 1022887;
 Tue, 24 Jun 2025 01:19:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uTsK1-0003pS-QO
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 01:19:37 +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 47f52eee-5099-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 03:19:32 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 503D75C58EF;
 Tue, 24 Jun 2025 01:17:14 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 22030C4CEEA;
 Tue, 24 Jun 2025 01:19:29 +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: 47f52eee-5099-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1750727970;
	bh=H2NzpB9T6zopmrvfQu3ZhSnewVqp8QgCwnhKlfRNEA8=;
	h=Date:From:To:cc:Subject:From;
	b=iA7rDorrz581RR5U1VKVgyW67Yqir+g42APsjWifQQgWBYOzv+HDOZZkRz//Z7KoL
	 F792YHAIsY2CEFjEub0gnIRAEFjv/V6LITIRx6tAWW5WqlwZKcX+iwBDg0qhGz1Jrv
	 dr01vP/ZtrcqPVer6kq3mKqymVvM+SgNL5Kdi9wz5yIJ3AZb1ZHSY1zL7JF5AcplsH
	 cY+CfIwkjYASt3+W526KRjo7aRxifqIS7ldNdHqhX7jbz9QVmNOEqB5sVrYMELpf+v
	 G2FaNMWx/vY2t3rPTCP7lk1jX2AT0r3N5quj3n+GKMxrBYxaSWdlw80OemGQKno2dj
	 a4tgryreXmjGw==
Date: Mon, 23 Jun 2025 18:19:27 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: xen-devel@lists.xenproject.org
cc: Andrew Cooper , michal.orzel@amd.com, 
    jbeulich@suse.com, julien@xen.org, roger.pau@citrix.com, 
    sstabellini@kernel.org, bertrand.marquis@arm.com, 
    federico.serafini@bugseng.com, Nicola Vetrini , 
    sstabellini@kernel.org
Subject: [PATCH v6] automation/eclair: update configuration of D4.10
Message-ID: 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

MISRA C Directive 4.10 states that "Precautions shall be taken in order
to prevent the contents of a header file being included more than
once".

Add a SAF tag and update the comment on top of cpufeatures.h.
Add a header inclusion guard to compile.h.
Generate header guards for hypercall-defs.h

Update ECLAIR configuration to:
- extend existing deviation to other comments explicitly saying a file
  is intended for multiple inclusion;
- extend existing deviation to other autogenerated files;
- tag the guidelines as clean.

Update deviations.rst accordingly.

Signed-off-by: Federico Serafini 
Signed-off-by: Stefano Stabellini 
---
Changes in v6:
- remove in-code comment and use SAF-8-safe instead
- add header guards for hypercall-defs.h

Successful pipeline:
https://gitlab.com/xen-project/people/sstabellini/xen/-/pipelines/1885561040
---

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index 9c67358d46..3b5bc87e1d 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -72,11 +72,14 @@ they are not instances of commented-out code."
 -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."
+-doc_begin="Files that are intended to be included more than once (and have
+a comment that says this explicitly) do not need to conform to the directive."
 -config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* This file is intended to be 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$)))"}
+-config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* Generated file, do not edit! \\*/$, begin-3...begin-2))"}
+-doc_end
+
+-doc_begin="Autogenerated files that do not need to conform to the directive."
+-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
diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl b/automation/eclair_analysis/ECLAIR/tagging.ecl
index f9da5d5f4d..b95f07feb0 100644
--- a/automation/eclair_analysis/ECLAIR/tagging.ecl
+++ b/automation/eclair_analysis/ECLAIR/tagging.ecl
@@ -23,6 +23,7 @@
 "MC3A2.D1.1||
 MC3A2.D2.1||
 MC3A2.D4.1||
+MC3A2.D4.10||
 MC3A2.D4.11||
 MC3A2.D4.14||
 MC3A2.R1.1||
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index fe0b1e10a2..63caa8f4a2 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -30,6 +30,18 @@ Deviations related to MISRA C:2012 Directives:
        not to add an additional encapsulation layer.
      - Tagged as `deliberate` for ECLAIR.
 
+   * - D4.10
+     - Files that are intended to be included more than once (and have
+       a comment that says this explicitly) do not need to conform to the
+       directive.
+     - Tagged as `safe` for ECLAIR.
+
+   * - D4.10
+     - There are autogenerated files that do not need to comply to the
+       directive.
+     - Tagged as `safe` for ECLAIR. Such files are:
+        - xen/include/generated/autoconf.h
+
    * - D4.10
      - Including multiple times a .c file is safe because every function or data item
        it defines would in (the common case) be already defined.
diff --git a/xen/arch/x86/include/asm/cpufeatures.h b/xen/arch/x86/include/asm/cpufeatures.h
index 9e3ed21c02..dce0713adf 100644
--- a/xen/arch/x86/include/asm/cpufeatures.h
+++ b/xen/arch/x86/include/asm/cpufeatures.h
@@ -1,7 +1,6 @@
-/*
- * Explicitly intended for multiple inclusion.
- */
+/* This file is intended to be included multiple times. */
 
+/* SAF-8-safe */
 #include 
 
 /* Number of capability words covered by the featureset words. */
diff --git a/xen/include/xen/compile.h.in b/xen/include/xen/compile.h.in
index 3151d1e7d1..9206341ba6 100644
--- a/xen/include/xen/compile.h.in
+++ b/xen/include/xen/compile.h.in
@@ -1,3 +1,6 @@
+#ifndef XEN_COMPILE_H
+#define XEN_COMPILE_H
+
 #define XEN_COMPILE_DATE	"@@date@@"
 #define XEN_COMPILE_TIME	"@@time@@"
 #define XEN_COMPILE_BY		"@@whoami@@"
diff --git a/xen/scripts/gen_hypercall.awk b/xen/scripts/gen_hypercall.awk
index 1a7e051fde..47a18cd75e 100644
--- a/xen/scripts/gen_hypercall.awk
+++ b/xen/scripts/gen_hypercall.awk
@@ -2,6 +2,8 @@
 # the calls of the handlers inside a switch() statement.
 
 BEGIN {
+    printf("#ifndef XEN_HYPERCALL_DEFS_H\n");
+    printf("#define XEN_HYPERCALL_DEFS_H\n\n");
     printf("/* Generated file, do not edit! */\n\n");
     e = 0;
     n = 0;
@@ -311,4 +313,5 @@ END {
                 printf("[__HYPERVISOR_%s] = %d, \\\n", fn[call_fn[i]], n_args[call_fn[i]]);
         printf("}\n");
     }
+    printf("\n#endif /* XEN_HYPERCALL_DEFS_H */\n");
 }
diff --git a/xen/tools/process-banner.sed b/xen/tools/process-banner.sed
index 56c76558bc..4cf3f9a116 100755
--- a/xen/tools/process-banner.sed
+++ b/xen/tools/process-banner.sed
@@ -12,3 +12,8 @@ s_(.*)_"\1\\n"_
 
 # Trailing \ on all but the final line.
 $!s_$_ \\_
+
+# Append closing header guard
+$a\
+\
+#endif /* XEN_COMPILE_H */


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 03:55:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 03:55:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022909.1398773 (Exim 4.92)
	(envelope-from )
	id 1uTuke-0006JI-Ef; Tue, 24 Jun 2025 03:55:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022909.1398773; Tue, 24 Jun 2025 03: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 1uTuke-0006JB-Bo; Tue, 24 Jun 2025 03:55:16 +0000
Received: by outflank-mailman (input) for mailman id 1022909;
 Tue, 24 Jun 2025 03:55: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 1uTukc-0006IZ-NT
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 03:55:14 +0000
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 065924b8-50af-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 05:55:11 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 065924b8-50af-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1750737309; x=1750996509;
	bh=yCudMdFYgoXw08jE2y4zALqq0ZHl0jnLUlz0092mkm0=;
	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;
	b=AENORXkaGdRBMqyIDZm2j2Lx0HCUTLgil2vFuaRYeGKBW/udVYVvpUPY0HMHskM1Z
	 s5Y+IsudnMkiJJOppGB8eDrpfBrPNgCGCM910oiprpKZcEpTx7B9qfI6r4efMJaAlH
	 cJfbBJwNlwj/0fn+WsGqHwncS1vnzRFTQiny3jl5RsB/k+YqQJU/wAPbBXqyB6ho+J
	 oYugEYX1efulWDlpRM10GZSXVpMYIlNCQ9QALVBKCx0nnHjWYxYfAvV9QZu2YEXe3L
	 wm/zBqhMBbwq90XBsp0BJF7eL9Q2Xmn65TUtyGO0TAaJRpGXguP/G2QunjQVQAQRZp
	 4poMtcJYlb5ww==
Date: Tue, 24 Jun 2025 03:55:04 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, oleksii.kurochko@gmail.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v1 01/16] arm/vpl011: rename virtual PL011 Kconfig option
Message-ID: <20250624035443.344099-2-dmukhin@ford.com>
In-Reply-To: <20250624035443.344099-1-dmukhin@ford.com>
References: <20250624035443.344099-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: e843f1976d3f637ab52c7c2c4788aa3930d7bf95
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin =20

Rename CONFIG_SBSA_VUART_CONSOLE to CONFIG_HAS_VUART_PL011.

No functional change.

Signed-off-by: Denis Mukhin 
---
 xen/arch/arm/Kconfig                  | 2 +-
 xen/arch/arm/Makefile                 | 2 +-
 xen/arch/arm/configs/tiny64_defconfig | 2 +-
 xen/arch/arm/dom0less-build.c         | 4 ++--
 xen/arch/arm/include/asm/domain.h     | 2 +-
 xen/arch/arm/include/asm/vpl011.h     | 2 +-
 xen/drivers/char/console.c            | 4 ++--
 7 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 3f25da3ca5fd..03888569f38c 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -170,7 +170,7 @@ config NEW_VGIC
 =09problems with the standard emulation.
 =09At the moment this implementation is not security supported.
=20
-config SBSA_VUART_CONSOLE
+config HAS_VUART_PL011
 =09bool "Emulated SBSA UART console support"
 =09default y
 =09help
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index ab0a0c2be6d8..2d6787fb03bc 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -65,7 +65,7 @@ obj-$(CONFIG_HAS_ITS) +=3D vgic-v3-its.o
 endif
 obj-$(CONFIG_VM_EVENT) +=3D vm_event.o
 obj-y +=3D vtimer.o
-obj-$(CONFIG_SBSA_VUART_CONSOLE) +=3D vpl011.o
+obj-$(CONFIG_HAS_VUART_PL011) +=3D vpl011.o
 obj-y +=3D vsmc.o
 obj-y +=3D vpsci.o
 obj-$(CONFIG_HWDOM_VUART) +=3D vuart.o
diff --git a/xen/arch/arm/configs/tiny64_defconfig b/xen/arch/arm/configs/t=
iny64_defconfig
index 469a1eb9f99d..acc227262d81 100644
--- a/xen/arch/arm/configs/tiny64_defconfig
+++ b/xen/arch/arm/configs/tiny64_defconfig
@@ -6,7 +6,7 @@ CONFIG_ARM=3Dy
 #
 # CONFIG_GICV3 is not set
 # CONFIG_VM_EVENT is not set
-# CONFIG_SBSA_VUART_CONSOLE is not set
+# CONFIG_HAS_VUART_PL011 is not set
=20
 #
 # Common Features
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index 4b285cff5ee2..2a5531a2b892 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -167,7 +167,7 @@ int __init make_intc_domU_node(struct kernel_info *kinf=
o)
     }
 }
=20
-#ifdef CONFIG_SBSA_VUART_CONSOLE
+#ifdef CONFIG_HAS_VUART_PL011
 static int __init make_vpl011_uart_node(struct kernel_info *kinfo)
 {
     void *fdt =3D kinfo->fdt;
@@ -226,7 +226,7 @@ int __init make_arch_nodes(struct kernel_info *kinfo)
=20
     if ( kinfo->arch.vpl011 )
     {
-#ifdef CONFIG_SBSA_VUART_CONSOLE
+#ifdef CONFIG_HAS_VUART_PL011
         ret =3D make_vpl011_uart_node(kinfo);
 #endif
         if ( ret )
diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/d=
omain.h
index a3487ca71303..746ea687d523 100644
--- a/xen/arch/arm/include/asm/domain.h
+++ b/xen/arch/arm/include/asm/domain.h
@@ -113,7 +113,7 @@ struct arch_domain
         uint8_t privileged_call_enabled : 1;
     } monitor;
=20
-#ifdef CONFIG_SBSA_VUART_CONSOLE
+#ifdef CONFIG_HAS_VUART_PL011
     struct vpl011 vpl011;
 #endif
=20
diff --git a/xen/arch/arm/include/asm/vpl011.h b/xen/arch/arm/include/asm/v=
pl011.h
index cc838682815c..be64883b8628 100644
--- a/xen/arch/arm/include/asm/vpl011.h
+++ b/xen/arch/arm/include/asm/vpl011.h
@@ -65,7 +65,7 @@ struct vpl011_init_info {
     evtchn_port_t evtchn;
 };
=20
-#ifdef CONFIG_SBSA_VUART_CONSOLE
+#ifdef CONFIG_HAS_VUART_PL011
 int domain_vpl011_init(struct domain *d,
                        struct vpl011_init_info *info);
 void domain_vpl011_deinit(struct domain *d);
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 5879e31786ba..0f37badc471e 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -37,7 +37,7 @@
 #ifdef CONFIG_X86
 #include 
 #endif
-#ifdef CONFIG_SBSA_VUART_CONSOLE
+#ifdef CONFIG_HAS_VUART_PL011
 #include 
 #endif
=20
@@ -606,7 +606,7 @@ static void __serial_rx(char c)
          */
         send_global_virq(VIRQ_CONSOLE);
     }
-#ifdef CONFIG_SBSA_VUART_CONSOLE
+#ifdef CONFIG_HAS_VUART_PL011
     else
         /* Deliver input to the emulated UART. */
         rc =3D vpl011_rx_char_xen(d, c);
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Tue Jun 24 03:55:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 03:55:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022908.1398764 (Exim 4.92)
	(envelope-from )
	id 1uTukU-00063M-8l; Tue, 24 Jun 2025 03:55:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022908.1398764; Tue, 24 Jun 2025 03:55: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 1uTukU-00063F-5N; Tue, 24 Jun 2025 03:55:06 +0000
Received: by outflank-mailman (input) for mailman id 1022908;
 Tue, 24 Jun 2025 03:55: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 1uTukS-000639-7n
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 03:55:05 +0000
Received: from mail-24416.protonmail.ch (mail-24416.protonmail.ch
 [109.224.244.16]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0062b6e7-50af-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 05:55:00 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0062b6e7-50af-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1750737299; x=1750996499;
	bh=kgm/ahmSt27FsPZowTug9QzPxVkvQcKb8PSoXe1OzuQ=;
	h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
	 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector;
	b=QxNEF7NarjQXhtoqwNIn/Gs4wjVTusx3nDB4GqHDHUkgJldgkd+J6/qrFWprlTjTp
	 TXlfYyA4ekY/rrLaBh/+dhDLTmXf9ZeXdeIIcP8oT8WexyXmr3CbAwuUO7d3kiH2Sa
	 okZbQ6ifganzPBOVix27XFwZbECOEsuvTaq+SiOe1jlqK/OWHbwjuLzgZVgzN2vEwj
	 Y6U09KdP4sUgqDRKdiI3V1z/w8Fy/Sw9CFknxw58W0BmOAU7cLLgUcsoE296E4ZYYu
	 eMUv36gPHrOlR0HE+nQI+fCDmd/onJKfqjCPr2EYVpKHMjTlDgd4RvUTC5LCUd4T5O
	 P7zc0aBzxRspg==
Date: Tue, 24 Jun 2025 03:54:54 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, oleksii.kurochko@gmail.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v1 00/16] xen: framework for UART emulators
Message-ID: <20250624035443.344099-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 1f3322f86847b85be4792570abbb73b99c01e441
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

The series introduces a driver framework to abstract UART emulators in the
hypervisor under drivers/vuart.

That allows for architecture-independent handling of virtual UARTs in the
console driver and simplifies enabling new UART emulators.

The framework is gated by CONFIG_HAS_VUART, which is automatically enabled
once the user enables any UART emulator.

Current implementation supports maximum of one vUART of each kind per domai=
n.

All current UART emulators (Arm) are switched to the new framework.

This works origins from [1].

Conceptually, there are 3 parts in the series:
- PL011 emulator cleanup: patches 1-6
- Simple MMIO-based UART emulator cleanup: patches 7-10, depends on the com=
mon
  header introduced in vpl011 cleanup
- vUART driver framework: patches 11-16, depends on the cleanup part

[1] https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v1-0-c5d36b3=
1d66c@ford.com/
[2] CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/18856=
41957

Denis Mukhin (16):
  arm/vpl011: rename virtual PL011 Kconfig option
  arm/vpl011: move DT node parsing to PL011 emulator code
  arm/vpl011: use vuart_ prefix in vpl011 public calls
  arm/vpl011: use raw spin_lock_{irqrestore,irqsave}
  arm/vpl011: use void pointer in domain struct
  arm/vpl011: remove vpl011 header file
  arm/vuart: rename 'virtual UART' Kconfig option
  arm/vuart: move simple MMIO-based vUART declarations to common header
  arm/vuart: use void pointer in domain struct
  arm/vuart: merge vuart_print_char() with vuart_mmio_write()
  xen/domain: introduce common emulation flags
  xen/domain: introduce domain-emu.h
  drivers/vuart: move PL011 emulator code
  drivers/vuart: move simple MMIO-based UART emulator
  drivers/vuart: introduce framework for UART emulators
  drivers/vuart: hook simple MMIO-based UART to vUART framework

 xen/arch/arm/Kconfig                          |  15 -
 xen/arch/arm/Makefile                         |   2 -
 xen/arch/arm/configs/tiny64_defconfig         |   2 +-
 xen/arch/arm/dom0less-build.c                 |  76 +---
 xen/arch/arm/domain.c                         |  11 +-
 xen/arch/arm/domctl.c                         |  15 +-
 xen/arch/arm/include/asm/domain.h             |  20 +-
 xen/arch/arm/include/asm/kernel.h             |   3 -
 xen/arch/arm/include/asm/vpl011.h             |  91 -----
 xen/arch/arm/vuart.c                          | 139 -------
 xen/arch/arm/vuart.h                          |  54 ---
 xen/arch/arm/xen.lds.S                        |   1 +
 xen/arch/ppc/include/asm/domain.h             |   1 +
 xen/arch/ppc/xen.lds.S                        |   1 +
 xen/arch/riscv/include/asm/domain.h           |   1 +
 xen/arch/riscv/xen.lds.S                      |   1 +
 xen/arch/x86/domain.c                         |   2 +-
 xen/arch/x86/domctl.c                         |   2 +-
 xen/arch/x86/include/asm/domain.h             |  48 ++-
 xen/arch/x86/xen.lds.S                        |   1 +
 xen/common/domain.c                           |  13 +
 xen/common/keyhandler.c                       |   4 +
 xen/drivers/Kconfig                           |   2 +
 xen/drivers/Makefile                          |   1 +
 xen/drivers/char/console.c                    |  11 +-
 xen/drivers/vuart/Kconfig                     |  23 ++
 xen/drivers/vuart/Makefile                    |   3 +
 xen/drivers/vuart/vuart-mmio.c                | 189 ++++++++++
 .../vpl011.c =3D> drivers/vuart/vuart-pl011.c}  | 347 +++++++++++++-----
 xen/drivers/vuart/vuart.c                     |  95 +++++
 xen/include/xen/domain-emu.h                  |  33 ++
 xen/include/xen/domain.h                      |   2 +
 xen/include/xen/sched.h                       |   2 +
 xen/include/xen/vuart.h                       |  72 ++++
 xen/include/xen/xen.lds.h                     |  10 +
 35 files changed, 771 insertions(+), 522 deletions(-)
 delete mode 100644 xen/arch/arm/include/asm/vpl011.h
 delete mode 100644 xen/arch/arm/vuart.c
 delete mode 100644 xen/arch/arm/vuart.h
 create mode 100644 xen/drivers/vuart/Kconfig
 create mode 100644 xen/drivers/vuart/Makefile
 create mode 100644 xen/drivers/vuart/vuart-mmio.c
 rename xen/{arch/arm/vpl011.c =3D> drivers/vuart/vuart-pl011.c} (71%)
 create mode 100644 xen/drivers/vuart/vuart.c
 create mode 100644 xen/include/xen/domain-emu.h
 create mode 100644 xen/include/xen/vuart.h

--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Tue Jun 24 03:55:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 03:55:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022910.1398783 (Exim 4.92)
	(envelope-from )
	id 1uTukk-0006as-Lc; Tue, 24 Jun 2025 03:55:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022910.1398783; Tue, 24 Jun 2025 03:55: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 1uTukk-0006al-Ic; Tue, 24 Jun 2025 03:55:22 +0000
Received: by outflank-mailman (input) for mailman id 1022910;
 Tue, 24 Jun 2025 03:55: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 1uTukj-000639-9F
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 03:55:21 +0000
Received: from mail-10630.protonmail.ch (mail-10630.protonmail.ch
 [79.135.106.30]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0bab80d8-50af-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 05:55:19 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0bab80d8-50af-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1750737317; x=1750996517;
	bh=fU+A+CPMQ76T5nM/3fv4rEH7OqjnjtaOzr8CFYG64PM=;
	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;
	b=a7w3v6wpxPr5LAgXe7c9kHpVKcAvzPEezqByuvtPqrQtTcVfV8JH/y+a3PmDOyKY2
	 /IGKgkhq6C+hdTiTb6ti4n92Soa/iw7uzkT3rNQv2VZ9UEwBFbjnzAbpNqKQcNhvzJ
	 GnWOgLpNrCeGWMPU50UbkUsePQYKCCJmwi/LDPWFwsN+AoLTDUOxo5/ziIQI3I2C0S
	 fR86bYc7leg2w9/zIDhqE3oF/7IghHcCsak0zPWgzuX2vUXKms0t/Ut5xy1iou8dFB
	 ap7OCeeUdLRI/JRRz0hd5qnz98v/waBJk3uSAwjhPUHAnmRqHz9+Nj/xfo/sN5RGG5
	 G5pKkHlZSg8Pw==
Date: Tue, 24 Jun 2025 03:55:12 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, oleksii.kurochko@gmail.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v1 02/16] arm/vpl011: move DT node parsing to PL011 emulator code
Message-ID: <20250624035443.344099-3-dmukhin@ford.com>
In-Reply-To: <20250624035443.344099-1-dmukhin@ford.com>
References: <20250624035443.344099-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 0cd9e5aac8ded32fc4e555ba40515db5f5c24244
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin =20

Move vpl011 DT node parsing from common Arm code to PL011 emulator code.

While doing it pick the generic name vuart_add_fwnode() for DT parser funct=
ion
and place the declaration in the common header in include/xen/vuart.h.

No functional change.

Signed-off-by: Denis Mukhin 
---
 xen/arch/arm/dom0less-build.c | 52 ++---------------------------------
 xen/arch/arm/vpl011.c         | 52 +++++++++++++++++++++++++++++++++++
 xen/include/xen/vuart.h       | 23 ++++++++++++++++
 3 files changed, 77 insertions(+), 50 deletions(-)
 create mode 100644 xen/include/xen/vuart.h

diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index 2a5531a2b892..7c1b59750fb5 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
=20
 #include 
 #include 
@@ -167,55 +168,6 @@ int __init make_intc_domU_node(struct kernel_info *kin=
fo)
     }
 }
=20
-#ifdef CONFIG_HAS_VUART_PL011
-static int __init make_vpl011_uart_node(struct kernel_info *kinfo)
-{
-    void *fdt =3D kinfo->fdt;
-    int res;
-    gic_interrupt_t intr;
-    __be32 reg[GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS];
-    __be32 *cells;
-    struct domain *d =3D kinfo->d;
-
-    res =3D domain_fdt_begin_node(fdt, "sbsa-uart", d->arch.vpl011.base_ad=
dr);
-    if ( res )
-        return res;
-
-    res =3D fdt_property_string(fdt, "compatible", "arm,sbsa-uart");
-    if ( res )
-        return res;
-
-    cells =3D ®[0];
-    dt_child_set_range(&cells, GUEST_ROOT_ADDRESS_CELLS,
-                       GUEST_ROOT_SIZE_CELLS, d->arch.vpl011.base_addr,
-                       GUEST_PL011_SIZE);
-
-    res =3D fdt_property(fdt, "reg", reg, sizeof(reg));
-    if ( res )
-        return res;
-
-    set_interrupt(intr, d->arch.vpl011.virq, 0xf, DT_IRQ_TYPE_LEVEL_HIGH);
-
-    res =3D fdt_property(fdt, "interrupts", intr, sizeof (intr));
-    if ( res )
-        return res;
-
-    res =3D fdt_property_cell(fdt, "interrupt-parent",
-                            kinfo->phandle_intc);
-    if ( res )
-        return res;
-
-    /* Use a default baud rate of 115200. */
-    fdt_property_u32(fdt, "current-speed", 115200);
-
-    res =3D fdt_end_node(fdt);
-    if ( res )
-        return res;
-
-    return 0;
-}
-#endif
-
 int __init make_arch_nodes(struct kernel_info *kinfo)
 {
     int ret;
@@ -227,7 +179,7 @@ int __init make_arch_nodes(struct kernel_info *kinfo)
     if ( kinfo->arch.vpl011 )
     {
 #ifdef CONFIG_HAS_VUART_PL011
-        ret =3D make_vpl011_uart_node(kinfo);
+        ret =3D vuart_add_fwnode(kinfo->d, kinfo);
 #endif
         if ( ret )
             return -EINVAL;
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 480fc664fc62..cafc532cf028 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -12,15 +12,20 @@
=20
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -784,6 +789,53 @@ void domain_vpl011_deinit(struct domain *d)
         XFREE(vpl011->backend.xen);
 }
=20
+int __init vuart_add_fwnode(struct domain *d, void *node)
+{
+    struct kernel_info *kinfo =3D node;
+    void *fdt =3D kinfo->fdt;
+    int res;
+    gic_interrupt_t intr;
+    __be32 reg[GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS];
+    __be32 *cells;
+
+    res =3D domain_fdt_begin_node(fdt, "sbsa-uart", d->arch.vpl011.base_ad=
dr);
+    if ( res )
+        return res;
+
+    res =3D fdt_property_string(fdt, "compatible", "arm,sbsa-uart");
+    if ( res )
+        return res;
+
+    cells =3D ®[0];
+    dt_child_set_range(&cells, GUEST_ROOT_ADDRESS_CELLS,
+                       GUEST_ROOT_SIZE_CELLS, d->arch.vpl011.base_addr,
+                       GUEST_PL011_SIZE);
+
+    res =3D fdt_property(fdt, "reg", reg, sizeof(reg));
+    if ( res )
+        return res;
+
+    set_interrupt(intr, d->arch.vpl011.virq, 0xf, DT_IRQ_TYPE_LEVEL_HIGH);
+
+    res =3D fdt_property(fdt, "interrupts", intr, sizeof (intr));
+    if ( res )
+        return res;
+
+    res =3D fdt_property_cell(fdt, "interrupt-parent",
+                            kinfo->phandle_intc);
+    if ( res )
+        return res;
+
+    /* Use a default baud rate of 115200. */
+    fdt_property_u32(fdt, "current-speed", 115200);
+
+    res =3D fdt_end_node(fdt);
+    if ( res )
+        return res;
+
+    return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/vuart.h b/xen/include/xen/vuart.h
new file mode 100644
index 000000000000..bb883823ea31
--- /dev/null
+++ b/xen/include/xen/vuart.h
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef XEN_VUART_H
+#define XEN_VUART_H
+
+#ifdef CONFIG_HAS_VUART_PL011
+int __init vuart_add_fwnode(struct domain *d, void *node);
+#else
+static inline int __init vuart_add_fwnode(struct domain *d, void *node)
+{
+    return 0;
+}
+#endif
+
+#endif /* XEN_VUART_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Tue Jun 24 03:55:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 03:55:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022915.1398793 (Exim 4.92)
	(envelope-from )
	id 1uTukv-00077T-3w; Tue, 24 Jun 2025 03:55:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022915.1398793; Tue, 24 Jun 2025 03: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 1uTukv-00077K-0j; Tue, 24 Jun 2025 03:55:33 +0000
Received: by outflank-mailman (input) for mailman id 1022915;
 Tue, 24 Jun 2025 03: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 1uTuku-000639-8e
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 03:55:32 +0000
Received: from mail-24417.protonmail.ch (mail-24417.protonmail.ch
 [109.224.244.17]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 107216de-50af-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 05:55:27 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 107216de-50af-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=7g7ds4sgnbbihb27j7qq7z4iwq.protonmail; t=1750737326; x=1750996526;
	bh=dPqyJU0mYRSIBJYCmrPsH7iYJx5buk1sy890qmF0Tmw=;
	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;
	b=dvpyMqsUZLPINvEcjflIliFXuDqRJcrcIFmcNj3RMVV7DuwyIOwnnu+Z/rOMJEKN4
	 b8rTXJ/TJaNkSuXk6TaogyMTjh8AxSzl6pLTnfQGZs4ToQKkwpTLk79ii5kk64asWW
	 3ekwlv4wz33ItTBn26fwejLk/lDSIkxjOcWOoIFL/r4ds7YE48TJFobUXL59sKQeQc
	 NYg3UzzFbcVEf5C2kvg9KWUuCqdNjqcWRGzNcm0kCL2zUFv4nDVAc22nu+QSvwNONK
	 JxcjhvegN+K6ud4KKrwXHstZfH9ahuRJv5aAC6Wl44bAZWM1JPWPRKKGa04kX+v1Gf
	 cr5PkBy9rQqpQ==
Date: Tue, 24 Jun 2025 03:55:22 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, oleksii.kurochko@gmail.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v1 03/16] arm/vpl011: use vuart_ prefix in vpl011 public calls
Message-ID: <20250624035443.344099-4-dmukhin@ford.com>
In-Reply-To: <20250624035443.344099-1-dmukhin@ford.com>
References: <20250624035443.344099-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 3253eba4e882246fd04bbb7112b4eac0d3f069ba
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin =20

Use generic names prefixed with 'vuart_' in public PL011 emulator data
structures and functions.

No functional change intended.

Signed-off-by: Denis Mukhin 
---
 xen/arch/arm/dom0less-build.c     |  4 ++--
 xen/arch/arm/domain.c             |  3 ++-
 xen/arch/arm/domctl.c             | 14 +++++++------
 xen/arch/arm/include/asm/vpl011.h | 20 ------------------
 xen/arch/arm/vpl011.c             | 24 +++++++++++-----------
 xen/drivers/char/console.c        |  6 ++----
 xen/include/xen/vuart.h           | 34 ++++++++++++++++++++++++++++++-
 7 files changed, 59 insertions(+), 46 deletions(-)

diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index 7c1b59750fb5..11b8498d3b22 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -216,7 +216,7 @@ int __init init_vuart(struct domain *d, struct kernel_i=
nfo *kinfo,
      */
     if ( kinfo->arch.vpl011 )
     {
-        rc =3D domain_vpl011_init(d, NULL);
+        rc =3D vuart_init(d, NULL);
         if ( rc < 0 )
             return rc;
     }
@@ -247,7 +247,7 @@ void __init arch_create_domUs(struct dt_device_node *no=
de,
          * d->arch.vpl011.irq. So the logic to find the vIRQ has to
          * be hardcoded.
          * The logic here shall be consistent with the one in
-         * domain_vpl011_init().
+         * vuart_init().
          */
         if ( flags & CDF_directmap )
         {
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index be58a23dd725..68297e619bad 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
=20
 #include 
 #include 
@@ -1072,7 +1073,7 @@ int domain_relinquish_resources(struct domain *d)
          * Release the resources allocated for vpl011 which were
          * allocated via a DOMCTL call XEN_DOMCTL_vuart_op.
          */
-        domain_vpl011_deinit(d);
+        vuart_exit(d);
=20
 #ifdef CONFIG_IOREQ_SERVER
         ioreq_server_destroy_all(d);
diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index ad914c915f81..dde25ceff6d0 100644
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
=20
@@ -30,10 +31,11 @@ static int handle_vuart_init(struct domain *d,
                              struct xen_domctl_vuart_op *vuart_op)
 {
     int rc;
-    struct vpl011_init_info info;
-
-    info.console_domid =3D vuart_op->console_domid;
-    info.gfn =3D _gfn(vuart_op->gfn);
+    struct vuart_params params =3D {
+        .console_domid =3D vuart_op->console_domid,
+        .gfn =3D _gfn(vuart_op->gfn),
+        .evtchn =3D 0,
+    };
=20
     if ( d->creation_finished )
         return -EPERM;
@@ -41,10 +43,10 @@ static int handle_vuart_init(struct domain *d,
     if ( vuart_op->type !=3D XEN_DOMCTL_VUART_TYPE_VPL011 )
         return -EOPNOTSUPP;
=20
-    rc =3D domain_vpl011_init(d, &info);
+    rc =3D vuart_init(d, ¶ms);
=20
     if ( !rc )
-        vuart_op->evtchn =3D info.evtchn;
+        vuart_op->evtchn =3D params.evtchn;
=20
     return rc;
 }
diff --git a/xen/arch/arm/include/asm/vpl011.h b/xen/arch/arm/include/asm/v=
pl011.h
index be64883b8628..5c308cc8c148 100644
--- a/xen/arch/arm/include/asm/vpl011.h
+++ b/xen/arch/arm/include/asm/vpl011.h
@@ -59,26 +59,6 @@ struct vpl011 {
     evtchn_port_t evtchn;
 };
=20
-struct vpl011_init_info {
-    domid_t console_domid;
-    gfn_t gfn;
-    evtchn_port_t evtchn;
-};
-
-#ifdef CONFIG_HAS_VUART_PL011
-int domain_vpl011_init(struct domain *d,
-                       struct vpl011_init_info *info);
-void domain_vpl011_deinit(struct domain *d);
-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)
-{
-    return -ENOSYS;
-}
-
-static inline void domain_vpl011_deinit(struct domain *d) { }
-#endif
 #endif  /* _VPL011_H_ */
=20
 /*
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index cafc532cf028..2cf88a70ecdb 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -134,7 +134,7 @@ static void vpl011_write_data_xen(struct domain *d, uin=
t8_t data)
=20
 /*
  * vpl011_read_data_xen reads data when the backend is xen. Characters
- * are added to the vpl011 receive buffer by vpl011_rx_char_xen.
+ * are added to the vpl011 receive buffer by vuart_putchar.
  */
 static uint8_t vpl011_read_data_xen(struct domain *d)
 {
@@ -571,9 +571,9 @@ static void vpl011_data_avail(struct domain *d,
 }
=20
 /*
- * vpl011_rx_char_xen adds a char to a domain's vpl011 receive buffer.
+ * vuart_putchar adds a char to a domain's vpl011 receive buffer.
  */
-int vpl011_rx_char_xen(struct domain *d, char c)
+int vuart_putchar(struct domain *d, char c)
 {
     unsigned long flags;
     struct vpl011 *vpl011 =3D &d->arch.vpl011;
@@ -642,7 +642,7 @@ static void vpl011_notification(struct vcpu *v, unsigne=
d int port)
     VPL011_UNLOCK(d, flags);
 }
=20
-int domain_vpl011_init(struct domain *d, struct vpl011_init_info *info)
+int vuart_init(struct domain *d, struct vuart_params *params)
 {
     int rc;
     struct vpl011 *vpl011 =3D &d->arch.vpl011;
@@ -694,27 +694,27 @@ int domain_vpl011_init(struct domain *d, struct vpl01=
1_init_info *info)
     }
=20
     /*
-     * info is NULL when the backend is in Xen.
-     * info is !=3D NULL when the backend is in a domain.
+     * params is NULL when the backend is in Xen.
+     * params is !=3D NULL when the backend is in a domain.
      */
-    if ( info !=3D NULL )
+    if ( params !=3D NULL )
     {
         vpl011->backend_in_domain =3D true;
=20
         /* Map the guest PFN to Xen address space. */
         rc =3D  prepare_ring_for_helper(d,
-                                      gfn_x(info->gfn),
+                                      gfn_x(params->gfn),
                                       &vpl011->backend.dom.ring_page,
                                       &vpl011->backend.dom.ring_buf);
         if ( rc < 0 )
             goto out;
=20
-        rc =3D alloc_unbound_xen_event_channel(d, 0, info->console_domid,
+        rc =3D alloc_unbound_xen_event_channel(d, 0, params->console_domid=
,
                                              vpl011_notification);
         if ( rc < 0 )
             goto out1;
=20
-        vpl011->evtchn =3D info->evtchn =3D rc;
+        vpl011->evtchn =3D params->evtchn =3D rc;
     }
     else
     {
@@ -746,13 +746,13 @@ int domain_vpl011_init(struct domain *d, struct vpl01=
1_init_info *info)
     return 0;
=20
 out1:
-    domain_vpl011_deinit(d);
+    vuart_exit(d);
=20
 out:
     return rc;
 }
=20
-void domain_vpl011_deinit(struct domain *d)
+void vuart_exit(struct domain *d)
 {
     struct vpl011 *vpl011 =3D &d->arch.vpl011;
=20
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 0f37badc471e..f322d59515ab 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -33,13 +33,11 @@
 #include 
 #include 
 #include 
+#include 
=20
 #ifdef CONFIG_X86
 #include 
 #endif
-#ifdef CONFIG_HAS_VUART_PL011
-#include 
-#endif
=20
 /* Internal console flags. */
 enum {
@@ -609,7 +607,7 @@ static void __serial_rx(char c)
 #ifdef CONFIG_HAS_VUART_PL011
     else
         /* Deliver input to the emulated UART. */
-        rc =3D vpl011_rx_char_xen(d, c);
+        rc =3D vuart_putchar(d, c);
 #endif
=20
     if ( consoled_is_enabled() )
diff --git a/xen/include/xen/vuart.h b/xen/include/xen/vuart.h
index bb883823ea31..cae72ac9c6b9 100644
--- a/xen/include/xen/vuart.h
+++ b/xen/include/xen/vuart.h
@@ -2,14 +2,46 @@
 #ifndef XEN_VUART_H
 #define XEN_VUART_H
=20
+#include 
+#include 
+#include 
+
+struct vuart_params {
+    domid_t console_domid;
+    gfn_t gfn;
+    evtchn_port_t evtchn;
+};
+
 #ifdef CONFIG_HAS_VUART_PL011
+
 int __init vuart_add_fwnode(struct domain *d, void *node);
+int vuart_init(struct domain *d, struct vuart_params *params);
+void vuart_exit(struct domain *d);
+int vuart_putchar(struct domain *d, char c);
+
 #else
+
 static inline int __init vuart_add_fwnode(struct domain *d, void *node)
 {
     return 0;
 }
-#endif
+
+static inline int vuart_init(struct domain *d, struct vuart_params *params=
)
+{
+    return 0;
+}
+
+static inline void vuart_exit(struct domain *d)
+{
+}
+
+static inline int vuart_putchar(struct domain *d, char c)
+{
+    ASSERT_UNREACHABLE();
+    return -ENODEV;
+}
+
+#endif /* CONFIG_HAS_VUART_PL011 */
=20
 #endif /* XEN_VUART_H */
=20
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Tue Jun 24 03:55:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 03:55:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022919.1398804 (Exim 4.92)
	(envelope-from )
	id 1uTul2-0007aF-Bl; Tue, 24 Jun 2025 03:55:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022919.1398804; Tue, 24 Jun 2025 03:55:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTul2-0007a8-8c; Tue, 24 Jun 2025 03:55:40 +0000
Received: by outflank-mailman (input) for mailman id 1022919;
 Tue, 24 Jun 2025 03:55: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 1uTul1-000639-Dx
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 03:55:39 +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 16912773-50af-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 05:55:37 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 16912773-50af-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=2aczlvp72nbmndnpqwlicus3vi.protonmail; t=1750737336; x=1750996536;
	bh=pr9da8QLriKGRhTHle+NhpCJzocZTv/fv9SkYEq/Fhw=;
	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;
	b=HN7U28yX6dmUEKHGm/r6clneTH6+QaKfBhDYbs05T9ULKQdU2S3jIuRiYTjoMIpff
	 zBkh/VPLe52KF7nBfZ5z0UqVCLvsfXyNY9VOw22ttyPwGtCzG965dnDXjAAwz7rUXG
	 j5xx23SMLVs0cuziGpfnDLpYzC7Cv7b/p5rcjVNTB/iGtg+3IYSZGVDoptBOIHYKDH
	 PuEqcfmtmbBPiWWF165El32XL0iJprRddQWGUnEOnsDVGBY1J8pF1rFGa/h74eWZuW
	 VdEKukowFiGjAM2HCnQQPWe0llZv//fK+BGtlRPzpfCgO2QhoPVanhpTi4xg58vI3u
	 K6nE8yBa+BpBw==
Date: Tue, 24 Jun 2025 03:55:32 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, oleksii.kurochko@gmail.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v1 04/16] arm/vpl011: use raw spin_lock_{irqrestore,irqsave}
Message-ID: <20250624035443.344099-5-dmukhin@ford.com>
In-Reply-To: <20250624035443.344099-1-dmukhin@ford.com>
References: <20250624035443.344099-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 6453bdc58832958b3427c6bbd46d5bfab2dde158
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin =20

Replace VPL011_{LOCK,UNLOCK} macros with raw spinlock calls to improve
readability.

No functional change.

Signed-off-by: Denis Mukhin 
---
 xen/arch/arm/include/asm/vpl011.h |  4 ---
 xen/arch/arm/vpl011.c             | 50 +++++++++++++++----------------
 2 files changed, 25 insertions(+), 29 deletions(-)

diff --git a/xen/arch/arm/include/asm/vpl011.h b/xen/arch/arm/include/asm/v=
pl011.h
index 5c308cc8c148..8f6ea0005e72 100644
--- a/xen/arch/arm/include/asm/vpl011.h
+++ b/xen/arch/arm/include/asm/vpl011.h
@@ -24,10 +24,6 @@
 #include 
 #include 
=20
-/* helper macros */
-#define VPL011_LOCK(d,flags) spin_lock_irqsave(&(d)->arch.vpl011.lock, fla=
gs)
-#define VPL011_UNLOCK(d,flags) spin_unlock_irqrestore(&(d)->arch.vpl011.lo=
ck, flags)
-
 #define SBSA_UART_FIFO_SIZE 32
 /* Same size as VUART_BUF_SIZE, used in vuart.c */
 #define SBSA_UART_OUT_BUF_SIZE 128
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 2cf88a70ecdb..a97c3b74208c 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -85,7 +85,7 @@ static void vpl011_write_data_xen(struct domain *d, uint8=
_t data)
     struct vpl011_xen_backend *intf =3D vpl011->backend.xen;
     struct domain *input =3D console_get_domain();
=20
-    VPL011_LOCK(d, flags);
+    spin_lock_irqsave(&vpl011->lock, flags);
=20
     intf->out[intf->out_prod++] =3D data;
     if ( d =3D=3D input )
@@ -127,7 +127,7 @@ static void vpl011_write_data_xen(struct domain *d, uin=
t8_t data)
     vpl011->uartfr |=3D TXFE;
     vpl011_update_interrupt_status(d);
=20
-    VPL011_UNLOCK(d, flags);
+    spin_unlock_irqrestore(&vpl011->lock, flags);
=20
     console_put_domain(input);
 }
@@ -144,7 +144,7 @@ static uint8_t vpl011_read_data_xen(struct domain *d)
     struct vpl011_xen_backend *intf =3D vpl011->backend.xen;
     XENCONS_RING_IDX in_cons, in_prod;
=20
-    VPL011_LOCK(d, flags);
+    spin_lock_irqsave(&vpl011->lock, flags);
=20
     in_cons =3D intf->in_cons;
     in_prod =3D intf->in_prod;
@@ -190,7 +190,7 @@ static uint8_t vpl011_read_data_xen(struct domain *d)
      */
     vpl011->uartfr &=3D ~RXFF;
=20
-    VPL011_UNLOCK(d, flags);
+    spin_unlock_irqrestore(&vpl011->lock, flags);
=20
     return data;
 }
@@ -203,7 +203,7 @@ static uint8_t vpl011_read_data(struct domain *d)
     struct xencons_interface *intf =3D vpl011->backend.dom.ring_buf;
     XENCONS_RING_IDX in_cons, in_prod;
=20
-    VPL011_LOCK(d, flags);
+    spin_lock_irqsave(&vpl011->lock, flags);
=20
     in_cons =3D intf->in_cons;
     in_prod =3D intf->in_prod;
@@ -249,7 +249,7 @@ static uint8_t vpl011_read_data(struct domain *d)
      */
     vpl011->uartfr &=3D ~RXFF;
=20
-    VPL011_UNLOCK(d, flags);
+    spin_unlock_irqrestore(&vpl011->lock, flags);
=20
     /*
      * Send an event to console backend to indicate that data has been
@@ -288,7 +288,7 @@ static void vpl011_write_data(struct domain *d, uint8_t=
 data)
     struct xencons_interface *intf =3D vpl011->backend.dom.ring_buf;
     XENCONS_RING_IDX out_cons, out_prod;
=20
-    VPL011_LOCK(d, flags);
+    spin_lock_irqsave(&vpl011->lock, flags);
=20
     out_cons =3D intf->out_cons;
     out_prod =3D intf->out_prod;
@@ -336,7 +336,7 @@ static void vpl011_write_data(struct domain *d, uint8_t=
 data)
=20
     vpl011->uartfr &=3D ~TXFE;
=20
-    VPL011_UNLOCK(d, flags);
+    spin_unlock_irqrestore(&vpl011->lock, flags);
=20
     /*
      * Send an event to console backend to indicate that there is
@@ -378,34 +378,34 @@ static int vpl011_mmio_read(struct vcpu *v,
     case FR:
         if ( !vpl011_reg32_check_access(dabt) ) goto bad_width;
=20
-        VPL011_LOCK(d, flags);
+        spin_lock_irqsave(&vpl011->lock, flags);
         *r =3D vreg_reg32_extract(vpl011->uartfr, info);
-        VPL011_UNLOCK(d, flags);
+        spin_unlock_irqrestore(&vpl011->lock, flags);
         return 1;
=20
     case RIS:
         if ( !vpl011_reg32_check_access(dabt) ) goto bad_width;
=20
-        VPL011_LOCK(d, flags);
+        spin_lock_irqsave(&vpl011->lock, flags);
         *r =3D vreg_reg32_extract(vpl011->uartris, info);
-        VPL011_UNLOCK(d, flags);
+        spin_unlock_irqrestore(&vpl011->lock, flags);
         return 1;
=20
     case MIS:
         if ( !vpl011_reg32_check_access(dabt) ) goto bad_width;
=20
-        VPL011_LOCK(d, flags);
+        spin_lock_irqsave(&vpl011->lock, flags);
         *r =3D vreg_reg32_extract(vpl011->uartris & vpl011->uartimsc,
                                 info);
-        VPL011_UNLOCK(d, flags);
+        spin_unlock_irqrestore(&vpl011->lock, flags);
         return 1;
=20
     case IMSC:
         if ( !vpl011_reg32_check_access(dabt) ) goto bad_width;
=20
-        VPL011_LOCK(d, flags);
+        spin_lock_irqsave(&vpl011->lock, flags);
         *r =3D vreg_reg32_extract(vpl011->uartimsc, info);
-        VPL011_UNLOCK(d, flags);
+        spin_unlock_irqrestore(&vpl011->lock, flags);
         return 1;
=20
     case ICR:
@@ -476,19 +476,19 @@ static int vpl011_mmio_write(struct vcpu *v,
     case IMSC:
         if ( !vpl011_reg32_check_access(dabt) ) goto bad_width;
=20
-        VPL011_LOCK(d, flags);
+        spin_lock_irqsave(&vpl011->lock, flags);
         vreg_reg32_update(&vpl011->uartimsc, r, info);
         vpl011_update_interrupt_status(v->domain);
-        VPL011_UNLOCK(d, flags);
+        spin_unlock_irqrestore(&vpl011->lock, flags);
         return 1;
=20
     case ICR:
         if ( !vpl011_reg32_check_access(dabt) ) goto bad_width;
=20
-        VPL011_LOCK(d, flags);
+        spin_lock_irqsave(&vpl011->lock, flags);
         vreg_reg32_clearbits(&vpl011->uartris, r, info);
         vpl011_update_interrupt_status(d);
-        VPL011_UNLOCK(d, flags);
+        spin_unlock_irqrestore(&vpl011->lock, flags);
         return 1;
=20
     default:
@@ -587,13 +587,13 @@ int vuart_putchar(struct domain *d, char c)
     if ( intf =3D=3D NULL )
         return -ENODEV;
=20
-    VPL011_LOCK(d, flags);
+    spin_lock_irqsave(&vpl011->lock, flags);
=20
     in_cons =3D intf->in_cons;
     in_prod =3D intf->in_prod;
     if ( xencons_queued(in_prod, in_cons, sizeof(intf->in)) =3D=3D sizeof(=
intf->in) )
     {
-        VPL011_UNLOCK(d, flags);
+        spin_unlock_irqrestore(&vpl011->lock, flags);
         return -ENOSPC;
     }
=20
@@ -605,7 +605,7 @@ int vuart_putchar(struct domain *d, char c)
                                    sizeof(intf->in));
=20
     vpl011_data_avail(d, in_fifo_level, sizeof(intf->in), 0, SBSA_UART_FIF=
O_SIZE);
-    VPL011_UNLOCK(d, flags);
+    spin_unlock_irqrestore(&vpl011->lock, flags);
=20
     return 0;
 }
@@ -619,7 +619,7 @@ static void vpl011_notification(struct vcpu *v, unsigne=
d int port)
     XENCONS_RING_IDX in_cons, in_prod, out_cons, out_prod;
     XENCONS_RING_IDX in_fifo_level, out_fifo_level;
=20
-    VPL011_LOCK(d, flags);
+    spin_lock_irqsave(&vpl011->lock, flags);
=20
     in_cons =3D intf->in_cons;
     in_prod =3D intf->in_prod;
@@ -639,7 +639,7 @@ static void vpl011_notification(struct vcpu *v, unsigne=
d int port)
     vpl011_data_avail(v->domain, in_fifo_level, sizeof(intf->in),
                       out_fifo_level, sizeof(intf->out));
=20
-    VPL011_UNLOCK(d, flags);
+    spin_unlock_irqrestore(&vpl011->lock, flags);
 }
=20
 int vuart_init(struct domain *d, struct vuart_params *params)
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Tue Jun 24 03:55:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 03:55:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022929.1398814 (Exim 4.92)
	(envelope-from )
	id 1uTulC-00087n-Jc; Tue, 24 Jun 2025 03:55:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022929.1398814; Tue, 24 Jun 2025 03: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 1uTulC-00087g-Ge; Tue, 24 Jun 2025 03:55:50 +0000
Received: by outflank-mailman (input) for mailman id 1022929;
 Tue, 24 Jun 2025 03:55: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 1uTulB-0006IZ-IV
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 03:55:49 +0000
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1d221973-50af-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 05:55:48 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1d221973-50af-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1750737347; x=1750996547;
	bh=lHc3ACLw6pt7GkNxldMDTQDd1/xX/S5inv8S6C9xx9k=;
	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;
	b=UyOkXxLnpo9E6dxPOgu5HimdTcmUCgQkr+Qdq1DTRW1QF9vMcC78WwzQQCqabOBta
	 L8Ffb4RLzCkB7jJeVbk6LzzVTbffTP+u+maRLHL9qaKBOh/iOrLTSu0/SEkLWdaJAv
	 RxQkkK5vgXFzOL8c5Cif7CyTZvOEu2bqdnro/sRyiY4tUHbQsqvq3ap3aK43+Y42Gt
	 3p7hovWsFFKZNq37WlljpxELXXSZQmhBe1Bbuj4yyZPzl4vYXjbPgdWRqKUw6zcY9w
	 LnZtEAO2Y0AMShp1Ely9lx0u3Lmeyl4k8Ht9gHVfyPheMjZxpHkHjw4xO76G3yhIGo
	 2vIrVLydr6gRA==
Date: Tue, 24 Jun 2025 03:55:41 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, oleksii.kurochko@gmail.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v1 05/16] arm/vpl011: use void pointer in domain struct
Message-ID: <20250624035443.344099-6-dmukhin@ford.com>
In-Reply-To: <20250624035443.344099-1-dmukhin@ford.com>
References: <20250624035443.344099-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 0ae6ac912a722d1d6ffe02af0bdd19ee8312a069
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin =20

Switch to using void pointer in domain struct to reduce compile-time
dependencies for PL011 emulator.

Signed-off-by: Denis Mukhin 
---
 xen/arch/arm/include/asm/domain.h |   3 +-
 xen/arch/arm/vpl011.c             | 139 +++++++++++++++++-------------
 2 files changed, 79 insertions(+), 63 deletions(-)

diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/d=
omain.h
index 746ea687d523..2ee9976b55a8 100644
--- a/xen/arch/arm/include/asm/domain.h
+++ b/xen/arch/arm/include/asm/domain.h
@@ -9,7 +9,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
=20
 struct hvm_domain
@@ -114,7 +113,7 @@ struct arch_domain
     } monitor;
=20
 #ifdef CONFIG_HAS_VUART_PL011
-    struct vpl011 vpl011;
+    void *vpl011;
 #endif
=20
 #ifdef CONFIG_TEE
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index a97c3b74208c..3c027ccf0b4e 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -31,6 +32,43 @@
 #include 
 #include 
=20
+static void __vpl011_exit(struct vpl011 *vpl011, struct domain *d)
+{
+    if ( vpl011->virq )
+    {
+        vgic_free_virq(d, vpl011->virq);
+
+        /*
+         * Set to invalid irq (we use SPI) to prevent extra free and to av=
oid
+         * freeing irq that could have already been reserved by someone el=
se.
+         */
+        vpl011->virq =3D 0;
+    }
+
+    if ( vpl011->backend_in_domain )
+    {
+        if ( vpl011->backend.dom.ring_buf )
+            destroy_ring_for_helper(&vpl011->backend.dom.ring_buf,
+                                    vpl011->backend.dom.ring_page);
+
+        if ( vpl011->evtchn )
+        {
+            free_xen_event_channel(d, vpl011->evtchn);
+
+            /*
+             * Set to invalid event channel port to prevent extra free and=
 to
+             * avoid freeing port that could have already been allocated f=
or
+             * other purposes.
+             */
+            vpl011->evtchn =3D 0;
+        }
+    }
+    else
+        XFREE(vpl011->backend.xen);
+
+    xfree(vpl011);
+}
+
 /*
  * Since pl011 registers are 32-bit registers, all registers
  * are handled similarly allowing 8-bit, 16-bit and 32-bit
@@ -43,7 +81,7 @@ static bool vpl011_reg32_check_access(struct hsr_dabt dab=
t)
=20
 static void vpl011_update_interrupt_status(struct domain *d)
 {
-    struct vpl011 *vpl011 =3D &d->arch.vpl011;
+    struct vpl011 *vpl011 =3D d->arch.vpl011;
     uint32_t uartmis =3D vpl011->uartris & vpl011->uartimsc;
=20
     /*
@@ -81,7 +119,7 @@ static void vpl011_update_interrupt_status(struct domain=
 *d)
 static void vpl011_write_data_xen(struct domain *d, uint8_t data)
 {
     unsigned long flags;
-    struct vpl011 *vpl011 =3D &d->arch.vpl011;
+    struct vpl011 *vpl011 =3D d->arch.vpl011;
     struct vpl011_xen_backend *intf =3D vpl011->backend.xen;
     struct domain *input =3D console_get_domain();
=20
@@ -140,7 +178,7 @@ static uint8_t vpl011_read_data_xen(struct domain *d)
 {
     unsigned long flags;
     uint8_t data =3D 0;
-    struct vpl011 *vpl011 =3D &d->arch.vpl011;
+    struct vpl011 *vpl011 =3D d->arch.vpl011;
     struct vpl011_xen_backend *intf =3D vpl011->backend.xen;
     XENCONS_RING_IDX in_cons, in_prod;
=20
@@ -199,7 +237,7 @@ static uint8_t vpl011_read_data(struct domain *d)
 {
     unsigned long flags;
     uint8_t data =3D 0;
-    struct vpl011 *vpl011 =3D &d->arch.vpl011;
+    struct vpl011 *vpl011 =3D d->arch.vpl011;
     struct xencons_interface *intf =3D vpl011->backend.dom.ring_buf;
     XENCONS_RING_IDX in_cons, in_prod;
=20
@@ -284,7 +322,7 @@ static void vpl011_update_tx_fifo_status(struct vpl011 =
*vpl011,
 static void vpl011_write_data(struct domain *d, uint8_t data)
 {
     unsigned long flags;
-    struct vpl011 *vpl011 =3D &d->arch.vpl011;
+    struct vpl011 *vpl011 =3D d->arch.vpl011;
     struct xencons_interface *intf =3D vpl011->backend.dom.ring_buf;
     XENCONS_RING_IDX out_cons, out_prod;
=20
@@ -350,10 +388,9 @@ static int vpl011_mmio_read(struct vcpu *v,
                             register_t *r,
                             void *priv)
 {
+    struct vpl011 *vpl011 =3D v->domain->arch.vpl011;
     struct hsr_dabt dabt =3D info->dabt;
-    uint32_t vpl011_reg =3D (uint32_t)(info->gpa -
-                                     v->domain->arch.vpl011.base_addr);
-    struct vpl011 *vpl011 =3D &v->domain->arch.vpl011;
+    uint32_t vpl011_reg =3D (uint32_t)(info->gpa - vpl011->base_addr);
     struct domain *d =3D v->domain;
     unsigned long flags;
=20
@@ -439,10 +476,9 @@ static int vpl011_mmio_write(struct vcpu *v,
                              register_t r,
                              void *priv)
 {
+    struct vpl011 *vpl011 =3D v->domain->arch.vpl011;
     struct hsr_dabt dabt =3D info->dabt;
-    uint32_t vpl011_reg =3D (uint32_t)(info->gpa -
-                                     v->domain->arch.vpl011.base_addr);
-    struct vpl011 *vpl011 =3D &v->domain->arch.vpl011;
+    uint32_t vpl011_reg =3D (uint32_t)(info->gpa - vpl011->base_addr);
     struct domain *d =3D v->domain;
     unsigned long flags;
=20
@@ -518,7 +554,7 @@ static void vpl011_data_avail(struct domain *d,
                               XENCONS_RING_IDX out_fifo_level,
                               XENCONS_RING_IDX out_size)
 {
-    struct vpl011 *vpl011 =3D &d->arch.vpl011;
+    struct vpl011 *vpl011 =3D d->arch.vpl011;
=20
     /**** Update the UART RX state ****/
=20
@@ -576,7 +612,7 @@ static void vpl011_data_avail(struct domain *d,
 int vuart_putchar(struct domain *d, char c)
 {
     unsigned long flags;
-    struct vpl011 *vpl011 =3D &d->arch.vpl011;
+    struct vpl011 *vpl011 =3D d->arch.vpl011;
     struct vpl011_xen_backend *intf =3D vpl011->backend.xen;
     XENCONS_RING_IDX in_cons, in_prod, in_fifo_level;
=20
@@ -614,7 +650,7 @@ static void vpl011_notification(struct vcpu *v, unsigne=
d int port)
 {
     unsigned long flags;
     struct domain *d =3D v->domain;
-    struct vpl011 *vpl011 =3D &d->arch.vpl011;
+    struct vpl011 *vpl011 =3D d->arch.vpl011;
     struct xencons_interface *intf =3D vpl011->backend.dom.ring_buf;
     XENCONS_RING_IDX in_cons, in_prod, out_cons, out_prod;
     XENCONS_RING_IDX in_fifo_level, out_fifo_level;
@@ -644,11 +680,14 @@ static void vpl011_notification(struct vcpu *v, unsig=
ned int port)
=20
 int vuart_init(struct domain *d, struct vuart_params *params)
 {
+    struct vpl011 *vpl011;
     int rc;
-    struct vpl011 *vpl011 =3D &d->arch.vpl011;
=20
-    if ( vpl011->backend.dom.ring_buf )
-        return -EINVAL;
+    BUG_ON(d->arch.vpl011);
+
+    vpl011 =3D xvzalloc(typeof(*vpl011));
+    if ( !vpl011 )
+        return -ENOMEM;
=20
     /*
      * The VPL011 virq is GUEST_VPL011_SPI, except for direct-map domains
@@ -670,7 +709,8 @@ int vuart_init(struct domain *d, struct vuart_params *p=
arams)
         {
             printk(XENLOG_ERR
                    "vpl011: Unable to re-use the Xen UART information.\n")=
;
-            return -EINVAL;
+            rc =3D -EINVAL;
+            goto err_out;
         }
=20
         /*
@@ -684,7 +724,8 @@ int vuart_init(struct domain *d, struct vuart_params *p=
arams)
         {
             printk(XENLOG_ERR
                    "vpl011: Can't re-use the Xen UART MMIO region as it is=
 too small.\n");
-            return -EINVAL;
+            rc =3D -EINVAL;
+            goto err_out;
         }
     }
     else
@@ -707,12 +748,12 @@ int vuart_init(struct domain *d, struct vuart_params =
*params)
                                       &vpl011->backend.dom.ring_page,
                                       &vpl011->backend.dom.ring_buf);
         if ( rc < 0 )
-            goto out;
+            goto err_out;
=20
         rc =3D alloc_unbound_xen_event_channel(d, 0, params->console_domid=
,
                                              vpl011_notification);
         if ( rc < 0 )
-            goto out1;
+            goto err_out;
=20
         vpl011->evtchn =3D params->evtchn =3D rc;
     }
@@ -725,7 +766,7 @@ int vuart_init(struct domain *d, struct vuart_params *p=
arams)
         if ( vpl011->backend.xen =3D=3D NULL )
         {
             rc =3D -ENOMEM;
-            goto out;
+            goto err_out;
         }
     }
=20
@@ -733,7 +774,7 @@ int vuart_init(struct domain *d, struct vuart_params *p=
arams)
     if ( !rc )
     {
         rc =3D -EINVAL;
-        goto out1;
+        goto err_out;
     }
=20
     vpl011->uartfr =3D TXFE | RXFE;
@@ -743,50 +784,22 @@ int vuart_init(struct domain *d, struct vuart_params =
*params)
     register_mmio_handler(d, &vpl011_mmio_handler,
                           vpl011->base_addr, GUEST_PL011_SIZE, NULL);
=20
+    d->arch.vpl011 =3D vpl011;
+
     return 0;
=20
-out1:
-    vuart_exit(d);
-
-out:
+err_out:
+    __vpl011_exit(vpl011, d);
     return rc;
 }
=20
 void vuart_exit(struct domain *d)
 {
-    struct vpl011 *vpl011 =3D &d->arch.vpl011;
-
-    if ( vpl011->virq )
+    if ( d->arch.vpl011 )
     {
-        vgic_free_virq(d, vpl011->virq);
-
-        /*
-         * Set to invalid irq (we use SPI) to prevent extra free and to av=
oid
-         * freeing irq that could have already been reserved by someone el=
se.
-         */
-        vpl011->virq =3D 0;
+        __vpl011_exit(d->arch.vpl011, d);
+        d->arch.vpl011 =3D NULL;
     }
-
-    if ( vpl011->backend_in_domain )
-    {
-        if ( vpl011->backend.dom.ring_buf )
-            destroy_ring_for_helper(&vpl011->backend.dom.ring_buf,
-                                    vpl011->backend.dom.ring_page);
-
-        if ( vpl011->evtchn )
-        {
-            free_xen_event_channel(d, vpl011->evtchn);
-
-            /*
-             * Set to invalid event channel port to prevent extra free and=
 to
-             * avoid freeing port that could have already been allocated f=
or
-             * other purposes.
-             */
-            vpl011->evtchn =3D 0;
-        }
-    }
-    else
-        XFREE(vpl011->backend.xen);
 }
=20
 int __init vuart_add_fwnode(struct domain *d, void *node)
@@ -797,8 +810,12 @@ int __init vuart_add_fwnode(struct domain *d, void *no=
de)
     gic_interrupt_t intr;
     __be32 reg[GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS];
     __be32 *cells;
+    struct vpl011 *vpl011 =3D d->arch.vpl011;
=20
-    res =3D domain_fdt_begin_node(fdt, "sbsa-uart", d->arch.vpl011.base_ad=
dr);
+    if ( !vpl011 )
+        return 0;
+
+    res =3D domain_fdt_begin_node(fdt, "sbsa-uart", vpl011->base_addr);
     if ( res )
         return res;
=20
@@ -808,14 +825,14 @@ int __init vuart_add_fwnode(struct domain *d, void *n=
ode)
=20
     cells =3D ®[0];
     dt_child_set_range(&cells, GUEST_ROOT_ADDRESS_CELLS,
-                       GUEST_ROOT_SIZE_CELLS, d->arch.vpl011.base_addr,
+                       GUEST_ROOT_SIZE_CELLS, vpl011->base_addr,
                        GUEST_PL011_SIZE);
=20
     res =3D fdt_property(fdt, "reg", reg, sizeof(reg));
     if ( res )
         return res;
=20
-    set_interrupt(intr, d->arch.vpl011.virq, 0xf, DT_IRQ_TYPE_LEVEL_HIGH);
+    set_interrupt(intr, vpl011->virq, 0xf, DT_IRQ_TYPE_LEVEL_HIGH);
=20
     res =3D fdt_property(fdt, "interrupts", intr, sizeof (intr));
     if ( res )
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Tue Jun 24 04:00:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 04:00:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022955.1398840 (Exim 4.92)
	(envelope-from )
	id 1uTuq4-0002Gs-Py; Tue, 24 Jun 2025 04:00:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022955.1398840; Tue, 24 Jun 2025 04:00: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 1uTuq4-0002FM-Iu; Tue, 24 Jun 2025 04:00:52 +0000
Received: by outflank-mailman (input) for mailman id 1022955;
 Tue, 24 Jun 2025 04:00: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 1uTulb-0006IZ-GS
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 03:56:15 +0000
Received: from mail-24417.protonmail.ch (mail-24417.protonmail.ch
 [109.224.244.17]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2c8d3310-50af-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 05:56:14 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2c8d3310-50af-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1750737373; x=1750996573;
	bh=EZPSUcu7la0M45CwJVaWkAOhNHBB8cLtWWRrJ9AK15Q=;
	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;
	b=cDkAGXIxwmH2Q6b45ukKQqCRljR8aIantC+Yo2I9dkyIfGby3MAZxLEiS9PJiq5A9
	 7TneQ+1A3wYc9m+sTTeRnDH+leZfPfqgpoNL/wdirJ682s47muibdxni48t0sc5KHS
	 Wi0RaXeKMJvriUfARBRDSN0/bkYiOVPdYvAVOjqA5Q+tlHXj6CJT+SX/g/sjozDO3N
	 qnFYsQ6kMzapzR/Xx42PKfPK+mb43s7C6DWMZX45DVd5PSH4PcQPBUFIbuj0Q+bxMf
	 AM74dmkPd1GOGYx3vRSnJBltwBDAu7epwcNR3vVet8V7vLhlvMO4S1Y8xza2SeI77f
	 pFzjvfz6Pyacg==
Date: Tue, 24 Jun 2025 03:56:09 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, oleksii.kurochko@gmail.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v1 08/16] arm/vuart: move simple MMIO-based vUART declarations to common header
Message-ID: <20250624035443.344099-9-dmukhin@ford.com>
In-Reply-To: <20250624035443.344099-1-dmukhin@ford.com>
References: <20250624035443.344099-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 41115d32da3b21d594ea62d30a415d088e6afb20
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin =20

Merge arch/arm/vuart.h with include/xen/vuart.h.

No functional change.

Signed-off-by: Denis Mukhin 
---
 xen/arch/arm/domain.c   |  1 -
 xen/arch/arm/vuart.c    |  3 +--
 xen/arch/arm/vuart.h    | 54 -----------------------------------------
 xen/include/xen/vuart.h | 20 +++++++++++++++
 4 files changed, 21 insertions(+), 57 deletions(-)
 delete mode 100644 xen/arch/arm/vuart.h

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 68297e619bad..3579d10d7e1d 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -31,7 +31,6 @@
 #include 
=20
 #include "vpci.h"
-#include "vuart.h"
=20
 DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
=20
diff --git a/xen/arch/arm/vuart.c b/xen/arch/arm/vuart.c
index bd2f425214b7..5403ed284846 100644
--- a/xen/arch/arm/vuart.c
+++ b/xen/arch/arm/vuart.c
@@ -28,8 +28,7 @@
 #include 
 #include 
 #include 
-
-#include "vuart.h"
+#include 
=20
 #define domain_has_vuart(d) ((d)->arch.vuart.info !=3D NULL)
=20
diff --git a/xen/arch/arm/vuart.h b/xen/arch/arm/vuart.h
deleted file mode 100644
index 726846355c3b..000000000000
--- a/xen/arch/arm/vuart.h
+++ /dev/null
@@ -1,54 +0,0 @@
-/*
- * xen/arch/arm/vuart.h
- *
- * Virtual UART Emulation Support
- *
- * Ian Campbell 
- * Copyright (c) 2012 Citrix Systems.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- */
-
-#ifndef __ARCH_ARM_VUART_H__
-#define __ARCH_ARM_VUART_H__
-
-struct domain;
-
-#ifdef CONFIG_HAS_VUART_MMIO
-
-int domain_vuart_init(struct domain *d);
-void domain_vuart_free(struct domain *d);
-
-#else
-
-static inline int domain_vuart_init(struct domain *d)
-{
-    /*
-     * The vUART is unconditionally inialized for the hw domain. So we
-     * can't return an error.
-     */
-    return 0;
-}
-
-static inline void domain_vuart_free(struct domain *d) {};
-
-#endif /* CONFIG_HAS_VUART_MMIO */
-
-#endif /* __ARCH_ARM_VUART_H__ */
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/include/xen/vuart.h b/xen/include/xen/vuart.h
index cae72ac9c6b9..928b60bbb4e2 100644
--- a/xen/include/xen/vuart.h
+++ b/xen/include/xen/vuart.h
@@ -43,6 +43,26 @@ static inline int vuart_putchar(struct domain *d, char c=
)
=20
 #endif /* CONFIG_HAS_VUART_PL011 */
=20
+#ifdef CONFIG_HAS_VUART_MMIO
+
+int domain_vuart_init(struct domain *d);
+void domain_vuart_free(struct domain *d);
+
+#else
+
+static inline int domain_vuart_init(struct domain *d)
+{
+    /*
+     * The vUART is unconditionally inialized for the hw domain. So we
+     * can't return an error.
+     */
+    return 0;
+}
+
+static inline void domain_vuart_free(struct domain *d) {};
+
+#endif /* CONFIG_HAS_VUART_MMIO */
+
 #endif /* XEN_VUART_H */
=20
 /*
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Tue Jun 24 04:00:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 04:00:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022953.1398834 (Exim 4.92)
	(envelope-from )
	id 1uTuq4-0002Dp-FE; Tue, 24 Jun 2025 04:00:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022953.1398834; Tue, 24 Jun 2025 04:00: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 1uTuq4-0002Di-CH; Tue, 24 Jun 2025 04:00:52 +0000
Received: by outflank-mailman (input) for mailman id 1022953;
 Tue, 24 Jun 2025 04:00: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 1uTumS-000639-86
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 03:57:08 +0000
Received: from mail-10629.protonmail.ch (mail-10629.protonmail.ch
 [79.135.106.29]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4b73ea28-50af-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 05:57:06 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4b73ea28-50af-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1750737425; x=1750996625;
	bh=EZ+uMveraa+cDZkwCgDIWFYhH2jzngRaVV7LukeCweg=;
	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;
	b=XYoKRTdUwDz/DU7S9mYIwzelOwKSVrRTMDn1HZvw6DdtwhN77jLq6ATpPRZoN/qg3
	 YmaDRlyNpPIshkXaoGy4WRAn/4qwpjEAAa0aSxqkarl1JfknvJVAcirucw+7wTxtte
	 b+s0q4KQQmHBPSv9xOmruko/r0oi+A7NVBwxaQKKgo2Ky7DOqi5aKlpkNBxTyjrQDo
	 we0wtEUi/OatP7tFJ58T7DSt5p3WkHVYp7zuhcWu8xdmDYgUoaHr4G3sZK/1DPhqJK
	 L3xL/Mbz8KhFT0arBWGp2tnY1nlsVZsz9gaNOmOJ5V0S3ni8eB8xQ+oTO4ytRTAUM1
	 M0yoalpTT9k2w==
Date: Tue, 24 Jun 2025 03:57:00 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, oleksii.kurochko@gmail.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v1 14/16] drivers/vuart: move simple MMIO-based UART emulator
Message-ID: <20250624035443.344099-15-dmukhin@ford.com>
In-Reply-To: <20250624035443.344099-1-dmukhin@ford.com>
References: <20250624035443.344099-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: f583a78ed85278e4f659d4fbdd3a908ebf03d47f
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin =20

Move simple MMIO-based UART emulator under drivers/vuart and rename it to
vuart-mmio.c to keep "vuart" for the vUART framework.

No functional change intended.

Signed-off-by: Denis Mukhin 
---
 xen/arch/arm/Kconfig                                 | 8 --------
 xen/arch/arm/Makefile                                | 1 -
 xen/drivers/vuart/Kconfig                            | 9 +++++++++
 xen/drivers/vuart/Makefile                           | 1 +
 xen/{arch/arm/vuart.c =3D> drivers/vuart/vuart-mmio.c} | 0
 5 files changed, 10 insertions(+), 9 deletions(-)
 rename xen/{arch/arm/vuart.c =3D> drivers/vuart/vuart-mmio.c} (100%)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 6eeae97293f2..7b915abc6f18 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -170,14 +170,6 @@ config NEW_VGIC
 =09problems with the standard emulation.
 =09At the moment this implementation is not security supported.
=20
-config HAS_VUART_MMIO
-=09bool "Emulated UART for hardware domain"
-=09default y
-=09help
-=09  Allows a hardware domain to use a minimalistic UART (single transmit
-=09  and status register) which takes information from dtuart. Note that t=
his
-=09  UART is not intended to be exposed (e.g. via device-tree) to a domain=
.
-
 config ARM_SSBD
 =09bool "Speculative Store Bypass Disable" if EXPERT
 =09depends on HAS_ALTERNATIVE
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 8475043d8701..24bc9c88f7ac 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -67,7 +67,6 @@ obj-$(CONFIG_VM_EVENT) +=3D vm_event.o
 obj-y +=3D vtimer.o
 obj-y +=3D vsmc.o
 obj-y +=3D vpsci.o
-obj-$(CONFIG_HAS_VUART_MMIO) +=3D vuart.o
=20
 extra-y +=3D xen.lds
=20
diff --git a/xen/drivers/vuart/Kconfig b/xen/drivers/vuart/Kconfig
index d8df0f6d1b3c..6002817152df 100644
--- a/xen/drivers/vuart/Kconfig
+++ b/xen/drivers/vuart/Kconfig
@@ -3,6 +3,15 @@ config HAS_VUART
=20
 if (ARM_32 || ARM_64)
=20
+config HAS_VUART_MMIO
+=09bool "Simple MMIO-based emulated UART support"
+=09default y
+=09select HAS_VUART
+=09help
+=09  Enables minimalistic UART (single transmit and status register) which
+=09  takes information from dtuart. Note that this UART is not intended to
+=09  be exposed (e.g. via device-tree) to a domain.
+
 config HAS_VUART_PL011
 =09bool "Emulated PL011 UART support"
 =09default y
diff --git a/xen/drivers/vuart/Makefile b/xen/drivers/vuart/Makefile
index 3b7069f1cf95..1c775ffb7f1d 100644
--- a/xen/drivers/vuart/Makefile
+++ b/xen/drivers/vuart/Makefile
@@ -1 +1,2 @@
+obj-$(CONFIG_HAS_VUART_MMIO) +=3D vuart-mmio.o
 obj-$(CONFIG_HAS_VUART_PL011) +=3D vuart-pl011.o
diff --git a/xen/arch/arm/vuart.c b/xen/drivers/vuart/vuart-mmio.c
similarity index 100%
rename from xen/arch/arm/vuart.c
rename to xen/drivers/vuart/vuart-mmio.c
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Tue Jun 24 04:00:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 04:00:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022952.1398824 (Exim 4.92)
	(envelope-from )
	id 1uTuq1-0001y6-9V; Tue, 24 Jun 2025 04:00:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022952.1398824; Tue, 24 Jun 2025 04: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 1uTuq1-0001xz-6Y; Tue, 24 Jun 2025 04:00:49 +0000
Received: by outflank-mailman (input) for mailman id 1022952;
 Tue, 24 Jun 2025 04:00: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 1uTulM-000639-HU
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 03:56:00 +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 2338276b-50af-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 05:55:59 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2338276b-50af-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=vvcfptfpireknpma5nle5ez43y.protonmail; t=1750737357; x=1750996557;
	bh=Hr/ZkUe3+2HPidIdCTxwSDIZWzLYqjdMotIU52bRYqY=;
	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;
	b=J9G5q+amCTOYNYSoOOYXFdP4tBeAGCM4ONZaVMGNf4RzbNrjBtEysWAfEXI8f/niw
	 sstjwf8ILPI7wTiUJF7/JsT6Z0ol7hRXGhFXEjrl6LZrK0IvPFZMXDgdHmQSwuw8qp
	 H/SWgr9Qwe9pRIOsGtXEQG7WaKIhy54LRxKlVGJC+ZrJg9v91/omJQNwYfmmobsIl5
	 rKBOesy3pi4DxHVoKYqMjBsDJKa9X6kKZv/rEa/v9IYwKJgnz4asxCXnoZOAlP59hs
	 FZKYDfdZ8qpsMdb6zb9qCp8sVslCc9okbF60n4GoOgU+Qy9yUTCb983COC133u9rQQ
	 4Tvx0fvs0BwWA==
Date: Tue, 24 Jun 2025 03:55:51 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, oleksii.kurochko@gmail.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v1 06/16] arm/vpl011: remove vpl011 header file
Message-ID: <20250624035443.344099-7-dmukhin@ford.com>
In-Reply-To: <20250624035443.344099-1-dmukhin@ford.com>
References: <20250624035443.344099-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 23672e309d6359726fd79b9e87ec955d61d4c858
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin =20

Make all PL011 emulator declarations private to emulator's code.

No functional change.

Signed-off-by: Denis Mukhin 
---
 xen/arch/arm/include/asm/vpl011.h | 67 -------------------------------
 xen/arch/arm/vpl011.c             | 39 ++++++++++++++++--
 2 files changed, 35 insertions(+), 71 deletions(-)
 delete mode 100644 xen/arch/arm/include/asm/vpl011.h

diff --git a/xen/arch/arm/include/asm/vpl011.h b/xen/arch/arm/include/asm/v=
pl011.h
deleted file mode 100644
index 8f6ea0005e72..000000000000
--- a/xen/arch/arm/include/asm/vpl011.h
+++ /dev/null
@@ -1,67 +0,0 @@
-/*
- * include/xen/vpl011.h
- *
- * Virtual PL011 UART
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License f=
or
- * more details.
- *
- * You should have received a copy of the GNU General Public License along=
 with
- * this program; If not, see .
- */
-
-#ifndef _VPL011_H_
-#define _VPL011_H_
-
-#include 
-#include 
-#include 
-#include 
-
-#define SBSA_UART_FIFO_SIZE 32
-/* Same size as VUART_BUF_SIZE, used in vuart.c */
-#define SBSA_UART_OUT_BUF_SIZE 128
-struct vpl011_xen_backend {
-    char in[SBSA_UART_FIFO_SIZE];
-    char out[SBSA_UART_OUT_BUF_SIZE];
-    XENCONS_RING_IDX in_cons, in_prod;
-    XENCONS_RING_IDX out_prod;
-};
-
-struct vpl011 {
-    bool backend_in_domain;
-    union {
-        struct {
-            void *ring_buf;
-            struct page_info *ring_page;
-        } dom;
-        struct vpl011_xen_backend *xen;
-    } backend;
-    uint32_t    uartfr;         /* Flag register */
-    uint32_t    uartcr;         /* Control register */
-    uint32_t    uartimsc;       /* Interrupt mask register*/
-    uint32_t    uarticr;        /* Interrupt clear register */
-    uint32_t    uartris;        /* Raw interrupt status register */
-    uint32_t    shadow_uartmis; /* shadow masked interrupt register */
-    paddr_t     base_addr;
-    unsigned int virq;
-    spinlock_t  lock;
-    evtchn_port_t evtchn;
-};
-
-#endif  /* _VPL011_H_ */
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 3c027ccf0b4e..bebfb5e0365c 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -7,9 +7,6 @@
=20
 #define XEN_WANT_FLEX_CONSOLE_RING 1
=20
-/* We assume the PL011 default of "1/2 way" for the FIFO trigger level. */
-#define SBSA_UART_FIFO_LEVEL (SBSA_UART_FIFO_SIZE / 2)
-
 #include 
 #include 
 #include 
@@ -25,13 +22,47 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
=20
+#define SBSA_UART_FIFO_SIZE         32
+/* Same size as VUART_BUF_SIZE, used in simple MMIO-based vUART */
+#define SBSA_UART_OUT_BUF_SIZE      128
+/* We assume the PL011 default of "1/2 way" for the FIFO trigger level. */
+#define SBSA_UART_FIFO_LEVEL        (SBSA_UART_FIFO_SIZE / 2)
+
+struct vpl011_xen_backend {
+    char in[SBSA_UART_FIFO_SIZE];
+    char out[SBSA_UART_OUT_BUF_SIZE];
+    XENCONS_RING_IDX in_cons, in_prod;
+    XENCONS_RING_IDX out_prod;
+};
+
+struct vpl011 {
+    bool backend_in_domain;
+    union {
+        struct {
+            void *ring_buf;
+            struct page_info *ring_page;
+        } dom;
+        struct vpl011_xen_backend *xen;
+    } backend;
+    uint32_t    uartfr;         /* Flag register */
+    uint32_t    uartcr;         /* Control register */
+    uint32_t    uartimsc;       /* Interrupt mask register*/
+    uint32_t    uarticr;        /* Interrupt clear register */
+    uint32_t    uartris;        /* Raw interrupt status register */
+    uint32_t    shadow_uartmis; /* shadow masked interrupt register */
+    paddr_t     base_addr;
+    unsigned int virq;
+    spinlock_t  lock;
+    evtchn_port_t evtchn;
+};
+
 static void __vpl011_exit(struct vpl011 *vpl011, struct domain *d)
 {
     if ( vpl011->virq )
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Tue Jun 24 04:01:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 04:01:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022956.1398854 (Exim 4.92)
	(envelope-from )
	id 1uTuqB-0002qX-T6; Tue, 24 Jun 2025 04:00:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022956.1398854; Tue, 24 Jun 2025 04: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 1uTuqB-0002qM-PR; Tue, 24 Jun 2025 04:00:59 +0000
Received: by outflank-mailman (input) for mailman id 1022956;
 Tue, 24 Jun 2025 04:00: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 1uTulV-000639-Om
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 03:56:09 +0000
Received: from mail-10630.protonmail.ch (mail-10630.protonmail.ch
 [79.135.106.30]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 28aa697f-50af-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 05:56:08 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 28aa697f-50af-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1750737366; x=1750996566;
	bh=kg+n/kedKNW1A1xHbIIccq1oruQHzzJGTEwBEt6y32w=;
	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;
	b=cbhvZjKl4wEvGLp+l1O52nOJvnAZ2JMOfL05zGSFYWO4ALt/qaMxhZSW9tNjra3ZR
	 TU+g7u+h8q/Qp9d/gq8Kva0F6DL3Ngb1+A8oP+7Q5/yTX9fSPSurvUjwGmIRCb3MMU
	 QhyLTtmOICf89QtllzI7Klxj52FIAGoH1vyuVwUPbti7HGx779cAPppShCVODo3HQR
	 iW4C2J6jHSFd52luVPAMAM7UiBRSGGs0n/KP0xtIHAGbteUWri0h22qAjNXE1SPPHa
	 TN9vpbtVbYI09asbKwMoUBxmfH9IJciAB3NrfcCtUwMFI8FRC4EsSwJuUi7X2R8m8l
	 PVNzdW50N+kUA==
Date: Tue, 24 Jun 2025 03:55:59 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, oleksii.kurochko@gmail.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v1 07/16] arm/vuart: rename 'virtual UART' Kconfig option
Message-ID: <20250624035443.344099-8-dmukhin@ford.com>
In-Reply-To: <20250624035443.344099-1-dmukhin@ford.com>
References: <20250624035443.344099-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 9bd0188e159941caa349c4817e61032d44273f78
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin =20

Rename HWDOM_VUART to HAS_VUART_MMIO.

This emulator emulates only one register and the use of the emulator is
limited to early boot console in the guest OS.

No functional change.

Signed-off-by: Denis Mukhin 
---
 xen/arch/arm/Kconfig              | 2 +-
 xen/arch/arm/Makefile             | 2 +-
 xen/arch/arm/include/asm/domain.h | 2 +-
 xen/arch/arm/vuart.h              | 4 ++--
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 03888569f38c..b11cb583a763 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -177,7 +177,7 @@ config HAS_VUART_PL011
 =09  Allows a guest to use SBSA Generic UART as a console. The
 =09  SBSA Generic UART implements a subset of ARM PL011 UART.
=20
-config HWDOM_VUART
+config HAS_VUART_MMIO
 =09bool "Emulated UART for hardware domain"
 =09default y
 =09help
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 2d6787fb03bc..dd015a2a19e8 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -68,7 +68,7 @@ obj-y +=3D vtimer.o
 obj-$(CONFIG_HAS_VUART_PL011) +=3D vpl011.o
 obj-y +=3D vsmc.o
 obj-y +=3D vpsci.o
-obj-$(CONFIG_HWDOM_VUART) +=3D vuart.o
+obj-$(CONFIG_HAS_VUART_MMIO) +=3D vuart.o
=20
 extra-y +=3D xen.lds
=20
diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/d=
omain.h
index 2ee9976b55a8..d668c11d7e2c 100644
--- a/xen/arch/arm/include/asm/domain.h
+++ b/xen/arch/arm/include/asm/domain.h
@@ -90,7 +90,7 @@ struct arch_domain
=20
     struct vgic_dist vgic;
=20
-#ifdef CONFIG_HWDOM_VUART
+#ifdef CONFIG_HAS_VUART_MMIO
     struct vuart {
 #define VUART_BUF_SIZE 128
         char                        *buf;
diff --git a/xen/arch/arm/vuart.h b/xen/arch/arm/vuart.h
index e90d84c6eddb..726846355c3b 100644
--- a/xen/arch/arm/vuart.h
+++ b/xen/arch/arm/vuart.h
@@ -22,7 +22,7 @@
=20
 struct domain;
=20
-#ifdef CONFIG_HWDOM_VUART
+#ifdef CONFIG_HAS_VUART_MMIO
=20
 int domain_vuart_init(struct domain *d);
 void domain_vuart_free(struct domain *d);
@@ -40,7 +40,7 @@ static inline int domain_vuart_init(struct domain *d)
=20
 static inline void domain_vuart_free(struct domain *d) {};
=20
-#endif /* CONFIG_HWDOM_VUART */
+#endif /* CONFIG_HAS_VUART_MMIO */
=20
 #endif /* __ARCH_ARM_VUART_H__ */
=20
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Tue Jun 24 04:01:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 04:01:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022959.1398864 (Exim 4.92)
	(envelope-from )
	id 1uTuqD-00036H-4L; Tue, 24 Jun 2025 04:01:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022959.1398864; Tue, 24 Jun 2025 04:01:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTuqD-000366-15; Tue, 24 Jun 2025 04:01:01 +0000
Received: by outflank-mailman (input) for mailman id 1022959;
 Tue, 24 Jun 2025 04:00: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 1uTumc-0006IZ-Kd
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 03:57:18 +0000
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 50f5f1dd-50af-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 05:57:15 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 50f5f1dd-50af-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=suhlavfxo5fcjncdpc7tjndoiq.protonmail; t=1750737434; x=1750996634;
	bh=G+phzEkJh7bBPfUI5tVh5uJv49ZZOGGUY1qVym3PEsU=;
	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;
	b=YGzehV0MRobbiY+vb5LN2ZXUJVWvxD1OCUBrMIbCzKCfh4dQxe3fMG9f8RYkhBV1h
	 or+fkTjdzobaFvZuysUs8aq1DW9wrZeR7s3dWS994aTJXLZvANgHd5TE80KEOjnOlI
	 QPUfnOquaI59Yr/6rVdV+30TNs+3EKBrpMifSBNNJUB6ZhTZpFLHaUO2cqnMoSWqEN
	 jO+1j0xWGhsEZrXecrlwAh0MGYyJfxpYI2ZOgLzn9abxX+DW2R89HRt9nsdqSUNuU4
	 P4GcErm8bQL5zp1t1jXb7ew5s7CXdEb2afYPRkHXMqWRW/1BJnkEeUMp8RivNwelQl
	 6S/ypOMHolQ1Q==
Date: Tue, 24 Jun 2025 03:57:09 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, oleksii.kurochko@gmail.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v1 15/16] drivers/vuart: introduce framework for UART emulators
Message-ID: <20250624035443.344099-16-dmukhin@ford.com>
In-Reply-To: <20250624035443.344099-1-dmukhin@ford.com>
References: <20250624035443.344099-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 9444a946e272c03e86bb37c3bab824ff5afa7c2f
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin =20

Introduce a driver framework to abstract UART emulators in the hypervisor.

That allows for architecture-independent handling of virtual UARTs in the
console driver and simplifies enabling new UART emulators.

The framework is built under CONFIG_HAS_VUART, which is automatically enabl=
ed
once the user enables any UART emulator.

Current implementation supports maximum of one vUART of each kind per domai=
n.

All domains with enabled virtual PL011 will have DOMAIN_EMU_UART_PL011 bit =
set
in d->arch.emulation_flags. Introduce domain_has_vuart() in arch code to ch=
eck
whether domain has virtual UART.

Use domain_has_vuart() in the console driver code to check whether to forwa=
rd
console input to the domain using vUART.

Hook existing PL011 UART emulator to the new driver framework.

Signed-off-by: Denis Mukhin 
---
Original code: https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v=
1-7-c5d36b31d66c@ford.com/
---
 xen/arch/arm/dom0less-build.c       | 22 +++----
 xen/arch/arm/domctl.c               |  3 +-
 xen/arch/arm/include/asm/domain.h   |  1 +
 xen/arch/arm/include/asm/kernel.h   |  3 -
 xen/arch/arm/xen.lds.S              |  1 +
 xen/arch/ppc/include/asm/domain.h   |  1 +
 xen/arch/ppc/xen.lds.S              |  1 +
 xen/arch/riscv/include/asm/domain.h |  1 +
 xen/arch/riscv/xen.lds.S            |  1 +
 xen/arch/x86/xen.lds.S              |  1 +
 xen/common/domain.c                 | 10 +++
 xen/common/keyhandler.c             |  3 +
 xen/drivers/char/console.c          |  5 +-
 xen/drivers/vuart/Makefile          |  1 +
 xen/drivers/vuart/vuart-pl011.c     | 71 +++++++++++++++++++--
 xen/drivers/vuart/vuart.c           | 95 +++++++++++++++++++++++++++++
 xen/include/xen/domain-emu.h        |  2 +
 xen/include/xen/domain.h            |  2 +
 xen/include/xen/vuart.h             | 25 ++++++--
 xen/include/xen/xen.lds.h           | 10 +++
 20 files changed, 227 insertions(+), 32 deletions(-)
 create mode 100644 xen/drivers/vuart/vuart.c

diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index 11b8498d3b22..c04441ef4657 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -176,14 +176,9 @@ int __init make_arch_nodes(struct kernel_info *kinfo)
     if ( ret )
         return -EINVAL;
=20
-    if ( kinfo->arch.vpl011 )
-    {
-#ifdef CONFIG_HAS_VUART_PL011
-        ret =3D vuart_add_fwnode(kinfo->d, kinfo);
-#endif
-        if ( ret )
-            return -EINVAL;
-    }
+    ret =3D vuart_add_fwnode(kinfo->d, kinfo);
+    if ( ret )
+        return ret;
=20
     return 0;
 }
@@ -207,19 +202,16 @@ int __init init_vuart(struct domain *d, struct kernel=
_info *kinfo,
 {
     int rc =3D 0;
=20
-    kinfo->arch.vpl011 =3D dt_property_read_bool(node, "vpl011");
-
     /*
      * Base address and irq number are needed when creating vpl011 device
      * tree node in prepare_dtb_domU, so initialization on related variabl=
es
      * shall be done first.
      */
-    if ( kinfo->arch.vpl011 )
-    {
+    if ( dt_property_read_bool(node, "vpl011") )
+        d->emulation_flags |=3D DOMAIN_EMU_UART_PL011;
+
+    if ( domain_has_vuart(d) )
         rc =3D vuart_init(d, NULL);
-        if ( rc < 0 )
-            return rc;
-    }
=20
     return rc;
 }
diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index dde25ceff6d0..45144eca1ae2 100644
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -43,8 +43,9 @@ static int handle_vuart_init(struct domain *d,
     if ( vuart_op->type !=3D XEN_DOMCTL_VUART_TYPE_VPL011 )
         return -EOPNOTSUPP;
=20
-    rc =3D vuart_init(d, ¶ms);
+    d->emulation_flags |=3D DOMAIN_EMU_UART_PL011;
=20
+    rc =3D vuart_init(d, ¶ms);
     if ( !rc )
         vuart_op->evtchn =3D params.evtchn;
=20
diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/d=
omain.h
index 38873c66f1f8..32ef281151d8 100644
--- a/xen/arch/arm/include/asm/domain.h
+++ b/xen/arch/arm/include/asm/domain.h
@@ -2,6 +2,7 @@
 #define __ASM_DOMAIN_H__
=20
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/arm/include/asm/kernel.h b/xen/arch/arm/include/asm/k=
ernel.h
index 7c3b7fde5b64..cfeab792c76e 100644
--- a/xen/arch/arm/include/asm/kernel.h
+++ b/xen/arch/arm/include/asm/kernel.h
@@ -13,9 +13,6 @@ struct arch_kernel_info
 #ifdef CONFIG_ARM_64
     enum domain_type type;
 #endif
-
-    /* Enable pl011 emulation */
-    bool vpl011;
 };
=20
 #endif /* #ifdef __ARCH_ARM_KERNEL_H__ */
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 5bfbe1e92c1e..e876e3efbe4c 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -66,6 +66,7 @@ SECTIONS
        __proc_info_end =3D .;
=20
        VPCI_ARRAY
+       VUART_ARRAY
   } :text
=20
 #if defined(BUILD_ID)
diff --git a/xen/arch/ppc/include/asm/domain.h b/xen/arch/ppc/include/asm/d=
omain.h
index 3a447272c6f2..426e6297c935 100644
--- a/xen/arch/ppc/include/asm/domain.h
+++ b/xen/arch/ppc/include/asm/domain.h
@@ -2,6 +2,7 @@
 #ifndef __ASM_PPC_DOMAIN_H__
 #define __ASM_PPC_DOMAIN_H__
=20
+#include 
 #include 
 #include 
=20
diff --git a/xen/arch/ppc/xen.lds.S b/xen/arch/ppc/xen.lds.S
index 1366e2819eed..56bf4a0638d5 100644
--- a/xen/arch/ppc/xen.lds.S
+++ b/xen/arch/ppc/xen.lds.S
@@ -55,6 +55,7 @@ SECTIONS
         *(.data.rel.ro.*)
=20
         VPCI_ARRAY
+        VUART_ARRAY
=20
         . =3D ALIGN(POINTER_ALIGN);
     } :text
diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/a=
sm/domain.h
index c3d965a559b6..fcde3bc78dc6 100644
--- a/xen/arch/riscv/include/asm/domain.h
+++ b/xen/arch/riscv/include/asm/domain.h
@@ -2,6 +2,7 @@
 #ifndef ASM__RISCV__DOMAIN_H
 #define ASM__RISCV__DOMAIN_H
=20
+#include 
 #include 
 #include 
=20
diff --git a/xen/arch/riscv/xen.lds.S b/xen/arch/riscv/xen.lds.S
index 8c3c06de01f6..45592fca128f 100644
--- a/xen/arch/riscv/xen.lds.S
+++ b/xen/arch/riscv/xen.lds.S
@@ -50,6 +50,7 @@ SECTIONS
         *(.data.rel.ro.*)
=20
         VPCI_ARRAY
+        VUART_ARRAY
=20
         . =3D ALIGN(POINTER_ALIGN);
     } :text
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index bf956b6c5fc0..b04ed1e6138c 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -149,6 +149,7 @@ SECTIONS
        __note_gnu_build_id_end =3D .;
 #endif
        VPCI_ARRAY
+       VUART_ARRAY
   } PHDR(text)
=20
 #if defined(CONFIG_PVH_GUEST) && !defined(EFI)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 8c8f70347a91..071fee81fe2c 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -2436,6 +2436,16 @@ void thaw_domains(void)
     rcu_read_unlock(&domlist_read_lock);
 }
=20
+bool domain_has_vuart(const struct domain *d)
+{
+    uint32_t mask =3D 0;
+
+    if ( IS_ENABLED(CONFIG_HAS_VUART_PL011) )
+        mask |=3D DOMAIN_EMU_UART_PL011;
+
+    return !!(d->emulation_flags & mask);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index eccd97c565c6..21e970aded9a 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
=20
 static unsigned char keypress_key;
@@ -354,6 +355,8 @@ static void cf_check dump_domains(unsigned char key)
                            v->periodic_period / 1000000);
             }
         }
+
+        vuart_dump(d);
     }
=20
     for_each_domain ( d )
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index f322d59515ab..5ddc05cc44da 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -594,6 +594,7 @@ static void __serial_rx(char c)
         /*
          * Deliver input to the hardware domain buffer, unless it is
          * already full.
+         * NB: must be the first check: hardware domain may have emulated =
UART.
          */
         if ( (serial_rx_prod - serial_rx_cons) !=3D SERIAL_RX_SIZE )
             serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] =3D c;
@@ -604,11 +605,9 @@ static void __serial_rx(char c)
          */
         send_global_virq(VIRQ_CONSOLE);
     }
-#ifdef CONFIG_HAS_VUART_PL011
-    else
+    else if ( domain_has_vuart(d) )
         /* Deliver input to the emulated UART. */
         rc =3D vuart_putchar(d, c);
-#endif
=20
     if ( consoled_is_enabled() )
         /* Deliver input to the PV shim console. */
diff --git a/xen/drivers/vuart/Makefile b/xen/drivers/vuart/Makefile
index 1c775ffb7f1d..fa9aab666c2a 100644
--- a/xen/drivers/vuart/Makefile
+++ b/xen/drivers/vuart/Makefile
@@ -1,2 +1,3 @@
+obj-$(CONFIG_HAS_VUART) +=3D vuart.o
 obj-$(CONFIG_HAS_VUART_MMIO) +=3D vuart-mmio.o
 obj-$(CONFIG_HAS_VUART_PL011) +=3D vuart-pl011.o
diff --git a/xen/drivers/vuart/vuart-pl011.c b/xen/drivers/vuart/vuart-pl01=
1.c
index bebfb5e0365c..312618ad1b6f 100644
--- a/xen/drivers/vuart/vuart-pl011.c
+++ b/xen/drivers/vuart/vuart-pl011.c
@@ -638,9 +638,9 @@ static void vpl011_data_avail(struct domain *d,
 }
=20
 /*
- * vuart_putchar adds a char to a domain's vpl011 receive buffer.
+ * vpl011_putchar adds a char to a domain's vpl011 receive buffer.
  */
-int vuart_putchar(struct domain *d, char c)
+static int cf_check vpl011_putchar(struct domain *d, char c)
 {
     unsigned long flags;
     struct vpl011 *vpl011 =3D d->arch.vpl011;
@@ -709,7 +709,8 @@ static void vpl011_notification(struct vcpu *v, unsigne=
d int port)
     spin_unlock_irqrestore(&vpl011->lock, flags);
 }
=20
-int vuart_init(struct domain *d, struct vuart_params *params)
+static int cf_check vpl011_init(struct domain *d,
+                                struct vuart_params *params)
 {
     struct vpl011 *vpl011;
     int rc;
@@ -824,7 +825,7 @@ err_out:
     return rc;
 }
=20
-void vuart_exit(struct domain *d)
+static void cf_check vpl011_exit(struct domain *d)
 {
     if ( d->arch.vpl011 )
     {
@@ -833,9 +834,57 @@ void vuart_exit(struct domain *d)
     }
 }
=20
-int __init vuart_add_fwnode(struct domain *d, void *node)
+static void cf_check vpl011_dump(const struct domain *d)
 {
-    struct kernel_info *kinfo =3D node;
+    struct vpl011 *vdev =3D d->arch.vpl011;
+
+    if ( !vdev )
+        return;
+
+    /* Allow printing state in case of a deadlock. */
+    if ( !spin_trylock(&vdev->lock) )
+        return;
+
+    printk("Virtual PL011@%"PRIpaddr" IRQ#%d owner %pd\n",
+            vdev->base_addr, vdev->virq, d);
+
+    if ( vdev->backend_in_domain )
+    {
+        printk("  Event channel %"PRIu32"\n", vdev->evtchn);
+    }
+    else
+    {
+        const struct vpl011_xen_backend *cons =3D vdev->backend.xen;
+
+        printk("  RX FIFO size %u in_prod %u in_cons %u used %u\n",
+                SBSA_UART_FIFO_SIZE, cons->in_prod, cons->in_cons,
+                cons->in_prod - cons->in_cons);
+
+        printk("  TX FIFO size %u out_prod %u used %u\n",
+                SBSA_UART_OUT_BUF_SIZE, cons->out_prod, cons->out_prod);
+    }
+
+    printk("  %02"PRIx8" DR    %08"PRIx8"\n", DR   , 0);
+    printk("  %02"PRIx8" RSR   %08"PRIx8"\n", RSR  , 0);
+    printk("  %02"PRIx8" FR    %08"PRIx8"\n", FR   , vdev->uartfr);
+    printk("  %02"PRIx8" ILPR  %08"PRIx8"\n", ILPR , 0);
+    printk("  %02"PRIx8" IBRD  %08"PRIx8"\n", IBRD , 0);
+    printk("  %02"PRIx8" FBRD  %08"PRIx8"\n", FBRD , 0);
+    printk("  %02"PRIx8" LCR_H %08"PRIx8"\n", LCR_H, 0);
+    printk("  %02"PRIx8" CR    %08"PRIx8"\n", CR   , vdev->uartcr);
+    printk("  %02"PRIx8" IFLS  %08"PRIx8"\n", IFLS , 0);
+    printk("  %02"PRIx8" IMSC  %08"PRIx8"\n", IMSC , vdev->uartimsc);
+    printk("  %02"PRIx8" RIS   %08"PRIx8"\n", RIS  , vdev->uartris);
+    printk("  %02"PRIX8" MIS   %08"PRIX8"\n", MIS  , vdev->shadow_uartmis)=
;
+    printk("  %02"PRIx8" ICR   %08"PRIx8"\n", ICR  , vdev->uarticr);
+    printk("  %02"PRIx8" DMACR %08"PRIx8"\n", DMACR, 0);
+
+    spin_unlock(&vdev->lock);
+}
+
+static int cf_check vpl011_add_fwnode(struct domain *d, void *info)
+{
+    struct kernel_info *kinfo =3D info;
     void *fdt =3D kinfo->fdt;
     int res;
     gic_interrupt_t intr;
@@ -884,6 +933,16 @@ int __init vuart_add_fwnode(struct domain *d, void *no=
de)
     return 0;
 }
=20
+static const struct vuart_ops vpl011_ops =3D {
+    .add_fwnode =3D vpl011_add_fwnode,
+    .init       =3D vpl011_init,
+    .exit       =3D vpl011_exit,
+    .dump       =3D vpl011_dump,
+    .putchar    =3D vpl011_putchar,
+};
+
+VUART_REGISTER(vpl011, &vpl011_ops);
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/drivers/vuart/vuart.c b/xen/drivers/vuart/vuart.c
new file mode 100644
index 000000000000..ab3c2504bff5
--- /dev/null
+++ b/xen/drivers/vuart/vuart.c
@@ -0,0 +1,95 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#include 
+#include 
+#include 
+
+extern const struct vuart_ops *const __vuart_array_start[];
+extern const struct vuart_ops *const __vuart_array_end[];
+
+#define VUART_ARRAY_SIZE    (__vuart_array_end - __vuart_array_start)
+
+#define for_each_vuart(vdev) \
+    for (unsigned __i =3D 0; \
+         __i < VUART_ARRAY_SIZE && (vdev =3D __vuart_array_start[__i], 1);=
 \
+         __i++)
+
+int vuart_add_fwnode(struct domain *d, void *node)
+{
+    const struct vuart_ops *vdev;
+    int rc;
+
+    for_each_vuart(vdev)
+    {
+        if ( !vdev->add_fwnode )
+            continue;
+
+        rc =3D vdev->add_fwnode(d, node);
+        if ( rc )
+            return rc;
+    }
+
+    return 0;
+}
+
+int vuart_init(struct domain *d, struct vuart_params *params)
+{
+    const struct vuart_ops *vdev;
+    int rc;
+
+    for_each_vuart(vdev)
+    {
+        rc =3D vdev->init(d, params);
+        if ( rc )
+            return rc;
+    }
+
+    d->console.input_allowed =3D true;
+
+    return 0;
+}
+
+/*
+ * Release any resources taken by UART emulators.
+ *
+ * NB: no flags are cleared, since currently exit() is called only during
+ * domain destroy.
+ */
+void vuart_exit(struct domain *d)
+{
+    const struct vuart_ops *vdev;
+
+    for_each_vuart(vdev)
+        vdev->exit(d);
+}
+
+void vuart_dump(const struct domain *d)
+{
+    const struct vuart_ops *vdev;
+
+    for_each_vuart(vdev)
+        vdev->dump(d);
+}
+
+/*
+ * Put character to the first suitable emulated UART's FIFO.
+ */
+int vuart_putchar(struct domain *d, char c)
+{
+    const struct vuart_ops *vdev =3D NULL;
+
+    for_each_vuart(vdev)
+        if ( vdev->putchar )
+            break;
+
+    return vdev ? vdev->putchar(d, c) : -ENODEV;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/domain-emu.h b/xen/include/xen/domain-emu.h
index 410963ff480c..1d3a6c80fadd 100644
--- a/xen/include/xen/domain-emu.h
+++ b/xen/include/xen/domain-emu.h
@@ -17,6 +17,8 @@
 #define DOMAIN_EMU_PIRQ             (1U << 9)
 #define DOMAIN_EMU_PCI              (1U << 10)
=20
+#define DOMAIN_EMU_UART_PL011       (1U << 15)
+
 #endif /* XEN_DOMAIN_EMU_H */
=20
 /*
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index e10baf2615fd..e40906380760 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -59,6 +59,8 @@ domid_t get_initial_domain_id(void);
 #define is_domain_direct_mapped(d) ((d)->cdf & CDF_directmap)
 #define is_domain_using_staticmem(d) ((d)->cdf & CDF_staticmem)
=20
+bool domain_has_vuart(const struct domain *d);
+
 /*
  * Arch-specifics.
  */
diff --git a/xen/include/xen/vuart.h b/xen/include/xen/vuart.h
index 928b60bbb4e2..1f4b47575359 100644
--- a/xen/include/xen/vuart.h
+++ b/xen/include/xen/vuart.h
@@ -12,16 +12,29 @@ struct vuart_params {
     evtchn_port_t evtchn;
 };
=20
-#ifdef CONFIG_HAS_VUART_PL011
+struct vuart_ops {
+    int (*add_fwnode)(struct domain *d, void *node);
+    int (*init)(struct domain *d, struct vuart_params *params);
+    void (*exit)(struct domain *d);
+    void (*dump)(const struct domain *d);
+    int (*putchar)(struct domain *d, char c);
+};
=20
-int __init vuart_add_fwnode(struct domain *d, void *node);
+#define VUART_REGISTER(name, x) \
+    static const struct vuart_ops *const __name##_entry \
+        __used_section(".data.vuart." #name) =3D (x);
+
+#ifdef CONFIG_HAS_VUART
+
+int vuart_add_fwnode(struct domain *d, void *node);
 int vuart_init(struct domain *d, struct vuart_params *params);
 void vuart_exit(struct domain *d);
+void vuart_dump(const struct domain *d);
 int vuart_putchar(struct domain *d, char c);
=20
 #else
=20
-static inline int __init vuart_add_fwnode(struct domain *d, void *node)
+static inline int vuart_add_fwnode(struct domain *d, void *node)
 {
     return 0;
 }
@@ -35,13 +48,17 @@ static inline void vuart_exit(struct domain *d)
 {
 }
=20
+static inline void vuart_dump(const struct domain *d)
+{
+}
+
 static inline int vuart_putchar(struct domain *d, char c)
 {
     ASSERT_UNREACHABLE();
     return -ENODEV;
 }
=20
-#endif /* CONFIG_HAS_VUART_PL011 */
+#endif /* CONFIG_HAS_VUART */
=20
 #ifdef CONFIG_HAS_VUART_MMIO
=20
diff --git a/xen/include/xen/xen.lds.h b/xen/include/xen/xen.lds.h
index 793d0e11450c..1671257e19ee 100644
--- a/xen/include/xen/xen.lds.h
+++ b/xen/include/xen/xen.lds.h
@@ -194,4 +194,14 @@
 #define VPCI_ARRAY
 #endif
=20
+#ifdef CONFIG_HAS_VUART
+#define VUART_ARRAY     \
+       . =3D ALIGN(POINTER_ALIGN); \
+       __vuart_array_start =3D .;  \
+       *(SORT(.data.vuart.*))    \
+       __vuart_array_end =3D .;
+#else
+#define VUART_ARRAY
+#endif
+
 #endif /* __XEN_LDS_H__ */
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Tue Jun 24 04:01:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 04:01:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022961.1398873 (Exim 4.92)
	(envelope-from )
	id 1uTuqF-0003Qc-Ky; Tue, 24 Jun 2025 04:01:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022961.1398873; Tue, 24 Jun 2025 04:01: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 1uTuqF-0003QQ-Gl; Tue, 24 Jun 2025 04:01:03 +0000
Received: by outflank-mailman (input) for mailman id 1022961;
 Tue, 24 Jun 2025 04:01: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 1uTumk-0006IZ-W9
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 03:57:26 +0000
Received: from mail-24417.protonmail.ch (mail-24417.protonmail.ch
 [109.224.244.17]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 574ca993-50af-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 05:57:26 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 574ca993-50af-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1750737445; x=1750996645;
	bh=XBHNSuDbgBBMVwzL8Si36lrzIPH6BlSYi7VpRWP3DmY=;
	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;
	b=bnXBk56uU4B3o8hqrw5rpChmiKLfMsbyky9ML+81U/L7dns2DqJIL4R1ta73+Zklq
	 LKpZYSEfpMHdCY2aVUJY4tL9ayh0LDCf+3VhOZ2LV0xJ4LVOOkl9p5jN35AK2iI9Wk
	 b7N7D0Vs8PPdDLe1hQ5OGkIRsglVNiwKK6+ak0q+g3wMKi1Mv1pUu5bEg6ymEqmuhh
	 RpcASFCkyjUmFRW2G5bEus6IsUo2rD+3QdeAe7G0aid+QJ7gr6ZLiGR6sClj0zF8ar
	 vg6Au5UQCIdiTa+958eke45qh+SHAPzN0sbrLDKZvjvYZWVzQ/9rbIc8m1Dk6DjFyQ
	 cMzzHsBpp1U8A==
Date: Tue, 24 Jun 2025 03:57:18 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, oleksii.kurochko@gmail.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v1 16/16] drivers/vuart: hook simple MMIO-based UART to vUART framework
Message-ID: <20250624035443.344099-17-dmukhin@ford.com>
In-Reply-To: <20250624035443.344099-1-dmukhin@ford.com>
References: <20250624035443.344099-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 1977647053db5ab95117f34afa1110e2b05be770
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin =20

Add new emulation flag DOMAIN_EMU_UART_MMIO and add it to domain_has_vuart(=
).

Add needed shims for vuart framework integration to MMIO-based UART emulato=
r.

Remove domain_vuart_{init,free}() and use generic vuart_{init,exit}() calls=
.

No functional change intended.

Signed-off-by: Denis Mukhin 
---
 xen/arch/arm/domain.c          |  7 +++++--
 xen/common/domain.c            |  3 +++
 xen/drivers/vuart/vuart-mmio.c | 36 ++++++++++++++++++++++++++++++++--
 xen/include/xen/domain-emu.h   |  1 +
 xen/include/xen/vuart.h        | 20 -------------------
 5 files changed, 43 insertions(+), 24 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 3579d10d7e1d..5d7006241be0 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -780,7 +780,10 @@ int arch_domain_create(struct domain *d,
      * Only use it for the hardware domain because the linux kernel may no=
t
      * support multi-platform.
      */
-    if ( is_hardware_domain(d) && (rc =3D domain_vuart_init(d)) )
+    if ( is_hardware_domain(d) && IS_ENABLED(CONFIG_HAS_VUART_MMIO) )
+        d->emulation_flags |=3D DOMAIN_EMU_UART_MMIO;
+
+    if ( domain_has_vuart(d) && (rc =3D vuart_init(d, NULL)) !=3D 0 )
         goto fail;
=20
     if ( (rc =3D domain_vpci_init(d)) !=3D 0 )
@@ -849,7 +852,7 @@ void arch_domain_destroy(struct domain *d)
     iommu_domain_destroy(d);
     p2m_final_teardown(d);
     domain_vgic_free(d);
-    domain_vuart_free(d);
+    vuart_exit(d);
     free_xenheap_page(d->shared_info);
 #ifdef CONFIG_ACPI
     free_xenheap_pages(d->arch.efi_acpi_table,
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 071fee81fe2c..fc0ceb266d88 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -2443,6 +2443,9 @@ bool domain_has_vuart(const struct domain *d)
     if ( IS_ENABLED(CONFIG_HAS_VUART_PL011) )
         mask |=3D DOMAIN_EMU_UART_PL011;
=20
+    if ( IS_ENABLED(CONFIG_HAS_VUART_MMIO) )
+        mask |=3D DOMAIN_EMU_UART_MMIO;
+
     return !!(d->emulation_flags & mask);
 }
=20
diff --git a/xen/drivers/vuart/vuart-mmio.c b/xen/drivers/vuart/vuart-mmio.=
c
index 66fac6c994ce..1888e44e3d94 100644
--- a/xen/drivers/vuart/vuart-mmio.c
+++ b/xen/drivers/vuart/vuart-mmio.c
@@ -49,7 +49,7 @@ static const struct mmio_handler_ops vuart_mmio_handler =
=3D {
     .write =3D vuart_mmio_write,
 };
=20
-int domain_vuart_init(struct domain *d)
+static int cf_check vuart_mmio_init(struct domain *d, struct vuart_params =
*params)
 {
     const struct vuart_info *info;
     struct vuart *vdev;
@@ -86,7 +86,7 @@ int domain_vuart_init(struct domain *d)
     return 0;
 }
=20
-void domain_vuart_free(struct domain *d)
+static void cf_check vuart_mmio_exit(struct domain *d)
 {
     struct vuart *vdev =3D d->arch.vuart;
=20
@@ -147,6 +147,38 @@ static int vuart_mmio_write(struct vcpu *v, mmio_info_=
t *info,
     return 1;
 }
=20
+static void cf_check vuart_mmio_dump(const struct domain *d)
+{
+    struct vuart *vdev =3D d->arch.vuart;
+
+    if ( !vdev )
+        return;
+
+    /* Allow printing state in case of a deadlock. */
+    if ( !spin_trylock(&vdev->lock) )
+        return;
+
+    printk("Virtual MMIO UART@%"PRIpaddr" owner %pd\n",
+           vdev->info->base_addr, d);
+    printk("  RX FIFO size %u idx %u\n",
+           VUART_BUF_SIZE, vdev->idx);
+    printk("  status 0x%lx 0x%lx\n",
+           vdev->info->status_off, vdev->info->status);
+
+    spin_unlock(&vdev->lock);
+}
+
+static const struct vuart_ops vuart_mmio_ops =3D {
+    .add_fwnode =3D NULL,
+    .init       =3D vuart_mmio_init,
+    .exit       =3D vuart_mmio_exit,
+    .dump       =3D vuart_mmio_dump,
+    /* Physical console focus is not supported */
+    .putchar    =3D NULL,
+};
+
+VUART_REGISTER(mmio, &vuart_mmio_ops);
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/domain-emu.h b/xen/include/xen/domain-emu.h
index 1d3a6c80fadd..9ef607666842 100644
--- a/xen/include/xen/domain-emu.h
+++ b/xen/include/xen/domain-emu.h
@@ -18,6 +18,7 @@
 #define DOMAIN_EMU_PCI              (1U << 10)
=20
 #define DOMAIN_EMU_UART_PL011       (1U << 15)
+#define DOMAIN_EMU_UART_MMIO        (1U << 16)
=20
 #endif /* XEN_DOMAIN_EMU_H */
=20
diff --git a/xen/include/xen/vuart.h b/xen/include/xen/vuart.h
index 1f4b47575359..4c923025b4eb 100644
--- a/xen/include/xen/vuart.h
+++ b/xen/include/xen/vuart.h
@@ -60,26 +60,6 @@ static inline int vuart_putchar(struct domain *d, char c=
)
=20
 #endif /* CONFIG_HAS_VUART */
=20
-#ifdef CONFIG_HAS_VUART_MMIO
-
-int domain_vuart_init(struct domain *d);
-void domain_vuart_free(struct domain *d);
-
-#else
-
-static inline int domain_vuart_init(struct domain *d)
-{
-    /*
-     * The vUART is unconditionally inialized for the hw domain. So we
-     * can't return an error.
-     */
-    return 0;
-}
-
-static inline void domain_vuart_free(struct domain *d) {};
-
-#endif /* CONFIG_HAS_VUART_MMIO */
-
 #endif /* XEN_VUART_H */
=20
 /*
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Tue Jun 24 04:01:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 04:01:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022962.1398884 (Exim 4.92)
	(envelope-from )
	id 1uTuqH-0003hB-2S; Tue, 24 Jun 2025 04:01:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022962.1398884; Tue, 24 Jun 2025 04: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 1uTuqG-0003gr-Qv; Tue, 24 Jun 2025 04:01:04 +0000
Received: by outflank-mailman (input) for mailman id 1022962;
 Tue, 24 Jun 2025 04:01: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 1uTum2-000639-16
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 03:56:42 +0000
Received: from mail-24417.protonmail.ch (mail-24417.protonmail.ch
 [109.224.244.17]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3bdf5ff5-50af-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 05:56:40 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3bdf5ff5-50af-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1750737399; x=1750996599;
	bh=sQjr1X/MYLsD22+VDl+MPDWcSEB3K5kISaVn/vZXiZc=;
	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;
	b=b1UKBbzULeg7v54z7Ljx0Z2VGSOue5K5SfB0yMBtMo5kUuzLqPQzSRzovKOZHOO6M
	 XEfZGXLk/gHD7qNu+UBG1200PuQCdUI4WpK9GpR80v0hSUj20CynlwI10o7Mx7pa+W
	 Q/QvFBDaiysSBIY/ujsNxFa8WoTM5ZwFUNRHmZcsJgduvqBM2GKPAHwWNlEb+VMICa
	 hhKIsfjknRIypUH8rmNnoA88OgLqmvyVNnGKPUknShYXblDowddLL6ugQm4OTe0Zze
	 FHO4j1PECK3Hb8diDvzqrmdSMfq4FVtDm5VHMsb4VsIyWya3mnNvV0gYYEYMw4Px46
	 8uHpEY7CfmYZQ==
Date: Tue, 24 Jun 2025 03:56:34 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, oleksii.kurochko@gmail.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v1 11/16] xen/domain: introduce common emulation flags
Message-ID: <20250624035443.344099-12-dmukhin@ford.com>
In-Reply-To: <20250624035443.344099-1-dmukhin@ford.com>
References: <20250624035443.344099-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 46118646609cefd37d47d7fd8541f13c82208d7c
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin =20

Add common emulation_flags for configuring domain emulation features.

Print d->emulation_flags from 'q' keyhandler for better traceability while
debugging.

Signed-off-by: Denis Mukhin 
Reviewed-by: Stefano Stabellini 
---
Original patch: https://lore.kernel.org/r/20250602191717.148361-2-dmukhin@f=
ord.com
---
 xen/arch/x86/domain.c             |  2 +-
 xen/arch/x86/domctl.c             |  2 +-
 xen/arch/x86/include/asm/domain.h | 25 +++++++++++--------------
 xen/common/keyhandler.c           |  1 +
 xen/include/xen/sched.h           |  2 ++
 5 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index d025befe3d8e..fc310b1164f4 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -881,7 +881,7 @@ int arch_domain_create(struct domain *d,
                emflags);
         return -EOPNOTSUPP;
     }
-    d->arch.emulation_flags =3D emflags;
+    d->emulation_flags =3D emflags;
=20
 #ifdef CONFIG_PV32
     HYPERVISOR_COMPAT_VIRT_START(d) =3D
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 3044f706de1c..37d848f68339 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -144,7 +144,7 @@ void arch_get_domain_info(const struct domain *d,
     if ( paging_mode_hap(d) )
         info->flags |=3D XEN_DOMINF_hap;
=20
-    info->arch_config.emulation_flags =3D d->arch.emulation_flags;
+    info->arch_config.emulation_flags =3D d->emulation_flags;
     info->gpaddr_bits =3D hap_paddr_bits;
 }
=20
diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/d=
omain.h
index 8c0dea12a526..eafd5cfc903d 100644
--- a/xen/arch/x86/include/asm/domain.h
+++ b/xen/arch/x86/include/asm/domain.h
@@ -455,9 +455,6 @@ struct arch_domain
=20
     /* Don't unconditionally inject #GP for unhandled MSRs. */
     bool msr_relaxed;
-
-    /* Emulated devices enabled bitmap. */
-    uint32_t emulation_flags;
 } __cacheline_aligned;
=20
 #ifdef CONFIG_HVM
@@ -494,17 +491,17 @@ struct arch_domain
                                  X86_EMU_PIT | X86_EMU_USE_PIRQ |       \
                                  X86_EMU_VPCI)
=20
-#define has_vlapic(d)      (!!((d)->arch.emulation_flags & X86_EMU_LAPIC))
-#define has_vhpet(d)       (!!((d)->arch.emulation_flags & X86_EMU_HPET))
-#define has_vpm(d)         (!!((d)->arch.emulation_flags & X86_EMU_PM))
-#define has_vrtc(d)        (!!((d)->arch.emulation_flags & X86_EMU_RTC))
-#define has_vioapic(d)     (!!((d)->arch.emulation_flags & X86_EMU_IOAPIC)=
)
-#define has_vpic(d)        (!!((d)->arch.emulation_flags & X86_EMU_PIC))
-#define has_vvga(d)        (!!((d)->arch.emulation_flags & X86_EMU_VGA))
-#define has_viommu(d)      (!!((d)->arch.emulation_flags & X86_EMU_IOMMU))
-#define has_vpit(d)        (!!((d)->arch.emulation_flags & X86_EMU_PIT))
-#define has_pirq(d)        (!!((d)->arch.emulation_flags & X86_EMU_USE_PIR=
Q))
-#define has_vpci(d)        (!!((d)->arch.emulation_flags & X86_EMU_VPCI))
+#define has_vlapic(d)      (!!((d)->emulation_flags & X86_EMU_LAPIC))
+#define has_vhpet(d)       (!!((d)->emulation_flags & X86_EMU_HPET))
+#define has_vpm(d)         (!!((d)->emulation_flags & X86_EMU_PM))
+#define has_vrtc(d)        (!!((d)->emulation_flags & X86_EMU_RTC))
+#define has_vioapic(d)     (!!((d)->emulation_flags & X86_EMU_IOAPIC))
+#define has_vpic(d)        (!!((d)->emulation_flags & X86_EMU_PIC))
+#define has_vvga(d)        (!!((d)->emulation_flags & X86_EMU_VGA))
+#define has_viommu(d)      (!!((d)->emulation_flags & X86_EMU_IOMMU))
+#define has_vpit(d)        (!!((d)->emulation_flags & X86_EMU_PIT))
+#define has_pirq(d)        (!!((d)->emulation_flags & X86_EMU_USE_PIRQ))
+#define has_vpci(d)        (!!((d)->emulation_flags & X86_EMU_VPCI))
=20
 #define gdt_ldt_pt_idx(v) \
       ((v)->vcpu_id >> (PAGETABLE_ORDER - GDT_LDT_VCPU_SHIFT))
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index b0a2051408d5..eccd97c565c6 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -306,6 +306,7 @@ static void cf_check dump_domains(unsigned char key)
             if ( test_bit(i, &d->watchdog_inuse_map) )
                 printk("    watchdog %d expires in %d seconds\n",
                        i, (u32)((d->watchdog_timer[i].expires - NOW()) >> =
30));
+        printk("    emulation_flags %#x\n", d->emulation_flags);
=20
         arch_dump_domain_info(d);
=20
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index fe53d4fab7ba..8b16efe6afd8 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -652,6 +652,8 @@ struct domain
     const unsigned int *llc_colors;
 #endif
=20
+    uint32_t emulation_flags;
+
     /* Console settings. */
     struct {
         /* Permission to take ownership of the physical console input. */
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Tue Jun 24 04:01:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 04:01:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022966.1398894 (Exim 4.92)
	(envelope-from )
	id 1uTuqL-0004I0-Cd; Tue, 24 Jun 2025 04:01:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022966.1398894; Tue, 24 Jun 2025 04:01:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTuqL-0004Gj-8L; Tue, 24 Jun 2025 04:01:09 +0000
Received: by outflank-mailman (input) for mailman id 1022966;
 Tue, 24 Jun 2025 04:01: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 1uTult-0006IZ-Ez
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 03:56:33 +0000
Received: from mail-24418.protonmail.ch (mail-24418.protonmail.ch
 [109.224.244.18]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 366a6e5a-50af-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 05:56:31 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 366a6e5a-50af-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=4ck5bogpevd5jkat5koiapv2s4.protonmail; t=1750737390; x=1750996590;
	bh=WzrROE+QI/UTY1xrOQAZvzV0WY59/mzY+ZWQRvx/c2U=;
	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;
	b=N2YwSZg3r4hR7riv+uBnF0UBwlN1gRkqsvv+3BT4xrwLNYpVhqnZhDa0zxlZ0Iusp
	 u7EIDsUs/S14/DgcmNqpZjKBcRu0WU2QrWObJxudWFfkwcwCI/+yTgSp0FqGJdwSES
	 jGQDFubrdcEcSG9LYTK77vfFyytjeDmde6Rk7yxbbfCFc9cKuFm3g4ixixJMFHMMRx
	 ms8OtGTspelJmSpil2R52j+pjL4VB8Mt9noLv9Y44kS2uBHVDzaba8PJ/eTxF1eOst
	 XiJHUD7KiYG9btHXVjGSBwuGGWpmhf9ZODETJf2AQuPEW0aZvlyjm+BSslwim8FtjF
	 ObhvNwkfMJPGw==
Date: Tue, 24 Jun 2025 03:56:26 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, oleksii.kurochko@gmail.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v1 10/16] arm/vuart: merge vuart_print_char() with vuart_mmio_write()
Message-ID: <20250624035443.344099-11-dmukhin@ford.com>
In-Reply-To: <20250624035443.344099-1-dmukhin@ford.com>
References: <20250624035443.344099-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 5a420a27ef110bf70270096b3b46a04f5ae9dc1f
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin =20

Simplify code a bit since there's only one user of vuart_print_char().

No functional change.

Signed-off-by: Denis Mukhin 
---
 xen/arch/arm/vuart.c | 45 ++++++++++++++++++--------------------------
 1 file changed, 18 insertions(+), 27 deletions(-)

diff --git a/xen/arch/arm/vuart.c b/xen/arch/arm/vuart.c
index d2f90ab0c64f..66fac6c994ce 100644
--- a/xen/arch/arm/vuart.c
+++ b/xen/arch/arm/vuart.c
@@ -1,7 +1,5 @@
 /* SPDX-License-Identifier: GPL-2.0-or-later */
 /*
- * xen/arch/arm/vuart.c
- *
  * Virtual UART Emulator.
  *
  * This emulator uses the information from dtuart. This is not intended to=
 be
@@ -21,6 +19,7 @@
  * Ian Campbell 
  * Copyright (c) 2012 Citrix Systems.
  */
+
 #include 
 #include 
 #include 
@@ -99,27 +98,6 @@ void domain_vuart_free(struct domain *d)
     }
 }
=20
-static void vuart_print_char(struct vcpu *v, char c)
-{
-    struct domain *d =3D v->domain;
-    struct vuart *uart =3D d->arch.vuart;
-
-    if ( !is_console_printable(c) )
-        return ;
-
-    spin_lock(&uart->lock);
-    uart->buf[uart->idx++] =3D c;
-    if ( (uart->idx =3D=3D (VUART_BUF_SIZE - 2)) || (c =3D=3D '\n') )
-    {
-        if ( c !=3D '\n' )
-            uart->buf[uart->idx++] =3D '\n';
-        uart->buf[uart->idx] =3D '\0';
-        printk(XENLOG_G_DEBUG "DOM%u: %s", d->domain_id, uart->buf);
-        uart->idx =3D 0;
-    }
-    spin_unlock(&uart->lock);
-}
-
 static int vuart_mmio_read(struct vcpu *v, mmio_info_t *info,
                            register_t *r, void *priv)
 {
@@ -145,12 +123,26 @@ static int vuart_mmio_write(struct vcpu *v, mmio_info=
_t *info,
     struct domain *d =3D v->domain;
     struct vuart *vdev =3D d->arch.vuart;
     paddr_t offset =3D info->gpa - vdev->info->base_addr;
+    char ch =3D r & 0xFF; /* ignore any status bits */
=20
     perfc_incr(vuart_writes);
=20
-    if ( offset =3D=3D vdev->info->data_off )
-        /* ignore any status bits */
-        vuart_print_char(v, r & 0xFF);
+    if ( !vdev || offset !=3D vdev->info->data_off || !is_console_printabl=
e(ch) )
+        return 1;
+
+    spin_lock(&vdev->lock);
+
+    vdev->buf[vdev->idx++] =3D ch;
+    if ( (vdev->idx =3D=3D (VUART_BUF_SIZE - 2)) || (ch =3D=3D '\n') )
+    {
+        if ( ch !=3D '\n' )
+            vdev->buf[vdev->idx++] =3D '\n';
+        vdev->buf[vdev->idx] =3D '\0';
+        printk(XENLOG_G_DEBUG "DOM%u: %s", d->domain_id, vdev->buf);
+        vdev->idx =3D 0;
+    }
+
+    spin_unlock(&vdev->lock);
=20
     return 1;
 }
@@ -163,4 +155,3 @@ static int vuart_mmio_write(struct vcpu *v, mmio_info_t=
 *info,
  * indent-tabs-mode: nil
  * End:
  */
-
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Tue Jun 24 04:01:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 04:01:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022973.1398903 (Exim 4.92)
	(envelope-from )
	id 1uTuqP-0004p9-LF; Tue, 24 Jun 2025 04:01:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022973.1398903; Tue, 24 Jun 2025 04:01: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 1uTuqP-0004ov-Gm; Tue, 24 Jun 2025 04:01:13 +0000
Received: by outflank-mailman (input) for mailman id 1022973;
 Tue, 24 Jun 2025 04:01: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 1uTulk-000639-8f
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 03:56:24 +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 31584067-50af-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 05:56:22 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 31584067-50af-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1750737381; x=1750996581;
	bh=7T+qIgAVUUiUK7ZTM4nraoYQpj7JidPaaBMAqs8DTzI=;
	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;
	b=gYTSUmos3OTm/ib6bGqk3P2QXZpmK3ZA3efPElwsFB2j22ReGJzpzlNg/hquCDDue
	 7duJ8O/RT7lI2OM25Y7EdJfmy1QuD9NuWx6QIJ6ry0bfqReywOxhqHw1OtudLm72EB
	 F6nNLRX4EHVYMKSuPNlFoaJ4uJuv4lhfH1R/GhCAmS0ZikHydlXeHnNstFZFox5RfV
	 kM+roRK/2OKyym7xane8d04kqrd22y3FCSMZCmbbPOVjSFzWKafr56a7NdvGFT7eaJ
	 I/KLSS/GUTESRGJDgZlpLS1xZNil924ILXHbxpnlNWW5mCeGOIyY/wGe3aRyHrKrc2
	 2PBDgcb6cXXnw==
Date: Tue, 24 Jun 2025 03:56:17 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, oleksii.kurochko@gmail.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v1 09/16] arm/vuart: use void pointer in domain struct
Message-ID: <20250624035443.344099-10-dmukhin@ford.com>
In-Reply-To: <20250624035443.344099-1-dmukhin@ford.com>
References: <20250624035443.344099-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 73cbc7bdf76c47a54c44afdb6056201ea0f919a1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin =20

Make all public data structures private to simple MMIO-based vUART
implementation and switch struct domain to using void pointer to reduce
compile-time dependencies.

Signed-off-by: Denis Mukhin 
---
 xen/arch/arm/include/asm/domain.h | 14 ++-----
 xen/arch/arm/vuart.c              | 68 ++++++++++++++++++++++---------
 2 files changed, 52 insertions(+), 30 deletions(-)

diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/d=
omain.h
index d668c11d7e2c..38873c66f1f8 100644
--- a/xen/arch/arm/include/asm/domain.h
+++ b/xen/arch/arm/include/asm/domain.h
@@ -90,16 +90,6 @@ struct arch_domain
=20
     struct vgic_dist vgic;
=20
-#ifdef CONFIG_HAS_VUART_MMIO
-    struct vuart {
-#define VUART_BUF_SIZE 128
-        char                        *buf;
-        int                         idx;
-        const struct vuart_info     *info;
-        spinlock_t                  lock;
-    } vuart;
-#endif
-
     unsigned int evtchn_irq;
 #ifdef CONFIG_ACPI
     void *efi_acpi_table;
@@ -116,6 +106,10 @@ struct arch_domain
     void *vpl011;
 #endif
=20
+#ifdef CONFIG_HAS_VUART_MMIO
+    void *vuart;
+#endif
+
 #ifdef CONFIG_TEE
     void *tee;
 #endif
diff --git a/xen/arch/arm/vuart.c b/xen/arch/arm/vuart.c
index 5403ed284846..d2f90ab0c64f 100644
--- a/xen/arch/arm/vuart.c
+++ b/xen/arch/arm/vuart.c
@@ -29,8 +29,16 @@
 #include 
 #include 
 #include 
+#include 
=20
-#define domain_has_vuart(d) ((d)->arch.vuart.info !=3D NULL)
+#define VUART_BUF_SIZE          128
+
+struct vuart {
+    char                        *buf;
+    int                         idx;
+    const struct vuart_info     *info;
+    spinlock_t                  lock;
+};
=20
 static int vuart_mmio_read(struct vcpu *v, mmio_info_t *info,
                            register_t *r, void *priv);
@@ -44,39 +52,57 @@ static const struct mmio_handler_ops vuart_mmio_handler=
 =3D {
=20
 int domain_vuart_init(struct domain *d)
 {
-    ASSERT( is_hardware_domain(d) );
+    const struct vuart_info *info;
+    struct vuart *vdev;
=20
-    d->arch.vuart.info =3D serial_vuart_info(SERHND_DTUART);
-    if ( !d->arch.vuart.info )
+    if ( !is_hardware_domain(d) )
         return 0;
=20
-    spin_lock_init(&d->arch.vuart.lock);
-    d->arch.vuart.idx =3D 0;
+    info =3D serial_vuart_info(SERHND_DTUART);
+    if ( !info )
+        return 0;
=20
-    d->arch.vuart.buf =3D xzalloc_array(char, VUART_BUF_SIZE);
-    if ( !d->arch.vuart.buf )
+    vdev =3D xvzalloc(typeof(*vdev));
+    if ( !vdev )
         return -ENOMEM;
=20
-    register_mmio_handler(d, &vuart_mmio_handler,
-                          d->arch.vuart.info->base_addr,
-                          d->arch.vuart.info->size,
+    vdev->buf =3D xzalloc_array(char, VUART_BUF_SIZE);
+    if ( !vdev->buf )
+    {
+        xfree(vdev);
+        return -ENOMEM;
+    }
+
+    spin_lock_init(&vdev->lock);
+
+    register_mmio_handler(d,
+                          &vuart_mmio_handler,
+                          info->base_addr,
+                          info->size,
                           NULL);
=20
+    vdev->info =3D info;
+    d->arch.vuart =3D vdev;
+
     return 0;
 }
=20
 void domain_vuart_free(struct domain *d)
 {
-    if ( !domain_has_vuart(d) )
-        return;
+    struct vuart *vdev =3D d->arch.vuart;
=20
-    xfree(d->arch.vuart.buf);
+    if ( vdev )
+    {
+        xfree(vdev->buf);
+        xfree(vdev);
+        d->arch.vuart =3D NULL;
+    }
 }
=20
 static void vuart_print_char(struct vcpu *v, char c)
 {
     struct domain *d =3D v->domain;
-    struct vuart *uart =3D &d->arch.vuart;
+    struct vuart *uart =3D d->arch.vuart;
=20
     if ( !is_console_printable(c) )
         return ;
@@ -98,16 +124,17 @@ static int vuart_mmio_read(struct vcpu *v, mmio_info_t=
 *info,
                            register_t *r, void *priv)
 {
     struct domain *d =3D v->domain;
-    paddr_t offset =3D info->gpa - d->arch.vuart.info->base_addr;
+    struct vuart *vdev =3D d->arch.vuart;
+    paddr_t offset =3D info->gpa - vdev->info->base_addr;
=20
     perfc_incr(vuart_reads);
=20
     /* By default zeroed the register */
     *r =3D 0;
=20
-    if ( offset =3D=3D d->arch.vuart.info->status_off )
+    if ( offset =3D=3D vdev->info->status_off )
         /* All holding registers empty, ready to send etc */
-        *r =3D d->arch.vuart.info->status;
+        *r =3D vdev->info->status;
=20
     return 1;
 }
@@ -116,11 +143,12 @@ static int vuart_mmio_write(struct vcpu *v, mmio_info=
_t *info,
                             register_t r, void *priv)
 {
     struct domain *d =3D v->domain;
-    paddr_t offset =3D info->gpa - d->arch.vuart.info->base_addr;
+    struct vuart *vdev =3D d->arch.vuart;
+    paddr_t offset =3D info->gpa - vdev->info->base_addr;
=20
     perfc_incr(vuart_writes);
=20
-    if ( offset =3D=3D d->arch.vuart.info->data_off )
+    if ( offset =3D=3D vdev->info->data_off )
         /* ignore any status bits */
         vuart_print_char(v, r & 0xFF);
=20
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Tue Jun 24 04:01:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 04:01:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022984.1398914 (Exim 4.92)
	(envelope-from )
	id 1uTuqU-0005WE-UL; Tue, 24 Jun 2025 04:01:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022984.1398914; Tue, 24 Jun 2025 04: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 1uTuqU-0005W7-Qi; Tue, 24 Jun 2025 04:01:18 +0000
Received: by outflank-mailman (input) for mailman id 1022984;
 Tue, 24 Jun 2025 04:01: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 1uTumJ-000639-FV
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 03:56:59 +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 465b7409-50af-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 05:56:58 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 465b7409-50af-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=ecvvigt2f5a3rbsqkhru7efk5u.protonmail; t=1750737417; x=1750996617;
	bh=BmcXMAPQmruv+WgoSlVyAgGhsw5O69P+wvMsGyq48aU=;
	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;
	b=PjQXMLRiOIdDXwsAC5JMhvzlQLkF+5gHcJhwudnRGG5aoUajK2Ng3TwWnFghbBGfT
	 J84eCTNPDiL/etV6bkLSNqdoy4GsJxlUeXHjYbJ3uS5qFevV+IUUD902Do8yVvnLd9
	 GJtyOWYKtl2O57HQ4WQI4otmrChDOLWiU00QIzPwPCTH7efVh0vwPsEUgvYdzMP1WS
	 SPY0QrYpWPdxfqSKJGvUDFRXGIfvKy82MKIY+glrf5t3Qg0JdQkbxEAwuu8iyT02XK
	 kWhJyPNfDIjR7bKPZncrulrFjCrn2Ee0IVl9QCGzakZDC9LUcAHBVbPjZlM0fwZKdC
	 ho6K91g/1xHvg==
Date: Tue, 24 Jun 2025 03:56:52 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, oleksii.kurochko@gmail.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v1 13/16] drivers/vuart: move PL011 emulator code
Message-ID: <20250624035443.344099-14-dmukhin@ford.com>
In-Reply-To: <20250624035443.344099-1-dmukhin@ford.com>
References: <20250624035443.344099-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: e703f20ca9c0a634a9318d220f2e9539bd9eca76
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin =20

Move PL011 emulator to the new location for UART emulators.

No functional change intended.

Signed-off-by: Denis Mukhin 
---
 xen/arch/arm/Kconfig                               |  7 -------
 xen/arch/arm/Makefile                              |  1 -
 xen/drivers/Kconfig                                |  2 ++
 xen/drivers/Makefile                               |  1 +
 xen/drivers/vuart/Kconfig                          | 14 ++++++++++++++
 xen/drivers/vuart/Makefile                         |  1 +
 .../arm/vpl011.c =3D> drivers/vuart/vuart-pl011.c}   |  0
 7 files changed, 18 insertions(+), 8 deletions(-)
 create mode 100644 xen/drivers/vuart/Kconfig
 create mode 100644 xen/drivers/vuart/Makefile
 rename xen/{arch/arm/vpl011.c =3D> drivers/vuart/vuart-pl011.c} (100%)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index b11cb583a763..6eeae97293f2 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -170,13 +170,6 @@ config NEW_VGIC
 =09problems with the standard emulation.
 =09At the moment this implementation is not security supported.
=20
-config HAS_VUART_PL011
-=09bool "Emulated SBSA UART console support"
-=09default y
-=09help
-=09  Allows a guest to use SBSA Generic UART as a console. The
-=09  SBSA Generic UART implements a subset of ARM PL011 UART.
-
 config HAS_VUART_MMIO
 =09bool "Emulated UART for hardware domain"
 =09default y
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index dd015a2a19e8..8475043d8701 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -65,7 +65,6 @@ obj-$(CONFIG_HAS_ITS) +=3D vgic-v3-its.o
 endif
 obj-$(CONFIG_VM_EVENT) +=3D vm_event.o
 obj-y +=3D vtimer.o
-obj-$(CONFIG_HAS_VUART_PL011) +=3D vpl011.o
 obj-y +=3D vsmc.o
 obj-y +=3D vpsci.o
 obj-$(CONFIG_HAS_VUART_MMIO) +=3D vuart.o
diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig
index 20050e9bb8b3..5e533b260004 100644
--- a/xen/drivers/Kconfig
+++ b/xen/drivers/Kconfig
@@ -12,6 +12,8 @@ source "drivers/pci/Kconfig"
=20
 source "drivers/video/Kconfig"
=20
+source "drivers/vuart/Kconfig"
+
 config HAS_VPCI
 =09bool
=20
diff --git a/xen/drivers/Makefile b/xen/drivers/Makefile
index 2a1ae8ad130a..510820472938 100644
--- a/xen/drivers/Makefile
+++ b/xen/drivers/Makefile
@@ -2,6 +2,7 @@ obj-y +=3D char/
 obj-$(CONFIG_HAS_CPUFREQ) +=3D cpufreq/
 obj-$(CONFIG_HAS_PCI) +=3D pci/
 obj-$(CONFIG_HAS_VPCI) +=3D vpci/
+obj-$(CONFIG_HAS_VUART) +=3D vuart/
 obj-$(CONFIG_HAS_PASSTHROUGH) +=3D passthrough/
 obj-$(CONFIG_ACPI) +=3D acpi/
 obj-$(CONFIG_VIDEO) +=3D video/
diff --git a/xen/drivers/vuart/Kconfig b/xen/drivers/vuart/Kconfig
new file mode 100644
index 000000000000..d8df0f6d1b3c
--- /dev/null
+++ b/xen/drivers/vuart/Kconfig
@@ -0,0 +1,14 @@
+config HAS_VUART
+=09bool
+
+if (ARM_32 || ARM_64)
+
+config HAS_VUART_PL011
+=09bool "Emulated PL011 UART support"
+=09default y
+=09select HAS_VUART
+=09help
+=09  Allows a guest to use SBSA Generic UART as a console. The
+=09  SBSA Generic UART implements a subset of ARM PL011 UART.
+
+endif
diff --git a/xen/drivers/vuart/Makefile b/xen/drivers/vuart/Makefile
new file mode 100644
index 000000000000..3b7069f1cf95
--- /dev/null
+++ b/xen/drivers/vuart/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_HAS_VUART_PL011) +=3D vuart-pl011.o
diff --git a/xen/arch/arm/vpl011.c b/xen/drivers/vuart/vuart-pl011.c
similarity index 100%
rename from xen/arch/arm/vpl011.c
rename to xen/drivers/vuart/vuart-pl011.c
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Tue Jun 24 04:01:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 04:01:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1022988.1398920 (Exim 4.92)
	(envelope-from )
	id 1uTuqV-0005a0-FD; Tue, 24 Jun 2025 04:01:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1022988.1398920; Tue, 24 Jun 2025 04:01: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 1uTuqV-0005Y3-4l; Tue, 24 Jun 2025 04:01:19 +0000
Received: by outflank-mailman (input) for mailman id 1022988;
 Tue, 24 Jun 2025 04:01: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 1uTum8-0006IZ-Oh
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 03:56:48 +0000
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4084eed8-50af-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 05:56:48 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4084eed8-50af-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1750737407; x=1750996607;
	bh=5yXPb6SqgHIQ4PIoB8k8GBXcIv2K6UWy6GJUDsY9e8g=;
	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;
	b=SYKGEdQ5sWCwPY6yPcDMhM+HBEIdbuJpsGuY1gSC5qpUJMqIPkoUdzIRKnJX92uNP
	 MtKjJZhD31QHJnIrXD3+gq0mUqzI+lntp6G9A7J+8LQoLloHKNR4y7nHbaF3gKskyH
	 eDP/biNweisrUTzDLZiOuR8GTlCbzMJ45wL7RNwjbVI67aLTi0eQGRNbTIe6tAnIUY
	 TUn/rRdBOC42Dlj6R7FwM6X4Ce4djcKH1za6o7mWN1Z4LtGpc8jF1BNmUzkFiJ6XOP
	 N0rING2hWudN/qmy8gMJy/8U/pUYjJRLFySPmXhXYLpxr0eAG86XD/v/3CDftMAoCF
	 PlFQw/m8y4cUQ==
Date: Tue, 24 Jun 2025 03:56:43 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, oleksii.kurochko@gmail.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v1 12/16] xen/domain: introduce domain-emu.h
Message-ID: <20250624035443.344099-13-dmukhin@ford.com>
In-Reply-To: <20250624035443.344099-1-dmukhin@ford.com>
References: <20250624035443.344099-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: b341b04a459a662589cb5e9b9a7be4c7a9828afd
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin =20

Define an architecture-independent location for describing domain emulation
flags.

Signed-off-by: Denis Mukhin 
---
Original code: https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v=
1-6-c5d36b31d66c@ford.com/
---
 xen/arch/x86/include/asm/domain.h | 23 ++++++++++++-----------
 xen/include/xen/domain-emu.h      | 30 ++++++++++++++++++++++++++++++
 2 files changed, 42 insertions(+), 11 deletions(-)
 create mode 100644 xen/include/xen/domain-emu.h

diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/d=
omain.h
index eafd5cfc903d..c6bc83b4abe0 100644
--- a/xen/arch/x86/include/asm/domain.h
+++ b/xen/arch/x86/include/asm/domain.h
@@ -3,6 +3,7 @@
=20
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -458,16 +459,16 @@ struct arch_domain
 } __cacheline_aligned;
=20
 #ifdef CONFIG_HVM
-#define X86_EMU_LAPIC    XEN_X86_EMU_LAPIC
-#define X86_EMU_HPET     XEN_X86_EMU_HPET
-#define X86_EMU_PM       XEN_X86_EMU_PM
-#define X86_EMU_RTC      XEN_X86_EMU_RTC
-#define X86_EMU_IOAPIC   XEN_X86_EMU_IOAPIC
-#define X86_EMU_PIC      XEN_X86_EMU_PIC
-#define X86_EMU_VGA      XEN_X86_EMU_VGA
-#define X86_EMU_IOMMU    XEN_X86_EMU_IOMMU
-#define X86_EMU_USE_PIRQ XEN_X86_EMU_USE_PIRQ
-#define X86_EMU_VPCI     XEN_X86_EMU_VPCI
+#define X86_EMU_LAPIC    DOMAIN_EMU_LAPIC
+#define X86_EMU_HPET     DOMAIN_EMU_HPET
+#define X86_EMU_PM       DOMAIN_EMU_PM
+#define X86_EMU_RTC      DOMAIN_EMU_RTC
+#define X86_EMU_IOAPIC   DOMAIN_EMU_IOAPIC
+#define X86_EMU_PIC      DOMAIN_EMU_PIC
+#define X86_EMU_VGA      DOMAIN_EMU_VGA
+#define X86_EMU_IOMMU    DOMAIN_EMU_IOMMU
+#define X86_EMU_USE_PIRQ DOMAIN_EMU_PIRQ
+#define X86_EMU_VPCI     DOMAIN_EMU_PCI
 #else
 #define X86_EMU_LAPIC    0
 #define X86_EMU_HPET     0
@@ -481,7 +482,7 @@ struct arch_domain
 #define X86_EMU_VPCI     0
 #endif
=20
-#define X86_EMU_PIT     XEN_X86_EMU_PIT
+#define X86_EMU_PIT     DOMAIN_EMU_PIT
=20
 /* This must match XEN_X86_EMU_ALL in xen.h */
 #define X86_EMU_ALL             (X86_EMU_LAPIC | X86_EMU_HPET |         \
diff --git a/xen/include/xen/domain-emu.h b/xen/include/xen/domain-emu.h
new file mode 100644
index 000000000000..410963ff480c
--- /dev/null
+++ b/xen/include/xen/domain-emu.h
@@ -0,0 +1,30 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef XEN_DOMAIN_EMU_H
+#define XEN_DOMAIN_EMU_H
+
+/*
+ * Domain emulation flags.
+ */
+#define DOMAIN_EMU_LAPIC            (1U << 0)
+#define DOMAIN_EMU_HPET             (1U << 1)
+#define DOMAIN_EMU_PM               (1U << 2)
+#define DOMAIN_EMU_RTC              (1U << 3)
+#define DOMAIN_EMU_IOAPIC           (1U << 4)
+#define DOMAIN_EMU_PIC              (1U << 5)
+#define DOMAIN_EMU_VGA              (1U << 6)
+#define DOMAIN_EMU_IOMMU            (1U << 7)
+#define DOMAIN_EMU_PIT              (1U << 8)
+#define DOMAIN_EMU_PIRQ             (1U << 9)
+#define DOMAIN_EMU_PCI              (1U << 10)
+
+#endif /* XEN_DOMAIN_EMU_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Tue Jun 24 04:20:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 04:20:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023045.1398933 (Exim 4.92)
	(envelope-from )
	id 1uTv8m-0003Zr-2S; Tue, 24 Jun 2025 04:20:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023045.1398933; Tue, 24 Jun 2025 04:20:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTv8l-0003Zk-W8; Tue, 24 Jun 2025 04:20:11 +0000
Received: by outflank-mailman (input) for mailman id 1023045;
 Tue, 24 Jun 2025 04:20: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 1uTv8j-0003ZO-Is
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 04:20:10 +0000
Received: from mail-24416.protonmail.ch (mail-24416.protonmail.ch
 [109.224.244.16]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7ea44f8c-50b2-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 06:20:01 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7ea44f8c-50b2-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=w3tumghdxnddrnv33t4pl64rly.protonmail; t=1750738800; x=1750998000;
	bh=EYYkmXjOENemakgw0TcCwSLXJu0cRjU9Ir4rUnc6dxk=;
	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;
	b=hx042SHsEY3U2rOCY4IWok2QD8yGuTvim4rdq4SWeKYsT30N0laZZlbjWiUXH0Bef
	 K1q/8uU5Q6s0meCnUTJpiaXjxuUCCn0o+iXncfDUV2bxRejFtM6gUYzf4uYhEXqI8E
	 Duv2+pJs6yla/0mPMz+eGOPFcLEkQl1lcP8PZUY4bb7fmYKGUbyegTadHsMo0vfe/F
	 SB4qJCCaIeFgu6qGZaSjJMODwISf6/xsjDjTC95yabJGdlwcofL2S4gBgb3DbgNADS
	 c+lOsQpJ8XC9P60dME+89xk7z+WQmBLOl57ud6Pr0qw1x3o3VfSpNXnMRZ+5d2dRNe
	 uxuOqw/QgXchg==
Date: Tue, 24 Jun 2025 04:19:56 +0000
To: Jan Beulich 
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v1] xen/domain: fix memory leak in domain_create()
Message-ID: 
In-Reply-To: 
References: <20250623011514.173367-1-dmukhin@ford.com> 
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 59c3443fc97bb0de9a88ccac0d1063c1a91a810a
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 23, 2025 at 10:09:54AM +0200, Jan Beulich wrote:
> On 23.06.2025 03:16, dmkhn@proton.me wrote:
> > From: Denis Mukhin 
> >
> > Fix potential memory leak in domain_create() in late hardware domain ca=
se.
> >
> > Fixes: b959f3b820f5 ("xen: introduce hardware domain create flag")
> > Signed-off-by: Denis Mukhin 
>=20
> Reviewed-by: Jan Beulich 

Thanks.

Just in case, I've seen the patch is committed as
  3491e85a1505  ("xen/domain: fix memory leak in domain_create()")
but there's no R-b tag.

>=20
> It may be relevant to mention that we still can't very well use "goto fai=
l"
> on this error path, as insufficient struct initialization was done just y=
et.
>=20
> What we may want to consider is to move down the get_unique_id() invocati=
on.
> It's not the end of the world to lose one, but that may better be avoided
> when we easily can.
>=20
> > ---
> > I think that no memory allocation is required before performing late hw=
dom
> > checks (ID range and hwdom existance).
> >
> > Looks like sanitise_domain_config() could better fit for performing suc=
h
> > configuration checks.
> >
> > Alternatively, hardware_domid range could be checked via custom parser
> > instead of code in domain_create() and then hwdom existance can be move=
d
> > before alloc_domain_struct().
> >
> > Thoughts?
>=20
> Keeping related things together is the other desire we commonly have.

Yeah, I see this is to avoid duplicated checks, but verifying hardware_domi=
d
range definitely can be moved outside of domain_create()=20

This superfluous memory allocation will need a test case in cert world sinc=
e
this is arch-common code :-/
So, IMO, it is better to avoid it.

>=20
> Jan



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 05:25:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 05:25:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023055.1398943 (Exim 4.92)
	(envelope-from )
	id 1uTwA4-0005Pm-LK; Tue, 24 Jun 2025 05:25:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023055.1398943; Tue, 24 Jun 2025 05:25: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 1uTwA4-0005Pf-Ib; Tue, 24 Jun 2025 05:25:36 +0000
Received: by outflank-mailman (input) for mailman id 1023055;
 Tue, 24 Jun 2025 05:25: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 1uTwA3-0005PZ-2T
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 05:25:35 +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 9e547465-50bb-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 07:25:19 +0200 (CEST)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3a548a73ff2so3616f8f.0
 for ; Mon, 23 Jun 2025 22:25:19 -0700 (PDT)
Received: from ?IPV6:2003:ca:b711:f2f9:d2d:164b:59bd:2475?
 (p200300cab711f2f90d2d164b59bd2475.dip0.t-ipconnect.de.
 [2003:ca:b711:f2f9:d2d:164b:59bd:2475])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4535eac92c6sm164145305e9.22.2025.06.23.22.25.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 22:25:18 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9e547465-50bb-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750742719; x=1751347519; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=JjJf1d0Da1yRQ7o0Lc9Soesx+IV28z3Sgzaq6Fkcm2Q=;
        b=M20mF8QpDq+HjpdmaunUJ4F91V5vvnWyvb+RPM7rodsLP3BTYjy225CkSXlyWnsQx4
         taXrNH+kKBeNIdnjOiUkrA55BQvrfLIUfmJ8+GNtiUVhEivhTLXb05oeZnmBeoLU0U7m
         KxqxMIemeuc+Uz5jHN0whL1PerqxPjjcgcxMBKm8LdBGZYHjj0vFqZFZAE9Xi7/0sSbC
         VBGSHwQxB4ornPgi5SjDr3mNSRbWhNVpcG68yn/8IHwbQJ80ZvnwT1OYZ/8+XPCVT01o
         YVhji0ERHAQgHJ4TZxIoglcOJI+aFzccx705JmU06k/wkBrSqcbATGfcutVMtgyfPjTx
         Xrsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750742719; x=1751347519;
        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=JjJf1d0Da1yRQ7o0Lc9Soesx+IV28z3Sgzaq6Fkcm2Q=;
        b=s5qQAJIWukX2pMfIbg0ssOVAd+Bb7flrOrnYxsEKKChBkljHtVFJplHWIOSRmfrfvc
         erv5PzN/irYXlD5LVeIyhSSypveYn/m2IV4js/zWgddmc9MJ9liv07pMmdftu4MdJVnO
         U9ND3Vf5vvrJvd4MCKssp+sog/ciJGCX4UYDDnXswe6ZDq51oD6gqKGf4FF5Wimw+XWr
         2STBcqFkTec1YJgrlyCy06bmzC0LdeTaPdQF0l8OMVJMDc3347xDJOZNSlC6RuhiFAnh
         n/WaqAgzvkkMFE6XlvlK/6QAViD/fBEM4Mh3xJZ8qLwTSIzpjshPn0/StZwNFdgUl4Nv
         GNSg==
X-Forwarded-Encrypted: i=1; AJvYcCVxEDU+hme2aojY+WPAlCwJ/OuDPcnlZq5iZbndmkC47meQW5pFXxGJ4RXqvaY8iZfJvlux6njT9Kw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyIDRRFhQ6qMU3cdYY1BlL2dU7l65IpgqLLqYYKhdrzQBxkRkgP
	X2vYTl0cJyOkXbn3KqESFw4u5d3FzrbJuzZRxE3gz3cdEsOLI4xnukDO/b/C9UfFhw==
X-Gm-Gg: ASbGnctZtWoh1KdCCXLv+fT65svbdajAKDVwwleBNvN5ZBVwtl88Qe4ZvnPWT7ETGOZ
	8wIG2svWJQnmSwXLWhzTmjwIen87VO6HuZBmPzBbPiq6nZb43F6fpZwLMdDGHjCK3fRJTSJLLOV
	doXnODuUvkw4Mi6lRHzUgX9mBDcdvQqWiQJqPx4iDxcTa6pBjNP8eOopY9Ck8XCd/jRXw1toF8D
	74hkRCv19QIDqx6bD/7uygcR2MCBPmFoawTT0WeEyVJWAlZxsKFjbmT+1f6/QS0TbS/AlYToA/l
	llsDeRuNKnFM1CQOwMScV1S/Zee3l2faLfi+9PVr+vfhqKX00A0pwiCN6HsDchZgLhOGGq9Obwe
	w1PfRKP1FJ6BfO99545gfKh0z3nbbuTmvmFuNMGRT1WeFl9qifv91mWfvGw7aMwnmB39O+fdxri
	7SAM9772ShESvXxyJgkg==
X-Google-Smtp-Source: AGHT+IFGTtl98d3mU4ACsFuXa5aFZObWzRC56aiPgkmpS2yxfTvfGZpZUIhZ0Cz+4N7r3Pds/662LA==
X-Received: by 2002:a05:6000:4188:b0:3a4:dbac:2dc1 with SMTP id ffacd0b85a97d-3a6d1313c09mr8875477f8f.54.1750742718880;
        Mon, 23 Jun 2025 22:25:18 -0700 (PDT)
Message-ID: <381dba84-3108-42c8-a4e5-7bc74d5e1075@suse.com>
Date: Tue, 24 Jun 2025 07:25:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: hardware domain and control domain separation
To: Stefano Stabellini 
Cc: jason.andryuk@amd.com, Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Andrew Cooper ,
 Anthony PERARD ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , ayankuma@amd.com,
 xen-devel@lists.xenproject.org, demiobenour@gmail.com
References: 
 <942a6178-0fe7-468e-8e45-ea255fd20680@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 24.06.2025 00:51, Stefano Stabellini wrote:
> On Mon, 23 Jun 2025, Demi Marie Obenour wrote:
>> On 6/23/25 11:44, Jan Beulich wrote:
>>> On 21.06.2025 02:41, Stefano Stabellini wrote:
>>> Also a more fundamental question I was wondering about: If Control had
>>> full privilege, nothing else in the system ought to be able to interfere
>>> with it. Yet then how does that domain communicate with the outside
>>> world? It can't have PV or Virtio drivers after all. And even if its
>>> sole communication channel was a UART, Hardware would likely be able to
>>> interfere.
> 
> There are well-established methods for implementing domain-to-domain
> communication that are free from interference, such as using carefully
> defined rings on static shared memory. I believe one of these techniques
> involves placing the indexes on separate pages and mapping them
> read-only from one of the two domains.

How's that going to help with the backend refusing service, which I view
as one "method" of interference? Or else, what exactly does "interference"
mean in this context? (More generally, I think it is necessary to very
clearly define terminology used. Without such, words can easily mean
different things to different people.)

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 05:43:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 05:43:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023063.1398954 (Exim 4.92)
	(envelope-from )
	id 1uTwQw-0001vc-0f; Tue, 24 Jun 2025 05:43:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023063.1398954; Tue, 24 Jun 2025 05: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 1uTwQv-0001vV-U8; Tue, 24 Jun 2025 05:43:01 +0000
Received: by outflank-mailman (input) for mailman id 1023063;
 Tue, 24 Jun 2025 05: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 1uTwQv-0001vP-78
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 05:43: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 164fda6b-50be-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 07:42:59 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-43edecbfb46so33825255e9.0
 for ; Mon, 23 Jun 2025 22:42:59 -0700 (PDT)
Received: from ?IPV6:2003:ca:b711:f2f9:d2d:164b:59bd:2475?
 (p200300cab711f2f90d2d164b59bd2475.dip0.t-ipconnect.de.
 [2003:ca:b711:f2f9:d2d:164b:59bd:2475])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4535ebcecb5sm165211135e9.37.2025.06.23.22.42.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 22:42:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 164fda6b-50be-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750743779; x=1751348579; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=YII/pg33QDjWUEY7B65NUePtYiEVx/EClHtlZV0meDY=;
        b=cjTS0CPEZtAIFEolRrZT7GN+Gi8ByZKTXUQqcpR+sdgHPh+GsOdfXWHgXgtIJOy/hJ
         G1+cmL3HX5tl218lJ9iEGdiERnBMXFRkT/+eAYdb26AjnYgruylwOAJRIzELrfixYBdh
         wi6u+5gecWPkxTFdAUjIOqjUi1Szxt1In7ivjdHhGf1PmZMDaRp45F6nIreL/POCTSUf
         3bSSufYi+aKvRvt4A0nIgzaxAHOmJQFIvC9AKij3lQSs9sqKAt2PvsSQIWSXEAlD3cb4
         cmYBFal91rqxQVDh73f9ZU4ljWI0fNVWfXUkF6EJb44nil7ojwXbxDL/fU5aRSCrSw23
         3Frw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750743779; x=1751348579;
        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=YII/pg33QDjWUEY7B65NUePtYiEVx/EClHtlZV0meDY=;
        b=Tg1n8BGWOJ8Rkc4+PjsHJ7sCiz7wW/F5UGw4YUH104J+DBIaoqAviF/np5ubAftvoO
         zVTbKEnU53q2DryE/kZOy5SC7EPANdu5b3oH1HJf777rxuTbq+NhPXJezsQdK7ZGvOyl
         /EMOnMYcF+8gli0MLm53LsCWsy+irnc5tT7jFPsy0s6SOV23mS0pg2TnUI1/4UDKPLmy
         8Mk7nBaDh3NHNiGygoYH2nnoTYZUYC/gUGTlg62iSHmkoO774qtV4OUy8SNE+Ze0e+9k
         s5PsFcEwOp+7bbkI4tFYep8QuS/4ZOt8lsW0+Hwdumiq29V08a0CAQtvQAmzscenjNJy
         FtPw==
X-Forwarded-Encrypted: i=1; AJvYcCUy1FHWn6ZV7lHOj2qr/U4HNVWFzs3CAzLVOT75NUTFryxKTF851+8jz5kdulMFAFJehkDJKXdRfV8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxamo1pE6uOtiElijNR24o5lwJLC7XOV3kv9Wf4l3qvXxVyLXCY
	zLRd8XGmkIN6ews0CkHbgbeTRjdZ3kWV4898VGIIQK3sGyaYGicuNPfDvPog4klqKA==
X-Gm-Gg: ASbGnct7AC2OSMAs7TgLD6z37QVDCnH1Cdq2dDnHD4Y5IkY8s++Ds4XtaNKhs0HYmoY
	VnvJXYDCnK6fJ+vO/60+ZxHKsapCFkTRLrXCqewZfqYmfg1HmLMFGtifN4UOr1VvjNpDI1G1Urn
	RljI+lhJsG43bQ9n0jc4j8kZWl/ZKeHsquR/ZUIDUcgRa2MdvJiuj3/qtTgp6b4s4bDHVui2h2O
	Q4SJ8c5RJSla5qv+RnIjEOB1zSLMxaGUNo4A+eayghYDig2gO18fVHXtzZO+RBmSLzOzFza4vdd
	XG26ci/SbTXJEDnRdTATbN4tA0wQn/x/b3xMxjalpdr/Q1qzOoD+GwINUp+ofLjuSii9eqqOriU
	GFOePVH8ZuynfMrRlNoy2GrwqdDlqUF7uFCRB66E6+amZPihZcJR8STSQGEI9PaMl1YbwBYAEFO
	3hrOneDXtmEC4oh5LUBg==
X-Google-Smtp-Source: AGHT+IG5+cap860JXD2/phP74gzUqDLovGSeEphWO1D5NzNq5T5iDnicpibE0V0RBR7FmPF80o+hfg==
X-Received: by 2002:a05:600c:81c8:b0:441:d4e8:76cd with SMTP id 5b1f17b1804b1-453659f6a8cmr144683075e9.29.1750743779200;
        Mon, 23 Jun 2025 22:42:59 -0700 (PDT)
Message-ID: 
Date: Tue, 24 Jun 2025 07:42:58 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] xen/x86: address violations of Rule 11.3
To: victorm.lira@amd.com, Nicola Vetrini 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?B?Um9nZXIgUGF1IE1vbm7Dg8Kp?= ,
 Stefano Stabellini ,
 Federico Serafini ,
 Bertrand Marquis , xen-devel@lists.xenproject.org
References: <20250624002018.4121819-1-victorm.lira@amd.com>
 <20250624002018.4121819-2-victorm.lira@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: <20250624002018.4121819-2-victorm.lira@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 24.06.2025 02:20, victorm.lira@amd.com wrote:
> From: Nicola Vetrini 
> 
> Use {get,put}_unaligned_t to ensure that reads and writes are
> safe to perform even on potentially misaligned pointers.

Also applicable to the Arm patch: Please can such patches mention the
main subject of the rule, not just the number?

Overall I'm unconvinced we really want or need this on x86; I'm curious
what Andrew and Roger think. Further, even beyond the respective remark
below, I'd be pretty surprised if these were all of the places that
would need fiddling with. Mind me asking how the places to touch were
identified? (This may actually be a good thing to mention in the
description.)

> @@ -388,7 +392,7 @@ static int init_or_livepatch apply_alt_calls(
>              return -EINVAL;
>          }
> 
> -        disp = *(int32_t *)(orig + 2);
> +        disp = get_unaligned_t(int32_t, orig + 2);
>          dest = *(const void **)(orig + 6 + disp);

Why is this latter line not also adjusted? The field is expected to be
aligned, yes, but for the code here there's no guarantee. Imo if this
was left alone along with applying the suggested change, a code comment
would need adding.

> --- a/xen/arch/x86/include/asm/hvm/vlapic.h
> +++ b/xen/arch/x86/include/asm/hvm/vlapic.h
> @@ -10,6 +10,7 @@
>  #define __ASM_X86_HVM_VLAPIC_H__
> 
>  #include 
> +#include 
>  #include 
> 
>  #define vcpu_vlapic(x)   (&(x)->arch.hvm.vlapic)
> @@ -85,13 +86,13 @@ struct vlapic {
>  static inline uint32_t vlapic_get_reg(const struct vlapic *vlapic,
>                                        uint32_t reg)
>  {
> -    return *((uint32_t *)(&vlapic->regs->data[reg]));
> +    return get_unaligned_t(uint32_t, &vlapic->regs->data[reg]);

This, aiui (or should I say "I hope"), also addresses another violation
(casting away of const). Such will want mentioning in the description,
imo.

> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -1249,7 +1249,7 @@ void asmlinkage __init noreturn __start_xen(void)
>                 (caps & 2) ? " V2" : "",
>                 !(caps & 3) ? " none" : "");
>          printk("EDID transfer time: %d seconds\n", caps >> 8);
> -        if ( *(u32 *)bootsym(boot_edid_info) == 0x13131313 )
> +        if ( get_unaligned_t(u32, bootsym(boot_edid_info)) == 0x13131313 )

When touching such, please can you also convert to uint_t?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 05:46:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 05:46:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023069.1398963 (Exim 4.92)
	(envelope-from )
	id 1uTwUd-0003Bj-E3; Tue, 24 Jun 2025 05:46:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023069.1398963; Tue, 24 Jun 2025 05:46: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 1uTwUd-0003Bc-BW; Tue, 24 Jun 2025 05:46:51 +0000
Received: by outflank-mailman (input) for mailman id 1023069;
 Tue, 24 Jun 2025 05:46: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 1uTwUc-0003BV-Du
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 05:46:50 +0000
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com
 [2a00:1450:4864:20::330])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9f351e79-50be-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 07:46:49 +0200 (CEST)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-453634d8609so39405e9.3
 for ; Mon, 23 Jun 2025 22:46:49 -0700 (PDT)
Received: from ?IPV6:2003:ca:b711:f2f9:d2d:164b:59bd:2475?
 (p200300cab711f2f90d2d164b59bd2475.dip0.t-ipconnect.de.
 [2003:ca:b711:f2f9:d2d:164b:59bd:2475])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a6e80ff799sm1004652f8f.69.2025.06.23.22.46.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 22:46:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9f351e79-50be-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750744009; x=1751348809; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=WwjJqIiD+vRIY+U9Ab2FDWWcE9p4j6eu5LP3+GPVKCI=;
        b=Ngw/QZVxwFupSrHlnlFW8k+gafqhxi3Mm9yN7AAVWLeykA+x6CZasVOartQ+hjdaAc
         Jpq1GAo4VcOhQYH44ib6wcXLDiECjnWsfPjZ+a2UUZRVRKGH3i/Eu0SpkvcnardKosjw
         bGXcakjV5w+GeUORikQ2AJ+FUh0DDfn460ullvT4F91fq+e7i2WFZ7iAbuIzNxZcYMGd
         DPnDhE95OD+tiRf0V2nVmuevGtUEiMvz228252rZvDwFC+9BxfPYcgfp6mChdVDVvLPB
         DlJPooAtUGT4GyU0/g3WjOxFQKMClHphXT8E0YmoWJqh4xPZ25ArJqkJPbYVNISkcVn9
         xUiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750744009; x=1751348809;
        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=WwjJqIiD+vRIY+U9Ab2FDWWcE9p4j6eu5LP3+GPVKCI=;
        b=RIiQyvAhhuAQoXCUbq7y5g1S/BKYSY/bkFl+NC0IL1QKPc5tVr9K/mKMkyOn7VeGsr
         mVPkClq60hVvWUTpBjIEQuhjfchjLY8RQusU4RrrKgbZzD/pMeEICQWtbXfyWDF5ki9m
         a5CFz0hLTQcKaIm7tZp79d07gHiOdsV2onGtJN3ljo1v+YL2dshF0E/BghtGghqnr7Je
         DTM+1KufRB+fRzU7glZ4zC3/HKl2AOecghphF6SSdkSIq5qvO8ss6LiWfC16rHztmxIG
         faaI69iiKBIkvffIEMP6JeDEac2Xcc/rNDY1vmPqx7LiAvA+QkwOmCMZDXDMho0Jvqui
         U0ZA==
X-Forwarded-Encrypted: i=1; AJvYcCWA4ngsfBIN5b6f2aQAvtfTv6fYCgvkjHl9S4W5x9omxIOPFuuM+DoguVACJQjLDlf5NZwQkMb8pLo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxR9QtThCyNe5Gq6QSIHKzwm09+t39ginO2Gw3WJKWn5HwDV40P
	jNicWrJxvZT568cYyD24ytIIw+yu1gk7rvFo6DvN9wWDydBjeXigGjUzUvhk4rLrnQ==
X-Gm-Gg: ASbGncszuo2mgmF/1Q7hLXbo40+egpTo6V3Gd1wZBP2sd3Ga+K+XoYB7V7l48PXSgnK
	s8Wi03VHdo2mHwTXlbv/k9B7wnxbUL5B5VPBcB3yKZKLFNpJVroWwZRzXl5mqy1vJVrfmT+08w/
	ftOFBqQWEoYwXhxuhbsYj1Wk6l0kUqTy4/xkwDHNG1vLP5gQNmJvHbeRosRkGi1zVsXPoQIJyBb
	SG4vda8cPAj5+gYx2vAWhqIxNBtFZVPV4MhDBclYSWlmBKmgTI5N3oL1M3TykDvDZ+AFivpaq74
	o0mJA9tKfeTgvZPJTSxlGatDv7wykIstftyLJDn+eh8inmQQWhRzap/zKcbW3SCGcv6/UGAFO/8
	vadBNeptiOxo0Q6+vlJxizuhCX19YVwOxmzp4dzDV4cfI6VO84F31w0wkoPCzidnhbB8WoROUlf
	ZFnPQy063aGHMWp3pWfA==
X-Google-Smtp-Source: AGHT+IF2Avmc6DE2VARtmB6K1L/+AwYTXrhPkBsZTYZ6JH+u+yhLaZPAAP6PQXcgk7PPAA3F7AqzXA==
X-Received: by 2002:a05:6000:4903:b0:3a4:dcb0:a5f with SMTP id ffacd0b85a97d-3a6d12a21d6mr12380692f8f.16.1750744008951;
        Mon, 23 Jun 2025 22:46:48 -0700 (PDT)
Message-ID: <08cb7878-fad7-47f4-9c91-5f866c54b1df@suse.com>
Date: Tue, 24 Jun 2025 07:46:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 04/16] arm/vpl011: use raw
 spin_lock_{irqrestore,irqsave}
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, oleksii.kurochko@gmail.com, roger.pau@citrix.com,
 sstabellini@kernel.org, dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250624035443.344099-1-dmukhin@ford.com>
 <20250624035443.344099-5-dmukhin@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: <20250624035443.344099-5-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 24.06.2025 05:55, dmkhn@proton.me wrote:
> From: Denis Mukhin  
> 
> Replace VPL011_{LOCK,UNLOCK} macros with raw spinlock calls to improve
> readability.

I'm not an Arm maintainer, so I have limited say here, but: How is this
improving readability? It better utilizes available local variables, yes,
so this may be a little bit of an optimization, but otherwise to me this
looks to rather hamper readability.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 05:50:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 05:50:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023079.1398973 (Exim 4.92)
	(envelope-from )
	id 1uTwYI-0004kC-1a; Tue, 24 Jun 2025 05:50:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023079.1398973; Tue, 24 Jun 2025 05:50: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 1uTwYH-0004k5-VD; Tue, 24 Jun 2025 05:50:37 +0000
Received: by outflank-mailman (input) for mailman id 1023079;
 Tue, 24 Jun 2025 05:50: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 1uTwYG-0004jz-Gc
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 05:50:36 +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 25dcd7db-50bf-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 07:50:35 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3a53359dea5so2383553f8f.0
 for ; Mon, 23 Jun 2025 22:50:35 -0700 (PDT)
Received: from ?IPV6:2003:ca:b711:f2f9:d2d:164b:59bd:2475?
 (p200300cab711f2f90d2d164b59bd2475.dip0.t-ipconnect.de.
 [2003:ca:b711:f2f9:d2d:164b:59bd:2475])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4535eada7adsm166545225e9.35.2025.06.23.22.50.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 22:50:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 25dcd7db-50bf-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750744235; x=1751349035; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=HB7iLFXg4b/ij/EZdtrHNAjWItdhh4KH8xY/4DGCqrE=;
        b=gBonfCFrsSs4S+gGPCU33N7vXP6s0SFx0WhtZi7tZU1Fr7moB1vKCCq6HknzlICczd
         3AEC+6SyYhIIo+Vgam3TtKeY+ViCwe5ISHUhrS+sF31zxmX4uiCa84NpngiKy9yrp1r4
         3aEp/yv431+ALYX58230FBlN/JEGe1BxXGINhOl3IQBU5rC/Voi56WMEmQxGH39CqLrs
         +brmLNxWsQbMyCuk7E6np1DHTorGLebI1ILSJG0IPksOqPfNeUEcu6YMWe3sWDkQRP7c
         XF31BSWiSD9TFEckfP10PyaG5waMMnZoxwuy0qOgw5nJke9K+IL6kKCRqGPvCopbjkfw
         cnDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750744235; x=1751349035;
        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=HB7iLFXg4b/ij/EZdtrHNAjWItdhh4KH8xY/4DGCqrE=;
        b=o6uv1j0zCSp3ySnLb5QzxWf+uItPeq9yov911SIb+JgrcyeD1JtwZzKgnAwS9hY0QJ
         h4QG1eHTrA2L84L2tjzHyG6vnRxhJhcpvtkHvhpMBlj4ULR9Qb02CJnbPh/c9jufS6Ez
         4vAeAGy9lYROpvQuS27g5hRrkwwTuIJPC01myj3V9OSYVenRaDQftdwAnkkv7Z3Gc/jl
         kUrXpccYZAIUsbx7Nb3N65AoJ74Y06k1giivTEOJJD54Hlg6RU6LzxdhQoyPnKvazctG
         TeTyiw30iWLOJQRylYKEE71czSODvv9zBJ62+2PbhRKCbAOxT6ZUUBSSf2A2tonN62xv
         5thA==
X-Forwarded-Encrypted: i=1; AJvYcCW57iKRnN5N4M8Ok37e8zAvmeJqjM15HKDaKjGhtoiaBHWA2X5iJ12psecvSpzYdUeQngPnqS2cmOk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyphRsLuxKz4+sgXeZAXSq5OoPZXwuPbrtzjO5uqcHAy769/kiw
	2vBp7vThWPhjOZ2cSOSZNHhjyErJRgnP0rYbIYo9Bsk62aqn5pWv4FbIOg/PJ5QMBw==
X-Gm-Gg: ASbGncsMCtqaTUMQPky89v5Ug6Ax8jXfjdRPnIqG/935L6NoF0G9mdAQA9rvWULVQTj
	IdP9E8/1mn0aiMG/z9flNVWoYixgTnucW/oYzQFYe1ENt3QD22XfYM8I735VErpVHW175r+hL68
	mF8mhTlwwTgrhaZP2Xfz1ZL4PltBvxHmRRtIDJDuZX5TMazeAImFcsmQMEPGFl+mc36+iBxF1Pt
	7SQcKCmtSF9ntlcP9DXo7ISBIbUTxSOMWMa0X8pNCjJgQztyBivlF3yDJMo5H35iiaOv8n9wc7r
	YfJeyfkno5ku2WhAhj4IRucyK4AChSvl90WDQdd35gQLGHpWBLK3+68bLiUXvrikPtkigo0E0lz
	WNZ+4PLxIYDk3nC9/yO1rQtm8iUMLENYv63QFMGuiOQs5NaP4E6m1d7XKYWqaxC9XtHkXsWZTwk
	OENBlsXmAR1UOSosWW4dN8gwH3bGXu
X-Google-Smtp-Source: AGHT+IEJ4/J4xqEOAFBPIpQZL4lncdgODu9XZJzYHmFynzz8iBowRH3vnPAKrO/qMX2apIBtuK1Eag==
X-Received: by 2002:a05:6000:2911:b0:3a3:7cbd:39b1 with SMTP id ffacd0b85a97d-3a6d12e2888mr13575355f8f.24.1750744234749;
        Mon, 23 Jun 2025 22:50:34 -0700 (PDT)
Message-ID: <6b2938a2-aa42-421f-b948-44e74f463b21@suse.com>
Date: Tue, 24 Jun 2025 07:50:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 13/16] drivers/vuart: move PL011 emulator code
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, oleksii.kurochko@gmail.com, roger.pau@citrix.com,
 sstabellini@kernel.org, dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250624035443.344099-1-dmukhin@ford.com>
 <20250624035443.344099-14-dmukhin@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: <20250624035443.344099-14-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 24.06.2025 05:56, dmkhn@proton.me wrote:
> From: Denis Mukhin  
> 
> Move PL011 emulator to the new location for UART emulators.
> 
> No functional change intended.
> 
> Signed-off-by: Denis Mukhin 
> ---
>  xen/arch/arm/Kconfig                               |  7 -------
>  xen/arch/arm/Makefile                              |  1 -
>  xen/drivers/Kconfig                                |  2 ++
>  xen/drivers/Makefile                               |  1 +
>  xen/drivers/vuart/Kconfig                          | 14 ++++++++++++++
>  xen/drivers/vuart/Makefile                         |  1 +
>  .../arm/vpl011.c => drivers/vuart/vuart-pl011.c}   |  0
>  7 files changed, 18 insertions(+), 8 deletions(-)
>  create mode 100644 xen/drivers/vuart/Kconfig
>  create mode 100644 xen/drivers/vuart/Makefile
>  rename xen/{arch/arm/vpl011.c => drivers/vuart/vuart-pl011.c} (100%)

I question the placement under drivers/. To me, driver != emulator. I
wonder what others think. But yes, we already have drivers/vpci/. That
may want moving then ...

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 05:53:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 05:53:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023086.1398983 (Exim 4.92)
	(envelope-from )
	id 1uTwaj-0006oR-EQ; Tue, 24 Jun 2025 05:53:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023086.1398983; Tue, 24 Jun 2025 05:53: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 1uTwaj-0006oK-Bs; Tue, 24 Jun 2025 05:53:09 +0000
Received: by outflank-mailman (input) for mailman id 1023086;
 Tue, 24 Jun 2025 05:53: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 1uTwai-0006oE-3y
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 05:53:08 +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 7fa6683d-50bf-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 07:53:06 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a54700a46eso8914f8f.1
 for ; Mon, 23 Jun 2025 22:53:06 -0700 (PDT)
Received: from ?IPV6:2003:ca:b711:f2f9:d2d:164b:59bd:2475?
 (p200300cab711f2f90d2d164b59bd2475.dip0.t-ipconnect.de.
 [2003:ca:b711:f2f9:d2d:164b:59bd:2475])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4535e9844a9sm165777755e9.12.2025.06.23.22.53.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 22:53:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7fa6683d-50bf-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750744385; x=1751349185; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=GByEpZ7h9aA9Uz+2nf0djki6A3F5D/O/zjRClaIujIE=;
        b=ec85ok+fvucrUwae0TsqiZxlv1nscKAzLmtxbuaseMN3F5ye3xZ5Q38zOqFrZE5j9u
         Q4tBFPzxYagmNny6RK063BYhz+Ypt8oNjyrwhYbEhDcH+yEv5gS5rEuRZZ1fThm8240X
         +tGt7X/0ZemqmGkql+3DD5MrjnT8bB8U2Qj8mlkAOCNXQ/ixsCiVW7P/sO7/h62fOn6G
         bCQR/u5ALoWZjNtUGnEJ7ucFMKZMAql2ULb1yQXa7dWhh54C7ct1IY7hl0GlmUkF5Sl4
         n7GczkckBzkCgguvCenyUuzeO/P5d0rKeYd6OLQDRZz8JOA4O9NbjGYLW/DlkOaAnc8+
         /5cA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750744385; x=1751349185;
        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=GByEpZ7h9aA9Uz+2nf0djki6A3F5D/O/zjRClaIujIE=;
        b=Bah5Fg3atlNrUHLsIlt+QLdRkVdfTjKEwOI2ueyh7+/MlT/9EbP/vzjdMoLfwkE3BW
         qE2gj8wIEyNFuhTMfDPwDRZTBjz0WbCW5BBW9gvZTbAseHzH6rEX3tciCNbE6X8Zj12A
         ZgB10XevVn8ErIN/mdBEMwVDv+tPebGxKvW4x6Vby8XFrIjJYLv/FwBy65hHCuQlP7mP
         LnbNSwYIkBDH3QZmA4rOkcniId2wd5f67DqGfE36YBBooAojxvmKEA7BgfpEJcsDiU/J
         3zOtY3iaXOzrlL6bTkfby6A+HsFDMa308WR5B/uZf7TBEVkHLMD+tjQJNM78AoIAh+X2
         3VrA==
X-Forwarded-Encrypted: i=1; AJvYcCXgWpiDK7qzRFd8cbukdtx1yBHFRmJJhb8jPt0XFqKxWHv5S24AwERZ0viMmj85CqL/bFJs+QHWZrU=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yytxn2vwZE0EjnkfbhyKC/etP/7Nh0s4DqK6E1PCZnql+l/tpIo
	eOcG/s1SAeZccXqyGruVW3GTMDMIM1OoD15STV0Z1IhanD6cdR2kuWC1dxoeDfee1Q==
X-Gm-Gg: ASbGnctvMMSbPIRCfNd3D58fVBD8h8+2cZ23cKDkRcATWSbxUpEE/23zRmvl4+l6880
	qjI51H6sk4ZQS5+TRZUiagxGLK2YIyO0Bf0+WZpbv2tMItIDiIYY+rAThHZx1Lgy6sQcWf+g7k4
	HY3MhugaCeS7qFJS6rUL6ug0+DkX5ja607EDg2njBlFM5YEXxMW42xluRyOf5XgIYZABua2zxEQ
	bXtDWvdFWOwQisDcm9wSCzFlfhB+cetSWQ8xU89OJpYfwwh0TEgXoAGLMhhLugK1yyy/0l/Kh0l
	EBU3Am5zUO8LlTmY8GXF0Nv84kFxeBsv1gV8/5koDl77Blz3JP6cycppchMTOtmwy5P+GUAccGh
	R1MtHw/pFwDbBDHeGx7/IO6jcmHZHZxmzoXO9STMopfuEJYSf9h2SwmIFITWERY2zORrAJ25ZZ9
	WQOfLRNhQSphLIdAROuA==
X-Google-Smtp-Source: AGHT+IHqLUP1YAhCSKk9yznJRi8SBcYoZiSeRnXJI6JTA/JSFqighhMNjXJnpc4TdPi0aSzr11LUTw==
X-Received: by 2002:a05:6000:2307:b0:3a4:eef5:dece with SMTP id ffacd0b85a97d-3a6d1322b53mr14027852f8f.35.1750744385526;
        Mon, 23 Jun 2025 22:53:05 -0700 (PDT)
Message-ID: <6e6c8664-2ff6-484d-bd47-7ee12c449f9e@suse.com>
Date: Tue, 24 Jun 2025 07:53:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 14/16] drivers/vuart: move simple MMIO-based UART
 emulator
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, oleksii.kurochko@gmail.com, roger.pau@citrix.com,
 sstabellini@kernel.org, dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250624035443.344099-1-dmukhin@ford.com>
 <20250624035443.344099-15-dmukhin@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: <20250624035443.344099-15-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 24.06.2025 05:57, dmkhn@proton.me wrote:
> --- a/xen/drivers/vuart/Kconfig
> +++ b/xen/drivers/vuart/Kconfig
> @@ -3,6 +3,15 @@ config HAS_VUART
>  
>  if (ARM_32 || ARM_64)
>  
> +config HAS_VUART_MMIO
> +	bool "Simple MMIO-based emulated UART support"

Perhaps in a separate change this should be renamed. HAS_* should never
have prompts.

> +	default y
> +	select HAS_VUART

This is questionable too (for still being controlled by a prompt), but
may need to remain as is.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 05:58:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 05:58:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023092.1398994 (Exim 4.92)
	(envelope-from )
	id 1uTwfs-0007OD-0V; Tue, 24 Jun 2025 05:58:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023092.1398994; Tue, 24 Jun 2025 05:58: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 1uTwfr-0007O6-U6; Tue, 24 Jun 2025 05:58:27 +0000
Received: by outflank-mailman (input) for mailman id 1023092;
 Tue, 24 Jun 2025 05:58: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 1uTwfr-0007O0-CZ
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 05:58:27 +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 3df94715-50c0-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 07:58:25 +0200 (CEST)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-45363645a8eso122345e9.1
 for ; Mon, 23 Jun 2025 22:58:25 -0700 (PDT)
Received: from ?IPV6:2003:ca:b711:f2f9:d2d:164b:59bd:2475?
 (p200300cab711f2f90d2d164b59bd2475.dip0.t-ipconnect.de.
 [2003:ca:b711:f2f9:d2d:164b:59bd:2475])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-453769da7f6sm49058255e9.40.2025.06.23.22.58.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 22:58:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3df94715-50c0-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750744705; x=1751349505; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=fA64XLLXaOWg/barh+VGMBQmAJDfhHcRQX2io5oVFKQ=;
        b=E8IFGIwVFa4s5ovrNhJtmpRBkpq9mfdPAe4Y9QL9ZyAr6ypoLewLRYmlXIctHSRaZJ
         nyHmYyaMfOSG2RdrUdbGE91nO6g5ktHFbj3IMXErFAbS56SMxO0nQmxsXNFsW1KXicwb
         LOa5Qg14HBnVx5hnV4eFkxsJJwm5p3vPs6FcghwYXOqJqmtHdRMF8HBVDEuKJxauYcFw
         0JGUUmV2RSchJbOvH6XmRH0Fsh0uhdICu1TlvUnWKkT7lJpC+p5OhQr+mNoLSk90Gx7B
         5lZXF5MHGJqqjsUtHrniDTiFxrpyh8uBdVqSzuX1C4+7ZhkO5VZe9iALAFvFeDeHTcct
         RCEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750744705; x=1751349505;
        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=fA64XLLXaOWg/barh+VGMBQmAJDfhHcRQX2io5oVFKQ=;
        b=WSAleYch7LZMZQ3JgdFEkMPMtgCVMjkGDVQk5O6eTBKHEX2TflBcRyPmeKXIHQPeDk
         qKtd6xX9SFRFBiwQN18rR4JKGWuOqRAFDDwnqqDO7Miiea1K1cOct5JJDcH5OkPj9MKi
         Znv8jpj7T7pw9Pnyxqno1TE1CksMBZGAUvVEzzV2lvg9UFy00qoowvmMkxLpxuW3Uvoz
         p/v2Iqqs+Ww5p8ydIYCsQ8ugPaIUCLSj4w3DM7Qy+uBb6Ku8i37H/VmTCCcfkODW/OX2
         5uMUxKYn3uZTrfZUa4u37YSeRn6z17j7Kd/M15faffJik6GLGyUqViM4V1Db5TP50cK2
         kWsA==
X-Forwarded-Encrypted: i=1; AJvYcCU1zXdwLEaIUy3WAMS8FpUFjwVZHMAyWLql+MhxbQlY2iY7C3bOs4iq3M3l+9cep64T7m7dnZDVS9E=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwO/wihai2H/9G7GeUuU4b7+SBCVSkplwbnOVV55GRcFG4E2d3l
	KMLXYBxW0pyHDZqiBhKfq+QFva/V2Np5dtq7mqkbpZ1+L5IdJnWYBC+pb2G2Ibvc7w==
X-Gm-Gg: ASbGncuoHmMzzgI4P1deJWG7zjdtdDqDAcRtAoViUjm6mGGucFnIwo4ymacK72lBjfm
	Ku4m8GCUvTmlheSlpy663GQeBeMpCUTkXDyxsYDU6EA+rsb1XVtc2Nlt5Cx91RF1Ovo+CcGg+hy
	Pgd1fcGLC8BOQubh52Zit1pntcWsmy074OZqoKjNULqcpz3oqfQJNeigMZzlQceSkuV2tdpS0Eu
	CdXPVQwY+EFSJu773NYm1AO3GsU8lsqb7aY84mwYQtwREY5GvJnkDLLKeUKJkU92iL/5dBWYYqy
	Y2IBWPf+g/fwFaOTk3bmi8JRTosMRPjWpy9Jmv7HWYuX914yEzca0QFRK4DS2XrpYD7+v4ZNAgi
	U6bv6qiYvliKc7BgK4UImVbirfqSlS28yLVHskxNTAonWE9lh3/dDbdQ2sQk1BuFdSIXCl/auRl
	vvYPZZQrhZ4JIiRHbDSw==
X-Google-Smtp-Source: AGHT+IGz1u0VS0S47EcvyuhHVrICLkRvQhA5/UfUCwgSXjPcak+OSlCJfS9SuH8qq5yFhzq0AVittQ==
X-Received: by 2002:a05:600c:1f14:b0:453:5d8d:d1b8 with SMTP id 5b1f17b1804b1-453659c4169mr151058945e9.30.1750744704722;
        Mon, 23 Jun 2025 22:58:24 -0700 (PDT)
Message-ID: <5ddcd969-cdb8-4ec7-8272-d7d733865fab@suse.com>
Date: Tue, 24 Jun 2025 07:58:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v10 1/3] xen/domain: unify domain ID allocation
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org,
 dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250623182721.194238-1-dmukhin@ford.com>
 <20250623182721.194238-2-dmukhin@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: <20250623182721.194238-2-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 23.06.2025 20:28, dmkhn@proton.me wrote:
> @@ -2433,6 +2443,71 @@ void thaw_domains(void)
>      rcu_read_unlock(&domlist_read_lock);
>  }
>  
> +domid_t domid_alloc(domid_t domid)
> +{
> +    static domid_t domid_last;
> +
> +    spin_lock(&domid_lock);
> +
> +    /* Exact match. */
> +    if ( domid < DOMID_FIRST_RESERVED )
> +    {
> +        if ( __test_and_set_bit(domid, domid_bitmap) )
> +            domid = DOMID_INVALID;
> +    }
> +    /*
> +     * Exhaustive search.
> +     *
> +     * Domain ID#0 is reserved for the first boot domain (e.g. control domain)
> +     * and excluded from allocation.
> +     *
> +     * In dom0less build, domains are not dynamically destroyed, so there's no
> +     * need to do a wraparound of the IDs.
> +     */
> +#ifdef CONFIG_DOM0LESS_BOOT
> +    else if ( domid_last + 1 >= DOMID_FIRST_RESERVED )
> +    {
> +        domid = DOMID_INVALID;
> +    }
> +#endif

With this, ...

> +    else
> +    {
> +        domid = find_next_zero_bit(domid_bitmap,
> +                                   DOMID_FIRST_RESERVED,
> +                                   domid_last + 1);
> +#ifdef CONFIG_DOM0LESS_BOOT

... was this meant to be #ifndef?

> +        if ( domid == DOMID_FIRST_RESERVED )

This needs to be >=.

> +            domid = find_next_zero_bit(domid_bitmap,
> +                                       DOMID_FIRST_RESERVED,
> +                                       1);
> +#endif
> +
> +        if ( domid < DOMID_FIRST_RESERVED )
> +        {
> +            __set_bit(domid, domid_bitmap);
> +            domid_last = domid;
> +        }
> +        else
> +        {
> +            domid = DOMID_INVALID;
> +        }
> +    }
> +
> +    spin_unlock(&domid_lock);
> +
> +    return domid;
> +}
> +
> +void domid_free(domid_t domid)
> +{
> +    if ( domid < DOMID_FIRST_RESERVED )

Is this legitimate to happen? IOW doesn't this want to be some kind of
assertion?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 06:08:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 06:08:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023099.1399003 (Exim 4.92)
	(envelope-from )
	id 1uTwp9-0002CS-R8; Tue, 24 Jun 2025 06:08:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023099.1399003; Tue, 24 Jun 2025 06:08: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 1uTwp9-0002CL-OM; Tue, 24 Jun 2025 06:08:03 +0000
Received: by outflank-mailman (input) for mailman id 1023099;
 Tue, 24 Jun 2025 06:08:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uTwp8-0002CF-ID
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 06:08:02 +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 930a26bb-50c1-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 08:07:57 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-453066fad06so151935e9.2
 for ; Mon, 23 Jun 2025 23:07:57 -0700 (PDT)
Received: from ?IPV6:2003:ca:b711:f2f9:d2d:164b:59bd:2475?
 (p200300cab711f2f90d2d164b59bd2475.dip0.t-ipconnect.de.
 [2003:ca:b711:f2f9:d2d:164b:59bd:2475])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4535eac8e0asm164433285e9.23.2025.06.23.23.07.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 23:07:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 930a26bb-50c1-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750745277; x=1751350077; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=msz8tMbNWaI6lpFLJaHTLWRxd9pAkhJLKqkuuQ5T81g=;
        b=d3JqMrkmO9ak0z9WEA/jsa4lDpd7AV/rxCIlA1YWw3EHNy4H3F9+OWh8hWKVqVgrM+
         iEsh1IK8Rm3TdPGVGXP+bAIboN8KgVGN7FL6fSrJ9hELHWQEgJ1qZG+aZoZ1Iy0fYrt0
         iyILjQedx3WlLgNQGBH9Zht54CIPtf0gaNBQ4ijdm6RLhO9lraUwNSzX1JFObHYzCONC
         FpNsbHw7egd2+7uDKvpvahpfYDtdgK1Vr3ScZbTRkAOp0HOQWjX4EqFgTKdQ/HAbxwXY
         0/TjAHXlO0Cl4IxFGuVBNPDSMcmuUSESvNwQgGYjNf9nceSgNGkJZ6+sfTrEu4wdjMaJ
         pm0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750745277; x=1751350077;
        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=msz8tMbNWaI6lpFLJaHTLWRxd9pAkhJLKqkuuQ5T81g=;
        b=h0oz4vEADFfZdnZnlvxsBKbfGfsrv3K0GWDhUryX2fsAl+jtBEJCm1ckETC/MSNRa+
         NcSMtZwVMf9+ttJsBqwCn+qFAOj5n+JxDM6eel0aT/sXTxHQANlVx8IY+dO0wOHMldzS
         5U0h3OuLVe5zkoKsuSJd2XmDbm/SkRBM7U3ODgKpFyM3ChNiXGanI/uKo1TBthDdOOKu
         UbiUPThPAGGUV2P3H27d4W9JNFVOZ5GAhH6DhswTkMUoloXlIP2waKM9lG2ORlI5EyZb
         kZTPtjlTiZHASLwTVeNEy6Ura2D4xW/Z1zkPnoFuD1Dbg1j/5tIpeAezZ1H9pZtQFBTO
         pk4g==
X-Forwarded-Encrypted: i=1; AJvYcCWk77zWE1Edz6F4CjQAprukKWP8e1R7THPGVg+uH0Ti4ZZiW1Dp4LiREemI3AExzMlnZoHDd8N513o=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxq4c1NRhdMYd2iAiOdO4tnKHQzox+Ihpto0j0nN283JAM2sI2b
	KKPn2L/Tcxc1faapFE2Ceu4SLMHtrBKBM25N762YJIQgz+MKHKkqaPPg9szOcFCZmw==
X-Gm-Gg: ASbGncvV3QWZTADeVWnp5cuxJUvsSztdfiOaQ9P7oLK6EIyHLxq5J5qQnWH7kzRxZnx
	D5S3611FgJ5G7FlDzV/Q+QpG1UzLTFc191uTn/TZn++sYbNq/RXDaLkT6HzQFC+gAtD77GxZG/k
	Bu5hbkbJplF4WWAnNhi1225XLyJen2Sw/yaE2sdsTZQkDYLQlQEEFxezHga69XEDnRiEb2qp7bF
	mIy/uOdIFLP9UU/3sR/1gjmuPSaKz65EMuVR6aYLIanU0dRQ7Kwuwym1hiPkm1vFBIgOqgLKUhO
	PYnshl7RUdTpTM9pm9bwjMpaszHw3Q2y9yfXjyC4/s806h7rYfRkfb/YdHZNRwHEJwd6Pf4aVlh
	4nmyVeuMk7yUsRCs0ko9ymsIFjs5rMfmOtUWCLSNdnS8SBJ/BsmABI1mNKfZPN+fLd4ZW1Q4tTC
	ALGQpsm+jB25BK7HheiA==
X-Google-Smtp-Source: AGHT+IEiPPVo52xKGNgs6VhbRDPtNhgjrTWfgmq+zcfDLx97hMmrNcoOXDIgnNHefMX8ma2W1yhNJA==
X-Received: by 2002:a05:600c:a209:b0:450:d00d:cc with SMTP id 5b1f17b1804b1-45365392622mr82554835e9.2.1750745276980;
        Mon, 23 Jun 2025 23:07:56 -0700 (PDT)
Message-ID: <93080cb5-d00d-4c58-9efd-c377343eb165@suse.com>
Date: Tue, 24 Jun 2025 08:07:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v10 3/3] xen/domain: use get_initial_domain_id() instead
 of open-coded 0
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org,
 dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250623182721.194238-1-dmukhin@ford.com>
 <20250623182721.194238-4-dmukhin@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: <20250623182721.194238-4-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 23.06.2025 20:28, dmkhn@proton.me wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -492,7 +492,7 @@ static int late_hwdom_init(struct domain *d)
>      struct domain *dom0;
>      int rv;
>  
> -    if ( d != hardware_domain || d->domain_id == 0 )
> +    if ( d != hardware_domain || d->domain_id == get_initial_domain_id() )
>          return 0;
>  
>      rv = xsm_init_hardware_domain(XSM_HOOK, d);
> @@ -501,7 +501,7 @@ static int late_hwdom_init(struct domain *d)
>  
>      printk("Initialising hardware domain %d\n", hardware_domid);
>  
> -    dom0 = rcu_lock_domain_by_id(0);
> +    dom0 = rcu_lock_domain_by_id(get_initial_domain_id());
>      ASSERT(dom0 != NULL);

For both changes above you're introducing a subtle (largely theoretical)
behavioral change: In shim mode, this assertion, if we somehow made it
here, would suddenly not trigger anymore. Similarly for the earlier
change the return path may wrongly be taken then.

> @@ -2479,7 +2479,7 @@ domid_t domid_alloc(domid_t domid)
>          if ( domid == DOMID_FIRST_RESERVED )
>              domid = find_next_zero_bit(domid_bitmap,
>                                         DOMID_FIRST_RESERVED,
> -                                       1);
> +                                       get_initial_domain_id() + 1);

This imo is the worst of the changes. get_initial_domain_id() can return
non-zero. In that case we still would (in principle) want to re-start
from 1 here.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 06:11:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 06:11:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023110.1399013 (Exim 4.92)
	(envelope-from )
	id 1uTwsI-0003zT-BP; Tue, 24 Jun 2025 06:11:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023110.1399013; Tue, 24 Jun 2025 06: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 1uTwsI-0003zM-8s; Tue, 24 Jun 2025 06:11:18 +0000
Received: by outflank-mailman (input) for mailman id 1023110;
 Tue, 24 Jun 2025 06:11: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 1uTwsG-0003y3-D5
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 06:11:16 +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 0874fc67-50c2-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 08:11:14 +0200 (CEST)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-453066fad06so167455e9.2
 for ; Mon, 23 Jun 2025 23:11:14 -0700 (PDT)
Received: from ?IPV6:2003:ca:b711:f2f9:d2d:164b:59bd:2475?
 (p200300cab711f2f90d2d164b59bd2475.dip0.t-ipconnect.de.
 [2003:ca:b711:f2f9:d2d:164b:59bd:2475])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a6e8109728sm1015666f8f.82.2025.06.23.23.11.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 23:11:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0874fc67-50c2-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750745474; x=1751350274; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=W1QzhyfwToBoxFhW+A1SUZaMdU32sCbyjFDgTEr98l4=;
        b=J1hHh+5iiQ3Khb5n0jw3a1evreRwWKtgl2RLexqSU0x6k5tncQCWevr2KFWnCEnLyN
         KQYlSH1yYxDJn4+cOe9zFpmXlgYfnh+wkrOkS3AUf7ayL0jwaTQbRkkfXIlk27u1u7kA
         QUTHBU6VF+EPfVHv7AoBK3emh/5ZceuW7EO4TSDBcPPq1ZKMqgA1vP0iER8u2KgLaes+
         G/X5vKXL3z7yQT1txHRdNzB74NORHYaA1g9kuXuyj3tm7I1iwS5jwhqzrupStzyESR5H
         pNkiXDBGk6/IyDqEspsxwNKNNLPC+DoBXe+ZVYuXHZ/znrVNCvEPVqrBwJqzilbt21f1
         Rl8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750745474; x=1751350274;
        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=W1QzhyfwToBoxFhW+A1SUZaMdU32sCbyjFDgTEr98l4=;
        b=unkqGMLk9ANL3pfm8M+XmG+wUBwOv2ijM+fidMbWYN7RsGK+tJuZ48CHcTkpscPpTO
         T47Bc54ygUH2inkOTDBtFKrH0ZCDAaUpKZ/oT1aFHguDTXyj7ppmlCQAFfYXhqeg3YO4
         1EPsBcHctBabAPpWOZZIYzJyrww9SbBU1H+a2oowR7GFC9KNAivxPDxHtOiBngu11nYQ
         KWVRnbIaegSqnjhQgeCIcdAehlnqvhcKIuI4YDAj1xjan6Re5RJ3v9QJbKufojEC6fVC
         IRdtnDuJrOUdXbqaInCmPWJKI7imUKjscMf1GxMtFPoQUq9dS0br2yC+kNNd2Tbaf/Ic
         sAIQ==
X-Forwarded-Encrypted: i=1; AJvYcCXyz3kvZJ265zslk+h9OnJBTlk5N+Zy10VCh925Yvq8s3LhXphfZ6NqtnFgE2uqjI9qUI9t19063QA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz5MJVjZ5mtki774iozTV3KP41uo6osJW2TeNVxGIx6ae9J+DKG
	/1MGv7lZcJXnacEsXZZw2hFlRwj/QFzRif5v/OeNulv8V3wZLRwDvERVY92rJGzReg==
X-Gm-Gg: ASbGncuxHuD2yF2UggVnjBS3ziYwsA6R4tlwFKqG5Oo/VfZA2Lf4Yno22KI9+BwzxB/
	HNfwVbGIughcbMKMv/VWy6ZYA6dWUg2oZ3R3Se328Dv282j7Mudyv/5WyyyECZ5k8I6uPPTyoTd
	t1BiqPYDtcpbfLGtp9jACXVZllWsK8eOKYzAMVORzoSzR4fNUj1PdO0ayRaa+ae1CrR0RfmTt/7
	TrkRWvukFCETbZLFiiNTcRfxSwIV54hl3fp2K28BjTyKjk0SpziyClRhj6tqAN5XXVx1lkaz9bL
	9k128FEOfxmXV6wEhzultX5o3fhYNWFC1mZwFvg28df+4WkToisjnnqkDGukasdRq9KsGbeG1A/
	W08R75dzX+j5LjT72SpEFnEzk/AE+8/u0Czc8OlskbCjEcfwBp6FWh0pwE0Q2xxGbcoq6FPzg9n
	ZCF5tr/1rWjyWJI4vBMA==
X-Google-Smtp-Source: AGHT+IHIKOIGaPJxhUWBzCKhUX8Efb0U/rFeIunkGNXLVsDJ0z96MluIDjiB8i2mLzQJysEApoG3iA==
X-Received: by 2002:a05:6000:400f:b0:3a4:df80:7284 with SMTP id ffacd0b85a97d-3a6d11932bemr12606503f8f.1.1750745474011;
        Mon, 23 Jun 2025 23:11:14 -0700 (PDT)
Message-ID: <0c6d5b49-ce69-4f16-b61e-ad1378b20807@suse.com>
Date: Tue, 24 Jun 2025 08:11:13 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] docs/misra/rules.rst: allow string literals with memcmp
To: Stefano Stabellini 
Cc: andrew.cooper3@citrix.com, michal.orzel@amd.com, julien@xen.org,
 roger.pau@citrix.com, Bertrand Marquis ,
 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 24.06.2025 01:45, Stefano Stabellini wrote:
> Rule 21.16 is about the types of arguments allowed for memcpy.

Seeing the subject - is it memcmp(), memcpy(), or both? (Writing from
home, where I don't have the Misra spec to hand, and hence can't check
what coverage the rule has.)

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 06:13:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 06:13:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023116.1399023 (Exim 4.92)
	(envelope-from )
	id 1uTwuG-0005DI-NU; Tue, 24 Jun 2025 06:13:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023116.1399023; Tue, 24 Jun 2025 06:13: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 1uTwuG-0005CO-KC; Tue, 24 Jun 2025 06:13:20 +0000
Received: by outflank-mailman (input) for mailman id 1023116;
 Tue, 24 Jun 2025 06:13: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 1uTwuE-0005Bn-VF
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 06:13:19 +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 5177a4d4-50c2-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 08:13:17 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by DS7PR12MB5910.namprd12.prod.outlook.com (2603:10b6:8:7b::7) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8857.29; Tue, 24 Jun 2025 06:13:13 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8857.026; Tue, 24 Jun 2025
 06:13: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: 5177a4d4-50c2-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=FB3YT5YLVdFIAtJ1HxgSr1Fkko+uGVj6O3MNABPZMUawbs99whMUmf8Fag46RUh5MVPfen4kHknhbK3yChaXmeoDa1ply8C95Xv0Dnm72YK2IUwFV4cHzoXhxar1VxsiKXpt0nMs98LukFSIf+sbusslkwwFNSEyf0GiAgriJYItLmmDfFH0qIqC6wTVsYr/j6jIJfqohjLbKLUyvT4SmxoBPCfgasK92ghREPgggeGeAz7Xfm+gitRgk54k4/8vBjFDmWyk5Lp/4+ULt26qiJCQWySr7QI/6VlMItPp5PC14iWfL0USa8+ejcyW/vgwyRqUpYXHb/SWLnzXFDpe6Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=cLInNVO5VPJEv3CPWloDyLH7X9uRtgBj61XjP3Xl46c=;
 b=sVnZ/WNs1tzYgpX/JgHVdgiTlCkCX9NKKcsc1uA8FcGqlbS4qbu1FdpW72TpLJDSAxsV0kpXMhv7DPMgairGQXEy5+ZCbm7T1+kcgeX+1M89lU+xlMhxbD4kLzUHe+Ej0C1U+QtxlDa4PnJB0+VPTXq421T4I1vb4y7jYt4fB5wKVXJSx3LqXt9GW0m6pReJ+wtCcOuO/jfvEht9RCOAfXP9dvmmtMaKW9GYxsoO6AWbxoiwPbHlauUTEZfjaArtViZhSPlYiyhoIVTFdRoNopEGXihBnnX5UgEU3d8MIVLgiU0ICnW3TCjjrc1JPAllTDezXt6HKp6zlI/kmAM/oA==
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=cLInNVO5VPJEv3CPWloDyLH7X9uRtgBj61XjP3Xl46c=;
 b=v2vXwdmGFd+edYvTM6nHriFa7DXVlG4W01k0LvVj1ycSjSMaioeIJB4Me7Vd6EBC6js2s4d1FB1e2gh8LL2GAheYENjthW+LZTgsvsIuRlX2bwGJAddoULG85IScqHskt0sz1d0FL05/oNel2IvCIbIVYFhQNWtnMhcUgj/H8vk=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Tue, 24 Jun 2025 08:13:08 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 01/16] arm/vpl011: rename virtual PL011 Kconfig option
To: dmkhn@proton.me, xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com,
 julien@xen.org, oleksii.kurochko@gmail.com, roger.pau@citrix.com,
 sstabellini@kernel.org, dmukhin@ford.com
References: <20250624035443.344099-1-dmukhin@ford.com>
 <20250624035443.344099-2-dmukhin@ford.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250624035443.344099-2-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR4P281CA0231.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:e9::11) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|DS7PR12MB5910:EE_
X-MS-Office365-Filtering-Correlation-Id: c0db42b4-9ecd-4313-7c3d-08ddb2e63372
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|366016|7416014|1800799024|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?ZEJaU0FONUlVS3pZaWpkOWNzYmhlR1kzbmNoZS9wQnBMd3gvVU12SC9NU1la?=
 =?utf-8?B?bzdJNklwOVMvT0l4R1N2b0tpMFdYNzlLUTlQbXZqMkhkdm5DQzhPWFFXbmJz?=
 =?utf-8?B?UzBZdVJUazNhQXBWalZQMlhNQ1MvVUt2dTNwemhIeW9IbHR5cHNYRWZTaWlp?=
 =?utf-8?B?ZmYrQk1UMnl3VU00MFNYdnltRFJQaU11bXJnZlBTS21IUmJIVUgvRGJXam40?=
 =?utf-8?B?SUltSTBVL08ycmhUbDM5R055THhWemtIMHpEeHRXOStITkVkaklBRXV1dGNl?=
 =?utf-8?B?cGYwaktZSzhuMEgybkZvZWVucVlYekdFa0ZsOStxMXFCUWsvcEg2ZFZxb1NE?=
 =?utf-8?B?cWdBZUpwMFAxQ2RTUCtXWnF2dk1sakJNR3p6d1BOeUJFTVFwL0lHSFJSVWhM?=
 =?utf-8?B?bUJrZUZ0SHpWOVFySDhVckJraGNYR1N0OXVFQ3dxZWRhRDdHNG5HcEthdEJB?=
 =?utf-8?B?RG1IeGkzK1E3dWppOFEvSFVDYWQrQWVVbUxTOWtIbHdWYWhDTGxVNm9tRkNW?=
 =?utf-8?B?NW1udy96a2lkekw3OElmcDlRY2ZpdEZNcUZVZC9maDFlSGhWaFVJaVZ6V0FY?=
 =?utf-8?B?UFprNnRSQ213YzhrTmxRbDhCRSs0NUd5QTh4eStvUHhKeTNveU5QTUtYUUN3?=
 =?utf-8?B?T3QrWElBbmdGTjVvWm5JSXN6cGhmZzNwSzllTmZUTXZPSytNOHYxamRYQzQ4?=
 =?utf-8?B?Q3BkTjluc216TTc1MEkvQWZKalo3VWZBNFNQVk9ReXZWanVnODR5eHpYemdJ?=
 =?utf-8?B?bk5xYm5BeGZ6V00zTEN3VTRjK1ZzWkV4c3B5M2FaRTA0WTRGSHpGNVJ6ck1N?=
 =?utf-8?B?bFlmN1VsWGxwbWFrVmtCQWplSVl1djlhbWZhTTREU3NMYWN1SUgzbVRUVlFN?=
 =?utf-8?B?NDRDbDZDWTIycWlHRndnbXlGc09xMWltUERHQU9SL1p3VERyVzMyam11UFkw?=
 =?utf-8?B?RWVVRDh1R0J6Sk9ZYnc1bXQ0TGRjNzRFc2RXYWs4TEViY09oNStBNEpEaDJs?=
 =?utf-8?B?NWt6SWdCYUROalppWHNhdnlWNDQ2eCtGdHZvOEwzWURxb0QveWVJRlRqaTFk?=
 =?utf-8?B?d2F2VGxPOW5QYjBpOVk0RGdLM3VCTUh4amlEbTVqeWtkWXFzajJwaG5KQ0Fl?=
 =?utf-8?B?WHBsMGdsaDZUTmtPTTBLRHhZanE5MjBQakRobkF4RytIMjlHeG43NGp5ZjR0?=
 =?utf-8?B?NkFzcTN1dGdaZGZyRmpZNGJ2RmdPY0hUVnAwaFdVUFJjdUtFWDh3Z3ZnSG16?=
 =?utf-8?B?ZGlhd05uYmZBeVl1Y0VyamhkZjRMTURkR3REa09jYnlIRGFmQy93UmFFaWdr?=
 =?utf-8?B?WkpHR1A4YkQxaUJVNVVUYktNNlQzY3Zpck5SOXA1SStTWmVhT2xROWxscWw3?=
 =?utf-8?B?cElEQkJpQ3J3SC9kL0d5K0pNZmdPUkpIamloUFpwWGtwLzNsSXRQMC91RVJY?=
 =?utf-8?B?Z2tsR0lYZE9Dd3hWNm4rakxZR3ZacFhaaWk4bkx2R3RmTklTRHdSVGJsRkZZ?=
 =?utf-8?B?dFZySHNBYjdSeFp1VU1wTXVTa1Q2VjN2S0d1S0tGZHl1am1MV2Q0QVlVWU51?=
 =?utf-8?B?TFhwVlovRnhZOWVVZnZBNHVzdTJiYmpianJRMi9qajhCeVVuRWZvZVZUb3I4?=
 =?utf-8?B?YmJxNkNsZExsUHRkcy9yKzFPWXdwdGMrNVpwbm9rY00wWS9BT2dxd1ZaWi9r?=
 =?utf-8?B?OGlCSjh1aTlOUHBvbEFqSUhNaUw0cnNqMWlqc3RNRk5BZ3BGYlVRU1hWQUdO?=
 =?utf-8?B?cUkwbzZ3cnhPNWd6V3U1ZVZLVTlQTmpKMG8xQ2dIOU1jT29WZDI4azhvbENv?=
 =?utf-8?B?bVE4VGlwMjZGdXhCOHZ1V1I4MzZ3UzBBVkpuYmFmenpWT1pPRTZ5UWV0QXVt?=
 =?utf-8?B?TzM0QXNlOU9tc3ZLTTV5NWtMeFN3a3hrYmNjRWxvaHNJS0lTQXhIZzI3Yk9G?=
 =?utf-8?Q?kHf5f/qTL8E=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(7416014)(1800799024)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?UmNubSs0Rzk0RUZNcXlFdE9zc0F5UGt4QzkrM204ZUtDSkRpQzBrL2hnakty?=
 =?utf-8?B?TzgzY21BTTYvdnF4Z0VEMy92QW51eUgwSGJFZmlqT2NRaExGWDhTWmljYjl3?=
 =?utf-8?B?cVF5bDRDYzh4aTZHWmJxWWw1dUR3ejdZdlVDVmtuKzVRbFNPSFlFL0hJZ1hB?=
 =?utf-8?B?ZjVrVzJlRGpEOEVSQzBrT0ZSZy84Y1FjQmcrRjRGNWFPREVzbGxzdlFreVpZ?=
 =?utf-8?B?YTN2T1pXRVhWYTg1MDNxNFVMK3lXcDVJT3B2SFNJQk14aDllQ1huTDRmWlNY?=
 =?utf-8?B?UjdKY0ptU3RXU2pLQ3F3OE5UWlFyeDBhS1NaNFFCaDIwRVlIM0VudHlBcEZx?=
 =?utf-8?B?WUVlSktIc2p2UElnMjhwVjlmUVE5RkxMQlkwRVo5U1FoTEZwMThZMzh3Sm95?=
 =?utf-8?B?aUgyaXBpVy9lbWo0UldiWlJHY2M2em9xKzU4bjZxbnpGTGpsNHIvRkNHRzVW?=
 =?utf-8?B?TWU5WGYvS3Fob3pOUGUxQzhncDNtSzFsc1FBOTFVcmVRWVJhSisydGZ3Rk5v?=
 =?utf-8?B?bU84bFlRT0pxcHJRMHhCcXJrdERHWUhwSk1oZldpeHRnZmNPNkVUeVlCaUtM?=
 =?utf-8?B?RXR6Wit3ODUyWXVqSkh2T1gxN0JUR1ZNQWdWUFFTUU53eDdUaklsWjAwdzl4?=
 =?utf-8?B?bkhGU3owU2llWHhpcEJ1WXI1QzAxVkM2VmlSaGVqeUVBOHYwRUpwMmRsTkl3?=
 =?utf-8?B?MU9vQjQwMGhuSTBvNVljMGFOUzU4bjBKOFpjUlJGRXFQYkMzenN2ZHltTy9w?=
 =?utf-8?B?M1hya2JlQ0lJZXFXL3M0WUlndU95aWNCVUE5U2N6bENpQjhSVC8vTWU2WW13?=
 =?utf-8?B?enJhNkMrYk5WL2hqd3dJNmMrTVVlRkZ3Y0VSSVVaUmt2RzgyUlo3eUxTOWpq?=
 =?utf-8?B?Y0tVck5heklCNzcwYklKWkx2OVY3ZytJTThjQVR4UUFCOUxHZW5la08zUUNP?=
 =?utf-8?B?R0dvRkdWbmttemExNHZZYmxxT2lKTEVEVTVBWG85ZDN3MmNzcmNOU2xHTjc2?=
 =?utf-8?B?QkdqcjdJd1o2eHhYWW5XV3BtMnB1OG96bFJ2Qks0SFQ4T3VlRDYvUUVMT2sz?=
 =?utf-8?B?Z20vbGZQYWtORXBHSE8zWUpsNFpoU1YyNkJOQ25mTEwvSlJkUGZBQzh6aDRt?=
 =?utf-8?B?UmNqNDhTU1FTYlNuYmVSVVRFWHRDQWIzL0Rkd0RUYndNdTZoZ0ZuV1JlOUZs?=
 =?utf-8?B?T0docHZqV3lLZS9IaG1DMUo2dGRZbXhxQ1gwbEczRHN3d3ZRTnBFRFdjdnh1?=
 =?utf-8?B?a3ZrQ1hVTVVaYUdWMnEvTzFGTFRINjcrZTNkakRoVXVzd1FrenB1MmhGekZ1?=
 =?utf-8?B?R2orMXNsVnJCS01JRE96ZVptc1VGcHF4VHYrRmw2ZmpyWE50eTVGYkdraFZk?=
 =?utf-8?B?WThCbnVNcmI1V1VnUXRIbXAvdXVkaUxkZnY1WVlYZEZPMEE4VUVxQTBXdjh0?=
 =?utf-8?B?cFh1SzlMalZpSkFyb2x1VTNtSGFjbFFoYm5RZ0FSYVpka0ZTelZ4bklTbkgw?=
 =?utf-8?B?OXpuRG5tcWJYOG4yRnZkSkV1UnFDNktrbDF2bzFBRFhWd1JDVHI0TnNlMU1l?=
 =?utf-8?B?ZlRpZnl6elpIQmcyTWJ3T0ZZWERpSnBNQkd5eFZXWUREYThkR0VjYWZVTXdB?=
 =?utf-8?B?c3ZBNzgxM0RNLzN2MnBBTmZhMFhUeWRnT3E4b2JDT1NlSlNXMmpHcHRmUVJ5?=
 =?utf-8?B?UWxBWHMyRTFPYzVlamlrVHU3Zi81U3ZsNjRqSHAzVXZja3ZQVTlsZ1hQV1Jk?=
 =?utf-8?B?aWc3MXFrZ0pRZk5UQkN1ZVVVTTAyMEE3MktvbTIrWDRtUWcreHVlUTU2a2Z1?=
 =?utf-8?B?RXJiYlpkYXZXNHN6TGJhNXg1ZHlLaHFxYzE0d3F4eDArZUNKZ2xDa0xXclVI?=
 =?utf-8?B?ejk1VzM0STdTdXJQdHRsZzVqUWxPMWlGY1FvUDlieFduNjU2Tkk3d2NzSVJS?=
 =?utf-8?B?ZnJ0Q2tROThtL3A0Tlg2TllXSTZEUjY0bGlJRHdHNlYvbjBGN3pQRVl1QzJv?=
 =?utf-8?B?NjY0cHRuMGJYdFdOTU9xaDBXN0ExV2NscUtscm5WcTZGUXoxZktzQU4rL2dF?=
 =?utf-8?B?U1BIYTJOOXdTeFFaV20wOWJtckVoWVBCcXQrSmVYVWk0dVlEZmZFT1ZPQzRO?=
 =?utf-8?Q?BRWBR9xn2NdIW1LLzX/U4Pisl?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c0db42b4-9ecd-4313-7c3d-08ddb2e63372
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jun 2025 06:13:13.3926
 (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: xBK6S6Ai5i88ZyXpcJCdnZ14YpCDu4NEeBMWXClDKiW8tn4JZk/kbDDaWPKoYxOh
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB5910



On 24/06/2025 05:55, dmkhn@proton.me wrote:
> From: Denis Mukhin  
> 
> Rename CONFIG_SBSA_VUART_CONSOLE to CONFIG_HAS_VUART_PL011.
Why? We emulate SBSA UART and not PL011. Despite the similarities (the former is
a subset of the latter) they are not the same. I find it confusing and drivers
for PL011 might not work with SBSA UART. Also, in the future we may want to
emulate full PL011 in which case it will be even more confusing.

Also, why HAS_?

~Michal



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 06:13:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 06:13:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023118.1399034 (Exim 4.92)
	(envelope-from )
	id 1uTwuU-0005af-V5; Tue, 24 Jun 2025 06:13:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023118.1399034; Tue, 24 Jun 2025 06:13:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTwuU-0005aY-SE; Tue, 24 Jun 2025 06:13:34 +0000
Received: by outflank-mailman (input) for mailman id 1023118;
 Tue, 24 Jun 2025 06:13: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 1uTwuT-0005XR-Rs
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 06:13:33 +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 5a847050-50c2-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 08:13:32 +0200 (CEST)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-451d7b50815so38499665e9.2
 for ; Mon, 23 Jun 2025 23:13:32 -0700 (PDT)
Received: from ?IPV6:2003:ca:b711:f2f9:d2d:164b:59bd:2475?
 (p200300cab711f2f90d2d164b59bd2475.dip0.t-ipconnect.de.
 [2003:ca:b711:f2f9:d2d:164b:59bd:2475])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a6e80f2b8fsm1043757f8f.59.2025.06.23.23.13.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Jun 2025 23:13:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5a847050-50c2-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750745612; x=1751350412; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=1XG8vcE/yTA/JXSmZmw22gycyjddihVhu0OgNLKL2/U=;
        b=DD+eAxqh7Cue1bXSK6zO52R39AV/5855Ru3GiugVvHVymX+eOFElrA2JZSQvu8f2EJ
         WQPVs+dPoUUts0A5KCpsFziJCKstkwSNFWxfgQBF9AkJEce49r3UIGIh5VzACR5JfXda
         v1K8v/cvR/BRRwfwZNwVYR2xj7UupsPrkRcSvQV8aGOOat6pyaPXGNupZJg23aXssUBY
         oMgGeDFFG97DdBioU8/hsKt03cldWdt7BLenmPOCZaJGsrgBDR+goc7lmUXBxob3l3H5
         x6aRUUKGMv/vi5iBVeZELGJUsq9xuugyPblOL7nqgZlM8u0F3yOr6or3n97yGBz/YTeJ
         eKTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750745612; x=1751350412;
        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=1XG8vcE/yTA/JXSmZmw22gycyjddihVhu0OgNLKL2/U=;
        b=XOsqf5p/g6Ed5ut0EL1+E+wSgfn/4Nwyp4p33MizyER29l+1jgIDLP+ib4CpAJXE56
         LtUk5SeBEloVmTdW5dlKor1AJU6qn7lQWL7+9jec25xZbgTiBnA2nIqghOkqoOhZir5c
         byQl+lkqQ6nmW50rzBAKmRGzU6ULpakkUrkgt/APVKYqvA51PwzD4H/nT/H2cOMGJxY/
         MMD7eP52iIMMcIDYBg0ZiwyEHbje/MzbbUzgJmM0DoKR4y8ndnlMB+XR4jhvdavExbjv
         xGvUohPoGULlORMcVKgNDh9zwevFlof9150k/PNIUtH4KIfm4C/lMFXlzK0pCdSrgefT
         CLvw==
X-Forwarded-Encrypted: i=1; AJvYcCXNA6sXlbCcHjW+hj4qHx8gdCIUxo+cC/ErYXUxMRA3bjD1hVhPPS0Lm5Sjy86Fnl6bVN4lHTZAQwY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxFOfaEk5ikoS4wVnBEx9Zuxtq38LKAY/9rVqCthsMHS60R/RBb
	H2p30kBMt7AGT3h3p1qc/MyLhP25l2Y0GZJJNQ4FU47RzS5tr6Wg7d7sB5Eft5RIVw==
X-Gm-Gg: ASbGnctVXgOHf25MjAYQ5teVw/PwZjxcwaChkHVRszfIkzCLK1CyJ1AKhbksF5jBXbV
	RcFNiwLfjqkoahypCIGYUA9SGUvhnWDkJka5KJW2QE2ehljIB4tvHA+hFleyP/G0FSoUJXuAN4W
	jcohwHRcqYN3G7J22VXNu+PGh+2IaoSMRzUCZV1NdSg8o4VV1afkR0QeMlZDfkk95rmo+mQRfJM
	gxD+rh0qUWGm6J0aiCeI8yUgGZQRP8rzW4AQXhUZdYh1Brm2oECP76SRMDseVA89tk6VHg8MV2/
	fJnLivItlB/nZrw+coearDb27uhMrbbXl6FJ2UREzN4699wOb2MMZq9L06Rf/2c/8N+t9YLwEIT
	gDxNAl9D4FxyrzOmSarIvZ5GzODz21ER3dEX7F5gU0RcI8JVKJ5awNaa+SNqvAIA5v3PPeo0Tuy
	xZBZMulMxIBADqoNfqnQ==
X-Google-Smtp-Source: AGHT+IHmqbbYIE5aDsVX82go0OmHtk93tcqmT+NUsoGJDlcy90yA9XFj/uHjbO4cWQjDYH0KywLVpw==
X-Received: by 2002:a05:600c:3ba4:b0:441:b3eb:570a with SMTP id 5b1f17b1804b1-453659c3b97mr136581065e9.2.1750745611601;
        Mon, 23 Jun 2025 23:13:31 -0700 (PDT)
Message-ID: <3de371c5-5594-4209-a430-7e7afd1198f4@suse.com>
Date: Tue, 24 Jun 2025 08:13:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6] automation/eclair: update configuration of D4.10
To: Stefano Stabellini 
Cc: Andrew Cooper , michal.orzel@amd.com,
 julien@xen.org, roger.pau@citrix.com, bertrand.marquis@arm.com,
 federico.serafini@bugseng.com, Nicola Vetrini ,
 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 24.06.2025 03:19, Stefano Stabellini wrote:
> MISRA C Directive 4.10 states that "Precautions shall be taken in order
> to prevent the contents of a header file being included more than
> once".
> 
> Add a SAF tag and update the comment on top of cpufeatures.h.
> Add a header inclusion guard to compile.h.
> Generate header guards for hypercall-defs.h
> 
> Update ECLAIR configuration to:
> - extend existing deviation to other comments explicitly saying a file
>   is intended for multiple inclusion;
> - extend existing deviation to other autogenerated files;
> - tag the guidelines as clean.
> 
> Update deviations.rst accordingly.
> 
> Signed-off-by: Federico Serafini 
> Signed-off-by: Stefano Stabellini 

Acked-by: Jan Beulich  # x86



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 06:36:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 06:36:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023129.1399043 (Exim 4.92)
	(envelope-from )
	id 1uTxGH-0003qK-Jo; Tue, 24 Jun 2025 06:36:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023129.1399043; Tue, 24 Jun 2025 06:36: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 1uTxGH-0003qD-HI; Tue, 24 Jun 2025 06:36:05 +0000
Received: by outflank-mailman (input) for mailman id 1023129;
 Tue, 24 Jun 2025 06:36: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 1uTxGG-0003q6-Q8
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 06:36:04 +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 7f9d802a-50c5-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 08:36:03 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3a6cdc27438so4210377f8f.2
 for ; Mon, 23 Jun 2025 23:36:03 -0700 (PDT)
Received: from localhost.localdomain (253.226.6.51.dyn.plus.net.
 [51.6.226.253]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-453646cb5a8sm133834135e9.7.2025.06.23.23.36.01
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 23 Jun 2025 23:36:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7f9d802a-50c5-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750746962; x=1751351762; 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=1lGzCSKb14mZMj9FzOXT7zB/agz3LVQjFAyPfpcymbc=;
        b=dfP8ZNAPduzsGm7nQeu+jKw0KDvvv1Q0AcQgtWFl+G/k4ITSP8/jwCIggsMoSYWthV
         MtQPI+Yq9NI2s60+sYSYZ5UHYZj67fIufhSRUKoRolExhncedtY0ge7IWfRCItGZ5d1T
         VITTLQxGlQ2wvJU18SQwiEwHZzRveAiShuZF8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750746962; x=1751351762;
        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=1lGzCSKb14mZMj9FzOXT7zB/agz3LVQjFAyPfpcymbc=;
        b=Oyx3ocNP8PwYRbRia8TQw3bT1zW+P1m/JK9K50rGHwk6Ff8oya4CCo2YP22/SKfW2F
         xPGkEJSkGhncq0sKcDBj0JgaFsjFmOi+3iJ8V9lj72NMyVpTPtDR9fRg8OhrZkgKKEDS
         kdtp2WeM796D7dL+St3bQA/UormjJKKqS0lnxrFBCVhd3TFMAi8jbwB5J0OLR7I0S9+l
         ziUyt1nvu1MYDs5k9cUDc40VPkiND1hK8ZmVXen/EY+hMYK9nF8o5Q3W7bB+OtS9v0Gd
         5s0c2SRskBCSHdBL+oVFsIyQ+ZqN8iBNu7FfHPty9X5AVNG7L/Oiv77mv5xderN4yC4d
         I5Vg==
X-Gm-Message-State: AOJu0YxSEP8Mb1D/aTFlXvEhQ/eaz1mmpy+oOP6SnxvHFxieSIxgzOKs
	68wKpgBMefopSR65vmnrJxFzAY5XuopbgKnyfNtKPdHxUdJHuq/711V3xmoQOZVmBqofofQEOfy
	8GiC76n7oJg==
X-Gm-Gg: ASbGncvJBjT7OMiBlgXAX5wvL6roMCP/Q/jtJ15BBNX7xelxQH58ZVGKWUAfcjkvAa8
	Jfm3p1Vw4UV9Uk3KW3VbsAa+pg+gGobUWq+uHkb9Uvy9usQ91g55wncSUFYQlhfwH7cz5mxLOvf
	nCboSIUM4IB6lkK6moMICKudgenin/qLHEEdwHFR4relg0vxn9GxpMK79cRp+G+knEZXXwayelP
	QQgdPpQ1D8fbkTty13JsGqXig2sMzQp64cNKyYrwal70oFp4lsYZAKciS276gVi8okwE76of61x
	9HuUteJiFwHlUaQ4UfYPmJcm9jEoVbrWcrwFZ/ZT5hyuDmvwUhCbSfbWdxzi1xStWVAtgnWWa3M
	sfiTui9v7oq/uGWryDOcVnYUXUyyvaQ==
X-Google-Smtp-Source: AGHT+IFJBhpZMr2nBpl6xVA7AGURxMbrnS5Qv5moQqiXV3g7Tl8ztvBt4m0eN5zYg8WwZE8L/5aaEA==
X-Received: by 2002:adf:9cc2:0:b0:3a4:f379:65bc with SMTP id ffacd0b85a97d-3a6d131dd70mr11495780f8f.40.1750746962164;
        Mon, 23 Jun 2025 23:36:02 -0700 (PDT)
From: Frediano Ziglio 
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio ,
	"Daniel P. Smith" ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Jan Beulich 
Subject: [PATCH] xen/efi: Show error message for EFI_INVALID_PARAMETER error
Date: Tue, 24 Jun 2025 07:35:39 +0100
Message-ID: <20250624063541.236691-1-frediano.ziglio@cloud.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Show string message instead of code.
This happened trying some different ways to boot Xen, specifically
trying loading xen.efi using GRUB2 "linux" command.

Signed-off-by: Frediano Ziglio 
---
 xen/common/efi/boot.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index fb3b120982..ded7cc129d 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -329,6 +329,9 @@ static void __init PrintErrMesg(const CHAR16 *mesg, EFI_STATUS ErrCode)
     case EFI_BUFFER_TOO_SMALL:
         mesg = L"Buffer too small";
         break;
+    case EFI_INVALID_PARAMETER:
+        mesg = L"Invalid parameter";
+        break;
     default:
         PrintErr(L"ErrCode: ");
         DisplayUint(ErrCode, 0);
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 06:36:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 06:36:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023130.1399054 (Exim 4.92)
	(envelope-from )
	id 1uTxGT-00046z-0N; Tue, 24 Jun 2025 06:36:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023130.1399054; Tue, 24 Jun 2025 06: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 1uTxGS-00046q-SW; Tue, 24 Jun 2025 06:36:16 +0000
Received: by outflank-mailman (input) for mailman id 1023130;
 Tue, 24 Jun 2025 06:36: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 1uTxGR-0003q6-Ma
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 06:36: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 86e8becf-50c5-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 08:36:15 +0200 (CEST)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-45310223677so37319385e9.0
 for ; Mon, 23 Jun 2025 23:36:15 -0700 (PDT)
Received: from localhost.localdomain (253.226.6.51.dyn.plus.net.
 [51.6.226.253]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a6e80f2670sm1076535f8f.49.2025.06.23.23.36.13
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 23 Jun 2025 23:36:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 86e8becf-50c5-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750746974; x=1751351774; 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=6QCeevMLk6yzxVIfNbN3B3ZRcu1Hfw38zoD9YhXS6dA=;
        b=jgCkddqRhahPD7mc2/VOPISexqwMA4MFVj05VhExm9dJ8QpvPpEFXOlSlibKcnJopO
         hVVTfHTqJ5sXcephVevSIxJ+eVPNP1GdMjJxY2X4c65CTik07/f5Ux4pfThSWw4BhyXB
         SObB0BOY435DAamK98irU0nFN8RcsbFYBBFSA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750746974; x=1751351774;
        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=6QCeevMLk6yzxVIfNbN3B3ZRcu1Hfw38zoD9YhXS6dA=;
        b=iNEYcQ1ApVtjIHmixOKCPnb+Du2s9+mJHydEiocObpIKVhezc42MZDla/eWJDd/QNF
         uIqD1Sjd6Aj8fC8XeEcRcUvFFm0FO4Z+Ym010P4gNBImSjFtU78c1yEhnBbbKwMWBYFj
         +qU86rrdhH/nSXVmNYrxBlEjCh5nzU8AaFtJ+Ki1TUDpFxcBHttrxaAJ+guAkOPMp+KE
         Lh732XLhd68Eo5eqLwB/AsYVYLywxHbSYUkAgILpNkWeFEczjYMQDpEgQtWfJEFvSLA9
         obOq8+IN3+IQ0bepfgUeLgoCJe9FVCpxBfQKarfhy889u+B+L+4PIyLIPTQMh58dxVI+
         r6Ug==
X-Gm-Message-State: AOJu0YxIGM1cvJYqXglhUpUnmiua0anOsaor9KhdMnEDXqkgBF+Grm31
	DwnU3QAD33h3jXPexRBQH7rFr4ol1dI8S54MAJ1Noi0QIjAtqd8mSUSEYbuRYQulqI4jRO4KtFx
	GCsG/IiD4Pw==
X-Gm-Gg: ASbGnct6OWF0/+IVTBkuzvD0wSvWWC3zYGMkFIEvurdp8zd7qTQzLJ3sgnxme1wpTlu
	lIJ/yo8UW4JsQen3bGi1bcZrfO9WkYfumpy+qsm2/d3znjQtXkheOJfZwzfKLpvj+aVPrji8BWj
	dhGCiejTkDTrMLaABgqHFnhrPqdl5q4+b/mEiHOzW+BArZq5llEtSA57wxupLFxtXSO+IsLCkvb
	M+oem1wZDp+yANZMJfw6BHVyuYfOUrRFCywLJPYM8f0qdKTW5T0Lqsx65MOe7fZ4WCnBVrIRUur
	nHxsCFYoOFl9ha0Nzjuu/EVTcGSHe4iLQbDAdFIpsxP/7/Ti0Qya7hvoc3Pnr8/rqxMrTUC9RD2
	OhyeMdvWI9far1V8F8bSmZO9b0jXrXQ==
X-Google-Smtp-Source: AGHT+IEePzjjQsOay9KgxV6MpmsYHGc8FdxFVTBdoBSX70CvVUpEDTJyZKj0ZuSb1HzcnNNIZ14uYA==
X-Received: by 2002:a05:600c:528c:b0:43c:ee3f:2c3 with SMTP id 5b1f17b1804b1-45373265d1dmr61915025e9.7.1750746974302;
        Mon, 23 Jun 2025 23:36:14 -0700 (PDT)
From: Frediano Ziglio 
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio ,
	"Daniel P. Smith" ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Jan Beulich 
Subject: [PATCH] xen/efi: Do not undefined not defined macro
Date: Tue, 24 Jun 2025 07:36:08 +0100
Message-ID: <20250624063611.236876-1-frediano.ziglio@cloud.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The "buffer" macro is not defined.
It was defined till commit 59e087bf6a9c8ad805294c32dfd7c77068d81eff
(cfr "xen/keyhandler: Drop keyhandler_scratch").

Signed-off-by: Frediano Ziglio 
---
 xen/common/efi/boot.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index ded7cc129d..1a9b4e7dae 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -513,7 +513,6 @@ static EFI_FILE_HANDLE __init get_parent_handle(const EFI_LOADED_IMAGE *loaded_i
     else
         *leaf = buffer;
 #undef BUFFERSIZE
-#undef buffer
 
     return dir_handle;
 }
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 06:37:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 06:37:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023146.1399064 (Exim 4.92)
	(envelope-from )
	id 1uTxHh-0004um-98; Tue, 24 Jun 2025 06:37:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023146.1399064; Tue, 24 Jun 2025 06: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 1uTxHh-0004uf-62; Tue, 24 Jun 2025 06:37:33 +0000
Received: by outflank-mailman (input) for mailman id 1023146;
 Tue, 24 Jun 2025 06:37: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 1uTxHf-0004uT-Vd
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 06:37:31 +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 b3c43565-50c5-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 08:37:30 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by BY5PR12MB4068.namprd12.prod.outlook.com (2603:10b6:a03:203::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.29; Tue, 24 Jun
 2025 06:37:26 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8857.026; Tue, 24 Jun 2025
 06:37: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: b3c43565-50c5-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=hl48SLcpM1I5txA+rhu4MnJ2KHPiKhiFDkQU7gkra8LH7u9ZZJ4YMK6FXfaJry7HmTLVwECFXC0AONul5BslpMEcoj6DrC9l57BDPp/q1WCqL7G522DkXToUb3+E5WBwDzidzpdTYxAqMFNzM5znh4xs8PKVAdsPrWl+v1c6sJuLH0FGcrcUO2D+dkSrIurv/zcZHjHE5v+pncXyOuNsa5ihtyufRj2ZFXlBj6x8VzdneohB8yKrBdzC9aOustc+UfPmJeNPzI6As56mEYiRq0Gd2pYb/HqDiARzB7dNvu+AzWtI8Z8vlusPoBf7ymmgCIa4/BGZ/G+JkJK+1U1ElQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=7HlwwAJT3wSwT9dOfKxVZ1LcxafB2aD3LX7acmr0LkE=;
 b=FkkM7/WlYwkZNAxVpmwXvlrRrdgV3GJND/bO+UfHcuhT5VicyTkNZRaaMo3ZIaXWiPjDyU4jWe62PEZMxq+i8w3SCD5qFD8EpSEPTapCv5kO+IPCL+ZPGv9hLYvtdMy2bKEbmZF2NKtxdZOKD4p1Ou+ZaW2Gc2+yo6gjEHQ/AnMyW0UPLS4oHa16fG77Q/Q4BktiVD62rFWBrJFU0584lUAE9suNRgxnrVT6lTXK2ar5/K8r5T/BOOpqH0K3zTVIUVkw1wfEu/ohwiBl1a30cHTGnO1rJp5SItpdjW3Sg1mDOPDCDrmcviwdaPvIS32fOz1NjZnEU+N8XK6fvXHZGQ==
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=7HlwwAJT3wSwT9dOfKxVZ1LcxafB2aD3LX7acmr0LkE=;
 b=YsnkooyrH7b0UKi7+keE9NHyaJRLCClSvLapiGpZWEDNP9U92OwkacbHKXoe6JQ4OUpovUE7ufNsfvUJ1NcJo/+2MJ+yawqA3EHvkoZKXXET8//A6edmxGu/zkY7uQbfL0KBs/10E0jpXjtFJKlyblos/sj6DQIzwa40+5Q5Abw=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <070f16b8-c397-487c-bcb8-0ba13bad919b@amd.com>
Date: Tue, 24 Jun 2025 08:37:22 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 07/16] arm/vuart: rename 'virtual UART' Kconfig option
To: dmkhn@proton.me, xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com,
 julien@xen.org, oleksii.kurochko@gmail.com, roger.pau@citrix.com,
 sstabellini@kernel.org, dmukhin@ford.com
References: <20250624035443.344099-1-dmukhin@ford.com>
 <20250624035443.344099-8-dmukhin@ford.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250624035443.344099-8-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR4P281CA0196.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:e5::18) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|BY5PR12MB4068:EE_
X-MS-Office365-Filtering-Correlation-Id: b0b1c9fd-a96e-4087-f174-08ddb2e99580
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|7416014|366016|1800799024|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?NklIdTh2ZWtJWk5zczN2V2lOTERXR2tmYkg2WjBKOGtXZlNTZzdUajNHRTFR?=
 =?utf-8?B?dHVaYnBGTWl6cnBoLzRQWGpzM0xyQlFjdXVSQ1NBQWFBVWNJQi9UeWFVN0tq?=
 =?utf-8?B?TlBhakUzditIaDJ6UktEOFQyTnRBQUdrdU9vSjdLQmtQUXZCNDhCNjhuNmxX?=
 =?utf-8?B?SUhTRmVsMnIyc01ISUlUcDF3ZkVqeDRJd2U5Wk8zUnRjaFpkeVdYY1ZXRmVr?=
 =?utf-8?B?RDF6dEN0bVpIdGJadWZXeTB2L2cyWExBOWRib1NxOTRlZmNOcHhzNU5ZZTdt?=
 =?utf-8?B?VFdOV0RibHJMVS9Pd1A3emNXaS9aeWRSZGdabkJER2p0bFlyaGdQS0JpR0Vn?=
 =?utf-8?B?cDZQUXlDZTV2WVhLUkU4eDF2QzRveWlUVkkxL0w0Vm5veXJoNWU3NS9sM054?=
 =?utf-8?B?TWdSTzU4ZFZoL1pFYXJBYnR6NWdDR2hteGlac0tvMVhBa3BQay92Tk9xN3V2?=
 =?utf-8?B?WFA5aGVYenFhM0I1aXp5UkJMY1Y2bS80T3FzcDQ5TFBMR1NyRDRzTTFJWHJr?=
 =?utf-8?B?WTA2ejhOMWdTeGUwaWJDRG9jeTg5NXg3cWdMQW9uTnltQ2ZzRFNGZnpkREY2?=
 =?utf-8?B?YWUyRXFoS0pjakI3UG5jamRKT2Zvb1FCeGVoc056bk1xRncva3VDT240a3Va?=
 =?utf-8?B?Vkxmc3gyVFR5OFFsOXVvbGZYaTdielhNVmxBZWZXOXBCQlM4eHZJS2YvME1y?=
 =?utf-8?B?MHJHOW5nMzR6emhBaW5MNm5pTnVabU50cUx2QXcxK0dHWEZFUWlNdnk5b0Ju?=
 =?utf-8?B?dXc3dk1IbHhJN0taNVBicGJTOXdHSS9EcnMxVlRYelpSRWorcGlhZ29UbjBG?=
 =?utf-8?B?YnpCOVZMd3p6amFVc2RiaDY2Z2hCMHlra3RZdzUxWW5GbU1rR2dzbEVqa0xY?=
 =?utf-8?B?UlEzczFZeVYwUnE3STNud1hJSTBwRFgwVFAwNTR6eHlHaEpyUU0rMFZpQTd5?=
 =?utf-8?B?YndZVDZtcG9IdzAvaU4vVHZOTVljOTJHNFZuMlBDNzREK05ISks3UCtVb2lk?=
 =?utf-8?B?Si9GczJrT0ZWdkZpNk9XSmh1NDFXR2g0RTRyckwvc0YrbDlGRGxrajlmVUhw?=
 =?utf-8?B?YUlYamtNVzVielRtSjhieHU2RmZ2L2pOV0ZRRGF0RTBDcjhiZ2djbkI5b0Rs?=
 =?utf-8?B?bG1RTjNLb1dWdWdNdm1zdG83MWxZK2ZWNTYwTE9OOUtmL3hqV0ZQNjNDRUY1?=
 =?utf-8?B?WndvNWFGVDZrTjhDRnhtaVlzNE4wZURKZ0o2NFF2MHMvSjlNYkxTSzM1RVBs?=
 =?utf-8?B?TXhsZ0ZxcmZyZWhOVytPMTVNSzN0QkVMTVgzTXYxVDMzNDREM2pLYmhqd21m?=
 =?utf-8?B?WStUd0N6L0NaSHB2Rm8wd1dmVE40czN5MzY5MVdJK3l4SjZXWGJtaUFtYzZo?=
 =?utf-8?B?em8wdEsvR1hxeUUxOE8vY29lNUprbS9ybFROd0tRbUl4Sy9XcFU3MDB0UE1S?=
 =?utf-8?B?S0ZGbVovTDZBcHZlWWNrRHZFSnVQWjdQdW5nWFFyZkcxUVR0ZkdqVEpobnkv?=
 =?utf-8?B?SHZLWnNXMi9kZjNyYUMyZWJqT253dzNSbGd4ZkJnSXhHT0FpdXF3U2JoUktD?=
 =?utf-8?B?MDhvWEV3SXd4RnJCVjdxVzM1eGM0MHEvY1RYNzdWc0FjZHNvLzlmRlZlN3dz?=
 =?utf-8?B?ODd0Y0lWWkZNN3MxNlo2TVkxWDhlakg2U3l2OXltK05JaVA5UmNuTzg1R3NG?=
 =?utf-8?B?eG4rZnQxWGJpb0hUTXBrNjBGbHZHRExOUjh3dGxWaGVKQndIS1Y4OERwMUto?=
 =?utf-8?B?V1FYSFh3OGNwWnBaS1dWSXE1dGlBSXJEUWR6SXc3QWl1dHJSbDFrWjdtZ1Fa?=
 =?utf-8?B?aG9nTWpXSWRwN1NtbFAwZGtmZXowTU9zTEpJWjNTdjhRVGxycUI5dlNyVGI5?=
 =?utf-8?B?L3YzcjhpT2JkMzh5YjhvbnhTbFpDVHQvUUpQQWFRM0Fvbmc9PQ==?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(366016)(1800799024)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?T1dISXl2azFtcjcwSlRqdm9VK2Z6eTNKNmRmaTR0MjN3eDUwZU9DTkJQT3ZV?=
 =?utf-8?B?azMxUmhSQXlybEZiRXgzYVVjK2YycjNieERNZnNOUUxXSDJLUFdPTjE2MEdn?=
 =?utf-8?B?S1pXN0l1bFhwcWdTUEJsczZPbEFwMldDK2QxVkErcTNwakJaRmtKRFl0UTUz?=
 =?utf-8?B?UTVLQTJGUmNWM3ZobURYZjc5UVhFS1lwUVVKckc1WXpNVFJGMGl3MFVIRDdn?=
 =?utf-8?B?WmQ1MGR6OC9OdkdKV2tHdGJncXVKTmVuQm5PSmloamxGd2VjNHFrUDA5aE5w?=
 =?utf-8?B?Yko1a0dWOFcvMktzd2RML3dCalZNNVVORStqSzVhZ1pnRG54OGJ1dzRPYm02?=
 =?utf-8?B?NlNpNjFtM0dJMUZxRVBUMTV0cVhyR3VQSWtRYkY0cDNzN2MzWTNmMmRFNDJv?=
 =?utf-8?B?c1R4VFhQWndIbGVFQlRoRVJyeFYwVHNyenhYcFBIVjExQTBnWHIwTGNaZTU2?=
 =?utf-8?B?OVlXU1VYMUJQN2IyL2ZSMXBsY0RjaGdBWEZyMlZVVUtTcUxpYjdRbGVDUWM5?=
 =?utf-8?B?Ymc2a2xTZjd2LzJVdStLSnBmb2grS0l6ZFBBNGN0Tld3TUtRNmhRR1FENmU5?=
 =?utf-8?B?TGVxcnIvcjh6RjY0blZDNDlLSnNqamdEMm94SGFsbkMvZzZaa2FpZExoUGNv?=
 =?utf-8?B?MUowTUdUWVdURzc2eXUvSlh4cFJQa1ZKSUlQb2JkZXl6cWlOSkIzcE5KcGkz?=
 =?utf-8?B?alh5bnpvMjlMWTZtUWxtQm9mK2JFakFDRW1kanFPc05IaFBmaWprMmZhK0NX?=
 =?utf-8?B?OGhRcEVqTXZRSEM3dUhrbW9XVldkVkdHVWZEbzA4MjVKOUV1bmVRN1kvZTBk?=
 =?utf-8?B?aitzNlB2UThKd0NwdzZRenpETUdiUHNGV1ZtWFU5OVlHT2llamJKKzE4SEN4?=
 =?utf-8?B?QUFlcWlFZ21OcWMxUU01S2tQTStUV3ZTeUJubmJKcUFpdDhBU0RuVFpkWGM0?=
 =?utf-8?B?WlZyTXN4d0xqUlg0MG9HTGdXZ2hQNmcvb1crNWpmYW9lYy9VL0hqUExxbVZP?=
 =?utf-8?B?Uk5ha05tTllHNElYdTV0b0hkbGhDb0loR0trU29QVFhGbVZiWFhKWmgwQURO?=
 =?utf-8?B?SEZrdU44ZEtLSzNTODk5dWxzSzNuWjZ1UU9CV1FCbFRJaHJpam5OV2toZnpO?=
 =?utf-8?B?SEJLUVppMFYvUkt5Tm85c1dadWg0R0liZjVBcVJFeHFvZ1Z0djNhU0I3L3NW?=
 =?utf-8?B?cHlFdTFXQWRsYUJPSFczeG5YS0hHQ1lWbkpnRlRFeGtFenI3Um5VRTQwdy80?=
 =?utf-8?B?NHlBZUJoM0I0K1dsV09PRkJGZ0UrbkEyL21KdjFVKzYzeXFuc3ZKeXRiNW90?=
 =?utf-8?B?cXRLNGNqZ0hRSkdHM0hWbm1iR3J0b0dMam1iV3BhSUkyWm1kMHg0ZlBxc001?=
 =?utf-8?B?Mzc1NXZ0aVFCbkZrb09wbkJiang4YTVPckNkKytsYk5QTmtKcjlTZUV0eGEx?=
 =?utf-8?B?a0hFcmNHamxXTEozNm96SVRmR0sxVWZXbkdVdExZMFpqQjlIUDQ4TzFoakN3?=
 =?utf-8?B?UW1YOEJ4YUxDTWxaL3h4bVY3UmJEVXZvaDZtb2RVK29Kdk00Ly9HeHFWdUVi?=
 =?utf-8?B?ZHJjWnVPT1FMV0FpUXdSYStUbHphZTNjeXVzeE5mZ285V1FRZjJWa3Y0THVm?=
 =?utf-8?B?SUxkVEVyaXRHZlJGQ3pwSVJiLzZQMm11eVhIaGRGUDVuVmlXY2VuQ2NNNnpK?=
 =?utf-8?B?NjVnZEEwYS9IQlc4ZkN3dVJPREt2MHVCNEl2ckJhZVcwUmNJRElKdWx0Yi9q?=
 =?utf-8?B?L1lNUEQzZEZBaVdZUk8wR1RyVlZZYkVITXJCMnZ1SUxsMVhFNytnQ0RhbzAr?=
 =?utf-8?B?K1hCbGRaZ0FlN0ZBbm96VEhtMU0wVy9UYkxmaVFmODVPKzhDVWxHVlZsSnZt?=
 =?utf-8?B?NXZFck1vblIxSmxDVlRjS3JIMGZFR0tjNGswN0ZUR2ZQcW9DRnR5WW5NZ0ZE?=
 =?utf-8?B?TWFRbm5iSkpiMjRMaTdubzJSK2dObHc3Z3M4RWh3c1FkbmtaWVpFU1k2OHkz?=
 =?utf-8?B?d0lvbDk1WTBXMVp4TU1wUmpOd3hWbUkweCtRZDN4NGpHMXJ1VkpKZzY4ZzdD?=
 =?utf-8?B?U21ZaHp5QlVWUVdtZUwrM2dpQkRZZGppOXQ2QXVEcmRmWG4xRlc5UE1BQU5j?=
 =?utf-8?Q?bKXmBz1aq7T+e4ZocR9kPC9O+?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b0b1c9fd-a96e-4087-f174-08ddb2e99580
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jun 2025 06:37:26.8178
 (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: HeIJ0pEwV+1XYGzVGrdzOD30iCv+n5ElSnxSBVyQ0PGYcxskuMK2NEIGfeVWyAXZ
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4068



On 24/06/2025 05:55, dmkhn@proton.me wrote:
> From: Denis Mukhin  
> 
> Rename HWDOM_VUART to HAS_VUART_MMIO.
> 
> This emulator emulates only one register and the use of the emulator is
> limited to early boot console in the guest OS.
> 
> No functional change.
> 
> Signed-off-by: Denis Mukhin 
> ---
>  xen/arch/arm/Kconfig              | 2 +-
>  xen/arch/arm/Makefile             | 2 +-
>  xen/arch/arm/include/asm/domain.h | 2 +-
>  xen/arch/arm/vuart.h              | 4 ++--
>  4 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index 03888569f38c..b11cb583a763 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -177,7 +177,7 @@ config HAS_VUART_PL011
>  	  Allows a guest to use SBSA Generic UART as a console. The
>  	  SBSA Generic UART implements a subset of ARM PL011 UART.
>  
> -config HWDOM_VUART
> +config HAS_VUART_MMIO
I personally don't like this change. The current config option name reads much
better and clearly denotes the purpose.

~Michal



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 06:57:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 06:57:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023154.1399073 (Exim 4.92)
	(envelope-from )
	id 1uTxaq-0001zx-LI; Tue, 24 Jun 2025 06:57:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023154.1399073; Tue, 24 Jun 2025 06:57: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 1uTxaq-0001zq-IS; Tue, 24 Jun 2025 06:57:20 +0000
Received: by outflank-mailman (input) for mailman id 1023154;
 Tue, 24 Jun 2025 06:57: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 1uTxap-0001zk-D3
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 06:57:19 +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 7738ac02-50c8-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 08:57:17 +0200 (CEST)
Received: by mail-lf1-x129.google.com with SMTP id
 2adb3069b0e04-553dceb345eso5531916e87.1
 for ; Mon, 23 Jun 2025 23:57:17 -0700 (PDT)
Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-553e41cc18esm1706337e87.229.2025.06.23.23.57.14
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 23 Jun 2025 23:57:15 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7738ac02-50c8-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750748236; x=1751353036; 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=x/YWy/FYLDxPFS3Zo1qm/QUmhAl184xKR8fcYgXKlX0=;
        b=RUD109ttk1qxsXu4Iad0W6UGRj7GovnLg2CAhzRFAG7zhZ9l5TVC7AAO5CNEG75hu8
         KoJ9vzZVXFLTMsFp9M5DPYtlYj1SSDT25S9gI7BvmlYlSqY5t43VR4CjLId+FdV+tsPr
         IBwHgfhTu4/pVYP9VDCnY3BVdWjpTGsRhqU95E0DMf7YNFtdP2QEN2QaOVbaOLrOvmKk
         RNjwF+m6zVR5FC8T+hSKlAFU8Fcx5tkonZwqa42q/2WqqqfIV+zTJ4eCkGWTiHjv1cJh
         B0EnnEV5MTUetQAl6qDnZaifhMhPMWcKZ1TpznwCdcKqdGQWf9Af8MM23FRGAH6JauL3
         AaPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750748236; x=1751353036;
        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=x/YWy/FYLDxPFS3Zo1qm/QUmhAl184xKR8fcYgXKlX0=;
        b=vtDurGaGDX1QlQPeRu1Qcmi67wFWtDwC0qnG9FhNFpUGpog0sdvCtEw+iad/+vs6Pp
         Im391A6YfVuo6TdMZNZz7tddrNZMpOJWjBCzM8cfskMhSDQR+xscjS8w+D8s7GyTZdzV
         a4h6vZ9Y/QGxdRj8mrU0TlsbsGp7b9ntT+y2b449uRpvLiUNY/DODgnn6y2+Hxmi9J9k
         ej4ILPJl0JbrZSfcYftX4WQlPZ6oXgaJKdkcE++QV82En8RVxEW9yD7PHCquyH5v74ZQ
         ppIcnO+UI+o1dvEnNQKZWG06uTRhZ01R93qOlx/9nppeV/nh6bboOhxAuvuN5y7BsafP
         nrJw==
X-Gm-Message-State: AOJu0YyyOsaaw7NcvV1qG/s2Khm4fJDz+Wvnh10E4Y4Xng7XNtC3JFPQ
	+Vk8sgiN5et26wVZYkB072Qbu+UE7Myp3+u6YfqiKIE7N8VU28IasNGh0/itg6A1bUQ=
X-Gm-Gg: ASbGncsyRXhr7BiUq1La6/Ge2PmSmw4x8mkP2s/xofmxBGjKrm2/poGC1YOZvJH/uG2
	u1UcOPHvs8b7SEzeTmaUd6LuoaDz3qdVrNP3l+ED77aP4FvpDU/+DnTKbwor9gi9+TxCC+2t3QZ
	XGEz66kBAwkSCGHrnkeQtUFLxoAyMLQJfDc6IdNj8WZmn+xo/hwY0FPnjo8yFS2C0z0RPJ9Mapz
	8OXBv1yR0NMuYimZYo6rcs6X5NFYT8GhJ2fOg5oVER1Wx8fs8X2UavAsKIfylTyTNrG7xnzhns9
	G8bBjJngDlpRu4LiKRKrlKV9V3wQ9d3cm2OWwrKNqSYTOWvQFOpPq9f9W4uMNdJruOenmEdbU30
	3nwfbwuHx+cvM3pCSEF2M/oSGcW+G+ijvMXvv
X-Google-Smtp-Source: AGHT+IEQfcUqSvvJ6gz7S2FK9BzDvjtZfr3lc3QrhI8oHiX/GFi9vslmVg782LlAXUKupClH1mQK/g==
X-Received: by 2002:a05:6512:3055:b0:553:2c65:f1d1 with SMTP id 2adb3069b0e04-553e3ba7286mr3707404e87.13.1750748235644;
        Mon, 23 Jun 2025 23:57:15 -0700 (PDT)
From: Mykola Kvach 
To: xen-devel@lists.xenproject.org
Cc: Mykola Kvach ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH] xen/common: Guard freeze/thaw_domains functions with CONFIG_SYSTEM_SUSPEND
Date: Tue, 24 Jun 2025 09:56:01 +0300
Message-ID: <20250624065601.197492-1-xakep.amatop@gmail.com>
X-Mailer: git-send-email 2.48.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Mykola Kvach 

This patch adds CONFIG_SYSTEM_SUSPEND guards around freeze_domains
and thaw_domains functions.

This ensures they are only compiled into the hypervisor when the system
suspend functionality is enabled, aligning their inclusion with their
specific use case.

Signed-off-by: Mykola Kvach 
---
 xen/common/domain.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 8c8f70347a..303c338ef2 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -2411,6 +2411,8 @@ domid_t get_initial_domain_id(void)
     return 0;
 }
 
+#ifdef CONFIG_SYSTEM_SUSPEND
+
 void freeze_domains(void)
 {
     struct domain *d;
@@ -2436,6 +2438,8 @@ void thaw_domains(void)
     rcu_read_unlock(&domlist_read_lock);
 }
 
+#endif /* CONFIG_SYSTEM_SUSPEND */
+
 /*
  * Local variables:
  * mode: C
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 07:01:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 07:01:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023161.1399083 (Exim 4.92)
	(envelope-from )
	id 1uTxej-0004Br-40; Tue, 24 Jun 2025 07:01:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023161.1399083; Tue, 24 Jun 2025 07:01: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 1uTxej-0004Bk-1J; Tue, 24 Jun 2025 07:01:21 +0000
Received: by outflank-mailman (input) for mailman id 1023161;
 Tue, 24 Jun 2025 07:01: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 1uTxeg-0004Be-Rf
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 07:01:19 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20608.outbound.protection.outlook.com
 [2a01:111:f403:2412::608])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 04c31ec4-50c9-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 09:01:16 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by PH7PR12MB6936.namprd12.prod.outlook.com (2603:10b6:510:1ba::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Tue, 24 Jun
 2025 07:01:10 +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.8835.027; Tue, 24 Jun 2025
 07:01: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: 04c31ec4-50c9-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=WHCTXoyU4979xWvloFyR/hj85+jCLgOwsUa15QCm0mY4mgqv5Y2mp3+c68JqmIfxL6uEoINwvZGPcThPoZHt2suu1sXEV8rXnbJcP+Ugd3p4oORKQP/hmzYVjJQIp+W2mLd8vX++mHM2D+ScPm08loi3grjfwCgKSSKYmNKm/ODuVM6kXcF8p6gIKGoiXd2BeIPYtKmM11XN1FeLtgL/TFp9ROM9Fpvijw5ULsIdDij3wvGZQlgtvWpi6g5cfguF/ofm64kb9Y4uxyZNxFADLhNZ9qifHq+Kuo+f0Sw+14Nf8KcDJ8zcNBSqHvvAtsyffrPUBG5LLcNcwICsQnOy3Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=w0G8RpxyseQ+LwX4bSHiNKqzn/0U9DNZI25y3B63mNI=;
 b=MeoQJKugsd33elynreIwy53dVKlj04/ccZpQDc6U8khGAS+PliQlzAaPaAUT6dgAuWrJ7PULmHywfovXSNxYvsNMYownyNVp+yc2IAWDcJ9BAeIrArW8zbbHbLwSHYjamTtxXDswUP2+l5bIbRRrVtkTouaqUvQA3XZ8FWZ9B45f3OXv9f8kJlGMknDy3rzapDBGm3ZKbiyL+NVKVG0EVSLC9E/jJIqL0i0KHOZqoNShsCoI5e/F5fW8GjCyxdNC6SlJbkD8qN1AnCaoaQBTA70GksbThYDKbxSxyFnbmdpjjTUGmwnUGbzk16tFdjJqQrD2Ig3pvS7tjVWuZNu8eg==
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=w0G8RpxyseQ+LwX4bSHiNKqzn/0U9DNZI25y3B63mNI=;
 b=X2nVWw+c4QOs9mzgfTjztxON1xkBrx33vDXivSV3TNp/61WhPQu1JhB5SS5a8gm4m8Cs5S3z0EYPTXU4Ho8xWVabtoOLdg+rX1lmXJ2i3+ukYyWjnmHBvCxF2SiEaoysMWrlHjWcVCqVGytT+cSUlTv0uNc2PGa1ybh9JClsQB4=
From: "Chen, Jiqian" 
To: Jan Beulich , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	
CC: "Huang, Ray" , "xen-devel@lists.xenproject.org"
	, "Chen, Jiqian" 
Subject: Re: [PATCH v6 1/8] vpci/header: Emulate extended capability list for
 dom0
Thread-Topic: [PATCH v6 1/8] vpci/header: Emulate extended capability list for
 dom0
Thread-Index: AQHb23yZHYwoBN0glE68BnOedByoqrQI+ZKAgAFXGYCAAVGyAIAG16sA
Date: Tue, 24 Jun 2025 07:01:10 +0000
Message-ID:
 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-2-Jiqian.Chen@amd.com>
 <669877f5-ef34-4552-9cfc-e097d40d444a@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.8835.025)
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_|PH7PR12MB6936:EE_
x-ms-office365-filtering-correlation-id: 399fe74a-0dca-48cc-e79c-08ddb2ece693
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?OVRZZmh6QnN0NGJoUjNuTHNLZ0ZZTTRKYm4yUlBNYUhsbWNSbDExMXVlN2Z6?=
 =?utf-8?B?TDdUbHFwcVFYOUM2N0dwQ3hwQ1RDanZjR05LRjNtTjFNT25ud0RIZHR1eTJK?=
 =?utf-8?B?dzVrcTE5VDg3Ym5BcThjeDNjNytRdExXZ3BJL3k5bXpVTm9WanhqYUtDU1FS?=
 =?utf-8?B?cHdid2ljeGZnVWp5WjFYeklIWnZFZEJyTUdrNGloL1c5MC8xekRHRUY1dU1Q?=
 =?utf-8?B?THBuSHpieTRYOVpnOGMvRTArcWdHY2V0cHQxL0QwRldrdXlSNmNYZTBNd2w3?=
 =?utf-8?B?VnJOYXpYakprdzlxTTBxdUxBd2JVZFRmNFBEWHNxNkx3cWIxREtDaUNIdjY5?=
 =?utf-8?B?TWtsVW95aDd6K1BIVVNKZzNINnRCQkdoemdBNFl6Qmx3SzZlczBBNDQzRXV5?=
 =?utf-8?B?WjM2UmZBT3d1QnVURndrUUpMNTgzMVRUTHFZeUVPTXBNazEyVzcvaEY1Mlh2?=
 =?utf-8?B?YzJYYzhDS3VQZ1VtNkYwMExaU3pTSjhZckpuNWlYejdxcnlHMk50dDdiK2Rr?=
 =?utf-8?B?cVdQOGI5eGRXd3JzZWdIQ1dvTDUrbVdqNGRlT1lQYTVOQmtLWVdKUTk2M1pQ?=
 =?utf-8?B?akUzOFA1aHpUWnk5YkR1YWhrN0RhS3JIZEQyU3VtUFRNODdiaUFLNjlTd2kz?=
 =?utf-8?B?MVpycm1BVDZDaE5ZSjdibjJnUlZxOUViZzNpbGgrSk1KS2NueGd5MjEvU3JF?=
 =?utf-8?B?RkpXbmQ1aHVzbURIcVdxZXdacnZBV2pWZU04MG4xb3NCbGtBYWZzb2ZwZkdN?=
 =?utf-8?B?MVovaU8yKytDQmhxU1RObG9EbjEvOXdtK1JzVXl6WU82TjNzOWhsQThRMEty?=
 =?utf-8?B?aHNUczQ4NnFpZEh5VkNzaFVHY09iaDdpaTZFY0IxSzhFWFRiNCtYOGZqWUpY?=
 =?utf-8?B?ZlNvS25VZk1mVXhKZUVCMGNSb2VTTDkyQnd2ZzBNUTJlc1VIWUhzQngyNjVm?=
 =?utf-8?B?cjVCOXRXbmdPN1NxaG5sdklWN0t2OGFxbS9mTFJOaTFuRlhTMXBiMUZuNE1I?=
 =?utf-8?B?TjhheWJJaUc4d1FmWGlsL1prRWVoZHlEUEM3WkM1RHZ0eWtJUEl4cDVNeGx6?=
 =?utf-8?B?Vy9ndmV6K0FpdnlvK291TzFkQlo3QnNOU1lPa2l6UmI3VkNQbHlPY3pGb3hq?=
 =?utf-8?B?YjVuVE9lSFFmMkJqbkRqa01aQnRhUkpKbkZHeVFpOTJ0L2FXU09Pb2VlRlk3?=
 =?utf-8?B?UmhTRlVkc3dJV0VhbDVVMGFYb2xqenFnbm5RUG9HYjJGVk5ySDVJQUZxaGVp?=
 =?utf-8?B?ZUdXd1BmTmdYbWM0eU9pMEdyaFVBMXdENDg3TmltVHgwYnk4RUFDc1IvV3Rl?=
 =?utf-8?B?cnl3ZEtsQWxISXZ6V01JeDk4UlFsdm9ubW9SU2VGenc2RmQ4YWtnbm9nU0hL?=
 =?utf-8?B?U0NPR2U4L0p6YlpPcEhjTkFyZC8xTW9udWN0T1VrWEFHVFNkNVNwdGZ1dk80?=
 =?utf-8?B?QWlQZTlJeExLc2x4NUNPa2RJMUh0MUtGQjBIaVBxUWxmR1c1czZ4YXgwZnNi?=
 =?utf-8?B?c2I2RFFBYzFqQUJBdEs5ZFUvdGJxNWRwaFNveXF6WUNWRFMrMFZhbDFkaEJX?=
 =?utf-8?B?T296VHZoRXBCL2RCbjZwUnIrT0MzUUNjNFZURmVrdXkyamxNanlkVEVQcTQy?=
 =?utf-8?B?Wm1waGVoRFF5eDZvY3VqK1oyVDlLUk93UXp6cGJXVWM2WFNuM3lLY25COW1G?=
 =?utf-8?B?bHNUd3hBVmhtTXQyWnhxUmtNdEZaMzNJZkpaL1FOM0IzTUlPN1BFMlpEL0xB?=
 =?utf-8?B?K3Y4L0J2dVVjMnRMc1hROVhxTFB5OGE5UU9sODhtR042ZzdtUFV4aHl4QVhB?=
 =?utf-8?B?N3NERlFRMVNPclN6WmcxdGJHbzlQTlFTam5tcVExQmIwaWwvUmhVdzJnMmYx?=
 =?utf-8?B?TnNqWHVGWTN1NEVkR1NnSWxNQXBJcVdGalFaL3dXc3pBU1lIb1V5c1VLSk5v?=
 =?utf-8?B?TTIzZTFZR0dvQ212RzJ5b1NrRngwVVVKL2RvemdneFhTRWhHZ2dCSExTMlhO?=
 =?utf-8?Q?rHi6lJ+GrdTEmohOB0epWefnjosr1A=3D?=
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?Nm5nTXZJYS9CN2FVTy9Icm5FS2hhQTBvN0kvSzVoQlNISjRZZDdJUGVoblZQ?=
 =?utf-8?B?aWNKTmoyOFI4anBuZ1NJSkVIbGFSU2NOeGZSSENQeW1SRzA0VUcxc2RPazNK?=
 =?utf-8?B?ajlpaHE0blJiL0huYlAyV2traTQ1L2l4SGxNMlRGWDFPUzBZUGo4WWQ2VndM?=
 =?utf-8?B?L1NnYmxPckZHUEhxOGFrTk84Q2NhSnk2a0N1L3FicjBnU1VHWW1VVGVFbHYz?=
 =?utf-8?B?SWs2SlBKNHRPOTc2UzBXU0ZDMnE3UVdzbS9iTXlqVE5FRkpKelN3VVZwQ1Yz?=
 =?utf-8?B?WVl6d1JLcmJIRjU2SFJSUHdkQ20zOTQrVElKMmNlSTNpUjFnSml4NkpjbFIy?=
 =?utf-8?B?b3hacjgxK21CRXgzZkw0aDZRRXpLaitvb1pmdHc5czl6dG43N2xwL1ppdEVK?=
 =?utf-8?B?NVpjV1ZsY3N2NzZuVWxUOUZrWFpJMkdQSkJCZzFyZ2ZpUnU3RlhuNVEzamh4?=
 =?utf-8?B?UThJRkpBTXo5bGRKMXdQZWxud0JsYVczN05UZ3pnblR5Y2VmdDBYeitjNDcr?=
 =?utf-8?B?SHkrS251TzZpSTV6SG5yWFkvZVRoSVFSWEtocWF0bEhHMUZFclNXa21jcmdj?=
 =?utf-8?B?bkh3WXJ0eDFLdGdFNkJwblNYWXVJdmtTMHE5MmF4ZFU1MlZYMFYreHFXaU1R?=
 =?utf-8?B?QnBhZXZhemtmZEFhdzQxcmgzS0dlWEhBSXYzWGJvdm1DV0Y5S0NaM2lhQ0Rz?=
 =?utf-8?B?Q1NMbnduZkZFeHlQSjV6b1ZweXFlUkVrSjBrYllTWFltcnk3RHZFeUdCYmF6?=
 =?utf-8?B?ZFpvY0FlK3o0ZmNwZWpOL01CM2t1YnVNaWljbGg4b1dzUXlHRmczdGV0NWhm?=
 =?utf-8?B?TjA2TmoyVVQ0eFBoYmFOclNzT3RaYnZJZ2xRV050dUFSclh4bnZTZFhjTllr?=
 =?utf-8?B?SmJDQWpOaFlJeWFiWWFuTlllVndXSnRLUDlDeHNqM3J6WHhIT09DMk12MVpT?=
 =?utf-8?B?WWxPN3UzYjNFL2RTdXZ5TXRwU1BjengxYkRiMndFenRZbE05RjBoSWRVcXRi?=
 =?utf-8?B?R3ZWYllTZTJZbkZQWVpJaGc3SWM3dGdRbSthNlZCQm1rakt0VG1sQVFCNTNr?=
 =?utf-8?B?UVJnQ1RxanBJemNtcWoxdDQzRFpSMWVXVTFyVlk5UjZ0OHBYbWc4a2ZjQVJP?=
 =?utf-8?B?OW04UmkrTUNiSytVcTg1U2hmcGE2blhSeGFCb2xSQ05iUndwVHg2YzNnZXpB?=
 =?utf-8?B?aGZ3TGlIaUkzclU1YWxyS3hHUkhUYmdIQnE2SUFndGFyZ05KaTB3aCt2SUhC?=
 =?utf-8?B?QmtLM1UwWmdjL2l6MXc2K3hPOXA4WUhxK2hmcUZkdWUxWnlVeEFlWGR2MzVz?=
 =?utf-8?B?eTVEQ1pLN1hhNVV0SUt0Qzl3ZWlOYitiRCtWeUxhRWgzczJ1TWtKMDRBN3la?=
 =?utf-8?B?NTVtdzZUWXNqVmVsYWxndDVnSDNHbHNVR1VWWlgrUFQ2NEFnbGhuNlR4SkVn?=
 =?utf-8?B?ZmJsQkNYZGFybGZkZHpPcm92SnNnMWR4RURzWDUxTzBCVkszK0gwUUFYRWN0?=
 =?utf-8?B?dFIvWGE2bUQwQ2o2eWh6T2hVcnV6UGZEdFJrSElkNVY5OG1vcjlOUTRNSDBK?=
 =?utf-8?B?QzgwcSs2TmJCTFExYmNrTENLMUJMYnNKV0NLU3lpS21WeUxOQTVlY2c1MHJC?=
 =?utf-8?B?aVZya21taHRQZlRsK2tGa1BhdzVXYjRmNjBPOGhaYlhXZSsyci9Pd1E3UTAx?=
 =?utf-8?B?OVRxOG9LbG1kNWpYK3hWUmcyRnZ1aHR1eGQzamsra2NGbGpUYitUQXg0K2lH?=
 =?utf-8?B?M0hNMDBsbWE1NmpnQkZLcFJiNXZJR2Y2QmJnS3RUVEVWRUlKb2pGMVE2RnhK?=
 =?utf-8?B?djB6VFZ1WnBPY2JCS1RpaFMweHFsdm5EYys1aDE0bnNHdnUrZElUYi81cld6?=
 =?utf-8?B?a083cDVQN2YxYmZMTk5VSm5DRGFaODEyb0k0QXhnYXdTU1VBZEw0TE5ya0c3?=
 =?utf-8?B?MHgwTm1oZno3VUU4N0wwNms2MHF3QWpSZEtHOXEzY0dSczA0dWFPcEFTR1ZZ?=
 =?utf-8?B?eXlxMkI5amRMa0lnYWlVeWVsdTFhdzRoeU9BUjV1V2RhUTJFZEdMekNpb0ZQ?=
 =?utf-8?B?ZDRENzRETVNBVVh5UXJUK3BodGd4ZXNBSEJYQmFiY1d3KzRxUE5wRkViQnRh?=
 =?utf-8?Q?lLYw=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <63FAC9A06786224BA7AAE2721DFC0395@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: 399fe74a-0dca-48cc-e79c-08ddb2ece693
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2025 07:01:10.6502
 (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: D6+u5ewYS3GJfmIMrR1XK0MX2PCIhL0TT+9MrM3f26UQMGoY1atcMs3Xe/vCi82bRj0AI7jBH8XhAgps8VaXfw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6936

T24gMjAyNS82LzIwIDE0OjI5LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMTkuMDYuMjAyNSAw
NDoyOSwgQ2hlbiwgSmlxaWFuIHdyb3RlOg0KPj4gT24gMjAyNS82LzE4IDIxOjUyLCBKYW4gQmV1
bGljaCB3cm90ZToNCj4+PiBPbiAxMi4wNi4yMDI1IDExOjI5LCBKaXFpYW4gQ2hlbiB3cm90ZToN
Cj4+Pj4gLS0tIGEveGVuL2RyaXZlcnMvdnBjaS9oZWFkZXIuYw0KPj4+PiArKysgYi94ZW4vZHJp
dmVycy92cGNpL2hlYWRlci5jDQo+Pj4+IEBAIC04MzYsNiArODM2LDQyIEBAIHN0YXRpYyBpbnQg
dnBjaV9pbml0X2NhcGFiaWxpdHlfbGlzdChzdHJ1Y3QgcGNpX2RldiAqcGRldikNCj4+Pj4gICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQQ0lfU1RBVFVTX1JTVkRaX01BU0spOw0K
Pj4+PiAgfQ0KPj4+PiAgDQo+Pj4+ICtzdGF0aWMgaW50IHZwY2lfaW5pdF9leHRfY2FwYWJpbGl0
eV9saXN0KHN0cnVjdCBwY2lfZGV2ICpwZGV2KQ0KPj4+PiArew0KPj4+PiArICAgIHVuc2lnbmVk
IGludCBwb3MgPSBQQ0lfQ0ZHX1NQQUNFX1NJWkU7DQo+Pj4+ICsNCj4+Pj4gKyAgICBpZiAoICFp
c19oYXJkd2FyZV9kb21haW4ocGRldi0+ZG9tYWluKSApDQo+Pj4+ICsgICAgICAgIC8qIEV4dGVu
ZGVkIGNhcGFiaWxpdGllcyByZWFkIGFzIHplcm8sIHdyaXRlIGlnbm9yZSBmb3IgZ3Vlc3QgKi8N
Cj4+Pg0KPj4+IHMvZ3Vlc3QvRG9tVS8gPw0KPj4gV2lsbCBkby4NCj4+DQo+Pj4NCj4+Pj4gKyAg
ICAgICAgcmV0dXJuIHZwY2lfYWRkX3JlZ2lzdGVyKHBkZXYtPnZwY2ksIHZwY2lfcmVhZF92YWws
IE5VTEwsDQo+Pj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwb3MsIDQsICh2
b2lkICopMCk7DQo+Pj4+ICsNCj4+Pj4gKyAgICB3aGlsZSAoIHBvcyA+PSBQQ0lfQ0ZHX1NQQUNF
X1NJWkUgKQ0KPj4+PiArICAgIHsNCj4+Pj4gKyAgICAgICAgdWludDMyX3QgaGVhZGVyID0gcGNp
X2NvbmZfcmVhZDMyKHBkZXYtPnNiZGYsIHBvcyk7DQo+Pj4+ICsgICAgICAgIGludCByYzsNCj4+
Pj4gKw0KPj4+PiArICAgICAgICBpZiAoICFoZWFkZXIgKQ0KPj4+PiArICAgICAgICAgICAgcmV0
dXJuIDA7DQo+Pj4NCj4+PiBJcyB0aGlzIGEgdmFsaWQgY2hlY2sgdG8gbWFrZSBmb3IgYW55dGhp
bmcgb3RoZXIgdGhhbiB0aGUgZmlyc3QgcmVhZD8gQW5kIGV2ZW4NCj4+PiBpZiB2YWxpZCBmb3Ig
dGhlIGZpcnN0IG9uZSwgc2hvdWxkbid0IHRoYXQgYWxzbyBnbyB0aHJvdWdoIC4uLg0KPj4+DQo+
Pj4+ICsgICAgICAgIHJjID0gdnBjaV9hZGRfcmVnaXN0ZXIocGRldi0+dnBjaSwgdnBjaV9yZWFk
X3ZhbCwgdnBjaV9od193cml0ZTMyLA0KPj4+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHBvcywgNCwgKHZvaWQgKikodWludHB0cl90KWhlYWRlcik7DQo+Pj4NCj4+PiAuLi4gaGVy
ZT8NCj4+IElmIGhlYWRlciBvZiBmaXJzdCBpcyB6ZXJvLiBUaGVyZSBpcyBubyBuZWVkIHRvIGFk
ZCBhIHJlZ2lzdGVyIEkgdGhpbmssIHNpbmNlIHRoZSBkb20wIGNhbiByZWFkL3dyaXRlIGRpcmVj
dGx5Lg0KPiANCj4gV2VsbCwgbXkgcmVtYXJrIG9mIGNvdXJzZSBkaWQgZ28gYWxvbmcgd2l0aCB0
aGF0IGZ1cnRoZXIgZG93bi4gUGx1cyBJIHdvbmRlcg0KPiB3aHkgdGhlIGVudGlyZSBmaWVsZCBi
ZWluZyB6ZXJvIGlzIHNwZWNpYWwsIGJ1dCB0aGUgZmllbGQgaG9sZGluZywgc2F5LA0KPiAweDAw
MDEwMDAwIGlzbid0LiBZZXMsIHRoZSBzcGVjIGNhbGxzIG91dCB6ZXJvZXMgaW4gYWxsIGZpZWxk
cyBzcGVjaWFsbHksDQo+IHlldCBhdCB0aGUgc2FtZSB0aW1lIGl0IGRvZXMgc2F5IG5vdGhpbmcg
YWJvdXQgY2VydGFpbiBvdGhlciBzcGVjaWFsIHZhbHVlcy4NCklmIHdhbnQgdG8gY292ZXIgdGhl
c2Ugc3BlY2lhbCB2YWx1ZXMuDQpTaG91bGQgSSBuZWVkIHRvIGNoYW5nZSB0aGUgY2hlY2sgZnJv
bSAiIWhlYWRlciIgdG8gIiEgUENJX0VYVF9DQVBfSUQoaGVhZGVyKSIgPw0KDQo+IA0KPiBKYW4N
Cj4gDQo+Pj4+IC0tLSBhL3hlbi9kcml2ZXJzL3ZwY2kvdnBjaS5jDQo+Pj4+ICsrKyBiL3hlbi9k
cml2ZXJzL3ZwY2kvdnBjaS5jDQo+Pj4+IEBAIC0yNjcsNiArMjY3LDEyIEBAIHZvaWQgY2ZfY2hl
Y2sgdnBjaV9od193cml0ZTE2KA0KPj4+PiAgICAgIHBjaV9jb25mX3dyaXRlMTYocGRldi0+c2Jk
ZiwgcmVnLCB2YWwpOw0KPj4+PiAgfQ0KPj4+PiAgDQo+Pj4+ICt2b2lkIGNmX2NoZWNrIHZwY2lf
aHdfd3JpdGUzMigNCj4+Pj4gKyAgICBjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldiwgdW5zaWdu
ZWQgaW50IHJlZywgdWludDMyX3QgdmFsLCB2b2lkICpkYXRhKQ0KPj4+PiArew0KPj4+PiArICAg
IHBjaV9jb25mX3dyaXRlMzIocGRldi0+c2JkZiwgcmVnLCB2YWwpOw0KPj4+PiArfQ0KPj4+DQo+
Pj4gSWlyYyB3ZSd2ZSBiZWVuIHRoZXJlIGJlZm9yZSwgeWV0IEkgY29udGludWUgdG8gd29uZGVy
IHdoZXRoZXIgd2UncmUgZG9pbmcNCj4+PiBvdXJzZWx2ZXMgYW55IGdvb2QgaW4gYWxsb3dpbmcg
d3JpdGVzIHRvIHNvbWV0aGluZyB0aGF0IGNlcnRhaW5seSBiZXR0ZXINCj4+PiB3b3VsZG4ndCBj
aGFuZ2UuIEV2ZW4gaWYgd2UgbGltaXQgdGhpcyB0byBEb20wLg0KPj4gSSByZW1lbWJlciB0aGlz
IHdhcyBzdWdnZXN0ZWQgYnkgUm9nZXIgaW4gVjIsIHNpbmNlIHRoZSBEb20wIGhhcyBubyBsaW1p
dGF0aW9ucyB0byB3cml0ZSB0aGUgZXh0ZW5kZWQgcmVnaXN0ZXIuDQo+Pg0KPj4+DQo+Pj4gSmFu
DQo+Pg0KPiANCg0KLS0gDQpCZXN0IHJlZ2FyZHMsDQpKaXFpYW4gQ2hlbi4NCg==


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 07:14:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 07:14:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023172.1399094 (Exim 4.92)
	(envelope-from )
	id 1uTxrJ-0007Zu-A4; Tue, 24 Jun 2025 07:14:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023172.1399094; Tue, 24 Jun 2025 07: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 1uTxrJ-0007Zn-76; Tue, 24 Jun 2025 07:14:21 +0000
Received: by outflank-mailman (input) for mailman id 1023172;
 Tue, 24 Jun 2025 07: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 1uTxrH-0007Zh-Dq
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 07:14:20 +0000
Received: from mail-10631.protonmail.ch (mail-10631.protonmail.ch
 [79.135.106.31]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d7308873-50ca-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 09:14:17 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d7308873-50ca-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1750749255; x=1751008455;
	bh=cuN8mmJqD27E+XZYiZXR3wELgsWrA9nQ/IWAH2J8jDI=;
	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;
	b=B/n0IILGgfCw8ysHPJEuMyCXx9jRsL5UYUszgMKm/knHBTnKd/qVVdl50qDg+JExS
	 OiVYF6qvks+tYRsBgYKOBo37qA27FvqeyF8Veg3Jum26S40cJn67W/CXeKABdKlNX4
	 HpUOJ9POc4UTpTdxFDeGbIq21NQX+BPJqnlGtL+zQyoGzWS503ALDaXXMy4NTgOJdm
	 Vprr8B10mmpx6XidqvLBJ0PV2WEHCx9J3EMqrARVR4oLtzeHzYfN8Vlhoe5GlxuSAm
	 8se+G3I0aDlKJjF+7Bi3bfSBWFS2xqhN+64FpjYpme+WA/2JFL6rcQz6RIEo8pkHgz
	 woFyrwYNao2iw==
Date: Tue, 24 Jun 2025 07:14:09 +0000
To: "Orzel, Michal" 
From: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, oleksii.kurochko@gmail.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: Re: [PATCH v1 07/16] arm/vuart: rename 'virtual UART' Kconfig option
Message-ID: 
In-Reply-To: <070f16b8-c397-487c-bcb8-0ba13bad919b@amd.com>
References: <20250624035443.344099-1-dmukhin@ford.com> <20250624035443.344099-8-dmukhin@ford.com> <070f16b8-c397-487c-bcb8-0ba13bad919b@amd.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 430f2903a2c0eccae9c94b94759ff41c164de67d
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 24, 2025 at 08:37:22AM +0200, Orzel, Michal wrote:
>=20
>=20
> On 24/06/2025 05:55, dmkhn@proton.me wrote:
> > From: Denis Mukhin 
> >
> > Rename HWDOM_VUART to HAS_VUART_MMIO.
> >
> > This emulator emulates only one register and the use of the emulator is
> > limited to early boot console in the guest OS.
> >
> > No functional change.
> >
> > Signed-off-by: Denis Mukhin 
> > ---
> >  xen/arch/arm/Kconfig              | 2 +-
> >  xen/arch/arm/Makefile             | 2 +-
> >  xen/arch/arm/include/asm/domain.h | 2 +-
> >  xen/arch/arm/vuart.h              | 4 ++--
> >  4 files changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> > index 03888569f38c..b11cb583a763 100644
> > --- a/xen/arch/arm/Kconfig
> > +++ b/xen/arch/arm/Kconfig
> > @@ -177,7 +177,7 @@ config HAS_VUART_PL011
> >  =09  Allows a guest to use SBSA Generic UART as a console. The
> >  =09  SBSA Generic UART implements a subset of ARM PL011 UART.
> >
> > -config HWDOM_VUART
> > +config HAS_VUART_MMIO
> I personally don't like this change. The current config option name reads=
 much
> better and clearly denotes the purpose.

In my opinion, the MMIO-based UART is a useful debugging tool for early gue=
st
boot, even when the guest doesn't run in hwdom or on Arm system.

>=20
> ~Michal
>=20



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 07:19:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 07:19:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023179.1399105 (Exim 4.92)
	(envelope-from )
	id 1uTxvw-00088s-Tm; Tue, 24 Jun 2025 07:19:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023179.1399105; Tue, 24 Jun 2025 07:19:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTxvw-00088l-PC; Tue, 24 Jun 2025 07:19:08 +0000
Received: by outflank-mailman (input) for mailman id 1023179;
 Tue, 24 Jun 2025 07:19: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 1uTxvv-00088f-NX
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 07:19:07 +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 82968876-50cb-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 09:19:04 +0200 (CEST)
Received: by mail-lf1-x136.google.com with SMTP id
 2adb3069b0e04-553ba7f11cbso112460e87.1
 for ; Tue, 24 Jun 2025 00:19:04 -0700 (PDT)
Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-553e41c301esm1713392e87.143.2025.06.24.00.19.02
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 24 Jun 2025 00:19:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 82968876-50cb-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750749544; x=1751354344; 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=LXYC7VlKvFyK65wnrApO7g7blDDOmo+NPeKeGgJUPGo=;
        b=W3RUm1EvZtOkibcHR/8KRq8sSeq4SmxIjUZULPcRWVMWfC8ajdLkDFoqfnDHQtWC60
         dM+IGRBcX8MdnR1YDUrec+OfQCRssaF65iIE2FN7w8ZbmJF48pufMqr031oQJ96nvcpa
         3a0ODyNrD9FVgluSFnj6XDVLa9L08YI04zutcJQzhviuXd8TmC1LpwWZarpXGzvTZfvq
         JjTqF6tGYYaxKdE1o2WHSSrsPbI2DZhUORyB97FehW6EOfUJir9nmAFHApRjYqODSCGd
         Q29/491Mppxc04kTWv3QkXkgiQDjR4SVF6iGUHW8Ub5+VXqlWY2ALOwSZWH+ZiFKLvnH
         5v3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750749544; x=1751354344;
        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=LXYC7VlKvFyK65wnrApO7g7blDDOmo+NPeKeGgJUPGo=;
        b=M7qQdntocf3ejiLGckaru3yhUpHM9p9BgHW0Wh2FGMxuGHxlmlaYnPzH6drAEfAiNs
         dO3AmUz2W9I6f1XcvdbmNz4z0jW0sels9oQZexkAH6u7b5+fQOh7hzDUOt8A76+22o3c
         iqIG9Ry6gQHC5/NLuKNQNmSPH/kojzlPlSz9EFsy7txbUHGgbCAYhHBZ8UPSF6KfwA2s
         uuJcIyjm6HRPKd9uipBA39+EM+Oo76rkGZMvzoqXhrWDOZEIjJwtM7Tx6Uz9oWPdaM6O
         Zv3CPlHFkPtuyg5LvUXz8S8dgaoceUHYq+g+Igpj0aU3/8/T/rx8CfTv++q41zfPsTK1
         hezQ==
X-Gm-Message-State: AOJu0YyIdKRYmHnB/iF9EUVLF7t/pYx5Z2uBHDp6eq//Wy/Av00m08Nb
	oZNfBWc9EWpIRMzUM4UCiBclcNb/o9DZcAQF6xRqXlOTm6XF74z/FAjNHYctV06GZao=
X-Gm-Gg: ASbGncshFkGDEDZxlAZuzRd/ri96cxIaP9TFGamohaOFxMsJzFmBJXMzkO68GzbqR2d
	UB9QyWfZnpEcnBFLIzAy80Cqw47ICY5JcHvDxCHBDUsp5wxBx0imQUPGJi7QOYhBWdObSDO2boP
	FXhEAUB97Eq2W5rT15qyv8MAHw0KVrb9kisqtwmDhoGbw39+/CwI2sz9839bZxQW/u12jWC5Wqb
	ivaIs1rf2HjbcnSlVqHfD4ZdzsAuqtfjY6DVzGUSi3JwoztdvKugWbngfhMGEfGHuRdAaUeY0k+
	k2ozBoTZSOWueYr4BwtspdUXTLknSwOdDkiS9a5wyzD0gYmNI7Hw1q/KGvWuOYKm4WFomcWfdi7
	GD3m+KIZIY70Fu9xQ6TYDh4qHQg==
X-Google-Smtp-Source: AGHT+IGa4Au9bIHRjI28POgwOAtq9JiCYwQiOMBbK1EpfFlaP4s3Aovcoamq2nQ/Phr0HY5Pc+OOlA==
X-Received: by 2002:a05:6512:224a:b0:553:ad9b:cfb1 with SMTP id 2adb3069b0e04-553e3b9a36fmr4461062e87.9.1750749543739;
        Tue, 24 Jun 2025 00:19:03 -0700 (PDT)
From: Mykola Kvach 
To: xen-devel@lists.xenproject.org
Cc: Volodymyr Babchuk ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Oleksandr Andrushchenko ,
	Mykola Kvach 
Subject: [PATCH v4] xen/char: implement suspend/resume calls for SCIF driver
Date: Tue, 24 Jun 2025 10:18:56 +0300
Message-ID: <5449d6fc4a6e47af173d9e2b285f1e3398de98a3.1750749332.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.48.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Volodymyr Babchuk 

Implement suspend and resume callbacks for the SCIF UART driver,
enabled when CONFIG_SYSTEM_SUSPEND is set. This allows proper
handling of UART state across system suspend/resume cycles.

Tested on Renesas R-Car H3 Starter Kit.

Signed-off-by: Volodymyr Babchuk 
Signed-off-by: Oleksandr Andrushchenko 
Signed-off-by: Mykola Kvach 
---
In patch v2, I just added a CONFIG_SYSTEM_SUSPEND check around
the suspend/resume functions in the SCIF driver.

In patch v4, enhance commit message, no functional changes
---
 xen/drivers/char/scif-uart.c | 40 ++++++++++++++++++++++++++++++++++--
 1 file changed, 38 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/char/scif-uart.c b/xen/drivers/char/scif-uart.c
index 757793ca45..888821a3b8 100644
--- a/xen/drivers/char/scif-uart.c
+++ b/xen/drivers/char/scif-uart.c
@@ -139,9 +139,8 @@ static void scif_uart_interrupt(int irq, void *data)
     }
 }
 
-static void __init scif_uart_init_preirq(struct serial_port *port)
+static void scif_uart_disable(struct scif_uart *uart)
 {
-    struct scif_uart *uart = port->uart;
     const struct port_params *params = uart->params;
 
     /*
@@ -155,6 +154,14 @@ static void __init scif_uart_init_preirq(struct serial_port *port)
 
     /* Reset TX/RX FIFOs */
     scif_writew(uart, SCIF_SCFCR, SCFCR_RFRST | SCFCR_TFRST);
+}
+
+static void scif_uart_init_preirq(struct serial_port *port)
+{
+    struct scif_uart *uart = port->uart;
+    const struct port_params *params = uart->params;
+
+    scif_uart_disable(uart);
 
     /* Clear all errors and flags */
     scif_readw(uart, params->status_reg);
@@ -271,6 +278,31 @@ static void scif_uart_stop_tx(struct serial_port *port)
     scif_writew(uart, SCIF_SCSCR, scif_readw(uart, SCIF_SCSCR) & ~SCSCR_TIE);
 }
 
+#ifdef CONFIG_SYSTEM_SUSPEND
+
+static void scif_uart_suspend(struct serial_port *port)
+{
+    struct scif_uart *uart = port->uart;
+
+    scif_uart_stop_tx(port);
+    scif_uart_disable(uart);
+}
+
+static void scif_uart_resume(struct serial_port *port)
+{
+    struct scif_uart *uart = port->uart;
+    const struct port_params *params = uart->params;
+    uint16_t ctrl;
+
+    scif_uart_init_preirq(port);
+
+    /* Enable TX/RX and Error Interrupts  */
+    ctrl = scif_readw(uart, SCIF_SCSCR);
+    scif_writew(uart, SCIF_SCSCR, ctrl | params->irq_flags);
+}
+
+#endif /* CONFIG_SYSTEM_SUSPEND */
+
 static struct uart_driver __read_mostly scif_uart_driver = {
     .init_preirq  = scif_uart_init_preirq,
     .init_postirq = scif_uart_init_postirq,
@@ -281,6 +313,10 @@ static struct uart_driver __read_mostly scif_uart_driver = {
     .start_tx     = scif_uart_start_tx,
     .stop_tx      = scif_uart_stop_tx,
     .vuart_info   = scif_vuart_info,
+#ifdef CONFIG_SYSTEM_SUSPEND
+    .suspend      = scif_uart_suspend,
+    .resume       = scif_uart_resume,
+#endif
 };
 
 static const struct dt_device_match scif_uart_dt_match[] __initconst =
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 07:25:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 07:25:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023189.1399114 (Exim 4.92)
	(envelope-from )
	id 1uTy1a-0002OC-FB; Tue, 24 Jun 2025 07:24:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023189.1399114; Tue, 24 Jun 2025 07: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 1uTy1a-0002O5-CI; Tue, 24 Jun 2025 07:24:58 +0000
Received: by outflank-mailman (input) for mailman id 1023189;
 Tue, 24 Jun 2025 07:24: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 1uTy1Y-0002Nz-Jh
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 07:24:56 +0000
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 524e0878-50cc-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 09:24:53 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 524e0878-50cc-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1750749892; x=1751009092;
	bh=VVhCu6AXyGiFE/pEpXY9yPGFpgtwRZv27Ird8ALnhrM=;
	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;
	b=Y5y+/Kd1pIAG5xQf96EyOXZxruLT8r7svg8RPAUDylNVRwu2kut5cv+YpMBx67Idc
	 g4f1GsWNcYL9rmSzHQrYat5VyKwSuLcMOPHi3xTr0dGXNKmDDnVlDlwVz1nFo//oM6
	 aaCVEps4u+YRbR2y0cAGqJHcr8p0j0MmW0f7F/RtdbZfE38E1kDeQyJ8FyrWurwTbU
	 GFQ7tMjwtuH7l2zCZdRrGRzhKg+NUZ8z1R9e6CjHhtWoz78y6qzNh+vgc1GPStErYj
	 LqMtaVZDrGo/sVKCm7uFdgUCt1nt5I45Votu5kczB8auanSn/YT2ReZ5rLsLqYXQ1S
	 Gyzj4urxftYlw==
Date: Tue, 24 Jun 2025 07:24:48 +0000
To: "Orzel, Michal" 
From: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, oleksii.kurochko@gmail.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: Re: [PATCH v1 01/16] arm/vpl011: rename virtual PL011 Kconfig option
Message-ID: 
In-Reply-To: 
References: <20250624035443.344099-1-dmukhin@ford.com> <20250624035443.344099-2-dmukhin@ford.com> 
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 0491f51817f76b1e65b102aad53aa0d5dc29fad7
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 24, 2025 at 08:13:08AM +0200, Orzel, Michal wrote:
>=20
>=20
> On 24/06/2025 05:55, dmkhn@proton.me wrote:
> > From: Denis Mukhin 
> >
> > Rename CONFIG_SBSA_VUART_CONSOLE to CONFIG_HAS_VUART_PL011.
> Why? We emulate SBSA UART and not PL011. Despite the similarities (the fo=
rmer is
> a subset of the latter) they are not the same. I find it confusing and dr=
ivers
> for PL011 might not work with SBSA UART. Also, in the future we may want =
to
> emulate full PL011 in which case it will be even more confusing.

That's because the emulator is called vpl011, but yes, it is SBSA UART.
I will adjust to SBSA, thanks!

>=20
> Also, why HAS_?

My understanding is that HAS_ is the desired naming convention throughout t=
he
code (not documented, though), e.g. all Arm UART drivers are gated by HAS_X=
XX
(e.g. arch/arm/platforms/Kconfig).

>=20
> ~Michal
>=20



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 07:31:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 07:31:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023196.1399124 (Exim 4.92)
	(envelope-from )
	id 1uTy7h-00042U-4w; Tue, 24 Jun 2025 07:31:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023196.1399124; Tue, 24 Jun 2025 07: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 1uTy7h-00042N-0e; Tue, 24 Jun 2025 07:31:17 +0000
Received: by outflank-mailman (input) for mailman id 1023196;
 Tue, 24 Jun 2025 07:31: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 1uTy7f-00040v-G4
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 07:31:15 +0000
Received: from mail-24416.protonmail.ch (mail-24416.protonmail.ch
 [109.224.244.16]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 34ce7faa-50cd-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 09:31:13 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 34ce7faa-50cd-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1750750272; x=1751009472;
	bh=m4tkI/DAqBg5rxuU99pgQ/A8zGC86vUO0IgnqLYERYI=;
	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;
	b=RL7r2O94A7isnlu8LEcHToWsqAIyPTtnc7mliPjWelPitgg7Rn5cX8HqW5qYXYgqX
	 0eP1hFwu3DsImXwwHQJAdn/gvKkt1N/0g060J9AhmjjmT8S5E1571O0W4z7olUd/7K
	 qZYJRIfm7MBo2LVfbUi+HrDOejax2uBDxsQj7U7MmNZCq72DbJrjh42uc0oe1sj51v
	 Lz+bWBbOSe70mtMFA5CDqygE8OJN8u2f5jQCYDUQwUx3GCGwj+gHgn0hWckSaraw5w
	 LwdZatbOvbksJEgaY8LcU3JBsLC4MNxg6TBN1pkwaxPbLi1VKIjaMModzUufxsbe16
	 ljhdkRgX1GYEA==
Date: Tue, 24 Jun 2025 07:31:05 +0000
To: Jan Beulich 
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com, oleksii.kurochko@gmail.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v1 13/16] drivers/vuart: move PL011 emulator code
Message-ID: 
In-Reply-To: <6b2938a2-aa42-421f-b948-44e74f463b21@suse.com>
References: <20250624035443.344099-1-dmukhin@ford.com> <20250624035443.344099-14-dmukhin@ford.com> <6b2938a2-aa42-421f-b948-44e74f463b21@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: d2e80d935fc37cdffd1531920a5f260b0e2d4858
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 24, 2025 at 07:50:33AM +0200, Jan Beulich wrote:
> On 24.06.2025 05:56, dmkhn@proton.me wrote:
> > From: Denis Mukhin 
> >
> > Move PL011 emulator to the new location for UART emulators.
> >
> > No functional change intended.
> >
> > Signed-off-by: Denis Mukhin 
> > ---
> >  xen/arch/arm/Kconfig                               |  7 -------
> >  xen/arch/arm/Makefile                              |  1 -
> >  xen/drivers/Kconfig                                |  2 ++
> >  xen/drivers/Makefile                               |  1 +
> >  xen/drivers/vuart/Kconfig                          | 14 ++++++++++++++
> >  xen/drivers/vuart/Makefile                         |  1 +
> >  .../arm/vpl011.c =3D> drivers/vuart/vuart-pl011.c}   |  0
> >  7 files changed, 18 insertions(+), 8 deletions(-)
> >  create mode 100644 xen/drivers/vuart/Kconfig
> >  create mode 100644 xen/drivers/vuart/Makefile
> >  rename xen/{arch/arm/vpl011.c =3D> drivers/vuart/vuart-pl011.c} (100%)
>=20
> I question the placement under drivers/. To me, driver !=3D emulator. I
> wonder what others think. But yes, we already have drivers/vpci/. That
> may want moving then ...

re: driver !=3D emulator: I agree; but I followed drivers/vpci.

Do you think common/vuart would be a better location?

>=20
> Jan



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 07:32:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 07:32:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023202.1399133 (Exim 4.92)
	(envelope-from )
	id 1uTy92-0004uE-CW; Tue, 24 Jun 2025 07:32:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023202.1399133; Tue, 24 Jun 2025 07:32: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 1uTy92-0004u7-9v; Tue, 24 Jun 2025 07:32:40 +0000
Received: by outflank-mailman (input) for mailman id 1023202;
 Tue, 24 Jun 2025 07:32: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 1uTy91-0004u1-Ml
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 07:32:39 +0000
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com
 [2a00:1450:4864:20::133])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 672bd0e2-50cd-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 09:32:37 +0200 (CEST)
Received: by mail-lf1-x133.google.com with SMTP id
 2adb3069b0e04-553b82f3767so4445482e87.3
 for ; Tue, 24 Jun 2025 00:32:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 672bd0e2-50cd-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750750357; x=1751355157; 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=idY0L7FAG5ombVL1pgVzwW+SP8Atsr2COoChxPRVi8s=;
        b=dGZjNF2P2HOunqK7rSOV5u0iI9Yx9dW7y0ZbK+8AEEpj0Kyky7njbzVR60wBukL8fB
         fLsEHR2sYTWizaMbofLoqqX3ZoJxm9gDfkdVTH9/+pCmAwzYmiTRFDd1BKxlrXWr18pc
         GE68SDFf6E1raFYOXj9QLDnNIDP9+CSiiq0Etb3+ysfpVWr0NbLKU0F0oghp+V6xNjfO
         6RR3BY+sbDQsMOfbD0JIgBP9Poj3bhOhCHh+zfuDMw2RJD1PDVyAOIK4vGTY8qDjsw+J
         csso5SqGrIQqz8nozGcGYv6vFcc9x1C0bcAK3+WGGylSacd4jNw2XiM+ABqtLS6IpT/M
         XNvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750750357; x=1751355157;
        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=idY0L7FAG5ombVL1pgVzwW+SP8Atsr2COoChxPRVi8s=;
        b=Q380OSaNFdicDOf0mNgq7pmNHBhVBbKLUyUPpcHAnfv9WxmIBGa2lKAiYCiIlOnEwh
         uQA/uWX27tQ9U76kfs62NHdFs2cfSBeo4c0v/EDqv1CCewaGBVOLE1l3a+XAmRA7G68+
         k5xUun45qERW4HO7U5ZUyIogvGxhfhbC4ul3TPGXzd1EjqU9/LfOdSlJ5x35q55DSvG6
         dAeRKXW3Bxdsz6v8pjvG/tT3SsctOfvpUmpzgqJAb95YCnRmC8EBOf6YHctCT23wThOk
         N0ZEYrhKCsJtrU55fDvK/dkpOFb+RuCXoeuIBcngDxngIVHpJdTgVGo+bwSJ+uBQ78Lo
         5SFg==
X-Forwarded-Encrypted: i=1; AJvYcCWe+jnqa1NwltUgADuryZBdzKPw3bGqqnuvp7SOhhZcK4gN7G+eyKyKqmeASOkouUPyvBSnXSdTtjQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyrEb71hB743qpJNJEJ/8VEpjVrj35Hk2Dw9Kt9U2r2mffpJMh6
	+62tumlDoPthqt+5cTpslf/L86Gy492piY+a5sOgH3gk+YM1Aj83Ut8dZo3bFP7xC+24fWyxvqZ
	tcGtBcJxV1oIUskqUE5I4KZFouhCRu7HqJolQLKdG8w==
X-Gm-Gg: ASbGnctfcDpv4dT6FeWTLV/6FT1ntpYmbWkx7VjcTRABqDdfwoe2KFVT0eTMYFET3FX
	v73pE5g0r18/Qtd5QseVxiEEH4j+XtXI+diDXM3jZb4B1NCbGrAdptElR1Ya2JuCczzQoYuplFC
	sqL6ksAvnvz4kspoRCa71cE2RfWWesrRFVPqB3sCDr3ZPrr8P5Uk32
X-Google-Smtp-Source: AGHT+IEL7SZMmDPhbWZETzSyYm+qp9+Rnpl2IsuPXqcLoDr/DqkeFdgNerkdqBq8z+LamlukndWrOXP1Og6tJsbiQwQ=
X-Received: by 2002:a05:6512:1052:b0:553:3407:eee0 with SMTP id
 2adb3069b0e04-553e3ba7f4amr5193639e87.4.1750750356867; Tue, 24 Jun 2025
 00:32:36 -0700 (PDT)
MIME-Version: 1.0
References:  <1a8313537603bee36636b0fcd2fdc2f76a2374fb.1748337249.git.mykola_kvach@epam.com>
  
 <8884a8e1-4816-4b08-9f27-58f1df0c1d30@amd.com>
In-Reply-To: <8884a8e1-4816-4b08-9f27-58f1df0c1d30@amd.com>
From: Mykola Kvach 
Date: Tue, 24 Jun 2025 10:32:25 +0300
X-Gm-Features: AX0GCFsZ7SMR_8aGlSm_llCyA2Cp8uEQFXLTPcdAo0Pcqa-p3ja_zWAuKIyORlA
Message-ID: 
Subject: Re: [PATCH v4][PART 1 2/4] xen/arm: Implement PSCI SYSTEM_SUSPEND
 call for guests
To: "Orzel, Michal" 
Cc: Julien Grall , xen-devel@lists.xenproject.org, 
	Mykola Kvach , Stefano Stabellini , 
	Bertrand Marquis , Volodymyr Babchuk 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Michal,

On Fri, Jun 13, 2025 at 10:53=E2=80=AFAM Orzel, Michal  wrote:
>
>
>
> On 06/06/2025 05:52, Mykola Kvach wrote:
> > Hi, @Julien Grall
> >
> > On Wed, Jun 4, 2025 at 2:00=E2=80=AFAM Julien Grall  wr=
ote:
> >>
> >> Hi Mykola,
> >>
> >> On 27/05/2025 10:18, Mykola Kvach wrote:
> >>> From: Mykola Kvach 
> >>>
> >>> This patch adds support for the PSCI SYSTEM_SUSPEND function in the v=
PSCI
> >>> (virtual PSCI) interface, allowing guests to request suspend via the =
PSCI
> >>> v1.0 SYSTEM_SUSPEND call (both 32-bit and 64-bit variants).
> >>>
> >>> The implementation:
> >>> - Adds SYSTEM_SUSPEND function IDs to PSCI definitions
> >>> - Implements trapping and handling of SYSTEM_SUSPEND in vPSCI
> >>> - Allows only non-hardware domains to invoke SYSTEM_SUSPEND; for the
> >>>    hardware domain, PSCI_NOT_SUPPORTED is returned to avoid halting t=
he
> >>>    system in hwdom_shutdown() called from domain_shutdown
> >>> - Ensures all secondary VCPUs of the calling domain are offline befor=
e
> >>>    allowing suspend due to PSCI spec
> >>> - Treats suspend as a "standby" operation: the domain is shut down wi=
th
> >>>    SHUTDOWN_suspend, and resumes execution at the instruction followi=
ng
> >>>    the call
> >>
> >> Looking at the specification, I am still not convinced you can impleme=
nt
> >> PSCI SUSPEND as a NOP. For instance, in the section "5.1.19
> >> SYSTEM_SUSPEND", the wording implies the call cannot return when it is
> >> successul.
> >>
> >> I understand that 5.20.2 ("Caller reponsabilities" for SYSTEM_SUSPEND)
> >> suggests the caller should apply all the rules from 5.4 ("Caller
> >> responsabilties" for CPU_SUSPEND), but it is also mentioned that
> >> SYSTEM_SUSPEND behave as the deepest power down state.
> >>
> >> So I don't think standby is an option. I would like an opinion from th=
e
> >> other maintainers.
> >
> > Sure, let's discuss this with the others.
> My understanding of the spec is that SYSTEM_SUSPEND is equivalent to CPU_=
SUSPEND
> *for the deepest possible powerdown* state. CPU_SUSPEND can be implemente=
d as
> standby or powerdown, but the SYSTEM_SUSPEND only mentions powerdown stat=
e
> (which is the true deepest state). Therefore I don't think standby could =
apply
> to SYSTEM_SUSPEND and we could simply ignore the entry point address pass=
ed by OS.

Thank you for your feedback.

I agree with your and Julien's suggestions.
I will revert the behavior to the previous implementation, as proposed.

Best regards,
Mykola

>
> ~Michal
>
> >
> >>
> >>> +static int32_t do_psci_1_0_system_suspend(register_t epoint, registe=
r_t cid)
> >>  > +{> +    struct vcpu *v;
> >>> +    struct domain *d =3D current->domain;
> >>> +
> >>> +    /* Drop this check once SYSTEM_SUSPEND is supported in hardware =
domain */
> >>> +    if ( is_hardware_domain(d) )
> >>> +        return PSCI_NOT_SUPPORTED;
> >>> +
> >>> +    /* Ensure that all CPUs other than the calling one are offline *=
/
> >>> +    for_each_vcpu ( d, v )
> >>> +    {
> >>> +        if ( v !=3D current && is_vcpu_online(v) )
> >>
> >> I think this is racy because you can still turn on a vCPU afterwards
> >> from a vCPU you haven't checked.
> >>
> >
> > I'll think about how to protect against such cases.
> > Thank you for pointing that out.
> >
> >> Did you add this check just to follow the specification, or is there a=
ny
> >> other problem in Xen?
> >
> > Yes, it's just to comply with the specification =E2=80=94 at least,
> > I've never seen PSCI_DENIED triggered because of this check.
> > It's a leftover from a previous patch series.
> >
> >>
> >>> +            return PSCI_DENIED;
> >>  > +    }> +
> >>> +    /*
> >>> +     * System suspend requests are treated as performing standby
> >>> +     * as this simplifies Xen implementation.
> >>> +     *
> >>> +     * Arm Power State Coordination Interface (DEN0022F.b)
> >>
> >> This comment is a bit too verbose. There is no need to copy/paste the
> >> specification. You can just write a couple of sentence with link to th=
e
> >> specification.
> >
> > Got it, I'll revise the comment accordingly.
> >
> >>
> >> Cheers,
> >>
> >> --
> >> Julien Grall
> >>
> >
> > Best regards,
> > Mykola
>


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 07:33:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 07:33:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023209.1399144 (Exim 4.92)
	(envelope-from )
	id 1uTy9d-0005fs-KS; Tue, 24 Jun 2025 07:33:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023209.1399144; Tue, 24 Jun 2025 07:33:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTy9d-0005fl-He; Tue, 24 Jun 2025 07:33:17 +0000
Received: by outflank-mailman (input) for mailman id 1023209;
 Tue, 24 Jun 2025 07:33: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 1uTy9c-0004u1-Ey
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 07:33:16 +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 7d1eb873-50cd-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 09:33:14 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a57c8e247cso3989704f8f.1
 for ; Tue, 24 Jun 2025 00:33:14 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d86e8fddsm100210615ad.210.2025.06.24.00.33.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 00:33:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7d1eb873-50cd-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750750394; x=1751355194; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=K0TGZ6rbmQMWuCm67eAqErb6H0rHOvPUz009tcPefSY=;
        b=dFUWQSyOj0m6E4+S5hWjBm14JQGaPWSAPCB6SEyM0XuKF0C5CKuT0zPk0G7UTIZ5b4
         exogsa4iygODHnUKTZBNY5yb48yjD6ToCb1Rn9oT2u2QqDtzzsE/25Ouh2oUkbejPZBA
         d1g8W4kvqo2vzNqZJVPz0hV4+ySt2zOu92v3X+3YouSEBGU2QDFC9q4jRCucfGUm4O2x
         4nq6M6eKR00j/g36bfC0kiSdcaQYp76daEXpvdiTrxeh6dt15wRbE5YAJfFSAX9cyA7k
         QR5/PlGOOmo/zjHD2BhV/7hNHQZJWbEimWec+kA5OH+n7NRU4mte+Vk8Jjz2OwOeD7lK
         FGDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750750394; x=1751355194;
        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=K0TGZ6rbmQMWuCm67eAqErb6H0rHOvPUz009tcPefSY=;
        b=B8x/UyMc3+SdV3bpMyE7SBqLF1CHdkru0x4k+99ka1o1dUc5y0fUUP79hyzaR9tA0B
         m7eKgC1KUSyIksGN5FkFeKVFWBapljPE5D5MOoFl0jbyQQQ/7EzzIrf2RQ8siAxGceyy
         LFShWhLCUxmfR69oVtqQLSM0ZGVoZFRC+NFW7gcdt0+FeWN8q7fNu4m4HAOvQO+9PcxT
         l0LENs9Lf0FNbCjCnA1ClTv0HfideUB56gFaYWiXi/PiuwYozUIL/JGqQJq2wUK9o8Op
         7pzU3U3sqLPTcODWd/pVI8u8D91oPWBmf5LJaDR+FmzGAtwRseyKNNDHthO+hq/yYEz5
         iuKA==
X-Forwarded-Encrypted: i=1; AJvYcCWQZVyI89JK7NmpWiC39moq9nI4m+qrWNYkKit7jM0LDI65fz6r9CLV4EpE7HHDOqaWaMFAd4NsZuY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwY7N6Y4ZXC0cgn2yzu5q4HchvdREZcVqbOTQ476GJa1XJFNCkv
	NKcYbHjY4DZFyyXfKCh/RRZQtRDn2Rp2v9aZlBicy0qTJ9GXid6ZkUGlrNMDzOz2sQ==
X-Gm-Gg: ASbGncs/a3mCgfvYsCeIeeHmS3LKTzHaYl6mwMh+It9Jwfqmmw94u88ekq+91AcR6Fv
	vU17gbL59E8Xc4wAhs+StxQPS6JZBexJb2XVjji7P0jCPDD/Zk/cZrn5+TYSMOQUu8zMFNxx+KQ
	7IY8HhhDuvesvu1YyoZzoyFTf3D4Hqg2ln8Jfd9VUfauVoO3A76TU3BHzdslXt4A35NgwL5g/0Y
	D7z4a/qhhWY5CGKsFUJxfIBWrgEUJfBqwuf5TjMZrUfU5783nXyQec+z/t4gpEC+n2y7rkKWHY9
	naLvl0NdMkIbuIsKKVSis9g8rCCMyqJSrjw7xjSkNfbTYB6cVx3MTo3Hku3Ili0KyLnoRyIvGfH
	3JUocN9v0eJqX8l5B2T0GKxL7JD0ESQ2xGtvSy2bMehhXqsQ=
X-Google-Smtp-Source: AGHT+IGe9ZnhqBEM/BgvR7Hz+Dof3t/CKhKOaBsoD1TVykpNTVuMuWW7bhSuoSBGa65+dYngPFBRRQ==
X-Received: by 2002:a05:6000:178f:b0:3a4:f038:af76 with SMTP id ffacd0b85a97d-3a6d1331ef9mr13547349f8f.53.1750750394130;
        Tue, 24 Jun 2025 00:33:14 -0700 (PDT)
Message-ID: <3da8604c-797c-4ad2-b059-4bf9c5bfb86a@suse.com>
Date: Tue, 24 Jun 2025 09:33:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 13/16] drivers/vuart: move PL011 emulator code
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, oleksii.kurochko@gmail.com, roger.pau@citrix.com,
 sstabellini@kernel.org, dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250624035443.344099-1-dmukhin@ford.com>
 <20250624035443.344099-14-dmukhin@ford.com>
 <6b2938a2-aa42-421f-b948-44e74f463b21@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 24.06.2025 09:31, dmkhn@proton.me wrote:
> On Tue, Jun 24, 2025 at 07:50:33AM +0200, Jan Beulich wrote:
>> On 24.06.2025 05:56, dmkhn@proton.me wrote:
>>> From: Denis Mukhin 
>>>
>>> Move PL011 emulator to the new location for UART emulators.
>>>
>>> No functional change intended.
>>>
>>> Signed-off-by: Denis Mukhin 
>>> ---
>>>  xen/arch/arm/Kconfig                               |  7 -------
>>>  xen/arch/arm/Makefile                              |  1 -
>>>  xen/drivers/Kconfig                                |  2 ++
>>>  xen/drivers/Makefile                               |  1 +
>>>  xen/drivers/vuart/Kconfig                          | 14 ++++++++++++++
>>>  xen/drivers/vuart/Makefile                         |  1 +
>>>  .../arm/vpl011.c => drivers/vuart/vuart-pl011.c}   |  0
>>>  7 files changed, 18 insertions(+), 8 deletions(-)
>>>  create mode 100644 xen/drivers/vuart/Kconfig
>>>  create mode 100644 xen/drivers/vuart/Makefile
>>>  rename xen/{arch/arm/vpl011.c => drivers/vuart/vuart-pl011.c} (100%)
>>
>> I question the placement under drivers/. To me, driver != emulator. I
>> wonder what others think. But yes, we already have drivers/vpci/. That
>> may want moving then ...
> 
> re: driver != emulator: I agree; but I followed drivers/vpci.
> 
> Do you think common/vuart would be a better location?

Or maybe common/emul/... This wants discussing, I think.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 07:36:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 07:36:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023220.1399155 (Exim 4.92)
	(envelope-from )
	id 1uTyCv-0006TS-7V; Tue, 24 Jun 2025 07:36:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023220.1399155; Tue, 24 Jun 2025 07:36: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 1uTyCv-0006TL-3c; Tue, 24 Jun 2025 07:36:41 +0000
Received: by outflank-mailman (input) for mailman id 1023220;
 Tue, 24 Jun 2025 07:36: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 1uTyCt-0006TF-Dz
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 07:36:39 +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 f637fd7d-50cd-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 09:36:38 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3a54700a463so2767560f8f.1
 for ; Tue, 24 Jun 2025 00:36:37 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d8393893sm101103145ad.25.2025.06.24.00.36.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 00:36:36 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f637fd7d-50cd-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750750597; x=1751355397; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=+oLrS76N/rLzGBRT5rjucNrPKVoSPDGVorHHeCAe2c8=;
        b=JKTTngQeYXqik/G5PvyvNnupRm2piePfsM9lgT12uBlKxDhHCPkqiQqHV2ya0LrLCq
         y80m8M5JcpMvkAJArWjvtCeri3K2dyqw+QESksTiTvfaTEiZQB8JG5f5smpOY+v0q6Ow
         Fb9mva/Bgv5wrcLtP67Q+jk8q5iIjwpT94ZLgzQ5EKRwg08y7Eusp0iPbR+j4nZiimgM
         TevGv1UfLeHi9EBo7ye/Y+S1zY94dSfRjW2+FOyBF2VeiSU/iS7FMACjoA75Lwo3dyOY
         tb3A+o7LPECv7NxcK1rQ5IGvEnN+vxJCCKw5kc/RPk2rmd6QsS4Vj0Zmgq6AmcFOsUIg
         IOug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750750597; x=1751355397;
        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=+oLrS76N/rLzGBRT5rjucNrPKVoSPDGVorHHeCAe2c8=;
        b=e7RRG93VTOJuFTbaEguvv7RByn2aLbHX3xgceuizeHZ4w1F8OE4bXhE1qTNChRi6eP
         yFk44luhYtyZY0Xy4CeKY1a/thv4RcNtRPgIO2K4yDClpVFZlugGgX/L2/G8gCTZx71E
         pBjERFyAkgkg4RDGTgYgJNrGZYFrnv1C/53hM6ROQp+3Fnx3Zto7FltlenXL5mFy+7vh
         bvKMteti2VOp0v8UfN9ee+solpZIEuOje0w2PaCYVtm70Pj/AX4nMN72xIF+RjMZjGhx
         Al2C788hb0eddMm8UzxyiJw4LR+Znmu+/xpiWhDXyw57WOzTAiTA+JA8W6wUGFrl7H5G
         xDwg==
X-Forwarded-Encrypted: i=1; AJvYcCU9vWK2VrLgyW3xNtuePATqigo9sjyQjGhoGOn5Y1N5dY0Sme/Ap3Seax5sEhkPPuen77l0QL/kscI=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw+smrcnTACuKD5ywXcdMUfHsrA04BxQL7azu7KzEpRsGyH5NsG
	lW5yGUkcdjKlgYh1RSJFnckk2ifzB/5tjM3UrPX/16v9NxeAVwQgpFmez3/NjuGfvg==
X-Gm-Gg: ASbGncsb3qH9Bn561jzzbMWT6l5VX5tTvaZQKKBK2cCkXIqp9Kg0/lp1lC3MGwRXgOJ
	Kbk/RX3wvltiDR2NBOot4T5l+neFzE5EnXj/WpHbEE33OlqByh3jcIxIrbZTdEwB8VNyxK5tHr6
	9O4viXuc70pVn7u8poVu7RKh9KkpnCT4ERo7TAL1Mj4mrSXCyigc7ZrkL6vFz5JRiCwU0Z3FtRv
	PIAc0UfZbhW7AilH4YX8mo9mI/szMpgPmZNzbsmp7tRr2TyTpjYywtBy5/28+zTagOOHudp8vsJ
	BnTpnTJJELBp4nUES9kodTk/ffCwTdgSWacDKtUTQ+TYInUz+dt113qoR0pdsCLdoB/Cism5PNe
	YjOKXxmHqFsILgUpbRO6uGU9BVwqaBZ8lTGgz8D1FKU4hlSk=
X-Google-Smtp-Source: AGHT+IH1lxQsxdWbBaFevM5FC72LxMjZoNZ1AZLIuurP2atKUQsA8Uus3IxxXv36Xf2xbujmVp8Tng==
X-Received: by 2002:a05:6000:18a5:b0:3a5:1360:6b34 with SMTP id ffacd0b85a97d-3a6e71b8a59mr1752959f8f.2.1750750597354;
        Tue, 24 Jun 2025 00:36:37 -0700 (PDT)
Message-ID: 
Date: Tue, 24 Jun 2025 09:36:29 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 1/8] vpci/header: Emulate extended capability list for
 dom0
To: "Chen, Jiqian" ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: "Huang, Ray" ,
 "xen-devel@lists.xenproject.org" 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-2-Jiqian.Chen@amd.com>
 <669877f5-ef34-4552-9cfc-e097d40d444a@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 24.06.2025 09:01, Chen, Jiqian wrote:
> On 2025/6/20 14:29, Jan Beulich wrote:
>> On 19.06.2025 04:29, Chen, Jiqian wrote:
>>> On 2025/6/18 21:52, Jan Beulich wrote:
>>>> On 12.06.2025 11:29, Jiqian Chen wrote:
>>>>> --- a/xen/drivers/vpci/header.c
>>>>> +++ b/xen/drivers/vpci/header.c
>>>>> @@ -836,6 +836,42 @@ static int vpci_init_capability_list(struct pci_dev *pdev)
>>>>>                                    PCI_STATUS_RSVDZ_MASK);
>>>>>  }
>>>>>  
>>>>> +static int vpci_init_ext_capability_list(struct pci_dev *pdev)
>>>>> +{
>>>>> +    unsigned int pos = PCI_CFG_SPACE_SIZE;
>>>>> +
>>>>> +    if ( !is_hardware_domain(pdev->domain) )
>>>>> +        /* Extended capabilities read as zero, write ignore for guest */
>>>>
>>>> s/guest/DomU/ ?
>>> Will do.
>>>
>>>>
>>>>> +        return vpci_add_register(pdev->vpci, vpci_read_val, NULL,
>>>>> +                                 pos, 4, (void *)0);
>>>>> +
>>>>> +    while ( pos >= PCI_CFG_SPACE_SIZE )
>>>>> +    {
>>>>> +        uint32_t header = pci_conf_read32(pdev->sbdf, pos);
>>>>> +        int rc;
>>>>> +
>>>>> +        if ( !header )
>>>>> +            return 0;
>>>>
>>>> Is this a valid check to make for anything other than the first read? And even
>>>> if valid for the first one, shouldn't that also go through ...
>>>>
>>>>> +        rc = vpci_add_register(pdev->vpci, vpci_read_val, vpci_hw_write32,
>>>>> +                               pos, 4, (void *)(uintptr_t)header);
>>>>
>>>> ... here?
>>> If header of first is zero. There is no need to add a register I think, since the dom0 can read/write directly.
>>
>> Well, my remark of course did go along with that further down. Plus I wonder
>> why the entire field being zero is special, but the field holding, say,
>> 0x00010000 isn't. Yes, the spec calls out zeroes in all fields specially,
>> yet at the same time it does say nothing about certain other special values.
> If want to cover these special values.
> Should I need to change the check from "!header" to "! PCI_EXT_CAP_ID(header)" ?

As indicated - my take is that the check may best be dropped. Roger?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 07:36:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 07:36:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023221.1399165 (Exim 4.92)
	(envelope-from )
	id 1uTyD9-0006l8-E3; Tue, 24 Jun 2025 07:36:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023221.1399165; Tue, 24 Jun 2025 07:36:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTyD9-0006l1-A3; Tue, 24 Jun 2025 07:36:55 +0000
Received: by outflank-mailman (input) for mailman id 1023221;
 Tue, 24 Jun 2025 07:36: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 1uTyD7-0006TF-7F
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 07:36:54 +0000
Received: from mail-24418.protonmail.ch (mail-24418.protonmail.ch
 [109.224.244.18]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fe729d3c-50cd-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 09:36:52 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fe729d3c-50cd-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1750750611; x=1751009811;
	bh=42siax0kogyrned8KRupFi9IYG+ihop/uG0YVs9QMik=;
	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;
	b=PbU7jM4k/BRHywwJLwDQz3VMvTaqDwZT512bmPi7fvx4zWwIFqy2YOeJ22ROnzmYF
	 /pQsrXsY4CPpWeR7NmkYMAlH45NYm9CSDjZpg6aNHZ8RMM+z9I2cXSg8wzlDJU0Ekw
	 D0xmRSKbWrY+5a6BoQojc7m45WJ3KkNmCZ3osWL3XGoKM1zP0iLRfUBe+efvhGPpmU
	 gIm8fuqv3+oq8QfPnPJsRLD9e0UsnUhTy+l6jvUHt553o7erzveQI/rg3IEt4GaNX9
	 66cXLV5efywR4354jEZM/Ko4tG6kIqusq6O0bCunmIw/WEf0La2sFalne6JD2ypQUG
	 5hfKmcRQmBUNA==
Date: Tue, 24 Jun 2025 07:36:47 +0000
To: Jan Beulich 
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com, oleksii.kurochko@gmail.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v1 14/16] drivers/vuart: move simple MMIO-based UART emulator
Message-ID: 
In-Reply-To: <6e6c8664-2ff6-484d-bd47-7ee12c449f9e@suse.com>
References: <20250624035443.344099-1-dmukhin@ford.com> <20250624035443.344099-15-dmukhin@ford.com> <6e6c8664-2ff6-484d-bd47-7ee12c449f9e@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 6f04fe74cf678d739b6fe28d14061cfbb820540f
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 24, 2025 at 07:53:04AM +0200, Jan Beulich wrote:
> On 24.06.2025 05:57, dmkhn@proton.me wrote:
> > --- a/xen/drivers/vuart/Kconfig
> > +++ b/xen/drivers/vuart/Kconfig
> > @@ -3,6 +3,15 @@ config HAS_VUART
> >
> >  if (ARM_32 || ARM_64)
> >
> > +config HAS_VUART_MMIO
> > +=09bool "Simple MMIO-based emulated UART support"
>=20
> Perhaps in a separate change this should be renamed. HAS_* should never
> have prompts.

Oh, so HAS_ flags are non-interactive selectors by design?
I did not find explanation in the docs :-/

Can you please explain?
(and I will add a note to docs for that)

>=20
> > +=09default y
> > +=09select HAS_VUART
>=20
> This is questionable too (for still being controlled by a prompt), but
> may need to remain as is.
>=20
> Jan



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 07:40:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 07:40:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023235.1399174 (Exim 4.92)
	(envelope-from )
	id 1uTyGO-0008To-Q8; Tue, 24 Jun 2025 07:40:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023235.1399174; Tue, 24 Jun 2025 07:40:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTyGO-0008Th-N0; Tue, 24 Jun 2025 07:40:16 +0000
Received: by outflank-mailman (input) for mailman id 1023235;
 Tue, 24 Jun 2025 07:40: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 1uTyGN-0008TY-40
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 07:40:15 +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 769423d6-50ce-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 09:40:13 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3a536ecbf6fso52384f8f.2
 for ; Tue, 24 Jun 2025 00:40:13 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d83932dfsm101967595ad.30.2025.06.24.00.40.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 00:40:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 769423d6-50ce-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750750813; x=1751355613; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=6OPQKA5Xu12cwY7Ki0OpcHSJzl+QeCS7t+q18ea7k6E=;
        b=QBo+oRdacFG73HtGNumb7i0e+YVUNkXbZtclAJjVxvWy/03D+kX5+5CVvd7xYerbdj
         sCxAFIF+ie1N4ASfvteswzNrzHUdXYjVHEY2olhMKQsso2bbHjLRT7MrPC2Crnk6yA5G
         Ngq+Vg+DbtTmysOqmnKU6qlQckoud8FGes0kW+KLkWsEEZJvTxy8R28Q/R01xY4F5y3/
         u3z6hYqs/kdYzxBpyHzLxBFHSMMLMkXGZOsqE9F/dljJhK5CgiQcZN/AamIfbaGRf1XF
         4LQgZo2/GQ9w0iNGpihZOhWcWs2YJQ/0dWyCTyRzMosAxRR3uaMHqFzydQj/qXvOluaN
         rBfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750750813; x=1751355613;
        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=6OPQKA5Xu12cwY7Ki0OpcHSJzl+QeCS7t+q18ea7k6E=;
        b=bUZIOuixBVyj4Orl2HE5cNJl/WnoAyiuUJ6MCU8P4hhkbnmbORHvE+rzTvw+LQwX0p
         DlK0dpUT3x/cQxJcUG/7U2rseJSR8472UrplAyiNi5YGgHw35Ap1RwD+Vz/9NnF22rVZ
         Xpbs4F5vIsSiTO+oFPugHSXjfQS37QyFxnbqMNesqmHEtsLU/eYQqKHvQAn9K45N3Aov
         0x2DT73V1YcTBN/O4/91gI6kPRVuQG0i5OaJrHYvMlJMy6eB4T5jobWguKzrXZxrbIWX
         CD0NCZXn6kYSgD0aMN1ozVk8u+n/dUZrV0uSP1l6t6fn2oXoOCTY1PZakWsc2pnWdbgX
         cLIA==
X-Forwarded-Encrypted: i=1; AJvYcCUNDnOgZcnUuc8SAVTskLUDfI+j+R4lSrZZUmhZBbeZjQo6yfoQzfH5XoxoL7ZzNINLiPK8J4edOuA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzo0kJSJhsdXhNhclrD1OLJvtErxLtlph7IQhDxX5bgL4XuPs4y
	Ij8+qCWSsrHgLzdcfSIn4psqk+YHH52bV8BiKCort75Ww2TqXYK1UW91nbZjEy/Hig==
X-Gm-Gg: ASbGncsFi17T3Fc83q98YWrL1E287Z1eTBqvGf6+O1BQUe4u8qHejPDhJ9PuwJ/1ib5
	z+g1/F7HCLt6aqxe55XIi06lKEzdDXBeDqx7VxIEM5gNW+0xzwEnP/btH09ZJQjQUqR+wBLWBlZ
	LtF6f73Mb21W8FLJHZuFImgvkjELn0CBAbh8U7/eBAfTqZRLo0N4NA1wKVhwqdo4I1N8UjpPeaL
	eMOwZerdRd06+8dsA08CRgJe04hKDb3kY2UDifcggCCliZaVypBvSriPJk2fLKss4/YyGPEN4/D
	dcF0UowUJ4RG5YQN2cKTwOO94bttjhBfmHSFTHthdmTs8pTHuLms5PsYphMUlxphDvHXkeTHzfs
	itQOhZPuDXg7wH/MJhLfwlsM9vksSaLLtnxjmFonKT0yIZTg=
X-Google-Smtp-Source: AGHT+IGBxywPIoDQlQDJssHQGBM0dEMRicayIkELANOuY57UmzARgUPyn5rg2EYi+M6tMnIxBFmytA==
X-Received: by 2002:a05:6000:2913:b0:3a4:c2e4:11b with SMTP id ffacd0b85a97d-3a6d1330159mr11183025f8f.51.1750750812625;
        Tue, 24 Jun 2025 00:40:12 -0700 (PDT)
Message-ID: <6d33355c-477f-4ef3-8f17-b7f1dd1164ce@suse.com>
Date: Tue, 24 Jun 2025 09:40:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 14/16] drivers/vuart: move simple MMIO-based UART
 emulator
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, oleksii.kurochko@gmail.com, roger.pau@citrix.com,
 sstabellini@kernel.org, dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250624035443.344099-1-dmukhin@ford.com>
 <20250624035443.344099-15-dmukhin@ford.com>
 <6e6c8664-2ff6-484d-bd47-7ee12c449f9e@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 24.06.2025 09:36, dmkhn@proton.me wrote:
> On Tue, Jun 24, 2025 at 07:53:04AM +0200, Jan Beulich wrote:
>> On 24.06.2025 05:57, dmkhn@proton.me wrote:
>>> --- a/xen/drivers/vuart/Kconfig
>>> +++ b/xen/drivers/vuart/Kconfig
>>> @@ -3,6 +3,15 @@ config HAS_VUART
>>>
>>>  if (ARM_32 || ARM_64)
>>>
>>> +config HAS_VUART_MMIO
>>> +	bool "Simple MMIO-based emulated UART support"
>>
>> Perhaps in a separate change this should be renamed. HAS_* should never
>> have prompts.
> 
> Oh, so HAS_ flags are non-interactive selectors by design?

Well "has" simply by the word means "this is available". Any user-selectable item
deriving from the mere availability would then have a "depends on HAS_...", thus
hiding the option in situation where the functionality isn't available (be it per
arch or for other reasons).

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 07:49:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 07:49:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023243.1399194 (Exim 4.92)
	(envelope-from )
	id 1uTyPe-0001ur-RV; Tue, 24 Jun 2025 07:49:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023243.1399194; Tue, 24 Jun 2025 07: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 1uTyPe-0001ui-Oa; Tue, 24 Jun 2025 07:49:50 +0000
Received: by outflank-mailman (input) for mailman id 1023243;
 Tue, 24 Jun 2025 07: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 1uTyPd-0001tj-9q
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 07:49:49 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on2061d.outbound.protection.outlook.com
 [2a01:111:f403:2418::61d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cbf01ea5-50cf-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 09:49:46 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by IA1PR12MB8466.namprd12.prod.outlook.com (2603:10b6:208:44b::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.20; Tue, 24 Jun
 2025 07:49:43 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8857.026; Tue, 24 Jun 2025
 07:49: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: cbf01ea5-50cf-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=rG4S/EDgGCfuBZ+FwlrD5h3POKzMh0gMCUzbK9kVg9LhksrphGbk1otve+CQPsiCstuSQxwZLAaRz1hRpWUTSkMpXQvedAnV//qX1YPMn/0jKHj7LG7vENK46M3s4SRFjEaRloWuuXE/8+c1xUafDeDufEyZUZcpJISlQItNHr3W9NmdH+3T3rWeLjyUHLX8bZtBsK2UINRwVQTKbsWc5HeJqWpG22ZhYb1bT6b7Hbmw3QfFbNMJ5/594BzPbmIp9NmQXB5bK5B0ZhVQTVeVe/V4MwXeRbyuhPwTrTseQUR5d/MUt6wwN7G0TxkfzSt3JuYfhRULYqQvS9iEnCDasA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=lwjy3pO/5OXHLkxHZG23RgXHbFJDgzCqWHi6p1bVC0M=;
 b=yUNJ80RtlyhV5AAyzHMZ86rrM0On/vJ4kxf2wiUVRXJxvGZ+TIdqf1JfHvuSVDhJmArV+l/JHeCo9mt9sWuf65Fq84CGHQY+NE36vrv3OKaD2vS8y471weqZ2xQuAQxADuAkLRDjb0kkQJGCAYvma9JZcFlNDmJ3A9feWcHAc5xxPGmKPNou7NuFyHJpQLWnvxgSOU2X25KjpEd80n/f17eMJOLN1X2cPDjkOwYSCHJUell89X8FSjU5eeRktEVA1OsRXQsMMesvl/mpgnqbZk0izAlOtFykZFMp+QRooc6uDHLQ+rbsjD/LRgR0UtC+oPy8rLqIkVzo/fUMuJ7uCQ==
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=lwjy3pO/5OXHLkxHZG23RgXHbFJDgzCqWHi6p1bVC0M=;
 b=UqDzzfmhwmbF4H4Ey/sbRNDjldq+YECktP7U3bFeEeB1NvqxJdBwKOUVMuoBa6CNC0skUNlTZ8pXJw9awcxz5ydGAs0ovqzxX8lk4yiQThpPAJhPTNEDYm5Kc4tDy3ewJHK7sy9vT4nZr0CIRazSbXim+WzPO+6v+TjsJAlBSG4=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Tue, 24 Jun 2025 09:49:39 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 02/16] arm/vpl011: move DT node parsing to PL011
 emulator code
To: dmkhn@proton.me, xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com,
 julien@xen.org, oleksii.kurochko@gmail.com, roger.pau@citrix.com,
 sstabellini@kernel.org, dmukhin@ford.com
References: <20250624035443.344099-1-dmukhin@ford.com>
 <20250624035443.344099-3-dmukhin@ford.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250624035443.344099-3-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR2P281CA0036.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:14::23) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|IA1PR12MB8466:EE_
X-MS-Office365-Filtering-Correlation-Id: c793df30-e899-4fad-369f-08ddb2f3aea7
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|366016|7416014|376014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?OUE1aENoNlVCeXl1SUd3MGlSY291R2YwL2FUc05QeU5aUklHNWxPOG9NZmEx?=
 =?utf-8?B?dEtHZDRtdVF6YSs3OUFOL0tCYmkzTmRRcGRnanNsRkN3UklUZURJdWZIMHE1?=
 =?utf-8?B?NmhVTm9TbFpUSVo4Z0lLSms0Zm5DZ25mQi90dUxEWC85aGNENGwvVUFjOGdH?=
 =?utf-8?B?RmNhN216Vi90UEsyWktBbGpRd0ZGTDQ2S2lpazhSc3daclRCT01JOG4rZXRF?=
 =?utf-8?B?cGpjNVBjWjhDQjRCd2UrbmwzZkI2YVhGYlh6NWMzUGs4NC9HdC80bnF4M3o1?=
 =?utf-8?B?dGo1UndySmlicUUwNmZLL1llRVJzT2VnL1VxOTRhb3dYV3lGek1ab2NUd3Fl?=
 =?utf-8?B?RWRBOXJKOFhRTFlNQ1RQUFZYQ0VoR2psbFNFQ2NSZWRvRkRwRVNMZDQwT1Bv?=
 =?utf-8?B?TGxSdEFXajBxdlNlYXBpY0p5Zk91WjhIYS95TW1qL3ZKZ1pMSFAwRDBiVkhT?=
 =?utf-8?B?cXpENE5PQXNmakh1TUZ5MW1tWHFZbVdhbjg2MGJOWVJvS3BMcW9iaXJLZmVm?=
 =?utf-8?B?b3p1TWI4aElZT05RbkJDT0NWR0xRc29DTmlDazhHNnphWWxQU0Y0dFF0ZGR2?=
 =?utf-8?B?UGdOUEc4b3Q1TVdGS3loMW93aGZCdEU0OVYzaklqOW9oZnFHY3dZVC9ydi8r?=
 =?utf-8?B?WjVJQThJMi9LVVpxcWZlOXJ2bGpMb21zb2dtN0VLeGRvR2pwVDBrWnJHVWpS?=
 =?utf-8?B?aTlBSHRHSkdaWDYxZ2hxOHFsa28rTzBuSVhmN2g1QjFITTdIMjl3TFl2U3B6?=
 =?utf-8?B?ZXFQSm9obDlxZjlPazFhUnNrWGc1VnZzOU43RUpSSG04M1VaSGgrR0piYlBx?=
 =?utf-8?B?ZU5KR3p6R2U2cHZKR3A5anQ3eEFJMlgyVUE3VGV6U3VSUzN2T1UvWUJxZVlx?=
 =?utf-8?B?bStXaG5MclJnQkxjV0t1VG5wbm5UcUUyai9QMmFnYnBDR1g5OFhuc0JMRVNo?=
 =?utf-8?B?bW5DVlJYUmphN1NKZFVQSWFHa28yb3gyamVXQnFpZ1l4NXV0Nko1V2ZnTWJy?=
 =?utf-8?B?OGNYOThEWENyeGtxTHZucFFhRFBNNUg3dWhoaE8yU3RvWmxCODJGbG5pOStX?=
 =?utf-8?B?dEdCL0FhQU5ZNE1hdjdNTDhiRGQzelpwRDQwbXBsWWYrK3ZpeFhsb2dFWVFR?=
 =?utf-8?B?djhzQkUzZW5sSTFaQ2dPNWl4Y0piaVZIaGNuOXdDbHBOOWplODFvaGFLeEQw?=
 =?utf-8?B?aVZ0NFZnS01GL3hkUTErdC9FdUE5QTJmMWMzUkhRbnFhem4xWmlvOTF2VlN2?=
 =?utf-8?B?UFUraHdMTEdDTTg0YXRjU1NCTmU3RFI0LzFBWmtmbnVsMzdOWjZPZk51dC9T?=
 =?utf-8?B?bXU3bGo1VWVUZThwSVA0OHVUcHJ0ZGs5d2FBekV3T0k1cDNoS25oSmhveG9l?=
 =?utf-8?B?UmQ3amM4WjdrSHlxaEZhbDREQk5TUi9UbDEwMkRLQ21GZVF0UytwWElUaVBV?=
 =?utf-8?B?YUdUT0JVdFVGaUxFb1FMSWJRUHVPNGNXQlZWVHFPY0g1ZVpHaWtqYTd5K29W?=
 =?utf-8?B?aTFyUjFyNnlibHVyRGhTZUxRWi9CekpSN3p6SjV5K0ZhNlpmWkJKc1lMOE1r?=
 =?utf-8?B?dXljajNWWGY4T1pFWGFBRm9rYmEwY3JXa3NYNG9iL3kzdHZjZGhlWGVQNFJU?=
 =?utf-8?B?ckNvemQ2VGtSZWNVMHFqSXdyVVoyZS9CKzh0REdvelk1SUdZWkhjU2UwZXlo?=
 =?utf-8?B?NG9hOXNoK0FzaDBZOHpyZ2I5elBtK0htL3RsUy9TZGNZditMaEVGMitnbHF0?=
 =?utf-8?B?SEFMN2tvb3FERkRtNjhab0MvdkR0c3RyTFNvZkdrQWhEUVJTVEU4K0ZUTnlq?=
 =?utf-8?B?ZlVXMTVGUUJmY3dhZEJGUWprRGdUdU4ranhNL0xMblpFaXhQZlBYS20xdnBa?=
 =?utf-8?B?dTJNd2tMWW9oZVFQZHJBNnVnMmFkMFNpRDNOTnpkNzl3ai9zT1pNUmQxOVhR?=
 =?utf-8?Q?kbG/lOSQgPY=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(7416014)(376014)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?M3luVTlSR3FBbm1UQThTMWdHZVpPNkJXVU4zdnFBNWpTS3ZtZ3RvTDdEVm9m?=
 =?utf-8?B?M0p3ZlZsd2EzMW1TbUpEVUJ3MUJzKzBVb3FlYTZvb0tEMzhURnA4Qm5lOVJx?=
 =?utf-8?B?aDlZcGFjeXhROGxJZ1RlUWFXZWFndndhTDQ5M2luZUllclVtYk5hU3VtU1A5?=
 =?utf-8?B?amdLZHBoY3NlZnhRNnFLdFhHajJ4TmlPOEhUWEN1d29BSi9kVEZEZ2R2QTVn?=
 =?utf-8?B?MHJMSlBqZTdIMzVOaTQ0bW9CM1kxbWxXTWFWay9meUwydFRuYzNXVlVjREdy?=
 =?utf-8?B?MjdYSU55anZBSkVFUEZ5SEFzYVlNZmU2VFV3SktxMm83MGxjSE5kS2pVNlBr?=
 =?utf-8?B?VjZLY0ZwYlVmcmxSODVacldXZVVXZW1BUVVuSXlwMHFjeVI1ZStwSUFOWldo?=
 =?utf-8?B?akMvbkhpdjBlWDN6ZFlQL0tsbUhFZ3pyNVZZbDIzVS9VUVcrK0I4Njg5dFRl?=
 =?utf-8?B?RWhjb1VQRWtFNk5xaFhjQWZkWkNFeFdwSTJkbzlJT0pzbzFWeXA1ZWFWWTlM?=
 =?utf-8?B?andLdUV5WFdpOGtVckNDdk5kVVI3MGZPVUx3Nm1icy81VmJ5Ulo2MGdKdDhs?=
 =?utf-8?B?UFRqbkVKcklFT2pkUmdvN3lEMVBKcmR4M215MG9FWW5BTGtPeUt2Ujdobkdq?=
 =?utf-8?B?S2pDVTNiVUFQVHNhWDVMTTk1RjNyRVBoK1ZIMDM4YUp2d1dXL243QlFFMkRM?=
 =?utf-8?B?cERQZ2pJMU9hWEkxZ1Y0OXpEQ0hGRXNLTFdQL2R4cE9OYy9BaEZiSVMrSWpN?=
 =?utf-8?B?SE5pOCtuZE9FblpTTFJ2V1VQWTNRdndxWUlkdk8zcDZPZUdod2hwd0xXajd6?=
 =?utf-8?B?QjZ1OHpHdjNaSXZhOFdoZlBlblF5YW1kWVB0Ty9Vd21UampnQTExTEp1R3Ay?=
 =?utf-8?B?UGIvNERzMFlhamxGMGhMRW1naXZFOWYvbzQvL2lwMy93YVpxM1N2OTFZNGhD?=
 =?utf-8?B?V0RKa2VrdDNqQitZOC9MWktQc1FDbUo5M1RBbGt2NzJwV0pTMFVEbXZNVGUx?=
 =?utf-8?B?Rm5kRytYZVliS0diK2RxdUI0WEpuWFFUeUpaeVhNWlpHUGdtKytaamI2K3l4?=
 =?utf-8?B?YXF3Q2JlWlNLVGFCQmVjSFp5WjFvN29BMitIcWMvZjhMYjFjeHFmZVg0Zktv?=
 =?utf-8?B?ZE5XbUJFVitqaHdQNzFUL0wvaUhjYXVxL1pOVVJFcUNibzNYZVdKNEp2dzJV?=
 =?utf-8?B?Sk9IZkhBaVZQR2dtZmxkOVFydm1aUExYOTVTa1NTVmVubU8zeTRZeVRiN1BF?=
 =?utf-8?B?b3NCNHRiR0tHRFl1RG9RMytaNWNUTXkzakRqMUJDMjZYaDJqK2t5OEk1S21w?=
 =?utf-8?B?NG14TGVxcEdVaVRGYitkV1cwL1V4YzZqRXg0VjF6VkRnUEZPdlNUS3BHYTd6?=
 =?utf-8?B?S2VHM2ROdXhYc1F3dklJSXNDNmVYK1NDalZjOXQ1M2R6OGtiaGtPRFpHUjd5?=
 =?utf-8?B?U01nc2M2L1NLMG9uT2J5b1gwREZ5cEJKWkR1RjJCMDN6aWNkbWtMVEpqLzVn?=
 =?utf-8?B?RS9SazJCNHBsemRBM3F0ZU92R1VmdUptWmdFdGxWMzQ3Y1FQdkh5VXhsbzBG?=
 =?utf-8?B?bmFQV01CdGVBNnhkT0dFQmh4SnNyQXpnTDNlc2FIb3VJWU5YTldUMFUvSFY5?=
 =?utf-8?B?VHYrS0lEdHhuSTEvSjRIc3A5QUt6d1MwY240dnlrQ1NQQ0JrV3p1dHFhWEZs?=
 =?utf-8?B?V1JHWHplQkt0eVNGbUtSRzFWenJ6eUE4T0ovM0Z2TmpyaDdpQlRvSmpCOEE1?=
 =?utf-8?B?OVhWNW1Malo1ZHIzUjhiQmZqNlh5Nk1SZ2t4Qi9XeFY5T1RPdGV5WXowMm9S?=
 =?utf-8?B?WFZrSHI3NE9KT2pBTVJSUHo5eWUzbXZYaHJLK3RqT1g0UXYrVVl1VktRNnU3?=
 =?utf-8?B?ZmNUdTJ6TlBQallGWTZtTm80U1QyN0FUL0F0d2k2czZaSk1yK08xMittRENC?=
 =?utf-8?B?dFR3OTNJY1NDbm9LZm9XRmp1WCtCRDZXeVlCeHQxV3F0dGI1SFpZNEdlY3Fy?=
 =?utf-8?B?bHVldXRWOG1ZQ2t2d3BVTTNaWUwzT3VGakZnd2J1Vm5sbVJUMEpkcWtMTXNN?=
 =?utf-8?B?MGJ2MkE5ZHY4T2w5NW80SGMxNEZNQVFiTXh4eitaTEpzWHV1QjRmcHYxZlZr?=
 =?utf-8?Q?Gusg=3D?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c793df30-e899-4fad-369f-08ddb2f3aea7
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jun 2025 07:49:43.4786
 (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: 7G3N08VjqYGoMCouDRywcY/blz3F4bhuYi7Bi8v9d88jQcH3C0h4HpHR5atPWEFu
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB8466



On 24/06/2025 05:55, dmkhn@proton.me wrote:
> From: Denis Mukhin  
> 
> Move vpl011 DT node parsing from common Arm code to PL011 emulator code.
It's not parsing, it's DT node generation.

We usually keep all the DT node generation functions in one place. I'm not sure
if we want to move them to respective drivers (i.e. vpl011 to vpl011.c, gicv3 to
gicv3.c, etc.). Not sure what other maintainers think.

> 
> While doing it pick the generic name vuart_add_fwnode() for DT parser function
What 'fw' stands for? Firmware? This function creates DT node for domU, so it
should better be sth like vuart_add_dt_node().

~Michal



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 07:49:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 07:49:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023242.1399183 (Exim 4.92)
	(envelope-from )
	id 1uTyPV-0001es-L1; Tue, 24 Jun 2025 07:49:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023242.1399183; Tue, 24 Jun 2025 07:49:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTyPV-0001el-Hq; Tue, 24 Jun 2025 07:49:41 +0000
Received: by outflank-mailman (input) for mailman id 1023242;
 Tue, 24 Jun 2025 07:49: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 1uTyPU-0001ec-CX
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 07:49:40 +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 c7e2f062-50cf-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 09:49:39 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a582e09144so3036201f8f.1
 for ; Tue, 24 Jun 2025 00:49:39 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-238072314basm5940225ad.145.2025.06.24.00.49.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 00:49:36 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c7e2f062-50cf-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750751378; x=1751356178; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=L0/IyvqH0WukLHpJxTEWtJaI8PalwrVi7HSsS2Qy+0k=;
        b=NIxNYCkf3tihIVuz+SWk89lgPVpkwxxQh22n+uI8mR2O9REdAyERb04wB+cm6aYspi
         n2oC2q5Z9OzPCFeqh4plJWczIlTkQTCCo9DCjVIDwInA983rbXcjsAbIZYhnkYTkL78Q
         mGcFfOD8ZcVc+Hl61HEnJvUxAO/uBSM7OIM9V1TGqQQd9IWjsJkyUjJp9qnWO1PILOHH
         u/BG3vThoYcewgT56KUacOLnsLjcTXUbVTgCmWfQ1DFZdowqbkctSycJE8XR++ek/nXy
         Zd+hNDmaFcrKY/QMFZy2QULeNP2YGM6g4i9V4fb1Us+4HQJk1dhw5Car1pMoo3+TEZ7Z
         NCkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750751378; x=1751356178;
        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=L0/IyvqH0WukLHpJxTEWtJaI8PalwrVi7HSsS2Qy+0k=;
        b=IqgfGSgTaSP1ZpboAfusL33FAQeIsVrPGZQ3HYH44a5X3yNWs5hDfOnUleUQImbYTK
         6L6AmNwy3mGl9VAEMOqKaSLNdj1LvxGWEpzBe0nP3J3BGWxY+FArHEseNPjNEuoE0gjy
         QdDPVzJKDmWK9Svo/5f3EgH+HsHMLfZF2aOXvAfVJqFpyZv8Bh1DKq/ehSoxUe27+e4N
         WZFyxRxHw3gFiclIzg3DXTfbOu2xnEY5/vUUopgaIp8+oR55aq1y3TrYY1Q+ObEyXw+5
         Nr170CsxztUKqFwtVM8maud4z71qcR4QDCVU0Ri1rGZeKzfjERkMRPeMgG+G5KySgNNR
         0V+A==
X-Forwarded-Encrypted: i=1; AJvYcCXP1b8CcHLChPXt36ygKR+goJd8i47ZtTZnS4qDDrQ+sqT3LSqOerJGuBJBpXb4nnnB9HWB30O++4c=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzbvXX0+q3EFk975sAcoyc3e0fAnh+oZY/eElhWY+L02YGTwEKN
	rrqT5B3NShSWRlOXQppPe7iwkLuxtSGCwB2gkcg7Xoe83hDbGWxi4XwcYzp+s4lRxw==
X-Gm-Gg: ASbGncvWe/tBvXtboHxVLiCyVoAE4vcAFok08cltX9s3hzQO0iBeD197ZiGT4HGp2C+
	+8c6kjzC15hJR99ALQiZ9KqXoo81vDgWxWEbiXi8W48uul0ZH7fG6XT40Zx1on+TudZ3o3SZu49
	EOBTkaNJYz3kKqKr0ynZB4ymQRD6n9mMA30ZDCMJFvvuZqefkyAabsx4f27zVXNhDQgEntVzUgx
	0xbTdOr+oZ9w6KoMNPq6NH08nnHWBdRAJoHywj6Kz8BEcie0g5AJNZ82HMSZjuzFyPyihogNhvd
	LOHM6mGJRsKt6OVNEegifIjnd1RJH5343QEfjUOFN5tSCLoFsQ83oCmWEfVKcSCBR9pqNymZY20
	v1gyz7woYvN/NxzWpaSA0aEp8YCQfkM0gKeSpbRk7bTmlVBI=
X-Google-Smtp-Source: AGHT+IFBrJ40Gi9afffyr6Vp38z9zq7ZLAbLHomhlh1+Clo2Z8wYGeXYKPEvy2GLfrRov+eRR6/d8Q==
X-Received: by 2002:a05:6000:4b0d:b0:3a6:d579:ec21 with SMTP id ffacd0b85a97d-3a6d579eca1mr9926603f8f.12.1750751377336;
        Tue, 24 Jun 2025 00:49:37 -0700 (PDT)
Message-ID: <04837952-8d7a-48e2-9618-6bc40e933d35@suse.com>
Date: Tue, 24 Jun 2025 09:49:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/common: Guard freeze/thaw_domains functions with
 CONFIG_SYSTEM_SUSPEND
To: Mykola Kvach 
Cc: Mykola Kvach ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250624065601.197492-1-xakep.amatop@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: <20250624065601.197492-1-xakep.amatop@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 24.06.2025 08:56, Mykola Kvach wrote:
> From: Mykola Kvach 
> 
> This patch adds CONFIG_SYSTEM_SUSPEND guards around freeze_domains
> and thaw_domains functions.
> 
> This ensures they are only compiled into the hypervisor when the system
> suspend functionality is enabled, aligning their inclusion with their
> specific use case.

This addresses two Misra Rule 2.1 violations.

> Signed-off-by: Mykola Kvach 

With the addition (happy to add while committing)
Reviewed-by: Jan Beulich 

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 07:51:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 07:51:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023258.1399204 (Exim 4.92)
	(envelope-from )
	id 1uTyR0-0004Gx-8c; Tue, 24 Jun 2025 07:51:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023258.1399204; Tue, 24 Jun 2025 07:51: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 1uTyR0-0004Gq-54; Tue, 24 Jun 2025 07:51:14 +0000
Received: by outflank-mailman (input) for mailman id 1023258;
 Tue, 24 Jun 2025 07: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 1uTyQy-0004Dw-M3
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 07:51:12 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20603.outbound.protection.outlook.com
 [2a01:111:f403:2417::603])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f9467407-50cf-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 09:51:03 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by IA1PR12MB8466.namprd12.prod.outlook.com (2603:10b6:208:44b::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.20; Tue, 24 Jun
 2025 07:51:00 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8857.026; Tue, 24 Jun 2025
 07:51: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: f9467407-50cf-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=FS9icDnXNoaOjAFAr6UtYY67iCKnkJiE9O9M7HRDB7sFSY7kSKQ0dqexq0C6qxrh2aZ5Hmh4EX3oIkU9F1vE8lVbRxR5uRV/UxoBpHuTvTbnFV+JmsM8DCoyDFqb4GlaXqS1RwH8haPWj1+D+Ooly9hUlr+IE479ae0XNYQ3poB1Qq3onfDcfl2n3YdP121tC+CerKKEae5oW0mcwHEzmAEE3dAHmKqIaQ2tpiGgoJfmXUVl5Ovw1WEx2BpwU6Ugu4i9cEsogSNkxPzvjZnOh9NE7v88r4tKT6Fo+AOd/AtF3E5LeS30aiBIX6bQeve/yPjciH/jZeztLkxDxNtX1Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=0VWDtRws4wrWqUa64cyzxkSJG3FdUSmAv16KbKWqihU=;
 b=JId3wbYeRGWDbqPTZzEObquXAuIQOCIr2mSyx63RtbDwRV7gQGDBLJ/ugBxxNyGXbntbvjRg4amkjfnJ0PUyVo3Ea5YGcdY4TEgTwzfiN5V/HXaE7YJW6PXgWgM1haVTFGPe2BdrIPiSU5h+T4a0E9mwfkmEiKwC6G7Y+4IEGm4bp6pBfJgnluVwMHqTpN3E35f9Tp0eoG1o7Oopnvx/MGHjYpeEaRPSxT5MLitzWaSeztfIebeAIaObQBjfVTNM8fHRlxcG0z1vuXFgzMMIBMtokwLPAonG73tyaTrHRh6bnE/1rjdTDNDK9IE6JtITekrp/lbrnhRfmO19vghC7g==
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=0VWDtRws4wrWqUa64cyzxkSJG3FdUSmAv16KbKWqihU=;
 b=GCQf+4+KI1qNcR8j/wqx//znJuPKheXP73Vq/WvmKFDWTER80CyF+y5vv76C4dlAtfmjK3yd/XqRd0MoaCYQyIt1G2nMKji9dnQ+nqNGMXZ01fZ6HfFX11rV3+odtTz9d8arH7O2eOW6U6QP0UUeXgPrJjmAyE2UJZ5EwLAV2Ak=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <0cfc9465-90d5-46db-88a7-ed47d0809b60@amd.com>
Date: Tue, 24 Jun 2025 09:50:54 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 04/16] arm/vpl011: use raw
 spin_lock_{irqrestore,irqsave}
To: Jan Beulich , dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 oleksii.kurochko@gmail.com, roger.pau@citrix.com, sstabellini@kernel.org,
 dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250624035443.344099-1-dmukhin@ford.com>
 <20250624035443.344099-5-dmukhin@ford.com>
 <08cb7878-fad7-47f4-9c91-5f866c54b1df@suse.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <08cb7878-fad7-47f4-9c91-5f866c54b1df@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR4P281CA0113.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:bb::7) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|IA1PR12MB8466:EE_
X-MS-Office365-Filtering-Correlation-Id: 7e23ca54-2b20-4d71-9d8f-08ddb2f3dc3c
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|7416014|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?Y0tudFlrem1GcGY4cy9aT3VoQ2U3QnczN1ZXU3lXeTFibmswYlRwd1dQWnZ6?=
 =?utf-8?B?R2hta2g4aDNNQk8xM3pHa0daYlJKSTJ6bjI5WHNnVzRPZXNrUzVKN3VlWlRz?=
 =?utf-8?B?UyswR3ZSMmx6cmlHcDc3aXIzTnRXdWtwalJnM3pXMHJSYmt1UG84ZVJMZkxC?=
 =?utf-8?B?aWRTNExZenFna25VLzdHWURlN2paRC9TbXE1Um90Zjl3Z0h5c0hjN1JxcXB3?=
 =?utf-8?B?Tkt3eWJJTVE3UW8ySGNiVWdxcDRiSTJ5dlZwNTRweDBwQk9Vc1ljWTBoNWxK?=
 =?utf-8?B?UmtHdFBvb1Z5SUJNdlIveTFLOGs5amg1aGkzdURhN0tOd3pOaFgrV2lwK0VQ?=
 =?utf-8?B?dWQ0Z2hHL1FyVjhwY2YzbGF0NDlXRGxXc1FYdXB3Y0xBNVptaXBxNk1yWlBR?=
 =?utf-8?B?NUFGcXYwYVFnNGo5Y0ZrTDcxRUVtMFQ3LzdJNWJuMExQdy9pZFZUVzZXUU1s?=
 =?utf-8?B?K21WRStTZnl0Z1NUT3ZGWExkdVlsRnhhN3FEUXV3NGtDRjdOakw2cll4K2FD?=
 =?utf-8?B?dXIvT2Z2YVZFREk1RGF5UnNSeVNxcnlzcC85dzBoVUZjUXVrZ2ZPTXJpZTJP?=
 =?utf-8?B?OXdhZlpGSGMrbm9TYmtHUHpMREc1NTd3TVh5Z0JWdXQwZUlqZWR2NXdQei8x?=
 =?utf-8?B?T1RMU3dsOHg0Ykc4aGJWdXpBUWlJV2trRm92ZmNDSWhCWmU4NmUzR3NML2xa?=
 =?utf-8?B?VFNoUlNKU0Z5Rk9NYVRPRjBWRXdSY3A0TU5SV0Iya1JrbFM5TmhFOTJ4Ry9M?=
 =?utf-8?B?Vnlab2tNS1lieTArS1N2SHgyZWRZVXdaSWZ2VnNOTVlXN24zMzgrVlBMcmZT?=
 =?utf-8?B?eDFPYjJSSjV2YXlHUTZnSVhxSXVMcG1LdnBaaXh2cklEZlN1V3NlY1plM2w4?=
 =?utf-8?B?ZmZCelJaZjEzU1EreDNxd0NFNkpLeHM1dUN6Y3RrL3ltcUx0RGxOMmVRRExr?=
 =?utf-8?B?OVU0a0pORnVXVU50TWQrSUl0WlY1SkNGV0VHRWs2ckZrRnFONENMbFJ4aUtx?=
 =?utf-8?B?Sm53cXhZc09EV1NZcngzQmNoQkxLSnVBamF6a3U0cjVmSk1LTXlERVZxcCs1?=
 =?utf-8?B?UmtFSjhnbjF4eWlxNDZKQXY4Qy9NKzltQVFuQ3dpZ2lieTRQVWhFc0FiNFI1?=
 =?utf-8?B?SkVWMUlnUFhrUUNqWGJrQmR5Wi9TZm1zdUZEL0s5ekZLZ3FZdW1QUUJJQlg0?=
 =?utf-8?B?RU11dEVvbzhLN0tGcHdNZHVJNW1WajdEc1habXdYdFZ3bkpWb0JOOUlWYUlZ?=
 =?utf-8?B?aG9EM2pmTlBmZWVkVVdWZGVzME1CUmU2bTRYZ3dJWSswWE9YQUZLclNURDhY?=
 =?utf-8?B?Z3ZVNTcvL3p1cHdIaWJKNnN2QVlnMnNXMmhDVUV4WHdlYWRLR3N6RjlUWEdE?=
 =?utf-8?B?d3p1NHBzdVJXNFJXQWxxLzROdjN4WHdqbzZsNVBqRy84UmwrNTkyVU5oeks4?=
 =?utf-8?B?TWVOdFlKU1RlSlVKaWI2ZVB3bUF4R1NoR3Jld2JjbHl1OGhoamVxMEtid1ZY?=
 =?utf-8?B?KzdXdWpyZ0RIUzczQk9ZQnBWMjVxdC9JNVM5MlRKb0dNQ0FCZVVOSmEyeWtT?=
 =?utf-8?B?SjZ5dVFUQnpEQVZ5RTNaM3R4REp2L0JPZkVHTTdlYmFxR3NhL1Nrdjlra25a?=
 =?utf-8?B?ZE8zemVsMUZBV1haR3pnWlFqeWRXUnJNSTA5bitOSUozL3dmNFRrOUIxdXp6?=
 =?utf-8?B?VkxzdjNkeDJiSHZzYlJlbXN2ckJvTEpsWGh3MEhLcVlTWWNSZi8xaElxOEVK?=
 =?utf-8?B?cHpiTWc3RXdZTHpETE91RGhoRkQ3cjFmeC9NMkRQcFcrVWpVZm81RkN0WW56?=
 =?utf-8?B?OGIrMGMra08wSWVnbWtuOG41UzZoelRsbEs5WHJ0dmMxYnpId2NCZGFwTUVM?=
 =?utf-8?B?RzRaak02L2M4NUgrb09yOXN0aWVRekhYajBIVks0NVFpVXNOTlIvV0pyWEdF?=
 =?utf-8?Q?eE+Cp8CJ4ZY=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(7416014)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?Y2RFYzVCMzdRNThXT0ozK08vdWhSQ0ZpVkpJZTlLaTc2ZGhQdjd2RHNma0E4?=
 =?utf-8?B?bFZZcVlDMmVVTVE3Y2EzRG9zK1Q3UzdkNzhBTnFxR0J3VTNKR0RGSDg5Wjhu?=
 =?utf-8?B?UTMyb2c2ZGpNeURiVXkwcHhWUWppSEpUSVV5cVBHT21zY1Jsd1lMQXBURlcw?=
 =?utf-8?B?TEsvRklTWE0rblNBc01DUU5XZ0RLNW91U0N2UGtFNUx2NmtyblpFbTFrVFls?=
 =?utf-8?B?czFJdTlYMDkwR2lsc1BkWUJyczdWUi91SXVPZXNKRWExZHJzVzhzK0k5Mi95?=
 =?utf-8?B?enVzcHZod25lK25mKzA1czhIdVU4Z2FZbEpjQ3k5N0FNRS9YN1locjYyVWV2?=
 =?utf-8?B?Z2lMWnExWCtJMzVEM2c5eHNIM2RWcjdHRjRGZG5CRTYxeFZWQkFQWmppQ1E4?=
 =?utf-8?B?QjJRMTQ3T0djZ2lMTGRaRzFmMlhNRVBrcmNNLzdMYm9YYndmZlhtM0JYMkhO?=
 =?utf-8?B?UmZLSkZ3YWJLbmpvVklmQXpvNjJGM3dEY1RpOC9YeUpzTElnUFFHYUxiRHZM?=
 =?utf-8?B?S1lxVTEwMGpkZ2R5V3R5a2ZVdGx5bktSVlFpWmRqRG5uajlqd212Zk9DSE5y?=
 =?utf-8?B?R252NGtZWlJTQWtkVWtPSE1VQ1kxbmMyak9FT3hreDlKZEJFR1AzVDZuaG1I?=
 =?utf-8?B?Mnl4Z2NWTXZHUnl2M3kySC9DTFoyZll4dFJpRzErWmZKblI0bGNZZFkxSjNS?=
 =?utf-8?B?VmVKaUEwOElqT2tmMkNZdmF0anZOWENHQnhGR1VEa3lQU0F3Y3BQS0tEUzRK?=
 =?utf-8?B?dlFqVGpvV1B6Vmxzd0xVaW1tR2oxblJPclNPSWY4bjdyUnlkblAxM2p1dGdz?=
 =?utf-8?B?clV4SWZaNWhxekJtWFhPMkZXNXIxV01oMUVHR0lCbXJLcnV3a2ExMnhBWkJX?=
 =?utf-8?B?cmlkUFNHVzZodXlJQ040b1ZpTG1UNW8vU0E5WGJMOUtYZWM5VXAwc0JEVm1t?=
 =?utf-8?B?dzA1Q2pIVnN1d2lROHJETTZmbzFnYnpWbzBuOTFxcW1pWmhWOTJLdDBHYWdG?=
 =?utf-8?B?aCtmT0JpUEJlUXJld1N2Y090YlgxWlJQQldyalpubXM1aVRXNHQ2WGpyeS9R?=
 =?utf-8?B?b1VlU05KSlR1YWVtemlZanJSUmNnaG03cm1ma1JYUyt3QXNwVXo1Q1NjTVQ0?=
 =?utf-8?B?Vy95UnRBdEJGd0dqR2VOdHYvKzYxSFMxSUhucSs4TUZmd3VSQnRGa3EzK0NJ?=
 =?utf-8?B?c0dodUJxYVlZMW9JM0lEMFRoU1R1Yis3cmRzZUVhTmRBNnJyaUhiQ05oZVVC?=
 =?utf-8?B?c2tHV3BoU2sycHByR3Z2RzlXblVLOS9pcmd4MjFSMGV3VTdnSnRCY1gyc2pq?=
 =?utf-8?B?NnBNenB3bFh0MGhQNWx5UU9qbGRaSEhkWHlXRUh2R1NSSzVXbUpnS1RpMlhX?=
 =?utf-8?B?RXV0SXpuWXFtUGtiL0hkdG9GanRSMDlkendXQW5LR0N4VjQwQWhsUHpBV0Mx?=
 =?utf-8?B?QUplckhnR0VQN2llUWMvdHN3UTk0Nmc0MHp6VjJhRGwwUFFEV0M1b3VFeVhQ?=
 =?utf-8?B?dy8rNmxITXkwMEhIVTB3QlN4Ylk3MFd6NjlueVVmM05qekRSOXF2S2g5YmQy?=
 =?utf-8?B?Q0k3WFFjUnhhTXFRMjh3ZHl3dDZKOVE1dzRERkZVeVhCcWxkUkZVNDRZSmpp?=
 =?utf-8?B?WjNJQ1R3V1RETnNHcm5HZmFlU3pteHg5TEhTWmU3SlYvbUxVWGlYSDZNVlNn?=
 =?utf-8?B?MG5aTnBORTBqMzRZT3dwb0RyUUZDcmJXZjZGM0FyYTMxUWpVYWxxcjJlR0xw?=
 =?utf-8?B?WmQ3ZFFvQis3TllhYTdjaWxMRGwwRzI3Z2RvRVNYRGVyRGUyWlUvcXpnbTda?=
 =?utf-8?B?Uy93ZmlsNWFlS3ZmbmZ1UjUwNkFXT1VTaHBNd3JpeVRETjVpUENiRnZCVTdK?=
 =?utf-8?B?UmN5QzhmQ01vNy81Ri9tWjVQOXh5QUNXZFZXWXd3SWFtU0NNdFU1ejJubzU0?=
 =?utf-8?B?QUswcDVCQndlTXdVTzU2L3VwMHl4R0txbFRrNGMvMm0zNFVLVGV3VXdKcksz?=
 =?utf-8?B?WHA3ODhndUpTQkhlWk5TRTZHYlFzQ2VSczFZd2hzS3JST1drVFF6TkVxSEp3?=
 =?utf-8?B?M2JoMWNNRWFkdmJ0RUh4eDZmeGN3cDkyUzlDeUJab3oxS2NrTEdSbSs4NXgr?=
 =?utf-8?Q?RG+OGIW0AqwwcB7CHA2DHu0eK?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7e23ca54-2b20-4d71-9d8f-08ddb2f3dc3c
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jun 2025 07:51:00.0098
 (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: H2VhBfgOub+ddeENFaz9AB++drIdz+G6c+GoLqwi16h88HBn5gbimRA9BomOynyo
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB8466



On 24/06/2025 07:46, Jan Beulich wrote:
> On 24.06.2025 05:55, dmkhn@proton.me wrote:
>> From: Denis Mukhin  
>>
>> Replace VPL011_{LOCK,UNLOCK} macros with raw spinlock calls to improve
>> readability.
> 
> I'm not an Arm maintainer, so I have limited say here, but: How is this
> improving readability? It better utilizes available local variables, yes,
> so this may be a little bit of an optimization, but otherwise to me this
> looks to rather hamper readability.
I agree with Jan here. I don't think it improves readability, therefore I don't
think such change is needed.

~Michal



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 07:53:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 07:53:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023263.1399214 (Exim 4.92)
	(envelope-from )
	id 1uTyTD-00059X-K3; Tue, 24 Jun 2025 07:53:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023263.1399214; Tue, 24 Jun 2025 07: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 1uTyTD-00059Q-H2; Tue, 24 Jun 2025 07:53:31 +0000
Received: by outflank-mailman (input) for mailman id 1023263;
 Tue, 24 Jun 2025 07:53: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 1uTyTC-00059K-GD
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 07:53:30 +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 5134daf7-50d0-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 09:53:29 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a588da60dfso2990242f8f.1
 for ; Tue, 24 Jun 2025 00:53:29 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3158a226f6fsm12742157a91.6.2025.06.24.00.53.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 00:53:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5134daf7-50d0-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750751609; x=1751356409; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=C1QJrSMq6CXVVCTvl8sSq5jZgyRmHg68fGGy4yje03g=;
        b=H+OU1WFoy4hXzzXqCKnqUXQXTl8KLWuOdlqfVCQ9+yRXGuPzyHqyekH3EwF6dufiNh
         xQTkPECSXHrHdSVCgIqEfy0gZojn43Wc3x4e/1kqSXz3alJdv81qh8h8ep71AB8rELFd
         J0PgAIkSpUbzlMawBvBWlNBPMRUGNwTVC80zBmfYB2omcXjpzN+0X+RKe9xqYanyDxUb
         hLLW6vH9owba3secpNIpZRkozItKQnd2OQu4xZBNr+mOcnGe4NzIsczKP+rR3IDaUgwz
         w5OQJU7TwuKhLsTjkHuOfjyv7bC1o77yGp9oKPgsWd+n0OND8ge10+Ku0ook+QVQh7I2
         HHGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750751609; x=1751356409;
        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=C1QJrSMq6CXVVCTvl8sSq5jZgyRmHg68fGGy4yje03g=;
        b=iEypLPTdbckn5Qd7VcbWWLfNkIPdg4+gAjUhZTr7/nXXVoaU6TKMpTPU167GkliT7N
         zbo0Ye2nMkR1HoDfJFiBxMrR8XA9YaQkUL6sh2dtGqFgNiGkd7HGyG8Uh/ytzu/uT+DQ
         +K80QuYUvY/nz0ZDgRwvba/9D+OBeuek0OZ/wp2OXMzkUhF/7Kd991h3L/zH7f/xLAQN
         3oF8x2ZMlKnwvH+mL2iOof5fF8j16G/q1oaosI4majrpjGmc+zb2Qwt88CdcEgYzSxG4
         NFGAnZsl66oQd+Ie4iXfs7xIfs4nZTlfrbOgyx8EswtiFDY3qe6Y52cPOe7tgAe/8+NY
         v1NQ==
X-Forwarded-Encrypted: i=1; AJvYcCUFuGQNpgiOa28lmDXVWFhblY0ykk1NCzrgIKthp5aBDPz8Spvnebu89fyeijZ99ICuFeMv3V4xvM4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YymHOi1So1Wf1ckCGN9sD3Vpa863jc5zIWT389XhQ3J4f1Xzto3
	1N78o0fu9DqGPdKbfLiH6PnhnzO4CdukFYnQA7hnOX2hWoNhYDDqmV5LKQ6res1kIA==
X-Gm-Gg: ASbGncu22j8PbsJAvIAWVyBZInBr6Aaya7PdyaExAJ1TPV+QRPW83ll5WzpBmhFLeu1
	Dh0LCsTHrheAVAEhsYne2J3p/ELMf8MrvLRShU7e+tYhKt+BhxZVwr4Svudvt8j1rO6wxBNmflf
	I+RL3Fc61lUsbwrZp4v+pgcTaNJQqzRhqgJH8Is8rpHGcyrudz4mA5v7eZhWByEfaXXE+5tIGE/
	Ijrj/svBrhsw+nYPJPZYj533kpjWlSeduYs6pseHMvEa5A+5GcXGgJPNloDSvkGyOCcaWIZalRd
	KHgfbQfwT6DvaNVvj+i0H3crlC9DtorZ8JRzO3Bctg9hf9U/6eCBtqEm52UoPfw3Uyib6IyEZKZ
	EidQgUXNFP7qHycciPT8SpDbYt1lT1NswOB9X9fNlfdtCMwzHCbnJ3UBA3A==
X-Google-Smtp-Source: AGHT+IF6enLITgWcdwf3Q3YXdaAKxsCC3a8NeAJ5+5yNggWbSj6cB3mLENq1X9qfRUtchcehlEhGaA==
X-Received: by 2002:a05:6000:25f3:b0:3a3:6a9a:5ebf with SMTP id ffacd0b85a97d-3a6d129d7f7mr11063287f8f.20.1750751608972;
        Tue, 24 Jun 2025 00:53:28 -0700 (PDT)
Message-ID: <2b345a72-5ab7-443f-bff4-2b4ee9952825@suse.com>
Date: Tue, 24 Jun 2025 09:53:19 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4] xen/char: implement suspend/resume calls for SCIF
 driver
To: Mykola Kvach 
Cc: Volodymyr Babchuk ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Oleksandr Andrushchenko ,
 Mykola Kvach , xen-devel@lists.xenproject.org
References: <5449d6fc4a6e47af173d9e2b285f1e3398de98a3.1750749332.git.mykola_kvach@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: <5449d6fc4a6e47af173d9e2b285f1e3398de98a3.1750749332.git.mykola_kvach@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 24.06.2025 09:18, Mykola Kvach wrote:
> @@ -281,6 +313,10 @@ static struct uart_driver __read_mostly scif_uart_driver = {
>      .start_tx     = scif_uart_start_tx,
>      .stop_tx      = scif_uart_stop_tx,
>      .vuart_info   = scif_vuart_info,
> +#ifdef CONFIG_SYSTEM_SUSPEND
> +    .suspend      = scif_uart_suspend,
> +    .resume       = scif_uart_resume,
> +#endif
>  };

As this being put inside #ifdef was to be expected, imo a prereq change is to
also make the struct fields conditional in xen/console.h. I think I did even
comment to this effect back at the time.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 07:58:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 07:58:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023273.1399223 (Exim 4.92)
	(envelope-from )
	id 1uTyY0-0005k2-5Z; Tue, 24 Jun 2025 07:58:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023273.1399223; Tue, 24 Jun 2025 07:58: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 1uTyY0-0005jv-30; Tue, 24 Jun 2025 07:58:28 +0000
Received: by outflank-mailman (input) for mailman id 1023273;
 Tue, 24 Jun 2025 07:58: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 1uTyXy-0005jp-B0
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 07:58:26 +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 ff185bb3-50d0-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 09:58:21 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-453608ed113so43840105e9.0
 for ; Tue, 24 Jun 2025 00:58:21 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-749b5e217bdsm1216481b3a.52.2025.06.24.00.58.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 00:58:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ff185bb3-50d0-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750751901; x=1751356701; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=V6xQj0y1FfvS292RhxT8v62hjhwlmlUxYI116gPjOZM=;
        b=XzsHD8c6Wx5el8ZoSz5fsZV0yzSOtOANLOJZ3+cmZLkk65ccIwqLIzSaRSmuP+Dy9w
         Hr30VLH1AP4Ig4BwsnDEBwmzjDXICWBp0yZb5X8jEMmX4nB9gzTSVURRn0XurVfuCj19
         p6imhDLDUTuQay5ggVqVZ+F8yeMrIrs4+3/ZkqGju9DG1fL8UHGC8ugRt71Wip+xp7hz
         vt7m2aSFN/41q0yk4Yu1B45kLf9MLqu0Qt86xAKzPTlf2YNHyMH1BFn02XcwHlHx/xGl
         txnPoU+wLyJujC+pUYigVgCiWGGTvcTnsc9YUz1mSjoin9qE7FsAnIanIcrib2NImytp
         qnLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750751901; x=1751356701;
        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=V6xQj0y1FfvS292RhxT8v62hjhwlmlUxYI116gPjOZM=;
        b=cvFDyzrZHQfE2iJ7upPPStBctxDPO3gqMkzYUGnEGbHBMgjpahJdHIIlK97N/PdLgr
         sqe2a+vsBALCSXF4G8J3+/WjRcrwFX235w46pkg+0wXE99FvipgpFwMtt+NCbCZjTkhI
         5BFQ+jf0H/OxFGHCoqYzg9metY01vDxXda+/hvt6bKFW/Jp4Va7A2JDdBHDPK7EFwOAa
         HIvySUoGJvkJ1DLu6ztrWlyUa1snFZ1/UkH9fiI8rYaTwrK5p08q1r7E4b/HQpekwIgt
         eGkrJP6JWrZPeWa+VhECZUy42LKmwn8f7Z6dmUSXcG4H5CsoIXgKicZckN8mqteCcBU7
         vfQQ==
X-Forwarded-Encrypted: i=1; AJvYcCVj0u0qIoAVWtUvbmgXXZSOWxxKTud5sGuifp1bbnEQ/abcPE6Y8Et4zZSZ1+HYXCs+eCPu+YWPBaw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwThs/ySM57cCn5AQu1xZ5OXCjbgdsnUIwcKOBDS+jHbLQxa5Mv
	xt+pAhOV/D7h6rb6rGVH6LzZyki5AqbUoeJXIHLrMT4UI4nghcaH8M3rv9SCAoWrgw==
X-Gm-Gg: ASbGncs9XzYL4QLtKJn5LUUAHTNvwBzWi1TQ2lK6xQQpXLWoNVpUIxCRd3/FSgmqYOW
	mL13XvP2W9Otn5LkGSXwWgA4URxtBxrYc/OHmdlTGDHy8PzeDliLPbB3zKtDfkBpNojzNv1agY3
	jUuWSzuLUo8pg1kvaOf7EI5vvWuzbT1o+9897blem+WPKHGyBzdOVLjYiLTqEOrT/LXBsexya05
	wAf5GpMzRiDNO52za/Ad8qIGb9gGHV6LpDK+QdWPchgBxIRI3m6UBooCwZDH9k95e1o8NNtr0E9
	NdTo22SCVgMWvoTHTp3uFSlnu5qq4bqBa7ot5D5Ua7og/24ITPDnnu2w4zJQdQPspAhChJ8SFmS
	+zb2fxZLKHKcEY3mKkEYo5n7gZTiyZN17d/UyF5rB5qOwkpA=
X-Google-Smtp-Source: AGHT+IF1jXWbrNsQe4ycNbGox/hi8MTmz/2xGI0w9OsCTCwEWquiHe0kHrsCpDIOuGlDq1VMfvL+rg==
X-Received: by 2002:a05:6000:22c1:b0:3a4:de02:208 with SMTP id ffacd0b85a97d-3a6d12e5a26mr13495125f8f.25.1750751900715;
        Tue, 24 Jun 2025 00:58:20 -0700 (PDT)
Message-ID: <7d53a801-89ed-440a-b5d2-bbc6abf8a6a8@suse.com>
Date: Tue, 24 Jun 2025 09:58:11 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4] xen/console: introduce domain_console struct
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org,
 dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250623202030.208655-1-dmukhin@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: <20250623202030.208655-1-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 23.06.2025 22:20, dmkhn@proton.me wrote:
> From: Denis Mukhin 
> 
> Introduce domain_console for grouping data structures used for integrating
> domain's diagnostic console with Xen's console driver.
> 
> Group all pbuf-related data structures under domain_console. Rename the moved
> fields to plain .buf, .idx and .lock names, since all uses of the fields are
> touched.
> 
> Bump the domain console buffer size to the closest power of 2 (256) and
> rename the symbol to DOMAIN_CONSOLE_BUF_SIZE.
> 
> Finally, update the domain_console allocation and initialization code.
> 
> No functional change.
> 
> Signed-off-by: Denis Mukhin 
> ---
> Changes since v3:
> - parentheses fixup in guest_console_write()
> - move buf to the end of domain_console

Plus do other re-arrangements there, if I'm not mistaken.
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -669,7 +669,7 @@ static void _domain_destroy(struct domain *d)
>      BUG_ON(!d->is_dying);
>      BUG_ON(atomic_read(&d->refcnt) != DOMAIN_DESTROYED);
>  
> -    xfree(d->pbuf);
> +    xfree(d->console);

This now needs to be xvfree(), to match ...

> @@ -877,6 +873,14 @@ struct domain *domain_create(domid_t domid,
>  
>      /* All error paths can depend on the above setup. */
>  
> +    err = -ENOMEM;
> +    d->console = xvzalloc(typeof(*d->console));

... this. Sorry, I probably could/should have noticed this earlier.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 08:02:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 08:02:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023282.1399234 (Exim 4.92)
	(envelope-from )
	id 1uTybZ-00088V-OM; Tue, 24 Jun 2025 08:02:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023282.1399234; Tue, 24 Jun 2025 08:02:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTybZ-00088O-LE; Tue, 24 Jun 2025 08:02:09 +0000
Received: by outflank-mailman (input) for mailman id 1023282;
 Tue, 24 Jun 2025 08:02: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 1uTybY-00088I-Qe
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 08:02:08 +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 8601fbcb-50d1-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 10:02:07 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3a589d99963so4873338f8f.1
 for ; Tue, 24 Jun 2025 01:02:07 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d8664f0esm101196515ad.159.2025.06.24.01.02.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 01:02:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8601fbcb-50d1-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750752127; x=1751356927; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=0pxYU9k82gDdxrz2FGnKvbqTeEJcdt1/BVM28t12BPw=;
        b=Ee+CnrXrn/biHH4UbxuQ5TCgn/+AbqB9FoKDAMFJZgqqcIMp5+FWzlWZZnhBh9awMu
         hAQV+x5HEZYwPqAyJVhLtKLK0X5dY3cssTsFJAKnPep6aMGR9r/sx8+PzGMPk9b9an3c
         ffcRrypYGppzE+TQScwh1dVvE4dSXOd0dillob07xxhxTrlSYe0wBJVxqLaakDnijwmH
         tH0BAhkHe3lPW887CigXyV0z8rX8y8Sdfljd8zu0w6QsjkbirfTlV5QkcMMYTWFyLXWz
         B9VIYSwF4Rjz+yJkpOjsUl7dJE40lTtzNk+xqUZtfQb8Y9JcG4esPRivM7VK7LfiL84j
         BZeg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750752127; x=1751356927;
        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=0pxYU9k82gDdxrz2FGnKvbqTeEJcdt1/BVM28t12BPw=;
        b=O/8WPiFtQz+AUXgcVN19dPyOf6Bokj0ESItiCouTVKsjeTolXC7e9vyej1kZVvcOrd
         2xAcFMQUJ/0ug3XYuJYtAXOv1Q9d/8mI9++PqUsclMOd7C7n5WqVV3C9sbINczd6n3k3
         OzZNKQlCYWFaw8ChxgTnVNDr7ds8k1rO/MRXUr4mKqP52R2627SWtwiUUsbFCQFgz8XI
         cco6Xrv6/NfmemGgTxBKkxZJyC9TxWKZ9cHXP4NYEc0GCpE9UmRCCsGlevr/VIRI5AvP
         VBLL1b9ZcK5zVt43FiPCtNp3inVSWbM/dLUCfBI4it4dbAN5pSwH+IbkvTdabmR1BCsd
         t01g==
X-Forwarded-Encrypted: i=1; AJvYcCVUfm/KkYaToN92+NGPKuSq2k4J2pbF9ajB5l4M8f2QEIQKQ0FXMPoAVaZblmfSwD6K0p4FqR3Z3Lg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywr+/PkgERruwdsMd+ydbnTaUuR2brfQ3g+FdxVB/Dhy/WOzZrz
	jvNYmeV7/YdVg2gL8unNcjTeMMv9TwmsLWlElikqg8iXIW2XJbMsr1G8gdlp1NjuiQ==
X-Gm-Gg: ASbGnctwPwaemXPpE1TgBoB1TNihcoy9zKB/XQKHYR9zs2bBpE8ZyK3/n12X+cbQIc5
	ArTxzYgO7kq2GW2l7uaAnz61CIblTz0e/Xxr/KIHtYk7yTeQ5QRt1MTI5F2SZ8X+vEwsNLRoG4A
	0KlfwESc9O4rcuBgkLlKK70/yhx4UI2bkpvqM023kioDdnA3W8sLEOKTaPV6ETwf8tk6YI9CXRc
	4v13NggObVAY+DtlIUMX1vjz3ZEHFPEKT0ex+OmoH8ufxafpcQac13vu9WwtkJd4sU9QlbTKSZv
	xKRuLRcyxIvWJfGcw8VbC47hPuNiRLkRKbV+EzpCiNYTFsVrIgS7P66cBKvrja5OJeWL9zgdp+d
	fr2UfKSC5mw5FzSE9NlpFdn6yD32rO1iKbyBvy67DAi0FE4c=
X-Google-Smtp-Source: AGHT+IGa8ybs9SCidA+M+B6GTihe1AeTOh/o05eOY0aPpSDLr8F/0E/ZxfhiOG5F9sSSnQ8MfGufFw==
X-Received: by 2002:a05:6000:144b:b0:3a5:1471:d885 with SMTP id ffacd0b85a97d-3a6d12ec3f6mr13602383f8f.56.1750752126954;
        Tue, 24 Jun 2025 01:02:06 -0700 (PDT)
Message-ID: <35d1546a-d09c-44bf-9fbd-911604c1dd5a@suse.com>
Date: Tue, 24 Jun 2025 10:01:58 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/3] x86/EFI: Fix detection of buildid
To: Andrew Cooper 
Cc: Ross Lagerwall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 "Daniel P . Smith" ,
 Xen-devel 
References: <20250605111638.2869914-1-andrew.cooper3@citrix.com>
 <20250605111638.2869914-2-andrew.cooper3@citrix.com>
 <0a314400-126a-4c2a-b36c-dda61bb0b751@suse.com>
 
 <4d1f1b70-e309-453b-bae6-e066d49a417a@suse.com>
 <9200277c-aa8e-4fd9-ab6a-f9e106114f54@citrix.com>
 <6eaf2b27-969a-4326-9726-8b6e0994e006@suse.com>
 <3f9c5a18-2ea1-4e2d-80a0-773abc3598ae@citrix.com>
 
 
 <134c69c8-ccff-475c-8bf7-241ec4805754@suse.com>
 <6690e6cc-60e8-4258-af80-1c8a56e76cb1@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: <6690e6cc-60e8-4258-af80-1c8a56e76cb1@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 23.06.2025 22:18, Andrew Cooper wrote:
> On 16/06/2025 7:27 am, Jan Beulich wrote:
>> To expand on my earlier suggestion (ab)using the "efi" global: With
>> the linker script having this
>>
>> #ifdef EFI
>>   .reloc ALIGN(4) : {
>>     __base_relocs_start = .;
>>     *(.reloc)
>>     __base_relocs_end = .;
>>   }
>> #elif defined(XEN_BUILD_EFI)
>>   /*
>>    * Due to the way EFI support is currently implemented, these two symbols
>>    * need to be defined.  Their precise values shouldn't matter (the consuming
>>    * function doesn't get called), but to be on the safe side both values would
>>    * better match.  Of course the need to be reachable by the relocations
>>    * referencing them.
>>    */
>>   PROVIDE(__base_relocs_start = .);
>>   PROVIDE(__base_relocs_end = .);
>> #else
>>   efi = .;
>> #endif
>>
>> where only the #if applies to xen.efi, can't we (ab)use the combination of the
>> other two symbols here to decide between xen.efi vs xen.gz?
>> __base_relocs_{start,efi} won't possibly be equal for xen.efi, except in an
>> extremely theoretical situation (and we could cover for that case by an ASSERT
>> in the linker script). Pseudo code:
>>
>> #ifdef XEN_BUILD_EFI
>>     if ( __base_relocs_start != __base_relocs_end )
>>     {
>>         ...
>>     }
>> #endif
>>
>> IOW that #if could simply replace the CONFIG_X86 one that's there right now.
> 
> That's horrifying.  Also you can't include efi-boot.h to get the
> declarations.

The declarations could be moved, but ...

> But given that you are adamant that the (...) in there containing a
> CodeView check is unacceptable to have, why does wrapping it in yet
> another conditional make it ok?

... hmm, yes, there'll still be unreachable code there. I guess I'll shut
up here and leave this to the EFI maintainers. Just as long as there's not
going to be any Eclair / Misra fallout.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 08:02:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 08:02:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023283.1399244 (Exim 4.92)
	(envelope-from )
	id 1uTybb-0008Nh-3n; Tue, 24 Jun 2025 08:02:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023283.1399244; Tue, 24 Jun 2025 08:02:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTyba-0008Na-Vn; Tue, 24 Jun 2025 08:02:10 +0000
Received: by outflank-mailman (input) for mailman id 1023283;
 Tue, 24 Jun 2025 08:02: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 1uTybZ-00088I-L1
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 08:02:09 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20628.outbound.protection.outlook.com
 [2a01:111:f403:2418::628])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 85da26df-50d1-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 10:02:08 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by SJ1PR12MB6266.namprd12.prod.outlook.com (2603:10b6:a03:457::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Tue, 24 Jun
 2025 08:02:03 +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.8835.027; Tue, 24 Jun 2025
 08:02: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: 85da26df-50d1-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=wkwrc2+hn7NpB/bakSmizquOmrGecjwmp4gSXUwbWXw1GEmHbyMkvNSKq/bm1sz0Lh3WFkza2Kkg5LIbb3L4EmRf3n5mhhG7IM71zhCZx3DXhd4UiAJWeBfvSBPL17iCJ9PJFXrzwGLAg4MwlhpvLHdahj4lAIOM5+zhyKHETToz4prMR9ZKOquRmoc5AQpl9d56CoFFDH7qyzmTtDQ4eFWuRX2IPCuRxqj9kGMXOQVQi3N9SU39qdVAPR8w+gUalWhSbo3LgJ5dsWmv33ItUt3NoqjK0xI+/T2+pBG0M/wlER08f6lM6tm6t3BljgZzRTx63TbuPzXhPMz3vypQ2w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=V4H55WUnEx4Z2Q3LTWJ1157yEqKV64s+HISe0A4fU8I=;
 b=b6FJDEWR/rfKysvIXdNWlvAsPB4yOhjkjDyRgNiy2UXUnbDJAT8p+07c5SrTzb0AcP5nvUPV4rGQRzsmTgN+wRlYhj+dXxYT1KNtwH5fgjhJQtxGQ7yBPW/eaBxK3+iuz8DdvmVtL5odD1Iso2yJke176jFN78mddi6nJ47ShoWwNjXjEYgkIB+dLaBroTSshv5q/rf6OLdZXOjIgbssOD5p8tlbOukSOGJl7g/REuIeajRfGPzYufn+vc+B2eOqVLAgMTdI9/xyexGqsYtzOjaGLQG6JFLetaX8KVzCVs4S1hxS1LZovYl751nJlSjFsftnDpisCRkYDrcR4yjlAA==
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=V4H55WUnEx4Z2Q3LTWJ1157yEqKV64s+HISe0A4fU8I=;
 b=Ea2l6cyaxBIHBMvQzvvBYvYwiWMw/eq+SCte4nUNXFijKj7qcjmuECSVeYlhuT3ndqzJMI40JBeOxdH6HvZaoA8s4FIT29mchn/RSc0nJq6WDpa0GRbkRdWJX43R6nbsq6ECvIy6g9EQ7tnJgiqL85SAQEqIz64M7LV/kJRBr50=
From: "Chen, Jiqian" 
To: Jan Beulich 
CC: "Huang, Ray" , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Andrew Cooper , Anthony
 PERARD , "Orzel, Michal" ,
	Julien Grall , Stefano Stabellini ,
	"xen-devel@lists.xenproject.org" , "Chen,
 Jiqian" 
Subject: Re: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
Thread-Topic: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
Thread-Index: AQHb23yakGdVC9XxvEWnYcnp8zrTt7QI/QAAgAGa9QCAAQzVgIAG5D6A
Date: Tue, 24 Jun 2025 08:02:03 +0000
Message-ID:
 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-3-Jiqian.Chen@amd.com>
 <516a3adc-320d-46ce-b235-8ef91469abcf@suse.com>
 
 <227df6d3-a2c3-4576-bde9-d8057c378e7a@suse.com>
In-Reply-To: <227df6d3-a2c3-4576-bde9-d8057c378e7a@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.8835.025)
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_|SJ1PR12MB6266:EE_
x-ms-office365-filtering-correlation-id: 7f9fc2e4-393e-4215-bea8-08ddb2f567e5
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?d1dIbGkvWnhiSWN5SkcxZWhXdmFxZ2lNeUZNVTFqdGJyZGx0bjgzUlFIOURl?=
 =?utf-8?B?dVZaYk8rZW9zTVNQVXNwem1jeUoxdzF6d3poL1dZUFN6ZGxTS0NyRGVJdDFD?=
 =?utf-8?B?eEhNcWR0Wml4STF2RmFCaW5FN3hYYzlUM2R4WU9vS0srdXMvZmYwQ0RLM1Vx?=
 =?utf-8?B?c2xqZFpTcHVFNkFPY3BRdlRpQWVUMVo0T0dObHc1VnA2WjFzRmRMQWMwK0JM?=
 =?utf-8?B?dXZuZUtvOW5IeFRNL09jd0pNbWJvdEYrRzdsY0RlSTd0K2g3M1pHNENwWUVp?=
 =?utf-8?B?ck16UGl3TU9vakJKMlZvL1B3OVhKbWVhNEpIV1dqdGJIS2Z5bUVpNC81SGtE?=
 =?utf-8?B?S3RGYWFJWnVOVGgwMG8weGtKc1FsQ3JId1REMk5NYnFGMEZNaU1NQjQzVkc0?=
 =?utf-8?B?bTFUcGlVMUFJekoyN0VpWmhPSzJmRmkzUUIvK0oyMm9zVVJiL3RUV2VFTmZL?=
 =?utf-8?B?WlhtZjFXOUJvSTBFQXlWazF2Z29LV2NMZVVINUVpQy9yeFZjdXRGUEhmK3JZ?=
 =?utf-8?B?MDNvREFOZ3JES3pGdWtlMmZNQ2IxajRBQS9xckpYRTFrVzlKRStGY1VxeWw3?=
 =?utf-8?B?bHp2aFQ5UTY4cUFTbWVpc2Y1RURXSVVXVzhsZm1zMjJZaXJlUXYrRGtjMGsv?=
 =?utf-8?B?R1pVd0t2U1ZYNDdDL2tUeUlHZVVSWXZycnp6UlNtSGxQWTdDN3o1Z1VMRmhV?=
 =?utf-8?B?R0ljRk9NdE1JMGdoRlptcjR2eHVJMzluTDRWd3prWlJOemxuZVVRYUE4dkVN?=
 =?utf-8?B?ZkpJNW42eUt5enlsZ0xKU3RmTDlaV0ZBSzMwWlNIQzNKQ3BBMEtqODQzbW8x?=
 =?utf-8?B?VjlYWUl1OGVGdW90TG44dXBValJ2cUZtQS9VMDN2U1NwWUdNZklNK1RuSlRT?=
 =?utf-8?B?VUZiczFzL2hHcWFIRjMwUHNQT0UvL2JveGJKZ3ByU3JnSkwwZzdybFZXWFVq?=
 =?utf-8?B?N1NxZWtTNXJ2SlNDcHkvSU1pTnkrcHEzbFdvcnc0MldpOXZIWkpTQmRFTjJQ?=
 =?utf-8?B?c1Q1cS84NWRVZHpuWWVPNU5TcVh4NS94YmJvVFo5RzRuL05JemFGMEdmZUUy?=
 =?utf-8?B?clJiT0NGRUlEMEFOMENNVHA0SXFNV1BPNzRPL2tZR3pIRjluWWwxUTMvT1hp?=
 =?utf-8?B?bUF5OHNLTWlTYzAwRzZicTBBbVFmRVp2Z1dBK0dvVzZlMGQyajJOY2FwU1VJ?=
 =?utf-8?B?d0hEVG4vRzl5dm44NUlSWmpwSDc0SWpLUC8rcHlGZFNUbndnVTNVWk04VUY5?=
 =?utf-8?B?V1NIUHZuZWs4OXVTb2JjQ2lpYUs5WEhqOHAycVNhd1loSTBucmRxWWhtcUVp?=
 =?utf-8?B?UFVZSFgzdjY5NzFyYmtITzhSZkc3Q0hUbnJDdGozaVl1M0lwUTZPNGJMRU9n?=
 =?utf-8?B?eURxSjVxakpYRzZHaGlDRTl6VUlERWlDRm90TFBPSSs4RVdXaE5BYWU3ME0y?=
 =?utf-8?B?b01DeDhac2EvRWxOcmJkTFlQMDNadGRhZ0toMzloazJvQTFybDB4RGd3SnZa?=
 =?utf-8?B?VXpnZkJRV3pVMlRRUFpvQVZabGliTHlMZ21LK3h6ZEtTSzhmU1gxTXdzbHlM?=
 =?utf-8?B?WjMyQThjSjRFb1kraFBMY0pYejdCM2d5eWpLK2Z3ZXRrRHNqS0RkQk9vK2sr?=
 =?utf-8?B?NEJJcjFKTURUTEIySDNXcUF6citsWVUxQjhlS2ExWmtFQ215Mmk5MUw0S2Iy?=
 =?utf-8?B?ZU40Q0ovTlNyNVdDaDh2NW8zaFJuQjg4bUdqcnZXT3E2UG9vUi9CajhFbVJs?=
 =?utf-8?B?elgwY0VlOXFldm4wT2c0bkhFLzMxcVJoNmY4Uk54aEJGdmtQQ3FiZzdVaXpY?=
 =?utf-8?B?VEUxUS9FZjlrR0g1ZWt4OTNLcmJ1dmZyOXZNbW9BOXUrZVQxdE5KTVlLUDVm?=
 =?utf-8?B?QWtxN2pnMFlRektMVnVzbENLVDB5UGpMbHlScFhrRDlIZ294ZlF2dHloTFhi?=
 =?utf-8?B?QXZ4Rk9LcGpHZVZMK1I2UG5kbDFaTy9rSzNyNmNkM3JseWcwWFl4ZzlCMjZx?=
 =?utf-8?Q?gPBQ35iqLSi3X9gj5rLyq+m1BSx6Oo=3D?=
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?Y2lVZjZETng3dXNBcWRnY1JBU25WY2dhRkFQMU51cWJWMjQvNGRVdG9DZEdu?=
 =?utf-8?B?eE9mQWhXZXE1U1BZYWI2ci9QbU5jZmtOR0ZCVG15QjRCT3NDSkt2Qy9TNlc5?=
 =?utf-8?B?YkJhU3dLV0pMTDhNRisxdEFsNjQvUUpkUURVMlFQZG50TytudDFTR2ljSzBH?=
 =?utf-8?B?Uk5DSnhjdnBHYktlZTNYbUkrWXgyNWZBNjUya1dGOWtHUjVmdjdnbVNqVW5u?=
 =?utf-8?B?VU5zc21Sd0p2M2Iyd3gyN0tYSUFZZjF4T1FlbjY1UEhyZFFhSTlReGwxN0Jl?=
 =?utf-8?B?ZWtkTHB3NjFScVlyMzQvYWhTQUJSVk1QbDJHVWNGZGM4VjhIVWNqTXpRTFdT?=
 =?utf-8?B?Y1lDemxsQWVlbXBMN1h4dm1aTCs2Q3FCeGsxMjZLQVZxOTY3K3FyN1I2NGF6?=
 =?utf-8?B?VWtZM043eGVKYS9XOEdPYXJKWFVjb1p0SityczZsN2JCOHJKNGRNajNnT3pz?=
 =?utf-8?B?SWxoTDlLVTZzRTVVVEwzeDdPZmhadU5NRXMrT09LRWE5TVdYTXJ3c3UxMnA4?=
 =?utf-8?B?S3RBZ0lRazUxMkFVaTV3RXF0Y2xzbk4rYjhVVEhqd0JZTzA2MExULzZmaUFq?=
 =?utf-8?B?M3I5VytGNWd2UUpuZnZGS3ZQTko1c21FbHhqWWNNNUtwM1VLZFpsWEErNktC?=
 =?utf-8?B?Vmk0cWVCK1B1TS9nOUJ6LzFnWURnekRtZFFlUlNXaExUK0FjM044aXVhT0tj?=
 =?utf-8?B?ekdjUWFQemtlRTF5cnVsR1YzTEwvL3FMMjR0aXcweWkyNmM4ZDIzY1FYeENX?=
 =?utf-8?B?d2VYRXBhZmZIdDM5NU1WdzJ4YTZqek9lYS9WenNMbXR5cWlVR2szN0tVbXNo?=
 =?utf-8?B?QldFczQ2STJBNWJwaW5lOWZwWks2TnU0Um5uU3A2c0g2bTZzVGJPVXY4R3Jv?=
 =?utf-8?B?dTZqMWlOWlFwRUUrYzZXQVlzaXdFZVVaZnJVcHNDNzJsdHJIMzE3c2ExOHVy?=
 =?utf-8?B?L1B5UWFMakIzZ3YzZXlsdkxyZlhwT3ZDcFpDc1czSGFQa1BWdkxBd2daTlhI?=
 =?utf-8?B?L0c4VThnN3BnTGE0UFFGdERGQUdDZEdSSDJRdDYybFQ1K2hWM2xHUWtJcWZX?=
 =?utf-8?B?R3dwdlh4Y1AzSjBlWDVEcWNSN0NVY1VaVmV1Sm55SEg0bHZrcjNwOVBrdkZY?=
 =?utf-8?B?UW9xREF1MXVMcVltY3JDeGJHTElJRmo1bktGdU1KS2hpTk5nYXg1N0lKdW0w?=
 =?utf-8?B?YXc4bHljQ21OVjBocXgzSHZqTXdzZDdTQmdXZjRaOWRJMnBmbWVoU1hpbkVQ?=
 =?utf-8?B?ZEtrSVU5UWpEQ2p4bVhnRGRnMkJUVXozcWZFUkZaMFh6QVNnbW9xaGxIaDZ3?=
 =?utf-8?B?YzgvV2xzalA3ZzdISzAyL0RzUkVEQml5alpYZUJGQzJBQzZBS1luV2VwanV4?=
 =?utf-8?B?cVBuTUl5bXVNQk01V2tEUFc3VERUZnBZK2pyeWp0NUJPNDI0SzQ2VmZDUS9R?=
 =?utf-8?B?TnBRVmkyRmFxaFBFU240OWpuSzhJVnlrdzJtT1g4OXVyRVhxTUdTckQvbzdK?=
 =?utf-8?B?ZFJnS1JLODhUOEMrMWRPRHl4WXdZZ0tiSHpVRjR3dlpKODY0VUo0b2kvR1J5?=
 =?utf-8?B?LzhMMjNTK3VzZlJlT0d3QytneHhueFcyVmJhU0tWTGRPNklrRXBwRU41YVlS?=
 =?utf-8?B?c1F2bzdtQ29WQkhleUQyQ0owVDFla1pFa0Z0d2RQTXpWKzVNOERBeUdVS0l1?=
 =?utf-8?B?WDQ0T0c1a2NKMW51WGFRejlxQkJQNDBxZXlsZStKUUNKVjFKNDc4bGkwdmNS?=
 =?utf-8?B?Y2NOb1grQ1hmMnJhZ0tBUlBKZ051MHcrcDZyVW9sb3Y5c3RSMW5POUJ0TTR2?=
 =?utf-8?B?TnI1RlgvaFNGTXVKcVl4RzFxMzZGeVJPL05aNUZLOEFZVWpicnREd1UwODdW?=
 =?utf-8?B?OGxrdFdNc3g3dVNwNUcrNnREM2lrRURVTGtCTlhnZGhsZlZ2ZDYwYm5scUda?=
 =?utf-8?B?a0FqZFZtdmgzLzlSSmNzeVEvcjhmRm5xNzBTbzNPUDlDb2ZwejE0SEdOVktk?=
 =?utf-8?B?aGVlZnJmMFFKY0dhbVFhV0dtYjZLc01DWlhRSVRnbkwzNEI3WU8waUF3MFpo?=
 =?utf-8?B?ZlBpVDRSZFNjYngvQS93d1N0VW1SUzNFYUNXMmZYODJnS0I0NUFBTWlCTFpJ?=
 =?utf-8?Q?WGyA=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <2DCD6F8435720F4EB433C8E9EFEAF274@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: 7f9fc2e4-393e-4215-bea8-08ddb2f567e5
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2025 08:02:03.6087
 (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: SOMlJY4QqdMOjPyIhrKMBGWTX4oFaier48tQ6MqljdeErtN+RH+Ezx2rm9eqkkD1SSdfQFBgVC+Mh8rIJRDbMw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ1PR12MB6266

T24gMjAyNS82LzIwIDE0OjM4LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMTkuMDYuMjAyNSAw
ODozOSwgQ2hlbiwgSmlxaWFuIHdyb3RlOg0KPj4gT24gMjAyNS82LzE4IDIyOjA1LCBKYW4gQmV1
bGljaCB3cm90ZToNCj4+PiBPbiAxMi4wNi4yMDI1IDExOjI5LCBKaXFpYW4gQ2hlbiB3cm90ZToN
Cj4+Pj4gLS0tIGEveGVuL2RyaXZlcnMvdnBjaS9tc2l4LmMNCj4+Pj4gKysrIGIveGVuL2RyaXZl
cnMvdnBjaS9tc2l4LmMNCj4+Pj4gQEAgLTcwMyw5ICs3MDMsMTMgQEAgc3RhdGljIGludCBjZl9j
aGVjayBpbml0X21zaXgoc3RydWN0IHBjaV9kZXYgKnBkZXYpDQo+Pj4+ICAgICAgcGRldi0+dnBj
aS0+bXNpeCA9IG1zaXg7DQo+Pj4+ICAgICAgbGlzdF9hZGQoJm1zaXgtPm5leHQsICZkLT5hcmNo
Lmh2bS5tc2l4X3RhYmxlcyk7DQo+Pj4+ICANCj4+Pj4gLSAgICByZXR1cm4gMDsNCj4+Pj4gKyAg
ICBzcGluX2xvY2soJnBkZXYtPnZwY2ktPmxvY2spOw0KPj4+PiArICAgIHJjID0gdnBjaV9tYWtl
X21zaXhfaG9sZShwZGV2KTsNCj4+Pj4gKyAgICBzcGluX3VubG9jaygmcGRldi0+dnBjaS0+bG9j
ayk7DQo+Pj4NCj4+PiBJZiB5b3UgYWRkIGEgY2FsbCB0byB2cGNpX21ha2VfbXNpeF9ob2xlKCkg
aGVyZSwgZG9lc24ndCBpdCBuZWVkIChvciBhdA0KPj4+IGxlYXN0IHdhbnQpIHJlbW92aW5nIHNv
bWV3aGVyZSBlbHNlPyBPdGhlcndpc2UgbWF5YmUgYSBjb2RlIGNvbW1lbnQgaXMNCj4+PiB3YXJy
YW50ZWQgbmV4dCB0byB0aGUgbmV3IGNhbGwgc2l0ZT8NClNvcnJ5LCBJIG1pc3VuZGVyc3Rvb2Qg
eW91IGluIG15IGxhc3QgZW1haWwuDQpBZnRlciBoZXJlJ3MgY2hhbmdlLCBpdCBzZWVtcyB0aGUg
Y2FsbCBpbiBtb2RpZnlfZGVjb2RpbmcoKSBpcyByZWR1bmRhbnQuDQpXaGF0J3MgeW91ciB0YXN0
ZT8gUmVtb3ZpbmcgdGhlIGNhbGwgaW4gbW9kaWZ5X2RlY29kaW5nKCkgb3IgYWRkaW5nIGEgY29k
ZSBjb21tZW50Pw0KDQo+PiBUaGUgcmVtb3Zpbmcgb3BlcmF0aW9uIGluIG1vZGlmeV9iYXJzKCkg
YW5kIHZwY2lfZGVhc3NpZ25fZGV2aWNlKCkgaXMgbm90IGVub3VnaD8NCj4gDQo+IEkgZmVhciBJ
IGRvbid0IHVuZGVyc3RhbmQgdGhpcyByZXBseSBvZiB5b3Vycy4gV2hpY2ggc3VnZ2VzdHMgdGhh
dCB0aGUgcGF0Y2gNCj4gZGVzY3JpcHRpb24gbWF5IHdhbnQgZXh0ZW5kaW5nIGFzIHRvIHRoaXMg
cGFydCBvZiB0aGUgY2hhbmdlLg0KPiANCj4+Pj4gQEAgLTI5LDkgKzMwLDIyIEBAIHR5cGVkZWYg
aW50IHZwY2lfcmVnaXN0ZXJfaW5pdF90KHN0cnVjdCBwY2lfZGV2ICpkZXYpOw0KPj4+PiAgICov
DQo+Pj4+ICAjZGVmaW5lIFZQQ0lfTUFYX1ZJUlRfREVWICAgICAgIChQQ0lfU0xPVCh+MCkgKyAx
KQ0KPj4+PiAgDQo+Pj4+IC0jZGVmaW5lIFJFR0lTVEVSX1ZQQ0lfSU5JVCh4LCBwKSAgICAgICAg
ICAgICAgICBcDQo+Pj4+IC0gIHN0YXRpYyB2cGNpX3JlZ2lzdGVyX2luaXRfdCAqY29uc3QgeCMj
X2VudHJ5ICBcDQo+Pj4+IC0gICAgICAgICAgICAgICBfX3VzZWRfc2VjdGlvbigiLmRhdGEudnBj
aS4iIHApID0gKHgpDQo+Pj4+ICsjZGVmaW5lIFJFR0lTVEVSX1ZQQ0lfQ0FQQUJJTElUWShjYXAs
IGZpbml0LCBmY2xlYW4sIGV4dCkgXA0KPj4+PiArICAgIHN0YXRpYyBjb25zdCB2cGNpX2NhcGFi
aWxpdHlfdCBmaW5pdCMjX3QgPSB7IFwNCj4+Pj4gKyAgICAgICAgLmlkID0gKGNhcCksIFwNCj4+
Pj4gKyAgICAgICAgLmluaXQgPSAoZmluaXQpLCBcDQo+Pj4+ICsgICAgICAgIC5jbGVhbnVwID0g
KGZjbGVhbiksIFwNCj4+Pj4gKyAgICAgICAgLmlzX2V4dCA9IChleHQpLCBcDQo+Pj4+ICsgICAg
fTsgXA0KPj4+PiArICAgIHN0YXRpYyBjb25zdCB2cGNpX2NhcGFiaWxpdHlfdCAqY29uc3QgZmlu
aXQjI19lbnRyeSAgXA0KPj4+PiArICAgICAgICBfX3VzZWRfc2VjdGlvbigiLmRhdGEucmVsLnJv
LnZwY2kiKSA9ICZmaW5pdCMjX3QNCj4+Pg0KPj4+IENvdWxkIHlvdSByZW1pbmQgbWUgd2h5IHRo
ZSBleHRyYSBsZXZlbCBvZiBpbmRpcmVjdGlvbiBpcyBuZWNlc3NhcnkgaGVyZT8NCj4+PiBUaGF0
IGlzLCB3aHkgY2FuJ3QgLmRhdGEucmVsLnJvLnZwY2kgYmUgYW4gYXJyYXkgb2YgdnBjaV9jYXBh
YmlsaXR5X3Q/DQo+PiBZb3UgbWVhbiBJIHNob3VsZCBjaGFuZ2UgdG8gYmU6DQo+PiAjZGVmaW5l
IFJFR0lTVEVSX1ZQQ0lfQ0FQQUJJTElUWShjYXAsIGZpbml0LCBmY2xlYW4sIGV4dCkgXA0KPj4g
ICAgIHN0YXRpYyBjb25zdCB2cGNpX2NhcGFiaWxpdHlfdCBmaW5pdCMjX3QgXA0KPj4gICAgICAg
ICBfX3VzZWRfc2VjdGlvbigiLmRhdGEucmVsLnJvLnZwY2kiKSA9IHsgXA0KPj4gICAgICAgICAu
aWQgPSAoY2FwKSwgXA0KPj4gICAgICAgICAuaW5pdCA9IChmaW5pdCksIFwNCj4+ICAgICAgICAg
LmNsZWFudXAgPSAoZmNsZWFuKSwgXA0KPj4gICAgICAgICAuaXNfZXh0ID0gKGV4dCksIFwNCj4+
ICAgICB9DQo+Pg0KPj4gUmlnaHQ/DQo+IA0KPiBZZXMsIHN1YmplY3QgdG8gdGhlIGVhcmxpZXIg
Y29tbWVudHMgb24gdGhlIGlkZW50aWZpZXIgY2hvaWNlLg0KR290IGl0Lg0KT25lIG1vcmUgcXVl
c3Rpb24sIGlmIGNoYW5nZSB0byBiZSB0aGF0LCB0aGVuIGhvdyBzaG91bGQgSSBtb2RpZnkgdGhl
IGRlZmluaXRpb24gb2YgVlBDSV9BUlJBWT8NCklzIFBPSU5URVJfQUxJR04gc3RpbGwgcmlnaHQ/
DQpTaW5jZSBJIGVuY291bnRlcmVkIGVycm9ycyB0aGF0IHRoZSB2YWx1ZXMgb2YgX19zdGFydF92
cGNpX2FycmF5IGFyZSBub3QgcmlnaHQgd2hlbiBJIHVzZSB0aGVtIGluIHZwY2lfaW5pdF9jYXBh
YmlsaXRpZXMoKS4NCg0KPiANCj4gSmFuDQoNCi0tIA0KQmVzdCByZWdhcmRzLA0KSmlxaWFuIENo
ZW4uDQo=


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 08:05:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 08:05:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023301.1399254 (Exim 4.92)
	(envelope-from )
	id 1uTyf8-0001Ty-Ir; Tue, 24 Jun 2025 08:05:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023301.1399254; Tue, 24 Jun 2025 08:05:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTyf8-0001Tr-Fy; Tue, 24 Jun 2025 08:05:50 +0000
Received: by outflank-mailman (input) for mailman id 1023301;
 Tue, 24 Jun 2025 08:05:49 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uTyf7-0001Tj-0L
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 08:05: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 08c749a8-50d2-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 10:05:47 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3a54690d369so4234438f8f.3
 for ; Tue, 24 Jun 2025 01:05:47 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b31f118ea2esm8317814a12.7.2025.06.24.01.05.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 01:05:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 08c749a8-50d2-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750752346; x=1751357146; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=BBKazxvzJ8Fm94ZBi7O25USsSSV4tLiKTWTkxYJUPrs=;
        b=YiUQN4b8vLiRJe+lWH672u9NBR1zWBIXAQs3K80BHKp0zUcGH5f03U9VK7MO0cPTgE
         0YAw93/ULo1noH6vadS2/rBB6V5Vau/2MS2fXZy2R9QsTK68aElGTwssxIQjEakY/S5n
         HwZpue967HxhktplZP/l06Q0PFaqFd32NVqHOWFNCFCYOPSVqrow9Dw63wjlWVcNLqJ/
         9Dlh8rLeAQknvUoJu7WxyxfITesVl4lkWAcpWZ8G00GlOzmOc4wu3lnOeuBhenZIwXAQ
         rSrW4SIq1/BSCOXFH/RvEpa8joCB0Yi9xCDq++4J8GmjMNZBKIOmT3BnyuRalOMxZ5EI
         0bbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750752346; x=1751357146;
        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=BBKazxvzJ8Fm94ZBi7O25USsSSV4tLiKTWTkxYJUPrs=;
        b=YoAPoodiIs1z5yCpNiq1zZLuFmAycEvty/m+IeSEap2vnAbjywkQNPfEcIzkr9x/9V
         Vpj7szM3IbgIPcaIDm7ymEGb/+YrxkcrQWJ6/8MhAnnxCWaUcuI3AZLeAftDW/U+gTE8
         hs2Yg1Zq7jnrnyvkEMGoMVkveh1iXO67mBbB0T6TeN39m0URJbkdF8PbY3dgV2WIhBKG
         P8bpcelUsWMP8RZQcEJp+PLMyZooxlSxvfajnPqE7szvKCwzixwMuXLS+mUhrRY04YMm
         PvT27QEqw9eUtCyrZsgafmOjHlP5RuPsoWhbHOhlstnT2/nZGudXdtP6I0/dlTh209T6
         L3yQ==
X-Forwarded-Encrypted: i=1; AJvYcCWz+WoEkxF42gg+PKQxDKj0/lGcAYm255UpqzXM5RVHhlUiKZcnhamzTvphfsIfIf4lXdDrzL4qjd8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxH38VLCNz7Tq/Cmrj+cvbGg/FkzNCu5pQByJiOkABYk1F6xnoD
	M43EBgUT3A9HiJCWyUFScz54IDAi6orku9QF29PVJya8C/1rFr0MdGpV5AYWdfXMGQ==
X-Gm-Gg: ASbGncvSv/tRzXbvU69nH3oynDeq42xkP9YtHGObQ0nCk1CjnIBRzecjun+mx85RJ1M
	N7uGgYIzIh9YvqrmB1eOlt3Yw1UEtfdh+/8pZK6Y3med2CWU9cDNIBcK9IgcMW3KwNg7Gsx3Fg4
	Ib6n7LmO3JkCLcszBFv/l4ckmuVA3JLw+MQVx8rhIx5ZLH6pNwIjshRhcxdIoyPi5YG7zC68gUk
	lHRvlP8lZWXzdlAhzp4UsrooBTNU3DkJ2ALQmaFkFkfjkDU3Q1vwLPbU3bVo4qAfn/kaM2UCGO8
	n18ycWvrjxxpC7GoGbbIgmyhnFFRjWIXxGgkTEawUhK4H6sHcd94ENwRfuHRLTukoi0FU/W5WEv
	pmmuxEYzUP1NvqDOEPmHJAdLJOz1MUDAwh8VZTTB5EBXCFaw=
X-Google-Smtp-Source: AGHT+IFNyP+CJTgUfZHZDIosdc6RJ5qDfxwe8oFudZ3DjzF+XqxjuOlUQ5VS7E5ePfEUc34h4PsVPQ==
X-Received: by 2002:a05:6000:2912:b0:3a4:fbd9:58e6 with SMTP id ffacd0b85a97d-3a6d12eb835mr10923314f8f.50.1750752346357;
        Tue, 24 Jun 2025 01:05:46 -0700 (PDT)
Message-ID: <5c4b186e-686e-4fc8-bcf1-854bc1f5ec8b@suse.com>
Date: Tue, 24 Jun 2025 10:05:36 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
To: "Chen, Jiqian" 
Cc: "Huang, Ray" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Andrew Cooper ,
 Anthony PERARD ,
 "Orzel, Michal" , Julien Grall ,
 Stefano Stabellini ,
 "xen-devel@lists.xenproject.org" 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-3-Jiqian.Chen@amd.com>
 <516a3adc-320d-46ce-b235-8ef91469abcf@suse.com>
 
 <227df6d3-a2c3-4576-bde9-d8057c378e7a@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 24.06.2025 10:02, Chen, Jiqian wrote:
> On 2025/6/20 14:38, Jan Beulich wrote:
>> On 19.06.2025 08:39, Chen, Jiqian wrote:
>>> On 2025/6/18 22:05, Jan Beulich wrote:
>>>> On 12.06.2025 11:29, Jiqian Chen wrote:
>>>>> --- a/xen/drivers/vpci/msix.c
>>>>> +++ b/xen/drivers/vpci/msix.c
>>>>> @@ -703,9 +703,13 @@ static int cf_check init_msix(struct pci_dev *pdev)
>>>>>      pdev->vpci->msix = msix;
>>>>>      list_add(&msix->next, &d->arch.hvm.msix_tables);
>>>>>  
>>>>> -    return 0;
>>>>> +    spin_lock(&pdev->vpci->lock);
>>>>> +    rc = vpci_make_msix_hole(pdev);
>>>>> +    spin_unlock(&pdev->vpci->lock);
>>>>
>>>> If you add a call to vpci_make_msix_hole() here, doesn't it need (or at
>>>> least want) removing somewhere else? Otherwise maybe a code comment is
>>>> warranted next to the new call site?
> Sorry, I misunderstood you in my last email.
> After here's change, it seems the call in modify_decoding() is redundant.
> What's your taste? Removing the call in modify_decoding() or adding a code comment?

I'd prefer the other call to be dropped if it's provably redundant. But Roger
has the final say here anyway.

>>> The removing operation in modify_bars() and vpci_deassign_device() is not enough?
>>
>> I fear I don't understand this reply of yours. Which suggests that the patch
>> description may want extending as to this part of the change.
>>
>>>>> @@ -29,9 +30,22 @@ typedef int vpci_register_init_t(struct pci_dev *dev);
>>>>>   */
>>>>>  #define VPCI_MAX_VIRT_DEV       (PCI_SLOT(~0) + 1)
>>>>>  
>>>>> -#define REGISTER_VPCI_INIT(x, p)                \
>>>>> -  static vpci_register_init_t *const x##_entry  \
>>>>> -               __used_section(".data.vpci." p) = (x)
>>>>> +#define REGISTER_VPCI_CAPABILITY(cap, finit, fclean, ext) \
>>>>> +    static const vpci_capability_t finit##_t = { \
>>>>> +        .id = (cap), \
>>>>> +        .init = (finit), \
>>>>> +        .cleanup = (fclean), \
>>>>> +        .is_ext = (ext), \
>>>>> +    }; \
>>>>> +    static const vpci_capability_t *const finit##_entry  \
>>>>> +        __used_section(".data.rel.ro.vpci") = &finit##_t
>>>>
>>>> Could you remind me why the extra level of indirection is necessary here?
>>>> That is, why can't .data.rel.ro.vpci be an array of vpci_capability_t?
>>> You mean I should change to be:
>>> #define REGISTER_VPCI_CAPABILITY(cap, finit, fclean, ext) \
>>>     static const vpci_capability_t finit##_t \
>>>         __used_section(".data.rel.ro.vpci") = { \
>>>         .id = (cap), \
>>>         .init = (finit), \
>>>         .cleanup = (fclean), \
>>>         .is_ext = (ext), \
>>>     }
>>>
>>> Right?
>>
>> Yes, subject to the earlier comments on the identifier choice.
> Got it.
> One more question, if change to be that, then how should I modify the definition of VPCI_ARRAY?
> Is POINTER_ALIGN still right?

Yes. The struct doesn't require bigger alignment afaics. (In fact in principle
no alignment should need specifying there, except that this would require
keeping the section separate in the final image. Which I don't think we want.)

> Since I encountered errors that the values of __start_vpci_array are not right when I use them in vpci_init_capabilities().

Details please.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 08:12:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 08:12:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023308.1399264 (Exim 4.92)
	(envelope-from )
	id 1uTyli-00030V-8V; Tue, 24 Jun 2025 08:12:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023308.1399264; Tue, 24 Jun 2025 08: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 1uTyli-00030O-4o; Tue, 24 Jun 2025 08:12:38 +0000
Received: by outflank-mailman (input) for mailman id 1023308;
 Tue, 24 Jun 2025 08: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 1uTylg-00030I-98
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 08:12:36 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20614.outbound.protection.outlook.com
 [2a01:111:f403:2417::614])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fbc4ec8e-50d2-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 10:12:34 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by BY5PR12MB4193.namprd12.prod.outlook.com (2603:10b6:a03:20c::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.25; Tue, 24 Jun
 2025 08:12: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%4]) with mapi id 15.20.8835.027; Tue, 24 Jun 2025
 08: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: fbc4ec8e-50d2-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=sH6I59s/sqPVCBHaHO/NCUswAG8SIV5IH9YAlQcgh+fpVo1hhBA8SlESuxGYjtSGs4HMxlvNT0ntjY46Cm3Jn+4ltIh5TkBWI/PGY5mxfXBBJAAXzQR3qvd6JxsIbX0jbSo6vttt+PE738Ne8SXz8T/drr+lypi/t0QmgrV7JcBwY2DGhr4g1UeewKYW4evMJPy/SlLa46FQaYGDqVDTxMasY4277usE5sKYZ6ppLZCfdMPsBDEO80R9k3E023+oYhsxiNpPuhraRqzFRtJlC6EM8wNuAyKmhAkME4SpBeVHJixFCNqrwoKbYROpHNNQtQdwMQMwT8jqyVzg+meLtA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=7aLn9ZAOzLv4vbwM704WJljDc9fj3fe48laNKV/vIk0=;
 b=CgY5ULCO8AkKV5BGj1MeEd5LZVGI3toWjZeDPq8kriICMIC2d23aeY+4RvGmKurxb6X4QfHoLvJ2d40QHcLtliwQOYUOXDDqH2/rPJ+WhgXyE2e0renMfqn1Tw1Zabf4fFjPaGpSm3kJLKKjVLUL7p7JtWZlIvCOfV+YcfpCoB972XDILe9zR7rWgBNzdcTXJ17ObYD9zzXpfEYJGYmVJM6UrxTF/iNXQtx2LK/19uWAyHPKJaroBdpJK8fuNUjswTiYbr9Nweiew2cdVxXsJEkaWfAkGpaZeaC4cIH/bc6Bprx3TpEyJTa5Vhc3bN2XiO6Uvvfk939yNnHuGq9Ijg==
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=7aLn9ZAOzLv4vbwM704WJljDc9fj3fe48laNKV/vIk0=;
 b=lJcUAPDFaIvl8GvMQRUYZuLHb/o4O0Dhj6d0ArkhIlUebha4Jm6eSfGj6UfNzmuUnIq3qWkgdSVVjf5/mVaovjSxEZplRUWqmyUDF1U+6MS/PapGz/RcyqGTXm7yHysjo1d1dy7UqwVTl2ys3F073hGuMUZEsM18noYHALbg+6U=
From: "Chen, Jiqian" 
To: Jan Beulich 
CC: "Huang, Ray" , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Andrew Cooper , Anthony
 PERARD , "Orzel, Michal" ,
	Julien Grall , Stefano Stabellini ,
	"xen-devel@lists.xenproject.org" , "Chen,
 Jiqian" 
Subject: Re: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
Thread-Topic: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
Thread-Index: AQHb23yakGdVC9XxvEWnYcnp8zrTt7QJBRKAgAGLVICAARN8gIAG6YaA
Date: Tue, 24 Jun 2025 08:12:30 +0000
Message-ID:
 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-3-Jiqian.Chen@amd.com>
 <1634c18d-e54e-4105-8b30-6f3085bace22@suse.com>
 
 <23293ec5-7466-400c-87a4-1482577b91fa@suse.com>
In-Reply-To: <23293ec5-7466-400c-87a4-1482577b91fa@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.8835.025)
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_|BY5PR12MB4193:EE_
x-ms-office365-filtering-correlation-id: 9ddacff2-c6f3-451b-0969-08ddb2f6ddb3
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?RGZUTFJickUyNHlwTngwTFJ3UHhaWjdncXNhRnRKMkpERmx6MVF6QVFqOUph?=
 =?utf-8?B?K2docmpXdFdVc1M3QnZENTdsb3hCVk9SMzFMRVFMWVhUYjArcVVjZ01FaUw3?=
 =?utf-8?B?WEFNSXZHd1c1bkN1bkh3YjZGNVJjM3hHSHlTWGMwM25NQkRESnViYkttVENC?=
 =?utf-8?B?OVh6ZUFYRGtKalp5RHBYRnhMc1dwU3VEZ2JKYnN1QnFiY0RvbC9iYS9tWmFn?=
 =?utf-8?B?SVJKTzluTHMycGxiK1ZZcFRhM3B6TzZhcVlVd2JRRFlHNG1IVUFZc1RzWGNz?=
 =?utf-8?B?TUlCSHhya0d6d3pUTzByZnJ4TFJ6Z1Q1bFNoY3NZbkY1S1hXYSsvbEUySEVD?=
 =?utf-8?B?bUN1TjRFcTVqRmtNb3liYXAyb01Sbis5WDIxRHpzMnNrbjhLdnZkVUJFQ2RY?=
 =?utf-8?B?REVrdmVtcnBOR2VwZG1wOURTR3Znc09KcExQaUJLSThiQ1lRRDViUTJjeHhJ?=
 =?utf-8?B?R0lXdTNZeThzNTlZclEwVlNFcWpsamdHekpMQ3Q1a0VVbHJMMnE5UlpNUEJa?=
 =?utf-8?B?aGNEdHYrTkx4NS9qeDYyRmRSVzRDNmd3cmRYbGRHVU5zVVdCanFBQ3ZBd1hh?=
 =?utf-8?B?MmtmMVd2WEk1Z1l0QjJWdVlXcGxkRlVHUVc3SVF0ZU5FZ0xzSXZrVHRzL2xs?=
 =?utf-8?B?THhqU3VmcGduZjdnK1R1a1F6eWtFNGZSRklTSkdBV01LNVlpY2FmbjdvZkkr?=
 =?utf-8?B?eWxmQzBuMS9WbkdyOXJDdXVXYXpSMzNaSE5tSnpUSndYK0tlcEZUKytjMU85?=
 =?utf-8?B?Z0NoUGN3TEN5bGIxcmM5NDVEci9pS09MV1pQL3VZamlJRVpJelVOeWh1YW1a?=
 =?utf-8?B?SHUvc3g0QXJoenJGZmY2WGp5blMwdTc2RmpVYkExTXJ1eGxmaExnQS9JUHhh?=
 =?utf-8?B?QzFzRjlGeFpYaCtUb1VwRlJHZDJ4MllsanRvZDFmRzJaUXVjZ1lkb3NMenBN?=
 =?utf-8?B?L3lWWEZtRHpCdTFCMGhlWm1oT200bitrWGlzVzNDRy91cmdvdTdONnZUbG9U?=
 =?utf-8?B?b2NiU25yOHdTeWxRb0QyaStIdGZRR2tqUXQyN3RqdXU3MG43c0xpN2dZcklD?=
 =?utf-8?B?Sm5pZk5uQWRqNjgyMnNDc2xVQVpsbjlwS2ZUUWl0WHFYejJQK3ZvUkc4U0hy?=
 =?utf-8?B?YUFRYUx4KzRlV1VpYk9zbUpUemVhVlQvakdmbEFIdzRFNGRDbCtlSzNmb21q?=
 =?utf-8?B?OWlQSktXb2YvT1hrMGRpUHZQK3FBTmtsamlVcTh3bUxUemtyVW81Nkg3YWJG?=
 =?utf-8?B?S1UrRWgxeXpuSldxdXIyWXpHanAxTVMyeUpNdDdzMmVkNGpLRjlHd1A3RFdr?=
 =?utf-8?B?YWVmdUd6WEVKZTh0NzJyYlhUT25rTFpiNHhlQk5QZVo5VllOSUNROWVPMURO?=
 =?utf-8?B?NXA5cnJnYTZ5aGp0amtVaXhCRkhWUERxOU9tdUNkWWhOU1ZENFJpMDRkZThU?=
 =?utf-8?B?QWs2cGlkVGRVTDU4RGdVNnJmbDBqdE1scHlrYlU5YmhxVWwrOUl6Qk43YkxC?=
 =?utf-8?B?czVPWTJobHpzUHA3YnlCOFVGRXhHNUYxZ21oeXdqeXNGamtBOVNZVzdsbE1t?=
 =?utf-8?B?NkFsVjA1cWhhNU93N2w1eEZrNHAxRXhmTFJpVGpsRFNoOFRhZURWRHZMRkJG?=
 =?utf-8?B?MFpOM01ON3pGd1FBdUtqYUNFc0R5aSs3VEFaOUJYNncrbStxa3VCalNZMVdD?=
 =?utf-8?B?RDgySmNyUjFVQmxWZUdwclp1UzRkRVRKWXE3WnFPWmJJV2NrMHFiVS9GVmRF?=
 =?utf-8?B?UTdFVWVaT2w4WFBHNi8wSTgrUEU3Qk9jRVg1dlVoQmIzSXJuTnVhWHd5eHFT?=
 =?utf-8?B?MWRnUmxEWTRvV2hMK0w3bG1IcW1ZYnRvNVlLVml6dTRjeTN1cnI2WUFWSWdy?=
 =?utf-8?B?c0E4K25NWFVVcW9xUkV0eXB3VGhXSlhRV2tuUG5BQWc5b0xMQ1FQN3AxQjVB?=
 =?utf-8?B?R0tsVnZxcDc3Z1lmMG50em02QUpTLzdOSnAxS3E4UTkyMm9KWFlUZU5PTG9X?=
 =?utf-8?Q?RQvIr0pUmO4iw3kEDwrV2zjvd2GDFI=3D?=
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?K2IzNmUvdm5pS2FodE0xVk83R1h6KzErOVBvY2dZOGQxaHh2aHdHUXl1dEd3?=
 =?utf-8?B?OFJBMmZRVmZyRUVGYy9VS3NmRFRUL24wdGFRRzhJNUpBYm9LYkNBNEQvVE93?=
 =?utf-8?B?Qk9KWmNSekFTK3BPNEdhNDh3aHpDV3o1Y3FFdTNPaUxMdmNzZU4yY25nNlpx?=
 =?utf-8?B?RE5wTzdMbUUzdm1kRlo2dEx4ejJQb2R0QnJXWElUOC9sdGJ0QnJtYlZXVEFT?=
 =?utf-8?B?cUp1RkRKNGQ4VzUzeWFoWlVlYW9SK1FDa0RNMG5TSm1TRnA5V1NJN0FCMkww?=
 =?utf-8?B?ZlFpUGZVS1Q0VkNMdkZRUGdUanJVV1JlbVJzOUxrSTIwN0FwTGpTSDV1SkRD?=
 =?utf-8?B?WlY4RzFidnE5U0NkeVpaZWM4S2Q1Z1dBOTczNmloTituZmp4Ni9haFlPc3Jz?=
 =?utf-8?B?L2tDUzVVYzZJSDdETG8yUkFMdjY1RjIrRng2VUV2QVhyVWZ2azA5c0ViMkR5?=
 =?utf-8?B?b3pUamZMOW54SnNvME96cEFrU05TT055SEFPSlhIRTNBWlpabGxjd3NBWFJC?=
 =?utf-8?B?b2pzWjFicm9mcmt0UWc2V2RJeXlBTDNzTk1GUi9kOG9URDhlNndUSjNnRTB6?=
 =?utf-8?B?WjVJdUpoMkZzb3lUa0c1eGpmN2JSK2kwTWl0MHFSZ3hVYWo1NHJHcTJHQjVV?=
 =?utf-8?B?d1k0QTBCcjFWSFpYemRpTTM1elZ6ZDR3U1QwVEhmR09lRHUySDRsYTV5NDJV?=
 =?utf-8?B?RU5nYXV1b2UxUmRGLzljeWtNVlJXUDNBZTQwOE80KzZ0a28vbnRPbnF4REVH?=
 =?utf-8?B?bWxqbmYwYmp1Rjc5RXorYzgrbHgzUndudzNhU1Q1TkIzR0loQVU1SFhrL0dR?=
 =?utf-8?B?aUc1V1VJdXU4OUdhZFZ4NGVGeFNFYTlMclRtM2Y5eC9FMHFCd0wzazFOZjIw?=
 =?utf-8?B?MC9BOS9id1JWWnh2Ym1DZmhiWnhub2lMQWlmdEFUM1pkSkpQcERtU0pmUVJK?=
 =?utf-8?B?d0RmbFdUZnVHK0xCVEh3bTZiTzFpaHlpZjNnL01QWDJrWEppM0p0dUpHYWQ4?=
 =?utf-8?B?Q3Z3RnNtNkFRMWdndHVMd1czSDRUYXdvZkJvbnIwZXM2MXQwYkNjd0xSSEhR?=
 =?utf-8?B?RGN3b2o0ZmZEbVpERG05K0RWK3pURTdVeHBlSVlKR2prNGxHNUV1QlMvS2I1?=
 =?utf-8?B?VFk5a2c2c1hGR0VKM21lNG1aS1R4bUxsRVV5QndKbmZJbXpFK2JlT0RGc3RZ?=
 =?utf-8?B?STVaVjh6WDhIRy96eGt0V0FYald3V3N2d2V0N2JxMWRQRmIraE5PRjUxVmwy?=
 =?utf-8?B?U0NzcnVjelBRV3ZDMkUrQnlXVVVkTGc5djcxTlpDMUhiTzBxb3V1aU5QNWM0?=
 =?utf-8?B?VEFxbE1jN0hweGI0NFVVcmFwREtaYWNvTXRRR3o2R2tzeEVTcjBCVXZkOHpw?=
 =?utf-8?B?eFlTd3dsS2ZFOTdtUFlYZXFBdE80LzVZektjYXkrZFR4eTlxK3ZvaGdvT2dE?=
 =?utf-8?B?L084eWxuWTU2cVhFU2VLMUxXUFo1TThveW40Y204NGhlTys3MkxKYUlZbk83?=
 =?utf-8?B?enVOY3liaExNZlVkRlZ6SHF6TWoxcWdvUTlhdy8yR3RDa00yOE1ZL1oyKzg4?=
 =?utf-8?B?cGMxY1d6TGdNRk9rcUxZZW54ejkwVmEwSFRLSkk2OFF6U1k2bzVpMEthVHp5?=
 =?utf-8?B?U0ZqbjcvdGpIUXVoSVA0U3pUUmxTbFhobFhxRGMzejRSR0ppbFNza1hLM2d1?=
 =?utf-8?B?UytlNUxST2svOVJCRkNvcGVQdnQrQWtsL1ZCNVVYc3JwaFpNU3Jya0FLYzd6?=
 =?utf-8?B?eitOVU1BKzlCSXZJUFR3Nkx1L212WmYrQnNyQ1ZmV2FTN0NkWElxNlBiR3Jl?=
 =?utf-8?B?eGFBbGFDNWw5VHUyalhuM1F5dUoxak9DY1FYQTMyMHRXdFhUeFZIckFpNURa?=
 =?utf-8?B?aUc1Z09WdmNZV3hNNksrelFVU3ZxUU1MUDg1RDJJZDFuNyszU0pjdm5yTTZK?=
 =?utf-8?B?aVN6VkVCWEh4c2w5TkdtOTB1dVgyU0tzRlJuaW0wL01FYWNIUEc2WnlmQ1VD?=
 =?utf-8?B?bFA4VGwwdDg4TGlDTHpDTHZ5YXNGZjdYMnFNdUlsY2V6ZFFsOGVhcDB3dVRK?=
 =?utf-8?B?YXpKTU1VU1RzTDhSY0phWnE1dFhOeUVqQ2crNDROTWh3cmN6cjBtRTE2NXhp?=
 =?utf-8?Q?+iSE=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: 9ddacff2-c6f3-451b-0969-08ddb2f6ddb3
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2025 08:12:30.7436
 (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: sP8goD9DdiDmu3RXUOlcbGJo9FmySDZF20459MUnyJ6OhOGgGkwgXaM9x1MT2vou4HEIbUJGdoaP4zE78OGbvw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4193

T24gMjAyNS82LzIwIDE0OjM0LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMTkuMDYuMjAyNSAw
ODoxNCwgQ2hlbiwgSmlxaWFuIHdyb3RlOg0KPj4gT24gMjAyNS82LzE4IDIyOjMzLCBKYW4gQmV1
bGljaCB3cm90ZToNCj4+PiBPbiAxMi4wNi4yMDI1IDExOjI5LCBKaXFpYW4gQ2hlbiB3cm90ZToN
Cj4+Pj4gLS0tIGEveGVuL2luY2x1ZGUveGVuL3ZwY2kuaA0KPj4+PiArKysgYi94ZW4vaW5jbHVk
ZS94ZW4vdnBjaS5oDQo+Pj4+IEBAIC0xMywxMSArMTMsMTIgQEAgdHlwZWRlZiB1aW50MzJfdCB2
cGNpX3JlYWRfdChjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldiwgdW5zaWduZWQgaW50IHJlZywN
Cj4+Pj4gIHR5cGVkZWYgdm9pZCB2cGNpX3dyaXRlX3QoY29uc3Qgc3RydWN0IHBjaV9kZXYgKnBk
ZXYsIHVuc2lnbmVkIGludCByZWcsDQo+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVp
bnQzMl90IHZhbCwgdm9pZCAqZGF0YSk7DQo+Pj4+ICANCj4+Pj4gLXR5cGVkZWYgaW50IHZwY2lf
cmVnaXN0ZXJfaW5pdF90KHN0cnVjdCBwY2lfZGV2ICpkZXYpOw0KPj4+PiAtDQo+Pj4+IC0jZGVm
aW5lIFZQQ0lfUFJJT1JJVFlfSElHSCAgICAgICIxIg0KPj4+PiAtI2RlZmluZSBWUENJX1BSSU9S
SVRZX01JRERMRSAgICAiNSINCj4+Pj4gLSNkZWZpbmUgVlBDSV9QUklPUklUWV9MT1cgICAgICAg
IjkiDQo+Pj4+ICt0eXBlZGVmIHN0cnVjdCB7DQo+Pj4+ICsgICAgdW5zaWduZWQgaW50IGlkOw0K
Pj4+PiArICAgIGJvb2wgaXNfZXh0Ow0KPj4+PiArICAgIGludCAoKmluaXQpKHN0cnVjdCBwY2lf
ZGV2ICpwZGV2KTsNCj4+Pj4gKyAgICBpbnQgKCpjbGVhbnVwKShzdHJ1Y3QgcGNpX2RldiAqcGRl
dik7DQo+Pj4NCj4+PiBJcyBjb25zdCByZWFsbHkgbm90IHBvc3NpYmxlIHRvIGFkZCB0byBhdCBs
ZWFzdCBvbmUgb2YgdGhlc2UgdHdvPw0KPj4gV2lsbCBjaGFuZ2UgdG8gYmUgOg0KPj4NCj4+IHR5
cGVkZWYgc3RydWN0IHsNCj4+ICAgICB1bnNpZ25lZCBpbnQgaWQ7DQo+PiAgICAgYm9vbCBpc19l
eHQ7DQo+PiAgICAgaW50ICgqIGNvbnN0IGluaXQpKHN0cnVjdCBwY2lfZGV2ICpwZGV2KTsNCj4+
ICAgICBpbnQgKCogY29uc3QgY2xlYW51cCkoc3RydWN0IHBjaV9kZXYgKnBkZXYpOw0KPj4gfSB2
cGNpX2NhcGFiaWxpdHlfdDsNCj4gDQo+IEVobSwgbm8uIFRoZSBxdWVzdGlvbiB3YXMgZm9yIHRo
ZSB0d28gZnVuY3Rpb24gKHBvaW50ZXIpIHBhcmFtZXRlcnMuICJjb25zdCINCj4gb24gc3RydWN0
IGZpZWxkcyB0aGVtc2VsdmVzIGNhbiBiZSB1c2VmdWwsIHRvbywgYnV0IGZvciBhbiBlbnRpcmVs
eSBkaWZmZXJlbnQNCj4gcHVycG9zZS4NCk9LLCB3aWxsIGFkZCBjb25zdCBib3RoIGZvciB0aGUg
c3RydWN0IGZpZWxkIGFuZCB0aGUgZnVuY3Rpb24gcGFyYW1ldGVycy4NCg0KPiANCj4+Pj4gK30g
dnBjaV9jYXBhYmlsaXR5X3Q7DQo+Pj4NCj4+PiBBcyB5b3UgaGF2ZSBpdCBoZXJlLCAuLi4NCj4+
Pg0KPj4+PiBAQCAtMjksOSArMzAsMjIgQEAgdHlwZWRlZiBpbnQgdnBjaV9yZWdpc3Rlcl9pbml0
X3Qoc3RydWN0IHBjaV9kZXYgKmRldik7DQo+Pj4+ICAgKi8NCj4+Pj4gICNkZWZpbmUgVlBDSV9N
QVhfVklSVF9ERVYgICAgICAgKFBDSV9TTE9UKH4wKSArIDEpDQo+Pj4+ICANCj4+Pj4gLSNkZWZp
bmUgUkVHSVNURVJfVlBDSV9JTklUKHgsIHApICAgICAgICAgICAgICAgIFwNCj4+Pj4gLSAgc3Rh
dGljIHZwY2lfcmVnaXN0ZXJfaW5pdF90ICpjb25zdCB4IyNfZW50cnkgIFwNCj4+Pj4gLSAgICAg
ICAgICAgICAgIF9fdXNlZF9zZWN0aW9uKCIuZGF0YS52cGNpLiIgcCkgPSAoeCkNCj4+Pj4gKyNk
ZWZpbmUgUkVHSVNURVJfVlBDSV9DQVBBQklMSVRZKGNhcCwgZmluaXQsIGZjbGVhbiwgZXh0KSBc
DQo+Pj4+ICsgICAgc3RhdGljIGNvbnN0IHZwY2lfY2FwYWJpbGl0eV90IGZpbml0IyNfdCA9IHsg
XA0KPj4+DQo+Pj4gLi4uIF90IHN1ZmZpeGVzIGdlbmVyYWxseSBkZXNpZ25hdGUgdHlwZXMuIEkg
ZG9uJ3QgdGhpbmsgd2Ugc2hvdWxkIGFidXNlDQo+Pj4gdGhhdCBzdWZmaXggZm9yIGFuIGlkZW50
aWZpZXIgb2YgYSB2YXJpYWJsZS4NCj4+IFdoYXQgZG8geW91IHRoaW5rIEkgc2hvdWxkIGNoYW5n
ZSB0bz8NCj4gDQo+IFdlbGwsIGlmIHlvdSB0YWtlIG15IG90aGVyIGFkdmljZSwgdGhpcyBxdWVz
dGlvbiB3b24ndCBuZWVkIGFuc3dlcmluZywgYXMNCj4gdGhlbiB5b3Ugb25seSBuZWVkIHRoZSAu
Li5fZW50cnkgb25lLg0KPiANCj4gQnR3LCBub3RpY2luZyBvbmx5IG5vdyAtIHdoeSBpcyBpdCBm
aW5pdCB0aGF0J3MgdXNlZCB0byBkZXJpdmUgdGhlIGlkZW50aWZpZXI/DQo+IFdpdGggdGhhdCwg
aXQgY291bGQgYXMgd2VsbCBiZSBmY2xlYW4gKGxlYXZpbmcgYXNpZGUgdGhlIGZhY3QgdGhhdCB0
aGF0J3MNCj4gb3B0aW9uYWwpLiBJbW8gdGhlIG5hbWUgd291bGQgYmV0dGVyIGJlIGRlcml2ZWQg
ZnJvbSBjYXAsIGFuZCBpdCB3b3VsZCBiZXR0ZXINCj4gYWxzbyByZWZsZWN0IHRoZSBwdXJwb3Nl
IG9mIHRoZSB2YXJpYWJsZS4NCkkgY29uc2lkZXJlZCB0aGlzLg0KSSB0aGluayBpdCBpcyBlYXNp
ZXIgdG8gdXNlIGZpbml0LCBhbmQgZmluaXQgY29udGFpbnMgdGhlIGNhcCB0eXBlLCBhbmQgdGhl
IG1haW4gcHVycG9zZSBvZiB0aGlzIHN0cnVjdCBpcyB0byBpbml0aWFsaXplIHRoZSBjYXAuDQoN
Cj4gDQo+IEphbg0KDQotLSANCkJlc3QgcmVnYXJkcywNCkppcWlhbiBDaGVuLg0K


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 08:17:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 08:17:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023319.1399273 (Exim 4.92)
	(envelope-from )
	id 1uTyqG-0004W8-Tg; Tue, 24 Jun 2025 08:17:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023319.1399273; Tue, 24 Jun 2025 08:17:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTyqG-0004W1-R6; Tue, 24 Jun 2025 08:17:20 +0000
Received: by outflank-mailman (input) for mailman id 1023319;
 Tue, 24 Jun 2025 08:17: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 1uTyqF-0004Vv-VC
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 08:17:19 +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 a4066c6f-50d3-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 10:17:17 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a57c8e247cso4019755f8f.1
 for ; Tue, 24 Jun 2025 01:17:17 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b31f118ecb2sm8352085a12.11.2025.06.24.01.17.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 01:17:15 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a4066c6f-50d3-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750753036; x=1751357836; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=YUpQR/bJOCZY0Vm4bTJ8ikZCpvMZ1XskOwbLdpJ+kQo=;
        b=F2hB2mH+U5sEBD3jBv6o00fc6sfWc6Cwul9Z/APYabRx6Z19vRSpgffPi1uhm8kFbR
         0tZ0nOpWklSJlNBR+DzNdL+Sq7vlENSeLwkehBFz8YySOIlS+LQE/spJpEwNb0fLzzhy
         dQ1VbRP98cNtufxuJKYKqHH+VFebZyE2UYzVYYYtETt6C6B1lMIjcfx1ZDMC7PlH4aZf
         DxT6bbfZh9UDaIW1PBOxlxxu4WCxJZS7AIrd1dN90XeVcRZM4Ag7DwescLhQ+qedR53/
         5vuh0yWTSGJK10j/SyZJuqnW3bOijfJmK56IuhmFhbYwGtCEc5ALIZTS49FM2TgIUW5o
         Y0nA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750753036; x=1751357836;
        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=YUpQR/bJOCZY0Vm4bTJ8ikZCpvMZ1XskOwbLdpJ+kQo=;
        b=RAvWdRgag5bbVZtAEERGwfGDl0f2r2LCOYPJRZ/mgeb5w51CWwHPURKWEPQM/uM8Ri
         q0H1Gb946Vvh+xoyUjMcXm7CpRer+/76kdmMO2puyQqoFjfq1NxILurlTKRiawP+R2so
         EdcP4x787Rp176d656ML+8ZJJ15nHcsMf+upkNNag2PyYPX3Qsup1nZi791KK1DdPz3D
         J/29dGC3tNzRMpXznL8m+keS3ZiSQEe6eBOeu4sA2st2vTLkDsUjg9jj2aPrrMoMpgj8
         V5H5ZxPw/FMvq74bFGDigPRp8MEAA8XWC5kC/bCVGC/3Zpw/FVCkCak77EkVazQN7BId
         6Jkw==
X-Forwarded-Encrypted: i=1; AJvYcCXfptIVU/RDXsAfkxQws6QwnpdwizTmEbpza2VobEigDHIApGsQJjrKPpl+NNpMDi1wKYxzfPwdnNE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzPg6qkKmjgdgw6J88E8Ww60DjmBCuBejuv+y02sz2SYwqpix9E
	qISeA+he/nIccjAPgJ5bu5BHZt/sftNd1Yqo+BsVuxkalr1+fp1+2/iol1UCCHKKQQ==
X-Gm-Gg: ASbGncvplXrt0tWCB0kwVjCFKoqmVLvbzKHF+FGTK9wiIGwltFDzH0/TGb3jGKyyPXz
	82RLaIgh4yteKJQDcoX0bejvM2aNMwf1i7wtXeOrNsH29ncZqHS7z+kBVzzT09Bf6zIAoTkRV6f
	4HYBzlaL8RHf8H921y38djNvVuYESVabPhgMhJLuFQyzUaVcgmg35juxA8/8TR7Iw08NxBBvKRq
	YDb7QG0oov22+kwpNHi/mzq/rXzFxZwPr1Si/csyQ5zmyl8eOy7bD9kZjnIhvKyd7P+tg8K8psu
	cDBcnk0IGAh0qTSHeMZ2PGxVjTZ9ogHj6egDvMq7zseOhtdBMmtK/pseZ1i7ylr8tgSkf51wN2u
	twodCjb5YrTRfwlSKTJhLEvq35+7iDP9OJ96c4TyJty2szvQ=
X-Google-Smtp-Source: AGHT+IFJ9yILQos1QLPUn6F6CddKlkR/cizG51ooi580OJ2CjYbYk9+09rD3G4k15g0d2fBAh7Jnog==
X-Received: by 2002:a05:6000:2908:b0:3a4:dd16:b287 with SMTP id ffacd0b85a97d-3a6d12e903fmr12734398f8f.19.1750753036388;
        Tue, 24 Jun 2025 01:17:16 -0700 (PDT)
Message-ID: <0cf4679d-ee86-4666-adae-63a3f9b9b8f7@suse.com>
Date: Tue, 24 Jun 2025 10:17:06 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
To: "Chen, Jiqian" 
Cc: "Huang, Ray" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Andrew Cooper ,
 Anthony PERARD ,
 "Orzel, Michal" , Julien Grall ,
 Stefano Stabellini ,
 "xen-devel@lists.xenproject.org" 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-3-Jiqian.Chen@amd.com>
 <1634c18d-e54e-4105-8b30-6f3085bace22@suse.com>
 
 <23293ec5-7466-400c-87a4-1482577b91fa@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 24.06.2025 10:12, Chen, Jiqian wrote:
> On 2025/6/20 14:34, Jan Beulich wrote:
>> On 19.06.2025 08:14, Chen, Jiqian wrote:
>>> On 2025/6/18 22:33, Jan Beulich wrote:
>>>> On 12.06.2025 11:29, Jiqian Chen wrote:
>>>>> --- a/xen/include/xen/vpci.h
>>>>> +++ b/xen/include/xen/vpci.h
>>>>> @@ -13,11 +13,12 @@ typedef uint32_t vpci_read_t(const struct pci_dev *pdev, unsigned int reg,
>>>>>  typedef void vpci_write_t(const struct pci_dev *pdev, unsigned int reg,
>>>>>                            uint32_t val, void *data);
>>>>>  
>>>>> -typedef int vpci_register_init_t(struct pci_dev *dev);
>>>>> -
>>>>> -#define VPCI_PRIORITY_HIGH      "1"
>>>>> -#define VPCI_PRIORITY_MIDDLE    "5"
>>>>> -#define VPCI_PRIORITY_LOW       "9"
>>>>> +typedef struct {
>>>>> +    unsigned int id;
>>>>> +    bool is_ext;
>>>>> +    int (*init)(struct pci_dev *pdev);
>>>>> +    int (*cleanup)(struct pci_dev *pdev);
>>>>
>>>> Is const really not possible to add to at least one of these two?
>>> Will change to be :
>>>
>>> typedef struct {
>>>     unsigned int id;
>>>     bool is_ext;
>>>     int (* const init)(struct pci_dev *pdev);
>>>     int (* const cleanup)(struct pci_dev *pdev);
>>> } vpci_capability_t;
>>
>> Ehm, no. The question was for the two function (pointer) parameters. "const"
>> on struct fields themselves can be useful, too, but for an entirely different
>> purpose.
> OK, will add const both for the struct field and the function parameters.

If you add (or rather keep) const for the struct field, the next question is
going to be why the other fields don't have const. Imo it's only the function
parameters which want it.

>>>>> +} vpci_capability_t;
>>>>
>>>> As you have it here, ...
>>>>
>>>>> @@ -29,9 +30,22 @@ typedef int vpci_register_init_t(struct pci_dev *dev);
>>>>>   */
>>>>>  #define VPCI_MAX_VIRT_DEV       (PCI_SLOT(~0) + 1)
>>>>>  
>>>>> -#define REGISTER_VPCI_INIT(x, p)                \
>>>>> -  static vpci_register_init_t *const x##_entry  \
>>>>> -               __used_section(".data.vpci." p) = (x)
>>>>> +#define REGISTER_VPCI_CAPABILITY(cap, finit, fclean, ext) \
>>>>> +    static const vpci_capability_t finit##_t = { \
>>>>
>>>> ... _t suffixes generally designate types. I don't think we should abuse
>>>> that suffix for an identifier of a variable.
>>> What do you think I should change to?
>>
>> Well, if you take my other advice, this question won't need answering, as
>> then you only need the ..._entry one.
>>
>> Btw, noticing only now - why is it finit that's used to derive the identifier?
>> With that, it could as well be fclean (leaving aside the fact that that's
>> optional). Imo the name would better be derived from cap, and it would better
>> also reflect the purpose of the variable.
> I considered this.
> I think it is easier to use finit, and finit contains the cap type, and the main purpose of this struct is to initialize the cap.

Yet identifier names should make sense for the object they name.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 08:26:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 08:26:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023326.1399283 (Exim 4.92)
	(envelope-from )
	id 1uTyyy-00070A-Ko; Tue, 24 Jun 2025 08:26:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023326.1399283; Tue, 24 Jun 2025 08:26:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTyyy-000703-I9; Tue, 24 Jun 2025 08:26:20 +0000
Received: by outflank-mailman (input) for mailman id 1023326;
 Tue, 24 Jun 2025 08:26: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 1uTyyx-0006zx-0k
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 08:26:19 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on2062e.outbound.protection.outlook.com
 [2a01:111:f403:2415::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e55ff4ee-50d4-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 10:26:17 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by PH0PR12MB8821.namprd12.prod.outlook.com (2603:10b6:510:28d::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.29; Tue, 24 Jun
 2025 08:26: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%4]) with mapi id 15.20.8835.027; Tue, 24 Jun 2025
 08:26: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: e55ff4ee-50d4-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=YTTVOSHgMwvsQXr0Z08MbG7pvezw1xPqnd+6I/ngXH7pbYwyoIhhJDqKfjtx413uuipElVZiCh7Tt8socCgyUT3jyu1lISmjRHrv2l+SRN2sm0j04FfukpCivrcR7+l1SgAA5/5XDY+XhcVsixs3q+FZcLte4upodfCyj34s1fLZfbWHCt+DfQovmU+iSUAnlRlPPCX2KwtRwXVh4lqXhJwkit4iRRwimHeWDCU2xw9HIoXX33/PChCIBwUy5yJs4Kmwl4xaDAYmBgHgxvMR48UiHOqRSNqjtG1HHeqdGE049r7FfUkQI23UEI3NxkeRba3Ib7HfL7WxaVrsz2tzMw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=anfg4A4LmDbPyHGb92dMccahIpthqHOWJucw9sU+Ka4=;
 b=i3t7rc0sl4LYSKwCaPjvCDjcQyh6lIoh7n106Q5DOJWxH1pR1vMi2ba7B7Ld4dMhsD2EkajfMthHDLEdJagHxm9YQJiAxLNGFSDTl/HrTiin6WTikeDWwdFw27Ne0XLWNfi0vbT2jpF3RWee4FmIEe/rYBp9zIRXsJFmZomaZ+d5wO2PC/BHSSSbz/8Qd9VP1DV+ATA+2vw3XyRHnE2WlitanZ3O4YU/P0uD16aRpp2QE3j8wnGl8/6TemAH6YQGZ79Fe+VN2ofm4vbUT+DXkLOgD5ZaiosxnKMSxRbzpyeTzPjUZDb/rlqKlPZEr6O8yGUSXX/I/xvBPFIrUtMaBg==
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=anfg4A4LmDbPyHGb92dMccahIpthqHOWJucw9sU+Ka4=;
 b=1zsPshMjQ4LN5480ZAacCKe2LXuoQ85F7xV0Tx0zDk5bZFBCQFIBI1JubuC+F/z1hiqZ7ou/qrhD5QaXv2fZPjZ4fw2lfyfNHR3qI0CKaXmmMi9ZWBf3Tn9GSYohxKJsW3/3LAn3R2ssZHVTOWRpW1OubHKZkBO6iPBouNDOwdY=
From: "Chen, Jiqian" 
To: Jan Beulich 
CC: "Huang, Ray" , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Andrew Cooper , Anthony
 PERARD , "Orzel, Michal" ,
	Julien Grall , Stefano Stabellini ,
	"xen-devel@lists.xenproject.org" , "Chen,
 Jiqian" 
Subject: Re: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
Thread-Topic: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
Thread-Index:
 AQHb23yakGdVC9XxvEWnYcnp8zrTt7QJBRKAgAGLVICAARN8gIAG6YaA//98XQCAAIcUAA==
Date: Tue, 24 Jun 2025 08:26:13 +0000
Message-ID:
 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-3-Jiqian.Chen@amd.com>
 <1634c18d-e54e-4105-8b30-6f3085bace22@suse.com>
 
 <23293ec5-7466-400c-87a4-1482577b91fa@suse.com>
 
 <0cf4679d-ee86-4666-adae-63a3f9b9b8f7@suse.com>
In-Reply-To: <0cf4679d-ee86-4666-adae-63a3f9b9b8f7@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.8835.025)
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_|PH0PR12MB8821:EE_
x-ms-office365-filtering-correlation-id: d3209c1c-b68f-4a9e-9959-08ddb2f8c80e
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?VSs3UmJvcXpQZ3VvR3NUWjhxTHdld3U5SUM4YUxpdGdFQWhmYUFkQjIrSFIw?=
 =?utf-8?B?Tm5BbG1SenVibkh0QUJNNlpTTE16Q0FxYitWbHVzUnBTSmJkNnVPSUlHbXg4?=
 =?utf-8?B?eWt4VmdycHdUZEU1QWFrZlJmWWdCU0haYk90cWp2L3VsYmxMOFVnbE1NTlo5?=
 =?utf-8?B?VDhoS3pCVmZLc0lCZEJ1YUQ5WitLSit2Sk5lWjhtdHFFOGNIeGlZZ2ZPZFJi?=
 =?utf-8?B?ZG1saXhqQjlTK1c0R2xZeHpncVFJdkwyUVZBZVJhd2Yzb20vNEM4c0hycG4w?=
 =?utf-8?B?ektPR0htVDNMN1k5dUVROGN4UkFoakdNSXhKbmgzcjMxV1Z4ZjloUDhJNXo0?=
 =?utf-8?B?YW5LUmNTYjE1T2tyUFcvZlk4RE9iVklzYmxSRTNhcWZ2Wk1pUDhYa2pOUXdI?=
 =?utf-8?B?SDFNOWt4RmZtQ3lybVpTMlh2cWVTdEFYTnJVOVk5TDBXbG1TOHRrWmVoM2ln?=
 =?utf-8?B?cldYU2xtQm1jZHRZQ3NuRWRtUVNHWC9zR3l6dFYyc3RhZWxOSjkzUkRyeXpu?=
 =?utf-8?B?RVJydE9PSmlCMXhqUlVpbEFOVFJTTTF3dyttRUdNdmlVVHdHOUNHdGZWZito?=
 =?utf-8?B?RkJ6bnR5d0hGQkFFT1hUUi9LcHZSUEdVT1BPYXZ5dktZdkNqRkFQRGV5SHFU?=
 =?utf-8?B?dGd2OWYvd3Vvb210WTd1RXBxQ1QyckloVnRmQTNHS3pWaG1NS1JudTVGZUNs?=
 =?utf-8?B?NXFTWFZZR1h6NExqVFlZdnRWK0ZZNUN1QVF5V0Y2eU4zaExIZmNKNzhDSU5i?=
 =?utf-8?B?eWtFOGdlSm1uTTFkVDI4MWtDZnVVelIvUmRzdHIxVlgrTVR2aDNZL0ZNVTFx?=
 =?utf-8?B?SWFtSjRrUlFRa2dPdFNWM1hsVldMUkdpdkRCb0NPaU94d3VjUklWQ1VFbE5n?=
 =?utf-8?B?TmN4NU5RS2pUUFpXcFBuM3ZoNFZKMzdBRFd6bVIzM0lnalJOVE1HeGVxYXZr?=
 =?utf-8?B?c29VRVdxemc4QktsQW14dzVHTW5YNjNpa0tsVEpJdDVnRTNpRlJQeVJJbkFa?=
 =?utf-8?B?a0RRWTJYbkFJa0s2TWVzWTUwT05jZjgyRSs0bWNRQzRwSlZyaDY4dDJNU05v?=
 =?utf-8?B?cXN1ZTE3ekwxZHF5UTVGYVpaVytnN1hnK2x6YTEzOXdmOFZ3TXNzOUF6aEN1?=
 =?utf-8?B?dE42K1p4WDJzNnUrbHZHNko4L3lqMXZyWDFKVmdPZG44QkR3Y3FiLzRxbzJs?=
 =?utf-8?B?YTdtRkdHZUhGcUNBaWNpRzMxMDdhVjQ0UmZQSW83NWplSWJUUmlDR3o0T2VR?=
 =?utf-8?B?M2lOT1RmR003VVNqSTRpTkxjamJPTWk1V1phQlB5aFJxVVRoWFFOQ1BsbHBw?=
 =?utf-8?B?aGxFSGp1TXo2TWlkck45bzF5SURQNkliVER1ZXB4YXEzN0tPS1VJR0luUXNx?=
 =?utf-8?B?bGRSdElNbHdINkdWWmdrRE1YQ0FZV0pHdlJDQWRJU1VkeVRSMm5lU2FhRDZq?=
 =?utf-8?B?b1pDaEtzTjViRkVTb1djTDNMRWs2RmhUQ1VBTW5ZUDM5RlI5THA5SDhRSU9N?=
 =?utf-8?B?T0YrcUxwcjhpVXdDQzNtb1crUHJ5Q1dUNlY2aTVvSmJOZlErLzZ2Zk50SHFZ?=
 =?utf-8?B?ZUxjSWt5MmlyVGxrQ1BnS0YxOUtJTkVWd3A5U3JHU3hXdzZEc2JFcXhIc2th?=
 =?utf-8?B?RUhQUnNnQkJkV3BWajlvMDhBWmxURnI0RzZLeU1CSEpXNTdFUDA4Y1NOYVJW?=
 =?utf-8?B?SVRGditvbzFYY2VDL1llSEptR294aUlXVC9XWlh6d0xUeFBvM0lVSEZVTmpi?=
 =?utf-8?B?Y25lRnl5K1dBaC9PZFpxakc1U2xRUEpGcFhlYklUM1lXOS8weHRWNmpxVUty?=
 =?utf-8?B?SjI2L0VZTCtpNDhuOFUzeGVPSE1YcW02MldJS1U0MHA4VCtBVDhyUXpvb2Q1?=
 =?utf-8?B?NmhYU0FsQlBWMTFvNEVkMHRKUi9xRmF1aUpzN1dxRS9TTEQzRHRVSXRBVk9L?=
 =?utf-8?B?c0RBUGlzbVhNRFV3WVJmS2czcXVRWktSampwQnoyVzZ6QndMcUI2QjRDeCtH?=
 =?utf-8?Q?6ZIMEjhjQgoeulTRoMgJhfYXhnzmVg=3D?=
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?Z0ZHVC9sREY1QlEwUmlMdUFWZThPUWlNd1FBZU5kQ1dZMlEzTXhsdis2SDRk?=
 =?utf-8?B?OXppS2lGYXZ3NGFSbGN4SWlXZExBNkpnbW1LaXRBMEhUWGhBb3VUWU1IK2s2?=
 =?utf-8?B?WEdnSnpRN0hIZWhsVjUrRE1ha2ZlcmpTZDZueEhVUXQwQUYwSENEUlBSSHFG?=
 =?utf-8?B?WFhFbTJuSFNBb2NjOEVkVDVuVitRSU1wNlZidU1xdE5GRjdFcWhRUU85d2Y5?=
 =?utf-8?B?aEhLV0FHZ2MrU21tdjlqZnhlRE5QWHpMOEdCbWtiNXpONkIrdXllTGlneVk3?=
 =?utf-8?B?MCtBTmtUTi84bFNnZkx0UG9CYnVsUkZWalF6eTZualJQcDJiVHRDbUJXbXFy?=
 =?utf-8?B?Vk9CcUFrZmdWWHNoeHdveGYrVVZ6VzZpOUw5TjY5T2Q5WnVKdGJIdEI0YXcx?=
 =?utf-8?B?S08yVy9xTlhJUG1aQ1pBSkdNZFhWRnd3bUZXNzVsckZlTFZleEgwSU1NaWFJ?=
 =?utf-8?B?Z1JBUUw0M3VkUDU2TXU1am12TzUrZzBySmtFWDU4VWtoS1Y2ZEtjNkdpeFJQ?=
 =?utf-8?B?UFZxS3psMGxjUEtpb0J3ODJRU3E1N25xTVJkUFB0aVRPb210RTZ0YW9jWFpt?=
 =?utf-8?B?dnZTdXNxVXlHZ0NtSU80R2R4WndOWklTWXFsWEdOTGpjZ2tZOVVCS3BzK3Vm?=
 =?utf-8?B?Qm9rWGt2TzJCNTZ4SndCRWVVYlh5a2xGYzJoNkRuOG9UV3Q0Z3FGUjRtVVJo?=
 =?utf-8?B?eEExZFlFQkxwaWEyRHVCQXEyaGZjNHF1OUd4TWtMZVIrOTl1RUhXSDVNMXBV?=
 =?utf-8?B?K0dnYUhTTlorQndYNnBIdHRha2djRTNoQnBiZGo1RkNBbGVid3VrMUtkMzA3?=
 =?utf-8?B?eXZQZnlGTE5WN3NiZyttVlRCelMvZEJUR1lxQ0F0cVdjMzRxOHlGcVR2TDVI?=
 =?utf-8?B?OG1uZjI3dnNOd3cvOFRqbGJ6TEwvdUc0SjM3bUhMR09BaUkvUnNMa3JreStP?=
 =?utf-8?B?TFY2T2NxWjRzMFBRdjBHeC94Y2w2Y3hCNWF4anVGUy9tckZicHRxc0haRWtv?=
 =?utf-8?B?YTFSVHp5S2xsQVRGZGh0ZEhxVklJc252VzkzT3FHVjhBVVJPMlVPN1RKUHVG?=
 =?utf-8?B?eTJqbFFOSW5RbXBIS1hadGRwMllVRjJwUG9VdHdPQzRjVzI0MGx0eGtBci9X?=
 =?utf-8?B?MEFoR1p5U0dFc01DYUNwNnByNTJLS0N1bG82MWQ0SGZHdmt3ZmZhVWZQa0x0?=
 =?utf-8?B?UFZ6dnJSaEVDOWJUTjhidUxtTk9pVkhOM25vTGEyOXRENkp6MmxrNGxmQTlY?=
 =?utf-8?B?NUViT3YxaDIvN1ZLOEsrREhXZE1DdlRRMkVOSXAxUG9pOS9aVXhhTVBJNzI0?=
 =?utf-8?B?aHhpSjl3ZG8valVwZFdtUkNOdlRXRjcvYUM2SDVHbzkrWTFqQzBOcGY2VEo1?=
 =?utf-8?B?eEtOL3hPcmhybHhLSHZJQnp0clJaazk2UUYrSVgxbEp0Vkl0eUtZN3B0YlZo?=
 =?utf-8?B?WmJCVS9aN1FacUhYOVVBZFQwNHdzQjAvNlVrQmxtRUkwMWptNEZsaVpQZjRx?=
 =?utf-8?B?ZUhPUEZvdGNFTFc4Mjd3eVROU2paZHlsUUNpOURWK3hMVWJEWnplYVRPQkY5?=
 =?utf-8?B?Y0hDd21JeGszR1R3YVphMkp2UnlhVG5VUDdOS3FOdkQwZWV2bW1wOW1DNDdz?=
 =?utf-8?B?VXNsUEF5ZHRtU3o2MnZkNkNOTXRKWnVIdG52UTVPTElaK09CRk9NRjd1c3ZK?=
 =?utf-8?B?YlZ0Vy9ZVnVndGRZcWxPdW9kd1AvODBaZnRqaENSSU81eUVPWW5UYlBCVVo0?=
 =?utf-8?B?dG5nc2xmaGQrK0Z0SjhKV21aQ1dGbzIyRXRUWGdaR3dDTWZhUWwrMFM5QnhW?=
 =?utf-8?B?UDgzTit5ZGRlOWtHQ3VFTmJEc1J0R3JCVG5Qd0VwU1VkRFAzVS8ybk9ZcCtr?=
 =?utf-8?B?RlMzSXhYa21QU2lsWEROY3d1ZVd5bHhvYVhrMURyM2JlOGVNblRiRDhPMHZl?=
 =?utf-8?B?V2FsRHQrMjhBMEZ3ZldYaGNDMTZqL0FYd0g0SXI4R2VUMTBURmh0WGgzWEVV?=
 =?utf-8?B?TzlZbk9TS1lkeDBLYVN4VDNiLzdLQndLdThSV1FGL0MxR3RlZFh2cjVkajZ0?=
 =?utf-8?B?b0R3UEVrdGg4U0lFTzRaMWdrYzZuRGIrTzUyMnp2MysxWWhXK3dKaytycEFR?=
 =?utf-8?Q?R1ag=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: d3209c1c-b68f-4a9e-9959-08ddb2f8c80e
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2025 08:26:13.4203
 (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: CK8q9z8R9IQfnf3msEVTsazdVHGQidAshuZD8A7AYBqJ0pNu1vLGryCqQTbF9VlegIQLb9/tziYzoL89Fsyimg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB8821

T24gMjAyNS82LzI0IDE2OjE3LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMjQuMDYuMjAyNSAx
MDoxMiwgQ2hlbiwgSmlxaWFuIHdyb3RlOg0KPj4gT24gMjAyNS82LzIwIDE0OjM0LCBKYW4gQmV1
bGljaCB3cm90ZToNCj4+PiBPbiAxOS4wNi4yMDI1IDA4OjE0LCBDaGVuLCBKaXFpYW4gd3JvdGU6
DQo+Pj4+IE9uIDIwMjUvNi8xOCAyMjozMywgSmFuIEJldWxpY2ggd3JvdGU6DQo+Pj4+PiBPbiAx
Mi4wNi4yMDI1IDExOjI5LCBKaXFpYW4gQ2hlbiB3cm90ZToNCj4+Pj4+PiAtLS0gYS94ZW4vaW5j
bHVkZS94ZW4vdnBjaS5oDQo+Pj4+Pj4gKysrIGIveGVuL2luY2x1ZGUveGVuL3ZwY2kuaA0KPj4+
Pj4+IEBAIC0xMywxMSArMTMsMTIgQEAgdHlwZWRlZiB1aW50MzJfdCB2cGNpX3JlYWRfdChjb25z
dCBzdHJ1Y3QgcGNpX2RldiAqcGRldiwgdW5zaWduZWQgaW50IHJlZywNCj4+Pj4+PiAgdHlwZWRl
ZiB2b2lkIHZwY2lfd3JpdGVfdChjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldiwgdW5zaWduZWQg
aW50IHJlZywNCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCB2YWws
IHZvaWQgKmRhdGEpOw0KPj4+Pj4+ICANCj4+Pj4+PiAtdHlwZWRlZiBpbnQgdnBjaV9yZWdpc3Rl
cl9pbml0X3Qoc3RydWN0IHBjaV9kZXYgKmRldik7DQo+Pj4+Pj4gLQ0KPj4+Pj4+IC0jZGVmaW5l
IFZQQ0lfUFJJT1JJVFlfSElHSCAgICAgICIxIg0KPj4+Pj4+IC0jZGVmaW5lIFZQQ0lfUFJJT1JJ
VFlfTUlERExFICAgICI1Ig0KPj4+Pj4+IC0jZGVmaW5lIFZQQ0lfUFJJT1JJVFlfTE9XICAgICAg
ICI5Ig0KPj4+Pj4+ICt0eXBlZGVmIHN0cnVjdCB7DQo+Pj4+Pj4gKyAgICB1bnNpZ25lZCBpbnQg
aWQ7DQo+Pj4+Pj4gKyAgICBib29sIGlzX2V4dDsNCj4+Pj4+PiArICAgIGludCAoKmluaXQpKHN0
cnVjdCBwY2lfZGV2ICpwZGV2KTsNCj4+Pj4+PiArICAgIGludCAoKmNsZWFudXApKHN0cnVjdCBw
Y2lfZGV2ICpwZGV2KTsNCj4+Pj4+DQo+Pj4+PiBJcyBjb25zdCByZWFsbHkgbm90IHBvc3NpYmxl
IHRvIGFkZCB0byBhdCBsZWFzdCBvbmUgb2YgdGhlc2UgdHdvPw0KPj4+PiBXaWxsIGNoYW5nZSB0
byBiZSA6DQo+Pj4+DQo+Pj4+IHR5cGVkZWYgc3RydWN0IHsNCj4+Pj4gICAgIHVuc2lnbmVkIGlu
dCBpZDsNCj4+Pj4gICAgIGJvb2wgaXNfZXh0Ow0KPj4+PiAgICAgaW50ICgqIGNvbnN0IGluaXQp
KHN0cnVjdCBwY2lfZGV2ICpwZGV2KTsNCj4+Pj4gICAgIGludCAoKiBjb25zdCBjbGVhbnVwKShz
dHJ1Y3QgcGNpX2RldiAqcGRldik7DQo+Pj4+IH0gdnBjaV9jYXBhYmlsaXR5X3Q7DQo+Pj4NCj4+
PiBFaG0sIG5vLiBUaGUgcXVlc3Rpb24gd2FzIGZvciB0aGUgdHdvIGZ1bmN0aW9uIChwb2ludGVy
KSBwYXJhbWV0ZXJzLiAiY29uc3QiDQo+Pj4gb24gc3RydWN0IGZpZWxkcyB0aGVtc2VsdmVzIGNh
biBiZSB1c2VmdWwsIHRvbywgYnV0IGZvciBhbiBlbnRpcmVseSBkaWZmZXJlbnQNCj4+PiBwdXJw
b3NlLg0KPj4gT0ssIHdpbGwgYWRkIGNvbnN0IGJvdGggZm9yIHRoZSBzdHJ1Y3QgZmllbGQgYW5k
IHRoZSBmdW5jdGlvbiBwYXJhbWV0ZXJzLg0KPiANCj4gSWYgeW91IGFkZCAob3IgcmF0aGVyIGtl
ZXApIGNvbnN0IGZvciB0aGUgc3RydWN0IGZpZWxkLCB0aGUgbmV4dCBxdWVzdGlvbiBpcw0KPiBn
b2luZyB0byBiZSB3aHkgdGhlIG90aGVyIGZpZWxkcyBkb24ndCBoYXZlIGNvbnN0LiBJbW8gaXQn
cyBvbmx5IHRoZSBmdW5jdGlvbg0KPiBwYXJhbWV0ZXJzIHdoaWNoIHdhbnQgaXQuDQpPSywgZ290
IGl0LCBqdXN0IHRoZSBmdW5jdGlvbiBwYXJhbWV0ZXJzLg0KDQo+IA0KPj4+Pj4+ICt9IHZwY2lf
Y2FwYWJpbGl0eV90Ow0KPj4+Pj4NCj4+Pj4+IEFzIHlvdSBoYXZlIGl0IGhlcmUsIC4uLg0KPj4+
Pj4NCj4+Pj4+PiBAQCAtMjksOSArMzAsMjIgQEAgdHlwZWRlZiBpbnQgdnBjaV9yZWdpc3Rlcl9p
bml0X3Qoc3RydWN0IHBjaV9kZXYgKmRldik7DQo+Pj4+Pj4gICAqLw0KPj4+Pj4+ICAjZGVmaW5l
IFZQQ0lfTUFYX1ZJUlRfREVWICAgICAgIChQQ0lfU0xPVCh+MCkgKyAxKQ0KPj4+Pj4+ICANCj4+
Pj4+PiAtI2RlZmluZSBSRUdJU1RFUl9WUENJX0lOSVQoeCwgcCkgICAgICAgICAgICAgICAgXA0K
Pj4+Pj4+IC0gIHN0YXRpYyB2cGNpX3JlZ2lzdGVyX2luaXRfdCAqY29uc3QgeCMjX2VudHJ5ICBc
DQo+Pj4+Pj4gLSAgICAgICAgICAgICAgIF9fdXNlZF9zZWN0aW9uKCIuZGF0YS52cGNpLiIgcCkg
PSAoeCkNCj4+Pj4+PiArI2RlZmluZSBSRUdJU1RFUl9WUENJX0NBUEFCSUxJVFkoY2FwLCBmaW5p
dCwgZmNsZWFuLCBleHQpIFwNCj4+Pj4+PiArICAgIHN0YXRpYyBjb25zdCB2cGNpX2NhcGFiaWxp
dHlfdCBmaW5pdCMjX3QgPSB7IFwNCj4+Pj4+DQo+Pj4+PiAuLi4gX3Qgc3VmZml4ZXMgZ2VuZXJh
bGx5IGRlc2lnbmF0ZSB0eXBlcy4gSSBkb24ndCB0aGluayB3ZSBzaG91bGQgYWJ1c2UNCj4+Pj4+
IHRoYXQgc3VmZml4IGZvciBhbiBpZGVudGlmaWVyIG9mIGEgdmFyaWFibGUuDQo+Pj4+IFdoYXQg
ZG8geW91IHRoaW5rIEkgc2hvdWxkIGNoYW5nZSB0bz8NCj4+Pg0KPj4+IFdlbGwsIGlmIHlvdSB0
YWtlIG15IG90aGVyIGFkdmljZSwgdGhpcyBxdWVzdGlvbiB3b24ndCBuZWVkIGFuc3dlcmluZywg
YXMNCj4+PiB0aGVuIHlvdSBvbmx5IG5lZWQgdGhlIC4uLl9lbnRyeSBvbmUuDQo+Pj4NCj4+PiBC
dHcsIG5vdGljaW5nIG9ubHkgbm93IC0gd2h5IGlzIGl0IGZpbml0IHRoYXQncyB1c2VkIHRvIGRl
cml2ZSB0aGUgaWRlbnRpZmllcj8NCj4+PiBXaXRoIHRoYXQsIGl0IGNvdWxkIGFzIHdlbGwgYmUg
ZmNsZWFuIChsZWF2aW5nIGFzaWRlIHRoZSBmYWN0IHRoYXQgdGhhdCdzDQo+Pj4gb3B0aW9uYWwp
LiBJbW8gdGhlIG5hbWUgd291bGQgYmV0dGVyIGJlIGRlcml2ZWQgZnJvbSBjYXAsIGFuZCBpdCB3
b3VsZCBiZXR0ZXINCj4+PiBhbHNvIHJlZmxlY3QgdGhlIHB1cnBvc2Ugb2YgdGhlIHZhcmlhYmxl
Lg0KPj4gSSBjb25zaWRlcmVkIHRoaXMuDQo+PiBJIHRoaW5rIGl0IGlzIGVhc2llciB0byB1c2Ug
ZmluaXQsIGFuZCBmaW5pdCBjb250YWlucyB0aGUgY2FwIHR5cGUsIGFuZCB0aGUgbWFpbiBwdXJw
b3NlIG9mIHRoaXMgc3RydWN0IGlzIHRvIGluaXRpYWxpemUgdGhlIGNhcC4NCj4gDQo+IFlldCBp
ZGVudGlmaWVyIG5hbWVzIHNob3VsZCBtYWtlIHNlbnNlIGZvciB0aGUgb2JqZWN0IHRoZXkgbmFt
ZS4NCk9LLiBXaGF0J3MgeW91ciBzdWdnZXN0aW9uIGFib3V0IG5hbWluZyB0aGUgZW50cnk/DQpX
aGF0IEkgY2FuIHRoaW5rIG9mLCBpdCBzZWVtcyB0byBuZWVkIG1vcmUgd29yayB0byBkZXJpdmVk
IGZyb20gY2FwIGFuZCB3aWxsIGJlIG1vcmUgY29tcGxleC4NCg0KPiANCj4gSmFuDQoNCi0tIA0K
QmVzdCByZWdhcmRzLA0KSmlxaWFuIENoZW4uDQo=


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 08:27:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 08:27:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023333.1399294 (Exim 4.92)
	(envelope-from )
	id 1uTz02-0007V2-TQ; Tue, 24 Jun 2025 08:27:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023333.1399294; Tue, 24 Jun 2025 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 1uTz02-0007Uv-Qj; Tue, 24 Jun 2025 08:27:26 +0000
Received: by outflank-mailman (input) for mailman id 1023333;
 Tue, 24 Jun 2025 08:27: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 1uTz01-0007Un-85
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 08:27:25 +0000
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com
 [2a00:1450:4864:20::133])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0e22a3d3-50d5-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 10:27:24 +0200 (CEST)
Received: by mail-lf1-x133.google.com with SMTP id
 2adb3069b0e04-553bcba4ff8so5148558e87.2
 for ; Tue, 24 Jun 2025 01:27:24 -0700 (PDT)
Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-553e414c2aasm1728209e87.55.2025.06.24.01.27.22
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 24 Jun 2025 01:27:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0e22a3d3-50d5-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750753644; x=1751358444; 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=bTAXSifYpKVVsl3+dj7jPUHgCEs/mNfGsj01sXZJxbY=;
        b=LqluetwuNPmQWZNU3k4lqY4XuRAXqZBGUXe3MYt18OS2RMUMRhfU0C01cBDKjhYJMF
         r0Td64UxPbm2nCyaXOeC+zlc5GhJPjrN6UQssdUnUB05mv+Hpsx/48rf3c3WPuUewk50
         v+lKUAvDt9gsIVaoZ1PSYxO8Jmfj5/s/750FEZRpGg59OgII8vttQAbwS8WB5i+r3AJf
         owk4qF8RfdDOQb+2365+sEctXQvMRA5idPVhiQ+ey9XMmRIboZWcc3STgv2uzDWyslsl
         5p2R8RIlrJAXr3sSkJ7v0OMBnpYXQEgqXZ02S/2PsLhPA/xxexXaXyP8pCAAnwcMFU6A
         JgvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750753644; x=1751358444;
        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=bTAXSifYpKVVsl3+dj7jPUHgCEs/mNfGsj01sXZJxbY=;
        b=l+QL7IBtmUVfzamicL2ncL4BsBWqP8KLKsY8vfVj1PNOvHavF4WmOUlN3MoRoti8yn
         fXrEygKHSVpRl5vWrddxGjlCothD335i1EaTVtf4VFVfCjCzMnwA4GxVEN5Dqg7veHsq
         jlg5eWUMt3bTu2IupX7ZZCWYMjzkGXSAGMPccxwIF+4N5td8fAJTfdAuWKDukWJL5wxq
         awHINDwCuDjk8X9n/u2/3GkIef9YwpSXeAUShXQ5NahrzA1VTyApJT9aELkQfv6oVxZf
         BioeZxCv1erKbpNIICgIcbTbe6lNtYxKgn4CjEkiRUPe8Jg1sl78RCS+IbymFCYCScw1
         Rb+g==
X-Gm-Message-State: AOJu0YxeTgclFsUBa8DCZF2NPvN1k/yD328UMzTXVkZyY6rJXudX1VTZ
	2GtOKcj+/cSlULgsCbUn9qhyTDsIHgptnkOSAhzIv1YTM2vAyKYVAQHn9De9Qg2ZWko=
X-Gm-Gg: ASbGncuO7BJBhH/EC3AKzGkDFdap1AXXDik+a5RP+91ivVD/8mRIA/sdfv3JNMY0HpW
	WvhWF9dcA6rauWbScZ6gg+cpS886Py5PkD3978qShiEaV0hcMXjiMA6JZW6Lo8to4tDUVLSExPR
	D2VtmIWcBeFKBWAkbc8MGNnGq5QxQKtDHvIXlsyO/BWfXes+3Xrwd7Z86BxxfCEeOP9Nt9mqMd/
	lRAj30pJneaOBuroMBEDdf47LR0VrMp5LE7r7XtMAve340u/V6FKVxovIjsSeQpEMxUdFL3vT+h
	RnPGVumBXBoNii00wIqWvLvV5PKDAPLlZSzA3xbKXIOWsXKnc41hjnG1Sfi5JP2bAYtx2A7bFXy
	EzxvGElPoAEd3/C6ghX1QzdOdug==
X-Google-Smtp-Source: AGHT+IEYxeXLaimuOjL//P1be+9wjvf8JP85KsTj4iF0g6PW9mduNTiv6q/MMDzYNehBPxFOw3cy8Q==
X-Received: by 2002:a05:6512:224b:b0:553:ce07:de8e with SMTP id 2adb3069b0e04-553e3c053e8mr4889291e87.42.1750753643308;
        Tue, 24 Jun 2025 01:27:23 -0700 (PDT)
From: Mykola Kvach 
To: xen-devel@lists.xenproject.org
Cc: Mykola Kvach ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v2] xen/common: Guard freeze/thaw_domains functions with CONFIG_SYSTEM_SUSPEND
Date: Tue, 24 Jun 2025 11:27:20 +0300
Message-ID: 
X-Mailer: git-send-email 2.48.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Mykola Kvach 

This patch adds CONFIG_SYSTEM_SUSPEND guards around freeze_domains
and thaw_domains functions.

This ensures they are only compiled into the hypervisor when the system
suspend functionality is enabled, aligning their inclusion with their
specific use case.

This addresses two Misra Rule 2.1 violations.

Signed-off-by: Mykola Kvach 
Reviewed-by: Jan Beulich 
---
Changes in v2: Mentioned that this patch fixes a MISRA rule violation
in the commit message after review, and added the Reviewed-by tag
---
 xen/common/domain.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 8c8f70347a..303c338ef2 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -2411,6 +2411,8 @@ domid_t get_initial_domain_id(void)
     return 0;
 }
 
+#ifdef CONFIG_SYSTEM_SUSPEND
+
 void freeze_domains(void)
 {
     struct domain *d;
@@ -2436,6 +2438,8 @@ void thaw_domains(void)
     rcu_read_unlock(&domlist_read_lock);
 }
 
+#endif /* CONFIG_SYSTEM_SUSPEND */
+
 /*
  * Local variables:
  * mode: C
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 08:28:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 08:28:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023343.1399304 (Exim 4.92)
	(envelope-from )
	id 1uTz1P-00085v-A2; Tue, 24 Jun 2025 08:28:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023343.1399304; Tue, 24 Jun 2025 08:28:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTz1P-00085o-6w; Tue, 24 Jun 2025 08:28:51 +0000
Received: by outflank-mailman (input) for mailman id 1023343;
 Tue, 24 Jun 2025 08: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 1uTz1O-00085d-3V
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 08:28: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 3fe8b1f5-50d5-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 10:28:48 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3a6e2d85705so90093f8f.0
 for ; Tue, 24 Jun 2025 01:28:48 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b31f119e820sm9704971a12.23.2025.06.24.01.28.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 01:28:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3fe8b1f5-50d5-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750753727; x=1751358527; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=BZ1v9caGWC8K5bNoYCQRWfHPK9+yKVOzzyRfF0h/i+I=;
        b=Hfizm9BqlnSLGpxAPIgh4S4mqIV3A5Lp+iLi13nZdulcCfnwjoejMVaELvgn3k8+hr
         d3SsFV8Ga3N6qmqMOyfP6W4+z5WImwbfM5M+VJstRDBl/e4R3o+mzuu09jyGLDuOJBPs
         GKtP4IkJwdgquzx1uqQ2sXh4KoxC7Xe6/4//Td7M0GyY8D5vqjCOmyJUmAHHAVkk9T+I
         ey4+shWX7ZX80uOTkx2HI0oo32XwxmyANXq/0zuMBhcE3n5lE6KNWl+KHkSyYkHGn5mu
         PhZf5umw39adj2AYHYCERaW78ociUdzu+GWyqxmR3PFpIcSlPSyUN6dVxEfUwtV5o/ya
         IT/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750753727; x=1751358527;
        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=BZ1v9caGWC8K5bNoYCQRWfHPK9+yKVOzzyRfF0h/i+I=;
        b=bA/QE8nMkWZIOHQG+RaFAiuixrEG7C2JSFLm+U5YfrQF9j9hSqDLgkJscFe8gocG0V
         7+cvEbbUrF7JN4dbUqJtZVtU+agR7ePSYn1RnitEkBHKTjtGmZUe8VmSaPxZNRBXa8sS
         I3PbjEOSkgVu8nwOdFAjaIM+eigocmZM5dSL/piaoPKbQVpMwEXJ4I3AWeBf3xvWTMRX
         LpuwGwb/8/qpbOXHVsc6/uJqQe2/kJoTq2d1NTqSNNla+tna2LxEnurpqBy+lN5f+wkx
         z8IjowM/+GWavJfAFpolXwHnkYWa06yaqTLgvV18W0xYBiev5Cp6pW8KlOi8zGcm8gCy
         k7HA==
X-Forwarded-Encrypted: i=1; AJvYcCV53cOeG8GsioxZW0x/w4VatkMXw1RHYaeruYkyEDi2obhWY+/IEDTRrk8T8SWWLCuAW/fWmzomJKk=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz3r7m3GNZqGnlKjzx4Tmp1KRc0Nh8OSBXBlMhrIW1fJPTSVsjW
	qw5Me1NBotYcfnQa+ujEfgiGZZVszTlHTWXEg+wi27T7IQVolpo+xHIc0zCGJdRO0w==
X-Gm-Gg: ASbGnctPLaBMQfYDFpjZd627YkNX6Xfq1kAaRb1/2f92PAC8H/T5O24DZIwyrnASv0+
	UHXvz3PHJCo7thNXQ5EkuG9HThPODlXvl+yKoyT3plgJapOP/0fNYZBGPYWPVewdzzbbx7Vqum7
	mMuMsNT8Oxyquu6RRLCkBmFz9EyH/v6W44Dg74qq906591zWxrv4Rx+H43bfOFOymvcr7LCQIL3
	a+08ia5q5NERmE+oXUoHyEPUvDwjsac8t7uBjDYKw3hCJfu8mLMVasVpx7Qvyka6GrfeooKL5X9
	5ntviPWU4sXXfkDCKiewqY+o1nilY8RooHh0rXwtooJJiOby5Gnl9FDenkpEPrkBv/yMLjNxTSR
	kNOktTwRdSYU4zZuTSO2pVLhcyH+ywvaDjs+IFNE9h6MvTfc=
X-Google-Smtp-Source: AGHT+IHul8aIkPK2JDOH4OgBtoVXKzlCdUGWTDtw/+uQHQHhn5HXtys5/EC62P1jGKykHqA4Au8G0g==
X-Received: by 2002:a05:6000:400f:b0:3a4:df80:7284 with SMTP id ffacd0b85a97d-3a6d11932bemr13084195f8f.1.1750753727375;
        Tue, 24 Jun 2025 01:28:47 -0700 (PDT)
Message-ID: <3eaaa6c8-d696-4eca-913e-6e6fd9e618d3@suse.com>
Date: Tue, 24 Jun 2025 10:28:37 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
To: "Chen, Jiqian" 
Cc: "Huang, Ray" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Andrew Cooper ,
 Anthony PERARD ,
 "Orzel, Michal" , Julien Grall ,
 Stefano Stabellini ,
 "xen-devel@lists.xenproject.org" 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-3-Jiqian.Chen@amd.com>
 <1634c18d-e54e-4105-8b30-6f3085bace22@suse.com>
 
 <23293ec5-7466-400c-87a4-1482577b91fa@suse.com>
 
 <0cf4679d-ee86-4666-adae-63a3f9b9b8f7@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 24.06.2025 10:26, Chen, Jiqian wrote:
> On 2025/6/24 16:17, Jan Beulich wrote:
>> On 24.06.2025 10:12, Chen, Jiqian wrote:
>>> On 2025/6/20 14:34, Jan Beulich wrote:
>>>> On 19.06.2025 08:14, Chen, Jiqian wrote:
>>>>> On 2025/6/18 22:33, Jan Beulich wrote:
>>>>>> On 12.06.2025 11:29, Jiqian Chen wrote:
>>>>>>> +} vpci_capability_t;
>>>>>>
>>>>>> As you have it here, ...
>>>>>>
>>>>>>> @@ -29,9 +30,22 @@ typedef int vpci_register_init_t(struct pci_dev *dev);
>>>>>>>   */
>>>>>>>  #define VPCI_MAX_VIRT_DEV       (PCI_SLOT(~0) + 1)
>>>>>>>  
>>>>>>> -#define REGISTER_VPCI_INIT(x, p)                \
>>>>>>> -  static vpci_register_init_t *const x##_entry  \
>>>>>>> -               __used_section(".data.vpci." p) = (x)
>>>>>>> +#define REGISTER_VPCI_CAPABILITY(cap, finit, fclean, ext) \
>>>>>>> +    static const vpci_capability_t finit##_t = { \
>>>>>>
>>>>>> ... _t suffixes generally designate types. I don't think we should abuse
>>>>>> that suffix for an identifier of a variable.
>>>>> What do you think I should change to?
>>>>
>>>> Well, if you take my other advice, this question won't need answering, as
>>>> then you only need the ..._entry one.
>>>>
>>>> Btw, noticing only now - why is it finit that's used to derive the identifier?
>>>> With that, it could as well be fclean (leaving aside the fact that that's
>>>> optional). Imo the name would better be derived from cap, and it would better
>>>> also reflect the purpose of the variable.
>>> I considered this.
>>> I think it is easier to use finit, and finit contains the cap type, and the main purpose of this struct is to initialize the cap.
>>
>> Yet identifier names should make sense for the object they name.
> OK. What's your suggestion about naming the entry?

cap##_init or _##cap##_init for example.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 08:29:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 08:29:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023350.1399314 (Exim 4.92)
	(envelope-from )
	id 1uTz27-0000BB-HY; Tue, 24 Jun 2025 08:29:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023350.1399314; Tue, 24 Jun 2025 08:29: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 1uTz27-0000B4-Ej; Tue, 24 Jun 2025 08:29:35 +0000
Received: by outflank-mailman (input) for mailman id 1023350;
 Tue, 24 Jun 2025 08:29: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 1uTz25-0000Ax-SB
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 08:29:33 +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 5a1a599b-50d5-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 10:29:32 +0200 (CEST)
Received: by mail-lf1-x12a.google.com with SMTP id
 2adb3069b0e04-54e98f73850so4405519e87.1
 for ; Tue, 24 Jun 2025 01:29:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5a1a599b-50d5-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750753771; x=1751358571; 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=EINKtiFQ12x+G2hBiaJd1jBjzmgneJmem09Rc4JkTN0=;
        b=gAY5LSZDwyym7poa/7TnUUFbhcogJOMEicsuUgPqaJYyfFOuIFgBk8KNRB+Ljf91ax
         DU5DhzQiIbn89tqBbyVgUmnkhh0fDjz96sEekV/5fLSkQHddYuXFloPJSqGX2BVXpcQy
         ziTb7flwI9mtuSXnG9w++HkCOTMpcxI/yjlLsV62hGAQSapiURZtCmFPCLU0DwZz1+fX
         zMuyUszBID4SFmuRXaoWH4yye/VsfS4Y9DTwFm2yiKpkj0aKus+Pzc/L6tH6o+hHYRsH
         ZBDrfMPx3JT0HeeHpuG+t5TdelUAmLk7/Q9mjJPjqDqONfPbd5Nn3w3Xczqv/mLoUHBK
         blmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750753771; x=1751358571;
        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=EINKtiFQ12x+G2hBiaJd1jBjzmgneJmem09Rc4JkTN0=;
        b=LHdPbHHLHQumr+YhxZnKO0eDzFRw7Pgi2mog+Z68N5UKDQ8y52w8au4xuo2uXhKP3i
         gzrKiTNk4f/GTw8Y/YG12lqZI879w6pFEd7vZKyD2MfzR+NOIO+Ej0ucQ/2XtlqHaUKG
         kZ5W+YXja5bGokGaer1eC0wkfOw4NMwbMQ4idXGjQmNdjTtYUPr8puUFYkbaTQhoA+ZO
         Unmpg4twexTqkSHbXW6O77k0T54NAedcYnGFFlpPIPSdwrQKund60k7B5R5L5m90XmFK
         So7G35x0oRadelZEMYzfDPHRneRUH3FoxRHEpGC5qxBGKCD4RVO97MfkNaQYmWCiMJMq
         q/9Q==
X-Forwarded-Encrypted: i=1; AJvYcCV2KKx89rSRdgNk41gH9pvsZkNfoKsfiG5UOQ6SuOyj/oADiEZhkUhfZS/F2sYcK9qR+6kuKQqBpE8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyWC4WOJf2vVaJ9qM2FMngZHbGTiyIb98dC+bRxkDxevo4XV2pW
	xQxjGtjKQ7JfdYpms7vbe6/rwMhAQganRxR5Dqj6mlsjEhBWEWJuvBl+h5f27RncP5cHRTZzqVR
	EHu6sOcv9m6yiq5hfcsdvQGO6DWu7HyI=
X-Gm-Gg: ASbGncuBSyhQfCbu66Wg/V81fCHDiGhmvR0Ek+Wau8fUdWK5FhBAuuB8+umt8jZPK79
	JO1ftScfYgVTFSHFvoIafYKZ+sU2nu0l697cX1G1KwBXxFY1mziojtRwwJB1Gqit79ci+8qbEJA
	MZX1kABSkoHT5vCBwb4m4SvZlh12+DpBGeK336CPFWPg==
X-Google-Smtp-Source: AGHT+IF1Z5fc+8q7VvYuPoBC9GNvSUrGip+h7Ag1qwI50ylEwDgEVsC4bssJWV7ulR3nLDiZzpf+sj9plIipEO021NE=
X-Received: by 2002:a05:6512:318e:b0:553:3770:c907 with SMTP id
 2adb3069b0e04-553e3b9adf2mr4634176e87.10.1750753771243; Tue, 24 Jun 2025
 01:29:31 -0700 (PDT)
MIME-Version: 1.0
References: <5449d6fc4a6e47af173d9e2b285f1e3398de98a3.1750749332.git.mykola_kvach@epam.com>
 <2b345a72-5ab7-443f-bff4-2b4ee9952825@suse.com>
In-Reply-To: <2b345a72-5ab7-443f-bff4-2b4ee9952825@suse.com>
From: Mykola Kvach 
Date: Tue, 24 Jun 2025 11:29:19 +0300
X-Gm-Features: AX0GCFu7bWTDJvjIOhddrRP2JQTFOZKqpLEv-cfb0XMOYyfyeofZe8_rsyb9woc
Message-ID: 
Subject: Re: [PATCH v4] xen/char: implement suspend/resume calls for SCIF driver
To: Jan Beulich 
Cc: Volodymyr Babchuk , Stefano Stabellini , 
	Julien Grall , Bertrand Marquis , 
	Michal Orzel , 
	Oleksandr Andrushchenko , Mykola Kvach , 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Jan,

On Tue, Jun 24, 2025 at 10:53=E2=80=AFAM Jan Beulich  wr=
ote:
>
> On 24.06.2025 09:18, Mykola Kvach wrote:
> > @@ -281,6 +313,10 @@ static struct uart_driver __read_mostly scif_uart_=
driver =3D {
> >      .start_tx     =3D scif_uart_start_tx,
> >      .stop_tx      =3D scif_uart_stop_tx,
> >      .vuart_info   =3D scif_vuart_info,
> > +#ifdef CONFIG_SYSTEM_SUSPEND
> > +    .suspend      =3D scif_uart_suspend,
> > +    .resume       =3D scif_uart_resume,
> > +#endif
> >  };
>
> As this being put inside #ifdef was to be expected, imo a prereq change i=
s to
> also make the struct fields conditional in xen/console.h. I think I did e=
ven
> comment to this effect back at the time.

Would you prefer that I include this change in the current patch
series, or is it acceptable to address it in a separate patch?

>
> Jan

Best Regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 08:32:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 08:32:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023356.1399325 (Exim 4.92)
	(envelope-from )
	id 1uTz4Z-0001kr-UX; Tue, 24 Jun 2025 08:32:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023356.1399325; Tue, 24 Jun 2025 08:32: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 1uTz4Z-0001kk-Q0; Tue, 24 Jun 2025 08:32:07 +0000
Received: by outflank-mailman (input) for mailman id 1023356;
 Tue, 24 Jun 2025 08:32: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 1uTz4Y-0001ke-Hl
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 08:32:06 +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 b517bc50-50d5-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 10:32:04 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3a6cdc27438so4294880f8f.2
 for ; Tue, 24 Jun 2025 01:32:04 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b31f126a7bbsm9808321a12.69.2025.06.24.01.31.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 01:32:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b517bc50-50d5-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750753924; x=1751358724; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=NVkI+qGtPevFR8TEjO/y3VZRgYAtodU0AtpHvWzJE2o=;
        b=Ob3Px9hRj/ZOsxs0kT/MeyxFNO7p1TkTsQ5kQxUV9+XvTVknj+hEqWsBw1tV6XElCb
         CZfo0415ZFiBNVdCHaeWegqPq6aTMC0DTTKq5+9V/6Ma/FYsEw9R8exua4iFUz3Llf7N
         OsSnTgLVaW2RhNDkmndeDOniFoPVib77IorvnrlQZT54mQD3UAu9Nw/34RUaKIdHEJYa
         gwlDl2lp+HiK2X834tRIkXoP02yyTQx13W2wKLghyEWkpSnbAdLqIP2yQ3t73zC+d2Xo
         ezEPPQHQJDBDSWUpjjVhcn8nJHH4aE11r+yvtrVQJR7aP6Fvh9etCKcb+N0Zuiw1oZLj
         LRCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750753924; x=1751358724;
        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=NVkI+qGtPevFR8TEjO/y3VZRgYAtodU0AtpHvWzJE2o=;
        b=LzMZBK6YvYmv4mbqL6dmOS4S366uQuNpgEOhNwrpidReXmKOgbVodsPBdXuhqcU9lo
         n2ERDt2P2XGxyDGToK44go3g0JHpTGMIQ3F9IMJnVSBz3Kbp41AbsDjn88IZVZFdKHBL
         BV+TvB3SgfPRaYrXmPv7rQTSQEV86wDbPgymmG3ff0NrNpoyh+tTQp3I39YLkIknJSEy
         SIpsewM3bctC19y9SZ/b622nyQds0LtP8PcNq7uBu5z6hlisLZjoDtCP8KMUmKiZ18bE
         hJpXx5bZ1cRbGu1OK9VFVOpIiuHB1q+6gXoTmFhr8+9JFi0CDUR6glXWusY5/3lO0bt5
         9xUg==
X-Forwarded-Encrypted: i=1; AJvYcCWO4wKzRyku7AshoVirhpy+C6AMfts+FnbeJA1+OGXPldQfSIJMbLWpmdjCBLS0h9+azZUgfF6ZdWI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxEkzYBfyo+Q6jDJPf5/4GVIyrt9kIHczEkxte/SOLwZAE+Uif+
	f526nORPuB2O7QlaGDJnynmoKd3u8gc9w+L4ETjjLWYNe7iJH9XwDPj9xngUUYO3HA==
X-Gm-Gg: ASbGnctatBkftD18im+hpPrRL/pddpvS25mdsX9KJg9wRikzfr2SPdZfPqys3PyqmLY
	W3CaChNj+0OPYmd4yFMIaNkilz2xzQJUfb88xfmh5NgQf5hkD54TcQ0uze74CwEXw/1cbI2jiYw
	p01ydyKL9amQebfqicXL0H/laT4lDmP3sRCxYiaclCZiApamR+lAKmNyYPiG0Ce1Jgm6AtYIRPA
	/o6ndIV/YozP/jcwTvT/AFdZNc4N1JIys0Vb9E8mrp0RMeX+IAepArx2Xexrf1V5yUhBwVi26SR
	fVH8dr64pGIMn07MzLGvshMLAQJBsxs0gRVa1n8xhkndBnJthJ8g6pkuH3vTmtVMda+LsMB1hov
	QbJPEapnFSyd+T21kQ1zw/ZZxAqIr62ABIP+Bt/RdRGFKIMLpJxxTaBfN7A==
X-Google-Smtp-Source: AGHT+IFHq3+eJRO4DHgaIXY5buDt1YLVcu5M42KzqKUGFzatuKc/0koVVNBv9H9qj1OZYo1ekXtTDw==
X-Received: by 2002:a5d:5846:0:b0:3a4:e6e6:a026 with SMTP id ffacd0b85a97d-3a6d131708fmr13665824f8f.28.1750753924075;
        Tue, 24 Jun 2025 01:32:04 -0700 (PDT)
Message-ID: 
Date: Tue, 24 Jun 2025 10:31:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4] xen/char: implement suspend/resume calls for SCIF
 driver
To: Mykola Kvach 
Cc: Volodymyr Babchuk ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Oleksandr Andrushchenko ,
 Mykola Kvach , xen-devel@lists.xenproject.org
References: <5449d6fc4a6e47af173d9e2b285f1e3398de98a3.1750749332.git.mykola_kvach@epam.com>
 <2b345a72-5ab7-443f-bff4-2b4ee9952825@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 24.06.2025 10:29, Mykola Kvach wrote:
> On Tue, Jun 24, 2025 at 10:53 AM Jan Beulich  wrote:
>> On 24.06.2025 09:18, Mykola Kvach wrote:
>>> @@ -281,6 +313,10 @@ static struct uart_driver __read_mostly scif_uart_driver = {
>>>      .start_tx     = scif_uart_start_tx,
>>>      .stop_tx      = scif_uart_stop_tx,
>>>      .vuart_info   = scif_vuart_info,
>>> +#ifdef CONFIG_SYSTEM_SUSPEND
>>> +    .suspend      = scif_uart_suspend,
>>> +    .resume       = scif_uart_resume,
>>> +#endif
>>>  };
>>
>> As this being put inside #ifdef was to be expected, imo a prereq change is to
>> also make the struct fields conditional in xen/console.h. I think I did even
>> comment to this effect back at the time.
> 
> Would you prefer that I include this change in the current patch
> series, or is it acceptable to address it in a separate patch?

Either way is fine with me. I expect the header fine change to be able to go
in right away (once submitted), whereas the patch here may take some time for
people to review.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 08:32:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 08:32:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023357.1399334 (Exim 4.92)
	(envelope-from )
	id 1uTz4g-00020F-4E; Tue, 24 Jun 2025 08:32:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023357.1399334; Tue, 24 Jun 2025 08:32: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 1uTz4g-000208-1Q; Tue, 24 Jun 2025 08:32:14 +0000
Received: by outflank-mailman (input) for mailman id 1023357;
 Tue, 24 Jun 2025 08:32: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 1uTz4e-0001zK-OQ
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 08:32:12 +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 b96903b0-50d5-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 10:32:11 +0200 (CEST)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-45348bff79fso55640205e9.2
 for ; Tue, 24 Jun 2025 01:32:11 -0700 (PDT)
Received: from localhost.localdomain (253.226.6.51.dyn.plus.net.
 [51.6.226.253]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a6e8050f53sm1322365f8f.3.2025.06.24.01.32.10
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 24 Jun 2025 01:32:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b96903b0-50d5-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750753931; x=1751358731; 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=yEKcMdqGBUYMaK8hVsdH0Ud6UR9wmE3/cnH1SRqJ8e8=;
        b=QhQNvW6m0gWK6gbbJgxESSmULWPcVfQOR1PiRwJNAIcvqKKE5PldzNtc6qZ6BmhHVU
         JSHfcAsZVI3p1h7l/CpO7HQgj4uXYlLI/KZvtNev/4BbKI6T6pLGlbdgoJTHkqZTKiDV
         7LrF+IHCcseGtoH59gipncBtLpG7yyQXwwbuw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750753931; x=1751358731;
        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=yEKcMdqGBUYMaK8hVsdH0Ud6UR9wmE3/cnH1SRqJ8e8=;
        b=GLV3TWZiMgzkm5G8+bwZzMMy+Qpvr+Ppuzjf3E2cG2X5lTg5cGz/skNOaon31hIu3X
         Qzv3Sxsn/M4K8cAUIL86IferoFXCfHZBGhauBguhEpwSINLs3dcuniAfIDfkuV8OeZZh
         wF81B4Be3VHVxV0l2MCSR3uf33kJOdSQPQj5Y6QlFHFwRdwMS8V+ZldfXWQaC98t5lWS
         qJk8zJmH7Qg4QCVbszQH2dHDOOFT+DDKbYKm745kbfr9yz4+AwTIEayE2QU72ifM/Lne
         UcJQgeyobmgEuep4haO8LjcAHrnKkEDD+eUasG7xtJ9ypGTU6yGUdO6U3W3cxcTdvB6a
         bOdA==
X-Gm-Message-State: AOJu0YwMLf6DQWiK4Sn4zyna5MG4oQWge64JFT0sT+GbX+S6d8Q8gGb3
	mJ8BLrRWEQMemCHn9/sLTX7QsEkZ5QPRnzi7Dzq0+38pfAM3RMri2PFAcX9BBaJe3EeiS9okEn6
	+44MM7q4GSw==
X-Gm-Gg: ASbGnctgp+WHVvuQDlsB4zGJe3R7JWy8CVsY4DuvbVENL20B+sxexY6dEH9RRteL5U2
	Rk2qeH3ho1mvWV0RFIvNcJpivcL3klDo/JB+kqdi6Qf2JI/93ENlrBk1FKY9xLNxsO69SSs9cpc
	cMyeVvRiPL50JOOhv+Y9ejEThOtSpIG3SuNDRyW0Szd5RC8yqVlinIS+mLwAUsKoSgF3XTimjQd
	ET6dAbMRykcctfbgjNjVkchKPIkOFQKNeJc/RdvS5eTtcGPx1dbslOhx0d+BYVdV/qMRkZFh1M1
	xjnLnnhx2PE2p92Kh17HDKHTtYy4o8ZtgIDD0cLQlNrq3vQ6x8maQLcUBIk5NHOM939HWU130a/
	AJworVzKmBCLJzeP7XGwLcnAAkpQwYg==
X-Google-Smtp-Source: AGHT+IGAtjt0m5rF6HsoH8uL19IHgC1D08/2KiW3QwwtBYuh93HJxdezCPFwKw86fsqnQHAqKtBWpQ==
X-Received: by 2002:a05:6000:4282:b0:3a5:783f:5296 with SMTP id ffacd0b85a97d-3a6d13339f6mr13449619f8f.56.1750753930894;
        Tue, 24 Jun 2025 01:32:10 -0700 (PDT)
From: Frediano Ziglio 
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio ,
	"Daniel P. Smith" ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Jan Beulich 
Subject: [PATCH 0/2] xen/efi: Make boot more flexible, especially with GRUB2
Date: Tue, 24 Jun 2025 09:31:53 +0100
Message-ID: <20250624083157.9334-1-frediano.ziglio@cloud.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The combination of GRUB2, EFI and UKI allows potentially more flexibility.
For instance is possible to load xen.efi from a no ESP partition leaving
a boot loader like GRUB2 taking care of the file loading.
This however requires some changes in Xen to be less restrictive.
Specifically for GRUB2 these changes allows the usage of "chainloader"
command with UKI and reading xen.efi from no ESP (so no DeviceHandle
set) and usage of "linux" and "initrd" commands to load separately
the kernel (embedding using UKI) and initrd (using LoadFile2 protocol).

Frediano Ziglio (2):
  xen/efi: Handle cases where file didn't come from ESP
  xen/efi: Support loading initrd using GRUB2 LoadFile2 protocol

 xen/common/efi/boot.c     | 98 +++++++++++++++++++++++++++++++++++++--
 xen/include/efi/efidevp.h | 21 +++++++++
 2 files changed, 116 insertions(+), 3 deletions(-)

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 08:32:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 08:32:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023358.1399344 (Exim 4.92)
	(envelope-from )
	id 1uTz4j-0002Gk-Bn; Tue, 24 Jun 2025 08:32:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023358.1399344; Tue, 24 Jun 2025 08:32:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTz4j-0002Gd-9A; Tue, 24 Jun 2025 08:32:17 +0000
Received: by outflank-mailman (input) for mailman id 1023358;
 Tue, 24 Jun 2025 08:32: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 1uTz4h-0001zK-SO
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 08:32:15 +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 bb937342-50d5-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 10:32:15 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a507e88b0aso4250136f8f.1
 for ; Tue, 24 Jun 2025 01:32:15 -0700 (PDT)
Received: from localhost.localdomain (253.226.6.51.dyn.plus.net.
 [51.6.226.253]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a6e8050f53sm1322365f8f.3.2025.06.24.01.32.11
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 24 Jun 2025 01:32:11 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bb937342-50d5-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750753935; x=1751358735; darn=lists.xenproject.org;
        h=content-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=YbnXF7V2QfdTrRqTRobcWnbo+kaLMKXyj/4viUPq/9w=;
        b=NXj/Q+lRWoNh8OrUd4bS4XyvNwb1zVGTIMnxrChzdq2KY6EmH02Vae/BSMW0FWMR+W
         TNwOzNmD+lKNGe216HVa8iPL7M4NsL6B6yXuDu2veV//HkRyVZc4gfkwqUBuSjVkdz6R
         ulYWra8P8zqxrRJghYpG3HS2Wmoofx770lXDM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750753935; x=1751358735;
        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=YbnXF7V2QfdTrRqTRobcWnbo+kaLMKXyj/4viUPq/9w=;
        b=M45jjOwTQnZGiyqNoP5y3Bws4nIWBB+hjVn3BOwtgxkF1DenSLbWgEnItXsoCLoRln
         kBM0I0kBUHUehI1pfGtloWAxLNFJnfMFYXofgMGigPrDhR2pqf4cIg+0SUwTqSaZ3zwL
         IX0WmX6OoCS02YWjTlelJ0bI95SAZXuQ6sbGnlN4XJAVVkbDqBKQkHpDOr1HmjKUJkJC
         IsDmNMLO3ZxfX/r9Wb8sjC1Oo/OSP7PlMCjkSadygZ30Fbij/shuTHJlBUruLHMQcgzX
         SVieZI+XYRAYMhv83tvSp5tKWL1Oqel9apLWsFieAzaZCJx8K1aUP71VzkBSwVQgFDi+
         Ipyg==
X-Gm-Message-State: AOJu0YwlOKdyRmpMDdGo8nevGuHCZRVuJ2Iw7mmS6BQTsR3eh1lJbOym
	5rqYN+m9h8wc2x/tjKvXwWYEvZEHoB6a4PbfeBTGXzYGfrdwhe7OqZi/ghliEc6qSITyhEkXw7k
	Nd7KVbraRUg==
X-Gm-Gg: ASbGncs3vilrNXlIA4uV3yrtBo8uIcnsfNkhLv75kCVR2e4hol2SoSDjUkUQX0KVxxP
	9TkmGTC5lmfnonvkBX1P3e6ZX0qcSuGVkowTpDLWC1pYjqqMsYxEKEhNYo+qJyOtFqksYzMVdUo
	Qs1F3mBI4W4mIL0oGJhe6JjxgQFCTIg5uMvvW+xZMCBp2PvsT0Ee4Obcckx2VVf8iPQIsgJtyLp
	frJ3w87sZeTl8ydZvOGuuAHxuap0f/phmq2zlb9s38ZETxNfhmXhidb3TUe3GJsGQYwupWSvOQt
	uT/x1TqlPNHqX57MEHDjJBGtaT+UR2Jg2uC2qVYwwXwJYOs2z/doJBi9dQt4ARNtmXicq8tEGG+
	OeQme7zM/GBmRDdwFEadmtjhT1rVjoA==
X-Google-Smtp-Source: AGHT+IH6ufTRv1s3uEcgC/zbpkNW8qMXVLG+4euJb/BBjbMMEyxOaaEUuQqE5TvedU4WCo8c+BKTiQ==
X-Received: by 2002:a05:6000:2308:b0:3a5:2f23:377d with SMTP id ffacd0b85a97d-3a6d1324f04mr11601799f8f.50.1750753931588;
        Tue, 24 Jun 2025 01:32:11 -0700 (PDT)
From: Frediano Ziglio 
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio ,
	"Daniel P. Smith" ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Jan Beulich 
Subject: [PATCH 1/2] xen/efi: Handle cases where file didn't come from ESP
Date: Tue, 24 Jun 2025 09:31:54 +0100
Message-ID: <20250624083157.9334-2-frediano.ziglio@cloud.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250624083157.9334-1-frediano.ziglio@cloud.com>
References: <20250624083157.9334-1-frediano.ziglio@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

A boot loader can load files from outside ESP.
In these cases device could be not provided or path could
be something not supported.
In these cases allows to boot anyway, all information
could be provided using UKI or using other boot loader
features.

Signed-off-by: Frediano Ziglio 
---
 xen/common/efi/boot.c | 27 +++++++++++++++++++++++++--
 1 file changed, 25 insertions(+), 2 deletions(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 1a9b4e7dae..2a49c6d05d 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -443,6 +443,18 @@ static EFI_FILE_HANDLE __init get_parent_handle(const EFI_LOADED_IMAGE *loaded_i
     CHAR16 *pathend, *ptr;
     EFI_STATUS ret;
 
+    /*
+     * In some cases the image could not come from a specific device.
+     * For instance this can happen if Xen was loaded using GRUB2 "linux"
+     * command.
+     */
+    *leaf = buffer;
+    if ( !loaded_image->DeviceHandle )
+    {
+        PrintStr(L"Xen image loaded without providing a device\r\n");
+        return NULL;
+    }
+
     do {
         EFI_FILE_IO_INTERFACE *fio;
 
@@ -466,7 +478,15 @@ static EFI_FILE_HANDLE __init get_parent_handle(const EFI_LOADED_IMAGE *loaded_i
 
         if ( DevicePathType(dp) != MEDIA_DEVICE_PATH ||
              DevicePathSubType(dp) != MEDIA_FILEPATH_DP )
-            blexit(L"Unsupported device path component");
+        {
+            /*
+             * The image could come from an unsupported device.
+             * For instance this can happen if Xen was loaded using GRUB2
+             * "chainloader" command and the file was not from ESP.
+             */
+            PrintStr(L"Unsupported device path component\r\n");
+            return NULL;
+        }
 
         if ( *buffer )
         {
@@ -772,6 +792,8 @@ static bool __init read_file(EFI_FILE_HANDLE dir_handle, CHAR16 *name,
 
     if ( !name )
         PrintErrMesg(L"No filename", EFI_OUT_OF_RESOURCES);
+    if ( !dir_handle )
+        return false;
     ret = dir_handle->Open(dir_handle, &FileHandle, name,
                            EFI_FILE_MODE_READ, 0);
     if ( file == &cfg && ret == EFI_NOT_FOUND )
@@ -1515,7 +1537,8 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle,
         efi_bs->FreePages(cfg.addr, PFN_UP(cfg.size));
         cfg.addr = 0;
 
-        dir_handle->Close(dir_handle);
+        if ( dir_handle )
+            dir_handle->Close(dir_handle);
 
         if ( gop && !base_video )
         {
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 08:32:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 08:32:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023360.1399354 (Exim 4.92)
	(envelope-from )
	id 1uTz4n-0002aP-OC; Tue, 24 Jun 2025 08:32:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023360.1399354; Tue, 24 Jun 2025 08:32: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 1uTz4n-0002aF-Jb; Tue, 24 Jun 2025 08:32:21 +0000
Received: by outflank-mailman (input) for mailman id 1023360;
 Tue, 24 Jun 2025 08:32: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 1uTz4m-0001zK-7g
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 08:32:20 +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 bdcf0d27-50d5-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 10:32:19 +0200 (CEST)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-450cf214200so45586075e9.1
 for ; Tue, 24 Jun 2025 01:32:19 -0700 (PDT)
Received: from localhost.localdomain (253.226.6.51.dyn.plus.net.
 [51.6.226.253]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a6e8050f53sm1322365f8f.3.2025.06.24.01.32.11
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 24 Jun 2025 01:32:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bdcf0d27-50d5-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750753938; x=1751358738; darn=lists.xenproject.org;
        h=content-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=TC5W+e8UqjgFWSnLG+QiiEwlV+/lFx7hnFwjokg9pes=;
        b=VYJEodOhLI2fx8v+cKLUFPDjfYre0ARWtFQeQhdXSLsSh/JjPPOcG2dHj6Kc8eTaV5
         zDLtegfxF6sRfA38+QeCECwbfdmlgRBscPNV++tX6HYws1CD3Kd/Bwne9ROjb7ZIUBkd
         /C3+fTIEbcAmnMjqV/QJ0a3lbGzktQ7qgm0nc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750753938; x=1751358738;
        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=TC5W+e8UqjgFWSnLG+QiiEwlV+/lFx7hnFwjokg9pes=;
        b=S9MYH+o1Xm6VSXzB9oKe1ToLmuKiHG2BhZPDabP3WYrbQckQpy8aet87qwxxSAQjTE
         x9ycsw5NeWV7Y5ss8HAEFdNAJ1i5ETpCV7Cjqmdg4OJI8JRuZ4cKqKmfIhPeDEB0nCLX
         napywAioJQs1X4k1gQmWVjh00oEmokvxz2rsHYKSf0u1VIrXpeNwkePpHfmCuhe9+yC5
         0uss7kJ3KJ3lGZETK9By79rBqAiBUp3+WynMCwRIaem1KVpGlDkO66fGqsIqJcJrIDaJ
         mm5LXtYZD8vdHRd+X519fQX5BiZEXvD/zU5WzpUdCBIwGQxDeU4WcIDBUEKhPaHzdIlS
         7bTQ==
X-Gm-Message-State: AOJu0YxqwneuI0kQ0h0cymciN0nFJPePBrPnzHkZxmXrRMnfr0P6lqHA
	rdFOdoreAZiCveSWYIuSdM3p8q3urxi7DEduVmNMZGOz59DvNMMDR6j88a8Ls9QeZdmPf0uPzge
	25vF909qd8A==
X-Gm-Gg: ASbGnctDllZJ+n6w27UgHv5Fup4C38tSon0b77JFGPtgi0MyU7CeTia3b/HbFfMFU2Q
	2f4K3In9UaR5FKbp+wtdXRlIFXwVCswP5dx143ws0CrgPW+nn7mUrj0t6l2xtUZIg3kbA6CT+Md
	ygBI9RXiqVWkLMtoFpCqX2z77Q90U4g+EoQ1BnegPDhWTfCRbA5vJC95emz6ipfRG4g/0wKn/GF
	ciuHRmrQTKFrcRWwK8MflU/doSDkTbGj5nSkF032c5ET/Yem65J+9ntMdEbwlrG99O6Egu9QGcg
	IBQVVI9/DJTWO4CeuS1qzGZYOhcOrj8gZwliUndAEw7vRvUFXQqr/6oVsY1iNiJ23ZGlMvV07FU
	sdJ00uLvhkGWsl67LuQno2UuhoJlAlA==
X-Google-Smtp-Source: AGHT+IFk4NTpmq2Tu/p7bd86OBbfSY/Fxt8MVCwrrpuwLk3S2Wx9x7X9FP3OyJySibdNREPQh+Xe+g==
X-Received: by 2002:a05:600c:1f94:b0:439:9424:1b70 with SMTP id 5b1f17b1804b1-45365a05192mr143331775e9.30.1750753932345;
        Tue, 24 Jun 2025 01:32:12 -0700 (PDT)
From: Frediano Ziglio 
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio ,
	"Daniel P. Smith" ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Jan Beulich 
Subject: [PATCH 2/2] xen/efi: Support loading initrd using GRUB2 LoadFile2 protocol
Date: Tue, 24 Jun 2025 09:31:55 +0100
Message-ID: <20250624083157.9334-3-frediano.ziglio@cloud.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250624083157.9334-1-frediano.ziglio@cloud.com>
References: <20250624083157.9334-1-frediano.ziglio@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Allows to load Xen using "linux" and "initrd" GRUB2 commands.
This can be used with UKI to separate initrd in a different module
instead of bundling all together.
Bundling all together can be a problem with Secure Boot where
we need to sign the bundle making harder to change it.
As initrd content does not need to be signed for Secure Boot
bundling it force it to be signed too.

Signed-off-by: Frediano Ziglio 
---
 xen/common/efi/boot.c     | 71 ++++++++++++++++++++++++++++++++++++++-
 xen/include/efi/efidevp.h | 21 ++++++++++++
 2 files changed, 91 insertions(+), 1 deletion(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 2a49c6d05d..87eb8bb8ae 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -849,6 +849,74 @@ static bool __init read_file(EFI_FILE_HANDLE dir_handle, CHAR16 *name,
     return true;
 }
 
+#pragma pack(1)
+typedef struct {
+    VENDOR_DEVICE_PATH              VenMediaNode;
+    EFI_DEVICE_PATH                 EndNode;
+} SINGLE_NODE_VENDOR_MEDIA_DEVPATH;
+#pragma pack()
+
+static bool __init initrd_load_file2(const CHAR16 *name, struct file *file)
+{
+    static const SINGLE_NODE_VENDOR_MEDIA_DEVPATH __initconst initrd_dev_path = {
+        {
+            {
+                MEDIA_DEVICE_PATH, MEDIA_VENDOR_DP, { sizeof (VENDOR_DEVICE_PATH) }
+            },
+            LINUX_EFI_INITRD_MEDIA_GUID
+        },
+        {
+            END_DEVICE_PATH_TYPE, END_ENTIRE_DEVICE_PATH_SUBTYPE,
+            { sizeof (EFI_DEVICE_PATH) }
+        }
+    };
+    static EFI_GUID __initdata lf2_proto_guid = EFI_LOAD_FILE2_PROTOCOL_GUID;
+    EFI_DEVICE_PATH *dp;
+    EFI_LOAD_FILE2_PROTOCOL *lf2;
+    EFI_HANDLE handle;
+    EFI_STATUS ret;
+    UINTN size;
+
+    dp = (EFI_DEVICE_PATH *)&initrd_dev_path;
+    ret = efi_bs->LocateDevicePath(&lf2_proto_guid, &dp, &handle);
+    if ( EFI_ERROR(ret) )
+    {
+        if ( ret == EFI_NOT_FOUND)
+            return false;
+        PrintErrMesg(L"Error getting file with LoadFile2 interface", ret);
+    }
+
+    ret = efi_bs->HandleProtocol(handle, &lf2_proto_guid, (void **)&lf2);
+    if ( EFI_ERROR(ret) )
+        PrintErrMesg(L"LoadFile2 file does not provide correct protocol", ret);
+
+    size = 0;
+    ret = lf2->LoadFile(lf2, dp, false, &size, NULL);
+    if ( ret != EFI_BUFFER_TOO_SMALL )
+        PrintErrMesg(L"Loading failed", ret);
+
+    file->addr = min(1UL << (32 + PAGE_SHIFT),
+                     HYPERVISOR_VIRT_END - DIRECTMAP_VIRT_START);
+    ret = efi_bs->AllocatePages(AllocateMaxAddress, EfiLoaderData,
+                                PFN_UP(size), &file->addr);
+    if ( EFI_ERROR(ret) )
+        PrintErrMesg(L"Allocation failed", ret);
+
+    file->need_to_free = true;
+    file->size = size;
+
+    ret = lf2->LoadFile(lf2, dp, false, &size, file->str);
+    if ( EFI_ERROR(ret) )
+    {
+        efi_bs->FreePages(file->addr, PFN_UP(size));
+        PrintErrMesg(L"Loading failed", ret);
+    }
+
+    efi_arch_handle_module(file, name, NULL);
+
+    return true;
+}
+
 static bool __init read_section(const EFI_LOADED_IMAGE *image,
                                 const CHAR16 *name, struct file *file,
                                 const char *options)
@@ -1492,7 +1560,8 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle,
             kernel_verified = true;
         }
 
-        if ( !read_section(loaded_image, L"ramdisk", &ramdisk, NULL) )
+        if ( !initrd_load_file2(L"ramdisk", &ramdisk) &&
+             !read_section(loaded_image, L"ramdisk", &ramdisk, NULL) )
         {
             name.s = get_value(&cfg, section.s, "ramdisk");
             if ( name.s )
diff --git a/xen/include/efi/efidevp.h b/xen/include/efi/efidevp.h
index beb5785a45..b240c15d2a 100644
--- a/xen/include/efi/efidevp.h
+++ b/xen/include/efi/efidevp.h
@@ -398,5 +398,26 @@ typedef union {
 
 } EFI_DEV_PATH_PTR;
 
+#define EFI_LOAD_FILE2_PROTOCOL_GUID \
+    { 0x4006c0c1, 0xfcb3, 0x403e, {0x99, 0x6d, 0x4a, 0x6c, 0x87, 0x24, 0xe0, 0x6d } }
+
+typedef struct EFI_LOAD_FILE2_PROTOCOL EFI_LOAD_FILE2_PROTOCOL;
+
+typedef
+EFI_STATUS
+(EFIAPI *EFI_LOAD_FILE2)(
+    IN EFI_LOAD_FILE2_PROTOCOL      *This,
+    IN EFI_DEVICE_PATH              *FilePath,
+    IN BOOLEAN                      BootPolicy,
+    IN OUT UINTN                    *BufferSize,
+    IN VOID                         *Buffer OPTIONAL
+    );
+
+struct EFI_LOAD_FILE2_PROTOCOL {
+    EFI_LOAD_FILE2                  LoadFile;
+};
+
+#define LINUX_EFI_INITRD_MEDIA_GUID \
+    { 0x5568e427, 0x68fc, 0x4f3d, {0xac, 0x74, 0xca, 0x55, 0x52, 0x31, 0xcc, 0x68} }
 
 #endif
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 08:32:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 08:32:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023385.1399364 (Exim 4.92)
	(envelope-from )
	id 1uTz5H-0003eR-Uo; Tue, 24 Jun 2025 08:32:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023385.1399364; Tue, 24 Jun 2025 08:32:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTz5H-0003eK-S4; Tue, 24 Jun 2025 08:32:51 +0000
Received: by outflank-mailman (input) for mailman id 1023385;
 Tue, 24 Jun 2025 08:32: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 1uTz5F-0001zK-W9
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 08:32:49 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20621.outbound.protection.outlook.com
 [2a01:111:f403:2417::621])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cd4e9db0-50d5-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 10:32:46 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by DS7PR12MB5815.namprd12.prod.outlook.com (2603:10b6:8:77::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.28; Tue, 24 Jun
 2025 08:32: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%4]) with mapi id 15.20.8835.027; Tue, 24 Jun 2025
 08:32: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: cd4e9db0-50d5-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Q0TfRwBadpRQ0VsfioR97EMC/EEP/I5cueS5zLo5UXWNO0dTsdOQXgjlu3oT5y+0WX2K7Clg1spZuUCV5tZ5IQHaVHQIzfG1W4buTrZHRnAT4M/9Nd9me8w8nt+y+jWc8Q+K6YICQfTp/uWacTEvWTfW7l4GKJiO71//YA6kOzdFXG4qUnMgy8IrP2GyYox60JmIZigVPdXyQ4F1EeUK+fxEBe2CItnWWvPtdplEGshbDR2JzMLHRJPjUYiD30vsTE6cPx9NoniiPKpHAKHlCcPW1SrGXlzGvLFnPk8R8UsjS2FpZv0oHx4UVDyIAbc3lIByPL2YkliVLBtfbmSlMw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=riykvut66DTxk6YJ7YMoyfqs5HLJBG2e0oJy/dPBol8=;
 b=tKoyQGhy1JH8L1juuFwoAoWedcBMBG2MVQ5Yl8H7KJNBRpvaXFQxn54rUruotAuqnZQc2Q4meWOYX+YlxjKCLWuc93JY/6R5A5elEqNKB4TfSY2YhUxkV9d7toOngIibp6IoTZ0FIHAPcmwjVYRDQLgiKUCkntXbJ1LoxEMKE+pDq2rhkbfryj6GWTAGzPz8QNk8kUwigip5IBz0iubw4LuiLVAkkjc/v/U7+GAICd/n8p3W0017YfKlNaZtdaEeht28viAI9A9oNUjkdt1ISg8CLLAECdnL5rcv0BGhtOv/2o834Q97XpTyCCJIu2V8fAyoSE7LZ+efZ3LQe5c6mw==
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=riykvut66DTxk6YJ7YMoyfqs5HLJBG2e0oJy/dPBol8=;
 b=g0w7vyR78IQfrxm4VczUaiATqxX/SRUOKAO8/R3+9XxRE4rDxph+h+VSiiOnaN5zW5RZRlx+ixQCNLZqxRifxAwKeK7FRo9WYHXi1gt1HFiN9E/hNQ4sqK82kib1Yr/njzXR/IuADclI6FzAoo/7bnzKUq0xfV1pQzWN1gneko0=
From: "Chen, Jiqian" 
To: Jan Beulich 
CC: "Huang, Ray" , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Andrew Cooper , Anthony
 PERARD , "Orzel, Michal" ,
	Julien Grall , Stefano Stabellini ,
	"xen-devel@lists.xenproject.org" , "Chen,
 Jiqian" 
Subject: Re: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
Thread-Topic: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
Thread-Index:
 AQHb23yakGdVC9XxvEWnYcnp8zrTt7QJBRKAgAGLVICAARN8gIAG6YaA//98XQCAAIcUAP//fCSAgACGWwA=
Date: Tue, 24 Jun 2025 08:32:40 +0000
Message-ID:
 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-3-Jiqian.Chen@amd.com>
 <1634c18d-e54e-4105-8b30-6f3085bace22@suse.com>
 
 <23293ec5-7466-400c-87a4-1482577b91fa@suse.com>
 
 <0cf4679d-ee86-4666-adae-63a3f9b9b8f7@suse.com>
 
 <3eaaa6c8-d696-4eca-913e-6e6fd9e618d3@suse.com>
In-Reply-To: <3eaaa6c8-d696-4eca-913e-6e6fd9e618d3@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.8835.025)
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_|DS7PR12MB5815:EE_
x-ms-office365-filtering-correlation-id: 9b51f1cf-fe16-489f-77ac-08ddb2f9aea5
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?WWtUMWxmbjMrYjJkK3R0Tk1MUkt3NWpSUUNBUzdtTGJrU0hKUHVWbzZPUkF3?=
 =?utf-8?B?NVJUb2M1d0xaNEtXZ1YzMFBoWTE4dmI2dTVvWkJYd1UzUHpKbVN0SUtadFVB?=
 =?utf-8?B?NTBib1RlWjhzY2llMVFWSHVQRlMyWjJIbXJaSDFLcVprSmMvYXFvd2ZKMFlQ?=
 =?utf-8?B?SlNnaE1aRzJvWElveE1HQ1VNaEVZb05pQ0N3SlQxTjNmQVJwOW9UdjlvYk1D?=
 =?utf-8?B?UU9tYWs1czFleENuOFE2MzFJNzVOQzhkN2lTZEdmdW1wOGNuTjZWZTlXem13?=
 =?utf-8?B?ekIzNVd1VStjK1FCeUU1aTdhVTBBNTNJakRRMlBxVW5rRU1iZkt4MFdKd2xn?=
 =?utf-8?B?RHN5ZkttNTh0NFRHNXVjSW9pc3I3OTJ4UGU1QU00cW1tVlJqV1o5Mno5K01u?=
 =?utf-8?B?bm5iTUxicWpPQ0tHa0RIZTFOcEo0UVdkS2w5VFNVYi82Mm5DYUlDVkNPanh4?=
 =?utf-8?B?ckNXWkNNUDV0R0RUamYvK3haWllFZHVRNitNTFhjTjBCV08xZHJoZlJzQUJV?=
 =?utf-8?B?NWltWXowQ3c0d1Rzai81VEMxQnNITUxjK01VTTdzMGhEMUVXWVBPV1VpQU9n?=
 =?utf-8?B?MEZpZHN4c1U4ZTJuTVI4WGgzOFV0Q3d3UXVPRU1GbVhTVWowSnlET0UzZGRt?=
 =?utf-8?B?cldDRCtpOFlqaFl4SU4zaGMrdm5XQkUwbUV2UTFiWE9QaGZ3VG54ZUwyTnpo?=
 =?utf-8?B?enBQRWdLcWFKNS8vQXFEVU40cmdTeFpkbHNoMUlvaWtUZUdLYWYvNiswOXBU?=
 =?utf-8?B?eDZRVFYzUVhEaUorb3Z6QzV4VUY5aUlDTUJ4anZrbzREQU9XMTJiNDduKzZC?=
 =?utf-8?B?N0lsNnYxc3RoYXZZRUNsNkY3R045djFDdHZrTkN1VmJKUzM2VUswWHNyRXZn?=
 =?utf-8?B?Nys0V05mUDZQRE92QnpFSlpGdHBMRFI0eHJDUCtBb3ZDSk9lVEJkNmRWOWlR?=
 =?utf-8?B?bXNpUTNYYU9pajVXTjBFbUJIQTYrWERXVVZCQ01NaklISGlyNWtKMy9VNVda?=
 =?utf-8?B?cEM4RkJkMFNUUG03Y29Wb1o3WmZjSmIrYlQzOHFOaEVXbkpub3dNYzY5dmE0?=
 =?utf-8?B?b1oxVXBqM1RDMlIrMHc5TDE1MXBLbXNBQlJiT0VBRitJc1p5blVZTHh2VUV0?=
 =?utf-8?B?Y29pMTMvSEVLeDBkYmVyaThxdVlxbVF4RndjKzhZa2NpZmJhY0NSRlpoQ05x?=
 =?utf-8?B?elo4TzRYd2hzWmtrOWhWM0xMYjVJM3RrL3ZWRG02L0FFbzJBZ09oeUYxT2Jz?=
 =?utf-8?B?SUwvbWx1VjVNS29pVlNWRm5Ob1BnSzd6TWw1bUlyb0xoY3ZjNGduWndjUWZI?=
 =?utf-8?B?ZmRIcmpXYzkwcjlPbmJ6Z1pyRXhvV2ZvbjZxNlQwTGRzTFlaOEFQcVRnNGF3?=
 =?utf-8?B?QWRCVkZaTUdZNTBRMXFJZkFUM0M0eHZxV2pyeFdra3RZS1lzMTlkZld6RUph?=
 =?utf-8?B?OWdyZFMyamE0ZnBhU3dLcGJTbUlCMlFLWnhjaHpMTy9ndHQvNTU4VGVKbG12?=
 =?utf-8?B?UjJIVE5sSzBrZVdtVnZPSXh4RnpQS3ZFOHdwcHdSdzErdWVmUWlGTGJpUEsw?=
 =?utf-8?B?Z2xlMk5VU0NwbldSQTVYdjhGbm9Zc2FCNnptY0EycTlYVkh0dUJFOFk1aDVI?=
 =?utf-8?B?S1NNbStaY245eXBPclhmeWhGSzFpdUU2ZVJYUWNKYkdFRkptWEF2Tjd3UG5i?=
 =?utf-8?B?MnBTK0RUcHVPQUhLTWkrMzhGTndGS0RqQUtsMkV6eEVlYVRDeGt4bzNxZmMw?=
 =?utf-8?B?eG01ME9ieVo4ZFdKNGdORXUzWlpzZFpRb3A3cWNVSFpCSnlFcGVwWkRWM2R2?=
 =?utf-8?B?V0JaYklQTnJ4RDhLNlZPd2V1WnlDWkN0Ti9QZFc4dG9tRFNpbWFrK3NpM2to?=
 =?utf-8?B?VVFhOE5wajRjRGxQM2RGOVNUdU9TekU5WTMrNlF3aXUxTm1xOE82dUdQczA3?=
 =?utf-8?B?WGZscUpvbHE3MjJlUVM2QnppdEZCeVVnUzlKTlFhMTR5SUdYUENRVzdlcXB1?=
 =?utf-8?Q?UtaG8oZZotEgRSJxQEGS1EATbVXClU=3D?=
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?aW1iSjNjVW1TRk96R0hheEsvZHdlaFU5RWZkbGZ6Ujd5dmxaYkpSQVpyVEZl?=
 =?utf-8?B?by9SaTgxM3piMjREWlhpOUNxOFY3dXRSWTRXN1M3TTE5aFNmUjZCWEVoNXo1?=
 =?utf-8?B?aExoSHd2bEZPMkJqNlJkaVBSN2dncVdDdlJnVjA0MmdPdlRQVUJJTy9rTWkr?=
 =?utf-8?B?Vi93b2lVb2FCRWE4bUtYUnhpSUFvTzBqRFQzdDdkVkJjWUltb04wUjh1MVVJ?=
 =?utf-8?B?TkNYcHVnL2tzUEpTbWZKZ1BOd2tFTGJ6NTI2ai9BeVVHbXFXRjhkVXdZU3J0?=
 =?utf-8?B?S1FqWXYzZFdRR2U4WVZuZ2hGOFZPaXF2RkNub1plVk9PR1hQV2pXK2dsR1pZ?=
 =?utf-8?B?Zzd1bW5WUk92WXExU3grc3lPYmNlcHdRN0lLaFVQRUtWYWNLVlMwV3ZEa3hm?=
 =?utf-8?B?dkhFdnU0L0ZTdTFscUtKZDFHeTV2b2RoMTIvYW5KUjNlbE4xRmJBQnlSVXBV?=
 =?utf-8?B?NHVWRDZYdjU4bU5SZUQzb1hLSXUrSFpTMGVPOEdxQ2hlL0lWalMvMjFDdVMw?=
 =?utf-8?B?bUlCNmpVTnk2bm4wWElEbWozczR3d0V1Qit6SlFNTm1ZTUdVcGNFU0xGWVlK?=
 =?utf-8?B?OCswZDE4MTEyR3BJN2N4dmdWdFJuaE5jUmYzOVNYSUpaN1ZSdEtoN2NlKzdl?=
 =?utf-8?B?U2hRYTRYSWczdmpjNlAzS1BndDA2TkhlbnZhRGRmam9DKzhUdmZ2d0F3Zll4?=
 =?utf-8?B?cVlGdnpZTCtTeU94V3Y1cW5IYy9pblhXU1czYWlKZVV3djkwd1I0NUlNUnlz?=
 =?utf-8?B?dEg3N2RlK2ppUFovNXVYOVRWLzlDYnNYbmh0MHBOUHkvN1o2UGdxQlAvMmlh?=
 =?utf-8?B?ZDNNaG9UZUlHRlBRZm1OQ3VZSFVEeUhpNFM0YjFYQk1jbzdoN2M4OE5lb0Vz?=
 =?utf-8?B?WDhKQWpCWGlFYm1VVWprUFhqRW5tY2hhK01XMDI2Y1NKOFV3aGtKNitlbGVS?=
 =?utf-8?B?L1g5b0c1SGRlT09JOXVKMkdOUUxoMnVZbTZGekF4QlNUaUxaaUdDc0dzeXVu?=
 =?utf-8?B?ZWcwMkpaVjNoRlpqOW45UURFTjJXSU8rYWdCMkN2NkVod084bStZNVUyMWln?=
 =?utf-8?B?Mjdvc2c0eVhROEdhNjZUTkFYSzZFdjUxYkR3TFZTUzVhbHArWUcySVRNaWZ2?=
 =?utf-8?B?TllrSys0ZnhqU0tJcG9ha2FoMTF0Vk9ac3Q3cndXMEdpZnpKbWNzZ2ZUaFJO?=
 =?utf-8?B?andXWGhhMEJuaUhjWlBNMXQzTE44aUxZNlRlZUNvdys5ekJBcVJReDR0L1c3?=
 =?utf-8?B?bDFYZzJuaFBFUm5VTGlVaUR1TWI5WUkzS2xUZjhzd3BybFkyeFZtRUhrNFdr?=
 =?utf-8?B?QVNGOTV5ajRkZGIwM0tVRFk5cjVqZUNpV2R4dm1lMHlFbWx3M05sSnc0NUxs?=
 =?utf-8?B?RzVZbjREVWw4L000dFdEcDhFY0dBTW9DN1ZKU3NDL3hQYXQ4bFd5Z05WNHZT?=
 =?utf-8?B?cDRjMVpzYm13N3RvbExoVjVMOWJOOG5aY1lyVUhxNjNrRTlTWVlHU2Qrc2pu?=
 =?utf-8?B?MGFTY2daUE1CazJuTk5aYjhNemlyM0F6dlRwb2pET3hNSU5nMlFiem1MM2NY?=
 =?utf-8?B?OTRvQzMyQVN1NVF0TE5hNUhoSWlaN2Y5NkQzMmFxaXQ5d0NTaS9odVRxSWxS?=
 =?utf-8?B?c3dlMWhUdCs5TmpLdUJVVUY4S3FRKythRXNmM3RHL21iZDZaTkxnK0tHek9a?=
 =?utf-8?B?dXdnNUhKaWtKZW9BUHd5UitpOGhrVlFSUDgyZVV6ckZEQXd6U2Q4UEh6TnNi?=
 =?utf-8?B?Y3NUVFdoUUtXZStoaWxWQVdETE9VSVNwTUkreHRVTG9yVW9Eb0p1VkRqZEds?=
 =?utf-8?B?dVRqd0xGZElJWWlmdlk5dVhvSUxRVXp5U0E0NUcxMGg4R1J2UTdwMGU5eDkx?=
 =?utf-8?B?dFpJTmZvSWkyUFJUbGZUa0FHaXBGczJjSitLazd3b2JvUWlXV2JNc0laOGYw?=
 =?utf-8?B?UkNqSFhMNDdtejJhaVk5M0VibXl0ZXNzL2t5QUhlRWxoNkt3aXZLOEZaK0h0?=
 =?utf-8?B?YjNuRDFYNG9mN1o4YjZwMytwUlpwL3BEbVRuZkE5SkV1aEllV1A4ZzhsK3lm?=
 =?utf-8?B?ejcxcGVLdEt3Z3FDckdRMnprUGdiMDJjU1hQYTZiTTBBYStGTGpJRExqc2ds?=
 =?utf-8?Q?fwR8=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <1F1D50AFCC1FF14F82765F81A9B1CFD6@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: 9b51f1cf-fe16-489f-77ac-08ddb2f9aea5
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2025 08:32:40.2792
 (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: SE5FEKmIsn3kC0TgmAbhst+g6AJ/LL0DHjp+hIZ6mqBGqSIbt2qyCv6yun9mn5/sd/E5TjjbeKNlOvFvD/KI8A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB5815

T24gMjAyNS82LzI0IDE2OjI4LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMjQuMDYuMjAyNSAx
MDoyNiwgQ2hlbiwgSmlxaWFuIHdyb3RlOg0KPj4gT24gMjAyNS82LzI0IDE2OjE3LCBKYW4gQmV1
bGljaCB3cm90ZToNCj4+PiBPbiAyNC4wNi4yMDI1IDEwOjEyLCBDaGVuLCBKaXFpYW4gd3JvdGU6
DQo+Pj4+IE9uIDIwMjUvNi8yMCAxNDozNCwgSmFuIEJldWxpY2ggd3JvdGU6DQo+Pj4+PiBPbiAx
OS4wNi4yMDI1IDA4OjE0LCBDaGVuLCBKaXFpYW4gd3JvdGU6DQo+Pj4+Pj4gT24gMjAyNS82LzE4
IDIyOjMzLCBKYW4gQmV1bGljaCB3cm90ZToNCj4+Pj4+Pj4gT24gMTIuMDYuMjAyNSAxMToyOSwg
SmlxaWFuIENoZW4gd3JvdGU6DQo+Pj4+Pj4+PiArfSB2cGNpX2NhcGFiaWxpdHlfdDsNCj4+Pj4+
Pj4NCj4+Pj4+Pj4gQXMgeW91IGhhdmUgaXQgaGVyZSwgLi4uDQo+Pj4+Pj4+DQo+Pj4+Pj4+PiBA
QCAtMjksOSArMzAsMjIgQEAgdHlwZWRlZiBpbnQgdnBjaV9yZWdpc3Rlcl9pbml0X3Qoc3RydWN0
IHBjaV9kZXYgKmRldik7DQo+Pj4+Pj4+PiAgICovDQo+Pj4+Pj4+PiAgI2RlZmluZSBWUENJX01B
WF9WSVJUX0RFViAgICAgICAoUENJX1NMT1QofjApICsgMSkNCj4+Pj4+Pj4+ICANCj4+Pj4+Pj4+
IC0jZGVmaW5lIFJFR0lTVEVSX1ZQQ0lfSU5JVCh4LCBwKSAgICAgICAgICAgICAgICBcDQo+Pj4+
Pj4+PiAtICBzdGF0aWMgdnBjaV9yZWdpc3Rlcl9pbml0X3QgKmNvbnN0IHgjI19lbnRyeSAgXA0K
Pj4+Pj4+Pj4gLSAgICAgICAgICAgICAgIF9fdXNlZF9zZWN0aW9uKCIuZGF0YS52cGNpLiIgcCkg
PSAoeCkNCj4+Pj4+Pj4+ICsjZGVmaW5lIFJFR0lTVEVSX1ZQQ0lfQ0FQQUJJTElUWShjYXAsIGZp
bml0LCBmY2xlYW4sIGV4dCkgXA0KPj4+Pj4+Pj4gKyAgICBzdGF0aWMgY29uc3QgdnBjaV9jYXBh
YmlsaXR5X3QgZmluaXQjI190ID0geyBcDQo+Pj4+Pj4+DQo+Pj4+Pj4+IC4uLiBfdCBzdWZmaXhl
cyBnZW5lcmFsbHkgZGVzaWduYXRlIHR5cGVzLiBJIGRvbid0IHRoaW5rIHdlIHNob3VsZCBhYnVz
ZQ0KPj4+Pj4+PiB0aGF0IHN1ZmZpeCBmb3IgYW4gaWRlbnRpZmllciBvZiBhIHZhcmlhYmxlLg0K
Pj4+Pj4+IFdoYXQgZG8geW91IHRoaW5rIEkgc2hvdWxkIGNoYW5nZSB0bz8NCj4+Pj4+DQo+Pj4+
PiBXZWxsLCBpZiB5b3UgdGFrZSBteSBvdGhlciBhZHZpY2UsIHRoaXMgcXVlc3Rpb24gd29uJ3Qg
bmVlZCBhbnN3ZXJpbmcsIGFzDQo+Pj4+PiB0aGVuIHlvdSBvbmx5IG5lZWQgdGhlIC4uLl9lbnRy
eSBvbmUuDQo+Pj4+Pg0KPj4+Pj4gQnR3LCBub3RpY2luZyBvbmx5IG5vdyAtIHdoeSBpcyBpdCBm
aW5pdCB0aGF0J3MgdXNlZCB0byBkZXJpdmUgdGhlIGlkZW50aWZpZXI/DQo+Pj4+PiBXaXRoIHRo
YXQsIGl0IGNvdWxkIGFzIHdlbGwgYmUgZmNsZWFuIChsZWF2aW5nIGFzaWRlIHRoZSBmYWN0IHRo
YXQgdGhhdCdzDQo+Pj4+PiBvcHRpb25hbCkuIEltbyB0aGUgbmFtZSB3b3VsZCBiZXR0ZXIgYmUg
ZGVyaXZlZCBmcm9tIGNhcCwgYW5kIGl0IHdvdWxkIGJldHRlcg0KPj4+Pj4gYWxzbyByZWZsZWN0
IHRoZSBwdXJwb3NlIG9mIHRoZSB2YXJpYWJsZS4NCj4+Pj4gSSBjb25zaWRlcmVkIHRoaXMuDQo+
Pj4+IEkgdGhpbmsgaXQgaXMgZWFzaWVyIHRvIHVzZSBmaW5pdCwgYW5kIGZpbml0IGNvbnRhaW5z
IHRoZSBjYXAgdHlwZSwgYW5kIHRoZSBtYWluIHB1cnBvc2Ugb2YgdGhpcyBzdHJ1Y3QgaXMgdG8g
aW5pdGlhbGl6ZSB0aGUgY2FwLg0KPj4+DQo+Pj4gWWV0IGlkZW50aWZpZXIgbmFtZXMgc2hvdWxk
IG1ha2Ugc2Vuc2UgZm9yIHRoZSBvYmplY3QgdGhleSBuYW1lLg0KPj4gT0suIFdoYXQncyB5b3Vy
IHN1Z2dlc3Rpb24gYWJvdXQgbmFtaW5nIHRoZSBlbnRyeT8NCj4gDQo+IGNhcCMjX2luaXQgb3Ig
XyMjY2FwIyNfaW5pdCBmb3IgZXhhbXBsZS4NCklmIHNvLCBJIG5lZWQgdG8gZXh0ZW5kIHRoZSBw
YXJhbWV0ZXIgb2YgUkVHSVNURVJfVlBDSV9DQVBBQklMSVRZIHNpbmNlIGN1cnJlbnQgY2FwIGlz
IG51bWJlciwgbm90IHN0cmluZy4NCk1heWJlOg0KUkVHSVNURVJfVlBDSV9DQVBBQklMSVRZIChj
YXAsIGNhcF9pZCwgZmluaXQsIGZjbGVhbiwgZXh0KQ0KDQo+IA0KPiBKYW4NCg0KLS0gDQpCZXN0
IHJlZ2FyZHMsDQpKaXFpYW4gQ2hlbi4NCg==


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 08:33:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 08:33:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023393.1399374 (Exim 4.92)
	(envelope-from )
	id 1uTz6N-0004yf-9J; Tue, 24 Jun 2025 08:33:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023393.1399374; Tue, 24 Jun 2025 08:33:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTz6N-0004yY-42; Tue, 24 Jun 2025 08:33:59 +0000
Received: by outflank-mailman (input) for mailman id 1023393;
 Tue, 24 Jun 2025 08:33: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 1uTz6L-0004yM-Si
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 08:33:57 +0000
Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com
 [2607:f8b0:4864:20::335])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f7c20ba5-50d5-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 10:33:57 +0200 (CEST)
Received: by mail-ot1-x335.google.com with SMTP id
 46e09a7af769-73ac5680bb0so35327a34.3
 for ; Tue, 24 Jun 2025 01:33:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f7c20ba5-50d5-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750754035; x=1751358835; 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=rDTE57ohFH1BjvClcBM9belopXhx6lLs32LALQQVjJA=;
        b=OxywZHB6VXAxp3j3hNnxBjBNs8a+RAbkeSYyoqEvloQcpWd9c17rYW0WgZPkm69l7c
         uPi7DVlbCxmoTigpXq8D+LE/jSo2eQod1TpSHiPejXtktMC4h/3+tjFkVi9ppQlhy74Y
         0oBN5WgOuJk7cK++ya3ceDAJFbKxH0ALUbLlg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750754035; x=1751358835;
        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=rDTE57ohFH1BjvClcBM9belopXhx6lLs32LALQQVjJA=;
        b=wMNdHKdKABrIPyhihyop69WUpZQymLe8qTlMwAehpCKFzgKEl73BFUJ+AVXS5TwVEw
         ppVe8ZjPBlC4gZhCx5ReGJFEaxBEn+3Oh/ZBpRokZMu2ZgPSy2Euj4g0QN6Itmf2TtNY
         2pfTMIkMA/8CvtN6kjF6InzDY0yATKhHUjRuWu66QZOiPMUYad3MGuSKmPSaOuHu0KRQ
         lXymydeGpm4ZL5hAYraLvbOL2kfEsvL8FCyTpzUmkULK+HbAyDDiWAOkKP+Gi0RSgNVf
         M8bRLmWGeCXgryvskjGe0jvnMCJksSBJXcQJBLZs9xHrIcE2bmwpTNDL37s1UEHWePKc
         MWEw==
X-Gm-Message-State: AOJu0Yy03gBILonf124DGnhsDxKlIDHRLeZobjyqf5Or5bEJtm64nQIH
	VlujfBPBQkyuleIVrngH72YFq0R2q8gtdro1UdLMsAP8OHUUG2CZ0a9X9PbUGCzVs8+JUkPuKEO
	FTtpXpyi0BiPOkxv7bXaczf7KGKF7rI9+wCHwAR0RWU6Q7pJL/cidl5Op0nxc
X-Gm-Gg: ASbGnct8vJsx3SgW5RNrilAvlAlzcKCbPK1x+pFNOixd7saXOfhS7X6+sY0Y8qnHAsO
	TDqHpCRgTHaOvkX9Sw03k597igEFJFDvXFhH/KnbGvBQjQD5Cex7sJ3JLNB0gAnt7All2i3N06S
	o4vUOSNVeV+kNHaPbIUVpkmWZhe+ph5ALJ6iMNPSjgg54rh9BQTho=
X-Google-Smtp-Source: AGHT+IHW5qXKYN9C/5sBMYyWTGRQpN0DIuvJNZ/0bJB3cw8oo5vYnzF/VuCIU4yNTXfJJ0YhrYaDIzmljgIAwwUjodI=
X-Received: by 2002:a05:6870:8306:b0:2e9:4038:83d7 with SMTP id
 586e51a60fabf-2eeda55b6b6mr9666154fac.11.1750754035597; Tue, 24 Jun 2025
 01:33:55 -0700 (PDT)
MIME-Version: 1.0
References: <20250624063611.236876-1-frediano.ziglio@cloud.com>
In-Reply-To: <20250624063611.236876-1-frediano.ziglio@cloud.com>
From: Frediano Ziglio 
Date: Tue, 24 Jun 2025 09:33:41 +0100
X-Gm-Features: AX0GCFuMWtMw47HXhQtceDiRGySBVcO2NZdSHAy8tbPY74fES07hK1mjSVLCR_0
Message-ID: 
Subject: Re: [PATCH] xen/efi: Do not undefined not defined macro
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" , 
	=?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= , 
	Jan Beulich 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 24, 2025 at 7:36=E2=80=AFAM Frediano Ziglio
 wrote:
>

Typo on title "Do not undefined not defined macro" -> "Do not undefine
not defined macro"

> The "buffer" macro is not defined.
> It was defined till commit 59e087bf6a9c8ad805294c32dfd7c77068d81eff
> (cfr "xen/keyhandler: Drop keyhandler_scratch").
>
> Signed-off-by: Frediano Ziglio 
> ---
>  xen/common/efi/boot.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> index ded7cc129d..1a9b4e7dae 100644
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -513,7 +513,6 @@ static EFI_FILE_HANDLE __init get_parent_handle(const=
 EFI_LOADED_IMAGE *loaded_i
>      else
>          *leaf =3D buffer;
>  #undef BUFFERSIZE
> -#undef buffer
>
>      return dir_handle;
>  }


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 08:39:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 08:39:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023401.1399383 (Exim 4.92)
	(envelope-from )
	id 1uTzBK-0005oP-Pg; Tue, 24 Jun 2025 08:39:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023401.1399383; Tue, 24 Jun 2025 08:39:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTzBK-0005oI-MU; Tue, 24 Jun 2025 08:39:06 +0000
Received: by outflank-mailman (input) for mailman id 1023401;
 Tue, 24 Jun 2025 08:39:05 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uTzBJ-0005oC-NP
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 08:39:05 +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 ab7acbaf-50d6-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 10:38:58 +0200 (CEST)
Received: by mail-ot1-x32a.google.com with SMTP id
 46e09a7af769-73a9c5ccfcdso2338527a34.0
 for ; Tue, 24 Jun 2025 01:38:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ab7acbaf-50d6-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750754337; x=1751359137; 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=3fdVqUv9Dx1b2vakRY+bKPqpAC4603RhipA/F0JK1j8=;
        b=SDi9nH9H2rubkvkfrREw+0FFjSgrc6dlxoMngv8mlvgJ1H0ysRJTrAeVv0zWkifguF
         8kznDJX24OUB2FYOaHJT7KzurEYmwVbgr+jRQF/+mHpL1x2Zw9XKjEXIZ7fGOruLW6aW
         w4YmuuoGuMflOolEnE06Qmt6UHy0h4tY6o0Vc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750754337; x=1751359137;
        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=3fdVqUv9Dx1b2vakRY+bKPqpAC4603RhipA/F0JK1j8=;
        b=EP22OFNOsx6opdvlY6aR1D46HfvwEq1/1yR3OXivfu/Ofi4ODiTtnXpqmLgWFXYmT3
         O5kgAd6fR5p1N/KnR/Ml8znXKNEOi6cTGTBbVruxtWl8FZrvU5ZFzlV+TqX6wNiC8o7F
         xd6aJLST7Z3hCJldmAa82rWSFo1Y4K0OOMWXDV3mRXuHSLSbo1MrVCkf7ATL9bITWiNW
         aNTJS7OO3bmdT67pn9/xjaxL5MVvqCQ0qkpSCMkcvAzIBcMCyJXQRItAzOes8vHS9FnW
         CpzG6Z1zkzSCuVJkqV3ha9e1WWTvFCgHhGr4xIZEUSdaGb1VH3JALlWLw26QSR68ll4m
         RK7g==
X-Gm-Message-State: AOJu0YxErxvAj+91JHHa6rfs3HiGTGf8lJoNK53qqP0pcY3giiHSl1Hu
	eaP4tYCSkQzxv8K6dwtDyHF5G/IKPWDGQzAoigpj2EUfymXU340BxOSry59ikBBreq0x/Tgv1ml
	nvFzUNDhaDrGEUDrrJ8louOcn8/FlYSV5s3cTGkFA2ACSnBT/ZGbDyk/3PFMd
X-Gm-Gg: ASbGncuGiyelCNfyM46uDr6H/0r6fxTY5FzxY4hy7btG215MwM8my/UHn//I8R7eTY3
	M+8uQ452ekNe/JxeGpAStSPf8eEoFNGr0xmuf0Mg5yISlLzmzGXZ0JEqABJg1xG3Pkj4ef0tkPA
	iHROdxrncZ1vJkjzNqwxsu/4c98dSr9B1PHoy7tZ0W
X-Google-Smtp-Source: AGHT+IHrwOyfG9xQhD0rUrwGqpyLmU+ovT0WF/XyeL5zH/sZXyGDmaSVwWhPjBL8peiR3Z3tcxYQYkDccPnFhHF1OsI=
X-Received: by 2002:a05:6871:729a:b0:2c2:bd31:cf37 with SMTP id
 586e51a60fabf-2eeee3a1368mr12362980fac.4.1750754337171; Tue, 24 Jun 2025
 01:38:57 -0700 (PDT)
MIME-Version: 1.0
References: <20250624083157.9334-1-frediano.ziglio@cloud.com>
In-Reply-To: <20250624083157.9334-1-frediano.ziglio@cloud.com>
From: Frediano Ziglio 
Date: Tue, 24 Jun 2025 09:38:42 +0100
X-Gm-Features: AX0GCFsSRwBTUdbyWPu7LqV1UnazyhdCwS-f7mQkE7nt0Nr1wjzp9uF173Rovnc
Message-ID: 
Subject: Re: [PATCH 0/2] xen/efi: Make boot more flexible, especially with GRUB2
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" , 
	=?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= , 
	Jan Beulich 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 24, 2025 at 9:32=E2=80=AFAM Frediano Ziglio
 wrote:
>
> The combination of GRUB2, EFI and UKI allows potentially more flexibility=
.
> For instance is possible to load xen.efi from a no ESP partition leaving
> a boot loader like GRUB2 taking care of the file loading.
> This however requires some changes in Xen to be less restrictive.
> Specifically for GRUB2 these changes allows the usage of "chainloader"
> command with UKI and reading xen.efi from no ESP (so no DeviceHandle
> set) and usage of "linux" and "initrd" commands to load separately
> the kernel (embedding using UKI) and initrd (using LoadFile2 protocol).

I was forgetting. If somebody wants to test "linux" and "initrd"
command with these changes be aware that GRUB currently has a problem
passing arguments, I posted a patch, see
https://lists.gnu.org/archive/html/grub-devel/2025-06/msg00156.html.
I also have a workaround for this issue in xen but it would be better
to have a fix in GRUB.

>
> Frediano Ziglio (2):
>   xen/efi: Handle cases where file didn't come from ESP
>   xen/efi: Support loading initrd using GRUB2 LoadFile2 protocol
>
>  xen/common/efi/boot.c     | 98 +++++++++++++++++++++++++++++++++++++--
>  xen/include/efi/efidevp.h | 21 +++++++++
>  2 files changed, 116 insertions(+), 3 deletions(-)


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 08:43:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 08:43:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023411.1399394 (Exim 4.92)
	(envelope-from )
	id 1uTzF6-0008Sa-BE; Tue, 24 Jun 2025 08:43:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023411.1399394; Tue, 24 Jun 2025 08:43:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTzF6-0008ST-7x; Tue, 24 Jun 2025 08:43:00 +0000
Received: by outflank-mailman (input) for mailman id 1023411;
 Tue, 24 Jun 2025 08:42:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uTzF4-0008SN-VR
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 08:42:59 +0000
Received: from AM0PR83CU005.outbound.protection.outlook.com
 (mail-westeuropeazlp170100001.outbound.protection.outlook.com
 [2a01:111:f403:c201::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3a699031-50d7-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 10:42:57 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by AS8PR03MB7842.eurprd03.prod.outlook.com (2603:10a6:20b:341::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8880.16; Tue, 24 Jun
 2025 08:42:55 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%4]) with mapi id 15.20.8857.026; Tue, 24 Jun 2025
 08:42: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: 3a699031-50d7-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Iit312uP3MRbcbgxjaRS2P/TpxaPgzg1TkpUuTieGJbLd6Xg0eNPXGJQg8f5MoHJ65tFtRvrPbUcNZcjQG+D/GEBhyngqqrHQVormhTrfIVP56Bb1pQ8kNiImnGQFoFWepIvlhj5NbyXYy6KDpQeWGYo18T6VO9Qm4DX3JkDanD2SvA+SYPXUs4lSfbkEcXAV+p6pSIxHKAdk4sy58B84lndAofodcrfcGF8r31VgpdphJEODn2wbGyHTa1oq+nlTr9FoVhAqAfkf8goWxe1F0YgZQL7Z7rfJKfjed9KgOmfJsCrBbRe56m2BtXpz18fV22fsfXjtMuYRoolR5oGug==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Y6AqxD5ErG783J2e0aZ8UpWyddV+VlzDQvc5JJ1As78=;
 b=kPsgLfupNe9tH0e7iuKG1ZeWBRJBrXXwkyaiBmQ1EZ+SEU70oYjIamMw3gbX6+hLxvulY89HzUAi8kZcpvaZaRG3W7q8wG+O35uKZEZN1cWoDNx1vlck7SyCZHZO89FWsa8CCeldf+1PwKpa5hAdjqJz902P5kw1zXFOy4Z4iMyXP+qSsWxUfWlmZArAn1K4I28nKTgEgzDowJ2M0oruoebzo5e7SUw8+DzmNYQIKc6o/gfoELMqG4T5FOF87PJlf78jrX/HJFGNFXaqZPUxRFfMePTiElvCFX/oMGfnXzZrYIkGXX8SraOybBPx4qsY6hJv8YrVrZLOejJ262W1zw==
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=Y6AqxD5ErG783J2e0aZ8UpWyddV+VlzDQvc5JJ1As78=;
 b=d6n13J7IgD5dG8/npmERXIyyRPedZU0Ls8jfHGtrDqX2818Fd03NEtG6Htag7reXi4kWVegrkoSxwfv8JqB6UBn5jPHxVzEAC73np22u0StwrnM4UIOz3cPV4ibr4lSvoZJFHPGmXMWpsffe0FcN7M/wiXsmuIpbBCw/3UzQqbcsS8zTxxrdQvvj4qvSDRjVRyhdpHkbkNk/uWDrpJImNLHOXHi1yIAKOOwD5u8ylO04yTwZ/RJ5ykwD3ON0+2U129NhEXMOI/jivdUCdh09L5o4VA/A9xhdbPngx1usNknz+W+zfQpwQe8xZ7xEJgBqhfWunXXf7iNrLeKGshyLnA==
From: Oleksii Moisieiev 
To: Stefano Stabellini , "jbeulich@suse.com"
	, "roger.pau@citrix.com" 
CC: "xen-devel@lists.xenproject.org" , Andrew
 Cooper , Anthony PERARD
	, Bertrand Marquis ,
	Juergen Gross , Julien Grall , Michal Orzel
	, Volodymyr Babchuk ,
	Grygorii Strashko , Roger Pau Monne
	, Jan Beulich 
Subject: Re: [RFC PATCH v4 5/8] xen/domctl: extend XEN_DOMCTL_assign_device to
 handle not only iommu
Thread-Topic: [RFC PATCH v4 5/8] xen/domctl: extend XEN_DOMCTL_assign_device
 to handle not only iommu
Thread-Index:
 AQHbyNXPDXt2FT3RV02cltfdm/Dd7rPdzmiAgCG+LgCACKrsAIACoXoAgAUPLACAAk4fgA==
Date: Tue, 24 Jun 2025 08:42:54 +0000
Message-ID: <4b69568b-3b21-4426-b78a-222ca11632e4@epam.com>
References: 
 <4f58bf9c47c40413ee9250c4cd21458382aac857.1747669845.git.oleksii_moisieiev@epam.com>
 
 
 
 <1780646c-cb6f-4508-86c8-a573fbc09f6a@epam.com>
 
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: PAVPR03MB8946:EE_|AS8PR03MB7842:EE_
x-ms-office365-filtering-correlation-id: 0c2fd0f6-a8ee-43f5-ff3c-08ddb2fb1cf9
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|376014|7416014|1800799024|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?VVNJSGhaVHZPZlYzSGpRZ3B6VVF5bDBSWjJnYklDQVAxT1ZPRGgrY1I1RXF3?=
 =?utf-8?B?RitFOEQvZkE4TE90R2EyVlZhaDNRY2pzdjhEMUQ1eHc1REZmdVN3UWpZK1Vn?=
 =?utf-8?B?S2gxZTM0N3gwTS9mTUtYaHdlQXIzMjJVbCtsOGpoejhCV0N2YjNDZ0REY2dp?=
 =?utf-8?B?WTdPT2JIOGFYTUY3SFJUb3JvSnN0MjBxcXZvS2dmaXZwUG5RUGZ0WlBMK29r?=
 =?utf-8?B?ZkVRWmR4bXFUWXFRQ1pOamlkUkpVRmRFdlk0Z01KNnpVemdBYStKY2hNaGQr?=
 =?utf-8?B?QTBlOVN1Yk1BUFJ4NXUvcXRMWi8xclo1TGo2MVNkTUhXUHA3MlBnWEJSWkIw?=
 =?utf-8?B?Mno5YVBHd05SbGxBSXlyQlZqR3E1TWUzbERyMEVzS09jdlNGVVc5d3B4MWxp?=
 =?utf-8?B?NXExQkhWdnZkNjRqSWRFVlpna1J6SHYwYXZvUHliYkRXWXhlb2YzcHlaQlU3?=
 =?utf-8?B?OERrK0pBMGcyeDJEQVBZQTA0T2JPSGllZ3JIOGhhRldxcWxNR3VNSkcrM2dr?=
 =?utf-8?B?ZkFqeHgvSno1UndBMit0VXVYbnVuM2Q4M0xiVklLUWhNS1FMYVh5cTBQdGxN?=
 =?utf-8?B?QUVzbUwxaFFyNlpjV2FVQzZhS3BXK05JMGQvSXN0OEZsY29sS2F0cllHNXpM?=
 =?utf-8?B?OWRwRHhZNmY0UlphTGVyT3BEUVc3LytvVkJjYlpsTzdYVytGOU1JamVBOVFr?=
 =?utf-8?B?SHB2b1hKOWtCNGJOZHpBV3NrQk9wSUhHYTltdzd2RjJYdHMrVUNLVDNqMUx2?=
 =?utf-8?B?VGduN3pmQ1dqWkkzOGV2ZFlvUGpFSlc3MS9ValNZcHJBbG1saGt3OVZHUmhp?=
 =?utf-8?B?RTlWUkQxWGtJK2ZsanFLdXROM2hWNHpwWVBqMXAyb3plcVgxdEZuZTM0MDVq?=
 =?utf-8?B?TmQybWJ1TkFoUkVmV0RwNXpSZDhGdXlwV0JFWVJDMmtNd1JzeFIzem1XUXkr?=
 =?utf-8?B?Mlc1eFdWUEpGYUxYYnlrRGN5Y3ZWRlpqRmJFQllUa0ZrclN1S2lwZWtweXh0?=
 =?utf-8?B?TnQ1eWNveTl4V0Rid1FEYzl3ZnUvd1hUUnBwMHkvSVd2aU40anpTOWVDajZn?=
 =?utf-8?B?UHBLRG45elVVQllNSkVqYUQrWDRnNmpyL2FML1pMTWxBMm96K1hoNk15MDlo?=
 =?utf-8?B?YVZQN0x2NVZpVmVXSDlDaVIyelFLVEdSSW5SRzd3YWt5SnU0c1cvS2t6SUJj?=
 =?utf-8?B?RU1KMjZFdUJUaDFKRy9idTl5NExNVzVzQ0hEN1dMZXh4RGZhdHd0dTgvMW1E?=
 =?utf-8?B?NXNLdjBpRTVOWGdsdW1zRzcwR0QxRmJYZGJxcG5tVGVHMXRpbDNpVzl5czJI?=
 =?utf-8?B?OE5oamRTZGRzMGovV0dLS2VkdFB6OXBMeU4vV0k1Znk4VkxuRUoxNTk3Vnd5?=
 =?utf-8?B?MmhSckVpeVZXQmZYeGpsMnV6T0VWZXoyaVBPaktpdUd6cnhsN25PQnMxV1J6?=
 =?utf-8?B?c2dhWVhSMzN3RWQ0dUZSMld0bTJYNEJiZjlFWm9Dd2FZS0x5NGxEQWxVMGx1?=
 =?utf-8?B?VUV6TzlnQmk0S20ySWFPNW4vRlE5cTBid3JleXJ4Z1dEVXBzdHBCNW9Oa0dO?=
 =?utf-8?B?c3FkeVJuY1N4V1Qrdy9jOUxOY3F1ZmhNR2lWY0FRQmVFRnMyQ2FsQzhhYnN0?=
 =?utf-8?B?R01JZWVuclllcDN6ODBZa1hMd0d5M2R4MHVOOXBISkdLblNqMmJwY0VtZlNz?=
 =?utf-8?B?ZkovckxSQnBLSGdJbEN1eVR6Z0xQeElOOTU1aDU1ZUtnZWR0ZDBGQm8rVm5m?=
 =?utf-8?B?YmtFb09Ycm94ZlpYb2lPOWFsbG9qV3QyWSt3Q1pnTlNZaGljTEt4RVRTZWhQ?=
 =?utf-8?B?OXhTbXNNb3RJMDNYZGpTUFpycDlxUTBFMFF5MkxlTUp6QWdXaDFTWklxNzVV?=
 =?utf-8?B?YVdhR1d1Q3VpdDdyVnl0aUROR1F2d01yM0lyWFFLN0FmMDJLcGFnVEUyRXVl?=
 =?utf-8?B?YkI3cmNCSUVsK1k5bHBaMEprTjNyUHQ5YzFBcEVzbG4xY3VkRmJvWjhGcS8y?=
 =?utf-8?Q?Jq3KSNXrzJjLpdkPCDzLc1EBRA+BTQ=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?Z0F6VnVCUUNnRXltaW0wTVhvellnNGxENXVJYWt1dHhUZTk4Y1pWUGFuSmFn?=
 =?utf-8?B?bTZYT3N0dEZmQ1NQWlNkQVd3eSs1eUtUUkxPcDI4UEFRb3JiZnIvdDAxbm9x?=
 =?utf-8?B?RnAyV25OTXdEUTRtM0Rsd3ZYSnpqbmlFUEVoQ0hwelpxOWFzWU9RR2pmbE16?=
 =?utf-8?B?QjIvaDZpSzhQMmJJa25XOXROZVdKcTN5b3NsY1luRWQ2SU1pVVBBVVQ3aDZk?=
 =?utf-8?B?Y3NJWG9GKzZ2dVBoTHZCTVlXWVAwRFdPdEdweGsrNEdOcUFTTUJtSjFpTlJQ?=
 =?utf-8?B?OEJNZnJqam1jZVBxK2lyREkwSkwrQlV1NGdSVk4vekpJb0EvVWxMS3R0R2px?=
 =?utf-8?B?dkg0L0tEQVdUM1hsRndickNFczJCYit6NVVXc3Q3bmFjM0lNejUxb1YxVmxR?=
 =?utf-8?B?RWZMaUNVb0thVHVDN29Mb1JSY3hiNDlnY0N2NWJacVNMMml5aTlnZnZWSnk3?=
 =?utf-8?B?L3huSlFJU3FjRG9kaUZlS3QvandtcmFUYi9zb2hkcTduNGRZaEN1SjFhZU1X?=
 =?utf-8?B?RGx0emNmVU1xcC9wNGZqemY3VDhNbU9pVEh5WTFickJ5N09XQTZ3V2ZCNDNM?=
 =?utf-8?B?ZFNZNHovTDNlMktSYTcvUDAxbGpRTFBtVSs4QUt2SFZBdmsyOHZqeEVFbTFP?=
 =?utf-8?B?dWJQR2R4UHdUTXRpUHhqZ0xadTJHaEFDZis2NjhmOUxpbkZFb1o1SUh6MitW?=
 =?utf-8?B?dFBWekJsb0UrVkFwSmZSbHlNNEkrRHB0M1J2UG1ITGN1cWhPQTQxWDQxbll1?=
 =?utf-8?B?M0tQakRKWksxaUNHN3czUUlOYUNsZ0lhc21jVndFaTBWSTNFM1lQaW5zRG14?=
 =?utf-8?B?clljYXBWYmhzblVNekF2eUlyNHF6KzR4dGtteGE2aEpUTjY2WHIvZDFrWlRP?=
 =?utf-8?B?WkNraW5ZaldkR0MvUC9xb2tOcG1MOHRONFU2N3NCOERWUUUxSTlRZ1FEaFNv?=
 =?utf-8?B?Q2NKTi9aYlR2d3haTU5SVFVuMUxwYmRhNE1mYVRSM3JsYlpuNm80aFMxQlp3?=
 =?utf-8?B?bk01djRzRUZFUWxEOEoyM0ppRG02VzVTVitjalN4dThUN2Y4ZnVqYmdDNmFT?=
 =?utf-8?B?dGo4V2NZUFBGVjMzS3daT2ZFSC9hcWFKNkN2WUt4TmRPcTRib3AzV1RYdVBr?=
 =?utf-8?B?c21GTnBvNlhCMEwyb3FnVXJNbE1RU0Iyclpxc0s3bCtCZS9rVWt4cVByRjV1?=
 =?utf-8?B?cGlOdGM1enRJenFQZ29ZWUNMTW9BL01qV3VXT05Ndi94MERUbWdSa0NlY3pG?=
 =?utf-8?B?QkdpK2NodEJ3YzE0VHVSYTVRTklBWGppV1Y4cUwxS3ZxRkxueVI2UDcvQ3NH?=
 =?utf-8?B?YkF2bkFhb2txaFV4ZURqVERnUGJoc0NHNkxVTGl4WktaTklTRmk5cFRlN3Y4?=
 =?utf-8?B?dElaSDFYZmxCSFVENjF2NGFrNVNxcWxBODczZGJTenhnY1IxdGw5RTZ4K3V4?=
 =?utf-8?B?dVRlUm1HRXpQTlhiUTk1MkFtbXZ1QjdNV2l1aDNDQ2FCVWE1d0w3U2FZMEVp?=
 =?utf-8?B?TWY2T25ZU2lmRHdQV09Pc1RzbzVCUFY3ZHRJMzZFakIxS3A0MnVlRm9xRjRJ?=
 =?utf-8?B?TmQvLzE2OVUzRVpMY1BlMWgyeGJIcWp5SDdyT2hZaTNyYThISU5jTTFBWVlV?=
 =?utf-8?B?MmN1WGdQemJBQU1WcnRQL0RsOWtUOU9DWmNXeVE3RUxuUU0zT1JQUys5d3JK?=
 =?utf-8?B?UlYyNEtVS3FmWkU3eW1oM0ZNUm5FOEVtay9WY3lMYXFINlZOQXQvWWg5NzRx?=
 =?utf-8?B?Q0FnaHRIb1YyZi9qcVJ1WHlkRE9zcW1ZTWJpdjNLTnowWFlwc3lFNEJWU2dN?=
 =?utf-8?B?TjVxd29RbCtwb2FST0FNN1k5WG11MllUUjF4YzE3bFI0YVoxZWlSaFVTdSsv?=
 =?utf-8?B?ZzZKVm9lektXV2wrTjNUV21VOW5IcThjZ1BsZk1zcFJEL1BNWW5jZVlKM0N6?=
 =?utf-8?B?a3Z2SlZtRkNrVStvVnRsdm1NOXhnRVBBVVl3aWc3WDR1M1JHV202Sml0QWY3?=
 =?utf-8?B?ajZYOEx4dG9POXA3cHA4TlpSVm1jLzBwTnpuUnZZcno3dnlIeERFUEhqN0cw?=
 =?utf-8?B?akhiZmo2K3dHdTZVVlA4T01VWjN0VGh3NjlqR3Y1VkxXbjVuVTUvbFVwM0FW?=
 =?utf-8?B?ODZFSEtrazZ1KzVrY0VZV2RmUVRGS3R5Szgvb2twY0VmdG1laERDbzd1SnFs?=
 =?utf-8?B?eWc9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <11D71BE6B80EA8468D3CBCE288EC2DF6@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: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0c2fd0f6-a8ee-43f5-ff3c-08ddb2fb1cf9
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2025 08:42:54.8603
 (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: KKlsQhx3q1UNVTkszCsOEMqRoBRwe6Exd3ePRoZY8Wx823Wl5IB/7gwXp5zWZwXw2bYpPTNYJNBWtpur0xnSDsiWPTm+HA9T5cOE1rBa++E=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7842

QWRkaW5nIFJvZ2VyIGFuZCBKYW4gdG8gdGhlIGNvbnZlcnNhdGlvbi4NCg0KUGxlYXNlIHNlZSBi
ZWxvdy4NCg0KT24gMjMvMDYvMjAyNSAwMDozMCwgU3RlZmFubyBTdGFiZWxsaW5pIHdyb3RlOg0K
PiBPbiBUaHUsIDE5IEp1biAyMDI1LCBPbGVrc2lpIE1vaXNpZWlldiB3cm90ZToNCj4+IE9uIDE4
LzA2LzIwMjUgMDM6MDQsIFN0ZWZhbm8gU3RhYmVsbGluaSB3cm90ZToNCj4+PiBPbiBUaHUsIDEy
IEp1biAyMDI1LCBPbGVrc2lpIE1vaXNpZWlldiB3cm90ZToNCj4+Pj4gSGkgU3RlZmFubywNCj4+
Pj4NCj4+Pj4gSSdtIHZlcnkgc29ycnkgZm9yIGEgbG9uZyBzaWxlbmNlLiBQbGVhc2Ugc2VlIG15
IGFuc3dlcnMgYmVsb3c6DQo+Pj4+DQo+Pj4+IE9uIDIyLzA1LzIwMjUgMDM6MjUsIFN0ZWZhbm8g
U3RhYmVsbGluaSB3cm90ZToNCj4+Pj4+IE9uIE1vbiwgMTkgTWF5IDIwMjUsIE9sZWtzaWkgTW9p
c2llaWV2IHdyb3RlOg0KPj4+Pj4+IEZyb206IEdyeWdvcmlpIFN0cmFzaGtvPGdyeWdvcmlpX3N0
cmFzaGtvQGVwYW0uY29tPg0KPj4+Pj4+DQo+Pj4+Pj4gQWRkIGNoYWluZWQgaGFuZGxpbmcgb2Yg
YXNzaWduZWQgRFQgZGV2aWNlcyB0byBzdXBwb3J0IGFjY2Vzcy1jb250cm9sbGVyDQo+Pj4+Pj4g
ZnVuY3Rpb25hbGl0eSB0aHJvdWdoIFNDSSBmcmFtZXdvcmssIHNvIERUIGRldmljZSBhc3NpZ24g
cmVxdWVzdCBjYW4gYmUNCj4+Pj4+PiBwYXNzZWQgdG8gRlcgZm9yIHByb2Nlc3NpbmcgYW5kIGVu
YWJsaW5nIFZNIGFjY2VzcyB0byByZXF1ZXN0ZWQgZGV2aWNlDQo+Pj4+Pj4gKGZvciBleGFtcGxl
LCBkZXZpY2UgcG93ZXIgbWFuYWdlbWVudCB0aHJvdWdoIEZXIGludGVyZmFjZSBsaWtlIFNDTUkp
Lg0KPj4+Pj4+DQo+Pj4+Pj4gVGhlIFNDSSBhY2Nlc3MtY29udHJvbGxlciBEVCBkZXZpY2UgcHJv
Y2Vzc2luZyBpcyBjaGFpbmVkIGFmdGVyIElPTU1VDQo+Pj4+Pj4gcHJvY2Vzc2luZyBhbmQgZXhw
ZWN0ZWQgdG8gYmUgZXhlY3V0ZWQgZm9yIGFueSBEVCBkZXZpY2UgcmVnYXJkbGVzcyBvZiBpdHMN
Cj4+Pj4+PiBwcm90ZWN0aW9uIGJ5IElPTU1VIChvciBpZiBJT01NVSBpcyBkaXNhYmxlZCkuDQo+
Pj4+Pj4NCj4+Pj4+PiBUaGlzIGFsbG93cyB0byBwYXNzIG5vdCBvbmx5IElPTU1VIHByb3RlY3Rl
ZCBEVCBkZXZpY2UgdGhyb3VnaA0KPj4+Pj4+IHhsLmNmZzoiZHRkZXYiIHByb3BlcnR5IGZvciBw
cm9jZXNzaW5nOg0KPj4+Pj4+DQo+Pj4+Pj4gZHRkZXYgPSBbDQo+Pj4+Pj4gICAgICAgICIvc29j
L3ZpZGVvQGU2ZWYwMDAwIiwgPC0gSU9NTVUgcHJvdGVjdGVkIGRldmljZQ0KPj4+Pj4+ICAgICAg
ICAiL3NvYy9pMmNAZTY1MDgwMDAiLCA8LSBub3QgSU9NTVUgcHJvdGVjdGVkIGRldmljZQ0KPj4+
Pj4+IF0NCj4+Pj4+Pg0KPj4+Pj4+IFRoZSBjaGFuZ2UgaXMgZG9uZSBpbiB0d28gcGFydHM6DQo+
Pj4+Pj4gMSkgdXBkYXRlIGlvbW11X2RvX2R0X2RvbWN0bCgpIHRvIGNoZWNrIGZvciBkdF9kZXZp
Y2VfaXNfcHJvdGVjdGVkKCkgYW5kDQo+Pj4+Pj4gbm90IGZhaWwgaWYgRFQgZGV2aWNlIGlzIG5v
dCBwcm90ZWN0ZWQgYnkgSU9NTVUNCj4+Pj4+PiAyKSBhZGQgY2hhaW5lZCBjYWxsIHRvIHNjaV9k
b19kb21jdGwoKSBpbiBkb19kb21jdGwoKQ0KPj4+Pj4+DQo+Pj4+Pj4gU2lnbmVkLW9mZi1ieTog
R3J5Z29yaWkgU3RyYXNoa288Z3J5Z29yaWlfc3RyYXNoa29AZXBhbS5jb20+DQo+Pj4+Pj4gU2ln
bmVkLW9mZi1ieTogT2xla3NpaSBNb2lzaWVpZXY8b2xla3NpaV9tb2lzaWVpZXZAZXBhbS5jb20+
DQo+Pj4+Pj4gLS0tDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gICAgIHhlbi9hcmNo
L2FybS9maXJtd2FyZS9zY2kuYyAgICAgICAgICAgICB8IDM3ICsrKysrKysrKysrKysrKysrKysr
KysrKysNCj4+Pj4+PiAgICAgeGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2Zpcm13YXJlL3NjaS5o
IHwgMTQgKysrKysrKysrKw0KPj4+Pj4+ICAgICB4ZW4vY29tbW9uL2RvbWN0bC5jICAgICAgICAg
ICAgICAgICAgICAgfCAxOSArKysrKysrKysrKysrDQo+Pj4+Pj4gICAgIHhlbi9kcml2ZXJzL3Bh
c3N0aHJvdWdoL2RldmljZV90cmVlLmMgICB8ICA2ICsrKysNCj4+Pj4+PiAgICAgNCBmaWxlcyBj
aGFuZ2VkLCA3NiBpbnNlcnRpb25zKCspDQo+Pj4+Pj4NCj4+Pj4+PiBkaWZmIC0tZ2l0IGEveGVu
L2FyY2gvYXJtL2Zpcm13YXJlL3NjaS5jIGIveGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjaS5jDQo+
Pj4+Pj4gaW5kZXggZTE1MjJlMTBlMi4uOGVmZDU0MWM0ZiAxMDA2NDQNCj4+Pj4+PiAtLS0gYS94
ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NpLmMNCj4+Pj4+PiArKysgYi94ZW4vYXJjaC9hcm0vZmly
bXdhcmUvc2NpLmMNCj4+Pj4+PiBAQCAtMTI2LDYgKzEyNiw0MyBAQCBpbnQgc2NpX2Fzc2lnbl9k
dF9kZXZpY2Uoc3RydWN0IGRvbWFpbiAqZCwgc3RydWN0IGR0X2RldmljZV9ub2RlICpkZXYpDQo+
Pj4+Pj4gICAgICAgICByZXR1cm4gMDsNCj4+Pj4+PiAgICAgfQ0KPj4+Pj4+ICAgICANCj4+Pj4+
PiAraW50IHNjaV9kb19kb21jdGwoc3RydWN0IHhlbl9kb21jdGwgKmRvbWN0bCwgc3RydWN0IGRv
bWFpbiAqZCwNCj4+Pj4+PiArICAgICAgICAgICAgICAgICAgWEVOX0dVRVNUX0hBTkRMRV9QQVJB
TSh4ZW5fZG9tY3RsX3QpIHVfZG9tY3RsKQ0KPj4+Pj4+ICt7DQo+Pj4+Pj4gKyAgICBzdHJ1Y3Qg
ZHRfZGV2aWNlX25vZGUgKmRldjsNCj4+Pj4+PiArICAgIGludCByZXQgPSAwOw0KPj4+Pj4+ICsN
Cj4+Pj4+PiArICAgIHN3aXRjaCAoIGRvbWN0bC0+Y21kICkNCj4+Pj4+PiArICAgIHsNCj4+Pj4+
PiArICAgIGNhc2UgWEVOX0RPTUNUTF9hc3NpZ25fZGV2aWNlOg0KPj4+Pj4+ICsgICAgICAgIHJl
dCA9IC1FT1BOT1RTVVBQOw0KPj4+Pj4gQXJlIHlvdSBzdXJlIC1FT1BOT1RTVVBQIGlzIHRoZSBy
aWdodCBlcnJvciBjb2RlIGZvciB0aGUgMyBjaGVja3MgYmVsb3c/DQo+Pj4+IFRoZSAtRU9QTk9U
U1VQUCBjb2RlIGlzIHVzZWQgYmVjYXVzZSB0aGlzIGlzIHBhcnQgb2YgYSBjaGFpbmVkIGNhbGwg
YWZ0ZXINCj4+Pj4gaW9tbXVfZG9fZG9tY3RsLCBhcyBzdGF0ZWQgaW4geGVuL2NvbW1vbi9kb21j
dGwuYzo4NTkuIFRoZQ0KPj4+PiBYRU5fRE9NQ1RMX2Fzc2lnbl9kZXZpY2UNCj4+Pj4gY2FsbCBp
cyBleHBlY3RlZCB0byBoYW5kbGUgYW55IERUIGRldmljZSwgcmVnYXJkbGVzcyBvZiB3aGV0aGVy
IHRoZSBEVA0KPj4+PiBkZXZpY2UgaXMNCj4+Pj4gcHJvdGVjdGVkIGJ5IGFuIElPTU1VIG9yIGlm
IHRoZSBJT01NVSBpcyBkaXNhYmxlZC4NCj4+Pj4gVGhlIGZvbGxvd2luZyBjYXNlcyBhcmUgY29u
c2lkZXJlZDoNCj4+Pj4NCj4+Pj4gMS4gSU9NTVUgUHJvdGVjdGVkIERldmljZSAoU3VjY2VzcykN
Cj4+Pj4NCj4+Pj4gSWYgdGhlIGRldmljZSBpcyBwcm90ZWN0ZWQgYnkgdGhlIElPTU1VIGFuZCBp
b21tdV9kb19kb21jdGwgcmV0dXJucyAwLA0KPj4+PiB3ZSBjb250aW51ZQ0KPj4+PiBwcm9jZXNz
aW5nIHRoZSBEVCBkZXZpY2UgYnkgY2FsbGluZyBzY2lfZG9fZG9tY3RsLg0KPj4+Pg0KPj4+PiAy
LiBJT01NVSBEaXNhYmxlZCAoLUVPUE5PVFNVUFAgZnJvbSBpb21tdV9kb19kb21jdGwpDQo+Pj4+
DQo+Pj4+IElmIGlvbW11X2RvX2RvbWN0bCByZXR1cm5zIC1FT1BOT1RTVVBQLCBpbmRpY2F0aW5n
IHRoYXQgdGhlIElPTU1VIGlzDQo+Pj4+IGRpc2FibGVkLA0KPj4+PiB3ZSBzdGlsbCBwcm9jZWVk
IHRvIGNhbGwgc2NpX2RvX2RvbWN0bC4NCj4+PiBPSyB0aGlzIG1ha2VzIHNlbnNlLiAgSSB0aGlu
ayBpdCBpcyBPSyB0byBoYXZlIGEgc3BlY2lhbCBlcnJvciBjb2RlIHRvDQo+Pj4gc2F5ICJ0aGUg
SU9NTVUgaXMgZGlzYWJsZWQiIGJ1dCBJIGRvbid0IGtub3cgaWYgaXQgaXMgYSBnb29kIGlkZWEg
dG8gdHJ5DQo+Pj4gdG8gdXNlIC1FT1BOT1RTVVBQIGZvciB0aGF0LiAtRU9QTk9UU1VQUCBjb3Vs
ZCBtZWFuIGEgaHlwZXJ2aXNvcg0KPj4+IGNvbmZpZ3VyYXRpb24gd2l0aCBkb21jdGwgZGlzYWJs
ZWQsIGZvciBpbnN0YW5jZS4NCj4+Pg0KPj4+IEl0IG1pZ2h0IGJlIHdpc2VyIHRvIHVzZSBhIGRp
ZmZlcmVudCBlcnJvciBjb2RlLiBNYXliZSBFTk9FTlQ/DQo+Pj4NCj4+IEkgc2VlIHRoYXQgaW4g
dGhlIGZvbGxvd2luZyBjb21taXQ6DQo+Pg0KPj4gNzFlNjE3YTZiOCAodXNlIGlzX2lvbW11X2Vu
YWJsZWQoKSB3aGVyZSBhcHByb3ByaWF0ZS4uLiwgMjAxOS0wOS0xNykNCj4+DQo+PiAtRU5PU1lT
IHJldHVybiBjb2RlIHdhcyBjaGFuZ2VkIHRvIC1FT1BOT1RTVVBQIGluIGlvbW11X2RvX2RvbWN0
bC4NCj4+DQo+PiBJdCdzIG5vdCBjbGVhciB0byBtZSB3aHkgdGhpcyB3YXMgZG9uZSBmcm9tIHRo
ZSBjb21taXQgZGVzY3JpcHRpb24uDQo+Pg0KPj4gTWF5YmUgd2Ugc2hvdWxkIGFkZCBjb21taXQg
YXV0aG9yPw0KPiBSb2dlciBhbmQgSmFuIG1pZ2h0IGtub3c=


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 08:45:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 08:45:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023418.1399404 (Exim 4.92)
	(envelope-from )
	id 1uTzHD-0000a4-M6; Tue, 24 Jun 2025 08:45:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023418.1399404; Tue, 24 Jun 2025 08:45: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 1uTzHD-0000Zx-J6; Tue, 24 Jun 2025 08:45:11 +0000
Received: by outflank-mailman (input) for mailman id 1023418;
 Tue, 24 Jun 2025 08:45: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 1uTzHC-0000Zp-Bl
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 08:45:10 +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 88b4328a-50d7-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 10:45:09 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a50fc7ac4dso101248f8f.0
 for ; Tue, 24 Jun 2025 01:45:09 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d8608d4asm101232745ad.128.2025.06.24.01.45.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 01:45:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 88b4328a-50d7-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750754708; x=1751359508; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=8miDBLok/lM907sVFvUEWVZBUvkM2zC54U64JikRjmo=;
        b=K7xWzFmK1q2Ky3vhimc+aRaC823KGg5128pbaw59H/qDp54J0j77wZZBM13FS6oWz5
         tKn/jg3VEisytTBXxUOTK3f8b2xUO8EgLKBKpAg7bdKT50VD4agQsQoHm/aniImqtskp
         ysq6XQ2iVVJl24vbJK2lgN80z2lvNrpucmuwPf0nPSJJ2h15u+yrLLZZB7xKUjtTkc1f
         GdS/BlujxlC2g+mqogFAbp8YUohFqqAKimbQnRy+jY/HPfFKOlNXKQN0xwfvqSJ11yAX
         JjUyh8YFZG6Au78S8amAjthiETy4vSTUbTKh5wWKLX4mcqp5V2jpZLQjkZWRHysMyyzL
         Titw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750754708; x=1751359508;
        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=8miDBLok/lM907sVFvUEWVZBUvkM2zC54U64JikRjmo=;
        b=hnQjJggCInfknCrnE3t6QcWbJy5wuYIIxIOsow423iLbogen3x0nO3QDEBg34/vZZD
         6r+w2VCpZevs+y7axS07pO5MChV56CvBJggIoRDaCXgPUP0yGzDci6TdgTfIQmYD+GJr
         TMciEuVXeb1imAVDKaKhGHUy4wwTzBLVFNtbeQ2K8HSY29xuMPQnz5DzR82yCO00OWk2
         uK0R51cax0YDa5fgfaqI04V/Op0Uk+G8C5B9evbXeBnBheej0qimjH4MeRqojzopXLc1
         iIU0/g6voJc+767UMGqzUEZsAYyApBhIgw3lE+9rL+S87uL1ZDOv1ht0B40df6Oyim5b
         oK2Q==
X-Forwarded-Encrypted: i=1; AJvYcCW3Gu0/S1avaJ/DK4MXyT5kf/Fda/1Od6ESkq5NerEQL0Rx9T/lMO9mF59fSA5f4a72cdj8K/Bxvbs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxHcGeqn9FN4n4JKpOivzzBh8UGttonH4hR2B9Oup1W1UhdITvI
	piUdBmko8Od94mggnBRarVsSJRWvkK/bu/tj9q63jeLOeA1owVPTVfAkBzWgGgSsig==
X-Gm-Gg: ASbGnctn0VxiInS1dEDhsSjbmseZx0fn/elTO5e8AynvRKbOhGDvEo3YHTTJSkPFfaw
	f10QIprsVwyNSyhBQQZOwN3iJFgfI4F9UV2oH/7viUhqH3gPnHhPr3HUHblq0FOUeYhZbIZw6Oc
	ZcPDR9K00+qxZCD555kRwRrXbtFcV8wjSpBnP/fZcm+rhzOF5HEmRoXJ/f2JluWVB4xXQnoZvrR
	3oq2T2Kdm94oJG5sNnt7vE2dBYdy+npuDOxcyv1O3prHvWDiNNOt/ipdnnzg2+0gqvsWi9pSr0s
	nz9RfgdH15xmmfX6WzfDRWXQPv37+6tXFKwlyOFsYuZcMKu+rEyyhCSqLMSXJtqDksBgTvfByvJ
	b/+7hhsDwgWGxA9POA88HAfwWyPbWMcEYQbf2liXYG39jT1E=
X-Google-Smtp-Source: AGHT+IEamTWLjidQw/vJ1Lq7cC+W/3IirPny9cjAL1lXqqhRufSTPbXH48ErDzeV2hrskdNork0SfA==
X-Received: by 2002:a05:6000:2b09:b0:3a4:dd02:f724 with SMTP id ffacd0b85a97d-3a6d1329a75mr8348679f8f.43.1750754708544;
        Tue, 24 Jun 2025 01:45:08 -0700 (PDT)
Message-ID: <1ea09a95-5f13-4af4-bad1-e7081bf065fc@suse.com>
Date: Tue, 24 Jun 2025 10:44:58 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
To: "Chen, Jiqian" 
Cc: "Huang, Ray" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Andrew Cooper ,
 Anthony PERARD ,
 "Orzel, Michal" , Julien Grall ,
 Stefano Stabellini ,
 "xen-devel@lists.xenproject.org" 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-3-Jiqian.Chen@amd.com>
 <1634c18d-e54e-4105-8b30-6f3085bace22@suse.com>
 
 <23293ec5-7466-400c-87a4-1482577b91fa@suse.com>
 
 <0cf4679d-ee86-4666-adae-63a3f9b9b8f7@suse.com>
 
 <3eaaa6c8-d696-4eca-913e-6e6fd9e618d3@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 24.06.2025 10:32, Chen, Jiqian wrote:
> On 2025/6/24 16:28, Jan Beulich wrote:
>> On 24.06.2025 10:26, Chen, Jiqian wrote:
>>> On 2025/6/24 16:17, Jan Beulich wrote:
>>>> On 24.06.2025 10:12, Chen, Jiqian wrote:
>>>>> On 2025/6/20 14:34, Jan Beulich wrote:
>>>>>> On 19.06.2025 08:14, Chen, Jiqian wrote:
>>>>>>> On 2025/6/18 22:33, Jan Beulich wrote:
>>>>>>>> On 12.06.2025 11:29, Jiqian Chen wrote:
>>>>>>>>> +} vpci_capability_t;
>>>>>>>>
>>>>>>>> As you have it here, ...
>>>>>>>>
>>>>>>>>> @@ -29,9 +30,22 @@ typedef int vpci_register_init_t(struct pci_dev *dev);
>>>>>>>>>   */
>>>>>>>>>  #define VPCI_MAX_VIRT_DEV       (PCI_SLOT(~0) + 1)
>>>>>>>>>  
>>>>>>>>> -#define REGISTER_VPCI_INIT(x, p)                \
>>>>>>>>> -  static vpci_register_init_t *const x##_entry  \
>>>>>>>>> -               __used_section(".data.vpci." p) = (x)
>>>>>>>>> +#define REGISTER_VPCI_CAPABILITY(cap, finit, fclean, ext) \
>>>>>>>>> +    static const vpci_capability_t finit##_t = { \
>>>>>>>>
>>>>>>>> ... _t suffixes generally designate types. I don't think we should abuse
>>>>>>>> that suffix for an identifier of a variable.
>>>>>>> What do you think I should change to?
>>>>>>
>>>>>> Well, if you take my other advice, this question won't need answering, as
>>>>>> then you only need the ..._entry one.
>>>>>>
>>>>>> Btw, noticing only now - why is it finit that's used to derive the identifier?
>>>>>> With that, it could as well be fclean (leaving aside the fact that that's
>>>>>> optional). Imo the name would better be derived from cap, and it would better
>>>>>> also reflect the purpose of the variable.
>>>>> I considered this.
>>>>> I think it is easier to use finit, and finit contains the cap type, and the main purpose of this struct is to initialize the cap.
>>>>
>>>> Yet identifier names should make sense for the object they name.
>>> OK. What's your suggestion about naming the entry?
>>
>> cap##_init or _##cap##_init for example.
> If so, I need to extend the parameter of REGISTER_VPCI_CAPABILITY since current cap is number, not string.
> Maybe:
> REGISTER_VPCI_CAPABILITY (cap, cap_id, finit, fclean, ext)

Well, yes, in the helper macro you may need to take precautions. However, I was
wondering anyway why

REGISTER_VPCI_CAP(PCI_CAP_ID_MSI, init_msi, NULL);

would be necessary, when

REGISTER_VPCI_CAP(MSI, init_msi, NULL);

could do, using e.g.

#define REGISTER_VPCI_CAP(cap, finit, fclean) \
    REGISTER_VPCI_CAPABILITY(PCI_CAP_ID_##cap, finit, fclean, false)
#define REGISTER_VPCI_EXTCAP(cap, finit, fclean) \
    REGISTER_VPCI_CAPABILITY(PCI_EXT_CAP_ID_##cap, finit, fclean, true)

(other variations are possible, of course). Then you could easily derive the
identifier wanted (requiring another parameter to REGISTER_VPCI_CAPABILITY(),
yes).

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 08:47:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 08:47:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023425.1399414 (Exim 4.92)
	(envelope-from )
	id 1uTzJU-00016x-1I; Tue, 24 Jun 2025 08:47:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023425.1399414; Tue, 24 Jun 2025 08: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 1uTzJT-00016q-Uf; Tue, 24 Jun 2025 08:47:31 +0000
Received: by outflank-mailman (input) for mailman id 1023425;
 Tue, 24 Jun 2025 08: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 1uTzJS-00016k-DP
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 08:47:30 +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 d9e17690-50d7-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 10:47:25 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-4530921461aso1392685e9.0
 for ; Tue, 24 Jun 2025 01:47:25 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d83936e1sm104979875ad.5.2025.06.24.01.47.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 01:47:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d9e17690-50d7-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750754845; x=1751359645; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=wvi133P+98o1WSxQXhxYZo9lX8ql32xnPy5zZe/nLlU=;
        b=KN7L1OGukGrf7lZL/yWwWkEjTMdZBkxFTCPpRjn+tJWbWmzstsTO7HH/PK86SRgtAC
         oJoOHBsTAU3KfQ2zZvo2rWi0pa12IIDMyo0ZGOFcHzonf4P3zwiA65Tsr3dUhMic+fB8
         +O2ujenYbL2E15UK/WHZuJ4LIiOkA8ZNLwrIVlykI0aZSSKnnKJJYDD9V0yArJcmgpB2
         UoKp7p6fQIfp23Qhp+QcYoAd1k/zFKl7srrQ9BuCLYOCy4q+6sxFeprhcZzXSwVtkqYN
         P0PClEyxR59ojRO/vzEMRsfXUpSnPGc8kkhGfzQ79bx9v5llVi1+C57MXXYhY0BnOZXJ
         IjFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750754845; x=1751359645;
        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=wvi133P+98o1WSxQXhxYZo9lX8ql32xnPy5zZe/nLlU=;
        b=BABAy2fJO0LxdNgvguVfKPfI3wQ6EnLYwck+cac5vvT7RusgqS3vTCmLpS7txDg5Op
         tXXAjWCFzW3Jpa57KXxtzAbQGhviim/DVqzIusr4p5pWx8YU/5I9P1XxltPwg6qHCRHt
         evEBPIVJZhQQc/cES5JLYmMD+AAjHJ6AtGVwPdMrTafSvECEx0+VW9haKHJzLuAYMUv7
         i8oMecov8mUI6ck4vkMJvjjte3AQTM54a05/3R8qLWupZiyiDPhQ5j2AhRhy+EIqOuu7
         dy1fsiJm+G0Ucf9C5LeFYmRw11+aJMximtuJKZUPRUY2EQRsIWEGUxAKV9Af3B+lAwx5
         bmfg==
X-Gm-Message-State: AOJu0YzdhHxqz5JCBq4TvJMHlQpojLVnxNOU/1pV5Zgl/1SMqGQRZtuR
	Ny7x1fLRjy1Ohwv7aZfwY4CSKItbM31qRrXjwXOKqL+Fk9XElBF0C19sC1EmcADPGfL7/JWWr/b
	f/t4=
X-Gm-Gg: ASbGncs4nXsZr0qlAYa+sgMNDXgAnffH+9sVxyMQeULWs7aosbsYdrmDCkysM+ZVjs0
	dM90ryFvYlp+4cmQmLEUPXxUoJ7ihQ31uqy+onbyL+bHhUUBafG47/thncYVTtfiKthjbmnDtx5
	yN/MKqUdjaBeZHL1dDliXJaLrFkKDc1KxCkPzAIYG/5lGj3CQOamBflvvvHxjOkCdj1l+1ariE0
	LNnv5mVihS+MWHhQj1sOHFZBtmoHQKMNu4KvQkyzKr+Bt4P0KUBfAXXOqaEUEjvkYnqqSCAkBe2
	Gn9cmS1XYt5e+feG0pEfoXxv0f9Fg1/3rLHMKrgRrUEXxWdJXX//JbL/zzaJNmLDgutLJ99h0Zf
	DFKe2w7K0UWcWUDziWrJbvLcKC2o+F3PEHQtsJrEdGv+vyE8=
X-Google-Smtp-Source: AGHT+IHO3QGaSJenn+WN49EqBW90i51B+aH+PfXu3w/34ZKiC9OyXrzXE/c4pA/6HjCLd2FKcRXusw==
X-Received: by 2002:a05:6000:2108:b0:3a5:3af1:e21b with SMTP id ffacd0b85a97d-3a6d12e6d88mr9393404f8f.47.1750754844577;
        Tue, 24 Jun 2025 01:47:24 -0700 (PDT)
Message-ID: <033988d2-5b4f-4182-b26e-f860e740cb4a@suse.com>
Date: Tue, 24 Jun 2025 10:47:13 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v4 5/8] xen/domctl: extend XEN_DOMCTL_assign_device to
 handle not only iommu
To: Oleksii Moisieiev 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper ,
 Anthony PERARD ,
 Bertrand Marquis , Juergen Gross
 , Julien Grall ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Grygorii Strashko ,
 Stefano Stabellini ,
 "roger.pau@citrix.com" 
References: 
 <4f58bf9c47c40413ee9250c4cd21458382aac857.1747669845.git.oleksii_moisieiev@epam.com>
 
 
 
 <1780646c-cb6f-4508-86c8-a573fbc09f6a@epam.com>
 
 <4b69568b-3b21-4426-b78a-222ca11632e4@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: <4b69568b-3b21-4426-b78a-222ca11632e4@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 24.06.2025 10:42, Oleksii Moisieiev wrote:
> Adding Roger and Jan to the conversation.
> 
> Please see below.

Why is this? I did answer that question at the bottom already.

Jan

> On 23/06/2025 00:30, Stefano Stabellini wrote:
>> On Thu, 19 Jun 2025, Oleksii Moisieiev wrote:
>>> On 18/06/2025 03:04, Stefano Stabellini wrote:
>>>> On Thu, 12 Jun 2025, Oleksii Moisieiev wrote:
>>>>> Hi Stefano,
>>>>>
>>>>> I'm very sorry for a long silence. Please see my answers below:
>>>>>
>>>>> On 22/05/2025 03:25, Stefano Stabellini wrote:
>>>>>> On Mon, 19 May 2025, Oleksii Moisieiev wrote:
>>>>>>> From: Grygorii Strashko
>>>>>>>
>>>>>>> Add chained handling of assigned DT devices to support access-controller
>>>>>>> functionality through SCI framework, so DT device assign request can be
>>>>>>> passed to FW for processing and enabling VM access to requested device
>>>>>>> (for example, device power management through FW interface like SCMI).
>>>>>>>
>>>>>>> The SCI access-controller DT device processing is chained after IOMMU
>>>>>>> processing and expected to be executed for any DT device regardless of its
>>>>>>> protection by IOMMU (or if IOMMU is disabled).
>>>>>>>
>>>>>>> This allows to pass not only IOMMU protected DT device through
>>>>>>> xl.cfg:"dtdev" property for processing:
>>>>>>>
>>>>>>> dtdev = [
>>>>>>>        "/soc/video@e6ef0000", <- IOMMU protected device
>>>>>>>        "/soc/i2c@e6508000", <- not IOMMU protected device
>>>>>>> ]
>>>>>>>
>>>>>>> The change is done in two parts:
>>>>>>> 1) update iommu_do_dt_domctl() to check for dt_device_is_protected() and
>>>>>>> not fail if DT device is not protected by IOMMU
>>>>>>> 2) add chained call to sci_do_domctl() in do_domctl()
>>>>>>>
>>>>>>> Signed-off-by: Grygorii Strashko
>>>>>>> Signed-off-by: Oleksii Moisieiev
>>>>>>> ---
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>     xen/arch/arm/firmware/sci.c             | 37 +++++++++++++++++++++++++
>>>>>>>     xen/arch/arm/include/asm/firmware/sci.h | 14 ++++++++++
>>>>>>>     xen/common/domctl.c                     | 19 +++++++++++++
>>>>>>>     xen/drivers/passthrough/device_tree.c   |  6 ++++
>>>>>>>     4 files changed, 76 insertions(+)
>>>>>>>
>>>>>>> diff --git a/xen/arch/arm/firmware/sci.c b/xen/arch/arm/firmware/sci.c
>>>>>>> index e1522e10e2..8efd541c4f 100644
>>>>>>> --- a/xen/arch/arm/firmware/sci.c
>>>>>>> +++ b/xen/arch/arm/firmware/sci.c
>>>>>>> @@ -126,6 +126,43 @@ int sci_assign_dt_device(struct domain *d, struct dt_device_node *dev)
>>>>>>>         return 0;
>>>>>>>     }
>>>>>>>     
>>>>>>> +int sci_do_domctl(struct xen_domctl *domctl, struct domain *d,
>>>>>>> +                  XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
>>>>>>> +{
>>>>>>> +    struct dt_device_node *dev;
>>>>>>> +    int ret = 0;
>>>>>>> +
>>>>>>> +    switch ( domctl->cmd )
>>>>>>> +    {
>>>>>>> +    case XEN_DOMCTL_assign_device:
>>>>>>> +        ret = -EOPNOTSUPP;
>>>>>> Are you sure -EOPNOTSUPP is the right error code for the 3 checks below?
>>>>> The -EOPNOTSUPP code is used because this is part of a chained call after
>>>>> iommu_do_domctl, as stated in xen/common/domctl.c:859. The
>>>>> XEN_DOMCTL_assign_device
>>>>> call is expected to handle any DT device, regardless of whether the DT
>>>>> device is
>>>>> protected by an IOMMU or if the IOMMU is disabled.
>>>>> The following cases are considered:
>>>>>
>>>>> 1. IOMMU Protected Device (Success)
>>>>>
>>>>> If the device is protected by the IOMMU and iommu_do_domctl returns 0,
>>>>> we continue
>>>>> processing the DT device by calling sci_do_domctl.
>>>>>
>>>>> 2. IOMMU Disabled (-EOPNOTSUPP from iommu_do_domctl)
>>>>>
>>>>> If iommu_do_domctl returns -EOPNOTSUPP, indicating that the IOMMU is
>>>>> disabled,
>>>>> we still proceed to call sci_do_domctl.
>>>> OK this makes sense.  I think it is OK to have a special error code to
>>>> say "the IOMMU is disabled" but I don't know if it is a good idea to try
>>>> to use -EOPNOTSUPP for that. -EOPNOTSUPP could mean a hypervisor
>>>> configuration with domctl disabled, for instance.
>>>>
>>>> It might be wiser to use a different error code. Maybe ENOENT?
>>>>
>>> I see that in the following commit:
>>>
>>> 71e617a6b8 (use is_iommu_enabled() where appropriate..., 2019-09-17)
>>>
>>> -ENOSYS return code was changed to -EOPNOTSUPP in iommu_do_domctl.
>>>
>>> It's not clear to me why this was done from the commit description.
>>>
>>> Maybe we should add commit author?
>> Roger and Jan might know



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 08:48:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 08:48:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023435.1399424 (Exim 4.92)
	(envelope-from )
	id 1uTzKV-0001fY-D3; Tue, 24 Jun 2025 08:48:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023435.1399424; Tue, 24 Jun 2025 08:48:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTzKV-0001fR-AM; Tue, 24 Jun 2025 08:48:35 +0000
Received: by outflank-mailman (input) for mailman id 1023435;
 Tue, 24 Jun 2025 08:48: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 1uTzKU-0001dI-B0
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 08:48:34 +0000
Received: from AS8PR03CU001.outbound.protection.outlook.com
 (mail-westeuropeazlp170120005.outbound.protection.outlook.com
 [2a01:111:f403:c201::5])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 024e4af6-50d8-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 10:48:33 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by GVXPR03MB8404.eurprd03.prod.outlook.com (2603:10a6:150:6::11) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.29; Tue, 24 Jun
 2025 08:48:30 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%4]) with mapi id 15.20.8857.026; Tue, 24 Jun 2025
 08:48: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: 024e4af6-50d8-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=iOzMihWDDhmCqO4GlQ+/iWoyUQSMir0MkS8br2WmODrfXpXjcY/gj51NgL42gqlDHmDWfPuYcqSbihkD3XOJmMy6kZmKvzeGLZ8NLkzYb2CS4kykEfB90wnklCNtZSR2JmvZXs3Ty8WsG2Lw7pIk+lx9LeXeFobmbcWdO+PCWxG1tDkF7E9V70+Dc0B9/9TFbOdA/P3lsQ5kHae75zpfZghKmlk2TAjXXOZICCJ6lA3s4eakZ3Ia4HmrFFZzeGtCTQuzPJJ9vre8ZiZkrAgtpxbxRsitCYrSXpqxlV4fQz1onFwr+EK488GQs2J3UqheMGdkXeWf4jojOW0RQ/uB9A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=taSQdpx+IBaxZR1DgnuNIvUAec8NTTp4wATXlmgziBw=;
 b=lsybjOaHqbyIDbzWDTGL9qCUioLUvweLv8zIuCu6sUK9bOxv0Q6XZ6PO5pojMOo1EjHnqsatWQXWkKxDWsXmPo0UwaevZ/GBDxr5Zn8BrsvpEhMAmXYw6+z2LMExmhC7RQF7bDzv2GAyJxzGS8v1kGTqUS0s+FXHVm4YqlirV54TWaCGMg5LQjWqq/o+Lrw6teU5wdQTpdjdinO2XkyTmFJSgL6dryHOXeDov/7E5gA7ZyneOch4oZJgZ/RTKt84mTEp5L9g+p8OyaVNNIsOMX6MiMx45CRfXx6zY8XYl1Dcu9CMBu2fnhTrQA4HW3m0tC3OjQgW9p+T2hthWAlSqw==
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=taSQdpx+IBaxZR1DgnuNIvUAec8NTTp4wATXlmgziBw=;
 b=UzjF4+dVqQr6LJ0scUI/8Xrbg4Mh44fCYBSDWKY59SL4PtNzi7JbocopZ0itr8GfkubFPZd6adkzh2ni+RyFTGlC/c2ewEAgR2U9pESzQVMnQwMzXGvFE3yqPMe26LgAQ2TzubXT/TgBhGvI8x6PbfhFYuxdCF4dujJHCRy3DDs6Q6tc5yU86wbfxzcoXOGz0QsygPrRndds6ihn6x3t0rPtuo2XYFDo+5THaEcuN+io0FKJVeJJged9PyglJd3JpOfJb7rY3qVKzcn24XXP3LR6Roa0yhho8/Lcb/yW0LYai7Br579IzqDNnkUHh1qo0e7CSGctqKaJB9ozajdDgg==
From: Oleksii Moisieiev 
To: Jan Beulich 
CC: "xen-devel@lists.xenproject.org" , Andrew
 Cooper , Anthony PERARD
	, Bertrand Marquis ,
	Juergen Gross , Julien Grall , Michal Orzel
	, Volodymyr Babchuk ,
	Grygorii Strashko , Stefano Stabellini
	, "roger.pau@citrix.com" 
Subject: Re: [RFC PATCH v4 5/8] xen/domctl: extend XEN_DOMCTL_assign_device to
 handle not only iommu
Thread-Topic: [RFC PATCH v4 5/8] xen/domctl: extend XEN_DOMCTL_assign_device
 to handle not only iommu
Thread-Index:
 AQHbyNXPDXt2FT3RV02cltfdm/Dd7rPdzmiAgCG+LgCACKrsAIACoXoAgAUPLACAAk4fgIAAATaAgAAAWoA=
Date: Tue, 24 Jun 2025 08:48:29 +0000
Message-ID: 
References: 
 <4f58bf9c47c40413ee9250c4cd21458382aac857.1747669845.git.oleksii_moisieiev@epam.com>
 
 
 
 <1780646c-cb6f-4508-86c8-a573fbc09f6a@epam.com>
 
 <4b69568b-3b21-4426-b78a-222ca11632e4@epam.com>
 <033988d2-5b4f-4182-b26e-f860e740cb4a@suse.com>
In-Reply-To: <033988d2-5b4f-4182-b26e-f860e740cb4a@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB8946:EE_|GVXPR03MB8404:EE_
x-ms-office365-filtering-correlation-id: 7a25519d-059e-4bdf-2544-08ddb2fbe4ac
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|366016|376014|7416014|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?VzBPNkpGRnliY1dZM1FWQ21jUUxWbllUWFIvbU9XOGxOTG9XVXM3dmI1a1Js?=
 =?utf-8?B?a2VIdkYwWldaTmFtaTZJTnV2bXo3SytrQU9tSHUvMVZoV0J0citkSnA1UzlE?=
 =?utf-8?B?TC9YQWNjUkh1S2FvNDVqQ25wZE5aR0xCODZXbjNNRFZSVFBMNVBhR3FRZDFo?=
 =?utf-8?B?SEkrbFpVci9ncHhGQlB2SmRWZ2E5RThSRzF3ZS9NNFpmcStqRzZhK0J0eFZz?=
 =?utf-8?B?ZnlTdE03djczTGFOWVFKcGRPMnI2aGRUMllEQWFNMTBkNnh1N2RaMi9CWXFF?=
 =?utf-8?B?QWxRcGJjS2krVFBqZm9QOTVHREppMzRXOGJtU0dzWVF1aWxYUnRod0RWNjJ4?=
 =?utf-8?B?cW5jcm5zWXgvYmozNU4rd0FzUlhNUHZEaDVsWVMzR0hieHVwUC9LcElFc2d6?=
 =?utf-8?B?Y0VtaUY0NGk0aXZ4WVIwaXkvL3NvT0dOU1lmUjRXclV6dUpmMVhTSjZhYjlj?=
 =?utf-8?B?K0tnQjVzcXlLdW02eGR2cGVGTS9UOGJpbUEwTW1FdVFSMGVCUlRvRXpGc0xm?=
 =?utf-8?B?VmNQM29qanJxYzJ0OU04RTYxVm5uZm5HZ3FYbFFrUVh0Q1NaM2dCM25TUFFW?=
 =?utf-8?B?cWt2RTZYRk9GcHJ0c0grbVM3d1pvcWdPNUNXVE9NenF6QVZwZyt0N3BwaHo5?=
 =?utf-8?B?ckNrQlFKMTdkamQxMzVYa0JNTVBxK01XRDBkM0tnbWpLNTN5REtoM256WHJi?=
 =?utf-8?B?Uy8yQmpzVGc0YXFDT3hEUW1YOW53TC9iUzhGMWxqNk5HU2ZYKzEvYkZVMUxH?=
 =?utf-8?B?aUw3L2tsd3M0ZTdkdUZFekpPZy9nVmwyQXJGTUFnMlJGNjI2V1ExZURLSmhU?=
 =?utf-8?B?bkpqdjJVeE1xSzhYRmNWUlVxYkpZdWswZ2hodnhMb0hwTmFNam8xdEpvNFBD?=
 =?utf-8?B?Mm04UEZGTVVRdHhJdjZBSjJ3VjNOSzBYSEFOY1pPMmJvakZjRmF1eXc2ek5j?=
 =?utf-8?B?TzY5MUFCTjR6ME5BZm5mbGNHV3V6OVh4anRZdEJjZDcxck9JN2NYenEzbi9X?=
 =?utf-8?B?OGR1VEJHbVZVSjkwS1QwcVRPUlpUd3V1bGphb0J0UzI4NGQ4RVNIQWJpeTQ1?=
 =?utf-8?B?UEQ0KzA2dkY1RVhLSXp2UmNuRkVwRGVUUGw3MW5jcWp0OHkzNzVLVjFrclhR?=
 =?utf-8?B?dE5NeDd6a3ZDaGFFL0RrL2NDVnRGaFNOaWprOGQzaWpNY3NjejE1VyticFlR?=
 =?utf-8?B?KzgrTmR4K2NrdUV1TkpkS3dOMVN3QmZhSXZyN1F0eEJpNDNiSVhvbFQxMDFa?=
 =?utf-8?B?WG1sYkQ0bXR6VW9VMkJDck5ZNjNJNlhhQzRvaWZxcW5IU3pSMmFEMnN4ZmdR?=
 =?utf-8?B?ZXNROEhZeTNPU3BWZGF1enZrbldxc01EL3kralgzNHlLL2w4K015Ui9FQmtE?=
 =?utf-8?B?Y0ppUm85RjViTDRobXg4a0F6cGVjM2tWY29QNnRzaHd0VlUxZkNlTVdHZ216?=
 =?utf-8?B?MUVmT2g3OG1ZWU1RTmpraGsrWHY1dGVYVW9pcWdHUCtSUXNxQS9ZZ25oR2VQ?=
 =?utf-8?B?MFZ1eU5maWJwcXFkei8xYWtFcWFSaVNYUU11VW5MSzZZMy9lSWVlM3pNOUNz?=
 =?utf-8?B?U3phNUFpVW1obC91WDREc2UvSTZ1Vm1ML2toUkI0MnBhUmYydUJmZEZQREtL?=
 =?utf-8?B?WVEyWmJOTCswMW93WDVYU24zTDFuWTNtU2wwK1hKMlNzeXJRT3Y1UDBiRUZE?=
 =?utf-8?B?WFZ2MXNoUUthKzcwMXVmZG1pT0w2a0daWWk2ZUZnZGxsMFBsT2ozSkJnQy9J?=
 =?utf-8?B?ZFhYYnIrUFlkQlJhUENqdHB5ZGZqeGVxakxvYXdXZUFJN2lHYUlvZjRiVWw4?=
 =?utf-8?B?eThoMXVyWHRCdnF3REtDZ3hKMXRwYkdBRVd5TEIwNmhJZ2VBL28zTUdlcFR3?=
 =?utf-8?B?QTVMcXoySWVOc3lYZFM3QUxxMmNEVmFteERKbmJYR0w0Z1ZEdlBmaDIzT0VN?=
 =?utf-8?B?eDQvalFyU0pxQUI5UXdlZnNpVkJ5dzh2OER2SVpMRXJwVXlHcWNQaHIyTDdu?=
 =?utf-8?B?cisyNDRHTHlBPT0=?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(7416014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?bHlNZCs3cmdmK0wxRUp6UlpHRjhvbDlDdG5JQ3Q0Mm51U1BKc096NDNBdW5J?=
 =?utf-8?B?bVR1OGpVVURVbVVNcStIVElYZ2I4QzgwRjJaRTdUYkMrN2pZWmN5Nm9QMG9B?=
 =?utf-8?B?UHNNMkpEbStwM2FCWnpHV0ZoVktTbG1EQjdKbXlXRXRhcE1HMlVodWZrV2pJ?=
 =?utf-8?B?c0pvVE91Zit6ZW9wZXNkTUNNY0ZLRlI5bFpWVXFrbU4vNjVCVUxmUmQwRXpQ?=
 =?utf-8?B?NUMzVUdvZkdnSk81Wm9rZythN1BXWnVBYVVoYm0xUFRQaWpjR0hndWprNVhT?=
 =?utf-8?B?V01oZFdrRVA3dW1sUDNhdEZ0Z0YxcUlKQ2F2ZlNJekFMWk9oTk1KN2x0MmM1?=
 =?utf-8?B?a1l2ckF5Rm4xSjdtVHpURjJ4MkVmbjVJc2lZbzlCTlVrZU5hTTJZQnR3RG1Y?=
 =?utf-8?B?SHdlZWhZbkQ1VEwwemRuWkhvamJKY1ZaNWVDWXM1WmJpTHNiRHg2cU5xbXdK?=
 =?utf-8?B?bkgvKzlYNExUVmsvYzFlbkxNSi83WThPUUdtMWk4d21kRkFtZHdYVnEwSmpy?=
 =?utf-8?B?UndVbHUvbHBSNy9seE9EVmJsYm9FRjFiRXJsM3RqNHNrdlF2SUl0WlQ3MU5U?=
 =?utf-8?B?RmJZektNVUZhcGs0OFMyNGl3WWttVjZVQjN4citQbVIxT3FHK2ZVaWEzS3lX?=
 =?utf-8?B?dUtyYmxoQldtNmxEbDJObWIwUWJhVkE5L244cWM5cTZvR0pBdElMTkVSQjRy?=
 =?utf-8?B?YzQvd0dtdlhvTVZJbnRPRHlKcjJ4d016UnhxZnE1eGtlUlpIZnh3SlhNbHk5?=
 =?utf-8?B?ckxZd3J3ZjJIL256bEtXR1RtcjRBN1hyY3I5QU5JWVNqRWwvcGZtNFNCcVIr?=
 =?utf-8?B?MEt1UU85eVM5THAxR2xFcEdvRzlFTFNhYmUrRDQrR00zdVh3K2NpY0lmekx6?=
 =?utf-8?B?czlka1I4WWJ4RUtLTE9JRkF0TWJkSXV3ZGpVZ2pjOFhpRW1PaTVNT0Rad2lt?=
 =?utf-8?B?TjM5cGRrdlFrMklJdFZXTjByM3BTMlRsOGxCeEJmRTVzbElveGJaaFZ5bzN0?=
 =?utf-8?B?RkVXWG5ORjlHSjAxNjlTdzJESVdDRGw2eHlYbVgzcy94NFVvc3d0UTdxU2dt?=
 =?utf-8?B?M2tJQ3Bza2lWb0VuNk04cWV6TnRZa3gyWlUyeWFycmJGUW52ejNCbzNHR1FT?=
 =?utf-8?B?c3J4TlNuODIxZzVSZmZ4ZXFndEhsVE5ZeisyUlR4MGJzaXZBYVkxTm9VQzNw?=
 =?utf-8?B?OXFqc1YzbW5nNlVDL29DdUhncUtBT2p3SHJnKzc3MENta08rT0t4VjBQMjVn?=
 =?utf-8?B?elQ5M3VBdUg4dmdqejJraU1Ua2llMEZHS0piSVhUbnVBRVNUREMxUTUzaDRG?=
 =?utf-8?B?anpHMm1yREpSSVNEZlYvTzBaSXoxbFd3VnczRTFIRFRGTHBiRzE1WlZIa1R1?=
 =?utf-8?B?dVd6VFhtbWFobkh5bHJPVUQrdlYzOUdlY0RJVm1hM3kzN1lnMm5OTkozZ2tj?=
 =?utf-8?B?bWVyaFR2elEzZjlZUUNQWHZHS1NHNE5mQmdVeUY2K05vYmQ2QktaVDc4bWMw?=
 =?utf-8?B?R0NOamthSUVIR2tvbkVVMGd1U2F3UEpQTVRXM2hCK3VybHQ2QTNBNlYzeXg1?=
 =?utf-8?B?Sm1ZYWdQaE1MZHBRMituZUZKR3g3U280Z3FIamdydlNrUFNDd1ZKd0dyOGc5?=
 =?utf-8?B?Q0Zreis2ZnNxemlWQjMwQ0Z4SmlxY0RqckVjNEt3TFhBMkc4VHZPcG53Z0My?=
 =?utf-8?B?ZjRJZGY1UHA1MWc4b2JtTklPMEtacGZidmFyYkJaUWNGZUkrTytaYzRHd243?=
 =?utf-8?B?bG9DWCtpaEJrVGw2ejIwT0lSWUhPM1lIV0Z0NzczOFJDcDJpNHR0anMzeEVa?=
 =?utf-8?B?ZlM2d1RIRjZ6K2ovQ2ZCeWZnUjV4M09uVERjWmVUUmhzR0VKRUFnS0hGRFJR?=
 =?utf-8?B?Q1NweWRWSkVKeVp1UkhFSUFvR25od1c4ZDNwUWVDZjdsYnRLVnVERTJGOGJv?=
 =?utf-8?B?cEJyLzlqelNrWXV1cndWUERjVGhKSFRyM0ZDbUtUZHlCQ0NZZ1A3T2lDZDBk?=
 =?utf-8?B?ak0yTkR6TDQ5UnE2R0k5ZnpaNGZQdTZzdHIwOEU0dFFIWXA0OTgzTzlwaGVu?=
 =?utf-8?B?eHBqVzZpWndQN1ZuZ0hkVk5vQTlyNy9Vanhnc0E1V3dOZ1ppM29xVFpLN3Vw?=
 =?utf-8?B?Mmk0ek5XUXNRUXRGUkF5Nm0zdmQvNXh4U3d6T0lEYVpsYVJGSWMwL0UrN0dD?=
 =?utf-8?B?aXc9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <268FB5296FEBE04BAC2605E7646A2F9B@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: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7a25519d-059e-4bdf-2544-08ddb2fbe4ac
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2025 08:48:29.8984
 (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: zVt4E44Rs+IY/CmAR18u5kKg9sOC6Y+Pk9vRnV10d0UGKlk2Zs+q1Q/FlORWT7pfCUFM5Omq1vcSvcVCB2CNrfh3RqBJkm8vk209BST2xl8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR03MB8404

DQpPbiAyNC8wNi8yMDI1IDExOjQ3LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMjQuMDYuMjAy
NSAxMDo0MiwgT2xla3NpaSBNb2lzaWVpZXYgd3JvdGU6DQo+PiBBZGRpbmcgUm9nZXIgYW5kIEph
biB0byB0aGUgY29udmVyc2F0aW9uLg0KPj4NCj4+IFBsZWFzZSBzZWUgYmVsb3cuDQo+IFdoeSBp
cyB0aGlzPyBJIGRpZCBhbnN3ZXIgdGhhdCBxdWVzdGlvbiBhdCB0aGUgYm90dG9tIGFscmVhZHku
DQo+DQo+IEphbg0KT2ggc29ycnksIG1pc3NlZCB0aGlzIGVtYWlsLi4NCj4+IE9uIDIzLzA2LzIw
MjUgMDA6MzAsIFN0ZWZhbm8gU3RhYmVsbGluaSB3cm90ZToNCj4+PiBPbiBUaHUsIDE5IEp1biAy
MDI1LCBPbGVrc2lpIE1vaXNpZWlldiB3cm90ZToNCj4+Pj4gT24gMTgvMDYvMjAyNSAwMzowNCwg
U3RlZmFubyBTdGFiZWxsaW5pIHdyb3RlOg0KPj4+Pj4gT24gVGh1LCAxMiBKdW4gMjAyNSwgT2xl
a3NpaSBNb2lzaWVpZXYgd3JvdGU6DQo+Pj4+Pj4gSGkgU3RlZmFubywNCj4+Pj4+Pg0KPj4+Pj4+
IEknbSB2ZXJ5IHNvcnJ5IGZvciBhIGxvbmcgc2lsZW5jZS4gUGxlYXNlIHNlZSBteSBhbnN3ZXJz
IGJlbG93Og0KPj4+Pj4+DQo+Pj4+Pj4gT24gMjIvMDUvMjAyNSAwMzoyNSwgU3RlZmFubyBTdGFi
ZWxsaW5pIHdyb3RlOg0KPj4+Pj4+PiBPbiBNb24sIDE5IE1heSAyMDI1LCBPbGVrc2lpIE1vaXNp
ZWlldiB3cm90ZToNCj4+Pj4+Pj4+IEZyb206IEdyeWdvcmlpIFN0cmFzaGtvPGdyeWdvcmlpX3N0
cmFzaGtvQGVwYW0uY29tPg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IEFkZCBjaGFpbmVkIGhhbmRsaW5n
IG9mIGFzc2lnbmVkIERUIGRldmljZXMgdG8gc3VwcG9ydCBhY2Nlc3MtY29udHJvbGxlcg0KPj4+
Pj4+Pj4gZnVuY3Rpb25hbGl0eSB0aHJvdWdoIFNDSSBmcmFtZXdvcmssIHNvIERUIGRldmljZSBh
c3NpZ24gcmVxdWVzdCBjYW4gYmUNCj4+Pj4+Pj4+IHBhc3NlZCB0byBGVyBmb3IgcHJvY2Vzc2lu
ZyBhbmQgZW5hYmxpbmcgVk0gYWNjZXNzIHRvIHJlcXVlc3RlZCBkZXZpY2UNCj4+Pj4+Pj4+IChm
b3IgZXhhbXBsZSwgZGV2aWNlIHBvd2VyIG1hbmFnZW1lbnQgdGhyb3VnaCBGVyBpbnRlcmZhY2Ug
bGlrZSBTQ01JKS4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBUaGUgU0NJIGFjY2Vzcy1jb250cm9sbGVy
IERUIGRldmljZSBwcm9jZXNzaW5nIGlzIGNoYWluZWQgYWZ0ZXIgSU9NTVUNCj4+Pj4+Pj4+IHBy
b2Nlc3NpbmcgYW5kIGV4cGVjdGVkIHRvIGJlIGV4ZWN1dGVkIGZvciBhbnkgRFQgZGV2aWNlIHJl
Z2FyZGxlc3Mgb2YgaXRzDQo+Pj4+Pj4+PiBwcm90ZWN0aW9uIGJ5IElPTU1VIChvciBpZiBJT01N
VSBpcyBkaXNhYmxlZCkuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gVGhpcyBhbGxvd3MgdG8gcGFzcyBu
b3Qgb25seSBJT01NVSBwcm90ZWN0ZWQgRFQgZGV2aWNlIHRocm91Z2gNCj4+Pj4+Pj4+IHhsLmNm
ZzoiZHRkZXYiIHByb3BlcnR5IGZvciBwcm9jZXNzaW5nOg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IGR0
ZGV2ID0gWw0KPj4+Pj4+Pj4gICAgICAgICAiL3NvYy92aWRlb0BlNmVmMDAwMCIsIDwtIElPTU1V
IHByb3RlY3RlZCBkZXZpY2UNCj4+Pj4+Pj4+ICAgICAgICAgIi9zb2MvaTJjQGU2NTA4MDAwIiwg
PC0gbm90IElPTU1VIHByb3RlY3RlZCBkZXZpY2UNCj4+Pj4+Pj4+IF0NCj4+Pj4+Pj4+DQo+Pj4+
Pj4+PiBUaGUgY2hhbmdlIGlzIGRvbmUgaW4gdHdvIHBhcnRzOg0KPj4+Pj4+Pj4gMSkgdXBkYXRl
IGlvbW11X2RvX2R0X2RvbWN0bCgpIHRvIGNoZWNrIGZvciBkdF9kZXZpY2VfaXNfcHJvdGVjdGVk
KCkgYW5kDQo+Pj4+Pj4+PiBub3QgZmFpbCBpZiBEVCBkZXZpY2UgaXMgbm90IHByb3RlY3RlZCBi
eSBJT01NVQ0KPj4+Pj4+Pj4gMikgYWRkIGNoYWluZWQgY2FsbCB0byBzY2lfZG9fZG9tY3RsKCkg
aW4gZG9fZG9tY3RsKCkNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBTaWduZWQtb2ZmLWJ5OiBHcnlnb3Jp
aSBTdHJhc2hrbzxncnlnb3JpaV9zdHJhc2hrb0BlcGFtLmNvbT4NCj4+Pj4+Pj4+IFNpZ25lZC1v
ZmYtYnk6IE9sZWtzaWkgTW9pc2llaWV2PG9sZWtzaWlfbW9pc2llaWV2QGVwYW0uY29tPg0KPj4+
Pj4+Pj4gLS0tDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAgICAgIHhl
bi9hcmNoL2FybS9maXJtd2FyZS9zY2kuYyAgICAgICAgICAgICB8IDM3ICsrKysrKysrKysrKysr
KysrKysrKysrKysNCj4+Pj4+Pj4+ICAgICAgeGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2Zpcm13
YXJlL3NjaS5oIHwgMTQgKysrKysrKysrKw0KPj4+Pj4+Pj4gICAgICB4ZW4vY29tbW9uL2RvbWN0
bC5jICAgICAgICAgICAgICAgICAgICAgfCAxOSArKysrKysrKysrKysrDQo+Pj4+Pj4+PiAgICAg
IHhlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2RldmljZV90cmVlLmMgICB8ICA2ICsrKysNCj4+Pj4+
Pj4+ICAgICAgNCBmaWxlcyBjaGFuZ2VkLCA3NiBpbnNlcnRpb25zKCspDQo+Pj4+Pj4+Pg0KPj4+
Pj4+Pj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY2kuYyBiL3hlbi9hcmNo
L2FybS9maXJtd2FyZS9zY2kuYw0KPj4+Pj4+Pj4gaW5kZXggZTE1MjJlMTBlMi4uOGVmZDU0MWM0
ZiAxMDA2NDQNCj4+Pj4+Pj4+IC0tLSBhL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY2kuYw0KPj4+
Pj4+Pj4gKysrIGIveGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjaS5jDQo+Pj4+Pj4+PiBAQCAtMTI2
LDYgKzEyNiw0MyBAQCBpbnQgc2NpX2Fzc2lnbl9kdF9kZXZpY2Uoc3RydWN0IGRvbWFpbiAqZCwg
c3RydWN0IGR0X2RldmljZV9ub2RlICpkZXYpDQo+Pj4+Pj4+PiAgICAgICAgICByZXR1cm4gMDsN
Cj4+Pj4+Pj4+ICAgICAgfQ0KPj4+Pj4+Pj4gICAgICANCj4+Pj4+Pj4+ICtpbnQgc2NpX2RvX2Rv
bWN0bChzdHJ1Y3QgeGVuX2RvbWN0bCAqZG9tY3RsLCBzdHJ1Y3QgZG9tYWluICpkLA0KPj4+Pj4+
Pj4gKyAgICAgICAgICAgICAgICAgIFhFTl9HVUVTVF9IQU5ETEVfUEFSQU0oeGVuX2RvbWN0bF90
KSB1X2RvbWN0bCkNCj4+Pj4+Pj4+ICt7DQo+Pj4+Pj4+PiArICAgIHN0cnVjdCBkdF9kZXZpY2Vf
bm9kZSAqZGV2Ow0KPj4+Pj4+Pj4gKyAgICBpbnQgcmV0ID0gMDsNCj4+Pj4+Pj4+ICsNCj4+Pj4+
Pj4+ICsgICAgc3dpdGNoICggZG9tY3RsLT5jbWQgKQ0KPj4+Pj4+Pj4gKyAgICB7DQo+Pj4+Pj4+
PiArICAgIGNhc2UgWEVOX0RPTUNUTF9hc3NpZ25fZGV2aWNlOg0KPj4+Pj4+Pj4gKyAgICAgICAg
cmV0ID0gLUVPUE5PVFNVUFA7DQo+Pj4+Pj4+IEFyZSB5b3Ugc3VyZSAtRU9QTk9UU1VQUCBpcyB0
aGUgcmlnaHQgZXJyb3IgY29kZSBmb3IgdGhlIDMgY2hlY2tzIGJlbG93Pw0KPj4+Pj4+IFRoZSAt
RU9QTk9UU1VQUCBjb2RlIGlzIHVzZWQgYmVjYXVzZSB0aGlzIGlzIHBhcnQgb2YgYSBjaGFpbmVk
IGNhbGwgYWZ0ZXINCj4+Pj4+PiBpb21tdV9kb19kb21jdGwsIGFzIHN0YXRlZCBpbiB4ZW4vY29t
bW9uL2RvbWN0bC5jOjg1OS4gVGhlDQo+Pj4+Pj4gWEVOX0RPTUNUTF9hc3NpZ25fZGV2aWNlDQo+
Pj4+Pj4gY2FsbCBpcyBleHBlY3RlZCB0byBoYW5kbGUgYW55IERUIGRldmljZSwgcmVnYXJkbGVz
cyBvZiB3aGV0aGVyIHRoZSBEVA0KPj4+Pj4+IGRldmljZSBpcw0KPj4+Pj4+IHByb3RlY3RlZCBi
eSBhbiBJT01NVSBvciBpZiB0aGUgSU9NTVUgaXMgZGlzYWJsZWQuDQo+Pj4+Pj4gVGhlIGZvbGxv
d2luZyBjYXNlcyBhcmUgY29uc2lkZXJlZDoNCj4+Pj4+Pg0KPj4+Pj4+IDEuIElPTU1VIFByb3Rl
Y3RlZCBEZXZpY2UgKFN1Y2Nlc3MpDQo+Pj4+Pj4NCj4+Pj4+PiBJZiB0aGUgZGV2aWNlIGlzIHBy
b3RlY3RlZCBieSB0aGUgSU9NTVUgYW5kIGlvbW11X2RvX2RvbWN0bCByZXR1cm5zIDAsDQo+Pj4+
Pj4gd2UgY29udGludWUNCj4+Pj4+PiBwcm9jZXNzaW5nIHRoZSBEVCBkZXZpY2UgYnkgY2FsbGlu
ZyBzY2lfZG9fZG9tY3RsLg0KPj4+Pj4+DQo+Pj4+Pj4gMi4gSU9NTVUgRGlzYWJsZWQgKC1FT1BO
T1RTVVBQIGZyb20gaW9tbXVfZG9fZG9tY3RsKQ0KPj4+Pj4+DQo+Pj4+Pj4gSWYgaW9tbXVfZG9f
ZG9tY3RsIHJldHVybnMgLUVPUE5PVFNVUFAsIGluZGljYXRpbmcgdGhhdCB0aGUgSU9NTVUgaXMN
Cj4+Pj4+PiBkaXNhYmxlZCwNCj4+Pj4+PiB3ZSBzdGlsbCBwcm9jZWVkIHRvIGNhbGwgc2NpX2Rv
X2RvbWN0bC4NCj4+Pj4+IE9LIHRoaXMgbWFrZXMgc2Vuc2UuICBJIHRoaW5rIGl0IGlzIE9LIHRv
IGhhdmUgYSBzcGVjaWFsIGVycm9yIGNvZGUgdG8NCj4+Pj4+IHNheSAidGhlIElPTU1VIGlzIGRp
c2FibGVkIiBidXQgSSBkb24ndCBrbm93IGlmIGl0IGlzIGEgZ29vZCBpZGVhIHRvIHRyeQ0KPj4+
Pj4gdG8gdXNlIC1FT1BOT1RTVVBQIGZvciB0aGF0LiAtRU9QTk9UU1VQUCBjb3VsZCBtZWFuIGEg
aHlwZXJ2aXNvcg0KPj4+Pj4gY29uZmlndXJhdGlvbiB3aXRoIGRvbWN0bCBkaXNhYmxlZCwgZm9y
IGluc3RhbmNlLg0KPj4+Pj4NCj4+Pj4+IEl0IG1pZ2h0IGJlIHdpc2VyIHRvIHVzZSBhIGRpZmZl
cmVudCBlcnJvciBjb2RlLiBNYXliZSBFTk9FTlQ/DQo+Pj4+Pg0KPj4+PiBJIHNlZSB0aGF0IGlu
IHRoZSBmb2xsb3dpbmcgY29tbWl0Og0KPj4+Pg0KPj4+PiA3MWU2MTdhNmI4ICh1c2UgaXNfaW9t
bXVfZW5hYmxlZCgpIHdoZXJlIGFwcHJvcHJpYXRlLi4uLCAyMDE5LTA5LTE3KQ0KPj4+Pg0KPj4+
PiAtRU5PU1lTIHJldHVybiBjb2RlIHdhcyBjaGFuZ2VkIHRvIC1FT1BOT1RTVVBQIGluIGlvbW11
X2RvX2RvbWN0bC4NCj4+Pj4NCj4+Pj4gSXQncyBub3QgY2xlYXIgdG8gbWUgd2h5IHRoaXMgd2Fz
IGRvbmUgZnJvbSB0aGUgY29tbWl0IGRlc2NyaXB0aW9uLg0KPj4+Pg0KPj4+PiBNYXliZSB3ZSBz
aG91bGQgYWRkIGNvbW1pdCBhdXRob3I/DQo+Pj4gUm9nZXIgYW5kIEphbiBtaWdodCBrbm93


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 08:52:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 08:52:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023443.1399434 (Exim 4.92)
	(envelope-from )
	id 1uTzO9-0003BQ-SI; Tue, 24 Jun 2025 08:52:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023443.1399434; Tue, 24 Jun 2025 08:52:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uTzO9-0003BJ-Oi; Tue, 24 Jun 2025 08:52:21 +0000
Received: by outflank-mailman (input) for mailman id 1023443;
 Tue, 24 Jun 2025 08:52: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 1uTzO8-0003BD-AF
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 08:52:20 +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 87ab8023-50d8-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 10:52:18 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by PH7PR12MB7185.namprd12.prod.outlook.com (2603:10b6:510:201::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.25; Tue, 24 Jun
 2025 08:52: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%4]) with mapi id 15.20.8835.027; Tue, 24 Jun 2025
 08:52: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: 87ab8023-50d8-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=nauSEY333JvqL4pO1Kg6Ee5k6dyLIEOKjTWHOczITyDeWDXM6dMA+sxchmEvCCLB2JQTJG7PeT5xx3Gmv5oc8bspiIcpMz+uLUJggK52e9T4xNMBqFnXfA7Z2z64IuXvkTXOMqDqF6xvJFN/hmoFqGuhCSHK7nsmMnbeiHWjqgSUlB5ahWFqGpJnn68d1bn7d40BenLjdqC3p7wcoveBiPApu8rCryOboc2vCO5V7kynaeP2K8zlGMz6c9lQr/y7QMxCUMZgWVVGt4kTflDIcKLGcJCQ/n8d+HPInJGg315XfQ+TlVchnih1RzSgOvh7GQGHg7bS1Cg7gE+9lDHd6w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=anh8iK1q/gVgSyi4qKPGIGy6eJIAgvOPHumV1o/VByg=;
 b=qeg+Ixswo+Yi5SELplG96rWQosCfjlbRpZOhi1OPqLsRbX05pwjORrwFoixmLpola5iq/JTWqK5Nv8SjkzXFLO11Js7XJIEOIQ/wsyCJ9+RpbYPrVbj8SlpeS57muM6sx5icI8sCBqOsKnAYQJqUnBdpUdsEWy6ufOmgWpggnTtF4ju51nC/ynMh4qwl7+Ao1AOHz4CHrIhkRZ5UfS3C5+ZQSl19XWXQksk+cFkmuLGetjDNFhqUZZplFW2OZkOep6z01XLVASBIOFszqozEoJCbcMKMl9xzCmVAMndw5nXdLchnxFGPeAsZfc1cAfjSYdIx4xeyXICj6cl/M5e6Cg==
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=anh8iK1q/gVgSyi4qKPGIGy6eJIAgvOPHumV1o/VByg=;
 b=25MSVGbdgns5Yc57myUO+1BX7TUa9vdr/nc014BYVMLjuf5/w8TSvVT+X2LuH8MV3skNHPu6BHjexmnqb5r5lKdo4SQui42aV5td5EB4uKmwbMNpiG40XH7Cwesb0h/YFMrj2ITL5e2+bO6LAKxJZdCAwY3cEs01biT/O66pPmw=
From: "Chen, Jiqian" 
To: Jan Beulich 
CC: "Huang, Ray" , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Andrew Cooper , Anthony
 PERARD , "Orzel, Michal" ,
	Julien Grall , Stefano Stabellini ,
	"xen-devel@lists.xenproject.org" , "Chen,
 Jiqian" 
Subject: Re: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
Thread-Topic: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
Thread-Index:
 AQHb23yakGdVC9XxvEWnYcnp8zrTt7QJBRKAgAGLVICAARN8gIAG6YaA//98XQCAAIcUAP//fCSAgACGWwD//342AAAQ9MYA
Date: Tue, 24 Jun 2025 08:52:12 +0000
Message-ID:
 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-3-Jiqian.Chen@amd.com>
 <1634c18d-e54e-4105-8b30-6f3085bace22@suse.com>
 
 <23293ec5-7466-400c-87a4-1482577b91fa@suse.com>
 
 <0cf4679d-ee86-4666-adae-63a3f9b9b8f7@suse.com>
 
 <3eaaa6c8-d696-4eca-913e-6e6fd9e618d3@suse.com>
 
 <1ea09a95-5f13-4af4-bad1-e7081bf065fc@suse.com>
In-Reply-To: <1ea09a95-5f13-4af4-bad1-e7081bf065fc@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.8835.025)
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_|PH7PR12MB7185:EE_
x-ms-office365-filtering-correlation-id: 2de5b82f-8d6e-4e26-148c-08ddb2fc6998
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?K3BrN2lHTTJ4SkR2L01uTkdhQkZMN0tBMVNLeGV0b2R2L29Pdmt1VDZKbGNK?=
 =?utf-8?B?MERBSm1xQm8yNFpqUlBPTVpTNEZ3UVFzWlF5aDNJemRZQUxPTWw5cWpqeXZk?=
 =?utf-8?B?TzRxQjU2TXd6WTNvUVZmK0FuZDVPaXpnVk4wb1lQbU91SERlUnlvTDkvY3pF?=
 =?utf-8?B?N3hUOG1wN1o3WUlYdmE5NEZLSWJWTE9mSTNhd1EwRVdFaGRUZTNVc2N5OUR5?=
 =?utf-8?B?TUxVTXFqaFhzVnd3ZFJpTDF3UHRMMDlMYVp6V21uNlhiK0Q0eWIwZ2h4MG1x?=
 =?utf-8?B?OGNFQkVwSXlicnZxc3hzUWhuekFtbGFPa1NvWWlab0h4UDkxblVFV05WcFJR?=
 =?utf-8?B?OVJEWXZoREJPNmVaeFFlUHE4K2FYS1kwdFAzMU5sM1Rjb2xPSXFSWFc1a0ZX?=
 =?utf-8?B?VHptSGx4VVFNejhvTml3Um9qVlFTcWxyN1BpVmZwaERieXY1TTZIYVhIbDVl?=
 =?utf-8?B?MVBob3BkajM1QUNrQmNaTmhvNVlSSkxHclNHNU0zSEcrMXc4MER2VHVUWXVi?=
 =?utf-8?B?UTlWTDgrVUkzOThFaDFLVDVRd3QzNTM4R1F3TVZZRmJkT1B6WFNMZjI1TDlx?=
 =?utf-8?B?TDljT2Y5T3ZHZG5oTGZGUWFFMTVHSDU3V1haRjN0M3NrNGtmZkF4dDh0cTdp?=
 =?utf-8?B?YVV6V21IbFpGQmhjYnA2OGRXTXpSOWtaTVR0aGRhenUvQlNLRVRvNmg5cVZY?=
 =?utf-8?B?ZW1pbTBRbUErREV1QmxiYUZjWDNhaXdoVkJNdHVjaUw2NnhYZ3cvZlNQZzhV?=
 =?utf-8?B?V1lsUWhvNVBFdXFqZEFDUUdXV1RMTkRCaVN1OFVIZHQ4cUtFNmJhWitXNS9R?=
 =?utf-8?B?UXBlZlVMcjM2V1ZLOVp5b1Z4OVY3T0pCRFl1eWc0L2w0MEpzeWZQTzlUOTVw?=
 =?utf-8?B?dVNHZlRXc05GMXBrZ01HbzIvMVA0VnB1LzBPK1g0d2F0NzVxOUJCZVZ4aFk5?=
 =?utf-8?B?UkhoUDlFMGdkdk1Lajg4R2o5OUtUQnNDOXV3Tm9nd3l1NUlzcWNFaHVZMm50?=
 =?utf-8?B?cmYvay90S3NjYi9XNU9sK2FCZ2lZamZQeHl1Nmdhc1Y0eHNnUjhOem1iWDdH?=
 =?utf-8?B?dS9ERGZjdkFIRkxsb3h6SmxVVnRJeWRpWDBOK29DMkhxS2d3L0F0V283eEhH?=
 =?utf-8?B?STlwZzZTdDVXaUhEU2JMeGFUaHNwZTRVUFlKbCtIcXBtSjlxRHJuNHJRbGFJ?=
 =?utf-8?B?dVlUNzAwUzNSZkllODQ0RHdWS0pENGNZaDNzak9wY0s4MXVTNnlSZ09ianBk?=
 =?utf-8?B?YVl2V2pQdDNqaHFQVHRXUktzcHAzV0xjY2pjSExYNWxZQTc4cE5LSDlCSkFZ?=
 =?utf-8?B?ZzlsSjB3bE5DYUs5UXNBUHd4cklPQ1NnaDVPM2h1azF2VWgya0pMbXVFNjNT?=
 =?utf-8?B?Vmo0QWh0b3BDTHBUR0hERE9XSTFkZ3dRWWhmUHR4c1VOazdJS2xlWm1GYjRL?=
 =?utf-8?B?L0dSNTFxdWpKcUVFVThzUXBlb3lKbGVPMlZlYkhhOHJBMCtPRVpJYWQ2ZjUy?=
 =?utf-8?B?MUN5dlRaSGFoWEtJSjhjMFBiS3RUWUdpUUdkSTY3NnFJR1RDSVNsN1hKRkdm?=
 =?utf-8?B?ZUxGaWJsUGc2YmpiMjhrM2FzZXpIYytrdDJnVzNPK1p2bVYwQWFtYVpHaC9F?=
 =?utf-8?B?d0o3UTVCY2dWMllPbHF1ZE5YZU9RVmFFa2wvQ2VxSkVBcHlJTGpXM3hTTTFG?=
 =?utf-8?B?KzlYaU45QW04V1JFbkFLaWFram1YSVdjVC9mS2E0WFFBQ1htRE9qQWVmU1Z6?=
 =?utf-8?B?QWhRRWZQZHhsZGROMHZsUW16aXVyRzl1VzNQeG9zeWJlcEJaeENCdURzSVd5?=
 =?utf-8?B?Q3ZpMlBrd0V5ZHA5SkJTbEJVTjgxdWROdlp2L1ViaE1KSjVtcWxvNWY2V051?=
 =?utf-8?B?blI0bmFoOUVQT3prd2FsRXlOdUVuZEo1N0VRdG1rYXBLUDdPWnBRL3dLZnEx?=
 =?utf-8?B?OTA4QzhuaG52SkZWQWw3eHlkeldGcWY5SmpaTkFHbUVVLzlQWjVEcDFGTUM1?=
 =?utf-8?Q?YR8GZVZ6nEYhs+wRdgIjzwirVc4sYk=3D?=
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?MXZHaW1KbS9rNUdZNzB3WW9adVpGdzZnckZlQ1FwbUhtbVMycys1ZXFSOEJ3?=
 =?utf-8?B?YVdMZ2lyY1VFWVN1NmgwT2FEZExBdzNjWlRRVDY4NzNtRndrNnBIajcwbEw5?=
 =?utf-8?B?VU5GWUJoS3p4MEtQWk83dEMxMVBzU04zNnJ6b3FoMXQzMTRlT3NaMFJ5S1Bx?=
 =?utf-8?B?RFJuZzlyWWlCMC9aTmxmdlZPem9hUnRjN0svbk8zQWhHSHdjUERacUYrRmUx?=
 =?utf-8?B?ZWR3TzBDL2NFRFpJejhrMWgwajhTUlFLTURwM1U2T05NVFFHdTFEWHJEOFVD?=
 =?utf-8?B?RHNwQ2VTSFJ3TVFwM3lPdDlKcjJzU2Y5YjdJTHBUOFdlZktkTWRadmw1Tmo0?=
 =?utf-8?B?aldBNjlZdlBrSzhDRzRDbTMrelNndW9zZEZ2UUtpbVJJWEV2YmwyMWpsd0lX?=
 =?utf-8?B?eHdteWQxR0ZhMzNwb3pGWURUcTlNWGJBR2V4VktsMEJtV0lVdlc1RENPb2pG?=
 =?utf-8?B?cXRPaGNTaHNIYXova2tUcFJHT3J3WGMvT2hrc043RmNNQTR6MCtQWHRobTl3?=
 =?utf-8?B?aXcweFNqN2V5U3lBTmVmUDR3M01waDhjSmxyTDZsRld5ZndRc3AyMElrUHBz?=
 =?utf-8?B?U3lwNllxNUVDeGhVQUtYMCs0Rk5sWU4rWmJsaWx5SHJWS1NlN2w5dnF6YWxu?=
 =?utf-8?B?dENRNnN3a3EyWmloSUlPVzA3ODRlV25lTDd6aGpKcGhvNXpvUGZuU3ZzVzYr?=
 =?utf-8?B?ZGFFdTR2alQyMDc0MCtXMjNZczFDOFdFNEhRMk1HR1djVndsdkl1RWkxc2c2?=
 =?utf-8?B?djkxcDc1ZGlZdEdHV3lGMTUzZUxWcVF4bW5NWVU5V0ZNVEY5NnJsdEd5VzJD?=
 =?utf-8?B?OU5UL2FVMEM1TFZoQ0JmWXJuZllYR3M3SWx2TFBsYmxBek43Y2xveE9DMzhQ?=
 =?utf-8?B?WHQ4VkZ4MnNaSzhsYXVXWnU5NVNNMXQ3dVByYmZYazcyQWNWVFBJZlJsU1V0?=
 =?utf-8?B?NmRNZGNhZytqV3RVeDQ0M1Q5d09zQzFKeTRyZmE1SmdiRXZzN1pvdnowbVpX?=
 =?utf-8?B?ZmZYc2hQS09hT2RnQUlrQzMxOWprbXUxbEhsdEVMSW5WOVRwTVhXc0dkMWFC?=
 =?utf-8?B?aldiM2JpNzdFZ1FycytQanhhdWUzUVFaRXJqSUQ5RndudHJGSU83TXZsMFhz?=
 =?utf-8?B?VEdBS1VSeHQ5SmQwTndDTDJJbVVwMzcvOWt2ZGJxKzhBU2tBREQ3YzJkalJZ?=
 =?utf-8?B?NUhWT2xMZXdac3o5UlVTWGdHeTBVT3oxb2draUUyMm81TlJockVGbWNDbElx?=
 =?utf-8?B?cDJnNm1CNURHbG1tQ3VkTDRnS0VGRld3M0kvYW9PMitHRmdUSm01ZGZSR3lC?=
 =?utf-8?B?bXI0Yk1mYSs1ZW5BT0dtUUxCb2RxL3EwanBoQjhiaGtuRDlENExSMHd5R2RR?=
 =?utf-8?B?KzJsWU9GSnFBWXBqUjhPL0UzWlptL1VIaTVUbFJkeS9pV1ZlRjVHQjA1R0hK?=
 =?utf-8?B?TG9VNEZvbS9xejhyK3NZK2NrL1hZbVFYRVIvWEZTaDRxOWtHNWk5UFdTMzl1?=
 =?utf-8?B?ZGVucGs1b2FpdGV4ZnBsYTJXR3VqOWxZcGxtdktBOGcxeERPS0pIQ3lKOGM1?=
 =?utf-8?B?Y1lzeFVQQk9EOUt0Nk5PTWlVczBjUjVLZllxY3VIZlI2b3FwZlFVcHdmbzhC?=
 =?utf-8?B?akkwN2YyRUN2S3FxL1dDcUIzbmFVRlJ3eFFrNGZGRkJXaUdMNTc3cmlDRUtL?=
 =?utf-8?B?eWVBbGpZc0Z2aTdTaUgrZllkMDdVQXVsb1M1ZkFkaTdzN2NjZEQwRDhZSHI5?=
 =?utf-8?B?QklaMlJneWNLVE1sOGgwaUsrL28zZDd4OXdrTysvQkErZmVaRjhzT3VLcHc5?=
 =?utf-8?B?Rk9rUlFJeE1hK1B1UklPZEhXdUNSRGZqY2ExdmxlM1lXZUZwWDFRcGdGbTBa?=
 =?utf-8?B?em9hZmhmcXM5djZtc242NG05SHRXVkxrR3VsUCt5eTdpd1VOTzNPVm81YjFv?=
 =?utf-8?B?R1cyeHh1cWt5TWRFRDdCSjc2RXYrMjcvbkk4eGhKdHZUUXhjSHI4c1I4WTUy?=
 =?utf-8?B?Q2xuT0dqb0E0YTNxWVFrUlJrSk1XenJjT29zUllISlBXQ1VWMnBhRWhhM0p4?=
 =?utf-8?B?OXhrb0dFQWFkNWdsa3pBUm1LVS9NR2NnUWxrbW5wdXl0N0MrNE5jSlBDTmtY?=
 =?utf-8?Q?50vU=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <70E18A3668564248981FC452DD64BBFA@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: 2de5b82f-8d6e-4e26-148c-08ddb2fc6998
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2025 08:52:12.9450
 (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: yH+0Md7OccAwhanT6XLSHvVQ9z4rsCdm424JtacA6YtRZF3X+aPdVF5u24jrpN0b8/AtiLYSOAjZfrSx/9ZSLQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB7185

T24gMjAyNS82LzI0IDE2OjQ0LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMjQuMDYuMjAyNSAx
MDozMiwgQ2hlbiwgSmlxaWFuIHdyb3RlOg0KPj4gT24gMjAyNS82LzI0IDE2OjI4LCBKYW4gQmV1
bGljaCB3cm90ZToNCj4+PiBPbiAyNC4wNi4yMDI1IDEwOjI2LCBDaGVuLCBKaXFpYW4gd3JvdGU6
DQo+Pj4+IE9uIDIwMjUvNi8yNCAxNjoxNywgSmFuIEJldWxpY2ggd3JvdGU6DQo+Pj4+PiBPbiAy
NC4wNi4yMDI1IDEwOjEyLCBDaGVuLCBKaXFpYW4gd3JvdGU6DQo+Pj4+Pj4gT24gMjAyNS82LzIw
IDE0OjM0LCBKYW4gQmV1bGljaCB3cm90ZToNCj4+Pj4+Pj4gT24gMTkuMDYuMjAyNSAwODoxNCwg
Q2hlbiwgSmlxaWFuIHdyb3RlOg0KPj4+Pj4+Pj4gT24gMjAyNS82LzE4IDIyOjMzLCBKYW4gQmV1
bGljaCB3cm90ZToNCj4+Pj4+Pj4+PiBPbiAxMi4wNi4yMDI1IDExOjI5LCBKaXFpYW4gQ2hlbiB3
cm90ZToNCj4+Pj4+Pj4+Pj4gK30gdnBjaV9jYXBhYmlsaXR5X3Q7DQo+Pj4+Pj4+Pj4NCj4+Pj4+
Pj4+PiBBcyB5b3UgaGF2ZSBpdCBoZXJlLCAuLi4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBAQCAt
MjksOSArMzAsMjIgQEAgdHlwZWRlZiBpbnQgdnBjaV9yZWdpc3Rlcl9pbml0X3Qoc3RydWN0IHBj
aV9kZXYgKmRldik7DQo+Pj4+Pj4+Pj4+ICAgKi8NCj4+Pj4+Pj4+Pj4gICNkZWZpbmUgVlBDSV9N
QVhfVklSVF9ERVYgICAgICAgKFBDSV9TTE9UKH4wKSArIDEpDQo+Pj4+Pj4+Pj4+ICANCj4+Pj4+
Pj4+Pj4gLSNkZWZpbmUgUkVHSVNURVJfVlBDSV9JTklUKHgsIHApICAgICAgICAgICAgICAgIFwN
Cj4+Pj4+Pj4+Pj4gLSAgc3RhdGljIHZwY2lfcmVnaXN0ZXJfaW5pdF90ICpjb25zdCB4IyNfZW50
cnkgIFwNCj4+Pj4+Pj4+Pj4gLSAgICAgICAgICAgICAgIF9fdXNlZF9zZWN0aW9uKCIuZGF0YS52
cGNpLiIgcCkgPSAoeCkNCj4+Pj4+Pj4+Pj4gKyNkZWZpbmUgUkVHSVNURVJfVlBDSV9DQVBBQklM
SVRZKGNhcCwgZmluaXQsIGZjbGVhbiwgZXh0KSBcDQo+Pj4+Pj4+Pj4+ICsgICAgc3RhdGljIGNv
bnN0IHZwY2lfY2FwYWJpbGl0eV90IGZpbml0IyNfdCA9IHsgXA0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+
Pj4gLi4uIF90IHN1ZmZpeGVzIGdlbmVyYWxseSBkZXNpZ25hdGUgdHlwZXMuIEkgZG9uJ3QgdGhp
bmsgd2Ugc2hvdWxkIGFidXNlDQo+Pj4+Pj4+Pj4gdGhhdCBzdWZmaXggZm9yIGFuIGlkZW50aWZp
ZXIgb2YgYSB2YXJpYWJsZS4NCj4+Pj4+Pj4+IFdoYXQgZG8geW91IHRoaW5rIEkgc2hvdWxkIGNo
YW5nZSB0bz8NCj4+Pj4+Pj4NCj4+Pj4+Pj4gV2VsbCwgaWYgeW91IHRha2UgbXkgb3RoZXIgYWR2
aWNlLCB0aGlzIHF1ZXN0aW9uIHdvbid0IG5lZWQgYW5zd2VyaW5nLCBhcw0KPj4+Pj4+PiB0aGVu
IHlvdSBvbmx5IG5lZWQgdGhlIC4uLl9lbnRyeSBvbmUuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEJ0dywg
bm90aWNpbmcgb25seSBub3cgLSB3aHkgaXMgaXQgZmluaXQgdGhhdCdzIHVzZWQgdG8gZGVyaXZl
IHRoZSBpZGVudGlmaWVyPw0KPj4+Pj4+PiBXaXRoIHRoYXQsIGl0IGNvdWxkIGFzIHdlbGwgYmUg
ZmNsZWFuIChsZWF2aW5nIGFzaWRlIHRoZSBmYWN0IHRoYXQgdGhhdCdzDQo+Pj4+Pj4+IG9wdGlv
bmFsKS4gSW1vIHRoZSBuYW1lIHdvdWxkIGJldHRlciBiZSBkZXJpdmVkIGZyb20gY2FwLCBhbmQg
aXQgd291bGQgYmV0dGVyDQo+Pj4+Pj4+IGFsc28gcmVmbGVjdCB0aGUgcHVycG9zZSBvZiB0aGUg
dmFyaWFibGUuDQo+Pj4+Pj4gSSBjb25zaWRlcmVkIHRoaXMuDQo+Pj4+Pj4gSSB0aGluayBpdCBp
cyBlYXNpZXIgdG8gdXNlIGZpbml0LCBhbmQgZmluaXQgY29udGFpbnMgdGhlIGNhcCB0eXBlLCBh
bmQgdGhlIG1haW4gcHVycG9zZSBvZiB0aGlzIHN0cnVjdCBpcyB0byBpbml0aWFsaXplIHRoZSBj
YXAuDQo+Pj4+Pg0KPj4+Pj4gWWV0IGlkZW50aWZpZXIgbmFtZXMgc2hvdWxkIG1ha2Ugc2Vuc2Ug
Zm9yIHRoZSBvYmplY3QgdGhleSBuYW1lLg0KPj4+PiBPSy4gV2hhdCdzIHlvdXIgc3VnZ2VzdGlv
biBhYm91dCBuYW1pbmcgdGhlIGVudHJ5Pw0KPj4+DQo+Pj4gY2FwIyNfaW5pdCBvciBfIyNjYXAj
I19pbml0IGZvciBleGFtcGxlLg0KPj4gSWYgc28sIEkgbmVlZCB0byBleHRlbmQgdGhlIHBhcmFt
ZXRlciBvZiBSRUdJU1RFUl9WUENJX0NBUEFCSUxJVFkgc2luY2UgY3VycmVudCBjYXAgaXMgbnVt
YmVyLCBub3Qgc3RyaW5nLg0KPj4gTWF5YmU6DQo+PiBSRUdJU1RFUl9WUENJX0NBUEFCSUxJVFkg
KGNhcCwgY2FwX2lkLCBmaW5pdCwgZmNsZWFuLCBleHQpDQo+IA0KPiBXZWxsLCB5ZXMsIGluIHRo
ZSBoZWxwZXIgbWFjcm8geW91IG1heSBuZWVkIHRvIHRha2UgcHJlY2F1dGlvbnMuIEhvd2V2ZXIs
IEkgd2FzDQo+IHdvbmRlcmluZyBhbnl3YXkgd2h5DQo+IA0KPiBSRUdJU1RFUl9WUENJX0NBUChQ
Q0lfQ0FQX0lEX01TSSwgaW5pdF9tc2ksIE5VTEwpOw0KPiANCj4gd291bGQgYmUgbmVjZXNzYXJ5
LCB3aGVuDQo+IA0KPiBSRUdJU1RFUl9WUENJX0NBUChNU0ksIGluaXRfbXNpLCBOVUxMKTsNCj4g
DQo+IGNvdWxkIGRvLCB1c2luZyBlLmcuDQo+IA0KPiAjZGVmaW5lIFJFR0lTVEVSX1ZQQ0lfQ0FQ
KGNhcCwgZmluaXQsIGZjbGVhbikgXA0KPiAgICAgUkVHSVNURVJfVlBDSV9DQVBBQklMSVRZKFBD
SV9DQVBfSURfIyNjYXAsIGZpbml0LCBmY2xlYW4sIGZhbHNlKQ0KPiAjZGVmaW5lIFJFR0lTVEVS
X1ZQQ0lfRVhUQ0FQKGNhcCwgZmluaXQsIGZjbGVhbikgXA0KPiAgICAgUkVHSVNURVJfVlBDSV9D
QVBBQklMSVRZKFBDSV9FWFRfQ0FQX0lEXyMjY2FwLCBmaW5pdCwgZmNsZWFuLCB0cnVlKQ0KPiAN
Cj4gKG90aGVyIHZhcmlhdGlvbnMgYXJlIHBvc3NpYmxlLCBvZiBjb3Vyc2UpLiBUaGVuIHlvdSBj
b3VsZCBlYXNpbHkgZGVyaXZlIHRoZQ0KPiBpZGVudGlmaWVyIHdhbnRlZCAocmVxdWlyaW5nIGFu
b3RoZXIgcGFyYW1ldGVyIHRvIFJFR0lTVEVSX1ZQQ0lfQ0FQQUJJTElUWSgpLA0KPiB5ZXMpLg0K
U2VlbXMgYmV0dGVyLg0KVGhhbmsgeW91IHZlcnkgbXVjaCENCg0KPiANCj4gSmFuDQoNCi0tIA0K
QmVzdCByZWdhcmRzLA0KSmlxaWFuIENoZW4uDQo=


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 09:30:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 09:30:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023470.1399444 (Exim 4.92)
	(envelope-from )
	id 1uTzyh-0002UM-Mc; Tue, 24 Jun 2025 09:30:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023470.1399444; Tue, 24 Jun 2025 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 1uTzyh-0002UF-Jl; Tue, 24 Jun 2025 09:30:07 +0000
Received: by outflank-mailman (input) for mailman id 1023470;
 Tue, 24 Jun 2025 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 1uTzyg-0002Od-FC
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 09:30:06 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on2062a.outbound.protection.outlook.com
 [2a01:111:f403:2408::62a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ccd589f4-50dd-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 11:30:01 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by PH0PR12MB8151.namprd12.prod.outlook.com (2603:10b6:510:299::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.30; Tue, 24 Jun
 2025 09:29:55 +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.8835.027; Tue, 24 Jun 2025
 09:29: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: ccd589f4-50dd-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=reeW1U3OgHgPw+ZVaRvalU2JNm7tf7N/b6d7jQys6Jac4iOXnzyfxL21MwE3JQ2YPptWlWXIhdwyQrVPsXEjgKrrieTz0nyt9NhKLVjWQywGT3xaaM4tO1EHb6Mm6hvoZThHeaR/Z2mft4UWMqITCwFfcYH3ONNutFmx1u8mAbkIOVl+WP47OFXrdg53THHutI56vbHr0jlDZnvtXFrOzuXx1evN1IVcMaZfzdXczcib4xZfgDfrZqtV6qyKJMxMQg1I/6ANGF2AliJOYcGpAB4O9zBkFcePxy/sfcSSofkPj/vs5G0YwG15nJrVWKoZXhnEBcFUnMaugqaA+HPlPA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=6OSqX8TPdt+TwcOTXS9Rjh7LbVBuChZINYEOQvnZ0ag=;
 b=seaRE2srG21BAI3gFKKRoBSzapTBDO7vgqkK4j5UINxSlgbd8reDWfHN41GuopOOY5JF/wdAaF5oJX/+YBpUA8amZri9tC5D7zzG7kaeghcTXLitcd28HsJa3eF69+xcAkW/dpwTcg5vAaAf6RtkTlnbBWrdo4i5zO7WQVE/oy34wDwT2xXwc0su3Z3NTkLjJWWe4tITVktNCiAUkiOrsfMJiLX/HYZ/BliIpEE1pascvlLft9Qj1n967whS5wj+Busjm8ED2usb7c9RUe+paWAnDr3Vx9QY0NCS9OE2WnXhpFhR5PEmaVp6g8ZQX+3W5+z2dgRIg8ASmW7SGiYYQA==
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=6OSqX8TPdt+TwcOTXS9Rjh7LbVBuChZINYEOQvnZ0ag=;
 b=vKq0RBBWIq3uro61dBNzINSU6flfWtRKv0N/e0vIwkiMIXHAC5KR61juiofMgnYUXR1Qx98BR7U9GfZR56gIp2nTYKBwyEBtON2tFsRBlQzB2jUCOneWqx8bIJ1+gCFsTNy3P4upSXMw6CYJfOV90fIhQJLydaw2W/wRI3zE9Xg=
From: "Chen, Jiqian" 
To: Jan Beulich , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	
CC: "Huang, Ray" , Andrew Cooper
	, Anthony PERARD ,
	"Orzel, Michal" , Julien Grall ,
	Stefano Stabellini , "xen-devel@lists.xenproject.org"
	, "Chen, Jiqian" 
Subject: Re: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
Thread-Topic: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
Thread-Index:
 AQHb23yakGdVC9XxvEWnYcnp8zrTt7QI/QAAgAGa9QCAAQzVgIAG5D6A//99hgCAAJwoAA==
Date: Tue, 24 Jun 2025 09:29:54 +0000
Message-ID:
 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-3-Jiqian.Chen@amd.com>
 <516a3adc-320d-46ce-b235-8ef91469abcf@suse.com>
 
 <227df6d3-a2c3-4576-bde9-d8057c378e7a@suse.com>
 
 <5c4b186e-686e-4fc8-bcf1-854bc1f5ec8b@suse.com>
In-Reply-To: <5c4b186e-686e-4fc8-bcf1-854bc1f5ec8b@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.8835.025)
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_|PH0PR12MB8151:EE_
x-ms-office365-filtering-correlation-id: a906a839-ea94-4312-2e72-08ddb301adb2
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?dVlvRDk0dENqSzMxUWdOaFZjR3RIQ2hFcTZyM1JsTldrRXR0b3A2RlNpL2Ju?=
 =?utf-8?B?MVVsbUtUS1c4dUQ1L2VPL1BhdE90dFlGUVc0ZUtlS3RSbUFCeTJxdktHakRJ?=
 =?utf-8?B?UGxVQ09qUzN1aW0xNXZyRHgvTkFhWU9saXZ5UXJYc2EwSEZLRkk4Qmh1YWJE?=
 =?utf-8?B?bWxIYXl6THRocHZDVzNKN2luM2VtRzNVUm1xNnIrcEtXQjFwZzBkdnFyYVh4?=
 =?utf-8?B?bFR0Vkx6ZlJBNkF6MzJ0d1ErUUJXYy95L0tUK3BIRXhzTnc0UGF5emlkckpt?=
 =?utf-8?B?MzVUNThGREZ3dCtLNGxDL1RtWlVvTEh2Z3FJUmd6akVBSU9qdXJpbXo2dmU0?=
 =?utf-8?B?cnNtS0U3bFE3SEJEQkp3QlV4ZitiNnJBeGFURUU2Rm5VaU9zWDJPb0lTNk5q?=
 =?utf-8?B?RTBDVW9XVHV4aThXM1YraWd1OGltQ1lXMUUrS2ZFbm9yOCtEMVo2ekkrQVd5?=
 =?utf-8?B?ZkY4VUdtcEhDWGRyWEFudGJxMzlsYk5GQXliYXBpOFRsOFhRMGc0cnVBb3ZC?=
 =?utf-8?B?QU41WWdrbmRoeW9XRGUyM3hNU0xTTGtuZm0xdGFENnJQR0ZkcHkvYmlpMW5T?=
 =?utf-8?B?SElwZlZVTTN3MDJIczFpKy9CT1NjRDhqNjBMT05UVlU0VVFlbGtHcWlPQmxR?=
 =?utf-8?B?eHZsa2VEZUJTSG5sK0VETEdrSkdNbTI1M3JsMzkzK0FpR0VZVm5OOFNjTjlE?=
 =?utf-8?B?QTM2MGgzZk1Pbm1TQXNwMUhTTEN4azMrOG9YbTVHa3FuSk9GUlhSK2k5NHR0?=
 =?utf-8?B?NnkrNHh6QkNUUWg0UGdydmRNc2o2disyaEwvUm5yZFNaQVVzbDNxMERaZndB?=
 =?utf-8?B?QnE5aXJTRGxVd2tQZTBFWnVpM0ljak4vbTB1ZGQ5TUlnc0wzc1R0cStTaHFa?=
 =?utf-8?B?TGorNlVBak82QnpLZ3BtQ3o0L096ejJ5NlRtb3ZFUlQ1QnZza3l5ZUJJWHJi?=
 =?utf-8?B?SnFxeE1hbE84eVlKRkt2T0tNNXRMN1lwWWdGRGJEUUxTNk8xNTJlS0U2REJ1?=
 =?utf-8?B?K1NJSy92UC90ZEoxaU1yTDhkWDZadjh0Nk9pNGNrMC93Q2gvY01WRUFFQjRn?=
 =?utf-8?B?d012dHN6ejBoNUlyOXI2NnhaQU1uamwxR1BTWklBRDRZQnhacWt5QnRhUzd0?=
 =?utf-8?B?bTNjMGo0ekxNdFdXRk9PZGJHTnZXRWVmNHFjR2g1SkNiUDJBOTJKR1dtRUxU?=
 =?utf-8?B?cjVXZFM0aDJTZ2Z5V0xaWEhmOUtMS2l6NU9kYlZFcWdyRUd0d2JTV0FiQjFK?=
 =?utf-8?B?Z0R1NWNoUU5QTk12WnBtV21iWU56elRiWlRmNk50djROZGFzZUZObkFCV3Fn?=
 =?utf-8?B?TUhtOE9UTVE4bXhRWjNWaExzZTl2RjViUzFYTmFlQy9YeVJJN2VRdUZTUi9j?=
 =?utf-8?B?VUNtWUZQM3YvTHFUK0xkQkpUd1ZkUTlIbVFDYy9JS3ZiN3B2Qmw1b0s3UEFD?=
 =?utf-8?B?V1dEZ0VoTHc3aGdCVEoxalZaR0hOQVNUeGI1VTFBZG9ZUDVLanoxNGJoRUU5?=
 =?utf-8?B?RVVRWXArKzlLNHFiL0JObTRvUERnSUlKdGMwaGNoeEdhbW8ybmlScTJ1em5C?=
 =?utf-8?B?bVVta3lYRCtlQlV3SW8xSjlHTXcwcS9NY0llR2RMY25lS3Eyd25qbTRJQVVs?=
 =?utf-8?B?QWRRQUlwV0prbkFWWmpQckp6ZHNiSHhCb1NQUzRjVVRHY2FDTG53RklCYnVk?=
 =?utf-8?B?L2dONWhRalF3Nzh5cXFQZkcwMlJzNlgwREV1NVY5NDRyd0VUUEpTL1A3d2xr?=
 =?utf-8?B?NCthL1RLMzhRSnI2djdaUkV2TitwOWdNWlBYU25NcENrV1JabFhEZytHcHNM?=
 =?utf-8?B?dkkvMnlnVmFWN2ZJeU5KNkthRjVOTUpEN1R2VkpYSm9KYXBtVWhwUGFheDNv?=
 =?utf-8?B?bXMvalFqay91cE05SVU5bmlYelB6aEdTZG00SjZmMFE3Y1JDMVE2THplbXdw?=
 =?utf-8?B?MWl1RlVzZ2ZhV3RYKzExQ3hwVWV2dkYwek4zNE9sRXg3TEoxRlpEMi81Z2Rp?=
 =?utf-8?Q?MDs+sxCISLZsuy9p8wOnIHX8hBj6u4=3D?=
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?SldROXlzTTEvYzVMY3AwQkt2WDU4L2NtRFJ2d2poaXByazFRb2pRTEFrVjBR?=
 =?utf-8?B?SUZrZHhoTG5YdHRwQ25rTDlEVFFMZURwbHZVZk85S0tuQTJPcGYyU2tSVnlo?=
 =?utf-8?B?TmIzTW5EWUdIRENEbVNkZXVRWlVOSjRtd2d2bEhMbmxyUUdJMVhtcFRRcnd0?=
 =?utf-8?B?anZaRU5xa3J0TllGNmFNZnMrWUc4bS9yKzNva0I1bnoyZTRhUno2NHlwSTV0?=
 =?utf-8?B?WmtLVUo4YlEvN1NzN25oSDZIdi9pcWpVUEUvOEJmdlk5RlZHeG5GbG12dndC?=
 =?utf-8?B?ZVNBM3dFUjkzNlRHcmdaak1KWEpuVUNoVS9YR1JXVmM4VmJ5bFkwUStMdXNl?=
 =?utf-8?B?UUZMaTAwb2JMeWE1Q2dldDhBMGhuby9YbVhFeWN2MGcwL0RiWUkzRkhENWFV?=
 =?utf-8?B?TU0rWlRscFVWSkprL0N3MlFORzlSbjJnRWM2K3BZaXloMkF6VTYzWUF5M2Fi?=
 =?utf-8?B?eWtGZHRMZlhKeDltM0RITE5nbjJrOVZXSFZvYjRaM3Ruc2JvdVV0L2FmV0hp?=
 =?utf-8?B?Ui9jVEhWNnFzTlNlRUx2K2NlaEhOaEtOWTBpR1pvVDlDemlYVExSVmdOblBr?=
 =?utf-8?B?NzVqRWMvN1h4c0gzY0s4VU9XanR5NVpMclVIY1dFL3h1aExKOVM2dlpiaVBZ?=
 =?utf-8?B?TWd1bUFqK20rbzIwdHZwdlpISUJUM0hrdlFUUERDSy9pNTBEMWwySGl0MXhE?=
 =?utf-8?B?VjIydHdEMUlmbGlpTnRudm54RWFQcHBSUGpEcnZlTk9CcXdFZ0lvWm8ycWFE?=
 =?utf-8?B?a3htaXZwbzBtVVl6TzcrRjdxT3VRa1J3Tzl0ekFxVVl2OWhKc2pud3lvZFRF?=
 =?utf-8?B?MWczb0xIb2hBa3ZORmxLSjNobTAzZFZmekFhWTJMYVlvWGRkeVNsVFdCN0xG?=
 =?utf-8?B?SVRFMHBDbUYyWGtuaDJEM21GdXNxYkpYYTJESys2NXk0M08wNlFaVGttcmJQ?=
 =?utf-8?B?LzVCcFg5N21hNDVaZHh4TkYrYjgzWWlaQnA0eVd6MlhtV2prUDZUbTNFSXBT?=
 =?utf-8?B?ZEttSnBXVGVRbVhVcHNiTmcxYzBJQkpWWTkzZk1vMkIxMmdKcmYxSmtueFVL?=
 =?utf-8?B?Vm9PSU8vNnRKaXpMbjlZTmdTM3QvNzFpaXdIampHcU5ZdWZQQ01YQjQ1djBk?=
 =?utf-8?B?K0JvZi9INmRudUhTTkpjT3Yxdk51Z05wa0RZZjUyd042bG8vaHlEaVhub3Vn?=
 =?utf-8?B?VUI0Q1FZRnBhMTdrcXRjZ2RTUzlYTVNoSEYwelNrWmUvbVQrdUN3cU5UT29D?=
 =?utf-8?B?UFdNOE53b24raG9VbDdmaWJ1Sk1uOU5tZUcyL2FxOE9jVzlSNy93d3lPYWdw?=
 =?utf-8?B?c3RRVFRwTElZMjFGLzRPK0Y4MzdFR0Y5Vmdmb3A5aEIrb3hnZE5tL055WFBx?=
 =?utf-8?B?NlFseUg0WldXNndvTHhEeDFPcm5IU0hBRm96Qy9QckttYzFUZ3NtQVhveE9O?=
 =?utf-8?B?bE1rZkNGQ0NnbHpSZGRwVlF3dGw1R1lOekNDYUZaNGtXcUNGNDFwajIvTVIz?=
 =?utf-8?B?Nk5CQXNSQ2JkMU1aZE02Q2hqWW9NcGF0VG14RlZvdE5rSDVXUCt4MUc4VlRJ?=
 =?utf-8?B?TEVWTDB1ZisxbllZWXljRDg0ay9hbVVDakJvMzVYREE5b3hVaVkzTWZZVkFE?=
 =?utf-8?B?Ry9KUUtnc2pnTkg1TE1MYktsSHg3VmtjMnBtRm43Z2M2eXlxL1VER0ZGZGZp?=
 =?utf-8?B?cWdvbmtVSjJjZEhHbVh3cE9NMm5VOW4rUC9UZHBOTVNUZXBZamlMSG9LUllI?=
 =?utf-8?B?WFh2TUxMSUtyS3RpV3hvRmdLUTVPVk91alI1MjJyMDBUa2M3S1ozWmc0OURo?=
 =?utf-8?B?MXMrYzRDaCsxWTlGZW1pQWNYbVpXcjVibjhQYW9uWGhYVWVzVjA0L0JHOUpW?=
 =?utf-8?B?bTFnKzFKei9abTdpcG9DTVR0V3kyZTJDeUYyalZua0pjNnhqQlRxZkRqYkJS?=
 =?utf-8?B?aDY5TFc0MUEvVXhGaVE4d0wyQ3RxNHk4aW9jcm1sRnl2ODhjdUxibzdiSTd0?=
 =?utf-8?B?VkpzVTdRTUI4WHZTcmNHanVBdVNEN3cxK2N1UVZEaWVEQVNqZHVwTjcweS9Q?=
 =?utf-8?B?OTZwejVaNWZqU0l3NUQ2ZlJpUk52RjdGQkZhVmFIVEJMWmpFM09NYyt0TTI4?=
 =?utf-8?Q?HMX8=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <61E853331BECFF4FB42AB6E5030E5219@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: a906a839-ea94-4312-2e72-08ddb301adb2
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2025 09:29:54.6880
 (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: WbjKV0LF9FM9fDTGB49oodpatObz+WycY5gbSYeNEyCSvaIAkI0BVLV959P4uwvbUyySnxwJqfBn3bnxHj60DQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB8151

T24gMjAyNS82LzI0IDE2OjA1LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMjQuMDYuMjAyNSAx
MDowMiwgQ2hlbiwgSmlxaWFuIHdyb3RlOg0KPj4gT24gMjAyNS82LzIwIDE0OjM4LCBKYW4gQmV1
bGljaCB3cm90ZToNCj4+PiBPbiAxOS4wNi4yMDI1IDA4OjM5LCBDaGVuLCBKaXFpYW4gd3JvdGU6
DQo+Pj4+IE9uIDIwMjUvNi8xOCAyMjowNSwgSmFuIEJldWxpY2ggd3JvdGU6DQo+Pj4+PiBPbiAx
Mi4wNi4yMDI1IDExOjI5LCBKaXFpYW4gQ2hlbiB3cm90ZToNCj4+Pj4+PiAtLS0gYS94ZW4vZHJp
dmVycy92cGNpL21zaXguYw0KPj4+Pj4+ICsrKyBiL3hlbi9kcml2ZXJzL3ZwY2kvbXNpeC5jDQo+
Pj4+Pj4gQEAgLTcwMyw5ICs3MDMsMTMgQEAgc3RhdGljIGludCBjZl9jaGVjayBpbml0X21zaXgo
c3RydWN0IHBjaV9kZXYgKnBkZXYpDQo+Pj4+Pj4gICAgICBwZGV2LT52cGNpLT5tc2l4ID0gbXNp
eDsNCj4+Pj4+PiAgICAgIGxpc3RfYWRkKCZtc2l4LT5uZXh0LCAmZC0+YXJjaC5odm0ubXNpeF90
YWJsZXMpOw0KPj4+Pj4+ICANCj4+Pj4+PiAtICAgIHJldHVybiAwOw0KPj4+Pj4+ICsgICAgc3Bp
bl9sb2NrKCZwZGV2LT52cGNpLT5sb2NrKTsNCj4+Pj4+PiArICAgIHJjID0gdnBjaV9tYWtlX21z
aXhfaG9sZShwZGV2KTsNCj4+Pj4+PiArICAgIHNwaW5fdW5sb2NrKCZwZGV2LT52cGNpLT5sb2Nr
KTsNCj4+Pj4+DQo+Pj4+PiBJZiB5b3UgYWRkIGEgY2FsbCB0byB2cGNpX21ha2VfbXNpeF9ob2xl
KCkgaGVyZSwgZG9lc24ndCBpdCBuZWVkIChvciBhdA0KPj4+Pj4gbGVhc3Qgd2FudCkgcmVtb3Zp
bmcgc29tZXdoZXJlIGVsc2U/IE90aGVyd2lzZSBtYXliZSBhIGNvZGUgY29tbWVudCBpcw0KPj4+
Pj4gd2FycmFudGVkIG5leHQgdG8gdGhlIG5ldyBjYWxsIHNpdGU/DQo+PiBTb3JyeSwgSSBtaXN1
bmRlcnN0b29kIHlvdSBpbiBteSBsYXN0IGVtYWlsLg0KPj4gQWZ0ZXIgaGVyZSdzIGNoYW5nZSwg
aXQgc2VlbXMgdGhlIGNhbGwgaW4gbW9kaWZ5X2RlY29kaW5nKCkgaXMgcmVkdW5kYW50Lg0KPj4g
V2hhdCdzIHlvdXIgdGFzdGU/IFJlbW92aW5nIHRoZSBjYWxsIGluIG1vZGlmeV9kZWNvZGluZygp
IG9yIGFkZGluZyBhIGNvZGUgY29tbWVudD8NCj4gDQo+IEknZCBwcmVmZXIgdGhlIG90aGVyIGNh
bGwgdG8gYmUgZHJvcHBlZCBpZiBpdCdzIHByb3ZhYmx5IHJlZHVuZGFudC4gQnV0IFJvZ2VyDQo+
IGhhcyB0aGUgZmluYWwgc2F5IGhlcmUgYW55d2F5Lg0KT0ssIGxldCdzIHdhaXQgUm9nZXIncyBp
bnB1dC4NCg0KPiANCj4+Pj4gVGhlIHJlbW92aW5nIG9wZXJhdGlvbiBpbiBtb2RpZnlfYmFycygp
IGFuZCB2cGNpX2RlYXNzaWduX2RldmljZSgpIGlzIG5vdCBlbm91Z2g/DQo+Pj4NCj4+PiBJIGZl
YXIgSSBkb24ndCB1bmRlcnN0YW5kIHRoaXMgcmVwbHkgb2YgeW91cnMuIFdoaWNoIHN1Z2dlc3Rz
IHRoYXQgdGhlIHBhdGNoDQo+Pj4gZGVzY3JpcHRpb24gbWF5IHdhbnQgZXh0ZW5kaW5nIGFzIHRv
IHRoaXMgcGFydCBvZiB0aGUgY2hhbmdlLg0KPj4+DQo+Pj4+Pj4gQEAgLTI5LDkgKzMwLDIyIEBA
IHR5cGVkZWYgaW50IHZwY2lfcmVnaXN0ZXJfaW5pdF90KHN0cnVjdCBwY2lfZGV2ICpkZXYpOw0K
Pj4+Pj4+ICAgKi8NCj4+Pj4+PiAgI2RlZmluZSBWUENJX01BWF9WSVJUX0RFViAgICAgICAoUENJ
X1NMT1QofjApICsgMSkNCj4+Pj4+PiAgDQo+Pj4+Pj4gLSNkZWZpbmUgUkVHSVNURVJfVlBDSV9J
TklUKHgsIHApICAgICAgICAgICAgICAgIFwNCj4+Pj4+PiAtICBzdGF0aWMgdnBjaV9yZWdpc3Rl
cl9pbml0X3QgKmNvbnN0IHgjI19lbnRyeSAgXA0KPj4+Pj4+IC0gICAgICAgICAgICAgICBfX3Vz
ZWRfc2VjdGlvbigiLmRhdGEudnBjaS4iIHApID0gKHgpDQo+Pj4+Pj4gKyNkZWZpbmUgUkVHSVNU
RVJfVlBDSV9DQVBBQklMSVRZKGNhcCwgZmluaXQsIGZjbGVhbiwgZXh0KSBcDQo+Pj4+Pj4gKyAg
ICBzdGF0aWMgY29uc3QgdnBjaV9jYXBhYmlsaXR5X3QgZmluaXQjI190ID0geyBcDQo+Pj4+Pj4g
KyAgICAgICAgLmlkID0gKGNhcCksIFwNCj4+Pj4+PiArICAgICAgICAuaW5pdCA9IChmaW5pdCks
IFwNCj4+Pj4+PiArICAgICAgICAuY2xlYW51cCA9IChmY2xlYW4pLCBcDQo+Pj4+Pj4gKyAgICAg
ICAgLmlzX2V4dCA9IChleHQpLCBcDQo+Pj4+Pj4gKyAgICB9OyBcDQo+Pj4+Pj4gKyAgICBzdGF0
aWMgY29uc3QgdnBjaV9jYXBhYmlsaXR5X3QgKmNvbnN0IGZpbml0IyNfZW50cnkgIFwNCj4+Pj4+
PiArICAgICAgICBfX3VzZWRfc2VjdGlvbigiLmRhdGEucmVsLnJvLnZwY2kiKSA9ICZmaW5pdCMj
X3QNCj4+Pj4+DQo+Pj4+PiBDb3VsZCB5b3UgcmVtaW5kIG1lIHdoeSB0aGUgZXh0cmEgbGV2ZWwg
b2YgaW5kaXJlY3Rpb24gaXMgbmVjZXNzYXJ5IGhlcmU/DQo+Pj4+PiBUaGF0IGlzLCB3aHkgY2Fu
J3QgLmRhdGEucmVsLnJvLnZwY2kgYmUgYW4gYXJyYXkgb2YgdnBjaV9jYXBhYmlsaXR5X3Q/DQo+
Pj4+IFlvdSBtZWFuIEkgc2hvdWxkIGNoYW5nZSB0byBiZToNCj4+Pj4gI2RlZmluZSBSRUdJU1RF
Ul9WUENJX0NBUEFCSUxJVFkoY2FwLCBmaW5pdCwgZmNsZWFuLCBleHQpIFwNCj4+Pj4gICAgIHN0
YXRpYyBjb25zdCB2cGNpX2NhcGFiaWxpdHlfdCBmaW5pdCMjX3QgXA0KPj4+PiAgICAgICAgIF9f
dXNlZF9zZWN0aW9uKCIuZGF0YS5yZWwucm8udnBjaSIpID0geyBcDQo+Pj4+ICAgICAgICAgLmlk
ID0gKGNhcCksIFwNCj4+Pj4gICAgICAgICAuaW5pdCA9IChmaW5pdCksIFwNCj4+Pj4gICAgICAg
ICAuY2xlYW51cCA9IChmY2xlYW4pLCBcDQo+Pj4+ICAgICAgICAgLmlzX2V4dCA9IChleHQpLCBc
DQo+Pj4+ICAgICB9DQo+Pj4+DQo+Pj4+IFJpZ2h0Pw0KPj4+DQo+Pj4gWWVzLCBzdWJqZWN0IHRv
IHRoZSBlYXJsaWVyIGNvbW1lbnRzIG9uIHRoZSBpZGVudGlmaWVyIGNob2ljZS4NCj4+IEdvdCBp
dC4NCj4+IE9uZSBtb3JlIHF1ZXN0aW9uLCBpZiBjaGFuZ2UgdG8gYmUgdGhhdCwgdGhlbiBob3cg
c2hvdWxkIEkgbW9kaWZ5IHRoZSBkZWZpbml0aW9uIG9mIFZQQ0lfQVJSQVk/DQo+PiBJcyBQT0lO
VEVSX0FMSUdOIHN0aWxsIHJpZ2h0Pw0KPiANCj4gWWVzLiBUaGUgc3RydWN0IGRvZXNuJ3QgcmVx
dWlyZSBiaWdnZXIgYWxpZ25tZW50IGFmYWljcy4gKEluIGZhY3QgaW4gcHJpbmNpcGxlDQo+IG5v
IGFsaWdubWVudCBzaG91bGQgbmVlZCBzcGVjaWZ5aW5nIHRoZXJlLCBleGNlcHQgdGhhdCB0aGlz
IHdvdWxkIHJlcXVpcmUNCj4ga2VlcGluZyB0aGUgc2VjdGlvbiBzZXBhcmF0ZSBpbiB0aGUgZmlu
YWwgaW1hZ2UuIFdoaWNoIEkgZG9uJ3QgdGhpbmsgd2Ugd2FudC4pDQo+IA0KPj4gU2luY2UgSSBl
bmNvdW50ZXJlZCBlcnJvcnMgdGhhdCB0aGUgdmFsdWVzIG9mIF9fc3RhcnRfdnBjaV9hcnJheSBh
cmUgbm90IHJpZ2h0IHdoZW4gSSB1c2UgdGhlbSBpbiB2cGNpX2luaXRfY2FwYWJpbGl0aWVzKCku
DQo+IA0KPiBEZXRhaWxzIHBsZWFzZS4NCkFmdGVyIGNoYW5naW5nIF9fc3RhcnRfdnBjaV9hcnJh
eSB0byBiZSB2cGNpX2NhcGFiaWxpdHlfdCBhcnJheSwgY29kZXMgd2lsbCBiZSAobWF5YmUgSSBt
b2RpZmllZCB3cm9uZyBzb21ld2hlcmUpOg0KDQpkaWZmIC0tZ2l0IGEveGVuL2RyaXZlcnMvdnBj
aS92cGNpLmMgYi94ZW4vZHJpdmVycy92cGNpL3ZwY2kuYw0KaW5kZXggYzUxYmJiOGFiYjE5Li45
ZjJmNDM4YjRmZGQgMTAwNjQ0DQotLS0gYS94ZW4vZHJpdmVycy92cGNpL3ZwY2kuYw0KKysrIGIv
eGVuL2RyaXZlcnMvdnBjaS92cGNpLmMNCkBAIC0zNiw4ICszNiw4IEBAIHN0cnVjdCB2cGNpX3Jl
Z2lzdGVyIHsNCiB9Ow0KDQogI2lmZGVmIF9fWEVOX18NCi1leHRlcm4gY29uc3QgdnBjaV9jYXBh
YmlsaXR5X3QgKmNvbnN0IF9fc3RhcnRfdnBjaV9hcnJheVtdOw0KLWV4dGVybiBjb25zdCB2cGNp
X2NhcGFiaWxpdHlfdCAqY29uc3QgX19lbmRfdnBjaV9hcnJheVtdOw0KK2V4dGVybiB2cGNpX2Nh
cGFiaWxpdHlfdCBfX3N0YXJ0X3ZwY2lfYXJyYXlbXTsNCitleHRlcm4gdnBjaV9jYXBhYmlsaXR5
X3QgX19lbmRfdnBjaV9hcnJheVtdOw0KICNkZWZpbmUgTlVNX1ZQQ0lfSU5JVCAoX19lbmRfdnBj
aV9hcnJheSAtIF9fc3RhcnRfdnBjaV9hcnJheSkNCg0KICNpZmRlZiBDT05GSUdfSEFTX1ZQQ0lf
R1VFU1RfU1VQUE9SVA0KQEAgLTI1NSw3ICsyNTUsNyBAQCBzdGF0aWMgaW50IHZwY2lfaW5pdF9j
YXBhYmlsaXRpZXMoc3RydWN0IHBjaV9kZXYgKnBkZXYpDQogew0KICAgICBmb3IgKCB1bnNpZ25l
ZCBpbnQgaSA9IDA7IGkgPCBOVU1fVlBDSV9JTklUOyBpKysgKQ0KICAgICB7DQotICAgICAgICBj
b25zdCB2cGNpX2NhcGFiaWxpdHlfdCAqY2FwYWJpbGl0eSA9IF9fc3RhcnRfdnBjaV9hcnJheVtp
XTsNCisgICAgICAgIGNvbnN0IHZwY2lfY2FwYWJpbGl0eV90ICpjYXBhYmlsaXR5ID0gJl9fc3Rh
cnRfdnBjaV9hcnJheVtpXTsNCiAgICAgICAgIGNvbnN0IHVuc2lnbmVkIGludCBjYXAgPSBjYXBh
YmlsaXR5LT5pZDsNCiAgICAgICAgIGNvbnN0IGJvb2wgaXNfZXh0ID0gY2FwYWJpbGl0eS0+aXNf
ZXh0Ow0KICAgICAgICAgaW50IHJjOw0KZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3hlbi92cGNp
LmggYi94ZW4vaW5jbHVkZS94ZW4vdnBjaS5oDQppbmRleCBmNGVjMWMyNTkyMmQuLjc3NzUwZGQ0
MTMxYSAxMDA2NDQNCi0tLSBhL3hlbi9pbmNsdWRlL3hlbi92cGNpLmgNCisrKyBiL3hlbi9pbmNs
dWRlL3hlbi92cGNpLmgNCkBAIC0zMSwxNCArMzEsMTMgQEAgdHlwZWRlZiBzdHJ1Y3Qgew0KICNk
ZWZpbmUgVlBDSV9NQVhfVklSVF9ERVYgICAgICAgKFBDSV9TTE9UKH4wKSArIDEpDQoNCiAjZGVm
aW5lIFJFR0lTVEVSX1ZQQ0lfQ0FQQUJJTElUWShjYXAsIGZpbml0LCBmY2xlYW4sIGV4dCkgXA0K
LSAgICBzdGF0aWMgY29uc3QgdnBjaV9jYXBhYmlsaXR5X3QgZmluaXQjI190ID0geyBcDQorICAg
IHN0YXRpYyB2cGNpX2NhcGFiaWxpdHlfdCBmaW5pdCMjX2VudHJ5IFwNCisgICAgICAgIF9fdXNl
ZF9zZWN0aW9uKCIuZGF0YS5yZWwucm8udnBjaSIpID0geyBcDQogICAgICAgICAuaWQgPSAoY2Fw
KSwgXA0KICAgICAgICAgLmluaXQgPSAoZmluaXQpLCBcDQogICAgICAgICAuY2xlYW51cCA9IChm
Y2xlYW4pLCBcDQogICAgICAgICAuaXNfZXh0ID0gKGV4dCksIFwNCi0gICAgfTsgXA0KLSAgICBz
dGF0aWMgY29uc3QgdnBjaV9jYXBhYmlsaXR5X3QgKmNvbnN0IGZpbml0IyNfZW50cnkgIFwNCi0g
ICAgICAgIF9fdXNlZF9zZWN0aW9uKCIuZGF0YS5yZWwucm8udnBjaSIpID0gJmZpbml0IyNfdA0K
KyAgICB9DQoNCiAjZGVmaW5lIFJFR0lTVEVSX1ZQQ0lfQ0FQKGNhcCwgZmluaXQsIGZjbGVhbikg
XA0KICAgICBSRUdJU1RFUl9WUENJX0NBUEFCSUxJVFkoY2FwLCBmaW5pdCwgZmNsZWFuLCBmYWxz
ZSkNCg0KSSBwcmludCB0aGUgdmFsdWUgb2YgTlVNX1ZQQ0lfSU5JVCwgaXQgaXMgYSBzdHJhbmdl
IG51bWJlciAoNjE0ODkxNDY5MTIzNjUxNzIwOSkuDQoNCg0KPiANCj4gSmFuDQoNCi0tIA0KQmVz
dCByZWdhcmRzLA0KSmlxaWFuIENoZW4uDQo=


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 09:31:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 09:31:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023477.1399453 (Exim 4.92)
	(envelope-from )
	id 1uU00G-0002zA-VZ; Tue, 24 Jun 2025 09:31:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023477.1399453; Tue, 24 Jun 2025 09:31: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 1uU00G-0002z3-T2; Tue, 24 Jun 2025 09:31:44 +0000
Received: by outflank-mailman (input) for mailman id 1023477;
 Tue, 24 Jun 2025 09:31: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 1uU00F-0002yv-9j
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 09:31:43 +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 0999bc92-50de-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 11:31:42 +0200 (CEST)
Received: by mail-lf1-x12c.google.com with SMTP id
 2adb3069b0e04-553b165c80cso200693e87.2
 for ; Tue, 24 Jun 2025 02:31:42 -0700 (PDT)
Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-553e414c819sm1738529e87.79.2025.06.24.02.31.39
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 24 Jun 2025 02:31:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0999bc92-50de-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750757501; x=1751362301; 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=byP8LjI+aWUJ/3ahxydRbTTYwpcCU0/sOWIxaFa3vSk=;
        b=P3uVBDm2ufxi7T0mf34QiQc6tkw4ZyzX43r4X+WnzV8cFm7VwVgMg97o5fCOhGBSUf
         k4cdd1XU/roUIrAyt1PCL8nHLIbQI+HprLu72vyN5rW6uJwwqpmIoHaUvYI457C8hFFA
         ukYFla9EPx/nrbzt0AcEeDn1xDKyhBQ0uTBLJJYeSzW5fnGZ84zujVr+Sc67Fjo+M0qO
         IUw7XH4t3WYcA4tgE4j6RP8oe+j0sP+qLliOIU6mYlWRb6LHfyu/WEIIwwM3QAeO3nwc
         CnACLb90aATtmOphhYaN612344w4NPMKnGpV74mOcqe5te0XhE+886n+UsPvGZPUMkad
         U13g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750757501; x=1751362301;
        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=byP8LjI+aWUJ/3ahxydRbTTYwpcCU0/sOWIxaFa3vSk=;
        b=U7lU/hROk6dNy3xDLpczODQ9pvRcdz07hP+fXAiafWgD74mZQrpcrSxzn60CuERbeF
         bUyuizBOqSPb0wYTJMuQjG65Z6P1rdatUD1bWsGY2N3+w6qPuPNsVoNU9p5dTllUx/DM
         7hMKehw5VddQRu/WldaiNHDEVHq812F1DEjJoXChyRaskeqJF13VX74s2tZ28NB0GOi/
         oRI3iM7vtDtprUhKzo9m8gCjal8okpEM1fDVPVsjd3mJVQrq7gpKbrIOR0c/q98rKr9v
         SOUhfCj0D9kvxW5fCSGEM8N2qCOVNj0l9qg9LdAmtiVcVyjli5g7wOiH3bWX34GsTFOB
         xlLw==
X-Gm-Message-State: AOJu0Yz7JJc0V2EME7TXhPDUdwPjYzc/q71D45sV3qMxgHQXGk3+Uacm
	7tfduiJifoihxjiInD09VfCvvhK5BB/bT3QCfewyeOU0t3URRG2ry2cXsjA3gaBcHZs=
X-Gm-Gg: ASbGncv86+szFV5HcuR+0iQSjwBA145qMW4infX8v+GDFCmwlM5gT8XUEEMMgpZYRtu
	rOkZE+1EuhJGq4gaGH0HbLP/H5LRhvd/SgMsZUz48Bx5W7CNVUiAU5YGO54YT5vxd9t6k5mqvz7
	hjAJd3Yd8gujCCS/E1yyOvrdCPTxQQX93QV/GY+qbCSHEJL77gCx8a3MgZQP5yupefjq3j2Se3c
	kB8UIwmP4XVkqU25WkhmAyYz8nLBgXXdDsiMxrJxDZb/qhG5HkdAIlcoqR4ZN+I2sDIIuplYLpQ
	YsrmngpZE7pA3t8DQaNGgxQo0LO8/1usUkL5++FY4t/rlMlJJ+YYHv8bx8BzyEkk/Y9g3HUY+t3
	l5P2SIDBEVAPp3AjAWQcA3llkpg==
X-Google-Smtp-Source: AGHT+IHbVNIJ4/GIRmsR+sg9L/Yy+f9x7Ag7IV0yYk0m581aBg8OJjhMaoqNPaNj5PRASROXQyk0Bg==
X-Received: by 2002:a05:6512:3c8b:b0:549:5b54:2c68 with SMTP id 2adb3069b0e04-553e3bcce22mr5219002e87.22.1750757501144;
        Tue, 24 Jun 2025 02:31:41 -0700 (PDT)
From: Mykola Kvach 
To: xen-devel@lists.xenproject.org
Cc: Mykola Kvach ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH] xen/char: wrap suspend/resume console callbacks with CONFIG_SYSTEM_SUSPEND
Date: Tue, 24 Jun 2025 12:31:22 +0300
Message-ID: <07f047e4a3640696e46c6890d3826c03d4f28856.1750756537.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.48.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Mykola Kvach 

This patch wraps the suspend/resume console callbacks and related code within
CONFIG_SYSTEM_SUSPEND blocks. This ensures that these functions and their
calls are only included in the build when CONFIG_SYSTEM_SUSPEND is enabled.

This addresses Misra Rule 2.1 violations.

Suggested-by: Jan Beulich 
Signed-off-by: Mykola Kvach 
---
 xen/drivers/char/console.c   |  4 ++++
 xen/drivers/char/ehci-dbgp.c |  6 ++++++
 xen/drivers/char/ns16550.c   | 12 ++++++++++++
 xen/drivers/char/serial.c    |  4 ++++
 xen/drivers/char/xhci-dbc.c  |  6 ++++++
 xen/include/xen/console.h    |  2 ++
 xen/include/xen/serial.h     |  4 ++++
 7 files changed, 38 insertions(+)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 5879e31786..ba5a809a99 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -1365,6 +1365,8 @@ void panic(const char *fmt, ...)
         machine_restart(5000);
 }
 
+#ifdef CONFIG_SYSTEM_SUSPEND
+
 /*
  * **************************************************************
  * ****************** Console suspend/resume ********************
@@ -1388,6 +1390,8 @@ int console_resume(void)
     return 0;
 }
 
+#endif /* CONFIG_SYSTEM_SUSPEND */
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/drivers/char/ehci-dbgp.c b/xen/drivers/char/ehci-dbgp.c
index e9cd59b254..a5c79f56fc 100644
--- a/xen/drivers/char/ehci-dbgp.c
+++ b/xen/drivers/char/ehci-dbgp.c
@@ -1419,6 +1419,8 @@ static void __init cf_check ehci_dbgp_endboot(struct serial_port *port)
     ehci_dbgp_check_release(port->uart);
 }
 
+#ifdef CONFIG_SYSTEM_SUSPEND
+
 static void cf_check ehci_dbgp_suspend(struct serial_port *port)
 {
     struct ehci_dbgp *dbgp = port->uart;
@@ -1452,12 +1454,16 @@ static void cf_check ehci_dbgp_resume(struct serial_port *port)
     ehci_dbgp_setup_postirq(dbgp);
 }
 
+#endif /* CONFIG_SYSTEM_SUSPEND */
+
 static struct uart_driver __read_mostly ehci_dbgp_driver = {
     .init_preirq  = ehci_dbgp_init_preirq,
     .init_postirq = ehci_dbgp_init_postirq,
     .endboot      = ehci_dbgp_endboot,
+#ifdef CONFIG_SYSTEM_SUSPEND
     .suspend      = ehci_dbgp_suspend,
     .resume       = ehci_dbgp_resume,
+#endif
     .tx_ready     = ehci_dbgp_tx_ready,
     .putc         = ehci_dbgp_putc,
     .flush        = ehci_dbgp_flush,
diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index eaeb0e09d0..6b4fb4ad31 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -57,7 +57,9 @@ static struct ns16550 {
 #endif
     /* UART with no IRQ line: periodically-polled I/O. */
     struct timer timer;
+#ifdef CONFIG_SYSTEM_SUSPEND
     struct timer resume_timer;
+#endif
     unsigned int timeout_ms;
     bool intr_works;
     bool dw_usr_bsy;
@@ -113,7 +115,9 @@ struct ns16550_config_param {
 static void enable_exar_enhanced_bits(const struct ns16550 *uart);
 #endif
 
+#ifdef CONFIG_SYSTEM_SUSPEND
 static void cf_check ns16550_delayed_resume(void *data);
+#endif
 
 static u8 ns_read_reg(const struct ns16550 *uart, unsigned int reg)
 {
@@ -420,7 +424,9 @@ static void __init cf_check ns16550_init_postirq(struct serial_port *port)
     serial_async_transmit(port);
 
     init_timer(&uart->timer, ns16550_poll, port, 0);
+#ifdef CONFIG_SYSTEM_SUSPEND
     init_timer(&uart->resume_timer, ns16550_delayed_resume, port, 0);
+#endif
 
     /* Calculate time to fill RX FIFO and/or empty TX FIFO for polling. */
     bits = uart->data_bits + uart->stop_bits + !!uart->parity;
@@ -506,6 +512,8 @@ static void __init cf_check ns16550_init_postirq(struct serial_port *port)
     ns16550_setup_postirq(uart);
 }
 
+#ifdef CONFIG_SYSTEM_SUSPEND
+
 static void cf_check ns16550_suspend(struct serial_port *port)
 {
     struct ns16550 *uart = port->uart;
@@ -584,6 +592,8 @@ static void cf_check ns16550_resume(struct serial_port *port)
         _ns16550_resume(port);
 }
 
+#endif /* CONFIG_SYSTEM_SUSPEND */
+
 static void __init cf_check ns16550_endboot(struct serial_port *port)
 {
 #ifdef CONFIG_HAS_IOPORTS
@@ -638,8 +648,10 @@ static struct uart_driver __read_mostly ns16550_driver = {
     .init_irq     = ns16550_init_irq,
     .init_postirq = ns16550_init_postirq,
     .endboot      = ns16550_endboot,
+#ifdef CONFIG_SYSTEM_SUSPEND
     .suspend      = ns16550_suspend,
     .resume       = ns16550_resume,
+#endif
     .tx_ready     = ns16550_tx_ready,
     .putc         = ns16550_putc,
     .getc         = ns16550_getc,
diff --git a/xen/drivers/char/serial.c b/xen/drivers/char/serial.c
index 591a009008..adb312d796 100644
--- a/xen/drivers/char/serial.c
+++ b/xen/drivers/char/serial.c
@@ -495,6 +495,8 @@ const struct vuart_info *serial_vuart_info(int idx)
     return NULL;
 }
 
+#ifdef CONFIG_SYSTEM_SUSPEND
+
 void serial_suspend(void)
 {
     int i;
@@ -511,6 +513,8 @@ void serial_resume(void)
             com[i].driver->resume(&com[i]);
 }
 
+#endif /* CONFIG_SYSTEM_SUSPEND */
+
 void __init serial_register_uart(int idx, struct uart_driver *driver,
                                  void *uart)
 {
diff --git a/xen/drivers/char/xhci-dbc.c b/xen/drivers/char/xhci-dbc.c
index d011159d18..1f7d4395dc 100644
--- a/xen/drivers/char/xhci-dbc.c
+++ b/xen/drivers/char/xhci-dbc.c
@@ -1271,6 +1271,8 @@ static void cf_check dbc_uart_flush(struct serial_port *port)
         set_timer(&uart->timer, goal);
 }
 
+#ifdef CONFIG_SYSTEM_SUSPEND
+
 static void cf_check dbc_uart_suspend(struct serial_port *port)
 {
     struct dbc_uart *uart = port->uart;
@@ -1303,6 +1305,8 @@ static void cf_check dbc_uart_resume(struct serial_port *port)
     set_timer(&uart->timer, NOW() + MICROSECS(DBC_POLL_INTERVAL));
 }
 
+#endif /* CONFIG_SYSTEM_SUSPEND */
+
 static struct uart_driver dbc_uart_driver = {
     .init_preirq = dbc_uart_init_preirq,
     .init_postirq = dbc_uart_init_postirq,
@@ -1310,8 +1314,10 @@ static struct uart_driver dbc_uart_driver = {
     .putc = dbc_uart_putc,
     .getc = dbc_uart_getc,
     .flush = dbc_uart_flush,
+#ifdef CONFIG_SYSTEM_SUSPEND
     .suspend = dbc_uart_suspend,
     .resume = dbc_uart_resume,
+#endif
 };
 
 /* Those are accessed via DMA. */
diff --git a/xen/include/xen/console.h b/xen/include/xen/console.h
index 83cbc9fbda..feb57f92f1 100644
--- a/xen/include/xen/console.h
+++ b/xen/include/xen/console.h
@@ -44,8 +44,10 @@ int console_steal(int handle, void (*fn)(const char *str, size_t nr));
 /* Give back stolen console. Takes the identifier returned by console_steal. */
 void console_giveback(int id);
 
+#ifdef CONFIG_SYSTEM_SUSPEND
 int console_suspend(void);
 int console_resume(void);
+#endif
 
 /* Emit a string via the serial console. */
 void console_serial_puts(const char *s, size_t nr);
diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h
index 63a82b032d..8e18445552 100644
--- a/xen/include/xen/serial.h
+++ b/xen/include/xen/serial.h
@@ -66,9 +66,11 @@ struct uart_driver {
     void (*init_postirq)(struct serial_port *port);
     /* Hook to clean up after Xen bootstrap (before domain 0 runs). */
     void (*endboot)(struct serial_port *port);
+#ifdef CONFIG_SYSTEM_SUSPEND
     /* Driver suspend/resume. */
     void (*suspend)(struct serial_port *port);
     void (*resume)(struct serial_port *port);
+#endif
     /* Return number of characters the port can hold for transmit,
      * or -EIO if port is inaccesible */
     int (*tx_ready)(struct serial_port *port);
@@ -131,9 +133,11 @@ int serial_irq(int idx);
 /* Retrieve basic UART information to emulate it (base address, size...) */
 const struct vuart_info* serial_vuart_info(int idx);
 
+#ifdef CONFIG_SYSTEM_SUSPEND
 /* Serial suspend/resume. */
 void serial_suspend(void);
 void serial_resume(void);
+#endif
 
 /*
  * Initialisation and helper functions for uart drivers.
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 09:32:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 09:32:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023487.1399464 (Exim 4.92)
	(envelope-from )
	id 1uU01N-0003aK-Bn; Tue, 24 Jun 2025 09:32:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023487.1399464; Tue, 24 Jun 2025 09: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 1uU01N-0003aD-9E; Tue, 24 Jun 2025 09:32:53 +0000
Received: by outflank-mailman (input) for mailman id 1023487;
 Tue, 24 Jun 2025 09:32: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 1uU01L-0003YL-98
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 09:32:51 +0000
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com
 [2a00:1450:4864:20::133])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 323bca5e-50de-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 11:32:50 +0200 (CEST)
Received: by mail-lf1-x133.google.com with SMTP id
 2adb3069b0e04-553b60de463so5511550e87.3
 for ; Tue, 24 Jun 2025 02:32:50 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 323bca5e-50de-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750757570; x=1751362370; 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=Zjfv4ZRWPWr+bDVThanQyVMbl9QwdG+xGJH6IJSYiYs=;
        b=JDfBr9XGKyapd9hX2EMJL6Sha4E5rDQlSoSRd6MYKpYzAeVb8AiO8xhFWPxqCSURxA
         byFaCiPeahDlRRCVYXWNoKbnNui5Z/i18TwG1vdAPmDj9MVaqNXrCjti59AqZSG7SDfs
         4fqFR3KR5dnLSS5zi6ECdwDLp7POhX9wrHcmYYCV7DDg6NVmlXz10K5Qt61sBpjlZ7NN
         FGhgzY80ZVJKuYa78c81JZYkWACxXl5xJVnQ6mPVhrEWcOytZkZUAWFSEx8eh/f6c6gH
         dapIbKgCqNPNjT3QasNG7O7/fFG5j/pMGkwNutQSVfEEYtFRb9O9WOLLa1A+O52zFg5h
         bx7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750757570; x=1751362370;
        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=Zjfv4ZRWPWr+bDVThanQyVMbl9QwdG+xGJH6IJSYiYs=;
        b=be7B95+Fv3Yu1pcsG9YOmDJJNFT2Kir3yhYN3/14MTU0ixgCf3glTp5Y1AZZr4PndI
         +keXPQNPAq/GrPT4LRPB9PZeH9Sn+/O/96NfSlIminFSQq2BTcbKxCzJZCwsQWsOQBrp
         lKgPHuQmoM4WLkIP62j2Vjpgqwylq+38qHGPdOUddJ61lPQ5rYHrcCfHwhSEEbmPww5O
         Kr6QtdIy9lkIB+6fCeMElU5MNGFKuhMEhAEM+P3fr5k1I9UAepIXQKSZItTp/PELcAuQ
         BcpwY4uSUSWHQuLAyc2sSQ0fj9anf/3pJAnFrhE+vNc31UKl5hIDkwMCZZ/t++WJIEEe
         xoQQ==
X-Forwarded-Encrypted: i=1; AJvYcCXK8SRuXa41slYYW/dD9cB0Rxo5p5f4m7Xt64W728mpeykPr55FeT1lcCrK3WA0xML0kWbPiM7sSrY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzVz9+09qAKOrntdVBIJd+2Qi/yKI4fLpCSaiJHMSkBZvq2jdcR
	u31nXEd0uPdxRXpecEfU75ZuoVxh14PS/T26EN1KF3Wama0Yoj5vuSMOTFrKM1L+WpUayRTWLhy
	3BRg3kzBnLyJpNM6mqfkUg6WdaJvmxAk=
X-Gm-Gg: ASbGncv92lNLP4TXoTywsCVARxdsXbRgYhi+R67S5LhoM2BpXsUFMrSzI/Uwz0mPpqh
	V/iqIOc+XCvqztslFGvT0ESkm9Xhlm6A0oNYm6ONV0cSPdrZdkLZufmQaRdgXrJz2KkGq4H1Rpd
	yeWsiQ2BxuUZetqL+9oLaI7gnDvsTv6fwTrlYQyqaPfw==
X-Google-Smtp-Source: AGHT+IFoocmjn9MyDHvP+VU0KkkfaturAcbKHIS58gY4vHCNTW5754Q6jZJc2fD9Qf3+TC8oJKPHMm/HqeWTC1JGl/8=
X-Received: by 2002:ac2:4f08:0:b0:553:2311:e1f6 with SMTP id
 2adb3069b0e04-553e3d05097mr4344893e87.49.1750757569673; Tue, 24 Jun 2025
 02:32:49 -0700 (PDT)
MIME-Version: 1.0
References: <5449d6fc4a6e47af173d9e2b285f1e3398de98a3.1750749332.git.mykola_kvach@epam.com>
 <2b345a72-5ab7-443f-bff4-2b4ee9952825@suse.com> 
 
In-Reply-To: 
From: Mykola Kvach 
Date: Tue, 24 Jun 2025 12:32:38 +0300
X-Gm-Features: AX0GCFuirwi4-Me3nNzmgiRWkBwchd5myKsSKc3iYICknn2TvnuJaCYsSfhx3P4
Message-ID: 
Subject: Re: [PATCH v4] xen/char: implement suspend/resume calls for SCIF driver
To: Jan Beulich 
Cc: Volodymyr Babchuk , Stefano Stabellini , 
	Julien Grall , Bertrand Marquis , 
	Michal Orzel , 
	Oleksandr Andrushchenko , Mykola Kvach , 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 24, 2025 at 11:32=E2=80=AFAM Jan Beulich  wr=
ote:
>
> On 24.06.2025 10:29, Mykola Kvach wrote:
> > On Tue, Jun 24, 2025 at 10:53=E2=80=AFAM Jan Beulich  wrote:
> >> On 24.06.2025 09:18, Mykola Kvach wrote:
> >>> @@ -281,6 +313,10 @@ static struct uart_driver __read_mostly scif_uar=
t_driver =3D {
> >>>      .start_tx     =3D scif_uart_start_tx,
> >>>      .stop_tx      =3D scif_uart_stop_tx,
> >>>      .vuart_info   =3D scif_vuart_info,
> >>> +#ifdef CONFIG_SYSTEM_SUSPEND
> >>> +    .suspend      =3D scif_uart_suspend,
> >>> +    .resume       =3D scif_uart_resume,
> >>> +#endif
> >>>  };
> >>
> >> As this being put inside #ifdef was to be expected, imo a prereq chang=
e is to
> >> also make the struct fields conditional in xen/console.h. I think I di=
d even
> >> comment to this effect back at the time.
> >
> > Would you prefer that I include this change in the current patch
> > series, or is it acceptable to address it in a separate patch?
>
> Either way is fine with me. I expect the header fine change to be able to=
 go
> in right away (once submitted), whereas the patch here may take some time=
 for
> people to review.

Got it, I'll submit a separate patch to make the struct fields and
related code wrapped within SYSTEM_SUSPEND.

~Mykola

>
> Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 09:37:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 09:37:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023494.1399474 (Exim 4.92)
	(envelope-from )
	id 1uU05h-0004TU-Sz; Tue, 24 Jun 2025 09:37:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023494.1399474; Tue, 24 Jun 2025 09:37: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 1uU05h-0004TN-Q9; Tue, 24 Jun 2025 09:37:21 +0000
Received: by outflank-mailman (input) for mailman id 1023494;
 Tue, 24 Jun 2025 09:37: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 1uU05h-0004TH-BC
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 09:37:21 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on2061e.outbound.protection.outlook.com
 [2a01:111:f403:2009::61e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d0a1d2a9-50de-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 11:37:17 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by DS0PR12MB7704.namprd12.prod.outlook.com (2603:10b6:8:138::22) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.20; Tue, 24 Jun
 2025 09:37: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%4]) with mapi id 15.20.8835.027; Tue, 24 Jun 2025
 09:37: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: d0a1d2a9-50de-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=JcE9haBs2am8ni3f7+9r1kBICDBXsC0FiaurQduXbvxcQMH37Rc752oZGPxvU7kBcYKp6hjH3tBL43d75I7MY/ylhT5KWAXcxyOGcl3yp3hf/H29kvXRVHEAY82Qbm30LRLO+NiZ/zkPOy0OPqUtFpiyyuhanUha9SiK6vWmaRksSQI5eKZatfE16lA7m99pw2i1xMnGn+sqdqD1LrH982B2OwxjMiXgDNfGQb65qRvNRxNmM9W1v8vEl0Szi5N0GyZz3S+dx3fsKZXpugjgUker1/aRSO5sS5/zmBeF7kEqwfDQ4OkqsR2PDGEnFO4AtnzUx0QrHqMAD/8Nbr55wg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=fptTgdbhLrjlnkw5z6nGSycRPV02lARyQEKGVV1iGs8=;
 b=NpZZFk+Kmpwri3cjED5VAqTrWyHxwT0KuECUnCthSoaBCcOuqHZWR1CsN5pIwNYduD9Z6zTO0EqRY4yIbBJ5R9rl+7SrldaqVwMAlbAYyGQypiq3arwKBcmF1XxpioVf2aa2JItoQXCUBOKMZXeTyXtChm+Wpj2mcjdJrXLk5+OkQt2LvZoogzi+qR0B96JdkM7Pq9tLzjyiIF/+5Io0foh1SHxR8mLhbAE3E44F3jyaUhWQAN6s4OGavZ6PT3SeZECWfmOcSHkItfagfkpc6Zg3WHvyGXGNtDq/tWDCNPO9Onm/8QeRZyjp6eavSRTtAULyj+gbnrDvf5LDLT2Z3g==
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=fptTgdbhLrjlnkw5z6nGSycRPV02lARyQEKGVV1iGs8=;
 b=qZDyNlr0vwAis9Gt8AY73tsXkUC5kjK+hUOEh96yZxJGud0KjEKo45FQuGWf8GkpzHqBNBW7YwsfqyuFNehQFVbSlTQS/Lr+8GL/FEkQbYVxZqQUTNmuaKmAdwhm80X1vMB1BVhu4kioe2zHyygDnrF3b8wBC/zrD8aCTEWF3o4=
From: "Chen, Jiqian" 
To: Jan Beulich , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	
CC: "Huang, Ray" , Andrew Cooper
	, Anthony PERARD ,
	"Orzel, Michal" , Julien Grall ,
	Stefano Stabellini , "xen-devel@lists.xenproject.org"
	, "Chen, Jiqian" 
Subject: Re: [PATCH v6 4/8] vpci: Hide extended capability when it fails to
 initialize
Thread-Topic: [PATCH v6 4/8] vpci: Hide extended capability when it fails to
 initialize
Thread-Index: AQHb23ycT0X2vA9tYE2cHa4M+crvOLQJAzsAgAmiH4A=
Date: Tue, 24 Jun 2025 09:37:13 +0000
Message-ID:
 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-5-Jiqian.Chen@amd.com>
 <816dd3fc-e6fc-40f6-b7c9-29d2411b52e5@suse.com>
In-Reply-To: <816dd3fc-e6fc-40f6-b7c9-29d2411b52e5@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.8835.025)
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_|DS0PR12MB7704:EE_
x-ms-office365-filtering-correlation-id: b960f6d1-0759-4fd6-f836-08ddb302b2fd
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?aStuTnlFTWN4dFg5OTkwOE9aSWNCZWVYTHkzQ0pMSnZLV3VHUkFmeXVPVXV0?=
 =?utf-8?B?ZG1VdktFc1hTeGxjZFFWYXBrNnVUaE1nM1NBUnRqS0w2allQTnkvMy9TOTF3?=
 =?utf-8?B?VDEyNEx4THE3ZlJIUitjakpvd2VRaDJHU0xtOFdlNXdqZjdGZDZETzlmYURl?=
 =?utf-8?B?QzNyWGUzOWtXZjFYd1JkUzJTeGM4VmpnWFhVWE9qeXI5WHJVSHg3STdLVTk1?=
 =?utf-8?B?ZUV4eHY5c1BMVHM5Q1hNOVQxVmx3YTZWNjFtVXpNMGh3cG15eWFxMGhUaTBj?=
 =?utf-8?B?MWdHZHk0YVlzMmZ6YzdoQlNLaFpRSXM3MWF1bW1aQUhXeVlzb21nUkNaeGhF?=
 =?utf-8?B?Tmg3amlFUjJPTE9FTHlVdDdZc2NkTUQvc3lScjNNTzFNSFlrT2JYMkVDMVJm?=
 =?utf-8?B?cVNGdVBjUmJYSmN2WnRLL3AveU84WTRxMm5yelVlUmYrQS9NUDFGQjVCOGZz?=
 =?utf-8?B?cExGR210azBjNzRwRHo5WUQzeXZZRk1sdzVLM0xSOHVXZTJ0SlQxQ2NEZGh2?=
 =?utf-8?B?Tk1xOVBCVVE5Zno5OHM5L0N5ZkhMYjRmQk1TZWtpRUhrcjljSU80dzZSeDRx?=
 =?utf-8?B?TG1jbXQ4SDRaaFczSTFHWUVxV2hlY3JBY2hwMDhpcVVNTnVrTThmVXBnTCth?=
 =?utf-8?B?eWdRK0JSNlVhYkk2RUgyRmRoS1NrLzlTTDQ2UGF6UWdtUzBIQUJ2Z3lnNGVD?=
 =?utf-8?B?Zmg3aVhZK21QYTlDNWdIVlFMZzNDUW40MWhRSVpJODQ5Y3g2QlNSSDFZc21W?=
 =?utf-8?B?OE93VU1jbEQxUFd6ZTFPU3ZtK21QbkFRekd6NVVvVFY0SUYxSHppZHNDUzUz?=
 =?utf-8?B?T0FiaXQwRTVQd25SOXhNZXB0NnJ3M2EyTDdxSGlTUEFSMTNyWXNjeEN6d0Vw?=
 =?utf-8?B?dDVsc25Yc0lNTzFGdTNuRElHcm5lbXE5akVESERucG5wbXJXOGprcjE3NUVu?=
 =?utf-8?B?SHNmNDVUajlCdDhQQkUrWXpua2s5V2QyZzFIWDlUVzJwZDBlMzNadURwZTRa?=
 =?utf-8?B?b1hjbitpRVorcTFDUm1vSUVTOWlOcE9NMktDVUNJNlNFS0hWYTFZTy9PQndO?=
 =?utf-8?B?QlpsdThjb3RZczFoQWpzdTk5azZ1ZlFRMUtncTNjVlNsOXRqYlFWNVIwR0Jl?=
 =?utf-8?B?QXFTQmZMaVZseSt1M3JTZFZKYnFiVzA1QTNiZmxqb3pKRmx0NksxMkt3c2RY?=
 =?utf-8?B?cGpQOHM5K0tKQ1JSVXp5N1hzbG5NN3BEdjNTMWJqcTREcldneDRYeE95akd6?=
 =?utf-8?B?QzA4MlNURENLdHA0RmtEWHBKbzJYRGpRVEkzMmFlTnBkd1poY2x0dzloYnBm?=
 =?utf-8?B?Vll1eDAvWnhjK21SbU95VEFXc216bVpxdGlUZ3c0elBlMzhmTm5iRUVnaGJL?=
 =?utf-8?B?dCtKWHVZeHlxMTAwTWk0L3VyRFpxait4U3pKR0U3bEl4Qit4ek13MVlyZ2Nx?=
 =?utf-8?B?ZGZ0cXEvVS85U0pSMlpkZDZKcTR2REVGQ3NDNjBQdnFoa2FtWnRBYWZTSUhJ?=
 =?utf-8?B?bjZnWEJLNmhidEdQSTNKN1ZuTXBQQmYyUFVZelZwZU9pRDcvOHIxb1oyV29x?=
 =?utf-8?B?cUpJbTJPWmg0TTJYRk16a1RPZGRtUERUL2JvZFBva0Frb1crbTdqZXZjYXoy?=
 =?utf-8?B?bkpDQzVueDBQSVpvR2M2YmRXQXVHcFpCYkdoRGtxcHB5ZTI2UVBYL2pvQXhp?=
 =?utf-8?B?R0xJdjhQeEFqUU04QXJJdXFpL2Rua2szQXNVSXFKaEVKVXB6K3ZjbEdtRTFI?=
 =?utf-8?B?NnNsUjVHbjBGVExKZ3pkOUZqZXJ2MXJ4QTlhdlJHcklIMXlWY2daSkdJdUhX?=
 =?utf-8?B?d1ptQ3pCT1AxdWk4M0FvREYwU242bEtPNEpvU1BLQU5lbWpBVGJwc0JabFRr?=
 =?utf-8?B?dnovQ3JvcFNyL240TGFieVZDbXlsdWVLenhKUy9BQWM4V0k5T1ovSmpHZFZC?=
 =?utf-8?B?bWMxR2xJRjVzejI0VUVIaitadmZOT0FCV3RBOXdvYjVJUHVUei9LUjUwOUVN?=
 =?utf-8?Q?2TX+tyyprv9h4YETitj/N/WpU+k+/8=3D?=
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?SjczRFZESTFVdXVSMUhUWG1TT1BkcG8yT3dEVnRYUE55YWgzVzlqc0ljdUg5?=
 =?utf-8?B?UzJRYUpHUDdIQk5WalVhYWJ2b0FKenRFTFNFN3FpS25rbVllQXBIamhmUWxr?=
 =?utf-8?B?bXMxSlZZOEF3VXBJd1gyNHdtMTY4WDZuUXlYcTNQenA0Lzd3Rmh1MVJRTzh5?=
 =?utf-8?B?WnBKSHRNU1NDZDBsQW1tSWdUNnZ6K2pLTWZIeU9FYjN2QU1ibnNCbWRrdytl?=
 =?utf-8?B?WVdCeWQ4UEJ4VVB0WjNPUFgwUXMxQk1aL2k2NXZseGduUjRHQWVXbmtKL3hk?=
 =?utf-8?B?bHBXdkxwSVVRdUVkY09oejZXRUtXZGNFb2h1ZWpUQk9PVEphZ0dIL215SjQz?=
 =?utf-8?B?ZFU1OTJGeVUveklnWEk2T1FNbTAvRWs1UjgyY0c2N0gyL01TRlBzSFFHUzdG?=
 =?utf-8?B?OFZaSVNheFlmQnJQSXBXSGFZTDVmWEQ5QmlQOWpBWTRiS08xOFhHY0FlbnJl?=
 =?utf-8?B?dThrVERpWjB2b0FNcGNpQ2VDbXZqTENkNVk1elBRTFV4aXVrWHRuMHpTOUpj?=
 =?utf-8?B?MFJRWUpwK0pUOHRHb0w1ZFA5dDVYRXcxNzhXRXk1UW1XYUxXUVp0T3A2ODJW?=
 =?utf-8?B?Z3NhQUhkZXhMU2JhSk1jbEhZWVRqUTc3akc5b3lmOFhsM1RNb1I3WnprSG9F?=
 =?utf-8?B?eE0wQ21MclptSWVwcW1kZ2FGaktXaHp0eFJHY0kvbTh3azdtODd1a2MyZzVJ?=
 =?utf-8?B?VUo5Znh0R1NPWVIyMUljSVF2ektqaHF4UUEvYzgxTnVBOHl5S2NQWHNzbFVr?=
 =?utf-8?B?S1poNEE4alNmZ21yc01mK0hvVklzTTV5cGNOalN0V3Y2UTc4N3JybEJGZnBm?=
 =?utf-8?B?dUlCWlQza21nTnphUVFKZzJ4U1VmYmpnNWFVY1ZaT28rL3hFQXl3T0ZQT3NJ?=
 =?utf-8?B?UmwyZ2xMdzRBRDlWdU41cXNkU0lkSHpGdThkaEhYZ29lYzRhcXljREVJUmpD?=
 =?utf-8?B?QklNWTlEQmV1OVVteTQ3dFNBd2d5Y3I5T0crRjN2bEZVUm00OUJ0WFFOeGk4?=
 =?utf-8?B?Tk1KVm1pMGMxWU05cjcrUTBIZTZhdFplZFdTV1JQMkEyWG5PakIwUzVuWWZW?=
 =?utf-8?B?TGZZQ3BQMXNOMDNqcnNyUWUxRmxYNkozL0c0VWFBZzdkOFlFNWVEcDdTQ0c2?=
 =?utf-8?B?ZmtwTTZ4KzhuSHdQT1N2VGNPNjBlV3c5K0NYbVFLT1R4Um9xSit3eXczTG5D?=
 =?utf-8?B?RTJEclVVN1A5ZzZ3UUE3alNnRzJsdDBHdzZQRGJEa21EUS9GWVFrdVRablY2?=
 =?utf-8?B?K1hXendrNzk1WGlhMW5FQ2hmU0JZamRuVFdHeGlsejhmTjZGYXlUWklBRHJT?=
 =?utf-8?B?bEY5NS9WRERnUmVFN0FxcURFZmlLRVZNdnQ0N2tTMEpvYWZBMWNnQWN2MUEv?=
 =?utf-8?B?VnFTeEZRRlZndG0rYVVIMWZGWlhkR0UraS9Mc0pqOEpyOE13OVU1T0U4Q0FE?=
 =?utf-8?B?Ym1zSTdEdnJieXhSSjYrQk5Udk9Ra2tndkhhVllBUmpkaEFTOTBvMTc3WUpq?=
 =?utf-8?B?Q3AycHF4NERzdkVxUHZrd1BxYWRpUjgzTU56YUliMFg5RnZaVTlnMWhqQ0Vj?=
 =?utf-8?B?R2RIWlFuNXpTcElFZm00R0tJLzQ5dk1CaXJFbVRka2xrUmwydXVnZ1RkcGRG?=
 =?utf-8?B?MThZWE9mS2FYQmsxLzZFb1N4M29YZE9PVy9Tak5ZdXVFYWdWQ1YvNmltMGlr?=
 =?utf-8?B?aG9COVNJeDVTa21PT1VNT3QzRmgxS3F3SlUwZ0tsUjAzZ2FlazhkZG5qQTdl?=
 =?utf-8?B?a0Z3ZE5aTlhHK2FsNjBDS3BWMncwYVhvQmlIT1I0a3VIR1JjS0g1VmxlSTJG?=
 =?utf-8?B?ckdtSXY5em1LU1FPemFtRlRMRHJqMWlQRXdkUWhCeDZKSFlkR0V6em1DZkhE?=
 =?utf-8?B?aHM1UXJGTlBTS3hYQ3daTWk4a3ROTjJIMlpabmtJRTFQMFgwa0NpRnM0WTl3?=
 =?utf-8?B?cHp3bGN3cUZ6Y2xGR2lIWCtBM1FmbDhNRmxPUWordDR5WkhLeXlCcnQrZVU4?=
 =?utf-8?B?dndXZkMrMFV2THNWcUhhT2tEbWYzZklvclVrSnBkaC8xSFM1Q1NjSFIvY2hn?=
 =?utf-8?B?QjNoL1R5WW0zR0p0Z1loV2U2UEJING1UOE1qMlBxUlZ6WmIvSm44V0VYdHg4?=
 =?utf-8?Q?VC/A=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <4360FD69A6C5B64C8ADE9409D4BE0483@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: b960f6d1-0759-4fd6-f836-08ddb302b2fd
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2025 09:37:13.0238
 (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: WnQ+UuTs5phEm1taPaEI0pklBUvcjs1lsy62aGsxCFt6ZztT19Q+86zaiPjNFlO7O9UTQFxRPdDAhDz+QvwYKw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB7704

T24gMjAyNS82LzE4IDIyOjI3LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMTIuMDYuMjAyNSAx
MToyOSwgSmlxaWFuIENoZW4gd3JvdGU6DQo+PiArc3RhdGljIGludCB2cGNpX2V4dF9jYXBhYmls
aXR5X2hpZGUoc3RydWN0IHBjaV9kZXYgKnBkZXYsIHVuc2lnbmVkIGludCBjYXApDQo+PiArew0K
Pj4gKyAgICBjb25zdCB1bnNpZ25lZCBpbnQgb2Zmc2V0ID0gcGNpX2ZpbmRfZXh0X2NhcGFiaWxp
dHkocGRldi0+c2JkZiwgY2FwKTsNCj4+ICsgICAgc3RydWN0IHZwY2lfcmVnaXN0ZXIgKnIsICpw
cmV2X3I7DQo+PiArICAgIHN0cnVjdCB2cGNpICp2cGNpID0gcGRldi0+dnBjaTsNCj4+ICsgICAg
dWludDMyX3QgaGVhZGVyLCBwcmVfaGVhZGVyOw0KPj4gKw0KPj4gKyAgICBpZiAoIG9mZnNldCA8
IFBDSV9DRkdfU1BBQ0VfU0laRSApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIEFTU0VSVF9VTlJF
QUNIQUJMRSgpOw0KPj4gKyAgICAgICAgcmV0dXJuIDA7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsg
ICAgc3Bpbl9sb2NrKCZ2cGNpLT5sb2NrKTsNCj4+ICsgICAgciA9IHZwY2lfZ2V0X3JlZ2lzdGVy
KHZwY2ksIG9mZnNldCwgNCk7DQo+PiArICAgIGlmICggIXIgKQ0KPj4gKyAgICB7DQo+PiArICAg
ICAgICBzcGluX3VubG9jaygmdnBjaS0+bG9jayk7DQo+PiArICAgICAgICByZXR1cm4gLUVOT0RF
VjsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICBoZWFkZXIgPSAodWludDMyX3QpKHVpbnRwdHJf
dClyLT5wcml2YXRlOw0KPj4gKyAgICBpZiAoIG9mZnNldCA9PSBQQ0lfQ0ZHX1NQQUNFX1NJWkUg
KQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBpZiAoIFBDSV9FWFRfQ0FQX05FWFQoaGVhZGVyKSA8
PSBQQ0lfQ0ZHX1NQQUNFX1NJWkUgKQ0KPj4gKyAgICAgICAgICAgIHItPnByaXZhdGUgPSAodm9p
ZCAqKSh1aW50cHRyX3QpMDsNCj4+ICsgICAgICAgIGVsc2UNCj4+ICsgICAgICAgICAgICAvKg0K
Pj4gKyAgICAgICAgICAgICAqIFRoZSBmaXJzdCBleHRlbmRlZCBjYXBhYmlsaXR5ICgweDEwMCkg
Y2FuIG5vdCBiZSByZW1vdmVkIGZyb20NCj4+ICsgICAgICAgICAgICAgKiB0aGUgbGlua2VkIGxp
c3QsIHNvIGluc3RlYWQgbWFzayBpdHMgY2FwYWJpbGl0eSBJRCB0byByZXR1cm4gMA0KPj4gKyAg
ICAgICAgICAgICAqIGFuZCBmb3JjZSBPU2VzIHRvIHNraXAgaXQuDQo+PiArICAgICAgICAgICAg
ICovDQo+PiArICAgICAgICAgICAgci0+cHJpdmF0ZSA9ICh2b2lkICopKHVpbnRwdHJfdCkoaGVh
ZGVyICYgflBDSV9FWFRfQ0FQX0lEKGhlYWRlcikpOw0KPiANCj4gQ2FuIHdlIHJlbHkgb24gT1Nl
cyByZWNvZ25pemluZyBJRCAwIGFzICJqdXN0IHNraXAiPyBTaW5jZSB0aGUgc2l6ZSBpc24ndCBl
bmNvZGVkDQo+IGluIHRoZSBoZWFkZXIsIHRoZXJlIG1pZ2h0IGJlIGlzc3VlcyBsdXJraW5nIGhl
cmUuDQpJIHdhcyBub3QgdmVyeSBjb25maWRlbnQgYWJvdXQgaG93IHRvIGhhbmRsZSB0aGlzIHNp
dHVhdGlvbi4NClRoaXMgdmVyc2lvbiB3YXMgbW9kaWZpZWQgYWNjb3JkaW5nIHRvIFJvZ2VyJ3Mg
c3VnZ2VzdGlvbnMuDQpNYXliZSBSb2dlciBjYW4gZ2l2ZSB5b3UgbW9yZSBleHBsYW5hdGlvbi4N
Cg0KPiANCj4gSmFuDQoNCi0tIA0KQmVzdCByZWdhcmRzLA0KSmlxaWFuIENoZW4uDQo=


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 09:46:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 09:46:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023501.1399483 (Exim 4.92)
	(envelope-from )
	id 1uU0EZ-0006LY-O7; Tue, 24 Jun 2025 09:46:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023501.1399483; Tue, 24 Jun 2025 09:46:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uU0EZ-0006LR-LN; Tue, 24 Jun 2025 09:46:31 +0000
Received: by outflank-mailman (input) for mailman id 1023501;
 Tue, 24 Jun 2025 09:46: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 1uU0EY-0006LJ-Kn
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 09:46:30 +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 141d5549-50e0-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 11:46:19 +0200 (CEST)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-addda47ebeaso47655666b.1
 for ; Tue, 24 Jun 2025 02:46:19 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ae054083c87sm841373066b.89.2025.06.24.02.46.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 02:46:17 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 141d5549-50e0-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750758378; x=1751363178; darn=lists.xenproject.org;
        h=in-reply-to:content-language:references:cc:to:subject:from
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=1Q7zDaHi7VY/WUKV4VqHjUqLF+P4rmn96cO/MBcraAg=;
        b=iN8DaMggKRIazQnTwB3x6GBKlFiAIWh4D4/Q1gwpXVOwsG9CS4dLgvKGt5gjt6Np/8
         VpwpdE8x6AKOdk76G8G7BBTYqeOdjsAIRj81ioRF2hBofwVKROC5UMNb49XoQjUk54Tw
         TEM55K4bjGEghbzo77ioyeQhwNfmrfsIYOzs5srG0NiHo31idUYZYW5epbJ60Qepu+Kb
         gDMs6iMXCZDGCZeL6NE0Ox3H/w1Xtv60OCct4vh4k+OgBljco9D8uQ2QZylYaEuqXrWZ
         lr66jgCVU0DCUo5muZYbKIuI6l2REzWO70KXjSYtVHvJbNq9fkhyCP0TdGmszFhsM6E2
         I4Ug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750758378; x=1751363178;
        h=in-reply-to: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=1Q7zDaHi7VY/WUKV4VqHjUqLF+P4rmn96cO/MBcraAg=;
        b=JmcySxZUAfMGlRZ9ScPUxXR9Querhz/AneqaXoHQLmVD5+N6xYBqNe/Vz1b944uhZe
         D0sVKzJdsRPPHW/tvDTX5pRvGgTx2cWwywGHAki0uWGpAaaGRqOEQCaHx5K05+rE+yGh
         dqjfN46xW3fktqYEkgnMqhOSqakFv8rjqToGrd1jFWD43KECZsSauBZZCH3zsuUPx0RM
         2ypSVxfpDMtzewJs3GP2rlQbLezKtDyNjaLOMwqejlgvcYc6w+XnHfmTgniPA3zVj+uH
         CoSjHsg7Pcwrkh/QVIs9drPEgcaZpx6bDxcZhxJYkI60JpE3gQ50Tqk259K0aFxknu9E
         PO1w==
X-Forwarded-Encrypted: i=1; AJvYcCWQkGFltJFNp7liDT5V6hTjKQnrxYwHYgkw4A4+VEMQyGtP5//C5Od+2PMfJjWMCOmznP2Pxgh1TjA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzF04Kk1uREThB2JzUsCMb79hzNzinIJS7rAVP9xgKqV7juo+cl
	fS/7/YiUwe4u1HO+IwQqk77IRDixByEK6SaXiTwo3lqCChD6dntO44OK
X-Gm-Gg: ASbGncuw+mYeeO7cyme4hpasFeEkXoIPWPrAUi2PVfazc5kWJ+lF+tIOpt9oyYqJxhc
	q921cE5U9hlptST2u/u2hEobMr9G2ZGByi6HpOdN0FAPdqiuQI9mUHN48a8yTDms3TLkkwmHBrs
	lnuQXT6ocfu0vzY2O+yifPPHp6jjhWa1I5OS2XtxbAn0uS28rVmgH7yco0VNgrXovcFGHIPmbpt
	kXk21/7K0u05cW5hpOEybMH+t84sVhgVpMGK9ajpF6YK0bzotnmMsI0aeASuNbSORUMmllpxDOK
	/pFeQiSJHD1knMHo2M9bzZXb9Tqe3K7LrKStin8NH7hD8rHZyekJOhBuk3j8ynEel9R07nMit7o
	QjVdiKf1y1cMelGFsQmfhloTfI8gQ0ddUVhk=
X-Google-Smtp-Source: AGHT+IHS9fMjQsyWzq24b1arCff0vE8jvrYpPJ+OyJbOOv1TcUfbFCQB7SQ3yjB3SzQWA6f3P2wNaQ==
X-Received: by 2002:a17:907:3da3:b0:ad4:f517:ca3 with SMTP id a640c23a62f3a-ae05794251bmr1633320766b.20.1750758377877;
        Tue, 24 Jun 2025 02:46:17 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------0njIQvGmM3eD3vN4bb8on5El"
Message-ID: <145f71c2-643e-4839-a2ae-0bc1f049db74@gmail.com>
Date: Tue, 24 Jun 2025 11:46:15 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Oleksii Kurochko 
Subject: Re: [PATCH v2 03/17] xen/riscv: introduce guest domain's VMID
 allocation and manegement
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
In-Reply-To: 

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


On 6/18/25 5:46 PM, Jan Beulich wrote:
> On 10.06.2025 15:05, Oleksii Kurochko wrote:
>> Implementation is based on Arm code with some minor changes:
>>   - Re-define INVALID_VMID.
>>   - Re-define MAX_VMID.
>>   - Add TLB flushing when VMID is re-used.
>>
>> Also, as a part of this path structure p2m_domain is introduced with
>> vmid member inside it. It is necessary for VMID management functions.
>>
>> Add a bitmap-based allocator to manage VMID space, supporting up to 127
>> VMIDs on RV32 and 16,383 on RV64 platforms, in accordance with the
>> architecture's hgatp VMID field (RV32 - 7 bit long, others - 14 bit long).
>>
>> Reserve the highest VMID as INVALID_VMID to ensure it's not reused.
> Why must that VMID not be (re)used? INVALID_VMID can be any value wider
> than the hgatp.VMID field.

Oh, agree it could be just any value wider tan hgatp.VMID filed. I forgot
about that hgatp.VMID is only 14-bit long value. So we have two extra bits
in uint16_t.

>> --- /dev/null
>> +++ b/xen/arch/riscv/p2m.c
>> @@ -0,0 +1,115 @@
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>> +
>> +static spinlock_t vmid_alloc_lock = SPIN_LOCK_UNLOCKED;
>> +
>> +/*
>> + * hgatp's VMID field is 7 or 14 bits. RV64 may support 14-bit VMID.
>> + * Using a bitmap here limits us to 127 (2^7 - 1) or 16383 (2^14 - 1)
>> + * concurrent domains.
> Which is pretty limiting especially in the RV32 case. Hence why we don't
> assign a permanent ID to VMs on x86, but rather manage IDs per-CPU (note:
> not per-vCPU).

Good point.

I don't believe anyone will use RV32.
For RV64, the available ID space seems sufficiently large.

However, if it turns out that the value isn't large enough even for RV64,
I can rework it to manage IDs per physical CPU.
Wouldn't that approach result in more TLB entries being flushed compared
to per-vCPU allocation, potentially leading to slightly worse performance?

What about then to allocate VMID per-domain?

>> The bitmap space will be allocated dynamically
>> + * based on whether 7 or 14 bit VMIDs are supported.
>> + */
>> +static unsigned long *vmid_mask;
>> +static unsigned long *vmid_flushing_needed;
>> +
>> +/*
>> + * -2 here because:
>> + *    - -1 is needed to get the maximal possible VMID
> I don't follow this part.

Probably, I'm missing something.

hgat.vmid is 7 bit long. BIT(7,U) = 1 << 7 = 128 which is bigger
then 7 bit can cover (0b1000_0000 and 0x111_1111). Thereby the MAX_VMID is:
  BIT(7, U) - 1 (in case of RV32).

>> + */
>> +#ifdef CONFIG_RISCV_32
>> +#define MAX_VMID (BIT(7, U) - 2)
>> +#else
> Better "#elif defined(CONFIG_RISCV_64)"?

First, I read the spec as for other bitness except 32 it will be 14 bit long, but I re-read it and
it is true only for HSXLEN=64, so RV128 will/can have different amount of bit for VMID. I will
update to "#elif defined(CONFIG_RISCV_64)" + #error "Define MAX_VMID" if bitness isn't 32 or 64.


>> +{
>> +    /*
>> +     * Allocate space for vmid_mask and vmid_flushing_needed
>> +     * based on INVALID_VMID as it is the max possible VMID which just
>> +     * was reserved to be INVALID_VMID.
>> +     */
>> +    vmid_mask = xvzalloc_array(unsigned long, BITS_TO_LONGS(INVALID_VMID));
>> +    vmid_flushing_needed =
>> +        xvzalloc_array(unsigned long, BITS_TO_LONGS(INVALID_VMID));
> These both want to use MAX_VMID + 1; there's no logical connection here to
> INVALID_VMID.
>
> Furthermore don't you first need to determine how many bits hgatp.VMID actually
> implements? The 7 and 14 bits respectively are maximum values only, after all.

I missed that it depends on VMIDLEN:
```
The number of VMID bits is UNSPECIFIED and may be zero. The number of implemented VMID bits,
termed VMIDLEN, may be determined by writing one to every bit position in the VMID field, then
reading back the value in hgatp to see which bit positions in the VMID field hold a one. The least-
significant bits of VMID are implemented first: that is, if VMIDLEN > 0, VMID[VMIDLEN-1:0] is
writable. The maximal value of VMIDLEN, termed VMIDMAX, is 7 for Sv32x4 or 14 for Sv39x4,
Sv48x4, and Sv57x4.
```
So yes, I have to determine first how many bits are supported by an implementation.

> VMIDLEN being permitted to be 0, how would you run more than one VM (e.g. Dom0)
> on such a system?

Hmm, good question.

Then it will be needed to flush TLB on each VM switch by using
sbi_remote_hfence_gvma().

>> +    if ( !vmid_mask || !vmid_flushing_needed )
>> +        panic("Could not allocate VMID bitmap space or VMID flushing map\n");
>> +
>> +    set_bit(INVALID_VMID, vmid_mask);
> If (see above) this is really needed, __set_bit() please.
>
>> +}
>> +
>> +int p2m_alloc_vmid(struct domain *d)
> Looks like this can be static? (p2m_free_vmid() has no caller at all, so
> it's not clear what use it is going to be.)

It really can be static. And p2m_free_vmid() too, but as there is no caller
of p2m_free_vmid() probably it makes sense to do in the following way:
   /* Uncomment static when p2m_free_vmid() will be called. */
   /* static */ void p2m_free_vmid(struct domain *d)
Or just drop for the moment when it will be really needed.



>> +        goto out;
>> +    }
>> +
>> +    set_bit(nr, vmid_mask);
> Since you do this under lock, even here __set_bit() ought to be sufficient.
>
>> +    if ( test_bit(p2m->vmid, vmid_flushing_needed) )
>> +    {
>> +        clear_bit(p2m->vmid, vmid_flushing_needed);
> And __clear_bit() here, or yet better use __test_and_clear_bit() in the if().
>
>> +        sbi_remote_hfence_gvma_vmid(d->dirty_cpumask, 0, 0, p2m->vmid);
> You're creating d; it cannot possibly have run on any CPU yet. IOW
> d->dirty_cpumask will be reliably empty here. I think it would be hard to
> avoid issuing the flush to all CPUs here in this scheme.

I didn't double check, but I was sure that in case d->dirty_cpumask is empty then
rfence for all CPUs will be send. But I was wrong about that.

What about just update a code of sbi_rfence_v02()?

At the moment, we have check if a pointer to cpu_mask isn't NULL and if NULL then
do rfence for all CPUs:

static int cf_check sbi_rfence_v02(unsigned long fid,
                                    const cpumask_t *cpu_mask,
                                    vaddr_t start, size_t size,
                                    unsigned long arg4, unsigned long arg5)
{
    ...

     /*
      * hart_mask_base can be set to -1 to indicate that hart_mask can be
      * ignored and all available harts must be considered.
      */
     if ( !cpu_mask )
         return sbi_rfence_v02_real(fid, 0UL, -1UL, start, size, arg4);
    ...

What about  just to add here:
     if ( !cpu_mask || cpumask_empty(cpu_mask) )

Does it make sense?

>> +    spin_unlock(&vmid_alloc_lock);
>> +    return rc;
>> +}
>> +
>> +void p2m_free_vmid(struct domain *d)
>> +{
>> +    struct p2m_domain *p2m = p2m_get_hostp2m(d);
>> +
>> +    spin_lock(&vmid_alloc_lock);
>> +
>> +    if ( p2m->vmid != INVALID_VMID )
>> +    {
>> +        clear_bit(p2m->vmid, vmid_mask);
>> +        set_bit(p2m->vmid, vmid_flushing_needed);
> Does this scheme really avoid any flushes (except near when the system is
> about to go down)?
>
> As to choice of functions - see above.

I think yes, so my idea was that if vmid isn't freed then we have enough free VMID
and in this case flush isn't needed as each vcpu has unique not-used yet VMID,
and if there is no free VMID then and error will return in p2m_alloc_vmid():
     if ( nr == MAX_VMID )
     {
         rc = -EBUSY;
         printk(XENLOG_ERR "p2m.c: dom%pd: VMID pool exhausted\n", d->domain_id);
         goto out;
     }

On other hand, if VMID was freed and then re-used in p2m_alloc_vmid(), then it means
that vmid_flushing_needed will have VMID bit set, what means that a TLB flush is needed.

>
>> +    }
>> +
>> +    spin_unlock(&vmid_alloc_lock);
>> +}
>> +
>> +int p2m_init(struct domain *d)
>> +{
>> +    struct p2m_domain *p2m = p2m_get_hostp2m(d);
>> +    int rc;
>> +
>> +    p2m->vmid = INVALID_VMID;
> Given the absence of callers of p2m_free_vmid() it's also not clear what use
> this is.

Just mark that VMID for this domain wasn't yet allocated.

Anyway, it will be called from arch_domain_create() by arch_domain_destroy() so if the some
error happens during arch_domain_create() and p2m->vmid wasn't allocated yet (so is equal to
INVALID_VMID), it means that there is no sense to update vmid_mask or vmid_flushing_needed.

~ Oleksii


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



  
    
  
  
    

    
    
    
    
    On 6/18/25 5:46 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 10.06.2025 15:05, Oleksii Kurochko wrote:

    
      
    
        
    Implementation is based on Arm code with some minor changes:
 - Re-define INVALID_VMID.
 - Re-define MAX_VMID.
 - Add TLB flushing when VMID is re-used.

Also, as a part of this path structure p2m_domain is introduced with
vmid member inside it. It is necessary for VMID management functions.

Add a bitmap-based allocator to manage VMID space, supporting up to 127
VMIDs on RV32 and 16,383 on RV64 platforms, in accordance with the
architecture's hgatp VMID field (RV32 - 7 bit long, others - 14 bit long).

Reserve the highest VMID as INVALID_VMID to ensure it's not reused.

    
      
    
      
    Why must that VMID not be (re)used? INVALID_VMID can be any value wider
than the hgatp.VMID field.
    
    
    
    
    Oh, agree it could be just any value wider tan hgatp.VMID filed. I forgot
about that hgatp.VMID is only 14-bit long value. So we have two extra bits
in uint16_t.

    
    
    
      
    
        
    --- /dev/null
+++ b/xen/arch/riscv/p2m.c
@@ -0,0 +1,115 @@
+#include <xen/bitops.h>
+#include <xen/lib.h>
+#include <xen/sched.h>
+#include <xen/spinlock.h>
+#include <xen/xvmalloc.h>
+
+#include <asm/p2m.h>
+#include <asm/sbi.h>
+
+static spinlock_t vmid_alloc_lock = SPIN_LOCK_UNLOCKED;
+
+/*
+ * hgatp's VMID field is 7 or 14 bits. RV64 may support 14-bit VMID.
+ * Using a bitmap here limits us to 127 (2^7 - 1) or 16383 (2^14 - 1)
+ * concurrent domains.

    
      
    
      
    Which is pretty limiting especially in the RV32 case. Hence why we don't
assign a permanent ID to VMs on x86, but rather manage IDs per-CPU (note:
not per-vCPU).
    
    
    
    
    Good point.
    
    
    I don't believe anyone will use RV32.
For RV64, the available ID space seems sufficiently large.

However, if it turns out that the value isn't large enough even for RV64,
I can rework it to manage IDs per physical CPU.
Wouldn't that approach result in more TLB entries being flushed compared
to per-vCPU allocation, potentially leading to slightly worse performance?

What about then to allocate VMID per-domain?

    
    
    
      
    
        
    The bitmap space will be allocated dynamically
+ * based on whether 7 or 14 bit VMIDs are supported.
+ */
+static unsigned long *vmid_mask;
+static unsigned long *vmid_flushing_needed;
+
+/*
+ * -2 here because:
+ *    - -1 is needed to get the maximal possible VMID

    
      
    
      
    I don't follow this part.

    
    
    
    
    Probably, I'm missing something.

hgat.vmid is 7 bit long. BIT(7,U) = 1 << 7 = 128 which is bigger
then 7 bit can cover (0b1000_0000 and 0x111_1111). Thereby the MAX_VMID is:
 BIT(7, U) - 1 (in case of RV32).


    
    
    
      
    
        
    + */
+#ifdef CONFIG_RISCV_32
+#define MAX_VMID (BIT(7, U) - 2)
+#else

    
      
    
      
    Better "#elif defined(CONFIG_RISCV_64)"?
    
    
    
    
    First, I read the spec as for other bitness except 32 it will be 14 bit long, but I re-read it and
it is true only for HSXLEN=64, so RV128 will/can have different amount of bit for VMID. I will
update to "#elif defined(CONFIG_RISCV_64)" + #error "Define MAX_VMID" if bitness isn't 32 or 64.



    
    
    
      
    
        
    +{
+    /*
+     * Allocate space for vmid_mask and vmid_flushing_needed
+     * based on INVALID_VMID as it is the max possible VMID which just
+     * was reserved to be INVALID_VMID.
+     */
+    vmid_mask = xvzalloc_array(unsigned long, BITS_TO_LONGS(INVALID_VMID));
+    vmid_flushing_needed =
+        xvzalloc_array(unsigned long, BITS_TO_LONGS(INVALID_VMID));

    
      
    
      
    These both want to use MAX_VMID + 1; there's no logical connection here to
INVALID_VMID.

Furthermore don't you first need to determine how many bits hgatp.VMID actually
implements? The 7 and 14 bits respectively are maximum values only, after all.
    
    
    
    
    I missed that it depends on VMIDLEN:
```
The number of VMID bits is UNSPECIFIED and may be zero. The number of implemented VMID bits,
termed VMIDLEN, may be determined by writing one to every bit position in the VMID field, then
reading back the value in hgatp to see which bit positions in the VMID field hold a one. The least-
significant bits of VMID are implemented first: that is, if VMIDLEN > 0, VMID[VMIDLEN-1:0] is
writable. The maximal value of VMIDLEN, termed VMIDMAX, is 7 for Sv32x4 or 14 for Sv39x4,
Sv48x4, and Sv57x4.
```
So yes, I have to determine first how many bits are supported by an implementation.


    
    
    
      
    VMIDLEN being permitted to be 0, how would you run more than one VM (e.g. Dom0)
on such a system?
    
    
    
    
    Hmm, good question.

Then it will be needed to flush TLB on each VM switch by using
sbi_remote_hfence_gvma().


    
    
    
      
    
        
    +    if ( !vmid_mask || !vmid_flushing_needed )
+        panic("Could not allocate VMID bitmap space or VMID flushing map\n");
+
+    set_bit(INVALID_VMID, vmid_mask);

    
      
    
      
    If (see above) this is really needed, __set_bit() please.


    
      
    
        
    +}
+
+int p2m_alloc_vmid(struct domain *d)

    
      
    
      
    Looks like this can be static? (p2m_free_vmid() has no caller at all, so
it's not clear what use it is going to be.)
    
    
    
    
    It really can be static. And p2m_free_vmid() too, but as there is no caller
of p2m_free_vmid() probably it makes sense to do in the following way:
  /* Uncomment static when p2m_free_vmid() will be called. */
  /* static */ void p2m_free_vmid(struct domain *d)
Or just drop for the moment when it will be really needed.




    
    
    
      
    
        
    +        goto out;
+    }
+
+    set_bit(nr, vmid_mask);

    
      
    
      
    Since you do this under lock, even here __set_bit() ought to be sufficient.


    
      
    
        
    +    if ( test_bit(p2m->vmid, vmid_flushing_needed) )
+    {
+        clear_bit(p2m->vmid, vmid_flushing_needed);

    
      
    
      
    And __clear_bit() here, or yet better use __test_and_clear_bit() in the if().


    
      
    
        
    +        sbi_remote_hfence_gvma_vmid(d->dirty_cpumask, 0, 0, p2m->vmid);

    
      
    
      
    You're creating d; it cannot possibly have run on any CPU yet. IOW
d->dirty_cpumask will be reliably empty here. I think it would be hard to
avoid issuing the flush to all CPUs here in this scheme.
    
    
    
    
    I didn't double check, but I was sure that in case d->dirty_cpumask is empty then
rfence for all CPUs will be send. But I was wrong about that.

What about just update a code of sbi_rfence_v02()?

At the moment, we have check if a pointer to cpu_mask isn't NULL and if NULL then
do rfence for all CPUs:

static int cf_check sbi_rfence_v02(unsigned long fid,
                                   const cpumask_t *cpu_mask,
                                   vaddr_t start, size_t size,
                                   unsigned long arg4, unsigned long arg5)
{
   ...

    /*
     * hart_mask_base can be set to -1 to indicate that hart_mask can be
     * ignored and all available harts must be considered.
     */
    if ( !cpu_mask )
        return sbi_rfence_v02_real(fid, 0UL, -1UL, start, size, arg4);
   ...

What about  just to add here:
    if ( !cpu_mask || cpumask_empty(cpu_mask) )

Does it make sense?


    
    
    
      
    
        
    +    spin_unlock(&vmid_alloc_lock);
+    return rc;
+}
+
+void p2m_free_vmid(struct domain *d)
+{
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+    spin_lock(&vmid_alloc_lock);
+
+    if ( p2m->vmid != INVALID_VMID )
+    {
+        clear_bit(p2m->vmid, vmid_mask);
+        set_bit(p2m->vmid, vmid_flushing_needed);

    
      
    
      
    Does this scheme really avoid any flushes (except near when the system is
about to go down)?

As to choice of functions - see above.
    
    
    
    
    I think yes, so my idea was that if vmid isn't freed then we have enough free VMID
and in this case flush isn't needed as each vcpu has unique not-used yet VMID,
and if there is no free VMID then and error will return in p2m_alloc_vmid():
    if ( nr == MAX_VMID )
    {
        rc = -EBUSY;
        printk(XENLOG_ERR "p2m.c: dom%pd: VMID pool exhausted\n", d->domain_id);
        goto out;
    }

On other hand, if VMID was freed and then re-used in p2m_alloc_vmid(), then it means
that vmid_flushing_needed will have VMID bit set, what means that a TLB flush is needed.


    
    
    
      
    

    
      
    
        
    +    }
+
+    spin_unlock(&vmid_alloc_lock);
+}
+
+int p2m_init(struct domain *d)
+{
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    int rc;
+
+    p2m->vmid = INVALID_VMID;

    
      
    
      
    Given the absence of callers of p2m_free_vmid() it's also not clear what use
this is.
    
    
    
    
    Just mark that VMID for this domain wasn't yet allocated.

Anyway, it will be called from arch_domain_create() by arch_domain_destroy() so if the some
error happens during arch_domain_create() and p2m->vmid wasn't allocated yet (so is equal to
INVALID_VMID), it means that there is no sense to update vmid_mask or vmid_flushing_needed.

~ Oleksii
    
    
    
  


--------------0njIQvGmM3eD3vN4bb8on5El--


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 09:49:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 09:49:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023512.1399494 (Exim 4.92)
	(envelope-from )
	id 1uU0Ho-0006xm-9a; Tue, 24 Jun 2025 09:49:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023512.1399494; Tue, 24 Jun 2025 09: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 1uU0Ho-0006xf-62; Tue, 24 Jun 2025 09:49:52 +0000
Received: by outflank-mailman (input) for mailman id 1023512;
 Tue, 24 Jun 2025 09:49: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 1uU0Hn-0006xZ-Ao
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 09:49:51 +0000
Received: from NAM02-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam02on20620.outbound.protection.outlook.com
 [2a01:111:f403:2405::620])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 90ae5f8e-50e0-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 11:49:49 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by IA0PPF6483BC7EA.namprd12.prod.outlook.com
 (2603:10b6:20f:fc04::bcf) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.25; Tue, 24 Jun
 2025 09:49: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%4]) with mapi id 15.20.8835.027; Tue, 24 Jun 2025
 09:49: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: 90ae5f8e-50e0-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=yb3+4o5A6EqwTJ9o0JnzvPNtHVFbaRhkpCiyH9PYui/2pNhGFPtL7dGHHaqcE0NKkU8RDhSeUpl+3WBEalfe05e1SuOzt88lt7A+8VA77SynIGZaAozjyJNEKfO6ule5SYWu/Fo2oX/QnprzKcBA/YgDyiC+XRxn5SsamBDErSvVlFxWdtG1Xt+tV8QbYoplGN5SFDvjPS/6qiPoTObUH90Y38JRZPBq1LRODxOJs1GPtjKQMWuNTuuGSmRnlwiMgHWOfNwCS79299/Dde+JseQin9/rvZ5cxbUnhXGZlG7dGFNLZ1dCKKqx5om2dVavOjH/Dh8KixhP6GUOJzH3cQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=BFy317j9jXVo9OnIQPKhKoki6BfP54zlWeEffymTP0g=;
 b=KqZJCo+2ojD7VcwDncj0tH9ktthakcv4NYuMVDxZVyIsLAhGUOM9VdcHFMkL+7fmQNJTskZqljW0FB0xLYddOYyW8h15jeBPjPHbIrX8u4Cxz0HttolPkCxN5i5ukZBFSh2oG8iD2EOgiJubEfNQhS+ebjl/FbkqT/myt2O97oacxWS7T5Ap5TVNVGaMaFuvh3/75rzV5u0yBgzCm+ypXFvwLACccP/sQEBQ9W4qJZhvhuIHylSIZ6gm2QfZuoR4Pn2ON4n8z0Nr3ClhNSVtlNHJLBgVeGFEy9gsF3SC1+UMXwtjZpgIdCgrxjh8/fRNrtldgFOBPXqErhXu6a0Nlw==
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=BFy317j9jXVo9OnIQPKhKoki6BfP54zlWeEffymTP0g=;
 b=VwHpJyAMOy9awOBks0T2qFd46D8c+K/cJ3EWlF80MCoadkCT8voyZ4iZGvl9UXgfrJwv3sEqT8HAx45DNCIzKaE/47Zy9q6BJLq5wnNNa4zQj9T+DUaqeN66dbjNP+XJAama0r4+fajcm7WZVdfILKoDsVSAm6hEq27dDCcokkM=
From: "Chen, Jiqian" 
To: Jan Beulich 
CC: "Huang, Ray" , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, "xen-devel@lists.xenproject.org"
	, "Chen, Jiqian" 
Subject: Re: [PATCH v6 7/8] vpci/msi: Free MSI resources when init_msi() fails
Thread-Topic: [PATCH v6 7/8] vpci/msi: Free MSI resources when init_msi()
 fails
Thread-Index: AQHb23yeMT8YFCMR3kaLDqQP1+DTK7QJCD4AgAme+gA=
Date: Tue, 24 Jun 2025 09:49:45 +0000
Message-ID:
 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-8-Jiqian.Chen@amd.com>
 <773c448a-d814-458f-ad83-e9740e724408@suse.com>
In-Reply-To: <773c448a-d814-458f-ad83-e9740e724408@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.8835.025)
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_|IA0PPF6483BC7EA:EE_
x-ms-office365-filtering-correlation-id: 18c4064e-c234-49b1-0eff-08ddb304734f
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?OTJXOE1YckptMmtmMHNmUWcvV0VTbkZZL2NOUVlIejVpblpIOExtV0hPYmxj?=
 =?utf-8?B?TUlMa2svQU9yazZ0NnNqSUtsU3JNNUxQdzBjQ1JhNVhZdjFqY1IvR2ZrKzE4?=
 =?utf-8?B?cjNyVVhjV1JCc0IvMEw5VEhVT051VmF2SDc4ai90eEpnUU9oWm5zaFFacE5v?=
 =?utf-8?B?dGFoaHNEVTlDeE1XeHJkVHBQekJyT1Y4ZlIxbE40Mlh5b0NCTVV5Y0pqY1R4?=
 =?utf-8?B?Zmw5UFJEbmh2ZzdEamxGNEJCTUFLOFFrbFFDSlc4OGMraDN6U04yaHVObDF0?=
 =?utf-8?B?WDI2M1FvU2pWMUh1R0tpRnlZcTY2WUZZMGIwdGJicy81eHJLUXNDV085U1VS?=
 =?utf-8?B?eDk3UENHWGZ1WVJZN3JqV1dDamZqS2tUaHR0NEkyNS9IVWxWcEs3NnNsdU9a?=
 =?utf-8?B?ZytDK3pVaDNFTHhJd2hFZXh4MjRQd1VWaGdDOTh1dUFndHFmTm9EeEtDOExU?=
 =?utf-8?B?VkJCS1hiRzZnSi8zWE5aL1ZTUzZxc2RkRXpDcUNMYnh2QVBqWVVWREp6MDlu?=
 =?utf-8?B?TzBtNEVMaXZkaWJnQUo0REFFRlRkSkpyNG9aWXkyM1VrWGcyWXZobjY2Z1Fn?=
 =?utf-8?B?b2gwZkZIWnBOZU9tQ2R5czdFaFBHR21pT1NtZzE1MTRrNDVwc0pOSnZ5b3lD?=
 =?utf-8?B?YitKR2Q3a3VjQ3hLMU1JUzgxeUFCZWkwdXFOWlBmVFc5SUd5WDgwVnM0NWdj?=
 =?utf-8?B?YUpOZEF0bWIxb1dXTHI3V3F6Y0VZcWJkd2Zrd0s3cG5xQllWSUJGUUVUd3dK?=
 =?utf-8?B?RDlLVzl5amFvcEVvSVc2RGxxakRzRG1kbnpZeXB3N2N2MFZTMmQrVTk5OEY5?=
 =?utf-8?B?UXVNeGd2K21CQkpySERRdW15K3Y1QU5jMk45QXM2ZVgza1pkL3RoTnYwRG1V?=
 =?utf-8?B?NXhYRVR1b2M3Z3ZpZlR5OE1ZSnJiWWIvN2RPbjg0MC90TzhrbE1WTUJjNjJt?=
 =?utf-8?B?cXlZSHYxMGxmUUpCcVZyZUkwMEwrbDdzT0cvTlZXTXNYN09tK3o0VWZHVCtn?=
 =?utf-8?B?UWpXV1ZtY1hyOU9QNS85ZFZIeWlsVWN6SXhoNlRadVNudmJZVCtuU05IUjVG?=
 =?utf-8?B?Uks1czA4ZGJHWnJHN0o1MVB4ajhqdnlxOUh6TGdWTFpTN0tRdlFTOFdvRlUv?=
 =?utf-8?B?Ni9Pc1p3RnpIMDJNd0F0Vk5DZTN3MmMrMnRSVGQwaEE5NHNUM0Q5d0NxQzBr?=
 =?utf-8?B?akJmdkxYamU0dS8yNkpiRm5OZ0VBKzZPc01MbmVhRHBMUkxWSkdUbXVMSUxm?=
 =?utf-8?B?ZG9BSzMyYjV1SmoydWI0ODEvbTVMUHpHdUE4amZBM0pFZlVMV0poeURpZnJB?=
 =?utf-8?B?MlVKdzgzK2NDVnpZQlFpV3ZaQVlxeEdDQ2tYTHFpNnVRb245akZmUUtoZkZI?=
 =?utf-8?B?UTV4YTU0YUhKMTAxTDRwUHlid1VlZ001d3RIWjFBZkc3NXpqOGExRVhNV1N5?=
 =?utf-8?B?UmpPR3dqZTNFSVdzSEhrTE5rLzU5WWlMUkkrZXlYSnJCTVlySlNQS2EwZjFj?=
 =?utf-8?B?MDdoSldzMDErNnpjWFAxTWYxNkQ4d1BNLzJwR1FQRUdyM0t2UlZmd1RoRXN5?=
 =?utf-8?B?dStmUTFiWVFVUm1WL2JZaW9pd3BXMCswTkhnM2s3dlFYV09Va0svZkVZZC9s?=
 =?utf-8?B?WmN4TVc0STQ2T1FTdXg5c083V0ZUcjIxNkRTQ1h6ZVlnUU9MOTJnMkxCTXdX?=
 =?utf-8?B?N3piUk4zWWJwa1BhVFpGUG13Ujljc0hGS0tIeEJoRDR1RTN5MlJ3c3pmcHFr?=
 =?utf-8?B?QVJhTE1hTTJyaDhvYnA5Nkd1RzR2Q2tRMzhDRGVqVzhYbC9WNzBIcmhwYUhs?=
 =?utf-8?B?LzFHMFJYaWd1dHppZjVPMFhJc25IankydmVDc21ialZHaGE5bytWNWhIZDdt?=
 =?utf-8?B?aGVGeVF4YzdEYzBBcG5CbWlPTEFaWFVtOWQ4eW5qMzM4SVBGRE5qdm1SeVRp?=
 =?utf-8?B?YjRVd3NBZ2s0b0UwQWZYemMrakFpMEN5UzBFYVlPaU5wSE9jN0ZBakdtZGRN?=
 =?utf-8?Q?9MFEuMg+3+Mzt255Glshv3WlwC4dTk=3D?=
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?RW5BWEFwMnVMcW5IdlUzbitNczJkYk9WaXF1TWIzYTZDT0lRN1dBYU12WWhQ?=
 =?utf-8?B?NVhkK0FWUmFycVcraFJDTUhqVDFQUjdtMFA0Wm1kbVNjdDRERUd2M1pFR1FC?=
 =?utf-8?B?Titpc250eGdoZDB4ZDNjUVBHWS9xNHF2dy9PUnN4S1VzR215U2pzb1RNMHRD?=
 =?utf-8?B?ZWlzUEJXMWdGTXY1cDZ2WHJNRDBtWEFkRldDTVRpZGdUVDlROW9EYlk3dmxx?=
 =?utf-8?B?TURtVTVzbXZPcDBvOUZzU0ZmcXlXQm9nanQ5a1E4MldNTTJSbzZ4TU9CTlll?=
 =?utf-8?B?T3NvRXFsU0lzMVFtcnhrbGN1TjdESFFVR25aZzcrTHEzcnY3d2N4STdIL0hv?=
 =?utf-8?B?L0x0RXJRZ0JPNEFFUytpSzBuUHhjK1JhMEZiVDFBWHFkMGpIVjVLcnFabTRp?=
 =?utf-8?B?ZWlPZHZFRGhoTlQ2bzI2cnU4REJNaU01MWlzSUlaY29EUnYwdDJDT2VDYVFY?=
 =?utf-8?B?cEVkRUJ2VzNpQk00b2l3T0x5M01PN2RoMGtBRkRZcWlrQmhGcUxRMFFRQkFs?=
 =?utf-8?B?bGpaTWgzVUtQQUp2VEFZRmZJSkJIUnFtcXdpYy9JUTU5eURCYWhLaDZYUWNT?=
 =?utf-8?B?eUovZ2JueWZBWUxqa3QxSlBnQ0dub0RhSjI5eFVNR01QOTZPVFJwR0FweGJO?=
 =?utf-8?B?U0pqNUt1UitkcC9hSGdoM2lDWEc5K3dIMWxyNmNsVlo4WW84Q0xWT0NRK3Z2?=
 =?utf-8?B?SjZqTEV6eVpST1dsNG9oaG5UU05RMndiWTNZWngvemtBZTZ6WDNGNEM5OEhx?=
 =?utf-8?B?THRVOGVBaml1VmUvUmNtK0hwUnVwbUtaT3BOQUdRVDllSk5aOFZuWkN6SlQ3?=
 =?utf-8?B?K1hJdnMzd0FVQUhGNzYzNU4wODZaeDk0MThRbEh4Y1Jmc1pScm44ZG92MVA1?=
 =?utf-8?B?eWs0a3FCb0RLcWkzOHpxMDVBWXN5YjUvcWRtRXR1cUFHcmpJeVYwNUJ2aWRu?=
 =?utf-8?B?ekV3UDNVVWk1bHJPWk51Y2hZalZTejA5Qy9PV1I0VWd1RHFuZmNVNHN0RU5C?=
 =?utf-8?B?TFVHTFlnWVhLSng0SDZMWGhVKzB4TXZVeUxvZ1hrWkRWQ2tCYy9ReXNIMC95?=
 =?utf-8?B?ampPRTJtWlN0all5UHM1WVF0SmMwYUVZSTFlRFNtK3AxR2JEU1FhNXZJY1Nx?=
 =?utf-8?B?d1piSVl4V3dMMGVIUDJLN1VkT2JOU25nOElWN204bGtTZVlocUxZMXRPZWR0?=
 =?utf-8?B?aXlWMnR4c0dCaXBpM2JkUWVwL1RMSTh5c1k5a1hWYnBXMzRIT1VtcC9UZ3Jw?=
 =?utf-8?B?Qm1DUEJ6Y2Z2aHRQZGVvYlIzRUlVYWpPbldrSTV4VHFqbTk0c3NKNkNlTThN?=
 =?utf-8?B?UWxvQ0dadUNZanhnOUV3NVZQQW1KSXhwbWQ3K2RuR0FoK240VHV5M3owQmxw?=
 =?utf-8?B?L0swaXlvSndyYkUxRFA4TmtDMVRkeWVKbHc2RUVhTk5lTWtSbXZUSUFCS3Zp?=
 =?utf-8?B?cmMvVFoxay9aaE0ra0kzakFXcnZ3NnpaVXBzdDQ4Ri9Cdk9QNWxUU1A5MTBN?=
 =?utf-8?B?NDYxVzlnQkJBOGR6cHJOMXNWN09KdjJvYTVra3B0clhuTnJ4Z1E0Vyt3dW1s?=
 =?utf-8?B?dDNxdkkzQTJOSXEwcUpPTHdFV25kdE54cTFuYWd5NzRTay8zL1I0YXk0K0o2?=
 =?utf-8?B?VHBjS1BudGZnZ1BUdGNQSXRCZi9nK09MdWsrVzlENVI5OU0xd21zM1lUL3dK?=
 =?utf-8?B?dy9PMWg2Rm9nT1l2N094K2JEakN6RGtBT1lsSm5ST1N2bG9mTGhpNTcvQ1Fk?=
 =?utf-8?B?QVhCQllmK3RRY1djVG81Y0c4SUJXZUlxUzVxRzRsM0lLc1plTHVzM2FtcWZW?=
 =?utf-8?B?Y2FETHJGNXdmaElmZVJ5SFpTZjEvV3phbExiTTBvU2dDMTJBM1lMcGh0VkQx?=
 =?utf-8?B?WVd0alQ0MEM5TkNKOVFTWE8zRWRQQ1BVQkJaRmhPK2VaaHM3UGJVcEJFbDJo?=
 =?utf-8?B?NUk0ZnZrUDdKT0NkUVE4T0IvSE9tbDVCV1ExQzd4c1ViN3VxZXAxcVhxbTdi?=
 =?utf-8?B?QVErYk9rNlgyVWpRY08rZXQvdFJCSXdZekZRdkZUVTBxRTZKTFU5SWNwZTJ5?=
 =?utf-8?B?cGg2ZHZuajM4ckJRQmRNZXZjbWxmMWRreTdjUU9CbUpPUk1LR3k3RHlRNHZx?=
 =?utf-8?Q?isAo=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: 18c4064e-c234-49b1-0eff-08ddb304734f
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2025 09:49:45.2175
 (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: HX/1Q9VsqSFQe8lAYCcU94MiGeL4AVZSvbG4qGQoz9/C2SZix0m7/yIGaXAcAxT9v0dAe2fsQ8UdF5OZYMYbqQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PPF6483BC7EA

T24gMjAyNS82LzE4IDIyOjQ1LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMTIuMDYuMjAyNSAx
MToyOSwgSmlxaWFuIENoZW4gd3JvdGU6DQo+PiAtLS0gYS94ZW4vZHJpdmVycy92cGNpL21zaS5j
DQo+PiArKysgYi94ZW4vZHJpdmVycy92cGNpL21zaS5jDQo+PiBAQCAtMTkzLDYgKzE5MywzMyBA
QCBzdGF0aWMgdm9pZCBjZl9jaGVjayBtYXNrX3dyaXRlKA0KPj4gICAgICBtc2ktPm1hc2sgPSB2
YWw7DQo+PiAgfQ0KPj4gIA0KPj4gK3N0YXRpYyBpbnQgY2ZfY2hlY2sgY2xlYW51cF9tc2koc3Ry
dWN0IHBjaV9kZXYgKnBkZXYpDQo+PiArew0KPj4gKyAgICBpbnQgcmM7DQo+PiArICAgIHVuc2ln
bmVkIGludCBlbmQsIHNpemU7DQo+PiArICAgIHN0cnVjdCB2cGNpICp2cGNpID0gcGRldi0+dnBj
aTsNCj4+ICsgICAgY29uc3QgdW5zaWduZWQgaW50IG1zaV9wb3MgPSBwZGV2LT5tc2lfcG9zOw0K
Pj4gKyAgICBjb25zdCB1bnNpZ25lZCBpbnQgY3RybCA9IG1zaV9jb250cm9sX3JlZyhtc2lfcG9z
KTsNCj4+ICsNCj4+ICsgICAgaWYgKCAhbXNpX3BvcyB8fCAhdnBjaS0+bXNpICkNCj4+ICsgICAg
ICAgIHJldHVybiAwOw0KPj4gKw0KPj4gKyAgICBpZiAoIHZwY2ktPm1zaS0+bWFza2luZyApDQo+
PiArICAgICAgICBlbmQgPSBtc2lfcGVuZGluZ19iaXRzX3JlZyhtc2lfcG9zLCB2cGNpLT5tc2kt
PmFkZHJlc3M2NCk7DQo+PiArICAgIGVsc2UNCj4+ICsgICAgICAgIGVuZCA9IG1zaV9tYXNrX2Jp
dHNfcmVnKG1zaV9wb3MsIHZwY2ktPm1zaS0+YWRkcmVzczY0KSAtIDI7DQo+PiArDQo+PiArICAg
IHNpemUgPSBlbmQgLSBjdHJsOw0KPj4gKw0KPj4gKyAgICByYyA9IHZwY2lfcmVtb3ZlX3JlZ2lz
dGVycyh2cGNpLCBjdHJsLCBzaXplKTsNCj4+ICsgICAgaWYgKCByYyApDQo+PiArICAgICAgICBy
ZXR1cm4gcmM7DQo+IA0KPiBUaGlzIGlzIGEgZGlmZmljdWx0IG9uZTogSXQncyBub3QgYSBnb29k
IGlkZWEgdG8gc2ltcGx5IHJldHVybiBoZXJlLCB5ZXQNCj4gYXQgdGhlIHNhbWUgdGltZSB0aGUg
aGFuZGxpbmcgb2YgdGhlIHJlZ2lzdGVyIHdlJ3JlIHVuYWJsZSB0byByZW1vdmUgbWF5DQo+IHN0
aWxsIHJlcXVpcmUgZS5nLiAuLi4NCj4gDQo+PiArICAgIFhGUkVFKHZwY2ktPm1zaSk7DQo+IA0K
PiAuLi4gdGhpcy4gVGhlcmUgbWF5IHRoZXJlZm9yZSBiZSBtb3JlIHdvcmsgcmVxdWlyZWQsIHN1
Y2ggdGhhdCBpbiB0aGUNCj4gZW5kIHdlJ3JlIGFibGUgdG8gLi4uDQo+IA0KPj4gKyAgICByZXR1
cm4gdnBjaV9hZGRfcmVnaXN0ZXIocGRldi0+dnBjaSwgdnBjaV9od19yZWFkMTYsIE5VTEwsIGN0
cmwsIDIsIE5VTEwpOw0KPiANCj4gLi4uIHRyeSB0aGlzIGF0IGxlYXN0IG9uIGEgYmVzdCBlZmZv
cnQgYmFzaXMuDQo+IA0KPiBNb3JlIGdlbmVyYWxseTogSSBkb24ndCB0aGluayBmYWlsdXJlIGhl
cmUgKG9yIGluIG90aGVyIC5jbGVhbnVwIGhvb2sNCj4gZnVuY3Rpb25zKSBtYXkgZ28gZW50aXJl
bHkgc2lsZW50bHkuDQpEb2VzIGJlbG93IG1lZXQgeW91ciBtb2RpZmljYXRpb24gZXhwZWN0YXRp
b25zPw0KDQogICAgcmMgPSB2cGNpX3JlbW92ZV9yZWdpc3RlcnModnBjaSwgY3RybCwgc2l6ZSk7
DQogICAgaWYgKCByYyApDQogICAgICAgIHByaW50ayhYRU5MT0dfRVJSICIlcGQgJXBwOiByZW1v
dmUgbXNpIGhhbmRsZXJzIGZhaWwgcmM9JWRcbiIsDQogICAgICAgICAgICAgICBwZGV2LT5kb21h
aW4sICZwZGV2LT5zYmRmLCByYyk7DQoNCiAgICBYRlJFRSh2cGNpLT5tc2kpOw0KDQogICAgLyoN
CiAgICAgKiBUaGUgZHJpdmVyIG1heSBub3QgdHJhdmVyc2UgdGhlIGNhcGFiaWxpdHkgbGlzdCBh
bmQgdGhpbmsgZGV2aWNlDQogICAgICogc3VwcG9ydHMgTVNJIGJ5IGRlZmF1bHQuIFNvIGhlcmUg
bGV0IHRoZSBjb250cm9sIHJlZ2lzdGVyIG9mIE1TSQ0KICAgICAqIGJlIFJlYWQtT25seSBpcyB0
byBlbnN1cmUgTVNJIGRpc2FibGVkLg0KICAgICAqLw0KICAgIHJjID0gdnBjaV9hZGRfcmVnaXN0
ZXIodnBjaSwgdnBjaV9od19yZWFkMTYsIE5VTEwsIGN0cmwsIDIsIE5VTEwpOw0KICAgIGlmICgg
cmMgKQ0KICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAiJXBkICVwcDogYWRkIGR1bW15IG1zaSBj
dHJsIGhhbmRsZXIgZmFpbCByYz0lZFxuIiwNCiAgICAgICAgICAgICAgIHBkZXYtPmRvbWFpbiwg
JnBkZXYtPnNiZGYsIHJjKTsNCg0KICAgIHJldHVybiByYzsNCg0KPiANCj4gSmFuDQoNCi0tIA0K
QmVzdCByZWdhcmRzLA0KSmlxaWFuIENoZW4uDQo=


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 09:58:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 09:58:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023519.1399504 (Exim 4.92)
	(envelope-from )
	id 1uU0QA-0000UD-24; Tue, 24 Jun 2025 09:58:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023519.1399504; Tue, 24 Jun 2025 09: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 1uU0Q9-0000U6-VP; Tue, 24 Jun 2025 09:58:29 +0000
Received: by outflank-mailman (input) for mailman id 1023519;
 Tue, 24 Jun 2025 09:58: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 1uU0Q8-0000Ty-JJ
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 09:58:28 +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 c5abbfc5-50e1-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 11:58:26 +0200 (CEST)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3a588da60dfso3072683f8f.1
 for ; Tue, 24 Jun 2025 02:58:26 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d860aa41sm105970925ad.106.2025.06.24.02.58.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 02:58:25 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c5abbfc5-50e1-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750759106; x=1751363906; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=P0Z4tXF+pI0lQ7neKAgB5b8El/84/p5Kvp/v8vWw24U=;
        b=BYXazRE73pxf9v/ZMRiiaVML0ad14Y/jnouD5UVr8rY4tfkki+0ZeD6BbrPiyGqvWX
         QkFcQtsnZxJqpEb0KvB4B022lmepWLOqH5wrNYppJZ0lqS4OSw5QNqR1+NqYFTBIl2/X
         y71r2ZOl0ChkM4yvkCKjWgmuKypAnZO3Cy7oNyYAs/f41fwpD3WDZYPlCVowEzd9hf7z
         KLWvX1FDghxRTLylRo4chx2BvEW8bqVddUrjOWRnXr1VaKVFyQ5cGcwtbN6yI6QDbhor
         LWeQB3nCGJjWn2ePG6etwoWWdK7MBvn/g/LBUkKfTCriJlf99PGvlIp9xtDepyeKlbZA
         QCwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750759106; x=1751363906;
        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=P0Z4tXF+pI0lQ7neKAgB5b8El/84/p5Kvp/v8vWw24U=;
        b=BHhjEh+bPHhEwf2glVsTEXJk9oXA9vwVN4FTYZTH/M0wFlbpyNeRDkgZzUERCwAw1r
         B3MfMbR+Ira22eV0S0C6tCL04pX9mInuVrqzZMuISW7J3bwFsmcW1s9B6vEZKGK3qV5y
         juWWwxn1hDLbx1YoKyOyHJDp8QZofZDnISm0VS9Y8i5NT2r8Y5rkIdv6a2o9Po08jHOA
         IAok+RaPHOjGK9gTLTgRILKzV1qIhhDOlADEzlF9dG8UtnFXcfjvjT975rbLCJzX4GxQ
         YeZMrM+8NdX8YsjsmtYJxEBSZFfynw4wfqU72z+/a5sf5O5WdcFGrKh6L8l33CEeVbaf
         v7HA==
X-Forwarded-Encrypted: i=1; AJvYcCW7mlWT8dNIsSxaMB0e7kkOZLzi3HLdLnfJBxNr5sfIVYOimUYj/x2gJGYCSq3wqa1kCakYgthslVg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyKXX96bS18pdCSxX8+BaJ66RC80+t0bMTVju3LuyKIiiK9NRLN
	RLzqjt5BObMXICDbcDFbZwwFq5DhsrZAWBaUwMZsipgpbe2nBhbnTvExITKnW8/8OQ==
X-Gm-Gg: ASbGncsmzHaQpz6CgLVpARa3gfHCb7/SfrwyDEW3SzgV9MdFupCuTLR2qxGklbzePYm
	TacXwWAJ5QP+29pxOIr8aGVSmrlJ+uhGGL7MT4o22eNTqRbgSMHeuL2xkpoH0yh9huBoWUy+5Zn
	7VaX/LWFcAQhf8A7SIx842+U5jiG1OZ+FMyvCfyCZ91wZ6M/g/SlmY3SXB8G5he8lUnnlSQmmyF
	TCevde65O0dcrzewmgNQzHAG8QrnuEsnG9FKPeUg+m6/Fepm0PO9rod7kGVKHTcW9qQ4ZeMFym1
	Y63+8BuvjPcWe8G3jlkSl2PndlU/7zzweYtGiOu+wqVg9pEXKvTpO0ydriNqJKuc8RkpVLIVUBj
	84MVSSVzridiNM+CDTNyekyT07Xk6WakYGiB9BRsa8M1LJMY=
X-Google-Smtp-Source: AGHT+IGvlxKgm7jPYLqOCXKKRmgk7n2rA2UgnPkH8J6u6epstKKX4KPtBDiDVqyN3L40PLvmJAFfLw==
X-Received: by 2002:a5d:5850:0:b0:3a5:14e1:d9ec with SMTP id ffacd0b85a97d-3a6d12e6386mr12553562f8f.51.1750759105736;
        Tue, 24 Jun 2025 02:58:25 -0700 (PDT)
Message-ID: <5e0c7bc4-13e4-4051-a65c-8ceb5e3b6925@suse.com>
Date: Tue, 24 Jun 2025 11:58:16 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/char: wrap suspend/resume console callbacks with
 CONFIG_SYSTEM_SUSPEND
To: Mykola Kvach 
Cc: Mykola Kvach ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <07f047e4a3640696e46c6890d3826c03d4f28856.1750756537.git.mykola_kvach@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: <07f047e4a3640696e46c6890d3826c03d4f28856.1750756537.git.mykola_kvach@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 24.06.2025 11:31, Mykola Kvach wrote:
> From: Mykola Kvach 
> 
> This patch wraps the suspend/resume console callbacks and related code within
> CONFIG_SYSTEM_SUSPEND blocks. This ensures that these functions and their
> calls are only included in the build when CONFIG_SYSTEM_SUSPEND is enabled.
> 
> This addresses Misra Rule 2.1 violations.
> 
> Suggested-by: Jan Beulich 
> Signed-off-by: Mykola Kvach 

Acked-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 10:08:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 10:08:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023525.1399515 (Exim 4.92)
	(envelope-from )
	id 1uU0a1-0002Tv-12; Tue, 24 Jun 2025 10:08:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023525.1399515; Tue, 24 Jun 2025 10:08:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uU0a0-0002To-SU; Tue, 24 Jun 2025 10:08:40 +0000
Received: by outflank-mailman (input) for mailman id 1023525;
 Tue, 24 Jun 2025 10:08: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 1uU0Zz-0002Ti-6t
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 10:08:39 +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 31b41cb5-50e3-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 12:08:37 +0200 (CEST)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3a57c8e247cso4109190f8f.1
 for ; Tue, 24 Jun 2025 03:08:37 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-749c8872246sm1415719b3a.159.2025.06.24.03.08.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 03:08:36 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 31b41cb5-50e3-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750759716; x=1751364516; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=KuTeWOTob/8p3ejM+znIczIbcgWK9s6JZ1TvFUIjBHs=;
        b=S02HilvNM0n7W5wxYGTpef+3kwZXFdPwGgZ4TqXJ23k7gscToEDDgnBm25nKvvHc0f
         LrRTCvGDzMWdtbBTQQXTJ+cmXLNSl5cYTvEB3BOjROfvZ6N1oVlDbs0LvMhEOenuAcsd
         I9lAdnAC/O5YDiUYQazPv0G4Tp6VVME5IYrmMpNFo58Gf+uGHEw+M9Yd78vCAPEQqKLY
         u55yLrWfeFrVygwe6a6dvOnatxf+N8x+0hcDj6lrhvlB3i8/C9MHr8Af0d5KL9DYsEaM
         tlsIfD2deXQoGnsObWQ3ldKd+IYARNndUDoZVGCyB8F1KbZHG78uIKQytoGKNolXJW21
         i1+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750759716; x=1751364516;
        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=KuTeWOTob/8p3ejM+znIczIbcgWK9s6JZ1TvFUIjBHs=;
        b=TLOcDEUCZ+qBDk33JfEP6HdTxSEiXAI+ArNdi/4kR3bLhRbHbCxtscT2IGY58An8zB
         O7Sfe4CWhUhWxXNM6r5t8Ww45tRnKBTLV9R32M78EPGkQd1bYft8eP9XqqbhazJt4wGD
         OiAR8ZtfFXCSIrQSfLYOLiquzGZKUA2DOjAqwjdQj2anGbINT9gE59mfNtL5Q17Uahuh
         5hceG0Y14muJt3rGjGNGROAenk6MChDv19v5IMRQM4g/vdbXJz1CyH9kKPpGxXSffDJR
         QHtv7DI0FNAPLkgrCOV0SZw4I2MN0VMFBBTNsFUlZdyzxeFvMchux612qbiVd/0/yLsx
         cutQ==
X-Forwarded-Encrypted: i=1; AJvYcCVp0qCS2MbK/LQKok4LQHvO1X9ZR0wHfwn8sffrczBCNbHBMQxStPARroUS4gFZRp21FXpBgRyt1Eg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyf8zhVUd6bfo1lDcRqAzhHfvuiKdbVTrIW5qhJSRfZtDOVTFtS
	sPALVApq+lrdjUhOzqErFtzwENbzJcMkpZXypH/0ZRckacQYkWAK+qNAqOLpLLm4FA==
X-Gm-Gg: ASbGncvRLRbuLrGWry4/LjigD6H7/XnU7jNv7zPapKHGJZXgXMJZL7mICLx/JR/o57t
	QkGUybBYlyJ6dTVGnN3KuvCkYY2U40JEwif7H+aF2PzIY6Bjq/0XcasSqriN5u8P82cRpxKAixn
	eKzH2dftcDCovYkvWtubL7eQELUDEz9XpuizdVfACXbteOx8mGwbQlPn8vKX7U9Q3FrCERtUBbI
	bxPmTiFEat3IzVoxquSmoavMMkfyoTuQ+xvbvJjEAOQaUaBdaFcW/ikE7e/f/3gcqbbLPhuxGlT
	/q8hLoLljSwBy8NL4n/tTR4/grZsGJRyghQjreP0Xoa+8x1IPjtmWA1jjkfs9FCvXPIse4Y5cYj
	Xuz8lVQUejgPNuKzQsmBqxWc008vV6ws/GE/lh2lqDJGPNMQ=
X-Google-Smtp-Source: AGHT+IF3v6jQluVJNX6LxM5IWU2CLfQRdMa1sX3BlbVw+di3trGOf0G9dXZzc43nRRuJFABGakZqwA==
X-Received: by 2002:a05:6000:2d05:b0:3a5:3517:de3e with SMTP id ffacd0b85a97d-3a6d1317833mr10665071f8f.35.1750759716516;
        Tue, 24 Jun 2025 03:08:36 -0700 (PDT)
Message-ID: <9d5d0e44-66c3-4e3f-8704-2c862c5f5aff@suse.com>
Date: Tue, 24 Jun 2025 12:08:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
To: "Chen, Jiqian" ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: "Huang, Ray" ,
 Andrew Cooper ,
 Anthony PERARD ,
 "Orzel, Michal" , Julien Grall ,
 Stefano Stabellini ,
 "xen-devel@lists.xenproject.org" 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-3-Jiqian.Chen@amd.com>
 <516a3adc-320d-46ce-b235-8ef91469abcf@suse.com>
 
 <227df6d3-a2c3-4576-bde9-d8057c378e7a@suse.com>
 
 <5c4b186e-686e-4fc8-bcf1-854bc1f5ec8b@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 24.06.2025 11:29, Chen, Jiqian wrote:
> On 2025/6/24 16:05, Jan Beulich wrote:
>> On 24.06.2025 10:02, Chen, Jiqian wrote:
>>> On 2025/6/20 14:38, Jan Beulich wrote:
>>>> On 19.06.2025 08:39, Chen, Jiqian wrote:
>>>>> On 2025/6/18 22:05, Jan Beulich wrote:
>>>>>> On 12.06.2025 11:29, Jiqian Chen wrote:
>>>>>>> @@ -29,9 +30,22 @@ typedef int vpci_register_init_t(struct pci_dev *dev);
>>>>>>>   */
>>>>>>>  #define VPCI_MAX_VIRT_DEV       (PCI_SLOT(~0) + 1)
>>>>>>>  
>>>>>>> -#define REGISTER_VPCI_INIT(x, p)                \
>>>>>>> -  static vpci_register_init_t *const x##_entry  \
>>>>>>> -               __used_section(".data.vpci." p) = (x)
>>>>>>> +#define REGISTER_VPCI_CAPABILITY(cap, finit, fclean, ext) \
>>>>>>> +    static const vpci_capability_t finit##_t = { \
>>>>>>> +        .id = (cap), \
>>>>>>> +        .init = (finit), \
>>>>>>> +        .cleanup = (fclean), \
>>>>>>> +        .is_ext = (ext), \
>>>>>>> +    }; \
>>>>>>> +    static const vpci_capability_t *const finit##_entry  \
>>>>>>> +        __used_section(".data.rel.ro.vpci") = &finit##_t
>>>>>>
>>>>>> Could you remind me why the extra level of indirection is necessary here?
>>>>>> That is, why can't .data.rel.ro.vpci be an array of vpci_capability_t?
>>>>> You mean I should change to be:
>>>>> #define REGISTER_VPCI_CAPABILITY(cap, finit, fclean, ext) \
>>>>>     static const vpci_capability_t finit##_t \
>>>>>         __used_section(".data.rel.ro.vpci") = { \
>>>>>         .id = (cap), \
>>>>>         .init = (finit), \
>>>>>         .cleanup = (fclean), \
>>>>>         .is_ext = (ext), \
>>>>>     }
>>>>>
>>>>> Right?
>>>>
>>>> Yes, subject to the earlier comments on the identifier choice.
>>> Got it.
>>> One more question, if change to be that, then how should I modify the definition of VPCI_ARRAY?
>>> Is POINTER_ALIGN still right?
>>
>> Yes. The struct doesn't require bigger alignment afaics. (In fact in principle
>> no alignment should need specifying there, except that this would require
>> keeping the section separate in the final image. Which I don't think we want.)
>>
>>> Since I encountered errors that the values of __start_vpci_array are not right when I use them in vpci_init_capabilities().
>>
>> Details please.
> After changing __start_vpci_array to be vpci_capability_t array, codes will be (maybe I modified wrong somewhere):
> 
> diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
> index c51bbb8abb19..9f2f438b4fdd 100644
> --- a/xen/drivers/vpci/vpci.c
> +++ b/xen/drivers/vpci/vpci.c
> @@ -36,8 +36,8 @@ struct vpci_register {
>  };
> 
>  #ifdef __XEN__
> -extern const vpci_capability_t *const __start_vpci_array[];
> -extern const vpci_capability_t *const __end_vpci_array[];
> +extern vpci_capability_t __start_vpci_array[];
> +extern vpci_capability_t __end_vpci_array[];

Just fyi: You lost const here.

> @@ -255,7 +255,7 @@ static int vpci_init_capabilities(struct pci_dev *pdev)
>  {
>      for ( unsigned int i = 0; i < NUM_VPCI_INIT; i++ )
>      {
> -        const vpci_capability_t *capability = __start_vpci_array[i];
> +        const vpci_capability_t *capability = &__start_vpci_array[i];
>          const unsigned int cap = capability->id;
>          const bool is_ext = capability->is_ext;
>          int rc;
> diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
> index f4ec1c25922d..77750dd4131a 100644
> --- a/xen/include/xen/vpci.h
> +++ b/xen/include/xen/vpci.h
> @@ -31,14 +31,13 @@ typedef struct {
>  #define VPCI_MAX_VIRT_DEV       (PCI_SLOT(~0) + 1)
> 
>  #define REGISTER_VPCI_CAPABILITY(cap, finit, fclean, ext) \
> -    static const vpci_capability_t finit##_t = { \
> +    static vpci_capability_t finit##_entry \
> +        __used_section(".data.rel.ro.vpci") = { \
>          .id = (cap), \
>          .init = (finit), \
>          .cleanup = (fclean), \
>          .is_ext = (ext), \
> -    }; \
> -    static const vpci_capability_t *const finit##_entry  \
> -        __used_section(".data.rel.ro.vpci") = &finit##_t
> +    }
> 
>  #define REGISTER_VPCI_CAP(cap, finit, fclean) \
>      REGISTER_VPCI_CAPABILITY(cap, finit, fclean, false)
> 
> I print the value of NUM_VPCI_INIT, it is a strange number (6148914691236517209).

What are the addresses of the two symbols __start_vpci_array and __end_vpci_array?
At the first glance the changes above are what I would have expected.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 10:11:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 10:11:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023536.1399523 (Exim 4.92)
	(envelope-from )
	id 1uU0cd-0004Jy-Eo; Tue, 24 Jun 2025 10:11:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023536.1399523; Tue, 24 Jun 2025 10: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 1uU0cd-0004Jr-Bm; Tue, 24 Jun 2025 10:11:23 +0000
Received: by outflank-mailman (input) for mailman id 1023536;
 Tue, 24 Jun 2025 10: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 1uU0cb-0004Jl-Nw
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 10:11:22 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20603.outbound.protection.outlook.com
 [2a01:111:f403:2414::603])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 91ec8a8e-50e3-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 12:11:18 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by CY8PR12MB7731.namprd12.prod.outlook.com (2603:10b6:930:86::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.25; Tue, 24 Jun
 2025 10:11:14 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8857.026; Tue, 24 Jun 2025
 10:11: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: 91ec8a8e-50e3-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ZM/yqeYX2S974vv4kSW193hPJnCJBInTV2+KeV5YEQRf5fF0e7tmDpsxw+8+fn9KznjZktdEAdk0l1zihU3Vt9a4CLL9jMJNBNWh/pV6d9T8oxAL4WDkBX6+Mt1OUU/6HpekUUej1cnpOD3mL0gaJJiQM2Q6r9pLK1UrUkl2+osQ7rQdIZEKSD+rCJs3pVVR2YUKgciRFI74O1jmBtzNnofbkOuUKOSGSO7cTtVp0435LxSvc5PFbccjHQFi3U0VfF035CLE2Nq1Xtbk//35oDnvuHvdatC3HYgv3hr+0PC05jK0G3CDF7XbUJKpksW9t/kxCuQE/doF1MuTtrsIpQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=I5K5MpxaxEOgN30+0HCW00YKn24ISJ2DThadpFnV008=;
 b=PMG+deCxJYAlQx5znr3KsHnhx0x4iyVhPfzJ1NskWcfx1UsTrDJN49LZpt2CcuOsw7cVTBUAaMcE72IK1DliDWxAdYbKN0nuocB63FjCH7H69xgdovtAHL89iXSvhL2DZbpS/60I+rJG5WbuT459JLg3IaeGMjAcG4efiXVZ1bulvi2l8FbIv+ESyHuKUZ1LkOM3vh1lhc4BqKppxYeTKKHhtEW7SfKqDH/0553taDPy9xOXPSyAIVvqS6RqjpX9Q57EfSQRoMRgzWbgkLN7dsm1fifIxIjkLaaYHRUm7LB7wvTALu4+BUbH0YtRlm/RR2p0uUZTWd0aHA7m7RKkdg==
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=I5K5MpxaxEOgN30+0HCW00YKn24ISJ2DThadpFnV008=;
 b=B4t+ZUrTX/OhxzmFetRgw35OnU273e+PNd+Rs4T7SoFsOMku5LoPyF0t3RM3WPWI8ent9oVyJNfuRc8Ye0KDJS2ocer4zqmAUzdmdfwIkhuJa768GSsQFeo1yg5ObWPR9EOMU0FLJAPkCl75jQ6FwhfvLBhM4zyZ5KBLfzY6GBs=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <8c35481f-6a2b-4579-9b34-c912cf3bbd14@amd.com>
Date: Tue, 24 Jun 2025 12:11:10 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 03/16] arm/vpl011: use vuart_ prefix in vpl011 public
 calls
To: dmkhn@proton.me, xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com,
 julien@xen.org, oleksii.kurochko@gmail.com, roger.pau@citrix.com,
 sstabellini@kernel.org, dmukhin@ford.com
References: <20250624035443.344099-1-dmukhin@ford.com>
 <20250624035443.344099-4-dmukhin@ford.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250624035443.344099-4-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR3P281CA0198.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:a5::20) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|CY8PR12MB7731:EE_
X-MS-Office365-Filtering-Correlation-Id: 56f72275-32ab-4df6-9239-08ddb30773c6
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|366016|7416014|1800799024|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?L3pTTFRGejdqVDFYd0Z2MVJOcnBiK3Buc3ZmcEgrTTNuNGZmcTVKZE9LcHhl?=
 =?utf-8?B?TnNocCt0T2ZvY0xTcXpZaHRwUEphUHU5UHhXdjY3OWZGc0RyRmZIVlUxRTBG?=
 =?utf-8?B?akZXRG8weHRXTlZXQ1k4aHhMeWV5YWpieWNWY2VqMFhBNDVIaGFQRDRoRkEw?=
 =?utf-8?B?MGdBY2hZNGlaNllCQkZReGtsYnZINVRxamtZRTl2UXhOT1FOWUhIM3hBa3J4?=
 =?utf-8?B?Y3lZWnZHYkpwM2NqNHk4QWdHdHlnWVZnYUJFVzhqRXJFdG9XRE8rOU9sb0dv?=
 =?utf-8?B?empUQXRIdWl3SGJuSHZoOVJEQkRyY2NhQnRrWU1FekJieWxHeHRxeGhVd3pG?=
 =?utf-8?B?N2Q4MmlzZUpZbk53M2JwcVJPWjJwbENpMFk5aTQvMmc0NWFRUVdRV240clhs?=
 =?utf-8?B?MmQvaFRXeXJOZzc1Ti9hY3NYMTM0bUtYeGs3RG4rY3M5ZmdncXdGd0ZEVkhq?=
 =?utf-8?B?ZE1QczJSN2t3NC8xTzE2SzJxcGVOVWluUldOWTBsaExJTW40bllMSzg2Smoz?=
 =?utf-8?B?MExwQVIwUlk3K0Qwd25kUGw1dTJzTWkwRFlpMWg3OEhiaUUxTS80ZU5wM3dx?=
 =?utf-8?B?N1paQ0FoY2JBOFVINDFGVW96STlmcGxqazVwRFlBdTNpZjZFWWpyb0xveDNC?=
 =?utf-8?B?aHBaZDFwcXN4ekg0b3Y1NUhyZnZTa0tzcnJrWStGSHhZaTBScldJMG9kdmR3?=
 =?utf-8?B?dDcxMnpzSnZHemc3Q3hZRXVrczBzNHFwZmI4OEpEcm11NVdWVVh5YmZhWmdm?=
 =?utf-8?B?WHdqTXphSGZvOGQyWDA2TlpmeXJnSkdZck1Lc3ArL1IvQVdCOGdzL3BmQ1F4?=
 =?utf-8?B?VDhXaWZWTFhra2Vwa0RJTlpqRnU5ZjBIckxaNU13SXhBL1QxN2VOY0Zoekdw?=
 =?utf-8?B?ZzNPWmNOa3owQVk5QjllZ3NZVExzTDJVTit6bWVwRWFJNHZ6aHA1RGpnVnJr?=
 =?utf-8?B?SDF3OFE3dDB4azdFbnhTWHNyeXk2cmx6NXUvTjJNV3M1d2lVVVFBVThmcVFq?=
 =?utf-8?B?ZXdIQ09FQ24wa0FKK0w4b0VScGpPanBVellFcmZSOW1MQjlaanpWUllOY0xo?=
 =?utf-8?B?aHYrYzdNV2EzaFJnRmpwU0NLeXloTWRZd2ZSdy85M0pUM3lCUmhLL3VocFBp?=
 =?utf-8?B?ZkJpR1NJazYyRWJUY296YVZiTnhpV2o2WEZuM2ZOMHRSWW1LQWVyUjRIa01q?=
 =?utf-8?B?UkYwSXBqdHV5T3AvaVdEOWJDQTQxc1F1N1krR2pBUXZ4L2hBcW9UdkEwTFg5?=
 =?utf-8?B?b2dtMmQ1MW0zTWJ5N2plVTZIZCtHYzJDUmFyUnFqbUdrZHFVWFlLV0pVUWNq?=
 =?utf-8?B?T2l3bm1MRFZhWndzdCtVZy8zQ2sweWd3YzVBOGlJN1NXdkZtODVnbkFZZmR0?=
 =?utf-8?B?NW11blFMRlVrQjJ3Qk1uQkpMVWkvTEV6RWtjSzVkNk8rQTVMZW1nV1doTVkz?=
 =?utf-8?B?UFhydzBTUklwTWZDZ2QvYnNBSGpkTHF1dzBkRjJlRktvTDZjWjY5TjU5NFcw?=
 =?utf-8?B?Z0VSYWE3cG44VWlBNXB2UEtGZk93WkYwYXdMWUthWHFINmJDc0RNT2FJemMx?=
 =?utf-8?B?Y1A2Vks4WW1kazRkUWhvNUhsdDdZemxGL1pzdU5ObW5PcytXYzhuNDZtNUdw?=
 =?utf-8?B?N09FdjB6ZjZpRmJBejJwRW5pR0JJejZkbzdNWk9XekV0OVVFTjB5ejI0WnhJ?=
 =?utf-8?B?bUdHZEhaeUhPSFpPdVJ1QUNXbmZ1bzN4ZVZtY08wOGx5MGxaaVNRcTRIVUxO?=
 =?utf-8?B?dWtDRGwyWlhpZ3lFVmFrdW1DQnExTnpmWWVNWUdMcTA0b0ZuV2V1NFM5Um10?=
 =?utf-8?B?eFdFOGh3SlR0OWxXYXcwQnVXU3NheTVzck9HazByZDRtZE5CTUFVNDJFYUZj?=
 =?utf-8?B?NTI5T0hCMUNWQURWYVIzdFk4emlHcFJhWGZsRWdQcXl1ME1XVTNib2xWK2lV?=
 =?utf-8?Q?NDuHHxYmzUA=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(7416014)(1800799024)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?QisveE9MTVpvZWk4SmpJejFqSDFzQkVISGJTSEJYN2xNNzhLbzJvWXE5TlZJ?=
 =?utf-8?B?QTRmd3FTcS9WUXMvOXowQnVJWTJZc3pCbG1XQ1EzcmZFcWpVZXpFcFkzSWxR?=
 =?utf-8?B?NXNiUGI4VUp6U05BY1doNXhlTzc1dWFMVmlYb1VpRXNYK0dCZEg4KzNyUE1Z?=
 =?utf-8?B?d25uVHV3YzdGbkk1SVVsRVAyY1BPVnFyZjVObkdiZVJyeC9haTZpemZpTldh?=
 =?utf-8?B?MWg2c3NUcVJ1eXhRUGVhYlJDdzV3V2YreTRraU40ak05bjhFYzkyd0dJZ1Ra?=
 =?utf-8?B?V0srK294azgwTjhGaFg0MHFEd3FPRWlYMDA3WExZcm1xUHFBVzlWdEpJdFBs?=
 =?utf-8?B?b3h5K3BMZzVqb0pLZzFXcmpPNUpjOXg2NzBEcDJ0bG4ybU5XNGVGZDV5UVVk?=
 =?utf-8?B?WkJaNENPb1ZPL2xjMyt5OTA3cGdvMXhBK1VsQ1JFVTNnTVl5V3BLQnBOSW94?=
 =?utf-8?B?WUlRYUhkVVpucTBJZlgxaUpMZGN1Syt2bE5SNVB1TXhUSnBHZURneTBER3g3?=
 =?utf-8?B?NGxuUDQ1RTR1M2U1U2dPaXFNcjNJUW5qNEk5Qko4WjNwK2owbktpeVVaSXhZ?=
 =?utf-8?B?SFF4MHQzYTJ3cUJpdGZlS3FPeGN4UUVhMFRFNnpXTDJCbDE0K2g1K2FyUG5z?=
 =?utf-8?B?ZzVEUlMrOEkvUnJ3bHZhcnl0bk5EVnR5TGFaTnN4d2dsZE9mQitpV2ZUT3c5?=
 =?utf-8?B?SFRKRFVxeTdPd0l1Z1VhWnBQV2plTTVqeTNGbTBPaURFbXI0RGp3TlJsSVpn?=
 =?utf-8?B?N1JRMlYxR1NYVEplTXEyTVdoeUd3MXVvYzNQVi8xWXNQclNGcEJEQXEyQnFI?=
 =?utf-8?B?cHFpVDBDZHI3cFpjcmlvcmx4NHNNNllIVXh2cjI0Rm54MlhjWHNwc2RnMnJ6?=
 =?utf-8?B?VDh1WnNpeUNaVGc3SlF0Q3VoVXBDdmJMS21KSFg5T2tPeDUrS1VRY0dDZk54?=
 =?utf-8?B?YnhGa0huWGtGWHJNOTgzNlBVZ2k3VGI5aFJzaWh2Ny80ZnZMSzV4Zm5BYWE4?=
 =?utf-8?B?NlB2cTFZVGxQMmlDdWIwQ0N4YzNuekNaUVdLYmJwOVBQdjhRUEl2dVhlYVAy?=
 =?utf-8?B?OXdDSzJtNERMWk5uVWkrYzI1UDhnY1FBQnVXU05XUC9Oc3ZIejNnTVo2elNm?=
 =?utf-8?B?RHgrQmZKOHNhOG5aemlqQU4xa2tpOWlCbjlLYTBoWitwNUFQZkZWRDc4NitU?=
 =?utf-8?B?aDh4N2JuOEs0RzkzbjRRNDRVQlAxcDJpM2x1bnVsUXNpN2d0WnJjblcxY2RW?=
 =?utf-8?B?Nm5XUGpsUDBoVHhWV3ZiMHZEbmw1d0ozdzhtbTJPYTRqOHNiZjU1amF3djF4?=
 =?utf-8?B?N3Q2SUFWd2RQUHhncUxDeUVvNWk4eE01MlFNL3pnT1ZtN3VrVGtOeXpZS2NT?=
 =?utf-8?B?R3g3RHFkOHZYb3MycHV6UHF3NFRwTy9lM203bnVWVE56Y1B3Q2hxdnBoK3V4?=
 =?utf-8?B?QzMydVA2SjRmaTIrL1prY3JlWEZoT2ppUUc4SElGcUQxbXgvWUszVThTUUs5?=
 =?utf-8?B?SXM1THFCL0NGekk1enRjN3BVc0NibWt4WWtqclZsejJoYXBkNHlpNnptWWpz?=
 =?utf-8?B?MHlJT2VYL3VTc29wa01KL1VRcDRIb0YrUk5tZHM3SUR5bDdNa1NVUGdlNTZy?=
 =?utf-8?B?RjU3UGxpMSsrSGJ4djZUTEkwSXdhQXdrNmZiTmJJSk95Um95YmR1OWhXYk9H?=
 =?utf-8?B?L0ZSYm1tVjlaaVlWaXEyUTF1dGtxSWxjSWUxMWJGcHpHUHgyM0NqZnNkZGR2?=
 =?utf-8?B?Wkc0bkdWZXg5dzd3RDFpcUdYSlZHaGxMV2dwKytkR0x2eUVXWWVDSkk2Nmhk?=
 =?utf-8?B?Wk1STUR3My9LNlluRkRZMktyWVFJcHhnRUV3cU5tZVdRcXRyV3RpNFp3bkpj?=
 =?utf-8?B?ZWp2M2FoY3VOc1VMZWJoRHpaaWtqQU1tRkJEeFoyaTFraXV3WitGREhVeHZy?=
 =?utf-8?B?L2UxejkvVTBpejBOd2ZxTnBCZnNwVXZtc2t0aEU5anRXS0hBckRxcEVoWXda?=
 =?utf-8?B?YU4yNitQVUFXOVp3TnJ1RW1JdDdibzVOWkNLdzZhbmUrcHlOb2RQdzVKYWJR?=
 =?utf-8?B?bkxnU2liVzNhUjAxRWxtWE50Y21lbkVjRlprdUUyUk1XVEFhYUoyYkE0RjJ0?=
 =?utf-8?Q?kPX2tEb+Dm1o3oO+B743ikK70?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 56f72275-32ab-4df6-9239-08ddb30773c6
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jun 2025 10:11:14.8149
 (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: /NfpKsDwlGycGgA68opeDy+6vVyrCmqZXgsIEpvOAhmg+IOZHAD7oPHM3gKqLcnH
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7731



On 24/06/2025 05:55, dmkhn@proton.me wrote:
> From: Denis Mukhin  
> 
> Use generic names prefixed with 'vuart_' in public PL011 emulator data
> structures and functions.
> 
> No functional change intended.
> 
> Signed-off-by: Denis Mukhin 
> ---
>  xen/arch/arm/dom0less-build.c     |  4 ++--
>  xen/arch/arm/domain.c             |  3 ++-
>  xen/arch/arm/domctl.c             | 14 +++++++------
>  xen/arch/arm/include/asm/vpl011.h | 20 ------------------
>  xen/arch/arm/vpl011.c             | 24 +++++++++++-----------
>  xen/drivers/char/console.c        |  6 ++----
>  xen/include/xen/vuart.h           | 34 ++++++++++++++++++++++++++++++-
>  7 files changed, 59 insertions(+), 46 deletions(-)
> 
> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
> index 7c1b59750fb5..11b8498d3b22 100644
> --- a/xen/arch/arm/dom0less-build.c
> +++ b/xen/arch/arm/dom0less-build.c
> @@ -216,7 +216,7 @@ int __init init_vuart(struct domain *d, struct kernel_info *kinfo,
As can be seen here ...

>       */
>      if ( kinfo->arch.vpl011 )
>      {
> -        rc = domain_vpl011_init(d, NULL);
> +        rc = vuart_init(d, NULL);
we end up with init_vuart() and vuart_init(). That's quite confusing. Maybe
domain_vuart_init() or alike?

>          if ( rc < 0 )
>              return rc;
>      }
> @@ -247,7 +247,7 @@ void __init arch_create_domUs(struct dt_device_node *node,
>           * d->arch.vpl011.irq. So the logic to find the vIRQ has to
>           * be hardcoded.
>           * The logic here shall be consistent with the one in
> -         * domain_vpl011_init().
> +         * vuart_init().
>           */
>          if ( flags & CDF_directmap )
>          {
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index be58a23dd725..68297e619bad 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -11,6 +11,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -1072,7 +1073,7 @@ int domain_relinquish_resources(struct domain *d)
>           * Release the resources allocated for vpl011 which were
>           * allocated via a DOMCTL call XEN_DOMCTL_vuart_op.
>           */
> -        domain_vpl011_deinit(d);
> +        vuart_exit(d);
IMO, deinit is more meaningful here.

>  
>  #ifdef CONFIG_IOREQ_SERVER
>          ioreq_server_destroy_all(d);
> diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
> index ad914c915f81..dde25ceff6d0 100644
> --- a/xen/arch/arm/domctl.c
> +++ b/xen/arch/arm/domctl.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -30,10 +31,11 @@ static int handle_vuart_init(struct domain *d,
>                               struct xen_domctl_vuart_op *vuart_op)
>  {
>      int rc;
> -    struct vpl011_init_info info;
> -
> -    info.console_domid = vuart_op->console_domid;
> -    info.gfn = _gfn(vuart_op->gfn);
> +    struct vuart_params params = {
> +        .console_domid = vuart_op->console_domid,
> +        .gfn = _gfn(vuart_op->gfn),
> +        .evtchn = 0,
> +    };
>  
>      if ( d->creation_finished )
>          return -EPERM;
> @@ -41,10 +43,10 @@ static int handle_vuart_init(struct domain *d,
>      if ( vuart_op->type != XEN_DOMCTL_VUART_TYPE_VPL011 )
>          return -EOPNOTSUPP;
>  
> -    rc = domain_vpl011_init(d, &info);
> +    rc = vuart_init(d, ¶ms);
>  
>      if ( !rc )
> -        vuart_op->evtchn = info.evtchn;
> +        vuart_op->evtchn = params.evtchn;
>  
>      return rc;
>  }
> diff --git a/xen/arch/arm/include/asm/vpl011.h b/xen/arch/arm/include/asm/vpl011.h
> index be64883b8628..5c308cc8c148 100644
> --- a/xen/arch/arm/include/asm/vpl011.h
> +++ b/xen/arch/arm/include/asm/vpl011.h
> @@ -59,26 +59,6 @@ struct vpl011 {
>      evtchn_port_t evtchn;
>  };
>  
> -struct vpl011_init_info {
> -    domid_t console_domid;
> -    gfn_t gfn;
> -    evtchn_port_t evtchn;
> -};
> -
> -#ifdef CONFIG_HAS_VUART_PL011
> -int domain_vpl011_init(struct domain *d,
> -                       struct vpl011_init_info *info);
> -void domain_vpl011_deinit(struct domain *d);
> -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)
> -{
> -    return -ENOSYS;
> -}
> -
> -static inline void domain_vpl011_deinit(struct domain *d) { }
> -#endif
>  #endif  /* _VPL011_H_ */
>  
>  /*
> diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> index cafc532cf028..2cf88a70ecdb 100644
> --- a/xen/arch/arm/vpl011.c
> +++ b/xen/arch/arm/vpl011.c
> @@ -134,7 +134,7 @@ static void vpl011_write_data_xen(struct domain *d, uint8_t data)
>  
>  /*
>   * vpl011_read_data_xen reads data when the backend is xen. Characters
> - * are added to the vpl011 receive buffer by vpl011_rx_char_xen.
> + * are added to the vpl011 receive buffer by vuart_putchar.
>   */
>  static uint8_t vpl011_read_data_xen(struct domain *d)
>  {
> @@ -571,9 +571,9 @@ static void vpl011_data_avail(struct domain *d,
>  }
>  
>  /*
> - * vpl011_rx_char_xen adds a char to a domain's vpl011 receive buffer.
> + * vuart_putchar adds a char to a domain's vpl011 receive buffer.
>   */
> -int vpl011_rx_char_xen(struct domain *d, char c)
> +int vuart_putchar(struct domain *d, char c)
How can putchar refer to RX? By definition putchar() is used to print data to
STDOUT. Here we receive a character and put it in the RX FIFO.

~Michal



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 10:17:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 10:17:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023543.1399534 (Exim 4.92)
	(envelope-from )
	id 1uU0iZ-0004xX-3b; Tue, 24 Jun 2025 10:17:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023543.1399534; Tue, 24 Jun 2025 10:17:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uU0iY-0004xQ-W9; Tue, 24 Jun 2025 10:17:30 +0000
Received: by outflank-mailman (input) for mailman id 1023543;
 Tue, 24 Jun 2025 10:17: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 1uU0iX-0004xK-VH
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 10:17: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 6e1b5e34-50e4-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 12:17:28 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3a6e2d85705so159201f8f.0
 for ; Tue, 24 Jun 2025 03:17:28 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3158a31d40bsm13929592a91.37.2025.06.24.03.17.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 03:17:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6e1b5e34-50e4-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750760247; x=1751365047; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=GpZiy302dBRQR7dYoAmoyN3ZKSyToQYFGFWF3abZdjc=;
        b=YXpQckjTk7b+6Rr8tgxxvFYnJ02saKzWpHI9diW/v3opy/EVykpGYoaNF+qgngck38
         XrZ0ifkXUS/8FVo58QfUA++DGb5b+YfkZJGAQqjv7E6/1N+b5HiuDgJ25wYJ6Z2hOU0X
         yC2msEuDXDItynLbldQD7zPQfXS/4zmqsXXQdh+emfHpooOk0piaTy7gz84VqOuFqh3K
         GHh2qk6ieoyEDzC77wuzeAU3n2H9TdQKu7qze+XSekspdBSJ2WNW5BTm4MGGdw1O683C
         MbSW5wJ+VcUoLetERC6La1W83dBw9/IXkNMntNs4gsxRzCAFDrlZDnfmbg9Po5rEQ9FJ
         KzKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750760247; x=1751365047;
        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=GpZiy302dBRQR7dYoAmoyN3ZKSyToQYFGFWF3abZdjc=;
        b=IMRmYtoCGxZikgsk5F53SoYVqn/Q49p4ryLd5RsvY7Kz9qHWwwSUuYAKW4N7vWb26t
         /KoBnH1QGchnw+7o39WZFj9WW/SI1WoHujXQBfRhTdEzz2zlbtkFV6O0cF3iPi5P18rt
         w8ocXvIzOZhzoWCK/qAnkXzUvVlZ3DFnDAZtW8wyv5MKNG7qMrGKGTkeKPK/vMUoLufg
         SKmROVTDXawraPiJxrR5gh4ASVAXqb1MUQyM5M7vMzKnXAyqKhacchpqMkMnxsVekQZd
         /gvdgKu/1C0bn13sH4dwm/OxH12CwCIE2Q8vs3LqQNeY/2vKXzLqy3ZaYLZBwYVPbo/E
         nLig==
X-Forwarded-Encrypted: i=1; AJvYcCXGYTnaZmUxPppMlc/0ckm+LPtzWdLjxzDS1RrdVRWmCGXEu6D7AIu/dD9xDGTT+q9AwucJXl/1Keg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzwsKxlypTsFAGIA2ASyKkUhNKCAxYQCp0sVNa2zRBJax0LzasS
	DXcr740Jyv9L5+LrsRkEkl3Gw5hs2FBPyfE/VzZ43MKOPOeDIenqzEfxig2igCOitw==
X-Gm-Gg: ASbGncuUjGLbFlhsH3fatbr+USRqJoyNxvhcWhXktr3w1U/XX95ZMQenp9CcRVOjmgl
	8PMxfKPTuulxssBhhUwc5s3ipASoi40pPKF9Hb3mWiMXlVKvI6vlqu/O/U//jPl8b/RPUcdwGe5
	G4gDfhuEAsikFkNrfvWpUhxLD0RHWk+uORSn/TDqzmQBQZpawdYp+ZUVo2rkBF8z4Y2QmtkXKmB
	FpTSr8iB3a2qzOKwhRQa+8bANbXXqeYcYYCML+axdAe3xo/zlXnAIadum1oiu32df/jGan+hoPf
	v2epHC3zPH0LelOQMjSbbfeNA+D1E2BeUT4TvntTrqrCczoKcIlir962ET6Jlq10Lo95mlExP8N
	pibyUzNkAA9oIJOqfCYbPXApbNY6AFOMDHYDZyKYk3Ea1KXA=
X-Google-Smtp-Source: AGHT+IFFaxjIpzIDICNGs4QkiVvB+6NJkJfJfXSgWqetYZThzcOdV5EkeUj++n9QHM+IDnTA7QJ7Zg==
X-Received: by 2002:a05:6000:144d:b0:3a5:26fd:d46f with SMTP id ffacd0b85a97d-3a6d12da03fmr12198944f8f.32.1750760247367;
        Tue, 24 Jun 2025 03:17:27 -0700 (PDT)
Message-ID: 
Date: Tue, 24 Jun 2025 12:17:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 7/8] vpci/msi: Free MSI resources when init_msi() fails
To: "Chen, Jiqian" 
Cc: "Huang, Ray" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 ,
 "xen-devel@lists.xenproject.org" 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-8-Jiqian.Chen@amd.com>
 <773c448a-d814-458f-ad83-e9740e724408@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 24.06.2025 11:49, Chen, Jiqian wrote:
> On 2025/6/18 22:45, Jan Beulich wrote:
>> On 12.06.2025 11:29, Jiqian Chen wrote:
>>> --- a/xen/drivers/vpci/msi.c
>>> +++ b/xen/drivers/vpci/msi.c
>>> @@ -193,6 +193,33 @@ static void cf_check mask_write(
>>>      msi->mask = val;
>>>  }
>>>  
>>> +static int cf_check cleanup_msi(struct pci_dev *pdev)
>>> +{
>>> +    int rc;
>>> +    unsigned int end, size;
>>> +    struct vpci *vpci = pdev->vpci;
>>> +    const unsigned int msi_pos = pdev->msi_pos;
>>> +    const unsigned int ctrl = msi_control_reg(msi_pos);
>>> +
>>> +    if ( !msi_pos || !vpci->msi )
>>> +        return 0;
>>> +
>>> +    if ( vpci->msi->masking )
>>> +        end = msi_pending_bits_reg(msi_pos, vpci->msi->address64);
>>> +    else
>>> +        end = msi_mask_bits_reg(msi_pos, vpci->msi->address64) - 2;
>>> +
>>> +    size = end - ctrl;
>>> +
>>> +    rc = vpci_remove_registers(vpci, ctrl, size);
>>> +    if ( rc )
>>> +        return rc;
>>
>> This is a difficult one: It's not a good idea to simply return here, yet
>> at the same time the handling of the register we're unable to remove may
>> still require e.g. ...
>>
>>> +    XFREE(vpci->msi);
>>
>> ... this. There may therefore be more work required, such that in the
>> end we're able to ...
>>
>>> +    return vpci_add_register(pdev->vpci, vpci_hw_read16, NULL, ctrl, 2, NULL);
>>
>> ... try this at least on a best effort basis.
>>
>> More generally: I don't think failure here (or in other .cleanup hook
>> functions) may go entirely silently.
> Does below meet your modification expectations?

Not sure, sorry. By "more" I really meant "more" (which may just be code
auditing, results of which would need writing down, but which may also
involve further code changes; see below).

>     rc = vpci_remove_registers(vpci, ctrl, size);
>     if ( rc )
>         printk(XENLOG_ERR "%pd %pp: remove msi handlers fail rc=%d\n",
>                pdev->domain, &pdev->sbdf, rc);
> 
>     XFREE(vpci->msi);

As I tried to indicate in my earlier reply, the freeing of this struct is
safe only if the failure above would not leave any register handlers in
place which still (without appropriate checking) use this struct.

>     /*
>      * The driver may not traverse the capability list and think device
>      * supports MSI by default. So here let the control register of MSI
>      * be Read-Only is to ensure MSI disabled.
>      */
>     rc = vpci_add_register(vpci, vpci_hw_read16, NULL, ctrl, 2, NULL);

You're losing the earlier error here, if there was one. If this one
succeeds, ...

>     if ( rc )
>         printk(XENLOG_ERR "%pd %pp: add dummy msi ctrl handler fail rc=%d\n",
>                pdev->domain, &pdev->sbdf, rc);
> 
>     return rc;

... the caller would (wrongly) get success back.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 10:34:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 10:34:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023550.1399543 (Exim 4.92)
	(envelope-from )
	id 1uU0yX-0007xI-Dv; Tue, 24 Jun 2025 10:34:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023550.1399543; Tue, 24 Jun 2025 10:34: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 1uU0yX-0007xB-BK; Tue, 24 Jun 2025 10:34:01 +0000
Received: by outflank-mailman (input) for mailman id 1023550;
 Tue, 24 Jun 2025 10:33: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 1uU0yV-0007x5-Fi
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 10:33:59 +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 bbc756cc-50e6-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 12:33:57 +0200 (CEST)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-ade4679fba7so46545566b.2
 for ; Tue, 24 Jun 2025 03:33:57 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ae0b618251bsm17148066b.55.2025.06.24.03.33.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 03:33:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bbc756cc-50e6-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750761237; x=1751366037; 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=PpYl/+rgNV5Exgpr6I3d3Pp7PRlvJtiIjdFGqf/ENjA=;
        b=jtZKXlEFkfzqnbPOiwrqkCZWI4FCDxwl4/jN8rkpLUk4hHtSMYmgEWyNxdq6C7sZ4t
         Ji72reTEB4I5keJ9wNsrzrx2q9T2YmMxB7698NnhIZ2Xdxf6uu6KaYXkOfOJbhRUWvPg
         ZGPughYQv1mAINLLx1MIXEo0UnbmBiSfxfxEzHq7jPuAupytmNHc+wF0FwS581AgsvM/
         CG98aPNTw04daJJmXcqL40aW5FuI5nT6JqSxwXczQMmQLHOfMPeowxluR5eqTEvA1Gze
         z8GoFwAqrroB44abPcpOOkgxIunjoCuFXxCboztQHj7at63xyFxEIig4jelLYk8XZ7s5
         5QKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750761237; x=1751366037;
        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=PpYl/+rgNV5Exgpr6I3d3Pp7PRlvJtiIjdFGqf/ENjA=;
        b=q3vivzQKgdjmJfpsL7C4t4ydW2d9YRYim1yh+8uCew648qCoR1EobQ4LOgDXkmr/Q3
         BNLKiAk6A2YtW/fD7w6KSu3uDpsgjJmAY5AQcb3Q2Pi4VDCYxaZtv7QseWWU5g370fQz
         weqZMPgjpFaERhScjJ6Xjv1ogB6sQLSwnFvLIFC1KBu+AGcCkVT3wEEx21byEQFm7r9I
         bwQDf3IEsd5TgPc+17MEo9jrx9kAKuzXIqP++g8+IKCkES8VJ9tCJGDrmwjmeOZ3dqgN
         ZdtrqKywwyDXJuYBqgrvZi/yMFg+Ow7go1pRrnCV6UhBvSuG+pUBUwETSeTphgVo6Sui
         87Zw==
X-Forwarded-Encrypted: i=1; AJvYcCWT0A8/xdafQb6ArE4slSB2iMH3bLuAUuY+2kKAlpjHSSG1IlsQe6zAr/zukRoqL6gAi40Z6ynntns=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyxnVhs8j32YgSDxrUTwOpVFKJvFnSOhx2Gwn78ntqYMW6IjoJp
	X18AMQ7ripZlseY1ZG78g1VcPBHBz6bgUEJ5uHed/pJkY6hpctvZOGCV
X-Gm-Gg: ASbGncvslxxzs8kyeCW5YPJThQg2KR08DgBqW2z8w2XV1z6OeHn5c2sgloO0SWnbXQZ
	f2SOPLMXqlaTVPgJObBtEoWnYfizay0vASdJVNXqAH3QX1oH2nlADxTfSKfLeG/iCnAusYO6IEp
	AUxf11Nyu7Pbxo2b0hZuOAkRMoiOWtEqyEQc64srMv//KhG/FluOYfqd4eriW6XzAa6LipXQV/z
	U61hHh0rDE5E3VrZE9NVmZPFm5u6PVNRDeN0eTX4SALeD8uSJZqldD3D2gktt5C0H1x6tc8RneJ
	Qqk8z9koTOLXz8q+h/6ZHQwQECQ3BjJENsil+obSCT4xp2b3Dj6H0mB4hXqDLdj5l55OOrqtL5x
	cYwUa/t4J5m/LbedBR7XTb6DEpfsHMg0KcaI=
X-Google-Smtp-Source: AGHT+IFmT4rxMzjg3fpBe+bkSRV7Pdt5X68i1wzOIhUhrDBQJo2pGsd8IRcTtSPMgjd4fj9db/l1Rg==
X-Received: by 2002:a17:907:3e95:b0:ad5:34cf:d23f with SMTP id a640c23a62f3a-ae0579246eamr1359036266b.21.1750761236307;
        Tue, 24 Jun 2025 03:33:56 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------RAhJxSzatQHsZlWOo1iK9zJz"
Message-ID: <7b8d5688-bfc3-4341-8fd5-8e9feefdfa82@gmail.com>
Date: Tue, 24 Jun 2025 12:33:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 01/17] xen/riscv: implement sbi_remote_hfence_gvma()
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: 
 
 <728ee92b-0e4f-4ccb-8c6e-54687bd75c62@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <728ee92b-0e4f-4ccb-8c6e-54687bd75c62@suse.com>

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


On 6/18/25 5:15 PM, Jan Beulich wrote:
> On 10.06.2025 15:05, Oleksii Kurochko wrote:
>> Instruct the remote harts to execute one or more HFENCE.GVMA instructions,
>> covering the range of guest physical addresses between start_addr and
>> start_addr + size for all the guests.
> Here and in the code comment: Why "for all the guests"? Under what conditions
> would you require such a broad (guest) TLB flush?

Hmm, it seems like KVM always do such a broad (guest) TLB flush during detection
of VMIDLEN:
	void __init kvm_riscv_gstage_vmid_detect(void)
	{
		unsigned long old;
	
		/* Figure-out number of VMID bits in HW */
		old = csr_read(CSR_HGATP);
		csr_write(CSR_HGATP, old | HGATP_VMID);
		vmid_bits = csr_read(CSR_HGATP);
		vmid_bits = (vmid_bits & HGATP_VMID) >> HGATP_VMID_SHIFT;
		vmid_bits = fls_long(vmid_bits);
		csr_write(CSR_HGATP, old);
	
		/* We polluted local TLB so flush all guest TLB */
		kvm_riscv_local_hfence_gvma_all();
	
		/* We don't use VMID bits if they are not sufficient */
		if ((1UL << vmid_bits) < num_possible_cpus())
			vmid_bits = 0;
	}

It is not clear actually why so broad and why not hfence_gvma_vmid(vmid_bits).

And I am not really 100% sure that any hfence_gvma() is needed here as I don't see
what could pollutes local guest TLB between csr_write() calls.

RISC-V spec. says that:
	Note that writing hgatp does not imply any ordering constraints between page-table updates and
	subsequent G-stage address translations. If the new virtual machine’s guest physical page tables have
	been modified, or if a VMID is reused, it may be necessary to execute an HFENCE.GVMA instruction
	(see Section 18.3.2) before or after writing hgatp.

But we don't modify VM's guest physical page table. We could potentially reuse VMID between csr_write()
calls, but it is returning back and we don't switch to a guest with this "new" VMID, so it isn't really used.

Do you have any thoughts about that?

~ Oleksii

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



  
    
  
  
    

    
    
    
    
    On 6/18/25 5:15 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 10.06.2025 15:05, Oleksii Kurochko wrote:

    Instruct the remote harts to execute one or more HFENCE.GVMA instructions,
covering the range of guest physical addresses between start_addr and
start_addr + size for all the guests.

    Here and in the code comment: Why "for all the guests"? Under what conditions
would you require such a broad (guest) TLB flush?
    
    
    
    
    Hmm, it seems like KVM always do such a broad (guest) TLB flush during detection
of VMIDLEN:
	void __init kvm_riscv_gstage_vmid_detect(void)
	{
		unsigned long old;
	
		/* Figure-out number of VMID bits in HW */
		old = csr_read(CSR_HGATP);
		csr_write(CSR_HGATP, old | HGATP_VMID);
		vmid_bits = csr_read(CSR_HGATP);
		vmid_bits = (vmid_bits & HGATP_VMID) >> HGATP_VMID_SHIFT;
		vmid_bits = fls_long(vmid_bits);
		csr_write(CSR_HGATP, old);
	
		/* We polluted local TLB so flush all guest TLB */
		kvm_riscv_local_hfence_gvma_all();
	
		/* We don't use VMID bits if they are not sufficient */
		if ((1UL << vmid_bits) < num_possible_cpus())
			vmid_bits = 0;
	}

It is not clear actually why so broad and why not hfence_gvma_vmid(vmid_bits).

And I am not really 100% sure that any hfence_gvma() is needed here as I don't see
what could pollutes local guest TLB between csr_write() calls.

RISC-V spec. says that:
	Note that writing hgatp does not imply any ordering constraints between page-table updates and
	subsequent G-stage address translations. If the new virtual machine’s guest physical page tables have
	been modified, or if a VMID is reused, it may be necessary to execute an HFENCE.GVMA instruction
	(see Section 18.3.2) before or after writing hgatp.

But we don't modify VM's guest physical page table. We could potentially reuse VMID between csr_write()
calls, but it is returning back and we don't switch to a guest with this "new" VMID, so it isn't really used.

Do you have any thoughts about that?

~ Oleksii

    
  


--------------RAhJxSzatQHsZlWOo1iK9zJz--


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 10:44:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 10:44:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023561.1399554 (Exim 4.92)
	(envelope-from )
	id 1uU18x-0001Ib-Gu; Tue, 24 Jun 2025 10:44:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023561.1399554; Tue, 24 Jun 2025 10:44:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uU18x-0001IU-Dy; Tue, 24 Jun 2025 10:44:47 +0000
Received: by outflank-mailman (input) for mailman id 1023561;
 Tue, 24 Jun 2025 10:44: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 1uU18v-0001IO-HK
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 10:44:45 +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 3cdba2a9-50e8-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 12:44:43 +0200 (CEST)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3a6e2d85705so175540f8f.0
 for ; Tue, 24 Jun 2025 03:44:43 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b31f1241f07sm10086947a12.37.2025.06.24.03.44.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 03:44:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3cdba2a9-50e8-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750761883; x=1751366683; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=jeLu3ICCQu6W5hgFV9sjRVxbV89+G1fWtqyCL142kAA=;
        b=AnEbGYRJH9wvZe5SobOYdR1iv92Th3D3ye9jKDD5EAx5JjiDeRNR5kOqx8snvl7KeA
         Q3eorIdwlGgcLn0EJ0SAQSnq7x36fpIAR+IwH1fVCDbJdOl5xoZP1cFHpqsM3a1TsdQt
         Mgh1si7Y5sDh2Fup9gJJfHQUvetWqESyS6EEX0ar5L+llOXvaXSmnP1cLfmIi3RoCdSa
         SVu0bmHRk695ZYU+87H6yeEgmI7YnmuafJ4/MPG2q28TbA7yEXGSMaVyJ3fb79Rgaa3F
         86OIRsRgZFH/IfetQYuoDQJtGxqeSR0JTPkhZLrTVlyx7c1bdL83I2ZnQPNSA6HfMXoD
         j9+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750761883; x=1751366683;
        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=jeLu3ICCQu6W5hgFV9sjRVxbV89+G1fWtqyCL142kAA=;
        b=Dloxr2HJN2ZUU9/5sOkQDh0zfCIkgWYFYCCtMF/5/djTSH7Ttu5lCll2tg+MUpidfg
         d3aTOhVwTAXirJ1/ovi9vQKwzm1vYZ3C546QfNoDDBEbljw4AZCnyiWvg/BZ2BPTjAL/
         ZOG7yWaBb3gXuva6Dp9lzXCCeB3ORGQd4sBGc2dKPxTVJ9c29kSeJMwk2frpqibNgoL8
         PemeNXi+dG8oZvGCarRnRzJchI9LJF0mxcuu/h52tgNDJBB7BN5jU5jOg7ZY/kUoBuUn
         6gqFRyQ8Vi5m5vth8U8stOJyIJgIpIjkPb8D8pdxJuTAsan3gzzkhyb5QQKqOo9ydk/a
         U6xA==
X-Forwarded-Encrypted: i=1; AJvYcCUwusu2Hu0KfhZvzPkKVteVutn34CmJRNHmY3yOM5eBFQDWhI4uh5ak3BJ1oKCdycF/ryY2rg0qsZc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxKpUSlSevvbnkX78WjzBGs8r1lwXWqG8VCRf/9Iz4EKaX1dWbi
	UwpR7Gj9FYO1jUfXEcEUZ2uaXn5xHmuJql7V727oEBwN1wkwBTVmN462F1M5emNyDA==
X-Gm-Gg: ASbGncsZVwV507pKbMFUsVsQV41PYjNxILuYbX/BacG5G0roIqePL6snMDkrWLdoD7O
	lu6jr5xhJOv1DjJH0na4ztfv3gLhPjdlhsUEqTK2zYfR5AQFOqXEIp3pnlxcix7n1xf7YduLg2c
	vUSV5O8yYOQxmoP9/vFKVed5c8u+DPFbt8/U/IXCwsyAPRS6bn7zrkrekipIhTKoX+SF1NnU9hL
	cH9KR/keNSFGoTZcFoAwwoZ/UFVVCjjzjcq9fQq2LlEbe1wD+j3/95RRoDTruXOnrTUG5s5vlTm
	yUh9ZFQP5EkmdZ0WTvMXOb+cqLp61sb8qme7IYBn33EMa/H8b8GLBqpUGk85B6e15Tp2GtA9h+l
	+EJbD5Xy1YECkvS02TvlUiyjmgpmhzWdg7CVNyfBPLGAnWsE=
X-Google-Smtp-Source: AGHT+IFOrUn1NY29QGV7qy24/rZ2wcOQiq7OWz4cNtaaJ9OviFtAcMOd6wsPhhBe0sJHLh0/ao0G0g==
X-Received: by 2002:a05:6000:2906:b0:3a4:e393:11e2 with SMTP id ffacd0b85a97d-3a6d12d9fb7mr13129253f8f.34.1750761882585;
        Tue, 24 Jun 2025 03:44:42 -0700 (PDT)
Message-ID: <80223fe3-7403-4026-9505-8826c318fabb@suse.com>
Date: Tue, 24 Jun 2025 12:44:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 03/17] xen/riscv: introduce guest domain's VMID
 allocation and manegement
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: 
 
 
 <145f71c2-643e-4839-a2ae-0bc1f049db74@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: <145f71c2-643e-4839-a2ae-0bc1f049db74@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 24.06.2025 11:46, Oleksii Kurochko wrote:
> On 6/18/25 5:46 PM, Jan Beulich wrote:
>> On 10.06.2025 15:05, Oleksii Kurochko wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/riscv/p2m.c
>>> @@ -0,0 +1,115 @@
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#include 
>>> +#include 
>>> +
>>> +static spinlock_t vmid_alloc_lock = SPIN_LOCK_UNLOCKED;
>>> +
>>> +/*
>>> + * hgatp's VMID field is 7 or 14 bits. RV64 may support 14-bit VMID.
>>> + * Using a bitmap here limits us to 127 (2^7 - 1) or 16383 (2^14 - 1)
>>> + * concurrent domains.
>> Which is pretty limiting especially in the RV32 case. Hence why we don't
>> assign a permanent ID to VMs on x86, but rather manage IDs per-CPU (note:
>> not per-vCPU).
> 
> Good point.
> 
> I don't believe anyone will use RV32.
> For RV64, the available ID space seems sufficiently large.
> 
> However, if it turns out that the value isn't large enough even for RV64,
> I can rework it to manage IDs per physical CPU.
> Wouldn't that approach result in more TLB entries being flushed compared
> to per-vCPU allocation, potentially leading to slightly worse performance?

Depends on the condition for when to flush. Of course performance is
unavoidably going to suffer if you have only very few VMIDs to use.
Nevertheless, as indicated before, the model used on x86 may be a
candidate to use here, too. See hvm_asid_handle_vmenter() for the
core (and vendor-independent) part of it.

> What about then to allocate VMID per-domain?

That's what you're doing right now, isn't it? And that gets problematic when
you have only very few bits in hgatp.VMID, as mentioned below.

>>> The bitmap space will be allocated dynamically
>>> + * based on whether 7 or 14 bit VMIDs are supported.
>>> + */
>>> +static unsigned long *vmid_mask;
>>> +static unsigned long *vmid_flushing_needed;
>>> +
>>> +/*
>>> + * -2 here because:
>>> + *    - -1 is needed to get the maximal possible VMID
>> I don't follow this part.
> 
> Probably, I'm missing something.
> 
> hgat.vmid is 7 bit long. BIT(7,U) = 1 << 7 = 128 which is bigger
> then 7 bit can cover (0b1000_0000 and 0x111_1111). Thereby the MAX_VMID is:
>   BIT(7, U) - 1 (in case of RV32).

Right, but then why -2? (Maybe this is moot now that you agreed that
INVALID_VMID can be defined differently.

>> VMIDLEN being permitted to be 0, how would you run more than one VM (e.g. Dom0)
>> on such a system?
> 
> Hmm, good question.
> 
> Then it will be needed to flush TLB on each VM switch by using
> sbi_remote_hfence_gvma().

Right, but just to be clear: That flush should not be conditional upon
VMIDLEN being 0. In whatever model you chose, the handling of this special
case should come out "natural".

>>> +        sbi_remote_hfence_gvma_vmid(d->dirty_cpumask, 0, 0, p2m->vmid);
>> You're creating d; it cannot possibly have run on any CPU yet. IOW
>> d->dirty_cpumask will be reliably empty here. I think it would be hard to
>> avoid issuing the flush to all CPUs here in this scheme.
> 
> I didn't double check, but I was sure that in case d->dirty_cpumask is empty then
> rfence for all CPUs will be send. But I was wrong about that.
> 
> What about just update a code of sbi_rfence_v02()?

I don't know, but dealing with the issue there feels wrong. However,
before deciding where to do something, it needs to be clear what you
actually want to achieve. To me at least, that's not clear at all.

>>> +    spin_unlock(&vmid_alloc_lock);
>>> +    return rc;
>>> +}
>>> +
>>> +void p2m_free_vmid(struct domain *d)
>>> +{
>>> +    struct p2m_domain *p2m = p2m_get_hostp2m(d);
>>> +
>>> +    spin_lock(&vmid_alloc_lock);
>>> +
>>> +    if ( p2m->vmid != INVALID_VMID )
>>> +    {
>>> +        clear_bit(p2m->vmid, vmid_mask);
>>> +        set_bit(p2m->vmid, vmid_flushing_needed);
>> Does this scheme really avoid any flushes (except near when the system is
>> about to go down)?
>>
>> As to choice of functions - see above.
> 
> I think yes, so my idea was that if vmid isn't freed then we have enough free VMID
> and in this case flush isn't needed as each vcpu has unique not-used yet VMID,
> and if there is no free VMID then and error will return in p2m_alloc_vmid():
>      if ( nr == MAX_VMID )
>      {
>          rc = -EBUSY;
>          printk(XENLOG_ERR "p2m.c: dom%pd: VMID pool exhausted\n", d->domain_id);
>          goto out;
>      }

Which, as said, is a problem when there are only very few VMIDs.

> On other hand, if VMID was freed and then re-used in p2m_alloc_vmid(), then it means
> that vmid_flushing_needed will have VMID bit set, what means that a TLB flush is needed.

Let's assume over the uptime of a system you cycle through all VMIDs a thousand
times. While you manage to delay some TLB flushes, the percentage of ones actually
saved is going to be very low then.

>>> +    }
>>> +
>>> +    spin_unlock(&vmid_alloc_lock);
>>> +}
>>> +
>>> +int p2m_init(struct domain *d)
>>> +{
>>> +    struct p2m_domain *p2m = p2m_get_hostp2m(d);
>>> +    int rc;
>>> +
>>> +    p2m->vmid = INVALID_VMID;
>> Given the absence of callers of p2m_free_vmid() it's also not clear what use
>> this is.
> 
> Just mark that VMID for this domain wasn't yet allocated.
> 
> Anyway, it will be called from arch_domain_create() by arch_domain_destroy() so if the some
> error happens during arch_domain_create() and p2m->vmid wasn't allocated yet (so is equal to
> INVALID_VMID), it means that there is no sense to update vmid_mask or vmid_flushing_needed.

But only if you actually came through p2m_init() prior to the error. My point
is: If you allocate a VMID here anyway, why first set the field like this?
(Again, this is likely moot since the allocation scheme is likely to change
altogether.)

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 10:48:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 10:48:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023569.1399564 (Exim 4.92)
	(envelope-from )
	id 1uU1CN-0001pm-UR; Tue, 24 Jun 2025 10:48:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023569.1399564; Tue, 24 Jun 2025 10: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 1uU1CN-0001pf-Ru; Tue, 24 Jun 2025 10:48:19 +0000
Received: by outflank-mailman (input) for mailman id 1023569;
 Tue, 24 Jun 2025 10: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 1uU1CM-0001pW-US
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 10:48:18 +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 bc749080-50e8-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 12:48:17 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3a4f72cba73so4054625f8f.1
 for ; Tue, 24 Jun 2025 03:48:17 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3158a334211sm12772091a91.48.2025.06.24.03.48.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 03:48:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bc749080-50e8-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750762097; x=1751366897; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=9jWzjxr0cOhT/YcZtHzGMhL/Sb22rIktfPaUhxasPII=;
        b=Ov4oADaelMihxAckWwlyCJ/TCngsANp1+gMic57feu2syf2fGWjaxmVAOYmGOdRBCp
         fmeQYgUqEEilhlG7IxQiYPPA1twOgLGTF2oJQSaePumoRSLWNs2WPFzWy9FULsUC8i2o
         kzQbAAyrxkyO4i+LpbasSsaWk1FIRkXsUuCR1WU4FzCfcV8V5KGHt7YkCnaTZlhe1EaG
         maZJ4L/kXcmuMxyiJRsRELvcPkqD2BiBXlf3nl9my+OGsAuCNPon+h9E5mV25if0xcjW
         +VI7uLZwL9cbbMh1ie6ktrV4rmdk25vS6YEVFpiiomHbYzGoCtNNyzTjKNCMy0oR5eh6
         E4gw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750762097; x=1751366897;
        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=9jWzjxr0cOhT/YcZtHzGMhL/Sb22rIktfPaUhxasPII=;
        b=nGjGytL3YViaSms6sekHN4S3DAM+C8NdFNe6KzrtHECWc0pJA1j/I2SLhYMUTYRgfx
         8GmGOsUYHe+95yv0Hp2+PNdkksNd54b8y9CocT/gFjvMMLnxE9Scs4na+bV98Nty5SuK
         kcLKA1tBQDHZ/tHxDJxfaPs3xQaTVq8rX/gusPTG/DhAfGJy5T8uOHRDel+xjGhCv68C
         UTty/vwbHWjE3o+QDK32OPZkIzYz993XiFUo9ZMTvw9JiUG0vIHA+4USIh7+uy0GK/ro
         bXCmn+Y/W4xbNKflmMSzVZ/hW+85EBJSaNQp5VkfrHfhmGGm6hZQxHO6fIa9AKqeISOt
         +utw==
X-Forwarded-Encrypted: i=1; AJvYcCVOhgemMxlF9psLdJAcwygpTKoJbODu8ulKfFEslJhSsnPQv3t926K7cfrRYVTvgaXXl7Gc4AM9iaI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxI+ufr6O0eNRjl3x+qwC5qD0SBEcLZXern4iSQdCeZcXmVF1pI
	1K8zdzvPcZ5oxDHdqM/6roLj9e5zgpblBtL6AMZARBfvEMppDZ11cKicSo59MlQ9Jw==
X-Gm-Gg: ASbGnctdC7gBzDmyDYdWSCteIvOWe5AFBJBCsbcmATni7cUpidMsd1FYbXkaFlwnMCR
	JtuzwcIEfx3D3Y+VkDmhsh7H+vSQgmwrM/rtY5gJGu6Bc3GbTSMj/vnZptsBrcwqg/6mm3TRMvi
	ORWrHyXNPMoegLs99Iw0eZK5eeLGTGAL0obJHGJcQIc0PTHxHnUGHQ0xgOXXC0ZFPNLmWwn7z+T
	xUPWIHK85r+xzMk4JFVFA/ViUDUOpMYtiSmP5pKeQ2MkVm4sh04eUrYboss6/3wgSHVnGDZY8ct
	4aEjKziqfFWRBBB1FFDif3LR5gZOSpWAMuJResRXp6pL19/66yUQDzNTSlWxQqxZWnQogu/Hh/+
	6pEZslefkJ87oZXpva2RWS7V66WRrG+L/wx+ZyQXCh2++dxem4cjiaVuUGg==
X-Google-Smtp-Source: AGHT+IEVT+sCPchI0oycodkT/Oe9BDp+XLqlUzaXN78CmqG4Tdw45POyjzlSKHnRPSqQbBxRUA9Ybw==
X-Received: by 2002:a05:6000:2209:b0:3a5:270e:7d3 with SMTP id ffacd0b85a97d-3a6e71ff79amr2609444f8f.13.1750762096862;
        Tue, 24 Jun 2025 03:48:16 -0700 (PDT)
Message-ID: <9649aaa4-ae9e-40a1-88c2-119a4f995250@suse.com>
Date: Tue, 24 Jun 2025 12:48:06 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 01/17] xen/riscv: implement sbi_remote_hfence_gvma()
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: 
 
 <728ee92b-0e4f-4ccb-8c6e-54687bd75c62@suse.com>
 <7b8d5688-bfc3-4341-8fd5-8e9feefdfa82@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: <7b8d5688-bfc3-4341-8fd5-8e9feefdfa82@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 24.06.2025 12:33, Oleksii Kurochko wrote:
> On 6/18/25 5:15 PM, Jan Beulich wrote:
>> On 10.06.2025 15:05, Oleksii Kurochko wrote:
>>> Instruct the remote harts to execute one or more HFENCE.GVMA instructions,
>>> covering the range of guest physical addresses between start_addr and
>>> start_addr + size for all the guests.
>> Here and in the code comment: Why "for all the guests"? Under what conditions
>> would you require such a broad (guest) TLB flush?
> 
> Hmm, it seems like KVM always do such a broad (guest) TLB flush during detection
> of VMIDLEN:
> 	void __init kvm_riscv_gstage_vmid_detect(void)
> 	{
> 		unsigned long old;
> 	
> 		/* Figure-out number of VMID bits in HW */
> 		old = csr_read(CSR_HGATP);
> 		csr_write(CSR_HGATP, old | HGATP_VMID);
> 		vmid_bits = csr_read(CSR_HGATP);
> 		vmid_bits = (vmid_bits & HGATP_VMID) >> HGATP_VMID_SHIFT;
> 		vmid_bits = fls_long(vmid_bits);
> 		csr_write(CSR_HGATP, old);
> 	
> 		/* We polluted local TLB so flush all guest TLB */
> 		kvm_riscv_local_hfence_gvma_all();
> 	
> 		/* We don't use VMID bits if they are not sufficient */
> 		if ((1UL << vmid_bits) < num_possible_cpus())
> 			vmid_bits = 0;
> 	}
> 
> It is not clear actually why so broad and why not hfence_gvma_vmid(vmid_bits).
> 
> And I am not really 100% sure that any hfence_gvma() is needed here as I don't see
> what could pollutes local guest TLB between csr_write() calls.
> 
> RISC-V spec. says that:
> 	Note that writing hgatp does not imply any ordering constraints between page-table updates and
> 	subsequent G-stage address translations. If the new virtual machine’s guest physical page tables have
> 	been modified, or if a VMID is reused, it may be necessary to execute an HFENCE.GVMA instruction
> 	(see Section 18.3.2) before or after writing hgatp.
> 
> But we don't modify VM's guest physical page table. We could potentially reuse VMID between csr_write()
> calls, but it is returning back and we don't switch to a guest with this "new" VMID, so it isn't really used.

That would be my expectation, too. Yet I don't know if RISC-V has any
peculiarities there.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 11:35:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 11:35:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023586.1399574 (Exim 4.92)
	(envelope-from )
	id 1uU1vf-0008Fs-8G; Tue, 24 Jun 2025 11:35:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023586.1399574; Tue, 24 Jun 2025 11:35: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 1uU1vf-0008Fl-4W; Tue, 24 Jun 2025 11:35:07 +0000
Received: by outflank-mailman (input) for mailman id 1023586;
 Tue, 24 Jun 2025 11:35: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 1uU1vd-0008Ff-UB
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 11:35:06 +0000
Received: from fout-a8-smtp.messagingengine.com
 (fout-a8-smtp.messagingengine.com [103.168.172.151])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 44c4c1b6-50ef-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 13:35:03 +0200 (CEST)
Received: from phl-compute-06.internal (phl-compute-06.phl.internal
 [10.202.2.46])
 by mailfout.phl.internal (Postfix) with ESMTP id 7B3BA13803ED;
 Tue, 24 Jun 2025 07:35:02 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-06.internal (MEProxy); Tue, 24 Jun 2025 07:35:02 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 24 Jun 2025 07:35:00 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 44c4c1b6-50ef-11f0-a30f-13f23c93f187
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=1750764902;
	 x=1750851302; bh=Y41ICOQIbdV3I2df50YnhOp4bTYE53gQg1EGs7FbBjA=; b=
	WBZmLfbsWGIlP8RNz0hj1RUX7HB4lnsDRE25Rn3PuEjBEJOQV1jLj9Wb+A+piB5g
	XR+s/tbKoO2+HxtCi9uT028Q6MQkbITAnZ1ggOEh604tw24rnNj8Ez2xVEg3CEW3
	f1YOpTFCQ87scVOHDPPkcY2GMSep8j26Be/OekNv7LMuQi1gw8/DpCDBbtFEYpja
	VayfrQWgqizVCYEtQJ9TYghFrcFaeKHZIt3HsW897bPGZcxoYvJ1DHdN/DwgCzcT
	Z72cLeZmaocNWBA+W8J4x8EtcrJglfk07PVeZzBC6pK9YFUlXdCWoPhnsB2vKNzg
	BV9UMVSOU+Gx8JVlrY7HnA==
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=
	1750764902; x=1750851302; bh=Y41ICOQIbdV3I2df50YnhOp4bTYE53gQg1E
	Gs7FbBjA=; b=mpHfkaDq7SPlbva4lFtqIPss4wktKwHcnRuwWlWsXQnVNqwPvkf
	3DmvYOB53TtbJm7ndjuZFNrFoyJn/gFVWjk8uGigJhqc+bUj6AlavE1PxDLZZ4Ip
	O9y9XHYKGKXT9BmFvlrQlrWaNZCs/Yvh5pU71RpeKYX69zEKVNjWQsd2zzEQdytB
	DTLIBNFqV/9mvqY63eqV2Fw/B013v5CGHiLFgdKwn2mDd/lWzGHH/dMR9Z9OxiwC
	TaR/dy0wIDT53CyNoYxDTsgkUbTOP2OWnb0Ca8bVE1uGAKBr6a/QhZWqs0Pv3YKV
	i5naM1CkIgCSLsvUc+lZ966mU7tHg7tq9eg==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgdduleejlecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghkucfo
    rghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhish
    hisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefgudelteef
    vefhfeehieetleeihfejhfeludevteetkeevtedtvdegueetfeejudenucevlhhushhtvg
    hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhn
    vhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopeegpdhmoh
    guvgepshhmthhpohhuthdprhgtphhtthhopehfrhgvughirghnohdriihighhlihhosegt
    lhhouhgurdgtohhmpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnh
    hprhhojhgvtghtrdhorhhgpdhrtghpthhtohepughpshhmihhthhesrghpvghrthhushhs
    ohhluhhtihhonhhsrdgtohhmpdhrtghpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtg
    homh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Tue, 24 Jun 2025 13:34:59 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Frediano Ziglio 
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" ,
	Jan Beulich 
Subject: Re: [PATCH] xen/efi: Do not undefined not defined macro
Message-ID: 
References: <20250624063611.236876-1-frediano.ziglio@cloud.com>
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="pZ8kuzZKgQs56Dm4"
Content-Disposition: inline
In-Reply-To: 


--pZ8kuzZKgQs56Dm4
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 24 Jun 2025 13:34:59 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Frediano Ziglio 
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" ,
	Jan Beulich 
Subject: Re: [PATCH] xen/efi: Do not undefined not defined macro

On Tue, Jun 24, 2025 at 09:33:41AM +0100, Frediano Ziglio wrote:
> On Tue, Jun 24, 2025 at 7:36=E2=80=AFAM Frediano Ziglio
>  wrote:
> >
>=20
> Typo on title "Do not undefined not defined macro" -> "Do not undefine
> not defined macro"

With typo fixed:

Acked-by: Marek Marczykowski-G=C3=B3recki 

> > The "buffer" macro is not defined.
> > It was defined till commit 59e087bf6a9c8ad805294c32dfd7c77068d81eff
> > (cfr "xen/keyhandler: Drop keyhandler_scratch").
> >
> > Signed-off-by: Frediano Ziglio 
> > ---
> >  xen/common/efi/boot.c | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> > index ded7cc129d..1a9b4e7dae 100644
> > --- a/xen/common/efi/boot.c
> > +++ b/xen/common/efi/boot.c
> > @@ -513,7 +513,6 @@ static EFI_FILE_HANDLE __init get_parent_handle(con=
st EFI_LOADED_IMAGE *loaded_i
> >      else
> >          *leaf =3D buffer;
> >  #undef BUFFERSIZE
> > -#undef buffer
> >
> >      return dir_handle;
> >  }

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

--pZ8kuzZKgQs56Dm4
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmhajWIACgkQ24/THMrX
1yzYQAf/f41rFmmw499w70hIqNYNXxh0khW+Pf404KX3BA1H3MOTjhluQmHEiGUO
miW8n9JXgI5HEAoo2a4u7LedY9bNJwS/429xnZsNUF4ShgoHRrismJtIuxYSkPhp
r6GXm+tBIb2wjmzC8EOOIqdKW3FGC2FXFDETykgXDU7i5KEON1dyhVwrk9DyN7gQ
aTo6rSwTiQkFFCPREqu4HtX8dp1bl17Moq63xfQw0iFBAWzm8VyeD8j1LS+8sLRs
/3igN/0wBuk2FH8hq+4gLT94bf/un044wcLh1wDJIpJ3ksun0o4wbsITRaMU0+AT
rTtEYzyBUymQ374BShX0jFrtTggE7g==
=LFxj
-----END PGP SIGNATURE-----

--pZ8kuzZKgQs56Dm4--


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 11:36:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 11:36:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023593.1399584 (Exim 4.92)
	(envelope-from )
	id 1uU1wv-0000JQ-GS; Tue, 24 Jun 2025 11:36:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023593.1399584; Tue, 24 Jun 2025 11:36:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uU1wv-0000JJ-De; Tue, 24 Jun 2025 11:36:25 +0000
Received: by outflank-mailman (input) for mailman id 1023593;
 Tue, 24 Jun 2025 11:36:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uU1wt-0000J4-JF
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 11:36:23 +0000
Received: from fhigh-a2-smtp.messagingengine.com
 (fhigh-a2-smtp.messagingengine.com [103.168.172.153])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 73194b91-50ef-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 13:36:21 +0200 (CEST)
Received: from phl-compute-06.internal (phl-compute-06.phl.internal
 [10.202.2.46])
 by mailfhigh.phl.internal (Postfix) with ESMTP id 877891140249;
 Tue, 24 Jun 2025 07:36:20 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-06.internal (MEProxy); Tue, 24 Jun 2025 07:36:20 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 24 Jun 2025 07:36:19 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 73194b91-50ef-11f0-b894-0df219b8e170
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=1750764980;
	 x=1750851380; bh=jGHHXZDvYPXiqdfREX+28aA5rNquNgwNysAfmLeCugA=; b=
	cs0uLU0+9ZmbgiDUU6RZ3AwovGtYpHIRkLOQpUN/Pf3vq5hjNwOaf3h3Gk59MCpj
	XBcHmM5//Yrusqeyef/AdGon+MOt8Uxg66jGp3z7ffqaDdCC6JvNm3gmlTKUpLni
	lfMue9DRvKXUVnD3lhOmb75aq9XZPVqroXqmNYLdcZAt6h/Pg5hAHiZg/5fIr52E
	IN7XgoPokedhoCQSMORbMpSwRicgoTmUuwyYfnyljxKlu4AZRTobzOshZleQcwpg
	JP28YaTRLkhP61M4Odfag3dqGAJZzVb5NWuA/7hjqwypVGdH9FwqhlGRM8SPMuwc
	NGLqARqr4sh56cpcFoX1aw==
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=
	1750764980; x=1750851380; bh=jGHHXZDvYPXiqdfREX+28aA5rNquNgwNysA
	fmLeCugA=; b=GPoEBLYPrptBEFz4Y2HgUba+X+Nv/ObYQbTfR1fi6z8NqiMi3Wk
	ynVZw4ODbymkZGUOAvza9XW1TaTz8hjWYVYzh53A9L0ubmqu32ygW4EPL98hTXAD
	0XLsfLsIRPRB7NplW9CL5kPeBC6tsicy0HlO+dS+5EpPMJiKzjAg0WboTU3qZjfx
	5uV7PSUwpkiQ4hnUqJD/Jij6ux98B2hmBgZ7zNuWQ99mLa1Z9Val0woOQNwm3/AJ
	1FPM3NmSIt96rM76nLpKRh66EBFywVIiNzUE4r/UV1xRwtZieWNKY+gD+8g22Nj5
	2+WCvJOJyBqGmsY3BhsH+outG2ua4jpRcpg==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgdduleejlecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghkucfo
    rghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhish
    hisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefgudelteef
    vefhfeehieetleeihfejhfeludevteetkeevtedtvdegueetfeejudenucevlhhushhtvg
    hrufhiiigvpedunecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhn
    vhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopeegpdhmoh
    guvgepshhmthhpohhuthdprhgtphhtthhopehfrhgvughirghnohdriihighhlihhosegt
    lhhouhgurdgtohhmpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnh
    hprhhojhgvtghtrdhorhhgpdhrtghpthhtohepughpshhmihhthhesrghpvghrthhushhs
    ohhluhhtihhonhhsrdgtohhmpdhrtghpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtg
    homh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Tue, 24 Jun 2025 13:36:17 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Frediano Ziglio 
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" ,
	Jan Beulich 
Subject: Re: [PATCH] xen/efi: Do not undefined not defined macro
Message-ID: 
References: <20250624063611.236876-1-frediano.ziglio@cloud.com>
 
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="65ugyNPzkkQuEljJ"
Content-Disposition: inline
In-Reply-To: 


--65ugyNPzkkQuEljJ
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 24 Jun 2025 13:36:17 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Frediano Ziglio 
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" ,
	Jan Beulich 
Subject: Re: [PATCH] xen/efi: Do not undefined not defined macro

On Tue, Jun 24, 2025 at 01:34:59PM +0200, Marek Marczykowski-G=C3=B3recki w=
rote:
> On Tue, Jun 24, 2025 at 09:33:41AM +0100, Frediano Ziglio wrote:
> > On Tue, Jun 24, 2025 at 7:36=E2=80=AFAM Frediano Ziglio
> >  wrote:
> > >
> >=20
> > Typo on title "Do not undefined not defined macro" -> "Do not undefine
> > not defined macro"
>=20
> With typo fixed:
>=20
> Acked-by: Marek Marczykowski-G=C3=B3recki 

Oh, and maybe:
Fixes: 59e087bf6a9c ("xen/keyhandler: Drop keyhandler_scratch")


> > > The "buffer" macro is not defined.
> > > It was defined till commit 59e087bf6a9c8ad805294c32dfd7c77068d81eff
> > > (cfr "xen/keyhandler: Drop keyhandler_scratch").
> > >
> > > Signed-off-by: Frediano Ziglio 
> > > ---
> > >  xen/common/efi/boot.c | 1 -
> > >  1 file changed, 1 deletion(-)
> > >
> > > diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> > > index ded7cc129d..1a9b4e7dae 100644
> > > --- a/xen/common/efi/boot.c
> > > +++ b/xen/common/efi/boot.c
> > > @@ -513,7 +513,6 @@ static EFI_FILE_HANDLE __init get_parent_handle(c=
onst EFI_LOADED_IMAGE *loaded_i
> > >      else
> > >          *leaf =3D buffer;
> > >  #undef BUFFERSIZE
> > > -#undef buffer
> > >
> > >      return dir_handle;
> > >  }
>=20
> --=20
> Best Regards,
> Marek Marczykowski-G=C3=B3recki
> Invisible Things Lab



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

--65ugyNPzkkQuEljJ
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmhajbEACgkQ24/THMrX
1ywMRQf9EuzV8PO6Uj5c2ZE+ts4JewX6ABN68oqXWDpnfypBOMpHxuvdNJqqyHn6
bC2b8zDjrpVCxRc/k9Kk7koiRg9aZKpqqSElCnZaSO6KGOJzRYIGOzF3K26y9nKB
RzfT4X4sGqQwzFUc0QCOFEjA2rBZFzipMl5AWydrVPjzJUR1oAiu+l7sR2odbkL6
aANcyDSVkHfJZnx5wtlI0fHQxPcdhMvOftg1gEaXCClW/bm3fwrkS893wjGsnh02
PJ80DCAybzH6fOL+ODd3ai/vZCYQYqiP4qi/OXWtLUYCFEa+qTNnxkzhZb8ykAur
VTKCuJuU9ZX904Ks+2np2Ukhex1R9g==
=ZDHY
-----END PGP SIGNATURE-----

--65ugyNPzkkQuEljJ--


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 11:39:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 11:39:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023604.1399594 (Exim 4.92)
	(envelope-from )
	id 1uU20L-0000xi-1t; Tue, 24 Jun 2025 11:39:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023604.1399594; Tue, 24 Jun 2025 11:39:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uU20K-0000xb-VK; Tue, 24 Jun 2025 11:39:56 +0000
Received: by outflank-mailman (input) for mailman id 1023604;
 Tue, 24 Jun 2025 11: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 1uU20J-0000xP-80
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 11:39:55 +0000
Received: from fout-a8-smtp.messagingengine.com
 (fout-a8-smtp.messagingengine.com [103.168.172.151])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f2123191-50ef-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 13:39:54 +0200 (CEST)
Received: from phl-compute-01.internal (phl-compute-01.phl.internal
 [10.202.2.41])
 by mailfout.phl.internal (Postfix) with ESMTP id 8AFA41380CCE;
 Tue, 24 Jun 2025 07:39:53 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-01.internal (MEProxy); Tue, 24 Jun 2025 07:39:53 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 24 Jun 2025 07:39:52 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f2123191-50ef-11f0-a30f-13f23c93f187
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=1750765193;
	 x=1750851593; bh=NtCDtcotcSzRjElW0HpZk3b852V3YOCBDiESB2CuzXU=; b=
	XAdrWiGTmr8mEN0cGsaXR7YfX80QLDGh6Ki/GRMiXFCoulBJ2wIbnUX4LI3SFdDB
	30LrVqPlq88xh1LLScKmLQzjXPDSUDn5a6L1ynx7wMNeLSImxJi6VuhN5lMZ+2h8
	Dc3BkhhnszcdFsAuPj61cBd09dq4EY42wIjGwfWGuSfOfyRVPohQFAPtSZAlAftp
	uJJ26YDJXs5h5MNloXboc8M+Ek4HZpTmrq2jAX5dKwO1CCBrP89Fxu8HTS4JdM/V
	Wz/U9ORf1yKfhLLyahGd+ljQGZ8lnQdv39GKbl/+uYo6w3NdQgrmQRRpanHUXSSi
	X82IyZ05XzghRLwz0smiWA==
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=
	1750765193; x=1750851593; bh=NtCDtcotcSzRjElW0HpZk3b852V3YOCBDiE
	SB2CuzXU=; b=hG9QTGHFGduG/jP2c6kKim0a25CMOyh6f7utgYDAvYUEUShjaR6
	BJq14PP/3QFQVcVtkKsgsdI9r3qzSI1K8LvViON1peAjUzwxTH1d+/yifF3o780d
	wo5byQag+YodgpFrwcJ7MpOgoDjhRKURWiW4+ecEoq8xlHtCEFNp6Z9iP6MycHLK
	vIunxqwSjIKtwdDP0kIky6WJxR33tSzsZkluXjUnVWGZqu1JptgxR6PDZhhIbHUm
	7c8W8zlxLUiLHw0eFF+oBLTPLHKBG2+XK6tQBL5T/KPpRF0GL1ja8PqOYp5Zgexa
	KIifi9rWD4m4Hk6YnKFxG/Dm7D+jPLM8C2g==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgdduleejlecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghkucfo
    rghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhish
    hisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefgudelteef
    vefhfeehieetleeihfejhfeludevteetkeevtedtvdegueetfeejudenucevlhhushhtvg
    hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhn
    vhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopeegpdhmoh
    guvgepshhmthhpohhuthdprhgtphhtthhopehfrhgvughirghnohdriihighhlihhosegt
    lhhouhgurdgtohhmpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnh
    hprhhojhgvtghtrdhorhhgpdhrtghpthhtohepughpshhmihhthhesrghpvghrthhushhs
    ohhluhhtihhonhhsrdgtohhmpdhrtghpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtg
    homh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Tue, 24 Jun 2025 13:39:50 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Frediano Ziglio 
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" ,
	Jan Beulich 
Subject: Re: [PATCH] xen/efi: Show error message for EFI_INVALID_PARAMETER
 error
Message-ID: 
References: <20250624063541.236691-1-frediano.ziglio@cloud.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="swWOuFDa8Otvr5Rq"
Content-Disposition: inline
In-Reply-To: <20250624063541.236691-1-frediano.ziglio@cloud.com>


--swWOuFDa8Otvr5Rq
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 24 Jun 2025 13:39:50 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Frediano Ziglio 
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" ,
	Jan Beulich 
Subject: Re: [PATCH] xen/efi: Show error message for EFI_INVALID_PARAMETER
 error

On Tue, Jun 24, 2025 at 07:35:39AM +0100, Frediano Ziglio wrote:
> Show string message instead of code.
> This happened trying some different ways to boot Xen, specifically
> trying loading xen.efi using GRUB2 "linux" command.
>=20
> Signed-off-by: Frediano Ziglio 

Acked-by: Marek Marczykowski-G=C3=B3recki 

> ---
>  xen/common/efi/boot.c | 3 +++
>  1 file changed, 3 insertions(+)
>=20
> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> index fb3b120982..ded7cc129d 100644
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -329,6 +329,9 @@ static void __init PrintErrMesg(const CHAR16 *mesg, E=
FI_STATUS ErrCode)
>      case EFI_BUFFER_TOO_SMALL:
>          mesg =3D L"Buffer too small";
>          break;
> +    case EFI_INVALID_PARAMETER:
> +        mesg =3D L"Invalid parameter";
> +        break;
>      default:
>          PrintErr(L"ErrCode: ");
>          DisplayUint(ErrCode, 0);
> --=20
> 2.43.0
>=20

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

--swWOuFDa8Otvr5Rq
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmhajoYACgkQ24/THMrX
1ywRSwf/bickcyO95ZolVxli1cu5IDly0kAfRdXXVlNW7UfrXDNNcjs6ipcBlfe4
qsnvUqtXyRrmN11eJShIVT40vmmKogjGZ7fuH7quFxHC8ifF5KIxefMCAkDWfI8i
h+4OQhoZuLBUgPK7runb+jIj+NIGrsglC+6jjsan82vRlgYBvsNkxddFj6SiEMJP
r23Iep+H7yqWDhR7MOpLoLZa+SmFzwXetNezjZXdMlDczCcAHQPxevxFDru5F0VC
cSFIGSbFhyc6aqpX4s9s7VZOiWr6Ad9+ElOh5UCZ0ZVEa0VwvvavH9yRFV3IiEMd
HB6s+7JpQGIf7Z7jez3BVMuF8HvAyA==
=l9Ut
-----END PGP SIGNATURE-----

--swWOuFDa8Otvr5Rq--


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 11:45:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 11:45:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023613.1399603 (Exim 4.92)
	(envelope-from )
	id 1uU25q-0002fL-K3; Tue, 24 Jun 2025 11:45:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023613.1399603; Tue, 24 Jun 2025 11: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 1uU25q-0002fE-HM; Tue, 24 Jun 2025 11:45:38 +0000
Received: by outflank-mailman (input) for mailman id 1023613;
 Tue, 24 Jun 2025 11:45: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 1uU25p-0002f8-Ep
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 11:45:37 +0000
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com
 [2a00:1450:4864:20::431])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id be2bf8d6-50f0-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 13:45:36 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a50fc7ac4dso221121f8f.0
 for ; Tue, 24 Jun 2025 04:45:36 -0700 (PDT)
Received: from localhost.localdomain (253.226.6.51.dyn.plus.net.
 [51.6.226.253]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a6e81105f0sm1781157f8f.90.2025.06.24.04.45.34
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 24 Jun 2025 04:45:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: be2bf8d6-50f0-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750765535; x=1751370335; 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=lVyqVpj2wY8y5hqZjGDjJCe56r4pMVR0ASveM16L3g0=;
        b=SqMc1WPMuLmBOJWmCW1kROUeIBKgXFge9WlYQwU1djK8XB+FjtmOocn2c6AAIKm0KY
         MBtOy7mOcKNsuDlhClOuOWZi7gxq/6RyyuM+b/epj0M1whtP/EMsEAeyeqNjz8gh99td
         OnW6GxphxwzKwAWJrVS+RYyakbY1bzZh8GdOk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750765535; x=1751370335;
        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=lVyqVpj2wY8y5hqZjGDjJCe56r4pMVR0ASveM16L3g0=;
        b=KrnoTa+rmH1cXr5A6ghgXh20A0qmepdrh/s6clunza17aEpTQiRPrXCfeLviBQZUWW
         Q/pT3o4kmUqgU0XNBTEOPsAOcJk66/8mRpSP55sQiDK3a7uPmJEdNcIMNqCgWbCBctxo
         8EZnNlinEh5pJ/EHfpZOctvmdA3naDGARNd8tTtuitO6gNtXZREFrer8NbyXWmczgUMO
         t05OV5CPVdTfx8UK+PaCQkgH90ut0+4V5mQzf17C176C55E02FKf5QN0j19WZX+LFbGq
         QLjVTmFfOoWvba3/IlAPGQ31YWPRUJyNt7ouWnY79FNeHqt3bdP9toiLy7zqnlpjzdZ2
         hYxA==
X-Gm-Message-State: AOJu0YwfUYBZdS8l6pAT7V6Su9hcSP+SxhDVD2mO6PLI9b+ZAywLZIFU
	EhD9lqGhkAFuRn1T+/QoRFdoEpepwWL/Xb1cAYHXEFmtX+/WEEDRowR6fsoYFPTCQgZPt8i36kU
	5H2Gp2pOiVA==
X-Gm-Gg: ASbGncsyIc0xavkd0Zjq+Ais0fch9eJ/OcodjXACqgJQH6oayXmkBevV6rHUu4Hh3jR
	w62jBkk2ODjWxvQ7l1vjk8qOjstFQ0No31f6vxc9PT+olWyygl8T1pMafyFZe1TpfzJ4fd8LF0r
	Mox2PHqA3k8MdDE2PIC6UkGPBxie0RjFYfLf/LQfyxdS7GJ1zd24D0MrPkc7tGLZk97Jig33IZ6
	owDBfYbEaKkfyHzasMdcdcTojxgEfENBb7syUIBFl+cHM+oRrojDLxk/hRYoP00vLzx9+RimAwv
	owCmuzkOfK9LSdWRPUPlvuDwZlJw9ynveA3/y9GFS+0T+xkBfdvtj9j2fsFGL5x/vjx8bFzeDMY
	uB4i+OLtHpu376YJILixzp9byPpWmZA==
X-Google-Smtp-Source: AGHT+IGjo5UPM8nJJTYnA7I630aKGqBdSDjlyvu7EJU0isHFK2HqZkJnsu/yiGeT6a0v0SnTYP2X9A==
X-Received: by 2002:adf:9c8d:0:b0:3a5:2ec5:35ba with SMTP id ffacd0b85a97d-3a6d1322917mr10060924f8f.30.1750765535477;
        Tue, 24 Jun 2025 04:45:35 -0700 (PDT)
From: Frediano Ziglio 
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio ,
	"Daniel P. Smith" ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Jan Beulich 
Subject: [PATCH v2] xen/efi: Do not undefine not defined macro
Date: Tue, 24 Jun 2025 12:45:26 +0100
Message-ID: <20250624114529.34743-1-frediano.ziglio@cloud.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The "buffer" macro is not defined.

Fixes: 59e087bf6a9c ("xen/keyhandler: Drop keyhandler_scratch")
Signed-off-by: Frediano Ziglio 
Acked-by: Marek Marczykowski-Górecki 
---
Changes since v1:
- fixed commit message;
- added Acked-by.
---
 xen/common/efi/boot.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 1a181ba933..c5625ccecf 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -556,7 +556,6 @@ static EFI_FILE_HANDLE __init get_parent_handle(const EFI_LOADED_IMAGE *loaded_i
     else
         *leaf = buffer;
 #undef BUFFERSIZE
-#undef buffer
 
     return dir_handle;
 }
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 11:57:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 11:57:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023620.1399614 (Exim 4.92)
	(envelope-from )
	id 1uU2H1-0004Qf-Jf; Tue, 24 Jun 2025 11:57:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023620.1399614; Tue, 24 Jun 2025 11:57:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uU2H1-0004QY-Gp; Tue, 24 Jun 2025 11:57:11 +0000
Received: by outflank-mailman (input) for mailman id 1023620;
 Tue, 24 Jun 2025 11:57: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 1uU2H0-0004QQ-HE
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 11:57:10 +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 5937e8ce-50f2-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 13:57:05 +0200 (CEST)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-3a54700a463so2950953f8f.1
 for ; Tue, 24 Jun 2025 04:57:05 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-453646d156esm142032915e9.11.2025.06.24.04.57.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 04:57:04 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5937e8ce-50f2-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750766225; x=1751371025; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=GMmY3CBjs8D7xUSCbldFoiZAUzdH0S+Gn6QAcfdKT8s=;
        b=LnXWinTpury5AaZgCglsgjV2qJ5UIM4lgok6ZSr0hAVWCe/qsUOumfKuWx0SNuzJQS
         TubhwF0ksGDoQrC6Vy87qJESsU8IWOv5Xa5v7csbLWY8t0vMKqcA3PyHl8Y7Yq7oCOQn
         cD5Rh+A+lVpQEY5B1XH2pQx8vIO3eUYOWlu7Q=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750766225; x=1751371025;
        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=GMmY3CBjs8D7xUSCbldFoiZAUzdH0S+Gn6QAcfdKT8s=;
        b=s8rzBx7X5gR/AcPrFEcMwO+e+3LWVlgWMrPaTg5GUAAxZgBWhciT0rcCWWXOeEKaSc
         tyqXz+EVB8y5Uu6xxjAZqjsz7zCSkLXTfH+Ds/ky7jEKqqFmmuNgn2SVmyEnE3WGzdMb
         YLwA/4JO8rcivadmp7nLJbrPnhOZWkvVxx9B7nAHTOMLHiBGwsL/c9/dgLvTzS9thGc4
         XNamEW7V+PePOx7wuxg2ORcg59NB/6n7E7DJ1bkAx7lWhK4pS2mvFFESB73eZTj9LVbA
         SYZyP+jvaMNxK6w2V93nPUBaEZ4k5odGUtsM94goVp4+eu8BbSiq2SFfuzMfEgKYn9xK
         +neQ==
X-Forwarded-Encrypted: i=1; AJvYcCW7pp9oNZYiYH0D/lhYSL/9ew5Ws8vo7X7iBJ4hElOBFRbbwWEhj6wGsi2eo+1f3yc5jdbUh3ppC0Q=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzf+68tp+iA7L6aKdRd1GkFqeTsWgMLAree02A3sYs39rJMcGSB
	lRhrw5Caq6QnR6v8WGlgTCUsEx3g5FPb441YU8j+3nxkY2dHkIsrPhmwcjjF08BzHvU=
X-Gm-Gg: ASbGncuewB5te7ZPqENEJpUI1Mvh8NtCgx9yD+A24fhBcPoSNfFkbL+tAddKuYR12GK
	M0K0HP8M+cRNTrf+8CmrspcRLgf8jI/J56IuXDnHoWzm/96zrshAiPYirtLzLdjNy1ZzFObBQar
	+/PqLUUD+cNGfwq8AuB7Z3pwIBTZ2DF/zWgXaA0O1fQ5CN19jktEKAB15LEJ+VlgllGqzhMroY0
	ntpRFdtOzSfaA9Z+INTqFP/kHNml33VM44rBknH+V0hL7i9i9Aw0Q9X2aPvQ+grzD7RpOV6f9Dj
	CSUK0ulDtBv0XYbIxb61A0mEgz9SA5kDq5XVjDm/HX1NXYcWn7MSZnnFcNX9LKs7xYWTl1jUojP
	Gy4ldTG2jTVrgcd4VTyO+QYazwF8=
X-Google-Smtp-Source: AGHT+IG6VRMIM+zUTo/aiJ7hnDlIwiyveHuxH3f+2ryO9hMC++NxXCn64Cu/4aNo0aUF/q0i5WJJwQ==
X-Received: by 2002:a05:6000:430c:b0:3a3:598f:5a97 with SMTP id ffacd0b85a97d-3a6e71c5b60mr2332889f8f.9.1750766225275;
        Tue, 24 Jun 2025 04:57:05 -0700 (PDT)
Message-ID: 
Date: Tue, 24 Jun 2025 12:57:04 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen/efi: Do not undefine not defined macro
To: Frediano Ziglio ,
 xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , Jan Beulich 
References: <20250624114529.34743-1-frediano.ziglio@cloud.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: <20250624114529.34743-1-frediano.ziglio@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 24/06/2025 12:45 pm, Frediano Ziglio wrote:
> The "buffer" macro is not defined.
>
> Fixes: 59e087bf6a9c ("xen/keyhandler: Drop keyhandler_scratch")
> Signed-off-by: Frediano Ziglio 
> Acked-by: Marek Marczykowski-Górecki 

While correct, the grammar isn't great.  I'd suggest "Drop stale #undef
buffer" for the subject, and "The "buffer" macro was removed when
keyhandler_scratch was removed."

Can fix on commit.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 11:59:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 11:59:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023626.1399624 (Exim 4.92)
	(envelope-from )
	id 1uU2JN-0004yU-Vi; Tue, 24 Jun 2025 11:59:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023626.1399624; Tue, 24 Jun 2025 11:59:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uU2JN-0004yN-S7; Tue, 24 Jun 2025 11:59:37 +0000
Received: by outflank-mailman (input) for mailman id 1023626;
 Tue, 24 Jun 2025 11: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 1uU2JM-0004yG-Tv
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 11:59:36 +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 b21193d3-50f2-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 13:59:36 +0200 (CEST)
Received: by mail-oa1-x2b.google.com with SMTP id
 586e51a60fabf-2cc89c59cc0so3136337fac.0
 for ; Tue, 24 Jun 2025 04:59:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b21193d3-50f2-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750766374; x=1751371174; 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=c0EpDBayDeBmUFPy+lsJUQFC0eABLtkCz5XhW10E+w0=;
        b=cdww+XC7g3mnq2DQjoT00KY5WGvCGnnyXEv0vGovj6Xm42OJAMKXYmaHym3VBK1Taq
         eWvam6EeTbmuHrnT7x4wIMPJX/n+OgUhQiwzSDOCJbp4DM082+vMPOInyxxyeJ5JT8MD
         QNCkmKDMsXaY4ypBMI4fjpCHRRgZC5sKLZC7c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750766374; x=1751371174;
        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=c0EpDBayDeBmUFPy+lsJUQFC0eABLtkCz5XhW10E+w0=;
        b=oLnrJLNuW3iKArq98qKv4/803ej8U3v23CTDkXEE/jqKlhx0CgJ3q/juyAbZ3O9vMy
         uYg8Dui7KUjiMEc46HWvvrnSnkzvfhXAnFTnOSRDnGAjFlxE+oLbqio/QWCp1RgsJ/hP
         m6rBk9qao8SGhk/r9M1ftjMbos6P1GNc6MsvKMNEEWnpyTbEwH8GdrT5Yc42/rZFna3P
         QLEaRkH59hQaMoO0FFsM5E4AvymV23MAtHW2z3DzU393VvGgzT65KoF6USuJb/xcbbCw
         BQEdPXGuPzIVxWSa+ruNEO/uxUi+mdTnimQcXRBMXxBgTJayRt/U7hRc9EhzjKkIB/L0
         Wrvg==
X-Gm-Message-State: AOJu0Yy9X6QZb6Hove3pdGu1ZrAWqPCTAOSwP3ouPA1pClCeaNpxkKag
	uhobyNqpPZAt8zhNKqwU37SRJImjmF7k71/wz5RwwxbKip54gCv0C9wzPV9WBym6zW5Qq90N1hb
	eSLD9vRszgjHt8TK6XuX6eObJGpXixK8iWIg7f/43Yw==
X-Gm-Gg: ASbGncuePUtr9z2YlmTiYoJpdNP8V6/PLCaF88huvgbKPJup574Ce15htDfqXsT67yH
	d1DmJqD7UYaPlEruNvbESTnyKq8pGv8UHnMs7UgwGZOzoziBYY2+nWyf7WsG/tUhilHsQGD7AOH
	uqtS3GefO3/fEayA1ZXT0zqsHhLSjFcuvEduoyjivA
X-Google-Smtp-Source: AGHT+IHj9Ex7rriEsYL7OpPSmQZPVWo4Y3/5pVE4q0bS2KGriGBFcJ054FLkn8Ix28Y6w0tx3NhkX2zbUaWBMJJvt8Q=
X-Received: by 2002:a05:6870:9494:b0:2b8:b76f:1196 with SMTP id
 586e51a60fabf-2ef95cf11bemr1780199fac.19.1750766374285; Tue, 24 Jun 2025
 04:59:34 -0700 (PDT)
MIME-Version: 1.0
References: <20250624114529.34743-1-frediano.ziglio@cloud.com> 
In-Reply-To: 
From: Frediano Ziglio 
Date: Tue, 24 Jun 2025 12:59:18 +0100
X-Gm-Features: AX0GCFvaheXfcx4MEt-6l7qljf7RbioszY3m-5LHlPwPIGFZVIrWIM7Nw9da1Pc
Message-ID: 
Subject: Re: [PATCH v2] xen/efi: Do not undefine not defined macro
To: Andrew Cooper 
Cc: xen-devel@lists.xenproject.org, 
	"Daniel P. Smith" , 
	=?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= , 
	Jan Beulich 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 24, 2025 at 12:57=E2=80=AFPM Andrew Cooper
 wrote:
>
> On 24/06/2025 12:45 pm, Frediano Ziglio wrote:
> > The "buffer" macro is not defined.
> >
> > Fixes: 59e087bf6a9c ("xen/keyhandler: Drop keyhandler_scratch")
> > Signed-off-by: Frediano Ziglio 
> > Acked-by: Marek Marczykowski-G=C3=B3recki 
>
> While correct, the grammar isn't great.  I'd suggest "Drop stale #undef
> buffer" for the subject, and "The "buffer" macro was removed when
> keyhandler_scratch was removed."
>

Fine for me.
Not sure about the acknowledgement.

> Can fix on commit.
>
> ~Andrew

Frediano


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 12:38:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 12:38:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023637.1399633 (Exim 4.92)
	(envelope-from )
	id 1uU2v3-00028A-Sc; Tue, 24 Jun 2025 12:38:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023637.1399633; Tue, 24 Jun 2025 12:38: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 1uU2v3-000283-Q0; Tue, 24 Jun 2025 12:38:33 +0000
Received: by outflank-mailman (input) for mailman id 1023637;
 Tue, 24 Jun 2025 12:38: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 1uU2v2-00027x-6z
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 12:38:32 +0000
Received: from fhigh-b5-smtp.messagingengine.com
 (fhigh-b5-smtp.messagingengine.com [202.12.124.156])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 218ffeb2-50f8-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 14:38:30 +0200 (CEST)
Received: from phl-compute-05.internal (phl-compute-05.phl.internal
 [10.202.2.45])
 by mailfhigh.stl.internal (Postfix) with ESMTP id AAE3D7A0136;
 Tue, 24 Jun 2025 08:38:28 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-05.internal (MEProxy); Tue, 24 Jun 2025 08:38:28 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 24 Jun 2025 08:38:26 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 218ffeb2-50f8-11f0-a30f-13f23c93f187
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=1750768708;
	 x=1750855108; bh=JgxsKQcCxG7jaWZi5t/3ZSbAPgDnmVw9S0ZC4z0+eEg=; b=
	JMyc9pIYgVPAZQ3YizG3QrDH83bj71R6gavq3TgaNfN3gKcQ/ULisk3TCuisjDJf
	9L2SitgE6P+lhp8d7S47JvZbiqDBNJ5cTQCt5r25YHxqZDjPnBi4P257JgldXKOR
	s+TS8CQ4HHJp+13AlrD41xLGnPZr8zzYIvOX5vfV1PMqGPkFnMrNw0e9EUnamqtX
	Io6ej7YWSt+R/m1iHllvuRUWjUMicWt86/t2WCAJ+PavlI2ra47ycDN/tLcqb9vD
	6s0ZkNBOEufQDQAh3Ln8W2Ii2fpPElAM8K8wvzlKwJXwKoEC29pnYfGjNi7DqKlj
	aqTZrLo+2YF+pld2OwZKhg==
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=
	1750768708; x=1750855108; bh=JgxsKQcCxG7jaWZi5t/3ZSbAPgDnmVw9S0Z
	C4z0+eEg=; b=h1ezKYW1ehowNNWix6MML1FHj/XsvuXjwPmmnQJ4oVrj3aVRvMh
	eX9XfN3iDtFoDVETzIqYo83x93tUnkxmYQdlPrex7pHDOKsGR9hHfv26w0Sfeygb
	FLpyZTcwkz5sJo/hBfEbGw1gg1nl4vIFp2580QbEMxvP/GU/G93vC1xritkl+VGa
	QxeAbhiTJG3Ynab9+14XgKP7+5DzsqRvnxgSTBdxnYe1Mo9c15Z3LFJSQeFTOet2
	HGjCSdwHcrh6tBaW9bvQhs78of6Sx89t6h8G0pBkupetH2tmNmapQqqjMf4r45Kx
	tskhMVa8YPukSDgyiMcW8XCLEU5gSW5W3fg==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgdduleeludcutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghkucfo
    rghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhish
    hisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefgudelteef
    vefhfeehieetleeihfejhfeludevteetkeevtedtvdegueetfeejudenucevlhhushhtvg
    hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhn
    vhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopeegpdhmoh
    guvgepshhmthhpohhuthdprhgtphhtthhopehfrhgvughirghnohdriihighhlihhosegt
    lhhouhgurdgtohhmpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnh
    hprhhojhgvtghtrdhorhhgpdhrtghpthhtohepughpshhmihhthhesrghpvghrthhushhs
    ohhluhhtihhonhhsrdgtohhmpdhrtghpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtg
    homh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Tue, 24 Jun 2025 14:38:25 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Frediano Ziglio 
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" ,
	Jan Beulich 
Subject: Re: [PATCH 1/2] xen/efi: Handle cases where file didn't come from ESP
Message-ID: 
References: <20250624083157.9334-1-frediano.ziglio@cloud.com>
 <20250624083157.9334-2-frediano.ziglio@cloud.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="wCYRVLT9hZdC2Cuv"
Content-Disposition: inline
In-Reply-To: <20250624083157.9334-2-frediano.ziglio@cloud.com>


--wCYRVLT9hZdC2Cuv
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 24 Jun 2025 14:38:25 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Frediano Ziglio 
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" ,
	Jan Beulich 
Subject: Re: [PATCH 1/2] xen/efi: Handle cases where file didn't come from ESP

On Tue, Jun 24, 2025 at 09:31:54AM +0100, Frediano Ziglio wrote:
> A boot loader can load files from outside ESP.
> In these cases device could be not provided or path could
> be something not supported.
> In these cases allows to boot anyway, all information
> could be provided using UKI or using other boot loader
> features.
>=20
> Signed-off-by: Frediano Ziglio 
> ---
>  xen/common/efi/boot.c | 27 +++++++++++++++++++++++++--
>  1 file changed, 25 insertions(+), 2 deletions(-)
>=20
> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> index 1a9b4e7dae..2a49c6d05d 100644
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -443,6 +443,18 @@ static EFI_FILE_HANDLE __init get_parent_handle(cons=
t EFI_LOADED_IMAGE *loaded_i
>      CHAR16 *pathend, *ptr;
>      EFI_STATUS ret;
> =20
> +    /*
> +     * In some cases the image could not come from a specific device.
> +     * For instance this can happen if Xen was loaded using GRUB2 "linux"
> +     * command.
> +     */
> +    *leaf =3D buffer;

This feels wrong, if DeviceHandle is NULL, it will point at the
empty buffer that shouldn't really be used for anything anyway.

IMO a better option would be to add "&& dir_handle" to the condition
guarding use of file_name in efi_start() instead.

BTW, by my reading of get_parent_handle() theoretically it should be
possible to get _some_ name out of loaded_image->FilePath even without
dir_handle. But since it isn't going to be used, it's not worth it.

> +    if ( !loaded_image->DeviceHandle )
> +    {
> +        PrintStr(L"Xen image loaded without providing a device\r\n");
> +        return NULL;
> +    }
> +
>      do {
>          EFI_FILE_IO_INTERFACE *fio;
> =20
> @@ -466,7 +478,15 @@ static EFI_FILE_HANDLE __init get_parent_handle(cons=
t EFI_LOADED_IMAGE *loaded_i
> =20
>          if ( DevicePathType(dp) !=3D MEDIA_DEVICE_PATH ||
>               DevicePathSubType(dp) !=3D MEDIA_FILEPATH_DP )
> -            blexit(L"Unsupported device path component");
> +        {
> +            /*
> +             * The image could come from an unsupported device.
> +             * For instance this can happen if Xen was loaded using GRUB2
> +             * "chainloader" command and the file was not from ESP.
> +             */
> +            PrintStr(L"Unsupported device path component\r\n");
> +            return NULL;
> +        }
> =20
>          if ( *buffer )
>          {
> @@ -772,6 +792,8 @@ static bool __init read_file(EFI_FILE_HANDLE dir_hand=
le, CHAR16 *name,
> =20
>      if ( !name )
>          PrintErrMesg(L"No filename", EFI_OUT_OF_RESOURCES);
> +    if ( !dir_handle )
> +        return false;

There are a lot of places where read_file() is used without checking its
return value. Which made sense since before this change the only cases
where read_file() would return false was for the config file, in all
other cases it handled errors via blexit().
Most of those read_file() calls seems to be fine (as in, will not
explode), but may still be confusing. For example when you embed a
config with "xsm=3Dpolicy" (but the actual policy is not embedded) now the
failure to load it will result just a warning ("Xen image loaded without
providing a device") not even related to the file name and it will
continue booting with unintended configuration.

For me it looks like this change is wrong: if the config specified a
file to load (and that blob was not embedded in the UKI), and yet it
couldn't be loaded, it should fail early.
Is there any (new) case where where read_file() failure (when it
actually gets to calling it) should really be non-fatal now?=20

In relation to the next patch - such UKI should simply not specify
ramdisk in the embedded config, to allow loading it via "initrd"
command. This would avoid calling read_file().

>      ret =3D dir_handle->Open(dir_handle, &FileHandle, name,
>                             EFI_FILE_MODE_READ, 0);
>      if ( file =3D=3D &cfg && ret =3D=3D EFI_NOT_FOUND )
> @@ -1515,7 +1537,8 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE Im=
ageHandle,
>          efi_bs->FreePages(cfg.addr, PFN_UP(cfg.size));
>          cfg.addr =3D 0;
> =20
> -        dir_handle->Close(dir_handle);
> +        if ( dir_handle )
> +            dir_handle->Close(dir_handle);
> =20
>          if ( gop && !base_video )
>          {
> --=20
> 2.43.0
>=20

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

--wCYRVLT9hZdC2Cuv
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmhanEEACgkQ24/THMrX
1ywPMAf+LxMKXIHh06rw2WDwIA+RrXaRNH7zqa3LONZ9p0W1a8cueVCt51bSljz7
89HzyIIJJB+1C8GuNNEF/8uUXpkrBiGz9Vf3qXBBqxoXInRndVRMQox1FEpLg6oZ
TmmLJ3rnPHU3LBrgzQt5YpDHcS0LtZ4Ogl+gs3daxe2y6u82QR1dGC/xa/lL7xxX
lgOAcAoKw9eG2kz3tGzNpVYk5VWv7gJADKXrInGBZsLr47u0UoHAVw0A12Wk1iYz
W60X94IouEOafE1h6K6l8kW315JbQn+7lELnnpEL9kK6OedDlI6EM8+pfz3BQ3yA
LcFntC3rm4xuOzbXfh70vKSEG9quKw==
=CNHA
-----END PGP SIGNATURE-----

--wCYRVLT9hZdC2Cuv--


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 12:46:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 12:46:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023650.1399668 (Exim 4.92)
	(envelope-from )
	id 1uU32y-00045j-S0; Tue, 24 Jun 2025 12:46:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023650.1399668; Tue, 24 Jun 2025 12:46:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uU32y-00045c-PR; Tue, 24 Jun 2025 12:46:44 +0000
Received: by outflank-mailman (input) for mailman id 1023650;
 Tue, 24 Jun 2025 12:46: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 1uU32x-00045W-QO
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 12:46:43 +0000
Received: from fhigh-b5-smtp.messagingengine.com
 (fhigh-b5-smtp.messagingengine.com [202.12.124.156])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 473eafe6-50f9-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 14:46:42 +0200 (CEST)
Received: from phl-compute-01.internal (phl-compute-01.phl.internal
 [10.202.2.41])
 by mailfhigh.stl.internal (Postfix) with ESMTP id 5B3617A0136;
 Tue, 24 Jun 2025 08:46:41 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-01.internal (MEProxy); Tue, 24 Jun 2025 08:46:41 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 24 Jun 2025 08:46:39 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 473eafe6-50f9-11f0-a30f-13f23c93f187
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=1750769201;
	 x=1750855601; bh=VX9e5XC3c5rl9CNnxhACIxF0/jLrmMLiHD41lh7PGlQ=; b=
	Yh1+ih8BY/V9K1lsZ6jZizID1JtmQODAH8AKL0d7R1niqzy49+eAmBNZceW9MCf4
	YSFM4ZvWZTfJEERTUt2OWGm5wcA5gBLgmDvBcXuqf/30HEPdHzrIQpC0g1JVhIWp
	Wb9L0SAXorECieMsSS3cscnbFpAfrpzvBxjfmJjxw2148jLwlTjZRYFMssFosorz
	xLCxmkiDSozjwK9+XxPPZ5Rycg2/LsId55Pb0bGmgzbhFxI7QYOQzvZiiabxozu+
	CAzFSzKRX3xTgmSD6t/+pcHGHNH764XjJx4q/Ur6rsOVyJvJARM7W3EKdTQ0iYNf
	mDODcnGU0hEF/Xzyx1BHPw==
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=
	1750769201; x=1750855601; bh=VX9e5XC3c5rl9CNnxhACIxF0/jLrmMLiHD4
	1lh7PGlQ=; b=jWfetVvk8ANPW5iKcS0nDZkYnMJWL0c87slMe+JIKUL+NgfnPUZ
	hzWXdWwhdUdJc9yXP6pL7KtsxmOKChv0gpkGhRz9yvRrEtQvAFMFphEqxjBR5yub
	8vpJIyN+ZE8KYQeWBF4uPZ5aKNiZA8F0eQHduazLLKCZ61fvyer1Niql02EWqNek
	SD9PfCM/g+m2Ns6xLSGYk6VCYezOqJ/w93w55eU2O8+fXBoTCE0CaODMHpjLsSuy
	DuIpDwiMyWH5knOnrkRM+PojYYZnaZsORWaXnZGarvnG9Rvy6zOie9stJRevjx70
	I/IhZbF4WSrwrTIsDfvRXASfXt0yqfvomHg==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgdduleelfecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghkucfo
    rghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhish
    hisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefgudelteef
    vefhfeehieetleeihfejhfeludevteetkeevtedtvdegueetfeejudenucevlhhushhtvg
    hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhn
    vhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopeegpdhmoh
    guvgepshhmthhpohhuthdprhgtphhtthhopehfrhgvughirghnohdriihighhlihhosegt
    lhhouhgurdgtohhmpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnh
    hprhhojhgvtghtrdhorhhgpdhrtghpthhtohepughpshhmihhthhesrghpvghrthhushhs
    ohhluhhtihhonhhsrdgtohhmpdhrtghpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtg
    homh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Tue, 24 Jun 2025 14:46:37 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Frediano Ziglio 
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" ,
	Jan Beulich 
Subject: Re: [PATCH 2/2] xen/efi: Support loading initrd using GRUB2
 LoadFile2 protocol
Message-ID: 
References: <20250624083157.9334-1-frediano.ziglio@cloud.com>
 <20250624083157.9334-3-frediano.ziglio@cloud.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="VHZAk3GJEJ7l8I77"
Content-Disposition: inline
In-Reply-To: <20250624083157.9334-3-frediano.ziglio@cloud.com>


--VHZAk3GJEJ7l8I77
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 24 Jun 2025 14:46:37 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Frediano Ziglio 
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" ,
	Jan Beulich 
Subject: Re: [PATCH 2/2] xen/efi: Support loading initrd using GRUB2
 LoadFile2 protocol

On Tue, Jun 24, 2025 at 09:31:55AM +0100, Frediano Ziglio wrote:
> Allows to load Xen using "linux" and "initrd" GRUB2 commands.
> This can be used with UKI to separate initrd in a different module
> instead of bundling all together.
> Bundling all together can be a problem with Secure Boot where
> we need to sign the bundle making harder to change it.
> As initrd content does not need to be signed for Secure Boot
> bundling it force it to be signed too.
>=20
> Signed-off-by: Frediano Ziglio 
> ---
>  xen/common/efi/boot.c     | 71 ++++++++++++++++++++++++++++++++++++++-
>  xen/include/efi/efidevp.h | 21 ++++++++++++
>  2 files changed, 91 insertions(+), 1 deletion(-)
>=20
> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> index 2a49c6d05d..87eb8bb8ae 100644
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -849,6 +849,74 @@ static bool __init read_file(EFI_FILE_HANDLE dir_han=
dle, CHAR16 *name,
>      return true;
>  }
> =20
> +#pragma pack(1)
> +typedef struct {
> +    VENDOR_DEVICE_PATH              VenMediaNode;
> +    EFI_DEVICE_PATH                 EndNode;
> +} SINGLE_NODE_VENDOR_MEDIA_DEVPATH;
> +#pragma pack()
> +
> +static bool __init initrd_load_file2(const CHAR16 *name, struct file *fi=
le)

This function I haven't tested yet, but it looks okay I think.

> +{
> +    static const SINGLE_NODE_VENDOR_MEDIA_DEVPATH __initconst initrd_dev=
_path =3D {
> +        {
> +            {
> +                MEDIA_DEVICE_PATH, MEDIA_VENDOR_DP, { sizeof (VENDOR_DEV=
ICE_PATH) }
> +            },
> +            LINUX_EFI_INITRD_MEDIA_GUID
> +        },
> +        {
> +            END_DEVICE_PATH_TYPE, END_ENTIRE_DEVICE_PATH_SUBTYPE,
> +            { sizeof (EFI_DEVICE_PATH) }
> +        }
> +    };
> +    static EFI_GUID __initdata lf2_proto_guid =3D EFI_LOAD_FILE2_PROTOCO=
L_GUID;
> +    EFI_DEVICE_PATH *dp;
> +    EFI_LOAD_FILE2_PROTOCOL *lf2;
> +    EFI_HANDLE handle;
> +    EFI_STATUS ret;
> +    UINTN size;
> +
> +    dp =3D (EFI_DEVICE_PATH *)&initrd_dev_path;
> +    ret =3D efi_bs->LocateDevicePath(&lf2_proto_guid, &dp, &handle);
> +    if ( EFI_ERROR(ret) )
> +    {
> +        if ( ret =3D=3D EFI_NOT_FOUND)
> +            return false;
> +        PrintErrMesg(L"Error getting file with LoadFile2 interface", ret=
);
> +    }
> +
> +    ret =3D efi_bs->HandleProtocol(handle, &lf2_proto_guid, (void **)&lf=
2);
> +    if ( EFI_ERROR(ret) )
> +        PrintErrMesg(L"LoadFile2 file does not provide correct protocol"=
, ret);
> +
> +    size =3D 0;
> +    ret =3D lf2->LoadFile(lf2, dp, false, &size, NULL);
> +    if ( ret !=3D EFI_BUFFER_TOO_SMALL )
> +        PrintErrMesg(L"Loading failed", ret);
> +
> +    file->addr =3D min(1UL << (32 + PAGE_SHIFT),
> +                     HYPERVISOR_VIRT_END - DIRECTMAP_VIRT_START);
> +    ret =3D efi_bs->AllocatePages(AllocateMaxAddress, EfiLoaderData,
> +                                PFN_UP(size), &file->addr);
> +    if ( EFI_ERROR(ret) )
> +        PrintErrMesg(L"Allocation failed", ret);
> +
> +    file->need_to_free =3D true;
> +    file->size =3D size;
> +
> +    ret =3D lf2->LoadFile(lf2, dp, false, &size, file->str);
> +    if ( EFI_ERROR(ret) )
> +    {
> +        efi_bs->FreePages(file->addr, PFN_UP(size));
> +        PrintErrMesg(L"Loading failed", ret);
> +    }
> +
> +    efi_arch_handle_module(file, name, NULL);
> +
> +    return true;
> +}
> +
>  static bool __init read_section(const EFI_LOADED_IMAGE *image,
>                                  const CHAR16 *name, struct file *file,
>                                  const char *options)
> @@ -1492,7 +1560,8 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE Im=
ageHandle,
>              kernel_verified =3D true;
>          }
> =20
> -        if ( !read_section(loaded_image, L"ramdisk", &ramdisk, NULL) )
> +        if ( !initrd_load_file2(L"ramdisk", &ramdisk) &&
> +             !read_section(loaded_image, L"ramdisk", &ramdisk, NULL) )

Unverified initrd loaded by the bootloader should _not_ take precedence
over embedded (signed) one - if whoever decided to bundle initrd into
UKI and sign it this way, that choice should be respected. The order of
conditions should be reversed here.

>          {
>              name.s =3D get_value(&cfg, section.s, "ramdisk");
>              if ( name.s )
> diff --git a/xen/include/efi/efidevp.h b/xen/include/efi/efidevp.h
> index beb5785a45..b240c15d2a 100644
> --- a/xen/include/efi/efidevp.h
> +++ b/xen/include/efi/efidevp.h
> @@ -398,5 +398,26 @@ typedef union {
> =20
>  } EFI_DEV_PATH_PTR;
> =20
> +#define EFI_LOAD_FILE2_PROTOCOL_GUID \
> +    { 0x4006c0c1, 0xfcb3, 0x403e, {0x99, 0x6d, 0x4a, 0x6c, 0x87, 0x24, 0=
xe0, 0x6d } }
> +
> +typedef struct EFI_LOAD_FILE2_PROTOCOL EFI_LOAD_FILE2_PROTOCOL;
> +
> +typedef
> +EFI_STATUS
> +(EFIAPI *EFI_LOAD_FILE2)(
> +    IN EFI_LOAD_FILE2_PROTOCOL      *This,
> +    IN EFI_DEVICE_PATH              *FilePath,
> +    IN BOOLEAN                      BootPolicy,
> +    IN OUT UINTN                    *BufferSize,
> +    IN VOID                         *Buffer OPTIONAL
> +    );
> +
> +struct EFI_LOAD_FILE2_PROTOCOL {
> +    EFI_LOAD_FILE2                  LoadFile;
> +};
> +
> +#define LINUX_EFI_INITRD_MEDIA_GUID \
> +    { 0x5568e427, 0x68fc, 0x4f3d, {0xac, 0x74, 0xca, 0x55, 0x52, 0x31, 0=
xcc, 0x68} }
> =20
>  #endif
> --=20
> 2.43.0
>=20

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

--VHZAk3GJEJ7l8I77
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmhani4ACgkQ24/THMrX
1yzhJggAjBISiQMSTBJaz207SX38ye/iTuq1k4IZ1Xehj4wqNtuoMamndV4YUD51
pwnhvSej25aOTCilaOCgo3BUV4pDzLYEQcZT1XSFZjeQl8PQhia9sUw15cjX1A5I
nl07tgx+5IhQMVajnn2BpInGuKyfXMGhyyj8DZuh8xSzER0R82NGtKw+5O960F/o
GOdMdGj560K8iDi2/oaU6pGfm0MJCR6tDX2uZNjghn/e33lubd//rI1FZbszQ1Pt
sJ7n9Eq7I0xgrN+X1ydi+SqlndCqHjfEEm95bNzUGXCukdNhbZ+9jOfvPfKycX33
kHiyqLkiCxE0eGrX2sWI+bnFTeVcYA==
=6v4V
-----END PGP SIGNATURE-----

--VHZAk3GJEJ7l8I77--


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 12:47:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 12:47:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023657.1399678 (Exim 4.92)
	(envelope-from )
	id 1uU342-0004aQ-4n; Tue, 24 Jun 2025 12:47:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023657.1399678; Tue, 24 Jun 2025 12:47:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uU342-0004aJ-1w; Tue, 24 Jun 2025 12:47:50 +0000
Received: by outflank-mailman (input) for mailman id 1023657;
 Tue, 24 Jun 2025 12:47: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 1uU340-0004NM-TJ
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 12:47:48 +0000
Received: from fhigh-b5-smtp.messagingengine.com
 (fhigh-b5-smtp.messagingengine.com [202.12.124.156])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6da99e0b-50f9-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 14:47:47 +0200 (CEST)
Received: from phl-compute-11.internal (phl-compute-11.phl.internal
 [10.202.2.51])
 by mailfhigh.stl.internal (Postfix) with ESMTP id 30A827A004A;
 Tue, 24 Jun 2025 08:47:46 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-11.internal (MEProxy); Tue, 24 Jun 2025 08:47:46 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 24 Jun 2025 08:47:44 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6da99e0b-50f9-11f0-b894-0df219b8e170
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=1750769266;
	 x=1750855666; bh=JsjP6RvreMp6FfY4Zo3DVWiWh+YaUroLK9oIyBtzDvM=; b=
	gw6jlosgEQpFK590GUuU6xaqUO1qJSRBreyPPW3d6fjdKMIbBIrKEnV8aVOYsekq
	vizsDhU07AO0D3w1kGIhcJ3ZEFhH7R1K7Y+s8fnxCPNeAcurdRTwxdci+YweKxfb
	ZUl3xyZmWaBb/N+onN3gBrKW9NJdPTuVXEZQjbttVaTpfX4DiVRxlrQoVccMUNVn
	SSbWMbpNoWhJKze8fn2qWfzfCJkzO/v4Bm7qoLBJVsAO0R2OdDbFdrCUDSRkBEce
	RgF4L9ngq5eFZQLpbJ+R8ymocKWM1JhjTcqAyKEZMjwUFes/6Hj6y3Wu34Pz/Hin
	8Pvjq2waEbjmlBr3pAvxKg==
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=
	1750769266; x=1750855666; bh=JsjP6RvreMp6FfY4Zo3DVWiWh+YaUroLK9o
	IyBtzDvM=; b=g7aBWpinfB/4xZh3dH5JoLKAr0a1MN6LqY8pUILGc20tHHnxHKW
	/ld48eX4MJvLh1eopE6ftD38KD0dwV0Z3a9cIt8oqjHdcx31YzwOP9vkRxkXeGMB
	TfO/vL86wXB0Tx3TSMggB8KfuOrfmwKq6iE9YnjA+YJyI57DRM/jI7FfL6b9hZ78
	8jff4vAWAJ7ackiM+Rh4Iv7WxZFvKzCnhoLeB56i4pGw0m2txoUf/w4kCoq/0BYr
	4ACWVCXueS3MD3Mmq46rUf2qH+dggQ3PKM3MsJND/EjCDrM+uOl/YLZ+ew2w9R/T
	xn5VRnT9ngyCMT72dlxvMZjbUw9quST1nLA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgdduleelfecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghkucfo
    rghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhish
    hisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefgudelteef
    vefhfeehieetleeihfejhfeludevteetkeevtedtvdegueetfeejudenucevlhhushhtvg
    hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhn
    vhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopeehpdhmoh
    guvgepshhmthhpohhuthdprhgtphhtthhopehfrhgvughirghnohdriihighhlihhosegt
    lhhouhgurdgtohhmpdhrtghpthhtoheprghnughrvgifrdgtohhophgvrhefsegtihhtrh
    higidrtghomhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhr
    ohhjvggtthdrohhrghdprhgtphhtthhopeguphhsmhhithhhsegrphgvrhhtuhhsshholh
    huthhiohhnshdrtghomhdprhgtphhtthhopehjsggvuhhlihgthhesshhushgvrdgtohhm
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Tue, 24 Jun 2025 14:47:42 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Frediano Ziglio 
Cc: Andrew Cooper ,
	xen-devel@lists.xenproject.org,
	"Daniel P. Smith" ,
	Jan Beulich 
Subject: Re: [PATCH v2] xen/efi: Do not undefine not defined macro
Message-ID: 
References: <20250624114529.34743-1-frediano.ziglio@cloud.com>
 
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="fNIkhp0iry7b3NdU"
Content-Disposition: inline
In-Reply-To: 


--fNIkhp0iry7b3NdU
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 24 Jun 2025 14:47:42 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Frediano Ziglio 
Cc: Andrew Cooper ,
	xen-devel@lists.xenproject.org,
	"Daniel P. Smith" ,
	Jan Beulich 
Subject: Re: [PATCH v2] xen/efi: Do not undefine not defined macro

On Tue, Jun 24, 2025 at 12:59:18PM +0100, Frediano Ziglio wrote:
> On Tue, Jun 24, 2025 at 12:57=E2=80=AFPM Andrew Cooper
>  wrote:
> >
> > On 24/06/2025 12:45 pm, Frediano Ziglio wrote:
> > > The "buffer" macro is not defined.
> > >
> > > Fixes: 59e087bf6a9c ("xen/keyhandler: Drop keyhandler_scratch")
> > > Signed-off-by: Frediano Ziglio 
> > > Acked-by: Marek Marczykowski-G=C3=B3recki 
> >
> > While correct, the grammar isn't great.  I'd suggest "Drop stale #undef
> > buffer" for the subject, and "The "buffer" macro was removed when
> > keyhandler_scratch was removed."
> >
>=20
> Fine for me.

Fine with me too.

> Not sure about the acknowledgement.
>=20
> > Can fix on commit.
> >
> > ~Andrew
>=20
> Frediano

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

--fNIkhp0iry7b3NdU
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmhanm4ACgkQ24/THMrX
1yzIwAf/RQvqWoRVUttYUGXsABFeXwhtpzS0uWEqz7vjHXn9+Kf2aezBSJo8OTgx
OMYHP1O/P+AE0SfAIASjLnHDUcEUOaOqG6W2gkM4JDWlnErzAqscGnMP6K8Shrv2
x1snm4AUmUUmnCQSv4HPr67YCJKvHLlVeA0ztSyx0fwKGd/Xhioo43GW1NtDMD9b
0ryrMfjvKMxywKoqD6Qip2mBgodSC14+wXBVRD0LKoooobhfR62TemhdrhsTMXIO
3H9I85rWSw6ORo+b4oUhN/D3PViw692Lbx2vBG4S0sDorU5RZscQtHLMwC6++0+7
zC2ZUyPuvBF+DHPCKVKvO+xIedTT+A==
=WeZ1
-----END PGP SIGNATURE-----

--fNIkhp0iry7b3NdU--


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 13:05:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 13:05:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023672.1399707 (Exim 4.92)
	(envelope-from )
	id 1uU3L2-0007uQ-QW; Tue, 24 Jun 2025 13:05:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023672.1399707; Tue, 24 Jun 2025 13:05:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uU3L2-0007uJ-Ny; Tue, 24 Jun 2025 13:05:24 +0000
Received: by outflank-mailman (input) for mailman id 1023672;
 Tue, 24 Jun 2025 13:05: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 1uU3L1-0007uD-HO
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 13:05:23 +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 e1fc72d0-50fb-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 15:05:20 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3a4f379662cso4359716f8f.0
 for ; Tue, 24 Jun 2025 06:05:20 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d860fb63sm107607565ad.130.2025.06.24.06.05.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 06:05:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e1fc72d0-50fb-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750770320; x=1751375120; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=e/GW8Eyf0J4TzNxNAzPAx6rpWSQoNir2DhD7+rjfBtA=;
        b=I79eABBfUfBw1WgghotqPPxpr95oIRJgPii1UFANV2H3ydWpiaV0gSu0mCRum7yoSx
         ZvECLlLHiUEM3XDRWuCARPlhl3mpkxWpbukrPneQNibQeLggQOX+NwtOrKKGWUh6fUzV
         enQR1ILg/4jNraPX4IU/gswO15pdpOskzR8gYKi67GqxGbcM5jiSokCsTgluuqQoWh3M
         +yC/9P/SI+rLuSGBg790tA2iNfyfb9pmhA33lVcaSSeHMORSQwpNrCZVbSfXr7pBtbqG
         Jd4SzO2KfBgIWkSKqqLDPWpa0HrG6J3gzQ85FcAIlzP9y5yjoIWjsdd+WIx/3y7RB//d
         9/Cg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750770320; x=1751375120;
        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=e/GW8Eyf0J4TzNxNAzPAx6rpWSQoNir2DhD7+rjfBtA=;
        b=sypeS1Ce6zax2OhU3vlQEc5T10gPHrcZ1REJRKPJ22KjEnPSUV7R6g0OLLAMc8nts6
         DZqk6MjVUGg8KyqZbLZD3g7tUrXNb43jGrESW9OVXDi4TZ2YIs9KNzCLkWgq1jpBHslZ
         YXv2rMmO/bkVaaF0deX9rac3yaO8Tv7eTJAdOro9gGt7z16ApQOO//lh7aeRzpOyzbj2
         7Fv2cuVZsxK25GGrfY7waIIe/yciFTrNIQfmJUuBJwm8t4lQnkLEtwMLcNuwdoob76e+
         Dhn/9YrAmlRya+PK/14K/6q6KrEwzJzrGH5pW7THCMjpo7i8tmegq7Upyo2XUjTGAdAL
         fYIw==
X-Forwarded-Encrypted: i=1; AJvYcCUZLhWl4kVijBxqgehZkb4xaZHR0dSNyDGtvXeVrGCNqzeDxMyWfbisNEZw71QTmkDke/QC2+995lo=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz2I6fMJPXBvIdssSQ1VM1j5xaaE8hZFEiOxEgoI7GQ2balAyVn
	1cbo2h+K/6sdkBZjjGD9lH5thp9+u0QB52TrKcwvhO7hpZeUWEs/byfk2VV6sCsEWRoxEbRDWqZ
	n7UU=
X-Gm-Gg: ASbGncuG92YHKzBgxm/6OWVjNvk0Sdh4U+j0TQXFVut43jP/dEHf3ggM6Fa8bAwmw3r
	naBfUMDF26RStJTV80/TKEMQu7S/FG0TTQYlPjzLQTQYeN7p/0v24Y/L0qRwisj+7lFZ/TtXuoe
	jDCMvD95GGaEpDbcmHk/R4XHCRIkM1nBJas+r7w4Aytv1+eO83bEicZmWV5lF3WCySAl6p23GLe
	WMT/Lyw3y1z4QIeQhbuaBCWpqr2TvAsvNGgeb0fhAtUUO4G/Y9/r4wLWDQTRQ3ok4F5qBOH/IOa
	A7pTaRZalvr+PBEPgieXio94UK/OLiSxfSM9aYFbDn/btnNJplz4aUXg1gdq7G9oARjcJXwa9Zm
	cUEx4dsZybFf5SLsjqcoRC9hKx8t4u2+yrCOgr+JER6HqzpM=
X-Google-Smtp-Source: AGHT+IH6UlcKafrLK8R2lfhg4xkf5ZFKVZbYAhMCffoiFvXbiVKFOyu+wK3GuQiGB13D5Qn9oKeINQ==
X-Received: by 2002:a05:6000:2507:b0:3a4:f038:af74 with SMTP id ffacd0b85a97d-3a6d12ebae4mr12396794f8f.51.1750770319882;
        Tue, 24 Jun 2025 06:05:19 -0700 (PDT)
Message-ID: 
Date: Tue, 24 Jun 2025 15:05:11 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/8] x86/pdx: simplify calculation of domain struct
 allocation boundary
To: Roger Pau Monne 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250620111130.29057-1-roger.pau@citrix.com>
 <20250620111130.29057-2-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: <20250620111130.29057-2-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 20.06.2025 13:11, Roger Pau Monne wrote:
> When not using CONFIG_BIGMEM there are some restrictions in the address
> width for allocations of the domain structure, as it's PDX truncated to 32
> bits it's stashed into page_info structure for domain allocated pages.
> 
> The current logic to calculate this limit is based on the internals of the
> PDX compression used, which is not strictly required.  Instead simplify the
> logic to rely on the existing PDX to PFN conversion helpers used elsewhere.
> 
> This has the added benefit of allowing alternative PDX compression
> algorithms to be implemented without requiring to change the calculation of
> the domain structure allocation boundary.
> 
> As a side effect introduce pdx_to_paddr() conversion macro and use it.
> 
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Jan Beulich 

> @@ -498,14 +474,20 @@ struct domain *alloc_domain_struct(void)
>       * On systems with CONFIG_BIGMEM there's no packing, and so there's no
>       * such restriction.
>       */
> -#if defined(CONFIG_BIGMEM) || !defined(CONFIG_PDX_COMPRESSION)
> -    const unsigned int bits = IS_ENABLED(CONFIG_BIGMEM) ? 0 :
> -                                                          32 + PAGE_SHIFT;
> +#if defined(CONFIG_BIGMEM)
> +    const unsigned int bits = 0;
>  #else
> -    static unsigned int __read_mostly bits;
> +    static unsigned int __ro_after_init bits;
>  
>      if ( unlikely(!bits) )
> -         bits = _domain_struct_bits();
> +         /*
> +          * Get the width for the next pfn, and unconditionally subtract one
> +          * from it to ensure the used width will not allocate past the PDX
> +          * field limit.
> +          */
> +         bits = flsl(pdx_to_paddr(1UL << (sizeof_field(struct page_info,
> +                                                       v.inuse._domain) * 8)))

You didn't like the slightly shorter sizeof(frame_table->v.inuse._domain) then?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 13:13:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 13:13:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023679.1399718 (Exim 4.92)
	(envelope-from )
	id 1uU3T1-0001AJ-KR; Tue, 24 Jun 2025 13:13:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023679.1399718; Tue, 24 Jun 2025 13:13: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 1uU3T1-0001AC-Gl; Tue, 24 Jun 2025 13:13:39 +0000
Received: by outflank-mailman (input) for mailman id 1023679;
 Tue, 24 Jun 2025 13:13: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 1uU3Sz-0001A5-Q3
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 13:13:37 +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 0994087b-50fd-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 15:13:36 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3a575a988f9so292735f8f.0
 for ; Tue, 24 Jun 2025 06:13:36 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-749c882cd07sm1925774b3a.91.2025.06.24.06.13.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 06:13:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0994087b-50fd-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750770816; x=1751375616; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=KI6wTPA9FrUcD9wPw3OdqkghzxDhy0OsQuP83Sb1dwo=;
        b=N9lluWg1svRd/r4ETPZoqkohPztrY06YUId4yLRZATeZGjsSpAaE07Ng5eqhdSIQBK
         Wf8bP3M/BhLDMR6ZS8gBxwTnDmF/9d1ofOAdaEVHUdFoIgs8v1flXBwcl+QEHhUpLTgF
         8Cz0hcIB01M+4kCsg0/vCBDWfEVr5jX+Ys2FNyuQwW9Zn/HbHSMzufOEYXULdgKW+Ftb
         T8Q0anU/BFOyeq9PwhROQKeV9EORKrY3RT+K+jVuTyov6mNhTs0RvxOhUq94zZWaQl8N
         CszQhqakMKlIbY/f8NkpAKHDLq/+bcoeQXBoHDNwKgdogpfmrcVJkPARzc9AvdFbMmBU
         f5Yg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750770816; x=1751375616;
        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=KI6wTPA9FrUcD9wPw3OdqkghzxDhy0OsQuP83Sb1dwo=;
        b=h58YnzEQameWF9jjG51LeCcKZmSSNJie+7PU3zcZrU/uXt1FU4I304eU3+gNFo2tNR
         zpvyJvlVHJ/rAisGBo4rsZwVVlPyGMsmnNNfIL3/zvYTvcWx+Egn28OKTNdbN7UfzjUK
         g0BTCej2pFIPbdcsZQUUPOpq9xDBLH1MCdqmjwgil5Tyiyak20RfXSv9GcHUiW3Xn8PQ
         MLpU6TAzYQEcW2p2ZRSikwWDXKzUuplCiQlbxL73r8ziA8uBUZovQiqpqYcXCCD5WA7o
         Ld6EURiiignA7dqjLYtHxFu6swQk+7cPpJ0316GJIKKq75kF9b7TETT9XnOV4jwdLuok
         qYSQ==
X-Forwarded-Encrypted: i=1; AJvYcCVobrqPN7ebSi1YMHfVAOiLlRf3nbIdSJuM4BK0LJ0J0KIcQSMjqx0tU+YcsiIAkZDai2E257QREyA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwNix/gpqwrblmcqPFXQ/xu6EDz9l0AwZ/8IfD7dkJsSmoYDYC3
	CqmfwgFyput4F+2kdZSg4KTC6ceGVg2jiI0JDyNlCyzeGvAXHjUEFDs17/nmfGkM9A==
X-Gm-Gg: ASbGncstHoHnO1a5+xPDdEvrb2Zi33+eKFKyOzRPPDmOhDvJ504domEAOSlflgwcNx2
	nMeSgG0ZFS9EjL7A1siuwtCCTF8YIIgKOpLvyWQxf5l0MYt/Y9VRlcmjs/FwMHA7Ukpd5cL72Ta
	geDKiVwKhj3mtHt63BPIQ4VelCDBdlhKULabgE5eMqDC929/3jjckz4e3FnKVJl+3XSLihzEkKY
	X8Y08IY+2C14NLQmeV+0P81ARV9V7Np9J7sGOWk2U/TrxWQ9ltOLoyzrcIjnRtMACZWg7FrMXD/
	BbUOXS/jbUgI9lMya061pEUjUWtGQCuugOp9K5x2lx3NMkYkDidBcByUaS0aHhDoFT5INxmhBrh
	QCcuiRIPRhyFk8YstEgK4gf+4vnSxms10uzsxxxPv+3Mw0sw=
X-Google-Smtp-Source: AGHT+IEkkKUT/mSazdN0INAwMCREK8oDfYmFU9fmUey7ACSfRphlCTCqK0d05Hu2pD0PouDQc2IBgQ==
X-Received: by 2002:a05:6000:491d:b0:3a1:f564:cd9d with SMTP id ffacd0b85a97d-3a6d12d92e1mr13156650f8f.36.1750770816076;
        Tue, 24 Jun 2025 06:13:36 -0700 (PDT)
Message-ID: 
Date: Tue, 24 Jun 2025 15:13:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/8] kconfig: turn PDX compression into a choice
To: Roger Pau Monne 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250620111130.29057-1-roger.pau@citrix.com>
 <20250620111130.29057-3-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: <20250620111130.29057-3-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 20.06.2025 13:11, Roger Pau Monne wrote:
> Rename the current CONFIG_PDX_COMPRESSION to CONFIG_PDX_MASK_COMPRESSION,
> and make it part of the PDX compression choice block, in preparation for
> adding further PDX compression algorithms.
> 
> No functional change intended as the PDX compression defaults should still
> be the same for all architectures, however the choice block cannot be
> protected under EXPERT and still have a default choice being
> unconditionally selected.  As a result, the new "PDX (Page inDeX)
> compression" item will be unconditionally visible in Kconfig.

Just to mention it: Afaict there is a functional change, but one I actually
appreciate, at least in part. So far ...

> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -52,9 +52,10 @@ config EVTCHN_FIFO
>  
>  	  If unsure, say Y.
>  
> -config PDX_COMPRESSION
> -	bool "PDX (Page inDeX) compression" if EXPERT && !X86 && !RISCV
> -	default ARM || PPC

... for x86 (and RISC-V) this option couldn't be selected. Whereas ...

> @@ -67,6 +68,17 @@ config PDX_COMPRESSION
>  	  If your platform does not have sparse RAM banks, do not enable PDX
>  	  compression.
>  
> +config PDX_MASK_COMPRESSION
> +	bool "Mask compression"
> +	help
> +	  Compression relying on all RAM addresses sharing a zeroed bit region.

... this option is now available, as the prior !X86 && !RISCV doesn't
re-appear here. (As the description mentions it, that dependency clearly
can't appear on the enclosing choice itself.) Since x86 actually still
should have mask compression implemented properly, that's fine (from my
pov; iirc I even asked that it would have remained available when the
earlier change was done), whereas I think for RISC-V it's not quite right
to offer the option. It also did escape me why the option was made
available for PPC, which I'm pretty sure also lacks the logic to determine
a suitable mask.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 13:32:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 13:32:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023693.1399728 (Exim 4.92)
	(envelope-from )
	id 1uU3lQ-000409-4G; Tue, 24 Jun 2025 13:32:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023693.1399728; Tue, 24 Jun 2025 13:32: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 1uU3lQ-000402-0P; Tue, 24 Jun 2025 13:32:40 +0000
Received: by outflank-mailman (input) for mailman id 1023693;
 Tue, 24 Jun 2025 13:32: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 1uU3lO-0003z2-UV
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 13:32:39 +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 af7f25f8-50ff-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 15:32:34 +0200 (CEST)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-451d6ade159so39941215e9.1
 for ; Tue, 24 Jun 2025 06:32:34 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3159df8354bsm11561933a91.18.2025.06.24.06.32.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 06:32:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: af7f25f8-50ff-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750771953; x=1751376753; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=blhfPWIypShvcGCB6Ww5PN1dp+qPVMDSX21SiT0WU6c=;
        b=PXn0AunYU8M5JWc7vIEmsFAFsq9Wy8d299SXXamYQ/1PTEmIkA5nqjM8ov7evBIgBB
         s7pnY21nWX6jFgeVDaDqKW0dzjWKGkGETjBmLIo0iJf6/z61hBqVyr6ikUwnM+PvZ3l+
         j8ktLHA1zob6JeShVRde/jp6f99bXgHru+vfHmUqehPEeu5F9PwDxwlZlbbxyevZHkEo
         A8A/+5+B6uOZKSh9wVGGkteByFkaHBjDWSdFl416HUzV3hdIhmkAduL9+O1EKjF4AVeV
         1GYHR6S5QhF8CSvTECetW0bc4rJMID42yXFrTssX/ntcXX+gBvbQqhAAC9R/+/OCoscQ
         O+3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750771953; x=1751376753;
        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=blhfPWIypShvcGCB6Ww5PN1dp+qPVMDSX21SiT0WU6c=;
        b=bz+eL5woPTaEmv2M7GQQNKl9BmydqlpQvuutWKQxS6Nn/YeDzSzHtOdSmDWDYevfwx
         tq7wOR2hgt2zUgP75g8/kSG1KDGP+Eg4NWfepz0KrnDWLoa+HT6ddXZ+OKiUyv8SIyiX
         5Gg6n847SMWrabgJSKt1nezPCk61rSl2dEryHlMtGYh1B/HjYKnqlH/REOfQaOR7NE7M
         3Qkp1z4m8i3VOpmnrhlrZOoQzmQlGO4wK4/OfKyLf5ZLD5ZzXiUFDJYfrcl0f3JVpdCS
         soSfrEnAZxlQ+tCKYGU3IWE8VRINDCwzyiHOaqCu2PWzQ7W+jnUe3ZRjtPjgO8danaAZ
         NRuw==
X-Forwarded-Encrypted: i=1; AJvYcCW2k8KG08Cksu9K/glCs2NPaF2HEvFiCvv7YSrKw+gC1SXBFtHOAVXRnJ/homR7O7zsVMS8eGN8wcs=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyjeyc8mX700y+Is4MWZrv/GcTT3dGbOUzxFAfL8Wfb8RviI/rp
	yq/Qat70pCPD1uHdi0EQaD4SfPDhxNQL6CyEqqdhMp0sRN7x2Clr1Id9fekgLNM8Lw==
X-Gm-Gg: ASbGncsIvkjv44+ezC77zvZnfqIjx94RcWQmUdONkBhUXhY+fyV5O2Rk9xXeZQ7V8W/
	oxH8f0+LBvpJ9UO5kGBms72cvd+jdjXXlQv225zfkNFA95nEcYZy9Hvy0B3JOBl9RBUljE90Sn1
	OJ+F+j0LZlwqrJ92cf3hzeuR3tlPJr6HS8i/toVCM54lehe0YaNiuvxkaR0wqm+4QNt7CBrvgBl
	ffP5JF+T6OLvRWrJRGVslCFTqUA0pBm+B//8r7+kTqeN3aFluVik6RHvcS/D2zv22uqdKp3XCE1
	oHfNyf0ojf3zlFTE4lwwlDlNYdoKVANURoEW6Gc0Rj0Aua2+H/UYzwqpxUVemGn/aTAN8a351JS
	AyOAW4bP5wture8Afy0ibnmgH/Iyhn45esEJhS8gGbUCQy4yHHia2lEkZpQ==
X-Google-Smtp-Source: AGHT+IEF8dGR52fbnkmu/7jg+UOfALVhkpxhpmJQGQEVyU12ojT5HyexjzdTqSke27xXKzkZOwcFnA==
X-Received: by 2002:a05:6000:26cc:b0:3a6:d255:7eda with SMTP id ffacd0b85a97d-3a6d25584ddmr12905011f8f.28.1750771953347;
        Tue, 24 Jun 2025 06:32:33 -0700 (PDT)
Message-ID: <1298a33e-b602-4887-86a7-cb69cdaa6311@suse.com>
Date: Tue, 24 Jun 2025 15:32:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/8] pdx: provide a unified set of unit functions
To: Roger Pau Monne 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD , xen-devel@lists.xenproject.org
References: <20250620111130.29057-1-roger.pau@citrix.com>
 <20250620111130.29057-4-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: <20250620111130.29057-4-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 20.06.2025 13:11, Roger Pau Monne wrote:
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -255,6 +255,10 @@ void __init init_pdx(void)
>  {
>      const struct membanks *mem = bootinfo_get_mem();
>      paddr_t bank_start, bank_size, bank_end;
> +    unsigned int bank;
> +
> +    for ( bank = 0 ; bank < mem->nr_banks; bank++ )
> +        pfn_pdx_add_region(mem->bank[bank].start, mem->bank[bank].size);
>  
>      /*
>       * Arm does not have any restrictions on the bits to compress. Pass 0 to
> @@ -263,28 +267,24 @@ void __init init_pdx(void)
>       * If the logic changes in pfn_pdx_hole_setup we might have to
>       * update this function too.
>       */
> -    uint64_t mask = pdx_init_mask(0x0);
> -    int bank;
> +    pfn_pdx_compression_setup(0);
>  
>      for ( bank = 0 ; bank < mem->nr_banks; bank++ )
>      {
> -        bank_start = mem->bank[bank].start;
> -        bank_size = mem->bank[bank].size;
> -
> -        mask |= bank_start | pdx_region_mask(bank_start, bank_size);
> -    }
> -
> -    for ( bank = 0 ; bank < mem->nr_banks; bank++ )
> -    {
> -        bank_start = mem->bank[bank].start;
> -        bank_size = mem->bank[bank].size;
> -
> -        if (~mask & pdx_region_mask(bank_start, bank_size))
> -            mask = 0;
> +        if ( !pdx_is_region_compressible(mem->bank[bank].start,
> +                 PFN_UP(mem->bank[bank].start + mem->bank[bank].size) -
> +                 PFN_DOWN(mem->bank[bank].start)) )

Nit: This, according to my understanding, is an "impossible" style. It wants
to either be

        if ( !pdx_is_region_compressible(
                  mem->bank[bank].start,
                  PFN_UP(mem->bank[bank].start + mem->bank[bank].size) -
                  PFN_DOWN(mem->bank[bank].start)) )

or ...

> +        {
> +            pfn_pdx_compression_reset();
> +            printk(XENLOG_WARNING
> +                   "PFN compression disabled, RAM region [%#" PRIpaddr ", %#"
> +                   PRIpaddr "] not covered\n",
> +                   mem->bank[bank].start,
> +                   mem->bank[bank].start + mem->bank[bank].size - 1);

... like this. But it's not written down anywhere, so I guess I shouldn't
insist.

And then - isn't the use of PFN_UP() and PFN_DOWN() the wrong way round?
Partial pages aren't usable anyway, so the smaller range is what matters
for every individual bank. However, for two contiguous banks (no idea
whether Arm would fold such into a single one, like we do with same-type
E820 regions on x86) this gets more complicated then.

> @@ -299,19 +295,29 @@ void __init srat_parse_regions(paddr_t addr)
>  
>  	/* Set "PXM" as early as feasible. */
>  	numa_fw_nid_name = "PXM";
> -	srat_region_mask = pdx_init_mask(addr);
>  	acpi_table_parse_srat(ACPI_SRAT_TYPE_MEMORY_AFFINITY,
>  			      srat_parse_region, 0);
>  
> -	for (mask = srat_region_mask, i = 0; mask && i < e820.nr_map; i++) {
> +	pfn_pdx_compression_setup(addr);
> +
> +	/* Ensure all RAM ranges in the e820 are covered. */
> +	for (i = 0; i < e820.nr_map; i++) {
>  		if (e820.map[i].type != E820_RAM)
>  			continue;
>  
> -		if (~mask & pdx_region_mask(e820.map[i].addr, e820.map[i].size))
> -			mask = 0;
> +		if (!pdx_is_region_compressible(e820.map[i].addr,
> +		    PFN_UP(e820.map[i].addr + e820.map[i].size) -
> +		    PFN_DOWN(e820.map[i].addr)))

Indentation is off here in any event, i.e. irrespective of my earlier
remark.

> --- a/xen/common/pdx.c
> +++ b/xen/common/pdx.c
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  /**
> @@ -55,6 +56,44 @@ void set_pdx_range(unsigned long smfn, unsigned long emfn)
>          __set_bit(idx, pdx_group_valid);
>  }
>  
> +#ifndef CONFIG_PDX_NONE
> +
> +#ifdef CONFIG_X86
> +# include 
> +# define MAX_PFN_RANGES E820MAX
> +#elif defined(CONFIG_HAS_DEVICE_TREE)
> +# include 
> +# define MAX_PFN_RANGES NR_MEM_BANKS
> +#endif
> +
> +#ifndef MAX_PFN_RANGES
> +# error "Missing architecture maximum number of RAM ranges"
> +#endif
> +
> +/* Generic PFN compression helpers. */
> +static struct pfn_range {
> +    unsigned long base, size;
> +} ranges[MAX_PFN_RANGES] __initdata;
> +static unsigned int __initdata nr_ranges;
> +
> +void __init pfn_pdx_add_region(paddr_t base, paddr_t size)
> +{
> +    if ( !size )
> +        return;
> +
> +    if ( nr_ranges >= ARRAY_SIZE(ranges) )
> +    {
> +        ASSERT((nr_ranges + 1) > nr_ranges);

This looks overly pessimistic to me. (I won't outright insist on its removal,
though.)

> +        nr_ranges++;

This requires pretty careful use of the variable as an upper bound of loops.
It's fine in pfn_pdx_compression_setup(), but it feels a little risky.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 13:37:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 13:37:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023702.1399738 (Exim 4.92)
	(envelope-from )
	id 1uU3qE-0004ZR-Ky; Tue, 24 Jun 2025 13:37:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023702.1399738; Tue, 24 Jun 2025 13:37:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uU3qE-0004ZK-H8; Tue, 24 Jun 2025 13:37:38 +0000
Received: by outflank-mailman (input) for mailman id 1023702;
 Tue, 24 Jun 2025 13:37:37 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uU3qD-0004ZE-6q
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 13:37:37 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uU3qC-000Krh-1g;
 Tue, 24 Jun 2025 13:37:36 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (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 1uU3qC-00H5np-0i;
 Tue, 24 Jun 2025 13:37: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=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date;
	bh=u0CZyf0YGFc8E3hpfxNE9Am/YLC1bZu/7k6uh5EdQMg=; b=D6BJGTDjiDCbz32IZQaH3jqIpJ
	PYAAh5cWNBt4VXkt43hLZyI2Nwv2q4h8wrKeQWQsmZSWUDJbFjVNc0zlNedAgQE8+jHFCcp/zhIqF
	XPn8zhcr58ewfj8vA36n8E0UukPwD6TWt+UmM+v9HrEG7Ot2UUihv/rX8lfD34SoZYyg=;
Date: Tue, 24 Jun 2025 15:37:34 +0200
From: Anthony PERARD 
To: Roger Pau Monne 
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v2 6/8] test/pdx: add PDX compression unit tests
Message-ID: 
References: <20250620111130.29057-1-roger.pau@citrix.com>
 <20250620111130.29057-7-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250620111130.29057-7-roger.pau@citrix.com>

On Fri, Jun 20, 2025 at 01:11:28PM +0200, Roger Pau Monne wrote:
> +.PHONY: run
> +run: $(TARGETS)
> +ifeq ($(CC),$(HOSTCC))
> +	for test in $? ; do \
> +		./$$test ;  \
> +	done

You need to add `set -e` or the exit value from the tested binary might
be ignored. This `run` target only failed if the last test binary return
a failure.

> +else
> +	$(warning HOSTCC != CC, will not run test)
> +endif
> +
> +.PHONY: clean
> +clean:
> +	$(RM) -- *.o $(TARGETS) $(DEPS_RM) pdx.c pdx.h

Is this "pdx.c" left over from version? It doesn't seems to be generated
by this makefile.

> +
> +pdx.h: $(XEN_ROOT)/xen/include/xen/pdx.h
> +	sed -E -e '/^#[[:space:]]?include/d' <$< >$@

Why allow only zero or one space characters between '#' and
"include"? Why not used '*' instead of '?' ?


Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 13:40:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 13:40:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023712.1399748 (Exim 4.92)
	(envelope-from )
	id 1uU3sz-00067K-3z; Tue, 24 Jun 2025 13:40:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023712.1399748; Tue, 24 Jun 2025 13:40:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uU3sz-00067D-1J; Tue, 24 Jun 2025 13:40:29 +0000
Received: by outflank-mailman (input) for mailman id 1023712;
 Tue, 24 Jun 2025 13:40: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 1uU3sx-000677-RM
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 13:40: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 c92c7efd-5100-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 15:40:27 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3a6e2d85705so300678f8f.0
 for ; Tue, 24 Jun 2025 06:40:26 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-749b5e099e1sm1940517b3a.12.2025.06.24.06.40.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 06:40:25 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c92c7efd-5100-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750772426; x=1751377226; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=P4W8EzzMsYXIxMULGqXve/loefSjiI4D8JGjlFBJPCw=;
        b=JvgKo05Z07Nn4cYu46XpXhpiL5NYx5/3b3LEWokHoydmONZBf1NLcpnRjpDTvU/Ydg
         5ht4oV+mA2bQ+cKKQM4r4jMsDK7vw3r5HJrvwJkzxph2xRPFTt88c5xkTFeb9GF4QZfq
         IvEheRi5AbHhJabPyPq/4kb5UYIiNwvkR/ET8CzTqjkxzW/eT8J3jQ0csqh+wy4kM3QK
         YWhPGFISBvNti/We76s/dERhOsOCo+B7/uzMajhq2i9P7IZ4x4ZsOq/6Lx7iDhMbnLGE
         EqTkemxMlFeQADdYw5oRcanCxR9wMDZunqhygQi5i+5nhXZKphAzWwC02fTTLm/QtNCn
         qNmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750772426; x=1751377226;
        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=P4W8EzzMsYXIxMULGqXve/loefSjiI4D8JGjlFBJPCw=;
        b=TiyvX3+j4nh+lp+S6TTN5oQtMwiflzRv5KfSPEcMyizBiwKxzfqWxTSsm6nlL21c/K
         hPqxnkpcz0pYp8l0YiWM03H8WC1GKqSIF7HJhIHjuffcapUKRRi8hKp3F2nMHmv0mser
         RDVMAgWrEzk1dGizbhkDSLWNtXTMTL9fzB9u7sWl829L6s8P8qoBwy1b0sDVFRotcpna
         14sIBuoigNn9MzU9i94gvSDDHDKGsc4y8Igng3PBypXhoxKtKUtQIujlmwouIwQ8GSoG
         6e2ii6PYpYL/3mXDtc+R1vP6NMhWIU08iE5ICDgyypXM6QDgh4xsTejLnyANcWiXybYs
         /ssA==
X-Forwarded-Encrypted: i=1; AJvYcCW/aOryCOTh568WlLfQYx+8dy7Nw+c5YM6iyhoh7xQmmMOfcP0153ySafloP0JjpD/LHfA3xdZE3yY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwTi7RclgNLe5s3BJXjvatKbEnCq6K0yNZ4AhzaAi6WA9uGEmEN
	H4kvxWMOiEDolatIugEn32S2L/XqRX7J2LwfASMBrZkBU5J2VWPIi0UitkvhNu6TPg==
X-Gm-Gg: ASbGncsqB/9uRAs2SHUrxx0ie8JmlDtZ0bI7OEB7EFDt0ZFTe5el5E7f3fiLcyQ0lGE
	WGTms+HkPRzQRaYAkuSh04GON2Pa8i4SHEcRE/RpfwAq8dB7HEjWxdf6NLIMVrxkVIIhCxiDk2U
	XiNPOnERKoKclR9ibQcmS+qY017I/iHB7xSN6WPs8p+7f9yImtPMIccekqXcowSD62QLQFd8foa
	9giDQzLyuiKqCxXTWV8uMDQHGOgqsOGUOLhlnanUPag/EDhj70wu1uK0kYaAiu6Q79mkw8GtCHS
	ylv3pihrnZgWL8/jsGrVUKgXETJxbNvtBco4SjqfuRNAbjaB2ibWXmW8k79XhlRmDEggr6WVCkY
	JtQOSVjfFgyOUUUDoDWvnm12Z/DMA8FnfgaC+/wQfkzZObW8=
X-Google-Smtp-Source: AGHT+IHCcXHeQFoG7GMczBbS84suP+92TOrdWuur3W5nGARpVZ4QmJ7tElLR9TR8EAE6VQ4ispNZTQ==
X-Received: by 2002:a05:6000:4912:b0:3a6:cfca:efee with SMTP id ffacd0b85a97d-3a6d12a15e6mr11232208f8f.17.1750772426045;
        Tue, 24 Jun 2025 06:40:26 -0700 (PDT)
Message-ID: 
Date: Tue, 24 Jun 2025 15:40:16 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 4/8] pdx: introduce command line compression toggle
To: Roger Pau Monne 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20250620111130.29057-1-roger.pau@citrix.com>
 <20250620111130.29057-5-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: <20250620111130.29057-5-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 20.06.2025 13:11, Roger Pau Monne wrote:
> Introduce a command line option to allow disabling PDX compression.  The
> disabling is done by turning pfn_pdx_add_region() into a no-op, so when
> attempting to initialize the selected compression algorithm the array of
> ranges to compress is empty.

While neat, this also feels fragile. It's not obvious that for any
algorithm pfn_pdx_compression_setup() would leave compression disabled
when there are zero ranges. In principle, if it was written differently
for mask compression, there being no ranges could result in compression
simply squeezing out all of the address bits. Yet as long as we think
we're going to keep this in mind ...

> Signed-off-by: Roger Pau Monné 

Reviewed-by: Jan Beulich 

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 13:47:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 13:47:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023725.1399778 (Exim 4.92)
	(envelope-from )
	id 1uU3zu-00072P-2k; Tue, 24 Jun 2025 13:47:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023725.1399778; Tue, 24 Jun 2025 13:47:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uU3zt-00072I-VU; Tue, 24 Jun 2025 13:47:37 +0000
Received: by outflank-mailman (input) for mailman id 1023725;
 Tue, 24 Jun 2025 13:47: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 1uU3zt-00072C-2a
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 13:47:37 +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 c86b4392-5101-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 15:47:34 +0200 (CEST)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-adeaa4f3d07so1049350666b.0
 for ; Tue, 24 Jun 2025 06:47:34 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ae053e7b3e7sm870915966b.21.2025.06.24.06.47.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 06:47:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c86b4392-5101-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750772854; x=1751377654; 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=/Ai2DEdThYtvB4OnOVTmqoinG56rBRphx6IqrHmJBBU=;
        b=XCrFtvndgpN3Qiz3RBvbQdWNtrjZIaAX4aixzXkz2/aB6omkDlq9qWLcsrULHwTHC5
         OUNN6bkxsx/4/bbnI3Hdn5gSLnbp48xB3VClPcJ+PfROtNN2Jtb7d1yEskm6vVJQoISo
         SwAyYKMhHIWvmEd7nOT0Ku+DRSocxwGfgbgLhZ5t99G56dhfV+cAgTJJy0X8eRtKoyRe
         xWDGFOCmlsLK14B1bnx2bt3Hd8yiaJ3L9uvxFju/LZZHkBLp7VaVTye1EYaLyl2qzSZ7
         fP7F8zYWwEV1SRYrYrkR/0K9Zp7G6VjWKPVsJFDA6QJBp9m69/7mJrSEJRfKVc6EQmQ+
         mJzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750772854; x=1751377654;
        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=/Ai2DEdThYtvB4OnOVTmqoinG56rBRphx6IqrHmJBBU=;
        b=sfrFotj+FsQyTeL2dI61IPK702nNX1AMjqwFKeLgKNg658lUWtYj2o2p4dTCXkrP8g
         BoBFmm8V4ofrVCZ6m5W1SJ8bRYCXv0AFmswrcMWrOSmURVHrMZGIxq7/IjST0dykSfgy
         RKNETbmwAgTg8R67KTrOaTV2K8kyGuH9WuAaTnKplfT+qfftJbZ7rMLADhLuynkZCQuI
         EPmRo/iN9bT03rkVAIBXX1Ql2V/prSXkR2ZAdBE5nlptjDpiRUQaLVHcQ62ed2ohXaXG
         T/6vzM0KHFJ7ZcvQTitkW+RXGVZ8oO9T5gpDUD36b3xyQcYvHvyI2Xh7pGjQxg1P3UJk
         sAyA==
X-Forwarded-Encrypted: i=1; AJvYcCXlwFLyca6F9+HLrIEEIbyk2leQqkweGntGiEuEKE6/DWKP4J5xBGXY5s2RUIAHI/yVcR0lPt6YGck=@lists.xenproject.org
X-Gm-Message-State: AOJu0YywFsEgKmBLfxjEF/opHGqNBcZ2sm9nTaRv3+Gr5KZ2kvshoToE
	GABmAcK3tGv2PxoRwv8xZ/Dd0W2eYAZmtFQxAFrR6W7SpN3dSfaZR+/+
X-Gm-Gg: ASbGncvTBYkg4d9P5oKNFfYP3Vv3kBpMVPCnAy8tI5v4Z6nPVI1pOdRQe5GAY/stIhz
	6Cfgj8ziUN0wDmhwYIcbFrsjSIPVul4IH52IonJt58h1V3D7aQSe5z0C6Dvo9CTFQ+HKLLFYFl8
	emckbz1SK6xJyauFJH+qHyfp0ga/K+wvVS9JbTC6nHrxu1OQT7ZiRtKKpUGUYV6kWPHml0bSc0U
	/AYRosNxtGWWUhLa4N7QTRf6LOtaqkDBmHVghnEAxrNyLzzGDqYacMVK9DZYRcnU+wNoAi+p4E/
	UsgXnFHsz9XsM+T/nOmtNyzJTq3Y9y/+b5mcdtfJ6EmhkASYOSUxM8ilCrXUcQTp3pnG3ujZyrb
	f6Q4ZKTch2zhP4gX2S/7rdEMkOVx+r/W/s1s=
X-Google-Smtp-Source: AGHT+IEYpeiT5h57/uThAquKzfMUKaSUNJ3mRBUymbfVP6sBdBP/86eYPNITDduPMISfA3v1lqO9fQ==
X-Received: by 2002:a17:907:9603:b0:ad8:9c97:c2da with SMTP id a640c23a62f3a-ae057f6473bmr1576443866b.40.1750772853811;
        Tue, 24 Jun 2025 06:47:33 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------egtLgrWjPl4TsCOGsEkn1syp"
Message-ID: 
Date: Tue, 24 Jun 2025 15:47:32 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 03/17] xen/riscv: introduce guest domain's VMID
 allocation and manegement
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: 
 
 
 <145f71c2-643e-4839-a2ae-0bc1f049db74@gmail.com>
 <80223fe3-7403-4026-9505-8826c318fabb@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <80223fe3-7403-4026-9505-8826c318fabb@suse.com>

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


On 6/24/25 12:44 PM, Jan Beulich wrote:
> On 24.06.2025 11:46, Oleksii Kurochko wrote:
>> On 6/18/25 5:46 PM, Jan Beulich wrote:
>>> On 10.06.2025 15:05, Oleksii Kurochko wrote:
>>>> --- /dev/null
>>>> +++ b/xen/arch/riscv/p2m.c
>>>> @@ -0,0 +1,115 @@
>>>> +#include 
>>>> +#include 
>>>> +#include 
>>>> +#include 
>>>> +#include 
>>>> +
>>>> +#include 
>>>> +#include 
>>>> +
>>>> +static spinlock_t vmid_alloc_lock = SPIN_LOCK_UNLOCKED;
>>>> +
>>>> +/*
>>>> + * hgatp's VMID field is 7 or 14 bits. RV64 may support 14-bit VMID.
>>>> + * Using a bitmap here limits us to 127 (2^7 - 1) or 16383 (2^14 - 1)
>>>> + * concurrent domains.
>>> Which is pretty limiting especially in the RV32 case. Hence why we don't
>>> assign a permanent ID to VMs on x86, but rather manage IDs per-CPU (note:
>>> not per-vCPU).
>> Good point.
>>
>> I don't believe anyone will use RV32.
>> For RV64, the available ID space seems sufficiently large.
>>
>> However, if it turns out that the value isn't large enough even for RV64,
>> I can rework it to manage IDs per physical CPU.
>> Wouldn't that approach result in more TLB entries being flushed compared
>> to per-vCPU allocation, potentially leading to slightly worse performance?
> Depends on the condition for when to flush. Of course performance is
> unavoidably going to suffer if you have only very few VMIDs to use.
> Nevertheless, as indicated before, the model used on x86 may be a
> candidate to use here, too. See hvm_asid_handle_vmenter() for the
> core (and vendor-independent) part of it.

Thanks.

IIUC, so basically it is just a round-robin and when VMIDs are ran out
then just do full guest TLB flush and start to re-use VMIDs from the start.
It makes sense to me, I'll implement something similar. (as I'm not really
sure that we needdata->core_asid_generation, probably, I will understand it better when 
start to implement it)

>
>> What about then to allocate VMID per-domain?
> That's what you're doing right now, isn't it? And that gets problematic when
> you have only very few bits in hgatp.VMID, as mentioned below.

Right, I just phrased my question poorly—sorry about that.

What I meant to ask is: does the approach described above actually depend on whether
VMIDs are allocated per-domain or per-pCPU? It seems that the main advantage of
allocating VMIDs per-pCPU is potentially reducing the number of TLB flushes,
since it's more likely that a platform will have more than|VMID_MAX| domains than
|VMID_MAX| physical CPUs—am I right?


>
>>>> The bitmap space will be allocated dynamically
>>>> + * based on whether 7 or 14 bit VMIDs are supported.
>>>> + */
>>>> +static unsigned long *vmid_mask;
>>>> +static unsigned long *vmid_flushing_needed;
>>>> +
>>>> +/*
>>>> + * -2 here because:
>>>> + *    - -1 is needed to get the maximal possible VMID
>>> I don't follow this part.
>> Probably, I'm missing something.
>>
>> hgat.vmid is 7 bit long. BIT(7,U) = 1 << 7 = 128 which is bigger
>> then 7 bit can cover (0b1000_0000 and 0x111_1111). Thereby the MAX_VMID is:
>>    BIT(7, U) - 1 (in case of RV32).
> Right, but then why -2? (Maybe this is moot now that you agreed that
> INVALID_VMID can be defined differently.

Yes, another one -1 was because how INVALID_VMID was defined.

>
>>> VMIDLEN being permitted to be 0, how would you run more than one VM (e.g. Dom0)
>>> on such a system?
>> Hmm, good question.
>>
>> Then it will be needed to flush TLB on each VM switch by using
>> sbi_remote_hfence_gvma().
> Right, but just to be clear: That flush should not be conditional upon
> VMIDLEN being 0. In whatever model you chose, the handling of this special
> case should come out "natural".

Sure. I have some ideas how to do it natural.

>
>>>> +        sbi_remote_hfence_gvma_vmid(d->dirty_cpumask, 0, 0, p2m->vmid);
>>> You're creating d; it cannot possibly have run on any CPU yet. IOW
>>> d->dirty_cpumask will be reliably empty here. I think it would be hard to
>>> avoid issuing the flush to all CPUs here in this scheme.
>> I didn't double check, but I was sure that in case d->dirty_cpumask is empty then
>> rfence for all CPUs will be send. But I was wrong about that.
>>
>> What about just update a code of sbi_rfence_v02()?
> I don't know, but dealing with the issue there feels wrong. However,
> before deciding where to do something, it needs to be clear what you
> actually want to achieve. To me at least, that's not clear at all.

I want to achieve the following behavior: if a mask is empty
(specifically, in our case|d->dirty_cpumask|), then perform the flush
on all CPUs.

If you think it's not a good idea to change the current implementation
of|sbi_rfence_v02()|, then I’ll just check if|d->dirty_cpumask| is empty
before calling|sbi_remote_hfence_gvma_vmid(d->dirty_cpumask, 0, 0, p2m->vmid)|.

If it is empty, I’ll call|sbi_remote_hfence_gvma()| instead:
|if( !cpumask_empty(d->dirty_cpumask) ) 
sbi_remote_hfence_gvma_vmid(d->dirty_cpumask, 0, 0, p2m->vmid); 
elsesbi_remote_hfence_gvma(NULL, 0, 0); |

A similar check will be needed in|p2m_force_tlb_flush_sync()|, which is
implemented in one of the following patches in this series.

However, if we instead move the|if ( !cpumask_empty(d->dirty_cpumask) ) |check into||https://gitlab.com/xen-project/xen/-/blob/staging/xen/arch/riscv/sbi.c?ref_type=heads#L178,
we could call only:
   |sbi_remote_hfence_gvma_vmid(d->dirty_cpumask, 0, 0, p2m->vmid); |and get the same effect, which might result in cleaner code overall
as we already have a similar check (cpumask == NULL)|sbi_rfence_v02|() and a result of which
is just to send rfence operation to all CPUs.

>
>>>> +    spin_unlock(&vmid_alloc_lock);
>>>> +    return rc;
>>>> +}
>>>> +
>>>> +void p2m_free_vmid(struct domain *d)
>>>> +{
>>>> +    struct p2m_domain *p2m = p2m_get_hostp2m(d);
>>>> +
>>>> +    spin_lock(&vmid_alloc_lock);
>>>> +
>>>> +    if ( p2m->vmid != INVALID_VMID )
>>>> +    {
>>>> +        clear_bit(p2m->vmid, vmid_mask);
>>>> +        set_bit(p2m->vmid, vmid_flushing_needed);
>>> Does this scheme really avoid any flushes (except near when the system is
>>> about to go down)?
>>>
>>> As to choice of functions - see above.
>> I think yes, so my idea was that if vmid isn't freed then we have enough free VMID
>> and in this case flush isn't needed as each vcpu has unique not-used yet VMID,
>> and if there is no free VMID then and error will return in p2m_alloc_vmid():
>>       if ( nr == MAX_VMID )
>>       {
>>           rc = -EBUSY;
>>           printk(XENLOG_ERR "p2m.c: dom%pd: VMID pool exhausted\n", d->domain_id);
>>           goto out;
>>       }
> Which, as said, is a problem when there are only very few VMIDs.
>
>> On other hand, if VMID was freed and then re-used in p2m_alloc_vmid(), then it means
>> that vmid_flushing_needed will have VMID bit set, what means that a TLB flush is needed.
> Let's assume over the uptime of a system you cycle through all VMIDs a thousand
> times. While you manage to delay some TLB flushes, the percentage of ones actually
> saved is going to be very low then.

Then it is just better to update VMID allocation algo.

>
>>>> +    }
>>>> +
>>>> +    spin_unlock(&vmid_alloc_lock);
>>>> +}
>>>> +
>>>> +int p2m_init(struct domain *d)
>>>> +{
>>>> +    struct p2m_domain *p2m = p2m_get_hostp2m(d);
>>>> +    int rc;
>>>> +
>>>> +    p2m->vmid = INVALID_VMID;
>>> Given the absence of callers of p2m_free_vmid() it's also not clear what use
>>> this is.
>> Just mark that VMID for this domain wasn't yet allocated.
>>
>> Anyway, it will be called from arch_domain_create() by arch_domain_destroy() so if the some
>> error happens during arch_domain_create() and p2m->vmid wasn't allocated yet (so is equal to
>> INVALID_VMID), it means that there is no sense to update vmid_mask or vmid_flushing_needed.
> But only if you actually came through p2m_init() prior to the error. My point
> is: If you allocate a VMID here anyway, why first set the field like this?

Oh, got your point. Indeed, there is no sense.

> (Again, this is likely moot since the allocation scheme is likely to change
> altogether.)

Yes, it won't be really needed in the new allocation scheme.

Thanks.

~ Oleksii

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



  
    
  
  
    

    
    
    
    
    On 6/24/25 12:44 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 24.06.2025 11:46, Oleksii Kurochko wrote:

    
      
    
        
    On 6/18/25 5:46 PM, Jan Beulich wrote:

    
        
    
          
    On 10.06.2025 15:05, Oleksii Kurochko wrote:

    
          
    
            
    --- /dev/null
+++ b/xen/arch/riscv/p2m.c
@@ -0,0 +1,115 @@
+#include <xen/bitops.h>
+#include <xen/lib.h>
+#include <xen/sched.h>
+#include <xen/spinlock.h>
+#include <xen/xvmalloc.h>
+
+#include <asm/p2m.h>
+#include <asm/sbi.h>
+
+static spinlock_t vmid_alloc_lock = SPIN_LOCK_UNLOCKED;
+
+/*
+ * hgatp's VMID field is 7 or 14 bits. RV64 may support 14-bit VMID.
+ * Using a bitmap here limits us to 127 (2^7 - 1) or 16383 (2^14 - 1)
+ * concurrent domains.

    
          
    
          
    Which is pretty limiting especially in the RV32 case. Hence why we don't
assign a permanent ID to VMs on x86, but rather manage IDs per-CPU (note:
not per-vCPU).

    
        
    
        
    Good point.

I don't believe anyone will use RV32.
For RV64, the available ID space seems sufficiently large.

However, if it turns out that the value isn't large enough even for RV64,
I can rework it to manage IDs per physical CPU.
Wouldn't that approach result in more TLB entries being flushed compared
to per-vCPU allocation, potentially leading to slightly worse performance?

    
      
    
      
    Depends on the condition for when to flush. Of course performance is
unavoidably going to suffer if you have only very few VMIDs to use.
Nevertheless, as indicated before, the model used on x86 may be a
candidate to use here, too. See hvm_asid_handle_vmenter() for the
core (and vendor-independent) part of it.
    
    
    
    
    Thanks.

IIUC, so basically it is just a round-robin and when VMIDs are ran out
then just do full guest TLB flush and start to re-use VMIDs from the start.
It makes sense to me, I'll implement something similar. (as I'm not really
sure that we need data->core_asid_generation, probably, I will understand
it better when start to implement it)


    
    
    
      
    

    
      
    
        
    What about then to allocate VMID per-domain?

    
      
    
      
    That's what you're doing right now, isn't it? And that gets problematic when
you have only very few bits in hgatp.VMID, as mentioned below.
    
    
    
    
    Right, I just phrased my question poorly—sorry about that.
    
    
    What I meant to ask is: does the approach described above actually depend on whether
VMIDs are allocated per-domain or per-pCPU? It seems that the main advantage of
allocating VMIDs per-pCPU is potentially reducing the number of TLB flushes,
since it's more likely that a platform will have more than VMID_MAX domains than
VMID_MAX physical CPUs—am I right?
    
    
    

    
    
    
      
    

    
      
    
        
    
          
    
            
    The bitmap space will be allocated dynamically
+ * based on whether 7 or 14 bit VMIDs are supported.
+ */
+static unsigned long *vmid_mask;
+static unsigned long *vmid_flushing_needed;
+
+/*
+ * -2 here because:
+ *    - -1 is needed to get the maximal possible VMID

    
          
    
          
    I don't follow this part.

    
        
    
        
    Probably, I'm missing something.

hgat.vmid is 7 bit long. BIT(7,U) = 1 << 7 = 128 which is bigger
then 7 bit can cover (0b1000_0000 and 0x111_1111). Thereby the MAX_VMID is:
  BIT(7, U) - 1 (in case of RV32).

    
      
    
      
    Right, but then why -2? (Maybe this is moot now that you agreed that
INVALID_VMID can be defined differently.
    
    
    
    
    Yes, another one -1 was because how INVALID_VMID was defined.


    
    
    
      
    

    
      
    
        
    
          
    VMIDLEN being permitted to be 0, how would you run more than one VM (e.g. Dom0)
on such a system?

    
        
    
        
    Hmm, good question.

Then it will be needed to flush TLB on each VM switch by using
sbi_remote_hfence_gvma().

    
      
    
      
    Right, but just to be clear: That flush should not be conditional upon
VMIDLEN being 0. In whatever model you chose, the handling of this special
case should come out "natural".
    
    
    
    
    Sure. I have some ideas how to do it natural.


    
    
    
      
    

    
      
    
        
    
          
    
            
    +        sbi_remote_hfence_gvma_vmid(d->dirty_cpumask, 0, 0, p2m->vmid);

    
          
    
          
    You're creating d; it cannot possibly have run on any CPU yet. IOW
d->dirty_cpumask will be reliably empty here. I think it would be hard to
avoid issuing the flush to all CPUs here in this scheme.

    
        
    
        
    I didn't double check, but I was sure that in case d->dirty_cpumask is empty then
rfence for all CPUs will be send. But I was wrong about that.

What about just update a code of sbi_rfence_v02()?

    
      
    
      
    I don't know, but dealing with the issue there feels wrong. However,
before deciding where to do something, it needs to be clear what you
actually want to achieve. To me at least, that's not clear at all.
    
    
    
    
    I want to achieve the following behavior: if a mask is empty
(specifically, in our case d->dirty_cpumask), then perform the flush
on all CPUs.
    
    
    If you think it's not a good idea to change the current implementation
of sbi_rfence_v02(), then I’ll just check if d->dirty_cpumask is empty
before calling sbi_remote_hfence_gvma_vmid(d->dirty_cpumask, 0, 0, p2m->vmid).

If it is empty, I’ll call sbi_remote_hfence_gvma() instead:

      if ( !cpumask_empty(d->dirty_cpumask) )
      sbi_remote_hfence_gvma_vmid(d->dirty_cpumask, 0, 0, p2m->vmid);
  else
      sbi_remote_hfence_gvma(NULL, 0, 0);

    
    
    A similar check will be needed in p2m_force_tlb_flush_sync(), which is
implemented in one of the following patches in this series.
    
    
    However, if we instead move the if ( !cpumask_empty(d->dirty_cpumask) )
check into https://gitlab.com/xen-project/xen/-/blob/staging/xen/arch/riscv/sbi.c?ref_type=heads#L178,
we could call only:
  sbi_remote_hfence_gvma_vmid(d->dirty_cpumask, 0, 0, p2m->vmid);
and get the same effect, which might result in cleaner code overall
as we already have a similar check (cpumask == NULL) sbi_rfence_v02() and a result of which
is just to send rfence operation to all CPUs.

    
    
    
    
    
      
    

    
      
    
        
    
          
    
            
    +    spin_unlock(&vmid_alloc_lock);
+    return rc;
+}
+
+void p2m_free_vmid(struct domain *d)
+{
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+    spin_lock(&vmid_alloc_lock);
+
+    if ( p2m->vmid != INVALID_VMID )
+    {
+        clear_bit(p2m->vmid, vmid_mask);
+        set_bit(p2m->vmid, vmid_flushing_needed);

    
          
    
          
    Does this scheme really avoid any flushes (except near when the system is
about to go down)?

As to choice of functions - see above.

    
        
    
        
    I think yes, so my idea was that if vmid isn't freed then we have enough free VMID
and in this case flush isn't needed as each vcpu has unique not-used yet VMID,
and if there is no free VMID then and error will return in p2m_alloc_vmid():
     if ( nr == MAX_VMID )
     {
         rc = -EBUSY;
         printk(XENLOG_ERR "p2m.c: dom%pd: VMID pool exhausted\n", d->domain_id);
         goto out;
     }

    
      
    
      
    Which, as said, is a problem when there are only very few VMIDs.


    
      
    
        
    On other hand, if VMID was freed and then re-used in p2m_alloc_vmid(), then it means
that vmid_flushing_needed will have VMID bit set, what means that a TLB flush is needed.

    
      
    
      
    Let's assume over the uptime of a system you cycle through all VMIDs a thousand
times. While you manage to delay some TLB flushes, the percentage of ones actually
saved is going to be very low then.
    
    
    
    
    Then it is just better to update VMID allocation algo.


    
    
    
      
    

    
      
    
        
    
          
    
            
    +    }
+
+    spin_unlock(&vmid_alloc_lock);
+}
+
+int p2m_init(struct domain *d)
+{
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    int rc;
+
+    p2m->vmid = INVALID_VMID;

    
          
    
          
    Given the absence of callers of p2m_free_vmid() it's also not clear what use
this is.

    
        
    
        
    Just mark that VMID for this domain wasn't yet allocated.

Anyway, it will be called from arch_domain_create() by arch_domain_destroy() so if the some
error happens during arch_domain_create() and p2m->vmid wasn't allocated yet (so is equal to
INVALID_VMID), it means that there is no sense to update vmid_mask or vmid_flushing_needed.

    
      
    
      
    But only if you actually came through p2m_init() prior to the error. My point
is: If you allocate a VMID here anyway, why first set the field like this?
    
    
    
    
    Oh, got your point. Indeed, there is no sense.


    
    
    
      
    (Again, this is likely moot since the allocation scheme is likely to change
altogether.)
    
    
    
    
    Yes, it won't be really needed in the new allocation scheme.

Thanks.

~ Oleksii

    
  


--------------egtLgrWjPl4TsCOGsEkn1syp--


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 13:51:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 13:51:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023738.1399789 (Exim 4.92)
	(envelope-from )
	id 1uU43Z-0000MC-Mp; Tue, 24 Jun 2025 13:51:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023738.1399789; Tue, 24 Jun 2025 13:51:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uU43Z-0000M5-IT; Tue, 24 Jun 2025 13:51:25 +0000
Received: by outflank-mailman (input) for mailman id 1023738;
 Tue, 24 Jun 2025 13: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 1uU43Y-0000Lz-76
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 13:51: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 4ff90791-5102-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 15:51:22 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3a525eee2e3so394483f8f.2
 for ; Tue, 24 Jun 2025 06:51:22 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-749b5e42ad8sm1940971b3a.70.2025.06.24.06.51.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 06:51:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4ff90791-5102-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750773082; x=1751377882; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=mMqvgfXFjuXxBYcGdcH4uhQW/vj09bAHSO+7Phn8pFI=;
        b=bqvIqdk0JgLppiv3m0s+YEaD7L387vpgpyiaZIkHiWBwtw0bMe3zt+i84uzxL2+FCv
         9WMvVCL8jxX6KLGCyt7RjZy9ciz/GsKor3ZN1akn6CblMvjGnZotdclHUMTeRLOVmgbl
         XxdPhzubaNleMXJ+TCcBTSBOh7b2rF60/asMKPM8sFSeVRR3oJEjXvrRpA/zJ3XnkFq0
         h7Rlj3dgH2xP5XHeGFKHRlqSUlD/rvbWV9dYQ+kXf95d07k/Fk2pqGZcYmhA9v+Y4a7Q
         h8KaVD55tYxq9z2eJg+a2XQpi7VWvBzdGaTQCZqfkyneuBzttvrFipPcNLA5wpVUu0sU
         adMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750773082; x=1751377882;
        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=mMqvgfXFjuXxBYcGdcH4uhQW/vj09bAHSO+7Phn8pFI=;
        b=u5Ra4v5F6l0vTov0fA/T2umLNKEmhM8rpPncOkx6whChpw2NP9to7y1/QARSNH1zmq
         ZFutgYjNWgtOrvLuU1Yxc2/Z5/6rbEXfeswbI0PyloikBHGP6lQoqpA7on8/18Yj7hWw
         r/g22uA4vUtbl7YH7y7fK3Zxjih/o/o4zbt6b9QVFbZhe6z8U9fBQaGb6Tpc8nPvMptm
         ZE4mQHcb+suXZ+2TZ8qwpg0U9v2GnXJ776VdQFjXXoL/HFc0DYK6T/zFYuDjprdDTipi
         q6vPdPy6IXoFzuWlf3BHB5y9scvAIPruOvB7/7bBr+fTS3ZAetPsfmBMtad8LpWXEy28
         hOIg==
X-Forwarded-Encrypted: i=1; AJvYcCVl81fHT0k8hSZsw8oz002tjv3RQ5D56+CKb4ujXj7kkWcJjAHvepChRPdv60XYT9egOjG146FYanU=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywk5d25jvV78U07QPXf2qFAZSGji3QKCHPwqB9QOFAzJUapG1eW
	jG/mw/IW5UoId+i9aqXcwYYvhcZm8dGTMYhytsuz7Ng2V9z9rOsyIXyI59wpRe22ag==
X-Gm-Gg: ASbGnctiYvf1+9IKAM24c8e3kQFokC7Kepm5bxXyjBfAPnsJ4lgT48t0v7XayBc8VrA
	5lwMC7x8kNJsTEYCO1fp4g1u/LvbFqwg4caHS/uH9IbtCKmEyKP05oK2WYSvVBroEGNG33v7OjO
	kmut0peGuB7jz+RFRYuQuHYpHpx+g0rXQ9QCrFDvsBh6RDs+eL+qUid7saCwvjogxe1W0jfxqLw
	sX6JEgWvKTizI+pdtZBKfl5HqEol2c6jaBQ4TcwcWep99tMPQIRjkTx0ShLXUZCYQ4tBpZWQSxB
	Wgi/edPjwwM3D9FphGGDaVySw6F+Za0PFs5pygjikNIucP16dwPR80yePfrhwpMR3hlnj1yBkdb
	qhkGzbbirSWghp8/bIi2uc3HX+9il4mcF1AXba+5Qbj2/CIE=
X-Google-Smtp-Source: AGHT+IHcVYqdVUM3GAGxo0KiVxKpr9hWtlOI8hMw7Wre/7/20c8QcnlbyG/ELJx8/NyMvp1veusJUg==
X-Received: by 2002:a05:6000:40c7:b0:3a4:d3ff:cef2 with SMTP id ffacd0b85a97d-3a6d12d8000mr13627227f8f.27.1750773081719;
        Tue, 24 Jun 2025 06:51:21 -0700 (PDT)
Message-ID: 
Date: Tue, 24 Jun 2025 15:51:09 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 5/8] pdx: allow per-arch optimization of PDX conversion
 helpers
To: Roger Pau Monne 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD ,
 Shawn Anastasio ,
 Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Oleksii Kurochko ,
 xen-devel@lists.xenproject.org
References: <20250620111130.29057-1-roger.pau@citrix.com>
 <20250620111130.29057-6-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: <20250620111130.29057-6-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 20.06.2025 13:11, Roger Pau Monne wrote:
> --- /dev/null
> +++ b/xen/arch/x86/include/asm/pdx.h
> @@ -0,0 +1,75 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#ifndef X86_PDX_H
> +#define X86_PDX_H
> +
> +#ifndef CONFIG_PDX_NONE
> +
> +#include 
> +
> +/*
> + * Introduce a macro to avoid repeating the same asm goto block in each helper.
> + * Note the macro is strictly tied to the code in the helpers.
> + */
> +#define PDX_ASM_GOTO_SKIP                           \
> +    asm_inline goto (                               \
> +        ALTERNATIVE(                                \
> +            "",                                     \
> +            "jmp %l[skip]",                         \
> +            ALT_NOT(X86_FEATURE_PDX_COMPRESSION))   \
> +        : : : : skip )

Did you consider passing the label name as argument to the macro? That way ...

> +static inline unsigned long pfn_to_pdx(unsigned long pfn)
> +{
> +    PDX_ASM_GOTO_SKIP;
> +
> +    return pfn_to_pdx_xlate(pfn);
> +
> + skip:
> +    return pfn;
> +}

... the labels here and below then wouldn't look unused.

The other slight anomaly with this is that we're wasting 2 or 5 bytes of
code space. Yet I guess that's an acceptable price to pay for keeping the
actual translation code in C (rather than in assembly).

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 13:52:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 13:52:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023745.1399797 (Exim 4.92)
	(envelope-from )
	id 1uU44o-0000rA-UI; Tue, 24 Jun 2025 13:52:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023745.1399797; Tue, 24 Jun 2025 13:52: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 1uU44o-0000r3-RZ; Tue, 24 Jun 2025 13:52:42 +0000
Received: by outflank-mailman (input) for mailman id 1023745;
 Tue, 24 Jun 2025 13:52:41 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uU44n-0000qc-55
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 13:52:41 +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 7e0aff32-5102-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 15:52:39 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a57c8e247cso4306097f8f.1
 for ; Tue, 24 Jun 2025 06:52:39 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b31f118ea2esm8941179a12.7.2025.06.24.06.52.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 06:52:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7e0aff32-5102-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750773159; x=1751377959; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=xT8pVmc99bP6/tpx5FsVFRp5st876WhQAswAfOva5gU=;
        b=W4P34lcGdB0MS76viJLdHsyp9m7XiatULB8JzbDj2snCoP6MhRfr3Z1/1SiO89+mUT
         oe/RCl/ql9T4grHQWwe25YluzyWb3gEd+pySXppx48S6VqznXMpt7+0j9COC/3X2ItUH
         15O7//sMulAP1gEteNNqy+iIgB96pVgfcXn41XA2o6uG4WpkUYXQJCWEZCUaiv2VMPLf
         z05fm+oTnPg8uu269I198dwZBsbLEnCCMic/4R4kQr8X1RwQmc4d3A4LyAp3T9Au/Gtj
         tumD8UtLRJjiPCPJ4kG8iB5yojQpnI7V+QOS9+YvW9TyCX4TN+hyQKQ3+kmqdu+xvg/d
         xxsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750773159; x=1751377959;
        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=xT8pVmc99bP6/tpx5FsVFRp5st876WhQAswAfOva5gU=;
        b=J7H3RQDbbN7IiewNHtvzeaMZ7X1RYmRlb9ROy5kEEE4hC+rTDF27Kqw02jGRWHGCl7
         XZMPr/lOs0767ezhfucl+TPbhezjUpbuCesJgC0Jy36NW/sqosJbYJDvGWBFAo0VSo7c
         ACRH4PVKsKjC8DZWlLkV0yajRqbTBvJ0lmLsKziDqGDGymPBWpfTaa5BnQxxvoRnRApB
         6HAdJnh4j9zfAb8ZrmRU8voklUa34PiFzMpZZFIyp90RAXCNYHpSvWkCUKKnmkc9miwO
         SVUnrq9gHmmweqbcJ6zbgJkgJnQ58v+EyRbwM+K5RgNKWhLp2xQ0UL+MJUJRYvc3yMPq
         Tu0A==
X-Forwarded-Encrypted: i=1; AJvYcCUJ7XIQqEB1kWjTJWDYs7K0bgOB5RzIXZhIMDadVYncnvaGT6x9ZEBUhGevMExTmD5bGxnfc2tapxE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyz04b4SU4QsgYqqPHtk3bPc/I0KW+sPQ5+0DXMi0BZvbTh3qWo
	qOUez0zOHjXRDTJp0KA3fVqXQi9mOK/qezhtYUHvmhZfzfyax32m3g8aSjXouUJuDQ==
X-Gm-Gg: ASbGncsmeVeS/D3oZkcFmv/KlHpn8CThQEF6N1JuTWllzPtm9HhT/g4QXUk9oL1wluX
	8cXQoB+oGNQyTdDyyIQYLmNgo0Z8Bmr5N2Ac+MVrv3xEBrly2hDVoj5GZybaNzymjwt3ZqjhYCB
	rLcoMRFwAY034Mupei/mXvnP79jiR3BsqJGep2bOxd3qlCpGXunUkdv9tuFQnSFSYBLPHrAPXQw
	UHV8RSW2pNyzSevb4GTvLQxe6HKVB5Tiw4vg3hI/PHXsdMI6RBqDlofKyraX2WePeWdI3oPSqIQ
	pIcPs7g7xfgX/NKerq0DQMOy3XXc8yNmwiJVtSp5DfxkGhwtEf595UwaBaMZ8SMBNsGK2/s2TrW
	RPd7oSfFE8OmPAkF5AQ5PBhZCk0itAePd3FEitV6i9XluMAg=
X-Google-Smtp-Source: AGHT+IHSrZaa3CHTH4I+4Ok+QAKsPp4FLWzFw60J4Q8BqvO2TBrsPAXVdV3JpP5uNoOKkF6amBWk+A==
X-Received: by 2002:a05:6000:2003:b0:3a4:d64a:3df6 with SMTP id ffacd0b85a97d-3a6d12dbd58mr14346689f8f.3.1750773159074;
        Tue, 24 Jun 2025 06:52:39 -0700 (PDT)
Message-ID: 
Date: Tue, 24 Jun 2025 15:52:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 7/8] pdx: move some helpers in preparation for new
 compression
To: Roger Pau Monne 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250620111130.29057-1-roger.pau@citrix.com>
 <20250620111130.29057-8-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: <20250620111130.29057-8-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 20.06.2025 13:11, Roger Pau Monne wrote:
> Move fill_mask(), pdx_region_mask() and pdx_init_mask() to the
> !CONFIG_PDX_NONE section in preparation of them also being used by a newly
> added PDX compression.
> 
> No functional change intended.
> 
> Signed-off-by: Roger Pau Monné 

Acked-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 14:01:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 14:01:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023756.1399807 (Exim 4.92)
	(envelope-from )
	id 1uU4DU-0002Yw-Nr; Tue, 24 Jun 2025 14:01:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023756.1399807; Tue, 24 Jun 2025 14:01:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uU4DU-0002Yp-Kn; Tue, 24 Jun 2025 14:01:40 +0000
Received: by outflank-mailman (input) for mailman id 1023756;
 Tue, 24 Jun 2025 14:01:39 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uU4DT-0002Yj-4a
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 14:01: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 befec530-5103-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 16:01:38 +0200 (CEST)
Received: by mail-lf1-x12b.google.com with SMTP id
 2adb3069b0e04-553b51f5218so462140e87.0
 for ; Tue, 24 Jun 2025 07:01:38 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d867f8d0sm111636445ad.175.2025.06.24.07.01.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 07:01:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: befec530-5103-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750773697; x=1751378497; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Vm+y1VGxVVOsdccpEdh9HYahOWLYN2AlvFui1euU3ic=;
        b=XOcLJBXDDnzgxmfrhBknsCbEmx09ModpBzBK/Bq69Hh0E/zXO/vilvtS+kLQES8/jV
         RqQR8uDHkVn+weeHjWZVqK99AM9RnF8PRwdOuWBKZbamHUnJL2ZZqKBB992JYaV/BiIJ
         SDtPVk2Sd3IwnTwVJYEjzmzxgmcdGnvAtbe8g8fZWKM+UcrYBf/UP5MAu9MmxX10xFV/
         L5J22JK5+9aBwh/3xbP07ETAPJ3Bzhzz4i3sY/MuL+ilrx5eb84rzQ6HULKQnNWTcARU
         t++yZUGzHuROIOroxAKxGON+oKHND5jmh6Y2SBIcQ+PeZXFqkYg5vMKu9/tepvRNWlp3
         nJ6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750773697; x=1751378497;
        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=Vm+y1VGxVVOsdccpEdh9HYahOWLYN2AlvFui1euU3ic=;
        b=mqoUfnuncmlHEVrXHby7ljor6uEPk7vZ1yTDNqOBtfndTlUigzokE1ba+bpcQHDhJl
         P8YjOMEx0IuwfJjcPVjQgD8OiZnU7Y0L8mGsTIS3jUpJC1o1Wkm967cN1C8VOtLTs85M
         JxY0RiHnZdMleOV95G7gW69RD3l3fziB9Lw8nVBdRuS9mJB8rbg2DyJ2OfO73sp1MRvV
         3YjptHTMxO7hRhJGE2RUzwdLjH8yPpudtyDvKcik6pgUNB7nT9c9/LMZNUjar1hP4Oui
         nB2IdYYL9Oe5a0P65NEaAZ3/0IfjODod5m2vlDqmyL5eCclt9MsQ/HMlckBgZ3DjPEhO
         QGSg==
X-Forwarded-Encrypted: i=1; AJvYcCUEWZ7lv/YDPY/RKIrEo8TJ4qUqyVa5swfcr511yvyFCtOM7rp0Uwc/VtvfanoRIrZEj85AAggjuzs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwlEDsUzkJCv+w8TbqbNOPV9AsFulNnk5CiFA2Rb+NA3a4je6uT
	UIAsuJaybT9XMhxMhOFS/1x5wiHawaUhUWjtM0GiwSlmrkIzc3rAsE7dddFD9vmjHg==
X-Gm-Gg: ASbGnctqyGhY2DjEh668hm8DPWCsrmY3cAye0YUmybXfvOukISda8F+dwsxX/5jIU7y
	q6ne3zTnjn6B6MAP8nHj0hEp0JajB0+5Tq6af+L9U+UnqYd/WBtOjyqknvxnPSylt4n7AjAATS4
	mYm4EpPPJlojueDBb3JDV515a58kLdLgcCQ1mC6IDK1vKMPFMeNpF2lzu7XLvgws0H9QHhnElta
	glGyaGXbQ5FiFEqf9wPakmw3tBFzJJn9KSaojkhE1hg4dDqvRNCbe81HZjYm5WePqiY1bJeUEOZ
	3JkPSbLOCY0ZmurlT6Jeh7OVXSZjIGY8eeUnTkldEPl/ZbL0AjP3y4rQTYm3UxochIOHGpL6dLL
	Hx0jxSK1A1y12Ma6Nv50By0+nwq5VjfXg9KmgatDlpTy8OTs=
X-Google-Smtp-Source: AGHT+IHBwjBRT9z/DZTIqLQYbJsyeg74EDwrFouTnuxVlapPFGG+NdG6n8A+r3CTZA1jfiBKL4TLKg==
X-Received: by 2002:a05:6512:3b9d:b0:553:65bc:4232 with SMTP id 2adb3069b0e04-553e3beb474mr5984699e87.31.1750773694994;
        Tue, 24 Jun 2025 07:01:34 -0700 (PDT)
Message-ID: 
Date: Tue, 24 Jun 2025 16:01:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 03/17] xen/riscv: introduce guest domain's VMID
 allocation and manegement
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: 
 
 
 <145f71c2-643e-4839-a2ae-0bc1f049db74@gmail.com>
 <80223fe3-7403-4026-9505-8826c318fabb@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 24.06.2025 15:47, Oleksii Kurochko wrote:
> On 6/24/25 12:44 PM, Jan Beulich wrote:
>> On 24.06.2025 11:46, Oleksii Kurochko wrote:
>>> On 6/18/25 5:46 PM, Jan Beulich wrote:
>>>> On 10.06.2025 15:05, Oleksii Kurochko wrote:
>>>>> --- /dev/null
>>>>> +++ b/xen/arch/riscv/p2m.c
>>>>> @@ -0,0 +1,115 @@
>>>>> +#include 
>>>>> +#include 
>>>>> +#include 
>>>>> +#include 
>>>>> +#include 
>>>>> +
>>>>> +#include 
>>>>> +#include 
>>>>> +
>>>>> +static spinlock_t vmid_alloc_lock = SPIN_LOCK_UNLOCKED;
>>>>> +
>>>>> +/*
>>>>> + * hgatp's VMID field is 7 or 14 bits. RV64 may support 14-bit VMID.
>>>>> + * Using a bitmap here limits us to 127 (2^7 - 1) or 16383 (2^14 - 1)
>>>>> + * concurrent domains.
>>>> Which is pretty limiting especially in the RV32 case. Hence why we don't
>>>> assign a permanent ID to VMs on x86, but rather manage IDs per-CPU (note:
>>>> not per-vCPU).
>>> Good point.
>>>
>>> I don't believe anyone will use RV32.
>>> For RV64, the available ID space seems sufficiently large.
>>>
>>> However, if it turns out that the value isn't large enough even for RV64,
>>> I can rework it to manage IDs per physical CPU.
>>> Wouldn't that approach result in more TLB entries being flushed compared
>>> to per-vCPU allocation, potentially leading to slightly worse performance?
>> Depends on the condition for when to flush. Of course performance is
>> unavoidably going to suffer if you have only very few VMIDs to use.
>> Nevertheless, as indicated before, the model used on x86 may be a
>> candidate to use here, too. See hvm_asid_handle_vmenter() for the
>> core (and vendor-independent) part of it.
> 
> IIUC, so basically it is just a round-robin and when VMIDs are ran out
> then just do full guest TLB flush and start to re-use VMIDs from the start.
> It makes sense to me, I'll implement something similar. (as I'm not really
> sure that we needdata->core_asid_generation, probably, I will understand it better when 
> start to implement it)

Well. The fewer VMID bits you have the more quickly you will need a new
generation. And keep track of the generation you're at you also need to
track the present number somewhere.

>>> What about then to allocate VMID per-domain?
>> That's what you're doing right now, isn't it? And that gets problematic when
>> you have only very few bits in hgatp.VMID, as mentioned below.
> 
> Right, I just phrased my question poorly—sorry about that.
> 
> What I meant to ask is: does the approach described above actually depend on whether
> VMIDs are allocated per-domain or per-pCPU? It seems that the main advantage of
> allocating VMIDs per-pCPU is potentially reducing the number of TLB flushes,
> since it's more likely that a platform will have more than|VMID_MAX| domains than
> |VMID_MAX| physical CPUs—am I right?

Seeing that there can be systems with hundreds or even thousands of CPUs,
I don't think I can agree here. Plus per-pCPU allocation would similarly
get you in trouble when you have only very few VMID bits.

>>>>> +        sbi_remote_hfence_gvma_vmid(d->dirty_cpumask, 0, 0, p2m->vmid);
>>>> You're creating d; it cannot possibly have run on any CPU yet. IOW
>>>> d->dirty_cpumask will be reliably empty here. I think it would be hard to
>>>> avoid issuing the flush to all CPUs here in this scheme.
>>> I didn't double check, but I was sure that in case d->dirty_cpumask is empty then
>>> rfence for all CPUs will be send. But I was wrong about that.
>>>
>>> What about just update a code of sbi_rfence_v02()?
>> I don't know, but dealing with the issue there feels wrong. However,
>> before deciding where to do something, it needs to be clear what you
>> actually want to achieve. To me at least, that's not clear at all.
> 
> I want to achieve the following behavior: if a mask is empty
> (specifically, in our case|d->dirty_cpumask|), then perform the flush
> on all CPUs.

That's still too far into the "how". The "why" here is still unclear: Why
do you need any flushing here at all? (With the scheme you now mean to
implement I expect it'll become yet more clear that no flush is needed
during domain construction.)

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 14:05:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 14:05:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023763.1399818 (Exim 4.92)
	(envelope-from )
	id 1uU4HX-0003KV-7z; Tue, 24 Jun 2025 14:05:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023763.1399818; Tue, 24 Jun 2025 14:05:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uU4HX-0003KO-46; Tue, 24 Jun 2025 14:05:51 +0000
Received: by outflank-mailman (input) for mailman id 1023763;
 Tue, 24 Jun 2025 14:05:49 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uU4HV-0003KI-LH
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 14:05:49 +0000
Received: from mail-oo1-xc33.google.com (mail-oo1-xc33.google.com
 [2607:f8b0:4864:20::c33])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 50bdfa26-5104-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 16:05:43 +0200 (CEST)
Received: by mail-oo1-xc33.google.com with SMTP id
 006d021491bc7-604ad0347f5so1293293eaf.2
 for ; Tue, 24 Jun 2025 07:05:43 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 50bdfa26-5104-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750773942; x=1751378742; 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=Bn8mrYwmbv0mNoEDLwFl4hXErZo20REMJyiJd3QKTmk=;
        b=Iv6fQ4AFegESZzj5EZFDlIe5l9aSFeUB1yby9/XW2eyy+g4miUO7xDGnX+SQVqiLVa
         VRkAU+YYhp0v6aEAzPECP+AEM1WeqpLF53xvc0lbCjjplCjVAuriwn4nt58X0NIbZEdO
         2db7vAs398l2xgLnS7EkvpPWNZEMyJcD9N5/I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750773942; x=1751378742;
        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=Bn8mrYwmbv0mNoEDLwFl4hXErZo20REMJyiJd3QKTmk=;
        b=MFBRzon1Lxfff7rkfWZ9j0+7EKMHUJzoxpjofKHwuxHJBRT908UCiO5ReR4gntd6ji
         u11rAXzqe9jgWbeMISzz0+iWTaOuPvc6cJ++gd0PdKBmsZxB1ffi41TUUNwfua5eznIQ
         87kJNZGW+bPsqH7/Ku8ggVcgSG+3/tTsckJ7k5Tz+17be2FYc4ONjtIold7ArtyyPli7
         0yELvXzPEpPJ7n2KY6299/WwLNa58SDfbocPsjcJa59Pyt5j6y1TUsTxsozbwV0NJpVd
         guiL65F2f4FQEJ0y2ccJtBXoGWIDNu08BhxNgaZOqnsEk6fKzd+/D48Qd9tz5wRZRN53
         OcSQ==
X-Gm-Message-State: AOJu0Yxa0X8DXitRmP0XftSViCxLI6a0rpyIEQeFnldTz8iP20Rsdbk+
	6ZH3UrABiFheJ0zVcSFZaQDvNQ6AgFlTSPWoX2KTP1RUeD3QW1bAwiz1M2l4gbO/mj18Knx62vj
	ogynSSPYFw/ZG/hD/2HPUdwiNrawGcTrdWapWLoHF5VocxN3dRaFuJ5gtOw==
X-Gm-Gg: ASbGncuI3QHrLSAQbenOeJHpyfvfARKmAOq86XJOTwg0l0Z400FGgrdLdePSvSrYSEJ
	BBzTnOiiUBgvzD8zi63zm5CZxdgptrvd4CZQ6EJUFqv1BdMsOFOJKPhbG8WZ8T+XBURtKboTDbK
	JWs7zWfqjcqq2zyx9jBBSplJQWzRpvwZb3f+Pa81xW
X-Google-Smtp-Source: AGHT+IFv95mUUUr/3h/xYXf41bUt+lbdyzEWbiAlx4S+0wclXtwk6erbCM5fwmF7K+6ZsID/bDgQZHPd8kSIu5xOL8A=
X-Received: by 2002:a05:6870:ff8f:b0:2b8:2f9c:d513 with SMTP id
 586e51a60fabf-2eeee4e519fmr10830188fac.19.1750773941687; Tue, 24 Jun 2025
 07:05:41 -0700 (PDT)
MIME-Version: 1.0
References: <20250624083157.9334-1-frediano.ziglio@cloud.com>
 <20250624083157.9334-2-frediano.ziglio@cloud.com> 
In-Reply-To: 
From: Frediano Ziglio 
Date: Tue, 24 Jun 2025 15:05:25 +0100
X-Gm-Features: AX0GCFsw559r3c4YqwVi6MfZtI6Z6EN0X3ELxEvnuZCTFQwSOEywCwNvfhn-niY
Message-ID: 
Subject: Re: [PATCH 1/2] xen/efi: Handle cases where file didn't come from ESP
To: =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= 
Cc: xen-devel@lists.xenproject.org, 
	"Daniel P. Smith" , Jan Beulich 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 24, 2025 at 1:38=E2=80=AFPM Marek Marczykowski-G=C3=B3recki
 wrote:
>
> On Tue, Jun 24, 2025 at 09:31:54AM +0100, Frediano Ziglio wrote:
> > A boot loader can load files from outside ESP.
> > In these cases device could be not provided or path could
> > be something not supported.
> > In these cases allows to boot anyway, all information
> > could be provided using UKI or using other boot loader
> > features.
> >
> > Signed-off-by: Frediano Ziglio 
> > ---
> >  xen/common/efi/boot.c | 27 +++++++++++++++++++++++++--
> >  1 file changed, 25 insertions(+), 2 deletions(-)
> >
> > diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> > index 1a9b4e7dae..2a49c6d05d 100644
> > --- a/xen/common/efi/boot.c
> > +++ b/xen/common/efi/boot.c
> > @@ -443,6 +443,18 @@ static EFI_FILE_HANDLE __init get_parent_handle(co=
nst EFI_LOADED_IMAGE *loaded_i
> >      CHAR16 *pathend, *ptr;
> >      EFI_STATUS ret;
> >
> > +    /*
> > +     * In some cases the image could not come from a specific device.
> > +     * For instance this can happen if Xen was loaded using GRUB2 "lin=
ux"
> > +     * command.
> > +     */
> > +    *leaf =3D buffer;
>
> This feels wrong, if DeviceHandle is NULL, it will point at the
> empty buffer that shouldn't really be used for anything anyway.
>

Yes, this was done just to make the compiler happy, I changed to
assign NULL instead.

> IMO a better option would be to add "&& dir_handle" to the condition
> guarding use of file_name in efi_start() instead.
>

Yes, it makes sense. Done.

> BTW, by my reading of get_parent_handle() theoretically it should be
> possible to get _some_ name out of loaded_image->FilePath even without
> dir_handle. But since it isn't going to be used, it's not worth it.
>
> > +    if ( !loaded_image->DeviceHandle )
> > +    {
> > +        PrintStr(L"Xen image loaded without providing a device\r\n");
> > +        return NULL;
> > +    }
> > +
> >      do {
> >          EFI_FILE_IO_INTERFACE *fio;
> >
> > @@ -466,7 +478,15 @@ static EFI_FILE_HANDLE __init get_parent_handle(co=
nst EFI_LOADED_IMAGE *loaded_i
> >
> >          if ( DevicePathType(dp) !=3D MEDIA_DEVICE_PATH ||
> >               DevicePathSubType(dp) !=3D MEDIA_FILEPATH_DP )
> > -            blexit(L"Unsupported device path component");
> > +        {
> > +            /*
> > +             * The image could come from an unsupported device.
> > +             * For instance this can happen if Xen was loaded using GR=
UB2
> > +             * "chainloader" command and the file was not from ESP.
> > +             */
> > +            PrintStr(L"Unsupported device path component\r\n");
> > +            return NULL;
> > +        }
> >
> >          if ( *buffer )
> >          {
> > @@ -772,6 +792,8 @@ static bool __init read_file(EFI_FILE_HANDLE dir_ha=
ndle, CHAR16 *name,
> >
> >      if ( !name )
> >          PrintErrMesg(L"No filename", EFI_OUT_OF_RESOURCES);
> > +    if ( !dir_handle )
> > +        return false;
>
> There are a lot of places where read_file() is used without checking its
> return value. Which made sense since before this change the only cases
> where read_file() would return false was for the config file, in all
> other cases it handled errors via blexit().
> Most of those read_file() calls seems to be fine (as in, will not
> explode), but may still be confusing. For example when you embed a
> config with "xsm=3Dpolicy" (but the actual policy is not embedded) now th=
e
> failure to load it will result just a warning ("Xen image loaded without
> providing a device") not even related to the file name and it will
> continue booting with unintended configuration.
>

Yes, it makes sense. Changing the code to handle dir_handle =3D=3D NULL as
Open returning EFI_NOT_FOUND so all failures (beside configuration)
will become fatal as before.

OT: the flow of read_file (specifically "what" handling) looks
weird... can I change it?

> For me it looks like this change is wrong: if the config specified a
> file to load (and that blob was not embedded in the UKI), and yet it
> couldn't be loaded, it should fail early.
> Is there any (new) case where where read_file() failure (when it
> actually gets to calling it) should really be non-fatal now?
>
> In relation to the next patch - such UKI should simply not specify
> ramdisk in the embedded config, to allow loading it via "initrd"
> command. This would avoid calling read_file().
>
> >      ret =3D dir_handle->Open(dir_handle, &FileHandle, name,
> >                             EFI_FILE_MODE_READ, 0);
> >      if ( file =3D=3D &cfg && ret =3D=3D EFI_NOT_FOUND )
> > @@ -1515,7 +1537,8 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE =
ImageHandle,
> >          efi_bs->FreePages(cfg.addr, PFN_UP(cfg.size));
> >          cfg.addr =3D 0;
> >
> > -        dir_handle->Close(dir_handle);
> > +        if ( dir_handle )
> > +            dir_handle->Close(dir_handle);
> >
> >          if ( gop && !base_video )
> >          {

Frediano


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 14:27:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 14:27:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023775.1399834 (Exim 4.92)
	(envelope-from )
	id 1uU4cM-0006bv-7x; Tue, 24 Jun 2025 14:27:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023775.1399834; Tue, 24 Jun 2025 14:27:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uU4cM-0006bi-1Q; Tue, 24 Jun 2025 14:27:22 +0000
Received: by outflank-mailman (input) for mailman id 1023775;
 Tue, 24 Jun 2025 14:27: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 1uU4cL-0006YR-HG
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 14:27:21 +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 559fc07b-5107-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 16:27:19 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3a531fcaa05so2431329f8f.3
 for ; Tue, 24 Jun 2025 07:27:19 -0700 (PDT)
Received: from localhost.localdomain (253.226.6.51.dyn.plus.net.
 [51.6.226.253]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45380705351sm4602115e9.0.2025.06.24.07.27.17
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 24 Jun 2025 07:27:18 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 559fc07b-5107-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750775238; x=1751380038; 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=1mBjtI5raQ25OjXe0+sC0wwT7xvu83F7yHgPnqqLXpY=;
        b=GXqILefRexbyI6FwSUm5bhWo7fmLd9kiXP5B8rpcblj2YGLRCIsZ/2WdBSyclnOC2C
         AEr9fW9Hi5mobGmt7b0Q8sgArmAX3q3kwiG7Bzg1TvLCQVY12GCUm57FQm8yRLXDRYUS
         u4jO5ztXMIKjjEbULCz+efmTxlm6NVf07M3T4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750775238; x=1751380038;
        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=1mBjtI5raQ25OjXe0+sC0wwT7xvu83F7yHgPnqqLXpY=;
        b=ufovB21kTRc87IseTTuo8gCaApfvrPRAdr78SbAz2hHPDrtqZ/s8cJVdFsbar+yqEQ
         tdfhyvCatuKAIp6F7MkZb5Jn94Sv5NvpzWiX9rIwJsw19LCqLDARdK5QGNRG1z868JcZ
         eQ6kIwsMTCGrxBNa1nVtWfDxh0OPR/Xl3Y2pnaJXpsYYxJR4gP6anTCOnUaHgpivcH1E
         iZZmt4+gPk7TvWlIeD/zz+SlYcpLv2HRDEqBciq2i/NBUbBx4Ei9D8LqR4GMILPlTE8g
         FHEycvI9BmilbdZEDilUbQJmdpujvyJaFK7R+Cv17BXWsynU9hCKxsqLHc4yjP8OkYr3
         lEYw==
X-Gm-Message-State: AOJu0YzlwMTaIdQNjhwSmWui13dwT+iaUmX83JMfHGwiwJOT1UVVeMZY
	za5m+pDOm8P8xSm4NntbxTyKQNsQN+sdacH0GZxx8Kr/pTejV/we7fQEfshXTKTa3saEbv5uR3/
	K7k5PfRq6/A==
X-Gm-Gg: ASbGncsV37KKtHC+aO8BUpexPzebdCZn5O15oC4wrzzaViseZCrKh9BBhKENeOhBrgj
	CixAz7BdLA5yZ4PL7CL0lqaEER9ckUJU1SnziMzqLqJvzUGNreGDQYZmUM2CHZAWLkDHA4tCIv9
	o+q8SuRmT2KqLB2flpTJBZU/munrxc0/m9dG53CwaUUIO/MNECjm6/5shf5sR/4YAJFtUe34CKf
	ewVswmrbwQJg2818z88acV+gxijosKBVrpktcGhcD+1j57/cUd4kMJoBMfGJjiv2c1C2goS74UP
	5TwIVjU0zemwpnzp+c1OLxQQHboXZssXHSRb12EyASv98P+JykdXviIgeUGCfWHEYS0h/XOOrPq
	a2Nit+E9K7IBka3/eZw3l46lvtrzItQ==
X-Google-Smtp-Source: AGHT+IGA4Iy4DR72Mj9/KuO4EyvaQcvpIUi1o0Y0hczLkFPQjhj6mw6JoILmIC4qxzBLAJXLGRwukg==
X-Received: by 2002:a05:6000:2107:b0:3a6:d967:380e with SMTP id ffacd0b85a97d-3a6d9673ec5mr7880515f8f.3.1750775238428;
        Tue, 24 Jun 2025 07:27:18 -0700 (PDT)
From: Frediano Ziglio 
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio ,
	"Daniel P. Smith" ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Jan Beulich 
Subject: [PATCH v2 0/2] xen/efi: Make boot more flexible, especially with GRUB2
Date: Tue, 24 Jun 2025 15:27:07 +0100
Message-ID: <20250624142711.54925-1-frediano.ziglio@cloud.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The combination of GRUB2, EFI and UKI allows potentially more flexibility.
For instance is possible to load xen.efi from a no ESP partition leaving
a boot loader like GRUB2 taking care of the file loading.
This however requires some changes in Xen to be less restrictive.
Specifically for GRUB2 these changes allows the usage of "chainloader"
command with UKI and reading xen.efi from no ESP (so no DeviceHandle
set) and usage of "linux" and "initrd" commands to load separately
the kernel (embedding using UKI) and initrd (using LoadFile2 protocol).

Changes since v1:
- keep read_file fatal when it was so;
- attempt to use LoadFile2 after trying object section;
- minor changes (see details on specific changes).

Frediano Ziglio (2):
  xen/efi: Handle cases where file didn't come from ESP
  xen/efi: Support loading initrd using GRUB2 LoadFile2 protocol

 xen/common/efi/boot.c     | 105 +++++++++++++++++++++++++++++++++++---
 xen/include/efi/efidevp.h |  21 ++++++++
 2 files changed, 120 insertions(+), 6 deletions(-)

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 14:27:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 14:27:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023774.1399828 (Exim 4.92)
	(envelope-from )
	id 1uU4cL-0006Yj-TE; Tue, 24 Jun 2025 14:27:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023774.1399828; Tue, 24 Jun 2025 14:27: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 1uU4cL-0006Yc-QS; Tue, 24 Jun 2025 14:27:21 +0000
Received: by outflank-mailman (input) for mailman id 1023774;
 Tue, 24 Jun 2025 14:27: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 1uU4cL-0006YQ-De
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 14:27:21 +0000
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com
 [2a00:1450:4864:20::32d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 561e875a-5107-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 16:27:20 +0200 (CEST)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-453608ed113so47946965e9.0
 for ; Tue, 24 Jun 2025 07:27:20 -0700 (PDT)
Received: from localhost.localdomain (253.226.6.51.dyn.plus.net.
 [51.6.226.253]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45380705351sm4602115e9.0.2025.06.24.07.27.18
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 24 Jun 2025 07:27:18 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 561e875a-5107-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750775239; x=1751380039; darn=lists.xenproject.org;
        h=content-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=zvSWfU3vS+cIfE2UVvh70sxlin2NyiKeV2rfWj9rRaM=;
        b=hUjxIUesXR7KB+0kFJ5Y+qlyjrPUfgZB+PBb7/YrlLRi9rXMNz8TJYpBUcjmsJjjKa
         QNVgUnxqDp8PkRbOs0yRXoGp/Lhd4pGxqEHv39d2+Y2VKtNWotOu8iq9Ur/I07nktpie
         7fQl4HrEbZU0zwXrllCqRncp7vvpd0yuTH90E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750775239; x=1751380039;
        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=zvSWfU3vS+cIfE2UVvh70sxlin2NyiKeV2rfWj9rRaM=;
        b=cUKbWtaSgLtEzKmw+hFkcUj+Fd9vxD+4rtnfm5016z2YPENYpZq06n1TNHW1Tgtp0x
         5IDXloa+54RxHuElgKkfYhWWsBXtQpusTUcWrNvVqJeCH5iVcSBOIoymlp+98B0MD7ZI
         FGilG2fkeGcaDlquBjMBHAS4wx8+tS884qdMccrylRutZJJJG4QhYUB4HJFmaS1iuNeU
         K7WSd3dV5Hy3ntmlg9p5iJJG/aicwd2qf0yIs1qAdKXm1PuwuWCr9ub9FDO9RTs/J9l8
         lO377SMgEJHcM2bIaFFLqYKRBskndIUeJapU3zYa67mA2MLKXMBUBgWsnR4FSgKesmH7
         cVrQ==
X-Gm-Message-State: AOJu0YwEJv/bLQJASrBezgfHlfdqSIYhS1hFoC1bJCnN51R+vNwkO32S
	xpOKmsQuQNFsvXTLBUKHTANHfMgQcHf7FMwW0xeD0xvJKFEFkx9nnZSK76T7JHdD1wLIqtPtkRg
	e8xlOCEdEzA==
X-Gm-Gg: ASbGnctMDc3gOLH5aeJhminwc+AcwN49vaoQUrdmbDw20+VGEGbwLxnC+oyiHF+T2Op
	mlvG4Yll3yX7L8z5ekPknZNDEUZxJEGyG/rXhb6FTuDtCH9XAUQW2iYK+pFNsiodf+A/PgkkvUq
	Rsr9yIZZ13PuNtiearYgKBV8/XVUV69gN17jus3s0b9sT0SYs0NaITidk1rXqyKYyLzQaZQBJ3q
	Xc8HjyCdSMzcS+Vi0nouZUT4k+eXqGDIAa0+FC1VrwZKI69NR85d6EahnH/xK1T863Uyz+xeDNz
	j6eh6ZYqH1MkIk+QLaRMEgfgUNdEVmDlIjgikAc/hgnbN8MD6TFaliNeYACnoRZ6J2rxorhOM1R
	ub3qrJhws2ivhbkg8LoudAd3EouRWdA==
X-Google-Smtp-Source: AGHT+IGed5CPjvOm2EqjTNPtlDK3NJOxPCE24eAzf5yW8bJSP56J1fQACDEGP8alWi51zx4L7c8xGw==
X-Received: by 2002:a05:600c:3d8d:b0:441:b3eb:574e with SMTP id 5b1f17b1804b1-453659c48cemr157512105e9.5.1750775239213;
        Tue, 24 Jun 2025 07:27:19 -0700 (PDT)
From: Frediano Ziglio 
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio ,
	"Daniel P. Smith" ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Jan Beulich 
Subject: [PATCH v2 1/2] xen/efi: Handle cases where file didn't come from ESP
Date: Tue, 24 Jun 2025 15:27:08 +0100
Message-ID: <20250624142711.54925-2-frediano.ziglio@cloud.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250624142711.54925-1-frediano.ziglio@cloud.com>
References: <20250624142711.54925-1-frediano.ziglio@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

A boot loader can load files from outside ESP.
In these cases device could be not provided or path could
be something not supported.
In these cases allows to boot anyway, all information
could be provided using UKI or using other boot loader
features.

Signed-off-by: Frediano Ziglio 
---
Changes since v1:
- set "leaf" to NULL instead of a buffer with an empty string;
- keep read_file fatal if cannot load file (except configuration).
---
 xen/common/efi/boot.c | 34 +++++++++++++++++++++++++++++-----
 1 file changed, 29 insertions(+), 5 deletions(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 1a9b4e7dae..b18af2f1f4 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -443,6 +443,18 @@ static EFI_FILE_HANDLE __init get_parent_handle(const EFI_LOADED_IMAGE *loaded_i
     CHAR16 *pathend, *ptr;
     EFI_STATUS ret;
 
+    /*
+     * In some cases the image could not come from a specific device.
+     * For instance this can happen if Xen was loaded using GRUB2 "linux"
+     * command.
+     */
+    *leaf = NULL;
+    if ( !loaded_image->DeviceHandle )
+    {
+        PrintStr(L"Xen image loaded without providing a device\r\n");
+        return NULL;
+    }
+
     do {
         EFI_FILE_IO_INTERFACE *fio;
 
@@ -466,7 +478,15 @@ static EFI_FILE_HANDLE __init get_parent_handle(const EFI_LOADED_IMAGE *loaded_i
 
         if ( DevicePathType(dp) != MEDIA_DEVICE_PATH ||
              DevicePathSubType(dp) != MEDIA_FILEPATH_DP )
-            blexit(L"Unsupported device path component");
+        {
+            /*
+             * The image could come from an unsupported device.
+             * For instance this can happen if Xen was loaded using GRUB2
+             * "chainloader" command and the file was not from ESP.
+             */
+            PrintStr(L"Unsupported device path component\r\n");
+            return NULL;
+        }
 
         if ( *buffer )
         {
@@ -772,8 +792,11 @@ static bool __init read_file(EFI_FILE_HANDLE dir_handle, CHAR16 *name,
 
     if ( !name )
         PrintErrMesg(L"No filename", EFI_OUT_OF_RESOURCES);
-    ret = dir_handle->Open(dir_handle, &FileHandle, name,
-                           EFI_FILE_MODE_READ, 0);
+    if ( dir_handle )
+        ret = dir_handle->Open(dir_handle, &FileHandle, name,
+                               EFI_FILE_MODE_READ, 0);
+    else
+        ret = EFI_NOT_FOUND;
     if ( file == &cfg && ret == EFI_NOT_FOUND )
         return false;
     if ( EFI_ERROR(ret) )
@@ -1404,7 +1427,7 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle,
         /* Read and parse the config file. */
         if ( read_section(loaded_image, L"config", &cfg, NULL) )
             PrintStr(L"Using builtin config file\r\n");
-        else if ( !cfg_file_name )
+        else if ( !cfg_file_name && file_name)
         {
             CHAR16 *tail;
 
@@ -1515,7 +1538,8 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle,
         efi_bs->FreePages(cfg.addr, PFN_UP(cfg.size));
         cfg.addr = 0;
 
-        dir_handle->Close(dir_handle);
+        if ( dir_handle )
+            dir_handle->Close(dir_handle);
 
         if ( gop && !base_video )
         {
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 14:27:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 14:27:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023776.1399848 (Exim 4.92)
	(envelope-from )
	id 1uU4cN-0006zu-Aw; Tue, 24 Jun 2025 14:27:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023776.1399848; Tue, 24 Jun 2025 14:27: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 1uU4cN-0006zn-83; Tue, 24 Jun 2025 14:27:23 +0000
Received: by outflank-mailman (input) for mailman id 1023776;
 Tue, 24 Jun 2025 14:27: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 1uU4cM-0006YQ-3H
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 14:27:22 +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 569b13fd-5107-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 16:27:21 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-4537fdec39fso2171485e9.0
 for ; Tue, 24 Jun 2025 07:27:20 -0700 (PDT)
Received: from localhost.localdomain (253.226.6.51.dyn.plus.net.
 [51.6.226.253]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45380705351sm4602115e9.0.2025.06.24.07.27.19
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 24 Jun 2025 07:27:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 569b13fd-5107-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750775240; x=1751380040; darn=lists.xenproject.org;
        h=content-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=LGXZEs8C2ojkzsUWVpaRntklr8ldtVYfN6U4O6Kve+s=;
        b=EbAe/wpeqoc9+49NFKzLEo/E3tj0vVgoyA8TB9x0SAxLWw84wTBuRfw/zVxCQlFhwE
         3X56KaqiO1QFnsWEkYuQDIdyOKNoIYqJUV3o+iPj/7raTUEKq7KPvSK0y4RMTEEfxvZV
         yfFwCG0W1Wn6HPC+TcE4ro1HsXi5Bpj73BO2c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750775240; x=1751380040;
        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=LGXZEs8C2ojkzsUWVpaRntklr8ldtVYfN6U4O6Kve+s=;
        b=GZOYACIQDlMl7roqeP346Vph1ZoVVD+Km1wWlKprA4YCRwTBi2uVWXmkWDKu8bUylJ
         xFvGhofhtJQ8sBOVv24Ls4z8KPXNRPPAn5PpWxswy0dztXfuwi+S3ohKlpNOkq9yzYry
         zwMuTPqm/bDb4VYZooSX+vGaVVIm4en/Y07wXgM0ImHomyML9OnMMu0xGb38ALWZCX1M
         lKDHib9cA6oiutT+cRDahOcUO+4bV8pmv674fso4o+LRUi7FswN1xkyDAGBHmqoeHll3
         joas2E3ZtLmulWGmcwjFdi5IH6iYMQHhNC6QAL0TpqyEkhn227P1ye/CxYwPJEU7LCNI
         BNtA==
X-Gm-Message-State: AOJu0YyoYjLMfCC6tyuF3sm+ZeRLK0wyrAlgwlJWAdf8vTmZLmDt8hRT
	O6o2yQGFY8L2BEA582DKZRV5DQJ14Lti9yLjh0z6uSQeq9HXyQ2befcHI3pa1r92T4xrRiLDh9a
	QUXtwruxQAA==
X-Gm-Gg: ASbGncsPkvITzfMqcW+JCE6cwCcEfiB05isMU1aYdKzP/CvRnWQOZVG8MJwOVBhcmf8
	YeZtUqVpWVnoQBIOPbxUEXQw45zAz7xBSH3Wk4Tfzb36GocCj6OjHEH2Pah5GBavutAmHpDXA03
	qkHpmeEBEC1EH23mC9zFgUAK22dwsnYsoJizpuYcqCngWuohE8sgZysVVBrvsxTboZJ6wO+qilp
	Vl7yI/oxl0kvq/x7BOe90u8u1vPfPHMD8OL/LAfQ7fakA8o+hd6MIk35TjHzf0DprUnR5bWrUSD
	wyPwxCp0XueuzcfLes4w+fzoyoxZJeLOAV6spMU2C1Xdlmj5yl2zBfmnoSf7XOBp5X1gZ4zOdR3
	0edLgeR69Wv/BZxnbQtE9whq4EiWptA==
X-Google-Smtp-Source: AGHT+IHYNga+DRn2K3B0qKtZbb3Yr1jJ3U11q1x65KLpALUXLiHsyFxqnFKSdE9qm9yUMVcJf3mSuA==
X-Received: by 2002:a05:600c:c083:b0:450:d01e:78ee with SMTP id 5b1f17b1804b1-4536bf70111mr79669005e9.24.1750775240067;
        Tue, 24 Jun 2025 07:27:20 -0700 (PDT)
From: Frediano Ziglio 
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio ,
	"Daniel P. Smith" ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Jan Beulich 
Subject: [PATCH v2 2/2] xen/efi: Support loading initrd using GRUB2 LoadFile2 protocol
Date: Tue, 24 Jun 2025 15:27:09 +0100
Message-ID: <20250624142711.54925-3-frediano.ziglio@cloud.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250624142711.54925-1-frediano.ziglio@cloud.com>
References: <20250624142711.54925-1-frediano.ziglio@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Allows to load Xen using "linux" and "initrd" GRUB2 commands.
This can be used with UKI to separate initrd in a different module
instead of bundling all together.
Bundling all together can be a problem with Secure Boot where
we need to sign the bundle making harder to change it.
As initrd content does not need to be signed for Secure Boot
bundling it force it to be signed too.

Signed-off-by: Frediano Ziglio 
---
Changes since v1:
- attempt to use LoadFile2 protocol after embedded section.
---
 xen/common/efi/boot.c     | 71 ++++++++++++++++++++++++++++++++++++++-
 xen/include/efi/efidevp.h | 21 ++++++++++++
 2 files changed, 91 insertions(+), 1 deletion(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index b18af2f1f4..b6ce3a0257 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -850,6 +850,74 @@ static bool __init read_file(EFI_FILE_HANDLE dir_handle, CHAR16 *name,
     return true;
 }
 
+#pragma pack(1)
+typedef struct {
+    VENDOR_DEVICE_PATH              VenMediaNode;
+    EFI_DEVICE_PATH                 EndNode;
+} SINGLE_NODE_VENDOR_MEDIA_DEVPATH;
+#pragma pack()
+
+static bool __init initrd_load_file2(const CHAR16 *name, struct file *file)
+{
+    static const SINGLE_NODE_VENDOR_MEDIA_DEVPATH __initconst initrd_dev_path = {
+        {
+            {
+                MEDIA_DEVICE_PATH, MEDIA_VENDOR_DP, { sizeof (VENDOR_DEVICE_PATH) }
+            },
+            LINUX_EFI_INITRD_MEDIA_GUID
+        },
+        {
+            END_DEVICE_PATH_TYPE, END_ENTIRE_DEVICE_PATH_SUBTYPE,
+            { sizeof (EFI_DEVICE_PATH) }
+        }
+    };
+    static EFI_GUID __initdata lf2_proto_guid = EFI_LOAD_FILE2_PROTOCOL_GUID;
+    EFI_DEVICE_PATH *dp;
+    EFI_LOAD_FILE2_PROTOCOL *lf2;
+    EFI_HANDLE handle;
+    EFI_STATUS ret;
+    UINTN size;
+
+    dp = (EFI_DEVICE_PATH *)&initrd_dev_path;
+    ret = efi_bs->LocateDevicePath(&lf2_proto_guid, &dp, &handle);
+    if ( EFI_ERROR(ret) )
+    {
+        if ( ret == EFI_NOT_FOUND)
+            return false;
+        PrintErrMesg(L"Error getting file with LoadFile2 interface", ret);
+    }
+
+    ret = efi_bs->HandleProtocol(handle, &lf2_proto_guid, (void **)&lf2);
+    if ( EFI_ERROR(ret) )
+        PrintErrMesg(L"LoadFile2 file does not provide correct protocol", ret);
+
+    size = 0;
+    ret = lf2->LoadFile(lf2, dp, false, &size, NULL);
+    if ( ret != EFI_BUFFER_TOO_SMALL )
+        PrintErrMesg(L"Loading failed", ret);
+
+    file->addr = min(1UL << (32 + PAGE_SHIFT),
+                     HYPERVISOR_VIRT_END - DIRECTMAP_VIRT_START);
+    ret = efi_bs->AllocatePages(AllocateMaxAddress, EfiLoaderData,
+                                PFN_UP(size), &file->addr);
+    if ( EFI_ERROR(ret) )
+        PrintErrMesg(L"Allocation failed", ret);
+
+    file->need_to_free = true;
+    file->size = size;
+
+    ret = lf2->LoadFile(lf2, dp, false, &size, file->str);
+    if ( EFI_ERROR(ret) )
+    {
+        efi_bs->FreePages(file->addr, PFN_UP(size));
+        PrintErrMesg(L"Loading failed", ret);
+    }
+
+    efi_arch_handle_module(file, name, NULL);
+
+    return true;
+}
+
 static bool __init read_section(const EFI_LOADED_IMAGE *image,
                                 const CHAR16 *name, struct file *file,
                                 const char *options)
@@ -1493,7 +1561,8 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle,
             kernel_verified = true;
         }
 
-        if ( !read_section(loaded_image, L"ramdisk", &ramdisk, NULL) )
+        if ( !read_section(loaded_image, L"ramdisk", &ramdisk, NULL) &&
+             !initrd_load_file2(L"ramdisk", &ramdisk) )
         {
             name.s = get_value(&cfg, section.s, "ramdisk");
             if ( name.s )
diff --git a/xen/include/efi/efidevp.h b/xen/include/efi/efidevp.h
index beb5785a45..b240c15d2a 100644
--- a/xen/include/efi/efidevp.h
+++ b/xen/include/efi/efidevp.h
@@ -398,5 +398,26 @@ typedef union {
 
 } EFI_DEV_PATH_PTR;
 
+#define EFI_LOAD_FILE2_PROTOCOL_GUID \
+    { 0x4006c0c1, 0xfcb3, 0x403e, {0x99, 0x6d, 0x4a, 0x6c, 0x87, 0x24, 0xe0, 0x6d } }
+
+typedef struct EFI_LOAD_FILE2_PROTOCOL EFI_LOAD_FILE2_PROTOCOL;
+
+typedef
+EFI_STATUS
+(EFIAPI *EFI_LOAD_FILE2)(
+    IN EFI_LOAD_FILE2_PROTOCOL      *This,
+    IN EFI_DEVICE_PATH              *FilePath,
+    IN BOOLEAN                      BootPolicy,
+    IN OUT UINTN                    *BufferSize,
+    IN VOID                         *Buffer OPTIONAL
+    );
+
+struct EFI_LOAD_FILE2_PROTOCOL {
+    EFI_LOAD_FILE2                  LoadFile;
+};
+
+#define LINUX_EFI_INITRD_MEDIA_GUID \
+    { 0x5568e427, 0x68fc, 0x4f3d, {0xac, 0x74, 0xca, 0x55, 0x52, 0x31, 0xcc, 0x68} }
 
 #endif
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 14:35:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 14:35:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023795.1399858 (Exim 4.92)
	(envelope-from )
	id 1uU4kM-0000wz-59; Tue, 24 Jun 2025 14:35:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023795.1399858; Tue, 24 Jun 2025 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 1uU4kM-0000ws-1X; Tue, 24 Jun 2025 14:35:38 +0000
Received: by outflank-mailman (input) for mailman id 1023795;
 Tue, 24 Jun 2025 14:35: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 1uU4kK-0000wk-F1
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 14:35:36 +0000
Received: from fhigh-b6-smtp.messagingengine.com
 (fhigh-b6-smtp.messagingengine.com [202.12.124.157])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7c5c4bcb-5108-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 16:35:34 +0200 (CEST)
Received: from phl-compute-05.internal (phl-compute-05.phl.internal
 [10.202.2.45])
 by mailfhigh.stl.internal (Postfix) with ESMTP id 262FF7A01B1;
 Tue, 24 Jun 2025 10:35:33 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-05.internal (MEProxy); Tue, 24 Jun 2025 10:35:33 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 24 Jun 2025 10:35:31 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7c5c4bcb-5108-11f0-a30f-13f23c93f187
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=1750775733;
	 x=1750862133; bh=1o5WLUPC3/xWp3VpukBP3ELtP/YYgjUGaXyyigzAvT4=; b=
	SUBlFZQRi+yj7t7+jhRcQEu1eUUnkm8zWZtY9bCwZ/HvJkuWu1OFZp+uI3ojTGpQ
	+Q3V3unEX0StNZtk5cDgJI9+MUmwEUEF+OUzJ/n8OBP8dbNvO3WIz6twSKfhanOM
	vhjBsaAT9vb0YB87QXspSstvjTev3vpR6FJD5xiQMEYAtjggbVrkur/uq92Zg1SU
	JD26Di5lNBYfRzlQwZC7FCM9wRaWg71jtmMUusGpQxEQNIBTPjukvfXXT9OoKKgx
	3OBAn8oj0/5DrVyYVqwYUSWBFYtgn7Nf+GWJ4yZs4OOZS2sF7d4XEYsWrYPlhub5
	6JoGgEizoiVPJQaVVJ+kZw==
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=
	1750775733; x=1750862133; bh=1o5WLUPC3/xWp3VpukBP3ELtP/YYgjUGaXy
	yigzAvT4=; b=FcnNIE72P7bk8abj8OvGrhFvErc98NYBgLiNMZyUXScMTjfo5Lt
	Dy0/+JbXyRpsaXPKoNjAB83/5kQLKK8NY3PktrMDFWcA/ggKh0uYgQHO/DE/MCPJ
	SfKDkM6ghdqLJg+VJe7/25gGiRm980u/AzHmloNoklPvGRL7Y9M+Dyzq+Wem7d6M
	g8EvZUI8SbGR63o6S6cYrG9/ZKXU61cyIvKEkvieCTZyu7qoqhFJ0IyX9q2HnqNl
	EQtMpbdOgyAmVPLkSwLOGc4I92Xqf0prdZtDkW5vtbq5NMIoaerWGmvx6i3UnG66
	7ukD6CHdfID4ogvH+j7WIVAALEkmqr1uGDg==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgddvtddugecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghkucfo
    rghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhish
    hisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefgudelteef
    vefhfeehieetleeihfejhfeludevteetkeevtedtvdegueetfeejudenucevlhhushhtvg
    hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhn
    vhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopeegpdhmoh
    guvgepshhmthhpohhuthdprhgtphhtthhopehfrhgvughirghnohdriihighhlihhosegt
    lhhouhgurdgtohhmpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnh
    hprhhojhgvtghtrdhorhhgpdhrtghpthhtohepughpshhmihhthhesrghpvghrthhushhs
    ohhluhhtihhonhhsrdgtohhmpdhrtghpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtg
    homh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Tue, 24 Jun 2025 16:35:29 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Frediano Ziglio 
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" ,
	Jan Beulich 
Subject: Re: [PATCH 1/2] xen/efi: Handle cases where file didn't come from ESP
Message-ID: 
References: <20250624083157.9334-1-frediano.ziglio@cloud.com>
 <20250624083157.9334-2-frediano.ziglio@cloud.com>
 
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="NsN83TDdGENhcKex"
Content-Disposition: inline
In-Reply-To: 


--NsN83TDdGENhcKex
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 24 Jun 2025 16:35:29 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Frediano Ziglio 
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" ,
	Jan Beulich 
Subject: Re: [PATCH 1/2] xen/efi: Handle cases where file didn't come from ESP

On Tue, Jun 24, 2025 at 03:05:25PM +0100, Frediano Ziglio wrote:
> OT: the flow of read_file (specifically "what" handling) looks
> weird... can I change it?

It tries to avoid duplication of PrintErr calls, while including what
failed in the error message. Looks like somebody really wanted to avoid
using goto here... Sure, if you want to clean it up go ahead.

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

--NsN83TDdGENhcKex
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmhat7EACgkQ24/THMrX
1yyKagf/T4PHyxHMgK22dMs0mphUEBQAF4V0+GhogN9r+coPIbAcK3q76HzWvfNK
B2ipZkOjLI3Tb4QM8xHr4oLybpQkxGK2X8N+jy8wXR6sf3PdccNgeW62rzUcQr2S
NMX2McS3Lfyrp2sZMBs+OsT85m6ZEjcFrrbA/7BVRKlVvtcmCxw24ih7iDhN25AQ
ODFuiB9+jK9tZpjv2jLxRZyorTWwXruLjt3sLOMgwqcwgSPpgmcrBfDioC4eLs2h
uyyOIOP+pRbsiqjJhlJLEhiG7WJVhEGUvEQ0iIM8OsVbEeXS6MVk3+VY4sA9u6zO
+PMpkT9DM3A8qrNpL0DR86hLFklqHA==
=8XvQ
-----END PGP SIGNATURE-----

--NsN83TDdGENhcKex--


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 14:39:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 14:39:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023801.1399868 (Exim 4.92)
	(envelope-from )
	id 1uU4nq-0001TR-JP; Tue, 24 Jun 2025 14:39:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023801.1399868; Tue, 24 Jun 2025 14:39: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 1uU4nq-0001TK-GX; Tue, 24 Jun 2025 14:39:14 +0000
Received: by outflank-mailman (input) for mailman id 1023801;
 Tue, 24 Jun 2025 14: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 1uU4no-0001TC-Lt
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 14:39:12 +0000
Received: from fhigh-b6-smtp.messagingengine.com
 (fhigh-b6-smtp.messagingengine.com [202.12.124.157])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fde1818f-5108-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 16:39:11 +0200 (CEST)
Received: from phl-compute-09.internal (phl-compute-09.phl.internal
 [10.202.2.49])
 by mailfhigh.stl.internal (Postfix) with ESMTP id 993527A01A0;
 Tue, 24 Jun 2025 10:39:10 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-09.internal (MEProxy); Tue, 24 Jun 2025 10:39:10 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 24 Jun 2025 10:39:08 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fde1818f-5108-11f0-a30f-13f23c93f187
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=1750775950;
	 x=1750862350; bh=W52Wu+jkJr796AN2LGGOEbnR5/30FkLvN8/chEch3p4=; b=
	JHjcofCwz6MEA1UNCeICT6PP9RAzzBixa5G5PtdQUhOlmiUcjYynZ/a5wxcg+fxc
	xBI4DHZ+xYWb1eOiYFCK1fuHDY03vpDApNvWqeU+OksSdOn9mql0OOYwMG49HZHr
	r78rqYM+Yaki+VLSl5VwHzUsZDXP8a6G717Zy7hAgNOuS/1okuBWtf9QyP2N6Tae
	niHPbphXKVqi7mWJcJxIhX6NZLU6WjTWoayLWQ3lR4EEzzU0eBowVcUaD2USM9TR
	OKmHuhcERGTc093nbr7lEPhA3WdUoE5kYGIGGRJbqYnC4sb1WNd8nJS2GuigUatE
	09D/Qes0ZUMzRQWDDSRedQ==
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=
	1750775950; x=1750862350; bh=W52Wu+jkJr796AN2LGGOEbnR5/30FkLvN8/
	chEch3p4=; b=Fk+ysJ8WOORw7Buaa3RTsqVstKUQaNjGyaTeMIhaRLeHDWhA9Yg
	Xmts17pwiMQxk2CRxctKOYx/ONq7iER5hytoScKiO07gyZuCVGUYX1TKOD7se4uU
	bV634deORriP42stHPW4YPID+YMTdGLhCkzzJKXvUXfANJuWeJc0YIonMDtVmNhV
	gyk4iHCWpug6CTgoRqoTz0awP++FqvJed55iX4TDt6/u+4+MbY52Aa7f/e+bBRqd
	9OA8Wmn7aOQdx7byyfH7F1rlVAq6CFQ+zvw/IEctDIWnV7vd76sQg4U0zpjqY75D
	UWlJ9BJf9gtDnhTHVD006n6RFiR7h+PuQyQ==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgddvtdduhecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghkucfo
    rghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhish
    hisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefgudelteef
    vefhfeehieetleeihfejhfeludevteetkeevtedtvdegueetfeejudenucevlhhushhtvg
    hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhn
    vhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopeegpdhmoh
    guvgepshhmthhpohhuthdprhgtphhtthhopehfrhgvughirghnohdriihighhlihhosegt
    lhhouhgurdgtohhmpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnh
    hprhhojhgvtghtrdhorhhgpdhrtghpthhtohepughpshhmihhthhesrghpvghrthhushhs
    ohhluhhtihhonhhsrdgtohhmpdhrtghpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtg
    homh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Tue, 24 Jun 2025 16:39:07 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Frediano Ziglio 
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" ,
	Jan Beulich 
Subject: Re: [PATCH v2 1/2] xen/efi: Handle cases where file didn't come from
 ESP
Message-ID: 
References: <20250624142711.54925-1-frediano.ziglio@cloud.com>
 <20250624142711.54925-2-frediano.ziglio@cloud.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="4qOJssDTK0c5RCyZ"
Content-Disposition: inline
In-Reply-To: <20250624142711.54925-2-frediano.ziglio@cloud.com>


--4qOJssDTK0c5RCyZ
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 24 Jun 2025 16:39:07 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Frediano Ziglio 
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" ,
	Jan Beulich 
Subject: Re: [PATCH v2 1/2] xen/efi: Handle cases where file didn't come from
 ESP

On Tue, Jun 24, 2025 at 03:27:08PM +0100, Frediano Ziglio wrote:
> A boot loader can load files from outside ESP.
> In these cases device could be not provided or path could
> be something not supported.
> In these cases allows to boot anyway, all information
> could be provided using UKI or using other boot loader
> features.
>=20
> Signed-off-by: Frediano Ziglio 

Acked-by: Marek Marczykowski-G=C3=B3recki 

> ---
> Changes since v1:
> - set "leaf" to NULL instead of a buffer with an empty string;
> - keep read_file fatal if cannot load file (except configuration).
> ---
>  xen/common/efi/boot.c | 34 +++++++++++++++++++++++++++++-----
>  1 file changed, 29 insertions(+), 5 deletions(-)
>=20
> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> index 1a9b4e7dae..b18af2f1f4 100644
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -443,6 +443,18 @@ static EFI_FILE_HANDLE __init get_parent_handle(cons=
t EFI_LOADED_IMAGE *loaded_i
>      CHAR16 *pathend, *ptr;
>      EFI_STATUS ret;
> =20
> +    /*
> +     * In some cases the image could not come from a specific device.
> +     * For instance this can happen if Xen was loaded using GRUB2 "linux"
> +     * command.
> +     */
> +    *leaf =3D NULL;
> +    if ( !loaded_image->DeviceHandle )
> +    {
> +        PrintStr(L"Xen image loaded without providing a device\r\n");
> +        return NULL;
> +    }
> +
>      do {
>          EFI_FILE_IO_INTERFACE *fio;
> =20
> @@ -466,7 +478,15 @@ static EFI_FILE_HANDLE __init get_parent_handle(cons=
t EFI_LOADED_IMAGE *loaded_i
> =20
>          if ( DevicePathType(dp) !=3D MEDIA_DEVICE_PATH ||
>               DevicePathSubType(dp) !=3D MEDIA_FILEPATH_DP )
> -            blexit(L"Unsupported device path component");
> +        {
> +            /*
> +             * The image could come from an unsupported device.
> +             * For instance this can happen if Xen was loaded using GRUB2
> +             * "chainloader" command and the file was not from ESP.
> +             */
> +            PrintStr(L"Unsupported device path component\r\n");
> +            return NULL;
> +        }
> =20
>          if ( *buffer )
>          {
> @@ -772,8 +792,11 @@ static bool __init read_file(EFI_FILE_HANDLE dir_han=
dle, CHAR16 *name,
> =20
>      if ( !name )
>          PrintErrMesg(L"No filename", EFI_OUT_OF_RESOURCES);
> -    ret =3D dir_handle->Open(dir_handle, &FileHandle, name,
> -                           EFI_FILE_MODE_READ, 0);
> +    if ( dir_handle )
> +        ret =3D dir_handle->Open(dir_handle, &FileHandle, name,
> +                               EFI_FILE_MODE_READ, 0);
> +    else
> +        ret =3D EFI_NOT_FOUND;
>      if ( file =3D=3D &cfg && ret =3D=3D EFI_NOT_FOUND )
>          return false;
>      if ( EFI_ERROR(ret) )
> @@ -1404,7 +1427,7 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE Im=
ageHandle,
>          /* Read and parse the config file. */
>          if ( read_section(loaded_image, L"config", &cfg, NULL) )
>              PrintStr(L"Using builtin config file\r\n");
> -        else if ( !cfg_file_name )
> +        else if ( !cfg_file_name && file_name)
>          {
>              CHAR16 *tail;
> =20
> @@ -1515,7 +1538,8 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE Im=
ageHandle,
>          efi_bs->FreePages(cfg.addr, PFN_UP(cfg.size));
>          cfg.addr =3D 0;
> =20
> -        dir_handle->Close(dir_handle);
> +        if ( dir_handle )
> +            dir_handle->Close(dir_handle);
> =20
>          if ( gop && !base_video )
>          {
> --=20
> 2.43.0
>=20

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

--4qOJssDTK0c5RCyZ
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmhauIsACgkQ24/THMrX
1yx6OQf+PH7GKtDpAMx6h3t2OCITY5qSCjnr74XiWl9Vj2WHQGfHD04Qo7XvaODL
KxL3C3sWNS35BEbR8XJ/Mlaa77KKSjz+sMxnJtoC12F84XCkPlr016SHf6MX2bGn
xPBv1V/hnzCo82a8guJfbMQQDwhQ2Ml2HjdcXqQg0uHF2xY8L/oTltjzk6GYxIq6
qXIiHSyp5gabzt9PflegPW8CoL1M0hWOAhnWoXesI+pRfsCBsAqtmj3VVjy0hEpz
p1n8pyJuZULobpxZ1O7DLNZhlvnCYeySBhGUUpFjWZvkZEDMD0b4a23MHUzbK+vJ
nVLSj0bThnn2xiyuWdoEGX+bm+TLsQ==
=NmM9
-----END PGP SIGNATURE-----

--4qOJssDTK0c5RCyZ--


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 14:51:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 14:51:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023814.1399877 (Exim 4.92)
	(envelope-from )
	id 1uU4zT-0004VM-N0; Tue, 24 Jun 2025 14:51:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023814.1399877; Tue, 24 Jun 2025 14:51: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 1uU4zT-0004VF-KL; Tue, 24 Jun 2025 14:51:15 +0000
Received: by outflank-mailman (input) for mailman id 1023814;
 Tue, 24 Jun 2025 14:51: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 1uU4zT-0004V9-2i
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 14:51:15 +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 acb9005e-510a-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 16:51:14 +0200 (CEST)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-451d3f72391so49838685e9.3
 for ; Tue, 24 Jun 2025 07:51:14 -0700 (PDT)
Received: from [192.168.0.18]
 (cpc92320-cmbg19-2-0-cust1786.5-4.cable.virginm.net. [82.13.70.251])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-453646dc66fsm142056145e9.18.2025.06.24.07.51.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 07:51:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: acb9005e-510a-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750776673; x=1751381473; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:subject:from:to:content-language
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=QgrYtW/tv35w17TFnrQWr/y8Cm7FKQy0c9kZ6+U/U+s=;
        b=J+2oYapEdIPT6zTX9lxNlKWX5Ej5ypSC1S3ZK6dg2j0GG+PB0xVqUdM4oLnRd0CVdr
         AeP2H/kasfPch8e3frO/O1pE4zCHJmeAD7Yq5zEE73k0H2o3IlGXKfJn74MYoAqz4yPA
         19oGQO5p7ezqaazsfuI/t74Ty7RIV1s6pTG9jcrO+FwgdN/tPzaRYrJphwFHLFvelJhe
         C3nv24Z5RXd23hVSTRjBJuerVYJOObwTkvSCEqYSQBvFFAHZCD7TAOM6MGvQxp3PjpD1
         C86Q/vQPYS2UeuNSpWIxP58yXD7Qd/kKwC0i9IoDrmr3bfHdvyFKiMmsmnVwvP2TKGSa
         jGqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750776673; x=1751381473;
        h=content-transfer-encoding:cc:subject:from:to:content-language
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=QgrYtW/tv35w17TFnrQWr/y8Cm7FKQy0c9kZ6+U/U+s=;
        b=eyzbwnToOJ+OqH2ZWJprnD5fa4lEV5J3jteQE/A/GxvCnCicZuei1Xy3pMppR85/fU
         gQn/ZlRUI0P7dI29qRYr4uwRomN8Z4b8CwiwBN+AW4A/Vdz0wH6tVjEsjOiuWFC1Tkkn
         t4dE7RFXSCZmM2gH6LcLTmjKz+7RDbZe2+CVbZsHa6XsjbGI/BD3rSK91nITV+v3xADM
         kjqR2gtY08YICugViZlomj7lOq1dDWGS+a5OvEOOzHr38Sp/hP5w4PJeePvwGJnlwCYR
         L9tHyxmFH0jI83vNMYtsZItXn0GrIUVaySk6xH7cc0pU3jZZ1BY7MJ1bp4ETJtn6JHf3
         TWqA==
X-Gm-Message-State: AOJu0YxLg86btdxzpa3CIXHeVF9iXpLVqxOQccVYoDIV8OmBfOpFCv1U
	dihbfHHInszStgSCUD/IXyv83qzKFBUiXgM9ZGVlHWjyCeHhGOh0Ml89SOud+0O7
X-Gm-Gg: ASbGncvWKTMQNrhED8q9/K9o7OWviSjp+0SFhJ4emwkuh7VEWaB6YWGsVypk6U0kba+
	ce8Za5q+58Vc/cpFQh47e5fGnIHnurz6xqXqTZ7sJGXA85LfzhQWxHWuMe81bOAnQDwxZfmWvJE
	gogNEJuArqVVGgD+oqfFJAxbpWXfXdsgG1l+ODA0dvuz39Ywjj0d/StuP+pN3o3ArLMXIUS9De3
	WZTaS+Mx6+wwSs4F2AakR/zf+w3UG7/oRlo/OiWPYnd99Yjnc4fb9kEawJRanNX1yTjbir8isvH
	pvpsj1s3tLPs+ykpLW5HRs8i6pgeoq8SAtwC8gCFX20f6fXbbIF/lQG8pJ7hRoFfpXfbjf5UgyT
	QAzzy64h9MDOXHDWP739b/L7yb/eJHoDC9pE3Zv7VYIyT1Xuh/mESFk1Ai5S27rU=
X-Google-Smtp-Source: AGHT+IFSCvw/fw3R7K3iRr+8t+Pvr1NIG4EpvtU0OP6x9SiFpy8ySl2l5/c7PhEW85sTOg+pPZI0MQ==
X-Received: by 2002:a05:600c:3b8d:b0:44a:b7a3:b95f with SMTP id 5b1f17b1804b1-453659f82abmr143099565e9.25.1750776672834;
        Tue, 24 Jun 2025 07:51:12 -0700 (PDT)
Message-ID: <47b7f870-e1d9-44c9-b8ea-5b9028843963@gmail.com>
Date: Tue, 24 Jun 2025 15:51:11 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: xen-devel@lists.xenproject.org
From: Andriy Sultanov 
Subject: xenstore - Suggestion of batching watch events
Cc: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= ,
 =?UTF-8?B?RWR3aW4gVMO2csO2aw==?= ,
 ngoc-tu.dinh@vates.tech, Christian Lindig 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Currently, as far as I am aware, the ability of xenstore clients to properly
handle and detect batch updates is somewhat lacking. Transactions are not
directly visible to the clients watching a particular directory - they will
receive a lot of individual watch_event's once the transaction is committed,
without any indication when such updates are going to end.

Clients such as xenopsd from the xapi toolstack are reliant on xenstore to
track their managed domains, and a flood of individual updates most often
results in a flood of events raised from xenopsd to xapi (There are
consolidation mechanisms implemented there, with updates getting merged
together, but if xapi picks up update events from the queue quickly 
enough, it
will only get more update events later)

The need for batching is fairly evident from the fact that XenServer's 
Windows
PV drivers, for example, adopted an ad-hoc "batch" optimization (not 
documented
anywhere, of course), where some sequence of writes is followed by a 
write of
the value "1" to "data/updated". This used to be honoured by xapi, which 
would
not consider the guest agent update done until it received notice of such a
"batch ended" update, but it caused xapi to miss updates that were not 
followed
by such a write, so xapi now ignores this ad-hoc batching. One could 
imagine
many workarounds here (for example, some sort of a mechanism where xenopsd
stalls an update for a second to see if any more related updates show up and
only then notifies xapi of it, with obvious trade-offs), but IMO it could be
worth considering making this easier on the xenstore side for different
use-cases.

Suggestion:
WATCH_EVENT's req_id and tx_id are currently 0. Could it be possible, for
example, to modify this such that watch events coming as a result of a
transaction commit (a "batch") have tx_id of the corresponding transaction
and req_id of, say, 2 if it's the last such watch event of a batch and 1
otherwise? Old clients would still ignore these values, but it would allow
some others to detect if an update is part of a logical batch that 
doesn't end
until its last event.

Is this beyond the scope of what xenstored wants to do? From a first glance,
this does not seem to introduce obvious unwanted information leaks 
either, but
I could be wrong. I would love to hear if this is something that could be
interesting to others and if this could be considered at all.

Thank you!




From xen-devel-bounces@lists.xenproject.org Tue Jun 24 15:02:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 15:02:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023821.1399887 (Exim 4.92)
	(envelope-from )
	id 1uU59s-0006KG-MM; Tue, 24 Jun 2025 15:02:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023821.1399887; Tue, 24 Jun 2025 15:02: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 1uU59s-0006K9-JU; Tue, 24 Jun 2025 15:02:00 +0000
Received: by outflank-mailman (input) for mailman id 1023821;
 Tue, 24 Jun 2025 15:02: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 1uU59r-0006K3-Un
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 15:01:59 +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 2d15389d-510c-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 17:01:58 +0200 (CEST)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-45363645a8eso5027195e9.1
 for ; Tue, 24 Jun 2025 08:01:58 -0700 (PDT)
Received: from [192.168.0.18]
 (cpc92320-cmbg19-2-0-cust1786.5-4.cable.virginm.net. [82.13.70.251])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-453646cb641sm150663495e9.3.2025.06.24.08.01.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 08:01:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2d15389d-510c-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750777318; x=1751382118; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:content-language:references
         :cc:to:from:subject:user-agent:mime-version:date:message-id:from:to
         :cc:subject:date:message-id:reply-to;
        bh=DRLfF/kocBaDAEM7U/BwU1Gq5xTvw2xL8sslj/yveaY=;
        b=fpd8IDYWZ/L7RyPnGgvnTXECeKP2rWGvJADCCE8PzKTJt/RYOFYSa9TQ/8hk5VJxJm
         HHr4S7VM5rqgCooH8K7JPKc1xtYvsekXS5nQbnC5lqJNW782ujt+5rTzmaYbREF25tAx
         a5HQaO+Kv1vHymBQSmDOsaVVFQDlPzO92S5H8epmC6NcUOMUr/n739SM1yCBWy5Mgr1p
         6EJHsatS67rRWp+EzHwPyfhNgVluWkPHa15VTfS6Uaj50Yw6dIIAoDlpzs7ZU6uDX+p0
         ReiKYmkVwQEdE6hl7K9PtSGwvh7AAw8GgD+CeTNeUTj42GoUV8DayZucsyk2wGOwEnYS
         htJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750777318; x=1751382118;
        h=content-transfer-encoding:in-reply-to: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=DRLfF/kocBaDAEM7U/BwU1Gq5xTvw2xL8sslj/yveaY=;
        b=Nk3fX/ApokZeKLAoGJA5ZU6fjsxixWCrLPxslfrS6bBubvKGVB/cq8jmiYYChuxfNV
         Uim9MsXTBy30fKn/tBcw6YYKwu85hIjdjADivpylobN4WDTqRrc4MNt0PXPu/wBZToRw
         a7vC0Kfdd85Nu4+Qry8ntWdDwxXI1xXlotPx4ZmPoHVaCyT2AfhwwL15OnQmfMxkasXW
         uAn1Ay3gIeV+MsVxw38NjX0l91loCs0AcusybaCJpRyP2EmbuU/EeSussDs1XCAVIx+u
         QPQE4kMS7Iev02gXzCiGFadGdmhpcpSHIjf5T6WMgtLXi14ZgHd+iOBsDpQQC/Sd6cFH
         0xbw==
X-Gm-Message-State: AOJu0YyW3MS89LeUH1Zn4w2O+BEmwGmUE+BB+64IxSV41xctV/gOxO6A
	T1rToSqE3F76qMcal/aPG96NZmciTTr/C+RnohNRzV+YPkbpvL5Ditn4Ew8M6Ht0
X-Gm-Gg: ASbGnctHKUjcxQestPyIHOeoBExcu4WqEoxKytzHjxMkvMW00HvtebYbyCCSM+8wXy8
	oFo1eGEeIqfzwZizGMf167i41av/wLzVemTsjHjJMO1PU04yKk2OnVYRrMksqDyDg4E77slU+Bx
	kTtuKrErQCOIbjDu/6x/uqpqvi9CdSMV08Brtn6QBcz+GHPQ6bZNCpbkEHmrdb2cPt8grO9vi2Z
	f/LIZn9vVcYe4NUxd/tjj4GyQj/+GP8IIvbsOUn2sNSiDDNkWnqANo2TwADcASCnLo0b1qydGzC
	6kRqKmDjIGJFjm73jgdrGHzKSd/tB9JVOmM4iDRz5zkGZvdMRTo7bDzHpPvTl13dFG4q+LzE2Ds
	czodK/TmYX92KR0iG3cPlsMt17aXWXbm1kvS9haYzg1/xxS9bhmhE
X-Google-Smtp-Source: AGHT+IFwjYI/GcfbhxAZzCJ5I1wiPfO5E5T60zHAQSyftHEAITc7wNbF01dSrpZBYnUx2giURmhsGQ==
X-Received: by 2002:a05:600c:1392:b0:44a:b793:9e4f with SMTP id 5b1f17b1804b1-453659aef47mr127097385e9.19.1750777315761;
        Tue, 24 Jun 2025 08:01:55 -0700 (PDT)
Message-ID: 
Date: Tue, 24 Jun 2025 16:01:54 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: xenstore - Suggestion of batching watch events
From: Andriy Sultanov 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= ,
 =?UTF-8?B?RWR3aW4gVMO2csO2aw==?= ,
 ngoc-tu.dinh@vates.tech, Christian Lindig 
References: <47b7f870-e1d9-44c9-b8ea-5b9028843963@gmail.com>
Content-Language: en-US
In-Reply-To: <47b7f870-e1d9-44c9-b8ea-5b9028843963@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 6/24/25 3:51 PM, Andriy Sultanov wrote:

> Suggestion:
> WATCH_EVENT's req_id and tx_id are currently 0. Could it be possible, for
> example, to modify this such that watch events coming as a result of a
> transaction commit (a "batch") have tx_id of the corresponding 
> transaction
> and req_id of, say, 2 if it's the last such watch event of a batch and 1
> otherwise? Old clients would still ignore these values, but it would 
> allow
> some others to detect if an update is part of a logical batch that 
> doesn't end
> until its last event. 

Come to think of it, since clients could watch arbitrary parts of
what the transaction touched, this wouldn't be as simple, xenstored
would have to issue the "batch ended" packet per token, tracking
that somehow internally... Perhaps transaction_start and transaction_end
could produce WATCH_EVENT (or some other similar packet) as well so
that this tracking could be done client-side? (standard WATCH_EVENT
would still need their tx_id to be modified)



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 15:06:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 15:06:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023827.1399897 (Exim 4.92)
	(envelope-from )
	id 1uU5E2-00071N-4p; Tue, 24 Jun 2025 15:06:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023827.1399897; Tue, 24 Jun 2025 15:06: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 1uU5E2-00071G-27; Tue, 24 Jun 2025 15:06:18 +0000
Received: by outflank-mailman (input) for mailman id 1023827;
 Tue, 24 Jun 2025 15:06: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 1uU5E0-00070u-Ge
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 15:06:16 +0000
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [2a00:1450:4864:20::531])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c5bc10c3-510c-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 17:06:14 +0200 (CEST)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-6099d89a19cso11437181a12.2
 for ; Tue, 24 Jun 2025 08:06:14 -0700 (PDT)
Received: from ?IPV6:2003:e5:8746:1a00:ff67:e633:2aa8:93ba?
 (p200300e587461a00ff67e6332aa893ba.dip0.t-ipconnect.de.
 [2003:e5:8746:1a00:ff67:e633:2aa8:93ba])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ae054082d25sm878697066b.88.2025.06.24.08.06.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 08:06:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c5bc10c3-510c-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750777574; x=1751382374; 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=OaEKKSglKBjpw0HRltdpBtSbGccxJxjiBgHBw7o2xk4=;
        b=bFTJii4kvfeJH+c5D2VI84O2rRjBnqOiTt3qHEXDBeOsFupZQp4HsMuVeBhPaER7zw
         vm/aoVcfDwa6ya3NlJ5j/4igITyUTo4Ad62uvpII6t8VBsiSPKSm7vwiVAwpxTqBJvzy
         Vme3YlhPWk4NAQ5Xky51LASW/6/YEozQVBxxFtACtz6Sc8jWLwBGdIhVYpgHKiemE8Wt
         wsc6VSiDtc1Lxh/IRU1C0mp8Q7WgK3V9r9GoLFqRoalwPRSxl+eBBybCsbFiInh3bwIX
         8CGfdF2TQZQOMgxdUxcyTSkd0DPIqMUTUe4h04fRQmG4qsijhFcgMmaYhpWD7msut6sH
         FmXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750777574; x=1751382374;
        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=OaEKKSglKBjpw0HRltdpBtSbGccxJxjiBgHBw7o2xk4=;
        b=BcoXVy4A/dfxb2PFWiZVJFRQeTUIq6tk39g1rlrBTFN7eA3W2LPwGuvQtjHzT0DfmM
         rd+17V1EEmU/HEQaSXD7Yb00O94/Uw4Fu6k+vLjSibaWRls6v2AapRw+3ucPmr6Clmoh
         IGaqa1Ht5/Vq1g5pGMQ3/KdTNPwCbVkI3TF1dAS+vVYXnzlFze07pfyFUM7rQLhaeaLY
         OWW8OMZoK7HQZRc7ezTVLpwWQ9nW7WTKNHH8ykNh7JGHkIhrImQMy/jUgjPYrWXzWrwp
         T1lN44UCJmQadp9L27n/nSiHPmbX3GPgtGA4jW+aH0Uc1JE9JvzU13X9Eu4a7vPGX6LD
         CGxg==
X-Forwarded-Encrypted: i=1; AJvYcCWRYYEnw9VIt5XTCaO5E68pKFnIC1V53AvUXQa4aeFENwbhZ6P4dFtrN32XapAXa2bgxcTr2Pel4uk=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz3ag1V6OUTzyEYEyojCSq1KsACtAovsQDECXmknvCMxS2QPKDl
	SwqcWx3ikWnZx3A3FxxuUeEYUDqFWeSHq4yiM9ObOcgIIjl6qr9fTpSUzRB3x/USBr3zn8uNsoN
	QTwWC188=
X-Gm-Gg: ASbGnctVom+hAXPUaoBwTW8ErkXpJKGe662hGBWzu16MEiu/RSC7W2z/Xfo3fyyoKWf
	xmL2heNCEK8k8zIByFs7orCNJXrdUdfYIfANq15BJskMVeglC++abG5G9UOfx73dgNiMfHUYDkg
	LJKtsFIz7dePx4QFTOH/fWywwN+RXpYivowW0IEflZwj2r7xkQIwMsYDWh3QR4al+zv2+CYQUtA
	3xYSf7pQaunuMy8P36aOyyPSlKPWE3AwUy6K3ONxMQuayvBwMCTzowJrnACBF9p7+bblUD3qQz7
	BRXskMvndeys9nIJkVZeRIoljW4n5efsm1ddypIJ9Ss72FIJ4cV7eX1lcy2P/37P2InorQCoP9Y
	9ANsj7PzseXmODOvBQMFZ/Zyfw0ldeKosdHckMLo+HpO83YceZT0QgLTUG/i5FkNRb6SCrUz1Gr
	+t3dt6Sd5F4fM=
X-Google-Smtp-Source: AGHT+IEhq1M/S93Bf1xBQzA/yzeUHuH1yQCmEpvTjgxrdgTfMJndkUwnQfvG+pdpuptB2w0fhKYW4A==
X-Received: by 2002:a17:907:3d46:b0:ae0:a912:f366 with SMTP id a640c23a62f3a-ae0a912f9e1mr386456766b.54.1750777573722;
        Tue, 24 Jun 2025 08:06:13 -0700 (PDT)
Message-ID: 
Date: Tue, 24 Jun 2025 17:06:11 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: xenstore - Suggestion of batching watch events
To: Andriy Sultanov , xen-devel@lists.xenproject.org
Cc: =?UTF-8?B?RWR3aW4gVMO2csO2aw==?= ,
 ngoc-tu.dinh@vates.tech, Christian Lindig 
References: <47b7f870-e1d9-44c9-b8ea-5b9028843963@gmail.com>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <47b7f870-e1d9-44c9-b8ea-5b9028843963@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------0MSUCUuua06DpeRxob0dVkRw"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------0MSUCUuua06DpeRxob0dVkRw
Content-Type: multipart/mixed; boundary="------------YY1xq8VnnRAZbUFKO0SIusx3";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Andriy Sultanov , xen-devel@lists.xenproject.org
Cc: =?UTF-8?B?RWR3aW4gVMO2csO2aw==?= ,
 ngoc-tu.dinh@vates.tech, Christian Lindig 
Message-ID: 
Subject: Re: xenstore - Suggestion of batching watch events
References: <47b7f870-e1d9-44c9-b8ea-5b9028843963@gmail.com>
In-Reply-To: <47b7f870-e1d9-44c9-b8ea-5b9028843963@gmail.com>

--------------YY1xq8VnnRAZbUFKO0SIusx3
Content-Type: multipart/mixed; boundary="------------B00gjkcfWdiPAdwplBp70dXC"

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

T24gMjQuMDYuMjUgMTY6NTEsIEFuZHJpeSBTdWx0YW5vdiB3cm90ZToNCj4gQ3VycmVudGx5
LCBhcyBmYXIgYXMgSSBhbSBhd2FyZSwgdGhlIGFiaWxpdHkgb2YgeGVuc3RvcmUgY2xpZW50
cyB0byBwcm9wZXJseQ0KPiBoYW5kbGUgYW5kIGRldGVjdCBiYXRjaCB1cGRhdGVzIGlzIHNv
bWV3aGF0IGxhY2tpbmcuIFRyYW5zYWN0aW9ucyBhcmUgbm90DQo+IGRpcmVjdGx5IHZpc2li
bGUgdG8gdGhlIGNsaWVudHMgd2F0Y2hpbmcgYSBwYXJ0aWN1bGFyIGRpcmVjdG9yeSAtIHRo
ZXkgd2lsbA0KPiByZWNlaXZlIGEgbG90IG9mIGluZGl2aWR1YWwgd2F0Y2hfZXZlbnQncyBv
bmNlIHRoZSB0cmFuc2FjdGlvbiBpcyBjb21taXR0ZWQsDQo+IHdpdGhvdXQgYW55IGluZGlj
YXRpb24gd2hlbiBzdWNoIHVwZGF0ZXMgYXJlIGdvaW5nIHRvIGVuZC4NCj4gDQo+IENsaWVu
dHMgc3VjaCBhcyB4ZW5vcHNkIGZyb20gdGhlIHhhcGkgdG9vbHN0YWNrIGFyZSByZWxpYW50
IG9uIHhlbnN0b3JlIHRvDQo+IHRyYWNrIHRoZWlyIG1hbmFnZWQgZG9tYWlucywgYW5kIGEg
Zmxvb2Qgb2YgaW5kaXZpZHVhbCB1cGRhdGVzIG1vc3Qgb2Z0ZW4NCj4gcmVzdWx0cyBpbiBh
IGZsb29kIG9mIGV2ZW50cyByYWlzZWQgZnJvbSB4ZW5vcHNkIHRvIHhhcGkgKFRoZXJlIGFy
ZQ0KPiBjb25zb2xpZGF0aW9uIG1lY2hhbmlzbXMgaW1wbGVtZW50ZWQgdGhlcmUsIHdpdGgg
dXBkYXRlcyBnZXR0aW5nIG1lcmdlZA0KPiB0b2dldGhlciwgYnV0IGlmIHhhcGkgcGlja3Mg
dXAgdXBkYXRlIGV2ZW50cyBmcm9tIHRoZSBxdWV1ZSBxdWlja2x5IGVub3VnaCwgaXQNCj4g
d2lsbCBvbmx5IGdldCBtb3JlIHVwZGF0ZSBldmVudHMgbGF0ZXIpDQo+IA0KPiBUaGUgbmVl
ZCBmb3IgYmF0Y2hpbmcgaXMgZmFpcmx5IGV2aWRlbnQgZnJvbSB0aGUgZmFjdCB0aGF0IFhl
blNlcnZlcidzIFdpbmRvd3MNCj4gUFYgZHJpdmVycywgZm9yIGV4YW1wbGUsIGFkb3B0ZWQg
YW4gYWQtaG9jICJiYXRjaCIgb3B0aW1pemF0aW9uIChub3QgZG9jdW1lbnRlZA0KPiBhbnl3
aGVyZSwgb2YgY291cnNlKSwgd2hlcmUgc29tZSBzZXF1ZW5jZSBvZiB3cml0ZXMgaXMgZm9s
bG93ZWQgYnkgYSB3cml0ZSBvZg0KPiB0aGUgdmFsdWUgIjEiIHRvICJkYXRhL3VwZGF0ZWQi
LiBUaGlzIHVzZWQgdG8gYmUgaG9ub3VyZWQgYnkgeGFwaSwgd2hpY2ggd291bGQNCj4gbm90
IGNvbnNpZGVyIHRoZSBndWVzdCBhZ2VudCB1cGRhdGUgZG9uZSB1bnRpbCBpdCByZWNlaXZl
ZCBub3RpY2Ugb2Ygc3VjaCBhDQo+ICJiYXRjaCBlbmRlZCIgdXBkYXRlLCBidXQgaXQgY2F1
c2VkIHhhcGkgdG8gbWlzcyB1cGRhdGVzIHRoYXQgd2VyZSBub3QgZm9sbG93ZWQNCj4gYnkg
c3VjaCBhIHdyaXRlLCBzbyB4YXBpIG5vdyBpZ25vcmVzIHRoaXMgYWQtaG9jIGJhdGNoaW5n
LiBPbmUgY291bGQgaW1hZ2luZQ0KPiBtYW55IHdvcmthcm91bmRzIGhlcmUgKGZvciBleGFt
cGxlLCBzb21lIHNvcnQgb2YgYSBtZWNoYW5pc20gd2hlcmUgeGVub3BzZA0KPiBzdGFsbHMg
YW4gdXBkYXRlIGZvciBhIHNlY29uZCB0byBzZWUgaWYgYW55IG1vcmUgcmVsYXRlZCB1cGRh
dGVzIHNob3cgdXAgYW5kDQo+IG9ubHkgdGhlbiBub3RpZmllcyB4YXBpIG9mIGl0LCB3aXRo
IG9idmlvdXMgdHJhZGUtb2ZmcyksIGJ1dCBJTU8gaXQgY291bGQgYmUNCj4gd29ydGggY29u
c2lkZXJpbmcgbWFraW5nIHRoaXMgZWFzaWVyIG9uIHRoZSB4ZW5zdG9yZSBzaWRlIGZvciBk
aWZmZXJlbnQNCj4gdXNlLWNhc2VzLg0KPiANCj4gU3VnZ2VzdGlvbjoNCj4gV0FUQ0hfRVZF
TlQncyByZXFfaWQgYW5kIHR4X2lkIGFyZSBjdXJyZW50bHkgMC4gQ291bGQgaXQgYmUgcG9z
c2libGUsIGZvcg0KPiBleGFtcGxlLCB0byBtb2RpZnkgdGhpcyBzdWNoIHRoYXQgd2F0Y2gg
ZXZlbnRzIGNvbWluZyBhcyBhIHJlc3VsdCBvZiBhDQo+IHRyYW5zYWN0aW9uIGNvbW1pdCAo
YSAiYmF0Y2giKSBoYXZlIHR4X2lkIG9mIHRoZSBjb3JyZXNwb25kaW5nIHRyYW5zYWN0aW9u
DQo+IGFuZCByZXFfaWQgb2YsIHNheSwgMiBpZiBpdCdzIHRoZSBsYXN0IHN1Y2ggd2F0Y2gg
ZXZlbnQgb2YgYSBiYXRjaCBhbmQgMQ0KPiBvdGhlcndpc2U/IE9sZCBjbGllbnRzIHdvdWxk
IHN0aWxsIGlnbm9yZSB0aGVzZSB2YWx1ZXMsIGJ1dCBpdCB3b3VsZCBhbGxvdw0KPiBzb21l
IG90aGVycyB0byBkZXRlY3QgaWYgYW4gdXBkYXRlIGlzIHBhcnQgb2YgYSBsb2dpY2FsIGJh
dGNoIHRoYXQgZG9lc24ndCBlbmQNCj4gdW50aWwgaXRzIGxhc3QgZXZlbnQuDQo+IA0KPiBJ
cyB0aGlzIGJleW9uZCB0aGUgc2NvcGUgb2Ygd2hhdCB4ZW5zdG9yZWQgd2FudHMgdG8gZG8/
IEZyb20gYSBmaXJzdCBnbGFuY2UsDQo+IHRoaXMgZG9lcyBub3Qgc2VlbSB0byBpbnRyb2R1
Y2Ugb2J2aW91cyB1bndhbnRlZCBpbmZvcm1hdGlvbiBsZWFrcyBlaXRoZXIsIGJ1dA0KPiBJ
IGNvdWxkIGJlIHdyb25nLiBJIHdvdWxkIGxvdmUgdG8gaGVhciBpZiB0aGlzIGlzIHNvbWV0
aGluZyB0aGF0IGNvdWxkIGJlDQo+IGludGVyZXN0aW5nIHRvIG90aGVycyBhbmQgaWYgdGhp
cyBjb3VsZCBiZSBjb25zaWRlcmVkIGF0IGFsbC4NCg0KVGhlIG1haW4gcmVhc29uIGZvciB0
aGUgbGFyZ2UgbnVtYmVyIG9mIHdhdGNoIGV2ZW50cyBhZnRlciBhIHRyYW5zYWN0aW9uIGlz
DQp0aGUgZmFjdCB0aGF0IHRoZSB3YXRjaCBmb3IgZS5nLiBkZXRlY3RpbmcgdGhlIGFkZGl0
aW9uIG9mIGEgbmV3IGJsb2NrIGRldmljZQ0Kd2lsbCBiZSBzZXQgb24gYSBub2RlIGJlaW5n
IGNvbW1vbiBmb3IgYWxsIHBvdGVudGlhbCBibG9jayBkZXZpY2VzIGhhbmRsZWQNCmJ5IHRo
ZSB3YXRjaGVyLiBUaGlzIHJlc3VsdHMgaW4gYSB3YXRjaCBldmVudCBmb3IgZWFjaCBzaW5n
bGUgbm9kZSBtb2RpZmllZA0KYmVsb3cgdGhpcyBub2RlLCB3aGljaCBhcmUgdXN1YWxseSBx
dWl0ZSBhIGxvdCBldmVuIHdoZW4gb25seSBhZGRpbmcgYSBzaW5nbGUNCmRldmljZS4NCg0K
VGhlIHNvbHV0aW9uIGZvciB0aGlzIHByb2JsZW0gaXMgTk9UIHRvIGJhdGNoIGFsbCB0aGUg
ZXZlbnRzIGFuZCB0byBpZ25vcmUgdGhlDQptYWpvcml0eSBvZiB0aG9zZSBldmVudHMsIGJ1
dCB0byBhdm9pZCBjcmVhdGluZyBtb3N0IG9mIHRob3NlIGV2ZW50cy4NCg0KRm9yIHRoaXMg
cmVhc29uIHRoZSBYZW5zdG9yZSBwcm90b2NvbCBoYXMgYmVlbiBleHRlbmRlZCB0byBhbGxv
dyBmb3IgbGltaXRpbmcNCnRoZSBudW1iZXIgb2Ygbm9kZSBsZXZlbHMgYmVsb3cgYSB3YXRj
aGVkIG5vZGUgdG8gYmUgcmVsZXZhbnQgZm9yIGEgd2F0Y2ggdG8NCmZpcmUuDQoNCldoYXQg
aXMgbWlzc2luZyBzbyBmYXIgYXJlIFhlbnN0b3JlIGltcGxlbWVudGF0aW9ucyB0byBzdXBw
b3J0IHRoaXMgZmVhdHVyZSwNCmFuZCBYZW5zdG9yZSB1c2VycyB0byBtYWtlIHVzZSBvZiBp
dC4gSSdtIHdvcmtpbmcgb24gc3VwcG9ydGluZyB0aGlzIGluDQpDIHhlbnN0b3JlZCwgYnV0
IGR1ZSB0byBvdGhlciB1cmdlbnQgd29yayB0aGlzIHdpbGwgcHJvYmFibHkgbGFuZCB1cHN0
cmVhbSBvbmx5DQppbiB0aGUgWGVuIDQuMjIgdGltZSBmcmFtZSwgcHJvYmFibHkgdG9nZXRo
ZXIgd2l0aCBYZW4gdG9vbHMgKGxpYnhsKSBtYWtpbmcgdXNlDQpvZiB0aGlzIGZlYXR1cmUu
DQoNCg0KSnVlcmdlbg0K
--------------B00gjkcfWdiPAdwplBp70dXC
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-----

--------------B00gjkcfWdiPAdwplBp70dXC--

--------------YY1xq8VnnRAZbUFKO0SIusx3--

--------------0MSUCUuua06DpeRxob0dVkRw
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/Ey8FAmhavuMFAwAAAAAACgkQsN6d1ii/Ey9c
fAf/Z+IunNpwjvetRvpu82528SqMfS7DgZM2TXD0CPaukXfve2PFtnXNoO+L7TIe/TjWEYKMpv19
LtpQKgZx9/dPKIoQN3/ggoXH1eyYoCcpspiDuo704/VrdxwOHd9BC9C6TFyyig7otKSwQoZJnnAr
8mo8u8U0yLp8lBHetkHBxdeXZ3VvqXpBY96eoHUd/Z97dk4V9pCMyTroeoIyTEBtP1uqc6LiKANO
FOa9t22cY0HVU+Y/6kC7L0IK7rnNyLye3MHRDyG/VDsGLgZoSP/UDTVfOkJdrZ7NKeutQAMaYhOH
BGUreLEq0UmgfiTbJZMzOq0SwTh5VCR6XCvZ8rqptg==
=AgpO
-----END PGP SIGNATURE-----

--------------0MSUCUuua06DpeRxob0dVkRw--


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 15:13:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 15:13:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023834.1399908 (Exim 4.92)
	(envelope-from )
	id 1uU5Ke-0000Kl-P1; Tue, 24 Jun 2025 15:13:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023834.1399908; Tue, 24 Jun 2025 15:13: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 1uU5Ke-0000Ke-M2; Tue, 24 Jun 2025 15:13:08 +0000
Received: by outflank-mailman (input) for mailman id 1023834;
 Tue, 24 Jun 2025 15:13: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 1uU5Kc-0000KY-Rk
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 15:13:06 +0000
Received: from mail-oo1-xc2c.google.com (mail-oo1-xc2c.google.com
 [2607:f8b0:4864:20::c2c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ba11ab92-510d-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 17:13:05 +0200 (CEST)
Received: by mail-oo1-xc2c.google.com with SMTP id
 006d021491bc7-610db3f3f90so248769eaf.2
 for ; Tue, 24 Jun 2025 08:13:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ba11ab92-510d-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750777984; x=1751382784; 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=XxSLs0Zy2EVf7+xTJftz9OoG0jRFzUdFRd/V1EooDck=;
        b=Vo8rrF7ndqrMCJa8Ni7ifVn+qMYRQIGjBZaXeyk++SMYh6XQu8BBcFagSIUmGqvKjs
         HE0P05DNjpivvV0Vlje/Pg7uJtjffh9VX91HOFoLa9fXcXxC0JxzHXh3TdhqKBfoAYLD
         vLx1h3Eq1tBeNqNAKYWgGV/c5PyEnMZBBEbqM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750777984; x=1751382784;
        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=XxSLs0Zy2EVf7+xTJftz9OoG0jRFzUdFRd/V1EooDck=;
        b=aLICluzIGq9WOiLVDlMO5ExwKqv81+fyKN2b7QzpFCr0yp3eKHKnYWQruN+JV0gTt2
         Hqv+vNnOC2zS9cQ+wXQYRMzCI/U0C/823lWvkWZ4a6z0K1vxFULP9NkCRBd4+Lvm9bJ2
         QrXOdorpcnu2gwi+XbQI3H5+29d95AJdSHD9LZgqlslsyA2Cfhs42uO+kqXzdORx5M5H
         MxcVHqlxQj5D0LUAOB9NVZoaE4OXEb8iJPsiQkV+Lw98mzv6xODB/o+YyUnL1WxvB+OQ
         vZr0blove8ugCJOfPY15f0IydyTDXaTU7/+wvwaf7zFp4EJVGl8xbCF71QDsyQmd1Jaz
         BdAg==
X-Gm-Message-State: AOJu0Yyrx6dSx04Ks80yFoPJRhYCXvoekDIi8TW78z8BfMFEeHJuUvan
	s0tRF8ISC8vOBZRw4hTeolWkc66OJtfHSWUqhj+rXG5O+WfwV08RsePrhzOd6fFCMPcvVpEyz2S
	U5fgjcQ0qbTIg8tSO7Szio2lmIdFFPWx9uMoQtjlMsg==
X-Gm-Gg: ASbGncvk0bm0DSzrLBVxxjpaiEouu0zp7yv2O8vCXxqkOz9xjBF5LUKX4a9GczDq9SK
	W7zXoAq7IW+j2dbb1ljtg8w+QKim/PY67jlodo3a7YRT/o5nWit2rUQgKDH15bEAxBy+6Xh7ojQ
	zQndsiPlmxMg8b1z7HN+2XZRKX6kZYygvP65ISUM7O
X-Google-Smtp-Source: AGHT+IGhG5YRXNh7ltEOHNr24yRx2e25hNQPik3tsdapkO8F67KZajZlYUraVtz/dLDZHi1oFdW3RrrFugNJ27UYE8k=
X-Received: by 2002:a05:6870:e8a:b0:2e9:d485:5ad4 with SMTP id
 586e51a60fabf-2efaf43e171mr165687fac.33.1750777984057; Tue, 24 Jun 2025
 08:13:04 -0700 (PDT)
MIME-Version: 1.0
References: <20250624083157.9334-1-frediano.ziglio@cloud.com>
 <20250624083157.9334-2-frediano.ziglio@cloud.com> 
  
In-Reply-To: 
From: Frediano Ziglio 
Date: Tue, 24 Jun 2025 16:12:46 +0100
X-Gm-Features: AX0GCFv4y0XEz-NK9ew9bIA39XR6y5Ktd--rTrtlhFUZIKGigicUL4fJY8rY7EM
Message-ID: 
Subject: Re: [PATCH 1/2] xen/efi: Handle cases where file didn't come from ESP
To: =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= 
Cc: xen-devel@lists.xenproject.org, 
	"Daniel P. Smith" , Jan Beulich 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 24, 2025 at 3:35=E2=80=AFPM Marek Marczykowski-G=C3=B3recki
 wrote:
>
> On Tue, Jun 24, 2025 at 03:05:25PM +0100, Frediano Ziglio wrote:
> > OT: the flow of read_file (specifically "what" handling) looks
> > weird... can I change it?
>
> It tries to avoid duplication of PrintErr calls, while including what
> failed in the error message. Looks like somebody really wanted to avoid
> using goto here... Sure, if you want to clean it up go ahead.
>

2 styles came into my mind
gotos: https://gitlab.com/xen-project/people/fziglio/xen/-/blob/flow1/xen/c=
ommon/efi/boot.c?ref_type=3Dheads#L765
no errors: https://gitlab.com/xen-project/people/fziglio/xen/-/blob/flow2/x=
en/common/efi/boot.c?ref_type=3Dheads#L765

What do you think?

Frediano


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 15:22:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 15:22:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023855.1399918 (Exim 4.92)
	(envelope-from )
	id 1uU5TG-00027a-Jx; Tue, 24 Jun 2025 15:22:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023855.1399918; Tue, 24 Jun 2025 15:22: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 1uU5TG-00027T-GP; Tue, 24 Jun 2025 15:22:02 +0000
Received: by outflank-mailman (input) for mailman id 1023855;
 Tue, 24 Jun 2025 15:22: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 1uU5TF-00027N-93
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 15:22:01 +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 f6d73ef3-510e-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 17:21:56 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-450ce671a08so35953475e9.3
 for ; Tue, 24 Jun 2025 08:21:56 -0700 (PDT)
Received: from smtpclient.apple ([46.149.103.13])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-453632312a3sm155541085e9.1.2025.06.24.08.21.54
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 24 Jun 2025 08:21:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f6d73ef3-510e-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750778516; x=1751383316; 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=Oua7XXUpqRR6QzmdHD2dGCTwDty4n6iwCzl/A0SPc1I=;
        b=jwaUsKYO1J3bTAEuw/kzFJ21BT9zKoJ/07EyYcAUOgpGZIRcwHjl+CR02UF8wGfYs4
         9InbFTwVL84Ywvj5pJsQjQFT/1/N0vCUCTWNRbJzduD8S1vsi601W4lgt7zxpK6cIdCH
         xXPamNkzJfl44AjkNFwy8n64kkSFCs51CJl20=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750778516; x=1751383316;
        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=Oua7XXUpqRR6QzmdHD2dGCTwDty4n6iwCzl/A0SPc1I=;
        b=U4KrhCCXYxNsj38xc72h1Aj46rUQl4P89pH6EJ2HDxv9bC4wsJqMlIVwPWHYFp7ppJ
         YorkiupxNRjUaI6BcgwdBT9/7f1uZxmel93jrhdh98myo9oSwIpGaE8mOAeSDVlzC6hZ
         +h/ruWIIFCsnFFPugvAJxJGbeAHNjfKutiY1pF0sCEcCXzhv+GFtUTEfi1VcSH0bELpe
         dScVqOajGfWYSNh3PZWZcHeSvkMxJ0EPqgkPIoktYm+s4DcipAztz87+xYs5Mg73KrpR
         vB9meqhIv8E6uVkB/2Qf8LN9qvVEIVmp3mHxvdrrw5KPWy/tAfDP0oUMimH1FdDTSd1+
         /zZQ==
X-Gm-Message-State: AOJu0Yy9dejNPbawTuyG5EfTj6O0N6CV8Nnt3+iJP0xDnN9Rn3IXmjiu
	CwUCnGDv4C9JDIjXzunvPFZGg/R6HoT02JXDHFA4MzTuLsmy8sPVrUzWkNtrS2jXoJX04NtFI9r
	911eb
X-Gm-Gg: ASbGnctrUgtXbRPRZgmeFqNEHd27Nya54wGlsWtygFxX7xhYH929hh4MW4jELGLNAZh
	bjbYntrMVS5LQvb7i19tRm0NX54ZOG3H5UI6cfZUi3P1pj+o05vjPsuNva/v6eSoMNINiPfKClQ
	wNw2w0FAmKtMor9LduVQzj9VLu0uFxdWzKW2VrxrRIjQByx2OlKVRt+MtGfMmffyk+wqmuAR+NQ
	iNeDU1Fi4qxqiDM1KUKMt2UBnr9b75T2d++fOV15HD3kITdEULzQ1Y9bJ+4Op+QV65rpccm/Foe
	Li0zpH8OuQkyLhVM5UMbMsYwo9RBdpBKWhz/BLjMdDyuZ11yHCQlOK2Bv3ltoHjoaiYFBFlHWt+
	Adn7StOpQPXQ=
X-Google-Smtp-Source: AGHT+IEvrg/oc2S3NIiDKwdhjw8Yf7Fp/WGqAAZ/6KmET8LI14DO1I34/FZaY1Z2zk8gDXjY6gZnyg==
X-Received: by 2002:a05:600d:114:b0:442:f482:c429 with SMTP id 5b1f17b1804b1-45365c15866mr98281035e9.8.1750778515523;
        Tue, 24 Jun 2025 08:21:55 -0700 (PDT)
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\))
Subject: Re: xenstore - Suggestion of batching watch events
From: Christian Lindig 
In-Reply-To: <47b7f870-e1d9-44c9-b8ea-5b9028843963@gmail.com>
Date: Tue, 24 Jun 2025 16:21:44 +0100
Cc: xen-devel@lists.xenproject.org,
 =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= ,
 =?utf-8?B?RWR3aW4gVMO2csO2aw==?= ,
 ngoc-tu.dinh@vates.tech,
 Christian Lindig 
Content-Transfer-Encoding: quoted-printable
Message-Id: <955F5D37-20D3-4B33-867E-78A0B83A4FB2@cloud.com>
References: <47b7f870-e1d9-44c9-b8ea-5b9028843963@gmail.com>
To: Andriy Sultanov 
X-Mailer: Apple Mail (2.3826.500.181.1.5)

I believe what you observe is a major source of inefficiency for the =
reason you describe: changes are acted upon too early because there is =
no way to observe that they are part of a transaction. So now heuristics =
come in like waiting for more changes before acting on the ones =
observed. I wonder how the tree structure plays into this. Clients watch =
different sub trees and we don=E2=80=99t exploit this knowledge. I do =
agree that some protocol or syntax to batch updates would be useful.

=E2=80=94 C


> On 24 Jun 2025, at 15:51, Andriy Sultanov  =
wrote:
>=20
> Currently, as far as I am aware, the ability of xenstore clients to =
properly
> handle and detect batch updates is somewhat lacking. Transactions are =
not
> directly visible to the clients watching a particular directory - they =
will
> receive a lot of individual watch_event's once the transaction is =
committed,
> without any indication when such updates are going to end.
>=20
> Clients such as xenopsd from the xapi toolstack are reliant on =
xenstore to
> track their managed domains, and a flood of individual updates most =
often
> results in a flood of events raised from xenopsd to xapi (There are
> consolidation mechanisms implemented there, with updates getting =
merged
> together, but if xapi picks up update events from the queue quickly =
enough, it
> will only get more update events later)
>=20
> The need for batching is fairly evident from the fact that XenServer's =
Windows
> PV drivers, for example, adopted an ad-hoc "batch" optimization (not =
documented
> anywhere, of course), where some sequence of writes is followed by a =
write of
> the value "1" to "data/updated". This used to be honoured by xapi, =
which would
> not consider the guest agent update done until it received notice of =
such a
> "batch ended" update, but it caused xapi to miss updates that were not =
followed
> by such a write, so xapi now ignores this ad-hoc batching. One could =
imagine
> many workarounds here (for example, some sort of a mechanism where =
xenopsd
> stalls an update for a second to see if any more related updates show =
up and
> only then notifies xapi of it, with obvious trade-offs), but IMO it =
could be
> worth considering making this easier on the xenstore side for =
different
> use-cases.
>=20
> Suggestion:
> WATCH_EVENT's req_id and tx_id are currently 0. Could it be possible, =
for
> example, to modify this such that watch events coming as a result of a
> transaction commit (a "batch") have tx_id of the corresponding =
transaction
> and req_id of, say, 2 if it's the last such watch event of a batch and =
1
> otherwise? Old clients would still ignore these values, but it would =
allow
> some others to detect if an update is part of a logical batch that =
doesn't end
> until its last event.
>=20
> Is this beyond the scope of what xenstored wants to do? =46rom a first =
glance,
> this does not seem to introduce obvious unwanted information leaks =
either, but
> I could be wrong. I would love to hear if this is something that could =
be
> interesting to others and if this could be considered at all.
>=20
> Thank you!
>=20
>=20



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 15:23:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 15:23:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023862.1399928 (Exim 4.92)
	(envelope-from )
	id 1uU5Uu-0002dG-Tg; Tue, 24 Jun 2025 15:23:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023862.1399928; Tue, 24 Jun 2025 15: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 1uU5Uu-0002d9-QZ; Tue, 24 Jun 2025 15:23:44 +0000
Received: by outflank-mailman (input) for mailman id 1023862;
 Tue, 24 Jun 2025 15: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 1uU5Ut-0002d1-MD
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 15:23:43 +0000
Received: from mail-vk1-xa2e.google.com (mail-vk1-xa2e.google.com
 [2607:f8b0:4864:20::a2e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 35ea255e-510f-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 17:23:42 +0200 (CEST)
Received: by mail-vk1-xa2e.google.com with SMTP id
 71dfb90a1353d-531426c7139so1679800e0c.2
 for ; Tue, 24 Jun 2025 08:23:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 35ea255e-510f-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750778621; x=1751383421; 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=X1oXnDljvh/r0rEbTqu2LKLOLW/85W+U5jWcdXp0lOw=;
        b=aCvbBTV38cCDG+gu9ZQeYO+MkmAApZKk+kai5e04ySsZxZtFtQPQnMeKdOHwvZHY+D
         mq7XgIRsehARCLXUkkkD+W/4BYd4sriG76LGsW09WMU7SnszpGj9vIMBucMDeyoBUPbx
         zSUNG5Weaww41M+rqxZL/c3Z3RGBVm4yplGA0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750778621; x=1751383421;
        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=X1oXnDljvh/r0rEbTqu2LKLOLW/85W+U5jWcdXp0lOw=;
        b=Q6iYp4py/E01FuIjKADX1SNQmVX5WxY39UiUReyi3Jh94zxXSCCiojgBNxDXvUtwPa
         KYaJt1dpFNSO/6lWo24G+TYrQrwZneO7k3GK1/aRIodna4DY+10j060mX5QkCLfQgo6j
         ajAyH3imSEVsnTR4KHli2fhEhx+kRATnDQXXqYjyOGF88YnAx5YQd7eBAlscFb8bYlkF
         drCkm1POOYS1ooX1PErISkKl40phelsS6MIKk6kU8FBa+ywlOGzNKsu1fsmGwJdS+pp4
         0pxZdJ7NivRKlRLK1mFKI64TrUPYhkHx242Jz2Y99MvDEfBxfs24x+6l65egRO9aLFvl
         CFow==
X-Gm-Message-State: AOJu0YxhKHhYv0io1OWs5xh/x9HvmfyiCdiMzmiQo90pIBnp+VvM601v
	m95lQdp2l7XTPtsN1UpaMCV3y8NW8t2Xaebmz1+1GMo71SdGG6OY2NHiQPYht68EgifW/xiX7h3
	q6iPzDlS/ywjCBLHQVvq7UlfJkyb3o/7R2gB14tBPhw==
X-Gm-Gg: ASbGncuJ+oQtf3GOc2o13zOvK4XtxVLmV3YxXP6Rpk6UEChbfzGuGUwqiCsWncHK1io
	hipQwiYz4n+qMMr8/OLKp71bFUyy4klMNN636SsLoQIXbhlSaBv8/4HwEUuQUzlAxe5TTjBlkQy
	WT3BSU0qGhEzzSfm2VQYhosgJ7Dw3U9BPEWZCeMXBynVWpjA==
X-Google-Smtp-Source: AGHT+IEHLJwL3LpSRe/Q+iHwf/l1EOsgDs0cunMwWo/BfYDTkyH+FAFmvyTifMh/2nWJz+ZurpwccuyfRGzGnog5qKw=
X-Received: by 2002:a05:6122:3c42:b0:531:2afc:462a with SMTP id
 71dfb90a1353d-531ad6c3e30mr10620157e0c.3.1750778621303; Tue, 24 Jun 2025
 08:23:41 -0700 (PDT)
MIME-Version: 1.0
References: <47b7f870-e1d9-44c9-b8ea-5b9028843963@gmail.com> 
In-Reply-To: 
From: Edwin Torok 
Date: Tue, 24 Jun 2025 16:23:29 +0100
X-Gm-Features: AX0GCFv--tcJdp_L9GQC1DMUioNA6x3uvZju0A-i6BB5KXaritUCPM3RsrJrWLA
Message-ID: 
Subject: Re: xenstore - Suggestion of batching watch events
To: Andriy Sultanov 
Cc: xen-devel@lists.xenproject.org, =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , 
	ngoc-tu.dinh@vates.tech, Christian Lindig 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 24, 2025 at 4:01=E2=80=AFPM Andriy Sultanov
 wrote:
>
> On 6/24/25 3:51 PM, Andriy Sultanov wrote:
>
> > Suggestion:
> > WATCH_EVENT's req_id and tx_id are currently 0. Could it be possible, f=
or
> > example, to modify this such that watch events coming as a result of a
> > transaction commit (a "batch") have tx_id of the corresponding
> > transaction
> > and req_id of, say, 2 if it's the last such watch event of a batch and =
1
> > otherwise? Old clients would still ignore these values, but it would
> > allow
> > some others to detect if an update is part of a logical batch that
> > doesn't end
> > until its last event.
>
> Come to think of it, since clients could watch arbitrary parts of
> what the transaction touched, this wouldn't be as simple, xenstored
> would have to issue the "batch ended" packet per token, tracking
> that somehow internally... Perhaps transaction_start and transaction_end
> could produce WATCH_EVENT (or some other similar packet) as well so
> that this tracking could be done client-side? (standard WATCH_EVENT
> would still need their tx_id to be modified)
>

The Windows PV drivers also write a huge amount of data to xenstore.
E.g. I see 74 entries under /data, grouped by 1st level:
/data/volumes: 39
/dta/scsi: 7
/data/vif: 3
/data/xd: 2
/data/cpus: 2
/data/...: 19

This is probably why the /data/updated optimization used to be beneficial.

/attr/os/hotfixes is also large (28 on this VM, but used to be in the
hundreds for older versions of Windows).

In some situations xenopsd could set up more granular watches, but
then you run into scalability issues due to having thousands of
watches per domain (although you've fixed the largest problem there:
connecting/disconnecting xenstore clients causing slowdowns due to
watch trie walks).

There is also the problem that watch events don't contain enough
information, so watch events only acts as signals to xenopsd, which
then goes on and fetches the entire xenstore subtree to figure out
what actually changed. Which is the result of some of the O(N^2)
performance issues we still have.
We used to have a prototype xenstore cache which avoided actually
making those fetches from oxenstored, and once something got into its
cache, it kept track of updates by setting up a watch on the key.
Although a cold start then took ~30m (worse than not having a cache at
all). Although a compromise could be to cache on-the-fly (instead of
precaching everything you see), e.g. I don't think we actually care
about the values under /data/volumes and attr/os/hotfixes, other than
for debugging purposes, so if xenopsd never fetches them, the cache
shouldn't either.

To avoid a lot of round-trips a new kind of watch event that tells you
the value(s) in addition to the keys might be useful. And then this
new kind of watch event could also be emitted once per transaction (I
think the events are already emitted at transaction commit time, and
not sooner).
If filtering watch events based on tree depths would be useful in some
situations then the new watch event could also try to do that.
But then one such "batched" watch event could become too big, larger
than what would fit into the xenstore ring (and for historic reasons
we don't support sending >4k packets through xenstore).

Best regards,
--Edwin


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 15:28:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 15:28:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023869.1399937 (Exim 4.92)
	(envelope-from )
	id 1uU5ZA-0003CQ-Cj; Tue, 24 Jun 2025 15:28:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023869.1399937; Tue, 24 Jun 2025 15:28: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 1uU5ZA-0003CJ-9r; Tue, 24 Jun 2025 15:28:08 +0000
Received: by outflank-mailman (input) for mailman id 1023869;
 Tue, 24 Jun 2025 15:28: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 1uU5Z9-0003CD-MZ
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 15:28:07 +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 d25e93a8-510f-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 17:28:05 +0200 (CEST)
Received: from phl-compute-06.internal (phl-compute-06.phl.internal
 [10.202.2.46])
 by mailfout.stl.internal (Postfix) with ESMTP id BC7281D0012F;
 Tue, 24 Jun 2025 11:28:03 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-06.internal (MEProxy); Tue, 24 Jun 2025 11:28:03 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 24 Jun 2025 11:28:02 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d25e93a8-510f-11f0-b894-0df219b8e170
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=1750778883;
	 x=1750865283; bh=xEewdMo0YgeCo5Z8JhThItTVNM53kGDBjvJaH2F472w=; b=
	LQJ4Rdn1H4u1PZLCEHTow73UMXBPBNSjWrv2oTQgrvqbpahNlYcnnlsYr6uBnrlB
	yXeN5z13QnxorOWLH91laP47RlTC2OVIyj4DCJbtcw2mbEtPfwIGAnC3174QBoMj
	u0ASGnsmrziEq0wjn2siGH2CmqK8vAdby5o45BFIo2ajx3tPDDwIc20FYquFvupS
	1YKZvA7CymnBQWkvf4vKGhzH28Qa6ikVxHYo9dmWE2COqjL2lrgf/5kS7XAF2N/h
	+gQwiW24FL+CIcwgF5aQHQmE7gd9fif6Dohnh3ZR2NQslvWbGw+FdoetPnOnxpF/
	8xzdrCkYHFyZGxXEEPbwyA==
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=
	1750778883; x=1750865283; bh=xEewdMo0YgeCo5Z8JhThItTVNM53kGDBjvJ
	aH2F472w=; b=ofQhcDMPJgf5bkNSlkj4Jr3qJCI7OE7lsxa8l7OjIqiSFqfk+TU
	dHnYlpWpfxO6HBe7x9U+0oDSmDMuBx/+xrCu5RKbkA+4g9twfxJMsP2qWL8O38vQ
	Wlj12TLBAnSqGhgq88gIJJkBde/7e/vaPMNbjLbp3vX5y2yRkTbghifN0cUiMQB7
	l4MK7PKdjgqKDQiVL2zT4xBv3VSvU2OvF4IJeBwmtTFQgwQxWSyk15Cjb/72KmxN
	JfsaWw4pljMPSnfOkE5ft3iepAETuWmcETvzxgL85SAXs2C3KBhtvCtpM6HJewqb
	My4Sz3gyVLmEKJBzpHwWGaIIiw+Bo1b2UIA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgddvtddvhecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghkucfo
    rghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhish
    hisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpeevueejteeg
    leelteduueevhfetgfffjeevtddvgfeiveehteehleegueelvdejveenucffohhmrghinh
    epghhithhlrggsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehm
    rghilhhfrhhomhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsg
    drtghomhdpnhgspghrtghpthhtohepgedpmhhouggvpehsmhhtphhouhhtpdhrtghpthht
    ohepfhhrvgguihgrnhhordiiihhglhhiohestghlohhuugdrtghomhdprhgtphhtthhope
    igvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdprhgtphht
    thhopeguphhsmhhithhhsegrphgvrhhtuhhsshholhhuthhiohhnshdrtghomhdprhgtph
    htthhopehjsggvuhhlihgthhesshhushgvrdgtohhm
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Tue, 24 Jun 2025 17:28:00 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Frediano Ziglio 
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" ,
	Jan Beulich 
Subject: Re: [PATCH 1/2] xen/efi: Handle cases where file didn't come from ESP
Message-ID: 
References: <20250624083157.9334-1-frediano.ziglio@cloud.com>
 <20250624083157.9334-2-frediano.ziglio@cloud.com>
 
 
 
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="zja0C8fd79G9+cQV"
Content-Disposition: inline
In-Reply-To: 


--zja0C8fd79G9+cQV
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 24 Jun 2025 17:28:00 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Frediano Ziglio 
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" ,
	Jan Beulich 
Subject: Re: [PATCH 1/2] xen/efi: Handle cases where file didn't come from ESP

On Tue, Jun 24, 2025 at 04:12:46PM +0100, Frediano Ziglio wrote:
> On Tue, Jun 24, 2025 at 3:35=E2=80=AFPM Marek Marczykowski-G=C3=B3recki
>  wrote:
> >
> > On Tue, Jun 24, 2025 at 03:05:25PM +0100, Frediano Ziglio wrote:
> > > OT: the flow of read_file (specifically "what" handling) looks
> > > weird... can I change it?
> >
> > It tries to avoid duplication of PrintErr calls, while including what
> > failed in the error message. Looks like somebody really wanted to avoid
> > using goto here... Sure, if you want to clean it up go ahead.
> >
>=20
> 2 styles came into my mind
> gotos: https://gitlab.com/xen-project/people/fziglio/xen/-/blob/flow1/xen=
/common/efi/boot.c?ref_type=3Dheads#L765

This one, harder to make a mistake if for example there would be a call
with different error reporting.

> no errors: https://gitlab.com/xen-project/people/fziglio/xen/-/blob/flow2=
/xen/common/efi/boot.c?ref_type=3Dheads#L765
>=20
> What do you think?
>=20
> Frediano

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

--zja0C8fd79G9+cQV
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmhaxAAACgkQ24/THMrX
1yyvTQf9HTFCcm4VrIpycf624uXehPkh1xbb16EuYGyPuKAFt1Ok/iLHnmQIm5p8
DOCaPmqjmvnN2zkPBvQOfXwnebOkuWzFY7v8JA2GSNcXs2v6jJy1gCFa6LXDUrDS
f+IkEpWEd6Bwtt+DLoDqCsxaopKz+U3VgG6WRMo0niz1BDj0kQWLINBI9jP6J75W
P6ige0520/lUb0v7+2eiODS80ONwTCQr0fOezaUTnjua87O0Zm9D78RqSJzClu6o
fqYuVlDEE4i1HCW5qD7mjot49Qus+xnvVRwSUsEvY6cWhRdkQZgBO8wQNoW/GEZK
UqV7XHpm4GJIz/T9MjN/gXgp5GGGxQ==
=gSuE
-----END PGP SIGNATURE-----

--zja0C8fd79G9+cQV--


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 15:29:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 15:29:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023876.1399948 (Exim 4.92)
	(envelope-from )
	id 1uU5ac-0003jL-N9; Tue, 24 Jun 2025 15:29:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023876.1399948; Tue, 24 Jun 2025 15:29:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uU5ac-0003jE-KN; Tue, 24 Jun 2025 15:29:38 +0000
Received: by outflank-mailman (input) for mailman id 1023876;
 Tue, 24 Jun 2025 15:29: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 1uU5ab-0003j8-BY
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 15:29:37 +0000
Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com
 [2607:f8b0:4864:20::932])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 081c4e09-5110-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 17:29:35 +0200 (CEST)
Received: by mail-ua1-x932.google.com with SMTP id
 a1e0cc1a2514c-87edd8f4e9fso158126241.0
 for ; Tue, 24 Jun 2025 08:29:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 081c4e09-5110-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750778974; x=1751383774; 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=L5CUv+qZ7XYmxSv8jilZY9A4Naqfa47fR+1/XJ1ZKe8=;
        b=PpXkIGFYTapV35pCVbs92GgCdTMRbXQshzyCq7oWmo4GkzAjRsHS6Pi36Bqy00IXrv
         FXYzhsZfx+QbHig8cHEm+oEXLEfT2k23F0epbfTVdkgS3pJix8faYhkG9Yy57Z1C7xIX
         ss7/XBkuweOW+k07jtJfU8pELYQt5SNGKJqwM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750778974; x=1751383774;
        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=L5CUv+qZ7XYmxSv8jilZY9A4Naqfa47fR+1/XJ1ZKe8=;
        b=NOiYsR3Xta/cYFs1JHJa0uIR7sE1kuhSjkc9OaB1WNh9OyfTgvViIh7hsZ6RyDPGMM
         fTQdnwpWeI+I8UUC8gI3GNAI//z27QCBA7vK9G0wntDMMFZLaecmLbGxw/afXuBviunZ
         5QyLGEWE1qELtd0Od6dCKXop+QT+kA+19A4EfJx+HG1nres2QyHozDV+Z6DYFeEK0dCN
         UqCejLdn6SaiiTa/JA9NHF5tf1U3ejkf6kp/8Kz0XS+zUQ1maBD9/zs1wZ/kObZO3KBL
         vSxXG3TV0D4xM/hpPHvw75/9gbAsMM/WmAsFlRdXGCKuGDGm1Shczb6Abf4U7iwktxvN
         3afA==
X-Forwarded-Encrypted: i=1; AJvYcCXSinpjRM0PMI8eeFi0Wgnitf7tmGmkW0iaHaaTpsVTrbiJMJVWZ49XvYpF6kHqkfwg2BduLmi4Osg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwAhQMelC36NBMxIQTQ2r9rJGmdauJbmZ4jVQ7gVRR6zxUhKvvL
	jOOxIG9JQiWvz/fvtgIeSWFKMtBOP4yI8QptmQ5zNUxNLU9yrz8auHg6mmHuPw62pxwXb1Wiqul
	Xi4sLP9oDzhDdkGSzcGvCZeaSVWkzo9AYQipDbd4ZYA==
X-Gm-Gg: ASbGncu1RSwSd8wAUY2ld6ay8h615jhNHF02IMfQhcCy7Ej4oa46/OfsGUpvxEuigyQ
	VTeH1vdYyPdhp+8/zamFsjrKkBXoC4TEd1fqbCcO3ZwbsGokW1i3WFjwGn54pbnOUDEMtrnbuSM
	l0hBobkt7gsv0N9WHz47DO47L3XxgT8VLnv0oZcuaZWnar2w==
X-Google-Smtp-Source: AGHT+IFJQ9gSxKG844xagbwUMVABeOtkjGjq9IfuqRh18kKVFfHuxToqr0nmfzAW97xmU/p3nhqUNRaNF0Yibk3pHTM=
X-Received: by 2002:a05:6122:4145:b0:530:65b3:4920 with SMTP id
 71dfb90a1353d-531ad58aaaamr9591284e0c.5.1750778973875; Tue, 24 Jun 2025
 08:29:33 -0700 (PDT)
MIME-Version: 1.0
References: <47b7f870-e1d9-44c9-b8ea-5b9028843963@gmail.com> <955F5D37-20D3-4B33-867E-78A0B83A4FB2@cloud.com>
In-Reply-To: <955F5D37-20D3-4B33-867E-78A0B83A4FB2@cloud.com>
From: Edwin Torok 
Date: Tue, 24 Jun 2025 16:29:22 +0100
X-Gm-Features: AX0GCFt4uagbeG36GDdVovC6o4Tkl0UZzSUs2zsqnnzveieYN6fgRhu2sgoYZTE
Message-ID: 
Subject: Re: xenstore - Suggestion of batching watch events
To: Christian Lindig 
Cc: Andriy Sultanov , xen-devel@lists.xenproject.org, 
	=?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , ngoc-tu.dinh@vates.tech, 
	Christian Lindig 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 24, 2025 at 4:21=E2=80=AFPM Christian Lindig
 wrote:
>
> I believe what you observe is a major source of inefficiency for the reas=
on you describe: changes are acted upon too early because there is no way t=
o observe that they are part of a transaction. So now heuristics come in li=
ke waiting for more changes before acting on the ones observed. I wonder ho=
w the tree structure plays into this. Clients watch different sub trees and=
 we don=E2=80=99t exploit this knowledge. I do agree that some protocol or =
syntax to batch updates would be useful.

This is probably where the Irmin-based prototype had an advantage,
pulling batched updates is something that 'git' is good at, and in
many ways Irmin was similar to git.
When I joined XenServer I've been told that all the improvements from
the Irmin prototype got integrated back into the mainline one, but
that clearly isn't true, because:
* the mainline one had a lot of security issues that the Irmin based one di=
dn't
* batching of updates is completely absent

Since this "high-bandwidth" event mechanism is only needed by Dom0 I
think we can avoid sending these using the xenstore PV ring protocol,
and even if we don't use Irmin to implement or send the updates, we
shouldn't be constrained anymore by the 4K limitation of a xenstore
packet on the socket interface in Dom0.

If this is a new kind of API message then clients can opt-in (older
clients who can't cope with such larger responses won't know to make
the new API call either).
That would avoid the problem we had with the directory protocol where
O and C versions assigned different semantics *to the same API call*
(O version used >4k packets, C version failed and only worked with the
PARTIAL protocol). Now we finally have behaviour parity on that, so
any change we make, I suggest we do by introducing a new API call that
doesn't inherit legacy limitations like 4K packets sizes on unix
domain sockets at least.

Best regards,
--Edwin
>
> =E2=80=94 C
>
>
> > On 24 Jun 2025, at 15:51, Andriy Sultanov  wr=
ote:
> >
> > Currently, as far as I am aware, the ability of xenstore clients to pro=
perly
> > handle and detect batch updates is somewhat lacking. Transactions are n=
ot
> > directly visible to the clients watching a particular directory - they =
will
> > receive a lot of individual watch_event's once the transaction is commi=
tted,
> > without any indication when such updates are going to end.
> >
> > Clients such as xenopsd from the xapi toolstack are reliant on xenstore=
 to
> > track their managed domains, and a flood of individual updates most oft=
en
> > results in a flood of events raised from xenopsd to xapi (There are
> > consolidation mechanisms implemented there, with updates getting merged
> > together, but if xapi picks up update events from the queue quickly eno=
ugh, it
> > will only get more update events later)
> >
> > The need for batching is fairly evident from the fact that XenServer's =
Windows
> > PV drivers, for example, adopted an ad-hoc "batch" optimization (not do=
cumented
> > anywhere, of course), where some sequence of writes is followed by a wr=
ite of
> > the value "1" to "data/updated". This used to be honoured by xapi, whic=
h would
> > not consider the guest agent update done until it received notice of su=
ch a
> > "batch ended" update, but it caused xapi to miss updates that were not =
followed
> > by such a write, so xapi now ignores this ad-hoc batching. One could im=
agine
> > many workarounds here (for example, some sort of a mechanism where xeno=
psd
> > stalls an update for a second to see if any more related updates show u=
p and
> > only then notifies xapi of it, with obvious trade-offs), but IMO it cou=
ld be
> > worth considering making this easier on the xenstore side for different
> > use-cases.
> >
> > Suggestion:
> > WATCH_EVENT's req_id and tx_id are currently 0. Could it be possible, f=
or
> > example, to modify this such that watch events coming as a result of a
> > transaction commit (a "batch") have tx_id of the corresponding transact=
ion
> > and req_id of, say, 2 if it's the last such watch event of a batch and =
1
> > otherwise? Old clients would still ignore these values, but it would al=
low
> > some others to detect if an update is part of a logical batch that does=
n't end
> > until its last event.
> >
> > Is this beyond the scope of what xenstored wants to do? From a first gl=
ance,
> > this does not seem to introduce obvious unwanted information leaks eith=
er, but
> > I could be wrong. I would love to hear if this is something that could =
be
> > interesting to others and if this could be considered at all.
> >
> > Thank you!
> >
> >
>


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 15:32:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 15:32:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023887.1399958 (Exim 4.92)
	(envelope-from )
	id 1uU5dN-0005V1-7A; Tue, 24 Jun 2025 15:32:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023887.1399958; Tue, 24 Jun 2025 15:32:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uU5dN-0005Uu-4Y; Tue, 24 Jun 2025 15:32:29 +0000
Received: by outflank-mailman (input) for mailman id 1023887;
 Tue, 24 Jun 2025 15:32: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 1uU5dL-0005Uo-Ow
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 15:32:27 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6e1b896f-5110-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 17:32:25 +0200 (CEST)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-60700a745e5so10869261a12.3
 for ; Tue, 24 Jun 2025 08:32:25 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-60c2f196c01sm1188587a12.8.2025.06.24.08.32.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 08:32:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6e1b896f-5110-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750779145; x=1751383945; 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=gpdaQy4McXynnxNOtXAw9z3+Dz9Lljao8HeM5Ru8ouA=;
        b=kutGpZzeXfHzOa/H990smssoIuhPJ0/R7nNCdoNN7gtD97j6Hn3zgROTCE1+lsMUVM
         P+bW/XROjgfiUf1fT5OV+lpD/DWOScsPviIlY03YDm2YLolspDNy9glKWInUV2spMu53
         2LuWQ1wVxHsRzu49yYxOak3S7imk0Ig6kogEoFEbOwfKO8HOFyGybmslQ2B0LM2AyK1L
         UAFxmdKlBuSuG/SPEnHa7uVTTexbbjcqHSW68LJdx1pOsPEXZORnP3wSknLMVhTUh6up
         92O/glcV3jOF2BY/uFMjvWZBxoEGk27K/CBv72LFWpki9UJlQ/P2W9A9WTDFzNI+hIBm
         gHrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750779145; x=1751383945;
        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=gpdaQy4McXynnxNOtXAw9z3+Dz9Lljao8HeM5Ru8ouA=;
        b=JpCMq2AkHskXctPOVeTnd+mGVheBSo2cqwJgbYaple346fp0mysO9BlE/ITWWBHNoe
         b+CLPIEtYoenBEPWe/nN0SApnniV1Eo+wsQkkYJTUQ0JHd+CZ7itGTnz/Gb3j12GyhUW
         g+lggqEuHOeRMAdBrBYWcPpkAhJTn3yhnzZgpHeWdI4sdTcJcj0e7sgHJwApC0Br+4C5
         Ezpi7pq0Eh3hbgK12pAT2+tT09IfJDhLfu1pmjaNA4YTRI1hSDobSD5pu10UUyaxP4VE
         cfXCeCSt45a0Vx0JmUFKjPxdhKvFvZ+tDUwFxRHfIBeZejc+nuZHsaNP7Jd1lB2369TM
         SByg==
X-Forwarded-Encrypted: i=1; AJvYcCX+mc2RXWj8oU4prFFLvhmPF3Pxm/V4jJZtGSA+6n1oB3m9CR3z5ClLryxH5GImadigXCA4yRENwsA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwiN7C1YEKOndRfIta+tUMWC7CvzBdWnLzp1D/n4I2obtIH92ak
	AGiAqrmPx724tFnVi8NIuM4EjoHQuJF6CE/X+Dy8T+/plpThEXXMXmWf
X-Gm-Gg: ASbGnct+OFBbfOplSgVZUOVao7lQ7zXYBnNm0beVSlLGj9U2q2FvSAc5jBu+yKLGRvE
	J+DQKWFp0IkixuNxQwpvujqs/YqI1CWoDL5MdBfqWC46wEePSvTL3bg9lcLZyscfqFZ0ihFo6Ge
	yQDgI79gFcWGVxs4NonUA8e+f+uYpzwj3+KkkNPcf/wDSW9u7Lq0lls9Ln5rQEPqFMm/uhw3wFN
	XjojshMwx4iJo2VfzwOhmbHAOAwkVPB2DyTGk5EiDlvS0tPhudyH9USybd/o3//IsCgSwIqNkXp
	/XeJHrj9mru3u2/GrAdgRm7rtHIY4E2zHvgTTJg7/edzRfWnJz7899VueaQkpRz2PPyPuKlaJYX
	YJ2M2RNlH9veSz5kTWhHNNG2Xf+PQNAOs9j4=
X-Google-Smtp-Source: AGHT+IElrT7EFJLCFM3kKWyD7xtoobTWY+tQrt1T92EoXQ+clgX7sdGIMSePrJCyCDLacdJyyBNspw==
X-Received: by 2002:a05:6402:d0d:b0:607:f257:ad1e with SMTP id 4fb4d7f45d1cf-60a1d16775amr15725564a12.22.1750779144958;
        Tue, 24 Jun 2025 08:32:24 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------VER609lEyLacFcpjKMatvkaI"
Message-ID: 
Date: Tue, 24 Jun 2025 17:32:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 03/17] xen/riscv: introduce guest domain's VMID
 allocation and manegement
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: 
 
 
 <145f71c2-643e-4839-a2ae-0bc1f049db74@gmail.com>
 <80223fe3-7403-4026-9505-8826c318fabb@suse.com>
 
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

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


On 6/24/25 4:01 PM, Jan Beulich wrote:
>>>>>> +        sbi_remote_hfence_gvma_vmid(d->dirty_cpumask, 0, 0, p2m->vmid);
>>>>> You're creating d; it cannot possibly have run on any CPU yet. IOW
>>>>> d->dirty_cpumask will be reliably empty here. I think it would be hard to
>>>>> avoid issuing the flush to all CPUs here in this scheme.
>>>> I didn't double check, but I was sure that in case d->dirty_cpumask is empty then
>>>> rfence for all CPUs will be send. But I was wrong about that.
>>>>
>>>> What about just update a code of sbi_rfence_v02()?
>>> I don't know, but dealing with the issue there feels wrong. However,
>>> before deciding where to do something, it needs to be clear what you
>>> actually want to achieve. To me at least, that's not clear at all.
>> I want to achieve the following behavior: if a mask is empty
>> (specifically, in our case|d->dirty_cpumask|), then perform the flush
>> on all CPUs.
> That's still too far into the "how". The "why" here is still unclear: Why
> do you need any flushing here at all? (With the scheme you now mean to
> implement I expect it'll become yet more clear that no flush is needed
> during domain construction.)

For the same reason x86 has flush:
     /* If there are no free ASIDs, need to go to a new generation */
     if ( unlikely(data->next_asid > data->max_asid) )
     {
         hvm_asid_flush_core();

But hvm_asid_flush_core() isn't doing a "real" flush what I missed to check
on the first look at hvm_asid_handle_vmenter().

So I assume then a "real" flush will be called somewhere before entry to guest
context.

I think now it is more or less clear.

Anyway, what then do for the cases if it is needed to have ASID which isn't
expected to be changed?
With this cycling approach after a new generation will be needed, all ASIDs
could/will be changed. It isn't a case for RISC-V (at least, at the moment)
but AFAIK it is an issue for AMD SEV.

~ Oleksii

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



  
    
  
  
    

    
    
    
    
    On 6/24/25 4:01 PM, Jan Beulich wrote:
    
    
    
    
    
      
    +        sbi_remote_hfence_gvma_vmid(d->dirty_cpumask, 0, 0, p2m->vmid);

    You're creating d; it cannot possibly have run on any CPU yet. IOW
d->dirty_cpumask will be reliably empty here. I think it would be hard to
avoid issuing the flush to all CPUs here in this scheme.

    I didn't double check, but I was sure that in case d->dirty_cpumask is empty then
rfence for all CPUs will be send. But I was wrong about that.

What about just update a code of sbi_rfence_v02()?

    I don't know, but dealing with the issue there feels wrong. However,
before deciding where to do something, it needs to be clear what you
actually want to achieve. To me at least, that's not clear at all.

    I want to achieve the following behavior: if a mask is empty
(specifically, in our case|d->dirty_cpumask|), then perform the flush
on all CPUs.

    That's still too far into the "how". The "why" here is still unclear: Why
do you need any flushing here at all? (With the scheme you now mean to
implement I expect it'll become yet more clear that no flush is needed
during domain construction.)
    
    
    
    
    For the same reason x86 has flush:
    /* If there are no free ASIDs, need to go to a new generation */
    if ( unlikely(data->next_asid > data->max_asid) )
    {
        hvm_asid_flush_core();

But hvm_asid_flush_core() isn't doing a "real" flush what I missed to check
on the first look at hvm_asid_handle_vmenter().

So I assume then a "real" flush will be called somewhere before entry to guest
context.

I think now it is more or less clear.

Anyway, what then do for the cases if it is needed to have ASID which isn't
expected to be changed?
With this cycling approach after a new generation will be needed, all ASIDs
could/will be changed. It isn't a case for RISC-V (at least, at the moment)
but AFAIK it is an issue for AMD SEV.

~ Oleksii


    
  


--------------VER609lEyLacFcpjKMatvkaI--


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 15:43:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 15:43:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023910.1399969 (Exim 4.92)
	(envelope-from )
	id 1uU5nv-0007NP-5g; Tue, 24 Jun 2025 15:43:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023910.1399969; Tue, 24 Jun 2025 15: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 1uU5nv-0007NI-1V; Tue, 24 Jun 2025 15:43:23 +0000
Received: by outflank-mailman (input) for mailman id 1023910;
 Tue, 24 Jun 2025 15: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 1uU5nt-0007NC-LY
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 15:43:21 +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 f4624384-5111-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 17:43:20 +0200 (CEST)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-451e2f0d9c2so37285525e9.1
 for ; Tue, 24 Jun 2025 08:43:20 -0700 (PDT)
Received: from [192.168.0.18]
 (cpc92320-cmbg19-2-0-cust1786.5-4.cable.virginm.net. [82.13.70.251])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4535e98b48asm180983835e9.16.2025.06.24.08.43.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 08:43:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f4624384-5111-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750779800; x=1751384600; 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=HEHY+qVq0r9ZpEE3sKqySuCMi7v4bHNZzkUN4mDy9dY=;
        b=BLpJj+Uw37Sg4iKwuY++PuzbqN6LispUihDEl8RpNJXYG7mKAu+7/6DLrNCkDYFcTb
         G3eL0eSzM7XgGHaVOVy1Gt7YzSAiXZfg6w6fSXJhqxApS9jkBx3BeszNkirNcAR8GJRR
         LVokNiPIu0kSqK3n0OIEC2OsZO5R4TVifITXTYtBdjL2N+hb7Xc40rc+bfd2oYN02i1W
         sF2nOz8eH5nz86dp7+isHi1789aQV5B+nauGfKfbE5xBJdwEsZpij1UMrACmRO2/nelE
         xqoQVGtMnQ450Xow46WKa9y9qYzLbO97kpZ/m7OUn9Y9EQ42xtTkQ3pGydaVvaUj58F+
         0DtA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750779800; x=1751384600;
        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=HEHY+qVq0r9ZpEE3sKqySuCMi7v4bHNZzkUN4mDy9dY=;
        b=eR5a6p47OuBe/6n/W8fhMEWLSO6ZzjNd+lO8eqTgMrTeT0ljQMCh1y+2HMmsh+39ZU
         Rka617o7kGisKiJHuvyS1mDqFk+lwjpuBs+NOZvcUXZs4XK6lkrYz+2jH7WbSfjxcUCu
         enuEyybPKkbMmPs5mngqjE34FBX3JAUQCZHTwM6o01RSwA5o727tHWVs/gOHL4BZZZky
         zxS4mKsjN08H2ZCqjsJwKr/NU+72HodijUXnCEpxxwFC9f1PTnZWHJ7bedo5mhcjbqGF
         awY7CImIkdyP/BpCnb6yy7g5tTe0kHQo4rpQEURHTyFTVZTTAyPGCG/xGUqOClYXHZR+
         kdzA==
X-Forwarded-Encrypted: i=1; AJvYcCWXO1SLDUMv6Yfw/wPnYTfTWuSlGCo257fBhj13fjfThWD5cmEVcky0Y0IMEmehZStlKt+VTDLGzIo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxCpNGAM/U8Fmj+9+k4RV/58QRjtaAoKkaWFdg2OO64GQ1K3Q8Z
	wSGsB3bpV5qvXTCRh31xiap9iCl9DBccYu7PfMM9l3ZbZaPIjLaWYUrH
X-Gm-Gg: ASbGncstyVjHjYLK2elV8gZ6ByyMQF7uFuNJyixu+I9zsb4Mt4RS67l8spl55G7W/Cv
	4k5npC3y9r5sipn3uvQlTEaPs6rJKBUG5PNv8ztSm6vCrPvS6pJ8GKkDLaFq9a6fORtz0Xll0yD
	fLolud1UiGdR/lP4FKSAv6L3OoQdXlNrhI0HHLdvcDCxLL/svRiPfJvysj0jZ4TKEe4PjH8hZBM
	+2lFBiBdG+7kxaw0VZiUd3hRPLEhw3LrBXwrDqjS5y0OBpu+UcSryFuFmUqpwrn1SfIXbAmBafy
	Kr7rkIAUwzcxKh+afExR9gZIXLRYJ+fKgHckPBWwDUAO3P5kYBt+4xN50cKnyrghiKL1c6k7Iiz
	xTx3X7SypKfAbIINCk1wY86QBwIlF9WnXjI1JXW38Y+7zHQF8KzTp
X-Google-Smtp-Source: AGHT+IG9gdcQt2YO1VB1xulXhkOVGAB5MZr3qOdYF4vJ0x8icTsa6zjgYlQrSW3eDS8JrV37HWWklw==
X-Received: by 2002:a05:600c:8b06:b0:453:6c45:ce14 with SMTP id 5b1f17b1804b1-4537ba0c671mr35361615e9.4.1750779799859;
        Tue, 24 Jun 2025 08:43:19 -0700 (PDT)
Message-ID: <0b43d8e0-7ba6-43e4-9b0a-58c45d222c4a@gmail.com>
Date: Tue, 24 Jun 2025 16:43:18 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: xenstore - Suggestion of batching watch events
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= ,
 xen-devel@lists.xenproject.org
Cc: =?UTF-8?B?RWR3aW4gVMO2csO2aw==?= ,
 ngoc-tu.dinh@vates.tech, Christian Lindig 
References: <47b7f870-e1d9-44c9-b8ea-5b9028843963@gmail.com>
 
Content-Language: en-US
From: Andriy Sultanov 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 6/24/25 4:06 PM, Jürgen Groß wrote:

> The main reason for the large number of watch events after a 
> transaction is
> the fact that the watch for e.g. detecting the addition of a new block 
> device
> will be set on a node being common for all potential block devices 
> handled
> by the watcher. This results in a watch event for each single node 
> modified
> below this node, which are usually quite a lot even when only adding a 
> single
> device.
>
> The solution for this problem is NOT to batch all the events and to 
> ignore the
> majority of those events, but to avoid creating most of those events.
>
> For this reason the Xenstore protocol has been extended to allow for 
> limiting
> the number of node levels below a watched node to be relevant for a 
> watch to
> fire.
>
> What is missing so far are Xenstore implementations to support this 
> feature,
> and Xenstore users to make use of it. I'm working on supporting this in
> C xenstored, but due to other urgent work this will probably land 
> upstream only
> in the Xen 4.22 time frame, probably together with Xen tools (libxl) 
> making use
> of this feature.
>
>
> Juergen

I was not aware that watch has had a (relatively) new unimplemented 
parameter
added, thanks! I've noted this on the oxenstored side.
(https://github.com/xapi-project/oxenstored/issues/15)

But I think this only covers part of the problem. Looking at the 
concrete case of
xenopsd and Windows VMs, xenopsd cares about most of the nodes it receives
watch events from, the issue is that it doesn't know when these are grouped
together in one way or another.



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 15:51:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 15:51:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023922.1399978 (Exim 4.92)
	(envelope-from )
	id 1uU5vu-0000jd-TN; Tue, 24 Jun 2025 15:51:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023922.1399978; Tue, 24 Jun 2025 15:51: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 1uU5vu-0000jW-QD; Tue, 24 Jun 2025 15:51:38 +0000
Received: by outflank-mailman (input) for mailman id 1023922;
 Tue, 24 Jun 2025 15:51: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 1uU5vu-0000jQ-1q
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 15:51:38 +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 1c5758be-5113-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 17:51:37 +0200 (CEST)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-45363645a8eso5479695e9.1
 for ; Tue, 24 Jun 2025 08:51:37 -0700 (PDT)
Received: from smtpclient.apple ([46.149.103.10])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4535e98b4bbsm177130985e9.15.2025.06.24.08.51.35
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 24 Jun 2025 08:51:36 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1c5758be-5113-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750780296; x=1751385096; 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=TmGd69PDFrNPW22/J1mbXlYqViu5Kv+SdMkooLD1Y/w=;
        b=fZ3WROFheGjCLjz20DTBlclnZ4e3e921jUxpBQmNFFEILvRNabpdSfqO9u5kzJwmbp
         RPsKwXnAoGTAt1Tr2IsEKUnjtKAST2ZEmVibJl1P3ytFZ+4aqH2e9mZU4v9Bs1Y5QKMF
         wdGG6tQYHu80hJmrdCBJORWTO4MJIpkTvp+GQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750780296; x=1751385096;
        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=TmGd69PDFrNPW22/J1mbXlYqViu5Kv+SdMkooLD1Y/w=;
        b=v2A6btBzigKNvcl45lk/N4F9iFK9dFaitATIjtyUP550oSZs1CJdvipGPGUGtPVCFa
         U4qG7yjhX2/UwUPuaLxdpntW436HfgwNsOFyme7aTxxa2njrU1ic0WqrdiWVmh0+W7F7
         ATvoDbPXA5erpgUSQy3YLXUI3aX9Ve/qWorfllZDILtd65NFnTYVJqwpnpTDJXbBE06A
         T4ELtjCaSVA/XMWwY1IM7rslJI7CtbT/hhY/w5gMz4NaMaViVM3u+PHW0SwZ3g25nNCo
         bY8DDgjEKgXNyDj32s01aoxdqmi/af7GGsGQrBIGY0bFTR2k1zotJ0AP6qolog5V1FMw
         WinQ==
X-Forwarded-Encrypted: i=1; AJvYcCVrsHT5hfhsgDFhQkzFJzVOGgX+5dGCEFbWhXYLvlnmAxRnDHJ3yYpH+qvMPFMyqLOO/CO6XoNrTJM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwAPKr2kcWFmg+Pz/ohkjX2Vg+UuA0AClpjlPqnlo5Zl0djaWFp
	BR6YSpleo5AUcZ8t9UWPXR2ShSfl997Q8Vu/tKJNcPMQoE1e0SVGAaA6RmjwJpqsLNE=
X-Gm-Gg: ASbGncu/lvPPYi7OyEq/TkEdqw4DAm/6ThsTYwrhciT93SLDnqE4bIZFT5QSXliw/n0
	lkwxkKyvc7dDs+drtODZoMDi0QR7IBaybrD/yi+9EaZoIZ7VDl4gTHMRjVXpuWCeTOBSaAWr0qQ
	FYkS27sJKpLxFqSVq/SEdIFMVDqsAZ02TSn9yJikh6HNNdKbr9QaJ3wuqL9+H7dszDZYYAWZ2mQ
	Y4wClUBUe8FALzWpC8rNMIRgTwiDd+XZ4qv4nRrO1FFOZqC+zN48KawxcIjc6y2F95Mf4FwcBAi
	IpsV4hbxf03f4GAoHCGV8DRuLSxpY3STfHIi+V3hgtY4EEqOHaI/4TrNj5JyAm3UOwgysnOdIkr
	BxF+l3CuQ3W/BGxu5
X-Google-Smtp-Source: AGHT+IHlNpAmC9nky8iOX7FQo+3wKBpZQDqYzNSzLSaRXV8395DtwZ57C69nfswU4MrKwKl+bIBftg==
X-Received: by 2002:a05:600c:3b24:b0:453:c39:d0a7 with SMTP id 5b1f17b1804b1-453653cf416mr154961135e9.5.1750780296565;
        Tue, 24 Jun 2025 08:51:36 -0700 (PDT)
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\))
Subject: Re: xenstore - Suggestion of batching watch events
From: Christian Lindig 
In-Reply-To: <0b43d8e0-7ba6-43e4-9b0a-58c45d222c4a@gmail.com>
Date: Tue, 24 Jun 2025 16:51:25 +0100
Cc: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= ,
 xen-devel@lists.xenproject.org,
 =?utf-8?B?RWR3aW4gVMO2csO2aw==?= ,
 ngoc-tu.dinh@vates.tech,
 Christian Lindig 
Content-Transfer-Encoding: quoted-printable
Message-Id: <66FC0F57-1654-40FD-88A9-37A960D37C1F@cloud.com>
References: <47b7f870-e1d9-44c9-b8ea-5b9028843963@gmail.com>
 
 <0b43d8e0-7ba6-43e4-9b0a-58c45d222c4a@gmail.com>
To: Andriy Sultanov 
X-Mailer: Apple Mail (2.3826.500.181.1.5)



> On 24 Jun 2025, at 16:43, Andriy Sultanov  =
wrote:
>=20
> But I think this only covers part of the problem. Looking at the =
concrete case of
> xenopsd and Windows VMs, xenopsd cares about most of the nodes it =
receives
> watch events from, the issue is that it doesn't know when these are =
grouped
> together in one way or another.

Is the common case that a client wants to observe the changes rather =
than just knowing that a change occurred? If so, it seems transmitting =
changes as part of a watch event (rather than forcing the client to =
traverse the tree) would be a better protocol. That would suggest to =
introduce a new kind of watch that reports changes at the end of a =
transaction. The size of the event would depend on the size of the =
change.

=E2=80=94 C




From xen-devel-bounces@lists.xenproject.org Tue Jun 24 16:16:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 16:16:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023928.1399988 (Exim 4.92)
	(envelope-from )
	id 1uU6Jy-0004Na-Og; Tue, 24 Jun 2025 16:16:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023928.1399988; Tue, 24 Jun 2025 16:16: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 1uU6Jy-0004NT-LX; Tue, 24 Jun 2025 16:16:30 +0000
Received: by outflank-mailman (input) for mailman id 1023928;
 Tue, 24 Jun 2025 16:16: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 1uU6Jx-0004NM-2Y
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 16:16:29 +0000
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com
 [2a00:1450:4864:20::436])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 94296399-5116-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 18:16:26 +0200 (CEST)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3a51481a598so2871015f8f.3
 for ; Tue, 24 Jun 2025 09:16:26 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d860aeacsm109511055ad.119.2025.06.24.09.16.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 09:16:25 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 94296399-5116-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750781786; x=1751386586; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=oT/Ii2+4GWo8Jygo9rxc/j+w8imMtzdp5Iq2z0ArJ2k=;
        b=QSvmkUWkKeHkwLauyhI2wR6PbCjDAQMEYCCHgilTK1eM9vOqMVji/obCNd9MT5aSxs
         ivDgNci7khaEXWgpOxq8G6xaSKAZWwfj8BMRRoK7MR5IgW6JTzrKFKqdu1G/0FYGSSzR
         3x4hUqphDdPovfjmDg8SxG1zHHRuYfO4VUsvKTDuvvUrYwXw8msRAotPZoBqqWkk8z30
         cZCgnD1fIxKhNRTfdNgS9ckzpGc7vJRq9O0aC8PcXM21pC4tYTUTyWRT/l9ztdvSHaum
         BkKew8DWSUlvRX3bs05JCVVfAH31Qg+TCa6qqy6ylvC4SR5lKltS14IsWkv+YWlNYLWm
         Te/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750781786; x=1751386586;
        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=oT/Ii2+4GWo8Jygo9rxc/j+w8imMtzdp5Iq2z0ArJ2k=;
        b=RWQdZOU4goqETAO4nRojqRMbN3TWZqz3uDm9+BeiT+WxFKpEOUcKoNOIqXhbxjU3dM
         fb+HMzbTj626MfpleDb5qwYNcZhBPGv+O5GzgEmRfxcghCGvmE9GS/2DNVEvqF+Up0/x
         uSTlAwS1qvo6mHmemIh9qQwk32X0Ju97KJRYPgsen9m+ee4TNjkAdCUuNKOqqdrAKBzU
         suL9PZ2Sz7PzeAGsAUwE/iQYPf7vDqGj9rUp9/h6WhSefgKKVB9JnK1D3ZkD/RoS+HWs
         cXZh7k7q3REYSF8AS3pmlSAOM5CGcNtr1cYcO+J4zqckGTtIQ6WVuEADcUOpqTJiFkek
         IGFA==
X-Forwarded-Encrypted: i=1; AJvYcCXwFVksg89CYOauRTGahoMLwtKSziwe1Uahl3ukLMeib0RzA7BMm2U4SfC5i3YOCAqrmCWIOsfpLPo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzBAWiNlBnvNPOpbMcu64cP8MRpzZLd/IM6FZGv2G0cjOpszNNh
	qsJFLDi3Xwn59ttO8jyWxXE80x0OpytsxwAtjr1nqH/cWxHyqkp64QYyRUCYxLxQxg==
X-Gm-Gg: ASbGncsYIQsoVORsAN4JBTgFzy4CkPDCh6sU9snZzlzelsqlyA6sS2at2MNVDgd7Qx7
	SQWDnTpHF2YcvHuvPWyeUg3Z8GWHHc6OcYyvJ1ZKPY49vd+f6IadpV0sJY/u52m29gyVdlXNLZZ
	lPCkCHZLzjHT6GMPB1gB1/q9KdNyo/6jPJjh8ECu27ib5gxYaaErQNwu3WD2s7Woz6a7jE5TDGq
	qs1CxVfGUk0q/G5uk9HWScx7+sRomesn0xQG14fQ01InV0YjgFpfJKLvnW2GFx12TqOh0o+broD
	CdRDvyl3asNKXT/Nf0XwSyHKVmsg16fJqazhjOpgoBnXBiay+L9ikw1dNN9DTUkAwywKJ0PL/QI
	7r9GciUFV0V2l7ejzmKSU62zcOJXYssvYjoGnmw5uyVxPgQ8=
X-Google-Smtp-Source: AGHT+IEjqM71Tw1eMGfZVe8z2+2MTh3rhR2gsunrL1uv3fkYyB2/d6tzjFrSOWVwVGEdKssJ0ofITA==
X-Received: by 2002:a05:6000:491a:b0:3a5:39e9:928d with SMTP id ffacd0b85a97d-3a6d1166d39mr16688472f8f.0.1750781785864;
        Tue, 24 Jun 2025 09:16:25 -0700 (PDT)
Message-ID: 
Date: Tue, 24 Jun 2025 18:16:15 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 8/8] pdx: introduce a new compression algorithm based
 on region offsets
To: Roger Pau Monne 
Cc: Oleksii Kurochko ,
 Community Manager ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250620111130.29057-1-roger.pau@citrix.com>
 <20250620111130.29057-9-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: <20250620111130.29057-9-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 20.06.2025 13:11, Roger Pau Monne wrote:
> With the appearance of Intel Sierra Forest and Granite Rapids it's now
> possible to get a production x86 host with the following memory map:
> 
> SRAT: Node 0 PXM 0 [0000000000000000, 000000007fffffff]
> SRAT: Node 0 PXM 0 [0000000100000000, 000000807fffffff]
> SRAT: Node 1 PXM 1 [0000063e80000000, 000006be7fffffff]
> SRAT: Node 2 PXM 2 [00000c7e80000000, 00000cfe7fffffff]
> SRAT: Node 3 PXM 3 [000012be80000000, 0000133e7fffffff]
> 
> This is from a four socket Granite Rapids system, with each node having
> 512GB of memory.  The total amount of RAM on the system is 2TB, but without
> enabling CONFIG_BIGMEM the last range is not accessible, as it's above the
> 16TB boundary covered by the frame table. Sierra Forest and Granite Rapids
> are socket compatible, however Sierra Forest only supports 2 socket
> configurations, while Granite Rapids can go up to 8 sockets.
> 
> Note that while the memory map is very sparse, it couldn't be compressed
> using the current PDX_MASK compression algorithm, which relies on all
> ranges having a shared zeroed region of bits that can be removed.
> 
> The memory map presented above has the property of all regions being
> similarly spaced between each other, and all having also a similar size.
> Use a lookup table to store the offsets to translate from/to PFN and PDX
> spaces.  Such table is indexed based on the input PFN or PDX to translated.
> The example PFN layout about would get compressed using the following:
> 
> PFN compression using PFN lookup table shift 29 and PDX region size 0x10000000
>  range 0 [0000000000000, 0x0000807ffff] PFN IDX  0 : 0000000000000
>  range 1 [0x00063e80000, 0x0006be7ffff] PFN IDX  3 : 0x00053e80000
>  range 2 [0x000c7e80000, 0x000cfe7ffff] PFN IDX  6 : 0x000a7e80000
>  range 3 [0x0012be80000, 0x00133e7ffff] PFN IDX  9 : 0x000fbe80000
> 
> Note how the tow ranges belonging to node 0 get merged into a single PDX
> region by the compression algorithm.
> 
> The default size of lookup tables currently set in Kconfig is 64 entries,
> and the example memory map consumes 10 entries.  Such memory map is from a
> 4 socket Granite Rapids host, which in theory supports up to 8 sockets
> according to Intel documentation.  Assuming the layout of a 8 socket system
> is similar to the 4 socket one, it would require 21 lookup table entries to
> support it, way below the current default of 64 entries.
> 
> The valid range of lookup table size is currently restricted from 1 to 512
> elements in Kconfig.
> 
> Unused lookup table entries are set to all ones (~0UL), so that we can
> detect whether a pfn or pdx is valid just by checking whether its
> translation is bi-directional.  The saturated offsets will prevent the
> translation from being bidirectional if the lookup table entry is not
> valid.

Right, yet with the sad effect of still leaving almost half the space unused.
I guess that's pretty much unavoidable though in this scheme, as long as we
want the backwards translation to also be "simple" (and in particular not
involving a loop of any kind).

> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -20,6 +20,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>       grant table or foreign memory.
>  
>  ### Added
> + - Introduce new PDX compression algorithm to cope with Intel Sapphire and
> +   Granite Rapids having sparse memory maps.

In the description you updated to mention Sierra Forest instead, but here you
didn't.

> --- a/tools/tests/pdx/harness.h
> +++ b/tools/tests/pdx/harness.h
> @@ -44,8 +44,10 @@
>  
>  #define MAX_RANGES 8
>  #define MAX_PFN_RANGES MAX_RANGES
> +#define CONFIG_PDX_OFFSET_TLB_ORDER 6
>  
>  #define ASSERT assert
> +#define ASSERT_UNREACHABLE() assert(0);

Nit: Stray semicolon.

> @@ -66,6 +68,8 @@ static inline unsigned int find_next(
>  #define find_next_zero_bit(a, s, o) find_next(a, s, o, false)
>  #define find_next_bit(a, s, o)      find_next(a, s, o, true)
>  
> +#define flsl(x) ((x) ? BITS_PER_LONG - __builtin_clzl(x) : 0)

While this is perhaps indeed good enough for a testing utility, ...

> @@ -75,6 +79,12 @@ static inline unsigned int find_next(
>  
>  typedef uint64_t paddr_t;
>  
> +#define sort(elem, nr, size, cmp, swp) {                                \
> +    /* Consume swp() so compiler doesn't complain it's unused. */       \
> +    (void)swp;                                                          \
> +    qsort(elem, nr, size, cmp);                                         \
> +}

... this I think wants to use either do/while of ({ }).

> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -54,7 +54,8 @@ config EVTCHN_FIFO
>  
>  choice
>  	prompt "PDX (Page inDeX) compression"
> -	default PDX_MASK_COMPRESSION if !X86 && !RISCV
> +	default PDX_OFFSET_COMPRESSION if X86
> +	default PDX_MASK_COMPRESSION if !RISCV
>  	default PDX_NONE
>  	help
>  	  PDX compression is a technique designed to reduce the memory
> @@ -73,12 +74,30 @@ config PDX_MASK_COMPRESSION
>  	help
>  	  Compression relying on all RAM addresses sharing a zeroed bit region.
>  
> +config PDX_OFFSET_COMPRESSION
> +	bool "Offset compression"
> +	help
> +	  Compression relying on size and distance between RAM regions being
> +	  compressible using an offset lookup table.
> +
>  config PDX_NONE
>  	bool "None"
>  	help
>  	  No compression
>  endchoice
>  
> +config PDX_OFFSET_TLB_ORDER

Please can we avoid the term "TLB" in the name? What we commonly call a TLB
is somewhat different. In fact is there anything wrong with just
PDX_OFFSET_ORDER?

> +	int "PDX offset compression lookup table order" if EXPERT
> +	depends on PDX_OFFSET_COMPRESSION
> +	default 6
> +	range 0 9

Is 0 really a sensible lower bound? There's not going to be any compression
then, I suppose?

> --- a/xen/common/pdx.c
> +++ b/xen/common/pdx.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /**
>   * Maximum (non-inclusive) usable pdx. Must be
> @@ -40,6 +41,8 @@ bool __mfn_valid(unsigned long mfn)
>  
>  #ifdef CONFIG_PDX_MASK_COMPRESSION
>      invalid |= mfn & pfn_hole_mask;
> +#elif defined(CONFIG_PDX_OFFSET_COMPRESSION)
> +    invalid |= mfn ^ pdx_to_pfn(pfn_to_pdx(mfn));

Hmm, that's pretty expensive already. Involving two (presumably back-to-back)
JMPs when compression isn't enabled.

> @@ -290,7 +300,200 @@ void __init pfn_pdx_compression_reset(void)
>      nr_ranges = 0;
>  }
>  
> -#endif /* CONFIG_PDX_COMPRESSION */
> +#elif defined(CONFIG_PDX_OFFSET_COMPRESSION) /* CONFIG_PDX_MASK_COMPRESSION */
> +
> +unsigned long __ro_after_init pfn_pdx_lookup[CONFIG_PDX_NR_LOOKUP];
> +unsigned int __ro_after_init pfn_index_shift;
> +
> +unsigned long __ro_after_init pdx_pfn_lookup[CONFIG_PDX_NR_LOOKUP];
> +unsigned int __ro_after_init pdx_index_shift;

For slightly better cache locality when only a few array indexes are in
use, may I suggest to put the indexes ahead of the arrays? Perhaps even
together, as they both take up a single unsigned long slot.

> +bool pdx_is_region_compressible(paddr_t base, unsigned long npages)
> +{
> +    unsigned long pfn = PFN_DOWN(base);
> +
> +    return pdx_to_pfn(pfn_to_pdx(pfn) + npages - 1) == (pfn + npages - 1);

Aiui for this to be correct, there need to be gaps between the ranges
covered by individual lookup table slots. In the setup logic you have a
check commented "Avoid compression if there's no gain", but that doesn't
look to guarantee gaps everywhere (nor would pfn_offset_sanitize_ranges()
appear to)?

> +static void __init cf_check swp_node(void *a, void *b, size_t size)
> +{
> +    struct pfn_range *l = a;
> +    struct pfn_range *r = b;
> +    struct pfn_range tmp = *l;
> +
> +    *l = *r;
> +    *r = tmp;
> +}

Any reason you effectively open-code SWAP() here?

> +static bool __init pfn_offset_sanitize_ranges(void)
> +{
> +    unsigned int i = 0;
> +
> +    if ( nr_ranges == 1 )
> +    {
> +        ASSERT(PFN_TBL_IDX_VALID(ranges[0].base));
> +        ASSERT(PFN_TBL_IDX(ranges[0].base) ==
> +               PFN_TBL_IDX(ranges[0].base + ranges[0].size - 1));
> +        return true;
> +    }
> +
> +    /* Sort nodes by start address. */
> +    sort(ranges, nr_ranges, sizeof(struct pfn_range), cmp_node, swp_node);

Better sizeof(*ranges) or sizeof(ranges[0])?

> +bool __init pfn_pdx_compression_setup(paddr_t base)
> +{
> +    unsigned long size = 0, mask = PFN_DOWN(pdx_init_mask(base));
> +    unsigned int i;
> +
> +    if ( !nr_ranges )
> +        return false;

Also bail if there's just a single range?

> +    if ( nr_ranges > ARRAY_SIZE(ranges) )
> +    {
> +        printk(XENLOG_WARNING
> +               "Too many PFN ranges (%u > %zu), not attempting PFN compression\n",
> +               nr_ranges, ARRAY_SIZE(ranges));
> +        return false;
> +    }
> +
> +    for ( i = 0; i < nr_ranges; i++ )
> +        mask |= pdx_region_mask(ranges[i].base, ranges[i].size);
> +
> +    pfn_index_shift = flsl(mask);

With this ...

> +    /*
> +     * Increase the shift as much as possible, removing bits that are equal in
> +     * all regions, as this allows the usage of smaller indexes, and in turn
> +     * smaller lookup tables.
> +     */
> +    for ( pfn_index_shift = flsl(mask); pfn_index_shift < sizeof(mask) * 8 - 1;

... you don't need to do this here another time.

Also - why the subtraction of 1 in what the shift is compared against? Logic
below should in principle guarantee we never exit the loop because of the
conditional above, but if we made it that far it looks like we could as well
also look at the top bit.

> +          pfn_index_shift++ )
> +    {
> +        const unsigned long bit = ranges[0].base & (1UL << pfn_index_shift);
> +
> +        for ( i = 1; i < nr_ranges; i++ )
> +            if ( bit != (ranges[i].base & (1UL << pfn_index_shift)) )
> +                break;
> +        if ( i != nr_ranges )
> +            break;
> +    }
> +
> +    /* Sort and sanitize ranges. */
> +    if ( !pfn_offset_sanitize_ranges() )
> +        return false;
> +
> +    /* Calculate PDX region size. */
> +    for ( i = 0; i < nr_ranges; i++ )
> +        size = max(size, ranges[i].size);
> +
> +    mask = PFN_DOWN(pdx_init_mask(size << PAGE_SHIFT));
> +    pdx_index_shift = flsl(mask);
> +
> +    /* Avoid compression if there's no gain. */
> +    if ( (mask + 1) * (nr_ranges - 1) >= ranges[nr_ranges - 1].base )
> +        return false;
> +
> +    /* Poison all lookup table entries ahead of setting them. */
> +    memset(pfn_pdx_lookup, ~0, sizeof(pfn_pdx_lookup));
> +    memset(pdx_pfn_lookup, ~0, sizeof(pfn_pdx_lookup));

Have the arrays have initializers instead?

> +    for ( i = 0; i < nr_ranges; i++ )
> +    {
> +        unsigned int idx = PFN_TBL_IDX(ranges[i].base);
> +
> +        pfn_pdx_lookup[idx] = ranges[i].base - (mask + 1) * i;
> +        pdx_pfn_lookup[i] = pfn_pdx_lookup[idx];
> +    }
> +
> +    printk(XENLOG_INFO
> +           "PFN compression using PFN lookup table shift %u and PDX region size %#lx\n",

I'd drop PFN and the latter PDX from this format string.

> +           pfn_index_shift, mask + 1);
> +
> +    for ( i = 0; i < nr_ranges; i++ )
> +        printk(XENLOG_DEBUG
> +               " range %u [%#013lx, %#013lx] PFN IDX %3lu : %#013lx\n",
> +               i, ranges[i].base, ranges[i].base + ranges[i].size - 1,
> +               PFN_TBL_IDX(ranges[i].base),
> +               pfn_pdx_lookup[PFN_TBL_IDX(ranges[i].base)]);

Do you really mean this to stay active also in release builds?

Also the outcome of the earlier loop isn't used by the intermediate printk().
Perhaps join both loops, thus allowing idx to be re-used here?

> +    return true;
> +}
> +
> +void __init pfn_pdx_compression_reset(void)
> +{
> +    memset(pfn_pdx_lookup, 0, sizeof(pfn_pdx_lookup));
> +    memset(pdx_pfn_lookup, 0, sizeof(pfn_pdx_lookup));

Why not ~0?

> --- a/xen/include/xen/pdx.h
> +++ b/xen/include/xen/pdx.h
> @@ -65,6 +65,43 @@
>   * This scheme also holds for multiple regions, where HHHHHHH acts as
>   * the region identifier and LLLLLL fully contains the span of every
>   * region involved.
> + *
> + * ## PDX offset compression
> + *
> + * Alternative compression mechanism that relies on RAM ranges having a similar
> + * size and offset between them:
> + *
> + * PFN address space:
> + * ┌────────┬──────────┬────────┬──────────┐   ┌────────┬──────────┐
> + * │ RAM 0  │          │ RAM 1  │          │...│ RAM N  │          │
> + * ├────────┼──────────┼────────┴──────────┘   └────────┴──────────┘
> + * │<------>│          │
> + * │  size             │
> + * │<----------------->│
> + *         offset
> + *
> + * The compression reduces the holes between RAM regions:
> + *
> + * PDX address space:
> + * ┌────────┬───┬────────┬───┐   ┌─┬────────┐
> + * │ RAM 0  │   │ RAM 1  │   │...│ │ RAM N  │
> + * ├────────┴───┼────────┴───┘   └─┴────────┘
> + * │<---------->│
> + *   pdx region size
> + *
> + * The offsets to convert from PFN to PDX and from PDX to PFN are stored in a
> + * pair of lookup tables, and the index into those tables to find the offset
> + * for each PFN or PDX is obtained by shifting the to be translated address by
> + * a specific value calculated at boot:
> + *
> + * pdx = pfn - pfn_lookup_table[pfn >> pfn_shift]
> + * pfn = pdx + pdx_lookup_table[pdx >> pdx_shift]

I assume it's intentional (for simplicity) that you omit the index masking
here?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 16:18:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 16:18:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023939.1399998 (Exim 4.92)
	(envelope-from )
	id 1uU6Le-0004wN-6G; Tue, 24 Jun 2025 16:18:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023939.1399998; Tue, 24 Jun 2025 16:18: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 1uU6Le-0004wG-3I; Tue, 24 Jun 2025 16:18:14 +0000
Received: by outflank-mailman (input) for mailman id 1023939;
 Tue, 24 Jun 2025 16:18: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 1uU6Lc-0004vR-8F
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 16:18:12 +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 d2c99d0c-5116-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 18:18:11 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3a54690d369so4834700f8f.3
 for ; Tue, 24 Jun 2025 09:18:11 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-749c882cdc4sm2223168b3a.84.2025.06.24.09.18.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 09:18:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d2c99d0c-5116-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750781891; x=1751386691; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=NaGuyFlzsMP6wYIOsiuUKVKUHnMtmSU1vu0ErJe0fgs=;
        b=CilFBZwWnfPffNSYLJpUG7NCNpXysENUTGU5Nc1vUuZ+YuWVcVJAo+EAlD/qn/6zNB
         6HgUrN4KphTxZrAqBSsObtWeJJkodoEe0/8yreqVD7IzYJ0XKeqpXPq7+zol2cw94D1u
         cubVVaDYYpMUpl8Be7/G5WGIJ6pWX1TD4djzNlmG3GnJmPvsidJxDsPvirX9qguvyDZJ
         tWDt6zFY5OsJsPbg+1JOjI2QWo/ztrNa6ari45E3NUCytrvo+FQeOqSGOUxS1kNt58FJ
         VEgjFwZ2Y8FBc5GOk7FAMzvcu0SVNzsCAtLP4kxmddlVpDpHDnPAMPmhqqIyZf9G0fBN
         9JQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750781891; x=1751386691;
        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=NaGuyFlzsMP6wYIOsiuUKVKUHnMtmSU1vu0ErJe0fgs=;
        b=kw8sRa1jCWEwU297y1d5PWWSfKT+MNascKHxvOIti8J2xQZdntQlvPgE7GgAOpfrXn
         7jW0COBVSRM7YK76d9Ew418UynxqRo+/RT5/riV4HFEUj1kuHVRXw4+DwHoPBlSIj5F6
         ZpTvRzfUFz0RzxcEp3F3ujKpxz/lX8QvpxISWwcpYtZH5KZy7oCnIBh3bgWvDp2a3FHi
         i6qmCTe7lveSHVopldJmLdethVbKMlxnFA/suRfAxAtTMsI6GIEfgRjNqopHOFRYqZNd
         d5ULzprz7aY71mVfRE7wtO/OQOrAZlNe5wCY4F/hjrRgtJjVIZhzIgqk9F7iNih12Wxw
         Gl1Q==
X-Gm-Message-State: AOJu0YzdSqJIPBO2owyOWcqMqXShH3TwA0T6FU0Que+nXHA4hVDBfNPg
	DdjK+bIIwbT6gQv8gt7KxRmfdQ+7m+0hPEWdGPDnyjmTKw+PrtNKufs5ecdzhN8Wu3RFRicOlec
	HNMY=
X-Gm-Gg: ASbGncvqIDo0zzFW9D60j0oEf+pz1+DSb1tS2OK4fR746NmyLVLqw404rp09VveTbUj
	vsVxY2hZYGoFpfEjGZGqyS3eEk3EaPlt55yX/KSyG9QuiIunu7WRXOmaaxlF45yLwX9DK4Q7jXV
	AFNhf64HEhReblupmZG7nh4oiYBKp03UlHPBvdJ4CJ91tDdAU+XQOs67oSmrVmnEX7hs0wAL8Zo
	tz3PJjro/yBdbWF9fm9ii80MCLwytKVZ9pj07JVo7ZbG3lZKm8v4w6gh6nRLTntTzf1j8fIY6sC
	59uw+yN/bp25IsWA8B9c0uElO3nrSX0D59GxJNs5jnUQLy8+ePe/ufdn5Hxvjf1WOX5IXHnM45l
	JhbYNzoZPCBQVjBF4yC1b3j6KAp0RgbdLoeQRDtepUCBZc2a+h8pYhR7b9A==
X-Google-Smtp-Source: AGHT+IGa7r8KeQMGTYbDY/qvyEPZjVgts1kvpzefi93LcqYl6tA+7NuR1x3s/w3XW4z/Ih+SSjS2LA==
X-Received: by 2002:a5d:584c:0:b0:3a4:fa6a:9174 with SMTP id ffacd0b85a97d-3a6d12de83emr13980352f8f.33.1750781891138;
        Tue, 24 Jun 2025 09:18:11 -0700 (PDT)
Message-ID: <6fe8a131-2997-4cde-b030-eb14f63ab065@suse.com>
Date: Tue, 24 Jun 2025 18:18:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] xen/efi: Handle cases where file didn't come from ESP
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 Frediano Ziglio 
Cc: xen-devel@lists.xenproject.org,
 "Daniel P. Smith" 
References: <20250624083157.9334-1-frediano.ziglio@cloud.com>
 <20250624083157.9334-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 24.06.2025 16:35, Marek Marczykowski-Górecki wrote:
> On Tue, Jun 24, 2025 at 03:05:25PM +0100, Frediano Ziglio wrote:
>> OT: the flow of read_file (specifically "what" handling) looks
>> weird... can I change it?
> 
> It tries to avoid duplication of PrintErr calls, while including what
> failed in the error message. Looks like somebody really wanted to avoid
> using goto here...

Yes indeed.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 16:23:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 16:23:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023946.1400007 (Exim 4.92)
	(envelope-from )
	id 1uU6QK-0006fd-M1; Tue, 24 Jun 2025 16:23:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023946.1400007; Tue, 24 Jun 2025 16:23: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 1uU6QK-0006fW-JH; Tue, 24 Jun 2025 16:23:04 +0000
Received: by outflank-mailman (input) for mailman id 1023946;
 Tue, 24 Jun 2025 16:23: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 1uU6QJ-0006fQ-11
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 16:23:03 +0000
Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com
 [2607:f8b0:4864:20::a33])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7e46c7ae-5117-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 18:23:00 +0200 (CEST)
Received: by mail-vk1-xa33.google.com with SMTP id
 71dfb90a1353d-531426c7143so1720706e0c.0
 for ; Tue, 24 Jun 2025 09:22:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7e46c7ae-5117-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750782179; x=1751386979; 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=30GIdBwPje0TxaWLDeGF8emUkBrMEvRfpZXuhgyUSzE=;
        b=bUzUdW+bqwWv6IYMihgfWLKmgWr7kU0QA29mBwaOmihQ1K1jnOgoHgL4CzVb4mdeWP
         1QjMBAyg6yO6cmM/os0182hxTsuaC4ccYYjeQ4I17Eyh77PbA7Cz6skeewPWS26sBppz
         ZSbA7PAuo8EzKYQLZtg8xAf3yzc3zv8vqQcL8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750782179; x=1751386979;
        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=30GIdBwPje0TxaWLDeGF8emUkBrMEvRfpZXuhgyUSzE=;
        b=tZbkKOLGH8ZJrDWTaM33vhhLjj7G5K+MnfJcqXXcb32SA0eseR+9hoZq+enbjmErky
         yO67ChybKeSGMlYtpx7oZSLp90x9O1qE67RgdvW4OGtdyy+BEZL7xC0iGi2ICOzlbcfD
         LIQ2bwoc1AzvY0MXxD5Kb4XYxysYDMombTw3M4cSPdIadx4wvx7kLaFn1neXUChGCv8s
         eHbHFYOTZmGHdS5WaWpT8pg+0LJakr6lDWkPwM46+6p9+2E9M6Gh/CnDRlnePZhclsSs
         p8M9YqzRGcqwrXgg7TsEtgqsi/560W1730bQFTffusDkMG35kds+Hu/yrVtB/3XrUUr4
         YzUA==
X-Forwarded-Encrypted: i=1; AJvYcCUMPSOFE4LcsDF9dDuuMr0+7wPOThptzGK7dK0u5MLr43qkThWc0Cea7IfLMaDdpQGnwSpEF0u4uGo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YykoZsjyQOh9Lk7y4n2rFTVXbBeogyhIn7yHcVQunUojNJ81vTT
	OFEQtQeACkxDstld70WAwAwOSBThW763BZvkRzpHOV7nxLJ95pp4myWsDcfi7+jZh5MjqdU1Y8f
	ySqplH/p+jjvo/6rjV9spWM590YKDmuOl4MItsJjqrg==
X-Gm-Gg: ASbGncvsAldiZUHzMqb5/0tdfL1mKzJe7vJ/GeNR3VXxMbOv+dzPHJMtgc3Fq3dy6f3
	FPH5p3g+s+7NvyzBCRSrdMOFaxBFV0BiIJ5S/+M0DdFhpXDb7K367M1OHp7JcFcenq+KYiTy5ro
	Lx27cBvJuhW0t5M5gaWB7jrIpHVB+XxdLrUOJHYlostkv/Dw==
X-Google-Smtp-Source: AGHT+IHqcXjNKRQ0wZcRpI0UdrrEr+8Z6+Z8cUqyk9Pvx7khNEjPe7B070IiA25pmW65WKU+wF6ULqZNM/Lk6x/qmuI=
X-Received: by 2002:a05:6122:20ac:b0:520:64ea:c479 with SMTP id
 71dfb90a1353d-531ad612168mr9869463e0c.10.1750782178770; Tue, 24 Jun 2025
 09:22:58 -0700 (PDT)
MIME-Version: 1.0
References: <47b7f870-e1d9-44c9-b8ea-5b9028843963@gmail.com>
  <0b43d8e0-7ba6-43e4-9b0a-58c45d222c4a@gmail.com>
 <66FC0F57-1654-40FD-88A9-37A960D37C1F@cloud.com>
In-Reply-To: <66FC0F57-1654-40FD-88A9-37A960D37C1F@cloud.com>
From: Edwin Torok 
Date: Tue, 24 Jun 2025 17:22:47 +0100
X-Gm-Features: AX0GCFuG4uONd59Xd30sSV640vlW-WPYisKk4TA31zGOzPLC-kJHWxpgnBGJICU
Message-ID: 
Subject: Re: xenstore - Suggestion of batching watch events
To: Christian Lindig 
Cc: Andriy Sultanov , =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , 
	xen-devel@lists.xenproject.org, ngoc-tu.dinh@vates.tech, 
	Christian Lindig 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 24, 2025 at 4:51=E2=80=AFPM Christian Lindig
 wrote:
>
>
>
> > On 24 Jun 2025, at 16:43, Andriy Sultanov  wr=
ote:
> >
> > But I think this only covers part of the problem. Looking at the concre=
te case of
> > xenopsd and Windows VMs, xenopsd cares about most of the nodes it recei=
ves
> > watch events from, the issue is that it doesn't know when these are gro=
uped
> > together in one way or another.
>
> Is the common case that a client wants to observe the changes rather than=
 just knowing that a change occurred? If so, it seems transmitting changes =
as part of a watch event (rather than forcing the client to traverse the tr=
ee) would be a better protocol. That would suggest to introduce a new kind =
of watch that reports changes at the end of a transaction. The size of the =
event would depend on the size of the change.

Most of the code in xapi_xenops.ml that deals with watch events wants
to compare the new value with the old, to know whether it needs to
send an update to XAPI.
So yes, including as much information as we can in the watch event
would avoid round-trips (and might also avoid some of the O(N^2)
issues because xenopsd would know exactly what key changed to what
value), for xenopsd's use-case.

The situation may be different for PV device backends/frontends, what
might be useful there are wildcards, e.g.
`/path/to/vif/*/state`, etc. which would also trigger when new devices
appear or old devices disappear.
The tree depth limit already proposed in xenstore.txt could also help
with this (so you can watch for a new device to appear without
constantly watching all its keys), and the driver can then setup
watches just on state (and whatever other fields it wants to watch).

Best regards,
--Edwin

>
> =E2=80=94 C
>
>


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 16:40:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 16:40:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023952.1400019 (Exim 4.92)
	(envelope-from )
	id 1uU6gj-00006X-4H; Tue, 24 Jun 2025 16:40:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023952.1400019; Tue, 24 Jun 2025 16: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 1uU6gi-00006Q-V1; Tue, 24 Jun 2025 16:40:00 +0000
Received: by outflank-mailman (input) for mailman id 1023952;
 Tue, 24 Jun 2025 16:40: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 1uU6gi-00006A-6B
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 16:40:00 +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 de293fa2-5119-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 18:39:59 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-4536b8c183cso315165e9.0
 for ; Tue, 24 Jun 2025 09:39:59 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a6e810caefsm2295472f8f.87.2025.06.24.09.39.57
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 24 Jun 2025 09:39:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: de293fa2-5119-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750783198; x=1751387998; darn=lists.xenproject.org;
        h=content-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=F6JXyUMx3IjQ54X/lCoYWUS3iBYfCqkhLOnaKoIjagI=;
        b=t7DzAA+ZcKtrqS5X1zuCZyD23c2N2WCkq1o4yME6hlampDzGiqGdSgDmKtPzb2yU7r
         8h7xuC8dFxtmvyZzrkELvYVTUO+5VIPFAt9jHDbbi5Ea+6DJFunqVity82Rl2Rkuu5KS
         5ZmkDis16Fyl1hszwD1WK4iCLfRLGD/3t8KEA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750783198; x=1751387998;
        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=F6JXyUMx3IjQ54X/lCoYWUS3iBYfCqkhLOnaKoIjagI=;
        b=HF5VGeUDRGdmq22pTWpvCCHyBZ1DDWN4xLwtWPIedIJxCqzU1+spgO2yF3yT9p0aXg
         Ci8oWvrh4gvATOcZgbTuTvtaFrP/goSqzAcC293NPHJDPujTwsmYvdjObq9SpdUJFSJZ
         m50eBztkgPIX1B61bJWa6Zsg3GbOo2x4uWoyNnopZWglV9dNYC+DuuY4ucDCFfBLKFPP
         XNsUN0sUcXYmd06qmN+EL7rOjz80DzVl5Pv7FEUEI/nbqgUSD8nv2eQCy8Ff2UfE+Rbr
         IVlPBzULey/yFIbAmnAbmk1O+WSoda5OlI2pkSO2zbZzvOFeEezRar2M/UaJss7LFL06
         xJCg==
X-Gm-Message-State: AOJu0YwSlFXiYwK1JS8QF2FhHDuSExvIgReaAJ20NRfSWog+F2Q4j89z
	TtG++7Z3GLbreaMIlL/Z791khjc/931OiAKA3wgFI8LmYwx97jGOtyJdjrlP+XKs1aRLnOaUZc7
	j6msWxGBPoA==
X-Gm-Gg: ASbGnctS1vUBTGoeWeZk1a0ehIXANvnUSuOXYYaU2zUwZL2ostZLR0JKQz6WxJPXqvr
	JE1iTdC+fWtWSqWtmm9f9G8kdY+wYabwuOtQzx02j+CDqr6jI3EkkSyP63SxaI58zzlTWwaKH2H
	gTcOZnPcqgLLp15RMG9hlG93kPnPaFuJXfBTCsiZpkopdSEST93v5PwTdYwTuvt+kq1Yfr5uxB7
	hYrj/2p8uURsW8puOqoN+83pKKhXA2Rb6jZaqVwy0Yq4WVjMXp05jwbMgsCbrU15u09R08v6W9K
	zUlHeXSK4FGs6JofajCyGTNwhZpD98EId/M1kKPhkF485Mw2lvVroI1eo3h6MIcL/96w4sF38TZ
	1unRwnwwCroq558q5NrfgouEUHGwf1fKxPAc=
X-Google-Smtp-Source: AGHT+IFQPLT83iQ184sq26JwFUC7OyLxsojaK3bBbVO5G1nNWggAhvjJkebTS7WzIykBYxvVMQQYbQ==
X-Received: by 2002:a05:600c:a107:b0:453:9b3:5b58 with SMTP id 5b1f17b1804b1-4537b73816bmr35245505e9.4.1750783198505;
        Tue, 24 Jun 2025 09:39:58 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH 1/4] x86/idle: Move monitor()/mwait() wrappers into cpu-idle.c
Date: Tue, 24 Jun 2025 17:39:48 +0100
Message-Id: <20250624163951.301743-2-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250624163951.301743-1-andrew.cooper3@citrix.com>
References: <20250624163951.301743-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

They're not used by any other translation unit, so shouldn't live in
asm/processor.h, which is included almost everywhere.

Our new toolchain baseline knows the MONITOR/MWAIT instructions, so use them
directly rather than using raw hex.

Change the hint/extention parameters from long to int.  They're specified to
remain 32bit operands even 64-bit mode.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
---
 xen/arch/x86/acpi/cpu_idle.c         | 21 +++++++++++++++++----
 xen/arch/x86/include/asm/processor.h | 17 -----------------
 2 files changed, 17 insertions(+), 21 deletions(-)

diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/acpi/cpu_idle.c
index 1dbf15b01ed7..40af42a18fb8 100644
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -60,6 +60,19 @@
 
 /*#define DEBUG_PM_CX*/
 
+static always_inline void monitor(
+    const void *addr, unsigned int ecx, unsigned int edx)
+{
+    asm volatile ( "monitor"
+                   :: "a" (addr), "c" (ecx), "d" (edx) );
+}
+
+static always_inline void mwait(unsigned int eax, unsigned int ecx)
+{
+    asm volatile ( "mwait"
+                   :: "a" (eax), "c" (ecx) );
+}
+
 #define GET_HW_RES_IN_NS(msr, val) \
     do { rdmsrl(msr, val); val = tsc_ticks2ns(val); } while( 0 )
 #define GET_MC6_RES(val)  GET_HW_RES_IN_NS(0x664, val)
@@ -470,7 +483,7 @@ void mwait_idle_with_hints(unsigned int eax, unsigned int ecx)
         mb();
     }
 
-    __monitor(monitor_addr, 0, 0);
+    monitor(monitor_addr, 0, 0);
     smp_mb();
 
     /*
@@ -484,7 +497,7 @@ void mwait_idle_with_hints(unsigned int eax, unsigned int ecx)
         cpumask_set_cpu(cpu, &cpuidle_mwait_flags);
 
         spec_ctrl_enter_idle(info);
-        __mwait(eax, ecx);
+        mwait(eax, ecx);
         spec_ctrl_exit_idle(info);
 
         cpumask_clear_cpu(cpu, &cpuidle_mwait_flags);
@@ -915,9 +928,9 @@ void cf_check acpi_dead_idle(void)
              */
             mb();
             clflush(mwait_ptr);
-            __monitor(mwait_ptr, 0, 0);
+            monitor(mwait_ptr, 0, 0);
             mb();
-            __mwait(cx->address, 0);
+            mwait(cx->address, 0);
         }
     }
     else if ( (current_cpu_data.x86_vendor &
diff --git a/xen/arch/x86/include/asm/processor.h b/xen/arch/x86/include/asm/processor.h
index 96b9bf5f5edb..04824c3633cf 100644
--- a/xen/arch/x86/include/asm/processor.h
+++ b/xen/arch/x86/include/asm/processor.h
@@ -315,23 +315,6 @@ static always_inline void set_in_cr4 (unsigned long mask)
         cr4_pv32_mask |= (mask & XEN_CR4_PV32_BITS);
 }
 
-static always_inline void __monitor(const void *eax, unsigned long ecx,
-                                    unsigned long edx)
-{
-    /* "monitor %eax,%ecx,%edx;" */
-    asm volatile (
-        ".byte 0x0f,0x01,0xc8;"
-        : : "a" (eax), "c" (ecx), "d"(edx) );
-}
-
-static always_inline void __mwait(unsigned long eax, unsigned long ecx)
-{
-    /* "mwait %eax,%ecx;" */
-    asm volatile (
-        ".byte 0x0f,0x01,0xc9;"
-        : : "a" (eax), "c" (ecx) );
-}
-
 #define IOBMP_BYTES             8192
 #define IOBMP_INVALID_OFFSET    0x8000
 
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 16:40:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 16:40:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023955.1400048 (Exim 4.92)
	(envelope-from )
	id 1uU6gl-00018W-UK; Tue, 24 Jun 2025 16:40:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023955.1400048; Tue, 24 Jun 2025 16:40: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 1uU6gl-00017o-Qs; Tue, 24 Jun 2025 16:40:03 +0000
Received: by outflank-mailman (input) for mailman id 1023955;
 Tue, 24 Jun 2025 16:40: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 1uU6gj-00006A-S0
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 16:40:01 +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 df0343e9-5119-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 18:40:00 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3a4e742dc97so40926f8f.0
 for ; Tue, 24 Jun 2025 09:40:00 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a6e810caefsm2295472f8f.87.2025.06.24.09.39.59
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 24 Jun 2025 09:39:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: df0343e9-5119-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750783200; x=1751388000; darn=lists.xenproject.org;
        h=content-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=G/Exz2bivC2q38JdIgYrIA5jvOxR/miT030/PESaUcw=;
        b=gm6FLfdU+BxicPVG9Gvx41u+JmUdVP0W4eEaDDIlLr2+uvQf37l4GL0gweL9kWkDP/
         lXZKcyivk4CbMPOVmLS0Mmc3TEnhAqbScJHdtnTKONcmJpS9HsQBf9Emft0znJFDqelW
         0j2s0Qcrq28iOoMeKSBjY/fCeQjSdtlE/Fzcw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750783200; x=1751388000;
        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=G/Exz2bivC2q38JdIgYrIA5jvOxR/miT030/PESaUcw=;
        b=uscgkfJKa1KtlupqYRykESt/JoNhsKkd2JJoLtgp+EuIL79azjEcwYk07tuF7ZHRMP
         3l4HcvCi0hWY1hne+RhfgQioug/dZONgWiE8fwXJhYQJ4a69KHd4GB5ujLObvVxAex7E
         ucKgl5t2wEdRGpejYzSpXf4Ion693HmEgRkRDg/67dQBb+UkrAANsUCdX4Cdr4Rmh5pd
         0xtiLU6sl4zPngC45kPvxyeSjgbBo+3NBs3H2pQatleP8ZPlSIhMWA4VcL9m39ePn1qO
         FNALLlQZQqojVWaGx88xZOJF2hP/PQCWVGOtGDWPZrhhLwgZswLqGqnOiJzbcVDhIjF9
         vPuQ==
X-Gm-Message-State: AOJu0Yy3lHpduld9qRWJREjHfpxpNNW+FZQW+XEn+3zO7+2Eq8CCDp3T
	bom7UWGXNvPoD+nXOi7DR8Umep7AtZRQ5DeiAA0TUXrGU7JNU+Q/C996rFQ/50smVgYaRz52GRW
	0O3GyaaDyCA==
X-Gm-Gg: ASbGncsiwX2wibqH1GRtBaL0Zt+LUkvyXLgCVJ3S3Y24SgAj8BMFOMfEuYjROUIfcv/
	yj77PCilvmU1qesJwfzIH+FapCILgi9V0K9lLISAX1t5Ftlt0nrG3hp3WMOLdgPhNDK7ZHkvmJx
	4wnQ4bf+5X7ew128nbH40ST+9GSZYN5n/nGVMvAeuIQxfS97wCvM+umSpp+kH0mFb1mj9sFTuij
	vbfwpx6asbqwK0cocUL8KEy4H3skWDHWnIoYHZHMRChPIRITtm9CJQRk7bOZzQKvhC8kE9OYLCr
	jmz38pdiyzmWYQ/ngrfJXVWkEoT8YuC5xJ7gYPhA8vkwDL9TkBJHlFeknDqv4347s9rYrkT8UUW
	ay78JLSoZmZw7mLAbyAKRr7s3cLJL0ncgfGQ=
X-Google-Smtp-Source: AGHT+IEWwnwjZMnetPkRyNK2jxOgOVLQiDgmZsM7QZSOCXMVV5F2wHw2iIdEDAE/G/vmiSZefTPDpA==
X-Received: by 2002:a05:6000:2882:b0:3a5:23c6:eeee with SMTP id ffacd0b85a97d-3a6e71ddb32mr4541424f8f.21.1750783199904;
        Tue, 24 Jun 2025 09:39:59 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH 3/4] Revert part of "x86/mwait-idle: disable IBRS during long idle"
Date: Tue, 24 Jun 2025 17:39:50 +0100
Message-Id: <20250624163951.301743-4-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250624163951.301743-1-andrew.cooper3@citrix.com>
References: <20250624163951.301743-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Most of the patch (handling of CPUIDLE_FLAG_IBRS) is fine, but the
adjustements to mwait_idle() are not.

spec_ctrl_{enter,exit}_idle() do more than just alter MSR_SPEC_CTRL.IBRS.  The
VERW and RSB stuff are **unsafe** to omit.

The only reason this doesn't need an XSA is because no changes were made to
the lower level mwait_idle_with_hints(), and thus it remained properly
protected.

I.e. This change only served to double the expensive operations in the case it
was trying to optimise.

I have an idea of how to plumb this more nicely, but it requires larger
changes to legacy IBRS handling to not make spec_ctrl_enter_idle() vulnerable
in other ways.  In the short term, simply take out the perf hit.

Fixes: 08acdf9a2615 ("x86/mwait-idle: disable IBRS during long idle")
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
---
 xen/arch/x86/cpu/mwait-idle.c | 12 ++----------
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/cpu/mwait-idle.c b/xen/arch/x86/cpu/mwait-idle.c
index 9c16cc166a14..5c16f5ad3a82 100644
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -875,7 +875,6 @@ static const struct cpuidle_state snr_cstates[] = {
 static void cf_check mwait_idle(void)
 {
 	unsigned int cpu = smp_processor_id();
-	struct cpu_info *info = get_cpu_info();
 	struct acpi_processor_power *power = processor_powers[cpu];
 	struct acpi_processor_cx *cx = NULL;
 	unsigned int next_state;
@@ -902,6 +901,8 @@ static void cf_check mwait_idle(void)
 			pm_idle_save();
 		else
 		{
+			struct cpu_info *info = get_cpu_info();
+
 			spec_ctrl_enter_idle(info);
 			safe_halt();
 			spec_ctrl_exit_idle(info);
@@ -928,11 +929,6 @@ static void cf_check mwait_idle(void)
 	if ((cx->type >= 3) && errata_c6_workaround())
 		cx = power->safe_state;
 
-	if (cx->ibrs_disable) {
-		ASSERT(!cx->irq_enable_early);
-		spec_ctrl_enter_idle(info);
-	}
-
 #if 0 /* XXX Can we/do we need to do something similar on Xen? */
 	/*
 	 * leave_mm() to avoid costly and often unnecessary wakeups
@@ -964,10 +960,6 @@ static void cf_check mwait_idle(void)
 
 	/* Now back in C0. */
 	update_idle_stats(power, cx, before, after);
-
-	if (cx->ibrs_disable)
-		spec_ctrl_exit_idle(info);
-
 	local_irq_enable();
 
 	TRACE_TIME(TRC_PM_IDLE_EXIT, cx->type, after,
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 16:40:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 16:40:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023956.1400059 (Exim 4.92)
	(envelope-from )
	id 1uU6gn-0001XF-7I; Tue, 24 Jun 2025 16:40:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023956.1400059; Tue, 24 Jun 2025 16:40:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uU6gn-0001WN-1e; Tue, 24 Jun 2025 16:40:05 +0000
Received: by outflank-mailman (input) for mailman id 1023956;
 Tue, 24 Jun 2025 16:40: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 1uU6gk-00006A-S2
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 16:40:02 +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 df8f0790-5119-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 18:40:01 +0200 (CEST)
Received: by mail-wm1-x344.google.com with SMTP id
 5b1f17b1804b1-442fda876a6so50634125e9.0
 for ; Tue, 24 Jun 2025 09:40:01 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a6e810caefsm2295472f8f.87.2025.06.24.09.40.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 24 Jun 2025 09:40:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: df8f0790-5119-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750783201; x=1751388001; darn=lists.xenproject.org;
        h=content-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=L8zvOhZvXOvF3gCKvTIhnAyw9lxFL7/6V29vjtTjdtI=;
        b=N/OXEHiZUzm8mnLPePAe2fItD/JrEMudJipQWS+SQsdXbgHLEstIrc9oKw513EtgHk
         lZ09fYqPncpgaDRQDFoFTvg8qbbRrlvmB4a4+88uTLFlXMxl8zM8LJRCEUXcSYK6Eatv
         nJHnuGJU9bFADOkZskNBVKiI4xC6PiGP3TdpQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750783201; x=1751388001;
        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=L8zvOhZvXOvF3gCKvTIhnAyw9lxFL7/6V29vjtTjdtI=;
        b=ad2TqltpNfZPXF+lA9hFBoi5AEbFTeMr7oK7jeVyikXnkSrNRFhqgMkxSL45wUAtDq
         JCHsoCQjXYAfmk4YIB47xBsfAhZFwLTyUM74rCO6KB3mmAKvw5IVyJmF/sKy7TNfEJij
         bVQzBTON166gSOljyoFCbNYpVYXyVoGWg/RrEakJnbgwhcMbAJbIRo3i0WEp5/eRxdYB
         VxYLA6ymqyfCNItWRZcAs91Q5C7CF/dnsKoxwjEjcTnEC0U7S+RyNlYQ8HKl5EHkb/a9
         OkKcMwfvZGtsaenhXXX0pMikKaX7KwcCGjbofv4ZYFTP3Ut29nLhU3oe5fqPhYQvGa+C
         eKNw==
X-Gm-Message-State: AOJu0YxP2zSXULe+BfdPEujTzhTlAuSnfHjTc42ujUnB9T5JxiIb3UGn
	k3q83w47yjDj1v/pgqm5D7cDpEzuncjcLfHN5l3qm6YHCurLGX9+jgH2baPYZTofAS8lSZPobwZ
	Q5QJnWYpFIKwo
X-Gm-Gg: ASbGnctdf53n/O+5vHFyNznEuZ15x77444QHYwK1IcR3tBx9L6FLPE0cgXHfixlIAQd
	dH3zp2NpWOVuqckguQ8clil2pb1Wxf832bOeQr6QXdS/tyRfSQbWlghFYInqqjcugUDWeMlbCR+
	crmfgqgQmQGOEmeI9RG45/SoYOxn1GCTNhgxWJtbN5ujlAUJSu463WmTLLRh4dLQJXMuI7B89nk
	Rt7+ApMMqo76DGUFKYeVc/ZyEo5tyfCepdt1e8brdF0sUUawEcub2BbKP+G3hXHEpDsDEu7Ek7A
	fXIz0bqSYZitqi0LV1OnJ/CZ6sfAv0dzk7+mV2P7Gr127c+8BeLORhyCMiSHFw1lhRcp1j0llZC
	ej4Ku/vjj5F3/p7ZPpDyBsJlCa2DViS4aw04=
X-Google-Smtp-Source: AGHT+IGEh75w0SXxePGB41NK4Hasuo5PBPHwu9ZhzWnvdRAaOu+/JFoOUgUI+oNuE7C60ofh3ArccA==
X-Received: by 2002:a05:600c:3b84:b0:442:ccfa:1461 with SMTP id 5b1f17b1804b1-453657bf26bmr155776385e9.13.1750783200779;
        Tue, 24 Jun 2025 09:40:00 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH 4/4] x86/idle: Misc cleanup
Date: Tue, 24 Jun 2025 17:39:51 +0100
Message-Id: <20250624163951.301743-5-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250624163951.301743-1-andrew.cooper3@citrix.com>
References: <20250624163951.301743-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Sort includes, and drop trailing whitespace.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
---
 xen/arch/x86/acpi/cpu_idle.c | 51 ++++++++++++++++++------------------
 1 file changed, 25 insertions(+), 26 deletions(-)

diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/acpi/cpu_idle.c
index e9493f7f577f..6c3a10e6fb4e 100644
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -1,6 +1,6 @@
 /*
- * cpu_idle - xen idle state module derived from Linux 
- *            drivers/acpi/processor_idle.c & 
+ * cpu_idle - xen idle state module derived from Linux
+ *            drivers/acpi/processor_idle.c &
  *            arch/x86/kernel/acpi/cstate.c
  *
  *  Copyright (C) 2001, 2002 Andy Grover 
@@ -30,34 +30,34 @@
  * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  */
 
-#include 
-#include 
-#include 
 #include 
-#include 
+#include 
+#include 
 #include 
+#include 
 #include 
+#include 
+#include 
 #include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-#include 
-#include 
 #include 
+#include 
+#include 
 #include 
-#include 
-#include 
+#include 
+
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
-#include 
-#include 
+#include 
 #include 
 
+#include 
+#include 
+
 /*#define DEBUG_PM_CX*/
 
 static always_inline void monitor(
@@ -791,7 +791,7 @@ static void cf_check acpi_processor_idle(void)
 
     case ACPI_STATE_C3:
         /*
-         * Before invoking C3, be aware that TSC/APIC timer may be 
+         * Before invoking C3, be aware that TSC/APIC timer may be
          * stopped by H/W. Without carefully handling of TSC/APIC stop issues,
          * deep C state can't work correctly.
          */
@@ -1082,7 +1082,7 @@ static int check_cx(struct acpi_processor_power *power, xen_processor_cx_t *cx)
         break;
 
     case ACPI_ADR_SPACE_FIXED_HARDWARE:
-        if ( cx->reg.bit_width != VENDOR_INTEL || 
+        if ( cx->reg.bit_width != VENDOR_INTEL ||
              cx->reg.bit_offset != NATIVE_CSTATE_BEYOND_HALT )
             return -EINVAL;
 
@@ -1269,14 +1269,14 @@ static void print_cx_pminfo(uint32_t cpu, struct xen_processor_power *power)
            "\t       pwr_setup_done[%d], bm_rld_set[%d]\n",
            power->flags.bm_control, power->flags.bm_check, power->flags.has_cst,
            power->flags.power_setup_done, power->flags.bm_rld_set);
-    
+
     states = power->states;
-    
+
     for ( i = 0; i < power->count; i++ )
     {
         if ( unlikely(copy_from_guest_offset(&state, states, i, 1)) )
             return;
-        
+
         printk("\tstates[%d]:\n", i);
         printk("\t\treg.space_id = %#x\n", state.reg.space_id);
         printk("\t\treg.bit_width = %#x\n", state.reg.bit_width);
@@ -1289,7 +1289,7 @@ static void print_cx_pminfo(uint32_t cpu, struct xen_processor_power *power)
 
         csd = state.dp;
         printk("\t\tdp(@0x%p)\n", csd.p);
-        
+
         if ( csd.p != NULL )
         {
             if ( unlikely(copy_from_guest(&dp, csd, 1)) )
@@ -1388,7 +1388,7 @@ long set_cx_pminfo(uint32_t acpi_id, struct xen_processor_power *power)
 
         dead_idle = acpi_dead_idle;
     }
- 
+
     return 0;
 }
 
@@ -1676,4 +1676,3 @@ static int __init cf_check cpuidle_presmp_init(void)
     return 0;
 }
 presmp_initcall(cpuidle_presmp_init);
-
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 16:40:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 16:40:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023953.1400024 (Exim 4.92)
	(envelope-from )
	id 1uU6gj-0000BF-Cw; Tue, 24 Jun 2025 16:40:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023953.1400024; Tue, 24 Jun 2025 16: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 1uU6gj-00008v-5r; Tue, 24 Jun 2025 16:40:01 +0000
Received: by outflank-mailman (input) for mailman id 1023953;
 Tue, 24 Jun 2025 16:40: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 1uU6gi-00006F-K6
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 16:40:00 +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 ddaf4de0-5119-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 18:39:58 +0200 (CEST)
Received: by mail-wr1-x442.google.com with SMTP id
 ffacd0b85a97d-3a51481a598so2883247f8f.3
 for ; Tue, 24 Jun 2025 09:39:58 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a6e810caefsm2295472f8f.87.2025.06.24.09.39.57
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 24 Jun 2025 09:39:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ddaf4de0-5119-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750783198; x=1751387998; 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=uYwnFK0C0cMRTnZqft/FNMzoDb8C6vWJ4xwQUmz06WM=;
        b=JkaFHxHDk+oQ1ZxwWMLtu4jXa2QdWxga5nwyuvXOS6IKYWVyYODVjXb4IAJGUNOV13
         C7gOIinfu6cDUDnIZIN2AxZZmSSE6MRokTZvNoFVLaYmd3WTeluEBsON7UhxlKFBKLNN
         4/ED0evzH4PatJOL64ggLnQjXffX9qefCfFfg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750783198; x=1751387998;
        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=uYwnFK0C0cMRTnZqft/FNMzoDb8C6vWJ4xwQUmz06WM=;
        b=wU8dpEbAYVd+LqMovT/cObMjyyIdCkpRwOjXtX4EtuYX4u6s9tiRLTCXKeADqNP/kz
         KxjNOdffW4F6EDD+mX/mPHxwLi6cfPhc+BB9dNDhuJoAK0bLZfelZz6j6huqMjW5LgJY
         m+Z2OiwkLM2PHUv/nNOwyOx/ZVjuyp6IfYx/4Bj7Yk9GXIivscgZkdWtj6K1pYZfV3sD
         EWJ1yuCBbkDqWj07DCrwXohdLEd1zYv2jYtVev+4lGD10igALaiV2xktwJvnrWxixrdC
         57kYgPnP9eER94FuO4YzUk2eHrcdykoVM65VABpiUP+17AhwoOGvg5aEn0hC7VwLvCmo
         GsVA==
X-Gm-Message-State: AOJu0YwQDTva7yWl9D9W754mnqNDVC/EWMfEll7zOCElOp11yQqlzIiu
	3+PIqfaHVLHXNiEGLmi820QRf0KcmwRfBoQsY3t8UHRf+HoFbBTJ2vUMPb8UqAskxVVGlIrly4S
	4bx7HO8lSQZib
X-Gm-Gg: ASbGncvu20j/1VSUvftdrXVnkd3fOeVZjASGsOMZm8wWBxY8qM3n/jXFid3GfmC4/bN
	tIn355dqrlwVyeFh6JqmqH3XMafmhGlCW+qObiQefJuc3St+ly5c0vt7Cdwo6PJ6+iJQgR9dar0
	V6/PD7DflduDp+7krGVwX93iiuE0iqIxDlAK+IPS6Hp0BOg23JAdgKDnnpmgGasOB3IxyibYjV9
	KJyJ8Yw29fe1j5alzrJoGlURtqzWysn6qosUUuhGaS9y0CyKL4ZPEp35YWWBhFR9NKhl5z+lOtY
	+S94qjYdaAB340TPj0XJYgwsKfC8DkhQ0OtEisGXBGURt6+bNxoJsI6ROPigmIAMWGu36kSlQUT
	R1agspfEt0PWF0uuOkiQ41c3PSYOUiDIKQ70=
X-Google-Smtp-Source: AGHT+IHiMcqReeXuTvZrLXu14uY6Rc20uOTaaUVUUM+BzmlGvgR2/Hwks1nJqqegnC27WWyS2OB/Vw==
X-Received: by 2002:adf:b605:0:b0:3a5:3930:f57 with SMTP id ffacd0b85a97d-3a6d13160c0mr12867062f8f.51.1750783197737;
        Tue, 24 Jun 2025 09:39:57 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH 0/4] x86/idle: Fixes and cleanup
Date: Tue, 24 Jun 2025 17:39:47 +0100
Message-Id: <20250624163951.301743-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

Assorted fixes for mwait/monitor that I've had sitting around too long.

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

Andrew Cooper (4):
  x86/idle: Move monitor()/mwait() wrappers into cpu-idle.c
  x86/idle: Remove MFENCEs for CLFLUSH_MONITOR
  Revert part of "x86/mwait-idle: disable IBRS during long idle"
  x86/idle: Misc cleanup

 xen/arch/x86/acpi/cpu_idle.c           | 94 ++++++++++++--------------
 xen/arch/x86/cpu/intel.c               |  3 +-
 xen/arch/x86/cpu/mwait-idle.c          | 12 +---
 xen/arch/x86/include/asm/cpufeatures.h |  3 +-
 xen/arch/x86/include/asm/processor.h   | 17 -----
 5 files changed, 51 insertions(+), 78 deletions(-)


base-commit: cc7394164633e75fb61d52565f75271e0b7f1236
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 16:40:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 16:40:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023954.1400038 (Exim 4.92)
	(envelope-from )
	id 1uU6gk-0000jS-Ie; Tue, 24 Jun 2025 16:40:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023954.1400038; Tue, 24 Jun 2025 16:40:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uU6gk-0000hQ-E5; Tue, 24 Jun 2025 16:40:02 +0000
Received: by outflank-mailman (input) for mailman id 1023954;
 Tue, 24 Jun 2025 16:40: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 1uU6gi-00006A-Rw
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 16:40:00 +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 deada2f6-5119-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 18:40:00 +0200 (CEST)
Received: by mail-wr1-x443.google.com with SMTP id
 ffacd0b85a97d-3a4f379662cso4592513f8f.0
 for ; Tue, 24 Jun 2025 09:40:00 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a6e810caefsm2295472f8f.87.2025.06.24.09.39.58
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 24 Jun 2025 09:39:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: deada2f6-5119-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750783199; x=1751387999; darn=lists.xenproject.org;
        h=content-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=YY0iNm4JGds+kin8aZfprVF5SX7hTwH9tOxocIXXJ6g=;
        b=onG1AVWLY+vhlyaFkWI9HV7F7lNEopuMzpCDsB4nhCvsDSCLi0XV5wDIxUUQGAGoH4
         5oONiXXq8kDrNNq8W7RlDO1yrlGM6zlFxV+hrZuFujtXo+R1FYQof/wSnVyqE3b9tPTZ
         XDU/rDMk5PJcaXpkVan2+EST2t/Tq9QHjF2b0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750783199; x=1751387999;
        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=YY0iNm4JGds+kin8aZfprVF5SX7hTwH9tOxocIXXJ6g=;
        b=s5e9RCkZFnpomr7JmJyK8qqxNrPvYnM4zGjM0cbCIxvstxjniPtpWzduMCNHoPl1vd
         Zm+OIpVIiBvKd7ijkRqvua8GNKjlQAFjPAzV22yZsZhCR/cKezi5YHcJI2nIqu24blYe
         QS5Vtl4hi7vy1Y1tANFQ1K3K0jYpAi/wRacFsrqKFatJnZUrHMppdf3AiqwEX+CDRRFs
         X+caGT+87+n5f9To85lX0pLr2zyytjzVR2W0sFOUj5igPBtMyx6c5IqG6DWgBuBpB/y3
         mWEwTGKiISfCwpyBfLsENq3vP8MEvMTVKsv9kiNdp7enOFY56o6e06QP8R4NVGuTK9s4
         SBuw==
X-Gm-Message-State: AOJu0Yxy7JTT+m2IeCp5bG5IiXwpoTPwh00L4msMXDVVIV6NDdwgyxv+
	7LyRSt3S+/OFuFvYtfRq0LzrwmSUaUnEKZeOKniKuA7nhHh2wKKG2xXGVm+bbvbNrU3zfcJsA3E
	EmYhQ+s0S+tTH
X-Gm-Gg: ASbGnctHIBL5GaecG0AEjmF8Zexv/MZvis4lOx4lNMz8nwpNYns+rsqt6UlICIeRIIo
	eqaUyFQ9bN6MSa+2cQAGpJKCPTCt3Ld0ial+8jh75/ZY9tXEt5RO8ncRE6i7NoVO5WrAGRMVwkp
	JtG3ZSf6PZqN00ye7+0UYrdwtC2BWDHH0D0PrK3ne+Q1GDixBO5RvhCduD2qF7Up7EiPnmS8HsH
	q71fH3zybgEuGSqf78jkJK0hMX2oWbAoLhrEcQCwKEUDqrUJ4lzRIw15sKXqKd1pMWp8GuUkrTu
	Awe04xr5Bkdbw9U24LSrbAWM7p9GvIHEYKmwmY2jiq8fU/EcYFbwMrHk1djBYKUn8R13EhYFOuq
	gc8s4uCxE/w9Be8glfVdt48B+qUCkdrn95uyOVImCljsUIw==
X-Google-Smtp-Source: AGHT+IHMBKXngsA9cu19BlMGLWeCIFT1NTU75mT8aDGPfmHjn9bd+SvP254RUlOgN4/hfW0Vr8ZBPQ==
X-Received: by 2002:a05:6000:230b:b0:3a5:8a68:b823 with SMTP id ffacd0b85a97d-3a6d12af83bmr12768448f8f.23.1750783199289;
        Tue, 24 Jun 2025 09:39:59 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH 2/4] x86/idle: Remove MFENCEs for CLFLUSH_MONITOR
Date: Tue, 24 Jun 2025 17:39:49 +0100
Message-Id: <20250624163951.301743-3-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250624163951.301743-1-andrew.cooper3@citrix.com>
References: <20250624163951.301743-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Commit 48d32458bcd4 ("x86, idle: add barriers to CLFLUSH workaround") was
inherited from Linux and added MFENCEs around the AAI65 errata fix.

The SDM now states:

  Executions of the CLFLUSH instruction are ordered with respect to each
  other and with respect to writes, locked read-modify-write instructions,
  and fence instructions[1].

with footnote 1 reading:

  Earlier versions of this manual specified that executions of the CLFLUSH
  instruction were ordered only by the MFENCE instruction.  All processors
  implementing the CLFLUSH instruction also order it relative to the other
  operations enumerated above.

I.e. the MFENCEs came about because of an incorrect statement in the SDM.

The Spec Update (no longer available on Intel's website) simply says "issue a
CLFLUSH", with no mention of MFENCEs.

As this erratum is specific to Intel, it's fine to remove the the MFENCEs; AMD
CPUs of a similar vintage do port otherwise-unordered CLFLUSHs.

Move the feature bit into the BUG range (rather than FEATURE), and move the
workaround into monitor() itself.

The erratum check itself must use setup_force_cpu_cap().  It needs activating
if any CPU needs it, not if all of them need it.

Fixes: 48d32458bcd4 ("x86, idle: add barriers to CLFLUSH workaround")
Fixes: 96d1b237ae9b ("x86/Intel: work around Xeon 7400 series erratum AAI65")
Link: https://web.archive.org/web/20090219054841/http://download.intel.com/design/xeon/specupdt/32033601.pdf
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 

https://git.kernel.org/linus/1f13c60d84e880df6698441026e64f84c7110c49 is my
equivalent patch to Linux.
---
 xen/arch/x86/acpi/cpu_idle.c           | 22 +++-------------------
 xen/arch/x86/cpu/intel.c               |  3 ++-
 xen/arch/x86/include/asm/cpufeatures.h |  3 ++-
 3 files changed, 7 insertions(+), 21 deletions(-)

diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/acpi/cpu_idle.c
index 40af42a18fb8..e9493f7f577f 100644
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -63,6 +63,9 @@
 static always_inline void monitor(
     const void *addr, unsigned int ecx, unsigned int edx)
 {
+    alternative_input("", "clflush (%[addr])", X86_BUG_CLFLUSH_MONITOR,
+                      [addr] "a" (addr));
+
     asm volatile ( "monitor"
                    :: "a" (addr), "c" (ecx), "d" (edx) );
 }
@@ -476,13 +479,6 @@ void mwait_idle_with_hints(unsigned int eax, unsigned int ecx)
     s_time_t expires = per_cpu(timer_deadline, cpu);
     const void *monitor_addr = &mwait_wakeup(cpu);
 
-    if ( boot_cpu_has(X86_FEATURE_CLFLUSH_MONITOR) )
-    {
-        mb();
-        clflush(monitor_addr);
-        mb();
-    }
-
     monitor(monitor_addr, 0, 0);
     smp_mb();
 
@@ -917,19 +913,7 @@ void cf_check acpi_dead_idle(void)
 
         while ( 1 )
         {
-            /*
-             * 1. The CLFLUSH is a workaround for erratum AAI65 for
-             * the Xeon 7400 series.  
-             * 2. The WBINVD is insufficient due to the spurious-wakeup
-             * case where we return around the loop.
-             * 3. Unlike wbinvd, clflush is a light weight but not serializing 
-             * instruction, hence memory fence is necessary to make sure all 
-             * load/store visible before flush cache line.
-             */
-            mb();
-            clflush(mwait_ptr);
             monitor(mwait_ptr, 0, 0);
-            mb();
             mwait(cx->address, 0);
         }
     }
diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c
index ef9368167a0d..5215b5405c76 100644
--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -446,6 +446,7 @@ static void __init probe_mwait_errata(void)
  *
  * Xeon 7400 erratum AAI65 (and further newer Xeons)
  * MONITOR/MWAIT may have excessive false wakeups
+ * https://web.archive.org/web/20090219054841/http://download.intel.com/design/xeon/specupdt/32033601.pdf
  */
 static void Intel_errata_workarounds(struct cpuinfo_x86 *c)
 {
@@ -463,7 +464,7 @@ static void Intel_errata_workarounds(struct cpuinfo_x86 *c)
 
 	if (c->x86 == 6 && cpu_has_clflush &&
 	    (c->x86_model == 29 || c->x86_model == 46 || c->x86_model == 47))
-		__set_bit(X86_FEATURE_CLFLUSH_MONITOR, c->x86_capability);
+		setup_force_cpu_cap(X86_BUG_CLFLUSH_MONITOR);
 
 	probe_c3_errata(c);
 	if (system_state < SYS_STATE_smp_boot)
diff --git a/xen/arch/x86/include/asm/cpufeatures.h b/xen/arch/x86/include/asm/cpufeatures.h
index 9e3ed21c026d..84c93292c80c 100644
--- a/xen/arch/x86/include/asm/cpufeatures.h
+++ b/xen/arch/x86/include/asm/cpufeatures.h
@@ -19,7 +19,7 @@ XEN_CPUFEATURE(ARCH_PERFMON,      X86_SYNTH( 3)) /* Intel Architectural PerfMon
 XEN_CPUFEATURE(TSC_RELIABLE,      X86_SYNTH( 4)) /* TSC is known to be reliable */
 XEN_CPUFEATURE(XTOPOLOGY,         X86_SYNTH( 5)) /* cpu topology enum extensions */
 XEN_CPUFEATURE(CPUID_FAULTING,    X86_SYNTH( 6)) /* cpuid faulting */
-XEN_CPUFEATURE(CLFLUSH_MONITOR,   X86_SYNTH( 7)) /* clflush reqd with monitor */
+/* Bit 7 unused */
 XEN_CPUFEATURE(APERFMPERF,        X86_SYNTH( 8)) /* APERFMPERF */
 XEN_CPUFEATURE(MFENCE_RDTSC,      X86_SYNTH( 9)) /* MFENCE synchronizes RDTSC */
 XEN_CPUFEATURE(XEN_SMEP,          X86_SYNTH(10)) /* SMEP gets used by Xen itself */
@@ -52,6 +52,7 @@ XEN_CPUFEATURE(USE_VMCALL,        X86_SYNTH(30)) /* Use VMCALL instead of VMMCAL
 #define X86_BUG_NULL_SEG          X86_BUG( 1) /* NULL-ing a selector preserves the base and limit. */
 #define X86_BUG_CLFLUSH_MFENCE    X86_BUG( 2) /* MFENCE needed to serialise CLFLUSH */
 #define X86_BUG_IBPB_NO_RET       X86_BUG( 3) /* IBPB doesn't flush the RSB/RAS */
+#define X86_BUG_CLFLUSH_MONITOR   X86_BUG( 4) /* MONITOR requires CLFLUSH */
 
 #define X86_SPEC_NO_LFENCE_ENTRY_PV X86_BUG(16) /* (No) safety LFENCE for SPEC_CTRL_ENTRY_PV. */
 #define X86_SPEC_NO_LFENCE_ENTRY_INTR X86_BUG(17) /* (No) safety LFENCE for SPEC_CTRL_ENTRY_INTR. */
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 16:46:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 16:46:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1023990.1400068 (Exim 4.92)
	(envelope-from )
	id 1uU6n5-00040c-Rr; Tue, 24 Jun 2025 16:46:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1023990.1400068; Tue, 24 Jun 2025 16:46: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 1uU6n5-00040V-O0; Tue, 24 Jun 2025 16:46:35 +0000
Received: by outflank-mailman (input) for mailman id 1023990;
 Tue, 24 Jun 2025 16:46: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 1uU6n5-00040P-8x
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 16:46:35 +0000
Received: from mail134-21.atl141.mandrillapp.com
 (mail134-21.atl141.mandrillapp.com [198.2.134.21])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c8933281-511a-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 18:46:33 +0200 (CEST)
Received: from pmta10.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail134-21.atl141.mandrillapp.com (Mailchimp) with ESMTP id
 4bRW7C4KDWz1XMfdq
 for ; Tue, 24 Jun 2025 16:46:31 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 0507621ca80f40ce8c63b7ec82219b8d; Tue, 24 Jun 2025 16:46: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: c8933281-511a-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1750783591; x=1751053591;
	bh=utlhzJJl5garRAOCZabEjFWcBAsz0PPqqW4UKkCMth0=;
	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=ZBOi1pfELwJ4xvdgVWseQlyN9OeAWO/XAECT6JzAK0XTcyMLL2fJ2V5HMi+gawCl7
	 NPlG3M3i19zImSd2irlaIqNdrOZQRzlldb3wHpbGLkv7HF0H64GE9oHwm7A4Lidtgd
	 E7kF3yCHTijtUVMfkCepP7Qs3nHtlwQzFYvkdyNsWqnf8hYynFlUrnJgZKxuDfI3mP
	 uLEfJY1Ic/FQMj4JHgTGOEPZE2vJpT9v8VNMsOejI0lF6yDhJGTkhKkB/PQ+ee4RSs
	 9Fo6a7BfaRc8C6vnicZNlX48DfyDkKtmP6u3NqLQNImv1TgPodcsr962PbCKcjyjnG
	 YiNQ3va7GdV3Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1750783591; x=1751044091; i=teddy.astie@vates.tech;
	bh=utlhzJJl5garRAOCZabEjFWcBAsz0PPqqW4UKkCMth0=;
	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=G7kGrDctVfeI5afiYHBDXctzA1AZAQa9Awn8QClkMZo625USzY9fZzwBXQl6gACCJ
	 /T8w6yXQivwNiWDfJP/fKiyhOzYZZ4lj24xMCwiERVBA88oluBs5dce8IavajRd7Tx
	 oQDlGfvgduu54kUR7CImqJqNY0bDzCHDeX6KQGviay3/2c4ZDlvBtZ6/kNQwV5pPJr
	 KoL/I7Mqi/HQQzDOGa0WDEJsRUXb9k7HzxaRRuhKaVdoOFX2G0U2vtVhcV7/VE8YV+
	 bvZqbmhIyDaQepcIYW9+6TMFWjyu7PJ72Y/kxbe1Q6Ji/ioFXFlQBqTuwIjJ+rJNMK
	 aY5qDSaB5BntA==
From: "Teddy Astie" 
Subject: =?utf-8?Q?Re:=20xenstore=20-=20Suggestion=20of=20batching=20watch=20events?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1750783590303
Message-Id: <6516c9bf-204d-45f6-9e24-e63150d3f354@vates.tech>
To: "Andriy Sultanov" , xen-devel@lists.xenproject.org
Cc: "=?utf-8?Q?J=C3=BCrgen=20Gro=C3=9F?=" , "=?utf-8?Q?Edwin=20T=C3=B6r=C3=B6k?=" , ngoc-tu.dinh@vates.tech, "Christian Lindig" 
References: <47b7f870-e1d9-44c9-b8ea-5b9028843963@gmail.com>
In-Reply-To: <47b7f870-e1d9-44c9-b8ea-5b9028843963@gmail.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.0507621ca80f40ce8c63b7ec82219b8d?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250624:md
Date: Tue, 24 Jun 2025 16:46:31 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hello,

Le 24/06/2025 =C3=A0 16:53, Andriy Sultanov a =C3=A9crit=C2=A0:
> Currently, as far as I am aware, the ability of xenstore clients to 
> properly
> handle and detect batch updates is somewhat lacking. Transactions are not
> directly visible to the clients watching a particular directory - they wi=
ll
> receive a lot of individual watch_event's once the transaction is 
> committed,
> without any indication when such updates are going to end.
> 
> Clients such as xenopsd from the xapi toolstack are reliant on xenstore t=
o
> track their managed domains, and a flood of individual updates most often
> results in a flood of events raised from xenopsd to xapi (There are
> consolidation mechanisms implemented there, with updates getting merged
> together, but if xapi picks up update events from the queue quickly 
> enough, it
> will only get more update events later)
> 
> The need for batching is fairly evident from the fact that XenServer's 
> Windows
> PV drivers, for example, adopted an ad-hoc "batch" optimization (not 
> documented
> anywhere, of course), where some sequence of writes is followed by a 
> write of
> the value "1" to "data/updated". This used to be honoured by xapi, which 
> would
> not consider the guest agent update done until it received notice of such=
 a
> "batch ended" update, but it caused xapi to miss updates that were not 
> followed
> by such a write, so xapi now ignores this ad-hoc batching. One could 
> imagine
> many workarounds here (for example, some sort of a mechanism where xenops=
d
> stalls an update for a second to see if any more related updates show up 
> and
> only then notifies xapi of it, with obvious trade-offs), but IMO it 
> could be
> worth considering making this easier on the xenstore side for different
> use-cases.
> 
> Suggestion:
> WATCH_EVENT's req_id and tx_id are currently 0. Could it be possible, for
> example, to modify this such that watch events coming as a result of a
> transaction commit (a "batch") have tx_id of the corresponding transactio=
n
> and req_id of, say, 2 if it's the last such watch event of a batch and 1
> otherwise? Old clients would still ignore these values, but it would allo=
w
> some others to detect if an update is part of a logical batch that 
> doesn't end
> until its last event.
> 

I find this a bit problematic as it adds assumption on a well-behaving 
xenstored. What happens if you receive WATCH_EVENTs with only 1 (and no 
2) ? Should the xenstore client assume that a WATCH_EVENT with 2 may 
come at some point (lingering some arbitrary time), or still process it 
in a singular way (like currently) ?

Without changing the protocol itself, we can improve the situation at 
the xenstored/client level.

xenstore being architecturally a ring buffer (and a socket when 
communicating directly with Dom0), we can batch multiples WATCH_EVENT in 
a atomic way (up to ring size with ring buffer). In a way where the 
client will be able to process multiple WATCH_EVENT without eventually 
stalling.

(with ring buffer : write multiples xs_wire messages and only then 
update ring index and raise event channel)

In userland, this could take the form as xenstored pushing multiples 
messages through a single send(), so the client would be able to perform 
all the recv() at once.

> Is this beyond the scope of what xenstored wants to do? From a first 
> glance,
> this does not seem to introduce obvious unwanted information leaks 
> either, but
> I could be wrong. I would love to hear if this is something that could be
> interesting to others and if this could be considered at all.
> 
> Thank you!
> 
> 
> 



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech




From xen-devel-bounces@lists.xenproject.org Tue Jun 24 18:01:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 18:01:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024020.1400077 (Exim 4.92)
	(envelope-from )
	id 1uU7x7-0005e9-Uf; Tue, 24 Jun 2025 18:01:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024020.1400077; Tue, 24 Jun 2025 18:01:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uU7x7-0005e2-Rv; Tue, 24 Jun 2025 18:01:01 +0000
Received: by outflank-mailman (input) for mailman id 1024020;
 Tue, 24 Jun 2025 18:01:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uU7x5-0005dw-Vb
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 18:01:00 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20604.outbound.protection.outlook.com
 [2a01:111:f403:2417::604])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2cedc599-5125-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 20:00:57 +0200 (CEST)
Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
 by DM3PR12MB9415.namprd12.prod.outlook.com (2603:10b6:8:1ac::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.30; Tue, 24 Jun
 2025 18:00:53 +0000
Received: from PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264]) by PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264%4]) with mapi id 15.20.8857.022; Tue, 24 Jun 2025
 18: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: 2cedc599-5125-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=oamGGq0szH1oi4OunNTl9Zr9PCMc/9grSWAmkFEZsyiQdloN8YAqhd+UqwoSkO1UhLhoRkTlbv4/jz9TEEeYUeDxCfEJxbQLp7JlKimUS120hc53IJM31vALPSjsZNqH6wi6j+ZOsIXnTgj6sh4sIvVvIF8ntVNGDk/G2uSxJx6+BAx8jMJol696GWWYTRt2ECgqO+6icirynbmPygIwCI3qB6Tb4Ra4aJP4wUaiK3alOtE2ReJr7u68YUle3Z2Ok5nk6v9eIQrx7n/20fAO2pugut7rljKsVZSw8+7iW4v01/8zeetgOtTHXZfQbDsv8ygWmyV1C8vt29RmoY8kXQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=T5wJo0L1SKWgKFZ51jXd3Jpj2o2N23/1Qjr2Vkfukbw=;
 b=L0KZAA16dhaq/Eg28Hwxk80MQubUVzxXKbkFI7zgh3UzpfsHnXDPcqiPBeVDSCZf9lKVE+2UMEf+W9A7Dh8mJuDXM88A+jXEbLnyvK6sKw71kNeqVZyhxCOdI76eTvhvWEzgrH0Ry1EYFXLMccxmGB8u8freMrYtzG3QyNE4xwp2iHo+W35pql5epUbsvThAH3CAiAFlXUa1Fy52A4XhLVtTAy7c2/WOtdO2nAN2lZ+am7BP6dZVVukQ9lYsopo6d3W0zthd7BYOM5xeMsTJHkJcRgOzz8w6hja50Ove40pLsR+0WXN+nWnaZJ2qM1gAa0R/9LA7aZl4JKGi3tk//Q==
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=T5wJo0L1SKWgKFZ51jXd3Jpj2o2N23/1Qjr2Vkfukbw=;
 b=wCdPmZTelUrVxwxDQztnJK1AdUM2WDrGt+QNaC96eod4TJ7K98+C1B6Z4V09ByVE6eH+WqpmIknmKWdCgJHx4q46Gst/m1JYNpLYVomr52q5QZ1N5H1xdZ/w0j5Vpt/NSPNGjAoHKgCnLTKoMFZM1CflpEctUnDT1VzRxnPt4ZU=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <86f13ad6-317e-4abb-a664-9db33658bf6f@amd.com>
Date: Tue, 24 Jun 2025 19:00:48 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/6] xen/arm: Introduce flags_has_rwx helper
To: Hari Limaye , xen-devel@lists.xenproject.org
Cc: luca.fancellu@arm.com, Stefano Stabellini ,
 Julien Grall , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: 
 
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: DB8PR06CA0062.eurprd06.prod.outlook.com
 (2603:10a6:10:120::36) To PH8PR12MB7326.namprd12.prod.outlook.com
 (2603:10b6:510:216::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|DM3PR12MB9415:EE_
X-MS-Office365-Filtering-Correlation-Id: d7020abf-d357-4d4b-07c2-08ddb3490f4f
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?STU2SDIxRkFJNkhsNTE0clBZTzcwVkF5NGpDK3UwNi9NSUZUWjBiNWh2ckl3?=
 =?utf-8?B?bE05Sm0zejl2UG5URlk1YWplQjVuSERnSWtFVEZZek1sTWE4cVI0SVlBSGQ0?=
 =?utf-8?B?c24rK1Uwa01obzJZSUxFcFAwN25zWFdibE54UFJuRUVIb1lvVmtOTU9ZSVBv?=
 =?utf-8?B?OHh4VkdJdGl2UnRXV2hMcjg0ZUVDNC83bFRjZTZCc0VMRkxIZ09nRW1TNEFR?=
 =?utf-8?B?UFZCU1hGajlUc3c5NmtMWGpSbGRKdlNSUmJDbk5wOXAwcEYwb3hCbmFNQlFh?=
 =?utf-8?B?RG8rQVYrZFlySTNyWlIrNjg1TTlJSFkxRkxlT3VmWlNacUs4Ylk1UEZWbjdT?=
 =?utf-8?B?OTRkUDBBQWQ2dWl1RHl2WkhteHZBSDk0UVNOalhqK24yRmxPQjZHTWt5ZzFl?=
 =?utf-8?B?WlZDNTYwRnJuMnZtYzJHWVlOUnMrRFN4bkxzckFTYVZiTTRPbFZqVkNmQmpz?=
 =?utf-8?B?eElEajB4eUxFZU04TVQvRlBRRE50eDZabWJwNnpSazZDMGtGRzFzNWtvZzZS?=
 =?utf-8?B?OFFyQThWeFVnVURpM3VKRTlTQnZGUi9zcmVwaWdDNTZVYnVlbnFHWnNoOVI5?=
 =?utf-8?B?eS9aOXcrY2Q0ZHZLcXd3cERoMnBmNk9IRm1MN1F6L0UzZHFoZmhXbHdYRW9h?=
 =?utf-8?B?VmFoaFpRNXNSbHV2bGVnNXpmRWZTMzFENHRSYkNESENTSTBaSWJLQVh2cXNY?=
 =?utf-8?B?REo3b1ZzUXRyU2FGd3BCbWxWWHVxRmxKa2lXQkU2TE5RUVd6RzVKR1hsU01y?=
 =?utf-8?B?SkxIdUJ2VXJzNHI3Q2l3QzNsR01NSy95VEE5bVlYWmM5T1N4N1V0WC96SW9Y?=
 =?utf-8?B?OUpwNEFyblJEL2I5VEE0Qi8wWDF3M1JYNCtkWTZTZDMveTBlMHRGZm4vSE4v?=
 =?utf-8?B?a0l6MnZxclJWc3I5ZWIvMm9meE5Ra3B1bis4VkFnOHQ4VzdQZ0xrcFVGb1cy?=
 =?utf-8?B?dXZYREkzaUZ6ZTBwRmpoSVM4T0Y2WkRBMXhUNGhQUWVraG84dGpJMzZma1Ji?=
 =?utf-8?B?TTFkQkgyN2xidTNnSkF3b3BpUTYrWEFrUis5U3RISE9QYVg2dFIyUCtrVXB3?=
 =?utf-8?B?ZGttNElNZGFyTmgvYUhoT21neVVHNFlVYVNtZkRHYU5yRzhsM2lIYjd0SWVy?=
 =?utf-8?B?QmFib0szdW9QamJvTEZXMkpuZExiVUVDWHRLQ3ZVWTloWVUycWFJTUVCVklW?=
 =?utf-8?B?TFZHdlNWZ1VCWWZQRFViaDF4WFMzeHFkT21BWis0Qmd2R2g0VS9OYUUyKzZ1?=
 =?utf-8?B?UGtIUDA1enpRSXR0NWF3K3Y4MitKZHBCRjVaR0liTk9EejNjSXFEM2RRQmZ2?=
 =?utf-8?B?SXJEcWZIeGNxL0duREd4KzRSOXF5MUZ4dHp1VEpLU2R5UUpTYk4zTzErVDB5?=
 =?utf-8?B?WXJnSy94QjVLUTRsMm1hTWtBS05OUlNpaW5pNjJFZVF5dDJMWkNhalczMVg4?=
 =?utf-8?B?cXF5VjJiL3Z6UUd1QjZLdS8rcUNNOHIzeDJLbnFDSWNETXp3VkkxYVo0ZmtT?=
 =?utf-8?B?aVNDU05hLzRaYWJYUVRxU2pNdDhua2ZGQm1xK1Azd0k0UUgrM21sSk5XM0sy?=
 =?utf-8?B?ZEV5OHVISU8wWjhLQVVFZWNGTGtWSzRZYjEyQzM0V1ZDYTZRNUUzVDZQcG9L?=
 =?utf-8?B?Q3NOUzQ3SkI3by9ic1ZvWjlrcUpndHBrTWl4NW5yN1dXVEtRMWQ1dGpTNGxX?=
 =?utf-8?B?anFhTit3ZTZaUStpWnNnNWFSWHMyTE8xZmJHK25iTkI2RlE4SWxPbUxNb0F3?=
 =?utf-8?B?VUxCL0tSeXBLNmhLakN0bkd6bEdiallLdXMwTHpXRkZ5LzA1V2FYU0d6ZW9X?=
 =?utf-8?B?Y1lZTE44NmtubjJ0dDZncHNTRFZwUGExTG1PREoyOEpRSzBIYSt1U2NHdzBx?=
 =?utf-8?B?UkdHRXlQbDV1M29WdUtDeEVZOE5UZ3VQQWVhNndZcUZ5YnNsZHI4bDdRNm55?=
 =?utf-8?Q?P/0KVhc+mB4=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)(376014)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?SEN4SXdEbndaeDFYeWtBU093NFlSdExDWm1RVVpSc0FhdzZDNEJWMjNzeEFN?=
 =?utf-8?B?MHF5STRXQU0vUDBPb3lkeUJLbmpSUC9EYkR4OVNNUVNjck1VY2lwM0JYNCta?=
 =?utf-8?B?Q1VMNFhrSlVJNjV6dEpyaWJJamlZRStkMjVpWFp1c29GYVRQTXVSRkRUWTdW?=
 =?utf-8?B?SFNtTmFaSUR2bFZYeitIVmNwbVpxNmJScVZCMzRlZVFFTE11STM3OFliTWJD?=
 =?utf-8?B?S2d4b3RUQUFLL0N3TDhMWnpXeDg3Q3VQTDUxUzZYL1h2MU5FN3UvTngrZytR?=
 =?utf-8?B?MVIzZks1YzRsMmJWWmlMMTlManQ0ejVZVHFTZWMrU3NIc3prL1hCVDZCWDJo?=
 =?utf-8?B?ZjV0T01NUzJCdzBBTnByQmw5SUYxemppdmtvRHNXQ0hFNGF0ZTFwZFBEM0RI?=
 =?utf-8?B?SGRtYmp4WUhMZkJpUkVsRm8vOTQ5V2QwTWp1Vy9MMWwyUDNHSm1hSnVKNW9w?=
 =?utf-8?B?WmpRREI4cjdSSVdQaGVKaXRlWVhFVHluWThQN0MyR1kwbU93QlpvTDJ6M0Zo?=
 =?utf-8?B?YzZaMDIzSjBHQXgxZG4wdVFkRGpzc1hOZkFjWWJzZlJFTzR3Y0VycUYrSWU0?=
 =?utf-8?B?RENNNGVERjhhVjR6MDRNdGhIWW5TVUdkTE9SM0ZKTmgyU01jbEkzbVhBZHM2?=
 =?utf-8?B?YitHdTZXbjhUWUdzeHdROVFhc0Z1dzBnWDI1Tk9qUi9FVlZsRG83WHE2VUMy?=
 =?utf-8?B?Y2x4KzZoK2tZL2hnUEZWWDR3UUN1VDZjLzc0Mm5ROWFPaFh5d3VsNnA3WUlN?=
 =?utf-8?B?V2RGMkpLcDdOM0srRlAzaTBSZVgvbktkUDIwVVFWN1VnR3E2VzdQclFTc0VZ?=
 =?utf-8?B?VUdSUjAweHJXRDdiVkFMSy9qdnhnemlXSnAwZnZIQWdRS3hNUzgzMnVlak5o?=
 =?utf-8?B?b21ZaGhqbUtlUWhSZEdVRGs4WmRzS0xKM2FOTXE2U08zQ0xQZlpMa0lJZkRE?=
 =?utf-8?B?cE45NitvWXBPNTUwdzJ2bzZPUGo4K0UrZ0JwYUtxRWIvRTNvY2RkNys1YVZH?=
 =?utf-8?B?T0VtOFNxTGNUVkZCNCtaMFF3Q1ZxcFV2K0Y1NU5qK0tiZmE3bXlsRDB2NzlZ?=
 =?utf-8?B?anpTUWhjZk1lUFBUR1U5TnhacjI3RFR6aVduMTFsTUNtZk9Ma0dOaHhMN0dJ?=
 =?utf-8?B?ZmtBTWtxQlVrVWpKbWt4NkpkVzRnM250RTlONjRZaVgrbklQM1BuM2d4RWEr?=
 =?utf-8?B?a0ZaNVk4Z0d5ODNOa0VVeEI5U0lzMkpHeUk0cnRYZFJ1TTJGMFJ4UGJTYmFl?=
 =?utf-8?B?T0E5d2h4SVdHSVp4ZzUxREVBbmhNV2d6NVE5QTd5bWRQaHY0U2N3QVd6ZFRh?=
 =?utf-8?B?TjNKb2xDZDVRdURHN1hkZTltdzhmd2JGb20zbHp0d2pSbGNiaU1YNFJGUStZ?=
 =?utf-8?B?N2pHblNwdTY2eVdOYTlrSmJVcmxUMllwK0lEUWlwZWZ3MVVMaUJCU2ZsNllI?=
 =?utf-8?B?eFhPdy9VSkc4NkNqemc2akNHNmZuanQ3d2NaQWhBZllpTXJIanIwVk9neXow?=
 =?utf-8?B?NmFhbzIrNDRFMDhEd0kwdmVtTU9GTnJUSW0xdnJzRFlyQkg0dUdrcU1CN3ZF?=
 =?utf-8?B?a1dHRmdEWGg3WTJWVS90MjY3ODRLM2lyVVE0dS9Fa0w2ZVU3ZHpVWkEzamdB?=
 =?utf-8?B?R2dBVGJEUDNnWU1abUdKVEwvK1Zzd0c0MCtYMGFkNVBkRlF2V2c2N2hBU3Ar?=
 =?utf-8?B?M203SEZwMTR1K1I1bHhEZXpzMTIwRklZS1BPaVdLRFQ0eFBZcE9ERUdENFR4?=
 =?utf-8?B?RjFoNGdmNGEvd3EwbGdZeWQ0Q1R1OVpOS0NlR1hpMytmVnBJVnFYb2hXY2Q0?=
 =?utf-8?B?UWdpQzR5TjZNeGxncE1pbG10VmFUTmRaclFVc2lPVExOREc4UHhkQlp0dVo3?=
 =?utf-8?B?ZlV5alJDb21RK2NoZ3krSm91enFCY3VxVGtVeHFWUFB4WTE0WFh1S29kY2R3?=
 =?utf-8?B?Q3EyaU5JYU1wbDRiMTEyanhlVVNveFRQU0JGcm56TDVuTit4a1ZOT09pRlhI?=
 =?utf-8?B?SForeDEvak9kdVRxVk1WTnhkSURqV3NTWC90ZVZNTUkyTUJQRzJMeS9FVDVl?=
 =?utf-8?B?cXZ3QkVuVjlVR0VTaVR6ak1YS3hVdzJ2SG11OEtLbG9CUkIzMk1GNCs5cjZV?=
 =?utf-8?Q?H9PKo/JF4NGn/WYbmFvu2Tan9?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d7020abf-d357-4d4b-07c2-08ddb3490f4f
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jun 2025 18:00:53.0583
 (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: Mx959RoDJziJe3RzIWdX0gUbkzqBdGOl0PbwYLiD/HlX7ZhyMdGaLQ4Uav4L8ga9TeRoHhBh9gvvGV12v9H8yg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3PR12MB9415

Hi,

On 20/06/2025 10:49, Hari Limaye wrote:
> CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email.
>
>
> From: Luca Fancellu 
>
> Introduce flags_has_rwx() function that will check if a
> mapping is both writable and executable when modifying
> or update the mapping.
>
> This check was already present in pt.c but since it will
> be used also for MPU system, it's wrapped into a function
> now.
>
> Signed-off-by: Luca Fancellu 
Reviewed-by: Ayan Kumar Halder 


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 18:43:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 18:43:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024032.1400088 (Exim 4.92)
	(envelope-from )
	id 1uU8c4-0002GR-0o; Tue, 24 Jun 2025 18:43:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024032.1400088; Tue, 24 Jun 2025 18:43:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uU8c3-0002GK-U8; Tue, 24 Jun 2025 18:43:19 +0000
Received: by outflank-mailman (input) for mailman id 1024032;
 Tue, 24 Jun 2025 18:43: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 1uU8c2-0002Fs-MI
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 18:43:18 +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 14f5406f-512b-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 20:43:14 +0200 (CEST)
Received: from lelvem-sh01.itg.ti.com ([10.180.77.71])
 by lelvem-ot01.ext.ti.com (8.15.2/8.15.2) with ESMTP id 55OIglKf1238390;
 Tue, 24 Jun 2025 13:42:47 -0500
Received: from DLEE114.ent.ti.com (dlee114.ent.ti.com [157.170.170.25])
 by lelvem-sh01.itg.ti.com (8.18.1/8.18.1) with ESMTPS id 55OIgluT1799620
 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=FAIL);
 Tue, 24 Jun 2025 13:42:47 -0500
Received: from DLEE104.ent.ti.com (157.170.170.34) 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.55; Tue, 24
 Jun 2025 13:42:47 -0500
Received: from lelvem-mr06.itg.ti.com (10.180.75.8) by DLEE104.ent.ti.com
 (157.170.170.34) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.55 via
 Frontend Transport; Tue, 24 Jun 2025 13:42:46 -0500
Received: from lelvem-mr05.itg.ti.com ([10.249.42.149])
 by lelvem-mr06.itg.ti.com (8.18.1/8.18.1) with ESMTP id 55OIgkxh1989825;
 Tue, 24 Jun 2025 13:42:46 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 14f5406f-512b-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com;
	s=ti-com-17Q1; t=1750790567;
	bh=d7RyoS9Xq2SqZl1k6ym5o4fjIiCYNNVYuTiU+w0N+C0=;
	h=From:To:CC:Subject:Date;
	b=nAAHio8ZNDbgN+CYEXlSX8ptbbLOIUV6HwBmawy1Tb5LqOjTZyTThqn9KBwzs0vJw
	 5Xit6sT2Nz66hLxFPPfb+0zrNEE5Pwz9STdGo0+4IXBT+JxmV2UAcMsLP6d6/nR5F2
	 7hCnBVlC1srj0C2ojrFRhd6buTHEga2/CVW9o7D4=
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 v6] ARM: Switch to new sys-off handler API
Date: Tue, 24 Jun 2025 13:42:45 -0500
Message-ID: <20250624184245.343657-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

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 
Acked-by: Alexey Charkov 
---

Changes for v6:
 - Rebased on v6.16-rc3
 - Squashed series and sent to soc@lists.linux.dev as suggested by Arnd

Changes for v5:
 - Rebase on v6.15-rc1

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

 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(-)

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);
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;
 
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();
 
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__);
 }
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 Tue Jun 24 19:41:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 19:41:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024049.1400098 (Exim 4.92)
	(envelope-from )
	id 1uU9WL-00011u-Sn; Tue, 24 Jun 2025 19:41:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024049.1400098; Tue, 24 Jun 2025 19:41:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uU9WL-00011n-P1; Tue, 24 Jun 2025 19:41:29 +0000
Received: by outflank-mailman (input) for mailman id 1024049;
 Tue, 24 Jun 2025 19:41: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 1uU9WK-00011g-9o
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 19:41:28 +0000
Received: from mail-pf1-x44a.google.com (mail-pf1-x44a.google.com
 [2607:f8b0:4864:20::44a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3722823b-5133-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 21:41:26 +0200 (CEST)
Received: by mail-pf1-x44a.google.com with SMTP id
 d2e1a72fcca58-748f3d4c7e7so4354377b3a.3
 for ; Tue, 24 Jun 2025 12:41:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3722823b-5133-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20230601; t=1750794085; x=1751398885; 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=FUFFiUTwDIQTjkS/XGuKJUupkz/Ptibx0+U0nupMqZk=;
        b=3KEomNLlbp5ascgkiZTtrC7tjL6J3wSr67ezADtNkChrDPgALXnWf8U/YIBlTbTcAC
         fRxmOOgcNf6Qyy1T9JkZVKZXy+eamhMSUCm4elizyw3rpX6G1WiL3igQbpbBQ/U+Pk/Q
         N7xQEKOjnT1D7kgxdnXA77RhpDR50DtqVRc3JPYvupHOxWPvckSfZaG4KxF9ee2Xct4k
         J8vALAchaMoyhQI6njZaylQt7OcfWxDR9dySdEX3Ej5QlpEFiCkINbdwvyb9IT+xLYbY
         3hoP/7Ij3CnZw2dBbFTRVDU5Fsq5Piw86niamcaJqqVwAMs4kSqTiXLFnzgI6Wpwj0lx
         38bQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750794085; x=1751398885;
        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=FUFFiUTwDIQTjkS/XGuKJUupkz/Ptibx0+U0nupMqZk=;
        b=qYWu7RN3W+uZj5KLXaA7OGiqYL6xrGA7Eo52Ii2QVOhIq8pwltS4s2dbDbUXrrVgyb
         EIhiQCz8z05ulDo/sLPXOjiUvkPBmomMwSvoF+oh0c2D7Clsiwkd2v4EghkWD1uva1IR
         wQs6+ekPC5XZptH4Nmy+wMdv7h2xe6lCQNoWg0PmMZ2StKZf70GghR2ejRRRZ4+qJTbH
         c94pO61jXAnVCDsaO4VWQ8plg+pEFZLGxRwwxme6IdeG84rIZWF/RGPNe5cIpVCYqqGa
         m8D07lCO1hHh+BitFfgwo2EK4EtXhVMcVqhM587KUs2S2l+bw33pW9aN/GArUafaIsqo
         xdwg==
X-Forwarded-Encrypted: i=1; AJvYcCXzpyTh886GDaS5zUIhWQsn7KpP8nKW2vO62CW8m+8q2Y4mcmLKXAGBu1LJDM/Vgj+1MdJn9p1bsx4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzwyWgv7Rm8pIOsTdem+NuvfkGHIlzJTmpxcScJidPz6IzGig/4
	sofc/1A4b1zR8QXgbL0zM0UlxlKpGB1saljtaYTgbDePEaMYkwUDM5zNpNwPfL5ouNCMHRLYlYZ
	OmIGUYA==
X-Google-Smtp-Source: AGHT+IHYexPIgCTXbHegrNWRwV9PAsICfBY+CW50dlQj/EuWE5JzEYSKqjcY5P3xX5xOKDb9+UElHwxg8eM=
X-Received: from pfrb8.prod.google.com ([2002:aa7:8ec8:0:b0:746:32ae:99d5])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:170d:b0:748:1bac:ad5f
 with SMTP id d2e1a72fcca58-74ad455d619mr461113b3a.12.1750794085384; Tue, 24
 Jun 2025 12:41:25 -0700 (PDT)
Date: Tue, 24 Jun 2025 12:38:26 -0700
In-Reply-To: <20250522235223.3178519-1-seanjc@google.com>
Mime-Version: 1.0
References: <20250522235223.3178519-1-seanjc@google.com>
X-Mailer: git-send-email 2.50.0.714.g196bf9f422-goog
Message-ID: <175079267460.517177.7949210108988821172.b4-ty@google.com>
Subject: Re: [PATCH v3 00/13] KVM: Make irqfd registration globally unique
From: Sean Christopherson 
To: Sean Christopherson , "K. Y. Srinivasan" , 
	Haiyang Zhang , Wei Liu , 
	Dexuan Cui , Juergen Gross , 
	Stefano Stabellini , Paolo Bonzini , 
	Ingo Molnar , Peter Zijlstra , 
	Juri Lelli , Vincent Guittot , 
	Shuah Khan , Marc Zyngier , Oliver Upton 
Cc: linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	xen-devel@lists.xenproject.org, kvm@vger.kernel.org, 
	linux-kselftest@vger.kernel.org, linux-arm-kernel@lists.infradead.org, 
	kvmarm@lists.linux.dev, K Prateek Nayak , 
	David Matlack 
Content-Type: text/plain; charset="utf-8"

On Thu, 22 May 2025 16:52:10 -0700, Sean Christopherson wrote:
> Non-KVM folks,
> 
> I am hoping to route this through the KVM tree (6.17 or later), as the non-KVM
> changes should be glorified nops.  Please holler if you object to that idea.
> 
> Hyper-V folks in particular, let me know if you want a stable topic branch/tag,
> e.g. on the off chance you want to make similar changes to the Hyper-V code,
> and I'll make sure that happens.
> 
> [...]

Applied to kvm-x86 irqs, thanks!

[01/13] KVM: Use a local struct to do the initial vfs_poll() on an irqfd
        https://github.com/kvm-x86/linux/commit/283ed5001d68
[02/13] KVM: Acquire SCRU lock outside of irqfds.lock during assignment
        https://github.com/kvm-x86/linux/commit/140768a7bf03
[03/13] KVM: Initialize irqfd waitqueue callback when adding to the queue
        https://github.com/kvm-x86/linux/commit/b5c543518ae9
[04/13] KVM: Add irqfd to KVM's list via the vfs_poll() callback
        https://github.com/kvm-x86/linux/commit/5f8ca05ea991
[05/13] KVM: Add irqfd to eventfd's waitqueue while holding irqfds.lock
        https://github.com/kvm-x86/linux/commit/86e00cd162a7
[06/13] sched/wait: Drop WQ_FLAG_EXCLUSIVE from add_wait_queue_priority()
        https://github.com/kvm-x86/linux/commit/867347bb21e1
[07/13] xen: privcmd: Don't mark eventfd waiter as EXCLUSIVE
        https://github.com/kvm-x86/linux/commit/a52664134a24
[08/13] sched/wait: Add a waitqueue helper for fully exclusive priority waiters
        https://github.com/kvm-x86/linux/commit/0d09582b3a60
[09/13] KVM: Disallow binding multiple irqfds to an eventfd with a priority waiter
        https://github.com/kvm-x86/linux/commit/2cdd64cbf990
[10/13] KVM: Drop sanity check that per-VM list of irqfds is unique
        https://github.com/kvm-x86/linux/commit/b599d44a71f1
[11/13] KVM: selftests: Assert that eventfd() succeeds in Xen shinfo test
        https://github.com/kvm-x86/linux/commit/033b76bc7f06
[12/13] KVM: selftests: Add utilities to create eventfds and do KVM_IRQFD
        https://github.com/kvm-x86/linux/commit/74e5e3fb0dd7
[13/13] KVM: selftests: Add a KVM_IRQFD test to verify uniqueness requirements
        https://github.com/kvm-x86/linux/commit/7e9b231c402a

--
https://github.com/kvm-x86/kvm-unit-tests/tree/next


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 20:14:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 20:14:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024072.1400108 (Exim 4.92)
	(envelope-from )
	id 1uUA2D-00050c-8c; Tue, 24 Jun 2025 20:14:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024072.1400108; Tue, 24 Jun 2025 20: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 1uUA2D-00050V-5w; Tue, 24 Jun 2025 20:14:25 +0000
Received: by outflank-mailman (input) for mailman id 1024072;
 Tue, 24 Jun 2025 20:14:23 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uUA2B-0004ys-Bz
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 20:14:23 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20601.outbound.protection.outlook.com
 [2a01:111:f403:200a::601])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cf12cd02-5137-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 22:14:20 +0200 (CEST)
Received: from MN0P222CA0011.NAMP222.PROD.OUTLOOK.COM (2603:10b6:208:531::17)
 by CH1PR12MB9670.namprd12.prod.outlook.com (2603:10b6:610:2af::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.25; Tue, 24 Jun
 2025 20:14:14 +0000
Received: from MN1PEPF0000ECD5.namprd02.prod.outlook.com
 (2603:10b6:208:531:cafe::1) by MN0P222CA0011.outlook.office365.com
 (2603:10b6:208:531::17) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8857.30 via Frontend Transport; Tue,
 24 Jun 2025 20:14:14 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 MN1PEPF0000ECD5.mail.protection.outlook.com (10.167.242.133) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8880.14 via Frontend Transport; Tue, 24 Jun 2025 20:14:13 +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; Tue, 24 Jun
 2025 15:14:13 -0500
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; Tue, 24 Jun
 2025 15:14:13 -0500
Received: from [172.29.43.193] (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 Jun 2025 15:14:11 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cf12cd02-5137-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=xWjOmclf/gU66jnvA462W+JyYV90BjkpwpND6VvnC/q1c9WLMHQFH/kYh+TgILoorbUHd/VC9u9NOb4zeLzGOJirLHQADSFhFvp5kkHR4ZZ3X9N1fcBflM8C7VcALC2d4H4C6WFzPCydV8pPoZRBmgRIELe2Qtya+T8mBVG0UlIQ2wTetpKCG2V/9DsKYS9oAkwX05VE1pU6jZvmHT3bBHCEOS+lndHy7QTFTMjxiUPxicZtULPYz1T/fgbrRUyEvjBDWE115MftJGAmgbYoKjrlmEULoimrq30PKr64bIEeLwCz9Exk57tl9+M9faGzyJgvu0vjM1GTWY94ZtX4kQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=6e6LxrDUk7QNpNs1K2g9YMcxMyKsWbi3PcOKroJCnoM=;
 b=oWgRIN+5B02xl05OPogbuzWCmEGF66aG8XE0BTDQUGh2kQpxw87GJ1MoaeoNUetMN168+rOpJ8iDm5n2cBZcxyDp2l4uFRGO4TpPwJUw/ED3GDWYce5R9WT4MJgglqhcvLXBjyGo1UM7G4Mzkm9Z3VUnOaFyTWcwFUrNwM2F2sCnBgy0PDP/KdcNZTOJDg3yDTLyoDduJNl81bcqdMQMMTXOWacSs6gpMD1pisaAjo+UZ/7js2A9M4pjI3Xx8q5DsilstZjJDZgzCjQQtdUuU3mr5nFnZWSAJMZGMVhYV4DM56GuM7PB6rMGacfUtqSLvnCFMhKPxU5p0kvbXrwJFQ==
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=6e6LxrDUk7QNpNs1K2g9YMcxMyKsWbi3PcOKroJCnoM=;
 b=eF7Sfz4loDitidUzC1gHBYfYgjuF0eScwrD+o+FemaXyMwTw3UdmNBB+bSxNuOKxhSbJ0Ws8kfpwLjA0VBWsLkuxBWix6BRpDRs1MVBGUY3TMcdTYHYsSICR9OpJwmtAtdLg14lVAfplVLoaGmKNsXu0DZ4i/dbHcrzC59mxi4g=
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: <2e27e128-398a-4714-b019-eab04520cc97@amd.com>
Date: Tue, 24 Jun 2025 16:14:08 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: hardware domain and control domain separation
To: Jan Beulich , Stefano Stabellini
	
CC: Julien Grall , Bertrand Marquis
	, Michal Orzel , "Andrew
 Cooper" , Anthony PERARD
	, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	, , ,
	
References: 
 <942a6178-0fe7-468e-8e45-ea255fd20680@suse.com>
 
 
 <381dba84-3108-42c8-a4e5-7bc74d5e1075@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <381dba84-3108-42c8-a4e5-7bc74d5e1075@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: MN1PEPF0000ECD5:EE_|CH1PR12MB9670:EE_
X-MS-Office365-Filtering-Correlation-Id: cf5392ee-b896-4506-f878-08ddb35bb05b
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?ZkxkUHhhbE1QdWNaYUlwRVFJVjRtM2gzTlBQRWpzM3dHYnkwYkRxazh4aW9D?=
 =?utf-8?B?RDg5OXVnbGNRUTlvL0YwbzVjcXIwYk1uczNsZG1jWWxzRUJ6MlBXRTlMdU5q?=
 =?utf-8?B?ZDZHN1UwOStQZEZkQjY5RUkzeDhuMUtlSzRLaVYrRExPczlObGRpQi93M0dv?=
 =?utf-8?B?OTBsOHk2cWRqcEVHM2lHTms0ZmZVVStyZE1lZkhlRjQwdS9iVWhHRndQVDJ4?=
 =?utf-8?B?Rnk4QWsxeWhuSURuNGRyVmI0M0NmTXppL2hNOG1tU0VnaWpRV1VyeUdXVXJF?=
 =?utf-8?B?TXplWHU5NVJTZG1RQWhnQXZENE1BYWVQbGhuN0haMW9aVERSRHNTTUlNdDlu?=
 =?utf-8?B?QW83cGhNcE9sLzcxOWZEdFZaQklQTWVuUUg4aFJVOURvU3VVQ3JjdGIreHlh?=
 =?utf-8?B?MDR5NFZucXJPb2gwdnE3OXFXSi9sSkZ0OVZNYXFtc0tYTHZpcUlSR2Vlemtj?=
 =?utf-8?B?bzdueW9FK3BWVlk3dEJPMklvS1dyREM3NHNDaHE0MERmZGN4QW1TaHRPaHEy?=
 =?utf-8?B?Tm1haml1bHBUSGE5WW5QQXNCUXhWeWJXSGZlRVZnNXBQNWZFbU1DU0RDd2xO?=
 =?utf-8?B?WU1lM2NkSW00aWRnYTF2S2ZCM0srTG5HK215YzNHeTM1aTVSODJXK1dvbmhs?=
 =?utf-8?B?c0Y3MS9BcGhydm0wd2t5TTY1dmxnT1ZZNlNOYVNUd2FpTjlkWFFsdGpGU2Va?=
 =?utf-8?B?SEhUaDd0bzJhSGg0NmFhN1lndGtXWTBHbTM5b3VDMWkzb0hSKzlBeEVPWmU1?=
 =?utf-8?B?b296TGc3OHZ1dlBlb1M4MnFMUklDSDh0dkVybjFBbDdLVUVWQlc1eXpzcmN5?=
 =?utf-8?B?QW9CTmY3YTlIVVdsVG9QM1Y3bFVEajZyVWhtSm1oSjhLSXJPa2V5cldlajRT?=
 =?utf-8?B?U0I0S2RpNjZnSVNFTWVnWDVwY0hwdENPbkVRYlVna0ZaQTVBRlU2SXNobDJS?=
 =?utf-8?B?VWc5SURBUDdCREg5UWo0RW9MdWU4UVExUEkwQjN2NW9BYUdRdStOdENHOTJK?=
 =?utf-8?B?OGppRnVsakJsZXRBd0ZqZTNRYWlwLzdYQStLdVY4UnlUclFTMkVwL0RIVjR3?=
 =?utf-8?B?RjhadUZMSkhQMjI3ZXdvc0FjRjZTK0NEcnFaQW1GRlVoV2c1MWU0YUU4TlM5?=
 =?utf-8?B?b2VNNjdEQXlFQXNtMlFuOFRoaVNGMW4zRldsamNoTXZJV2wvZThwY25yM0dJ?=
 =?utf-8?B?ZjhuVHdONzV1Q3lvZ1grM3VQWTgvMzhwUExOZTRSTmJkRE9hMExqQTcwaUUv?=
 =?utf-8?B?SXdYUGw2U1l4MTRpSzZNcU1FWVZNcTduaU9zcGQySmNiSVpXc2RuREg1VEVL?=
 =?utf-8?B?QS8ySVoyZEFVVVBoeUMrVUxlRWJRNVYwK0ZoWjNvdzRlY29BSE9RK3hFOU04?=
 =?utf-8?B?alpEWC91WWp2dkltMzlSZGNqOU8zaHlnM25IRlNZR2wweElmSUM2Q1diS05r?=
 =?utf-8?B?M096L0RGNnhHMEsxcmNGeUdQencweUwrRktWT2xJTmw3OEZ5dzFCbXorb3ky?=
 =?utf-8?B?MU1sTFBZbG9EaXpKTHRyaHJCT012NElTdkxhdVptWkNTNXFhZkxuOUgwa01K?=
 =?utf-8?B?Z0xEMnNLeWNYTzdQY2UwbmEzMWp4Nk44eHkxTlNtWTlEZjUyTHpmeUJoUUFC?=
 =?utf-8?B?ZGlFOXZURFNmVHVUMGlnYmh5aHhMUjlBcEltVERncDJHbU8zdFBsL1YyckdP?=
 =?utf-8?B?ZVAvTEkzSzVMbWdrWUdEMXZZMS9kL2srVGZ6VXgvNEtHNE9XTkhjVlZpT0d0?=
 =?utf-8?B?Y0FFYU1Cb1FsbGxQMTJIWU5jbGh4NWRndWFLTlRabVd6aGxOMHFmc1lwUEZy?=
 =?utf-8?B?YitrM2RZdHRINnI2V1diV1djaHh6TUxoSGlza3ptRXVpQk1zL2FSb3Y5U3pi?=
 =?utf-8?B?dkNwMzRLZHFxSC9kNWUxMkhPZzNRTHlxWXVjMFliMGdEa1hMNFA5OXd1NS9t?=
 =?utf-8?B?endpY1ZzSHRsM3drT3dYaFVpZnlpaVFXdi9NM3NEUU1qcFkyekt5MXlPTFV3?=
 =?utf-8?B?azIza3UwSndrQXl0a3o0bWhZYlRQSTlhUXJhcGVDNElwTXdzY0dkV00xY1pB?=
 =?utf-8?Q?zrsIOu?=
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: 24 Jun 2025 20:14:13.8238
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: cf5392ee-b896-4506-f878-08ddb35bb05b
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:
	MN1PEPF0000ECD5.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH1PR12MB9670

On 2025-06-24 01:25, Jan Beulich wrote:
> On 24.06.2025 00:51, Stefano Stabellini wrote:
>> On Mon, 23 Jun 2025, Demi Marie Obenour wrote:
>>> On 6/23/25 11:44, Jan Beulich wrote:
>>>> On 21.06.2025 02:41, Stefano Stabellini wrote:
>>>> Also a more fundamental question I was wondering about: If Control had
>>>> full privilege, nothing else in the system ought to be able to interfere
>>>> with it. Yet then how does that domain communicate with the outside
>>>> world? It can't have PV or Virtio drivers after all. And even if its
>>>> sole communication channel was a UART, Hardware would likely be able to
>>>> interfere.
>>
>> There are well-established methods for implementing domain-to-domain
>> communication that are free from interference, such as using carefully
>> defined rings on static shared memory. I believe one of these techniques
>> involves placing the indexes on separate pages and mapping them
>> read-only from one of the two domains.
> 
> How's that going to help with the backend refusing service, which I view
> as one "method" of interference? Or else, what exactly does "interference"
> mean in this context? (More generally, I think it is necessary to very
> clearly define terminology used. Without such, words can easily mean
> different things to different people.)

Yes, there are different kids of interference.  We are concerned about a 
domain blocking another domain.  The main example is an ioreq blocking a 
vCPU.  The blocked domain is unable to recover on its own.

A PV backend not servicing a request is interference, but it doesn't 
block the frontend domain or vcpu.  The primitives don't block, so 
drivers can be written to handle the lack of a response.  As you note, 
this can't be a critical service for the domain.

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 20:59:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 20:59:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024084.1400117 (Exim 4.92)
	(envelope-from )
	id 1uUAjU-0001rp-BK; Tue, 24 Jun 2025 20:59:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024084.1400117; Tue, 24 Jun 2025 20:59:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUAjU-0001ri-85; Tue, 24 Jun 2025 20:59:08 +0000
Received: by outflank-mailman (input) for mailman id 1024084;
 Tue, 24 Jun 2025 20:59: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 1uUAjT-0001rc-MB
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 20:59:07 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on20619.outbound.protection.outlook.com
 [2a01:111:f403:2407::619])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1013d33c-513e-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 22:59:05 +0200 (CEST)
Received: from MW4PR03CA0089.namprd03.prod.outlook.com (2603:10b6:303:b6::34)
 by SA5PPFA403A61D8.namprd12.prod.outlook.com
 (2603:10b6:80f:fc04::8da) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8678.27; Tue, 24 Jun
 2025 20:58:59 +0000
Received: from SJ1PEPF000023CF.namprd02.prod.outlook.com
 (2603:10b6:303:b6:cafe::f7) by MW4PR03CA0089.outlook.office365.com
 (2603:10b6:303:b6::34) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8857.29 via Frontend Transport; Tue,
 24 Jun 2025 20:58:59 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SJ1PEPF000023CF.mail.protection.outlook.com (10.167.244.11) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8880.14 via Frontend Transport; Tue, 24 Jun 2025 20:58:58 +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, 24 Jun
 2025 15:58:58 -0500
Received: from [172.29.43.193] (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 Jun 2025 15:58:57 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1013d33c-513e-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=mYezYZ5i7PGC+U98A5ZXgF6HR4uEFaYMrRhc5+E0t1vy5mccOFjj/7DiJiMYpmxMpcu53mbFOimtnSj2b8E/1b6Gr57WUfXWwZAPPzDuWOCU/BbtcWXf5K/jvPul5AyBuq1K//Lu+bRlptxtsv8a1LF3Q2VZ4BQapNfVa6Bdewc0Sh+ZSvpuj2R6i3/zq6l8ZZ9D6z2O0E0cONOta3B58ivF81FaVtfaFWpeazP9YFSc+erSrRfGVU16nVBE8kiPFHjY98nWWexXL3ZbDH+SiyLD4mOWqIF5V7NhWmOvNE8GL3ZMosfnpiAcPhhT6zmiIKNYjK3nXawOxquTuIS1eA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=6RO44iSbQZHsEat2MA7ef/QCZoLfnm7fnQZeluYpsxw=;
 b=B8KxRWFZfdhWV3nWWm6k99WL4zgtTBsCqbthzXL8yE+ngvfgLty/yyI+Q9s+iEuBR1xJw8RpF9yGcCpma7ewiEl9Z6uNRB+bT4oGQKa41EHvfGZTOQ88Eqx4HcRKHFrliV7RJ40vh8NwOep9u8QNbOS7R+ndTKawb29ic0JlhjGND2/TLPagzmTaQLyHyPPtAc07WXv/DyKeac3i50cnznjLQaelbmI0jzdKAROry/hdUgZf6Ovgh/0Jmh/uNnvN4fNOZ0fpU3OSOteEt0WD37ZW8w4jEhVNWviSdz2CpQXeJBGMQSCZTScYrsPxXQ70N/NgUEYxrZsf4OIBPNdDxQ==
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=6RO44iSbQZHsEat2MA7ef/QCZoLfnm7fnQZeluYpsxw=;
 b=Mxvhc9/G2WF4VlmT6ZORuuLGpHEv+Np2f9Jw20GCdY7YDA9XX5eeww29x8FA2Q2CRbFi5PvFL9U4SaJXt+GfWg4POU5KdwcSPh1jgHtRgqjgjjD1L3lNMTBb4OkpPeLheBRb3e0CRbH1zP3Cr0077AGNvqsxxY2jXu7GTjCQDAM=
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: <1271f390-2697-4db2-b9a4-735e34bef521@amd.com>
Date: Tue, 24 Jun 2025 16:58:59 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 4/7] x86: re-work memcpy()
To: Jan Beulich , "xen-devel@lists.xenproject.org"
	
CC: Andrew Cooper ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: 
 <991c9caf-c7b6-4e1f-9855-5b2930b7989c@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <991c9caf-c7b6-4e1f-9855-5b2930b7989c@suse.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: SJ1PEPF000023CF:EE_|SA5PPFA403A61D8:EE_
X-MS-Office365-Filtering-Correlation-Id: fece4e9d-720a-4aff-bae0-08ddb361f0d6
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|82310400026|36860700013|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?NTFKeGl1REJrSkp3QVROTmRrSC9jWk1NYjFWTzdPdW8wRjNjQ3dBcWxmT01P?=
 =?utf-8?B?bjc0UnpSSzNvcGJkTGxpR3FaZ1FHaGJCaW9GTy83ZGt1UnZrNVF0MUlIeHVI?=
 =?utf-8?B?RWhrU0tDWE03ZFdkTGRtdlVOOG81RWZFTEZVR3hJVlpQTk9sVkczbVRFZUho?=
 =?utf-8?B?dFhHZ210Yk5kSFR0ZWthYngxdzNGdml5d2VUdURhMldsV3gzZUljT0xlWlVx?=
 =?utf-8?B?MGRVVXAycTMzNmtwYitTME51OXJKYnJRUEdKSzZuODZJcWdVdnZLMVlEU09V?=
 =?utf-8?B?Y0dPQ0FGQVZmdnBhRXRGNldLYzhTMkJEUzdUVjBsYzhkbm5pSjV1Q0ZXWnJP?=
 =?utf-8?B?ZjFRRytXbVFjSnc0MERublVRcDNmbU1OYWVxMVBQTVhNUzJXMlI0YlNSb1pR?=
 =?utf-8?B?OWt6cmdrQWlBZUkzSUYza2pLeURaVjRnMktvckhIcEgyUm5vU3JZM29GRnJ6?=
 =?utf-8?B?RUw0TURVOHZ1YWt1eCtmVDhwQjc5VWt6cDlYWm55WGkyZlZHZ1N3RmgxcGtK?=
 =?utf-8?B?aWhBaStucmRwVWw0RXJ3UlRZdEt4cU5LYmgzSFlpRmRBWjlwbk9iNG4xczVm?=
 =?utf-8?B?Z1U5ODlPanJLRTFxdk1TRENWNWp5Mmd2MXQwcTI3eUZSdEFOUUJrcVFXbWNi?=
 =?utf-8?B?emdHdGJoMG5VbmZTUzZUSE5RblVyV0xzQmMxaWJVL25hSXd1NTRLYURpbnFE?=
 =?utf-8?B?bGc5RGFvMkVXczdJdVFoNnREdjJGa2l6S2duWGM2cVhjcDI0MjdBT2NLcDNv?=
 =?utf-8?B?amtvcjQvc2I5QnlPZkphREVnQmRPVWpTb1BabURmNGVvbzZQT0JxejFoQVM3?=
 =?utf-8?B?K2pvdy94QnpoRnp0SDVjdXNQMytMY095blM2UHlNa3VZc2tmOG9qM1k4ZU9M?=
 =?utf-8?B?KzBabGhxR2NrM3NZTjJyZndadXdkTWRPd2Z5Vml6UUxHcE1CRjgzQUNuZUlY?=
 =?utf-8?B?ZWpTVElBR0FiMHVxK1RSclhXWnU1R1RjNjJBeFVsRi9mL0VYN2lKSEV0dEhk?=
 =?utf-8?B?ckwvbkJzbTFBTEZsMStEamtXWTE0bndyeStuajZvRFBwdm5McGY5R1VaTVpL?=
 =?utf-8?B?bUtFSDdyNk1WbzVMd3dZeS9WamxPOFJNc0J2Mmd6d1J4djQxajJrM3pKb1NZ?=
 =?utf-8?B?WU4wdnN5eTZUNTBwUmZmczh1YXhhdXlFZkxXdWc5dkpSZ0Y3S0hVNVJrUUhB?=
 =?utf-8?B?L3JaL3phVmZ3dEt1VmF2RytxSDl3RDV5amt4NVp0UDA2WTRxTmF5b0RUTzMr?=
 =?utf-8?B?UStXYVlrak04R1JkbjVGWUZ3VUVHc2NtQ1FUWFdpbWs5SElJQjVhNXROSDJW?=
 =?utf-8?B?SVhsT2VmM2lZdWhaZklBRkhJcnNhQXhiWm5RNzdKU0NIRHdRZ3RsZGZUUHF4?=
 =?utf-8?B?ZFM3YkUrRGU4V0QxSUZnWlpSOTRQQkIwSXQ1WitrVVpCTlRtYUdFcmlTZmtL?=
 =?utf-8?B?SU5zZ2tWVnkwTm9ZczFiWGhVaUpZa3Nnb2loU0x2NGtkbWlEVGp4bnByQlY3?=
 =?utf-8?B?QUlTcTgxQjgxWldoN3FpMUw5VTRKQmRVQlFXZkdEa1V3Q1pqSi9mVldEZDFF?=
 =?utf-8?B?d2pGT002RW9pNkFJK2d1b3Q0VWdVS2RYWWpjeUIxL3hjUWhwWVBsN0Rnazhr?=
 =?utf-8?B?cXRJYzJub2NCWlVKUE54QmVzcXJkdHRnSWFnSWxLOUlYSmpJd0k5eCs2cDRW?=
 =?utf-8?B?eFhScnFXcWlTWUpkZHNoL2h5NVkvN1BaQ0VrZHFEL1VQUWsvS2R5c0c5SE5u?=
 =?utf-8?B?NTBwSFFCRGVyVFBGS2t2VjJNOWV6YWY3ZTBkcW9mSUJXQTM4VGhIZFZyVTJy?=
 =?utf-8?B?K2ljeGR1TlZzWm1BUGdrSlNkcDRZL09vNG9XYXFBZ1ovRjhVbUY4eG9aZFRy?=
 =?utf-8?B?Q0VYamh4UHdzSFFrQ3o5TThiQ1RCMk1ZeUQxMXVlUTRCalRZTHhHcnFDZWV2?=
 =?utf-8?B?YjljS2hvRnpxczZlelloQWJEVjlnSzV0dnFJNUVGN3NabE9JUW15OHhGNkRR?=
 =?utf-8?B?OFVtUEVjYW9JVDF3ZzhId1Qra3dsSXovVXJCakQ5OEU5ZnRtbldkSkZYbzdJ?=
 =?utf-8?Q?u9r1vL?=
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)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jun 2025 20:58:58.8932
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: fece4e9d-720a-4aff-bae0-08ddb361f0d6
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:
	SJ1PEPF000023CF.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA5PPFA403A61D8

On 2025-06-16 09:00, Jan Beulich wrote:
> Move the function to its own assembly file. Having it in C just for the
> entire body to be an asm() isn't really helpful. Then have two flavors:
> A "basic" version using qword steps for the bulk of the operation, and an
> ERMS version for modern hardware, to be substituted in via alternatives
> patching.
> 
> Alternatives patching, however, requires an extra precaution: It uses
> memcpy() itself, and hence the function may patch itself. Luckily the
> patched-in code only replaces the prolog of the original function. Make
> sure this remains this way.
> 
> Signed-off-by: Jan Beulich 
> Reviewed-by: Teddy Astie 

> --- /dev/null
> +++ b/xen/arch/x86/memcpy.S
> @@ -0,0 +1,20 @@
> +#include 
> +
> +FUNC(memcpy)
> +        mov     %rdx, %rcx
> +        mov     %rdi, %rax
> +        /*
> +         * We need to be careful here: memcpy() is involved in alternatives
> +         * patching, so the code doing the actual copying (i.e. past setting
> +         * up registers) may not be subject to patching (unless further
> +         * precautions were taken).
> +         */

I think this phrasing is a little clearer:

We need to be careful here: memcpy() is involved in alternatives 
patching.  Define the original code as only the register setup.  The 
code doing the actual copying (i.e. past setting up registers) is not 
subject to patching, which avoids it changing underneath the processor.

Your comment is okay if you prefer not to change it:

Reviewed-by: Jason Andryuk 

Regards,
Jason

> +        ALTERNATIVE "and $7, %edx; shr $3, %rcx", \
> +                    STR(rep movsb; RET), X86_FEATURE_ERMS
> +        rep movsq
> +        or      %edx, %ecx
> +        jz      1f
> +        rep movsb
> +1:
> +        RET
> +END(memcpy)


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 21:00:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 21:00:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024094.1400129 (Exim 4.92)
	(envelope-from )
	id 1uUAkS-0003Ng-ON; Tue, 24 Jun 2025 21:00:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024094.1400129; Tue, 24 Jun 2025 21:00: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 1uUAkS-0003NZ-KQ; Tue, 24 Jun 2025 21:00:08 +0000
Received: by outflank-mailman (input) for mailman id 1024094;
 Tue, 24 Jun 2025 21:00: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 1uUAkR-0001rc-U0
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 21:00:07 +0000
Received: from NAM04-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam04on20624.outbound.protection.outlook.com
 [2a01:111:f403:2409::624])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 34483e89-513e-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 23:00:06 +0200 (CEST)
Received: from SJ0PR03CA0220.namprd03.prod.outlook.com (2603:10b6:a03:39f::15)
 by MW4PR12MB7142.namprd12.prod.outlook.com (2603:10b6:303:220::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.22; Tue, 24 Jun
 2025 21:00:01 +0000
Received: from SJ1PEPF000023CD.namprd02.prod.outlook.com
 (2603:10b6:a03:39f:cafe::90) by SJ0PR03CA0220.outlook.office365.com
 (2603:10b6:a03:39f::15) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8857.30 via Frontend Transport; Tue,
 24 Jun 2025 21:00:01 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SJ1PEPF000023CD.mail.protection.outlook.com (10.167.244.8) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8880.14 via Frontend Transport; Tue, 24 Jun 2025 21:00:00 +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; Tue, 24 Jun
 2025 16:00:00 -0500
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; Tue, 24 Jun
 2025 15:59:59 -0500
Received: from [172.29.43.193] (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 Jun 2025 15:59:59 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 34483e89-513e-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=MaDYHQtcdwDInOO8yTpbxE8fJJhGgELhOdZZnMWlaePjdxndXH6wp70s67WrJRWTc5fMHaH/dnWaipXPc46pk1YULm5QiasE+CDC3pA6i4zjZvCpRfkVh5DSM3+0/8Fuwhu8vjGidZjIPCiKsqXqtIA/qmnePFXsplJrHNRxzW/pTvzqrIqhBOcYB+pTd2ecMckGck/aN2Ni59EMBuHGX3EYDliTtai1zcu1j6U2jF9r3m+1sTIb+LUknenqeEALcCTOitaQba8lryqfFTHJ4xC19JFbtK/uX65/gZ5AEkuIkw9enMefoFNZDGhZGiAHrrb1KkFbwt2dZOc4ch0BOw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=s3uEL0VfP8gxDc1pnTVaS5liZ4SfDSVgPX7sBd+vu68=;
 b=Z2S6w5ULcMSqxnT3aohSSpM3rDzXSFmOCa4itMYty3/IDL42MpbxB3Axdoaxt44x4LTxployuss2GiyVkDb6Zug2x2s1z9lYh1qJFDooyxwj0YicRf7BC86v+03GfdyUyshzMFpRKmUgrXUvu5FtC1Vc7jiXKKz5a4yf5bv0Ub2lTEzsVUQ6avvTqvlnly0xqprGzMm9RrH0pa87bc9OVkerBFaO/2+XQIW0caWGzkc9f685YK0/j1m6hrZmnSKU8ByIr7w2ZQFCKDacXuywT+Zc4KnrsRoZETYJ4m+2CDWv8o54qNxzB7ABhBTtgly5EkCGL88gWXmtrMVa756QOQ==
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=s3uEL0VfP8gxDc1pnTVaS5liZ4SfDSVgPX7sBd+vu68=;
 b=wJ1Pf7E9dp39gfdYV+jtH2otwmwG2esiJcIQCD88Z7SxREwz3h4VfDdcT1qBz8C6Hotuo2lxfV6J4N758/6z/gwJWu8EoLsdnJyWRrM45FnQbPRATotj9waR1UFkB2RDw7Fqk0F+fB+Z29nWfrVwvko4+2wsf2yMnCTjKjLil3I=
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: <222702e3-d525-46fa-8ae5-45f3c184b9f8@amd.com>
Date: Tue, 24 Jun 2025 17:00:01 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 5/7] x86: control memset() and memcpy() inlining
To: Jan Beulich , "xen-devel@lists.xenproject.org"
	
CC: Andrew Cooper ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: 
 
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 (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF000023CD:EE_|MW4PR12MB7142:EE_
X-MS-Office365-Filtering-Correlation-Id: cae5e0d3-6e49-4bc0-ca77-08ddb36215c2
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?dmRjUVdMbXNUR1pWbXc2M01vc0ZIcHloVC92VUNrM3FGUG13VnZPS2p5Lzd5?=
 =?utf-8?B?U1l1NjVxZzlYazVTS2JKZHN3ZHc1bktoZkswdTdhTDlzNU8xVnVYMm4rVEFB?=
 =?utf-8?B?eGFUK0daYjV2Z29admQrMFMwY3B6cCtqbFNacHdzT3lodm1YQ3luUWlpQmxu?=
 =?utf-8?B?cDhwS1lVWURYbjVjRjNMZDFEWkp6NkVzS1lzQTBiOWZXL2tzME16VmluODNM?=
 =?utf-8?B?VnFYakMvcERjRlBqQ1htRzVwQXk2RGdiYTd6NTVvY05XREtwQlZqTHBaSU15?=
 =?utf-8?B?RUpBaTdmQW5JZDlnWUY2dVNVZ3N2SnV1Tys2UDJXd2Z4WnhlamQvSEVPcjZk?=
 =?utf-8?B?SFlPakNGVjVQbDVUQWlqY0lCdXZZVGdMTXlBQXY2c2NhK0tGMHJRclMwd01l?=
 =?utf-8?B?TUQ2c2ZKVGxZWVplcjBOMDN1VHcwa2hRSUpBbSswaGMyMEZ4ODBhZ1hkYjFI?=
 =?utf-8?B?MWRSeEI5elozZndNK2krRTBkZzVKWVZrYzI5a3V5VlNGcXB5MDF4cDdpbUhU?=
 =?utf-8?B?MlUzbGc0a2M0cGtldEtzQTJEOHU4K29pbkpicCtQbG5pTGhxMWhweldIWjh1?=
 =?utf-8?B?OFl6Rmo4QmFkdm1FZmM0cmJNNFdXN0E3bUtqUDhjR0Y4dVF3Z0xxOER6NmhG?=
 =?utf-8?B?QTl1WGZvQ2NUQ2xvWlF0TmFMVitsSEs0eUovUDhzMTZRRTZDb3N5OXpSeXVs?=
 =?utf-8?B?bVYrMTVXdjZQaWhoK1pCQjh6SUxBUHZMSmRFTkxKZmtUNzVrWHIyQzA4RkpZ?=
 =?utf-8?B?b3hBR2U5Tld1Y1BhZXNhdk1JM3R5WVZReXBOU3diRXZBdlJwUjg5RU55a2FP?=
 =?utf-8?B?eUE4ekt0ZTlSOVZNMWJ4MjlOUmhIZzBMUnA5akdMM1NWcEttMHRLdmxsSlFj?=
 =?utf-8?B?eUZOMGNWVmVUUkRCTmNSU2duYWlockYvUUpFcE9MYlhiaGszRGRVT3NsU3Nu?=
 =?utf-8?B?OXFBS1RsZjUrN3I4eFQyeTB5ci92T2dZSjNDLzduZWJiVU9XZkdEc0UrMjVi?=
 =?utf-8?B?NzExeVdLeEVTNURuUlJCQnZ2YzJmdHIvUmlOY05TNjZaRnY4Zzh2T21lU0tU?=
 =?utf-8?B?YnVFZE1xMTJMVTZEVjFuS2hLMFNWbHRXaW11cDcvUlJzK0l1YzVEOEx1S3BQ?=
 =?utf-8?B?Nm1aL0pRZGcxcTFVc21DNFVsQmtISzQ3dzdmRmtzb294UGNjZXdoWnBYbVUw?=
 =?utf-8?B?Zk1IalBIb29QSllnUXNZUDdOZ1lpbVV6Qm9sc3B0UUZuT3NDb2tHL3VycGta?=
 =?utf-8?B?aGRJdTRFTzVkNTRqRGlGK1NSc3JjakgwRlU5RFlIRTd4ZTNDQU1DaGNoYVc5?=
 =?utf-8?B?ZTdBc1dYK1VUOVBYeHNXQ285c2RuQkE3RW9yTGV5ZGEzQVNIK1BJT2pFTEx4?=
 =?utf-8?B?ODlYek1vL2h6WER5cFZodXRDWTc3aUhPcHpvYkpNRzhzUmFraGx3YXoxa3ZY?=
 =?utf-8?B?d2p5bzl1bXFycEdiZWZIcVQyZ2gvQUxGdVRGWWxtc1VZWEpiS2xqS0NBOXRa?=
 =?utf-8?B?UWJDSXpyb0o2c2RTdHFZR3RBUDNMeWhaL2hUcHdYblNzWGg3RnFlVnVSNDV3?=
 =?utf-8?B?S0poV0JQREZRa0xRZlBVRjM4cUVqUUtkckZKc2NUU051WDJjWEVlekN1MnBk?=
 =?utf-8?B?eEVwbEdsWHNGdXNuVElkK2Z4ZEZFeUxpcVBZVElZVDdzQ09QYWhvYllHTm4z?=
 =?utf-8?B?c25FWGptMEFTQkc5S0IyZm5ZTHJZQ1oxNGZqN3VzTGoxTUlXeUhpVXJXL25R?=
 =?utf-8?B?ZzNYdXFmRmVhUU9Hd0ZsaHcrY1FQd09GZlBoMWp4eExnQnZTKys4VXRmdS8r?=
 =?utf-8?B?ejZTNlBlOWUrY3k2OFkxaGJ0WnRpbVJRYTFnOEp1YlB0MzFPT0Y1WW9qczFu?=
 =?utf-8?B?d1pFemRRbXJsMlNiOG1NMFBCbnlxYjN0MW9aOTRsQVdjYlpRWW9GNUQ3cWFR?=
 =?utf-8?B?MVd5SS81WXROcS9zdnUrbjcyaG9EYklnVmc1Z2MySHcrWkoyUDFlM0FXeEdP?=
 =?utf-8?B?M3JES1VaYjBpd1RlQlFEamlLdkJmb2JBT0svSFZ4SzNKU1NUZDFRcytPMFRE?=
 =?utf-8?Q?TvTK3P?=
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: 24 Jun 2025 21:00:00.8373
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: cae5e0d3-6e49-4bc0-ca77-08ddb36215c2
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:
	SJ1PEPF000023CD.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB7142

On 2025-06-16 09:01, Jan Beulich wrote:
> Stop the compiler from inlining non-trivial memset() and memcpy() (for
> memset() see e.g. map_vcpu_info() or kimage_load_segments() for
> examples). This way we even keep the compiler from using REP STOSQ /
> REP MOVSQ when we'd prefer REP STOSB / REP MOVSB (when ERMS is
> available).
> 
> With gcc10 this yields a modest .text size reduction (release build) of
> around 2k.
> 
> Unfortunately these options aren't understood by the clang versions I
> have readily available for testing with; I'm unaware of equivalents.
> 
> Note also that using cc-option-add is not an option here, or at least I
> couldn't make things work with it (in case the option was not supported
> by the compiler): The embedded comma in the option looks to be getting
> in the way.
> 
> Requested-by: Andrew Cooper 
> Signed-off-by: Jan Beulich 

Reviewed-by: Jason Andryuk 


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 21:01:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 21:01:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024102.1400137 (Exim 4.92)
	(envelope-from )
	id 1uUAli-000403-0o; Tue, 24 Jun 2025 21:01:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024102.1400137; Tue, 24 Jun 2025 21: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 1uUAlh-0003zw-UN; Tue, 24 Jun 2025 21:01:25 +0000
Received: by outflank-mailman (input) for mailman id 1024102;
 Tue, 24 Jun 2025 21:01: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 1uUAlg-0003zm-BQ
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 21:01:24 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20607.outbound.protection.outlook.com
 [2a01:111:f403:2418::607])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6191eef7-513e-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 23:01:22 +0200 (CEST)
Received: from CH0PR03CA0077.namprd03.prod.outlook.com (2603:10b6:610:cc::22)
 by SJ2PR12MB8928.namprd12.prod.outlook.com (2603:10b6:a03:53e::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.29; Tue, 24 Jun
 2025 21:01:17 +0000
Received: from CH2PEPF0000013E.namprd02.prod.outlook.com
 (2603:10b6:610:cc:cafe::71) by CH0PR03CA0077.outlook.office365.com
 (2603:10b6:610:cc::22) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8857.30 via Frontend Transport; Tue,
 24 Jun 2025 21:01:16 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH2PEPF0000013E.mail.protection.outlook.com (10.167.244.70) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8880.14 via Frontend Transport; Tue, 24 Jun 2025 21:01:16 +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; Tue, 24 Jun
 2025 16:01:16 -0500
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; Tue, 24 Jun
 2025 16:01:16 -0500
Received: from [172.29.43.193] (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 Jun 2025 16:01:15 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6191eef7-513e-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=DMggrWFMB/6yZ54zXbfVAP4EbVE9bFMK7P6dNtWuOT2Fp11hcA7uesmSO1pBWv1Ap3LrX7plCwizTd+IBZYdE4CAE3r1kNG+VTynL9fcnM3mchVSJr4KAHbGUwJO7VVkozuq9egqOdmBeD63e2PRLNKAZ6ICmtR/QGbFOlSCwVievIZ6UzmQ9n3qHM3yX21HxVnXQTddqK1MKhYYC3+WAbWanB+niTv52Q38tq7hFVHgJ4XKD2uATATzEAakFbfyfEarpMXRbBQNNZkFHlZLVui7FQ/dPe+9XhrfMcQ2uAM6WpbnxQZ+xSABnkTeSiJW3xpnbuxJJ/XZi0nsFhikKw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=kO8bfoNMbPfdf3VI464ZG31w3hQoectP0oDqSm6OO2I=;
 b=B+C2G4pzZz5cd/mf4nXYPC3HFKmX8XxxZTFRlGjsq4eZJxsObHbTFLhDjdlZS1pizju8KY9fkIbdk6+8dP0ffdmzzZkuFDymtCth0O6Z8nzPGO6IPUNnMP+YQSrnmg1uBXE2L6w2tCSBxSEjbrh7feb1sh0lt4/rcnm/vZyCgNTCGktHfNUCs39BOZ7YdB1iLqVyqsr0PEnr2P551ujXoU/RWr9KNmzTVa729+4sGCt3IiOLTLbNel6Lsfefdc8h+1mIMxYb+9pXGfQSFBixjyJuibYG7RRAcMXsnB2e02toJcGj3DYyhv0RG9vfEYblnxv+J30R8reIHHaA0NM6jA==
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=kO8bfoNMbPfdf3VI464ZG31w3hQoectP0oDqSm6OO2I=;
 b=47z4I58ipGiUT3g7yVkYvSMXHK7xwu5awiSekaDK994AhWF2ATkWPOMcfps6fly8hmkaWMRyIQZ0Pto9UbzipKa6IumgE3/6W87IdQGSN/UtgYcJ1eH+paHxASnZen6pKcvoA/9It7U5eSmRRPTyACxLmXV5J7n7GUftwYGv7Ik=
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, 24 Jun 2025 17:01:17 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 6/7] x86: introduce "hot" and "cold" page clearing
 functions
To: Jan Beulich , "xen-devel@lists.xenproject.org"
	
CC: Andrew Cooper ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: 
 
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 (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PEPF0000013E:EE_|SJ2PR12MB8928:EE_
X-MS-Office365-Filtering-Correlation-Id: 5e208b29-a9a7-438f-3d76-08ddb36242e5
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?UmVQbHFyelBnTWtHdGJaajVWbjFaU094aFQyY0ppQ25rZm9GZzhDN1VPaWRF?=
 =?utf-8?B?ZkVBY1V3Snp2ZmJxMno0SG51akN4aE9tMkZaVHd3WFpKTHpXRGp1QmtMb2xm?=
 =?utf-8?B?bDBCVStwMERpTDAvdHMzdEM5MGNVM2dxQjR1OFAzY2Zmb0ZlSk9KZXVDTWt1?=
 =?utf-8?B?dGhQeTBmOG5SYVRheENJM0FhRlFFbFZDRmVqb0dLWHlFVjQxcU9uN2JiODg3?=
 =?utf-8?B?alVQTEY3UUQvVnNQcGNXTXFNaHRWT0VKTjFDdUZIZTBadTVER0NidU1xa2pY?=
 =?utf-8?B?QkdLQkJSSUZLZXR1eGhaemFTQ0hzU1RJYVlXeTc3aERUWGt1N1NtQmZTOUJD?=
 =?utf-8?B?eTRrMElDajVuWTRyalBmZWRkeFFXeHZLdmFjUmVEYktoRkEyQzFRc3pqY0NB?=
 =?utf-8?B?QjBqQkFYbVFHNXhyVy91cnovbUVWSHN1ZlNPQTgrNHlZc0FDRmYvWWpTaXRX?=
 =?utf-8?B?QTB1dmpQbHdsejB2M0lCakdQeVh1S0NyOWltc01nZTFXRHJMSENCbCtMTXBC?=
 =?utf-8?B?U0JLMzg0R3R0RXB6YU1JSFZscllXb3I0cU1qTzVPQjdZdDV2VlFTelA0V0lI?=
 =?utf-8?B?NUdGK0puUkgzTGNDZnhWMkR0L0tIRHJBblFvZmJUZjJ1TEVXMmZiQlpDanBM?=
 =?utf-8?B?WXUrc0FEWkF6ZW5xcDNVd3ZQNHRsa3lndnVuSGhKYnhKL3JDeVUyckF4Q29P?=
 =?utf-8?B?K0pCalpnWU5hM0ZPaUF1cHIrSSs1S3M0K0hNUExxL3crelBkZXZGR1hRdjVK?=
 =?utf-8?B?bUVzbWRlb0k4OStkdVBEMUxqYW9ZR2RVeUNPWjFwTUxFOUtrVEZZTFV1ZDBq?=
 =?utf-8?B?KzhyS1pveXdMWStoNXM0ckZicDUxWmllQTV0OFlGbW1Rb1dvcnVJWGFQSFdV?=
 =?utf-8?B?U3kzUjFxSGlZMkJlOFY3NWNTU3FkeEkyVlZMaEdnVk5hNThRQnNFeU90WVQ2?=
 =?utf-8?B?c1dMUVI5R3Z5VmJ5bThwRkNSVmIwR1N5amx2WTJKa1JNRUZmTERQb1F6TzBz?=
 =?utf-8?B?ZlRoRC9hOTg1SnlRNkk2c0VvSzJ4VG5jdFROUHNTb2Vkb29veTkwMVBJcUVC?=
 =?utf-8?B?TnF0MkFPc1JZQWhOYUJHM25mTmFlZ2Q2UmdYeWJWUmMra2ZRKzFObHZqOGRH?=
 =?utf-8?B?dWVxM29pRDJVM2Ztcm1mQXluTExRUEg2MUJidXFlYm9mVVNMcDEzdXk1ZkV0?=
 =?utf-8?B?Sm80czErTS9HdTVidjR4TFpGSW1GZENIRG02NHkyYzJTN0V4VlRDT3ppZUVv?=
 =?utf-8?B?TlhWQ3lNbWU1K0t0TExjVlNNY08yU3BkU1YxVytXZXpkM2FkcG94YlRTUEVY?=
 =?utf-8?B?OHBBVWNkN0dxeHFHU2QwamtLZkRZSWlzWUxXWWlYaW1hTE1NOFNva0V5R1dy?=
 =?utf-8?B?a1Ywb2I4d1NBV2JYL0Qyb0dWZzhoZ1RoaWlpb1IyU0tiZ3plQ3cxVXJQeHY3?=
 =?utf-8?B?VGlOSHB6Y08rQktaL1NyQlRuMk9mcHFCTVpHS1oxVFoyaXlKTlBBRHpKbVo3?=
 =?utf-8?B?b0liM0JPTmdSbDI0cjJjRys3d0ZBL1F2Qm9qbGExeG0xekh5K1M5VTlGZWdN?=
 =?utf-8?B?c3FFZldIU2Y4OHlRNlZsSnl0UUdZWFhXRk10SzZqT00wYzRWbmFCTDlMenA4?=
 =?utf-8?B?WXNCRk1UU1lMZUcxYkFFc3JZbTZZU21SVTZ2dHNGNC80bVlUV1psZjVnb2lU?=
 =?utf-8?B?QktGZnhNN1VSb3lKSGMxSkFYcEJxeCt0OU16bXg2RHBUS1BkUU1YaHIxMGMy?=
 =?utf-8?B?ZXBzZkluYUJySHpwL3V1MUYzanlXL3ZPWkNob3lucUZkdXY4eWl3MkFpb1E1?=
 =?utf-8?B?eUZyV0E1NmI0UXlkV2pkN0c4SW5mcmYxQlJlTDRzUFFoWXJOUkJWWE5id2p4?=
 =?utf-8?B?Q1pHVzlHY2RKM2tYUWZvNmxFZko5S3VzQXRHb2pBNldiLzZCMXVRVmFNcjZR?=
 =?utf-8?B?bHRsTFFMK0o5dkVSVzMvdnlwcjVhaGF3ZGNHTVlDZXVpVlJhNjhiOElIazFy?=
 =?utf-8?B?b0RjdHY3bjZQQlRaZDFrUjYxWmR2UW0ra2Vqd0VPVnIwOVBSeFIyYTFJc2xq?=
 =?utf-8?Q?tM5jnu?=
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: 24 Jun 2025 21:01:16.6350
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5e208b29-a9a7-438f-3d76-08ddb36242e5
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:
	CH2PEPF0000013E.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB8928

On 2025-06-16 09:01, Jan Beulich wrote:
> The present clear_page_sse2() is useful in case a page isn't going to
> get touched again soon, or if we want to limit churn on the caches.
> Amend it by alternatively using CLZERO, which has been found to be quite
> a bit faster on Zen2 hardware at least. Note that to use CLZERO, we need
> to know the cache line size, and hence a feature dependency on CLFLUSH
> gets introduced.
> 
> For cases where latency is the most important aspect, or when it is
> expected that sufficiently large parts of a page will get accessed again
> soon after the clearing, introduce a "hot" alternative. Again use
> alternatives patching to select between a "legacy" and an ERMS variant.
> 
> Don't switch any callers just yet - this will be the subject of
> subsequent changes.
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Jason Andryuk 


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 21:02:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 21:02:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024108.1400148 (Exim 4.92)
	(envelope-from )
	id 1uUAmo-0004Vn-9S; Tue, 24 Jun 2025 21:02:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024108.1400148; Tue, 24 Jun 2025 21: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 1uUAmo-0004Vg-6V; Tue, 24 Jun 2025 21:02:34 +0000
Received: by outflank-mailman (input) for mailman id 1024108;
 Tue, 24 Jun 2025 21: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 1uUAmm-0004VO-HE
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 21:02:32 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20604.outbound.protection.outlook.com
 [2a01:111:f403:2415::604])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8a765dc1-513e-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 23:02:30 +0200 (CEST)
Received: from CH0P221CA0048.NAMP221.PROD.OUTLOOK.COM (2603:10b6:610:11d::29)
 by DS0PR12MB6535.namprd12.prod.outlook.com (2603:10b6:8:c0::16) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.38; Tue, 24 Jun
 2025 21:02:25 +0000
Received: from CH2PEPF0000013B.namprd02.prod.outlook.com
 (2603:10b6:610:11d:cafe::b6) by CH0P221CA0048.outlook.office365.com
 (2603:10b6:610:11d::29) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8880.17 via Frontend Transport; Tue,
 24 Jun 2025 21:02:25 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH2PEPF0000013B.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.8880.14 via Frontend Transport; Tue, 24 Jun 2025 21:02:25 +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, 24 Jun
 2025 16:02:24 -0500
Received: from [172.29.43.193] (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 Jun 2025 16:02:23 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8a765dc1-513e-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=PtTR8jT9olP7XZKcro1VybMRLLMpq171X871OpRlFsVgADrgdOktkhp2tnVJpSpE2g/FLZlGhtelkwQ1NA/hZgxMBoGnR1tfw3gu3hzkqOZdegLF7jvVUb/scPJ0S9rAbt7y351HuvbQWYoO59hx8DOK6nzS1BobFXuOJPEJcok+VEtoyL1f2r5XF71r1g03Gb+ul8C0ZY8hSXKLxKbKs5dkG0QW9BkYHIUpbGmyNhB9y97RA6tunrB1wdcgGjZky/Haa5ZDxX+eDUZIruhKhKC5jpMaLhNPiK5wNFZEPjCZtj3wT/3VihOdd1Lb7WuHHpqsWUQUpXx1Db0IBMea2A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=iziTIulgBRL0iZ4VHL8f+gFBagH0ReS49NxaMmUA4fE=;
 b=KT8JfPotumlJOqq95uopYspqvzqmCUSxYVBKMo8rLUME1ZiYQ+nsq/YsbD7Pd7XO7TVAUydn3Rq0wIOK8friQsxz51bhOMGdF12MqLWEnzNffxttWRuWHPqaSWYE9Lep+QUD7RygCcNuWCCiuLX7D7lZ9u+tKWVGGaZnhccJy+N7kptGyBvIc+6ZgBRTRctUeqjX5WvAv6/xnRN2VuqcZb38zovvb+UTmSgUPnVDD1OoSKro1j777oJkgvD25iouH+ImgHSEVH+vt/3HPFtfqGVKIPW8m9bpA2mrdtTlYqFOkQdxlicG4b8q1MQVXEnxaMjpSwZOLP5s6YgU33mSNQ==
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=iziTIulgBRL0iZ4VHL8f+gFBagH0ReS49NxaMmUA4fE=;
 b=mj1C6CwUp5GtjUnHBYh6GVrqSii+zmMnDDdDSRVVywcsBC9sjb1yhl6ViQdMtOBpRjjQOfZdzOZL6OW8AOOWw5m9+9f/UuvV0apVZoHTY1GFhqqiGLM7GSZSkdWup5JNI5aVlAlj655yqVM3zxez4OyPsr4zuzqjH0KcXodj2FY=
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: <4845b3ec-7f08-432c-8d8c-eed611ba4a90@amd.com>
Date: Tue, 24 Jun 2025 17:02:25 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 7/7] mm: allow page scrubbing routine(s) to be arch
 controlled
To: Jan Beulich , "xen-devel@lists.xenproject.org"
	
CC: Andrew Cooper , Julien Grall ,
	Stefano Stabellini , Anthony PERARD
	, Michal Orzel ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Bertrand Marquis
	, Volodymyr Babchuk ,
	Oleksii Kurochko , Shawn Anastasio
	
References: 
 <0d2b44e3-bf6c-40ae-be4f-d0ad2845e925@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <0d2b44e3-bf6c-40ae-be4f-d0ad2845e925@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: CH2PEPF0000013B:EE_|DS0PR12MB6535:EE_
X-MS-Office365-Filtering-Correlation-Id: 7ebbec1d-0dfc-41d3-d05b-08ddb3626bae
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|7416014|82310400026|36860700013|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?dnRBZk82TExpWDVSUnBIcGE2SFZsbWpXUkNjRnFkQS9XRWxZTG5Rb2szekhk?=
 =?utf-8?B?UUlqbnE2ZnZsTkVQcFVYVGRRZC9sV3hXYnkzY3ZzRHNONzUvK1dneWRTc1Rn?=
 =?utf-8?B?SjdMaTBjaEpXR3o1M01uNnBBcXhxY2x2RHJtQlVySEZZMnBxUitJSm82YitI?=
 =?utf-8?B?S05GTWpYVzhMaGdHTHNyVUg0VDduRmFhRWR4aGgxck8vZzl5cWdJdmpaWFd6?=
 =?utf-8?B?YlpjeWJVR1M0RDBMUS9rZVIxWDRsYlZNRFhMUE5NUndnNzk3N3FIOXJQYlQ5?=
 =?utf-8?B?Tm1GV3FVMjY3SWNOZU9sT216SUdZa0c4MXIvOCtQSUttNytpYkxuUkZ3bEFI?=
 =?utf-8?B?bDhudXdyWkJsVnBtUW1pSmJoV29vamRFTk51SzZDbnNVbkhjdlY5aGw3S3Jy?=
 =?utf-8?B?a2haQXJGalNPd0FiMmtiMFlaNHUrUjZhamMxcGpyUWxJRnFBWUNPVFFoa0F2?=
 =?utf-8?B?aUZQNmZadmMxRWhaZnk2ZElTWGQ4THF6ODRDTU13VXNNMEtyZGlHYnZkMDdi?=
 =?utf-8?B?d3FwMnpGMFhMZDdadHJXME9nWUQ0c2hSbE1ka0xvTHA0dy9venpSSmQxcU13?=
 =?utf-8?B?OHBKQ2I4MTlRcHNDYkUzSzArb3JKQ3U4Q2NLdXZLQkZvaFE3SmtENU5JdVdL?=
 =?utf-8?B?eEYweFA5Y0NXY0NnWGlGTW12WklXN3BxWU1XeENBcnFDU1g4d0FBeE41M1Fp?=
 =?utf-8?B?QkdENjhCOWJiMWFJd1NUZDhqVFdiTUQxZDFCOU91M0ErdkN4QitkdWdqT2Nh?=
 =?utf-8?B?TUlwOXRBbnZIVkdKUU4yYnFkMlZObUkrM1QyOWVTWGJlYjlvNmpwVnVKZzFM?=
 =?utf-8?B?RG5CMGhhK2taSERoSU9KTjNJWTVkS2lZTzMyck4xYjF5MEpSb2N5cHJlUytL?=
 =?utf-8?B?OFZuQmhleDhOU0tiZ3B1THRjeGkzb3lPOHZlZmpNSW41dm5naEQ4elV6NXly?=
 =?utf-8?B?a0gxRmtBekp4M2JQOHBnSGkydUFHWnpNdFhWbHdKTWJNMTV4NC9vYnpKcmdR?=
 =?utf-8?B?Z3IzUWdBSEYrYmVXV2FkRURDcWxha1ZMS2w4elVVa3VjZUdQT3htNVlzbm1N?=
 =?utf-8?B?aXRrS2tjbkdQUXhyQzFJOEdDKy9XOVZRa2FoelFjcHJvekpxd2JBM1NzVkZH?=
 =?utf-8?B?UmRXNUlUa25COThMTHNHUy95SFk0MElwTFphMkw5cStpY0JnTHozZHpnQ1R5?=
 =?utf-8?B?a0JvVXRjMlNaU3BFbm1EWjJGV2p4TnhJOVdZOW5TNXY5Mkpyaml4dmtmbWhN?=
 =?utf-8?B?eEYxRmZOSVB2bUZ0QlJxYUVjMHhVeUcyK2dQSGVmeXpPeU50RXY4QTZMUGJR?=
 =?utf-8?B?eGdSR0x1WExVdWRMcm1sVGJUVTNJTUJETDlvZ0IwbkJOeU9HSm52L09Xcms0?=
 =?utf-8?B?OVVka2E2aGwzMXdYbzM3b3U0NkxJVlIzSFZENlowZXl2QnoyMjVmUVlYMmQ5?=
 =?utf-8?B?Y3hCa0luM0pWZU5LMWlLbTQ5emV5WHB3RzJ3OXV5aEtZREFVQWtKaEtDdEJr?=
 =?utf-8?B?WjkySmpTbHVseE9Zb1k3azlWK1c3QlI2ZjNGWWk4RHF2UnpldFE3T1FHbjNJ?=
 =?utf-8?B?ZFE5VnVtU3htWFV6ZUtMWkNpckxrdkc5VUNYNEFiQmIxaGZNT1lZTDZDaXpB?=
 =?utf-8?B?RkhLcTFhdlJ5LzNJOUFzRk0rbnFIU0tDd1JVS0VmNndrVGxab090MWVrUWg1?=
 =?utf-8?B?dEwxcDNWajRqTndZYThxMnhDMlRGSDdyWVptQzVxdEVpSXdWbFhrQ3AzQmox?=
 =?utf-8?B?NHRVZ3JNRDM5M3Y5ZWc2ZDVoRVoyb1M0T0sxcVdvUkE1bjU5c1FrcXNwQmZZ?=
 =?utf-8?B?am5ZUWhXZG92UzBmYmQ3SGZadEFKbk42cWxoRUxUR2lxVC9sM2ozTEUzMGpM?=
 =?utf-8?B?b3MrcFYxNlM0ZkFieE0rVi94ek5wZjBCRjY1L0gwamZvVWJNZ3l2Vmw2RmNq?=
 =?utf-8?B?RXFpQWlSNFpYMk1CbzBXMnZ2bGxZSExqQTBVUkFZUXJXSkhDa0FHZ0R5eS9S?=
 =?utf-8?B?YlBENUpZcjJvRTMyWmlSNU8vN3JuZWFUKzBzbnFXQTlubE92SWcxT29hRFN1?=
 =?utf-8?Q?MxArZG?=
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)(7416014)(82310400026)(36860700013)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jun 2025 21:02:25.0747
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7ebbec1d-0dfc-41d3-d05b-08ddb3626bae
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:
	CH2PEPF0000013B.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB6535

On 2025-06-16 09:02, Jan Beulich wrote:
> Especially when dealing with large amounts of memory, memset() may not
> be very efficient; this can be bad enough that even for debug builds a
> custom function is warranted. We additionally want to distinguish "hot"
> and "cold" cases (with, as initial heuristic, "hot" being for any
> allocations a domain does for itself, assuming that in all other cases
> the page wouldn't be accessed [again] soon). The goal is for accesses
> of "cold" pages to not disturb caches (albeit finding a good balance
> between this and the higher latency looks to be difficult).
> 
> Keep the default fallback to clear_page_*() in common code; this may
> want to be revisited down the road.
> 
> Signed-off-by: Jan Beulich 
> Acked-by: Julien Grall 
> Reviewed-by: Oleksii Kurochko

Reviewed-by: Jason Andryuk 


From xen-devel-bounces@lists.xenproject.org Tue Jun 24 21:46:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 21:46:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024145.1400158 (Exim 4.92)
	(envelope-from )
	id 1uUBT8-0001cS-Bu; Tue, 24 Jun 2025 21:46:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024145.1400158; Tue, 24 Jun 2025 21:46: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 1uUBT8-0001cL-88; Tue, 24 Jun 2025 21:46:18 +0000
Received: by outflank-mailman (input) for mailman id 1024145;
 Tue, 24 Jun 2025 21:46: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 1uUBT5-0001bx-IM
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 21:46:16 +0000
Received: from mail-24418.protonmail.ch (mail-24418.protonmail.ch
 [109.224.244.18]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a53bb04b-5144-11f0-b894-0df219b8e170;
 Tue, 24 Jun 2025 23:46:12 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a53bb04b-5144-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=f7aaecxqerdwfoifvdrhwmc7iy.protonmail; t=1750801570; x=1751060770;
	bh=uUoXBx+WkAQjOqVzqs8bXZJ2hdmdHJy6BYnbKje2GKg=;
	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;
	b=Vj2VYCHaCOJ3Xp1siAwm/pnRPcU3Fo/XKsLC9VbEM7zDaTQO0v2rbyBAqTeJlt9w5
	 9IY0exJ/4DmbDEPOf/14ckUQrac76+VmxeNERMX2aNQIMFR+fcoiO4ESOFY0lKTt1b
	 0njj4WwMd6+KCL6dobTXfGVQ0xtpVLQ0lrU5tvjRFaYPReAKRgxdHGlbf+0CZXhlYB
	 M2QOzhGcKZX2BlCibG1XxwpkxcA6cGrk/pnxyfX40ENhIapTPR8/Q7Krb68r2+s25e
	 4dByCYgxW7NJKjpKulywA3GFT/Ffpaqgk+rzZ2Bic9pP8smzIKPvDMQ3AjzvMq+haE
	 wJ+5H+zyFMOEA==
Date: Tue, 24 Jun 2025 21:46:07 +0000
To: "Orzel, Michal" 
From: dmkhn@proton.me
Cc: Jan Beulich , andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org, oleksii.kurochko@gmail.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v1 04/16] arm/vpl011: use raw spin_lock_{irqrestore,irqsave}
Message-ID: 
In-Reply-To: <0cfc9465-90d5-46db-88a7-ed47d0809b60@amd.com>
References: <20250624035443.344099-1-dmukhin@ford.com> <20250624035443.344099-5-dmukhin@ford.com> <08cb7878-fad7-47f4-9c91-5f866c54b1df@suse.com> <0cfc9465-90d5-46db-88a7-ed47d0809b60@amd.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: ce6b5dcc0e2aef4cb8e481eb4a9d954992306d8e
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 24, 2025 at 09:50:54AM +0200, Orzel, Michal wrote:
>=20
>=20
> On 24/06/2025 07:46, Jan Beulich wrote:
> > On 24.06.2025 05:55, dmkhn@proton.me wrote:
> >> From: Denis Mukhin 
> >>
> >> Replace VPL011_{LOCK,UNLOCK} macros with raw spinlock calls to improve
> >> readability.
> >
> > I'm not an Arm maintainer, so I have limited say here, but: How is this
> > improving readability? It better utilizes available local variables, ye=
s,
> > so this may be a little bit of an optimization, but otherwise to me thi=
s
> > looks to rather hamper readability.
> I agree with Jan here. I don't think it improves readability, therefore I=
 don't
> think such change is needed.

I think exdanding macros helps to understand the code since is explicitly
shows what kind of locking *really* used, so this aspect is actually gettin=
g
more readable; yes, that's a bit of more text.

But, MMIO-based flavor does not define such helpers for example, so now vUA=
RTs
follow similar coding pattern which is easy to read/follow.

>=20
> ~Michal
>=20



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 21:56:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 21:56:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024151.1400167 (Exim 4.92)
	(envelope-from )
	id 1uUBd7-0003KG-6r; Tue, 24 Jun 2025 21:56:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024151.1400167; Tue, 24 Jun 2025 21:56:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUBd7-0003K9-42; Tue, 24 Jun 2025 21:56:37 +0000
Received: by outflank-mailman (input) for mailman id 1024151;
 Tue, 24 Jun 2025 21:56: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 1uUBd6-0003K3-NR
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 21:56:36 +0000
Received: from mail-24418.protonmail.ch (mail-24418.protonmail.ch
 [109.224.244.18]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 18c0a8c6-5146-11f0-a30f-13f23c93f187;
 Tue, 24 Jun 2025 23:56:35 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 18c0a8c6-5146-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1750802194; x=1751061394;
	bh=mzYTxXFIDk3ifXUaCRYvp8lsFAcbodVaahIFNCfLVfQ=;
	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;
	b=hptgjXimAW6+TedYonRPMILzVI3wY1HeZn2a3cbWKKphYpZFX9Pf/EXS2XiyV3bkN
	 oLAkkbkCXtplWRZ91rqrGq9EecJhFfGEgJl+MzGnHp+vwpU6bpN4BnlQcX7Xvn7m2v
	 5fumYXhJCACzyQ02olotc2Cw3MBuGxq4mfx6aSrTmD483QsnEYVLdezj2nvJkiiKoF
	 szQqHZXZoVMYJa6HwtPo7R0MCn3W6dFBKt6OIX2P4FkLmKQ7vZkKFsKiiW3N3BPaBZ
	 bhnfNmaJqlsRJEEg9C7QlK+T6erf4tIzFJWKJu6eTb7hmuBCw/jMLFLZvT8HpnGCv2
	 KUHvS+5onc+zQ==
Date: Tue, 24 Jun 2025 21:56:30 +0000
To: "Orzel, Michal" 
From: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, oleksii.kurochko@gmail.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: Re: [PATCH v1 02/16] arm/vpl011: move DT node parsing to PL011 emulator code
Message-ID: 
In-Reply-To: 
References: <20250624035443.344099-1-dmukhin@ford.com> <20250624035443.344099-3-dmukhin@ford.com> 
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 8767df20f3d77c07f604a503425281a7665f5384
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 24, 2025 at 09:49:39AM +0200, Orzel, Michal wrote:
>=20
>=20
> On 24/06/2025 05:55, dmkhn@proton.me wrote:
> > From: Denis Mukhin 
> >
> > Move vpl011 DT node parsing from common Arm code to PL011 emulator code=
.
> It's not parsing, it's DT node generation.

Oh, that's right, overlooked.
Thanks, will update.

>=20
> We usually keep all the DT node generation functions in one place. I'm no=
t sure
> if we want to move them to respective drivers (i.e. vpl011 to vpl011.c, g=
icv3 to
> gicv3.c, etc.). Not sure what other maintainers think.
>=20
> >
> > While doing it pick the generic name vuart_add_fwnode() for DT parser f=
unction
> What 'fw' stands for? Firmware? This function creates DT node for domU, s=
o it
> should better be sth like vuart_add_dt_node().

'fw' stands for 'firmware'.

It should be some generic name because the function will be used on x86 to
generate to generate the guest ACPI tables.

>=20
> ~Michal
>=20
>=20



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 22:18:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 22:18:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024158.1400177 (Exim 4.92)
	(envelope-from )
	id 1uUBy1-0006B7-SF; Tue, 24 Jun 2025 22:18:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024158.1400177; Tue, 24 Jun 2025 22: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 1uUBy1-0006B0-PJ; Tue, 24 Jun 2025 22:18:13 +0000
Received: by outflank-mailman (input) for mailman id 1024158;
 Tue, 24 Jun 2025 22:18: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 1uUBxz-0006Au-1z
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 22:18:12 +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 1756597b-5149-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 00:18:01 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1756597b-5149-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=ohpi6hxocbgyfgkikvprtbnmwa.protonmail; t=1750803480; x=1751062680;
	bh=V6io7CTkqeDWbh6RvldlLiRXAY5v70bWhoTL7mYz7uE=;
	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;
	b=i2YIviqOhyrkRjXycJTh8IzcH3sRQ/rFCVtfrTk+Hv8ds7J3nJoZdpY15kLAvsBNH
	 BqfzfnpeJHDL+8WGJP4MWlEpRK260qo2gHiP6RnYidPGDRQGFLYM6NaDoyNvgi5DLY
	 Y+9nGJGGUMW+pVjaIpq1xptTy6IhzT25R0c4C1TwCojfxHg2b6jIwuXpsyaA2oYhFn
	 T6W0HJVZko+arKE9iDgkhzewSwlrFviw0/5habyHl2wIsldjSN1oHxKmL6UVXFZfWk
	 QW96fl3z8HAUd7BREnAJa8xPhUgVviLbchfpn/L2QGaS1886zSm5FvJgAKxcb21NG8
	 0agFGZp21oaLQ==
Date: Tue, 24 Jun 2025 22:17:53 +0000
To: "Orzel, Michal" 
From: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, oleksii.kurochko@gmail.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: Re: [PATCH v1 03/16] arm/vpl011: use vuart_ prefix in vpl011 public calls
Message-ID: 
In-Reply-To: <8c35481f-6a2b-4579-9b34-c912cf3bbd14@amd.com>
References: <20250624035443.344099-1-dmukhin@ford.com> <20250624035443.344099-4-dmukhin@ford.com> <8c35481f-6a2b-4579-9b34-c912cf3bbd14@amd.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 7a1ad049282da2ee301df2a0fc54787e6b6a2ad5
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 24, 2025 at 12:11:10PM +0200, Orzel, Michal wrote:
>=20
>=20
> On 24/06/2025 05:55, dmkhn@proton.me wrote:
> > From: Denis Mukhin 
> >
> > Use generic names prefixed with 'vuart_' in public PL011 emulator data
> > structures and functions.
> >
> > No functional change intended.
> >
> > Signed-off-by: Denis Mukhin 
> > ---
> >  xen/arch/arm/dom0less-build.c     |  4 ++--
> >  xen/arch/arm/domain.c             |  3 ++-
> >  xen/arch/arm/domctl.c             | 14 +++++++------
> >  xen/arch/arm/include/asm/vpl011.h | 20 ------------------
> >  xen/arch/arm/vpl011.c             | 24 +++++++++++-----------
> >  xen/drivers/char/console.c        |  6 ++----
> >  xen/include/xen/vuart.h           | 34 ++++++++++++++++++++++++++++++-
> >  7 files changed, 59 insertions(+), 46 deletions(-)
> >
> > diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-buil=
d.c
> > index 7c1b59750fb5..11b8498d3b22 100644
> > --- a/xen/arch/arm/dom0less-build.c
> > +++ b/xen/arch/arm/dom0less-build.c
> > @@ -216,7 +216,7 @@ int __init init_vuart(struct domain *d, struct kern=
el_info *kinfo,
> As can be seen here ...
>=20
> >       */
> >      if ( kinfo->arch.vpl011 )
> >      {
> > -        rc =3D domain_vpl011_init(d, NULL);
> > +        rc =3D vuart_init(d, NULL);
> we end up with init_vuart() and vuart_init(). That's quite confusing. May=
be
> domain_vuart_init() or alike?

That's right!
But domain_vuart_init() is used by MMIO-based variant :)
I will write an extra patch and put it to the end of the series to update t=
he
name here.

>=20
> >          if ( rc < 0 )
> >              return rc;
> >      }
> > @@ -247,7 +247,7 @@ void __init arch_create_domUs(struct dt_device_node=
 *node,
> >           * d->arch.vpl011.irq. So the logic to find the vIRQ has to
> >           * be hardcoded.
> >           * The logic here shall be consistent with the one in
> > -         * domain_vpl011_init().
> > +         * vuart_init().
> >           */
> >          if ( flags & CDF_directmap )
> >          {
> > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> > index be58a23dd725..68297e619bad 100644
> > --- a/xen/arch/arm/domain.c
> > +++ b/xen/arch/arm/domain.c
> > @@ -11,6 +11,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include 
> >  #include 
> > @@ -1072,7 +1073,7 @@ int domain_relinquish_resources(struct domain *d)
> >           * Release the resources allocated for vpl011 which were
> >           * allocated via a DOMCTL call XEN_DOMCTL_vuart_op.
> >           */
> > -        domain_vpl011_deinit(d);
> > +        vuart_exit(d);
> IMO, deinit is more meaningful here.

Yeah, it's just MMIO UART uses init/free, here it is init/deinit.

So I just picked init/exit similar to module_{init,exit} in Linux driver mo=
del
and applied to all existing vUARTs.

Can update all vUARTs to deinit()

>=20
> >
> >  #ifdef CONFIG_IOREQ_SERVER
> >          ioreq_server_destroy_all(d);
> > diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
> > index ad914c915f81..dde25ceff6d0 100644
> > --- a/xen/arch/arm/domctl.c
> > +++ b/xen/arch/arm/domctl.c
> > @@ -14,6 +14,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >
> > @@ -30,10 +31,11 @@ static int handle_vuart_init(struct domain *d,
> >                               struct xen_domctl_vuart_op *vuart_op)
> >  {
> >      int rc;
> > -    struct vpl011_init_info info;
> > -
> > -    info.console_domid =3D vuart_op->console_domid;
> > -    info.gfn =3D _gfn(vuart_op->gfn);
> > +    struct vuart_params params =3D {
> > +        .console_domid =3D vuart_op->console_domid,
> > +        .gfn =3D _gfn(vuart_op->gfn),
> > +        .evtchn =3D 0,
> > +    };
> >
> >      if ( d->creation_finished )
> >          return -EPERM;
> > @@ -41,10 +43,10 @@ static int handle_vuart_init(struct domain *d,
> >      if ( vuart_op->type !=3D XEN_DOMCTL_VUART_TYPE_VPL011 )
> >          return -EOPNOTSUPP;
> >
> > -    rc =3D domain_vpl011_init(d, &info);
> > +    rc =3D vuart_init(d, ¶ms);
> >
> >      if ( !rc )
> > -        vuart_op->evtchn =3D info.evtchn;
> > +        vuart_op->evtchn =3D params.evtchn;
> >
> >      return rc;
> >  }
> > diff --git a/xen/arch/arm/include/asm/vpl011.h b/xen/arch/arm/include/a=
sm/vpl011.h
> > index be64883b8628..5c308cc8c148 100644
> > --- a/xen/arch/arm/include/asm/vpl011.h
> > +++ b/xen/arch/arm/include/asm/vpl011.h
> > @@ -59,26 +59,6 @@ struct vpl011 {
> >      evtchn_port_t evtchn;
> >  };
> >
> > -struct vpl011_init_info {
> > -    domid_t console_domid;
> > -    gfn_t gfn;
> > -    evtchn_port_t evtchn;
> > -};
> > -
> > -#ifdef CONFIG_HAS_VUART_PL011
> > -int domain_vpl011_init(struct domain *d,
> > -                       struct vpl011_init_info *info);
> > -void domain_vpl011_deinit(struct domain *d);
> > -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)
> > -{
> > -    return -ENOSYS;
> > -}
> > -
> > -static inline void domain_vpl011_deinit(struct domain *d) { }
> > -#endif
> >  #endif  /* _VPL011_H_ */
> >
> >  /*
> > diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> > index cafc532cf028..2cf88a70ecdb 100644
> > --- a/xen/arch/arm/vpl011.c
> > +++ b/xen/arch/arm/vpl011.c
> > @@ -134,7 +134,7 @@ static void vpl011_write_data_xen(struct domain *d,=
 uint8_t data)
> >
> >  /*
> >   * vpl011_read_data_xen reads data when the backend is xen. Characters
> > - * are added to the vpl011 receive buffer by vpl011_rx_char_xen.
> > + * are added to the vpl011 receive buffer by vuart_putchar.
> >   */
> >  static uint8_t vpl011_read_data_xen(struct domain *d)
> >  {
> > @@ -571,9 +571,9 @@ static void vpl011_data_avail(struct domain *d,
> >  }
> >
> >  /*
> > - * vpl011_rx_char_xen adds a char to a domain's vpl011 receive buffer.
> > + * vuart_putchar adds a char to a domain's vpl011 receive buffer.
> >   */
> > -int vpl011_rx_char_xen(struct domain *d, char c)
> > +int vuart_putchar(struct domain *d, char c)
> How can putchar refer to RX? By definition putchar() is used to print dat=
a to
> STDOUT. Here we receive a character and put it in the RX FIFO.

That's confusing, I agree; I think this is a leftover from the earlier vUAR=
T
series.

Will update, thanks!

>=20
> ~Michal
>=20
>=20



From xen-devel-bounces@lists.xenproject.org Tue Jun 24 22:55:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jun 2025 22:55:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024175.1400188 (Exim 4.92)
	(envelope-from )
	id 1uUCXY-0002sn-GY; Tue, 24 Jun 2025 22:54:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024175.1400188; Tue, 24 Jun 2025 22:54: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 1uUCXY-0002sf-Do; Tue, 24 Jun 2025 22:54:56 +0000
Received: by outflank-mailman (input) for mailman id 1024175;
 Tue, 24 Jun 2025 22:54: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 1uUCXV-0002sD-NY
 for xen-devel@lists.xenproject.org; Tue, 24 Jun 2025 22:54:54 +0000
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3cc0a5fd-514e-11f0-a30f-13f23c93f187;
 Wed, 25 Jun 2025 00:54:52 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3cc0a5fd-514e-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1750805691; x=1751064891;
	bh=SKwtyaV8cOlnunCeb+0okvgr6dv0f3K+ukAufcNG6Pw=;
	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;
	b=Fs26RKQ1YTleb7bzdAaoQroH8MLr6l59J+6la4HXsKUy3VizS/Bnpetb17t7nx+3b
	 9P0qVgD70kCfJ2UNpLEhBD2QqCfdy6aJR2s7RZgtEpKaKnBIjFm5/qFRMPgNSLoVRj
	 XeFW9Lj0aK0gh7bNAlhVL9Vrt9plXqL8CksXWLE1HalpbMGIJMVTQeaXuh+buSqyNi
	 3RMk3uMS+97+kEDCC3/aiYVOccO29Mt3USG25py9iXRG/VYnwrVin7xCVYVZcE3nUE
	 8EnifkxExLOg6ScWmYK91flB+McfLJ6qi/QpBVOQXm8TB1TpAHqxQUIc3G6W9KTf2n
	 iTuY8vUtmnM+w==
Date: Tue, 24 Jun 2025 22:54:45 +0000
To: Jan Beulich 
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com, oleksii.kurochko@gmail.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v1 14/16] drivers/vuart: move simple MMIO-based UART emulator
Message-ID: 
In-Reply-To: <6d33355c-477f-4ef3-8f17-b7f1dd1164ce@suse.com>
References: <20250624035443.344099-1-dmukhin@ford.com> <20250624035443.344099-15-dmukhin@ford.com> <6e6c8664-2ff6-484d-bd47-7ee12c449f9e@suse.com>  <6d33355c-477f-4ef3-8f17-b7f1dd1164ce@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 66105701014664e1d1feb02ae7cca8b61ac1c785
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 24, 2025 at 09:40:02AM +0200, Jan Beulich wrote:
> On 24.06.2025 09:36, dmkhn@proton.me wrote:
> > On Tue, Jun 24, 2025 at 07:53:04AM +0200, Jan Beulich wrote:
> >> On 24.06.2025 05:57, dmkhn@proton.me wrote:
> >>> --- a/xen/drivers/vuart/Kconfig
> >>> +++ b/xen/drivers/vuart/Kconfig
> >>> @@ -3,6 +3,15 @@ config HAS_VUART
> >>>
> >>>  if (ARM_32 || ARM_64)
> >>>
> >>> +config HAS_VUART_MMIO
> >>> +=09bool "Simple MMIO-based emulated UART support"
> >>
> >> Perhaps in a separate change this should be renamed. HAS_* should neve=
r
> >> have prompts.
> >
> > Oh, so HAS_ flags are non-interactive selectors by design?
>=20
> Well "has" simply by the word means "this is available". Any user-selecta=
ble item
> deriving from the mere availability would then have a "depends on HAS_...=
", thus
> hiding the option in situation where the functionality isn't available (b=
e it per
> arch or for other reasons).

I see there's a lot of drivers (UARTs) which are selectable by the user via
HAS_ symbols (drivers/char/Kconfig), e.g:

CONFIG_HAS_NS16550:                                                        =
                                                                           =
                                                     =E2=94=82 =20
  =E2=94=82                                                                =
                                                                           =
                                                                 =E2=94=
=82 =20
  =E2=94=82 This selects the 16550-series UART support. For most systems, s=
ay Y.                                                                      =
                                                                 =E2=94=
=82 =20
  =E2=94=82                                                                =
                                                                           =
                                                                 =E2=94=
=82 =20
  =E2=94=82 Symbol: HAS_NS16550 [=3Dy]                                     =
                                                                           =
                                                                   =
=E2=94=82 =20
  =E2=94=82 Type  : bool                                                   =
                                                                           =
                                                                 =E2=94=
=82 =20
  =E2=94=82 Prompt: NS16550 UART driver                                    =
                                                                           =
                                                                 =E2=94=
=82 =20
  =E2=94=82   Location:                                                    =
                                                                           =
                                                                 =E2=94=
=82 =20
  =E2=94=82     -> Device Drivers                                          =
                                                                           =
                                                                 =E2=94=
=82 =20
  =E2=94=82   Defined at drivers/char/Kconfig:4=20

>=20
> Jan



From xen-devel-bounces@lists.xenproject.org Wed Jun 25 00:30:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 00:30:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024207.1400198 (Exim 4.92)
	(envelope-from )
	id 1uUE1n-0006Lu-Ok; Wed, 25 Jun 2025 00:30:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024207.1400198; Wed, 25 Jun 2025 00:30:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUE1n-0006Ln-Lc; Wed, 25 Jun 2025 00:30:15 +0000
Received: by outflank-mailman (input) for mailman id 1024207;
 Wed, 25 Jun 2025 00: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 1uUE1l-0006Lh-0R
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 00:30:14 +0000
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8cfcdc8a-515b-11f0-a30f-13f23c93f187;
 Wed, 25 Jun 2025 02:30:10 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8cfcdc8a-515b-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1750811408; x=1751070608;
	bh=3WVZ9q2ZwLdVR60DweiI0nbtP9SSLsIaeTMBqquVSlE=;
	h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
	 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector;
	b=gGYfDIMYMrbJIRG6vq7SpjuS12h7zh0tugLr4oAO2m9ki2CA2HN+mLNQV1I45IxA/
	 tTT51Z8kNNfHBMinWLJiw5VW5qNuljgcnuHsZYZlAWNO3dMKQ/NGHLXYLXgLpITiHD
	 ChWtVvqMYv78Uwx/YWrm28PU4uDf6xRKCT/+lxFzJ7LAOJH+O83XTTcHGqKlA982h5
	 5aQg5Qov/pR3k7CVS5p0iMZI9dpejINP/GO3hx7vknjiWoUCJRJRBqfaySwMRdu/7A
	 wx9sDkN4uSXKnfBBNFn50eNZlE8L9fmxyWNasXBOpG9dojZQp0OLUgex9nCKF/Dk/V
	 wUaPnp3y6slKw==
Date: Wed, 25 Jun 2025 00:30:03 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v5] xen/console: introduce domain_console struct
Message-ID: <20250625002956.408945-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 4c66c248c671b170d2096b627ed759031772e5ba
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin =20

Introduce domain_console for grouping data structures used for integrating
domain's diagnostic console with Xen's console driver.

Group all pbuf-related data structures under domain_console. Rename the mov=
ed
fields to plain .buf, .idx and .lock names, since all uses of the fields ar=
e
touched.

Bump the domain console buffer size to the closest power of 2 (256) and
rename the symbol to DOMAIN_CONSOLE_BUF_SIZE.

Finally, update the domain_console allocation and initialization code.

No functional change.

Signed-off-by: Denis Mukhin 
---
Changes since v4:
- use xvfree() in _domain_destroy()

Link to v4: https://lore.kernel.org/r/20250623202030.208655-1-dmukhin@ford.=
com
CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/188759385=
9
---
 xen/arch/arm/vpl011.c      |  2 +-
 xen/arch/x86/hvm/hvm.c     | 17 +++++++++--------
 xen/arch/x86/pv/shim.c     |  2 +-
 xen/common/domain.c        | 19 +++++++++----------
 xen/drivers/char/console.c | 21 +++++++++++----------
 xen/include/xen/sched.h    | 30 ++++++++++++++++++++----------
 6 files changed, 51 insertions(+), 40 deletions(-)

diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 2b6f2a09bca6..f4a840da10c5 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -713,7 +713,7 @@ int domain_vpl011_init(struct domain *d, struct vpl011_=
init_info *info)
     }
     else
     {
-        d->console.input_allowed =3D true;
+        d->console->input_allowed =3D true;
         vpl011->backend_in_domain =3D false;
=20
         vpl011->backend.xen =3D xzalloc(struct vpl011_xen_backend);
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 056360d5fe50..7d599eab73f2 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -559,7 +559,8 @@ void hvm_do_resume(struct vcpu *v)
 static int cf_check hvm_print_line(
     int dir, unsigned int port, unsigned int bytes, uint32_t *val)
 {
-    struct domain *cd =3D current->domain;
+    const struct domain *d =3D current->domain;
+    struct domain_console *cons =3D d->console;
     char c =3D *val;
=20
     ASSERT(bytes =3D=3D 1 && port =3D=3D XEN_HVM_DEBUGCONS_IOPORT);
@@ -571,16 +572,16 @@ static int cf_check hvm_print_line(
     if ( !is_console_printable(c) )
         return X86EMUL_OKAY;
=20
-    spin_lock(&cd->pbuf_lock);
+    spin_lock(&cons->lock);
     if ( c !=3D '\n' )
-        cd->pbuf[cd->pbuf_idx++] =3D c;
-    if ( (cd->pbuf_idx =3D=3D (DOMAIN_PBUF_SIZE - 1)) || (c =3D=3D '\n') )
+        cons->buf[cons->idx++] =3D c;
+    if ( (cons->idx =3D=3D (DOMAIN_CONSOLE_BUF_SIZE - 1)) || (c =3D=3D '\n=
') )
     {
-        cd->pbuf[cd->pbuf_idx] =3D '\0';
-        guest_printk(cd, XENLOG_G_DEBUG "%s\n", cd->pbuf);
-        cd->pbuf_idx =3D 0;
+        cons->buf[cons->idx] =3D '\0';
+        guest_printk(d, XENLOG_G_DEBUG "%s\n", cons->buf);
+        cons->idx =3D 0;
     }
-    spin_unlock(&cd->pbuf_lock);
+    spin_unlock(&cons->lock);
=20
     return X86EMUL_OKAY;
 }
diff --git a/xen/arch/x86/pv/shim.c b/xen/arch/x86/pv/shim.c
index bc2a7dd5fae5..bd29c53a2d34 100644
--- a/xen/arch/x86/pv/shim.c
+++ b/xen/arch/x86/pv/shim.c
@@ -239,7 +239,7 @@ void __init pv_shim_setup_dom(struct domain *d, l4_pgen=
try_t *l4start,
      */
     d->max_pages =3D domain_tot_pages(d);
=20
-    d->console.input_allowed =3D true;
+    d->console->input_allowed =3D true;
 }
=20
 static void write_start_info(struct domain *d)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 303c338ef293..caef4cc8d649 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -669,7 +669,7 @@ static void _domain_destroy(struct domain *d)
     BUG_ON(!d->is_dying);
     BUG_ON(atomic_read(&d->refcnt) !=3D DOMAIN_DESTROYED);
=20
-    xfree(d->pbuf);
+    xvfree(d->console);
=20
     argo_destroy(d);
=20
@@ -835,8 +835,6 @@ struct domain *domain_create(domid_t domid,
         flags |=3D CDF_hardware;
         if ( old_hwdom )
             old_hwdom->cdf &=3D ~CDF_hardware;
-
-        d->console.input_allowed =3D true;
     }
=20
     /* Holding CDF_* internal flags. */
@@ -866,8 +864,6 @@ struct domain *domain_create(domid_t domid,
     spin_lock_init(&d->shutdown_lock);
     d->shutdown_code =3D SHUTDOWN_CODE_INVALID;
=20
-    spin_lock_init(&d->pbuf_lock);
-
     rwlock_init(&d->vnuma_rwlock);
=20
 #ifdef CONFIG_HAS_PCI
@@ -877,6 +873,14 @@ struct domain *domain_create(domid_t domid,
=20
     /* All error paths can depend on the above setup. */
=20
+    err =3D -ENOMEM;
+    d->console =3D xvzalloc(typeof(*d->console));
+    if ( !d->console )
+        goto fail;
+
+    spin_lock_init(&d->console->lock);
+    d->console->input_allowed =3D is_hardware_domain(d);
+
     /*
      * Allocate d->vcpu[] and set ->max_vcpus up early.  Various per-domai=
n
      * resources want to be sized based on max_vcpus.
@@ -959,11 +963,6 @@ struct domain *domain_create(domid_t domid,
     if ( (err =3D argo_init(d)) !=3D 0 )
         goto fail;
=20
-    err =3D -ENOMEM;
-    d->pbuf =3D xzalloc_array(char, DOMAIN_PBUF_SIZE);
-    if ( !d->pbuf )
-        goto fail;
-
     if ( (err =3D sched_init_domain(d, config->cpupool_id)) !=3D 0 )
         goto fail;
=20
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 5d3681b16aee..a894dc6dc3b2 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -524,7 +524,7 @@ struct domain *console_get_domain(void)
     if ( !d )
         return NULL;
=20
-    if ( d->console.input_allowed )
+    if ( d->console->input_allowed )
         return d;
=20
     rcu_unlock_domain(d);
@@ -567,7 +567,7 @@ static void console_switch_input(void)
         {
             rcu_unlock_domain(d);
=20
-            if ( !d->console.input_allowed )
+            if ( !d->console->input_allowed )
                 continue;
=20
             console_rx =3D next_rx;
@@ -757,6 +757,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(=
char) buffer,
         else
         {
             char *kin =3D kbuf, *kout =3D kbuf, c;
+            struct domain_console *cons =3D cd->console;
=20
             /* Strip non-printable characters */
             do
@@ -769,22 +770,22 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARA=
M(char) buffer,
             } while ( --kcount > 0 );
=20
             *kout =3D '\0';
-            spin_lock(&cd->pbuf_lock);
+            spin_lock(&cons->lock);
             kcount =3D kin - kbuf;
             if ( c !=3D '\n' &&
-                 (cd->pbuf_idx + (kout - kbuf) < (DOMAIN_PBUF_SIZE - 1)) )
+                 (cons->idx + (kout - kbuf) < (DOMAIN_CONSOLE_BUF_SIZE - 1=
)) )
             {
                 /* buffer the output until a newline */
-                memcpy(cd->pbuf + cd->pbuf_idx, kbuf, kout - kbuf);
-                cd->pbuf_idx +=3D (kout - kbuf);
+                memcpy(cons->buf + cons->idx, kbuf, kout - kbuf);
+                cons->idx +=3D kout - kbuf;
             }
             else
             {
-                cd->pbuf[cd->pbuf_idx] =3D '\0';
-                guest_printk(cd, XENLOG_G_DEBUG "%s%s\n", cd->pbuf, kbuf);
-                cd->pbuf_idx =3D 0;
+                cons->buf[cons->idx] =3D '\0';
+                guest_printk(cd, XENLOG_G_DEBUG "%s%s\n", cons->buf, kbuf)=
;
+                cons->idx =3D 0;
             }
-            spin_unlock(&cd->pbuf_lock);
+            spin_unlock(&cons->lock);
         }
=20
         guest_handle_add_offset(buffer, kcount);
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index fe53d4fab7ba..3c74dc71fe5e 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -371,6 +371,25 @@ struct evtchn_port_ops;
=20
 #define MAX_NR_IOREQ_SERVERS 8
=20
+/*
+ * Arbitrary value.
+ * The buffer is part of the dynamically-allocated data structure, using a=
n
+ * even multiple of a cache line size may help to optimize the allocation
+ * overhead.
+ */
+#define DOMAIN_CONSOLE_BUF_SIZE 256
+
+/* Domain console settings. */
+struct domain_console {
+    /* Permission to take ownership of the physical console input. */
+    bool input_allowed;
+
+    /* hvm_print_line() and guest_console_write() logging. */
+    spinlock_t lock;
+    unsigned int idx;
+    char buf[DOMAIN_CONSOLE_BUF_SIZE];
+};
+
 struct domain
 {
     domid_t          domain_id;
@@ -562,12 +581,6 @@ struct domain
     /* Control-plane tools handle for this domain. */
     xen_domain_handle_t handle;
=20
-    /* hvm_print_line() and guest_console_write() logging. */
-#define DOMAIN_PBUF_SIZE 200
-    char       *pbuf;
-    unsigned int pbuf_idx;
-    spinlock_t  pbuf_lock;
-
     /* OProfile support. */
     struct xenoprof *xenoprof;
=20
@@ -653,10 +666,7 @@ struct domain
 #endif
=20
     /* Console settings. */
-    struct {
-        /* Permission to take ownership of the physical console input. */
-        bool input_allowed;
-    } console;
+    struct domain_console *console;
 } __aligned(PAGE_SIZE);
=20
 static inline struct page_list_head *page_to_list(
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Wed Jun 25 05:25:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 05:25:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024307.1400207 (Exim 4.92)
	(envelope-from )
	id 1uUIdd-0004vD-6k; Wed, 25 Jun 2025 05:25:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024307.1400207; Wed, 25 Jun 2025 05: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 1uUIdd-0004v6-3s; Wed, 25 Jun 2025 05:25:37 +0000
Received: by outflank-mailman (input) for mailman id 1024307;
 Wed, 25 Jun 2025 05:25: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 1uUIdb-0004v0-Kh
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 05:25:35 +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 d0a30589-5184-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 07:25:32 +0200 (CEST)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-442fda876a6so55090675e9.0
 for ; Tue, 24 Jun 2025 22:25:32 -0700 (PDT)
Received: from ?IPV6:2003:ca:b711:f22a:dc83:b72e:7a24:c0fa?
 (p200300cab711f22adc83b72e7a24c0fa.dip0.t-ipconnect.de.
 [2003:ca:b711:f22a:dc83:b72e:7a24:c0fa])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4538236694esm8574135e9.28.2025.06.24.22.25.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 22:25:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d0a30589-5184-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750829132; x=1751433932; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=P+bJU4PAZSKYKKXh3OEvEgCL/2i5HMkaPXf4oVzoT/Y=;
        b=TweZsfiFeMMJ4VOzfmnqKvWVc1gi3hW0uK2VKL1xJDggI7lbR4gJ7H3bxVXkKRCCRr
         6Hv3QyjC8F2E6pseM0CRoDXxL0U10KU6KRkbyr6aSpnZY0DkdY/Xx4YCsChm77/CV020
         uHD+7vaxLSbMjtDg3tGt/PjARq0aeSOjCvu9Fr29q3jdktSDdGfGbP1DuBEE6LEFBYHP
         CMtd+aDGiHR2surRvvXNxyjZCe2NCQQwXIq4X7/FHeRBHzpvAv9MKcU8x48+IyeNtWRZ
         S/8dD1mhBOrwHiK0Y5W+yBX7m79vK9gn9rJeW9PzNcBIL69cVfwnBnhhB8Z+H/aemqtp
         hxEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750829132; x=1751433932;
        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=P+bJU4PAZSKYKKXh3OEvEgCL/2i5HMkaPXf4oVzoT/Y=;
        b=thpK2yBTeUuqvBIzqZlRLR67OpTq4BqT4nn8A9ViVxW7sdiH//VCM21iNupaZGPFp4
         6VIVpMgQCzbKIpXFTuM8s+EevL/hvGmttofzepTHLfmhmneQp6MrTymQralXcIbAKCEQ
         RNEf3ZcWhELZFqYVGHEYtEJzvWo806E0PCAHLRhNOMS+i09oHpBYiCFhYo98W1DBLsAY
         QmCCATErzbWqCOAW7Ay0mm1Mm/20UWdEE3iSJUqX9GJNDSU+h2fz0DanqWX41tM0DV0m
         bsFAaMurOtf0vRLihJPbiwTQUu/aO+zD/9X383MJYra3kvc/Aws/xvY8kCR2i6UVu9Ol
         r3fA==
X-Forwarded-Encrypted: i=1; AJvYcCWA8o2j8ZefbPnwxEIMgP6pQmjAWrHclCxzOkDqqdAcYQM/JQllSx+Rs86bs6Fu9kkCOipC/il67Pc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YytAJm1sGtMhNxCQ61P984KNAyVaO7C1Hw89NfNQvJxkfRBAVDE
	ZWBbMFI+jbZ+Vwo5L4X6Z/+h+Dk0I0J2vtYbuFv4+BGUT62wGm/Csm1edM+lUADAhA==
X-Gm-Gg: ASbGnctAZRIwKF+GBPksCmzqIzL2wcSFyZbS9QqbdJR09z4IBdKFaIx7ghM8E2KDwR/
	ymcz/ZVPChsQPAaTNKwBWwJcu5wK1KDxvhEqap9TExIwVDh7VFr7Xlx6U2VbZYjpFzrl3lADSMK
	9t5z+y7asw5n9iVVh6p2oKGpSqtlUTskzQmeKkn/MvOnqG96UifIAqbankon7ZqAE5LWwSSAnu8
	K1V7vpVOI1z5RCQ3mc6RosxhlCQjhVeLukmr7n+tgWTNubRwVaNhgv7Cddxg/vP4GGC2ENHfylW
	TNWjWK4zwIve8Szq3tMw3lIfSkn6o9AmEGZW8drhxm5RTbDShdBsLY9uVwBoRdfG34gHuyCNvpq
	zOIWCeFKdhxiDVeYZmt9+ADb28xEGmhF2Nd8JY0K4oneUhxOPBGrryODpTOUNi4FbcGn5WT2Hy3
	3ST8JyNBo5pjDYcYQk6cSlaRY1HGDr7us=
X-Google-Smtp-Source: AGHT+IHKBdM//9HncCq6qLsA3PG01Qz9U9HhmPGH3kzv2eaQ4AKdkbndTv6YKs9aPGhYA6R8ihJjsA==
X-Received: by 2002:a05:600c:5492:b0:453:6ca:16b1 with SMTP id 5b1f17b1804b1-45381af1eaemr10357805e9.26.1750829132180;
        Tue, 24 Jun 2025 22:25:32 -0700 (PDT)
Message-ID: 
Date: Wed, 25 Jun 2025 07:25:29 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 14/16] drivers/vuart: move simple MMIO-based UART
 emulator
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, oleksii.kurochko@gmail.com, roger.pau@citrix.com,
 sstabellini@kernel.org, dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250624035443.344099-1-dmukhin@ford.com>
 <20250624035443.344099-15-dmukhin@ford.com>
 <6e6c8664-2ff6-484d-bd47-7ee12c449f9e@suse.com> 
 <6d33355c-477f-4ef3-8f17-b7f1dd1164ce@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 25.06.2025 00:54, dmkhn@proton.me wrote:
> On Tue, Jun 24, 2025 at 09:40:02AM +0200, Jan Beulich wrote:
>> On 24.06.2025 09:36, dmkhn@proton.me wrote:
>>> On Tue, Jun 24, 2025 at 07:53:04AM +0200, Jan Beulich wrote:
>>>> On 24.06.2025 05:57, dmkhn@proton.me wrote:
>>>>> --- a/xen/drivers/vuart/Kconfig
>>>>> +++ b/xen/drivers/vuart/Kconfig
>>>>> @@ -3,6 +3,15 @@ config HAS_VUART
>>>>>
>>>>>  if (ARM_32 || ARM_64)
>>>>>
>>>>> +config HAS_VUART_MMIO
>>>>> +	bool "Simple MMIO-based emulated UART support"
>>>>
>>>> Perhaps in a separate change this should be renamed. HAS_* should never
>>>> have prompts.
>>>
>>> Oh, so HAS_ flags are non-interactive selectors by design?
>>
>> Well "has" simply by the word means "this is available". Any user-selectable item
>> deriving from the mere availability would then have a "depends on HAS_...", thus
>> hiding the option in situation where the functionality isn't available (be it per
>> arch or for other reasons).
> 
> I see there's a lot of drivers (UARTs) which are selectable by the user via
> HAS_ symbols (drivers/char/Kconfig), e.g:
> 
> CONFIG_HAS_NS16550:

Iirc it was prompt-less up to some point. And when the prompt was added, the name
wasn't changed / split. Other UARTs then followed suit (when they shouldn't have).

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 05:32:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 05:32:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024316.1400217 (Exim 4.92)
	(envelope-from )
	id 1uUIkE-0006TI-SM; Wed, 25 Jun 2025 05:32:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024316.1400217; Wed, 25 Jun 2025 05: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 1uUIkE-0006TB-PM; Wed, 25 Jun 2025 05:32:26 +0000
Received: by outflank-mailman (input) for mailman id 1024316;
 Wed, 25 Jun 2025 05: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 1uUIkD-0006T0-TE
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 05:32:25 +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 c64fa774-5185-11f0-a30f-13f23c93f187;
 Wed, 25 Jun 2025 07:32:25 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-450cb2ddd46so6520455e9.2
 for ; Tue, 24 Jun 2025 22:32:25 -0700 (PDT)
Received: from ?IPV6:2003:ca:b711:f22a:dc83:b72e:7a24:c0fa?
 (p200300cab711f22adc83b72e7a24c0fa.dip0.t-ipconnect.de.
 [2003:ca:b711:f22a:dc83:b72e:7a24:c0fa])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a6e810010fsm3599457f8f.74.2025.06.24.22.32.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Jun 2025 22:32:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c64fa774-5185-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750829544; x=1751434344; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=0PBeaqPshxiz7kaMy08XNTLoyNAXF1MsQkoXvieZLy8=;
        b=D3Et8j9vF2KZOklJl1eGKdqnnurUBnMJQoxVKSldlS8AGLZudwM02/NHIX5ZkoPa8B
         tHFIN62Q0QPTaV/BP6Pph73bEEoRTNgGq1FxQQv+FcTUAjbqYunLmZHsHYJ6/nhDybxB
         Ys/M8neFDGLrzpPFoMweMs2mfoIexlKmpdNMe4/Nvdbpol89cUwDmU1Qy78aCiuHrgm3
         kNCbCFmNQidJmUX9aZj5LnscQFgB7ntgRMTiFY2ROT0loJqzlVks7ULh3x3b7Kf2QzSQ
         qtGIDt4aQx/FCpyArz3LAHWxIdVlloS3q5ynZl8H/3Aj3OBx+/7l3bjhHv/O7SkKv7em
         +E3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750829544; x=1751434344;
        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=0PBeaqPshxiz7kaMy08XNTLoyNAXF1MsQkoXvieZLy8=;
        b=UmgXmaxhB7pWskPJilX8D8dKtzrBWMts09QsTVvYVFPHIuvOAmTDrcE0hsGIM2A/dH
         mvEJesGvSgpi4vUWFqnOPXmhP/JEpXTz9/pYkbjHA32BeuIgIHgLO+oQ7pl1FfA1/hYC
         Y3VEHj80GganqBxOLK+PnE4JOEz4EzoDF++Y64D4C+hr63+X9zGdEzvGe7K96JautgyL
         oV6Rz4g20LT9pSHcvuuHyKLoiyLxJJvOLjrFuG9eXxWlYDUHcHWwtxrywLxJs5iemgHi
         u9jlYCU0jCEp5UUh2jjRYAcyyuHag33tG284e9RtevuPYd9HcEkxtkFSiZdH7hFKYBjo
         y58w==
X-Forwarded-Encrypted: i=1; AJvYcCWADSsVr+ftSpyMQ33TzvCcRacvramvboasPNmqwjtLkvNtmtTkKD5Gpru2LNV+2y+4m5jD4Ta076I=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz99gK6yz7dWK1eghxZNfUD+ltjj9n1PU2GCY5OGtBVoMucCpRa
	Y3gEjPtTvzSi0pild1NU0VbETLenhNRoLh4EtcKeJVV8rXZ74eovX8inb73OZ2H8WA==
X-Gm-Gg: ASbGnctpYYFGY76zSUXa7ZY/VuV9M5Ka0b3NN+p0K2mFx+Nun4Kh1cRzDxp0ztUKSc6
	nc8vDfztR3dZS4t8xQNJcRebcfwoWfe36vI68WZJHFObZODX7yobLH1QAEzO5HubKmh25v4U3ln
	YaD7e2iqjrOSIc34+upoACvqnWTYeCFoPMR6mQ8wjhvdsGlrAZGWBhJGJ/RmarJQvLp4BgaG3jm
	hdwAcnRp1iPHAtaIyCW4/UtrZW1IBzdiCpzObTljzvk/+RgXBvE0sSCYowx4U5YFTt/3ihN0m8i
	o7ds9rbWxvwrBp+avBsicXIQOOdEJeBmNwWu7nzxVa8TnxUeFEPCCoJe4AprJTnQ7h42UPVyOV4
	YEwxpkSMEsq7VNl8g+wfOq3rBzDN/SP8+K141sUI2+uwnMziYUcQvCC+8GFa1zHbkETAX0Vz+qf
	Wtzggs1okQpVt3QPd24TQvlfPzMwE9uMg=
X-Google-Smtp-Source: AGHT+IE4GUMgzm5cjuU+Nl98c5+rJJc6D4oFhIG4jh1M3MjA1L8b2HMBMVhiO3K2IjCFiO2i4vfsRA==
X-Received: by 2002:a05:600c:1e03:b0:453:c39:d0c2 with SMTP id 5b1f17b1804b1-453839047d5mr2680805e9.24.1750829544444;
        Tue, 24 Jun 2025 22:32:24 -0700 (PDT)
Message-ID: <48def2b5-44ad-45fa-b052-67520c0961f0@suse.com>
Date: Wed, 25 Jun 2025 07:32:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: hardware domain and control domain separation
To: Jason Andryuk 
Cc: Julien Grall , Bertrand Marquis
 , Michal Orzel ,
 Andrew Cooper ,
 Anthony PERARD ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , ayankuma@amd.com,
 xen-devel@lists.xenproject.org, demiobenour@gmail.com,
 Stefano Stabellini 
References: 
 <942a6178-0fe7-468e-8e45-ea255fd20680@suse.com>
 
 
 <381dba84-3108-42c8-a4e5-7bc74d5e1075@suse.com>
 <2e27e128-398a-4714-b019-eab04520cc97@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: <2e27e128-398a-4714-b019-eab04520cc97@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 24.06.2025 22:14, Jason Andryuk wrote:
> On 2025-06-24 01:25, Jan Beulich wrote:
>> On 24.06.2025 00:51, Stefano Stabellini wrote:
>>> On Mon, 23 Jun 2025, Demi Marie Obenour wrote:
>>>> On 6/23/25 11:44, Jan Beulich wrote:
>>>>> On 21.06.2025 02:41, Stefano Stabellini wrote:
>>>>> Also a more fundamental question I was wondering about: If Control had
>>>>> full privilege, nothing else in the system ought to be able to interfere
>>>>> with it. Yet then how does that domain communicate with the outside
>>>>> world? It can't have PV or Virtio drivers after all. And even if its
>>>>> sole communication channel was a UART, Hardware would likely be able to
>>>>> interfere.
>>>
>>> There are well-established methods for implementing domain-to-domain
>>> communication that are free from interference, such as using carefully
>>> defined rings on static shared memory. I believe one of these techniques
>>> involves placing the indexes on separate pages and mapping them
>>> read-only from one of the two domains.
>>
>> How's that going to help with the backend refusing service, which I view
>> as one "method" of interference? Or else, what exactly does "interference"
>> mean in this context? (More generally, I think it is necessary to very
>> clearly define terminology used. Without such, words can easily mean
>> different things to different people.)
> 
> Yes, there are different kids of interference.  We are concerned about a domain blocking another domain.  The main example is an ioreq blocking a vCPU.  The blocked domain is unable to recover on its own.

On which insns an ioreq server may kick in can be well known. A kernel
can therefore, in principle, come with recovery code, just like it can ...

> A PV backend not servicing a request is interference, but it doesn't block the frontend domain or vcpu.  The primitives don't block, so drivers can be written to handle the lack of a response.  As you note, this can't be a critical service for the domain.

... here. (Not responding at all is also only one way of refusing service,
just to mention it.)

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 06:52:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 06:52:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024339.1400228 (Exim 4.92)
	(envelope-from )
	id 1uUJzD-0007JD-8F; Wed, 25 Jun 2025 06:51:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024339.1400228; Wed, 25 Jun 2025 06:51: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 1uUJzD-0007J6-4X; Wed, 25 Jun 2025 06:51:59 +0000
Received: by outflank-mailman (input) for mailman id 1024339;
 Wed, 25 Jun 2025 06:51: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 1uUJzA-0007J0-Tp
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 06:51:57 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20630.outbound.protection.outlook.com
 [2a01:111:f403:2408::630])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e102ca71-5190-11f0-a30f-13f23c93f187;
 Wed, 25 Jun 2025 08:51:55 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by SA1PR12MB7223.namprd12.prod.outlook.com (2603:10b6:806:2bc::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.25; Wed, 25 Jun
 2025 06:51:50 +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.8835.027; Wed, 25 Jun 2025
 06:51: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: e102ca71-5190-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=JRmWqjGqvAIMuqVR2//gN7Jt50Reu5y18b27JbAS18AUScjsheGsc2sXwH7yFPLchFIWGkKqNu5jamjMnBgVN/Lo9w94wQH6mYnhnCUvO8S36MGLjjPen2YdQU1Cz7ET1BftCMzD1AH2KUw3gjQughC2YcKiGVf9u4a4abUEsn46e5xGPVTqxMAsOmDoZwh8vUvjXL7G6BOn+M2yztUkhbQfdaJcYp66T2hhimXA1Nt/2lCdM2Vby4rAztq66gHvP04YIpXxNpFelg9K1ZJ/RTd2d8one8VHB93zP2y7EVaPJyePVdULn/gU7MnvKIJA/bFuJfNRHL+s4vvRe38EDg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=UsuGD6OSWKpBAf6O5TS+39FWcvIRYURXGfkHs+ayxx4=;
 b=HUtj16t1jeg+jUO0x7GVYOE0BEcGmGkGE1/dcTfDJBNzLJTq2CsgP7xdVQtnNibqNJpdNJrUHr0m/LIGFdG/RY4qTLeBHEifRunsycoomaxJc2ATDa0gLH/S4jrhZN5Ui+ydRRXDaI3kX4L8uAtYLDD6jhU+JZNeSH8zMasam2VeA+1slmjTfgEbA2Qf+n2+abUmT2RriiL1NU9FO59m8rRWv2Gp2YF50tctzybT8ga8n9RY7djM8Z60MpAC5PYPWjPqEMYlxvkxPBVWuyfgsVj2ssiUaPwOj+caHu6Tc7Sa2Z9CuLxb2nggdGGJgts7XP65j2sfAHLRm5MDi2QxAA==
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=UsuGD6OSWKpBAf6O5TS+39FWcvIRYURXGfkHs+ayxx4=;
 b=pW3A0fEz0zYW1dquKDFztDxrVjFVe8Hw8YjxOQVQzjZuO+CPkClUhnc+gVy3apwBs1zoWZ5hxyqvRdD2ifbLi7HwOzNZrJR6CHl5W0QeImn+7uiQJrq3PcoTFS2HpqRxktXAFqbwHa+hZ/MpJiE3/O37I9ezcWKnHZAU5Q/KPqA=
From: "Chen, Jiqian" 
To: Jan Beulich 
CC: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Andrew Cooper
	, Anthony PERARD ,
	"Orzel, Michal" , Julien Grall ,
	Stefano Stabellini , "xen-devel@lists.xenproject.org"
	, "Huang, Ray" , "Chen,
 Jiqian" 
Subject: Re: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
Thread-Topic: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
Thread-Index:
 AQHb23yakGdVC9XxvEWnYcnp8zrTt7QI/QAAgAGa9QCAAQzVgIAG5D6A//99hgCAAJwoAP//hioAgAHew4A=
Date: Wed, 25 Jun 2025 06:51:50 +0000
Message-ID:
 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-3-Jiqian.Chen@amd.com>
 <516a3adc-320d-46ce-b235-8ef91469abcf@suse.com>
 
 <227df6d3-a2c3-4576-bde9-d8057c378e7a@suse.com>
 
 <5c4b186e-686e-4fc8-bcf1-854bc1f5ec8b@suse.com>
 
 <9d5d0e44-66c3-4e3f-8704-2c862c5f5aff@suse.com>
In-Reply-To: <9d5d0e44-66c3-4e3f-8704-2c862c5f5aff@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.8835.025)
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_|SA1PR12MB7223:EE_
x-ms-office365-filtering-correlation-id: c5e6e4fb-3133-412a-61ba-08ddb3b4c308
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?aHRPa0RyRmtPYkhObzRhdGJsZCt0TFNzeU9KWUFpRmZBWXBzWHNGTjNWcW5x?=
 =?utf-8?B?MDN4bnE2QVFCZmhJblI3d0hSNm9VSXFFVzQyZktkTjllK3kzUjJ5OTZGQXBQ?=
 =?utf-8?B?cjhBSXo3NlRiQmdjL05oWkZzemlDMlh4TGJtMjJJQ0s2L2JEUzVzaHRzT0dG?=
 =?utf-8?B?OUZteXdWWm01NENyeEZRUWl2bXk5MkJPWUtOc1NiTmdWamNwZE5RdTcweWhS?=
 =?utf-8?B?WWpmWGxCWXBnSEI2WGpMa1Bmdi8wblM2RHhvYjlXRzlZNFpiUXd5dERRNDF3?=
 =?utf-8?B?bXhxVENPR09paXRBK0QrOW1UWXdOcXhYK3NraWZYRWZTTU9uQi9oUS96SXZ1?=
 =?utf-8?B?V01IR2JYanMvdGVNZkE4WjlhNndlMkxXWEF0MVZWSjJwSytxYWJvYUxZUjRQ?=
 =?utf-8?B?WXZyNDNXSG1ESDRQbFB2U1BpN0FueUVwUmNrczNMUmRxMlJkMTJMMHBwV25E?=
 =?utf-8?B?SXFyaEUySFpyRStzN3ovTy8vdk5EU2hoME5rNElpQzNuQ3EvMERwZ3FvTDQ5?=
 =?utf-8?B?SlJXdkpwaXdUVlFyZnh3Ymg2alBpUVF4aG1nWlNjQm5YVUU1OW55TDc0bFhV?=
 =?utf-8?B?amVyeDdxZklkV1FmYnhtL282SXZFSWJTT3p5SFV3bjMwYm9XdGZCSVd2Mnhn?=
 =?utf-8?B?aExDOUdObHlqcEhlVmNZVWdxZ1cvN2NEeVlPZ0ZCRUR3aE1zTUIvdEZja0FT?=
 =?utf-8?B?Unk1QnZGZ0JaQ09ybC91VVBWRWJJa2JhL2pPb2NFVGxWYjBhVzR4RWhQNzdz?=
 =?utf-8?B?Y1RVeU0xcTZBaWZyV2N3dW5hTmJHeCthQ1FhZERDSVV0Y201dm94SDUzYzFt?=
 =?utf-8?B?R1JSMkUrSTdzNGFUUHk0dWYra3JRdWQ5NGdoY1hiRnE4cy93TXdCSUhBcFls?=
 =?utf-8?B?emFoTUxObXVUSXRWVEM3M0U4bmZTMDQ2QTF6Rng3cGMwSm1vaFBXS0hqRGpU?=
 =?utf-8?B?d2k3Wk0xY3VwTzl5cmpFSmZ6ZlpuczZBemtNdkcvdHcwekgyQzFkWDZ3eWdt?=
 =?utf-8?B?dWRUa21aMU9JTVRVR283OFZtcnFvV1Rja3B0Q0FkZU90ODFJc2FyTFE2d2h1?=
 =?utf-8?B?WTVrODVxRnlodnE4cVdkYzAyUG15bDJaNEk4b01ycGpzYm9XWWZIRzBFeG5s?=
 =?utf-8?B?WUFJWE00V1dvSWhoViszL0dOTCtFdzRRZVpMTzZrSkkyaW5QTEVraFlWNUNK?=
 =?utf-8?B?YURuS3UxM3dGUWp0T3VpZk9Yc01oa25OallwNEpnZnQ3Y05uWUJSN0tkVk5x?=
 =?utf-8?B?UGJ1a0JSK1d3aWxKcHAvbWxxWEFVdVhmVlczdmlGOGR3aTJYQVkwbWw0ZHVh?=
 =?utf-8?B?MDdMVjEreDQ0VzdVR0twcFk5YTluK1dOejFHeEZpdCtXVmt1Q3BoN0ttbDdZ?=
 =?utf-8?B?ZjF4Mi8xM1gwSXpiK2tOR1lYUEtidDQ3UjdiTlNWNVN5YWVabHVUUzY0K0E5?=
 =?utf-8?B?TndqdjN0bXVQdjZnUkpyMmlJdUdpQlhudEVGeFdJQTVkbnlyd2hmcWdmV2RZ?=
 =?utf-8?B?RXlob2VtSzNiVXE0S0hucmFWeG83Z2h2UUd1dEpmMlRKRCs0ZkU1dnhlU2M3?=
 =?utf-8?B?dTgrOUx1VHZBV0ZUMzJpUlRoVUFUZEVBTHJrNjJuUlZlTEdETkFBMVlEQ2VT?=
 =?utf-8?B?SnR1UmdWa3R4QllBYlVrcHlCSkh3NmtTV3E0REFSNkpPN3dlK1Q3d1JUWnNu?=
 =?utf-8?B?b1FHWVhVckFBK3oxaC9BdVZpS3loeE1qUnRmY3FWelpxWFo3dHlVbGNlOFpM?=
 =?utf-8?B?azVTUFk4NFRYdjVseEdCT3Vxd0cyTURoVkpMWEQ1NElsWEJGNGpUY1F6b0NZ?=
 =?utf-8?B?T3ZIS0RjOFpEU3lXN3dFRHE4ZjlaeXFLQWorbEt4dlJyRDNnWmZuT0o3eEFH?=
 =?utf-8?B?bmJGeG1sVFRwMXBVUVBpb2xNOEV5U2NCRm5KMUw5QmlucDM5SEt4K3pqTzFq?=
 =?utf-8?B?MVhHdWcwb250elk1UHBnRHEwKy9FT25lcjJkVXUwV1lxcHVpc2JxaE5zWlNa?=
 =?utf-8?Q?6PD+l4X4gkLickiXhYl7qQO5MDPr8I=3D?=
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?M0QzR1ZSUW0wSWlBVW43UnZkV2hIdnF3OU1tRHJzWWt6NGZneXhQNHIzSDBa?=
 =?utf-8?B?amxZSDg1bFc3SFZ3RjBwbWlaZlZuNjRRNUdONmd5cGVPckVBS21mdlpLZWNP?=
 =?utf-8?B?MnJRcVNvZkdVWnplZkJyU1JDTHBMVlhRZkl5SGwxRUVCM1hmS1RMdW94d0Vo?=
 =?utf-8?B?aWlab1ZEUWV2TEcwUVlKTEdtbFF4cHF4c1F5SWhvbnFnVlJZem1LSy9Yd0xP?=
 =?utf-8?B?YmtiUHFZYkNPNEtHSnY0Qm5KYy9GUTN1dm4rQmpDTFYyZmk1SlpiL3k4V05a?=
 =?utf-8?B?NkJlQ0hHTzFBVVNJb0ZxTlpzd1dzcGZYUTZ4TkhmTG1zdEhSSEF2Yy9PSnZw?=
 =?utf-8?B?RGVUQjNNeUowakZxTWRPZ21Cc2Q0NHJkM2ptbkU1L2lwZk9rRnIwWGRZYkRC?=
 =?utf-8?B?UEM3RGxWdys2K0hxUGF2RTNiMlNRWDdzTDY2bUFwNUorWWFCOHhib0l5enNN?=
 =?utf-8?B?eC8vVjdXYlNjTTcvTjRsZ1p2b2RRbXhBOWxIaDhCQjRPNFRmZEMvbVZLM01L?=
 =?utf-8?B?TVo0SHhwWGpqZDYyaDhadmpvSlptekFmOVg1bk1VWklTNzJ5ckp0S0Z2Nm5Y?=
 =?utf-8?B?bzExREw1MTNJYzJZbEdLTkRBcEFpN0NubHplTzNaZlZLd3BNQ0ZiT05WaGkx?=
 =?utf-8?B?eTRZSFJvYUpWaDVUR0pkWEJIRy80NGpVNE8wVnZ2RGJkUy9MR29NT1VDSitM?=
 =?utf-8?B?NCtlejdGN1RGU2oybFZMcUhYWElITWk1aS80d0pUY3BkeFFDQ0t1UFhXT3Fp?=
 =?utf-8?B?bUJTaVpIazl1VHJwK1hqd25QM1cvNnZnVm5HYVo2T0pvRDdidGIyeUs4WlZr?=
 =?utf-8?B?ZFhmNFhsRWY2SG5tVU1wTkFmZnQ2Mk52MlZSZDJyY0VOS1ZJT28yN3BqL3I5?=
 =?utf-8?B?Y2JONUZreXpCOUdHTE93WHJVdU9GcXc5cUM0cHR3b005RmN2bnhmRFdGSGVv?=
 =?utf-8?B?TGdvbmdGNEIvK0hCdnlScS9rSk9NUmZtZWFuQ2hTQ2YrcDJVR2ZkWTlzSk03?=
 =?utf-8?B?dm5mQ1dYWGg5TERRa2VOdzdQSkorM0gybkhaSEkwMUYvTWJUYmp5YWlaOHN3?=
 =?utf-8?B?QjBEcXN1d2dQUllVcUNyLzFPK2R1ZEJEU2tSR3ExL0RmK0hFaDk1bXZwcWZv?=
 =?utf-8?B?L21NekRTMHdMblZHY2xiTjcxMUNrVlZsTzI5MHJLdk45ekxGcUs2dUZMK3B6?=
 =?utf-8?B?c3hEdXR1UDZCRHU3dVBpTDNjNkVMUE83NVRYZlQ2R040MFVFNC9PcHlrUGYw?=
 =?utf-8?B?L3V4bWtqSTJBNmNUNktLSndOSHl6aEZUeFB1ZUM1elppejFFOFNwVFlWWGYr?=
 =?utf-8?B?YlB4U2hGYlRFZmhTYmlWSTAzYzJUR1FEeHV5dXZuWVI0YSt3SUN4UVA1a24r?=
 =?utf-8?B?SDl2U045NlhJL0lFVTEwdXhMcXRzL2ZWWE5uV25OUld1eXJ0TGhEcTI4WmFv?=
 =?utf-8?B?cFRXeC9VVldUWlBLd1NWLzlJNVROMFBCYWFVWGErWTcxY2FGUk9MVGNIMndR?=
 =?utf-8?B?a0paR3JZdmxSbmdWYzZublJyVm5TUjJ4aWNuTkZUbWRUM2dUQzI2bUFXMjdt?=
 =?utf-8?B?MXpvWnNkMXlOa1pGbXNCZnllcCtBVHYxbkpwZTVOU04vY3pna3J4eU54b1FF?=
 =?utf-8?B?YkJjeThuNUpGZVFuZC9ISkx4djdsSHRCY1FEWldzVG90WUcxNEJ3N0tSZ2to?=
 =?utf-8?B?MTc2eDJvRFAzYzk1Z2xOdGtON0laOHF4WnRIZjc1RWUyTWMzc3lvMlQ4Vjcr?=
 =?utf-8?B?WVg5SEl1V0tOYUM2cXo1Sk04V24vQzNadTV1aGljL2hTcXU1RW0xMTNzU004?=
 =?utf-8?B?eHVzVUJzNWJXN1l6VEJQekJTSVh2V0x6OTZJVHk1SEVRZWFpWXM1QzkxMXlp?=
 =?utf-8?B?YW82VGhHQjR6eTRHWlpDMXVlNGNkOFB5UEdvVVByMWNaUVZKMG1vTVhncEZF?=
 =?utf-8?B?Z3pHQW5mTS9mTTBWRnA4NzBmSzVkL1JmZzJtdU9EeDBRL3ErRXdCYVU1bVFa?=
 =?utf-8?B?SjR4YlB4TlhJd0k2YXBZSk9HeUtBenFSZVRkTGlzeXZFWVptS2NpWUpIWnND?=
 =?utf-8?B?Mmo2NEhjZko1dEczSThFYUpvVWdUMTE3UkRrcW5sVlY4a2J1elJhMS9jM2pn?=
 =?utf-8?Q?NgNY=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <45C8088827DCB94782F4B4671AFB4064@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: c5e6e4fb-3133-412a-61ba-08ddb3b4c308
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2025 06:51:50.3700
 (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: zwHaSggVWQGLJtRM5U40jd2B1JY3RKTJoHv5KtWKi/1x1FGaTEDLYnBI2HCGyLug984zJf3fEv12AYeETEqwdQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB7223

T24gMjAyNS82LzI0IDE4OjA4LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMjQuMDYuMjAyNSAx
MToyOSwgQ2hlbiwgSmlxaWFuIHdyb3RlOg0KPj4gT24gMjAyNS82LzI0IDE2OjA1LCBKYW4gQmV1
bGljaCB3cm90ZToNCj4+PiBPbiAyNC4wNi4yMDI1IDEwOjAyLCBDaGVuLCBKaXFpYW4gd3JvdGU6
DQo+Pj4+IE9uIDIwMjUvNi8yMCAxNDozOCwgSmFuIEJldWxpY2ggd3JvdGU6DQo+Pj4+PiBPbiAx
OS4wNi4yMDI1IDA4OjM5LCBDaGVuLCBKaXFpYW4gd3JvdGU6DQo+Pj4+Pj4gT24gMjAyNS82LzE4
IDIyOjA1LCBKYW4gQmV1bGljaCB3cm90ZToNCj4+Pj4+Pj4gT24gMTIuMDYuMjAyNSAxMToyOSwg
SmlxaWFuIENoZW4gd3JvdGU6DQo+Pj4+Pj4+PiBAQCAtMjksOSArMzAsMjIgQEAgdHlwZWRlZiBp
bnQgdnBjaV9yZWdpc3Rlcl9pbml0X3Qoc3RydWN0IHBjaV9kZXYgKmRldik7DQo+Pj4+Pj4+PiAg
ICovDQo+Pj4+Pj4+PiAgI2RlZmluZSBWUENJX01BWF9WSVJUX0RFViAgICAgICAoUENJX1NMT1Qo
fjApICsgMSkNCj4+Pj4+Pj4+ICANCj4+Pj4+Pj4+IC0jZGVmaW5lIFJFR0lTVEVSX1ZQQ0lfSU5J
VCh4LCBwKSAgICAgICAgICAgICAgICBcDQo+Pj4+Pj4+PiAtICBzdGF0aWMgdnBjaV9yZWdpc3Rl
cl9pbml0X3QgKmNvbnN0IHgjI19lbnRyeSAgXA0KPj4+Pj4+Pj4gLSAgICAgICAgICAgICAgIF9f
dXNlZF9zZWN0aW9uKCIuZGF0YS52cGNpLiIgcCkgPSAoeCkNCj4+Pj4+Pj4+ICsjZGVmaW5lIFJF
R0lTVEVSX1ZQQ0lfQ0FQQUJJTElUWShjYXAsIGZpbml0LCBmY2xlYW4sIGV4dCkgXA0KPj4+Pj4+
Pj4gKyAgICBzdGF0aWMgY29uc3QgdnBjaV9jYXBhYmlsaXR5X3QgZmluaXQjI190ID0geyBcDQo+
Pj4+Pj4+PiArICAgICAgICAuaWQgPSAoY2FwKSwgXA0KPj4+Pj4+Pj4gKyAgICAgICAgLmluaXQg
PSAoZmluaXQpLCBcDQo+Pj4+Pj4+PiArICAgICAgICAuY2xlYW51cCA9IChmY2xlYW4pLCBcDQo+
Pj4+Pj4+PiArICAgICAgICAuaXNfZXh0ID0gKGV4dCksIFwNCj4+Pj4+Pj4+ICsgICAgfTsgXA0K
Pj4+Pj4+Pj4gKyAgICBzdGF0aWMgY29uc3QgdnBjaV9jYXBhYmlsaXR5X3QgKmNvbnN0IGZpbml0
IyNfZW50cnkgIFwNCj4+Pj4+Pj4+ICsgICAgICAgIF9fdXNlZF9zZWN0aW9uKCIuZGF0YS5yZWwu
cm8udnBjaSIpID0gJmZpbml0IyNfdA0KPj4+Pj4+Pg0KPj4+Pj4+PiBDb3VsZCB5b3UgcmVtaW5k
IG1lIHdoeSB0aGUgZXh0cmEgbGV2ZWwgb2YgaW5kaXJlY3Rpb24gaXMgbmVjZXNzYXJ5IGhlcmU/
DQo+Pj4+Pj4+IFRoYXQgaXMsIHdoeSBjYW4ndCAuZGF0YS5yZWwucm8udnBjaSBiZSBhbiBhcnJh
eSBvZiB2cGNpX2NhcGFiaWxpdHlfdD8NCj4+Pj4+PiBZb3UgbWVhbiBJIHNob3VsZCBjaGFuZ2Ug
dG8gYmU6DQo+Pj4+Pj4gI2RlZmluZSBSRUdJU1RFUl9WUENJX0NBUEFCSUxJVFkoY2FwLCBmaW5p
dCwgZmNsZWFuLCBleHQpIFwNCj4+Pj4+PiAgICAgc3RhdGljIGNvbnN0IHZwY2lfY2FwYWJpbGl0
eV90IGZpbml0IyNfdCBcDQo+Pj4+Pj4gICAgICAgICBfX3VzZWRfc2VjdGlvbigiLmRhdGEucmVs
LnJvLnZwY2kiKSA9IHsgXA0KPj4+Pj4+ICAgICAgICAgLmlkID0gKGNhcCksIFwNCj4+Pj4+PiAg
ICAgICAgIC5pbml0ID0gKGZpbml0KSwgXA0KPj4+Pj4+ICAgICAgICAgLmNsZWFudXAgPSAoZmNs
ZWFuKSwgXA0KPj4+Pj4+ICAgICAgICAgLmlzX2V4dCA9IChleHQpLCBcDQo+Pj4+Pj4gICAgIH0N
Cj4+Pj4+Pg0KPj4+Pj4+IFJpZ2h0Pw0KPj4+Pj4NCj4+Pj4+IFllcywgc3ViamVjdCB0byB0aGUg
ZWFybGllciBjb21tZW50cyBvbiB0aGUgaWRlbnRpZmllciBjaG9pY2UuDQo+Pj4+IEdvdCBpdC4N
Cj4+Pj4gT25lIG1vcmUgcXVlc3Rpb24sIGlmIGNoYW5nZSB0byBiZSB0aGF0LCB0aGVuIGhvdyBz
aG91bGQgSSBtb2RpZnkgdGhlIGRlZmluaXRpb24gb2YgVlBDSV9BUlJBWT8NCj4+Pj4gSXMgUE9J
TlRFUl9BTElHTiBzdGlsbCByaWdodD8NCj4+Pg0KPj4+IFllcy4gVGhlIHN0cnVjdCBkb2Vzbid0
IHJlcXVpcmUgYmlnZ2VyIGFsaWdubWVudCBhZmFpY3MuIChJbiBmYWN0IGluIHByaW5jaXBsZQ0K
Pj4+IG5vIGFsaWdubWVudCBzaG91bGQgbmVlZCBzcGVjaWZ5aW5nIHRoZXJlLCBleGNlcHQgdGhh
dCB0aGlzIHdvdWxkIHJlcXVpcmUNCj4+PiBrZWVwaW5nIHRoZSBzZWN0aW9uIHNlcGFyYXRlIGlu
IHRoZSBmaW5hbCBpbWFnZS4gV2hpY2ggSSBkb24ndCB0aGluayB3ZSB3YW50LikNCj4+Pg0KPj4+
PiBTaW5jZSBJIGVuY291bnRlcmVkIGVycm9ycyB0aGF0IHRoZSB2YWx1ZXMgb2YgX19zdGFydF92
cGNpX2FycmF5IGFyZSBub3QgcmlnaHQgd2hlbiBJIHVzZSB0aGVtIGluIHZwY2lfaW5pdF9jYXBh
YmlsaXRpZXMoKS4NCj4+Pg0KPj4+IERldGFpbHMgcGxlYXNlLg0KPj4gQWZ0ZXIgY2hhbmdpbmcg
X19zdGFydF92cGNpX2FycmF5IHRvIGJlIHZwY2lfY2FwYWJpbGl0eV90IGFycmF5LCBjb2RlcyB3
aWxsIGJlIChtYXliZSBJIG1vZGlmaWVkIHdyb25nIHNvbWV3aGVyZSk6DQo+Pg0KPj4gZGlmZiAt
LWdpdCBhL3hlbi9kcml2ZXJzL3ZwY2kvdnBjaS5jIGIveGVuL2RyaXZlcnMvdnBjaS92cGNpLmMN
Cj4+IGluZGV4IGM1MWJiYjhhYmIxOS4uOWYyZjQzOGI0ZmRkIDEwMDY0NA0KPj4gLS0tIGEveGVu
L2RyaXZlcnMvdnBjaS92cGNpLmMNCj4+ICsrKyBiL3hlbi9kcml2ZXJzL3ZwY2kvdnBjaS5jDQo+
PiBAQCAtMzYsOCArMzYsOCBAQCBzdHJ1Y3QgdnBjaV9yZWdpc3RlciB7DQo+PiAgfTsNCj4+DQo+
PiAgI2lmZGVmIF9fWEVOX18NCj4+IC1leHRlcm4gY29uc3QgdnBjaV9jYXBhYmlsaXR5X3QgKmNv
bnN0IF9fc3RhcnRfdnBjaV9hcnJheVtdOw0KPj4gLWV4dGVybiBjb25zdCB2cGNpX2NhcGFiaWxp
dHlfdCAqY29uc3QgX19lbmRfdnBjaV9hcnJheVtdOw0KPj4gK2V4dGVybiB2cGNpX2NhcGFiaWxp
dHlfdCBfX3N0YXJ0X3ZwY2lfYXJyYXlbXTsNCj4+ICtleHRlcm4gdnBjaV9jYXBhYmlsaXR5X3Qg
X19lbmRfdnBjaV9hcnJheVtdOw0KPiANCj4gSnVzdCBmeWk6IFlvdSBsb3N0IGNvbnN0IGhlcmUu
DQo+IA0KPj4gQEAgLTI1NSw3ICsyNTUsNyBAQCBzdGF0aWMgaW50IHZwY2lfaW5pdF9jYXBhYmls
aXRpZXMoc3RydWN0IHBjaV9kZXYgKnBkZXYpDQo+PiAgew0KPj4gICAgICBmb3IgKCB1bnNpZ25l
ZCBpbnQgaSA9IDA7IGkgPCBOVU1fVlBDSV9JTklUOyBpKysgKQ0KPj4gICAgICB7DQo+PiAtICAg
ICAgICBjb25zdCB2cGNpX2NhcGFiaWxpdHlfdCAqY2FwYWJpbGl0eSA9IF9fc3RhcnRfdnBjaV9h
cnJheVtpXTsNCj4+ICsgICAgICAgIGNvbnN0IHZwY2lfY2FwYWJpbGl0eV90ICpjYXBhYmlsaXR5
ID0gJl9fc3RhcnRfdnBjaV9hcnJheVtpXTsNCj4+ICAgICAgICAgIGNvbnN0IHVuc2lnbmVkIGlu
dCBjYXAgPSBjYXBhYmlsaXR5LT5pZDsNCj4+ICAgICAgICAgIGNvbnN0IGJvb2wgaXNfZXh0ID0g
Y2FwYWJpbGl0eS0+aXNfZXh0Ow0KPj4gICAgICAgICAgaW50IHJjOw0KPj4gZGlmZiAtLWdpdCBh
L3hlbi9pbmNsdWRlL3hlbi92cGNpLmggYi94ZW4vaW5jbHVkZS94ZW4vdnBjaS5oDQo+PiBpbmRl
eCBmNGVjMWMyNTkyMmQuLjc3NzUwZGQ0MTMxYSAxMDA2NDQNCj4+IC0tLSBhL3hlbi9pbmNsdWRl
L3hlbi92cGNpLmgNCj4+ICsrKyBiL3hlbi9pbmNsdWRlL3hlbi92cGNpLmgNCj4+IEBAIC0zMSwx
NCArMzEsMTMgQEAgdHlwZWRlZiBzdHJ1Y3Qgew0KPj4gICNkZWZpbmUgVlBDSV9NQVhfVklSVF9E
RVYgICAgICAgKFBDSV9TTE9UKH4wKSArIDEpDQo+Pg0KPj4gICNkZWZpbmUgUkVHSVNURVJfVlBD
SV9DQVBBQklMSVRZKGNhcCwgZmluaXQsIGZjbGVhbiwgZXh0KSBcDQo+PiAtICAgIHN0YXRpYyBj
b25zdCB2cGNpX2NhcGFiaWxpdHlfdCBmaW5pdCMjX3QgPSB7IFwNCj4+ICsgICAgc3RhdGljIHZw
Y2lfY2FwYWJpbGl0eV90IGZpbml0IyNfZW50cnkgXA0KPj4gKyAgICAgICAgX191c2VkX3NlY3Rp
b24oIi5kYXRhLnJlbC5yby52cGNpIikgPSB7IFwNCj4+ICAgICAgICAgIC5pZCA9IChjYXApLCBc
DQo+PiAgICAgICAgICAuaW5pdCA9IChmaW5pdCksIFwNCj4+ICAgICAgICAgIC5jbGVhbnVwID0g
KGZjbGVhbiksIFwNCj4+ICAgICAgICAgIC5pc19leHQgPSAoZXh0KSwgXA0KPj4gLSAgICB9OyBc
DQo+PiAtICAgIHN0YXRpYyBjb25zdCB2cGNpX2NhcGFiaWxpdHlfdCAqY29uc3QgZmluaXQjI19l
bnRyeSAgXA0KPj4gLSAgICAgICAgX191c2VkX3NlY3Rpb24oIi5kYXRhLnJlbC5yby52cGNpIikg
PSAmZmluaXQjI190DQo+PiArICAgIH0NCj4+DQo+PiAgI2RlZmluZSBSRUdJU1RFUl9WUENJX0NB
UChjYXAsIGZpbml0LCBmY2xlYW4pIFwNCj4+ICAgICAgUkVHSVNURVJfVlBDSV9DQVBBQklMSVRZ
KGNhcCwgZmluaXQsIGZjbGVhbiwgZmFsc2UpDQo+Pg0KPj4gSSBwcmludCB0aGUgdmFsdWUgb2Yg
TlVNX1ZQQ0lfSU5JVCwgaXQgaXMgYSBzdHJhbmdlIG51bWJlciAoNjE0ODkxNDY5MTIzNjUxNzIw
OSkuDQo+IA0KPiBXaGF0IGFyZSB0aGUgYWRkcmVzc2VzIG9mIHRoZSB0d28gc3ltYm9scyBfX3N0
YXJ0X3ZwY2lfYXJyYXkgYW5kIF9fZW5kX3ZwY2lfYXJyYXk/DQpfX2VuZF92cGNpX2FycmF5IGlz
IDB4ZmZmZjgyZDA0MDQyNTFiOA0KX19zdGFydF92cGNpX2FycmF5IGlzIDB4ZmZmZjgyZDA0MDQy
NTE2MA0KTlVNX1ZQQ0lfSU5JVCBpcyAweDU1NTU1NTU1NTU1NTU1NTkNCnNpemVvZih2cGNpX2Nh
cGFiaWxpdHlfdCkgaXMgMHgxOA0KDQo+IEF0IHRoZSBmaXJzdCBnbGFuY2UgdGhlIGNoYW5nZXMg
YWJvdmUgYXJlIHdoYXQgSSB3b3VsZCBoYXZlIGV4cGVjdGVkLg0KPiANCj4gSmFuDQoNCi0tIA0K
QmVzdCByZWdhcmRzLA0KSmlxaWFuIENoZW4uDQo=


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 06:52:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 06:52:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024348.1400238 (Exim 4.92)
	(envelope-from )
	id 1uUK00-0007q7-Jc; Wed, 25 Jun 2025 06:52:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024348.1400238; Wed, 25 Jun 2025 06:52: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 1uUK00-0007q0-GK; Wed, 25 Jun 2025 06:52:48 +0000
Received: by outflank-mailman (input) for mailman id 1024348;
 Wed, 25 Jun 2025 06:52: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 1uUK00-0007J0-13
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 06:52:48 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on2060e.outbound.protection.outlook.com
 [2a01:111:f403:2418::60e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0036a381-5191-11f0-a30f-13f23c93f187;
 Wed, 25 Jun 2025 08:52:47 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by DS7PR12MB5790.namprd12.prod.outlook.com (2603:10b6:8:75::18) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8880.17; Wed, 25 Jun
 2025 06:52:43 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8857.026; Wed, 25 Jun 2025
 06:52: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: 0036a381-5191-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=fWwfDRPYh2wnT3c4AGVgZXWNttULiz57/YTKvEepFjTD5jetWYATqaK341si17ia9o/E7lsYJDfWOQmkuqfEfhR2MNLNvhgShsbEVMVOE8AgWz9IOfbhpnX7+PiohCDg3Tb/FvPxdoiYWgwvZssoIH4shVGpB4HN+asFWKZwSAfxp6VSiVzaIkc3UZ/SFieyf9UEx6Iijf+udvb2KqbhRTNtf+zfIs+Wle9j/U4QnaPqbBDj6SYyVUfXETY6IBoNGtf1EnsXtJ/dhWMYB1FA+9spuIOnKI27TNKEcBEhSVi68SwIi3nvN9txj43cBQwr45uwWE4+bZMS1KBou25HHg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=VKXHAIGeMQ7sxRSWLLIKNAIWYJaNR/hChrkaKJBDn14=;
 b=ix8D9vLr4BFD3Rbm+cDF4DcTpwAnzGYYb6Dn5+oIqcIobjgxvuro/l/7OnPWGU5E29t+cNI9PXDDVNwvTTl59+NnjsenyzI54+0Xnlc4VLgQW5XP4fyTUAwH4ug9hikt60R9RM/ohiwLQHKU3tk+U8W8ffBDVjkSXj4NBwh6nS5jhAkCMXvE1M/6rmQ4bSZB46FS9SYRjh4vDC2FSej/3tcyX51Olu4MLTXFv67s+I4eQ09lNfogrHDucwpRyoKevCfU2WViV2lyMCHbTvAeIDseEMOqWcJ+0HWMkrvdOtF0wPrvL2fHAgJ4uQlvka1H+TF7yDIDMGMF/2N2/N3J2g==
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=VKXHAIGeMQ7sxRSWLLIKNAIWYJaNR/hChrkaKJBDn14=;
 b=lfCZUJP9ymyvAhypiB7ynZO6RKaeNK0ViFlaUEDeEPjKY1JPWjPeFgshOOBtc9j5h61TVVWd+HT7SR9eBZVgYaKuUbGW+WR32wA3TyqrVJylhtN2TkVi7E4JqRWSa5No8ocwVf1ZpG5I9TOHbF2Zo9+KdlJme/6x/NfluXu6aHg=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <096ba4c4-16eb-43cd-ae4a-6ef654f08ccf@amd.com>
Date: Wed, 25 Jun 2025 08:52:39 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 04/16] arm/vpl011: use raw
 spin_lock_{irqrestore,irqsave}
To: dmkhn@proton.me
Cc: Jan Beulich , andrew.cooper3@citrix.com,
 anthony.perard@vates.tech, julien@xen.org, oleksii.kurochko@gmail.com,
 roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com,
 xen-devel@lists.xenproject.org
References: <20250624035443.344099-1-dmukhin@ford.com>
 <20250624035443.344099-5-dmukhin@ford.com>
 <08cb7878-fad7-47f4-9c91-5f866c54b1df@suse.com>
 <0cfc9465-90d5-46db-88a7-ed47d0809b60@amd.com> 
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR2P281CA0018.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:a::28) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|DS7PR12MB5790:EE_
X-MS-Office365-Filtering-Correlation-Id: 13b5271b-4a27-4aac-7e0a-08ddb3b4e217
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|366016|376014|7416014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?czNqYlA3N29MUWw1blZCZXVmaDhOK21weDZFRFVsbnQvS3lTSHgrclI0NHB6?=
 =?utf-8?B?Wm5scFk2ZVlQcXBsQ1Y5SGFZb01tVkM2UHRuWG90Ynk1QkpacmNrZHF2K01W?=
 =?utf-8?B?Y3R1NjRPWkI3eXZCek5LOWdobXgxMmFycGE4eUZUVHdaMk10RmQxWEhEL0Yv?=
 =?utf-8?B?Si9ldzhGOW5OemU4eC8rQ3c4OXF0djNlb00vSTBqK1RIM2V5am5QSXMwVk11?=
 =?utf-8?B?aU1HcWNXT2E4QmRsMy9SL2ZiQnJjQ2ZYYUgwaTIyNjdCajhiWUNqaWRpVnVL?=
 =?utf-8?B?RGtzdVZLRThUTXdldnY3WmVlNURYRWhCbWR1U2Q5RUh6U3QrdEYvQnh5Umt1?=
 =?utf-8?B?eXpla25xSEIwazF0bWErenltQ1BXSk96L2hWd045RUg5WG5PdWllTzlIQzNs?=
 =?utf-8?B?K1VCcUtDNzJYeUpUaFp5LzYxaEd5SkpPOHpTVUNJR29mcVhjVG40ZzQ1eU1U?=
 =?utf-8?B?RTdGQy9xVlJoRk9wMjJOS2ZzOVBMTXBmQnQvTmVjWXp2K0VZRXNtZEx3TUR1?=
 =?utf-8?B?cUIzbnh0Q2VJV2c2cnZaZzBLVVhNMzloSFRpWC9zdmp5THJSUHlGOElTZCto?=
 =?utf-8?B?TjQ3SEFScXpBU3JTa2FURWZzVTZxcW9ud0UwNUV3UUxSRCt0OFZCTThjTnFQ?=
 =?utf-8?B?YXVBcHgwZ0ltQjgwL25XYlZ0aTZRcElSS3NPQk1TOU8wVVNBWkFIb0k4emFS?=
 =?utf-8?B?L3Z6aDgvOGg5ajN6VU1ybExrOFdjQTNSZUswaTAzQ0hydVF4T1JvaE5ncWdh?=
 =?utf-8?B?U2J3bzZQbXl6REo4bG43a09ZUVZqczlndk9VTEtIWEw3SFh5UllHcXNKVmxC?=
 =?utf-8?B?ZXh2VjJRTW1BdDhENEFNZEJUeDNHRDJ2R0xYME9KNW02QVQzVXRxTER1ZlZC?=
 =?utf-8?B?R2tHaWFxT3o1T25rUnZDalRSRm9hdHN5WTliZHVDeVU0SElDWWMyaUZiVHNa?=
 =?utf-8?B?R21VV3JESHVLbm8rUng1SlZTVldIOFhiUTQxdG1CYkp3S2x1RnNxWXczL1Mw?=
 =?utf-8?B?VzVZSnh6eWRtRDlkRnIyeGpMNXFoaW9SN0QzbGgxY05ETFRHMHVKdTdPTi9R?=
 =?utf-8?B?N3J0TVNLbXBxVi9ENFBjNnJrcG9sMTZQTHdsZC9UZUw4SzZrQ0VubjFnSnJG?=
 =?utf-8?B?Z2I2SnQ1VzdEUVFDU2hPcjRwQXVrV0N3eUJQOXBnWVV2aVJnamtQK3V4aHo3?=
 =?utf-8?B?V3dpckFZVURZMGs5azZ4UkhvY01IZWdnNU1VTlJ2VGpGcXJlOExDQ09RN2RS?=
 =?utf-8?B?TlJWdGROcW9pc3dkWjFhcmtuTXEyVEVlZGVRdDVIelk0NktiVG90MktJemVL?=
 =?utf-8?B?WTBDdCtSUWdwanNFdnJLWXN1ZUIxTjdRZ2x3WTRqTFp2QzZReDN1dWs2aWdY?=
 =?utf-8?B?NytOUXllRk1sM1VwMG0yMkZOV0JPQlE4TFV0WWJkcFpKOFZKOXNSKzhZRFZN?=
 =?utf-8?B?ejVYR2FBSEpBVmZoVDlXL3hJeTY0TGN6TEl4SEVQeThNeU13eDFSQU1KNmZ6?=
 =?utf-8?B?T2F1ZEpwNk1vTTkramkvVVlCNnNJUmlBWGhJYkFHZ0hLL2Y3WUpZZVFJRUcv?=
 =?utf-8?B?RnJKZk05dm5MeDI1Si9ZdEZxQlVEaEtRL1R0MzBtaEl2V1RIdjV4bXpkQThK?=
 =?utf-8?B?WW82SjZQcy9ub21SNjJjVzN4cXVqdkwyRUVTSWNrZVV2OW5Hby9SV0JUaUpY?=
 =?utf-8?B?RW4rbklYUUZDSE5sQXpVaWFSMnpMSVBka2l4enIwTEdNSDJIVUR0Nm5LdUZF?=
 =?utf-8?B?MXRJRHN4cWZXUTAycFlZMUl2a21nTXZ6OHpaTjV2Q3NhRnBEdHpYV0ZBZzFG?=
 =?utf-8?B?OU5pdHlsMHVsdjZkdEVOVWdreE1Kb09WcGdYait0SXFUMi92T0pLL0IrMFJv?=
 =?utf-8?B?cVhhWWU0ams2RWUyVms2NS8vWmxNWndrOFQxYld3Vm5ydnc9PQ==?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(7416014)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?VUgvQmllenJEN0JlMGVIVXdDa25hMEZKWnA3YWtkNlpEL0NIaU5ScHFDUmlT?=
 =?utf-8?B?akNhMkJpL0ZyaVJtNUtzLzFYVlVMcHhCZUJhL1JtbWMrUTUvcllHVWlOQm9s?=
 =?utf-8?B?eDJOSEI4WWFUdjZFeHdFcmYxL2t2d2lLUURNUHlKdy90WUxab3QzMGlLL3pZ?=
 =?utf-8?B?WlA1REo1WDU0azllcGVOdjN3VkhnMTNZR0hHZHlMQzc0VlFUU2xGdllERjZo?=
 =?utf-8?B?N1gwdFcyY1hqWWNZYkEyQjV0bjBSSnpVdG8xTjBVRHpoY0ptQ1ZoSkRlcmhh?=
 =?utf-8?B?R0V5TGIxOUk2UE5ueHZnMWR0eVh3bmlNNFYxVUdKNlkzamxydlhMZnlMbGFO?=
 =?utf-8?B?d2NKcHBjSGZmWTFwVXpUQjNqS3ppZyt0SDN0cnVNMTh0WUdyUTF6cXBEekg0?=
 =?utf-8?B?cFFDYjExWmxCdVYvV0UzNmt4QlI3TjByUTQvdVE1MDRid2I1MWNPdWVIRjV0?=
 =?utf-8?B?VlhGMTlkNnNRKzNhYzFVekdGV3plMVNXbzRqaWQwL1dRQ3VPNU1VMCtOSmdi?=
 =?utf-8?B?WEdYbHRBdklwbXZGbEJyNm8zYlJqZkxyaGtYcEZ1S1JOMENDVGRVMDBaR1NU?=
 =?utf-8?B?aUZldzFmWERWVWtuNHZKQzZZeTRGSmFhb3ppelU1M2JXMEdXKzhNaW5NOEhz?=
 =?utf-8?B?bVNSdUM2a2wyczVueElXeVJJcTJCREZ3clVvRjRESnVtZ2lBbnhxVGJLOGF1?=
 =?utf-8?B?SFVPMm1UdEJqMmhpeTc4TjFIZ09kTzE0T24rL20rQXBBbzA5bVVDNk8rRFlX?=
 =?utf-8?B?SHB1ZXE5RDByTG1kNC9MTEgxdktjcHJjdXM3cDkvTHlRczVhcnZiTjArdVlM?=
 =?utf-8?B?MkJQOE5WQitBeFhXMzEzem40U3I5a3JQaEFvc1pLbkpodnd5akwzek5PcStm?=
 =?utf-8?B?YXlqSlRMZ0FhWTJtazZKNm5zMG91aS90ZEp6NFg0TG15ZmI5SnA3S2NLcGlz?=
 =?utf-8?B?RVNoMlc2eENSbG9HMmowRU9LZ096TFBXelpnNHVLbkVDTlc3alppSHZUN2l3?=
 =?utf-8?B?bWZoaytMeFB4ZVREWE55Y3VzZklYNjdjdktqSUZaaE1JQkxaMkR1OURoYURt?=
 =?utf-8?B?UjhSNE9va3cwV0tWM2o1VlRITlFTQjFVQ2svTzNRWDBndWlQTGNvTG1yOU9h?=
 =?utf-8?B?djhlelVzQUNQeFVGZDE3OVRWK3NjSXdJWXVrMU84K2NRNjV0UFdHbUpacEFG?=
 =?utf-8?B?Nlh1RVJ5bXFHTzhKYWplVGlSZG1oSm9UemlBZGJSSDJzNzRnaVdFU1lVS2ZQ?=
 =?utf-8?B?MnNWSldOODB6NVBxS214Kyt1SkZsVlZCeHBJNXVMVlc0MFR5WEdRU1ZFTHE5?=
 =?utf-8?B?WUlCL0JJa2ZwOHk3c0JlQ3g3OVgza1lkWE5UTSt3Ym1WRFJQYjZJU3hBWmtW?=
 =?utf-8?B?RVJWbXljU3RiLzFKVURiYll5clFHbHZTdFAxQUtYUXpHMzlxd1Jpa1ZxUXR2?=
 =?utf-8?B?TEcwejhCKzNMeS9jNTZUV3VRY3pVT09YK0ZFeStoS25URlhoZ1UwSFlKdGJj?=
 =?utf-8?B?UGIyc1h0ZklJajErM3k1SHdvd1FGL0YwZTlUWEIyWXpXemFYay9YZmVxNnlL?=
 =?utf-8?B?TUJpa0lqQWo2cSt4Qmx3NTZQZ2lJUTZTMDZQZXZJV1RuSGJmRVZId2dxM2ZS?=
 =?utf-8?B?d0h1NHNvUUMvMjg0UnVpK2pCYVNWaitVbXp6YlZmZUxucERVSlhqWkVVenhu?=
 =?utf-8?B?b1pMWDdUWGZvMkpsdk5jVTB6WTlKditqM0FpOVZYNzBlcGk1UnRwRTEwOVRw?=
 =?utf-8?B?eUFqNGxDYmx2bnRHeGx2SGtHdHF2QTIzbEdjRmR2ZWJjVytjTVFqd1BFejY0?=
 =?utf-8?B?cVJ1RXFTUFIwUDVmL0VyS1AyZm01UmFrZmUxd2VsWGdHKzg5UHhwQkpWYzVJ?=
 =?utf-8?B?VUo1RC9ubW1ldVBoVXhmNTBRMG1IYmtyZ0tqWVF0TkMwcWo3UGJ0c3hRM1Yy?=
 =?utf-8?B?MjBCY0lpV0ZMV1VYRVJKOHdndm1xVE5RRUg1RWU1dlZsU2oxcVdkSWdHNThZ?=
 =?utf-8?B?OWRvY3lEaXJ1YVU3T0dWTTdzanNWQW5Dd1JtOHYwZXFVVEtPMWJvU0FpZFAw?=
 =?utf-8?B?Y09ZUGlKTFV1bml6ZThLdnlIQ2ZzdDNSTlBzZVBrWW1qaG5hRnBSNytvQWpV?=
 =?utf-8?Q?JZXkBAFmjlA57Npcg8iat/gLP?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 13b5271b-4a27-4aac-7e0a-08ddb3b4e217
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jun 2025 06:52:43.1233
 (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: ZAkuV7S4ii1PtYtHwLca7Y1Wou1/xB5rPmwQ7MLVXnNbHbgOPerdC2KhGsJu7fiR
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB5790



On 24/06/2025 23:46, dmkhn@proton.me wrote:
> On Tue, Jun 24, 2025 at 09:50:54AM +0200, Orzel, Michal wrote:
>>
>>
>> On 24/06/2025 07:46, Jan Beulich wrote:
>>> On 24.06.2025 05:55, dmkhn@proton.me wrote:
>>>> From: Denis Mukhin 
>>>>
>>>> Replace VPL011_{LOCK,UNLOCK} macros with raw spinlock calls to improve
>>>> readability.
>>>
>>> I'm not an Arm maintainer, so I have limited say here, but: How is this
>>> improving readability? It better utilizes available local variables, yes,
>>> so this may be a little bit of an optimization, but otherwise to me this
>>> looks to rather hamper readability.
>> I agree with Jan here. I don't think it improves readability, therefore I don't
>> think such change is needed.
> 
> I think exdanding macros helps to understand the code since is explicitly
> shows what kind of locking *really* used, so this aspect is actually getting
> more readable; yes, that's a bit of more text.
> 
> But, MMIO-based flavor does not define such helpers for example, so now vUARTs
> follow similar coding pattern which is easy to read/follow.
I understand your point of view. It's more like a matter of taste here, so I
won't oppose to it. Others may chime in.

~Michal



From xen-devel-bounces@lists.xenproject.org Wed Jun 25 06:57:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 06:57:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024360.1400248 (Exim 4.92)
	(envelope-from )
	id 1uUK4g-0008Tl-5Q; Wed, 25 Jun 2025 06:57:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024360.1400248; Wed, 25 Jun 2025 06:57:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUK4g-0008Te-1R; Wed, 25 Jun 2025 06:57:38 +0000
Received: by outflank-mailman (input) for mailman id 1024360;
 Wed, 25 Jun 2025 06:57: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 1uUK4e-0008TY-J1
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 06:57:36 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20601.outbound.protection.outlook.com
 [2a01:111:f403:2412::601])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ab9b36c3-5191-11f0-a30f-13f23c93f187;
 Wed, 25 Jun 2025 08:57:35 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by CY8PR12MB8361.namprd12.prod.outlook.com (2603:10b6:930:7b::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.28; Wed, 25 Jun
 2025 06:57:31 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8857.026; Wed, 25 Jun 2025
 06:57: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: ab9b36c3-5191-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=qHaxt0EsBnzpROHa5YK41CoaPP1MgtuwpbyOtKUGkrr4sck6kPgjJurzmDDGxXA1I451lrfQf0qL/ZjmK18of1cD++fvpuWV2f7XykgFp5KZMJGMain2lemIr1kF5EkXHhqE50BVpAViupPj6iaWqfgqksE9ahw8ndVq92qDTriOSO0ONh+am1Xum3JNqcke5qTTcLN1mHlmlgfu6MulD4IMlvlgrhh6QCJUqMmZkWZjf9pyR9FUCUCsLWu7Ex8bA6b7tRFLYhhbJK/qmCtWSUkGbxushylXVUPotQLzK7EzOrrQnXNGTwUdpKgfFsFBz8ykViYDJyay1GqyM9sPmg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=qvYenQp3ahDHYQWfOgVudhzSrs6/DFyVHKXFxpepVEE=;
 b=CIJmQUHOrxJknVMp6m80iheg7zHcqEGyHVUR85PXazyyWAS3DRbVXBMvwxqlkKEpLMn4ISweXh/So3hhCXOBJcQ/6e/N64Xfa6Xb04/LqvBdRr4qKSZfxtQkKcKAq0W38l9m019HhBzblwNG6FfaquMM/Jsf4Jsq4HdCNbrzaE12feJC96IUB63U6grOxNdqyi1ASHCXryaFTqjejiZPI8tSAe74PDW7gzxdgxQGcPpNz2tQsMal6B3AOddeKsSujCBwKxT8ta2Fba13ESHHK75RJcYhwjFRZvVFOWgGm/5qKXUdMqMStuSR/O+6LzBLC+pvt+krrjRHd2WRKtWoBw==
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=qvYenQp3ahDHYQWfOgVudhzSrs6/DFyVHKXFxpepVEE=;
 b=W2YmZDPiVhO46sR8QdXJy7GzilBm7LbKIPGHfFkhI9bMXEP64OLumX3muZ5h32nrDAHmDNRQEHXlltadtPO0KWCaDkuJzqABX1/RNTZVR+xHUhwiNGe9IcfaQ4MYeTAJ+3Z6LBSF3Xx9i/aTuFa3IeRobo1BVgYno5D6Ij1JBEw=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Wed, 25 Jun 2025 08:57:27 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 02/16] arm/vpl011: move DT node parsing to PL011
 emulator code
To: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com,
 anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org,
 oleksii.kurochko@gmail.com, roger.pau@citrix.com, sstabellini@kernel.org,
 dmukhin@ford.com
References: <20250624035443.344099-1-dmukhin@ford.com>
 <20250624035443.344099-3-dmukhin@ford.com>
  
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR2P281CA0022.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:14::9) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|CY8PR12MB8361:EE_
X-MS-Office365-Filtering-Correlation-Id: 35c3de32-b126-4dcb-1f0e-08ddb3b58e1c
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|7416014|366016|1800799024|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?U1hCd1lxK2ZXbzhQemszaVVKQ1ZaYXVreWxpTjFIbDAxQ0NYU0VWUzhiZGtj?=
 =?utf-8?B?SjNRWTJBZlREK3Njb3hQaUhwOGlXRHI5WnQwYk5HcWl6VTA0YStqaEtsRDdQ?=
 =?utf-8?B?Vklad3dzY1I0UzJ1SDF0Q0x3YzkrMUFnemFZRGRhTHExb1hDMEZZRGVydXgy?=
 =?utf-8?B?TEN1bjZnd1FSVkE1dktzVTlHcFVnYUVUM0d4VnVzWWYxcXB2MU9kYUVVTEp0?=
 =?utf-8?B?VVpaWldFL0dqektoTndYdTdWTVUzckhYTjR3WDk3MWE1R3lJQ2tMVWZiTEtU?=
 =?utf-8?B?eW1VdjI1bEd5VEN2Vi9zcFdGdDgzWk93c2hOVWNmRUJLTW5mVFZDak1OT3A4?=
 =?utf-8?B?R3J2a1RjUC8rK21VcUFWeGpuV2RxOUhMbzIxRmhyM0xFcVhuQko0OGlNMDhM?=
 =?utf-8?B?dG5DWXdVVlJBTFQ3cThETGRvRTRkK1BxTjAzTVROQURFVDJhWTJQV3lPNE9w?=
 =?utf-8?B?d3hCWmt0eDhBLyt3NG9wWndqV1AvWnp4REdsK0UyYU8xdm42Q1B5WVRHWm1l?=
 =?utf-8?B?YUxBL2tnRG5hRWdZZU9ybW9WRmJWK0FpOXdiZFdpNWdUejV2RGtJakgrUlF5?=
 =?utf-8?B?T1dFMzNtckw5R1kzaHBOOUFKOU5OaVU2WjlwNzUvbHNnMUV3bDZ1eGZZNHRD?=
 =?utf-8?B?QW5CMERHZWUxTXhBdXdHQzFCZWF5WStuZVYzS2ZKNTduU3F0R1dYVjJSSGxj?=
 =?utf-8?B?eWZabzJqZHlUNVZNRisvcDh4V3BwbTZ2SFYyVktKUVdaYVh4OEJLVXBjeXNs?=
 =?utf-8?B?M0xxNHNEemxRTmwrUUhMQldJeFhVOGJCOFcxUkJtNDFpaDBoTDQvQVRhSENa?=
 =?utf-8?B?RU4vdTVpSU5sNElLazd3TmdLSGFNRzY5M3ZqOFdnZ2dHNXRHcXVhUDMwWFU5?=
 =?utf-8?B?UG5KNXBESStEVjVqeHpaV2FnT2o1Q0gvaGxGb2RDaFBlUWVKL0JhejczZVlz?=
 =?utf-8?B?UnY2djNvemdGY1ZBOXA1d2dMUWM4SHBMbkpBUHdEK0lGNGdlV1F0UEZnOFVa?=
 =?utf-8?B?eVl3bCtIbm9oOHlTWGhWdXRJR1NneHAwdUJVeGF4TFRYRVNyMEI4Zm1EQVBC?=
 =?utf-8?B?bXE0ZDQ0a0o0Wm9XU0pnNVcyZnVEd0VMVWZiZzI0cjcxTzhQZDk4U2FRRnZk?=
 =?utf-8?B?T3JzRmNteC9LcnlrOSt5ZHJ4ZFN2bk1GSklLY2g4Qm54aGNDdlhlK0xZOFN1?=
 =?utf-8?B?RmkzRUtKK2ZrOFUrajF5VUdacWhmMXRwaDlldkZFeXdnQjVkWktDanhqZEFI?=
 =?utf-8?B?bHd4Rytva2FhL0J5bDU0UmhUZ29OYTVNMFNhSy83bFJFb0ZvV20zRGRPWG5G?=
 =?utf-8?B?UXlKTTdPY0NrbWJTL283TWRvWkFSYkVvNWgwKzR6UjFxRG9mVWpMRnk5UmhD?=
 =?utf-8?B?WTNzUThlbEh6YU50UDdjYjVHWnVERDNHUU5KUWx6RlM5MXJGWU95aWNqenBB?=
 =?utf-8?B?MFNWeVFpYnBwYXl3bkYweE5lMVFhVEtvYTk1UDFQTjBEZDgyZ2RZcXR2VG15?=
 =?utf-8?B?N2ovenFKeVhwMmxSQ0wwNWFCdVRWa2dUc1ppa1p6NXRDenBzRkU2UmNJOUNK?=
 =?utf-8?B?OHZQdFZhQStYelprenBqdjZXMnR0QXIyWWVTaFBPVmJ0bXMvRTFQaFY3b3Jw?=
 =?utf-8?B?MGxwaFFHTHJjemcrVmc2ZnI5SFh5M043RlBhRWtyN2dWdmZwU3p1ekZKV1FF?=
 =?utf-8?B?cVU0NERjU2hzL3cwY1ltSmdMa1gyNWNpRHZEaGFBcWdvSTU3NDNEakk3dkJ0?=
 =?utf-8?B?bG0ybW5aYnQzejJLbFplci9mZXBwcjNKbE02OWdpM1RHSFNJNEhnUWFENTZ5?=
 =?utf-8?B?OTUvMW5jM0FCMVNhUG9TK3dPY0hzMisrS0Q4NUE1TEdpbllDS2krVDE5YkJF?=
 =?utf-8?B?T1pWcVBBbDdRakNNbUdyNDFoRm44d0FZeXBxcFJsM0JHREE5bUk3VlhMRFNN?=
 =?utf-8?Q?ZfZ9xidLFD0=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(366016)(1800799024)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?Mjk0QXFibXAxWlZYb0xnZXM0YVhIN3p3MnN1dkUxWkkvK0YyMkRvaTU2MHVj?=
 =?utf-8?B?Z0s0dEo2WHQ2MU52MW1xY3BBb1VzTnhHblVaa3FxY0p5UDlWNUd3aVlWS0hH?=
 =?utf-8?B?QThzM3pSTnZTMTRHN2t5SlVSeDh1MnhKRzlGZnN6Y21LYjR3OHgvVmdzMzFX?=
 =?utf-8?B?MDdXSkpCMUYyRGoveHVReDdieUd2aGNuUFFhaXFEQmQ0aFVFVjhLTTVOWHdv?=
 =?utf-8?B?bCtMSTBxMk5IZFpTZlRuRHJNVkF0UjdQUzJSQUJCbVlqTFhidGNIT3ljSy9p?=
 =?utf-8?B?MDZsczhKWUNqS1ZLTmd1NjYvdWxKT241QXdKQkJES1lMbmhsWUppTkJPeHM1?=
 =?utf-8?B?TE0rMHFWUE5kVkV4WUN2Z09GOS9WVGFyb1lrYWJzOEdCbFZyVmw3MWhXeWE4?=
 =?utf-8?B?LzlRNUEzR1lZV2lOc1N6d2xvV3ZPQ0x0aDkya1puNHJBekNQVzJnVENLcWVs?=
 =?utf-8?B?WmNMSlAzZjZLMkt5aXpEcTdXQ29pL3lQdWdrb25iM2JHWSt6cFdMV0xzMmh0?=
 =?utf-8?B?TUtTeXFuVGNaNWUvM28rSURyT1RjUENrNm50M0QzTEFCcFU3MmlIa1JSMVI4?=
 =?utf-8?B?MFZ1QjlEVW9DM1RhYUZuUHUvWkdUaDliTlAyb0dickw0WGI4bloyWU9SaWx6?=
 =?utf-8?B?NlkrbnBJZUJXQW1vaFhCb2IydXFTa0hiNUVjYXZTdS82Nkcva3RGa0Njdk5r?=
 =?utf-8?B?Zmw5WHhWRFo2dWI2NHB4ZWJLUHJOT2ZlSW1nRmk0MzVveDBJZU9URU1zOUZJ?=
 =?utf-8?B?MWx2TDdnUGVEeXVZaGppRk1JM3U2dmF0OStXRUkwWFMrZ3M1RjBzai9mWVZV?=
 =?utf-8?B?cVkzNUlNa3JYYWVzVlpFN1dleW5uWVlvdkNFa0dPa1BsS0tkZU1qeHQ2UVJz?=
 =?utf-8?B?Z1c3VXFLc0FYTU9SLzdTeGlmWWhJRUFETFJiV1dzQStMK2taZHJVOVBQNzI2?=
 =?utf-8?B?TCtpdTNGUVBSNGFQVHBmUi9GZ1VHcXJYNmprMFFpV0dQMmJlbll3UDQ1eXRx?=
 =?utf-8?B?OTBLNmhwRHV4OERTVWZLUFVXZEtqYVpFMk1kRElZUUFQNzhyMFBGeVVCcEpB?=
 =?utf-8?B?UDc0K3ZaVlk0YjB2ZW41K1Ywc3V2ZUFyY1VDODlKb3BhVzlXYW5JQTM4MUs0?=
 =?utf-8?B?S0Yvb0lvUFpnMkFXNDZxRERxM29IYnU0Ym5XaEFEV3pMMS9ZcytQNE9acjlR?=
 =?utf-8?B?dlVHYzVxNzFkc0VKekJuNUczbnZMSmR0SHFvSk9YRHNycEJFWEN6a1dNTVJJ?=
 =?utf-8?B?ZTdyS3NxN2Z6Si8zOHZGWHk1d1hVV25BTFoxWURnbEYwVlZSdmwrSmRtWGpJ?=
 =?utf-8?B?U0x2RDZBU2pTOXYzZDZldFZDbGFNbytwRTMvMUE2ZE93K3dtVXRVMm9aTHI0?=
 =?utf-8?B?ZXMxYVFvT1BjaWVQZ1lmWVBNZWE0NVpyNStlYXg2a3AxWHhycWFxV3NzU1U0?=
 =?utf-8?B?QlFCeGlwbUI2V2hHV2FYbnVDUlR1OG4wVU9DOVVIbVZEUzc1bDR1cUIrYjg5?=
 =?utf-8?B?QklJYWIyYTNZUWhSNHJ4cFZFYkhjcy8xVHdvb2JoOXBCT2NDTGZoQWlrUmgw?=
 =?utf-8?B?VS9hcU5ZTVNmR004cDBXZkZ3cFFiR1c1STBiNWpSbzIxbDdsZVc0ZFphbjNG?=
 =?utf-8?B?cGJidHc0dFNEaXZwdnd3VjZRQ3YzcVhTMk9ldGxQVUNsNldYQlRuRG4vT1hR?=
 =?utf-8?B?cmE4UGx1STYrK2RiUlZmaFRCY2dNU2xRU28vbTI4blo4ZERjL1VXSjRyVHNI?=
 =?utf-8?B?NkxrSkFjMVg5SzRMcGJtSkYzQlN4azducHA4eFpHSERBTkNGZndRK2xYUEU2?=
 =?utf-8?B?NHBGZjgxUUNyL0NQTjBJcFFQY0NodWlIV3NreUUzTExLb0t2Qm1iclIyMDMz?=
 =?utf-8?B?YjMzaStlek9GUGk0YzlrNlRiRTdGd1huN0pvME9OeGJCalRQdTdqSmVhc0xh?=
 =?utf-8?B?MWg1N1hoek1vVDA3Z2VxU0NqUkVhQUhUUkZlKzBBNnRTUVdSSFl4dGlNeWk0?=
 =?utf-8?B?NnFGQVNCWGx3d0RFSjlOVWlMZG8wVHlaL21PaUo2NXdUc0IyT3BiU2lDSnlm?=
 =?utf-8?B?OGlsZ24yaFNCV2dOTEZpSVcvdVFEYWczK3pGZkhmZWRuTWNZanF4a24yTndZ?=
 =?utf-8?Q?CFV1wTC3mcwnOB/ioiN83wDGo?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 35c3de32-b126-4dcb-1f0e-08ddb3b58e1c
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jun 2025 06:57:31.5291
 (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: hJ135IyMoYvlZBv1NKZcOBvdexM1mYPXzfFIfxPKvWUcHQ4qGKLJBR/NRKhmWYhT
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB8361



On 24/06/2025 23:56, dmkhn@proton.me wrote:
> On Tue, Jun 24, 2025 at 09:49:39AM +0200, Orzel, Michal wrote:
>>
>>
>> On 24/06/2025 05:55, dmkhn@proton.me wrote:
>>> From: Denis Mukhin 
>>>
>>> Move vpl011 DT node parsing from common Arm code to PL011 emulator code.
>> It's not parsing, it's DT node generation.
> 
> Oh, that's right, overlooked.
> Thanks, will update.
> 
>>
>> We usually keep all the DT node generation functions in one place. I'm not sure
>> if we want to move them to respective drivers (i.e. vpl011 to vpl011.c, gicv3 to
>> gicv3.c, etc.). Not sure what other maintainers think.
>>
>>>
>>> While doing it pick the generic name vuart_add_fwnode() for DT parser function
>> What 'fw' stands for? Firmware? This function creates DT node for domU, so it
>> should better be sth like vuart_add_dt_node().
> 
> 'fw' stands for 'firmware'.
> 
> It should be some generic name because the function will be used on x86 to
> generate to generate the guest ACPI tables.
I see but maybe vuart_add_node() would be a better choice here.

~Michal



From xen-devel-bounces@lists.xenproject.org Wed Jun 25 07:08:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 07:08:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024370.1400257 (Exim 4.92)
	(envelope-from )
	id 1uUKEn-0001lm-0c; Wed, 25 Jun 2025 07:08:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024370.1400257; Wed, 25 Jun 2025 07:08:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUKEm-0001lf-UM; Wed, 25 Jun 2025 07:08:04 +0000
Received: by outflank-mailman (input) for mailman id 1024370;
 Wed, 25 Jun 2025 07:08: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 1uUKEl-0001lZ-ES
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 07:08:03 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20610.outbound.protection.outlook.com
 [2a01:111:f403:2415::610])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1e88318c-5193-11f0-a30f-13f23c93f187;
 Wed, 25 Jun 2025 09:07:57 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by CY5PR12MB6552.namprd12.prod.outlook.com (2603:10b6:930:40::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.28; Wed, 25 Jun
 2025 07:07:54 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8857.026; Wed, 25 Jun 2025
 07:07: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: 1e88318c-5193-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lWOGEGWyDB8tzCuEduuS0zUk7kyl5DV5kBSNhj31JGdB6mdZCOrgTZ9LHiuw58SXuQ/yazbvozCQxYUNjjtVVOd4spmDqj6b8e+OVcFFw4pFNriX1WtlUP1mamqjvyPXCJA2q3Hqr2FijUygGCIPDzLsEKtUsh+njk8DE4lG3vTRX3F0YRbDct1IKTjGQRS5UwePPzYg0I5kQ8xLoaw4/vHpW1sVj0Um1+Oh0ptDydJTKRMobGvzY9eonGyvnGGFGwwJghv5VRO03Lto7THocqUW5VqNxcEnjk07FfZByilZGuexsGHXnlaOOyvOvIZUXs7YTx7lDEVPLPCw37Gt+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=CtjlSkJ20liyj4cXzJrperPcGHouu4Jxydc/MkCdwVE=;
 b=H3gU7dIRwebrrZDmHdSlwFc1Ofu8PvjYTNJVOAL8ttlbfzyGHZPQvvLFAiqrDrwJLGbrUqort14OP9Co5I57BoZ7+IEJ4e9bftQPzbKgdyktSjvDNE7CDZ2cJcnzkn4yiUjYSKNe1upsUK7qvTzNgH0oElikVFCiSX7YDlSbHObmzXCvZCVxiDqtLdDY382MYlsg0Nud4c7L+Sxu3kYrGSpw2oqdv/V73K9o58WIebDivc+vsuwJqUbeg04cqECCJ3EQiD+eI/hDHBQii3oKSOP2HGpeYEHAJo1I4vT0ejEH7U1MaR9Rtdfvt1XwfRpY74lzmRfqI9G7CVhDo58wTg==
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=CtjlSkJ20liyj4cXzJrperPcGHouu4Jxydc/MkCdwVE=;
 b=2gYtkqFFGWJ5dQnf+5LrschSHw5zuUt+HUseWT6hv6CsBL957DCt++wJAAHNT2zXafDBo09dg41SqKjOXO6jD+adeSJ05V21eev8NP/wOu7ye9isD8vrm3wNy8wzD1dBA+iSxr9FgOh1EifNsVcJRFrhP5j0odTX8m5zePxtHKY=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <3daf1254-0acb-426b-b28b-57665f406c3b@amd.com>
Date: Wed, 25 Jun 2025 09:07:48 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 07/16] arm/vuart: rename 'virtual UART' Kconfig option
To: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com,
 anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org,
 oleksii.kurochko@gmail.com, roger.pau@citrix.com, sstabellini@kernel.org,
 dmukhin@ford.com
References: <20250624035443.344099-1-dmukhin@ford.com>
 <20250624035443.344099-8-dmukhin@ford.com>
 <070f16b8-c397-487c-bcb8-0ba13bad919b@amd.com> 
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR2P281CA0171.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:99::16) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|CY5PR12MB6552:EE_
X-MS-Office365-Filtering-Correlation-Id: e07ea026-feec-433a-a0ac-08ddb3b70134
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|366016|376014|7416014|1800799024|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?eDV3V1ZuZDM1MDBla0xXSHRyK2lYTzRmQmt0V2pXeURJQVNNYlc0REtvTVc4?=
 =?utf-8?B?eXlKRXBwZUpwa3lJWk8wd1dCUnM2UWJPOU9KYWNwZUZyTEJmZE5McnhRcE0x?=
 =?utf-8?B?eXlJUDBrQUgwVm9DZVRCSTl3eng5dDZic3BPNFdzMVdhWER1MWZ5QXJ0bURL?=
 =?utf-8?B?YWNXZUdkdjRGSWI2RFNTTm85U2Zrc1VYV2JVcmVjV3c4ajh4SDBwdmZ5enVX?=
 =?utf-8?B?S3FiTTFJV1NWYUs5d3R0SVN6YVJkNmU3SU5lV2tmbitYL3cySU4yK0dhVTcw?=
 =?utf-8?B?UkU5MnNvU3ZRbkFoTnlwZTEvemRHWnd0Rk5OeW54RUdDUmtUVWRzanlnenRH?=
 =?utf-8?B?WW1meWpDS3FpNDlaclQ3VWxDdnVRR0Yzd0NzQVhqNjhIVzQ1blgzendpUWhK?=
 =?utf-8?B?UHlTMVF2cjMrWDZEcXIvZjlqV1ljc1hOVGV4T0ZnQnROUDl3a1d0aGxlT3R2?=
 =?utf-8?B?YnNFZmgwQjVNK29RdDkyTERhbE9rUHcwV0h3b3NsM0NsZlAySVRmQStSTGhs?=
 =?utf-8?B?YVJhakwwYUh5S3kvdGkyWUMvZTNyYzUzYklDSmlHMVYwMkdUMnZ3c2s4ZlNS?=
 =?utf-8?B?ZmpaMTgyZHFEU1pDRXBDMUlGMG5mdkRCcC9JSzIyRzNPdWQ5ZGxZNVdsNmh5?=
 =?utf-8?B?a0RReExBK1RmZ2NlOTZBdTlncm0xcHl0TnNUcWNmWXkyR1c0K0ZVZStBTW1t?=
 =?utf-8?B?bmRmUS9kTUdQMkJrTmNaaVpqRGw0SHVpK1FIT0NxaWQ5TmpaMGlrWFcwaWRp?=
 =?utf-8?B?YnptZVArZDJZZldNZHE5UDRZaFVMQzkwU0cvMXJ1SXBGVkdHdzN0S3E1QVp1?=
 =?utf-8?B?eGdUVlU4aVRVV1Z4MGFhY01RdmZRTGlNdEl6Sjh3ZXJScTB4RFlMd2c5LzBG?=
 =?utf-8?B?SFBzeUhuTUc5SUpXV1Zmc0xKRmo1cVl4cnd6Ym1Rb1p6UGtaSEN6c0c2SmtH?=
 =?utf-8?B?ZFBiUmE5c2NvQVc0blZiN055WVhRMnF1OGJIZ210dmNFTG1jaFJnZXF5UGlT?=
 =?utf-8?B?RC9VcnVyRXJ4QkhTRmgxWW1YNWhPemJRbFN6NDdxKzFtcmlDUDQrejhYc2dq?=
 =?utf-8?B?U3RYSnNnL2V6V1g3dXJJVlEzbzlNK2NOcDFhbjU4NzZ2Y2c0MmRMM1VpLzBm?=
 =?utf-8?B?UjdjaDIzandQdTliZkhYUkpCOUxFNHUxQWdvZC9yQWQ5SkcrK0ZYZzBOYXdQ?=
 =?utf-8?B?Wmk1OEpiNjRLVEtJa1NMdy9FZGlaYjNiTEYzVEhMaUFaeGJVenM2WFhQdjVE?=
 =?utf-8?B?Tk1pTUVkYk9HTzg1S1JmTTZQMUhqaW9GdE5GeWszT21tL2N1dG1PT01Jb2hK?=
 =?utf-8?B?eXh0MGF5eDJ0MjRoRFhtdlNMZlQrdVpBTWtCbHAwYmh3Qkdvc2t3aGxJUDhR?=
 =?utf-8?B?T3dJMkRQNzdwTUNYYlhWQVc3TEZmS1ErSWlkWWFISjUySThLbTFsb0ZRYzh1?=
 =?utf-8?B?eHlXSDU0V1dyeEhMQm9BQXFOSnh2Y04wQzdZMll5eHNPM3MyMXBhS3ZuN0Uz?=
 =?utf-8?B?cEJSbHhkNUhmOVlOUCtJUGZpN1F0Y3dONzFDMms2aFo5QTRjMHJmTi9tdFBW?=
 =?utf-8?B?ckNPSzFCeElqbkxrZDFXbVBubEJCcW5XTGRjd2xjU2YyR0pTQUpVQ3VTa1Fq?=
 =?utf-8?B?b3lObzJSOHgyWVhtU2pUV2NQK1ZvTWFibXU3Ky9xbmUxUjdHcFpacjk3VUVv?=
 =?utf-8?B?R2lwREtIQ0NaVS9OYklyNWJxejBXYmhhOXVyMUw2ZGJ5ZXMzelVmdUs0L2o0?=
 =?utf-8?B?anV2OXpEckp4SXBGVXYvK2FSTGNlOFFZZUoweE9oR0hpU2NKRFFQd0I1bERj?=
 =?utf-8?B?MkZHZ09QOUdUQ3oxL08wVGFVOFBYUmE1amY2blRjanZZcmhXRms1L0pnbGp3?=
 =?utf-8?B?alM4aE5qRU4yY3NpN0RaT2JZR0tmUDBnOHd5Z0xTYjAwQVM1TU5FdzR3bW1s?=
 =?utf-8?Q?FbccWiuW7mo=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(7416014)(1800799024)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?TnpRcGQyREF6VVlhQWlkVlkraFFsMzBuT0R4UndBclEzOWxCd1BLU1BldUxw?=
 =?utf-8?B?YXBJQ1ZITE4rM3dESUJhb2l0b091RDE3bi83Z05OK1FyWTMxVy9NTCtpMml4?=
 =?utf-8?B?eVlCMm1qQ0lzeHorQyt5ZmZvbld0VnorUm53eFBoZWkyclBvQVhmUS9pdEVq?=
 =?utf-8?B?SmVOc0FTdjk5dzd5bXR3YjdoM0RIeTdSUDNBckNzZ1F2RTFubWVLWGlabWtv?=
 =?utf-8?B?NGRJMWxzbVpUT2gxY3ZXSDE0VXR6d25kQUorbkNLWUVUZWI4TnlwZWd1R3JI?=
 =?utf-8?B?V2p5dWFRcUtaMklqanJhcVE4SFRKbnFVMytOMU1LUUdNYnFPZEdlSmVoUi90?=
 =?utf-8?B?cDg4MSsxa1FzVks1ODBrR3FsNU5nQVNYcWhsQ1VZKzY0UVdIQ3pRTlA0WnBX?=
 =?utf-8?B?MHhISmU0ODQ0dXoxTUN6OEJnYjM0ZjEvcVNPbElOVTdKT1VGZjNwMFRYVkpu?=
 =?utf-8?B?SFlURkp5emM5STlMOEJWaWVsdEsvNzRzUW9oRzVOZkJYa2hFRVUvNW56S3Rv?=
 =?utf-8?B?NzQ3dVB3WlhmSk5zMGxhMFpyK1Q3NENyZnhmL3FCT0hLb29uV0NtR0RhOUF6?=
 =?utf-8?B?eFRpNjJoZitlRVNnLzNhTitDU0hsVEhZWE5kUnpqOThBUVdZaVpBbG5xOWNR?=
 =?utf-8?B?R1RHK3MwTmZ4djR0OUloSlZwdElEdGgwbGZCcWFLaXNBOU10c2VPUFE2NW15?=
 =?utf-8?B?QzRaVmJ3Yy9kVTFoTkY5Ynd5K294Vmw2dkRFOW96WjBJcnFYOFlER3ltRXJM?=
 =?utf-8?B?YWVDSXAzSzdueDluYzA1UEJTRnY3dldIdXJiTmk0U05SYVBGSWdacGJhd29Z?=
 =?utf-8?B?cnBYVkJCMTkyME9wdGVtRm03ZG1Kc080cUJUZ3pQaE50SmRRUTRRMGV2N3Fz?=
 =?utf-8?B?K1NPT3JLSmxTcktNOTcrcFY5RFByMjQ0Um1WaHdLZ0JZM2hpSTZ5Q3p6UDl3?=
 =?utf-8?B?THBJaE1za3lYTDRnZWUvK1Z1SjdiODlGR1RVSFVTMWVmY3BYcEIvbFVRSVAw?=
 =?utf-8?B?N2hHSkU1VGN0S09JUXlPOW9Rd0dsWmgwQ0RsL3ZLNXJuUFYyc3dwUkQ1eGNo?=
 =?utf-8?B?dG1LRXZJOWU2ZW5WSGRpL3BwSlpHNEVCZ0FXYVlRME8zb0tQUXZOOG5FLzRk?=
 =?utf-8?B?QTZPRjA1WlNIZTZLTFJrY3RpRmZmZ0tXUlVYelN0cncrdWRsWmhsYXkyOVBy?=
 =?utf-8?B?TWhxeXdZMThvQ3BSKzNkMjFSbWNRbVJoallpc1F5NWpTUkdNcW1OVzlackE4?=
 =?utf-8?B?WkVvTCsvOUU3N0dpMlNTcmhlMmNkSXZZMEY2Njd4WGg4ZlhUb2o3TFBpM0dt?=
 =?utf-8?B?QmN3UEJMMW9ha0l6Uk5HWjFjOEIxTWNWd3M0cUhsVXBiMEpPSXAveVZWSlVl?=
 =?utf-8?B?ZVRncDQ0UlVUT3llRkg1Y3RMYTNUcmlST1QvZHRXOEovUkt2cUJpWHh1WmNj?=
 =?utf-8?B?SW9hZnhJZ2J2TzNTSFBheVdobmlUV0lEUDVWdVJGRVlEcWhlc1hyak91WUpC?=
 =?utf-8?B?R1ZHSkVkN1FxZFZsbDNWSFMydWdnZ1F6M3VSSmFOeHNJMDVDcnlHd1gvdXh6?=
 =?utf-8?B?Z2RRUHp1TUFiUGY3dTFXS1I5TGpURm5ORFhJdHoxS3g5U3lacmVuREw2b0xG?=
 =?utf-8?B?ZG1KcTY1SlJlSTJMcGFzMDdOZWcwMC9FVDlHSHpXMElRSW15enJaZ0x0NU1D?=
 =?utf-8?B?K2ptU3VzeWJ4bEhFZEJBTWF0NTdLekhEQVEvby9TWEpZMXFQc0hTL2Z6N1Zp?=
 =?utf-8?B?S2RoRzZSR1hLcENzT08vNC9NSWU2ei9kZUp6cUVpSWhEWFNlZUU1MTE3ZkRn?=
 =?utf-8?B?ZWVyYmZ0NCtlNFlBaEJUY01rL1VCM2hCZzFKaTZJK2tFVnJGZkNvb29wWXhq?=
 =?utf-8?B?SFdUWk96OFFURVpkbzlIeEdkL1VHR0VuRWdWNzR5SjdYSVdPQ042M2ZtZWhi?=
 =?utf-8?B?eEJFTXh0Z055V1BZemM4N0JrNjNtejR4bEliRFJ5TkdkYUdpWm0rSVhIRjJk?=
 =?utf-8?B?YUc3Ri85Wkl2MEY5ZVZjZ1hmM25NQU5ZQmxLaHZ6eXByRDNkTnRzRWRFekI4?=
 =?utf-8?B?ZzZQdG1jQjdlUUhNZjZHV3ZnYk9BUGM3ZUlTOHJBVHpWQmorRzcvNVZ2SENn?=
 =?utf-8?Q?fZ9ru5PMMwjenv+koJwD6JSHy?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e07ea026-feec-433a-a0ac-08ddb3b70134
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jun 2025 07:07:53.8964
 (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: qvK3uNug0RCgcQHhiDos0l1eP+E6DCY9hDJMNNjl4JGrw08oQMLWnKPorpGI5wx3
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR12MB6552



On 24/06/2025 09:14, dmkhn@proton.me wrote:
> On Tue, Jun 24, 2025 at 08:37:22AM +0200, Orzel, Michal wrote:
>>
>>
>> On 24/06/2025 05:55, dmkhn@proton.me wrote:
>>> From: Denis Mukhin 
>>>
>>> Rename HWDOM_VUART to HAS_VUART_MMIO.
>>>
>>> This emulator emulates only one register and the use of the emulator is
>>> limited to early boot console in the guest OS.
>>>
>>> No functional change.
>>>
>>> Signed-off-by: Denis Mukhin 
>>> ---
>>>  xen/arch/arm/Kconfig              | 2 +-
>>>  xen/arch/arm/Makefile             | 2 +-
>>>  xen/arch/arm/include/asm/domain.h | 2 +-
>>>  xen/arch/arm/vuart.h              | 4 ++--
>>>  4 files changed, 5 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
>>> index 03888569f38c..b11cb583a763 100644
>>> --- a/xen/arch/arm/Kconfig
>>> +++ b/xen/arch/arm/Kconfig
>>> @@ -177,7 +177,7 @@ config HAS_VUART_PL011
>>>  	  Allows a guest to use SBSA Generic UART as a console. The
>>>  	  SBSA Generic UART implements a subset of ARM PL011 UART.
>>>
>>> -config HWDOM_VUART
>>> +config HAS_VUART_MMIO
>> I personally don't like this change. The current config option name reads much
>> better and clearly denotes the purpose.
> 
> In my opinion, the MMIO-based UART is a useful debugging tool for early guest
> boot, even when the guest doesn't run in hwdom or on Arm system.
The reason why this vUART is for hwdom is that is uses information from dtuart
(physical UART used by Xen probed from DT). This is to enable kernels used as
dom0 that had early printk/earlycon set for this serial device (as if they run
baremetal). Regular domUs have vPL011 and don't need hwdom vUART.

~Michal



From xen-devel-bounces@lists.xenproject.org Wed Jun 25 07:16:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 07:16:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024381.1400267 (Exim 4.92)
	(envelope-from )
	id 1uUKNA-0003WP-QN; Wed, 25 Jun 2025 07:16:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024381.1400267; Wed, 25 Jun 2025 07:16: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 1uUKNA-0003WI-No; Wed, 25 Jun 2025 07:16:44 +0000
Received: by outflank-mailman (input) for mailman id 1024381;
 Wed, 25 Jun 2025 07:16: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 1uUKN8-0003WC-Nw
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 07:16:42 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on2060e.outbound.protection.outlook.com
 [2a01:111:f403:2417::60e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 56ebc6cf-5194-11f0-a30f-13f23c93f187;
 Wed, 25 Jun 2025 09:16:40 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by MW4PR12MB7358.namprd12.prod.outlook.com (2603:10b6:303:22b::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8880.16; Wed, 25 Jun
 2025 07:16:36 +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.8835.027; Wed, 25 Jun 2025
 07:16: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: 56ebc6cf-5194-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=KGbjalnRBi203WN8q4mPFY9SD5pyVecyEx9Y0GZJeY9P3WFQVA2QJhLlI43FehqH+kWleWqaoM6jmKSRqYd6NiB2ldaqC9tdeYdsUroTRJ6bxtsHiBnMHqOm3PCBxGs1A7Mxgqkn6+wh/xt1H4w37Z/AK4dto2fNaaARNwp7Ya+mb6iNCINIVv34d3o+m4B+WOW0W+3htcgvS691RkCZ83bDTSgB5kPjZReofn2fr6bnbu++A4po354yMo09VC4ap+MUKWFtScs4kN8V7gikhVbGLrmGS5AO4gFIKDI1IbIBmDezAk+QNlS/SwhzGO4LvA4Gg5AnjLGZAcmre3wcMA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=50UXk7v/g9AC4US9wrzKl3fIkcen8nYuLvGMZhtnf5M=;
 b=VxzTUTY9OBqCEJlAeSK765g2tR5ayqSDADzLDR8opqZQ3OJirDcg72kclWoB+CxLL6YijaZXOhJRpfTIIldEEkBMyEaHuF8Xcah/qR3MjvhydU1YlRtq0YBE8gq3HdDlsaFkAB90jIXymQhvsgirxReqWo5TzpB/4+LtLr/Ty/qSfqGuK3aQa8TUmQ3Dkit8MZy8lDv7Jf0N8C2f90lyiP9RqRa537Z/trYINoU7EYIATq1JEDqKuKt68q9FiqbyxrXjtUjmD/CXnWhcWCoGDvUxEPGdTABpe6oCT9alSACtnBwkc5tR9FMq5nsnrmsGifODFTjsUTgttZ/LrCm24A==
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=50UXk7v/g9AC4US9wrzKl3fIkcen8nYuLvGMZhtnf5M=;
 b=ynLFrmWi5bcbMgcTBd3FvDPRawuw76DxZLy09Rlvg3S9iKLvrMKTaqs/x3qyWAt+oplCTU4i/CcC1sLwhKo6M3hx0U1xpS1FcrX0rUO/o+f8TICR03BpWAl+qH9CgBZhEY5Iax64gzJYhCaUUMOe8znYYMYFjzUW7Iwm6FbCwKA=
From: "Chen, Jiqian" 
To: Jan Beulich 
CC: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= ,
	"xen-devel@lists.xenproject.org" , "Huang,
 Ray" , "Chen, Jiqian" 
Subject: Re: [PATCH v6 7/8] vpci/msi: Free MSI resources when init_msi() fails
Thread-Topic: [PATCH v6 7/8] vpci/msi: Free MSI resources when init_msi()
 fails
Thread-Index: AQHb23yeMT8YFCMR3kaLDqQP1+DTK7QJCD4AgAme+gD//4QlAIAB4iSA
Date: Wed, 25 Jun 2025 07:16:35 +0000
Message-ID:
 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-8-Jiqian.Chen@amd.com>
 <773c448a-d814-458f-ad83-e9740e724408@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.8835.025)
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_|MW4PR12MB7358:EE_
x-ms-office365-filtering-correlation-id: 823f758a-10e7-4967-d8b4-08ddb3b8387d
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?WUIyUmU0YjFpQSsrWW5GMzVzL3lCc3dydWllemtIb2JXS2g1WlIxczZhaWhp?=
 =?utf-8?B?dlFXQ1FwcUR4bzU5RjYzNitFSFozTVF6djVpM3RFU3pLZHl5ZjJpOExoTUJU?=
 =?utf-8?B?SHlyN0oxUXU4MG9mQnBhS09majhTc09LeTAzd1V1UDJ2TTJOOUFGTG1QekQ4?=
 =?utf-8?B?N2xrUndGbGI3bWpXZWNiWklXbGxreGpWRms0NFJJaGc0WHV2V283TXF5dlNj?=
 =?utf-8?B?cWJSK29iRE5Nak0ybzlpVGx6bkozUWp6Zi92a0ZNVE83ZlB2RncxeUdXelVv?=
 =?utf-8?B?T05aY1pDS3BnZGR1eEx1akFPRGhjeE05ZEdVdGttK21qS1BnVXJtb04wcE43?=
 =?utf-8?B?TEoybmpkZzJ2MU5hYnlrL1ZOL0tRSlpyTzBvclY5S0g4VGIyUkw5LzNnU25L?=
 =?utf-8?B?eVZWNno2NXVpOUpjNEJrd2JrNHplR0RRZVBvWFMyMU43V2NwZXhQclhFV1Vm?=
 =?utf-8?B?bUljZDVZUTZ0QVlVVkxNejl2RDI1TEQ5TmY5eEl3UEg1Vmo3UlhhOUxIdGhR?=
 =?utf-8?B?cjg0b1BvUDdadUNONGF3YWVjV1UyWGhnS3BXRmtYRUpHa1U2NndxTWdTS0VT?=
 =?utf-8?B?WU9jNXhyV0E4U3B2QjdhVWtYY3UrMUU1MW9KdVdRZzVwRFoyQk93SGpwejVu?=
 =?utf-8?B?TU5QNGFUdWFNcXlqaHhWWE5sSndEMXpjL1RLa1NQbnhicW5McFRTUkhrYkIx?=
 =?utf-8?B?bE9qckdRZzlkYndzVStMK2lsOW8rMEpJaGZDYUdMR2pWV3Z3OTdMWFNNRlJB?=
 =?utf-8?B?WE1aZE5vZ3V0aW90QlVUU0dJKzBqMlVDZGxiczlkeDRiQWxOM2RNeURCWDFE?=
 =?utf-8?B?T2lXK1p3VktPOVFoOEJsOUtSOHQwcXVYd0IvYnQ3dCtVUXFvOGc4OXhCN3cw?=
 =?utf-8?B?ajVkUVQweGZTR2lkZjR6SDk3Q2VrbjhJSDFQa3poRjUrTXdNWkR0WEFHdms4?=
 =?utf-8?B?bzZENEw4S1liM3Jacyt2ZUZlYlo5Q1Q2YmxWN3phakZ4a1UzcllVNEJCWDNt?=
 =?utf-8?B?Z21Kbm9KTTZFREJHc0hqMFdHTFkrUVh2Y3FPb2Z5NElOalNuTGlmZGFZMkxx?=
 =?utf-8?B?MWtEdUx2UUh2Vmp2K1FrYUZsYzZ5OE1HZC9WdW5ybjFxc2lxMWxQeFJkUm84?=
 =?utf-8?B?MERHaWp6N0V5T2lkVjJOUkZWTytvVW5vd2VzVWZOd2NBNWN0WWVvWTZobDJH?=
 =?utf-8?B?OVpGWlA2NlFoMmdZMzVRaWc5ejdtbEZCemRXenArWVVoNUpqQTBqWkVvcnE5?=
 =?utf-8?B?d3ZCdmxuVFNwUVNtL0tnclF2MlVQNXZrNG9McURiZ1VSeVNSdXZxSFpXWmNZ?=
 =?utf-8?B?cU1Od0ZnaWNZcCszV1VURHdUYVN1MjBCTGMwYUZib1QybXNISUdTY3IzR1da?=
 =?utf-8?B?TjkxdFJ2czZoZnhlaE1LNUtzRlRaUnk2RURiRDFlMmpacVRmWGJqZVI3Mm5S?=
 =?utf-8?B?ek4zKzFRY2lFUnFJZDdWOE1GT3krcGE3Y2toaUdvMytQa054UXRJbjkvQnpl?=
 =?utf-8?B?OVZiM0lsSDVpUDVydXZIelpwOS83TEwzbXNrenR2ZFZJazZMaHcxbHhqMzZq?=
 =?utf-8?B?MGhZTEwvNjNTYVc4TXVON0xWNWkrcU10L3NNanMyYmJrNDVKdU5oL2xWQ3A4?=
 =?utf-8?B?OENzWDBnSDIyRTA5Q0VQVkxkVjBIY3pPMnJ3Qm9XYndwajJRQm4xRDQvdmVS?=
 =?utf-8?B?UlNQSEJ6WDB3U2tra25YeG5SNVUydDZMU0FLTWp1ZmY4RWhTNDNkOFZML0Vz?=
 =?utf-8?B?ODA3MURNdTdzY09BRmFlQnArQWw2NHE3S1FZUHNVNjNpOElKUGxsV28wRnVP?=
 =?utf-8?B?ZmQwVGtVTUNTUllUZ2lzbE9BRGxqWUI5MEo0WVpkU1FnOHBSK2dwVVFLQUIy?=
 =?utf-8?B?eUpqaHY3RlQ2bDgxdXMvdFh0RWdzbVNjUTIrK0ErUk1QZlZWdU5pam4rME1P?=
 =?utf-8?B?NG9OSnBhdmgyUnVuSVBWVGJaUkR6Q0lSNWVqRjkrZitkQXowSDRxcXB4dlRE?=
 =?utf-8?Q?Mws0Q9xMVqO7ESk6RtBM9brOmbrt08=3D?=
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?MnB1aVR4cVovbmdWQWFVUkNwNHp2UTBmeFZMYlBsZ2gxVWRlUnVtM0pXcVFG?=
 =?utf-8?B?bWp0cmpwMVhHUEpwOE5VcTZJRnJpenV3WWdjeHBha1JzZW52YlFMK2IwYTdj?=
 =?utf-8?B?RnVOMW1obFVqMVc5S2JnQmhYa3VUVmYwbzZCNkJpcHk0RWxZbHpwUXlzNmpm?=
 =?utf-8?B?RmcxaFd2aEFEMnhVWXRBVnlSWVNOVGl4RklOQW5vMVJFY3hWOEo5UHA1ZTNt?=
 =?utf-8?B?UThkalZ1U2FvdXU3RVM2ejA2SjRwYktuQjdoUnFSSVVMQnJCZDZzNkVzb0d6?=
 =?utf-8?B?akZJNzBHcWVETEhXVmtFZW5pbjFyZ3VRUGo4Ti9JR2pjRS9majZsNUJQQ0E3?=
 =?utf-8?B?QjhvN21tVDdVU2tsbEdjTjZ0ci95UkhMdzZ1c1ZnWlk2MEdEWUtSMmNPZVhj?=
 =?utf-8?B?ZVpLNWZnMlNXVDdscTkzWlMyWVBNZUtQUkNhek9GMlRLZjBwMnVzV0tqSGpQ?=
 =?utf-8?B?bUs2ZDJrU0pMSUdDNEJDVStyM092RXFETkJLc3FtQmlSKzZIU0ZmOWhMZFdB?=
 =?utf-8?B?ZW85Undwby9YN2t0N3VHTU0wM2pDeXNRcGlCZkpHUE9LLzFDMGIrdzlBbG5M?=
 =?utf-8?B?YVRrUVJFQUt6VDhQQUFZYW5LMVVKZ0tXc2YzUnlCc0diM3lxQ1V5aDBqamt0?=
 =?utf-8?B?N0tsMXlNRW9Sbm9rNzV1MytEQUJTNE04NHJJbjZIbWJEcjBuNWdVRUhQZmVw?=
 =?utf-8?B?OVp6MlJMeFRla3ZubnI5MUgrcFkvcndGNWVKWDdka1hnUnRpV3FRN0FuVGk1?=
 =?utf-8?B?Q0tQWXlQb3U1ZGtlcUtWT1QzdFdVOUZCekE5a09EbnFhdTAxMVdzNStZbWx0?=
 =?utf-8?B?TFJ6ZlNUa1owc0VtNTJnQjNUblc2bERTa0lSMGJuTGlCVXJxRFQ0OG5iRHJa?=
 =?utf-8?B?VGFxcGpnZS9tdFEwNGFjQWhYMlRJUkRsbExpdXU4MGdWR0lwL1Q4QW53ZWlB?=
 =?utf-8?B?TTduRDZvOEV0RGFMaHQyK1lkdXhDQUtsOHpqblRXUmUra1lITGJzdnZkeGpK?=
 =?utf-8?B?bHF1bXJIT1Y4QURrczg3VENJZ3MzZWd3SmJtVWZBeTZTOUM1U3FkaW5LTk5U?=
 =?utf-8?B?ZHlydmJLMmJrMHJHWGRHQXpsK3pDYU1IRmw5c3RQR3lxVXFEeEhadUQ4cGcx?=
 =?utf-8?B?eDR1MmZrSDZXSktpdDU2TzZra0pIWWFwZmtYUDNqRzUxZlF3cnJCMUpIdFBk?=
 =?utf-8?B?d3dtaDR2dkEwdzRwTHY1U0dLaWEwcnhTS0J4M2xwSVVoamlMaGdyWEhvN3Zk?=
 =?utf-8?B?ZUQ3RURqeFRJUHcwMmhXU05pTUZORXBLK0pQQ0YvQzRhZFFDWXhHQ1dtbW40?=
 =?utf-8?B?SzBSdlFzem9pYnhpZUJqM0FGWk1zL2Y2c3duNTBlVVFjV2ZnTU9QUjVHdkNN?=
 =?utf-8?B?blJ3b0ZOSlBwRTZ2MVhGSGdreHl0WER5WkhrTEdZYUIwU3hlemF2R0ZmU2Uw?=
 =?utf-8?B?OU9hMURvSlV6c0k0YmgyRWRyanhJbzVDZ1ZxRCt6OWxmSmlmQWcvYmJnTW5s?=
 =?utf-8?B?YU56RlBqNHNiMDdsenkxeEl3VTYvK09FZHNrZzh5Ui8rNVYweHZLb1JmUllK?=
 =?utf-8?B?QVZFclY3NkxkVWVyekc4Q0FqTzhhUzgrT1FZc0xyVWlsaEk1RTJnbUlDdmIx?=
 =?utf-8?B?RTRMQTg1UWc4Q0wrSWQvRnlQbTJHT2kwbTVKVFQ5dlBqTUJSWjB6Mzd2OVMx?=
 =?utf-8?B?QWFWeVNIVkZXbXhIdWpGNkNVN1VVd01PUFh1MmQvenpielo3Z2p0L3BSMGkz?=
 =?utf-8?B?OVB6aHF6QXN5NUhCcE8zSU5zcHRJeHhhd2NsN0ROVDA0RDhLN2dORXNmM1Ji?=
 =?utf-8?B?eHEvUk0vR0xYWTZpVWo5aUtJTW5IUDIxc3hQcGlIRHN5R1k1RFFnbTFKa042?=
 =?utf-8?B?cE9HWWlkUUR0NjdXSWZUQjhIc0toTTdRdU1uUTRnS3hXTm1zZS9LaG9wb2Zo?=
 =?utf-8?B?N2lnMWdPKzE5VnZRQkthZnNwRWJjQzFHSk1KQUtncFBJMm10dFNnakJpNjEx?=
 =?utf-8?B?RTNEam5tdERYRHp3cEZqTUFhRXlpV2hGbmw4MWcyRWxHZENNemRrbkFvNVlX?=
 =?utf-8?B?ZG50VG1FeXBJeVBmUEpEbVJiZlR6MXNnUk4wWG1EcVgrYXdhdXhieUJaaEdF?=
 =?utf-8?Q?x45A=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <5B924DD1E380C34B9F2923A9AB94F622@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: 823f758a-10e7-4967-d8b4-08ddb3b8387d
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2025 07:16:35.9127
 (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: LLLsMC2qjBYcD9zLmdFUYOImaj3JqnI6P63Hi75FVcOFe69Cvm1ulGtVakrRytCNfc4mnqSx36nlyUKd8US37A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB7358

T24gMjAyNS82LzI0IDE4OjE3LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMjQuMDYuMjAyNSAx
MTo0OSwgQ2hlbiwgSmlxaWFuIHdyb3RlOg0KPj4gT24gMjAyNS82LzE4IDIyOjQ1LCBKYW4gQmV1
bGljaCB3cm90ZToNCj4+PiBPbiAxMi4wNi4yMDI1IDExOjI5LCBKaXFpYW4gQ2hlbiB3cm90ZToN
Cj4+Pj4gLS0tIGEveGVuL2RyaXZlcnMvdnBjaS9tc2kuYw0KPj4+PiArKysgYi94ZW4vZHJpdmVy
cy92cGNpL21zaS5jDQo+Pj4+IEBAIC0xOTMsNiArMTkzLDMzIEBAIHN0YXRpYyB2b2lkIGNmX2No
ZWNrIG1hc2tfd3JpdGUoDQo+Pj4+ICAgICAgbXNpLT5tYXNrID0gdmFsOw0KPj4+PiAgfQ0KPj4+
PiAgDQo+Pj4+ICtzdGF0aWMgaW50IGNmX2NoZWNrIGNsZWFudXBfbXNpKHN0cnVjdCBwY2lfZGV2
ICpwZGV2KQ0KPj4+PiArew0KPj4+PiArICAgIGludCByYzsNCj4+Pj4gKyAgICB1bnNpZ25lZCBp
bnQgZW5kLCBzaXplOw0KPj4+PiArICAgIHN0cnVjdCB2cGNpICp2cGNpID0gcGRldi0+dnBjaTsN
Cj4+Pj4gKyAgICBjb25zdCB1bnNpZ25lZCBpbnQgbXNpX3BvcyA9IHBkZXYtPm1zaV9wb3M7DQo+
Pj4+ICsgICAgY29uc3QgdW5zaWduZWQgaW50IGN0cmwgPSBtc2lfY29udHJvbF9yZWcobXNpX3Bv
cyk7DQo+Pj4+ICsNCj4+Pj4gKyAgICBpZiAoICFtc2lfcG9zIHx8ICF2cGNpLT5tc2kgKQ0KPj4+
PiArICAgICAgICByZXR1cm4gMDsNCj4+Pj4gKw0KPj4+PiArICAgIGlmICggdnBjaS0+bXNpLT5t
YXNraW5nICkNCj4+Pj4gKyAgICAgICAgZW5kID0gbXNpX3BlbmRpbmdfYml0c19yZWcobXNpX3Bv
cywgdnBjaS0+bXNpLT5hZGRyZXNzNjQpOw0KPj4+PiArICAgIGVsc2UNCj4+Pj4gKyAgICAgICAg
ZW5kID0gbXNpX21hc2tfYml0c19yZWcobXNpX3BvcywgdnBjaS0+bXNpLT5hZGRyZXNzNjQpIC0g
MjsNCj4+Pj4gKw0KPj4+PiArICAgIHNpemUgPSBlbmQgLSBjdHJsOw0KPj4+PiArDQo+Pj4+ICsg
ICAgcmMgPSB2cGNpX3JlbW92ZV9yZWdpc3RlcnModnBjaSwgY3RybCwgc2l6ZSk7DQo+Pj4+ICsg
ICAgaWYgKCByYyApDQo+Pj4+ICsgICAgICAgIHJldHVybiByYzsNCj4+Pg0KPj4+IFRoaXMgaXMg
YSBkaWZmaWN1bHQgb25lOiBJdCdzIG5vdCBhIGdvb2QgaWRlYSB0byBzaW1wbHkgcmV0dXJuIGhl
cmUsIHlldA0KPj4+IGF0IHRoZSBzYW1lIHRpbWUgdGhlIGhhbmRsaW5nIG9mIHRoZSByZWdpc3Rl
ciB3ZSdyZSB1bmFibGUgdG8gcmVtb3ZlIG1heQ0KPj4+IHN0aWxsIHJlcXVpcmUgZS5nLiAuLi4N
Cj4+Pg0KPj4+PiArICAgIFhGUkVFKHZwY2ktPm1zaSk7DQo+Pj4NCj4+PiAuLi4gdGhpcy4gVGhl
cmUgbWF5IHRoZXJlZm9yZSBiZSBtb3JlIHdvcmsgcmVxdWlyZWQsIHN1Y2ggdGhhdCBpbiB0aGUN
Cj4+PiBlbmQgd2UncmUgYWJsZSB0byAuLi4NCj4+Pg0KPj4+PiArICAgIHJldHVybiB2cGNpX2Fk
ZF9yZWdpc3RlcihwZGV2LT52cGNpLCB2cGNpX2h3X3JlYWQxNiwgTlVMTCwgY3RybCwgMiwgTlVM
TCk7DQo+Pj4NCj4+PiAuLi4gdHJ5IHRoaXMgYXQgbGVhc3Qgb24gYSBiZXN0IGVmZm9ydCBiYXNp
cy4NCj4+Pg0KPj4+IE1vcmUgZ2VuZXJhbGx5OiBJIGRvbid0IHRoaW5rIGZhaWx1cmUgaGVyZSAo
b3IgaW4gb3RoZXIgLmNsZWFudXAgaG9vaw0KPj4+IGZ1bmN0aW9ucykgbWF5IGdvIGVudGlyZWx5
IHNpbGVudGx5Lg0KPj4gRG9lcyBiZWxvdyBtZWV0IHlvdXIgbW9kaWZpY2F0aW9uIGV4cGVjdGF0
aW9ucz8NCj4gDQo+IE5vdCBzdXJlLCBzb3JyeS4gQnkgIm1vcmUiIEkgcmVhbGx5IG1lYW50ICJt
b3JlIiAod2hpY2ggbWF5IGp1c3QgYmUgY29kZQ0KPiBhdWRpdGluZywgcmVzdWx0cyBvZiB3aGlj
aCB3b3VsZCBuZWVkIHdyaXRpbmcgZG93biwgYnV0IHdoaWNoIG1heSBhbHNvDQo+IGludm9sdmUg
ZnVydGhlciBjb2RlIGNoYW5nZXM7IHNlZSBiZWxvdykuDQo+IA0KPj4gICAgIHJjID0gdnBjaV9y
ZW1vdmVfcmVnaXN0ZXJzKHZwY2ksIGN0cmwsIHNpemUpOw0KPj4gICAgIGlmICggcmMgKQ0KPj4g
ICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAiJXBkICVwcDogcmVtb3ZlIG1zaSBoYW5kbGVycyBm
YWlsIHJjPSVkXG4iLA0KPj4gICAgICAgICAgICAgICAgcGRldi0+ZG9tYWluLCAmcGRldi0+c2Jk
ZiwgcmMpOw0KPj4NCj4+ICAgICBYRlJFRSh2cGNpLT5tc2kpOw0KPiANCj4gQXMgSSB0cmllZCB0
byBpbmRpY2F0ZSBpbiBteSBlYXJsaWVyIHJlcGx5LCB0aGUgZnJlZWluZyBvZiB0aGlzIHN0cnVj
dCBpcw0KPiBzYWZlIG9ubHkgaWYgdGhlIGZhaWx1cmUgYWJvdmUgd291bGQgbm90IGxlYXZlIGFu
eSByZWdpc3RlciBoYW5kbGVycyBpbg0KPiBwbGFjZSB3aGljaCBzdGlsbCAod2l0aG91dCBhcHBy
b3ByaWF0ZSBjaGVja2luZykgdXNlIHRoaXMgc3RydWN0Lg0KSG1tLCBidXQgYWxsIGhhbmRsZXJz
IGFkZGVkIGluIGluaXRfbXNpKCkgdXNlIHRoaXMgc3RydWN0Lg0KU28gaXQgZG9lc24ndCBleGlz
dCB0aGUgY2FzZSB0aGF0IHdoZW4gYWJvdmUgdW5hYmxlIHRvIHJlbW92ZSBhbGwgaGFuZGxlcnMg
YW5kIHN0aWxsIHJlcXVpcmUgeGZyZWUgdGhpcyBzdHJ1Y3QuDQoNCj4gDQo+PiAgICAgLyoNCj4+
ICAgICAgKiBUaGUgZHJpdmVyIG1heSBub3QgdHJhdmVyc2UgdGhlIGNhcGFiaWxpdHkgbGlzdCBh
bmQgdGhpbmsgZGV2aWNlDQo+PiAgICAgICogc3VwcG9ydHMgTVNJIGJ5IGRlZmF1bHQuIFNvIGhl
cmUgbGV0IHRoZSBjb250cm9sIHJlZ2lzdGVyIG9mIE1TSQ0KPj4gICAgICAqIGJlIFJlYWQtT25s
eSBpcyB0byBlbnN1cmUgTVNJIGRpc2FibGVkLg0KPj4gICAgICAqLw0KPj4gICAgIHJjID0gdnBj
aV9hZGRfcmVnaXN0ZXIodnBjaSwgdnBjaV9od19yZWFkMTYsIE5VTEwsIGN0cmwsIDIsIE5VTEwp
Ow0KPiANCj4gWW91J3JlIGxvc2luZyB0aGUgZWFybGllciBlcnJvciBoZXJlLCBpZiB0aGVyZSB3
YXMgb25lLiBJZiB0aGlzIG9uZQ0KPiBzdWNjZWVkcywgLi4uDQpCdXQgaWYgcmV0dXJuIHRoZSBl
YXJsaWVyIGVycm9yIHRvIHRoZSBjYWxsZXIsIHRoaXMgZGV2aWNlIHdpbGwgYmUgdW51c2FibGUs
IHRoZW4gc3RpbGwgYWRkaW5nIHRoaXMgaGFuZGxlciB3aGVuIGFib3ZlIGZhaWxpbmcgdG8gcmVt
b3ZlIGhhbmRsZXJzIGlzIHVzZWxlc3MuDQoNCj4gDQo+PiAgICAgaWYgKCByYyApDQo+PiAgICAg
ICAgIHByaW50ayhYRU5MT0dfRVJSICIlcGQgJXBwOiBhZGQgZHVtbXkgbXNpIGN0cmwgaGFuZGxl
ciBmYWlsIHJjPSVkXG4iLA0KPj4gICAgICAgICAgICAgICAgcGRldi0+ZG9tYWluLCAmcGRldi0+
c2JkZiwgcmMpOw0KPj4NCj4+ICAgICByZXR1cm4gcmM7DQo+IA0KPiAuLi4gdGhlIGNhbGxlciB3
b3VsZCAod3JvbmdseSkgZ2V0IHN1Y2Nlc3MgYmFjay4NCj4gDQo+IEphbg0KDQotLSANCkJlc3Qg
cmVnYXJkcywNCkppcWlhbiBDaGVuLg0K


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 07:21:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 07:21:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024390.1400277 (Exim 4.92)
	(envelope-from )
	id 1uUKS0-0005B3-BY; Wed, 25 Jun 2025 07:21:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024390.1400277; Wed, 25 Jun 2025 07:21:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUKS0-0005Aw-8q; Wed, 25 Jun 2025 07:21:44 +0000
Received: by outflank-mailman (input) for mailman id 1024390;
 Wed, 25 Jun 2025 07:21: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 1uUKRy-0005Aq-Tj
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 07:21:43 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on2061a.outbound.protection.outlook.com
 [2a01:111:f403:2009::61a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0a3b48ee-5195-11f0-a30f-13f23c93f187;
 Wed, 25 Jun 2025 09:21:41 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by LV8PR12MB9155.namprd12.prod.outlook.com (2603:10b6:408:183::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.30; Wed, 25 Jun
 2025 07:21:36 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8857.026; Wed, 25 Jun 2025
 07:21: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: 0a3b48ee-5195-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=nB+KLDcsuank98k9rUrhn7djY2iY3pRDMs2joCDWGGZPctdFvS5bFYyEkVabHa5c4dTlNps9SRmQfIVSV/azaWYGvPmPByjmalJEzAnMIH/Axfzh4K6ISp5kaijPGa1ZlRdRo/QXjZOq2xMzTEkNFKuCqu4NxqmZLnoHraKKeB7SiDCz8JRVAp4nxAQEnkPprtVGb0pqGVQ/oQJ/epXZmt/3ymd6m0Aylw6dcqsRWwA8o/ablnPZX0hFURhGAA/PTPgHtp2Jv8UjtK28OVeinyk2zLabPxlYZrOsPt1TypnVvNTcvlNBZop2BFigeXetOESNxLIEtIO48hKm4OSgGw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=gonRy1FaP36eKCrWW86Ilg4H11Yign/dP9BjkpiZdZ8=;
 b=EcsF0lTr7RKXj7h6lO6e30pbncSPPFTdqL3gMKi/dOfJ/9pR4W3sGtCtvYH4laJoSHauTczPljeZdigw8QMV04qaEPejcFc2vuANIIMM1u5GSUrzy3wxrD3WMwDIZ9zny1Sh498gf94qQ3M1hvYTTNVG4vsv6Q0WZVBE4MLTNXEYJPajc6SGWsfcHKeEgYMKf0iguUvkdedkq92PTfek29+fwceUPRyZaqXpeVjVbb26isexIV5nfoiP3GVE7qeoY3CZxMwPFpapt7uKAH+DJCYJvt7/yScj7NoRW7IkpPus46qQuBBDpgltUIU6mmncFJfGQ2hmMC3zBFHYEnJ2Ng==
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=gonRy1FaP36eKCrWW86Ilg4H11Yign/dP9BjkpiZdZ8=;
 b=KIy8i6ENDHFPKZkiUR4jszHorOwm+SoK1K9GIBhNauc40dtY4FNmKsrumY06bVXur3QR/TlRo0CQiujLRZSMVb5UZUcTi8GC0a+YvRamlCbOH/0erROV5g0VaRt8M2Mvy/+dboQG74Tp64UpR4cQbuoEvnWxqkHReIUUm1x3Q1g=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <22990854-7048-42eb-b48c-5f79115e8170@amd.com>
Date: Wed, 25 Jun 2025 09:21:32 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 05/16] arm/vpl011: use void pointer in domain struct
To: dmkhn@proton.me, xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com,
 julien@xen.org, oleksii.kurochko@gmail.com, roger.pau@citrix.com,
 sstabellini@kernel.org, dmukhin@ford.com
References: <20250624035443.344099-1-dmukhin@ford.com>
 <20250624035443.344099-6-dmukhin@ford.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250624035443.344099-6-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR2P281CA0109.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:9c::8) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|LV8PR12MB9155:EE_
X-MS-Office365-Filtering-Correlation-Id: 6d93572e-1863-407d-0f89-08ddb3b8eb7d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|366016|376014|7416014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?cm4yNVBFL0RaVEViRTJpS0NlWUd4SitVakxrZ2xvdi9zN1RNRGkvTXl4ZlA0?=
 =?utf-8?B?NWZiT0RzR3pmNzUrODEwZ2g4MTF3azlnOVk5Yy8zZjJJMDVLUG5CRGo2dmhD?=
 =?utf-8?B?Q1hyb052RTFCdWNpVnh6eHZnRFVNYW56UzVaTFVuU0Z2enpJY1ZjOW9VZlNF?=
 =?utf-8?B?RW83dVhKNWdYYUxUNXVFbXJ0NGJpSVJBemFMcXgyUzFjbzZrOUtmQ2l0bDYr?=
 =?utf-8?B?dXoydVpBK3lFYkt3THRycG1JNVU4eFp2b3hmZlhGdEJtbi9CWVBmSUxDVUo0?=
 =?utf-8?B?ajFKNkdWU2NTdW5KeGVEOHRaU1RTOENYMlJyVlRidFUwK1NIRFJDb2ZKSFBP?=
 =?utf-8?B?TDlINy8rUGxvNUdMREJPOXdPN0VWZE1xWVpxNmFKYjVzNktkU0ptallTTXVj?=
 =?utf-8?B?VXBzc2Mxa1pONEZ0dmZvVFNIY0NNN3BBd3dQQU43MG9vYWNhRVVxV0tKZUJJ?=
 =?utf-8?B?eGs0L1p5Nklrd2NQK0lQeDZEYzlJemZKa3pjMXZTb0xwbDdtZDBlbnVhQ0F4?=
 =?utf-8?B?MWtlbXhKLzVmU0NFdGFhRFh6Sy9VNjRPczROdDYxOFE3SjlKVDFvTTEyRm5M?=
 =?utf-8?B?S1J4VGNiQXB0RVRaa09EckNUbGl6SDFoNlhReWJKT1d2NWpYTVd2cUpNV2pR?=
 =?utf-8?B?aGl0WEdrdGtvVnArQnNvWUxINHgwVlg1dTNmSGw0T3VUeDR6ZXV0VFovUFBm?=
 =?utf-8?B?VmJuU21aSjJhQ3IyVHp0OUYzbkNKZ0RIbjlRa05uNXBSODFocnlBNkZZY1By?=
 =?utf-8?B?aUExUHhiblhuNGRISXBrZlliZG1NMldQY2xaYitYWHhCYW1GYWd0Ymh5UGJP?=
 =?utf-8?B?N1FvNFpPS3ZaSUJaaHJTelBNUVhLOFdVZEFpczRFWkVXYkFWTzl6TnB3K3JO?=
 =?utf-8?B?ODcydEkwZ0d5OEFTdXNBN2dIWnJtbk1RY1d0ZFdTL2NtRDZSc0dPZkY0S2NX?=
 =?utf-8?B?V3JWd0U2Qks3M2hsVXJ4YUdJaDc1UFFvdVdRVEZvU3B6YTZCSzNWSWIrRHZr?=
 =?utf-8?B?UEt3SGV2cko1UmZNajBVb3BhRFBSdUJLeE5BdFF6WUUwcFN3ZXFWU3ZONlla?=
 =?utf-8?B?MjF2OWlCeFdoRCtaQzdjcHFIYm01S1lMcklMUmdjWnl2NTlUbTFTQ0ZFdnZ2?=
 =?utf-8?B?eDZ5UDQ4RjBsZ2FNV3ZqR0g0QXd0djZuSzVFSGRIZHZuNVJSOG9peUZibmtM?=
 =?utf-8?B?b01PMHJOOURCT3J3SVNnelFWc29ZUSsrVFRIWExGN3IxcnUxRTZVSHJhOWRT?=
 =?utf-8?B?eVp5SHE2QnNSMVBTL1h2dkkwZXQwb2lURFZ5Q3JLQ0kxalNLdnhQWXU3T3Za?=
 =?utf-8?B?ckVxOHVNT054TmFScURBSFpPa3g0eVlMVUs2S3RyRk9JYXNLOVVWb2ZQNXZW?=
 =?utf-8?B?VDM1bjc1YS9XRVEzSmN3SHpEKytKQzdUQlREQ2c2dTlzQzhFRUFuMGFXUktl?=
 =?utf-8?B?NDFWTEZWK3BlSDF2TC80ZVAvK2NPUytYZjhJQndkczJJUEZLU2lZU1ZDcUhY?=
 =?utf-8?B?Q2tRdDlmWXRzVGQ4V2lmWFlKSGpma2JXUDhNSWJweXMrUVhyQzJRR2l1WXkw?=
 =?utf-8?B?c2QrS0hCdVAzVXBnZHd0QktvSzVVTXkwWTAvb2NYb1dnSUhiN01xMUZlcm55?=
 =?utf-8?B?REVndXN0dkFIYXlXUUxvbmFvSGIrams1eU9kWHRaSGFCSUJiakVzQm1hZkJk?=
 =?utf-8?B?Q1BIbk5nYnNxbDRJcktkeGxNRm5hcjFwZnAzRjY4ZGIyWVJ5em9QMEdCT1g3?=
 =?utf-8?B?N0xxQ0pJY0JuenBiSVZYSVk4MWQzOVVLdGJubXhWcWJqb0xjYjRFb3pJZ2RY?=
 =?utf-8?B?bUpIaS9tcGFJOXpEa3R3Z3JTRmRJR1BwV21Rdm9hdHhrQW41am9GeFk5VUtV?=
 =?utf-8?B?ZThaSUVzZXlVNXR4TW5FaFFqZFZlVXZ1VGI0Vno2QVNnTGc9PQ==?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(7416014)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?ZE1ZTXVObGl6eXVvTllOZ2pYbXZ1NlZpTWg5SktuOHR5TUc4aUtabXpEcVR3?=
 =?utf-8?B?NEpHOEFZN3hKcXF0d1dWZnltRnBiR2JWL0Z3bCt6cFhDTmR4VXYrRWhjUW4x?=
 =?utf-8?B?WWxVTVV6WU43VGswTGYvT3g5TlczTUVidFJoS2NsMzEreVlmRjZoTDFnZmpq?=
 =?utf-8?B?SUwvbmpTZzJKNHE0UXZuaWZwZWlrREg3NFdiNWFhUDNBZVVHMGpmL3JkQ2tY?=
 =?utf-8?B?bm5KMTFrc0hGd21sWk1ZUjl2c2Y4K041TW1vc01pTkFwVExOZ29UUWsrSElm?=
 =?utf-8?B?ZUZQU3JhSGF0TFQ2Z28zdTcrZE5rb0dPdEk3Sk9yNkJsbVprWWNRbnpvZGht?=
 =?utf-8?B?ZmtTRlQrL2lkc1VkWVYySm0ydXJQeW41QzdVZy9jRzN0WGZSMEtkdHZwM0J5?=
 =?utf-8?B?cDd5MDFxa0lJaENldXpQUWRxVkw3WnNsTFFPRzV1NXdPcVRGS1A2ZG0yUlN4?=
 =?utf-8?B?NlQzWTRhRFByRXk5U3krb0R1UVBNTXJacU44bEVhS3NVYlJyZkJCcTFuWEpK?=
 =?utf-8?B?alloZGhJVWl1dHBnQlFqSkZ4TkRSdlMxOUx2SDNoYUFyR2psUWcrNFBpS09L?=
 =?utf-8?B?N0pVdkpXWDgva2lqVHROUjNIR2gzZ1piVzRVcUxHRlF6VFZaQlFvdldYcDRo?=
 =?utf-8?B?b1g4YUVGV2RNZkxvWWNaS1JGa3YrT0tRR1orbVEyUks1SFVEaUpCWFFHODdH?=
 =?utf-8?B?RHNhMjFBeEZvUll6K0VvZmxwcDhFMFc3RkhHM0J4UmtaTDgyRHYxempXakF0?=
 =?utf-8?B?Q0hGSGlqMklQVkdCWU5YVnVVUk94L1RWWks1cGRTaWREYVpqcXR2dUdGbStO?=
 =?utf-8?B?bG9ZeXRzQTNPRjJTOEhuQ0ZGeDk2TVdsazhyUmRYR0JpOVRneENrYTIxNGhv?=
 =?utf-8?B?bVdKdnNPd2ZZcUVwYU9XSWZ2UlVCempQQ0wrQjhoTEtuV3ZNbVVNY3ZCNzY2?=
 =?utf-8?B?amFzN0ZOQWpaSSsrL2RNWTc4SkF3SWhNSkJ2dkkyWVlQRmFmaTJyOHBwTjNo?=
 =?utf-8?B?L3UxdjZJaTNtazZUYUpmWkd5TVBNRkl4WVY2SWpOVWN6c2k3TllEUDg3OENt?=
 =?utf-8?B?MmdsY0hXOGo5RUxGT1p0SHM4N0RqS0dFL1lodGp0cGczMCtWcGplNTdRdTNW?=
 =?utf-8?B?eXVBVlZCN2NqTCtDQXBUOHVxSmZwMDN2ZnB3bmNndFN3YW1Kbi9EcDc0a0Yx?=
 =?utf-8?B?QzE3enBiY2d4MEpIQXRSa044YUFmdnVBQnoxN0V1c1ZFeDQ2QWVGZUh3N09L?=
 =?utf-8?B?S1FiYjNZUjJGUFZ2K01ZcVg1bXNqZ3k0ellJWjdqSkl2WldJS25SUk5pN29y?=
 =?utf-8?B?LzlYTW1JdmRjd1k1MXRwSkZrcTlyMENMK1hTdzlGM0NsYzg1M2lRdVppcG1Z?=
 =?utf-8?B?MU0rSTFkOGFmcWhvVTJIVXkwYVBFbE5BNUNubDJtcHVqeEc1YkZUQlBCUUwv?=
 =?utf-8?B?dkZick1wUEdjYzNHNnQrYmpqb2REQlRNZnFmaHp0ZUZPUGxXY1RocWNjblVh?=
 =?utf-8?B?WDNaL1BmaXRwYjluWnhPVGJwUytmRkRYQ0VwazVmWUlYbVVtVU5ySHYydU1a?=
 =?utf-8?B?RlY4azZVQWZPS2dMSitVNDA2bmc5K01mUDZ6b2gvRjJVSHlnR3UxWFNnZkc3?=
 =?utf-8?B?TjRUcG9NM2UvV05vcXdUR2p2cGRtSDdWNVprU3NzaWxpMjBmYVQySkpqZ1Fq?=
 =?utf-8?B?TTJ0VmRCOEdQWUFtTHRBQ2JjRytYOG5qalVoaXhKRm1sSERUdVdhYisxcE0v?=
 =?utf-8?B?L0tIbFZJZUttcEdleUZGVUVwZ0I0NklwTDVOQUY5UDRzNm1kQ0xxc056ektI?=
 =?utf-8?B?UjJVZXZpYjJCTzFmaTdMTVExUkJ1MmZ0L0lxcG56dHFlbnI4a21RY0FvVWF1?=
 =?utf-8?B?K0FNMHpHcmVqV3Y3YVI4WGZWWUpCUXdXenJCblFtdG1ZNnM5R0V2UEJzajBl?=
 =?utf-8?B?Tm5nZE1EaXlWbHNveG9hcXRDN3Fla1BVYmNDckJVVXBqUWRUelB1NWNzVjlF?=
 =?utf-8?B?TEFmbVVnS2xVcUpXd1h6NndBRjRQNEJhVlQvMVYxUDFQeDJkVG8vMlI0OFF6?=
 =?utf-8?B?T3pueW5UVHJWZ2FZQVlSN1QzT3JkbE9wcCszUEsxYUdXeHNZZWZ3bUtUTExW?=
 =?utf-8?Q?nDe2IIXibXgH4ZAL2PzhitzP3?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6d93572e-1863-407d-0f89-08ddb3b8eb7d
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jun 2025 07:21:36.5092
 (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: RvAwCWoyqLzlbIcP0dKTh5/pb+PDzFqOx/hBFCbqt5DdobLVorrsXreIQUdNNsqx
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR12MB9155



On 24/06/2025 05:55, dmkhn@proton.me wrote:
> From: Denis Mukhin  
> 
> Switch to using void pointer in domain struct to reduce compile-time
> dependencies for PL011 emulator.
I don't understand the rationale very well. Could you provide more details?
Why can't we keep struct vpl011 in domain struct given? I would understand the
need for void if we used a single member that could map to different vUARTs
depending on selection. That's clearly not the case. If it is just to avoid the
header, then I don't think we need such churn.

> 
> Signed-off-by: Denis Mukhin 
> ---
>  xen/arch/arm/include/asm/domain.h |   3 +-
>  xen/arch/arm/vpl011.c             | 139 +++++++++++++++++-------------
>  2 files changed, 79 insertions(+), 63 deletions(-)
> 
> diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/domain.h
> index 746ea687d523..2ee9976b55a8 100644
> --- a/xen/arch/arm/include/asm/domain.h
> +++ b/xen/arch/arm/include/asm/domain.h
> @@ -9,7 +9,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  
>  struct hvm_domain
> @@ -114,7 +113,7 @@ struct arch_domain
>      } monitor;
>  
>  #ifdef CONFIG_HAS_VUART_PL011
> -    struct vpl011 vpl011;
> +    void *vpl011;
>  #endif
>  
>  #ifdef CONFIG_TEE
> diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> index a97c3b74208c..3c027ccf0b4e 100644
> --- a/xen/arch/arm/vpl011.c
> +++ b/xen/arch/arm/vpl011.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -31,6 +32,43 @@
>  #include 
>  #include 
>  
> +static void __vpl011_exit(struct vpl011 *vpl011, struct domain *d
Names starting with '__' are reserved and forbidden by MISRA C rule that AFAIR
we accepted (don't remember what rule exactly).

> +{
> +    if ( vpl011->virq )
> +    {
> +        vgic_free_virq(d, vpl011->virq);
> +
> +        /*
> +         * Set to invalid irq (we use SPI) to prevent extra free and to avoid
> +         * freeing irq that could have already been reserved by someone else.
> +         */
> +        vpl011->virq = 0;
> +    }
> +
> +    if ( vpl011->backend_in_domain )
> +    {
> +        if ( vpl011->backend.dom.ring_buf )
> +            destroy_ring_for_helper(&vpl011->backend.dom.ring_buf,
> +                                    vpl011->backend.dom.ring_page);
> +
> +        if ( vpl011->evtchn )
> +        {
> +            free_xen_event_channel(d, vpl011->evtchn);
> +
> +            /*
> +             * Set to invalid event channel port to prevent extra free and to
> +             * avoid freeing port that could have already been allocated for
> +             * other purposes.
> +             */
> +            vpl011->evtchn = 0;
> +        }
> +    }
> +    else
> +        XFREE(vpl011->backend.xen);
> +
> +    xfree(vpl011);
> +}
> +
>  /*
>   * Since pl011 registers are 32-bit registers, all registers
>   * are handled similarly allowing 8-bit, 16-bit and 32-bit
> @@ -43,7 +81,7 @@ static bool vpl011_reg32_check_access(struct hsr_dabt dabt)
>  
>  static void vpl011_update_interrupt_status(struct domain *d)
>  {
> -    struct vpl011 *vpl011 = &d->arch.vpl011;
> +    struct vpl011 *vpl011 = d->arch.vpl011;
>      uint32_t uartmis = vpl011->uartris & vpl011->uartimsc;
>  
>      /*
> @@ -81,7 +119,7 @@ static void vpl011_update_interrupt_status(struct domain *d)
>  static void vpl011_write_data_xen(struct domain *d, uint8_t data)
>  {
>      unsigned long flags;
> -    struct vpl011 *vpl011 = &d->arch.vpl011;
> +    struct vpl011 *vpl011 = d->arch.vpl011;
>      struct vpl011_xen_backend *intf = vpl011->backend.xen;
>      struct domain *input = console_get_domain();
>  
> @@ -140,7 +178,7 @@ static uint8_t vpl011_read_data_xen(struct domain *d)
>  {
>      unsigned long flags;
>      uint8_t data = 0;
> -    struct vpl011 *vpl011 = &d->arch.vpl011;
> +    struct vpl011 *vpl011 = d->arch.vpl011;
>      struct vpl011_xen_backend *intf = vpl011->backend.xen;
>      XENCONS_RING_IDX in_cons, in_prod;
>  
> @@ -199,7 +237,7 @@ static uint8_t vpl011_read_data(struct domain *d)
>  {
>      unsigned long flags;
>      uint8_t data = 0;
> -    struct vpl011 *vpl011 = &d->arch.vpl011;
> +    struct vpl011 *vpl011 = d->arch.vpl011;
>      struct xencons_interface *intf = vpl011->backend.dom.ring_buf;
>      XENCONS_RING_IDX in_cons, in_prod;
>  
> @@ -284,7 +322,7 @@ static void vpl011_update_tx_fifo_status(struct vpl011 *vpl011,
>  static void vpl011_write_data(struct domain *d, uint8_t data)
>  {
>      unsigned long flags;
> -    struct vpl011 *vpl011 = &d->arch.vpl011;
> +    struct vpl011 *vpl011 = d->arch.vpl011;
>      struct xencons_interface *intf = vpl011->backend.dom.ring_buf;
>      XENCONS_RING_IDX out_cons, out_prod;
>  
> @@ -350,10 +388,9 @@ static int vpl011_mmio_read(struct vcpu *v,
>                              register_t *r,
>                              void *priv)
>  {
> +    struct vpl011 *vpl011 = v->domain->arch.vpl011;
>      struct hsr_dabt dabt = info->dabt;
> -    uint32_t vpl011_reg = (uint32_t)(info->gpa -
> -                                     v->domain->arch.vpl011.base_addr);
> -    struct vpl011 *vpl011 = &v->domain->arch.vpl011;
> +    uint32_t vpl011_reg = (uint32_t)(info->gpa - vpl011->base_addr);
>      struct domain *d = v->domain;
>      unsigned long flags;
>  
> @@ -439,10 +476,9 @@ static int vpl011_mmio_write(struct vcpu *v,
>                               register_t r,
>                               void *priv)
>  {
> +    struct vpl011 *vpl011 = v->domain->arch.vpl011;
>      struct hsr_dabt dabt = info->dabt;
> -    uint32_t vpl011_reg = (uint32_t)(info->gpa -
> -                                     v->domain->arch.vpl011.base_addr);
> -    struct vpl011 *vpl011 = &v->domain->arch.vpl011;
> +    uint32_t vpl011_reg = (uint32_t)(info->gpa - vpl011->base_addr);
>      struct domain *d = v->domain;
>      unsigned long flags;
>  
> @@ -518,7 +554,7 @@ static void vpl011_data_avail(struct domain *d,
>                                XENCONS_RING_IDX out_fifo_level,
>                                XENCONS_RING_IDX out_size)
>  {
> -    struct vpl011 *vpl011 = &d->arch.vpl011;
> +    struct vpl011 *vpl011 = d->arch.vpl011;
>  
>      /**** Update the UART RX state ****/
>  
> @@ -576,7 +612,7 @@ static void vpl011_data_avail(struct domain *d,
>  int vuart_putchar(struct domain *d, char c)
>  {
>      unsigned long flags;
> -    struct vpl011 *vpl011 = &d->arch.vpl011;
> +    struct vpl011 *vpl011 = d->arch.vpl011;
>      struct vpl011_xen_backend *intf = vpl011->backend.xen;
>      XENCONS_RING_IDX in_cons, in_prod, in_fifo_level;
>  
> @@ -614,7 +650,7 @@ static void vpl011_notification(struct vcpu *v, unsigned int port)
>  {
>      unsigned long flags;
>      struct domain *d = v->domain;
> -    struct vpl011 *vpl011 = &d->arch.vpl011;
> +    struct vpl011 *vpl011 = d->arch.vpl011;
>      struct xencons_interface *intf = vpl011->backend.dom.ring_buf;
>      XENCONS_RING_IDX in_cons, in_prod, out_cons, out_prod;
>      XENCONS_RING_IDX in_fifo_level, out_fifo_level;
> @@ -644,11 +680,14 @@ static void vpl011_notification(struct vcpu *v, unsigned int port)
>  
>  int vuart_init(struct domain *d, struct vuart_params *params)
>  {
> +    struct vpl011 *vpl011;
>      int rc;
> -    struct vpl011 *vpl011 = &d->arch.vpl011;
>  
> -    if ( vpl011->backend.dom.ring_buf )
> -        return -EINVAL;
> +    BUG_ON(d->arch.vpl011);
> +
> +    vpl011 = xvzalloc(typeof(*vpl011));
> +    if ( !vpl011 )
> +        return -ENOMEM;
>  
>      /*
>       * The VPL011 virq is GUEST_VPL011_SPI, except for direct-map domains
> @@ -670,7 +709,8 @@ int vuart_init(struct domain *d, struct vuart_params *params)
>          {
>              printk(XENLOG_ERR
>                     "vpl011: Unable to re-use the Xen UART information.\n");
> -            return -EINVAL;
> +            rc = -EINVAL;
> +            goto err_out;
>          }
>  
>          /*
> @@ -684,7 +724,8 @@ int vuart_init(struct domain *d, struct vuart_params *params)
>          {
>              printk(XENLOG_ERR
>                     "vpl011: Can't re-use the Xen UART MMIO region as it is too small.\n");
> -            return -EINVAL;
> +            rc = -EINVAL;
> +            goto err_out;
>          }
>      }
>      else
> @@ -707,12 +748,12 @@ int vuart_init(struct domain *d, struct vuart_params *params)
>                                        &vpl011->backend.dom.ring_page,
>                                        &vpl011->backend.dom.ring_buf);
>          if ( rc < 0 )
> -            goto out;
> +            goto err_out;
>  
>          rc = alloc_unbound_xen_event_channel(d, 0, params->console_domid,
>                                               vpl011_notification);
>          if ( rc < 0 )
> -            goto out1;
> +            goto err_out;
>  
>          vpl011->evtchn = params->evtchn = rc;
>      }
> @@ -725,7 +766,7 @@ int vuart_init(struct domain *d, struct vuart_params *params)
>          if ( vpl011->backend.xen == NULL )
>          {
>              rc = -ENOMEM;
> -            goto out;
> +            goto err_out;
>          }
>      }
>  
> @@ -733,7 +774,7 @@ int vuart_init(struct domain *d, struct vuart_params *params)
>      if ( !rc )
>      {
>          rc = -EINVAL;
> -        goto out1;
> +        goto err_out;
>      }
>  
>      vpl011->uartfr = TXFE | RXFE;
> @@ -743,50 +784,22 @@ int vuart_init(struct domain *d, struct vuart_params *params)
>      register_mmio_handler(d, &vpl011_mmio_handler,
>                            vpl011->base_addr, GUEST_PL011_SIZE, NULL);
>  
> +    d->arch.vpl011 = vpl011;
> +
>      return 0;
>  
> -out1:
> -    vuart_exit(d);
> -
> -out:
> +err_out:
Labels should be indented by one space.

~Michal



From xen-devel-bounces@lists.xenproject.org Wed Jun 25 07:34:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 07:34:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024417.1400298 (Exim 4.92)
	(envelope-from )
	id 1uUKeG-0007HI-NF; Wed, 25 Jun 2025 07:34:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024417.1400298; Wed, 25 Jun 2025 07: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 1uUKeG-0007HB-KT; Wed, 25 Jun 2025 07:34:24 +0000
Received: by outflank-mailman (input) for mailman id 1024417;
 Wed, 25 Jun 2025 07:34:23 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uUKeF-00071z-4I
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 07:34:23 +0000
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com
 [2a00:1450:4864:20::433])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cff02075-5196-11f0-a30f-13f23c93f187;
 Wed, 25 Jun 2025 09:34:22 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a4fea34e07so648369f8f.1
 for ; Wed, 25 Jun 2025 00:34:22 -0700 (PDT)
Received: from localhost.localdomain (253.226.6.51.dyn.plus.net.
 [51.6.226.253]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4538233c05csm11319445e9.5.2025.06.25.00.34.20
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 25 Jun 2025 00:34:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cff02075-5196-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750836862; x=1751441662; darn=lists.xenproject.org;
        h=content-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=Vsyq/VDtJXv+144v9RhWaKYSLA/NOYLJKdqG4Hj8gbU=;
        b=GzoQLVhIhO0TZ0utu+HsxFuX8zslSeOBPA3K45AS8iwvDbjq6DawN9PDlXChaw/LFz
         SBz4wlpb7X1P+T0xfuOmpPKCgOCgA1Xd/yKyMnmRWAGkl0/ic9t6IyE4uz4wZLm6YjJZ
         WrfP4v88wJKJvGFtvFmP4zTxIcvXGs2a5vPHw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750836862; x=1751441662;
        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=Vsyq/VDtJXv+144v9RhWaKYSLA/NOYLJKdqG4Hj8gbU=;
        b=K11YFcgCmwnP0xjP+JHNOiqL2l61i0ZNPDWIFndylB5pFU0TKP9pBKvJdoT/Hhif9G
         iZPnU9i0v3GA7QKRJKm9ODlGcaCwGNNyphVVduy1bM6APmErXgtx1RPm+ZhnZxlbFu+W
         kBxNd/2DSqJXcnZ48MpTFQy/h7JuA0MJ3oYE9SK99G6Q5dt9K2m4qrhWxWrJmFIBwfnD
         zevOv8VGSAlUzI9X/m+8tN1oU1Np2/zCxeIc8bnxEzDIyrqGUW8koGBaCTuQ31f3eZww
         ne0yf3lM4cDCGYk8NQ1NkAjodv1t4somWKCSxDPMC9I36W3FRgsFF08bW0xoD1KU/Y+9
         8VSg==
X-Gm-Message-State: AOJu0YxnQUxvSBwA0CGGOrv/duiwd8nDJHUfrrjjNCKc5KOSVR1timj/
	/yANC/pYy72BPY/yHDXrnjP4s5x77PEzNPtrDfcbcImqir7Jz4EfrAu+diHprXAO6jHpNA/bokh
	ygQKdgG4A7w==
X-Gm-Gg: ASbGnctV94loPCyZk330r632IWcz5Ndr80OGTKxLJfjoh0MlaJlz6uUNf3OPcAta/5U
	43yZGxl2WVgNecrXZB/mHGmnDjU/DiDbora9A09Zzw3ZC+UgJA9YovYQRanZNy1pfQ4OkeEQEQX
	nfRviSf1KdSmLRbvKQEBXDwPbwJQCOTffOwlW/ghgD+AfmL9aCNgnQbP3LvjH/yGTP6gRvF41Vf
	7JaX9coib+iad9R1kzqppOAdEt49GJzQt3AFJnUK2PZsi8vJUeRwPJ069Gen+9gKtBbXhm/98li
	Pzi/ZW/VA2ez5ZwHNSv+DT4cKnQCLrWvPt3AtpAJjPOGphVNw1+jHfdwdsGI41K5OzgUd2aQOW7
	X0B+Ml1a44i9pxQHMubAJhmmAH51FqA==
X-Google-Smtp-Source: AGHT+IFVmrgt1T38A7ERw6soRLcvDczrOUkuFgE2tl8CzJitksBUAXlHjE6GPe7vMJCVFLlc1m8Y8w==
X-Received: by 2002:a5d:64c2:0:b0:3a3:7753:20ff with SMTP id ffacd0b85a97d-3a6ed655bc3mr1599155f8f.35.1750836861536;
        Wed, 25 Jun 2025 00:34:21 -0700 (PDT)
From: Frediano Ziglio 
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio ,
	"Daniel P. Smith" ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Jan Beulich 
Subject: [PATCH v3 1/3] xen/efi: Handle cases where file didn't come from ESP
Date: Wed, 25 Jun 2025 08:34:03 +0100
Message-ID: <20250625073408.7496-2-frediano.ziglio@cloud.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250625073408.7496-1-frediano.ziglio@cloud.com>
References: <20250625073408.7496-1-frediano.ziglio@cloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

A boot loader can load files from outside ESP.
In these cases device could be not provided or path could
be something not supported.
In these cases allows to boot anyway, all information
could be provided using UKI or using other boot loader
features.

Signed-off-by: Frediano Ziglio 
Acked-by: Marek Marczykowski-Górecki 
---
Changes since v1:
- set "leaf" to NULL instead of a buffer with an empty string;
- keep read_file fatal if cannot load file (except configuration).

Changes since v2:
- Added acked-by.
---
 xen/common/efi/boot.c | 34 +++++++++++++++++++++++++++++-----
 1 file changed, 29 insertions(+), 5 deletions(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 1a9b4e7dae..b18af2f1f4 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -443,6 +443,18 @@ static EFI_FILE_HANDLE __init get_parent_handle(const EFI_LOADED_IMAGE *loaded_i
     CHAR16 *pathend, *ptr;
     EFI_STATUS ret;
 
+    /*
+     * In some cases the image could not come from a specific device.
+     * For instance this can happen if Xen was loaded using GRUB2 "linux"
+     * command.
+     */
+    *leaf = NULL;
+    if ( !loaded_image->DeviceHandle )
+    {
+        PrintStr(L"Xen image loaded without providing a device\r\n");
+        return NULL;
+    }
+
     do {
         EFI_FILE_IO_INTERFACE *fio;
 
@@ -466,7 +478,15 @@ static EFI_FILE_HANDLE __init get_parent_handle(const EFI_LOADED_IMAGE *loaded_i
 
         if ( DevicePathType(dp) != MEDIA_DEVICE_PATH ||
              DevicePathSubType(dp) != MEDIA_FILEPATH_DP )
-            blexit(L"Unsupported device path component");
+        {
+            /*
+             * The image could come from an unsupported device.
+             * For instance this can happen if Xen was loaded using GRUB2
+             * "chainloader" command and the file was not from ESP.
+             */
+            PrintStr(L"Unsupported device path component\r\n");
+            return NULL;
+        }
 
         if ( *buffer )
         {
@@ -772,8 +792,11 @@ static bool __init read_file(EFI_FILE_HANDLE dir_handle, CHAR16 *name,
 
     if ( !name )
         PrintErrMesg(L"No filename", EFI_OUT_OF_RESOURCES);
-    ret = dir_handle->Open(dir_handle, &FileHandle, name,
-                           EFI_FILE_MODE_READ, 0);
+    if ( dir_handle )
+        ret = dir_handle->Open(dir_handle, &FileHandle, name,
+                               EFI_FILE_MODE_READ, 0);
+    else
+        ret = EFI_NOT_FOUND;
     if ( file == &cfg && ret == EFI_NOT_FOUND )
         return false;
     if ( EFI_ERROR(ret) )
@@ -1404,7 +1427,7 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle,
         /* Read and parse the config file. */
         if ( read_section(loaded_image, L"config", &cfg, NULL) )
             PrintStr(L"Using builtin config file\r\n");
-        else if ( !cfg_file_name )
+        else if ( !cfg_file_name && file_name)
         {
             CHAR16 *tail;
 
@@ -1515,7 +1538,8 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle,
         efi_bs->FreePages(cfg.addr, PFN_UP(cfg.size));
         cfg.addr = 0;
 
-        dir_handle->Close(dir_handle);
+        if ( dir_handle )
+            dir_handle->Close(dir_handle);
 
         if ( gop && !base_video )
         {
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Jun 25 07:34:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 07:34:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024418.1400307 (Exim 4.92)
	(envelope-from )
	id 1uUKeI-0007WB-Tw; Wed, 25 Jun 2025 07:34:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024418.1400307; Wed, 25 Jun 2025 07:34: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 1uUKeI-0007W4-Qz; Wed, 25 Jun 2025 07:34:26 +0000
Received: by outflank-mailman (input) for mailman id 1024418;
 Wed, 25 Jun 2025 07:34: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 1uUKeH-00071t-KN
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 07:34:25 +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 d0d81e65-5196-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 09:34:24 +0200 (CEST)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-45363645a8eso9982275e9.1
 for ; Wed, 25 Jun 2025 00:34:24 -0700 (PDT)
Received: from localhost.localdomain (253.226.6.51.dyn.plus.net.
 [51.6.226.253]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4538233c05csm11319445e9.5.2025.06.25.00.34.22
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 25 Jun 2025 00:34:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d0d81e65-5196-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750836863; x=1751441663; darn=lists.xenproject.org;
        h=content-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=2u/dNL0zGTpCOJg2Jk0Pnt2b5neRnRqaGdBf3ycdnjw=;
        b=G6SMwt9vfW/+omiNV8CIM78WHHaBEWSQAArbfT7RO+EzQTqyqHga5pZzYJMHXpnfZo
         P8H2omnfLzdN43/JHCAQ586ujNUK4gsF1v/nINJYszJKVIyI+0SuaQpH3UpQ/fSQ6Izy
         n3Xp0SY75c2nlvBn5Zjz28mDYYdtw0fxugFEk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750836863; x=1751441663;
        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=2u/dNL0zGTpCOJg2Jk0Pnt2b5neRnRqaGdBf3ycdnjw=;
        b=lPzq9or4glMsAbWpGE26qPcTtU0xxON9PihKQz5VnTCXjwPelqKpM0Gjuig8Qn6ylC
         rmMzHQj+3Ab0pVR7aHSYGCe2Gi22mBD7n7BarvQA1bQR/bVphzVF+vtYkrXSsfNH1WVn
         jC8b5u5lWXWX2S5gjBqKPkwYCy4Z63981VT33KppLOxULL5jsZBWFCE+ZuyYvdgm/KyP
         GkGeuAjHgJcnHtKZO6e9Zep25p9Od4uMNiFBF0BTZFfI+v78CiJcvvUYf31UWO6r+Bf9
         4XGMe1hk/VNiAwgssCSi744DCq0B/BdkoZsrz/71RX9wTddTLuL14H22i+N7J3fSvtkn
         eNig==
X-Gm-Message-State: AOJu0Yz5isTnRBgEIlbDYalrNfb2YMI2taJamKZnTfFKoiYKEHp1ulge
	YicO+m3h+WhludThvrjKh2/2hxBYqn4y87Z8wfr4CvVfnRmQhzdVyRM97wtDzA+tdMOJZ/i/rum
	bJCXj2HbUIA==
X-Gm-Gg: ASbGncsMBjy+IB3KYHyvZSuy89NHbM3zSlkJnIgRZzCFOyexuecNVxzsLuHtNxff9sw
	Y0Zr9z4PItPPTM1C/wQgRL8915fwegPNklugWht0fU0jr+yphX5JuI71S0AzItguOMbmzq66uey
	u5uYcQAF+YIQ5+szw10utOx0K87VuIhEDqn/SeE8v1SxnAALvJ+nNCvLis0BY5lEupvoSr8syuA
	HdyPSH2L/8MV1ckLDlOCpyAEOjtyUOxdFySep5H7exDH4VBZpbR1ASpj4RLf7moSpb1iYypOREu
	tpTIOt9Eq8iTTaMe+YwB0L4aSa9e7CbIMCBK734WapMRSNAXag+GBrHFwMQAbua0iQagri4Po0v
	5lEgH0UjDziS/G4dB9eGlfIrk/CIhVg==
X-Google-Smtp-Source: AGHT+IECGcdpnjc8qdQWw0CpidFRo4B7mb6gEOKf268r3/OuAS0AJUvt6RM81TyWc1Q6MtmwJ+1Thw==
X-Received: by 2002:a05:600c:8b58:b0:440:9b1a:cd78 with SMTP id 5b1f17b1804b1-45381ac23aemr17908645e9.10.1750836863225;
        Wed, 25 Jun 2025 00:34:23 -0700 (PDT)
From: Frediano Ziglio 
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio ,
	"Daniel P. Smith" ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Jan Beulich 
Subject: [PATCH v3 3/3] xen/efi: Update error flow for read_file function
Date: Wed, 25 Jun 2025 08:34:05 +0100
Message-ID: <20250625073408.7496-4-frediano.ziglio@cloud.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250625073408.7496-1-frediano.ziglio@cloud.com>
References: <20250625073408.7496-1-frediano.ziglio@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Use more explicit goto statements to handle common error code
path instead of a lot of if/else.

Signed-off-by: Frediano Ziglio 
---
 xen/common/efi/boot.c | 80 +++++++++++++++++++++++--------------------
 1 file changed, 43 insertions(+), 37 deletions(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index b6ce3a0257..fa61da4931 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -792,6 +792,8 @@ static bool __init read_file(EFI_FILE_HANDLE dir_handle, CHAR16 *name,
 
     if ( !name )
         PrintErrMesg(L"No filename", EFI_OUT_OF_RESOURCES);
+
+    what = L"Open";
     if ( dir_handle )
         ret = dir_handle->Open(dir_handle, &FileHandle, name,
                                EFI_FILE_MODE_READ, 0);
@@ -800,54 +802,58 @@ static bool __init read_file(EFI_FILE_HANDLE dir_handle, CHAR16 *name,
     if ( file == &cfg && ret == EFI_NOT_FOUND )
         return false;
     if ( EFI_ERROR(ret) )
-        what = L"Open";
-    else
-        ret = FileHandle->SetPosition(FileHandle, -1);
+        goto fail;
+
+    what = L"Seek";
+    ret = FileHandle->SetPosition(FileHandle, -1);
     if ( EFI_ERROR(ret) )
-        what = what ?: L"Seek";
-    else
-        ret = FileHandle->GetPosition(FileHandle, &size);
+        goto fail;
+
+    what = L"Get size";
+    ret = FileHandle->GetPosition(FileHandle, &size);
     if ( EFI_ERROR(ret) )
-        what = what ?: L"Get size";
-    else
-        ret = FileHandle->SetPosition(FileHandle, 0);
+        goto fail;
+
+    what = L"Seek";
+    ret = FileHandle->SetPosition(FileHandle, 0);
     if ( EFI_ERROR(ret) )
-        what = what ?: L"Seek";
-    else
-    {
-        file->addr = min(1UL << (32 + PAGE_SHIFT),
-                         HYPERVISOR_VIRT_END - DIRECTMAP_VIRT_START);
-        ret = efi_bs->AllocatePages(AllocateMaxAddress, EfiLoaderData,
-                                    PFN_UP(size), &file->addr);
-    }
+        goto fail;
+
+    what = L"Allocation";
+    file->addr = min(1UL << (32 + PAGE_SHIFT),
+                     HYPERVISOR_VIRT_END - DIRECTMAP_VIRT_START);
+    ret = efi_bs->AllocatePages(AllocateMaxAddress, EfiLoaderData,
+                                PFN_UP(size), &file->addr);
     if ( EFI_ERROR(ret) )
-        what = what ?: L"Allocation";
-    else
-    {
-        file->need_to_free = true;
-        file->size = size;
-        handle_file_info(name, file, options);
+        goto fail;
 
-        ret = FileHandle->Read(FileHandle, &file->size, file->str);
-        if ( !EFI_ERROR(ret) && file->size != size )
-            ret = EFI_ABORTED;
-        if ( EFI_ERROR(ret) )
-            what = L"Read";
-    }
+    file->need_to_free = true;
+    file->size = size;
+    handle_file_info(name, file, options);
 
-    if ( FileHandle )
-        FileHandle->Close(FileHandle);
+    what = L"Read";
+    ret = FileHandle->Read(FileHandle, &file->size, file->str);
+    if ( !EFI_ERROR(ret) && file->size != size )
+        ret = EFI_ABORTED;
+    if ( EFI_ERROR(ret) )
+        goto fail;
 
-    if ( what )
-    {
-        PrintErr(what);
-        PrintErr(L" failed for ");
-        PrintErrMesg(name, ret);
-    }
+    FileHandle->Close(FileHandle);
 
     efi_arch_flush_dcache_area(file->ptr, file->size);
 
     return true;
+
+fail:
+    if ( FileHandle )
+        FileHandle->Close(FileHandle);
+
+    PrintErr(what);
+    PrintErr(L" failed for ");
+    PrintErrMesg(name, ret);
+
+    /* not reached */
+    return false;
 }
 
 #pragma pack(1)
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Jun 25 07:34:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 07:34:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024416.1400287 (Exim 4.92)
	(envelope-from )
	id 1uUKeF-000732-HH; Wed, 25 Jun 2025 07:34:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024416.1400287; Wed, 25 Jun 2025 07:34:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUKeF-00072v-Dq; Wed, 25 Jun 2025 07:34:23 +0000
Received: by outflank-mailman (input) for mailman id 1024416;
 Wed, 25 Jun 2025 07:34: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 1uUKeE-00071z-Eo
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 07:34:22 +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 cf6bbe7a-5196-11f0-a30f-13f23c93f187;
 Wed, 25 Jun 2025 09:34:21 +0200 (CEST)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-45363645a8eso9981925e9.1
 for ; Wed, 25 Jun 2025 00:34:21 -0700 (PDT)
Received: from localhost.localdomain (253.226.6.51.dyn.plus.net.
 [51.6.226.253]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4538233c05csm11319445e9.5.2025.06.25.00.34.20
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 25 Jun 2025 00:34:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cf6bbe7a-5196-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750836861; x=1751441661; 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=ku/bkWnKDeRxrJXT+SYJnnAc76B76woDVUrHOmPvtLo=;
        b=NquKiVMAvKgbABJhpXndvZDz2URHX/vkzT/e5W4b8drtQaEWAtOmgkJPMzRTxL4tGG
         Xav8sQ39IaGaUn7IobMJz3SW2D2MumtFCyR/oV5WDNvNL9XB0khiAqK/pr9CJRkl0QfL
         s1Iq9RqtiDoVGwLnOQqwJLsvN9C6IfKjBV51s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750836861; x=1751441661;
        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=ku/bkWnKDeRxrJXT+SYJnnAc76B76woDVUrHOmPvtLo=;
        b=XcHqpv7Ak1hb77mX8fnUquCuE6qTO/d6P1GAV8v6CwBkWkIBvFr+QDyk0fl5Y7BdVJ
         HAdNMFlBv3lY3UrL9UXDmgtTfmQSahaVbJMfCNp1EzRpgAySc/Sc/E9nVKYyND7v3gM2
         KIisYxn/eRiK59x9cjsZC9NO5koXcI9Va2Lsc5qEKnL/FMCfM55XP0iw5PaUb5JMLMHV
         rvM4F/WQTq7uXXHd3fY3FHgo9UHVf6Tn0FkARhIo+XJJHjASzQlYa/LMqgVzIvU9I7wh
         vCFUzXQhVWKc3p+CD3rDS1kyRGIwzDhW+vFCDXkz833Xl0ifKlvv9xwArjJvsRsAUABh
         0SHA==
X-Gm-Message-State: AOJu0YwVyH9bg3El3+vmvRawCzfJWL0Vj/JrW5RGE+qeUP3bWgAxWKrz
	/fChjtz1SlgIgdRBJkVZa6/GDedF3bYeIZcsHyWv/Oy/bobSetEuHmHRA7xh7SCp1r0Byv8hyVY
	OSRpTMIbvHA==
X-Gm-Gg: ASbGnctqfuRtLDraWiaSN2MGNFJrV55sy8ZSdcpgCtQl1ArTNnZaUUCOweJWa2+cQWy
	yUEs2lxOkVzt7o6kVmKUBfGnix6QAfIbmWY0hnSwN17n0ZW+gyk2Ubu89dFzG3Y5rQfModg+DWA
	b/jkkA7Gb/Uf8dVF6KdyIC8XtgVJ8CHbqStZMHWkoibdVACiZD4eRdEKsdQIC2/upbQerM3uyP0
	dvB65gHdjYEaO5yGFlisDrjHnC9V1IzpNZcbsF7rdfcNm2rTRudsp+Ia1yhx4uS/fI4gex82Nfo
	qXFxv9mZgysQLuOV3x9NiYeX8nwgJRy2sudhLahbifuh5AhF4gHzo+Xx0B/dV1Nbp/QfnaHHNhj
	UaURWTQlv2pT5ZPdbxj5GL+NEvuXzxgN4/sUi+SVf
X-Google-Smtp-Source: AGHT+IGUj4fbsRaMsN8tCyV60UhoJ13zAH1kbx+HylBijsbW2KTZhREm2HCvDC5EMys9zsZy0lujQA==
X-Received: by 2002:a05:600c:1e1e:b0:43c:f3e4:d6f6 with SMTP id 5b1f17b1804b1-45381b0632dmr18067825e9.31.1750836860777;
        Wed, 25 Jun 2025 00:34:20 -0700 (PDT)
From: Frediano Ziglio 
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio ,
	"Daniel P. Smith" ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Jan Beulich 
Subject: [PATCH v3 0/3] xen/efi: Make boot more flexible, especially with GRUB2
Date: Wed, 25 Jun 2025 08:34:02 +0100
Message-ID: <20250625073408.7496-1-frediano.ziglio@cloud.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The combination of GRUB2, EFI and UKI allows potentially more flexibility.
For instance is possible to load xen.efi from a no ESP partition leaving
a boot loader like GRUB2 taking care of the file loading.
This however requires some changes in Xen to be less restrictive.
Specifically for GRUB2 these changes allows the usage of "chainloader"
command with UKI and reading xen.efi from no ESP (so no DeviceHandle
set) and usage of "linux" and "initrd" commands to load separately
the kernel (embedding using UKI) and initrd (using LoadFile2 protocol).

Changes since v1:
- keep read_file fatal when it was so;
- attempt to use LoadFile2 after trying object section;
- minor changes (see details on specific changes).

Changes since v2:
- update read_file style;
- added acked-by.

Frediano Ziglio (3):
  xen/efi: Handle cases where file didn't come from ESP
  xen/efi: Support loading initrd using GRUB2 LoadFile2 protocol
  xen/efi: Update error flow for read_file function

 xen/common/efi/boot.c     | 179 +++++++++++++++++++++++++++++---------
 xen/include/efi/efidevp.h |  21 +++++
 2 files changed, 160 insertions(+), 40 deletions(-)

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Jun 25 07:34:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 07:34:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024419.1400318 (Exim 4.92)
	(envelope-from )
	id 1uUKeM-0007mn-55; Wed, 25 Jun 2025 07:34:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024419.1400318; Wed, 25 Jun 2025 07: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 1uUKeM-0007me-2M; Wed, 25 Jun 2025 07:34:30 +0000
Received: by outflank-mailman (input) for mailman id 1024419;
 Wed, 25 Jun 2025 07:34: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 1uUKeK-00071t-KT
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 07:34:28 +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 d0624c6c-5196-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 09:34:23 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-450dd065828so10443125e9.2
 for ; Wed, 25 Jun 2025 00:34:23 -0700 (PDT)
Received: from localhost.localdomain (253.226.6.51.dyn.plus.net.
 [51.6.226.253]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4538233c05csm11319445e9.5.2025.06.25.00.34.21
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 25 Jun 2025 00:34:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d0624c6c-5196-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750836862; x=1751441662; darn=lists.xenproject.org;
        h=content-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=LGXZEs8C2ojkzsUWVpaRntklr8ldtVYfN6U4O6Kve+s=;
        b=NujdmlbWXGT++dZ/DIwDuw/4o6wtiyhzGbnZuthRPySmisCFKAmiJOFhf3VlF31bG+
         /wCxQJvpyiRR9E+dBkQv/UQAvPxY6NTLe6h6RDVG39MosHDQrEdCd4yJDlUyN647HLwv
         If1agaNS0HnnDfATlJhmV2K7CtzUwEjoOIH60=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750836862; x=1751441662;
        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=LGXZEs8C2ojkzsUWVpaRntklr8ldtVYfN6U4O6Kve+s=;
        b=HEUs9ua9b3vykecorZ1cd9UgcVCczubLw5SKTPKQPiXjcL8pWHzV5EpNRl5mOYe9Qt
         GIfztuwZdLSkVDkGWTAeI7oI5/CMygSgIfQbYqvXV8/qu23KhqWxMYCz+HupF/uIYxwh
         Dv3t8/XJLV6C0VllTW35bcNt/P52v6oHRxKvEIpabN9/dwf367nVco+gfFZdYrS4TmvH
         XwVtjQOHt0vFlET4w/QZKVcyViGw6y0gBr65Iol3KatKcrNU96WaROfgvJCQpKaGsWRk
         WEf7KRSjBJ6qSWVy9R7JJlsG+QsjgICZwrwFE2ULjuQcFZg9jeCM0TftugyDLYPIxArP
         RghA==
X-Gm-Message-State: AOJu0YzT1mjByR2OOdSEYTifNHzFRq8a3FeqMgjPFC2aILfe3u/5M2pI
	D8S9WDtezSSpUcFZoSPJ4GPsA+sFSVkld1cVcbmnBEEi/qsA76fiSi6mse+oZQyxovNNvUudIwG
	L3YIcLvCsBg==
X-Gm-Gg: ASbGnctPdk4WRGahYUZtUG7uC5RBmjryOG2e6VrsW2i6EYetgATGfe6gfg/Ws8K+r25
	8iuFmsxqnYLqMg+bQeW1Yz3zhrhnau2LQi3yznlD7WceQzTMZmhLhh4UHajC1NG1mffyOz3ITPV
	2CT31SPtrWmFR+cSoSZ3+TJ+0m6B0zaTV0Yx7RFfzkszR89Bac7oM0diodVF4xZwtOPPkUmhBUo
	wGNBtcoVH79+Ph604QF7Yn9rRs6yWH6XSxbIouGXLRJbCsYugeGRvUaxCNSHNkfomOuuWIsrPFn
	An5ukSbSpQa4RcmXQCxBf6QAxMq7ptpHxw0ePJiaPoVJGOkz7KiM8kqwJsXVXxqoVjkK2hzT/TW
	C8cg0j9CZL2jlD+vIwq+yeptYEe39PA==
X-Google-Smtp-Source: AGHT+IGgmbl/LRwOIK7iBZHPOQtU4N7XqXv2rwd65foSNPt8UucyHihR3kQtschc7xRYK0lxcl8AOQ==
X-Received: by 2002:a05:600c:a48:b0:450:d4a6:799e with SMTP id 5b1f17b1804b1-45381af6b04mr13712695e9.20.1750836862370;
        Wed, 25 Jun 2025 00:34:22 -0700 (PDT)
From: Frediano Ziglio 
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio ,
	"Daniel P. Smith" ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Jan Beulich 
Subject: [PATCH v3 2/3] xen/efi: Support loading initrd using GRUB2 LoadFile2 protocol
Date: Wed, 25 Jun 2025 08:34:04 +0100
Message-ID: <20250625073408.7496-3-frediano.ziglio@cloud.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250625073408.7496-1-frediano.ziglio@cloud.com>
References: <20250625073408.7496-1-frediano.ziglio@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Allows to load Xen using "linux" and "initrd" GRUB2 commands.
This can be used with UKI to separate initrd in a different module
instead of bundling all together.
Bundling all together can be a problem with Secure Boot where
we need to sign the bundle making harder to change it.
As initrd content does not need to be signed for Secure Boot
bundling it force it to be signed too.

Signed-off-by: Frediano Ziglio 
---
Changes since v1:
- attempt to use LoadFile2 protocol after embedded section.
---
 xen/common/efi/boot.c     | 71 ++++++++++++++++++++++++++++++++++++++-
 xen/include/efi/efidevp.h | 21 ++++++++++++
 2 files changed, 91 insertions(+), 1 deletion(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index b18af2f1f4..b6ce3a0257 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -850,6 +850,74 @@ static bool __init read_file(EFI_FILE_HANDLE dir_handle, CHAR16 *name,
     return true;
 }
 
+#pragma pack(1)
+typedef struct {
+    VENDOR_DEVICE_PATH              VenMediaNode;
+    EFI_DEVICE_PATH                 EndNode;
+} SINGLE_NODE_VENDOR_MEDIA_DEVPATH;
+#pragma pack()
+
+static bool __init initrd_load_file2(const CHAR16 *name, struct file *file)
+{
+    static const SINGLE_NODE_VENDOR_MEDIA_DEVPATH __initconst initrd_dev_path = {
+        {
+            {
+                MEDIA_DEVICE_PATH, MEDIA_VENDOR_DP, { sizeof (VENDOR_DEVICE_PATH) }
+            },
+            LINUX_EFI_INITRD_MEDIA_GUID
+        },
+        {
+            END_DEVICE_PATH_TYPE, END_ENTIRE_DEVICE_PATH_SUBTYPE,
+            { sizeof (EFI_DEVICE_PATH) }
+        }
+    };
+    static EFI_GUID __initdata lf2_proto_guid = EFI_LOAD_FILE2_PROTOCOL_GUID;
+    EFI_DEVICE_PATH *dp;
+    EFI_LOAD_FILE2_PROTOCOL *lf2;
+    EFI_HANDLE handle;
+    EFI_STATUS ret;
+    UINTN size;
+
+    dp = (EFI_DEVICE_PATH *)&initrd_dev_path;
+    ret = efi_bs->LocateDevicePath(&lf2_proto_guid, &dp, &handle);
+    if ( EFI_ERROR(ret) )
+    {
+        if ( ret == EFI_NOT_FOUND)
+            return false;
+        PrintErrMesg(L"Error getting file with LoadFile2 interface", ret);
+    }
+
+    ret = efi_bs->HandleProtocol(handle, &lf2_proto_guid, (void **)&lf2);
+    if ( EFI_ERROR(ret) )
+        PrintErrMesg(L"LoadFile2 file does not provide correct protocol", ret);
+
+    size = 0;
+    ret = lf2->LoadFile(lf2, dp, false, &size, NULL);
+    if ( ret != EFI_BUFFER_TOO_SMALL )
+        PrintErrMesg(L"Loading failed", ret);
+
+    file->addr = min(1UL << (32 + PAGE_SHIFT),
+                     HYPERVISOR_VIRT_END - DIRECTMAP_VIRT_START);
+    ret = efi_bs->AllocatePages(AllocateMaxAddress, EfiLoaderData,
+                                PFN_UP(size), &file->addr);
+    if ( EFI_ERROR(ret) )
+        PrintErrMesg(L"Allocation failed", ret);
+
+    file->need_to_free = true;
+    file->size = size;
+
+    ret = lf2->LoadFile(lf2, dp, false, &size, file->str);
+    if ( EFI_ERROR(ret) )
+    {
+        efi_bs->FreePages(file->addr, PFN_UP(size));
+        PrintErrMesg(L"Loading failed", ret);
+    }
+
+    efi_arch_handle_module(file, name, NULL);
+
+    return true;
+}
+
 static bool __init read_section(const EFI_LOADED_IMAGE *image,
                                 const CHAR16 *name, struct file *file,
                                 const char *options)
@@ -1493,7 +1561,8 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle,
             kernel_verified = true;
         }
 
-        if ( !read_section(loaded_image, L"ramdisk", &ramdisk, NULL) )
+        if ( !read_section(loaded_image, L"ramdisk", &ramdisk, NULL) &&
+             !initrd_load_file2(L"ramdisk", &ramdisk) )
         {
             name.s = get_value(&cfg, section.s, "ramdisk");
             if ( name.s )
diff --git a/xen/include/efi/efidevp.h b/xen/include/efi/efidevp.h
index beb5785a45..b240c15d2a 100644
--- a/xen/include/efi/efidevp.h
+++ b/xen/include/efi/efidevp.h
@@ -398,5 +398,26 @@ typedef union {
 
 } EFI_DEV_PATH_PTR;
 
+#define EFI_LOAD_FILE2_PROTOCOL_GUID \
+    { 0x4006c0c1, 0xfcb3, 0x403e, {0x99, 0x6d, 0x4a, 0x6c, 0x87, 0x24, 0xe0, 0x6d } }
+
+typedef struct EFI_LOAD_FILE2_PROTOCOL EFI_LOAD_FILE2_PROTOCOL;
+
+typedef
+EFI_STATUS
+(EFIAPI *EFI_LOAD_FILE2)(
+    IN EFI_LOAD_FILE2_PROTOCOL      *This,
+    IN EFI_DEVICE_PATH              *FilePath,
+    IN BOOLEAN                      BootPolicy,
+    IN OUT UINTN                    *BufferSize,
+    IN VOID                         *Buffer OPTIONAL
+    );
+
+struct EFI_LOAD_FILE2_PROTOCOL {
+    EFI_LOAD_FILE2                  LoadFile;
+};
+
+#define LINUX_EFI_INITRD_MEDIA_GUID \
+    { 0x5568e427, 0x68fc, 0x4f3d, {0xac, 0x74, 0xca, 0x55, 0x52, 0x31, 0xcc, 0x68} }
 
 #endif
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Jun 25 08:37:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 08:37:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024474.1400328 (Exim 4.92)
	(envelope-from )
	id 1uULd0-0000Qe-M6; Wed, 25 Jun 2025 08:37:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024474.1400328; Wed, 25 Jun 2025 08:37: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 1uULd0-0000QX-JX; Wed, 25 Jun 2025 08:37:10 +0000
Received: by outflank-mailman (input) for mailman id 1024474;
 Wed, 25 Jun 2025 08:37: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 1uULcz-0000QR-Q2
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 08:37:09 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 948b4884-519f-11f0-a30f-13f23c93f187;
 Wed, 25 Jun 2025 10:37:08 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-45310223677so46897795e9.0
 for ; Wed, 25 Jun 2025 01:37:08 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-749b5e08cf0sm4017191b3a.10.2025.06.25.01.37.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 25 Jun 2025 01:37:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 948b4884-519f-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750840628; x=1751445428; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=xeX8n97CPUt5vrF9ItN+TfIeKQ/k9YGoD5U2k7iUU/M=;
        b=bZzk1YBNEvygv5iE7CCI8Qjg/uIzxSUBF+G3SN/Vm3dTNA73VKO23s0/1EGpctnsSU
         H+/YFPImjvYPPVp1xQ1VrtkZ78Bwq9XyO1kzxqpsclXiXIZc+KJaYgGNDo+yTYYY2lI4
         wBzlcYBQf8soTMGXdWPg1wERzXcE3SJ/Jtse6NTjyUG4klrqfJOhZADa1f2lXaGhGfs8
         gptHwY4g8Rr395121EdPl0WYdwoAmY+OV7dMExzpv9NngzV5lQXvm/CrEFdW8uxKE4q3
         UIVA1HxZ5+V7iUwGhgAPp7F4+j3VJOxr3+oqUOnwjIfdrjUOoMBK6TTbd+fkWgIioNSc
         8CVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750840628; x=1751445428;
        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=xeX8n97CPUt5vrF9ItN+TfIeKQ/k9YGoD5U2k7iUU/M=;
        b=FSC6CbGj0Nwzw36llQnzq8WVIwIOULWG7ECJh7wcP/vgnfrQZipZpaW3NhgRRVeMBN
         Z2p6dPWpevDlRE0Tj0n1WrTKDPE6AwlxjoBGf681ratU4UUa6WmU9jdj16rFiZrhXYcd
         0HIg1IpbQlyDt6wRcf9lQce/vd+69mlHb9E0d9L38neCCglAQtvR+dlyJORDRikyEuqR
         sHdJ9ro5VEsxci69itnVB0E6Cry//twF9gKWSZ18DfmS4xT5zlnaUdQcw6gDSXb3Uv5A
         2T8kb8WwCLRcCijifSChCI/yY7U+qqEHBgH2fOAnlPmikfkPEqin4m3JCxAbZ4umG3AQ
         3DCw==
X-Forwarded-Encrypted: i=1; AJvYcCVRFN27y5097GfWytkCVHaKixSlkP5TYIgszJ2vb+yd/5BHTNBN7HJPP4oKW7sMhDJKRG97JFbilwg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywf98wQECXMx8hxE2BMyCX3jSGudSsaUg2t8OTlNYmEuH9I5RO0
	MEpGL0lP4xJqY6AWowdFtHacMrh2GZbG+nLzZ0A0jBc8vduD2NCAewBh5jYAgOaFcA==
X-Gm-Gg: ASbGncuIcZHKmOX8vj7LcI4NSjXWFW7XZK+H6BCgtEfrPNk3O34vVaF3gMPEHhQMheL
	9E28YGM+nmnj2F58plYivMn75S4iyutJV1mDT8mmRwvL2QLsjv8ZTHjcVCuQHTHIt1LJlgpAc3K
	idLo35OP5O740753AHvx67fvaMDvCeAf9X0RYC2ZsVmPf3jS1A0XK+0Agqk+l7i0evHDKE/k0s4
	eKJKoHtSJblyYQvuIxC1rHbmvO+CiUwFtMcb3JoZKK3K5siAZ/fZbqDbdrBvuAkXT7vyCxa5baG
	w1z0PlFcSx8N4sKvccArqQgBZxlbuHPmT40KlqxzOLXwEd49PW52owD+7K6brSGc/fgqyqqBeG/
	VRrSUJ8CNrCDlHqZAsMGbV88KIjq4pRUiJuvqAcP92+r462w=
X-Google-Smtp-Source: AGHT+IEXl5H/wnrk0C1dqbuus5cIxWhUlhi5CnTUgR1KB/5TyHmY7KAcgEjaoA+/aD1be8ELl4tfXQ==
X-Received: by 2002:a05:6000:2410:b0:3a5:2ddf:c934 with SMTP id ffacd0b85a97d-3a6ed644198mr1281188f8f.30.1750840627584;
        Wed, 25 Jun 2025 01:37:07 -0700 (PDT)
Message-ID: <3638e73c-2a83-4164-9a84-839245245727@suse.com>
Date: Wed, 25 Jun 2025 10:36:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
To: "Chen, Jiqian" 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Andrew Cooper ,
 Anthony PERARD ,
 "Orzel, Michal" , Julien Grall ,
 Stefano Stabellini ,
 "xen-devel@lists.xenproject.org" ,
 "Huang, Ray" 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-3-Jiqian.Chen@amd.com>
 <516a3adc-320d-46ce-b235-8ef91469abcf@suse.com>
 
 <227df6d3-a2c3-4576-bde9-d8057c378e7a@suse.com>
 
 <5c4b186e-686e-4fc8-bcf1-854bc1f5ec8b@suse.com>
 
 <9d5d0e44-66c3-4e3f-8704-2c862c5f5aff@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 25.06.2025 08:51, Chen, Jiqian wrote:
> On 2025/6/24 18:08, Jan Beulich wrote:
>> On 24.06.2025 11:29, Chen, Jiqian wrote:
>>> On 2025/6/24 16:05, Jan Beulich wrote:
>>>> On 24.06.2025 10:02, Chen, Jiqian wrote:
>>>>> On 2025/6/20 14:38, Jan Beulich wrote:
>>>>>> On 19.06.2025 08:39, Chen, Jiqian wrote:
>>>>>>> On 2025/6/18 22:05, Jan Beulich wrote:
>>>>>>>> On 12.06.2025 11:29, Jiqian Chen wrote:
>>>>>>>>> @@ -29,9 +30,22 @@ typedef int vpci_register_init_t(struct pci_dev *dev);
>>>>>>>>>   */
>>>>>>>>>  #define VPCI_MAX_VIRT_DEV       (PCI_SLOT(~0) + 1)
>>>>>>>>>  
>>>>>>>>> -#define REGISTER_VPCI_INIT(x, p)                \
>>>>>>>>> -  static vpci_register_init_t *const x##_entry  \
>>>>>>>>> -               __used_section(".data.vpci." p) = (x)
>>>>>>>>> +#define REGISTER_VPCI_CAPABILITY(cap, finit, fclean, ext) \
>>>>>>>>> +    static const vpci_capability_t finit##_t = { \
>>>>>>>>> +        .id = (cap), \
>>>>>>>>> +        .init = (finit), \
>>>>>>>>> +        .cleanup = (fclean), \
>>>>>>>>> +        .is_ext = (ext), \
>>>>>>>>> +    }; \
>>>>>>>>> +    static const vpci_capability_t *const finit##_entry  \
>>>>>>>>> +        __used_section(".data.rel.ro.vpci") = &finit##_t
>>>>>>>>
>>>>>>>> Could you remind me why the extra level of indirection is necessary here?
>>>>>>>> That is, why can't .data.rel.ro.vpci be an array of vpci_capability_t?
>>>>>>> You mean I should change to be:
>>>>>>> #define REGISTER_VPCI_CAPABILITY(cap, finit, fclean, ext) \
>>>>>>>     static const vpci_capability_t finit##_t \
>>>>>>>         __used_section(".data.rel.ro.vpci") = { \
>>>>>>>         .id = (cap), \
>>>>>>>         .init = (finit), \
>>>>>>>         .cleanup = (fclean), \
>>>>>>>         .is_ext = (ext), \
>>>>>>>     }
>>>>>>>
>>>>>>> Right?
>>>>>>
>>>>>> Yes, subject to the earlier comments on the identifier choice.
>>>>> Got it.
>>>>> One more question, if change to be that, then how should I modify the definition of VPCI_ARRAY?
>>>>> Is POINTER_ALIGN still right?
>>>>
>>>> Yes. The struct doesn't require bigger alignment afaics. (In fact in principle
>>>> no alignment should need specifying there, except that this would require
>>>> keeping the section separate in the final image. Which I don't think we want.)
>>>>
>>>>> Since I encountered errors that the values of __start_vpci_array are not right when I use them in vpci_init_capabilities().
>>>>
>>>> Details please.
>>> After changing __start_vpci_array to be vpci_capability_t array, codes will be (maybe I modified wrong somewhere):
>>>
>>> diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
>>> index c51bbb8abb19..9f2f438b4fdd 100644
>>> --- a/xen/drivers/vpci/vpci.c
>>> +++ b/xen/drivers/vpci/vpci.c
>>> @@ -36,8 +36,8 @@ struct vpci_register {
>>>  };
>>>
>>>  #ifdef __XEN__
>>> -extern const vpci_capability_t *const __start_vpci_array[];
>>> -extern const vpci_capability_t *const __end_vpci_array[];
>>> +extern vpci_capability_t __start_vpci_array[];
>>> +extern vpci_capability_t __end_vpci_array[];
>>
>> Just fyi: You lost const here.
>>
>>> @@ -255,7 +255,7 @@ static int vpci_init_capabilities(struct pci_dev *pdev)
>>>  {
>>>      for ( unsigned int i = 0; i < NUM_VPCI_INIT; i++ )
>>>      {
>>> -        const vpci_capability_t *capability = __start_vpci_array[i];
>>> +        const vpci_capability_t *capability = &__start_vpci_array[i];
>>>          const unsigned int cap = capability->id;
>>>          const bool is_ext = capability->is_ext;
>>>          int rc;
>>> diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
>>> index f4ec1c25922d..77750dd4131a 100644
>>> --- a/xen/include/xen/vpci.h
>>> +++ b/xen/include/xen/vpci.h
>>> @@ -31,14 +31,13 @@ typedef struct {
>>>  #define VPCI_MAX_VIRT_DEV       (PCI_SLOT(~0) + 1)
>>>
>>>  #define REGISTER_VPCI_CAPABILITY(cap, finit, fclean, ext) \
>>> -    static const vpci_capability_t finit##_t = { \
>>> +    static vpci_capability_t finit##_entry \
>>> +        __used_section(".data.rel.ro.vpci") = { \
>>>          .id = (cap), \
>>>          .init = (finit), \
>>>          .cleanup = (fclean), \
>>>          .is_ext = (ext), \
>>> -    }; \
>>> -    static const vpci_capability_t *const finit##_entry  \
>>> -        __used_section(".data.rel.ro.vpci") = &finit##_t
>>> +    }
>>>
>>>  #define REGISTER_VPCI_CAP(cap, finit, fclean) \
>>>      REGISTER_VPCI_CAPABILITY(cap, finit, fclean, false)
>>>
>>> I print the value of NUM_VPCI_INIT, it is a strange number (6148914691236517209).
>>
>> What are the addresses of the two symbols __start_vpci_array and __end_vpci_array?
> __end_vpci_array is 0xffff82d0404251b8
> __start_vpci_array is 0xffff82d040425160
> NUM_VPCI_INIT is 0x5555555555555559
> sizeof(vpci_capability_t) is 0x18

Oh, of course - there's a psABI peculiarity that you run into here: Aggregates
larger than 8 bytes are required to have 16-byte alignment. Hence while
sizeof() == 0x18 and __alignof() == 8, the section contributions still are
accompanied by ".align 16", and thus respective padding is inserted by
assembler and linker. IOW you end up with two 32-byte entries and a trailing
24-byte one. The easiest (and least problematic going forward) approach to
deal with that is probably going to be to add __aligned(16) to the struct
decl. (Whether to limit this to just x86 I'm not sure: While other psABI-s may
be different in this regard, we may want to be on the safe side.)

However, there looks to be another (gcc) anomaly: By default, half-way recent
gcc aligns this kind of object even to 32-byte boundaries, due to defaulting
to -malign-data=compat. We will want to consider to use -malign-data=abi
instead (supported by gcc5 and newer). I'm in the process of preparing a patch
to propose this more formally.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 09:04:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 09:04:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024494.1400339 (Exim 4.92)
	(envelope-from )
	id 1uUM3P-0004Nf-PC; Wed, 25 Jun 2025 09:04:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024494.1400339; Wed, 25 Jun 2025 09:04:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUM3P-0004NY-Ky; Wed, 25 Jun 2025 09:04:27 +0000
Received: by outflank-mailman (input) for mailman id 1024494;
 Wed, 25 Jun 2025 09:04: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 1uUM3O-0004NS-D9
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 09:04:26 +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 628b4598-51a3-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 11:04:22 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a503d9ef59so4286268f8f.3
 for ; Wed, 25 Jun 2025 02:04:22 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-749c887586dsm3856893b3a.158.2025.06.25.02.04.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 25 Jun 2025 02:04:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 628b4598-51a3-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750842262; x=1751447062; 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=wAVbUXgy7vt1kY/50PVUiDr+/RKIFhkPfiwiNTsCpWA=;
        b=gf5tvw1J4q3fP68anuv9xKIpPRkZ8CpmmRDSVjL6ZE2TdzRQ4An5j9MVq0OYtFM864
         VKDoABIj2KjE0yl9R8ZwT8lbOBh0C1WATGRKf0f+JNzEYkUhUmfIL2SdHCEoJEiMOdAM
         kZar6Hf//piY35v+damdgIIuUmz057fjmFJiBc0Hld5kS6VCUONxSPTEji2MmVOtnKJH
         9/vPZgP+6FEunrDsX61Xff80dfKOVJH80Z61qGsIFhk1BEAqLBrKGOUM98ZBfPMSe5F+
         B5Ng90x/wTbguGPNDiYax9UF75HnA7U6L04gVNU8CaKbp9BEsSRVhtsd4aBLxi1HrqlW
         UJNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750842262; x=1751447062;
        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=wAVbUXgy7vt1kY/50PVUiDr+/RKIFhkPfiwiNTsCpWA=;
        b=lSIcMQrtPAhmaSJ+Wjg3LL4gjsUnanVntEim4tp9vwYQ+s5XMIs8lR6ghHaRrnjnMQ
         8NH68C/ahWFemcIBCaQSLKY0wLWjBDKQYMlje5dFO/Uuy2PzgM/DX5/oTLXUPE43lyws
         wRNp4xLISw/IPNwrS9RL97haTvyXmXZHv9+XJdrdSTsrgT+ZtgHI/tz9xvSUKmS5Ykrw
         KWdh4JJX22lOx5H+9+kvnASRPL49ABUKztHrFe9dg6oh8o40dlPzZdqtQ/fLYR5dCZQO
         X6iRuuu6SrfEyMc1Vwv6YV26aW+gRdOpZuff62WuWoQryfvlY5ZpI0jEEIF1kWqfjVC6
         3ahQ==
X-Gm-Message-State: AOJu0YwGxOKI9X33FkuFOy/K7SOEGITk0g9LASxUCNbhDt26yXYHaZdN
	v2YfB+Rpd2doNy1oW7hZARDMMs8jUwTGrpO9//U4W9i6GJr2q+Q+Eao4yAm0GB+Phmgih4P4nXA
	rVOA=
X-Gm-Gg: ASbGncsGjVSsw0RaY7WK69nwH1v8MA4rU1o/eYqKB064COBAPDqeVYyV+mcjVJUz8ja
	flW5b1WRCY2PQMHjiRt2v3qzAU0k7Naiyx15CrN2ILPA5lvT5O0OAmPYAE9pq4KbUFFAS7A/j1r
	hMGlsWJ9xWrDcfnE//DuEJeP3XGAgO+QQiS9pGhsr7k+oE2z9kio4A2MCR7mZqOqrdCbCf6buCo
	bYLdAxhxqdDCggeGABDmBQ9mdXnQILTnkzb83PTD5g6NUpi4wV8dtCRCKdswee75BYBQ2TLnYaT
	aRi9+0Mtg5hXrrc59wNHLzDOOSLEJKP4x7p/iLq3vskBZOlGKe0J4zcg6ybHTtfI7fti2Gz304R
	Ycf+wAOdCbcdqwxknCsQFNcTvsuspo3XyQuFEUYsmA/X1Cwo=
X-Google-Smtp-Source: AGHT+IGRO4recyp9hehWWSeWwTskw7onPVlriAxn/9Z9hc0X8O49QnU6wSNuB1YILzsMk/DnynHJsQ==
X-Received: by 2002:a5d:58cf:0:b0:3a4:f655:8c4d with SMTP id ffacd0b85a97d-3a6ed642557mr1253147f8f.27.1750842261789;
        Wed, 25 Jun 2025 02:04:21 -0700 (PDT)
Message-ID: 
Date: Wed, 25 Jun 2025 11:04:14 +0200
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?= ,
 Chen Jiqian 
From: Jan Beulich 
Subject: [PATCH] x86: don't have gcc over-align data
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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

For (aiui) backwards compatibility reasons, gcc defaults to a mode that
was the exclusive one up to gcc4.8, establishing 32-byte alignment for
aggregates larger than a certain size. We don't rely on such, and hence
we can do with the psABI-compliant 16-byte alignment.

Savings in the build I'm looking at:
- .data.ro_after_init		 344 bytes
- .rodata + .data.rel.ro	1904 bytes
- .init.*data.cf_clobber	 232 bytes
- .init (overall)		 688 bytes
- .data.read_mostly		 864 bytes
- .data				 600 bytes
- .bss				1472 bytes

Overall xen-syms' _end happens to move down there by 2 pages.

Clang doesn't support the option, presumably because they never over-
aligned data.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/arch.mk
+++ b/xen/arch/x86/arch.mk
@@ -8,6 +8,9 @@ CFLAGS += -DXEN_IMG_OFFSET=$(XEN_IMG_OFF
 # Prevent floating-point variables from creeping into Xen.
 CFLAGS += -msoft-float
 
+# Don't needlessly over-align larger aggregates.
+CFLAGS-$(CONFIG_CC_IS_GCC) += -malign-data=abi
+
 $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
 $(call cc-option-add,CFLAGS,CC,-Wnested-externs)
 $(call as-option-add,CFLAGS,CC,".equ \"x\"$(comma)1",-DHAVE_AS_QUOTED_SYM)


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 09:05:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 09:05:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024501.1400347 (Exim 4.92)
	(envelope-from )
	id 1uUM4s-0004t1-1r; Wed, 25 Jun 2025 09:05:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024501.1400347; Wed, 25 Jun 2025 09:05:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUM4r-0004st-Vb; Wed, 25 Jun 2025 09:05:57 +0000
Received: by outflank-mailman (input) for mailman id 1024501;
 Wed, 25 Jun 2025 09:05: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 1uUM4q-0004sl-5Y
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 09:05:56 +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 99b532e8-51a3-11f0-a30f-13f23c93f187;
 Wed, 25 Jun 2025 11:05:55 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a365a6804eso848507f8f.3
 for ; Wed, 25 Jun 2025 02:05:55 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-315f53d9098sm1235474a91.31.2025.06.25.02.05.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 25 Jun 2025 02:05:53 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 99b532e8-51a3-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750842354; x=1751447154; 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=OuI9+lF7qlVECjIOb4TEfzkDj+6Kd7hWaKl7whIrRmk=;
        b=FGmwWs3M07DPjdC3mrRu5CTNZWNsEyL4iC1B7irMeA5q6pcDliCLieoRhtZf5WfDWx
         8YiyuzB9iTV+nZI2/Jz/t8I3xYIeyzpiiy1WsYKPJozm/CkBf4LGqLUSpexIRQ4glaul
         khL5scjAqNP8uJcHXhRO5fv90ip/kk0hs/I58g0vjDJGimLCA/gU3XckspM2d5F+O8gw
         4NFNOaoQMO7Kc/01Qb9wiWDJ0duW37H+jXuCRgg8/7AqwdRDT+2/9PrhqKo0tYQQsvQg
         DsiiXsG/ucvI0ro7gcGXKZrnYnZgANtJVPVTc0cMcpdnWm3/ooNbrAp69V5m6yRt/t/r
         rc9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750842354; x=1751447154;
        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=OuI9+lF7qlVECjIOb4TEfzkDj+6Kd7hWaKl7whIrRmk=;
        b=da/DKvOopQUvEDvPtMhFrJP/jKL6Ru17N4SBKQV94Zd5JSlEqU3m9qXWpSVLVPHNvh
         5XQdOFn2G2jVeAgcrxrY0LjfU/sYS+bAG9TAZKObQ8TPj4P3Qdh69EDfvj2sbrwVMcgb
         rSSeuhSceknrgNkVyeQIprJXVxi88PBMw/StyIuz33+s8c/G8rnsesikuxIxHTks/yJC
         XMnErhVGCCSjN0Cd8Izc6Rper7e4K+5kuZZLsEGEifFguD3/KMeRTThltgGwQYod+aoQ
         uCtlAiIIoD6pRuc0OWuDcF8NAK0rmiLLeQz3uDTdY/y6wb/GYYLvH7q5Lx8Qo/oyEBL/
         nWVQ==
X-Gm-Message-State: AOJu0Yypl1uBqtvyMwi32UyeSVEKKSwhfzQywL7uG47SxsJBqnfj+tuB
	GcV6gNTSpc62+yGzp+L1q6myhkql2h+rpm/CIilVpWrpV/MscGl/GjNUWpo2OQMkPrgqzW4nhIZ
	MEUE=
X-Gm-Gg: ASbGncve64Ko+cVwvJ5ILUaE0LUUVLiMDndbrxIrLisSmziuY41QetOpCl7E71VwRmc
	Ma78DrwqxZy2S5vEi+cyxi2btGi36DAq4UxWk3/KIk9H7Ds8HbFh6HHDTlgsLMHD3OYQMHMlGU0
	fKZhs/e+DfqRFByvmc/zZ7TxqP0mAI7gdRO0DuGAIiHFU568fKCLkSHXIOyWOrSBioTgx2+LxK9
	PfgM4r8ThsicadfpHABnAulybib66yGbf7DhEvQZWy04QH3DzlZ9RmeZCVL5CFMD6dd/nskssCt
	OfADr3dGPTtzKhC0CLQA//cOjcgj3xlgF0R/kpoJVormxPTzyfSZQhzaxvhPBIUs2uqPyt4giK3
	nbLktUnur7UPNHSNsoT2kNjbKJhj+FDR7pVbGFjSKf0uhTCY=
X-Google-Smtp-Source: AGHT+IHc1brvycHUDqGfh4sWCwouMRG1kvc0R1WO0f2urWT8RnQGfVLk0rtFLAMOhpf4oYMoaVrxUA==
X-Received: by 2002:a05:6000:40ca:b0:3a4:c2e4:11b with SMTP id ffacd0b85a97d-3a6ed66fabfmr1419464f8f.51.1750842354330;
        Wed, 25 Jun 2025 02:05:54 -0700 (PDT)
Message-ID: 
Date: Wed, 25 Jun 2025 11:05:47 +0200
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?= 
From: Jan Beulich 
Subject: [PATCH] x86/boot: move l_bootmap
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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

Having them in the general .init.data section is somewhat wasteful, due
to involved padding. Move them into .init.data.page_aligned, and place
that right after .init.bss.stack_aligned.

Overall .init.data* shrinks by slightly over 2 pages in the build I'm
looking at.

Signed-off-by: Jan Beulich 
---
All three tables are merely zero-filled. They could hence even be put in
.init.bss.page_aligned, yet then we perhaps better wouldn't use .fill
but .skip there (i.e. a larger diff for little gain). Thoughts?

--- a/xen/arch/x86/boot/x86_64.S
+++ b/xen/arch/x86/boot/x86_64.S
@@ -193,7 +193,7 @@ END(idle_pg_table)
 GLOBAL(__page_tables_end)
 
 /* Init pagetables. Enough page directories to map into 4GB. */
-        .section .init.data, "aw", @progbits
+        .section .init.data.page_aligned, "aw", @progbits
 
 DATA_LOCAL(l1_bootmap, PAGE_SIZE)
         .fill L1_PAGETABLE_ENTRIES, 8, 0
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -221,6 +221,7 @@ SECTIONS
   DECL_SECTION(.init.data) {
 #endif
        *(.init.bss.stack_aligned)
+       *(.init.data.page_aligned)
 
        . = ALIGN(POINTER_ALIGN);
        __initdata_cf_clobber_start = .;


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 09:15:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 09:15:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024508.1400358 (Exim 4.92)
	(envelope-from )
	id 1uUMDw-0006aj-V3; Wed, 25 Jun 2025 09:15:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024508.1400358; Wed, 25 Jun 2025 09:15: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 1uUMDw-0006ac-SQ; Wed, 25 Jun 2025 09:15:20 +0000
Received: by outflank-mailman (input) for mailman id 1024508;
 Wed, 25 Jun 2025 09:15: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 1uUMDv-0006aW-Bw
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 09:15:19 +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 e92ff4dd-51a4-11f0-a30f-13f23c93f187;
 Wed, 25 Jun 2025 11:15:17 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3a4fb9c2436so959855f8f.1
 for ; Wed, 25 Jun 2025 02:15:17 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-749c8851b90sm3952113b3a.127.2025.06.25.02.15.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 25 Jun 2025 02:15:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e92ff4dd-51a4-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750842917; x=1751447717; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=CmgWHc4X1qkNq2u665PqDQpHYrMcxnRRycuhOeFkBN8=;
        b=NqSSddAuz7CVhCsi1izMVsVEBCD7neBvnfxLqmi3xHU7E8SPX2aHwGEMYVRudNh0+n
         AByHF05l2x1zP4pSZJC47MoTPfZzrrBwxhmMgmXO0V9x1Q5Vkbnshl61QI+7KmvLvTzh
         lZqirqrfh6sag6y2JdrpslRt11eQzTD5tUHkEohgp/Yc4pXptzlJsCIukh2eBboY//4p
         ihP4WA5neQ31EClJ9hGlpGkInF9Tp4ZZuBBYNs/D8TX2GQ7IgMVvNmiYGESWJSaBRZvI
         rfb0H+5OQ7yqFA31P/jRWRu+5WXH1YhEHaPwOeBlnPClxH+GXIqW52+2N6BhnRzG2lQL
         /LaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750842917; x=1751447717;
        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=CmgWHc4X1qkNq2u665PqDQpHYrMcxnRRycuhOeFkBN8=;
        b=O2oPfsVB9Dq9y0D1HYQYr65MeVJ1odfqKzN4Y938iq7g3n0KVd/fAz1vFLNQD7KKkg
         ea4grzitjbok6wOMH5udZ4idwTBtYmupzyvLm2G7Dw5zcQ0LL+J4EZ8h7xtJt70Y+nOE
         KlvlUD10+vwcmRKvCZs6GOuhKshEJodYyTJyouaSd74j0i5EkpodUJmM7Qn0RG73rkfS
         4yTdkASGOK1LYQR0kkAeFJBI7C4A0d5hXn37+Y7K9/i/IeHiVyGGNV0KeC5Cz+kmEa2g
         aopeyDSouKC+Ykxe593yn8GnDjUzPD8XKOG4kbQ4R+aydOrZlrcPU/5mGS3mxbL8Sr1z
         OVGQ==
X-Forwarded-Encrypted: i=1; AJvYcCXOvCJGDJ1xHSEv8VhXb+R9sq3pnFRfMq9BDuUSqo1n8rkYHgwz7mTAL0UvSB2tCfv1Kjm9iOvJPOY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyYb2VV6VBgUfW30he8kHix6bLKfsKRGxuNOPAxf3U40reGY9vB
	LNNTmur6MY04pHHxlqaHq2eDT1+nncJZ47pAU+RfR38HKKU8G7pTjNrpkGXJm0jG5g==
X-Gm-Gg: ASbGnct7NbanmGV03qH2FH1cHX9WYJ9W13J2z4SVYGfB9jhBGonMblZdiy55D5b0ZsW
	y0wL3K78DOk7TEJ+WZhIXI/d8I686FbxiJ5MeuMqmw0UB3AVihyy4UzmNY6sjk+NQZcVV/9GsOv
	fXsTJv1IWsc4Ux26ApxFsaW5EjvCVTJ9MZOyPYV8cPmz80xR5f2jjy4DwhXD1KPlcwjv4ObOtME
	i8Shu1A3xWCaCIIlOrdvo4rFvZTsAikuqta62xfpqPXWhOJqTF4jEi0RI0ScmyxE1mCnfB7YwME
	8nsobw7U/M+o1L+zrVB/W0IEvPYV83BvY2770Z+bzd3dNmqz9GG9QODiAWduZ9rXXtFTZYw1/60
	WRPH1+FXJpJJl5Q2OvoXSvHbJjY/wQ1eygLi1GYHfntoh5egODlAoBkkJ4g==
X-Google-Smtp-Source: AGHT+IHIZbxB0e9wYBJ7nCRbVT9mr3tDkvKLzh8J29co+wRc/u9j7vMaUWoD+PNP5J5/uMvdrrveGg==
X-Received: by 2002:a05:6000:2810:b0:3a4:d939:62fc with SMTP id ffacd0b85a97d-3a6ed638772mr1005308f8f.22.1750842917127;
        Wed, 25 Jun 2025 02:15:17 -0700 (PDT)
Message-ID: 
Date: Wed, 25 Jun 2025 11:15:09 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 7/8] vpci/msi: Free MSI resources when init_msi() fails
To: "Chen, Jiqian" 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "xen-devel@lists.xenproject.org" ,
 "Huang, Ray" 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-8-Jiqian.Chen@amd.com>
 <773c448a-d814-458f-ad83-e9740e724408@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 25.06.2025 09:16, Chen, Jiqian wrote:
> On 2025/6/24 18:17, Jan Beulich wrote:
>> On 24.06.2025 11:49, Chen, Jiqian wrote:
>>> On 2025/6/18 22:45, Jan Beulich wrote:
>>>> On 12.06.2025 11:29, Jiqian Chen wrote:
>>>>> --- a/xen/drivers/vpci/msi.c
>>>>> +++ b/xen/drivers/vpci/msi.c
>>>>> @@ -193,6 +193,33 @@ static void cf_check mask_write(
>>>>>      msi->mask = val;
>>>>>  }
>>>>>  
>>>>> +static int cf_check cleanup_msi(struct pci_dev *pdev)
>>>>> +{
>>>>> +    int rc;
>>>>> +    unsigned int end, size;
>>>>> +    struct vpci *vpci = pdev->vpci;
>>>>> +    const unsigned int msi_pos = pdev->msi_pos;
>>>>> +    const unsigned int ctrl = msi_control_reg(msi_pos);
>>>>> +
>>>>> +    if ( !msi_pos || !vpci->msi )
>>>>> +        return 0;
>>>>> +
>>>>> +    if ( vpci->msi->masking )
>>>>> +        end = msi_pending_bits_reg(msi_pos, vpci->msi->address64);
>>>>> +    else
>>>>> +        end = msi_mask_bits_reg(msi_pos, vpci->msi->address64) - 2;
>>>>> +
>>>>> +    size = end - ctrl;
>>>>> +
>>>>> +    rc = vpci_remove_registers(vpci, ctrl, size);
>>>>> +    if ( rc )
>>>>> +        return rc;
>>>>
>>>> This is a difficult one: It's not a good idea to simply return here, yet
>>>> at the same time the handling of the register we're unable to remove may
>>>> still require e.g. ...
>>>>
>>>>> +    XFREE(vpci->msi);
>>>>
>>>> ... this. There may therefore be more work required, such that in the
>>>> end we're able to ...
>>>>
>>>>> +    return vpci_add_register(pdev->vpci, vpci_hw_read16, NULL, ctrl, 2, NULL);
>>>>
>>>> ... try this at least on a best effort basis.
>>>>
>>>> More generally: I don't think failure here (or in other .cleanup hook
>>>> functions) may go entirely silently.
>>> Does below meet your modification expectations?
>>
>> Not sure, sorry. By "more" I really meant "more" (which may just be code
>> auditing, results of which would need writing down, but which may also
>> involve further code changes; see below).
>>
>>>     rc = vpci_remove_registers(vpci, ctrl, size);
>>>     if ( rc )
>>>         printk(XENLOG_ERR "%pd %pp: remove msi handlers fail rc=%d\n",
>>>                pdev->domain, &pdev->sbdf, rc);
>>>
>>>     XFREE(vpci->msi);
>>
>> As I tried to indicate in my earlier reply, the freeing of this struct is
>> safe only if the failure above would not leave any register handlers in
>> place which still (without appropriate checking) use this struct.
> Hmm, but all handlers added in init_msi() use this struct.
> So it doesn't exist the case that when above unable to remove all handlers and still require xfree this struct.

Well, in the end you say in different words what I did say, if I understand
correctly. There are several options how to deal with that. One might be to
have those handlers recognize the lack of that pointer, and behave like ...

>>>     /*
>>>      * The driver may not traverse the capability list and think device
>>>      * supports MSI by default. So here let the control register of MSI
>>>      * be Read-Only is to ensure MSI disabled.
>>>      */
>>>     rc = vpci_add_register(vpci, vpci_hw_read16, NULL, ctrl, 2, NULL);

... what is tried to be put in place here (and like "no handler installed"
for other registers).

>> You're losing the earlier error here, if there was one. If this one
>> succeeds, ...
> But if return the earlier error to the caller, this device will be unusable, then still adding this handler when above failing to remove handlers is useless.

True, yet that's the case also with your code if removing the ctrl handler
failed, as then the attempt above to add another handler would also fail.

I don't know what the best approach is (I did suggest one above, albeit
that's not quite complete yet as to the behavior here); I merely observed
that the behavior as you have it doesn't look quite right / consistent.

Jan

>>>     if ( rc )
>>>         printk(XENLOG_ERR "%pd %pp: add dummy msi ctrl handler fail rc=%d\n",
>>>                pdev->domain, &pdev->sbdf, rc);
>>>
>>>     return rc;
>>
>> ... the caller would (wrongly) get success back.
>>
>> Jan
> 



From xen-devel-bounces@lists.xenproject.org Wed Jun 25 09:19:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 09:19:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024519.1400368 (Exim 4.92)
	(envelope-from )
	id 1uUMI9-0007DQ-Io; Wed, 25 Jun 2025 09:19:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024519.1400368; Wed, 25 Jun 2025 09:19:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUMI9-0007DJ-Fg; Wed, 25 Jun 2025 09:19:41 +0000
Received: by outflank-mailman (input) for mailman id 1024519;
 Wed, 25 Jun 2025 09:19: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 1uUMI8-0007DA-Ae
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 09:19:40 +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 851ff450-51a5-11f0-a30f-13f23c93f187;
 Wed, 25 Jun 2025 11:19:39 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3a531fcaa05so2958874f8f.3
 for ; Wed, 25 Jun 2025 02:19:39 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-749c88532absm4208139b3a.131.2025.06.25.02.19.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 25 Jun 2025 02:19:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 851ff450-51a5-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750843179; x=1751447979; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=sYn1x5oEmuiSA6FLdznXxNVrpOZ/8QkMXxM3/RevbEw=;
        b=XbSAi/lIsoeSI6HKEBgsgWvcOTjfIMFPeA6TKBdFaMVUMJOCLyQaMhWxPM3FO39YfP
         oG+fmfHUoSFqN9JMjtkdd6pws1Ux82216HWhOg9tUlKUPixS9EO3JH+w2KqejVsAt/zn
         /t+YKZeAO5TtXWk0cbdqh6aLhDBitWK70x0nl3fVruqoiJKYrwvxkhO2T0OQ/jQUbDlx
         d/JcZuu/rA/f3OTl4TjZr0QRp9LHURwYa1JQ9AIdwR1l2fhS95C9lryWdlq+9nX+1YpC
         Blqy/tmnvMtHq+DkqtFItzNoKWyCQE20bDCDRV3UkS49exb+WPRXYA3O8Gn5PcKgH5dW
         rT/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750843179; x=1751447979;
        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=sYn1x5oEmuiSA6FLdznXxNVrpOZ/8QkMXxM3/RevbEw=;
        b=REihmVh9rxh0qHLJZatvIiyDeZitlW9tf3yfRwm2P9mmXYeuoxug108hYQkME3uzrM
         s6n98nF1zzLNW501rVaeeapiWHEl3lGt8P5VXKxEjjp8Gvg/lmUUvq+eehxgKqkcqZI/
         Act39uZ0Mp1RjIBgqUx81inrFTF237IqQ2SnYJFK+c6rL4+wKfEE+4bpJKaYcNnnBHQO
         rAUEZ/tKcmh+N4fHS5D71FxFWZTLheOjWyak3Y01o+ijK9iZNDVpRTkPEpeSxrFobqBO
         f3Dt5wy/YpWMiDi4SDajAtMNcPsZamB7czwGnXdahsdkvYamrL4ycBaFotNUX3pmh0CY
         jF3Q==
X-Forwarded-Encrypted: i=1; AJvYcCUfbFkXaGYMml/4Dx0o1b6XJMonbb6LYDP5xS6Zrs1auJZnGdkzPS7IN3WGFGS1CjeGxnzqu31mtsI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YydhFxMmqVa8J9NBtVbj901ddga97rITAUs8mXDB1kt92EGK+JP
	6fr1j4eZYaRg5m24fZJ+2z7fP62M5h55onishighz8ld0jWMlfIjK9ynBvFiuivNQg==
X-Gm-Gg: ASbGncsGM4AGxuiEgNIEzDsdCz2DFlYeWqzs7zIGy9MDntVedXJpF6TaFeiR1scDKHD
	MUwAJUkK/ts2zjO7+yuIA/l42g+Kcd71Wu0+xmVgsc07K+4oaYjx6Guk8ZuBPo+R5MXA/rHf3js
	Oi8t2J8Yc2VwDbjFAav4SY7ShIl0tFHMIs/17CvrokKd9jjoM/HipNPAyneQCq6KN63IKGnaneQ
	3FlVVuNRj4Z/Y3VDbDh1xM17prMBx9ca1EXr8CPlB4agW2uE2gMlVw66pxYPgaGq0OADa0flau2
	zX96n8SRJ1cXYOZlWFxE3/UJgjdjcNWtdoFwgk0Yy1o9TV3B3y1ZhDt7GZH+xdvoYz64c7n9JA2
	B2wIxxQBGbCSWUNQhy7MzjkWqvKPW4E3WxqJVNJdvF1vmIMY=
X-Google-Smtp-Source: AGHT+IG3qua4F0WkdiAGSQC5O7N4zIJl/M9LXQYs2Aw523TbATL/DsYvFbKrDk0v+gK3e+HCDuFs0A==
X-Received: by 2002:a05:6000:18ad:b0:3a3:6b07:20a1 with SMTP id ffacd0b85a97d-3a6ed652850mr1717756f8f.40.1750843178838;
        Wed, 25 Jun 2025 02:19:38 -0700 (PDT)
Message-ID: 
Date: Wed, 25 Jun 2025 11:19:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/4] x86/idle: Move monitor()/mwait() wrappers into
 cpu-idle.c
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20250624163951.301743-1-andrew.cooper3@citrix.com>
 <20250624163951.301743-2-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20250624163951.301743-2-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 24.06.2025 18:39, Andrew Cooper wrote:
> They're not used by any other translation unit, so shouldn't live in
> asm/processor.h, which is included almost everywhere.
> 
> Our new toolchain baseline knows the MONITOR/MWAIT instructions, so use them
> directly rather than using raw hex.
> 
> Change the hint/extention parameters from long to int.  They're specified to
> remain 32bit operands even 64-bit mode.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 

We may need to undo this though if we ever meant to use mwait elsewhere, like
for spinlocks. Many years ago that idea was entertained some, but it may well
be that it was given up altogether by now.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 09:26:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 09:26:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024526.1400378 (Exim 4.92)
	(envelope-from )
	id 1uUMOC-0000TP-5U; Wed, 25 Jun 2025 09:25:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024526.1400378; Wed, 25 Jun 2025 09: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 1uUMOC-0000TI-2l; Wed, 25 Jun 2025 09:25:56 +0000
Received: by outflank-mailman (input) for mailman id 1024526;
 Wed, 25 Jun 2025 09: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 1uUMOB-0000TC-4q
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 09:25:55 +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 63a7c8b1-51a6-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 11:25:52 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3a4fea34e07so703927f8f.1
 for ; Wed, 25 Jun 2025 02:25:52 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b31f124249bsm10574265a12.38.2025.06.25.02.25.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 25 Jun 2025 02:25:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 63a7c8b1-51a6-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750843552; x=1751448352; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=VKKjVWZ2YRcVdvg2lHk6HnNZ4Bkgleult3V2FPmOFNc=;
        b=dicUydZS7LgxiVPIVki/WJetFF8C+RfojKr223OvFq+cPfbVNiqaoACv9IIpya9J/n
         hHQr1VoNdxZmW+LY8+8bbq3LinlUk/W79p6Zhs4N2nwIyzYOsr1AMixMstboyaufh2r1
         +6R86yExY9gAlgQeGZj0AgWvhj7UXTrjXO5m97tq4Q5I3H38C0dMdIA3epPAdOagOtoz
         sqANOQsxfdGVGzzLZKljQhChghhK2UO8bJyLGEj5Sph8u9Zo4NDYDTtCZhO14K8Llu1z
         6AOsiLUJHsvk7sjUbyp4oyCRkh3a2hfn0wdlnrupyfSe0uIPCkjJCf/brWRSPJfrcX2Y
         eVdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750843552; x=1751448352;
        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=VKKjVWZ2YRcVdvg2lHk6HnNZ4Bkgleult3V2FPmOFNc=;
        b=IzkTABPtWqjFRlS+LS3x2EVqPrQMYKvSV3V2+Eb15NqKxR7Ekx6Di7MXHAhRyfwke5
         rbYk9yPwKRcTieP7gbrIL5arfu2kVrnKnP9HLXEYRx2p1umfimGiTU0xCFWqT2F0Skwe
         Xe8PcH2+GI+MycLhaoEj14UF/xxrAsWMt+46TykkQvSHSfvjBroQYAVYlkXQKT/bOokv
         1scZtqWrLgbKPFyvn9hZlUA3OFkz0Zv/VXZbyWYLdcp89zd0rml1GOlkkBaqfypmw8mQ
         5vkt8/EdcH1CQYmL2t1BiSGr9Oi3ZFSsbNIwIPZhS8Ys7sRCwgClGNssWUtLV/5e+zbS
         v+RQ==
X-Forwarded-Encrypted: i=1; AJvYcCXDaLawWT9e62EG8XGF7fBOilisZeSXYQgZAKOOR+oivLXF0Wp30lypbMLeFK0vkGkJ/vSVmeTeCsM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx7uQn+pFnv1sxKYUr62oUOuKtizbyXRco3X++c9pvGn0HwV+kG
	2aKm4BpkSuRg5yycapxVpfF7T1lOvOhmfXtw2bg6S1nOQDFFf8qIiPyP/VkY2RGXtg==
X-Gm-Gg: ASbGncsVmi2FzUFZH5QGDL2eUasWAPVZytqRKO1mUhJGUm1TBgyiBlnUgJjK2rMe4Sx
	xGu9kz1XaZIHaNgpCh6T7VO3kkPu1zLPpjaNubY0wB7Sjei20L5H0VWD6LQmp9JyBggxLpmAgNK
	BPtoo7SNF7UIqOTQtQbb5YqwWueLodKYMwQB98sJv6rO5veM81iHm9XhbnYPDCsKOLrrurCRx9A
	EBLRZtXFQ1aantuF1OxBM2ieOx/ddKzmL3pWLDE9EwSTRqjDw83RrlwVnqDqCw9rp0FdAxr96qA
	07bbKTob/WXQBgOF4qGYB9gFXOCjoOAjUidmUyJVtgQYwp7FursBb37otPZDQV8C/wR6f92CI+e
	WoLujyQMNdqcY4WGCId2HuZsV9PM8TrLtIvf21Cnh1BXjYk4=
X-Google-Smtp-Source: AGHT+IE92f1EdVifDWFUowityyhPSFM/8lOsOJo8SSxTTHLSwHHeyMMMbknkJpjUI7/8eumVxeYsrQ==
X-Received: by 2002:a05:6000:2d84:b0:3a4:cfbf:51a0 with SMTP id ffacd0b85a97d-3a6ed6222e9mr1349718f8f.21.1750843552144;
        Wed, 25 Jun 2025 02:25:52 -0700 (PDT)
Message-ID: 
Date: Wed, 25 Jun 2025 11:25:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/4] x86/idle: Remove MFENCEs for CLFLUSH_MONITOR
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20250624163951.301743-1-andrew.cooper3@citrix.com>
 <20250624163951.301743-3-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20250624163951.301743-3-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 24.06.2025 18:39, Andrew Cooper wrote:
> Commit 48d32458bcd4 ("x86, idle: add barriers to CLFLUSH workaround") was
> inherited from Linux and added MFENCEs around the AAI65 errata fix.
> 
> The SDM now states:
> 
>   Executions of the CLFLUSH instruction are ordered with respect to each
>   other and with respect to writes, locked read-modify-write instructions,
>   and fence instructions[1].
> 
> with footnote 1 reading:
> 
>   Earlier versions of this manual specified that executions of the CLFLUSH
>   instruction were ordered only by the MFENCE instruction.  All processors
>   implementing the CLFLUSH instruction also order it relative to the other
>   operations enumerated above.
> 
> I.e. the MFENCEs came about because of an incorrect statement in the SDM.

And their exact placement even differed between the two sites.

> The Spec Update (no longer available on Intel's website) simply says "issue a
> CLFLUSH", with no mention of MFENCEs.
> 
> As this erratum is specific to Intel, it's fine to remove the the MFENCEs; AMD
> CPUs of a similar vintage do port otherwise-unordered CLFLUSHs.

Nit: DYM "sport"? I think the corresponding Linux commit that I once looked
at has it that way.

> Move the feature bit into the BUG range (rather than FEATURE), and move the
> workaround into monitor() itself.
> 
> The erratum check itself must use setup_force_cpu_cap().  It needs activating
> if any CPU needs it, not if all of them need it.
> 
> Fixes: 48d32458bcd4 ("x86, idle: add barriers to CLFLUSH workaround")
> Fixes: 96d1b237ae9b ("x86/Intel: work around Xeon 7400 series erratum AAI65")
> Link: https://web.archive.org/web/20090219054841/http://download.intel.com/design/xeon/specupdt/32033601.pdf
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Wed Jun 25 09:27:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 09:27:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024532.1400388 (Exim 4.92)
	(envelope-from )
	id 1uUMPe-0000y3-Gv; Wed, 25 Jun 2025 09:27:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024532.1400388; Wed, 25 Jun 2025 09: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 1uUMPe-0000xw-CJ; Wed, 25 Jun 2025 09:27:26 +0000
Received: by outflank-mailman (input) for mailman id 1024532;
 Wed, 25 Jun 2025 09:27: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 1uUMPd-0000xq-Cy
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 09:27:25 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20612.outbound.protection.outlook.com
 [2a01:111:f403:2413::612])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 95ba6797-51a6-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 11:27:18 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by PH8PR12MB6721.namprd12.prod.outlook.com (2603:10b6:510:1cc::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.28; Wed, 25 Jun
 2025 09:27:14 +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.8835.027; Wed, 25 Jun 2025
 09:27: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: 95ba6797-51a6-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=akvj8ZDk1Nfq7fdc4Pv6I8WSJNZEO/OJZZHjOqN/tXhCa7jZWkvfLvedGL4bisrxqDAVPN6bpbFlI/84cWw6MuoK9HwdaPabDn/F39sjBh/YZOWZLoTuCm0zR72tHwtJRdrQSXvxZBjj13padVOdQefq/82vf8tun5JnAxZd5yN7/Lr7GrDiaREIrjQuzHOX1xrvJDsVrK1YlVCkua017AoND8z0toclj5XQIVNCODlruTwf7/q774CvgZQhbMydDKcFvVeaZsQQgz/uRH6Ea4jb9eDCSKyvV7skKmngyS1ZZIh9OIz9B28GmXu63ujHvS+hKH/QJk0Oer2sLJwBug==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=kfGqWPB5RHtMg4vAIjdmD6y/U1QN28cGjp7FvHZBi4E=;
 b=NX4IYP/v29VodyFSEb51QPBXk6d48h97z0m7xkC+a+B4Y90juivGMnYHXbs1he9xf1SvPZGT7ZB7Uwz6pdvISqk6njpC03L7oOJrCL2LN1VRvqyZMnBWYVIrn8V4boQ2GVFXBvbVLbwS4B5cf0AvYHfDjXuuPjfLT186oT4zhuS42QKWZFh4+DLU/ZFLHjVksPQqDYkJOuwmptggVZdylCLR72anJPNIgrfIk2H9vBJlFPUiviicArHq2TJYU6BOGZZfAQ3MwF0vFASfCqlWApsrzeKz8EPbsQFk9HYFBBiH9ciTSOTES+VJyfkSXhXzeaflVqCC7DQ7uRATwOFq0w==
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=kfGqWPB5RHtMg4vAIjdmD6y/U1QN28cGjp7FvHZBi4E=;
 b=2cWp7oLaSMycZR+uVTHvlNWUsZznp2yl8mfqk+5Sq7x4i7roZfFf+MzL4iax/McNbI/4/K8qu9X13SSzzlxsx+LjAXbDnYTRoIvctJuo+C4YFNUdY7LtCEL/CaATCJLlj8m60pHq/1M0XfofRVXlgpWRc1DcP5a6SbOn85LeYIU=
From: "Chen, Jiqian" 
To: Jan Beulich 
CC: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Andrew Cooper
	, Anthony PERARD ,
	"Orzel, Michal" , Julien Grall ,
	Stefano Stabellini , "xen-devel@lists.xenproject.org"
	, "Huang, Ray" , "Chen,
 Jiqian" 
Subject: Re: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
Thread-Topic: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
Thread-Index:
 AQHb23yakGdVC9XxvEWnYcnp8zrTt7QI/QAAgAGa9QCAAQzVgIAG5D6A//99hgCAAJwoAP//hioAgAHew4D//5oCgAASTfCA
Date: Wed, 25 Jun 2025 09:27:13 +0000
Message-ID:
 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-3-Jiqian.Chen@amd.com>
 <516a3adc-320d-46ce-b235-8ef91469abcf@suse.com>
 
 <227df6d3-a2c3-4576-bde9-d8057c378e7a@suse.com>
 
 <5c4b186e-686e-4fc8-bcf1-854bc1f5ec8b@suse.com>
 
 <9d5d0e44-66c3-4e3f-8704-2c862c5f5aff@suse.com>
 
 <3638e73c-2a83-4164-9a84-839245245727@suse.com>
In-Reply-To: <3638e73c-2a83-4164-9a84-839245245727@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.8835.025)
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_|PH8PR12MB6721:EE_
x-ms-office365-filtering-correlation-id: dd6e413f-d1e4-47d6-afce-08ddb3ca7851
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?N3pHdldVbVc3RVdNT3FZTUVHZmEzK1lieDNNbmREblkycjZKRldzc3ZGRktD?=
 =?utf-8?B?S0Z0QlhxQUI2a2NsZjVMM3BzYjZvYnZTQlNZOGg0enJFdWQ5OUNXZE0xbmty?=
 =?utf-8?B?bWR6MWVNTlQ3SnV0Ti92V2Z0N1VaU3VVWmtOb3M0ZFBMbVBiVFQ4VUgxRndK?=
 =?utf-8?B?UW94WDlGdlNwOEVoV1ZrTjdLU1prS0thZENLNTRqY092cDA4VmZ0ZXoxTWFj?=
 =?utf-8?B?cFpDeGFoRHd0MjhlcHRHWGVidDU4elpTbHFaUnNBUnpZTmFNL1hhRU56a2RR?=
 =?utf-8?B?TDVZWktyeGN1YTY5R08vYll6bk1YQ050SW5Fa010L2gvYVdyQ1hna25oWU5v?=
 =?utf-8?B?NjNkLzhCT1Nnbjd4NmltcnM0a1ZiMWhFL3BzY3g5eCtIYnRjZmhkbHZCRnFO?=
 =?utf-8?B?ZWV6dWFFeld1L0syVWMzYlMzdHordXNVZDNxcENLRzAyenZocVNVNnBhajRz?=
 =?utf-8?B?V2xVbFVaUytCejVwcDgveW4xMkNMOTdlRlVvdFFXWUhpWjFhdjc4dzNwZXJD?=
 =?utf-8?B?MnV6Q1R1M25hY2RSeExWMkVoRWRDUjdJSzJ1ejF5NmFjTTZyQU9pcnJ3TTVw?=
 =?utf-8?B?MUxtMXpCRGNtY3ZyVUFxZHRzWDVIMll6R3JXWTR1eWRqSzB5WUpmTzNlV0JB?=
 =?utf-8?B?ak52U0dyWmQ5d2lBM1U4RXRCbFdpaGpkK2FHdG0rVExQYmRzd0VMRkc5Wkd6?=
 =?utf-8?B?SHNITTRqKzM5S2h3RXMvVFNxdXM3R1JheTYwRVp3dzJHbEVFSHplWHR0YkMv?=
 =?utf-8?B?T0x6bXNNeVEyaHFwMEF3b0hXdXVhd0lNcWkrWktRNlphQVRVTWQwYVdLV1Ur?=
 =?utf-8?B?d3BMYnZEbGJuVU9TUnZDaG13UlBadHdvSWl5MS8vdkozS1dOT2JWelpGdXlQ?=
 =?utf-8?B?bVQxa0JpWS9pcWd2MmFLN0t3MlBBKzJzaVhSYjlITDIvbUQwVk1HUnR4N0Zn?=
 =?utf-8?B?dzFYeE9ScjBsaDVjKzVnY2l3ejBYQk5TNVZrQ1pyb0hJaEs0NjdvRGQ1dUhL?=
 =?utf-8?B?Nm9MdGpHcGpGVzdWM1dZMklLbmZDS0szNEN4OTgybHVQQllyU21GcXZhTU9T?=
 =?utf-8?B?R1g2OXhVdmk0bjNGcW1vQzhqUCtrSE56RFpjTWtOc1lOWnVwTnd3U0NiTXQr?=
 =?utf-8?B?SHdHM1FoeVhjeDJzZXJOUmRQYjZhS2VXNk96akNXbHUxNmd4MU9XUkpkMC9o?=
 =?utf-8?B?a0JyNFpuRTYzRzFVNTM5RW9hRXJuQnRqTzRXSHMxRDlRNFMraVE1VkdaMHQ5?=
 =?utf-8?B?UUREZUN0c3FJdDVETmRFWHFtK044cDNVMzMxVnpaRElmejRyMExyUzB4R1ZQ?=
 =?utf-8?B?WVJPNTNQdFJ3UURCaWdmYzcxYm16dVdxcTc3VXh1SkRQeStUcksyY3d6SVhF?=
 =?utf-8?B?VGMvR1EyVjN0d2owVWZCeW50S0xraDZtK1doL2I1aCtLU1U4eitWV3ZnK0s1?=
 =?utf-8?B?REc0MWZDQVFPOWVLQWlCUzY5b0VBcThkNklWcTZiSDlMWlVpaWZqYzFjUjdr?=
 =?utf-8?B?WFM1RG50WkQ1RWZGeHIySEJhMXlCNEZJaVQ5VG5wVVVDbmg5UktKOEJKNmg3?=
 =?utf-8?B?S0RLQWIycHB2eHFxVTNKUXdacEEvb0FGRFIvTUEzWWM0Nk1tYmhQaitBUUVW?=
 =?utf-8?B?SFgvMCtIY0dtTjNBeHdjR1ZUejRYSmt5a2U5TGw4UU1hbE4zRnFsb3dkTlJ6?=
 =?utf-8?B?S0F1RFY4OFU5M1BtUVMxd3FUS3VQMjBocTl0MHZHblhzbFd2QkNMam45enk5?=
 =?utf-8?B?UGdlUm9YcFNhd0NoU3ZGN2w1TXdUaWpIY1JPTk9lRkcvMmprK0VRbTVhRFZQ?=
 =?utf-8?B?YVFPV3ZjVi8wQmhpeHdPY2tkQVlkU3MycE5qQXZJREVvaWd4azdjSmhiSTdj?=
 =?utf-8?B?cFVNZGoxZ3JEQjdKQkxtYXE0dXJJd28vLzFPc1B0VTh3NDlhMlNiVHpPK0hG?=
 =?utf-8?B?VWx3bnRWV3lKZkZjOFVUNHRkSkhlc1ZCODVXbEg2dmJQL2tuN09lUzQ3Nlh4?=
 =?utf-8?Q?IhCXqzYdDNWsXAZkSQw5zswsOUeJig=3D?=
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?VTViOU5NVndsWjNwNzVtallhYjlpdUF1Yjk4bmNJaXk1a2ZjeWxtbDZvQ1BI?=
 =?utf-8?B?OUZFdTZtYTBRNWVBc1A5MkR0RXM5MDFlOG5KVi8xcUxEWFF3dmg3WjF4Vm9O?=
 =?utf-8?B?ZWpYaURpbitFS2lTSVVscGgzb01jVnArQWJKbnlUUnB3d3IwVHdVN2twMEkx?=
 =?utf-8?B?N2Fqd0l1UjluNHVsdG1PaWlINWV3TWtEV0VrOUZlOVFnQUNLeERNeUdXRTBJ?=
 =?utf-8?B?SzRhbVZaV29oS0xQWVQzU3BMN01ZQmg0UERQRHR6S1lub3JibzVadGpvU1lZ?=
 =?utf-8?B?dFpRUWVVdUI0a0RGeWRKanYzNWhUYnE2d0h1aS9JS3JVam1rcU9BWFlyQU9U?=
 =?utf-8?B?Nkw2cVBoZmxCbks3K3lVZ1NXNzVZU0lHOXN6V05CVTRxTVRqR3FNc2M3VEVS?=
 =?utf-8?B?OWtMNVE4QU1HOEw2VzdKamd1WnFrNVdtQkFsMUlMTjdLQkRDd1VvNzkvc0xw?=
 =?utf-8?B?YWQ1OEt5azF2S0FKTEZEWGJmbE1kUU8zM1lYL2o1UmFwQnlFbi9UZ3J4MklQ?=
 =?utf-8?B?dzNHZklhSFhlK05lSXp1M2NXTStjRERJa1EvcjE2UlpSUU40RUlsTXdIUDBS?=
 =?utf-8?B?SXM1RWcwdlFWdEpSamY5SzFka0NaRCtlNnZvVE9qRnE1NzdDQytzNERhVTVk?=
 =?utf-8?B?UitUdWdnUjRRdE5ycmVraFY1cjFZakM3RG5FV2trSjUvVFFXYVpjQ3c0MG1z?=
 =?utf-8?B?NGRZUktYeW95SU5YYWlvdzFEVU5ucVBVU1VPUEs4RWNBK3RnWjNnSTY0R3Yy?=
 =?utf-8?B?eXMwZmVIeTdvWVZ3SWQwWWorbnBmR29nc3NEMktMVENXQ1I5VGZ5aU50U3N3?=
 =?utf-8?B?ZnEzeUhOMXpzUWhaQ1M4clZwQXFpc0s3elRiWU5PYzFyalI0SXZPYWZ3WjZH?=
 =?utf-8?B?M1J4Rmg0YmlTOWpSUk12aUZ0S2kyWUZpcFM5SHRXaURsTVd1TU52RjJlQmpW?=
 =?utf-8?B?Z1RERk9vcUpuY0FPdEVJcHBLaDRWZzBTSkxja2hZcVlES3d4VU5FNFpFcGdx?=
 =?utf-8?B?TlJBUHg3ZFNpVTJZdjI3RWtTckV3dThIRW1yQ2JidjhLSHhTeEFtbG5RdlZw?=
 =?utf-8?B?L0VDVzlNTVVaZkRONUlXQVhEMElPT1R6cXpVUWlsMmU5QmFLNXB1cDU4MXUx?=
 =?utf-8?B?cGMzMXB3RVEySno1anJ5bUwwTnVzZXBJWEVNR1pUNmcya1VHaVFxOGF3ZTdv?=
 =?utf-8?B?K094dWQ3NExrY3U2WjZXdndSdW5xUkhzd3pRNkNtRHlDa29ncVVZSUJwZ0hW?=
 =?utf-8?B?S2F5RkZQYzVDVkRTODl1MVBYalpvQWozNmdCeGJnQmlUNWFmdXp0TXpKNE1V?=
 =?utf-8?B?K3V3akxEclRQKzhWK0hnWmtzTGNBMDdLKzRXOUU2NDRGMHpFNDZueEdibUtI?=
 =?utf-8?B?dzI3TkpKckFVL0QxazZTV0pERktISzhLOUdZZ1c0REdqV01zWmJZSXJ1d0F5?=
 =?utf-8?B?cGROVytXSzdMY3pueHV2am9jUFBuZisvMGE3YjE0S3hwaFJQM1FvczYvL1RL?=
 =?utf-8?B?dzJWcGJCZFFPV0lJQzlOekFlWFZUS243SW1wazRSSy9RNFVFekdkWm9iRCs5?=
 =?utf-8?B?K3hRamdsVkZGSFd3Q0Z5K3R0T3RuK3QxUzBBaUh4K2FTV01nZjZ5bHlIYkNY?=
 =?utf-8?B?eklYSWJmbEd0R1JDejRlZXhsQStzVUk4bUF1aWJVL3JoZWNuaS9rRjBCaURl?=
 =?utf-8?B?dG01TWdYYzFaQjhLdW9rOFVPeHNNMGdGRVNzNjBpNVlGTnpGa2pLaHlSR3hB?=
 =?utf-8?B?dXphQ0tuUXJzTmNrY0pUeWVsdlNHeVZHdGRVWnlZWVFrbnZKOVJhRXVpSEF2?=
 =?utf-8?B?QkNKa3NlWG8xVVJMdkluMURHbVpuQlB0QzlPOXlkWDhWanZrZk4vNStWM21p?=
 =?utf-8?B?NjlUa29qVVFBUVMzR0d1Znh3V24reFJzczkxbWxzV09OTis5S0I5NEdkMDV5?=
 =?utf-8?B?VVhvUFFTb0VzaHRibWw2RXR1K09YTVB0SVlOTVRsTytiQ3djMGU2b0h6L3NU?=
 =?utf-8?B?cUxROVYyMDZXd3oxVDlFbHdLM2NSamlxVjFRUVpUUzQ3L1dnRm9LWSticzlY?=
 =?utf-8?B?cXorV2p0a1JYbWNzZU1ROWZUMkNGbFc1OXZ1MFNBU1RiV2luOWVjMUVNRnNS?=
 =?utf-8?Q?LVYk=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <872E33BBEB810C489D2EEC92BD7BFEFA@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: dd6e413f-d1e4-47d6-afce-08ddb3ca7851
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2025 09:27:13.9722
 (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: 9Cg/sElPb8/TU2TfWR9wY43EhLCkTXInP4cclLJuxMC3IZjPjuq8ZQF0I6GKBIg7vCxFEPqwlvHHVQ08M4+Nnw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB6721

T24gMjAyNS82LzI1IDE2OjM2LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMjUuMDYuMjAyNSAw
ODo1MSwgQ2hlbiwgSmlxaWFuIHdyb3RlOg0KPj4gT24gMjAyNS82LzI0IDE4OjA4LCBKYW4gQmV1
bGljaCB3cm90ZToNCj4+PiBPbiAyNC4wNi4yMDI1IDExOjI5LCBDaGVuLCBKaXFpYW4gd3JvdGU6
DQo+Pj4+IE9uIDIwMjUvNi8yNCAxNjowNSwgSmFuIEJldWxpY2ggd3JvdGU6DQo+Pj4+PiBPbiAy
NC4wNi4yMDI1IDEwOjAyLCBDaGVuLCBKaXFpYW4gd3JvdGU6DQo+Pj4+Pj4gT24gMjAyNS82LzIw
IDE0OjM4LCBKYW4gQmV1bGljaCB3cm90ZToNCj4+Pj4+Pj4gT24gMTkuMDYuMjAyNSAwODozOSwg
Q2hlbiwgSmlxaWFuIHdyb3RlOg0KPj4+Pj4+Pj4gT24gMjAyNS82LzE4IDIyOjA1LCBKYW4gQmV1
bGljaCB3cm90ZToNCj4+Pj4+Pj4+PiBPbiAxMi4wNi4yMDI1IDExOjI5LCBKaXFpYW4gQ2hlbiB3
cm90ZToNCj4+Pj4+Pj4+Pj4gQEAgLTI5LDkgKzMwLDIyIEBAIHR5cGVkZWYgaW50IHZwY2lfcmVn
aXN0ZXJfaW5pdF90KHN0cnVjdCBwY2lfZGV2ICpkZXYpOw0KPj4+Pj4+Pj4+PiAgICovDQo+Pj4+
Pj4+Pj4+ICAjZGVmaW5lIFZQQ0lfTUFYX1ZJUlRfREVWICAgICAgIChQQ0lfU0xPVCh+MCkgKyAx
KQ0KPj4+Pj4+Pj4+PiAgDQo+Pj4+Pj4+Pj4+IC0jZGVmaW5lIFJFR0lTVEVSX1ZQQ0lfSU5JVCh4
LCBwKSAgICAgICAgICAgICAgICBcDQo+Pj4+Pj4+Pj4+IC0gIHN0YXRpYyB2cGNpX3JlZ2lzdGVy
X2luaXRfdCAqY29uc3QgeCMjX2VudHJ5ICBcDQo+Pj4+Pj4+Pj4+IC0gICAgICAgICAgICAgICBf
X3VzZWRfc2VjdGlvbigiLmRhdGEudnBjaS4iIHApID0gKHgpDQo+Pj4+Pj4+Pj4+ICsjZGVmaW5l
IFJFR0lTVEVSX1ZQQ0lfQ0FQQUJJTElUWShjYXAsIGZpbml0LCBmY2xlYW4sIGV4dCkgXA0KPj4+
Pj4+Pj4+PiArICAgIHN0YXRpYyBjb25zdCB2cGNpX2NhcGFiaWxpdHlfdCBmaW5pdCMjX3QgPSB7
IFwNCj4+Pj4+Pj4+Pj4gKyAgICAgICAgLmlkID0gKGNhcCksIFwNCj4+Pj4+Pj4+Pj4gKyAgICAg
ICAgLmluaXQgPSAoZmluaXQpLCBcDQo+Pj4+Pj4+Pj4+ICsgICAgICAgIC5jbGVhbnVwID0gKGZj
bGVhbiksIFwNCj4+Pj4+Pj4+Pj4gKyAgICAgICAgLmlzX2V4dCA9IChleHQpLCBcDQo+Pj4+Pj4+
Pj4+ICsgICAgfTsgXA0KPj4+Pj4+Pj4+PiArICAgIHN0YXRpYyBjb25zdCB2cGNpX2NhcGFiaWxp
dHlfdCAqY29uc3QgZmluaXQjI19lbnRyeSAgXA0KPj4+Pj4+Pj4+PiArICAgICAgICBfX3VzZWRf
c2VjdGlvbigiLmRhdGEucmVsLnJvLnZwY2kiKSA9ICZmaW5pdCMjX3QNCj4+Pj4+Pj4+Pg0KPj4+
Pj4+Pj4+IENvdWxkIHlvdSByZW1pbmQgbWUgd2h5IHRoZSBleHRyYSBsZXZlbCBvZiBpbmRpcmVj
dGlvbiBpcyBuZWNlc3NhcnkgaGVyZT8NCj4+Pj4+Pj4+PiBUaGF0IGlzLCB3aHkgY2FuJ3QgLmRh
dGEucmVsLnJvLnZwY2kgYmUgYW4gYXJyYXkgb2YgdnBjaV9jYXBhYmlsaXR5X3Q/DQo+Pj4+Pj4+
PiBZb3UgbWVhbiBJIHNob3VsZCBjaGFuZ2UgdG8gYmU6DQo+Pj4+Pj4+PiAjZGVmaW5lIFJFR0lT
VEVSX1ZQQ0lfQ0FQQUJJTElUWShjYXAsIGZpbml0LCBmY2xlYW4sIGV4dCkgXA0KPj4+Pj4+Pj4g
ICAgIHN0YXRpYyBjb25zdCB2cGNpX2NhcGFiaWxpdHlfdCBmaW5pdCMjX3QgXA0KPj4+Pj4+Pj4g
ICAgICAgICBfX3VzZWRfc2VjdGlvbigiLmRhdGEucmVsLnJvLnZwY2kiKSA9IHsgXA0KPj4+Pj4+
Pj4gICAgICAgICAuaWQgPSAoY2FwKSwgXA0KPj4+Pj4+Pj4gICAgICAgICAuaW5pdCA9IChmaW5p
dCksIFwNCj4+Pj4+Pj4+ICAgICAgICAgLmNsZWFudXAgPSAoZmNsZWFuKSwgXA0KPj4+Pj4+Pj4g
ICAgICAgICAuaXNfZXh0ID0gKGV4dCksIFwNCj4+Pj4+Pj4+ICAgICB9DQo+Pj4+Pj4+Pg0KPj4+
Pj4+Pj4gUmlnaHQ/DQo+Pj4+Pj4+DQo+Pj4+Pj4+IFllcywgc3ViamVjdCB0byB0aGUgZWFybGll
ciBjb21tZW50cyBvbiB0aGUgaWRlbnRpZmllciBjaG9pY2UuDQo+Pj4+Pj4gR290IGl0Lg0KPj4+
Pj4+IE9uZSBtb3JlIHF1ZXN0aW9uLCBpZiBjaGFuZ2UgdG8gYmUgdGhhdCwgdGhlbiBob3cgc2hv
dWxkIEkgbW9kaWZ5IHRoZSBkZWZpbml0aW9uIG9mIFZQQ0lfQVJSQVk/DQo+Pj4+Pj4gSXMgUE9J
TlRFUl9BTElHTiBzdGlsbCByaWdodD8NCj4+Pj4+DQo+Pj4+PiBZZXMuIFRoZSBzdHJ1Y3QgZG9l
c24ndCByZXF1aXJlIGJpZ2dlciBhbGlnbm1lbnQgYWZhaWNzLiAoSW4gZmFjdCBpbiBwcmluY2lw
bGUNCj4+Pj4+IG5vIGFsaWdubWVudCBzaG91bGQgbmVlZCBzcGVjaWZ5aW5nIHRoZXJlLCBleGNl
cHQgdGhhdCB0aGlzIHdvdWxkIHJlcXVpcmUNCj4+Pj4+IGtlZXBpbmcgdGhlIHNlY3Rpb24gc2Vw
YXJhdGUgaW4gdGhlIGZpbmFsIGltYWdlLiBXaGljaCBJIGRvbid0IHRoaW5rIHdlIHdhbnQuKQ0K
Pj4+Pj4NCj4+Pj4+PiBTaW5jZSBJIGVuY291bnRlcmVkIGVycm9ycyB0aGF0IHRoZSB2YWx1ZXMg
b2YgX19zdGFydF92cGNpX2FycmF5IGFyZSBub3QgcmlnaHQgd2hlbiBJIHVzZSB0aGVtIGluIHZw
Y2lfaW5pdF9jYXBhYmlsaXRpZXMoKS4NCj4+Pj4+DQo+Pj4+PiBEZXRhaWxzIHBsZWFzZS4NCj4+
Pj4gQWZ0ZXIgY2hhbmdpbmcgX19zdGFydF92cGNpX2FycmF5IHRvIGJlIHZwY2lfY2FwYWJpbGl0
eV90IGFycmF5LCBjb2RlcyB3aWxsIGJlIChtYXliZSBJIG1vZGlmaWVkIHdyb25nIHNvbWV3aGVy
ZSk6DQo+Pj4+DQo+Pj4+IGRpZmYgLS1naXQgYS94ZW4vZHJpdmVycy92cGNpL3ZwY2kuYyBiL3hl
bi9kcml2ZXJzL3ZwY2kvdnBjaS5jDQo+Pj4+IGluZGV4IGM1MWJiYjhhYmIxOS4uOWYyZjQzOGI0
ZmRkIDEwMDY0NA0KPj4+PiAtLS0gYS94ZW4vZHJpdmVycy92cGNpL3ZwY2kuYw0KPj4+PiArKysg
Yi94ZW4vZHJpdmVycy92cGNpL3ZwY2kuYw0KPj4+PiBAQCAtMzYsOCArMzYsOCBAQCBzdHJ1Y3Qg
dnBjaV9yZWdpc3RlciB7DQo+Pj4+ICB9Ow0KPj4+Pg0KPj4+PiAgI2lmZGVmIF9fWEVOX18NCj4+
Pj4gLWV4dGVybiBjb25zdCB2cGNpX2NhcGFiaWxpdHlfdCAqY29uc3QgX19zdGFydF92cGNpX2Fy
cmF5W107DQo+Pj4+IC1leHRlcm4gY29uc3QgdnBjaV9jYXBhYmlsaXR5X3QgKmNvbnN0IF9fZW5k
X3ZwY2lfYXJyYXlbXTsNCj4+Pj4gK2V4dGVybiB2cGNpX2NhcGFiaWxpdHlfdCBfX3N0YXJ0X3Zw
Y2lfYXJyYXlbXTsNCj4+Pj4gK2V4dGVybiB2cGNpX2NhcGFiaWxpdHlfdCBfX2VuZF92cGNpX2Fy
cmF5W107DQo+Pj4NCj4+PiBKdXN0IGZ5aTogWW91IGxvc3QgY29uc3QgaGVyZS4NCj4+Pg0KPj4+
PiBAQCAtMjU1LDcgKzI1NSw3IEBAIHN0YXRpYyBpbnQgdnBjaV9pbml0X2NhcGFiaWxpdGllcyhz
dHJ1Y3QgcGNpX2RldiAqcGRldikNCj4+Pj4gIHsNCj4+Pj4gICAgICBmb3IgKCB1bnNpZ25lZCBp
bnQgaSA9IDA7IGkgPCBOVU1fVlBDSV9JTklUOyBpKysgKQ0KPj4+PiAgICAgIHsNCj4+Pj4gLSAg
ICAgICAgY29uc3QgdnBjaV9jYXBhYmlsaXR5X3QgKmNhcGFiaWxpdHkgPSBfX3N0YXJ0X3ZwY2lf
YXJyYXlbaV07DQo+Pj4+ICsgICAgICAgIGNvbnN0IHZwY2lfY2FwYWJpbGl0eV90ICpjYXBhYmls
aXR5ID0gJl9fc3RhcnRfdnBjaV9hcnJheVtpXTsNCj4+Pj4gICAgICAgICAgY29uc3QgdW5zaWdu
ZWQgaW50IGNhcCA9IGNhcGFiaWxpdHktPmlkOw0KPj4+PiAgICAgICAgICBjb25zdCBib29sIGlz
X2V4dCA9IGNhcGFiaWxpdHktPmlzX2V4dDsNCj4+Pj4gICAgICAgICAgaW50IHJjOw0KPj4+PiBk
aWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUveGVuL3ZwY2kuaCBiL3hlbi9pbmNsdWRlL3hlbi92cGNp
LmgNCj4+Pj4gaW5kZXggZjRlYzFjMjU5MjJkLi43Nzc1MGRkNDEzMWEgMTAwNjQ0DQo+Pj4+IC0t
LSBhL3hlbi9pbmNsdWRlL3hlbi92cGNpLmgNCj4+Pj4gKysrIGIveGVuL2luY2x1ZGUveGVuL3Zw
Y2kuaA0KPj4+PiBAQCAtMzEsMTQgKzMxLDEzIEBAIHR5cGVkZWYgc3RydWN0IHsNCj4+Pj4gICNk
ZWZpbmUgVlBDSV9NQVhfVklSVF9ERVYgICAgICAgKFBDSV9TTE9UKH4wKSArIDEpDQo+Pj4+DQo+
Pj4+ICAjZGVmaW5lIFJFR0lTVEVSX1ZQQ0lfQ0FQQUJJTElUWShjYXAsIGZpbml0LCBmY2xlYW4s
IGV4dCkgXA0KPj4+PiAtICAgIHN0YXRpYyBjb25zdCB2cGNpX2NhcGFiaWxpdHlfdCBmaW5pdCMj
X3QgPSB7IFwNCj4+Pj4gKyAgICBzdGF0aWMgdnBjaV9jYXBhYmlsaXR5X3QgZmluaXQjI19lbnRy
eSBcDQo+Pj4+ICsgICAgICAgIF9fdXNlZF9zZWN0aW9uKCIuZGF0YS5yZWwucm8udnBjaSIpID0g
eyBcDQo+Pj4+ICAgICAgICAgIC5pZCA9IChjYXApLCBcDQo+Pj4+ICAgICAgICAgIC5pbml0ID0g
KGZpbml0KSwgXA0KPj4+PiAgICAgICAgICAuY2xlYW51cCA9IChmY2xlYW4pLCBcDQo+Pj4+ICAg
ICAgICAgIC5pc19leHQgPSAoZXh0KSwgXA0KPj4+PiAtICAgIH07IFwNCj4+Pj4gLSAgICBzdGF0
aWMgY29uc3QgdnBjaV9jYXBhYmlsaXR5X3QgKmNvbnN0IGZpbml0IyNfZW50cnkgIFwNCj4+Pj4g
LSAgICAgICAgX191c2VkX3NlY3Rpb24oIi5kYXRhLnJlbC5yby52cGNpIikgPSAmZmluaXQjI190
DQo+Pj4+ICsgICAgfQ0KPj4+Pg0KPj4+PiAgI2RlZmluZSBSRUdJU1RFUl9WUENJX0NBUChjYXAs
IGZpbml0LCBmY2xlYW4pIFwNCj4+Pj4gICAgICBSRUdJU1RFUl9WUENJX0NBUEFCSUxJVFkoY2Fw
LCBmaW5pdCwgZmNsZWFuLCBmYWxzZSkNCj4+Pj4NCj4+Pj4gSSBwcmludCB0aGUgdmFsdWUgb2Yg
TlVNX1ZQQ0lfSU5JVCwgaXQgaXMgYSBzdHJhbmdlIG51bWJlciAoNjE0ODkxNDY5MTIzNjUxNzIw
OSkuDQo+Pj4NCj4+PiBXaGF0IGFyZSB0aGUgYWRkcmVzc2VzIG9mIHRoZSB0d28gc3ltYm9scyBf
X3N0YXJ0X3ZwY2lfYXJyYXkgYW5kIF9fZW5kX3ZwY2lfYXJyYXk/DQo+PiBfX2VuZF92cGNpX2Fy
cmF5IGlzIDB4ZmZmZjgyZDA0MDQyNTFiOA0KPj4gX19zdGFydF92cGNpX2FycmF5IGlzIDB4ZmZm
ZjgyZDA0MDQyNTE2MA0KPj4gTlVNX1ZQQ0lfSU5JVCBpcyAweDU1NTU1NTU1NTU1NTU1NTkNCj4+
IHNpemVvZih2cGNpX2NhcGFiaWxpdHlfdCkgaXMgMHgxOA0KPiANCj4gT2gsIG9mIGNvdXJzZSAt
IHRoZXJlJ3MgYSBwc0FCSSBwZWN1bGlhcml0eSB0aGF0IHlvdSBydW4gaW50byBoZXJlOiBBZ2dy
ZWdhdGVzDQo+IGxhcmdlciB0aGFuIDggYnl0ZXMgYXJlIHJlcXVpcmVkIHRvIGhhdmUgMTYtYnl0
ZSBhbGlnbm1lbnQuIEhlbmNlIHdoaWxlDQo+IHNpemVvZigpID09IDB4MTggYW5kIF9fYWxpZ25v
ZigpID09IDgsIHRoZSBzZWN0aW9uIGNvbnRyaWJ1dGlvbnMgc3RpbGwgYXJlDQo+IGFjY29tcGFu
aWVkIGJ5ICIuYWxpZ24gMTYiLCBhbmQgdGh1cyByZXNwZWN0aXZlIHBhZGRpbmcgaXMgaW5zZXJ0
ZWQgYnkNCj4gYXNzZW1ibGVyIGFuZCBsaW5rZXIuIElPVyB5b3UgZW5kIHVwIHdpdGggdHdvIDMy
LWJ5dGUgZW50cmllcyBhbmQgYSB0cmFpbGluZw0KPiAyNC1ieXRlIG9uZS4gVGhlIGVhc2llc3Qg
KGFuZCBsZWFzdCBwcm9ibGVtYXRpYyBnb2luZyBmb3J3YXJkKSBhcHByb2FjaCB0bw0KPiBkZWFs
IHdpdGggdGhhdCBpcyBwcm9iYWJseSBnb2luZyB0byBiZSB0byBhZGQgX19hbGlnbmVkKDE2KSB0
byB0aGUgc3RydWN0DQo+IGRlY2wuIChXaGV0aGVyIHRvIGxpbWl0IHRoaXMgdG8ganVzdCB4ODYg
SSdtIG5vdCBzdXJlOiBXaGlsZSBvdGhlciBwc0FCSS1zIG1heQ0KPiBiZSBkaWZmZXJlbnQgaW4g
dGhpcyByZWdhcmQsIHdlIG1heSB3YW50IHRvIGJlIG9uIHRoZSBzYWZlIHNpZGUuKQ0KVGhhbmtz
IGZvciB5b3UgZGV0YWlsZWQgZXhwbGFuYXRpb24uDQpJZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5
LCBJIG5lZWQgdG8gY2hhbmdlIHRoZSBkZWZpbml0aW9uIG9mIHZwY2lfY2FwYWJpbGl0eV90IHRv
IGJlOg0KDQp0eXBlZGVmIHN0cnVjdCB7DQogICAgdW5zaWduZWQgaW50IGlkOw0KICAgIGJvb2wg
aXNfZXh0Ow0KICAgIGludCAoKiBpbml0KShjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldik7DQog
ICAgaW50ICgqIGNsZWFudXApKGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZGV2KTsNCn0NCiNpZmRl
ZiBDT05GSUdfWDg2DQpfX2FsaWduZWQoMTYpDQojZW5kaWYNCnZwY2lfY2FwYWJpbGl0eV90Ow0K
DQo+IA0KPiBIb3dldmVyLCB0aGVyZSBsb29rcyB0byBiZSBhbm90aGVyIChnY2MpIGFub21hbHk6
IEJ5IGRlZmF1bHQsIGhhbGYtd2F5IHJlY2VudA0KPiBnY2MgYWxpZ25zIHRoaXMga2luZCBvZiBv
YmplY3QgZXZlbiB0byAzMi1ieXRlIGJvdW5kYXJpZXMsIGR1ZSB0byBkZWZhdWx0aW5nDQo+IHRv
IC1tYWxpZ24tZGF0YT1jb21wYXQuIFdlIHdpbGwgd2FudCB0byBjb25zaWRlciB0byB1c2UgLW1h
bGlnbi1kYXRhPWFiaQ0KPiBpbnN0ZWFkIChzdXBwb3J0ZWQgYnkgZ2NjNSBhbmQgbmV3ZXIpLiBJ
J20gaW4gdGhlIHByb2Nlc3Mgb2YgcHJlcGFyaW5nIGEgcGF0Y2gNCj4gdG8gcHJvcG9zZSB0aGlz
IG1vcmUgZm9ybWFsbHkuDQo+IA0KPiBKYW4NCg0KLS0gDQpCZXN0IHJlZ2FyZHMsDQpKaXFpYW4g
Q2hlbi4NCg==


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 09:47:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 09:47:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024573.1400398 (Exim 4.92)
	(envelope-from )
	id 1uUMjI-00045r-7k; Wed, 25 Jun 2025 09:47:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024573.1400398; Wed, 25 Jun 2025 09: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 1uUMjI-00045k-4o; Wed, 25 Jun 2025 09:47:44 +0000
Received: by outflank-mailman (input) for mailman id 1024573;
 Wed, 25 Jun 2025 09:47: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 1uUMjG-00045e-3u
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 09:47:42 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20618.outbound.protection.outlook.com
 [2a01:111:f403:2418::618])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6dc682d6-51a9-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 11:47:39 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by DS4PR12MB9771.namprd12.prod.outlook.com (2603:10b6:8:29b::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.25; Wed, 25 Jun
 2025 09:47:33 +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.8835.027; Wed, 25 Jun 2025
 09:47: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: 6dc682d6-51a9-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=qG1u5Dm0/BbUuBMzfotPeTpl0+fjZ17OsmcTIHW9HvC/tb53nD4qU0z4TAbdlSJavjOiPtIrZVhjh3+DRdKPYmVTGlmBWwMGTuMdH3T0wo95iPWRSaXEnRL8OJ7X8jTtMMPQNc6ceqFMy3L5u2CVcwq5PvOGFbDdOZoyi1V07WYK0qXG+FogcNegXnjhG0i8eN6kTX9mjtdceDGp8JmIUjmOvwTP9MFye3nHfk7Qzrjx4/HF2AxGTfCNnZ0ajGTbIoh0e/RLkeKI/Iiuz6hjZy81/PPoeFqX29Rqx9GgJhTLFJKqCxJ/jOB6TeVDm2eQcORkJMTPIoW5wMWkxL5eQQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=CprJL6e30ubqpLtgzxrXcJF5KCl+aapxkW/fPW/kgtg=;
 b=MVhqiNjyM7F/TQEz0RPoDmgjG925F5wRPzhV/BQK4Um7CXm5C2zgBtey3Kl1vzi58My6aaHBx5g/lAxh9TJ1+bBiSi6j+uNhZQRR6tlZ0WeNRx2vwfRJnu2kyvwrvt2Ks9aIept/1SEsHi3v8i84ULesR/Tyf3Kkh87uCVXZOr8PqCUrHn6rjY44ERmnUU5UyhJJe34MzjWAeks9iDF0K8iKyH2FnLhbB8Bmd0YpKc4WxaMsb9loP+i3SZdCEyf0aYXSV9TLjGcRlDTEZ6w8Rg3VqLRGORhKAbaggmpjXYd7yzJ1rQEAR5u5k4bYdRAx1TR36PYyMUAl+I6Gg0elrw==
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=CprJL6e30ubqpLtgzxrXcJF5KCl+aapxkW/fPW/kgtg=;
 b=00PV7O4a2KBauLT+ppubfTkBTYFJM7T6pdG0xeKOJa7ec837i+j4W9Rx5/tIbgtqW6/O5LEbGFcMMvxLNFZk/4f41oVP2CPCvwfanafW/P7yUBObrXBIsv90Y2KSO1wLBcIrraVrlPI9QD6cwbdBMhAvDJI2PDlX/zS1uFStUOU=
From: "Chen, Jiqian" 
To: Jan Beulich 
CC: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= ,
	"xen-devel@lists.xenproject.org" , "Huang,
 Ray" , "Chen, Jiqian" 
Subject: Re: [PATCH v6 7/8] vpci/msi: Free MSI resources when init_msi() fails
Thread-Topic: [PATCH v6 7/8] vpci/msi: Free MSI resources when init_msi()
 fails
Thread-Index:
 AQHb23yeMT8YFCMR3kaLDqQP1+DTK7QJCD4AgAme+gD//4QlAIAB4iSA//+e0YCAAIz0gA==
Date: Wed, 25 Jun 2025 09:47:33 +0000
Message-ID:
 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-8-Jiqian.Chen@amd.com>
 <773c448a-d814-458f-ad83-e9740e724408@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.8835.025)
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_|DS4PR12MB9771:EE_
x-ms-office365-filtering-correlation-id: aa544dfc-aad5-4eb5-da3d-08ddb3cd4f50
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?VE9Td1Z1L0lUWDV5NjQwazNHUVZVdnZTV2lUR3Myd1F4NHNXcnZQQXNNT2d6?=
 =?utf-8?B?VkpKWVFEdWVqbUc1Z2prNG9PcFgvTUJpU3hwejd0aEJzRCttamN3R1RYQjdk?=
 =?utf-8?B?T3BlS0FVTU5rbUR6U3RkREhBRm5jK1hrVisvaGI2aERCUGxRaGFLZllLQ1Jt?=
 =?utf-8?B?NDB0THl5UVV6ajM4NnlRcFJwNlVneHZkQm5UVTJUTmlTUmcycEs4NjdRZXlz?=
 =?utf-8?B?eDF6bDJ3TG1VL2hZbU4rZkdYOVFkV25RQmlmd1pQYWRmVzZYVnlkS2RNbkt6?=
 =?utf-8?B?UTdicVlzY1VreE9RN2d3RC8zVS9mUkY1OEI3ZjNYR0ppODU0aWo5SWNnZFVx?=
 =?utf-8?B?blNRaCtRai9lTU5qbGpsQ2U1NXNmMXRodWJLSnprWXMxZFNZMnV2dVYvRlI0?=
 =?utf-8?B?S1JadXlQTDczUjRNbkZaOXdYSnRJS3J6bGJlVXdIZEhLVkhGSnNHTFpMYU0y?=
 =?utf-8?B?K20waWc3MnpubFRTTXhRL04zcTV6bHEyZ3RVNFFSM25wS0J4MVpoNS8rOWxF?=
 =?utf-8?B?c1YvaDdadVJ0UGtJcDVvN0VJRHRRODlrZTZMNnhSSG9NbXlHVTNZMGFSNU9m?=
 =?utf-8?B?ZytJUHJuMkxFazNVbW9pdk1IRFdIZm5LU2dEcVkyckE3TVViYVVhSmtFbHFh?=
 =?utf-8?B?RXhLNUtmZ012aFFEK2s1aEpUb2N2STZBMXl1MXFlY1ZKbTdoQmpJOHprWDQ0?=
 =?utf-8?B?MVZ1Q0piSU00dUJRMWowL1B0Sy91NngvTjZ4MFRFUElYTmhuVTdCa3JqUWRV?=
 =?utf-8?B?ZEVxVmZkZThCWlNvRDhLRDNVbGdpZ1l1NWlnK3prQURBMGxlR1JDYW45MWZU?=
 =?utf-8?B?ZjB6UWduUjZkek5rdHNmUXA2MGY4NVFWcFVZY1B4emRqZ3RnOHZZVDFuYnNN?=
 =?utf-8?B?UDh2b2dPVkJsUXlmUVlReFlUTml4U0dpUm5RaUVjemVaYlBZY0wxYW5jeDlu?=
 =?utf-8?B?YzZuOWxtZ1RkOTNvMVdJV1lHRUNhd3VwZ2V2Q2FweFArWjlpK3pzRGMxK0Zk?=
 =?utf-8?B?NkZGdmx1V2lIeWNsWjdwalo1YlVyR0pnZGwxano0R2NoQW52L3p0M09jamo2?=
 =?utf-8?B?WnNpTGlNR1J4UHdYS2pLS3JMejRMRW5OVndpc3RULzQwZVczN01JcnNOdG4w?=
 =?utf-8?B?N25IREJiR1FXWjB4ZGRsSW1aaVc4cC9zd1lENmxsN1RBUVdqcXI1bTk5YlFS?=
 =?utf-8?B?dmpDd3NuTmNTTDRYMGNoOXZVdmRDdGdJQ0VHN3JVYzFCWmRnMUVBV29ZdStq?=
 =?utf-8?B?UjZEVmtXRElQMTNMTy9DdDhlWVl4Qjhza2VuM0wyZmJ1dVU4Ym5iRmE3QWl0?=
 =?utf-8?B?UzBkaXFDY2lHcFJ4bmsvdVNNN0k2aDhQWDBwbHE5TW9leDdYbFcrcjVRZ1Zs?=
 =?utf-8?B?dlI2MDZqeFpobGh0Ukl5TUlKNm9qZE5SVDdJTDdXMXdJSWNuaCtWVk5TZmdZ?=
 =?utf-8?B?anp4T3BjYVE3a1pMQXBJT20rQjZveHh4K051WXB5SEVxWFpUa2JndFNmVnB2?=
 =?utf-8?B?M01pRVdlZDA2Qkw3R3JKdEI4ZTdVMlBqU2FMZmRPdTVsemp4V2NUZWdMQkFv?=
 =?utf-8?B?clpURW5Tb2U0N3RuaExyNTdIeXFlRnNPMU4yVG8wSEhadkd5dEIrU2tDZTFJ?=
 =?utf-8?B?eHl0VjJ1U2ZvOUU2Y0ZzSmFoNTVPT3FPS0x4bytGVytsZTl6SldnVzFCVWt6?=
 =?utf-8?B?cE83cEFyQjA4ZlFFS2FxRWxpeHJ1Q2pPWldScnF1TDZNOU95eGhRVGRDVzcy?=
 =?utf-8?B?aE90UFBMcmU4MkRqblhvRmEwUnRCbkNZcm53NGVTNmZwQ21mUEtIdzBtMWZC?=
 =?utf-8?B?RS9UVW1hOUttU0pQcXhQVkNRSU8zazVmdkJ0dHkzY0Vxcytnc2VuSmF1UjMv?=
 =?utf-8?B?S1R1ZEM4dUs5blFZc3FGYUZZOWxvN0JmR2NhcmZVK01rVlRtazFuTkVIVE9U?=
 =?utf-8?B?cEI5QTczNEhjOURTR2F4cVdnMGoyYzNqcCtBVDBFalVEWkkwU2lWZWgvZnFt?=
 =?utf-8?Q?QJLlqgu3sD9+Gtd7ATNjvxue7lkmiw=3D?=
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?V2RLSHR6WmZKdWdwMlhxcDR0Tk9xL0QveWthd1NRK0VESG9aU2NHcURVcWoy?=
 =?utf-8?B?MXQrNDhCMVRVcGI0cTdhWUJNS1lSS0xFeVVIZjRkU2JabTJFd1B4WVdoeGhm?=
 =?utf-8?B?WUZPTTNTMjhtTGtFb294bEdyVCs1ajlxNG9mQVdoMDlxYjdwOEJRV09DeE1B?=
 =?utf-8?B?dHVETlFWZVJmQTFJcVRlZ05GM1RwWTZxTnJSR2hzQkliTThZL2MzNXRKUS8w?=
 =?utf-8?B?bVEwUGYrTmUwanFDMW9tOENSWkNFSVJ1V1FmTzF3c3ZjMVZjcFNWenBOeDNS?=
 =?utf-8?B?ZS9UZlg0Z3NCRWlxVmN4VEZXLzVZeFk3UWJiT1dUazl4WnlaeHpZL0ZHREZv?=
 =?utf-8?B?dHhOM2dPU3plRS9BNnNpdUZOMFRYYWhiWGc4bjlFbFlKOEhVdFN4WVRPbGlV?=
 =?utf-8?B?SjFJS3pISDBEaDgwZnMvOFhaU3h4UVJGanhZeW5NWm9pRGFxNmNlNVJ3cmZ6?=
 =?utf-8?B?dk9LRndMeS9URTd2dXZXNkJSRGFsT3JLNGFkZlBUTHJmaXdOcXdJUlNZd0F0?=
 =?utf-8?B?Vlo2N29KbnBXQnMrejBGNXM0QnZhUjhvalJ3RkxkRzY3Z2g3YXp4ODkrZE5T?=
 =?utf-8?B?ejRvb0xiVVk0U3diSXRUcEdrRGlmWS9uNTloQ2lldjdmSURKc3BocWYzRkM2?=
 =?utf-8?B?OG9wVGtQNDhQMDdnNFpmblU2QWI1K3U3SXoxNkphNS91YXoyeHV5ZTdNN1dB?=
 =?utf-8?B?Sy9INjhGeVNyekZFVTJZemdWczllOVE2UTRoTDBWMnV5Um9DVXlURWx4bHZ1?=
 =?utf-8?B?aC9vOFJQV1piQWcyTUZlOUZXK2pqMnc1UjlSVlVXOUxNL2U4N21ta2VrQlo4?=
 =?utf-8?B?ZmRMbkVJUG5oT0M1OXd0NmVTcmxaZDVxMnNoTWVTYWxsUVMrMjRSd3dLUnRS?=
 =?utf-8?B?cFJFQjlMeC95TEdHOGEzdW8wS0pCNnl0L0RQdzJIVHlhV1Z1cFpYOGs3dFlr?=
 =?utf-8?B?T2xFSkFrblRnUStQYW9ReEgxME5TQnBZdmpha0s3UXRhMHVZQjBZUU82SlFP?=
 =?utf-8?B?N21RVTZhWGtQT285VnpHVjJ3MmxiR21tdDMzUFY2eitCZDBHeU9xUnNaQ2di?=
 =?utf-8?B?TXFKSkx2L0ZVUkg3MXlsQld0T1Bmcm1pb0dMbkdlZWN4a3V4VFo4ZDF1ci9R?=
 =?utf-8?B?TDB1RjlaTzI0aFhmckpoU1hKazhnV0pwd24xVGxmRFRRZUpjMU1GTkFZSC9O?=
 =?utf-8?B?NmJNSGxjdjNjM29pVklFVjlRbWVpZlpkK09mNjRkeDl0ZndZRWUybUFiSjZx?=
 =?utf-8?B?aThTN0NoMHk3SXB4RlVtQ1h4eXJ1S2pTZlg1Y09kNk5LR0JUSVRtMnBsRzJp?=
 =?utf-8?B?anBqV050dVZOdGdHZk54NUVGeDhxa3JtVjNuWmVuSE5SdXNyT291M1hieU1v?=
 =?utf-8?B?c2xzSWcrUjRqZ0NsRmhCK1RXUUQ2TGk3dk1DSjFWMSsrUDc3cGl3ZUsyRUdG?=
 =?utf-8?B?a3Jna2o3SG5MUkhHdERsa2hvS092azE0VlNZQm9yYjBUR3ZIZmp2OUJJbDM3?=
 =?utf-8?B?NGFkb3pOM01rb2xHeS9MOXJOVDZ1SWlBWFBIVjdWallxWm1NRnB6ZHB3Ymho?=
 =?utf-8?B?blJlRmF1NGdPRUJxQ3I2RG52TXVBbVZyazBIWUxlbUZ6MUFmVkVyTS9ObGpM?=
 =?utf-8?B?WWQvNTJPVWw2KzJCeHRTZDNQRTlEQVpDR0QzSzFqbUZjN204Q3d0djBLVjNL?=
 =?utf-8?B?OFV1ZjRQUmN5K3g2Y1cwQU5vSUM4WFF0S0tUVjFwZWhqUkZmRjJlOVhxbE0r?=
 =?utf-8?B?blRnTENjdEtydnM1QVNKMTd3UzNkY09CemVoTXVqQ1F6dVAvYWJjVGJ0WUds?=
 =?utf-8?B?MzhZWUJjSmhYVmo3ZFh4YytxMzJINFNGK3ZTcmI3UVM3Q3puRnM1clJJZWV0?=
 =?utf-8?B?RHRVWE8yTVNVRGZ3OFF0OUh1WTVDN1ZNV0N6cFI3bEpWdEJNMko2QUljY0dS?=
 =?utf-8?B?Zm9oc1kwbGdCcGRBL2lqK1BUbUhQSnVXN29IRXNyTHI5U0R0RkFiSDU0V3lx?=
 =?utf-8?B?YVZKWWpCYWt1Z21jOFFOTlNvVGw4cHdCZVI1Snl6UWdwTGF6YjhJM0pveU9y?=
 =?utf-8?B?Nm1ST3kyRU1BOFNEL1AxOGJtQmxEdlJPL2lGMWhwdGFpWTVMaGFTaXlYZysw?=
 =?utf-8?Q?/erI=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <3532033AEC47A64BA97956E2B65EA74D@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: aa544dfc-aad5-4eb5-da3d-08ddb3cd4f50
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2025 09:47:33.6709
 (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: 3APFK8600uUUdxQ1r8GuD3Kvi09SUl7otAL5tNxAggD4uND+3Fp4vxZS+ZKSnfn0wQ8jbNiMxXHbCUz9odNcKA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS4PR12MB9771

T24gMjAyNS82LzI1IDE3OjE1LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMjUuMDYuMjAyNSAw
OToxNiwgQ2hlbiwgSmlxaWFuIHdyb3RlOg0KPj4gT24gMjAyNS82LzI0IDE4OjE3LCBKYW4gQmV1
bGljaCB3cm90ZToNCj4+PiBPbiAyNC4wNi4yMDI1IDExOjQ5LCBDaGVuLCBKaXFpYW4gd3JvdGU6
DQo+Pj4+IE9uIDIwMjUvNi8xOCAyMjo0NSwgSmFuIEJldWxpY2ggd3JvdGU6DQo+Pj4+PiBPbiAx
Mi4wNi4yMDI1IDExOjI5LCBKaXFpYW4gQ2hlbiB3cm90ZToNCj4+Pj4+PiAtLS0gYS94ZW4vZHJp
dmVycy92cGNpL21zaS5jDQo+Pj4+Pj4gKysrIGIveGVuL2RyaXZlcnMvdnBjaS9tc2kuYw0KPj4+
Pj4+IEBAIC0xOTMsNiArMTkzLDMzIEBAIHN0YXRpYyB2b2lkIGNmX2NoZWNrIG1hc2tfd3JpdGUo
DQo+Pj4+Pj4gICAgICBtc2ktPm1hc2sgPSB2YWw7DQo+Pj4+Pj4gIH0NCj4+Pj4+PiAgDQo+Pj4+
Pj4gK3N0YXRpYyBpbnQgY2ZfY2hlY2sgY2xlYW51cF9tc2koc3RydWN0IHBjaV9kZXYgKnBkZXYp
DQo+Pj4+Pj4gK3sNCj4+Pj4+PiArICAgIGludCByYzsNCj4+Pj4+PiArICAgIHVuc2lnbmVkIGlu
dCBlbmQsIHNpemU7DQo+Pj4+Pj4gKyAgICBzdHJ1Y3QgdnBjaSAqdnBjaSA9IHBkZXYtPnZwY2k7
DQo+Pj4+Pj4gKyAgICBjb25zdCB1bnNpZ25lZCBpbnQgbXNpX3BvcyA9IHBkZXYtPm1zaV9wb3M7
DQo+Pj4+Pj4gKyAgICBjb25zdCB1bnNpZ25lZCBpbnQgY3RybCA9IG1zaV9jb250cm9sX3JlZyht
c2lfcG9zKTsNCj4+Pj4+PiArDQo+Pj4+Pj4gKyAgICBpZiAoICFtc2lfcG9zIHx8ICF2cGNpLT5t
c2kgKQ0KPj4+Pj4+ICsgICAgICAgIHJldHVybiAwOw0KPj4+Pj4+ICsNCj4+Pj4+PiArICAgIGlm
ICggdnBjaS0+bXNpLT5tYXNraW5nICkNCj4+Pj4+PiArICAgICAgICBlbmQgPSBtc2lfcGVuZGlu
Z19iaXRzX3JlZyhtc2lfcG9zLCB2cGNpLT5tc2ktPmFkZHJlc3M2NCk7DQo+Pj4+Pj4gKyAgICBl
bHNlDQo+Pj4+Pj4gKyAgICAgICAgZW5kID0gbXNpX21hc2tfYml0c19yZWcobXNpX3BvcywgdnBj
aS0+bXNpLT5hZGRyZXNzNjQpIC0gMjsNCj4+Pj4+PiArDQo+Pj4+Pj4gKyAgICBzaXplID0gZW5k
IC0gY3RybDsNCj4+Pj4+PiArDQo+Pj4+Pj4gKyAgICByYyA9IHZwY2lfcmVtb3ZlX3JlZ2lzdGVy
cyh2cGNpLCBjdHJsLCBzaXplKTsNCj4+Pj4+PiArICAgIGlmICggcmMgKQ0KPj4+Pj4+ICsgICAg
ICAgIHJldHVybiByYzsNCj4+Pj4+DQo+Pj4+PiBUaGlzIGlzIGEgZGlmZmljdWx0IG9uZTogSXQn
cyBub3QgYSBnb29kIGlkZWEgdG8gc2ltcGx5IHJldHVybiBoZXJlLCB5ZXQNCj4+Pj4+IGF0IHRo
ZSBzYW1lIHRpbWUgdGhlIGhhbmRsaW5nIG9mIHRoZSByZWdpc3RlciB3ZSdyZSB1bmFibGUgdG8g
cmVtb3ZlIG1heQ0KPj4+Pj4gc3RpbGwgcmVxdWlyZSBlLmcuIC4uLg0KPj4+Pj4NCj4+Pj4+PiAr
ICAgIFhGUkVFKHZwY2ktPm1zaSk7DQo+Pj4+Pg0KPj4+Pj4gLi4uIHRoaXMuIFRoZXJlIG1heSB0
aGVyZWZvcmUgYmUgbW9yZSB3b3JrIHJlcXVpcmVkLCBzdWNoIHRoYXQgaW4gdGhlDQo+Pj4+PiBl
bmQgd2UncmUgYWJsZSB0byAuLi4NCj4+Pj4+DQo+Pj4+Pj4gKyAgICByZXR1cm4gdnBjaV9hZGRf
cmVnaXN0ZXIocGRldi0+dnBjaSwgdnBjaV9od19yZWFkMTYsIE5VTEwsIGN0cmwsIDIsIE5VTEwp
Ow0KPj4+Pj4NCj4+Pj4+IC4uLiB0cnkgdGhpcyBhdCBsZWFzdCBvbiBhIGJlc3QgZWZmb3J0IGJh
c2lzLg0KPj4+Pj4NCj4+Pj4+IE1vcmUgZ2VuZXJhbGx5OiBJIGRvbid0IHRoaW5rIGZhaWx1cmUg
aGVyZSAob3IgaW4gb3RoZXIgLmNsZWFudXAgaG9vaw0KPj4+Pj4gZnVuY3Rpb25zKSBtYXkgZ28g
ZW50aXJlbHkgc2lsZW50bHkuDQo+Pj4+IERvZXMgYmVsb3cgbWVldCB5b3VyIG1vZGlmaWNhdGlv
biBleHBlY3RhdGlvbnM/DQo+Pj4NCj4+PiBOb3Qgc3VyZSwgc29ycnkuIEJ5ICJtb3JlIiBJIHJl
YWxseSBtZWFudCAibW9yZSIgKHdoaWNoIG1heSBqdXN0IGJlIGNvZGUNCj4+PiBhdWRpdGluZywg
cmVzdWx0cyBvZiB3aGljaCB3b3VsZCBuZWVkIHdyaXRpbmcgZG93biwgYnV0IHdoaWNoIG1heSBh
bHNvDQo+Pj4gaW52b2x2ZSBmdXJ0aGVyIGNvZGUgY2hhbmdlczsgc2VlIGJlbG93KS4NCj4+Pg0K
Pj4+PiAgICAgcmMgPSB2cGNpX3JlbW92ZV9yZWdpc3RlcnModnBjaSwgY3RybCwgc2l6ZSk7DQo+
Pj4+ICAgICBpZiAoIHJjICkNCj4+Pj4gICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAiJXBkICVw
cDogcmVtb3ZlIG1zaSBoYW5kbGVycyBmYWlsIHJjPSVkXG4iLA0KPj4+PiAgICAgICAgICAgICAg
ICBwZGV2LT5kb21haW4sICZwZGV2LT5zYmRmLCByYyk7DQo+Pj4+DQo+Pj4+ICAgICBYRlJFRSh2
cGNpLT5tc2kpOw0KPj4+DQo+Pj4gQXMgSSB0cmllZCB0byBpbmRpY2F0ZSBpbiBteSBlYXJsaWVy
IHJlcGx5LCB0aGUgZnJlZWluZyBvZiB0aGlzIHN0cnVjdCBpcw0KPj4+IHNhZmUgb25seSBpZiB0
aGUgZmFpbHVyZSBhYm92ZSB3b3VsZCBub3QgbGVhdmUgYW55IHJlZ2lzdGVyIGhhbmRsZXJzIGlu
DQo+Pj4gcGxhY2Ugd2hpY2ggc3RpbGwgKHdpdGhvdXQgYXBwcm9wcmlhdGUgY2hlY2tpbmcpIHVz
ZSB0aGlzIHN0cnVjdC4NCj4+IEhtbSwgYnV0IGFsbCBoYW5kbGVycyBhZGRlZCBpbiBpbml0X21z
aSgpIHVzZSB0aGlzIHN0cnVjdC4NCj4+IFNvIGl0IGRvZXNuJ3QgZXhpc3QgdGhlIGNhc2UgdGhh
dCB3aGVuIGFib3ZlIHVuYWJsZSB0byByZW1vdmUgYWxsIGhhbmRsZXJzIGFuZCBzdGlsbCByZXF1
aXJlIHhmcmVlIHRoaXMgc3RydWN0Lg0KPiANCj4gV2VsbCwgaW4gdGhlIGVuZCB5b3Ugc2F5IGlu
IGRpZmZlcmVudCB3b3JkcyB3aGF0IEkgZGlkIHNheSwgaWYgSSB1bmRlcnN0YW5kDQo+IGNvcnJl
Y3RseS4gVGhlcmUgYXJlIHNldmVyYWwgb3B0aW9ucyBob3cgdG8gZGVhbCB3aXRoIHRoYXQuIE9u
ZSBtaWdodCBiZSB0bw0KPiBoYXZlIHRob3NlIGhhbmRsZXJzIHJlY29nbml6ZSB0aGUgbGFjayBv
ZiB0aGF0IHBvaW50ZXIsIGFuZCBiZWhhdmUgbGlrZSAuLi4NCj4gDQo+Pj4+ICAgICAvKg0KPj4+
PiAgICAgICogVGhlIGRyaXZlciBtYXkgbm90IHRyYXZlcnNlIHRoZSBjYXBhYmlsaXR5IGxpc3Qg
YW5kIHRoaW5rIGRldmljZQ0KPj4+PiAgICAgICogc3VwcG9ydHMgTVNJIGJ5IGRlZmF1bHQuIFNv
IGhlcmUgbGV0IHRoZSBjb250cm9sIHJlZ2lzdGVyIG9mIE1TSQ0KPj4+PiAgICAgICogYmUgUmVh
ZC1Pbmx5IGlzIHRvIGVuc3VyZSBNU0kgZGlzYWJsZWQuDQo+Pj4+ICAgICAgKi8NCj4+Pj4gICAg
IHJjID0gdnBjaV9hZGRfcmVnaXN0ZXIodnBjaSwgdnBjaV9od19yZWFkMTYsIE5VTEwsIGN0cmws
IDIsIE5VTEwpOw0KPiANCj4gLi4uIHdoYXQgaXMgdHJpZWQgdG8gYmUgcHV0IGluIHBsYWNlIGhl
cmUgKGFuZCBsaWtlICJubyBoYW5kbGVyIGluc3RhbGxlZCINCj4gZm9yIG90aGVyIHJlZ2lzdGVy
cykuDQpBY2NvcmRpbmcgdG8geW91ciBzdWdnZXN0LiBXaGF0IEkgY2FuIHRoaW5rIG9mIGlzIHdo
ZW4gdnBjaV9yZW1vdmVfcmVnaXN0ZXJzKCkgZmFpbHMsDQp0aGVuIGxvb2t1cCB0aGUgTVNJIHJl
bGF0ZWQgaGFuZGxlcnMsDQphbmQgc2V0IHRoZSByZWFkL3dyaXRlIGhvb2sgdG8gYmUgdnBjaV9p
Z25vcmVkX3JlYWQoKS92cGNpX2lnbm9yZWRfd3JpdGUoKSwNCmFuZCBzZXQgdGhlIHByaXZhdGUg
ZGF0YSB0byBiZSBOVUxMLg0KSXMgaXQgYWNjZXB0YWJsZT8NCg0KPiANCj4+PiBZb3UncmUgbG9z
aW5nIHRoZSBlYXJsaWVyIGVycm9yIGhlcmUsIGlmIHRoZXJlIHdhcyBvbmUuIElmIHRoaXMgb25l
DQo+Pj4gc3VjY2VlZHMsIC4uLg0KPj4gQnV0IGlmIHJldHVybiB0aGUgZWFybGllciBlcnJvciB0
byB0aGUgY2FsbGVyLCB0aGlzIGRldmljZSB3aWxsIGJlIHVudXNhYmxlLCB0aGVuIHN0aWxsIGFk
ZGluZyB0aGlzIGhhbmRsZXIgd2hlbiBhYm92ZSBmYWlsaW5nIHRvIHJlbW92ZSBoYW5kbGVycyBp
cyB1c2VsZXNzLg0KPiANCj4gVHJ1ZSwgeWV0IHRoYXQncyB0aGUgY2FzZSBhbHNvIHdpdGggeW91
ciBjb2RlIGlmIHJlbW92aW5nIHRoZSBjdHJsIGhhbmRsZXINCj4gZmFpbGVkLCBhcyB0aGVuIHRo
ZSBhdHRlbXB0IGFib3ZlIHRvIGFkZCBhbm90aGVyIGhhbmRsZXIgd291bGQgYWxzbyBmYWlsLg0K
PiANCj4gSSBkb24ndCBrbm93IHdoYXQgdGhlIGJlc3QgYXBwcm9hY2ggaXMgKEkgZGlkIHN1Z2dl
c3Qgb25lIGFib3ZlLCBhbGJlaXQNCj4gdGhhdCdzIG5vdCBxdWl0ZSBjb21wbGV0ZSB5ZXQgYXMg
dG8gdGhlIGJlaGF2aW9yIGhlcmUpOyBJIG1lcmVseSBvYnNlcnZlZA0KPiB0aGF0IHRoZSBiZWhh
dmlvciBhcyB5b3UgaGF2ZSBpdCBkb2Vzbid0IGxvb2sgcXVpdGUgcmlnaHQgLyBjb25zaXN0ZW50
Lg0KPiANCj4gSmFuDQo+IA0KPj4+PiAgICAgaWYgKCByYyApDQo+Pj4+ICAgICAgICAgcHJpbnRr
KFhFTkxPR19FUlIgIiVwZCAlcHA6IGFkZCBkdW1teSBtc2kgY3RybCBoYW5kbGVyIGZhaWwgcmM9
JWRcbiIsDQo+Pj4+ICAgICAgICAgICAgICAgIHBkZXYtPmRvbWFpbiwgJnBkZXYtPnNiZGYsIHJj
KTsNCj4+Pj4NCj4+Pj4gICAgIHJldHVybiByYzsNCj4+Pg0KPj4+IC4uLiB0aGUgY2FsbGVyIHdv
dWxkICh3cm9uZ2x5KSBnZXQgc3VjY2VzcyBiYWNrLg0KPj4+DQo+Pj4gSmFuDQo+Pg0KPiANCg0K
LS0gDQpCZXN0IHJlZ2FyZHMsDQpKaXFpYW4gQ2hlbi4NCg==


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 09:58:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 09:58:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024581.1400408 (Exim 4.92)
	(envelope-from )
	id 1uUMtS-0005qa-5z; Wed, 25 Jun 2025 09:58:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024581.1400408; Wed, 25 Jun 2025 09:58: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 1uUMtS-0005qT-2x; Wed, 25 Jun 2025 09:58:14 +0000
Received: by outflank-mailman (input) for mailman id 1024581;
 Wed, 25 Jun 2025 09:58: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 1uUMtR-0005qN-5t
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 09:58:13 +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 e6c01763-51aa-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 11:58:10 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a528243636so911475f8f.3
 for ; Wed, 25 Jun 2025 02:58:10 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d87305d3sm125830065ad.241.2025.06.25.02.58.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 25 Jun 2025 02:58:09 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e6c01763-51aa-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750845490; x=1751450290; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=c9QNUAb7NIahs2+pIVDI5v13ldUKxcCQSaK0r6cL9qA=;
        b=IvcE/Q37KQw3qoHYMQlvanZQpvW/D9zKQK15AJpUbJV5eM3rMTmLZEsoht2Gw0+8IU
         WAJuG6D83+vcN+tiUA61/EjTbzSVWdQIEemUdEkRQPvxWe0F+cK5riZf7igrjyo+A4if
         DI9QwPJzQCPVdecvWxwKC/LbFNt1/L0w6dc34+NEMLMoE2h1/9P/iQe85VaTWZEAOIQq
         5qCmKsqeor/wOX45jU8MDH6YoWp8tNuHuOya0wS3ZWEyhY3ZXD3zxIeHjH6o5X0qgfcK
         5cn8Zc0E+N9G8Y6SVlsNX3/pwEvp8wFJ3OU/voUVBdWmD40nxFUWI2qNHma7HR4JXr9E
         Bydw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750845490; x=1751450290;
        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=c9QNUAb7NIahs2+pIVDI5v13ldUKxcCQSaK0r6cL9qA=;
        b=usTeM4sje4hTut4yxZT9j+TSV9YtgDs9+GzMDWhBTo8q+vA1CUvswzb9frQJF48vQM
         qMLdokDnbBpFmOpqoP625N7H3xYz0lM3Wdd5WwkvIzEROMcAeTvvINXmSx/9GJ6qETMM
         d0/LBJzri7oFn86AfJ4LozsxYw1xk9MaPcgrQbIygcARbEJjq0wk57f8aAz8089z0heD
         eVKCo8iQihlLV4EVug76f9m2MgVqVMRwGAJmiBhmeSAJtjmJlTNdz9Ru70e+8Eyjn7cT
         0D9/eG1i2nAdP7QZyiqr7harhhUoOAJYozKW9DwJfUCixR36ZfJDFtP8yIUyeSDk+eEF
         qknw==
X-Forwarded-Encrypted: i=1; AJvYcCUCGJgkTAsfU5t+RUgDZjcSLgIIMoWRV7Pep7pTcCLIq2CYKA6XXFGx5qbJ8UWC8t5qIGAIDDO9NBM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwGEzl7f2AbFpBELcJtt+P9pgo+TxDGn8iJngQ9oj1yJFJCGZPc
	JyOqBYOzBqUWu3vS4ey9ZWhzW0F73apYdIerafTvew1tKrcQ6HiDdPL8y0tpi6XLNg==
X-Gm-Gg: ASbGncvN0kWDq6e6L4vfa3/wfiK12ToxayXbntQpeWgDq+BABuQuQUpCJl2n6Z0o6WS
	0ZI7b2Aco+3+4tmUwmJFxIcqdMmPTHYqLdlHqknAy4/LMGboSBQu85TsPpWrn/3HumEcScAU1CS
	yq8oHZjVpTJj8VRrPlK1ujPLqoQbwrXnrh4wid1qK6Lb6YrY6kJ6zXvYHZ2XL6GZXnxg7oIC1M9
	hcQ6u2EJ7DIVhbc4zKEUQrOemeIMeiuRPNlewR1tHrbbC4q2O6/YjRKjy5R+n7v/aNJsbjqtyP0
	WRHrkJYyXmFO4n0jDk14tB2z9cBU3tfepAV0o0EQG6RJstmfGQUL5VeJCwB9/8hz4CvWkhdJAh4
	3U2OTVY7r9f12oJbNA1clg08k2nG4pRkpBrxUsYBOArL26e92RHg1360ujA==
X-Google-Smtp-Source: AGHT+IHiW0lttO1ElT6QXLEDXQOC8JGWMnX+2j0WCIhnP4Xyt1G/A9AYz6TLqy0xsIetQtMT3NZL+A==
X-Received: by 2002:a05:6000:4028:b0:3a4:f90c:31e3 with SMTP id ffacd0b85a97d-3a6ed6644dbmr1710737f8f.31.1750845489979;
        Wed, 25 Jun 2025 02:58:09 -0700 (PDT)
Message-ID: <86841b35-119a-4265-8ff0-9b8549e8ca52@suse.com>
Date: Wed, 25 Jun 2025 11:58:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/4] Revert part of "x86/mwait-idle: disable IBRS during
 long idle"
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20250624163951.301743-1-andrew.cooper3@citrix.com>
 <20250624163951.301743-4-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20250624163951.301743-4-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 24.06.2025 18:39, Andrew Cooper wrote:
> Most of the patch (handling of CPUIDLE_FLAG_IBRS) is fine, but the
> adjustements to mwait_idle() are not.
> 
> spec_ctrl_{enter,exit}_idle() do more than just alter MSR_SPEC_CTRL.IBRS.  The
> VERW and RSB stuff are **unsafe** to omit.
> 
> The only reason this doesn't need an XSA is because no changes were made to
> the lower level mwait_idle_with_hints(), and thus it remained properly
> protected.
> 
> I.e. This change only served to double the expensive operations in the case it
> was trying to optimise.
> 
> I have an idea of how to plumb this more nicely, but it requires larger
> changes to legacy IBRS handling to not make spec_ctrl_enter_idle() vulnerable
> in other ways.

What are the concerns here? As it looks skipping the MSR write would look
to require checking some (per-CPU) conditional. Conditional branches can't
really be of concern, or the "if (cx->ibrs_disable)" that you're now
removing again would have been of concern, too. Hence simply a new SCF_
flag would look to be sufficient, for mwait_idle() to convey the necessary
info to spec_ctrl_enter_idle()?

>  In the short term, simply take out the perf hit.
> 
> Fixes: 08acdf9a2615 ("x86/mwait-idle: disable IBRS during long idle")
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Wed Jun 25 10:03:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 10:03:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024588.1400418 (Exim 4.92)
	(envelope-from )
	id 1uUMyY-0007ce-Nl; Wed, 25 Jun 2025 10:03:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024588.1400418; Wed, 25 Jun 2025 10:03:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUMyY-0007cX-LC; Wed, 25 Jun 2025 10:03:30 +0000
Received: by outflank-mailman (input) for mailman id 1024588;
 Wed, 25 Jun 2025 10:03: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 1uUMyX-0007c8-Oa
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 10:03:29 +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 a3b5e34d-51ab-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 12:03:27 +0200 (CEST)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-4537edf2c3cso15121985e9.3
 for ; Wed, 25 Jun 2025 03:03:27 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d83989besm133596205ad.38.2025.06.25.03.03.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 25 Jun 2025 03:03:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a3b5e34d-51ab-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750845807; x=1751450607; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=LRZisrk1CvchhghWLjgl9BWSNnuDsNqurJUooOP/gK0=;
        b=HYxyuPGGF81Z2VDtrWm/qk3Lo503Atl9Lg/V5bHDwU1BK4fF8NvgXHL5z4OROirm//
         etSUaco/2G282e+LzQu3t0S96gTyXuzyybtlqLUNju3+36MnXiDnPiqdBPzkWIPpAGd5
         YzRPXDkG/DOHONrAVH3d4pkJCidK8IrYAwzWwpTiw5rgk+cYWQ2Fe/7/+WhomPA0dgEe
         eEfPkpICP3I1Gl5yDk1SwrRWhrWbvACsxRLWaXcOfrxPdYFs5ZaMsgsAWq0+hpdnx6Cz
         8G1Mk/Jp7O9qvOOLgiBqcmiqeOs0CYZvG4FnH9YgFAyawXHwwx7YIsMWBkyaaeakRuWS
         cmOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750845807; x=1751450607;
        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=LRZisrk1CvchhghWLjgl9BWSNnuDsNqurJUooOP/gK0=;
        b=Wu5XvpX1ljK/CrFP+UwVsog3U9EjBuqWF8AnSsP2KuTkq8/7LQ5dAHkptjYoPyvwYg
         UHMN7F5ZO5D3dGEW2462duARBsHtG3n50d9khy7J7d7dylP5EjU2bGD/McHxCtRdZj7a
         VpWJJicJiFX0yrJRZ8M6AFQrLUzMGsLGvAOPQriLib2aH9lIcuSKdVqhunUknxs5zqQm
         HJItXDbJBlY4g5YWyCFEJegpjukN4Ym8eTO/x5XXUgWJQxBERFdG/4+ODq4+WzxlzBpx
         lVLQizUo06LYqI5O+Jfp6ZRT9AKbMZccb1DAsDCzsnlAHXvv3daEbY41dz4BF/v7PC3N
         mPwQ==
X-Forwarded-Encrypted: i=1; AJvYcCWvk4P8/WvwAK+fhtk3+aGDM720axPckLZcn3PK5sfFm4Ih+uhOlvtkx5Qb70nwO6QafkcEtR3yiGg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwCGbsupIzqnqIdB/BrKqFPpUTD5zRQUxCjX7JohY+sHbZdUqkg
	DKD/fGnoEBphsLy4H9dZ5/LY6T/YMuPW/1CUnCW6aOXieG4aUZSYxs95bnJk9IbmIA==
X-Gm-Gg: ASbGncvbHJbXtHwg1gZ8QG3JyCAmCZMAH6jlIEY0Br4DFr/ORUt2o9TSyo5qmLOcYhC
	7a7ncHFRytGK6VGMgQOUcPRIITs3fmHC87YYg9k60ZUYm94jREfC6RRn+QdC8mxzJFNfXjvB8ob
	aSTHY7J0Knj8Gme4MF3teuKEeGiK0xkEWyacZucGG28M5n0IjYS2aC6Y1IcSaMlsEL66z5c/SKX
	NO5zbjrSLodBFybII2EnCn1jaTLe4G2NoOrllGTmS7ny9Q7U53WOYNIUNZz1uVIBSSwjEtAJZYP
	y4jtgNDLJgzZbyjCSg2ti9wkpaflXtPF/gxtNk0iG6hmjLN00YbdrfWev1SRUFbsXvnEyz64eIG
	QQKBGmblZMQ6p9piNqvCUXkqplMX28RsIxe30BlOPXRyG0+w=
X-Google-Smtp-Source: AGHT+IFeBAt5fN5CyHGHoXbqB0USI7Qq4EvKcCX3amxF/o4SwbCDSz6AK84giEdgxYTRKOEvBXgCbw==
X-Received: by 2002:a05:6000:2406:b0:3a1:fe77:9e1d with SMTP id ffacd0b85a97d-3a6ed5da5bdmr1547320f8f.16.1750845806756;
        Wed, 25 Jun 2025 03:03:26 -0700 (PDT)
Message-ID: <771cd5b7-2b89-49b1-9aba-8cd79319d3ce@suse.com>
Date: Wed, 25 Jun 2025 12:03:16 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
To: "Chen, Jiqian" 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Andrew Cooper ,
 Anthony PERARD ,
 "Orzel, Michal" , Julien Grall ,
 Stefano Stabellini ,
 "xen-devel@lists.xenproject.org" ,
 "Huang, Ray" 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-3-Jiqian.Chen@amd.com>
 <516a3adc-320d-46ce-b235-8ef91469abcf@suse.com>
 
 <227df6d3-a2c3-4576-bde9-d8057c378e7a@suse.com>
 
 <5c4b186e-686e-4fc8-bcf1-854bc1f5ec8b@suse.com>
 
 <9d5d0e44-66c3-4e3f-8704-2c862c5f5aff@suse.com>
 
 <3638e73c-2a83-4164-9a84-839245245727@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 25.06.2025 11:27, Chen, Jiqian wrote:
> On 2025/6/25 16:36, Jan Beulich wrote:
>> On 25.06.2025 08:51, Chen, Jiqian wrote:
>>> On 2025/6/24 18:08, Jan Beulich wrote:
>>>> On 24.06.2025 11:29, Chen, Jiqian wrote:
>>>>> On 2025/6/24 16:05, Jan Beulich wrote:
>>>>>> On 24.06.2025 10:02, Chen, Jiqian wrote:
>>>>>>> On 2025/6/20 14:38, Jan Beulich wrote:
>>>>>>>> On 19.06.2025 08:39, Chen, Jiqian wrote:
>>>>>>>>> On 2025/6/18 22:05, Jan Beulich wrote:
>>>>>>>>>> On 12.06.2025 11:29, Jiqian Chen wrote:
>>>>>>>>>>> @@ -29,9 +30,22 @@ typedef int vpci_register_init_t(struct pci_dev *dev);
>>>>>>>>>>>   */
>>>>>>>>>>>  #define VPCI_MAX_VIRT_DEV       (PCI_SLOT(~0) + 1)
>>>>>>>>>>>  
>>>>>>>>>>> -#define REGISTER_VPCI_INIT(x, p)                \
>>>>>>>>>>> -  static vpci_register_init_t *const x##_entry  \
>>>>>>>>>>> -               __used_section(".data.vpci." p) = (x)
>>>>>>>>>>> +#define REGISTER_VPCI_CAPABILITY(cap, finit, fclean, ext) \
>>>>>>>>>>> +    static const vpci_capability_t finit##_t = { \
>>>>>>>>>>> +        .id = (cap), \
>>>>>>>>>>> +        .init = (finit), \
>>>>>>>>>>> +        .cleanup = (fclean), \
>>>>>>>>>>> +        .is_ext = (ext), \
>>>>>>>>>>> +    }; \
>>>>>>>>>>> +    static const vpci_capability_t *const finit##_entry  \
>>>>>>>>>>> +        __used_section(".data.rel.ro.vpci") = &finit##_t
>>>>>>>>>>
>>>>>>>>>> Could you remind me why the extra level of indirection is necessary here?
>>>>>>>>>> That is, why can't .data.rel.ro.vpci be an array of vpci_capability_t?
>>>>>>>>> You mean I should change to be:
>>>>>>>>> #define REGISTER_VPCI_CAPABILITY(cap, finit, fclean, ext) \
>>>>>>>>>     static const vpci_capability_t finit##_t \
>>>>>>>>>         __used_section(".data.rel.ro.vpci") = { \
>>>>>>>>>         .id = (cap), \
>>>>>>>>>         .init = (finit), \
>>>>>>>>>         .cleanup = (fclean), \
>>>>>>>>>         .is_ext = (ext), \
>>>>>>>>>     }
>>>>>>>>>
>>>>>>>>> Right?
>>>>>>>>
>>>>>>>> Yes, subject to the earlier comments on the identifier choice.
>>>>>>> Got it.
>>>>>>> One more question, if change to be that, then how should I modify the definition of VPCI_ARRAY?
>>>>>>> Is POINTER_ALIGN still right?
>>>>>>
>>>>>> Yes. The struct doesn't require bigger alignment afaics. (In fact in principle
>>>>>> no alignment should need specifying there, except that this would require
>>>>>> keeping the section separate in the final image. Which I don't think we want.)
>>>>>>
>>>>>>> Since I encountered errors that the values of __start_vpci_array are not right when I use them in vpci_init_capabilities().
>>>>>>
>>>>>> Details please.
>>>>> After changing __start_vpci_array to be vpci_capability_t array, codes will be (maybe I modified wrong somewhere):
>>>>>
>>>>> diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
>>>>> index c51bbb8abb19..9f2f438b4fdd 100644
>>>>> --- a/xen/drivers/vpci/vpci.c
>>>>> +++ b/xen/drivers/vpci/vpci.c
>>>>> @@ -36,8 +36,8 @@ struct vpci_register {
>>>>>  };
>>>>>
>>>>>  #ifdef __XEN__
>>>>> -extern const vpci_capability_t *const __start_vpci_array[];
>>>>> -extern const vpci_capability_t *const __end_vpci_array[];
>>>>> +extern vpci_capability_t __start_vpci_array[];
>>>>> +extern vpci_capability_t __end_vpci_array[];
>>>>
>>>> Just fyi: You lost const here.
>>>>
>>>>> @@ -255,7 +255,7 @@ static int vpci_init_capabilities(struct pci_dev *pdev)
>>>>>  {
>>>>>      for ( unsigned int i = 0; i < NUM_VPCI_INIT; i++ )
>>>>>      {
>>>>> -        const vpci_capability_t *capability = __start_vpci_array[i];
>>>>> +        const vpci_capability_t *capability = &__start_vpci_array[i];
>>>>>          const unsigned int cap = capability->id;
>>>>>          const bool is_ext = capability->is_ext;
>>>>>          int rc;
>>>>> diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
>>>>> index f4ec1c25922d..77750dd4131a 100644
>>>>> --- a/xen/include/xen/vpci.h
>>>>> +++ b/xen/include/xen/vpci.h
>>>>> @@ -31,14 +31,13 @@ typedef struct {
>>>>>  #define VPCI_MAX_VIRT_DEV       (PCI_SLOT(~0) + 1)
>>>>>
>>>>>  #define REGISTER_VPCI_CAPABILITY(cap, finit, fclean, ext) \
>>>>> -    static const vpci_capability_t finit##_t = { \
>>>>> +    static vpci_capability_t finit##_entry \
>>>>> +        __used_section(".data.rel.ro.vpci") = { \
>>>>>          .id = (cap), \
>>>>>          .init = (finit), \
>>>>>          .cleanup = (fclean), \
>>>>>          .is_ext = (ext), \
>>>>> -    }; \
>>>>> -    static const vpci_capability_t *const finit##_entry  \
>>>>> -        __used_section(".data.rel.ro.vpci") = &finit##_t
>>>>> +    }
>>>>>
>>>>>  #define REGISTER_VPCI_CAP(cap, finit, fclean) \
>>>>>      REGISTER_VPCI_CAPABILITY(cap, finit, fclean, false)
>>>>>
>>>>> I print the value of NUM_VPCI_INIT, it is a strange number (6148914691236517209).
>>>>
>>>> What are the addresses of the two symbols __start_vpci_array and __end_vpci_array?
>>> __end_vpci_array is 0xffff82d0404251b8
>>> __start_vpci_array is 0xffff82d040425160
>>> NUM_VPCI_INIT is 0x5555555555555559
>>> sizeof(vpci_capability_t) is 0x18
>>
>> Oh, of course - there's a psABI peculiarity that you run into here: Aggregates
>> larger than 8 bytes are required to have 16-byte alignment. Hence while
>> sizeof() == 0x18 and __alignof() == 8, the section contributions still are
>> accompanied by ".align 16", and thus respective padding is inserted by
>> assembler and linker. IOW you end up with two 32-byte entries and a trailing
>> 24-byte one. The easiest (and least problematic going forward) approach to
>> deal with that is probably going to be to add __aligned(16) to the struct
>> decl. (Whether to limit this to just x86 I'm not sure: While other psABI-s may
>> be different in this regard, we may want to be on the safe side.)
> Thanks for you detailed explanation.
> If I understand correctly, I need to change the definition of vpci_capability_t to be:
> 
> typedef struct {
>     unsigned int id;
>     bool is_ext;
>     int (* init)(const struct pci_dev *pdev);
>     int (* cleanup)(const struct pci_dev *pdev);
> }
> #ifdef CONFIG_X86
> __aligned(16)
> #endif
> vpci_capability_t;

You'll need to check whether this has the intended effect. There are yet more
peculiarities when it comes to attributes on structs, typedefs, and the
combination of the two. I wonder though: Do we really need a typedef here?
Going with just struct vcpi_capability would eliminate concerns over those
peculiarities.

Also, as said - you will need to check whether other architectures are
different from x86-64 in this regard. We better wouldn't leave a trap here,
for them to fall into when they enable vPCI support. I.e. my recommendation
would be that if in doubt, we put the __aligned() there unconditionally.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 10:04:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 10:04:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024598.1400428 (Exim 4.92)
	(envelope-from )
	id 1uUMzP-00088S-4a; Wed, 25 Jun 2025 10:04:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024598.1400428; Wed, 25 Jun 2025 10:04: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 1uUMzP-00088L-10; Wed, 25 Jun 2025 10:04:23 +0000
Received: by outflank-mailman (input) for mailman id 1024598;
 Wed, 25 Jun 2025 10:04: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 1uUMzN-0007uJ-QX
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 10:04:21 +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 c3a69a1a-51ab-11f0-a30f-13f23c93f187;
 Wed, 25 Jun 2025 12:04:21 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3a507e88b0aso5319399f8f.1
 for ; Wed, 25 Jun 2025 03:04:21 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d86ef84fsm127050225ad.216.2025.06.25.03.04.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 25 Jun 2025 03:04:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c3a69a1a-51ab-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750845861; x=1751450661; 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=SBeqnB9PW2QxdiM/RBwMWjUFjBtgIPeRVqMNQVohzec=;
        b=Qh+WxbiMZ+jkwUkMbt2xw+3tJoMxLzaGVyHu2GvibcpuOU8f323Mg4kRASxqnyTUrd
         ijrFFK809r8WU41amgPD5EIhY9+d9AKOL4tdgCGKsp11QgffJbixTp+wX4vDp5gjMsCg
         vQJgXQ30DxLnkb8ktojujwaz2B5ZbDXdplpy542gK71B1MSglG1seru5KySJWG/OdTuf
         +AZ8fSKVRxTBSnf119b0/IJKvbi4oAxQylet2s5Lg6dX3ouG/r5nh1T0EvJM3UFsu7S4
         8HXXxNoFBK1TT1P3n8qL84OcKsWv0u1hW/yCEmHMv8TWhcOt48xS9sIquX0ckiNgqXkx
         mCOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750845861; x=1751450661;
        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=SBeqnB9PW2QxdiM/RBwMWjUFjBtgIPeRVqMNQVohzec=;
        b=QENlWCZ6PoWaLeeZyN4oQpKQXiYqGryzDeZCW0nRDEO6VsrUPpqgk8HpFxAugJUrG3
         36qtGxtm7e+7uQhkl1iBUGBM425UnZCwzbcfJyGxMWN/+z+Rxnvlw7+vYRHKGNLvupwY
         03aPX4PsOaUgRMTxNZqNhlfdehoCNww1AnK7SUoiPEAWF5wZtVcMYpgNEK8laKLwerp1
         xYguQN8J3oYijDRTREeKgej9qDTPu2RAhJ+X3g1nRGR6Rn159VkTrHGQAypmPYtpdgpa
         AYk/cl6sRvWRjGebjX9wnvaKRmcLjkoh/wy4gkTQE81YHXnImV/9crgzPMvpBY/kdhZk
         Sd7A==
X-Forwarded-Encrypted: i=1; AJvYcCXEYdNOASDGwR4AzWNKDjaphOeFdXlQF3Xkgdo5ANhlZCsp5efWPRzXGwCP3EDp0zHAbzaCqK407IE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxxd1EQlAErFUsK+hJT3/cPId+LVvteXcgzrkZ6G+Muc25pbYBy
	din4D/ed2A+OsxwTa7XpksVbr+zcU9zA+n2BhndERUYbbFdghOoLoLhWHTPyWdR0uA==
X-Gm-Gg: ASbGncvJj+bBZEN7rXMN0t4Mf2pMguw+gDecBCk1ZDwikBUEVdSJJeWKJq2paYv0Yku
	q3dbEukrkyEqaVG2s5rVmNPCU+p0EHEOKnH9w1XLcI/tEcthv+RlI6hoDjT0SkhOtZX+8tlidrB
	57tj8euAjCuKeUmcrgUw1gt4mZuW+Mkv10Z+G5A2voXvjtt06R4gvSte5EhZQD7XnpUFg08pM1o
	GtJtqnW3W8n12RLu2s33YTaeiLc0AiUhanoNQgjuf57epFuswLfwsazNHNW7vfaCVVUva0eFmvq
	IbPFHTHUouTXvX/6TVaR6rBqCYUBOPfMwpz0g/LidclageTqIpvgB0OM9YI9jC5AsMKhGVUMas3
	m3rsX5gpfp50kO72kfmQHDGRmCAJFZK326yeypNu+JQw9wPM=
X-Google-Smtp-Source: AGHT+IFaG15mC0GvyMJkG5Aj3mFOCu8Em5Z6QXe9+vH8vVL5DFWkKbMD2+fUWCWfJMkc7Xaq6Rz2xg==
X-Received: by 2002:a05:6000:401f:b0:3a0:9dfc:da4 with SMTP id ffacd0b85a97d-3a6ed646a0fmr1801919f8f.42.1750845860630;
        Wed, 25 Jun 2025 03:04:20 -0700 (PDT)
Message-ID: 
Date: Wed, 25 Jun 2025 12:04:10 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
From: Jan Beulich 
To: "Chen, Jiqian" 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Andrew Cooper ,
 Anthony PERARD ,
 "Orzel, Michal" , Julien Grall ,
 Stefano Stabellini ,
 "xen-devel@lists.xenproject.org" ,
 "Huang, Ray" 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-3-Jiqian.Chen@amd.com>
 <516a3adc-320d-46ce-b235-8ef91469abcf@suse.com>
 
 <227df6d3-a2c3-4576-bde9-d8057c378e7a@suse.com>
 
 <5c4b186e-686e-4fc8-bcf1-854bc1f5ec8b@suse.com>
 
 <9d5d0e44-66c3-4e3f-8704-2c862c5f5aff@suse.com>
 
 <3638e73c-2a83-4164-9a84-839245245727@suse.com>
 
 <771cd5b7-2b89-49b1-9aba-8cd79319d3ce@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: <771cd5b7-2b89-49b1-9aba-8cd79319d3ce@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 25.06.2025 12:03, Jan Beulich wrote:
> On 25.06.2025 11:27, Chen, Jiqian wrote:
>> If I understand correctly, I need to change the definition of vpci_capability_t to be:
>>
>> typedef struct {
>>     unsigned int id;
>>     bool is_ext;
>>     int (* init)(const struct pci_dev *pdev);
>>     int (* cleanup)(const struct pci_dev *pdev);
>> }
>> #ifdef CONFIG_X86
>> __aligned(16)
>> #endif
>> vpci_capability_t;
> 
> You'll need to check whether this has the intended effect. There are yet more
> peculiarities when it comes to attributes on structs, typedefs, and the
> combination of the two. I wonder though: Do we really need a typedef here?
> Going with just struct vcpi_capability would eliminate concerns over those
> peculiarities.
> 
> Also, as said - you will need to check whether other architectures are
> different from x86-64 in this regard. We better wouldn't leave a trap here,
> for them to fall into when they enable vPCI support. I.e. my recommendation
> would be that if in doubt, we put the __aligned() there unconditionally.

And, forgot to say, there definitely wants to be a comment here.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 10:09:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 10:09:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024605.1400438 (Exim 4.92)
	(envelope-from )
	id 1uUN4i-0000M7-Mf; Wed, 25 Jun 2025 10:09:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024605.1400438; Wed, 25 Jun 2025 10:09:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUN4i-0000M0-Jc; Wed, 25 Jun 2025 10:09:52 +0000
Received: by outflank-mailman (input) for mailman id 1024605;
 Wed, 25 Jun 2025 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 1uUN4h-0000Lu-FD
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 10:09:51 +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 8715533e-51ac-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 12:09:49 +0200 (CEST)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3a4ef2c2ef3so5044114f8f.2
 for ; Wed, 25 Jun 2025 03:09:49 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-315f5426bfbsm1333473a91.24.2025.06.25.03.09.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 25 Jun 2025 03:09:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8715533e-51ac-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750846189; x=1751450989; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=nxpelb5lmsHUzuwhvxF3XvwkzaOQ7mp/Y+YwY3O5WB0=;
        b=QOlddUzQ0Who4DnCVrTGbrjiJX5cz1P7pjkDQT4sU4B2+9ItePl5J10Lg7t9jYs2RH
         7C8ht7judBC5w7kTjhspAyasgAbmF81ZDj3E4S2PgQlROJS1OPc/aoBcSYX5niJLGXUz
         gRknLms3p/nq3cfO1ggTTOU5mmh38RkVinkW7CCUXWwDyB6yD2joDiSEJr1GcblGzp72
         QK0hmpwPUZixEthy/TYsOvnb8gz0kZ9W9/c2Z8xbn8hT+DgFoe/lCuSSiQiMV4LSDmo9
         Jtq9tBCl3VkyEu53kpBGO0rEI65oIfjeoFX96FUJf9okAaq70djUwwgGceW5Jve57hk2
         Dcng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750846189; x=1751450989;
        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=nxpelb5lmsHUzuwhvxF3XvwkzaOQ7mp/Y+YwY3O5WB0=;
        b=mvOBElRmj/yAEoCPZ7gExDM0CesKjoZwt6UB5/4mxh9GBelHcYkCkqyZdnAGmKGR/c
         6W8d/C9SfIMK60Gl7Kmf3P5d6toMdk0Nq78Xjeky5uGezJB/pqZh5tkwy2O5DqVN2opb
         gYQrFpMurI5dV+bXH4jA7qNpBNsQ6+cRzAzyeH+H8o7vgTjk8wgC6MQ2Zlf5NATJBq5A
         TFSVVLNMHnLwTFDsk7f/hvMJfTlgeNwlMb7mO1R+WILTb9RxW+PzvLJuqJMiiMcGmP/j
         IGvAeBoerV54oWzJHCQK4ZTZ0JSiTNPQ+ssGE1fxG55PqcZyMyztZ/22mLQBQd/y5idu
         kK4Q==
X-Forwarded-Encrypted: i=1; AJvYcCXLk8+GT/fZjaKSvVfa+gY1rcogGIsWg/bfUw/lWFb3Xl2+cEVAzTtxAYE51ppIAJqbYPJN/DYt8Q8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzfefdBQ26KkZYS589yuCoxMgJvxgEBLmIqo6Q7+fsEGbBZcfpl
	KdYRaM+hPvOO9AwMIVPUS5UZLayEqflhMqQgVsMmPaRLeBFf0PhlCxlO9SI8HupQbw==
X-Gm-Gg: ASbGncvNgEC5YK9GwEREARjXyE9vEAeGqZT41BRXmXov5PuqXi+M4E/T8iISCmNx3ik
	QQlYjwIQsqTczae9g5qaEijSALZHlNoyQK/wwGQsiqO3ofe1QBHy/8dHLqGVPtwODSm0cISg85S
	Bl1iwM8Pxtf0VFDmv52wguYjMNwp9ng1wNsTxI6MywGfxanbW0Bpg0BNs9vOGx76TKCMohLJRUH
	eroaQXOwaAw/0nEEQRzYiDolZlBAmgRApvfyk1xjI4czIrrGViGRBEiaCkw/QMDdRXqIzrJWQer
	GDc0Yy04R9ItFiHtb7yACSmFgZuII2fwjzf9XxQgdqrr4evQqrlJIiSRKqAFG/xR3CiVVkvFxE5
	VcfYOPWvFxIwzF2PlRBqBsp16JYVWWY2z9QZdsVYgtG5l254=
X-Google-Smtp-Source: AGHT+IFExYa00bXuyHac/TpkDQ64LH4arzyqqwSPaN83068etj84IFeXJkQ9XRgduneKjv7kWcqk1w==
X-Received: by 2002:a05:6000:200e:b0:3a4:f6ba:51c8 with SMTP id ffacd0b85a97d-3a6ed5ee613mr1945143f8f.14.1750846188567;
        Wed, 25 Jun 2025 03:09:48 -0700 (PDT)
Message-ID: 
Date: Wed, 25 Jun 2025 12:09:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 7/8] vpci/msi: Free MSI resources when init_msi() fails
To: "Chen, Jiqian" 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "xen-devel@lists.xenproject.org" ,
 "Huang, Ray" 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-8-Jiqian.Chen@amd.com>
 <773c448a-d814-458f-ad83-e9740e724408@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 25.06.2025 11:47, Chen, Jiqian wrote:
> On 2025/6/25 17:15, Jan Beulich wrote:
>> On 25.06.2025 09:16, Chen, Jiqian wrote:
>>> On 2025/6/24 18:17, Jan Beulich wrote:
>>>> On 24.06.2025 11:49, Chen, Jiqian wrote:
>>>>> On 2025/6/18 22:45, Jan Beulich wrote:
>>>>>> On 12.06.2025 11:29, Jiqian Chen wrote:
>>>>>>> --- a/xen/drivers/vpci/msi.c
>>>>>>> +++ b/xen/drivers/vpci/msi.c
>>>>>>> @@ -193,6 +193,33 @@ static void cf_check mask_write(
>>>>>>>      msi->mask = val;
>>>>>>>  }
>>>>>>>  
>>>>>>> +static int cf_check cleanup_msi(struct pci_dev *pdev)
>>>>>>> +{
>>>>>>> +    int rc;
>>>>>>> +    unsigned int end, size;
>>>>>>> +    struct vpci *vpci = pdev->vpci;
>>>>>>> +    const unsigned int msi_pos = pdev->msi_pos;
>>>>>>> +    const unsigned int ctrl = msi_control_reg(msi_pos);
>>>>>>> +
>>>>>>> +    if ( !msi_pos || !vpci->msi )
>>>>>>> +        return 0;
>>>>>>> +
>>>>>>> +    if ( vpci->msi->masking )
>>>>>>> +        end = msi_pending_bits_reg(msi_pos, vpci->msi->address64);
>>>>>>> +    else
>>>>>>> +        end = msi_mask_bits_reg(msi_pos, vpci->msi->address64) - 2;
>>>>>>> +
>>>>>>> +    size = end - ctrl;
>>>>>>> +
>>>>>>> +    rc = vpci_remove_registers(vpci, ctrl, size);
>>>>>>> +    if ( rc )
>>>>>>> +        return rc;
>>>>>>
>>>>>> This is a difficult one: It's not a good idea to simply return here, yet
>>>>>> at the same time the handling of the register we're unable to remove may
>>>>>> still require e.g. ...
>>>>>>
>>>>>>> +    XFREE(vpci->msi);
>>>>>>
>>>>>> ... this. There may therefore be more work required, such that in the
>>>>>> end we're able to ...
>>>>>>
>>>>>>> +    return vpci_add_register(pdev->vpci, vpci_hw_read16, NULL, ctrl, 2, NULL);
>>>>>>
>>>>>> ... try this at least on a best effort basis.
>>>>>>
>>>>>> More generally: I don't think failure here (or in other .cleanup hook
>>>>>> functions) may go entirely silently.
>>>>> Does below meet your modification expectations?
>>>>
>>>> Not sure, sorry. By "more" I really meant "more" (which may just be code
>>>> auditing, results of which would need writing down, but which may also
>>>> involve further code changes; see below).
>>>>
>>>>>     rc = vpci_remove_registers(vpci, ctrl, size);
>>>>>     if ( rc )
>>>>>         printk(XENLOG_ERR "%pd %pp: remove msi handlers fail rc=%d\n",
>>>>>                pdev->domain, &pdev->sbdf, rc);
>>>>>
>>>>>     XFREE(vpci->msi);
>>>>
>>>> As I tried to indicate in my earlier reply, the freeing of this struct is
>>>> safe only if the failure above would not leave any register handlers in
>>>> place which still (without appropriate checking) use this struct.
>>> Hmm, but all handlers added in init_msi() use this struct.
>>> So it doesn't exist the case that when above unable to remove all handlers and still require xfree this struct.
>>
>> Well, in the end you say in different words what I did say, if I understand
>> correctly. There are several options how to deal with that. One might be to
>> have those handlers recognize the lack of that pointer, and behave like ...
>>
>>>>>     /*
>>>>>      * The driver may not traverse the capability list and think device
>>>>>      * supports MSI by default. So here let the control register of MSI
>>>>>      * be Read-Only is to ensure MSI disabled.
>>>>>      */
>>>>>     rc = vpci_add_register(vpci, vpci_hw_read16, NULL, ctrl, 2, NULL);
>>
>> ... what is tried to be put in place here (and like "no handler installed"
>> for other registers).
> According to your suggest. What I can think of is when vpci_remove_registers() fails,
> then lookup the MSI related handlers,

What exactly does this mean? Aiui if vpci_remove_registers() ends up failing,
it may be the lookup which is the problem. Which isn't why this wasn't what
I suggested. Instead I suggested to make the respective handlers deal with
the case of vpci->msi being NULL. Which of course in turn would require
passing pdev->vpci to the respective vpci_add_register(), not pdev->vpci->msi.

> and set the read/write hook to be vpci_ignored_read()/vpci_ignored_write(),

But vpci_hw_read16() != vpci_ignored_read().

> and set the private data to be NULL.
> Is it acceptable?

Altering already registered handler properties feels pretty fragile to me.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 10:11:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 10:11:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024611.1400448 (Exim 4.92)
	(envelope-from )
	id 1uUN5s-00020F-VS; Wed, 25 Jun 2025 10:11:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024611.1400448; Wed, 25 Jun 2025 10:11: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 1uUN5s-000208-ST; Wed, 25 Jun 2025 10:11:04 +0000
Received: by outflank-mailman (input) for mailman id 1024611;
 Wed, 25 Jun 2025 10:11: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 1uUN5r-0001yh-KJ
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 10:11:03 +0000
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com
 [2a00:1450:4864:20::42e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b252b1a5-51ac-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 12:11:01 +0200 (CEST)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3a5257748e1so4293122f8f.2
 for ; Wed, 25 Jun 2025 03:11:01 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d867c0d9sm126764955ad.177.2025.06.25.03.10.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 25 Jun 2025 03:11:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b252b1a5-51ac-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750846261; x=1751451061; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=tOKD7SS3i7ofLqEhbd0+VCWuLYRnzbWGbJM7HLdoG88=;
        b=VDHW/Xd4h/Z0FQXiraY/IEm5VfsqNVggiGEkuznZKXdjJH3A7OgnhBuUmWd2m180v4
         2XdhFDJAYHlhJvZbQZnyfN2JqnBGy+W5EKkuY927MkJ9yNfl226eZmjf+Nozs1ysmbj2
         boRBLHzuX0187ZQMhbqXZ8mR23E9qKCJLPdF1zvHDgGm34tVKgbfb1xUHHMaJbB9uzrz
         8nGYgJkqA6IPDhgSa8eLeOBucwF943MtLUe4TnblfjSLMuAvM9r2N5C/FEABeo7mwEcU
         IjKqc2DUoueFTRBBUYMBVNa2+Il3kMZyGy43Ve2lM6Zm088DlRF3+O2E7XcCETfEXnMb
         zVCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750846261; x=1751451061;
        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=tOKD7SS3i7ofLqEhbd0+VCWuLYRnzbWGbJM7HLdoG88=;
        b=l2oP9Jz6ONHQAfVreq6dQbYzN4/hxfHnb4MZ5/3Rw0YfdapLmaIGnPvLH/VMCQkeuh
         RfX5rw9UqNV8xTaAEaWkpU+1GLwEHmXbyUX002W+tV6MjhU4UIRCU0g/X204sZawGkCh
         4683YSjwS5wt58MDohql4sQHE4rYaLc5ulQlim4VgxFxgJl5u+ej+esLNCwU4B8CD/MW
         Mwe7+qtwArLuu0KRZOJeDYQizpGqZsr2+MZKtJRHHIawCLtZgQh8shUgGadzRBv40+Jj
         ym7pN0rdUTgDEhykdeg6Vch7YlDKn5tHZoFzaZtiPjr9YiHIL4fyfsoDpYs4NbMpvDD8
         wJAg==
X-Forwarded-Encrypted: i=1; AJvYcCWEOVU3RM1zixH15RZisHRosGlOFFAkyzuVwpPUq0VyAwWjuxVduslDWepZu1XEA9TEODX89y/eL48=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywq2VMn4LfFTJX9TkkLgisLM7+/got5AgbfCi5Saywbvy4WKhuY
	03JT+2nrzQxC5VB5Q7M9WCngx16GUxTzYYbF2hGiyR0bTOoABsuJoYS0w1juaqsL2g==
X-Gm-Gg: ASbGncsy87Lcmf//veUGBwndkHAWjM0btiKeKIr6Xxyt1QrezaeBGSjl77wg+cMQ0tb
	YiCqmLCUPOBfLDshe7qB9eJN97Zu+HjoS4rWEqQ17Ku41S5sG0aD14FNLxmiGG5NLSHjF5aSmOj
	/g+JVLTHJj5ZxKGgoV0EqGy91+nWXhYr1QmzHSjX5WayUvSaOhoVgyFDX0+it7Pzgpq2X2kMo3b
	VQlKNyLXftAIIoN1LeM2UXyCclyNR/bhkciovDch6XWV7xyoagqOnaE47Nx+ZQSmxvl5ZW33C4j
	q2VHDl0izaeLSryND/2Ni67RPcUdhoWC4W3pWVQ5s+RxEZrxeY5pvqE8JJCN3Xw5uKGTS3nfFEe
	piAeC9c8aihpiCC8JO33irxJk77aFI6Vk/Qs6T3URRPSutgg=
X-Google-Smtp-Source: AGHT+IFTRGOiNdRzKSQme27JWqDxKOu/+FCYWooQW6C2iq/oPQ66OrYZa6CR5R0vvSq3RNS2fhpUwg==
X-Received: by 2002:a05:6000:26d2:b0:3a4:d0fe:42b2 with SMTP id ffacd0b85a97d-3a6ed631f38mr1716511f8f.19.1750846261143;
        Wed, 25 Jun 2025 03:11:01 -0700 (PDT)
Message-ID: <8767478f-aa4b-4be6-b942-c40f0281dee0@suse.com>
Date: Wed, 25 Jun 2025 12:10:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 4/4] x86/idle: Misc cleanup
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20250624163951.301743-1-andrew.cooper3@citrix.com>
 <20250624163951.301743-5-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20250624163951.301743-5-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 24.06.2025 18:39, Andrew Cooper wrote:
> Sort includes, and drop trailing whitespace.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Wed Jun 25 10:12:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 10:12:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024617.1400458 (Exim 4.92)
	(envelope-from )
	id 1uUN7c-0002Yu-9p; Wed, 25 Jun 2025 10:12:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024617.1400458; Wed, 25 Jun 2025 10:12: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 1uUN7c-0002Yn-71; Wed, 25 Jun 2025 10:12:52 +0000
Received: by outflank-mailman (input) for mailman id 1024617;
 Wed, 25 Jun 2025 10:12: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 1uUN7b-0002Yg-IW
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 10:12:51 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on2061f.outbound.protection.outlook.com
 [2a01:111:f403:200a::61f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f1638697-51ac-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 12:12:49 +0200 (CEST)
Received: from CH2PR02CA0027.namprd02.prod.outlook.com (2603:10b6:610:4e::37)
 by DM6PR12MB4091.namprd12.prod.outlook.com (2603:10b6:5:222::16) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.19; Wed, 25 Jun
 2025 10:12:44 +0000
Received: from CH2PEPF00000149.namprd02.prod.outlook.com
 (2603:10b6:610:4e:cafe::61) by CH2PR02CA0027.outlook.office365.com
 (2603:10b6:610:4e::37) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8857.30 via Frontend Transport; Wed,
 25 Jun 2025 10:12:44 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CH2PEPF00000149.mail.protection.outlook.com (10.167.244.106) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8880.14 via Frontend Transport; Wed, 25 Jun 2025 10:12:43 +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; Wed, 25 Jun
 2025 05:12:43 -0500
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, 25 Jun
 2025 05:12:42 -0500
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; Wed, 25 Jun 2025 05:12:41 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f1638697-51ac-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lr4hVe9KP3Q3AQtUxiu33Qo/mLRXFZ+a0nVOImWoTKn+VotUeGO20h+g29qXW+lTG9BhP8lP0xx/e/w2BTLRV7Wih+snmY93ZSXSDTbuWydZQdbdo8tZvUe/mGhXlqaFSiVxB0RQutapUABiwKtUESWRuVYXVT4vSY2ssM7vBSXsWwGD8te/4RDK6p4VDlAvTpox7+1NqrONzzqsLeF0iiGUAIa0op6ihaycxIa1myENtZIiJQR2dSw5rG5HeMYeTJH0oWExPVkLF6NFl0rQ4+ihqmfqhx9tTyL8w8KICimQtbchTGQ97oggy+EUubTItsWdeq56HN0ijR9VC+cyug==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Y3hiNFzxIQZ9mKBcULLnKYBwTI1NMIdUdy4GH33M5uc=;
 b=rZu6aj4dAu7FpSIeh9mqytc1hE716IZVQTxh1jYNTGtr5ATDjGmh60siMlCEGim0jm9dNz4t7mEWRNfHRn0PuH9pBXZFapq1Uts0Y5w/0MUz+coxhoPVmmG4A3k1hCDvNFvi6M1OFqgF753ABwCuSPB6BFR0f10as84Bia1Zeuc+0Ud2JOdPlxU3r6bpDkx6n3wM37y4SkuiVzdFq/38wmz5TyZ1g6/nUZDbSuqlNuIzH7/LSTU94WXhnwzxSUliCKP5gZMnZ7AfsJxqpWMIxzSLAxcWIDz9kQ5MCDp9+auYaFV/07REKL6XwMOreCFhtgVDQCz0C5MZryIS2nUzCg==
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=Y3hiNFzxIQZ9mKBcULLnKYBwTI1NMIdUdy4GH33M5uc=;
 b=Yps6SHg6MF/zrsLvULkNlyVBg6KHK/jzp+vcGUE3BQpaLAPNw74biHUy7ZGjoM8HTh22AoExNCB4jvqz0WSAHlM/s/rFFY8gWXzeAJZ/DLrPTYL9rdydEhye5mQf+OYRYRYBjS58S4aZVLtFhrtqeEDufHTChZZ2A5wR6BAjD/k=
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 , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Volodymyr Babchuk 
Subject: [PATCH] xen/arm: Fix booting hwdom/1:1 domU with CONFIG_GRANT_TABLE=n
Date: Wed, 25 Jun 2025 12:12:30 +0200
Message-ID: <20250625101230.49653-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 (SATLEXMB05.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PEPF00000149:EE_|DM6PR12MB4091:EE_
X-MS-Office365-Filtering-Correlation-Id: d7caad40-15da-4861-11dd-08ddb3d0d367
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?EbHbte8EpQUwes09fy0UWQcVAcZhfdJx4fDENVuSakyU1PtOaLVcDi4kmrW+?=
 =?us-ascii?Q?ceHgcvgjIW3RdPQD5Nv+oR1wzEQNHCWbI9CinGx+U2HjZACsWmsOvosPBODn?=
 =?us-ascii?Q?Vl0yQm5rQft+tpe9nMTRryzuckJW7QaMtiqoV63ozM3DFScU7NcUKNum1zxv?=
 =?us-ascii?Q?13hpj+KWRQS58x914SUX+5LrzVptiUqCSK3QDv/GFuNt+NzIxQiVCHqPhEOa?=
 =?us-ascii?Q?iQZVyaNW/eRLb2Ths1+tcRSvBBpm9lzNZvXGGXruIn3scG1BPlsFFyLvH08Z?=
 =?us-ascii?Q?2XtMvWIWFuzy0e2C7bXSJrzYcJZ873W+BbxBkS4LEIo0THUWrdvCzBMpF35i?=
 =?us-ascii?Q?7vIBy9g+qiaTTTjxol4J/su81s97AbI7LViWJ2bb3SjVBhvDGIXQgocOYvPC?=
 =?us-ascii?Q?fn0OzuAWCEl88l3wefHBQE5PzQC1F6XhKWV+SIlnwbTuVG86Q/sKmJdIUllv?=
 =?us-ascii?Q?50Qq82oD+HnK1Zqc8MkdGsHba6uVf6q7Y5BiV6mdyy57YYQ8I4DdikHa5bJt?=
 =?us-ascii?Q?q6ZMnuJuZCt/U3andHjCvkhuxF82yScg1a4veyaj33lEbYGLrdJRd3Z3dYTp?=
 =?us-ascii?Q?2+i2xbc3hnTk1E+V3Qn+YO1tzhu0O8bspjz3/4i0CJlcnKPsGIkm+E3drPYa?=
 =?us-ascii?Q?A0ArfgVi7muYK2T2noxzL0wngx8VwGdwMyW2G30AdODP9wzLXsneS3zKi5kI?=
 =?us-ascii?Q?GCoruhEHsUAZtVrT/8PyC6MdeYkOVrFgESaX8cRlo0hfAAQGzK7AW8i0dPzL?=
 =?us-ascii?Q?Bw40o7xnga5TUMzvbkiN8iF8Jr194KVik/dxpVsacmQ8QmirTO2Xnh996g0y?=
 =?us-ascii?Q?hwYArww8fCgcuucam/fdxh05uRsQl1yJ8Y8qmglHHGgbosUpZBHjwIaCABt2?=
 =?us-ascii?Q?Fxk9MBlrxj4pmcztSjZWR8W9mVEDVLcvIkBDPu1Exw2JaDVpEotCX60Gn10e?=
 =?us-ascii?Q?UPTUij1jS8UeAKNbu5DCw5ZiW0KCsFxkhm3NMTEPOa55nL5LdmTLxjXGn5oI?=
 =?us-ascii?Q?SZC5gi4fPSINVJYqoTv96KKN+4sPnrQxChAaYooF9UJT3QbQe7Nr5XKmYT+r?=
 =?us-ascii?Q?XbI76QSIjP16a8CXaTfsWhPVnab8dC8F71/m/xAYiHuLQ+vCxth17N6jyxaT?=
 =?us-ascii?Q?gtoJaqizmQS3WmkJmhfli2WRa7Lip7Vw85cv/COBZzgJ3EhORlTVnr4Ksxpz?=
 =?us-ascii?Q?xx1XpnBWndzDE2MD2h57I8burYlNuK6mVHBlFN1anz5HbAWN9L4QULVGZBp/?=
 =?us-ascii?Q?vjOpuq+vtSSrplq6exmPpMUA3bfPUXRIoIBOmaHsA33vo04fR7rO9uN9S/DD?=
 =?us-ascii?Q?gcnUFeLqNq1ZB3MXxvrAOlbr1Tm0aMKOrHNMALyHPiQp0hPQNR3u5rZN/Mot?=
 =?us-ascii?Q?OPzCuha3dIIQ2wM/HbhWQZiYwM1FZV/QI0pl6QGGUsZnj5OO9LZhUfNwmbKN?=
 =?us-ascii?Q?07awTwKu9tZXjETrOJCthZZ7w6ZMQLiblFxS7qIPBRlBafg3J4G394Ze13JR?=
 =?us-ascii?Q?w4RdflAwmxESzkZzxJEPIQ5t9K99ZvBsAQye?=
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: 25 Jun 2025 10:12:43.7229
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d7caad40-15da-4861-11dd-08ddb3d0d367
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:
	CH2PEPF00000149.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4091

At the moment, we unconditionally allocate space for grant table region
membank and add it in the membanks array to find_unallocated_memory() to
find unused memory. In case of CONFIG_GRANT_TABLE=n, the size of the
region is empty and assertion in rangeset_remove_range() fails when
booting hwdom or 1:1 domU without IOMMU. Example:

(XEN) Assertion 's <= e' failed at common/rangeset.c:189
...
(XEN) Xen call trace:
(XEN)    [<00000a0000218b5c>] rangeset_remove_range+0xbc/0x2d4 (PC)
(XEN)    [<00000a00002b8370>] find_unallocated_memory+0x140/0x208 (LR)
(XEN)    [<00000a00002cc28c>] make_hypervisor_node+0x310/0x7e0
...

Same issue would occur when booting hwdom with LLC coloring enabled.
Fix it by performing conditional allocation and configuration.

Signed-off-by: Michal Orzel 
---
 xen/arch/arm/domain_build.c           | 19 ++++++++++++-------
 xen/common/device-tree/domain-build.c |  7 ++++++-
 2 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 3f5c7c2e5aa8..04d3dca38a42 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1011,7 +1011,10 @@ static int __init find_host_extended_regions(const struct kernel_info *kinfo,
                                              struct membanks *ext_regions)
 {
     int res;
-    struct membanks *gnttab = membanks_xzalloc(1, MEMORY);
+    struct membanks *gnttab =
+        IS_ENABLED(CONFIG_GRANT_TABLE)
+        ? membanks_xzalloc(1, MEMORY)
+        : NULL;
     struct membanks *xen_reg =
         kinfo->xen_reg_assigned
         ? membanks_xzalloc(count_ranges(kinfo->xen_reg_assigned), MEMORY)
@@ -1037,12 +1040,6 @@ static int __init find_host_extended_regions(const struct kernel_info *kinfo,
 
     dt_dprintk("Find unallocated memory for extended regions\n");
 
-    if ( !gnttab )
-    {
-        res = -ENOMEM;
-        goto out;
-    }
-
     if ( kinfo->xen_reg_assigned )
     {
         if ( !xen_reg )
@@ -1056,9 +1053,17 @@ static int __init find_host_extended_regions(const struct kernel_info *kinfo,
                                rangeset_to_membank, xen_reg);
     }
 
+#ifdef CONFIG_GRANT_TABLE
+    if ( !gnttab )
+    {
+        res = -ENOMEM;
+        goto out;
+    }
+
     gnttab->nr_banks = 1;
     gnttab->bank[0].start = kinfo->gnttab_start;
     gnttab->bank[0].size = kinfo->gnttab_size;
+#endif
 
     res = find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_banks),
                                   ext_regions, add_ext_regions);
diff --git a/xen/common/device-tree/domain-build.c b/xen/common/device-tree/domain-build.c
index cd01a8b4bc9f..e6d7b8961e89 100644
--- a/xen/common/device-tree/domain-build.c
+++ b/xen/common/device-tree/domain-build.c
@@ -250,7 +250,10 @@ void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
      */
     if ( is_hardware_domain(d) )
     {
-        struct membanks *gnttab = membanks_xzalloc(1, MEMORY);
+        struct membanks *gnttab =
+            IS_ENABLED(CONFIG_GRANT_TABLE)
+            ? membanks_xzalloc(1, MEMORY)
+            : NULL;
         /*
          * Exclude the following regions:
          * 1) Remove reserved memory
@@ -261,12 +264,14 @@ void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
             gnttab,
         };
 
+#ifdef CONFIG_GRANT_TABLE
         if ( !gnttab )
             goto fail;
 
         gnttab->nr_banks = 1;
         gnttab->bank[0].start = kinfo->gnttab_start;
         gnttab->bank[0].size = kinfo->gnttab_size;
+#endif
 
         hwdom_free_mem = membanks_xzalloc(NR_MEM_BANKS, MEMORY);
         if ( !hwdom_free_mem )
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Wed Jun 25 10:16:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 10:16:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024628.1400467 (Exim 4.92)
	(envelope-from )
	id 1uUNAu-0003Co-TY; Wed, 25 Jun 2025 10:16:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024628.1400467; Wed, 25 Jun 2025 10: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 1uUNAu-0003Ch-Ql; Wed, 25 Jun 2025 10:16:16 +0000
Received: by outflank-mailman (input) for mailman id 1024628;
 Wed, 25 Jun 2025 10:16: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 1uUNAt-0003CZ-U5
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 10:16:16 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20625.outbound.protection.outlook.com
 [2a01:111:f403:2415::625])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6b50d21b-51ad-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 12:16:13 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by BL4PR12MB9723.namprd12.prod.outlook.com (2603:10b6:208:4ed::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Wed, 25 Jun
 2025 10:16: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%4]) with mapi id 15.20.8835.027; Wed, 25 Jun 2025
 10:16: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: 6b50d21b-51ad-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=m7w1oxyOvCWyxj9bLwa1JOsvN48X71Mtkmk1//z6G4RFU/F9WyLbyV6pBhFKao15Mx5xdnpBF7/PPWdpv/tjPpH1hiJnqML1xFKVvC2M5aTONKDpxuylyjbx6+FFAr02/isSgeyfAAOuJqtPrhwCYMi6LaYB1RiL/CXBAHkJJ013DDaZCOQWxt2MXXuriYBdjfA/slogI4DFsHhE/E8qfi10MxKA7BCryMjH/q56AS78/sPKMoglYTQ11lKi2L7r1OKWlVLer+F1XulVF+m7fRLktehhPiAFWddlOoEuo0qx2YIWvGAOa10vHDkmz1OCXB5aIXiXd7SBvt1qPvNkIw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=wRAasRSBI1oSj8pjEJ5i6ho6Luoo8aujRZGoQxaNo/Y=;
 b=Ln7czIQAdds4nIwKLYY3HSuDMsbtw/5HJBLMuxGi8hDaIXdKnLu7pXuKmUpGFqXG3gUZmvRNHOah6c9qZZ3YKv9QrBy1XqigX1iplnMDb6KFcvYvYHeM+eqA2Uo8tkZUtU+riNsKn794G+RCZ+rblLBWUeooHFlta1qqzGyQRMnGr/P2TQXZt7g2HjlVAXfP1X/qaO6/rYACIBX+Y5sNDuDU/CTE1DNr++Hf5XoN8i+/faO/Xdx0Bl/sehR6RYnTNJ3v9YiJd9X86B1NsKElzeCRcwMHCXFtMZBt9YfUfhrww2a9nGMjoi9YGo/skURXW3cN5uH45Pi6VPf8UMGZcw==
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=wRAasRSBI1oSj8pjEJ5i6ho6Luoo8aujRZGoQxaNo/Y=;
 b=BbXkFc/Au8VJf0BWiuiF2WiPTV3G8mMH/as+tE0hNW/8uRBEeaZTJLJzeGg4rK2ez4TaMkv6/dV9jTgQpUxKOK7CwIO7Sk7uNOR+1voI7+Ijy4eyEAZr9nZxIhNRV24A0ZXNERjDeH9t1cDn1uL3gIhmqUeKpeFs4bLZkXF4cvI=
From: "Chen, Jiqian" 
To: Jan Beulich 
CC: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Andrew Cooper
	, Anthony PERARD ,
	"Orzel, Michal" , Julien Grall ,
	Stefano Stabellini , "xen-devel@lists.xenproject.org"
	, "Huang, Ray" , "Chen,
 Jiqian" 
Subject: Re: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
Thread-Topic: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
Thread-Index:
 AQHb23yakGdVC9XxvEWnYcnp8zrTt7QI/QAAgAGa9QCAAQzVgIAG5D6A//99hgCAAJwoAP//hioAgAHew4D//5oCgAASTfCA//+FrwCAAIi+gA==
Date: Wed, 25 Jun 2025 10:16:09 +0000
Message-ID:
 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-3-Jiqian.Chen@amd.com>
 <516a3adc-320d-46ce-b235-8ef91469abcf@suse.com>
 
 <227df6d3-a2c3-4576-bde9-d8057c378e7a@suse.com>
 
 <5c4b186e-686e-4fc8-bcf1-854bc1f5ec8b@suse.com>
 
 <9d5d0e44-66c3-4e3f-8704-2c862c5f5aff@suse.com>
 
 <3638e73c-2a83-4164-9a84-839245245727@suse.com>
 
 <771cd5b7-2b89-49b1-9aba-8cd79319d3ce@suse.com>
In-Reply-To: <771cd5b7-2b89-49b1-9aba-8cd79319d3ce@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.8835.025)
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_|BL4PR12MB9723:EE_
x-ms-office365-filtering-correlation-id: 0367f957-dbfb-415e-f042-08ddb3d14e28
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?aEtzQWs1RmdyNmg2alNvSkY3bzdPOHJnMWZNT24yVzhHRHFnQmhrQTFnbUZN?=
 =?utf-8?B?bU13UmZ2T3Nrem1jQnlpeDR5cTh2bXN0RE9jelhOTjhXRW1oc1Z5SHRwOTE3?=
 =?utf-8?B?MVJzY1FUelRJNGN0cENkQU9NVDlxMkFxMUpsRzVIWXVZTmF4TjJsVXNwM3BU?=
 =?utf-8?B?UTN0V1FrSHBNNysxeHNmSW5ZWnM0OXlUbmNqWnlxd2RXZFc5NzRSRHFwSUhR?=
 =?utf-8?B?NmRFNThkM2cyVklmV09JUGcvdG9ZdWIzRjhFN0p3UmdlMVAvKzZNWVd0MWhq?=
 =?utf-8?B?T2RVUk5lSDZPcStrTGk2UXU2OXFYVmdMSkNuOFd4bzllR01DekNpTUg3bVdV?=
 =?utf-8?B?S01mdlBPaUcrTVd2K1FGMkpBT2Z1bzgrVG55c2FHdW50azBLR1FrOUFwNytr?=
 =?utf-8?B?TFRmN0Rnd2w2bFpONFVLcklkUVFQVFc5M01RS1pZUkNmK0pnZTFxNmZ1ajlx?=
 =?utf-8?B?K3RmdERBRjFFNVlscGNWdUFXTHdWZnhnalYwb2NMT2FmaEUxbHc4cTlDTVA1?=
 =?utf-8?B?VzRwOEJVWStNUzh4Z0dLRGxzZEdzOG1HempKdDVJbmJNY2t2ZmVacFZjZ2ZI?=
 =?utf-8?B?eXlSTEtuUDdxc3NuRmljSmJmYTJYZ215NkVJU0tUblQ4ZmpJQzVDOTFXeDEr?=
 =?utf-8?B?QXVCZjdqS2c4SWV5MFFlUzdsVjl6T1pnWDUzWVN3UnNFVWw3M3JZN2lvKy9X?=
 =?utf-8?B?ZFF0NHlJYlI4bzM4N1paZmFQWHIvR3JlSTcxWXRGMVEzdDBoS3U5enVldVFp?=
 =?utf-8?B?Y1pvSHlHcHJTSkJFVSsxS29VdXlOU2hFUitVaGtCOTJINGd4dGJtNFkxTG9D?=
 =?utf-8?B?ZVZhMGkwYktPNTZvemRNU1dycHhQTytNcDMvNzlWVUdBN3FGajAwMXIvbzhR?=
 =?utf-8?B?YXk4ZjZCUG4xNjljQ3A2YzNCQnFuTTd6amVzN1VIZkRsSWRzN1BsdUFYUmlO?=
 =?utf-8?B?bGt3bDFTUGpXTUc3a0R0WjJGb3QrNU5qbUdqQklHc2FDNDdDU01jcGxhTGhi?=
 =?utf-8?B?aUFSdS85eEg1eE9jaGd0Z1NyZjIzVkNsOXlnMStlSGRyUlI0YjdSOXZBdXA0?=
 =?utf-8?B?cmdWSU5LY1RJZlgrYlJaTmR3bjhSOGcvSDBUQ3BRNUhPRzl0T2VhMThnU2RR?=
 =?utf-8?B?VFVjZnJFUk5ZeFVGUGJpL205TGdFSGFIS2lvVW9rSnF1WXFvcjVoNFg0VUps?=
 =?utf-8?B?WExlZ04wbFV2ci94NXUvcjFld3pHU1lQTGJGMzFwb1RrQUdjWXZDaE5jb1hF?=
 =?utf-8?B?cFJ4Rzg1YmV2VVZpdVY4TTRDdGNKdUtCR0txWi9ScS9VZG96cXZFVi82OG9W?=
 =?utf-8?B?Z3EyOXVERnpBN3RsRVNkcUREdk9XRk9xc3RkSm9mck1Zay9yajJzdEpDYUU2?=
 =?utf-8?B?TEVUQXhsRTUyeGp2UHdoTWozWUU1R1lNSGxZN0p2cGhXZFZZUlNJekVKTUhu?=
 =?utf-8?B?MTBoazNrb3hTR0R5ck50SHg5VmR0V0YwdVdHTkk1TWMvK2k0M1F4cjRHWjVU?=
 =?utf-8?B?Qmk4eUxlZHBoVTVJRTRaSndWTmwwcERXY211Z1k0TWFwNmY2Y2FQOS9kazlH?=
 =?utf-8?B?ZVJVS1B1cjFLMU9TQW4xRVN1dkRBRmgxVjREVW8yQ1Z6WVY5cGE0eGRFbVVJ?=
 =?utf-8?B?WjBSQitMZld2aHM0dnZYTDRWb3BYY21CZFdNZ21WcWMwR3JYVHdwV2lNTUR0?=
 =?utf-8?B?YXdNek8wbnJpNnd2V2JjMXpzZWNHaGNRaGRlVitxL0NHZHpmRlhNUWVHeS9u?=
 =?utf-8?B?L3N4aVczdFl3MlJYcjE4NVh4N3cvaG4xa3lMUUtPVk0vWkdJMGd4ckYzOGVt?=
 =?utf-8?B?NklJVGc1RW9CaWNnekZSemVaekZtL3BGUElxZFpTTDEwenhuZW1idkdYaFNQ?=
 =?utf-8?B?UFd2WUtpOVdBeHJrWXU0bTl5UUVra3ZHOCtwVnF4WlJ6UnhJQlNiaEZQWWhm?=
 =?utf-8?B?M3pOL3ZheXEzbXVQdTB6L3ZHSmtZbEk0dmkrRDB1VDhNOVpWU2RVd1VnTWp5?=
 =?utf-8?Q?tPQhN5vW4PHnUitNN+wf6cxsQ9B0os=3D?=
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?Mi9oU01oU0crSmZQM3AzM3BUMzlPS1dMb1B2cE9ibDFtRGRnQW52dXhZWHpI?=
 =?utf-8?B?WUQxaGZ1UUR5Zi8rV0QwMThNcGkvZklBKzVTRWlBUmxzc2FFZzVYM1U1WUZP?=
 =?utf-8?B?alF4NHNnSVFqbDUvcnprWXhCTTRHR3gwbFRPMlpibStyZ3FpQ0R2b3l5cnhT?=
 =?utf-8?B?RFlYM1pNajRzVkxqVE9kdkFZWUJUZjZCUkRNWWVST2k3bmp5WEg2V2k3cWpU?=
 =?utf-8?B?Vk03Wjc1dkppYkpJRTMxcXVEazFVZURIbHFMTGFLdjl2TE9rSEFrMEJ6dEZw?=
 =?utf-8?B?M3R2OXRQZWNwMkFXVUtBSUw1OHE5aElyQURFc3ppS0tpdTlHVm8wSTVtd0Zt?=
 =?utf-8?B?dVJjdTI1U0xnNys2RGh6eVhmeU0zYWMwWjM3ZmI5THU4OUFnaUZVNXdyWkpj?=
 =?utf-8?B?MTRIOVI0NjlwTityWndjdWRuZ1djR0RpWlZQSHdpZFJtcE5TbzhJeTFoWXVW?=
 =?utf-8?B?dVpaQzJRT0Zjci9RN0JYYUpqbVRPelUydnFCSWRabFVPRlpubzJUNHdxZVpM?=
 =?utf-8?B?VXJuRXJhQlgvblZoQ2NsbXhsTVlFTUp0QnBTZFV6d2hBK3FQNjhuYm55T0ZO?=
 =?utf-8?B?M0hpTzh4NVVLT3FpMjlIVzl2azJ3YmJVOHI5ZVVpbTBrbFBpTHFrdzFqU0sy?=
 =?utf-8?B?aUF6TmF4N2swZlM1WTRJU3ZLL251NWRDeDR4elVoRE5XdHZ3SVMzZDhxSTdk?=
 =?utf-8?B?T3ZuZGNjNWhzdDErNy9zMm9qL0Z1eUdaakRxdVpkY1RVcE81dzk3VWNGT0R3?=
 =?utf-8?B?YkFrM2UyQnNiQVNKZy9UN3JubW51ZTdKSnRiamRlSFV4TUt2SExyKzlOVkFL?=
 =?utf-8?B?cVh2cnZqRnpOS1hsaHF6dEJHK3EwYS9nNm4wQ2huaUNHTjZBcDhZWlJPeGYw?=
 =?utf-8?B?WW5SSWFwTnNXQjZGV3hMLzc1cEhhNUtXTzFJWGFabnFqMmRnRmR6aEEzTHhj?=
 =?utf-8?B?UnFrekZhK0JnQ2JsRXg0Z1VPTTFVS2ZkTmlnN05oWi9OL2pDaE9hRmVIQzgw?=
 =?utf-8?B?YUN5NEJyWEE2SDNwVnU1Q0d4b08yTzBIMUpSTUVwdk9iYVVITjBzcGRnUGRX?=
 =?utf-8?B?ZVdwL0FZSFRTVy9teC8xOCt6akp1MVdZeUZOTlJXdHdZVC9qTXVOMTdldHhH?=
 =?utf-8?B?VFhGVlZJVTNoL0lzajR5WlphYi9Sd1Vadk1EMlEzc1d5SjBzY2svcXJIdmxR?=
 =?utf-8?B?NlVrYjJJM2pjZ0VzbHFPY1AxeXpTcjN1YXZkNkZIaER2cWhuZ1B0a21udDZ4?=
 =?utf-8?B?ZzVaT3ZGb2dYWkZHVmVqczdEUTdpUVFuTDI4Wmx1U3hNWVI4K0dSMXF2WFFM?=
 =?utf-8?B?cTlVM3FhZGF5d0x2ZjRSVzIyeDJ2RVZ3OUFIUTFxK0JNNUZOSVFLTGtRaTR4?=
 =?utf-8?B?RllGdDk0ZmpUVzJnQU5odkZkTmUxTUNVbjgzR1N4QmlsNXFWamxzWm9NL0hB?=
 =?utf-8?B?TlF0aFlHOGhnZlhIcGN5Y1JjR3Q4UU82cDN4WmlKSnlra0pUYlBCUWVHNjU0?=
 =?utf-8?B?QlduS2JVUUlLbXVtSTVaMnNzdkJPbzh5NFNOaUo2WFZQWXA3clhnYXhQQ0s2?=
 =?utf-8?B?YnlHLzBwWjE5cm5kbFlRbEMzRVFoTzUxV0pKQ3RQSXpzQjJzMVdoekhoSCs4?=
 =?utf-8?B?dEZjaHY3ZlpaQXptd0wzdS9ST0E4WWxHT2I3Y3VmVXhRUXVjWlYyMExKTTJx?=
 =?utf-8?B?WE50Q3ZtWEpLYWpDYXg3UUsyOHJlVytPZlVwdXphdS81RVo5R2dhUUI3TGRQ?=
 =?utf-8?B?Q1dVdXgwWTNQK1c0QWhwbVYxdjJCM25jQTZTenp2S1B1T0dSVndIekcxQ1NH?=
 =?utf-8?B?U1h0eHI4Z242Z1Z5ZjJTcThvMS9KM095Q2prbjZXWmFzQUNuck9tWndmSVY1?=
 =?utf-8?B?QkJGY0FUMmJZY0MyT3gzMXp6V2k2eG5UMnB4cTI0amJ0YkRBMktCNDNRcGVP?=
 =?utf-8?B?OHdHVzFDeWt4a1pRZUNjZFd2Wld0WHhKZVN2Wjh3VjN5QnY4M3Q1R3lRd21y?=
 =?utf-8?B?NXJpMTZsRUlPeHI4V082MVRkZ29QTXhKRUpiQ21Bc2hrMjFrU2JCWktTR2Fl?=
 =?utf-8?B?SlFsSHlwZ3I2V05VQmxzaVBjaDBndzVmb1dNekR4aytORjRoc2FMOW9IWXZE?=
 =?utf-8?Q?o/pc=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <256A2C7757B089499046157518BF557E@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: 0367f957-dbfb-415e-f042-08ddb3d14e28
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2025 10:16:09.6756
 (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: PRiDQFAT5W1d6cLDwxmYcwCDuDeruVAfTS/2lbiSc5mVVL1EfXjIOu91XYQVxiI2CiULFmSqUtIISaxbvSQirA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL4PR12MB9723

T24gMjAyNS82LzI1IDE4OjAzLCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMjUuMDYuMjAyNSAx
MToyNywgQ2hlbiwgSmlxaWFuIHdyb3RlOg0KPj4gT24gMjAyNS82LzI1IDE2OjM2LCBKYW4gQmV1
bGljaCB3cm90ZToNCj4+PiBPbiAyNS4wNi4yMDI1IDA4OjUxLCBDaGVuLCBKaXFpYW4gd3JvdGU6
DQo+Pj4+IE9uIDIwMjUvNi8yNCAxODowOCwgSmFuIEJldWxpY2ggd3JvdGU6DQo+Pj4+PiBPbiAy
NC4wNi4yMDI1IDExOjI5LCBDaGVuLCBKaXFpYW4gd3JvdGU6DQo+Pj4+Pj4gT24gMjAyNS82LzI0
IDE2OjA1LCBKYW4gQmV1bGljaCB3cm90ZToNCj4+Pj4+Pj4gT24gMjQuMDYuMjAyNSAxMDowMiwg
Q2hlbiwgSmlxaWFuIHdyb3RlOg0KPj4+Pj4+Pj4gT24gMjAyNS82LzIwIDE0OjM4LCBKYW4gQmV1
bGljaCB3cm90ZToNCj4+Pj4+Pj4+PiBPbiAxOS4wNi4yMDI1IDA4OjM5LCBDaGVuLCBKaXFpYW4g
d3JvdGU6DQo+Pj4+Pj4+Pj4+IE9uIDIwMjUvNi8xOCAyMjowNSwgSmFuIEJldWxpY2ggd3JvdGU6
DQo+Pj4+Pj4+Pj4+PiBPbiAxMi4wNi4yMDI1IDExOjI5LCBKaXFpYW4gQ2hlbiB3cm90ZToNCj4+
Pj4+Pj4+Pj4+PiBAQCAtMjksOSArMzAsMjIgQEAgdHlwZWRlZiBpbnQgdnBjaV9yZWdpc3Rlcl9p
bml0X3Qoc3RydWN0IHBjaV9kZXYgKmRldik7DQo+Pj4+Pj4+Pj4+Pj4gICAqLw0KPj4+Pj4+Pj4+
Pj4+ICAjZGVmaW5lIFZQQ0lfTUFYX1ZJUlRfREVWICAgICAgIChQQ0lfU0xPVCh+MCkgKyAxKQ0K
Pj4+Pj4+Pj4+Pj4+ICANCj4+Pj4+Pj4+Pj4+PiAtI2RlZmluZSBSRUdJU1RFUl9WUENJX0lOSVQo
eCwgcCkgICAgICAgICAgICAgICAgXA0KPj4+Pj4+Pj4+Pj4+IC0gIHN0YXRpYyB2cGNpX3JlZ2lz
dGVyX2luaXRfdCAqY29uc3QgeCMjX2VudHJ5ICBcDQo+Pj4+Pj4+Pj4+Pj4gLSAgICAgICAgICAg
ICAgIF9fdXNlZF9zZWN0aW9uKCIuZGF0YS52cGNpLiIgcCkgPSAoeCkNCj4+Pj4+Pj4+Pj4+PiAr
I2RlZmluZSBSRUdJU1RFUl9WUENJX0NBUEFCSUxJVFkoY2FwLCBmaW5pdCwgZmNsZWFuLCBleHQp
IFwNCj4+Pj4+Pj4+Pj4+PiArICAgIHN0YXRpYyBjb25zdCB2cGNpX2NhcGFiaWxpdHlfdCBmaW5p
dCMjX3QgPSB7IFwNCj4+Pj4+Pj4+Pj4+PiArICAgICAgICAuaWQgPSAoY2FwKSwgXA0KPj4+Pj4+
Pj4+Pj4+ICsgICAgICAgIC5pbml0ID0gKGZpbml0KSwgXA0KPj4+Pj4+Pj4+Pj4+ICsgICAgICAg
IC5jbGVhbnVwID0gKGZjbGVhbiksIFwNCj4+Pj4+Pj4+Pj4+PiArICAgICAgICAuaXNfZXh0ID0g
KGV4dCksIFwNCj4+Pj4+Pj4+Pj4+PiArICAgIH07IFwNCj4+Pj4+Pj4+Pj4+PiArICAgIHN0YXRp
YyBjb25zdCB2cGNpX2NhcGFiaWxpdHlfdCAqY29uc3QgZmluaXQjI19lbnRyeSAgXA0KPj4+Pj4+
Pj4+Pj4+ICsgICAgICAgIF9fdXNlZF9zZWN0aW9uKCIuZGF0YS5yZWwucm8udnBjaSIpID0gJmZp
bml0IyNfdA0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IENvdWxkIHlvdSByZW1pbmQgbWUgd2h5
IHRoZSBleHRyYSBsZXZlbCBvZiBpbmRpcmVjdGlvbiBpcyBuZWNlc3NhcnkgaGVyZT8NCj4+Pj4+
Pj4+Pj4+IFRoYXQgaXMsIHdoeSBjYW4ndCAuZGF0YS5yZWwucm8udnBjaSBiZSBhbiBhcnJheSBv
ZiB2cGNpX2NhcGFiaWxpdHlfdD8NCj4+Pj4+Pj4+Pj4gWW91IG1lYW4gSSBzaG91bGQgY2hhbmdl
IHRvIGJlOg0KPj4+Pj4+Pj4+PiAjZGVmaW5lIFJFR0lTVEVSX1ZQQ0lfQ0FQQUJJTElUWShjYXAs
IGZpbml0LCBmY2xlYW4sIGV4dCkgXA0KPj4+Pj4+Pj4+PiAgICAgc3RhdGljIGNvbnN0IHZwY2lf
Y2FwYWJpbGl0eV90IGZpbml0IyNfdCBcDQo+Pj4+Pj4+Pj4+ICAgICAgICAgX191c2VkX3NlY3Rp
b24oIi5kYXRhLnJlbC5yby52cGNpIikgPSB7IFwNCj4+Pj4+Pj4+Pj4gICAgICAgICAuaWQgPSAo
Y2FwKSwgXA0KPj4+Pj4+Pj4+PiAgICAgICAgIC5pbml0ID0gKGZpbml0KSwgXA0KPj4+Pj4+Pj4+
PiAgICAgICAgIC5jbGVhbnVwID0gKGZjbGVhbiksIFwNCj4+Pj4+Pj4+Pj4gICAgICAgICAuaXNf
ZXh0ID0gKGV4dCksIFwNCj4+Pj4+Pj4+Pj4gICAgIH0NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4g
UmlnaHQ/DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBZZXMsIHN1YmplY3QgdG8gdGhlIGVhcmxpZXIg
Y29tbWVudHMgb24gdGhlIGlkZW50aWZpZXIgY2hvaWNlLg0KPj4+Pj4+Pj4gR290IGl0Lg0KPj4+
Pj4+Pj4gT25lIG1vcmUgcXVlc3Rpb24sIGlmIGNoYW5nZSB0byBiZSB0aGF0LCB0aGVuIGhvdyBz
aG91bGQgSSBtb2RpZnkgdGhlIGRlZmluaXRpb24gb2YgVlBDSV9BUlJBWT8NCj4+Pj4+Pj4+IElz
IFBPSU5URVJfQUxJR04gc3RpbGwgcmlnaHQ/DQo+Pj4+Pj4+DQo+Pj4+Pj4+IFllcy4gVGhlIHN0
cnVjdCBkb2Vzbid0IHJlcXVpcmUgYmlnZ2VyIGFsaWdubWVudCBhZmFpY3MuIChJbiBmYWN0IGlu
IHByaW5jaXBsZQ0KPj4+Pj4+PiBubyBhbGlnbm1lbnQgc2hvdWxkIG5lZWQgc3BlY2lmeWluZyB0
aGVyZSwgZXhjZXB0IHRoYXQgdGhpcyB3b3VsZCByZXF1aXJlDQo+Pj4+Pj4+IGtlZXBpbmcgdGhl
IHNlY3Rpb24gc2VwYXJhdGUgaW4gdGhlIGZpbmFsIGltYWdlLiBXaGljaCBJIGRvbid0IHRoaW5r
IHdlIHdhbnQuKQ0KPj4+Pj4+Pg0KPj4+Pj4+Pj4gU2luY2UgSSBlbmNvdW50ZXJlZCBlcnJvcnMg
dGhhdCB0aGUgdmFsdWVzIG9mIF9fc3RhcnRfdnBjaV9hcnJheSBhcmUgbm90IHJpZ2h0IHdoZW4g
SSB1c2UgdGhlbSBpbiB2cGNpX2luaXRfY2FwYWJpbGl0aWVzKCkuDQo+Pj4+Pj4+DQo+Pj4+Pj4+
IERldGFpbHMgcGxlYXNlLg0KPj4+Pj4+IEFmdGVyIGNoYW5naW5nIF9fc3RhcnRfdnBjaV9hcnJh
eSB0byBiZSB2cGNpX2NhcGFiaWxpdHlfdCBhcnJheSwgY29kZXMgd2lsbCBiZSAobWF5YmUgSSBt
b2RpZmllZCB3cm9uZyBzb21ld2hlcmUpOg0KPj4+Pj4+DQo+Pj4+Pj4gZGlmZiAtLWdpdCBhL3hl
bi9kcml2ZXJzL3ZwY2kvdnBjaS5jIGIveGVuL2RyaXZlcnMvdnBjaS92cGNpLmMNCj4+Pj4+PiBp
bmRleCBjNTFiYmI4YWJiMTkuLjlmMmY0MzhiNGZkZCAxMDA2NDQNCj4+Pj4+PiAtLS0gYS94ZW4v
ZHJpdmVycy92cGNpL3ZwY2kuYw0KPj4+Pj4+ICsrKyBiL3hlbi9kcml2ZXJzL3ZwY2kvdnBjaS5j
DQo+Pj4+Pj4gQEAgLTM2LDggKzM2LDggQEAgc3RydWN0IHZwY2lfcmVnaXN0ZXIgew0KPj4+Pj4+
ICB9Ow0KPj4+Pj4+DQo+Pj4+Pj4gICNpZmRlZiBfX1hFTl9fDQo+Pj4+Pj4gLWV4dGVybiBjb25z
dCB2cGNpX2NhcGFiaWxpdHlfdCAqY29uc3QgX19zdGFydF92cGNpX2FycmF5W107DQo+Pj4+Pj4g
LWV4dGVybiBjb25zdCB2cGNpX2NhcGFiaWxpdHlfdCAqY29uc3QgX19lbmRfdnBjaV9hcnJheVtd
Ow0KPj4+Pj4+ICtleHRlcm4gdnBjaV9jYXBhYmlsaXR5X3QgX19zdGFydF92cGNpX2FycmF5W107
DQo+Pj4+Pj4gK2V4dGVybiB2cGNpX2NhcGFiaWxpdHlfdCBfX2VuZF92cGNpX2FycmF5W107DQo+
Pj4+Pg0KPj4+Pj4gSnVzdCBmeWk6IFlvdSBsb3N0IGNvbnN0IGhlcmUuDQo+Pj4+Pg0KPj4+Pj4+
IEBAIC0yNTUsNyArMjU1LDcgQEAgc3RhdGljIGludCB2cGNpX2luaXRfY2FwYWJpbGl0aWVzKHN0
cnVjdCBwY2lfZGV2ICpwZGV2KQ0KPj4+Pj4+ICB7DQo+Pj4+Pj4gICAgICBmb3IgKCB1bnNpZ25l
ZCBpbnQgaSA9IDA7IGkgPCBOVU1fVlBDSV9JTklUOyBpKysgKQ0KPj4+Pj4+ICAgICAgew0KPj4+
Pj4+IC0gICAgICAgIGNvbnN0IHZwY2lfY2FwYWJpbGl0eV90ICpjYXBhYmlsaXR5ID0gX19zdGFy
dF92cGNpX2FycmF5W2ldOw0KPj4+Pj4+ICsgICAgICAgIGNvbnN0IHZwY2lfY2FwYWJpbGl0eV90
ICpjYXBhYmlsaXR5ID0gJl9fc3RhcnRfdnBjaV9hcnJheVtpXTsNCj4+Pj4+PiAgICAgICAgICBj
b25zdCB1bnNpZ25lZCBpbnQgY2FwID0gY2FwYWJpbGl0eS0+aWQ7DQo+Pj4+Pj4gICAgICAgICAg
Y29uc3QgYm9vbCBpc19leHQgPSBjYXBhYmlsaXR5LT5pc19leHQ7DQo+Pj4+Pj4gICAgICAgICAg
aW50IHJjOw0KPj4+Pj4+IGRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS94ZW4vdnBjaS5oIGIveGVu
L2luY2x1ZGUveGVuL3ZwY2kuaA0KPj4+Pj4+IGluZGV4IGY0ZWMxYzI1OTIyZC4uNzc3NTBkZDQx
MzFhIDEwMDY0NA0KPj4+Pj4+IC0tLSBhL3hlbi9pbmNsdWRlL3hlbi92cGNpLmgNCj4+Pj4+PiAr
KysgYi94ZW4vaW5jbHVkZS94ZW4vdnBjaS5oDQo+Pj4+Pj4gQEAgLTMxLDE0ICszMSwxMyBAQCB0
eXBlZGVmIHN0cnVjdCB7DQo+Pj4+Pj4gICNkZWZpbmUgVlBDSV9NQVhfVklSVF9ERVYgICAgICAg
KFBDSV9TTE9UKH4wKSArIDEpDQo+Pj4+Pj4NCj4+Pj4+PiAgI2RlZmluZSBSRUdJU1RFUl9WUENJ
X0NBUEFCSUxJVFkoY2FwLCBmaW5pdCwgZmNsZWFuLCBleHQpIFwNCj4+Pj4+PiAtICAgIHN0YXRp
YyBjb25zdCB2cGNpX2NhcGFiaWxpdHlfdCBmaW5pdCMjX3QgPSB7IFwNCj4+Pj4+PiArICAgIHN0
YXRpYyB2cGNpX2NhcGFiaWxpdHlfdCBmaW5pdCMjX2VudHJ5IFwNCj4+Pj4+PiArICAgICAgICBf
X3VzZWRfc2VjdGlvbigiLmRhdGEucmVsLnJvLnZwY2kiKSA9IHsgXA0KPj4+Pj4+ICAgICAgICAg
IC5pZCA9IChjYXApLCBcDQo+Pj4+Pj4gICAgICAgICAgLmluaXQgPSAoZmluaXQpLCBcDQo+Pj4+
Pj4gICAgICAgICAgLmNsZWFudXAgPSAoZmNsZWFuKSwgXA0KPj4+Pj4+ICAgICAgICAgIC5pc19l
eHQgPSAoZXh0KSwgXA0KPj4+Pj4+IC0gICAgfTsgXA0KPj4+Pj4+IC0gICAgc3RhdGljIGNvbnN0
IHZwY2lfY2FwYWJpbGl0eV90ICpjb25zdCBmaW5pdCMjX2VudHJ5ICBcDQo+Pj4+Pj4gLSAgICAg
ICAgX191c2VkX3NlY3Rpb24oIi5kYXRhLnJlbC5yby52cGNpIikgPSAmZmluaXQjI190DQo+Pj4+
Pj4gKyAgICB9DQo+Pj4+Pj4NCj4+Pj4+PiAgI2RlZmluZSBSRUdJU1RFUl9WUENJX0NBUChjYXAs
IGZpbml0LCBmY2xlYW4pIFwNCj4+Pj4+PiAgICAgIFJFR0lTVEVSX1ZQQ0lfQ0FQQUJJTElUWShj
YXAsIGZpbml0LCBmY2xlYW4sIGZhbHNlKQ0KPj4+Pj4+DQo+Pj4+Pj4gSSBwcmludCB0aGUgdmFs
dWUgb2YgTlVNX1ZQQ0lfSU5JVCwgaXQgaXMgYSBzdHJhbmdlIG51bWJlciAoNjE0ODkxNDY5MTIz
NjUxNzIwOSkuDQo+Pj4+Pg0KPj4+Pj4gV2hhdCBhcmUgdGhlIGFkZHJlc3NlcyBvZiB0aGUgdHdv
IHN5bWJvbHMgX19zdGFydF92cGNpX2FycmF5IGFuZCBfX2VuZF92cGNpX2FycmF5Pw0KPj4+PiBf
X2VuZF92cGNpX2FycmF5IGlzIDB4ZmZmZjgyZDA0MDQyNTFiOA0KPj4+PiBfX3N0YXJ0X3ZwY2lf
YXJyYXkgaXMgMHhmZmZmODJkMDQwNDI1MTYwDQo+Pj4+IE5VTV9WUENJX0lOSVQgaXMgMHg1NTU1
NTU1NTU1NTU1NTU5DQo+Pj4+IHNpemVvZih2cGNpX2NhcGFiaWxpdHlfdCkgaXMgMHgxOA0KPj4+
DQo+Pj4gT2gsIG9mIGNvdXJzZSAtIHRoZXJlJ3MgYSBwc0FCSSBwZWN1bGlhcml0eSB0aGF0IHlv
dSBydW4gaW50byBoZXJlOiBBZ2dyZWdhdGVzDQo+Pj4gbGFyZ2VyIHRoYW4gOCBieXRlcyBhcmUg
cmVxdWlyZWQgdG8gaGF2ZSAxNi1ieXRlIGFsaWdubWVudC4gSGVuY2Ugd2hpbGUNCj4+PiBzaXpl
b2YoKSA9PSAweDE4IGFuZCBfX2FsaWdub2YoKSA9PSA4LCB0aGUgc2VjdGlvbiBjb250cmlidXRp
b25zIHN0aWxsIGFyZQ0KPj4+IGFjY29tcGFuaWVkIGJ5ICIuYWxpZ24gMTYiLCBhbmQgdGh1cyBy
ZXNwZWN0aXZlIHBhZGRpbmcgaXMgaW5zZXJ0ZWQgYnkNCj4+PiBhc3NlbWJsZXIgYW5kIGxpbmtl
ci4gSU9XIHlvdSBlbmQgdXAgd2l0aCB0d28gMzItYnl0ZSBlbnRyaWVzIGFuZCBhIHRyYWlsaW5n
DQo+Pj4gMjQtYnl0ZSBvbmUuIFRoZSBlYXNpZXN0IChhbmQgbGVhc3QgcHJvYmxlbWF0aWMgZ29p
bmcgZm9yd2FyZCkgYXBwcm9hY2ggdG8NCj4+PiBkZWFsIHdpdGggdGhhdCBpcyBwcm9iYWJseSBn
b2luZyB0byBiZSB0byBhZGQgX19hbGlnbmVkKDE2KSB0byB0aGUgc3RydWN0DQo+Pj4gZGVjbC4g
KFdoZXRoZXIgdG8gbGltaXQgdGhpcyB0byBqdXN0IHg4NiBJJ20gbm90IHN1cmU6IFdoaWxlIG90
aGVyIHBzQUJJLXMgbWF5DQo+Pj4gYmUgZGlmZmVyZW50IGluIHRoaXMgcmVnYXJkLCB3ZSBtYXkg
d2FudCB0byBiZSBvbiB0aGUgc2FmZSBzaWRlLikNCj4+IFRoYW5rcyBmb3IgeW91IGRldGFpbGVk
IGV4cGxhbmF0aW9uLg0KPj4gSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgSSBuZWVkIHRvIGNo
YW5nZSB0aGUgZGVmaW5pdGlvbiBvZiB2cGNpX2NhcGFiaWxpdHlfdCB0byBiZToNCj4+DQo+PiB0
eXBlZGVmIHN0cnVjdCB7DQo+PiAgICAgdW5zaWduZWQgaW50IGlkOw0KPj4gICAgIGJvb2wgaXNf
ZXh0Ow0KPj4gICAgIGludCAoKiBpbml0KShjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldik7DQo+
PiAgICAgaW50ICgqIGNsZWFudXApKGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZGV2KTsNCj4+IH0N
Cj4+ICNpZmRlZiBDT05GSUdfWDg2DQo+PiBfX2FsaWduZWQoMTYpDQo+PiAjZW5kaWYNCj4+IHZw
Y2lfY2FwYWJpbGl0eV90Ow0KPiANCj4gWW91J2xsIG5lZWQgdG8gY2hlY2sgd2hldGhlciB0aGlz
IGhhcyB0aGUgaW50ZW5kZWQgZWZmZWN0LiBUaGVyZSBhcmUgeWV0IG1vcmUNCj4gcGVjdWxpYXJp
dGllcyB3aGVuIGl0IGNvbWVzIHRvIGF0dHJpYnV0ZXMgb24gc3RydWN0cywgdHlwZWRlZnMsIGFu
ZCB0aGUNCj4gY29tYmluYXRpb24gb2YgdGhlIHR3by4gSSB3b25kZXIgdGhvdWdoOiBEbyB3ZSBy
ZWFsbHkgbmVlZCBhIHR5cGVkZWYgaGVyZT8NCj4gR29pbmcgd2l0aCBqdXN0IHN0cnVjdCB2Y3Bp
X2NhcGFiaWxpdHkgd291bGQgZWxpbWluYXRlIGNvbmNlcm5zIG92ZXIgdGhvc2UNCj4gcGVjdWxp
YXJpdGllcy4NClllcywgb24geDg2IHRoaXMgd29ya3Mgbm93Lg0KQXMgZm9yIHRoZSB0eXBlZGVm
LCB0aGF0J3MgZmluZSBmb3IgbWUgdG8ganVzdCB1c2Ugc3RydWN0IHZwY2lfY2FwYWJpbGl0eS4N
Cg0KPiANCj4gQWxzbywgYXMgc2FpZCAtIHlvdSB3aWxsIG5lZWQgdG8gY2hlY2sgd2hldGhlciBv
dGhlciBhcmNoaXRlY3R1cmVzIGFyZQ0KPiBkaWZmZXJlbnQgZnJvbSB4ODYtNjQgaW4gdGhpcyBy
ZWdhcmQuIFdlIGJldHRlciB3b3VsZG4ndCBsZWF2ZSBhIHRyYXAgaGVyZSwNCj4gZm9yIHRoZW0g
dG8gZmFsbCBpbnRvIHdoZW4gdGhleSBlbmFibGUgdlBDSSBzdXBwb3J0LiBJLmUuIG15IHJlY29t
bWVuZGF0aW9uDQo+IHdvdWxkIGJlIHRoYXQgaWYgaW4gZG91YnQsIHdlIHB1dCB0aGUgX19hbGln
bmVkKCkgdGhlcmUgdW5jb25kaXRpb25hbGx5Lg0KVGhhdCdzIGRpZmZpY3VsdCBmb3IgbWUgdG8g
Y2hlY2sgb24gYWxsIGRpZmZlcmVudCBwbGF0Zm9ybXMgc2luY2UgSSBkb24ndCBoYXZlIHRoZW0g
YWxsLg0KU28geW91IG1lYW4gSSBzaG91bGQgcmVtb3ZlICIjaWZkZWYgQ09ORklHX1g4NiI/IEp1
c3QgbGV0IF9fYWxpZ25lZCgxNikgZm9yIGFsbCBwbGF0Zm9ybXM/DQoNCj4gDQo+IEphbg0KDQot
LSANCkJlc3QgcmVnYXJkcywNCkppcWlhbiBDaGVuLg0K


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 10:27:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 10:27:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024650.1400478 (Exim 4.92)
	(envelope-from )
	id 1uUNLP-00058D-Rt; Wed, 25 Jun 2025 10:27:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024650.1400478; Wed, 25 Jun 2025 10:27:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUNLP-000586-Oa; Wed, 25 Jun 2025 10:27:07 +0000
Received: by outflank-mailman (input) for mailman id 1024650;
 Wed, 25 Jun 2025 10:27: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 1uUNLO-000580-2z
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 10:27:06 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20605.outbound.protection.outlook.com
 [2a01:111:f403:2416::605])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id eea7385b-51ae-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 12:27:03 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by BL4PR12MB9723.namprd12.prod.outlook.com (2603:10b6:208:4ed::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Wed, 25 Jun
 2025 10:26:57 +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.8835.027; Wed, 25 Jun 2025
 10:26: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: eea7385b-51ae-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=SkmMEaSxKt2TTm+kZ8AX5XbgC6QmwsBzaOmNWumUoi4Xew9fI2Q38h74n/lihAnU4W6d2faq6MQ4yyJ3wLsHgSQBwPLHAtGvPT7STY11Uv4peewCQ6BFqwMXjf8LIX/DzS81136XjnrHhKMR7KEyvPTDCJNbTEjGuUPsV4KCbtTncb5O2hzeRKh7j/+kGoi+wLJ+mJc64aI1vEZ8AkViXkwUd35TbomMYjTjxtzZbicrot3+GC+2nurWkaM8V303DCdWRnTd29qUc1+x8uS8Dr70uhNnG6pOd4x0hFEZogxMGHJ79HTJjN+0nxbkgc5g2/eTc6//1GHX8h4K8g7o2A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Io2TwqX1crxotawNmhDF7I+Z3FoCJZvQSMAHAUAtCsw=;
 b=R3o9bOQeY4ZsyUNL/RdnodBkxgJoyNEx2euxn22bbSQYsJsS9Tia3KXPxOUgxfRGb7vJPvcL4ibJfqHS4Wz5OHuhaXPSwCZle1VQ7HRgpx6OUB3zNHX+k2bTlPiBKESZaKPibk6HHrhR7Pq2eD2gZIUNgTngyHNMCGLL/+klwsNZ3O/seEsN6PTz0QbXUyQ3/MHS7Rnm1LWcjq1zgwoXC8VAfDefU88fDRart4p4XphrLX8LzO1K1omCoOMgfJoEWFY/OefCKoyFWsiy2DScGB+zCqGXRd4085yHAagNuGWxBaVhC/vzn6B4TOzQTQaBBRDwGHHj3WB9Os3t6uFPiQ==
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=Io2TwqX1crxotawNmhDF7I+Z3FoCJZvQSMAHAUAtCsw=;
 b=2N6o9x8CQW+eXDxZpWz2ZuqTHM+u6mS98U5z+kw+VQHyO3dbq4vZeKLDuzCXiYFRAguJKVyVziW8nntsuUPWAe5ykjte8GDR/PEncgOaCwjyZoLs9BKJKjukPjfH0oDzjUed0ClWy8W+r+I9eBnwIwmEYFBI+Q76tONtLpBcPYg=
From: "Chen, Jiqian" 
To: Jan Beulich 
CC: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= ,
	"xen-devel@lists.xenproject.org" , "Huang,
 Ray" , "Chen, Jiqian" 
Subject: Re: [PATCH v6 7/8] vpci/msi: Free MSI resources when init_msi() fails
Thread-Topic: [PATCH v6 7/8] vpci/msi: Free MSI resources when init_msi()
 fails
Thread-Index:
 AQHb23yeMT8YFCMR3kaLDqQP1+DTK7QJCD4AgAme+gD//4QlAIAB4iSA//+e0YCAAIz0gP//gkiAABEx5YA=
Date: Wed, 25 Jun 2025 10:26:57 +0000
Message-ID:
 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-8-Jiqian.Chen@amd.com>
 <773c448a-d814-458f-ad83-e9740e724408@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.8835.025)
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_|BL4PR12MB9723:EE_
x-ms-office365-filtering-correlation-id: 3f6014e8-9133-4f0c-d3cd-08ddb3d2d062
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?cElWbWs2cXp4bDFqVHNETnR3MGMyNVhwT1NFN0pPenhOMHdaaVNHZjJNcmJK?=
 =?utf-8?B?N3BSeVhQZEhiYVF1dmZZTjhpRjFVQ3l4WHc5ckNJZmZpUXdGY3g5U3ZkU1Fx?=
 =?utf-8?B?ZXRqellzcllzNklyMkczbWRLbFE2Mlo2L0NoU1FoTmJYQXdITWhZdEJZMDZQ?=
 =?utf-8?B?SmdmZjM3MUZlTjZwNU5hbjRMQ0hzb0t2cFZxMnpmdXo0Rm9ZcVBTbzFmWjA3?=
 =?utf-8?B?bzhGTzA2bUg4cXdubWFUSHFpQ3hYb01HVGRZYW9ZSS8rTkpzTEs5Tm1XQkJY?=
 =?utf-8?B?aHY1WlFFZlJOMHY3c0NjZGFVOEFJNlRhWmU0REpSbWNKaWhJV0pxVEdhU1Zx?=
 =?utf-8?B?Z2dWUHhsZ0I1OWNKZ0hWV2c3bi9JdUFDKzdQVk8vRVVnLzh2ZWlDZURuQUtD?=
 =?utf-8?B?elZrRlZGcEdpZ29lRG96OUdraTc4OXBlR3A5Z2wvRzQ4amJrNWFtN0FZRFFG?=
 =?utf-8?B?MlZ5SEZKWmhSMWt6eXVFcU1BY2tubENUTlVxM2FBdWhlVTU0aTB4QnY2YmVz?=
 =?utf-8?B?ditPMWU2M2ZMQnhEYXZpakJKU3R3UDBWcnp3cGFadXY2dEtFT3N6MXBmQnVs?=
 =?utf-8?B?YkExOGRHU0l2bm1TSjh3N3VWbS9JZHN2djgwSm9LYnJoQ0x2YlBLSFJ2MHE4?=
 =?utf-8?B?MGVvS2UxbnNVYUNMbURGVnBoUzFDdGpLU2pxQUFCZUxyV2EzREFESXFJcnJs?=
 =?utf-8?B?Si9DcUJWZjAzWXhGZE1kR214cEZSbU1KNTJzSXZhV3AwaVFCWTV3bWJVT2dw?=
 =?utf-8?B?ajFRck1GbGtybmt2SHY4K3BMdmdKREJXN2NZSXdPdmVEcVhlVGpRNSsyd2tv?=
 =?utf-8?B?SFF4NnZzc3FYRUF0djM5VTNCMmFEVXB4aEFKNXl2elNTV2k0UjU2MGpwUjd6?=
 =?utf-8?B?TUx2cW9NSGx0MnZpYjViS28wQ3hKclRtKzhNcUlzWGdNNVMzaXRDeG9OT0U2?=
 =?utf-8?B?Nkd4aXV0VnQ4VG9nbWMycVU3YnVqYW9jWnFrSDRLb2NmcG5EKzBPb2g5TElQ?=
 =?utf-8?B?SzVwMEdmUlhFWTg0eWZQSFFNdkU2Q2kvMlVFck50QVdDWmJtYkZJM3Rva2lr?=
 =?utf-8?B?NzI2NGpBRzhDNS9tUmd1elBqeGVwcUFFeVlyRjN3ZU4xM3k3SmZyY2pjTzcx?=
 =?utf-8?B?THBKcGpXUy9aRnlVRTdZdGk2S2tYQnVCbDNDUmZuc3VjeDdrSzNZWUFNQTNt?=
 =?utf-8?B?Q1lxcFU4OXFTSHBpVEs0TWdGR1Yvc21jK1ZWa2xPbDJIQW1QQUY5OTZqZ2Q4?=
 =?utf-8?B?MlN2SWdzZkIvdjFpQkJGblB6MlNxbGQ1bmdxUXdydXBUc2xjSURCeklpZDVu?=
 =?utf-8?B?SGxKZjc5MkhZMEdBeTRZOFd6N04waCsyU3h2THlTa1E1RWlWZS9aT0E0NHhw?=
 =?utf-8?B?NXQ2blVOVkM1SGxvWmhsUkVsa0J2c1hEd01COGxTV3pLbTdDK1VwR25XSnVO?=
 =?utf-8?B?V0Fwb2pxc0xSWElKdHFDSEJEQ3dWUnBiVlRyek9vZE14cHNHMU8rQkNud2Zj?=
 =?utf-8?B?akNZMkVqaFhrcFNJajVsRFhLMGpPdnRLSE5waVJBdHFYWTVPVUUybUF4L1Nh?=
 =?utf-8?B?MDk4TmR1V2Vabk9iTUlkUmJsTlBuT1B2UXR3bEViUTdsM1phR2wyR1VmZ1Ba?=
 =?utf-8?B?dUdUWTdxVkhnckIzMjRTQXZBSUY1YU9FT2daU0IwaHFQeC9wVFVKRTlpL3J3?=
 =?utf-8?B?Qzc0TW9Tck9qRHpOTndZV29sbmlCdjRsNFQxdkl0czJaa2xud09qM2UwYy8x?=
 =?utf-8?B?d04xNkMrVVNSQkRYaTlVRTlSRlRyTFUvR1ByQjh0UFh5OGhOL0VDQjdOREJH?=
 =?utf-8?B?QzVqNUtvaTBZTGxYS0ZiOSthTGcxUVNLcHpuMnZwZE1uN281RENXdjhlQk41?=
 =?utf-8?B?Rlg5M1YzcEErTm9Wdy9Cc3ZKb2xlR0xDdEFCOHMwSmR6NHdINHRIQUdiOEM2?=
 =?utf-8?B?dWxteFFvQ2tqeG54OWJMd01HdnUyQlROTkhyUHBTaDhiR2gzbkxmV1l0NDVN?=
 =?utf-8?Q?DdF3HxJg8bleFoUJ/Xv9yw6pSHI+2E=3D?=
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?ZTI2SHNWajhub0plWDQ1a3VzYk5kNDBvYlJWSlUvMTQ2NUV1ZWlqS2l1NWtF?=
 =?utf-8?B?UVF4NFk3aHpTT0Nxb1I4SDErc3VPc2h1N3pNbVMrdDdmbFpoeUZ1bHdDemF4?=
 =?utf-8?B?SzFJUEJ3b1dWeGRTVHRkY0VxYmRZbzAwbUl2T0Nzd3dOb3NLTGh2a2VxdHZG?=
 =?utf-8?B?eUNIditCUDAxUEtUVnNidldSV3BSamJRazMvR05QT2loWHBlNjM4SXlCU3JO?=
 =?utf-8?B?SWdDeHVUQjkxWDFJN3N3cWdwMUVBV0ZNLzlhQ3VLNitaRTh0T2V5SG8zSEhS?=
 =?utf-8?B?bG9kZVVUbU1aU3hSUG9HcWIvZUg2RGQ3TkVaL292U25OY1IwTFJuMkx6VHM0?=
 =?utf-8?B?bVdPTmVDNmlOQnVleGlnTzZQSitLRWdCNzV3aC9kMFBEdHVrc1JMQzBMdE15?=
 =?utf-8?B?QUZValdnVDUwRDZxUS91OGptQnJndFRYK1F6L0ZWbmxOdzF5T3BKMWxvbGZW?=
 =?utf-8?B?dUFKTFM2MFJDUGxJRmdQZFVKYWNkYWNhK2NPYzZDNDBPcE8vVDY5QlJpWksv?=
 =?utf-8?B?ZGF5blplTFE1T3dBR2E2R2FMMlhBWkM5V2VoNzRlTEk2ZXVXM0dUMmxYbCtB?=
 =?utf-8?B?VTcxTUZqVGhRbHd5cnNrUU5JU2N4V3huRlgvYWJLcG5oQUZVLzJDNXZvNVFO?=
 =?utf-8?B?LzNVc3gwOXJkcWxqSzVuY0lhNzFwOHRtd0JvRTZnTVJFSTRwbWJBSTlNVzBO?=
 =?utf-8?B?ZE9ud2JYeWNCSXYyTk5FMDRvNTV3Si9FQVFnOXpyM1YyanI4S01XRWVEZFBZ?=
 =?utf-8?B?azNmMVc5b0hCK05UbDk1OFA1TjVabGxuWGIrbGE4V1V0dHV4Y1NhV29LY0NP?=
 =?utf-8?B?WENUakVFVjRtQURObkliN0JZYlA2STVjaUJzUnRPNlgzOTQ5c3hoVlBKT2J4?=
 =?utf-8?B?d1dXczVxZWtEckxwMUJYUWh2S3NsaGV2ekoyTVJ1dFNCMGJIem9SakpDSzIw?=
 =?utf-8?B?MVV0bDc1ckFpTGs5SEM3Vkk2MjBJY1RyOVVTYjFVRTh6MWllNGhMUHMrSXV4?=
 =?utf-8?B?OHlvcmZwYlJvZHlHNjZGRTlpK2s0dWNzeFF1bkp0ajdnL2R2SUlsTURZWXY1?=
 =?utf-8?B?Vk5qVnY0TlJuOTZsd3Z4dVVDWUVVa2l2WTRxWGJtRGcyWlZ3NDhrOXRDRWJi?=
 =?utf-8?B?Zk5zcDZhT0F5ZnVDWkVEM2xMamNnNmRWSzY4SXgzSEU3VTMyd2hlR1pDSFgv?=
 =?utf-8?B?ZzFQMGFrQk9qbXFFd0NpREVqcTkyUU9rTTVjREVyWU9aV0NUQ2RWTDUrd1dy?=
 =?utf-8?B?UWxZRHVnT1hiS0ZCN2xnWlk1b1JRZWlZTU1TNE04RjIwZUlpS3FWOUFvYnc5?=
 =?utf-8?B?b2xjOGUreFhLbFlnaHlZS2FBeDd1Qkw0NVcxZTFzYVpXOEc0dWV5RE5aN29F?=
 =?utf-8?B?RExGdnlQSklaMDRIQllydW4yb1JuNjdoenhYcGZ1cldWNWVMc2huR2ROY1FR?=
 =?utf-8?B?eTNLT28wcVROSCtjN2xKTnlSRHJoWmNvN3FVdHMyd0hFQTV6YmZ0NDJxeEFw?=
 =?utf-8?B?WGdmdkFyd1FCbmFFT0VvM2ptNy9iS3RiVU40T2F0eGh6SHRtc0ZuUUkxNWNa?=
 =?utf-8?B?MHVkN1lWbjRBL2ZEeUFhV2w2d0dTMmE4NklEbXZNMGR5WDRraWR4SFNuMURt?=
 =?utf-8?B?OE5vQURycXZYU0hGRlNzMDVjNlY3U0V1SUhoNjlFek5tRnZEeHpjTlRpZWdk?=
 =?utf-8?B?ZC9PRkJLbjZUVG53cU1jRG5pSHVtVDRkWXUxVEJZN2VNVVRkeDdTUkJMMEtX?=
 =?utf-8?B?YXY5Z0ZaUlhpdGl2S0Zua3JDTkxwWEUvYlRaejFGZzlFUnZ5blhkOFNCcGpy?=
 =?utf-8?B?ZEl2TWZCRnZjN0p1MXVUMC9XYmVkQUJZWjh3dmhTM3FETUYzaVVFTGMvT3A0?=
 =?utf-8?B?MndqeGdEWkN2b2MvWWF6UHJvQWNpaERObzdqUG94TXBoblBhd2plalFra2I2?=
 =?utf-8?B?aHIxTlZPVlRIY09vdVB0dFdEVDd2dGVQUDY4Yng4Mnh3MkxMcmVZc0pTMkJW?=
 =?utf-8?B?MzVKaCtub0FIYzVuNUxrS0J2bEtQZ1lQbndvVzJKQVFRZEM3ak9FSVJOUDlV?=
 =?utf-8?B?UTZ5V3pkaGN4aUlzOUs2V2JHR2ppOHNZc1dKc2RLTlo3V0RVQThVT3lETWsw?=
 =?utf-8?Q?MLt4=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <4E4BF00CE9A3814FAEE7D85E08FE583A@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: 3f6014e8-9133-4f0c-d3cd-08ddb3d2d062
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2025 10:26:57.6567
 (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: CSaymvZI73dywLnwVvn3nX8VbisrQHae8GOHsH2edUlC2TF+oU/GkAqalgGziEo2OsgdiNBe5eMc3NicZdqcLw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL4PR12MB9723

T24gMjAyNS82LzI1IDE4OjA5LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMjUuMDYuMjAyNSAx
MTo0NywgQ2hlbiwgSmlxaWFuIHdyb3RlOg0KPj4gT24gMjAyNS82LzI1IDE3OjE1LCBKYW4gQmV1
bGljaCB3cm90ZToNCj4+PiBPbiAyNS4wNi4yMDI1IDA5OjE2LCBDaGVuLCBKaXFpYW4gd3JvdGU6
DQo+Pj4+IE9uIDIwMjUvNi8yNCAxODoxNywgSmFuIEJldWxpY2ggd3JvdGU6DQo+Pj4+PiBPbiAy
NC4wNi4yMDI1IDExOjQ5LCBDaGVuLCBKaXFpYW4gd3JvdGU6DQo+Pj4+Pj4gT24gMjAyNS82LzE4
IDIyOjQ1LCBKYW4gQmV1bGljaCB3cm90ZToNCj4+Pj4+Pj4gT24gMTIuMDYuMjAyNSAxMToyOSwg
SmlxaWFuIENoZW4gd3JvdGU6DQo+Pj4+Pj4+PiAtLS0gYS94ZW4vZHJpdmVycy92cGNpL21zaS5j
DQo+Pj4+Pj4+PiArKysgYi94ZW4vZHJpdmVycy92cGNpL21zaS5jDQo+Pj4+Pj4+PiBAQCAtMTkz
LDYgKzE5MywzMyBAQCBzdGF0aWMgdm9pZCBjZl9jaGVjayBtYXNrX3dyaXRlKA0KPj4+Pj4+Pj4g
ICAgICBtc2ktPm1hc2sgPSB2YWw7DQo+Pj4+Pj4+PiAgfQ0KPj4+Pj4+Pj4gIA0KPj4+Pj4+Pj4g
K3N0YXRpYyBpbnQgY2ZfY2hlY2sgY2xlYW51cF9tc2koc3RydWN0IHBjaV9kZXYgKnBkZXYpDQo+
Pj4+Pj4+PiArew0KPj4+Pj4+Pj4gKyAgICBpbnQgcmM7DQo+Pj4+Pj4+PiArICAgIHVuc2lnbmVk
IGludCBlbmQsIHNpemU7DQo+Pj4+Pj4+PiArICAgIHN0cnVjdCB2cGNpICp2cGNpID0gcGRldi0+
dnBjaTsNCj4+Pj4+Pj4+ICsgICAgY29uc3QgdW5zaWduZWQgaW50IG1zaV9wb3MgPSBwZGV2LT5t
c2lfcG9zOw0KPj4+Pj4+Pj4gKyAgICBjb25zdCB1bnNpZ25lZCBpbnQgY3RybCA9IG1zaV9jb250
cm9sX3JlZyhtc2lfcG9zKTsNCj4+Pj4+Pj4+ICsNCj4+Pj4+Pj4+ICsgICAgaWYgKCAhbXNpX3Bv
cyB8fCAhdnBjaS0+bXNpICkNCj4+Pj4+Pj4+ICsgICAgICAgIHJldHVybiAwOw0KPj4+Pj4+Pj4g
Kw0KPj4+Pj4+Pj4gKyAgICBpZiAoIHZwY2ktPm1zaS0+bWFza2luZyApDQo+Pj4+Pj4+PiArICAg
ICAgICBlbmQgPSBtc2lfcGVuZGluZ19iaXRzX3JlZyhtc2lfcG9zLCB2cGNpLT5tc2ktPmFkZHJl
c3M2NCk7DQo+Pj4+Pj4+PiArICAgIGVsc2UNCj4+Pj4+Pj4+ICsgICAgICAgIGVuZCA9IG1zaV9t
YXNrX2JpdHNfcmVnKG1zaV9wb3MsIHZwY2ktPm1zaS0+YWRkcmVzczY0KSAtIDI7DQo+Pj4+Pj4+
PiArDQo+Pj4+Pj4+PiArICAgIHNpemUgPSBlbmQgLSBjdHJsOw0KPj4+Pj4+Pj4gKw0KPj4+Pj4+
Pj4gKyAgICByYyA9IHZwY2lfcmVtb3ZlX3JlZ2lzdGVycyh2cGNpLCBjdHJsLCBzaXplKTsNCj4+
Pj4+Pj4+ICsgICAgaWYgKCByYyApDQo+Pj4+Pj4+PiArICAgICAgICByZXR1cm4gcmM7DQo+Pj4+
Pj4+DQo+Pj4+Pj4+IFRoaXMgaXMgYSBkaWZmaWN1bHQgb25lOiBJdCdzIG5vdCBhIGdvb2QgaWRl
YSB0byBzaW1wbHkgcmV0dXJuIGhlcmUsIHlldA0KPj4+Pj4+PiBhdCB0aGUgc2FtZSB0aW1lIHRo
ZSBoYW5kbGluZyBvZiB0aGUgcmVnaXN0ZXIgd2UncmUgdW5hYmxlIHRvIHJlbW92ZSBtYXkNCj4+
Pj4+Pj4gc3RpbGwgcmVxdWlyZSBlLmcuIC4uLg0KPj4+Pj4+Pg0KPj4+Pj4+Pj4gKyAgICBYRlJF
RSh2cGNpLT5tc2kpOw0KPj4+Pj4+Pg0KPj4+Pj4+PiAuLi4gdGhpcy4gVGhlcmUgbWF5IHRoZXJl
Zm9yZSBiZSBtb3JlIHdvcmsgcmVxdWlyZWQsIHN1Y2ggdGhhdCBpbiB0aGUNCj4+Pj4+Pj4gZW5k
IHdlJ3JlIGFibGUgdG8gLi4uDQo+Pj4+Pj4+DQo+Pj4+Pj4+PiArICAgIHJldHVybiB2cGNpX2Fk
ZF9yZWdpc3RlcihwZGV2LT52cGNpLCB2cGNpX2h3X3JlYWQxNiwgTlVMTCwgY3RybCwgMiwgTlVM
TCk7DQo+Pj4+Pj4+DQo+Pj4+Pj4+IC4uLiB0cnkgdGhpcyBhdCBsZWFzdCBvbiBhIGJlc3QgZWZm
b3J0IGJhc2lzLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBNb3JlIGdlbmVyYWxseTogSSBkb24ndCB0aGlu
ayBmYWlsdXJlIGhlcmUgKG9yIGluIG90aGVyIC5jbGVhbnVwIGhvb2sNCj4+Pj4+Pj4gZnVuY3Rp
b25zKSBtYXkgZ28gZW50aXJlbHkgc2lsZW50bHkuDQo+Pj4+Pj4gRG9lcyBiZWxvdyBtZWV0IHlv
dXIgbW9kaWZpY2F0aW9uIGV4cGVjdGF0aW9ucz8NCj4+Pj4+DQo+Pj4+PiBOb3Qgc3VyZSwgc29y
cnkuIEJ5ICJtb3JlIiBJIHJlYWxseSBtZWFudCAibW9yZSIgKHdoaWNoIG1heSBqdXN0IGJlIGNv
ZGUNCj4+Pj4+IGF1ZGl0aW5nLCByZXN1bHRzIG9mIHdoaWNoIHdvdWxkIG5lZWQgd3JpdGluZyBk
b3duLCBidXQgd2hpY2ggbWF5IGFsc28NCj4+Pj4+IGludm9sdmUgZnVydGhlciBjb2RlIGNoYW5n
ZXM7IHNlZSBiZWxvdykuDQo+Pj4+Pg0KPj4+Pj4+ICAgICByYyA9IHZwY2lfcmVtb3ZlX3JlZ2lz
dGVycyh2cGNpLCBjdHJsLCBzaXplKTsNCj4+Pj4+PiAgICAgaWYgKCByYyApDQo+Pj4+Pj4gICAg
ICAgICBwcmludGsoWEVOTE9HX0VSUiAiJXBkICVwcDogcmVtb3ZlIG1zaSBoYW5kbGVycyBmYWls
IHJjPSVkXG4iLA0KPj4+Pj4+ICAgICAgICAgICAgICAgIHBkZXYtPmRvbWFpbiwgJnBkZXYtPnNi
ZGYsIHJjKTsNCj4+Pj4+Pg0KPj4+Pj4+ICAgICBYRlJFRSh2cGNpLT5tc2kpOw0KPj4+Pj4NCj4+
Pj4+IEFzIEkgdHJpZWQgdG8gaW5kaWNhdGUgaW4gbXkgZWFybGllciByZXBseSwgdGhlIGZyZWVp
bmcgb2YgdGhpcyBzdHJ1Y3QgaXMNCj4+Pj4+IHNhZmUgb25seSBpZiB0aGUgZmFpbHVyZSBhYm92
ZSB3b3VsZCBub3QgbGVhdmUgYW55IHJlZ2lzdGVyIGhhbmRsZXJzIGluDQo+Pj4+PiBwbGFjZSB3
aGljaCBzdGlsbCAod2l0aG91dCBhcHByb3ByaWF0ZSBjaGVja2luZykgdXNlIHRoaXMgc3RydWN0
Lg0KPj4+PiBIbW0sIGJ1dCBhbGwgaGFuZGxlcnMgYWRkZWQgaW4gaW5pdF9tc2koKSB1c2UgdGhp
cyBzdHJ1Y3QuDQo+Pj4+IFNvIGl0IGRvZXNuJ3QgZXhpc3QgdGhlIGNhc2UgdGhhdCB3aGVuIGFi
b3ZlIHVuYWJsZSB0byByZW1vdmUgYWxsIGhhbmRsZXJzIGFuZCBzdGlsbCByZXF1aXJlIHhmcmVl
IHRoaXMgc3RydWN0Lg0KPj4+DQo+Pj4gV2VsbCwgaW4gdGhlIGVuZCB5b3Ugc2F5IGluIGRpZmZl
cmVudCB3b3JkcyB3aGF0IEkgZGlkIHNheSwgaWYgSSB1bmRlcnN0YW5kDQo+Pj4gY29ycmVjdGx5
LiBUaGVyZSBhcmUgc2V2ZXJhbCBvcHRpb25zIGhvdyB0byBkZWFsIHdpdGggdGhhdC4gT25lIG1p
Z2h0IGJlIHRvDQo+Pj4gaGF2ZSB0aG9zZSBoYW5kbGVycyByZWNvZ25pemUgdGhlIGxhY2sgb2Yg
dGhhdCBwb2ludGVyLCBhbmQgYmVoYXZlIGxpa2UgLi4uDQo+Pj4NCj4+Pj4+PiAgICAgLyoNCj4+
Pj4+PiAgICAgICogVGhlIGRyaXZlciBtYXkgbm90IHRyYXZlcnNlIHRoZSBjYXBhYmlsaXR5IGxp
c3QgYW5kIHRoaW5rIGRldmljZQ0KPj4+Pj4+ICAgICAgKiBzdXBwb3J0cyBNU0kgYnkgZGVmYXVs
dC4gU28gaGVyZSBsZXQgdGhlIGNvbnRyb2wgcmVnaXN0ZXIgb2YgTVNJDQo+Pj4+Pj4gICAgICAq
IGJlIFJlYWQtT25seSBpcyB0byBlbnN1cmUgTVNJIGRpc2FibGVkLg0KPj4+Pj4+ICAgICAgKi8N
Cj4+Pj4+PiAgICAgcmMgPSB2cGNpX2FkZF9yZWdpc3Rlcih2cGNpLCB2cGNpX2h3X3JlYWQxNiwg
TlVMTCwgY3RybCwgMiwgTlVMTCk7DQo+Pj4NCj4+PiAuLi4gd2hhdCBpcyB0cmllZCB0byBiZSBw
dXQgaW4gcGxhY2UgaGVyZSAoYW5kIGxpa2UgIm5vIGhhbmRsZXIgaW5zdGFsbGVkIg0KPj4+IGZv
ciBvdGhlciByZWdpc3RlcnMpLg0KPj4gQWNjb3JkaW5nIHRvIHlvdXIgc3VnZ2VzdC4gV2hhdCBJ
IGNhbiB0aGluayBvZiBpcyB3aGVuIHZwY2lfcmVtb3ZlX3JlZ2lzdGVycygpIGZhaWxzLA0KPj4g
dGhlbiBsb29rdXAgdGhlIE1TSSByZWxhdGVkIGhhbmRsZXJzLA0KPiANCj4gV2hhdCBleGFjdGx5
IGRvZXMgdGhpcyBtZWFuPyBBaXVpIGlmIHZwY2lfcmVtb3ZlX3JlZ2lzdGVycygpIGVuZHMgdXAg
ZmFpbGluZywNCj4gaXQgbWF5IGJlIHRoZSBsb29rdXAgd2hpY2ggaXMgdGhlIHByb2JsZW0uIFdo
aWNoIGlzbid0IHdoeSB0aGlzIHdhc24ndCB3aGF0DQo+IEkgc3VnZ2VzdGVkLiBJbnN0ZWFkIEkg
c3VnZ2VzdGVkIHRvIG1ha2UgdGhlIHJlc3BlY3RpdmUgaGFuZGxlcnMgZGVhbCB3aXRoDQo+IHRo
ZSBjYXNlIG9mIHZwY2ktPm1zaSBiZWluZyBOVUxMLiBXaGljaCBvZiBjb3Vyc2UgaW4gdHVybiB3
b3VsZCByZXF1aXJlDQo+IHBhc3NpbmcgcGRldi0+dnBjaSB0byB0aGUgcmVzcGVjdGl2ZSB2cGNp
X2FkZF9yZWdpc3RlcigpLCBub3QgcGRldi0+dnBjaS0+bXNpLg0KDQpMaWtlIGJlbG93Pw0KDQpA
QCAtMzcsNyArNDIsMTMgQEAgc3RhdGljIHVpbnQzMl90IGNmX2NoZWNrIGNvbnRyb2xfcmVhZCgN
CiBzdGF0aWMgdm9pZCBjZl9jaGVjayBjb250cm9sX3dyaXRlKA0KICAgICBjb25zdCBzdHJ1Y3Qg
cGNpX2RldiAqcGRldiwgdW5zaWduZWQgaW50IHJlZywgdWludDMyX3QgdmFsLCB2b2lkICpkYXRh
KQ0KIHsNCi0gICAgc3RydWN0IHZwY2lfbXNpICptc2kgPSBkYXRhOw0KKyAgICBjb25zdCBzdHJ1
Y3QgdnBjaSAqdnBjaSA9IGRhdGE7DQorDQorICAgIGlmICggIXZwY2ktPm1zaSApDQorICAgICAg
ICByZXR1cm47DQorDQorICAgIGNvbnN0IHN0cnVjdCB2cGNpX21zaSAqbXNpID0gdnBjaS0+bXNp
Ow0KKw0KICAgICB1bnNpZ25lZCBpbnQgdmVjdG9ycyA9IG1pbl90KHVpbnQ4X3QsDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgMXUgPDwgTUFTS19FWFRSKHZhbCwgUENJX01TSV9G
TEFHU19RU0laRSksDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGRldi0+bXNp
X21heHZlYyk7DQpAQCAtMjM5LDcgKzI1MCw3IEBAIHN0YXRpYyBpbnQgY2ZfY2hlY2sgaW5pdF9t
c2koc3RydWN0IHBjaV9kZXYgKnBkZXYpDQogICAgICAgICByZXR1cm4gLUVOT01FTTsNCg0KICAg
ICByZXQgPSB2cGNpX2FkZF9yZWdpc3RlcihwZGV2LT52cGNpLCBjb250cm9sX3JlYWQsIGNvbnRy
b2xfd3JpdGUsDQotICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1zaV9jb250cm9sX3JlZyhw
b3MpLCAyLCBwZGV2LT52cGNpLT5tc2kpOw0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBt
c2lfY29udHJvbF9yZWcocG9zKSwgMiwgcGRldi0+dnBjaSk7DQoNCj4gDQo+PiBhbmQgc2V0IHRo
ZSByZWFkL3dyaXRlIGhvb2sgdG8gYmUgdnBjaV9pZ25vcmVkX3JlYWQoKS92cGNpX2lnbm9yZWRf
d3JpdGUoKSwNCj4gDQo+IEJ1dCB2cGNpX2h3X3JlYWQxNigpICE9IHZwY2lfaWdub3JlZF9yZWFk
KCkuDQo+IA0KPj4gYW5kIHNldCB0aGUgcHJpdmF0ZSBkYXRhIHRvIGJlIE5VTEwuDQo+PiBJcyBp
dCBhY2NlcHRhYmxlPw0KPiANCj4gQWx0ZXJpbmcgYWxyZWFkeSByZWdpc3RlcmVkIGhhbmRsZXIg
cHJvcGVydGllcyBmZWVscyBwcmV0dHkgZnJhZ2lsZSB0byBtZS4NCj4gDQo+IEphbg0KDQotLSAN
CkJlc3QgcmVnYXJkcywNCkppcWlhbiBDaGVuLg0K


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 10:27:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 10:27:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024658.1400487 (Exim 4.92)
	(envelope-from )
	id 1uUNLw-0005dU-5w; Wed, 25 Jun 2025 10:27:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024658.1400487; Wed, 25 Jun 2025 10:27: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 1uUNLw-0005dN-2t; Wed, 25 Jun 2025 10:27:40 +0000
Received: by outflank-mailman (input) for mailman id 1024658;
 Wed, 25 Jun 2025 10:27: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 1uUNLu-0005SS-CG
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 10:27:38 +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 03e7e08f-51af-11f0-a30f-13f23c93f187;
 Wed, 25 Jun 2025 12:27:37 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3a4f72cba73so427613f8f.1
 for ; Wed, 25 Jun 2025 03:27:37 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-315f542708esm1434165a91.30.2025.06.25.03.27.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 25 Jun 2025 03:27:36 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 03e7e08f-51af-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750847257; x=1751452057; 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=SVwUm0TQgfV34+E1Tvun/X7VE2A8Ltp0UFTVKHj/Upc=;
        b=b52xIpLDemwdTXMxO59Ll7oVZQGb7hDLid5bJwicb3kAcXnQKgGPaWJ4ZD2iPsMD+F
         SOdW3UKMnqcWsAWk5KMWywZSRhIq6SnuWhNXC0v2dhz42PtFuqBd3H4pZem2zXO1//1w
         kPB9RUA1GELrZhYvf9+90Wb+cYxv0jgQnbZ2/N7BGUndtSSR0PvoxKoWfTuIsVIUomgr
         G1PaI2LZDJL/qAZWWjv8pYQ9nU5IB+iZ3e7LOsZmIx6xDG9qEK9/sRr/KIQ3o/GLc24O
         b6ZM6/KjLSBOYUzgCf5KiubWIbDTwQ21hVXt5LXmQSH/20eaNvWb6L5Ouohsd3zJyVic
         wFGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750847257; x=1751452057;
        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=SVwUm0TQgfV34+E1Tvun/X7VE2A8Ltp0UFTVKHj/Upc=;
        b=d5F66QAaccLX5gLMrohrRIS5qMW3ljWtDyx+3EZJ/dHBrI5dlU8CW5ucqLG9WN6tfR
         JkSzpbHyUtp0t+OcKeCLyVwA262NLpUMapJJygpYlMBM+N6MV5oznxiFdTCShER8seMU
         8qOCifLjiA+hpCCbxKZZsqewYVuEx/mJzDtPK7N8gaAx5d3Cn3xPRgfJdSI23ymYmmKM
         /yy8xO+zqu0sQ7fqcNcFQYaF90rGRXPe6oB14WC+ZpcuqrxbUhGAkfTcRNGkzS3XGEg5
         lSLmguwqDpBkhUJ2heV6o9bBsLMBE/7vRV374T24N7xh5g1M8YiyZkBEpnT5QrtWip+0
         g9WA==
X-Gm-Message-State: AOJu0YyXMZ3H46PyKBR79+dchayj9J1ujxIl/c3mcawzuyx5/Ee9l3Jd
	77d3PHcJ+AYwUyud3tXPvf94SrkzjtlxqLxEUddfXFMmsFA4bxFWhT72nqNUai+oLKZ66HIUGRd
	xnms=
X-Gm-Gg: ASbGncu5WAmVbLyxdRX78CRrwAk39L5VDa/PokcppEnMZdHDVRyptK28i72lcEybYQK
	gL0ulr7zD4vl/sgn2djFZPTNRKluaDmtbiPEGlxAnXB+hf6w7Nzd54kq2Y/VNMK+MmVmHbzt6ir
	PyS4l15TfpTbwYHSyfweTJZ2JDWo3qhN/d2F3jQTp8cet2UucE998j7TtZWDwhIEg6XTJNcoZpu
	crYGTfDZge43dcek6dWzkmf8Mvf0E4AF4zQ5ZMqY6orJS/EPJ0JjeX/NHKCfkPVFcDoonOnuj23
	WAoB2zgB8EaynG/puuxHiUAaXUVsp7i3XWd/qfzx1VwiSaa4GGd8L81PbTxprHm9TvwnBQjMfhe
	DoO181HKYGNSz3C67cWPkC4VIEUExzRNPHaWVc5jerr1web8=
X-Google-Smtp-Source: AGHT+IGUm0pqrMFG//sqkL3OrHMzhilTOZ3RgTCCCbtYpqu+SR4fX3REJFHhLBSvLvVNoWVb4po9TQ==
X-Received: by 2002:a05:6000:2382:b0:3a6:e2d5:f12d with SMTP id ffacd0b85a97d-3a6e71c5c6bmr6011597f8f.11.1750847256991;
        Wed, 25 Jun 2025 03:27:36 -0700 (PDT)
Message-ID: 
Date: Wed, 25 Jun 2025 12:27:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 7/7] mm: allow page scrubbing routine(s) to be arch
 controlled
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini ,
 Anthony PERARD ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Bertrand Marquis ,
 Volodymyr Babchuk ,
 Oleksii Kurochko ,
 Shawn Anastasio 
References: 
 <0d2b44e3-bf6c-40ae-be4f-d0ad2845e925@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: <0d2b44e3-bf6c-40ae-be4f-d0ad2845e925@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.06.2025 15:02, Jan Beulich wrote:
> --- /dev/null
> +++ b/xen/arch/x86/scrub_page.S
> @@ -0,0 +1,39 @@
> +        .file __FILE__
> +
> +#include 
> +#include 
> +#include 
> +
> +FUNC(scrub_page_cold)
> +        mov     $PAGE_SIZE/32, %ecx
> +        mov     $SCRUB_PATTERN, %rax
> +
> +0:      movnti  %rax,   (%rdi)
> +        movnti  %rax,  8(%rdi)
> +        movnti  %rax, 16(%rdi)
> +        movnti  %rax, 24(%rdi)
> +        add     $32, %rdi
> +        sub     $1, %ecx
> +        jnz     0b
> +
> +        sfence
> +        ret
> +END(scrub_page_cold)
> +
> +        .macro scrub_page_stosb
> +        mov     $PAGE_SIZE, %ecx
> +        mov     $SCRUB_BYTE_PATTERN, %eax
> +        rep stosb
> +        ret
> +        .endm
> +
> +        .macro scrub_page_stosq
> +        mov     $PAGE_SIZE/8, %ecx
> +        mov     $SCRUB_PATTERN, %rax
> +        rep stosq
> +        ret
> +        .endm
> +
> +FUNC(scrub_page_hot)
> +        ALTERNATIVE scrub_page_stosq, scrub_page_stosb, X86_FEATURE_ERMS
> +END(scrub_page_hot)

Bah, I've noticed only now that I failed to do the ret -> RET conversion here
during the most recent re-basing.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 10:28:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 10:28:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024668.1400498 (Exim 4.92)
	(envelope-from )
	id 1uUNN3-0006By-GP; Wed, 25 Jun 2025 10:28:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024668.1400498; Wed, 25 Jun 2025 10:28: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 1uUNN3-0006Bq-BX; Wed, 25 Jun 2025 10:28:49 +0000
Received: by outflank-mailman (input) for mailman id 1024668;
 Wed, 25 Jun 2025 10:28: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 1uUNN1-0006Be-64
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 10:28:47 +0000
Received: from TY3P286CU002.outbound.protection.outlook.com
 (mail-japaneastazlp170100001.outbound.protection.outlook.com
 [2a01:111:f403:c405::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 29f151f9-51af-11f0-a30f-13f23c93f187;
 Wed, 25 Jun 2025 12:28:43 +0200 (CEST)
Received: from OSOPR01MB12408.jpnprd01.prod.outlook.com (2603:1096:604:2d7::7)
 by OSCPR01MB14757.jpnprd01.prod.outlook.com (2603:1096:604:3ae::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.27; Wed, 25 Jun
 2025 10:28:35 +0000
Received: from OSOPR01MB12408.jpnprd01.prod.outlook.com
 ([fe80::7ff4:8a98:ccd4:daa1]) by OSOPR01MB12408.jpnprd01.prod.outlook.com
 ([fe80::7ff4:8a98:ccd4:daa1%4]) with mapi id 15.20.8857.026; Wed, 25 Jun 2025
 10:28: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: 29f151f9-51af-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=adI/X/gz2iA/JT2pk+3Mc22d4ruxNRrMVsgdppFy3hSfScMjIx8w7HuIK3WtJqJRQxFo8YOXPfBBQy74mIQxbnyG+uzm8h8xCsmw591+lF5HfnsOVyxdutFxDG7i/3GlWEcXLjGgHx1882irWBzLC01G0bUwE7zdOo8Bav5Mf0oNjpSrMrEt85adbAyLK+dCJJ/3wySc00YYFYYWvxEsZXS3U1nd+IzfSBEUOH+4YDW8vZxgyDilEilzWWuKgbLvoYOAvBZdUkh93Per8f+X5tvTtiOtm+GsLNmSLYMpbgB99wmTTfZwHBp4e6l2p9fbMcSFihlk+yH2W49XyeDY2A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=fKzWTVWrGb0bC9gAvNTpISKhhAEiaXgjCxN0G+Rap/0=;
 b=kaN6sRb34FyPqpGqIGT5I+WX9yvm6cgvSC/qwuC0BB0d3HLUeXDrek+/PITyESMkxEVxSxKnjEFbxO1wjIuNz/n5kpU76xyeWLtBK5K0hYqbs8aERHtcbYWzSUkXqn+UV0AVgOptLUknWUEOXsHEVAbQCgzCBuxjhVhCucJ0YCfzTDPorEW2fdCYjHOyAGrAf/LwroJKc0Zn47MelW2aZFQ3nFC4VG0NsblL0DsYjdXsZzwLhxUOAQdiCrbLXXdNhCkNnkogjFah4MA6HXL6LKgyV2/w5wmrV0wKaljXH9G5eSvy/IR7jhdW+O+7z9KLgb3LA4l6goqtO1nyu7238g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=renesas.com; dmarc=pass action=none header.from=renesas.com;
 dkim=pass header.d=renesas.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=renesas.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=fKzWTVWrGb0bC9gAvNTpISKhhAEiaXgjCxN0G+Rap/0=;
 b=I8KEpVD/Y9ZmWjHBGiwZ7rHAuvVoy/+LrPjVU/Jd2G0KvoxXlsLBmx6sTpOxPnoSEhKy7m54PT8kLe3JmWRSnFoAv6giqV2JgOeZwPHjTSRhg9T5VOPKP8r3+cAIrPttlmD82A36A0bNl7UfJnmuyWw3iZLzribyHK/j3XZAolU=
From: Jahan Murudi 
To: "Orzel, Michal" , "xen-devel@lists.xenproject.org"
	
CC: Stefano Stabellini , Julien Grall
	, Bertrand Marquis , Volodymyr
 Babchuk 
Subject: RE: [PATCH] xen/arm: Enhance IPMMU-VMSA driver robustness and debug
 output
Thread-Topic: [PATCH] xen/arm: Enhance IPMMU-VMSA driver robustness and debug
 output
Thread-Index: AQHb4c6ALl3IHvqkBEOgbLXzyjOhU7QQXHcAgANRIGA=
Date: Wed, 25 Jun 2025 10:28:35 +0000
Message-ID:
 
References: <20250620103123.2174529-1-jahan.murudi.zg@renesas.com>
 <445c5594-a003-4cd8-aa46-8544c0543b1c@amd.com>
In-Reply-To: <445c5594-a003-4cd8-aa46-8544c0543b1c@amd.com>
Accept-Language: en-IN, kn-IN, 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=renesas.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: OSOPR01MB12408:EE_|OSCPR01MB14757:EE_
x-ms-office365-filtering-correlation-id: ad3b8a7e-930d-4047-b962-08ddb3d30a8f
x-ld-processed: 53d82571-da19-47e4-9cb4-625a166a4a2a,ExtAddr
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?ZjZGWVFjNlozNHByVFNNODZtUno0MGlwQ1RKeE93U2pTSUxWVzdLS1lFb2li?=
 =?utf-8?B?LzFrQ1ZITTR6UUV6bEpIU0FSY1RTY29ITUhkZHFyQmYzWW16RTYwSjJWSHU2?=
 =?utf-8?B?VFhRZ2lySVo3N3BZM1F2ckY4Y0p0Q3FUNFl6WElkV0RaRFRkVDZsTTZ6WWxQ?=
 =?utf-8?B?V1NmdEpibXNQckVtTXJtTkxQVHdjM0R6c05aUFlUOFlxbVVZckViMjRpakFw?=
 =?utf-8?B?Q3BMYitEOUx0VWU4M3Z1RUVwbmFZenoyUHVzTHpCbjN4UjZHYzFPSkpCWWl4?=
 =?utf-8?B?cENmelRJQkQ4YzRTZGJtNSt1UUxyeUdhN1VGcHBGdkVTdFlSbFZjMFkzVjNp?=
 =?utf-8?B?RXUrV011am45eUwxekkxNlYxdUlVSnBWTHFhT2hXNVhyUkhEUWRwbXBIdXh0?=
 =?utf-8?B?eGZVeEtvOVdkT0dhL0QxYUtMbU5vVFo5VnlvUkhqWlNZYlVJSnNpQWxLcmto?=
 =?utf-8?B?Ym1RcXM3ckxoS0lXTkhCQU9PeVo2OWl5UFBwVVBCTmFXRmIvNE85akdqbTFH?=
 =?utf-8?B?UW1MRDBValVzMTRsV1J4RDRVR0dXcytTUThxUHlqbXMrVi9BeGVjWEtqWlhp?=
 =?utf-8?B?Qkg5NHc1WVNZaXNQaGkrdTJzcmFIbkg5ZGtHS2loVkkwNjNzR0FIbVhBYUI3?=
 =?utf-8?B?cW9ma21lbCsxVEZKY2FMS0hxQ0hFY2liMjdQL1owdGFjak1qRFBLQjJvbWlp?=
 =?utf-8?B?bENRWnRTVnNINS9yQUhBbW95OGJGZG5SYmNOQStIVkU5RUNsRExsZlJyNEo5?=
 =?utf-8?B?LzFVajNXeU5zQlNqYWowM2ZkUHpVWVFkTnd4QkZNSEY5TFIxVnB0d1FsLzZq?=
 =?utf-8?B?RTlyTkNyS2l2elg5SElBWCtORXptZkpJcmwxUzJJRGdSaTd3V3haaG8vWHZH?=
 =?utf-8?B?S2g0dkdTY05FNDdlWHBTaEU4a1poMDRQeFBlMUxHdXZGL3hLZlZkcEtmRFh4?=
 =?utf-8?B?ZFoxSE4zdkZsekRPSjhqbFVBMkszaXMyVnlFOHF5YWVFaWJLWTFnL0RDZnpt?=
 =?utf-8?B?TWdpUFhPdFhDNGx5cWxxcWREVzROTlNaZHpmNGQ1T3RhaHlCYUxzOUVSMnlo?=
 =?utf-8?B?M3FCY0Z0ZWJ3R3Qrci9hMzF0MldqOEVlcmYyaDNsSUtkYmswK1d2RnAyVFVO?=
 =?utf-8?B?Nk9zT2dnaFlqT1FZTnhJSlZDMyszMHpWN2RQdU45SUYwYm52VTBpMUtqWlhO?=
 =?utf-8?B?dUJhVmQ1MEtuNUJvZzJIME55R0d0N0tyeXUzMllXMHBwVndIM0g1U3NNYnpr?=
 =?utf-8?B?dkpWM2g0UmVUcFY3Q0JNY29lSjhVUHlWT3QydWVKcUs0d3N2WkJWd1VWM3FM?=
 =?utf-8?B?eHlGN1VTSFo0VU8vRXdxR21aaTVBa1REOThxZlVMRmpXREwzcHF0ZEtIOURB?=
 =?utf-8?B?VElqUmt4dTMyYVJSeUZNVmRLWm4wMHdZNDY4QTdpWHBIQUptKzFNcHdocmNp?=
 =?utf-8?B?cHdaeU0zRmd5NE9SdCt0RkphQlZCYTlhN0dEUWNOK2czRjVxa3Z3clFhZlY0?=
 =?utf-8?B?a0FTY0ZaMXUyYWloU2FoT2oyR05lUUdabVpHZmc1QU5PeXA0VElIaEUxK25P?=
 =?utf-8?B?Mm82YnF1c2xkR3BnN3REZ2toejFoVTB1WXREbFlCc0pMNC9kbFI2bVEwek41?=
 =?utf-8?B?ZVFzRGhSZnZuMEVWUE50S3pwZVVkdFRIdVNpekpTekp5UEhYVUFZKzhJODhn?=
 =?utf-8?B?NmI3bURMKzU2RzBjZE5lWU95bWdYQ2J1bXpyak9WWFJlLy9heUUzNHY1WlZ5?=
 =?utf-8?B?WHpGaFZKdXg5dlFxOGdyamJDQXM0SUROb0drUG0vNFAvL0dpTVE2RnhKUDU5?=
 =?utf-8?B?bFMvNXNlbDVFRk5Da1RBcFRISm9TVnlST0lmVDFOMWwvb3Nld0d5QVczOUF5?=
 =?utf-8?B?VERTVlNqTlFlOWRvdWRrVllGa1QwMVhEUzdOY0hIN0NnQkVNWTBoelJCN1pE?=
 =?utf-8?B?TGJmV1J0ekc5dXB5QXNvMHM3R1BmeG1XdGx6WkQ5SlNBR09nU1lhTU9YODVN?=
 =?utf-8?Q?mVC8S4r9nQllwNpPZuXL3u7X9EUrro=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:OSOPR01MB12408.jpnprd01.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?UXUwcVJoVGt2aVA5WVY4QzJGeVhUczk4RDdRMmtqK0F0VEZ5OHhwNmtiOFp0?=
 =?utf-8?B?WXJKaWFNRFZiMFR6NG9JUUtoWjFlRlNXUW5jYVIrVXlyRy84MGZuOW9hazBm?=
 =?utf-8?B?NjUzWjZJTjNLbmFIZzdaM3FCUG5MMmhNQm9RR2Z6d2FnTU5ENXlrOXhaU1pE?=
 =?utf-8?B?N25YdDFZZ0Nva2ZtUjVjMkI5Y0VJYjI4TWsra0U1bW1TNk5WaVdMQTJpbEI3?=
 =?utf-8?B?MWRuaStJQnNLWDJmUE5Hd0ZkMGNCN0xJS0JqQ1NSc293c2l6ZFNXemtQRFF0?=
 =?utf-8?B?eXhjM1IxclpzempJRkREQWlwVGhsWE1oaEhKZjg5NDdJaFdubVNWSDZscjRH?=
 =?utf-8?B?UGRPWGFma2xuelkrYjJkTCs2bFBpRmU2c1AyUFpMQ2t1aXdmczhPNzNRQmto?=
 =?utf-8?B?VjJRbisvREcrUU9penhpU3Q0cExCUmdPN252eDcydkVQVzAzMFVwVjMzNUZM?=
 =?utf-8?B?LzAxenluVUM2T1UzMnFqbTF5Z2NtTjFySU9wT1UvWFNDaWtMK0F5Vk1ITlQ4?=
 =?utf-8?B?UzlTQWdrT3VURi9sNmVmMXVBUkUzdHF1cisrSkNTZzFOWU9tWUY2K3ROMzVJ?=
 =?utf-8?B?K3pxcW5ZVjJsT1hkWlhJSWF5Sk02NzBIQmxhc3dnWkp5N2l1ZFZITVVTZWxB?=
 =?utf-8?B?MlRZL2dSTnZZakRWZFpFNjk1SW1ROHIrN00zbmN6dnBuaGNFZXJFY0VNUDh0?=
 =?utf-8?B?WFd3Q1RYNm1NVzlKWSt2MXliaUI2YWdZU0IwbXMwTnpwQ0RwdGFUOVVsaHBR?=
 =?utf-8?B?V0IxNEx2ZzFQZ3NNdXVJUDBnSFNFanRaWXpoY3prNndTNHBGQWlnd1p1QkxM?=
 =?utf-8?B?blI3cTZUK1NaMldNNGRjUmVQZHhzVDN5cm9UZ2NGQXlGMS9ZVlYxbGpObDFz?=
 =?utf-8?B?a2djektPU1o0b1pvV3JzWUdsQlN1dUpMeEZUWHVESC9yMDFWUlRqeC9xSEph?=
 =?utf-8?B?US9vbHQ5Y3FiZWVzWnBlTVYranYxYXovUWRmL3kraUJ0THU1dTFOU2QvL3Fr?=
 =?utf-8?B?ZENBSC9uSStDZjZOVE1HdkltY1N3bjNuMktEMU9YOVVkaC9zSFRhYzFLU0tw?=
 =?utf-8?B?Mm9oZDZwd21qUm1pNDJWVGd6MVFnUXBSelBDeEtVZ3M0YVdDaVZ3WmV0WVRu?=
 =?utf-8?B?eVVHOUF4QzlhWGYxMndqSGt2MC9ObjZzTHJ3bWpGYTJ5aGNaRlhScUZMY0NU?=
 =?utf-8?B?UW1TSjVTUll4QmxJTDhGS3hYZnVwZ2hYZUY1Q2UwVC91NmlTQ1ZHWjFuRXky?=
 =?utf-8?B?dzRQckpyVEZGYUlLbUdVTXpjODdCbThsYjJwVFZ3NUtRY0NwZ2NySWtabzNZ?=
 =?utf-8?B?dHdYcFduSkI2VEtRK1RveHFOUjl2NUZpVTYwZGcxMFZaNFZHL3B3RTBGZXF6?=
 =?utf-8?B?U1pZWks1dVFaNEUvZmpoUDBmaTF2ajAzdW94OFNwL3hUYnI1SU1ibDUrWnc1?=
 =?utf-8?B?MUZBNHp1ZnpyZ0YwbUlyUm95aVhWYW8ySVVVNFl2YjBWQWgvbzMxMDRIVlEv?=
 =?utf-8?B?VXRoVUpIRS9oNmxrRzFVTTVBMlZsVTFFajFwNFdYNWlKeW5ZZFUyWnFNaXh1?=
 =?utf-8?B?MExkRWJzOXZOaHAva3BXSzJZZXY4N25yamtONHVsekJhNHRoQkdpTjBKTXpZ?=
 =?utf-8?B?RVJ5ZHlzelUzVlBsRjMvc2ZiUGZYaWxqY2oxRWVjL2dkc1UwRDhvWVJDY2Jm?=
 =?utf-8?B?NFhWZm1pcUVOT3QzbFFCdFBFVldxVnR1eFZXM1djT0Yzc3dyQlRQczRadVB1?=
 =?utf-8?B?Vm51SEdBRnVpb1B5eFhoeFVjMjhnQWFZMmNIN2NMdTlMU3JaNkdZK3hMZFdX?=
 =?utf-8?B?K3VSZjBzQVl6eUVVNXpYTHVxTldRK1pJUk1JaWNrVGxvcEx6bW5IKzNkL29P?=
 =?utf-8?B?U1JOaGs5K3EyQUVHaFJ1VUVNQmFJL3R2d2w4eUw4VU1nVkV1cU83TXpIRHgz?=
 =?utf-8?B?NDFmcllMMWI4aVBUL0JFazRKdXM0U2R6cHRQcDVnSjkvVVNrd1pNN0wwTUd4?=
 =?utf-8?B?bEFiM3ozNGRZcXZqQnlJMlhKa05GcW9ka1hhaXRNb0pOMG5BYjUrMi9YQlV6?=
 =?utf-8?B?eWpISjFJZU40QWE5em1UamRZdVpLaVF2UXJtRGNSaDVQUmh6eWd0VDg5ZWQ5?=
 =?utf-8?B?U2Q4K3JHZHVsMDRRUmFtQXRtZllOMTZMSkRWRVd6ZFFVSXBnQjc3SHNjT0ZF?=
 =?utf-8?B?Y0E9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: renesas.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: OSOPR01MB12408.jpnprd01.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ad3b8a7e-930d-4047-b962-08ddb3d30a8f
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2025 10:28:35.2520
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 53d82571-da19-47e4-9cb4-625a166a4a2a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 57e7D9NLGAr3/P/SNj8vhuEo+qwbcAg1Bg4ryJ087CQjV3IeANuMQjv87JO/UzG8EV4Mjlww4CB2RnEokaT/KoeJwY4CdZCxp8dvYYQczVs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSCPR01MB14757

SGkgTWljaGFsLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3IGFuZCB0aGUgQWNrLg0KDQo+
PiArICAgIGRzYihzeSk7DQo+IEFueSBjbHVlIHdoeSBMaW51eCAobWFpbmxpbmUpIGRvZXMgbm90
IGRvIHRoYXQ/DQoNClRoZSBpbXBsZW1lbnRhdGlvbiB3cml0ZWwoKSB3aGljaCBjb250YWlucyBh
biBpbXBsaWNpdCBkc2Ioc3QpIHdoaWNoIGxpa2VseSBzdWZmaWNpZW50IGZvciBMaW51eCBmb3Ig
aXRzIFN0YWdlLTEgSU9NTVUgdXNhZ2Ugd2hlcmUgQ1BVIGFuZCBJT01NVSBpbnRlcmFjdGlvbnMg
YXJlIGNvaGVyZW50LiANCkhvd2V2ZXIsIFhlbiB1c2VzIHRoZSBJUE1NVSBhcyBhIFN0YWdlLTIg
SU9NTVUgZm9yIG5vbi1jb2hlcmVudCBETUEgb3BlcmF0aW9ucyAoc3VjaCBhcyBQQ0llIHBhc3N0
aHJvdWdoKSwgcmVxdWlyaW5nIHRoZSBzdHJvbmdlciBkc2Ioc3kpIHRvIGVuc3VyZSB3cml0ZXMg
ZnVsbHkgcHJvcGFnYXRlIHRvIHRoZSBJUE1NVSBoYXJkd2FyZSBiZWZvcmUgY29udGludWluZy4N
Cg0KUmVnYXJkcywNCkphaGFuIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog
T3J6ZWwsIE1pY2hhbCA8bWljaGFsLm9yemVsQGFtZC5jb20+IA0KU2VudDogMjMgSnVuZSAyMDI1
IDEyOjU2DQpUbzogSmFoYW4gTXVydWRpIDxqYWhhbi5tdXJ1ZGkuemdAcmVuZXNhcy5jb20+OyB4
ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcNCkNjOiBTdGVmYW5vIFN0YWJlbGxpbmkgPHNz
dGFiZWxsaW5pQGtlcm5lbC5vcmc+OyBKdWxpZW4gR3JhbGwgPGp1bGllbkB4ZW4ub3JnPjsgQmVy
dHJhbmQgTWFycXVpcyA8YmVydHJhbmQubWFycXVpc0Bhcm0uY29tPjsgVm9sb2R5bXlyIEJhYmNo
dWsgPHZvbG9keW15cl9iYWJjaHVrQGVwYW0uY29tPg0KU3ViamVjdDogUmU6IFtQQVRDSF0geGVu
L2FybTogRW5oYW5jZSBJUE1NVS1WTVNBIGRyaXZlciByb2J1c3RuZXNzIGFuZCBkZWJ1ZyBvdXRw
dXQNCg0KDQoNCk9uIDIwLzA2LzIwMjUgMTI6MzEsIEphaGFuIE11cnVkaSB3cm90ZToNCj4gLSBG
aXggdHlwbyBpbiBzb3VyY2UgY29tbWVudCAoInlvdSBjYW4gZm91bmQiIC0+ICJ3aGljaCBjYW4g
YmUgZm91bmQiKS4NCj4gLSBBZGQgZHNiKHN5KSBhZnRlciBJTUNUUiB3cml0ZSB0byBlbnN1cmUg
Zmx1c2ggaXMgY29tcGxldGUgYmVmb3JlIHBvbGxpbmcuDQo+IC0gQWRkIGRldl9pbmZvKCkgbG9n
IGluIGlwbW11X2RldmljZV9yZXNldCgpIHRvIGluZGljYXRlIHRoZSBudW1iZXIgb2YgZGlzYWJs
ZWQgY29udGV4dHMuDQo+IA0KPiBUaGVzZSBjaGFuZ2VzIGltcHJvdmUgbWVtb3J5IG9wZXJhdGlv
biBvcmRlcmluZywgY29kZSByZWFkYWJpbGl0eSwgYW5kIA0KPiBydW50aW1lIHRyYWNlYWJpbGl0
eSBmb3IgSVBNTVUgb24gUi1DYXIgR2VuMy9HZW40IFNvQ3MNCj4gDQo+IFNpZ25lZC1vZmYtYnk6
IEphaGFuIE11cnVkaSA8amFoYW4ubXVydWRpLnpnQHJlbmVzYXMuY29tPg0KQWNrZWQtYnk6IE1p
Y2hhbCBPcnplbCA8bWljaGFsLm9yemVsQGFtZC5jb20+DQoNCj4gLS0tDQo+ICB4ZW4vZHJpdmVy
cy9wYXNzdGhyb3VnaC9hcm0vaXBtbXUtdm1zYS5jIHwgNiArKysrKy0NCj4gIDEgZmlsZSBjaGFu
Z2VkLCA1IGluc2VydGlvbnMoKyksIDEgZGVsZXRpb24oLSkNCj4gDQo+IGRpZmYgLS1naXQgYS94
ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vaXBtbXUtdm1zYS5jIA0KPiBiL3hlbi9kcml2ZXJz
L3Bhc3N0aHJvdWdoL2FybS9pcG1tdS12bXNhLmMNCj4gaW5kZXggZDgyOGQ5Y2Y2YS4uZGFjMGRk
NmQ0NiAxMDA2NDQNCj4gLS0tIGEveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYXJtL2lwbW11LXZt
c2EuYw0KPiArKysgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hcm0vaXBtbXUtdm1zYS5jDQo+
IEBAIC0xMyw3ICsxMyw3IEBADQo+ICAgKg0KPiAgICogQmFzZWQgb24gTGludXgncyBJUE1NVS1W
TVNBIGRyaXZlciBmcm9tIFJlbmVzYXMgQlNQOg0KPiAgICogICAgZHJpdmVycy9pb21tdS9pcG1t
dS12bXNhLmMNCj4gLSAqIHlvdSBjYW4gZm91bmQgYXQ6DQo+ICsgKiB3aGljaCBjYW4gYmUgZm91
bmQgYXQ6DQo+ICAgKiAgICB1cmw6IGdpdDovL2dpdC5rZXJuZWwub3JnL3B1Yi9zY20vbGludXgv
a2VybmVsL2dpdC9ob3Jtcy9yZW5lc2FzLWJzcC5naXQNCj4gICAqICAgIGJyYW5jaDogdjQuMTQu
NzUtbHRzaS9yY2FyLTMuOS42DQo+ICAgKiAgICBjb21taXQ6IGUyMDZlYjViODFhNjBlNjRjMzVm
YmMzYTk5OWIxYTBkYjJiOTgwNDQNCj4gQEAgLTQzMyw2ICs0MzMsOCBAQCBzdGF0aWMgdm9pZCBp
cG1tdV90bGJfaW52YWxpZGF0ZShzdHJ1Y3QgaXBtbXVfdm1zYV9kb21haW4gKmRvbWFpbikNCj4g
ICAgICBkYXRhIHw9IElNQ1RSX0ZMVVNIOw0KPiAgICAgIGlwbW11X2N0eF93cml0ZV9hbGwoZG9t
YWluLCBJTUNUUiwgZGF0YSk7DQo+ICANCj4gKyAgICAvKiBGb3JjZSBJTUNUUiB3cml0ZSB0byBj
b21wbGV0ZSBiZWZvcmUgcG9sbGluZyB0byBhdm9pZCBmYWxzZSBjb21wbGV0aW9uIGNoZWNrLiAq
Lw0KPiArICAgIGRzYihzeSk7DQpBbnkgY2x1ZSB3aHkgTGludXggKG1haW5saW5lKSBkb2VzIG5v
dCBkbyB0aGF0Pw0KDQp+TWljaGFsDQoNCg==


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 10:33:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 10:33:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024677.1400507 (Exim 4.92)
	(envelope-from )
	id 1uUNRH-00083z-Ug; Wed, 25 Jun 2025 10:33:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024677.1400507; Wed, 25 Jun 2025 10:33: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 1uUNRH-00083s-SB; Wed, 25 Jun 2025 10:33:11 +0000
Received: by outflank-mailman (input) for mailman id 1024677;
 Wed, 25 Jun 2025 10:33: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 1uUNRH-00083m-0c
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 10:33:11 +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 c9e7ef65-51af-11f0-a30f-13f23c93f187;
 Wed, 25 Jun 2025 12:33:10 +0200 (CEST)
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 2219F2116D;
 Wed, 25 Jun 2025 10:33:09 +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 F2E0E13AC4;
 Wed, 25 Jun 2025 10:33: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 flnCOWTQW2gkSAAAD6G6ig
 (envelope-from ); Wed, 25 Jun 2025 10:33: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: c9e7ef65-51af-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750847589; 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=7/+BzpDTLyj/g6qTn3N+ge2TUlSpNqc+t5mf+a0g4AA=;
	b=UhG7Z1pVQmJBJbpqFP0gB1L0HYXBM5djkfz/6lxkbS3qQ74sU5L5xzBVbel1e7Vc+A9DdT
	+xWDXv1JTVTcyVRyht08gWTuYo8WWOpa1DCBUnSvZymXGxMbagOo3HQBDWH99t/aAlOk8d
	9eH1pEdIN3EP8UAdad03eKDxqmOwHfg=
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=UhG7Z1pV
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750847589; 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=7/+BzpDTLyj/g6qTn3N+ge2TUlSpNqc+t5mf+a0g4AA=;
	b=UhG7Z1pVQmJBJbpqFP0gB1L0HYXBM5djkfz/6lxkbS3qQ74sU5L5xzBVbel1e7Vc+A9DdT
	+xWDXv1JTVTcyVRyht08gWTuYo8WWOpa1DCBUnSvZymXGxMbagOo3HQBDWH99t/aAlOk8d
	9eH1pEdIN3EP8UAdad03eKDxqmOwHfg=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Anthony PERARD 
Subject: [PATCH] tools/libxenguest: fix build in stubdom environment
Date: Wed, 25 Jun 2025 12:33:06 +0200
Message-ID: <20250625103306.4599-1-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Queue-Id: 2219F2116D
X-Rspamd-Action: no action
X-Spam-Flag: NO
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)[-0.995];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	DKIM_TRACE(0.00)[suse.com:+];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	DNSWL_BLOCKED(0.00)[2a07:de40:b281:106:10:150:64:167:received,2a07:de40:b281:104:10:150:64:97:from];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received];
	RCPT_COUNT_THREE(0.00)[3];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,suse.com:dkim,suse.com:email,imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo]
X-Spam-Score: -3.01
X-Spam-Level: 

With introduction of the new byteswap infrastructure the build of
libxenguest for stubdoms was broken. Fix that again.

Fixes: 60dcff871e34 ("xen/decompressors: Remove use of *_to_cpup() helpers")
Signed-off-by: Juergen Gross 
---
 tools/libs/guest/xg_dom_decompress_unsafe_lzo1x.c | 9 +++++++++
 tools/libs/guest/xg_dom_decompress_unsafe_xz.c    | 2 +-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/tools/libs/guest/xg_dom_decompress_unsafe_lzo1x.c b/tools/libs/guest/xg_dom_decompress_unsafe_lzo1x.c
index ca2f37d915..356f228718 100644
--- a/tools/libs/guest/xg_dom_decompress_unsafe_lzo1x.c
+++ b/tools/libs/guest/xg_dom_decompress_unsafe_lzo1x.c
@@ -25,6 +25,15 @@ static inline uint16_t be16_to_cpu(const uint16_t v)
 #endif
 }
 
+static inline uint32_t be32_to_cpu(const uint32_t v)
+{
+#if BYTE_ORDER == LITTLE_ENDIAN
+	return __builtin_bswap32(v);
+#else
+	return v;
+#endif
+}
+
 #include "../../xen/common/lzo.c"
 #include "../../xen/common/unlzo.c"
 
diff --git a/tools/libs/guest/xg_dom_decompress_unsafe_xz.c b/tools/libs/guest/xg_dom_decompress_unsafe_xz.c
index 1f52875340..0501f7f693 100644
--- a/tools/libs/guest/xg_dom_decompress_unsafe_xz.c
+++ b/tools/libs/guest/xg_dom_decompress_unsafe_xz.c
@@ -25,7 +25,7 @@ static inline uint32_t cpu_to_le32(const uint32_t v)
 #endif
 }
 
-static inline uint32_t le32_to_cpu(const uint32_t p)
+static inline uint32_t le32_to_cpu(const uint32_t v)
 {
 #if BYTE_ORDER == BIG_ENDIAN
 	return __builtin_bswap32(v);
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Jun 25 10:45:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 10:45:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024686.1400518 (Exim 4.92)
	(envelope-from )
	id 1uUNdT-0001Z6-W8; Wed, 25 Jun 2025 10:45:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024686.1400518; Wed, 25 Jun 2025 10: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 1uUNdT-0001Yz-TV; Wed, 25 Jun 2025 10:45:47 +0000
Received: by outflank-mailman (input) for mailman id 1024686;
 Wed, 25 Jun 2025 10:45: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 1uUNdT-0001Yo-8z
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 10:45:47 +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 8a9c5cd3-51b1-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 12:45:42 +0200 (CEST)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-60780d74c8cso9874014a12.2
 for ; Wed, 25 Jun 2025 03:45:42 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-60c2f482e8csm2347719a12.59.2025.06.25.03.45.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 25 Jun 2025 03:45:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8a9c5cd3-51b1-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750848342; x=1751453142; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=dVKTI8M5rR8w941Jup6TIzyhKTqn/6q8Xgpx4N6o1QA=;
        b=pTn2O6t3QQRi016wG/DSEzk6kQlbGwQOBRfm3TrSOHcvtl9AQmwna33PYF4hhXj3wv
         n4N4paxMaTNeuD9WoaAX+rbVFOwd5TRc8ixaQnHyfOzXTJqlTLc+u1r/F4aZdEMdiRTb
         suYRrZgmQsZuHnADNvtKnhGT1xsz7blO+ZIAM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750848342; x=1751453142;
        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=dVKTI8M5rR8w941Jup6TIzyhKTqn/6q8Xgpx4N6o1QA=;
        b=J3D0V8k8XddcYBPSyg93ZGa3RvEqOF1PS/YMo/b2z59/JMOQ4b0ERIrV7d4ka19qyA
         NvCaJkbTLvkpyKTv5TaAxGNyG/0amlIoxtfz0eBu3S7xAVNjXBNvxCc2b+eWCegbFljy
         ZUqox6p+rCpbzmmd3wnTgPrywkUK8K7e9Yr/M9mrlhPmxLFPM6wSS2uiTjzZzcYuWw1r
         /YqwWzLOACob5ytFlB2V2oC2qPR7GDrv2yMNtQVh1uajFx5coUgybF+i4u/NdN8dsDSB
         npkrLovaqPmV99n8TI3lbfyr7cSXmnZ+d1xSmlkcQ7cXpKsKV79+YehPdUEs4atBSZQp
         5Jbg==
X-Forwarded-Encrypted: i=1; AJvYcCXY+/OF/1GfbL6tofHKl1RegAhBZmxP3YJ6pVMCJ3Mpj/woAokC2Ndb9u41FnU8KK77VlOSw5ehLZU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwRxika2EQCJGxu260UZkfmWmE1O12VkLdhZDP8p+y2pEZHPfjO
	LWb1uz8KFtqUFh101Fk/MZYkBjuoCVNuAazmA02SNI3TOBzPUn4j3NYg2AjzsSFfC1E=
X-Gm-Gg: ASbGncujxYZIa9F+gebq10Qs4lXgF3+qrCislZcj6bf6VEihWVdsRFiF7XF4im2EuVq
	SoLE5W9VhBhHMDvzHyPKi+r0NhPDln7ro3jrvsZSdGXAMBQuYw0bAFq24+xpgHOoUFFAXEkc+lI
	NDolFYZGJ1didtudrrUwuyVqOZUWt5SbejI9A4GDvnqRdJIyk6K207uwWHF1fV4qdCLBD3YB0aR
	sPasoPtNKwqiEeVPXe5iFoBuyRBFut0vVhJ2+rT0L/Uzhyg8dvL2Hl5YS/2qp3/VDqYGWDYMPJX
	St+7YBb+fNeHxnsf2u5yzugUhPHOeIoKSHcJioh5FTMcax17BxIAnrZX2Wo7XUNfZsPMLOzBQAf
	3n6Ywp91dXd12E9SO25urtQHWP3c=
X-Google-Smtp-Source: AGHT+IE0hwLOiyQ2WiF3q2CFdxOTFGfZuxpfOZu+PrUcMrwByabyvMTX9jmx9zcoQRCC5YDTJbKQdg==
X-Received: by 2002:a05:6402:2745:b0:608:523c:1365 with SMTP id 4fb4d7f45d1cf-60c4de011d8mr1382759a12.29.1750848342016;
        Wed, 25 Jun 2025 03:45:42 -0700 (PDT)
Message-ID: <23269cf9-778e-4478-bb74-458bf84a9f62@citrix.com>
Date: Wed, 25 Jun 2025 11:45:40 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] tools/libxenguest: fix build in stubdom environment
To: Juergen Gross , xen-devel@lists.xenproject.org
Cc: Anthony PERARD 
References: <20250625103306.4599-1-jgross@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: <20250625103306.4599-1-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 25/06/2025 11:33 am, Juergen Gross wrote:
> With introduction of the new byteswap infrastructure the build of
> libxenguest for stubdoms was broken. Fix that again.
>
> Fixes: 60dcff871e34 ("xen/decompressors: Remove use of *_to_cpup() helpers")
> Signed-off-by: Juergen Gross 

Sorry for breaking this.  The decompressors are an intractable mess.

Acked-by: Andrew Cooper 



From xen-devel-bounces@lists.xenproject.org Wed Jun 25 10:51:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 10:51:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024696.1400527 (Exim 4.92)
	(envelope-from )
	id 1uUNiY-0003FI-KG; Wed, 25 Jun 2025 10:51:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024696.1400527; Wed, 25 Jun 2025 10:51:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUNiY-0003FB-He; Wed, 25 Jun 2025 10:51:02 +0000
Received: by outflank-mailman (input) for mailman id 1024696;
 Wed, 25 Jun 2025 10:51: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 1uUNiW-0003F5-Vh
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 10:51:00 +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 47a47d5b-51b2-11f0-a30f-13f23c93f187;
 Wed, 25 Jun 2025 12:50:59 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-451d7b50815so51455305e9.2
 for ; Wed, 25 Jun 2025 03:50:59 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-45382363f7fsm16389415e9.27.2025.06.25.03.50.58
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 25 Jun 2025 03:50:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 47a47d5b-51b2-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750848659; x=1751453459; 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=eJ6l13ZT3eRbCEJcy5ZWmFHCxqPUIBe+vkntGYJzXXw=;
        b=QlKD1aF6aBihRm+18PV4HiLDxWXihqGIkmE619OqBj8/wFO6PLRVLy139sDgD46Oaa
         p9MfHOxu8KP8NYuce1MYdkHulDD3w83fUy9+K4TSDlqSvEBYhmmPDIKN8IAX96ZgMbEa
         xycWjm7rlNHeX3eRRqMdSzBKHhpG4031NG11M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750848659; x=1751453459;
        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=eJ6l13ZT3eRbCEJcy5ZWmFHCxqPUIBe+vkntGYJzXXw=;
        b=PChX8dJDDrKvXRGRGTCyleo7l2/xZK3mgho4NUyzTd+XWKzFoeJw3cNYDWkMM59n2b
         OMazGoDP/XpWNUJR6mNqdg34kJxLJsN8Fhkj8u5A4ewmMrKt19bkZKMyJXZC9LjK6V8X
         zNwJPuyzVHxX/lKML2sKMVu5a3LbIqrQ/Kl2N156KAdYmeMC4A8fVy8Baed2g6Rbgc/m
         YW8gQXkimOqNxc7nc2AaRBM4wpBHm6cydapp0rbfushbc4+TSs4YJ1m2frpPEVknG3fH
         OieRIGC/PkCySm2WrHqhObu8EvZ731ZjUoPKvXeHQd4dwE8JchgDvf/TI6mK7HEC/zhk
         8nxQ==
X-Gm-Message-State: AOJu0YyjjeG1B514U83oJ59XY11Ud6MuzgppbqYQATynAC3iiasblojY
	YeAAW/AH0VKq2GxOHVOsU38wS10XQ4ucDYd1y7sCt7H9zi8GP2BPNI65wEKQ/ncwdsc=
X-Gm-Gg: ASbGncsULtyY3PfXqITyBctep8AQQ3Vjjfn1rLIoRl5OtiK7Sj+CksVs2MMKAsVrPtN
	E66OSZ/wVzSpyMGoY+2LN7Pmdlwm9jfZD/lOoZdCp9zxEpXDb3mM+jvRud4r70baP/SYW77BZfA
	tUXdrOrqjqvpIi6tjo1BSGLMBhyKbZqzTPCc9GosmTgLUUpvwMAfsseGRKmw3gRn12OFTfMhQQB
	yjeqvO2sFpdHw4Vrju+HXtZvnpuTM69m/RrEYUCQ7ZAQdCxxO+JY96S70zSdxljX8+0wPduKiEB
	mTjDPVbHSX9fRH3vbZZjNjiTJi/nmxyJqBL35aZE9VuRuFki+6BQVMYf1Z6qAT5Gm6okT9wPlQs
	le/at4norRLLv+fF52oRNGo95mOfxDKX2QOn2dvs0
X-Google-Smtp-Source: AGHT+IGLL21mVjMWWaLY1wjOTNBoiZMctgY94sCw6GOMbubN4M9h0f87NGdxZ4772t1eCtXMs6gCqA==
X-Received: by 2002:a05:600c:8b14:b0:441:b3eb:570a with SMTP id 5b1f17b1804b1-45381aafee6mr21855615e9.2.1750848659106;
        Wed, 25 Jun 2025 03:50:59 -0700 (PDT)
Date: Wed, 25 Jun 2025 12:50:57 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com,
	anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org,
	michal.orzel@amd.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: Re: [PATCH v3 2/2] xen/console: unify printout behavior for UART
 emulators
Message-ID: 
References: <20250606201102.2414022-1-dmukhin@ford.com>
 <20250606201102.2414022-3-dmukhin@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250606201102.2414022-3-dmukhin@ford.com>

On Fri, Jun 06, 2025 at 08:11:26PM +0000, dmkhn@proton.me wrote:
> From: Denis Mukhin 
> 
> If virtual UART from domain X prints on the physical console, the behavior is
> updated to (see [1]):
> - console focus in domain X: do not prefix messages;
> - no console focus in domain X: prefix all messages with "(dX)".
> 
> Use guest_printk() in all current in-hypervisor UART emulators. That aligns the
> behavior with debug I/O port 0xe9 handler on x86 and slightly improves the
> logging since guest_printk() already prints the domain ID. guest_printk() was
> modified to account for console focus ownership.
> 
> Modify guest_console_write() for hardware domain case by adding domain ID to
> the message when hwdom does not have console focus.
> 
> [1] https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2412121655360.463523@ubuntu-linux-20-04-desktop/
> Signed-off-by: Denis Mukhin 
> ---
> Changes since v2:
> - dropped rate-limiting change for vuart
> ---
>  xen/arch/arm/vpl011.c      |  6 +++---
>  xen/arch/arm/vuart.c       |  2 +-
>  xen/drivers/char/console.c | 23 +++++++++++++++++++++--
>  3 files changed, 25 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> index 480fc664fc..2b6f2a09bc 100644
> --- a/xen/arch/arm/vpl011.c
> +++ b/xen/arch/arm/vpl011.c
> @@ -87,7 +87,7 @@ static void vpl011_write_data_xen(struct domain *d, uint8_t data)
>      {
>          if ( intf->out_prod == 1 )
>          {
> -            printk("%c", data);
> +            guest_printk(d, "%c", data);
>              intf->out_prod = 0;
>          }
>          else
> @@ -95,7 +95,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("%s", intf->out);
> +            guest_printk(d, "%s", intf->out);
>              intf->out_prod = 0;
>          }
>      }
> @@ -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 bd2f425214..6641f9d775 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, XENLOG_G_DEBUG "%s", uart->buf);
>          uart->idx = 0;
>      }
>      spin_unlock(&uart->lock);
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index 6e77b4af82..3855962af7 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -740,7 +740,17 @@ 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 */
> +            char prefix[16] = "";
> +            struct domain *consd;
> +
> +            consd = console_get_domain();
> +            if ( consd != cd )
> +                snprintf(prefix, sizeof(prefix), "(d%d) ", cd->domain_id);
> +            console_put_domain(consd);
> +
>              nrspin_lock_irq(&console_lock);
> +            if ( prefix[0] != '\0' )
> +                console_send(prefix, strlen(prefix), flags);
>              console_send(kbuf, kcount, flags);
>              nrspin_unlock_irq(&console_lock);
>          }
> @@ -1032,12 +1042,21 @@ void printk(const char *fmt, ...)
>      va_end(args);
>  }
>  
> +/*
> + * Print message from the guest on the diagnostic console.
> + * Prefixes all messages w/ "(dX)" if domain X does not own physical console
> + * focus.
> + */
>  void guest_printk(const struct domain *d, const char *fmt, ...)
>  {
>      va_list args;
> -    char prefix[16];
> +    char prefix[16] = "";
> +    struct domain *consd;
>  
> -    snprintf(prefix, sizeof(prefix), "(d%d) ", d->domain_id);
> +    consd = console_get_domain();
> +    if ( consd != d )
> +        snprintf(prefix, sizeof(prefix), "(d%d) ", d->domain_id);
> +    console_put_domain(consd);

It might be helpful to abstract this into a separate helper, as it's
used by both functions:

static void fill_console_prefix(char *prefix, unsigned int len,
                                const struct domain *d)
{
    struct domain *consd = console_get_domain();

    if ( consd ? consd != d : !is_hardware_domain(d)) )
       snprintf(prefix, len, "(d%d) ", d->domain_id);
    console_put_domain(consd);
}

Note the above code should also handle the current discussion of not
printing the (d0) prefix for the hardware domain when the console
target is Xen.  I think this keeps the previous behavior when console
input is switched to Xen, while still providing unified (dX) prefixes
otherwise.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 10:55:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 10:55:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024703.1400537 (Exim 4.92)
	(envelope-from )
	id 1uUNmV-000423-3F; Wed, 25 Jun 2025 10:55:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024703.1400537; Wed, 25 Jun 2025 10:55: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 1uUNmV-00041w-0i; Wed, 25 Jun 2025 10:55:07 +0000
Received: by outflank-mailman (input) for mailman id 1024703;
 Wed, 25 Jun 2025 10:55: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 1uUNmT-00041q-LL
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 10:55:05 +0000
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com
 [2a00:1450:4864:20::32b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d90136c0-51b2-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 12:55:03 +0200 (CEST)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-450ce671a08so40876635e9.3
 for ; Wed, 25 Jun 2025 03:55:03 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a6e80ff799sm4386288f8f.69.2025.06.25.03.55.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 25 Jun 2025 03:55:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d90136c0-51b2-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750848903; x=1751453703; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=aZ3CvkfRigZNUSteX+mfrw6ugifN4FJ4HOdXg4r1jW4=;
        b=uX15ET4/dpzb56IsN9pE9nMxvZUrjmPBTdWX/WJQ4SOM0FACoM0LhE3I32b679FZDT
         mGOzHG9uI9OZvohDgH/m9qmC0Hd9GG1yWhxOXbVSkOC5dKR2cai5Wo90i74My2oHvguT
         K0tOdhqs4SEadB9sXmNHucgZnUOx5WspsXU28=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750848903; x=1751453703;
        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=aZ3CvkfRigZNUSteX+mfrw6ugifN4FJ4HOdXg4r1jW4=;
        b=Ur+gL3s4FvYKoxL6ZdUPCwKCBJe+NVH7hgWPMhT51mYD82BLwKHy2Em958umrID3RZ
         2C/iGIzEQ71isC9DL4rXszhq7g1u4KFhmhQ6BVJavU6ZZnWG7MrhkKbGHvaMmTjAwXGg
         1Lg6vTapWqXd23MWEiJNZX07SIsexUMxGguQ0i3a7mwhDCHSD0VxAaM4LSGVdiaJgRxr
         ihUj8qn2O9rHoXSkEXxHG6k446vAZVQe2uAbpvBc0nWOo6sYJRIoBmOZY0uUwOEXoPDs
         7OsRQQ6MSq0lj4ijlcSDteO6cMiAnv0NjAHrCPpsytMCQnDX1GPbpp7pbOC3xnmcM6Qx
         7trg==
X-Forwarded-Encrypted: i=1; AJvYcCUdIibGa+iPf+d674xeTxdZCIzgdNzmKmWGRIjOFxhAgaksQ6Gc99DujPEpXCeE5ZfagkdH+6JkyME=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyFc3+yOsUQNQdOxLO+fSj00K8Gy0siGZk5LFqP/cky7TdKW8qB
	2C3nPd/3iMPGWStcyek9tfNri8R2c2v1rgCvxyFgYOPcqOZIREJMJv/Ockw2qWTugLE=
X-Gm-Gg: ASbGncvRMCSNIUQT1JwynkyuQfCZgcJXjFCziuxyU0Jbxt4KK1cToKKjwy57WPOO7Nk
	yQpls5MeUkHAmlh4wObb2O3rrhcinJeHO0sBkE0ybnN+bK9tj9SyVc+Czdc2j1jXgu3fQOxzTSf
	dcRKTPBisqNpwy/Zyv4mPuTC7ubHadLSiMKksoUAgAtQzrCuuBa6E9oP5d1/vCFYccpr89C3gMz
	+dHS90rNlNDozvx/NUrLKrY5zSdAbpxDkrpd0m3efx+n1umtqOkdtBxI0qN/5Hao+3tG7mifEf8
	ySFbjXarAbGI5epm2TzXPcNrrKxOn6wqBLIDEoB4dOij6Z0aYyWf+aTtg+zl4UVK/LgIWTYPVBm
	rVfl3zBmTosP17zBt+B7gI/rbQv0=
X-Google-Smtp-Source: AGHT+IHB28VOsXxGhXQAnKHgpbuV35MKGFbrNdDQrygQ/HYfplzxagAoRdV3DTcjlxlGj9MDu2H54g==
X-Received: by 2002:a05:6000:2308:b0:3a5:2c18:b181 with SMTP id ffacd0b85a97d-3a6ed6769camr1820789f8f.53.1750848903030;
        Wed, 25 Jun 2025 03:55:03 -0700 (PDT)
Message-ID: <889b4c70-076d-4499-b290-f74c34b6c9aa@citrix.com>
Date: Wed, 25 Jun 2025 11:55:01 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/4] x86/idle: Move monitor()/mwait() wrappers into
 cpu-idle.c
To: Jan Beulich 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20250624163951.301743-1-andrew.cooper3@citrix.com>
 <20250624163951.301743-2-andrew.cooper3@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 25/06/2025 10:19 am, Jan Beulich wrote:
> On 24.06.2025 18:39, Andrew Cooper wrote:
>> They're not used by any other translation unit, so shouldn't live in
>> asm/processor.h, which is included almost everywhere.
>>
>> Our new toolchain baseline knows the MONITOR/MWAIT instructions, so use them
>> directly rather than using raw hex.
>>
>> Change the hint/extention parameters from long to int.  They're specified to
>> remain 32bit operands even 64-bit mode.
>>
>> Signed-off-by: Andrew Cooper 
> Reviewed-by: Jan Beulich 

Thanks.

> We may need to undo this though if we ever meant to use mwait elsewhere, like
> for spinlocks. Many years ago that idea was entertained some, but it may well
> be that it was given up altogether by now.

If they need to move back into a header, that's fine, but it will be
something new.

That said, I'm not sure how useful it would be to mwait on a spinlock. 
You'd need the spinlock in its own cacheline or you'll get false wakeups
triggered by CPU which has the has the lock writing adjacent to the
lock.  Transitions in and out of idle like this are almost certainly
more expensive than a pause loop.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 11:01:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 11:01:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024720.1400548 (Exim 4.92)
	(envelope-from )
	id 1uUNsC-0005au-Lv; Wed, 25 Jun 2025 11:01:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024720.1400548; Wed, 25 Jun 2025 11: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 1uUNsC-0005an-JO; Wed, 25 Jun 2025 11:01:00 +0000
Received: by outflank-mailman (input) for mailman id 1024720;
 Wed, 25 Jun 2025 11: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 1uUNsA-0005ZV-K0
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 11:00:58 +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 ab723f13-51b3-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 13:00:56 +0200 (CEST)
Received: by mail-wr1-x444.google.com with SMTP id
 ffacd0b85a97d-3a588da60dfso3859038f8f.1
 for ; Wed, 25 Jun 2025 04:00:56 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4538234be76sm16426865e9.15.2025.06.25.04.00.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 25 Jun 2025 04:00:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ab723f13-51b3-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750849256; x=1751454056; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=KHjmbeTQ4LZd39yfwiq79TAb+cG4TDHCyRzJj6/H7AU=;
        b=ePcYagZGM6SQVvCCijuIm4Ah/QGhEZy7/VaeNLvrakek2Q9hbGqyF4Cm4TcXB58Wqe
         oBUvzVRik6NX41JUjko8v476MnPmonMLS5m662SYK6u6Y25c/kY/kXUePmxSlWZfbjLF
         Tbh5JVh/AmupZxU8qi2f0NuTjpF2vwMYYwAzE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750849256; x=1751454056;
        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=KHjmbeTQ4LZd39yfwiq79TAb+cG4TDHCyRzJj6/H7AU=;
        b=DftaG1p6AHN4ePiNbP/YlUWA6B77zQVV+Wqn0up9Htk/+RneS7FwTodSqKKLo5oYLq
         XCWFUXx/8ETX/rOt104EUZJcj1NnhxjISgPRsrLz4y5DfbLAAGp5M6Z6CUPEIG+CQ4rk
         Lz/U7duWQ1IxhCWWp2QrB5qChk/rmA5bN4yqpGAVJt0ULI15PDWtRrgl1wLNpxzzdpk9
         1Y6HspI2nnFGuNYf8F1OmJnL9cXkdLpwIzP54I5wCdI6HBprn+hQyz5Xs3+uUV6ZKmpk
         qM+LLCksJ60Gm15g5Vs/PU9ZOeqLcyxAWBMfriuovG7/3WNqGOV/6GzifejdBNRqWGhn
         /1kQ==
X-Forwarded-Encrypted: i=1; AJvYcCXm7cnKF2CD4BXazXLGWJlAJ5HTY2qpIJ7Z0DmdnU7Tf/xTtVT2O0bRazbhzrjnTnbAbm9POTvOpVg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyZPzQUBuslB/TLfyOX7Qt44LH/oo6izFTfTSYISZGLKKsd5Hpe
	RZIp7Jbzkvth8hqP5+wE68VTT1EpQcNVYt+n+fllgrlEc1ch8uUMJV//Jcq+5gf+dWc=
X-Gm-Gg: ASbGncsSnXazviDsBhS78u5Tf6SeknhDeBIuXibtgseqJXo7oy6lSvfzGvk8DZbh21S
	hbAPUvn3PRaKe4HASIa1xbGSXd6W5YrH79lZmCODFBgoAOgj4K1chjwkLnFx8orArCOwsdX0Zbe
	haSchj3bsLLZXaFFCM4Szkd1YHjra39J2YWVJZ0Zii3el9p95ARDZZUEqf2K2YZ8UJkNcUh+cEi
	1O3gJX2nmBi+K0HcKPslQvhhCCXaA5+zv2tQxRKdVTA1ZCpMnP6WSTxTxGUO/mIBYJ3uxY0jY7D
	MhN6y8jwe77eEh1qXMgvHMlEfZXf7dbyjvJwEod30ffDN3Q4MSBATuVMki9S63XQspUdSWXA8Dj
	+r+rV3kKuuO3oP5unXgR6JwHRl64=
X-Google-Smtp-Source: AGHT+IFVcrcvwp6B88oqlTRbS/IZ/Cf8MJRZZd8G7i9fXhYVPhmjoD9PkBI0lvJXzPjA9GGvYcAhqg==
X-Received: by 2002:a05:6000:2881:b0:3a4:e5bc:9892 with SMTP id ffacd0b85a97d-3a6ed60dee6mr2069241f8f.21.1750849255825;
        Wed, 25 Jun 2025 04:00:55 -0700 (PDT)
Message-ID: 
Date: Wed, 25 Jun 2025 12:00:54 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/4] x86/idle: Remove MFENCEs for CLFLUSH_MONITOR
To: Jan Beulich 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20250624163951.301743-1-andrew.cooper3@citrix.com>
 <20250624163951.301743-3-andrew.cooper3@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: 7bit

On 25/06/2025 10:25 am, Jan Beulich wrote:
> On 24.06.2025 18:39, Andrew Cooper wrote:
>> Commit 48d32458bcd4 ("x86, idle: add barriers to CLFLUSH workaround") was
>> inherited from Linux and added MFENCEs around the AAI65 errata fix.
>>
>> The SDM now states:
>>
>>   Executions of the CLFLUSH instruction are ordered with respect to each
>>   other and with respect to writes, locked read-modify-write instructions,
>>   and fence instructions[1].
>>
>> with footnote 1 reading:
>>
>>   Earlier versions of this manual specified that executions of the CLFLUSH
>>   instruction were ordered only by the MFENCE instruction.  All processors
>>   implementing the CLFLUSH instruction also order it relative to the other
>>   operations enumerated above.
>>
>> I.e. the MFENCEs came about because of an incorrect statement in the SDM.
> And their exact placement even differed between the two sites.
>
>> The Spec Update (no longer available on Intel's website) simply says "issue a
>> CLFLUSH", with no mention of MFENCEs.
>>
>> As this erratum is specific to Intel, it's fine to remove the the MFENCEs; AMD
>> CPUs of a similar vintage do port otherwise-unordered CLFLUSHs.
> Nit: DYM "sport"? I think the corresponding Linux commit that I once looked
> at has it that way.

Oops, yes I did.

>
>> Move the feature bit into the BUG range (rather than FEATURE), and move the
>> workaround into monitor() itself.
>>
>> The erratum check itself must use setup_force_cpu_cap().  It needs activating
>> if any CPU needs it, not if all of them need it.
>>
>> Fixes: 48d32458bcd4 ("x86, idle: add barriers to CLFLUSH workaround")
>> Fixes: 96d1b237ae9b ("x86/Intel: work around Xeon 7400 series erratum AAI65")
>> Link: https://web.archive.org/web/20090219054841/http://download.intel.com/design/xeon/specupdt/32033601.pdf
>> Signed-off-by: Andrew Cooper 
> Reviewed-by: Jan Beulich 

Thanks.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 11:08:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 11:08:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024727.1400557 (Exim 4.92)
	(envelope-from )
	id 1uUNzn-0006TM-D8; Wed, 25 Jun 2025 11:08:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024727.1400557; Wed, 25 Jun 2025 11:08: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 1uUNzn-0006TF-AK; Wed, 25 Jun 2025 11:08:51 +0000
Received: by outflank-mailman (input) for mailman id 1024727;
 Wed, 25 Jun 2025 11:08: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 1uUNzm-0006T9-Uj
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 11:08:50 +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 c4053f60-51b4-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 13:08:47 +0200 (CEST)
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 D7ACE2119B;
 Wed, 25 Jun 2025 11:08:45 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id B4E1313485;
 Wed, 25 Jun 2025 11:08:45 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id Gk+0Kr3YW2jxUwAAD6G6ig
 (envelope-from ); Wed, 25 Jun 2025 11:08: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: c4053f60-51b4-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750849725; 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=EJnYB4I7T81pzp3oR2TiURRb56pVwU4EOA7kExk3Rfc=;
	b=dVwGoS1LTzDjZP57yLKxu/dDEQIZft4ixJH74JQ2wka5MyjHX0LZ9G/b4a0WwF04vUetrb
	lQBvKi4rAFfh2AlRzdCZuzPqMY30qH9ZvJ74/8qVJ8z2bb1voZ6xw0rkYtETcj/sYEB4GN
	sa+I9dQ+Z7syy47BqNd2ooEDVD9HRaQ=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750849725; 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=EJnYB4I7T81pzp3oR2TiURRb56pVwU4EOA7kExk3Rfc=;
	b=dVwGoS1LTzDjZP57yLKxu/dDEQIZft4ixJH74JQ2wka5MyjHX0LZ9G/b4a0WwF04vUetrb
	lQBvKi4rAFfh2AlRzdCZuzPqMY30qH9ZvJ74/8qVJ8z2bb1voZ6xw0rkYtETcj/sYEB4GN
	sa+I9dQ+Z7syy47BqNd2ooEDVD9HRaQ=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Samuel Thibault 
Subject: [PATCH] stubdom/grub: avoid relying on start_info definition
Date: Wed, 25 Jun 2025 13:08:43 +0200
Message-ID: <20250625110843.24840-1-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
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];
	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:email,suse.com:mid,imap1.dmz-prg2.suse.org:helo];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Level: 
X-Spam-Flag: NO
X-Spam-Score: -2.80

The kexec() function of grub-pv is relying on the exact definition of
start_info from Mini-OS by having an "#undef start_info" and a few
lines later a copy of the Mini-OS definition again.

This is bad practice by making all attempts of Mini-OS to change that
definition impossible.

Avoid that dependency by moving the code fragment in question to the
very end of the source file, allowing to drop the copy of the
definition.

Signed-off-by: Juergen Gross 
---
 stubdom/grub/kexec.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/stubdom/grub/kexec.c b/stubdom/grub/kexec.c
index 3da80b5b4a..2c426cc378 100644
--- a/stubdom/grub/kexec.c
+++ b/stubdom/grub/kexec.c
@@ -209,6 +209,8 @@ static void tpm_hash2pcr(struct xc_dom_image *dom, char *cmdline)
 	shutdown_tpmfront(tpm);
 }
 
+static void call_start_info_hook(struct xc_dom_image *dom);
+
 void kexec(void *kernel, long kernel_size, void *module, long module_size, char *cmdline, unsigned long flags)
 {
     struct xc_dom_image *dom;
@@ -330,10 +332,7 @@ void kexec(void *kernel, long kernel_size, void *module, long module_size, char
         }
 
     /* start info page */
-#undef start_info
-    if ( dom->arch_hooks->start_info )
-        dom->arch_hooks->start_info(dom);
-#define start_info (start_info_union.start_info)
+    call_start_info_hook(dom);
 
     xc_dom_log_memory_footprint(dom);
 
@@ -432,3 +431,10 @@ out:
     allocated = 0;
     xc_interface_close(xc_handle );
 }
+
+static void call_start_info_hook(struct xc_dom_image *dom)
+{
+#undef start_info
+    if ( dom->arch_hooks->start_info )
+        dom->arch_hooks->start_info(dom);
+}
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Jun 25 11:14:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 11:14:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024738.1400567 (Exim 4.92)
	(envelope-from )
	id 1uUO5J-0008LQ-2R; Wed, 25 Jun 2025 11:14:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024738.1400567; Wed, 25 Jun 2025 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 1uUO5I-0008LJ-WA; Wed, 25 Jun 2025 11:14:32 +0000
Received: by outflank-mailman (input) for mailman id 1024738;
 Wed, 25 Jun 2025 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 1uUO5H-0008L5-FG
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 11:14:31 +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 8fe1ade2-51b5-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 13:14:29 +0200 (CEST)
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 BB4481F745;
 Wed, 25 Jun 2025 11:14:28 +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 8FE0813485;
 Wed, 25 Jun 2025 11:14:28 +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 R/yKIRTaW2ifVQAAD6G6ig
 (envelope-from ); Wed, 25 Jun 2025 11:14: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: 8fe1ade2-51b5-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750850068; 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=ebTJSN+LRFMkpgZ0N6d3le5nJ7MpmpJZsubaFSuJRag=;
	b=D9TwRjBkclcK5xmNz6NRX0gdmQzTVySghGcZCgKarn3hCmgFt4kimnMDF+KmD0PsxjzPbA
	WnRndf2/p2gCjL3aQIYiqVmbGnGEbsmppltvw2bgI7aFcuM3dbCOcSqftLUNVCPMDu/lI6
	Cv+ko23dK0QYgh9WgbjIk3YdMFuXVaA=
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=D9TwRjBk
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750850068; 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=ebTJSN+LRFMkpgZ0N6d3le5nJ7MpmpJZsubaFSuJRag=;
	b=D9TwRjBkclcK5xmNz6NRX0gdmQzTVySghGcZCgKarn3hCmgFt4kimnMDF+KmD0PsxjzPbA
	WnRndf2/p2gCjL3aQIYiqVmbGnGEbsmppltvw2bgI7aFcuM3dbCOcSqftLUNVCPMDu/lI6
	Cv+ko23dK0QYgh9WgbjIk3YdMFuXVaA=
From: Juergen Gross 
To: minios-devel@lists.xenproject.org,
	xen-devel@lists.xenproject.org
Cc: samuel.thibault@ens-lyon.org,
	Juergen Gross 
Subject: [MINI-OS PATCH] x86/pv: fix breakage of grub-pv build
Date: Wed, 25 Jun 2025 13:14:26 +0200
Message-ID: <20250625111426.25321-1-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-3.01 / 50.00];
	BAYES_HAM(-3.00)[99.99%];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	MID_CONTAINS_FROM(1.00)[];
	R_MISSING_CHARSET(0.50)[];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	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];
	RCVD_TLS_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	DKIM_TRACE(0.00)[suse.com:+]
X-Spam-Level: 
X-Spam-Flag: NO
X-Rspamd-Queue-Id: BB4481F745
X-Rspamd-Action: no action
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Score: -3.01

grub-pv is relying on start_info being defined, so provide a definition
which can be used.

Fixes: d669a312b2b2 ("x86/pv: remove global start_info")
Signed-off-by: Juergen Gross 
---
 arch/x86/setup.c     | 1 +
 include/hypervisor.h | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/arch/x86/setup.c b/arch/x86/setup.c
index b3fc835a..ed28d940 100644
--- a/arch/x86/setup.c
+++ b/arch/x86/setup.c
@@ -67,6 +67,7 @@ static inline void sse_init(void) {
  * This pointer holds a reference to the start_info struct.
  */
 start_info_t *start_info_ptr;
+EXPORT_SYMBOL(start_info_ptr);
 
 #define hpc_init()
 
diff --git a/include/hypervisor.h b/include/hypervisor.h
index f40bc8c3..d199f039 100644
--- a/include/hypervisor.h
+++ b/include/hypervisor.h
@@ -30,6 +30,8 @@
 #ifdef CONFIG_PARAVIRT
 /* A pointer to the start of day information passed up from the hypervisor. */
 extern start_info_t *start_info_ptr;
+
+#define start_info (*start_info_ptr)
 #else
 int hvm_get_parameter(int idx, uint64_t *value);
 int hvm_set_parameter(int idx, uint64_t value);
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Jun 25 11:22:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 11:22:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024751.1400582 (Exim 4.92)
	(envelope-from )
	id 1uUODH-0001kG-Tk; Wed, 25 Jun 2025 11:22:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024751.1400582; Wed, 25 Jun 2025 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 1uUODH-0001k9-Q5; Wed, 25 Jun 2025 11:22:47 +0000
Received: by outflank-mailman (input) for mailman id 1024751;
 Wed, 25 Jun 2025 11:22:46 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uUODG-0001k2-3q
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 11:22:46 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uUODD-001wzb-26;
 Wed, 25 Jun 2025 11:22:43 +0000
Received: from [15.248.3.91] (helo=[10.24.67.243])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uUODD-001ukM-1G;
 Wed, 25 Jun 2025 11:22: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" 
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=StcuBj2e+ppyM+2Dov7j3fySUk+DdVHI589u5gAKDfs=; b=yGTjDs/cb7Jn6HrVrO0cfK9cLo
	tEYomHToH1aOZBby06VZeyg4MmCkP0TS2kBYsDbzgs69vjNy2dRbl0J5Ba08K/Ofpq6v4xyq40zLk
	zqbohHy/tGyul5l/HPiF6dg8kXvK4LwWVnQLvj7eEmQ6l8Cn0ROkXE5hcCPNLFhvd2PQ=;
Message-ID: <52b27bae-b182-488f-afcb-bdbfbc1a495e@xen.org>
Date: Wed, 25 Jun 2025 12:22:41 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/arm: Enhance IPMMU-VMSA driver robustness and debug
 output
Content-Language: en-GB
To: Jahan Murudi ,
 "Orzel, Michal" ,
 "xen-devel@lists.xenproject.org" 
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250620103123.2174529-1-jahan.murudi.zg@renesas.com>
 <445c5594-a003-4cd8-aa46-8544c0543b1c@amd.com>
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit



On 25/06/2025 11:28, Jahan Murudi wrote:
> Hi Michal,

Hi Jahan,

> 
> Thank you for your review and the Ack.
> 
>>> +    dsb(sy);
>> Any clue why Linux (mainline) does not do that?

One process remark, we typically comment inline rather than pasting a 
quote and replying at the top of the e-mail.

> 
> The implementation writel() which contains an implicit dsb(st) which likely sufficient for Linux for its Stage-1 IOMMU usage where CPU and IOMMU interactions are coherent.
> However, Xen uses the IPMMU as a Stage-2 IOMMU for non-coherent DMA operations (such as PCIe passthrough), requiring the stronger dsb(sy) to ensure writes fully propagate to the IPMMU hardware before continuing.

I don't follow. Are you saying the IPMMU driver in Linux doesn't 
non-coherent DMA operations?

But even if that's the case, I still don't see why non-coherent DMA 
would matter. From my understanding, here we want to make sure the TLB 
walker sees the change before the flush.

So if the TLB walker is coherent with the rest of the system. Then it 
would be similar to the CPU TLBs where we only need a "dsb st" (well we 
use "nshst" because the TLB is in non-shareable domain).

If the walker is not coherent, then that's a different topic.

Anyway, I am not against using "dsb(sy)". It is stronger than necessary 
but also probably not a massive deal in the TLB flush path.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Wed Jun 25 11:34:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 11:34:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024768.1400591 (Exim 4.92)
	(envelope-from )
	id 1uUOOQ-0003X9-SQ; Wed, 25 Jun 2025 11:34:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024768.1400591; Wed, 25 Jun 2025 11:34: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 1uUOOQ-0003X2-PV; Wed, 25 Jun 2025 11:34:18 +0000
Received: by outflank-mailman (input) for mailman id 1024768;
 Wed, 25 Jun 2025 11:34: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 1uUOOO-0003Ww-P7
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 11:34:17 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on2061b.outbound.protection.outlook.com
 [2a01:111:f403:2009::61b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 51ed38a9-51b8-11f0-a30f-13f23c93f187;
 Wed, 25 Jun 2025 13:34:14 +0200 (CEST)
Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
 by SN7PR12MB6931.namprd12.prod.outlook.com (2603:10b6:806:261::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Wed, 25 Jun
 2025 11:34:11 +0000
Received: from PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264]) by PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264%4]) with mapi id 15.20.8857.022; Wed, 25 Jun 2025
 11:34: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: 51ed38a9-51b8-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=YmZZPE1cNI+w8ZQXJXo1tmklHqp3mWlf9qnG45K1nIQkWLbpkF8CUgC7x9/WRdYBVuj7DbH8X1RKnmw4YyTr710G6rKkB7m3pczSJH8El7u7WT04+EiSTUvtQTCJVxkg/+l6tlgCDy2UByZo7BVC3psj7rviVT9dx3Ld4SMzJ/MK1fDAAjHZt+VzQWi4F0qkJd3o59hcdQNKhP73VZm0y99ia1Je0FYj5Hg1WuI3zv4EYri3Y/k6oG2ORH8GfjwfhguMxJvhP4QqFGyeYrgQXJSxaCBYPfbJ4pvn36hC3bnU4w9Uu4LwszvKZYK4PjMNQvTHcxqNPRMfYNIZTphbRA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=UHgeBPvj8ieZL/ZPJDqgX2qU3yp7ZynenHEeu1JWNe0=;
 b=GXepESVnzdadh/ZWmDGIgLoreW4/T4SsQ24XeXyKGf8nZZ64VRrxN7YCjbFNLxWKXfU1AipkYiSMC+eTCgHLY+EHwO9uJG4eZ2Ol4XQfh7ofQjdvHUCM61KdjR+QoCilxGcTR/BlGBq1hflZOXXqVQRVdCaOY1mhapnn22e+7Xayk5hISlHHJfq4qLXEMIzQwyVNdcBiwCQXw0W2/R61M9SCLTnw1oeHB3NAUSXpqC1GbJFWT58Cpal+N/vKpCHBQ0HZ9ouKV1TM/kA+GJhtDP5XNIQUcnLjO8eNnr/OfEkS6d9fkfgkuxir7V8Ih3tCtuqLTwxEMHhv3q6JfQEMPg==
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=UHgeBPvj8ieZL/ZPJDqgX2qU3yp7ZynenHEeu1JWNe0=;
 b=WXv6QM9oGgrk1/IjVknx6cvPBM65/7u9+fC9dWHbOzes9/VcE5IXnG26m+IkwqTWwR0H6h9WQj4G/6hgLSn1vhi3PHLGskJcqdHjl+RqYJVZxTjpnb5TAqR/rkN6J99h96TT85Fdj2aZSLMN2cR+G52dNzZLH7oUcY9/dfCA5As=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <8f27f147-7755-4f78-bf56-884d3035d491@amd.com>
Date: Wed, 25 Jun 2025 12:34:08 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1] xen: fusa: arch_specs: Definition of the Virtual
 Machines' roles
Content-Language: en-GB
To: Yann Sionneau , xen-devel@lists.xenproject.org
References: <20250304183115.2509666-1-ayan.kumar.halder@amd.com>
 
From: Ayan Kumar Halder 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: DU7PR01CA0038.eurprd01.prod.exchangelabs.com
 (2603:10a6:10:50e::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_|SN7PR12MB6931:EE_
X-MS-Office365-Filtering-Correlation-Id: e5dcbcc3-08ba-4577-7cde-08ddb3dc3436
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?RTFnUmZsNXVQVkpoeGo1NU4vQmJYOURmbjJpQ3NwR240N3JtSFhZWjJ6MGgv?=
 =?utf-8?B?Q0JHSkV0QVZFeDJ4RzhSV05SRFVoSTEwNGtyNjlQeDhueklSam5aZG9nOXA3?=
 =?utf-8?B?V1Q1WVJ5QWJ3UDgwUGFTTkRsOEtMeDlSaHphSTAxVnFMNStLalhhbk9zWHIw?=
 =?utf-8?B?Q3haOVJRZHFBUjk4NGFtSnliei9iRkV4UXlTK0k2Sjh5bW90L1lyTHVYZkNa?=
 =?utf-8?B?Q3B4dWFuT21UeTJuRjh4Y2NTQWxZL0hTQ3paMGI2YnZmbGtzNk93ZE9pVTNt?=
 =?utf-8?B?NVFtbytlR1VSaHJBelduWXFBS25MUUNzUTR1WE96Z2RJc3ZoczRLcEZFTVZK?=
 =?utf-8?B?RUdkUlRkd0NrYTNWUXBCTysrU0xJdGJTYnlnNTd1UFJlUGZvbTd1WllBWXB4?=
 =?utf-8?B?SWFwY1hZVnFuMGtTZVJpV0hVbTRZSVZ3bTVFNnFQNGsvb0J6RTQyVFNHNk52?=
 =?utf-8?B?QUcyWGRFN1RLZVlYQlI3bWxBcEV3clVLUEI3UjBsblE0K2F2RUphRWlmVHhj?=
 =?utf-8?B?ZGZJSEtQVGYwbjhKcmdrbFQ2UGwrQ1JGOE82RDU1UVR3T0tBWkF3ZTVDSFA0?=
 =?utf-8?B?Z3ZLMnpvbk5GNlNxNVRnekhOdTBIUzBxRmFOcURQTmxXT2ViZ3pad2E4ME45?=
 =?utf-8?B?dWZobDdHUVU1UzVVcHdneTdhZmhsQXZPa2pkRmdxS2JqMDBJc3NxeThZa2hJ?=
 =?utf-8?B?OEUzZEloTlI2RWVUN0RkemVTUkJjb2R4dGcyNytuelNYd2pvbkUrdlp1MVVP?=
 =?utf-8?B?MUhlRUhaY25sNGlhaW5BcUVTcCt1SDF3b09iSy9zMjllRTZRU3BYMnlWUE1M?=
 =?utf-8?B?aGZObWROT0RPWlRNNUdMT2Jic1JVcEVUNzhqVTVBTWFGWVVRTm9hWDI4eWFH?=
 =?utf-8?B?QjVzTXFKZ3pFMTBqTEhwSnNvc3BhbFpHVUNwNk9aaDdVdk5KajFBam9udW5y?=
 =?utf-8?B?WG1nZEE4dCtXRGtmTnYvRFAwQXBIUzNMY0VOd0FyTm1Nd1h6Y2g1Y0FUWlJt?=
 =?utf-8?B?dUQ0dEpFOHpXZ1Z1LzhNbm5aZzg1TWRuTnAvMm1Jc3locER4NGFTZDFwbktG?=
 =?utf-8?B?Rm5ZeTgzQTMzaStHZEFjcXNIMHdTdlppYStMQ0p3dDlKTlZWcEZxd1NyNjRr?=
 =?utf-8?B?SzJab0JyMmM5ODJjUnNoQ1NRTnplcC9GcXBaWjVLTmNwcDgrZ3kvRWp6azkw?=
 =?utf-8?B?aWcvUU1ya25Dd01uT01ObEpqa05nN0lrSjJGNUQ5WUFGNG1CQUdyUnJubmR3?=
 =?utf-8?B?bUVvVVYxVXd1ZFdJbXRxWllIdGVySE1VN3drZk03dDZ5Q1lxYTZQa2lCd3NW?=
 =?utf-8?B?OTlUUUNUOHFhSWpZNFpkMDNkR245VWlxcnl4OFpITGhIVmZlR2VCMHd4SXJw?=
 =?utf-8?B?Rytvb0RUbDZKcEhPR2lvb2ZLQ05tZ3BsNGEzWE0xdWZYSU83ZTErcnJIWnVp?=
 =?utf-8?B?RjFDb2RLK1dpWnFtTzYwVXFCYnU5cmxzWDgwM1VOQlRlbnZPZTN4cUtWbU84?=
 =?utf-8?B?MElHY0lrSGVoRWlxVjI3ZGlRSFY1M01yK1FCaS90VllXTmFURUVHY0x6VkxK?=
 =?utf-8?B?TTUrcit4YURPc0pHU3ZaMzhqdTExV0FCOEF4bXRQTFNyWVIzcFprVWx3WU9F?=
 =?utf-8?B?c0pUUHdUcWhYbXI2RVQwM0dDSmxUenh3QTI5SWMxejlsaDNRWGYxRG4vU1hh?=
 =?utf-8?B?ZnJBZyszeFlYTWhEWUhrQkpXREZ6bnJjNSszYXIyY0xBNVBFMHRtTVdIS1dt?=
 =?utf-8?B?UHFuV0duQVR4OGd6SWtVQW45QzY1WHRGdE4yVnFtWUFLdXJPSmwzL0k3MWZ2?=
 =?utf-8?Q?CUj6PD92vzN2gcVGe9jrhwkJP8mqUv4pM29ek=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)(376014)(1800799024)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?aXRiZkhzdE1NQmZkUTExWW5hUFdva25TR3drU1pvQUM4WkZSZDlFeWVEemJk?=
 =?utf-8?B?WTVwQXJDVEs2UTd1YmtZQ3NNU21PS1dWblg0SGVEcG1UTExDRUt5Z05qeSs2?=
 =?utf-8?B?Z1ZPSG85RW00ZDN0NmR1VnBQTHFqRzI1dEIvbGQwaXdvQjFmQUZXL1p2dEh2?=
 =?utf-8?B?VWYvd1NxWi9rK0N1QTJwSVRhV3FwYk1PY01EV1RGU3NaTGZ5a2EvOEozeGNu?=
 =?utf-8?B?R3pqaHY0bVpwb1ErVkNjN2hla3JPY1JSWEhRdWpGTVF6V29maUtIQ1VPNHRn?=
 =?utf-8?B?OHg5ZlJlcVdFSVh0ekZDMzQzcGFEbXV5TWZPVWhmY25hN0hZc3dLNldMZVdo?=
 =?utf-8?B?Vm5wbUZwME5BNXRPRmdDc0g3VlFOVlVuQmJIQm94UkRLUWFuWVlOUXBaSng3?=
 =?utf-8?B?bExNQVFVNElGTDd1TEMwTnh2OUhjYTQvZFdkck41ZjVGTHdPa0svWlQxWE41?=
 =?utf-8?B?eldlWEVRMGgyOStZZmxOU09vY3Q1UVZaYjE4Si9VZkxCdEZ4S0lVaUxsekRz?=
 =?utf-8?B?NXFGcVBjRHRXcnE5T0JzN1ZRWC9KdWlXQlpZZFNBQXd3cHcrcFQ0a05JajNh?=
 =?utf-8?B?bWF0dFM3bkhlV2JnMVJJc3U2ZnlqTkRJbEhvcUdJb1JGTVFhaDFRb2VOSmx1?=
 =?utf-8?B?TjRYRkR5VVl1K1dWTjBUcXR1cUFvMENWTzdLMFExYXZEZUVuN2k1WW5udk5I?=
 =?utf-8?B?aEdZcGVWWnk3Nk02YmRxVjcwVW5DQkptZ201VmJQLzRZYlVyWk9HTVl4QmRa?=
 =?utf-8?B?SXpVU1k1TXNWYUhmTE5IWUhTODF6VHR1Q0tkWGEyRDZVYWRSd1BMdm1IcHE1?=
 =?utf-8?B?K0piZ2hWWlJDK2wvU2RnbzllekhpRnRzOGxnSXI2K2VsSXoxbi9CWDhtMzFw?=
 =?utf-8?B?eWpreHRWYnA2NXR2Q3dheEFwVkZrNEc2WkNVVVk4OTYxcDhqNTRubi94NEp5?=
 =?utf-8?B?eDE0dHZNVENPdVdVWXRzQU9HR3JtSzNXeVFGSmw2Mm1LWjZySk1NQXVRTy9E?=
 =?utf-8?B?SEI0cTZOU3RNR1JobjQ4Zi9XN0hvVm1GOE55YnJ1REZTQnFvYytsMjVoQnZu?=
 =?utf-8?B?U3JHRHZqSkE1Mm43SXU2cmlOUmRCQldFT3lMWlorMzROUFJMakNNbUxhUXND?=
 =?utf-8?B?SGhVRHFmdnZVZjRXMkFLMXUxOHo4WnpodWo5blFBYzNHTzN1NFFTb3Bua0xk?=
 =?utf-8?B?TzJHSUUrM21TT1cvazIvUC9RSm80NTlzU0RISm50UVorekhVNlVLb0ZkbGpO?=
 =?utf-8?B?TGZ1WFV6V1FzZTRGa2w5WkYvMmc0M0RKM3BEL0dsU3J4dTZXbXovR3QzVVNT?=
 =?utf-8?B?WXJJSEw5RGNYc3pZRG1TL3ZBVExkaTI1cjhESHRodE5iSnlrT3JSN1Q0b1Rz?=
 =?utf-8?B?UktqejVpQ2Z0a0RieWIvTHAwYkMrOXlzQ3owT1ZiTVBSbE1MSWJibDRta3NT?=
 =?utf-8?B?QnhMTzJGQ0V3M0xORURFQVVkYWxIOVQ0VVlVUzhLanZHMzV2NXYzN2hYMkl4?=
 =?utf-8?B?NlNDd2l5dWxmYVAvajRFdzhHTXJscG1VZGprYlVWbkhvNElPVzBZc25LTUk0?=
 =?utf-8?B?OFZ1VkhpZkkreVQyYWc0cEJ4OStwajFtNkhodlQzVjJ3Mlhoa0Fzdk1qc0J2?=
 =?utf-8?B?N3FoOE9ZdURYb01LK2F0a3VTalNLWHRNOFl5M0JQcTM3K2xhQUt5NzJ4dk1R?=
 =?utf-8?B?YkxOZk9CRXF1Y3V5NXRYYXkrV0dvV3d2ZXdWREZJT0xqU0U1OUVnV3Z2NjVk?=
 =?utf-8?B?aXAzKytTTnk4aFlPU2VpZTUvQklTbU8wSFE1UlZZUTF1R1puZlJKdWpOVktZ?=
 =?utf-8?B?Qm5Qd0Z6N1ZHMUlDQlNMenh1ZU1CU0xsVjZqdnRWNm1IZ3Y3d0FwNXFXUUM4?=
 =?utf-8?B?aGVmT1JQVVBVTGpSMGdERkVNdTZ6d3kycXdxWTJTaTJJUzBUWEJkRjQrTDdT?=
 =?utf-8?B?ZlpOMHptSHhwRUxXc0FHSDloa2VWOFM4OE15VExaVkN5RWpMMHdBN2dQWEU2?=
 =?utf-8?B?QWdpQnJKRGVQVC83MVduY0szL3JiUEQwYStTZHJIZm1LZW9jdVU2SVVERENw?=
 =?utf-8?B?bGV2cGpCbXlreklQczR2OHFzd0tiSjdsUVJWcTNpSy8raEIxV2h1Z3puU3ZK?=
 =?utf-8?Q?B0gT0+1CsXOdIUyPGe+94WKR5?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e5dcbcc3-08ba-4577-7cde-08ddb3dc3436
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jun 2025 11:34:10.9012
 (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: impq7ErkQEtzrJu94GCDwkbwJY4Am7Fr6B75eQ074OE1ZNLIb2n8uVogrOsEUW/xmfi+ABFoflRYw7oWzmJFnQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB6931


On 23/06/2025 10:34, Yann Sionneau wrote:
> CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email.
>
>
> Hi Ayan, Stefano,
Hi Yann,
>
> This doc looks nice overall!
>
> However I do think that maybe the role part should be separate from all
> the explanations about virtio.
>
> I would say virtio deserves its own page.
>
> Also, I'm curious what "FFI" is.

"FFI" is freedom from interference. This term is taken from ISO-26262-6 
Annex D.  As per understanding, FFI for Xen means whether Xen is able to 
prevent or detect and mitigate interference to one or more VM from other 
VMs. The VM/s which cen be protected from interference, can be 
considered for running safety critical tasks.

Now, there are various operations which are used for communication 
between VMs. For eg grants, event channels, shared memory. Also, there 
are operations which have a system wide impact. For eg suspend, power 
off, clock control. Each of them is a potential source of interference 
between VMs. What we need to determine is whether Xen can prevent or 
detect such interferences for any (or a set of) VM/s in a given 
scenario/s using VM roles and other properties. The scenario/s will be 
validated for safety certification (under testing for FFI).

You can find some relevant discussion on "hardware domain and control 
domain separation".

@Bertrand , do you want to add something or correct me ?

- Ayan

>
> Thanks!
>
> Regards,
>
> Yann
>
> On 3/4/25 19:31, Ayan Kumar Halder wrote:
>> From: Stefano Stabellini 
>>
>> Define "Hardware Domain", "Control Domain", "DomUs", "SafeVMs" and
>> "UnsafeVMs".
>>
>> Explain the limitations that VirtIO introduces and the way they affect
>> the defined roles.
>>
>> Signed-off-by: Stefano Stabellini 
>> Signed-off-by: Ayan Kumar Halder 
>> ---
>>    docs/fusa/arch_specs/roles.rst | 200 +++++++++++++++++++++++++++++++++
>>    docs/fusa/index.rst            |   1 +
>>    2 files changed, 201 insertions(+)
>>    create mode 100644 docs/fusa/arch_specs/roles.rst
>>
>> diff --git a/docs/fusa/arch_specs/roles.rst b/docs/fusa/arch_specs/roles.rst
>> new file mode 100644
>> index 0000000000..0b3fe821c3
>> --- /dev/null
>> +++ b/docs/fusa/arch_specs/roles.rst
>> @@ -0,0 +1,200 @@
>> +===============================
>> +Xen Domain Roles and Privileges
>> +===============================
>> +
>> +Roles
>> +=====
>> +
>> +We define the following roles that Xen domains can have:
>> +- Hardware Domain
>> +- Control Domain
>> +- DomU
>> +
>> +In addition, we classify domains based on the criticality of the tasks
>> +they perform:
>> +- SafeVM
>> +- UnSafeVM
>> +
>> +DomU
>> +----
>> +
>> +A DomU is a regular domain without extra privileges to perform
>> +operations that affect other domains or the entire platform. A DomU is
>> +therefore unprivileged and can only affect itself.
>> +
>> +Hardware Domain
>> +---------------
>> +
>> +The Hardware Domain is a domain that has direct access to all hardware
>> +peripherals by default, except for those controlled by Xen (CPU, MMU,
>> +IOMMU, Interrupt Controller, Timers, UART). Hardware resources can be
>> +directly assigned to other domains ("passthrough"), but the default is
>> +that they get assigned to the Hardware Domain. As such, there can only
>> +be one Hardware Domain in the system. The Hardware Domain is not
>> +privileged: it cannot perform operations that affect other domains or
>> +the entire platform.
>> +
>> +In cases where VirtIO is used to share access to physical devices among
>> +multiple domains, the Hardware Domain requires some limited privileges
>> +to run the VirtIO backends.
>> +
>> +Control Domain
>> +--------------
>> +
>> +The Control Domain has full privileges over the system. As such, it can
>> +perform privileged operations, typically implemented as hypercalls, that
>> +affect other domains and even the entire platform, such as platform
>> +reboot. There can only be one Control Domain in the system. A
>> +non-exhaustive list of these operations follows:
>> +
>> +- Reboot other domains
>> +- Reboot and shutdown the platform
>> +- Suspend/resume other domains
>> +- Pause/unpause other domains
>> +
>> +The Control Domain is optional.
>> +
>> +SafeVMs and UnSafeVMs
>> +---------------------
>> +
>> +A SafeVM is a domain running a safety-critical task. An UnsafeVM is a
>> +domain running non-safety-critical software only. No safety-critical
>> +tasks are running in the UnsafeVM.
>> +
>> +The Control Domain must be a SafeVM because the Control Domain has
>> +enough privileges to affect the entire system.
>> +
>> +Without VirtIO (see below), both the Hardware Domain and DomUs can be
>> +SafeVMs or UnsafeVMs. There are no restrictions. For example, the
>> +following configuration is compatible with safety:
>> +
>> +- Hardware Domain: UnsafeVM
>> +- 2x DomU: SafeVMs
>> +- 2x DomU: UnsafeVMs
>> +
>> +Privileges
>> +==========
>> +
>> +Full Privileges
>> +---------------
>> +
>> +A domain with full privileges has unrestricted access to all services
>> +provided by Xen, including the ability to perform operations that impact
>> +other VMs and the entire platform. Only one domain holds these full
>> +privileges: the Control Domain.
>> +
>> +Unprivileged
>> +------------
>> +
>> +An Unprivileged domain lacks special access rights, allowing it to
>> +perform only operations that affect itself without impacting other
>> +domains. For example, an Unprivileged domain cannot map the memory of
>> +another domain.
>> +
>> +VirtIO Privileges
>> +-----------------
>> +
>> +Domains running VirtIO backends, such as QEMU, require specific
>> +privileges over domains with VirtIO frontends to enable proper
>> +functionality. For instance, they need permission to map the memory of
>> +the domain with the VirtIO frontend. These additional privileges are
>> +necessary for standard VirtIO operation but can be removed when using
>> +the VirtIO extensions described in the VirtIO chapter. This is the list
>> +of VirtIO privileges:
>> +- mapping memory of VirtIO frontend domains (foreign map hypercall)
>> +- device model hypercalls targeting VirtIO frontend domains
>> +
>> +VirtIO
>> +======
>> +
>> +VirtIO is a specification and set of drivers to share a physical device
>> +among multiple domains. For example, assuming the Hardware Domain has
>> +access to an Ethernet device, VirtIO provides a way for the Hardware
>> +Domain to allow one or more DomUs to access the Ethernet device.
>> +
>> +VirtIO is based on a frontend/backend architecture: the frontend is a
>> +driver similar to a regular Ethernet device driver (using Ethernet as an
>> +example), running in the DomU. The backend is a "proxy" driver running
>> +in the same domain as the device driver and have direct access to the
>> +device. That domain is typically the Hardware Domain because it is the
>> +default domain for hardware assignment, but it is also possible to run
>> +VirtIO backends in other domains, provided they have been configured with
>> +passthrough access to a physical device. These other domains are called
>> +"Driver Domains," and the limitations discussed in the context of VirtIO
>> +for the Hardware Domain also apply to Driver Domains.
>> +
>> +There are multiple issues in VirtIO that affect freedom from
>> +interference, so deploying VirtIO introduces limits on the configuration
>> +regarding what domains can run safety-critical workloads.
>> +
>> +It is important to note that VirtIO is not the only way for domains to
>> +communicate with each other. Specifically, there are other protocols
>> +such as Argo and plain shared memory that do not have the same
>> +interference concerns.
>> +
>> +FFI: Shared Memory and Interrupts
>> +---------------------------------
>> +
>> +All VirtIO protocols are based on ring buffers over shared memory,
>> +called "VirtQueues." Although there are well-known methods to set up
>> +ring buffers over shared memory that are free from interference, in
>> +practice, the existing VirtIO specification and current frontend/backend
>> +driver implementations do not follow these best practices. Thus, the
>> +ring buffers over shared memory can be a source of interference.
>> +
>> +Given the current state of the VirtIO specification and drivers, it is
>> +recommended that both VirtIO frontends and backends run in UnsafeVMs
>> +only. This way, SafeVMs will not be affected by interference caused by
>> +VirtIO protocols.
>> +
>> +As ring buffers exist over memory shared between domains, it is the
>> +domains' responsibility to ensure they are safe. This is outside of
>> +Xen's responsibility, and out of scope for this document.
>> +
>> +FFI: Memory Mappings
>> +--------------------
>> +
>> +VirtIO expects the backend to access ("map") arbitrary memory addresses
>> +passed by the frontend. In other words, the backend needs to map any
>> +memory of the frontend, which is a privileged operation in Xen.
>> +
>> +Xen implements a Xen-specific extension to VirtIO to address this issue:
>> +"VirtIO with Grants."
>> +
>> +Xen has a feature called the "grant table" that guests can use to
>> +voluntarily share individual memory pages with other domains. This way,
>> +the backend does not need the privilege to map any memory page of the
>> +domain running the frontend, as the frontend whitelists pages for the
>> +backend to access.
>> +
>> +Unless "VirtIO with Grants" is used, to enable VirtIO, a domain with
>> +VirtIO backends (the Hardware Domain or a Driver Domain) is given the
>> +extra privilege of being able to map any memory of domains with VirtIO
>> +frontends.  As this is a source of interference, only UnsafeVMs can run
>> +VirtIO frontends without "VirtIO with Grants".
>> +
>> +FFI: Synchronous Emulation
>> +--------------------------
>> +
>> +VirtIO expects certain operations to be synchronous: the frontend
>> +virtual CPU requesting the operation is fully blocked until the backend
>> +completes the operation. If the backend does nothing, the frontend vCPU
>> +remains blocked. This is a source of interference.
>> +
>> +When VirtIO is enabled, the domain with the backends (Hardware Domain or
>> +Driver Domain) implements these synchronous operations for domains
>> +running VirtIO frontends.
>> +
>> +Xen implements a Xen-specific extensions to VirtIO to address this
>> +issue: "non-blocking VirtIO." Two extra virtio-pci registers are
>> +provided, allowing the frontend to perform non-blocking operations. By
>> +using the two Xen-specific non-blocking registers, the frontend virtual
>> +CPU doesn't have to block while waiting for the backend to complete the
>> +operations.
>> +
>> +Unless "non-blocking VirtIO" is used, to enable VirtIO, a domain with
>> +VirtIO backends (the Hardware Domain or a Driver Domain) is given the
>> +extra privilege of being able to implement these synchronous operations
>> +for domains running VirtIO frontends. As this is a source of
>> +interference, only UnsafeVMs can run VirtIO frontends without
>> +"non-blocking VirtIO."
>> diff --git a/docs/fusa/index.rst b/docs/fusa/index.rst
>> index 5f1e8acfc4..9d989f5105 100644
>> --- a/docs/fusa/index.rst
>> +++ b/docs/fusa/index.rst
>> @@ -7,3 +7,4 @@ Functional Safety documentation
>>       :maxdepth: 2
>>
>>       reqs/index
>> +   arch_specs/roles
>
> Yann Sionneau | Vates XCP-ng Developer
>
> XCP-ng & Xen Orchestra - Vates solutions
>
> web: https://vates.tech
>
>


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 11:37:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 11:37:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024779.1400602 (Exim 4.92)
	(envelope-from )
	id 1uUORh-00048w-Ew; Wed, 25 Jun 2025 11:37:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024779.1400602; Wed, 25 Jun 2025 11:37: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 1uUORh-00048p-BH; Wed, 25 Jun 2025 11:37:41 +0000
Received: by outflank-mailman (input) for mailman id 1024779;
 Wed, 25 Jun 2025 11:37: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 1uUORg-00048h-Do
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 11:37:40 +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 cbb315c5-51b8-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 13:37:38 +0200 (CEST)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-451d54214adso10389695e9.3
 for ; Wed, 25 Jun 2025 04:37:38 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45382368742sm17461245e9.31.2025.06.25.04.37.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 25 Jun 2025 04:37:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cbb315c5-51b8-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750851458; x=1751456258; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ZpK5NSj1AhtrPLmgfwCD34PO938ZfQZnprKBOfrooKQ=;
        b=DHBVjhftQ0TCO4MrXAa16m4l8VwRsz89q6zAbb5bBThh7oye37NDe9xSpeAObwuPOm
         IxMx7HcW8GFJy+0YO71pFST+QFb0nGF2iGF+HzdVfwUk8muaHZ2OEAChQdJNRKu5BBD5
         xk68tIG+NUhdKuRFFKj9MTuyOidVYP/ueY0zg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750851458; x=1751456258;
        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=ZpK5NSj1AhtrPLmgfwCD34PO938ZfQZnprKBOfrooKQ=;
        b=qxuGOamIPE+2R7PLgfOOzWHPHR8WfM0pFr8s6FaMXc50UX0QGPpsv5FWRaIrmKek8v
         0cY3x5N4Mrvilgt7qbrjiN8a6cHtXYr979k3eay/w79FKEwZQH74r1Ik1W3njoKVb+jA
         xe9BDSV7GZWfw3d8MQ8DJc3UFOP9aOGCvj7GbKysaM3/UWxGTert1mOK98yDyk5H//hW
         OvN0UKRcQIwY6u73gX/Ob1FZvCSWiIg5qqJMnU6FDBDzuM5nJ+exYr/AP6UiW/lcHsOr
         3uTT3uMMzP7c+Ewdx4f0as3V3pWGgB1N2N/AqWBEjYt1DSvKGq8K++IdfG5mN7FWSDtm
         ZuVw==
X-Forwarded-Encrypted: i=1; AJvYcCWjIKQ0zA7DeJ6cSF0YTn3yst+nsCIvTKx3t2GbmN6k4TAuA5jKsNFjGVcykBMUS39fcFsZr/E/MRc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxCO1jL2Rql0GoGvrvVy2CqKYdYXMIdn51ABJvrIrGesmFy+MpZ
	bduWl2mz43H1VrAVBAWuKsSPNYKOhRPGrixKJikotx7TayV9dv1Fn6SvL4ybR/QLEOsmVHRYlVs
	kNmfdBbr94Q==
X-Gm-Gg: ASbGncuVIeE9jdgnfORP+1Ck5nYX5d3rcZQtVrDENJraO7+nIbDWkMEWOqIDpHtV0IN
	2x7973xDoVEE49uGzG5T3A/6IQ0qg8ExAoSJYA0vdyYbUH6hyZA0p+wXcqYNZWSHA/0on4iqDG0
	CaUjF4cvzdmZIE0oYsUCMIe+bHPNitO7JP+YPwYDaQ9eZ0Lc3qTvkMMzRYHl3p0fUisGt26QkRp
	6jLDtZ8fWuDakfEqMy11TOuJMeDqxgf3ISPf1/mXk1vQSWdrHoCSIBvAZx4P/qlZ2WeFNsKw/VK
	Z5NuIXbjUR5GjHnqs52926taKhLaurbzRYaOlCb1BzqVmEYqPv6SPa82ryqz5d5HaShKBPJVirx
	AUv57PcAgoD5ye5uxQ6DRDkhJH+k=
X-Google-Smtp-Source: AGHT+IEcBErnnkD1DAqhB1k7m+NFfWfMr8NP9cFcHed69gFbJ0kxhHNXfPRv9DaZR+gCgp1SHHRXSw==
X-Received: by 2002:a05:600c:674a:b0:442:c993:6f94 with SMTP id 5b1f17b1804b1-45381ab2544mr27989235e9.12.1750851457635;
        Wed, 25 Jun 2025 04:37:37 -0700 (PDT)
Message-ID: <5fe410bd-2399-482e-aecd-922094921551@citrix.com>
Date: Wed, 25 Jun 2025 12:37:36 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/boot: move l_bootmap
To: Jan Beulich ,
 "xen-devel@lists.xenproject.org" 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
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 25/06/2025 10:05 am, Jan Beulich wrote:
> Having them in the general .init.data section is somewhat wasteful, due
> to involved padding. Move them into .init.data.page_aligned, and place
> that right after .init.bss.stack_aligned.
>
> Overall .init.data* shrinks by slightly over 2 pages in the build I'm
> looking at.
>
> Signed-off-by: Jan Beulich 

Acked-by: Andrew Cooper 

> ---
> All three tables are merely zero-filled. They could hence even be put in
> .init.bss.page_aligned, yet then we perhaps better wouldn't use .fill
> but .skip there (i.e. a larger diff for little gain). Thoughts?

It makes no difference to the binary.  .init.bss is merged with the rest
of .init, so is a block of real zeroes.

I'd opt for lower churn.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 11:49:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 11:49:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024791.1400612 (Exim 4.92)
	(envelope-from )
	id 1uUOcz-0005xB-EK; Wed, 25 Jun 2025 11:49:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024791.1400612; Wed, 25 Jun 2025 11:49:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUOcz-0005x4-BS; Wed, 25 Jun 2025 11:49:21 +0000
Received: by outflank-mailman (input) for mailman id 1024791;
 Wed, 25 Jun 2025 11:49: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 1uUOcy-0005wy-Ne
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 11:49:20 +0000
Received: from mail-oa1-x2c.google.com (mail-oa1-x2c.google.com
 [2001:4860:4864:20::2c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6d85d56e-51ba-11f0-a30f-13f23c93f187;
 Wed, 25 Jun 2025 13:49:20 +0200 (CEST)
Received: by mail-oa1-x2c.google.com with SMTP id
 586e51a60fabf-2e95ab2704fso3783958fac.3
 for ; Wed, 25 Jun 2025 04:49:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6d85d56e-51ba-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750852158; x=1751456958; 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=tYMA41oHHLLHzp1mzf518OORY00VDkMnuZjpm9G9Xv4=;
        b=feuu1gDJzV9DVWdcvfGrBuN0Y0WTcSTpOfSYjRG1tEn6jXlGwZlAFFX4MLe9nomKjx
         O88ZYr9ele4nPKyLtQcByp+/Wr82bJZK+JWXnvap7euqD/R1q8156W5NTnU0GQYYWx34
         Kp/yYDwocrNK0o8fTBnYyIhzomNTf27nTZO9s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750852158; x=1751456958;
        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=tYMA41oHHLLHzp1mzf518OORY00VDkMnuZjpm9G9Xv4=;
        b=TG6k8J5IiYHjd6AZCTD4bZ+IkZfJe/Lv0fXqkIhBMkgPLCrLcvKksJtjGDgl8dtYjG
         beOJDovLTK3/cm8WOx6xSS1K29LjLSEwqsFQWuPbiOQ9913apn8henGn2smRxE81k31n
         BGqwKPoYmTshBo92AZ5qpoPFU/8U8TD16JkM0hvb1xglMA+XH1n4BAPRHDyTAg3/PjZ4
         46WNV3KU4KjqXMdPvNuoxn9qDLiWMtqncFNcCMk/I3cT1XePla/yP9bsO8IANzuCSQJF
         jVaIKvNWlBJCYDGFuyTULzTQfTotTMjsCCFnZhfPVuaNZ/MJ1sCPOGrG0CevwOft3V20
         nxmQ==
X-Gm-Message-State: AOJu0Yy3Umyf8YRRVXKplS8wySAykRql/WrlF7GLfL62O5ufSoF0EtUH
	7+7h8wfRaUXgiIQLr5Sf/e/TcqY1wRwzFjE6E7IX1IpZnTPxjGRyU+jTVPKKnRQTEU2yFX8SrOe
	PuQW+pLpJy6Y3v59mVsuxie2Ghk7sRyOIRpqVGvWhhF4FtMWl51oAw1M=
X-Gm-Gg: ASbGncvdDPGHZAOmpYhxGekF3MrzheAHpTmbkA8P6Yp97czYMHWvpmMzQ/i2kFi/V7z
	mcULDq+oWJwWwvt99XFiwjgGDS2sJQ5C1DAUEe1+LrbuuWw0ML3ImO3uj1rVsEzWRXO5CvHNrBs
	CBDQ1Wy8Y419Sa5Mb0k0qmcwJ42rdLGec+Jk9x3fm6
X-Google-Smtp-Source: AGHT+IF3pjNyTk164eSFqmO3VlPiQNa2wCEy+2+B1gaXgDFCTNhuRasdwAf/D1U9e/PKlA8zDydrOphwQ38DYlJ25sg=
X-Received: by 2002:a05:6870:14d2:b0:29e:74a0:e03f with SMTP id
 586e51a60fabf-2efb28cff1amr1823269fac.24.1750852158402; Wed, 25 Jun 2025
 04:49:18 -0700 (PDT)
MIME-Version: 1.0
References: <20250612100705.21988-1-frediano.ziglio@cloud.com>
In-Reply-To: <20250612100705.21988-1-frediano.ziglio@cloud.com>
From: Frediano Ziglio 
Date: Wed, 25 Jun 2025 12:49:01 +0100
X-Gm-Features: Ac12FXyJh4-bas7fncV97c2_81NKJPd53UgTnW0spIoZk9LVmfMSQV6_kHr8yP8
Message-ID: 
Subject: Re: [PATCH v2] xen: Strip xen.efi by default
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper , Anthony PERARD , 
	Michal Orzel , Jan Beulich , Julien Grall , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Stefano Stabellini 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 12, 2025 at 11:07=E2=80=AFAM Frediano Ziglio
 wrote:
>
> For xen.gz file we strip all symbols and have an additional
> xen-syms file version with all symbols.
> Make xen.efi more coherent stripping all symbols too.
> xen.efi.elf can be used for debugging.
>
> Signed-off-by: Frediano Ziglio 
> ---
> Changes since v1:
> - avoid leaving target if some command fails
> ---
>  docs/misc/efi.pandoc  |  8 +-------
>  xen/Kconfig.debug     |  9 ++-------
>  xen/Makefile          | 19 -------------------
>  xen/arch/x86/Makefile |  8 +++++---
>  4 files changed, 8 insertions(+), 36 deletions(-)
>
> diff --git a/docs/misc/efi.pandoc b/docs/misc/efi.pandoc
> index 11c1ac3346..c66b18a66b 100644
> --- a/docs/misc/efi.pandoc
> +++ b/docs/misc/efi.pandoc
> @@ -20,13 +20,7 @@ Xen to load the configuration file even if multiboot m=
odules are found.
>  Once built, `make install-xen` will place the resulting binary directly =
into
>  the EFI boot partition, provided `EFI_VENDOR` is set in the environment =
(and
>  `EFI_MOUNTPOINT` is overridden as needed, should the default of `/boot/e=
fi` not
> -match your system). When built with debug info, the binary can be quite =
large.
> -Setting `INSTALL_EFI_STRIP=3D1` in the environment will cause it to be s=
tripped
> -of debug info in the process of installing. `INSTALL_EFI_STRIP` can also=
 be set
> -to any combination of options suitable to pass to `strip`, in case the d=
efault
> -ones don't do. The xen.efi binary will also be installed in `/usr/lib64/=
efi/`,
> -unless `EFI_DIR` is set in the environment to override this default. Thi=
s
> -binary will not be stripped in the process.
> +match your system).
>
>  The binary itself will require a configuration file (names with the `.ef=
i`
>  extension of the binary's name replaced by `.cfg`, and - until an existi=
ng
> diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
> index d14093017e..cafbb1236c 100644
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -147,12 +147,7 @@ config DEBUG_INFO
>           Say Y here if you want to build Xen with debug information. Thi=
s
>           information is needed e.g. for doing crash dump analysis of the
>           hypervisor via the "crash" tool.
> -         Saying Y will increase the size of the xen-syms and xen.efi
> -         binaries. In case the space on the EFI boot partition is rather
> -         limited, you may want to install a stripped variant of xen.efi =
in
> -         the EFI boot partition (look for "INSTALL_EFI_STRIP" in
> -         docs/misc/efi.pandoc for more information - when not using
> -         "make install-xen" for installing xen.efi, stripping needs to b=
e
> -         done outside the Xen build environment).
> +         Saying Y will increase the size of the xen-syms and xen.efi.elf
> +         binaries.
>
>  endmenu
> diff --git a/xen/Makefile b/xen/Makefile
> index 8fc4e042ff..664c4ea7b8 100644
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -488,22 +488,6 @@ endif
>  .PHONY: _build
>  _build: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
>
> -# Strip
> -#
> -# INSTALL_EFI_STRIP, if defined, will cause xen.efi to be stripped befor=
e it
> -# is installed. If INSTALL_EFI_STRIP is '1', then the default option(s) =
below
> -# will be used. Otherwise, INSTALL_EFI_STRIP value will be used as the
> -# option(s) to the strip command.
> -ifdef INSTALL_EFI_STRIP
> -
> -ifeq ($(INSTALL_EFI_STRIP),1)
> -efi-strip-opt :=3D --strip-debug --keep-file-symbols
> -else
> -efi-strip-opt :=3D $(INSTALL_EFI_STRIP)
> -endif
> -
> -endif
> -
>  .PHONY: _install
>  _install: D=3D$(DESTDIR)
>  _install: T=3D$(notdir $(TARGET))
> @@ -530,9 +514,6 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
>                 ln -sf $(T)-$(XEN_FULLVERSION).efi $(D)$(EFI_DIR)/$(T)-$(=
XEN_VERSION).efi; \
>                 ln -sf $(T)-$(XEN_FULLVERSION).efi $(D)$(EFI_DIR)/$(T).ef=
i; \
>                 if [ -n '$(EFI_MOUNTPOINT)' -a -n '$(EFI_VENDOR)' ]; then=
 \
> -                       $(if $(efi-strip-opt), \
> -                            $(STRIP) $(efi-strip-opt) -p -o $(TARGET).ef=
i.stripped $(TARGET).efi && \
> -                            $(INSTALL_DATA) $(TARGET).efi.stripped $(D)$=
(EFI_MOUNTPOINT)/efi/$(EFI_VENDOR)/$(T)-$(XEN_FULLVERSION).efi ||) \
>                         $(INSTALL_DATA) $(TARGET).efi $(D)$(EFI_MOUNTPOIN=
T)/efi/$(EFI_VENDOR)/$(T)-$(XEN_FULLVERSION).efi; \
>                 elif [ "$(D)" =3D "$(patsubst $(shell cd $(XEN_ROOT) && p=
wd)/%,%,$(D))" ]; then \
>                         echo 'EFI installation only partially done (EFI_V=
ENDOR not set)' >&2; \
> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> index ce724a9daa..e0ebc8c73e 100644
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -232,14 +232,16 @@ endif
>         $(MAKE) $(build)=3D$(@D) .$(@F).1r.o .$(@F).1s.o
>         $(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T $(obj)/efi.lds $< \
>               $(dot-target).1r.o $(dot-target).1s.o $(orphan-handling-y) =
\
> -             $(note_file_option) -o $@
> -       $(NM) -pa --format=3Dsysv $@ \
> +             $(note_file_option) -o $@.tmp
> +       $(NM) -pa --format=3Dsysv $@.tmp \
>                 | $(objtree)/tools/symbols --all-symbols --xensyms --sysv=
 --sort \
>                 > $@.map
>  ifeq ($(CONFIG_DEBUG_INFO),y)
> -       $(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) =
-O elf64-x86-64 $@ $@.elf
> +       $(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) =
-O elf64-x86-64 $@.tmp $@.elf
> +       $(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(STRIP) $@=
.tmp
>  endif
>         rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]*
> +       mv -f $@.tmp $@
>  ifeq ($(CONFIG_XEN_IBT),y)
>         $(SHELL) $(srctree)/tools/check-endbr.sh $@
>  endif

Any comments on this version?

Frediano


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 13:02:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 13:02:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024852.1400622 (Exim 4.92)
	(envelope-from )
	id 1uUPlH-00077I-Cb; Wed, 25 Jun 2025 13:01:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024852.1400622; Wed, 25 Jun 2025 13:01: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 1uUPlH-00077B-9q; Wed, 25 Jun 2025 13:01:59 +0000
Received: by outflank-mailman (input) for mailman id 1024852;
 Wed, 25 Jun 2025 13:01: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 1uUPlG-000775-EX
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 13:01:58 +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 9350a033-51c4-11f0-a30f-13f23c93f187;
 Wed, 25 Jun 2025 15:01:57 +0200 (CEST)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-450cf214200so57420725e9.1
 for ; Wed, 25 Jun 2025 06:01:57 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-453823b6d50sm19719255e9.30.2025.06.25.06.01.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 25 Jun 2025 06:01:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9350a033-51c4-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750856517; x=1751461317; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=iHaqTGf8LuQR8idyKtMWvqW1F7bXPkIKvJrDRdEEuGc=;
        b=l66njT3Sqv6jJTbbFEF2ExjTnVCxVdkxxjrjodXdX2xXE6app3w4qxPOIanzvPN/Pz
         I8VdxwfxbxOqdNTShbu9tH+bRltUbtewUcs+WL3P2cHJxQ3tWO1f1/Ibh5NOsVXZ/3Up
         zcQxcjzlCXGbnArQagahBQYzIaSX8YX6JY6Zs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750856517; x=1751461317;
        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=iHaqTGf8LuQR8idyKtMWvqW1F7bXPkIKvJrDRdEEuGc=;
        b=bdnegGmlbmqAVCpSyB8p63lsPvVeg6a3nnHYScSJ/aEClAW44fX/d4hC/9hKcPv5s1
         /ySRxAcBBTs3YjkzzNS8NeLWf7g9PJFC86/oXr1FJWjvYNZ7g5GwYCA+puE4KkIZNLBP
         uBlIwOYEu0hnBvkQOe+N5CWziNrs+wV6vtP/21isYWfpmK1+rYOSDFYSeUK0ntvGZvKh
         dlHQ5IAvZyPg1NF0u0PU3hxn8osK5lynIKRRivbFg26rx/KzDYTtJAvSKRO/8nh2YPlS
         xxwF27cb6hxAyEuqtkjgOScR6nmWSm+2kr+iYfX/OXJnzjYGzrLzcZAZOc0iRvnSgosM
         awlw==
X-Forwarded-Encrypted: i=1; AJvYcCWVP0HZ8P2ZTeMB1MFP8fPekfz4X+ISJy3tF+h3QiKKTk+YemAFXK0veFlgVbSghyir2UeiPJS7u1k=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwVk2ORSFdg3G3tFoYBfD5VRPNba7QdeY0wnvRSmsY+hX7UOfkk
	at+/c313jKvwKBEnmoIaN7WQlZYMHyGBAnqUviYNotzLDSMpALzSH0Jj1lYROe8psp8=
X-Gm-Gg: ASbGnctUSHg6YnBM0HcD5lqY/4xaT8bEGWlPvcyDR291U3m21l2CxdLiw299Z9LPmPw
	0wr5/n/DCGpXa7rf/OxCXEaz4IDPEtby5OAXfZwOOWg55713b79YYdqmNO1Nhlwoe2EKKteffVS
	UPn4cJ0jQtmlTfEQiVPub2K9bc8gBXPAlVPhqokkA1AKn2vVouZar+xROU5tliCjALMF3SP45IL
	TcLPC0onDj44OLXI2rzKKXYmccfW1NICMxFLdB9gjz/K/wqSluOhksc8hztTb1Mm5TwePS8QU5C
	D/0Znj+JJFwenmRSXqa+sw3nqqIIrx7AAs04PgXXhNoM3gWC9/0rivikg3su/HOZJDlhjp3vi7K
	0mQ+qgsS2xe3kAX3oclR3cN4p8hs=
X-Google-Smtp-Source: AGHT+IE39YSbRaXA+8T5eOsd/hstAwz2Rai+6zSwlpSkB4Z99W3q0CTvrIXA9m0BANbqS24MFdHapQ==
X-Received: by 2002:a05:600c:4e47:b0:453:5c30:a2c2 with SMTP id 5b1f17b1804b1-453831fe206mr21899325e9.8.1750856516844;
        Wed, 25 Jun 2025 06:01:56 -0700 (PDT)
Message-ID: <026d2b8c-4b3c-4bc3-955c-732d665e38ba@citrix.com>
Date: Wed, 25 Jun 2025 14:01:55 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/4] Revert part of "x86/mwait-idle: disable IBRS during
 long idle"
To: Jan Beulich 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20250624163951.301743-1-andrew.cooper3@citrix.com>
 <20250624163951.301743-4-andrew.cooper3@citrix.com>
 <86841b35-119a-4265-8ff0-9b8549e8ca52@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: <86841b35-119a-4265-8ff0-9b8549e8ca52@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 25/06/2025 10:58 am, Jan Beulich wrote:
> On 24.06.2025 18:39, Andrew Cooper wrote:
>> Most of the patch (handling of CPUIDLE_FLAG_IBRS) is fine, but the
>> adjustements to mwait_idle() are not.
>>
>> spec_ctrl_{enter,exit}_idle() do more than just alter MSR_SPEC_CTRL.IBRS.  The
>> VERW and RSB stuff are **unsafe** to omit.
>>
>> The only reason this doesn't need an XSA is because no changes were made to
>> the lower level mwait_idle_with_hints(), and thus it remained properly
>> protected.
>>
>> I.e. This change only served to double the expensive operations in the case it
>> was trying to optimise.
>>
>> I have an idea of how to plumb this more nicely, but it requires larger
>> changes to legacy IBRS handling to not make spec_ctrl_enter_idle() vulnerable
>> in other ways.
> What are the concerns here? As it looks skipping the MSR write would look
> to require checking some (per-CPU) conditional. Conditional branches can't
> really be of concern, or the "if (cx->ibrs_disable)" that you're now
> removing again would have been of concern, too.

The conditional branches are what set off alarm bells in the first place.

A conditional branch in enter should be ok; HLT and MWAIT should be
serialising enough.

A conditional branch in exit is not ok without extra safety measures.

I can expand on this in the commit message if you'd like.  I was trying
to not be overly critical...

>  Hence simply a new SCF_
> flag would look to be sufficient, for mwait_idle() to convey the necessary
> info to spec_ctrl_enter_idle()?

I've got a local patch going that route, but it needs more than just an
SCF flag.  This is the "requires larger changes".

>
>>  In the short term, simply take out the perf hit.
>>
>> Fixes: 08acdf9a2615 ("x86/mwait-idle: disable IBRS during long idle")
>> Signed-off-by: Andrew Cooper 
> Reviewed-by: Jan Beulich 
>

Thanks.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 13:20:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 13:20:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024860.1400632 (Exim 4.92)
	(envelope-from )
	id 1uUQ2h-0000Nh-Ol; Wed, 25 Jun 2025 13:19:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024860.1400632; Wed, 25 Jun 2025 13:19:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUQ2h-0000Na-LZ; Wed, 25 Jun 2025 13:19:59 +0000
Received: by outflank-mailman (input) for mailman id 1024860;
 Wed, 25 Jun 2025 13:19: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 1uUQ2f-0000NT-TL
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 13:19:58 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on2060c.outbound.protection.outlook.com
 [2a01:111:f403:2417::60c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1424ac6c-51c7-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 15:19:52 +0200 (CEST)
Received: from DS0PR17CA0015.namprd17.prod.outlook.com (2603:10b6:8:191::23)
 by DM6PR12MB4076.namprd12.prod.outlook.com (2603:10b6:5:213::15) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8880.16; Wed, 25 Jun
 2025 13:19:48 +0000
Received: from CY4PEPF0000EDD5.namprd03.prod.outlook.com
 (2603:10b6:8:191:cafe::af) by DS0PR17CA0015.outlook.office365.com
 (2603:10b6:8:191::23) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8880.17 via Frontend Transport; Wed,
 25 Jun 2025 13:19:47 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CY4PEPF0000EDD5.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.8880.14 via Frontend Transport; Wed, 25 Jun 2025 13:19:47 +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, 25 Jun
 2025 08:19:47 -0500
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, 25 Jun
 2025 08:19:47 -0500
Received: from [172.28.201.131] (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, 25 Jun 2025 08:19:46 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1424ac6c-51c7-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=H+8qn4k01HRV7gla74GZD4VyrYhS1Qtw0aoWd2LBj6rtledNX2GBE/7r6n1umCf3scwnQd6GBSQckBwRt84NKh8SO7WOz7ISLZs9+5oqsgphIVVPU4sXtYEUbRbvFSHn4hkZbpLIKj8MN0jILxS7Zb6k03sI7wPow6rC7fL2bLZVvJ96svkFrgxpFJB7+IUtFEXcJ5R6FJ+VgyUd2UjUjBR0ekqdtC8pMHCtc1Y31Ky3i+b7ba2096vrT7iPqjg39u5MYbkpqUuMlZpJDz5Egwe85bAu+SXq5tgfdYKF/sDcaGt+rDp6DrOc6GZVrF2Ixtkk+24CHrA0pKEnKz0dNg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=gNtbdsYLSFUeeiPyzWY36IScq6lgYjc2TQMbGxRaukg=;
 b=ee1/OiKN6a+qyaqUEOOyoFqiWmEIx4YheNp5ASWKmeEeQOQXJZBLG7SnHemErp8QqtNms/z/OKVW1SxpqJSXVTQmVqz4oPCp6DpI2as8j6Hl6KTzoXYVTfDRXDLmlk/2P2gJUeopfXgiXECpFgncQqtQ1Ju9MezYhsLL/esxCcJrdj7wcUo++F4P+mY61WG1W9wb0DSdE+M+FTwuN1RL58aAVYgVJYpfx/TIoGFNlB53eoDX0eydqDLsLYMMkL3wiLJyJyTfwOz45ilLxHOb9kVVACQ0ac7fHnGMvAuV+h/+8RVeK05RLL6e7dOmYYvvi/7jMHuQ4m4TXF4TOYp5hQ==
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=gNtbdsYLSFUeeiPyzWY36IScq6lgYjc2TQMbGxRaukg=;
 b=gVbG9Udmq+SkR9A2MbaBkhsU3Q3Vl9sJ/uanTecMqGWnzhutLzb/uTwTG25OWWfvJhGFsvueEjLZfbZAgTQUQOP4SXBz08xnU1QrvpCfWkhg1o+0YmKdXm+v7ERi3ytVn2q1uQAnRJ54ZdmW2WnUJfm3/FQ3KnKdHR5XrzOPxLA=
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: <9fd514ce-900d-44e0-bc81-d846e711dc1e@amd.com>
Date: Wed, 25 Jun 2025 09:19:47 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 7/7] mm: allow page scrubbing routine(s) to be arch
 controlled
To: Jan Beulich , "xen-devel@lists.xenproject.org"
	
CC: Andrew Cooper , Julien Grall ,
	Stefano Stabellini , Anthony PERARD
	, Michal Orzel ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Bertrand Marquis
	, Volodymyr Babchuk ,
	Oleksii Kurochko , Shawn Anastasio
	
References: 
 <0d2b44e3-bf6c-40ae-be4f-d0ad2845e925@suse.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 (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000EDD5:EE_|DM6PR12MB4076:EE_
X-MS-Office365-Filtering-Correlation-Id: bb465328-423e-4cf9-9f0e-08ddb3eaf57c
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|1800799024|36860700013|7416014|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?bld0V2Q0V2dqVEpFSWk1cnZ3NEY0bDFabExJN1J1dlJDai9MSVpQTERndUZJ?=
 =?utf-8?B?NW9ybnh3S3BIbzJhVTd2WGJxVVp2aHlFM1ptV0MxUTBLbW0yVXYrVDA2ZVln?=
 =?utf-8?B?d1V3UjBUOUdrTUMzb0wzbmIvMXBMTWZLc0JidGlianFkRGc5bEJNeVhjdzBr?=
 =?utf-8?B?R0F6RnFsTGNORHJmY0VtZjNDbFc5dWp6NGlOdjQwM253SU1sSm1Ba0NVeGFT?=
 =?utf-8?B?cTdlUGNSL1Qwc2JUVUdaUi91aHBBMzBEYU5peVk4WDRubEM3Q0dzTE5mYnpS?=
 =?utf-8?B?bkdzSjYwQTBScCtUZGNLMXJZUHdlYXdma0hSSllnY1p3alZPZDJTdzIyTzBq?=
 =?utf-8?B?VUVNVG1VNHpwNWNocXJpdGM5ZjV3TUo5aFFsRWFBTk1rSmZVRzJHSmVZRTJN?=
 =?utf-8?B?VUVreU5ZYmI0WmFRT0RqQmNVNVk2ZHlUSm9JOEZndE5JNkNDR1IrVU41T0Q3?=
 =?utf-8?B?ZGtnL2YwZXhIYzNTL1VPeGExZWpsZ3hXZXFwK3pRdG42eThibWJWTzJVdFh3?=
 =?utf-8?B?SUtOTTR0K24wQnAweHMxVkZudllPV0lSMWxqUlYxRkNZMDFVUVhGRDRBWVAr?=
 =?utf-8?B?N3E3Nks1a2t6Qk9wUTlMSjZxZG1ad2g4VFFwMWpjOVV1eEQzMmM3N2t6R2VX?=
 =?utf-8?B?NUZTck15Tmk2a01abmhJbnNmQmt1dk9lbDlTV1hyRDBoRFBRV21lamgwcm9l?=
 =?utf-8?B?ZiswMmF3dGVmVk1NRWh6K1ZWeXRBTCtTMWJzbHBtM2U2dGZhQXJkeEJrSno1?=
 =?utf-8?B?U0dVL0tjSE9kdjVWNWZvN2RDbkxQSnlJUEZTRGdYUkk4Q0NxZUhvTXpwMklW?=
 =?utf-8?B?ejN1KzNJVU1MUDhoQzFnOTVOMUtVNUpZZzdLdE56aksrMVhsdnlzZ1J3OE1m?=
 =?utf-8?B?Uk83QkUyM3RyS05JbnhQSWdCOVRxRXZwSDNRUjQrV3NHQmpWd2J6b09sa1Fj?=
 =?utf-8?B?djVLNUpuanFJUXcydXdSWVVRc2w3YVkwY3FjMk1EU1phUUhwOVlOb0RmMkdt?=
 =?utf-8?B?ZGw1V0FQdUNaaUNCTTM5dW1yTXNjTVllOTdSL1pUU1owNFVZaGFHTDdocGVi?=
 =?utf-8?B?YnBCa1J0Sm5nOWZKaXJnN3BLMFdCY2MyY0ZzaTRMWG1nUUVkT2JjWUttemVR?=
 =?utf-8?B?NEFKV2pkRFVHSnlCUXBERHdmeitCU3dDL0htVytQa1dWcC9jZjU5K3J2YTZv?=
 =?utf-8?B?V0puMzNPSVVuSFltc09jdUcycEdWdkdtU3lkU3ppSng4bXp1cHBDYjBRMytU?=
 =?utf-8?B?bUJ0U3Bwb0hSczZybEhrOTh0VXp5OCtXa0hPVjFCZkp4RXAxNDZCNXBtanRG?=
 =?utf-8?B?TmkxTkh6QmxFSDB0Mis2eDZET3d4eFdJaEk0a2JEY0NkeFgycjhWSjEzVzhH?=
 =?utf-8?B?QytRcDNWT0J4MFBmUTg3ZVBCelQ4TEkrMFlMQnZlVGJoZUxBZU03eGVSbnRX?=
 =?utf-8?B?YTgwWjBpTW1ncDNiZlhrUU5qMjZlZXIxaXVyUXFFalh1MXNXcFdBVDZYZENY?=
 =?utf-8?B?UUpPK1czWm51QlNvbldBaDhUNHpRVXBiSVYyY0JnclNuSERwUjlGeHU5SXd5?=
 =?utf-8?B?aGtmVGtTc0hLYUN1MkhVWlIyWG5rSVFkdEFtakM2WUtHNHNSZ3FHenRkaTRh?=
 =?utf-8?B?OGlRcDdqdnFyRm16UGgyWlJQVm9CQTNJUGF4QTd1aTNxbW1tQmgzUGhILzMx?=
 =?utf-8?B?QnpFSHM2NFdZRE00SEo1V0NITExJbjc0RXFCRlRjOGc1YTExd3l0MXFWS1Jq?=
 =?utf-8?B?MXdXOHVvRzZpd1dMRkhLSzdtVE9pMy9Ja2hDQU8xUE5iVjJEbWlsRytHUDBE?=
 =?utf-8?B?Qzl1TFNQdnppWmhlMUJnUDBRRXZ6SEN1elA1dlFkVHZYWkgwWnZOYkF0QkUy?=
 =?utf-8?B?NWppUkVaVHBkaERHcGJoTjhUcXlPNGc4cWw4Rk4wQjJlTmVwQzdJMzBacEhn?=
 =?utf-8?B?emltZDZNa2gvbGQ5UWE2a21ZMnR6ZVpsV0c5VG9mR3pSQVdSUE9tQWwrR0JZ?=
 =?utf-8?B?NHRSRWtkbHZkbXczeXVCWDVUL3ljZ0dUK1lEWTlKczBYQ0pwM2dHTmNacW1t?=
 =?utf-8?Q?CTsCBY?=
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);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jun 2025 13:19:47.7902
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: bb465328-423e-4cf9-9f0e-08ddb3eaf57c
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:
	CY4PEPF0000EDD5.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4076

On 2025-06-25 06:27, Jan Beulich wrote:
> On 16.06.2025 15:02, Jan Beulich wrote:
>> --- /dev/null
>> +++ b/xen/arch/x86/scrub_page.S
>> @@ -0,0 +1,39 @@
>> +        .file __FILE__
>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>> +FUNC(scrub_page_cold)
>> +        mov     $PAGE_SIZE/32, %ecx
>> +        mov     $SCRUB_PATTERN, %rax
>> +
>> +0:      movnti  %rax,   (%rdi)
>> +        movnti  %rax,  8(%rdi)
>> +        movnti  %rax, 16(%rdi)
>> +        movnti  %rax, 24(%rdi)
>> +        add     $32, %rdi
>> +        sub     $1, %ecx
>> +        jnz     0b
>> +
>> +        sfence
>> +        ret
>> +END(scrub_page_cold)
>> +
>> +        .macro scrub_page_stosb
>> +        mov     $PAGE_SIZE, %ecx
>> +        mov     $SCRUB_BYTE_PATTERN, %eax
>> +        rep stosb
>> +        ret
>> +        .endm
>> +
>> +        .macro scrub_page_stosq
>> +        mov     $PAGE_SIZE/8, %ecx
>> +        mov     $SCRUB_PATTERN, %rax
>> +        rep stosq
>> +        ret
>> +        .endm
>> +
>> +FUNC(scrub_page_hot)
>> +        ALTERNATIVE scrub_page_stosq, scrub_page_stosb, X86_FEATURE_ERMS
>> +END(scrub_page_hot)
> 
> Bah, I've noticed only now that I failed to do the ret -> RET conversion here
> during the most recent re-basing.

Good job catching that.  My R-b still applies with the RET fixup.

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 13:20:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 13:20:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024862.1400641 (Exim 4.92)
	(envelope-from )
	id 1uUQ2x-0001bK-Ux; Wed, 25 Jun 2025 13:20:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024862.1400641; Wed, 25 Jun 2025 13: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 1uUQ2x-0001bA-SM; Wed, 25 Jun 2025 13:20:15 +0000
Received: by outflank-mailman (input) for mailman id 1024862;
 Wed, 25 Jun 2025 13: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 1uUQ2w-0000NT-Mh
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 13:20:14 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20629.outbound.protection.outlook.com
 [2a01:111:f403:2413::629])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1f3bd679-51c7-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 15:20:12 +0200 (CEST)
Received: from BY3PR10CA0012.namprd10.prod.outlook.com (2603:10b6:a03:255::17)
 by SJ0PR12MB6685.namprd12.prod.outlook.com (2603:10b6:a03:478::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.28; Wed, 25 Jun
 2025 13:20:09 +0000
Received: from CY4PEPF0000EDD7.namprd03.prod.outlook.com
 (2603:10b6:a03:255:cafe::32) by BY3PR10CA0012.outlook.office365.com
 (2603:10b6:a03:255::17) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8880.17 via Frontend Transport; Wed,
 25 Jun 2025 13:20:09 +0000
Received: from SATLEXMB04.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.8880.14 via Frontend Transport; Wed, 25 Jun 2025 13:20:08 +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, 25 Jun
 2025 08:20:04 -0500
Received: from [172.28.201.131] (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, 25 Jun 2025 08:20:04 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1f3bd679-51c7-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Pk1F/BNOFqnGTOXcapgActkrZIN9/dAZpPEfKyPAN3ldHxxQGenq3++Jp6oCPm/XFD+O2wYAUreASAQ9bnf2//1f8ZeTpDNQcBiiEgx79P9Akjl4Qwcpgnt5+wOiXCEjjVSBFc+HpAHC3LokGJcCxj90BfbFTZyh2PW2Agy+7gm93OnCSjfgAZnXQyRaeE+n5BCM8l6bhl5d1X6tHDT6qPDhT9DwBRen8b6RpbS8fnp3Dbg5/lGZka/ZT7M9LHRGiNPx7ECGcgr4lf9YHcNmf74Uv80rbU8HWZ1VQ0eICofbgWaFnpkgAau8113cYu7UOkvxRpkRiWB7CeMIGbt0eQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=JkKLTSX9uvKnQiiYiqOyGwN0Slh8IS2Jkz/rFIx2Z+U=;
 b=BkYsVCqzpPjUlw4NTuW1JSRokdvxESZKDQBJzJ1aceE3qtudYA5vhWZG+Q5mfJdSNw2ntC+tT3jduSYmQEX1O6d6B/y+BPDAqsgSwr+yckkuc8IchS/ZSECFpC4pzcqDIgQlPArFcpKdkZPqnWeNeRsjtZeUTH1921WkG+mioaOAtTd9lfxqp6//L3VUkNVVPS0iXs5YRkW9wombml/Y/HP08r+9Lkt3nYjRJWpsVkQTUxV/Na5BoKYqxbyWJROHXg7jFc0/y2AiOo64nXRfrhRTO6SXrxWTJF3eF4SC0NryluqAncB8eQrcqelVuMCLOg3H06lVUXo7FCQsWD7AsA==
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=JkKLTSX9uvKnQiiYiqOyGwN0Slh8IS2Jkz/rFIx2Z+U=;
 b=oupqZv09ceEg9CexO+Z8cOBqX6K/MEB+jb6QkuNbz/RwBaIRa4HnPzjSahSONYr74G/eZ8rKjlESP6OSs/D1P0MP3HSaqpeczWIbG7Pv6lv4GnPu7X5iE3vksxJMWlkd+9UcWswx41pjxSCWIJQoxwbVOOS9pQG4c4EDCTyt+e8=
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, 25 Jun 2025 09:20:05 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] tools/libxenguest: fix build in stubdom environment
To: Juergen Gross , 
CC: Anthony PERARD 
References: <20250625103306.4599-1-jgross@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <20250625103306.4599-1-jgross@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: CY4PEPF0000EDD7:EE_|SJ0PR12MB6685:EE_
X-MS-Office365-Filtering-Correlation-Id: bdfc53eb-e84b-422e-f9ed-08ddb3eb01e6
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|376014|82310400026|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?VmRlZU5lTVBEMXBrMDg2Q2s4WHVSYTYyNGJ3encrWDdPdVpQT1FPL2xFdWVo?=
 =?utf-8?B?VkFVKzFaTkJPNUc0anpRWTFSQ0szejVYWEF5eTVLVnA5UU5Xby9kTE1Ock1S?=
 =?utf-8?B?TUsxa1l1b2xsWnZxZnh6bExBU2VXZ0g5ZHJiMWNsdnp0bm9rNjdWUUczaXpQ?=
 =?utf-8?B?MW54VHhncUhmSzlLdHB3L1ova0RYMXI2ZEdxaDFSbkNGenBJZ09YTzdxUTRH?=
 =?utf-8?B?OThRaHRKS3dCLzhQc3N1d2NKN050dG40Q0dXNC9IUkZDNjljWUExdEpQMS9j?=
 =?utf-8?B?NytrWnBibGNqSXVsN0o1OGNQVkYranVGZ3dtU3VLYm91b0lYNU1zL1dYeUhr?=
 =?utf-8?B?RDNnd0Q1Zk8rVFpERi91NzBMWW5GWE9jVTQxQ0hiYURTOG5Hdm9iQXExRTNy?=
 =?utf-8?B?S3F4VWs5YTdraDRMLzl0VXg0V0R1YTFDZUNwcnRCZ2d3V0pISzZNMXplWnFK?=
 =?utf-8?B?L0JCNVQycTZXT09CdllzTUkvazZpMHVEWksvSExCRTJFZE01MlJaVUE0YVBW?=
 =?utf-8?B?WTIwM1R0d1JjU1doWnExNmpUR01sd3BRNTZJMWw0Z0MyeE5iMlNMdFB3OTB4?=
 =?utf-8?B?KzB1T0tKQmw1MEI3MzgrWGRmWTU3OTZoTnhIR0JUMXN2Y014SW02ZzQvREY3?=
 =?utf-8?B?Mms0R0p5cjlWeEc5UmY5ZklsNFNXUkw5S252U3owazFjSE02dDNjZnBoTlZj?=
 =?utf-8?B?YmloeVNIOTRrejNsTDd5TFNGYWgvdnRtSS9UQW5BVXdlUVQ1WXEyUE9laXM5?=
 =?utf-8?B?OXhJd1VMaTcyM0tVa0NkNE9KbHlzWGtvWXJQdERBa0ZoYnpPWndyUnJtVzZ5?=
 =?utf-8?B?dDR0Nm5Femt3UmMrNlpTY09TS20xck5WZTRCUzN1N0RiY3FRRWZ0WExPdHJy?=
 =?utf-8?B?dlFycldYcEt0SHN1WHNXMlJnalZWY2Q4SXd6czFoYksyTXJDMDkrQUc3LzJZ?=
 =?utf-8?B?eWdCM2JTOHEzcThSY0xZY1NqVE8rYXZQZjZRaWx1eXlrY2R6cDBYcUg4SG5B?=
 =?utf-8?B?cmhqVmdySEZoYjkwa2pXRUZLU0tQZW4yS2dIVzU2ZlR0N09CNlhjc3NRQzBW?=
 =?utf-8?B?bWZWMjA1TXJTdE1VM1o4anNpV3ZZbFVWUFpUb1ZxdHlTMmZvSzBvdUlicGNS?=
 =?utf-8?B?TEFoV3N4WXBpSG9udWxYckdYNjRua0hjLzBQSE55aDFUaVdqcHV6bDlrMkNw?=
 =?utf-8?B?NjFnWEZoQVhORWVGVmJKajFwSXVCUVlueU1BT0VOTnFoVTJNUlE4QVVSeHZu?=
 =?utf-8?B?K2czV3YydUFuRGNEamJ2UnIwN0M5TVpUS3RMQXIzUjhuODg5MDcwWklCVjhk?=
 =?utf-8?B?V0lkTUNJeWRkQjVpelQrbXdHUGtXTUt6UzM1WkFSVnZiSG1IZXRvanU1WXlQ?=
 =?utf-8?B?b21YRndHaHlHODVYMDFpZFllL2lxT2JXa0tLR0FKVzJRQWVGYkhsRUFhUHJY?=
 =?utf-8?B?bnhBdDYzT2Z6c0UybnFUK2dCbnRxazc2NDRBTmg4OXluSzRNRUZxVUl6dXhv?=
 =?utf-8?B?NVNqV0p2Q0pnZGhabFAzWFM5TVMrL3NLYmdEYmswWDFReG14YndIbEVhSDRv?=
 =?utf-8?B?UFRoY2lRWmFmVnY5L2xUQTdKMC9mTWFpVi9CbTU3WVZ1OFhTQjhqMUlkNWh0?=
 =?utf-8?B?WkdQNEdPd2Rma2Z0ajNPcUlyR2JJZC9JbE83ejMrS2pFN0JOS2ROOXJlMVV4?=
 =?utf-8?B?TmJ1YzZWN25QTzUrN2R0bzJoK1pTc3VjZkRLdUFmdDV0NithSXVNZzJBTlJJ?=
 =?utf-8?B?ZzJLN2x0clZjYUJHUWRVdTBQVGdSYnZhakRhQld4M3VITjlTa2Zpc3BCUmNY?=
 =?utf-8?B?TWNIVHlYelg5cEpUbEpMV2tpYjRUTHRLcVNyL2Mrd3ZPUXY3SDFJZVlmOVVw?=
 =?utf-8?B?Z1d4SlU0MW85Yk9tWEdUaHlMTTI4VmdIdmVmWWZxUFdjeVpybU1RTlpmV0I4?=
 =?utf-8?B?bWljSlYvL1RGWmNNS0FYbk82R3hrZGJ1eXBIczdDYi9Kc2F5N1RJZ2hsbGUx?=
 =?utf-8?B?MUlXeEdDY21nYlh0OFVzWk83RWhCT1V1R3lRMENJVW02OVJIL2xPOGpiWHRn?=
 =?utf-8?Q?2BnkUy?=
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)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jun 2025 13:20:08.6186
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: bdfc53eb-e84b-422e-f9ed-08ddb3eb01e6
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:
	CY4PEPF0000EDD7.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB6685

On 2025-06-25 06:33, Juergen Gross wrote:
> With introduction of the new byteswap infrastructure the build of
> libxenguest for stubdoms was broken. Fix that again.
> 
> Fixes: 60dcff871e34 ("xen/decompressors: Remove use of *_to_cpup() helpers")
> Signed-off-by: Juergen Gross 

Reviewed-by: Jason Andryuk 


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 13:25:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 13:25:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024876.1400651 (Exim 4.92)
	(envelope-from )
	id 1uUQ8R-0002UT-MQ; Wed, 25 Jun 2025 13:25:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024876.1400651; Wed, 25 Jun 2025 13:25:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUQ8R-0002UM-JO; Wed, 25 Jun 2025 13:25:55 +0000
Received: by outflank-mailman (input) for mailman id 1024876;
 Wed, 25 Jun 2025 13:25: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 1uUQ8Q-0002UF-GH
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 13:25:54 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20602.outbound.protection.outlook.com
 [2a01:111:f403:2414::602])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e9cb5695-51c7-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 15:25:52 +0200 (CEST)
Received: from SN1PR12CA0104.namprd12.prod.outlook.com (2603:10b6:802:21::39)
 by PH7PR12MB5655.namprd12.prod.outlook.com (2603:10b6:510:138::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.25; Wed, 25 Jun
 2025 13:25:48 +0000
Received: from SN1PEPF000397B4.namprd05.prod.outlook.com
 (2603:10b6:802:21:cafe::1f) by SN1PR12CA0104.outlook.office365.com
 (2603:10b6:802:21::39) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8880.17 via Frontend Transport; Wed,
 25 Jun 2025 13:25:48 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF000397B4.mail.protection.outlook.com (10.167.248.58) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8880.14 via Frontend Transport; Wed, 25 Jun 2025 13:25:47 +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, 25 Jun
 2025 08:25:47 -0500
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, 25 Jun
 2025 08:25:47 -0500
Received: from [172.28.201.131] (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, 25 Jun 2025 08:25:46 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e9cb5695-51c7-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=LLnZDTFwgc9a+TdEd2YPIlOkZZbUu3hfkr6KqdMN1Yyr+2B1LnzozAX87O7UQLeFppOea/eQeprsqcp8FILGhYfSSwknkmUQTV1cFyfHwni744snFn88D8oepViIjNYL2rTm6fgagLjdWdpDacaZcu0OLEXy7WCZyUTkF7UA4H87Ux9OMNG8n0+5B2QhUpEAfwy6YcPCFLkqa7SWSTPWXCqT9Qo5l+R9tzWK51dT+Hs85IXNgOdcPQHomS4YBuDYBRA0iVcVD4ftgJS5/Dd6Cr/dhog3czza8zRsseuNz2h7+1Na4MrsSZxLkWRlEEmZA9Oe8erVlqmkb5DLlk4NMA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=7PgfEBNTfs9tlqljiTqfK0ldvGQZopp+kEXzXSsVFMI=;
 b=hwjA95h6z9uCw/nac6YgNOniwV3JE5W+JhgjDWLnPSqcoeulv9mtZc2cvy/ByaWhyHj275NKzxQymdcvNbAOA9WKgEKnsKie5JUTJVbBn4Yvql15zqCLT+rxbzpgn+1G3+H8Wsl+P0Z+rHaNk/+yBIHdzgZ4PVX6eBhdhEqnXvnXz1eTJehErGcgaNZhfqr8XzKfYpwhoFO2MGxck8+zDMisKPaas0BPwYxlLFSZkZk0nd1hPoKe+/Jy5+fO+iZSWreHXLmEeb/VF0PxWKHDlaHHLi3Le1kfJFG5oaTQYNoLZFbnuKLr1AYtMbcRgXQ+zuvPOs/xABWAGGWDgVdRlw==
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=7PgfEBNTfs9tlqljiTqfK0ldvGQZopp+kEXzXSsVFMI=;
 b=g4yVGiCbm2XzXFctSImwjRKMXA37J4++PV2kx1bcaU9C9XiINFMSZ41kyc7R8mI3id7ICX9sCy21D9fEKXUDmodcr+kHxfyRWWyx9V3dkkIsB1ZZbEA9bJG5e5OQl0RukqGMVHROn9okOOycDn1Yguw11ppupBeBWktxzSr0nvU=
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: <9388a4b6-a936-405c-b691-00f606c07fda@amd.com>
Date: Wed, 25 Jun 2025 09:25:48 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] stubdom/grub: avoid relying on start_info definition
To: Juergen Gross , 
CC: Samuel Thibault 
References: <20250625110843.24840-1-jgross@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <20250625110843.24840-1-jgross@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: SN1PEPF000397B4:EE_|PH7PR12MB5655:EE_
X-MS-Office365-Filtering-Correlation-Id: 6e7af79d-636b-4e08-ecdf-08ddb3ebcc28
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|36860700013|376014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?dmpDNDNRdVFYeVJUMEtjV0pOMFdudTl1V3dER0FYY0QyY3pyRVFFOWhsdVI0?=
 =?utf-8?B?aGRWRFljQVF2WjVrU05iakJHSXhSNWJzaEZML0NHeEJ5UG5iQ1NlR2d5VUdn?=
 =?utf-8?B?dWlHVWRmUWc5SUFMNjhoS0Q2TFp1M1FubC9DRXFhSHB5ZHRpaTlPT0d4cFc3?=
 =?utf-8?B?L2IrYW0xcmxQVUdmeVNHVEdFdFRkQ0hQWFlEc0VrM2ZxdzVaNE5vcnJ6cCts?=
 =?utf-8?B?UE9FQUZmYVNzbFRJaVFNYnc2cnpaQi9CVDcrZ0VWMDFCaU1FR1lVZUR4aHNv?=
 =?utf-8?B?a0VhVWs4S3JBSDgxR2NvNGMxYklIM3JGa0t5NXNIcnJueUk5NHQvQXNjMmVF?=
 =?utf-8?B?TFNzbjBDNUwrWktUejMyWkt3Ymt2Z3BkNFlVd1FIbVB4YW1MYVNLR0QwZXMw?=
 =?utf-8?B?MzJ0bCtwbmV0R1pvakFTM2preEUzbktDcG1BZnRqTFF4UVFmK1BLZExRWURG?=
 =?utf-8?B?YlVqT3ZrUFJTSG1uYTlCUkNRd3JSSGNnSkdvYXhsSmFHWmMxU2krY0lweFNO?=
 =?utf-8?B?U1JlZTF3OFlEWURsSGd2ZjFoREdsU0czWCs1Yi9pa01uU3gvL3ZjVE1kc1F1?=
 =?utf-8?B?RTJHZ3ZEVjVCM1JLdllyY2dMTnk0QjZBb0pIZ1dseDB6OTJVeWlHNHNCYUQ5?=
 =?utf-8?B?bERuY2xZWkh3bm5MMlN6c0xqa1ZmWmJBNWFlbnI1ZnJHWHZnVTh6b0NtTWhx?=
 =?utf-8?B?bkIvNHgrNktoYXVnNGZiN0FRdHVxV3lhQ3VxSU5SdldaaENiRUI5ZXpiSm1p?=
 =?utf-8?B?ZEllQUZvdHBES1pWaUl6ZUtxNi9wYVhmQmlnNlZSUS94Y2FabEhlaDE5a2Fs?=
 =?utf-8?B?WEFqREwzelBRV3dGZG1MMXoyQmc0RmNvYWFHWTRDeHdSMmdhUFdacXY1dUFJ?=
 =?utf-8?B?V0NwNWRMdEdXdHg0N2pJYlMvbzk3dkN3NCtvbHZuZVhtN0tSU3ZzUlkwWmFX?=
 =?utf-8?B?L0lFRG4xdjdmNWdFdG1RWlFCV25xS3NxaFBuU1RsUVl2dFozdXk2RkI5VGVR?=
 =?utf-8?B?YjVWWTArWTJPNWFKUStOaXNKNG9KbFNNVHJva3pIYWh4QWFOeHhMREV1cVpv?=
 =?utf-8?B?NlA2UjNRMjlXUUE4RDBGZllQa001MHRvWjBLNGlZT1BFdEhiVVJvTXB4SVpY?=
 =?utf-8?B?Skw4dTRJbHhYZnZVeEFNc29sTVA0dVc2RUxDMmhaZHh5akNFTE0xTnNaMTdK?=
 =?utf-8?B?b1RGWTQ0NkQzWXRSaTljMlNSL1ZxYUk1cmxLM2VCM0NRbHRmckF1ODhBdXAr?=
 =?utf-8?B?a0VDTHhWdnRIY2VWWlRvc1lVWkR4ZEFaa1AyNmRyeHFySzJ6M2s3cGxRL09P?=
 =?utf-8?B?UFNCZjJ6d2QzSGt0Q0VEQXhiYnJkWnJPNDVkYUdBMitGdTl3QnRjSytBMzBR?=
 =?utf-8?B?SEtWektXcnF2WnJOTUhuUEZzNEVxMkFGM0tWZmlYN3g2dytqSE56Q0VZTSt6?=
 =?utf-8?B?RFJFQUluVXBKQ0hYZnNKcDdmTHhkd2JXaUpKUkg5ZFRNU045cXVrbEF3M2F0?=
 =?utf-8?B?Smw1cjlkQ0tuSG9kZWhzU0RtU0U3WG8zcGIrSDZSeElpcUxaQjQrUWdiSWph?=
 =?utf-8?B?bzZlQWdyR0VoUFErVFVsSnNzaTFBTEdzSlhQQVhmUEx0dFNoZ3MzOEc2cEJv?=
 =?utf-8?B?NWNlZ2hjbml5a055MytiS1YzYTNoSC9NYlFFQlRBZFh2RHhGT2tCcFlidlkr?=
 =?utf-8?B?QnRsaTFnTE45Z0lzRXpHOElRdEl1czhqN3p4eTNnL1RrS3NoWEtpWFlBcE93?=
 =?utf-8?B?QmZDTktObkQzWG5jZ1NXa3c2R29wbloxYzFhNnZLV0Z4MW4yOVQ1NTc3RHhm?=
 =?utf-8?B?My8valoyM1ZNWnZsSVFTbW5LR29EUEl6OHVuUUpuZ3Y0am94OEo2VDFsVVdQ?=
 =?utf-8?B?cGV1YWhmUStUNHVMWURWV0kxeVhUcVFPWlZqbnhmaTFpNTFIeFQyNm9kWmxy?=
 =?utf-8?B?YTdMOC9hSEhTMjcxaGNHeHYrQnBPSFJDYk5PSENDajRCbmg5emkyUUJ4Sjdl?=
 =?utf-8?B?RlcyMHZ5WG1Qc283M3VYbGRXN2hJOXVDT2Q3VUVMMVN0RERUejBabDY5WmdJ?=
 =?utf-8?Q?KIjZ3D?=
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)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jun 2025 13:25:47.9741
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 6e7af79d-636b-4e08-ecdf-08ddb3ebcc28
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:
	SN1PEPF000397B4.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB5655

On 2025-06-25 07:08, Juergen Gross wrote:
> The kexec() function of grub-pv is relying on the exact definition of
> start_info from Mini-OS by having an "#undef start_info" and a few
> lines later a copy of the Mini-OS definition again.
> 
> This is bad practice by making all attempts of Mini-OS to change that
> definition impossible.
> 
> Avoid that dependency by moving the code fragment in question to the
> very end of the source file, allowing to drop the copy of the
> definition.
> 
> Signed-off-by: Juergen Gross 

Reviewed-by: Jason Andryuk 


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 13:27:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 13:27:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024882.1400662 (Exim 4.92)
	(envelope-from )
	id 1uUQ9W-000308-VU; Wed, 25 Jun 2025 13:27:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024882.1400662; Wed, 25 Jun 2025 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 1uUQ9W-000301-Sh; Wed, 25 Jun 2025 13:27:02 +0000
Received: by outflank-mailman (input) for mailman id 1024882;
 Wed, 25 Jun 2025 13:27: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 1uUQ9V-0002zo-Kk
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 13:27:01 +0000
Received: from NAM04-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam04on20616.outbound.protection.outlook.com
 [2a01:111:f403:240a::616])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 113110bb-51c8-11f0-a30f-13f23c93f187;
 Wed, 25 Jun 2025 15:27:00 +0200 (CEST)
Received: from SJ0PR03CA0269.namprd03.prod.outlook.com (2603:10b6:a03:3a0::34)
 by CY8PR12MB8214.namprd12.prod.outlook.com (2603:10b6:930:76::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.20; Wed, 25 Jun
 2025 13:26:55 +0000
Received: from SN1PEPF000397B3.namprd05.prod.outlook.com
 (2603:10b6:a03:3a0:cafe::b5) by SJ0PR03CA0269.outlook.office365.com
 (2603:10b6:a03:3a0::34) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8857.30 via Frontend Transport; Wed,
 25 Jun 2025 13:26:54 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF000397B3.mail.protection.outlook.com (10.167.248.57) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8880.14 via Frontend Transport; Wed, 25 Jun 2025 13:26:53 +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, 25 Jun
 2025 08:26:53 -0500
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, 25 Jun
 2025 08:26:53 -0500
Received: from [172.28.201.131] (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, 25 Jun 2025 08:26:52 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 113110bb-51c8-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=bdw3HtkIWS7bzDvQQTgcujC1mPsm0Ap2j/EiXr/P2NnykoLfzY7YnuO5KRzz+kNleZz8nCyGMNDOYzqpOH6wmLOGg3D7xgqpNhKKPqhmkxQxTuUYX4du/fIxecUKHwXCUXrMHOExp8h0twmj6/+Equl8AuiYNNS66G/vR7ZkcSTK0wOQyV49cHbg7AEYDpPxCEJhNC5kEdr/lPV1WKFnpOw0JGXhhbfdH0Rp+ulrTIP+lGVE+IOnv6yG3wz6MlKDOeBmxU2ymvYykPJjXLFdNFzaU/lSSQ+xLzZEL+XEJNNpshmdnVyGM0tyc91vODfEfGkBMw6+P4DEiSB4C5VuCA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=K8wnfYIJML8VKa7z5A0ujjxh/RVxgjvfIFcsjT7Igns=;
 b=Ckwx2JUZFLvZt63uO2c7AkTxRDKMC4gP5qLzSk7m742xqSsIh1k4wygRn760j6JZrfOqPzFkMuPgLQKEMV6OpjBTwEOtFL4jI2YSgksjCbR2aF5ggyt77Z8PyuUA/CCWswK867NufXapAJpX8axFoPGkaG5+w/YczvITx+fWUTOV+h5ZLkCleQu3THODvUnE3Zx+tRqP+KRX+p4VTebvTKUx5/NGcPt9SN5iYnL3duX7j/Ss0c0ASV1l/r83qxGojgOVlKarYnN4MVauJFNKe/nzNFHB4qtdeKDshYndqwbNRzI13UcplG3uBsdnfdeMQ8evHYQjs+u7eiPxEx6zJQ==
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=K8wnfYIJML8VKa7z5A0ujjxh/RVxgjvfIFcsjT7Igns=;
 b=EZw3j7IrxXlIh/hW3Eh/F86jmwmGVpiODQJEyBDOgpRGOoXcKC+jJc5i9qOkmHMZw/HVbuDXKnxOW0Isfpp/a2+la7FapiAeY7PQ8OFiuf5xZ1+TK77J7GfCbwjLFgzoYDXHjNZjj9Nw5muprvmjzLe7WpEwSoTW8DdSEIL9lic=
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: <78c324cf-edbb-4628-a019-ce8cf85a0e0c@amd.com>
Date: Wed, 25 Jun 2025 09:26:49 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [MINI-OS PATCH] x86/pv: fix breakage of grub-pv build
To: Juergen Gross , ,
	
CC: 
References: <20250625111426.25321-1-jgross@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <20250625111426.25321-1-jgross@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: SN1PEPF000397B3:EE_|CY8PR12MB8214:EE_
X-MS-Office365-Filtering-Correlation-Id: abecb1e3-dffb-4c28-a1d0-08ddb3ebf35b
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|36860700013|82310400026|1800799024|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?R3F4ZUd2ZDdxQ3J5ekMzZlRubFltSmIrd2pncEd4SlhWVWZMbHhKTFBzR2wv?=
 =?utf-8?B?cTV1cGRxd0oxWkczZVdQT3N0QkZvbDM1aFB6am5IeVR4TXRjZ1liSFVBdFUv?=
 =?utf-8?B?U2JmSXRzQmZJRG9WUEo5emdHQ3cyUUxNa3FoaEZibkZUUjBMTlJWRFB6M0M0?=
 =?utf-8?B?Q1lxaTYrS1pvVVNjeFVPTUovRnhzS3pXakl5Q3JMTlZJZ2I0YWVWcGJBalF5?=
 =?utf-8?B?UnpuTFNmT21qeUxYZkpWSDhiYXJyZWs2RTFHT25sYzlla1AzK1ppakxwOFdK?=
 =?utf-8?B?MDNPUkNBK2RvWEg1ZlQ0cUtrT2orbzhUdmRGb1RtckRjVVRMb09MampheXZ1?=
 =?utf-8?B?MGxiK0ppaDBScXQ5d0RMZVY0Zlc0L3I2Nk1iaFhKTUV0cmMrZkthYzV5am5i?=
 =?utf-8?B?YkFaeERMbGI5Q3BHbm1oczRFQ2hJV0luWkFvNktxTDdRMDV5cURweWdJdmtt?=
 =?utf-8?B?KzlqMWdGdDVxMjd0OU4ySkpObi9iazBqRmVaaUpKQ2tLYVZxVTVUTmI0OVpO?=
 =?utf-8?B?OEJzV3RjRHpTQ0NzMzFBR25RSlRFQWxmR1hvVHFMcXg0WDRobWg2NkZJaDhD?=
 =?utf-8?B?SGV1WDArMXdZbmxwRnJ3QXlkaFFYeVFJRERkZllvc0l1S1JxSVlDSzlrTUR5?=
 =?utf-8?B?dlM3Z2M0bkcvaTJJRSs3MUtYb2hKaGpQazc1TlpaakszREhRNmZvSk1JQ3cy?=
 =?utf-8?B?ZFZHRFV6YVI3OXhFRnFCSGowNXhVNXppcXBxZkJ6T3ZKdGREVXFmOWwxSFRU?=
 =?utf-8?B?ZWZvZVA2eUNSRWtvbmcvSjM1ckVLMGFHSG1GN3BCUWpMUGNGcGZaOWxySzJl?=
 =?utf-8?B?enF1dFBLS21ycTZxaGpSQWc4Slo5Ly9jcmt3d1Z1MkVIN1k2cDc0RWdrSlRL?=
 =?utf-8?B?RkRIYjFJUW1OaDN6czRHSHVrNGVjbVR5TllBMXFUbTZ2eHVrbHpDQVdzaXhH?=
 =?utf-8?B?bCsvOWw1czUrZHhiTlZpenFFVk5Ud1VvZkRwc1dGTVFoT2ZQT2FyQTM5Zy8x?=
 =?utf-8?B?WE82ek92QU5DWUxKcEhGWDNsOFhCNjRFV2lGWXgzd1pvR2cvNlVHa3FRbkRJ?=
 =?utf-8?B?dnVZbC9udm1hTlc1ZlNWaEdSRmxTTUxIQkQ4Ums0SjBWOCtpUXRnS05lVlNV?=
 =?utf-8?B?UDhWQ2JPLzFTaHBneXlnRkJVc0wzc3d2REFqU1ozTDNmS2hZMmhpbDJEMDR1?=
 =?utf-8?B?dEFnRlVtWjN6TXB4WHFYNzUzaU0zbkMzVGorUWszVnhxcnEyUzlYM1RsWGk1?=
 =?utf-8?B?V2gyWW9HREFtRmVKODhOdmEyVTFVdjlEYlRjRmpaS1M5VnJiU1hjRVFFQ0ts?=
 =?utf-8?B?RWxOSXQrN2oxWU5mODlkK0hOUHJQVHFiZTNhRmRWQTdhdGJRaWF3dWlhZ2cw?=
 =?utf-8?B?RkxvVEJ4VEpCUGFyTWYyK2J3VWFmSUViWmFVdHpYZy9uTlpZN28raDZydkow?=
 =?utf-8?B?UmhCV0pnNXp3Vm96T0ZzdklHck1TRWVWRGNJS3psVmZSeUxnUmN2ZWdUdm9S?=
 =?utf-8?B?bWxQdDhXVGxqYytCaCt0QjhCRmQwVTN5WlFzR2RvY3Q2WWlDSHRWRjJya0tG?=
 =?utf-8?B?L1lxaHA0UkRsWnNCMVpsREJuaUJsVW9WaHVsYnV1MG85QmhZckpBKzdOanpD?=
 =?utf-8?B?TGJSOVNpWUJXMWlMVzhDeEVzRVJ1TSsvSkpuVExRR21rKzh3T0hhVVNOVzkz?=
 =?utf-8?B?K3ZuZTAvUityUDYxTVQvcjNtYlUwMnRYQURCVU5VanJPL3E4Vzl2NW9vMDZE?=
 =?utf-8?B?SHJXckZDQjZXc0xLdGVIUTNPclhnRnJ6cjdtait4R1hoS084TkNxdXRwQVIx?=
 =?utf-8?B?TnQvUDJBbG9Sd2tFSWNPd2czcko3NS9NOVZxWjhrN0ExbXM2MVVEYmwzUDBP?=
 =?utf-8?B?SllVRDJldEFBd0piM3l6SEc3YjZ5ZzlBV29JUEJjc09WWGRKbTBZTUh2cWN4?=
 =?utf-8?B?bmQwRWpQU0pJdzMwb3lISjhCWTRmbFc2TngvcEoyTllGZHJSTXUyQk1weVpz?=
 =?utf-8?B?RGc5VFNVVkxZTnZpZ3ZyNTRZd2lmM2YzcDRrSThtUmMzT28rRGpBeUFja01X?=
 =?utf-8?Q?WtgAJO?=
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)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jun 2025 13:26:53.7376
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: abecb1e3-dffb-4c28-a1d0-08ddb3ebf35b
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:
	SN1PEPF000397B3.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB8214

On 2025-06-25 07:14, Juergen Gross wrote:
> grub-pv is relying on start_info being defined, so provide a definition
> which can be used.
> 
> Fixes: d669a312b2b2 ("x86/pv: remove global start_info")
> Signed-off-by: Juergen Gross 

Reviewed-by: Jason Andryuk 


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 14:06:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 14:06:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024922.1400677 (Exim 4.92)
	(envelope-from )
	id 1uUQlS-0008Qe-Uw; Wed, 25 Jun 2025 14:06:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024922.1400677; Wed, 25 Jun 2025 14:06:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUQlS-0008QU-Pu; Wed, 25 Jun 2025 14:06:14 +0000
Received: by outflank-mailman (input) for mailman id 1024922;
 Wed, 25 Jun 2025 14:06: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 1uUQlR-0008QK-Ly
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 14:06:13 +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 8aa29456-51cd-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 16:06:08 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a365a6804eso1063682f8f.3
 for ; Wed, 25 Jun 2025 07:06:08 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237f7579cddsm76964365ad.202.2025.06.25.07.06.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 25 Jun 2025 07:06:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8aa29456-51cd-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750860368; x=1751465168; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=rYYIcFGkg/MhhG4bT0x9A4wvSzFmJN1/HvQlEZtE7Ck=;
        b=UsdKbXeqyefiJ6CQsfsAflD7dKcDGb3MG2wlmBBdeN0srV9bnOgwUy3znLYUmdZ041
         GJPd0/fMF5dYxG5wRzOHVJ9h8LlMnK2hn5/S1u02NP5q/EAtWgPigFDb3UNXPdlJ3/xy
         BoTt1N86KD++65V2bvKJo8w6u8FptejJnBNGDIUdikordpD3hWRwugV398K49NGS+ufh
         PLSAUbMW8fTzZBXHGqwu8gYM5KntAbhIAytOQ1K+ooETWTiuFkBGm4qZM7Kq8cr2y5Rt
         lf64z0acgiJE2lesFTYDN54y0MsLLvIX5zL+F5d5mpVy+im0FJxfVlKOeKeEyXTYfqaU
         SH1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750860368; x=1751465168;
        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=rYYIcFGkg/MhhG4bT0x9A4wvSzFmJN1/HvQlEZtE7Ck=;
        b=g+xRPzUSp2fSZX6Ejj+kfsEIRFiTMhv1lrS50qY94yAKhhCmveWa0ZgaHSFpXCHtsB
         GpSCdpbvFcsEZIsgUBok9neO+IsXJD4zte8NvuDolJrWmVIbdNmJ2+1AVs2f8BaBdfgY
         vlTMHbCvvCbXbeuwPqQMj/eoAYvUW03E4g/eDYDY6RqqMq5N9sdT/pjZY3zNZNOSyweu
         82Or0AnyUolS8iip8hrqobS/q4ckVEeGHJl+iy0eX2YrbRah09YYjFns8HSjmAmFfGAN
         TyLqvU/t8htvvXC1YeIQz3x+DiurmIm80K3lUZUfN5jAy60IKWBWSco+fYql0u4HO+Vq
         ef8A==
X-Forwarded-Encrypted: i=1; AJvYcCVwZ/kcK+9hOazK4EP2RKnIyvZ1jCZOyga87fWXfIgPWe7/VaR29QNpFd5wCpyMQUNo6k8s7u8sI5M=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwVAtXE4rATcjhVUyA5S0pPnNPgThsrM8Eqcu5B9PsqJiBV0KKW
	nlZVcxnvBE751bfroqGwXOZPvVeOL5HIonqHHFlysMCTC9/H9oEG2PAbHiUGWdYjOw==
X-Gm-Gg: ASbGncuIHEXRkMi0ZBISZ94YiEv/qwUoyg8USVbBE0OjXtgmk0JyZ8q/ZCAOSJkGs7z
	ZMZGmA92iGTBqE0Ih8nSoS591Wn0CIFdRh4AwBC7jaNRacShML4Ep7yrSdHrcX6Qr18WbhfKKAd
	FgazaDZhUXRf2g3JBkBPtNhfADVYHE6RRG6Ph/vKC4rGPdm6z7fvaiSc1AFDbIOkGmhMKVrKRVi
	EJis1kayX/lq+J/lsLMAHnzE3QT2OZ+P+Wtz9bJFDIdy+rjmHzxAqDSDyuOuCtE7iZQsrk9hBK+
	GL4zPWOwpO4GvANbvlzAkkNLuVgFU6KYGUigt/NyuZ4gEF7fXoi1fvlEjYh7fj8jvd7wQeQJ0sO
	61NxG3SWrYZWhcVT3iVbgV8I+Kd+gAtnVK3gW339YdiH+mMM=
X-Google-Smtp-Source: AGHT+IFfKF5gudLnWLkRDdHiR4dT8N6OXo5ICBVqzcizTWHzm9+JgUX/YPjLuDTADiPNzV0ZI892qw==
X-Received: by 2002:a05:6000:2084:b0:3a5:42:b17b with SMTP id ffacd0b85a97d-3a6ed65e60fmr2364776f8f.29.1750860366278;
        Wed, 25 Jun 2025 07:06:06 -0700 (PDT)
Message-ID: 
Date: Wed, 25 Jun 2025 16:05:59 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/4] Revert part of "x86/mwait-idle: disable IBRS during
 long idle"
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20250624163951.301743-1-andrew.cooper3@citrix.com>
 <20250624163951.301743-4-andrew.cooper3@citrix.com>
 <86841b35-119a-4265-8ff0-9b8549e8ca52@suse.com>
 <026d2b8c-4b3c-4bc3-955c-732d665e38ba@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: <026d2b8c-4b3c-4bc3-955c-732d665e38ba@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 25.06.2025 15:01, Andrew Cooper wrote:
> On 25/06/2025 10:58 am, Jan Beulich wrote:
>> On 24.06.2025 18:39, Andrew Cooper wrote:
>>> Most of the patch (handling of CPUIDLE_FLAG_IBRS) is fine, but the
>>> adjustements to mwait_idle() are not.
>>>
>>> spec_ctrl_{enter,exit}_idle() do more than just alter MSR_SPEC_CTRL.IBRS.  The
>>> VERW and RSB stuff are **unsafe** to omit.
>>>
>>> The only reason this doesn't need an XSA is because no changes were made to
>>> the lower level mwait_idle_with_hints(), and thus it remained properly
>>> protected.
>>>
>>> I.e. This change only served to double the expensive operations in the case it
>>> was trying to optimise.
>>>
>>> I have an idea of how to plumb this more nicely, but it requires larger
>>> changes to legacy IBRS handling to not make spec_ctrl_enter_idle() vulnerable
>>> in other ways.
>> What are the concerns here? As it looks skipping the MSR write would look
>> to require checking some (per-CPU) conditional. Conditional branches can't
>> really be of concern, or the "if (cx->ibrs_disable)" that you're now
>> removing again would have been of concern, too.
> 
> The conditional branches are what set off alarm bells in the first place.
> 
> A conditional branch in enter should be ok; HLT and MWAIT should be
> serialising enough.
> 
> A conditional branch in exit is not ok without extra safety measures.
> 
> I can expand on this in the commit message if you'd like.  I was trying
> to not be overly critical...

For me, the answer here is sufficient, I guess. Hence I won't insist on you
amending the description. It may help others and/or some time into the
future, though.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 14:08:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 14:08:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024937.1400687 (Exim 4.92)
	(envelope-from )
	id 1uUQnM-0000VG-9J; Wed, 25 Jun 2025 14:08:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024937.1400687; Wed, 25 Jun 2025 14:08: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 1uUQnM-0000V9-5C; Wed, 25 Jun 2025 14:08:12 +0000
Received: by outflank-mailman (input) for mailman id 1024937;
 Wed, 25 Jun 2025 14:08: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 1uUQnK-0000V3-IU
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 14:08:10 +0000
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com
 [2a00:1450:4864:20::432])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d2436997-51cd-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 16:08:08 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3a6cd1a6fecso1678957f8f.3
 for ; Wed, 25 Jun 2025 07:08:08 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-749b5e2145bsm4894594b3a.54.2025.06.25.07.08.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 25 Jun 2025 07:08:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d2436997-51cd-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750860488; x=1751465288; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=cxjiKF220tZ4ezq10EPqwbZvYUvol3Fy/rHGsaAVyJI=;
        b=NxcWLXxYdAjQ3jzigIrgXL7C3pTr1iJTLSAdWLnmnfGDtRDxAamIqSViV+ZinfARke
         GPb95NSriNnfnIsG02q46cxc9VdYlYnyQUWl5CvV2ryE2sm1MzxepHxX9QGsi94zlWZR
         uFzwVxBc20SRByNkwCidOHVW1/0Bsot7YlDyJ6/xxTR+PZgSOzZGIYrpu9M3A2p9iens
         IBWqqCRcYR/fGE9/lySLVit0FaZPOOWFrof8VXhE/ZzlYm2v+xBjn1KGkia6c0rOqEum
         zZbHZ3n3ZinD/dGj1FZQXLCuihARqVtAPEfWMwBOQXt/3WMrMl4PkVW+vVKHnU42HMgv
         xnhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750860488; x=1751465288;
        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=cxjiKF220tZ4ezq10EPqwbZvYUvol3Fy/rHGsaAVyJI=;
        b=kxwXtwzZw//PIfLMG1a/IfU8fOno2mFeZg99Tt5MoKK3SY7vauzUOHrztu+fQI2CDk
         dmv33XLX8r/plG6tzygF8AjKXEeOQTIRa0Pg4eZkLYGKZzBHUXQ+eYa/ASXnTmxoJ4a/
         105CNrsF/JegwMAhm73WuHHe/qfOtsdo8SdQhXeTtCyURsc4EIarYg82tCWe9jDcXZ8T
         j1AqnTOvH5BcMpU07Lbznfrt9H0XJ8NKb0lJLpvRoAIRm8nN2p9sJNYREK50fX9jee1O
         wA/+8HI5nIPPcBPTbrItv++N9EZaZytoZK924Ppd6kLURnvkbxqbIHIW45Rl5JRCVuWI
         NV1A==
X-Forwarded-Encrypted: i=1; AJvYcCX9M3Z8KIAFY+N8wNYJUbVhbfJ+27axFb6cRMhADQ55fsfdwc+fmjvUIS0Xcwo45wS4yzYPq5FBxJI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxieTcSUusW+ub8KGk6c0Sg7FPIaIRqXgU7zSI6k7WWoh+5H2+3
	w/gsh0mdu/PIHGC/syFIFvkTjCUEj77vlIHXtYi2Og9lN5+iStWLqxMuDXg4qI0kKw==
X-Gm-Gg: ASbGncuELVHIq64p/u8tnX+tVlCm9BRAGqjDZitO35Q6vXvGa/9kSRDD1ZNK4KjGXM6
	RgpR0/iTO9376EbCPhvP+WkYUEYtSyoDspNwM/lXgPxDWXqtBWW47RtXO01TCKsL9T+xfB5PckA
	7dSPjeJzXAa/TOUIB6kT5OGcZBO/4GiP1QWNVyJX0A9DAbq5HzsPv6eX8dHDWZnTEqdSuwJKzVY
	IDWA26ly08luJztAxgDWsp/JtuKhHXlkBlWFiJ4pAVH8UzdwQDYliGCZBtjUXDbV3gkezRSK2xI
	9GusJmL54T7X3uIAJHcoY0sRYGjUE05KeoSyfHddmPFAUDg42G19KWaE+38lfiISEvFpAsTt0OD
	U5vfUe5bzdl48h/HwRzLZbFt2gTb67RG8C1J5q73P2o0f3bw=
X-Google-Smtp-Source: AGHT+IFdr1XYTOMipMlU6GXt1wzEp1KzG0ejdmXJT0llPCKQibgQdxRlE8+JvAybNyTsn0YVQcCoDw==
X-Received: by 2002:a05:6000:4022:b0:3a5:8977:e10f with SMTP id ffacd0b85a97d-3a6ed637c5amr2730210f8f.28.1750860487648;
        Wed, 25 Jun 2025 07:08:07 -0700 (PDT)
Message-ID: <7753470a-efef-478a-bbe5-ae48d008cfdb@suse.com>
Date: Wed, 25 Jun 2025 16:07:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
To: "Chen, Jiqian" 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Andrew Cooper ,
 Anthony PERARD ,
 "Orzel, Michal" , Julien Grall ,
 Stefano Stabellini ,
 "xen-devel@lists.xenproject.org" ,
 "Huang, Ray" 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-3-Jiqian.Chen@amd.com>
 <516a3adc-320d-46ce-b235-8ef91469abcf@suse.com>
 
 <227df6d3-a2c3-4576-bde9-d8057c378e7a@suse.com>
 
 <5c4b186e-686e-4fc8-bcf1-854bc1f5ec8b@suse.com>
 
 <9d5d0e44-66c3-4e3f-8704-2c862c5f5aff@suse.com>
 
 <3638e73c-2a83-4164-9a84-839245245727@suse.com>
 
 <771cd5b7-2b89-49b1-9aba-8cd79319d3ce@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 25.06.2025 12:16, Chen, Jiqian wrote:
> On 2025/6/25 18:03, Jan Beulich wrote:
>> Also, as said - you will need to check whether other architectures are
>> different from x86-64 in this regard. We better wouldn't leave a trap here,
>> for them to fall into when they enable vPCI support. I.e. my recommendation
>> would be that if in doubt, we put the __aligned() there unconditionally.
> That's difficult for me to check on all different platforms since I don't have them all.

You don't need to have them. You'd need to carefully go through the respective
section(s) of their psABI-s.

> So you mean I should remove "#ifdef CONFIG_X86"? Just let __aligned(16) for all platforms?

Yes. And, as also said, with a suitable comment please.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 14:09:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 14:09:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024947.1400695 (Exim 4.92)
	(envelope-from )
	id 1uUQou-00017l-MD; Wed, 25 Jun 2025 14:09:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024947.1400695; Wed, 25 Jun 2025 14: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 1uUQou-00017e-JK; Wed, 25 Jun 2025 14:09:48 +0000
Received: by outflank-mailman (input) for mailman id 1024947;
 Wed, 25 Jun 2025 14:09: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 1uUQot-00017P-F7
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 14:09: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 0bfb81f7-51ce-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 16:09:45 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3a4e742dc97so717761f8f.0
 for ; Wed, 25 Jun 2025 07:09:45 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b31f126b6fesm12895728a12.71.2025.06.25.07.09.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 25 Jun 2025 07:09:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0bfb81f7-51ce-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750860585; x=1751465385; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=suP9PxE4wqeKgefOdzrc4creCLiYWB11VMlQkiWel0g=;
        b=Fvnqrg5GbIZzrZt6PcohboR8EEV8m51zh4zdZd/OXcz4U7jNKwrU3esRkFzB2RhDpo
         lq1VMtLYf4/2lzLeS94mMN1Yy+jRc5InPuOy33cQ1ihiZ026mhmIpNucRR58fNXVkD5u
         2+5N7XybO8FEjjGCHuV2Uz0sJirCbYY6F4Od4ymAHmYSWm7VzjQ+0eAIoKj9POFYljQx
         HD+O91KBn4i3Ekoxvq/lD7v+GvpiBV/wqiQ2xpHCBe2/S5hGTyz9guVFK1mwmJYD0XkV
         kBMkf5pWMjRofoMACjes4am4upS0kJ518kT69EBU/uNdAxNBbXX1wf6BmffNEtIRn+YM
         1ARg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750860585; x=1751465385;
        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=suP9PxE4wqeKgefOdzrc4creCLiYWB11VMlQkiWel0g=;
        b=FeejhtIh3XwD2pLWBxnA/BjSajDYfdQwUNn5WwLH7bnWmZIJaCbFWAfawPLDxzYTl6
         IkqAyQildGcReYOyKrgR0ukTPIOCRScma1OeEzdrZKtLSO+X2CDSRIM9xXTznS+rFi4B
         rSwRRzirEaNJ8jL6PxjRXT9IOfKidXNQUMcuyGUDiXpE3guNIsP4O/Y+Np41shSA9xhv
         byjnKuqc43XAL0ZjTpL2qxv+wXJOavJ5BEUnM+W8BgQPCYzASXemKu6/r2ww1nzMvhXQ
         oYy/wWQfos7oxQwU2tWr1a4TmgsnD/peUVQRP2iV+u7dJF+oNUA9h8Z+dvcLeUMIJAOA
         cCJw==
X-Forwarded-Encrypted: i=1; AJvYcCXHkFDmsI0des6/R7Tv4el0rLPO34jqzNIrPWGu1VS4m3xkIP0m9fgb9WAKlY96DDwopVn4JjxX3Lo=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw92Pi6DZ/e7Ri+UnrmMX+r8/WNNbtUldDcCHvbZ4B0SZkkHVTG
	ulIoxm5AYrtGK4n1KdxryiNMO34D5tTJKu0ny+ANGAfUPbYbCVICd2Ez6pDzwjK8XQ==
X-Gm-Gg: ASbGncso+S0HWXSdqzwB1mhB11i7BNXtCIbTBfXEaRTQLcLOhPnlLCI9gE6o8UHZGqA
	I2ahzqe8xZbHxinQNU01V+Y+lMPQXmVKzV3WSqwMKe2kVoXd7kgG+cbhwsBjShV3oi7hcoKDG9K
	hAo+TPqb4c7UckJ+v3wJFWKtAGuybULBCwF09zX4hu5reqieDifMXKhfFJSqta8flHUzzcH2wy0
	DoXjDQWoUGjvymA5OK0Zie55knNATdZ6WAi56Er95ZqgXnfuRHf/3MPYj5l5F6HgJ0CT9mGQWvX
	Iq85HrK2v7GocNQL2Mbk0lzFA7Z7vHu3FGmJwVs2sQJIVnkHYY3oPGUDSWVNiO/8uusNLjVfER8
	PNHc+XPWMAnrPXlh0TV74PpPmiWCrQm3f2G/M7+IrWUWITu4=
X-Google-Smtp-Source: AGHT+IFo40wWU5TIyErfvDJhP72AWQTN02ixbA6h/ZLLLk+L+NVVXbKGe4gyap1N2WtuP+KOpKR8qA==
X-Received: by 2002:a05:6000:1acc:b0:3a5:271e:c684 with SMTP id ffacd0b85a97d-3a6e720de4emr6516727f8f.24.1750860584785;
        Wed, 25 Jun 2025 07:09:44 -0700 (PDT)
Message-ID: <531ff40d-ab69-4eb6-8e61-3c1c23ccf95e@suse.com>
Date: Wed, 25 Jun 2025 16:09:37 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 7/8] vpci/msi: Free MSI resources when init_msi() fails
To: "Chen, Jiqian" 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "xen-devel@lists.xenproject.org" ,
 "Huang, Ray" 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-8-Jiqian.Chen@amd.com>
 <773c448a-d814-458f-ad83-e9740e724408@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 25.06.2025 12:26, Chen, Jiqian wrote:
> On 2025/6/25 18:09, Jan Beulich wrote:
>> On 25.06.2025 11:47, Chen, Jiqian wrote:
>>> On 2025/6/25 17:15, Jan Beulich wrote:
>>>> On 25.06.2025 09:16, Chen, Jiqian wrote:
>>>>> On 2025/6/24 18:17, Jan Beulich wrote:
>>>>>> On 24.06.2025 11:49, Chen, Jiqian wrote:
>>>>>>> On 2025/6/18 22:45, Jan Beulich wrote:
>>>>>>>> On 12.06.2025 11:29, Jiqian Chen wrote:
>>>>>>>>> --- a/xen/drivers/vpci/msi.c
>>>>>>>>> +++ b/xen/drivers/vpci/msi.c
>>>>>>>>> @@ -193,6 +193,33 @@ static void cf_check mask_write(
>>>>>>>>>      msi->mask = val;
>>>>>>>>>  }
>>>>>>>>>  
>>>>>>>>> +static int cf_check cleanup_msi(struct pci_dev *pdev)
>>>>>>>>> +{
>>>>>>>>> +    int rc;
>>>>>>>>> +    unsigned int end, size;
>>>>>>>>> +    struct vpci *vpci = pdev->vpci;
>>>>>>>>> +    const unsigned int msi_pos = pdev->msi_pos;
>>>>>>>>> +    const unsigned int ctrl = msi_control_reg(msi_pos);
>>>>>>>>> +
>>>>>>>>> +    if ( !msi_pos || !vpci->msi )
>>>>>>>>> +        return 0;
>>>>>>>>> +
>>>>>>>>> +    if ( vpci->msi->masking )
>>>>>>>>> +        end = msi_pending_bits_reg(msi_pos, vpci->msi->address64);
>>>>>>>>> +    else
>>>>>>>>> +        end = msi_mask_bits_reg(msi_pos, vpci->msi->address64) - 2;
>>>>>>>>> +
>>>>>>>>> +    size = end - ctrl;
>>>>>>>>> +
>>>>>>>>> +    rc = vpci_remove_registers(vpci, ctrl, size);
>>>>>>>>> +    if ( rc )
>>>>>>>>> +        return rc;
>>>>>>>>
>>>>>>>> This is a difficult one: It's not a good idea to simply return here, yet
>>>>>>>> at the same time the handling of the register we're unable to remove may
>>>>>>>> still require e.g. ...
>>>>>>>>
>>>>>>>>> +    XFREE(vpci->msi);
>>>>>>>>
>>>>>>>> ... this. There may therefore be more work required, such that in the
>>>>>>>> end we're able to ...
>>>>>>>>
>>>>>>>>> +    return vpci_add_register(pdev->vpci, vpci_hw_read16, NULL, ctrl, 2, NULL);
>>>>>>>>
>>>>>>>> ... try this at least on a best effort basis.
>>>>>>>>
>>>>>>>> More generally: I don't think failure here (or in other .cleanup hook
>>>>>>>> functions) may go entirely silently.
>>>>>>> Does below meet your modification expectations?
>>>>>>
>>>>>> Not sure, sorry. By "more" I really meant "more" (which may just be code
>>>>>> auditing, results of which would need writing down, but which may also
>>>>>> involve further code changes; see below).
>>>>>>
>>>>>>>     rc = vpci_remove_registers(vpci, ctrl, size);
>>>>>>>     if ( rc )
>>>>>>>         printk(XENLOG_ERR "%pd %pp: remove msi handlers fail rc=%d\n",
>>>>>>>                pdev->domain, &pdev->sbdf, rc);
>>>>>>>
>>>>>>>     XFREE(vpci->msi);
>>>>>>
>>>>>> As I tried to indicate in my earlier reply, the freeing of this struct is
>>>>>> safe only if the failure above would not leave any register handlers in
>>>>>> place which still (without appropriate checking) use this struct.
>>>>> Hmm, but all handlers added in init_msi() use this struct.
>>>>> So it doesn't exist the case that when above unable to remove all handlers and still require xfree this struct.
>>>>
>>>> Well, in the end you say in different words what I did say, if I understand
>>>> correctly. There are several options how to deal with that. One might be to
>>>> have those handlers recognize the lack of that pointer, and behave like ...
>>>>
>>>>>>>     /*
>>>>>>>      * The driver may not traverse the capability list and think device
>>>>>>>      * supports MSI by default. So here let the control register of MSI
>>>>>>>      * be Read-Only is to ensure MSI disabled.
>>>>>>>      */
>>>>>>>     rc = vpci_add_register(vpci, vpci_hw_read16, NULL, ctrl, 2, NULL);
>>>>
>>>> ... what is tried to be put in place here (and like "no handler installed"
>>>> for other registers).
>>> According to your suggest. What I can think of is when vpci_remove_registers() fails,
>>> then lookup the MSI related handlers,
>>
>> What exactly does this mean? Aiui if vpci_remove_registers() ends up failing,
>> it may be the lookup which is the problem. Which isn't why this wasn't what
>> I suggested. Instead I suggested to make the respective handlers deal with
>> the case of vpci->msi being NULL. Which of course in turn would require
>> passing pdev->vpci to the respective vpci_add_register(), not pdev->vpci->msi.
> 
> Like below?
> 
> @@ -37,7 +42,13 @@ static uint32_t cf_check control_read(
>  static void cf_check control_write(
>      const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data)
>  {
> -    struct vpci_msi *msi = data;
> +    const struct vpci *vpci = data;
> +
> +    if ( !vpci->msi )
> +        return;
> +
> +    const struct vpci_msi *msi = vpci->msi;
> +
>      unsigned int vectors = min_t(uint8_t,
>                                   1u << MASK_EXTR(val, PCI_MSI_FLAGS_QSIZE),
>                                   pdev->msi_maxvec);
> @@ -239,7 +250,7 @@ static int cf_check init_msi(struct pci_dev *pdev)
>          return -ENOMEM;
> 
>      ret = vpci_add_register(pdev->vpci, control_read, control_write,
> -                            msi_control_reg(pos), 2, pdev->vpci->msi);
> +                            msi_control_reg(pos), 2, pdev->vpci);
> 

Yes, with control_read() also suitably adjusted. And assuming there are no other
caveats.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 14:11:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 14:11:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024953.1400705 (Exim 4.92)
	(envelope-from )
	id 1uUQqV-0002iZ-VV; Wed, 25 Jun 2025 14:11:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024953.1400705; Wed, 25 Jun 2025 14:11:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUQqV-0002iS-Sq; Wed, 25 Jun 2025 14:11:27 +0000
Received: by outflank-mailman (input) for mailman id 1024953;
 Wed, 25 Jun 2025 14:11: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 1uUQqU-0002iM-Ko
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 14:11:26 +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 477c1c5d-51ce-11f0-a30f-13f23c93f187;
 Wed, 25 Jun 2025 16:11:25 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3a5257748e1so4507421f8f.2
 for ; Wed, 25 Jun 2025 07:11:25 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-749c882cd82sm4383566b3a.86.2025.06.25.07.11.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 25 Jun 2025 07:11:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 477c1c5d-51ce-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750860685; x=1751465485; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=DV6oPbR2l+JP4t5pHcIoD17yiGgUyU1F3njM/i/mbPo=;
        b=XgyTHxLsHGF44+FO6wkP/aZUbvIZr3wwAySScq2nNM93Br98FbEySLNgrW5kmeKXO8
         ThcYjfSYqq0uGFCE237xFQI7VCeBqjmgzfXxNI/vyrIBcIEBlGja8MZRTyRnGc1HpnVt
         KlSIZK/PAPYTEa7uuBsSPtJvXCLXsBVdBkxuT3VWr3gwO0Un3D415XhzvWC+0Fa32N8L
         rgqRbOTOtuM0y3An0XDp6M0ModNVtdChVfgfyKzFDlDD6Myx+HtidprdBDkbGpkjRCCZ
         LkIO59h+NSjjmMPrONJxqzTZ62pQr3fv503Tm2Ukg7Ln4OGl63DVyUKB+M4FH0aN0WBd
         ILuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750860685; x=1751465485;
        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=DV6oPbR2l+JP4t5pHcIoD17yiGgUyU1F3njM/i/mbPo=;
        b=upN1UF2I6ifXWpSHITjyxTI3trtWFmJ2P7x4hmjUgHvEmWLV35ZsVnv1NQrcv38MU+
         HW/tBCRruF4sMW61whQbnx0hHkpVDwEzg5yR8eck2eahJ/qPw1nj8rdEfPSX+7AeyBMy
         3Y/W48DDS1C++bprattIadH7MJF/KE+rRKhFVeFnNh0K456kKyCUxkaiy0a/+2vCMjuO
         KuKIYPrPWZVxlmV6nuLwqvTs+0GiU4twkYCO03sX4GC0KdmBqYLK6zCENgrELjQCCTr3
         dSh3iEr7AvZyiMQ8Jdi9BHKp9/sxzOabcYmzkhtDkmNztAymqT06uDuyy4lt8I+D9rxw
         o0Ag==
X-Forwarded-Encrypted: i=1; AJvYcCV+eApZZkMZScSK1WIdx3/N2D2qh76GbZFJLREsiiljgvE5glTy7DoyYCPRva8zhR799Jjmq12Ti4Q=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyYbYd4HXllG9D/AhEpmGY+IXODuCFHh/zTeWmqZPkw5ZzvX0T2
	T8g8zV05vkW+Dyfp9jVI6xVz8i4Z4oButtuaCNersS400vXDp7unkDMv2zf+Fl2PIDoHlY1vpo7
	yhb8=
X-Gm-Gg: ASbGncsJkMzyZ3iacYZqSODV1n1D2eE8QX6iaZJzyi8lHjfocNSAw9ivEocP4aldGYV
	IpXgiiHGF8nZ4pORu9cyT1xtKaIPQ9Veb1yHnQX5AOXrl5CLx/s+FT+NHMn7uMk+YItcPKFNDlw
	VNNuzDZQiehhIAINhAEgxmMybPHy4oDHFegEoHqT+6hZiEZirVwqbB0+CwwBNod4HOTW4M1JP1a
	/qqh66I0s/MZq60wQURjrINT7pRG7VFC3zqMUIkdtOFr9mO00C5v2hyA3bJE9xBqfvGFwi6aTgT
	H+K/U9+LIVpfWNNeDW9vIQqfHTA/Qsk4O0tW0BNJOTAQsp1mnV1WSb4Ej1VTNhu3swBGJDNYvC4
	I7EKYRhyISzRBaoe6DsKNp5tTeTQApWRK/wws+fgd9RV9RbU=
X-Google-Smtp-Source: AGHT+IHnO0QspmKVnEdhyf3I9wfSMOm/+CV+xxunZcmUQ30pZdUqGM6MbJ15zOSdx3VgtJuIjJKMnA==
X-Received: by 2002:a05:6000:23c4:b0:3a3:6415:96c8 with SMTP id ffacd0b85a97d-3a6ed66f9ccmr1554661f8f.41.1750860684607;
        Wed, 25 Jun 2025 07:11:24 -0700 (PDT)
Message-ID: 
Date: Wed, 25 Jun 2025 16:11:16 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 7/8] vpci/msi: Free MSI resources when init_msi() fails
To: "Chen, Jiqian" 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "xen-devel@lists.xenproject.org" ,
 "Huang, Ray" 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-8-Jiqian.Chen@amd.com>
 <773c448a-d814-458f-ad83-e9740e724408@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 25.06.2025 12:26, Chen, Jiqian wrote:
> On 2025/6/25 18:09, Jan Beulich wrote:
>> On 25.06.2025 11:47, Chen, Jiqian wrote:
>>> On 2025/6/25 17:15, Jan Beulich wrote:
>>>> On 25.06.2025 09:16, Chen, Jiqian wrote:
>>>>> On 2025/6/24 18:17, Jan Beulich wrote:
>>>>>> On 24.06.2025 11:49, Chen, Jiqian wrote:
>>>>>>> On 2025/6/18 22:45, Jan Beulich wrote:
>>>>>>>> On 12.06.2025 11:29, Jiqian Chen wrote:
>>>>>>>>> --- a/xen/drivers/vpci/msi.c
>>>>>>>>> +++ b/xen/drivers/vpci/msi.c
>>>>>>>>> @@ -193,6 +193,33 @@ static void cf_check mask_write(
>>>>>>>>>      msi->mask = val;
>>>>>>>>>  }
>>>>>>>>>  
>>>>>>>>> +static int cf_check cleanup_msi(struct pci_dev *pdev)
>>>>>>>>> +{
>>>>>>>>> +    int rc;
>>>>>>>>> +    unsigned int end, size;
>>>>>>>>> +    struct vpci *vpci = pdev->vpci;
>>>>>>>>> +    const unsigned int msi_pos = pdev->msi_pos;
>>>>>>>>> +    const unsigned int ctrl = msi_control_reg(msi_pos);
>>>>>>>>> +
>>>>>>>>> +    if ( !msi_pos || !vpci->msi )
>>>>>>>>> +        return 0;
>>>>>>>>> +
>>>>>>>>> +    if ( vpci->msi->masking )
>>>>>>>>> +        end = msi_pending_bits_reg(msi_pos, vpci->msi->address64);
>>>>>>>>> +    else
>>>>>>>>> +        end = msi_mask_bits_reg(msi_pos, vpci->msi->address64) - 2;
>>>>>>>>> +
>>>>>>>>> +    size = end - ctrl;
>>>>>>>>> +
>>>>>>>>> +    rc = vpci_remove_registers(vpci, ctrl, size);
>>>>>>>>> +    if ( rc )
>>>>>>>>> +        return rc;
>>>>>>>>
>>>>>>>> This is a difficult one: It's not a good idea to simply return here, yet
>>>>>>>> at the same time the handling of the register we're unable to remove may
>>>>>>>> still require e.g. ...
>>>>>>>>
>>>>>>>>> +    XFREE(vpci->msi);
>>>>>>>>
>>>>>>>> ... this. There may therefore be more work required, such that in the
>>>>>>>> end we're able to ...
>>>>>>>>
>>>>>>>>> +    return vpci_add_register(pdev->vpci, vpci_hw_read16, NULL, ctrl, 2, NULL);
>>>>>>>>
>>>>>>>> ... try this at least on a best effort basis.
>>>>>>>>
>>>>>>>> More generally: I don't think failure here (or in other .cleanup hook
>>>>>>>> functions) may go entirely silently.
>>>>>>> Does below meet your modification expectations?
>>>>>>
>>>>>> Not sure, sorry. By "more" I really meant "more" (which may just be code
>>>>>> auditing, results of which would need writing down, but which may also
>>>>>> involve further code changes; see below).
>>>>>>
>>>>>>>     rc = vpci_remove_registers(vpci, ctrl, size);
>>>>>>>     if ( rc )
>>>>>>>         printk(XENLOG_ERR "%pd %pp: remove msi handlers fail rc=%d\n",
>>>>>>>                pdev->domain, &pdev->sbdf, rc);
>>>>>>>
>>>>>>>     XFREE(vpci->msi);
>>>>>>
>>>>>> As I tried to indicate in my earlier reply, the freeing of this struct is
>>>>>> safe only if the failure above would not leave any register handlers in
>>>>>> place which still (without appropriate checking) use this struct.
>>>>> Hmm, but all handlers added in init_msi() use this struct.
>>>>> So it doesn't exist the case that when above unable to remove all handlers and still require xfree this struct.
>>>>
>>>> Well, in the end you say in different words what I did say, if I understand
>>>> correctly. There are several options how to deal with that. One might be to
>>>> have those handlers recognize the lack of that pointer, and behave like ...
>>>>
>>>>>>>     /*
>>>>>>>      * The driver may not traverse the capability list and think device
>>>>>>>      * supports MSI by default. So here let the control register of MSI
>>>>>>>      * be Read-Only is to ensure MSI disabled.
>>>>>>>      */
>>>>>>>     rc = vpci_add_register(vpci, vpci_hw_read16, NULL, ctrl, 2, NULL);
>>>>
>>>> ... what is tried to be put in place here (and like "no handler installed"
>>>> for other registers).
>>> According to your suggest. What I can think of is when vpci_remove_registers() fails,
>>> then lookup the MSI related handlers,
>>
>> What exactly does this mean? Aiui if vpci_remove_registers() ends up failing,
>> it may be the lookup which is the problem. Which isn't why this wasn't what
>> I suggested. Instead I suggested to make the respective handlers deal with
>> the case of vpci->msi being NULL. Which of course in turn would require
>> passing pdev->vpci to the respective vpci_add_register(), not pdev->vpci->msi.
> 
> Like below?
> 
> @@ -37,7 +42,13 @@ static uint32_t cf_check control_read(
>  static void cf_check control_write(
>      const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data)
>  {
> -    struct vpci_msi *msi = data;
> +    const struct vpci *vpci = data;
> +
> +    if ( !vpci->msi )
> +        return;
> +
> +    const struct vpci_msi *msi = vpci->msi;

Oh, btw, personally I'd prefer:

    const struct vpci *vpci = data;
    const struct vpci_msi *msi = vpci->msi;

    if ( !msi )
        return;

But I'm not a maintainer of this file.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 14:15:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 14:15:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024961.1400716 (Exim 4.92)
	(envelope-from )
	id 1uUQul-0003JM-Ft; Wed, 25 Jun 2025 14:15:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024961.1400716; Wed, 25 Jun 2025 14:15: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 1uUQul-0003JF-CC; Wed, 25 Jun 2025 14:15:51 +0000
Received: by outflank-mailman (input) for mailman id 1024961;
 Wed, 25 Jun 2025 14:15: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 1uUQuj-0003J6-KA
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 14:15:49 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on2060e.outbound.protection.outlook.com
 [2a01:111:f403:2414::60e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e2c2eab5-51ce-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 16:15:47 +0200 (CEST)
Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
 by DM4PR12MB5866.namprd12.prod.outlook.com (2603:10b6:8:65::6) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8857.25; Wed, 25 Jun 2025 14:15:42 +0000
Received: from PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264]) by PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264%4]) with mapi id 15.20.8857.022; Wed, 25 Jun 2025
 14:15: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: e2c2eab5-51ce-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=t/jtHwp2ltemq7fKVS9aCx3NakRwA8j/mAgTQQlRunvX41vX9eIS6JSQzYwyKkHTAfQo6EUgzKFY4lArKYMjYv+LU2eJRP13kmfnc6OeB39bpEC3/0PTCRyZ2A+VSlSaPDrkRzDWKLl7w2UD23XKv6HtFc3FGwejKCvJo0Cel6aA7DPQv4B9fOhlKqc2N+zz0L1QWR3VwqhPNykstv2X70UmTYn4j2cTm28pp2VXRw1jhD7yxg2qzcK1luEo/qbrt5H/Kj9ayguJUlr8QNNl1gt6QGvhtWrlRBLNEFPPNA7p4jLSASzKrpKOk9ZilJvsVN+30lD0DBqnr7LeFjLwnw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=CYgPdWRnj0mClzlnmlH/ZXSxxYpCMH3YEgd7+AiGMKI=;
 b=IggMYjkk7fRiKdeQ9IJZR/S6gclS1UrT+G/7VD5KB+IDsbW0JccFfwxOASmhyN/pfJhG6revEAYVnE03Xffm3g+ibrG1wtfb+VAkuaPiHOZtEfZEz3mhH5B34x7Gu+MOROw7pOh44jwpXwYig0TxlQyPS5eTf7/WS+bshRuUyC+LX2XFQbuC6i9DrrYbdguLCegfIbn7azkmyqhEkoAjnmzVK8tbgKxzbKrmg9uNrPjPWi4xfRZSBB7pXi49gYQFDE685JaIBvLp3CTK9JZM/ZqZc91rC/Jq43G/l+5988okQUZi6rbAOwFWzXpreLTISroGlC5hZDNEZKaEmsa5mw==
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=CYgPdWRnj0mClzlnmlH/ZXSxxYpCMH3YEgd7+AiGMKI=;
 b=n2xGXEO6xJUwTwApL5SxXMhTp8XzqyxD/B1A5akExb15zt/gj1z33sOSI+uxrgjqAxQH2FK3w72KLrpuuQlEEZQX4LFEwFdjlacY3BuZSzBrqp0i1NSfkTdCsgQic1ufJ0aKWX3ZnfxKzXuztI3icCJLPY1aTGbQqZCXGlhfXhI=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Wed, 25 Jun 2025 15:15:37 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/6] arm/mpu: Populate a new region in Xen MPU mapping
 table
Content-Language: en-GB
To: Hari Limaye , xen-devel@lists.xenproject.org
Cc: luca.fancellu@arm.com, Penny Zheng ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk , Wei Chen 
References: 
 <840ec219278c2fcb4f8592303eb671b5271b0a95.1750411205.git.hari.limaye@arm.com>
From: Ayan Kumar Halder 
In-Reply-To: <840ec219278c2fcb4f8592303eb671b5271b0a95.1750411205.git.hari.limaye@arm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: DU7PR01CA0022.eurprd01.prod.exchangelabs.com
 (2603:10a6:10:50f::10) To PH8PR12MB7326.namprd12.prod.outlook.com
 (2603:10b6:510:216::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|DM4PR12MB5866:EE_
X-MS-Office365-Filtering-Correlation-Id: c8ff1683-6f25-4b09-56de-08ddb3f2c48a
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?aTdoa2dQOGVuRzZadWhVRzIrclZIOEVnc2QyTkY3VXRqSW9MUXM2L1ZzQjJo?=
 =?utf-8?B?Qzl5ak95UHhNTTd6TUx4UHpNQ3FmQlNiNnB6YmdmKzRUbko5NWYxNmdOU1hD?=
 =?utf-8?B?YTJZYVJMdGgzZGVSUm91YXVlbzNqK0R2bitDQ0JibHZ3TEIybmhHV2lSZ3JB?=
 =?utf-8?B?bEVHNENZY0lGU1BzQ2lKNzZUb3ZSaUhXT093WWlQTGh1UkNucmVzTDVneWhG?=
 =?utf-8?B?WXpmVGJSZWRVNXV1Zm1mV1JYT01NQmthZCtNLzJxQ0ZhUW0rRDNYUThJcENM?=
 =?utf-8?B?bXdPaXRITURuSkNTUEVYblN4MWVFU3dFZ29USlJxZDNLdDZrSWR1NEtHUjRr?=
 =?utf-8?B?dmZmMXdrL29HKzRSV2Vpalp0SCs3RlRzQndTZjlOWTdlNTlHWXQ2NlZGZU9N?=
 =?utf-8?B?dWFSZCtSd2dpcnVFRXRDdDdaWTNPWVlTeU5pbVhJSWxicDl3cUtzalc2TjVT?=
 =?utf-8?B?cmNJNzNUbk1OcUF5a3VVVGtJZmU0ZXlDR2NoWEp1NjQzY3l6bGZhVjdkanpu?=
 =?utf-8?B?MTJKNEVuTW1zQlVQWHl0NjQrSFV5NWpsSjNQUWxnUWprVE5sM3lpMExkY1Bw?=
 =?utf-8?B?VmplbDBsSTZZdXBFbGpHZ05pQ1hZOXcrMUFKQWgzbDBkWXVYVUVQME9aTTcw?=
 =?utf-8?B?LzZ4bXRoUmpkNFAxdUVMRnhBTExhdFZBa3lzYmt1MndNRGpJcGxBaU9qTCtZ?=
 =?utf-8?B?VnB0TkIxaXltdFVjcmJkeGh4dy9zemZXOTdFKzJDUkVPeXdEdWJyRllqM1BT?=
 =?utf-8?B?SW9CT0tLeXN3Mk41cDRwWnMxSGpUY1NGeGt3WGd6YW55STR2OW1LOGJxWlNG?=
 =?utf-8?B?QkF0T09tSWpUL2U3TkNFb0J4aUtFcDJtUFAxbVhObWNtUGthMXlhaDdnc0lX?=
 =?utf-8?B?ZWEybFlPZmJFMWwzQWNnSGNXdHlGNDVQNWsrSW90bTEwd09jWk5sdTBzTE53?=
 =?utf-8?B?a29DOHlwb2x3MDdTK3JwalBaUzFpYmFhR1VKNkZ1TnlLRHZyb05lYUNtK0RR?=
 =?utf-8?B?NElpblAzcHBxaVl2aXRSYXY5YTVnSWJLOXVsNmdNWU80OHlsc3NqRHNjb0lx?=
 =?utf-8?B?VEhyV29jZVVFaCtIa3IvNjlUYURWREdzcDNjVE5sSHRhQzBoblpzWUdNOUFR?=
 =?utf-8?B?cDQyZkxaRWV4NkhqTnRRUmdNS2VCSkJTWnNQblFtNUs0dC9jb1NHcURIYTR0?=
 =?utf-8?B?TVNubnBRTVJldEtXbjJOSklza3JVWlVJU2M5QVMvRURveEt2SnFJdTFPT0dL?=
 =?utf-8?B?UU1BV1d5b0lyRzNjWHdyYXd0YkhhQzhFemxxb0U1WWYyMzZVUE45Y01LV29l?=
 =?utf-8?B?a2NNenlhemdzbmxkMUV2OXhic2pMNkhJUjVFYmNKcjBmQndheGNmYWZiZ2hw?=
 =?utf-8?B?N2kyRGI2NnR4UDh3a2dxT1dTdFRta2t5bnY4S1JhRGhRMnVuRDE2cEFqM1hS?=
 =?utf-8?B?a3Fxb0R4TjZVNzQ0MEZWV1REc3hnUWpTZFl1YVNGaFh5Y2s1Z0FlUWJOcTVi?=
 =?utf-8?B?cC96OCtBeHRTNStuWDFXTlk1R3ZEdFdHYkhHZ2VFTVZMcktlM3V4Z0c0WnNK?=
 =?utf-8?B?cFdsb0RySFVYanlwaGhKOWVnbXVwbVAwZ1NHajVZN2pEdk1XMUluMUlXWVBZ?=
 =?utf-8?B?MUdZTSt2M01UM2VVaGMrV0VZVW55anVmeXlyRDdjL1dvdXduYVBWMlVsTFV5?=
 =?utf-8?B?RWcyb1pydVRGU0xETGp3U09WcmtVSU1KRkp2ZWN1K0lDZ0k2WExNZWl5T3Fp?=
 =?utf-8?B?dGVMZ2hlTFI2ODdrNk82N0tBaC9ud0wxUXM2YldNZVFRNDljOTlZUEJnb2dZ?=
 =?utf-8?B?ckZvUEs0U1N2ZEZmQUpqS0tJTU94dlkzTElyYzVJY0tkR2tQeDJVVG9XWHEv?=
 =?utf-8?B?clQ2RWxYcW1USGlOOUFibHBRZ0xScWphbmRJbnJrOXF4VCtwZE5pdGxjUVIy?=
 =?utf-8?Q?o8bSoTasp0M=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)(376014)(366016)(1800799024)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?ckxwekg2SXc0Y1lJZDdyWUNOMVhYLzRmSUhkekdmdGUwcFpQaFI2b25rRFZI?=
 =?utf-8?B?RTRwRk5nSGNDdGFqcHJGYWJsdnIzQjdrS1FQcEZlZ1ErVjlGWHBDMjdodHNk?=
 =?utf-8?B?R09lUUdCMEhaNDF2enJmNWQ0VjgwbXEzcjNFSHRrQUthUG1CV3h5SUxQZWdZ?=
 =?utf-8?B?WFUzeWY2UFlMaW96dUtNME9MdGVYNVpmZjVNQnlCSDZSbEdLUTgyM0FsT0Zi?=
 =?utf-8?B?MXd0MFRIdm40Z1l3UXNHUXFnd1djeUlqUFVMT2dwWmdFVUJKYktGM0hWVzlu?=
 =?utf-8?B?SVdwUElNUDA1VUwzYlV5TEd2OVdGdS8zNndYeTBjMmdobzNNN3NwZEpwWWV6?=
 =?utf-8?B?N0FPOE9GZWNqcUpSWjhsQmVKU1J3THFDSm50ODJIa2FmTTM1UEx5TW9qc2tC?=
 =?utf-8?B?T3ozMnhTQnp3cXhJb2lncWdjU1FxajB4dDFiSlJwalE2TGloLzRjN3UwanB2?=
 =?utf-8?B?dStCQnd5STNyMlpWeGNIaGRpQXdEQk14OWY5bU1IUjVQZnRwYlpvWlltVHBs?=
 =?utf-8?B?U0NNTEVsSm5WM1FobG13TGtXUWVjelJxSm1yQy9mK0JTcCtDNXdwdERoNTlq?=
 =?utf-8?B?UkhmM3E1TUZnY1B4MXg5ZXBUMlhoOVBWNlp6OGtWS2JEa3k5dW9KR0RyMFJT?=
 =?utf-8?B?TG9wVmtMbHhBKzdXWkJjeWY1UWFWOUVDUmhNOXR3K0d0STBmRSs5c2xDbFdU?=
 =?utf-8?B?dkR3VUZQMmJpYnlkL043V3h3OTFGd3FiNlJBQkRaOTZPYlZVR0RHTWs3OTBR?=
 =?utf-8?B?RnRTUitYSFBiZzdrYjd5THc0d2xNRFFTd0FKbWxqMGxsWUoxaStrRzB3NWh0?=
 =?utf-8?B?MDExd2ViNkxSdU16YXhYamtIK2JMd0g2S1RZNHdYVzlvS0JpcXZQcjlHOXhG?=
 =?utf-8?B?SklBODFzSFhUWmFmQWJtektvcmxqNFpiKys0bEJGRVk4N3E0VVkxdTM2TkVo?=
 =?utf-8?B?blRud1N3aXZXa0NKUHRVbXNDYytkLzMyWkNtcFRMVmVGcnFNdmRvczlobjFU?=
 =?utf-8?B?VzhlcnRiU3VNaElyTGdkd1FLbG5mYjNVS1VBYUtGS0hhZXB5SUdvSDFEeVl5?=
 =?utf-8?B?WmVvdWdHcEpTUW4xL1dKalNHdU1sblduV0M3L2k1UUdDM01JTTZtM2t4VGtQ?=
 =?utf-8?B?YVdJdGtkUmZlZDc2Q3VINTFFVjhCWEZpMGdVQTk0eXpFQWJOak5VMlU1cnhn?=
 =?utf-8?B?ZllRdzV5ZTUxZ3I4ZzFzQ3Y0TXM0akpkV2dNWHR4VEp5QTFqU1VSRTRMWUZB?=
 =?utf-8?B?R2VQV2pKSlhXaHQzMkdPa1h6dGZ5RDFkZjRGRDc2b1hEa2FVNlpoMTYyQkdZ?=
 =?utf-8?B?dTBVa0JaaUpnZ2czdG5Hd0VCN3VYL3ZpUDF5dkptWERTOGJhazdMQllGK2hO?=
 =?utf-8?B?eVZGL21MWnl3Yk9HMFN6OUE3WEQzVkttMXMxNnhSZFRvS0xjQkRTVkhPd2dt?=
 =?utf-8?B?MlRidjdqb1BCUDRjMTdZZUdXMWgwMklxVnU3cXBGQWVDSXl2UWdCM25Ocy9i?=
 =?utf-8?B?TDkyNWtMOWtJLzZmMTVidjhKTUU1Mk0wZ3RuSmxxOS93SEVhZFVPUU1jWXVz?=
 =?utf-8?B?SjY1TGRRUkVVeEw1OFIyVTQ3VS8raE9GWWE2M01mK1FkS1p4ZG1OTXhmM1Z4?=
 =?utf-8?B?RFF2YVJRTTVpRDZyanh3WWxHaDNncnBqcW55NGxnNXNKd1oxMjBGSnBENWU1?=
 =?utf-8?B?MWo0SC9pc2NybGx4bXF6K0x6cm51cFJQcE40a0ZwQmdza1RmbVB3ZndJSWhK?=
 =?utf-8?B?RWxoUXl3QkJLOGp1ZmdmNFhEUTdHVzRBclFPSTREVHNoV1ZDdThmdkZMaVVK?=
 =?utf-8?B?TFJsMitXSERaSGVwWHNRTjdSM1B6VmhrcGFUb2hIOEIzTFl5dGxuTVlwYm04?=
 =?utf-8?B?T1RzRjg5YkEyVktid1UzQmJyVjlEYUtjNUlHUzBUcEdoenljUDdKOXBzaS8x?=
 =?utf-8?B?a1NYb2tTQlBJT251TUtZZzFrWlNWVFhxeHFMVlVKd1hrN1A3azZKWkRtU2tN?=
 =?utf-8?B?dUhqS1BKWTgyMUI1UnNEdCt6cUlTWlcrc0xtWTdIUVNtK1dZa21veU02YTRw?=
 =?utf-8?B?eXVnTWY3THNMd1RlNHFsNUhRRGlhNE1ZTFVseXFQeXkxV0dxUlg3RjV6WHZI?=
 =?utf-8?Q?ANCNNiwsKQJ+tXf9fC16qU4o5?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c8ff1683-6f25-4b09-56de-08ddb3f2c48a
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jun 2025 14:15:42.0251
 (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: 4PeCl8+ITDqDQgRGmGTHTBi1F+DbNOmQJ0dM0YnCIS22FHHJmovN5ej2pwy25TogP1hZ8sehcbmI529kNec7Gg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB5866

Hi Hari,

Some questions.

On 20/06/2025 10:49, Hari Limaye wrote:
> CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email.
>
>
> From: Penny Zheng 
>
> Introduce map_pages_to_xen() that is implemented using a new helper,
> xen_mpumap_update(), which is responsible for updating Xen MPU memory
> mapping table(xen_mpumap), including creating a new entry, updating
> or destroying an existing one, it is equivalent to xen_pt_update in MMU.
>
> This commit only implements populating a new entry in Xen MPU memory mapping
> table(xen_mpumap).
>
> Signed-off-by: Penny Zheng 
> Signed-off-by: Wei Chen 
> Signed-off-by: Luca Fancellu 
> Signed-off-by: Hari Limaye 
> ---
>   xen/arch/arm/include/asm/mpu/mm.h | 12 ++++
>   xen/arch/arm/mpu/mm.c             | 96 +++++++++++++++++++++++++++++++
>   2 files changed, 108 insertions(+)
>
> diff --git a/xen/arch/arm/include/asm/mpu/mm.h b/xen/arch/arm/include/asm/mpu/mm.h
> index a0f0d86d4a..f0f41db210 100644
> --- a/xen/arch/arm/include/asm/mpu/mm.h
> +++ b/xen/arch/arm/include/asm/mpu/mm.h
> @@ -64,6 +64,7 @@ static inline void context_sync_mpu(void)
>    * The following API requires context_sync_mpu() after being used to modify MPU
>    * regions:
>    *  - write_protection_region
> + *  - xen_mpumap_update
>    */
>
>   /* Reads the MPU region (into @pr_read) with index @sel from the HW */
> @@ -72,6 +73,17 @@ void read_protection_region(pr_t *pr_read, uint8_t sel);
>   /* Writes the MPU region (from @pr_write) with index @sel to the HW */
>   void write_protection_region(const pr_t *pr_write, uint8_t sel);
>
> +/*
> + * Maps an address range into the MPU data structure and updates the HW.
> + * Equivalent to xen_pt_update in an MMU system.
> + *
> + * @param base      Base address of the range to map (inclusive).
> + * @param limit     Limit address of the range to map (exclusive).
> + * @param flags     Flags for the memory range to map.
> + * @return          0 on success, negative on error.
> + */
> +int xen_mpumap_update(paddr_t base, paddr_t limit, unsigned int flags);
> +
>   /*
>    * Creates a pr_t structure describing a protection region.
>    *
> diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
> index 15197339b1..1de28d2120 100644
> --- a/xen/arch/arm/mpu/mm.c
> +++ b/xen/arch/arm/mpu/mm.c
> @@ -6,6 +6,7 @@
>   #include 
>   #include 
>   #include 
> +#include 
>   #include 
>   #include 
>   #include 
> @@ -41,6 +42,8 @@ DECLARE_BITMAP(xen_mpumap_mask, MAX_MPU_REGION_NR) \
>   /* EL2 Xen MPU memory region mapping table. */
>   pr_t __cacheline_aligned __section(".data") xen_mpumap[MAX_MPU_REGION_NR];
>
> +static DEFINE_SPINLOCK(xen_mpumap_lock);
> +
>   static void __init __maybe_unused build_assertions(void)
>   {
>       /*
> @@ -176,6 +179,99 @@ int mpumap_contain_region(pr_t *table, uint8_t nr_regions, paddr_t base,
>       return MPUMAP_REGION_NOTFOUND;
>   }
>
> +/*
> + * Allocate a new free EL2 MPU memory region, based on bitmap xen_mpumap_mask.
> + * @param idx   Set to the index of the allocated EL2 MPU region on success.
> + * @return      0 on success, otherwise -ENOENT on failure.
> + */
> +static int xen_mpumap_alloc_entry(uint8_t *idx)
> +{
> +    ASSERT(spin_is_locked(&xen_mpumap_lock));
> +
> +    *idx = find_first_zero_bit(xen_mpumap_mask, max_mpu_regions);
> +    if ( *idx == max_mpu_regions )
> +    {
> +        printk(XENLOG_ERR "mpu: EL2 MPU memory region mapping pool exhausted\n");
> +        return -ENOENT;
> +    }
> +
> +    set_bit(*idx, xen_mpumap_mask);
> +    return 0;
> +}
> +
> +/*
> + * Update the entry in the MPU memory region mapping table (xen_mpumap) for the
> + * given memory range and flags, creating one if none exists.
> + *
> + * @param base  Base address (inclusive).
> + * @param limit Limit address (exclusive).
> + * @param flags Region attributes (a combination of PAGE_HYPERVISOR_XXX)
> + * @return      0 on success, otherwise negative on error.
> + */
> +static int xen_mpumap_update_entry(paddr_t base, paddr_t limit,
> +                                   unsigned int flags)
> +{
> +    uint8_t idx;
> +    int rc;
> +
> +    ASSERT(spin_is_locked(&xen_mpumap_lock));
> +
> +    rc = mpumap_contain_region(xen_mpumap, max_mpu_regions, base, limit, &idx);
> +    if ( (rc < 0) || (rc > MPUMAP_REGION_NOTFOUND) )
if ( !(rc == MPUMAP_REGION_NOTFOUND) ) <<-- Does it read better ?
> +        return -EINVAL;
> +
> +    /* We are inserting a mapping => Create new region. */
> +    if ( flags & _PAGE_PRESENT )

Why do we need to check for this flag ? Or where have we set it.

If we have reached here, doesn't it mean that the region does not exist. 
So we need to create one.

> +    {
> +        rc = xen_mpumap_alloc_entry(&idx);
> +        if ( rc )
> +            return -ENOENT;
> +
> +        xen_mpumap[idx] = pr_of_addr(base, limit, flags);
> +
> +        write_protection_region(&xen_mpumap[idx], idx);
> +    }
> +
> +    return 0;
> +}
> +
> +int xen_mpumap_update(paddr_t base, paddr_t limit, unsigned int flags)
> +{
> +    int rc;
> +
> +    if ( flags_has_rwx(flags) )
> +    {
> +        region_printk("Mappings should not be both Writeable and Executable\n");
> +        return -EINVAL;
> +    }
> +
> +    if ( !IS_ALIGNED(base, PAGE_SIZE) || !IS_ALIGNED(limit, PAGE_SIZE) )
> +    {
> +        region_printk("base address 0x%"PRIpaddr", or limit address 0x%"PRIpaddr" is not page aligned\n",
> +                      base, limit);
> +        return -EINVAL;
> +    }
> +
> +    spin_lock(&xen_mpumap_lock);
> +
> +    rc = xen_mpumap_update_entry(base, limit, flags);
> +
> +    spin_unlock(&xen_mpumap_lock);
> +
> +    return rc;
> +}
> +
> +int map_pages_to_xen(unsigned long virt, mfn_t mfn, unsigned long nr_mfns,
> +                     unsigned int flags)
> +{
> +    int rc = xen_mpumap_update(mfn_to_maddr(mfn),
> +                               mfn_to_maddr(mfn_add(mfn, nr_mfns)), flags);
> +    if ( !rc )
> +        context_sync_mpu();
> +
> +    return rc;
> +}
> +
>   void __init setup_mm(void)
>   {
>       BUG_ON("unimplemented");

Rest look good to me.

- Ayan

> --
> 2.34.1
>
>


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 14:20:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 14:20:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024972.1400726 (Exim 4.92)
	(envelope-from )
	id 1uUQz2-0004rG-20; Wed, 25 Jun 2025 14:20:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024972.1400726; Wed, 25 Jun 2025 14: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 1uUQz1-0004r9-VX; Wed, 25 Jun 2025 14:20:15 +0000
Received: by outflank-mailman (input) for mailman id 1024972;
 Wed, 25 Jun 2025 14:20: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 1uUQz1-0004r3-2L
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 14:20:15 +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 82957486-51cf-11f0-a30f-13f23c93f187;
 Wed, 25 Jun 2025 16:20:14 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3a50fc7ac4dso1097819f8f.0
 for ; Wed, 25 Jun 2025 07:20:14 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d8391574sm138071255ad.28.2025.06.25.07.20.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 25 Jun 2025 07:20:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 82957486-51cf-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750861213; x=1751466013; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=OC1YKeH/WCJq6Wjy8egzIZEhR8mzEaIjmqEqPACoQhs=;
        b=Z2haDrF9l53w86npbVV0zG7gVr7eQSBX8UnjRqbojCg1z12Cul7GP9XyOEwVcW+3Tl
         oF/TIlvGHo4FnJpCUzDEhRtpHiEVPK1KyE4g5e7SmkeTYQNT3rnpMBSRnQEELzajDF0q
         gbkw4GI4I1qgsSUM3T6vU7cOa/V5ISfy4LXmMMl0mkay8cNl7mHJSvYMEVHu6tl2VwkJ
         BPdtxiHuZXhzdyxssILt6OF+N2IQcBObmfGEMMstt8NOF2LXB23CiPjrtL5Slv4M3AMC
         A/t8VVLEVPbhSU8oJh4Zj+YvwuRr5fawQUagguZeSCkydR2szuy5tsAeDM9xmIKSicB9
         CBkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750861213; x=1751466013;
        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=OC1YKeH/WCJq6Wjy8egzIZEhR8mzEaIjmqEqPACoQhs=;
        b=P7L/pc8OK3rIz/clFp3eXw9kQQEROv+Jc38wuzz9rkIAzUHNjYBBbNXTNMR5E0Vtoq
         K6JxPwX7N26X1Z6jCPhGxe+8GD2N2xjhfMOH+QWvXULjHLG+5Aj26aQmn3t2C4mztRz+
         aG/UOhIrsswNO1yAzzZuLovmgD9Z0dzIZv6OZ7j2LdW8uR0CgavNFTqZDQt0yOLEVgbJ
         3rmy5X8oBbB7K6fdB/BIwQB489BD8DhkucaNXUAxiAIxO8mJE//VfuLUmK94sPIoZe+l
         8n8xhFvWbVfLpPy6jhiM0MBcpm3JctiABh9ChlGiRyGN1SMXIDJTTqdehvTjk00vOfWz
         Rq2w==
X-Forwarded-Encrypted: i=1; AJvYcCW8p9ZlWgKHmSGCbV6dwrHXE1/zNMTk/FyUGJOkQzxcHCVPf+AoQ2zW44wV71zNr47BMpLwd/BTpIE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz8cdxTSYyEWq732JLTuTWzdiPN5+OFL5DsnRIaJIr5iNJoUSsO
	X2M7CVq7APT43eqyUdT0NCK3Wqx1q38p9FMV+5l/ZPTdRN8xbX0P7z3XlDmatLaDOg==
X-Gm-Gg: ASbGnct/LNcJx4/zXo6cMwk8jyvV+ASQY60B/6kcQZFgdCrTZzT96DBhqiZNd33co9Q
	2K91cWCQri9V7fS0twQusKEarCnHyn35o6dnsZmdPWDqgC2S3mbh4Kvp1/Y7oVvKb7Bh1439+Ut
	O+vjd0uS8DAabYz3GWWlAyshik/e5hpjfrnW3irwIiTXoVD52JZ6fBKoI+kiNTzykrWnDprPRDq
	+YZTBY1734wvkrU4rUFYkWgUSTVGyhvnJ76agTKUegLTYZGp0Hf17XZtr3r2ilR2f3kzye6o+2T
	Y1WNzlfNSL3LJe3OV55nZVZ7UD4Sv4e5E2FNjqRBzqvFZZE4CGN6A23QDWH3RsPQD0+4dVCckod
	PiG8YFdKJHCY4G3V7g40jvdE0+a2UbxFYffIzz0op7rPT26g=
X-Google-Smtp-Source: AGHT+IGne5DzCr7NUWkqmaZdVwlFBtB+vLucY3gvlA7JR07+s+GhLyB6Uxq4B9gZB4dTBh+fbWAexw==
X-Received: by 2002:adf:e18f:0:b0:3a1:f5c4:b81b with SMTP id ffacd0b85a97d-3a6ed630717mr2668368f8f.23.1750861213449;
        Wed, 25 Jun 2025 07:20:13 -0700 (PDT)
Message-ID: 
Date: Wed, 25 Jun 2025 16:20:05 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] stubdom/grub: avoid relying on start_info definition
To: Juergen Gross 
Cc: Samuel Thibault ,
 xen-devel@lists.xenproject.org
References: <20250625110843.24840-1-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: <20250625110843.24840-1-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 25.06.2025 13:08, Juergen Gross wrote:
> @@ -432,3 +431,10 @@ out:
>      allocated = 0;
>      xc_interface_close(xc_handle );
>  }
> +
> +static void call_start_info_hook(struct xc_dom_image *dom)
> +{
> +#undef start_info
> +    if ( dom->arch_hooks->start_info )
> +        dom->arch_hooks->start_info(dom);
> +}

Maybe add a comment ahead of the function clarifying that it ought to remain
last?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 14:28:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 14:28:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1024993.1400736 (Exim 4.92)
	(envelope-from )
	id 1uUR6n-0005ll-Rk; Wed, 25 Jun 2025 14:28:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1024993.1400736; Wed, 25 Jun 2025 14:28: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 1uUR6n-0005le-Ni; Wed, 25 Jun 2025 14:28:17 +0000
Received: by outflank-mailman (input) for mailman id 1024993;
 Wed, 25 Jun 2025 14:28: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 1uUR6l-0005lW-Ux
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 14:28:15 +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 a08de970-51d0-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 16:28:13 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-451d54214adso11808715e9.3
 for ; Wed, 25 Jun 2025 07:28:13 -0700 (PDT)
Received: from ?IPV6:2003:e5:8746:1a00:ff67:e633:2aa8:93ba?
 (p200300e587461a00ff67e6332aa893ba.dip0.t-ipconnect.de.
 [2003:e5:8746:1a00:ff67:e633:2aa8:93ba])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a6e8117187sm4624855f8f.101.2025.06.25.07.28.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 25 Jun 2025 07:28:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a08de970-51d0-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750861693; x=1751466493; 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=qw9S+X7qnN19jV+x7VJaMOPSM0RwFy5vyFi9AVqCGq4=;
        b=ciBZ+H2NGo+xcGut4oJ+02UqmJ9LsaKJv39MYAqNTlGG8n8oUHqHFn1oss0Nr/U23Z
         CfY4RyE2e0f8xIHVOlCuWU7Djr9oQKvidknUvkKuflDp1YJNyYdkwR3kF236CxAXbJ+e
         GDKbSqtitJMp8w5N52x3Q2z5ewhWGQt2SpSP2DJ0tuKFT6HbPqzXOd0v5k8IJf7n/Ggm
         5gzqyPA/vGg1bv0bHiG6W55oOqxslxPPyAC3kSpUlAh6MDo2rOzsLp9k53yWo57MXkyJ
         4TICB70T15jAcI4FUKGAg0oMIkiOcdRYQ+dUFAR4Z6kmrJZdFFVWuCYYxVZqWcutSr0V
         kzmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750861693; x=1751466493;
        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=qw9S+X7qnN19jV+x7VJaMOPSM0RwFy5vyFi9AVqCGq4=;
        b=O/TgEH9dkMMvIx9FTXkVLSLMmfA8YHTduOFciRBjcudKpt9eHCRSxhtxAMvGDLJOK1
         UQUvLF5M/looRLkGcc8HjTiJpbtqkr64xH/EiNgpLEC5hqXCHHDJfzyvGy0PwoWftYsM
         9OTut6CAcVj2YFez3VgV2a8+huBcnclDDi2oXIQFrqOGSb+DXnV6WLyyWzIlJsuMKk/V
         V4s9do7ZB7EmSyTEDxe9eKbRPqpr3lPlaDp0ZvsV3fPtRrS67Gx4nqkhn9+2gIOF27//
         ICIothRwJZi4G399KGv/9je/o6sxtQGA7tpEiBr3+s9WstJR27N0wfYWXblVDvSnRdxG
         oekg==
X-Forwarded-Encrypted: i=1; AJvYcCU1jhJgmyJs/172H8Plc0Z6F47Ma7qLpwPeBTnY3xPMmoaIqAtUH+UFwuJe//WmtOutRBh9DZO7ikc=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxd993zCppJmd6rrQc6AGzvlP13fg4C8wLEp9qliACVUwQv5X9V
	le8i2DIG5XSL+UT8QzhKrMkMZhuyXG6Yg3S9k1oYUg2JKzXubdZMYUZ6tGufhgtZmWF3lutOchG
	Uljh3ppU=
X-Gm-Gg: ASbGncubnAGaoZTi0PNRuyiXwQ1IyoOQ1m7d2ZFhDU4OAZjy5JngZdW1jp1K2pY8ols
	AkY5E3Iz8IqSH0ZvtGDLGnQDmrNyFO91HIOhxB8W3d9336tQaxWGvpOIfNIIkeg6qG1OqkfqzDL
	dba/9YUCIUCzH0cWrup+TRloncU1EhMVW7Np4qaggiFU5KOkZAQgB1pc9/KpqBuUKCK55mpl5jM
	AVy09KC1T1qwOh0Z0hQCEXSx89oqZNALX4aK2adiQ64prjq282Zi4rxq/ixyyLOluqhcA/Zf8Qx
	XbM0c8d14mmw78khrTD4H8h8WCG6Qo6xsdS45MHOnfhYWZFLe7GaYNTs6on71k+Hh0ViN2LiXL7
	EZ0P82/koYFGgOKJKJSKi/gPnZxSlZNnznmFz6Cx8yIkAkyyOh/LN9OyGPEvzxb/SzKLN0+Ajm5
	zj2ZkVBMNhqk8=
X-Google-Smtp-Source: AGHT+IFi8xbdBn4Q/OQtDPIvwYsVnbfcBoQry3KfQ9qeYmrKsDasKnEl818iXs4xP9bUZUcyoXXW9Q==
X-Received: by 2002:a05:600c:3e87:b0:450:cabd:160 with SMTP id 5b1f17b1804b1-45381aa4a74mr34947745e9.3.1750861693207;
        Wed, 25 Jun 2025 07:28:13 -0700 (PDT)
Message-ID: 
Date: Wed, 25 Jun 2025 16:28:11 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] stubdom/grub: avoid relying on start_info definition
To: Jan Beulich 
Cc: Samuel Thibault ,
 xen-devel@lists.xenproject.org
References: <20250625110843.24840-1-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="------------HEz1L8lF0CODSDdXSJOb0xlG"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------HEz1L8lF0CODSDdXSJOb0xlG
Content-Type: multipart/mixed; boundary="------------SdlYIbD1f6CwtfcK4p66slQ7";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Jan Beulich 
Cc: Samuel Thibault ,
 xen-devel@lists.xenproject.org
Message-ID: 
Subject: Re: [PATCH] stubdom/grub: avoid relying on start_info definition
References: <20250625110843.24840-1-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=

--------------SdlYIbD1f6CwtfcK4p66slQ7
Content-Type: multipart/mixed; boundary="------------MN8lH1EsB1dqeen9LADNKhNF"

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

T24gMjUuMDYuMjUgMTY6MjAsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAyNS4wNi4yMDI1
IDEzOjA4LCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPj4gQEAgLTQzMiwzICs0MzEsMTAgQEAg
b3V0Og0KPj4gICAgICAgYWxsb2NhdGVkID0gMDsNCj4+ICAgICAgIHhjX2ludGVyZmFjZV9j
bG9zZSh4Y19oYW5kbGUgKTsNCj4+ICAgfQ0KPj4gKw0KPj4gK3N0YXRpYyB2b2lkIGNhbGxf
c3RhcnRfaW5mb19ob29rKHN0cnVjdCB4Y19kb21faW1hZ2UgKmRvbSkNCj4+ICt7DQo+PiAr
I3VuZGVmIHN0YXJ0X2luZm8NCj4+ICsgICAgaWYgKCBkb20tPmFyY2hfaG9va3MtPnN0YXJ0
X2luZm8gKQ0KPj4gKyAgICAgICAgZG9tLT5hcmNoX2hvb2tzLT5zdGFydF9pbmZvKGRvbSk7
DQo+PiArfQ0KPiANCj4gTWF5YmUgYWRkIGEgY29tbWVudCBhaGVhZCBvZiB0aGUgZnVuY3Rp
b24gY2xhcmlmeWluZyB0aGF0IGl0IG91Z2h0IHRvIHJlbWFpbg0KPiBsYXN0Pw0KDQpHb29k
IGlkZWEuDQoNCkknbGwgYWRkOg0KDQovKiBObyByZWZlcmVuY2VzIHRvIHN0YXJ0X2luZm8g
b2YgTWluaS1PUyBhZnRlciB0aGlzIGZ1bmN0aW9uLiAqLw0KDQoNCkp1ZXJnZW4NCg==
--------------MN8lH1EsB1dqeen9LADNKhNF
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-----

--------------MN8lH1EsB1dqeen9LADNKhNF--

--------------SdlYIbD1f6CwtfcK4p66slQ7--

--------------HEz1L8lF0CODSDdXSJOb0xlG
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/Ey8FAmhcB3sFAwAAAAAACgkQsN6d1ii/Ey+e
ogf6AhUwS+4G4yPlmh8x7VLyEAv3XKGrob3ja/rpNp4DWm4vR3/v3NKOO4wBNNmDgSFTBup8T591
v2M7gwOqD8XSGcCzKNSEFhDExz/tJ7iW7i9mD+I7IpQRhG6N/BM+L3VT/JZYBbNSwsPVnFOewvc0
SGOXzEXeAc7WIK/NpsiV36zT5RoMseRkVjTJst3OUZEB1+6yOD3s+cozDxBt+JDvthoY0zoRhVkW
BGufCKMQtYTsRhqfhVavRz4G3YKXksJjNbMrH/KLtQ76dCXr7xE+vqPRKCE7WZHDweJK/6O6eUpN
FYM45H40qi/PRlpXVnsj2vOwfNrr3dpCnpK955EECA==
=QU7h
-----END PGP SIGNATURE-----

--------------HEz1L8lF0CODSDdXSJOb0xlG--


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 14:31:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 14:31:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1025000.1400745 (Exim 4.92)
	(envelope-from )
	id 1uUR9T-0007JD-7N; Wed, 25 Jun 2025 14:31:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1025000.1400745; Wed, 25 Jun 2025 14: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 1uUR9T-0007J6-4U; Wed, 25 Jun 2025 14:31:03 +0000
Received: by outflank-mailman (input) for mailman id 1025000;
 Wed, 25 Jun 2025 14: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 1uUR9S-0007Hj-3B
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 14:31:02 +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 01b25bb1-51d1-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 16:30:56 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a4f72cba73so619373f8f.1
 for ; Wed, 25 Jun 2025 07:30:56 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a6e8114795sm4867080f8f.92.2025.06.25.07.30.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 25 Jun 2025 07:30:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 01b25bb1-51d1-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750861856; x=1751466656; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=AfoV0ok+azQOUk9Jz8s1HVQ7+dgn6nR8KSlRZrz/LRc=;
        b=aoFuBjML/fSt4tR1hqGXHLl2w/3ud7hzvP5yFWH6ct+NOQPKJIiOwMokw6b53hzeht
         eISgTA9QiTTzuEMC6pwUPYWlLG9f00bDG1AAnuucTlwVouJXgs9eOjAOMkSvfSnMR5WN
         IEM30mEpLF5U245ShybQpIgSRTASUEMFPxm9k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750861856; x=1751466656;
        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=AfoV0ok+azQOUk9Jz8s1HVQ7+dgn6nR8KSlRZrz/LRc=;
        b=fOFoC/uWKKnCZk2gMS52zMIGvxilKPyLNMHGsB8pof37nQbFKwZAV8JjbnkfCWJcGT
         2S7gWcmozK/PS4RTYkMZEevW/puwAB4Mn6igKvo+Ey4JewOxWUYE2YR8awu5h58HfFlU
         KLb/et40yvfRCIFnkNt5N06uUK91/FLPE+l1pnN9Lh34zpgDPoUIkx2zrBInr19o1WVa
         +nyolMTWFJQM5LLIA/iIDBDZQLYNoCLzU5l0ZDS3OozMUISxi7o1vK6iAwnZG8yL/M3n
         Umwm3hqNGubtQtamCME+duDUDGj5ZmwBIUPwMU5ZdxJ97NLbacypa/hwlBq2Cs/8LPjr
         M7vA==
X-Forwarded-Encrypted: i=1; AJvYcCUmWKoydCmUrTBCNYn7GbViU0TpV9LousoxVOU5/mXbBkt9Mxi24AlVG6lmZT7clEF2om2WKmO9FDc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyazkJnh/IhokV5SqUSasy32ccVvTE2cu7RL4ZfsF2wffyTb0Fn
	L15AidkHUhge1wlGcd775sDVmOtucUqOiApPrXc1HBRrltFDwgUpHwMieXrcLqyO1IUlgVD6S/c
	+52HCAJFjbw==
X-Gm-Gg: ASbGncv9UoRxCb+JONtZEp2cfEOAg6MSsnGX1GJoGNWYhUNspKvYbfCHC2Hl9cVpWlG
	/fHvUgPxqJC0QSG+3h2tq3yMBUw0gg+7c58gVb9c+3mdXoYCDoGM8zA7PvYmxh5AVyTBXw+0psB
	0xYl3ZuBGWpZ/KhD4UU2n3wfOplyckcRkVrMVYWoEtuDM3Y44I0/1gbMA5FaFnMCg478QbI+4er
	8eXPpFJCI5zFqjZrnL4qx7tz609dPaKjgXXRr2GxjEk3TQ8rnYELOZhTtJH+SyAkNePhpP1MY0R
	gGLFwcQsfbclvnrDZknS2kwCkUKXJC1cOgyMeUgwoQY6l9XEw7NaIB3sQiWQFibL6u5ppypE7Wq
	YBxWC9oBFWDAAqbuLEUGe3j9NVMk=
X-Google-Smtp-Source: AGHT+IG0Kr73omSq5ZOcD9l0skpoHlI828vWdcJ5jZ596WJZxDcKTuUVAfysoPI+0MqI/YyCzv6pYQ==
X-Received: by 2002:a5d:5846:0:b0:3a4:c71a:8119 with SMTP id ffacd0b85a97d-3a6ecf5d361mr3211910f8f.25.1750861856133;
        Wed, 25 Jun 2025 07:30:56 -0700 (PDT)
Message-ID: 
Date: Wed, 25 Jun 2025 15:30:55 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] stubdom/grub: avoid relying on start_info definition
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= ,
 Jan Beulich 
Cc: Samuel Thibault ,
 xen-devel@lists.xenproject.org
References: <20250625110843.24840-1-jgross@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: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 25/06/2025 3:28 pm, Jürgen Groß wrote:
> On 25.06.25 16:20, Jan Beulich wrote:
>> On 25.06.2025 13:08, Juergen Gross wrote:
>>> @@ -432,3 +431,10 @@ out:
>>>       allocated = 0;
>>>       xc_interface_close(xc_handle );
>>>   }
>>> +
>>> +static void call_start_info_hook(struct xc_dom_image *dom)
>>> +{
>>> +#undef start_info
>>> +    if ( dom->arch_hooks->start_info )
>>> +        dom->arch_hooks->start_info(dom);
>>> +}
>>
>> Maybe add a comment ahead of the function clarifying that it ought to
>> remain
>> last?
>
> Good idea.
>
> I'll add:
>
> /* No references to start_info of Mini-OS after this function. */

Given how few uses of start_info there actually are, can't you just drop
that piece of extreme obfuscation and make this work like regular C?

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 14:47:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 14:47:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1025156.1400812 (Exim 4.92)
	(envelope-from )
	id 1uURPh-0002BA-Uc; Wed, 25 Jun 2025 14:47:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1025156.1400812; Wed, 25 Jun 2025 14:47: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 1uURPh-0002B3-Rs; Wed, 25 Jun 2025 14:47:49 +0000
Received: by outflank-mailman (input) for mailman id 1025156;
 Wed, 25 Jun 2025 14:47: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 1uURPg-0002Ax-Ki
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 14:47:48 +0000
Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com
 [2a00:1450:4864:20::342])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5bd0a375-51d3-11f0-a30f-13f23c93f187;
 Wed, 25 Jun 2025 16:47:47 +0200 (CEST)
Received: by mail-wm1-x342.google.com with SMTP id
 5b1f17b1804b1-4536b8c183cso121205e9.0
 for ; Wed, 25 Jun 2025 07:47:47 -0700 (PDT)
Received: from ?IPV6:2003:e5:8746:1a00:ff67:e633:2aa8:93ba?
 (p200300e587461a00ff67e6332aa893ba.dip0.t-ipconnect.de.
 [2003:e5:8746:1a00:ff67:e633:2aa8:93ba])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a6e80f264esm4758822f8f.47.2025.06.25.07.47.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 25 Jun 2025 07:47:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5bd0a375-51d3-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750862866; x=1751467666; 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=x9RFIw6wUxqrKC8KklVrEHXXs9oNUzPHaXVEpobsAwY=;
        b=gsHhmklYjFa7v/2eIJ7iaUYOPTxaRYfMfqi6Tmtd5sS5+dKeOPeYXMAtxLfjGJ90wm
         Fl2XaNcCXPTVszhEHr1gZH4UijQ+vno676hRT9lhcfr4WaxH5X/N0k8S5E/mRxSu/hue
         mu0RICn4eSF8QgUJaHmgsG+ncuZwOpCfnOhj5ECzcPe5Klt7uyM4jLGZx0iwj0Yyz52/
         CvH3e9631J1z0VmbrnpCpFBDf8kmel+BYwDoqoybmmevoOUrBDxcQbbNMMfymjifA/uo
         s9awE1r/SqPlpl4vjTxyALpVv4zweK985a0SZDceCojYmIk6p+Iq5IK7Aoyz88spE2cB
         tFQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750862866; x=1751467666;
        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=x9RFIw6wUxqrKC8KklVrEHXXs9oNUzPHaXVEpobsAwY=;
        b=QzPzvKB/1zO1FTOuqpvdqsLJSgC+uPxaox4mLvQU9miEg9sJSR1lHzz3OGeHUP9lSD
         3loiqr8Q6v33GoMSV354PFBgGsjWzKUr1uY5cUPSeYPuviYWGVz4y/C8Wnl74CQNi7Ml
         Rq4pNb2C9qxpTEjZSCLkHX0Q4/tiIzcWrXJl0d2y7sfZwo8PEo4J1ttUJCxKV2vtDrk6
         +4U78GalTG3KMEtV2lkfhRiFADnltA+NX3aLUphL8Vyhv9QTzBCYm/vv3U47OEB11Nvo
         1gLg+i/hTy+X0ysBjLhRONfixTqiTvWMAaYPbjERY9uyI/N3g+2gaIfowg8uoUGgmhPG
         zv0w==
X-Forwarded-Encrypted: i=1; AJvYcCV91lNmaagt18k/8U4XYLrooz9skUxcAflA/BXp/mX+hJdpCgSQbApbygJ72ByJvhf7NKUQbzjpwVM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yydv3R1KVff8OqPCiRsYZBHNXNo2e7mIzOjHt2MOyEnSYX39SWs
	tZstZyMvavJEjtZhrxeI6+DTXokYp6zBr7HzLmITrmCT3y3OkdT1POCUA3RTd2Z+9Aw=
X-Gm-Gg: ASbGncsdiHvt+lr1YMpps8YJrWCb5k1Oel9ZM3CQvG/s5jj15HO8fFl/VF4zqhXtAnt
	1ydhn8B8IsGpUFHkDJo7mtwefsTsIqoSX63NIp5ktB6jy1VgnzEukQfHOJuxsxDMbZAfHIIzYdG
	FyeLndVegjZs9lfdnTWItT7pNI/Ye7RfJmeN9XDGM/kGWZ0aRq1sbUGe0N/xMGNwrMjjuaOuMEQ
	TSbWL4tsEIQjmcIQMrrSD0iELFtAmukX7jVA3cgzse/X1/bRGR4hl/rxXXG5YJkjOifGyMfQvsD
	BcB81qQT1195aZRr79XW9dHy/dI9HanO/BTSFavY0j6iOKy9Pnj/vcGBDulUnEMYYSdvH6JVuXA
	GvosH4m3taXyJC1fL823eRMsHH8GIaTSC2ovXGUeCvyMRvZPDsXpqQM6/3ELCSxYH4hlhpGzxsg
	uOBKGlaPI+mgw=
X-Google-Smtp-Source: AGHT+IHa7qBvbArMb+KXB+Y4KskDxfPnw+YxQMAp4qBGD2NLYJ7aWSzZ2IOVs6L5wxls3EYlkdhQ2g==
X-Received: by 2002:a05:600c:3541:b0:453:10c1:cb21 with SMTP id 5b1f17b1804b1-45381b8a0d7mr33522775e9.8.1750862866326;
        Wed, 25 Jun 2025 07:47:46 -0700 (PDT)
Message-ID: <6eeb2f5a-3ef1-402f-a56d-3053984bf8f8@suse.com>
Date: Wed, 25 Jun 2025 16:47:44 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] stubdom/grub: avoid relying on start_info definition
To: Andrew Cooper , Jan Beulich 
Cc: Samuel Thibault ,
 xen-devel@lists.xenproject.org
References: <20250625110843.24840-1-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="------------ordGi8MfxLipVyK70PP0rJSW"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------ordGi8MfxLipVyK70PP0rJSW
Content-Type: multipart/mixed; boundary="------------HAYeLfaIqdZkW3zCm16glos7";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Andrew Cooper , Jan Beulich 
Cc: Samuel Thibault ,
 xen-devel@lists.xenproject.org
Message-ID: <6eeb2f5a-3ef1-402f-a56d-3053984bf8f8@suse.com>
Subject: Re: [PATCH] stubdom/grub: avoid relying on start_info definition
References: <20250625110843.24840-1-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=

--------------HAYeLfaIqdZkW3zCm16glos7
Content-Type: multipart/mixed; boundary="------------Z4qHNc0BR3WUAaVtue4RInwa"

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

T24gMjUuMDYuMjUgMTY6MzAsIEFuZHJldyBDb29wZXIgd3JvdGU6DQo+IE9uIDI1LzA2LzIw
MjUgMzoyOCBwbSwgSsO8cmdlbiBHcm/DnyB3cm90ZToNCj4+IE9uIDI1LjA2LjI1IDE2OjIw
LCBKYW4gQmV1bGljaCB3cm90ZToNCj4+PiBPbiAyNS4wNi4yMDI1IDEzOjA4LCBKdWVyZ2Vu
IEdyb3NzIHdyb3RlOg0KPj4+PiBAQCAtNDMyLDMgKzQzMSwxMCBAQCBvdXQ6DQo+Pj4+ICDC
oMKgwqDCoMKgIGFsbG9jYXRlZCA9IDA7DQo+Pj4+ICDCoMKgwqDCoMKgIHhjX2ludGVyZmFj
ZV9jbG9zZSh4Y19oYW5kbGUgKTsNCj4+Pj4gIMKgIH0NCj4+Pj4gKw0KPj4+PiArc3RhdGlj
IHZvaWQgY2FsbF9zdGFydF9pbmZvX2hvb2soc3RydWN0IHhjX2RvbV9pbWFnZSAqZG9tKQ0K
Pj4+PiArew0KPj4+PiArI3VuZGVmIHN0YXJ0X2luZm8NCj4+Pj4gK8KgwqDCoCBpZiAoIGRv
bS0+YXJjaF9ob29rcy0+c3RhcnRfaW5mbyApDQo+Pj4+ICvCoMKgwqDCoMKgwqDCoCBkb20t
PmFyY2hfaG9va3MtPnN0YXJ0X2luZm8oZG9tKTsNCj4+Pj4gK30NCj4+Pg0KPj4+IE1heWJl
IGFkZCBhIGNvbW1lbnQgYWhlYWQgb2YgdGhlIGZ1bmN0aW9uIGNsYXJpZnlpbmcgdGhhdCBp
dCBvdWdodCB0bw0KPj4+IHJlbWFpbg0KPj4+IGxhc3Q/DQo+Pg0KPj4gR29vZCBpZGVhLg0K
Pj4NCj4+IEknbGwgYWRkOg0KPj4NCj4+IC8qIE5vIHJlZmVyZW5jZXMgdG8gc3RhcnRfaW5m
byBvZiBNaW5pLU9TIGFmdGVyIHRoaXMgZnVuY3Rpb24uICovDQo+IA0KPiBHaXZlbiBob3cg
ZmV3IHVzZXMgb2Ygc3RhcnRfaW5mbyB0aGVyZSBhY3R1YWxseSBhcmUsIGNhbid0IHlvdSBq
dXN0IGRyb3ANCj4gdGhhdCBwaWVjZSBvZiBleHRyZW1lIG9iZnVzY2F0aW9uIGFuZCBtYWtl
IHRoaXMgd29yayBsaWtlIHJlZ3VsYXIgQz8NCg0KSG1tLCB5b3UgbWVhbiBieSB1c2luZyBz
dGFydF9pbmZvX3B0ciBkaXJlY3RseT8NCg0KVGhpcyB3b3VsZCBiZSBwb3NzaWJsZSwgYnV0
IGl0IHdvdWxkIGludHJvZHVjZSBhIHR3by13YXkgZGVwZW5kZW5jeSBiZXR3ZWVuDQp4ZW4u
Z2l0IGFuZCBtaW5pb3MuZ2l0Lg0KDQpSaWdodCBub3cgdGhlIGJ1aWxkIGlzIGJhc2ljYWxs
eSBmaW5lLCBhcyBDb25maWcubWsgZG9lc24ndCByZWZlcmVuY2UgdGhlDQp2YXJpYW50IG9m
IE1pbmktT1MgYnJlYWtpbmcgdG9kYXkncyBncnViLXB2Lg0KDQpBcHBseWluZyBteSBjdXJy
ZW50IHBhdGNoIHRvIGdydWItcHYgd2lsbCBzdGlsbCB3b3JrIHdpdGggdGhlICJvbGQiIE1p
bmktT1MsDQp3aGljaCB0aGVuIGNvdWxkIGJlIHVwZGF0ZWQgdG8gYSBjb21taXQtaWQgY29u
dGFpbmluZyB0aGUgcmVsYXRlZCBNaW5pLU9TDQpwYXRjaCBkZWZpbmluZyBzdGFydF9pbmZv
IGRpZmZlcmVudGx5Lg0KDQpUaGlzIHVwZGF0ZSBzdHJhdGVneSB3b3VsZCBub3QgcmVzdWx0
IGluIGEgc2l0dWF0aW9uIHdoZXJlIHRoZSBidWlsZCBpcyBicm9rZW4sDQp3aGlsZSBtb2Rp
ZnlpbmcgZ3J1Yi1wdiB0byB1c2Ugc3RhcnRfaW5mb19wdHIgZGlyZWN0bHkgaXNuJ3QgcG9z
c2libGUgd2l0aG91dA0KZWl0aGVyIGJyZWFraW5nIHRoZSBidWlsZCBpbiBiZXR3ZWVuICh3
ZSdkIG5lZWQgYSBNaW5pLU9TIHVwZGF0ZSBmb3IgdGhhdCB0bw0KaGF2ZSAiRVhQT1JUX1NZ
TUJPTChzdGFydF9pbmZvX3B0cik7IiBpbmNsdWRlZCksIG9yIGJ5IHRha2luZyBteSBjdXJy
ZW50IHBhdGNoDQphcyBhbiBpbnRlcm1lZGlhdGUgc3RlcCBhbmQgb25seSB0aGVuIHN3aXRj
aCBncnViLXB2IHRvIHVzZSBzdGFydF9pbmZvX3B0ci4NCg0KVGhvdWdodHM/DQoNCg0KSnVl
cmdlbg0K
--------------Z4qHNc0BR3WUAaVtue4RInwa
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-----

--------------Z4qHNc0BR3WUAaVtue4RInwa--

--------------HAYeLfaIqdZkW3zCm16glos7--

--------------ordGi8MfxLipVyK70PP0rJSW
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/Ey8FAmhcDBEFAwAAAAAACgkQsN6d1ii/Ey/F
mAf5AePUfJNXbyF8kXda94FeI2iCREuNO33hTE7Hh3kfREVRabwwQgGOeibQzEvh0y3cev3l4Efm
Zf5ONNUCKbNadTBn1AMlRsIyA00udVf2SvJ9CSso6ROeurVO+PMvK5bVPN9u/Gnk4rcacK9+GKFn
6cJ3032sKXdfYeXTRXarOe5cvWCfHH6AW4vHnkj/7wqFET3iRDJ9jgdZ1LpCX7ufh1GO+a30F7Zj
Pos6YDp0Z9hEf8GWVdczX0SpxkjMtBTlC4QK/nBw155lIehbBL6cRIdE9bKSMMttrEjBI5eQOWm8
Qhpt87o25dMr3QnIlyYj2lGxut6HEcNnWkwCJH9Wlg==
=oEhA
-----END PGP SIGNATURE-----

--------------ordGi8MfxLipVyK70PP0rJSW--


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 14:48:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 14:48:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1025159.1400822 (Exim 4.92)
	(envelope-from )
	id 1uURPz-0002V4-9v; Wed, 25 Jun 2025 14:48:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1025159.1400822; Wed, 25 Jun 2025 14:48:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uURPz-0002Uv-6Z; Wed, 25 Jun 2025 14:48:07 +0000
Received: by outflank-mailman (input) for mailman id 1025159;
 Wed, 25 Jun 2025 14:48: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 1uURPx-0002SA-IF
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 14:48:05 +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 65acc9aa-51d3-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 16:48:03 +0200 (CEST)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-ad88d77314bso344632166b.1
 for ; Wed, 25 Jun 2025 07:48:03 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ae053ecbf36sm1071643166b.53.2025.06.25.07.48.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 25 Jun 2025 07:48:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 65acc9aa-51d3-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750862883; x=1751467683; 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=fge5zHFjiGQNL2sTZ1U7ExzyqJgZjSHIFj9BUTjsG58=;
        b=Oy6l6fxmlktiMrpmiJ8ihEiiTDlRQIwxBvvLA3cwcEzFqnJJuUukrfcsT2hr7Ajqc/
         i7z5YDQLrw59ms3D2MgGO4Zi2rI/aEGEYrbZOUSc0Dkm+y87m+HR9reI9sCTxkF4rTBz
         hUJFf55PlzDjCbc223u8IxHBF63dyaBjxRJR9uNOp1lsJ0gSHbF454DSVcU8Hk3bhb1Z
         O7gqe7ygVNZWzOHqKp2IwSI3XiICPA6qLO+Wyiu6WfGdKZO+7dAoR+7pXu6FcOVf98P7
         jpR6WOg10FWEtxreR/BgInXDvL7izmoNeOby20hd0IAoTSS+s4uhZPOgfTZw5Jaq/0Nq
         53Cw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750862883; x=1751467683;
        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=fge5zHFjiGQNL2sTZ1U7ExzyqJgZjSHIFj9BUTjsG58=;
        b=Uhdw87gIzRmIvBQifaq14HUJx/ktKPO4MFe0RSsG4LZOQMPbDl+8+ZxR2uJjd6RF9i
         u+WM2VfMHw1WUcEoLqS9p+TIPSIMACuwBVdYqWjqZigQsn8gGpZqcQdQ4HHpVkSDD9Yt
         O2uwrWbUSnyfFf7DIHkoV0o0DEF2JOguGrCrVNPwqTRUELwVKiUJbd0iU3u0XMiGXtkD
         TUuHsiLvsZFDVilUDKTf8vhteskiJjLcX5hbHEgsxhXyQiUeFsYHctOswVhLCbRd8Lwa
         TNagQsFZyjDDjNzBAXIgbnD+gw4E4WgfLblEvph+bzcorZAZkH7HzxB/w42HQcHX5SED
         y7kA==
X-Forwarded-Encrypted: i=1; AJvYcCVh6iSrdXTEJXxh16bYRnJuCTSVuVC6qXPfFKpZsinLFOmfwOQS8A/NAufnbvuHRa70aPGr/W2eyQk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyPoPsTcxLxnPloWMJ1g/vS09nOxpTUl34rsR2dGYGKmd9tl4zv
	dVj6o78H9sg63RssLtZiqqk2v0qkrdMnU4sjV8AkKr9RYrKxcG7xPNIJ
X-Gm-Gg: ASbGncs2kn69FBWvL1gKrKfr4FQtxg04rxgC67CYI8JN8UlmDvEqhq7DHttnXQFeBUF
	bd+Zr+phMUIFyQmkkNUG4ber8/FXoQZ4sh/4rmp1euq5MjTYzv8OxLunjlFv7YEJEJBSm+nHnHl
	hzhHqvWxFtSktXyXFk6oJiOrIkGyZ2TgpgKmlVGMEBpN9e1tfjCJH0T2jYVkajSZAobJcns79jG
	MT+7w9kx4dzVQBbsFpALbLv+lZsceXvFCIe0eex2BBP88fd6DRaJV04ued+UB3FHIWkD/YJP7c/
	04DxkYpoNaNvF80Gl8E/e3L1kWdHpkorHrOlWVMAVU3L/OGkSelQ67dYirft6+hZO/Jb6x9l+PE
	J7hpU58Gx5pOVVsG2FhLt93MlGYrcVdrTIyQ=
X-Google-Smtp-Source: AGHT+IGvol92BsSzpbkNsKXd4lbpieZOu3E/OeEyZ+2JuL/BhiAVRwOCXdiS8cL75SovyCLe/XUFsw==
X-Received: by 2002:a17:906:7953:b0:ad8:930b:4c32 with SMTP id a640c23a62f3a-ae0be9bd89amr325693566b.28.1750862882586;
        Wed, 25 Jun 2025 07:48:02 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------jFpNxgHsVLo55CahoZCNutO2"
Message-ID: <3db6770c-005f-4123-bb85-0445b4d2d437@gmail.com>
Date: Wed, 25 Jun 2025 16:48:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 04/17] xen/riscv: construct the P2M pages pool for
 guests
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: 
 
 <3bbc8962-eaaa-4ed0-bc21-757bdc6be49d@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <3bbc8962-eaaa-4ed0-bc21-757bdc6be49d@suse.com>

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


On 6/18/25 5:53 PM, Jan Beulich wrote:
> On 10.06.2025 15:05, Oleksii Kurochko wrote:
>> @@ -18,10 +20,20 @@ struct arch_vcpu_io {
>>   struct arch_vcpu {
>>   };
>>   
>> +struct paging_domain {
>> +    spinlock_t lock;
>> +    /* Free P2M pages from the pre-allocated P2M pool */
>> +    struct page_list_head p2m_freelist;
>> +    /* Number of pages from the pre-allocated P2M pool */
>> +    unsigned long p2m_total_pages;
>> +};
>> +
>>   struct arch_domain {
>>       struct hvm_domain hvm;
>>   
>>       struct p2m_domain p2m;
>> +
>> +    struct paging_domain paging;
> With the separate structures, do you have plans to implement e.g. shadow paging?
> Or some other paging mode beyond the basic one based on the H extension?

No, there is no such plans.

>   If the
> structures are to remain separate, may I suggest that you keep things properly
> separated (no matter how e.g. Arm may have it) in terms of naming? I.e. no
> single "p2m" inside struct paging_domain.

Arm doesn't implement shadow paging too (AFAIK) and probably this approach was
copied from x86, and then to RISC-V.
I thought that a reason for that was just to have two separate entities: one which
covers page tables and which covers the full available guest memory.
And if the only idea of that was to have shadow paging then I don't how it should
be done better. As p2m code is based on Arm's, perhaps, it makes sense to have
this stuff separated, so easier porting will be.

>
>> @@ -105,6 +106,9 @@ int p2m_init(struct domain *d)
>>       struct p2m_domain *p2m = p2m_get_hostp2m(d);
>>       int rc;
>>   
>> +    spin_lock_init(&d->arch.paging.lock);
>> +    INIT_PAGE_LIST_HEAD(&d->arch.paging.p2m_freelist);
> If you want p2m and paging to be separate, you will want to put these in a new
> paging_init().

I am not really understand what is wrong to have it here, but likely it is because
I don't really get an initial purpose of having p2m and paging separately.
It seems like p2m and paging are connected between each other, so it is fine
to init them together.

~ Oleksii

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



  
    
  
  
    

    
    
    
    
    On 6/18/25 5:53 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 10.06.2025 15:05, Oleksii Kurochko wrote:

    
      
    
        
    @@ -18,10 +20,20 @@ struct arch_vcpu_io {
 struct arch_vcpu {
 };
 
+struct paging_domain {
+    spinlock_t lock;
+    /* Free P2M pages from the pre-allocated P2M pool */
+    struct page_list_head p2m_freelist;
+    /* Number of pages from the pre-allocated P2M pool */
+    unsigned long p2m_total_pages;
+};
+
 struct arch_domain {
     struct hvm_domain hvm;
 
     struct p2m_domain p2m;
+
+    struct paging_domain paging;

    
      
    
      
    With the separate structures, do you have plans to implement e.g. shadow paging?
Or some other paging mode beyond the basic one based on the H extension?
    
    
    
    
    No, there is no such plans.


    
    
    
      
     If the
structures are to remain separate, may I suggest that you keep things properly
separated (no matter how e.g. Arm may have it) in terms of naming? I.e. no
single "p2m" inside struct paging_domain.
    
    
    
    
    Arm doesn't implement shadow paging too (AFAIK) and probably this approach was
copied from x86, and then to RISC-V.
I thought that a reason for that was just to have two separate entities: one which
covers page tables and which covers the full available guest memory.
And if the only idea of that was to have shadow paging then I don't how it should
be done better. As p2m code is based on Arm's, perhaps, it makes sense to have
this stuff separated, so easier porting will be.


    
    
    
      
    

    
      
    
        
    @@ -105,6 +106,9 @@ int p2m_init(struct domain *d)
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
     int rc;
 
+    spin_lock_init(&d->arch.paging.lock);
+    INIT_PAGE_LIST_HEAD(&d->arch.paging.p2m_freelist);

    
      
    
      
    If you want p2m and paging to be separate, you will want to put these in a new
paging_init().
    
    
    
    
    I am not really understand what is wrong to have it here, but likely it is because
I don't really get an initial purpose of having p2m and paging separately.
It seems like p2m and paging are connected between each other, so it is fine
to init them together.

~ Oleksii
    
  


--------------jFpNxgHsVLo55CahoZCNutO2--


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 14:55:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 14:55:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1025184.1400832 (Exim 4.92)
	(envelope-from )
	id 1uURXQ-0004p4-VR; Wed, 25 Jun 2025 14:55:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1025184.1400832; Wed, 25 Jun 2025 14:55: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 1uURXQ-0004ox-SD; Wed, 25 Jun 2025 14:55:48 +0000
Received: by outflank-mailman (input) for mailman id 1025184;
 Wed, 25 Jun 2025 14: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 1uURXQ-0004or-0c
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 14:55:48 +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 795d7e14-51d4-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 16:55:46 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3a52874d593so6410337f8f.0
 for ; Wed, 25 Jun 2025 07:55:46 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-315f54417f7sm2081092a91.45.2025.06.25.07.55.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 25 Jun 2025 07:55:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 795d7e14-51d4-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750863345; x=1751468145; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=4DEBsRDON+pSe3JqtFBV4gG9aGg5hlLrM3lQwQJNfNw=;
        b=VJfHcVIhmMAkd7DU3vUITXI0zafxP7tzeeW74pf73+oZPCjljzGwJhGNGnA86fXVMn
         Mb5yhQNDcL8QgaO+biaMioWN963ncy6+XxYuiy6PsHinBcuL7VSni2nvh5efm1NZ+LY/
         WeU+yQvdICwh/EfdXZt3lpts/OGSWBSMnger5i4Fz/wRskp3cgRdfG4kfypE9De5OTLk
         2P3Don/8LywgcugXeyj1tzr+44t2guzLkHLe14dqbcT7RycTR8BZuzhawAYQfYEMCCD4
         jhGaU+xCvTmPv25ADuOmCreU7DqDATMRgPzdeXQZUnZLY0Tc6fY/8+ygr5f51aFM9jwd
         87Hg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750863345; x=1751468145;
        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=4DEBsRDON+pSe3JqtFBV4gG9aGg5hlLrM3lQwQJNfNw=;
        b=PdCWN4QSi7YAba2Gzv85D4E9wsF566vYj/YhKwZUNToG+WPRNenUooDdQIPwYj2yV2
         6LL4/brAFNZczjhMl9wXUXX7XvBjwenbC7vfLBID0S0MK4wwu4qTJ+2sRR+yDMp3oLzD
         CJZnmBjQLukyfwVB+SlrGuIo7JdTdx42K7Dx3gjFa3/45i8ckhvD90zdKO5zKs7VauN7
         PLhrW4BNELTydSUo3Ol4+P6fFNoc3r9ka0en0K3HGx59rHmCzRAweoIfBqvzO4dt03zI
         SdhB5zyCTBRbchuowHxR3Tw6yyJTGnwihg6xLVKTD7IUTmGbGnwXoTqi38NqUOyvTR19
         720w==
X-Forwarded-Encrypted: i=1; AJvYcCVNisb5yqpiJHPisFDV9DVFmRw3wqxEdPX97seXAQqRSmyUJ6ygclDNHPvK5YFYjUrRVbXaG7mWJhk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzZXGhEjPt11FcWNTOVfGYCnxz5ApErrk4gEdOTrXrV/b89+7z8
	vaT3DclT+naTfH7aqs9EbTN5GfdyCl6vnGGlKVXIhdTv0W9b7XZ0M0Xc+A/5cpDChA==
X-Gm-Gg: ASbGncviltuM0n05wvULawdUeK8Ss9oXLFSt4fOKI2BA7Fgiijy/7Mi7srcpTlAGHdc
	yGFVvwxCvgvpc3v1PWGLEjdfsAk0aBjqJKB4aKiQCKpMmbwvn/3GjIfnNl8fG8z7Fo8basml9XQ
	7V/qsjEvf1DYNzdn7ImljU0ToGD0T5N84Gq+FXyf8r7rospUjAo7h8O9rLRF6NcmZki4GHfvppw
	edPAeCKTDcfSKtsYihm+6kMEuFBGXg0TvlrEN2ga9+bn7MOodk/fKWyGh79H8MpSkrFDHdekiI3
	oottc1oHdZ8KKaHUvrxF1GP8qvVFY1H1gvwfwBNGqeCi5oO2yGl+3UCyWWwukCd0iAecV52Hysb
	suPUGPHZkbuHpuAoR41TAtD7rQApvIoY0v+7VH22X5P0duj0=
X-Google-Smtp-Source: AGHT+IHJfn4yoTaF86xXFVjN1+uRRejVOD5+T6aINQOWRVUlLVO+PaE2dTBGu8hc/TqMdYKcfR7atg==
X-Received: by 2002:a05:6000:2c13:b0:3a4:e68e:d33c with SMTP id ffacd0b85a97d-3a6ed64ba0emr2863608f8f.47.1750863345277;
        Wed, 25 Jun 2025 07:55:45 -0700 (PDT)
Message-ID: 
Date: Wed, 25 Jun 2025 16:55:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 04/17] xen/riscv: construct the P2M pages pool for
 guests
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: 
 
 <3bbc8962-eaaa-4ed0-bc21-757bdc6be49d@suse.com>
 <3db6770c-005f-4123-bb85-0445b4d2d437@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: <3db6770c-005f-4123-bb85-0445b4d2d437@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 25.06.2025 16:48, Oleksii Kurochko wrote:
> 
> On 6/18/25 5:53 PM, Jan Beulich wrote:
>> On 10.06.2025 15:05, Oleksii Kurochko wrote:
>>> @@ -18,10 +20,20 @@ struct arch_vcpu_io {
>>>   struct arch_vcpu {
>>>   };
>>>   
>>> +struct paging_domain {
>>> +    spinlock_t lock;
>>> +    /* Free P2M pages from the pre-allocated P2M pool */
>>> +    struct page_list_head p2m_freelist;
>>> +    /* Number of pages from the pre-allocated P2M pool */
>>> +    unsigned long p2m_total_pages;
>>> +};
>>> +
>>>   struct arch_domain {
>>>       struct hvm_domain hvm;
>>>   
>>>       struct p2m_domain p2m;
>>> +
>>> +    struct paging_domain paging;
>> With the separate structures, do you have plans to implement e.g. shadow paging?
>> Or some other paging mode beyond the basic one based on the H extension?
> 
> No, there is no such plans.
> 
>>   If the
>> structures are to remain separate, may I suggest that you keep things properly
>> separated (no matter how e.g. Arm may have it) in terms of naming? I.e. no
>> single "p2m" inside struct paging_domain.
> 
> Arm doesn't implement shadow paging too (AFAIK) and probably this approach was
> copied from x86, and then to RISC-V.
> I thought that a reason for that was just to have two separate entities: one which
> covers page tables and which covers the full available guest memory.
> And if the only idea of that was to have shadow paging then I don't how it should
> be done better. As p2m code is based on Arm's, perhaps, it makes sense to have
> this stuff separated, so easier porting will be.
> 
>>> @@ -105,6 +106,9 @@ int p2m_init(struct domain *d)
>>>       struct p2m_domain *p2m = p2m_get_hostp2m(d);
>>>       int rc;
>>>   
>>> +    spin_lock_init(&d->arch.paging.lock);
>>> +    INIT_PAGE_LIST_HEAD(&d->arch.paging.p2m_freelist);
>> If you want p2m and paging to be separate, you will want to put these in a new
>> paging_init().
> 
> I am not really understand what is wrong to have it here, but likely it is because
> I don't really get an initial purpose of having p2m and paging separately.
> It seems like p2m and paging are connected between each other, so it is fine
> to init them together.

If you want to retain the separation, imo you want to follow what x86 has:
paging_domain_init() calling p2m_init(). And d->arch.paging.* would then
be initialized in paging_domain_init(), like x86 has it.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 15:01:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 15:01:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1025191.1400842 (Exim 4.92)
	(envelope-from )
	id 1uURce-0006S5-H3; Wed, 25 Jun 2025 15:01:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1025191.1400842; Wed, 25 Jun 2025 15:01: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 1uURce-0006Ry-Dw; Wed, 25 Jun 2025 15:01:12 +0000
Received: by outflank-mailman (input) for mailman id 1025191;
 Wed, 25 Jun 2025 15: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 1uURcc-0006Rs-Kt
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 15:01:10 +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 39e55371-51d5-11f0-a30f-13f23c93f187;
 Wed, 25 Jun 2025 17:01:09 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3a6cd1a6fecso1760583f8f.3
 for ; Wed, 25 Jun 2025 08:01:09 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a6e80ff461sm4976757f8f.67.2025.06.25.08.01.07
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 25 Jun 2025 08:01:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 39e55371-51d5-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750863668; x=1751468468; 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=lyHnyI4d1dHiQHo2ct9/+EepdKlaa/PFCwCjM+tAtHA=;
        b=UFa7bBY3RAVQ4pzM1/2qeLjgGOa8smUDQNVnSPOTkYzRzKi5pTtpZ/a+8cYkS/FsoY
         /pgkd5GjpBy7qUKZWjgPt3CvtwdArM5WtExng61bPcngOOpQ3GtXPeoWPm64YWg3WBvP
         mYLL2bzkPpMTrBUsQpoMlOth/W0ceRW/kFVxA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750863668; x=1751468468;
        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=lyHnyI4d1dHiQHo2ct9/+EepdKlaa/PFCwCjM+tAtHA=;
        b=iotwL/Lbt3SzytguvHpvmqI8f3FHK/eilLXBHlVkiAivXUDiDA88ehvC6O5FJcZmeO
         c+iye2wRARjAfQmVYXntcdv9iHyqQz9owwscSxYWCZlAzAHzgg/QDebiRSHNGe1LOsYU
         VXK3mjVZ47QokuwBAmTLtteCPs/Quku7FJv1D91n5Wu+Nx25DLA/ZBYBxhSDvNFAFmMj
         j4y+PT9M7WrBdrUFQ0BgUBaVsmiFu28JKq3tezsifwiwbxS8dbNhyVgZYhaad0qXxqH8
         jAOKi8UKWxwgq6nZ2DfHK296oxRpsuPBazaNfT1tVqZmSeBWmZn0TJ9Lx4NQP8Ed7U9X
         ysYg==
X-Gm-Message-State: AOJu0YwX4CBT2SbPMta4Nz1FJ+6H8SZAxOFUgm65hw20FixMKftU9ztY
	6PUdVZJnm7AnsZ3p4Lv4Pb+iQXIJvH1ihV73gClb9H/GU3SXnXKDrUhg3n3piBwZAa+dk5KwEf7
	OOmA7cxCDsw==
X-Gm-Gg: ASbGnct9w5nzp32CL114iHd4Br74iMYjBIMx5pxPVYAUnNulLMwL96XB8LuyIEXNnT8
	rvioIh0iWglmwJaFDuzkWliNCjgnaX/46ak13pNRRRhzHX4Tsnez0scQ5ya8vLOEYnwvbIJHw9a
	2+EUn5aJC46x9PaqrGYRroxgBOSvbS6VYVxIw7ASaf11b9QWA95NEdW51AnDuUxtL99eU0CH2zh
	lAaoYKqPbiuUItXPtgBImvFLmmeALlz/qnHMi7AWtskwvs6AQEwquNb3ITyiNl+dZx++0LpZ9wN
	PfszTFJ/Vc2GQA1+WqAhPiWuLCpoyjQumIeyAL840r8nlLNCiSVXUdXBOVYEOV5AGqVCYKyI4ja
	YjdEexi+DGTCy9wbXN73jA3V/eTG7BW04Q34=
X-Google-Smtp-Source: AGHT+IEmB1NAnfJhGeQ1oYtGB5BEC2vkgscHqdf6pso725m8DgTsRb6cLg5nVo0omltImBMbIRg5Cw==
X-Received: by 2002:a05:6000:2709:b0:3a4:fe9d:1b10 with SMTP id ffacd0b85a97d-3a6ed646c16mr2220102f8f.45.1750863667898;
        Wed, 25 Jun 2025 08:01:07 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH] x86/boot: Improve paging mode diagnostics in create_dom0()
Date: Wed, 25 Jun 2025 16:01:05 +0100
Message-Id: <20250625150105.402005-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

I was presented with this:

  (XEN) NX (Execute Disable) protection active
  (XEN) d0 has maximum 416 PIRQs
  (XEN)
  (XEN) ****************************************
  (XEN) Panic on CPU 0:
  (XEN) Error creating d0: -95
  (XEN) ****************************************

which is less than helpful.  It turns out to be the -EOPNOTSUPP from
shadow_domain_init().

The real bug here is create_dom0() unconditionally assuming the presence of
SHADOW_PAGING.  Rework it to panic() rather than choosing a dom0_cfg which is
guaranteed to fail.  This results in:

  (XEN) NX (Execute Disable) protection active
  (XEN)
  (XEN) ****************************************
  (XEN) Panic on CPU 0:
  (XEN) Neither HAP nor Shadow available for PVH domain
  (XEN) ****************************************

which is rather more helpful.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
---
 xen/arch/x86/setup.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index f32efa7c6045..24e4f5ac7f5d 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1033,9 +1033,12 @@ static struct domain *__init create_dom0(struct boot_info *bi)
 
     if ( opt_dom0_pvh )
     {
-        dom0_cfg.flags |= (XEN_DOMCTL_CDF_hvm |
-                           ((hvm_hap_supported() && !opt_dom0_shadow) ?
-                            XEN_DOMCTL_CDF_hap : 0));
+        dom0_cfg.flags |= XEN_DOMCTL_CDF_hvm;
+
+        if ( hvm_hap_supported() && !opt_dom0_shadow )
+            dom0_cfg.flags |= XEN_DOMCTL_CDF_hap;
+        else if ( !IS_ENABLED(CONFIG_SHADOW_PAGING) )
+            panic("Neither HAP nor Shadow available for PVH domain\n");
 
         dom0_cfg.arch.emulation_flags |=
             XEN_X86_EMU_LAPIC | XEN_X86_EMU_IOAPIC | XEN_X86_EMU_VPCI;

base-commit: cc7394164633e75fb61d52565f75271e0b7f1236
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Wed Jun 25 15:14:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 15:14:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1025215.1400851 (Exim 4.92)
	(envelope-from )
	id 1uURpN-0008Rh-Io; Wed, 25 Jun 2025 15:14:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1025215.1400851; Wed, 25 Jun 2025 15: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 1uURpN-0008Ra-G6; Wed, 25 Jun 2025 15:14:21 +0000
Received: by outflank-mailman (input) for mailman id 1025215;
 Wed, 25 Jun 2025 15: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 1uURpM-0008Q9-Fr
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 15:14:20 +0000
Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com
 [2607:f8b0:4864:20::42f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1093de12-51d7-11f0-a30f-13f23c93f187;
 Wed, 25 Jun 2025 17:14:19 +0200 (CEST)
Received: by mail-pf1-x42f.google.com with SMTP id
 d2e1a72fcca58-7426c44e014so34150b3a.3
 for ; Wed, 25 Jun 2025 08:14:19 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 41be03b00d2f7-b320ef71cf5sm8918135a12.77.2025.06.25.08.14.16
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 25 Jun 2025 08:14:17 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1093de12-51d7-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750864458; x=1751469258; 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=EhFoht+ZsIrNOntSfCCAOP4S5UhiAYMnhAPoQTjIBi8=;
        b=Er1OQwyUdCizAza5Bg/j6K5+4AG0MZSQsAnOiXUSWF0kZ4+1ph/gyg3L6wJDJiwmAI
         dDbWn45taqO+O9ofUlm++WDtit402XqUB5SRGscdQ7KSFlluwlAM4wWjkqa/UABXYWLL
         zK5cxSV07J7lDWkFDMUcocz8+OoQBawQbuR5o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750864458; x=1751469258;
        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=EhFoht+ZsIrNOntSfCCAOP4S5UhiAYMnhAPoQTjIBi8=;
        b=tnUZ8fdlYgTsiVwJFtVPvpr5AwCBoO0XyWIriQQNiggCObIBUeOfZtXzUFwUPKF7m1
         MVWVYzh33f8mlIYE1el5ipMcwqeXBPyIh3drU8l7mMtmpECnccM1IYTmGAh8K8z3TMLG
         UzaazNpExeTIpuoVwwFaxIDbgMPAx60adaFu1d1iclmu1lMBiY2YI3unNWyICLjt+lik
         PaMvmNZlL67en4AFXBoa0FZ15I3xE+js0RfY/s1c51y9XnLW5BFKwfrAkYrcIq8n/K9q
         XarfSIWn+aeKhVJ0eL82nlTcQW6fPI0Cr4rgatAJfUTP4/hYQOqvIohA9BcT8bqgM69Y
         fBvw==
X-Forwarded-Encrypted: i=1; AJvYcCWsyQgdb28i8/OwurQNzpHuyEtgfOyvcIE0myFCh3hkOR20I3cklcnnsQSMcnqqM6voH9XqxugiPhM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YytuPX76X+Hd7TWXiKrDwtLY4YiLvMgQSed+hyUb+2lffEf+4zs
	VhQtY5iKyFfxvlebiMD6YDDRuy5mFSuFj6TNZxbCAFhYvHxgyLgsfKGQTmhZq9uDQuY=
X-Gm-Gg: ASbGnctLjIm/ytEM5D7WhPFhhYBm2VqSPbWixGr1nsva364GWkUw+HXZUqnIjC4KGBW
	uhjThi4d7Hm3eGnQJ4/ThhOT6wkYTUpGIr1WcidPaajDh5bG6dHwMvvHxJxOvO7xVt6SH4npHYf
	ugUhb9d7BQvRrQH8lXUd2k4iZ24cSGw2DF6mOQiNJ2EQ68SXLHLUItCO3HK2CGiDQpdnjfXGoVw
	bAIp+tCpNF/1qmmjpw/YYhZ+sLqD/E0nptW9wmi1Eaj8LixmhS+LErUqpfKJjFp7P/xzcDPI8H4
	ExX6FlvmLzFfkPaVLYbc+ySm3RT9BRP0STQ31iyBRpvT5D/2TVUWTcGmSjPoeqUekrgIoI2ISl0
	qzNncLAnmMQpMxMhnl522/dBLikmstg==
X-Google-Smtp-Source: AGHT+IF9BzxdrwxNcQZxU0a9LJzENuHzYiLNvleTDUqVxQhnmx00tQ8+e4hf26rreoE0jbaFe354eg==
X-Received: by 2002:a05:6a20:e30b:b0:203:c461:dd36 with SMTP id adf61e73a8af0-2208c08a537mr371930637.6.1750864457947;
        Wed, 25 Jun 2025 08:14:17 -0700 (PDT)
Date: Wed, 25 Jun 2025 17:14:12 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 1/8] x86/pdx: simplify calculation of domain struct
 allocation boundary
Message-ID: 
References: <20250620111130.29057-1-roger.pau@citrix.com>
 <20250620111130.29057-2-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, Jun 24, 2025 at 03:05:11PM +0200, Jan Beulich wrote:
> On 20.06.2025 13:11, Roger Pau Monne wrote:
> > When not using CONFIG_BIGMEM there are some restrictions in the address
> > width for allocations of the domain structure, as it's PDX truncated to 32
> > bits it's stashed into page_info structure for domain allocated pages.
> > 
> > The current logic to calculate this limit is based on the internals of the
> > PDX compression used, which is not strictly required.  Instead simplify the
> > logic to rely on the existing PDX to PFN conversion helpers used elsewhere.
> > 
> > This has the added benefit of allowing alternative PDX compression
> > algorithms to be implemented without requiring to change the calculation of
> > the domain structure allocation boundary.
> > 
> > As a side effect introduce pdx_to_paddr() conversion macro and use it.
> > 
> > Signed-off-by: Roger Pau Monné 
> 
> Reviewed-by: Jan Beulich 

Thanks.

> > @@ -498,14 +474,20 @@ struct domain *alloc_domain_struct(void)
> >       * On systems with CONFIG_BIGMEM there's no packing, and so there's no
> >       * such restriction.
> >       */
> > -#if defined(CONFIG_BIGMEM) || !defined(CONFIG_PDX_COMPRESSION)
> > -    const unsigned int bits = IS_ENABLED(CONFIG_BIGMEM) ? 0 :
> > -                                                          32 + PAGE_SHIFT;
> > +#if defined(CONFIG_BIGMEM)
> > +    const unsigned int bits = 0;
> >  #else
> > -    static unsigned int __read_mostly bits;
> > +    static unsigned int __ro_after_init bits;
> >  
> >      if ( unlikely(!bits) )
> > -         bits = _domain_struct_bits();
> > +         /*
> > +          * Get the width for the next pfn, and unconditionally subtract one
> > +          * from it to ensure the used width will not allocate past the PDX
> > +          * field limit.
> > +          */
> > +         bits = flsl(pdx_to_paddr(1UL << (sizeof_field(struct page_info,
> > +                                                       v.inuse._domain) * 8)))
> 
> You didn't like the slightly shorter sizeof(frame_table->v.inuse._domain) then?

No strong opinion really, I have the impression however that using the
struct type itself would be less fragile, in case we ever change
frame_table variable name (which is very unlikely).

Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 15:31:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 15:31:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1025227.1400861 (Exim 4.92)
	(envelope-from )
	id 1uUS66-000378-1T; Wed, 25 Jun 2025 15:31:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1025227.1400861; Wed, 25 Jun 2025 15:31: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 1uUS65-000371-V9; Wed, 25 Jun 2025 15:31:37 +0000
Received: by outflank-mailman (input) for mailman id 1025227;
 Wed, 25 Jun 2025 15:31: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 1uUS64-00036v-Ob
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 15:31:36 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7539d12f-51d9-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 17:31:26 +0200 (CEST)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-60780d74c85so2721594a12.2
 for ; Wed, 25 Jun 2025 08:31:26 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-60c2f4a497dsm2636326a12.69.2025.06.25.08.31.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 25 Jun 2025 08:31:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7539d12f-51d9-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750865486; x=1751470286; 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=IK1rwYVWatbwXx37+p9OST/WtX06FQelroGhU5xtCAc=;
        b=PxxeKBRGLkcWKWc/Ld+EaBmVAcnVn1cNHPLpExNMFM8Cb+BIDBWsuooOX2vDDKn6S1
         tEcqYXOHlPjElDGImWbnbBLUFs7iF6CERPy5rtOiBmuKWLlnzLoF/RTze672cm2khNPO
         2qpYy8v13RmYehLD7OI4Iwx0Kw2TyQXla/kQTEONUAz+n9TqdQIMaisdj0sKTwG+x+sg
         TW1d+H/iC3XIhTA1yGrU5767BD0oDTN7eUTZmA49rGs4SHRTUQEIBNj2SRN8nUirx86Y
         8yFrcDFjQN3Iphu8Z8IY+p72L5l8UC1jT5umim7qxFAYoN6Laf5J6Ttc9wujazHatIZe
         yA2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750865486; x=1751470286;
        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=IK1rwYVWatbwXx37+p9OST/WtX06FQelroGhU5xtCAc=;
        b=r/wsLlXXHlsthVnaK+0YCDiB77ykYVIZt+rzp0U7xwXFaT/KqSn2ShwBUw/Toy2wtn
         /BQB3RAR2HdKWZin/cfqhUwRbzyqdJQYwO85XsBVGqjYmmFLhKG99aPCS/4rZTfAF7BE
         mZrHJ2tmRFCpdxA8QFBcETT21EOQcU4oWBPndZY+UieoJEhaTZj1MPwLHc9zAgxWCcBh
         u+JPS7mV2yxfshdWgM4FMPQV52ezmypZI3usDlslD1uXO6dGXtxFy9udARq5+VR4Cw6H
         YrfE0JBzhNg0aM6X81vBuLBiPgmoMQKoF52CfyH9PW6E1KB7pqeymNhJhJVO6OCwscbm
         wh5A==
X-Forwarded-Encrypted: i=1; AJvYcCU7bYUDYJqmn/rBABcrs4MqDAg/y21/pSv2M/wSvJ9SbNWHku3XyeK8OdBAezz3Yft2vaMnZ2QbnbU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzMd2UI3UipxTyNYH8THABNrbBCVbViq/PYp+/sNkkfNhJMXj9/
	oVszUVjmhWqmaT3v+KvqqJ1kpqTVMAk7KDTbEMfQREu3w1I0nIUSdwbg
X-Gm-Gg: ASbGncuXUdxjFiTGUqwfrn9VKvymAJnjLvILefREjalNs9b9vzoPfeqwIJlATpgIExa
	qXqrRkf/cmJu3xNPMmcmJPnMZ1FU0efFr9HWfnlImsziPVEh3p9Yv0BihTezjQscFjyNvK+GfAy
	p3z98F0YTON9rG98As6htr+STkLHcIj0SzCs36PN7TXpImIvJqt6lSNlcSwFVV9Uqm8k63pDstr
	QE243ZKL4JUXQAnMYhjUNjnV41nkNG/hkQpYSDe7Jo6htx0jkvPGekmeGB8SlBzIoEA31/9lLSY
	1eYzmuIPVPHDhEIrw5EEeyNwDbq/8LA9rvHceaNR2988QRoWtHFnPOIWdaE6w2D4NkizI5YvCir
	s3gqlYbPKPX5ci+ldTlrqqrSpaKVGyT7h8N+8JNn+peEOiQ==
X-Google-Smtp-Source: AGHT+IFLEhctetxyRGrgZoJVxxzyFeD5ZTOI/ltJVfwGU0WEHrqKHEQ1qChuTtSvR4F+ByErmUH+rw==
X-Received: by 2002:a05:6402:42d0:b0:60c:4bc0:453e with SMTP id 4fb4d7f45d1cf-60c4dc5250cmr2681685a12.2.1750865485711;
        Wed, 25 Jun 2025 08:31:25 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------eaK6LrHcXj0tDtk9P2XbyRiC"
Message-ID: <0b3c403b-0f24-4fc6-ba5b-fb4df62d7057@gmail.com>
Date: Wed, 25 Jun 2025 17:31:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 05/17] xen/riscv: introduce things necessary for p2m
 initialization
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: 
 <443cb3566a60dcb5d5440c72410ff6d76a010a58.1749555949.git.oleksii.kurochko@gmail.com>
 <5c61fd86-5c0e-481e-a5a9-6a53f2d78c36@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <5c61fd86-5c0e-481e-a5a9-6a53f2d78c36@suse.com>

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


On 6/18/25 6:08 PM, Jan Beulich wrote:
> On 10.06.2025 15:05, Oleksii Kurochko wrote:
>> Introduce the following things:
>> - Update p2m_domain structure, which describe per p2m-table state, with:
>>    - lock to protect updates to p2m.
>>    - pool with pages used to construct p2m.
>>    - clean_pte which indicate if it is requires to clean the cache when
>>      writing an entry.
>>    - radix tree to store p2m type as PTE doesn't have enough free bits to
>>      store type.
>>    - default_access to store p2m access type for each page in the domain.
>>    - back pointer to domain structure.
>> - p2m_init() to initalize members introduced in p2m_domain structure.
>> - Introudce p2m_write_lock() and p2m_is_write_locked().
> What about the reader variant? If you don't need that, why not use a simple
> spin lock?

It will be introduced later in "xen/riscv: add support of page lookup by GFN"
of this patch series where it is really used.

But I can move it here.

>
>> @@ -14,6 +18,29 @@
>>   
>>   /* Per-p2m-table state */
>>   struct p2m_domain {
>> +    /*
>> +     * Lock that protects updates to the p2m.
>> +     */
>> +    rwlock_t lock;
>> +
>> +    /* Pages used to construct the p2m */
>> +    struct page_list_head pages;
>> +
>> +    /* Indicate if it is required to clean the cache when writing an entry */
>> +    bool clean_pte;
>> +
>> +    struct radix_tree_root p2m_type;
> A field with a p2m_ prefix in a p2m struct?

p2m_ prefix could be really dropped.

>   And is this tree really about
> just a single "type"?

Yes, we don't have enough bits in PTE so we need some extra storage to store type.

>
>> +    /*
>> +     * Default P2M access type for each page in the the domain: new pages,
>> +     * swapped in pages, cleared pages, and pages that are ambiguously
>> +     * retyped get this access type.  See definition of p2m_access_t.
>> +     */
>> +    p2m_access_t default_access;
>> +
>> +    /* Back pointer to domain */
>> +    struct domain *domain;
> This you may want to introduce earlier, to prefer passing around struct
> p2m_domain * in / to P2M functions (which would benefit earlier patches
> already, I think).

But nothing uses it earlier.

>
>> --- a/xen/arch/riscv/p2m.c
>> +++ b/xen/arch/riscv/p2m.c
>> @@ -1,13 +1,46 @@
>>   #include 
>> +#include 
>>   #include 
>> +#include 
>>   #include 
>> +#include 
>> +#include 
>> +#include 
>>   #include 
>>   #include 
>>   #include 
>>   
>> +#include 
>>   #include 
>>   #include 
>>   
>> +/*
>> + * Force a synchronous P2M TLB flush.
>> + *
>> + * Must be called with the p2m lock held.
>> + */
>> +static void p2m_force_tlb_flush_sync(struct p2m_domain *p2m)
>> +{
>> +    struct domain *d = p2m->domain;
>> +
>> +    ASSERT(p2m_is_write_locked(p2m));
>> +
>> +    sbi_remote_hfence_gvma_vmid(d->dirty_cpumask, 0, 0, p2m->vmid);
>> +}
>> +
>> +/* Unlock the flush and do a P2M TLB flush if necessary */
>> +void p2m_write_unlock(struct p2m_domain *p2m)
>> +{
>> +    /*
>> +     * The final flush is done with the P2M write lock taken to avoid
>> +     * someone else modifying the P2M wbefore the TLB invalidation has
>> +     * completed.
>> +     */
>> +    p2m_force_tlb_flush_sync(p2m);
> The comment ahead of the function says "if necessary". Yet there's no
> conditional here. I also question the need for a global flush in all
> cases.

Stale comment.

But if p2m page table was modified that it is needed to do a flush for CPUs
in d->dirty_cpumask.

>
>> @@ -109,8 +142,33 @@ int p2m_init(struct domain *d)
>>       spin_lock_init(&d->arch.paging.lock);
>>       INIT_PAGE_LIST_HEAD(&d->arch.paging.p2m_freelist);
>>   
>> +    rwlock_init(&p2m->lock);
>> +    INIT_PAGE_LIST_HEAD(&p2m->pages);
>> +
>>       p2m->vmid = INVALID_VMID;
>>   
>> +    p2m->default_access = p2m_access_rwx;
>> +
>> +    radix_tree_init(&p2m->p2m_type);
>> +
>> +#ifdef CONFIG_HAS_PASSTHROUGH
> Do you expect this to be conditionally selected on RISC-V?

No, once it will be implemented it will be just selected once by config RISC-V.
And it was done so because iommu_has_feature() isn't implemented now as IOMMU
isn't supported now and depends on CONFIG_HAS_PASSTHROUGH.

>
>> +    /*
>> +     * Some IOMMUs don't support coherent PT walk. When the p2m is
>> +     * shared with the CPU, Xen has to make sure that the PT changes have
>> +     * reached the memory
>> +     */
>> +    p2m->clean_pte = is_iommu_enabled(d) &&
>> +        !iommu_has_feature(d, IOMMU_FEAT_COHERENT_WALK);
> The comment talks about shared page tables, yet you don't check whether
> page table sharing is actually enabled for the domain.

Do we have such function/macros? It is shared by implementation now.

>
>> +#else
>> +    p2m->clean_pte = false;
> I hope the struct starts out zero-filled, in which case you wouldn't need
> this.
>
>> +#endif
>> +
>> +    /*
>> +     * "Trivial" initialisation is now complete.  Set the backpointer so the
>> +     * users of p2m could get an access to domain structure.
>> +     */
>> +    p2m->domain = d;
> Better set this about the very first thing?

It makes sense. I will move it up.

Thanks.

~ Oleksii


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



  
    
  
  
    

    
    
    
    
    On 6/18/25 6:08 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 10.06.2025 15:05, Oleksii Kurochko wrote:

    
      
    
        
    Introduce the following things:
- Update p2m_domain structure, which describe per p2m-table state, with:
  - lock to protect updates to p2m.
  - pool with pages used to construct p2m.
  - clean_pte which indicate if it is requires to clean the cache when
    writing an entry.
  - radix tree to store p2m type as PTE doesn't have enough free bits to
    store type.
  - default_access to store p2m access type for each page in the domain.
  - back pointer to domain structure.
- p2m_init() to initalize members introduced in p2m_domain structure.
- Introudce p2m_write_lock() and p2m_is_write_locked().

    
      
    
      
    What about the reader variant? If you don't need that, why not use a simple
spin lock?
    
    
    
    
    It will be introduced later in "xen/riscv: add support of page lookup by GFN"
of this patch series where it is really used.

But I can move it here.


    
    
    
      
    

    
      
    
        
    @@ -14,6 +18,29 @@
 
 /* Per-p2m-table state */
 struct p2m_domain {
+    /*
+     * Lock that protects updates to the p2m.
+     */
+    rwlock_t lock;
+
+    /* Pages used to construct the p2m */
+    struct page_list_head pages;
+
+    /* Indicate if it is required to clean the cache when writing an entry */
+    bool clean_pte;
+
+    struct radix_tree_root p2m_type;

    
      
    
      
    A field with a p2m_ prefix in a p2m struct?
    
    
    
    
    p2m_ prefix could be really dropped.
    
    
    
      
     And is this tree really about
just a single "type"?
    
    
    
    
    Yes, we don't have enough bits in PTE so we need some extra storage to store type.


    
    
    
      
    

    
      
    
        
    +    /*
+     * Default P2M access type for each page in the the domain: new pages,
+     * swapped in pages, cleared pages, and pages that are ambiguously
+     * retyped get this access type.  See definition of p2m_access_t.
+     */
+    p2m_access_t default_access;
+
+    /* Back pointer to domain */
+    struct domain *domain;

    
      
    
      
    This you may want to introduce earlier, to prefer passing around struct
p2m_domain * in / to P2M functions (which would benefit earlier patches
already, I think).
    
    
    
    
    But nothing uses it earlier.


    
    
    
      
    

    
      
    
        
    --- a/xen/arch/riscv/p2m.c
+++ b/xen/arch/riscv/p2m.c
@@ -1,13 +1,46 @@
 #include <xen/bitops.h>
+#include <xen/domain_page.h>
 #include <xen/event.h>
+#include <xen/iommu.h>
 #include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/pfn.h>
+#include <xen/rwlock.h>
 #include <xen/sched.h>
 #include <xen/spinlock.h>
 #include <xen/xvmalloc.h>
 
+#include <asm/page.h>
 #include <asm/p2m.h>
 #include <asm/sbi.h>
 
+/*
+ * Force a synchronous P2M TLB flush.
+ *
+ * Must be called with the p2m lock held.
+ */
+static void p2m_force_tlb_flush_sync(struct p2m_domain *p2m)
+{
+    struct domain *d = p2m->domain;
+
+    ASSERT(p2m_is_write_locked(p2m));
+
+    sbi_remote_hfence_gvma_vmid(d->dirty_cpumask, 0, 0, p2m->vmid);
+}
+
+/* Unlock the flush and do a P2M TLB flush if necessary */
+void p2m_write_unlock(struct p2m_domain *p2m)
+{
+    /*
+     * The final flush is done with the P2M write lock taken to avoid
+     * someone else modifying the P2M wbefore the TLB invalidation has
+     * completed.
+     */
+    p2m_force_tlb_flush_sync(p2m);

    
      
    
      
    The comment ahead of the function says "if necessary". Yet there's no
conditional here. I also question the need for a global flush in all
cases.
    
    
    
    
    Stale comment.

But if p2m page table was modified that it is needed to do a flush for CPUs
in d->dirty_cpumask.


    
    
    
      
    

    
      
    
        
    @@ -109,8 +142,33 @@ int p2m_init(struct domain *d)
     spin_lock_init(&d->arch.paging.lock);
     INIT_PAGE_LIST_HEAD(&d->arch.paging.p2m_freelist);
 
+    rwlock_init(&p2m->lock);
+    INIT_PAGE_LIST_HEAD(&p2m->pages);
+
     p2m->vmid = INVALID_VMID;
 
+    p2m->default_access = p2m_access_rwx;
+
+    radix_tree_init(&p2m->p2m_type);
+
+#ifdef CONFIG_HAS_PASSTHROUGH

    
      
    
      
    Do you expect this to be conditionally selected on RISC-V?
    
    
    
    
    No, once it will be implemented it will be just selected once by config RISC-V.
And it was done so because iommu_has_feature() isn't implemented now as IOMMU
isn't supported now and depends on CONFIG_HAS_PASSTHROUGH.
    
    
    
      
    

    
      
    
        
    +    /*
+     * Some IOMMUs don't support coherent PT walk. When the p2m is
+     * shared with the CPU, Xen has to make sure that the PT changes have
+     * reached the memory
+     */
+    p2m->clean_pte = is_iommu_enabled(d) &&
+        !iommu_has_feature(d, IOMMU_FEAT_COHERENT_WALK);

    
      
    
      
    The comment talks about shared page tables, yet you don't check whether
page table sharing is actually enabled for the domain.
    
    
    
    
    Do we have such function/macros? It is shared by implementation now.


    
    
    
      
    

    
      
    
        
    +#else
+    p2m->clean_pte = false;

    
      
    
      
    I hope the struct starts out zero-filled, in which case you wouldn't need
this.


    
      
    
        
    +#endif
+
+    /*
+     * "Trivial" initialisation is now complete.  Set the backpointer so the
+     * users of p2m could get an access to domain structure.
+     */
+    p2m->domain = d;

    
      
    
      
    Better set this about the very first thing?
    
    
    
    
    It makes sense. I will move it up.

Thanks.

~ Oleksii
    
    
    
  


--------------eaK6LrHcXj0tDtk9P2XbyRiC--


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 15:32:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 15:32:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1025234.1400871 (Exim 4.92)
	(envelope-from )
	id 1uUS7I-0003cM-BF; Wed, 25 Jun 2025 15:32:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1025234.1400871; Wed, 25 Jun 2025 15:32: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 1uUS7I-0003cF-8a; Wed, 25 Jun 2025 15:32:52 +0000
Received: by outflank-mailman (input) for mailman id 1025234;
 Wed, 25 Jun 2025 15:32: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 1uUS7G-0003c5-Vp
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 15:32:51 +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 a46a1037-51d9-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 17:32:45 +0200 (CEST)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-450dd065828so15302515e9.2
 for ; Wed, 25 Jun 2025 08:32:45 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-45382363167sm24059015e9.26.2025.06.25.08.32.44
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 25 Jun 2025 08:32:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a46a1037-51d9-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750865565; x=1751470365; 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=8CUztxAY5fNunNcET+EhgY1/3CWzr9FgKMwyyZ6dFd4=;
        b=wMS/7urydesBQNu5AEZP+Fq1YpjNLmfJjrD28K53hK8m9ipLcyMA0i1XGkLcsL73cl
         +f2/3YJSND6cozmDbzM1zF52vzkVcg1l1GleWnxByqPYg4Z2hOu7yai7BbbMJa4fZ4M7
         zc9cTy2+nNuTNN4VVeRAu5qom6JNJh1EtteV8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750865565; x=1751470365;
        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=8CUztxAY5fNunNcET+EhgY1/3CWzr9FgKMwyyZ6dFd4=;
        b=CD/o9juXrpp3LMXk2tvuP4UOmhig3BQufaHIP5OhhmpD31N6hnLo8hIX7fT0o6aEe+
         6cM9nwWl/1vAl/0BvtdGdXPlYSM0slgMztjgwB+7X8hJJ27Pecb9CM48N2u5s2cSDCGg
         kr3XgOxVZ/VslEDiP5Z52S5R7I8rhZnuo0lmHCpLFecEg9nEnSRsPSCDaSXwxyXBF82r
         MKrkC6gXS9O9rnPvZSpnbweX8uUZSP0PTDcmpVzWeO3MkJQLl8bRLkTKyJr0f7oXxlV/
         QxQaN0zXG1L54vzC6OuYKOdSbqv4AmBdKfPyl0mLN5UhKu2uwtddkyubhOgfKgfsMv4Q
         y4Nw==
X-Forwarded-Encrypted: i=1; AJvYcCUZogDnhbRdn2KU8n4x+C7Dw15TPyIwwGhoDzfrDO9/dNwsmXTqGpIbfv7H1kQCynTBkjVm1mYU51U=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyRHRH+HLs0FXBTPU2jFGLDr1ZyASNsyHlGFFtuZJ3RYdjP9DQs
	iHt38FSeo1fD+ExIpWgYYl+9kp/B7GST8FdIJafNPrSJInWtBkObidL19bLreacaA2E=
X-Gm-Gg: ASbGncvgVHg+Yz45HmLEC6tyjE+hav3XFBvyIkZuaKyayPkvVN7PppBTcWWgqWH9Yhp
	lKDQRkhzXLX4Y/K4XVietGOLmByxivYcPn5Trr1AuHhtIcojWW9VhD/uBPCyFTdOI0cp2hJI2np
	A9WqCEUwV+Td1Q+2E3i05b9ZVgk3p169PTRP1Ia3UpPvPWrwEy8px6z/Qu/pEwSozaSEuVnkzeN
	5hHnosFQPiVByUvdPVVyUSOxb0oOMHWlC8JMYfvR1kwQA/xOJA1Txo2PnBPQWT6u23c019hi4B8
	xwCGRyFsreAVIc6fS29qjQLpuBtaqZR6NDElETVA1FAJZfilZnvBnCsTQG3eoaYFtTqLZLQG7xH
	ucaH3Bki3Haob6LjCBKrbAWjJSj9+6g==
X-Google-Smtp-Source: AGHT+IEHujfIZsEM+oVocdW+wdXeDwzBjrn4Q6uj1SwlWXG14TFuwvFLiM6C6g18XILKDy1cUThPKA==
X-Received: by 2002:a05:600c:c4aa:b0:43c:fd27:a216 with SMTP id 5b1f17b1804b1-45381afd69bmr34069835e9.23.1750865565100;
        Wed, 25 Jun 2025 08:32:45 -0700 (PDT)
Date: Wed, 25 Jun 2025 17:32:43 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Andrew Cooper ,
	Anthony PERARD ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 3/8] pdx: provide a unified set of unit functions
Message-ID: 
References: <20250620111130.29057-1-roger.pau@citrix.com>
 <20250620111130.29057-4-roger.pau@citrix.com>
 <1298a33e-b602-4887-86a7-cb69cdaa6311@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <1298a33e-b602-4887-86a7-cb69cdaa6311@suse.com>

On Tue, Jun 24, 2025 at 03:32:23PM +0200, Jan Beulich wrote:
> On 20.06.2025 13:11, Roger Pau Monne wrote:
> > --- a/xen/arch/arm/setup.c
> > +++ b/xen/arch/arm/setup.c
> > @@ -255,6 +255,10 @@ void __init init_pdx(void)
> >  {
> >      const struct membanks *mem = bootinfo_get_mem();
> >      paddr_t bank_start, bank_size, bank_end;
> > +    unsigned int bank;
> > +
> > +    for ( bank = 0 ; bank < mem->nr_banks; bank++ )
> > +        pfn_pdx_add_region(mem->bank[bank].start, mem->bank[bank].size);
> >  
> >      /*
> >       * Arm does not have any restrictions on the bits to compress. Pass 0 to
> > @@ -263,28 +267,24 @@ void __init init_pdx(void)
> >       * If the logic changes in pfn_pdx_hole_setup we might have to
> >       * update this function too.
> >       */
> > -    uint64_t mask = pdx_init_mask(0x0);
> > -    int bank;
> > +    pfn_pdx_compression_setup(0);
> >  
> >      for ( bank = 0 ; bank < mem->nr_banks; bank++ )
> >      {
> > -        bank_start = mem->bank[bank].start;
> > -        bank_size = mem->bank[bank].size;
> > -
> > -        mask |= bank_start | pdx_region_mask(bank_start, bank_size);
> > -    }
> > -
> > -    for ( bank = 0 ; bank < mem->nr_banks; bank++ )
> > -    {
> > -        bank_start = mem->bank[bank].start;
> > -        bank_size = mem->bank[bank].size;
> > -
> > -        if (~mask & pdx_region_mask(bank_start, bank_size))
> > -            mask = 0;
> > +        if ( !pdx_is_region_compressible(mem->bank[bank].start,
> > +                 PFN_UP(mem->bank[bank].start + mem->bank[bank].size) -
> > +                 PFN_DOWN(mem->bank[bank].start)) )
> 
> Nit: This, according to my understanding, is an "impossible" style. It wants
> to either be
> 
>         if ( !pdx_is_region_compressible(
>                   mem->bank[bank].start,
>                   PFN_UP(mem->bank[bank].start + mem->bank[bank].size) -
>                   PFN_DOWN(mem->bank[bank].start)) )
> 
> or ...

I will switch to the example above, thanks.

> > +        {
> > +            pfn_pdx_compression_reset();
> > +            printk(XENLOG_WARNING
> > +                   "PFN compression disabled, RAM region [%#" PRIpaddr ", %#"
> > +                   PRIpaddr "] not covered\n",
> > +                   mem->bank[bank].start,
> > +                   mem->bank[bank].start + mem->bank[bank].size - 1);
> 
> ... like this. But it's not written down anywhere, so I guess I shouldn't
> insist.
> 
> And then - isn't the use of PFN_UP() and PFN_DOWN() the wrong way round?
> Partial pages aren't usable anyway, so the smaller range is what matters
> for every individual bank. However, for two contiguous banks (no idea
> whether Arm would fold such into a single one, like we do with same-type
> E820 regions on x86) this gets more complicated then.

I think it's safer to always attempt to cover the wider range, even if
the first and last pages are not fully covered, and shouldn't be used
as RAM.  Like you said it will get more complicated if ranges are
contiguous but the start and end are not page aligned.

> > @@ -299,19 +295,29 @@ void __init srat_parse_regions(paddr_t addr)
> >  
> >  	/* Set "PXM" as early as feasible. */
> >  	numa_fw_nid_name = "PXM";
> > -	srat_region_mask = pdx_init_mask(addr);
> >  	acpi_table_parse_srat(ACPI_SRAT_TYPE_MEMORY_AFFINITY,
> >  			      srat_parse_region, 0);
> >  
> > -	for (mask = srat_region_mask, i = 0; mask && i < e820.nr_map; i++) {
> > +	pfn_pdx_compression_setup(addr);
> > +
> > +	/* Ensure all RAM ranges in the e820 are covered. */
> > +	for (i = 0; i < e820.nr_map; i++) {
> >  		if (e820.map[i].type != E820_RAM)
> >  			continue;
> >  
> > -		if (~mask & pdx_region_mask(e820.map[i].addr, e820.map[i].size))
> > -			mask = 0;
> > +		if (!pdx_is_region_compressible(e820.map[i].addr,
> > +		    PFN_UP(e820.map[i].addr + e820.map[i].size) -
> > +		    PFN_DOWN(e820.map[i].addr)))
> 
> Indentation is off here in any event, i.e. irrespective of my earlier
> remark.

Hm, yes, I've made a mess with indentation here.

> 
> > --- a/xen/common/pdx.c
> > +++ b/xen/common/pdx.c
> > @@ -19,6 +19,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  
> >  /**
> > @@ -55,6 +56,44 @@ void set_pdx_range(unsigned long smfn, unsigned long emfn)
> >          __set_bit(idx, pdx_group_valid);
> >  }
> >  
> > +#ifndef CONFIG_PDX_NONE
> > +
> > +#ifdef CONFIG_X86
> > +# include 
> > +# define MAX_PFN_RANGES E820MAX
> > +#elif defined(CONFIG_HAS_DEVICE_TREE)
> > +# include 
> > +# define MAX_PFN_RANGES NR_MEM_BANKS
> > +#endif
> > +
> > +#ifndef MAX_PFN_RANGES
> > +# error "Missing architecture maximum number of RAM ranges"
> > +#endif
> > +
> > +/* Generic PFN compression helpers. */
> > +static struct pfn_range {
> > +    unsigned long base, size;
> > +} ranges[MAX_PFN_RANGES] __initdata;
> > +static unsigned int __initdata nr_ranges;
> > +
> > +void __init pfn_pdx_add_region(paddr_t base, paddr_t size)
> > +{
> > +    if ( !size )
> > +        return;
> > +
> > +    if ( nr_ranges >= ARRAY_SIZE(ranges) )
> > +    {
> > +        ASSERT((nr_ranges + 1) > nr_ranges);
> 
> This looks overly pessimistic to me. (I won't outright insist on its removal,
> though.)

TBH I've added this later, I don't have a strong opinion either.  I
don't think we usually check for overflows, so I understand this might
look odd.

> > +        nr_ranges++;
> 
> This requires pretty careful use of the variable as an upper bound of loops.
> It's fine in pfn_pdx_compression_setup(), but it feels a little risky.

It does require careful handling in pfn_pdx_compression_setup(), but
also has the benefit of providing the possibly new required upper
bound for PDX to be usable in the error message.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 15:46:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 15:46:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1025261.1400881 (Exim 4.92)
	(envelope-from )
	id 1uUSKg-0005pi-GY; Wed, 25 Jun 2025 15:46:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1025261.1400881; Wed, 25 Jun 2025 15:46: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 1uUSKg-0005pb-Dg; Wed, 25 Jun 2025 15:46:42 +0000
Received: by outflank-mailman (input) for mailman id 1025261;
 Wed, 25 Jun 2025 15:46: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 1uUSKf-0005pV-1q
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 15:46:41 +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 9511c2c2-51db-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 17:46:39 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a57ae5cb17so3836191f8f.0
 for ; Wed, 25 Jun 2025 08:46:39 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a6e805d1e2sm4899093f8f.24.2025.06.25.08.46.37
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 25 Jun 2025 08:46:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9511c2c2-51db-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750866398; x=1751471198; 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=0LojgLOCtW02dabTp+YFhUX08RNdTWTM2YGGvpuBMsg=;
        b=BNU8/zFsV7By3U2mWhPmAQdlMqmatRPuPxSASwrTFIyocS40vxCab3SS8+NPARkqkj
         166L+Wn3hGXO6hHbsG04Rj8+WasOzr5XIEgNfol+6/POPU8ZgcCS9k0q0KKLmeHH2Yun
         puXF9XD9jeWbqtXpqSekxVBMbx5HYRjR+o+9U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750866398; x=1751471198;
        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=0LojgLOCtW02dabTp+YFhUX08RNdTWTM2YGGvpuBMsg=;
        b=Pt3ltWytwZpXZLPpgiHxW04bdcfPK1PhUzogYprxayONppRYcBn2cLumZCDDP7iJCy
         E4LB+YhfXuv/ZI4JA4D/SZWv+zl3b3BYr2EEUye0feR4cBub1OSTFT6MdIMQuz+a9ZNN
         R5oyCTQCyIuNzWyWFRKc2dTCQODTuggq8A3aJAxi506MeIbgRoc01AI6KS2q9qSgCKIL
         qz576tYur1BdGLe8IJcvlUWkkXD/4Autd8BuUKRVeGbSPf4w3FK9gS8nUxEtmYIWMO6d
         B+buagr0E7fOMIJ62FpDQWaB/Wo9oIf9uPQjQnZsMpa+DLmEiwsdtxbQkwhKMK560tFN
         n4NQ==
X-Forwarded-Encrypted: i=1; AJvYcCX8Ey9Tw+FgKrv+1l8wVKpoj7WrAVydNdT4OkKGj8OrsgrJgOqVn7SEzzRMPhxx4HABjGiDmuCqazU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwL6jLWC2Y2vPglsIN4fkSUZ3cceACdeOnUWP3RgxJnDnTg6lsB
	kAXsVFRk0qdtte93I+3SRYzWfpQnMJjVfhWLsKVF4gymYfJF7HNdkdb1vLdJTd1VNdk=
X-Gm-Gg: ASbGncszbrJrifQu7636Pd2/kRweJwnLx19JE6UQ97nXUVzECNz6mpZz7h/DayEs90f
	6G5o86ERsFMJjXcAl2mQDsNMLM6b7llkhf4nnEwEtEkQE7gYJi9WlnTZ67KjiSrwKKYH02zRBjE
	w66d98dtg8M0VNqrY8pcGCZ2QnhbSYkSiU22hGItv5NUih0+xrAPjbZI847DvgNAGjltpGfu2Ht
	ZlzefqGgg8K8X6YsDlqN4gjR1NjSFDo0LgDjmQGYisHgp/HuAZ/6USixQPYWnTxXvXLi+nLeL40
	RyElNCM0DrVfK12BvGcTOHy77BI0zkQoMV2F5bawxxgFeJeC7jozkYiX8eRmdBBVFCZ/VdRhP6l
	2jzKgAtd7I1Euw4jaI8ndWF+Jw/byhw==
X-Google-Smtp-Source: AGHT+IEaBje4n4tW3pprxvp31ACccblpyQwMt4pKIXwM5W+3kLDRM7hnt4DoqIiRPWBIazp78/ydjQ==
X-Received: by 2002:a05:6000:2287:b0:3a5:27ba:47a8 with SMTP id ffacd0b85a97d-3a6ed65d23amr2936984f8f.52.1750866398437;
        Wed, 25 Jun 2025 08:46:38 -0700 (PDT)
Date: Wed, 25 Jun 2025 17:46:37 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Stefano Stabellini ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 4/8] pdx: introduce command line compression toggle
Message-ID: 
References: <20250620111130.29057-1-roger.pau@citrix.com>
 <20250620111130.29057-5-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, Jun 24, 2025 at 03:40:16PM +0200, Jan Beulich wrote:
> On 20.06.2025 13:11, Roger Pau Monne wrote:
> > Introduce a command line option to allow disabling PDX compression.  The
> > disabling is done by turning pfn_pdx_add_region() into a no-op, so when
> > attempting to initialize the selected compression algorithm the array of
> > ranges to compress is empty.
> 
> While neat, this also feels fragile. It's not obvious that for any
> algorithm pfn_pdx_compression_setup() would leave compression disabled
> when there are zero ranges. In principle, if it was written differently
> for mask compression, there being no ranges could result in compression
> simply squeezing out all of the address bits. Yet as long as we think
> we're going to keep this in mind ...

It seemed to me that nr_rages == 0 (so no ranges reported) should
result in no compression, for example on x86 this means there's no
SRAT.

> > Signed-off-by: Roger Pau Monné 
> 
> Reviewed-by: Jan Beulich 

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 15:51:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 15:51:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1025272.1400892 (Exim 4.92)
	(envelope-from )
	id 1uUSPe-0007OE-8o; Wed, 25 Jun 2025 15:51:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1025272.1400892; Wed, 25 Jun 2025 15:51: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 1uUSPe-0007O7-4T; Wed, 25 Jun 2025 15:51:50 +0000
Received: by outflank-mailman (input) for mailman id 1025272;
 Wed, 25 Jun 2025 15:51: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 1uUSPd-0007O1-51
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 15:51:49 +0000
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com
 [2a00:1450:4864:20::42d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4d65854a-51dc-11f0-a30f-13f23c93f187;
 Wed, 25 Jun 2025 17:51:48 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3a548a73ff2so1737584f8f.0
 for ; Wed, 25 Jun 2025 08:51:48 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a6e80f26ebsm4973115f8f.51.2025.06.25.08.51.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 25 Jun 2025 08:51:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4d65854a-51dc-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750866708; x=1751471508; 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=b8dagTzTb5fekUVgpHboAFaIDntps4PnWDcZvFV1Gtk=;
        b=vKvZVnu1m59ePjC0z9HJ1ghwujPVWJuOi6heQJsymk885Wnh4vTKdOK8YA6Ku9TmMP
         tIz+9RZs+nRKUdmPiSeQbtixKiD/IniAv3P9RaQ2Qse3yOIyCQrd64ak7i30XnrzRBjl
         OMyn5MJNAnIbEh6saTVQrkr9iOsWBjNeG/XdA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750866708; x=1751471508;
        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=b8dagTzTb5fekUVgpHboAFaIDntps4PnWDcZvFV1Gtk=;
        b=G9nF+uxnzT0cOV8e6P/dDl7YKfh+7I/SXWqLHqkq3yVt5foRpizGval1YXQh5T1PJT
         OzfpopD7msbeFogpkKZsgjIl66v39SD/q24lk9U/2WE9j9Jk/dPNhzVn3aa6qzEkT4Vk
         goRVuiNDmmCLh+2IwSM+A/wzJQZDTp2Wb+sJFlRHdv5khgBnFDrNTGgY/JAJc1SgyA1v
         guBqsHPoC/4domsvJPCG07whMLGT18AG/gSfqxhjoXMYB67rKXgTkXAAGcPLo/KqXonG
         l/CY/x3Km/BGSdrdaMDHIYOQ0g1tU8Nmpp7Bl3iZeQjeDCmnpqH1ZL73scyiIRNkoSbU
         ll6g==
X-Forwarded-Encrypted: i=1; AJvYcCXaIwXDNCpmSlo7TQKzI5jL9RjwZA1EB3n2ArZ852YfX/TcE6XiKxeQHcL1bf7tkjDq63N9CBnvMDg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyqt9muF80DMmJapRevnu0B2HYapvXS0V+HxPakVcwMt4cbh7mi
	KrQR/tGpeYtS5w/tKrr9F6anTzuDL0EFjTZ5bfj28FohnE6A4BHt9C5Nzqoz8GLCJsA=
X-Gm-Gg: ASbGncs1f1x9jjvagzMlAjkEvNuW7Ri10lo8zGNWXn956gQVJWnL+Md8JrV5nPWQme4
	7dF3allHxNF3rZ8MgTu3SwKAzKzP8Ly+GjW2EWPQ/9Lc/JtaOsFGi1QU/1hupC0SlbUeLAiQTxx
	TMFiyrMm7Cy6/J3GgW3doP236csMhQyM9OPmESLfNvB8991THKjAU6B2WG69Ua/JRM3GjV38dsS
	yPv7+UITp64Loaa4NHoDcw/mhz5IyiFdEHsZ9CRpTaOx+//Ma/VRcD0BBhgZdl7TSCqiM2S7qS9
	EmJX/uBxQTYLWwlvp5I3vsubxvv3AsTKIoTdSsRhQ30CERAJM5Mm2jaRfP6iWMpI9OIAF4qZ+sp
	+0br8UrfWrHg8h13yTrgoQjkCnMotvA==
X-Google-Smtp-Source: AGHT+IGxhiusxpzUMBPK8NRg5KEQzm+jCEHGoI9IDCbOgQKDcxpuQGaXbajWYANYgZVvY9jZlSnSig==
X-Received: by 2002:a05:6000:2dc7:b0:39f:175b:a68d with SMTP id ffacd0b85a97d-3a6ed5b8c1fmr2971086f8f.11.1750866707647;
        Wed, 25 Jun 2025 08:51:47 -0700 (PDT)
Date: Wed, 25 Jun 2025 17:51:46 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Andrew Cooper ,
	Anthony PERARD ,
	Shawn Anastasio ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Oleksii Kurochko ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 5/8] pdx: allow per-arch optimization of PDX
 conversion helpers
Message-ID: 
References: <20250620111130.29057-1-roger.pau@citrix.com>
 <20250620111130.29057-6-roger.pau@citrix.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 

On Tue, Jun 24, 2025 at 03:51:09PM +0200, Jan Beulich wrote:
> On 20.06.2025 13:11, Roger Pau Monne wrote:
> > --- /dev/null
> > +++ b/xen/arch/x86/include/asm/pdx.h
> > @@ -0,0 +1,75 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +
> > +#ifndef X86_PDX_H
> > +#define X86_PDX_H
> > +
> > +#ifndef CONFIG_PDX_NONE
> > +
> > +#include 
> > +
> > +/*
> > + * Introduce a macro to avoid repeating the same asm goto block in each helper.
> > + * Note the macro is strictly tied to the code in the helpers.
> > + */
> > +#define PDX_ASM_GOTO_SKIP                           \
> > +    asm_inline goto (                               \
> > +        ALTERNATIVE(                                \
> > +            "",                                     \
> > +            "jmp %l[skip]",                         \
> > +            ALT_NOT(X86_FEATURE_PDX_COMPRESSION))   \
> > +        : : : : skip )
> 
> Did you consider passing the label name as argument to the macro? That way ...
> 
> > +static inline unsigned long pfn_to_pdx(unsigned long pfn)
> > +{
> > +    PDX_ASM_GOTO_SKIP;
> > +
> > +    return pfn_to_pdx_xlate(pfn);
> > +
> > + skip:
> > +    return pfn;
> > +}
> 
> ... the labels here and below then wouldn't look unused.

Yes - that's why I've added the "Note the macro is strictly tied to
the code in the helpers" comment ahead of the macro, and named it as
"GOTO_SKIP" to explicitly reference the label name.  I could pass the
label name however if that's preferred, ie: PDX_ASM_GOTO(skip).  IMO
It seems a bit redundant since all callers will pass the same label
name.

> The other slight anomaly with this is that we're wasting 2 or 5 bytes of
> code space. Yet I guess that's an acceptable price to pay for keeping the
> actual translation code in C (rather than in assembly).

I wanted to avoid doing the translation in assembly, so I think it's a
fair price to pay.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 15:54:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 15:54:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1025279.1400902 (Exim 4.92)
	(envelope-from )
	id 1uUSRi-00089O-IQ; Wed, 25 Jun 2025 15:53:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1025279.1400902; Wed, 25 Jun 2025 15:53: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 1uUSRi-00089H-Fd; Wed, 25 Jun 2025 15:53:58 +0000
Received: by outflank-mailman (input) for mailman id 1025279;
 Wed, 25 Jun 2025 15:53:58 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uUSRh-00089B-V8
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 15:53:57 +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 9a0bdbd2-51dc-11f0-a30f-13f23c93f187;
 Wed, 25 Jun 2025 17:53:56 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a6f2c6715fso223929f8f.1
 for ; Wed, 25 Jun 2025 08:53:56 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-749c8850c7asm4773267b3a.115.2025.06.25.08.53.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 25 Jun 2025 08:53:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9a0bdbd2-51dc-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750866836; x=1751471636; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=BYRAvkXBUYWPLM/wm4erVKztHhnVAhzz8icM464Xgkc=;
        b=Bu0qpJ51+8pAeiXlpxqXsN+KxlPSyT+QN9IQOt254j4SG9U8U9DI3Xy5Y4MXjoOVeA
         CczyCMCx9UtL/ZrGVzGTjCAzaOdoclfDMoJWpJX9tB1EiVrWXW5irH1cHRhdwSJn1mOb
         PiNfa4kMKQyeoP1mFAkx4dNdGskyE+7qaIFQuXGc2u8A6mVZLlEIp7kkdmXPL8suvTDx
         jO2dUAfoqXI/M4o1hISIj69tF49vFVxGCYICqn7hW5npUNoQZbmuKkwpC0XIU63Z2J1X
         GghIaghNY8Il/nzhphQXhHmq08ZBQU70iytS3JGUrpZT/08H5EEbXyzkNjQPMJDtfbLh
         utbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750866836; x=1751471636;
        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=BYRAvkXBUYWPLM/wm4erVKztHhnVAhzz8icM464Xgkc=;
        b=f4ouErxERG1woTo5Uz4Kmvpx8gA1Ojk98sz8Qog9BSUIAWMM1fLutsUCRrWCdn5zsC
         0Z2VUfHmwgR2D4TWwrSpCFBcmxklaqxLegsOeJKnzVAYG+jd/kMKVHdlODYHZ8yScSMZ
         t8JJFJ53JJ3aX2F/HE3KGgsz3OTV4Qh02aB08dCvChi5h54rY3RYKl4VtQ+DOV82nKFv
         +25f9uc05KZHbQndQ4EpeI7GWtr0G2/xTNt+Q5KhzeCHpA+rGHTgj7jTI8poM7WaIfUZ
         YvCq+hVkmWFtC9BZ0kKvtUmVN29j0Pj4ZgmBEGA9pPfkVE2Sy+Y0oKOM5FNLvi6vrMde
         Mfqg==
X-Forwarded-Encrypted: i=1; AJvYcCVx74wX34xKfwEgBpARdTkUuQ7eogrdJHKJ6BIKlJTDMs5M7uCKhu8gL2OZs5fcHurCKkaZavrF+UM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyXgE5ZIgK8bpryp2r27ZIZP0ELrn3y5CDg4w5+DRRBW+g/n0No
	8+W/mDy24W/iihp0sJ7Lf9AvMyW7E8IQ00RcAYsf7MK0UVwgZrCnKW4td7b66FyTrA==
X-Gm-Gg: ASbGncuNHXLJtivnLH8u+VVX8u4Kw+/oWhgQ0z28r+hyzqv4JA0Q4TF6luabhtxolyN
	dAMmDx+hmYI2CbrYyt7Vhdv9P/S4F3l0yN+dsfOPRrHVSSr+JYJ264YOLX/0zINdrviMpN9nfVG
	OaGve2lfdlq6MtmSXrEx4B3GoS/fzdh79VaYqnvdLtlkjXj8TXoLN5+P8CQ6Yo3HLEgbsUJLDQm
	bL/ajn+r7PfIqU1Sn1KvPtXWhWHB89MNl63K8E/BDGBI03ulfpldBrIhBQ6PCT1evwBohnxy1fs
	FtIjlgJYQUfh3fgrYHE7iz6NgMKapwhycul6ldugD5gDd1LKk3VmlbpQbbVw3wHFQLeVWAVm57E
	Sk8eJ3f46ehR9ee+CkUrreK2wyK9OUHKXrrNC0kuIua7OVh0=
X-Google-Smtp-Source: AGHT+IGprPs/sdO69BD+FtqKFCKUvs4v1dGCAis7/L8up8AOm7hrlO80TQD3Jbsx1FmR9yS2l5hmNQ==
X-Received: by 2002:a5d:5f92:0:b0:3a6:d5fd:4687 with SMTP id ffacd0b85a97d-3a6ed60299cmr2924878f8f.18.1750866836170;
        Wed, 25 Jun 2025 08:53:56 -0700 (PDT)
Message-ID: <7cb7a46b-8d2e-4f9e-9613-f7a4199096ee@suse.com>
Date: Wed, 25 Jun 2025 17:53:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 05/17] xen/riscv: introduce things necessary for p2m
 initialization
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: 
 <443cb3566a60dcb5d5440c72410ff6d76a010a58.1749555949.git.oleksii.kurochko@gmail.com>
 <5c61fd86-5c0e-481e-a5a9-6a53f2d78c36@suse.com>
 <0b3c403b-0f24-4fc6-ba5b-fb4df62d7057@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: <0b3c403b-0f24-4fc6-ba5b-fb4df62d7057@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 25.06.2025 17:31, Oleksii Kurochko wrote:
> On 6/18/25 6:08 PM, Jan Beulich wrote:
>> On 10.06.2025 15:05, Oleksii Kurochko wrote:
>>> @@ -14,6 +18,29 @@
>>>   
>>>   /* Per-p2m-table state */
>>>   struct p2m_domain {
>>> +    /*
>>> +     * Lock that protects updates to the p2m.
>>> +     */
>>> +    rwlock_t lock;
>>> +
>>> +    /* Pages used to construct the p2m */
>>> +    struct page_list_head pages;
>>> +
>>> +    /* Indicate if it is required to clean the cache when writing an entry */
>>> +    bool clean_pte;
>>> +
>>> +    struct radix_tree_root p2m_type;
>> A field with a p2m_ prefix in a p2m struct?
> 
> p2m_ prefix could be really dropped.
> 
>>   And is this tree really about
>> just a single "type"?
> 
> Yes, we don't have enough bits in PTE so we need some extra storage to store type.

My question wasn't about that, though. My question was whether in the name
"type" (singular) is appropriate. I didn't think you need a tree to store just
a single type.

>>> +    /*
>>> +     * Default P2M access type for each page in the the domain: new pages,
>>> +     * swapped in pages, cleared pages, and pages that are ambiguously
>>> +     * retyped get this access type.  See definition of p2m_access_t.
>>> +     */
>>> +    p2m_access_t default_access;
>>> +
>>> +    /* Back pointer to domain */
>>> +    struct domain *domain;
>> This you may want to introduce earlier, to prefer passing around struct
>> p2m_domain * in / to P2M functions (which would benefit earlier patches
>> already, I think).
> 
> But nothing uses it earlier.

If you do as suggested and pass around struct p2m_domain * for p2m_*()
functions, you'll quickly find it used, I think.

>>> --- a/xen/arch/riscv/p2m.c
>>> +++ b/xen/arch/riscv/p2m.c
>>> @@ -1,13 +1,46 @@
>>>   #include 
>>> +#include 
>>>   #include 
>>> +#include 
>>>   #include 
>>> +#include 
>>> +#include 
>>> +#include 
>>>   #include 
>>>   #include 
>>>   #include 
>>>   
>>> +#include 
>>>   #include 
>>>   #include 
>>>   
>>> +/*
>>> + * Force a synchronous P2M TLB flush.
>>> + *
>>> + * Must be called with the p2m lock held.
>>> + */
>>> +static void p2m_force_tlb_flush_sync(struct p2m_domain *p2m)
>>> +{
>>> +    struct domain *d = p2m->domain;
>>> +
>>> +    ASSERT(p2m_is_write_locked(p2m));
>>> +
>>> +    sbi_remote_hfence_gvma_vmid(d->dirty_cpumask, 0, 0, p2m->vmid);
>>> +}
>>> +
>>> +/* Unlock the flush and do a P2M TLB flush if necessary */
>>> +void p2m_write_unlock(struct p2m_domain *p2m)
>>> +{
>>> +    /*
>>> +     * The final flush is done with the P2M write lock taken to avoid
>>> +     * someone else modifying the P2M wbefore the TLB invalidation has
>>> +     * completed.
>>> +     */
>>> +    p2m_force_tlb_flush_sync(p2m);
>> The comment ahead of the function says "if necessary". Yet there's no
>> conditional here. I also question the need for a global flush in all
>> cases.
> 
> Stale comment.
> 
> But if p2m page table was modified that it is needed to do a flush for CPUs
> in d->dirty_cpumask.

Right, but is that true for each and every case where you acquire the
lock in write mode? There may e.g. be early-out path which end up doing
nothing, yet you would then still flush the TLB.

>>> @@ -109,8 +142,33 @@ int p2m_init(struct domain *d)
>>>       spin_lock_init(&d->arch.paging.lock);
>>>       INIT_PAGE_LIST_HEAD(&d->arch.paging.p2m_freelist);
>>>   
>>> +    rwlock_init(&p2m->lock);
>>> +    INIT_PAGE_LIST_HEAD(&p2m->pages);
>>> +
>>>       p2m->vmid = INVALID_VMID;
>>>   
>>> +    p2m->default_access = p2m_access_rwx;
>>> +
>>> +    radix_tree_init(&p2m->p2m_type);
>>> +
>>> +#ifdef CONFIG_HAS_PASSTHROUGH
>> Do you expect this to be conditionally selected on RISC-V?
> 
> No, once it will be implemented it will be just selected once by config RISC-V.
> And it was done so because iommu_has_feature() isn't implemented now as IOMMU
> isn't supported now and depends on CONFIG_HAS_PASSTHROUGH.

If the selection isn't going to be conditional, then I see no reason to have
such conditionals in RISC-V-specific code. The piece of code presently inside
that #ifdef may simply need adding later, once there's enough infrastructure
to allow that code to compile. Or maybe it would even compile fine already now?

>>> +    /*
>>> +     * Some IOMMUs don't support coherent PT walk. When the p2m is
>>> +     * shared with the CPU, Xen has to make sure that the PT changes have
>>> +     * reached the memory
>>> +     */
>>> +    p2m->clean_pte = is_iommu_enabled(d) &&
>>> +        !iommu_has_feature(d, IOMMU_FEAT_COHERENT_WALK);
>> The comment talks about shared page tables, yet you don't check whether
>> page table sharing is actually enabled for the domain.
> 
> Do we have such function/macros?

We have iommu_hap_pt_share, and we have the per-domain hap_pt_share flag.

> It is shared by implementation now.

I don't understand. There's no IOMMU support yet for RISC-V. Hence it's in
neither state - not shared, but also not not shared.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 15:55:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 15:55:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1025286.1400912 (Exim 4.92)
	(envelope-from )
	id 1uUSTD-0000FK-Tt; Wed, 25 Jun 2025 15:55:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1025286.1400912; Wed, 25 Jun 2025 15:55:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUSTD-0000FD-QV; Wed, 25 Jun 2025 15:55:31 +0000
Received: by outflank-mailman (input) for mailman id 1025286;
 Wed, 25 Jun 2025 15:55: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 1uUSTC-0000F7-Sf
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 15:55:30 +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 d17f4105-51dc-11f0-a30f-13f23c93f187;
 Wed, 25 Jun 2025 17:55:30 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3a54700a46eso1196824f8f.1
 for ; Wed, 25 Jun 2025 08:55:30 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a6e8114697sm5044424f8f.98.2025.06.25.08.55.28
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 25 Jun 2025 08:55:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d17f4105-51dc-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750866929; x=1751471729; 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=7buStalg0deP2mOBjFco5ld6+7SBqWlQLcb6PvVK9Vw=;
        b=fiknQgPdqntTHQBVXhjv9+zI91sLSPpas2+dVz/CDa3vzUXPvoqTGJKKsOk3QcOkQH
         saGe4wUdys6ZVjmp/B5TYtz6hSavSM7ap6BHZjfff0lWGxeRblqGI3vJd69pEldggUTM
         1LOCDYf3AsHuZIDK/kVtO8YBCXTTNYevluPjk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750866929; x=1751471729;
        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=7buStalg0deP2mOBjFco5ld6+7SBqWlQLcb6PvVK9Vw=;
        b=KjD6eC0ttQBPg8wL9iDCzu/0zo9pw/iREHB6CDVQxRa+Hw1ykPqKgqYFtwiDyi8rGu
         MGXAhjkKkGmuGmJcXqFtZ8XgV6udW3P2CcpQXidK2B9jRaJqXhRsxWWTilK7lGfJe032
         x9UpQpwM2LJLq6xEpVs4eU5XaVq9vy3zyOcjo6bn6y8iMCA6QntibZri4KGl7ki261u0
         eK1Lprf6ZkBwYhu44y4nuNFcFO1+0MSxoZviSkPr/O8NfoH5Qrwjq+5L6YCOz5xz9go4
         /QFxhSQmEu4J6r4Qjm1PjIYv0NnExYia88hDbtqdPtOTh75vLJBBuVYljEt8prIr76UF
         WtpA==
X-Gm-Message-State: AOJu0Yxf7bJH/nSJts1TmEcBO16oP9TnZ9PTDqz/BpFWPWPw2lE04hfl
	hTlteGKbS9hGGT8VyqBd2hBl9kf8ifOl6Rm6ukpj+2tVn/FECFJKU9xUcxghxSfKkqI=
X-Gm-Gg: ASbGncsWdHOj8Q7UrSYcHwsPE9rNcq/jEYNt3UokQMMtvp50Iu4tjdymYq0A+5iRBAl
	6oUdHGNcBcmhTOY/8OWPXRXl87Y2KpMxeYdHBA4Ax32wtihY7NgKzMGMGd5PpIn4HSKEmsnJRmW
	EHRnmIQHa0jNAeBoLg4409Pbm4iZTGk4QRvDrtTUf0GkjCxdsM0Xam/gUhYFUGIqSj3RVHr/VIV
	Pg2byaYsUiBK1RKp3VJt9JXy4JaG4e/N/rAPUy1O4wi2HHzK9vpk2lKLShTsKl5AHHvANbmn5l5
	mzAUzXwfPT5litfp1yThXGP/tqw4yfHP1OA/DpOwKsvI5G/Gq+8BUCLVdPpHSM6iqdEMsc05nOD
	RRk+nEYmMDF/oaZDX/mvfbkKHzu9jqSK6GHsd1FCF
X-Google-Smtp-Source: AGHT+IExt9KwI27fmbyPyE/KN2wDLDbVv0JX3TdiSnvsF3v/bvY8nLZ0j2tbCubOiBAKjupFUH8D6Q==
X-Received: by 2002:a05:6000:2084:b0:3a5:42:b17b with SMTP id ffacd0b85a97d-3a6ed65e60fmr2699081f8f.29.1750866929324;
        Wed, 25 Jun 2025 08:55:29 -0700 (PDT)
Date: Wed, 25 Jun 2025 17:55:28 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Anthony PERARD 
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v2 6/8] test/pdx: add PDX compression unit tests
Message-ID: 
References: <20250620111130.29057-1-roger.pau@citrix.com>
 <20250620111130.29057-7-roger.pau@citrix.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 

On Tue, Jun 24, 2025 at 03:37:34PM +0200, Anthony PERARD wrote:
> On Fri, Jun 20, 2025 at 01:11:28PM +0200, Roger Pau Monne wrote:
> > +.PHONY: run
> > +run: $(TARGETS)
> > +ifeq ($(CC),$(HOSTCC))
> > +	for test in $? ; do \
> > +		./$$test ;  \
> > +	done
> 
> You need to add `set -e` or the exit value from the tested binary might
> be ignored. This `run` target only failed if the last test binary return
> a failure.

Oh, I did see it failing, but both tests at teh same time, that's why
I didn't notice that only the first failing won't be reported.

> > +else
> > +	$(warning HOSTCC != CC, will not run test)
> > +endif
> > +
> > +.PHONY: clean
> > +clean:
> > +	$(RM) -- *.o $(TARGETS) $(DEPS_RM) pdx.c pdx.h
> 
> Is this "pdx.c" left over from version? It doesn't seems to be generated
> by this makefile.

Yeah, it's a leftover from the previous version where I was also
making a local copy of pdx.c.

> > +
> > +pdx.h: $(XEN_ROOT)/xen/include/xen/pdx.h
> > +	sed -E -e '/^#[[:space:]]?include/d' <$< >$@
> 
> Why allow only zero or one space characters between '#' and
> "include"? Why not used '*' instead of '?' ?

Because that's all we currently use in the header, but I can indeed
switch to * just in case we gain includes with more spaces.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 16:01:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 16:01:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1025292.1400921 (Exim 4.92)
	(envelope-from )
	id 1uUSYZ-0002Oi-G1; Wed, 25 Jun 2025 16:01:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1025292.1400921; Wed, 25 Jun 2025 16:01: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 1uUSYZ-0002ON-D2; Wed, 25 Jun 2025 16:01:03 +0000
Received: by outflank-mailman (input) for mailman id 1025292;
 Wed, 25 Jun 2025 16:01: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 1uUSYY-0002NC-DU
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 16:01:02 +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 966fd072-51dd-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 18:01:00 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3a503d9ef59so4614046f8f.3
 for ; Wed, 25 Jun 2025 09:01:00 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d8608d4asm134216355ad.128.2025.06.25.09.00.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 25 Jun 2025 09:00:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 966fd072-51dd-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750867260; x=1751472060; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=2YoKjuD0rlflwuG2CSjCcyB+nKRUBL1XxuyWu9Ue/1o=;
        b=hGQIcWpJXDIJMhNYlFbXrrKEFO2z7GE04dO55ytJltRPpJRnjyXindPTpoWoL+kp50
         RQSJOA8+Utp4lbk3t/rJz5cIrqT+nAl3qoWrHO5ZqN3RfsMYxWw8nZo2I1ITu05M0pEs
         gVpfg6+Wq8rYfY7IAJu63szm6FcfIaIdlVaat0G7wM0D2hArKotM9Rg+vCSBphehLJW/
         K1UuV+6jAG7ki35dmHHk4nteZvjN2hwXVHMVmPXtIk4zFaoyY5bNFfiAogeK0VYws9pT
         1rIe+LkU253slpX8T75cSsJVVEkLuhohKfthO4VuS1P2gIxIMKPRKDyhOr+hLrMLZGq0
         4Zbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750867260; x=1751472060;
        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=2YoKjuD0rlflwuG2CSjCcyB+nKRUBL1XxuyWu9Ue/1o=;
        b=nu0ct3U6g1ScStPzFxsrQHvfKc/fsllNxXdKIF+AR+uYALFEj1PcLgTiDf2xfy3xTt
         yz4uy3sfCsbmkn9wyhX5bBRDgVDZGxuHEqz55Q51Axtk7GVMr4zLit/zVYjHlDPxRhvE
         VR1OdAhtaId0TGshn4ity9bgIsodErvpQzPbLjuLnxi7ZTWydYhHq49yZjUXpotiHm/h
         6+Fp0/e+qt8hUrt26X/mmD9pWIwZlSqahqvEUzOcIB3kxscrQ7RCjuwNUoIfaA3XEFMD
         xVIfckmDMdaRMY1IhC/70b3YtLzo86WNPZV6024j3l5zh746kn10WQPBnMzLgMp5e4aK
         Fhag==
X-Forwarded-Encrypted: i=1; AJvYcCW2BaNyReE+WUEMFQNJ64BiB7LLJojd8ByQuLt7O/do0GesfCb4+tL+rOj55/gQPDSU0oTHCD71Tss=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzzxpR+natIr1rhGcVYRVLTHeZAXH8ecUNuESiQ8FDcyyEg1laV
	yBKSzWZv1LrFw9N3hEtNc3wSLxTa/90Q+zzx0MVGYReEBKuCXnPDFjXu8oJWwvQB6w==
X-Gm-Gg: ASbGnctrhsGF6YMDWZenMrVNQeUGNCik+9eALaL6hPwjCfp8AZyUKpcxD8YlXxeKGST
	TRs+vbIwhZ774IHAqyaT2V87PdMx1Z/VpWUZfWb/7Y1zWtdS+AYCoFFNSER07aQa8C2mT/OULVO
	7oXS7WVtjItrOo1hO7B98b0TQYNneIilFxe1g7WsCsZbbTEgt0C8yfdjPBlheY0ig1Yb4djcg0A
	X9gxkcXH8ULHdlODtJM86fFSiKHJrBKdK4/CYusRtwLkzXp9gChlf7WbangGO/1yzs6ayiwOZtn
	BYM/8DFBGugHja13r1rOExBL1jV6Hupauy9mcpC0mdh5uGv+rSB0cqCxsW3hexQ48+cwcorLvMB
	+26hCq+MrKEMZNRgm3hnhK2iUbZhhOIcXlyZUyPadTx9BwGk=
X-Google-Smtp-Source: AGHT+IGAN80m9k6Oyy6oEXPrzAvQ9yy96RroQd9YnSikeRZ9hK7mZo9QObVzXl5ukovbf9U0SGioRw==
X-Received: by 2002:a05:6000:2082:b0:3a4:e740:cd72 with SMTP id ffacd0b85a97d-3a6ed5f20e5mr3463691f8f.13.1750867258104;
        Wed, 25 Jun 2025 09:00:58 -0700 (PDT)
Message-ID: <23206592-6016-47cc-87a6-151c76f254d6@suse.com>
Date: Wed, 25 Jun 2025 18:00:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 4/8] pdx: introduce command line compression toggle
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20250620111130.29057-1-roger.pau@citrix.com>
 <20250620111130.29057-5-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: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 25.06.2025 17:46, Roger Pau Monné wrote:
> On Tue, Jun 24, 2025 at 03:40:16PM +0200, Jan Beulich wrote:
>> On 20.06.2025 13:11, Roger Pau Monne wrote:
>>> Introduce a command line option to allow disabling PDX compression.  The
>>> disabling is done by turning pfn_pdx_add_region() into a no-op, so when
>>> attempting to initialize the selected compression algorithm the array of
>>> ranges to compress is empty.
>>
>> While neat, this also feels fragile. It's not obvious that for any
>> algorithm pfn_pdx_compression_setup() would leave compression disabled
>> when there are zero ranges. In principle, if it was written differently
>> for mask compression, there being no ranges could result in compression
>> simply squeezing out all of the address bits. Yet as long as we think
>> we're going to keep this in mind ...
> 
> It seemed to me that nr_rages == 0 (so no ranges reported) should
> result in no compression, for example on x86 this means there's no
> SRAT.

Just to mention it: While in the pfn_pdx_compression_setup() flavor in
patch 3 there's no explicit check (hence the logic is assumed to be
coping with that situation), the one introduced in the last patch does
have such an explicit check. Apparently there the logic doesn't cleanly
cover that case all by itself.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 16:05:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 16:05:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1025303.1400932 (Exim 4.92)
	(envelope-from )
	id 1uUScV-0003CO-36; Wed, 25 Jun 2025 16:05:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1025303.1400932; Wed, 25 Jun 2025 16: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 1uUScU-0003CH-WA; Wed, 25 Jun 2025 16:05:06 +0000
Received: by outflank-mailman (input) for mailman id 1025303;
 Wed, 25 Jun 2025 16:05: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 1uUScU-0003CB-57
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 16:05:06 +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 269307fe-51de-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 18:05:02 +0200 (CEST)
Received: by mail-lf1-x12f.google.com with SMTP id
 2adb3069b0e04-553b6a349ccso29783e87.0
 for ; Wed, 25 Jun 2025 09:05:02 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d83c7d45sm140986265ad.55.2025.06.25.09.04.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 25 Jun 2025 09:05:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 269307fe-51de-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750867501; x=1751472301; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=b5Ce150+excxZCDbiei0DwFbtK25gxeKUYuQd7UHRW0=;
        b=bkFiH00+0G5ucAS/mNjyNivQ4pjaDw9KW3Sw0XpBLxGw12X5lR4Ozs+GUOMUUxTQ9+
         /EBEmneTgH/HvZp5Z7F/QWAj0+vkrp0NbNEWfVJXfb7PT3iQ0eqEafmOV8yKKmtCkAEM
         SXj6m978ejDzvp8WBTa5zvpL7aXlcM6wwOTUoBI7MTFIlZtlIrTO4rRJTWGwyPoXk0NB
         pjhAlRwVBy0ogxUWsKXLvm3GMAWEAs/fMoHD4u/a7Ix7fJAWrezEOpnPQTpzVYNnTVEz
         PEQ9LhpSRyeexGQS4D8ShxaJQMkvEJkJqkHDzEbwWygrYrOSBjuoPq4yI0YP6JILG0Yp
         o7GA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750867501; x=1751472301;
        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=b5Ce150+excxZCDbiei0DwFbtK25gxeKUYuQd7UHRW0=;
        b=aEpZluMNt/id1G/iryBjc7muBNF+lqE+B1Iw/by5rglJi75g/P6/tH6redTounzPGv
         faPY1zHwhX9oc/pHpLex3lK1k0GnCtczTdQz3tg/Rz3e77O6llx/EHkG8PlcL0R6w7p5
         ZHGXWegSxdYqxy48nIwGmv9KZ41lmr0pOz5tXDNv238/zhDEIfnxcQwK4BzLjZ4xDaRu
         wd2SQOJ56krwdh8mlocT875uCnH2ufYRTo4LSGkUxr/VTEQyr98ytR0UiB9ciUc7Czft
         SgQT/Id1mvvN181GioP4TkgFqWHT5fkvhGxu4X3psrIf2sEJoLhV1Y8VBxLYR7vW12D2
         tMVA==
X-Forwarded-Encrypted: i=1; AJvYcCUDcMkqQANbmMjn//XyghOZ/GXH0Mw4K0I++qr+GYhYC1nOLEup9XBn+773QfpjbXv4R1MZlZRG8/A=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyfABbtQq09yufv4hz+3OExuc+Wt3qqWU+rAgkWRKre/4hozpM+
	nB9Uc/xiup53nVjoo4CgpdC+EunF+hGOF+cWfj1/y226N5IJKJukZcgv7yfONaCQpA==
X-Gm-Gg: ASbGncuQgTP4F3ch7GkdR2Focg6iu1k7K5uXrPCrq3k0dmHloVsjAi8OCIInyzT2Ybh
	9M/JXvY3G7G9hIyltF0V0uZ/SX+ooQu9ywE64i8iWMLM9WW3rSq/RM8S3iejDmvE0f8x3Lnt+r3
	00xG7Hym9KmbGIw5/DhbrT1zKUo0jQJcegocaq4u0wUuCZA6eLjjqC2iWDN21+t3lQIlb/2SEy6
	XPsqRdxk1NofPuoE19fkhpeGt/0SQE9lH7+r6uQyQ+QPw1tWIPZE/9lqDUc29hDBn3s8mfgBZ+8
	mpxdMhLLwngZ668g+YnWESk5zIa6m75cLLhL/5nrouE8X+CKcyYFiipNSe1+SZcL/WaMFxoP3dE
	q2Kn5Zw2sMwsVE83Bb/3qOSpELFaNb7kbAsQh1Oj9tAbhHXk=
X-Google-Smtp-Source: AGHT+IEYX80sL4mH2Xh+f1pg0Sot5/VQ52+EM9rAXDMcmBCmazlT0o4hxF97HH+FOe1Sj5MRGScqXg==
X-Received: by 2002:ac2:4e07:0:b0:550:e527:886f with SMTP id 2adb3069b0e04-554fdf650a8mr1313110e87.51.1750867500869;
        Wed, 25 Jun 2025 09:05:00 -0700 (PDT)
Message-ID: 
Date: Wed, 25 Jun 2025 18:04:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 5/8] pdx: allow per-arch optimization of PDX conversion
 helpers
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD ,
 Shawn Anastasio ,
 Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Oleksii Kurochko ,
 xen-devel@lists.xenproject.org
References: <20250620111130.29057-1-roger.pau@citrix.com>
 <20250620111130.29057-6-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: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 25.06.2025 17:51, Roger Pau Monné wrote:
> On Tue, Jun 24, 2025 at 03:51:09PM +0200, Jan Beulich wrote:
>> On 20.06.2025 13:11, Roger Pau Monne wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/x86/include/asm/pdx.h
>>> @@ -0,0 +1,75 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>> +
>>> +#ifndef X86_PDX_H
>>> +#define X86_PDX_H
>>> +
>>> +#ifndef CONFIG_PDX_NONE
>>> +
>>> +#include 
>>> +
>>> +/*
>>> + * Introduce a macro to avoid repeating the same asm goto block in each helper.
>>> + * Note the macro is strictly tied to the code in the helpers.
>>> + */
>>> +#define PDX_ASM_GOTO_SKIP                           \
>>> +    asm_inline goto (                               \
>>> +        ALTERNATIVE(                                \
>>> +            "",                                     \
>>> +            "jmp %l[skip]",                         \
>>> +            ALT_NOT(X86_FEATURE_PDX_COMPRESSION))   \
>>> +        : : : : skip )
>>
>> Did you consider passing the label name as argument to the macro? That way ...
>>
>>> +static inline unsigned long pfn_to_pdx(unsigned long pfn)
>>> +{
>>> +    PDX_ASM_GOTO_SKIP;
>>> +
>>> +    return pfn_to_pdx_xlate(pfn);
>>> +
>>> + skip:
>>> +    return pfn;
>>> +}
>>
>> ... the labels here and below then wouldn't look unused.
> 
> Yes - that's why I've added the "Note the macro is strictly tied to
> the code in the helpers" comment ahead of the macro, and named it as
> "GOTO_SKIP" to explicitly reference the label name.  I could pass the
> label name however if that's preferred, ie: PDX_ASM_GOTO(skip).  IMO
> It seems a bit redundant since all callers will pass the same label
> name.

Well, that comment isn't necessarily "in sight" when looking at the
functions using the macro. Personally I'd favor passing the label as
an argument; indeed I think we would better try to do away with other
such macros where inputs are implicit. Yes, there may be cases where
that's hard or getting unwieldy. But the one here isn't one of them.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 16:07:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 16:07:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1025310.1400941 (Exim 4.92)
	(envelope-from )
	id 1uUSev-0003iv-Eh; Wed, 25 Jun 2025 16:07:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1025310.1400941; Wed, 25 Jun 2025 16:07:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUSev-0003io-C6; Wed, 25 Jun 2025 16:07:37 +0000
Received: by outflank-mailman (input) for mailman id 1025310;
 Wed, 25 Jun 2025 16:07: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 1uUSeu-0003ih-GU
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 16:07:36 +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 81774df3-51de-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 18:07:34 +0200 (CEST)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-451d6ade159so50861545e9.1
 for ; Wed, 25 Jun 2025 09:07:34 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-74ad3fed402sm2455200b3a.125.2025.06.25.09.07.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 25 Jun 2025 09:07:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 81774df3-51de-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750867654; x=1751472454; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=JlWIg5AL+uwdSMf+icLYMi1uOb9L0IeOaxWTplwF3HU=;
        b=dxwUCCChrqCwb8Ue8gnM+/kUIomKIRcnb5I5EPOACteJcIORGVrFtROgzUz+kAg0pJ
         FuGSQxc5Chr03D6JXHyj+UsjMleIOLzC3rD1S9vyOKZyZPhoxSKzJIcO1Ct67a+URouo
         P63inOBJBeKGc+J/PK+ZitJwutRmfzH0LEpzgEe2K+iGkdxAT/KGEWfrPiShsupxLZn3
         SuoW+FUwHNCfas9K8ZauSHrLPkJu4nedZZYAlJ4JZRcEJlEdwxJY3DYvPjM59je0BZS6
         xQE5kkCRtH0Sw9g2cj288ZnGQSgJ58ACK/fLjYw2vXQjMwjpkPWbAWRvX4y7Bq9Z/MP6
         alLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750867654; x=1751472454;
        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=JlWIg5AL+uwdSMf+icLYMi1uOb9L0IeOaxWTplwF3HU=;
        b=mT887tsAiBvHaU61+AAdZVsf4FkBv0uowjZwvWT+8GEeY1aXlBj6ExzF1jEI05EI3k
         EREf17JfnZTYV5Ps1wPGoELmZtGdRI6xPpqLXhU5u+PQz1rVES/wceY7/s7joRsk9wSh
         YDpG+sKOURQq3uIHnkFa6zvR9ptDDj9f8w5Wmdjd1qvuZbvRCKom4Gi0eJ1Km27a/aoS
         CKMZR54oSOFxGiK9MANYsWAoZOIiQfVzHph7POhCqr5uNmeB2BMzET3MlvzslPbGhTJA
         BmEwx5WM8gmio9tNGfau2APB33E0/deBTP27CMTgjCuQQIcxknnn13XgmsB7CUQTJYJr
         rWvg==
X-Forwarded-Encrypted: i=1; AJvYcCV6Aj5ECcgPAGyMIy2H+AAXzJgW3c/jca6Jvq/FUfuo3YSTdrBRTB5R//xfaHfcQGxE2LkN372ddDE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzl+YjBZLfijDUfdCBLFlGxA3g1pJCM8SWDdWf5xs5DMPYOJ0pW
	7F8xiBxlhCSLiNE6PCTRZTPbAzO/fnr65Jn9lAykE4r+1y44taUvq7JKuQntDmqk6+jj9chz8bI
	NpT8=
X-Gm-Gg: ASbGncvKfoCRkjNA6LGRix8sDEkjPlxlR3L4pESkgzttjQYj4geQdN8/lMvvsAau4sZ
	z5cNzjBhVsnFYIsBeNYt+9rS3rzMKv34vkqXyOiPb+/BU22p54eMknOc+hIds8/J/V+BAIqFnWc
	dVJINUorofh5tsqdz6oz4nVy6622cxSJN2xbk1YXvdu61ZKWdhKpFHucu+Hjy21kjL9YrwNelQZ
	/kpJk/UBs5EmpQf02exvnyO8uyHIUieoPAYp+eVpmHuCo+OHzz1/7mXSWyDWt03RdqTFEH0DN3n
	VFLPO3LXL8rh1UPyb7PaMqfTNs5PfRj3YpJPYTLXZUByHRNjszIJwLSvRcPM+ydM5buWRLif/V7
	e1aKou49H020t/KcEUOPAa/QoytCTbjBxh56R4pxYpYtxKio=
X-Google-Smtp-Source: AGHT+IEyuvRvIlBmwu5AANJaJnhjtJJRojk01S4w8PQzVXi5dUXR9gMnAIVcPXpCp1mzGVvJRJTzIQ==
X-Received: by 2002:a05:6000:2004:b0:3a6:d579:ec21 with SMTP id ffacd0b85a97d-3a6ed61a4admr2890668f8f.12.1750867653764;
        Wed, 25 Jun 2025 09:07:33 -0700 (PDT)
Message-ID: <21e532ca-2988-4136-978b-a12564e9a5f3@suse.com>
Date: Wed, 25 Jun 2025 18:07:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/boot: Improve paging mode diagnostics in
 create_dom0()
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20250625150105.402005-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: <20250625150105.402005-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 25.06.2025 17:01, Andrew Cooper wrote:
> I was presented with this:
> 
>   (XEN) NX (Execute Disable) protection active
>   (XEN) d0 has maximum 416 PIRQs
>   (XEN)
>   (XEN) ****************************************
>   (XEN) Panic on CPU 0:
>   (XEN) Error creating d0: -95
>   (XEN) ****************************************
> 
> which is less than helpful.  It turns out to be the -EOPNOTSUPP from
> shadow_domain_init().
> 
> The real bug here is create_dom0() unconditionally assuming the presence of
> SHADOW_PAGING.  Rework it to panic() rather than choosing a dom0_cfg which is
> guaranteed to fail.  This results in:
> 
>   (XEN) NX (Execute Disable) protection active
>   (XEN)
>   (XEN) ****************************************
>   (XEN) Panic on CPU 0:
>   (XEN) Neither HAP nor Shadow available for PVH domain
>   (XEN) ****************************************
> 
> which is rather more helpful.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Wed Jun 25 16:24:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 16:24:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1025325.1400952 (Exim 4.92)
	(envelope-from )
	id 1uUSv9-0006vA-Qc; Wed, 25 Jun 2025 16:24:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1025325.1400952; Wed, 25 Jun 2025 16:24:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUSv9-0006v3-N2; Wed, 25 Jun 2025 16:24:23 +0000
Received: by outflank-mailman (input) for mailman id 1025325;
 Wed, 25 Jun 2025 16:24: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 1uUSv8-0006uC-VS
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 16:24:23 +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 d90d514e-51e0-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 18:24:20 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3a5123c1533so3602003f8f.2
 for ; Wed, 25 Jun 2025 09:24:20 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a6e8050e1fsm4960664f8f.8.2025.06.25.09.24.19
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 25 Jun 2025 09:24:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d90d514e-51e0-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750868660; x=1751473460; 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=MKdRFtq/FsRfJyxZawMg/6AI/mJV7ZYU4ww0R/FiueA=;
        b=HyZyjdXzsm3rcPPtOR4kvQX9RFT1ubZ+fmBp4HHOLcR4fDaNBSJSaTwxqsLN2GkED6
         5CvTm/bGIEmqLWW/xGKGUMtcToTOrDD9nZpom/xP1BuIp1hA8aQanoEE4zQXz41J8pIw
         RZyfhHXBw5cJIq7e03wI1bZqT9TS8oXEaOXCQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750868660; x=1751473460;
        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=MKdRFtq/FsRfJyxZawMg/6AI/mJV7ZYU4ww0R/FiueA=;
        b=MePYYH9L8MP4ciVLs5XvCvYS9QhfDU50w83ObSgUP97JS6zVx5WXaGncTaoKknF6op
         EwQzDY0lbue15JPnNYRpYbni902nGVozJvu6/c93JUfuknLLGGnMcB8qlWfqT31UOEDU
         Y/nzyHKcz0kapUBKLK81UTiKFVSxwdbCWlsBEBASuTnoEeUHqvthhy8q0br0AGScBPe5
         G5IgB7HaP0sNZooNCQZ+gcTaL7vfiGL+fwbZV1sqgwBKB0VDn0W28cOog+og4+r7VaR7
         c9vaaaR665fVckIu0zOuoYHXE15+d7KGqPiLUdTPKNYjx77995PJ9zqFb1/64ifHSOQ1
         J6MA==
X-Forwarded-Encrypted: i=1; AJvYcCWj4bK9zF+13NE9+Bgklu33LT//AHrR78pHZnvmrIQyDUGYuYWwCPB7kcp7GiUDA7+FlqiD0+JpJp0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzplTm+du9zVnQHJ0TIg2oAIhIVH1bs4kbzWGNOvyIL23tvWQw8
	Qy7AOHMWU/Yh649lcvRgmJui6CAuPAZZNnbMlApPrU54nMUlNJR9JAuWoAxEo9fSK+s=
X-Gm-Gg: ASbGncsU6NnHw5Ano7MEpJa1kyYrg20R0GMqdnKZ15r9+11rC/IEPE9F26H6WrczQCD
	ZChHOXSeKOVbr6iuKMmU4j78Ue5Gkgl9Cdo7QMrEYTKh8DWSj5LJ7x7uNyRftji5DAOIvsdg5To
	N4ECwMACEBpBi9LAqJuMrNEC1/XbVUPvzKvRR+WNM/WcRMJFC7Qs8kICFM6uoXuEK280cduZjJl
	KbTwjO9B+wTddwDMWME4JoPwLVKjjCv3qYgN91WkgKp1y8V+SF70mZ+oZ5RAfjSacZfRmVSwRaq
	c+nSp9QFSd+mFGNQMRO2E2pQnNCxgiPV7y7afesgoGDy2UfCkrYCSh5mQFEvxk9SNIUQ79OddU0
	11DPS9JWuLQPBEZLzL1uX+tCmwnvgCA==
X-Google-Smtp-Source: AGHT+IFPrzhsvdjGKFbS4wqxgTxOLSEN4/jlrygpl08i1P5uC5WNi22OwgqCF3oWeEgy0LzFFrnsZw==
X-Received: by 2002:a05:6000:2586:b0:3a4:f7df:7564 with SMTP id ffacd0b85a97d-3a6ed575241mr3179740f8f.0.1750868659672;
        Wed, 25 Jun 2025 09:24:19 -0700 (PDT)
Date: Wed, 25 Jun 2025 18:24:18 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Oleksii Kurochko ,
	Community Manager ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 8/8] pdx: introduce a new compression algorithm based
 on region offsets
Message-ID: 
References: <20250620111130.29057-1-roger.pau@citrix.com>
 <20250620111130.29057-9-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, Jun 24, 2025 at 06:16:15PM +0200, Jan Beulich wrote:
> On 20.06.2025 13:11, Roger Pau Monne wrote:
> > With the appearance of Intel Sierra Forest and Granite Rapids it's now
> > possible to get a production x86 host with the following memory map:
> > 
> > SRAT: Node 0 PXM 0 [0000000000000000, 000000007fffffff]
> > SRAT: Node 0 PXM 0 [0000000100000000, 000000807fffffff]
> > SRAT: Node 1 PXM 1 [0000063e80000000, 000006be7fffffff]
> > SRAT: Node 2 PXM 2 [00000c7e80000000, 00000cfe7fffffff]
> > SRAT: Node 3 PXM 3 [000012be80000000, 0000133e7fffffff]
> > 
> > This is from a four socket Granite Rapids system, with each node having
> > 512GB of memory.  The total amount of RAM on the system is 2TB, but without
> > enabling CONFIG_BIGMEM the last range is not accessible, as it's above the
> > 16TB boundary covered by the frame table. Sierra Forest and Granite Rapids
> > are socket compatible, however Sierra Forest only supports 2 socket
> > configurations, while Granite Rapids can go up to 8 sockets.
> > 
> > Note that while the memory map is very sparse, it couldn't be compressed
> > using the current PDX_MASK compression algorithm, which relies on all
> > ranges having a shared zeroed region of bits that can be removed.
> > 
> > The memory map presented above has the property of all regions being
> > similarly spaced between each other, and all having also a similar size.
> > Use a lookup table to store the offsets to translate from/to PFN and PDX
> > spaces.  Such table is indexed based on the input PFN or PDX to translated.
> > The example PFN layout about would get compressed using the following:
> > 
> > PFN compression using PFN lookup table shift 29 and PDX region size 0x10000000
> >  range 0 [0000000000000, 0x0000807ffff] PFN IDX  0 : 0000000000000
> >  range 1 [0x00063e80000, 0x0006be7ffff] PFN IDX  3 : 0x00053e80000
> >  range 2 [0x000c7e80000, 0x000cfe7ffff] PFN IDX  6 : 0x000a7e80000
> >  range 3 [0x0012be80000, 0x00133e7ffff] PFN IDX  9 : 0x000fbe80000
> > 
> > Note how the tow ranges belonging to node 0 get merged into a single PDX
> > region by the compression algorithm.
> > 
> > The default size of lookup tables currently set in Kconfig is 64 entries,
> > and the example memory map consumes 10 entries.  Such memory map is from a
> > 4 socket Granite Rapids host, which in theory supports up to 8 sockets
> > according to Intel documentation.  Assuming the layout of a 8 socket system
> > is similar to the 4 socket one, it would require 21 lookup table entries to
> > support it, way below the current default of 64 entries.
> > 
> > The valid range of lookup table size is currently restricted from 1 to 512
> > elements in Kconfig.
> > 
> > Unused lookup table entries are set to all ones (~0UL), so that we can
> > detect whether a pfn or pdx is valid just by checking whether its
> > translation is bi-directional.  The saturated offsets will prevent the
> > translation from being bidirectional if the lookup table entry is not
> > valid.
> 
> Right, yet with the sad effect of still leaving almost half the space unused.
> I guess that's pretty much unavoidable though in this scheme, as long as we
> want the backwards translation to also be "simple" (and in particular not
> involving a loop of any kind).
> 
> > --- a/CHANGELOG.md
> > +++ b/CHANGELOG.md
> > @@ -20,6 +20,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
> >       grant table or foreign memory.
> >  
> >  ### Added
> > + - Introduce new PDX compression algorithm to cope with Intel Sapphire and
> > +   Granite Rapids having sparse memory maps.
> 
> In the description you updated to mention Sierra Forest instead, but here you
> didn't.

Bah, my bad.  It's Sierra Forest and Granite Rapids, not Sapphire.
I've got confused with the names.

> > --- a/tools/tests/pdx/harness.h
> > +++ b/tools/tests/pdx/harness.h
> > @@ -44,8 +44,10 @@
> >  
> >  #define MAX_RANGES 8
> >  #define MAX_PFN_RANGES MAX_RANGES
> > +#define CONFIG_PDX_OFFSET_TLB_ORDER 6
> >  
> >  #define ASSERT assert
> > +#define ASSERT_UNREACHABLE() assert(0);
> 
> Nit: Stray semicolon.
> 
> > @@ -66,6 +68,8 @@ static inline unsigned int find_next(
> >  #define find_next_zero_bit(a, s, o) find_next(a, s, o, false)
> >  #define find_next_bit(a, s, o)      find_next(a, s, o, true)
> >  
> > +#define flsl(x) ((x) ? BITS_PER_LONG - __builtin_clzl(x) : 0)
> 
> While this is perhaps indeed good enough for a testing utility, ...
> 
> > @@ -75,6 +79,12 @@ static inline unsigned int find_next(
> >  
> >  typedef uint64_t paddr_t;
> >  
> > +#define sort(elem, nr, size, cmp, swp) {                                \
> > +    /* Consume swp() so compiler doesn't complain it's unused. */       \
> > +    (void)swp;                                                          \
> > +    qsort(elem, nr, size, cmp);                                         \
> > +}
> 
> ... this I think wants to use either do/while of ({ }).

OK.  Given it's limited test only usage I've assume it was fine like
this, but I certainly don't mind adjusting.

> > --- a/xen/common/Kconfig
> > +++ b/xen/common/Kconfig
> > @@ -54,7 +54,8 @@ config EVTCHN_FIFO
> >  
> >  choice
> >  	prompt "PDX (Page inDeX) compression"
> > -	default PDX_MASK_COMPRESSION if !X86 && !RISCV
> > +	default PDX_OFFSET_COMPRESSION if X86
> > +	default PDX_MASK_COMPRESSION if !RISCV
> >  	default PDX_NONE
> >  	help
> >  	  PDX compression is a technique designed to reduce the memory
> > @@ -73,12 +74,30 @@ config PDX_MASK_COMPRESSION
> >  	help
> >  	  Compression relying on all RAM addresses sharing a zeroed bit region.
> >  
> > +config PDX_OFFSET_COMPRESSION
> > +	bool "Offset compression"
> > +	help
> > +	  Compression relying on size and distance between RAM regions being
> > +	  compressible using an offset lookup table.
> > +
> >  config PDX_NONE
> >  	bool "None"
> >  	help
> >  	  No compression
> >  endchoice
> >  
> > +config PDX_OFFSET_TLB_ORDER
> 
> Please can we avoid the term "TLB" in the name? What we commonly call a TLB

It should have been TBL_ORDER, not TLB.  My finger memory is too use
to type TLB I think.

> is somewhat different. In fact is there anything wrong with just
> PDX_OFFSET_ORDER?

I've assumed that would be seen as too short and not descriptive
enough.  If that's fine I will switch it.

> > +	int "PDX offset compression lookup table order" if EXPERT
> > +	depends on PDX_OFFSET_COMPRESSION
> > +	default 6
> > +	range 0 9
> 
> Is 0 really a sensible lower bound? There's not going to be any compression
> then, I suppose?

No, you can still compress a single range if start if offset from 0.
See the following example in the test file:

/* Single range not starting at 0. */
{
    .ranges = {
        { .start = (1 << MAX_ORDER) * 10,
          .end   = (1 << MAX_ORDER) * 11 },
    },
    .compress = true,
},

Which results in:

PFN compression using PFN lookup table shift 63 and PDX region size 0x40000
 range 0 [0x00000280000, 0x000002bffff] PFN IDX   0 : 0x00000280000

> > --- a/xen/common/pdx.c
> > +++ b/xen/common/pdx.c
> > @@ -24,6 +24,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  /**
> >   * Maximum (non-inclusive) usable pdx. Must be
> > @@ -40,6 +41,8 @@ bool __mfn_valid(unsigned long mfn)
> >  
> >  #ifdef CONFIG_PDX_MASK_COMPRESSION
> >      invalid |= mfn & pfn_hole_mask;
> > +#elif defined(CONFIG_PDX_OFFSET_COMPRESSION)
> > +    invalid |= mfn ^ pdx_to_pfn(pfn_to_pdx(mfn));
> 
> Hmm, that's pretty expensive already. Involving two (presumably back-to-back)
> JMPs when compression isn't enabled.

There's a conditional with evaluate_nospec() below, so I think the
JMPs are unlikely to make much difference?  Otherwise I would need to
check the index in the lookup table, and possibly introduce a new
variable to store the PDX region size to ensure it also fits in there.

Overall I think it's more complex for possibly little benefit given
the current code in mfn_valid() anyway.

> > @@ -290,7 +300,200 @@ void __init pfn_pdx_compression_reset(void)
> >      nr_ranges = 0;
> >  }
> >  
> > -#endif /* CONFIG_PDX_COMPRESSION */
> > +#elif defined(CONFIG_PDX_OFFSET_COMPRESSION) /* CONFIG_PDX_MASK_COMPRESSION */
> > +
> > +unsigned long __ro_after_init pfn_pdx_lookup[CONFIG_PDX_NR_LOOKUP];
> > +unsigned int __ro_after_init pfn_index_shift;
> > +
> > +unsigned long __ro_after_init pdx_pfn_lookup[CONFIG_PDX_NR_LOOKUP];
> > +unsigned int __ro_after_init pdx_index_shift;
> 
> For slightly better cache locality when only a few array indexes are in
> use, may I suggest to put the indexes ahead of the arrays? Perhaps even
> together, as they both take up a single unsigned long slot.

Can do, yes.

> > +bool pdx_is_region_compressible(paddr_t base, unsigned long npages)
> > +{
> > +    unsigned long pfn = PFN_DOWN(base);
> > +
> > +    return pdx_to_pfn(pfn_to_pdx(pfn) + npages - 1) == (pfn + npages - 1);
> 
> Aiui for this to be correct, there need to be gaps between the ranges
> covered by individual lookup table slots. In the setup logic you have a
> check commented "Avoid compression if there's no gain", but that doesn't
> look to guarantee gaps everywhere (nor would pfn_offset_sanitize_ranges()
> appear to)?

But if there are no gaps, the full region is covered correctly, and
hence it's compressible?

Maybe I'm missing something, could you maybe provide an example that
would exhibit this issue?

> > +static void __init cf_check swp_node(void *a, void *b, size_t size)
> > +{
> > +    struct pfn_range *l = a;
> > +    struct pfn_range *r = b;
> > +    struct pfn_range tmp = *l;
> > +
> > +    *l = *r;
> > +    *r = tmp;
> > +}
> 
> Any reason you effectively open-code SWAP() here?

Lack of knowledge :).

> > +static bool __init pfn_offset_sanitize_ranges(void)
> > +{
> > +    unsigned int i = 0;
> > +
> > +    if ( nr_ranges == 1 )
> > +    {
> > +        ASSERT(PFN_TBL_IDX_VALID(ranges[0].base));
> > +        ASSERT(PFN_TBL_IDX(ranges[0].base) ==
> > +               PFN_TBL_IDX(ranges[0].base + ranges[0].size - 1));
> > +        return true;
> > +    }
> > +
> > +    /* Sort nodes by start address. */
> > +    sort(ranges, nr_ranges, sizeof(struct pfn_range), cmp_node, swp_node);
> 
> Better sizeof(*ranges) or sizeof(ranges[0])?
> 
> > +bool __init pfn_pdx_compression_setup(paddr_t base)
> > +{
> > +    unsigned long size = 0, mask = PFN_DOWN(pdx_init_mask(base));
> > +    unsigned int i;
> > +
> > +    if ( !nr_ranges )
> > +        return false;
> 
> Also bail if there's just a single range?

No, you can still compress (and thus reduce the PDX space) if there's
a single range.

> > +    if ( nr_ranges > ARRAY_SIZE(ranges) )
> > +    {
> > +        printk(XENLOG_WARNING
> > +               "Too many PFN ranges (%u > %zu), not attempting PFN compression\n",
> > +               nr_ranges, ARRAY_SIZE(ranges));
> > +        return false;
> > +    }
> > +
> > +    for ( i = 0; i < nr_ranges; i++ )
> > +        mask |= pdx_region_mask(ranges[i].base, ranges[i].size);
> > +
> > +    pfn_index_shift = flsl(mask);
> 
> With this ...
> 
> > +    /*
> > +     * Increase the shift as much as possible, removing bits that are equal in
> > +     * all regions, as this allows the usage of smaller indexes, and in turn
> > +     * smaller lookup tables.
> > +     */
> > +    for ( pfn_index_shift = flsl(mask); pfn_index_shift < sizeof(mask) * 8 - 1;
> 
> ... you don't need to do this here another time.

Oh, good catch.  This was ordered differently, and I didn't realize
the duplication after the code movement.

> Also - why the subtraction of 1 in what the shift is compared against? Logic
> below should in principle guarantee we never exit the loop because of the
> conditional above, but if we made it that far it looks like we could as well
> also look at the top bit.

Because for a single range this would otherwise end up with
pfn_index_shift == 64, and thus lead to undefined behavior.

> > +          pfn_index_shift++ )
> > +    {
> > +        const unsigned long bit = ranges[0].base & (1UL << pfn_index_shift);
> > +
> > +        for ( i = 1; i < nr_ranges; i++ )
> > +            if ( bit != (ranges[i].base & (1UL << pfn_index_shift)) )
> > +                break;
> > +        if ( i != nr_ranges )
> > +            break;
> > +    }
> > +
> > +    /* Sort and sanitize ranges. */
> > +    if ( !pfn_offset_sanitize_ranges() )
> > +        return false;
> > +
> > +    /* Calculate PDX region size. */
> > +    for ( i = 0; i < nr_ranges; i++ )
> > +        size = max(size, ranges[i].size);
> > +
> > +    mask = PFN_DOWN(pdx_init_mask(size << PAGE_SHIFT));
> > +    pdx_index_shift = flsl(mask);
> > +
> > +    /* Avoid compression if there's no gain. */
> > +    if ( (mask + 1) * (nr_ranges - 1) >= ranges[nr_ranges - 1].base )
> > +        return false;
> > +
> > +    /* Poison all lookup table entries ahead of setting them. */
> > +    memset(pfn_pdx_lookup, ~0, sizeof(pfn_pdx_lookup));
> > +    memset(pdx_pfn_lookup, ~0, sizeof(pfn_pdx_lookup));
> 
> Have the arrays have initializers instead?

No, because otherwise early use (before the initialization done here)
of the translation functions would give bogus results.

> > +    for ( i = 0; i < nr_ranges; i++ )
> > +    {
> > +        unsigned int idx = PFN_TBL_IDX(ranges[i].base);
> > +
> > +        pfn_pdx_lookup[idx] = ranges[i].base - (mask + 1) * i;
> > +        pdx_pfn_lookup[i] = pfn_pdx_lookup[idx];
> > +    }
> > +
> > +    printk(XENLOG_INFO
> > +           "PFN compression using PFN lookup table shift %u and PDX region size %#lx\n",
> 
> I'd drop PFN and the latter PDX from this format string.

Ack.

> > +           pfn_index_shift, mask + 1);
> > +
> > +    for ( i = 0; i < nr_ranges; i++ )
> > +        printk(XENLOG_DEBUG
> > +               " range %u [%#013lx, %#013lx] PFN IDX %3lu : %#013lx\n",
> > +               i, ranges[i].base, ranges[i].base + ranges[i].size - 1,
> > +               PFN_TBL_IDX(ranges[i].base),
> > +               pfn_pdx_lookup[PFN_TBL_IDX(ranges[i].base)]);
> 
> Do you really mean this to stay active also in release builds?

I had it guarded with #ifdef CONFIG_DEBUG initially, but later decided
it was worth giving the possibility to print it in release builds if
debug log level is selected.

> Also the outcome of the earlier loop isn't used by the intermediate printk().
> Perhaps join both loops, thus allowing idx to be re-used here?

Hm, yes.  I wanted to first print the message about enabling PFN
compression, and later the compression specific information.  I can
move the message about enabling PFN compression ahead of the loop.

> > +    return true;
> > +}
> > +
> > +void __init pfn_pdx_compression_reset(void)
> > +{
> > +    memset(pfn_pdx_lookup, 0, sizeof(pfn_pdx_lookup));
> > +    memset(pdx_pfn_lookup, 0, sizeof(pfn_pdx_lookup));
> 
> Why not ~0?

Because translation needs to work, if I poison all entries with ~0
translation won't work.

> > --- a/xen/include/xen/pdx.h
> > +++ b/xen/include/xen/pdx.h
> > @@ -65,6 +65,43 @@
> >   * This scheme also holds for multiple regions, where HHHHHHH acts as
> >   * the region identifier and LLLLLL fully contains the span of every
> >   * region involved.
> > + *
> > + * ## PDX offset compression
> > + *
> > + * Alternative compression mechanism that relies on RAM ranges having a similar
> > + * size and offset between them:
> > + *
> > + * PFN address space:
> > + * ┌────────┬──────────┬────────┬──────────┐   ┌────────┬──────────┐
> > + * │ RAM 0  │          │ RAM 1  │          │...│ RAM N  │          │
> > + * ├────────┼──────────┼────────┴──────────┘   └────────┴──────────┘
> > + * │<------>│          │
> > + * │  size             │
> > + * │<----------------->│
> > + *         offset
> > + *
> > + * The compression reduces the holes between RAM regions:
> > + *
> > + * PDX address space:
> > + * ┌────────┬───┬────────┬───┐   ┌─┬────────┐
> > + * │ RAM 0  │   │ RAM 1  │   │...│ │ RAM N  │
> > + * ├────────┴───┼────────┴───┘   └─┴────────┘
> > + * │<---------->│
> > + *   pdx region size
> > + *
> > + * The offsets to convert from PFN to PDX and from PDX to PFN are stored in a
> > + * pair of lookup tables, and the index into those tables to find the offset
> > + * for each PFN or PDX is obtained by shifting the to be translated address by
> > + * a specific value calculated at boot:
> > + *
> > + * pdx = pfn - pfn_lookup_table[pfn >> pfn_shift]
> > + * pfn = pdx + pdx_lookup_table[pdx >> pdx_shift]
> 
> I assume it's intentional (for simplicity) that you omit the index masking
> here?

Indeed.  I can add it, but I think the point here is to explain the
algorithm used in a clear way, without implementation details.  I would
consider the masking one of such implementation details.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 16:50:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 16:50:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1025354.1400962 (Exim 4.92)
	(envelope-from )
	id 1uUTKF-0002iP-QX; Wed, 25 Jun 2025 16:50:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1025354.1400962; Wed, 25 Jun 2025 16:50: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 1uUTKF-0002iI-NW; Wed, 25 Jun 2025 16:50:19 +0000
Received: by outflank-mailman (input) for mailman id 1025354;
 Wed, 25 Jun 2025 16:50: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 1uUTKE-0002iC-FP
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 16:50:18 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20617.outbound.protection.outlook.com
 [2a01:111:f403:2417::617])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 75b67389-51e4-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 18:50:13 +0200 (CEST)
Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
 by PH8PR12MB8608.namprd12.prod.outlook.com (2603:10b6:510:1bc::9)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.38; Wed, 25 Jun
 2025 16:50:08 +0000
Received: from PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264]) by PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264%4]) with mapi id 15.20.8857.022; Wed, 25 Jun 2025
 16:50: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: 75b67389-51e4-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=w15h2qnXBKAfxpFJQ3ywpyXUMDXdk3GKE/ocw70gj8XGoDTxYpAq3W1D19ur4fs5UEmLrRqw0W39f9jnnQ0q+5E7qXsxIRogUcnGz6hmSyCr2zBqiZPim7XD2q7m1s+ufC3IgveZ1jYE+LXWZ7YuanU92iM1x3HlGxJ+qfFt7FgHUu+Vf+8mo7GXcS0Wx6s2P1cwVt38IC/DkA8T9hYd3p0f+wdx9OZrYscTolFbSsDOaBYNPOVnX7LJYNukj1xGN+xjTxMfK3V6kqYe1RRUflExUspoW6cYaw2MYCfCzLV4QREBZ7bF1C0+vYrqeqaVszS0GgMUHoB5T/ZOxAKO8g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=O+YeSWqwHsVG8icKv48d0Goii6UbM+lf2kEgO4NeEt4=;
 b=bJqRuibgvP9FIYwrVxGGvERbrkUlflUguEU69dmCabS0Kzrj0njIi+/QV5EupmW6fP8nwtzBk/Mrz+6OmOSrKUVrgxor1vdb6xieluuPPixD8V8bwcvJ9Zx6kaswz/DKLTJOdnDmM5RnpLvMz2rALhtBOeLzSOR5MJhnjz04SVOfldnOFHyIgVFBGohrfmVjY9Qsi3Rb0lCJWYHI9GmaY0ceQeS9cJww3WZIkunXrj+5On1sazeHNrfUQ9GZY7+okHFjJH7/IrOHjSZt7Twjl0/zSIaufIetMs7vXApXXzw7guHq4ZIhKbenVMfZ6+JNesH3g6r+xIeOCAiCta6Q+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=O+YeSWqwHsVG8icKv48d0Goii6UbM+lf2kEgO4NeEt4=;
 b=nQUfxvQCH2YghVpvKhSwx0dfnhw3Am5ipIsaTYmdzr7atq1pdn0xkSK6SujjPvqDc7Y5Uv9eBMBgs2aso5UWH9SQMhEuutYjEoAbXxfogW0UsAlIIM1emV31XCq35SsCClYMFdrsscWvD+ct3Q6DKsSdls9fyxg+6ZHHZ348cHQ=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Wed, 25 Jun 2025 17:50:04 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 4/6] arm/mpu: Destroy an existing entry in Xen MPU memory
 mapping table
Content-Language: en-GB
To: Hari Limaye , xen-devel@lists.xenproject.org
Cc: luca.fancellu@arm.com, Penny Zheng ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk , Wei Chen 
References: 
 <95cc28af74339ea617081f3935123e38a53cc657.1750411205.git.hari.limaye@arm.com>
From: Ayan Kumar Halder 
In-Reply-To: <95cc28af74339ea617081f3935123e38a53cc657.1750411205.git.hari.limaye@arm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: DU7PR01CA0027.eurprd01.prod.exchangelabs.com
 (2603:10a6:10:50e::14) To PH8PR12MB7326.namprd12.prod.outlook.com
 (2603:10b6:510:216::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|PH8PR12MB8608:EE_
X-MS-Office365-Filtering-Correlation-Id: 01644961-59e7-44ef-1c7e-08ddb40857d1
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?TVhOR0RFYmdCWGtUci9sb1Q5ZG9VN3U3VFJKM21oMk9OY2xEc2VsdEdYY3k1?=
 =?utf-8?B?QjBKdFJUekgwL3dtbUFjaCt6WjZkTEFDVmNKcnd6aW9ZUkxEMUNkQTdydHUr?=
 =?utf-8?B?elFaTi9WenJ1NjdRdmtJZkNSWnZEdkxUY3RBN3NxZGZna0puYkpUWHB5Nll5?=
 =?utf-8?B?WlFjcmhHU2w1aHNFeFpHKzhBZ1NJd2NtTDNOUnFkTDMwV1RyZjRwRzZlbDRJ?=
 =?utf-8?B?cTFvUDJRTUJzVnNKdm1BdHJ4T3pJRDVLUitpT1R2S2p0VUEzak96c29pL0s5?=
 =?utf-8?B?ZXhwb0I2dDB6TTdjN1dRMHRsSkpDSFVJMk4xRjMxOC9BRmZzY1MwdkJScjI0?=
 =?utf-8?B?a1J0OE0raHNsS1hRSE5ERVM2MG1WS0JmTXMzSHYzMzZKdEFMRXhaVkVXMTMr?=
 =?utf-8?B?cEIxSDVma0JkZk4xb1gvMVBEZXplUzB2MVhTekgyT3NmVUZnM1lyUHNTZ21Q?=
 =?utf-8?B?VUkrMnk3Ui9KL0RGYlJ4VDVYd05raVpLeEpsUis1bDIvL244NWl2azRxWnFC?=
 =?utf-8?B?VS9NRGlhOFpDdXhleXlzMkhmdVdEWWFZbzNKbUVxdjNOb0hLSmpmQUxKVk54?=
 =?utf-8?B?ZkFvU1ExNXU2SUErK0FGdTJ2b2wxV0tGR0xCZDc3NDhkcVdMTlVOU0lLbDRp?=
 =?utf-8?B?ZnkzU1RoRUYxWTZkQUdJWWJJVEthTmFmc1NrTU16SzZsK3hWNk5yQzd2UnZu?=
 =?utf-8?B?WWJ3ejdjOFhjWDJwaGt3MkVKaTBFUXpwdXhZV2tQSnN5OWExZzJMTDE4OERt?=
 =?utf-8?B?My9BNElsYUFWRzhlSS9odnNhUk5hVzJvdzJaQTE5QS94QzN6bUc0dDZYUkdV?=
 =?utf-8?B?QkNlNlc3d2taL2tGTkNoMjZ2Q1R6dENkNHUrUzh2NzJ6aFpGYk54ei9Ob0tZ?=
 =?utf-8?B?S3drcXplWklaek1WNGxGMy9vSzlMMjVOd1Q3eFdseEI3bGZIcUNObjYzSDU0?=
 =?utf-8?B?RHFHcXg1Wk1XYzVOZWJDRXg3dklsbTlvSnFaUnpEdk5xb3ZvWmd1MDlGTUts?=
 =?utf-8?B?eVhKRU9jaEJncTZ3OW5oRTIyMFJvM2k5T09vcXhvWUZaS3c2QlpKMi9oUWVB?=
 =?utf-8?B?dmNCN0RDYkhLeDJINGxYSHpvaU9YVk51Z2xYM29TQS81WDMyV3lhSGdCN0dQ?=
 =?utf-8?B?ekRQdnZpRWlYZ0t6SGp2VlhFRWlwMWpIc0VQanI1RURBMmVkZGxVbHFpN2p5?=
 =?utf-8?B?Q0NKUm1wL3M2elpZUFZVUXpZRGZJcDNpMWpVRVZvVm5VR0dvdU43ZkwwdVor?=
 =?utf-8?B?YmNDc0UwaWMxbjlxUzhXTHdPTlFKeDJCd2pSZktPejhLc29xZDdEeko5ZWZN?=
 =?utf-8?B?QlcwRG41RlFwSXRXWEtjSU1oRndCODFpZERCMHRrSUMxQTgwZXBBY2lJbFNJ?=
 =?utf-8?B?eWx4NFlRczNKQTJRL0N1NVVXMzUwWWNiRG9vWlBMVks0TjVOR2U0SkJhKzdT?=
 =?utf-8?B?c2IrWk5vbGNSSVh6cFFZQnprRGt1NU9JbTFPNEJqa1hVanlzYVI4VmlLdEZi?=
 =?utf-8?B?LzN2SGdncG0wVzJSRE53NXZNWWhVZnNUVklRek4rVDlBcjN3d3d0U2pwVWJD?=
 =?utf-8?B?ZkFGYWZZTnJhVXhIQWpFczBzSkdqeTRTSkV1ajVQVjExVWFQSmhHYkJVQWZ5?=
 =?utf-8?B?N2hrdmorYWd0bkZVSGJBMVR5YndQVDN5aFFQM2xEa25sZ1duZGlBK1lpUWZq?=
 =?utf-8?B?SDdEL3JmZjhZMHI4Qjd3b1h5Y2ZsbWtHUGFzQ096aXlLdkNEUTRuaDJaN28x?=
 =?utf-8?B?OVNxd3BHSWsyUDdUeXFDQjF1ZmZTZ3VOME5yUXl1aTdTbG0zazA1NVJ6ZDdE?=
 =?utf-8?B?dFBlaG55anBnWmcyalBaOGQ2L2N6K2hIUnNnVUdMaHExbktSMUhSWFZyZkNp?=
 =?utf-8?B?YjhlQW1WTEtrS2tMZnA1NU1Mak54MjRDb1hteHpJcGg2Z3RPOXhWR2hwZHBh?=
 =?utf-8?Q?WLsRQo96pUE=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)(376014)(366016)(1800799024)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?Mkh2bEFqZWt6a0czbFJ1YVBMZlYwSmZ1TVk3bGo3RnMreU1BRGJKUVdTRzVy?=
 =?utf-8?B?MnBoSVJ4QVBzdUNCdTY2UU83SjFhQWNWMXNHM29QR05oVmozdFliWnZ6SDlx?=
 =?utf-8?B?YTJWaGpyS1IzQkpjdGZGaFAyMElyWVB4bUIxUm10M2t5bW0rL0lubXhxUzUw?=
 =?utf-8?B?YzhxQnd5RmJyTDN4QkFDZGY2NTNSTEh3aG8wQ3h4Wk1KaGtMWlJxUVBiblhL?=
 =?utf-8?B?ZVpoWFV3SUtmeUw5Slg0M2JUWEp4UG1RZHpOaDlCRmc0QTYvL1k0OE9leHcr?=
 =?utf-8?B?SWZaWVZZeVcza1U3c1kyM2Zqc0pPNWtwTlBxS2pyQnQxVFZRTG1TYTBjNWVh?=
 =?utf-8?B?VnBhalBZNEE1TXpaY1k2T3l5eVVKRXBhMEF3L0h3d3Z4QUxsYzFkN2I4SzV6?=
 =?utf-8?B?Qk5vdnFFQVEzNUFIL05DNlZyRDVTbmhBeEhFZHM2ZUp1a0E4RFZPY3RKZ0Jk?=
 =?utf-8?B?eS83QzB6TEhkK0R0MSs4QkgwN2ZMQ0JDT21OZ25TYTFNZ1hVdUpuNUVCUzFx?=
 =?utf-8?B?RnpTYWtBWG0ya0MwNVd5RVo1VEJGVzNGTlppY25YWXpEakZjMnVYNTAvS2Jy?=
 =?utf-8?B?ZFoxb1hBZUFMQk01SEZoNTlOaG1LT09LOVVUWmdXeFZGa2U5WmFDaDB4cHNT?=
 =?utf-8?B?bWZmYlhPNmEzZE9IZEVOYUwvcDVxV0x1cTV1cktJTUYxT2g5UlpPQVhhSHJn?=
 =?utf-8?B?RDBIMDhOb3haZWJRSiswUTN2WVBRRDQ1TS9WWFV3VjRKTVZ3dUZwN1VOTks0?=
 =?utf-8?B?L3BXajljTXpRa0VpR2VVVk9tSlNzOXRmbW5TUjZ0NzlidVo4RHZXbm5jblJO?=
 =?utf-8?B?bW5xWkhxZjh5Tnk1dVU0dGx3WGg0YVh2ampkQnpSV1JRQ2JJeDlnQTZCWGE4?=
 =?utf-8?B?SmVkL0JmL3hPdHBvc1ZOMHVyNDloTWZLWnhhYmZrTzBnMVZleUptdXB2SmtU?=
 =?utf-8?B?S1VNSWh0MlpvSHNmc3FGcjhZTEpwcTdjV3p4MmdYNHUyZ2RSK1lYSGl6dFAx?=
 =?utf-8?B?ay9SREV4TitGcE1LOEZPKzRDZUpyQzQ4akNnUjFRN3ErUmRvNUloZXRycWVo?=
 =?utf-8?B?NFpscGdseDJ6MERYSWpRVDA5MkxoLzgrK1NtcDdlaE55NTdZVGdKTHgwN1V6?=
 =?utf-8?B?OC8yMnlQZDhCYUk5MDBHRU10WFBQcVMwanpoVmhpL0l2czNlanhwRzVkcHB5?=
 =?utf-8?B?ejJjZ0xRUXdkbXMvSlZxQ3oyWDgxdmV5Z2trMkhKMkdWT0s3a1dkVlBDRUtI?=
 =?utf-8?B?RUV5dHZUc2l4QXJvWTdjVXhRMHIrNHc3K3VqMlNxTEZYdldHYlBYOGZoUndr?=
 =?utf-8?B?UFg2dW0yZ0xQVG0wb0dQYXRJdUQvOTdPQWhIZlZWTURwYThpNVF1ZlltYWQ5?=
 =?utf-8?B?TU02WXd0RUUxQnUvS3g5MmluclUwdG13MFZlTWN0ejBkZE1vQ3lubjJHdHdC?=
 =?utf-8?B?bnhwZnZjUTBhdk5TekhKWVcxOU1QUEQ2a2d5ZG9zUDA2Y25DSHVRU0tPY2Ix?=
 =?utf-8?B?MnRNenJ2MVNxMFlRK2pzWk15V0U2YVZQeFpiQ0tIUXAybHNaWGJOeW1yclFM?=
 =?utf-8?B?b1VDMTBUY21sb0VQZFBhZ0g4VHc0Ni9hcDRvOWV4WUxnQjhpRUdyZDVvN0Zr?=
 =?utf-8?B?dnIzbU5QbkF2dGZtNkYxL1czUzZHU2QraFpTMjZPQkdtNnhkSVJaSzllaHhq?=
 =?utf-8?B?Tk5mejVnbng0L1ZvdTFFVnBnNmNSL1hyeC9LbDl3MEhJaDFZZEpHRnZNNVpk?=
 =?utf-8?B?eXgzbjY2STdqNFRzQ01hTnhlVmhxbHVvTW91UFBCdmhWNzZTSGJpaXllNTVP?=
 =?utf-8?B?SGRaYm5LbFJrb2g2WS9KMWZ3bmRwOUJmMzE3SDVaNGhGRUorOXJNYkJBZlRw?=
 =?utf-8?B?OWdmVi9URUcrZVp4a1ppYWtDak9NYlNrOEtxbWZMMmVxdm50L0hOeXp4OFgy?=
 =?utf-8?B?czdyOFRzMm1PVGV5MzBwcEtFN1dVUUVmRTh5RWw3eDdic29SUFJiQS9MVlo3?=
 =?utf-8?B?eGxrei8walNmcGh2dm9Pd0sxUnBYN3YrWG5Gd2p6RlZvb2tZelNCYytNbklj?=
 =?utf-8?B?b1Y2RWJXUTNGMlZKSVJCMzdWTFFOTmRYd0d4SkpkZFJmVnpxQTNxYWx6V2px?=
 =?utf-8?Q?v0mFvgrURXTcVv+17eTZWQwlp?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 01644961-59e7-44ef-1c7e-08ddb40857d1
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jun 2025 16:50:08.4327
 (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: HqkgNey2/9SJzxeF9P+cnRKiELLwE4NRaX6+uayvbs6QJnbiu3/e2/+BGG1Rc5k6kQg+h+r5y+ryi0hePkzBpQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB8608

Hi Hari,

On 20/06/2025 10:49, Hari Limaye wrote:
> CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email.
>
>
> From: Penny Zheng 
>
> This commit expands xen_mpumap_update/xen_mpumap_update_entry to include
> destroying an existing entry.
>
> We define a new helper "disable_mpu_region_from_index" to disable the MPU
> region based on index. If region is within [0, 31], we could quickly
> disable the MPU region through PRENR_EL2 which provides direct access to the
> PRLAR_EL2.EN bits of EL2 MPU regions.
>
> Rignt now, we only support destroying a *WHOLE* MPU memory region,
> part-region removing is not supported, as in worst case, it will
> leave two fragments behind.
>
> Signed-off-by: Penny Zheng 
> Signed-off-by: Wei Chen 
> Signed-off-by: Luca Fancellu 
> Signed-off-by: Hari Limaye 
> ---
>   xen/arch/arm/include/asm/mpu.h        |  2 +
>   xen/arch/arm/include/asm/mpu/cpregs.h |  4 ++
>   xen/arch/arm/mpu/mm.c                 | 71 ++++++++++++++++++++++++++-
>   3 files changed, 75 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/arm/include/asm/mpu.h b/xen/arch/arm/include/asm/mpu.h
> index 63560c613b..5053edaf63 100644
> --- a/xen/arch/arm/include/asm/mpu.h
> +++ b/xen/arch/arm/include/asm/mpu.h
> @@ -23,6 +23,8 @@
>   #define NUM_MPU_REGIONS_MASK    (NUM_MPU_REGIONS - 1)
>   #define MAX_MPU_REGION_NR       NUM_MPU_REGIONS_MASK
>
> +#define PRENR_MASK  GENMASK(31, 0)
> +
>   #ifndef __ASSEMBLY__
>
>   /*
> diff --git a/xen/arch/arm/include/asm/mpu/cpregs.h b/xen/arch/arm/include/asm/mpu/cpregs.h
> index bb15e02df6..9f3b32acd7 100644
> --- a/xen/arch/arm/include/asm/mpu/cpregs.h
> +++ b/xen/arch/arm/include/asm/mpu/cpregs.h
> @@ -6,6 +6,9 @@
>   /* CP15 CR0: MPU Type Register */
>   #define HMPUIR          p15,4,c0,c0,4
>
> +/* CP15 CR6: Protection Region Enable Register */
> +#define HPRENR          p15,4,c6,c1,1
> +
>   /* CP15 CR6: MPU Protection Region Base/Limit/Select Address Register */
>   #define HPRSELR         p15,4,c6,c2,1
>   #define HPRBAR          p15,4,c6,c3,0
> @@ -82,6 +85,7 @@
>   /* Alphabetically... */
>   #define MPUIR_EL2       HMPUIR
>   #define PRBAR_EL2       HPRBAR
> +#define PRENR_EL2       HPRENR
>   #define PRLAR_EL2       HPRLAR
>   #define PRSELR_EL2      HPRSELR
>   #endif /* CONFIG_ARM_32 */
> diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
> index 1de28d2120..23230936f7 100644
> --- a/xen/arch/arm/mpu/mm.c
> +++ b/xen/arch/arm/mpu/mm.c
> @@ -199,6 +199,42 @@ static int xen_mpumap_alloc_entry(uint8_t *idx)
>       return 0;
>   }
>
> +/*
> + * Disable and remove an MPU region from the data structure and MPU registers.
> + *
> + * @param index Index of the MPU region to be disabled.
> + */
> +static void disable_mpu_region_from_index(uint8_t index)
> +{
> +    ASSERT(spin_is_locked(&xen_mpumap_lock));
> +    ASSERT(index != INVALID_REGION_IDX);
> +
> +    if ( !region_is_valid(&xen_mpumap[index]) )
> +    {
> +        printk(XENLOG_WARNING
> +               "mpu: MPU memory region[%u] is already disabled\n", index);
> +        return;
> +    }
> +
> +    /* Zeroing the region will also zero the region enable */
> +    memset(&xen_mpumap[index], 0, sizeof(pr_t));
> +    clear_bit(index, xen_mpumap_mask);

NIT.

These 2 lines we can move before the if { ..}. So that the region is 
zeroed even if the region is disabled. This will add a small overhead, 
but we will be sure that the region is zeroed whenever it is disabled.

> +
> +    /*
> +     * Both Armv8-R AArch64 and AArch32 have direct access to the enable bit for
> +     * MPU regions numbered from 0 to 31.
> +     */
> +    if ( (index & PRENR_MASK) != 0 )
> +    {
> +        /* Clear respective bit */
> +        uint64_t val = READ_SYSREG(PRENR_EL2) & (~(1UL << index));
> +
> +        WRITE_SYSREG(val, PRENR_EL2);
> +    }
> +    else
> +        write_protection_region(&xen_mpumap[index], index);
> +}
> +
>   /*
>    * Update the entry in the MPU memory region mapping table (xen_mpumap) for the
>    * given memory range and flags, creating one if none exists.
> @@ -217,11 +253,11 @@ static int xen_mpumap_update_entry(paddr_t base, paddr_t limit,
>       ASSERT(spin_is_locked(&xen_mpumap_lock));
>
>       rc = mpumap_contain_region(xen_mpumap, max_mpu_regions, base, limit, &idx);
> -    if ( (rc < 0) || (rc > MPUMAP_REGION_NOTFOUND) )
> +    if ( rc < 0 )
>           return -EINVAL;
>
>       /* We are inserting a mapping => Create new region. */
> -    if ( flags & _PAGE_PRESENT )
> +    if ( (flags & _PAGE_PRESENT) && (MPUMAP_REGION_NOTFOUND == rc) )

Same question in this patch , why do we need to check for _PAGE_PRESENT. 
Can't we just rely on MPUMAP_REGION_XXX ?

>       {
>           rc = xen_mpumap_alloc_entry(&idx);
>           if ( rc )
> @@ -232,6 +268,22 @@ static int xen_mpumap_update_entry(paddr_t base, paddr_t limit,
>           write_protection_region(&xen_mpumap[idx], idx);
>       }
>
> +    if ( !(flags & _PAGE_PRESENT) && (rc >= MPUMAP_REGION_FOUND) )
> +    {
> +        /*
> +         * Currently, we only support destroying a *WHOLE* MPU memory region,
> +         * part-region removing is not supported, as in worst case, it will
> +         * leave two fragments behind.
> +         */
> +        if ( MPUMAP_REGION_INCLUSIVE == rc )
> +        {
> +            region_printk("mpu: part-region removing is not supported\n");
> +            return -EINVAL;
> +        }

NIT.

Can we keep this ^^^ outside of the outer if condition ie "if ( !(flags 
& _PAGE_PRESENT) && (rc >= MPUMAP_REGION_FOUND) )" ?

> +
> +        disable_mpu_region_from_index(idx);
> +    }
> +
>       return 0;
>   }
>
> @@ -261,6 +313,21 @@ int xen_mpumap_update(paddr_t base, paddr_t limit, unsigned int flags)
>       return rc;
>   }
>
> +int destroy_xen_mappings(unsigned long s, unsigned long e)
> +{
> +    int rc;
> +
> +    ASSERT(IS_ALIGNED(s, PAGE_SIZE));
> +    ASSERT(IS_ALIGNED(e, PAGE_SIZE));
> +    ASSERT(s <= e);

Can we have these asserts in xen_mpumap_update() as well ?

> +
> +    rc = xen_mpumap_update(virt_to_maddr(s), virt_to_maddr(e), 0);
> +    if ( !rc )
> +        context_sync_mpu();
> +
> +    return rc;
> +}
> +
>   int map_pages_to_xen(unsigned long virt, mfn_t mfn, unsigned long nr_mfns,
>                        unsigned int flags)
>   {
> --
> 2.34.1
- Ayan
>
>


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 17:02:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 17:02:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1025376.1400996 (Exim 4.92)
	(envelope-from )
	id 1uUTVa-0004m4-1m; Wed, 25 Jun 2025 17:02:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1025376.1400996; Wed, 25 Jun 2025 17:02: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 1uUTVZ-0004lx-VP; Wed, 25 Jun 2025 17:02:01 +0000
Received: by outflank-mailman (input) for mailman id 1025376;
 Wed, 25 Jun 2025 17:02: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 1uUTVY-0004lr-NO
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 17:02:00 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20609.outbound.protection.outlook.com
 [2a01:111:f403:2417::609])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 19f1898c-51e6-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 19:01:58 +0200 (CEST)
Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
 by BY5PR12MB4241.namprd12.prod.outlook.com (2603:10b6:a03:20c::9)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.25; Wed, 25 Jun
 2025 17:01:53 +0000
Received: from PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264]) by PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264%4]) with mapi id 15.20.8857.022; Wed, 25 Jun 2025
 17:01: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: 19f1898c-51e6-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=n4IZV4Pwye0gXgKk/cWu1NFcRnWOiD5Gj1tTpDrk6CjGzpnMhdmwSypAYhxffu3b1/iZ7rzdwJ6QtOoRGwZwF8R8StvrpoSArW6f4C2JgJSnvCI5MTCrWnTElhsg7COce5/OOuJfW++G8V30PtNsyPYKRdcWOfzcLNxiY1LHywhIct3rDc5USCqUSYJe6b00wbX6b392AcMT16KnsAHXN8evzyQU9vQTbl0+c+Xc+vjCdPJaiXMQSZB32zpqLpjPDZ5kGGqXlQJ0PoPZOiysVJShCrrR8sjfsB5cCIQi9+gr/5IMZr7Xahk+njmGqrfHV/SnMZIiBccytrKOAaaqMA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=fe1jM1HvCbwC3yXV3AUQFdoOhEPHhPFFFzyAW0fJZLc=;
 b=FlXenz5Nyy2CuHqgrtP+hvcSxFw7O1fnVO6X4IJziz6n8fVH5DodMK6qmmfsUg1ASRgRjuRZzKx3H2wRTgBjnoJog2cK9VCzf4flCpHK0pKRf2lqDFYmX7Qaq3dyrd4goHZ05rseoSsiSIH4PlX33S0H97DzWTTZD2YAZxot5RCopyQ6mS9SNoeh3wLJkolWiUluM2LE9jSUhMBuJPtJEDxCcq6+JC3N3o+fajIjC1FeSBOEmBtmJcS2XH04h9uebCNQNxxVtGnHuyqBWBF2NP2uTGkuOd6vwDeS3BL/laUK1dDNjRJhJkEJvU6lM5veAtLIqnBC3TOmRzoCiNwEyA==
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=fe1jM1HvCbwC3yXV3AUQFdoOhEPHhPFFFzyAW0fJZLc=;
 b=kAj5sbz6alANGwUF/a8+fOw4GbPWlnl1Lv3XKnwCGhGoHiNaRGzsh3BUkgpHDFGMDvtKH2z6z1MMx9TIXdNgPrAlzf35633WcM+/wH5G1e5/DLFuZlmxNHzgisQABogNm3QK1sr9TFpA8Lv01/vUJaYphdH7mla+c+tCBKYls5g=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Wed, 25 Jun 2025 18:01:49 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/6] arm/mpu: Find MPU region by range
Content-Language: en-GB
To: Hari Limaye , xen-devel@lists.xenproject.org
Cc: luca.fancellu@arm.com, Stefano Stabellini ,
 Julien Grall , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: 
 
From: Ayan Kumar Halder 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: DU7P191CA0002.EURP191.PROD.OUTLOOK.COM
 (2603:10a6:10:54e::31) To PH8PR12MB7326.namprd12.prod.outlook.com
 (2603:10b6:510:216::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|BY5PR12MB4241:EE_
X-MS-Office365-Filtering-Correlation-Id: c08be669-2ff4-4096-1f51-08ddb409fbfc
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?Tmo4aFRSSlZNR21Pd1ZsTUxDTW91MkpOdnNtRTQ2UUV1ZXlzdkhrUHNHUUNz?=
 =?utf-8?B?VGhYTXNadEwxTmZOMGk4aDhveG1BSmdlOHdVb3ErTjVjNnFmc3MxZnRFazJF?=
 =?utf-8?B?ZFlQc3c1WE1WSUVOZmJLcFg0NkJxNm1QWGdTY1phNjlqVkNnWkZ0dWorWHZl?=
 =?utf-8?B?d3luOGdKVkxMVVMrV2FlMzhVMkt3Qjd3V3Rob1pobmhocnBNdVRnU2ZiUEtT?=
 =?utf-8?B?NVJhZW4xSjRMYklmT2t2L0dMQXlGeVNiU29FNUdjczhYRTdqK0NXcVFNbXhj?=
 =?utf-8?B?ekxLRXpteExqM0JwSE83ZGQ4dEthV3F3UW9KczdQdTg4cGdrYkRZMVJMakFr?=
 =?utf-8?B?YitYb05saTN4WUhBbklQaDl3b0djSWs5aUpzMlZNMGJtWDZlWGduM0JWd3My?=
 =?utf-8?B?bExEWEgwN1duY3RncHA5aDN0cHkwZEd1dGNaWGF5YUFJenJUWWFmcExXWTBC?=
 =?utf-8?B?bGRBaDdtTkExZ3ZDdEcwcEc2UGMrU3lMSTMvWTRZRHJ1M2tVeFExbmg0dndI?=
 =?utf-8?B?dFBYeU15Q2pwQ1cyUTQxNDdVVDM4aU9KMG54K1haV0F5anAwY3Zoa0xCSDNM?=
 =?utf-8?B?YlduZFlwNmpKVm5QR21uOHdsMlJ0eENwMENDT2pQY2UwYU1PT2NrTjVPZ1dp?=
 =?utf-8?B?dkE5cVByQllzajJNdisxYVprdEZEd3pqZE1GRWx2VGNPL3hhcTBYWW9mV2dH?=
 =?utf-8?B?NXdIaXhERGJqVFRqNjliRXVSZks3STc3QVFPbWxYUkRUV2c4YWZEK0lNRWVJ?=
 =?utf-8?B?MzNVSUwwczlhd0hRY1lDbWxPcVJCQ3hyaUdwM05qNFV5Q0tReVZhbHN2TjhO?=
 =?utf-8?B?Y2dJVUlDcXZ6NTJyaGh2STlpT25ReGJZMWdlclo4U2p2VWtXUGY2QzJEcGhI?=
 =?utf-8?B?Z3FlMHNRTHJEa1Ftc0I1L0E2WXFOSzUzK1BkVjI1TFBKdU9kdXZBNzJrUWVW?=
 =?utf-8?B?RjB3dmdqbFY4K2M5MEdHZGIwcjJZUkVnNnByWGpGeHN6ZTQ4VVU4WE9GYStv?=
 =?utf-8?B?dWtnR3JsbWFHNzRmZWk2cmJmUHRFS2hRMFFsTG91c3pZN3NEK21YZG9tSnFr?=
 =?utf-8?B?bi96dUxHWWk3MmJLOHVXQ2RDM3I3eGwxV1dRMzdUdnFkbXhnczdpMXNWSDZa?=
 =?utf-8?B?RExCR04yekxMZUtoN3g0S3Vlb1lHdmp2aU44L0NPZklTaFMyZTNibnNRZjll?=
 =?utf-8?B?R0Z0TWNsYXlFTXRYYUM5NVpyRFhmeCtXcmc3TGFxNU5OVnR6eFpzVENaSW80?=
 =?utf-8?B?ODYyUFhrSkZZNUhXblBzTk5OL25zelRMc3VlOVJ5VUYzdkQ4b2UyZkJ5Rmtp?=
 =?utf-8?B?c0xuWmROL0ZFc1o2RlpTZmU3NW9Tazc0aHVCV0o2Q0pIOVF0U2NYNFpnZ05U?=
 =?utf-8?B?ZzlDTGoxMjdGMHRCY2Z3UlU5cFFwdVhCZHM1T0h4R0JidlV0ZnFrT0c2aWFT?=
 =?utf-8?B?N0R2dXZ3eUw5cERicnZKUHEvbFNKNjBrbmdOdEtDRTBBbHR2cVJ4ZmNhNXVS?=
 =?utf-8?B?ODBycUFyUk5lUHgvSDBIUnVXc1hjK2FWWGc1MTRKelVsTFp6ZkpCUW5wYXlu?=
 =?utf-8?B?cUVZYVpMUWs4Zzdxa1dhSnM4RVdyUmdVUk9SQnBtb01TSGlKRnZrVmJISHE5?=
 =?utf-8?B?azlSV2o2TjBIL204VWpZM3ZXOUlRcm1KN1VqZ3JXSmR1eXNHbFpEemlhSlNT?=
 =?utf-8?B?Tno3UnpzcGk3MEd6Q2tvK09sOE5kZE01YmxLei9BN1N5cEw1M0hzVmFIL3Bz?=
 =?utf-8?B?NThsakJJaW1MQ3cxWmtFenBUQzFGRC9YVHUyNVJOcTZuZXEwV01kNzF6MTZT?=
 =?utf-8?B?Kzc3d3hjWXhOdFVadi9Gb252NGJnZEhxYVNkSWFNdVZIR09uRXJUQ3VLTG5r?=
 =?utf-8?B?bkZkekoxUFJaWkFDbDR0YU0rRkRvaHQ3RlRoNURjSWd4V2xXeWZuRGZFcVBq?=
 =?utf-8?Q?g6HxBWZNXk8=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)(376014)(1800799024)(366016)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?OWhXV2llMHhVS0hsMjlIcDFxQzArWWhYOTlENUx0TDJNb3JlZGZUdWU1SDJX?=
 =?utf-8?B?cnBPR0I3dWV4L1kzaE5LWFJpUWtVdkY0SXNzbXZzZ0RCZGszNmtRcHpSa0da?=
 =?utf-8?B?VFduZk0xaWZ6UlV6Q0E5bVNsR0RDcmY4OEw4OHZCV2ttVWJxaE1NdEdZbTNF?=
 =?utf-8?B?YjQ5akdrbmhWejZNYVJybm1XM0tIa2l6MlZSMGw3eDUwSm91d2VPSStZYzNk?=
 =?utf-8?B?ZzZwYWpXK2IrbjNlTkFNLzFRTFR5RG1jdkE5eDluWTBKS2p6eUs0M09TbkJ2?=
 =?utf-8?B?TkFjelhmV3JUeGE2STRRMGdLSlVyZW4xWVI5WkNzWTAwZWcwR2MwVVZTaldO?=
 =?utf-8?B?aVZBK3NyamxCOFVmRW85TmhyNjJrVFlOTWdHaTNabEV1RVYzVHdKWnNJVXdD?=
 =?utf-8?B?c2JGWHFCUUxqNkVzSVg2b2lvb1NwOHBJQjV6Umt5TWs2SkxIbmFHSnZYQU9P?=
 =?utf-8?B?RjUzVGxoZy9lTCtJekNsMEVVTUxXN3p6c2hHSjhsODRiOE5oMzdXM0tGSFYw?=
 =?utf-8?B?OWZjd01QdnJ4MmpXc3NTdFVhVHpsaFVYUWxXZDN5a002WVJVN3lIYkREN00v?=
 =?utf-8?B?b3M4RkZvaEZsRWJHUjhjdm1ScnFzejhOb2tLVDVudS9idFFEME1FaHd6cEJC?=
 =?utf-8?B?WGJ2Qnk2ZDZWWXk2K3R3MHNmbTBQcmZubjJsQm9kSDMyb0U3S292L290KzFV?=
 =?utf-8?B?WHhZcW81WFlsZ1k5K0J3NFNqUVN2RzlhNkpaSVVMWDJ3R09hTjBOaEdNcmVR?=
 =?utf-8?B?YTFFR0ozdWM0YytpcnV4elNVYW1aY01hanRRQTNQVDJwdjEweUVLd1dyTldL?=
 =?utf-8?B?V2Jac21xbmc3T3JaWUhReThGOWJVdExVbm5rK2hTMWQwVUh4TzQ2MDBvVng5?=
 =?utf-8?B?TDVGN0haS3JOQzRtajY5VTAraWVwUk1weFM1ZHprK1VnTEdDMFVFS1cvV2xq?=
 =?utf-8?B?Ny93dGVmUVRrYlQrcGlkZXdwdjNTdjFYaC9aMUVIZHpvWUwwWjdlS1YyZ1o3?=
 =?utf-8?B?QkQzak53dUk3RzAvQjV3VFRhSmRiZ2FiU01ycFBTRTlHdERITlh3aEFsb1pz?=
 =?utf-8?B?YWkzRVdBWkFnbk9WdDBmU1pHbjQ2MXNXSTVudWMyb0tKQmJLUFVRNklXcnZm?=
 =?utf-8?B?TzJyUlBsY0JPNjI0MkpRR2pkZ3ZYMW9qY2orMHdvMVhKWE05R0VjcVhHSi9X?=
 =?utf-8?B?YlhGeXA3ekpiNGNOR3hkS1lEa2k1bmRyN2cvdTZNU1BxdDVSeUVuR1NBWnBp?=
 =?utf-8?B?WG5BN2t0cUVVQzh0RTlvcDkwL3IyNWxsVVd6SmhSVUJjd1FScnllNG9ZRXBh?=
 =?utf-8?B?RUZFTVVhOXM1UnBJOXRXZ0Rwck1yTlZrY1NUVUs4M0x1bi9RWVYyeTcrbXNw?=
 =?utf-8?B?bkNrWGlDSjJWZjVDZHBTSVZOQTZ2TmI5bGhKOG9BcXBCUnE1U0RFZGgwL3ZX?=
 =?utf-8?B?TUtmNHBrRGVhc09aQ3ZvY1RiOFJSWWVqQjRsdFd1WFh6ZEJVS1htbURsODdo?=
 =?utf-8?B?T0htUUxXQiszNkpPd1A1cXVoQlNwS3hQamlJVXRPR2czay93TmVqWHZsWnl5?=
 =?utf-8?B?YlM0OGxSVEdSejBsRDU1NFZnanBDTUowR2YwSzBqd3ZUb1FzOU4yRGt0SEph?=
 =?utf-8?B?TE1VcDBTdnBjZWRZN29EMzdXNEVFQjYraC9zazRnY1R1VGUzeFMzRUlsdEg3?=
 =?utf-8?B?YTk2cHE5U0dseldpTDR0elJyOHIrSG5FaDNOcWQzUm5vZldvQUlIN2piVXBn?=
 =?utf-8?B?Qm1BZDAvK1ZBUk9IK1NyNndnRE4zbmpoaTE1bGtEeU45NDhHRWE4aXU5LzZO?=
 =?utf-8?B?aUJGOU1UNWVMb3JqYzcva0RwWmYwcWQveWxwWVNZblRxakU0WUtGK2FtMXcw?=
 =?utf-8?B?dGEra29SUkVLTytZZTRpVkRsVWNLNVFadW43YWtITVZWWERNUHF6bk0wZyto?=
 =?utf-8?B?SHJIb2dxUjN3eWFxYXMyNHFiNVlnc1dsMzlDQUNFaE4wdEMyb2loYm1UUW9N?=
 =?utf-8?B?bzJBWXNldVNHL0htZWE2L1JUYnBsMlJkU241STRsTHhhc3BxQncxZ2hUN28y?=
 =?utf-8?B?eTk2Zm0yeTMwaS9wY1hsVnRBazRvdG0wZ01jNEpFcmJob2M4UjNablFnbEJi?=
 =?utf-8?Q?RC1z1ywjaWvNvA4C87K+Zx19k?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c08be669-2ff4-4096-1f51-08ddb409fbfc
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jun 2025 17:01:53.4630
 (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: PztjZeDwZRu+x3T8DZsp6D3+HWFwJsJqucTIgFBZfDy9tfeY2sc8Iig7F3f7LbcKQc08nXnuzxJtUWsX/pxLJA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4241

Hi,

On 20/06/2025 10:49, Hari Limaye wrote:
> CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email.
>
>
> From: Luca Fancellu 
>
> Implement a function to find the index of a MPU region
> in the xen_mpumap MPU region array.
>
> Signed-off-by: Luca Fancellu 
> Signed-off-by: Hari Limaye 
Reviewed-by: Ayan Kumar Halder 
> ---
>   xen/arch/arm/include/asm/mpu/mm.h | 29 ++++++++++++++
>   xen/arch/arm/mpu/mm.c             | 66 +++++++++++++++++++++++++++++++
>   2 files changed, 95 insertions(+)
>
> diff --git a/xen/arch/arm/include/asm/mpu/mm.h b/xen/arch/arm/include/asm/mpu/mm.h
> index a7f970b465..a0f0d86d4a 100644
> --- a/xen/arch/arm/include/asm/mpu/mm.h
> +++ b/xen/arch/arm/include/asm/mpu/mm.h
> @@ -10,6 +10,13 @@
>   #include 
>   #include 
>
> +#define MPUMAP_REGION_OVERLAP      -1
> +#define MPUMAP_REGION_NOTFOUND      0
> +#define MPUMAP_REGION_FOUND         1
> +#define MPUMAP_REGION_INCLUSIVE     2
> +
> +#define INVALID_REGION_IDX     0xFFU
> +
>   extern struct page_info *frame_table;
>
>   extern uint8_t max_mpu_regions;
> @@ -75,6 +82,28 @@ void write_protection_region(const pr_t *pr_write, uint8_t sel);
>    */
>   pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags);
>
> +/*
> + * Checks whether a given memory range is present in the provided table of
> + * MPU protection regions.
> + *
> + * @param table         Array of pr_t protection regions.
> + * @param r_regions     Number of elements in `table`.
> + * @param base          Start of the memory region to be checked (inclusive).
> + * @param limit         End of the memory region to be checked (exclusive).
> + * @param index         Set to the index of the region if an exact or inclusive
> + *                      match is found, and INVALID_REGION otherwise.
> + * @return: Return code indicating the result of the search:
> + *          MPUMAP_REGION_NOTFOUND: no part of the range is present in #table
> + *          MPUMAP_REGION_FOUND: found an exact match in #table
> + *          MPUMAP_REGION_INCLUSIVE: found an inclusive match in #table
> + *          MPUMAP_REGION_OVERLAP: found an overlap with a mapping in #table
> + *
> + * Note: make sure that the range [#base, #limit) refers to the half-open
> + * interval inclusive of #base and exclusive of #limit.
> + */
> +int mpumap_contain_region(pr_t *table, uint8_t nr_regions, paddr_t base,
> +                          paddr_t limit, uint8_t *index);
> +
>   #endif /* __ARM_MPU_MM_H__ */
>
>   /*
> diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
> index ccfb37a67b..15197339b1 100644
> --- a/xen/arch/arm/mpu/mm.c
> +++ b/xen/arch/arm/mpu/mm.c
> @@ -12,6 +12,18 @@
>   #include 
>   #include 
>
> +#ifdef NDEBUG
> +static inline void __attribute__ ((__format__ (__printf__, 1, 2)))
> +region_printk(const char *fmt, ...) {}
> +#else /* !NDEBUG */
> +#define region_printk(fmt, args...)         \
> +    do                                      \
> +    {                                       \
> +        dprintk(XENLOG_ERR, fmt, ## args);  \
> +        WARN();                             \
> +    } while (0)
> +#endif /* NDEBUG */
> +
>   struct page_info *frame_table;
>
>   /* Maximum number of supported MPU memory regions by the EL2 MPU. */
> @@ -110,6 +122,60 @@ pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags)
>       return region;
>   }
>
> +int mpumap_contain_region(pr_t *table, uint8_t nr_regions, paddr_t base,
> +                          paddr_t limit, uint8_t *index)
> +{
> +    uint8_t i = 0, _index;
> +
> +    /* Allow index to be NULL */
> +    index = index ? index : &_index;
> +
> +    /* Inside mpumap_contain_region check for inclusive range */
> +    limit = limit - 1;
> +
> +    *index = INVALID_REGION_IDX;
> +
> +    if ( limit < base )
> +    {
> +        region_printk("Base address 0x%"PRIpaddr" must be smaller than limit address 0x%"PRIpaddr"\n",
> +                      base, limit);
> +        return -EINVAL;
> +    }
> +
> +    for ( ; i < nr_regions; i++ )
> +    {
> +        paddr_t iter_base = pr_get_base(&table[i]);
> +        paddr_t iter_limit = pr_get_limit(&table[i]);
> +
> +        /* Found an exact valid match */
> +        if ( (iter_base == base) && (iter_limit == limit) &&
> +             region_is_valid(&table[i]) )
> +        {
> +            *index = i;
> +            return MPUMAP_REGION_FOUND;
> +        }
> +
> +        /* No overlapping */
> +        if ( (iter_limit < base) || (iter_base > limit) )
> +            continue;
> +
> +        /* Inclusive and valid */
> +        if ( (base >= iter_base) && (limit <= iter_limit) &&
> +             region_is_valid(&table[i]) )
> +        {
> +            *index = i;
> +            return MPUMAP_REGION_INCLUSIVE;
> +        }
> +
> +        /* Overlap */
> +        region_printk("Range 0x%"PRIpaddr" - 0x%"PRIpaddr" overlaps with the existing region 0x%"PRIpaddr" - 0x%"PRIpaddr"\n",
> +                      base, limit + 1, iter_base, iter_limit + 1);
> +        return MPUMAP_REGION_OVERLAP;
> +    }
> +
> +    return MPUMAP_REGION_NOTFOUND;
> +}
> +
>   void __init setup_mm(void)
>   {
>       BUG_ON("unimplemented");

LGTM.

- Ayan

> --
> 2.34.1
>
>


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 17:25:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 17:25:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1025403.1401006 (Exim 4.92)
	(envelope-from )
	id 1uUTrn-0007lJ-UF; Wed, 25 Jun 2025 17:24:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1025403.1401006; Wed, 25 Jun 2025 17:24:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUTrn-0007lC-RU; Wed, 25 Jun 2025 17:24:59 +0000
Received: by outflank-mailman (input) for mailman id 1025403;
 Wed, 25 Jun 2025 17:24: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 1uUTrm-0007l6-Qy
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 17:24:58 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on2062d.outbound.protection.outlook.com
 [2a01:111:f403:2416::62d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4f301abd-51e9-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 19:24:56 +0200 (CEST)
Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
 by SJ2PR12MB9242.namprd12.prod.outlook.com (2603:10b6:a03:56f::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.27; Wed, 25 Jun
 2025 17:24:51 +0000
Received: from PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264]) by PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264%4]) with mapi id 15.20.8857.022; Wed, 25 Jun 2025
 17:24: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: 4f301abd-51e9-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ABRTcAEew/t39LwpPw9ro6gJZLwQ7X3DXVVSe8Pr4MhfQ33ign6Aqzwo5XpOAAoprcBMap/h0Vwmq7tfxinF4cspXRffH2C1/KCpDgJKmWCo+Cp9ejjT+E5YbbZJwCzFw0daKZjJa09hiF4xoNHck5AD7GNDLw3gulkUR5kt6jxiCLhgp1NVu1N74WOpylX+ULs4aty8Av36YznseoegQ3rTV6IhsZwG9TDRqEv2H9RaNbWBVRgG+OH08g4ZQMTUFbcejBMZZ4h/wwImw7NBvzRWO5H0kFwniqO+21xAnocO5quN0ZoW793dVrV6j5vekYroTFnuC8mKP53vqc0tiA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=38IiDfL3+sgUkD/I3AVMLowzxSszLt0gLmARJVyjBU0=;
 b=i5qUb5716IcUFwrb/IucQf/KDKFnH1/LMBXtldqUaB5r3N9/Sh9J1KgTxdN1/4Lj4W88aVS/LaZZYYqcU9cdGzoxX73h/BSWy0CnPsKRvsle92nYg6kyaD24b8tNSokaeAbcZ4+HGi30B3vabPPGyGmoYXmbKOVynBk2TxTmCEouIInJT0wdFl8DImSHNtPT/DNNYynLqFIKZj6ix4KrZpPDhSrS/31AnDGX9V/oNCLrOM55k13J13fBUwuJMotWGjyWkM9SjUEsos4TYpwCPNqXg9d/B6oJnGWQxHaUK2T1lRUvFdV/V31c9eEfZVRCJkFswfk1GE47gsevXw/ZGg==
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=38IiDfL3+sgUkD/I3AVMLowzxSszLt0gLmARJVyjBU0=;
 b=UuFyGzdo7suOFhf8qsXYk3wHcH3vOLb05z9qEiOibpcH1eWQr4DTl4UhirsVfUvf3xli77Af6DdnBkXipkErKcgQL4Y33rag+DXcBmAGioVe5xsdlQKLnViQZwaR51YnwpR+XPuvpK07AGXin1tIkcSEkyA+60HCREV+GyoGuIE=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Wed, 25 Jun 2025 18:24:47 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/6] arm/mpu: Implement early_fdt_map support in MPU
 systems
Content-Language: en-GB
To: Hari Limaye , xen-devel@lists.xenproject.org
Cc: luca.fancellu@arm.com, Stefano Stabellini ,
 Julien Grall , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: 
 
From: Ayan Kumar Halder 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: DU6P191CA0013.EURP191.PROD.OUTLOOK.COM
 (2603:10a6:10:540::24) To PH8PR12MB7326.namprd12.prod.outlook.com
 (2603:10b6:510:216::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|SJ2PR12MB9242:EE_
X-MS-Office365-Filtering-Correlation-Id: 0d4f51bf-3941-477a-fd84-08ddb40d3112
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?QUs1cHJ1Vkc5SXk4aTIzamhmbFZxMytETm04NlN5cjVsZ1RMd2JpWHdKS21x?=
 =?utf-8?B?LzlDa1ZEZmw2aWV3RDB4Q0lZUHdwZHB0Z0FObytvamhjaTlBejlnUkJZTmU1?=
 =?utf-8?B?UkxZS1BtQjVSZDRLeEJiL1JheFJKYjFnbGpodnl4Z0VNbjJEZ3h0UG4vdEEy?=
 =?utf-8?B?SFVPNHF4VHFhbnVOVkM5a2ZIUEVSOFRjR01SQ1pnN29WaTBPMlBXZFM4VnM0?=
 =?utf-8?B?Z05kd1NobmVzQXdabkFydXJXTzNHY3g4SDBvejlmY2hEd0pLT0VoaEt6bzdu?=
 =?utf-8?B?bnNpRFpTQmdTWjNsMFBJUjgxemhTcjRKSWlVM2lISm40NXc0SlhzVUsyNDVY?=
 =?utf-8?B?TGord05hUmV4T1hJSWFSZ1Rma2l3ZVNkSzJLY3J5N3I2aEJ1T3hkdVNFZEJH?=
 =?utf-8?B?N2lrNVd5d3JxYnc2ZmN2WVl4aGtFZHhsRjJPQWlZdjFDaHl3RjdacWJQQ2hM?=
 =?utf-8?B?dVYyV1JML2NScWI3OHZYRmM5eW5QMFlWK2pBWk14WUE2MjU4MDJOYUVobENW?=
 =?utf-8?B?Wjk5Mml2RExxWktHSitadzNIM1h6MWc0L0xIYit4dk9BVWczQmtUU0dDejhz?=
 =?utf-8?B?aGZ0ZDNmTVpYMUdGM2pmZkpOZ0l2UmVLcjRVTFZYc1hRVERQMEVxbk5WUkpO?=
 =?utf-8?B?UzFlNTFqUTNVYVBkZ1dZZ0hnTmdEdHZPTWt2anFmU21COWN1UG1jR05BU1VK?=
 =?utf-8?B?QVgyUEdUQjZoWTgrRmhyaFVXTk1SbE9qeDVKaDQreHdVNVBZWWkvYjE1b1Zm?=
 =?utf-8?B?VUdreU1taE1kL1h3TGVzWVhwenNqQTdFUDc0bzViVVB4QXJXR3lkNklmd0FP?=
 =?utf-8?B?YVlIUmlzbXl6dzdwUG02SER5YXM5U1FBaHlKZ0tmTklMQTQyVmdORk9FdTZS?=
 =?utf-8?B?VFFlU0R6VXBaQnRSM3hMK2JtUkpsU3l2ODlzaGx1ZXpza0NURHBLY3VTUWZ4?=
 =?utf-8?B?cGtQbDZWVzdoVm9TRTBWV0JDSEVEVEg1U0k1TFIxa01KTElURTZhOUVCWFB0?=
 =?utf-8?B?MFFMZVRQazVUeGRQQXdwNmZpRFRSUWwwQVorbEVhRXgvb2p0c3lBUmE1Um9z?=
 =?utf-8?B?YUI1YXRZVDMyNjFRS2dWM3EwWk9pcERIYUJoVTV0SC9SSlFoVkJ3NGhMSk1I?=
 =?utf-8?B?RzQ3c205RllmN3FEVFRYMnpENzVoazREbE5najZyWWkvZVlLbEpBKzRndEda?=
 =?utf-8?B?UFNSSzhnV0xoYmwxbHBVa0cxaWMzcGk0YXhqTytjR2VaZkVXU1VtTDJrRWRU?=
 =?utf-8?B?eERXazJxNVJKdlRnY0RQR1Q4Qno2bFBORkdFNFFQY1lHMERPQXpWdk1GT3Rp?=
 =?utf-8?B?cEtsZDFFU1diK2Zyc1liTkpReC9TOUNiZDg1aDhFcWlBZjVET1BwdlAvRWdh?=
 =?utf-8?B?VytXK2tyUVlGYmZxVmlwMDJhRDVncndKSGcvNlRQTWxXbW9FV1FWOUx2aE5I?=
 =?utf-8?B?UW5JeFVtaUdGcHNZTEVGVUNMd2VzcE5wbDlDbndyRnlBaVJHenc1dkJpdWkz?=
 =?utf-8?B?SkFGb1c0VWNPQmZ4QjNOMDFHaDJIMzM1SGloWGZxTVNCWmdVd1kvYldBWEFa?=
 =?utf-8?B?dnBkQWNkLzVUN2RBQWJ2SUt0THVKeFdRWEcyOFY1aGl3YWxTbG90M3Q2TE95?=
 =?utf-8?B?N1p2UHoxVjRLdXhrbzQ4WWlQc0xDZVlveC9UZmgvY3V6ajZtNzJ4dTVINUJM?=
 =?utf-8?B?K0R4OVhHdVVtOVZ0RVdta01RNFlBRVUzbHpESU1wTWRaZFc0TFQyaTM4eVpY?=
 =?utf-8?B?VUlQMnZvKzVKcGdQeTdYb29zYzlMSW5MSnhTcFFIaGFoQ0hBUVpQVjhMd1ZJ?=
 =?utf-8?B?VFE0WUY5Zjc4YXQrNHRWMVNqK29QM2xxOWZuUHFIQTVuNFBXYit3eVA3dnRJ?=
 =?utf-8?B?QWRSekcxNkZMc2pvSkZKR09JVjNoRjQyNGVGV05WMWxvQWdOdGpRSE45ZHBj?=
 =?utf-8?Q?VJi5pidnMXI=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)(376014)(366016)(1800799024)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?SE94TTllVTN3cUJrK2tKNWlxWmRDT1NCc295VnE1aHBaRUt5VTlMVzJzVTVU?=
 =?utf-8?B?TCtqTThvUEZhbTVGeFUxcGoyTFRqbk53ZWNuTmNRQ210bk5iQVF6VEJzcDEz?=
 =?utf-8?B?RUlERXZCTkthWnVNSjA5UDFlUkRZTUpZZDF4bHQxcExwT3ltOWoybnNOQW1O?=
 =?utf-8?B?V1A0bGs3c3JuVDdPN285dlZ0RTdGQWZrbjlPalZYS2FsTVUrUlNQcWh5YUcv?=
 =?utf-8?B?QTAxZERUT2xlc2ptQThYVDdicmJJNWs0U0tubmpqNTM4dndqSHZ4d0IyZDZv?=
 =?utf-8?B?cExlSlNpUEJsb3oxZW5LNEVyTFpuOFo4dzAvVzU3clB3WkZlM3lHZ1hqUEQ0?=
 =?utf-8?B?ZHJDT1YrTDRXaDh0dTY3SEtKY0lacGdEWm8rTlFtTGczQ0hmWlM4VDZpWnRw?=
 =?utf-8?B?alJIMVdtQ0FmMlpPRHBYL0pkM085b2hBdmtyb0ptQW5YNDRNaFF3RHc3Q2dU?=
 =?utf-8?B?RCtpdWtsaEJtMlZ4TDZreUFzTHZRYyt1NWNtMDVTeVBrYk5MTkpjVGMwbjZi?=
 =?utf-8?B?RVhOTWc5elN5a3h3aFdPeTNUbnRGK2NFRWVacU5EcFA4U21kTThYdElWazVF?=
 =?utf-8?B?TXhpNGlMRWQzSzlua1NxMGRDT0hxL0l0eWNVbkZPSlhsU0tUakVTNk1KVkcv?=
 =?utf-8?B?SmQ5OExBV1gxR25QQ1pwUXFoWGhSWm5GRnlsSUFrUVZVaGpFQ0E4aVM0ZHNa?=
 =?utf-8?B?U2RMajRtQ085aUg3MVlZWjhqNE4vUWVTSFRxTHg5Ymw4d3AzNERIN2VZaVNa?=
 =?utf-8?B?TUNQNHVSYlZtTzhqQWJSUXRFQmlWWjdWR2U2UzZoNXJCWEtpWlVTK096OWJR?=
 =?utf-8?B?WGd5RS8vNWpjNHh3Q3hUQUswRGdmYU9tVFdHWERkejkxL3FBR1c2VGtvQlFK?=
 =?utf-8?B?OVNUM1V5eUswUHF4SCtRMW93NHNtME5iMldrdHRWRFhBTGhDSktick9mMVJy?=
 =?utf-8?B?cm5wdEFNTXBnbndYc1VnRjlLVWhCK0F0YjJkbVZYWXliZUJPL252RWJGcU94?=
 =?utf-8?B?M0NCWFVIQ1ZkL3c3aEFlcDNvb2pWOTUwVUZpbHRRdHhTSHRrY05hOG91c3Vz?=
 =?utf-8?B?RmZrWHV1b2JSbllzQ0tYd096Zmt1a3c3QlFXMEFUdHFHWGFPYUlCaStMRUtX?=
 =?utf-8?B?R1BtbVduUnR1SWVmRUhpSEhzczFVMTV2cCtnZWhjVEV2cFJoNG42WVFFeW9J?=
 =?utf-8?B?K1BwaHZhK3Z3aWVXSTBSb0lpZ2dSd2VCNDUybmI5TTMxL1N5YVNrN1hzUnph?=
 =?utf-8?B?RWExQkF3cEFNRDg1N3VNekNuMkFLdW01MDljRTN3cmduY0ExdXFQU1VkK25x?=
 =?utf-8?B?TWFhNnJWWVJWR052Z3N4eHRkR2FyZVZaS0N5WlJwcUYxTmhDRVRxQld4a2Yx?=
 =?utf-8?B?R29ubmtWbXBVZlk1T214dTdpd21wUHZwbTE2a3UybW16SHRWeGphQm9QN2JV?=
 =?utf-8?B?R0RIakZnYlNIS3ZiYk5aMk9lWXlWNWxGdWo0N252a3RJRnByYnl4K1BFR0tK?=
 =?utf-8?B?cVhCeWZLb1BYY0dTb1JhVEZpbVhBeFlXQnlkdWQvdnZIcUNZVkZsZkdabEg1?=
 =?utf-8?B?dTl6SWxYYTA3TzBhMVpXeWRWcDBxS3hLd083cUNVRmFZNUR0a1kzV01XOGMz?=
 =?utf-8?B?UXdYMzZPVnZXcjhBQTZFbFNpcGY5TExJcEF5WXpYU094YVNFSi93YWVQMFpW?=
 =?utf-8?B?OUpOOTVhZVo1Ri9tNmZMd05KcU5KQkd4MkU3U2oxUTdCRFBxYnBKeWdub2k5?=
 =?utf-8?B?dDlMQWZ5ZFFGNFRiNWZRUFF5Q3hjOGR2QTdVTEwyRXJhQlhWNnFlajVmMmFU?=
 =?utf-8?B?YUFPaGF5ZENQY1JlY3R4Slh3WnQ2djBVbWF3V3U5Z2lwK3Bjb0JtNHpNVm9h?=
 =?utf-8?B?RHJ2dWN0UktTRjZpaDA2czNzeTM2UGx4RGprd25janpkc3B0STF1Wm85azc1?=
 =?utf-8?B?UWtNUkJyZ2pKYnpwY095WGpBOGVKdU1uNVM0dXFUN3kxdUNhVitEUWlaenpk?=
 =?utf-8?B?R09UMHFneUFLZFR6UjRleVY0NGtUT2FUYUlDVXc3WHVyU3hmd3g5cG1VKzBF?=
 =?utf-8?B?blpiZGVMaDlHYXI1T3hRZnRnRFphTW9LNmZwQ2RESGdFOENhLzBlN2E4elg3?=
 =?utf-8?Q?OMcJ/uPErT1Fg9d2v5MIkiqF5?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0d4f51bf-3941-477a-fd84-08ddb40d3112
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jun 2025 17:24:51.1144
 (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: r97S+8icojzXf0WbjeH7TfV3aCK2CPxqA6l5K/EwkBSsPRTTw/YmYRyF5UzViwBigywB0NRaeXhozLZ3NVkqpA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB9242


On 20/06/2025 10:49, Hari Limaye wrote:
> CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email.
>
>
> From: Luca Fancellu 
>
> Implement the function early_fdt_map(), which is responsible for mapping
> the Device Tree Blob in the early stages of the boot process, for MPU
> systems.
>
> We make use of the map_pages_to_xen() and destroy_xen_mappings() APIs.
> In particular the latter function is necessary in the case that the
> initial mapping of the fdt_header is insufficient to cover the entire
> DTB, as we must destroy and then remap the region due to the APIs no
> providing support for extending the size of an existing region.
>
> Signed-off-by: Luca Fancellu 
> Signed-off-by: Hari Limaye 
> ---
>   xen/arch/arm/mpu/setup.c | 74 ++++++++++++++++++++++++++++++++++++++--
>   1 file changed, 72 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/arm/mpu/setup.c b/xen/arch/arm/mpu/setup.c
> index b4da77003f..ab00cb944b 100644
> --- a/xen/arch/arm/mpu/setup.c
> +++ b/xen/arch/arm/mpu/setup.c
> @@ -1,17 +1,87 @@
>   /* SPDX-License-Identifier: GPL-2.0-only */
>
> +#include 
>   #include 
>   #include 
> +#include 
>   #include 
> +#include 
>   #include 
>   #include 
>
> +static paddr_t __initdata mapped_fdt_paddr = INVALID_PADDR;
> +static paddr_t __initdata mapped_fdt_limit = INVALID_PADDR;
> +
>   void __init setup_pagetables(void) {}
>
>   void * __init early_fdt_map(paddr_t fdt_paddr)
>   {
> -    BUG_ON("unimplemented");
> -    return NULL;
> +    /* Map at least a page containing the DTB address, exclusive range */
> +    paddr_t base = round_pgdown(fdt_paddr);
> +    paddr_t limit = round_pgup(fdt_paddr + sizeof(struct fdt_header));
> +    unsigned int flags = PAGE_HYPERVISOR_RO;
> +    void *fdt_virt = (void *)fdt_paddr; /* virt == paddr for MPU */
> +    int rc;
> +    unsigned long nr_mfns;
> +
> +    /*
> +     * Check whether the physical FDT address is set and meets the minimum
> +     * alignment requirement. Since we are relying on MIN_FDT_ALIGN to be at
> +     * least 8 bytes so that we always access the magic and size fields
> +     * of the FDT header after mapping the first chunk, double check if
> +     * that is indeed the case.
> +     */
> +    BUILD_BUG_ON(MIN_FDT_ALIGN < 8);
> +    if ( !fdt_paddr || fdt_paddr % MIN_FDT_ALIGN )
> +        return NULL;
> +
> +    /* DTB starting at this address has already been mapped. */
> +    if ( mapped_fdt_paddr == fdt_paddr )
> +        return fdt_virt;
> +
> +    /*
> +     * DTB starting at a different address has been mapped, so destroy this
> +     * before continuing.
> +     */
> +    if ( mapped_fdt_paddr != INVALID_PADDR )
> +    {
> +        rc = destroy_xen_mappings(round_pgdown(mapped_fdt_paddr),
> +                                  mapped_fdt_limit);
> +        if ( rc )
> +            panic("Unable to unmap existing device-tree.\n");
> +    }
> +
> +    nr_mfns = (limit - base) >> PAGE_SHIFT;
> +
> +    rc = map_pages_to_xen(base, maddr_to_mfn(base), nr_mfns, flags);
> +    if ( rc )
> +        panic("Unable to map the device-tree.\n");
> +
> +    mapped_fdt_paddr = fdt_paddr;
> +    mapped_fdt_limit = limit;
> +
> +    if ( fdt_magic(fdt_virt) != FDT_MAGIC )
> +        return NULL;
> +
> +    limit = round_pgup(fdt_paddr + fdt_totalsize(fdt_virt));
> +
> +    /* If the mapped range is not enough, map the rest of the DTB. */
> +    if ( limit > mapped_fdt_limit )
> +    {
> +        rc = destroy_xen_mappings(base, mapped_fdt_limit);
> +        if ( rc )
> +            panic("Unable to unmap the device-tree header.\n");
> +
> +        nr_mfns = (limit - base) >> PAGE_SHIFT;
> +
> +        rc = map_pages_to_xen(base, maddr_to_mfn(base), nr_mfns, flags);
> +        if ( rc )
> +            panic("Unable to map the device-tree.\n");
> +
> +        mapped_fdt_limit = limit;
> +    }
> +
> +    return fdt_virt;
>   }

LGTM

Reviewed-by: Ayan Kumar Halder 

>
>   /*
> --
> 2.34.1
>
>


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 17:26:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 17:26:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1025408.1401016 (Exim 4.92)
	(envelope-from )
	id 1uUTtU-0008Fv-8t; Wed, 25 Jun 2025 17:26:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1025408.1401016; Wed, 25 Jun 2025 17: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 1uUTtU-0008Fo-5P; Wed, 25 Jun 2025 17:26:44 +0000
Received: by outflank-mailman (input) for mailman id 1025408;
 Wed, 25 Jun 2025 17:26: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 1uUTtS-0008Fi-Vy
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 17:26:42 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on20601.outbound.protection.outlook.com
 [2a01:111:f403:2407::601])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8e56d153-51e9-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 19:26:40 +0200 (CEST)
Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
 by MW4PR12MB6707.namprd12.prod.outlook.com (2603:10b6:303:1ee::9)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.28; Wed, 25 Jun
 2025 17:26:36 +0000
Received: from PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264]) by PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264%4]) with mapi id 15.20.8857.022; Wed, 25 Jun 2025
 17:26: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: 8e56d153-51e9-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=KQrvy4ODv6g7TWGIlOFOTd3GW/dt9ZRLtpno57uw5I7KLE86bN4rrVEoCg1b1P0QSBycqg9BMFuL9pzW2j63WJ6PhZFR6Tvm8WsmQmE4gWm+iAClvtHUWTnFiJt5N3cnAfGsvGc+EIAH5yoOO+XoV466ir//UOQBUeby3v+yRqrzyWGeJ4Dv76i4r8oj6iJHEalClK6tIskHF4fXR8kICQob5Dt5cEuJdKhSngBpZcKrxUbNbbwpC5wTYMirG6MJ9kvU6z2/jeoKJ6SzacuxmqPsGpkjvZLpSD9eIw95Eac99j0UCBe1k9193PVccVGJQuyEJnf1XJuvxZcnwUdMhQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=L08ObTZ2rdiNkLCpPBNhf5bX/1KhDny2ZiY1FyFu6Fc=;
 b=k+0alFl7vZmhhRx34zv+SaG8dttn1yyIjM7GlPKZ9ZfC3EFW/ZpD9ZQaM1NtbAc882+2oX5gB8R3Zbt7RsWLLSzRJal/0MgwN0iUQObq188KjqqUAetcBoh64PbBv77zZFhYWXZ/lyXNNyQP2xtoNvK/dNvfMpHA3Qa5Ef8GosnYd9z6j6v2uITRrq4nMs26IovO2/C+I/Q2hb6HCBUKSb1tsvprqASzqyTCHjvROZo+4J4A8HoKzVAErAKBbQ0BTXO0BJcJ5Yz6ckadYIdOHgqqP4FZ6qAcOYquD79cuyZucEDHL2LqtqzZPcRNeCwWdQIgojKTHkqT079TBa9FAw==
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=L08ObTZ2rdiNkLCpPBNhf5bX/1KhDny2ZiY1FyFu6Fc=;
 b=KIToS3MK9PSTjSiMamWTd2xyyXCaltXnoGD2fe6jnw1n8jtvK1Za79w7PzjjzH2v+VmT3GYbXOO1NNFC/TsdjmUGMnIRlN0kjC0+OLvoY97GIB+ovmgK0nG0RPZVCdXWvRCrAOWSvGkGPKcLBfjbu/Em+S7EW+w+VHGnB0hUhX8=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <33aaf6ce-011d-477c-aecf-071610392950@amd.com>
Date: Wed, 25 Jun 2025 18:26:32 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 6/6] arm/mpu: Implement remove_early_mappings for MPU
 systems
Content-Language: en-GB
To: Hari Limaye , xen-devel@lists.xenproject.org
Cc: luca.fancellu@arm.com, Stefano Stabellini ,
 Julien Grall , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: 
 <9a8b831cc6ff25b03c7ffab6a5c79e653496aa4f.1750411205.git.hari.limaye@arm.com>
From: Ayan Kumar Halder 
In-Reply-To: <9a8b831cc6ff25b03c7ffab6a5c79e653496aa4f.1750411205.git.hari.limaye@arm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: DU6P191CA0004.EURP191.PROD.OUTLOOK.COM
 (2603:10a6:10:540::21) To PH8PR12MB7326.namprd12.prod.outlook.com
 (2603:10b6:510:216::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|MW4PR12MB6707:EE_
X-MS-Office365-Filtering-Correlation-Id: f41e7f1f-04d8-4f1c-e7e4-08ddb40d6fec
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?bW9ucUovWW42MWtxWEZ4RlliaVpSclp1YUxwbzEwdW5VeEtTMWFiZkpwNXds?=
 =?utf-8?B?UUhFSWx2YjA1REljZk9jL1FnNE1kSSsxSG92QkRod0VCM1NwbzBlMzRQZjly?=
 =?utf-8?B?Kzdhb0hFOE01NkJDa2tMdkRDdjYrSFZ3V002SkdLVTlqZmpYSllCRXlNVGZY?=
 =?utf-8?B?YktSWjZiTDVlem1xeEpyUEtxc3YyVGRGMy9paXYvZHlGeWFyN1pZTkxqbktE?=
 =?utf-8?B?YVhBRGsvMk1kalFtZ1lqWUNOVnVxbFpuMm5aeG83T2ExZjFyd0lyc0IwR3Qx?=
 =?utf-8?B?WFYyZkc2b0VHYXdtbURCRUkzN1hYYnlLUDR3V093RkRaZHFDbmtYNU9KcWlQ?=
 =?utf-8?B?WlJqNVZnTzBXS25DUkNNRkJxRm1KZmRSYnRGTnJxNzVKSmF4SVZTU3ZmQThz?=
 =?utf-8?B?SVZQWDVyWmVheHpkRFpzYUJGRGVEWm5BQ2ZVMGU4S1NZcEJXV3ZsKzVXb3dk?=
 =?utf-8?B?UWE4aWpaSUVLeHpUTk5SVU1xaCswY3ZaZG9FUE5YUXphZmM0VzZLT3ZVMGxK?=
 =?utf-8?B?WHNBLzNTdjlGaWdaYUJvQm1wUlQ2QXlETytKWVJhdXpCUUY2TFhFOW96Zmlv?=
 =?utf-8?B?TURxcmoxVmVWRGNyVlRmM2pabmhBVmFhUFpoVitnSEUxdE9BVmh6bUFQVDJH?=
 =?utf-8?B?YSt2T3RPMTRHN3dPUXdXTjdDY09yQ0Z4NUZVWXNnK1BwYkFBWWdKZXphK0g3?=
 =?utf-8?B?UDdNRXNlQVNaUXdpN2JGMHZBQzhFVG1jWkduZUdMMkJ4eGR4M3UwOGF0Q2p4?=
 =?utf-8?B?UW9ycHZKMkNOQmxnMVFzQmRHUEJ1YWlHMjVyZ2JoWngxbkZiUWhpVnNmYkxU?=
 =?utf-8?B?NHVqL29MVEsyY3h4enBFVGJsUkhTZjRCcWVEQlF3d3lVb1JlLzF3YUlKaWJu?=
 =?utf-8?B?MnJnbXJzeDJuOEpNeVA1L3dmaTYzaXlOYnprSGZtSStac0dubXlDVlNoU013?=
 =?utf-8?B?OE9aREhUMEZTRmdZTmt2OWd3TDBwMUxFMFFCa1o2UG02R2o4TW50RXlPSnZK?=
 =?utf-8?B?T3NTaU0zMXE4SkxZT3c5YzRIRDl0dUhPMUZ4N2FUQ3hKbnhUcCswVEsxR1hS?=
 =?utf-8?B?MlJxNGp6NkdlRnowcklOZEdHbGZ1d1lGRE5rMjFBOGkwVlJqVThhSnVOVXh0?=
 =?utf-8?B?Y3A1NkhxNWZhdG1aZmFhMXYzcnNpNVQ4bm94R0wvSmJDTzhVS3NTQ00yK1FX?=
 =?utf-8?B?Zk1Pb2FhY0VhY2JaenAwaGZVMUQ0NWJDN0lnQlhleHRPY05TYjlOakNkZXFt?=
 =?utf-8?B?clZiUkJJdXpMdk5mWHJJamdrWGxxWjNSZHdLU0oyM0s2UDhQaGlYSDNuQnFW?=
 =?utf-8?B?UmNaL25qdi9oemVHMUtSVEdhMk41UnFudVBRYnVBeUYybHhkSko3VnlGQWxn?=
 =?utf-8?B?MDMvb2toMER1RWd3L2c3U1YrWlZseVUwUndyWFRGYnUvL1V2S2oxV3VJT1ZL?=
 =?utf-8?B?cmVyeUhUZ3VrL1c0dGRLZjdiYis2KzNjZnUweGNma2UwQ3JwWWlrYVgrUjdh?=
 =?utf-8?B?cmtnNEtUd2g1ZnBwV001TUFNekREcEh6dGxuSTRTeGVQODNhNU4xbmQ2SmV4?=
 =?utf-8?B?dmgyT0hISE0zVmNvVWdUSE5yZTBKSHg2NXdtYUJpVWhzRHBROS9icU1oT01T?=
 =?utf-8?B?SStmaVZLOCtqM1VKTTlZaTJiQ0g4U3QxVjFQTVB3cHBNc2ZubmdIMm1saW5S?=
 =?utf-8?B?a0lBZVE4a0x1YVh3MU5KU2FLYTZDU2Jnd3B5VGZoblJkVWtHejZmMnVoVnR4?=
 =?utf-8?B?WjlYcldzUitvc3FGcDVqZzQwdGhjOHpXZkdjTHZnczNLeFg0clFYWmFCNGxi?=
 =?utf-8?B?MGMxN3JidVh6UDJuTUdsRW9zNitycW1ZSEppWi93aWRxa09MdHFxekVLNFJp?=
 =?utf-8?B?VlFTNzlVV093UTdDNWpZMWlkTmFUY3N0ZVhVWWxpLzJRV1l6enVFVUxySUdS?=
 =?utf-8?Q?DjSilvzRKNo=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)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?OFpsMVc3Wjd0Uy9DeVFCQ2xLY2RYRTdtamhHTmNvbTFrWXZtblgxSitHa2ZQ?=
 =?utf-8?B?T0xrM0VYUlBSMWE4eFEybkhQNENPUUtNTk83OU9KWXcvamdVK3h5Nzc0L2pu?=
 =?utf-8?B?NTdWdHlpZlF3aXpET0JaZTRyZlluY3U5SDZXd3ZWT0ZLL3REcFJyYlA4TGRy?=
 =?utf-8?B?cSsxa1FTRDVvOUJtOGtyQWlqeVpYaDE3VlJ1RjkyOTFuZ05lcTVIcHVUOXZp?=
 =?utf-8?B?NERxeHIramNCTmNEYUtLNjNOVjZUcnB2bnpzWUlzWUZaaTRsYnVNdlRKTnNS?=
 =?utf-8?B?N2FCVE1pWG5MWXVCYjNUMlpIYVNVZ2RENkVHRm9jMFN4UFR3OUd5QjdmTWda?=
 =?utf-8?B?amN3TXpwMnRhN0FsS2p3SHJYcklnYSt0UUhRTXZGVUhTNHNNQjRDWEFwL1A5?=
 =?utf-8?B?cDZHV05kdlA1eWNET2huSkZXdDBQVXdWWGU0ZjgrZ0s1U3dhQjFtWVNuSis1?=
 =?utf-8?B?QXU1NHBXOUZSaXVUTXZYV3RvRFB1ZHN6c1V4d2JBQzZDcldKNm9MNHB1TXlE?=
 =?utf-8?B?dVk4dzRHUnExVWtIUGlGcDRpd3h3L1pDYUxSbVF3aDQwYXV1amtCcWtDTlY4?=
 =?utf-8?B?WkFTVmg4ZTRsdDF3bnBIZDlNNmNaWHZBWDZPRis4UDlDZUVRTUszRkh2MUl5?=
 =?utf-8?B?VnZ4aUgyejErQ2VpNUFFbGFMclUrUmQyOTRxNHlFRjhUbVBDbVN6MTZheXJn?=
 =?utf-8?B?bUpXZElZM2JrSXUzdURtOGJpQ1FHWjlXSjhvQjE3TlFOeUhpeTY2MFBPNTR0?=
 =?utf-8?B?Rm9pUy9Yd1lPOTVxNzNnYlpYYmxzZUpidU53MllOYjR5ZXZBcHNQdlNlOUl0?=
 =?utf-8?B?enlYQkVhMkFOS1lSdHpjcVdidS9MWm5lTmlEY3FnNjZwMXFmOTIzUEZOS1Mz?=
 =?utf-8?B?V1J2UG45TGN4WXVwNU1ubDYxeDlRWlllbWE3ZmF5MmpTMERITlJHcFV3Zmow?=
 =?utf-8?B?czF6bWhwcWZ0WVorV0dPWmlsOFFQM1kvNkg1OGZ5bm9kaVZXNG9SOXZkTUtk?=
 =?utf-8?B?dXY1OXhYejFpNzdsTUtCS0l1NzJYZFBzd01tak5mek91VEdFTDFtblVMS2pG?=
 =?utf-8?B?dDRIN1kyU1ZzM3ZGS3JUUm9zVWRYSkl6UnRyekM0Z3llNzN4NjlVODZGK2M1?=
 =?utf-8?B?VVN1U21sa2h0eDdmZi8rYXZVeDBjVTBFbCtIV3RKd0hVR2Jxa1o1NE96V2dE?=
 =?utf-8?B?WU5kRTVyT1JaWkpYNXJTelViTWw5RFYyOGRiZi9hL0hIK1ZSaEEyaVdzL010?=
 =?utf-8?B?OUw1ZVhzdGxINzJieCt2ZnVXK3kxM0NxYm0ya2V0ZmRmQ0VUQ3hETkltTThq?=
 =?utf-8?B?a1UyaFhoVk9jdEhSUFZXcUtiSGNVNmpQU2NRT2pFdk1aZzI3Q0xNL1k5OW9a?=
 =?utf-8?B?bjRNRngrN29aVDVoNnlCQW45Y3FxcGFFVnVQVHQzanNkVWxUaGQ2VEE5Nm9E?=
 =?utf-8?B?SG02LzRJSWlNNWhMYzJMQnVYVk1xTlBlM2R0OWhoTTIyeENxdUdQanh3MW5Z?=
 =?utf-8?B?ZlArMEhuTEVFTWZteWkvVWcyUXZLdzk2T25Nc2xsWWU3VWlMYllVd1I4ZHNK?=
 =?utf-8?B?VE9HaXZ6ZCtIYXRxNlRXOTk1aEpHbXAvb0NGQTRsM3dmRTJWdUhaTGZEKyt0?=
 =?utf-8?B?ZEQ4Z1JSd0FTbVpJVitFOElXMzU5VVcyOW5yTFNJM3NSSEVVM01rOTB6cWp6?=
 =?utf-8?B?SFVTN29uUi84d2g3TmRtczA5WnVFcURyMXo2UEw0cWtGU1IzU1hTcEtmai9S?=
 =?utf-8?B?SnpmSXhYSG11c0FrMktwaHp6bHBQYTQ5VGp1WEw4b045Ukg5SVI0UDE3NHdJ?=
 =?utf-8?B?NjRaL2FzOWJyNDlNbUFhN1R5OHNSL084ME5ZOGpuMjhxSVVaTmhaRXpCcnVS?=
 =?utf-8?B?bnVlSUZDRGVVb1R0NnIweDUzUlRJdTlIZzNscTYzM1BFd24xRkxBRTB3allK?=
 =?utf-8?B?dGxVV083MzZRa1ZYbVYwS1BIVmNFR1dRc3M5M2ZHTnlLTVNVbG1PenVNQWpX?=
 =?utf-8?B?bFc1TUZEVGN0c3VjNVBxVFV4dkZndk5aWWRoaGJkbWU4MlB3OGZyVWhkdWlP?=
 =?utf-8?B?ejVCYmVMR0llTWI0ZFY4Y0wvajlMZUJsbmMyYXllY2hncnlpcFFZeXVPUFIx?=
 =?utf-8?Q?p1bYSBoGxWFhvoED0JpYhUYm7?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f41e7f1f-04d8-4f1c-e7e4-08ddb40d6fec
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jun 2025 17:26:36.4543
 (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: cSxJ9xsk2ZzoJSPmbAw52nHzLuTDcTb+dJuE4F91MfF/jNxQ8cPrH4xI/1J/DxT3ayJH3YBYS+3Z/QI7WH5EmQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB6707

Hi,

On 20/06/2025 10:49, Hari Limaye wrote:
> CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email.
>
>
> From: Luca Fancellu 
>
> Implement remove_early_mappings for MPU systems.
>
> Signed-off-by: Luca Fancellu 
> Signed-off-by: Hari Limaye 

Reviewed-by: Ayan Kumar Halder 

I have tested the series on R52 and R82 and it works fine.

- Ayan

> ---
>   xen/arch/arm/mpu/setup.c | 9 ++++++++-
>   1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/mpu/setup.c b/xen/arch/arm/mpu/setup.c
> index ab00cb944b..5928b534d5 100644
> --- a/xen/arch/arm/mpu/setup.c
> +++ b/xen/arch/arm/mpu/setup.c
> @@ -97,7 +97,14 @@ void __init copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
>
>   void __init remove_early_mappings(void)
>   {
> -    BUG_ON("unimplemented");
> +    int rc;
> +
> +    if ( mapped_fdt_paddr == INVALID_PADDR )
> +        return;
> +
> +    rc = destroy_xen_mappings(round_pgdown(mapped_fdt_paddr), mapped_fdt_limit);
> +    if ( rc )
> +        panic("Unable to unmap the device-tree.\n");
>   }
>
>   /*
> --
> 2.34.1
>
>


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 17:45:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 17:45:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1025432.1401025 (Exim 4.92)
	(envelope-from )
	id 1uUUBT-0002rJ-No; Wed, 25 Jun 2025 17:45:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1025432.1401025; Wed, 25 Jun 2025 17:45:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUUBT-0002rC-L2; Wed, 25 Jun 2025 17:45:19 +0000
Received: by outflank-mailman (input) for mailman id 1025432;
 Wed, 25 Jun 2025 17:45: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 1uUUBT-0002nO-9B
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 17:45:19 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2467fcad-51ec-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 19:45:11 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-4530921461aso728355e9.0
 for ; Wed, 25 Jun 2025 10:45:11 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-45382349548sm26265485e9.10.2025.06.25.10.45.10
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 25 Jun 2025 10:45:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2467fcad-51ec-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750873511; x=1751478311; 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=9HuvtyMrzxiIvDmIcbYJGjbJbaFae+Zfd5+5FgSgtCs=;
        b=Se7CqhPfLp3X72JHx7kVDIhvtHd+x3ybaN+zhrAIGdHmp/i9JcXhO+c7V/SSE4p+py
         lnKUh/zY4z4HOro1ynFboRx4OaaWswGSzPrdSehCkyUCGjvE3mC2Owq94peeG4AGA4IN
         9McrDHuH2M0Fek6Y5fOrqrIWIDVwIvrRnNw/Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750873511; x=1751478311;
        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=9HuvtyMrzxiIvDmIcbYJGjbJbaFae+Zfd5+5FgSgtCs=;
        b=ZlF//sA5P/1DVZV01T/JpFIFoWESHlPQ3ohZQBjWyQZLJjQhgnVy5/xt3I32oUtfl3
         7Gtqo9+HN0Ps5LxB7Wv1WHxot91ngoqoeww794Yk6RPvvd+y+yYbIokzxXtEtXGpdD09
         MBKqpWkkKMEoQUsH/qXIKvY1+aoUcYYtFKznemqZS6WkQOg9UwHtGKKuU95NCL2YLInt
         dLqqa9t+P2ad0VnBAtXQ2lagoSFl+oRfN7RUyoLIpXFq7x58I1IBUslPKU6cip6ntjjL
         FrtXSoLOVpH9nu0W4yKElUyOv8AfuDbD0KDC386kzx4YHu/VLz5mY2YPmgWEAyZa0CWO
         UKjw==
X-Forwarded-Encrypted: i=1; AJvYcCWmTVVskPMJXx3OXvaFYoR7FRzIJBkl8YNim+zFA9OvgpRGUoRAT+ECi6M8c8b1jWbrD313sERmhaY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxE4i5Xp7xNcw5K4q1mhPhKRbG1DCKOmeAiDPMBLqWDvblIqK8S
	yONb2Qe05zXdiLUqOaSrdy18Xwv5bZz8P0FMGsgku1ZZEZhOG5vyPIwy0qpDt3JTINU=
X-Gm-Gg: ASbGncvCYizAaA3UkbgdPnmQM9Bpz7uRFQoC+tp9SzqtzfEcJ/8SZ54m9MIn5R6r3YI
	3TvjXdvW28ihKu8tw0mRvsHJ2DoIY9D3VFcxRMT9Kf6WF7KxWA7IqGt3Z1ui+UV2JUCbV+9Z6sK
	B6+LHNylruUIjNXkdM4tGxwLIFa2k17RzGL60i1K1RHFk4yYi0gXjG5k2zq4a/1eRyzS6Rcz4Jw
	Ld93WRVHqtuHRddPbYJZQkeqClBPpP5D9eC0AHhbxvDKxJTHDinawfSfzC4WANr+fFgpDSqHd73
	BcCzhhGe1bCk1rjmeyoEu2PTsAdiNyDUX8SxzTumzgDy58oRQi/gHbr/NObLupXwQYEVSW91eM/
	sPAK0M0Pm6jUuaBXJLeMj3t9ltv9RSw==
X-Google-Smtp-Source: AGHT+IH/z+9PRdFLv6Qd4p8Wctzhgxso1VXIficXEtNWFMItPL8wsUqv4AlYmkqQra3mH6NkBOD3GA==
X-Received: by 2002:a05:600c:8b58:b0:441:d43d:4f68 with SMTP id 5b1f17b1804b1-4538870ce27mr8065835e9.15.1750873510856;
        Wed, 25 Jun 2025 10:45:10 -0700 (PDT)
Date: Wed, 25 Jun 2025 19:45:09 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Stefano Stabellini ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 4/8] pdx: introduce command line compression toggle
Message-ID: 
References: <20250620111130.29057-1-roger.pau@citrix.com>
 <20250620111130.29057-5-roger.pau@citrix.com>
 
 
 <23206592-6016-47cc-87a6-151c76f254d6@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <23206592-6016-47cc-87a6-151c76f254d6@suse.com>

On Wed, Jun 25, 2025 at 06:00:48PM +0200, Jan Beulich wrote:
> On 25.06.2025 17:46, Roger Pau Monné wrote:
> > On Tue, Jun 24, 2025 at 03:40:16PM +0200, Jan Beulich wrote:
> >> On 20.06.2025 13:11, Roger Pau Monne wrote:
> >>> Introduce a command line option to allow disabling PDX compression.  The
> >>> disabling is done by turning pfn_pdx_add_region() into a no-op, so when
> >>> attempting to initialize the selected compression algorithm the array of
> >>> ranges to compress is empty.
> >>
> >> While neat, this also feels fragile. It's not obvious that for any
> >> algorithm pfn_pdx_compression_setup() would leave compression disabled
> >> when there are zero ranges. In principle, if it was written differently
> >> for mask compression, there being no ranges could result in compression
> >> simply squeezing out all of the address bits. Yet as long as we think
> >> we're going to keep this in mind ...
> > 
> > It seemed to me that nr_rages == 0 (so no ranges reported) should
> > result in no compression, for example on x86 this means there's no
> > SRAT.
> 
> Just to mention it: While in the pfn_pdx_compression_setup() flavor in
> patch 3 there's no explicit check (hence the logic is assumed to be
> coping with that situation),

If you prefer I can leave the pfn_pdx_compression_setup() as-is in
patch 3, as AFAICT that implementation does cope with nr_ranges == 0,
that would result in a mask with just the low bits set, and hence
hole_shift will be 0.

> the one introduced in the last patch does
> have such an explicit check. Apparently there the logic doesn't cleanly
> cover that case all by itself.

No, I don't think the logic in patch 8 will cope nicely with nr_ranges
== 0, it seems to me at least the flsl() against a 0 pdx size mask
would result in an invalid pdx_index_shift given the current logic.

IMO it's best to short-circuit the nr_ranges == 0 case early in the
function, as that avoids complexity.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 19:47:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 19:47:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1025497.1401035 (Exim 4.92)
	(envelope-from )
	id 1uUW5P-0000ZD-3g; Wed, 25 Jun 2025 19:47:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1025497.1401035; Wed, 25 Jun 2025 19:47:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUW5P-0000Z6-17; Wed, 25 Jun 2025 19:47:11 +0000
Received: by outflank-mailman (input) for mailman id 1025497;
 Wed, 25 Jun 2025 19:47: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 1uUW5N-0000Z0-IC
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 19:47:09 +0000
Received: from DUZPR83CU001.outbound.protection.outlook.com
 (mail-northeuropeazlp170120005.outbound.protection.outlook.com
 [2a01:111:f403:c200::5])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2c003ca1-51fd-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 21:47:05 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by AS8PR03MB6869.eurprd03.prod.outlook.com (2603:10a6:20b:23f::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.29; Wed, 25 Jun
 2025 19:47:03 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%4]) with mapi id 15.20.8857.026; Wed, 25 Jun 2025
 19:47: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: 2c003ca1-51fd-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=iK7Yxtun2i6o05Wd1ERXr/9bIYZscElpKQjzz4zhqyDSBD87Nqed6gE7a0y3OPlPyX2tG7C6EWeQm1vAy4F2nUAJuoi9tgYBEO+FB+YPE4W5rAU48vFCyj2t2Tmsr1UhXjTE/MoLx3/xyZG6p5FcQwccC/fnZiIR5ZkOCV+Cuh14TB3YujaRU3DLD5h0lUQ7dK1cNJTLLtzWx0w0dUFLXPkWH2CWj/Md4caxMVvvav9gyp/28Uywzbafgm34H+4nlrZlAu63jZz4PvXMkPfx90LhZbEXyH0EI8MxwrLYbqhtY+MP5i0Xa4U2C4AUU/lbxns1ZKaIpepvFkLYUU+IYg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=pq0deBK2atO06y7P8Q70iCCGe0BtI6RVI0qpn1FQ574=;
 b=SrGpbJ87hgH3Uoml7WpONy54Dd1PaxsR/PXkQOt5cXdayL8fNPxZlliZnPC9rP9KhHITG1N6hrsKXoFO5oAAOzAD5Zj3z6ecLlk0xQjvUwtLI60rswJp/SRmf2SjyX1rIR5Unk/F6+vNhUljAPJCSsHFEpMccUStDxuEDbr/J1q7YO8uKiXG43oqU8E100nPhZj8MFXQQOyuimHB0M6sEfK2AZ2RT7dHnmCtEhv8d2Aq6rxr0J9U/FjDA1Pn47LeJ8d/P3a5k2ZxTlXcevJ339fAWB/14qiZ1+86e1mRL4x6TepNw7MoPM3i5l/Xpp4BrvcgD1YtvbXSUE8LhRewIw==
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=pq0deBK2atO06y7P8Q70iCCGe0BtI6RVI0qpn1FQ574=;
 b=daV5ezEewnldWJHzUtK7ckISaW+FGcECZd+FOoQl6STuM1NXM9fJtEWlSpy0Js718Y7+GoRmCZYRJQzjM2j6HpZe+WUWKYYSpedsBEICJlRKON/ADbcaxxaHqJLPpFnG/s4uyMS9bcrQfvmN0P3kua1ntAL41lvm1uEAGiFC0dEgzlnz0JZ89I4Z/tj7ukblthIppoC9yyCp4KQICiI1EvavioakB3lVp/wWEnUL20sDB1M8WSQ6JeGKWIw6qT2HYQBdbaFze5Z+53J64UiQnl+mjSxSZcHMxTProTayAWVHrAxdDlJiqd13C6RwVnRPB+u7j8DCX2OiGfo+J5guBg==
From: Oleksii Moisieiev 
To: Stefano Stabellini 
CC: "xen-devel@lists.xenproject.org" , Andrew
 Cooper , Anthony PERARD
	, Bertrand Marquis , Jan
 Beulich , Juergen Gross , Julien Grall
	, Michal Orzel ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Volodymyr
 Babchuk , Grygorii Strashko
	
Subject: Re: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC
 multi-agent driver
Thread-Topic: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC
 multi-agent driver
Thread-Index:
 AQHbyNXPHUV4T01ZEEC9Uxm0LaLKHbPgqpIAgB7nygCACJlwgIACrSiAgAUbw4CABI1zgA==
Date: Wed, 25 Jun 2025 19:47:02 +0000
Message-ID: <842fe403-5350-4bae-8fbc-736322b156d7@epam.com>
References: 
 <318044ae12f13b6b297b3f5fda577a1a6cd143da.1747669845.git.oleksii_moisieiev@epam.com>
 
 <6080ff71-2634-4269-8a63-fdafdf03f01b@epam.com>
 
 <769aad0a-8bee-45c6-8c5c-35f9d47ed8ae@epam.com>
 
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: PAVPR03MB8946:EE_|AS8PR03MB6869:EE_
x-ms-office365-filtering-correlation-id: 060120dd-2752-4b34-5634-08ddb4210eb0
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|7416014|376014|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?M3BHR0hjQnQ2clBGWTczSWF4bXRweWIrZzlGN2R5RTd5Y1JHOXN4enlsVExI?=
 =?utf-8?B?cU1RNFg4ZFQ0eE51c29XTTNiN09PZDRCdW81VnJCRW5kUFhKLzAyT3VXck1X?=
 =?utf-8?B?K0hwcjhBc3UzeUZ1aW5vLzlGR0puRFFCQWt1MlAySnByL0ROYkRNT1pmM1lL?=
 =?utf-8?B?ZWlsRXVIdEJsMmtWSjM5REs0anlrTDNUYmZ0N0xGdlhtZThQNXV5VFQ3Mkox?=
 =?utf-8?B?NGV1bWp5YW1wcUZvMlQyZlpOangvNTZETHU0c1dzUG1lT3RDbGpHMUI1cWxt?=
 =?utf-8?B?T0pjNTJ5ZHkxUVk4QmszQ2U3Nm1GK29WT3pzWitCR0lMSGUxbGN2UVJFa0N4?=
 =?utf-8?B?YVlLSjBzK295anVhRUhZSyt4SFNWd3JrRmZJWTBYcjNVaEV3eTlObnk1Z0V6?=
 =?utf-8?B?NnZrd0dSUkdXcWhmSitDaHBybHpXSzFxZmN0OWpUUU16Y25neldDY1hNNG1S?=
 =?utf-8?B?QVZneG1UMzFIVCtJUGpJSkxKMlJ2Y20xRk9Jb01rejIwN3VtT0I0UURXVXdu?=
 =?utf-8?B?QzV1Z2ZGZDZ4aitidlN2UndnV1hlcjRZeVY5V0Q3WWYrWVMvWkVwSTJmV0Mr?=
 =?utf-8?B?REFwSWxNbG5YR1NaMHFEdlFFYzVvdUg3c3hXeE5iclNJL0tHT0NxL1V6Rmho?=
 =?utf-8?B?YmlLVG1yR281M01kdzVlMnFOUEFXTzBnWHBWUmlLRXVmL3ptVGxQdERqM0Fy?=
 =?utf-8?B?QlorMTVGUkJDc1h3S0dqdlNwMEVWK0E5TnZSMmczM1BvZzlFd1MrS3RpYkZa?=
 =?utf-8?B?M2JyNkpNSmMrNnl5aUhMZGhrNUNFZHhBQm8rYi9BUlc1UXRWL3V2UFZ0T1J2?=
 =?utf-8?B?UFgyZUJEOUF0QUNnaFBWdXBZTWlWeGd5SUVPak90T215WmlMWWl4YStRS1o0?=
 =?utf-8?B?a2x1ZEN2WUVyV1pDNndRRkJWWWEzQ1lPNjNKZmdXSDk5ekh5UkFMVUlFNW5X?=
 =?utf-8?B?ajFmUEF1dWFhMlVvWktmcGFLRjgrN3BMYnBMSExiamZYNkI1S25TZDEwdzc3?=
 =?utf-8?B?T2pnNzJNR09lczh2VVQ5cHdLT2M3dVZIRG5vMmdoVm5mRUhyeURyVSs3VWZZ?=
 =?utf-8?B?UXVLeGM5ZlcvYXAzMFJiam55SzVJSmErK0hJcTFYN0VJcHhPV0tNektZUG9w?=
 =?utf-8?B?b1BhcGFNRDN1REtGakRZNjFEa1drZ1h2QThQMlNpbzVQVS9MQm9Cc2l1Unps?=
 =?utf-8?B?WHpMSkYveHpZU05sWDBoRmliY25XbmZRekhuaHo1dmNmUDF1ekI5b1hRUEJG?=
 =?utf-8?B?MWJ0MGc3SUlGaSszbHBFdDF1NzE3VFpHalBJVFRpV1EwSkNQekZOZWNKMkVE?=
 =?utf-8?B?a3pjL2ZzWFJDUENVVG5HN0RPeUJ1ZDBpR3hWOU9FL2krWS9iZTdXaXA3ZFJw?=
 =?utf-8?B?TkV3T0Z5UzFpU3VKa3BPVHltOC9QVmRuSFk0bGNXSmRKVExvSVAzY0JNdENU?=
 =?utf-8?B?WmppMGdBdytEVnRLMzM1S3orc3dxaldyRHZRcy9lVzlxZXBoNHUybjhKQjhG?=
 =?utf-8?B?dElwanBLRjNFSllUS3A0MlVSeWVOdkZsZHBiZjJuYVRWUTQzQ3lndHpySGFt?=
 =?utf-8?B?R3BlU2xaOW1HZ3BuTmdmTjJWNUxzelBCWTc0WFFjcGdRZk5kUnNaY3g3TGF5?=
 =?utf-8?B?MTc0QUliTGFnRzdZUnZxUGJVd1RBUmgxZjNjVjJ3bHNkSXFpNmIxTHVsbTdV?=
 =?utf-8?B?TWtLRVBTM1hrUFRjaGN3cDhWUmgrUEZOWDZMdW5mU0ZFQlAxMWVPdHYrUDhP?=
 =?utf-8?B?UjRvSHhyOTFtUTN5VFN3eDRkSmc2RU9SU1hiZ2REK2YvdXRHcUNyMUhFZE45?=
 =?utf-8?B?RTZ6cUFQb2gxam5lTlo0d3lnVWd6Rm1PRkEyd0k2WjVzQnhIcW44NEx4VCtO?=
 =?utf-8?B?OG4xS3pMVFJJU09aYmZtNFRuU0NOYnAza1NCcW9ZdXJKdXZlUGNEY2VwYWdT?=
 =?utf-8?Q?bHclW8dTCFc=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?NUJKQmtGcnhoUGk0WnZkYlowV2lodzZQNU5jeSt6bHRBY1RkWlh5UkpkTi90?=
 =?utf-8?B?TFJIVStVaWJOSEpKN0diZ3lXTTJQWGo5U3Z5T1NYeDZidmMrOVM2b0RDWWpl?=
 =?utf-8?B?SDBvbEZ2Z1ZFZmlLOVF6S1dyNDc3MWV4TlFiTFlQdWp6SWdQOU5BcVBuRms3?=
 =?utf-8?B?aUd3c0VtU0ozQ1NIcWJRY2wzNVM4bGM5ZVkyV3dhdVdOWHZiTm5POE1ybHpy?=
 =?utf-8?B?TEc4bXlMQzluVGNyNFYrZ0lEaFdDREtkV3FpNkkxSERDQmZvWEFiQnl1MGpM?=
 =?utf-8?B?US96RUVDc1Roc0J3OXhtV3BwVzg0MmVWMU1tL05FS3lORFlDb0ZLMUU0TGVh?=
 =?utf-8?B?TnZLb2d5VmMzZEE0cktOSXpRWnpDZ0JKT1NjUVcwV2g4L1gwZnJJSjFRcXc5?=
 =?utf-8?B?VnFkUmo4VFRmc3MxUnJpbU5iZGc5ZDV3VU5DdnBoam9IcnJMa2R6a3hXR1Ns?=
 =?utf-8?B?blp5ckJhVm1hMUFkZTRUQ1M0ZEx5R0Njc1BlNS9NRFNkUEUvekdJL3NXZXdM?=
 =?utf-8?B?QVlEeXFnRWlNTDBZdHdTdndvRHc4SmhOS2loREdycnpiUUpIUDZPRDZ6WnZz?=
 =?utf-8?B?akduRW1QZmpQNno2RDEyWkVZZHduNmFhRldLdUhvTml0Z2ZYRVlhZ3p3SUtZ?=
 =?utf-8?B?NDFnNWs0MGNXZEYrbU1kUXZCRHQyR0FSTlIxQm15YkhIMUZpbitUYmhoeitE?=
 =?utf-8?B?NVR3cVFKWmxyaEdZRy9RU3J0T0h4R3lMZzkySUt4QXozQW8zcU4xc3VrRDBY?=
 =?utf-8?B?OXhhOCtlVUt3cURkVW8zWUZQUHkrZnhyMC9mMkI4WUxOK3hHN3BmYlYyMElT?=
 =?utf-8?B?dWxhaUdya2QrMlh6a0pyVEo0bEV5NVZ2S0MxZFYxTEtsWUV2ZElDb3gyQklo?=
 =?utf-8?B?M1VCVWFBbXVlc2F0YXA5cklUeVlKSklZdU5tQk54dGxXSW1nUkxPbXdvNnRh?=
 =?utf-8?B?MTdOdkM2eHJMQXZmSUwzSnd5WTJwekJESTNWOTdlUkFON000QVNEdC9uZW5j?=
 =?utf-8?B?UVlZZDJoRnkxa01DYWkyQmRWWTVpdHB3QWtNMEJmeWdKWTZIdkphZEl6SXh0?=
 =?utf-8?B?OXZlTEoweE9ncEx6WDFlekJXZUI4RjFrcHhzNTRhdlAwRllRYjhMa1h5ZzVj?=
 =?utf-8?B?aGVjL0VPTFBQeUFJUldkeEJ6Vkc3T1Fyd25sYTZIN1ExYSsvaDlNcThwaXJX?=
 =?utf-8?B?OVB2dk8ybUZDVnNsVlNibTQwNkY1ZVBqa1krelhLZ3RDVXVvdjhPVjZMOVdl?=
 =?utf-8?B?ekhacGViN2w2R2J3OC9tdjFyaVNweFFpOUYxTUNrd2Z6bGpPc1RXK0NaV05l?=
 =?utf-8?B?QmJlODVGeC9keUFSZVBHWTNYNUNjM0NiTkt6ai9UTU56N0hiaGhxQ1NvK2JQ?=
 =?utf-8?B?T0lIZjFlSnZiQnBqOWdCUm5sTVNxMndXazJ4SWcxOHhQY2VQWkFwbC96WVVw?=
 =?utf-8?B?cUhyRXBERlloUVVZeXNzS3lZanZGUnR4dkhYTTV6OFFSSlNQbXZIcDFoN1M5?=
 =?utf-8?B?WW4zRVJqcElVQ25UdTNtWkVhWHRxbXJaNGhlYlM1TXdUeDFvd09JMytTMGt1?=
 =?utf-8?B?SXlKZ24ySFRvQ3V5ckJhdktROUtDZTFFcklkQmxVOWQ5N2F4V082czF2dUtk?=
 =?utf-8?B?NGswbEh2K0VhOEdKY0xHcTB2dkpMNmY2ejZZaS9LRHArVTlJeFNoMG4wcVBU?=
 =?utf-8?B?QlI3VHJrZjJ5SHdVQTdmSHJQVkltcHAvWEg0ek0zQUNacm5uSmpyRnJ2emdX?=
 =?utf-8?B?ZmJHMnlEUDVHUDZGUkNDZlJMc21OaWl6V2RoajNVZDhlRzAvalhicEVqV2hB?=
 =?utf-8?B?WHpZZGNtVEgydFJNYkQ4WkpJaWtSK1B4SWhYci85MUxoMjB4ZkdEdGo1azFv?=
 =?utf-8?B?ZkhyL0w5dm5CY1h0bnZZQ3pWZk40TjhDaG9OYksrMjVqYjJNTEI5Um5VWTlR?=
 =?utf-8?B?TVBVTFpMRlBBZ2hjam8rMkZ4bVk2YnNLU01PZngwTXlFUERkeEs1cjFnd3kw?=
 =?utf-8?B?VTdLRUhqbzlQMEtKWXEyMU1iaXZoRGM4V2lPNVk4NjY2a3dpUy82WDZGS0t2?=
 =?utf-8?B?Z3N4cWRtRVRIdjJxdnpNZXRDVmFzMjFPM1o2NS9rYUJaeGRCR1VPZkN6TmdZ?=
 =?utf-8?B?czd5bHJEb0d6Z3hwSlZraFc2V3dpc2JPWnNJT3N1MU9FNjFwNjZuNnF5OVBX?=
 =?utf-8?B?WGc9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 060120dd-2752-4b34-5634-08ddb4210eb0
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2025 19:47:02.9754
 (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: HIuWQbU3ulxLjc1wxj/UmrAK0FlorpxctTOB5bNOxN2Gqy0aLE2cAzbZ3cvDhglpolGvUEU7/BwDU1xflnOoBshczRy5lNAECvLowPYnWq4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB6869

DQpPbiAyMy8wNi8yMDI1IDAxOjE1LCBTdGVmYW5vIFN0YWJlbGxpbmkgd3JvdGU6DQo+IE9uIFRo
dSwgMTkgSnVuIDIwMjUsIE9sZWtzaWkgTW9pc2llaWV2IHdyb3RlOg0KPj4gT24gMTgvMDYvMjAy
NSAwMjoyMiwgU3RlZmFubyBTdGFiZWxsaW5pIHdyb3RlOg0KPj4+IE9uIFRodSwgMTIgSnVuIDIw
MjUsIE9sZWtzaWkgTW9pc2llaWV2IHdyb3RlOg0KW3NuaXBdDQo+Pj4+PiBBcmUgeW91IHN1cmUg
aXQgaXMgd29ydGggdG8gZ28gdGhyb3VnaCBhbGwgdGhpcyB0cm91YmxlIHRvIG1vZGlmeSBGRFQg
aW4NCj4+Pj4+IHBsYWNlIHdoZW4gd2UgY291bGQgc2ltcGx5IGdlbmVyYXRlIHRoZSBEVCBub2Rl
IGZyb20gc2NyYXRjaCBsaWtlIHdlIGRvDQo+Pj4+PiBmb3IgZXhhbXBsZSBmb3IgdGhlIEdJQz8g
VGhpcyBzZWVtcyB0byBiZSBtb3JlIGVycm9yIHByb25lIGFzIHdlbGwuIElzDQo+Pj4+PiBnZW5l
cmF0aW5nIGl0IGZyb20gc2NyYXRjaCBpcyByZWFsbHkgZGlmZmljdWx0PyBJZiBpdCBpcyBkaWZm
aWN1bHQgdGhlbiBPSy4NCj4+Pj4+DQo+Pj4+IEluIHRoZSBsYXN0IHBhdGNoIFswXSBvZiB0aGUg
c2VyaWVzLCB0aGVyZSBpcyBhIHByb3Bvc2FsIHRvIHNlcGFyYXRlDQo+Pj4+DQo+Pj4+ICAgICB0
aGUgWGVuIHByaXZpbGVnZWQgYWdlbnQgZnJvbSB0aGUgRG9tMCBhZ2VudC4gVGhpcyBlbGltaW5h
dGVzIHRoZQ0KPj4+Pg0KPj4+PiBuZWVkIHRvIG1vZGlmeSB0aGUgWGVuIERldmljZSBUcmVlIEJs
b2IgKERUQiksIHdoaWNoIGlzIGEgcG9zaXRpdmUNCj4+Pj4gaW1wcm92ZW1lbnQNCj4+Pj4NCj4+
Pj4gc2luY2UgdGhlIERvbTAgYWdlbnQgbm9kZSBpcyBhbHJlYWR5IHByZXNlbnQgaW4gdGhlIGRl
dmljZSB0cmVlLg0KPj4+Pg0KPj4+PiBIb3dldmVyLCB0aGUgaXNzdWUgd2l0aCBTQ01JIG5vZGUg
Z2VuZXJhdGlvbiBsaWVzIGluIHRoZSBuZWVkIHRvIGhhbmRsZQ0KPj4+Pg0KPj4+PiB0aGUgbGlz
dCBvZiBwcm90b2NvbHMgdGhhdCBhcmUgc3VwcG9ydGVkIGFjcm9zcyB0aGUgc3lzdGVtLg0KPj4+
Pg0KPj4+PiBJZiB3ZSB3YW50IHRvIGdlbmVyYXRlIHRoZSBTQ01JIG5vZGUgZm9yIERvbTAsIHdl
IG5lZWQgdG86DQo+Pj4+DQo+Pj4+IENvcHkgdGhlc2UgcHJvdG9jb2xzIGZyb20gYSBjZW50cmFs
aXplZCBvciBwcmVkZWZpbmVkIHNvdXJjZS4NCj4+Pj4gU2V0IHRoZSBjb3JyZWN0IHBoYW5kbGUg
Zm9yIGVhY2ggc3Vibm9kZSB3aXRoaW4gdGhlIFNDTUkgbm9kZSwgZW5zdXJpbmcNCj4+Pj4NCj4+
Pj4gYWNjdXJhdGUgcmVwcmVzZW50YXRpb24gYW5kIGZ1bmN0aW9uYWxpdHkuDQo+Pj4+IFRoaXMg
ZXh0cmEgc3RlcCBvZiBtYW5hZ2luZyB0aGUgcHJvdG9jb2xzIGFuZCBwaGFuZGxlcyBhZGRzDQo+
Pj4+DQo+Pj4+IGNvbXBsZXhpdHkgYnV0IGlzIG5lY2Vzc2FyeSBmb3IgZW5zdXJpbmcgcHJvcGVy
IHN1cHBvcnQgZm9yIERvbTAuDQo+Pj4+DQo+Pj4+IFswXQ0KPj4+PiBodHRwczovL2xpc3RzLnhl
bnByb2plY3Qub3JnL2FyY2hpdmVzL2h0bWwveGVuLWRldmVsLzIwMjUtMDUvbXNnMDEwNDEuaHRt
bA0KPj4+IEkgd2FzIG9ubHkgY29tbWVudGluZyB0aGF0IHJhdGhlciB0aGFuIHRyeWluZyB0byBt
b2RpZnkgdGhlIERUIGluIHBsYWNlDQo+Pj4gd2UgY291bGQgY3JlYXRlIHRoZSBub2RlIGZvciBE
b20wIGZyb20gc2NyYXRjaCAoYXJ0aWZpY2lhbGx5KSwgYmFzZWQgb24NCj4+PiBob3N0IERUIGlu
Zm9ybWF0aW9uIGFzIHJlcXVpcmVkIChmZXRjaGluZyBkYXRhIGZyb20gdGhlIGhvc3QgRFQgYXMN
Cj4+PiByZXF1aXJlZCBhbmQgY29weWluZyBpdCB0byB0aGUgRG9tMCBEVCkuDQo+Pj4NCj4+IFRo
ZSBwcm9ibGVtIGlzIHRoYXQgc2NtaSBub2RlLCBhcGFydCBmcm9tIHRoZSBkZWZhdWx0IHBhcmFt
ZXRlcnMgaGFzIGENCj4+IGxpc3Qgb2YNCj4+DQo+PiBzdXBwb3J0ZWQgcHJvdG9jb2xzIHdoaWNo
IG1heSBiZSBkaWZmZXJlbnQgZm9yIFhlbiBhbmQgRG9tMCBzbyB0bw0KPj4gZ2VuZXJhdGUgRG9t
MCBub2RlDQo+Pg0KPj4gZnJvbSBzY3JhdGNoIHdlIG5lZWQgdG8gY29weShvciBldmVuIGdlbmVy
YXRlKSB0aGVzZSBub2RlcyB3aGljaCB3aWxsDQo+PiByZXF1aXJlIGNvbXBsZXggaW1wbGVtZW50
YXRpb24uDQo+Pg0KPj4gSW4gY29udHJhcnksIGlmIHdlIGdvIHdpdGggaW1wbGVtZW50YXRpb24s
IHByb3Bvc2VkIGluIHRoZSBsYXN0IHBhdGNoIC0NCj4+IHRoZW4gd2UgY2FuIGhhdmUNCj4+DQo+
PiBtb3JlIGNsZWFuZXIgWGVuIGRldmljZSB0cmVlLCB3aGljaCB3aWxsIGxvb2sgbGlrZSB0aGlz
Og0KPj4NCj4+IGBgYA0KPj4NCj4+IGNob3NlbiB7DQo+Pg0KPj4gICAgICAgc2NtaV94ZW46IHNj
bWkgew0KPj4NCj4+ICAgICAgICAgICAgIGFybSxzbWMtaWQgPSA8MHg4MjAwMDAwMj47DQo+Pg0K
Pj4gICAgICAgICAgICAgc2htZW09IDwkc2htXzA+Ow0KPj4NCj4+ICAgICAgICAgICAgLi4uICMg
bm8gcHJvdG9jb2xzIGRlc2NyaXB0aW9uIGhlcmUNCj4+DQo+PiB9Ow0KPj4NCj4+IGZpcm13YXJl
IHsNCj4+DQo+PiAgICAgIHNjbWkgew0KPj4NCj4+ICAgICAgICAgICAgIGFybSxzbWMtaWQgPSA8
MHg4MjAwMDAwMz47DQo+Pg0KPj4gICAgICAgICAgICAgc2htZW09IDwkc2htXzE+Ow0KPj4NCj4+
ICAgICAgICAgICAgIHByb3RvY29sQFh7DQo+Pg0KPj4gICAgICAgICAgICAgfTsNCj4+DQo+PiAg
ICAgIH0NCj4+DQo+PiB9Ow0KPj4NCj4+IGBgYA0KPj4NCj4+IEluIHRoaXMgY2FzZSwgd2UgZG9u
4oCZdCBwcm92aWRlIGFueSBwcm90b2NvbCBpbmZvcm1hdGlvbiBmb3IgdGhlIFhlbg0KPj4gYWdl
bnQgYW5kIGluc3RlYWQgc2V0IHByb3RvY29scyBmb3IgRG9tMC4NCj4+DQo+PiBUaGlzIGVuc3Vy
ZXMgdGhhdCBlYWNoIG5vZGUgaGFzIHRoZSBpbmZvcm1hdGlvbiBpdCByZXF1aXJlcy4NCj4gTGVh
dmluZyBhc2lkZSBob3cgd2UgZ2VuZXJhdGUgdGhlIGRldmljZSB0cmVlIG5vZGVzIGZvciBEb20w
LCB3aGljaCBpcw0KPiBvZiBtaW5vciBpbXBvcnRhbmNlLCB3ZSBoYXZlIHR3byBwb3RlbnRpYWxs
eSBjb25mbGljdGluZyBnb2FsczoNCj4NCj4gMSkgbm8gWGVuLXNwZWNpZmljIGNoYW5nZXMgdG8g
RGV2aWNlIFRyZWUgb3V0c2lkZSBvZiAvY2hvc2VuDQo+IDIpIFdoZW4gWGVuIGlzIHByZXNlbnQs
IFhlbiBzaG91bGQgYmUgdGhlIG9uZSB1c2luZyB0aGUgaW5mb3JtYXRpb24gaW4gdGhlIEhvc3Qg
RGV2aWNlIFRyZWUNCj4NCj4gV2l0aCAxKSwgSSBtZWFuIHRoYXQgdGhlIEhvc3QgRGV2aWNlIFRy
ZWUsIG91dHNpZGUgb2YgdGhlIC9jaG9zZW4gbm9kZSwNCj4gc2hvdWxkIGJlIHRoZSBzYW1lIGZv
ciB0aGUgQlNQIChubyBYZW4pIGFuZCBmb3IgWGVuLiBUaGF0IGlzIGJlY2F1c2UgaXQNCj4gc2hv
dWxkIGRlc2NyaWJlIHRoZSBwbGF0Zm9ybSwgbm8gbWF0dGVyIHRoZSBzb2Z0d2FyZSBydW5uaW5n
IG9uIGl0LiBBbHNvDQo+IGF0IHRoZSB0aW1lIHRoZSBEZXZpY2UgVHJlZSBpcyBnZW5lcmF0ZWQs
IG9mdGVuIGl0IGlzIG5vdCBrbm93biBpZiBYZW4NCj4gd2lsbCBiZSBydW5uaW5nIG9uIHRoZSBw
bGF0Zm9ybSBvciBub3QuDQo+DQo+IFdpdGggMikgSSBtZWFudCB0aGF0IGlkZWFsbHkgd2hlbiBY
ZW4gaXMgcHJlc2VudCwgWGVuIHNob3VsZCBiZSB0aGUgb25lDQo+IHRvIHVzZSB0aGUgaW5mb3Jt
YXRpb24gdW5kZXIgL2Zpcm13YXJlL3NjbWksIGJlY2F1c2UgWGVuIGlzIHRoZQ0KPiBwcmluY2lw
YWwgU0NNSSBjbGllbnQuIFRoZW4gWGVuIHdvdWxkIGdlbmVyYXRlIHNvbWVob3cgdGhlIFNDTUkg
ZGV2aWNlDQo+IHRyZWUgbm9kZXMgZm9yIERvbTAgYW5kIHRoZSBEb21Vcy4NCj4NCj4gMSkgaXMg
bW9yZSBpbXBvcnRhbnQgdGhhbiAyKS4NCj4NCj4gPkZyb20gd2hhdCB5b3Ugd3JvdGUsIGl0IGxv
b2tzIGxpa2UgdGhlIFNDTUkgZGV2aWNlIHRyZWUgbm9kZXMgYXJlDQo+IGRpZmZlcmVudCBiZXR3
ZWVuIExpbnV4IGJhcmVtZXRhbCBhbmQgWGVuLiBJZiAvZmlybXdhcmUvc2NtaSBkZXNjcmliZXMN
Cj4gd2hhdCBMaW51eCBiYXJlbWV0YWwgc2hvdWxkIHVzZSwgdGhlbiBpdCB3b3VsZCB3b3JrIGZv
ciBMaW51eCBiYXJlbWV0YWwNCj4gYnV0IGl0IHdvdWxkICpub3QqIHdvcmsgZm9yIFhlbidzIG93
biBTQ01JIGNvbm5lY3Rpb24uIElzIHRoYXQgY29ycmVjdD8NCj4NCj4gSWYgdGhhdCBpcyB0aGUg
Y2FzZSwgdGhhdCBpcyB1bmZvcnR1bmF0ZS4gV2UgbmVlZCB0byBjb21wcm9taXNlIG9uIDIpLg0K
Pg0KPiBJIHdvdWxkIGtlZXAgL2Zpcm13YXJlL3NjbWkgYXMgdGhlIG9uZSB1c2VkIGJ5IExpbnV4
IGJhcmVtZXRhbCBiZWNhdXNlIEkNCj4gdGhpbmsgd2Ugc2hvdWxkIHVwaG9sZCAxKSBhYm92ZSBh
bGwgZWxzZS4NCj4NCj4gVGhlbiB0aGUgWGVuIFNDTUkgbm9kZXMgY291bGQgYmUgcGxhY2VkIHVu
ZGVyIC9jaG9zZW4uIFRoaXMgaXMgbGVzcyB0aGFuDQo+IGlkZWFsIGJlY2F1c2UgL2Nob3NlbiBz
aG91bGQgY29udGFpbiBYZW4vTGludXggY29uZmlndXJhdGlvbnMsIG5vdA0KPiBmaXJtd2FyZSBp
bnRlcmZhY2VzLiBCdXQgaXQgaXMgdGhlIGJlc3Qgd2UgY2FuIGRvIGluIGEgZGlmZmljdWx0DQo+
IHNpdHVhdGlvbi4NCj4NCj4gSSB0aGluayB0aGF0IHdoZXRoZXIgdGhlIERvbTAgZGV2aWNlIHRy
ZWUgbm9kZXMgYXJlIGFydGlmaWNpYWxseQ0KPiBnZW5lcmF0ZWQgYnkgWGVuLCBvciBjb3BpZWQg
ZnJvbSB0aGUgSG9zdCBEZXZpY2UgVHJlZSBzb21ld2hlcmUsIGl0DQo+IG1hdHRlcnMgbGVzcy4N
Cg0KSSBjb21wbGV0ZWx5IGFncmVlIHdpdGggeW91ciBwb2ludC4gVGhhdOKAmXMgd2h5LCBkdXJp
bmcgdGhlIGRpc2N1c3Npb24gb2YNCnRoZSBsYXN0IHBhdGNoIGluIHRoZSBzZXJpZXMsIEkgcHJv
cG9zZWQgYW4gYXBwcm9hY2gNCg0KdGhhdCBrZWVwcyB0aGUgL2Zpcm13YXJlL3NjbWkgbm9kZSB1
bmNoYW5nZWQgaW4gdGhlIEhvc3QgRGV2aWNlIFRyZWUNCihEVCkgYW5kIHBsYWNlcyBhbGwgWGVu
LXJlbGF0ZWQNCg0KY2hhbmdlcyBpbnNpZGUgdGhlIC9jaG9zZW4veGVuLGNvbmZpZyBub2RlLg0K
DQpJIHBsYW4gdG8gZm9sbG93IHRoaXMgYXBwcm9hY2ggaW4gdjUuDQoNCkhlcmXigJlzIHRoZSBs
aW5rIHRvIHRoZSBtZXNzYWdlIHdoZXJlIEkgcHJvdmlkZWQgYSBEVCBleGFtcGxlIHRoYXQNCmVu
c3VyZXMgdGhlIC9maXJtd2FyZS9zY21pIG5vZGUgcmVtYWlucyB0aGUgc2FtZSBhcyBpbiB0aGUg
SG9zdCBEVDogWzBdLg0KDQpbMF06DQpodHRwczovL2xpc3RzLnhlbnByb2plY3Qub3JnL2FyY2hp
dmVzL2h0bWwveGVuLWRldmVsLzIwMjUtMDYvbXNnMDE0MjEuaHRtbA0K


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 19:47:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 19:47:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1025510.1401045 (Exim 4.92)
	(envelope-from )
	id 1uUW5w-0000zH-B0; Wed, 25 Jun 2025 19:47:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1025510.1401045; Wed, 25 Jun 2025 19: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 1uUW5w-0000zA-8J; Wed, 25 Jun 2025 19:47:44 +0000
Received: by outflank-mailman (input) for mailman id 1025510;
 Wed, 25 Jun 2025 19:47: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 1uUW5u-0000Z0-OU
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 19:47:42 +0000
Received: from AS8PR03CU001.outbound.protection.outlook.com
 (mail-westeuropeazlp170120005.outbound.protection.outlook.com
 [2a01:111:f403:c201::5])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4121320b-51fd-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 21:47:41 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by GVXPR03MB10803.eurprd03.prod.outlook.com (2603:10a6:150:221::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.29; Wed, 25 Jun
 2025 19:47:38 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%4]) with mapi id 15.20.8857.026; Wed, 25 Jun 2025
 19: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: 4121320b-51fd-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=eZiN0OFOY5nxg2y61QeIORF4AUtkMVEaJDBvnqXP+JAeoXhWSbSbn4XlrXqVT2tqaWP1V7FwxxbrzNtVViCI2qI/FY81fEUKDPnFA9QqVByo64jJ3Uqi7xQaBZMtr00953kAzQ+setQn9m8YdTET+o+BmpvPtpgtuDzWH4rmyuIGzIZb7YEL6NL00VNWd+Aon1hxSR9h1Re0bs+xxGalz40z3+xTQEqbfypl3lqTZBaE0Ub6BK5JyQI6OKF4tGNhap+2iHwvt7VkPE4VNlbPkhHWm/JTlFdY/wkj3uCyvDB8LqRvKaXEkJsa9kJltmyI9N+ZhadfDaTwoZPbJsbS/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=0+ImBwAG3nv9PtIK6NLMZYGR3Q1CHLpmGvC3XPvbaS0=;
 b=dke8apB+N5UYRRxeADJUh/kXQvogWNFXD/EcN9qv6LoMMnakoJhxPnhVRnZcNdzCRF4vEVDykqITe8oT86nr/BTvwljZUifCASSux4YmXBHOQ7kyC8b0ahJlCLbW0No7geNkDa5PQ8e6dWgc4naKeTxkGe4MpmMqSHRN49sPczHstCo17ZVd5boOGa6LxGr7JjbDnk+B+1bLSfgjuKvikOJ79ip3t9f70W30MxvixN9pNWEAaojLzugkvJxRp0S3fvJSFNDH1C4X7AOhAsLrTx95uarF0G2N4+5Z1cW7WEWftf5S3hXNatg0+vlI0nrO7Sy4dx9cIZcHZUoGAsBTRQ==
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=0+ImBwAG3nv9PtIK6NLMZYGR3Q1CHLpmGvC3XPvbaS0=;
 b=vj7KLOfAPpIU2RFgibGmnw+PlXJEtPkaQqHMUbkCNEM+0qPm0dkwmrxqxL1mvgszSpjf9NgB9vPxDAPv2tkdDtUqOP/f/sPn+W2oP8tK/B0qNXXjvCwncjrGxj9roI7apOpD6ZkdXIeDRtD7vInBAnBidPA4wS5geT4M51dn2+5GMIaAltpqd8L/BlE+yPGxugsh8HSdNQxuyPx8bOVXOR3j5rlt+WRartkaBDbk3QQ95wmjwWGE8DbhYXh3iAX9t2R/eAoBIkiKkSZQLe2MvMmr7b9l8OyCPuikcYh4XJG7M8siE48LeQPlzNx3BWwE2CqGYH7cBnREu/WhucHgkw==
From: Oleksii Moisieiev 
To: Julien Grall , Stefano Stabellini 
CC: "xen-devel@lists.xenproject.org" , Andrew
 Cooper , Anthony PERARD
	, Bertrand Marquis , Jan
 Beulich , Juergen Gross , Michal Orzel
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Volodymyr Babchuk ,
	Grygorii Strashko 
Subject: Re: [RFC PATCH v4 8/8] docs: armproposa: l to add separate SCMI node
 for Xen agent
Thread-Topic: [RFC PATCH v4 8/8] docs: armproposa: l to add separate SCMI node
 for Xen agent
Thread-Index: AQHb4TVhOpwmaSC7dkC7oLLOKyrberQPvwGAgACpCACAA+mNgA==
Date: Wed, 25 Jun 2025 19:47:38 +0000
Message-ID: 
References: 
 <3f7e1e99f5d1018064f3c4825aff16bd487cf558.1747669845.git.oleksii_moisieiev@epam.com>
 
 
 
 
 
 <3468bb57-3178-460b-8fb2-3ce106475319@xen.org>
In-Reply-To: <3468bb57-3178-460b-8fb2-3ce106475319@xen.org>
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: PAVPR03MB8946:EE_|GVXPR03MB10803:EE_
x-ms-office365-filtering-correlation-id: 1eca9613-82d7-4346-e0bf-08ddb42123a4
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|7416014|376014|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?UWtXOTdsMmJkUENUb0x1WXBkZGF1RUlNdVV3Q2FnRDUwK1NZRzZTTURqcDFm?=
 =?utf-8?B?UnZ6YlJMTWlWdFVWdDNNbFhYK2trSFdYa2RuWnMxOFh5d1NTcEZOVzYzYURH?=
 =?utf-8?B?T1hGckUxNDVvL29hVngzMDhYM1ZTbytmaVZEeUdNeFdFdkNaandobkNOSmkr?=
 =?utf-8?B?YXNBSWNzRlVOU3JkR0wzd3c3UVBuZStmbHFBeUNRZWpsTm5CS2w3QVZhdHZv?=
 =?utf-8?B?UDR3UjFYOVFKN0tLc3A1VDNkNEJqZjlQWEJhV3c2YU5CTDRlRktwTFNuMU5F?=
 =?utf-8?B?Q0VDNnVsVEZSQ3NyMDZiTC83TDUrTUVkRkoxUkVoSXRPZ2pNa0htRzdqdWxz?=
 =?utf-8?B?RkJyd3hRZ3l1NGlNQjVTRm1YVXJPYnB5MmNmeW1wbjQvdVBvTU11QmU1Vyt6?=
 =?utf-8?B?cjZudnZsRURIeENGM1VIYUZmTUJaVU40M3o3eHJuRnhYS0YyMDg1aWQ4TzhP?=
 =?utf-8?B?RnVIL3BMWUpKODZnV0JWcnhEb1BRZ2RvKzlieU41cnAzTmFVN2JCTlpPVkJw?=
 =?utf-8?B?eVpEd2FPdVJhb2FSUXMwQm9tcnZuMVhLcVlidUZYbHFZcEpvalhlb0pZUTFK?=
 =?utf-8?B?S3phLy9YUXdtd0Nrb0JYOEVLdU1BQy9ZaUtEV3VONUJ0ZCsvQ2IwOUEyT0I4?=
 =?utf-8?B?cUxLajBnOExFSDhaWjZBSi9KOHBQeHdqcTBBMklSYjBQTjc4SHl6NVZ0Nmc1?=
 =?utf-8?B?SjlVWEtoTUVFM0FIODZvQndUdm5qT2M3dDd2VFA2UDFvbHRaU2RIQzVPdzBw?=
 =?utf-8?B?VEVBeENnRUhlZ2tkK3FJakRYdGd4QXE5WGlCOSttNU8yZlNtMVdJK2FYV0xr?=
 =?utf-8?B?L2F0U3ZzQ2x3RktjSGhUN0hsblRCQUVZa0lkZEEwMHBtVlQvd3JUc01QWWRC?=
 =?utf-8?B?bGY1MXRLc3pUcnI1czhjcytJVERwNEZzaUdLNjZXYUI2L0VEVW9hRi8zR3JQ?=
 =?utf-8?B?WTFwQVMva0tGSkxtcTdOc1JjVEZpanF1d2swQXlscFVxVC9WOUlqVTA3ZWI0?=
 =?utf-8?B?ejU5am9qdXFPRm9Ud2M2dGVTWFVaZjIxNitTdmdqTFFiY1ZwaFoxNUhwa2pr?=
 =?utf-8?B?U1lZWUJVRm9OVjlGWTNPMHFzUmFLOC93MjljeldsQTFsN1I4RHVMblFUakty?=
 =?utf-8?B?MkpTeDB1VlNrTElYMHNxaEdKWWJFVDVDTkN0ZWFLeEphMjc1aDJEeEFrZS9v?=
 =?utf-8?B?cWE1TFpvYXFoUG5hazBObkRDR2RsbWVudGtRMWczMzZ6RHduMzRPQmp3VjBI?=
 =?utf-8?B?Wm5OODJ4OEg1QXVRTWxsUitwOXpSamJ6a1pEaFRaVXNocE1QTk5lOGdEcUxR?=
 =?utf-8?B?cEVEak8vLy9sZFhOamQ4TW5XWkVxUUdrVWc5a2xGV1NGeWlEUVNDZVhNUGtl?=
 =?utf-8?B?ODNPUzlNMU5mUWRHa3N0T052WEFKZDJ0S090Rm1kUUdwZjF4Z3I4THRjYzlF?=
 =?utf-8?B?VnJsbDBtT2Y3d2N2ZDhydFRsV3BoaEh2UVBNdi9Sa3h6cXdkb3J6bE1wa3lY?=
 =?utf-8?B?MmxxVXR1ams4YXlqaXdMTzViVnJXN2dtQXBRU0NmMWR2TkR1aW5pa2JGeVlk?=
 =?utf-8?B?NkQ0U1V5RmsvYWJOcHEvM2xCOWJjZDZEOS85QWtEdTc4cHNlMjBFRktMSzJk?=
 =?utf-8?B?UkRWZGIxbmVUVWVENWVRSlhMSzJTUkNGVnFSaTYyZzVtQmVrRGs3dlp3Tk9C?=
 =?utf-8?B?WTBiemp5SnlSQWw1SFFpOEFwZmFRKzZWbVlmbXF6VEFVWHgveUEzYVA3cnEw?=
 =?utf-8?B?UExQeENIUUN4NG5nNlNjY3FGS0d0Q2tPUE9TZjZwRWpOUGJKT2gwbG1EUDAw?=
 =?utf-8?B?R2hJdVRjd1p3cVRVZG1ibWVQbGRwdTZENjQvc05LeGF1YVNNOUhWUXEzUXVm?=
 =?utf-8?B?TVRhcUlsaDl5bnlidXpOWVkySW90RjkwOXpoUGNxbU8xUnQ4emQ3eXUvanh1?=
 =?utf-8?B?UFduZk1WbmxtaGJZVHpKOE96bnNhTXkrSWpEZS9kWUd4TFZXNDdnV2lCbnU0?=
 =?utf-8?Q?wRhVlUZaqfKI3i9qW0qP3Ayd/9R2OQ=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?MGl3SW93U01jWjh5aklsNFlzZ0gvRS9SdFhVdFJxRXRhbk0zMnB0ODY0aGkz?=
 =?utf-8?B?RDBrd3B0YVZ4WmU1RUhISFNQdHBmODFRd3RMU1IxYUNvK3lHeEthQ0NWMDJs?=
 =?utf-8?B?eDVpUWhPcUFJMWdwbjVqbVdsTVNWZTFDa25QUVNkUTdXaGJ6MjJQSTRUMDlm?=
 =?utf-8?B?QXg0V29NYVQwbWxwY2dEVDVaMGVrZUNkU3c1dXRMT2JNR2ZzSGxUZHdnWmhK?=
 =?utf-8?B?RjJ1RU8wdHB5bjEvOHEzdVpqaDVzNXN5L2xFaVJhSzNWcGMrQ2YvRmdHZFJO?=
 =?utf-8?B?bHlnNFpGamVIdUppQUlpNEVMYzlwaWQyeC81SVpWQW9kNTB5aStBRXZ5QW1z?=
 =?utf-8?B?SHlheUd1M0dxVk96RmNCTXF4NHIxM2xyKzdJN3R6MnZVQVRBVWxKdStaRkpu?=
 =?utf-8?B?NjVSYytoczJ4eGVqMlRjR3owdlV2Uzh4bmRKM3RtV3ZncFNZbCtjaTJzUkov?=
 =?utf-8?B?bndMeVRkRGtXcjlhLyt5TDZYVEo1WmVHTmNsbVp5aGZsa3dxYkEwNXlSQkFP?=
 =?utf-8?B?RFBDSVlFOFRFVGphS1RIQWNtT2xERmRUT3BHYTVrUDVndE9uRHhZUmRDQjAz?=
 =?utf-8?B?L0RWTzhBWXYxM25jQWdXM05CdHZ4MFBjbEIrUFovMWQvbTJmQ1loZloyaDN1?=
 =?utf-8?B?eGNTOU9iSGhrVDExeVZYb0pkSUoxSmdWOEExWlo0N2l0SHFGMSsyWmJ4Vlc5?=
 =?utf-8?B?NnhYUnB5KzRRekRhbTlMWnBaVndhMVlVaVFyZDVTVWtXTDU2OVViRU9CbXhC?=
 =?utf-8?B?ajE5cUNGWmRtK0NRZXVSbXRGOWplS1lxV2dOUDNnWmR4Wll5cll6R245UVVn?=
 =?utf-8?B?QnpWSFBqY252ekxvTmRmWFh3cHN4NE8wNDYrY3ZwRU44UWhKSWdyNWJTZE1t?=
 =?utf-8?B?c2FVaU1UenlweXh6akk1eHdDdTFpMFJ1alhmRnl6eG5NUFNtR3F2TjE3V0ds?=
 =?utf-8?B?RVpabzBNUHkvQW1qM3I1cFdDWnJmOVdEcU0za2JBNi93d0dvcEhkd0dRRTUy?=
 =?utf-8?B?UW16bjlHU2ZJc08zTFh3eml2S2lHV1d2OFQyWHlZUk9iZG12ZTV5aWJUc3Mr?=
 =?utf-8?B?UlB3WXNjcTYvK3dtR09nWUJRNFRuN2FtMW90OUJCdnZmcmlDWGRaVTB4TnFm?=
 =?utf-8?B?K1pvc25QVTJkTFEvTGsrTmFKRHFLVlgyQVQ3djRUSHFSWWNjMUsvRUU5Y2kr?=
 =?utf-8?B?bjlqM2dBUVFFVDdHWnZ2WHE4ZGpiYW14eEhFek11dlRZSjZFZnJqclcvQlFh?=
 =?utf-8?B?SjBJMGo2TDB3QW9jM3hzWUZvWS96VFgxb2d1S2NKcm80TEZBVjJLMUhrcFpi?=
 =?utf-8?B?SldBWjUyWjVIcW5NTkNMUzJ5NDQ4WTlQaExRWmp4QTJ1T2JYQUE4OHdYUFRK?=
 =?utf-8?B?b0dUQzE2WmcwdlBjc2tXNmZBVTlnNW1oam1KcGMwREU5Q3hYQ2h0d003YmNW?=
 =?utf-8?B?b0pwaEkyMEhYUDljRFdLcDdDWmtCa2pwQ0tXRVZ3Z1d1eHBOTk9WYS9OelZa?=
 =?utf-8?B?TEdqaW1YbWlkbUszU09OKzF0ZTFyZXBpYjY0QWc0d3VUbzMwTDJwWE1UWnZo?=
 =?utf-8?B?RzVHczd6dUZTaGh3UFQvU3FxMVRsc0ZtakZDWWdhcFh1M2svbXRuUWNvb2sz?=
 =?utf-8?B?eW9xMWZrVVl3MWppc256T2szbm1QYWRJLzd4VmlVcm00RFhrcFh4b0tva1N5?=
 =?utf-8?B?VE9PSmlTaXloS01CaXRIM0JNa1NHWGx1Wk5xUmppWjVNTkhUOXk1ZmZmWE9X?=
 =?utf-8?B?OCtDb2xmcWRudmFLMDRkUXRTWWMxSnNnZWNtZ3dnb2FSZTVEbTlDMkxFeEVG?=
 =?utf-8?B?V0JsaXpkTUFwSDVhUExHZGJMU1N3L3FPVmF5OFRvOUZwV1ZIWUNkRjBmS3lO?=
 =?utf-8?B?MTZuMFdERWk5NU9yMnN0MFZyS0J3RFlDT0g2aTgyK25laDRWeVpMeU1scjc0?=
 =?utf-8?B?TXFNb0FheHJRU2FhRDNNSmp0VG1KWUJXQ3JWZ2k1REFoSWNrTS82aE0wOVZ0?=
 =?utf-8?B?UUVySDRmdHI2eXdIWTNkaFZPSFpVNzN5b2hiRTRrQzdBbTRkSUdIUkc1YXd4?=
 =?utf-8?B?akgxUzZ6eDkwWHFFd01odWRZNlBsUEFBL2FNUkY2cE5lNHRLZXVHSG12S2Zz?=
 =?utf-8?B?RXJmRWtTTzFtcWVtQlZKN3RiZ2NpV2FyelpjVGhxSWc2VzdJYzQzRXhEU3ZI?=
 =?utf-8?B?RWc9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <956E71C92EF55E4BBFE06C2A3664DEA2@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: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1eca9613-82d7-4346-e0bf-08ddb42123a4
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2025 19:47:38.1179
 (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: RUeLYlvxwGQqUkUo6eTVjMYP7+kGZj1dA+k7Uljo/+TSzERDssH7vX+s852JquxUbTLtXx5qmCUuBDfFGwqYOLNjlbU2x3OoZImYXAo7csQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR03MB10803

DQpPbiAyMy8wNi8yMDI1IDExOjAyLCBKdWxpZW4gR3JhbGwgd3JvdGU6DQo+IEhpIFN0ZWZhbm8g
YW5kIE9sZWtzaWksDQo+DQo+IExldCBtZSBzdGFydCB3aXRoIGEgYml0IG9mIHByb2Nlc3MuIFRo
aXMgaXMgZGlzY3Vzc2lvbiBpcyBnZXR0aW5nIA0KPiBmYWlybHkgZGlmZmljdWx0IHRvIGZvbGxv
dy4uLi7CoENhbiB5b3UgcGxlYXNlIHRyaW0gdW5yZWxldmFudCBiaXRzIA0KPiB3aGVuIHJlcGx5
aW5nPw0KPg0KPiBPbiAyMi8wNi8yMDI1IDIyOjU3LCBTdGVmYW5vIFN0YWJlbGxpbmkgd3JvdGU6
DQo+PiBPbiBUaHUsIDE5IEp1biAyMDI1LCBPbGVrc2lpIE1vaXNpZWlldiB3cm90ZToNCj4+PiBP
biAxOC8wNi8yMDI1IDAzOjM1LCBTdGVmYW5vIFN0YWJlbGxpbmkgd3JvdGU6DQo+Pj4+IE9uIFRo
dSwgMTIgSnVuIDIwMjUsIE9sZWtzaWkgTW9pc2llaWV2IHdyb3RlOg0KPj4+Pj4gT24gMjMvMDUv
MjAyNSAyMzoxOSwgU3RlZmFubyBTdGFiZWxsaW5pIHdyb3RlOg0KPj4+Pj4+IE9uIE1vbiwgMTkg
TWF5IDIwMjUsIE9sZWtzaWkgTW9pc2llaWV2IHdyb3RlOg0KPj4+Pj4+PiBGcm9tOiBHcnlnb3Jp
aSBTdHJhc2hrbzxncnlnb3JpaV9zdHJhc2hrb0BlcGFtLmNvbT4NCj4+PiB0aGUgc2FtZSAoc21j
LWlkIGFuZCBzaG1lbSkgZm9yIGJvdGggdGhlIEJTUCBjYXNlIChubyBYZW4pIGFuZCB0aGUgWGVu
DQo+Pj4gY2FzZSAoRG9tMCBkb21haW4pLg0KPj4+DQo+Pj4gTWVhbndoaWxlLCB0aGUgWGVuIG1h
bmFnZW1lbnQgYWdlbnQncyBTQ01JIG5vZGUgYW5kIGNvbmZpZ3VyYXRpb24gYXJlDQo+Pj4gZXhw
ZWN0ZWQgdG8gYmUgcGxhY2VkIHVuZGVyIC9jaG9zZW4uDQo+Pj4NCj4+PiBUaGlzIGFwcHJvYWNo
IGVuc3VyZXMgdGhhdCB0aGUgSG9zdCBEVCByZW1haW5zIGFzIHVuY2hhbmdlZCBhcyANCj4+PiBw
b3NzaWJsZS4NCj4+DQo+PiBZZXMsIG15IG1haW4gcG9pbnQgaXMgdGhhdCBhbGwgdGhlIGRldmlj
ZSB0cmVlIGluZm9ybWF0aW9uLCBleGNlcHQgZm9yDQo+PiB3aGF0IGlzIHVuZGVyIC9jaG9zZW4s
IHNob3VsZCBiZSBsZWZ0IHVuY2hhbmdlZCBiZXR3ZWVuIHRoZSBCU1AgY2FzZSAobm8NCj4+IFhl
bikgYW5kIHRoZSBYZW4gY2FzZS4NCj4+DQo+PiBXZSBoYXZlIGZyZWVkb20gdG8gZGVjaWRlOg0K
Pj4gLSB0aGUgaW5mb3JtYXRpb24gd2UgcHV0IHVuZGVyIC9jaG9zZW4gYW5kIGhvdyB0byBpbnRl
cnByZXQgaXQNCj4+IC0gaG93IHRvIHVzZSB0aGUgaW5mb3JtYXRpb24gdW5kZXIgL2Zpcm13YXJl
L3NjbWkgd2hlbiBYZW4gaXMgcHJlc2VudA0KPj4NCj4+DQo+Pj4gQ3VycmVudGx5Og0KPj4+DQo+
Pj4gVGhlIEhvc3QgRFQgL2Zpcm13YXJlL3NjbWkgbm9kZSByZXF1aXJlcyBtb2RpZmljYXRpb24g
dG8gcG9pbnQgdG8gdGhlDQo+Pj4gWGVuIG1hbmFnZW1lbnQgYWdlbnQgYnkgY2hhbmdpbmcNCj4+
Pg0KPj4+IHRoZSBzbWMtaWQgYW5kIHNobWVtIHZhbHVlcy4NCj4+DQo+PiBJIGRvbid0IHRoaW5r
IHdlIHNob3VsZCByZXF1aXJlIGNoYW5nZXMgdG8gL2Zpcm13YXJlL3NjbWkgaW4gdGhlIGhvc3Qg
RFQNCj4+IHdoZW4gWGVuIGlzIHByZXNlbnQuDQo+Pg0KPj4gT2Z0ZW4sIHBlb3BsZSBkb24ndCBr
bm93IHdoZW4gb3IgaWYgWGVuIGlzIHByZXNlbnQgYXQgdGhlIHRpbWUgdGhlDQo+PiBEZXZpY2Ug
VHJlZSBpcyBnZW5lcmF0ZWQuIFNvIGl0IGlzIGJlc3QgdG8gYXZvaWQgbW9kaWZpY2F0aW9uIChv
dXRzaWRlDQo+PiBvZiAvY2hvc2VuKS4NCj4NCj4gSSBhbSBwcm9iYWJseSBtaXNzaW5nIHNvbWV0
aGluZy4gQnV0IGl0IGxvb2tzIGxpa2UgVEYtQSByZXF1aXJlcyB0byANCj4gc3Vwb3J0IG11bHRp
LWFnZW50IHNvIFhlbiBjYW4gdXNlIGl0LiBBbSBJIGNvcnJlY3Q/DQo+DQo+IEZ1cnRoZXJtb3Jl
LCBJIGNhbid0IHRlbGwgd2h5IHRoZSBtdWx0aS1hZ2VudCBzdXBwb3J0IGlzIFhlbiBzcGVjaWZp
Yy4gDQo+IFN1cmVseSwgeW91IG1heSB3YW50IHNvbWV0aGluZyBzaW1pbGFyIHdpdGggb3RoZXIg
aHlwZXJ2aXNvcnM/IElmIG5vdCwgDQo+IHRoZW4gbXkgbmV4dCBxdWVzdGlvbiBpcyB3aHkgZG9l
cyBYZW4gbmVlZHMgdG8gZG8gdGhpbmdzIGRpZmZlcmVudGx5Pw0KPg0KPiBDaGVlcnMsDQo+DQoN
ClllcywgbXVsdGktYWdlbnQgc3VwcG9ydCBpcyByZXF1aXJlZCBpbiBURi1BIGZvciBYZW4sIGJ1
dCB0aGlzIGlzIG5vdCANCnNwZWNpZmljIHRvIFhlbi4NCg0KDQpUaGUgaW1wbGVtZW50YXRpb24g
aXMgYmFzZWQgb24gdGhlIHNjZW5hcmlvIGRlc2NyaWJlZCBpbiB0aGUgbGFzdCANCnBhcmFncmFw
aCBvZg0KDQpzZWN0aW9uIDQuMi4xIG9mIERFTjAwNTYgWzBdLg0KDQoNClRoZSBrZXkgcG9pbnRz
IGFyZSBhcyBmb2xsb3dzOg0KDQotIGEgVmlydHVhbCBNYWNoaW5lIChWTSkgc2VydmVzIGFzIGEg
bm9uLXRydXN0ZWQgYWdlbnQgaW4gdGhlDQoNCk5vbi1zZWN1cmUgU2VjdXJpdHkgc3RhdGUuDQoN
Ci0gYSBoeXBlcnZpc29yIGFjdHMgYXMgYSB0cnVzdGVkIGFnZW50IGluIHRoZSBOb24tc2VjdXJl
DQoNClNlY3VyaXR5IHN0YXRlLg0KDQotIHRoZSBoeXBlcnZpc29yIGNhbiBjb25maWd1cmUgZmlu
ZS1ncmFpbmVkIE5vbi1zZWN1cmUgcmVzb3VyY2UgYWNjZXNzIA0KcGVybWlzc2lvbnMgZm9yDQoN
ClZpcnR1YWwgTWFjaGluZXMuDQoNCi0gdGhlIGh5cGVydmlzb3Igc2V0cyByZXNvdXJjZSBhY2Nl
c3MgcGVybWlzc2lvbnMgZm9yIHRoZSBhZ2VudCANCmlkZW50aWZpZXIgYXNzb2NpYXRlZCB3aXRo
DQoNCnRoZSBjaGFubmVsIGFuZCBhc3NpZ25zIHRoZSBjaGFubmVsIHRvIHRoZSBWTS4NCg0KDQpU
aGVyZWZvcmUsIHdlIGNhbiBleHBlY3Qgb3RoZXIgaHlwZXJ2aXNvcnMgdG8gZm9sbG93IHRoaXMg
c3BlY2lmaWNhdGlvbi4NCg0KDQpbMF06IGh0dHBzOi8vZGV2ZWxvcGVyLmFybS5jb20vZG9jdW1l
bnRhdGlvbi9kZW4wMDU2L2xhdGVzdC8NCg0K


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 19:56:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 19:56:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1025534.1401056 (Exim 4.92)
	(envelope-from )
	id 1uUWEY-0002qc-9T; Wed, 25 Jun 2025 19:56:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1025534.1401056; Wed, 25 Jun 2025 19:56: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 1uUWEY-0002qV-6L; Wed, 25 Jun 2025 19:56:38 +0000
Received: by outflank-mailman (input) for mailman id 1025534;
 Wed, 25 Jun 2025 19:56: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 1uUWEX-0002qP-57
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 19:56:37 +0000
Received: from DB3PR0202CU003.outbound.protection.outlook.com
 (mail-northeuropeazlp170100001.outbound.protection.outlook.com
 [2a01:111:f403:c200::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7ff2f56c-51fe-11f0-a30f-13f23c93f187;
 Wed, 25 Jun 2025 21:56:36 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by AS8PR03MB9510.eurprd03.prod.outlook.com (2603:10a6:20b:5a5::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8880.17; Wed, 25 Jun
 2025 19:56:34 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%4]) with mapi id 15.20.8857.026; Wed, 25 Jun 2025
 19:56: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: 7ff2f56c-51fe-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=b99ohGESLUWaDKisqo/DEmbL6i7TNOgYkZZrikSmy7Bi3B+5xVonyO19k1p2yDdoCUlm3moVnFCdxqJeWpxeh6rgb2mlz5hozSf3J/sSbNd3IDWdZGBgn0xthWrBobBLqP+fWRRnp682k2wZm3m3KxLC/hbKS9JJsBUvXiNUbmltwBwQFGb2FFkDy0tRjgeGTX/k3AOs6+NPL7K2oZJ9C7j/n2QeJ3CItH1zYDb4ZUbAr5JyPJCED9aFJrvS/hWcMwioGPQSr0YtmOd0J6C2Ypzgjp1nU1OXgaMctOB7mi06guIO94zLm6v59kVMDn1gHPK221rUiToIQcGR1So3/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=qqS6g+CWXgeqBpi8r4n+GYpZYOddUpw/F9eMXxh0q3g=;
 b=KVDgiidMf2l95GrPhNHLNxr4IjaFXjvEuCLNXaowUAisYfgPo0+N12xgseU8s1kMabc/XcLiWHdap4b7eYJfmwc6GSPegOJDWAH7rS1q+eGyeVEYyGrqFMwRFw+sKPo5x50GtgWNX7Na1nTfPyBMuYXHP+zwKep6tPr5YrcgqThlB9r7xGxVVKQqJMgHm0noSAWXiQxKdtgZwCoemuPrbhLo9VTdmUrbE/nA33dlI6hnLUpYcf+UEl233LPZpu8xUPTXe5JUCKLCOaEe6hnh1xdgc0HH1+v781wglvn7kYpaAxDKiYczIsUm0nyE+vdV2XgWzCvaAt1/53J0argMnw==
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=qqS6g+CWXgeqBpi8r4n+GYpZYOddUpw/F9eMXxh0q3g=;
 b=RQc/6GCpLhu7NUigtrFjNZnoZdkrfD1xYuWaztQUsp5y7hXgSidY+fz9l1KrkgAKC5HQqV/uvA79CCxQQE+wy2zzvxXmncTmyHuff1tfpZ4UTLHRGzJwyEtmU9xeluP+39zj2/raT18gucojxk8Nzq/L+SqDyF+P3QZyzUBB+/tvm8BnY1Tdm+U6+FyXX8EmpypWhX2BdKdjbzQgsPkZvCkjZ8sSj5S2jE2NUaow91ukinen6CzbQwVvCt1Tu8msspF0829dLmEZZ+fmL9MW3fOrCZBbcM33vDtFpVo33CH30Ye2ieXM1uPh2HqMzLwd1v3wWY+MI4uUScOs0QuloQ==
From: Oleksii Moisieiev 
To: Jan Beulich 
CC: "xen-devel@lists.xenproject.org" , Andrew
 Cooper , Anthony PERARD
	, Bertrand Marquis ,
	Juergen Gross , Julien Grall , Michal Orzel
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Volodymyr Babchuk ,
	Grygorii Strashko , Stefano Stabellini
	
Subject: Re: [RFC PATCH v4 5/8] xen/domctl: extend XEN_DOMCTL_assign_device to
 handle not only iommu
Thread-Topic: [RFC PATCH v4 5/8] xen/domctl: extend XEN_DOMCTL_assign_device
 to handle not only iommu
Thread-Index:
 AQHbyNXPDXt2FT3RV02cltfdm/Dd7rPdzmiAgCG+LgCACKrsAIACoXoAgAWykoCAA/lGgA==
Date: Wed, 25 Jun 2025 19:56:34 +0000
Message-ID: <3e190e60-74a4-4565-acae-3b8602a4c46e@epam.com>
References: 
 <4f58bf9c47c40413ee9250c4cd21458382aac857.1747669845.git.oleksii_moisieiev@epam.com>
 
 
 
 <1780646c-cb6f-4508-86c8-a573fbc09f6a@epam.com>
 <1e116116-ddf7-4640-9809-2502203abe46@suse.com>
In-Reply-To: <1e116116-ddf7-4640-9809-2502203abe46@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB8946:EE_|AS8PR03MB9510:EE_
x-ms-office365-filtering-correlation-id: f44ec939-a175-4364-d186-08ddb4226320
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|7416014|376014|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?RnAxYjlzeGJpd1NpZDRvU1UrVlZaemJva3RLRUF0WE0vUVlOOWtUNzM0dmhv?=
 =?utf-8?B?d1JnUkVNd0w4OVYwSzFpUXE3TjRTcE9QTmtlb25RRXpNTlZRMWJBSW1aL1JL?=
 =?utf-8?B?akJqZXpQWG1mODJDK1FhNlpRR2ZQNHhTakM1TzBXNHdtVkNSeWlGQUZKL0Jy?=
 =?utf-8?B?bEtMK2FkL0FBV01WWjdoejJmRFVRZithQTFtQ2dNVXUxc2dhMEVLVzlJa2Jl?=
 =?utf-8?B?eXI2MGxwbnAxdTNRVWxEcHpTQ1l1VXRRQ25tSUhBSFFhYXNjc1ZkYnF5Q0J1?=
 =?utf-8?B?aW1UZTZ5SEtkeW9ydjR4YnRoOE5DSkZYOEJiUEV6ZmUrYVVaWFFhQkRGeEtM?=
 =?utf-8?B?N2xNbUV5TGNGMFp1RExiUDIvVXJYNU1QdXJuRFBXNjRhWHRIeFVRSEFyMkxt?=
 =?utf-8?B?VjFKRjRUUnFwRFN4bkVnYmJqMnZoMzR4SmVIMCtRekZSR0xzMXltd2dudGwv?=
 =?utf-8?B?V0tkcDh6bzhpN21XVFFzRTBsclNwTms2WDhJOHhoNm9za1gvUjZhM3BabU4r?=
 =?utf-8?B?b2hUUTR1amFWVFNFVE92QjQycnp2UEVDUkkvb3paYWpUeVduSENtbjFJc3h4?=
 =?utf-8?B?OE4yWFcvbTVxNnhNMDB2OW1SbWZ5M0lzcTN3bm1pRGhmVVp6NC82ajVXS2M3?=
 =?utf-8?B?Y3pVQTI0cGpWd3hDRXR5VUFidjV1VlMzK0N4RFYxNkpDQzk4Wkw4K0ZYR1FF?=
 =?utf-8?B?WVVyQnRhYW4rUnBTcVpxQnNnZnJVWGdXc2k0K1RGb2Nxb2Y4U2FYMVpiNms0?=
 =?utf-8?B?VE1OM25EQ0ZQUk81b3RyTkFYdjNoVHFSNE9oR2hjNFIyeVJGSlZtQlRxdXd1?=
 =?utf-8?B?QlJTazFDZkJTNlNjTkpzTnZBUkpmS3BnY2V1Snk5V3k0cmZOWlpUUytlblkw?=
 =?utf-8?B?ZTB2Skd3alRZTExUbm12cmZOVXppa1NtSWNLN1hlQUhKekFYTkFEalBaN0d1?=
 =?utf-8?B?dnpsaGducDNSaEFuRVpNcFhNZXhWQVBmSkF0bGpSZkppeFlIeVl4eUJWTitz?=
 =?utf-8?B?OWZCcXFIL0hiZEhCYTRsSTFQbm9JZmtteTl1ajBSbHFkTmVnY3U5Ym9TK2Ru?=
 =?utf-8?B?U2hzLzJScGl5SENKS01UYm9KUzV5RFZBWVVZNmJ1OC9LTkNDei9MV1Rpc2Mx?=
 =?utf-8?B?THZXbUVKd0dRR0RNMk85cUtzRnV2ZmFodEtYTnZIWGdwcVpJQWJIdU5mRjNE?=
 =?utf-8?B?V2cwSGlQckNqckxISmpFT0VnMEVzUnBkZlEwaUh2SmRCRXd1NU5ydVVqWDUz?=
 =?utf-8?B?MHlzcnF5R2JCZmFnTy8zeDFrSGZvQnJtdmJyN0V6alhxMFY4QWgrYkN6VCtH?=
 =?utf-8?B?dWduV0VEWXNUNk5YbC8zdEhLOEd1bVdpcVlLbzQwcjdzaC9ObUo4NEtVazNa?=
 =?utf-8?B?U01yMFB2SGRTdWJsWjVFY1ozRGFMaEgzMnBHNzFvZXNVcmUwdFlnRFdzUFJW?=
 =?utf-8?B?c2NJUDNMeHFkRFEydGwrbnd5N1lVOWZCK1c3WUtXbmk2YnQ0dStoREZuS1lw?=
 =?utf-8?B?NVJyQU8zSWR2ZkRmYjBKZWtreVJJcFNMeENIYTFGWk51aUhtR0FZclhBaVUw?=
 =?utf-8?B?bm0xNTVURGk3RWlsVHlOWnkyYk8zbk5ibzdOeVh3aUhod3lEUXdjWUw2cVJE?=
 =?utf-8?B?SjR6aW1SUFBGZm9yRnZCRkJqM0Y5b1JuTjZCd1ZsajI2V0ZvOFcyZFQrV0hD?=
 =?utf-8?B?cHZHMkVxaXRuckwwMnZQUkV2UUlnN0duTktZdjBLRGh4bDBGTm9QcjRQQjJS?=
 =?utf-8?B?ZW1aL1FUQkpSTE1MOG50YmdycXFiV0ljTnRKUkV6dFMwWG4wL0FlZ2ZsV3FW?=
 =?utf-8?B?SGs3aGpMalNPemt0RmtaeFd1dm5FeXgxUHJyZE1oNDA2N2xpN3Z4SXJYTWUy?=
 =?utf-8?B?NkdxR0NqcjJCSmloV2NoVjcydmJob2FtYjF2MUpaaG5iTXhJMURzRUhhMWE0?=
 =?utf-8?Q?Z2d/qi/h7I0=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?YjVNNVE4QlZuc3llSDFQTDY4aTZjMzRTR1pudGtmZHE5MUVCQ20wdUJYMmZq?=
 =?utf-8?B?SVBXcUZ2bk4rbWdtRGVYUldCWGFFUTJ2WnVJcXRNbjh5NGh0QXY5N2ZFSHNS?=
 =?utf-8?B?bTZGMVUzU0Z5cGt5ZnhxVzRTN3hscU5yRUt3YzlablNlb3lWOVpURmdWbGZj?=
 =?utf-8?B?K3JrU0RwcXBjVGNra1RYNFBIQUZlVjZqaDhTaXhweHRtTTFITWpVTitHTTBo?=
 =?utf-8?B?alpPNXFkUGY4eE9TeGN0dHpqRHh1QkxMcGtUNm5Ec0V5REwzUXJqUjFJdGht?=
 =?utf-8?B?Nk13TWtSQ2NQbGNnc3p1aVNleElwQUxpYnRMSWt2SmcvYk5nM1hvVE14c29k?=
 =?utf-8?B?eXhnUE5xYjI2Rk1iVWpjTitCMEpwVjhGeWlnSFU3dHM2MHJlM0V1WU5wSTlJ?=
 =?utf-8?B?NVY0eUt3WGJCUkx4TUpiZUE4R1VxTWNTOHNoa0UyWlRrd0kyRHEvbERQVVF4?=
 =?utf-8?B?WjhqQWh0cDJNM3owOHQ5ZkZ4eGRFaDUyN08xNDZqT2x1TUJmODZPUEE3OThT?=
 =?utf-8?B?UlZndlhyajcxd0c5cklsdGt2Q2NEcmhpbFRVb1VOeW5LL2VEei82azRVblNV?=
 =?utf-8?B?cTNaK1o2NzdDZndoNkd5ZGRxbUJBZTdKaHRxdmVVbFM4c2tIVENSSjdkSmF1?=
 =?utf-8?B?Zlc5SnZ3cEQ4ZnRPRHdKSkZDOExxbDdkRlZTU1pkUW9EbmQxTU5kbmMxbXBG?=
 =?utf-8?B?L2YzOUJlUmx1WnU1NHQ4a09oYytvSUdOWXkzdUNlMHliSUJPcVRkOGk5UjQr?=
 =?utf-8?B?UlZ0QXlPRTZKZ1diT3gzMkcyakRSRWU5NGNtWm0zZFlwaXlMeEpEbU83akNl?=
 =?utf-8?B?V0MvNnBWb3pabUFwRG5QSUtweU1MSStjL2RHQ2ZqeXpaSDZWNjQxbXY0YUlo?=
 =?utf-8?B?YjhGS2Y0bGYzcVNwaDB6WTJ1UVVlaHBhcFJWWVpDajN3SHRLeVdpVGNhY3dq?=
 =?utf-8?B?MFFRdlVDbDZqdzNTeXdHcjB1cVFzUTh4aFl1RGtQV2Z3b3V2RWIrajVkTGd6?=
 =?utf-8?B?T1JpQUVGUHZaUWVkcmxDNEdNSUdYZ0N2L3F6V0t3Rkc3SXlNbytJN1lHRGpC?=
 =?utf-8?B?Mk9YU3lwL2dQMzloRGVkVHpDRHNXVWpNRjNnOHFvajNkRFhQTy9sV2M2QmJ5?=
 =?utf-8?B?dVV0V0QzRHpibThuWFRBVVdPanVxblFTdjlxdDVVS3FBVFU1VUxwQzZ0c3dh?=
 =?utf-8?B?QWNWMi9nS25nVExxbE4wcktUMUhLaldmVDhxS2JPK3NuUmwzakRXdlR0a1Vj?=
 =?utf-8?B?VmgzK2F5RU00bVZTN2tTQ3RLSmZETzJQTEtYd3I2bVVyK1BDN3BNa1dMcmN4?=
 =?utf-8?B?SkIwejZJalUrK0E1VUgrZGhtMkNEMldLb0VwRFl4Rm5qb2xVSDAyb2pzaTJB?=
 =?utf-8?B?aWpxZDdaWi93UlFRS3R6Y3RBRlFHd3pDQjJ2dW9MeXM2a2JObXo2U3JOSWNZ?=
 =?utf-8?B?REQydCtoSkhEaFBuMVhBdnV2ZHhndFZTNmwyMGQ0K1JMLzN3QXd4OVV4V3Ny?=
 =?utf-8?B?NXZUcGpRakpaR3ZPa1hMcEZEYXBZQUR5WmlQc2lUd00vaHllZWwwSDRUTG5w?=
 =?utf-8?B?VWhCRDJhTmU3NjJPZ1VPUXNOWVpVVTl4UjRoVUp5Q2wyYjMvZmxCb3RLYlVK?=
 =?utf-8?B?NFNyZ1dETkNCd0NrcXJBWXVrajVHRTRPVjBZZUtESE1ta3JuQzI0WGhjL0sw?=
 =?utf-8?B?bGp4UVFmU1E1Tlp5ODJoaTZRYmo1OFNOTFQzbGp5VktTdUdEbTlycXdHQXhN?=
 =?utf-8?B?eVpqNVBsZEJkcDZzMnlSVkRwY2V2MitGdDNSNXNCMlZaVWlXbjdla1VTVHdD?=
 =?utf-8?B?b0p1RExFWGlXcW80U2d3UnZiNTNPZktFMEoyOW5SaGNnbWlRSEFlWk04K2Zt?=
 =?utf-8?B?YnB6YjBXam1oSE9BcnRldnJJZ1JLN3hHMWRRaHp2R29MUVdFWFRzcVFEK0VW?=
 =?utf-8?B?SkFWaWN0WWFsSys3VkdSN1BNSGcxbHNwS1JlTWl3OW5QaWd3MXJoZTZHMHZP?=
 =?utf-8?B?MEpTdVgzdTFYY1g1WXM0QkhEMXY5TUdKV2xxbXpxSWlsOWw4S0hJeXE1NnBO?=
 =?utf-8?B?aEdvLzdmTUFWZmhsY01PZFlEai8vREZLaFByU2hjekJUT3NBRGtXcGl0Uzdq?=
 =?utf-8?B?NUJJbXVOSGlHc1FHcGVWY3lnS0NlajhNZ0hRcDdJMVFtTUNBMFRLSjhpMmEr?=
 =?utf-8?B?YXc9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <037DB2CE029CC140817AD88D83A656EF@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: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f44ec939-a175-4364-d186-08ddb4226320
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2025 19:56:34.1113
 (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: 9VwstMyFnglf67C2RmVl05gSuNnt/YgAweYP65sKn/U3m00rICh+SYH1cgPxDAkDczVTRqsYo3oxleLDYSNrlRXgcy46XwGXMB3aZ7B1nn4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB9510

DQpPbiAyMy8wNi8yMDI1IDEwOjE1LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMTkuMDYuMjAy
NSAxODoxNSwgT2xla3NpaSBNb2lzaWVpZXYgd3JvdGU6DQo+PiBPbiAxOC8wNi8yMDI1IDAzOjA0
LCBTdGVmYW5vIFN0YWJlbGxpbmkgd3JvdGU6DQo+Pj4gT24gVGh1LCAxMiBKdW4gMjAyNSwgT2xl
a3NpaSBNb2lzaWVpZXYgd3JvdGU6DQo+Pj4+Pj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9m
aXJtd2FyZS9zY2kuYyBiL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY2kuYw0KPj4+Pj4+IGluZGV4
IGUxNTIyZTEwZTIuLjhlZmQ1NDFjNGYgMTAwNjQ0DQo+Pj4+Pj4gLS0tIGEveGVuL2FyY2gvYXJt
L2Zpcm13YXJlL3NjaS5jDQo+Pj4+Pj4gKysrIGIveGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjaS5j
DQo+Pj4+Pj4gQEAgLTEyNiw2ICsxMjYsNDMgQEAgaW50IHNjaV9hc3NpZ25fZHRfZGV2aWNlKHN0
cnVjdCBkb21haW4gKmQsIHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqZGV2KQ0KPj4+Pj4+ICAgICAg
ICAgcmV0dXJuIDA7DQo+Pj4+Pj4gICAgIH0NCj4+Pj4+PiAgICAgDQo+Pj4+Pj4gK2ludCBzY2lf
ZG9fZG9tY3RsKHN0cnVjdCB4ZW5fZG9tY3RsICpkb21jdGwsIHN0cnVjdCBkb21haW4gKmQsDQo+
Pj4+Pj4gKyAgICAgICAgICAgICAgICAgIFhFTl9HVUVTVF9IQU5ETEVfUEFSQU0oeGVuX2RvbWN0
bF90KSB1X2RvbWN0bCkNCj4+Pj4+PiArew0KPj4+Pj4+ICsgICAgc3RydWN0IGR0X2RldmljZV9u
b2RlICpkZXY7DQo+Pj4+Pj4gKyAgICBpbnQgcmV0ID0gMDsNCj4+Pj4+PiArDQo+Pj4+Pj4gKyAg
ICBzd2l0Y2ggKCBkb21jdGwtPmNtZCApDQo+Pj4+Pj4gKyAgICB7DQo+Pj4+Pj4gKyAgICBjYXNl
IFhFTl9ET01DVExfYXNzaWduX2RldmljZToNCj4+Pj4+PiArICAgICAgICByZXQgPSAtRU9QTk9U
U1VQUDsNCj4+Pj4+IEFyZSB5b3Ugc3VyZSAtRU9QTk9UU1VQUCBpcyB0aGUgcmlnaHQgZXJyb3Ig
Y29kZSBmb3IgdGhlIDMgY2hlY2tzIGJlbG93Pw0KPj4+PiBUaGUgLUVPUE5PVFNVUFAgY29kZSBp
cyB1c2VkIGJlY2F1c2UgdGhpcyBpcyBwYXJ0IG9mIGEgY2hhaW5lZCBjYWxsIGFmdGVyDQo+Pj4+
IGlvbW11X2RvX2RvbWN0bCwgYXMgc3RhdGVkIGluIHhlbi9jb21tb24vZG9tY3RsLmM6ODU5LiBU
aGUNCj4+Pj4gWEVOX0RPTUNUTF9hc3NpZ25fZGV2aWNlDQo+Pj4+IGNhbGwgaXMgZXhwZWN0ZWQg
dG8gaGFuZGxlIGFueSBEVCBkZXZpY2UsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciB0aGUgRFQNCj4+
Pj4gZGV2aWNlIGlzDQo+Pj4+IHByb3RlY3RlZCBieSBhbiBJT01NVSBvciBpZiB0aGUgSU9NTVUg
aXMgZGlzYWJsZWQuDQo+Pj4+IFRoZSBmb2xsb3dpbmcgY2FzZXMgYXJlIGNvbnNpZGVyZWQ6DQo+
Pj4+DQo+Pj4+IDEuIElPTU1VIFByb3RlY3RlZCBEZXZpY2UgKFN1Y2Nlc3MpDQo+Pj4+DQo+Pj4+
IElmIHRoZSBkZXZpY2UgaXMgcHJvdGVjdGVkIGJ5IHRoZSBJT01NVSBhbmQgaW9tbXVfZG9fZG9t
Y3RsIHJldHVybnMgMCwNCj4+Pj4gd2UgY29udGludWUNCj4+Pj4gcHJvY2Vzc2luZyB0aGUgRFQg
ZGV2aWNlIGJ5IGNhbGxpbmcgc2NpX2RvX2RvbWN0bC4NCj4+Pj4NCj4+Pj4gMi4gSU9NTVUgRGlz
YWJsZWQgKC1FT1BOT1RTVVBQIGZyb20gaW9tbXVfZG9fZG9tY3RsKQ0KPj4+Pg0KPj4+PiBJZiBp
b21tdV9kb19kb21jdGwgcmV0dXJucyAtRU9QTk9UU1VQUCwgaW5kaWNhdGluZyB0aGF0IHRoZSBJ
T01NVSBpcw0KPj4+PiBkaXNhYmxlZCwNCj4+Pj4gd2Ugc3RpbGwgcHJvY2VlZCB0byBjYWxsIHNj
aV9kb19kb21jdGwuDQo+Pj4gT0sgdGhpcyBtYWtlcyBzZW5zZS4gIEkgdGhpbmsgaXQgaXMgT0sg
dG8gaGF2ZSBhIHNwZWNpYWwgZXJyb3IgY29kZSB0bw0KPj4+IHNheSAidGhlIElPTU1VIGlzIGRp
c2FibGVkIiBidXQgSSBkb24ndCBrbm93IGlmIGl0IGlzIGEgZ29vZCBpZGVhIHRvIHRyeQ0KPj4+
IHRvIHVzZSAtRU9QTk9UU1VQUCBmb3IgdGhhdC4gLUVPUE5PVFNVUFAgY291bGQgbWVhbiBhIGh5
cGVydmlzb3INCj4+PiBjb25maWd1cmF0aW9uIHdpdGggZG9tY3RsIGRpc2FibGVkLCBmb3IgaW5z
dGFuY2UuDQo+Pj4NCj4+PiBJdCBtaWdodCBiZSB3aXNlciB0byB1c2UgYSBkaWZmZXJlbnQgZXJy
b3IgY29kZS4gTWF5YmUgRU5PRU5UPw0KPj4+DQo+PiBJIHNlZSB0aGF0IGluIHRoZSBmb2xsb3dp
bmcgY29tbWl0Og0KPj4NCj4+IDcxZTYxN2E2YjggKHVzZSBpc19pb21tdV9lbmFibGVkKCkgd2hl
cmUgYXBwcm9wcmlhdGUuLi4sIDIwMTktMDktMTcpDQo+Pg0KPj4gLUVOT1NZUyByZXR1cm4gY29k
ZSB3YXMgY2hhbmdlZCB0byAtRU9QTk9UU1VQUCBpbiBpb21tdV9kb19kb21jdGwuDQo+Pg0KPj4g
SXQncyBub3QgY2xlYXIgdG8gbWUgd2h5IHRoaXMgd2FzIGRvbmUgZnJvbSB0aGUgY29tbWl0IGRl
c2NyaXB0aW9uLg0KPiBUaGlzIGhhcyBiZWVuIGRpc2N1c3NlZCBtYW55IHRpbWVzIGVsc2V3aGVy
ZS4gTWFueSBvZiBvdXIgRU5PU1lTIHVzZXMgYXJlDQo+IHNpbXBseSB3cm9uZy4gRU5PU1lTIGhh
cyB2ZXJ5IGxpbWl0ZWQgYXBwbGljYWJpbGl0eTogVW5hdmFpbGFiaWxpdHkgb2YgYQ0KPiB0b3At
bGV2ZWwgaHlwZXJjYWxsIChvcmlnaW5hbGx5OiBzeXNjYWxsKS4NCj4NCldoYXQgaXMgeW91ciBv
cGluaW9uIGFib3V0IGNoYW5naW5nIGl0IHRvIC1FTk9FTlQgdG8gc2F5ICJ0aGUgSU9NTVUgaXMg
DQpkaXNhYmxlZCIgYXMgU3RlZmFubyBzdWdnZXN0ZWQgaW4gWzBdPw0KDQpbMF06IGh0dHBzOi8v
bGlzdHMueGVuLm9yZy9hcmNoaXZlcy9odG1sL3hlbi1kZXZlbC8yMDI1LTA2L21zZzAxMjMzLmh0
bWwNCg==


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 20:27:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 20:27:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1025551.1401066 (Exim 4.92)
	(envelope-from )
	id 1uUWhz-00072W-Gb; Wed, 25 Jun 2025 20:27:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1025551.1401066; Wed, 25 Jun 2025 20:27: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 1uUWhz-00072P-Dn; Wed, 25 Jun 2025 20:27:03 +0000
Received: by outflank-mailman (input) for mailman id 1025551;
 Wed, 25 Jun 2025 20:27: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 1uUWhy-00072J-Cn
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 20:27:02 +0000
Received: from fout-b3-smtp.messagingengine.com
 (fout-b3-smtp.messagingengine.com [202.12.124.146])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bc5580da-5202-11f0-b894-0df219b8e170;
 Wed, 25 Jun 2025 22:26:56 +0200 (CEST)
Received: from phl-compute-06.internal (phl-compute-06.phl.internal
 [10.202.2.46])
 by mailfout.stl.internal (Postfix) with ESMTP id 7292D1D00171;
 Wed, 25 Jun 2025 16:26:54 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-06.internal (MEProxy); Wed, 25 Jun 2025 16:26:54 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 25 Jun 2025 16:26:52 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bc5580da-5202-11f0-b894-0df219b8e170
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=1750883214;
	 x=1750969614; bh=iTuvUqK6UxntR0DvtXRfTwo23JZ9mVGUGcVstB8NmzM=; b=
	bfYXhIyxt+0O7/5so+589CTD1cbcpIb9tQni8K2DFyGcY45OwIGIlSAR9yca0Iie
	k3/8fDmEPmwRLEnqSb/BDxtSCM8Jv9lvMY1IvTsjyvJ17AZ8V1/Xusi9aPvSM7JB
	vD0u+i8aLUAV2rD5pW/yI1rkQNxHsa04zGtCUQPcHuUIciy2tpHKYYC3HjrFgft9
	HGqz0d8vEseI46ktfw88RrfZHG1KMmNwKg2qfmRKgGX/jiidKa/GN0bmh/JY9yoy
	SZEDbpGnKePYA6UjZsT7rY9sDtdmj2oaYssLzxMMrnircX5PU8/G8UxIsaZ/kzP+
	0s7BEolg2O5p6P0GpCC/MQ==
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=
	1750883214; x=1750969614; bh=iTuvUqK6UxntR0DvtXRfTwo23JZ9mVGUGcV
	stB8NmzM=; b=DJzkfrHzZKWIRWOTmLR7b+ii8dQb9x2sMqOTwzpnDUHR5D4oo4e
	db0SrKp8Gq71Mu3SQWprBnRO/twS2tqthOw1fyh4gipxyTdlXJCd6lp7QnlshAch
	o0fRnJsMSTwU+Hnk5yJJI2sO2O8vOJIcUDcN0NEOZLLk/cGL+kK0cPBgS1auC3Fn
	cWgzQEgHdc9mwPT/MMpzzT2sGTA4woukFgjgUztUAOoOiZoOswqUJ2FvdLK5QPEI
	0Wh/j/KVqsh/dP91ieyJMyLGEBb+HJFlm1XmcDyu0GVWdsYfNoXSWKRczsLaeeEl
	dD9+2aWHNQbBPH3MwKbeu8/1CInh82BuKRA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgddvfeejfecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghkucfo
    rghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhish
    hisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpeeigeeukeev
    tedugfehgfeiveffleeiieeukefftdegjeekleegffduhfffhfejfeenucffohhmrghinh
    epghhnuhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl
    fhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtoh
    hmpdhnsggprhgtphhtthhopeegpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehf
    rhgvughirghnohdriihighhlihhosegtlhhouhgurdgtohhmpdhrtghpthhtohepgigvnh
    dquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtohep
    ughpshhmihhthhesrghpvghrthhushhsohhluhhtihhonhhsrdgtohhmpdhrtghpthhtoh
    epjhgsvghulhhitghhsehsuhhsvgdrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Wed, 25 Jun 2025 22:26:50 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Frediano Ziglio 
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" ,
	Jan Beulich 
Subject: Re: [PATCH 0/2] xen/efi: Make boot more flexible, especially with
 GRUB2
Message-ID: 
References: <20250624083157.9334-1-frediano.ziglio@cloud.com>
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="yTvFbj8bQLmgNqm8"
Content-Disposition: inline
In-Reply-To: 


--yTvFbj8bQLmgNqm8
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Wed, 25 Jun 2025 22:26:50 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Frediano Ziglio 
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" ,
	Jan Beulich 
Subject: Re: [PATCH 0/2] xen/efi: Make boot more flexible, especially with
 GRUB2

On Tue, Jun 24, 2025 at 09:38:42AM +0100, Frediano Ziglio wrote:
> On Tue, Jun 24, 2025 at 9:32=E2=80=AFAM Frediano Ziglio
>  wrote:
> >
> > The combination of GRUB2, EFI and UKI allows potentially more flexibili=
ty.
> > For instance is possible to load xen.efi from a no ESP partition leaving
> > a boot loader like GRUB2 taking care of the file loading.
> > This however requires some changes in Xen to be less restrictive.
> > Specifically for GRUB2 these changes allows the usage of "chainloader"
> > command with UKI and reading xen.efi from no ESP (so no DeviceHandle
> > set) and usage of "linux" and "initrd" commands to load separately
> > the kernel (embedding using UKI) and initrd (using LoadFile2 protocol).
>=20
> I was forgetting. If somebody wants to test "linux" and "initrd"
> command with these changes be aware that GRUB currently has a problem
> passing arguments, I posted a patch, see
> https://lists.gnu.org/archive/html/grub-devel/2025-06/msg00156.html.
> I also have a workaround for this issue in xen but it would be better
> to have a fix in GRUB.

Can you tell more how to test this, especially the second variant? When
trying to use GRUB linux or linuxefi commands on xen.efi, I get "invalid
magic number" error.

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

--yTvFbj8bQLmgNqm8
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmhcW4sACgkQ24/THMrX
1yx/qgf+NrB03zsRbIO28kwVEC9k2EYtzWY/GAFQFdx9oJg+ET/0ixGkdXhjAAHv
dltGNjslGRVtJoRV3HG0kUSNZcVzO9GhOkFc1K8eqhxQR+Qqg6jYQsWTrhdMa7x2
weBb46ezacUJ1xa/kwJU65Ccc9mqCdZ82wyKe9vrxp7R2tgVKT1CtRbkctYb6XNS
8zkysCxcnSGOsfoQFYY7NZf9QndKx91u2xvPRuT2Ckbf6uySyPt5Doptsrv8P9Sv
rG87QmSA+2Y/NVpRQxnmSmsPuUa4F7EkTGF495ZlJEmVvjwrh6G99BsBqUYdTSni
0gl1/2Oyi6opsJ0mgV2USMzp8HAPfw==
=lqBA
-----END PGP SIGNATURE-----

--yTvFbj8bQLmgNqm8--


From xen-devel-bounces@lists.xenproject.org Wed Jun 25 20:32:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jun 2025 20:32:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1025574.1401075 (Exim 4.92)
	(envelope-from )
	id 1uUWnc-0000Ie-4C; Wed, 25 Jun 2025 20:32:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1025574.1401075; Wed, 25 Jun 2025 20:32: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 1uUWnc-0000IX-16; Wed, 25 Jun 2025 20:32:52 +0000
Received: by outflank-mailman (input) for mailman id 1025574;
 Wed, 25 Jun 2025 20:32:50 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uUWna-0000IR-R4
 for xen-devel@lists.xenproject.org; Wed, 25 Jun 2025 20:32:50 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uUWnZ-00288T-2x;
 Wed, 25 Jun 2025 20:32:49 +0000
Received: from [2a02:8012:3a1:0:fd5d:2703:c772:3074]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uUWnZ-0031nR-1v;
 Wed, 25 Jun 2025 20:32: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=7s51iM3PPGZDgvFJxYNybSrDZN/qPGnVkWEbJshEWfA=; b=jdAAT/zNcvcTe+J9plHh/CmlV1
	PevhtEwbybrUGxB68QRHZPnbIewCKaARpcOAsZRtc0xuMRfxwNnrYbXGS+9OwYJwe/lOJNgsI+Q5/
	wdu1jbmULcN1HKJxwzYfE6qKODZQbZ3GwdyYLx8cb3l6ObjdXCgFhFf5mB0g9c6qb5pU=;
Message-ID: 
Date: Wed, 25 Jun 2025 21:32:47 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v4 8/8] docs: armproposa: l to add separate SCMI node
 for Xen agent
Content-Language: en-GB
To: Oleksii Moisieiev ,
 Stefano Stabellini 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper ,
 Anthony PERARD ,
 Bertrand Marquis , Jan Beulich
 , Juergen Gross ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Volodymyr Babchuk ,
 Grygorii Strashko 
References: 
 <3f7e1e99f5d1018064f3c4825aff16bd487cf558.1747669845.git.oleksii_moisieiev@epam.com>
 
 
 
 
 
 <3468bb57-3178-460b-8fb2-3ce106475319@xen.org>
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Oleksii,

On 25/06/2025 20:47, Oleksii Moisieiev wrote:
> 
> On 23/06/2025 11:02, Julien Grall wrote:
>> I am probably missing something. But it looks like TF-A requires to
>> suport multi-agent so Xen can use it. Am I correct?
>>
>> Furthermore, I can't tell why the multi-agent support is Xen specific.
>> Surely, you may want something similar with other hypervisors? If not,
>> then my next question is why does Xen needs to do things differently?
>>
>> Cheers,
>>
> 
> Yes, multi-agent support is required in TF-A for Xen, but this is not
> specific to Xen.

I am really confused. If the support is not Xen specific then why do we 
end up to have xen specific node/properties in your proposal (see [1]) 
such as xen,scmi-secondary-agents.

I also question the placement of the SMCI multi-agent in /chosen. For me 
/chosen is for configuration related to the hypervisor/OS. But here, it 
seems the multi-agent SMCI is related to the platform.

So wouldn't it be better to create a new compatible arm,smci-multi that 
will include the information for multi? An alternative would be to 
extend the existing SCMI node in a backward compatible way.

Lastly, I see if you put a node under "/chosen" with "arm,scmi-smc". 
Have you checked this will not confused Linux? I was under the 
impression Linux would look for any node with the compatible when 
initializing a driver.

Cheers,

[1] 
https://lists.xenproject.org/archives/html/xen-devel/2025-06/msg01421.html


-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Thu Jun 26 03:51:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 03:51:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1025808.1401110 (Exim 4.92)
	(envelope-from )
	id 1uUddX-0007bC-7w; Thu, 26 Jun 2025 03:50:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1025808.1401110; Thu, 26 Jun 2025 03:50: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 1uUddX-0007b4-3C; Thu, 26 Jun 2025 03:50:55 +0000
Received: by outflank-mailman (input) for mailman id 1025808;
 Thu, 26 Jun 2025 03: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 1uUddU-0007ay-SR
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 03:50:53 +0000
Received: from ewa-mbsout-02.mbs.boeing.net (ewa-mbsout-02.mbs.boeing.net
 [130.76.20.195]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bc4e9f7a-5240-11f0-b894-0df219b8e170;
 Thu, 26 Jun 2025 05:50:46 +0200 (CEST)
Received: from localhostlocalhost (localhost [127.0.0.1])
 by ewa-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id
 55Q3og51030390; Wed, 25 Jun 2025 20:50:42 -0700
Received: from XCH16-02-01.nos.boeing.com (xch16-02-01.nos.boeing.com
 [137.137.110.53])
 by ewa-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with
 ESMTPS id 55Q3oWIS030339
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
 Wed, 25 Jun 2025 20:50:32 -0700
Received: from XCH16-09-06.nos.boeing.com (137.137.111.51) by
 XCH16-02-01.nos.boeing.com (137.137.110.53) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.1.2507.44; Wed, 25 Jun 2025 20:50:32 -0700
Received: from XCH19-EDGE-Q02.nos.boeing.com (130.76.23.14) by
 XCH16-09-06.nos.boeing.com (137.137.111.51) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.1.2507.44 via Frontend Transport; Wed, 25 Jun 2025 20:50:32 -0700
Received: from USG02-CY1-obe.outbound.protection.office365.us (23.103.199.175)
 by boeing.com (130.76.23.14) with Microsoft SMTP Server
 (version=TLS1_2, 
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1748.10; Wed, 25 Jun
 2025 20:50:30 -0700
Received: from BN0P110MB2148.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:19b::17)
 by SA1P110MB1359.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:197::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8813.21; Thu, 26 Jun
 2025 03:50:30 +0000
Received: from BN0P110MB2148.NAMP110.PROD.OUTLOOK.COM
 ([fe80::394b:7a34:da07:485d]) by BN0P110MB2148.NAMP110.PROD.OUTLOOK.COM
 ([fe80::394b:7a34:da07:485d%5]) with mapi id 15.20.8857.026; Thu, 26 Jun 2025
 03:50: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: bc4e9f7a-5240-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com;
	s=boeing-s1912; t=1750909842;
	bh=p69J/5sr60GizvBupwyAViTfwTc/Zat/sv06XApCAks=;
	h=From:To:CC:Subject:Date:From;
	b=AH45lr58MTmWQ3TA6n1lcEp7apCShnFnpwRGTlRXK6ZUZ/oT0mqd+huxuUw6vVTH+
	 74/V6TO6HOSeUr9osZCJppQo2myo3YklpbOWJSjE6YWxIri/4hC1tMXNi1CtEBzQPh
	 nCcb9F42pmP0JOAFSDYn7yOzJ1MHti4wTTCdpDtlVw3vuhjGQEJyzcfj5evsQGI6Zm
	 dcZeZ1HB59cnfB2GjKMcd2FCwht3hWilXEtQ36hDiI7fWsQFE7Z0oYCS5fEo9aZORN
	 YZG2lEon+OPO6wZtpnsa2uOG6sJ4jseZCDMzEcg9wKKaBCuQSSDK9YM+sBYIPOBD3j
	 dLPPl9qFWFcZw==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none;
 b=Wc8AFOKaggjMsvGO1295jP/L9tq87FzfYeb1Uw10Ex06lnU/5PpYH/K65xvXD+b4xQJUT4dJwmsQIqH59whvhWv8ZulYOWeDk5tcWjP4DU6YSSsyJCNt0gfKwaShADngqwKdQp9EiQ/MXD+6qGKIAmAVOWnE7e6ql/QvSZWfD+oWx+9JOwuFi1SRJXBijpVclApJzHff5Kt9E4JGA1je/ssU/lVQTPbZm2UmnhevCk7g+G0hI7th2k2w2iXlR7bL541CtPpRc2eUbBDGFMQFSCs3JtwxlLxkFon5Jh3AboxGL7qNoFdal16xUQyHIEBaN4PYHjf7Ngl9Nzrd6C7wcw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector5401;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=p69J/5sr60GizvBupwyAViTfwTc/Zat/sv06XApCAks=;
 b=L7P3tR9dUWcrHaSCWOGevW9EvRmDhncRatp6Vycmod4nwjDGOm9sdtasZQvXFMSNEtB0lUAd/eOTwvshz08bm6199/woC81Rh3WuBVeBVWQGKiBMiX3MWPk98ozx9HPpgvL3Jw6x9WbrGzFqY30uTUE9NFTVrke4mzMJf5/cVYOm4wThfxDYVwBWO5wz5aCCqWv36NtWdAdirnr+0OIBTnkOv2RKNPYFDZSRRLSO8oJe4CnvFloV4jxemZkehnSJQfiUV5XTOtmZdX9AYBBjKkhKVTEBjJZ4AeXMhxqGe2bprwalm6nx8tpyA87u5aLK3w1ZpP3w4s8+Fd/bNehYvg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=boeing.com; dmarc=pass action=none header.from=boeing.com;
 dkim=pass header.d=boeing.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=boeing.onmicrosoft.com; s=selector1-boeing-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=p69J/5sr60GizvBupwyAViTfwTc/Zat/sv06XApCAks=;
 b=EHIQuRKs1NlckrXy+KM6HaMDsdG4+3CYFxXZQdxaK2dW0YDDQkgh3if1LWVkI0prPjmkDwMXtgFS8IcQHfmruiM/S5QmQp60QkbrcYYiImjmQOzirGi4cOrsj+Y9d7+cN27jgPMxXYzlO8cBF1c/W/tqNon5y+Rh421yqHGEpxo=
From: "Choi, Anderson" 
To: "xen-devel@lists.xenproject.org" 
CC: "nathan.studer@dornerworks.com" ,
        "stewart@stew.dk" ,
        "Weber (US), Matthew L"
	,
        "Whitehead (US), Joshua C"
	
Subject: Discussion on the delayed start of major frame with ARINC653
 scheduler
Thread-Topic: Discussion on the delayed start of major frame with ARINC653
 scheduler
Thread-Index: AdvmTXSjjVtbwyT/QSCLI/dKN0kF9Q==
Date: Thu, 26 Jun 2025 03:50:30 +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=boeing.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BN0P110MB2148:EE_|SA1P110MB1359:EE_
x-ms-office365-filtering-correlation-id: 9fab9b26-becf-429c-9f25-08ddb4649844
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|38070700018;
x-microsoft-antispam-message-info: =?us-ascii?Q?dRPhLlJlZKOVNBXi84du+vh/uWiEZb3EsfxHjtIPfxXWbLEwyDq7aN4iPvJr?=
 =?us-ascii?Q?0Cha/OzBp1bk7OFEEBztNRnP/e76MO5/aIPFx5ZSO+IwC4RtZA9XnIRGNmLK?=
 =?us-ascii?Q?ovrEgK5U7t4cDEKCwoaUYNfQ16GXl+2xTWVjtITYhedwJII4pmETR8ITOLfB?=
 =?us-ascii?Q?LDkJiVqYdFKC/LSVE83OyvTSsT+nVO6bo9qyG8Bc+5Woz16HN0qgFOqWL9hU?=
 =?us-ascii?Q?mukHnv6g9Y11TvYoon0LaoBvT3JHS/t5ve0Q4dXhq7/jmq3PlltvEVaFKhEo?=
 =?us-ascii?Q?CDIocTMkNoJl7DdLdj4m58Fr4TWjo/Q5SwtnLTgHY/M0uzmPJY2TpfXgSCYW?=
 =?us-ascii?Q?yQkWPBR+QMvn9izDRM/oJZSm1rZqs/Z7k3H6MMckXD50vJLe7voD+H27SQHG?=
 =?us-ascii?Q?r8LV1roVsbMNFWoZ1msHXPsLe2l1IqwBtcP30CY8kLA+HunZKlsUnvmoXJTj?=
 =?us-ascii?Q?PzWTwcpv2I5x9vQ+8jBOXxVynWN6dlDGmaX44HqZQIMQI2TNvH17Yus//+e4?=
 =?us-ascii?Q?FC/cpoSSJmgqXMetIXPGLQxqem4cT/ru8SGMc5TkGcKYafcPDpPTVVvoXmuj?=
 =?us-ascii?Q?4sXsLh+ofr273vdcpvsY1sV24S4MUtP71RWtZMpuA0D6P/FTrvguIX1iTmSR?=
 =?us-ascii?Q?bZ6easH1gdbxvadrIDy7gTaoMZiGoHUSs4C2yG7e6fAPq196pmGe94kmT0uC?=
 =?us-ascii?Q?BFMFhXRlkt0DYvHdB6GME42wxCoMcbVM4310a32eDVAAE+3aYnuRsJWBTKqN?=
 =?us-ascii?Q?mzYNX8GRoI7o0NJ4Xmn2Qa2ll5148fPqVEwMZFdGGVBcyd3Lu9EQ6SjCbUgq?=
 =?us-ascii?Q?A5knAEVotL3rBHOf8LPKYYX/CTeKj1TUxVXLt37egYxKwlU0471+7m4x5ql2?=
 =?us-ascii?Q?3gDVH1Bp08LGF+QYCgRYPFtvH3qp5jQiuvDMeR7nKbXRSVjCmIi5i1nX0qol?=
 =?us-ascii?Q?wPABcucD7sgow9OCaBBVFeQmwoUJ67aU9aDTUVs3iVIecu0hil25pXMaOtsT?=
 =?us-ascii?Q?f/Xa3IRdz4b5r8KRVBvAAaXBHuso7C26auS7xPHABobQuB9ypYwIbOQOh1Nx?=
 =?us-ascii?Q?rtrNMNIytsblxhJTDWd6RWvPxZ+Zz8bJmzXjIOjCeQM0MMGyAKBSNv5/tBj7?=
 =?us-ascii?Q?1gIzpq+s1SoUuoHSQmX3cEGlGJFvXOYXG7N1j7gfS48yLoHNkPNdJLhZEoSv?=
 =?us-ascii?Q?4ei3Bj3PiNQmf9ACN2y/N8vzGz79yfSkwtsJ0tWOP2HOwtN9zibCQ/uAdU2G?=
 =?us-ascii?Q?d1Gvsl2uUnaofmkLt1jv+w9vc5KUT1wqo3I8I7TUmgkDyKsXBgAadp0Rw/Nh?=
 =?us-ascii?Q?GpQvI+PpzQ+Jjobz86oNx7K69Ghd+JjJGOJ411pQj7MjGuH/a2Fu4qGsQAL3?=
 =?us-ascii?Q?Pikvci16R4I0YM0S0jstrLMhw6bI9CxgagOW+gDCuabFS9cAdt/tdxF8FNo7?=
 =?us-ascii?Q?TR3UvB/n+NwWjgqZXV6XWjILy+kclCfqqf3j+4tHpcEF71eIffOtsw=3D=3D?=
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN0P110MB2148.NAMP110.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?07HMVYT17xHGpP5+ry3vzNN//Ge48/klRKBntQnqBmExGjlxlpH97L63IjkB?=
 =?us-ascii?Q?gkywFSb48pqe6K8pjc0XlmJyFUD+P5JdNx4+vbWs7ZC5AWfeeAuZR/8ixQwY?=
 =?us-ascii?Q?Z4nr4UaHINyHZzg/2T5C3KK78X1nTzhJLOp/bbO39LDDIHGASt5b1YJiURFr?=
 =?us-ascii?Q?9m7FBMIULSTcHC4c19G11y/hs51WY20hKbgeqjRpA4YVlamWhBvu4oO/P2sB?=
 =?us-ascii?Q?gxdyQTdNrV7bqbyi/nJqfPlIt1LVNwJTbI9gpARy3NjmFdp9byDpImCi5EXi?=
 =?us-ascii?Q?lunX7/N8k+cLEmTOKscCjuD7lH4cMq4BigNA2R+tL7OVnIGq1TaMdBkrlXyv?=
 =?us-ascii?Q?XyLjYCitTh0vl7mKJQLagr+d86imVB3XiDYz4kVcvAlQVtOC+4NhfZCostVc?=
 =?us-ascii?Q?yOkHCT/shEph5tBM4ZBkkSlcUiSElsV6mci6pDZrhLPOd4343hhu8OFUCWYv?=
 =?us-ascii?Q?lqEjwN/HFXNIA/eWDSFLYKk7ds2jj9e2nMDVKQoOxCNwCVtT6SuRlHVY4FcW?=
 =?us-ascii?Q?8dhhvX2/OAGZsTxBCdy3Vl9vJA26i5Wjh3gL9swDE324VlsMN1+3/Xv+sCtG?=
 =?us-ascii?Q?jVjfGlWRH3vHrAgbDPnaKLwRmF5w78LIewba0fPdO/zT2dZL90t+sY6/Oy2C?=
 =?us-ascii?Q?8YKxq5tLV6bYaBbpiWZnYe4aZfS75fftu2ywyXSTQPOaJCSInpX95N0+kR+d?=
 =?us-ascii?Q?NE4Nx7CLM3YvE2lPnYxQxxdKDGHTE9cGR87DolftnO745FscVZEKueu054UG?=
 =?us-ascii?Q?ZiawO5Q5sKAaCLp/p+zA4r67XmieWsZ1Soasx2uu3IVyheWRPP+uCACZ/ZCx?=
 =?us-ascii?Q?vRlKYb0suG6aHeezm9DXxSoOj2+211Z7MgYjA0fzIYmV709QJxpL3vistbon?=
 =?us-ascii?Q?FtVw2cL7CUEr74MKdCqtjTIFu4w+UuTHUywFzbE7hGw3JO2u4ODaxR/zSwv2?=
 =?us-ascii?Q?DL7HZrFOskx7KeJ6c9Mp/PUcoFChcX4LQfkNe3g6uA6vfH1BQ7z7G0dAQK9U?=
 =?us-ascii?Q?VoARYzEXaWF1WtKSpnQxfKfMoUB/xAbwLFxXnXQDFBmQ4IUuT2rPU3NoNLXB?=
 =?us-ascii?Q?VnzbGRxIs6+2XJ+lLyS2EXqwniJdEb7g8HSY1OED7Zk0ZfgidnJ4dzruj2RO?=
 =?us-ascii?Q?/NJySbwgnJv2818NFv6lRopjCZ2FHn+FhOFCNaWEB3UVvTDY44xIzu5ptVPc?=
 =?us-ascii?Q?z+aRWN5dmbvgJR+oKd6woZ8fTwUh/uPuHogRYVQE6NFWQtaBJ6K9ohJjUIdP?=
 =?us-ascii?Q?/hBZBAUPg4urKlLSyciPsPWk8d0FsjonmAVTizAWKy69a99EkUJabtTSwkci?=
 =?us-ascii?Q?2NL6wE+hEPIILTwtyDWSJwBqUc/My4Evg3+3LQcLeZ6VEkZMXMuoJFsRSApq?=
 =?us-ascii?Q?wrXtmw62foWHlhdTtwPhVfACJHUDwBrLueEAeaTzuHVZbWaFg/y3l4G9/j9I?=
 =?us-ascii?Q?OJrnEgE3W2b8tMP3tRwS0oXTr4kYuQO1r6OLKZ67VISWR6MMAOkPCdClgGCK?=
 =?us-ascii?Q?9VdqjLJOhER3EBBH+nnu0CP8IyOxBTNeoVS7?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN0P110MB2148.NAMP110.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 9fab9b26-becf-429c-9f25-08ddb4649844
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2025 03:50:30.0519
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bcf48bba-4d6f-4dee-a0d2-7df59cc36629
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1P110MB1359
X-OriginatorOrg: boeing.com
X-TM-AS-GCONF: 00

We are observing a slight delay in the start of major frame with the curren=
t implementation of ARINC653 scheduler, which breaks the determinism in the=
 periodic execution of domains.

This seems to result from the logic where the variable "next_major_frame" i=
s calculated based on the current timestamp "now" at a653sched_do_schedule(=
).

static void cf_check
a653sched_do_schedule(

    else if ( now >=3D sched_priv->next_major_frame )
    {
        /* time to enter a new major frame
         * the first time this function is called, this will be true */
        /* start with the first domain in the schedule */
        sched_priv->sched_index =3D 0;
        sched_priv->next_major_frame =3D now + sched_priv->major_frame;
        sched_priv->next_switch_time =3D now + sched_priv->schedule[0].runt=
ime;
    }

Therefore, the inherent delta between "now" and the previous "next_major_fr=
ame" is added to the next start of major frame represented by the variable =
"next_major_frame".

And I think the issue can be fixed with the following change to use "next_m=
ajor_frame" as the base of calculation.

diff --git a/xen/common/sched/arinc653.c b/xen/common/sched/arinc653.c inde=
x 930361fa5c..15affad3a3 100644
--- a/xen/common/sched/arinc653.c
+++ b/xen/common/sched/arinc653.c
@@ -534,8 +534,11 @@ a653sched_do_schedule(
          * the first time this function is called, this will be true */
         /* start with the first domain in the schedule */
         sched_priv->sched_index =3D 0;
-        sched_priv->next_major_frame =3D now + sched_priv->major_frame;
-        sched_priv->next_switch_time =3D now + sched_priv->schedule[0].run=
time;
+
+        do {
+            sched_priv->next_switch_time =3D sched_priv->next_major_frame =
+ sched_priv->schedule[0].runtime;
+            sched_priv->next_major_frame +=3D sched_priv->major_frame;
+        } while ((now >=3D sched_priv->next_major_frame) || (now >=3D sche=
d_priv->next_switch_time));
     }
     Else

Can I get your advice on this subject?

Should you have any questions about the description, please let me know.

Here are the details to reproduce the issue on QEMUARM64.

[Xen version]
- 4.19 (43aeacff8695850ee26ee038159b1f885e69fdf)

[ARINC653 pool configuration]
- name=3D"Pool-arinc"
- sched=3D"arinc653"
- cpus=3D["3"]

[Dom1 configuration]
- name =3D "dom1"
- kernel =3D "/etc/xen/dom1/Image"
- ramdisk =3D "/etc/xen/dom1/guest.cpio.gz"
- extra =3D "root=3D/dev/loop0 rw nohlt"
- memory =3D 256
- vcpus =3D 1
- pool =3D "Pool-arinc"

[Major frame configuration]
$ a653_sched -p Pool-arinc dom1:10 :10 //20 msec (Dom1 10 msec : Idle 10 ms=
ec)

[Collecting xentrace dump]
$ xentrace -D -T 5 -e 0x2f000 /tmp/xentrace.bin

Parsed xentrace shows that its runstate change from 'runnable' to 'running'=
, which means the start of major frame, is slightly shifted every period.
Below are the first 21 traces since dom1 has started running. With the give=
n major frame of 20 msec, the 21st major frame should have started at 0.414=
553536 sec (0.01455336 + 20 msec * 20).
However, it started running at 0.418066096 sec which results in 3.5 msec of=
 shift, which will be eventually long enough to wrap around the whole major=
 frame (roughly after 120 periods).
=20
0.014553536 ---x d?v? runstate_change d1v0 runnable->running
0.034629712 ---x d?v? runstate_change d1v0 runnable->running
0.054771216 ---x d?v? runstate_change d1v0 runnable->running
0.075080608 -|-x d?v? runstate_change d1v0 runnable->running
0.095236544 ---x d?v? runstate_change d1v0 runnable->running
0.115390144 ---x d?v? runstate_change d1v0 runnable->running
0.135499040 ---x d?v? runstate_change d1v0 runnable->running
0.155614784 ---x d?v? runstate_change d1v0 runnable->running
0.175833744 ---x d?v? runstate_change d1v0 runnable->running
0.195887488 ---x d?v? runstate_change d1v0 runnable->running
0.216028656 ---x d?v? runstate_change d1v0 runnable->running
0.236182032 ---x d?v? runstate_change d1v0 runnable->running
0.256302368 ---x d?v? runstate_change d1v0 runnable->running
0.276457472 ---x d?v? runstate_change d1v0 runnable->running
0.296649296 ---x d?v? runstate_change d1v0 runnable->running
0.316753856 ---x d?v? runstate_change d1v0 runnable->running
0.336909120 ---x d?v? runstate_change d1v0 runnable->running
0.357329936 ---x d?v? runstate_change d1v0 runnable->running
0.377691744 |||x d?v? runstate_change d1v0 runnable->running
0.397747008 |||x d?v? runstate_change d1v0 runnable->running
0.418066096 -||x d?v? runstate_change d1v0 runnable->running

However, with the suggested change applied, we can obtain the deterministic=
 behavior of arinc653 scheduler, where every major frame starts 20 msec apa=
rt.
=20
0.022110320 ---x d?v? runstate_change d1v0 runnable->running
0.041985952 ---x d?v? runstate_change d1v0 runnable->running
0.062345824 ---x d?v? runstate_change d1v0 runnable->running
0.082145808 ---x d?v? runstate_change d1v0 runnable->running
0.101957360 ---x d?v? runstate_change d1v0 runnable->running
0.122223776 ---x d?v? runstate_change d1v0 runnable->running
0.142334352 ---x d?v? runstate_change d1v0 runnable->running
0.162126256 ---x d?v? runstate_change d1v0 runnable->running
0.182261984 ---x d?v? runstate_change d1v0 runnable->running
0.202001840 |--x d?v? runstate_change d1v0 runnable->running
0.222070800 ---x d?v? runstate_change d1v0 runnable->running
0.242137680 ---x d?v? runstate_change d1v0 runnable->running
0.262313040 ---x d?v? runstate_change d1v0 runnable->running
0.282178128 ---x d?v? runstate_change d1v0 runnable->running
0.302071328 ---x d?v? runstate_change d1v0 runnable->running
0.321969216 ---x d?v? runstate_change d1v0 runnable->running
0.341958464 ---x d?v? runstate_change d1v0 runnable->running
0.362147136 ---x d?v? runstate_change d1v0 runnable->running
0.382085296 ---x d?v? runstate_change d1v0 runnable->running
0.402076560 ---x d?v? runstate_change d1v0 runnable->running
0.421985456 ---x d?v? runstate_change d1v0 runnable->running

Thanks,
Anderson


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 06:10:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 06:10:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1025882.1401120 (Exim 4.92)
	(envelope-from )
	id 1uUfoq-0007Mh-Om; Thu, 26 Jun 2025 06:10:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1025882.1401120; Thu, 26 Jun 2025 06:10: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 1uUfoq-0007Ma-LK; Thu, 26 Jun 2025 06:10:44 +0000
Received: by outflank-mailman (input) for mailman id 1025882;
 Thu, 26 Jun 2025 06:10: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 1uUfop-0007Kc-9h
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 06:10:43 +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 424f317f-5254-11f0-b894-0df219b8e170;
 Thu, 26 Jun 2025 08:10:29 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a6d1369d4eso270922f8f.2
 for ; Wed, 25 Jun 2025 23:10:29 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d86f701csm148107875ad.217.2025.06.25.23.10.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 25 Jun 2025 23:10:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 424f317f-5254-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750918228; x=1751523028; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=khMk2IX4IhlJytG0pFhEMNyHmUbj0HrxsnGjlRpXUYw=;
        b=W/tdwvXQP2vw0zQLFsMhBKiSpdr4SVFGRDSzGzkwxQGvW+uQ5YDDNHyai12pw/+mvX
         xsq4TS/z1w3oYY8gjDjqrnB0eahOxoZIDJwKiC4cNCZgQss02Ej0d/gHz1GcmE1fHFNC
         9NkkVkdIWqk1eIEWXrx24TgjJrfEVDeiY9MvMkXsMuyK1nycGfTDzBp3cgsnhGVUYlJC
         2ByInRZ5r9ugQVY+sQ5D4+re6VM1KZchxpgQIX1SEtcZZ6hjIrPnHaGOQcGLWrLPrjBU
         HBedUaglaM+bE/mpkxupO0AWUQIYaB26Dj3L+cekZafJoHGufFJ8fkVXRSOW6C0+w4Bi
         YWEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750918229; x=1751523029;
        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=khMk2IX4IhlJytG0pFhEMNyHmUbj0HrxsnGjlRpXUYw=;
        b=ufzaGZgp1T11mp2TttfuW4ogZCfWpxQpjbNH2N/L5BQ3u8ggoNaWasmrO8KzPLnwAb
         4JjnHzItPburjy6s+V0sArpCtWC/kAmpHzJYGPXFqrfOL6ZoytWFy+QE5ufaMG0ArziY
         QIc9f5hpeVy3IqHbSrPXRk5GaSMVeWC9v1RG9SQ04XiMkbHJVJysrjr8v2Fl4JccHekt
         KfAgLjv5u07CwXlfGDvls4tVufUzx5URXu6cs8iLwQsQMxVJDrbBl6O3JiHYl/mAbbZF
         UjNg0exjfTolVYxjQOq0Iz0H0fvBbUDNl+gJocDtjT3yC9btp8CD4dfH4dceIHbpQY1/
         Qp9Q==
X-Gm-Message-State: AOJu0YytAQa4HNHYkHEUxmtfZ62E3+8dkXShwiQGL2a9WsKTY2BLWlUc
	LDRiP8/Bxo7D6i3SkxqMiwyUEBGoRtokQaJp/GS9hFlltoXb0OpRUQ2iDQVh7iGmuQ==
X-Gm-Gg: ASbGncu0FsMDlxskQQpQ9ybdDr1CLQBEdl/qNPfHyqCrixlf4feRN04oNKnRz/IDEni
	E1w4wzdPUkcxrslKbiZjL9LQR4e5cUjV7Q9ksb74uSocRD63xT4+23/gH6y4wO5334PE42rPAyn
	5VCgEADoG2vsCmyy8jPhPpNaETXdn1s+FRyhR4xrVLhrwrDmjs/+EpxtuZP/9kmy/9ZBDnJcIrQ
	jnVAytPfjLdn6fJw5WpqG94t0blUgphgYQJMdRZxzbeSLAeEIt9IVzJ0p+QdAyO15CbdRVFlrkm
	8qPFc1+eRU82W0KY4r3y91zc6d0w9xVt70l+ImF8AUY89+e8gfcx0akdEY23MEVl9LORl6xEzd9
	hosYkgQHbP7oTs3fyfF9GGN7mSWb6oJiUy/Y8F0tRio91x0u3BspEMKBDUw==
X-Google-Smtp-Source: AGHT+IFsvY3XdK0ytlJNEOiyGLOndo9xUdM9aLuh4iEl7bw047+QvDDvRSw4kK+hTdUJqdsPdl3SYQ==
X-Received: by 2002:a05:6000:714:b0:3a5:8cc2:dabc with SMTP id ffacd0b85a97d-3a6f2e871d4mr1901259f8f.5.1750918228554;
        Wed, 25 Jun 2025 23:10:28 -0700 (PDT)
Message-ID: <8bb4e188-eb3b-4ee3-88cc-93c826b04ef8@suse.com>
Date: Thu, 26 Jun 2025 08:10:16 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v4 5/8] xen/domctl: extend XEN_DOMCTL_assign_device to
 handle not only iommu
To: Oleksii Moisieiev 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper ,
 Anthony PERARD ,
 Bertrand Marquis , Juergen Gross
 , Julien Grall ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Volodymyr Babchuk ,
 Grygorii Strashko ,
 Stefano Stabellini 
References: 
 <4f58bf9c47c40413ee9250c4cd21458382aac857.1747669845.git.oleksii_moisieiev@epam.com>
 
 
 
 <1780646c-cb6f-4508-86c8-a573fbc09f6a@epam.com>
 <1e116116-ddf7-4640-9809-2502203abe46@suse.com>
 <3e190e60-74a4-4565-acae-3b8602a4c46e@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: <3e190e60-74a4-4565-acae-3b8602a4c46e@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 25.06.2025 21:56, Oleksii Moisieiev wrote:
> 
> On 23/06/2025 10:15, Jan Beulich wrote:
>> On 19.06.2025 18:15, Oleksii Moisieiev wrote:
>>> On 18/06/2025 03:04, Stefano Stabellini wrote:
>>>> On Thu, 12 Jun 2025, Oleksii Moisieiev wrote:
>>>>>>> diff --git a/xen/arch/arm/firmware/sci.c b/xen/arch/arm/firmware/sci.c
>>>>>>> index e1522e10e2..8efd541c4f 100644
>>>>>>> --- a/xen/arch/arm/firmware/sci.c
>>>>>>> +++ b/xen/arch/arm/firmware/sci.c
>>>>>>> @@ -126,6 +126,43 @@ int sci_assign_dt_device(struct domain *d, struct dt_device_node *dev)
>>>>>>>         return 0;
>>>>>>>     }
>>>>>>>     
>>>>>>> +int sci_do_domctl(struct xen_domctl *domctl, struct domain *d,
>>>>>>> +                  XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
>>>>>>> +{
>>>>>>> +    struct dt_device_node *dev;
>>>>>>> +    int ret = 0;
>>>>>>> +
>>>>>>> +    switch ( domctl->cmd )
>>>>>>> +    {
>>>>>>> +    case XEN_DOMCTL_assign_device:
>>>>>>> +        ret = -EOPNOTSUPP;
>>>>>> Are you sure -EOPNOTSUPP is the right error code for the 3 checks below?
>>>>> The -EOPNOTSUPP code is used because this is part of a chained call after
>>>>> iommu_do_domctl, as stated in xen/common/domctl.c:859. The
>>>>> XEN_DOMCTL_assign_device
>>>>> call is expected to handle any DT device, regardless of whether the DT
>>>>> device is
>>>>> protected by an IOMMU or if the IOMMU is disabled.
>>>>> The following cases are considered:
>>>>>
>>>>> 1. IOMMU Protected Device (Success)
>>>>>
>>>>> If the device is protected by the IOMMU and iommu_do_domctl returns 0,
>>>>> we continue
>>>>> processing the DT device by calling sci_do_domctl.
>>>>>
>>>>> 2. IOMMU Disabled (-EOPNOTSUPP from iommu_do_domctl)
>>>>>
>>>>> If iommu_do_domctl returns -EOPNOTSUPP, indicating that the IOMMU is
>>>>> disabled,
>>>>> we still proceed to call sci_do_domctl.
>>>> OK this makes sense.  I think it is OK to have a special error code to
>>>> say "the IOMMU is disabled" but I don't know if it is a good idea to try
>>>> to use -EOPNOTSUPP for that. -EOPNOTSUPP could mean a hypervisor
>>>> configuration with domctl disabled, for instance.
>>>>
>>>> It might be wiser to use a different error code. Maybe ENOENT?
>>>>
>>> I see that in the following commit:
>>>
>>> 71e617a6b8 (use is_iommu_enabled() where appropriate..., 2019-09-17)
>>>
>>> -ENOSYS return code was changed to -EOPNOTSUPP in iommu_do_domctl.
>>>
>>> It's not clear to me why this was done from the commit description.
>> This has been discussed many times elsewhere. Many of our ENOSYS uses are
>> simply wrong. ENOSYS has very limited applicability: Unavailability of a
>> top-level hypercall (originally: syscall).
>>
> What is your opinion about changing it to -ENOENT to say "the IOMMU is 
> disabled" as Stefano suggested in [0]?
> 
> [0]: https://lists.xen.org/archives/html/xen-devel/2025-06/msg01233.html

To me, ENOENT is closer to ENODEV, and hence not overly applicable here.
If you want to avoid EOPNOTSUPP for whatever reason, how about ENXIO or
EIO? (EPERM might also be an option, but we assign that a different
meaning generally.)

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 06:17:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 06:17:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1025889.1401129 (Exim 4.92)
	(envelope-from )
	id 1uUfvJ-0007wy-Dz; Thu, 26 Jun 2025 06:17:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1025889.1401129; Thu, 26 Jun 2025 06: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 1uUfvJ-0007wr-BR; Thu, 26 Jun 2025 06:17:25 +0000
Received: by outflank-mailman (input) for mailman id 1025889;
 Thu, 26 Jun 2025 06:17: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 1uUfvI-0007wl-6v
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 06:17: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 374c5bec-5255-11f0-b894-0df219b8e170;
 Thu, 26 Jun 2025 08:17:20 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a531fcaa05so280195f8f.3
 for ; Wed, 25 Jun 2025 23:17:20 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d874fe39sm148478005ad.251.2025.06.25.23.17.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 25 Jun 2025 23:17:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 374c5bec-5255-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750918640; x=1751523440; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=oTF0+ihzfz4kUDQoZFagBc2UYaepFiD7BMnzfXmS91Y=;
        b=dc18djiIPy8Mm65kpmiCbh31DIjHHeXfoVboF0QbwrwOa+W4qGCUiVVS7MupBlAznd
         bw3G2vQKi+0ArNnpJYA2SZg4vlQGbN7fvv+oup/ZPzD7iDrjFoxwfGhNGzIufkbhGMS+
         UNtn85ZMLZw9oBTyX3osmfw9thzKAf25QeIyCx2grVZoGUy8MACdVSkW8U84Z0w5n3zh
         mfYK6604TLObTa/2jmo/9GCTgWYUO5R8xNG5UgrWyc+zNVrbWB1/SOAnLZIhRIX7e/rB
         lNf7NiqMVKqKm7iVHCButvhKrDjvrMw5POBnHpbKkJ99/9vTESTbccJ9v0LGAWtchHjm
         s7hg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750918640; x=1751523440;
        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=oTF0+ihzfz4kUDQoZFagBc2UYaepFiD7BMnzfXmS91Y=;
        b=PNZ84/nG2hwU7m1p2i5+dXaYNzMnHmUY2o8kvB5W6KkQQgLXHaE/PgY+9JtDeC1h9b
         M/pmt8sF0Wyadqd7qe4hNRMjD17TerLGEvIUma8LqDzxX7G3rdMZenuBM3o65dtywdm+
         pJodHoo97jU1lKfZRkNxW7MujvWLmuFpqZuMqz/EQHdGFbUKhtUJWFinme0HAc/GGz+U
         iS8vq/jrsVIIkz2Ed6tR1Eb92Jw7qZo6h0PWNB5fHyC1voKkZ3S2q8f9l4sjA0t7YMzW
         1glmNoOPm44i9AhO4cW+UN1lsjOlRDh5jrxYe2V1PgapMlrUCSWml0qpmpL9KzwTAkpJ
         qnlA==
X-Forwarded-Encrypted: i=1; AJvYcCXVb3xEgHMJCKCe0X+2T0r0nBhJ4JGqUzMaO6kgUhvXxLShO9naa7DCpbbJBNIvsFXOPRtuHSl34zc=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy7JzW+cjmVV30BggDx0a3fmk9wA9TBn2Uj9bzn7lVeuduBIjtU
	0z3+uPChN9CJKA+UXSevMMpmG0P3dJ+yw16esHejlhXwY4/FVj7S3l/V4Lrv+/Zicw==
X-Gm-Gg: ASbGncvKrwrWFrfQ2MokGKnaw9jXGb60Jd2ElmzjTbZpzUBtcWxkf/11HehkvCZIJ+s
	gn6l87MrvGj+kNzl7dNol+Pw0iQeoh37mXfDJq1ZH7qEAVQlCy62oJ7nDhEgv0sfZBYDmp/qbr+
	jdG1IjwXTyQfy+r3a1s3wLDJ5j8WMFU5Q4ccym7s648ijFh66VT7+SYowCJQVg4+++vWtvSoKH2
	z/Ogpe9Z8+TtzmyZwVXEomdCXfTB1Anxg+59NdWpjSiZYuCNp8XeJqEeg8ixydU/+Gd4iM+rnSa
	+WvzKfuBIhw5qY/PrOcGmsYXK70eG0xwnBHcXAnNspb/5GJvqnaGbG4gnNVFoKaOep9y2MFOTSC
	ZyTZ0/Da168LjcaM15AdLBBG6kZRMfkeLXjJf/FctYjk/yhk=
X-Google-Smtp-Source: AGHT+IHrt2wufvA81nXTB59pCOJcogHROtKtPzmEXM2n1tflw4peYCtHoQvf0oCA89D0Fsv0hmAhLw==
X-Received: by 2002:a05:6000:230a:b0:3a4:e193:e707 with SMTP id ffacd0b85a97d-3a6ed652ad4mr4216896f8f.41.1750918639620;
        Wed, 25 Jun 2025 23:17:19 -0700 (PDT)
Message-ID: <06de6dd2-f73f-44be-8c72-6e5d400c3407@suse.com>
Date: Thu, 26 Jun 2025 08:17:09 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 4/8] pdx: introduce command line compression toggle
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20250620111130.29057-1-roger.pau@citrix.com>
 <20250620111130.29057-5-roger.pau@citrix.com>
 
 
 <23206592-6016-47cc-87a6-151c76f254d6@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 25.06.2025 19:45, Roger Pau Monné wrote:
> On Wed, Jun 25, 2025 at 06:00:48PM +0200, Jan Beulich wrote:
>> On 25.06.2025 17:46, Roger Pau Monné wrote:
>>> On Tue, Jun 24, 2025 at 03:40:16PM +0200, Jan Beulich wrote:
>>>> On 20.06.2025 13:11, Roger Pau Monne wrote:
>>>>> Introduce a command line option to allow disabling PDX compression.  The
>>>>> disabling is done by turning pfn_pdx_add_region() into a no-op, so when
>>>>> attempting to initialize the selected compression algorithm the array of
>>>>> ranges to compress is empty.
>>>>
>>>> While neat, this also feels fragile. It's not obvious that for any
>>>> algorithm pfn_pdx_compression_setup() would leave compression disabled
>>>> when there are zero ranges. In principle, if it was written differently
>>>> for mask compression, there being no ranges could result in compression
>>>> simply squeezing out all of the address bits. Yet as long as we think
>>>> we're going to keep this in mind ...
>>>
>>> It seemed to me that nr_rages == 0 (so no ranges reported) should
>>> result in no compression, for example on x86 this means there's no
>>> SRAT.
>>
>> Just to mention it: While in the pfn_pdx_compression_setup() flavor in
>> patch 3 there's no explicit check (hence the logic is assumed to be
>> coping with that situation),
> 
> If you prefer I can leave the pfn_pdx_compression_setup() as-is in
> patch 3, as AFAICT that implementation does cope with nr_ranges == 0,
> that would result in a mask with just the low bits set, and hence
> hole_shift will be 0.
> 
>> the one introduced in the last patch does
>> have such an explicit check. Apparently there the logic doesn't cleanly
>> cover that case all by itself.
> 
> No, I don't think the logic in patch 8 will cope nicely with nr_ranges
> == 0, it seems to me at least the flsl() against a 0 pdx size mask
> would result in an invalid pdx_index_shift given the current logic.
> 
> IMO it's best to short-circuit the nr_ranges == 0 case early in the
> function, as that avoids complexity.

FTAOD - I didn't mean to ask for any change. I merely meant to point out
that already within this series the special use of setting nr_ranges to
zero requires (a tiny bit of) extra care. But yes, since nr_ranges can
also end up being zero for other reasons, that bit of care is necessary
anyway.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 06:39:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 06:39:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1025899.1401139 (Exim 4.92)
	(envelope-from )
	id 1uUgG9-0002K1-4B; Thu, 26 Jun 2025 06:38:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1025899.1401139; Thu, 26 Jun 2025 06:38:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUgG9-0002Ju-1Z; Thu, 26 Jun 2025 06:38:57 +0000
Received: by outflank-mailman (input) for mailman id 1025899;
 Thu, 26 Jun 2025 06:38:55 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uUgG6-0002Jo-ST
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 06:38:55 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 28f9d17c-5258-11f0-a30f-13f23c93f187;
 Thu, 26 Jun 2025 08:38:25 +0200 (CEST)
Received: from nico.tail79467d.ts.net (unknown [46.228.253.214])
 (Authenticated sender: nicola)
 by support.bugseng.com (Postfix) with ESMTPSA id 697934EE989B;
 Thu, 26 Jun 2025 08:38:22 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 28f9d17c-5258-11f0-a30f-13f23c93f187
Authentication-Results: bugseng.com; arc=none smtp.remote-ip=46.228.253.214
ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1750919904;
	b=yLHdS4Q7PKMNmMvv6i9wf/mJv525rpzURRWJwQjsOGQ3GxwtH8Yns9DuBAZ6vJSrq4Fh
	 yCA9PpPstmlAscS+pZ+eXEY5m27JZyuYD9gZlMQt1q4hXM6SYe/RkEyqm7qnhTmH4c/5D
	 fvV90zUUAYfJ/dKReFBb8gspaPJH+ErMO3UvVrvUG3bUilfXvdw7fDfLDtZD9ekNHsNW3
	 jC9b0dqpWvQt2WHXujPttKDg9Vv3o6rlx4ZeZwIS1ZVZkOS2EgsdbKmWv4JkvFqIzonSX
	 ID3AVsLWR3UgyuXVN2MRgp6gUhvEFrzuAsb2L7MRUAgF3ojgCZu/Hhegx7FcRdisbSD3k
	 WLUbaRVpKiEM4maV/dhXCr6/2LObtA42wXlp0OC0i1z/lwOWszL4P9U1M9tmKhP6qg8d9
	 m9RqYzg1ifG9tDg2Fnk80BLhxDJAEc35eMaL2DZuGDrQMblRC1AuJYQFd9hHzXx82Z2sf
	 Fqm8fJT9OjXODwjnZNuFhx/vqOGPfcrwnQSQFg50ZvJFlslXq4KFOk0aGi+V5JwaMB+sH
	 RWIk4bhMNGRCggZKotZhJPt5YeTHV7UNAqFzXdiNQornV4I/Ec27kdYVGwB7LsyPRTT0O
	 E9xp2Qv0GEVFdm8CNzvQfN6SZvhfalBnWXYzsKTZexKkPwQUKtowHjSf/WMS5C8=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1750919904;
	h=DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer:
	 MIME-Version:Content-Transfer-Encoding;
	bh=oQrXzCRUj/9EDUcm1lVVMIZUPbolg+1+jcZaFR2XY8c=;
	b=aHoiHG5l39k5UcGzwTsBeispIZPwjEnP9w7iPEHZB4ttcT3Ww3ZrGwlXSsjd1PR18/aV
	 GFEiJFILD1EDl9t2Van4i4biliKq9HnlpDXSA2CbOpEGVVo3iND+w2eAyHqTcKP0vGcLF
	 9oOEw/UkRzbv0uOw4IgpZeEFnCqOCeTE/MUa9dN4Nkn3IuFXn0WX0PRA9Cw17y3qfTUL9
	 Vwt191fCM9nI90QYmfnNeHl8KCHUKC/W/jAZfbmDkshmARNqYBulmQKgOS14rEUPTsSi7
	 38B38xK/QHJQeky/M7SCzJOXuh3xs+faD4I4RSx/kCHPAtv8cAEDcta/c6mOgQJ4hdrW+
	 ucZOT11m2cBZMmd1q4f/5nf6SFhYkPnxG0A/lDqowAYLHLe2tmF/hqZv58+fyC7jHrBUG
	 VnLAyFfJOchwPElCIqihS//FWdOcY9wJ4JhOwI7FlZLRC0/xKOWaVm8zq2VgX/4BXinOV
	 CqtVog0+BkRFgUDlM0tMAztKGrxOeq6HN4L9e5dGxxs3JNg9d+WbMiiLqaFZfoZhwsoV7
	 vSqZJS80VgtwgLkU37t19KoYdKi0dEYh4w/RnJ130iL4g8DFbA+ycyFu9mEznYZ3SlStS
	 KI0fSxxcJXcgoug3FsLZoifOlSwM8xwEsyGLuA7a5Ak3G6MNfq3020E7qN6AD2U=
ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=46.228.253.214
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1750919903; bh=ijvoRc6978K4tpVuonXlG24o0J0Oueq2vRD/faZQN40=;
	h=From:To:Cc:Subject:Date:From;
	b=Jkjqh09Mz1M/amAXa9HcZZVAZIULYwc+SklVfiapDWbHvvogTrjkJeqj6nwTp4Vc8
	 +FBOq4DomjsbrS6a6qe3JEjwQTJFEmSDkyEA7eJyDDlNEdbL+DvpYD8IrkVHN37oR3
	 x5cbb30d7X2CytBn90UsnvcSFzhPraY+k/7pcV+WyEbRLTiGVm/s94A91KDeMJ+AoN
	 2PbdvhdqAUpEe7v+oi/rVAHH7HVJs2fyjfG/jN5eWWFbMQk1l1lybHuUsBXK9bzZqM
	 p2RhNyrWDlsZ6Kze+2vT/V3rBcHWq8yIMadfb2s5pWZBAOvkn8TeU/B3tkrvftU1+0
	 +tMgbCdJk5JYQ==
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 ,
	Doug Goldstein ,
	Anthony Perard ,
	Alessandro Zucchelli 
Subject: [XEN PATCH] automation/eclair: Make report browsing URL configurable.
Date: Thu, 26 Jun 2025 08:38:18 +0200
Message-ID: <2c0003504925e6f62b0bb1a13711c206e40f9393.1750919773.git.nicola.vetrini@bugseng.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Currently, the URL where the ECLAIR MISRA C scan reports are saved
is hardcoded; making it configurable allows multiple runners and storage
servers to be used without resorting to publishing all artifacts
to the same report server.

Signed-off-by: Alessandro Zucchelli 
Signed-off-by: Nicola Vetrini 
---
Note: this is a key enabler for drafting more comprehensive community
analyses that can be possibly split between different machines
---
 .../eclair_analysis/ECLAIR/action.settings    | 31 +++++++++++++++----
 .../eclair_analysis/ECLAIR/action_push.sh     |  2 +-
 automation/gitlab-ci/analyze.yaml             |  2 ++
 automation/scripts/eclair                     | 13 +++++++-
 4 files changed, 40 insertions(+), 8 deletions(-)

diff --git a/automation/eclair_analysis/ECLAIR/action.settings b/automation/eclair_analysis/ECLAIR/action.settings
index 1577368b613b..f822f0ea66d7 100644
--- a/automation/eclair_analysis/ECLAIR/action.settings
+++ b/automation/eclair_analysis/ECLAIR/action.settings
@@ -14,9 +14,6 @@ autoPRRepository="${AUTO_PR_REPOSITORY:-}"
 # Customized
 autoPRBranch="${AUTO_PR_BRANCH:-}"
 
-# Customized
-artifactsRoot=/var/local/eclair
-
 case "${ci}" in
 github)
     # To be customized
@@ -166,12 +163,34 @@ esac
 
 ECLAIR_BIN_DIR=/opt/bugseng/eclair/bin/
 
-artifactsDir="${artifactsRoot}/xen-project.ecdf/${repository}/ECLAIR_${ANALYSIS_KIND}"
+# Artifacts URL served by the eclair_report server
+if [ -z "${MACHINE_ARTIFACTS_ROOT}" ];
+then
+  echo "WARNING: No artifacts root supplied, using default"
+fi
+if [ -z "${MACHINE_ECDF_DIR}" ];
+then
+  echo "WARNING: No ecdf dir supplied, using default"
+fi
+artifactsRoot="${MACHINE_ARTIFACTS_ROOT:-/var/local/eclair}"
+artifactsEcdfDir="${MACHINE_ECDF_DIR:-xen-project.ecdf}"
+artifactsDir="${artifactsRoot}/${artifactsEcdfDir}/${repository}/ECLAIR_${ANALYSIS_KIND}"
 subDir="${subDir}${variantSubDir}"
 jobHeadline="${jobHeadline}${variantHeadline}"
 
-# Customized
-eclairReportUrlPrefix=https://saas.eclairit.com:3787
+# Remote eclair_report hosting server
+if [ -z "${MACHINE_HOST}" ];
+then
+  echo "WARNING: No machine host supplied, using default"
+fi
+if [ -z "${MACHINE_PORT}" ];
+then
+  echo "WARNING: No machine port supplied, using default"
+fi
+
+eclairReportHost="${MACHINE_HOST:-saas.eclairit.com}"
+eclairReportPort="${MACHINE_PORT:-3787}"
+eclairReportUrlPrefix="https://${eclairReportHost}:${eclairReportPort}"
 
 jobDir="${artifactsDir}/${subDir}/${jobId}"
 updateLog="${analysisOutputDir}/update.log"
diff --git a/automation/eclair_analysis/ECLAIR/action_push.sh b/automation/eclair_analysis/ECLAIR/action_push.sh
index 45215fbf005b..5002b48522e2 100755
--- a/automation/eclair_analysis/ECLAIR/action_push.sh
+++ b/automation/eclair_analysis/ECLAIR/action_push.sh
@@ -1,6 +1,6 @@
 #!/bin/sh
 
-set -eu
+set -eux
 
 usage() {
     echo "Usage: $0 WTOKEN ANALYSIS_OUTPUT_DIR" >&2
diff --git a/automation/gitlab-ci/analyze.yaml b/automation/gitlab-ci/analyze.yaml
index 5b00b9f25ca6..f027c6bc90b1 100644
--- a/automation/gitlab-ci/analyze.yaml
+++ b/automation/gitlab-ci/analyze.yaml
@@ -8,6 +8,8 @@
     ENABLE_ECLAIR_BOT: "n"
     AUTO_PR_BRANCH: "staging"
     AUTO_PR_REPOSITORY: "xen-project/xen"
+    MACHINE_ARTIFACTS_ROOT: "/space"
+    MACHINE_ECDF_DIR: "XEN.ecdf"
   script:
     - ./automation/scripts/eclair 2>&1 | tee "${LOGFILE}"
   artifacts:
diff --git a/automation/scripts/eclair b/automation/scripts/eclair
index 0a2353c20a92..7020eaa0982f 100755
--- a/automation/scripts/eclair
+++ b/automation/scripts/eclair
@@ -1,4 +1,15 @@
-#!/bin/sh -eu
+#!/bin/sh -eux
+
+# Runner-specific variables
+ex=0
+export "$(env | grep MACHINE_ARTIFACTS_ROOT)" || ex=$?
+[ "${ex}" = 0 ] || exit "${ex}"
+export "$(env | grep MACHINE_ECDF_DIR)" || ex=$?
+[ "${ex}" = 0 ] || exit "${ex}"
+export "$(env | grep MACHINE_HOST)" || ex=$?
+[ "${ex}" = 0 ] || exit "${ex}"
+export "$(env | grep MACHINE_PORT)" || ex=$?
+[ "${ex}" = 0 ] || exit "${ex}"
 
 ECLAIR_ANALYSIS_DIR=automation/eclair_analysis
 ECLAIR_DIR="${ECLAIR_ANALYSIS_DIR}/ECLAIR"
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 26 06:41:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 06:41:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1025906.1401150 (Exim 4.92)
	(envelope-from )
	id 1uUgIn-0003nP-Hw; Thu, 26 Jun 2025 06:41:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1025906.1401150; Thu, 26 Jun 2025 06:41: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 1uUgIn-0003nI-Ef; Thu, 26 Jun 2025 06:41:41 +0000
Received: by outflank-mailman (input) for mailman id 1025906;
 Thu, 26 Jun 2025 06:41: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 1uUgIl-0003nC-EH
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 06:41:39 +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 9b50adf4-5258-11f0-a30f-13f23c93f187;
 Thu, 26 Jun 2025 08:41:36 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a5257748e1so369627f8f.2
 for ; Wed, 25 Jun 2025 23:41:36 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-749c8851337sm6084616b3a.126.2025.06.25.23.41.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 25 Jun 2025 23:41:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9b50adf4-5258-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750920096; x=1751524896; 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=YRQYjpAwhqBYk3HxETddrIIdoO8JHXwaW3HZ/hSgaKI=;
        b=giyid+dd5JFJlUspftCptxXhsezQASF/sT7wBOlJgxGeqbPlkDc/+p0KJw6Z2daV18
         cBQ/05u2ehvquPCJs7SEVCxe0TEYXS1jrrdHhgYfQOTN2l+MPPfY5DMn9KkWA3/mERa3
         t9onGfkGhKUlVtzo1XOLPfZzG+Av32Mjb7z9oXwAUXAaJIit5JoSSIpQ5vMZpwJA6o2e
         CJo2EbkqqKsvLEhhVyXJYL+hge5hNULvzLKToi4JGnav/XLSK9xu0SZG0sAv2QOmRJT9
         1gKTghTdzlFphIjWd2YakbXyAhgIWXG0bEAx5hTl7Xto6a91n40ON/uInbAGhlrGEE+I
         TPbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750920096; x=1751524896;
        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=YRQYjpAwhqBYk3HxETddrIIdoO8JHXwaW3HZ/hSgaKI=;
        b=Q63yeda+7/a7VcLdoGJfAqHZO+E4KVmmBKBksIHVJC3ruuu4YLMOaxeUqwaFG+gmRm
         IT4AniV+v+++uZHV1n33Bi0tbaNySLZs6Xrz384Sm8MgiyrvsjP6QiNPV6TdgJlsdr59
         FDQD9Cf8onfotItE5fZFjLdPR3WmrYU23+3Y/boe8O11qMdQO0GR53CDE1J8D3uGi5lV
         CQpMQMjFghYFxBrL6JUnVrtHMy/l76TnZPvasu0mJVO5STFvvCnrC+0VE55kEzd+MKz+
         cDwU9fxpo86u4/rJ0RQyFWs2ZAbtXBOWeSsuTXGjKSiQx9isWmp2Z2qvXT2yKo+qQX9+
         rpMw==
X-Gm-Message-State: AOJu0Yzp62s4Yh0qDNLPrgO0cses/i3IDiNHvA+5D6D39LHZfh6r1kB3
	b1RrufZSDoc40DyjCtZ0R1clOFBmGIXpEx+8HQTS1SCn87nT6KCCsMLjEQ+JZHQbvSP9itlZPLL
	jqoo=
X-Gm-Gg: ASbGnctLku9SznLCnPx0u+f8ys7AnD2JBmRCnLrq+I7N2dnzOlsjPsIcj0WVHAdSC8K
	3eFR8fbllnoCCQM8Swz42CBU1wani+qVyDCgDslN9z9XOadGJQhyNqZkky5Fvq/eOSlIJO04XMR
	sS3bgAa3lIwVOiyO7Z7klQtCmxrGI82SLwoyc2YtunwMtnXekQ6t0vqk7i7G55BeUiQXTqXGfgf
	dm9p/epjsU8OHTnLyF5BspESDhH75VCqOJqh9ZHMbjN2xjLmZ3U1rbvBitJzysSPXL0zmQdLSMv
	zFc9sI8dxFDnyRfCSCOF7u/hiAwP0uODBDrJUCH8fzU7S+/A8dcFqdg4X6FduXx9R8skfjGD+c3
	cIc//8ZdZ03sBkb0q2DLxrfFw0E7eoxe8OVKbIiqS0SZenjk=
X-Google-Smtp-Source: AGHT+IEu5LzMptFkmHsSXaVLgUfRl4RYzJ+9Cnc7ERaey9OtF4rFbbCL2yAo4Frvaka371T8QgP6aQ==
X-Received: by 2002:a05:6000:2004:b0:3a6:d579:ec21 with SMTP id ffacd0b85a97d-3a6ed61a4admr4580524f8f.12.1750920095916;
        Wed, 25 Jun 2025 23:41:35 -0700 (PDT)
Message-ID: <24bc698d-4e60-4f34-9b8b-8b1f315655f1@suse.com>
Date: Thu, 26 Jun 2025 08:41:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Jan Beulich 
Subject: preparations for 4.20.1
To: "xen-devel@lists.xenproject.org" 
Cc: Stefano Stabellini , Julien Grall
 , Anthony PERARD ,
 "community.manager@xenproject.org" 
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

All,

the release is due in about a week or two. Please point out backports you find
missing from the respective staging branch, but which you consider relevant.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 07:35:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 07:35:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1025951.1401228 (Exim 4.92)
	(envelope-from )
	id 1uUh8q-0002PW-45; Thu, 26 Jun 2025 07:35:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1025951.1401228; Thu, 26 Jun 2025 07:35:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUh8q-0002PP-1B; Thu, 26 Jun 2025 07:35:28 +0000
Received: by outflank-mailman (input) for mailman id 1025951;
 Thu, 26 Jun 2025 07:35: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 1uUh8o-0002PJ-Of
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 07:35:26 +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 1a1f95ad-5260-11f0-b894-0df219b8e170;
 Thu, 26 Jun 2025 09:35:15 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3a525eee2e3so457184f8f.2
 for ; Thu, 26 Jun 2025 00:35:15 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b34c4445c3fsm1011796a12.47.2025.06.26.00.35.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 26 Jun 2025 00:35:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1a1f95ad-5260-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750923315; x=1751528115; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=6zYxkOur4MvGv2/d/SZXTfsE80BS0nzVwbTD6CeT38M=;
        b=f9oZCKqple9uGsJ25E1hcVnlfkfvwa+jHNkRR6GryJANi18+lUMiEGBS8jRP74h/Z9
         lvudEHNPaauaLdo7s/sDW4dmvkUNXinOocQkW3YBDF77S77nyGItJooIui7TWy7lI6sT
         jikmzomowXvX8CJ7K8+5VCOm8nyQ0vnSTYBZKxXdKXoDZQk22mkKJfUstYSI2J21avpR
         YSVmn4EK0891ekrvzU8QHk5DSTKpvSDPFSY7BJ7W6nHMpcjXIuLnwhilLPfqlVi/kkPV
         hDV324r2KdZWAoxyu3m3Zub/y8NCHUh/9wvMwJuou5WUdppJ7zLhmNULm4UlAhE0xSna
         5MyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750923315; x=1751528115;
        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=6zYxkOur4MvGv2/d/SZXTfsE80BS0nzVwbTD6CeT38M=;
        b=UJPLXDhIO2zDcsVdM6bXOv82llKkAA6NmkaNi7vtQpctIw+bl5k/P0ygwNKkOpIUPN
         94p2sn9UxWqUC+sbHnsUJYPaNKyROnDwDdJFmV3d+XaPcMTHvGYt4NjjYo3l6Ne5YmR1
         IDhVT7owKgO6DiLjMKiv4A0vnGRFYGTqeFjJzenyaLlfWTN0pYtSXeD773JfsrA14DZf
         8Csi9WSH6ucMdP1gRCjHq++52yWjb1dsbpmiW37GCIMKCL8u0RHLR57TEYkdu6FagQkK
         b1a69TBlBCttB8Ibi0Q4iyq/5oxwNIdCVB10waYhtVKhnH1eYMhBLwrr+xuO5r0GTTvW
         LjqA==
X-Forwarded-Encrypted: i=1; AJvYcCXmUTgJ3EJ56OI+Oae6KyGkf6X2WBXtCxlvxPjEWnmADmjb/jsddJeYfyFmYDPP4ZSgMvUwPobk4n4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzJzcG4ro6E1jO4ew8y6p+WDgob+PZ+q04yAO3UoOpUDxLbN90r
	MEj0pAAVcSZU4YC0+IF6J6ktHvdbDElPSdphn1McHr462NganEXQh2BBTh7vMv/TGw==
X-Gm-Gg: ASbGncvG31/4W9PiwXM/GJcrmNXDHwOUebsGg4+HDb4ebysPQ9w16bP706MaWtIySr+
	oGWV40B5o7VuONB6Wf1R4KR4yaxFScb9+1suhgR83b/iIJZvI/QX68WBtnbkpHe5+ijA35IsxcH
	m9m39FuJXNYAgwj8TEjt96yR6hCCgsZFhGV15R3+ijcomrlo0rw/mqjgf3ucBJ2lQg/KY522eFh
	okz+I8tIeGkrM5xZARsrLLOf2bHfuhltzCYCl9iL6ghxTRctSRX2BIgSG/FnyUG7volhTnmTPOx
	CJ3x28BVdXafH5OjD6OwbnMD6LFJ7OSDlW3/kG+CcNkhXYWeVP9XMSOt0M6ks3TkA5Mw/4G1m9s
	TZVDZVyTSzf0I5f+anNVeHLTyaI+vsseAeHHWKQc4lswQB1avNimyN0Sajg==
X-Google-Smtp-Source: AGHT+IH8/54ih4C497dd3H3sXoY0rCkhXerZadzbLUSNTjtA3LGQ+uIY+SJgEUbTBGySHsawrcYBwg==
X-Received: by 2002:a05:6000:1acd:b0:3a0:aed9:e34 with SMTP id ffacd0b85a97d-3a6ed66e377mr5580843f8f.48.1750923315084;
        Thu, 26 Jun 2025 00:35:15 -0700 (PDT)
Message-ID: <475fb02b-0b00-4aab-b73c-9604fe050074@suse.com>
Date: Thu, 26 Jun 2025 09:35:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 8/8] pdx: introduce a new compression algorithm based
 on region offsets
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Oleksii Kurochko ,
 Community Manager ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250620111130.29057-1-roger.pau@citrix.com>
 <20250620111130.29057-9-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: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 25.06.2025 18:24, Roger Pau Monné wrote:
> On Tue, Jun 24, 2025 at 06:16:15PM +0200, Jan Beulich wrote:
>> On 20.06.2025 13:11, Roger Pau Monne wrote:
>>> --- a/xen/common/Kconfig
>>> +++ b/xen/common/Kconfig
>>> @@ -54,7 +54,8 @@ config EVTCHN_FIFO
>>>  
>>>  choice
>>>  	prompt "PDX (Page inDeX) compression"
>>> -	default PDX_MASK_COMPRESSION if !X86 && !RISCV
>>> +	default PDX_OFFSET_COMPRESSION if X86
>>> +	default PDX_MASK_COMPRESSION if !RISCV
>>>  	default PDX_NONE
>>>  	help
>>>  	  PDX compression is a technique designed to reduce the memory
>>> @@ -73,12 +74,30 @@ config PDX_MASK_COMPRESSION
>>>  	help
>>>  	  Compression relying on all RAM addresses sharing a zeroed bit region.
>>>  
>>> +config PDX_OFFSET_COMPRESSION
>>> +	bool "Offset compression"
>>> +	help
>>> +	  Compression relying on size and distance between RAM regions being
>>> +	  compressible using an offset lookup table.
>>> +
>>>  config PDX_NONE
>>>  	bool "None"
>>>  	help
>>>  	  No compression
>>>  endchoice
>>>  
>>> +config PDX_OFFSET_TLB_ORDER
>>
>> Please can we avoid the term "TLB" in the name? What we commonly call a TLB
> 
> It should have been TBL_ORDER, not TLB.  My finger memory is too use
> to type TLB I think.
> 
>> is somewhat different. In fact is there anything wrong with just
>> PDX_OFFSET_ORDER?
> 
> I've assumed that would be seen as too short and not descriptive
> enough.  If that's fine I will switch it.

Oh, TBL is fine with me. And perhaps indeed better, for being more precise.

>>> +	int "PDX offset compression lookup table order" if EXPERT
>>> +	depends on PDX_OFFSET_COMPRESSION
>>> +	default 6
>>> +	range 0 9
>>
>> Is 0 really a sensible lower bound? There's not going to be any compression
>> then, I suppose?
> 
> No, you can still compress a single range if start if offset from 0.
> See the following example in the test file:
> 
> /* Single range not starting at 0. */
> {
>     .ranges = {
>         { .start = (1 << MAX_ORDER) * 10,
>           .end   = (1 << MAX_ORDER) * 11 },
>     },
>     .compress = true,
> },
> 
> Which results in:
> 
> PFN compression using PFN lookup table shift 63 and PDX region size 0x40000
>  range 0 [0x00000280000, 0x000002bffff] PFN IDX   0 : 0x00000280000

Oh, indeed. But: Does this actually work? I'm not only slightly concerned
of PDX 0 (that may indeed be fine), but more as to mfn_valid(). An MFN below
the start of that region will still use index 0, aiui. (With the resulting
underflow, a huge PDX will result.) With PDX_TBL_MASK being zero, and with
there being only a single entry in both tables, the reverse translation will
use that single entry, simply undoing the underflowed subtraction. Hence
mfn_valid() would wrongly return true, afaict. (Thinking about it, the same
issue would appear to occur for MFNs above the sum of that range's start and
the region size.)

>>> --- a/xen/common/pdx.c
>>> +++ b/xen/common/pdx.c
>>> @@ -24,6 +24,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  
>>>  /**
>>>   * Maximum (non-inclusive) usable pdx. Must be
>>> @@ -40,6 +41,8 @@ bool __mfn_valid(unsigned long mfn)
>>>  
>>>  #ifdef CONFIG_PDX_MASK_COMPRESSION
>>>      invalid |= mfn & pfn_hole_mask;
>>> +#elif defined(CONFIG_PDX_OFFSET_COMPRESSION)
>>> +    invalid |= mfn ^ pdx_to_pfn(pfn_to_pdx(mfn));
>>
>> Hmm, that's pretty expensive already. Involving two (presumably back-to-back)
>> JMPs when compression isn't enabled.
> 
> There's a conditional with evaluate_nospec() below, so I think the
> JMPs are unlikely to make much difference?

Hard to tell. They still take up decode bandwidth and at least some execution
resources, aiui. But perhaps you're right and that's indeed negligible, or at
least acceptable enough. Especially since, ...

>  Otherwise I would need to
> check the index in the lookup table, and possibly introduce a new
> variable to store the PDX region size to ensure it also fits in there.
> 
> Overall I think it's more complex for possibly little benefit given
> the current code in mfn_valid() anyway.

... as you say, complexity would grow.

>>> +bool pdx_is_region_compressible(paddr_t base, unsigned long npages)
>>> +{
>>> +    unsigned long pfn = PFN_DOWN(base);
>>> +
>>> +    return pdx_to_pfn(pfn_to_pdx(pfn) + npages - 1) == (pfn + npages - 1);
>>
>> Aiui for this to be correct, there need to be gaps between the ranges
>> covered by individual lookup table slots. In the setup logic you have a
>> check commented "Avoid compression if there's no gain", but that doesn't
>> look to guarantee gaps everywhere (nor would pfn_offset_sanitize_ranges()
>> appear to)?
> 
> But if there are no gaps, the full region is covered correctly, and
> hence it's compressible?

If there's a guarantee that such ranges would be folded into a single one,
all would be fine.

> Maybe I'm missing something, could you maybe provide an example that
> would exhibit this issue?

My understanding is that when there's no gap between regions, and when
[base, base + npages) crosses as region boundary, then the expression
above will yield true when, because of crossing a region boundary, it
ought to be false. Or did I simply misunderstand the purpose of the
pdx_is_region_compressible() invocations?

>>> +    if ( nr_ranges > ARRAY_SIZE(ranges) )
>>> +    {
>>> +        printk(XENLOG_WARNING
>>> +               "Too many PFN ranges (%u > %zu), not attempting PFN compression\n",
>>> +               nr_ranges, ARRAY_SIZE(ranges));
>>> +        return false;
>>> +    }
>>> +
>>> +    for ( i = 0; i < nr_ranges; i++ )
>>> +        mask |= pdx_region_mask(ranges[i].base, ranges[i].size);
>>> +
>>> +    pfn_index_shift = flsl(mask);
>>
>> With this ...
>>
>>> +    /*
>>> +     * Increase the shift as much as possible, removing bits that are equal in
>>> +     * all regions, as this allows the usage of smaller indexes, and in turn
>>> +     * smaller lookup tables.
>>> +     */
>>> +    for ( pfn_index_shift = flsl(mask); pfn_index_shift < sizeof(mask) * 8 - 1;
>>
>> ... you don't need to do this here another time.
> 
> Oh, good catch.  This was ordered differently, and I didn't realize
> the duplication after the code movement.
> 
>> Also - why the subtraction of 1 in what the shift is compared against? Logic
>> below should in principle guarantee we never exit the loop because of the
>> conditional above, but if we made it that far it looks like we could as well
>> also look at the top bit.
> 
> Because for a single range this would otherwise end up with
> pfn_index_shift == 64, and thus lead to undefined behavior.

Hmm, right. Yet then isn't this another reason you need at least two array slots?
At least in the (theoretical) case of paddr_bits == 64? Which raises the question
whether the loop wouldn't better be bounded by paddr_bits anyway.

>>> +          pfn_index_shift++ )
>>> +    {
>>> +        const unsigned long bit = ranges[0].base & (1UL << pfn_index_shift);
>>> +
>>> +        for ( i = 1; i < nr_ranges; i++ )
>>> +            if ( bit != (ranges[i].base & (1UL << pfn_index_shift)) )
>>> +                break;
>>> +        if ( i != nr_ranges )
>>> +            break;
>>> +    }
>>> +
>>> +    /* Sort and sanitize ranges. */
>>> +    if ( !pfn_offset_sanitize_ranges() )
>>> +        return false;
>>> +
>>> +    /* Calculate PDX region size. */
>>> +    for ( i = 0; i < nr_ranges; i++ )
>>> +        size = max(size, ranges[i].size);
>>> +
>>> +    mask = PFN_DOWN(pdx_init_mask(size << PAGE_SHIFT));
>>> +    pdx_index_shift = flsl(mask);
>>> +
>>> +    /* Avoid compression if there's no gain. */
>>> +    if ( (mask + 1) * (nr_ranges - 1) >= ranges[nr_ranges - 1].base )
>>> +        return false;
>>> +
>>> +    /* Poison all lookup table entries ahead of setting them. */
>>> +    memset(pfn_pdx_lookup, ~0, sizeof(pfn_pdx_lookup));
>>> +    memset(pdx_pfn_lookup, ~0, sizeof(pfn_pdx_lookup));
>>
>> Have the arrays have initializers instead?
> 
> No, because otherwise early use (before the initialization done here)
> of the translation functions would give bogus results.

Isn't that true anyway? Before making it here, PDX and PFN have a fixed
(and hence wrong) relationship for the entire number space. And mfn_valid()
would yield true for any input no matter what the initializer, afaict. IOW
early uses look to be invalid anyway.

(Later) Oh, wait - your comment on pfn_pdx_compression_reset() made me
understand: We rely on identity mapping PDX <-> PFN if compression is
disabled, at least until alternatives patching arranges to bypass the
calculations.

>>> +           pfn_index_shift, mask + 1);
>>> +
>>> +    for ( i = 0; i < nr_ranges; i++ )
>>> +        printk(XENLOG_DEBUG
>>> +               " range %u [%#013lx, %#013lx] PFN IDX %3lu : %#013lx\n",
>>> +               i, ranges[i].base, ranges[i].base + ranges[i].size - 1,
>>> +               PFN_TBL_IDX(ranges[i].base),
>>> +               pfn_pdx_lookup[PFN_TBL_IDX(ranges[i].base)]);
>>
>> Do you really mean this to stay active also in release builds?
> 
> I had it guarded with #ifdef CONFIG_DEBUG initially, but later decided
> it was worth giving the possibility to print it in release builds if
> debug log level is selected.
> 
>> Also the outcome of the earlier loop isn't used by the intermediate printk().
>> Perhaps join both loops, thus allowing idx to be re-used here?
> 
> Hm, yes.  I wanted to first print the message about enabling PFN
> compression, and later the compression specific information.  I can
> move the message about enabling PFN compression ahead of the loop.

But that's not what I meant. You can move the body of the earlier loop
into the later one, since - as said - the printk() between the two loops
doesn't use what the first loop does.

>>> --- a/xen/include/xen/pdx.h
>>> +++ b/xen/include/xen/pdx.h
>>> @@ -65,6 +65,43 @@
>>>   * This scheme also holds for multiple regions, where HHHHHHH acts as
>>>   * the region identifier and LLLLLL fully contains the span of every
>>>   * region involved.
>>> + *
>>> + * ## PDX offset compression
>>> + *
>>> + * Alternative compression mechanism that relies on RAM ranges having a similar
>>> + * size and offset between them:
>>> + *
>>> + * PFN address space:
>>> + * ┌────────┬──────────┬────────┬──────────┐   ┌────────┬──────────┐
>>> + * │ RAM 0  │          │ RAM 1  │          │...│ RAM N  │          │
>>> + * ├────────┼──────────┼────────┴──────────┘   └────────┴──────────┘
>>> + * │<------>│          │
>>> + * │  size             │
>>> + * │<----------------->│
>>> + *         offset
>>> + *
>>> + * The compression reduces the holes between RAM regions:
>>> + *
>>> + * PDX address space:
>>> + * ┌────────┬───┬────────┬───┐   ┌─┬────────┐
>>> + * │ RAM 0  │   │ RAM 1  │   │...│ │ RAM N  │
>>> + * ├────────┴───┼────────┴───┘   └─┴────────┘
>>> + * │<---------->│
>>> + *   pdx region size
>>> + *
>>> + * The offsets to convert from PFN to PDX and from PDX to PFN are stored in a
>>> + * pair of lookup tables, and the index into those tables to find the offset
>>> + * for each PFN or PDX is obtained by shifting the to be translated address by
>>> + * a specific value calculated at boot:
>>> + *
>>> + * pdx = pfn - pfn_lookup_table[pfn >> pfn_shift]
>>> + * pfn = pdx + pdx_lookup_table[pdx >> pdx_shift]
>>
>> I assume it's intentional (for simplicity) that you omit the index masking
>> here?
> 
> Indeed.  I can add it, but I think the point here is to explain the
> algorithm used in a clear way, without implementation details.  I would
> consider the masking one of such implementation details.

I see. It's the balancing between simplicity and making the reader (wrongly)
suspect a possible array overrun here (as it happened in my case). Maybe
keep the expressions as they are, but add a few words towards masking in the
text?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 07:49:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 07:49:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1025973.1401237 (Exim 4.92)
	(envelope-from )
	id 1uUhMM-00048J-9w; Thu, 26 Jun 2025 07:49:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1025973.1401237; Thu, 26 Jun 2025 07:49:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUhMM-00048C-7O; Thu, 26 Jun 2025 07:49:26 +0000
Received: by outflank-mailman (input) for mailman id 1025973;
 Thu, 26 Jun 2025 07:49: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 1uUhMK-000485-SO
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 07:49:24 +0000
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com
 [2a00:1450:4864:20::32d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 12821cea-5262-11f0-a30f-13f23c93f187;
 Thu, 26 Jun 2025 09:49:22 +0200 (CEST)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-4538bc1cffdso1671865e9.0
 for ; Thu, 26 Jun 2025 00:49:22 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a6e8117187sm6429439f8f.101.2025.06.26.00.49.20
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 26 Jun 2025 00:49:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 12821cea-5262-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750924161; x=1751528961; 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=N2eBZ73J800zS0COuSSb7WwAu4nL1GCeHQjgrI24kL4=;
        b=BLUyqqfkkrE7h+Vw2RnLLdg7LMtCDL/2zwgznBry6ZyN7LpMEnZz/g1BzNlA6re8R3
         YoU1JwHOmAS9Ow8J/5PWlf5fKCEhkHZ9gLMYUZy6+H4xDBsahNXSlnBb7km3ziF1MMd/
         eERfPxmQlwaSj+4VjFqIxayOH8NwqmQwSIOw8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750924161; x=1751528961;
        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=N2eBZ73J800zS0COuSSb7WwAu4nL1GCeHQjgrI24kL4=;
        b=DuBYkVbihlfLTi6k4gYHQaBqVaa197ICkpVVrsc5EE89upSTrIBbH1U4Q0yQhb+GUb
         gcs25vcoiBpR1XBGSjfJzFEEdgvl8OnAMPGP5XGrPIHae53S70a446nawmF8eLp3PO3K
         0KZvTFOBKoctQMfsYHgPiY2sczdpdEmmBHlo5zdE3LDPYSlVpdOaToTBOPoMFDMXU6QN
         ZR1NzFhC1bjPFgMIj3kdyQXdeH2147+iK+AbBif6Xzemdg6CuX0X49deFZdJrq9il98g
         6FO9xOPS+EIPAOB4URdq7BWgIxI1wasBRHhRUFZRl5QGU34uxPbCi7rd36pzj/EhLrVR
         OuCQ==
X-Forwarded-Encrypted: i=1; AJvYcCWt3HNzH77xHN1HclcJL3z76jD02bZGF+4nEdWg1D/HJBu7KtmgwraZqqW2b4Dum5rxfF/AHUhDTYQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwIhB6NDY15UFMs8sQt8JT7bHBU16xYdriimvEW6S6Z+jncrdyS
	9UKx8zSpoJwd9WmghhJobWWpoIUAa9nDuV9Ndbw4eDJB5OLIAMGSHi3SSMBan2gjdT4=
X-Gm-Gg: ASbGncunn68UIX1lnACNLqufZmOJ5Hg/YWFCYomGYlHT5cvrx8dMabATeZqsN8OnQW/
	00TGjrTVmt//au5O23sJeGxAftGxTz7PSge25wcpBvPPBt5MlFP0OHnD1x9+0PkHRGSTL7F4lf5
	epKxB/Z5nMrrCazuHfZdnWAoiOAoJ+ouq44WW9DSOdRekYohUJQprl0oi9uJip9ZL/3m1A8nvNG
	SWXZLDqAgltAJF+v98yP6njVZNFMKTWUuf1iQJrsEFDPgA7QVSjMOOgvz31kK3Kj2EVk48ShPPm
	jUpHHOGqypo2bJNX8eJkVz8HdrnpfGiv8sLFnv1tIOJgNazPH+1IlY23lfAQkQ9tobtT1BELdWd
	3wvzNgemUQZIPh/5lnqfUJpeWYN6/1zEDafGVGt1f0GbNSQ==
X-Google-Smtp-Source: AGHT+IEX8T0o9JAt/xqkiCO4Z4Di1M0dnj4pP/mnuAu8IsEmIwPyUZom3xaz9I61nrm4fV9WdYOIwg==
X-Received: by 2002:a05:600c:4684:b0:450:cea0:1781 with SMTP id 5b1f17b1804b1-45381ae456bmr62138925e9.16.1750924161364;
        Thu, 26 Jun 2025 00:49:21 -0700 (PDT)
Date: Thu, 26 Jun 2025 09:49:20 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 2/8] kconfig: turn PDX compression into a choice
Message-ID: 
References: <20250620111130.29057-1-roger.pau@citrix.com>
 <20250620111130.29057-3-roger.pau@citrix.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 

On Tue, Jun 24, 2025 at 03:13:27PM +0200, Jan Beulich wrote:
> On 20.06.2025 13:11, Roger Pau Monne wrote:
> > Rename the current CONFIG_PDX_COMPRESSION to CONFIG_PDX_MASK_COMPRESSION,
> > and make it part of the PDX compression choice block, in preparation for
> > adding further PDX compression algorithms.
> > 
> > No functional change intended as the PDX compression defaults should still
> > be the same for all architectures, however the choice block cannot be
> > protected under EXPERT and still have a default choice being
> > unconditionally selected.  As a result, the new "PDX (Page inDeX)
> > compression" item will be unconditionally visible in Kconfig.
> 
> Just to mention it: Afaict there is a functional change, but one I actually
> appreciate, at least in part. So far ...
> 
> > --- a/xen/common/Kconfig
> > +++ b/xen/common/Kconfig
> > @@ -52,9 +52,10 @@ config EVTCHN_FIFO
> >  
> >  	  If unsure, say Y.
> >  
> > -config PDX_COMPRESSION
> > -	bool "PDX (Page inDeX) compression" if EXPERT && !X86 && !RISCV
> > -	default ARM || PPC
> 
> ... for x86 (and RISC-V) this option couldn't be selected. Whereas ...
> 
> > @@ -67,6 +68,17 @@ config PDX_COMPRESSION
> >  	  If your platform does not have sparse RAM banks, do not enable PDX
> >  	  compression.
> >  
> > +config PDX_MASK_COMPRESSION
> > +	bool "Mask compression"
> > +	help
> > +	  Compression relying on all RAM addresses sharing a zeroed bit region.
> 
> ... this option is now available, as the prior !X86 && !RISCV doesn't
> re-appear here. (As the description mentions it, that dependency clearly
> can't appear on the enclosing choice itself.) Since x86 actually still
> should have mask compression implemented properly, that's fine (from my
> pov; iirc I even asked that it would have remained available when the
> earlier change was done), whereas I think for RISC-V it's not quite right
> to offer the option. It also did escape me why the option was made
> available for PPC, which I'm pretty sure also lacks the logic to determine
> a suitable mask.

Yes, the only architectures that have functional PDX compression are
x86 and ARM, as neither RISC-V nor PowerPC call the initialization
functions.  AFAICT this is harmless apart from giving the wrong
impression to the user that PDX compression might be implemented.

Would you prefer for me to introduce a new HAS_PDX config option
that's selected by x86 and ARM, and is used to enable the choice PDX
config?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 08:03:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 08:03:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1025993.1401248 (Exim 4.92)
	(envelope-from )
	id 1uUhZx-0007VA-Ix; Thu, 26 Jun 2025 08:03:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1025993.1401248; Thu, 26 Jun 2025 08:03: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 1uUhZx-0007V3-F6; Thu, 26 Jun 2025 08:03:29 +0000
Received: by outflank-mailman (input) for mailman id 1025993;
 Thu, 26 Jun 2025 08:03: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 1uUhZw-0007Ux-Bw
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 08:03:28 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20616.outbound.protection.outlook.com
 [2a01:111:f403:2412::616])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 05b8fff9-5264-11f0-b894-0df219b8e170;
 Thu, 26 Jun 2025 10:03:22 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by SA1PR12MB6993.namprd12.prod.outlook.com (2603:10b6:806:24c::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.29; Thu, 26 Jun
 2025 08:03:16 +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.8835.027; Thu, 26 Jun 2025
 08:03: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: 05b8fff9-5264-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=fufd88mbvN8rR1b8EwEfQI1euLtRYkSxvm2V501gJnMSaCGQ6lvMx6kpsvtxkvwn+bjNaDbysX1EY9ljinN0xDum5bkB19yqLx4bGV2iFVoLYDSDsj7CEnivThCwOgOf3hQFdrDKkXhnm8GgbzDhhFcg8z7pUi7YPW0nBcC/b2hIAZ3zu0DN6XmUuBSbBNbeb6aOngDlPUPaP0C5oq+4PGRnm6LOqnt4UWYtb2wczDv2816CDfKF85Yctw1TsYmiEHuGScVb3CX4DRQJsyRFeDzkLb6WYEU3KYHpvmKDNNVDKIRxSH0mVhLlYzFtH8yvDsnOEf4879X0bsZiD9joOQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=yUUBeDXFvjCJhw2C1JuM6OwIToeQin86XXHa2v986Rw=;
 b=E8kp8h/87tKllxwjH0FuXccMLCVEazKKkzt3oleQD58E5zzApLVTudRBwoy89SWLWCsMyqaGA5/PhyudqxUYrmDmveg6K9dvcaYfJzPylpcP19pMgvYJHvn/c88mEiW0hgW0U8tNKEBujCEj5Ve+h/qRp/SLGeoL2Irq9tz4DJyYeNyu5b1dv4LCYbHVPY2j+Dzn33AeuriP1bZSW7Kp4BmVwz+7hb7cw092U4SjVQEOB9OiSHVCDap/ZpWMM4+12/s1/EazSFfv6Avf9GcQnTGz9c0+4duZACXyLT1lrY1RAv4OGNIC0+7L386ohcv7umhKF0XNyo1yDRCKBQlieg==
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=yUUBeDXFvjCJhw2C1JuM6OwIToeQin86XXHa2v986Rw=;
 b=1lJeXiBbl+Wlx5NNcoyoFofBshh3JVJSm836ObS4hwMYIVvPeaZSxO84HokbuoeZL0kCtHB4lH6+76yqHJ0q+Fzbr6vf4coBcNm03HYioQ7kTt0bSfcv/Fl79FSfUjLzpUz3SU9DYyljQO008gaELz1i1JE7hlEMFnlx90Jzjw0=
From: "Chen, Jiqian" 
To: Jan Beulich 
CC: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Andrew Cooper
	, Anthony PERARD ,
	"Orzel, Michal" , Julien Grall ,
	Stefano Stabellini , "xen-devel@lists.xenproject.org"
	, "Huang, Ray" , "Chen,
 Jiqian" 
Subject: Re: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
Thread-Topic: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
Thread-Index:
 AQHb23yakGdVC9XxvEWnYcnp8zrTt7QI/QAAgAGa9QCAAQzVgIAG5D6A//99hgCAAJwoAP//hioAgAHew4D//5oCgAASTfCA//+FrwCAAIi+gP//u5+AgAGwYIA=
Date: Thu, 26 Jun 2025 08:03:15 +0000
Message-ID:
 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-3-Jiqian.Chen@amd.com>
 <516a3adc-320d-46ce-b235-8ef91469abcf@suse.com>
 
 <227df6d3-a2c3-4576-bde9-d8057c378e7a@suse.com>
 
 <5c4b186e-686e-4fc8-bcf1-854bc1f5ec8b@suse.com>
 
 <9d5d0e44-66c3-4e3f-8704-2c862c5f5aff@suse.com>
 
 <3638e73c-2a83-4164-9a84-839245245727@suse.com>
 
 <771cd5b7-2b89-49b1-9aba-8cd79319d3ce@suse.com>
 
 <7753470a-efef-478a-bbe5-ae48d008cfdb@suse.com>
In-Reply-To: <7753470a-efef-478a-bbe5-ae48d008cfdb@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.8835.025)
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_|SA1PR12MB6993:EE_
x-ms-office365-filtering-correlation-id: f7582701-d58c-48b6-4d11-08ddb487e7dd
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?c21iV3V2a0xJL3V0Wkt0am5MTVZSaUdGSUNwR0dFWU42b2w4ZmdZL0RTN3U1?=
 =?utf-8?B?bmZYVDZvS3kzWm9UeGozQjRUbkZCOWkwSkhYRTFrL3Jlamp0QkRhV0phVVN5?=
 =?utf-8?B?bFpqVHVUaG13MldxL2w4YjVhYVVWSGtVOGxJYy9sc041b0tWTGd5eFVXRzZC?=
 =?utf-8?B?S0I0R2FtNWM2MDFOMXd4a0o4ZjBtd0xvWmk1aHZHZkUybUJCYUtTWHlwL1ZY?=
 =?utf-8?B?TUFnS3RrN3ZLazZ5QjdPNmJuSmNwL0IrYVRTT3dKemZnUnYyYkJyRDJ0S1JM?=
 =?utf-8?B?c0pCZElFclNyd24yZzRkZzFXSzJ5ZjRSeFFRUjF4VVpJQnBKYkVFMHZuYStl?=
 =?utf-8?B?TDA3a3ZVVVUrYUVsZzI0OVRBRlQzWXY1bjRTSFpGR05PYnh5UzBDRGppTFRS?=
 =?utf-8?B?ZFkzZnZxaldQa3g1TW0zbzZOU3orbGVzemlYMTdvNHE3eGRBdHZZYjRoNWJH?=
 =?utf-8?B?RHE2cGw2ZEt2dzF6Z0JLbVZ6eEJZRmUwUVRUWGpyRDF1N3BGNFFJWkI5cWxP?=
 =?utf-8?B?QllUMUNFWWZPeUNZT21kUHBDcHY5djI1Tzd5a3BzVFFWYi9BMjAzTlcySEVp?=
 =?utf-8?B?b1l5V0xOR05OVWVxc3NrU2tOeXRTcm1aNGFtZjZlUFd4eDRoN2lIQ2xQaXhH?=
 =?utf-8?B?bHlQUkdEZXJlYzdjNEZPSEF2WHpTUjBHV1doWFVhZlVkbkQzTERRYzVqRkpU?=
 =?utf-8?B?ZnpOZlF1cGFDQUVvQ0xXTnQyakUzakdDTTU3SysxcFJ2eTVmTFdwbysreUgv?=
 =?utf-8?B?N0lYTzVyQWhGSWhUOHlPNzFZek1xdUJ4K25lWDdkbHlYU0tBWE10U2dFRjNj?=
 =?utf-8?B?V1NNY2g5RTZnMnd1b0JVMXhSREhYVy85UHNrQmc1V281cGlQb3NvUVREOXZh?=
 =?utf-8?B?MytxaXpoMURlMlBTbEY5V2tCc1hNb1A3RmUvM1pGZXdqMXZHQnRUckkrTTln?=
 =?utf-8?B?anorUklDeG9Gc203cW9nSWZqaFlBWG5abDIxbkZEblVkdXEvcW4yVlgrcWo0?=
 =?utf-8?B?c0xHQ3ppTmlQdUZPME43d2xjeTFqVDVQUWFFeWZSLytuTXVjWmZqNjhYcC9M?=
 =?utf-8?B?K0QxQ2dmTDZpMVV5dVE3a3ROU1Rvd0NlMkRPTlFTVXQ3QmVHQTZXT1Jxbksz?=
 =?utf-8?B?bVR6Q0txNmhXYjJiYmY4UHhiWU9vV2wxVXlYMVVlTG9hYWUySHJwbzVFUFhD?=
 =?utf-8?B?V29ReHQ3U2VoUVVxbEVwdEVFSFd5QmROVHhYRnFiZU5jWE8xUUt2blJqWm9t?=
 =?utf-8?B?ZUNMZ1o0dGVROFFVSjJmc05xNGo5eG1ORTVYMW5aeUFqZ2ErWDZmQ3l3OVlk?=
 =?utf-8?B?RFJnbDVzZitRYnlFcThsRVVhdHNXeWhhTFZ0VWw0Z1dmM1RpTTBOcVZmUjNj?=
 =?utf-8?B?WkNvNGIwY21nRFpzWHEvc0QrNkpwRkU3Z2M0dWw4S0phUlRkcnJVMGpTMEwx?=
 =?utf-8?B?NWJCNm9icU1PeVA2WkhteEcxMWZwMnpTTWJDVVJCOC9CNVhqOFlNY1d2QVlV?=
 =?utf-8?B?MkN4YWp6YVZMNGJ0Z2JuNFZDWXFJT3Z1WUhxUHhhQ3llQ2FiNzZ0RmxWSzF6?=
 =?utf-8?B?eUN0MC9qUUJFbmlLUWFFZEVRcE5OWmJqQ2JXR3ZGVExsUUJPdll0aTdqM0xL?=
 =?utf-8?B?TFZ1QnRTRDZFVzdSQ3FyMVR4VEpLVS83aTBFMGNJa1gwY2VDbHFSMkFmTjVJ?=
 =?utf-8?B?THUyUnI4T0hQQWkwQmlseVJwblpiNGd6REVUazZmNndaVnJPa2lqeG10dkU0?=
 =?utf-8?B?bmNYUUI3MWdET2ZNazZ3aVpONFJwaDBwRXN3UHJGbDdFK0dFa3llcGEwcDQv?=
 =?utf-8?B?S2RmM2ZrbTRnU1hXL2sxYjA2RUpzTkhNejAzTEV4a2h6eDIvb1lJSUZOVkFN?=
 =?utf-8?B?b1FSWDVMclRaQ0ZuemNzTWZyK0tzbWsrVEF5R0JBRkFYanZwQy9Wa2I4M1Ft?=
 =?utf-8?B?WFJhM1RJTTErS1NmMDhWZ2tCaW80N2ZMNE9KWUtSbGtETlllQ3NtTkM1WkdW?=
 =?utf-8?B?Z280akhHQXFBPT0=?=
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?MlJQVjdCeGtmMHFKdWJKN04rVHBOSC92bkhiZUZTN2E1QVFmWFB1T24ybnQ4?=
 =?utf-8?B?UUNuSFlieGkvWHFUd0dmRjRjd1pHZWU1b1pnYU9uR1lkSjFiTFJadkwrVEJ0?=
 =?utf-8?B?dDIyQmxFalNVQjBrZW1Wcy9QdzM3NkxSdmJTUmVpOGpCcW9RT2d3U1k3UGM1?=
 =?utf-8?B?bzhIMEpxK0ExaTdCNnpTS1Y5L0hZZHhIMDJqczJTbG9pUlVVV0NZZ1FQM2JG?=
 =?utf-8?B?MUJqKy9ra09pOGRyVFhqVXNsRW1SbmZ1OTQrTURJa0k3WCtCcDArT3hYamRS?=
 =?utf-8?B?c1MyK1FldHYwclpZbUljU3lYWjQ1YUxRRE5Fd29IcXZaWklYTGVOM1ZyVStl?=
 =?utf-8?B?MlVxV0x5WjNlbnovYlRDcS8rbm02RmwxV0RhNGlISFpKdDJ3elRwSllrcDht?=
 =?utf-8?B?OGdvUExadVNETUdud3JjYzZEZTgrV0c2SUp2U3pHcFZLWW43aXdhSkRnOERh?=
 =?utf-8?B?SytsZ3VpZjNEZzdpcU9DOUN1Y1lub2VsamJsQjFxUEF5SEVjR0FtbmdYc3Vu?=
 =?utf-8?B?SStZNzE1ZGRTeWpJWmdEaXdXTWRhclR4K1N5UDlLUW1WeDRnYkd6by9QTVBJ?=
 =?utf-8?B?SzhCcVBZTVEzVlk2WFBXdEdUeEZQbTh6eXpQWG5vREg5QnVlMmVmcWczRnJ1?=
 =?utf-8?B?R1FkV2pFU2M0Ky9WV3lrODRjay95SlY4L1RjSGlZZXRBOGFKNVlINGhmc1RF?=
 =?utf-8?B?Y29vWnk4YUNXZkxYSjhUdThRR2lYR3R4bHF6NmsvUGtMbjYwWTVzQmR3T0th?=
 =?utf-8?B?QVBLVVorVFhOaE8rRFF1a2M4bVVXNXhpcTZTSVE3VXhrd0ZaZ0MwanhPZkJ6?=
 =?utf-8?B?YkdvaWtJaExjcURDc1RYVHMxTXA5ZkZPbnc2Um1ER3hzMDdZRnM3bVp4ZEFN?=
 =?utf-8?B?ZWdWSUR4amFLZWdqWU5lbkw4ZEJzWTRNSWNpVTYwMWlJMUpTTDJoelNWckJu?=
 =?utf-8?B?eUROTjNmaVpDUGM4Q1dadmRjS3kvL0QrMG5WSDQwZDVmMVBBWFRsVTJVZllH?=
 =?utf-8?B?c2dzenYxUDE0K1NFaXJ2b3dSM2dlOFExOFUrUGwxSzZQdXBsMjNHYnprNk5s?=
 =?utf-8?B?aERYYXZLZ1ZZdUNheitoaFZxM0RtZG83aXg0dmYxUGVHS29jWjNqNTgweXVK?=
 =?utf-8?B?SHQveVhpUEoySGxKRzhDUmNnM0xuOWdqSDBJV1Y4NlZSVEs0THJmSTRpZUNi?=
 =?utf-8?B?TU1sYmdualFZRHVQQW5pTU45VXlCZTY5ZDZ4SHFaTHpGZjJxMHRjc1RFSzdp?=
 =?utf-8?B?VEdqS1RUTXpHRzRTczc1YzIrSmpwdkRxZ01yQmxEWFRPendrZ3o2WmRIVEdR?=
 =?utf-8?B?TDFQQ3liSm03ODIyZ2RDbSszY09QVjFaMWZBaThORWVOZDhBVHBleGl0QU5s?=
 =?utf-8?B?TXRlbUxNRTlWSHdqTm1JYkdlRmlxczVQZHJTZnBicWdFTkpqWjh4T1RhTkNX?=
 =?utf-8?B?bDZYTjc2UDJsaUhreThQc24xVmhsRnQ2bVZPeTlHeTh6eXF6ZlZMaXRMaDc2?=
 =?utf-8?B?a2dqZFZPUCtyZXp0ZEdJRkxYcWlvOXZUYlRmejNhZUdlR3pjUGE0Y0cvbXR2?=
 =?utf-8?B?WFZsWWVtemc0KzBKRTJsUXJTL2tKeEJzdXFKU2lOVXdPUnFJZkpKbDJMZ0E3?=
 =?utf-8?B?bVRBQUxYa0ZJK1NuSHdNSDRJZjVudFhPUE92NkZ1YjJVQ3VjUkJoeGJDVWVL?=
 =?utf-8?B?MksrRHFabWRub2NGcGpTUlhEcHVWV1ZXYWtTVk9MZ2tnQTQrV1MzVy84MHZj?=
 =?utf-8?B?QzVWYnpFRUpGdU5zQWkzdHREL1daeklYaDhIZTc5S2dsMEZKdUtqeHZUSHA0?=
 =?utf-8?B?UE1CWHlnVGg4MXVHTHdZajNLeU5sSWUrR1BRNE9sTGxTVDFXRzQveDRLY3lx?=
 =?utf-8?B?RUJpWHFKSUhialVMQmY5Nks1a0h3dHI1QmF3Zno5WE4yTGtVNjVGVkdEcitu?=
 =?utf-8?B?VXppNXN2OXN6UWJuVEg4aXlNajM1R1h5ellzYyswdVRmdWVJREtMbm05b2RT?=
 =?utf-8?B?UlM3dGs5S3kzRk1ldDNub01Kb09hMUx0b2NaRDUrMHZ6cG4wLzNpTW9GZlhB?=
 =?utf-8?B?K1pheUdlbDJCZDMvRjhJUVdXUDJOMVdyVkhzSW9QeHZVcDZML2lWUnZNWkto?=
 =?utf-8?Q?Jl30=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <4309F9D59A4D6A4ABC87986D07FADB31@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: f7582701-d58c-48b6-4d11-08ddb487e7dd
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2025 08:03:15.9630
 (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: uT0FqQjp9j4YHgog9BCMKlle85gwZkmXSTG4hoBL+1Zkg+tijZCzu/9vITpUXN//pDvKjKmJOHne46hxzSS6Ww==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB6993

T24gMjAyNS82LzI1IDIyOjA3LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMjUuMDYuMjAyNSAx
MjoxNiwgQ2hlbiwgSmlxaWFuIHdyb3RlOg0KPj4gT24gMjAyNS82LzI1IDE4OjAzLCBKYW4gQmV1
bGljaCB3cm90ZToNCj4+PiBBbHNvLCBhcyBzYWlkIC0geW91IHdpbGwgbmVlZCB0byBjaGVjayB3
aGV0aGVyIG90aGVyIGFyY2hpdGVjdHVyZXMgYXJlDQo+Pj4gZGlmZmVyZW50IGZyb20geDg2LTY0
IGluIHRoaXMgcmVnYXJkLiBXZSBiZXR0ZXIgd291bGRuJ3QgbGVhdmUgYSB0cmFwIGhlcmUsDQo+
Pj4gZm9yIHRoZW0gdG8gZmFsbCBpbnRvIHdoZW4gdGhleSBlbmFibGUgdlBDSSBzdXBwb3J0LiBJ
LmUuIG15IHJlY29tbWVuZGF0aW9uDQo+Pj4gd291bGQgYmUgdGhhdCBpZiBpbiBkb3VidCwgd2Ug
cHV0IHRoZSBfX2FsaWduZWQoKSB0aGVyZSB1bmNvbmRpdGlvbmFsbHkuDQo+PiBUaGF0J3MgZGlm
ZmljdWx0IGZvciBtZSB0byBjaGVjayBvbiBhbGwgZGlmZmVyZW50IHBsYXRmb3JtcyBzaW5jZSBJ
IGRvbid0IGhhdmUgdGhlbSBhbGwuDQo+IA0KPiBZb3UgZG9uJ3QgbmVlZCB0byBoYXZlIHRoZW0u
IFlvdSdkIG5lZWQgdG8gY2FyZWZ1bGx5IGdvIHRocm91Z2ggdGhlIHJlc3BlY3RpdmUNCj4gc2Vj
dGlvbihzKSBvZiB0aGVpciBwc0FCSS1zLg0KPiANCj4+IFNvIHlvdSBtZWFuIEkgc2hvdWxkIHJl
bW92ZSAiI2lmZGVmIENPTkZJR19YODYiPyBKdXN0IGxldCBfX2FsaWduZWQoMTYpIGZvciBhbGwg
cGxhdGZvcm1zPw0KPiANCj4gWWVzLiBBbmQsIGFzIGFsc28gc2FpZCwgd2l0aCBhIHN1aXRhYmxl
IGNvbW1lbnQgcGxlYXNlLg0KQWgsIG15IGNvbW1lbnQgZGVmaW5pdGVseSBuZWVkcyB5b3VyIGNo
YW5nZSBzdWdnZXN0aW9uLg0KSSB3cm90ZSBhIGRyYWZ0IGFzIGJlbG93Og0KDQovKg0KICogU2l6
ZSBvZiB2cGNpX2NhcGFiaWxpdHkgaXMgbGFnZXIgdGhhbiA4IGJ5dGVzLiBXaGVuIGl0IGlzIHVz
ZWQgYXMgdGhlIGVudHJ5DQogKiBvZiBfX3N0YXJ0X3ZwY2lfYXJyYXkgaW4gc2VjdGlvbiwgaXQg
aXMgMTYtYnl0ZSBhbGlnbmVkIGJ5IGFzc2VtYmxlciwgdGhhdA0KICogY2F1c2VzIHRoZSBhcnJh
eSBsZW5ndGggKF9fZW5kX3ZwY2lfYXJyYXkgLSBfX3N0YXJ0X3ZwY2lfYXJyYXkpIHdyb25nLCBz
bw0KICogZm9yY2UgaXRzIGRlZmluaXRpb24gdG8gdXNlIDE2LWJ5dGUgYWxpZ25lZCBoZXJlLg0K
ICovDQpzdHJ1Y3QgdnBjaV9jYXBhYmlsaXR5IHsNCiAgICB1bnNpZ25lZCBpbnQgaWQ7DQogICAg
Ym9vbCBpc19leHQ7DQogICAgaW50ICgqIGluaXQpKGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZGV2
KTsNCiAgICBpbnQgKCogY2xlYW51cCkoY29uc3Qgc3RydWN0IHBjaV9kZXYgKnBkZXYpOw0KfSBf
X2F0dHJpYnV0ZV9fKChhbGlnbmVkKDE2KSkpOw0KDQo+IA0KPiBKYW4NCg0KLS0gDQpCZXN0IHJl
Z2FyZHMsDQpKaXFpYW4gQ2hlbi4NCg==


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 08:13:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 08:13:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026004.1401258 (Exim 4.92)
	(envelope-from )
	id 1uUhjM-0000oh-HJ; Thu, 26 Jun 2025 08:13:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026004.1401258; Thu, 26 Jun 2025 08: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 1uUhjM-0000oa-E2; Thu, 26 Jun 2025 08:13:12 +0000
Received: by outflank-mailman (input) for mailman id 1026004;
 Thu, 26 Jun 2025 08: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 1uUhjL-0000oU-63
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 08:13:11 +0000
Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com
 [2607:f8b0:4864:20::22c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 62c5eefa-5265-11f0-b894-0df219b8e170;
 Thu, 26 Jun 2025 10:13:05 +0200 (CEST)
Received: by mail-oi1-x22c.google.com with SMTP id
 5614622812f47-40b1c099511so482530b6e.0
 for ; Thu, 26 Jun 2025 01:13:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 62c5eefa-5265-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750925584; x=1751530384; 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=g9ZticWj5kAENHq8+uBatymybMIvM2nhg2Pt9//5kNE=;
        b=fyQC3dguEVWOvd526voLmGLNOkxsZR6orgU1kOQEOxJBwAcsdqfzMAuIENmMFUR+tP
         Fmk/jm8gxxlbQo6IResOq9bAz1aTh3pVzq/N0coiKY5KntQscdKsnGPQZ3pZ+Y0zj5iV
         Zc2GDC085eIqfeTj3gYTYqNbK6irQNUg2CFvw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750925584; x=1751530384;
        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=g9ZticWj5kAENHq8+uBatymybMIvM2nhg2Pt9//5kNE=;
        b=wXoW+EDJJVL7p0MHsKM8L6s9E6hI1C9h186bheRQqY6GdXtmG9NayiLUVzL86ceDGd
         nNASLJnBViTAbXRkXj5sgZOB2FxB0jvnI3zYZGwOrQ+4/TQVT3SP/GDxtzJS//3CcskN
         LqSxtdC3MzBR3rmogUDFiTiH8JWDv0q+ckEr9l9k+ER1WyY9xyGsEiBjQoGwuPHc82kr
         3/RuvikJWPGs2CdRg1M0EJOpTV7h9lwMrgCsYsmlWUaMGpxUV5cBmhTB7L9vmXOBjrt8
         Qd5RYmb6v0t95R1IMVzNGVZGxkrofgqH8w6r0iUUvpK09c3mStvdg/UCQqHhVUwefiN+
         mVcQ==
X-Gm-Message-State: AOJu0YyY76yg8w2JixPeGiVAmPUGYAUGg0msXk2V7IpzyWaLjDVa8fUa
	AgUuVhsfqJmN2GaAWBPWgZsvdT79fGFY47Z0BlA+O69S6MQkUHSrodWppfTBO5dDaqaqRmNE5L8
	nFIjA719GXUKxzz6u5qH55OeygP20YT2eh9y1FpLATEXDciNRBcdM02cP9Q==
X-Gm-Gg: ASbGncuQwq6vhU1A44g5miS5/XhpMW8Wdo7KUZ5Hmg/GhCyhDJIKpFxQPruSGvs6YT9
	9vnjhC1Ji8WVwnZB4zhQbRmarudcLcBlgoUGLOlNU476+u3gniMo03Bk9coPTSW2+mSfeE8Mryl
	C4SlSHMFMssoHouSTKTPOvDOHw0KCHgpIWVa/kqfYR36wvkXYlzNQ=
X-Google-Smtp-Source: AGHT+IFM8deR5ZSoma45hIBqa3JSfBKh9vQj7/leXkmKK0p9GKN/ib4GzVYcV6p3eEP8yVQ9HgLcj7PwPq4SYsOi0eQ=
X-Received: by 2002:a05:6808:1207:b0:3f6:7091:d297 with SMTP id
 5614622812f47-40b1cd0dffamr1985623b6e.18.1750925584325; Thu, 26 Jun 2025
 01:13:04 -0700 (PDT)
MIME-Version: 1.0
References: <20250624083157.9334-1-frediano.ziglio@cloud.com>
  
In-Reply-To: 
From: Frediano Ziglio 
Date: Thu, 26 Jun 2025 09:12:53 +0100
X-Gm-Features: Ac12FXw5LQPN7oWVRjKAXJTeZptYPZ9q3R-3BEQyJd9s371og-g9kmSRI14xO2c
Message-ID: 
Subject: Re: [PATCH 0/2] xen/efi: Make boot more flexible, especially with GRUB2
To: =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= 
Cc: xen-devel@lists.xenproject.org, 
	"Daniel P. Smith" , Jan Beulich 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 25, 2025 at 9:26=E2=80=AFPM Marek Marczykowski-G=C3=B3recki
 wrote:
>
> On Tue, Jun 24, 2025 at 09:38:42AM +0100, Frediano Ziglio wrote:
> > On Tue, Jun 24, 2025 at 9:32=E2=80=AFAM Frediano Ziglio
> >  wrote:
> > >
> > > The combination of GRUB2, EFI and UKI allows potentially more flexibi=
lity.
> > > For instance is possible to load xen.efi from a no ESP partition leav=
ing
> > > a boot loader like GRUB2 taking care of the file loading.
> > > This however requires some changes in Xen to be less restrictive.
> > > Specifically for GRUB2 these changes allows the usage of "chainloader=
"
> > > command with UKI and reading xen.efi from no ESP (so no DeviceHandle
> > > set) and usage of "linux" and "initrd" commands to load separately
> > > the kernel (embedding using UKI) and initrd (using LoadFile2 protocol=
).
> >
> > I was forgetting. If somebody wants to test "linux" and "initrd"
> > command with these changes be aware that GRUB currently has a problem
> > passing arguments, I posted a patch, see
> > https://lists.gnu.org/archive/html/grub-devel/2025-06/msg00156.html.
> > I also have a workaround for this issue in xen but it would be better
> > to have a fix in GRUB.
>
> Can you tell more how to test this, especially the second variant? When
> trying to use GRUB linux or linuxefi commands on xen.efi, I get "invalid
> magic number" error.
>

That's weird.

Be the way. As usual I have a super complicated script that does everything=
.

But to simplify:
- I compile xen (plain upstream plus my patches) with "make -C
~/work/xen/xen -j O=3Dnormal MAP"
- output xen.efi in "~/work/xen/xen/normal/xen.efi"
- add configuration and kernel with "./add_sections xen.efi
xen.unified.efi .config xen.cfg .kernel vmlinuz-xen"
- boot using patched Grub (or patched Xen, to handle command line, if
you don't care about command line you can use a stock one), the menu
entry is

menuentry 'XenServer (Serial)' {
        search --label --set root EFI-BOOT
        linux /boot/xen.unified.efi -- com1=3D115200,8n1
console=3Dcom1,vga dom0_mem=3D1232M,max:1232M watchdog dom0_max_vcpus=3D1-4
crashkernel=3D256M,below=3D4G -- root=3DLABEL=3Droot-qjhppe ro nolvm
hpet=3Ddisable console=3Dtty0 console=3Dhvc0
        initrd /boot/initrd.img
}

xen.cfg file:
----------
[global]
default=3Dxen

[xen]
----------

add_sections file:
----------
#!/usr/bin/env perl
use strict;

die if $#ARGV < 1;
my $in =3D shift @ARGV;
my $out =3D shift @ARGV;

my $max =3D 0;
open(IN, "objdump -h $in |") or die;
while () {
        next if !/^\s*\d+\s+\S+\s+([0-9a-f]+)\s+([0-9a-f]+)\s+/;
        my $val =3D hex($1) + hex($2);
        $max =3D $val if $val > $max;
}
close(IN);

sub up($) {
        my $n =3D shift;
        return ($n + 4095) & -4096;
}

my @args =3D ('objcopy');

my $start =3D up($max);
while ($#ARGV >=3D 1) {
        my $name =3D shift;
        my $fn =3D shift;
        push @args, '--add-section', "$name=3D$fn";
        push @args, '--change-section-vma', sprintf("%s=3D%#x", $name, $sta=
rt);
        $start +=3D -s $fn;
        $start =3D up($start);
}
push @args, $in, $out;
print "Executing @args\n";
system(@args) =3D=3D 0 || die "Error!";
----------

My script creates the initrd, builds a full disk for Qemu and launches
Qemu too with specific options.

Frediano


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 08:13:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 08:13:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026009.1401267 (Exim 4.92)
	(envelope-from )
	id 1uUhjs-0001H0-Ox; Thu, 26 Jun 2025 08:13:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026009.1401267; Thu, 26 Jun 2025 08:13: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 1uUhjs-0001Gt-MT; Thu, 26 Jun 2025 08:13:44 +0000
Received: by outflank-mailman (input) for mailman id 1026009;
 Thu, 26 Jun 2025 08:13: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 1uUhjr-00015u-Em
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 08:13:43 +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 7942863a-5265-11f0-a30f-13f23c93f187;
 Thu, 26 Jun 2025 10:13:42 +0200 (CEST)
Received: by mail-lj1-x232.google.com with SMTP id
 38308e7fff4ca-32b910593edso6083551fa.1
 for ; Thu, 26 Jun 2025 01:13:42 -0700 (PDT)
Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-553e414c2aasm2474283e87.55.2025.06.26.01.13.40
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 26 Jun 2025 01:13:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7942863a-5265-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750925622; x=1751530422; 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=M9gQgFlI8smtr41SXezhqALTk3eHL+YQaCdxEISeBOk=;
        b=BHZxmpNjU5mol0PCY9lYuSRZ9pbNSrC62m9p3XZqHp5ktrYCjNJkR2T37KtG9X7ahk
         KbIv+HTmPcOjCmqXQk5NPPNVZ8q/Iyj0Dv1P2JBHaSzieeAMGJCkvVM+NRwirbkAeNR7
         8aSTY7K8hd8cWyfKemZ1YFJzCQLuqB07oDIg/U8HW8OSEnWQfCJJCtNmTM8DK6D+MQ8w
         iKpCH4tHaPMhNJl4sjNuwulNVZD4Rd8sB3Eyjg74WzQi4HZJXKwQEp0kMG8DxbFla9Pf
         zDpDvpCETjqlFmR9xRVjDPAvvgkQhzpS4arBvRY8L+nowJJAoRAgIiXDOuncxVg7LV9u
         G63A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750925622; x=1751530422;
        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=M9gQgFlI8smtr41SXezhqALTk3eHL+YQaCdxEISeBOk=;
        b=Wc6qUTuT9HGvRwSwO1y/alG6OOBNJFTNhGmmeF0IqFTCjLjKb3UgGClo21q0y0wiax
         cpvTCfwicdycU6dl/dTBTZ+RIqacvgDfacyeCuu9ENVDW35IBUsPGe38LXodSTSrl9AQ
         Dys4MtyeK4Xh2HdY76I2oGOnl5qvvZsvS62/RAoXn1XGJcEGSSZf5U5aic54HzcMQ4Ar
         EKf8rVPwvUw8d1Ujol6MSzp0bmYjVYTtTY5YVOk3TIJ6S9GV7LfqEAeR7RKtoFntvpoX
         fCtwqFJlIaxeo07SuYCMjmFiYvILWoaWsUpo4mAbLdZsV7tjihWoxMWoN8izxCK0aWOG
         +mJQ==
X-Gm-Message-State: AOJu0YzhVcZgIJWR89otkOpqd4tG5dj54s1ywMmID0R4fYYVkq2QvRsp
	Lb/oL4DTwou+tgZX8NYmRSTje4CnOQ4QTZAj9JIfBy/iHfnAQvCluZnx+qbMKCcW
X-Gm-Gg: ASbGncumrlq3nlA6rI3g/G8a+iEa4hQPIR+uE1bfxb2H9UXEeOl6lMnJ4GziflJyM7w
	xyfBPC0dxSu/aQh1q7T5z/aURkvYR1Pj7JaB6BPIeRyx83WRE+Tgh44R3NSPmJt3+0lIEOn/5Jm
	tFd4mz7JP+MjhSHReksaCnKHTM51ukd/OilNLohp/n0qTUXs1Bm+156wJ2+BZQf3WLzNEI2mfOR
	ZEJQka3qKe9AKcV1c0KbPnnDYLjByZPFWQvrZBdH02pyGBO5TpCcSZSfdi85V4jnokhgmpgACmd
	ihI4Qdop0r14dZJp7g2Qjb1BaUq4ViX3+/p8lbYxR8nYmilITk10+ekr0aS/0HKpuzbxeQ4i7Va
	YBkh6TxBSMy0gQ4F9K0ewumH2Bg==
X-Google-Smtp-Source: AGHT+IFZ4LE5QGB7kp29fS4SAvNa6WI+Y6fL0MATHiOu//mK7Kd/3Ls4ZEj5ryhfe9uPhpoPVpIKgg==
X-Received: by 2002:a05:6512:3b0b:b0:553:25e9:7f3c with SMTP id 2adb3069b0e04-554fde595bcmr2099733e87.37.1750925621606;
        Thu, 26 Jun 2025 01:13:41 -0700 (PDT)
From: Mykola Kvach 
To: xen-devel@lists.xenproject.org
Cc: Anthony PERARD ,
	Mykola Kvach 
Subject: [PATCH] systemd: Add hooks to stop/start xen-watchdog on suspend/resume
Date: Thu, 26 Jun 2025 11:12:46 +0300
Message-ID: <20250626081246.1923956-1-xakep.amatop@gmail.com>
X-Mailer: git-send-email 2.48.1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This patch adds a systemd sleep hook script to stop the xen-watchdog
service before system suspend and start it again after resume.

Stopping the watchdog before a system suspend operation may look unsafe.
Let’s imagine the following situation: 'systemctl suspend' does not
interact with the running service at all. In such a case, the Xen
watchdog daemon freezes just before suspend. If this happens, for
example, right before sending a ping, and Xen has not yet marked the
domain as suspended (is_shutting_down), the Xen watchdog timer may
trigger a false alert.

This is an almost impossible situation, because typically:
    ping time = watchdog timeout / 2

and the watchdog timeout is usually set to a relatively large value
(dozens of seconds).

Still, this is more likely with very short watchdog timeouts. It may
happen in the following scenarios:
    * Significant delays occur between freezing Linux tasks and
      triggering the ACPI or PSCI sleep request or handler.
    * Long delays happen inside Xen between the entrance to the sleep
      trigger and the actual forwarding of the sleep request further.

A similar situation may occur on resume with short timeouts. During the
resume operation, Xen restores timers and the domain context. The Xen
watchdog timer also resumes. If it schedules the domain right before the
watchdog timeout expires, and the daemon responsible for pinging is not
yet running, a timeout might occur.

Both scenarios are rare and typically require very small watchdog
timeouts combined with significant delays in Xen or the Linux kernel
during suspend/resume flows.

Conceptually, however, if activating and pinging the Xen watchdog is the
responsibility of the domain and its services, then the domain should
also manage the watchdog service/daemon lifecycle. This is similar to
what is already done by the Xen watchdog driver inside the Linux kernel.

Signed-off-by: Mykola Kvach 
---
 tools/hotplug/Linux/systemd/Makefile          | 12 ++++-
 .../Linux/systemd/xen-watchdog-sleep.sh       | 45 +++++++++++++++++++
 2 files changed, 56 insertions(+), 1 deletion(-)
 create mode 100644 tools/hotplug/Linux/systemd/xen-watchdog-sleep.sh

diff --git a/tools/hotplug/Linux/systemd/Makefile b/tools/hotplug/Linux/systemd/Makefile
index e29889156d..98d325cc5d 100644
--- a/tools/hotplug/Linux/systemd/Makefile
+++ b/tools/hotplug/Linux/systemd/Makefile
@@ -5,6 +5,9 @@ XEN_SYSTEMD_MODULES := xen.conf
 
 XEN_SYSTEMD_MOUNT := proc-xen.mount
 
+XEN_SYSTEMD_SLEEP_SCRIPTS := xen-watchdog-sleep.sh
+XEN_SYSTEMD_SLEEP_DIR := $(XEN_SYSTEMD_DIR)/../system-sleep
+
 XEN_SYSTEMD_SERVICE := xenstored.service
 XEN_SYSTEMD_SERVICE += xenconsoled.service
 XEN_SYSTEMD_SERVICE += xen-qemu-dom0-disk-backend.service
@@ -15,7 +18,8 @@ XEN_SYSTEMD_SERVICE += xendriverdomain.service
 
 ALL_XEN_SYSTEMD :=	$(XEN_SYSTEMD_MODULES)  \
 			$(XEN_SYSTEMD_MOUNT)	\
-			$(XEN_SYSTEMD_SERVICE)
+			$(XEN_SYSTEMD_SERVICE)	\
+			$(XEN_SYSTEMD_SLEEP_SCRIPTS)
 
 .PHONY: all
 all:	$(ALL_XEN_SYSTEMD)
@@ -31,15 +35,21 @@ distclean: clean
 install: $(ALL_XEN_SYSTEMD)
 	$(INSTALL_DIR) $(DESTDIR)$(XEN_SYSTEMD_DIR)
 	$(INSTALL_DIR) $(DESTDIR)$(XEN_SYSTEMD_MODULES_LOAD)
+	$(INSTALL_DIR) $(DESTDIR)$(XEN_SYSTEMD_SLEEP_DIR)
 	$(INSTALL_DATA) *.service $(DESTDIR)$(XEN_SYSTEMD_DIR)
 	$(INSTALL_DATA) *.mount $(DESTDIR)$(XEN_SYSTEMD_DIR)
 	$(INSTALL_DATA) *.conf $(DESTDIR)$(XEN_SYSTEMD_MODULES_LOAD)
+	set -e; for i in $(XEN_SYSTEMD_SLEEP_SCRIPTS); \
+	    do \
+	    $(INSTALL_PROG) $$i $(DESTDIR)$(XEN_SYSTEMD_SLEEP_DIR); \
+	done
 
 .PHONY: uninstall
 uninstall:
 	rm -f $(DESTDIR)$(XEN_SYSTEMD_MODULES_LOAD)/*.conf
 	rm -f $(DESTDIR)$(XEN_SYSTEMD_DIR)/*.mount
 	rm -f $(DESTDIR)$(XEN_SYSTEMD_DIR)/*.service
+	rm -f $(addprefix $(DESTDIR)$(XEN_SYSTEMD_SLEEP_DIR)/, $(XEN_SYSTEMD_SLEEP_SCRIPTS))
 
 $(XEN_SYSTEMD_MODULES):
 	rm -f $@.tmp
diff --git a/tools/hotplug/Linux/systemd/xen-watchdog-sleep.sh b/tools/hotplug/Linux/systemd/xen-watchdog-sleep.sh
new file mode 100644
index 0000000000..2b2f0e16d8
--- /dev/null
+++ b/tools/hotplug/Linux/systemd/xen-watchdog-sleep.sh
@@ -0,0 +1,45 @@
+#!/bin/sh
+
+# The first argument ($1) is:
+#     "pre" or "post"
+# The second argument ($2) is:
+#     "suspend", "hibernate", "hybrid-sleep", or "suspend-then-hibernate"
+
+. /etc/xen/scripts/hotplugpath.sh
+
+SERVICE_NAME="xen-watchdog.service"
+STATE_FILE="/run/xen-watchdog-sleep-marker"
+XEN_WATCHDOG_SLEEP_LOG="${XEN_LOG_DIR}/xen-watchdog-sleep.log"
+
+log_watchdog() {
+    echo "$1"
+    echo "$(date): $1" >> "${XEN_WATCHDOG_SLEEP_LOG}"
+}
+
+# Exit silently if Xen watchdog service is not present
+if ! systemctl show "${SERVICE_NAME}" > /dev/null 2>&1; then
+    exit 0
+fi
+
+case "$1" in
+pre)
+    if systemctl is-active --quiet "${SERVICE_NAME}"; then
+        touch "${STATE_FILE}"
+        log_watchdog "Stopping ${SERVICE_NAME} before $2."
+        systemctl stop "${SERVICE_NAME}"
+    fi
+    ;;
+post)
+    if [ -f "${STATE_FILE}" ]; then
+        log_watchdog "Starting ${SERVICE_NAME} after $2."
+        systemctl start "${SERVICE_NAME}"
+        rm "${STATE_FILE}"
+    fi
+    ;;
+*)
+    log_watchdog "Script called with unknown action '$1'. Arguments: '$@'"
+    exit 1
+    ;;
+esac
+
+exit 0
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Thu Jun 26 08:40:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 08:40:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026031.1401314 (Exim 4.92)
	(envelope-from )
	id 1uUi9Q-0005gY-4Q; Thu, 26 Jun 2025 08:40:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026031.1401314; Thu, 26 Jun 2025 08:40:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUi9P-0005gE-WF; Thu, 26 Jun 2025 08:40:08 +0000
Received: by outflank-mailman (input) for mailman id 1026031;
 Thu, 26 Jun 2025 08:40:07 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uUi9O-0005aO-Rm
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 08:40:06 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 28945707-5269-11f0-a30f-13f23c93f187;
 Thu, 26 Jun 2025 10:40:05 +0200 (CEST)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-ae0d11bb2a7so98306266b.3
 for ; Thu, 26 Jun 2025 01:40:05 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ae0a4da13fcsm475770766b.20.2025.06.26.01.40.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 26 Jun 2025 01:40:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 28945707-5269-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750927205; x=1751532005; 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=BbVpDqo2TcDM1/esE61LVN5Y0nn2ueDRgX1i6NDRF4w=;
        b=aMRRjZUJE/9YDjMb2clZ59K2tRSs2fBIIfIFa8xf34otLbfJAnNFeb9XKmuApy/FnC
         YVNxhlnZUD3C7LtZf7j8fkRj6kNTyrSaY6svQfISuJEpb38Bx3apakuGFY695Wmo9evY
         rnaBdvfC45p5KgXvHcUVH2sSLWZNFOzYkmikJWmlbssAlSKZtXm9YzcdZ4iOpFpExYvy
         p82q9x9RhITVCgt8+ynqJfZNBFZlI0QlnGpuxUQWVq4x7kVFAg2vqvoEjheEJN2Ju32i
         FSj+1uzHwJOLboOpAoi34anFCfZ19Ki/YqX5cnjFrOXirHm1F3r9SMuZe4Onz8KUZnwI
         IhOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750927205; x=1751532005;
        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=BbVpDqo2TcDM1/esE61LVN5Y0nn2ueDRgX1i6NDRF4w=;
        b=iHnw5OG7xEOCdvNWJrp+l0QxLef+AMRUQqyLBEzlMB/+4C4rm58wJ54sXTV25w2pco
         4mPbmPnvDfFdvDGqTp2OFd+L2Tvkiq3z+TzJIv7uZXNJ5k61ykzXG256Nh9f9OnTD+At
         PrEdhn0d0G3DuDlA4W5UFVaL9mE5QsM7oP9knsb0CJ+K/9Z8Ph3J9N9FoMLFRjJLShUq
         O6G+wmJmo1nkAGpmhK0re0X7fpdtyNBQWNpNNblmORKeT2sjIorkm3beiBIEiFHRjoRP
         QU0etysCTSbiI0ylueYZX8JxelypLfFuKvmtLMNir5xVdOUjLsoM7GZIW2//BPbegKhV
         oCEA==
X-Forwarded-Encrypted: i=1; AJvYcCVndCf9AVb8ixuMCHzcGrZbkWv/RPJBj1vnu0jaIIFYo9Hsu4xxVAipJwM4sQ0qY6WMElSKN/LMLXw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy/ASAW10GY2v4PkZUAtSQYNdWnYFHcwotFzKl2LzaGolbxdZCW
	Uka04wCgg/In2vrwowpaFmtOckid2fAd434CkEvXs53xHBhLUJlo76dD
X-Gm-Gg: ASbGnctsCyYg1YuKg8Byfo60huZJKgF8gy+v8NzCOCENPcSWyddKHzDpmQnIfljFpIr
	CwwrzAZkcYtRtjJAcoIg+yoKlD4SHPNGtJfnxxksgF4MABQxsHN2HPsyMtFsYmOPFwotpfddism
	JWvPA5xZ69gg/ZVfoJnSvL53QKuHX0FFJTaSflsq//CprGbPKkwtf52I2bfyH3l0Eu4NwWhVJLb
	0rviJ3tzqYkY2EM5HQevjG9rcHus7orcSkFiIFDFWpIjChw1keV5rE6CBs1fdqGomaAIfRU5Ave
	1geoV8yku+kCXKjnB3VJuHcYiGum/yjmXgtO51aYmHAbkWHBf26uQimxfuFlgLdRGVIqpRaXqcd
	zgiAVHk77+DNzqMj5El4OcG372qExGxDLvIo=
X-Google-Smtp-Source: AGHT+IE6skJd82UuucOQtjBxc2kQDLCfxaXWEC/Ua80HHcrYs6Owck6tnVKhuANSJ29EnXEY7RGYVQ==
X-Received: by 2002:a17:907:9690:b0:ae0:de30:8569 with SMTP id a640c23a62f3a-ae0de30874emr51877166b.1.1750927204495;
        Thu, 26 Jun 2025 01:40:04 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------4C0lvgBwVJ7PPdUnn48sBYMC"
Message-ID: <8741800f-b40b-4c42-b435-91e2f9375f6c@gmail.com>
Date: Thu, 26 Jun 2025 10:40:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 05/17] xen/riscv: introduce things necessary for p2m
 initialization
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: 
 <443cb3566a60dcb5d5440c72410ff6d76a010a58.1749555949.git.oleksii.kurochko@gmail.com>
 <5c61fd86-5c0e-481e-a5a9-6a53f2d78c36@suse.com>
 <0b3c403b-0f24-4fc6-ba5b-fb4df62d7057@gmail.com>
 <7cb7a46b-8d2e-4f9e-9613-f7a4199096ee@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <7cb7a46b-8d2e-4f9e-9613-f7a4199096ee@suse.com>

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


On 6/25/25 5:53 PM, Jan Beulich wrote:
> On 25.06.2025 17:31, Oleksii Kurochko wrote:
>> On 6/18/25 6:08 PM, Jan Beulich wrote:
>>> On 10.06.2025 15:05, Oleksii Kurochko wrote:
>>>> @@ -14,6 +18,29 @@
>>>>    
>>>>    /* Per-p2m-table state */
>>>>    struct p2m_domain {
>>>> +    /*
>>>> +     * Lock that protects updates to the p2m.
>>>> +     */
>>>> +    rwlock_t lock;
>>>> +
>>>> +    /* Pages used to construct the p2m */
>>>> +    struct page_list_head pages;
>>>> +
>>>> +    /* Indicate if it is required to clean the cache when writing an entry */
>>>> +    bool clean_pte;
>>>> +
>>>> +    struct radix_tree_root p2m_type;
>>> A field with a p2m_ prefix in a p2m struct?
>> p2m_ prefix could be really dropped.
>>
>>>    And is this tree really about
>>> just a single "type"?
>> Yes, we don't have enough bits in PTE so we need some extra storage to store type.
> My question wasn't about that, though. My question was whether in the name
> "type" (singular) is appropriate. I didn't think you need a tree to store just
> a single type.

I need tree to store a pair of , where gfn is an index. And it seems
to me a tree is a good structure for fast insert/search.

>
>>>> +    /*
>>>> +     * Default P2M access type for each page in the the domain: new pages,
>>>> +     * swapped in pages, cleared pages, and pages that are ambiguously
>>>> +     * retyped get this access type.  See definition of p2m_access_t.
>>>> +     */
>>>> +    p2m_access_t default_access;
>>>> +
>>>> +    /* Back pointer to domain */
>>>> +    struct domain *domain;
>>> This you may want to introduce earlier, to prefer passing around struct
>>> p2m_domain * in / to P2M functions (which would benefit earlier patches
>>> already, I think).
>> But nothing uses it earlier.
> If you do as suggested and pass around struct p2m_domain * for p2m_*()
> functions, you'll quickly find it used, I think.
>
>>>> --- a/xen/arch/riscv/p2m.c
>>>> +++ b/xen/arch/riscv/p2m.c
>>>> @@ -1,13 +1,46 @@
>>>>    #include 
>>>> +#include 
>>>>    #include 
>>>> +#include 
>>>>    #include 
>>>> +#include 
>>>> +#include 
>>>> +#include 
>>>>    #include 
>>>>    #include 
>>>>    #include 
>>>>    
>>>> +#include 
>>>>    #include 
>>>>    #include 
>>>>    
>>>> +/*
>>>> + * Force a synchronous P2M TLB flush.
>>>> + *
>>>> + * Must be called with the p2m lock held.
>>>> + */
>>>> +static void p2m_force_tlb_flush_sync(struct p2m_domain *p2m)
>>>> +{
>>>> +    struct domain *d = p2m->domain;
>>>> +
>>>> +    ASSERT(p2m_is_write_locked(p2m));
>>>> +
>>>> +    sbi_remote_hfence_gvma_vmid(d->dirty_cpumask, 0, 0, p2m->vmid);
>>>> +}
>>>> +
>>>> +/* Unlock the flush and do a P2M TLB flush if necessary */
>>>> +void p2m_write_unlock(struct p2m_domain *p2m)
>>>> +{
>>>> +    /*
>>>> +     * The final flush is done with the P2M write lock taken to avoid
>>>> +     * someone else modifying the P2M wbefore the TLB invalidation has
>>>> +     * completed.
>>>> +     */
>>>> +    p2m_force_tlb_flush_sync(p2m);
>>> The comment ahead of the function says "if necessary". Yet there's no
>>> conditional here. I also question the need for a global flush in all
>>> cases.
>> Stale comment.
>>
>> But if p2m page table was modified that it is needed to do a flush for CPUs
>> in d->dirty_cpumask.
> Right, but is that true for each and every case where you acquire the
> lock in write mode? There may e.g. be early-out path which end up doing
> nothing, yet you would then still flush the TLB.

Initially, I assumed that early-out patch will happen mostly in the cases when
some error happen, so it will be okay to flush the TLB each time.

But, yes, I missed some cases when it will be end up doing nothing. I will return
back need_flush.

>
>>>> @@ -109,8 +142,33 @@ int p2m_init(struct domain *d)
>>>>        spin_lock_init(&d->arch.paging.lock);
>>>>        INIT_PAGE_LIST_HEAD(&d->arch.paging.p2m_freelist);
>>>>    
>>>> +    rwlock_init(&p2m->lock);
>>>> +    INIT_PAGE_LIST_HEAD(&p2m->pages);
>>>> +
>>>>        p2m->vmid = INVALID_VMID;
>>>>    
>>>> +    p2m->default_access = p2m_access_rwx;
>>>> +
>>>> +    radix_tree_init(&p2m->p2m_type);
>>>> +
>>>> +#ifdef CONFIG_HAS_PASSTHROUGH
>>> Do you expect this to be conditionally selected on RISC-V?
>> No, once it will be implemented it will be just selected once by config RISC-V.
>> And it was done so because iommu_has_feature() isn't implemented now as IOMMU
>> isn't supported now and depends on CONFIG_HAS_PASSTHROUGH.
> If the selection isn't going to be conditional, then I see no reason to have
> such conditionals in RISC-V-specific code. The piece of code presently inside
> that #ifdef may simply need adding later, once there's enough infrastructure
> to allow that code to compile. Or maybe it would even compile fine already now?

I haven't tried. Anyway, I get your point.

>
>>>> +    /*
>>>> +     * Some IOMMUs don't support coherent PT walk. When the p2m is
>>>> +     * shared with the CPU, Xen has to make sure that the PT changes have
>>>> +     * reached the memory
>>>> +     */
>>>> +    p2m->clean_pte = is_iommu_enabled(d) &&
>>>> +        !iommu_has_feature(d, IOMMU_FEAT_COHERENT_WALK);
>>> The comment talks about shared page tables, yet you don't check whether
>>> page table sharing is actually enabled for the domain.
>> Do we have such function/macros?
> We have iommu_hap_pt_share, and we have the per-domain hap_pt_share flag.
>
>> It is shared by implementation now.
> I don't understand. There's no IOMMU support yet for RISC-V. Hence it's in
> neither state - not shared, but also not not shared.

In downstream there is a support of IOMMU for RISC-V.

~ Oleksii

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



  
    
  
  
    

    
    
    
    
    On 6/25/25 5:53 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 25.06.2025 17:31, Oleksii Kurochko wrote:

    
      
    
        
    On 6/18/25 6:08 PM, Jan Beulich wrote:

    
        
    
          
    On 10.06.2025 15:05, Oleksii Kurochko wrote:

    
          
    
            
    @@ -14,6 +18,29 @@
  
  /* Per-p2m-table state */
  struct p2m_domain {
+    /*
+     * Lock that protects updates to the p2m.
+     */
+    rwlock_t lock;
+
+    /* Pages used to construct the p2m */
+    struct page_list_head pages;
+
+    /* Indicate if it is required to clean the cache when writing an entry */
+    bool clean_pte;
+
+    struct radix_tree_root p2m_type;

    
          
    
          
    A field with a p2m_ prefix in a p2m struct?

    
        
    
        
    p2m_ prefix could be really dropped.


    
        
    
          
      And is this tree really about
just a single "type"?

    
        
    
        
    Yes, we don't have enough bits in PTE so we need some extra storage to store type.

    
      
    
      
    My question wasn't about that, though. My question was whether in the name
"type" (singular) is appropriate. I didn't think you need a tree to store just
a single type.
    
    
    
    
    I need tree to store a pair of <gfn, p2m_type>, where gfn is an index. And it seems
to me a tree is a good structure for fast insert/search.


    
    
    
      
    

    
      
    
        
    
          
    
            
    +    /*
+     * Default P2M access type for each page in the the domain: new pages,
+     * swapped in pages, cleared pages, and pages that are ambiguously
+     * retyped get this access type.  See definition of p2m_access_t.
+     */
+    p2m_access_t default_access;
+
+    /* Back pointer to domain */
+    struct domain *domain;

    
          
    
          
    This you may want to introduce earlier, to prefer passing around struct
p2m_domain * in / to P2M functions (which would benefit earlier patches
already, I think).

    
        
    
        
    But nothing uses it earlier.

    
      
    
      
    If you do as suggested and pass around struct p2m_domain * for p2m_*()
functions, you'll quickly find it used, I think.


    
      
    
        
    
          
    
            
    --- a/xen/arch/riscv/p2m.c
+++ b/xen/arch/riscv/p2m.c
@@ -1,13 +1,46 @@
  #include <xen/bitops.h>
+#include <xen/domain_page.h>
  #include <xen/event.h>
+#include <xen/iommu.h>
  #include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/pfn.h>
+#include <xen/rwlock.h>
  #include <xen/sched.h>
  #include <xen/spinlock.h>
  #include <xen/xvmalloc.h>
  
+#include <asm/page.h>
  #include <asm/p2m.h>
  #include <asm/sbi.h>
  
+/*
+ * Force a synchronous P2M TLB flush.
+ *
+ * Must be called with the p2m lock held.
+ */
+static void p2m_force_tlb_flush_sync(struct p2m_domain *p2m)
+{
+    struct domain *d = p2m->domain;
+
+    ASSERT(p2m_is_write_locked(p2m));
+
+    sbi_remote_hfence_gvma_vmid(d->dirty_cpumask, 0, 0, p2m->vmid);
+}
+
+/* Unlock the flush and do a P2M TLB flush if necessary */
+void p2m_write_unlock(struct p2m_domain *p2m)
+{
+    /*
+     * The final flush is done with the P2M write lock taken to avoid
+     * someone else modifying the P2M wbefore the TLB invalidation has
+     * completed.
+     */
+    p2m_force_tlb_flush_sync(p2m);

    
          
    
          
    The comment ahead of the function says "if necessary". Yet there's no
conditional here. I also question the need for a global flush in all
cases.

    
        
    
        
    Stale comment.

But if p2m page table was modified that it is needed to do a flush for CPUs
in d->dirty_cpumask.

    
      
    
      
    Right, but is that true for each and every case where you acquire the
lock in write mode? There may e.g. be early-out path which end up doing
nothing, yet you would then still flush the TLB.
    
    
    
    
    Initially, I assumed that early-out patch will happen mostly in the cases when
some error happen, so it will be okay to flush the TLB each time.

But, yes, I missed some cases when it will be end up doing nothing. I will return
back need_flush.


    
    
    
      
    

    
      
    
        
    
          
    
            
    @@ -109,8 +142,33 @@ int p2m_init(struct domain *d)
      spin_lock_init(&d->arch.paging.lock);
      INIT_PAGE_LIST_HEAD(&d->arch.paging.p2m_freelist);
  
+    rwlock_init(&p2m->lock);
+    INIT_PAGE_LIST_HEAD(&p2m->pages);
+
      p2m->vmid = INVALID_VMID;
  
+    p2m->default_access = p2m_access_rwx;
+
+    radix_tree_init(&p2m->p2m_type);
+
+#ifdef CONFIG_HAS_PASSTHROUGH

    
          
    
          
    Do you expect this to be conditionally selected on RISC-V?

    
        
    
        
    No, once it will be implemented it will be just selected once by config RISC-V.
And it was done so because iommu_has_feature() isn't implemented now as IOMMU
isn't supported now and depends on CONFIG_HAS_PASSTHROUGH.

    
      
    
      
    If the selection isn't going to be conditional, then I see no reason to have
such conditionals in RISC-V-specific code. The piece of code presently inside
that #ifdef may simply need adding later, once there's enough infrastructure
to allow that code to compile. Or maybe it would even compile fine already now?
    
    
    
    
    I haven't tried. Anyway, I get your point.


    
    
    
      
    

    
      
    
        
    
          
    
            
    +    /*
+     * Some IOMMUs don't support coherent PT walk. When the p2m is
+     * shared with the CPU, Xen has to make sure that the PT changes have
+     * reached the memory
+     */
+    p2m->clean_pte = is_iommu_enabled(d) &&
+        !iommu_has_feature(d, IOMMU_FEAT_COHERENT_WALK);

    
          
    
          
    The comment talks about shared page tables, yet you don't check whether
page table sharing is actually enabled for the domain.

    
        
    
        
    Do we have such function/macros?

    
      
    
      
    We have iommu_hap_pt_share, and we have the per-domain hap_pt_share flag.


    
      
    
        
    It is shared by implementation now.

    
      
    
      
    I don't understand. There's no IOMMU support yet for RISC-V. Hence it's in
neither state - not shared, but also not not shared.
    
    
    
    
    In downstream there is a support of IOMMU for RISC-V.
    
    
    ~ Oleksii

    
  


--------------4C0lvgBwVJ7PPdUnn48sBYMC--


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 10:06:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 10:06:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026089.1401360 (Exim 4.92)
	(envelope-from )
	id 1uUjUY-0007T5-Js; Thu, 26 Jun 2025 10:06:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026089.1401360; Thu, 26 Jun 2025 10:06: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 1uUjUY-0007St-Fx; Thu, 26 Jun 2025 10:06:02 +0000
Received: by outflank-mailman (input) for mailman id 1026089;
 Thu, 26 Jun 2025 10:06: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 1uUjUW-0007Sn-RJ
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 10:06:01 +0000
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [2a00:1450:4864:20::531])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 28af76be-5275-11f0-a30f-13f23c93f187;
 Thu, 26 Jun 2025 12:05:59 +0200 (CEST)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-604bff84741so1440777a12.2
 for ; Thu, 26 Jun 2025 03:05:59 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ae0ab44620csm451043966b.163.2025.06.26.03.05.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 26 Jun 2025 03:05:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 28af76be-5275-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750932359; x=1751537159; 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=+Lcbo0ciVhY04bYQvgNmQdQVatcke9QdNM6d3z3UZSU=;
        b=AU+k1RqrpSxUDTg6CLLcXjEJ2LrwcpaujgZbklAKFLFU+cjd0b0LmKFYI4ys6bnluo
         aKIwoLw2x4IXMpCnVI8gdzdKJeIeYJEvbyeDV9OhbX8RifVfOsszitfeY25TOxN0c+CX
         nXORUaF8Y8Qt5WpcxgifoK6t07sHGV8SpKe5EJd4fnitGKMsWGZsD/JTVDzMdsjXa8P2
         k6WsyYdZ6IzJZ2APuvi+jZk1vhR+D/Bxeb2PDwEFvkE02V2bRNHZquUSLOD1yLU/YDx4
         u0fQTR1lfzfTbBS/F+Ir51c6Axu3PD5Xjy/P/3OQtGwWSGzz3pE2hR1Ph/SdShWNK31A
         R4yg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750932359; x=1751537159;
        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=+Lcbo0ciVhY04bYQvgNmQdQVatcke9QdNM6d3z3UZSU=;
        b=quy7G40R/eIh1dtaawq2544sp2NbrtcpZVlcgqcvsMOZ5MPz1+G70+xoOosGxE+hU2
         /rda69z/DBT/5DNPp/jAgbvtJihznQjz7yowL0J+cKRD2FjD1GGOIXmYjQBFqWFhMtBV
         UWNxRVBU3hFSa7xsGRb4fDQBZbkeDYcnyctmEOzPENm+C/MSVf6gVB1XhaGhDJ/PlTtj
         +uIvGdR3Bz4Qr59CeDMgRhzYYCDZ76zgXTkW6FU7UHV2xfyI6H3qgfCewOe+1D5MW5CP
         Y5w8qh65Sbfkjz1CdCyziF0Appmk0U2wo8r+saPDZSPACTj7JT0wcBq38wyfjI2DeG7N
         Pv6A==
X-Forwarded-Encrypted: i=1; AJvYcCULACTJBj2+b3TTuUnA9ZHJD58xm5Fm1921sxpuBFJWkgrvo8u4xlNE40vz5Y2JS/XXC7SFbwDCGQA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyDiUglmzwFplOcUppwHxFFkFnuHDVFJTBQh4rwqOKFugWWWaeF
	XK+Qg3wEOuzvhp1zqEsjTPNW506kNugob+C+MqcHBAVHLY/VGAh0o9BQ
X-Gm-Gg: ASbGncsrJFr0IjMD3Y9Bln1KCAncue8P62v9HnrDHlHSSvbKvRKKoC/JLeII3fkp6q3
	UTo1y8kXA1HTLnNkcCysJhYkZx/wWguRRiAGAaQcX+zxeIClAqn4tPhP71TqNBv+IMmz3TFWdAV
	xgttMVNpaTOyS47249/F6oeiCUGa8g0qVt1yee3ZwPqdawXeaLX68Bw06WQb+DqB9M5MpAsIUYU
	QESL1sk/ySJLQkgwjRzvrjoVd17h2If01lzRIphGcuglfknWY6euIDLiXlvrMUMVhNA1SyEfudr
	/Utpgi2GpEpudpqiLd0cW6EaLNk+74tAYi/1JyxhjnmfqvgWYGfO8z1Vyyu3BTRnPt3kaFpP8xF
	YxLPFfmrxkALwc4u5r7a3LFCl0HBO/0Bte5g8g1jqvqlEDQ==
X-Google-Smtp-Source: AGHT+IGe9SwppheZUjam/H8AswI2L0vhLXctkS2UfNnH08NIo77sgRy0d9XZOZ5bzb21Kk+nahdvew==
X-Received: by 2002:a17:907:72c6:b0:ae0:d332:f637 with SMTP id a640c23a62f3a-ae0d332fee5mr308556766b.31.1750932358577;
        Thu, 26 Jun 2025 03:05:58 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------VDEQ7fGcXo4njzSsfmj00UBY"
Message-ID: <1a570c32-e207-47f5-9702-a752246328a9@gmail.com>
Date: Thu, 26 Jun 2025 12:05:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 03/17] xen/riscv: introduce guest domain's VMID
 allocation and manegement
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: 
 
 
 <145f71c2-643e-4839-a2ae-0bc1f049db74@gmail.com>
 <80223fe3-7403-4026-9505-8826c318fabb@suse.com>
 
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

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


On 6/24/25 4:01 PM, Jan Beulich wrote:
> On 24.06.2025 15:47, Oleksii Kurochko wrote:
>> On 6/24/25 12:44 PM, Jan Beulich wrote:
>>> On 24.06.2025 11:46, Oleksii Kurochko wrote:
>>>> On 6/18/25 5:46 PM, Jan Beulich wrote:
>>>>> On 10.06.2025 15:05, Oleksii Kurochko wrote:
>>>>>> --- /dev/null
>>>>>> +++ b/xen/arch/riscv/p2m.c
>>>>>> @@ -0,0 +1,115 @@
>>>>>> +#include 
>>>>>> +#include 
>>>>>> +#include 
>>>>>> +#include 
>>>>>> +#include 
>>>>>> +
>>>>>> +#include 
>>>>>> +#include 
>>>>>> +
>>>>>> +static spinlock_t vmid_alloc_lock = SPIN_LOCK_UNLOCKED;
>>>>>> +
>>>>>> +/*
>>>>>> + * hgatp's VMID field is 7 or 14 bits. RV64 may support 14-bit VMID.
>>>>>> + * Using a bitmap here limits us to 127 (2^7 - 1) or 16383 (2^14 - 1)
>>>>>> + * concurrent domains.
>>>>> Which is pretty limiting especially in the RV32 case. Hence why we don't
>>>>> assign a permanent ID to VMs on x86, but rather manage IDs per-CPU (note:
>>>>> not per-vCPU).
>>>> Good point.
>>>>
>>>> I don't believe anyone will use RV32.
>>>> For RV64, the available ID space seems sufficiently large.
>>>>
>>>> However, if it turns out that the value isn't large enough even for RV64,
>>>> I can rework it to manage IDs per physical CPU.
>>>> Wouldn't that approach result in more TLB entries being flushed compared
>>>> to per-vCPU allocation, potentially leading to slightly worse performance?
>>> Depends on the condition for when to flush. Of course performance is
>>> unavoidably going to suffer if you have only very few VMIDs to use.
>>> Nevertheless, as indicated before, the model used on x86 may be a
>>> candidate to use here, too. See hvm_asid_handle_vmenter() for the
>>> core (and vendor-independent) part of it.
>> IIUC, so basically it is just a round-robin and when VMIDs are ran out
>> then just do full guest TLB flush and start to re-use VMIDs from the start.
>> It makes sense to me, I'll implement something similar. (as I'm not really
>> sure that we needdata->core_asid_generation, probably, I will understand it better when
>> start to implement it)
> Well. The fewer VMID bits you have the more quickly you will need a new
> generation. And keep track of the generation you're at you also need to
> track the present number somewhere.
>
>>>> What about then to allocate VMID per-domain?
>>> That's what you're doing right now, isn't it? And that gets problematic when
>>> you have only very few bits in hgatp.VMID, as mentioned below.
>> Right, I just phrased my question poorly—sorry about that.
>>
>> What I meant to ask is: does the approach described above actually depend on whether
>> VMIDs are allocated per-domain or per-pCPU? It seems that the main advantage of
>> allocating VMIDs per-pCPU is potentially reducing the number of TLB flushes,
>> since it's more likely that a platform will have more than|VMID_MAX| domains than
>> |VMID_MAX| physical CPUs—am I right?
> Seeing that there can be systems with hundreds or even thousands of CPUs,
> I don't think I can agree here. Plus per-pCPU allocation would similarly
> get you in trouble when you have only very few VMID bits.

But not so fast as in case of per-domain allocation, right?

I mean that if we have only 4 bits, then in case of per-domain allocation we will
need to do TLB flush + VMID re-assigning when we have more then 16 domains.

But in case of per-pCPU allocation we could run 16 domains on 1 pCPU and at the same
time in multiprocessor systems we have more pCPUs, which will allow us to run more
domains and avoid TLB flushes.
On other hand, it is needed to consider that it's unlikely that a domain will have
only one vCPU. And it is likely that amount of vCPUs will be bigger then an amount
of domains, so to have a round-robin approach (as x86) without permanent ID allocation
for each domain will work better then per-pCPU allocation.
In other words, I'm not 100% sure that I get a point why x86 chose per-pCPU allocation
instead of per-domain allocation with having the same VMID for all vCPUs of domains.

~ Oleksii

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



  
    
  
  
    

    
    
    
    
    On 6/24/25 4:01 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 24.06.2025 15:47, Oleksii Kurochko wrote:

    On 6/24/25 12:44 PM, Jan Beulich wrote:

    On 24.06.2025 11:46, Oleksii Kurochko wrote:

    On 6/18/25 5:46 PM, Jan Beulich wrote:

    On 10.06.2025 15:05, Oleksii Kurochko wrote:

    --- /dev/null
+++ b/xen/arch/riscv/p2m.c
@@ -0,0 +1,115 @@
+#include <xen/bitops.h>
+#include <xen/lib.h>
+#include <xen/sched.h>
+#include <xen/spinlock.h>
+#include <xen/xvmalloc.h>
+
+#include <asm/p2m.h>
+#include <asm/sbi.h>
+
+static spinlock_t vmid_alloc_lock = SPIN_LOCK_UNLOCKED;
+
+/*
+ * hgatp's VMID field is 7 or 14 bits. RV64 may support 14-bit VMID.
+ * Using a bitmap here limits us to 127 (2^7 - 1) or 16383 (2^14 - 1)
+ * concurrent domains.

    Which is pretty limiting especially in the RV32 case. Hence why we don't
assign a permanent ID to VMs on x86, but rather manage IDs per-CPU (note:
not per-vCPU).

    Good point.

I don't believe anyone will use RV32.
For RV64, the available ID space seems sufficiently large.

However, if it turns out that the value isn't large enough even for RV64,
I can rework it to manage IDs per physical CPU.
Wouldn't that approach result in more TLB entries being flushed compared
to per-vCPU allocation, potentially leading to slightly worse performance?

    Depends on the condition for when to flush. Of course performance is
unavoidably going to suffer if you have only very few VMIDs to use.
Nevertheless, as indicated before, the model used on x86 may be a
candidate to use here, too. See hvm_asid_handle_vmenter() for the
core (and vendor-independent) part of it.

    IIUC, so basically it is just a round-robin and when VMIDs are ran out
then just do full guest TLB flush and start to re-use VMIDs from the start.
It makes sense to me, I'll implement something similar. (as I'm not really
sure that we needdata->core_asid_generation, probably, I will understand it better when 
start to implement it)

    Well. The fewer VMID bits you have the more quickly you will need a new
generation. And keep track of the generation you're at you also need to
track the present number somewhere.


    What about then to allocate VMID per-domain?

    That's what you're doing right now, isn't it? And that gets problematic when
you have only very few bits in hgatp.VMID, as mentioned below.

    Right, I just phrased my question poorly—sorry about that.

What I meant to ask is: does the approach described above actually depend on whether
VMIDs are allocated per-domain or per-pCPU? It seems that the main advantage of
allocating VMIDs per-pCPU is potentially reducing the number of TLB flushes,
since it's more likely that a platform will have more than|VMID_MAX| domains than
|VMID_MAX| physical CPUs—am I right?

    Seeing that there can be systems with hundreds or even thousands of CPUs,
I don't think I can agree here. Plus per-pCPU allocation would similarly
get you in trouble when you have only very few VMID bits.
    
    
    
    
    But not so fast as in case of per-domain allocation, right?

I mean that if we have only 4 bits, then in case of per-domain allocation we will
need to do TLB flush + VMID re-assigning when we have more then 16 domains.

But in case of per-pCPU allocation we could run 16 domains on 1 pCPU and at the same
time in multiprocessor systems we have more pCPUs, which will allow us to run more
domains and avoid TLB flushes.
On other hand, it is needed to consider that it's unlikely that a domain will have
only one vCPU. And it is likely that amount of vCPUs will be bigger then an amount
of domains, so to have a round-robin approach (as x86) without permanent ID allocation
for each domain will work better then per-pCPU allocation.
In other words, I'm not 100% sure that I get a point why x86 chose per-pCPU allocation
instead of per-domain allocation with having the same VMID for all vCPUs of domains.

~ Oleksii


    
  


--------------VDEQ7fGcXo4njzSsfmj00UBY--


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 10:08:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 10:08:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026096.1401369 (Exim 4.92)
	(envelope-from )
	id 1uUjWx-0007yO-VV; Thu, 26 Jun 2025 10:08:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026096.1401369; Thu, 26 Jun 2025 10: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 1uUjWx-0007yH-T0; Thu, 26 Jun 2025 10:08:31 +0000
Received: by outflank-mailman (input) for mailman id 1026096;
 Thu, 26 Jun 2025 10:08:30 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uUjWw-0007y9-4D
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 10:08:30 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uUjWv-003aCJ-1T;
 Thu, 26 Jun 2025 10:08:29 +0000
Received: from lfbn-gre-1-199-136.w90-112.abo.wanadoo.fr ([90.112.161.136]
 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 1uUjWv-005d3f-0I;
 Thu, 26 Jun 2025 10:08: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=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date;
	bh=4yJb8br+8EIUswdpssPtJLAqKPvkBi0TBobjJi2jxSU=; b=FzM8OJY9LN+3JmcM4KyhXig9Aa
	k0gpcfL3quyFM/c1FmNeiwSotqjwt+ya3a2pu0m8/6QcEbVz9k6PZk+wrQCs96eaPA42dCCi0G+SU
	+xCuvpTiSeIHitfRJF7C5meIUOnlRzp+NfDKdcWxlP/+clL6MRQqOWJus9UId3sOiQ/w=;
Date: Thu, 26 Jun 2025 12:08:26 +0200
From: Anthony PERARD 
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,
	Doug Goldstein ,
	Alessandro Zucchelli 
Subject: Re: [XEN PATCH] automation/eclair: Make report browsing URL
 configurable.
Message-ID: 
References: <2c0003504925e6f62b0bb1a13711c206e40f9393.1750919773.git.nicola.vetrini@bugseng.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2c0003504925e6f62b0bb1a13711c206e40f9393.1750919773.git.nicola.vetrini@bugseng.com>

On Thu, Jun 26, 2025 at 08:38:18AM +0200, Nicola Vetrini wrote:
> diff --git a/automation/eclair_analysis/ECLAIR/action.settings b/automation/eclair_analysis/ECLAIR/action.settings
> index 1577368b613b..f822f0ea66d7 100644
> --- a/automation/eclair_analysis/ECLAIR/action.settings
> +++ b/automation/eclair_analysis/ECLAIR/action.settings
> @@ -14,9 +14,6 @@ autoPRRepository="${AUTO_PR_REPOSITORY:-}"
>  # Customized
>  autoPRBranch="${AUTO_PR_BRANCH:-}"
>  
> -# Customized
> -artifactsRoot=/var/local/eclair
> -
>  case "${ci}" in
>  github)
>      # To be customized
> @@ -166,12 +163,34 @@ esac
>  
>  ECLAIR_BIN_DIR=/opt/bugseng/eclair/bin/
>  
> -artifactsDir="${artifactsRoot}/xen-project.ecdf/${repository}/ECLAIR_${ANALYSIS_KIND}"
> +# Artifacts URL served by the eclair_report server
> +if [ -z "${MACHINE_ARTIFACTS_ROOT}" ];

You don't need a ';' if you have `then` on the next line ;-)

> +then
> +  echo "WARNING: No artifacts root supplied, using default"
> +fi
> +if [ -z "${MACHINE_ECDF_DIR}" ];
> +then
> +  echo "WARNING: No ecdf dir supplied, using default"
> +fi
> +artifactsRoot="${MACHINE_ARTIFACTS_ROOT:-/var/local/eclair}"
> +artifactsEcdfDir="${MACHINE_ECDF_DIR:-xen-project.ecdf}"

Do we need to separate varables for these two? It might be a bit simpler
to have:
    artifactsRoot=/var/local/eclair/xen-project.ecdf
unless there's other path than *.ecdf. But in any case, two separate
variables looks fine too.

> +artifactsDir="${artifactsRoot}/${artifactsEcdfDir}/${repository}/ECLAIR_${ANALYSIS_KIND}"
>  subDir="${subDir}${variantSubDir}"
>  jobHeadline="${jobHeadline}${variantHeadline}"
>  
> -# Customized
> -eclairReportUrlPrefix=https://saas.eclairit.com:3787
> +# Remote eclair_report hosting server
> +if [ -z "${MACHINE_HOST}" ];
> +then
> +  echo "WARNING: No machine host supplied, using default"
> +fi
> +if [ -z "${MACHINE_PORT}" ];
> +then
> +  echo "WARNING: No machine port supplied, using default"
> +fi
> +
> +eclairReportHost="${MACHINE_HOST:-saas.eclairit.com}"
> +eclairReportPort="${MACHINE_PORT:-3787}"
> +eclairReportUrlPrefix="https://${eclairReportHost}:${eclairReportPort}"

Please, don't make the port number mandatory. Can you merge both host
and port in the same variable? This part seems to be called "authority":

    https://en.wikipedia.org/wiki/URL#Syntax

Also, don't use `MACHINE` as prefix/namespace for these new variables,
in a pipeline context, "machine" could be many things. Maybe
"ECLAIR_REPORT_HOST" for this one? With the default been:

    ECLAIR_REPORT_HOST=saas.eclairit.com:3787

I wonder if "https" should be configurable as well, but I guess there
shouldn't be any need for it as we probably don't want to serve reports
over http.

>  
>  jobDir="${artifactsDir}/${subDir}/${jobId}"
>  updateLog="${analysisOutputDir}/update.log"
> diff --git a/automation/eclair_analysis/ECLAIR/action_push.sh b/automation/eclair_analysis/ECLAIR/action_push.sh
> index 45215fbf005b..5002b48522e2 100755
> --- a/automation/eclair_analysis/ECLAIR/action_push.sh
> +++ b/automation/eclair_analysis/ECLAIR/action_push.sh
> @@ -1,6 +1,6 @@
>  #!/bin/sh
>  
> -set -eu
> +set -eux

Left over change from debugging?

>  
>  usage() {
>      echo "Usage: $0 WTOKEN ANALYSIS_OUTPUT_DIR" >&2
> diff --git a/automation/gitlab-ci/analyze.yaml b/automation/gitlab-ci/analyze.yaml
> index 5b00b9f25ca6..f027c6bc90b1 100644
> --- a/automation/gitlab-ci/analyze.yaml
> +++ b/automation/gitlab-ci/analyze.yaml
> @@ -8,6 +8,8 @@
>      ENABLE_ECLAIR_BOT: "n"
>      AUTO_PR_BRANCH: "staging"
>      AUTO_PR_REPOSITORY: "xen-project/xen"
> +    MACHINE_ARTIFACTS_ROOT: "/space"
> +    MACHINE_ECDF_DIR: "XEN.ecdf"

Is this the right place for these variables? Shouldn't they be set on
gitlab (at project or repo scope) or even set by the runner itself.

>    script:
>      - ./automation/scripts/eclair 2>&1 | tee "${LOGFILE}"
>    artifacts:
> diff --git a/automation/scripts/eclair b/automation/scripts/eclair
> index 0a2353c20a92..7020eaa0982f 100755
> --- a/automation/scripts/eclair
> +++ b/automation/scripts/eclair
> @@ -1,4 +1,15 @@
> -#!/bin/sh -eu
> +#!/bin/sh -eux
> +
> +# Runner-specific variables
> +ex=0
> +export "$(env | grep MACHINE_ARTIFACTS_ROOT)" || ex=$?
> +[ "${ex}" = 0 ] || exit "${ex}"

That's a really complicated way to check a variable is set...
Exporting a variable that's already in env isn't useful, and I think
`ex` is only ever set to `0`. It seems that `dash` just exit if you do
`export=""`.

You could simply do:

    : ${MACHINE_ARTIFACTS_ROOT:?Missing MACHINE_ARTIFACTS_ROOT variable}
    : ${MACHINE_ECDF_DIR:?Missing MACHINE_ECDF_DIR variable}

To check that the variables are set. Or nothing, if you add `set -u` to
the script (instead of the one -u in the sheband which might be ignored
if one run `sh ./eclair` instead of just `./eclair`.) Also the variable
should come from the env, as nothing sets it, so no need to for that.

( The `:` at the begining of the line is necessary, and behave the same
way as `true` does. We need it because ${parm:?msg} is expanded.)

Or you could use `if [ -z "${param}" ]` if ${param:?msg} is too obscure.
We would just have "parameter not set" instead of a nicer message, due
to `set -u`.

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 10:41:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 10:41:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026140.1401384 (Exim 4.92)
	(envelope-from )
	id 1uUk2s-0004YL-EA; Thu, 26 Jun 2025 10:41:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026140.1401384; Thu, 26 Jun 2025 10:41:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUk2s-0004YE-BY; Thu, 26 Jun 2025 10:41:30 +0000
Received: by outflank-mailman (input) for mailman id 1026140;
 Thu, 26 Jun 2025 10:41: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 1uUk2r-0004Y7-7k
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 10:41:29 +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 1aed2fc5-527a-11f0-b894-0df219b8e170;
 Thu, 26 Jun 2025 12:41:24 +0200 (CEST)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-3a4fea34e07so373682f8f.1
 for ; Thu, 26 Jun 2025 03:41:24 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-749c882cc92sm6552698b3a.82.2025.06.26.03.41.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 26 Jun 2025 03:41:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1aed2fc5-527a-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750934483; x=1751539283; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=y1cBcurgCqqnZFCG+WCAQ21C9Go9725VOpbeSHrWZXQ=;
        b=Ij1jTwls9FoM2EM8Ew/519PeTB70RKZn2sLWSp3wo1aDnZz70ywnSt3uJ3efLPCMzp
         DJoVhmcFRo9Uz5Oejxc9vAyaZXxCr4oJ5AoiUfNtvx9sj/IdKs7dHmjGvb3CqwMT9Y+I
         f/ITJPAJNoPS7pRykqN0WiSmoD7oRW/zSKlgO6gfl4zaPFxa7eAxrHf1PSrr8PFNaKOY
         I9l5bQDCYPF4o+wh4xEHLBTWa1Uaa7f6GEbI6W8yGTIcI5SDwyk/3gR9Jkl79oY3R1oS
         EYW12pdeDSPf9KisBjf/AfNA5O5nto5EjRr1jjI39fMjQ8TX/5mQGF1hcROi3qSYq0T7
         IuNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750934483; x=1751539283;
        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=y1cBcurgCqqnZFCG+WCAQ21C9Go9725VOpbeSHrWZXQ=;
        b=jIPL8XsUBXJYdQhskSmGEK6KsXxrHb+NFPy2FZkW9KgS+MHaUkXD5R8KkvLD1Zy85n
         h0gU8oGXXkiXj6n5Dwzzk3UKaBAHnrr0C8Yu6nhDZy+olzYCwA413WoMGPSrg/WiqWiT
         Eo9Z6YS3WjMq5RsM0VJWhj8nw9eMQYhWlf/64GNJOv5NuWDWe5E6S9Wz8OK4hlnE54Zh
         q1YVu6CTOMe6dxJB/wT7jIs5pEuQCi/S842AnPPAZSTo8fwD74+BxpUaYF8939n4CK74
         0kZd3hqf6lgmAg97t/zdTUaOzW4eSXFAPiPsYEaWFxom/79HbS+oeI7FWhS6bf6VZ4X6
         NUhw==
X-Forwarded-Encrypted: i=1; AJvYcCXlxm9W4RLSotUEOZrt1lmzmGLLhflMjgk6vvIxeQMENG2ogSRZFKegiR7o152GDJBRA7s8MRoMufo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxY/ftGlLP71b/14a+XdyPI6/QSTQbAXTRKoyFgbKhVoNhxTwkX
	TxvIiZho8qRl7MJeocMzRia+iVXVr5fLhB8fAcW36ffq8qpx+D1JDB8gw+VlSDyHug==
X-Gm-Gg: ASbGncs5m4M49d5CXm1cJCidZaLWshgBG5Gl9nBYpU6zkMt9gXpYGEbFhKCS3NGV0DU
	DbfSbZs6q+AxGvob5akOCcUl+BwMTNUO/997NTKPoJMfcjb0rWD+zgBndj/swAB3721qSoUfSQt
	4oxnxaJjZb0aHGP7OWblQu1qraN88E5uSvjh/kfv9vZIhIGkquJHfTHPXWqHF1l1I7+6FtwgvHA
	ZH+yHwAr9EyZSTmAOQ5fxJF963kDgr13xRS1AzLP7z3tk7Z8uj4pXVtMes1CW+tPBMQAOlXnBW1
	FveiNs0ne4EgmjuafHcum5E1XDOg4x/pZG+dhjlyyf8PWuUem3f9sGFkKan/IFyzIyLf8Ut1tuY
	W35XUH1HqLAzlJyx/jgx8OwI8F+Qr7vsbUBY2aO6981ZJel0=
X-Google-Smtp-Source: AGHT+IEQSVf3SvVkT3vns+YLr+3r/4KxOTTOiNPnZY+3T1TteF7HTAzQyvleLyseEsJHX/lblmXrvg==
X-Received: by 2002:a05:6000:1883:b0:3a0:7d27:f076 with SMTP id ffacd0b85a97d-3a6f2e86a29mr3108615f8f.2.1750934483367;
        Thu, 26 Jun 2025 03:41:23 -0700 (PDT)
Message-ID: 
Date: Thu, 26 Jun 2025 12:41:11 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 03/17] xen/riscv: introduce guest domain's VMID
 allocation and manegement
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: 
 
 
 <145f71c2-643e-4839-a2ae-0bc1f049db74@gmail.com>
 <80223fe3-7403-4026-9505-8826c318fabb@suse.com>
 
 
 <1a570c32-e207-47f5-9702-a752246328a9@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: <1a570c32-e207-47f5-9702-a752246328a9@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 26.06.2025 12:05, Oleksii Kurochko wrote:
> 
> On 6/24/25 4:01 PM, Jan Beulich wrote:
>> On 24.06.2025 15:47, Oleksii Kurochko wrote:
>>> On 6/24/25 12:44 PM, Jan Beulich wrote:
>>>> On 24.06.2025 11:46, Oleksii Kurochko wrote:
>>>>> On 6/18/25 5:46 PM, Jan Beulich wrote:
>>>>>> On 10.06.2025 15:05, Oleksii Kurochko wrote:
>>>>>>> --- /dev/null
>>>>>>> +++ b/xen/arch/riscv/p2m.c
>>>>>>> @@ -0,0 +1,115 @@
>>>>>>> +#include 
>>>>>>> +#include 
>>>>>>> +#include 
>>>>>>> +#include 
>>>>>>> +#include 
>>>>>>> +
>>>>>>> +#include 
>>>>>>> +#include 
>>>>>>> +
>>>>>>> +static spinlock_t vmid_alloc_lock = SPIN_LOCK_UNLOCKED;
>>>>>>> +
>>>>>>> +/*
>>>>>>> + * hgatp's VMID field is 7 or 14 bits. RV64 may support 14-bit VMID.
>>>>>>> + * Using a bitmap here limits us to 127 (2^7 - 1) or 16383 (2^14 - 1)
>>>>>>> + * concurrent domains.
>>>>>> Which is pretty limiting especially in the RV32 case. Hence why we don't
>>>>>> assign a permanent ID to VMs on x86, but rather manage IDs per-CPU (note:
>>>>>> not per-vCPU).
>>>>> Good point.
>>>>>
>>>>> I don't believe anyone will use RV32.
>>>>> For RV64, the available ID space seems sufficiently large.
>>>>>
>>>>> However, if it turns out that the value isn't large enough even for RV64,
>>>>> I can rework it to manage IDs per physical CPU.
>>>>> Wouldn't that approach result in more TLB entries being flushed compared
>>>>> to per-vCPU allocation, potentially leading to slightly worse performance?
>>>> Depends on the condition for when to flush. Of course performance is
>>>> unavoidably going to suffer if you have only very few VMIDs to use.
>>>> Nevertheless, as indicated before, the model used on x86 may be a
>>>> candidate to use here, too. See hvm_asid_handle_vmenter() for the
>>>> core (and vendor-independent) part of it.
>>> IIUC, so basically it is just a round-robin and when VMIDs are ran out
>>> then just do full guest TLB flush and start to re-use VMIDs from the start.
>>> It makes sense to me, I'll implement something similar. (as I'm not really
>>> sure that we needdata->core_asid_generation, probably, I will understand it better when
>>> start to implement it)
>> Well. The fewer VMID bits you have the more quickly you will need a new
>> generation. And keep track of the generation you're at you also need to
>> track the present number somewhere.
>>
>>>>> What about then to allocate VMID per-domain?
>>>> That's what you're doing right now, isn't it? And that gets problematic when
>>>> you have only very few bits in hgatp.VMID, as mentioned below.
>>> Right, I just phrased my question poorly—sorry about that.
>>>
>>> What I meant to ask is: does the approach described above actually depend on whether
>>> VMIDs are allocated per-domain or per-pCPU? It seems that the main advantage of
>>> allocating VMIDs per-pCPU is potentially reducing the number of TLB flushes,
>>> since it's more likely that a platform will have more than|VMID_MAX| domains than
>>> |VMID_MAX| physical CPUs—am I right?
>> Seeing that there can be systems with hundreds or even thousands of CPUs,
>> I don't think I can agree here. Plus per-pCPU allocation would similarly
>> get you in trouble when you have only very few VMID bits.
> 
> But not so fast as in case of per-domain allocation, right?
> 
> I mean that if we have only 4 bits, then in case of per-domain allocation we will
> need to do TLB flush + VMID re-assigning when we have more then 16 domains.
> 
> But in case of per-pCPU allocation we could run 16 domains on 1 pCPU and at the same
> time in multiprocessor systems we have more pCPUs, which will allow us to run more
> domains and avoid TLB flushes.
> On other hand, it is needed to consider that it's unlikely that a domain will have
> only one vCPU. And it is likely that amount of vCPUs will be bigger then an amount
> of domains, so to have a round-robin approach (as x86) without permanent ID allocation
> for each domain will work better then per-pCPU allocation.

Here you (appear to) say one thing, ...

> In other words, I'm not 100% sure that I get a point why x86 chose per-pCPU allocation
> instead of per-domain allocation with having the same VMID for all vCPUs of domains.

... and then here the opposite. Overall I'm in severe trouble understanding this
reply of yours as a whole, so I fear I can't really respond to it (or even just
parts thereof).

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 11:01:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 11:01:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026153.1401394 (Exim 4.92)
	(envelope-from )
	id 1uUkMJ-0007QW-3k; Thu, 26 Jun 2025 11:01:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026153.1401394; Thu, 26 Jun 2025 11:01: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 1uUkMJ-0007QP-0I; Thu, 26 Jun 2025 11:01:35 +0000
Received: by outflank-mailman (input) for mailman id 1026153;
 Thu, 26 Jun 2025 11:01: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 1uUkMH-0007QJ-8A
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 11:01:33 +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 ea6bd86d-527c-11f0-b894-0df219b8e170;
 Thu, 26 Jun 2025 13:01:31 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a57ae5cb17so497675f8f.0
 for ; Thu, 26 Jun 2025 04:01:31 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-749c88548dbsm7122468b3a.133.2025.06.26.04.01.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 26 Jun 2025 04:01:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ea6bd86d-527c-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750935691; x=1751540491; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=JTTzSn1mp5tKrc97TyIj6fMd1If/EadWFimAPQUV/t4=;
        b=LBP4LMA0G6kLrn5qOsISIhRs3+HwFsXZDwi92jBNMl3EK9Lw0pmdpXpIx/BUpuXk37
         9EqxherzkuoUS+oiUJn9O4AtQUfoil2KiCgc+W8Sfged7qn4M2+gZVLzfTDTIjZhvfsx
         6RJMY46wpBqmzWsQC+11MigvzayiQYA4Q1mMZS19E+y5noni3+DXqI9Bm3E3u//ybDYT
         T9Rcw4nFh+7u1TpX6tKgMAtJ/h/NlqcvRlRnWX/L69obnrYfZ+YF35xyLO3b4INtl1lR
         R/twzPzQ2xTiSTYDn3Ue7YovYsLrWZIr0Cy9LaMfbdBDSj9HZ6vEII04lip/jACJVgEf
         Ztzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750935691; x=1751540491;
        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=JTTzSn1mp5tKrc97TyIj6fMd1If/EadWFimAPQUV/t4=;
        b=Erc9PW6AZBTx0UlRw9FTXpb+tC3+R8MSrOzVPS91kF4cEIF1BHBndMjH4ZW33vJJmB
         tlPuK7fQzA7IvjL7ZnlfVpJOQYQB/ctCCLWGFl7HfP62o8QFJI+lr+uwkf7BBP1Gg5Ia
         zu41mQntJUEYAPNPFtaXiY2JyGoZsKbB14Hch4WHcCeJycV9klIF6osoXF90xwIrisAJ
         1znCy+PXS/PQLR64NwubjL4H5RtPrRx56wBxrXnbrJaenRqoGgwHug9Ldjr+NX6lppKs
         NsW+9WN+H2YpPBJ4V0dTcmR+CihEf7pO5ueozbEOri+OlFXIwGQ5j4kRHk5ksGooS8VA
         zPhg==
X-Forwarded-Encrypted: i=1; AJvYcCUlwUCW6zW2u0PqHfdrIPPaFSKSFjAqI9DGmM+78RFG2s/rkBRxLP6gccV+k9DMK446Twg3x+XObkc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxjUXSuUi5dGIUv4lp9JMM/AFXD+nZDO9FxOZKO5DCaYfQ6LGwN
	papMeoVgJgvE0Kp1kbbSv3Y+w8bXrNQFUUWELHIYKA9IQ4K/NknLMFP88E0+FIAHWA==
X-Gm-Gg: ASbGncsxkppVekpPhRC7Q/B66uJHpv0OYNtHw7h7HBSt/izF97TRd93+D4/EuXIeTGT
	RfdNKL11WrGJe7BQpssP+eQZ38RYtHmLlthWTacpBW36yuLwciYQiRGrBrpVz6zSBXTU4oWX9Hr
	7M+XX47qJT7S9f+M/K5sQetAf9x707u500yzcnZBlfzrVNXrrXjna/WxUREYHN+aKRX4DE0roih
	lquIPeK0K6Jij3Nz/buDwRU5U6SqlinLyFwuUqmXm3rYBvbJqENCliOWs82qDhVZZf22dWNTHBM
	xllMLhZ+2JyXAP+MpJJyfwzsnLtROBc2I1bxihYb/5KTEs6oD8Tlhk4DQHemUUwVDJ9OvWiBf17
	6KbNm/bXOHEwSrSse1MW9YWjc1vxM40cLRLSeI3mheJy9yVA=
X-Google-Smtp-Source: AGHT+IFy6hVfBXCtLj2C/CgIn2/UKXGM1mCYTqCw3Usbx3prNtRhG0Flbrgrb9SzdiySjRr8FsEaJw==
X-Received: by 2002:a5d:5e8d:0:b0:3a5:88e9:a54f with SMTP id ffacd0b85a97d-3a6ed5ea197mr5914677f8f.1.1750935690424;
        Thu, 26 Jun 2025 04:01:30 -0700 (PDT)
Message-ID: <1bb7c808-9383-4c51-880e-a12984d544c4@suse.com>
Date: Thu, 26 Jun 2025 13:01:19 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 05/17] xen/riscv: introduce things necessary for p2m
 initialization
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: 
 <443cb3566a60dcb5d5440c72410ff6d76a010a58.1749555949.git.oleksii.kurochko@gmail.com>
 <5c61fd86-5c0e-481e-a5a9-6a53f2d78c36@suse.com>
 <0b3c403b-0f24-4fc6-ba5b-fb4df62d7057@gmail.com>
 <7cb7a46b-8d2e-4f9e-9613-f7a4199096ee@suse.com>
 <8741800f-b40b-4c42-b435-91e2f9375f6c@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: <8741800f-b40b-4c42-b435-91e2f9375f6c@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 26.06.2025 10:40, Oleksii Kurochko wrote:
> On 6/25/25 5:53 PM, Jan Beulich wrote:
>> On 25.06.2025 17:31, Oleksii Kurochko wrote:
>>> On 6/18/25 6:08 PM, Jan Beulich wrote:
>>>> On 10.06.2025 15:05, Oleksii Kurochko wrote:
>>>>> @@ -14,6 +18,29 @@
>>>>>    
>>>>>    /* Per-p2m-table state */
>>>>>    struct p2m_domain {
>>>>> +    /*
>>>>> +     * Lock that protects updates to the p2m.
>>>>> +     */
>>>>> +    rwlock_t lock;
>>>>> +
>>>>> +    /* Pages used to construct the p2m */
>>>>> +    struct page_list_head pages;
>>>>> +
>>>>> +    /* Indicate if it is required to clean the cache when writing an entry */
>>>>> +    bool clean_pte;
>>>>> +
>>>>> +    struct radix_tree_root p2m_type;
>>>> A field with a p2m_ prefix in a p2m struct?
>>> p2m_ prefix could be really dropped.
>>>
>>>>    And is this tree really about
>>>> just a single "type"?
>>> Yes, we don't have enough bits in PTE so we need some extra storage to store type.
>> My question wasn't about that, though. My question was whether in the name
>> "type" (singular) is appropriate. I didn't think you need a tree to store just
>> a single type.
> 
> I need tree to store a pair of , where gfn is an index. And it seems
> to me a tree is a good structure for fast insert/search.

Hmm, I'm increasingly puzzled. I tried to emphasize that my question was towards
the singular "type" in the variable name. I can't see any relationship between
that and your reply. (And yes, using a tree here may be appropriate. There is a
concern towards memory consumption, but that's a separate topic.)

Having said that, aiui you don't use the two RSW bits in the PTE. Do you have
any plans there? If not, can't they be used to at least represent the most
commonly used types, such that the number of entries in that tree can be kept
(relatively) low?

>>>>> +    /*
>>>>> +     * Some IOMMUs don't support coherent PT walk. When the p2m is
>>>>> +     * shared with the CPU, Xen has to make sure that the PT changes have
>>>>> +     * reached the memory
>>>>> +     */
>>>>> +    p2m->clean_pte = is_iommu_enabled(d) &&
>>>>> +        !iommu_has_feature(d, IOMMU_FEAT_COHERENT_WALK);
>>>> The comment talks about shared page tables, yet you don't check whether
>>>> page table sharing is actually enabled for the domain.
>>> Do we have such function/macros?
>> We have iommu_hap_pt_share, and we have the per-domain hap_pt_share flag.
>>
>>> It is shared by implementation now.
>> I don't understand. There's no IOMMU support yet for RISC-V. Hence it's in
>> neither state - not shared, but also not not shared.
> 
> In downstream there is a support of IOMMU for RISC-V.

And there page tables are unconditionally shared? I'll be surprised if no
want/need for non-shared page tables would ever appear.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 11:35:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 11:35:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026172.1401404 (Exim 4.92)
	(envelope-from )
	id 1uUksd-00035g-HE; Thu, 26 Jun 2025 11:34:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026172.1401404; Thu, 26 Jun 2025 11: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 1uUksd-00035Z-EK; Thu, 26 Jun 2025 11:34:59 +0000
Received: by outflank-mailman (input) for mailman id 1026172;
 Thu, 26 Jun 2025 11:34: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 1uUksb-00035T-O2
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 11:34:57 +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 95670877-5281-11f0-a30f-13f23c93f187;
 Thu, 26 Jun 2025 13:34:56 +0200 (CEST)
Received: by mail-ed1-x52d.google.com with SMTP id
 4fb4d7f45d1cf-60780d74c85so1302513a12.2
 for ; Thu, 26 Jun 2025 04:34:56 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-60c2f4812a6sm3809620a12.60.2025.06.26.04.34.53
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 26 Jun 2025 04:34:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 95670877-5281-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750937695; x=1751542495; 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=c43Gu5XtzSkIfMKI2APDEJf2hd+ypM6IFOU4O6EScPA=;
        b=Me7Khi7nYCZ7i8uDM54B8nf0r5txP50F07RldWABsKeSE+AKHTMYMv+Zn11XIbnZkk
         GzM3sJD5APm4TSySgR6g6oyxMs4hSASWEtFvAii1p1downFvUcLwpQOoXFXeGikx6jIu
         pkDCDT0wf6PonLBW+INRotNXfJQFzmj0aZhJxkn5zT8A+qHqkthT42oPxc/0+y1pQ7gh
         J8eevcHDNw3o/6TX0yc/Bj8Hha0V40ZB9VGkdbYSdl/ieSIxFNnWNERIx5fppXVoeT80
         +ZqjRimR//fo3h2Kog0FuAg8zhASq/oQe/DObmbuWDTl8F1iNDL8YOdjgk7tcQbC/Dxq
         3rzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750937695; x=1751542495;
        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=c43Gu5XtzSkIfMKI2APDEJf2hd+ypM6IFOU4O6EScPA=;
        b=rzkp2m14R/Nl7vApZKAgrsg+66Mad/N0O78AaE8SDXNonlzuaanjUF1h7YnMR39g6V
         obmAgcd40nY231/Ndp7zfNss39FEmBJF3bEk24ZoyQX0Py0KOq6NQvNMgacauifqmVgb
         vfBG+XwDE7bNV0mTzvSRcPIk6h1o3jjbrZP4x0enbhLxjf9oJ2PgdA9s+EBHPlyw6vkN
         7aW7ZRQWs02iKFb/OxEl045rDl1F0O04MZMN/+Cp0C4YODQh25HhUbprK/PN416BgCOm
         EwQ/4iCThnPoudFdEK5OhyxbnISE8/qKKRKP/I6UflWeibIyubkGixpOo95qW6kktw8X
         rfsg==
X-Forwarded-Encrypted: i=1; AJvYcCXh7cVSp3NmT17mn/W56Z1APOQG5LabBKo1ImJrmTFej34LGsDve+NY2nigiOOoR8v0kzJp4DqwURY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy5coDiUoDjYkGj2EIyuDb/Bn5uAw/AFVLkGDTJWnou+EZj/eEb
	xK66u5Dyx3s0GDU5M2aJd3wDhphDAHFy4asqJ++cvga2zXMsavt5pPw3
X-Gm-Gg: ASbGncvSrM6cGWvcYh8NgN4uBQQKZXQdL0nvyvcLxX7o+Lf+pRYWF1mIkdhLWb+/dYF
	FPVgDWt4hxDtoeVF7XJ26L3G3WnoKM1hgk7iHQfHYtjfVh+zFKOoaNmwe3FcCg6VrV09vP4T+Hw
	ceJVRcUEiE0NVKaC0e75tlK0KAXkelA0cTF8B47LRqOEoXLNtyOf6h6CuLoU/9eOg8lMDvZf1yG
	GeGRBKid4gDhEweC6s2MLT9otmli5kg51gRzs96duRv9eX5A4Hno1DCVy+u3gWFd+am9iKBED50
	RlJbk0i7muqLUTXK2MufJ2XiKMKAIXVjSVTOk1JXfybTXSJdmMyPAcIgCza2b4ZtdjLwV32znht
	eRC25I17spQfMCX6AB0sYbHd6rK66Cum+cn8=
X-Google-Smtp-Source: AGHT+IFY2KYhNC3wd+6m1ev6CZTO+3Azx9n8u/4uCB9ax2OPBocdwr6Vj+c9OJqP7ZJRxm176o87gA==
X-Received: by 2002:a05:6402:5cd:b0:60c:3a86:e117 with SMTP id 4fb4d7f45d1cf-60c4df1890emr5164619a12.34.1750937695112;
        Thu, 26 Jun 2025 04:34:55 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------Mw32BkD2nR21rsGAgsMukTKb"
Message-ID: <264db0b0-43bf-4829-a5cc-ca696601349c@gmail.com>
Date: Thu, 26 Jun 2025 13:34:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 03/17] xen/riscv: introduce guest domain's VMID
 allocation and manegement
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: 
 
 
 <145f71c2-643e-4839-a2ae-0bc1f049db74@gmail.com>
 <80223fe3-7403-4026-9505-8826c318fabb@suse.com>
 
 
 <1a570c32-e207-47f5-9702-a752246328a9@gmail.com>
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

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


On 6/26/25 12:41 PM, Jan Beulich wrote:
> On 26.06.2025 12:05, Oleksii Kurochko wrote:
>> On 6/24/25 4:01 PM, Jan Beulich wrote:
>>> On 24.06.2025 15:47, Oleksii Kurochko wrote:
>>>> On 6/24/25 12:44 PM, Jan Beulich wrote:
>>>>> On 24.06.2025 11:46, Oleksii Kurochko wrote:
>>>>>> On 6/18/25 5:46 PM, Jan Beulich wrote:
>>>>>>> On 10.06.2025 15:05, Oleksii Kurochko wrote:
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/xen/arch/riscv/p2m.c
>>>>>>>> @@ -0,0 +1,115 @@
>>>>>>>> +#include 
>>>>>>>> +#include 
>>>>>>>> +#include 
>>>>>>>> +#include 
>>>>>>>> +#include 
>>>>>>>> +
>>>>>>>> +#include 
>>>>>>>> +#include 
>>>>>>>> +
>>>>>>>> +static spinlock_t vmid_alloc_lock = SPIN_LOCK_UNLOCKED;
>>>>>>>> +
>>>>>>>> +/*
>>>>>>>> + * hgatp's VMID field is 7 or 14 bits. RV64 may support 14-bit VMID.
>>>>>>>> + * Using a bitmap here limits us to 127 (2^7 - 1) or 16383 (2^14 - 1)
>>>>>>>> + * concurrent domains.
>>>>>>> Which is pretty limiting especially in the RV32 case. Hence why we don't
>>>>>>> assign a permanent ID to VMs on x86, but rather manage IDs per-CPU (note:
>>>>>>> not per-vCPU).
>>>>>> Good point.
>>>>>>
>>>>>> I don't believe anyone will use RV32.
>>>>>> For RV64, the available ID space seems sufficiently large.
>>>>>>
>>>>>> However, if it turns out that the value isn't large enough even for RV64,
>>>>>> I can rework it to manage IDs per physical CPU.
>>>>>> Wouldn't that approach result in more TLB entries being flushed compared
>>>>>> to per-vCPU allocation, potentially leading to slightly worse performance?
>>>>> Depends on the condition for when to flush. Of course performance is
>>>>> unavoidably going to suffer if you have only very few VMIDs to use.
>>>>> Nevertheless, as indicated before, the model used on x86 may be a
>>>>> candidate to use here, too. See hvm_asid_handle_vmenter() for the
>>>>> core (and vendor-independent) part of it.
>>>> IIUC, so basically it is just a round-robin and when VMIDs are ran out
>>>> then just do full guest TLB flush and start to re-use VMIDs from the start.
>>>> It makes sense to me, I'll implement something similar. (as I'm not really
>>>> sure that we needdata->core_asid_generation, probably, I will understand it better when
>>>> start to implement it)
>>> Well. The fewer VMID bits you have the more quickly you will need a new
>>> generation. And keep track of the generation you're at you also need to
>>> track the present number somewhere.
>>>
>>>>>> What about then to allocate VMID per-domain?
>>>>> That's what you're doing right now, isn't it? And that gets problematic when
>>>>> you have only very few bits in hgatp.VMID, as mentioned below.
>>>> Right, I just phrased my question poorly—sorry about that.
>>>>
>>>> What I meant to ask is: does the approach described above actually depend on whether
>>>> VMIDs are allocated per-domain or per-pCPU? It seems that the main advantage of
>>>> allocating VMIDs per-pCPU is potentially reducing the number of TLB flushes,
>>>> since it's more likely that a platform will have more than|VMID_MAX| domains than
>>>> |VMID_MAX| physical CPUs—am I right?
>>> Seeing that there can be systems with hundreds or even thousands of CPUs,
>>> I don't think I can agree here. Plus per-pCPU allocation would similarly
>>> get you in trouble when you have only very few VMID bits.
>> But not so fast as in case of per-domain allocation, right?
>>
>> I mean that if we have only 4 bits, then in case of per-domain allocation we will
>> need to do TLB flush + VMID re-assigning when we have more then 16 domains.
>>
>> But in case of per-pCPU allocation we could run 16 domains on 1 pCPU and at the same
>> time in multiprocessor systems we have more pCPUs, which will allow us to run more
>> domains and avoid TLB flushes.
>> On other hand, it is needed to consider that it's unlikely that a domain will have
>> only one vCPU. And it is likely that amount of vCPUs will be bigger then an amount
>> of domains, so to have a round-robin approach (as x86) without permanent ID allocation
>> for each domain will work better then per-pCPU allocation.
> Here you (appear to) say one thing, ...
>
>> In other words, I'm not 100% sure that I get a point why x86 chose per-pCPU allocation
>> instead of per-domain allocation with having the same VMID for all vCPUs of domains.
> ... and then here the opposite. Overall I'm in severe trouble understanding this
> reply of yours as a whole, so I fear I can't really respond to it (or even just
> parts thereof).

IIUC, x86 allocates VMIDs per physical CPU (pCPU) "dynamically" — these are just
sequential numbers, and once VMIDs run out on a given pCPU, there's no guarantee
that a vCPU will receive the same VMID again.

On the other hand, RISC-V currently allocates a single VMID per domain, and that
VMID is considered "permanent" until the domain is destroyed. This means we are
limited to at most VMID_MAX domains. To avoid this limitation, I plan to implement
a round-robin reuse approach: when no free VMIDs remain, we start a new generation
and begin reusing old VMIDs.

The only remaining design question is whether we want RISC-V to follow a global
VMID allocation policy (i.e., one VMID per domain, shared across all of its vCPUs),
or adopt a policy similar to x86 with per-CPU VMID allocation (each vCPU gets its
own VMID, local to the CPU it's running on).

Each policy has its own trade-offs. But in the case where the number of available
VMIDs is small (i.e., low VMIDLEN), a global allocation policy may be more suitable,
as it requires fewer VMIDs overall.

So my main question was:
What are the advantages of per-pCPU VMID allocation in scenarios with limited VMID
space, and why did x86 choose that design?

 From what I can tell, the benefits of per-pCPU VMID allocation include:
- Minimized inter-CPU TLB flushes — since VMIDs are local, TLB entries don’t need
   to be invalidated on other CPUs when reused.
- Better scalability — this approach works better on systems with a large number
   of CPUs.
- Frequent VM switches don’t require global TLB flushes — reducing the overhead
   of context switching.
However, the downside is that this model consumes more VMIDs. For example,
if a single domain runs on 4 vCPUs across 4 CPUs, it will consume 4 VMIDs instead
of just one.

~ Oleksii

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



  
    
  
  
    

    
    
    
    
    On 6/26/25 12:41 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 26.06.2025 12:05, Oleksii Kurochko wrote:

    
      
    
        
    On 6/24/25 4:01 PM, Jan Beulich wrote:

    
        
    
          
    On 24.06.2025 15:47, Oleksii Kurochko wrote:

    
          
    
            
    On 6/24/25 12:44 PM, Jan Beulich wrote:

    
            
    
              
    On 24.06.2025 11:46, Oleksii Kurochko wrote:

    
              
    
                
    On 6/18/25 5:46 PM, Jan Beulich wrote:

    
                
    
                  
    On 10.06.2025 15:05, Oleksii Kurochko wrote:

    
                  
    
                    
    --- /dev/null
+++ b/xen/arch/riscv/p2m.c
@@ -0,0 +1,115 @@
+#include <xen/bitops.h>
+#include <xen/lib.h>
+#include <xen/sched.h>
+#include <xen/spinlock.h>
+#include <xen/xvmalloc.h>
+
+#include <asm/p2m.h>
+#include <asm/sbi.h>
+
+static spinlock_t vmid_alloc_lock = SPIN_LOCK_UNLOCKED;
+
+/*
+ * hgatp's VMID field is 7 or 14 bits. RV64 may support 14-bit VMID.
+ * Using a bitmap here limits us to 127 (2^7 - 1) or 16383 (2^14 - 1)
+ * concurrent domains.

    
                  
    
                  
    Which is pretty limiting especially in the RV32 case. Hence why we don't
assign a permanent ID to VMs on x86, but rather manage IDs per-CPU (note:
not per-vCPU).

    
                
    
                
    Good point.

I don't believe anyone will use RV32.
For RV64, the available ID space seems sufficiently large.

However, if it turns out that the value isn't large enough even for RV64,
I can rework it to manage IDs per physical CPU.
Wouldn't that approach result in more TLB entries being flushed compared
to per-vCPU allocation, potentially leading to slightly worse performance?

    
              
    
              
    Depends on the condition for when to flush. Of course performance is
unavoidably going to suffer if you have only very few VMIDs to use.
Nevertheless, as indicated before, the model used on x86 may be a
candidate to use here, too. See hvm_asid_handle_vmenter() for the
core (and vendor-independent) part of it.

    
            
    
            
    IIUC, so basically it is just a round-robin and when VMIDs are ran out
then just do full guest TLB flush and start to re-use VMIDs from the start.
It makes sense to me, I'll implement something similar. (as I'm not really
sure that we needdata->core_asid_generation, probably, I will understand it better when
start to implement it)

    
          
    
          
    Well. The fewer VMID bits you have the more quickly you will need a new
generation. And keep track of the generation you're at you also need to
track the present number somewhere.


    
          
    
            
    
              
    
                
    What about then to allocate VMID per-domain?

    
              
    
              
    That's what you're doing right now, isn't it? And that gets problematic when
you have only very few bits in hgatp.VMID, as mentioned below.

    
            
    
            
    Right, I just phrased my question poorly—sorry about that.

What I meant to ask is: does the approach described above actually depend on whether
VMIDs are allocated per-domain or per-pCPU? It seems that the main advantage of
allocating VMIDs per-pCPU is potentially reducing the number of TLB flushes,
since it's more likely that a platform will have more than|VMID_MAX| domains than
|VMID_MAX| physical CPUs—am I right?

    
          
    
          
    Seeing that there can be systems with hundreds or even thousands of CPUs,
I don't think I can agree here. Plus per-pCPU allocation would similarly
get you in trouble when you have only very few VMID bits.

    
        
    
        
    But not so fast as in case of per-domain allocation, right?

I mean that if we have only 4 bits, then in case of per-domain allocation we will
need to do TLB flush + VMID re-assigning when we have more then 16 domains.

But in case of per-pCPU allocation we could run 16 domains on 1 pCPU and at the same
time in multiprocessor systems we have more pCPUs, which will allow us to run more
domains and avoid TLB flushes.
On other hand, it is needed to consider that it's unlikely that a domain will have
only one vCPU. And it is likely that amount of vCPUs will be bigger then an amount
of domains, so to have a round-robin approach (as x86) without permanent ID allocation
for each domain will work better then per-pCPU allocation.

    
      
    
      
    Here you (appear to) say one thing, ...


    
      
    
        
    In other words, I'm not 100% sure that I get a point why x86 chose per-pCPU allocation
instead of per-domain allocation with having the same VMID for all vCPUs of domains.

    
      
    
      
    ... and then here the opposite. Overall I'm in severe trouble understanding this
reply of yours as a whole, so I fear I can't really respond to it (or even just
parts thereof).
    
    
    
    
    IIUC, x86 allocates VMIDs per physical CPU (pCPU) "dynamically" — these are just
sequential numbers, and once VMIDs run out on a given pCPU, there's no guarantee
that a vCPU will receive the same VMID again.

On the other hand, RISC-V currently allocates a single VMID per domain, and that
VMID is considered "permanent" until the domain is destroyed. This means we are
limited to at most VMID_MAX domains. To avoid this limitation, I plan to implement
a round-robin reuse approach: when no free VMIDs remain, we start a new generation
and begin reusing old VMIDs.

The only remaining design question is whether we want RISC-V to follow a global
VMID allocation policy (i.e., one VMID per domain, shared across all of its vCPUs),
or adopt a policy similar to x86 with per-CPU VMID allocation (each vCPU gets its
own VMID, local to the CPU it's running on).

Each policy has its own trade-offs. But in the case where the number of available
VMIDs is small (i.e., low VMIDLEN), a global allocation policy may be more suitable,
as it requires fewer VMIDs overall.

So my main question was:
What are the advantages of per-pCPU VMID allocation in scenarios with limited VMID
space, and why did x86 choose that design?

>From what I can tell, the benefits of per-pCPU VMID allocation include:
- Minimized inter-CPU TLB flushes — since VMIDs are local, TLB entries don’t need
  to be invalidated on other CPUs when reused.
- Better scalability — this approach works better on systems with a large number
  of CPUs.
- Frequent VM switches don’t require global TLB flushes — reducing the overhead
  of context switching.
However, the downside is that this model consumes more VMIDs. For example,
if a single domain runs on 4 vCPUs across 4 CPUs, it will consume 4 VMIDs instead
of just one.

~ Oleksii

    
  


--------------Mw32BkD2nR21rsGAgsMukTKb--


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 11:43:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 11:43:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026180.1401414 (Exim 4.92)
	(envelope-from )
	id 1uUl0x-0004kT-Aw; Thu, 26 Jun 2025 11:43:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026180.1401414; Thu, 26 Jun 2025 11: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 1uUl0x-0004kM-7A; Thu, 26 Jun 2025 11:43:35 +0000
Received: by outflank-mailman (input) for mailman id 1026180;
 Thu, 26 Jun 2025 11:43: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 1uUl0w-0004kG-H8
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 11:43:34 +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 c8fa0c34-5282-11f0-b894-0df219b8e170;
 Thu, 26 Jun 2025 13:43:32 +0200 (CEST)
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 A78C71F441;
 Thu, 26 Jun 2025 11:43: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 1FC2C13188;
 Thu, 26 Jun 2025 11:43:30 +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 wsi3BWIyXWghdwAAD6G6ig
 (envelope-from ); Thu, 26 Jun 2025 11:43: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: c8fa0c34-5282-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750938210; 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=U1PHGs6u5gXVgovDdK/sHcoSlnq8syJ5n85D6SsLAPI=;
	b=PWXFpEMw6f5dlhi6ZuUASem+C9HcQmSUfBROSn2uPQMzDgUuJ8t2SbndeoMbjD8pGrpgb3
	vSaOpBXYChq9dUVWTT5TUvDFsBlBHlGYZrve5diALL5niYKmPyt8pOMKrGycGnIqUMgtVq
	V94veLUU7VClcplI1ocY9ZFvTrMAkBQ=
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=PWXFpEMw
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750938210; 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=U1PHGs6u5gXVgovDdK/sHcoSlnq8syJ5n85D6SsLAPI=;
	b=PWXFpEMw6f5dlhi6ZuUASem+C9HcQmSUfBROSn2uPQMzDgUuJ8t2SbndeoMbjD8pGrpgb3
	vSaOpBXYChq9dUVWTT5TUvDFsBlBHlGYZrve5diALL5niYKmPyt8pOMKrGycGnIqUMgtVq
	V94veLUU7VClcplI1ocY9ZFvTrMAkBQ=
Message-ID: <7c5761b5-805c-4d56-ad8c-1746540423e4@suse.com>
Date: Thu, 26 Jun 2025 13:43:29 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 03/17] xen/riscv: introduce guest domain's VMID
 allocation and manegement
To: Oleksii Kurochko ,
 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: 
 
 
 <145f71c2-643e-4839-a2ae-0bc1f049db74@gmail.com>
 <80223fe3-7403-4026-9505-8826c318fabb@suse.com>
 
 
 <1a570c32-e207-47f5-9702-a752246328a9@gmail.com>
 
 <264db0b0-43bf-4829-a5cc-ca696601349c@gmail.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: <264db0b0-43bf-4829-a5cc-ca696601349c@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------K10vCUM7dVPJ1aOi9z7jRLXY"
X-Spamd-Result: default: False [-4.91 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SIGNED_PGP(-2.00)[];
	SUSPICIOUS_RECIPS(1.50)[];
	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_UNKNOWN(0.10)[application/pgp-keys];
	MIME_BASE64_TEXT(0.10)[];
	MX_GOOD(-0.01)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[12];
	FREEMAIL_TO(0.00)[gmail.com,suse.com];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~];
	FREEMAIL_ENVRCPT(0.00)[gmail.com];
	FREEMAIL_CC(0.00)[wdc.com,gmail.com,citrix.com,vates.tech,amd.com,xen.org,kernel.org,lists.xenproject.org];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TAGGED_RCPT(0.00)[];
	DKIM_TRACE(0.00)[suse.com:+];
	HAS_ATTACHMENT(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns,suse.com:dkim,suse.com:mid]
X-Spam-Level: 
X-Spam-Flag: NO
X-Rspamd-Queue-Id: A78C71F441
X-Rspamd-Action: no action
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Score: -4.91

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------K10vCUM7dVPJ1aOi9z7jRLXY
Content-Type: multipart/mixed; boundary="------------FzgV8efe0ptC8GC9tEE9uAEC";
 protected-headers="v1"
From: Juergen Gross 
To: Oleksii Kurochko ,
 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
Message-ID: <7c5761b5-805c-4d56-ad8c-1746540423e4@suse.com>
Subject: Re: [PATCH v2 03/17] xen/riscv: introduce guest domain's VMID
 allocation and manegement
References: 
 
 
 <145f71c2-643e-4839-a2ae-0bc1f049db74@gmail.com>
 <80223fe3-7403-4026-9505-8826c318fabb@suse.com>
 
 
 <1a570c32-e207-47f5-9702-a752246328a9@gmail.com>
 
 <264db0b0-43bf-4829-a5cc-ca696601349c@gmail.com>
In-Reply-To: <264db0b0-43bf-4829-a5cc-ca696601349c@gmail.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------FzgV8efe0ptC8GC9tEE9uAEC
Content-Type: multipart/mixed; boundary="------------z0kEzZEukLClS4nK3Nm5EB00"

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

T24gMjYuMDYuMjUgMTM6MzQsIE9sZWtzaWkgS3Vyb2Noa28gd3JvdGU6DQo+IA0KPiBPbiA2
LzI2LzI1IDEyOjQxIFBNLCBKYW4gQmV1bGljaCB3cm90ZToNCj4+IE9uIDI2LjA2LjIwMjUg
MTI6MDUsIE9sZWtzaWkgS3Vyb2Noa28gd3JvdGU6DQo+Pj4gT24gNi8yNC8yNSA0OjAxIFBN
LCBKYW4gQmV1bGljaCB3cm90ZToNCj4+Pj4gT24gMjQuMDYuMjAyNSAxNTo0NywgT2xla3Np
aSBLdXJvY2hrbyB3cm90ZToNCj4+Pj4+IE9uIDYvMjQvMjUgMTI6NDQgUE0sIEphbiBCZXVs
aWNoIHdyb3RlOg0KPj4+Pj4+IE9uIDI0LjA2LjIwMjUgMTE6NDYsIE9sZWtzaWkgS3Vyb2No
a28gd3JvdGU6DQo+Pj4+Pj4+IE9uIDYvMTgvMjUgNTo0NiBQTSwgSmFuIEJldWxpY2ggd3Jv
dGU6DQo+Pj4+Pj4+PiBPbiAxMC4wNi4yMDI1IDE1OjA1LCBPbGVrc2lpIEt1cm9jaGtvIHdy
b3RlOg0KPj4+Pj4+Pj4+IC0tLSAvZGV2L251bGwNCj4+Pj4+Pj4+PiArKysgYi94ZW4vYXJj
aC9yaXNjdi9wMm0uYw0KPj4+Pj4+Pj4+IEBAIC0wLDAgKzEsMTE1IEBADQo+Pj4+Pj4+Pj4g
KyNpbmNsdWRlIDx4ZW4vYml0b3BzLmg+DQo+Pj4+Pj4+Pj4gKyNpbmNsdWRlIDx4ZW4vbGli
Lmg+DQo+Pj4+Pj4+Pj4gKyNpbmNsdWRlIDx4ZW4vc2NoZWQuaD4NCj4+Pj4+Pj4+PiArI2lu
Y2x1ZGUgPHhlbi9zcGlubG9jay5oPg0KPj4+Pj4+Pj4+ICsjaW5jbHVkZSA8eGVuL3h2bWFs
bG9jLmg+DQo+Pj4+Pj4+Pj4gKw0KPj4+Pj4+Pj4+ICsjaW5jbHVkZSA8YXNtL3AybS5oPg0K
Pj4+Pj4+Pj4+ICsjaW5jbHVkZSA8YXNtL3NiaS5oPg0KPj4+Pj4+Pj4+ICsNCj4+Pj4+Pj4+
PiArc3RhdGljIHNwaW5sb2NrX3Qgdm1pZF9hbGxvY19sb2NrID0gU1BJTl9MT0NLX1VOTE9D
S0VEOw0KPj4+Pj4+Pj4+ICsNCj4+Pj4+Pj4+PiArLyoNCj4+Pj4+Pj4+PiArICogaGdhdHAn
cyBWTUlEIGZpZWxkIGlzIDcgb3IgMTQgYml0cy4gUlY2NCBtYXkgc3VwcG9ydCAxNC1iaXQg
Vk1JRC4NCj4+Pj4+Pj4+PiArICogVXNpbmcgYSBiaXRtYXAgaGVyZSBsaW1pdHMgdXMgdG8g
MTI3ICgyXjcgLSAxKSBvciAxNjM4MyAoMl4xNCAtIDEpDQo+Pj4+Pj4+Pj4gKyAqIGNvbmN1
cnJlbnQgZG9tYWlucy4NCj4+Pj4+Pj4+IFdoaWNoIGlzIHByZXR0eSBsaW1pdGluZyBlc3Bl
Y2lhbGx5IGluIHRoZSBSVjMyIGNhc2UuIEhlbmNlIHdoeSB3ZSBkb24ndA0KPj4+Pj4+Pj4g
YXNzaWduIGEgcGVybWFuZW50IElEIHRvIFZNcyBvbiB4ODYsIGJ1dCByYXRoZXIgbWFuYWdl
IElEcyBwZXItQ1BVIChub3RlOg0KPj4+Pj4+Pj4gbm90IHBlci12Q1BVKS4NCj4+Pj4+Pj4g
R29vZCBwb2ludC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gSSBkb24ndCBiZWxpZXZlIGFueW9uZSB3
aWxsIHVzZSBSVjMyLg0KPj4+Pj4+PiBGb3IgUlY2NCwgdGhlIGF2YWlsYWJsZSBJRCBzcGFj
ZSBzZWVtcyBzdWZmaWNpZW50bHkgbGFyZ2UuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEhvd2V2ZXIs
IGlmIGl0IHR1cm5zIG91dCB0aGF0IHRoZSB2YWx1ZSBpc24ndCBsYXJnZSBlbm91Z2ggZXZl
biBmb3IgUlY2NCwNCj4+Pj4+Pj4gSSBjYW4gcmV3b3JrIGl0IHRvIG1hbmFnZSBJRHMgcGVy
IHBoeXNpY2FsIENQVS4NCj4+Pj4+Pj4gV291bGRuJ3QgdGhhdCBhcHByb2FjaCByZXN1bHQg
aW4gbW9yZSBUTEIgZW50cmllcyBiZWluZyBmbHVzaGVkIGNvbXBhcmVkDQo+Pj4+Pj4+IHRv
IHBlci12Q1BVIGFsbG9jYXRpb24sIHBvdGVudGlhbGx5IGxlYWRpbmcgdG8gc2xpZ2h0bHkg
d29yc2UgcGVyZm9ybWFuY2U/DQo+Pj4+Pj4gRGVwZW5kcyBvbiB0aGUgY29uZGl0aW9uIGZv
ciB3aGVuIHRvIGZsdXNoLiBPZiBjb3Vyc2UgcGVyZm9ybWFuY2UgaXMNCj4+Pj4+PiB1bmF2
b2lkYWJseSBnb2luZyB0byBzdWZmZXIgaWYgeW91IGhhdmUgb25seSB2ZXJ5IGZldyBWTUlE
cyB0byB1c2UuDQo+Pj4+Pj4gTmV2ZXJ0aGVsZXNzLCBhcyBpbmRpY2F0ZWQgYmVmb3JlLCB0
aGUgbW9kZWwgdXNlZCBvbiB4ODYgbWF5IGJlIGENCj4+Pj4+PiBjYW5kaWRhdGUgdG8gdXNl
IGhlcmUsIHRvby4gU2VlIGh2bV9hc2lkX2hhbmRsZV92bWVudGVyKCkgZm9yIHRoZQ0KPj4+
Pj4+IGNvcmUgKGFuZCB2ZW5kb3ItaW5kZXBlbmRlbnQpIHBhcnQgb2YgaXQuDQo+Pj4+PiBJ
SVVDLCBzbyBiYXNpY2FsbHkgaXQgaXMganVzdCBhIHJvdW5kLXJvYmluIGFuZCB3aGVuIFZN
SURzIGFyZSByYW4gb3V0DQo+Pj4+PiB0aGVuIGp1c3QgZG8gZnVsbCBndWVzdCBUTEIgZmx1
c2ggYW5kIHN0YXJ0IHRvIHJlLXVzZSBWTUlEcyBmcm9tIHRoZSBzdGFydC4NCj4+Pj4+IEl0
IG1ha2VzIHNlbnNlIHRvIG1lLCBJJ2xsIGltcGxlbWVudCBzb21ldGhpbmcgc2ltaWxhci4g
KGFzIEknbSBub3QgcmVhbGx5DQo+Pj4+PiBzdXJlIHRoYXQgd2UgbmVlZGRhdGEtPmNvcmVf
YXNpZF9nZW5lcmF0aW9uLCBwcm9iYWJseSwgSSB3aWxsIHVuZGVyc3RhbmQgaXQgYmV0dGVy
IHdoZW4NCj4+Pj4+IHN0YXJ0IHRvIGltcGxlbWVudCBpdCkNCj4+Pj4gV2VsbC4gVGhlIGZl
d2VyIFZNSUQgYml0cyB5b3UgaGF2ZSB0aGUgbW9yZSBxdWlja2x5IHlvdSB3aWxsIG5lZWQg
YSBuZXcNCj4+Pj4gZ2VuZXJhdGlvbi4gQW5kIGtlZXAgdHJhY2sgb2YgdGhlIGdlbmVyYXRp
b24geW91J3JlIGF0IHlvdSBhbHNvIG5lZWQgdG8NCj4+Pj4gdHJhY2sgdGhlIHByZXNlbnQg
bnVtYmVyIHNvbWV3aGVyZS4NCj4+Pj4NCj4+Pj4+Pj4gV2hhdCBhYm91dCB0aGVuIHRvIGFs
bG9jYXRlIFZNSUQgcGVyLWRvbWFpbj8NCj4+Pj4+PiBUaGF0J3Mgd2hhdCB5b3UncmUgZG9p
bmcgcmlnaHQgbm93LCBpc24ndCBpdD8gQW5kIHRoYXQgZ2V0cyBwcm9ibGVtYXRpYyB3aGVu
DQo+Pj4+Pj4geW91IGhhdmUgb25seSB2ZXJ5IGZldyBiaXRzIGluIGhnYXRwLlZNSUQsIGFz
IG1lbnRpb25lZCBiZWxvdy4NCj4+Pj4+IFJpZ2h0LCBJIGp1c3QgcGhyYXNlZCBteSBxdWVz
dGlvbiBwb29ybHnigJRzb3JyeSBhYm91dCB0aGF0Lg0KPj4+Pj4NCj4+Pj4+IFdoYXQgSSBt
ZWFudCB0byBhc2sgaXM6IGRvZXMgdGhlIGFwcHJvYWNoIGRlc2NyaWJlZCBhYm92ZSBhY3R1
YWxseSBkZXBlbmQgb24gd2hldGhlcg0KPj4+Pj4gVk1JRHMgYXJlIGFsbG9jYXRlZCBwZXIt
ZG9tYWluIG9yIHBlci1wQ1BVPyBJdCBzZWVtcyB0aGF0IHRoZSBtYWluIGFkdmFudGFnZSBv
Zg0KPj4+Pj4gYWxsb2NhdGluZyBWTUlEcyBwZXItcENQVSBpcyBwb3RlbnRpYWxseSByZWR1
Y2luZyB0aGUgbnVtYmVyIG9mIFRMQiBmbHVzaGVzLA0KPj4+Pj4gc2luY2UgaXQncyBtb3Jl
IGxpa2VseSB0aGF0IGEgcGxhdGZvcm0gd2lsbCBoYXZlIG1vcmUgdGhhbnxWTUlEX01BWHwg
ZG9tYWlucyB0aGFuDQo+Pj4+PiB8Vk1JRF9NQVh8IHBoeXNpY2FsIENQVXPigJRhbSBJIHJp
Z2h0Pw0KPj4+PiBTZWVpbmcgdGhhdCB0aGVyZSBjYW4gYmUgc3lzdGVtcyB3aXRoIGh1bmRy
ZWRzIG9yIGV2ZW4gdGhvdXNhbmRzIG9mIENQVXMsDQo+Pj4+IEkgZG9uJ3QgdGhpbmsgSSBj
YW4gYWdyZWUgaGVyZS4gUGx1cyBwZXItcENQVSBhbGxvY2F0aW9uIHdvdWxkIHNpbWlsYXJs
eQ0KPj4+PiBnZXQgeW91IGluIHRyb3VibGUgd2hlbiB5b3UgaGF2ZSBvbmx5IHZlcnkgZmV3
IFZNSUQgYml0cy4NCj4+PiBCdXQgbm90IHNvIGZhc3QgYXMgaW4gY2FzZSBvZiBwZXItZG9t
YWluIGFsbG9jYXRpb24sIHJpZ2h0Pw0KPj4+DQo+Pj4gSSBtZWFuIHRoYXQgaWYgd2UgaGF2
ZSBvbmx5IDQgYml0cywgdGhlbiBpbiBjYXNlIG9mIHBlci1kb21haW4gYWxsb2NhdGlvbiB3
ZSB3aWxsDQo+Pj4gbmVlZCB0byBkbyBUTEIgZmx1c2ggKyBWTUlEIHJlLWFzc2lnbmluZyB3
aGVuIHdlIGhhdmUgbW9yZSB0aGVuIDE2IGRvbWFpbnMuDQo+Pj4NCj4+PiBCdXQgaW4gY2Fz
ZSBvZiBwZXItcENQVSBhbGxvY2F0aW9uIHdlIGNvdWxkIHJ1biAxNiBkb21haW5zIG9uIDEg
cENQVSBhbmQgYXQgdGhlIHNhbWUNCj4+PiB0aW1lIGluIG11bHRpcHJvY2Vzc29yIHN5c3Rl
bXMgd2UgaGF2ZSBtb3JlIHBDUFVzLCB3aGljaCB3aWxsIGFsbG93IHVzIHRvIHJ1biBtb3Jl
DQo+Pj4gZG9tYWlucyBhbmQgYXZvaWQgVExCIGZsdXNoZXMuDQo+Pj4gT24gb3RoZXIgaGFu
ZCwgaXQgaXMgbmVlZGVkIHRvIGNvbnNpZGVyIHRoYXQgaXQncyB1bmxpa2VseSB0aGF0IGEg
ZG9tYWluIHdpbGwgaGF2ZQ0KPj4+IG9ubHkgb25lIHZDUFUuIEFuZCBpdCBpcyBsaWtlbHkg
dGhhdCBhbW91bnQgb2YgdkNQVXMgd2lsbCBiZSBiaWdnZXIgdGhlbiBhbiBhbW91bnQNCj4+
PiBvZiBkb21haW5zLCBzbyB0byBoYXZlIGEgcm91bmQtcm9iaW4gYXBwcm9hY2ggKGFzIHg4
Nikgd2l0aG91dCBwZXJtYW5lbnQgSUQgYWxsb2NhdGlvbg0KPj4+IGZvciBlYWNoIGRvbWFp
biB3aWxsIHdvcmsgYmV0dGVyIHRoZW4gcGVyLXBDUFUgYWxsb2NhdGlvbi4NCj4+IEhlcmUg
eW91IChhcHBlYXIgdG8pIHNheSBvbmUgdGhpbmcsIC4uLg0KPj4NCj4+PiBJbiBvdGhlciB3
b3JkcywgSSdtIG5vdCAxMDAlIHN1cmUgdGhhdCBJIGdldCBhIHBvaW50IHdoeSB4ODYgY2hv
c2UgcGVyLXBDUFUgYWxsb2NhdGlvbg0KPj4+IGluc3RlYWQgb2YgcGVyLWRvbWFpbiBhbGxv
Y2F0aW9uIHdpdGggaGF2aW5nIHRoZSBzYW1lIFZNSUQgZm9yIGFsbCB2Q1BVcyBvZiBkb21h
aW5zLg0KPj4gLi4uIGFuZCB0aGVuIGhlcmUgdGhlIG9wcG9zaXRlLiBPdmVyYWxsIEknbSBp
biBzZXZlcmUgdHJvdWJsZSB1bmRlcnN0YW5kaW5nIHRoaXMNCj4+IHJlcGx5IG9mIHlvdXJz
IGFzIGEgd2hvbGUsIHNvIEkgZmVhciBJIGNhbid0IHJlYWxseSByZXNwb25kIHRvIGl0IChv
ciBldmVuIGp1c3QNCj4+IHBhcnRzIHRoZXJlb2YpLg0KPiANCj4gSUlVQywgeDg2IGFsbG9j
YXRlcyBWTUlEcyBwZXIgcGh5c2ljYWwgQ1BVIChwQ1BVKSAiZHluYW1pY2FsbHkiIOKAlCB0
aGVzZSBhcmUganVzdA0KPiBzZXF1ZW50aWFsIG51bWJlcnMsIGFuZCBvbmNlIFZNSURzIHJ1
biBvdXQgb24gYSBnaXZlbiBwQ1BVLCB0aGVyZSdzIG5vIGd1YXJhbnRlZQ0KPiB0aGF0IGEg
dkNQVSB3aWxsIHJlY2VpdmUgdGhlIHNhbWUgVk1JRCBhZ2Fpbi4NCj4gDQo+IE9uIHRoZSBv
dGhlciBoYW5kLCBSSVNDLVYgY3VycmVudGx5IGFsbG9jYXRlcyBhIHNpbmdsZSBWTUlEIHBl
ciBkb21haW4sIGFuZCB0aGF0DQo+IFZNSUQgaXMgY29uc2lkZXJlZCAicGVybWFuZW50IiB1
bnRpbCB0aGUgZG9tYWluIGlzIGRlc3Ryb3llZC4gVGhpcyBtZWFucyB3ZSBhcmUNCj4gbGlt
aXRlZCB0byBhdCBtb3N0IFZNSURfTUFYIGRvbWFpbnMuIFRvIGF2b2lkIHRoaXMgbGltaXRh
dGlvbiwgSSBwbGFuIHRvIGltcGxlbWVudA0KPiBhIHJvdW5kLXJvYmluIHJldXNlIGFwcHJv
YWNoOiB3aGVuIG5vIGZyZWUgVk1JRHMgcmVtYWluLCB3ZSBzdGFydCBhIG5ldyBnZW5lcmF0
aW9uDQo+IGFuZCBiZWdpbiByZXVzaW5nIG9sZCBWTUlEcy4NCj4gDQo+IFRoZSBvbmx5IHJl
bWFpbmluZyBkZXNpZ24gcXVlc3Rpb24gaXMgd2hldGhlciB3ZSB3YW50IFJJU0MtViB0byBm
b2xsb3cgYSBnbG9iYWwNCj4gVk1JRCBhbGxvY2F0aW9uIHBvbGljeSAoaS5lLiwgb25lIFZN
SUQgcGVyIGRvbWFpbiwgc2hhcmVkIGFjcm9zcyBhbGwgb2YgaXRzIHZDUFVzKSwNCj4gb3Ig
YWRvcHQgYSBwb2xpY3kgc2ltaWxhciB0byB4ODYgd2l0aCBwZXItQ1BVIFZNSUQgYWxsb2Nh
dGlvbiAoZWFjaCB2Q1BVIGdldHMgaXRzDQo+IG93biBWTUlELCBsb2NhbCB0byB0aGUgQ1BV
IGl0J3MgcnVubmluZyBvbikuDQo+IA0KPiBFYWNoIHBvbGljeSBoYXMgaXRzIG93biB0cmFk
ZS1vZmZzLiBCdXQgaW4gdGhlIGNhc2Ugd2hlcmUgdGhlIG51bWJlciBvZiBhdmFpbGFibGUN
Cj4gVk1JRHMgaXMgc21hbGwgKGkuZS4sIGxvdyBWTUlETEVOKSwgYSBnbG9iYWwgYWxsb2Nh
dGlvbiBwb2xpY3kgbWF5IGJlIG1vcmUgc3VpdGFibGUsDQo+IGFzIGl0IHJlcXVpcmVzIGZl
d2VyIFZNSURzIG92ZXJhbGwuDQo+IA0KPiBTbyBteSBtYWluIHF1ZXN0aW9uIHdhczoNCj4g
V2hhdCBhcmUgdGhlIGFkdmFudGFnZXMgb2YgcGVyLXBDUFUgVk1JRCBhbGxvY2F0aW9uIGlu
IHNjZW5hcmlvcyB3aXRoIGxpbWl0ZWQgVk1JRA0KPiBzcGFjZSwgYW5kIHdoeSBkaWQgeDg2
IGNob29zZSB0aGF0IGRlc2lnbj8NCj4gDQo+PkZyb20gd2hhdCBJIGNhbiB0ZWxsLCB0aGUg
YmVuZWZpdHMgb2YgcGVyLXBDUFUgVk1JRCBhbGxvY2F0aW9uIGluY2x1ZGU6DQo+IC0gTWlu
aW1pemVkIGludGVyLUNQVSBUTEIgZmx1c2hlcyDigJQgc2luY2UgVk1JRHMgYXJlIGxvY2Fs
LCBUTEIgZW50cmllcyBkb27igJl0IG5lZWQNCj4gICAgdG8gYmUgaW52YWxpZGF0ZWQgb24g
b3RoZXIgQ1BVcyB3aGVuIHJldXNlZC4NCj4gLSBCZXR0ZXIgc2NhbGFiaWxpdHkg4oCUIHRo
aXMgYXBwcm9hY2ggd29ya3MgYmV0dGVyIG9uIHN5c3RlbXMgd2l0aCBhIGxhcmdlIG51bWJl
cg0KPiAgICBvZiBDUFVzLg0KPiAtIEZyZXF1ZW50IFZNIHN3aXRjaGVzIGRvbuKAmXQgcmVx
dWlyZSBnbG9iYWwgVExCIGZsdXNoZXMg4oCUIHJlZHVjaW5nIHRoZSBvdmVyaGVhZA0KPiAg
ICBvZiBjb250ZXh0IHN3aXRjaGluZy4NCj4gSG93ZXZlciwgdGhlIGRvd25zaWRlIGlzIHRo
YXQgdGhpcyBtb2RlbCBjb25zdW1lcyBtb3JlIFZNSURzLiBGb3IgZXhhbXBsZSwNCj4gaWYg
YSBzaW5nbGUgZG9tYWluIHJ1bnMgb24gNCB2Q1BVcyBhY3Jvc3MgNCBDUFVzLCBpdCB3aWxs
IGNvbnN1bWUgNCBWTUlEcyBpbnN0ZWFkDQo+IG9mIGp1c3Qgb25lLg0KDQpDb25zaWRlciB5
b3UgaGF2ZSA0IGJpdHMgZm9yIFZNSURzLCByZXN1bHRpbmcgaW4gMTYgVk1JRCB2YWx1ZXMu
DQoNCklmIHlvdSBoYXZlIGEgc3lzdGVtIHdpdGggMzIgcGh5c2ljYWwgQ1BVcyBhbmQgMzIg
ZG9tYWlucyB3aXRoIDEgdmNwdSBlYWNoDQpvbiB0aGF0IHN5c3RlbSwgeW91ciBzY2hlbWUg
d291bGQgTk9UIGFsbG93IHRvIGtlZXAgZWFjaCBwaHlzaWNhbCBjcHUgYnVzeQ0KYnkgcnVu
bmluZyBhIGRvbWFpbiBvbiBpdCwgYXMgb25seSAxNiBkb21haW5zIGNvdWxkIGJlIGFjdGl2
ZSBhdCB0aGUgc2FtZQ0KdGltZS4NCg0KDQpKdWVyZ2VuDQo=
--------------z0kEzZEukLClS4nK3Nm5EB00
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-----

--------------z0kEzZEukLClS4nK3Nm5EB00--

--------------FzgV8efe0ptC8GC9tEE9uAEC--

--------------K10vCUM7dVPJ1aOi9z7jRLXY
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/Ey8FAmhdMmEFAwAAAAAACgkQsN6d1ii/Ey+c
SQgAkE5GuUHelWcA0EyLjBASNKnHFh9gvVPlvT5AKU5rorjEf2k7Fxr4SKFODV1we3pOVthrGG6O
U2A6I0Xlka/r92R3olxN8EfxrCmu6ieObOtzITenjvKMsi4y1D8ylpAYOxTeXTP26Qp3UvRjrWbf
0A+pEfUy85Y12qx/C58AfkDT2JkW9Co6HMmO6FXYAcii6EWFTwI7640HGE2adf+VQU93vkFjA/gF
djcTyp20piM9MNlhdfzHWawDGSqOKd4uHb9pfAL5aefFmpcGttFZYeSg+ewClcPmcpoY69rU6+8S
aIFbwV3REYZKdGV/lxCAt0exEfYLIOeEH7am5S92Zw==
=0cF8
-----END PGP SIGNATURE-----

--------------K10vCUM7dVPJ1aOi9z7jRLXY--


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 11:55:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 11:55:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026206.1401424 (Exim 4.92)
	(envelope-from )
	id 1uUlCm-0006ZW-Fa; Thu, 26 Jun 2025 11:55:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026206.1401424; Thu, 26 Jun 2025 11:55: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 1uUlCm-0006ZP-Cu; Thu, 26 Jun 2025 11:55:48 +0000
Received: by outflank-mailman (input) for mailman id 1026206;
 Thu, 26 Jun 2025 11:55: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 1uUlCk-0006Z0-Sa
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 11:55:46 +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 7e3e4233-5284-11f0-a30f-13f23c93f187;
 Thu, 26 Jun 2025 13:55:45 +0200 (CEST)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-ae0a0cd709bso400753366b.0
 for ; Thu, 26 Jun 2025 04:55:45 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-60c2f1ae7basm3756934a12.25.2025.06.26.04.55.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 26 Jun 2025 04:55:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7e3e4233-5284-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750938945; x=1751543745; 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=FBJ7rmajfjnZp6vc+/rsIwGpNupfVLjB2hWKyfaFwZU=;
        b=XB1p+v1f5Iwvtuz4681VHBs3kVL6ojR9EQlNOa7nwe88htXtwEfdB04IVwKvnOzUSG
         4aiW8pLfY7w7svo/bWM5O0uBmw3cCMKoiqzkeMWIxX4d6DJpdMknTp+8h9E3rhLObKpz
         unpUbQVgekQ4tu0Ce7wUkmy+K7LAZ0cfY+M/TUBKYp48lLWVxRE6eAs2KszJtQYQpoxy
         22nkcakh4Fh9pje+rpcaSteh9u1nKgNzcw3sf+JfJM5uxaNEF9tTa/++ZZSvd0CZOmFS
         PaEsdU/eukjeTF+ziD8TgqUbEpXhok3hmqLKiZLLNkcqfjJR7p+BkYMWWPByZ/1kyksw
         vj4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750938945; x=1751543745;
        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=FBJ7rmajfjnZp6vc+/rsIwGpNupfVLjB2hWKyfaFwZU=;
        b=c6d87ZsMh4UAU7G4NPSsX5IwPGO6KBPZJuC3RUWW52Az0+8aAAMsGEk3AfO55fHccB
         RWD8KVv0GFQQ3EolHPlnNDs23DcLgpbBMXDQdl+2EAIp7a9t9c6icItE515pl3vQZqD2
         mMwQNtxERDtjZRxYXBxS029F4DQ+oQjF3qRW+UvCTEHFh0Np7syaAFh3kdpFtk+4gNdW
         pectELgdaoXTxxdz/WjgcPwn4aFTf1KcTb4WqIrJgF3nliQ/hrgXzcSSW6XVM7b2s/A+
         Ezntt9rX3AzLW2407EdQLQScSEwWhVuzL5ay/02yuSb/Fwb3Ctgcq185s9gpPpHAObxj
         a8Aw==
X-Forwarded-Encrypted: i=1; AJvYcCV93RNPRUaKe0hryejSSJGSH1eiZHH6tsRuBP3+xImubhptJxPsHlUdqc899dSaAnaUS3dpd65jphI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwFJye81CTpCiBUPP92HSQ37MTXF8yz9Exw58VUOtXG7cEznLrF
	S5x8XiSwafJaj5T1Kq6ytAhcB1R87MJPBAjbcnwBSOLRALduxbVnxy9n
X-Gm-Gg: ASbGnctFBac5zx04DhJ/WXx6nscWzSswHYyzQtmS5lFXJYQOeRLxwmkn+5E9AKRMiFz
	7n/0X6GzZ7TmXz7EGQYZq3j8/UKI3ikMzFFQxyqtKLR5tDnS0TLYnXe+kmCf+F16ndzen9HNErI
	qAPDKcobM4JuVcBqxDJpxsz6rkTlakk46TG4VRAdBJ4LXoJyQYG4kD70y7IyTlnBIcWfM8m+tbc
	CPFxYmGSL9ChdwPVc6o2zVj9njY3a1l3NOPMSOjZ0PTLr8XqhTD0UcZtYgo+fWsTixuOPMJ/R4x
	7/pB5YwNCN+H8xf9J9rua2VZiGse9Y0a5IakZkr0d/o+se4+AJ9nfXaXNvc+uQyG/n1wM2pWQko
	ERBN6XRzdtP6JEXcLvyPTlVjOcv8KwrAZPh8=
X-Google-Smtp-Source: AGHT+IGWWtesavkwF3KKfw1lMHY2khY0fHRHnHtOTWHw0mu4oBONNtgf6/XtlWaKIV6tS2wO+kwE4w==
X-Received: by 2002:a17:906:c148:b0:ae0:dc9e:2f8f with SMTP id a640c23a62f3a-ae0dc9e3079mr121264366b.23.1750938944684;
        Thu, 26 Jun 2025 04:55:44 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------xFqQBfbcP2sKFIYGmL6NCh0X"
Message-ID: 
Date: Thu, 26 Jun 2025 13:55:43 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 05/17] xen/riscv: introduce things necessary for p2m
 initialization
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: 
 <443cb3566a60dcb5d5440c72410ff6d76a010a58.1749555949.git.oleksii.kurochko@gmail.com>
 <5c61fd86-5c0e-481e-a5a9-6a53f2d78c36@suse.com>
 <0b3c403b-0f24-4fc6-ba5b-fb4df62d7057@gmail.com>
 <7cb7a46b-8d2e-4f9e-9613-f7a4199096ee@suse.com>
 <8741800f-b40b-4c42-b435-91e2f9375f6c@gmail.com>
 <1bb7c808-9383-4c51-880e-a12984d544c4@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <1bb7c808-9383-4c51-880e-a12984d544c4@suse.com>

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


On 6/26/25 1:01 PM, Jan Beulich wrote:
> On 26.06.2025 10:40, Oleksii Kurochko wrote:
>> On 6/25/25 5:53 PM, Jan Beulich wrote:
>>> On 25.06.2025 17:31, Oleksii Kurochko wrote:
>>>> On 6/18/25 6:08 PM, Jan Beulich wrote:
>>>>> On 10.06.2025 15:05, Oleksii Kurochko wrote:
>>>>>> @@ -14,6 +18,29 @@
>>>>>>     
>>>>>>     /* Per-p2m-table state */
>>>>>>     struct p2m_domain {
>>>>>> +    /*
>>>>>> +     * Lock that protects updates to the p2m.
>>>>>> +     */
>>>>>> +    rwlock_t lock;
>>>>>> +
>>>>>> +    /* Pages used to construct the p2m */
>>>>>> +    struct page_list_head pages;
>>>>>> +
>>>>>> +    /* Indicate if it is required to clean the cache when writing an entry */
>>>>>> +    bool clean_pte;
>>>>>> +
>>>>>> +    struct radix_tree_root p2m_type;
>>>>> A field with a p2m_ prefix in a p2m struct?
>>>> p2m_ prefix could be really dropped.
>>>>
>>>>>     And is this tree really about
>>>>> just a single "type"?
>>>> Yes, we don't have enough bits in PTE so we need some extra storage to store type.
>>> My question wasn't about that, though. My question was whether in the name
>>> "type" (singular) is appropriate. I didn't think you need a tree to store just
>>> a single type.
>> I need tree to store a pair of , where gfn is an index. And it seems
>> to me a tree is a good structure for fast insert/search.
> Hmm, I'm increasingly puzzled. I tried to emphasize that my question was towards
> the singular "type" in the variable name. I can't see any relationship between
> that and your reply. (And yes, using a tree here may be appropriate. There is a
> concern towards memory consumption, but that's a separate topic.)

Oh, I got your initial intention. For sure, it should be "types".

>
> Having said that, aiui you don't use the two RSW bits in the PTE. Do you have
> any plans there? If not, can't they be used to at least represent the most
> commonly used types, such that the number of entries in that tree can be kept
> (relatively) low?

It could be really an option for optimization.

In this case I have to p2m_type_t by adding a new type p2m_tree_type:
typedef enum {
     p2m_invalid = 0,    /* Nothing mapped here */
     p2m_ram_rw,         /* Normal read/write domain RAM */
     p2m_ram_ro,         /* Read-only */
     
     + p2m_tree_type,    /* The types below p2m_free_type will be stored outside PTE's bits */

     p2m_mmio_direct_dev,/* Read/write mapping of genuine Device MMIO area */
     p2m_grant_map_rw,   /* Read/write grant mapping */
     p2m_grant_map_ro,   /* Read-only grant mapping */
} p2m_type_t;

Probably, it make sense to switch p2m_ram_ro and p2m_mmio_direct_dev. I think device mapping
is more often operations.

>
>>>>>> +    /*
>>>>>> +     * Some IOMMUs don't support coherent PT walk. When the p2m is
>>>>>> +     * shared with the CPU, Xen has to make sure that the PT changes have
>>>>>> +     * reached the memory
>>>>>> +     */
>>>>>> +    p2m->clean_pte = is_iommu_enabled(d) &&
>>>>>> +        !iommu_has_feature(d, IOMMU_FEAT_COHERENT_WALK);
>>>>> The comment talks about shared page tables, yet you don't check whether
>>>>> page table sharing is actually enabled for the domain.
>>>> Do we have such function/macros?
>>> We have iommu_hap_pt_share, and we have the per-domain hap_pt_share flag.
>>>
>>>> It is shared by implementation now.
>>> I don't understand. There's no IOMMU support yet for RISC-V. Hence it's in
>>> neither state - not shared, but also not not shared.
>> In downstream there is a support of IOMMU for RISC-V.
> And there page tables are unconditionally shared? I'll be surprised if no
> want/need for non-shared page tables would ever appear.

At the moment, yes, but it isn't strict limitation. So yes, it should be page
tables should be conditionally shared.

~ Oleksii

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



  
    
  
  
    

    
    
    
    
    On 6/26/25 1:01 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 26.06.2025 10:40, Oleksii Kurochko wrote:

    
      
    
        
    On 6/25/25 5:53 PM, Jan Beulich wrote:

    
        
    
          
    On 25.06.2025 17:31, Oleksii Kurochko wrote:

    
          
    
            
    On 6/18/25 6:08 PM, Jan Beulich wrote:

    
            
    
              
    On 10.06.2025 15:05, Oleksii Kurochko wrote:

    
              
    
                
    @@ -14,6 +18,29 @@
   
   /* Per-p2m-table state */
   struct p2m_domain {
+    /*
+     * Lock that protects updates to the p2m.
+     */
+    rwlock_t lock;
+
+    /* Pages used to construct the p2m */
+    struct page_list_head pages;
+
+    /* Indicate if it is required to clean the cache when writing an entry */
+    bool clean_pte;
+
+    struct radix_tree_root p2m_type;

    
              
    
              
    A field with a p2m_ prefix in a p2m struct?

    
            
    
            
    p2m_ prefix could be really dropped.


    
            
    
              
       And is this tree really about
just a single "type"?

    
            
    
            
    Yes, we don't have enough bits in PTE so we need some extra storage to store type.

    
          
    
          
    My question wasn't about that, though. My question was whether in the name
"type" (singular) is appropriate. I didn't think you need a tree to store just
a single type.

    
        
    
        
    I need tree to store a pair of <gfn, p2m_type>, where gfn is an index. And it seems
to me a tree is a good structure for fast insert/search.

    
      
    
      
    Hmm, I'm increasingly puzzled. I tried to emphasize that my question was towards
the singular "type" in the variable name. I can't see any relationship between
that and your reply. (And yes, using a tree here may be appropriate. There is a
concern towards memory consumption, but that's a separate topic.)
    
    
    
    
    Oh, I got your initial intention. For sure, it should be "types".


    
    
    
      
    
Having said that, aiui you don't use the two RSW bits in the PTE. Do you have
any plans there? If not, can't they be used to at least represent the most
commonly used types, such that the number of entries in that tree can be kept
(relatively) low?
    
    
    
    
    It could be really an option for optimization.

In this case I have to p2m_type_t by adding a new type p2m_tree_type:
typedef enum {
    p2m_invalid = 0,    /* Nothing mapped here */
    p2m_ram_rw,         /* Normal read/write domain RAM */
    p2m_ram_ro,         /* Read-only */
    
    + p2m_tree_type,    /* The types below p2m_free_type will be stored outside PTE's bits */

    p2m_mmio_direct_dev,/* Read/write mapping of genuine Device MMIO area */
    p2m_grant_map_rw,   /* Read/write grant mapping */
    p2m_grant_map_ro,   /* Read-only grant mapping */
} p2m_type_t;

Probably, it make sense to switch p2m_ram_ro and p2m_mmio_direct_dev. I think device mapping
is more often operations.


    
    
    
      
    

    
      
    
        
    
          
    
            
    
              
    
                
    +    /*
+     * Some IOMMUs don't support coherent PT walk. When the p2m is
+     * shared with the CPU, Xen has to make sure that the PT changes have
+     * reached the memory
+     */
+    p2m->clean_pte = is_iommu_enabled(d) &&
+        !iommu_has_feature(d, IOMMU_FEAT_COHERENT_WALK);

    
              
    
              
    The comment talks about shared page tables, yet you don't check whether
page table sharing is actually enabled for the domain.

    
            
    
            
    Do we have such function/macros?

    
          
    
          
    We have iommu_hap_pt_share, and we have the per-domain hap_pt_share flag.


    
          
    
            
    It is shared by implementation now.

    
          
    
          
    I don't understand. There's no IOMMU support yet for RISC-V. Hence it's in
neither state - not shared, but also not not shared.

    
        
    
        
    In downstream there is a support of IOMMU for RISC-V.

    
      
    
      
    And there page tables are unconditionally shared? I'll be surprised if no
want/need for non-shared page tables would ever appear.
    
    
    
    
    At the moment, yes, but it isn't strict limitation. So yes, it should be page
tables should be conditionally shared.

~ Oleksii
    
  


--------------xFqQBfbcP2sKFIYGmL6NCh0X--


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 12:06:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 12:06:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026235.1401433 (Exim 4.92)
	(envelope-from )
	id 1uUlMc-0008S4-H9; Thu, 26 Jun 2025 12:05:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026235.1401433; Thu, 26 Jun 2025 12:05:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUlMc-0008Rx-ET; Thu, 26 Jun 2025 12:05:58 +0000
Received: by outflank-mailman (input) for mailman id 1026235;
 Thu, 26 Jun 2025 12:05: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 1uUlMa-0008Rr-MI
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 12:05:56 +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 e91f9df0-5285-11f0-b894-0df219b8e170;
 Thu, 26 Jun 2025 14:05:54 +0200 (CEST)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-adfb562266cso177496366b.0
 for ; Thu, 26 Jun 2025 05:05:54 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ae086a98f6dsm786885966b.32.2025.06.26.05.05.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 26 Jun 2025 05:05:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e91f9df0-5285-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750939554; x=1751544354; 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=JvqOUCz6CM/70Tu4cQNcQFaup+NPkqjq/GUJGfkTCzk=;
        b=EM2c4yh4Do0yA/3RAPZmRjagnQGWjESS865iX+SoRmYlS7GH6fjkPKvo9FXEaQELis
         dZxwLrneM3qBF1sYUS9Cjyz1EH1sAUd8f1KdIpU5BakzAEokrvYsEYmwnANR1zdtxEBf
         lGZnk8tqJhB1BM/ApTIHvpBX+A0GdFrnY7sLIndpiwKuMTiZoR/q5mA8BpnXe/FLU139
         ueQ1fwNn5TdX55NqgRVAXY88bIC5t7NzQzbohIkqDSyyRu8DVHZN/un/1JnY7GgDTV12
         9NA9Dm1wNcw2OmywasIGRTAkX3UiHPzNE4JZmc4VflrCMBbSVELEh4nMbzX0gBFiop6X
         GAKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750939554; x=1751544354;
        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=JvqOUCz6CM/70Tu4cQNcQFaup+NPkqjq/GUJGfkTCzk=;
        b=Dv1oA4LK3J3FpXgYvLdZ/iw5TzaWhuiEgnFe8SDzmovPccQavDxOGhyV5+xnHGgDTh
         QV4Mw3H/SlIioOVYJaIN/XnKWD00lJIBFGc0uSjMsL/xxG1T+qE+LHGkz9wh7LnxWWCC
         qv305EZz+6jS9fV9PpmAiUwziVLoO2uXA22Hn1jM429p/r5Od184VSfDAeVHC/hU0mhY
         uZpcN3nlanIERxwUUnqLX3sNMXk1oRF2RGL2tux71CuMKCjdiW+P8+8bmLQJ3kjauSMq
         rRiyVfih/4H/N6xcS0VGSUyM2PlM/57c5OG7Smmt3VbQNtJSCsa5E4NhkqNvIKEKS00F
         +TfA==
X-Forwarded-Encrypted: i=1; AJvYcCXxa5o8YW/r8W2ys/kCFMamdehlHM+xMcS/qJcGX8E7yYKoFonENm4WbDP/OVYzGTKbmjAgBZJdIfk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzqwH06tbh+5JxmVXctTj45q6wMwlzr7YQ6ouNfgW0lOlBr1Nuv
	lF0NHoIYkVR/oE0fvJwToHlsDZ1MPzLLBqtaw60NcvDSHJ0dB/FWt6OT
X-Gm-Gg: ASbGncsP2oACo3czFcKD7OgLlhy40/RrZPB9W33/+/hV9c7//QWkfFIDHKa9mUCxXmy
	r1FTkoxoTNtaNAofPUSmBdLP/x0lVIHBxtA/ZVvd7aPT81Imq8434cK8vyVNU5yIWjY1SzsD6KH
	glgvs9xY4CGsLabMOOS1IOVZfmFx4YVA9VOIm06R7vkaKFc3yukAxVqIOuTIiA4OnjRSaH/aBHp
	eNiAzlsD7SHDMvnM+WdqRm2mvW95BWFhNicqAFS8W+Dy2ZfuWnAKoMr3pl0V7lmHlNhy+0NxBHN
	rOvfVBL3Q3NHDAj+QczBFmhjwzWkmB5ypkxWQ54SBBPvNFM5+AIzMselE5D1S1PBKqX34M2QTd4
	NVMwzzpptmMuCQycporDSQNC7V/7DlLA4Ozo=
X-Google-Smtp-Source: AGHT+IFjCXcb0Cb3YkACgioKxbZYK9NGSnJYxawKvdBT4aUlDIWGJgMaH8jopo/yhCunOc9IZvVqzg==
X-Received: by 2002:a17:907:7e82:b0:ad8:9b5d:2c16 with SMTP id a640c23a62f3a-ae0bebe9319mr683549066b.11.1750939551748;
        Thu, 26 Jun 2025 05:05:51 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------7TZvkuo8fanFMXJhoM8Z9Rxa"
Message-ID: <817a318b-ec0d-4f1e-b29e-5f0b624a89f3@gmail.com>
Date: Thu, 26 Jun 2025 14:05:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 03/17] xen/riscv: introduce guest domain's VMID
 allocation and manegement
To: Juergen Gross , 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: 
 
 
 <145f71c2-643e-4839-a2ae-0bc1f049db74@gmail.com>
 <80223fe3-7403-4026-9505-8826c318fabb@suse.com>
 
 
 <1a570c32-e207-47f5-9702-a752246328a9@gmail.com>
 
 <264db0b0-43bf-4829-a5cc-ca696601349c@gmail.com>
 <7c5761b5-805c-4d56-ad8c-1746540423e4@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <7c5761b5-805c-4d56-ad8c-1746540423e4@suse.com>

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


On 6/26/25 1:43 PM, Juergen Gross wrote:
> On 26.06.25 13:34, Oleksii Kurochko wrote:
>>
>> On 6/26/25 12:41 PM, Jan Beulich wrote:
>>> On 26.06.2025 12:05, Oleksii Kurochko wrote:
>>>> On 6/24/25 4:01 PM, Jan Beulich wrote:
>>>>> On 24.06.2025 15:47, Oleksii Kurochko wrote:
>>>>>> On 6/24/25 12:44 PM, Jan Beulich wrote:
>>>>>>> On 24.06.2025 11:46, Oleksii Kurochko wrote:
>>>>>>>> On 6/18/25 5:46 PM, Jan Beulich wrote:
>>>>>>>>> On 10.06.2025 15:05, Oleksii Kurochko wrote:
>>>>>>>>>> --- /dev/null
>>>>>>>>>> +++ b/xen/arch/riscv/p2m.c
>>>>>>>>>> @@ -0,0 +1,115 @@
>>>>>>>>>> +#include 
>>>>>>>>>> +#include 
>>>>>>>>>> +#include 
>>>>>>>>>> +#include 
>>>>>>>>>> +#include 
>>>>>>>>>> +
>>>>>>>>>> +#include 
>>>>>>>>>> +#include 
>>>>>>>>>> +
>>>>>>>>>> +static spinlock_t vmid_alloc_lock = SPIN_LOCK_UNLOCKED;
>>>>>>>>>> +
>>>>>>>>>> +/*
>>>>>>>>>> + * hgatp's VMID field is 7 or 14 bits. RV64 may support 
>>>>>>>>>> 14-bit VMID.
>>>>>>>>>> + * Using a bitmap here limits us to 127 (2^7 - 1) or 16383 
>>>>>>>>>> (2^14 - 1)
>>>>>>>>>> + * concurrent domains.
>>>>>>>>> Which is pretty limiting especially in the RV32 case. Hence 
>>>>>>>>> why we don't
>>>>>>>>> assign a permanent ID to VMs on x86, but rather manage IDs 
>>>>>>>>> per-CPU (note:
>>>>>>>>> not per-vCPU).
>>>>>>>> Good point.
>>>>>>>>
>>>>>>>> I don't believe anyone will use RV32.
>>>>>>>> For RV64, the available ID space seems sufficiently large.
>>>>>>>>
>>>>>>>> However, if it turns out that the value isn't large enough even 
>>>>>>>> for RV64,
>>>>>>>> I can rework it to manage IDs per physical CPU.
>>>>>>>> Wouldn't that approach result in more TLB entries being flushed 
>>>>>>>> compared
>>>>>>>> to per-vCPU allocation, potentially leading to slightly worse 
>>>>>>>> performance?
>>>>>>> Depends on the condition for when to flush. Of course 
>>>>>>> performance is
>>>>>>> unavoidably going to suffer if you have only very few VMIDs to use.
>>>>>>> Nevertheless, as indicated before, the model used on x86 may be a
>>>>>>> candidate to use here, too. See hvm_asid_handle_vmenter() for the
>>>>>>> core (and vendor-independent) part of it.
>>>>>> IIUC, so basically it is just a round-robin and when VMIDs are 
>>>>>> ran out
>>>>>> then just do full guest TLB flush and start to re-use VMIDs from 
>>>>>> the start.
>>>>>> It makes sense to me, I'll implement something similar. (as I'm 
>>>>>> not really
>>>>>> sure that we needdata->core_asid_generation, probably, I will 
>>>>>> understand it better when
>>>>>> start to implement it)
>>>>> Well. The fewer VMID bits you have the more quickly you will need 
>>>>> a new
>>>>> generation. And keep track of the generation you're at you also 
>>>>> need to
>>>>> track the present number somewhere.
>>>>>
>>>>>>>> What about then to allocate VMID per-domain?
>>>>>>> That's what you're doing right now, isn't it? And that gets 
>>>>>>> problematic when
>>>>>>> you have only very few bits in hgatp.VMID, as mentioned below.
>>>>>> Right, I just phrased my question poorly—sorry about that.
>>>>>>
>>>>>> What I meant to ask is: does the approach described above 
>>>>>> actually depend on whether
>>>>>> VMIDs are allocated per-domain or per-pCPU? It seems that the 
>>>>>> main advantage of
>>>>>> allocating VMIDs per-pCPU is potentially reducing the number of 
>>>>>> TLB flushes,
>>>>>> since it's more likely that a platform will have more 
>>>>>> than|VMID_MAX| domains than
>>>>>> |VMID_MAX| physical CPUs—am I right?
>>>>> Seeing that there can be systems with hundreds or even thousands 
>>>>> of CPUs,
>>>>> I don't think I can agree here. Plus per-pCPU allocation would 
>>>>> similarly
>>>>> get you in trouble when you have only very few VMID bits.
>>>> But not so fast as in case of per-domain allocation, right?
>>>>
>>>> I mean that if we have only 4 bits, then in case of per-domain 
>>>> allocation we will
>>>> need to do TLB flush + VMID re-assigning when we have more then 16 
>>>> domains.
>>>>
>>>> But in case of per-pCPU allocation we could run 16 domains on 1 
>>>> pCPU and at the same
>>>> time in multiprocessor systems we have more pCPUs, which will allow 
>>>> us to run more
>>>> domains and avoid TLB flushes.
>>>> On other hand, it is needed to consider that it's unlikely that a 
>>>> domain will have
>>>> only one vCPU. And it is likely that amount of vCPUs will be bigger 
>>>> then an amount
>>>> of domains, so to have a round-robin approach (as x86) without 
>>>> permanent ID allocation
>>>> for each domain will work better then per-pCPU allocation.
>>> Here you (appear to) say one thing, ...
>>>
>>>> In other words, I'm not 100% sure that I get a point why x86 chose 
>>>> per-pCPU allocation
>>>> instead of per-domain allocation with having the same VMID for all 
>>>> vCPUs of domains.
>>> ... and then here the opposite. Overall I'm in severe trouble 
>>> understanding this
>>> reply of yours as a whole, so I fear I can't really respond to it 
>>> (or even just
>>> parts thereof).
>>
>> IIUC, x86 allocates VMIDs per physical CPU (pCPU) "dynamically" — 
>> these are just
>> sequential numbers, and once VMIDs run out on a given pCPU, there's 
>> no guarantee
>> that a vCPU will receive the same VMID again.
>>
>> On the other hand, RISC-V currently allocates a single VMID per 
>> domain, and that
>> VMID is considered "permanent" until the domain is destroyed. This 
>> means we are
>> limited to at most VMID_MAX domains. To avoid this limitation, I plan 
>> to implement
>> a round-robin reuse approach: when no free VMIDs remain, we start a 
>> new generation
>> and begin reusing old VMIDs.
>>
>> The only remaining design question is whether we want RISC-V to 
>> follow a global
>> VMID allocation policy (i.e., one VMID per domain, shared across all 
>> of its vCPUs),
>> or adopt a policy similar to x86 with per-CPU VMID allocation (each 
>> vCPU gets its
>> own VMID, local to the CPU it's running on).
>>
>> Each policy has its own trade-offs. But in the case where the number 
>> of available
>> VMIDs is small (i.e., low VMIDLEN), a global allocation policy may be 
>> more suitable,
>> as it requires fewer VMIDs overall.
>>
>> So my main question was:
>> What are the advantages of per-pCPU VMID allocation in scenarios with 
>> limited VMID
>> space, and why did x86 choose that design?
>>
>>> From what I can tell, the benefits of per-pCPU VMID allocation include:
>> - Minimized inter-CPU TLB flushes — since VMIDs are local, TLB 
>> entries don’t need
>>    to be invalidated on other CPUs when reused.
>> - Better scalability — this approach works better on systems with a 
>> large number
>>    of CPUs.
>> - Frequent VM switches don’t require global TLB flushes — reducing 
>> the overhead
>>    of context switching.
>> However, the downside is that this model consumes more VMIDs. For 
>> example,
>> if a single domain runs on 4 vCPUs across 4 CPUs, it will consume 4 
>> VMIDs instead
>> of just one.
>
> Consider you have 4 bits for VMIDs, resulting in 16 VMID values.
>
> If you have a system with 32 physical CPUs and 32 domains with 1 vcpu 
> each
> on that system, your scheme would NOT allow to keep each physical cpu 
> busy
> by running a domain on it, as only 16 domains could be active at the same
> time.

It makes sense to me.

Thanks.

~ Oleksii

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



  
    
  
  
    

    
    
    
    
    On 6/26/25 1:43 PM, Juergen Gross
      wrote:
    
    
    
    
    On
      26.06.25 13:34, Oleksii Kurochko wrote:
      
    
      
    
        
    
        On 6/26/25 12:41 PM, Jan Beulich wrote:
        
    
        
    On 26.06.2025 12:05, Oleksii Kurochko
          wrote:
          
    
          
    On 6/24/25 4:01 PM, Jan Beulich wrote:
            
    
            
    On 24.06.2025 15:47, Oleksii
              Kurochko wrote:
              
    
              
    On 6/24/25 12:44 PM, Jan Beulich
                wrote:
                
    
                
    On 24.06.2025 11:46, Oleksii
                  Kurochko wrote:
                  
    
                  
    On 6/18/25 5:46 PM, Jan
                    Beulich wrote:
                    
    
                    
    On 10.06.2025 15:05, Oleksii
                      Kurochko wrote:
                      
    
                      
    --- /dev/null
                        
    
                        +++ b/xen/arch/riscv/p2m.c
                        
    
                        @@ -0,0 +1,115 @@
                        
    
                        +#include <xen/bitops.h>
                        
    
                        +#include <xen/lib.h>
                        
    
                        +#include <xen/sched.h>
                        
    
                        +#include <xen/spinlock.h>
                        
    
                        +#include <xen/xvmalloc.h>
                        
    
                        +
                        
    
                        +#include <asm/p2m.h>
                        
    
                        +#include <asm/sbi.h>
                        
    
                        +
                        
    
                        +static spinlock_t vmid_alloc_lock =
                        SPIN_LOCK_UNLOCKED;
                        
    
                        +
                        
    
                        +/*
                        
    
                        + * hgatp's VMID field is 7 or 14 bits. RV64 may
                        support 14-bit VMID.
                        
    
                        + * Using a bitmap here limits us to 127 (2^7 -
                        1) or 16383 (2^14 - 1)
                        
    
                        + * concurrent domains.
                        
    
                      
    
                      Which is pretty limiting especially in the RV32
                      case. Hence why we don't
                      
    
                      assign a permanent ID to VMs on x86, but rather
                      manage IDs per-CPU (note:
                      
    
                      not per-vCPU).
                      
    
                    
    
                    Good point.
                    
    
                    
    
                    I don't believe anyone will use RV32.
                    
    
                    For RV64, the available ID space seems sufficiently
                    large.
                    
    
                    
    
                    However, if it turns out that the value isn't large
                    enough even for RV64,
                    
    
                    I can rework it to manage IDs per physical CPU.
                    
    
                    Wouldn't that approach result in more TLB entries
                    being flushed compared
                    
    
                    to per-vCPU allocation, potentially leading to
                    slightly worse performance?
                    
    
                  
    
                  Depends on the condition for when to flush. Of course
                  performance is
                  
    
                  unavoidably going to suffer if you have only very few
                  VMIDs to use.
                  
    
                  Nevertheless, as indicated before, the model used on
                  x86 may be a
                  
    
                  candidate to use here, too. See
                  hvm_asid_handle_vmenter() for the
                  
    
                  core (and vendor-independent) part of it.
                  
    
                
    
                IIUC, so basically it is just a round-robin and when
                VMIDs are ran out
                
    
                then just do full guest TLB flush and start to re-use
                VMIDs from the start.
                
    
                It makes sense to me, I'll implement something similar.
                (as I'm not really
                
    
                sure that we needdata->core_asid_generation,
                probably, I will understand it better when
                
    
                start to implement it)
                
    
              
    
              Well. The fewer VMID bits you have the more quickly you
              will need a new
              
    
              generation. And keep track of the generation you're at you
              also need to
              
    
              track the present number somewhere.
              
    
              
    
              
    
                
    
                  
    What about then to allocate
                    VMID per-domain?
                    
    
                  
    
                  That's what you're doing right now, isn't it? And that
                  gets problematic when
                  
    
                  you have only very few bits in hgatp.VMID, as
                  mentioned below.
                  
    
                
    
                Right, I just phrased my question poorly—sorry about
                that.
                
    
                
    
                What I meant to ask is: does the approach described
                above actually depend on whether
                
    
                VMIDs are allocated per-domain or per-pCPU? It seems
                that the main advantage of
                
    
                allocating VMIDs per-pCPU is potentially reducing the
                number of TLB flushes,
                
    
                since it's more likely that a platform will have more
                than|VMID_MAX| domains than
                
    
                |VMID_MAX| physical CPUs—am I right?
                
    
              
    
              Seeing that there can be systems with hundreds or even
              thousands of CPUs,
              
    
              I don't think I can agree here. Plus per-pCPU allocation
              would similarly
              
    
              get you in trouble when you have only very few VMID bits.
              
    
            
    
            But not so fast as in case of per-domain allocation, right?
            
    
            
    
            I mean that if we have only 4 bits, then in case of
            per-domain allocation we will
            
    
            need to do TLB flush + VMID re-assigning when we have more
            then 16 domains.
            
    
            
    
            But in case of per-pCPU allocation we could run 16 domains
            on 1 pCPU and at the same
            
    
            time in multiprocessor systems we have more pCPUs, which
            will allow us to run more
            
    
            domains and avoid TLB flushes.
            
    
            On other hand, it is needed to consider that it's unlikely
            that a domain will have
            
    
            only one vCPU. And it is likely that amount of vCPUs will be
            bigger then an amount
            
    
            of domains, so to have a round-robin approach (as x86)
            without permanent ID allocation
            
    
            for each domain will work better then per-pCPU allocation.
            
    
          
    
          Here you (appear to) say one thing, ...
          
    
          
    
          
    In other words, I'm not 100% sure that
            I get a point why x86 chose per-pCPU allocation
            
    
            instead of per-domain allocation with having the same VMID
            for all vCPUs of domains.
            
    
          
    
          ... and then here the opposite. Overall I'm in severe trouble
          understanding this
          
    
          reply of yours as a whole, so I fear I can't really respond to
          it (or even just
          
    
          parts thereof).
          
    
        
    
        
    
        IIUC, x86 allocates VMIDs per physical CPU (pCPU) "dynamically"
        — these are just
        
    
        sequential numbers, and once VMIDs run out on a given pCPU,
        there's no guarantee
        
    
        that a vCPU will receive the same VMID again.
        
    
        
    
        On the other hand, RISC-V currently allocates a single VMID per
        domain, and that
        
    
        VMID is considered "permanent" until the domain is destroyed.
        This means we are
        
    
        limited to at most VMID_MAX domains. To avoid this limitation, I
        plan to implement
        
    
        a round-robin reuse approach: when no free VMIDs remain, we
        start a new generation
        
    
        and begin reusing old VMIDs.
        
    
        
    
        The only remaining design question is whether we want RISC-V to
        follow a global
        
    
        VMID allocation policy (i.e., one VMID per domain, shared across
        all of its vCPUs),
        
    
        or adopt a policy similar to x86 with per-CPU VMID allocation
        (each vCPU gets its
        
    
        own VMID, local to the CPU it's running on).
        
    
        
    
        Each policy has its own trade-offs. But in the case where the
        number of available
        
    
        VMIDs is small (i.e., low VMIDLEN), a global allocation policy
        may be more suitable,
        
    
        as it requires fewer VMIDs overall.
        
    
        
    
        So my main question was:
        
    
        What are the advantages of per-pCPU VMID allocation in scenarios
        with limited VMID
        
    
        space, and why did x86 choose that design?
        
    
        
    
        
    From what I can tell, the benefits of
          per-pCPU VMID allocation include:
          
    
        
    
        - Minimized inter-CPU TLB flushes — since VMIDs are local, TLB
        entries don’t need
        
    
           to be invalidated on other CPUs when reused.
        
    
        - Better scalability — this approach works better on systems
        with a large number
        
    
           of CPUs.
        
    
        - Frequent VM switches don’t require global TLB flushes —
        reducing the overhead
        
    
           of context switching.
        
    
        However, the downside is that this model consumes more VMIDs.
        For example,
        
    
        if a single domain runs on 4 vCPUs across 4 CPUs, it will
        consume 4 VMIDs instead
        
    
        of just one.
        
    
      
    
      
    
      Consider you have 4 bits for VMIDs, resulting in 16 VMID values.
      
    
      
    
      If you have a system with 32 physical CPUs and 32 domains with 1
      vcpu each
      
    
      on that system, your scheme would NOT allow to keep each physical
      cpu busy
      
    
      by running a domain on it, as only 16 domains could be active at
      the same
      
    
      time.
      
    
    
    
    
    It makes sense to me.

Thanks.

    
    
    ~ Oleksii

    
  


--------------7TZvkuo8fanFMXJhoM8Z9Rxa--


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 12:06:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 12:06:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026242.1401444 (Exim 4.92)
	(envelope-from )
	id 1uUlNQ-0000UA-Q9; Thu, 26 Jun 2025 12:06:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026242.1401444; Thu, 26 Jun 2025 12: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 1uUlNQ-0000U3-MG; Thu, 26 Jun 2025 12:06:48 +0000
Received: by outflank-mailman (input) for mailman id 1026242;
 Thu, 26 Jun 2025 12: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 1uUlNO-0000P7-Tw
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 12:06:46 +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 07c3595a-5286-11f0-a30f-13f23c93f187;
 Thu, 26 Jun 2025 14:06:46 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a548a73ff2so859667f8f.0
 for ; Thu, 26 Jun 2025 05:06:46 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-315f5386e67sm4324596a91.3.2025.06.26.05.06.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 26 Jun 2025 05:06:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 07c3595a-5286-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750939605; x=1751544405; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=dcdunHN2ZTZuC2Jvl8j4xdpkRodv1OL3Trto6r3lA4A=;
        b=InztHen6+KkMCLduBQVr081U6w0nuFsMUT8mrumMylN6F/lhJg00Z6Tdty8kRkZ1Fu
         0YFNuk2bKUdztbINfBaRTElVR1o7OSN8fK1O71isTuAEKD/nTQLnf47Ty604+2dO8AIb
         YqRcHJTapDVj2M/nqukJrW+ASpGvzbkgSQgCNzBeq7vXs50sZcNyv5k8kyQaSZESgOvL
         F06xAEwXx74enddzuPOgaoZ2OY/k2FpFiw37A25JJYRsb1C3fpoz+Lx4Y7iMREmBs2g1
         /Xyd7Vi3OatEvH5PN45L1engIxNWRrijN85PKl+7KscjKz+DYGQabl0V7/aMgnRR/xV1
         HuHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750939605; x=1751544405;
        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=dcdunHN2ZTZuC2Jvl8j4xdpkRodv1OL3Trto6r3lA4A=;
        b=OaMx01YcnXHVp7X/wVspFkFWv9iZf9dekimmVcIAKJKoBQWRr8nimheRKkkX/DofSu
         gQQeu8NKdspl3ftEiLJ2YOfnUXiyeO0tkUMcNWD6tL58gjfe+W7qU+cHZJYkE3uf5nix
         WpTSOeLaoy95CMynGEJCVqn2vy2lUTlohTpl8oDkXZExf98WxXDSVJvL1jZLAmplvvEJ
         v+CqHdgZRvhzIYBGTP/q7UfDx7f2GlBDANyv7TStYlO8kMEyw6sjERpzC+5GwzA8Z7mt
         GbSpM0pvo9dJG8VlRvof6uCJ8yqnB6w5pyIsJ36xk4t1TlIFQ62yFCSLsrzBbXkob39c
         TYMQ==
X-Forwarded-Encrypted: i=1; AJvYcCXwGSaglt8uyDdnE2SgqSyo0U33vjpph+6zqSxtInXdQnc7bFMn8kmEJQAWYIaQbGv4ZHNfypkbZ50=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywh0plPkvQFw9IDDEGl6I4PYUY3uKu8lyjc0hPjfg+jzZDNlWGT
	MsDTdpc2L+zbbJ0/umytgcYvKf2zvZDl0CktGoWwSR/dSR5K9yB1ZZzMkHcVdHyH6g==
X-Gm-Gg: ASbGncuFy9EObLxc2+YHMKVVcJ372+VpKcRj7K5O03hNKrV2BjQ7lFiJsz+8SqnovO7
	/iKKf79Z9h0V84+1ZKi3DgTw76qHlrWbwABU7UF5WMQXptDycQ8l/4puR1gvuS65/cVlnRisDpJ
	H078902549eGxDIomr/II5S3Vjrgy952pRG2p0oPoqFXhoLcqtUlWdixrmwTuI8QZFuTdHAZzqi
	3QDSyYI2ur2+LcTKBDMS9uLmATxLo20NaZUOjmWOnBV4/Xh3RjKsqxAh3A0uAa+a0V7fAbdlprW
	UlDkKANjANWeTDqX4X19KWEdU1A+4PCDVTBITRMXeDzBnt7LpEztG9gRR2oxHJ3uXiv4bQtFweo
	lOLjw5xVEt6Lr9AhC+tGgthNrSEiBnIyAtKezj2aBfXwYXdJXKZdFBLbtXw==
X-Google-Smtp-Source: AGHT+IEB++qs8mTz710/kOIXzFLiiseR8vhzbMPicNBhE9z82aNEVjVlyP7FbWjs7H8Ama9ZBq/c4w==
X-Received: by 2002:a05:6000:2dc6:b0:3a6:ec1b:5742 with SMTP id ffacd0b85a97d-3a6ed5dd5famr5724727f8f.22.1750939605145;
        Thu, 26 Jun 2025 05:06:45 -0700 (PDT)
Message-ID: 
Date: Thu, 26 Jun 2025 14:06:35 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
To: "Chen, Jiqian" 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Andrew Cooper ,
 Anthony PERARD ,
 "Orzel, Michal" , Julien Grall ,
 Stefano Stabellini ,
 "xen-devel@lists.xenproject.org" ,
 "Huang, Ray" 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <516a3adc-320d-46ce-b235-8ef91469abcf@suse.com>
 
 <227df6d3-a2c3-4576-bde9-d8057c378e7a@suse.com>
 
 <5c4b186e-686e-4fc8-bcf1-854bc1f5ec8b@suse.com>
 
 <9d5d0e44-66c3-4e3f-8704-2c862c5f5aff@suse.com>
 
 <3638e73c-2a83-4164-9a84-839245245727@suse.com>
 
 <771cd5b7-2b89-49b1-9aba-8cd79319d3ce@suse.com>
 
 <7753470a-efef-478a-bbe5-ae48d008cfdb@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 26.06.2025 10:03, Chen, Jiqian wrote:
> On 2025/6/25 22:07, Jan Beulich wrote:
>> On 25.06.2025 12:16, Chen, Jiqian wrote:
>>> On 2025/6/25 18:03, Jan Beulich wrote:
>>>> Also, as said - you will need to check whether other architectures are
>>>> different from x86-64 in this regard. We better wouldn't leave a trap here,
>>>> for them to fall into when they enable vPCI support. I.e. my recommendation
>>>> would be that if in doubt, we put the __aligned() there unconditionally.

Note how I used __aligned() here. Why would you ...

>>> That's difficult for me to check on all different platforms since I don't have them all.
>>
>> You don't need to have them. You'd need to carefully go through the respective
>> section(s) of their psABI-s.
>>
>>> So you mean I should remove "#ifdef CONFIG_X86"? Just let __aligned(16) for all platforms?
>>
>> Yes. And, as also said, with a suitable comment please.
> Ah, my comment definitely needs your change suggestion.
> I wrote a draft as below:
> 
> /*
>  * Size of vpci_capability is lager than 8 bytes. When it is used as the entry
>  * of __start_vpci_array in section, it is 16-byte aligned by assembler, that
>  * causes the array length (__end_vpci_array - __start_vpci_array) wrong, so
>  * force its definition to use 16-byte aligned here.
>  */
> struct vpci_capability {
>     unsigned int id;
>     bool is_ext;
>     int (* init)(const struct pci_dev *pdev);
>     int (* cleanup)(const struct pci_dev *pdev);
> } __attribute__((aligned(16)));

... open-code that here?

As to the comment: First, it wants to be as close to what is being commented as
possible. Hence

struct __aligned(16) vpci_capability {

is likely the better placement. Second, there's nothing here the assembler does
on its own. It's the compiler which does something (insert alignment directives),
and only to follow certain rules. (See "x86: don't have gcc over-align data"
that I Cc-ed you on for some of the relevant aspects.) That is, you don't want
to "blame" any part of the tool chain, at least not where it's the underlying
ABI that mandates certain behavior. There's also no strong need to talk about
the specific effects that it would have if we didn't arrange things properly.
That is, talking about the effect on arrays in general is fine and helpful.
Talking about __{start,end}_vpci_array imo is not.

While further playing with the compiler, I noticed that adding __aligned(16)
actually has a negative effect as long as that other patch isn't in use: The
struct instances then are being aligned to even 32-byte boundaries (which means
__start_vpci_array would then also need aligning as much). When that other
patch is in use, the __aligned() becomes unnecessary. Therefore I'm no longer
convinced using __aligned() is the best solution here. Instead I think you want
to base your patch on top of mine. Which in turn would eliminate the need for
any commentary here.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 12:16:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 12:16:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026255.1401454 (Exim 4.92)
	(envelope-from )
	id 1uUlX1-0002Q6-Pd; Thu, 26 Jun 2025 12:16:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026255.1401454; Thu, 26 Jun 2025 12:16: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 1uUlX1-0002Pz-Mj; Thu, 26 Jun 2025 12:16:43 +0000
Received: by outflank-mailman (input) for mailman id 1026255;
 Thu, 26 Jun 2025 12:16: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 1uUlX0-0002Pr-Gf
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 12:16:42 +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 6a36632b-5287-11f0-a30f-13f23c93f187;
 Thu, 26 Jun 2025 14:16:40 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a4fd1ba177so668200f8f.0
 for ; Thu, 26 Jun 2025 05:16:40 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-315f54417f7sm4496103a91.45.2025.06.26.05.16.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 26 Jun 2025 05:16:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6a36632b-5287-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750940200; x=1751545000; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=HGEsWebFUXiN/3IEv6Xxi8z7pzk1iGYRvyBnFPVTlno=;
        b=N8mGjhRQFhxZeiypDgWN1M8m1/GtAHwd99RC62lbJ7F54NSnrafXE/zUupjdPUF8qA
         5qxcpqDEJixYykYeZRQmtuOFFuwifPAZsT7jMZpG7H1rckhdkGC2lnKDr3/0xlTtM+iw
         EqrCRA0Go8WnzvvY4e3fr0hUH2nJgXkur5WUaYgvJl5dKNLuELImiB6vHEXfinZ7tXc4
         qkMl/FOs8yXbzIgVhQ60l89q/IOgcSKUJzJvIi+3Lhg+faMUyDIGYzmwD3XU4SMSr4Do
         gsUB4d68xyexCdi7CS8Sl51Hzkj37nj6bxYu+m6GlnfjpWPc2YsYCqZpvI6hoHvQ7/HE
         YLTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750940200; x=1751545000;
        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=HGEsWebFUXiN/3IEv6Xxi8z7pzk1iGYRvyBnFPVTlno=;
        b=e3/R4ZP7v3Z8ULGOX/Jv8KfpxizR7mLODtIk8N0YXA7XEqBKaesTbol95WvILHym4m
         +OWFH9XyUxL5GI9/m5MlevV3/K9bnhflLAq1YUTosLYBhwVBaj+svknTiYu5oFDBZ/39
         g666iOf1fXWKOoIeIsA5ktkJSwhUxqDcvkLVxmuMMcKrbDqUW4snHk7maalyxakpenh8
         HHl1slrqRXryEGKIC4x9GMf6BSxCXZkq/xd+IXHSCow2Og/cQsrhMqb/Xj+JCMFnj2eD
         gbKNKC+q9/1y9/yIlPaO6T2NAmJeWBil2O+LlBXAqDqg4iC5rzHIB3VZ3wjia+eJCgjz
         LPKg==
X-Forwarded-Encrypted: i=1; AJvYcCWAdrjQwbMdxR+JQnugEtBKJGblSHhdwkU6DSRjNydZ6eWuXdw54hc0xo6NRDfaqt2woGw+Okju5Kc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxywxsGgyJJlAZ3rERX6TfRl6kqQQHjj6PGrbbwkiwYXIHE1VwQ
	4DIR/+eK8uh2pKwQ14WYWNVKc+cOJM/IdJaKCG9M2zONgz+/jHAPD2zAugZcbQMA5g==
X-Gm-Gg: ASbGncsWreGk7BCT3EFJ9QGRFbs6D8I5FA6if4zxNk+9bmNSl/ovwlcDvI54lt3cCV+
	k+XdlU5WpCPahW5e9khvhk9YkM5K5yl1IQ0HVglZbdEvl2B/18eJQNpwqOFS/eZ6vapt1+0/yVM
	rv7t08unwPJPnCi8D1h0k9Bt0Y0OkvJvyZPOOVgSp7Jh9XFhUhfXuPilucwo5vdFNVyFy68hIwP
	qss+p8RmswfcJp4gKfNY6uqNLi0/TSwpcc3KbIeNy+VKAQYtePKObKAyrRsspHiP1YsmxXAyqHF
	qX9Uxy1oc3vIsyoGw8NkGgqkCu5pOlkPAwTeVKcf57/qxPRFNsH+upfcSx482+y9kGHCI/d+Lqo
	orHEZ8eHE6Q59oYx0XTf89z3uOIunpdA5c+AzOvav5WpZYpJHkV8EMTy3kQ==
X-Google-Smtp-Source: AGHT+IE7M2lpksZJsGvCMlis+EDtuTpFTG0bDAkbeziXEFn9O7H6FOB4f646ZbdiraFWwvSSN0QCvQ==
X-Received: by 2002:a05:6000:230f:b0:3a5:24cc:6d5e with SMTP id ffacd0b85a97d-3a6f30fc1admr2940608f8f.3.1750940199691;
        Thu, 26 Jun 2025 05:16:39 -0700 (PDT)
Message-ID: 
Date: Thu, 26 Jun 2025 14:16:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 03/17] xen/riscv: introduce guest domain's VMID
 allocation and manegement
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: 
 
 
 <145f71c2-643e-4839-a2ae-0bc1f049db74@gmail.com>
 <80223fe3-7403-4026-9505-8826c318fabb@suse.com>
 
 
 <1a570c32-e207-47f5-9702-a752246328a9@gmail.com>
 
 <264db0b0-43bf-4829-a5cc-ca696601349c@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: <264db0b0-43bf-4829-a5cc-ca696601349c@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 26.06.2025 13:34, Oleksii Kurochko wrote:
> 
> On 6/26/25 12:41 PM, Jan Beulich wrote:
>> On 26.06.2025 12:05, Oleksii Kurochko wrote:
>>> On 6/24/25 4:01 PM, Jan Beulich wrote:
>>>> On 24.06.2025 15:47, Oleksii Kurochko wrote:
>>>>> On 6/24/25 12:44 PM, Jan Beulich wrote:
>>>>>> On 24.06.2025 11:46, Oleksii Kurochko wrote:
>>>>>>> On 6/18/25 5:46 PM, Jan Beulich wrote:
>>>>>>>> On 10.06.2025 15:05, Oleksii Kurochko wrote:
>>>>>>>>> --- /dev/null
>>>>>>>>> +++ b/xen/arch/riscv/p2m.c
>>>>>>>>> @@ -0,0 +1,115 @@
>>>>>>>>> +#include 
>>>>>>>>> +#include 
>>>>>>>>> +#include 
>>>>>>>>> +#include 
>>>>>>>>> +#include 
>>>>>>>>> +
>>>>>>>>> +#include 
>>>>>>>>> +#include 
>>>>>>>>> +
>>>>>>>>> +static spinlock_t vmid_alloc_lock = SPIN_LOCK_UNLOCKED;
>>>>>>>>> +
>>>>>>>>> +/*
>>>>>>>>> + * hgatp's VMID field is 7 or 14 bits. RV64 may support 14-bit VMID.
>>>>>>>>> + * Using a bitmap here limits us to 127 (2^7 - 1) or 16383 (2^14 - 1)
>>>>>>>>> + * concurrent domains.
>>>>>>>> Which is pretty limiting especially in the RV32 case. Hence why we don't
>>>>>>>> assign a permanent ID to VMs on x86, but rather manage IDs per-CPU (note:
>>>>>>>> not per-vCPU).
>>>>>>> Good point.
>>>>>>>
>>>>>>> I don't believe anyone will use RV32.
>>>>>>> For RV64, the available ID space seems sufficiently large.
>>>>>>>
>>>>>>> However, if it turns out that the value isn't large enough even for RV64,
>>>>>>> I can rework it to manage IDs per physical CPU.
>>>>>>> Wouldn't that approach result in more TLB entries being flushed compared
>>>>>>> to per-vCPU allocation, potentially leading to slightly worse performance?
>>>>>> Depends on the condition for when to flush. Of course performance is
>>>>>> unavoidably going to suffer if you have only very few VMIDs to use.
>>>>>> Nevertheless, as indicated before, the model used on x86 may be a
>>>>>> candidate to use here, too. See hvm_asid_handle_vmenter() for the
>>>>>> core (and vendor-independent) part of it.
>>>>> IIUC, so basically it is just a round-robin and when VMIDs are ran out
>>>>> then just do full guest TLB flush and start to re-use VMIDs from the start.
>>>>> It makes sense to me, I'll implement something similar. (as I'm not really
>>>>> sure that we needdata->core_asid_generation, probably, I will understand it better when
>>>>> start to implement it)
>>>> Well. The fewer VMID bits you have the more quickly you will need a new
>>>> generation. And keep track of the generation you're at you also need to
>>>> track the present number somewhere.
>>>>
>>>>>>> What about then to allocate VMID per-domain?
>>>>>> That's what you're doing right now, isn't it? And that gets problematic when
>>>>>> you have only very few bits in hgatp.VMID, as mentioned below.
>>>>> Right, I just phrased my question poorly—sorry about that.
>>>>>
>>>>> What I meant to ask is: does the approach described above actually depend on whether
>>>>> VMIDs are allocated per-domain or per-pCPU? It seems that the main advantage of
>>>>> allocating VMIDs per-pCPU is potentially reducing the number of TLB flushes,
>>>>> since it's more likely that a platform will have more than|VMID_MAX| domains than
>>>>> |VMID_MAX| physical CPUs—am I right?
>>>> Seeing that there can be systems with hundreds or even thousands of CPUs,
>>>> I don't think I can agree here. Plus per-pCPU allocation would similarly
>>>> get you in trouble when you have only very few VMID bits.
>>> But not so fast as in case of per-domain allocation, right?
>>>
>>> I mean that if we have only 4 bits, then in case of per-domain allocation we will
>>> need to do TLB flush + VMID re-assigning when we have more then 16 domains.
>>>
>>> But in case of per-pCPU allocation we could run 16 domains on 1 pCPU and at the same
>>> time in multiprocessor systems we have more pCPUs, which will allow us to run more
>>> domains and avoid TLB flushes.
>>> On other hand, it is needed to consider that it's unlikely that a domain will have
>>> only one vCPU. And it is likely that amount of vCPUs will be bigger then an amount
>>> of domains, so to have a round-robin approach (as x86) without permanent ID allocation
>>> for each domain will work better then per-pCPU allocation.
>> Here you (appear to) say one thing, ...
>>
>>> In other words, I'm not 100% sure that I get a point why x86 chose per-pCPU allocation
>>> instead of per-domain allocation with having the same VMID for all vCPUs of domains.
>> ... and then here the opposite. Overall I'm in severe trouble understanding this
>> reply of yours as a whole, so I fear I can't really respond to it (or even just
>> parts thereof).
> 
> IIUC, x86 allocates VMIDs per physical CPU (pCPU) "dynamically" — these are just
> sequential numbers, and once VMIDs run out on a given pCPU, there's no guarantee
> that a vCPU will receive the same VMID again.
> 
> On the other hand, RISC-V currently allocates a single VMID per domain, and that
> VMID is considered "permanent" until the domain is destroyed. This means we are
> limited to at most VMID_MAX domains. To avoid this limitation, I plan to implement
> a round-robin reuse approach: when no free VMIDs remain, we start a new generation
> and begin reusing old VMIDs.
> 
> The only remaining design question is whether we want RISC-V to follow a global
> VMID allocation policy (i.e., one VMID per domain, shared across all of its vCPUs),
> or adopt a policy similar to x86 with per-CPU VMID allocation (each vCPU gets its
> own VMID, local to the CPU it's running on).

Besides what Jürgen has said, what would this mean if you have 16 VMIDs and a 17th
domain appears? You can't "take away" the VMID from any domain, unless you fully
suspended it first (that is, all of its vCPU-s).

> Each policy has its own trade-offs. But in the case where the number of available
> VMIDs is small (i.e., low VMIDLEN), a global allocation policy may be more suitable,
> as it requires fewer VMIDs overall.
> 
> So my main question was:
> What are the advantages of per-pCPU VMID allocation in scenarios with limited VMID
> space, and why did x86 choose that design?
> 
>  From what I can tell, the benefits of per-pCPU VMID allocation include:
> - Minimized inter-CPU TLB flushes — since VMIDs are local, TLB entries don’t need
>    to be invalidated on other CPUs when reused.
> - Better scalability — this approach works better on systems with a large number
>    of CPUs.
> - Frequent VM switches don’t require global TLB flushes — reducing the overhead
>    of context switching.
> However, the downside is that this model consumes more VMIDs. For example,
> if a single domain runs on 4 vCPUs across 4 CPUs, it will consume 4 VMIDs instead
> of just one.

I don't understand this, nor why it's a downside. Looking at a domain as a whole
simply doesn't make sense in this model. Or if you do, then you need to consider
the system-wide number of VMIDs you have available:
(1 << VMIDLEN) * num_online_cpus(). That is, in your calculation a domain with
4 vCPU-s may indeed use up to 4 VMIDs at a time, but out of a pool at least 4
times the size of that of an individual pCPU.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 12:17:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 12:17:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026262.1401464 (Exim 4.92)
	(envelope-from )
	id 1uUlXh-0002tE-2T; Thu, 26 Jun 2025 12:17:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026262.1401464; Thu, 26 Jun 2025 12: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 1uUlXg-0002t7-VU; Thu, 26 Jun 2025 12:17:24 +0000
Received: by outflank-mailman (input) for mailman id 1026262;
 Thu, 26 Jun 2025 12:17: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 1uUlXg-0002sI-2h
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 12:17:24 +0000
Received: from mail180-2.suw31.mandrillapp.com
 (mail180-2.suw31.mandrillapp.com [198.2.180.2])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 80ad9555-5287-11f0-b894-0df219b8e170;
 Thu, 26 Jun 2025 14:17:18 +0200 (CEST)
Received: from pmta11.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail180-2.suw31.mandrillapp.com (Mailchimp) with ESMTP id 4bSd3d3XNJzS62TVL
 for ; Thu, 26 Jun 2025 12:17:17 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 c1a4f0ada62143388848be4f9023356b; Thu, 26 Jun 2025 12:17: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: 80ad9555-5287-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1750940237; x=1751210237;
	bh=UWIKLwILb6aA5FgaHMD88bwDLgXunzUumJKkuTX5xQ0=;
	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=wZw0KzfWs5iZslDNqh5WC9W232kfx8ykspQ6D3yUKP9wHdPAIM0oqVJaYvMsCptDC
	 KfNbYaMLux4Bc8XIyWaVO1+sVFNRkXsVRqsp4eEAZBu6mDkhutwcu5jvbiRZUSwFr2
	 99ba5p8CEEitNT9wZG9ZCxg/pAnIDyC39JiI8LKKZzewuQ5KvRSFL26SQaDcjrFgvT
	 Goh3hGdSL5O0L1Vs0iWpqTPEb791lcGfgh69GVevnenmYa2CJSzvS6LfTIw3dCwgiO
	 NYuj5OE//nSzJQqIW4i1qaXZeNJef6+7f795+zdkXeo8MtYU5VmlBO76E+bjWJcFAH
	 tyOxEe48MFFBw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1750940237; x=1751200737; i=teddy.astie@vates.tech;
	bh=UWIKLwILb6aA5FgaHMD88bwDLgXunzUumJKkuTX5xQ0=;
	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=Bvv7pC5urOtAwzG787xNJgk9XVOIZqbSAmE1pWavmvCkM5Zt1NfLIrYF42kJ9ExFi
	 8FJg/8pNUejy9e/Co/kBje4/X4vQ4nHrmZdQyYWdE96mk6TEoHLMGh5xuAJ5VNKMP0
	 I/0EYZx8xRAQWZ83ReTXH30TEDLV5fLvzUWpkKnsCtilUAJtxTz03UaJ1PkNNylave
	 Lv06tQcrLqrXLQnQqGgTbGZB5XSuMTEhlZxtPN2gH7sbiZx/RyIu8uSWS58Pb1nnBL
	 R5Fy6U4AbS9wVKXN5AVHoZRiZnAx8tpJoXblpeojk/iMWBaKDTZlSxFrPM/5Ka+Sc6
	 Tw4aWRKq/C4bA==
From: "Teddy Astie" 
Subject: =?utf-8?Q?Re:=20[PATCH=20v2=2003/17]=20xen/riscv:=20introduce=20guest=20domain's=20VMID=20allocation=20and=20manegement?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1750940235219
Message-Id: <096224cd-12f3-4e4f-8cd8-74c1ae292609@vates.tech>
To: "Juergen Gross" , "Oleksii Kurochko" , "Jan Beulich" 
Cc: "Alistair Francis" , "Bob Eshleman" , "Connor Davis" , "Andrew Cooper" , "Anthony PERARD" , "Michal Orzel" , "Julien Grall" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Stefano Stabellini" , xen-devel@lists.xenproject.org
References:    <145f71c2-643e-4839-a2ae-0bc1f049db74@gmail.com> <80223fe3-7403-4026-9505-8826c318fabb@suse.com>   <1a570c32-e207-47f5-9702-a752246328a9@gmail.com>  <264db0b0-43bf-4829-a5cc-ca696601349c@gmail.com> <7c5761b5-805c-4d56-ad8c-1746540423e4@suse.com>
In-Reply-To: <7c5761b5-805c-4d56-ad8c-1746540423e4@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.c1a4f0ada62143388848be4f9023356b?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250626:md
Date: Thu, 26 Jun 2025 12:17:17 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Le 26/06/2025 =C3=A0 13:46, Juergen Gross a =C3=A9crit=C2=A0:
> On 26.06.25 13:34, Oleksii Kurochko wrote:
>>
>> On 6/26/25 12:41 PM, Jan Beulich wrote:
>> - Minimized inter-CPU TLB flushes =E2=80=94 since VMIDs are local, TLB e=
ntries 
>> don=E2=80=99t need
>> =C2=A0=C2=A0 to be invalidated on other CPUs when reused.
>> - Better scalability =E2=80=94 this approach works better on systems wit=
h a 
>> large number
>> =C2=A0=C2=A0 of CPUs.
>> - Frequent VM switches don=E2=80=99t require global TLB flushes =E2=80=
=94 reducing the 
>> overhead
>> =C2=A0=C2=A0 of context switching.
>> However, the downside is that this model consumes more VMIDs. For 
>> example,
>> if a single domain runs on 4 vCPUs across 4 CPUs, it will consume 4 
>> VMIDs instead
>> of just one.
> 
> Consider you have 4 bits for VMIDs, resulting in 16 VMID values.
> 
> If you have a system with 32 physical CPUs and 32 domains with 1 vcpu eac=
h
> on that system, your scheme would NOT allow to keep each physical cpu bus=
y
> by running a domain on it, as only 16 domains could be active at the same
> time.
> 

Why not instead consider dropping use of VMID in case there is no one 
remaining ?
(i.e systematically flush the guest TLB before entering the vcpu and 
using a "blank" VMID)

I don't expect a lot of platforms to allow for 32 pCPU while not giving 
more than 16 VMID values. So it would just be less efficient in that 
case at worst.

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 Jun 26 12:26:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 12:26:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026284.1401474 (Exim 4.92)
	(envelope-from )
	id 1uUlg0-0004n6-RV; Thu, 26 Jun 2025 12:26:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026284.1401474; Thu, 26 Jun 2025 12:26: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 1uUlg0-0004mz-Oc; Thu, 26 Jun 2025 12:26:00 +0000
Received: by outflank-mailman (input) for mailman id 1026284;
 Thu, 26 Jun 2025 12:25:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uUlfz-0004mB-Iv
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 12:25:59 +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 b6c64ffd-5288-11f0-a30f-13f23c93f187;
 Thu, 26 Jun 2025 14:25:58 +0200 (CEST)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-60c6fea6742so1139075a12.1
 for ; Thu, 26 Jun 2025 05:25:58 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-60c2f484513sm3846246a12.63.2025.06.26.05.25.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 26 Jun 2025 05:25:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b6c64ffd-5288-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750940758; x=1751545558; 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=EtVThhDR2ZkPKlPNqNM2MZDX8KfeUM3tCDZbDjHg4uw=;
        b=QHcVG1jYei95InxQJ0zJdAh+k1GsWsgZGGPyaFqa+Dx4bRWwhobV5DKUeKMTXma4u3
         v695+9nfArEMzkohT/7K3TRx4bJQfunW1rLdu8sp0OjQbLWAD9Oe96LWPguzqBU/LqlQ
         30NwrCCgH78Ga1+luKomZYDd3d3vyZW06t83wHIExzy7kgQzdZFrjWtJk/0SXkCMwhqJ
         9JKJLfkr7umdqpUMJMRjzkog8Vww4/XnmyPkQ/CeWYzhUkg/UUKyYum2e4N3CmJFfGDg
         xgcnmfLE6ub3myH+OeOmAEkjg/UIkf1T5vmYIrpSadx0Q0uw7m81XEnz02Okw7mp6tx0
         XRfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750940758; x=1751545558;
        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=EtVThhDR2ZkPKlPNqNM2MZDX8KfeUM3tCDZbDjHg4uw=;
        b=ieTSGKB/HjQ+VUPx1EI/N5KOTawv5AT2cfGOjqzdzpQu4IET3eJGsk2jOoBETgST5n
         wfL/QPSXrLY0oBDilHCHLULS3ILNRccCytCpVbQkeyqHVIZPE+UZKGC59B9wEdQlidKk
         fx4Nqn+sNPbHdTJY2gbHDgzHji3iLeTfgM1kzASrV9+SZVFqUwPTmgXaOfRXM78qT5D0
         FTMCLheM4/3WQ7Fhdt9QmzX+nKqRNaSxjTDSRXYfajIKzJqh4ZXzTuXw0p8W7OZTFQ3L
         wcCxe1JAUeJcERj+BdUQu3D4chwPqcP5zlBlqHGfaRZVNDajlxqK9pKRkrDzoP3ocGMj
         L2Ug==
X-Forwarded-Encrypted: i=1; AJvYcCW08me0XNGNjIEtB5Jg4BYMH74sDCnwGhokGS+zihcctntf8bRYgNQzxjrgxWRqtIpUm70GOz0mDcY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzOCYhTAUYVxtUF5jCPNiq8lfa+ff6XFwKk0PlKL37c4ZhFD/WN
	5bcyWP0yM1AFozLIm8JsuJOOXCHiJvzgxXjGG3DQv/wxRRDNp3928XIu
X-Gm-Gg: ASbGncs8Yh+NuO9sCgUSFANQlnigKeJ/9G0W3DZAa0gms1TyJnWcfZ3UmYJlnnfMSoZ
	2ypcP9U2ydnemxDxhhZjrZMRlY65mMmz5QGgv8TjO4Sqyozl3CFJumA7KP3t2d27yho9OVUEvU8
	Nyi98xZ/JZrzhkFIizsBnjRHxdxkVD1GsUhrBVH+r1iSLrs9BSLPdeNW66T9n9I+FWdzK+vShhL
	XjUOC4w7NRgYskRrL4Qz/deYq/FEENNZNsG8HzQHd0fkyBs15ryZUNon/rHp7iftuSxapjOtMKA
	eEM9iMg0D22/ECuJhUfdb7P8YD68/Q9hfNNfWW3cAbyGUV4bx1SmrWbt9HV87jLpZrPyfiLzKXO
	KIaEfeOGmyKEDc9Jd03sn8GiuAart+qNy6no=
X-Google-Smtp-Source: AGHT+IEMop9OPusb263sBsJLaApm/zJD5bLdPhV0FRZOkQsGKx2Dy9lVFcaSNephjvwdtQwjC8Z2vA==
X-Received: by 2002:a05:6402:1ed4:b0:607:6fd3:374f with SMTP id 4fb4d7f45d1cf-60c4dd26e88mr6433457a12.20.1750940757650;
        Thu, 26 Jun 2025 05:25:57 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------N0HV02j0fnyagYQmqyOgJ6V9"
Message-ID: 
Date: Thu, 26 Jun 2025 14:25:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 03/17] xen/riscv: introduce guest domain's VMID
 allocation and manegement
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: 
 
 
 <145f71c2-643e-4839-a2ae-0bc1f049db74@gmail.com>
 <80223fe3-7403-4026-9505-8826c318fabb@suse.com>
 
 
 <1a570c32-e207-47f5-9702-a752246328a9@gmail.com>
 
 <264db0b0-43bf-4829-a5cc-ca696601349c@gmail.com>
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

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


On 6/26/25 2:16 PM, Jan Beulich wrote:
> On 26.06.2025 13:34, Oleksii Kurochko wrote:
>> On 6/26/25 12:41 PM, Jan Beulich wrote:
>>> On 26.06.2025 12:05, Oleksii Kurochko wrote:
>>>> On 6/24/25 4:01 PM, Jan Beulich wrote:
>>>>> On 24.06.2025 15:47, Oleksii Kurochko wrote:
>>>>>> On 6/24/25 12:44 PM, Jan Beulich wrote:
>>>>>>> On 24.06.2025 11:46, Oleksii Kurochko wrote:
>>>>>>>> On 6/18/25 5:46 PM, Jan Beulich wrote:
>>>>>>>>> On 10.06.2025 15:05, Oleksii Kurochko wrote:
>>>>>>>>>> --- /dev/null
>>>>>>>>>> +++ b/xen/arch/riscv/p2m.c
>>>>>>>>>> @@ -0,0 +1,115 @@
>>>>>>>>>> +#include 
>>>>>>>>>> +#include 
>>>>>>>>>> +#include 
>>>>>>>>>> +#include 
>>>>>>>>>> +#include 
>>>>>>>>>> +
>>>>>>>>>> +#include 
>>>>>>>>>> +#include 
>>>>>>>>>> +
>>>>>>>>>> +static spinlock_t vmid_alloc_lock = SPIN_LOCK_UNLOCKED;
>>>>>>>>>> +
>>>>>>>>>> +/*
>>>>>>>>>> + * hgatp's VMID field is 7 or 14 bits. RV64 may support 14-bit VMID.
>>>>>>>>>> + * Using a bitmap here limits us to 127 (2^7 - 1) or 16383 (2^14 - 1)
>>>>>>>>>> + * concurrent domains.
>>>>>>>>> Which is pretty limiting especially in the RV32 case. Hence why we don't
>>>>>>>>> assign a permanent ID to VMs on x86, but rather manage IDs per-CPU (note:
>>>>>>>>> not per-vCPU).
>>>>>>>> Good point.
>>>>>>>>
>>>>>>>> I don't believe anyone will use RV32.
>>>>>>>> For RV64, the available ID space seems sufficiently large.
>>>>>>>>
>>>>>>>> However, if it turns out that the value isn't large enough even for RV64,
>>>>>>>> I can rework it to manage IDs per physical CPU.
>>>>>>>> Wouldn't that approach result in more TLB entries being flushed compared
>>>>>>>> to per-vCPU allocation, potentially leading to slightly worse performance?
>>>>>>> Depends on the condition for when to flush. Of course performance is
>>>>>>> unavoidably going to suffer if you have only very few VMIDs to use.
>>>>>>> Nevertheless, as indicated before, the model used on x86 may be a
>>>>>>> candidate to use here, too. See hvm_asid_handle_vmenter() for the
>>>>>>> core (and vendor-independent) part of it.
>>>>>> IIUC, so basically it is just a round-robin and when VMIDs are ran out
>>>>>> then just do full guest TLB flush and start to re-use VMIDs from the start.
>>>>>> It makes sense to me, I'll implement something similar. (as I'm not really
>>>>>> sure that we needdata->core_asid_generation, probably, I will understand it better when
>>>>>> start to implement it)
>>>>> Well. The fewer VMID bits you have the more quickly you will need a new
>>>>> generation. And keep track of the generation you're at you also need to
>>>>> track the present number somewhere.
>>>>>
>>>>>>>> What about then to allocate VMID per-domain?
>>>>>>> That's what you're doing right now, isn't it? And that gets problematic when
>>>>>>> you have only very few bits in hgatp.VMID, as mentioned below.
>>>>>> Right, I just phrased my question poorly—sorry about that.
>>>>>>
>>>>>> What I meant to ask is: does the approach described above actually depend on whether
>>>>>> VMIDs are allocated per-domain or per-pCPU? It seems that the main advantage of
>>>>>> allocating VMIDs per-pCPU is potentially reducing the number of TLB flushes,
>>>>>> since it's more likely that a platform will have more than|VMID_MAX| domains than
>>>>>> |VMID_MAX| physical CPUs—am I right?
>>>>> Seeing that there can be systems with hundreds or even thousands of CPUs,
>>>>> I don't think I can agree here. Plus per-pCPU allocation would similarly
>>>>> get you in trouble when you have only very few VMID bits.
>>>> But not so fast as in case of per-domain allocation, right?
>>>>
>>>> I mean that if we have only 4 bits, then in case of per-domain allocation we will
>>>> need to do TLB flush + VMID re-assigning when we have more then 16 domains.
>>>>
>>>> But in case of per-pCPU allocation we could run 16 domains on 1 pCPU and at the same
>>>> time in multiprocessor systems we have more pCPUs, which will allow us to run more
>>>> domains and avoid TLB flushes.
>>>> On other hand, it is needed to consider that it's unlikely that a domain will have
>>>> only one vCPU. And it is likely that amount of vCPUs will be bigger then an amount
>>>> of domains, so to have a round-robin approach (as x86) without permanent ID allocation
>>>> for each domain will work better then per-pCPU allocation.
>>> Here you (appear to) say one thing, ...
>>>
>>>> In other words, I'm not 100% sure that I get a point why x86 chose per-pCPU allocation
>>>> instead of per-domain allocation with having the same VMID for all vCPUs of domains.
>>> ... and then here the opposite. Overall I'm in severe trouble understanding this
>>> reply of yours as a whole, so I fear I can't really respond to it (or even just
>>> parts thereof).
>> IIUC, x86 allocates VMIDs per physical CPU (pCPU) "dynamically" — these are just
>> sequential numbers, and once VMIDs run out on a given pCPU, there's no guarantee
>> that a vCPU will receive the same VMID again.
>>
>> On the other hand, RISC-V currently allocates a single VMID per domain, and that
>> VMID is considered "permanent" until the domain is destroyed. This means we are
>> limited to at most VMID_MAX domains. To avoid this limitation, I plan to implement
>> a round-robin reuse approach: when no free VMIDs remain, we start a new generation
>> and begin reusing old VMIDs.
>>
>> The only remaining design question is whether we want RISC-V to follow a global
>> VMID allocation policy (i.e., one VMID per domain, shared across all of its vCPUs),
>> or adopt a policy similar to x86 with per-CPU VMID allocation (each vCPU gets its
>> own VMID, local to the CPU it's running on).
> Besides what Jürgen has said, what would this mean if you have 16 VMIDs and a 17th
> domain appears? You can't "take away" the VMID from any domain, unless you fully
> suspended it first (that is, all of its vCPU-s).

In this case, use of VMID could be dropped and just flush the guest TLB before entering
domain. Not efficient, but still an option.

>
>> Each policy has its own trade-offs. But in the case where the number of available
>> VMIDs is small (i.e., low VMIDLEN), a global allocation policy may be more suitable,
>> as it requires fewer VMIDs overall.
>>
>> So my main question was:
>> What are the advantages of per-pCPU VMID allocation in scenarios with limited VMID
>> space, and why did x86 choose that design?
>>
>>   From what I can tell, the benefits of per-pCPU VMID allocation include:
>> - Minimized inter-CPU TLB flushes — since VMIDs are local, TLB entries don’t need
>>     to be invalidated on other CPUs when reused.
>> - Better scalability — this approach works better on systems with a large number
>>     of CPUs.
>> - Frequent VM switches don’t require global TLB flushes — reducing the overhead
>>     of context switching.
>> However, the downside is that this model consumes more VMIDs. For example,
>> if a single domain runs on 4 vCPUs across 4 CPUs, it will consume 4 VMIDs instead
>> of just one.
> I don't understand this, nor why it's a downside. Looking at a domain as a whole
> simply doesn't make sense in this model. Or if you do, then you need to consider
> the system-wide number of VMIDs you have available:
> (1 << VMIDLEN) * num_online_cpus(). That is, in your calculation a domain with
> 4 vCPU-s may indeed use up to 4 VMIDs at a time, but out of a pool at least 4
> times the size of that of an individual pCPU.

Good point, I thought about that too.

~ Oleksii

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



  
    
  
  
    

    
    
    
    
    On 6/26/25 2:16 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 26.06.2025 13:34, Oleksii Kurochko wrote:

    
      
    
        
    On 6/26/25 12:41 PM, Jan Beulich wrote:

    
        
    
          
    On 26.06.2025 12:05, Oleksii Kurochko wrote:

    
          
    
            
    On 6/24/25 4:01 PM, Jan Beulich wrote:

    
            
    
              
    On 24.06.2025 15:47, Oleksii Kurochko wrote:

    
              
    
                
    On 6/24/25 12:44 PM, Jan Beulich wrote:

    
                
    
                  
    On 24.06.2025 11:46, Oleksii Kurochko wrote:

    
                  
    
                    
    On 6/18/25 5:46 PM, Jan Beulich wrote:

    
                    
    
                      
    On 10.06.2025 15:05, Oleksii Kurochko wrote:

    
                      
    
                        
    --- /dev/null
+++ b/xen/arch/riscv/p2m.c
@@ -0,0 +1,115 @@
+#include <xen/bitops.h>
+#include <xen/lib.h>
+#include <xen/sched.h>
+#include <xen/spinlock.h>
+#include <xen/xvmalloc.h>
+
+#include <asm/p2m.h>
+#include <asm/sbi.h>
+
+static spinlock_t vmid_alloc_lock = SPIN_LOCK_UNLOCKED;
+
+/*
+ * hgatp's VMID field is 7 or 14 bits. RV64 may support 14-bit VMID.
+ * Using a bitmap here limits us to 127 (2^7 - 1) or 16383 (2^14 - 1)
+ * concurrent domains.

    
                      
    
                      
    Which is pretty limiting especially in the RV32 case. Hence why we don't
assign a permanent ID to VMs on x86, but rather manage IDs per-CPU (note:
not per-vCPU).

    
                    
    
                    
    Good point.

I don't believe anyone will use RV32.
For RV64, the available ID space seems sufficiently large.

However, if it turns out that the value isn't large enough even for RV64,
I can rework it to manage IDs per physical CPU.
Wouldn't that approach result in more TLB entries being flushed compared
to per-vCPU allocation, potentially leading to slightly worse performance?

    
                  
    
                  
    Depends on the condition for when to flush. Of course performance is
unavoidably going to suffer if you have only very few VMIDs to use.
Nevertheless, as indicated before, the model used on x86 may be a
candidate to use here, too. See hvm_asid_handle_vmenter() for the
core (and vendor-independent) part of it.

    
                
    
                
    IIUC, so basically it is just a round-robin and when VMIDs are ran out
then just do full guest TLB flush and start to re-use VMIDs from the start.
It makes sense to me, I'll implement something similar. (as I'm not really
sure that we needdata->core_asid_generation, probably, I will understand it better when
start to implement it)

    
              
    
              
    Well. The fewer VMID bits you have the more quickly you will need a new
generation. And keep track of the generation you're at you also need to
track the present number somewhere.


    
              
    
                
    
                  
    
                    
    What about then to allocate VMID per-domain?

    
                  
    
                  
    That's what you're doing right now, isn't it? And that gets problematic when
you have only very few bits in hgatp.VMID, as mentioned below.

    
                
    
                
    Right, I just phrased my question poorly—sorry about that.

What I meant to ask is: does the approach described above actually depend on whether
VMIDs are allocated per-domain or per-pCPU? It seems that the main advantage of
allocating VMIDs per-pCPU is potentially reducing the number of TLB flushes,
since it's more likely that a platform will have more than|VMID_MAX| domains than
|VMID_MAX| physical CPUs—am I right?

    
              
    
              
    Seeing that there can be systems with hundreds or even thousands of CPUs,
I don't think I can agree here. Plus per-pCPU allocation would similarly
get you in trouble when you have only very few VMID bits.

    
            
    
            
    But not so fast as in case of per-domain allocation, right?

I mean that if we have only 4 bits, then in case of per-domain allocation we will
need to do TLB flush + VMID re-assigning when we have more then 16 domains.

But in case of per-pCPU allocation we could run 16 domains on 1 pCPU and at the same
time in multiprocessor systems we have more pCPUs, which will allow us to run more
domains and avoid TLB flushes.
On other hand, it is needed to consider that it's unlikely that a domain will have
only one vCPU. And it is likely that amount of vCPUs will be bigger then an amount
of domains, so to have a round-robin approach (as x86) without permanent ID allocation
for each domain will work better then per-pCPU allocation.

    
          
    
          
    Here you (appear to) say one thing, ...


    
          
    
            
    In other words, I'm not 100% sure that I get a point why x86 chose per-pCPU allocation
instead of per-domain allocation with having the same VMID for all vCPUs of domains.

    
          
    
          
    ... and then here the opposite. Overall I'm in severe trouble understanding this
reply of yours as a whole, so I fear I can't really respond to it (or even just
parts thereof).

    
        
    
        
    IIUC, x86 allocates VMIDs per physical CPU (pCPU) "dynamically" — these are just
sequential numbers, and once VMIDs run out on a given pCPU, there's no guarantee
that a vCPU will receive the same VMID again.

On the other hand, RISC-V currently allocates a single VMID per domain, and that
VMID is considered "permanent" until the domain is destroyed. This means we are
limited to at most VMID_MAX domains. To avoid this limitation, I plan to implement
a round-robin reuse approach: when no free VMIDs remain, we start a new generation
and begin reusing old VMIDs.

The only remaining design question is whether we want RISC-V to follow a global
VMID allocation policy (i.e., one VMID per domain, shared across all of its vCPUs),
or adopt a policy similar to x86 with per-CPU VMID allocation (each vCPU gets its
own VMID, local to the CPU it's running on).

    
      
    
      
    Besides what Jürgen has said, what would this mean if you have 16 VMIDs and a 17th
domain appears? You can't "take away" the VMID from any domain, unless you fully
suspended it first (that is, all of its vCPU-s).
    
    
    
    
    In this case, use of VMID could be dropped and just flush the guest TLB before entering
domain. Not efficient, but still an option.


    
    
    
      
    

    
      
    
        
    Each policy has its own trade-offs. But in the case where the number of available
VMIDs is small (i.e., low VMIDLEN), a global allocation policy may be more suitable,
as it requires fewer VMIDs overall.

So my main question was:
What are the advantages of per-pCPU VMID allocation in scenarios with limited VMID
space, and why did x86 choose that design?

 From what I can tell, the benefits of per-pCPU VMID allocation include:
- Minimized inter-CPU TLB flushes — since VMIDs are local, TLB entries don’t need
   to be invalidated on other CPUs when reused.
- Better scalability — this approach works better on systems with a large number
   of CPUs.
- Frequent VM switches don’t require global TLB flushes — reducing the overhead
   of context switching.
However, the downside is that this model consumes more VMIDs. For example,
if a single domain runs on 4 vCPUs across 4 CPUs, it will consume 4 VMIDs instead
of just one.

    
      
    
      
    I don't understand this, nor why it's a downside. Looking at a domain as a whole
simply doesn't make sense in this model. Or if you do, then you need to consider
the system-wide number of VMIDs you have available:
(1 << VMIDLEN) * num_online_cpus(). That is, in your calculation a domain with
4 vCPU-s may indeed use up to 4 VMIDs at a time, but out of a pool at least 4
times the size of that of an individual pCPU.
    
    
    
    
    Good point, I thought about that too.

~ Oleksii

    
  


--------------N0HV02j0fnyagYQmqyOgJ6V9--


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 12:34:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 12:34:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026307.1401484 (Exim 4.92)
	(envelope-from )
	id 1uUlnq-0006eO-Mb; Thu, 26 Jun 2025 12:34:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026307.1401484; Thu, 26 Jun 2025 12:34: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 1uUlnq-0006eH-JX; Thu, 26 Jun 2025 12:34:06 +0000
Received: by outflank-mailman (input) for mailman id 1026307;
 Thu, 26 Jun 2025 12:34: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 1uUlno-0006eB-KX
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 12:34:04 +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 d72cbbec-5289-11f0-b894-0df219b8e170;
 Thu, 26 Jun 2025 14:34:02 +0200 (CEST)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-3a4f72cba73so1303454f8f.1
 for ; Thu, 26 Jun 2025 05:34:02 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-749c88730d9sm6944422b3a.171.2025.06.26.05.33.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 26 Jun 2025 05:34:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d72cbbec-5289-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750941242; x=1751546042; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=yzwRf7vEaSbj+tQj+ivMabI+UWE0BBbNilWBtKbn4yo=;
        b=WoPsjGWJj3UfsSshL9zclXWyg62sTYdADjg4YhyZpvba3BQEetQQdTbJ1K/A9QXGGI
         te2ceDaqWEyO0WA/rVaJtS4OhyN+z1MRf4XYjaALtDB1gq9HDLmkUjHgzm3Iyq6iJAqT
         ZxDy8x3NKBeiwDg598rxVbXFXx74aQNLPxAyCWYVlHukYD3kwFXq333nxZ83uxk5RZYP
         c0XFqpxgc784npRpVSioidbwEa6S6Ihb+5+1jbna6IH1ewqcW2XJIWA7d6to6TTMXxKw
         g+lz+lxanFiYqcVSTAWX84Qypmx6KBaHTfV8QVUzyEXe0H0atmrPoemLxLu8r9CO/IZQ
         0Qcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750941242; x=1751546042;
        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=yzwRf7vEaSbj+tQj+ivMabI+UWE0BBbNilWBtKbn4yo=;
        b=v2TG0sndGN0hJnA5/enMAf8mg2pOe762/aXy35HYuXCBzdtgM3H9IWjWdRxIUcp/q7
         xhLfrmvR0T8+/Z8U1efEVWRjobnI23U8NfY2Ycz/Oe0RgS6CF0dbRBNajjOI4BLDT7nI
         GBZtqlqAISe3fQu8FUd7eIwN3SQWtVZlKDyTo0S0kur8+Ea2+fS8CA17lf6/K6jcRwvu
         KhNLecly8os/JMtamFSqawJpWEqiJrMFY08K+PUnqx5mGNUrWYPyf85Na21KQjTIHZ9+
         J1G5n47FnuDb5wn7K6Ax81oRxuZCI5zp0zNX/FYw7qzufczH9CfX+j+ztuwjiueIczTs
         z8Yw==
X-Forwarded-Encrypted: i=1; AJvYcCUWuL0YeVCB/3mNvDSvzdyhUz7eI+I4VmCfQHxBBi57qQldc5MUynJpyPANA+9qPOcKUP6Z4ABt2MI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxBsCEw8GTyhopaTj2BjZ6rNhkaecvTBiF1i7ll5ZRRrn55n228
	EMaNxXndDUp3lTMsVGmHJnXd63LfLcT1cd1SJrjx/XMvwE17UYpNcPdAsBJhxHPWMQ==
X-Gm-Gg: ASbGnctPpU0CU/1/dRF8gUi6TL4XeP7xsPziGXjNypfTqmenWKQDS2e9TkdBtje8xS3
	1Dul4IKYiRNK6+If3tP/GhF3hpw1BiNM1lEmcWCwMMF6iLmPxQEqU8UTmoL6V2Ju3SyI+vc8Wp/
	n8ZBn7QahfpyaKX2yAtg2nVSHCymCSUb/fcqwafLSfZ3S8zxBzVMr1TnJ/IrQq9MM8SGbKkUqxO
	wG1Tt5qsQjXiQfIp/xnllnbzuXOfDMLBxZNwBOqSk1vCbR0UtX57j9tavGFJ8kD8Kyp7DwxLHAE
	NtkLkZkCH0REjZHBqREHo+fiu+yuLQ25MpiCRvZJqBha8joxokuLvhclRAHwY9KnsqeXFoE1ozY
	20Yxci0Gy/50FINTC3QLudI3xWLAscEw2ZmhV695vGZjeio8=
X-Google-Smtp-Source: AGHT+IErYitMQtuFaoyPd/Pe6I3EqDgAtHsBtlkDN3viBKQ2Dmp0biKCYCwM7w1aXWsKQbwNhEoSMQ==
X-Received: by 2002:a5d:584b:0:b0:3a6:e2d5:f12d with SMTP id ffacd0b85a97d-3a6f3102cb4mr2923819f8f.11.1750941241696;
        Thu, 26 Jun 2025 05:34:01 -0700 (PDT)
Message-ID: 
Date: Thu, 26 Jun 2025 14:33:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/8] kconfig: turn PDX compression into a choice
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250620111130.29057-1-roger.pau@citrix.com>
 <20250620111130.29057-3-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: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 26.06.2025 09:49, Roger Pau Monné wrote:
> On Tue, Jun 24, 2025 at 03:13:27PM +0200, Jan Beulich wrote:
>> On 20.06.2025 13:11, Roger Pau Monne wrote:
>>> Rename the current CONFIG_PDX_COMPRESSION to CONFIG_PDX_MASK_COMPRESSION,
>>> and make it part of the PDX compression choice block, in preparation for
>>> adding further PDX compression algorithms.
>>>
>>> No functional change intended as the PDX compression defaults should still
>>> be the same for all architectures, however the choice block cannot be
>>> protected under EXPERT and still have a default choice being
>>> unconditionally selected.  As a result, the new "PDX (Page inDeX)
>>> compression" item will be unconditionally visible in Kconfig.
>>
>> Just to mention it: Afaict there is a functional change, but one I actually
>> appreciate, at least in part. So far ...
>>
>>> --- a/xen/common/Kconfig
>>> +++ b/xen/common/Kconfig
>>> @@ -52,9 +52,10 @@ config EVTCHN_FIFO
>>>  
>>>  	  If unsure, say Y.
>>>  
>>> -config PDX_COMPRESSION
>>> -	bool "PDX (Page inDeX) compression" if EXPERT && !X86 && !RISCV
>>> -	default ARM || PPC
>>
>> ... for x86 (and RISC-V) this option couldn't be selected. Whereas ...
>>
>>> @@ -67,6 +68,17 @@ config PDX_COMPRESSION
>>>  	  If your platform does not have sparse RAM banks, do not enable PDX
>>>  	  compression.
>>>  
>>> +config PDX_MASK_COMPRESSION
>>> +	bool "Mask compression"
>>> +	help
>>> +	  Compression relying on all RAM addresses sharing a zeroed bit region.
>>
>> ... this option is now available, as the prior !X86 && !RISCV doesn't
>> re-appear here. (As the description mentions it, that dependency clearly
>> can't appear on the enclosing choice itself.) Since x86 actually still
>> should have mask compression implemented properly, that's fine (from my
>> pov; iirc I even asked that it would have remained available when the
>> earlier change was done), whereas I think for RISC-V it's not quite right
>> to offer the option. It also did escape me why the option was made
>> available for PPC, which I'm pretty sure also lacks the logic to determine
>> a suitable mask.
> 
> Yes, the only architectures that have functional PDX compression are
> x86 and ARM, as neither RISC-V nor PowerPC call the initialization
> functions.  AFAICT this is harmless apart from giving the wrong
> impression to the user that PDX compression might be implemented.
> 
> Would you prefer for me to introduce a new HAS_PDX config option
> that's selected by x86 and ARM, and is used to enable the choice PDX
> config?

Hmm, no, I don't think I want you to make any change to the code. I'm
actually happy with the slight relaxation for x86 (and RISC-V), and
aiui you don't alter behavior for PPC. The fact that behavior there
(and for RISC-V) doesn't look quite right isn't an effect of your
change.

A change may be wanted to the description, to avoid giving the wrong
(afaict) impression of this being "no functional change". Considering
how things ended up the way they are prior to this series, this
becoming explicit may cause _others_ to want you to make changes,
though. Hence I simply wanted to raise that aspect, to give others a
hint that they may need to chime in.

For the record, below is what I think would represent original
behavior ("help" parts omitted), albeit still leaving out the EXPERT
aspect (as it's not clear to me what a condition on a prompt means in
a choice element):

choice
	prompt "PDX (Page inDeX) compression"
	default PDX_MASK_COMPRESSION if !X86 && !RISCV
	default PDX_NONE

config PDX_MASK_COMPRESSION
	bool "Mask compression"
	depends on !X86 && !RISCV

config PDX_NONE
	bool "None"
endchoice

But again, specifically for x86 I'd prefer if PDX_MASK_COMPRESSION
became available (again), so the above is not a suggestion to change
the code, unless others insisted on restoring prior behavior.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 12:37:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 12:37:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026314.1401493 (Exim 4.92)
	(envelope-from )
	id 1uUlrE-0007Ca-3T; Thu, 26 Jun 2025 12:37:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026314.1401493; Thu, 26 Jun 2025 12:37: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 1uUlrE-0007CT-0s; Thu, 26 Jun 2025 12:37:36 +0000
Received: by outflank-mailman (input) for mailman id 1026314;
 Thu, 26 Jun 2025 12:37: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 1uUlrD-0007CN-1u
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 12:37:35 +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 55492ad9-528a-11f0-a30f-13f23c93f187;
 Thu, 26 Jun 2025 14:37:34 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a507e88b0aso716058f8f.1
 for ; Thu, 26 Jun 2025 05:37:33 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-749c88722e7sm6896887b3a.166.2025.06.26.05.37.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 26 Jun 2025 05:37:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 55492ad9-528a-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750941453; x=1751546253; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=B/pdsmga+9WLKORcptWiaUY7QzAxD+mRE9Kq8aLAfIw=;
        b=WXQzdjeQeQzefEd5twVwbXUEMkbk2Hc1ecLck5YoXHwxIldSjcbW/VF2eMRbPv3fqd
         IfTtFbcDBaMGV2q/wo/Kzp0HcFX+V/cHQcw0KUIGhl83kdU9uGw/pB9LDVdKyVjAH0+d
         caOjD6Q+xjyG44LbH7Ld6dFE5JjcmMIZ6JunP+f9+L/pmlbXryxcYXrp2/kdLWE6lqUt
         kSJQgk+7u424BEddzzeSMt5uQYlLQ5FiCg3g5SSMIEW5n+qqkEr0KU9ZtER/E7GvyvXg
         sQXHk4Ay0lAVeKIOPClFYtT40pnV3TkW1ylD5REpgunwwZVXCQtHqD55vqFy2VI+Dz0o
         t20Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750941453; x=1751546253;
        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=B/pdsmga+9WLKORcptWiaUY7QzAxD+mRE9Kq8aLAfIw=;
        b=qupMSVnmUK9hy7DhKnszEoxhSKngvl8oTQRm08T5BK47zRHOO8XcSk+v8k6faf6WNC
         VCkdE8+YH8+6h41kNSekMEabcvwnO3otly7WtpyOPDjQz5JbhC45+IzWF/UEZDx18Ueq
         IJ5sEW/zvv91WYzbBH4TOuw4reEO0UYyVyt7k9y09Yb02T+59M0SRIovCIEm4PRvU68Y
         4JIu8OhBR+DJqqs1It1IDW+83hpYubnE8JgJv+0Ktedj//5UXAtZjNfmy3MM/ZCHO41e
         rA1Q2XyxrFXu5GBt6435gS+kNZPbdTTSIOUGDAMhDfnslNz3EwlMweL+cEzuTb95OcXO
         R/bQ==
X-Forwarded-Encrypted: i=1; AJvYcCWnK+hure0UqbYYTqCShhfNaP8fYmxIBH0y2qwrs5elNTCiMTVHs6jAczzln7ZYKuk4GVlgm69lQdE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwTjmP4L9eU/Xf/z1BAV5rULdi2qAdZ71UpUCVGIbn/GDKAZD8z
	fRSmTKgP7IVnm4P/Exm+Bt6EIzkAPI03hMOtJgeFS+xCmbM9ptOPgiM77/dnKzZALg==
X-Gm-Gg: ASbGnctTnCrWiV4XeOGF+1GRMs/NhkCG6Gdd02Xawse8rCOJHapht2eU7hZZM/unuHi
	X32t0Q8lqARnyMoUGLAIyMdBCBLMnRk02Efsw2ag0tE413X7uoVVcpuJmEvpuAUILlUV8UV2da8
	vSjB6RLuig/gfRKx4kBw5DApJGfthQp09Znf5mnMAkstC9Evxhnr8zV1lY1rslZJ9pihFirl7Zs
	JqffSXkSQL+vf24VNQbOUZ82gHwpvE/fM9/ToCbinrCqhd4rFKxrGHsvaFh8msVDcz5WSI2YDp+
	pvATLAXSIW5MMyCPgvgMblSbzmOsMWEnWEJPYPUtY9efzz66zCZziWdG9s95UZG9a+n7eJ2lRTp
	TqWw2IIzqPXyiczRKrNaDzt3kzHaDIEY1Dk0hzvl7L7uNAmw=
X-Google-Smtp-Source: AGHT+IESv1h3tnJEKeF6Ymq81qeBEhUM3V4jdP9Jh74MDjdmwb2GdgZk8fANh/5Hjk2dqEo9xLxE2Q==
X-Received: by 2002:a05:6000:2184:b0:3a4:f519:ed3 with SMTP id ffacd0b85a97d-3a6ed648fedmr4449075f8f.44.1750941453377;
        Thu, 26 Jun 2025 05:37:33 -0700 (PDT)
Message-ID: 
Date: Thu, 26 Jun 2025 14:37:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 03/17] xen/riscv: introduce guest domain's VMID
 allocation and manegement
To: Teddy Astie 
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,
 Juergen Gross ,
 Oleksii Kurochko 
References: 
 
 
 <145f71c2-643e-4839-a2ae-0bc1f049db74@gmail.com>
 <80223fe3-7403-4026-9505-8826c318fabb@suse.com>
 
 
 <1a570c32-e207-47f5-9702-a752246328a9@gmail.com>
 
 <264db0b0-43bf-4829-a5cc-ca696601349c@gmail.com>
 <7c5761b5-805c-4d56-ad8c-1746540423e4@suse.com>
 <096224cd-12f3-4e4f-8cd8-74c1ae292609@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: <096224cd-12f3-4e4f-8cd8-74c1ae292609@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 26.06.2025 14:17, Teddy Astie wrote:
> Le 26/06/2025 à 13:46, Juergen Gross a écrit :
>> On 26.06.25 13:34, Oleksii Kurochko wrote:
>>>
>>> On 6/26/25 12:41 PM, Jan Beulich wrote:
>>> - Minimized inter-CPU TLB flushes — since VMIDs are local, TLB entries 
>>> don’t need
>>>    to be invalidated on other CPUs when reused.
>>> - Better scalability — this approach works better on systems with a 
>>> large number
>>>    of CPUs.
>>> - Frequent VM switches don’t require global TLB flushes — reducing the 
>>> overhead
>>>    of context switching.
>>> However, the downside is that this model consumes more VMIDs. For 
>>> example,
>>> if a single domain runs on 4 vCPUs across 4 CPUs, it will consume 4 
>>> VMIDs instead
>>> of just one.
>>
>> Consider you have 4 bits for VMIDs, resulting in 16 VMID values.
>>
>> If you have a system with 32 physical CPUs and 32 domains with 1 vcpu each
>> on that system, your scheme would NOT allow to keep each physical cpu busy
>> by running a domain on it, as only 16 domains could be active at the same
>> time.
> 
> Why not instead consider dropping use of VMID in case there is no one 
> remaining ?
> (i.e systematically flush the guest TLB before entering the vcpu and 
> using a "blank" VMID)

Why would one want to do that, when there's a better scheme available?
And how would you decide which VMs to penalize?

> I don't expect a lot of platforms to allow for 32 pCPU while not giving 
> more than 16 VMID values. So it would just be less efficient in that 
> case at worst.

How would you know? How many CPUs (cores) to have in a system is entirely
independent of the capabilities of the individual CPUs.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 12:45:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 12:45:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026321.1401504 (Exim 4.92)
	(envelope-from )
	id 1uUlyi-0000aa-RF; Thu, 26 Jun 2025 12:45:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026321.1401504; Thu, 26 Jun 2025 12:45: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 1uUlyi-0000aT-OS; Thu, 26 Jun 2025 12:45:20 +0000
Received: by outflank-mailman (input) for mailman id 1026321;
 Thu, 26 Jun 2025 12:45: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 1uUlyh-0000aN-6k
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 12:45:19 +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 69faae26-528b-11f0-a30f-13f23c93f187;
 Thu, 26 Jun 2025 14:45:18 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a57c8e247cso788406f8f.1
 for ; Thu, 26 Jun 2025 05:45:18 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b34c4473133sm1677962a12.59.2025.06.26.05.45.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 26 Jun 2025 05:45:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 69faae26-528b-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750941917; x=1751546717; 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=EnD865kQZT3U9m0YypsVhDcIpSJ1IT0MoGncbtt139I=;
        b=WwLhNOVNQPtoH8TFjBTgW++uCtq+w0/DP5ruVYziy/XkaaK43GewSxoiOSuLBHHX9h
         xXCnhYd41JMIkp70m42u6xUhm4Z2VS4WFL9OldQf4G4vw81rW/nJQlNZtVTTopnqRfOX
         rsLkJt0Bs6lcwzkeYOGsxgj6Tez0kCKH32WRsfpsaVFkeMwLg4ZCtuPfmk4raMhuSc6d
         eHnyBsqENC/cn2CuTIlyVUhWwxaRzY32Ax8CRhUf6PuP+0KuggGvJlYMqU16k3AS/Atg
         dV+2YHp6VahRhvrcr7CrJ1YpfDyE8falwiTiY9BRtunFupskL3Oxb0dRnTKYZkhvVvPv
         SkzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750941917; x=1751546717;
        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=EnD865kQZT3U9m0YypsVhDcIpSJ1IT0MoGncbtt139I=;
        b=pk2v81yr1AT/7J4gTRpCTlgfcfXRTdaK/0OFi3hxwsAxm6/8wylcmgB65XgN4/MsLo
         rbNVE8rPX3rSMbamorA6KzB+BMl7ZENsx84a0un/v67fNF240DKlKKpvsp8E5ehqaSzA
         iTUuHWQSKHEMapCmNpqzvkKdVHoJIMXke9F9qUZJKzKpaE5ObO7Qubk1dGV2h18JhK9w
         XRBJCICmlXlXFmyYXVrk85RUKtVewU7pbAOqQkYKpj72XcUfkY53G3ZrSEJCQscjukjR
         ikmxCL6VxOPMF/iolkHmTuEUTd25SB6lHKqxjNFtZpyPjgQCRYfWwnCe8sOt26kSW7nu
         /fXA==
X-Gm-Message-State: AOJu0Yxd+u+Fs7s+0EBniXYRh91wAsq28ILhWFCI554x8AjkaZgTT+0d
	PnwOZH97FQlOpx8MxxbZH0b8p7rdXMV2Hdan3KHCnNfUZ3gQsDOZrMBeglZf1upXWLvpiGdJ/nT
	L+Yw=
X-Gm-Gg: ASbGncvbJId0vr+2pzLQloM3f4wCmUCqFIAWZBGMIMJWhR94RmYRuA+qBWZ/gWBRWh3
	bM7ok2fjCgdo4RqzvGtawYILdhiyGU+o5e/6a/+Wy8LSPlbOPJlLJaXgx1S9C/iyJyoL4YZ4okn
	UME/uhcbrEnssQk2n8ZCD67t4k0K+Vo3hTEWv8uEewLkXaQOmpIrvJ4Xvn+/lBcORBL/dCEWGAs
	Uc3HWNJM2A8zK5Vebs10EPZ6FUKtZPhh79UNS87N09M/j+/HwHSI6n6A2Y1VScucBMEHckG6YUb
	69akz5gvKFyEgE45ZBJsQpPY7DYworvy7lrDBahVwP0QzA4GopZcFu5BMEhs/j2EepAFSfFmRyR
	bh80KUbtj7iLSYG4mneoc1I1pQpLOH5j578InyEAO4ODPWjo=
X-Google-Smtp-Source: AGHT+IFgNX90Jkv79okhnr3X7yZYSluPgNCpiOV3F1rIVVA/MUCX5Xsfyjwq9Nqv4OaF11BYTKiWwA==
X-Received: by 2002:a05:6000:1a50:b0:3a4:e6e6:a026 with SMTP id ffacd0b85a97d-3a6ed641e0bmr4827813f8f.28.1750941917307;
        Thu, 26 Jun 2025 05:45:17 -0700 (PDT)
Message-ID: 
Date: Thu, 26 Jun 2025 14:45:08 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Marek Marczykowski ,
 Daniel Smith 
From: Jan Beulich 
Subject: [PATCH] x86/EFI: restrict use of --dynamicbase
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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

At least GNU ld 2.35 takes this option to (also) mean what newer
versions have controllable by --enable-reloc-section. From there being
no relocations in check.efi (as we don't pass the option there) we infer
that we need to involve mkreloc, we'd end up with two sets of
relocations, which clearly isn't going to work. Furthermore the
relocations ld emits in this case also aren't usable: For bsp_idt[] we
end up with PE_BASE_RELOC_LOW ones, which efi_arch_relocate_image()
(deliberately) doesn't know how to deal with. (Related to that is also
why we check the number of relocations produced: The linker simply
didn't get this right there, yet.)

We also can't add the option to what we use when linking check.efi: That
ld version then would produce relocations, but 4 of them (instead of the
expected two). That would make us pass --disable-reloc-section, which
however only ld 2.36 and newer understand.

For such older binutils versions we therefore need to accept the slight
inconsistency in DLL characteristics that the earlier commit meant to
eliminate.

Fixes: f2148773b8ac ("x86/EFI: sanitize DLL characteristics in binary")
Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/arch.mk
+++ b/xen/arch/x86/arch.mk
@@ -106,7 +106,7 @@ efi-nr-fixups := $(shell LC_ALL=C $(OBJD
 
 ifeq ($(efi-nr-fixups),2)
 MKRELOC := :
-EFI_LDFLAGS += --disable-high-entropy-va
+EFI_LDFLAGS += --disable-high-entropy-va --dynamicbase
 else
 MKRELOC := arch/x86/efi/mkreloc
 # If the linker produced fixups but not precisely two of them, we need to
@@ -117,8 +117,6 @@ EFI_LDFLAGS += --disable-reloc-section
 endif
 endif
 
-EFI_LDFLAGS += --dynamicbase
-
 endif # $(XEN_BUILD_PE)
 
 export XEN_BUILD_EFI XEN_BUILD_PE


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 12:53:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 12:53:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026328.1401514 (Exim 4.92)
	(envelope-from )
	id 1uUm6V-0002Hh-K0; Thu, 26 Jun 2025 12:53:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026328.1401514; Thu, 26 Jun 2025 12:53: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 1uUm6V-0002HZ-Fp; Thu, 26 Jun 2025 12:53:23 +0000
Received: by outflank-mailman (input) for mailman id 1026328;
 Thu, 26 Jun 2025 12: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 1uUm6T-0002Fy-RZ
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 12:53:21 +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 881b837e-528c-11f0-b894-0df219b8e170;
 Thu, 26 Jun 2025 14:53:18 +0200 (CEST)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-3a510432236so747387f8f.0
 for ; Thu, 26 Jun 2025 05:53:18 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d8607c96sm156411895ad.138.2025.06.26.05.53.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 26 Jun 2025 05:53:17 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 881b837e-528c-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750942398; x=1751547198; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=gXDUW5WwrevfyDEA07KKbi2JpoDr3uAr7Hsstk9AqxI=;
        b=YwyIVVsd/GxrcmahY3r79kZSHMlXfLE9+nZcYSrqLx3HfntpAUceW20Qwttz+refHO
         kvU81c+SSY24rdPtWyIf3YNYrBizvZ6bhhwzze+bGnMlChSVXZDrkeMi8Ov2+9+u5K3s
         L9pidQTXf4ODVXeOyscGmUBbWb23kIFBOF7IJSb2xZpiGm1qpaBH0EVqfmtgPqmsSsDW
         83Ysx3IFJkZDnw+jChDNFbz59RH93D8JgpNy3zaAUy/PI12hkx91/U96V3xEZItaxj25
         VhimvPsL9f6gQvr6ym72dkjhOQ6WUrKSehP7ba7STjvlqDYD06qXiRQnvqW0/VZuehuq
         HMkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750942398; x=1751547198;
        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=gXDUW5WwrevfyDEA07KKbi2JpoDr3uAr7Hsstk9AqxI=;
        b=MZSKys6UxOIhUvxlS0KoM3MlVyLZOwS/a5+4EwtGpn4+P144sdYJ9aHJ8oe0OQt9t2
         E799Z37A3cN0grofVwbj+ZfxHFV69hQOOhKxbVsKSoMuQL0xbuCU41D40FsxIIa+zjBI
         NywWSgIy1EEIooYUrebdq9597bpM426aW6s57nu2tYhnYFIuI/ipzQEi4pKw3aL8+EIX
         wctH2dVaU/VaLfOUoUP1o80tezEn3i+NUkWht9W1AE3gjInB9mP6pwnLTLq06phxyCti
         N818QJOPRQ5bf72prMZ9WBMRQ7vtS15QaFVS38tvqBllZFa7zGise2QW9v6hcbEDu2fv
         Kfag==
X-Forwarded-Encrypted: i=1; AJvYcCWCc2t3i0YOOOpFVlZaadcbqusHQEIDeLAoLl0ppWYMXovxzvLBGwvuUqmBUacPvPHYjGkM37ad9pQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzzMvYelI1AqtsPKfzWzLpwpE/4ikVO+jX9cK7qbR97dZ3YnbOU
	Op7pTeRVHYq+Mwt0pOJGRupCPCGuFXCO6DLdd1DVfyvSApRhySQHoQ5/B0d4I52RTw==
X-Gm-Gg: ASbGncvOcjR3Svw0pb8GNkrSXaByG9n4KFlEk7Fcc3hYASq9jw93y15ryntdgMFxbXn
	P2rwM6r0oP6lS9w36D7gZZSuzCyJ6oaIM0iNFR7PEM3an7zhSK3sk3tBfx6L/kTa7SWaifjAvV1
	4xk4XcRvqZhDx3/LJPnXl4k7AnrIvq25DfXsBvu3xsC1DNkeklHXyhwTT2a+ZcRGCej7HflDC3r
	0YufxoOId66Tj2oSj1S6Y9BY1Sspzqth+NmK29SFxa6F9//eRoiHMZiyc4bGpfga4CsnJRrBstK
	Bfgv0+PyPujzEjcFIzpkeIMAPVEIBsHmQxRKJT0X/F5cfwnCGHoS6fy5xQBgPgEa4uN9v8j7YTy
	bTWbGM+FTCIWThE7TTFQixg77AroXzlEUUS+T+36ph8eOnY0=
X-Google-Smtp-Source: AGHT+IF5qX8MT0FiR76B6K3JXP2hKh9+95y8Fhhenb0Opf0TlMZv8/UgfAOKKOtNpxpt2Bb6yE6zQg==
X-Received: by 2002:a05:6000:1446:b0:3a1:fcd6:1e6b with SMTP id ffacd0b85a97d-3a6ed65b46emr5590981f8f.57.1750942397554;
        Thu, 26 Jun 2025 05:53:17 -0700 (PDT)
Message-ID: 
Date: Thu, 26 Jun 2025 14:53:09 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/3] xen/efi: Handle cases where file didn't come from
 ESP
To: Frediano Ziglio 
Cc: "Daniel P. Smith" ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , xen-devel@lists.xenproject.org
References: <20250625073408.7496-1-frediano.ziglio@cloud.com>
 <20250625073408.7496-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: <20250625073408.7496-2-frediano.ziglio@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 25.06.2025 09:34, Frediano Ziglio wrote:
> A boot loader can load files from outside ESP.

I think it would have helped if you said somewhere what ESP is. People may
think of this as UEFI System Partition (or some such), which doesn't collapse
to the acronym used.

> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -443,6 +443,18 @@ static EFI_FILE_HANDLE __init get_parent_handle(const EFI_LOADED_IMAGE *loaded_i
>      CHAR16 *pathend, *ptr;
>      EFI_STATUS ret;
>  
> +    /*
> +     * In some cases the image could not come from a specific device.
> +     * For instance this can happen if Xen was loaded using GRUB2 "linux"
> +     * command.
> +     */

I consider this bogus: Why in the world would one use "linux" for loading Xen?

Yet I'll commit this as-is anyway, as Marek has acked it, just with ...

> @@ -1404,7 +1427,7 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle,
>          /* Read and parse the config file. */
>          if ( read_section(loaded_image, L"config", &cfg, NULL) )
>              PrintStr(L"Using builtin config file\r\n");
> -        else if ( !cfg_file_name )
> +        else if ( !cfg_file_name && file_name)

... the style issue addressed here.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 13:08:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 13:08:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026345.1401528 (Exim 4.92)
	(envelope-from )
	id 1uUmKd-0004Os-U2; Thu, 26 Jun 2025 13:07:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026345.1401528; Thu, 26 Jun 2025 13:07: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 1uUmKd-0004Ol-RB; Thu, 26 Jun 2025 13:07:59 +0000
Received: by outflank-mailman (input) for mailman id 1026345;
 Thu, 26 Jun 2025 13:07: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 1uUmKb-0004Of-QM
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 13:07:57 +0000
Received: from DU2PR03CU002.outbound.protection.outlook.com
 (mail-northeuropeazlp170110003.outbound.protection.outlook.com
 [2a01:111:f403:c200::3])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9121482c-528e-11f0-b894-0df219b8e170;
 Thu, 26 Jun 2025 15:07:52 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by AS8PR03MB7669.eurprd03.prod.outlook.com (2603:10a6:20b:34f::9)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.29; Thu, 26 Jun
 2025 13:07:50 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%4]) with mapi id 15.20.8857.026; Thu, 26 Jun 2025
 13:07: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: 9121482c-528e-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=AYZV/2tbW9z3Ec7W5jklEmZsXsmPh7xErlnXCRIm8q3Pfos5FbpWWlhXIIEHi5o5Mjtfm7zdllJA+lARDR0dC6nEdBWg2lyaKXgP0X6sZadckwwDlNrVXZvI1FJaKt+8IUq21JBk7GCHEjkwYB+HsVIgWXxvZUP+4vNWoC4tBsGGXrqW+M4WXHclvOnYFQsZRFh2oXwNS3LRJi1nmi6KZwLjKdIVnRzeVvhXhcr+RWG6+osssjeICNlus2XBHPG1sJpvDTg2im2n7ud1atHkvpcMWOrXCdl4WEwt1jLIVJvb41tVU+ZaSQBikvIDOd3PjFGHtjnQxGVNIs/MwxouPg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=nQOXd2xuBmC0z2sS76ftQRZkVS8V/6CMt3/5wSiZYQE=;
 b=WqvLnHPfLepLdIyZ/zAiWBai7vT6DupsQDTr4xVGtvp20g9Iwl3L2b/Kr4dNN4wNlRY6i1MSX7avvX7ig8Zid48FXhQwWOYkGzwMqbL8aMaG1ND/5WbgDhbq2f7Hd//+ms+PV7IcoB367lzEuRQjPFWJDEPH0H7UdQJBEJHkvAcuz297wTCJEVIfGJ7RDAMwe07sS/BLUqPZ8hKlYeTUZg5qR4qZETB9QcovnrwK0ZLAZxxNCjpZidE3SM8uSr53ZCSXOtou304eQhXsmTVWFMyKFesO1pJYobLIQvhfBX/0SQROrPfTKPeJZ0g8k6zInGXdf758bZKXZcsD8/vLTg==
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=nQOXd2xuBmC0z2sS76ftQRZkVS8V/6CMt3/5wSiZYQE=;
 b=hRUPKNWGbWEZ70YRUDwW/rDL3zGzILd1MAXQ5JfdHVeZxulITf2UHB413lbLstk9O11rCqPK5JcXF5mPEReWAJW073qm3R9Ir5bRnoVlQQ8fs4dTnvsVOIIxcEX6eIpkAAMqCq5YTud8domR+nFR1rtfNaYqw/1N3Rf6IeZiGhT2zlzTSphjXFjsu1fZZF8vGT44QZuapy7RRdQxs4xqDvSpTJ/zxqyLrPjo0perUra9618bnvEufTTLom3cIrKgnYK6aGLwKhTsgdnJUYmGktf4BE8cOyNUjJNu31EVPaOUOGTXi9vkQmrm17ot0VUJSCnzmWoI/v57otKJH08ctA==
From: Oleksii Moisieiev 
To: Jan Beulich 
CC: "xen-devel@lists.xenproject.org" , Andrew
 Cooper , Anthony PERARD
	, Bertrand Marquis ,
	Juergen Gross , Julien Grall , Michal Orzel
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Volodymyr Babchuk ,
	Grygorii Strashko , Stefano Stabellini
	
Subject: Re: [RFC PATCH v4 5/8] xen/domctl: extend XEN_DOMCTL_assign_device to
 handle not only iommu
Thread-Topic: [RFC PATCH v4 5/8] xen/domctl: extend XEN_DOMCTL_assign_device
 to handle not only iommu
Thread-Index:
 AQHbyNXPDXt2FT3RV02cltfdm/Dd7rPdzmiAgCG+LgCACKrsAIACoXoAgAWykoCAA/lGgIAAq3gAgAB0qoA=
Date: Thu, 26 Jun 2025 13:07:50 +0000
Message-ID: <0cb693b6-c22c-41e2-b332-7b7e4134d0df@epam.com>
References: 
 <4f58bf9c47c40413ee9250c4cd21458382aac857.1747669845.git.oleksii_moisieiev@epam.com>
 
 
 
 <1780646c-cb6f-4508-86c8-a573fbc09f6a@epam.com>
 <1e116116-ddf7-4640-9809-2502203abe46@suse.com>
 <3e190e60-74a4-4565-acae-3b8602a4c46e@epam.com>
 <8bb4e188-eb3b-4ee3-88cc-93c826b04ef8@suse.com>
In-Reply-To: <8bb4e188-eb3b-4ee3-88cc-93c826b04ef8@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB8946:EE_|AS8PR03MB7669:EE_
x-ms-office365-filtering-correlation-id: 65be1eef-384d-42d9-2442-08ddb4b27436
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|376014|7416014|1800799024|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?dnd2VWRwTk5YZFdqb1FOTWl5M2dtdEJtS3preXhTVDlZWUQ2NGJqcDdXaXZX?=
 =?utf-8?B?TWNWUmhvQU5ueXoyc0ZjREdMcE02WjBhd3kwdnpJS0x1ZU1BLzQzMk9TMHRY?=
 =?utf-8?B?WWNCNXZQWUdzTS82RXhjaDZvV1kvQjUveS9zTHZzTE9nbG9ZOGU1TitTaitO?=
 =?utf-8?B?L1hSdncrQ2pVR1dXVFRYWGQycFd4Z21va01XVDlWcXVDdEhXUlFBbHdiT01m?=
 =?utf-8?B?Y25kaDBTcStSbVNnYWVnbTdWU2cyb0pLT3RRdjZRSVRpbHAzZjdvUTFrcjBS?=
 =?utf-8?B?WnkweHVualE1eFZRckRjK09MT2dPamNhdHNyWEJWRWtOMDJvdTNDSVdEUEda?=
 =?utf-8?B?TmRWaGxvTCtRT1V6YTE4UTB1d0h5WEc0SC9aeXlOWGhkN0tzQU9vV0xPc0Ja?=
 =?utf-8?B?Qkp6Ynl2eDN3dC9pTysyYTRpWjcxZEc5cU1rNGRjUjhCb1JhMXFmcnd3d1Bk?=
 =?utf-8?B?b2wvOHo0VGtiaHAxeXhFRENRR1IwMWxuNjJCcE80bFQvSXBGMGNMVm5nMERQ?=
 =?utf-8?B?bjdNMHJkS1pMenpVMWdld1RqOUZ2SGVCTjBxK3BMNnY5eG5OWVUwQlpXb0lx?=
 =?utf-8?B?S0hrNHBnNElxMTF0clNvcVdkcURuV1NibTVzQTZTZ3RDbEFqUHlKdlhTK3l1?=
 =?utf-8?B?YVZZV3hOaHd6RkNPbXlSellQVDAwTnFsWWN5QkhyODkrR3pmWWM5YXFFVDhS?=
 =?utf-8?B?cE5qMGJjK2VXdm9iR0xpOGxETTlyZmdMbEtuUjBaa21NZGJWZklIUmtIU010?=
 =?utf-8?B?R1NDZWV1aDQ2N0g2WHNHOEhpSlMzdU5LbnJ1cUZ5ZENiaHRGTEU5eFR4THky?=
 =?utf-8?B?MTBDWEl2Tno4cVF4d1lyT2tsM1JnMkluQ09lWk94SzZ5NU9zalUyZlc1RUxV?=
 =?utf-8?B?R1BkNkh2eFF6L0pUR29BTGYwUDRVdStXdjRFcnBrdVVld2IvUnE5bWRvWEt5?=
 =?utf-8?B?MnU3b0FlaFVjaDlER0RiQmFwanUrY25GQ1hqTmNDank0UWJUU1p6VmtTTGRR?=
 =?utf-8?B?Z3pMc1pGUHN3SFZGOVJpWWt4QnRxSmxsTXk4TThwSW5IZVlMMjYxRmN2dFVv?=
 =?utf-8?B?aGcrbW9xMDhtdXFYOUxWNnZPTkQ5MUpma0NwV2NQcS92ckVPczk2NGFtQ1NC?=
 =?utf-8?B?TmhqakxyVU9IR1Zna2w1cDJZTWI1L1ViUkFUWndDVXpJVGNaM3Nzc1dVMnRT?=
 =?utf-8?B?UGtERS84R2pNTE1qWm5nYXdHK2RQLzZYUm9SNDExNkcwcEZMR0ZLdGsvRGRm?=
 =?utf-8?B?dENyb25RZDJCQ2IxMG0xR2d4KzdjQW5VNnVPTVdtR2lPeEcyaW8vNm1UVFZD?=
 =?utf-8?B?OVZXSUZhemZKeE0yUWQrUFFGVVNEZWhWeHREdTY4UitPcG80M1VyWHBkZDJZ?=
 =?utf-8?B?SW5EUm5GQmQzR0xWdUFhbFlTazJjRnZxOStKVTllMFlVY1crcGtJWDE0MEtZ?=
 =?utf-8?B?QnVWU1FLbFo2TEN0VGhBdStaSXM1eXJxVjd0cmJhNkNleUtNTS9Eek54dTYy?=
 =?utf-8?B?ZTF2SDBxaStMeGJDdFF5bDA2cnVtVVVEZ1l0akt6UDhFbjkvMXhQTWtYdGEz?=
 =?utf-8?B?MS9OUVdyNTloMEJ5bHc5ZlZsUWFLaGJsVlcxMWN0OVY1V1ZMeFFFOGsyU1FE?=
 =?utf-8?B?NllycWtWQUVoNFM4Q2ZuZW5qbGR1ckhFMHZzWW9JYXhGTE02d1k0aDNZMHho?=
 =?utf-8?B?MGpHZEN1d3lCNkZrb1QwYy9mcEYyLy9OQWdVejZJUW0rZG45Ri9mV0NWYkZ2?=
 =?utf-8?B?ZFdBNXJndXcrc2poV1FkbklzTmtNZG5vV0pnWmh3ZkhNSUo5UGJwUGt0aWxk?=
 =?utf-8?B?d0NHcTlOaTUzOXJzT1NmeXZ6RHpaVm1aU2wza1BMZkNid0ZnLzZLNkhEcDIy?=
 =?utf-8?B?NkxJNkZmcHo2RTJ4QUVoTjQ2THg4VVJGZG9sajQybVZDbGhEYXp0cGRpd3JZ?=
 =?utf-8?Q?n3ooCobwzNg=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?MXJTMEdKamtzbGh3N21yWEhoUWxISlM0d0pMTTZ1THF1NHcyMjlzS3k4L1lG?=
 =?utf-8?B?S01DclVpVy9mNkJZZGx3aDBPbEhZL05JZ2V4dEx4ak9IV0g0bHE0T0p0bXFB?=
 =?utf-8?B?ZXE1VmVkNVBwV3dHaFEva0YyRHpqYld5VS9DWDVJQ1JDWkFKSGJpN2pBcGJB?=
 =?utf-8?B?anZiL05pemVVNnBrck9EdzRlOUdBYjdkQVVXcjk4dnpWMkFicGcvY3ViZklx?=
 =?utf-8?B?ZExpZzFFTWMvazNaRi93azJCRDJBMUI5UEViMm84d2xCYWdFTHM3ajBmT1Jj?=
 =?utf-8?B?WkIrRXY5SVJNN2dkM3pYMm82a2o0cmpBWjJTbno4OXpjeUx3ZlJQeERlSENq?=
 =?utf-8?B?T3B2czF5bFgxVkF3UlBDUVloeEhMeDZYM1pTR3p3R255UjMvSWxWbjJtYWJt?=
 =?utf-8?B?SXlmOVNaUmdLVFZubFRjcW1UdXFiRENGcVpjWEZod0ZlZ1dkemFMWUxmRkV0?=
 =?utf-8?B?REhPanNLU1ZpRTAwbUo5bHpralZtRHhiVE92eEczVk5kbVlRWExsTlhobmZR?=
 =?utf-8?B?aWVFL0FJWHV6MUJBalhPT2pSMk96bTNrdEJKTkdxS2Fwc0xPbk5hZUtZZkZK?=
 =?utf-8?B?VTRGckZaM1prNWE5K2Y0NGtDak44a01BWEw2dm1ka3hXVGIzVTBwbEpxYVRw?=
 =?utf-8?B?RUI0R2xlWEYrQm9SZXFKbUhiZDZGT0RrTXJoQUQxTHBVQzNFcXZRaVA3d0FY?=
 =?utf-8?B?UGs2a0Y4Z2liTm9CZkxVenVMRTlRYUJnaFNkSXpoNzM1L3IxRHF2VE9MWTBU?=
 =?utf-8?B?c29tMkZhNkZzaThiNTlLK2FyZVVCc1Z2YVR0Q0ZlcEtEV1NZL3picFRvanRJ?=
 =?utf-8?B?WGVhWk9NeHB1T01SWHlleFgxc1RBdVlpOWZ3NDBPNTRGN2NQWVh6aitNYnFO?=
 =?utf-8?B?c1YxYUUvWmpXUDI2N2NucEE2NXBtWkg4WmlONHg3di9kc2hqRVJKdjdCcGtT?=
 =?utf-8?B?cmoxZXdiWDZjNlE3ZkJ5aWdwZFZQSVFEN1FYelh1b3g3TFB3VzBxZGNUZWNy?=
 =?utf-8?B?cm1YbzlCTzI5MExTOFRockpKQzFTR0JlSWVYeitjQkNhSnZQTHVLMFhSMVBr?=
 =?utf-8?B?MFZaSkZxN0dGditlNmhsRitPZVMzb1JlNlRPYUhqTDdzdTFXa0U2cklvVnRs?=
 =?utf-8?B?bTZKQjFTc1NTemFydXdUSjMySDBSV09sdlh1L3JwY1pYSis2YkNlQkh0VHpF?=
 =?utf-8?B?ZVYyeXJVYXkrS0wrTTF5bE95Qk0zTXdxTFd1VGlLeUpsTjdPNGdLeHhKMys4?=
 =?utf-8?B?SnNQRnJDWGIzNnlrUndmOEp5ZnkvZUhORzZNbVNGN2M2NTY4aThZVjMyZW9T?=
 =?utf-8?B?NkNoa3dXcDQyZyt5OUJZUFBJcXJvYkVPUHYyTEozdkhpRmd5aFROdk1RNFFM?=
 =?utf-8?B?NHhWK2tIcjFDVnl3dEZYa3ZQSWZyQ3l2VnJIZUFBNHR1WGVGVDNyVHIrRlh0?=
 =?utf-8?B?YVBrMWYybGY0OHlDV1h6SFFFbkxlaGE1eEdMN1hncjFpR3ZJMnBwem5RZFor?=
 =?utf-8?B?a3c5dkg0ZXZXK3hCNVFKUXB5S3c5b0p2bjJ4d2xDRUZCS2x2eDBRQTJBWExw?=
 =?utf-8?B?R25hNy9mTERmK2daMjRZcm56bDZVQStBT003ak5sNi9jZDlhcmRBYUZQUEJO?=
 =?utf-8?B?WlI1aVN5UjhmbnJlSytFOWZWLzRFUXcvZkFDRVg5bWh0MXllZk1MWU9OeVdv?=
 =?utf-8?B?SkpIekU1NzZjMmpaSVF0OWFFb1RhWUc1VGdhY2MySEZwK3duVVI1RldLcUpI?=
 =?utf-8?B?QVdHb01OQ0lLVFRVWldocWtGeHA3eEo5NnNMOERlaHFDbVoxcHBRSjRnU1NY?=
 =?utf-8?B?YTJpS3FNY2VJTllwUFlWalczR21PQlFhT0dTU1ArNHdPY29RcWw4TTlWbkFt?=
 =?utf-8?B?OHcrTmdSUmZuTCtIYnZua3ZlZE9HSHV2NGk4L040VjRZZHRJWm1lVytlL2RF?=
 =?utf-8?B?eUU2b3N1UC96R3ZIMUNoS2Q0WXVaSFRFcU1IOTZVYUJsN2d3MlpwdTYyZWhu?=
 =?utf-8?B?cmNyeWcxTTROeERwSXZ2TFpsRkU2ZmRQNnhFaEVJNHU3aVQrTjl0S1IyMUtQ?=
 =?utf-8?B?Q0hvdFd6SnFoSGI5OUJUK1l5L2JOaHRUbmVwZHRoMk8rS1Z3SGxUVHRCb0lz?=
 =?utf-8?B?Q0FHVytxQUtOQndFR3ViSHN6bmxMVk1QNGRQR3JNdFJoNVIwS2lVd1YrbWsy?=
 =?utf-8?B?bmc9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <221FA101A8A34440B86CD74ED8ABCA22@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: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 65be1eef-384d-42d9-2442-08ddb4b27436
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2025 13:07:50.3108
 (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: FShf/aZHNFSFWOjk0EypnMVJMpldsVSwB4v2gT0c8yaD0u9/YA2yA9sElKaTEWjiQhUapVprKzn562K+FY+D4D+52bn2Hulg5Ip+mORtmSo=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7669

DQpPbiAyNi8wNi8yMDI1IDA5OjEwLCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMjUuMDYuMjAy
NSAyMTo1NiwgT2xla3NpaSBNb2lzaWVpZXYgd3JvdGU6DQo+PiBPbiAyMy8wNi8yMDI1IDEwOjE1
LCBKYW4gQmV1bGljaCB3cm90ZToNCj4+PiBPbiAxOS4wNi4yMDI1IDE4OjE1LCBPbGVrc2lpIE1v
aXNpZWlldiB3cm90ZToNCj4+Pj4gT24gMTgvMDYvMjAyNSAwMzowNCwgU3RlZmFubyBTdGFiZWxs
aW5pIHdyb3RlOg0KPj4+Pj4gT24gVGh1LCAxMiBKdW4gMjAyNSwgT2xla3NpaSBNb2lzaWVpZXYg
d3JvdGU6DQo+Pj4+Pj4+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjaS5j
IGIveGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjaS5jDQo+Pj4+Pj4+PiBpbmRleCBlMTUyMmUxMGUy
Li44ZWZkNTQxYzRmIDEwMDY0NA0KPj4+Pj4+Pj4gLS0tIGEveGVuL2FyY2gvYXJtL2Zpcm13YXJl
L3NjaS5jDQo+Pj4+Pj4+PiArKysgYi94ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NpLmMNCj4+Pj4+
Pj4+IEBAIC0xMjYsNiArMTI2LDQzIEBAIGludCBzY2lfYXNzaWduX2R0X2RldmljZShzdHJ1Y3Qg
ZG9tYWluICpkLCBzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKmRldikNCj4+Pj4+Pj4+ICAgICAgICAg
IHJldHVybiAwOw0KPj4+Pj4+Pj4gICAgICB9DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gK2ludCBzY2lf
ZG9fZG9tY3RsKHN0cnVjdCB4ZW5fZG9tY3RsICpkb21jdGwsIHN0cnVjdCBkb21haW4gKmQsDQo+
Pj4+Pj4+PiArICAgICAgICAgICAgICAgICAgWEVOX0dVRVNUX0hBTkRMRV9QQVJBTSh4ZW5fZG9t
Y3RsX3QpIHVfZG9tY3RsKQ0KPj4+Pj4+Pj4gK3sNCj4+Pj4+Pj4+ICsgICAgc3RydWN0IGR0X2Rl
dmljZV9ub2RlICpkZXY7DQo+Pj4+Pj4+PiArICAgIGludCByZXQgPSAwOw0KPj4+Pj4+Pj4gKw0K
Pj4+Pj4+Pj4gKyAgICBzd2l0Y2ggKCBkb21jdGwtPmNtZCApDQo+Pj4+Pj4+PiArICAgIHsNCj4+
Pj4+Pj4+ICsgICAgY2FzZSBYRU5fRE9NQ1RMX2Fzc2lnbl9kZXZpY2U6DQo+Pj4+Pj4+PiArICAg
ICAgICByZXQgPSAtRU9QTk9UU1VQUDsNCj4+Pj4+Pj4gQXJlIHlvdSBzdXJlIC1FT1BOT1RTVVBQ
IGlzIHRoZSByaWdodCBlcnJvciBjb2RlIGZvciB0aGUgMyBjaGVja3MgYmVsb3c/DQo+Pj4+Pj4g
VGhlIC1FT1BOT1RTVVBQIGNvZGUgaXMgdXNlZCBiZWNhdXNlIHRoaXMgaXMgcGFydCBvZiBhIGNo
YWluZWQgY2FsbCBhZnRlcg0KPj4+Pj4+IGlvbW11X2RvX2RvbWN0bCwgYXMgc3RhdGVkIGluIHhl
bi9jb21tb24vZG9tY3RsLmM6ODU5LiBUaGUNCj4+Pj4+PiBYRU5fRE9NQ1RMX2Fzc2lnbl9kZXZp
Y2UNCj4+Pj4+PiBjYWxsIGlzIGV4cGVjdGVkIHRvIGhhbmRsZSBhbnkgRFQgZGV2aWNlLCByZWdh
cmRsZXNzIG9mIHdoZXRoZXIgdGhlIERUDQo+Pj4+Pj4gZGV2aWNlIGlzDQo+Pj4+Pj4gcHJvdGVj
dGVkIGJ5IGFuIElPTU1VIG9yIGlmIHRoZSBJT01NVSBpcyBkaXNhYmxlZC4NCj4+Pj4+PiBUaGUg
Zm9sbG93aW5nIGNhc2VzIGFyZSBjb25zaWRlcmVkOg0KPj4+Pj4+DQo+Pj4+Pj4gMS4gSU9NTVUg
UHJvdGVjdGVkIERldmljZSAoU3VjY2VzcykNCj4+Pj4+Pg0KPj4+Pj4+IElmIHRoZSBkZXZpY2Ug
aXMgcHJvdGVjdGVkIGJ5IHRoZSBJT01NVSBhbmQgaW9tbXVfZG9fZG9tY3RsIHJldHVybnMgMCwN
Cj4+Pj4+PiB3ZSBjb250aW51ZQ0KPj4+Pj4+IHByb2Nlc3NpbmcgdGhlIERUIGRldmljZSBieSBj
YWxsaW5nIHNjaV9kb19kb21jdGwuDQo+Pj4+Pj4NCj4+Pj4+PiAyLiBJT01NVSBEaXNhYmxlZCAo
LUVPUE5PVFNVUFAgZnJvbSBpb21tdV9kb19kb21jdGwpDQo+Pj4+Pj4NCj4+Pj4+PiBJZiBpb21t
dV9kb19kb21jdGwgcmV0dXJucyAtRU9QTk9UU1VQUCwgaW5kaWNhdGluZyB0aGF0IHRoZSBJT01N
VSBpcw0KPj4+Pj4+IGRpc2FibGVkLA0KPj4+Pj4+IHdlIHN0aWxsIHByb2NlZWQgdG8gY2FsbCBz
Y2lfZG9fZG9tY3RsLg0KPj4+Pj4gT0sgdGhpcyBtYWtlcyBzZW5zZS4gIEkgdGhpbmsgaXQgaXMg
T0sgdG8gaGF2ZSBhIHNwZWNpYWwgZXJyb3IgY29kZSB0bw0KPj4+Pj4gc2F5ICJ0aGUgSU9NTVUg
aXMgZGlzYWJsZWQiIGJ1dCBJIGRvbid0IGtub3cgaWYgaXQgaXMgYSBnb29kIGlkZWEgdG8gdHJ5
DQo+Pj4+PiB0byB1c2UgLUVPUE5PVFNVUFAgZm9yIHRoYXQuIC1FT1BOT1RTVVBQIGNvdWxkIG1l
YW4gYSBoeXBlcnZpc29yDQo+Pj4+PiBjb25maWd1cmF0aW9uIHdpdGggZG9tY3RsIGRpc2FibGVk
LCBmb3IgaW5zdGFuY2UuDQo+Pj4+Pg0KPj4+Pj4gSXQgbWlnaHQgYmUgd2lzZXIgdG8gdXNlIGEg
ZGlmZmVyZW50IGVycm9yIGNvZGUuIE1heWJlIEVOT0VOVD8NCj4+Pj4+DQo+Pj4+IEkgc2VlIHRo
YXQgaW4gdGhlIGZvbGxvd2luZyBjb21taXQ6DQo+Pj4+DQo+Pj4+IDcxZTYxN2E2YjggKHVzZSBp
c19pb21tdV9lbmFibGVkKCkgd2hlcmUgYXBwcm9wcmlhdGUuLi4sIDIwMTktMDktMTcpDQo+Pj4+
DQo+Pj4+IC1FTk9TWVMgcmV0dXJuIGNvZGUgd2FzIGNoYW5nZWQgdG8gLUVPUE5PVFNVUFAgaW4g
aW9tbXVfZG9fZG9tY3RsLg0KPj4+Pg0KPj4+PiBJdCdzIG5vdCBjbGVhciB0byBtZSB3aHkgdGhp
cyB3YXMgZG9uZSBmcm9tIHRoZSBjb21taXQgZGVzY3JpcHRpb24uDQo+Pj4gVGhpcyBoYXMgYmVl
biBkaXNjdXNzZWQgbWFueSB0aW1lcyBlbHNld2hlcmUuIE1hbnkgb2Ygb3VyIEVOT1NZUyB1c2Vz
IGFyZQ0KPj4+IHNpbXBseSB3cm9uZy4gRU5PU1lTIGhhcyB2ZXJ5IGxpbWl0ZWQgYXBwbGljYWJp
bGl0eTogVW5hdmFpbGFiaWxpdHkgb2YgYQ0KPj4+IHRvcC1sZXZlbCBoeXBlcmNhbGwgKG9yaWdp
bmFsbHk6IHN5c2NhbGwpLg0KPj4+DQo+PiBXaGF0IGlzIHlvdXIgb3BpbmlvbiBhYm91dCBjaGFu
Z2luZyBpdCB0byAtRU5PRU5UIHRvIHNheSAidGhlIElPTU1VIGlzDQo+PiBkaXNhYmxlZCIgYXMg
U3RlZmFubyBzdWdnZXN0ZWQgaW4gWzBdPw0KPj4NCj4+IFswXTogaHR0cHM6Ly9saXN0cy54ZW4u
b3JnL2FyY2hpdmVzL2h0bWwveGVuLWRldmVsLzIwMjUtMDYvbXNnMDEyMzMuaHRtbA0KPiBUbyBt
ZSwgRU5PRU5UIGlzIGNsb3NlciB0byBFTk9ERVYsIGFuZCBoZW5jZSBub3Qgb3Zlcmx5IGFwcGxp
Y2FibGUgaGVyZS4NCj4gSWYgeW91IHdhbnQgdG8gYXZvaWQgRU9QTk9UU1VQUCBmb3Igd2hhdGV2
ZXIgcmVhc29uLCBob3cgYWJvdXQgRU5YSU8gb3INCj4gRUlPPyAoRVBFUk0gbWlnaHQgYWxzbyBi
ZSBhbiBvcHRpb24sIGJ1dCB3ZSBhc3NpZ24gdGhhdCBhIGRpZmZlcmVudA0KPiBtZWFuaW5nIGdl
bmVyYWxseS4pDQo+DQo+IEphbg0KDQpNYXliZSAtRU5PREVWIGlzIGEgYmV0dGVyIGNob2ljZSBi
ZWNhdXNlIGlvbW11X2RvX3BjaV9kb21jdGwgYW5kDQppb21tdV9kb19kdF9kb21jdGwgcmV0dXJu
IHRoaXMNCg0KY29kZSB3aGVuIHNvbWUgZmVhdHVyZSBpcyBub3Qgc3VwcG9ydGVkLg0KDQpJIHRo
aW5rIC1FSU8gb3IgLUVOWElPIGFyZW7igJl0IHN1aXRhYmxlIGhlcmUgc2luY2Ugd2XigJlyZSBw
bGFubmluZyB0byBzZW5kDQp0aGlzIG1lc3NhZ2Ugd2hlbiB0aGUgSU9NTVUgaXMgZGlzYWJsZWQu
DQoNCldoYXQgZG8geW91IHRoaW5rPw0KDQpXQlIsDQoNCk9sZWtzaWkuDQoNCg0K


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 13:11:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 13:11:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026352.1401539 (Exim 4.92)
	(envelope-from )
	id 1uUmNY-0005vW-CL; Thu, 26 Jun 2025 13:11:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026352.1401539; Thu, 26 Jun 2025 13: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 1uUmNY-0005vP-8H; Thu, 26 Jun 2025 13:11:00 +0000
Received: by outflank-mailman (input) for mailman id 1026352;
 Thu, 26 Jun 2025 13:10: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 1uUmNX-0005vJ-Ka
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 13:10:59 +0000
Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com
 [2607:f8b0:4864:20::32e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ffe70581-528e-11f0-a30f-13f23c93f187;
 Thu, 26 Jun 2025 15:10:58 +0200 (CEST)
Received: by mail-ot1-x32e.google.com with SMTP id
 46e09a7af769-739f2508ffaso684747a34.2
 for ; Thu, 26 Jun 2025 06:10:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ffe70581-528e-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750943457; x=1751548257; 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=Rx5FUsSKfgP2TJrEREDe0yQWf3Zalpe0SRkPT5EUUFI=;
        b=WSaBuJvdGcTictjU8xcyVs+x+hCcHHz/GTlqIaqcfWO+AQjL299ihjc4SCv61rxNC8
         7IkvdxUx2yoPcz/aqaFa54L8QYkazl2QtHIGOaknhKWeJJnQ8WYVeD+Zbe+dkykZs48o
         DeL/mr7Qyf5ebKGhVwZUpcps6kwG+QYUk3Sdg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750943457; x=1751548257;
        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=Rx5FUsSKfgP2TJrEREDe0yQWf3Zalpe0SRkPT5EUUFI=;
        b=B6dymB1ECbH2EURupUQmAVxMsLWGVWJ5+7mNWDIlX/qQCyyJF6CmBbgNJkG4KQFEma
         OFMu0gG0/OZOdLQaQn1hnRyejYDf1UqJfoBU7oWh/zg2NItXHXRUiIsbmw+5Tkn/5o1m
         whkGUlNpTF5FFd7Nj5Vpyd9r5as207Q8JiEItGr6qteKNqDm5NYp/Bbb5+w3wZKKXG7l
         rjwjwyh3zBycYmxLYutwIwNqpzLBP9ooJwUB6Pptq7d/LL/AQmF62CvtLrIYWuc3YlZn
         qpAwfZx7j79APZcHZQ1/sUYl3nLTLGnceY3ow94np5o85pftVP3NlHQh3ufJi+G2SCAK
         xe7Q==
X-Forwarded-Encrypted: i=1; AJvYcCVh/vLDPq8pfhFck0iy67Nu1NCuLRgUsuNcTdZNr9Qin7G6FzpEutDLir6yVB5lKWW0Jcn79J1/e7w=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwW32/WUwVf732PE92SgV66Yn2Ivp4O5sryTs9lsKP/7Jyr4Zdx
	Q/dUqCxWXlN/F0la1uxGqEi9ci8gRzCg03uTIfnmRaisEqlyCxzK6ti9NHmiwHxWS82uIkM1omU
	AImxkpcWtfqDU/l8xYPL4MwI9f4hkhNlCHTkKLx9AuQ==
X-Gm-Gg: ASbGnct4mtGapVoLyfKYAknX/MItE18P+WOkqr8vD07fNpO/hrUiNNaKGghlKROus/x
	gmM41fFIlkw6WHxtvAls2Z5J5zcnbAaHqCfpM+S0ZNNpMnHpEjIMrQRYlGhg7qjw2VwTTOE/bSM
	78SO7pRQWu7/5v9gMcbaeJC6FmCA/kadqGWXVYiF4J
X-Google-Smtp-Source: AGHT+IEofwggQsHZnosStN/XNnzweBloEtubNd/yIfvbRhRFw27NlRSp59qIhoMxarRc2ydLIccux7f3dP7dYLxWy/o=
X-Received: by 2002:a05:6871:70f:b0:2d5:4d2d:9525 with SMTP id
 586e51a60fabf-2efb24ee421mr5193806fac.8.1750943457363; Thu, 26 Jun 2025
 06:10:57 -0700 (PDT)
MIME-Version: 1.0
References: <20250625073408.7496-1-frediano.ziglio@cloud.com>
 <20250625073408.7496-2-frediano.ziglio@cloud.com> 
In-Reply-To: 
From: Frediano Ziglio 
Date: Thu, 26 Jun 2025 14:10:46 +0100
X-Gm-Features: Ac12FXxVjCMfQen9NpeMclxAomZj8RkryvC3ePbKWf-m-qiWpTT2YqUCcLkMESw
Message-ID: 
Subject: Re: [PATCH v3 1/3] xen/efi: Handle cases where file didn't come from ESP
To: Jan Beulich 
Cc: "Daniel P. Smith" , 
	=?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= , 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 26, 2025 at 1:53=E2=80=AFPM Jan Beulich  wro=
te:
>
> On 25.06.2025 09:34, Frediano Ziglio wrote:
> > A boot loader can load files from outside ESP.
>
> I think it would have helped if you said somewhere what ESP is. People ma=
y
> think of this as UEFI System Partition (or some such), which doesn't coll=
apse
> to the acronym used.
>

The acronym is EFI System Partition (ESP).
Most files and prefixes use "efi" more than "uefi".

> > --- a/xen/common/efi/boot.c
> > +++ b/xen/common/efi/boot.c
> > @@ -443,6 +443,18 @@ static EFI_FILE_HANDLE __init get_parent_handle(co=
nst EFI_LOADED_IMAGE *loaded_i
> >      CHAR16 *pathend, *ptr;
> >      EFI_STATUS ret;
> >
> > +    /*
> > +     * In some cases the image could not come from a specific device.
> > +     * For instance this can happen if Xen was loaded using GRUB2 "lin=
ux"
> > +     * command.
> > +     */
>
> I consider this bogus: Why in the world would one use "linux" for loading=
 Xen?
>

The question could be why "linux" for efi is very different from
no-efi "linux" not having much to do with Linux kernel.
One answer is that EFI is dominated by PE format and so "linux"
command just use PE standard entry, relocations and "LoadOptions" and
use specific protocols (like LoadFile2 here) instead of Linux standard
ways.

> Yet I'll commit this as-is anyway, as Marek has acked it, just with ...
>
> > @@ -1404,7 +1427,7 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE =
ImageHandle,
> >          /* Read and parse the config file. */
> >          if ( read_section(loaded_image, L"config", &cfg, NULL) )
> >              PrintStr(L"Using builtin config file\r\n");
> > -        else if ( !cfg_file_name )
> > +        else if ( !cfg_file_name && file_name)
>
> ... the style issue addressed here.
>

Done, sending v4

> Jan

Frediano


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 13:11:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 13:11:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026354.1401551 (Exim 4.92)
	(envelope-from )
	id 1uUmNg-0006Eo-KZ; Thu, 26 Jun 2025 13:11:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026354.1401551; Thu, 26 Jun 2025 13:11:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUmNg-0006Eh-I4; Thu, 26 Jun 2025 13:11:08 +0000
Received: by outflank-mailman (input) for mailman id 1026354;
 Thu, 26 Jun 2025 13:11: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 1uUmNf-0005vJ-8B
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 13:11:07 +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 05115511-528f-11f0-a30f-13f23c93f187;
 Thu, 26 Jun 2025 15:11:06 +0200 (CEST)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3a50fc7ac4dso498087f8f.0
 for ; Thu, 26 Jun 2025 06:11:06 -0700 (PDT)
Received: from localhost.localdomain (253.226.6.51.dyn.plus.net.
 [51.6.226.253]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a6e806916esm7351356f8f.43.2025.06.26.06.11.05
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 26 Jun 2025 06:11:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 05115511-528f-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750943466; x=1751548266; 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=s6BJndVvhk0Ds/aN/1ClgpsDUl6Okek1m4XQxq4tbbw=;
        b=IeQgBiiU8ztHIulSYcDyU2SUlF4UsIKba5NXk6S7pRXltnHO6Ami/Qppg6Mw1nEl/0
         b8vXkwkDIXRjMkvbLIVLydFRy9RCU7XL7mFlSw+ruKWN7XV6xfDfVQGfNXugxIgomW8E
         DzU03ZYx0KJbZxAt9EAzaJ3RXE1CZaYjxQbs8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750943466; x=1751548266;
        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=s6BJndVvhk0Ds/aN/1ClgpsDUl6Okek1m4XQxq4tbbw=;
        b=npt2skFT5JuKAJV8VoPT3M2xCLyKyKX9IvI+y1Z5kQXUPS2xZ7CIVXuyVOGCAxoTIz
         LEMV8tdqyLDDbOjY1PyFJz3LHTy8Q7MvLV5laLxxl8/Fm8f/WqnOr/nX9tLngkwRcDLA
         D/jFyWIpNqyBUSs2lfQNKaW/TjimrxOM/qYonf5CINcjXbogczCkhIkL18BBHJtMXQF/
         RCE4nbrWujbcvTX9y9nxoSm/1qI3hIixff67nathCMD1OUATMxg9W1HLeNIXXA5oTW4P
         p8T3emjMGI/MFIQ+KXpkGgZ7sBKGT7j6t/kjzeP5dMQmVkGHTPeWxC2khCWBScFfxIW9
         iWuw==
X-Gm-Message-State: AOJu0Yw+kc2pPUz3vDbOautbmH01EDPGOTqMFkwnwgprXls62d2c5DnV
	u+Z0b2i+18rL3cGvYQeK4/Bv4iUh5VruWlF4Um9PM6Ql+v9BNIsKpHxR77GqkUFhZz4uwDCQJ7c
	4HDDot3c=
X-Gm-Gg: ASbGncvncieBVZqz0xEYwqMmWtELYSROW4SoHos9qyY49xC2LKrw7l56P0Mfgd311Uf
	nU6AEH/j9bYgSYyFHQ4Hg+/q6KGMZIWwpbeZFsMCWXq1L8UVT3Rf+bemRWsVBfN6Nr4pcRXlQLt
	SVACeDpF09wMj0wsEUvXwlVC4uRXTkW+y9IdiZ1O+8NJ8CxiS1DYqpDIMgVAo9/bsuRvTDiBJPY
	23n+iwuK9moBhcTdLY8jdX1VfD7A+KBibz5BmOqNrPxkru+dpCCePJ0uzgAq/dOgezSguLoEfI1
	Hq/MkjzMS7OZUXw0DVy8gnbtwhqCC3SBuyZz7O5cdBJIdLwnliKocfTULsORInMlqVBqyniOjt5
	0kn41H3Wo+cjTJ8RSdOL8MAgOZuM73g==
X-Google-Smtp-Source: AGHT+IFBB6Ws21E1/GkABDlKkF9TxdfI+48vAclDO2Kyd8hhNU8tB1webCV5hV3qXq6B8uR4cIb/6A==
X-Received: by 2002:a05:6000:2c0d:b0:3a4:ea40:4d3f with SMTP id ffacd0b85a97d-3a6ed6717e2mr6058709f8f.53.1750943465951;
        Thu, 26 Jun 2025 06:11:05 -0700 (PDT)
From: Frediano Ziglio 
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio ,
	"Daniel P. Smith" ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Jan Beulich 
Subject: [PATCH v4 0/3] xen/efi: Make boot more flexible, especially with GRUB2
Date: Thu, 26 Jun 2025 14:10:52 +0100
Message-ID: <20250626131059.61894-1-frediano.ziglio@cloud.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The combination of GRUB2, EFI and UKI allows potentially more flexibility.
For instance is possible to load xen.efi from a no ESP partition leaving
a boot loader like GRUB2 taking care of the file loading.
This however requires some changes in Xen to be less restrictive.
Specifically for GRUB2 these changes allows the usage of "chainloader"
command with UKI and reading xen.efi from no ESP (so no DeviceHandle
set) and usage of "linux" and "initrd" commands to load separately
the kernel (embedding using UKI) and initrd (using LoadFile2 protocol).

Changes since v1:
- keep read_file fatal when it was so;
- attempt to use LoadFile2 after trying object section;
- minor changes (see details on specific changes).

Changes since v2:
- update read_file style;
- added acked-by.

Changes since v3:
- style update;
- coherency changes for LoadFile2.

Frediano Ziglio (3):
  xen/efi: Handle cases where file didn't come from ESP
  xen/efi: Support loading initrd using GRUB2 LoadFile2 protocol
  xen/efi: Update error flow for read_file function

 xen/common/efi/boot.c     | 177 +++++++++++++++++++++++++++++---------
 xen/include/efi/efidevp.h |   2 +
 xen/include/efi/efiprot.h |  19 ++++
 3 files changed, 159 insertions(+), 39 deletions(-)

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 26 13:11:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 13:11:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026355.1401562 (Exim 4.92)
	(envelope-from )
	id 1uUmNh-0006Tx-SW; Thu, 26 Jun 2025 13:11:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026355.1401562; Thu, 26 Jun 2025 13:11: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 1uUmNh-0006Tq-Of; Thu, 26 Jun 2025 13:11:09 +0000
Received: by outflank-mailman (input) for mailman id 1026355;
 Thu, 26 Jun 2025 13:11: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 1uUmNg-0005vJ-Bw
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 13:11:08 +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 05b626fc-528f-11f0-a30f-13f23c93f187;
 Thu, 26 Jun 2025 15:11:08 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-453634d8609so7285825e9.3
 for ; Thu, 26 Jun 2025 06:11:07 -0700 (PDT)
Received: from localhost.localdomain (253.226.6.51.dyn.plus.net.
 [51.6.226.253]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a6e806916esm7351356f8f.43.2025.06.26.06.11.06
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 26 Jun 2025 06:11:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 05b626fc-528f-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750943467; x=1751548267; darn=lists.xenproject.org;
        h=content-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=19ROcQ+NE6uRH9cKCCikx8gAVzBifn0kY2OpATrBDp8=;
        b=aCC5N2EkddFl4s3faYTpbsetQEtfhCRRkP4qy5/H2PMzINxkPi/s5cjPOEKlftO7V6
         L/lSioXvfoZq95LXx1+bJnRue3o2BWCdQT0xzeTMOb2KLd1xLpesU1DBFNT1FVtO+D7G
         sI4IegTydZ5YCzVEMxB2TRwt4OJoVoZnpQLjQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750943467; x=1751548267;
        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=19ROcQ+NE6uRH9cKCCikx8gAVzBifn0kY2OpATrBDp8=;
        b=nmQYjGg5x81Bd2lCiPUUypLHoTuNWUDX2yonL+yj7vs3W8Yt3OqSqSWwhl/gCo4yRn
         zJUwxuoolP8Yn37JKFb4KoNKKSUl2uFnriavDdHzLFJpVLlEt4AHIYXwI0LRY2xgPgiD
         ckRsngm+Z4WpfdtwCXflNysYV74fabZ7Z1X6XFavDMYZ8QY9Fkb6g5uCj3VABuo54Nro
         ubSp2w8KfOo+McjeAYUlb2m/fKjt47HcpVIttd3ewF4KL0p5Gr5RLbhTNjWBCBi4GSn6
         nkpovR1yW7b5cZepF1xhe3vH8gMPQJHflYWSil6CPGvv77L9gByF9PqL6Iz2y5CqjzbH
         yYfA==
X-Gm-Message-State: AOJu0YzUlxhw/MX7mrKHuPaROxDWUlUikHTozaKtD+sD9Kk+z9JO1snG
	me5HNKcjETKhuTQmMylDXeiRc6U/JUX8QQGTohIAx5TWTSN+l2GN7nJSLEG4Tlp/tYkZUATGF16
	6p4UAV1s=
X-Gm-Gg: ASbGncs+tG8iDLSOvtf+Rc1tCkJhoqjhDPLANxuLVEmMlNZQak1YKbETG1s80ROwQLM
	zC6C3Sr/FjCrvPeUPN/I7nIe3pe0u0CQxsxczSp/vKdD+JPYXdRAUT3OPIgHqcNTu5KYoN1tVTA
	w27tIA6q9o3igKxVOHIaTSF9dt0wPbopWptLjwwD6JF0pBgn3OuS+VqSpg4X1patUzP5hpZQdTS
	dQrnGfcq26dLXc4Ml538Pqcdon11VDx1A+Ahwxk/2ZI4wt4dJvEHhKuvphVz+uM6q260l0lBZ7R
	TsRY8kvDIXpb4xI9EDzPyY7lVlbmVvT6trbv6KGoK82vzijTsQ/OTN0cCgWBoYFmTiccHiDsYD7
	oAdpgrw1TG4SD5LNfs3WG9XOjNnQjJA==
X-Google-Smtp-Source: AGHT+IHftnWwmJMkPMW09W9VY9+YM1UmRdHPziBBZ1IbJg4TPTO5PkismHUyTMIoUu4WaMQ8CMkznQ==
X-Received: by 2002:a05:600c:35c9:b0:450:d00d:cc with SMTP id 5b1f17b1804b1-453886d53d9mr41151945e9.2.1750943466805;
        Thu, 26 Jun 2025 06:11:06 -0700 (PDT)
From: Frediano Ziglio 
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio ,
	"Daniel P. Smith" ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Jan Beulich 
Subject: [PATCH v4 1/3] xen/efi: Handle cases where file didn't come from ESP
Date: Thu, 26 Jun 2025 14:10:53 +0100
Message-ID: <20250626131059.61894-2-frediano.ziglio@cloud.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250626131059.61894-1-frediano.ziglio@cloud.com>
References: <20250626131059.61894-1-frediano.ziglio@cloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

A boot loader can load files from outside ESP.
In these cases device could be not provided or path could
be something not supported.
In these cases allows to boot anyway, all information
could be provided using UKI or using other boot loader
features.

Signed-off-by: Frediano Ziglio 
Acked-by: Marek Marczykowski-Górecki 
---
Changes since v1:
- set "leaf" to NULL instead of a buffer with an empty string;
- keep read_file fatal if cannot load file (except configuration).

Changes since v2:
- Added acked-by.

Changes since v3:
- style fix.
---
 xen/common/efi/boot.c | 34 +++++++++++++++++++++++++++++-----
 1 file changed, 29 insertions(+), 5 deletions(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 1a9b4e7dae..9306dc8953 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -443,6 +443,18 @@ static EFI_FILE_HANDLE __init get_parent_handle(const EFI_LOADED_IMAGE *loaded_i
     CHAR16 *pathend, *ptr;
     EFI_STATUS ret;
 
+    /*
+     * In some cases the image could not come from a specific device.
+     * For instance this can happen if Xen was loaded using GRUB2 "linux"
+     * command.
+     */
+    *leaf = NULL;
+    if ( !loaded_image->DeviceHandle )
+    {
+        PrintStr(L"Xen image loaded without providing a device\r\n");
+        return NULL;
+    }
+
     do {
         EFI_FILE_IO_INTERFACE *fio;
 
@@ -466,7 +478,15 @@ static EFI_FILE_HANDLE __init get_parent_handle(const EFI_LOADED_IMAGE *loaded_i
 
         if ( DevicePathType(dp) != MEDIA_DEVICE_PATH ||
              DevicePathSubType(dp) != MEDIA_FILEPATH_DP )
-            blexit(L"Unsupported device path component");
+        {
+            /*
+             * The image could come from an unsupported device.
+             * For instance this can happen if Xen was loaded using GRUB2
+             * "chainloader" command and the file was not from ESP.
+             */
+            PrintStr(L"Unsupported device path component\r\n");
+            return NULL;
+        }
 
         if ( *buffer )
         {
@@ -772,8 +792,11 @@ static bool __init read_file(EFI_FILE_HANDLE dir_handle, CHAR16 *name,
 
     if ( !name )
         PrintErrMesg(L"No filename", EFI_OUT_OF_RESOURCES);
-    ret = dir_handle->Open(dir_handle, &FileHandle, name,
-                           EFI_FILE_MODE_READ, 0);
+    if ( dir_handle )
+        ret = dir_handle->Open(dir_handle, &FileHandle, name,
+                               EFI_FILE_MODE_READ, 0);
+    else
+        ret = EFI_NOT_FOUND;
     if ( file == &cfg && ret == EFI_NOT_FOUND )
         return false;
     if ( EFI_ERROR(ret) )
@@ -1404,7 +1427,7 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle,
         /* Read and parse the config file. */
         if ( read_section(loaded_image, L"config", &cfg, NULL) )
             PrintStr(L"Using builtin config file\r\n");
-        else if ( !cfg_file_name )
+        else if ( !cfg_file_name && file_name )
         {
             CHAR16 *tail;
 
@@ -1515,7 +1538,8 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle,
         efi_bs->FreePages(cfg.addr, PFN_UP(cfg.size));
         cfg.addr = 0;
 
-        dir_handle->Close(dir_handle);
+        if ( dir_handle )
+            dir_handle->Close(dir_handle);
 
         if ( gop && !base_video )
         {
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 26 13:11:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 13:11:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026356.1401572 (Exim 4.92)
	(envelope-from )
	id 1uUmNl-0006lO-5v; Thu, 26 Jun 2025 13:11:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026356.1401572; Thu, 26 Jun 2025 13:11:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUmNl-0006lE-2w; Thu, 26 Jun 2025 13:11:13 +0000
Received: by outflank-mailman (input) for mailman id 1026356;
 Thu, 26 Jun 2025 13:11: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 1uUmNj-0006jN-OE
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 13:11:11 +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 068c1767-528f-11f0-b894-0df219b8e170;
 Thu, 26 Jun 2025 15:11:09 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3a528243636so585550f8f.3
 for ; Thu, 26 Jun 2025 06:11:09 -0700 (PDT)
Received: from localhost.localdomain (253.226.6.51.dyn.plus.net.
 [51.6.226.253]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a6e806916esm7351356f8f.43.2025.06.26.06.11.07
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 26 Jun 2025 06:11:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 068c1767-528f-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750943468; x=1751548268; darn=lists.xenproject.org;
        h=content-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=Arkastc7FTqBBhA884vRzOj/VWCapeivXKRaS0y4Ts0=;
        b=SyUxy1zTp61tg8DI6EjwgOBrWM7qt5xSJcHgBzAC71FNW/UEyJRTBtImyhx+OGiqtR
         LosteY0D7H0iuV98incwrUi2Gtb6WEEcopdRcVYVkIBg+XF+ZF6vQXOmIQua5sIyzCld
         3QT9glxC0t5dE8JDxyJOeMKEsBNppXz+L23nU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750943468; x=1751548268;
        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=Arkastc7FTqBBhA884vRzOj/VWCapeivXKRaS0y4Ts0=;
        b=rmS1i4GBtqdsbSJkRHMbhro2rHlVt2aON+Dc6ZFsuIs7VHGE18VVMie+qs+JB1+q9b
         nL8KQcs0SIqC8A7seTB3v1hEsgj/YmY9g4OZTNGXIgMESinVjHl2TRFGZwjEi0uiq7hG
         NJJ3VQxfXx+RGHSO5vIfdzgGPdrirFSU5TBUt0csYbBLmGcD2ZAgXrqZQGJOJy9xDFPO
         agnrTdNrqnziXJgxuPVz9YPMUpPmvyE127d6oOU4O0X64Ec1X53unR/FKQCHkWr4VxNi
         +YMCu/foog0pmEj6PCYpXNuJrDQ0aD6uh0uz6DGaJ7dUFpoCNgfQlXBU92j1T1KR5ep0
         tJ1w==
X-Gm-Message-State: AOJu0YzzujFW/InqIKejjwocWVG0+8D4JNGsWjzX4C7HciF0wc/fyMVV
	/3D4CEoopM0zhe96wJcfPBKctQHkuOJPbnSDqzkfhlcDfwWlZkFlKYP+6G8y982v+hOxBICvf5W
	mn8+RXaw=
X-Gm-Gg: ASbGncu/+nvJfqYslR73W9ruw57Cl5FRcdx8w+54W3V6sD2t9iJAN9T1DVol9gy0sox
	vYwElYA/PXYrW6kh6ATf9qSkg1GbbyB4ZIGXtqR05Kod48FvUBfeYJVSCaT/NzcXtAegyluOyAt
	v76f90OKsY3LREUilkcgARMkZKIOpsNMve/Hk1cE3MR/5sScCV8VoZSDsbxl0YDwoDFKHLKpciP
	uoPlzKM1bPngEP0bJHCdzUamdGOa5MIirS+igOx4v7JVcZyrqjVSEorMswgXoda8tuvYi0QExne
	Yl2YV3xXwefIRJLZhS6R6ZbGuM5mwhkYhRai7aLlrK7UF+kCMXNVMDlhoMxKBu+jcF4l6NsWUXq
	4T3lZ/LsX6aGTfZMDnFEfBHKtGsICfukw+OeveL+p
X-Google-Smtp-Source: AGHT+IEMoyWamH+/GJbtG6xlOTCstBg1G51VJ6ogmc3sMopKuNX7Rw4BQ3S55LTrqTQnV2qkJs8Y5g==
X-Received: by 2002:a05:6000:2484:b0:3a6:d604:a017 with SMTP id ffacd0b85a97d-3a6ed63d398mr5842184f8f.24.1750943468404;
        Thu, 26 Jun 2025 06:11:08 -0700 (PDT)
From: Frediano Ziglio 
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio ,
	"Daniel P. Smith" ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Jan Beulich 
Subject: [PATCH v4 3/3] xen/efi: Update error flow for read_file function
Date: Thu, 26 Jun 2025 14:10:55 +0100
Message-ID: <20250626131059.61894-4-frediano.ziglio@cloud.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250626131059.61894-1-frediano.ziglio@cloud.com>
References: <20250626131059.61894-1-frediano.ziglio@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Use more explicit goto statements to handle common error code
path instead of a lot of if/else.

Signed-off-by: Frediano Ziglio 
---
 xen/common/efi/boot.c | 80 +++++++++++++++++++++++--------------------
 1 file changed, 43 insertions(+), 37 deletions(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 4cbf1aa894..f6e8d4726d 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -792,6 +792,8 @@ static bool __init read_file(EFI_FILE_HANDLE dir_handle, CHAR16 *name,
 
     if ( !name )
         PrintErrMesg(L"No filename", EFI_OUT_OF_RESOURCES);
+
+    what = L"Open";
     if ( dir_handle )
         ret = dir_handle->Open(dir_handle, &FileHandle, name,
                                EFI_FILE_MODE_READ, 0);
@@ -800,54 +802,58 @@ static bool __init read_file(EFI_FILE_HANDLE dir_handle, CHAR16 *name,
     if ( file == &cfg && ret == EFI_NOT_FOUND )
         return false;
     if ( EFI_ERROR(ret) )
-        what = L"Open";
-    else
-        ret = FileHandle->SetPosition(FileHandle, -1);
+        goto fail;
+
+    what = L"Seek";
+    ret = FileHandle->SetPosition(FileHandle, -1);
     if ( EFI_ERROR(ret) )
-        what = what ?: L"Seek";
-    else
-        ret = FileHandle->GetPosition(FileHandle, &size);
+        goto fail;
+
+    what = L"Get size";
+    ret = FileHandle->GetPosition(FileHandle, &size);
     if ( EFI_ERROR(ret) )
-        what = what ?: L"Get size";
-    else
-        ret = FileHandle->SetPosition(FileHandle, 0);
+        goto fail;
+
+    what = L"Seek";
+    ret = FileHandle->SetPosition(FileHandle, 0);
     if ( EFI_ERROR(ret) )
-        what = what ?: L"Seek";
-    else
-    {
-        file->addr = min(1UL << (32 + PAGE_SHIFT),
-                         HYPERVISOR_VIRT_END - DIRECTMAP_VIRT_START);
-        ret = efi_bs->AllocatePages(AllocateMaxAddress, EfiLoaderData,
-                                    PFN_UP(size), &file->addr);
-    }
+        goto fail;
+
+    what = L"Allocation";
+    file->addr = min(1UL << (32 + PAGE_SHIFT),
+                     HYPERVISOR_VIRT_END - DIRECTMAP_VIRT_START);
+    ret = efi_bs->AllocatePages(AllocateMaxAddress, EfiLoaderData,
+                                PFN_UP(size), &file->addr);
     if ( EFI_ERROR(ret) )
-        what = what ?: L"Allocation";
-    else
-    {
-        file->need_to_free = true;
-        file->size = size;
-        handle_file_info(name, file, options);
+        goto fail;
 
-        ret = FileHandle->Read(FileHandle, &file->size, file->str);
-        if ( !EFI_ERROR(ret) && file->size != size )
-            ret = EFI_ABORTED;
-        if ( EFI_ERROR(ret) )
-            what = L"Read";
-    }
+    file->need_to_free = true;
+    file->size = size;
+    handle_file_info(name, file, options);
 
-    if ( FileHandle )
-        FileHandle->Close(FileHandle);
+    what = L"Read";
+    ret = FileHandle->Read(FileHandle, &file->size, file->str);
+    if ( !EFI_ERROR(ret) && file->size != size )
+        ret = EFI_ABORTED;
+    if ( EFI_ERROR(ret) )
+        goto fail;
 
-    if ( what )
-    {
-        PrintErr(what);
-        PrintErr(L" failed for ");
-        PrintErrMesg(name, ret);
-    }
+    FileHandle->Close(FileHandle);
 
     efi_arch_flush_dcache_area(file->ptr, file->size);
 
     return true;
+
+fail:
+    if ( FileHandle )
+        FileHandle->Close(FileHandle);
+
+    PrintErr(what);
+    PrintErr(L" failed for ");
+    PrintErrMesg(name, ret);
+
+    /* not reached */
+    return false;
 }
 
 typedef struct __packed {
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 26 13:11:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 13:11:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026358.1401586 (Exim 4.92)
	(envelope-from )
	id 1uUmNm-00072D-Gh; Thu, 26 Jun 2025 13:11:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026358.1401586; Thu, 26 Jun 2025 13:11:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUmNm-000712-D6; Thu, 26 Jun 2025 13:11:14 +0000
Received: by outflank-mailman (input) for mailman id 1026358;
 Thu, 26 Jun 2025 13:11: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 1uUmNl-0006jN-Cz
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 13:11:13 +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 062d611b-528f-11f0-b894-0df219b8e170;
 Thu, 26 Jun 2025 15:11:08 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-451d3f72391so9669825e9.3
 for ; Thu, 26 Jun 2025 06:11:08 -0700 (PDT)
Received: from localhost.localdomain (253.226.6.51.dyn.plus.net.
 [51.6.226.253]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a6e806916esm7351356f8f.43.2025.06.26.06.11.06
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 26 Jun 2025 06:11:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 062d611b-528f-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750943468; x=1751548268; darn=lists.xenproject.org;
        h=content-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=W+mo0WOKd3A0EKEylip0Ln3TwOuR0JvCpuUcmvIccPQ=;
        b=Aum2uHGtUzzWZ7bUMAiSw5GqXv9cJK8OSTVtggrlBTWOe/WCiYGBebDINGcZdPITLk
         m0XK2xYoVTIanZO+GtMP/7eBq9FUSk5pESqzeNawDtqnMssVft+v2rDmnKmTrwqwMEJt
         Nvyv0SXnibkyPjsJ7IP68miJcTpFlDEEb4L24=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750943468; x=1751548268;
        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=W+mo0WOKd3A0EKEylip0Ln3TwOuR0JvCpuUcmvIccPQ=;
        b=mTv/bdbW+KkbDnG8b62vQqW1O8VCQzVlY2w8SFH/0iTuAQqm9PsJMduJE3McdMjeSQ
         iT4Y79EKWPdVcdmq8TVNLNwaT77elV9tqIZTCylFydnOzk+Ah1EseuXzk5EkFrx2pguD
         PjT6mVTU5tNvzFJzbIZubjn7O8+tcMcELlsVL5sdecgKvic7jVEX4jlh7zdIcInR6XrS
         jW/YsP0kyez8x5oJ+ZdzZpZEa7WIOG+JU9htIRGE/nKDZduIiXoxXX/xVtG16ZewOAKV
         qKcO4wRFDdQkv/B6HB6AIfIza8DGIprkyerOjtbNN5uLhkLAMNs19QTEZyq202DMPQGV
         6YFg==
X-Gm-Message-State: AOJu0Ywu7gOlrwfeiUNbURM7EfQd5CgwxeRAlJH22/eJkvfCTflZWSU0
	KrkETVjk4iE3JUd2qcm3VeZ02P854GQYOW6F1J6Jh7sSWtPFw9TWl7jO5QrX0XtZ/oUwngiqRL/
	fcOw0w7Y=
X-Gm-Gg: ASbGnctNwZrqlNbtfbFcI1BjHnJpCzQiqBPXb2WRkOeCYaICrmXl4r5TT82wTKsBXWS
	eJVROfGX/Ywf7xxi/eQSumPVAARs9IMi0KUv2xW8FSytuFlMKY8zFUT+TQ2hTf4JurWHAli6JMc
	JDPdddtQVv2hd2MujJuidqlHAxSXiAkE8g+j4CtnjeL7fGiuDanN3/gdrmCjj/bglzSjZbivI69
	Tvr262z3PQQUDHxyRv3/j4Motl7GphSHoSjReFh7UMrWgEg39ZLJ7vIFu88FKssxl8ZjOK/Hvy6
	VjkXHckvIzej5Ia1rtgzxmECxhEEE2mAUFRxinFbB56/amztmjUMrUnLtq1j1ZXOpzcCYNvxNaR
	bAfM83FLxXLjakfAN37Ckjj5NpUs4gg==
X-Google-Smtp-Source: AGHT+IF2sIhI5qYgc8DsZ9N26609R1JHS5126HSQCIqc8YcGxsb7eDmgHQyWFIKF+4U/LrHrli+IUQ==
X-Received: by 2002:a05:600c:b95:b0:43c:f8fe:dd82 with SMTP id 5b1f17b1804b1-45381ae2520mr74274265e9.18.1750943467661;
        Thu, 26 Jun 2025 06:11:07 -0700 (PDT)
From: Frediano Ziglio 
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio ,
	"Daniel P. Smith" ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Jan Beulich 
Subject: [PATCH v4 2/3] xen/efi: Support loading initrd using GRUB2 LoadFile2 protocol
Date: Thu, 26 Jun 2025 14:10:54 +0100
Message-ID: <20250626131059.61894-3-frediano.ziglio@cloud.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250626131059.61894-1-frediano.ziglio@cloud.com>
References: <20250626131059.61894-1-frediano.ziglio@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Allows to load Xen using "linux" and "initrd" GRUB2 commands.
This can be used with UKI to separate initrd in a different module
instead of bundling all together.
Bundling all together can be a problem with Secure Boot where
we need to sign the bundle making harder to change it.
As initrd content does not need to be signed for Secure Boot
bundling it force it to be signed too.

Signed-off-by: Frediano Ziglio 
---
Changes since v1:
- attempt to use LoadFile2 protocol after embedded section.

Changes since v3 (mainly internal review):
- use __packed instead of #pragma pack(), more consistent;
- call handle_file_info instead of efi_arch_handle_module, more
  consistent;
- call efi_arch_flush_dcache_area like other functions;
- move protocol definitions to efiprot.h file.
---
 xen/common/efi/boot.c     | 71 ++++++++++++++++++++++++++++++++++++++-
 xen/include/efi/efidevp.h |  2 ++
 xen/include/efi/efiprot.h | 19 +++++++++++
 3 files changed, 91 insertions(+), 1 deletion(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 9306dc8953..4cbf1aa894 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -850,6 +850,74 @@ static bool __init read_file(EFI_FILE_HANDLE dir_handle, CHAR16 *name,
     return true;
 }
 
+typedef struct __packed {
+    VENDOR_DEVICE_PATH              VenMediaNode;
+    EFI_DEVICE_PATH                 EndNode;
+} SINGLE_NODE_VENDOR_MEDIA_DEVPATH;
+
+static bool __init initrd_load_file2(const CHAR16 *name, struct file *file)
+{
+    static const SINGLE_NODE_VENDOR_MEDIA_DEVPATH __initconst initrd_dev_path = {
+        {
+            {
+                MEDIA_DEVICE_PATH, MEDIA_VENDOR_DP, { sizeof (VENDOR_DEVICE_PATH) }
+            },
+            LINUX_EFI_INITRD_MEDIA_GUID
+        },
+        {
+            END_DEVICE_PATH_TYPE, END_ENTIRE_DEVICE_PATH_SUBTYPE,
+            { sizeof (EFI_DEVICE_PATH) }
+        }
+    };
+    static EFI_GUID __initdata lf2_proto_guid = EFI_LOAD_FILE2_PROTOCOL_GUID;
+    EFI_DEVICE_PATH *dp;
+    EFI_LOAD_FILE2_PROTOCOL *lf2;
+    EFI_HANDLE handle;
+    EFI_STATUS ret;
+    UINTN size;
+
+    dp = (EFI_DEVICE_PATH *)&initrd_dev_path;
+    ret = efi_bs->LocateDevicePath(&lf2_proto_guid, &dp, &handle);
+    if ( EFI_ERROR(ret) )
+    {
+        if ( ret == EFI_NOT_FOUND)
+            return false;
+        PrintErrMesg(L"Error getting file with LoadFile2 interface", ret);
+    }
+
+    ret = efi_bs->HandleProtocol(handle, &lf2_proto_guid, (void **)&lf2);
+    if ( EFI_ERROR(ret) )
+        PrintErrMesg(L"LoadFile2 file does not provide correct protocol", ret);
+
+    size = 0;
+    ret = lf2->LoadFile(lf2, dp, false, &size, NULL);
+    if ( ret != EFI_BUFFER_TOO_SMALL )
+        PrintErrMesg(L"Loading failed", ret);
+
+    file->addr = min(1UL << (32 + PAGE_SHIFT),
+                     HYPERVISOR_VIRT_END - DIRECTMAP_VIRT_START);
+    ret = efi_bs->AllocatePages(AllocateMaxAddress, EfiLoaderData,
+                                PFN_UP(size), &file->addr);
+    if ( EFI_ERROR(ret) )
+        PrintErrMesg(L"Allocation failed", ret);
+
+    file->need_to_free = true;
+    file->size = size;
+
+    ret = lf2->LoadFile(lf2, dp, false, &size, file->str);
+    if ( EFI_ERROR(ret) )
+    {
+        efi_bs->FreePages(file->addr, PFN_UP(size));
+        PrintErrMesg(L"Loading failed", ret);
+    }
+
+    handle_file_info(name, file, NULL);
+
+    efi_arch_flush_dcache_area(file->ptr, file->size);
+
+    return true;
+}
+
 static bool __init read_section(const EFI_LOADED_IMAGE *image,
                                 const CHAR16 *name, struct file *file,
                                 const char *options)
@@ -1493,7 +1561,8 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle,
             kernel_verified = true;
         }
 
-        if ( !read_section(loaded_image, L"ramdisk", &ramdisk, NULL) )
+        if ( !read_section(loaded_image, L"ramdisk", &ramdisk, NULL) &&
+             !initrd_load_file2(L"ramdisk", &ramdisk) )
         {
             name.s = get_value(&cfg, section.s, "ramdisk");
             if ( name.s )
diff --git a/xen/include/efi/efidevp.h b/xen/include/efi/efidevp.h
index beb5785a45..dc070007b8 100644
--- a/xen/include/efi/efidevp.h
+++ b/xen/include/efi/efidevp.h
@@ -398,5 +398,7 @@ typedef union {
 
 } EFI_DEV_PATH_PTR;
 
+#define LINUX_EFI_INITRD_MEDIA_GUID \
+    { 0x5568e427, 0x68fc, 0x4f3d, {0xac, 0x74, 0xca, 0x55, 0x52, 0x31, 0xcc, 0x68} }
 
 #endif
diff --git a/xen/include/efi/efiprot.h b/xen/include/efi/efiprot.h
index 56d7636b2b..94c1faae0a 100644
--- a/xen/include/efi/efiprot.h
+++ b/xen/include/efi/efiprot.h
@@ -771,5 +771,24 @@ typedef struct _EFI_EDID_OVERRIDE_PROTOCOL {
     EFI_EDID_OVERRIDE_PROTOCOL_GET_EDID  GetEdid;
 } EFI_EDID_OVERRIDE_PROTOCOL;
 
+#define EFI_LOAD_FILE2_PROTOCOL_GUID \
+    { 0x4006c0c1, 0xfcb3, 0x403e, {0x99, 0x6d, 0x4a, 0x6c, 0x87, 0x24, 0xe0, 0x6d } }
+
+typedef struct EFI_LOAD_FILE2_PROTOCOL EFI_LOAD_FILE2_PROTOCOL;
+
+typedef
+EFI_STATUS
+(EFIAPI *EFI_LOAD_FILE2)(
+    IN EFI_LOAD_FILE2_PROTOCOL      *This,
+    IN EFI_DEVICE_PATH              *FilePath,
+    IN BOOLEAN                      BootPolicy,
+    IN OUT UINTN                    *BufferSize,
+    IN VOID                         *Buffer OPTIONAL
+    );
+
+struct EFI_LOAD_FILE2_PROTOCOL {
+    EFI_LOAD_FILE2                  LoadFile;
+};
+
 #endif
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 26 13:29:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 13:29:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026407.1401599 (Exim 4.92)
	(envelope-from )
	id 1uUmfI-0001w0-V0; Thu, 26 Jun 2025 13:29:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026407.1401599; Thu, 26 Jun 2025 13:29: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 1uUmfI-0001vR-SP; Thu, 26 Jun 2025 13:29:20 +0000
Received: by outflank-mailman (input) for mailman id 1026407;
 Thu, 26 Jun 2025 13:29: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 1uUmfI-0001vL-6C
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 13:29:20 +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 8f796df8-5291-11f0-b894-0df219b8e170;
 Thu, 26 Jun 2025 15:29:18 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a6e8b1fa37so986518f8f.2
 for ; Thu, 26 Jun 2025 06:29:18 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b34c4320a15sm1738284a12.32.2025.06.26.06.29.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 26 Jun 2025 06:29:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8f796df8-5291-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750944557; x=1751549357; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=n0YSGjtTnyxc0oIsd6TCtR4VeLrCFWR5/fPHWZKd58o=;
        b=UdwiVvEbD3bh2GITiWvrXbQYoR7tAfiJSbbFc5aozkuYPnNTIiBp6cVGwvRpBzaZyh
         FBgZrolAMq0WWDibBLmYlfLP6COeotfaRXCVUSgd8VmmhtQXIUAFmy0s9nvBWVSM68mU
         0C5CIfMkfgrJ+ycova60UErnYiuq0t01n0Z4Lcd8bOCy+45dHjelemwj9JYuxrRg7d1R
         xVpc9TMS6UE0LYBfseB3lhYCxHI4uT7ze+CkslaoV5EpFWE3uyrms6ZMVPBu5kTfg+CV
         tfhXc7bl300+FMq4W9+bvq5n24dfoTsPfP5iCrxk0Dfg+Jp1qiPYkDowrqe+uhr5aA2n
         b93g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750944557; x=1751549357;
        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=n0YSGjtTnyxc0oIsd6TCtR4VeLrCFWR5/fPHWZKd58o=;
        b=hQ5XEmhjXcSF/MVWQiPUhNlTPeb60HnYRdTikdnQ8vkiUQRZKMiIaDb5+vKyUPHIs9
         ghJ0iMN1egGjzItgvSfVKxszm4TD9LkQDCPU+qsYZK34ekxMsQqt3AgaeURy3OOkT+PM
         MtRtDRD+aNZeK5uAQdZa45rukUFLYw1IUzQue9W6f1/oQ2SDObpUJhHbb7ceBbi4mq6o
         Ue3SfQqYQ3YNvAPIDIteJDtIZCf2WX1I2mbMnRqrvVuuEZE/Fdc6zxDkE9AjyfGfqroT
         mkpSEApUg03L7nFx5zirvJlPsnDcO0ZIgElj6kKThr9WcjQdk9JykJwFLtS//TK8zjG6
         1laQ==
X-Forwarded-Encrypted: i=1; AJvYcCXTk/cC8SSnTH8AoDLeXCoZ/Wh5kn9abnHvBazk/k9pbCBlpYvIhMEDFOgS8IO7f/14Mst/0DOr9+s=@lists.xenproject.org
X-Gm-Message-State: AOJu0YynGjUBZeMTzSGr1BJc9XwCgNlswarGrQS3nblzG1lnvLw2JIA+
	fxiabBjZBTphor7cwyCBFdVEv/1cpfHNROykOXyz36QYcWeTem+vG0n3PTYJkVY8kWIubHQV5cE
	qgUc=
X-Gm-Gg: ASbGnctNqNOz6oTnX/f7R2Bd2t01sG4KQqpf0ZAAOiBUsDq8SwMXbZT8rzPMCBTFSBU
	e4K56PP8D0ewt2dW7rpuPoqcaQOtDvi595NSFuEworemAkgROs8nnPDXQ7lr8gZpFoapURYSnqT
	TrfwLsilXud1t/zD6gzXdjRKR8rjYyJT8HPr+h06Ae8P5RpacAnEeCW+djp6s1XEzUNuup8tUnv
	0GSLummIudj+ZzHUFuoyU7iHah9z5f7i5qBYaS7MUUGPP1nmm9IOBeP3VgJb+09+ABvUj/IXg4q
	/N00h7MXNGJbMY9C7SLbZMUrZSeGctAhcidBr8Gkymf090es/5YpNGgWJwcezSo09M8ZBC0qY2d
	icUW1Oz5PP24DmMBKWX64HtCNC1mhFGG+WrHdEPVf1gJc5M+Hlfb1TGrTqw==
X-Google-Smtp-Source: AGHT+IEjnshZCBjUzlUKNsgqGIxMbZnCFBDBRHjT8ENSCXmS0sLEuKLALIYs+Xh65nyVKb4vP6bQMg==
X-Received: by 2002:a5d:5f91:0:b0:3a5:2465:c0a4 with SMTP id ffacd0b85a97d-3a6ed5db111mr5967480f8f.20.1750944557327;
        Thu, 26 Jun 2025 06:29:17 -0700 (PDT)
Message-ID: 
Date: Thu, 26 Jun 2025 15:29:09 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/3] xen/efi: Support loading initrd using GRUB2
 LoadFile2 protocol
To: Frediano Ziglio 
Cc: "Daniel P. Smith" ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , xen-devel@lists.xenproject.org
References: <20250625073408.7496-1-frediano.ziglio@cloud.com>
 <20250625073408.7496-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: <20250625073408.7496-3-frediano.ziglio@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 25.06.2025 09:34, Frediano Ziglio wrote:
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -850,6 +850,74 @@ static bool __init read_file(EFI_FILE_HANDLE dir_handle, CHAR16 *name,
>      return true;
>  }
>  
> +#pragma pack(1)
> +typedef struct {
> +    VENDOR_DEVICE_PATH              VenMediaNode;
> +    EFI_DEVICE_PATH                 EndNode;
> +} SINGLE_NODE_VENDOR_MEDIA_DEVPATH;
> +#pragma pack()

Where is this coming from? And why is this declared locally here, but the ...

> +static bool __init initrd_load_file2(const CHAR16 *name, struct file *file)
> +{
> +    static const SINGLE_NODE_VENDOR_MEDIA_DEVPATH __initconst initrd_dev_path = {
> +        {
> +            {
> +                MEDIA_DEVICE_PATH, MEDIA_VENDOR_DP, { sizeof (VENDOR_DEVICE_PATH) }
> +            },
> +            LINUX_EFI_INITRD_MEDIA_GUID
> +        },
> +        {
> +            END_DEVICE_PATH_TYPE, END_ENTIRE_DEVICE_PATH_SUBTYPE,
> +            { sizeof (EFI_DEVICE_PATH) }
> +        }
> +    };
> +    static EFI_GUID __initdata lf2_proto_guid = EFI_LOAD_FILE2_PROTOCOL_GUID;

... corresponding GUID is put in a (random?) header file?

> +    EFI_DEVICE_PATH *dp;
> +    EFI_LOAD_FILE2_PROTOCOL *lf2;
> +    EFI_HANDLE handle;
> +    EFI_STATUS ret;
> +    UINTN size;
> +
> +    dp = (EFI_DEVICE_PATH *)&initrd_dev_path;

Instead of a (fragile) cast, why not

    dp = &initrd_dev_path->VenMediaNode.Header;

? And then perhaps also as initializer of the variable?

> +    ret = efi_bs->LocateDevicePath(&lf2_proto_guid, &dp, &handle);
> +    if ( EFI_ERROR(ret) )
> +    {
> +        if ( ret == EFI_NOT_FOUND)
> +            return false;
> +        PrintErrMesg(L"Error getting file with LoadFile2 interface", ret);
> +    }
> +
> +    ret = efi_bs->HandleProtocol(handle, &lf2_proto_guid, (void **)&lf2);
> +    if ( EFI_ERROR(ret) )
> +        PrintErrMesg(L"LoadFile2 file does not provide correct protocol", ret);
> +
> +    size = 0;
> +    ret = lf2->LoadFile(lf2, dp, false, &size, NULL);
> +    if ( ret != EFI_BUFFER_TOO_SMALL )
> +        PrintErrMesg(L"Loading failed", ret);

Here it's particularly bad, but throughout: How would one know in what
context the failure was? Wouldn't you want to include "name" in the
output? read_file() does include this detail.

> +    file->addr = min(1UL << (32 + PAGE_SHIFT),
> +                     HYPERVISOR_VIRT_END - DIRECTMAP_VIRT_START);

I understand you took this from read_file(), but the construct looks
outdated. For one, it should have been abstracted away when the Arm64
work was done (I don't think such a restriction exists there), and
then I'm also not sure the restriction would unconditionally apply on
x86 anymore.

> +    ret = efi_bs->AllocatePages(AllocateMaxAddress, EfiLoaderData,
> +                                PFN_UP(size), &file->addr);
> +    if ( EFI_ERROR(ret) )
> +        PrintErrMesg(L"Allocation failed", ret);
> +
> +    file->need_to_free = true;
> +    file->size = size;
> +
> +    ret = lf2->LoadFile(lf2, dp, false, &size, file->str);
> +    if ( EFI_ERROR(ret) )
> +    {
> +        efi_bs->FreePages(file->addr, PFN_UP(size));
> +        PrintErrMesg(L"Loading failed", ret);
> +    }
> +
> +    efi_arch_handle_module(file, name, NULL);

Shouldn't it be handle_file_info() that you call, and a little earlier?

> --- a/xen/include/efi/efidevp.h
> +++ b/xen/include/efi/efidevp.h
> @@ -398,5 +398,26 @@ typedef union {
>  
>  } EFI_DEV_PATH_PTR;
>  
> +#define EFI_LOAD_FILE2_PROTOCOL_GUID \
> +    { 0x4006c0c1, 0xfcb3, 0x403e, {0x99, 0x6d, 0x4a, 0x6c, 0x87, 0x24, 0xe0, 0x6d } }
> +
> +typedef struct EFI_LOAD_FILE2_PROTOCOL EFI_LOAD_FILE2_PROTOCOL;
> +
> +typedef
> +EFI_STATUS
> +(EFIAPI *EFI_LOAD_FILE2)(
> +    IN EFI_LOAD_FILE2_PROTOCOL      *This,
> +    IN EFI_DEVICE_PATH              *FilePath,
> +    IN BOOLEAN                      BootPolicy,
> +    IN OUT UINTN                    *BufferSize,
> +    IN VOID                         *Buffer OPTIONAL
> +    );
> +
> +struct EFI_LOAD_FILE2_PROTOCOL {
> +    EFI_LOAD_FILE2                  LoadFile;
> +};
> +
> +#define LINUX_EFI_INITRD_MEDIA_GUID \
> +    { 0x5568e427, 0x68fc, 0x4f3d, {0xac, 0x74, 0xca, 0x55, 0x52, 0x31, 0xcc, 0x68} }
>  
>  #endif

While I'm not maintainer of this code anymore, I hope the new maintainers will
still respect the original idea of keeping these headers in sync with their
origin. The way it's arranged, this change doesn't look like it would have been
taken from the gnu-efi package (albeit I will admit I didn't go check).

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 13:32:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 13:32:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026415.1401609 (Exim 4.92)
	(envelope-from )
	id 1uUmhr-0003X5-D6; Thu, 26 Jun 2025 13:31:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026415.1401609; Thu, 26 Jun 2025 13:31:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUmhr-0003Wy-9o; Thu, 26 Jun 2025 13:31:59 +0000
Received: by outflank-mailman (input) for mailman id 1026415;
 Thu, 26 Jun 2025 13: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 1uUmhp-0003Ws-Sw
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 13:31:57 +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 ed90a8c4-5291-11f0-b894-0df219b8e170;
 Thu, 26 Jun 2025 15:31:56 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3a548a73ff2so953866f8f.0
 for ; Thu, 26 Jun 2025 06:31:56 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d872ffd5sm166317075ad.240.2025.06.26.06.31.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 26 Jun 2025 06:31:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ed90a8c4-5291-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750944715; x=1751549515; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=g4LQsjev7sNqxQo+ymGPdBu+bLwbE2u9tg5PJftsgZo=;
        b=VW8XolgTe/xCplFaEqlabnZ2r6/S29pZ3MRZhorwVhladkr1XVLRvKy98pSH8g8WTW
         96L7lR6ckfeWqDA7bugguHEKimluh3o291MOUyED17A3aOBtLW2s9jtYcArYxMc34Y/+
         SXZWK+s5oZnW91Stt1NL97LIwnf+oOu8fmN7qBfcD/UrERJANI12YMf6WbzUM1CdxpkE
         nRXDcf8CHMNlQNrejoClHDThOAauiYfLEMHzs5nVhDl4aobaTVccHPvhF4wOvpFz1yU7
         634eiDe1TtpJA8T0EApKkCmN/qSo82dCNW1QWqy0F2zGMnIz33wpsw2RjpNk47wnjsBh
         lk2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750944715; x=1751549515;
        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=g4LQsjev7sNqxQo+ymGPdBu+bLwbE2u9tg5PJftsgZo=;
        b=OtHGDEtdEdoYZofPgQDi4gv2iFfIrCdO+cVKbsw8feTXfZmVzsv1/8SKtwZ2YP29dz
         qg3uL2PIS0UzkZ4NVeko0qROg5VO98GA6aGDmW17Jr9I05KYV5DosUqljtcfXgApQJ7L
         GRocuX7GBLbQ54h6JVtNSyP1HxvrfvjMMqlEpJn5tjMlS3APGAodGph00CRoLtlPgwqY
         aILKav2xCb6teYptoyHaIh/pOM/GeR/xgMy/pLth7sjDyyjq56AciRsspNDk17Frjfjy
         TFEakQGpHNXyu6MiTCABJc31GlBhZNqvB8sROOEygFXNuUW9PXr9Bs7OTyLNtYo1ZEPB
         Uu5Q==
X-Forwarded-Encrypted: i=1; AJvYcCW8w1u09Rf4p1a/Pf7UP4Hs9qx3X9zksB1ZFM/U30SdBdczpX4k8oJqH8Eh4Uytyvqo7FAlDPJu+gk=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz2LhbPmNUtbk/NZL3yOwzN8f6A5k68VYkMNxD4lmn6qnD29MgP
	KPVCLAFT9Todo1mEkutECRSQT4m/RwrfQy8wIt4Pask+i0xaZBrdjthBetbCF70YIqMfO+drqlL
	YN8Q=
X-Gm-Gg: ASbGnctLMT9xn47JW5MZbuCral9eF5HsUqymiScpBeW26NVhVd35h3x8x6lwp/pKWem
	mcLH2BXQXQtFdwxMJSEdlBFB+rYWT0n3O8TX1p+7ky8Hpe7z5dX54hVT0B4l7F6PtS17HpLzhD4
	l3RAUjNn+qDHHPuJ1TpN5ckQYsoCzMDg4WAxnuRAHy1lDlF0QJOOQKZqJ8lppC+2zxhoFlJBxTN
	9iri5kACjzVlgOUy5UoOH9amjtugYAFNkF7bVMKQOdkKMdNotU0WQyDyNjocBZRvKHePDWeUrm4
	+UCBorocx6UDMeVaJFzkKdfMN8tz8O/JEODl3ikb7LEKq9CugZjsfUuHimJyD53gPAkflekRddP
	jYD3qRj5TSq/e6lakL8uU+OfxeAVM1UtV+opsBxUjh/uxvq0=
X-Google-Smtp-Source: AGHT+IEMJdO+y8FTF/ninkWfW6Ch0l6BgVjKyaXzSDvx+Y5h7cJ39YRaEYcYeJ62AI/0awScpkL7Ig==
X-Received: by 2002:a05:6000:2b11:b0:3a4:fb33:85ce with SMTP id ffacd0b85a97d-3a6ed646bebmr4033870f8f.46.1750944715073;
        Thu, 26 Jun 2025 06:31:55 -0700 (PDT)
Message-ID: <9d64c239-d6cc-4eb5-b180-a5034bedcfdb@suse.com>
Date: Thu, 26 Jun 2025 15:31:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 3/3] xen/efi: Update error flow for read_file function
To: Frediano Ziglio 
Cc: "Daniel P. Smith" ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , xen-devel@lists.xenproject.org
References: <20250626131059.61894-1-frediano.ziglio@cloud.com>
 <20250626131059.61894-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: <20250626131059.61894-4-frediano.ziglio@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 26.06.2025 15:10, Frediano Ziglio wrote:
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -792,6 +792,8 @@ static bool __init read_file(EFI_FILE_HANDLE dir_handle, CHAR16 *name,
>  
>      if ( !name )
>          PrintErrMesg(L"No filename", EFI_OUT_OF_RESOURCES);
> +
> +    what = L"Open";
>      if ( dir_handle )
>          ret = dir_handle->Open(dir_handle, &FileHandle, name,
>                                 EFI_FILE_MODE_READ, 0);
> @@ -800,54 +802,58 @@ static bool __init read_file(EFI_FILE_HANDLE dir_handle, CHAR16 *name,
>      if ( file == &cfg && ret == EFI_NOT_FOUND )
>          return false;
>      if ( EFI_ERROR(ret) )
> -        what = L"Open";
> -    else
> -        ret = FileHandle->SetPosition(FileHandle, -1);
> +        goto fail;
> +
> +    what = L"Seek";
> +    ret = FileHandle->SetPosition(FileHandle, -1);
>      if ( EFI_ERROR(ret) )
> -        what = what ?: L"Seek";
> -    else
> -        ret = FileHandle->GetPosition(FileHandle, &size);
> +        goto fail;
> +
> +    what = L"Get size";
> +    ret = FileHandle->GetPosition(FileHandle, &size);
>      if ( EFI_ERROR(ret) )
> -        what = what ?: L"Get size";
> -    else
> -        ret = FileHandle->SetPosition(FileHandle, 0);
> +        goto fail;
> +
> +    what = L"Seek";
> +    ret = FileHandle->SetPosition(FileHandle, 0);
>      if ( EFI_ERROR(ret) )
> -        what = what ?: L"Seek";
> -    else
> -    {
> -        file->addr = min(1UL << (32 + PAGE_SHIFT),
> -                         HYPERVISOR_VIRT_END - DIRECTMAP_VIRT_START);
> -        ret = efi_bs->AllocatePages(AllocateMaxAddress, EfiLoaderData,
> -                                    PFN_UP(size), &file->addr);
> -    }
> +        goto fail;
> +
> +    what = L"Allocation";
> +    file->addr = min(1UL << (32 + PAGE_SHIFT),
> +                     HYPERVISOR_VIRT_END - DIRECTMAP_VIRT_START);
> +    ret = efi_bs->AllocatePages(AllocateMaxAddress, EfiLoaderData,
> +                                PFN_UP(size), &file->addr);
>      if ( EFI_ERROR(ret) )
> -        what = what ?: L"Allocation";
> -    else
> -    {
> -        file->need_to_free = true;
> -        file->size = size;
> -        handle_file_info(name, file, options);
> +        goto fail;
>  
> -        ret = FileHandle->Read(FileHandle, &file->size, file->str);
> -        if ( !EFI_ERROR(ret) && file->size != size )
> -            ret = EFI_ABORTED;
> -        if ( EFI_ERROR(ret) )
> -            what = L"Read";
> -    }
> +    file->need_to_free = true;
> +    file->size = size;
> +    handle_file_info(name, file, options);
>  
> -    if ( FileHandle )
> -        FileHandle->Close(FileHandle);
> +    what = L"Read";
> +    ret = FileHandle->Read(FileHandle, &file->size, file->str);
> +    if ( !EFI_ERROR(ret) && file->size != size )
> +        ret = EFI_ABORTED;
> +    if ( EFI_ERROR(ret) )
> +        goto fail;
>  
> -    if ( what )
> -    {
> -        PrintErr(what);
> -        PrintErr(L" failed for ");
> -        PrintErrMesg(name, ret);
> -    }
> +    FileHandle->Close(FileHandle);
>  
>      efi_arch_flush_dcache_area(file->ptr, file->size);
>  
>      return true;
> +
> +fail:

Nit: Style (see ./CODING_STYLE).

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 13:42:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 13:42:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026426.1401619 (Exim 4.92)
	(envelope-from )
	id 1uUmrj-0005j2-Br; Thu, 26 Jun 2025 13:42:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026426.1401619; Thu, 26 Jun 2025 13:42:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUmrj-0005iv-8v; Thu, 26 Jun 2025 13:42:11 +0000
Received: by outflank-mailman (input) for mailman id 1026426;
 Thu, 26 Jun 2025 13:42: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 1uUmrh-0005ip-Fu
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 13:42:09 +0000
Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com
 [2607:f8b0:4864:20::333])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5a3da758-5293-11f0-a30f-13f23c93f187;
 Thu, 26 Jun 2025 15:42:08 +0200 (CEST)
Received: by mail-ot1-x333.google.com with SMTP id
 46e09a7af769-73ac40e810eso261894a34.1
 for ; Thu, 26 Jun 2025 06:42:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5a3da758-5293-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750945327; x=1751550127; 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=fOaLR4NsW3bYPPDN8PATHK9da4Z1YXA1iEKUCq2Qs5g=;
        b=MfJGqkZstyNr+uFw+a/4p61bMwTcd+l18dPp6cLeCTNP2zNsKpGLJuCCtUa0zMfeLX
         Z1IPaCWbz6vpZYomIKc3ZAypgPyxGWfLM1G3cHke8+4hX41wZFOnxRvjFCKCGzyPY0HZ
         czTy+5rLBtdJBLgFpUrtnY03p7w63hiHG/YVo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750945327; x=1751550127;
        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=fOaLR4NsW3bYPPDN8PATHK9da4Z1YXA1iEKUCq2Qs5g=;
        b=qHodf4mM55cYbP0+PrTxW1RmrPW02Tz3qqTPCAT34cWcw0jO+0lxy4whVWJsNd+zw6
         TLtbkmRugjQ2/sQNCrqJi0/MZjjyFvW7NIkEIa4lCz56LNS9NtE9YCqyZu221HGqUfG6
         /mZaCaKh4q6DsC/nNJtdHXEIH9lNVsU+D/asy5VgoJFQ8dSwG3LxYQoo5qXSKozWKNnL
         FBt2j+hQYoSg9Aupps6OjaeRAQi1IMx0haz9FEM+er8d1M8fPYH1uipbPH6vyzPSVKTG
         Rr2yOMeeIf29uvUDU2V61h62b9jY9XC9+FCKFJWA4D9vJ/2jbPk3bJ1xDuMDorKka6//
         EHTQ==
X-Forwarded-Encrypted: i=1; AJvYcCW6DSyUmmuzTc5aJXdgDPyqFwxQyhQ4t3OE90LISODZefauWgmbcVAlJtGOFypHSlx0VEXse+JAOnE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw4LgO3yEj2R8GCpv+Re+3x/trRkzWT/tCXkxIDouK2f/JHpXG7
	UIV3MJw4PT7KaDE15+EgD1GVZxjtizTgVYHp2gVTrcSRIGU23L8y5h9U3I9sasf9D9lGqs8pjKB
	OIoZI7lHGp12/K+5PKMivQc9YfDaf6s6u2Jp76iH2i6VPdZ2o0/PvNRyVeA==
X-Gm-Gg: ASbGncu+KchVJJdUrt4AGjNd/bv2I+DzoKedw6bFwT4ncyXZo9hOldpbG7/m6AGQTR8
	J5923uwt2eashSOak/23WH/IkzHOC8u3NM9zopb7gQ2Uhj2ITfGoTT6U9dmv4RVys4man8NqjTW
	IJxGtKNdf5QlGNNGtXQi+WVztgXDqzfmvIdwjgrl1e
X-Google-Smtp-Source: AGHT+IGyvxOlGCvdz3b5LNvOwpMzxibIPaEygU2dLNGbRfGDBUExPKtE4L0HhdKBF+zED91/lHA/c5rvipQeUXOpuHc=
X-Received: by 2002:a05:6870:80c6:b0:2db:a997:7a62 with SMTP id
 586e51a60fabf-2efb21f4a35mr4784013fac.17.1750945326974; Thu, 26 Jun 2025
 06:42:06 -0700 (PDT)
MIME-Version: 1.0
References: <20250626131059.61894-1-frediano.ziglio@cloud.com>
 <20250626131059.61894-4-frediano.ziglio@cloud.com> <9d64c239-d6cc-4eb5-b180-a5034bedcfdb@suse.com>
In-Reply-To: <9d64c239-d6cc-4eb5-b180-a5034bedcfdb@suse.com>
From: Frediano Ziglio 
Date: Thu, 26 Jun 2025 14:41:55 +0100
X-Gm-Features: Ac12FXwBnaNQueTZgk2R1KISJ2R07wjY9BI-dVM7X_R_2r8fOnii4WIIPH-i_6o
Message-ID: 
Subject: Re: [PATCH v4 3/3] xen/efi: Update error flow for read_file function
To: Jan Beulich 
Cc: "Daniel P. Smith" , 
	=?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= , 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 26, 2025 at 2:31=E2=80=AFPM Jan Beulich  wro=
te:
>
> On 26.06.2025 15:10, Frediano Ziglio wrote:
> > --- a/xen/common/efi/boot.c
> > +++ b/xen/common/efi/boot.c
> > @@ -792,6 +792,8 @@ static bool __init read_file(EFI_FILE_HANDLE dir_ha=
ndle, CHAR16 *name,
> >
> >      if ( !name )
> >          PrintErrMesg(L"No filename", EFI_OUT_OF_RESOURCES);
> > +
> > +    what =3D L"Open";
> >      if ( dir_handle )
> >          ret =3D dir_handle->Open(dir_handle, &FileHandle, name,
> >                                 EFI_FILE_MODE_READ, 0);
> > @@ -800,54 +802,58 @@ static bool __init read_file(EFI_FILE_HANDLE dir_=
handle, CHAR16 *name,
> >      if ( file =3D=3D &cfg && ret =3D=3D EFI_NOT_FOUND )
> >          return false;
> >      if ( EFI_ERROR(ret) )
> > -        what =3D L"Open";
> > -    else
> > -        ret =3D FileHandle->SetPosition(FileHandle, -1);
> > +        goto fail;
> > +
> > +    what =3D L"Seek";
> > +    ret =3D FileHandle->SetPosition(FileHandle, -1);
> >      if ( EFI_ERROR(ret) )
> > -        what =3D what ?: L"Seek";
> > -    else
> > -        ret =3D FileHandle->GetPosition(FileHandle, &size);
> > +        goto fail;
> > +
> > +    what =3D L"Get size";
> > +    ret =3D FileHandle->GetPosition(FileHandle, &size);
> >      if ( EFI_ERROR(ret) )
> > -        what =3D what ?: L"Get size";
> > -    else
> > -        ret =3D FileHandle->SetPosition(FileHandle, 0);
> > +        goto fail;
> > +
> > +    what =3D L"Seek";
> > +    ret =3D FileHandle->SetPosition(FileHandle, 0);
> >      if ( EFI_ERROR(ret) )
> > -        what =3D what ?: L"Seek";
> > -    else
> > -    {
> > -        file->addr =3D min(1UL << (32 + PAGE_SHIFT),
> > -                         HYPERVISOR_VIRT_END - DIRECTMAP_VIRT_START);
> > -        ret =3D efi_bs->AllocatePages(AllocateMaxAddress, EfiLoaderDat=
a,
> > -                                    PFN_UP(size), &file->addr);
> > -    }
> > +        goto fail;
> > +
> > +    what =3D L"Allocation";
> > +    file->addr =3D min(1UL << (32 + PAGE_SHIFT),
> > +                     HYPERVISOR_VIRT_END - DIRECTMAP_VIRT_START);
> > +    ret =3D efi_bs->AllocatePages(AllocateMaxAddress, EfiLoaderData,
> > +                                PFN_UP(size), &file->addr);
> >      if ( EFI_ERROR(ret) )
> > -        what =3D what ?: L"Allocation";
> > -    else
> > -    {
> > -        file->need_to_free =3D true;
> > -        file->size =3D size;
> > -        handle_file_info(name, file, options);
> > +        goto fail;
> >
> > -        ret =3D FileHandle->Read(FileHandle, &file->size, file->str);
> > -        if ( !EFI_ERROR(ret) && file->size !=3D size )
> > -            ret =3D EFI_ABORTED;
> > -        if ( EFI_ERROR(ret) )
> > -            what =3D L"Read";
> > -    }
> > +    file->need_to_free =3D true;
> > +    file->size =3D size;
> > +    handle_file_info(name, file, options);
> >
> > -    if ( FileHandle )
> > -        FileHandle->Close(FileHandle);
> > +    what =3D L"Read";
> > +    ret =3D FileHandle->Read(FileHandle, &file->size, file->str);
> > +    if ( !EFI_ERROR(ret) && file->size !=3D size )
> > +        ret =3D EFI_ABORTED;
> > +    if ( EFI_ERROR(ret) )
> > +        goto fail;
> >
> > -    if ( what )
> > -    {
> > -        PrintErr(what);
> > -        PrintErr(L" failed for ");
> > -        PrintErrMesg(name, ret);
> > -    }
> > +    FileHandle->Close(FileHandle);
> >
> >      efi_arch_flush_dcache_area(file->ptr, file->size);
> >
> >      return true;
> > +
> > +fail:
>
> Nit: Style (see ./CODING_STYLE).
>

What specifically? I checked the indentation and it's 4 spaces. if-s
are spaced correctly. About labels I didn't find much on CODING_STYLE
so I opened 3/4 files and most of them are indented with no spaces
(they start at column 1).

> Jan

Frediano


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 14:01:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 14:01:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026454.1401641 (Exim 4.92)
	(envelope-from )
	id 1uUnAo-0000kD-0e; Thu, 26 Jun 2025 14:01:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026454.1401641; Thu, 26 Jun 2025 14:01:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUnAn-0000k6-Tn; Thu, 26 Jun 2025 14:01:53 +0000
Received: by outflank-mailman (input) for mailman id 1026454;
 Thu, 26 Jun 2025 14:01: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 1uUnAn-0000k0-BK
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 14:01:53 +0000
Received: from mail187-29.suw11.mandrillapp.com
 (mail187-29.suw11.mandrillapp.com [198.2.187.29])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1b6b3111-5296-11f0-a30f-13f23c93f187;
 Thu, 26 Jun 2025 16:01:51 +0200 (CEST)
Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail187-29.suw11.mandrillapp.com (Mailchimp) with ESMTP id
 4bSgNF6ZNTz7lmc04
 for ; Thu, 26 Jun 2025 14:01:49 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 8d86ec1b1d5845b0bc07aaba3dcfc810; Thu, 26 Jun 2025 14:01: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: 1b6b3111-5296-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1750946509; x=1751216509;
	bh=rMTOANt3p+25g116jy6kB29hJo6UBAKp08lO4/yXHjk=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=ku8DoKafVUJwPvr5jkqA9eiAtHEspUs3u1fwCyGASs72ClDWSsNcjb9gjqS55V2ze
	 T8MF95UHH8P0sgntuX/+L4SFyC+fCro/zlCxhNjXYCP4vZ5yeyENYbWGRRFVt0ZgRB
	 Th5gU8WxSzT/ULfx1RgpYhrbCwwir2kIt2Vgadhx7+XXAztdbSxjOIPG+vdgrOi7De
	 qcsSDs5jpdnrmLlpnynH6uUZjYLUas4ekA7unHi7U4EYvtEVIDPSoaa0VhfmkgE6VN
	 of29ewFwCK5K8kaxW783GfdNtXEoGXnV/1UNYgps7FeTnOYbFNwZtZvpzTRm4TMQAJ
	 Fy46f9XnjiQig==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1750946509; x=1751207009; i=teddy.astie@vates.tech;
	bh=rMTOANt3p+25g116jy6kB29hJo6UBAKp08lO4/yXHjk=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=uXMYOA9bSAkg5u7qo88uN8SkMXuqYba4YSrLLCiza1BXFZ5MIz+/YRa5ucuwr1SSU
	 IP4EVarwh57FLeEnOYbARD20mfBgk+MJpRi85DXVEM5vFzZf8HLTXpP+i2wxdYzhMt
	 dtmqeL9/BuVAyl4/F6iOCRfLUZ3A/rpYOBgWPvGtxI55qGJh5pf8go06Wx4a7HaJ0/
	 9sYFNPwBKj97u16RlcgN7RRIPEefJpP/j5PFoekXntMdqE9kd/2Vaxte+zoTRSIM9B
	 wWxGDHTC/VW5uydozCVWTpHZ6H3PCPWFYlmVE9iGui3gS8ToUqpPPEDcek3+8tWox2
	 BJ+i2mw3ZqxAQ==
From: "Teddy Astie" 
Subject: =?utf-8?Q?[RFC=20PATCH=20v3=201/3]=20vmx:=20Rewrite=20vpid=5Fsync=5Fvcpu=5Fgva?=
X-Mailer: git-send-email 2.50.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1750946506901
To: xen-devel@lists.xenproject.org
Cc: "Teddy Astie" , "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" 
Message-Id: 
In-Reply-To: 
References: 
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.8d86ec1b1d5845b0bc07aaba3dcfc810?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250626:md
Date: Thu, 26 Jun 2025 14:01:49 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Rewrite this function such as it doesn't rely on goto, also change the
type of "type" to match the __invvpid function call.

Suggested-by: Jan Beulich 
Signed-off-by: Teddy Astie 
---
 xen/arch/x86/include/asm/hvm/vmx/vmx.h | 29 +++++++++-----------------
 1 file changed, 10 insertions(+), 19 deletions(-)

diff --git a/xen/arch/x86/include/asm/hvm/vmx/vmx.h b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
index 56bea252cc..8559343857 100644
--- a/xen/arch/x86/include/asm/hvm/vmx/vmx.h
+++ b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
@@ -287,10 +287,10 @@ extern uint8_t posted_intr_vector;
 #define cpu_has_vmx_vpid_invvpid_single_context_retaining_global    \
     (vmx_caps.vpid & VMX_VPID_INVVPID_SINGLE_CONTEXT_RETAINING_GLOBAL)
 
-#define INVVPID_INDIVIDUAL_ADDR                 0
-#define INVVPID_SINGLE_CONTEXT                  1
-#define INVVPID_ALL_CONTEXT                     2
-#define INVVPID_SINGLE_CONTEXT_RETAINING_GLOBAL 3
+#define INVVPID_INDIVIDUAL_ADDR                 0UL
+#define INVVPID_SINGLE_CONTEXT                  1UL
+#define INVVPID_ALL_CONTEXT                     2UL
+#define INVVPID_SINGLE_CONTEXT_RETAINING_GLOBAL 3UL
 
 static always_inline void __vmptrld(u64 addr)
 {
@@ -454,25 +454,16 @@ void ept_sync_domain(struct p2m_domain *p2m);
 
 static inline void vpid_sync_vcpu_gva(struct vcpu *v, unsigned long gva)
 {
-    int type = INVVPID_INDIVIDUAL_ADDR;
+    unsigned long type;
 
-    /*
-     * If individual address invalidation is not supported, we escalate to
-     * use single context invalidation.
-     */
+    /* Use the most precise invalidation type available. */
     if ( likely(cpu_has_vmx_vpid_invvpid_individual_addr) )
-        goto execute_invvpid;
-
-    type = INVVPID_SINGLE_CONTEXT;
-
-    /*
-     * If single context invalidation is not supported, we escalate to
-     * use all context invalidation.
-     */
-    if ( !cpu_has_vmx_vpid_invvpid_single_context )
+        type = INVVPID_INDIVIDUAL_ADDR;
+    else if ( likely(cpu_has_vmx_vpid_invvpid_single_context) )
+        type = INVVPID_SINGLE_CONTEXT;
+    else
         type = INVVPID_ALL_CONTEXT;
 
-execute_invvpid:
     __invvpid(type, v->arch.hvm.n1asid.asid, (u64)gva);
 }
 
-- 
2.50.0



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Thu Jun 26 14:01:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 14:01:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026456.1401657 (Exim 4.92)
	(envelope-from )
	id 1uUnAp-00010Y-FM; Thu, 26 Jun 2025 14:01:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026456.1401657; Thu, 26 Jun 2025 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 1uUnAp-0000zv-9h; Thu, 26 Jun 2025 14:01:55 +0000
Received: by outflank-mailman (input) for mailman id 1026456;
 Thu, 26 Jun 2025 14:01: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 1uUnAo-0000rM-J3
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 14:01:54 +0000
Received: from mail187-29.suw11.mandrillapp.com
 (mail187-29.suw11.mandrillapp.com [198.2.187.29])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1a0bce55-5296-11f0-b894-0df219b8e170;
 Thu, 26 Jun 2025 16:01:49 +0200 (CEST)
Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail187-29.suw11.mandrillapp.com (Mailchimp) with ESMTP id
 4bSgNC5kTXz7lmZNy
 for ; Thu, 26 Jun 2025 14:01:47 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 8194c57ddcf2475c99955f729ca8d011; Thu, 26 Jun 2025 14:01:47 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1a0bce55-5296-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1750946507; x=1751216507;
	bh=D//ZFc6UoOgONIbmthT1nBmp9LrwkgeSRqu/qNbCOso=;
	h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=ayQIMBCHRIhaLqrMuOnp2uKxB7hLenYWdkJTJC9yRDSGCncijLq8vkINwqZVtA/Rb
	 JLkqRlcs8D+b7DbOn/oBz2Pr22QmWx29bKYdYXifPjUOC921YApMJUzrOSj3o9yJVO
	 QF+HjcG2QZ+0+gL2lWHXWU2oYwtY1caY0rr87PjhMW6Z5bvMCF8OAtATYR52159EKj
	 kGOvBP5R9k/M7vPFK0xJ1FQLiWMTC0lWr0S2m8r3mrjVcGfOtvXQuIu00fRy7Na2fo
	 5FLyfmFThBgN9Wwip2mgJMnsVicZKFzu+s+w9RfAI990dFWUBorT7buOS1uJSULEg3
	 cHMznu/RbGUPg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1750946507; x=1751207007; i=teddy.astie@vates.tech;
	bh=D//ZFc6UoOgONIbmthT1nBmp9LrwkgeSRqu/qNbCOso=;
	h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=NQmADtk13iQYLh4XfzP2ihOks0gOVQCeBXjPVeACM0aH8Ur0HoPdLEkBn/SCHL9wC
	 z6zhEwszt9HzcxGV3QeasDWyOfNLqXI1Srn7wC2+VldA3UfDIUjtO/lvd1unuFfNmo
	 aqusrc39PTMSplFb7sJfWpwStPkli+pKwDLMrpEpi2CbPzTO1eOsrhYaildEcPtqF9
	 fvz7hRv3K4PQs0BO5HjTfKXorwrzH1BEJhCoOO18vTWd7PMSSYQnayLVaafAIUDYyw
	 1T1wQv+13de1XytyDwtNmNoaMJhlKgT12fcL8FMGrI44pNaOaGH8m2e3rt/34gDU5Q
	 H8kam+NNWOacw==
From: "Teddy Astie" 
Subject: =?utf-8?Q?[RFC=20PATCH=20v3=200/3]=20x86/hvm:=20Introduce=20Xen-wide=20ASID=20allocator?=
X-Mailer: git-send-email 2.50.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1750946504564
To: xen-devel@lists.xenproject.org
Cc: "Teddy Astie" , "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Anthony PERARD" , "Michal Orzel" , "Julien Grall" , "Stefano Stabellini" 
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.8194c57ddcf2475c99955f729ca8d011?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250626:md
Date: Thu, 26 Jun 2025 14:01:47 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

From: Vaishali Thakkar  (formely vates.tech)
original v2: https://lore.kernel.org/xen-devel/cover.1723574652.git.vaishali.thakkar@vates.tech/

This is part of the effort to enable AMD SEV technologies in Xen. For
AMD SEV support, we need a fixed ASID associated with all vcpus of the
same domain throughout the domain's lifetime. This is because for SEV/
SEV-{ES,SNP} VM, the ASID is the index which is associated with the
encryption key.

Currently, ASID generation and management is done per-PCPU in Xen. And
at the time of each VMENTER, the ASID associated with vcpus of the
domain is changed. This implementation is incompatible with SEV
technologies for the above mentioned reasons. In a discussion with
Andrew Cooper, it came up that it'll be nice to have fixed ASIDs not
only for SEV VMs but also for all VMs. Because it opens up the
opportunity to use features like TLBSYNC/INVLPGB (Section
5.5.3 in AMD Architecture manual[0]) and Intel RAR [1] for broadcasting
the TLB Invalidations.

Changes since v2:
-----------------
A lot has changed since v2, though the concept is still the same.
The asid management logic is a lot simpler, by relying a bitmap to track
all used ASIDs, and freeing them individually instead of using a ASID
reclaim strategy.

When a vCPU needs to be flushed, it is signaled through vcpu.needs_tlb_flush,
indicating that the next time the guest is re-entered, a TLB flush will have
to be issued (either using per-context invvpid on Intel or flush-by-asid
tlb_control on AMD).

Changes were tested on Intel Haswell, KVM AMD virtual machine and AMD EPYC Genoa.

Teddy Astie (3):
  vmx: Rewrite vpid_sync_vcpu_gva
  vmx: Introduce vcpu single context VPID invalidation
  x86/hvm: Introduce Xen-wide ASID allocator

 xen/arch/x86/flushtlb.c                |  31 +++---
 xen/arch/x86/hvm/asid.c                | 148 +++++++++----------------
 xen/arch/x86/hvm/emulate.c             |   2 +-
 xen/arch/x86/hvm/hvm.c                 |  14 ++-
 xen/arch/x86/hvm/nestedhvm.c           |   6 +-
 xen/arch/x86/hvm/svm/asid.c            |  77 ++++++++-----
 xen/arch/x86/hvm/svm/nestedsvm.c       |   1 -
 xen/arch/x86/hvm/svm/svm.c             |  36 +++---
 xen/arch/x86/hvm/svm/svm.h             |   4 -
 xen/arch/x86/hvm/vmx/vmcs.c            |   5 +-
 xen/arch/x86/hvm/vmx/vmx.c             |  68 ++++++------
 xen/arch/x86/hvm/vmx/vvmx.c            |   5 +-
 xen/arch/x86/include/asm/flushtlb.h    |   7 --
 xen/arch/x86/include/asm/hvm/asid.h    |  25 ++---
 xen/arch/x86/include/asm/hvm/domain.h  |   1 +
 xen/arch/x86/include/asm/hvm/hvm.h     |  15 +--
 xen/arch/x86/include/asm/hvm/svm/svm.h |   5 +
 xen/arch/x86/include/asm/hvm/vcpu.h    |  10 +-
 xen/arch/x86/include/asm/hvm/vmx/vmx.h |  44 ++++----
 xen/arch/x86/mm/hap/hap.c              |   6 +-
 xen/arch/x86/mm/p2m.c                  |   7 +-
 xen/arch/x86/mm/paging.c               |   2 +-
 xen/arch/x86/mm/shadow/hvm.c           |   1 +
 xen/arch/x86/mm/shadow/multi.c         |  12 +-
 xen/include/xen/sched.h                |   2 +
 25 files changed, 249 insertions(+), 285 deletions(-)

-- 
2.50.0



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Thu Jun 26 14:01:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 14:01:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026455.1401652 (Exim 4.92)
	(envelope-from )
	id 1uUnAp-0000yJ-6S; Thu, 26 Jun 2025 14:01:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026455.1401652; Thu, 26 Jun 2025 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 1uUnAp-0000yC-3q; Thu, 26 Jun 2025 14:01:55 +0000
Received: by outflank-mailman (input) for mailman id 1026455;
 Thu, 26 Jun 2025 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 1uUnAo-0000k0-F0
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 14:01:54 +0000
Received: from mail187-29.suw11.mandrillapp.com
 (mail187-29.suw11.mandrillapp.com [198.2.187.29])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1cd261f3-5296-11f0-a30f-13f23c93f187;
 Thu, 26 Jun 2025 16:01:53 +0200 (CEST)
Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail187-29.suw11.mandrillapp.com (Mailchimp) with ESMTP id
 4bSgNJ2FDMz7lmc0K
 for ; Thu, 26 Jun 2025 14:01:52 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 1e65ae06e1504cd5bff887064f71c6f6; Thu, 26 Jun 2025 14:01: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: 1cd261f3-5296-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1750946512; x=1751216512;
	bh=vYNfbUgiAlXIcQwc14Rgxl0bPeXHRh2iS+BzaTbjWWg=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=D9GcbzrObh7seVpnRikE8+f93RPKH1DnjzwsdOMmlOaPR8PRZR4/eA9nsxoquok+z
	 4s20EOJ1NjB8jjZpD1DoMhSo35SF7Pr5N4TNqwQgDujefqfBDpGN6FWvKD0DNjJdiX
	 7xiG9156s/fcKQI7Gf6XDjWJrpb+BUzQ26yslUFDcl944vsrj8eH4DHWmGZtpd8t7i
	 CRYAeQBlOfFN2Mw6nZKls9JDGCrwCrRMho57+uvpiItXDBadiwWXUx6W+xLDWfGMiY
	 bGm6BVfdR5PhbI5BUk7MoQeXePEIKC6cZ44yCXcpM612vRrZp0BVNP6Hpc9n7Y0nyc
	 yvpf+APYPxa5w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1750946512; x=1751207012; i=teddy.astie@vates.tech;
	bh=vYNfbUgiAlXIcQwc14Rgxl0bPeXHRh2iS+BzaTbjWWg=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=G4TpTOaTQM9XBp0xxTempTFrHaYENTUmNgRMYSRaPol/Z82gW4TsbFGt0FobWk5P6
	 20fbW9ozSVjziY1MYMe/rubswo0JtpfsbKoCoJajgivmnVxyhUTNoyWkaRRe/Iu8n4
	 7dp4qFHEpXt2wGj+bhJGKUGY1WBEYp0iMzIXEuXMZOfHFF6FX7mqEbnncIg0I/1QyH
	 bhtzO4UlGfUari/g2SxjZ8A/fVDFd+PLzvU6Rp2fpUzvxZcciDlPEnMN/ddXPSPqDw
	 Jo7/now34Z2eWMsR+LZr9xbyx/go45RF5Vdofc3Ap5VMp1N0WynwWl+vg0t+OMJ8RZ
	 HylAL2qteTIuA==
From: "Teddy Astie" 
Subject: =?utf-8?Q?[RFC=20PATCH=20v3=202/3]=20vmx:=20Introduce=20vcpu=20single=20context=20VPID=20invalidation?=
X-Mailer: git-send-email 2.50.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1750946509336
To: xen-devel@lists.xenproject.org
Cc: "Teddy Astie" , "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" 
Message-Id: <5aa649e122401c627d4560f68d156ead470ef6d6.1750770621.git.teddy.astie@vates.tech>
In-Reply-To: 
References: 
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.1e65ae06e1504cd5bff887064f71c6f6?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250626:md
Date: Thu, 26 Jun 2025 14:01:52 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Introduce vpid_sync_vcpu_context to do a single-context invalidation
on the vpid attached to the vcpu as a alternative to per-gva and all-context
invlidations.

Signed-off-by: Teddy Astie 
---
 xen/arch/x86/include/asm/hvm/vmx/vmx.h | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/xen/arch/x86/include/asm/hvm/vmx/vmx.h b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
index 8559343857..173311bfbb 100644
--- a/xen/arch/x86/include/asm/hvm/vmx/vmx.h
+++ b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
@@ -452,6 +452,19 @@ static inline void ept_sync_all(void)
 
 void ept_sync_domain(struct p2m_domain *p2m);
 
+static inline void vpid_sync_vcpu_context(struct vcpu *v)
+{
+    unsigned long type;
+
+    /* Use the most precise invalidation type available. */
+    if ( likely(cpu_has_vmx_vpid_invvpid_single_context) )
+        type = INVVPID_SINGLE_CONTEXT;
+    else
+        type = INVVPID_ALL_CONTEXT;
+
+    __invvpid(type, v->arch.hvm.n1asid.asid, 0);
+}
+
 static inline void vpid_sync_vcpu_gva(struct vcpu *v, unsigned long gva)
 {
     unsigned long type;
-- 
2.50.0



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Thu Jun 26 14:01:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 14:01:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026457.1401672 (Exim 4.92)
	(envelope-from )
	id 1uUnAt-0001SG-K3; Thu, 26 Jun 2025 14:01:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026457.1401672; Thu, 26 Jun 2025 14:01: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 1uUnAt-0001S9-HL; Thu, 26 Jun 2025 14:01:59 +0000
Received: by outflank-mailman (input) for mailman id 1026457;
 Thu, 26 Jun 2025 14:01: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 1uUnAs-0000rM-Ih
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 14:01:58 +0000
Received: from mail186-10.suw21.mandrillapp.com
 (mail186-10.suw21.mandrillapp.com [198.2.186.10])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1e2cbcff-5296-11f0-b894-0df219b8e170;
 Thu, 26 Jun 2025 16:01:56 +0200 (CEST)
Received: from pmta10.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail186-10.suw21.mandrillapp.com (Mailchimp) with ESMTP id
 4bSgNL6txvz5QkLn0
 for ; Thu, 26 Jun 2025 14:01:54 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 73c8d3664bef4407a8edfc05b3ae1149; Thu, 26 Jun 2025 14:01: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: 1e2cbcff-5296-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1750946515; x=1751216515;
	bh=Rm64bWElnba8o8Te6BBLMhNLYbaDnb1OyqjnZTCWD5A=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=ks0XwuoXCRNxpBdBUWVdicngk58DFFtfATCNsr2gwa9y/FD+KJgdUP9QtIIZ6mrNB
	 Ng5DW5db6ziT2oGXCuyha7U6anodbXH9ZHZYUzrR+5xsON7H2cgEEGns3DKUFIFZ5f
	 u/7h6etCMnu80SS1kvUHjBGAiWxiRtI4//+VXePaCFRpfptjEjMBEqMc24lpxrnXMH
	 HTtwQJdiUjQEL9qL/5URoEh1/NDMKwpy/JDSiLwSJ8TG2OOXKOvg5D+qD+pehKoaoY
	 qyGMheS3WTJvmvfAmUqJvm9o9NjI4NyblUyJDon0t8qbnq49rFSLeYE3mXuckBbmGx
	 43908xQ+RIang==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1750946515; x=1751207015; i=teddy.astie@vates.tech;
	bh=Rm64bWElnba8o8Te6BBLMhNLYbaDnb1OyqjnZTCWD5A=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=aToLUTJpKemxiWUmZbF8VBx+G/N86Z7EHsR8NXXs63wmDshnWgWMFL5ccmcIkAwZG
	 uh2/5ZaxM9PLf7v9xM3QZBOu++mJr6NnFQb1ipQd6liE8LvRKrS0ijOx/XAXDu3ZIA
	 3bBVyA1t//8LlNhWliUK+p2MwymS99OS7KWUO/CJn1fwrn2M2aQfwDc0yjmgJzGnCf
	 fzFuY+Fbbj7HnxC0wQk8vuXcoMLw+vRodA2/Twm4m8oVI2BJtUlQ3IGOjDnah/OVwz
	 O/qN6JGVRpD9VGu+dMAqU1YVjGLFoEpMQP/jcq3otKao+6US9xSmQd9KxP5TamuHOz
	 wYdbWpnuaWHeg==
From: "Teddy Astie" 
Subject: =?utf-8?Q?[RFC=20PATCH=20v3=203/3]=20x86/hvm:=20Introduce=20Xen-wide=20ASID=20allocator?=
X-Mailer: git-send-email 2.50.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1750946511780
To: xen-devel@lists.xenproject.org
Cc: "Teddy Astie" , "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Anthony PERARD" , "Michal Orzel" , "Julien Grall" , "Stefano Stabellini" , "Vaishali Thakkar" , "Oleksii Kurochko" 
Message-Id: <81169a40fdc8c124b1656e451ac2e81f4e8edd2d.1750770621.git.teddy.astie@vates.tech>
In-Reply-To: 
References: 
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.73c8d3664bef4407a8edfc05b3ae1149?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250626:md
Date: Thu, 26 Jun 2025 14:01:54 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

From: Vaishali Thakkar  (formely vates.tech)

Currently ASID generation and management is done per-PCPU. This
scheme is incompatible with SEV technologies as SEV VMs need to
have a fixed ASID associated with all vcpus of the VM throughout
it's lifetime.

This commit introduces a Xen-wide allocator which initializes
the asids at the start of xen and allows to have a fixed asids
throughout the lifecycle of all domains. Having a fixed asid
for non-SEV domains also presents us with the opportunity to
further take use of AMD instructions like TLBSYNC and INVLPGB
for broadcasting the TLB invalidations.

Introduce vcpu->needs_tlb_flush attribute to schedule a guest TLB
flush for the next VMRUN/VMENTER. This will be later be done using
either TLB_CONTROL field (AMD) or INVEPT (Intel). This flush method
is used in place of the current ASID swapping logic.

Signed-off-by: Teddy Astie 
Signed-off-by: Vaishali Thakkar  (formely vates.tech)
---
CC: Oleksii Kurochko 

Should the ASID/VPID/VMID management logic code being shared accross
x86/ARM/RISC-V ?

Is it possible to have multiples vCPUs of a same domain simultaneously
scheduled on top of a single pCPU ? If so, it would need a special
consideration for this corner case, such as we don't miss a TLB flush
in such cases.

I get various stability when testing shadow paging in these patches, unsure
what's the exact root case. HAP works perfectly fine though.

TODO:
- Intel: Don't assign the VPID at each VMENTER, though we need
  to rethink how we manage VMCS with nested virtualization / altp2m
  for changing this behavior.
- AMD: Consider hot-plug of CPU with ERRATA_170. (is it possible ?)
- Consider cases where we don't have enough ASIDs (e.g Xen as nested guest)
- Nested virtualization ASID management

Changes since v2:
 - Moved hvm_asid_domain_create to hvm_domain_initialise
 - Added __ro_after_init for bitmaps
 - Make hvm_asid_init  unsigned int __init
 - Drop functions hvm_asid_flush_domain_asid and hvm_asid_flush_vcpu
 - Mark ASID 0 permenantly
 - Add a logic to move asids from reclaim_bitmap->asid_bitmap
 - Misc styling fixes - remove unncessary trailing spaces/printks
 - Simplified asid bitmap management
   It is only called once per domain, so it doesn't need to have
   a complicated logic.
 - Drop hvm_asid_data structure which doesn't serve a purpose anymore.
 - Introduce and use vcpu->needs_tlb_flush to indicate that a guest TLB
   flush is needed before waking the vcpu. It is used to set
   TLB_CONTROL (AMD) field properly or make a appropriate invept (Intel).
 - Only assign ASID once (see TODO for Intel side)
 - Check the ERRATA_170 for each CPU present.
 - rewrote guest_flush_tlb_mask for this new mecanism

Changes since v1:
 - Introudce hvm_asid_bitmap as discussed at Xen-summit
 - Introduce hvm_reclaim_bitmap for reusing ASIDs
 - Assign the asid to the domain at the domain creation via
   hvm_asid_domain_create
 - Corrected the use of CPUID in the svm_asid_init function
 - Adjusted the code in nested virtualization related files
   to use new scheme. As discussed at the Xen-summit, this
   is not tested.
 - Addressed Jan's comments about using uniform style for
   accessing domains via v->domain
 - Allow to flush at the vcpu level in HAP code
 - Documented the sketch of implementation for the new scheme
 - Remove min_asid as for this patch, we are not demonstarting
   it's usecase
 - Arrange includes in multiple files as per Jan's feedback
---
 xen/arch/x86/flushtlb.c                |  31 +++---
 xen/arch/x86/hvm/asid.c                | 148 +++++++++----------------
 xen/arch/x86/hvm/emulate.c             |   2 +-
 xen/arch/x86/hvm/hvm.c                 |  14 ++-
 xen/arch/x86/hvm/nestedhvm.c           |   6 +-
 xen/arch/x86/hvm/svm/asid.c            |  77 ++++++++-----
 xen/arch/x86/hvm/svm/nestedsvm.c       |   1 -
 xen/arch/x86/hvm/svm/svm.c             |  36 +++---
 xen/arch/x86/hvm/svm/svm.h             |   4 -
 xen/arch/x86/hvm/vmx/vmcs.c            |   5 +-
 xen/arch/x86/hvm/vmx/vmx.c             |  68 ++++++------
 xen/arch/x86/hvm/vmx/vvmx.c            |   5 +-
 xen/arch/x86/include/asm/flushtlb.h    |   7 --
 xen/arch/x86/include/asm/hvm/asid.h    |  25 ++---
 xen/arch/x86/include/asm/hvm/domain.h  |   1 +
 xen/arch/x86/include/asm/hvm/hvm.h     |  15 +--
 xen/arch/x86/include/asm/hvm/svm/svm.h |   5 +
 xen/arch/x86/include/asm/hvm/vcpu.h    |  10 +-
 xen/arch/x86/include/asm/hvm/vmx/vmx.h |   4 +-
 xen/arch/x86/mm/hap/hap.c              |   6 +-
 xen/arch/x86/mm/p2m.c                  |   7 +-
 xen/arch/x86/mm/paging.c               |   2 +-
 xen/arch/x86/mm/shadow/hvm.c           |   1 +
 xen/arch/x86/mm/shadow/multi.c         |  12 +-
 xen/include/xen/sched.h                |   2 +
 25 files changed, 227 insertions(+), 267 deletions(-)

diff --git a/xen/arch/x86/flushtlb.c b/xen/arch/x86/flushtlb.c
index 796b25dad6..8ddb4dc6cb 100644
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -124,7 +125,6 @@ void switch_cr3_cr4(unsigned long cr3, unsigned long cr4)
 
     if ( tlb_clk_enabled )
         t = pre_flush();
-    hvm_flush_guest_tlbs();
 
     old_cr4 = read_cr4();
     ASSERT(!(old_cr4 & X86_CR4_PCIDE) || !(old_cr4 & X86_CR4_PGE));
@@ -229,9 +229,6 @@ unsigned int flush_area_local(const void *va, unsigned int flags)
             do_tlb_flush();
     }
 
-    if ( flags & FLUSH_HVM_ASID_CORE )
-        hvm_flush_guest_tlbs();
-
     if ( flags & (FLUSH_CACHE | FLUSH_CACHE_WRITEBACK) )
     {
         const struct cpuinfo_x86 *c = ¤t_cpu_data;
@@ -321,18 +318,24 @@ void cache_writeback(const void *addr, unsigned int size)
     asm volatile ("sfence" ::: "memory");
 }
 
-unsigned int guest_flush_tlb_flags(const struct domain *d)
+void guest_flush_tlb_mask(const struct domain *d, const cpumask_t *mask)
 {
-    bool shadow = paging_mode_shadow(d);
-    bool asid = is_hvm_domain(d) && (cpu_has_svm || shadow);
+    struct vcpu *v;
 
-    return (shadow ? FLUSH_TLB : 0) | (asid ? FLUSH_HVM_ASID_CORE : 0);
-}
+    if ( is_pv_domain(d) )
+    {
+        flush_tlb_mask(mask);
+        return;
+    }
 
-void guest_flush_tlb_mask(const struct domain *d, const cpumask_t *mask)
-{
-    unsigned int flags = guest_flush_tlb_flags(d);
+    for_each_vcpu(d, v)
+        if ( cpumask_test_cpu(v->vcpu_id, mask) )
+            v->needs_tlb_flush = true;
 
-    if ( flags )
-        flush_mask(mask, flags);
+    smp_wmb();
+
+    if ( paging_mode_shadow(d) )
+        flush_tlb_mask(mask);
+    else
+        on_selected_cpus(mask, NULL, NULL, 0);
 }
diff --git a/xen/arch/x86/hvm/asid.c b/xen/arch/x86/hvm/asid.c
index 8d27b7dba1..04ac2ddc89 100644
--- a/xen/arch/x86/hvm/asid.c
+++ b/xen/arch/x86/hvm/asid.c
@@ -8,133 +8,85 @@
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
+#include 
+#include 
+
 #include 
+#include 
 
 /* Xen command-line option to enable ASIDs */
 static bool __read_mostly opt_asid_enabled = true;
 boolean_param("asid", opt_asid_enabled);
 
+bool __read_mostly asid_enabled = false;
+static unsigned long __ro_after_init *asid_bitmap;
+static unsigned long __ro_after_init asid_count;
+static DEFINE_SPINLOCK(asid_lock);
+
 /*
- * ASIDs partition the physical TLB.  In the current implementation ASIDs are
- * introduced to reduce the number of TLB flushes.  Each time the guest's
- * virtual address space changes (e.g. due to an INVLPG, MOV-TO-{CR3, CR4}
- * operation), instead of flushing the TLB, a new ASID is assigned.  This
- * reduces the number of TLB flushes to at most 1/#ASIDs.  The biggest
- * advantage is that hot parts of the hypervisor's code and data retain in
- * the TLB.
- *
  * Sketch of the Implementation:
- *
- * ASIDs are a CPU-local resource.  As preemption of ASIDs is not possible,
- * ASIDs are assigned in a round-robin scheme.  To minimize the overhead of
- * ASID invalidation, at the time of a TLB flush,  ASIDs are tagged with a
- * 64-bit generation.  Only on a generation overflow the code needs to
- * invalidate all ASID information stored at the VCPUs with are run on the
- * specific physical processor.  This overflow appears after about 2^80
- * host processor cycles, so we do not optimize this case, but simply disable
- * ASID useage to retain correctness.
+ * ASIDs are assigned uniquely per domain and doesn't change during
+ * the lifecycle of the domain. Once vcpus are initialized and are up,
+ * we assign the same ASID to all vcpus of that domain at the first VMRUN.
+ * In order to process a TLB flush on a vcpu, we set needs_tlb_flush
+ * to schedule a TLB flush for the next VMRUN (e.g using tlb control field
+ * of VMCB).
  */
 
-/* Per-CPU ASID management. */
-struct hvm_asid_data {
-   uint64_t core_asid_generation;
-   uint32_t next_asid;
-   uint32_t max_asid;
-   bool disabled;
-};
-
-static DEFINE_PER_CPU(struct hvm_asid_data, hvm_asid_data);
-
-void hvm_asid_init(int nasids)
+int __init hvm_asid_init(unsigned long nasids)
 {
-    static int8_t g_disabled = -1;
-    struct hvm_asid_data *data = &this_cpu(hvm_asid_data);
+    ASSERT(nasids);
 
-    data->max_asid = nasids - 1;
-    data->disabled = !opt_asid_enabled || (nasids <= 1);
+    asid_count = nasids;
+    asid_enabled = opt_asid_enabled || (nasids <= 1);
 
-    if ( g_disabled != data->disabled )
-    {
-        printk("HVM: ASIDs %sabled.\n", data->disabled ? "dis" : "en");
-        if ( g_disabled < 0 )
-            g_disabled = data->disabled;
-    }
+    asid_bitmap = xvzalloc_array(unsigned long, BITS_TO_LONGS(asid_count));
+    if ( !asid_bitmap )
+        return -ENOMEM;
 
-    /* Zero indicates 'invalid generation', so we start the count at one. */
-    data->core_asid_generation = 1;
+    printk("HVM: ASIDs %sabled (count=%lu)\n", asid_enabled ? "en" : "dis", asid_count);
 
-    /* Zero indicates 'ASIDs disabled', so we start the count at one. */
-    data->next_asid = 1;
-}
+    /* ASID 0 is reserved, mark it as permanently used */
+    set_bit(0, asid_bitmap);
 
-void hvm_asid_flush_vcpu_asid(struct hvm_vcpu_asid *asid)
-{
-    write_atomic(&asid->generation, 0);
+    return 0;
 }
 
-void hvm_asid_flush_vcpu(struct vcpu *v)
+int hvm_asid_alloc(struct hvm_asid *asid)
 {
-    hvm_asid_flush_vcpu_asid(&v->arch.hvm.n1asid);
-    hvm_asid_flush_vcpu_asid(&vcpu_nestedhvm(v).nv_n2asid);
-}
+    unsigned long new_asid;
 
-void hvm_asid_flush_core(void)
-{
-    struct hvm_asid_data *data = &this_cpu(hvm_asid_data);
+    if ( !asid_enabled )
+    {
+        asid->asid = 1;
+        return 0;
+    }
 
-    if ( data->disabled )
-        return;
+    spin_lock(&asid_lock);
+    new_asid = find_first_zero_bit(asid_bitmap, asid_count);
+    if ( new_asid > asid_count )
+        return -ENOSPC;
 
-    if ( likely(++data->core_asid_generation != 0) )
-        return;
+    set_bit(new_asid, asid_bitmap);
 
-    /*
-     * ASID generations are 64 bit.  Overflow of generations never happens.
-     * For safety, we simply disable ASIDs, so correctness is established; it
-     * only runs a bit slower.
-     */
-    printk("HVM: ASID generation overrun. Disabling ASIDs.\n");
-    data->disabled = 1;
+    asid->asid = new_asid;
+    spin_unlock(&asid_lock);
+    return 0;
 }
 
-bool hvm_asid_handle_vmenter(struct hvm_vcpu_asid *asid)
+void hvm_asid_free(struct hvm_asid *asid)
 {
-    struct hvm_asid_data *data = &this_cpu(hvm_asid_data);
-
-    /* On erratum #170 systems we must flush the TLB. 
-     * Generation overruns are taken here, too. */
-    if ( data->disabled )
-        goto disabled;
-
-    /* Test if VCPU has valid ASID. */
-    if ( read_atomic(&asid->generation) == data->core_asid_generation )
-        return 0;
-
-    /* If there are no free ASIDs, need to go to a new generation */
-    if ( unlikely(data->next_asid > data->max_asid) )
-    {
-        hvm_asid_flush_core();
-        data->next_asid = 1;
-        if ( data->disabled )
-            goto disabled;
-    }
+    ASSERT( asid->asid );
 
-    /* Now guaranteed to be a free ASID. */
-    asid->asid = data->next_asid++;
-    write_atomic(&asid->generation, data->core_asid_generation);
+    if ( !asid_enabled )
+        return;
 
-    /*
-     * When we assign ASID 1, flush all TLB entries as we are starting a new
-     * generation, and all old ASID allocations are now stale. 
-     */
-    return (asid->asid == 1);
+    ASSERT( asid->asid < asid_count );
 
- disabled:
-    asid->asid = 0;
-    return 0;
+    spin_lock(&asid_lock);
+    WARN_ON(!test_bit(asid->asid, asid_bitmap));
+    clear_bit(asid->asid, asid_bitmap);
+    spin_unlock(&asid_lock);
 }
 
 /*
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 91f004d233..6ed8e03475 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -2666,7 +2666,7 @@ static int cf_check hvmemul_tlb_op(
     case x86emul_invpcid:
         if ( x86emul_invpcid_type(aux) != X86_INVPCID_INDIV_ADDR )
         {
-            hvm_asid_flush_vcpu(current);
+            current->needs_tlb_flush = true;
             break;
         }
         aux = x86emul_invpcid_pcid(aux);
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 4cb2e13046..6cac062ba6 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -702,6 +702,10 @@ int hvm_domain_initialise(struct domain *d,
     if ( rc )
         goto fail2;
 
+    rc = hvm_asid_alloc(&d->arch.hvm.asid);
+    if ( rc )
+        goto fail2;
+
     rc = alternative_call(hvm_funcs.domain_initialise, d);
     if ( rc != 0 )
         goto fail2;
@@ -782,8 +786,9 @@ void hvm_domain_destroy(struct domain *d)
         list_del(&ioport->list);
         xfree(ioport);
     }
-
+    hvm_asid_free(&d->arch.hvm.asid);
     destroy_vpci_mmcfg(d);
+
 }
 
 static int cf_check hvm_save_tsc_adjust(struct vcpu *v, hvm_domain_context_t *h)
@@ -1603,7 +1608,7 @@ int hvm_vcpu_initialise(struct vcpu *v)
     int rc;
     struct domain *d = v->domain;
 
-    hvm_asid_flush_vcpu(v);
+    v->needs_tlb_flush = true;
 
     spin_lock_init(&v->arch.hvm.tm_lock);
     INIT_LIST_HEAD(&v->arch.hvm.tm_list);
@@ -4134,6 +4139,11 @@ static void hvm_s3_resume(struct domain *d)
     }
 }
 
+int hvm_flush_tlb(const unsigned long *vcpu_bitmap)
+{
+    return current->domain->arch.paging.flush_tlb(vcpu_bitmap);
+}
+
 static int hvmop_flush_tlb_all(void)
 {
     if ( !is_hvm_domain(current->domain) )
diff --git a/xen/arch/x86/hvm/nestedhvm.c b/xen/arch/x86/hvm/nestedhvm.c
index bddd77d810..ed1b9303ad 100644
--- a/xen/arch/x86/hvm/nestedhvm.c
+++ b/xen/arch/x86/hvm/nestedhvm.c
@@ -36,13 +36,11 @@ nestedhvm_vcpu_reset(struct vcpu *v)
     hvm_unmap_guest_frame(nv->nv_vvmcx, 1);
     nv->nv_vvmcx = NULL;
     nv->nv_vvmcxaddr = INVALID_PADDR;
-    nv->nv_flushp2m = 0;
+    nv->nv_flushp2m = true;
     nv->nv_p2m = NULL;
     nv->stale_np2m = false;
     nv->np2m_generation = 0;
 
-    hvm_asid_flush_vcpu_asid(&nv->nv_n2asid);
-
     alternative_vcall(hvm_funcs.nhvm_vcpu_reset, v);
 
     /* vcpu is in host mode */
@@ -86,7 +84,7 @@ static void cf_check nestedhvm_flushtlb_ipi(void *info)
      * This is cheaper than flush_tlb_local() and has
      * the same desired effect.
      */
-    hvm_asid_flush_core();
+    WARN_ON(hvm_flush_tlb(NULL));
     vcpu_nestedhvm(v).nv_p2m = NULL;
     vcpu_nestedhvm(v).stale_np2m = true;
 }
diff --git a/xen/arch/x86/hvm/svm/asid.c b/xen/arch/x86/hvm/svm/asid.c
index 7977a8e86b..1b6def4a4c 100644
--- a/xen/arch/x86/hvm/svm/asid.c
+++ b/xen/arch/x86/hvm/svm/asid.c
@@ -1,56 +1,77 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 /*
- * asid.c: handling ASIDs in SVM.
+ * asid.c: handling ASIDs/VPIDs.
  * Copyright (c) 2007, Advanced Micro Devices, Inc.
  */
 
+#include 
+
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "svm.h"
 
-void svm_asid_init(const struct cpuinfo_x86 *c)
+void __init svm_asid_init(void)
 {
-    int nasids = 0;
+    unsigned int cpu;
+    int nasids = cpuid_ebx(0x8000000aU);
+
+    if ( !nasids )
+        nasids = 1;
 
-    /* Check for erratum #170, and leave ASIDs disabled if it's present. */
-    if ( !cpu_has_amd_erratum(c, AMD_ERRATUM_170) )
-        nasids = cpuid_ebx(0x8000000aU);
+    for_each_present_cpu(cpu)
+    {
+        /* Check for erratum #170, and leave ASIDs disabled if it's present. */
+        if ( cpu_has_amd_erratum(&cpu_data[cpu], AMD_ERRATUM_170) )
+        {
+            printk(XENLOG_WARNING "Disabling ASID due to errata 170 on CPU%u\n", cpu);
+            nasids = 1;
+        }
+    }
 
-    hvm_asid_init(nasids);
+    BUG_ON(hvm_asid_init(nasids));
 }
 
 /*
- * Called directly before VMRUN.  Checks if the VCPU needs a new ASID,
- * assigns it, and if required, issues required TLB flushes.
+ * Called directly at the first VMRUN/VMENTER of a vcpu to assign the ASID/VPID.
  */
-void svm_asid_handle_vmrun(void)
+void svm_vcpu_assign_asid(struct vcpu *v)
 {
-    struct vcpu *curr = current;
-    struct vmcb_struct *vmcb = curr->arch.hvm.svm.vmcb;
-    struct hvm_vcpu_asid *p_asid =
-        nestedhvm_vcpu_in_guestmode(curr)
-        ? &vcpu_nestedhvm(curr).nv_n2asid : &curr->arch.hvm.n1asid;
-    bool need_flush = hvm_asid_handle_vmenter(p_asid);
-
-    /* ASID 0 indicates that ASIDs are disabled. */
-    if ( p_asid->asid == 0 )
-    {
-        vmcb_set_asid(vmcb, true);
-        vmcb->tlb_control =
-            cpu_has_svm_flushbyasid ? TLB_CTRL_FLUSH_ASID : TLB_CTRL_FLUSH_ALL;
-        return;
-    }
+    struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb;
+    struct hvm_asid *p_asid = &v->domain->arch.hvm.asid;
+
+    ASSERT(p_asid->asid);
 
-    if ( vmcb_get_asid(vmcb) != p_asid->asid )
-        vmcb_set_asid(vmcb, p_asid->asid);
+    /* In case ASIDs are disabled, as ASID = 0 is reserved, guest can use 1 instead. */
+    vmcb_set_asid(vmcb, asid_enabled ? p_asid->asid : 1);
+}
+
+/* Call to make a TLB flush at the next VMRUN. */
+void svm_vcpu_set_tlb_control(struct vcpu *v)
+{
+    struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb;
+    
+    /*
+     * If the vcpu is already running, the tlb control flag may not be
+     * processed and will be cleared at the next VMEXIT, which will undo
+     * what we are trying to do.
+     */
+    WARN_ON(v != current && v->is_running);
 
     vmcb->tlb_control =
-        !need_flush ? TLB_CTRL_NO_FLUSH :
         cpu_has_svm_flushbyasid ? TLB_CTRL_FLUSH_ASID : TLB_CTRL_FLUSH_ALL;
 }
 
+void svm_vcpu_clear_tlb_control(struct vcpu *v)
+{
+    struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb;
+
+    vmcb->tlb_control = TLB_CTRL_NO_FLUSH;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c
index dc2b6a4253..975b796d01 100644
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -699,7 +699,6 @@ nsvm_vcpu_vmentry(struct vcpu *v, struct cpu_user_regs *regs,
     if ( svm->ns_asid != vmcb_get_asid(ns_vmcb))
     {
         nv->nv_flushp2m = 1;
-        hvm_asid_flush_vcpu_asid(&vcpu_nestedhvm(v).nv_n2asid);
         svm->ns_asid = vmcb_get_asid(ns_vmcb);
     }
 
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index e33a38c1e4..4ec6caee27 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -183,14 +184,17 @@ static void cf_check svm_update_guest_cr(
         if ( !nestedhvm_enabled(v->domain) )
         {
             if ( !(flags & HVM_UPDATE_GUEST_CR3_NOFLUSH) )
-                hvm_asid_flush_vcpu(v);
+                v->needs_tlb_flush = true;
         }
         else if ( nestedhvm_vmswitch_in_progress(v) )
             ; /* CR3 switches during VMRUN/VMEXIT do not flush the TLB. */
         else if ( !(flags & HVM_UPDATE_GUEST_CR3_NOFLUSH) )
-            hvm_asid_flush_vcpu_asid(
-                nestedhvm_vcpu_in_guestmode(v)
-                ? &vcpu_nestedhvm(v).nv_n2asid : &v->arch.hvm.n1asid);
+        {
+            if (nestedhvm_vcpu_in_guestmode(v))
+                vcpu_nestedhvm(v).nv_flushp2m = true;
+            else
+                v->needs_tlb_flush = true;
+        }
         break;
     case 4:
         value = HVM_CR4_HOST_MASK;
@@ -991,8 +995,7 @@ static void noreturn cf_check svm_do_resume(void)
         v->arch.hvm.svm.launch_core = smp_processor_id();
         hvm_migrate_timers(v);
         hvm_migrate_pirqs(v);
-        /* Migrating to another ASID domain.  Request a new ASID. */
-        hvm_asid_flush_vcpu(v);
+        v->needs_tlb_flush = true;
     }
 
     if ( !vcpu_guestmode && !vlapic_hw_disabled(vlapic) )
@@ -1019,13 +1022,15 @@ void asmlinkage svm_vmenter_helper(void)
 
     ASSERT(hvmemul_cache_disabled(curr));
 
-    svm_asid_handle_vmrun();
-
     TRACE_TIME(TRC_HVM_VMENTRY |
                (nestedhvm_vcpu_in_guestmode(curr) ? TRC_HVM_NESTEDFLAG : 0));
 
     svm_sync_vmcb(curr, vmcb_needs_vmsave);
 
+    if ( test_and_clear_bool(curr->needs_tlb_flush) ||
+         paging_mode_shadow(curr->domain) )
+        svm_vcpu_set_tlb_control(curr);
+
     vmcb->rax = regs->rax;
     vmcb->rip = regs->rip;
     vmcb->rsp = regs->rsp;
@@ -1146,6 +1151,8 @@ static int cf_check svm_vcpu_initialise(struct vcpu *v)
         return rc;
     }
 
+    svm_vcpu_assign_asid(v);
+
     return 0;
 }
 
@@ -1572,9 +1579,6 @@ static int _svm_cpu_up(bool bsp)
     /* check for erratum 383 */
     svm_init_erratum_383(c);
 
-    /* Initialize core's ASID handling. */
-    svm_asid_init(c);
-
     /* Initialize OSVW bits to be used by guests */
     svm_host_osvw_init();
 
@@ -2338,7 +2342,7 @@ static void svm_invlpga_intercept(
 {
     svm_invlpga(linear,
                 (asid == 0)
-                ? v->arch.hvm.n1asid.asid
+                ? v->domain->arch.hvm.asid.asid
                 : vcpu_nestedhvm(v).nv_n2asid.asid);
 }
 
@@ -2360,8 +2364,8 @@ static bool cf_check is_invlpg(
 
 static void cf_check svm_invlpg(struct vcpu *v, unsigned long linear)
 {
-    /* Safe fallback. Take a new ASID. */
-    hvm_asid_flush_vcpu(v);
+    /* Schedule a tlb flush on the VCPU. */
+    v->needs_tlb_flush = true;
 }
 
 static bool cf_check svm_get_pending_event(
@@ -2528,6 +2532,8 @@ const struct hvm_function_table * __init start_svm(void)
     svm_function_table.caps.hap_superpage_2mb = true;
     svm_function_table.caps.hap_superpage_1gb = cpu_has_page1gb;
 
+    svm_asid_init();
+
     return &svm_function_table;
 }
 
@@ -2584,6 +2590,8 @@ void asmlinkage svm_vmexit_handler(void)
                    (vlapic_get_reg(vlapic, APIC_TASKPRI) & 0x0F));
     }
 
+    svm_vcpu_clear_tlb_control(v);
+
     exit_reason = vmcb->exitcode;
 
     if ( hvm_long_mode_active(v) )
diff --git a/xen/arch/x86/hvm/svm/svm.h b/xen/arch/x86/hvm/svm/svm.h
index f5b0312d2d..92145c6d7b 100644
--- a/xen/arch/x86/hvm/svm/svm.h
+++ b/xen/arch/x86/hvm/svm/svm.h
@@ -12,12 +12,8 @@
 #include 
 
 struct cpu_user_regs;
-struct cpuinfo_x86;
 struct vcpu;
 
-void svm_asid_init(const struct cpuinfo_x86 *c);
-void svm_asid_handle_vmrun(void);
-
 unsigned long *svm_msrbit(unsigned long *msr_bitmap, uint32_t msr);
 void __update_guest_eip(struct cpu_user_regs *regs, unsigned int inst_len);
 
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 57d49364db..01372c8ee2 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -760,8 +760,6 @@ static int _vmx_cpu_up(bool bsp)
 
     this_cpu(vmxon) = 1;
 
-    hvm_asid_init(cpu_has_vmx_vpid ? (1u << VMCS_VPID_WIDTH) : 0);
-
     if ( cpu_has_vmx_ept )
         ept_sync_all();
 
@@ -1944,7 +1942,7 @@ void cf_check vmx_do_resume(void)
          */
         v->arch.hvm.vmx.hostenv_migrated = 1;
 
-        hvm_asid_flush_vcpu(v);
+        v->needs_tlb_flush = true;
     }
 
     debug_state = v->domain->debugger_attached
@@ -2157,7 +2155,6 @@ void vmcs_dump_vcpu(struct vcpu *v)
          (SECONDARY_EXEC_ENABLE_VPID | SECONDARY_EXEC_ENABLE_VM_FUNCTIONS) )
         printk("Virtual processor ID = 0x%04x VMfunc controls = %016lx\n",
                vmr16(VIRTUAL_PROCESSOR_ID), vmr(VM_FUNCTION_CONTROL));
-
     vmx_vmcs_exit(v);
 }
 
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index d8879c304e..ed6768135d 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -824,6 +825,18 @@ static void cf_check vmx_cpuid_policy_changed(struct vcpu *v)
         vmx_update_secondary_exec_control(v);
     }
 
+    if ( asid_enabled )
+    {
+        v->arch.hvm.vmx.secondary_exec_control |= SECONDARY_EXEC_ENABLE_VPID;
+        vmx_update_secondary_exec_control(v);
+    }
+    else
+    {
+        v->arch.hvm.vmx.secondary_exec_control &= ~SECONDARY_EXEC_ENABLE_VPID;
+        vmx_update_secondary_exec_control(v);
+    }
+
+
     /*
      * We can safely pass MSR_SPEC_CTRL through to the guest, even if STIBP
      * isn't enumerated in hardware, as SPEC_CTRL_STIBP is ignored.
@@ -1477,7 +1490,7 @@ static void cf_check vmx_handle_cd(struct vcpu *v, unsigned long value)
             vmx_set_msr_intercept(v, MSR_IA32_CR_PAT, VMX_MSR_RW);
 
             wbinvd();               /* flush possibly polluted cache */
-            hvm_asid_flush_vcpu(v); /* invalidate memory type cached in TLB */
+            v->needs_tlb_flush = true; /* invalidate memory type cached in TLB */
             v->arch.hvm.cache_mode = NO_FILL_CACHE_MODE;
         }
         else
@@ -1486,7 +1499,7 @@ static void cf_check vmx_handle_cd(struct vcpu *v, unsigned long value)
             vmx_set_guest_pat(v, *pat);
             if ( !is_iommu_enabled(v->domain) || iommu_snoop )
                 vmx_clear_msr_intercept(v, MSR_IA32_CR_PAT, VMX_MSR_RW);
-            hvm_asid_flush_vcpu(v); /* no need to flush cache */
+            v->needs_tlb_flush = true;
         }
     }
 }
@@ -1847,7 +1860,7 @@ static void cf_check vmx_update_guest_cr(
         __vmwrite(GUEST_CR3, v->arch.hvm.hw_cr[3]);
 
         if ( !(flags & HVM_UPDATE_GUEST_CR3_NOFLUSH) )
-            hvm_asid_flush_vcpu(v);
+            v->needs_tlb_flush = true;
         break;
 
     default:
@@ -3128,6 +3141,8 @@ const struct hvm_function_table * __init start_vmx(void)
     lbr_tsx_fixup_check();
     ler_to_fixup_check();
 
+    BUG_ON(hvm_asid_init(cpu_has_vmx_vpid ? (1u << VMCS_VPID_WIDTH) : 1));
+
     return &vmx_function_table;
 }
 
@@ -4901,9 +4916,7 @@ bool asmlinkage vmx_vmenter_helper(const struct cpu_user_regs *regs)
 {
     struct vcpu *curr = current;
     struct domain *currd = curr->domain;
-    u32 new_asid, old_asid;
-    struct hvm_vcpu_asid *p_asid;
-    bool need_flush;
+    struct hvm_asid *p_asid;
 
     ASSERT(hvmemul_cache_disabled(curr));
 
@@ -4914,38 +4927,14 @@ bool asmlinkage vmx_vmenter_helper(const struct cpu_user_regs *regs)
     if ( curr->domain->arch.hvm.pi_ops.vcpu_block )
         vmx_pi_do_resume(curr);
 
-    if ( !cpu_has_vmx_vpid )
+    if ( !asid_enabled )
         goto out;
     if ( nestedhvm_vcpu_in_guestmode(curr) )
         p_asid = &vcpu_nestedhvm(curr).nv_n2asid;
     else
-        p_asid = &curr->arch.hvm.n1asid;
-
-    old_asid = p_asid->asid;
-    need_flush = hvm_asid_handle_vmenter(p_asid);
-    new_asid = p_asid->asid;
-
-    if ( unlikely(new_asid != old_asid) )
-    {
-        __vmwrite(VIRTUAL_PROCESSOR_ID, new_asid);
-        if ( !old_asid && new_asid )
-        {
-            /* VPID was disabled: now enabled. */
-            curr->arch.hvm.vmx.secondary_exec_control |=
-                SECONDARY_EXEC_ENABLE_VPID;
-            vmx_update_secondary_exec_control(curr);
-        }
-        else if ( old_asid && !new_asid )
-        {
-            /* VPID was enabled: now disabled. */
-            curr->arch.hvm.vmx.secondary_exec_control &=
-                ~SECONDARY_EXEC_ENABLE_VPID;
-            vmx_update_secondary_exec_control(curr);
-        }
-    }
+        p_asid = &currd->arch.hvm.asid;
 
-    if ( unlikely(need_flush) )
-        vpid_sync_all();
+    __vmwrite(VIRTUAL_PROCESSOR_ID, p_asid->asid);
 
     if ( paging_mode_hap(curr->domain) )
     {
@@ -4954,12 +4943,18 @@ bool asmlinkage vmx_vmenter_helper(const struct cpu_user_regs *regs)
         unsigned int inv = 0; /* None => Single => All */
         struct ept_data *single = NULL; /* Single eptp, iff inv == 1 */
 
+        if ( test_and_clear_bool(curr->needs_tlb_flush)  )
+        {
+            inv = 1;
+            single = ept;
+        }
+
         if ( cpumask_test_cpu(cpu, ept->invalidate) )
         {
             cpumask_clear_cpu(cpu, ept->invalidate);
 
             /* Automatically invalidate all contexts if nested. */
-            inv += 1 + nestedhvm_enabled(currd);
+            inv = 1 + nestedhvm_enabled(currd);
             single = ept;
         }
 
@@ -4986,6 +4981,11 @@ bool asmlinkage vmx_vmenter_helper(const struct cpu_user_regs *regs)
             __invept(inv == 1 ? INVEPT_SINGLE_CONTEXT : INVEPT_ALL_CONTEXT,
                      inv == 1 ? single->eptp          : 0);
     }
+    else /* Shadow paging */
+    {
+        /* Always perform a TLB flush */
+        vpid_sync_vcpu_context(curr);
+    }
 
  out:
     if ( unlikely(curr->arch.hvm.vmx.lbr_flags & LBR_FIXUP_MASK) )
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 3c848ef546..13d638a1ea 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -12,6 +12,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1254,7 +1255,7 @@ static void virtual_vmentry(struct cpu_user_regs *regs)
 
         if ( nvmx->guest_vpid != new_vpid )
         {
-            hvm_asid_flush_vcpu_asid(&vcpu_nestedhvm(v).nv_n2asid);
+            v->needs_tlb_flush = true;
             nvmx->guest_vpid = new_vpid;
         }
     }
@@ -2056,7 +2057,7 @@ static int nvmx_handle_invvpid(struct cpu_user_regs *regs)
     case INVVPID_INDIVIDUAL_ADDR:
     case INVVPID_SINGLE_CONTEXT:
     case INVVPID_ALL_CONTEXT:
-        hvm_asid_flush_vcpu_asid(&vcpu_nestedhvm(current).nv_n2asid);
+        hvm_flush_tlb(NULL);
         break;
     default:
         vmfail(regs, VMX_INSN_INVEPT_INVVPID_INVALID_OP);
diff --git a/xen/arch/x86/include/asm/flushtlb.h b/xen/arch/x86/include/asm/flushtlb.h
index cd625f9114..dc7327d051 100644
--- a/xen/arch/x86/include/asm/flushtlb.h
+++ b/xen/arch/x86/include/asm/flushtlb.h
@@ -120,12 +120,6 @@ void switch_cr3_cr4(unsigned long cr3, unsigned long cr4);
 #define FLUSH_VCPU_STATE 0x1000
  /* Flush the per-cpu root page table */
 #define FLUSH_ROOT_PGTBL 0x2000
-#if CONFIG_HVM
- /* Flush all HVM guests linear TLB (using ASID/VPID) */
-#define FLUSH_HVM_ASID_CORE 0x4000
-#else
-#define FLUSH_HVM_ASID_CORE 0
-#endif
 #if defined(CONFIG_PV) || defined(CONFIG_SHADOW_PAGING)
 /*
  * Adding this to the flags passed to flush_area_mask will prevent using the
@@ -185,7 +179,6 @@ void flush_area_mask(const cpumask_t *mask, const void *va,
 
 static inline void flush_page_to_ram(unsigned long mfn, bool sync_icache) {}
 
-unsigned int guest_flush_tlb_flags(const struct domain *d);
 void guest_flush_tlb_mask(const struct domain *d, const cpumask_t *mask);
 
 #endif /* __FLUSHTLB_H__ */
diff --git a/xen/arch/x86/include/asm/hvm/asid.h b/xen/arch/x86/include/asm/hvm/asid.h
index 17c58353d1..d59b3e3ea2 100644
--- a/xen/arch/x86/include/asm/hvm/asid.h
+++ b/xen/arch/x86/include/asm/hvm/asid.h
@@ -8,25 +8,20 @@
 #ifndef __ASM_X86_HVM_ASID_H__
 #define __ASM_X86_HVM_ASID_H__
 
+#include 
+#include 
 
-struct vcpu;
-struct hvm_vcpu_asid;
+struct hvm_asid {
+    uint32_t asid;
+};
 
-/* Initialise ASID management for the current physical CPU. */
-void hvm_asid_init(int nasids);
+extern bool asid_enabled;
 
-/* Invalidate a particular ASID allocation: forces re-allocation. */
-void hvm_asid_flush_vcpu_asid(struct hvm_vcpu_asid *asid);
+/* Initialise ASID management distributed across all CPUs. */
+int hvm_asid_init(unsigned long nasids);
 
-/* Invalidate all ASID allocations for specified VCPU: forces re-allocation. */
-void hvm_asid_flush_vcpu(struct vcpu *v);
-
-/* Flush all ASIDs on this processor core. */
-void hvm_asid_flush_core(void);
-
-/* Called before entry to guest context. Checks ASID allocation, returns a
- * boolean indicating whether all ASIDs must be flushed. */
-bool hvm_asid_handle_vmenter(struct hvm_vcpu_asid *asid);
+int hvm_asid_alloc(struct hvm_asid *asid);
+void hvm_asid_free(struct hvm_asid *asid);
 
 #endif /* __ASM_X86_HVM_ASID_H__ */
 
diff --git a/xen/arch/x86/include/asm/hvm/domain.h b/xen/arch/x86/include/asm/hvm/domain.h
index 333501d5f2..80adc93b91 100644
--- a/xen/arch/x86/include/asm/hvm/domain.h
+++ b/xen/arch/x86/include/asm/hvm/domain.h
@@ -140,6 +140,7 @@ struct hvm_domain {
     } write_map;
 
     struct hvm_pi_ops pi_ops;
+    struct hvm_asid asid;
 
     union {
         struct vmx_domain vmx;
diff --git a/xen/arch/x86/include/asm/hvm/hvm.h b/xen/arch/x86/include/asm/hvm/hvm.h
index bf8bc2e100..7af111cb39 100644
--- a/xen/arch/x86/include/asm/hvm/hvm.h
+++ b/xen/arch/x86/include/asm/hvm/hvm.h
@@ -268,6 +268,8 @@ int hvm_domain_initialise(struct domain *d,
 void hvm_domain_relinquish_resources(struct domain *d);
 void hvm_domain_destroy(struct domain *d);
 
+int hvm_flush_tlb(const unsigned long *vcpu_bitmap);
+
 int hvm_vcpu_initialise(struct vcpu *v);
 void hvm_vcpu_destroy(struct vcpu *v);
 void hvm_vcpu_down(struct vcpu *v);
@@ -483,17 +485,6 @@ static inline void hvm_set_tsc_offset(struct vcpu *v, uint64_t offset,
     alternative_vcall(hvm_funcs.set_tsc_offset, v, offset, at_tsc);
 }
 
-/*
- * Called to ensure than all guest-specific mappings in a tagged TLB are 
- * flushed; does *not* flush Xen's TLB entries, and on processors without a 
- * tagged TLB it will be a noop.
- */
-static inline void hvm_flush_guest_tlbs(void)
-{
-    if ( hvm_enabled )
-        hvm_asid_flush_core();
-}
-
 static inline unsigned int
 hvm_get_cpl(struct vcpu *v)
 {
@@ -881,8 +872,6 @@ static inline int hvm_cpu_up(void)
 
 static inline void hvm_cpu_down(void) {}
 
-static inline void hvm_flush_guest_tlbs(void) {}
-
 static inline void hvm_invlpg(const struct vcpu *v, unsigned long linear)
 {
     ASSERT_UNREACHABLE();
diff --git a/xen/arch/x86/include/asm/hvm/svm/svm.h b/xen/arch/x86/include/asm/hvm/svm/svm.h
index 4eeeb25da9..a610ebbb17 100644
--- a/xen/arch/x86/include/asm/hvm/svm/svm.h
+++ b/xen/arch/x86/include/asm/hvm/svm/svm.h
@@ -9,6 +9,11 @@
 #ifndef __ASM_X86_HVM_SVM_H__
 #define __ASM_X86_HVM_SVM_H__
 
+void svm_asid_init(void);
+void svm_vcpu_assign_asid(struct vcpu *v);
+void svm_vcpu_set_tlb_control(struct vcpu *v);
+void svm_vcpu_clear_tlb_control(struct vcpu *v);
+
 /*
  * PV context switch helpers.  Prefetching the VMCB area itself has been shown
  * to be useful for performance.
diff --git a/xen/arch/x86/include/asm/hvm/vcpu.h b/xen/arch/x86/include/asm/hvm/vcpu.h
index 196fed6d5d..960bea6734 100644
--- a/xen/arch/x86/include/asm/hvm/vcpu.h
+++ b/xen/arch/x86/include/asm/hvm/vcpu.h
@@ -9,6 +9,7 @@
 #define __ASM_X86_HVM_VCPU_H__
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -17,11 +18,6 @@
 #include 
 #include 
 
-struct hvm_vcpu_asid {
-    uint64_t generation;
-    uint32_t asid;
-};
-
 struct hvm_vcpu_io {
     /*
      * HVM emulation:
@@ -79,7 +75,7 @@ struct nestedvcpu {
     bool stale_np2m; /* True when p2m_base in VMCx02 is no longer valid */
     uint64_t np2m_generation;
 
-    struct hvm_vcpu_asid nv_n2asid;
+    struct hvm_asid nv_n2asid;
 
     bool nv_vmentry_pending;
     bool nv_vmexit_pending;
@@ -141,8 +137,6 @@ struct hvm_vcpu {
     /* (MFN) hypervisor page table */
     pagetable_t         monitor_table;
 
-    struct hvm_vcpu_asid n1asid;
-
     u64                 msr_tsc_adjust;
 
     union {
diff --git a/xen/arch/x86/include/asm/hvm/vmx/vmx.h b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
index 173311bfbb..2938cc245f 100644
--- a/xen/arch/x86/include/asm/hvm/vmx/vmx.h
+++ b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
@@ -462,7 +462,7 @@ static inline void vpid_sync_vcpu_context(struct vcpu *v)
     else
         type = INVVPID_ALL_CONTEXT;
 
-    __invvpid(type, v->arch.hvm.n1asid.asid, 0);
+    __invvpid(type, v->domain->arch.hvm.asid.asid, 0);
 }
 
 static inline void vpid_sync_vcpu_gva(struct vcpu *v, unsigned long gva)
@@ -477,7 +477,7 @@ static inline void vpid_sync_vcpu_gva(struct vcpu *v, unsigned long gva)
     else
         type = INVVPID_ALL_CONTEXT;
 
-    __invvpid(type, v->arch.hvm.n1asid.asid, (u64)gva);
+    __invvpid(type, v->domain->arch.hvm.asid.asid, (u64)gva);
 }
 
 static inline void vpid_sync_all(void)
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index ec5043a8aa..b1d7afee1d 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -739,7 +739,7 @@ static bool cf_check flush_tlb(const unsigned long *vcpu_bitmap)
         if ( !flush_vcpu(v, vcpu_bitmap) )
             continue;
 
-        hvm_asid_flush_vcpu(v);
+        v->needs_tlb_flush = true;
 
         cpu = read_atomic(&v->dirty_cpu);
         if ( cpu != this_cpu && is_vcpu_dirty_cpu(cpu) && v->is_running )
@@ -748,9 +748,7 @@ static bool cf_check flush_tlb(const unsigned long *vcpu_bitmap)
 
     /*
      * Trigger a vmexit on all pCPUs with dirty vCPU state in order to force an
-     * ASID/VPID change and hence accomplish a guest TLB flush. Note that vCPUs
-     * not currently running will already be flushed when scheduled because of
-     * the ASID tickle done in the loop above.
+     * ASID/VPID flush and hence accomplish a guest TLB flush.
      */
     on_selected_cpus(mask, NULL, NULL, 0);
 
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index b9a7c2dc53..857968ea0d 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1416,7 +1417,7 @@ p2m_flush(struct vcpu *v, struct p2m_domain *p2m)
     ASSERT(v->domain == p2m->domain);
     vcpu_nestedhvm(v).nv_p2m = NULL;
     p2m_flush_table(p2m);
-    hvm_asid_flush_vcpu(v);
+    v->needs_tlb_flush = true;
 }
 
 void
@@ -1475,7 +1476,7 @@ static void assign_np2m(struct vcpu *v, struct p2m_domain *p2m)
 
 static void nvcpu_flush(struct vcpu *v)
 {
-    hvm_asid_flush_vcpu(v);
+    v->needs_tlb_flush = true;
     vcpu_nestedhvm(v).stale_np2m = true;
 }
 
@@ -1595,7 +1596,7 @@ void np2m_schedule(int dir)
             if ( !np2m_valid )
             {
                 /* This vCPU's np2m was flushed while it was not runnable */
-                hvm_asid_flush_core();
+                curr->needs_tlb_flush = true;
                 vcpu_nestedhvm(curr).nv_p2m = NULL;
             }
             else
diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
index c77f4c1dac..26b6ce9e9b 100644
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -964,7 +964,7 @@ void paging_update_nestedmode(struct vcpu *v)
     else
         /* TODO: shadow-on-shadow */
         v->arch.paging.nestedmode = NULL;
-    hvm_asid_flush_vcpu(v);
+    v->needs_tlb_flush = true;
 }
 
 int __init paging_set_allocation(struct domain *d, unsigned int pages,
diff --git a/xen/arch/x86/mm/shadow/hvm.c b/xen/arch/x86/mm/shadow/hvm.c
index 114957a3e1..f98591f976 100644
--- a/xen/arch/x86/mm/shadow/hvm.c
+++ b/xen/arch/x86/mm/shadow/hvm.c
@@ -737,6 +737,7 @@ bool cf_check shadow_flush_tlb(const unsigned long *vcpu_bitmap)
             continue;
 
         paging_update_cr3(v, false);
+        v->needs_tlb_flush = true;
 
         cpu = read_atomic(&v->dirty_cpu);
         if ( is_vcpu_dirty_cpu(cpu) )
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 7be9c180ec..b55f4bca08 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -79,12 +79,6 @@ const char *const fetch_type_names[] = {
 # define for_each_shadow_table(v, i) for ( (i) = 0; (i) < 1; ++(i) )
 #endif
 
-/* Helper to perform a local TLB flush. */
-static void sh_flush_local(const struct domain *d)
-{
-    flush_local(guest_flush_tlb_flags(d));
-}
-
 #if GUEST_PAGING_LEVELS >= 4 && defined(CONFIG_PV32)
 #define ASSERT_VALID_L2(t) \
     ASSERT((t) == SH_type_l2_shadow || (t) == SH_type_l2h_shadow)
@@ -2926,7 +2920,8 @@ static bool cf_check sh_invlpg(struct vcpu *v, unsigned long linear)
     if ( mfn_to_page(sl1mfn)->u.sh.type
          == SH_type_fl1_shadow )
     {
-        sh_flush_local(v->domain);
+        v->needs_tlb_flush = true;
+        flush_tlb_local();
         return false;
     }
 
@@ -3143,7 +3138,8 @@ sh_update_linear_entries(struct vcpu *v)
      * linear pagetable to read a top-level shadow page table entry. But,
      * without this change, it would fetch the wrong value due to a stale TLB.
      */
-    sh_flush_local(d);
+    v->needs_tlb_flush = true;
+    flush_tlb_local();
 }
 
 static pagetable_t cf_check sh_update_cr3(struct vcpu *v, bool noflush)
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index fe53d4fab7..55b0561988 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -228,6 +228,8 @@ struct vcpu
     bool             defer_shutdown;
     /* VCPU is paused following shutdown request (d->is_shutting_down)? */
     bool             paused_for_shutdown;
+    /* VCPU needs its TLB flushed before waking. */
+    bool             needs_tlb_flush;
     /* VCPU need affinity restored */
     uint8_t          affinity_broken;
 #define VCPU_AFFINITY_OVERRIDE    0x01
-- 
2.50.0



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Thu Jun 26 14:09:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 14:09:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026497.1401683 (Exim 4.92)
	(envelope-from )
	id 1uUnIU-0002xb-Kg; Thu, 26 Jun 2025 14:09:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026497.1401683; Thu, 26 Jun 2025 14: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 1uUnIU-0002xU-Gw; Thu, 26 Jun 2025 14:09:50 +0000
Received: by outflank-mailman (input) for mailman id 1026497;
 Thu, 26 Jun 2025 14:09: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 1uUnIS-0002x5-SK
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 14:09:48 +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 34a368f2-5297-11f0-a30f-13f23c93f187;
 Thu, 26 Jun 2025 16:09:42 +0200 (CEST)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-453647147c6so11559925e9.2
 for ; Thu, 26 Jun 2025 07:09:42 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a6e810617bsm7551014f8f.75.2025.06.26.07.09.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 26 Jun 2025 07:09:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 34a368f2-5297-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750946982; x=1751551782; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=tE1a4NOYjLD3i/3qY8e3f+0xzk2jNBxfIW/7EnTcPKc=;
        b=DGpFlmwoklBsNEigjojTLYdMtUf8I3Yh9juIovkEPLT/a1fFzNEc6NzjvTw27LauzM
         1+zWdTP7rT8Q+naj5Otzq6f4NIIqYujlSE4n9WXohcMvnBh13f/C3l9IaC2PJFQ7l0DD
         m7u0vSStezYxsiBVBzQh98fSAT0VJfvUUsu9I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750946982; x=1751551782;
        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=tE1a4NOYjLD3i/3qY8e3f+0xzk2jNBxfIW/7EnTcPKc=;
        b=LyCSPSiRD4t4EB6Xpi3+5L/6KeCsWqIOexrhxGfyEMiLxEMMjI+1lSlSFCScIKbp6E
         ozvI4oweYNxHKnBtlb2JOWciodNTgPICO+pqtmPZQg6vnq3TIS8xo+W7KAgRHVY54biV
         95kNRDxK316CG7EvYf7oDyVZx6vU2870RfMid9acbzt9akfeLD4ccKI0pgyu9uEK6Jmc
         8BNFvNLT/dWu8IL1xfZvni343h7xAQSqyjL34vcTcS4XysTmRww3ujsEGX/2qYt4TOm0
         iliiofh/bvv5/mIw5Z52a+1sN1C5ZM2p336NehMtgoheHCBh8I6qHBclUxqsMhzO/Gor
         XfWQ==
X-Forwarded-Encrypted: i=1; AJvYcCXogembNSt5CRvVsCnfkKdcxuUtAH1xbYfqWxceNBIRGaCwn3jd438WEJ/70xq2uIypBBxJjByZuIg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzAVj8XSNTWbpX+zcqLvsTO76Ye81Q1iLvfUMnW3HwlofgIBuIW
	TuUDMSusgkaRWy8sZgBN/YN0PrFnWHejpCn8vpHOwAkjQSqrywKwFjgihda3j0Vfk/c=
X-Gm-Gg: ASbGncuAP3VTfA7iWo42EfLZx0supMp4b4u/3iHfGiGNrRxvR5KkhtHOOhlgTUGVVMS
	Bv1M9LqLfiDvAqie3MV/q7FtdpqJ3m91sadZ+0nnDUU4j1vPXD/aGq1xY0RaS1h/cAgSzKjnzdr
	mqPThutgs1MpGIhZyPC0G+GCCy/JB04SEaLM/hxXDhbI012vukEzbYsMb8p+U8Ix/uawB1OpWgm
	g4a2gmJ4su4cZYsynr0rW7uEfbO+luinLQI14jlkJB9HbyLy77udwB/yrJuBIqZ74+fnGB1H1WI
	nCiamQbGFgE2JSEFM2XtkkdUrzKzhmohwtXxGvRt4DegtZZC62svPouaY0RpYmz/elvqxFO+wSM
	P924CEQMtz/isN6YpioAXE213Sws=
X-Google-Smtp-Source: AGHT+IEXBdH7hOKCYchLvLuyRxWERSggcVeU0ucQiOEho39r1QroFT39P8ZPoOlum4WPte4UN4GaYg==
X-Received: by 2002:a05:600c:3495:b0:44b:eb56:1d45 with SMTP id 5b1f17b1804b1-4538c404805mr22605405e9.15.1750946979761;
        Thu, 26 Jun 2025 07:09:39 -0700 (PDT)
Message-ID: 
Date: Thu, 26 Jun 2025 15:09:38 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: preparations for 4.20.1
To: Jan Beulich ,
 "xen-devel@lists.xenproject.org" 
Cc: Stefano Stabellini , Julien Grall
 , Anthony PERARD ,
 "community.manager@xenproject.org" 
References: <24bc698d-4e60-4f34-9b8b-8b1f315655f1@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: <24bc698d-4e60-4f34-9b8b-8b1f315655f1@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 26/06/2025 7:41 am, Jan Beulich wrote:
> All,
>
> the release is due in about a week or two. Please point out backports you find
> missing from the respective staging branch, but which you consider relevant.

de6a05a8a0d5 and 1ff7f87e8f4f?  They're the tools side of the px/cx changes.

4c3ce492ede1 is another one although I guess you've excluded that one on
the grounds of being an ABI change (albeit minor)?

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 14:24:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 14:24:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026511.1401693 (Exim 4.92)
	(envelope-from )
	id 1uUnWm-0006Ic-S9; Thu, 26 Jun 2025 14:24:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026511.1401693; Thu, 26 Jun 2025 14:24:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUnWm-0006IV-ND; Thu, 26 Jun 2025 14:24:36 +0000
Received: by outflank-mailman (input) for mailman id 1026511;
 Thu, 26 Jun 2025 14:24: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 1uUnWl-0006IP-W3
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 14:24:36 +0000
Received: from mail-oo1-xc2d.google.com (mail-oo1-xc2d.google.com
 [2607:f8b0:4864:20::c2d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 45b9422d-5299-11f0-b894-0df219b8e170;
 Thu, 26 Jun 2025 16:24:30 +0200 (CEST)
Received: by mail-oo1-xc2d.google.com with SMTP id
 006d021491bc7-60d63174f05so251243eaf.0
 for ; Thu, 26 Jun 2025 07:24:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 45b9422d-5299-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750947869; x=1751552669; 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=vQH72RUtOOhXFPvQiawnRTqKjOYJTKUJ1G1pl4DuuII=;
        b=Rb72afwIxtxqaNIs4JrZlX66mXYgNQXAUXAsfIdZNu6Bxyg32sOy93MtZpN3woHAeh
         bamBwS+i/hm9XDBf6MDlZWYstAMR+zg+Zh6NViPIkui23Lb55WJp2fX7+Rr2UvyiZmyX
         3GbJna/0ALcoWUxlQepE5p4k4rO6uIxHPji/4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750947869; x=1751552669;
        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=vQH72RUtOOhXFPvQiawnRTqKjOYJTKUJ1G1pl4DuuII=;
        b=DT3lK9+gbTLeFFUy2HLvbaRZ1xGQKhLeO7DR5GUpCIwftRUKL0d1jC6LbScn91QYzp
         hb75LVw4kBpF0l6jjuH1gNhqnwtkMkTVR9i1zBqMxoLF0r4k2G+Nu7gVkEbKMvoLKxTg
         tIB0g+KQUdlMohoWugkg2ap0sDbK+ZCfhg02JbWNr+z6jACJG8TsB1NVi7ucvpmkt/1x
         hevxTbuZyhV9RslU6vujEQF4+k8fqXw8fQzwQNzPCngOzx9qL6dP80q2iNwoUm6yIdvq
         nnhStaEtATmM/DENrWyUYQm7i6UZ4QOizrnsInURCrdydNTy/kgghdogC9PjOFGxUW7G
         ZtHQ==
X-Forwarded-Encrypted: i=1; AJvYcCV9QLWOGP6Gl0nF9/Kgzj0gq5X6B3aBckTH5y+5HZ22F2paX56S4/YaZ6+0yzLNKtgzinOjvbARbOk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyfnWtFJXMff4GdBpAiNrkElw2vO+yCIHOt7kyyzGisERD6+D2L
	MH6/+b3Al9cuTqHqEo0rfi0lcjKR0HA3xT+OgNXTjdVSFO/Ep9nT8oyt2XB5YhOCataPhgUI0OB
	aCPyYWGvojXRTIOHPuze+ApS7q01DkdrC+omzapLAmw==
X-Gm-Gg: ASbGncvgrg+MiSO8PwMTuQGZuKEGbzAWkvrRpn6l3gRn2JE73ufVtXDXclZAyzAoWYO
	Ng/3LPm3GPlL8DbFnoqAhCjh9Jbe+c4v7FJqLk8fLutuoZchLQmb8akFDTfIitr5FpcMsN4HXMI
	kO9wlkQyEnQV6noAkiyq6QhrSaPKLecPRcQrX/6JNI
X-Google-Smtp-Source: AGHT+IHPZBxGUyJeGShC9o2zvi7OikHtAIO2kA7RlChNOvlssMZ/uI2boKa0jSltydFTuRFhHpjwYEtqU7ensS314rU=
X-Received: by 2002:a05:6871:6186:b0:2ea:70ad:4517 with SMTP id
 586e51a60fabf-2efb26d256cmr4843673fac.15.1750947869383; Thu, 26 Jun 2025
 07:24:29 -0700 (PDT)
MIME-Version: 1.0
References: <20250625073408.7496-1-frediano.ziglio@cloud.com>
 <20250625073408.7496-3-frediano.ziglio@cloud.com> 
In-Reply-To: 
From: Frediano Ziglio 
Date: Thu, 26 Jun 2025 15:24:17 +0100
X-Gm-Features: Ac12FXw7akKnmee6VdAe-D1aln_rIFIj6MnU4h0Q5RoQd80HYnxd8EXE08bIr44
Message-ID: 
Subject: Re: [PATCH v3 2/3] xen/efi: Support loading initrd using GRUB2
 LoadFile2 protocol
To: Jan Beulich 
Cc: "Daniel P. Smith" , 
	=?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= , 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 26, 2025 at 2:29=E2=80=AFPM Jan Beulich  wro=
te:
>
> On 25.06.2025 09:34, Frediano Ziglio wrote:
> > --- a/xen/common/efi/boot.c
> > +++ b/xen/common/efi/boot.c
> > @@ -850,6 +850,74 @@ static bool __init read_file(EFI_FILE_HANDLE dir_h=
andle, CHAR16 *name,
> >      return true;
> >  }
> >
> > +#pragma pack(1)
> > +typedef struct {
> > +    VENDOR_DEVICE_PATH              VenMediaNode;
> > +    EFI_DEVICE_PATH                 EndNode;
> > +} SINGLE_NODE_VENDOR_MEDIA_DEVPATH;
> > +#pragma pack()
>
> Where is this coming from? And why is this declared locally here, but the=
 ...
>

The declaration comes from e2dk code and it's similar to code in Linux.
It's not a generic declaration so it's not in a header.

> > +static bool __init initrd_load_file2(const CHAR16 *name, struct file *=
file)
> > +{
> > +    static const SINGLE_NODE_VENDOR_MEDIA_DEVPATH __initconst initrd_d=
ev_path =3D {
> > +        {
> > +            {
> > +                MEDIA_DEVICE_PATH, MEDIA_VENDOR_DP, { sizeof (VENDOR_D=
EVICE_PATH) }
> > +            },
> > +            LINUX_EFI_INITRD_MEDIA_GUID
> > +        },
> > +        {
> > +            END_DEVICE_PATH_TYPE, END_ENTIRE_DEVICE_PATH_SUBTYPE,
> > +            { sizeof (EFI_DEVICE_PATH) }
> > +        }
> > +    };
> > +    static EFI_GUID __initdata lf2_proto_guid =3D EFI_LOAD_FILE2_PROTO=
COL_GUID;
>
> ... corresponding GUID is put in a (random?) header file?
>

The GUID is declared in the header for device paths, being a GUID for
a device path.

> > +    EFI_DEVICE_PATH *dp;
> > +    EFI_LOAD_FILE2_PROTOCOL *lf2;
> > +    EFI_HANDLE handle;
> > +    EFI_STATUS ret;
> > +    UINTN size;
> > +
> > +    dp =3D (EFI_DEVICE_PATH *)&initrd_dev_path;
>
> Instead of a (fragile) cast, why not
>
>     dp =3D &initrd_dev_path->VenMediaNode.Header;
>

It makes sense, although at the end it's just style. Code came from
Linux in this case.

> ? And then perhaps also as initializer of the variable?
>
> > +    ret =3D efi_bs->LocateDevicePath(&lf2_proto_guid, &dp, &handle);
> > +    if ( EFI_ERROR(ret) )
> > +    {
> > +        if ( ret =3D=3D EFI_NOT_FOUND)
> > +            return false;
> > +        PrintErrMesg(L"Error getting file with LoadFile2 interface", r=
et);
> > +    }
> > +
> > +    ret =3D efi_bs->HandleProtocol(handle, &lf2_proto_guid, (void **)&=
lf2);
> > +    if ( EFI_ERROR(ret) )
> > +        PrintErrMesg(L"LoadFile2 file does not provide correct protoco=
l", ret);
> > +
> > +    size =3D 0;
> > +    ret =3D lf2->LoadFile(lf2, dp, false, &size, NULL);
> > +    if ( ret !=3D EFI_BUFFER_TOO_SMALL )
> > +        PrintErrMesg(L"Loading failed", ret);
>
> Here it's particularly bad, but throughout: How would one know in what
> context the failure was? Wouldn't you want to include "name" in the
> output? read_file() does include this detail.
>

It makes sense

> > +    file->addr =3D min(1UL << (32 + PAGE_SHIFT),
> > +                     HYPERVISOR_VIRT_END - DIRECTMAP_VIRT_START);
>
> I understand you took this from read_file(), but the construct looks
> outdated. For one, it should have been abstracted away when the Arm64
> work was done (I don't think such a restriction exists there), and
> then I'm also not sure the restriction would unconditionally apply on
> x86 anymore.
>

Do you have an updated/correct formula?

> > +    ret =3D efi_bs->AllocatePages(AllocateMaxAddress, EfiLoaderData,
> > +                                PFN_UP(size), &file->addr);
> > +    if ( EFI_ERROR(ret) )
> > +        PrintErrMesg(L"Allocation failed", ret);
> > +
> > +    file->need_to_free =3D true;
> > +    file->size =3D size;
> > +
> > +    ret =3D lf2->LoadFile(lf2, dp, false, &size, file->str);
> > +    if ( EFI_ERROR(ret) )
> > +    {
> > +        efi_bs->FreePages(file->addr, PFN_UP(size));
> > +        PrintErrMesg(L"Loading failed", ret);
> > +    }
> > +
> > +    efi_arch_handle_module(file, name, NULL);
>
> Shouldn't it be handle_file_info() that you call, and a little earlier?
>

Already changed in the last series.
Earlier where? You want it after loading data, right ?

> > --- a/xen/include/efi/efidevp.h
> > +++ b/xen/include/efi/efidevp.h
> > @@ -398,5 +398,26 @@ typedef union {
> >
> >  } EFI_DEV_PATH_PTR;
> >
> > +#define EFI_LOAD_FILE2_PROTOCOL_GUID \
> > +    { 0x4006c0c1, 0xfcb3, 0x403e, {0x99, 0x6d, 0x4a, 0x6c, 0x87, 0x24,=
 0xe0, 0x6d } }
> > +
> > +typedef struct EFI_LOAD_FILE2_PROTOCOL EFI_LOAD_FILE2_PROTOCOL;
> > +
> > +typedef
> > +EFI_STATUS
> > +(EFIAPI *EFI_LOAD_FILE2)(
> > +    IN EFI_LOAD_FILE2_PROTOCOL      *This,
> > +    IN EFI_DEVICE_PATH              *FilePath,
> > +    IN BOOLEAN                      BootPolicy,
> > +    IN OUT UINTN                    *BufferSize,
> > +    IN VOID                         *Buffer OPTIONAL
> > +    );
> > +
> > +struct EFI_LOAD_FILE2_PROTOCOL {
> > +    EFI_LOAD_FILE2                  LoadFile;
> > +};
> > +
> > +#define LINUX_EFI_INITRD_MEDIA_GUID \
> > +    { 0x5568e427, 0x68fc, 0x4f3d, {0xac, 0x74, 0xca, 0x55, 0x52, 0x31,=
 0xcc, 0x68} }
> >
> >  #endif
>
> While I'm not maintainer of this code anymore, I hope the new maintainers=
 will
> still respect the original idea of keeping these headers in sync with the=
ir
> origin. The way it's arranged, this change doesn't look like it would hav=
e been
> taken from the gnu-efi package (albeit I will admit I didn't go check).
>

I'll have a look at gnu-efi headers.
Note that the media GUID is GRUB/Linux specific so probably won't be in gnu=
-efi.

> Jan

Frediano


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 14:33:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 14:33:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026546.1401702 (Exim 4.92)
	(envelope-from )
	id 1uUnf3-0008BU-KV; Thu, 26 Jun 2025 14:33:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026546.1401702; Thu, 26 Jun 2025 14:33: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 1uUnf3-0008BN-Gg; Thu, 26 Jun 2025 14:33:09 +0000
Received: by outflank-mailman (input) for mailman id 1026546;
 Thu, 26 Jun 2025 14:33: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 1uUnf2-0008BH-AO
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 14:33:08 +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 79a1bfe4-529a-11f0-a30f-13f23c93f187;
 Thu, 26 Jun 2025 16:33:06 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a522224582so511420f8f.3
 for ; Thu, 26 Jun 2025 07:33:06 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d86d1b2asm158553875ad.204.2025.06.26.07.33.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 26 Jun 2025 07:33:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 79a1bfe4-529a-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750948386; x=1751553186; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=iFYV4k6nw6c52VgE2QZRx0IjCdqJ9JCqbzasiOOzfbI=;
        b=VR3Z/3pR0tcFHIpcxJEWkZyV4STEURhNQxCxtrXb4+e7E7H14zovR1PH86vvJ6R85z
         zuo+ttjColxBKkLzTEIVRjtdrytck/8U1croB+SL3V0pHFUqFZsRz97xMHotmzqisBf5
         M7y+UuexwcHWRsrE01hnkXKziP69VLybLR7NIEi1Fy+71vckaotf6qoq2abC8o62xWc3
         yQlmV+MYm6xE2P8NhhUWHJlOTtp28N1wGBIJ/0EGsf6Vdr1y/6zsK7hAcl+FjCLiKVD4
         KSoX2mDkedzljZPKiXMzCPLYB1yPhjI9tVbdFda9JuHZyPmP08uRwbVi7EMBmVb39Zcn
         sUGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750948386; x=1751553186;
        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=iFYV4k6nw6c52VgE2QZRx0IjCdqJ9JCqbzasiOOzfbI=;
        b=ExjVQogx1/7Q0IvW5GNniVXqsF54EdQ1Jsf8TfDTlpInIaDfFCrNrlgcLmeVZ2CO7g
         jsFor+Yg5OtNWYCiwJxOYyPhCga09iaqIkS1WtY3y86uiJIqBaCrAy0aXPZyMMZjHIgG
         eae91GT0P7Jwgo/kOqmuAyUY6IfwFS3uj1pS5nN9oFoyyq+1p6vK8N7u8gaO4/rKvEhi
         mmusvhOn1e3u96R6Efp7iyQxnKWMlBoPNBHezfwn9eJpVEqYMDynqw2uF8zg/tQX3Ksr
         a2H0g1yJNkjct0g/8ISYOwRMldXPNtzUKcrVJX4iK7TomzKwGnTYC9IHI/EfWzItjcYm
         GEbw==
X-Forwarded-Encrypted: i=1; AJvYcCUYcBtT/kEFmB5CMQUaEDTj0sE+AXFhBD8hK3/unvnylBKvnLgGNFcEnsJW1KnNjOdw7fIn8wzjdh0=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy+XKn7+Rd4z8ykv5VOdWXWpT2x/vOwuho6E5bd5M9gKYV0Kn+0
	NjFphHef8+bEOxPZm7Tgtac0OLvy1G/5DF1sCGIp4MpDq3hRcWwabFK//bGPYNe2Qg==
X-Gm-Gg: ASbGnctcdTV6RPZue5Wvi6QeWHWiZ0zEjpcm2pbtnGbY5vyrqYbYfboW+6ciPpSqGZq
	hHh/q5cHZb1Obx8prF5g1fUpBHmilE534vCMJlfvENnqmgaGv9vEoBRG9xp2kfblBUXCGBGwmFi
	YlRKKDcq0mGpR6k2tBKQX48emMJ5htQblzVs/CR4DC6t3c6/mIFjtffVo3M9yQur9Si9uHqBScB
	zr4NeuOpii6ILZUSfU0ScGXj6ygMd4wPeE7CMcIQUnm/KBJmVJPE6/5foxx1AfM2VXcElzyQ+h5
	95McLI2TfmcYTwcl2XlOU5CjKpaG3npJH1TiYZWu/UDRRK3D/ldJKEjtOrtQUtoyGHCFmQ3puuC
	R1IOH6Essmsnsp6tzlI7XB9yL75uQ8KLWm+3I12zp4Q3YTYs=
X-Google-Smtp-Source: AGHT+IFiG6Nyna/CFxeprhlHAapGVLUybMEDot+r2T3nA54J/AudALV7qYdfHKVM/C5Nhl6k0RZUjg==
X-Received: by 2002:a05:6000:270b:b0:3a4:ee40:6c85 with SMTP id ffacd0b85a97d-3a6f30adb13mr2558294f8f.54.1750948386242;
        Thu, 26 Jun 2025 07:33:06 -0700 (PDT)
Message-ID: 
Date: Thu, 26 Jun 2025 16:32:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: preparations for 4.20.1
To: Andrew Cooper 
Cc: Stefano Stabellini , Julien Grall
 , Anthony PERARD ,
 "community.manager@xenproject.org" ,
 "xen-devel@lists.xenproject.org" 
References: <24bc698d-4e60-4f34-9b8b-8b1f315655f1@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 26.06.2025 16:09, Andrew Cooper wrote:
> On 26/06/2025 7:41 am, Jan Beulich wrote:
>> the release is due in about a week or two. Please point out backports you find
>> missing from the respective staging branch, but which you consider relevant.
> 
> de6a05a8a0d5 and 1ff7f87e8f4f?  They're the tools side of the px/cx changes.

Hmm, I can pull them in, but not the least the lack of Fixes: tags made me
not consider them for backport. (Plus I would really like to hand off tools
side backports again.)

> 4c3ce492ede1 is another one although I guess you've excluded that one on
> the grounds of being an ABI change (albeit minor)?

The interface version bump in particular is something I consider non-
backportable in principle. If we really wanted to, we could apparently
bump it again in staging, and backport the bump that's in the patch you
point at. Since there was no bump between 4.17 and 4.21, that might
even work for the 4.19 branch, but we'd be in uncertain territory then.

IOW - I'd prefer to leave that one out.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 14:41:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 14:41:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026552.1401712 (Exim 4.92)
	(envelope-from )
	id 1uUnnF-0001W2-Bg; Thu, 26 Jun 2025 14:41:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026552.1401712; Thu, 26 Jun 2025 14:41: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 1uUnnF-0001Vv-80; Thu, 26 Jun 2025 14:41:37 +0000
Received: by outflank-mailman (input) for mailman id 1026552;
 Thu, 26 Jun 2025 14:41: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 1uUnnD-0001Vp-Mz
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 14:41:35 +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 a8122fca-529b-11f0-a30f-13f23c93f187;
 Thu, 26 Jun 2025 16:41:34 +0200 (CEST)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3a52874d593so869402f8f.0
 for ; Thu, 26 Jun 2025 07:41:34 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-315f539e6aasm4548917a91.15.2025.06.26.07.41.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 26 Jun 2025 07:41:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a8122fca-529b-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750948894; x=1751553694; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=w6PRCiGWEvs/8aVW1mwFAFqKTo0UWkXGFOGwvC0cNw8=;
        b=Eyogs75dyGt/fPvdp33N68iQ8iqHqO/FxeqlQHDwSe4UQAQaA/XDy+t4uBuQAbl58x
         bRadcaf3WmBtrzZTESfaLvbJBJ0vBFNZy0mRyndZ2LR+Le+ubELDLKYx5iza74W65/IJ
         Uf0TEjDCxh4xK49V1mA28YWzj4263ylUGVW5E5I5zKkDLEhDM0eBw9JA21wilVe3UExO
         74BMUXlIB284EydILGKQnISLiF3vBKyxso/9HtXn4jnNNn6B6n7MHZWBjcQsqF2Px6Hk
         lAtqSaTsDF7WXFfzlyjAl6AnxnWOyJ5/9D3HPee//6wzAZv6pJyWg33p71HYp2KJq+RP
         k/7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750948894; x=1751553694;
        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=w6PRCiGWEvs/8aVW1mwFAFqKTo0UWkXGFOGwvC0cNw8=;
        b=vNZwPzlOtcHUZEdIjg9v5r1klpw+Df8Om8J3VY5p1KVoZ2eEv9Co4wvhTg/SGY0DHX
         KkypsBZ2g8eaWGkCnDw7YJG4kc4wIHeSfnxs6f0T3cwfSAu0Dv+ED9BF+rHlDIQEl37n
         7KRd19NXkGMCeTQpVUIBxxPYZxdcz3GdN8U3Xc3gc0ENbfZpB1xX8g6sA+UIM8O/8Wrt
         D9Yrz2IcGThEQycxFlQg14lz6XBPmVirag4OEoJhxu3DYv86jaFWoA4bIvi8sQy8KeQK
         LSIf4C5QatPguDoiDzI2B5PmGkR9N2WpMyh2d9p/8ztPFQR6ykYN2VFJ1uB5OTAjjRc5
         0PMg==
X-Gm-Message-State: AOJu0YyO66FIBiCLXbTtgFUpkoUKcj3jrx/+uW4mkU45ep0yhoTsw3s4
	wxd8x3i3xBMU/v1GSdsadlFqID7csQeSndhgGZbkaqu91ISD2z3dq7RqzEYDMUUi7g==
X-Gm-Gg: ASbGnctRheqoDiQNowejAY6BnP4QlO2jeFckKOMmByGl+NwLH22VT0foDmycluSSPas
	zBPber2JK+6RBPtl4E+2yariSxl6y9E9Zmn1mDJyBVdgs3nqcPV10itwGtK5zzQjUM73wjsEHgR
	v9do4/fTR2RLZehTMW59zch08k8rMkLBzUwLhkWLsaJmtXKsbCBqyP4gGv5CE4b9eWP1mDiMBzv
	ZpHgeHp9BUPYjnU5oN+yxLVFgZp+xm8a1C9WZ7ZXh2XygXMlDVEzNnXFxwGN+KKfnE7ENlAfIgz
	G6P+QlzcMaP3dxGn+wIS5raRe6UFARvXnWfIbhEXuWhmhsz1J4O9gRVXtthA87feyTDloQbpDFe
	C9AHVDyI9sFXOMPOKi+BAFzP+NjGbZ1m6MJk9eYdj6wWKa48=
X-Google-Smtp-Source: AGHT+IHP2v0f6liJL0SU+vzW8MdfcUG2IVDI1YnvdfeGPuJ4p7qXOxNg/wQfdvJUVVf3rSsjGzhCXQ==
X-Received: by 2002:a05:6000:650:b0:3a4:f892:de7f with SMTP id ffacd0b85a97d-3a6ed63786dmr5876410f8f.36.1750948893662;
        Thu, 26 Jun 2025 07:41:33 -0700 (PDT)
Message-ID: 
Date: Thu, 26 Jun 2025 16:41:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v4 5/8] xen/domctl: extend XEN_DOMCTL_assign_device to
 handle not only iommu
To: Oleksii Moisieiev 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper ,
 Anthony PERARD ,
 Bertrand Marquis , Juergen Gross
 , Julien Grall ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Volodymyr Babchuk ,
 Grygorii Strashko ,
 Stefano Stabellini 
References: 
 <4f58bf9c47c40413ee9250c4cd21458382aac857.1747669845.git.oleksii_moisieiev@epam.com>
 
 
 
 <1780646c-cb6f-4508-86c8-a573fbc09f6a@epam.com>
 <1e116116-ddf7-4640-9809-2502203abe46@suse.com>
 <3e190e60-74a4-4565-acae-3b8602a4c46e@epam.com>
 <8bb4e188-eb3b-4ee3-88cc-93c826b04ef8@suse.com>
 <0cb693b6-c22c-41e2-b332-7b7e4134d0df@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: <0cb693b6-c22c-41e2-b332-7b7e4134d0df@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 26.06.2025 15:07, Oleksii Moisieiev wrote:
> 
> On 26/06/2025 09:10, Jan Beulich wrote:
>> On 25.06.2025 21:56, Oleksii Moisieiev wrote:
>>> On 23/06/2025 10:15, Jan Beulich wrote:
>>>> On 19.06.2025 18:15, Oleksii Moisieiev wrote:
>>>>> On 18/06/2025 03:04, Stefano Stabellini wrote:
>>>>>> On Thu, 12 Jun 2025, Oleksii Moisieiev wrote:
>>>>>>>>> diff --git a/xen/arch/arm/firmware/sci.c b/xen/arch/arm/firmware/sci.c
>>>>>>>>> index e1522e10e2..8efd541c4f 100644
>>>>>>>>> --- a/xen/arch/arm/firmware/sci.c
>>>>>>>>> +++ b/xen/arch/arm/firmware/sci.c
>>>>>>>>> @@ -126,6 +126,43 @@ int sci_assign_dt_device(struct domain *d, struct dt_device_node *dev)
>>>>>>>>>          return 0;
>>>>>>>>>      }
>>>>>>>>>
>>>>>>>>> +int sci_do_domctl(struct xen_domctl *domctl, struct domain *d,
>>>>>>>>> +                  XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
>>>>>>>>> +{
>>>>>>>>> +    struct dt_device_node *dev;
>>>>>>>>> +    int ret = 0;
>>>>>>>>> +
>>>>>>>>> +    switch ( domctl->cmd )
>>>>>>>>> +    {
>>>>>>>>> +    case XEN_DOMCTL_assign_device:
>>>>>>>>> +        ret = -EOPNOTSUPP;
>>>>>>>> Are you sure -EOPNOTSUPP is the right error code for the 3 checks below?
>>>>>>> The -EOPNOTSUPP code is used because this is part of a chained call after
>>>>>>> iommu_do_domctl, as stated in xen/common/domctl.c:859. The
>>>>>>> XEN_DOMCTL_assign_device
>>>>>>> call is expected to handle any DT device, regardless of whether the DT
>>>>>>> device is
>>>>>>> protected by an IOMMU or if the IOMMU is disabled.
>>>>>>> The following cases are considered:
>>>>>>>
>>>>>>> 1. IOMMU Protected Device (Success)
>>>>>>>
>>>>>>> If the device is protected by the IOMMU and iommu_do_domctl returns 0,
>>>>>>> we continue
>>>>>>> processing the DT device by calling sci_do_domctl.
>>>>>>>
>>>>>>> 2. IOMMU Disabled (-EOPNOTSUPP from iommu_do_domctl)
>>>>>>>
>>>>>>> If iommu_do_domctl returns -EOPNOTSUPP, indicating that the IOMMU is
>>>>>>> disabled,
>>>>>>> we still proceed to call sci_do_domctl.
>>>>>> OK this makes sense.  I think it is OK to have a special error code to
>>>>>> say "the IOMMU is disabled" but I don't know if it is a good idea to try
>>>>>> to use -EOPNOTSUPP for that. -EOPNOTSUPP could mean a hypervisor
>>>>>> configuration with domctl disabled, for instance.
>>>>>>
>>>>>> It might be wiser to use a different error code. Maybe ENOENT?
>>>>>>
>>>>> I see that in the following commit:
>>>>>
>>>>> 71e617a6b8 (use is_iommu_enabled() where appropriate..., 2019-09-17)
>>>>>
>>>>> -ENOSYS return code was changed to -EOPNOTSUPP in iommu_do_domctl.
>>>>>
>>>>> It's not clear to me why this was done from the commit description.
>>>> This has been discussed many times elsewhere. Many of our ENOSYS uses are
>>>> simply wrong. ENOSYS has very limited applicability: Unavailability of a
>>>> top-level hypercall (originally: syscall).
>>>>
>>> What is your opinion about changing it to -ENOENT to say "the IOMMU is
>>> disabled" as Stefano suggested in [0]?
>>>
>>> [0]: https://lists.xen.org/archives/html/xen-devel/2025-06/msg01233.html
>> To me, ENOENT is closer to ENODEV, and hence not overly applicable here.
>> If you want to avoid EOPNOTSUPP for whatever reason, how about ENXIO or
>> EIO? (EPERM might also be an option, but we assign that a different
>> meaning generally.)
> 
> Maybe -ENODEV is a better choice because iommu_do_pci_domctl and
> iommu_do_dt_domctl return this
> 
> code when some feature is not supported.

What feature are you talking about? All I see in the former is

        ret = -ENODEV;
        if ( domctl->u.assign_device.dev != XEN_DOMCTL_DEV_PCI )
            break;

and there -ENODEV is quite appropriate.

> I think -EIO or -ENXIO aren’t suitable here since we’re planning to send
> this message when the IOMMU is disabled.

Well, I don't like those two very much either for the use here, but I still
view them as better than ENOENT.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 14:45:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 14:45:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026564.1401721 (Exim 4.92)
	(envelope-from )
	id 1uUnqy-00028l-Tw; Thu, 26 Jun 2025 14:45:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026564.1401721; Thu, 26 Jun 2025 14: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 1uUnqy-00028e-Qn; Thu, 26 Jun 2025 14:45:28 +0000
Received: by outflank-mailman (input) for mailman id 1026564;
 Thu, 26 Jun 2025 14:45: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 1uUnqx-00028Y-7C
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 14:45:27 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3223eb75-529c-11f0-a30f-13f23c93f187;
 Thu, 26 Jun 2025 16:45:26 +0200 (CEST)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 (Authenticated sender: nicola)
 by support.bugseng.com (Postfix) with ESMTPA id D6D534EE98AA;
 Thu, 26 Jun 2025 16:45:24 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3223eb75-529c-11f0-a30f-13f23c93f187
Authentication-Results: bugseng.com; arc=none smtp.remote-ip=162.55.131.47
ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1750949124;
	b=U3Ojx9d//tQtIb3KhvDi6ZEZNGQumKRkfh/hVx8sBBrGbcbXWEc9xcNQC84bgKKdmK2P
	 xaMooXmpUfwtXQ09+yiNgcmufKEMBiVHzqQwq4t+i62c3LQ+ThZI/5dgbKH727iXOQy5l
	 02D8yNSG8H+I5i07ZtNf2j14Pxw97E886SZryVyCbQWYm/UpJP7Y7KlqctcPNql+sbJhD
	 o9VRyvD9mXBapa4oSBVQTi/WWNBgR8xZ8hx4x2mX7OAA0Ih3Za7Qs46SPJujJFgPNEDDL
	 M5xbnvM0hn05uAVwHuQM0JDH0eZcy9B77tIhTRdL1lroQLS1OxOLVze0AXqBdJbQpmhbf
	 grg3aqvSz6ekB3CuFTN4UjciS5WD6FNgZv21kbMEF7oaSGqJ2Wz6Hwjwm+65ssiHAeUFT
	 kc57HcgTLP9PX35P4YqOIU9NIph33hT/06E9k8YktpPq5LMrZAXR3SHpOVKyFpGOpw3f0
	 /o5y8PQI0fYD3odAqH6EBrwojJO3CfRQveN+nZimp5sOpbDpPvgCvZMe2gkAqcEbhL43b
	 4AQ7HsmD6fQrYVfBoDsbqG5N9ghdTfv/dTyaJzRiWv01VmDpYJ9M4Dbe1VyTKjMKfn/th
	 A4lauEvI00KOwX7o7gRZHG7DqSTsIXZQFJ3Gn/Ob1LIKqdKcA3spdjAM0vW9MmY=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1750949124;
	h=DKIM-Signature:MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:
	 References:Message-ID:X-Sender:Organization:Content-Type:
	 Content-Transfer-Encoding;
	bh=Qz0iB7aUQ9vqJuypBRbALfOZSr2anArAlOVnsRMt83c=;
	b=PMIYYsMP1p5CIW0QT+ZItd60oVL8/MdEzku71QbgX6r5zXPMIQ4A2OgvhBljmmidZqGQ
	 aI9vvdiNDCFIeY3feycGAeeNflJdVzHwhaxjulCldiIjqHr+Jj+HrDkRxmo2IH78GqOpi
	 khYheWuemn8qkdmq0iSqW4k0fHgeoW/T5x4+uqaXx2DrltIeJjp7a669CRQ8yOwuItkxa
	 7eeQzFVoEnCzfQBZ0dHtMznsliEJbhw2uoK0M63V8X4u2/PFrBeG0IV8YBKkZZ2eoX4nS
	 7z0i28GDQBBc1+C8sNxcKImoIVXZOlpjjX02BXst7Nv4uXoTDyREpJPQl5zBG94gHhUbp
	 AKdt4YUqlXpXrQJoaavNljW3E5t/7B3idgoTlrq7W8s3+C3AWifNGoTXbkbBZ5uJRIqrH
	 n4ZA3oZpDaEGG+D/iPLxRjCW9o+GaaYuH/ZMIn7xbu/0eqiHDKRouCkrVs30TiM1TiQ2m
	 wy8Ed0s5TU7+F4QslPUB3iJ6EMDohiQPmhWvxC0f/y2MmIldzf3JqK/rif74fR518TaQV
	 xnbIVLALx5ml6UA5Kctvgt563fGrszxKt3shCcDbxmfy8X73OSyAjrErpAlE7plY1tTMp
	 VmgbnDOaB8fM8r0g8oBnWQQD4FfgeItmRYFsoukc6alJGZ0zRrN2QzGAVtGYuUU=
ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1750949124; bh=vFuZYmp056XyyVm6vEIbSCdf+ety9niT2s7YK5Cj+mk=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=UPw4/dKsOhbbjScYRzHCAD304cCFz3l3mdyvGarWwauwtgigBvlqfYmYwnMB2cmSO
	 Og4XzZfNq1xPOejnjEprdTjrn6hnsnUOl4yXDC2pUfnCjdm75bx9oapZQIGMuBjv21
	 3F8KA7w3VFE8A2xvNkwaV1c0aYXYpKMofD0IiwaKbsWjewg4FWioBuLlcL0vq5iEbJ
	 fvIXPeAYFRLvHO7nneRmGR9g7n76DEPorKznBOobk0A0GFP/ibNuIp/zkl7L+w9ZOA
	 CxsjeP+H/9ZEKjjuMDgAyS9M5RWYuY+/NLKld3qu4kDmySnCNu/Y4K7RG5Ik9BvaAv
	 wTTwH+5Rwr5Dw==
MIME-Version: 1.0
Date: Thu, 26 Jun 2025 16:45:24 +0200
From: Nicola Vetrini 
To: Jan Beulich 
Cc: Stefano Stabellini , andrew.cooper3@citrix.com,
 michal.orzel@amd.com, julien@xen.org, roger.pau@citrix.com, Bertrand Marquis
 , xen-devel@lists.xenproject.org
Subject: Re: [PATCH] docs/misra/rules.rst: allow string literals with memcmp
In-Reply-To: <0c6d5b49-ce69-4f16-b61e-ad1378b20807@suse.com>
References: 
 <0c6d5b49-ce69-4f16-b61e-ad1378b20807@suse.com>
Message-ID: 
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 2025-06-24 08:11, Jan Beulich wrote:
> On 24.06.2025 01:45, Stefano Stabellini wrote:
>> Rule 21.16 is about the types of arguments allowed for memcpy.
> 
> Seeing the subject - is it memcmp(), memcpy(), or both? (Writing from
> home, where I don't have the Misra spec to hand, and hence can't check
> what coverage the rule has.)
> 
> Jan

In this case the rule covers just memcmp(): "The pointer arguments to 
the Standard Library function memcmp shall point to either a pointer 
type, an essentially signed type, an essentially unsigned type, an 
essentially Boolean type or an essentially enum type"

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 14:48:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 14:48:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026570.1401732 (Exim 4.92)
	(envelope-from )
	id 1uUntw-0002fA-Bk; Thu, 26 Jun 2025 14:48:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026570.1401732; Thu, 26 Jun 2025 14:48:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUntw-0002f3-83; Thu, 26 Jun 2025 14:48:32 +0000
Received: by outflank-mailman (input) for mailman id 1026570;
 Thu, 26 Jun 2025 14: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 1uUntu-0002ex-Is
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 14:48:30 +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 9d261cbc-529c-11f0-b894-0df219b8e170;
 Thu, 26 Jun 2025 16:48:25 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3a54700a463so726999f8f.1
 for ; Thu, 26 Jun 2025 07:48:25 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-315f5382eecsm4476508a91.6.2025.06.26.07.48.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 26 Jun 2025 07:48:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9d261cbc-529c-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750949305; x=1751554105; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=NC1zhCG4gaYiUufABQmXdid/inR6JqOPVSGdC/cVfiY=;
        b=Y+JOTuhQIVS2sZQFqdRMHIIeyVrZCEOo+e5UbNTm4RShnGBKvAfcTolXb5/Gdx2Lh3
         4UZEJXCUknAx7uO6ii8gvE14Syn6tTTOJfdduja59fCVa7Mw+GQJCGYbk/tlqR01b3cX
         gz67k2W+3r9zo3KaWs8aMYdSkcFfX88fKUGfUVQJT+ru9BrclC/08CVqU57Wun7IzojI
         XSrbLxXu6yuwhpwbUuLsZcAS4uufRfOwvlFUX8ZHgJKYaIMBQnk/0jYKvcLOk4akm6+T
         jq6nkpgSi1F9+/yPtZuMvLzQpNbVdCI7bMHqxhZ3bzW0bZa1oXRz4En3R+UL3+XEbIHA
         ZK0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750949305; x=1751554105;
        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=NC1zhCG4gaYiUufABQmXdid/inR6JqOPVSGdC/cVfiY=;
        b=JrKvKCKq3jfgBy5+HSsHdATW9Ef0EnQCsZlc1XUZEmFdnvWTBtSr8ERtgAUEj4jk6G
         E/Fdjis0ss8IBJvcE6QiJyZ6yQ/XSdNLAHpll1BUcCPLn3bdPE60tUGQ+zpXs23Qs0PA
         c06r4cGfgu559CTkhxdadjkC2IVgnQxBhvOqMZUM396sK1RSNUe/3tbAfRCC744CARcY
         BHFV6D6MFGMNo51ipVUx3aR0QWSyHxfU/VrA0/J4Id4QirxPJDC3Qe12Ju1biwPcf9F9
         HcqPoKYG7bvsl07Si9F7diFGnpkMxEBpdTC1+oLoL/+eE5i9upr3OdseR36IqBB04WKZ
         NknA==
X-Forwarded-Encrypted: i=1; AJvYcCXiQTDy4rGHcIX7PGXIReTMRCgjKVWYwJMNNEOvWfvM+UMaE06s4n/F+QnDdHjUm/I22d8VLlo4Noc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwfGcaLSgxPNrxSF8+qqidMpex/PShWDzBn7/ErawQnQvuIv9U7
	qa32vcnbQRV+Uxxi/7Wsym+6wlGH3mlVjkYIG1E20oSsir0Dw43jws38hmzqpTOwiw==
X-Gm-Gg: ASbGncvWaXo70W1o8VcmQSxZpWpNWdRMsF/UEISMkh4scuvmjf0a9hWzHTxitz8nRgI
	Qxx/L57twNKj/TMuC+F5P1CRTTNLycBIZyTWqXw+/RIuploYshk1GcOPMR9Tfs7cSKsh11Q28Sw
	mvWd49AR/G07eS4TvFHlce0LnnMaR8A8kOpM0UkE9/SleY6vA2cKX6tGDxy5nlT+RjbZKvcgVXu
	4xkITO6UYQw1uYQRALCzL60EbAQElXrqq8AnckOVRa59QcYrYzXVeAqrL09dZnK9i1i9tnxH/dX
	qovRsq1VeCmqsD5iwPdKzSvU/YwPOUedLfHaeIuvYu68sz35br4/8rY9fZbuU7BH6rpxb96Ulsa
	llsByrIFGZ8L0/lGzifYuq7vpKHmRwOXWUoWaXfT67NvXRqs=
X-Google-Smtp-Source: AGHT+IFfbYd6hIl1ed4ToupI5sGQWvVLnf9k6tm6Oq5hWCNiIdOfoGM9qYRePhuepgm2d2OIL/pDhw==
X-Received: by 2002:a05:6000:4008:b0:3a5:8977:e0fd with SMTP id ffacd0b85a97d-3a6f30c897bmr3338263f8f.0.1750949304808;
        Thu, 26 Jun 2025 07:48:24 -0700 (PDT)
Message-ID: <3f250f66-e7fd-4072-8e55-e34eb9a14e58@suse.com>
Date: Thu, 26 Jun 2025 16:48:16 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/3] xen/efi: Support loading initrd using GRUB2
 LoadFile2 protocol
To: Frediano Ziglio 
Cc: "Daniel P. Smith" ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , xen-devel@lists.xenproject.org
References: <20250625073408.7496-1-frediano.ziglio@cloud.com>
 <20250625073408.7496-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: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 26.06.2025 16:24, Frediano Ziglio wrote:
> On Thu, Jun 26, 2025 at 2:29 PM Jan Beulich  wrote:
>> On 25.06.2025 09:34, Frediano Ziglio wrote:
>>> --- a/xen/common/efi/boot.c
>>> +++ b/xen/common/efi/boot.c
>>> @@ -850,6 +850,74 @@ static bool __init read_file(EFI_FILE_HANDLE dir_handle, CHAR16 *name,
>>>      return true;
>>>  }
>>>
>>> +#pragma pack(1)
>>> +typedef struct {
>>> +    VENDOR_DEVICE_PATH              VenMediaNode;
>>> +    EFI_DEVICE_PATH                 EndNode;
>>> +} SINGLE_NODE_VENDOR_MEDIA_DEVPATH;
>>> +#pragma pack()
>>
>> Where is this coming from? And why is this declared locally here, but the ...
> 
> The declaration comes from e2dk code and it's similar to code in Linux.
> It's not a generic declaration so it's not in a header.

Please add some kind of reference to the patch description in such cases.

>>> +static bool __init initrd_load_file2(const CHAR16 *name, struct file *file)
>>> +{
>>> +    static const SINGLE_NODE_VENDOR_MEDIA_DEVPATH __initconst initrd_dev_path = {
>>> +        {
>>> +            {
>>> +                MEDIA_DEVICE_PATH, MEDIA_VENDOR_DP, { sizeof (VENDOR_DEVICE_PATH) }
>>> +            },
>>> +            LINUX_EFI_INITRD_MEDIA_GUID
>>> +        },
>>> +        {
>>> +            END_DEVICE_PATH_TYPE, END_ENTIRE_DEVICE_PATH_SUBTYPE,
>>> +            { sizeof (EFI_DEVICE_PATH) }
>>> +        }
>>> +    };
>>> +    static EFI_GUID __initdata lf2_proto_guid = EFI_LOAD_FILE2_PROTOCOL_GUID;
>>
>> ... corresponding GUID is put in a (random?) header file?
> 
> The GUID is declared in the header for device paths, being a GUID for
> a device path.

Oh, sorry, my comment belonged a few lines up, where the other GUID is
used.

>>> +    EFI_DEVICE_PATH *dp;
>>> +    EFI_LOAD_FILE2_PROTOCOL *lf2;
>>> +    EFI_HANDLE handle;
>>> +    EFI_STATUS ret;
>>> +    UINTN size;
>>> +
>>> +    dp = (EFI_DEVICE_PATH *)&initrd_dev_path;
>>
>> Instead of a (fragile) cast, why not
>>
>>     dp = &initrd_dev_path->VenMediaNode.Header;
> 
> It makes sense, although at the end it's just style. Code came from
> Linux in this case.

Using casts (or not) is "just style", yes, but imo a pretty important part
thereof.

>>> +    file->addr = min(1UL << (32 + PAGE_SHIFT),
>>> +                     HYPERVISOR_VIRT_END - DIRECTMAP_VIRT_START);
>>
>> I understand you took this from read_file(), but the construct looks
>> outdated. For one, it should have been abstracted away when the Arm64
>> work was done (I don't think such a restriction exists there), and
>> then I'm also not sure the restriction would unconditionally apply on
>> x86 anymore.
> 
> Do you have an updated/correct formula?

No, hence why I said "not sure". For Arm at least I would assume no
restriction applies at all.

>>> +    ret = efi_bs->AllocatePages(AllocateMaxAddress, EfiLoaderData,
>>> +                                PFN_UP(size), &file->addr);
>>> +    if ( EFI_ERROR(ret) )
>>> +        PrintErrMesg(L"Allocation failed", ret);
>>> +
>>> +    file->need_to_free = true;
>>> +    file->size = size;
>>> +
>>> +    ret = lf2->LoadFile(lf2, dp, false, &size, file->str);
>>> +    if ( EFI_ERROR(ret) )
>>> +    {
>>> +        efi_bs->FreePages(file->addr, PFN_UP(size));
>>> +        PrintErrMesg(L"Loading failed", ret);
>>> +    }
>>> +
>>> +    efi_arch_handle_module(file, name, NULL);
>>
>> Shouldn't it be handle_file_info() that you call, and a little earlier?
> 
> Already changed in the last series.
> Earlier where? You want it after loading data, right ?

See where read_file() has it.

>>> --- a/xen/include/efi/efidevp.h
>>> +++ b/xen/include/efi/efidevp.h
>>> @@ -398,5 +398,26 @@ typedef union {
>>>
>>>  } EFI_DEV_PATH_PTR;
>>>
>>> +#define EFI_LOAD_FILE2_PROTOCOL_GUID \
>>> +    { 0x4006c0c1, 0xfcb3, 0x403e, {0x99, 0x6d, 0x4a, 0x6c, 0x87, 0x24, 0xe0, 0x6d } }
>>> +
>>> +typedef struct EFI_LOAD_FILE2_PROTOCOL EFI_LOAD_FILE2_PROTOCOL;
>>> +
>>> +typedef
>>> +EFI_STATUS
>>> +(EFIAPI *EFI_LOAD_FILE2)(
>>> +    IN EFI_LOAD_FILE2_PROTOCOL      *This,
>>> +    IN EFI_DEVICE_PATH              *FilePath,
>>> +    IN BOOLEAN                      BootPolicy,
>>> +    IN OUT UINTN                    *BufferSize,
>>> +    IN VOID                         *Buffer OPTIONAL
>>> +    );
>>> +
>>> +struct EFI_LOAD_FILE2_PROTOCOL {
>>> +    EFI_LOAD_FILE2                  LoadFile;
>>> +};
>>> +
>>> +#define LINUX_EFI_INITRD_MEDIA_GUID \
>>> +    { 0x5568e427, 0x68fc, 0x4f3d, {0xac, 0x74, 0xca, 0x55, 0x52, 0x31, 0xcc, 0x68} }
>>>
>>>  #endif
>>
>> While I'm not maintainer of this code anymore, I hope the new maintainers will
>> still respect the original idea of keeping these headers in sync with their
>> origin. The way it's arranged, this change doesn't look like it would have been
>> taken from the gnu-efi package (albeit I will admit I didn't go check).
>>
> 
> I'll have a look at gnu-efi headers.
> Note that the media GUID is GRUB/Linux specific so probably won't be in gnu-efi.

Right, in which case it doesn't belong in any of these headers.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 14:50:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 14:50:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026578.1401742 (Exim 4.92)
	(envelope-from )
	id 1uUnw5-00048n-Mh; Thu, 26 Jun 2025 14:50:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026578.1401742; Thu, 26 Jun 2025 14:50:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUnw5-00048g-JS; Thu, 26 Jun 2025 14:50:45 +0000
Received: by outflank-mailman (input) for mailman id 1026578;
 Thu, 26 Jun 2025 14:50: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 1uUnw4-00048a-Q4
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 14:50:44 +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 ef109a8f-529c-11f0-b894-0df219b8e170;
 Thu, 26 Jun 2025 16:50:42 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a4fd1ba177so790236f8f.0
 for ; Thu, 26 Jun 2025 07:50:42 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23abe329b85sm319805ad.65.2025.06.26.07.50.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 26 Jun 2025 07:50:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ef109a8f-529c-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750949442; x=1751554242; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=lAxWw6kamL9VL9aPQKfyJmUPbAlK3M80eAWF7PJIgJg=;
        b=gsyD6AleU4rYA7NFCeSfIw2P3pYy33H9wBrhPt3Ma7Zj/l3MZ6DyiWAc7cnuseiYDk
         9jj4zN9jm2SPf9SJVP6G0sUZ/9Xz6hgtvRQRKiCIq94qefnnVIM5bPV9t8Ts3SaSID+A
         +HY5Od9anbDHbc6GSBySEGoPLXWSsgGoLxQrMPr51XyLM6Eraz9y3jCw36PMm4V1UA8r
         sBN2s2xntBwx4SJZ8WrYfLvupCT0n8rVuNgTwR/fysbjZJF+uZb+yWgMiCVIDx6KoupZ
         SDLak6pVaNIFvMz8y4/VQ+UBJZgmGo9j8ppxb8mOM3IOktVwqO/WS5uvW+X1QumNjmIK
         tlsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750949442; x=1751554242;
        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=lAxWw6kamL9VL9aPQKfyJmUPbAlK3M80eAWF7PJIgJg=;
        b=E7/6KF6F9yklKtbaEKQmguwNQ+s+I/IpoMYu0NQH1B1dIUBJDt1H/fI0TBms57tPK0
         qsyc7tpyjMClmhRcfLD73hesloO1WMKehiImHGzan1T6iGIcDx8JXryu20zFPXWn8PaQ
         tSEXXbs6sQYWocmZXMYWcWK2SqyqXNoDltxDCx/bUV5lz4JDJrCrEQgXayMcVxPfnT/1
         H0ulpBHOCsI8KG0Evtyw7Yf4+qwRjxUZs+fcqSceamf6RFZcR1/jkLTQv7/P1mAQvqfU
         +QeqUaIQ14E29YSQKgYaMglnbd4WEqp5jzQg5QtB+fFSlaltQSXF+fttM5OZExB20I3t
         MQhg==
X-Forwarded-Encrypted: i=1; AJvYcCXNdEIgntS14t/uajxibLaRTf1JY7qHhMf5oPMCIE6PHS0HqtHkBpCcqFWkkqhBes8tLDR2e/0CiSQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzTK3bRpGs6OkMHYPrT1Z+59hYsCF+JJJqDO8I61qsvwfvSR2kf
	ZWGoVGsmuAJmCj11NWG5ECbqRoTF8MtgSzCbrv+E/F9nMvlY2IoJpxBZ7xdlqFpXgQ==
X-Gm-Gg: ASbGncudCWVbzsQc0RdKLhP+Hw7PG7f8mm0lZUdC20l73N9KZ1Su1a4ItX1qIufBtdG
	OFsJ8pksUi/O2om3lpju/wdNexq/BDdVEJto9A5ZxpiYpk3mVHJdX/iVWXqqVyyI/yVIx3xyL1n
	7AxS5nVXXC789/wDtFw+k2sELDHIi3DsLNLpVthiWKT72bePhEzqrciifFL+v0aulB36RHrC4My
	fzhhXoLuMuFRyiMsqDcZRO57sNUh8Fo8tK6M+UFmYAZ2LU9rQYgMr5WG+dSQU3mahRXlyhUJC6D
	vciqXj7q29vlHRHFZLmArLuf0CIDU/mOpZSTvMKn/ESnSVR0oLrhzKqFX7gi1sCt6K1ZycY56sY
	uAxeR/eyOYbq6moCKJLUALpQu+/FKroyOaoZjl4A6tx//E8E=
X-Google-Smtp-Source: AGHT+IGNzN5cfC3/OUlWg9VbMPY7KaQOuIfh8Twk2zE5SOVRfSNFE4JVJPEFDlOW5CztMZKQ5UnRyg==
X-Received: by 2002:a5d:584b:0:b0:3a5:1360:6b34 with SMTP id ffacd0b85a97d-3a6f30fc280mr3336130f8f.2.1750949442153;
        Thu, 26 Jun 2025 07:50:42 -0700 (PDT)
Message-ID: 
Date: Thu, 26 Jun 2025 16:50:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 3/3] xen/efi: Update error flow for read_file function
To: Frediano Ziglio 
Cc: "Daniel P. Smith" ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , xen-devel@lists.xenproject.org
References: <20250626131059.61894-1-frediano.ziglio@cloud.com>
 <20250626131059.61894-4-frediano.ziglio@cloud.com>
 <9d64c239-d6cc-4eb5-b180-a5034bedcfdb@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 26.06.2025 15:41, Frediano Ziglio wrote:
> On Thu, Jun 26, 2025 at 2:31 PM Jan Beulich  wrote:
>>
>> On 26.06.2025 15:10, Frediano Ziglio wrote:
>>> --- a/xen/common/efi/boot.c
>>> +++ b/xen/common/efi/boot.c
>>> @@ -792,6 +792,8 @@ static bool __init read_file(EFI_FILE_HANDLE dir_handle, CHAR16 *name,
>>>
>>>      if ( !name )
>>>          PrintErrMesg(L"No filename", EFI_OUT_OF_RESOURCES);
>>> +
>>> +    what = L"Open";
>>>      if ( dir_handle )
>>>          ret = dir_handle->Open(dir_handle, &FileHandle, name,
>>>                                 EFI_FILE_MODE_READ, 0);
>>> @@ -800,54 +802,58 @@ static bool __init read_file(EFI_FILE_HANDLE dir_handle, CHAR16 *name,
>>>      if ( file == &cfg && ret == EFI_NOT_FOUND )
>>>          return false;
>>>      if ( EFI_ERROR(ret) )
>>> -        what = L"Open";
>>> -    else
>>> -        ret = FileHandle->SetPosition(FileHandle, -1);
>>> +        goto fail;
>>> +
>>> +    what = L"Seek";
>>> +    ret = FileHandle->SetPosition(FileHandle, -1);
>>>      if ( EFI_ERROR(ret) )
>>> -        what = what ?: L"Seek";
>>> -    else
>>> -        ret = FileHandle->GetPosition(FileHandle, &size);
>>> +        goto fail;
>>> +
>>> +    what = L"Get size";
>>> +    ret = FileHandle->GetPosition(FileHandle, &size);
>>>      if ( EFI_ERROR(ret) )
>>> -        what = what ?: L"Get size";
>>> -    else
>>> -        ret = FileHandle->SetPosition(FileHandle, 0);
>>> +        goto fail;
>>> +
>>> +    what = L"Seek";
>>> +    ret = FileHandle->SetPosition(FileHandle, 0);
>>>      if ( EFI_ERROR(ret) )
>>> -        what = what ?: L"Seek";
>>> -    else
>>> -    {
>>> -        file->addr = min(1UL << (32 + PAGE_SHIFT),
>>> -                         HYPERVISOR_VIRT_END - DIRECTMAP_VIRT_START);
>>> -        ret = efi_bs->AllocatePages(AllocateMaxAddress, EfiLoaderData,
>>> -                                    PFN_UP(size), &file->addr);
>>> -    }
>>> +        goto fail;
>>> +
>>> +    what = L"Allocation";
>>> +    file->addr = min(1UL << (32 + PAGE_SHIFT),
>>> +                     HYPERVISOR_VIRT_END - DIRECTMAP_VIRT_START);
>>> +    ret = efi_bs->AllocatePages(AllocateMaxAddress, EfiLoaderData,
>>> +                                PFN_UP(size), &file->addr);
>>>      if ( EFI_ERROR(ret) )
>>> -        what = what ?: L"Allocation";
>>> -    else
>>> -    {
>>> -        file->need_to_free = true;
>>> -        file->size = size;
>>> -        handle_file_info(name, file, options);
>>> +        goto fail;
>>>
>>> -        ret = FileHandle->Read(FileHandle, &file->size, file->str);
>>> -        if ( !EFI_ERROR(ret) && file->size != size )
>>> -            ret = EFI_ABORTED;
>>> -        if ( EFI_ERROR(ret) )
>>> -            what = L"Read";
>>> -    }
>>> +    file->need_to_free = true;
>>> +    file->size = size;
>>> +    handle_file_info(name, file, options);
>>>
>>> -    if ( FileHandle )
>>> -        FileHandle->Close(FileHandle);
>>> +    what = L"Read";
>>> +    ret = FileHandle->Read(FileHandle, &file->size, file->str);
>>> +    if ( !EFI_ERROR(ret) && file->size != size )
>>> +        ret = EFI_ABORTED;
>>> +    if ( EFI_ERROR(ret) )
>>> +        goto fail;
>>>
>>> -    if ( what )
>>> -    {
>>> -        PrintErr(what);
>>> -        PrintErr(L" failed for ");
>>> -        PrintErrMesg(name, ret);
>>> -    }
>>> +    FileHandle->Close(FileHandle);
>>>
>>>      efi_arch_flush_dcache_area(file->ptr, file->size);
>>>
>>>      return true;
>>> +
>>> +fail:
>>
>> Nit: Style (see ./CODING_STYLE).
>>
> 
> What specifically? I checked the indentation and it's 4 spaces. if-s
> are spaced correctly. About labels I didn't find much on CODING_STYLE
> so I opened 3/4 files and most of them are indented with no spaces
> (they start at column 1).

You didn't search for the word "label" then, did you? Quote:

'Due to the behavior of GNU diffutils "diff -p", labels should be
 indented by at least one blank.  Non-case labels inside switch() bodies
 are preferred to be indented the same as the block's case labels.'

Jan



From xen-devel-bounces@lists.xenproject.org Thu Jun 26 14:57:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 14:57:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026585.1401752 (Exim 4.92)
	(envelope-from )
	id 1uUo2g-00050U-9T; Thu, 26 Jun 2025 14:57:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026585.1401752; Thu, 26 Jun 2025 14:57:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUo2g-00050N-6k; Thu, 26 Jun 2025 14:57:34 +0000
Received: by outflank-mailman (input) for mailman id 1026585;
 Thu, 26 Jun 2025 14:57: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 1uUo2f-00050H-K3
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 14:57:33 +0000
Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com
 [2607:f8b0:4864:20::22b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e178e475-529d-11f0-b894-0df219b8e170;
 Thu, 26 Jun 2025 16:57:30 +0200 (CEST)
Received: by mail-oi1-x22b.google.com with SMTP id
 5614622812f47-40abe6f8f08so783794b6e.0
 for ; Thu, 26 Jun 2025 07:57:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e178e475-529d-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1750949849; x=1751554649; 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=2UxNtejzHt6apB6xUG64xQhpByahe+qgV8NS6kBpydc=;
        b=eRk/8ciB3jyPuvjyyprU0EOJ2Sbbr1ZyRgO+iuE2hjPGsmBYewoWWlHuBP2KA6x0MW
         M/+oJ18rAZKZQ3h+LBlcCAJwg+ifV9seyDeaa9DCS6Zcq6twRfnZeGhjRG/8IycuWrRh
         /Y/FIFHuiM0tTDr3dK+j1quidfqIroBlXk4X4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750949849; x=1751554649;
        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=2UxNtejzHt6apB6xUG64xQhpByahe+qgV8NS6kBpydc=;
        b=absVl2GYLXw1S4SfI0ND9Wc0rtJSrWfCLCspPBQhSOXebKh9WTwwe3gfEP8RzxUHcE
         hOK6LWOztIX5GwjBo60TxzBMpGkqid4pRshI3HIYsRRnYVEVwM7TtTvz8ruHspAO8TtB
         jWDyP0Pbwn7RKGIjEFQaT+0XoGNAvbCeHCW9+8NGfk2VLFvvaF8qVlu0409C2U84QgZW
         ds0DqkpoHuIH0TU+LabNETubnFYTFXKnVn5LRLa59dHlPDqejl2azJmn17LB9A6SnbaZ
         nyzMg6Czhua7rK1SzGGtX2UH0wCMoOR9rC0IwdyVSuaF4FLYNLZ3bGFVefPrTALKg6FV
         LeVQ==
X-Forwarded-Encrypted: i=1; AJvYcCWy/RZVSYweUJ7g3MVmQLScLFde0VVG6KSTlrPFY+4DVsK3TZKQeVREN/5b/QqiALJ+N/D88gCRqNU=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw42T/M97TtPs5crlU1qiJwS89Inh+SABbgY9KQECA0Kp4iONCo
	Y2U3ueLtYWosNiRty8hEeasWBl+L3shwsqoTIYiSwxaKanWHCCrRDPeNgMlchu5y9jf79NU5/si
	tBuqXkygKB+OCkUUAAnNtkLZN3WaYOb2l3oHZ7uRrcA==
X-Gm-Gg: ASbGncvmcqhX40vZuZZQN/BcoLubo85oqKqgv2Q/Bp0Pd/HSOv+Q5EkBNeESA5DRf6o
	ajNnZEYAaq6U/kpLjCCbeWcyYCXGs0QsKDrwhg7ALFOWXj2Wz8lIGACcfT9y4I9zCY0XRV5ZTIU
	Rqmc09Lp9M/v2sZvnPZ+koPejruVScs2uw7W2RJZ6jxQi+SvTNIX8=
X-Google-Smtp-Source: AGHT+IFgipUoECT9/8Y9lScFTVonwJ5KpC3n6+Sg0ksevR+vFHlx+reQX2VPbLypOpfPh1yHawDd7W9PhMgIx2qNagY=
X-Received: by 2002:a05:6808:2011:b0:406:6d79:49e3 with SMTP id
 5614622812f47-40b05c40646mr6095367b6e.34.1750949848827; Thu, 26 Jun 2025
 07:57:28 -0700 (PDT)
MIME-Version: 1.0
References: <20250626131059.61894-1-frediano.ziglio@cloud.com>
 <20250626131059.61894-4-frediano.ziglio@cloud.com> <9d64c239-d6cc-4eb5-b180-a5034bedcfdb@suse.com>
  
In-Reply-To: 
From: Frediano Ziglio 
Date: Thu, 26 Jun 2025 15:57:16 +0100
X-Gm-Features: Ac12FXxq8FY-Ylm26SB8CocNTSa_zgjHVQYPoHn44z-przQqbAshdw5tzIuI2pU
Message-ID: 
Subject: Re: [PATCH v4 3/3] xen/efi: Update error flow for read_file function
To: Jan Beulich 
Cc: "Daniel P. Smith" , 
	=?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= , 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 26, 2025 at 3:50=E2=80=AFPM Jan Beulich  wro=
te:
>
> On 26.06.2025 15:41, Frediano Ziglio wrote:
> > On Thu, Jun 26, 2025 at 2:31=E2=80=AFPM Jan Beulich =
 wrote:
> >>
> >> On 26.06.2025 15:10, Frediano Ziglio wrote:
> >>> --- a/xen/common/efi/boot.c
> >>> +++ b/xen/common/efi/boot.c
> >>> @@ -792,6 +792,8 @@ static bool __init read_file(EFI_FILE_HANDLE dir_=
handle, CHAR16 *name,
> >>>
> >>>      if ( !name )
> >>>          PrintErrMesg(L"No filename", EFI_OUT_OF_RESOURCES);
> >>> +
> >>> +    what =3D L"Open";
> >>>      if ( dir_handle )
> >>>          ret =3D dir_handle->Open(dir_handle, &FileHandle, name,
> >>>                                 EFI_FILE_MODE_READ, 0);
> >>> @@ -800,54 +802,58 @@ static bool __init read_file(EFI_FILE_HANDLE di=
r_handle, CHAR16 *name,
> >>>      if ( file =3D=3D &cfg && ret =3D=3D EFI_NOT_FOUND )
> >>>          return false;
> >>>      if ( EFI_ERROR(ret) )
> >>> -        what =3D L"Open";
> >>> -    else
> >>> -        ret =3D FileHandle->SetPosition(FileHandle, -1);
> >>> +        goto fail;
> >>> +
> >>> +    what =3D L"Seek";
> >>> +    ret =3D FileHandle->SetPosition(FileHandle, -1);
> >>>      if ( EFI_ERROR(ret) )
> >>> -        what =3D what ?: L"Seek";
> >>> -    else
> >>> -        ret =3D FileHandle->GetPosition(FileHandle, &size);
> >>> +        goto fail;
> >>> +
> >>> +    what =3D L"Get size";
> >>> +    ret =3D FileHandle->GetPosition(FileHandle, &size);
> >>>      if ( EFI_ERROR(ret) )
> >>> -        what =3D what ?: L"Get size";
> >>> -    else
> >>> -        ret =3D FileHandle->SetPosition(FileHandle, 0);
> >>> +        goto fail;
> >>> +
> >>> +    what =3D L"Seek";
> >>> +    ret =3D FileHandle->SetPosition(FileHandle, 0);
> >>>      if ( EFI_ERROR(ret) )
> >>> -        what =3D what ?: L"Seek";
> >>> -    else
> >>> -    {
> >>> -        file->addr =3D min(1UL << (32 + PAGE_SHIFT),
> >>> -                         HYPERVISOR_VIRT_END - DIRECTMAP_VIRT_START)=
;
> >>> -        ret =3D efi_bs->AllocatePages(AllocateMaxAddress, EfiLoaderD=
ata,
> >>> -                                    PFN_UP(size), &file->addr);
> >>> -    }
> >>> +        goto fail;
> >>> +
> >>> +    what =3D L"Allocation";
> >>> +    file->addr =3D min(1UL << (32 + PAGE_SHIFT),
> >>> +                     HYPERVISOR_VIRT_END - DIRECTMAP_VIRT_START);
> >>> +    ret =3D efi_bs->AllocatePages(AllocateMaxAddress, EfiLoaderData,
> >>> +                                PFN_UP(size), &file->addr);
> >>>      if ( EFI_ERROR(ret) )
> >>> -        what =3D what ?: L"Allocation";
> >>> -    else
> >>> -    {
> >>> -        file->need_to_free =3D true;
> >>> -        file->size =3D size;
> >>> -        handle_file_info(name, file, options);
> >>> +        goto fail;
> >>>
> >>> -        ret =3D FileHandle->Read(FileHandle, &file->size, file->str)=
;
> >>> -        if ( !EFI_ERROR(ret) && file->size !=3D size )
> >>> -            ret =3D EFI_ABORTED;
> >>> -        if ( EFI_ERROR(ret) )
> >>> -            what =3D L"Read";
> >>> -    }
> >>> +    file->need_to_free =3D true;
> >>> +    file->size =3D size;
> >>> +    handle_file_info(name, file, options);
> >>>
> >>> -    if ( FileHandle )
> >>> -        FileHandle->Close(FileHandle);
> >>> +    what =3D L"Read";
> >>> +    ret =3D FileHandle->Read(FileHandle, &file->size, file->str);
> >>> +    if ( !EFI_ERROR(ret) && file->size !=3D size )
> >>> +        ret =3D EFI_ABORTED;
> >>> +    if ( EFI_ERROR(ret) )
> >>> +        goto fail;
> >>>
> >>> -    if ( what )
> >>> -    {
> >>> -        PrintErr(what);
> >>> -        PrintErr(L" failed for ");
> >>> -        PrintErrMesg(name, ret);
> >>> -    }
> >>> +    FileHandle->Close(FileHandle);
> >>>
> >>>      efi_arch_flush_dcache_area(file->ptr, file->size);
> >>>
> >>>      return true;
> >>> +
> >>> +fail:
> >>
> >> Nit: Style (see ./CODING_STYLE).
> >>
> >
> > What specifically? I checked the indentation and it's 4 spaces. if-s
> > are spaced correctly. About labels I didn't find much on CODING_STYLE
> > so I opened 3/4 files and most of them are indented with no spaces
> > (they start at column 1).
>
> You didn't search for the word "label" then, did you? Quote:
>

I did, I probably mis-typed it.

> 'Due to the behavior of GNU diffutils "diff -p", labels should be
>  indented by at least one blank.  Non-case labels inside switch() bodies
>  are preferred to be indented the same as the block's case labels.'
>

I suppose labels should be indented less than the code they refer to,
so in this case from 1 to 3 spaces. I supposed 2 would be the best
option.

> Jan
>


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 14:57:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 14:57:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026586.1401762 (Exim 4.92)
	(envelope-from )
	id 1uUo2j-0005Ee-J2; Thu, 26 Jun 2025 14:57:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026586.1401762; Thu, 26 Jun 2025 14:57: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 1uUo2j-0005EX-Fv; Thu, 26 Jun 2025 14:57:37 +0000
Received: by outflank-mailman (input) for mailman id 1026586;
 Thu, 26 Jun 2025 14:57: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 1uUo2i-0005E8-4M
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 14:57:36 +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 e4542726-529d-11f0-a30f-13f23c93f187;
 Thu, 26 Jun 2025 16:57:34 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a4e742dc97so1511406f8f.0
 for ; Thu, 26 Jun 2025 07:57:34 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-749b5e2178csm7287971b3a.46.2025.06.26.07.57.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 26 Jun 2025 07:57:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e4542726-529d-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750949854; x=1751554654; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=HNq41wpOMxtjdVyPqHubusShV1czkm2z7ddoQnzqMZY=;
        b=P8b17cMJQpzMsYburb5VXKBQasd94Fn049xUylMHotzLPAha9+fU0aRwkEZHDJEwZg
         bgonNvJ3/KOcz3pE/dSgNUQYJ4L7ATnxRzxA4R4gooNwrKgPdeXNREACSxyf/OSK9PLA
         Ukgkux7xBu7J9jPqoRy2pkVJwxjE13vY99GZ8030Yaetg+eoaG20QgQRKeL+PN6jhm0w
         ILEclA0gDRiJoj/y+7e0/r3occfcnPjGcLgJPnjz3yprEIpBDcOOp4D4iBtbXEVM71uN
         QRdncxL5F4MZcAIetQcswZX4i6wE9P3hwmJKGI+GGwWi863qWyY4VYDC+ZuXcB08OGVd
         5ojQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750949854; x=1751554654;
        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=HNq41wpOMxtjdVyPqHubusShV1czkm2z7ddoQnzqMZY=;
        b=nEZ3BaWrLfvnUmvwzgOLhh1C7Ci83KoUCPwbmMc5ZHXhzd/UTKbWbDHfGVwP5tmBPs
         MaHldo0rvPGLemVQG3E/PSNLSmyjbFQQRsdI/8k+s5ys62/q7YlgrqgSSbuFnh7uXDSn
         CXPsx8gTNOGydnmbwbXa9IPjawbdy0B33xEh0iYub0DdSwlE06bA6Vsj2tUn2jk98MHS
         ltxgrzoIWSX2EA2xWvwAe27N51QsOOa1UyYM6VauSBQXIG939t8j1vS/W38zHdJ0CiTq
         KoOEwoeqLsg6BKwV0Bkr8lwKAv7md1WXFsm/2yFtmHPzRMJyjKY9XNzCgBbx71C8SZ1x
         2DWg==
X-Forwarded-Encrypted: i=1; AJvYcCV+mouvGX6FdcvbZ2xsLhNrmCg53ukQpATzYnT6Svt2VzWhd2C8y7214I+4wbRkInGFOQO2QBWsHrk=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz0C9tKKZSz8OIr3p521mKQ3kgRJnj6c7YZreikhhRJ4A8L8zE2
	E4redbcu03/1m3I8XIF3oXXExk1p4/qwr1A8LYBGEBCx54bg4H9e+1UGIzAg84qITA==
X-Gm-Gg: ASbGncvOY7PrGwcBZB0icTXWwidf0lT7dfubL/uTw41032FwyBb0EFwL9wYnw512PCj
	TbQNJavG5ga+B6LXc9SRauDNJ/PLb9O7zOMiaMCBl24DGbkxqLgKB+ig64YztupSxBWICPTzwmX
	HMIIbnUmCdX+tleMm2f5NkPNzgxA7reCE/k+kUqmqv+S7WC19QH7r8bAbO4i3FqlLyhZtdDx46d
	VI2tjN046quBn8RUqVAS0UfqeiTIvXl6Rgpn5LgNyNgmX6j3O0IftfDcojkX6yuicy4Rtanzw8B
	6FER2rl2MRNfgiGz2uFF4UXRyYG4szn5uy+J4xFPXJUNr8cTbjlj6sfXDHMbEr56GzAnpyCc5hC
	AtCfoMZXDecCelHhdEQfNbbD0oeG2fIfz0aSxyP3xt3fUxp0=
X-Google-Smtp-Source: AGHT+IG8cMZwSQd99ZfKY5gVcx2aIZbar4YAUryrpoVjT4fQpwaAUyeeEEqTRFS3FrY1JMQGvYknNw==
X-Received: by 2002:a05:6000:418a:b0:3a4:f70d:aff0 with SMTP id ffacd0b85a97d-3a6f312df2bmr2362695f8f.14.1750949853778;
        Thu, 26 Jun 2025 07:57:33 -0700 (PDT)
Message-ID: <525d7483-a2b3-4d78-8eb6-2bade5bba21f@suse.com>
Date: Thu, 26 Jun 2025 16:57:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 07/17] xen/riscv: introduce pte_{set,get}_mfn()
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: 
 <5e2f0cea49ac1e0669be15811b1426bf4b4d2fec.1749555949.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: <5e2f0cea49ac1e0669be15811b1426bf4b4d2fec.1749555949.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.06.2025 15:05, Oleksii Kurochko wrote:
> Introduce helpers pte_{set,get}_mfn() to simplify setting and getting
> of mfn.
> 
> Also, introduce PTE_PPN_MASK and add BUILD_BUG_ON() to be sure that
> PTE_PPN_MASK remains the same for all MMU modes except Sv32.
> 
> Signed-off-by: Oleksii Kurochko 

Acked-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Thu Jun 26 14:59:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 14:59:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026602.1401773 (Exim 4.92)
	(envelope-from )
	id 1uUo4p-00067N-Vw; Thu, 26 Jun 2025 14:59:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026602.1401773; Thu, 26 Jun 2025 14:59: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 1uUo4p-00067G-RP; Thu, 26 Jun 2025 14:59:47 +0000
Received: by outflank-mailman (input) for mailman id 1026602;
 Thu, 26 Jun 2025 14:59: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 1uUo4o-000677-NS
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 14:59:46 +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 32aa3df8-529e-11f0-a30f-13f23c93f187;
 Thu, 26 Jun 2025 16:59:45 +0200 (CEST)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-3a6cd1a6fecso1073324f8f.3
 for ; Thu, 26 Jun 2025 07:59:45 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-749c8851337sm7129468b3a.126.2025.06.26.07.59.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 26 Jun 2025 07:59:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 32aa3df8-529e-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750949985; x=1751554785; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=NDCHXjNU/JPLNa8tmrdUtGPpjR/p3lLSltJO3ThCpsg=;
        b=V0C8WdMwWtxVcw0rfJoA7k+WMHZI8SJ785gTb2r8u2y8Cx4Dzc8RuPyqeGq0XNOylP
         YPuGm7JSTYpAReiQWrhjxzafFGd8GDpNsRifc+/6psTz9BZD5+yLvS+kWwgda3csoK3s
         eUVsyy91RV5wAzlplK0b3AN5IDhMtSUZGebVcAVEVbf4dzDvRxLdLoM9A0XvnONAS+iM
         pj66O/j2MQqSnZe2Hog+TkptbQnkkT/U2x3ykUmy7rNq2bhh9gPfrLYu5+KS6l0ncpxs
         /dSvfhwI5rpIzQdC61E2D+b8vnJRGgRwvM7LAcNjeUS1Bre1AaAI5XDgm22MKH4Udvnk
         yt5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750949985; x=1751554785;
        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=NDCHXjNU/JPLNa8tmrdUtGPpjR/p3lLSltJO3ThCpsg=;
        b=WeJ/UYnA+ukxSxTXg/UCgUbOO6vQyOB7mtKZtHitB/rNUPjTFbZfCsIF8Q4iA7sbMS
         EIkKWnknSS9D+74X+0KEVcBymPvnMQk+yZHknVqUuPeYVanMd1kevN1pY0GLq864uTst
         h6+Vp8lqyzXbjf1sdAeX7ikG+8xk3pAft4IbTE3Z2LZKKQRr35KesyRcp3JD3aRuBqMy
         DodagM0A0topPe2lsCoCbTUVFWaVXYf7FCosmzl/tR4KF4gfp2/31thjSuM99PHKC5rY
         HQd62ZbGmkpdaRgJHQnY+ZZwRtfA3i7SvkIOYMslSHNZHBRepAAs1HONuvnVnZoHff5l
         Y35g==
X-Forwarded-Encrypted: i=1; AJvYcCUmf16x5PcyXXCQVVpWjIG/STLKI8fV6nycSsRfIH9o+mtxklmSLmKlONVErI2PzLXuz7zNjfGRFag=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyHmNEA3d5++0qfW8nuhjEH64IK8U9atV5qpiziky1mG+PtWJGr
	HFM86NaCeHDHG/QnUKg51kK9Z2T5QR6pWMdHlT59BmmMKTvtFWt/HSYr3F+6TiYiJQ==
X-Gm-Gg: ASbGnctfxNuozQPc/566SSEbWAmPeiHARAinojmnN8gbFa3yq5POoEXVcIg0Q9w9Q0o
	lpZca0ZeQ2zQ0K585EhKZMmcx6VS0Wqp2EKwN7HloroW41GFGUdIa2XA0shhn6SYf2YpjMzFNtQ
	Vxw/tlr1OnF7sv5AVl9mOiKFG8lc7qMvnPpnz52PU+7YEG79X3pKXwwM/fXf5WSEjYRw5Eryzqd
	65iNeG55OXj0t9wdNoawfTuShr/qsjqN/duyNFhjwYPVZNe2mWls0vMkjh9J+hff0MuO9Xv47+W
	xvv7ZqbJvRNHonfrsYoH9gRdY4tCa+nDQPz5dQP4lZTOnFI7h4LeaFFBfZmQXaR6Aja3R+wq5G3
	9Eou+ghBELsruCQRU5bTCDAyawUrXx0PSjW+dMw8kEW+S7qE=
X-Google-Smtp-Source: AGHT+IFd4XfXXZOF6D9gtbQvB9AsQbqD8qUAugkWk0UKLfW8JiZSsFftN3hkt2VZ+mhySFymXqcLdw==
X-Received: by 2002:a5d:64e1:0:b0:3a5:8e0e:108b with SMTP id ffacd0b85a97d-3a6ed5dbf79mr7250087f8f.21.1750949985123;
        Thu, 26 Jun 2025 07:59:45 -0700 (PDT)
Message-ID: <8f45cffe-e2a2-46e3-8370-2b6b4c86dccf@suse.com>
Date: Thu, 26 Jun 2025 16:59:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 08/17] xen/riscv: add new p2m types and helper macros
 for type classification
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 10.06.2025 15:05, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/include/asm/p2m.h
> +++ b/xen/arch/riscv/include/asm/p2m.h
> @@ -61,8 +61,28 @@ struct p2m_domain {
>  typedef enum {
>      p2m_invalid = 0,    /* Nothing mapped here */
>      p2m_ram_rw,         /* Normal read/write domain RAM */
> +    p2m_ram_ro,         /* Read-only; writes are silently dropped */

As indicated before - this type should be added when the special handling that
it requires is also introduced.

> +    p2m_mmio_direct_dev,/* Read/write mapping of genuine Device MMIO area */

What's the _dev suffix indicating here?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 15:00:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 15:00:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026605.1401782 (Exim 4.92)
	(envelope-from )
	id 1uUo59-0007NZ-8v; Thu, 26 Jun 2025 15:00:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026605.1401782; Thu, 26 Jun 2025 15:00:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUo59-0007MX-32; Thu, 26 Jun 2025 15:00:07 +0000
Received: by outflank-mailman (input) for mailman id 1026605;
 Thu, 26 Jun 2025 15:00: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 1uUo57-0006Oi-5Z
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 15:00:05 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3d427150-529e-11f0-b894-0df219b8e170;
 Thu, 26 Jun 2025 17:00:03 +0200 (CEST)
Received: from nico.tail79467d.ts.net
 (host-79-60-221-62.business.telecomitalia.it [79.60.221.62])
 (Authenticated sender: nicola)
 by support.bugseng.com (Postfix) with ESMTPSA id 1CD444EE98AA;
 Thu, 26 Jun 2025 17:00:00 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3d427150-529e-11f0-b894-0df219b8e170
Authentication-Results: bugseng.com; arc=none smtp.remote-ip=79.60.221.62
ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1750950002;
	b=BVYuxEkDZl0omnkjEkxS/7On9/J1Wc8vxEQvpn92jrueueGRIxGhwv5bRxtFmbCm/wI2
	 c2ZMLCyQq8LM6QCixQh0WI/2cWCGTlIG4N/QEjJQEk4N6HJeLaJcDDLTT7zlTeRR/Eg12
	 y9HAJVypsqYQErwjmANhNSXB8lrQzzjxxP0GkM2i9LktREo2gtGp9WgjSdbR73ns/2EEm
	 xhKYTWao/v+QSTMq3LDY4sERV1agFe1/z9ZPIEXFfdhbgn1HYPcQb16Y3Jyae/q67BMQo
	 MMsOObfV/lBxMMde3UFe/HMho7HULUBYn4Q0z1N5sLun6bTPWd//e8rRUJDIKmAXHE3Mz
	 jdrNmpz0WvWiEupkeRjrmPm8tjDdOqQIihUufYyI9vZ9dmINfKvJ+l0ON56Z2x/qouHe+
	 T1LrV+r3LCo30hYXBa+Rq5TGcCnkbY6PUXIKm+7e6OdMkJuk5iiRhEmRcTYAaj2Pao5ap
	 x4KE3+HuCaAsYqLxfNvgM1T37X8aMn+p/iFZ1LoOACkJTOv6a54wp5Aum04z8twjsFIp0
	 5NbcjtB9XSZGOLNlGFtQEfF6AOdQahryWPXuQrCmIkmL8wFKADguEd4dMIXQHrplVx3+Y
	 +RvD9NQ5ecPJTb/I+zz2cNPDsDTGILwwgfL/DudObyBUNQq1JRPM8js3JKb85AI=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1750950002;
	h=DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer:
	 MIME-Version:Content-Transfer-Encoding;
	bh=DhbZyzEvXZJwU+5fKTxJbtSSLieax0xoM5Exn3sYlOM=;
	b=wEevkCu8Cn2wyEQHbuHr6w4nj3qARxQCasBl7RSMj+xKlsWgQK4lWkUV4N9WtlUel/vF
	 eni2cpJmFQ0rEWXGiXrZCJf9sGDG3vO9em07JpmBH1wC/gx0FmpD9WMuM9LBDq/SFUEs4
	 upLy0hkj0PzqrbKGSfuHfogTKPLXQYsDhH1AWULupvrHaSlD2hCd70ByOqHGZlPtHiwNU
	 s7uWQLq/z/yOIpTiT0St/EftGu4dcezIXbakVkB5CkRN3uMcAOyytiZnbj+M36Yox0t+Q
	 G1PypYZk3jwAtWea+Yj3s08SkYFkRRfCV6uYzNM1yyH6PApDOMpzDm8vcTSY2Ra2aVuNj
	 cedRwRCY/CQouecL1t+z2d6GQLiVuva9p4r2Zif8szXKF/c6o4upf4EtZGyoKIfqEo6Vl
	 RFxcd9SPBYURnvh9kVEmSbzH5S4AFAbwS+1eHDDF6VMdaR1tjO3c1vo1XQX/IlTXw/YMR
	 vkq6vHEOlXaIsu043HlZ3P+JviSd6TvKcg1DKOVlU+fWT81e6E6gFkSrUlmP+4lkM3bql
	 knef++jw01GqihYaj+1uYkC/xvWB96cSpFtITuHO6nj2ighEfcWCHHHoW3IXZVjdcfg6O
	 Og5jp9hhXWw+3VBImXbvFoyoHhdeAhiXCAZGmW+BEtEEuTPgQlUiDCYtur0x6yo=
ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=79.60.221.62
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1750950002; bh=GrRCNb7zRHi1VBh2VzYJ7xawetPSi5T3rUK2AAE7Lu4=;
	h=From:To:Cc:Subject:Date:From;
	b=d2JfNBhe6I1Bjo7RGjym2MErfX8ImLEj129SRScLyBUomKu8JvroaCwKRCYLp9mUI
	 BA6/+FwxHFlycV941Ed8LGDI8PAfBbbxVXfK9Iha1yguCjP5xP1aLHjaBnrWR1pf4i
	 qIfC5tk9YHS6dtk2jlyy/qcizm3iYpEZC00Y6f6Bc0BOK7KNy7HqYLqgruOtpUIOc0
	 HnsUfTYl5MN8d//rJMVO0pMyZlSZ+HfN7jaXwnpZYFI7BGyCOUobEkoU+3lqSg1OIw
	 zd7lxhNGu+gTRMv8W7k2k7TQTTm4Zl8rKhXQ47Hb84A1q/6yX8/Cx8elw+QshneoZF
	 9y8YUBQ2R/pXQ==
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 ,
	Andrew Cooper ,
	Anthony PERARD ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [XEN PATCH] xen: fix unspecified behavior in tr invocation
Date: Thu, 26 Jun 2025 16:59:57 +0200
Message-ID: 
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The result of the command is undefined according to the specification if
the "string2" argument in tr is shorter than "string1". GNU tr behaves
correctly by extending "string2" to repeat the last character.

Fixes: eb61a4fb14d2 ("xen: fix header guard generation for asm-generic headers")
Reported-by: Jan Beulich 
Signed-off-by: Nicola Vetrini 
---
 xen/scripts/Makefile.asm-generic | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/scripts/Makefile.asm-generic b/xen/scripts/Makefile.asm-generic
index f6850758c54b..4e628e116adf 100644
--- a/xen/scripts/Makefile.asm-generic
+++ b/xen/scripts/Makefile.asm-generic
@@ -34,7 +34,7 @@ unwanted    := $(filter-out $(generic-y) $(generated-y),$(old-headers))
 quiet_cmd_wrap = WRAP    $@
       cmd_wrap = \
 	arch=$$(echo $@ | sed -n 's:.*arch/\([^/]*\)/.*:\1:p' | tr a-z A-Z); \
-	upper=$$(echo $*.h | tr a-z A-Z | tr '/.-' '__'); \
+	upper=$$(echo $*.h | tr a-z A-Z | tr '/.-' '___'); \
 	echo "\#ifndef $${arch}_GENERIC_$${upper}" > $@.new; \
 	echo "\#define $${arch}_GENERIC_$${upper}" >> $@.new; \
 	echo "\#include " >> $@.new; \
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 26 15:01:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 15:01:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026614.1401792 (Exim 4.92)
	(envelope-from )
	id 1uUo6H-0008DU-FE; Thu, 26 Jun 2025 15:01:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026614.1401792; Thu, 26 Jun 2025 15: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 1uUo6H-0008DN-CK; Thu, 26 Jun 2025 15:01:17 +0000
Received: by outflank-mailman (input) for mailman id 1026614;
 Thu, 26 Jun 2025 15:01:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uUo6G-0008DF-5g
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 15:01:16 +0000
Received: from AS8PR03CU001.outbound.protection.outlook.com
 (mail-westeuropeazlp170120005.outbound.protection.outlook.com
 [2a01:111:f403:c201::5])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 669b0b41-529e-11f0-a30f-13f23c93f187;
 Thu, 26 Jun 2025 17:01:13 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by VI1PR03MB9914.eurprd03.prod.outlook.com (2603:10a6:800:1c1::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.27; Thu, 26 Jun
 2025 15:01:09 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%4]) with mapi id 15.20.8857.026; Thu, 26 Jun 2025
 15:01: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: 669b0b41-529e-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=bVuyXXAivdRnvtQ+NrxcvwhhqdFxlbr1B2Gq0Q7wbhpIlbMl98N3PAf42GZQeAHUUXYCuFwUEfaYZSJB26hN1PiSp4GwJqb8WW9+eSvZltwj+9u8vf0/QMJErmVy6s651fUQxfoVcdS9fBFrkLykUv7hugvLPNUL2GiDJ/5+OeVNh07i8b4isHZjA3w4q/NO2hzkURMw5zc3jMRac3fhpzFQmaM33qR9xqQwZc8dktfkbg6dpMUheb98PbDJiPZ+6oqdvZqU5CsslZmdbqiPHrrmuTQcsrYRl0xmCgGRW8NQ8b0mLDPypKvvaQLB9FWe1vxyMQyJ5E9xV5S2pj1orw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Hw5VFipeQe76nGX70jT6k3y+mNf6TPWpK1jLYyycsDI=;
 b=RVi1a3ZmSGjIWTfkU5P9agMSIhG8XDYE3aO8F+IwJ/hA2IxzyvPaDUJTyLs6D/5o+2rFYdB2PCSp3dJIcvuHsqMZqi239vS8lAKU9EOXX8ittr3U039fHzZMKMMOGdU5FnAojnDph4IODg9mQivNCqytGC+oviTufBPshZK2HST/4rYqA2rkkQfQDMkfZu/v5VPT10ITdSM6+oThw0Pw36eWpHKmGuDOwCcuwomb7YtZvngjs6jbH1orkeGENtKLUlc9hcXA1eGBTPQNO5RTrUzqydGVNelge31+UpqodZOPMDWnAERWsy6DmBzqmKm8cSojq5h5kv9RMSLT4kdgXw==
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=Hw5VFipeQe76nGX70jT6k3y+mNf6TPWpK1jLYyycsDI=;
 b=uEr0D/Ghs5mSAz3Tqgtv4SJf5/Lw1AJrd2rxByjmpSHVoIgdx44moPW4lMtuIj3/lTUKetUJFCpucksZC09liKRsm20UbYupoS6BTUTD3G2fZlg/+Yhl52rsCZ/Hrq23HUAWEv4r3/YBy/EJ2VTdFW+vAjc9dx+6T1BprLsytH7s0DOBqAO4SMyKI+HeCPZRkFcHjQytpL27dO21zfQZXk8mjOwrnWdhvglP5whHyimadd7Ht+EV/6L17Wnvmb6YA3Z/OSIo6CGfdMLgcoshK2S3hkx7Klrg/5krqpjijnTaPgQ4UW2sMWscRLOueLt2ozSA5aTsrvH1afk5KdVQdQ==
From: Oleksii Moisieiev 
To: Jan Beulich 
CC: "xen-devel@lists.xenproject.org" , Andrew
 Cooper , Anthony PERARD
	, Bertrand Marquis ,
	Juergen Gross , Julien Grall , Michal Orzel
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Volodymyr Babchuk ,
	Grygorii Strashko , Stefano Stabellini
	
Subject: Re: [RFC PATCH v4 5/8] xen/domctl: extend XEN_DOMCTL_assign_device to
 handle not only iommu
Thread-Topic: [RFC PATCH v4 5/8] xen/domctl: extend XEN_DOMCTL_assign_device
 to handle not only iommu
Thread-Index:
 AQHbyNXPDXt2FT3RV02cltfdm/Dd7rPdzmiAgCG+LgCACKrsAIACoXoAgAWykoCAA/lGgIAAq3gAgAB0qoCAABoigIAABYiA
Date: Thu, 26 Jun 2025 15:01:09 +0000
Message-ID: <1c019e95-1b62-4c19-9a5c-bfe541dd5813@epam.com>
References: 
 <4f58bf9c47c40413ee9250c4cd21458382aac857.1747669845.git.oleksii_moisieiev@epam.com>
 
 
 
 <1780646c-cb6f-4508-86c8-a573fbc09f6a@epam.com>
 <1e116116-ddf7-4640-9809-2502203abe46@suse.com>
 <3e190e60-74a4-4565-acae-3b8602a4c46e@epam.com>
 <8bb4e188-eb3b-4ee3-88cc-93c826b04ef8@suse.com>
 <0cb693b6-c22c-41e2-b332-7b7e4134d0df@epam.com>
 
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: PAVPR03MB8946:EE_|VI1PR03MB9914:EE_
x-ms-office365-filtering-correlation-id: 8774332d-0992-41d3-aa46-08ddb4c248ee
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|7416014|376014|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?LzlKNEo4enJOVURGQ3RZS0l4ZnJRcElzNzNHY2VaWXkrZUZ2dW9OSWZERGRz?=
 =?utf-8?B?UWl4dDMrTUdYQUhPaDBPQ3A4L3hoRVBFMG5ENDRtSDdDMThYbjZsQ2FoYU1k?=
 =?utf-8?B?QXZvZ2J3Q2VCeGVXdGxKaDc3cGZEczcrUGcrdnZ5ZDF3UzF3ZHh3WWNTS2FI?=
 =?utf-8?B?OXdDdlFWZUpUNzd6anc5a3BTL3F6VlZaTElpQ1g4RDRXeTJsdGdSRDcyZkRJ?=
 =?utf-8?B?WGNnazdkbEFmT2I2ZjBwWWtDYUp1Mk15RHhJSzhkUkhuOXNmZWUySDhGWDBX?=
 =?utf-8?B?N3Y2NDVnWEtkWU9aRkNORVcyYXgxd2VJaW10cVlMeUdSMi9La21wbnNidmtX?=
 =?utf-8?B?N3pHOGtKNGl1UjdYTVFsRTJZVjVGeEo1b1MxZGpSdnNlV0x2R0lkcWVNcFZQ?=
 =?utf-8?B?a3FpNitaeDM4VTZZZzlsS2ZNb2VDVGQ3UWVrcTQ5UFZEL1BTNlJBWUN2UVdK?=
 =?utf-8?B?WEluNGFMMS85akFNWWdmOVdaaDJkY1dCTGxqZWJuRlVTUllmZ1lYT0pTNnd2?=
 =?utf-8?B?bDJXSU5YOHh0bmVGZFZ4TmpEU2F2b01TTnlJL3dsNFZ1WUtFZjVEUHpNd3pt?=
 =?utf-8?B?QzBqSUxOUktMRWJ0ckRnZGVaYjZSekdoc09pRFA4bDdITWFHWDhSanBuNDdz?=
 =?utf-8?B?NlkzTlVWQmZlSHBOV1c2cFJqdk94Q1ExUUdSY2lXZnNmbUg4b1NqVEh4Vm5L?=
 =?utf-8?B?cGs4RjBHWnNIdUFwYWVLQ2k3ZzFwTk1pZUVhaVgxSis0dXNTblJLOTQ5REU0?=
 =?utf-8?B?V01HTzdKN2NqcnZYQm1iL1cxY25BbHgvaEpwdnRWa0MxRktXalBDa01oOUd6?=
 =?utf-8?B?YythajRMeWx3QW5MN1BzQWUyMlh2U25iOE9LZWxKTDhiQWRabW0reWJZWDhR?=
 =?utf-8?B?bG85SDVLdFJqQkZQNHBseGpFZm40cWlLY3BhcUJSczFVVk1zMkcwcnBtemJR?=
 =?utf-8?B?MjVaR3BKQzNZc0FNM3BzcEd4ODVKcE5hdHJ4Nm4yMkRtSzViamk3K01LMmcz?=
 =?utf-8?B?TFhVYlh3T0p2SWs0eFNoYUJxVSs1UHMrVUdCOFAzY25STGYyZDZtTFVLTXB4?=
 =?utf-8?B?Y2R3RVlWUFhlNnZ1clJkUXlzL1Qzek5JTlJPQU1oSFR4OXUxS1pqZVpBU05O?=
 =?utf-8?B?VnRZOFB4WGExb0huWVpmODR0VEpNYW4xYUg5a1VNTEtweGR1SHBTeGtMVFRk?=
 =?utf-8?B?bkZMT0VEVDJTSXBVRE5vemxlR2l5RDR4c2hHRk5VeTcxdWhHVnNkdUtwa1hE?=
 =?utf-8?B?RTJTNW04MVZPZjhZRG5xTXdtOWhIV0NnSVM2cWwwRjJPUEN2MTRPUXJEOXNN?=
 =?utf-8?B?Y1Fxd2lEYVI0eitTT0RzZlo2N0t5YzI5U05BVjhxZzIyWTRHY2pybUR0N3RI?=
 =?utf-8?B?ajZUVE9jZUJRSjVKYnFnTEFDWFM1U0RJQjFJbkdqSk1wcmVSckUvS0xhaXFX?=
 =?utf-8?B?UjRVZkpSblFUelZkUk5adnNFRHZjUnFpa2kzaDYzS1RyTWhsbzc1djVneFdz?=
 =?utf-8?B?TFJra2EvQVp6c1c5Ny8vVThKOG1sZkwyc2J0R29NVGt1T2lJZEdEZ3NpYytX?=
 =?utf-8?B?cWpyaWtMZitPZ0ZQL3hMZnltREE1WkZycUdmUGRaUGhyUGlmdG9mbWc4VjVT?=
 =?utf-8?B?Y3Z6MEp6bDl6RkhqSUMzWUhJQWtvYUFuRU5KZzZwbHQ4OG5GQ0hwajUxVnhL?=
 =?utf-8?B?Z1Z1TE00dTExRjlMSXg4dlg1Q3IrL2EveWMvd29GV1JudVZnM1lPTXRvY1hN?=
 =?utf-8?B?am9zc29oMmV2ZURROWMzTVNrYVlQYW4wYmREay91YStSUEVYVUpjOStXbEUz?=
 =?utf-8?B?azFYbEFhS284NzNxRjg2dnZMT3QyVnFaVDIxVmJySEQ1Z0E2Y1B0UjZJcnRa?=
 =?utf-8?B?RjVTV3cyaEZoMmZCN2RZUWtGdWp2SEt6K1MxaGhucEVMZGNoR0lQRERvR01a?=
 =?utf-8?Q?GAYAwvubRhs=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?QnRTTjIvaXg4QjBjVlNhUDhEZ0tHdTNxYWdMWjlNWTVKV1oyVzJRbmhLcldt?=
 =?utf-8?B?NHFTUyttSmFJWkFSOHViWmp1empFWGsvOElVdHFRMytIUktKZUE2dFNSRzBG?=
 =?utf-8?B?TyttYTlLTXd6L0pWZDdBV2FJWkRpVFZlM2c3U2duVEgxSWh0b1RkdjdjWEs1?=
 =?utf-8?B?a2lMNXdHVS9JL0NzQ0RBTnFRU3JXMWhYNXlOK1I4SmtBLzdzaEJuMWFjUmxS?=
 =?utf-8?B?V1dnODNJUWprMHIvRlRqaUQyWittMkcyRFZYS1VTK2pxd2FObGUyMVBydWRX?=
 =?utf-8?B?YXJtU0hja09QeXJTOHRZWkU2UGJrSDZUSytaZEZDbFpoNkdlN1MwSFJaZXFG?=
 =?utf-8?B?Q0d3cENJUVNhV1k5UExZNlpsd0pyZXoydERDRzJpbUYwNys3MlBFVjZEUW1F?=
 =?utf-8?B?Q1kyUFMwVnZnaWlZQ1ltRVo3MHZ1b203NUkrUTcvbTNzaGtLNHFhNUNFZXdY?=
 =?utf-8?B?U1J5N2pCY0p5b1ZwUFhYdSsxQzRPQnZRVGozY1FIdDhHUlJjbkhqa0ZpZjhh?=
 =?utf-8?B?aXZGOXJRUkRFVG43YVMyVUJjeXROSUkrSEFiQ1kvdWU4Y0ppZWhZTFVkYUVy?=
 =?utf-8?B?TnJCaUhxR1BWWVVwbkxtOXRRZjVNZVFiVjk3aVY4QjdvR0NIM0ZHSVF6U2FY?=
 =?utf-8?B?N1FyUnU0Wm9CZ21rV3BrM28yVVZnd2Q0WUhOQkVRdWFiOWZVV05ycDdaUVl5?=
 =?utf-8?B?VGFiQ3ZlS1NwNFBFWXVJYUZRZ0NyWmFjelQrV2JjSi9HVFNDbVJtZWZmWldr?=
 =?utf-8?B?dGVPWXJqR3NHMW9vS3lmUnA2NzVraDdOaU1xcHZHZ2l3UHNIaUZGRVZjd21H?=
 =?utf-8?B?RmtLQlU2RXBMTWh5bnhsMDdpaXExeHdWNGJGVmp2UWtjUXpFaE55V2dyTy9U?=
 =?utf-8?B?Z0ZuVCs5bzg2NzFVdVFsUytkYWJxbFdnbUd2cGRUeTBnM1JCcEh5WFhMcWR2?=
 =?utf-8?B?aklQSmlBUkZkdHlqaE1FYTZaeG1iNGZFNXlEcUovd0Z5MGxxVFk1ZUR4ODRs?=
 =?utf-8?B?K3dhbVhrWXFaQThJNk9YbUZIUS9aRjMyTE14RURhc2llditoeldtbU9sOTBv?=
 =?utf-8?B?NEQrTmtXOG9nY0tDUUhYOHl2OXlxTTIvZERUZkNhRk5hTDMxL3dsOWhTMU5C?=
 =?utf-8?B?VWhLeUlIVlJhMlhiMUdVWUtDL0x6TjQ3WDVkcGF3NldTNWI5SGxRbG5BOXRF?=
 =?utf-8?B?WTVPRzJ1eFJrZE1FcUdvdFRpU0x4SzQxdjYxTXJJbVB2MlNzVjlMbmM0WGpQ?=
 =?utf-8?B?QjI1U3ptMFEvNGs1Y0Zpb2JvZmpmZmtWK0srV3QzUnh3UGFNQmxXeXJ3ZVM5?=
 =?utf-8?B?UmJKVXNDL2wyTEsvUlZkeXJlM2lrZ050SFlLTDdraVhxTjRrMDZRWWkvY0I3?=
 =?utf-8?B?RHd4QStXVk05eVNTQ2YvQ2x0VmhHb0ovSHF3cnpqMDArM3l4SnFic0E5cExO?=
 =?utf-8?B?NThhbHBXOE1JdlFEM0tuSzFwRzJLRTRvZFBoRHdlckpEdWk1eVlabDZNUnE2?=
 =?utf-8?B?ZURTcnE5VWc1WWJyVEhER2ZoQnlQRHVkVzJZN1RORkJLVlJvUHZ1MkxaWlJK?=
 =?utf-8?B?NldQOG5KQzNtWXdKRlVwVTY3UGxRaEQ2V3p0c0hHM01PVjNycyszUlp5V2ky?=
 =?utf-8?B?em5Fcmw4eDBuSDVYZDZMZktubERsOVdnTEdQdDJGQTJMQUdMT1ZWa25ZVm9E?=
 =?utf-8?B?UEtrdks5ZUpEbkpmblNPOTg0azYrUEZMVHZDa2ZFV1gwQUdxOFZ5NUJ6YitR?=
 =?utf-8?B?U0I0bkI4aU1FYUFOUlNqdEw4aDhtRThPL1pCTHVmeDhTcW5Eb1IrR0dpTHhn?=
 =?utf-8?B?dlh6OC8vSTdnZm1MRE81bW93RFY3bEdzOEhHaWlxQTRTR3lUc3c2ZUNUemV6?=
 =?utf-8?B?TGVRMEJHa2l1cEJZR2RIdWpLZFJLWDNCand6STFFZ0haTFFYbU9JT3EvdEtH?=
 =?utf-8?B?MURLRStCUUZhRkRXL21HeEphZlExNXNWLzFtbUcyVUVNUHI3emc3UjQ1YmNt?=
 =?utf-8?B?RW1OQXlxZ2NpcnJJckZLZGs5YkQxT0pnN05OcGprS2wydE52aTRnSXR4NnZY?=
 =?utf-8?B?d2gvWkNqNDZvWVdVc1JpYWYvdHBESDJEQU9IWlU0QWdXU2dMSUtLMmkzbEMw?=
 =?utf-8?B?bW1paGwvb2tuSkR4TXN3NU95S0FNWHlhazdCaThCL1pRNmp4ZzMrKys0VEh1?=
 =?utf-8?B?d2c9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8774332d-0992-41d3-aa46-08ddb4c248ee
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2025 15:01:09.6138
 (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: 3fiNyaCHqepZsNpgtqe5Su6GD0KU5GuFKDRw5mFf6uheZCDDCQc9LktaNgqr0wZH76AUtAcFLX10XokGSH7Z6NgUB9siO9DTIYWp1VvesvM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB9914

DQpPbiAyNi8wNi8yMDI1IDE3OjQxLCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMjYuMDYuMjAy
NSAxNTowNywgT2xla3NpaSBNb2lzaWVpZXYgd3JvdGU6DQo+PiBPbiAyNi8wNi8yMDI1IDA5OjEw
LCBKYW4gQmV1bGljaCB3cm90ZToNCj4+PiBPbiAyNS4wNi4yMDI1IDIxOjU2LCBPbGVrc2lpIE1v
aXNpZWlldiB3cm90ZToNCj4+Pj4gT24gMjMvMDYvMjAyNSAxMDoxNSwgSmFuIEJldWxpY2ggd3Jv
dGU6DQo+Pj4+PiBPbiAxOS4wNi4yMDI1IDE4OjE1LCBPbGVrc2lpIE1vaXNpZWlldiB3cm90ZToN
Cj4+Pj4+PiBPbiAxOC8wNi8yMDI1IDAzOjA0LCBTdGVmYW5vIFN0YWJlbGxpbmkgd3JvdGU6DQo+
Pj4+Pj4+IE9uIFRodSwgMTIgSnVuIDIwMjUsIE9sZWtzaWkgTW9pc2llaWV2IHdyb3RlOg0KPj4+
Pj4+Pj4+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjaS5jIGIveGVuL2Fy
Y2gvYXJtL2Zpcm13YXJlL3NjaS5jDQo+Pj4+Pj4+Pj4+IGluZGV4IGUxNTIyZTEwZTIuLjhlZmQ1
NDFjNGYgMTAwNjQ0DQo+Pj4+Pj4+Pj4+IC0tLSBhL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY2ku
Yw0KPj4+Pj4+Pj4+PiArKysgYi94ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NpLmMNCj4+Pj4+Pj4+
Pj4gQEAgLTEyNiw2ICsxMjYsNDMgQEAgaW50IHNjaV9hc3NpZ25fZHRfZGV2aWNlKHN0cnVjdCBk
b21haW4gKmQsIHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqZGV2KQ0KPj4+Pj4+Pj4+PiAgICAgICAg
ICAgcmV0dXJuIDA7DQo+Pj4+Pj4+Pj4+ICAgICAgIH0NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4g
K2ludCBzY2lfZG9fZG9tY3RsKHN0cnVjdCB4ZW5fZG9tY3RsICpkb21jdGwsIHN0cnVjdCBkb21h
aW4gKmQsDQo+Pj4+Pj4+Pj4+ICsgICAgICAgICAgICAgICAgICBYRU5fR1VFU1RfSEFORExFX1BB
UkFNKHhlbl9kb21jdGxfdCkgdV9kb21jdGwpDQo+Pj4+Pj4+Pj4+ICt7DQo+Pj4+Pj4+Pj4+ICsg
ICAgc3RydWN0IGR0X2RldmljZV9ub2RlICpkZXY7DQo+Pj4+Pj4+Pj4+ICsgICAgaW50IHJldCA9
IDA7DQo+Pj4+Pj4+Pj4+ICsNCj4+Pj4+Pj4+Pj4gKyAgICBzd2l0Y2ggKCBkb21jdGwtPmNtZCAp
DQo+Pj4+Pj4+Pj4+ICsgICAgew0KPj4+Pj4+Pj4+PiArICAgIGNhc2UgWEVOX0RPTUNUTF9hc3Np
Z25fZGV2aWNlOg0KPj4+Pj4+Pj4+PiArICAgICAgICByZXQgPSAtRU9QTk9UU1VQUDsNCj4+Pj4+
Pj4+PiBBcmUgeW91IHN1cmUgLUVPUE5PVFNVUFAgaXMgdGhlIHJpZ2h0IGVycm9yIGNvZGUgZm9y
IHRoZSAzIGNoZWNrcyBiZWxvdz8NCj4+Pj4+Pj4+IFRoZSAtRU9QTk9UU1VQUCBjb2RlIGlzIHVz
ZWQgYmVjYXVzZSB0aGlzIGlzIHBhcnQgb2YgYSBjaGFpbmVkIGNhbGwgYWZ0ZXINCj4+Pj4+Pj4+
IGlvbW11X2RvX2RvbWN0bCwgYXMgc3RhdGVkIGluIHhlbi9jb21tb24vZG9tY3RsLmM6ODU5LiBU
aGUNCj4+Pj4+Pj4+IFhFTl9ET01DVExfYXNzaWduX2RldmljZQ0KPj4+Pj4+Pj4gY2FsbCBpcyBl
eHBlY3RlZCB0byBoYW5kbGUgYW55IERUIGRldmljZSwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIHRo
ZSBEVA0KPj4+Pj4+Pj4gZGV2aWNlIGlzDQo+Pj4+Pj4+PiBwcm90ZWN0ZWQgYnkgYW4gSU9NTVUg
b3IgaWYgdGhlIElPTU1VIGlzIGRpc2FibGVkLg0KPj4+Pj4+Pj4gVGhlIGZvbGxvd2luZyBjYXNl
cyBhcmUgY29uc2lkZXJlZDoNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAxLiBJT01NVSBQcm90ZWN0ZWQg
RGV2aWNlIChTdWNjZXNzKQ0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IElmIHRoZSBkZXZpY2UgaXMgcHJv
dGVjdGVkIGJ5IHRoZSBJT01NVSBhbmQgaW9tbXVfZG9fZG9tY3RsIHJldHVybnMgMCwNCj4+Pj4+
Pj4+IHdlIGNvbnRpbnVlDQo+Pj4+Pj4+PiBwcm9jZXNzaW5nIHRoZSBEVCBkZXZpY2UgYnkgY2Fs
bGluZyBzY2lfZG9fZG9tY3RsLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IDIuIElPTU1VIERpc2FibGVk
ICgtRU9QTk9UU1VQUCBmcm9tIGlvbW11X2RvX2RvbWN0bCkNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBJ
ZiBpb21tdV9kb19kb21jdGwgcmV0dXJucyAtRU9QTk9UU1VQUCwgaW5kaWNhdGluZyB0aGF0IHRo
ZSBJT01NVSBpcw0KPj4+Pj4+Pj4gZGlzYWJsZWQsDQo+Pj4+Pj4+PiB3ZSBzdGlsbCBwcm9jZWVk
IHRvIGNhbGwgc2NpX2RvX2RvbWN0bC4NCj4+Pj4+Pj4gT0sgdGhpcyBtYWtlcyBzZW5zZS4gIEkg
dGhpbmsgaXQgaXMgT0sgdG8gaGF2ZSBhIHNwZWNpYWwgZXJyb3IgY29kZSB0bw0KPj4+Pj4+PiBz
YXkgInRoZSBJT01NVSBpcyBkaXNhYmxlZCIgYnV0IEkgZG9uJ3Qga25vdyBpZiBpdCBpcyBhIGdv
b2QgaWRlYSB0byB0cnkNCj4+Pj4+Pj4gdG8gdXNlIC1FT1BOT1RTVVBQIGZvciB0aGF0LiAtRU9Q
Tk9UU1VQUCBjb3VsZCBtZWFuIGEgaHlwZXJ2aXNvcg0KPj4+Pj4+PiBjb25maWd1cmF0aW9uIHdp
dGggZG9tY3RsIGRpc2FibGVkLCBmb3IgaW5zdGFuY2UuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEl0IG1p
Z2h0IGJlIHdpc2VyIHRvIHVzZSBhIGRpZmZlcmVudCBlcnJvciBjb2RlLiBNYXliZSBFTk9FTlQ/
DQo+Pj4+Pj4+DQo+Pj4+Pj4gSSBzZWUgdGhhdCBpbiB0aGUgZm9sbG93aW5nIGNvbW1pdDoNCj4+
Pj4+Pg0KPj4+Pj4+IDcxZTYxN2E2YjggKHVzZSBpc19pb21tdV9lbmFibGVkKCkgd2hlcmUgYXBw
cm9wcmlhdGUuLi4sIDIwMTktMDktMTcpDQo+Pj4+Pj4NCj4+Pj4+PiAtRU5PU1lTIHJldHVybiBj
b2RlIHdhcyBjaGFuZ2VkIHRvIC1FT1BOT1RTVVBQIGluIGlvbW11X2RvX2RvbWN0bC4NCj4+Pj4+
Pg0KPj4+Pj4+IEl0J3Mgbm90IGNsZWFyIHRvIG1lIHdoeSB0aGlzIHdhcyBkb25lIGZyb20gdGhl
IGNvbW1pdCBkZXNjcmlwdGlvbi4NCj4+Pj4+IFRoaXMgaGFzIGJlZW4gZGlzY3Vzc2VkIG1hbnkg
dGltZXMgZWxzZXdoZXJlLiBNYW55IG9mIG91ciBFTk9TWVMgdXNlcyBhcmUNCj4+Pj4+IHNpbXBs
eSB3cm9uZy4gRU5PU1lTIGhhcyB2ZXJ5IGxpbWl0ZWQgYXBwbGljYWJpbGl0eTogVW5hdmFpbGFi
aWxpdHkgb2YgYQ0KPj4+Pj4gdG9wLWxldmVsIGh5cGVyY2FsbCAob3JpZ2luYWxseTogc3lzY2Fs
bCkuDQo+Pj4+Pg0KPj4+PiBXaGF0IGlzIHlvdXIgb3BpbmlvbiBhYm91dCBjaGFuZ2luZyBpdCB0
byAtRU5PRU5UIHRvIHNheSAidGhlIElPTU1VIGlzDQo+Pj4+IGRpc2FibGVkIiBhcyBTdGVmYW5v
IHN1Z2dlc3RlZCBpbiBbMF0/DQo+Pj4+DQo+Pj4+IFswXTogaHR0cHM6Ly9saXN0cy54ZW4ub3Jn
L2FyY2hpdmVzL2h0bWwveGVuLWRldmVsLzIwMjUtMDYvbXNnMDEyMzMuaHRtbA0KPj4+IFRvIG1l
LCBFTk9FTlQgaXMgY2xvc2VyIHRvIEVOT0RFViwgYW5kIGhlbmNlIG5vdCBvdmVybHkgYXBwbGlj
YWJsZSBoZXJlLg0KPj4+IElmIHlvdSB3YW50IHRvIGF2b2lkIEVPUE5PVFNVUFAgZm9yIHdoYXRl
dmVyIHJlYXNvbiwgaG93IGFib3V0IEVOWElPIG9yDQo+Pj4gRUlPPyAoRVBFUk0gbWlnaHQgYWxz
byBiZSBhbiBvcHRpb24sIGJ1dCB3ZSBhc3NpZ24gdGhhdCBhIGRpZmZlcmVudA0KPj4+IG1lYW5p
bmcgZ2VuZXJhbGx5LikNCj4+IE1heWJlIC1FTk9ERVYgaXMgYSBiZXR0ZXIgY2hvaWNlIGJlY2F1
c2UgaW9tbXVfZG9fcGNpX2RvbWN0bCBhbmQNCj4+IGlvbW11X2RvX2R0X2RvbWN0bCByZXR1cm4g
dGhpcw0KPj4NCj4+IGNvZGUgd2hlbiBzb21lIGZlYXR1cmUgaXMgbm90IHN1cHBvcnRlZC4NCj4g
V2hhdCBmZWF0dXJlIGFyZSB5b3UgdGFsa2luZyBhYm91dD8gQWxsIEkgc2VlIGluIHRoZSBmb3Jt
ZXIgaXMNCj4NCj4gICAgICAgICAgcmV0ID0gLUVOT0RFVjsNCj4gICAgICAgICAgaWYgKCBkb21j
dGwtPnUuYXNzaWduX2RldmljZS5kZXYgIT0gWEVOX0RPTUNUTF9ERVZfUENJICkNCj4gICAgICAg
ICAgICAgIGJyZWFrOw0KPg0KPiBhbmQgdGhlcmUgLUVOT0RFViBpcyBxdWl0ZSBhcHByb3ByaWF0
ZS4NCg0KSSB3YXMgdGFsa2luZyBhYm91dCB0aGUgZm9sbG93aW5nIGNvZGUgaW4gaW9tbXVfZG9f
cGNpX2RvbWN0bDoNCg0KICAgICByZXQgPSAtRU5PREVWOw0KICAgICAgICAgaWYgKCBkb21jdGwt
PnUuYXNzaWduX2RldmljZS5kZXYgIT0gWEVOX0RPTUNUTF9ERVZfUENJICkNCiAgICAgICAgICAg
ICBicmVhazsNCg0KU29ycnksIEkgbWlzaW50ZXJwcmV0ZWQgdGhpcy4NCg0KPj4gSSB0aGluayAt
RUlPIG9yIC1FTlhJTyBhcmVu4oCZdCBzdWl0YWJsZSBoZXJlIHNpbmNlIHdl4oCZcmUgcGxhbm5p
bmcgdG8gc2VuZA0KPj4gdGhpcyBtZXNzYWdlIHdoZW4gdGhlIElPTU1VIGlzIGRpc2FibGVkLg0K
PiBXZWxsLCBJIGRvbid0IGxpa2UgdGhvc2UgdHdvIHZlcnkgbXVjaCBlaXRoZXIgZm9yIHRoZSB1
c2UgaGVyZSwgYnV0IEkgc3RpbGwNCj4gdmlldyB0aGVtIGFzIGJldHRlciB0aGFuIEVOT0VOVC4N
Cj4NCkkgdGhpbmsgSSBjb3VsZCB1c2UgLUVOWElPIHNpbmNlIGl0IGhhcyB0aGUgZm9sbG93aW5n
IGNvbW1lbnQ6DQogICAgIC8qIE5vIHN1Y2ggZGV2aWNlIG9yIGFkZHJlc3MgKi8NCkl0IHNlZW1z
IHRvIGJlIHN1aXRhYmxlIGZvciBvdXIgY2FzZS4NCg0KV0JSLA0KDQpPbGVrc2lpLg0K


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 15:01:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 15:01:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026616.1401802 (Exim 4.92)
	(envelope-from )
	id 1uUo6L-0008VY-QG; Thu, 26 Jun 2025 15:01:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026616.1401802; Thu, 26 Jun 2025 15:01: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 1uUo6L-0008VR-NV; Thu, 26 Jun 2025 15:01:21 +0000
Received: by outflank-mailman (input) for mailman id 1026616;
 Thu, 26 Jun 2025 15:01: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 1uUo6K-0008Tc-Vi
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 15:01:20 +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 6a3a5e8c-529e-11f0-b894-0df219b8e170;
 Thu, 26 Jun 2025 17:01:19 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3a6d1369d4eso608139f8f.2
 for ; Thu, 26 Jun 2025 08:01:19 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-749c887130fsm7279456b3a.145.2025.06.26.08.01.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 26 Jun 2025 08:01:17 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6a3a5e8c-529e-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750950078; x=1751554878; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=/XDDULvEyGusIDzXVz0upl5NaEZ+iog+pE4K6CNqNTY=;
        b=NWjz50ps2xvVwQOrXie0ephK6aEHnen/1IR2GPrT8XGpVlfOlujdDyxMMJyYVNFq8S
         wFGTN+q9otI3014K4ALXVVDpqPkbNYTl33Ilfd/wETTz1XKRIBctY+DuaKORrmuFfzUx
         fQvicNcWl48z5OMJuoPTG4jvfudPCNlf4ud2pgKFpHycE0cODceIl0gavu8ZH4Jqm8fu
         492YAJh5nb5ToHZ9aA1xEGNmdqpL/6ZSEd+377qeC77u/mHxQku4p1ONlIyEUMoA1OU/
         5YCHheIB2vbUGM22VhxjLEj0Rt1eEK2F9RFCdXyFm7Hz7JTXOoDyi3okcaJmLTP0tf8M
         /lEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750950078; x=1751554878;
        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=/XDDULvEyGusIDzXVz0upl5NaEZ+iog+pE4K6CNqNTY=;
        b=puX4rP/afRDM8OtXeiNTlJHK/+0R7iLj7M80jiyIaTvqwXWCoNgEoA4YYwaHoY850i
         Q8UjJNh2kePri1jti3RpaZOeVZtCMKcieT7uS18sA5bWpGIxLBMoqL7r7KD5WawUVGlz
         UOhz1IpksWclXdmYQlu/24maEbLtFCsFRuWy6hTf1dj8AL24nkS6ZPaWdtGB9gki7PRC
         OiCXRG6/8eT3TQ6G3i1sofKpbFWd4C4rJx42b7EKff4i/jLcMlOg196sqsoHR4sZFQSU
         hjyScVek/IU47VuBrJMQrl+zmck3aD+G9nkqZUXWvW80sE+umex0DZC4UKWGO8lsOEdj
         gOfg==
X-Forwarded-Encrypted: i=1; AJvYcCUsOWqkCxRli9WArf1F6x7+u/SGQg9FyiBaDOWy+TTICk9RZpkix1r1Ub3OnQ5Nc7gJLp2kMXL4H18=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwOaVLiyOnurslQK6Jy7+5SQubAN57ofbQVYEMp6XqWuUViH378
	mJkWeCVYGaUFyN1FL7LTleTAVuMs3tcOpix4UkqW8mOjpEnDNNjeO74lxjandmW2dw==
X-Gm-Gg: ASbGncvR52zxTak75XkzLOvVrlERekEHltIYgtAl1pqJ4VPwcO48CZe9AzSAgizrtjY
	PjCn82QuBfxi2Xgr72Hc1waYTshEz9X0TLJU30/XHL4TVrF8EAw1MSgSI7emnIy/Z1EwEG8ZHUL
	57jWfI6i/VxidEZ44XwaO5livgw94n/5wlIS3iGyvf87dMOTu+Se0M+fF/F38VY5EYS+W4bIn9A
	ZOh2evPZftXeqjdHVpvy367izZOZqW3+mfzP+bzmI8owspYC1/LCGDnoiNOlCj7lrgEQFTeQexG
	oSk3k6rfhp1AeSxcJ9rHeVgRQrRFjm5heg0HLX9zNIRkRzlwTSh0mNPGWZjqCSEz/isdY7FTuma
	LZ4l+AeO+XJszM2hU1dpuToA8atqZhyiQMv3UdMxW4b9ktFI=
X-Google-Smtp-Source: AGHT+IGPN95JPwhg9eSyVZ+BszLTzRuZYUSCyj+KA4MRUXCR0Hx0CzvIizvpS+boLm24X3O6twjBAQ==
X-Received: by 2002:adf:b647:0:b0:3a5:2d42:aa25 with SMTP id ffacd0b85a97d-3a6f30a9d15mr2751253f8f.50.1750950077933;
        Thu, 26 Jun 2025 08:01:17 -0700 (PDT)
Message-ID: 
Date: Thu, 26 Jun 2025 17:01:09 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 3/3] xen/efi: Update error flow for read_file function
To: Frediano Ziglio 
Cc: "Daniel P. Smith" ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , xen-devel@lists.xenproject.org
References: <20250626131059.61894-1-frediano.ziglio@cloud.com>
 <20250626131059.61894-4-frediano.ziglio@cloud.com>
 <9d64c239-d6cc-4eb5-b180-a5034bedcfdb@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 26.06.2025 16:57, Frediano Ziglio wrote:
> On Thu, Jun 26, 2025 at 3:50 PM Jan Beulich  wrote:
>>
>> On 26.06.2025 15:41, Frediano Ziglio wrote:
>>> On Thu, Jun 26, 2025 at 2:31 PM Jan Beulich  wrote:
>>>>
>>>> On 26.06.2025 15:10, Frediano Ziglio wrote:
>>>>> --- a/xen/common/efi/boot.c
>>>>> +++ b/xen/common/efi/boot.c
>>>>> @@ -792,6 +792,8 @@ static bool __init read_file(EFI_FILE_HANDLE dir_handle, CHAR16 *name,
>>>>>
>>>>>      if ( !name )
>>>>>          PrintErrMesg(L"No filename", EFI_OUT_OF_RESOURCES);
>>>>> +
>>>>> +    what = L"Open";
>>>>>      if ( dir_handle )
>>>>>          ret = dir_handle->Open(dir_handle, &FileHandle, name,
>>>>>                                 EFI_FILE_MODE_READ, 0);
>>>>> @@ -800,54 +802,58 @@ static bool __init read_file(EFI_FILE_HANDLE dir_handle, CHAR16 *name,
>>>>>      if ( file == &cfg && ret == EFI_NOT_FOUND )
>>>>>          return false;
>>>>>      if ( EFI_ERROR(ret) )
>>>>> -        what = L"Open";
>>>>> -    else
>>>>> -        ret = FileHandle->SetPosition(FileHandle, -1);
>>>>> +        goto fail;
>>>>> +
>>>>> +    what = L"Seek";
>>>>> +    ret = FileHandle->SetPosition(FileHandle, -1);
>>>>>      if ( EFI_ERROR(ret) )
>>>>> -        what = what ?: L"Seek";
>>>>> -    else
>>>>> -        ret = FileHandle->GetPosition(FileHandle, &size);
>>>>> +        goto fail;
>>>>> +
>>>>> +    what = L"Get size";
>>>>> +    ret = FileHandle->GetPosition(FileHandle, &size);
>>>>>      if ( EFI_ERROR(ret) )
>>>>> -        what = what ?: L"Get size";
>>>>> -    else
>>>>> -        ret = FileHandle->SetPosition(FileHandle, 0);
>>>>> +        goto fail;
>>>>> +
>>>>> +    what = L"Seek";
>>>>> +    ret = FileHandle->SetPosition(FileHandle, 0);
>>>>>      if ( EFI_ERROR(ret) )
>>>>> -        what = what ?: L"Seek";
>>>>> -    else
>>>>> -    {
>>>>> -        file->addr = min(1UL << (32 + PAGE_SHIFT),
>>>>> -                         HYPERVISOR_VIRT_END - DIRECTMAP_VIRT_START);
>>>>> -        ret = efi_bs->AllocatePages(AllocateMaxAddress, EfiLoaderData,
>>>>> -                                    PFN_UP(size), &file->addr);
>>>>> -    }
>>>>> +        goto fail;
>>>>> +
>>>>> +    what = L"Allocation";
>>>>> +    file->addr = min(1UL << (32 + PAGE_SHIFT),
>>>>> +                     HYPERVISOR_VIRT_END - DIRECTMAP_VIRT_START);
>>>>> +    ret = efi_bs->AllocatePages(AllocateMaxAddress, EfiLoaderData,
>>>>> +                                PFN_UP(size), &file->addr);
>>>>>      if ( EFI_ERROR(ret) )
>>>>> -        what = what ?: L"Allocation";
>>>>> -    else
>>>>> -    {
>>>>> -        file->need_to_free = true;
>>>>> -        file->size = size;
>>>>> -        handle_file_info(name, file, options);
>>>>> +        goto fail;
>>>>>
>>>>> -        ret = FileHandle->Read(FileHandle, &file->size, file->str);
>>>>> -        if ( !EFI_ERROR(ret) && file->size != size )
>>>>> -            ret = EFI_ABORTED;
>>>>> -        if ( EFI_ERROR(ret) )
>>>>> -            what = L"Read";
>>>>> -    }
>>>>> +    file->need_to_free = true;
>>>>> +    file->size = size;
>>>>> +    handle_file_info(name, file, options);
>>>>>
>>>>> -    if ( FileHandle )
>>>>> -        FileHandle->Close(FileHandle);
>>>>> +    what = L"Read";
>>>>> +    ret = FileHandle->Read(FileHandle, &file->size, file->str);
>>>>> +    if ( !EFI_ERROR(ret) && file->size != size )
>>>>> +        ret = EFI_ABORTED;
>>>>> +    if ( EFI_ERROR(ret) )
>>>>> +        goto fail;
>>>>>
>>>>> -    if ( what )
>>>>> -    {
>>>>> -        PrintErr(what);
>>>>> -        PrintErr(L" failed for ");
>>>>> -        PrintErrMesg(name, ret);
>>>>> -    }
>>>>> +    FileHandle->Close(FileHandle);
>>>>>
>>>>>      efi_arch_flush_dcache_area(file->ptr, file->size);
>>>>>
>>>>>      return true;
>>>>> +
>>>>> +fail:
>>>>
>>>> Nit: Style (see ./CODING_STYLE).
>>>>
>>>
>>> What specifically? I checked the indentation and it's 4 spaces. if-s
>>> are spaced correctly. About labels I didn't find much on CODING_STYLE
>>> so I opened 3/4 files and most of them are indented with no spaces
>>> (they start at column 1).
>>
>> You didn't search for the word "label" then, did you? Quote:
>>
> 
> I did, I probably mis-typed it.
> 
>> 'Due to the behavior of GNU diffutils "diff -p", labels should be
>>  indented by at least one blank.  Non-case labels inside switch() bodies
>>  are preferred to be indented the same as the block's case labels.'
> 
> I suppose labels should be indented less than the code they refer to,
> so in this case from 1 to 3 spaces. I supposed 2 would be the best
> option.

Except that I think 1 is what we commonly use (levaing aside the many bad
examples that we still have).

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 15:03:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 15:03:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026633.1401811 (Exim 4.92)
	(envelope-from )
	id 1uUo84-0001AQ-4L; Thu, 26 Jun 2025 15:03:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026633.1401811; Thu, 26 Jun 2025 15: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 1uUo84-0001AH-1b; Thu, 26 Jun 2025 15:03:08 +0000
Received: by outflank-mailman (input) for mailman id 1026633;
 Thu, 26 Jun 2025 15:03: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 1uUo82-0001A8-MJ
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 15:03:06 +0000
Received: from fhigh-a8-smtp.messagingengine.com
 (fhigh-a8-smtp.messagingengine.com [103.168.172.159])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a6385bf5-529e-11f0-b894-0df219b8e170;
 Thu, 26 Jun 2025 17:03:00 +0200 (CEST)
Received: from phl-compute-03.internal (phl-compute-03.phl.internal
 [10.202.2.43])
 by mailfhigh.phl.internal (Postfix) with ESMTP id E5F541400031;
 Thu, 26 Jun 2025 11:02:58 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-03.internal (MEProxy); Thu, 26 Jun 2025 11:02:58 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 26 Jun 2025 11:02:57 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a6385bf5-529e-11f0-b894-0df219b8e170
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=1750950178;
	 x=1751036578; bh=JNKituUeUdPKycoRaCS6tsxKpHjrP5kr9AX5sCJlG2o=; b=
	AR3IGma44pqJ9YfFSPNR+ah4Qq7Vzt/H1JdIo8ulRc2MnMygLYjnokYzgXU5CmCC
	S2Gi44bdyx18ZSRTAg3vTPXnCWYU21vmBOPrM/958EEmUgD4U4cHMLpdD/HskUwJ
	CEO5FRIXWbuH2TLhbrUXuh6Ar0YkR8gMBiiwl4B/tcXyJCA1hjfKRpYgO8rGHVnI
	3BEjf47KLj5lM8rq5f8Ox61HRuZ+kjooIolUd2ZkwKDVv4lHJcyICh1/oPILfLPl
	/Tn1B/4bHRpc2Qm4FhMYhoiYRaSXNbLbRVxQX824QN8Gi2HyD/6sIDDYqh2MRLZL
	RlEaCG4xvoAKhTj1DOAYPQ==
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=
	1750950178; x=1751036578; bh=JNKituUeUdPKycoRaCS6tsxKpHjrP5kr9AX
	5sCJlG2o=; b=Rea3kE3/VpHeFV54ukdO8odFCAEvUjlzjMZ7L7rBfTkrqadrlgf
	VaPd60MWtjv2fOh9ZDRlUHEzXE1gGn++fa+36WwUJK5MhPwFue1o3CZDUT1xdpzB
	8YyR/GptLmfsoZX5n+eBv8jSReOYff/ov4CbM8lsLWJCXR3u9Yh4VrKCiZKFG3qZ
	hUuzeGcS8dl1LgQXru52ocSmzCzVkpk0TuDn3z6UDmR5Ns5HgmjY8dJuA8clctS7
	YDtC/jYiSyIFFnn0hRdoDaL+auX4BTQeSGMeJCpEAqhlKYPcNNr5oV4/4i9EwfSo
	F+zLJJAMNIofR7mu3gtkoR7lxWQAeTu2RzA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdeglecutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegrihhl
    ohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpe
    ffhffvvefukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghkucforghr
    tgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhishhisg
    hlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefgleegveffkeei
    keejjefhudelhedtgeefieefueeitefgvdeiheeuledvffefvdenucffohhmrghinhepgh
    hnuhdrohhrghdpghhithhlrggsrdgtohhmpdhqvghmuhdqshhmohhkvgdqgiekiedqieeg
    qdgvfhhiqdhukhhirdhshhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh
    grihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggs
    rdgtohhmpdhnsggprhgtphhtthhopeegpdhmohguvgepshhmthhpohhuthdprhgtphhtth
    hopehfrhgvughirghnohdriihighhlihhosegtlhhouhgurdgtohhmpdhrtghpthhtohep
    gigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdhrtghpth
    htohepughpshhmihhthhesrghpvghrthhushhsohhluhhtihhonhhsrdgtohhmpdhrtghp
    thhtohepjhgsvghulhhitghhsehsuhhsvgdrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Thu, 26 Jun 2025 17:02:54 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Frediano Ziglio 
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" ,
	Jan Beulich 
Subject: Re: [PATCH 0/2] xen/efi: Make boot more flexible, especially with
 GRUB2
Message-ID: 
References: <20250624083157.9334-1-frediano.ziglio@cloud.com>
 
 
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="f4hgJwe7T6D4GLZx"
Content-Disposition: inline
In-Reply-To: 


--f4hgJwe7T6D4GLZx
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 26 Jun 2025 17:02:54 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Frediano Ziglio 
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" ,
	Jan Beulich 
Subject: Re: [PATCH 0/2] xen/efi: Make boot more flexible, especially with
 GRUB2

On Thu, Jun 26, 2025 at 09:12:53AM +0100, Frediano Ziglio wrote:
> On Wed, Jun 25, 2025 at 9:26=E2=80=AFPM Marek Marczykowski-G=C3=B3recki
>  wrote:
> >
> > On Tue, Jun 24, 2025 at 09:38:42AM +0100, Frediano Ziglio wrote:
> > > On Tue, Jun 24, 2025 at 9:32=E2=80=AFAM Frediano Ziglio
> > >  wrote:
> > > >
> > > > The combination of GRUB2, EFI and UKI allows potentially more flexi=
bility.
> > > > For instance is possible to load xen.efi from a no ESP partition le=
aving
> > > > a boot loader like GRUB2 taking care of the file loading.
> > > > This however requires some changes in Xen to be less restrictive.
> > > > Specifically for GRUB2 these changes allows the usage of "chainload=
er"
> > > > command with UKI and reading xen.efi from no ESP (so no DeviceHandle
> > > > set) and usage of "linux" and "initrd" commands to load separately
> > > > the kernel (embedding using UKI) and initrd (using LoadFile2 protoc=
ol).
> > >
> > > I was forgetting. If somebody wants to test "linux" and "initrd"
> > > command with these changes be aware that GRUB currently has a problem
> > > passing arguments, I posted a patch, see
> > > https://lists.gnu.org/archive/html/grub-devel/2025-06/msg00156.html.
> > > I also have a workaround for this issue in xen but it would be better
> > > to have a fix in GRUB.
> >
> > Can you tell more how to test this, especially the second variant? When
> > trying to use GRUB linux or linuxefi commands on xen.efi, I get "invalid
> > magic number" error.
> >
>=20
> That's weird.
>=20
> Be the way. As usual I have a super complicated script that does everythi=
ng.
>=20
> But to simplify:
> - I compile xen (plain upstream plus my patches) with "make -C
> ~/work/xen/xen -j O=3Dnormal MAP"

Is there any that would be related to the "invalid magic" error? IIUC
without your patches options will be mangled, but I don't think I get
this far.

> - output xen.efi in "~/work/xen/xen/normal/xen.efi"
> - add configuration and kernel with "./add_sections xen.efi
> xen.unified.efi .config xen.cfg .kernel vmlinuz-xen"
> - boot using patched Grub (or patched Xen, to handle command line, if
> you don't care about command line you can use a stock one), the menu
> entry is
>=20
> menuentry 'XenServer (Serial)' {
>         search --label --set root EFI-BOOT
>         linux /boot/xen.unified.efi -- com1=3D115200,8n1
> console=3Dcom1,vga dom0_mem=3D1232M,max:1232M watchdog dom0_max_vcpus=3D1=
-4
> crashkernel=3D256M,below=3D4G -- root=3DLABEL=3Droot-qjhppe ro nolvm
> hpet=3Ddisable console=3Dtty0 console=3Dhvc0
>         initrd /boot/initrd.img
> }

All looks quite similar. FWIW my setup is:
https://gitlab.com/xen-project/people/marmarek/xen/-/blob/test-uki/automati=
on/scripts/qemu-smoke-x86-64-efi-uki.sh?ref_type=3Dheads

Booting such UKI from OVMF directly works, as well as with
"chainloader" grub command:

https://gitlab.com/xen-project/people/marmarek/xen/-/pipelines/1891308263

CI uses Grub 2.06 from Debian, but I get the same result with 2.12 from
Fedora too.

>=20
> xen.cfg file:
> ----------
> [global]
> default=3Dxen
>=20
> [xen]
> ----------
>=20
> add_sections file:
> ----------
> #!/usr/bin/env perl
> use strict;
>=20
> die if $#ARGV < 1;
> my $in =3D shift @ARGV;
> my $out =3D shift @ARGV;
>=20
> my $max =3D 0;
> open(IN, "objdump -h $in |") or die;
> while () {
>         next if !/^\s*\d+\s+\S+\s+([0-9a-f]+)\s+([0-9a-f]+)\s+/;
>         my $val =3D hex($1) + hex($2);
>         $max =3D $val if $val > $max;
> }
> close(IN);
>=20
> sub up($) {
>         my $n =3D shift;
>         return ($n + 4095) & -4096;
> }
>=20
> my @args =3D ('objcopy');
>=20
> my $start =3D up($max);
> while ($#ARGV >=3D 1) {
>         my $name =3D shift;
>         my $fn =3D shift;
>         push @args, '--add-section', "$name=3D$fn";
>         push @args, '--change-section-vma', sprintf("%s=3D%#x", $name, $s=
tart);
>         $start +=3D -s $fn;
>         $start =3D up($start);
> }
> push @args, $in, $out;
> print "Executing @args\n";
> system(@args) =3D=3D 0 || die "Error!";
> ----------
>=20
> My script creates the initrd, builds a full disk for Qemu and launches
> Qemu too with specific options.
>=20
> Frediano

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

--f4hgJwe7T6D4GLZx
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmhdYSAACgkQ24/THMrX
1yz2/Af/bZ9rJzhMGKYOuWLllBLQQj1vZrLMSvyPU2ae7uwUupuMcEJ/nkfrguNm
Gsq7RYM2AL7B0i3xizwWF/idND7Po5dwUnFvjS209DKeoABQ+bAhc33Y43CGbWAj
/1AVMtLAXIMRvMc86aqekPh1lK6o1wgSXYY/PJ/r1ZU5CsQB+3W1maCbU8BwyOU0
2S++KWWbAViGkjVo/hnRVPvjHHG6jEc+X9eP506pE7/0Y5Qmp84lFSP2tOLd0LT2
sNB6RHWIJ7qGZHYEATyw8dqGx95xhITPYgtt/pokggi7kEtka42DtVs2jhQosU3Z
yE0SbyKrRFZPyqiGAdoq+Ik4rxu/NQ==
=ZmLQ
-----END PGP SIGNATURE-----

--f4hgJwe7T6D4GLZx--


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 15:07:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 15:07:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026640.1401822 (Exim 4.92)
	(envelope-from )
	id 1uUoBx-0001kp-Jv; Thu, 26 Jun 2025 15:07:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026640.1401822; Thu, 26 Jun 2025 15: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 1uUoBx-0001ki-GV; Thu, 26 Jun 2025 15:07:09 +0000
Received: by outflank-mailman (input) for mailman id 1026640;
 Thu, 26 Jun 2025 15:07: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 1uUoBw-0001kc-1c
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 15:07:08 +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 39a490b0-529f-11f0-a30f-13f23c93f187;
 Thu, 26 Jun 2025 17:07:07 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3a510432236so885578f8f.0
 for ; Thu, 26 Jun 2025 08:07:07 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23abe3db391sm375525ad.139.2025.06.26.08.06.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 26 Jun 2025 08:07:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 39a490b0-529f-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750950426; x=1751555226; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=1oPywFUyYv/fTsXTDWp8CyF7m0n1Bg6cJujbKlNGHO0=;
        b=IIMWI/5bAdYmQKohB0lfpN933LZ71uz/gPoV7oHaC8WrTeEwi0hLwy4Swb2DA8n33G
         LcoYK36P+CLj3gsKDOevyb4CNGZbp3qwj7BzmH5Gv4h1iyG17jahdBUCi2GJXFIIZsum
         p8XdrR3NVbnO7Ip5MLftQLzKEy+IPbyrhm93fQGt1Lz9mqb37gVmy2c1rQ2nX8KTwCbD
         0T9ifvfe/kUogGYeCbDibOJzWCbLF2ArXbfggl9FjVTPngGqp5FlyPbvY2F5ixqcMnn0
         KecIjCdneQ+MwIMqZc58xzyI8Y+WsnhqgYzhKixlU/nWvO38VhrNVNOcsf6e0WgKZOPI
         LRPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750950426; x=1751555226;
        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=1oPywFUyYv/fTsXTDWp8CyF7m0n1Bg6cJujbKlNGHO0=;
        b=Pcmhv1Fmbdi9vWaNSiH2IabeEIrbVBiQBXeh4nIFXh5p8nHV8OrVBwPxSb4mnYwB/W
         Mil5ahjgRBghhm6ua6OLl03ng3mnoan4hpyfFFdglzGLDIgz0L6YRF0TdjJYF/3YIoyB
         WmLiZy+ilSiDsBeTzUSx/GbL5er9fkilmGsgqIdZXXIaB1gaZJLvyYv+19lLVhBcD6uv
         jUF81AmHn5r0wLnqU98vzAS7UGsL1yAIlhkB3CDPVo/AI+Du6sLge0HlzsvaXlsvcVFA
         3qbt8vz1aFNNo2JeoPW7vBuppYb64X4oVA18veyBEaiGR/gb4JDRdSY+8iTa6y8b6fMu
         ydNw==
X-Forwarded-Encrypted: i=1; AJvYcCU3Rj2NqGFEDjdChucol5i5pj96us9BN+bOP+xeLghp1xPm8Bg4eLDLXHhu9CZJYGwE1Y1FyLybUS8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy6LuuLi3mTwBMOKE3I26dskp/E1rQBf2yX8XbkvXmCcLDxGqBD
	BtpIjRNny5RoBd/x3pZNfK/TgjWzA73+YKPavo4zbUlMplAsUgNVeqCIyZjAA5E+3g==
X-Gm-Gg: ASbGncusgjOT2QoEuRm2m2ldk/CgNHKdONe3rx87WgmiqTacHxg8y7CXbeHhhlecJI5
	y+ZwFfrVGhMVxxh+ED4MNBx+NleCcz7p3zyfFHE72tFZR+PrCL8MlgGvPs0aBZY2LNe/jUUp1+Z
	eNooimgfqkuJ6yAZsh/ZjIrs4YVoUe9Ac6WQBfSqYW2hV+845LBfCtwrSMfUJCHMscvu/G7bH/r
	1AUVKLvKUW0llsN5lJhYWdXnHebPdn2cMljgda+rIRsk40eOswhhPzNhaLzFwtTLGgLpbBzJjM7
	WobO5Y6g9AycEVOa4hMWuQXlQ8oPstM0x/C8sF5bf/tsBKtKi0Tw/mhIkPAkbeUEBxcZT8wbIRj
	TdiCf1Wwx7dUAWtPgURyhlslKwLIkIlChZG2Kaq1dvoQCZzE=
X-Google-Smtp-Source: AGHT+IFfpnQgKBgzIoesLSMa4iwugYZPf09Jey5rOcTdqytakJ5xS15YC8xF1favhNHGM7U+MpddNA==
X-Received: by 2002:a05:6000:18ac:b0:3a4:ec32:e4f3 with SMTP id ffacd0b85a97d-3a6ed5fac72mr6102493f8f.17.1750950425919;
        Thu, 26 Jun 2025 08:07:05 -0700 (PDT)
Message-ID: <51f1103a-0efc-4dfb-8ea8-9bf8ebe9f6a9@suse.com>
Date: Thu, 26 Jun 2025 17:06:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH] xen: fix unspecified behavior in tr invocation
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 ,
 Anthony PERARD , Julien Grall ,
 =?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 26.06.2025 16:59, Nicola Vetrini wrote:
> The result of the command is undefined according to the specification if
> the "string2" argument in tr is shorter than "string1". GNU tr behaves
> correctly by extending "string2" to repeat the last character.
> 
> Fixes: eb61a4fb14d2 ("xen: fix header guard generation for asm-generic headers")
> Reported-by: Jan Beulich 
> Signed-off-by: Nicola Vetrini 

Reviewed-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Thu Jun 26 15:14:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 15:14:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026650.1401832 (Exim 4.92)
	(envelope-from )
	id 1uUoIV-0003sp-88; Thu, 26 Jun 2025 15:13:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026650.1401832; Thu, 26 Jun 2025 15: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 1uUoIV-0003si-5Q; Thu, 26 Jun 2025 15:13:55 +0000
Received: by outflank-mailman (input) for mailman id 1026650;
 Thu, 26 Jun 2025 15:13: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 1uUoIT-0003sc-3D
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 15:13:53 +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 2899ae2f-52a0-11f0-b894-0df219b8e170;
 Thu, 26 Jun 2025 17:13:47 +0200 (CEST)
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 3FCFB2117A;
 Thu, 26 Jun 2025 15:13: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 D8DB813188;
 Thu, 26 Jun 2025 15:13: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 d7Y5M6pjXWjnOgAAD6G6ig
 (envelope-from ); Thu, 26 Jun 2025 15:13: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: 2899ae2f-52a0-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750950827; 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=BUHGghIHe7WPy3rBL11hpqHMD1d3lwvA0GNEh4izy4c=;
	b=LKTRNdSir2I8WBpDDXchIB8olZ8882JMTyTK2aLSSNe6k+Rqx7ZU+LFk724glmHIEs72Pz
	RuImcUYcruQLVxzt2KWnZfxBVUMrCjqY1IOcjvZ9ViFC05vQ4+DhOhqYP5dHoLr3+Aq+kT
	0fg+Jwfn3opi4kdCG7YlpGaM27kI1cM=
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=LKTRNdSi
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750950827; 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=BUHGghIHe7WPy3rBL11hpqHMD1d3lwvA0GNEh4izy4c=;
	b=LKTRNdSir2I8WBpDDXchIB8olZ8882JMTyTK2aLSSNe6k+Rqx7ZU+LFk724glmHIEs72Pz
	RuImcUYcruQLVxzt2KWnZfxBVUMrCjqY1IOcjvZ9ViFC05vQ4+DhOhqYP5dHoLr3+Aq+kT
	0fg+Jwfn3opi4kdCG7YlpGaM27kI1cM=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Samuel Thibault ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v2 0/3] stubdom/grub: avoid relying on start_info definition
Date: Thu, 26 Jun 2025 17:13:41 +0200
Message-ID: <20250626151344.6971-1-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
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)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	ARC_NA(0.00)[];
	TO_DN_SOME(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[10];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[suse.com:+];
	SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	RCVD_TLS_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:dkim,suse.com:mid,imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns]
X-Spam-Level: 
X-Spam-Flag: NO
X-Rspamd-Queue-Id: 3FCFB2117A
X-Rspamd-Action: no action
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Score: -3.01

With the related change having been added to Mini-OS, the single V1
patch can now be expanded to a 3 patch series, especially meant to
untangle the close dependencies between grub-pv and Mini-OS internals.

Changes in V2:
- add comment to patch 1
- added patches 2+3

Juergen Gross (3):
  stubdom/grub: avoid relying on start_info definition
  Config: update Mini-OS commit id
  stubdom/grub: swap start_info usage with start_info_ptr

 Config.mk            |  2 +-
 stubdom/grub/kexec.c | 26 +++++++++++++-------------
 2 files changed, 14 insertions(+), 14 deletions(-)

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 26 15:14:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 15:14:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026652.1401841 (Exim 4.92)
	(envelope-from )
	id 1uUoIX-00046w-HB; Thu, 26 Jun 2025 15:13:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026652.1401841; Thu, 26 Jun 2025 15: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 1uUoIX-00046p-Ed; Thu, 26 Jun 2025 15:13:57 +0000
Received: by outflank-mailman (input) for mailman id 1026652;
 Thu, 26 Jun 2025 15:13: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 1uUoIW-00046W-JX
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 15:13:56 +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 2d007de0-52a0-11f0-a30f-13f23c93f187;
 Thu, 26 Jun 2025 17:13:55 +0200 (CEST)
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 DAEF421168;
 Thu, 26 Jun 2025 15:13: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 AC8EF13188;
 Thu, 26 Jun 2025 15:13: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 OZaZKLBjXWjuOgAAD6G6ig
 (envelope-from ); Thu, 26 Jun 2025 15:13: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: 2d007de0-52a0-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750950833; 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=AhGYBQwHApEqN1+5+tUHs1qBVwnk8aDK8vn7IKkZCtY=;
	b=GY15QzAa6URhOhe3Z3MZYdNM9+tp/jpv+lcT7sAgNinru9ScYhVxWUf9n8szNPzPLzrZK5
	hTzlDAsdh1+994zZLXj6+1tpbxh9vs8EXITx0/rKm6Bhf3cpVO+gdEbRcp71HLthuxhxrb
	TYa6MqsPcR1FLf55trk5AJtW5PU5wVU=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750950832; 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=AhGYBQwHApEqN1+5+tUHs1qBVwnk8aDK8vn7IKkZCtY=;
	b=LSZ7UzjvXwUVDrUsyrzSGwkqxgS6G2SBUi2yw8zrbNZyprOH8uPwHdt8bN2CyxFa8zniFg
	DAZCcmV9+LXtb1iykQ/AtAfdP9bafl/XFSbDdfpTVnxjU4Z2VpO6Q0mx4SEna1Q6t4W+pH
	SP1J1znXcuxjhzj7v+cYqaDhSnL7GFA=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Samuel Thibault ,
	Jason Andryuk 
Subject: [PATCH v2 1/3] stubdom/grub: avoid relying on start_info definition
Date: Thu, 26 Jun 2025 17:13:42 +0200
Message-ID: <20250626151344.6971-2-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250626151344.6971-1-jgross@suse.com>
References: <20250626151344.6971-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Flag: NO
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];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	MIME_TRACE(0.00)[0:+];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	ARC_NA(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	RCVD_TLS_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	DBL_BLOCKED_OPENRESOLVER(0.00)[amd.com:email,imap1.dmz-prg2.suse.org:helo,suse.com:mid,suse.com:email]
X-Spam-Level: 

The kexec() function of grub-pv is relying on the exact definition of
start_info from Mini-OS by having an "#undef start_info" and a few
lines later a copy of the Mini-OS definition again.

This is bad practice by making all attempts of Mini-OS to change that
definition impossible.

Avoid that dependency by moving the code fragment in question to the
very end of the source file, allowing to drop the copy of the
definition.

Signed-off-by: Juergen Gross 
Reviewed-by: Jason Andryuk 
---
V2:
- add comment (Jan Beulich)
---
 stubdom/grub/kexec.c | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/stubdom/grub/kexec.c b/stubdom/grub/kexec.c
index 3da80b5b4a..b423e856a4 100644
--- a/stubdom/grub/kexec.c
+++ b/stubdom/grub/kexec.c
@@ -209,6 +209,8 @@ static void tpm_hash2pcr(struct xc_dom_image *dom, char *cmdline)
 	shutdown_tpmfront(tpm);
 }
 
+static void call_start_info_hook(struct xc_dom_image *dom);
+
 void kexec(void *kernel, long kernel_size, void *module, long module_size, char *cmdline, unsigned long flags)
 {
     struct xc_dom_image *dom;
@@ -330,10 +332,7 @@ void kexec(void *kernel, long kernel_size, void *module, long module_size, char
         }
 
     /* start info page */
-#undef start_info
-    if ( dom->arch_hooks->start_info )
-        dom->arch_hooks->start_info(dom);
-#define start_info (start_info_union.start_info)
+    call_start_info_hook(dom);
 
     xc_dom_log_memory_footprint(dom);
 
@@ -432,3 +431,11 @@ out:
     allocated = 0;
     xc_interface_close(xc_handle );
 }
+
+/* No references to start_info of Mini-OS after this function. */
+static void call_start_info_hook(struct xc_dom_image *dom)
+{
+#undef start_info
+    if ( dom->arch_hooks->start_info )
+        dom->arch_hooks->start_info(dom);
+}
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 26 15:14:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 15:14:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026653.1401852 (Exim 4.92)
	(envelope-from )
	id 1uUoIa-0004Me-Pe; Thu, 26 Jun 2025 15:14:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026653.1401852; Thu, 26 Jun 2025 15:14: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 1uUoIa-0004MU-M9; Thu, 26 Jun 2025 15:14:00 +0000
Received: by outflank-mailman (input) for mailman id 1026653;
 Thu, 26 Jun 2025 15:13: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 1uUoIZ-00046W-KG
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 15:13:59 +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 2f48dc7d-52a0-11f0-a30f-13f23c93f187;
 Thu, 26 Jun 2025 17:13:59 +0200 (CEST)
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 B1F7C21160;
 Thu, 26 Jun 2025 15:13: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 5045C13188;
 Thu, 26 Jun 2025 15:13: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 4PTTEbZjXWj1OgAAD6G6ig
 (envelope-from ); Thu, 26 Jun 2025 15:13: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: 2f48dc7d-52a0-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750950838; 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=MsNYyEfvb5jYbzHJ2E51/v1/xsNYdiKTSuL/Sh/LsmA=;
	b=a2qkNvNUCc1rfEIgIGag4Fb7dMwh44gx1IcCc2s7uvXIqToLirV3Oo8TAfuLcXOVV7whg/
	GQbzV0Cwc/sfcBXan3FVq/ywlfN5lR8QHpRIv/KA/ziN+iyGjKskg40qn/EB3JHQ0Lg22x
	aPFluaB3it/q37XoQbYPTAPRFaDCW7o=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750950838; 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=MsNYyEfvb5jYbzHJ2E51/v1/xsNYdiKTSuL/Sh/LsmA=;
	b=a2qkNvNUCc1rfEIgIGag4Fb7dMwh44gx1IcCc2s7uvXIqToLirV3Oo8TAfuLcXOVV7whg/
	GQbzV0Cwc/sfcBXan3FVq/ywlfN5lR8QHpRIv/KA/ziN+iyGjKskg40qn/EB3JHQ0Lg22x
	aPFluaB3it/q37XoQbYPTAPRFaDCW7o=
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 v2 2/3] Config: update Mini-OS commit id
Date: Thu, 26 Jun 2025 17:13:43 +0200
Message-ID: <20250626151344.6971-3-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250626151344.6971-1-jgross@suse.com>
References: <20250626151344.6971-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Flag: NO
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)[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:mid,suse.com:email,imap1.dmz-prg2.suse.org:helo];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Level: 

Use the newest Mini-OS.

Signed-off-by: Juergen Gross 
---
V2:
- new patch
---
 Config.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Config.mk b/Config.mk
index 3ebc9ac125..55b1b83d49 100644
--- a/Config.mk
+++ b/Config.mk
@@ -208,7 +208,7 @@ QEMU_UPSTREAM_URL ?= https://xenbits.xen.org/git-http/qemu-xen.git
 QEMU_UPSTREAM_REVISION ?= master
 
 MINIOS_UPSTREAM_URL ?= https://xenbits.xen.org/git-http/mini-os.git
-MINIOS_UPSTREAM_REVISION ?= d273a44cec90dad5d3f0bc361a6fea41e0288a56
+MINIOS_UPSTREAM_REVISION ?= 2d3b22f842a969574cf967925b435c5913e8a6e0
 
 SEABIOS_UPSTREAM_URL ?= https://xenbits.xen.org/git-http/seabios.git
 SEABIOS_UPSTREAM_REVISION ?= rel-1.16.3
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 26 15:14:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 15:14:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026655.1401862 (Exim 4.92)
	(envelope-from )
	id 1uUoIh-0004hd-2e; Thu, 26 Jun 2025 15:14:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026655.1401862; Thu, 26 Jun 2025 15:14:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUoIg-0004hT-V6; Thu, 26 Jun 2025 15:14:06 +0000
Received: by outflank-mailman (input) for mailman id 1026655;
 Thu, 26 Jun 2025 15:14: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 1uUoIf-00046W-GI
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 15:14:05 +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 328ed4bb-52a0-11f0-a30f-13f23c93f187;
 Thu, 26 Jun 2025 17:14:04 +0200 (CEST)
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 4B1B721160;
 Thu, 26 Jun 2025 15:14: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 2092C13188;
 Thu, 26 Jun 2025 15:14: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 YfNXBrxjXWgAOwAAD6G6ig
 (envelope-from ); Thu, 26 Jun 2025 15: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: 328ed4bb-52a0-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750950844; 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=5aD+bS4T0OmGOE8GUbzM6J/43FA2KaMdcwiETXcLbNs=;
	b=Gh60U7kudqIgV5k0t2pBSXmrOQTQhVd0Nyfa78osydhR2c9FGpfyZImZAvxheY4jXNK3UW
	hUsDVZ01RSkJetiY+ABDjGAdAB9k1Z0pZ8TXC9qYDAv4ztl/lJ7AWX7MVShbWGXrpAabHb
	6ClmhVS+oJBFJavLn8Mg9cNpO2Qf0O8=
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=Gh60U7ku
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1750950844; 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=5aD+bS4T0OmGOE8GUbzM6J/43FA2KaMdcwiETXcLbNs=;
	b=Gh60U7kudqIgV5k0t2pBSXmrOQTQhVd0Nyfa78osydhR2c9FGpfyZImZAvxheY4jXNK3UW
	hUsDVZ01RSkJetiY+ABDjGAdAB9k1Z0pZ8TXC9qYDAv4ztl/lJ7AWX7MVShbWGXrpAabHb
	6ClmhVS+oJBFJavLn8Mg9cNpO2Qf0O8=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Samuel Thibault 
Subject: [PATCH v2 3/3] stubdom/grub: swap start_info usage with start_info_ptr
Date: Thu, 26 Jun 2025 17:13:44 +0200
Message-ID: <20250626151344.6971-4-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250626151344.6971-1-jgross@suse.com>
References: <20250626151344.6971-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Queue-Id: 4B1B721160
X-Rspamd-Action: no action
X-Spam-Flag: NO
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)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,suse.com:dkim,suse.com:email,imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MIME_TRACE(0.00)[0:+];
	SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	TO_DN_SOME(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_TLS_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DKIM_TRACE(0.00)[suse.com:+]
X-Spam-Score: -3.01
X-Spam-Level: 

Now that Mini-OS is exporting start_info_ptr, use that instead of the
tedious start_info macro.

Note that the Mini-OS macro still needs to be undefined, but now it can
be done right at the top of kexec.c.

Undo the previous move of the "other" start_info into a dedicated
function.

Signed-off-by: Juergen Gross 
---
V2:
- new patch
---
 stubdom/grub/kexec.c | 37 +++++++++++++++----------------------
 1 file changed, 15 insertions(+), 22 deletions(-)

diff --git a/stubdom/grub/kexec.c b/stubdom/grub/kexec.c
index b423e856a4..92646ad8cd 100644
--- a/stubdom/grub/kexec.c
+++ b/stubdom/grub/kexec.c
@@ -34,6 +34,8 @@
 
 #include "mini-os.h"
 
+#undef start_info
+
 #if 0
 #define DEBUG(fmt, ...) printk(fmt, ## __VA_ARGS__)
 #else
@@ -86,10 +88,10 @@ static void do_exchange(struct xc_dom_image *dom, xen_pfn_t target_pfn, xen_pfn_
     xen_pfn_t source_pfn;
     xen_pfn_t target_mfn;
 
-    for (source_pfn = 0; source_pfn < start_info.nr_pages; source_pfn++)
+    for (source_pfn = 0; source_pfn < start_info_ptr->nr_pages; source_pfn++)
         if (dom->pv_p2m[source_pfn] == source_mfn)
             break;
-    ASSERT(source_pfn < start_info.nr_pages);
+    ASSERT(source_pfn < start_info_ptr->nr_pages);
 
     target_mfn = dom->pv_p2m[target_pfn];
 
@@ -209,8 +211,6 @@ static void tpm_hash2pcr(struct xc_dom_image *dom, char *cmdline)
 	shutdown_tpmfront(tpm);
 }
 
-static void call_start_info_hook(struct xc_dom_image *dom);
-
 void kexec(void *kernel, long kernel_size, void *module, long module_size, char *cmdline, unsigned long flags)
 {
     struct xc_dom_image *dom;
@@ -242,8 +242,8 @@ void kexec(void *kernel, long kernel_size, void *module, long module_size, char
     xc_dom_module_mem(dom, module, module_size, NULL);
 
     dom->flags = flags;
-    dom->console_evtchn = start_info.console.domU.evtchn;
-    dom->xenstore_evtchn = start_info.store_evtchn;
+    dom->console_evtchn = start_info_ptr->console.domU.evtchn;
+    dom->xenstore_evtchn = start_info_ptr->store_evtchn;
 
     tpm_hash2pcr(dom, cmdline);
 
@@ -279,7 +279,7 @@ void kexec(void *kernel, long kernel_size, void *module, long module_size, char
         errnum = ERR_EXEC_FORMAT;
         goto out;
     }
-    dom->total_pages = start_info.nr_pages;
+    dom->total_pages = start_info_ptr->nr_pages;
 
     /* equivalent of arch_setup_meminit */
     dom->p2m_size = dom->total_pages;
@@ -306,7 +306,7 @@ void kexec(void *kernel, long kernel_size, void *module, long module_size, char
     }
 
     /* Equivalent of xc_dom_boot_image */
-    dom->shared_info_mfn = PHYS_PFN(start_info.shared_info);
+    dom->shared_info_mfn = PHYS_PFN(start_info_ptr->shared_info);
 
     if (!xc_dom_compat_check(dom)) {
         printk("xc_dom_compat_check failed\n");
@@ -315,8 +315,8 @@ void kexec(void *kernel, long kernel_size, void *module, long module_size, char
     }
 
     /* Move current console, xenstore and boot MFNs to the allocated place */
-    do_exchange(dom, dom->console_pfn, start_info.console.domU.mfn);
-    do_exchange(dom, dom->xenstore_pfn, start_info.store_mfn);
+    do_exchange(dom, dom->console_pfn, start_info_ptr->console.domU.mfn);
+    do_exchange(dom, dom->xenstore_pfn, start_info_ptr->store_mfn);
     DEBUG("virt base at %llx\n", virt_base);
     DEBUG("bootstack_pfn %lx\n", dom->bootstack_pfn);
     _boot_target = virt_base + PFN_PHYS(dom->bootstack_pfn);
@@ -332,7 +332,8 @@ void kexec(void *kernel, long kernel_size, void *module, long module_size, char
         }
 
     /* start info page */
-    call_start_info_hook(dom);
+    if ( dom->arch_hooks->start_info )
+        dom->arch_hooks->start_info(dom);
 
     xc_dom_log_memory_footprint(dom);
 
@@ -371,7 +372,7 @@ void kexec(void *kernel, long kernel_size, void *module, long module_size, char
     DEBUG("boot page mfn %lx\n", boot_page_mfn);
     _boot_page_entry = PFN_PHYS(boot_page_mfn) | L1_PROT;
     DEBUG("boot page entry %llx\n", _boot_page_entry);
-    _boot_oldpdmfn = virt_to_mfn(start_info.pt_base);
+    _boot_oldpdmfn = virt_to_mfn(start_info_ptr->pt_base);
     DEBUG("boot old pd mfn %lx\n", _boot_oldpdmfn);
     DEBUG("boot pd virt %lx\n", dom->pgtables_seg.vstart);
     _boot_pdmfn = dom->pv_p2m[PHYS_PFN(dom->pgtables_seg.vstart - virt_base)];
@@ -384,12 +385,12 @@ void kexec(void *kernel, long kernel_size, void *module, long module_size, char
     DEBUG("boot start %lx\n", _boot_start);
 
     /* Keep only useful entries */
-    for (nr_m2p_updates = pfn = 0; pfn < start_info.nr_pages; pfn++)
+    for (nr_m2p_updates = pfn = 0; pfn < start_info_ptr->nr_pages; pfn++)
         if (dom->pv_p2m[pfn] != pfn_to_mfn(pfn))
             nr_m2p_updates++;
 
     m2p_updates = malloc(sizeof(*m2p_updates) * nr_m2p_updates);
-    for (i = pfn = 0; pfn < start_info.nr_pages; pfn++)
+    for (i = pfn = 0; pfn < start_info_ptr->nr_pages; pfn++)
         if (dom->pv_p2m[pfn] != pfn_to_mfn(pfn)) {
             m2p_updates[i].ptr = PFN_PHYS(dom->pv_p2m[pfn]) | MMU_MACHPHYS_UPDATE;
             m2p_updates[i].val = pfn;
@@ -431,11 +432,3 @@ out:
     allocated = 0;
     xc_interface_close(xc_handle );
 }
-
-/* No references to start_info of Mini-OS after this function. */
-static void call_start_info_hook(struct xc_dom_image *dom)
-{
-#undef start_info
-    if ( dom->arch_hooks->start_info )
-        dom->arch_hooks->start_info(dom);
-}
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Jun 26 15:25:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 15:25:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026683.1401872 (Exim 4.92)
	(envelope-from )
	id 1uUoTi-0007jJ-1i; Thu, 26 Jun 2025 15:25:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026683.1401872; Thu, 26 Jun 2025 15:25: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 1uUoTh-0007jC-V7; Thu, 26 Jun 2025 15:25:29 +0000
Received: by outflank-mailman (input) for mailman id 1026683;
 Thu, 26 Jun 2025 15: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 1uUoTg-0007j6-3y
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 15:25:28 +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 c8a7e827-52a1-11f0-b894-0df219b8e170;
 Thu, 26 Jun 2025 17:25:26 +0200 (CEST)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3a5123c1533so636857f8f.2
 for ; Thu, 26 Jun 2025 08:25:25 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23abe442a40sm589525ad.249.2025.06.26.08.25.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 26 Jun 2025 08:25:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c8a7e827-52a1-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750951525; x=1751556325; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=YKQ6Gh73dlwtNUwQq11DNaPFzHPmUBkXRAJ2x86egh8=;
        b=U4HvG/R+oe+WSEJTO6eSsTedOz6jTf4R0vvMkzz8hDrjhRPqQw0YC2NliAFfMmld1p
         ND7hMzC9LQ6CdYtqUOQlHy83JEs5cuEo/LkAt2jpGWzfjVgrznaXW+JT5qZ8/Y1BR1Mp
         0hHUHvpP5LupelMNK5VaLPF7eitlCI2RmlIJbq4d+YU/dbfYkLaVJMZfaUqp7HFr7MOK
         TLAK2/9n1gd9yONgE9i3FY40CWwBy+YcZKOtLXglpvqS3rXC5OPEP7hcqTpfbauGMw3Z
         ulnpYPO7+AIAf4eY0rZ4QXowFF7jbHNi9or/x/lu/JWCnzuvqcigbZ7m2ylGrcSCPiM2
         3Zwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750951525; x=1751556325;
        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=YKQ6Gh73dlwtNUwQq11DNaPFzHPmUBkXRAJ2x86egh8=;
        b=MAfsOcZFyCFJoIP/tKj6urAVXol+BZ87hD9/3GXYxCWv9NZLXp/+Wg4fWcLhFzMjMw
         137JYUj14xXapeO3yGEE1bk3JB5BJpJ+H6TTo9MfyYG3m1LvQ6xFDxudzu6s4StfSx21
         aEniIr5ml3f+ZNRLcwdUlzz7YaQeOOKZLcxo8ub4lDqC2jicQL2ofnEP9G6/8i/bd+pg
         J9wUpXcqwnks3P5Q9aJ4lxJC6Sn+pMiIDQWqW1bez6vJ2x+hHQXIb93wNv5pTuYz4UZI
         45cxer+HD5hJ5jUFJjyrAiAOHmHKtQp0qVEi1lYiu/zaU5VjWBQ94b/heV5/bjQpdpSZ
         u8Zw==
X-Forwarded-Encrypted: i=1; AJvYcCVNkHW5fak3Ok1HobqDLStMd1ZKsm4vDEpvw7GP6IbLN1H0Gr8x213om/keXxw8QPMgkGw0GhKC3Pk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzF5kSzrIGF5TvX02KRVA9zuGv7EgjuPfosfcDuTlJzbUDlSvbN
	LzlWAwHsVXK5j4tCZmdkYygODB42lHXa4uEYvMcMWldOVBxju8Z+QJzjCKzrPr3wGQ==
X-Gm-Gg: ASbGncsJQJWO0KW2V3t4BHdJx7f2mL/bVHy7NqApq2ligqv313v+YoEHgNrQ5NXDV0a
	ry/wdoTViqTogCWaNw3dZDJTcxpwU5WmrLy550saRIjd9x7c6/HeEegkEHTPeFjt8HHDLoihvKs
	rxopGHa3CXQePUqsUBckezr9VyoX/iJrFK3bw8sucbFNruff4GT/YnlFKkwJ2o+rPL7z9oF19nk
	YxyYFZdwWxcC9fECLtJJv/nI4SChjzkkii2ogpxg3x661lQYm0790mOYLkAj2PGtWI/AFKdG2rz
	T5kfgiPWEJIoJ4ZJ+q5JpWm0cF20fm1whtu7nbznQAxkcxhqL5MGnXDPGLsiDeRnmxpiTIkQQRU
	JYtZ9JFp66h6qxUr5KqxC5Fp3KKZ96rq8MSOdJj8XnQKCEhc=
X-Google-Smtp-Source: AGHT+IE4ND3cyfwCJChr6Hn/EHoH7uuBTyxSHJur+XkAcZrgadTv3YoZ0NbX/1Rpqdow7+QL5py0Vg==
X-Received: by 2002:a5d:5f55:0:b0:3a4:fbaf:749e with SMTP id ffacd0b85a97d-3a6ed65ce01mr5745113f8f.49.1750951525285;
        Thu, 26 Jun 2025 08:25:25 -0700 (PDT)
Message-ID: <99ccbf92-2673-4b09-a6fe-4cf5d2f7cbda@suse.com>
Date: Thu, 26 Jun 2025 17:25:15 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/3] Config: update Mini-OS commit id
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: <20250626151344.6971-1-jgross@suse.com>
 <20250626151344.6971-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: <20250626151344.6971-3-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 26.06.2025 17:13, Juergen Gross wrote:
> Use the newest Mini-OS.
> 
> Signed-off-by: Juergen Gross 

Acked-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Thu Jun 26 15:28:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 15:28:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026689.1401883 (Exim 4.92)
	(envelope-from )
	id 1uUoW9-0008FE-Fs; Thu, 26 Jun 2025 15:28:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026689.1401883; Thu, 26 Jun 2025 15: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 1uUoW9-0008F7-BH; Thu, 26 Jun 2025 15:28:01 +0000
Received: by outflank-mailman (input) for mailman id 1026689;
 Thu, 26 Jun 2025 15:27: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 1uUoW7-0008F1-FV
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 15:27:59 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on2062b.outbound.protection.outlook.com
 [2a01:111:f403:2416::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 22cf04d2-52a2-11f0-a30f-13f23c93f187;
 Thu, 26 Jun 2025 17:27:57 +0200 (CEST)
Received: from CH0PR03CA0360.namprd03.prod.outlook.com (2603:10b6:610:11a::11)
 by CY8PR12MB7097.namprd12.prod.outlook.com (2603:10b6:930:51::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.28; Thu, 26 Jun
 2025 15:27:52 +0000
Received: from DS3PEPF000099DE.namprd04.prod.outlook.com
 (2603:10b6:610:11a:cafe::ab) by CH0PR03CA0360.outlook.office365.com
 (2603:10b6:610:11a::11) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8880.21 via Frontend Transport; Thu,
 26 Jun 2025 15:27:52 +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.8880.14 via Frontend Transport; Thu, 26 Jun 2025 15:27:52 +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, 26 Jun
 2025 10:27:51 -0500
Received: from [172.28.201.131] (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, 26 Jun 2025 10:27:51 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 22cf04d2-52a2-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=yXDJr8Gs6A8ezy2jfq7gt9t1X4lgbCiTOLRl9vFK96EHvRNeb5Gd08Oq2Gtm+e0rCtke7Moj31dWoH7nd5A5mWazEIL9xZ3zz83UzIdekgNaqEYRKYpKI5mRPWAxAZymEHusgoJShQeYI0Qm4jSfa0LfZm+SXGHj5ajSTpwZg3gf0KIR/ySGR9/2T00d8WTpCavWKWQIJmwCzAgAFCKh2apygVK/3sOR4SPBNFIG2Hiynwn1QRia2mqOD+8pY+Oo+bXCCbNAej8hoWxcaz9+2zC0HJRBVvNoX7TlH7H0cXzgfT7w/CPW333ouU02fft/YIbFYWk9ahnVNXp5Y84r4g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=VoImiqSU2A79r1jD4fd6kFDddsDiHIsNUisqkPxo6Hg=;
 b=lvs0vyl4QoTf4O1v/KJzOpAWMI9SShVdC1MRnS4IrJBJajFEnsWe9t1CFTtUP3sIALoM35umJdHdpgLs74VZkk0F7sZQ8ig+jHOi4gRQb9NQP+85UElnaTWru96ZdBwCaAadI46minvUCPJnHd587j3VXhCJNp3yZhUPl8ben+QW2/oFUo96jiepZSUI/aXzxvkcQR+5vU4MjFApeo8wuG+75wyyMiEa6bPPjZf+0J/85TF60O3QDibr7HUKVKHaV7IYgRddUZRLDREkPKk2VsHmj0iFF2YHD5UksklcU5OipIXaG9UFO1/hPear5veb7AqZ0GDI6XQmpErdWYmaWg==
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=VoImiqSU2A79r1jD4fd6kFDddsDiHIsNUisqkPxo6Hg=;
 b=woditHVkjBpvbS53TXivJ1f2U9PbdVCHziFlU/uIWzVSpmL4uqdDNgVYgoTLtjNiqOh+ycMpY3YYZ+Jzsm3snTfqJGhuzcfzpPiu8EanmXDeoHh6WLlmzOjWLCYRM7EpRjC3r+6QxgUlMfrSLhvSSruoQd7UQE3h9r2c6pGV2P4=
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: <421c4e26-f09c-4e7a-9329-9c1666d09232@amd.com>
Date: Thu, 26 Jun 2025 11:27:51 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/3] stubdom/grub: swap start_info usage with
 start_info_ptr
To: Juergen Gross , 
CC: Samuel Thibault 
References: <20250626151344.6971-1-jgross@suse.com>
 <20250626151344.6971-4-jgross@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <20250626151344.6971-4-jgross@suse.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: DS3PEPF000099DE:EE_|CY8PR12MB7097:EE_
X-MS-Office365-Filtering-Correlation-Id: ada69fdc-7847-479c-b7e3-08ddb4c6043a
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|82310400026|36860700013|1800799024|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?ZW12U0xSdVZPM1NnWkc5RzhuZzdSemVYUElXSWlvSmV6UTFXMXBqT3N0N2Z3?=
 =?utf-8?B?ZW5pMzgrWkI4UWZaUWI1elRERmlvQ1FPdHZIV1hud0V1UWp1N3pmRTU2ZWQv?=
 =?utf-8?B?YUhuSisrWXVJOFUyK2NuQ0U4eGRVaFRHbXVRdFBMK1NZL0FoQ041NHdKNUxC?=
 =?utf-8?B?S1dldFphNXMyMDBUYjg2Y2w5a284N0Uwb1ZNdzFNTUtFVGhPVi80Y2VxK2Y1?=
 =?utf-8?B?YTBMQ001MU1jdlRxU0hSU2QrMkgwQmx4K2pQaWVzSHZ2TVRBYnZ5N3NlK0lx?=
 =?utf-8?B?V1dROUt5SzA5M01TOFkxM1p3TXFld2RMTk5uZnF6M2dTSGxpL3ZjL01oUll3?=
 =?utf-8?B?T2pJVDNCSHg2TkxDNzVxY2U3WExkQitvbmRNVUFIZFl2ZGM4bzVTQkdTaFpE?=
 =?utf-8?B?RGlxYm9tR3p6UXJQeGsrSW5TOHZhQTNHOXB1Zk1IOUZNdTEyWkNOMFZFRTZI?=
 =?utf-8?B?ZGl1SDdUZ0V3Y1VHcHF2RXBqcU1pZDVSdU51V3ZtdGNWMGxvb2tYdFlHY1Nx?=
 =?utf-8?B?bjI3bXc5aWJRMHRLTXdDc0xsaFNvRG9DL2lUbElLWThoY3F4ejFtZ3RScUZ4?=
 =?utf-8?B?NHlpL0VjYzNoNUkxcm15bzl5bGMxaG9YV1FMemJleTNyTS9ZTXMxc0xCVkp5?=
 =?utf-8?B?R0o5OFJPbUc5OXZKNlhhdHBXTFlkTjcydHNKVVBxNVh3eHhGRXVLQzk1Wjc3?=
 =?utf-8?B?STJMVXpaY0ZsRElJWFJRNSt6VTF6SkFIbTJSM01SeTFBb3hoL3BDSnZqdGVI?=
 =?utf-8?B?RTBCVTlQM1hIMEVBZHkvSlAvaUJXSnhUdUJhQXFuNFF0Q2o4VkwzdURiZ1pD?=
 =?utf-8?B?akszVTh1Tndnb0d5U1lZWG1HUXl0UExWWHZ0dEhja2YzaThmbTVHbnEwcmV6?=
 =?utf-8?B?WStJWllhenEyY1duY1pWdFptbGJHUUsyYW8xTFpFSkZuSFhzd3hIZHJFc3RW?=
 =?utf-8?B?NGc2aVVZN3dVOHlLWVdWdXB4ZWxRbjR2VkVLNFJxSEpaNVRpUElCcExlT0Jz?=
 =?utf-8?B?THA1dGt4T3JTcXFzSXlXNm1DVUtZUUxZVTRyMlZ3cmFZUjQxUlJaOG1lSDRt?=
 =?utf-8?B?bWFQRGs5cWU4ZTlvNlRVRlBxZmhJMGxOWjFreGs5VTN4dzc2WEZxS2ZYdEUv?=
 =?utf-8?B?enFLMnJnT0t3ZXduekV5VnN2WFlNS1B4ZVBUY3pWTStvTWVlTldkemJTQlg1?=
 =?utf-8?B?QVY1bEtYaGplTjRhYW1VdUJqcGxmWWhCMGJ3bGUrcnF3YU91ZlFNdnMvRkJS?=
 =?utf-8?B?RzlKdUo4cGRranVjVHhvWXpJcUdGNlpmY2liTVhZWmFyd0htZUc2dXJzUWhI?=
 =?utf-8?B?ZnUwTjVwL05POFVTOWY1RnQyUHNlT0kwbVVxR1J1ZG5QOXJOdzZDdmVlaThL?=
 =?utf-8?B?dUhoVTRaY2JDeEZTZlZNSUwzdlRCYVh2VFk0VHc5NlRTOTdZUjc1cTJKbnhp?=
 =?utf-8?B?MjdQQU9OUzI5cEJVZnMyeExldml4bWwxbnlNQUppMXRlU1BBNnRjaW9tRG1B?=
 =?utf-8?B?S2pweVNlNWU0dy9qTUQwSjFCMW5iYnhUOE56UUxaYzE4Y0VwVmhNalFBU2pp?=
 =?utf-8?B?YTVjSVd2VXZ4d3lxci9OZTE4ZDVUM2ZLOC9TU2ZMdkJ3aTluamxIVlpBYS9u?=
 =?utf-8?B?ZTYwaGRDOUI2MU41TzRxSlhrc3VIbHo2Y2ZlRm13dDhQdXNQcHVrbjRjdFpz?=
 =?utf-8?B?N1dmNzNBUFJ1bGlBdkdXbm0yMWdsODl4NlZHSnRVb0pIOTdwZkV2c1ExK1c4?=
 =?utf-8?B?cmxlOVN4WmhUNDRxL1lUMWJ4blE4T0J0UTJvNW1tcUdleWozeHZPakJHR0Qr?=
 =?utf-8?B?RkdEYXloNHlWR0JsMjRoUmVMVnVScXZJVEwrNEZKT2JJVFdGVytBN0I3T1M4?=
 =?utf-8?B?VkxpaVhwcnM3NFA1bmFPUnFWajM2cEprenVNckFYd0ZHUjB0SnlCUisxci95?=
 =?utf-8?B?OUI1VlJTeEFVeG5FV042SGFmcmE2bGRpUDZwaWwxVU5MNEtpdTN0SENReU1N?=
 =?utf-8?B?RUxXeXdTeDNVZnZDVXI3ZDFaRkxmcDFkZVFteEI0T0pXM2pZTlZHQ3NNK1cw?=
 =?utf-8?Q?qheP3q?=
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)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jun 2025 15:27:52.3160
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ada69fdc-7847-479c-b7e3-08ddb4c6043a
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: CY8PR12MB7097

On 2025-06-26 11:13, Juergen Gross wrote:
> Now that Mini-OS is exporting start_info_ptr, use that instead of the
> tedious start_info macro.
> 
> Note that the Mini-OS macro still needs to be undefined, but now it can
> be done right at the top of kexec.c.
> 
> Undo the previous move of the "other" start_info into a dedicated
> function.
> 
> Signed-off-by: Juergen Gross 

Reviewed-by: Jason Andryuk 


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 15:28:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 15:28:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026699.1401891 (Exim 4.92)
	(envelope-from )
	id 1uUoWj-0000LP-Pc; Thu, 26 Jun 2025 15:28:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026699.1401891; Thu, 26 Jun 2025 15:28: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 1uUoWj-0000LI-N1; Thu, 26 Jun 2025 15:28:37 +0000
Received: by outflank-mailman (input) for mailman id 1026699;
 Thu, 26 Jun 2025 15:28:36 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uUoWi-0000LC-Me
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 15:28:36 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uUoWh-003gRL-2R;
 Thu, 26 Jun 2025 15:28:35 +0000
Received: from [15.248.2.232] (helo=[10.24.67.104])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uUoWh-00712Y-1i;
 Thu, 26 Jun 2025 15:28: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" 
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=PeCm88sX+Bt3VwHD1/H6v9mTFtlIeva0wm74H3Qc7QE=; b=sVqEg/0RXo5zr/b9yYFHZLDF7I
	esE8WpO9Ozdu0/yspg5+VtMvGf/G4kym1G6W7Goay9WIhdgEfpKTBaJbId/cBXmUqfvHIwiq+IVKU
	KuXiBWrcdGR7hFjv5yYyw4nmrs54JuhyCvOxLxDLK/UzqWfmB0+r9FpOz8rLnTXYq0ZM=;
Message-ID: 
Date: Thu, 26 Jun 2025 16:28:33 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1] xen: move __ro_after_init section symbols to
 xen/sections.h
Content-Language: en-GB
To: Oleksii Kurochko ,
 xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <1254ad9fd9f9fefc71ff8a5f5d23f5037d854943.1750237599.git.oleksii.kurochko@gmail.com>
From: Julien Grall 
In-Reply-To: <1254ad9fd9f9fefc71ff8a5f5d23f5037d854943.1750237599.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Oleksii,

On 18/06/2025 10:13, Oleksii Kurochko wrote:
> Instead of declaring __ro_after_init_{start,end} in each architecture's
> asm/setup.h, move these declarations to the common header xen/sections.h.
> 
> This centralizes the declarations and reduces duplication across
> architectures.
> 
> No functional change intended.
> 
> Signed-off-by: Oleksii Kurochko 

Acked-by: Julien Grall 

I also don't have a strong opinion either way about Jan's comment about 
the placement.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Thu Jun 26 15:31:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 15:31:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026712.1401902 (Exim 4.92)
	(envelope-from )
	id 1uUoZb-0001yE-51; Thu, 26 Jun 2025 15:31:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026712.1401902; Thu, 26 Jun 2025 15: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 1uUoZb-0001y7-1P; Thu, 26 Jun 2025 15:31:35 +0000
Received: by outflank-mailman (input) for mailman id 1026712;
 Thu, 26 Jun 2025 15:31: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 1uUoZa-0001wg-9W
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 15:31:34 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a3d422b7-52a2-11f0-a30f-13f23c93f187;
 Thu, 26 Jun 2025 17:31:33 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-4530921461aso8342125e9.0
 for ; Thu, 26 Jun 2025 08:31:33 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4538a390d11sm23539015e9.7.2025.06.26.08.31.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 26 Jun 2025 08:31:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a3d422b7-52a2-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1750951893; x=1751556693; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ii0s8oFrsFKQMxXFB8UV/79cvMtrCFlANuWblYnEDag=;
        b=iJWiqWAPNCE2ZB56npLUYIOl4x4UmW5b2ktSUhhJC7yt6yV/bvJFlEsjj2K3hNnpCl
         /2Nh2+TZhBq56GrqLmhVQskOAziuwtF9WVMcz03fB5FOMY0qUSywrJt9VMWslamqRM+g
         57KsMNHw9wLyTE+ITQuJh3q7lIN0MG2cPJnic=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750951893; x=1751556693;
        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=ii0s8oFrsFKQMxXFB8UV/79cvMtrCFlANuWblYnEDag=;
        b=DGzcYhDnO+MlYbMhJz6wWMHNhsmJkvY7tGaIYHed1I+ngpbEN1XbUPbnSUCuCFDgPU
         qOlFVrDKn222CURWKTFCMek1Sljrz9jyUonEFMF7neG99el9HBlN1A7Wqm8Y2lkCJeT1
         y5Y2WmORq58yGOZJQIFCvBdjkgmjXHSGfCbypIKGIcFCSqi05ot26f+kgPP/FfAnzcrp
         la0Lv4zBZoBfWQ6hS8gwl3fNmJW9uoPfE2uUjFcVZC9hBsAEmt4XTcDVZbRmNk6nYLK4
         U5ghrN3gkiHVcXzSgpgyhNWcQ/t3Yh8sx7OgIRPdT80yZc3hDRAs+vWSMubT2qrxG1EP
         GV4Q==
X-Forwarded-Encrypted: i=1; AJvYcCWoPhgWIMUVtzzeNPV6zRV/VVwtIlWvuTLCDuIytr9r0wfqFACD/ePSGbQnqJvlQchELRi1XfmKpzY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzWHKAI+6r0Y9DfXC94KzSkeaGl+8PKDYO6B+db+EOv90ox+Cdl
	JUTdMsU5FMkS3g2znpwT/n/a9902ju3RZDzX/NvwRDp1DTl4g+BbsD7rItg88KiPncI=
X-Gm-Gg: ASbGncvyzFi2WfJ10bGVMyoTNcHgIUsQvlvJHQ9aTecmdtiZspQ6JwrZruG2bc9eE+n
	Gp36HQdMEx1aYeEtXMSX7ZqPG2QBIBgaRxy7hi2neJZ0RdCQEW/r+7PuOJByivBEkKabEA4py83
	wopaCNlbZ1/rPAeCegTAj9xvcuOasU5z2hXcGWahBGVJ0t0MW11kyVOeNWP66E2SXm6AEj67029
	Z5m5Pf7AsN1hzBDHDqjVU+HshT6W18unSXpQkpsSadxbak//9nN8dYFeMUuHPHb30cWHFoQX1wR
	G3XEvRM8zWf2K3u0VEa/mVq/Ks2TSWK6rLzhxPMDR+Gf7j4dKLKUB64pkl6JXFW/bWXyAXMs0Qp
	spDizu5u83sxrZTSi1BzCtOsPUYk=
X-Google-Smtp-Source: AGHT+IHGvdhPTmft1rx6rUXbrDNTVj+SQ18m4p5TGMyswCm0DPPB7l8jXgSs0cVAUbZV4/FC5Ivjpg==
X-Received: by 2002:a05:600c:37c9:b0:453:7bd:2e30 with SMTP id 5b1f17b1804b1-4538dbd5effmr17066965e9.29.1750951892987;
        Thu, 26 Jun 2025 08:31:32 -0700 (PDT)
Message-ID: 
Date: Thu, 26 Jun 2025 16:31:31 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 1/7] x86: suppress ERMS for internal use when
 MISC_ENABLE.FAST_STRING is clear
To: Jan Beulich ,
 "xen-devel@lists.xenproject.org" 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
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 16/06/2025 1:59 pm, Jan Beulich wrote:
> --- a/xen/arch/x86/cpu-policy.c
> +++ b/xen/arch/x86/cpu-policy.c
> @@ -487,6 +487,12 @@ static void __init guest_common_max_feat
>       */
>      if ( test_bit(X86_FEATURE_RTM, fs) )
>          __set_bit(X86_FEATURE_RTM_ALWAYS_ABORT, fs);
> +
> +    /*
> +     * We expose MISC_ENABLE to guests, so our internal clearing of ERMS when
> +     * FAST_STRING is not set should not affect the view of migrating-in guests.
> +     */

The logic is ok, but the justification wants to be different.

"ERMS is a performance hint.  A VM which previously saw ERMS will
function correctly when migrated here, even if ERMS isn't available."

What Xen chooses to do with the bit isn't relevant to why we
unconditionally set it in the max featureset.

> +    __set_bit(X86_FEATURE_ERMS, fs);
>  }
>  
>  static void __init guest_common_default_feature_adjustments(uint32_t *fs)
> @@ -567,6 +573,16 @@ static void __init guest_common_default_
>          __clear_bit(X86_FEATURE_RTM, fs);
>          __set_bit(X86_FEATURE_RTM_ALWAYS_ABORT, fs);
>      }
> +
> +    /*
> +     * We expose MISC_ENABLE to guests, so our internal clearing of ERMS when
> +     * FAST_STRING is not set should not propagate to guest view.  Guests can
> +     * judge on their own whether to ignore the CPUID bit when the MSR bit is
> +     * clear.  The bit being uniformly set in the max policies, we only need
> +     * to clear it here (if hardware doesn't have it).
> +     */

"ERMS is a performance hint, so is set unconditionally in the max
policy.  However, the guest should default to the host setting."

> +    if ( !raw_cpu_policy.feat.erms )

This wants to be the host policy, not the raw policy.  That's why
`cpuid=no-erms` isn't working in the way you'd expect.

cpuid=no-$foo means "Xen should behave as if $foo wasn't reported by
hardware", and that includes not giving it to guests by default.

> +        __clear_bit(X86_FEATURE_ERMS, fs);
>  }
>  

It occurs to me that there are quite a few examples of clear/cond-set
which could be converted to cond-clear like this

I'll do a prep patch to make things consistent.  It shouldn't conflict
with this, but I'd prefer to keep the function logic consistent; it's
hard enough to follow already.

~Andrew

P.S. I don't have time right now, but this is yet another example that
could be eliminated with an annotation meaning "set in max, host in
default".  I'll try to find some time to make this happen, because
there's clearly a pattern now.


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 15:46:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 15:46:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026723.1401911 (Exim 4.92)
	(envelope-from )
	id 1uUonm-0004Wy-7n; Thu, 26 Jun 2025 15:46:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026723.1401911; Thu, 26 Jun 2025 15:46: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 1uUonm-0004Wr-4o; Thu, 26 Jun 2025 15:46:14 +0000
Received: by outflank-mailman (input) for mailman id 1026723;
 Thu, 26 Jun 2025 15:46: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 1uUonk-0004Wl-Ur
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 15:46:12 +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 aa264e72-52a4-11f0-a30f-13f23c93f187;
 Thu, 26 Jun 2025 17:46:03 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a582e09144so719533f8f.1
 for ; Thu, 26 Jun 2025 08:46:03 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23abe3f535esm985025ad.142.2025.06.26.08.45.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 26 Jun 2025 08:46:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: aa264e72-52a4-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750952763; x=1751557563; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=YsUWoyoctkemtOz6fwgwSl0pHJTLE5/67MsKJbMWSp4=;
        b=MzZ4bz1ltb/OtGBBWwYn/ttMYy9TjLh+c2PgCfIES7wnvsIXrmMerANDTq0vu9GsXo
         b7QCmItBRRn8xHJHkK6WzrSCTD2BN8gfeXmSUwPvKvYcpjrE+rdYmsid6cAYkLXRsyBq
         h0hFwx4QcuJkHA+RNYFo3mvmX8siTDwqKlaCwtHWuuFL+nEfZSKqclnNetduy50HBSYe
         Z29B0c3zIBM7h2NBZ3GgNWdjlAlepoghlb0X2PUk6jwSWgMr3yg9qlVdI+xyssTxv0uw
         DUVmIorSpRgqI9PCuYi103acEbIh1Q0DJxCBDedGd3QzxXrLuj3U5vKcmtNwRLLNt8Ki
         wR6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750952763; x=1751557563;
        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=YsUWoyoctkemtOz6fwgwSl0pHJTLE5/67MsKJbMWSp4=;
        b=ZSP43R8A3KIA35indn5/LIkFKqHpY6ftzaGGtn+K3l31E2tg49h7bA4E2iae2ZlVai
         wPAmXEtihNzCUR2bnQc96AXoSXtfHesALa6HTWWUyfIdbqvtOSAGd+4jU3PuknNJxIXs
         d/RkbTevb0gToWkhOtzxe3+j8wvhJkyO8WWWMdCa2NcjnJd39AG6yEtb3ZeXF1yg2SE6
         s4TwmHQ+rJWzsAIdZS38A2pSiXhdw1GC6IUDU/RA8lBDeCrQI6dh9ZaK8MnvJ61mc+2a
         ciFlSvgvBkKLXhfbqozMWWG9HWAZC8gIW2swGFmzUO6sboudbHXQ0a7qgyZMPE/Dqjpq
         i6GA==
X-Forwarded-Encrypted: i=1; AJvYcCXYzgJT8W/L1Dv/x2KnfidfpjSBnRz15V5yhW5q/qM1JkZBqQpKnqiFeXydo/4/gHogdEO6/BdpfNs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzQn72LK4pOCIi/IjMK4hjWZ8zdSkbOGy2b0BkcpYR/LnLzM1Zl
	kOUMqZhfmTDcX3X0B+WlLbbLoaUwbRVFRwMwbLMovg5XaoYccW2gAUADx+xWCXoCoQ==
X-Gm-Gg: ASbGncs0jVCUqnRjB2DoOIY2WSLzMr76W9UZD5aG1P0SNeKlhlInPZfhPyFrL993qWZ
	uvNaJcIVl/UqXHkKDGbQzUVguJGMMCoHShF8MlhjkV/ZSeG2i7ixYKraone8BnQWfKeOH0uaa4C
	unJeAFvRykswKKWWmb+7+D9L9fdZbyCyGxnBFfkH9b6bjoRYy06PVCX6H29HQ5zXjOSOtK9l9lt
	qfCRWBiM0RJG8mK+Lh4hewTKpkp8CiNh0WUWG3SgKQuLRjRgjn2bXrzFq32io9aKbPzQ48TI3Wx
	B5AV8Zx++cgN2qXgD3z7W0VY79NlIoCvAE5C1XkCK1b1ivjcBkOThh9+LMHU/BYIdYKCpEDBVEu
	yXFvQ2AdKRJUQZT9R5KJTWjpDiFCa7gbfmbDafaQrQUb905/t7O7Em2Q99g==
X-Google-Smtp-Source: AGHT+IEnL9s+illgmh4N43IAFMmYtwhbDT3XODUPLOB6JeVHsODKLzjrYpFD9sXBkLau5KRoCK9gHg==
X-Received: by 2002:a05:6000:23c3:b0:3a5:25e0:ab53 with SMTP id ffacd0b85a97d-3a6ed66a535mr4374560f8f.32.1750952762705;
        Thu, 26 Jun 2025 08:46:02 -0700 (PDT)
Message-ID: <634154c0-ecd7-4c24-bc52-91aeefe367f0@suse.com>
Date: Thu, 26 Jun 2025 17:45:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 1/7] x86: suppress ERMS for internal use when
 MISC_ENABLE.FAST_STRING is clear
To: Andrew Cooper 
Cc: =?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 26.06.2025 17:31, Andrew Cooper wrote:
> On 16/06/2025 1:59 pm, Jan Beulich wrote:
>> --- a/xen/arch/x86/cpu-policy.c
>> +++ b/xen/arch/x86/cpu-policy.c
>> @@ -487,6 +487,12 @@ static void __init guest_common_max_feat
>>       */
>>      if ( test_bit(X86_FEATURE_RTM, fs) )
>>          __set_bit(X86_FEATURE_RTM_ALWAYS_ABORT, fs);
>> +
>> +    /*
>> +     * We expose MISC_ENABLE to guests, so our internal clearing of ERMS when
>> +     * FAST_STRING is not set should not affect the view of migrating-in guests.
>> +     */
> 
> The logic is ok, but the justification wants to be different.
> 
> "ERMS is a performance hint.  A VM which previously saw ERMS will
> function correctly when migrated here, even if ERMS isn't available."
> 
> What Xen chooses to do with the bit isn't relevant to why we
> unconditionally set it in the max featureset.

It's different words for effectively the same thing, to me at least. I can
certainly use your wording, ...

>> @@ -567,6 +573,16 @@ static void __init guest_common_default_
>>          __clear_bit(X86_FEATURE_RTM, fs);
>>          __set_bit(X86_FEATURE_RTM_ALWAYS_ABORT, fs);
>>      }
>> +
>> +    /*
>> +     * We expose MISC_ENABLE to guests, so our internal clearing of ERMS when
>> +     * FAST_STRING is not set should not propagate to guest view.  Guests can
>> +     * judge on their own whether to ignore the CPUID bit when the MSR bit is
>> +     * clear.  The bit being uniformly set in the max policies, we only need
>> +     * to clear it here (if hardware doesn't have it).
>> +     */
> 
> "ERMS is a performance hint, so is set unconditionally in the max
> policy.  However, the guest should default to the host setting."

... also here.

>> +    if ( !raw_cpu_policy.feat.erms )
> 
> This wants to be the host policy, not the raw policy.  That's why
> `cpuid=no-erms` isn't working in the way you'd expect.
> 
> cpuid=no-$foo means "Xen should behave as if $foo wasn't reported by
> hardware", and that includes not giving it to guests by default.

Hmm, interesting. That's definitely not the meaning I give this. To me it
means merely Xen shouldn't use the feature (with an impact on guests only
when the feature in hardware is required to surface it to guests). I
don't think we have the precise meaning of this option written down
anywhere?

>> +        __clear_bit(X86_FEATURE_ERMS, fs);
>>  }
>>  
> 
> It occurs to me that there are quite a few examples of clear/cond-set
> which could be converted to cond-clear like this
> 
> I'll do a prep patch to make things consistent.  It shouldn't conflict
> with this, but I'd prefer to keep the function logic consistent; it's
> hard enough to follow already.

Right, I too noticed that there are others which could be swapped over.
I actually had it the other way around in early versions of the series,
and it was only in the course of some re-work where I noticed it might
be a little tidier this way. But I first wanted to see whether perhaps I
have some thinko there, so didn't want to convert anything pre-existing.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 15:51:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 15:51:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026730.1401921 (Exim 4.92)
	(envelope-from )
	id 1uUosy-0006If-Pw; Thu, 26 Jun 2025 15:51:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026730.1401921; Thu, 26 Jun 2025 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 1uUosy-0006IY-NU; Thu, 26 Jun 2025 15:51:36 +0000
Received: by outflank-mailman (input) for mailman id 1026730;
 Thu, 26 Jun 2025 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 1uUosx-0006IS-JT
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 15:51:35 +0000
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com
 [2a00:1450:4864:20::42f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6fae8573-52a5-11f0-a30f-13f23c93f187;
 Thu, 26 Jun 2025 17:51:34 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3a548a73ff2so1103015f8f.0
 for ; Thu, 26 Jun 2025 08:51:34 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23abe3f4001sm1126535ad.162.2025.06.26.08.51.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 26 Jun 2025 08:51:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6fae8573-52a5-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1750953094; x=1751557894; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=XMH7NJmQpgEZtIptyfWpGZKvZi25xkE+dUzrCuXHHlY=;
        b=OxXqTP1t8CMJMPLESMeqztTFAHWPB/Su377qwrxwV8+0xeA9Sggao9Drlw1b9u6b+K
         6lhTnEe5eD287KZQVzLhX0nYrDrkuw6la9jnodQfvFlJC2fkzGte1709zzyW4QegWwtB
         GtoAl6J301DUZKKXnCx9Z4LsKEIdpw4N2Hsz9HlwnNOOln6fzTjB0+CEsjJo+HDbANEE
         eyt33UkTlMdfh0p17zDJ5Rz+GAjlMi5qavfR4qZMn1Tzw3o3lhU4QOlG15Aq12977BQZ
         6kFm7AcrRZxXHkpUljnqAKOr7K+6IC9ASpHKluTSVYWxqtG1hX6C5P0bvj4rZLE2gy9z
         /JFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750953094; x=1751557894;
        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=XMH7NJmQpgEZtIptyfWpGZKvZi25xkE+dUzrCuXHHlY=;
        b=WFeUvNW26qPEmAAr25G3KfixMiFnJhjx4nHw7DJVF3ytno2wb6yl4JYN6vVbgU+GRZ
         uzIwYC7m90K6gdOs9rVpchAXof2OORxxxf2Omo4E+lJk7s08qLWiTbBr7j8nJ3yHn0Ja
         75ReYGqLgC+V81+3LjlhjPCortC4VcF3AyUBDJSGVySTk8GzCowFYw/gKUlece/k69ss
         1/mdWUAFOc5S5JfRu0MAbRmDu9Lko5oYqbyodoMi7zvyz9JA1h3d5iPa++zfFwbzdVQa
         TdboFi153jXFQybE/Mx1Na50yeS8SWG7JJFQ0jR6kYdsr925I2mIpYvv86ztb2pLCO3F
         yRnw==
X-Forwarded-Encrypted: i=1; AJvYcCXjUoeOozwpPupEou9JljwYTWcaa6WggQKUp+A/V9Kq9O50pNhwi0WMt/kW1ZDD9CuKVvxLAFIcnzM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz18g4MnJfglxAStcZRR7KtK4ZS0fGLBabQIavoA1S/yWNQW5Ro
	wqYJjWu4X/h255hq2hZtvk7RWDpxfT89GCGCejpnHqykF/F3L6ATjpM1AKGQBR7EjA==
X-Gm-Gg: ASbGnctre8HzdqV9HjS9LerplEt1jGinvTFaS2Ng97P5Wa7tuFKa6kGYJHHoOvaDbil
	fJvKmmf7PhaOh6xSsigDZXZs6aShnaKUyBJWjTvfz6pFjx3h2h3akYNHgKkRLot4ZrdwXhfQNck
	KVj4jolKIqFzxCydGYNGEjr8gKLrGEUubafnzTzKzxc7nAHmnyKCsKrmwisBuUit5AP6IpvCClp
	KFttAgOSRSvZi3dTRSofGd+kMBDXR7sgoj171RppDRmTwJT0BiGJMur+18GIFgqDQuXHctT9UfN
	lggthkqmD3rtY7s4zP4bH86wCY44GB9i8V+ZYMe0LuEjSS6EME6lKz3kahOS1/ijrfseVXYk51S
	aGq3/AHhbmMcHCGXDZxRl3bAr7G3w8vTwDv6fNPEO0qiJqro=
X-Google-Smtp-Source: AGHT+IHjsauj8msB2NXjd4GJqODEZwb2GxtPJmR3Uiw5/UijiBGjpbMETmDnCasg9rO4ehdoeHwrJw==
X-Received: by 2002:a05:6000:2a88:b0:3a5:8905:2dda with SMTP id ffacd0b85a97d-3a8f4549d3amr37874f8f.43.1750953094002;
        Thu, 26 Jun 2025 08:51:34 -0700 (PDT)
Message-ID: <2e35ed6d-f9a5-48c7-8e81-6f5daa5c16d7@suse.com>
Date: Thu, 26 Jun 2025 17:51:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 00/18] xen: introduce CONFIG_SYSCTL
To: Penny Zheng 
Cc: ray.huang@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini ,
 "Daniel P. Smith" ,
 Dario Faggioli , Juergen Gross ,
 George Dunlap ,
 Nathan Studer ,
 Stewart Hildebrand ,
 Bertrand Marquis ,
 Volodymyr Babchuk ,
 Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Oleksii Kurochko ,
 xen-devel@lists.xenproject.org, xen-devel@dornerworks.com
References: <20250616064128.581164-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: <20250616064128.581164-1-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.06.2025 08:41, Penny Zheng wrote:
> It can be beneficial for some dom0less systems to further reduce Xen footprint
> via disabling 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:
> - sysctl
> - domctl
> - hvm
> - physdev
> - platform
> 
> This patch serie is only focusing on introducing CONFIG_SYSCTL. Different
> options will be covered in different patch serie.
> 
> Features, like LIVEPATCH, Overlay DTB, which fully rely on sysctl op, will
> be wrapped with CONFIG_SYSCTL, to reduce Xen footprint as much as possible.
> 
> It is derived from Stefano Stabellini's commit "xen: introduce kconfig options to
> disable hypercalls"(
> https://lore.kernel.org/xen-devel/20241219092917.3006174-1-Sergiy_Kibrik@epam.com)
> 
> Penny Zheng (16):
>   xen/x86: remove "depends on !PV_SHIM_EXCLUSIVE"
>   xen/xsm: wrap around xsm_sysctl with CONFIG_SYSCTL
>   xen/sysctl: wrap around XEN_SYSCTL_readconsole
>   xen/sysctl: make CONFIG_TRACEBUFFER depend on CONFIG_SYSCTL
>   xen/sysctl: wrap around XEN_SYSCTL_sched_id
>   xen/sysctl: wrap around XEN_SYSCTL_perfc_op
>   xen/sysctl: wrap around XEN_SYSCTL_lockprof_op
>   xen/pmstat: introduce CONFIG_PM_OP
>   xen/sysctl: introduce CONFIG_PM_STATS
>   xen/sysctl: wrap around XEN_SYSCTL_page_offline_op
>   xen/sysctl: wrap around XEN_SYSCTL_cpupool_op
>   xen/sysctl: wrap around XEN_SYSCTL_scheduler_op
>   xen/sysctl: wrap around XEN_SYSCTL_physinfo
>   xen/sysctl: make CONFIG_COVERAGE depend on CONFIG_SYSCTL
>   xen/sysctl: make CONFIG_LIVEPATCH depend on CONFIG_SYSCTL
>   xen/sysctl: wrap around arch-specific arch_do_sysctl

When thinking about whether to commit part of the series, it occurred to me that
to avoid transiently regressing shim (in size), shouldn't the currently 1st patch
be moved to be 2nd to last, and then be committed together with the last one? In
any event the plan right now is to commit some patches from the beginning of this
series, but specifically without patch 1. Please shout if you see any problem
with this.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Jun 26 21:18:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jun 2025 21:18:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1026977.1401932 (Exim 4.92)
	(envelope-from )
	id 1uUtzM-0001FC-Bd; Thu, 26 Jun 2025 21:18:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1026977.1401932; Thu, 26 Jun 2025 21:18:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uUtzM-0001F5-8g; Thu, 26 Jun 2025 21:18:32 +0000
Received: by outflank-mailman (input) for mailman id 1026977;
 Thu, 26 Jun 2025 21: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 1uUtzK-0001Di-Gr
 for xen-devel@lists.xenproject.org; Thu, 26 Jun 2025 21:18:30 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on2062b.outbound.protection.outlook.com
 [2a01:111:f403:200a::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 19b254f7-52d3-11f0-a30f-13f23c93f187;
 Thu, 26 Jun 2025 23:18:28 +0200 (CEST)
Received: from BN9PR03CA0455.namprd03.prod.outlook.com (2603:10b6:408:139::10)
 by MN0PR12MB6269.namprd12.prod.outlook.com (2603:10b6:208:3c3::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.29; Thu, 26 Jun
 2025 21:18:23 +0000
Received: from BL6PEPF0001AB59.namprd02.prod.outlook.com
 (2603:10b6:408:139:cafe::6b) by BN9PR03CA0455.outlook.office365.com
 (2603:10b6:408:139::10) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8880.17 via Frontend Transport; Thu,
 26 Jun 2025 21:18:23 +0000
Received: from SATLEXMB03.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.8880.14 via Frontend Transport; Thu, 26 Jun 2025 21:18:23 +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, 26 Jun
 2025 16:18:23 -0500
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, 26 Jun
 2025 16:18:22 -0500
Received: from [172.28.201.131] (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, 26 Jun 2025 16:18:21 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 19b254f7-52d3-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=icWI1a5JOUG8T4Tr/Ibk+ModEVr7yFpjSXy1wb2L4Q1Lodil74PEsR4TZFB43Da80gXNPXl2GmkzOR6UQ8yucuFMctP1dvvG4cxEHXk5sMcARbEnVC4ZAUpetQoetiJxhdlzxN/l6o6nUv2HZLZ0X5h+UPiKXefnNj+MEt1EkAtl1xRNc5q67rusjXoRL6qN4AEuzJa7A42vcfwJU0AeIg0lnXAll70WUysZzOtY+GuvXHp7wcc3/IqJsO570fuk3mxvdBlUn1EeitVS8kSwd7LA6Y1FEOHrFYPu2Kfz7LdV3sBUpZrAUXA0fGvCZh6L0hg7/YZWFpozRs/ieJb3Iw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=gG9SC/bbvUjsp3Sqt+FjZ4EKyg2m1ayJDhBQ3M3nfpE=;
 b=U2rHQA1cVcXENcwDZNj7uj15MTzSptq2oZdZSd9+dimHoitI5oxy07ekc/7OUOxTMS+SDipkOgL8tamHOkTKm2cjUV1Avfd9hWox+dJCtDIbIRDNF3vK9b8JmDUQGRJbHb76JmoeGNNUfk6YqQZF9V9IWPL+3MBkZKb3umBeY1yho2iddlkLOTariQhy50OW+JgpOUGePt6mbV+NbVH/H0Zf8xiHlvX/FkeygynSg1+v/zC5L/2LwEkQwi3h4KUzHfWSkwaGxtfwpts3FuQcBZCbiwOtaUwwgbCEmcCAOV+FwPpGYINeQ6fEvYwZww/3aKbtxmqFgHeRGnDTYuhPhw==
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=gG9SC/bbvUjsp3Sqt+FjZ4EKyg2m1ayJDhBQ3M3nfpE=;
 b=hnoTPZ6+/58IW/gdqs1tsFeZGjpzYBmC0syK2XNOfETk6TMK4RWZG7Q6bMZ4Qe25h/G3dYHCbWQDvFQeWgaRrC9X1Uvq6h44jTCATlCzDmGyiTPu+hiIEUmMRFqaJLYUO5FAE51xD/IRwB9Ss42MT0j+l1hIMsjSOnIbgvqxorI=
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: <96104098-0369-4607-b378-60b80bb0f560@amd.com>
Date: Thu, 26 Jun 2025 17:18:21 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: hardware domain and control domain separation
To: Jan Beulich 
CC: Julien Grall , Bertrand Marquis
	, Michal Orzel , "Andrew
 Cooper" , Anthony PERARD
	, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	, , ,
	, Stefano Stabellini 
References: 
 <942a6178-0fe7-468e-8e45-ea255fd20680@suse.com>
 
 
 <381dba84-3108-42c8-a4e5-7bc74d5e1075@suse.com>
 <2e27e128-398a-4714-b019-eab04520cc97@amd.com>
 <48def2b5-44ad-45fa-b052-67520c0961f0@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <48def2b5-44ad-45fa-b052-67520c0961f0@suse.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL6PEPF0001AB59:EE_|MN0PR12MB6269:EE_
X-MS-Office365-Filtering-Correlation-Id: fe136fcc-c18f-4be2-2e99-08ddb4f6fbc6
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?Y2t5V0VXNmxTSTlLMHBLVC9remljRU5xVzRzTHhkNmd2WnJDWWxpUEhxUng0?=
 =?utf-8?B?YTA4KzRobnBCcm1Pcno4MFo5TGx1TGRwNHpJWDJJS0lqdktFRFFaUW5Gb01Y?=
 =?utf-8?B?aCt3VEJ3RndiWjBGUy9BMTFkUEZpTVRTcU5majB6cTNIZ2s4YkFIYitaaFlT?=
 =?utf-8?B?L0k2MW1HdWhKL0pkK2VGRGNiaXF1ZDBjcmdVcmY2NWRoVnNMaDViR1VOR29Q?=
 =?utf-8?B?cy9rWDM1a2M1UE9CbEcvei96SmlMZ1lnS3JQVU9tUHVpTyswd3NWRnI5Y2JB?=
 =?utf-8?B?dmIyRW0zZGFSWHVTOHV5ZFFwdGZBS2NvbXJleFowcTNKbm1kNFJlMTlvK2k4?=
 =?utf-8?B?TzJEQ0dsTW1xTDlaTk9jZktwdGdtNUh3WlJIU0ZtRnQrU3k4ZjZGeUx0bE5i?=
 =?utf-8?B?c2hxTFZtejRyNXZJWnprWXJDYjZGenM3amp4VGc3d0RsRm0wTTBKU2NpVS9C?=
 =?utf-8?B?NVhIUGlMd3A3aUU3R2ZOYklzL1A2NzNtcG85bCsvSm5aYlRrOGp0ZVBwSmVq?=
 =?utf-8?B?STRid3VsanNEY1ZaK2daRmxhVWdmRlg0NVpFRlZHSjJPOUhpSDVRQW14RzJa?=
 =?utf-8?B?RVFCTkZqMkhJM2E3REhHeUxHcHhtM3RXU3Z5WkRaV01KWThDMnJoemJLNFo5?=
 =?utf-8?B?ek5sL3hzRU9EVEZGODVlOHl3OFZUU0tqc052NnlSa24vb0gxN3U4S1hrdGFj?=
 =?utf-8?B?NGlBbmFqQzR5c3M2azdvb1dMeVJLZk9qbFFPVHZtdWhic0tGQnJrTE03OGZ1?=
 =?utf-8?B?cVIzV2I5ZTEyUk5JWVdrM3p5MlVHcHRseHprUWZmbzhIRHdJeUJtaTlGaGRv?=
 =?utf-8?B?L1ZqMDRLR29QRWpLaUFOOThwZ0RnMWVzSS9VQ09WVmJEOVJsVVB2cEszVlVQ?=
 =?utf-8?B?eXZvZ1R6ek9DS3hCT1dGNzNZUFZHMzJyK2t1ajJ2bXJUTTFuSHNjcms2OXMw?=
 =?utf-8?B?OENMZ0NPVTFFNDNWdW5ibFVkSjR5akowWENiWlM0SkN1bXVCMWdyOFkyQmdl?=
 =?utf-8?B?SldGU2VYWjJoaHBveTlncmJEaW5xYVFmemNCanhEdDZ4SStkWGpLdko3blVQ?=
 =?utf-8?B?Mmg5d2hKUVRoSk9FbVI4cnVRcFppcElCUUZqTFhSakFDYms2N1JLaEJVTVp1?=
 =?utf-8?B?TzBXcGRUSHhWMy9JVnlMM0xsdmNuc2VaaVo2MVA1RHBtaGNYaFRkT1BIQ2ZX?=
 =?utf-8?B?TERJQmFwWVJZYnI3ZlIzSWhyT3E3VUtzaFVoWkxjbFphZTdDUW00emw4MHRY?=
 =?utf-8?B?b0JLdXNiZUJUZ3ppalFhbldONGJsR1JzVTY3b3p3YU9DS1c1bDlQMHlySzUx?=
 =?utf-8?B?MFJWS1FySEFzdnFTREdRRk10amF5dWl0WVFOMVVNaEk2NmZaNS84M28rc3FZ?=
 =?utf-8?B?UGdPWUk0UXMvZURlQWVsekJYSUVZVEFubjVOdXBGb0g1amx6Y3FXR29QeW1B?=
 =?utf-8?B?RWVMN0hmUlVWeU9NYlZNTytmUHp2bktkdVV1ZDVnajlMRTdsNnlOcUxOVnY3?=
 =?utf-8?B?WTFsOVNxOFlxcjEzSHBzOHBSQnFwT05tRFkrTDYvUitKUGI4QmpnaVE2UDVX?=
 =?utf-8?B?RFRmR3UwNlJjUDN4dDNSNzhXbGJBUWFvdFI5SWtsL0tDN2pGSUR0bi9JeHNN?=
 =?utf-8?B?a0lHYitXOHhlT1kxMkE2L3NBRU5xNFM5Q1YzdGtNS0kzVUk4QjJGaVdMcDZl?=
 =?utf-8?B?UE1wWEx3SmJqTEJqdmxyVDJzbVRzK2NjS0VwL004V2Qza081NzJjaElrWCtW?=
 =?utf-8?B?WmgyTjhLejA4bGphSEducmVxWHlBWkdZeS9kVWlrelJQaXF1N0xKQkkvRjdG?=
 =?utf-8?B?R29wNmdiQUMwRWVwaklUNlh1a3cxdnNxeHBaNXRUbVNhK0lvbkRCMW92ZDFX?=
 =?utf-8?B?NDFoL3VXQy9vR1A3T1FhWmFoSEQ2NzBneEdiVUJ6WldTd2Iydkt3Uk00RHlT?=
 =?utf-8?B?cXF6NHFITEpSTkdiZzdXYm41OStQUUdkeVpMUSswQVp6MVRpR0FMU3lzOUV4?=
 =?utf-8?B?MC93dWFJSjFQL3ZCT2tXNUttQU8rcHV5M0d3ZUh5ME5kemFteHZZNzFLZ0Ri?=
 =?utf-8?Q?naJCe5?=
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: 26 Jun 2025 21:18:23.5058
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: fe136fcc-c18f-4be2-2e99-08ddb4f6fbc6
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:
	BL6PEPF0001AB59.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6269

On 2025-06-25 01:32, Jan Beulich wrote:
> On 24.06.2025 22:14, Jason Andryuk wrote:
>> On 2025-06-24 01:25, Jan Beulich wrote:
>>> On 24.06.2025 00:51, Stefano Stabellini wrote:
>>>> On Mon, 23 Jun 2025, Demi Marie Obenour wrote:
>>>>> On 6/23/25 11:44, Jan Beulich wrote:
>>>>>> On 21.06.2025 02:41, Stefano Stabellini wrote:
>>>>>> Also a more fundamental question I was wondering about: If Control had
>>>>>> full privilege, nothing else in the system ought to be able to interfere
>>>>>> with it. Yet then how does that domain communicate with the outside
>>>>>> world? It can't have PV or Virtio drivers after all. And even if its
>>>>>> sole communication channel was a UART, Hardware would likely be able to
>>>>>> interfere.
>>>>
>>>> There are well-established methods for implementing domain-to-domain
>>>> communication that are free from interference, such as using carefully
>>>> defined rings on static shared memory. I believe one of these techniques
>>>> involves placing the indexes on separate pages and mapping them
>>>> read-only from one of the two domains.
>>>
>>> How's that going to help with the backend refusing service, which I view
>>> as one "method" of interference? Or else, what exactly does "interference"
>>> mean in this context? (More generally, I think it is necessary to very
>>> clearly define terminology used. Without such, words can easily mean
>>> different things to different people.)
>>
>> Yes, there are different kids of interference.  We are concerned about a domain blocking another domain.  The main example is an ioreq blocking a vCPU.  The blocked domain is unable to recover on its own.
> 
> On which insns an ioreq server may kick in can be well known. A kernel
> can therefore, in principle, come with recovery code, just like it can ...

The case I am thinking of is QEMU providing a virtio device to a domain. 
  The domain has to write to a MMIO area in a BAR to notify QEMU.  From 
my understanding, that vCPU is blocked in Xen until QEMU responds to the 
ioreq.  I don't see how any recovery code is possible, but I may be 
missing something.

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Fri Jun 27 03:00:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 03:00:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027154.1401942 (Exim 4.92)
	(envelope-from )
	id 1uUzJt-00063t-0l; Fri, 27 Jun 2025 03:00:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027154.1401942; Fri, 27 Jun 2025 03: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 1uUzJs-000639-Ro; Fri, 27 Jun 2025 03:00:04 +0000
Received: by outflank-mailman (input) for mailman id 1027154;
 Fri, 27 Jun 2025 03:00: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 1uUzJs-0005rj-7P
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 03:00:04 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20610.outbound.protection.outlook.com
 [2a01:111:f403:2413::610])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ce746c5e-5302-11f0-b894-0df219b8e170;
 Fri, 27 Jun 2025 04:59:58 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by CY1PR12MB9700.namprd12.prod.outlook.com (2603:10b6:930:108::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8880.21; Fri, 27 Jun
 2025 02:59:53 +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.8835.027; Fri, 27 Jun 2025
 02:59: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: ce746c5e-5302-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=acwLxqDpnxWsAD5O3P/BxoFsKelaKBBVa/oHQuRIxWX0SpfskWJ75G75+N/Yh5ez5sxHdsw9VnkMdSjguSyO7bdswo1g4m3CQlXsxbK0G0zVei6Gp4q0FyjlppsBzX8oYVAGteQ9rCBiT71y3LtxpX3/FCZcXoIM7kOXu09ziHIZVkKcrIipEXo8+Kb4Mrvx7mt5zq2HaTuyVyCiaJ/f5rc4D0G2cMHukLlZvSla5YjG2sbsKOdGEvP+TB+J9Q0lqMGWj/1PfNgxevKgJ+WDc4Pc5tIAIxSFLnmidyJ+PDZNlPXQS9sYSboUKdk/JSuGpc+fHDId1GpSdSLRZKTKeQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=U+jRtypYYzqLpyKsu5gjznzXitFwFM4JD46DDheDFm0=;
 b=t/s+VXipE5fbkYkaqJEbWNY05S+MisN618F0ZQ7ZwkCOwSOKFlORf2yEh2u255R1yEaZun4IZo9/tQSzZ1QlkLranC8wk6urTauCrDrlOs6jIXgy/NsjMG0s7NlYbSkYTxmT9JWahCx/drTTZDiNkkfm3BpDMjpwq96l613sGX9i+okOwaIxWNv4ripiklPZUmKOVHtXdeBpKH79ldYeGyLeo0KhHDPai9FpmmGWePbuClUy4vvvpNj0246pBeJ/7Xq7/ZexVw5ihZ74iZw24KnjXnIjGPGVLJq8WMK5b+tVQILjyMtF3pHJxsepPuUJBf6CABSgfLAdhcUCxNN0ig==
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=U+jRtypYYzqLpyKsu5gjznzXitFwFM4JD46DDheDFm0=;
 b=uW3h+dkvR78BfpStbmXzi/PK2nuVinjWI6L2VH62QE4JaNBNmo06BXXgVwgXBaaZqdXZ3fZI7XHM861a6rrPhyRk29PQzEVYjvXrQ1z/EDxiFANrPCV2dboGEgJw013p+Jb2QT8kE4B3NsQrpp9B1WycWoAHCdZPbAW/KDZHxIg=
From: "Chen, Jiqian" 
To: Jan Beulich 
CC: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Andrew Cooper
	, Anthony PERARD ,
	"Orzel, Michal" , Julien Grall ,
	Stefano Stabellini , "xen-devel@lists.xenproject.org"
	, "Huang, Ray" , "Chen,
 Jiqian" 
Subject: Re: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
Thread-Topic: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
Thread-Index:
 AQHb23yakGdVC9XxvEWnYcnp8zrTt7QI/QAAgAGa9QCAAQzVgIAG5D6A//99hgCAAJwoAP//hioAgAHew4D//5oCgAASTfCA//+FrwCAAIi+gP//u5+AgAGwYID//8AMgIABfE8A
Date: Fri, 27 Jun 2025 02:59:53 +0000
Message-ID:
 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 
 <227df6d3-a2c3-4576-bde9-d8057c378e7a@suse.com>
 
 <5c4b186e-686e-4fc8-bcf1-854bc1f5ec8b@suse.com>
 
 <9d5d0e44-66c3-4e3f-8704-2c862c5f5aff@suse.com>
 
 <3638e73c-2a83-4164-9a84-839245245727@suse.com>
 
 <771cd5b7-2b89-49b1-9aba-8cd79319d3ce@suse.com>
 
 <7753470a-efef-478a-bbe5-ae48d008cfdb@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.8835.025)
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_|CY1PR12MB9700:EE_
x-ms-office365-filtering-correlation-id: a0fd2a9f-c7ca-4e32-76ed-08ddb526b09d
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?SW5Zemt6Z3RZRU1vUStkVjQxUGVXTmowRWhpaHdhSlpiYlVIUGhJSml3eStr?=
 =?utf-8?B?RngzR3RSbysyS3ZTNXJ3cmZtczNZTHl3aWl5UUh4YnZRSHlJNXpJekQ2Ykhy?=
 =?utf-8?B?UVpOSzAwWWM0UUxyamx0ajBvRGlTWXdrZjB3ZW5aa040Zy9iT2ptbXdEcXh2?=
 =?utf-8?B?NzlGN0VvWWEyTzZRZGZwSXBZeUc0SEZIU2twZk5uaUJlMVJQMk1ZM0NPSzlU?=
 =?utf-8?B?ako4VGlLc1JTR1Y0aVBScU5DTDl4dzI5di93aHZkUTBBNkxPSjhjMDRva2pw?=
 =?utf-8?B?V2RwcG1rTy9vMFlNcFNRMFA2VGpGLy9sd0JUU1pxR21DaE45RWNITURBbGxw?=
 =?utf-8?B?bWN4bUlqaVZWbE1BYUs4RGJqMEVGdFBpalVzckZVWHBmVVR2QjM0ZEdPN1Vm?=
 =?utf-8?B?bnVocUVHOVk2aTM1UnYxT1RxVU5vaExGem41MGtUU25sOUFneXk5c2ltRW93?=
 =?utf-8?B?Nkx3VFNMVkUyZUZpOUQ4WXduME5HdWxqQWRXOWRDM0FJQjI0V0ZXY1RYako2?=
 =?utf-8?B?Smx3bmZpT1RJcXBCaFJ4emVVY1VEVWx5b3Zja0FQVGJ2eEpnb2pzNjEyQVoy?=
 =?utf-8?B?QW0wRDJqa2hvUndlcTUwOWZaeU90N0xjWEs1Z1lsQURSTkIyeHFLNDhsYnkx?=
 =?utf-8?B?OExQMGx1WmhPUzJZbWVhOEh5RjRZZjRZQkhKdVc2cmZlYlN4QklwSXdhWEx5?=
 =?utf-8?B?RVR6b1lGT2t0Z3JPS0VUbU9FUzJqN3ZLbmJNREpxaFRDSXoyYnNvbGpGV0RO?=
 =?utf-8?B?VWxBNDNFQkRYeEFEazQyVG5qR01xNjRjcGowdTcwdVZvcjlNS3E1OEVJQ0NM?=
 =?utf-8?B?bmFxNnpBc2ZTcjJmZGJINzhRV2gweDI0Y3N1QjlYSUtucURqeSs3ay9ya0lv?=
 =?utf-8?B?UWVSK0FMK05tWlo3djQ5OW9XbkJLYUREUys5UG5QRUcrWUczTlNRTlM3NW5V?=
 =?utf-8?B?NDU0VWpQQ0dqVHBUR2YzQmQ4VVNmMWR6dzR4TVQyR1JJS01JdGszcDdwMFhx?=
 =?utf-8?B?Q3NwYTNKUWcyYllkcmw2V2JDMVJXQm4zWEtWZW01MFQ0WUQzTk40WlllK0RV?=
 =?utf-8?B?aStHOFBjS1JXVGhMMDdkT1Z2OHNyR2NiYVFFcHlNRUhpeGgwOFdFZTE1Nmg4?=
 =?utf-8?B?RW55YWsvYVR6bjRORHptV3JqUE9wbjkxRnRxVEFsbS9XdDM3d3FRSDdwMkx0?=
 =?utf-8?B?SmNVZ2tOOGRLTlBuOXhhMitnSlh5YjEvSTh3UU1VZy93MUYxRUtHSEl6TkdJ?=
 =?utf-8?B?YURkdTlFZmY3MTNNU0s1K3o5RUhlM2o1R1d5ckJsNzJ2bVgwL0ZtN2NrM3RP?=
 =?utf-8?B?ZEFOY2t1UExsbDFqMGFyK1NrVk9iaHFCenI1MkFiTzg0TjByemp2NGpzdnA0?=
 =?utf-8?B?NXpUNXdVV3Y0VTlNZE11V2F2ZnArU1dkdkZndTBBVmJTaUNDNGxqWElLeFRz?=
 =?utf-8?B?WThtRmNqcVpON2xPNzNFYjRRaHFxc1hTdWh4SkMyVThXVW9meVJVQmtEYjZ4?=
 =?utf-8?B?bXJCS3V2SDZ1bTg3K3FkYUcwU3UrcXVpMG01Qml3RmcxR1NJSDNVUUdnYlIz?=
 =?utf-8?B?aEFFNlpOWERYOXJiZmZwaFFnczYyRjJDVzlQNFhnV0ZsU3NzdkVtSzlLd1JC?=
 =?utf-8?B?WWFvRmVWeTJwTUFOR1QrU1IyYlJVVW9PdTN2cVZINzBQMi9LSk9hZW0zK1RH?=
 =?utf-8?B?aGs4UktrOHRNMlV1bkhqcXZOektESHhBTEdoNEVBa0VUUXJ4NHRMZVdCSjh5?=
 =?utf-8?B?eGpkaGJqK1lPRFdYd2d5OHNKbW4yaFRIdlYyeGVlMThtMm5wWmMzZjhuTE5Y?=
 =?utf-8?B?ZmpQK2tHM2JBMDZnaUM3cGVUcEJyQkpJK2NORHdwTnl4V2NYM2YyVGNzOXRD?=
 =?utf-8?B?Y0g4RGdIMk5qWlp4RkF6SnRUM0xadlhUcnlRbWRjUmFubmN6S1QrN2JCZlVJ?=
 =?utf-8?B?SW5Tc09nK3JqQnZhQmxnRFZRWjlIU2ZuRHRoeFNFeVF5a2pqWWw3NjU4UUM3?=
 =?utf-8?B?cEErYkQycTZRPT0=?=
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?QnAyQWl4Y2JiWGNrTXJzUTlua1FMYTV1aTF1SVhNOFN1R2ZWYW9iTGtDMmxX?=
 =?utf-8?B?UXJGRFRIVkM1a0FBVlZEamwwUU00c2tTaFIzQnFIbHlHalhTdUd2QmpjK3BQ?=
 =?utf-8?B?Z0hVZ09VRjVUQ2lFclJZcURMUURnS0ZWZ0lOc0VZbDdYRldQalpESkRTWEcx?=
 =?utf-8?B?RGNDa3gwLy8rK2IyWk5WOGRaanJuTlNBTDZjR2k0UlQ4NGZycnhSZG5HdkYw?=
 =?utf-8?B?dHQ5NXVBRENNVWRSRlVuVWszYVZSVXRUY1YvOFJnOTJsbjJ0cXJWWUdPVUgz?=
 =?utf-8?B?OWd6eTlySlRQTVJranc4TFJPb3dEVUFpaUxEU3BhRVN5eGxGdzNBbjZqNW15?=
 =?utf-8?B?MjBNL3hYQVhJS0RNY0c0T3FSQm5NellUTzdQaXZVR1pUZk1HSVlWejlKWjY3?=
 =?utf-8?B?Q3dpbnBncUlFR2JzVUVLdGtGajkrNmdjV3ArL0dyd015RDRBU1RGUWdKbGxk?=
 =?utf-8?B?U1Vwdy9WSmZlam82UFJVeWUyVlMxQnI3RkpXT1RvY2hKVUlHN280T1ZoK2pQ?=
 =?utf-8?B?aktGZkZPT0UrT01FNVB3NzRGZ0F3cklnVVV0YjMvcHdGdlFRdG5OQTNvZXlH?=
 =?utf-8?B?bXFHeVYyeE93RmI4UGZpTFNmcmFCa2pWeHh4dXlXdk1yR1ZhNDF6TS9lOWl0?=
 =?utf-8?B?VC9NWk1aWEVKRkZBWDIvelF5Tyt0N1M0RWNyQXIwdnc2aGZDekZwSGxOekhE?=
 =?utf-8?B?V3dKTi92L3g1NmhWUW44ektIQ0VaUzE5a3Q4SzRHSGFITXh3ZnJIQ01SQnVw?=
 =?utf-8?B?ZDQzaktMZEFnN2thVXByTVdqLytSOWNtMWxPNDRsMi9EalpFZ2NoZTFXdDJr?=
 =?utf-8?B?c1N2WWUyV2F6VFhUNVRYK2E1NlNHK3Uvd2d0T3FQUlQ3UThHcGNrMGt1WVVS?=
 =?utf-8?B?R1NSZ2EyU0RoV0VnNDJCUjF5TDNKNHNjaWgvNFNIeFM2QkhGOHI4THdtNW5i?=
 =?utf-8?B?dm1wQjR0Vi9iY3crQUUrc21CSjBTbnhqb1lJOVBtL2tRY0hiK2JGSldMSy8y?=
 =?utf-8?B?TUZUN2pFajdSUmlFMTlSUkxNRk5uMVhVd0hFRzdRVG50Y2pFdEpIbHZ2NEZL?=
 =?utf-8?B?Z1k4MjEzSVNXM2paN3N4bDl3dzEzODdtUlFUZHFwbzk3eUZsU1Zid3BJTjRh?=
 =?utf-8?B?TndleTNWclhZTXV3cEpGS1JrMWhXWUFKM2hSMkdXNGpEUU1Md0JqNmphQWIy?=
 =?utf-8?B?WXZ3WUZtK2VoUkZpNko3R3dGbzNGbkZzU2dYekpVYWdTRllrbGVjRVFtWENw?=
 =?utf-8?B?ZzlnWVFpWG9ZamY2VjFQanBvNEJFeWFWSnRndUF0NmROMTB6ZmwyekI1V1BO?=
 =?utf-8?B?VWZQYTcrWlhBM3FUM3o3UmMzSEZuTFptT3Z5YUcyaVhNdnJleXp4QVRFSjBY?=
 =?utf-8?B?QUZvcUw4eEwrZzRZWkhKSXdOQ0VrKzhrVjFNN1NQa1RLVVVxb09keXo0WDBW?=
 =?utf-8?B?TDhyTDNycExEaTlUVTFEM3RBdHBnTGhEa29EUWdWNTljSzRkU3dHVGV1c2Yv?=
 =?utf-8?B?UDNXaFVoM0NaL2g0QmNDKzNiVnlsOVZ5ZjRwdVVOUHI0ck9nUGlxVHJMNG5V?=
 =?utf-8?B?dXNkaUVqZXIxWmFKNDZ2ZDhIZWxwOXM1RCtlRzlpNFhPSWw1ZENJQkViRG1r?=
 =?utf-8?B?UjhzY3lwamUwWnF2SHoxajNmc1hMN3BlZThEVGJZaHdaZ2NEK2I5SW95UFJQ?=
 =?utf-8?B?T0V5K1B3cXVCKzNnRFNtdTBWTTJMYmkxeVEydVhqMkRKOVowV092YnI0R1dn?=
 =?utf-8?B?NmRlanNCSnZlNXlSbTg3c1ptU0hVT0c4OEhQVjdoc04wazlRanQzczdEcGlu?=
 =?utf-8?B?SGdxSE8rbWdIemZIeUc2UndiN2hNbXZYcXVwZTJQU1FNN0JpTW5RbHhCdzAx?=
 =?utf-8?B?RWhkd0M1OW1DYWpCaThqWm9MSzVwY3FLbkZaZFVoSDM0SzhjRndOYW0vUkNw?=
 =?utf-8?B?b2dlamxMMnc3VXpYbFU3SDE5VFZ0STFic280aUFZN3RnNE1TVW80dHE5L1ly?=
 =?utf-8?B?SytDdWhaaVUrV3pmdS81aEdHVHVRRnFNN21xT21mR05OcE9ZenN1TjArYWpi?=
 =?utf-8?B?S1BheVdYSVhKaUUxR0Nia3cwRzJLdnh3NldKSGJGVGRyVURuLzg5ZHoreERB?=
 =?utf-8?Q?MigU=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: a0fd2a9f-c7ca-4e32-76ed-08ddb526b09d
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2025 02:59:53.2749
 (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: a9WCwHY+ByCT7qvPgh+saLgVNnw8nLJTflUTh3nWH9F7KFbtYUdA6fX6ctwp9N3tRZh+Rel25SMA7X1hXJjZEQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR12MB9700

T24gMjAyNS82LzI2IDIwOjA2LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMjYuMDYuMjAyNSAx
MDowMywgQ2hlbiwgSmlxaWFuIHdyb3RlOg0KPj4gT24gMjAyNS82LzI1IDIyOjA3LCBKYW4gQmV1
bGljaCB3cm90ZToNCj4+PiBPbiAyNS4wNi4yMDI1IDEyOjE2LCBDaGVuLCBKaXFpYW4gd3JvdGU6
DQo+Pj4+IE9uIDIwMjUvNi8yNSAxODowMywgSmFuIEJldWxpY2ggd3JvdGU6DQo+Pj4+PiBBbHNv
LCBhcyBzYWlkIC0geW91IHdpbGwgbmVlZCB0byBjaGVjayB3aGV0aGVyIG90aGVyIGFyY2hpdGVj
dHVyZXMgYXJlDQo+Pj4+PiBkaWZmZXJlbnQgZnJvbSB4ODYtNjQgaW4gdGhpcyByZWdhcmQuIFdl
IGJldHRlciB3b3VsZG4ndCBsZWF2ZSBhIHRyYXAgaGVyZSwNCj4+Pj4+IGZvciB0aGVtIHRvIGZh
bGwgaW50byB3aGVuIHRoZXkgZW5hYmxlIHZQQ0kgc3VwcG9ydC4gSS5lLiBteSByZWNvbW1lbmRh
dGlvbg0KPj4+Pj4gd291bGQgYmUgdGhhdCBpZiBpbiBkb3VidCwgd2UgcHV0IHRoZSBfX2FsaWdu
ZWQoKSB0aGVyZSB1bmNvbmRpdGlvbmFsbHkuDQo+IA0KPiBOb3RlIGhvdyBJIHVzZWQgX19hbGln
bmVkKCkgaGVyZS4gV2h5IHdvdWxkIHlvdSAuLi4NCj4gDQo+Pj4+IFRoYXQncyBkaWZmaWN1bHQg
Zm9yIG1lIHRvIGNoZWNrIG9uIGFsbCBkaWZmZXJlbnQgcGxhdGZvcm1zIHNpbmNlIEkgZG9uJ3Qg
aGF2ZSB0aGVtIGFsbC4NCj4+Pg0KPj4+IFlvdSBkb24ndCBuZWVkIHRvIGhhdmUgdGhlbS4gWW91
J2QgbmVlZCB0byBjYXJlZnVsbHkgZ28gdGhyb3VnaCB0aGUgcmVzcGVjdGl2ZQ0KPj4+IHNlY3Rp
b24ocykgb2YgdGhlaXIgcHNBQkktcy4NCj4+Pg0KPj4+PiBTbyB5b3UgbWVhbiBJIHNob3VsZCBy
ZW1vdmUgIiNpZmRlZiBDT05GSUdfWDg2Ij8gSnVzdCBsZXQgX19hbGlnbmVkKDE2KSBmb3IgYWxs
IHBsYXRmb3Jtcz8NCj4+Pg0KPj4+IFllcy4gQW5kLCBhcyBhbHNvIHNhaWQsIHdpdGggYSBzdWl0
YWJsZSBjb21tZW50IHBsZWFzZS4NCj4+IEFoLCBteSBjb21tZW50IGRlZmluaXRlbHkgbmVlZHMg
eW91ciBjaGFuZ2Ugc3VnZ2VzdGlvbi4NCj4+IEkgd3JvdGUgYSBkcmFmdCBhcyBiZWxvdzoNCj4+
DQo+PiAvKg0KPj4gICogU2l6ZSBvZiB2cGNpX2NhcGFiaWxpdHkgaXMgbGFnZXIgdGhhbiA4IGJ5
dGVzLiBXaGVuIGl0IGlzIHVzZWQgYXMgdGhlIGVudHJ5DQo+PiAgKiBvZiBfX3N0YXJ0X3ZwY2lf
YXJyYXkgaW4gc2VjdGlvbiwgaXQgaXMgMTYtYnl0ZSBhbGlnbmVkIGJ5IGFzc2VtYmxlciwgdGhh
dA0KPj4gICogY2F1c2VzIHRoZSBhcnJheSBsZW5ndGggKF9fZW5kX3ZwY2lfYXJyYXkgLSBfX3N0
YXJ0X3ZwY2lfYXJyYXkpIHdyb25nLCBzbw0KPj4gICogZm9yY2UgaXRzIGRlZmluaXRpb24gdG8g
dXNlIDE2LWJ5dGUgYWxpZ25lZCBoZXJlLg0KPj4gICovDQo+PiBzdHJ1Y3QgdnBjaV9jYXBhYmls
aXR5IHsNCj4+ICAgICB1bnNpZ25lZCBpbnQgaWQ7DQo+PiAgICAgYm9vbCBpc19leHQ7DQo+PiAg
ICAgaW50ICgqIGluaXQpKGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZGV2KTsNCj4+ICAgICBpbnQg
KCogY2xlYW51cCkoY29uc3Qgc3RydWN0IHBjaV9kZXYgKnBkZXYpOw0KPj4gfSBfX2F0dHJpYnV0
ZV9fKChhbGlnbmVkKDE2KSkpOw0KPiANCj4gLi4uIG9wZW4tY29kZSB0aGF0IGhlcmU/DQpUaGF0
IGJlY2F1c2Ugd2hlbiB1c2luZyBfX2FsaWduZWQoKSB3aXRob3V0IENPTkZJR19YODYsIEkgZ290
IGNvbXBpbGUgZXJyb3INCnZwY2kuaDoxODoxMzogZXJyb3I6IGV4cGVjdGVkIGRlY2xhcmF0aW9u
IHNwZWNpZmllcnMgb3Ig4oCYLi4u4oCZIGJlZm9yZSBudW1lcmljIGNvbnN0YW50DQogICAxOCB8
IH0gX19hbGlnbmVkKDE2KTsNCiAgICAgIHwgICAgICAgICAgICAgXn4NCkkgdHJpZWQgc29tZSBt
ZXRob2RzLCBvbmx5IG9wZW4tY29kZSBjYW4gZml4IGl0Lg0KDQo+IA0KPiBBcyB0byB0aGUgY29t
bWVudDogRmlyc3QsIGl0IHdhbnRzIHRvIGJlIGFzIGNsb3NlIHRvIHdoYXQgaXMgYmVpbmcgY29t
bWVudGVkIGFzDQo+IHBvc3NpYmxlLiBIZW5jZQ0KPiANCj4gc3RydWN0IF9fYWxpZ25lZCgxNikg
dnBjaV9jYXBhYmlsaXR5IHsNClRoaXMgYWxzbyBnb3QgdGhlIGNvbXBpbGUgZXJyb3IuDQo+IA0K
PiBpcyBsaWtlbHkgdGhlIGJldHRlciBwbGFjZW1lbnQuIFNlY29uZCwgdGhlcmUncyBub3RoaW5n
IGhlcmUgdGhlIGFzc2VtYmxlciBkb2VzDQo+IG9uIGl0cyBvd24uIEl0J3MgdGhlIGNvbXBpbGVy
IHdoaWNoIGRvZXMgc29tZXRoaW5nIChpbnNlcnQgYWxpZ25tZW50IGRpcmVjdGl2ZXMpLA0KPiBh
bmQgb25seSB0byBmb2xsb3cgY2VydGFpbiBydWxlcy4gKFNlZSAieDg2OiBkb24ndCBoYXZlIGdj
YyBvdmVyLWFsaWduIGRhdGEiDQo+IHRoYXQgSSBDYy1lZCB5b3Ugb24gZm9yIHNvbWUgb2YgdGhl
IHJlbGV2YW50IGFzcGVjdHMuKSBUaGF0IGlzLCB5b3UgZG9uJ3Qgd2FudA0KPiB0byAiYmxhbWUi
IGFueSBwYXJ0IG9mIHRoZSB0b29sIGNoYWluLCBhdCBsZWFzdCBub3Qgd2hlcmUgaXQncyB0aGUg
dW5kZXJseWluZw0KPiBBQkkgdGhhdCBtYW5kYXRlcyBjZXJ0YWluIGJlaGF2aW9yLiBUaGVyZSdz
IGFsc28gbm8gc3Ryb25nIG5lZWQgdG8gdGFsayBhYm91dA0KPiB0aGUgc3BlY2lmaWMgZWZmZWN0
cyB0aGF0IGl0IHdvdWxkIGhhdmUgaWYgd2UgZGlkbid0IGFycmFuZ2UgdGhpbmdzIHByb3Blcmx5
Lg0KPiBUaGF0IGlzLCB0YWxraW5nIGFib3V0IHRoZSBlZmZlY3Qgb24gYXJyYXlzIGluIGdlbmVy
YWwgaXMgZmluZSBhbmQgaGVscGZ1bC4NCj4gVGFsa2luZyBhYm91dCBfX3tzdGFydCxlbmR9X3Zw
Y2lfYXJyYXkgaW1vIGlzIG5vdC4NCj4gDQo+IFdoaWxlIGZ1cnRoZXIgcGxheWluZyB3aXRoIHRo
ZSBjb21waWxlciwgSSBub3RpY2VkIHRoYXQgYWRkaW5nIF9fYWxpZ25lZCgxNikNCj4gYWN0dWFs
bHkgaGFzIGEgbmVnYXRpdmUgZWZmZWN0IGFzIGxvbmcgYXMgdGhhdCBvdGhlciBwYXRjaCBpc24n
dCBpbiB1c2U6IFRoZQ0KPiBzdHJ1Y3QgaW5zdGFuY2VzIHRoZW4gYXJlIGJlaW5nIGFsaWduZWQg
dG8gZXZlbiAzMi1ieXRlIGJvdW5kYXJpZXMgKHdoaWNoIG1lYW5zDQo+IF9fc3RhcnRfdnBjaV9h
cnJheSB3b3VsZCB0aGVuIGFsc28gbmVlZCBhbGlnbmluZyBhcyBtdWNoKS4gV2hlbiB0aGF0IG90
aGVyDQo+IHBhdGNoIGlzIGluIHVzZSwgdGhlIF9fYWxpZ25lZCgpIGJlY29tZXMgdW5uZWNlc3Nh
cnkuIFRoZXJlZm9yZSBJJ20gbm8gbG9uZ2VyDQo+IGNvbnZpbmNlZCB1c2luZyBfX2FsaWduZWQo
KSBpcyB0aGUgYmVzdCBzb2x1dGlvbiBoZXJlLg0KRW0sIGNoYW5naW5nIF9fc3RhcnRfdnBjaV9h
cnJheSB0byBiZSBzdHJ1Y3QgdnBjaV9jYXBhYmlsaXR5IGFycmF5IGNhdXNlIHRob3NlIGNvbmNl
cm5zLCBtYXliZSBrZWVwaW5nIHVzaW5nIHN0cnVjdCBwb2ludGVyIGlzIGEgY29tcHJvbWlzZSBt
ZXRob2QuDQoNCj4gSW5zdGVhZCBJIHRoaW5rIHlvdSB3YW50IHRvIGJhc2UgeW91ciBwYXRjaCBv
biB0b3Agb2YgbWluZS4gV2hpY2ggaW4gdHVybiB3b3VsZCBlbGltaW5hdGUgdGhlIG5lZWQgZm9y
DQo+IGFueSBjb21tZW50YXJ5IGhlcmUuDQpJIGFtIGZpbmUgdG8gd2FpdCB1bnRpbCB5b3VyIHBh
dGNoIGlzIG1lcmdlZC4NCg0KPiANCj4gSmFuDQoNCi0tIA0KQmVzdCByZWdhcmRzLA0KSmlxaWFu
IENoZW4uDQo=


From xen-devel-bounces@lists.xenproject.org Fri Jun 27 05:33:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 05:33:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027228.1401952 (Exim 4.92)
	(envelope-from )
	id 1uV1iL-0007AB-6n; Fri, 27 Jun 2025 05:33:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027228.1401952; Fri, 27 Jun 2025 05: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 1uV1iL-0007A4-3a; Fri, 27 Jun 2025 05:33:29 +0000
Received: by outflank-mailman (input) for mailman id 1027228;
 Fri, 27 Jun 2025 05: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 1uV1iK-00079y-3T
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 05:33:28 +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 3e0942e3-5318-11f0-b894-0df219b8e170;
 Fri, 27 Jun 2025 07:33:25 +0200 (CEST)
Received: by mail-lf1-x12d.google.com with SMTP id
 2adb3069b0e04-553b544e7b4so1835361e87.3
 for ; Thu, 26 Jun 2025 22:33:23 -0700 (PDT)
Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5550b2d0a49sm296845e87.192.2025.06.26.22.33.20
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 26 Jun 2025 22:33:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3e0942e3-5318-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1751002403; x=1751607203; 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=Ck4QcCZhtWT+wZCyZsWQpDgsHHh2Ls7o7eMTmnBThXw=;
        b=ZOyUqvRhGmisWTNnX9x3U+FENRcMKyuAuTE07j18k9RD+2eCLYexQ+ijHVOSFJV5xJ
         JFi0s4OqBg/X68UNAR56Ya0jvMnx1A7vdm3pAaciFK1GLtJ046579jkvbHB06SeQawWn
         wOM0DvyYxFc7OIT8chAkLzyr4OyBDzkTK7Guq6gUSxDEgWK3M1kfibulA7zduC4tjfsZ
         hjKoE/6HzkVZ2POSv9hLfMUA+0V/puAHseh6hP7n5H23SNf3VpAXY0veVb4klDF/rkiE
         /tT0BRhRFXwEgzgGTnf2RW711uX6YKiiLe44/bsSV2P/pjUT9yT2cAoAM4nI/E+rzFla
         QM5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751002403; x=1751607203;
        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=Ck4QcCZhtWT+wZCyZsWQpDgsHHh2Ls7o7eMTmnBThXw=;
        b=Pb2pF6DZaCCSMr3BMlHuFpdsJOB1RNhS0g0u+xne4Kfaf3bD8/eieAdGGdeqV2FfwB
         Apoewsm/d8APueUe+p9Us4RZcRPsFIa7d3A2+N/B+Fvd0/9p7tEH0rx9a0C5VCeoXx//
         Vz1FikIB8Os3FhjIO6Rixj75PneqQtj4LfNkixIugYZo61Vz/ayPCzN2nqwxSiP1TNxW
         NV6Jds2xDNAohl3mL7Q8k0DL2caDXUV8npg1KgNV5nZy7bMkhHyhCy/HrWe+J1D5Oqtb
         rZD5WsTcMClEhDaaFDT+DkLtwV8ZTApY/OOOI95DXBaVKykwIoUH2fv3xn/Nm1/Ecbp1
         ofbA==
X-Gm-Message-State: AOJu0YxpqP5C7jYt8lDlKjYyA5fhJC5VuLifFrELdczvZukRWHk3bE1i
	oFa8H/2VGwMRabEwEIXOpaeX9KUgf5Q8OM4UtHxgkHuDc8SnF/z+2FdLXOKwlyeY
X-Gm-Gg: ASbGncu6/QmQvDSg22CYDe4vcXdwsQL/hahcD0GwNgVEbp2f/t5suuyHSVmtZa5RRNz
	//B65psXqgnhQW9QCVT0A8g/yNvLRibcSWtyjONkUfvt3s+UAmBYNB8tZ9i+di1okDX0O6xb/hG
	ZmPAD8rMiiT1lAI5hcLfC5KDjWFRYjxfqH/UHmpGTrX+AY/nu8WHYb9hEMvCMTT3KIdGO8didX1
	JnGErggz6Q4/gseDsQveLBl8vMibvnWOAMB9+hWXZxyl8eQ2dcd+oeX7yEZI3rzL6Z9Dpa3BY1i
	A73iAdNSZ3/FUMIaGw26OPlRenRTp/owr3zu9T8ilF/vZZb/4sg2WVw+wIEZAnIZz0/rwVfp9fQ
	T78Y2wOVwxXPobjiFpnCXdWobBA==
X-Google-Smtp-Source: AGHT+IHbVv+cbcuPFo2L+WuDLVrA6u7XPEqiKPWaE1bwPDedy6NESR19iTkUMO7AdP2sHGwj+VEqlg==
X-Received: by 2002:a05:6512:2346:b0:553:3492:b712 with SMTP id 2adb3069b0e04-5550ba167f5mr662570e87.54.1751002402326;
        Thu, 26 Jun 2025 22:33:22 -0700 (PDT)
From: Mykola Kvach 
To: xen-devel@lists.xenproject.org
Cc: Mykola Kvach ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH] SUPPORT.md: Document guest PSCI support
Date: Fri, 27 Jun 2025 08:33:13 +0300
Message-ID: <20250627053313.2233826-1-xakep.amatop@gmail.com>
X-Mailer: git-send-email 2.48.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Mykola Kvach 

Add a new entry under "Virtual Hardware, Hypervisor" for guest PSCI
support on ARM. Describes support for mandatory functions from
PSCI versions 0.2 and 1.0, as well as the optional MIGRATE_INFO_TYPE
function.

Signed-off-by: Mykola Kvach 
---
 SUPPORT.md | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/SUPPORT.md b/SUPPORT.md
index f0b5718e84..01a3ee9499 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -956,6 +956,14 @@ by hwdom. Some platforms use SCMI for access to system-level resources.
 
     Status: Supported
 
+### ARM: Guest PSCI support
+
+Emulated PSCI interface exposed to guests. Supports all mandatory functions
+from PSCI versions 0.2 and 1.0, as well as the optional MIGRATE_INFO_TYPE
+function.
+
+    Status: Supported
+
 ## Virtual Hardware, QEMU
 
 This section describes supported devices available in HVM mode using a
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Fri Jun 27 05:58:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 05:58:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027260.1401962 (Exim 4.92)
	(envelope-from )
	id 1uV26m-0001Zf-5j; Fri, 27 Jun 2025 05:58:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027260.1401962; Fri, 27 Jun 2025 05:58: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 1uV26m-0001ZY-2Q; Fri, 27 Jun 2025 05:58:44 +0000
Received: by outflank-mailman (input) for mailman id 1027260;
 Fri, 27 Jun 2025 05:58: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 1uV26j-0001ZS-Te
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 05:58:42 +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 c65d575b-531b-11f0-a30f-13f23c93f187;
 Fri, 27 Jun 2025 07:58:40 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a507e88b0aso1333852f8f.1
 for ; Thu, 26 Jun 2025 22:58:40 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-318c14e224csm1405952a91.32.2025.06.26.22.58.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 26 Jun 2025 22:58:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c65d575b-531b-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1751003920; x=1751608720; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=dSYAZdOVW1BBaNzT6nIbWfeeFJmvvWuz+ZuN8s51rwU=;
        b=P9pDltNoPnaPvtVsDae9lr8YW90wmS55gDYDD5/xYaVCnwB0IndSjh6P6K8x3dLkHC
         ufTOUDZ4SHyJfpu1qkL0mGr+Ijifq+THlFH5VX/8/dWRtgAPL713tjh7oS+KSuqwH6IY
         k/kVMV/p2KnGmdZENuzQE8xfh0LLFoET9f7C5NhbfwuZWf1UIG2AkzY9+NXTd/Q4VMir
         EMTFqFhbi+fh9U1hzgyWpUsZf5+bSDbOtIHsqsNtM0GPBJh+WvuPoBnMoJm7L6lty1Xz
         JDxz0qsva2jx+bIaxs1YHJNLXSPCRt4bMBf1rE4SNR8Ppvo4eGYsjYb+GZCQmEPjll0R
         QQJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751003920; x=1751608720;
        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=dSYAZdOVW1BBaNzT6nIbWfeeFJmvvWuz+ZuN8s51rwU=;
        b=TH6ILuQB0EGBjI+Xp9K68jqDo7hImnC3+bNvFHw+4MsBGXd0jn0E5Zq0VIVhdi3tqn
         YJDjB7y4t6T9IxX3uZE0pwmAaLjvVOJIZOY70+4gYPkr7Yuf5EJ3PEvEene3H5FXEg9i
         7xQEyboNWt3HuHPYO1Fp5GZkcFQeUWgg8K1G/mBdVFjEH7wGbC0iR5G7EyoNSUeGRxmS
         9CC4m3kq5pxENzsYLD2dAliUGGrffihpPyHNOfAJXb9SayAVPeBvywcPr5eZcrx0P+m8
         PYBEmR09hmMc2IE4V70c8ehM5DxPNQk9tIpk5mBHjOpDZkqyddpfr9zeSLKeZClk1x4Q
         BbTg==
X-Forwarded-Encrypted: i=1; AJvYcCUlFse1NG+/+iKFAdKv532FL+07h+Jpzdnz60m5+Qc1NfUIwwDSpSVdISggZOyzd69D2Ln1JnCPzbI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzXDoMAy1QiNrKVKZpfPB85QhHeye/mRAUDtb3ZfN5GHyT5VKGD
	HDU5GT3UNeRzHcXh941dfOSWrP3eW069WEqPgr1Xy2F80M8hB2sZWQETED6EVlJHTA==
X-Gm-Gg: ASbGncuthRUu05Wg+ifSrtbrI0lusGMwuLrCO0rmA3j4r067N/a7yMZ720EnFuuUY6f
	pfX0q89kzd5rKocyWIS8p420zxanrhlfBIdEKHrYGuj+U1ZoXcrGbE2AFz8nGSkP9QgoxBrlXEE
	P687i15EwUNWr73g68cBOrm++0rB2o862Dl1ZcYE89kK4wKbOQV3weIEfJ+t1U/SecDq+J+NwiL
	Owr0ICdxiMe5aHCcJJIWX3zEbJ57I2lXeptwzz/jJUNfi2QJC6/wyXuA5sOwKB04RIPlgFc+aJ2
	jvZZZgnfLL9UoekkaNmr56TSLJr5ac8zzqUhqid5qIoRe2bxAcNBCVAw5ryL9C9wIozokdAatcB
	dQ8l39i1dxd6rNb0DwWtwnoaXTtdPkCRSm9Ssstn88qR5fVc=
X-Google-Smtp-Source: AGHT+IGNHGBtCU9405shdxz716hxGs/iugmok9cODuxcnRHBb3ZDWfXXcljQME0Ig9YLncdQZoRXAg==
X-Received: by 2002:adf:ea49:0:b0:3a5:1c3c:8d8d with SMTP id ffacd0b85a97d-3a9000ac6b6mr1393572f8f.55.1751003920070;
        Thu, 26 Jun 2025 22:58:40 -0700 (PDT)
Message-ID: <0be4bc45-5634-422c-8820-bf4e9a903868@suse.com>
Date: Fri, 27 Jun 2025 07:58:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: hardware domain and control domain separation
To: Jason Andryuk 
Cc: Julien Grall , Bertrand Marquis
 , Michal Orzel ,
 Andrew Cooper ,
 Anthony PERARD ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , ayankuma@amd.com,
 xen-devel@lists.xenproject.org, demiobenour@gmail.com,
 Stefano Stabellini 
References: 
 <942a6178-0fe7-468e-8e45-ea255fd20680@suse.com>
 
 
 <381dba84-3108-42c8-a4e5-7bc74d5e1075@suse.com>
 <2e27e128-398a-4714-b019-eab04520cc97@amd.com>
 <48def2b5-44ad-45fa-b052-67520c0961f0@suse.com>
 <96104098-0369-4607-b378-60b80bb0f560@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: <96104098-0369-4607-b378-60b80bb0f560@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 26.06.2025 23:18, Jason Andryuk wrote:
> On 2025-06-25 01:32, Jan Beulich wrote:
>> On 24.06.2025 22:14, Jason Andryuk wrote:
>>> On 2025-06-24 01:25, Jan Beulich wrote:
>>>> On 24.06.2025 00:51, Stefano Stabellini wrote:
>>>>> On Mon, 23 Jun 2025, Demi Marie Obenour wrote:
>>>>>> On 6/23/25 11:44, Jan Beulich wrote:
>>>>>>> On 21.06.2025 02:41, Stefano Stabellini wrote:
>>>>>>> Also a more fundamental question I was wondering about: If Control had
>>>>>>> full privilege, nothing else in the system ought to be able to interfere
>>>>>>> with it. Yet then how does that domain communicate with the outside
>>>>>>> world? It can't have PV or Virtio drivers after all. And even if its
>>>>>>> sole communication channel was a UART, Hardware would likely be able to
>>>>>>> interfere.
>>>>>
>>>>> There are well-established methods for implementing domain-to-domain
>>>>> communication that are free from interference, such as using carefully
>>>>> defined rings on static shared memory. I believe one of these techniques
>>>>> involves placing the indexes on separate pages and mapping them
>>>>> read-only from one of the two domains.
>>>>
>>>> How's that going to help with the backend refusing service, which I view
>>>> as one "method" of interference? Or else, what exactly does "interference"
>>>> mean in this context? (More generally, I think it is necessary to very
>>>> clearly define terminology used. Without such, words can easily mean
>>>> different things to different people.)
>>>
>>> Yes, there are different kids of interference.  We are concerned about a domain blocking another domain.  The main example is an ioreq blocking a vCPU.  The blocked domain is unable to recover on its own.
>>
>> On which insns an ioreq server may kick in can be well known. A kernel
>> can therefore, in principle, come with recovery code, just like it can ...
> 
> The case I am thinking of is QEMU providing a virtio device to a domain. 
>   The domain has to write to a MMIO area in a BAR to notify QEMU.  From 
> my understanding, that vCPU is blocked in Xen until QEMU responds to the 
> ioreq.  I don't see how any recovery code is possible, but I may be 
> missing something.

Hmm, yes, no idea now what I was thinking when I wrote the earlier reply.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jun 27 06:05:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 06:05:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027266.1401972 (Exim 4.92)
	(envelope-from )
	id 1uV2D3-0003FZ-Pg; Fri, 27 Jun 2025 06:05:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027266.1401972; Fri, 27 Jun 2025 06:05:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uV2D3-0003FS-Mt; Fri, 27 Jun 2025 06:05:13 +0000
Received: by outflank-mailman (input) for mailman id 1027266;
 Fri, 27 Jun 2025 06:05: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 1uV2D3-0003FM-5W
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 06:05: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 afab9360-531c-11f0-a30f-13f23c93f187;
 Fri, 27 Jun 2025 08:05:12 +0200 (CEST)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3a6e2d85705so1017292f8f.0
 for ; Thu, 26 Jun 2025 23:05:12 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-318c1392096sm1433319a91.8.2025.06.26.23.05.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 26 Jun 2025 23:05:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: afab9360-531c-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1751004311; x=1751609111; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=71BtaHv2rHGfs3Kxlsalek4YVZ/ViyaMH5Z00NaP3H8=;
        b=Am77YHdd56HzgjatoQtXc9U+yoxF1eERBKea5AzeSBkc5L85wY2nOLyjOjympk+NC3
         yp5/3QD57uHBZwql0SSHempYgV2k+xVOf5nMMHCwGDY0aE5Gg45CnUxLsmzhXZZihpbL
         PI5X99Xn7qHwT7vbMQDCB7po52c6CAGInjOyViZFl64RRYddEUGebd0La6dPKZ9hqTZM
         twzZ5o/jGJ5oC+Yu6GbqHA4gjlAwgwzviBRq/rlIs5AJ7kWAGm7yQLvWlbxPYD5EDKY3
         jnDB/Wi4cLhnLKgDUZbsT9Sc0zLJBNTIXGcXmE1G0aLY1VU2ctDlVidPfYhKUaPsgVKz
         WI5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751004311; x=1751609111;
        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=71BtaHv2rHGfs3Kxlsalek4YVZ/ViyaMH5Z00NaP3H8=;
        b=SLhjB0I9znGhH3OxJSjPETL9FTmcxfi5dUXTjV0nk9OFn180vY/qsKyayOMRvJEY5j
         BQ4gI3MKnqIuudpy6JqOdrxHQXIyBVwK6/HQf8cYKX5ou+1iATcx3cdh3JfX+G6krKrL
         8gGGlnJux9FIYw4LvuaWNFxg3wp0OS4y9nuVA/OS2X0LJTlIzoUcWuoFTwqWMX3GYuRK
         RbHQ2esKMTN2NOt7aCQfiMRe7L8iXgXPBr6+qTyi7sNYcPgR1xxw87K90KM5ccQfHSWD
         TaQ0SX5Z+v5x6wTgNlcrC6VR1+rTw7XIfzAKlgnkW+8Qt5SmiJ+8k2mt14bmsDrLzlvM
         2Krw==
X-Forwarded-Encrypted: i=1; AJvYcCWwXqDpyolSyTdHpu2mmavr4ZI6Cq5Z1XlACbvsx8F2O9YObBg2DHauR4D/RDH1cLh/4BuaAKzdJeA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzujO1KBHs/WRCGTtCaNC6+ftHPKx/UcI+bLSn6Z9f8yOFLhSNW
	9uM3FVlfjrW2cpupxrZGJx4xIdmF4Ximh49P/l45WJf26T8VunVWkomFGMBYjp5U2w==
X-Gm-Gg: ASbGnctE/1mb0t/+QakF5P6O470DzkT4osv7c4Odf462/H7egdrwDr7R0miYNhT7sCu
	/0/kCfpD0pnieVB58xGd1qI7yBNmao5JzurlNw4OCFrfsZqo1UzaZothfATZbNgXk1l3gq2FeTZ
	joca7sSzylnKXpUpbjP6J6km3RRi1BMyYjoNnzHBCdUQmfsFj2meJUFmRt189vz9IWlZpUbAXVR
	oEYZ8jaLOJZdE9h9uso2RPsaCgDNEXDRLu56InzpbNUJW5fmCp7oT8zWrC1X8STf/bQpS4fPjnT
	0sF1TRRZJAXEizhVGARiYYwAa0L14OWlOj+pHCXrZmGXaGBR0yMv4jdL3m59W0mNYFerhsViSkV
	bBAo0x2L9UBFBuIynAAdjTHSM08gMQDm+EQ9+KIhtYDZx5K4=
X-Google-Smtp-Source: AGHT+IFDUn5auWwwt+IPXCCCt0j5Q6fk1UAaGWG/FRTATzzkgFo/k8KwVLusnndCySxjZPzEZa/YZg==
X-Received: by 2002:a5d:5f55:0:b0:3a4:edf5:b942 with SMTP id ffacd0b85a97d-3a90b8c9779mr1974743f8f.57.1751004311441;
        Thu, 26 Jun 2025 23:05:11 -0700 (PDT)
Message-ID: 
Date: Fri, 27 Jun 2025 08:05:01 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
To: "Chen, Jiqian" 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Andrew Cooper ,
 Anthony PERARD ,
 "Orzel, Michal" , Julien Grall ,
 Stefano Stabellini ,
 "xen-devel@lists.xenproject.org" ,
 "Huang, Ray" 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <227df6d3-a2c3-4576-bde9-d8057c378e7a@suse.com>
 
 <5c4b186e-686e-4fc8-bcf1-854bc1f5ec8b@suse.com>
 
 <9d5d0e44-66c3-4e3f-8704-2c862c5f5aff@suse.com>
 
 <3638e73c-2a83-4164-9a84-839245245727@suse.com>
 
 <771cd5b7-2b89-49b1-9aba-8cd79319d3ce@suse.com>
 
 <7753470a-efef-478a-bbe5-ae48d008cfdb@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 27.06.2025 04:59, Chen, Jiqian wrote:
> On 2025/6/26 20:06, Jan Beulich wrote:
>> On 26.06.2025 10:03, Chen, Jiqian wrote:
>>> On 2025/6/25 22:07, Jan Beulich wrote:
>>>> On 25.06.2025 12:16, Chen, Jiqian wrote:
>>>>> On 2025/6/25 18:03, Jan Beulich wrote:
>>>>>> Also, as said - you will need to check whether other architectures are
>>>>>> different from x86-64 in this regard. We better wouldn't leave a trap here,
>>>>>> for them to fall into when they enable vPCI support. I.e. my recommendation
>>>>>> would be that if in doubt, we put the __aligned() there unconditionally.
>>
>> Note how I used __aligned() here. Why would you ...
>>
>>>>> That's difficult for me to check on all different platforms since I don't have them all.
>>>>
>>>> You don't need to have them. You'd need to carefully go through the respective
>>>> section(s) of their psABI-s.
>>>>
>>>>> So you mean I should remove "#ifdef CONFIG_X86"? Just let __aligned(16) for all platforms?
>>>>
>>>> Yes. And, as also said, with a suitable comment please.
>>> Ah, my comment definitely needs your change suggestion.
>>> I wrote a draft as below:
>>>
>>> /*
>>>  * Size of vpci_capability is lager than 8 bytes. When it is used as the entry
>>>  * of __start_vpci_array in section, it is 16-byte aligned by assembler, that
>>>  * causes the array length (__end_vpci_array - __start_vpci_array) wrong, so
>>>  * force its definition to use 16-byte aligned here.
>>>  */
>>> struct vpci_capability {
>>>     unsigned int id;
>>>     bool is_ext;
>>>     int (* init)(const struct pci_dev *pdev);
>>>     int (* cleanup)(const struct pci_dev *pdev);
>>> } __attribute__((aligned(16)));
>>
>> ... open-code that here?
> That because when using __aligned() without CONFIG_X86, I got compile error
> vpci.h:18:13: error: expected declaration specifiers or ‘...’ before numeric constant
>    18 | } __aligned(16);
>       |             ^~
> I tried some methods, only open-code can fix it.

Well, that's odd. In e.g. xen/sched.h we have

struct domain
{
    ...
} __aligned(PAGE_SIZE);

which clearly must be working fine. The error message from the compiler
doesn't say very much alone. For informational diagnostics the compiler
normally also emits may help, or else it would take looking at the
pre-processed output to understand what's going on here.

>> As to the comment: First, it wants to be as close to what is being commented as
>> possible. Hence
>>
>> struct __aligned(16) vpci_capability {
> This also got the compile error.
>>
>> is likely the better placement. Second, there's nothing here the assembler does
>> on its own. It's the compiler which does something (insert alignment directives),
>> and only to follow certain rules. (See "x86: don't have gcc over-align data"
>> that I Cc-ed you on for some of the relevant aspects.) That is, you don't want
>> to "blame" any part of the tool chain, at least not where it's the underlying
>> ABI that mandates certain behavior. There's also no strong need to talk about
>> the specific effects that it would have if we didn't arrange things properly.
>> That is, talking about the effect on arrays in general is fine and helpful.
>> Talking about __{start,end}_vpci_array imo is not.
>>
>> While further playing with the compiler, I noticed that adding __aligned(16)
>> actually has a negative effect as long as that other patch isn't in use: The
>> struct instances then are being aligned to even 32-byte boundaries (which means
>> __start_vpci_array would then also need aligning as much). When that other
>> patch is in use, the __aligned() becomes unnecessary. Therefore I'm no longer
>> convinced using __aligned() is the best solution here.
> Em, changing __start_vpci_array to be struct vpci_capability array cause those concerns, maybe keeping using struct pointer is a compromise method.

It would be a last resort, yes, but imo (a) we ought to strive to avoid
unnecessary indirection and (b) the same underlying issue could become a
problem elsewhere as well.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jun 27 06:09:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 06:09:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027281.1401982 (Exim 4.92)
	(envelope-from )
	id 1uV2HR-0003pW-9w; Fri, 27 Jun 2025 06:09:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027281.1401982; Fri, 27 Jun 2025 06: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 1uV2HR-0003pP-6z; Fri, 27 Jun 2025 06:09:45 +0000
Received: by outflank-mailman (input) for mailman id 1027281;
 Fri, 27 Jun 2025 06: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 1uV2HQ-0003pJ-FW
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 06:09:44 +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 50d0f598-531d-11f0-b894-0df219b8e170;
 Fri, 27 Jun 2025 08:09:42 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-453647147c6so19390555e9.2
 for ; Thu, 26 Jun 2025 23:09:42 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-74af55c6a45sm1381758b3a.114.2025.06.26.23.09.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 26 Jun 2025 23:09:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 50d0f598-531d-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1751004582; x=1751609382; 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=o4v0TGDYWLzd0Emz6k3M4SJ7ptTgDVOJ7qukt+movY8=;
        b=M6dkQpoK/iN6Zygych/lo794tKvrY0x+BbZuhE/4iITeb6aZTki1UTDBUrYdVkHKKs
         zdYGuIcWXCWtyBAxNCrCh/v6omvNhtjlgdjUwt8OI1ykryrOL8Ysq0agoVT0hfrvI4si
         xQMPNd+yUpwPSTW9IQWXpkGOLWb9dCuh8huneSMdy4lM1rEXvmDu4uhiBYiECxGRvWW4
         6foyySRkmcMVSZZB4PO7CoxWWb+gMvwZ3tKZeN5nSlWSeccbePh/tvjtmSskf3MT3lOQ
         iJuYbXKK3inZXU9AZNVYTPth5QCTimuYnseVc2Npk6+VZDplDmjp7lOTC7qZq38pfBKL
         /JwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751004582; x=1751609382;
        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=o4v0TGDYWLzd0Emz6k3M4SJ7ptTgDVOJ7qukt+movY8=;
        b=ZyKe7+RmhSw3uI4DfR6Stt0zuV9oCFHAErZuYP+vqJz0DOP3IEn6AiprtyA+++fDSx
         xZdf3QTlKO3vse6USYwYVtyAio//e72CICdA0MtFuqAXVWP3lib3U0M9VOwUsf6CznBu
         qvi4f0rYi5ZA79iWObtRgu0YDlurhNi50ZkbReBukLk1cjIsAEmR3C2ARLPMjtCusixa
         ISPbmgH27v9Y6WSCigGrnBncQ9xnlScER46JymNf0zWv/kmaUwXgiNHDyIXWoZ46L2RT
         WLKv3ITsN1Yj3YQJr1xr9LDHcQmuyBGMvOgyxqFscs6Nh1z+ubSc0GILKdP8GqC5Tob7
         jAIA==
X-Gm-Message-State: AOJu0Yzc/JLaYARTTqNNwk6HF6PfoSRiKPgOReAafjoPX+IGEjyQcxGm
	mD2YGk32T1BP+4zMLfmDKUOCIWgORpDR3O6tvIJbm20vFBHDnO1dDlcvnl2HqMqISxWOkBd/33j
	Win0=
X-Gm-Gg: ASbGncsagcydSbxncJudGySb1LuVg6qhf5ByGIPFPJWVwL4ShsOOKPstE8gA2oCWyDb
	I+rNDVvbu3Vq1F+igr832/nFRREfdMS/O0L958MSkE/r+al9dA8lJwD4RIiwhubvpj8djGEoTM7
	QjuoIIlttdE+1vbgrulX3z6z7R9ZNv6sKR/cS7YlLfM4AwGaSeHxWslqW/ANarTtezs+7/BFWct
	XzB52vFjSPs6npkVaQNdilQCAhajd1F6EanXU6TA9Nhfpj2iloTx6o++mtKJz2yAJGgnIsBJPJY
	6m1vQ3OkwiYIJyRl3QQy7duXyQurB2QxuNPv/bwzAATF6r8lQeZZjIDw+FFGSrq1mY0FM4QUlPc
	8O+d7IEANY7QyZCdz8CaxHtNPotocwme3uaUUeBCO3Ue8bP0=
X-Google-Smtp-Source: AGHT+IG9Fo7MqDdZK0o6aBOCdzRJB8cjbK/6hkrLRBHKFn1Pq1X1jtm82JyQeAP9v42shQI3Fl5Tbw==
X-Received: by 2002:a05:6000:41d3:b0:3a5:52d4:5b39 with SMTP id ffacd0b85a97d-3a90d0d6a0fmr1525302f8f.8.1751004581802;
        Thu, 26 Jun 2025 23:09:41 -0700 (PDT)
Message-ID: <24664c4f-c703-47bf-9a5f-f2852e5983fd@suse.com>
Date: Fri, 27 Jun 2025 08:09:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86: don't have gcc over-align data
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Chen Jiqian 
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 25.06.2025 11:04, Jan Beulich wrote:
> For (aiui) backwards compatibility reasons, gcc defaults to a mode that
> was the exclusive one up to gcc4.8, establishing 32-byte alignment for

Correction - it's 16- or 32-byte alignment, depending on size.

> aggregates larger than a certain size. We don't rely on such, and hence
> we can do with the psABI-compliant 16-byte alignment.
> 
> Savings in the build I'm looking at:
> - .data.ro_after_init		 344 bytes
> - .rodata + .data.rel.ro	1904 bytes
> - .init.*data.cf_clobber	 232 bytes
> - .init (overall)		 688 bytes
> - .data.read_mostly		 864 bytes
> - .data				 600 bytes
> - .bss				1472 bytes
> 
> Overall xen-syms' _end happens to move down there by 2 pages.
> 
> Clang doesn't support the option, presumably because they never over-
> aligned data.
> 
> Signed-off-by: Jan Beulich 

Looks like this is becoming a necessary pre-req to "vpci: Refactor
REGISTER_VPCI_INIT" [1], unless we want to use undesirable workarounds
or hackery there [2]. Hence may I ask for feedback here?

Thanks, Jan

[1] https://lists.xen.org/archives/html/xen-devel/2025-06/msg00840.html
[2] https://lists.xen.org/archives/html/xen-devel/2025-06/msg01760.html


From xen-devel-bounces@lists.xenproject.org Fri Jun 27 06:38:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 06:38:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027296.1401992 (Exim 4.92)
	(envelope-from )
	id 1uV2ip-0007mO-BR; Fri, 27 Jun 2025 06:38:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027296.1401992; Fri, 27 Jun 2025 06:38: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 1uV2ip-0007mH-7X; Fri, 27 Jun 2025 06:38:03 +0000
Received: by outflank-mailman (input) for mailman id 1027296;
 Fri, 27 Jun 2025 06:38: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 1uV2in-0007mB-Et
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 06:38:01 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on2060d.outbound.protection.outlook.com
 [2a01:111:f403:200a::60d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 40190b44-5321-11f0-b894-0df219b8e170;
 Fri, 27 Jun 2025 08:37:53 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by SN7PR12MB6929.namprd12.prod.outlook.com (2603:10b6:806:263::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.25; Fri, 27 Jun
 2025 06:37: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%4]) with mapi id 15.20.8835.027; Fri, 27 Jun 2025
 06:37: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: 40190b44-5321-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=pORaVjFfO+DKZ80JcbX8GWwwYABptLCR3gVnkMeoMEhPwLNNiILVaANzjwVQARLemzRCSq7Fb0EgBld1fvxtoH+oI16bYqliRDCskup47+7vI4PngRiPVnoA0oQjSzGVVUdRVfLXGqELWOhZY9rfZ5roKyHGgCYjUdlr6NKn5UlhddEiRudlDnehv5nVpvNtZG/RxmmvEiUvgG80Xa0lqLbh8OnR70zVJE5LFmBfjC7Z19vGLX0p1u9LEffezjWKLR3WzSiz9+g64FP+xOKale4QnRWQR8puKFIPHByw+mtsa2sh4EfyE/qQK/ri3k3NYnuCmp/n74A9V6fQyptlmQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=jR0zseXZk2bUXzqXRG9P5SSPPrGx3g90Zcg/c0ZFAg8=;
 b=AoesZZwmWQ7TQ6idgp8Q+glhmQZPwuL8Ax+MR3w6A5hKQvaH8C2c4/aOLS13zQqKTZG0TFeV+uaZNjRAfBUUJg4/rDyI18z+I3AmCSdtMj41Rrz6bn+vImvHWRYeWWdlf4i2hA3ea0j5g3Xb5cRs/KAS+nr78LwYlweShKx4hD0G20ih+BnFqDyHClhHsP+K1StVTtZvbGcYa/LWcMjNXDnd6Y7iHhREYzEpkIwrgCIiPU/eTu5cSmR8KoV0uvVXi/4Nn5i3uhSVLoydzJR9TxkYyf5OpUeV4bnTV170lPCVWrXzjq0K72O81qtHFWbIdeBNTW6XkpmgNUzGS8PW+Q==
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=jR0zseXZk2bUXzqXRG9P5SSPPrGx3g90Zcg/c0ZFAg8=;
 b=ymSfVkqA1v06PG0x73fCRSbua5KU6Rz1KEf9tgYxvBnbONjUDRQOV9zf4lBj3QD5EK1FSxDrCMa4Bb6s/TncARj6W2xmjH7SXT0yR8vvo966LHkjRNGeuxFyXq8c5qZQowMCIpAD0oOONURYYFhXP2w9GWjl0ZvFqUl5i7e/Z/E=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= 
CC: Jan Beulich , "xen-devel@lists.xenproject.org"
	, "Huang, Ray" , "Chen,
 Jiqian" 
Subject: Re: [PATCH v6 1/8] vpci/header: Emulate extended capability list for
 dom0
Thread-Topic: [PATCH v6 1/8] vpci/header: Emulate extended capability list for
 dom0
Thread-Index:
 AQHb23yZHYwoBN0glE68BnOedByoqrQI+ZKAgAFXGYCAAVGyAIAG16sA//+EZICABSptAA==
Date: Fri, 27 Jun 2025 06:37:48 +0000
Message-ID:
 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <20250612092942.1450344-2-Jiqian.Chen@amd.com>
 <669877f5-ef34-4552-9cfc-e097d40d444a@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.8835.025)
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_|SN7PR12MB6929:EE_
x-ms-office365-filtering-correlation-id: f0bc20a6-719d-4216-3472-08ddb5452245
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?N0xQQ3I2OHFHazFBRG5UdUZXQ0JsZ0tyY0JuL3Rkc1JwRTNTWUl6Yk5hSUph?=
 =?utf-8?B?amNsbmYwc3NwZFBvVXJ5UmR4T00xSnBOMTF5TERjN21uMFZyby84UlZHMVps?=
 =?utf-8?B?dkMzMGhadUFKYlFseDNZNWxXUmkyUEpvMk5oN3duRjBxVFdtZzNtYjZTZkJR?=
 =?utf-8?B?aEZ3TkhiblBEZDJSWlNPeW9oeWhuWFpIRkczUlBBay8rL3dnZ3RIaExNUzB4?=
 =?utf-8?B?RWptM242TlhWRjQzMU54N1AremVieTFZSlNQT2ptVjZhb0hhdndjMzZxV2dL?=
 =?utf-8?B?bXgyeXZheGdyYWh5V1ROTU1SaC93STNDMENzZWpkWW41WDJQSVdEdHc2RDk2?=
 =?utf-8?B?YWVHQ1dTN1gvZ1JlQXQzTWtUVXp4U0lsNDZpWXRhNjRMalp6Q1Vnak1nRVBy?=
 =?utf-8?B?OFEyTWF3NDUwRElJTW5HanBHdmdCS1B6K0JsUm5uZXRtYXlMcXNxaHptT2h5?=
 =?utf-8?B?Q0s5TjFHOXpLanpRU25lcWdQN0hQZFkwTW5QejlteEtueUVvRit6NG5sbHBx?=
 =?utf-8?B?cjJhUDdaUW5Cc05ZNVArODlES0tBaEFES21MSy8xWStZWnk0VjFsbmMyMU1q?=
 =?utf-8?B?QTBWR2pvMlBtbFNDNEhxQlZXYXhIY2lmSjJTMzN6d0pNM2hRRG5QSGx5MFky?=
 =?utf-8?B?N3VUd2p6dnhGZDRXSFM5Yy83dmtpbHRFcWpxeElFbUxEdG82eWxoRUlKbWdt?=
 =?utf-8?B?Q0ZrMXFaUGZ2ZlBodEU4cFRlVXVmdFRLa1h2WDdNZmoxck1HbjhuZGcyMlJt?=
 =?utf-8?B?WjU1L3ltWXNKMlhTb3ZQeFVOWnVmZS9PNG5GTFV4a3pxRFVsM1E0ZE1zZUk0?=
 =?utf-8?B?a052OHFIaW1UQ08vVGRkMEFZUGhLM1JtYXpvOTAzTDBxeDhzNk9icmttUmNN?=
 =?utf-8?B?NHBHYWsrbHZQZnAwUmNtbURMcVQwZHlyU1VwMXIzV1ozZEdWb0ptQmdCaHJj?=
 =?utf-8?B?K1pwbEpWb0gzNlVYS3B2b2pVMTVsempIVjRFSW9WYmZSbGhxQVJ5T09rNC9j?=
 =?utf-8?B?bGdZR1FIVnF5SEl3cjNiUXhVQm9tMThlbUVHQWJ5Tk0zMEhQbGZHM0hlQjE0?=
 =?utf-8?B?SlI2cGl2c084VUNKYUtnMVpoTG5CaFlONGJma1llaW0rdlRJNytKd3JZTFRD?=
 =?utf-8?B?c0Y0eTh0Z3FaczN0ZjdCc0I3TTM5blM3dUJ6eTZtMlpwTVkwUnN1a0hIcUFP?=
 =?utf-8?B?ZWJhNlNKdll2eTRWYzBySnc3NjIrK05nK1VSZWdiRUo1S2hEWFdVMGZkY1hm?=
 =?utf-8?B?WWxjVzdIVFZoNVZyT1MwVE8wdWpJWjgzSGl3VUhvMEZIUXprT3E0LzZaRmtD?=
 =?utf-8?B?UkltSTRyZDRaczNvd0VySHA1UnlWZ1o0WDNkYisxOEpuNk96clFDNmtvMVNj?=
 =?utf-8?B?c2h3YnAzWjBWdm9HVHlxSjVzVHpjMXVpQis4SjI4bDg3TmNvZDlvSmRjUlhL?=
 =?utf-8?B?SnRqckRyK1BNcXM0NzEzckVJclRCWlBhblNLeHBRZkpwRmNXZnE1Q1QwOXlv?=
 =?utf-8?B?YkNGMTNQZkszZG44MWJ0Qm5IQnhBNUt5YWU3U1ptZlhZQmpXS2ZjTTgzYjht?=
 =?utf-8?B?UDZCeVBWdm1KRGFhdWMvVmhFaDZPVG4vbllTVURxaFVzRmdTNVgzcCtZT3BK?=
 =?utf-8?B?RThZTjFoT0QrbVE3U0hqdUcwbk94OUhPdjRZM25DUTcvRGdscmNBRDlsZkNX?=
 =?utf-8?B?SDdJUkZRV3J5azkzT0RKSUpPTFJMbHhiU01GOUdqUWxoc0xUaUtvWnpPNU1M?=
 =?utf-8?B?SXdKN0F1QVpMMU1Wa05NcHRGbWhYTi81dlZKeHBoL3lPSlBqRFN3eFhRcGh6?=
 =?utf-8?B?cFZ2RkNJcW9RNUtvWStXSmtnZXRaSk5kVEpPbWVWWlRBNHpFaENYUWlHNjE3?=
 =?utf-8?B?VG51N21Ea0dadGFXcllXdUJNTEZNSGZTSGlmUzNuVmgzREZzbFlSYkVjWHpi?=
 =?utf-8?B?ZmRJaUdKbXI2TkJyZzFyZ0UrUzNUQThVbVE0MmdVdm00QmIvSFlNanZ6MGdC?=
 =?utf-8?Q?l+ZvZjnsKnQtd/xC501+ZEUlGjsOjA=3D?=
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?amZ3Z2U5M2FPK2pZeEF3ZncwWURuWDV3WDQzR2hod0M5U2I4aFQzZ2xrSUpU?=
 =?utf-8?B?MXM4UkRVRGpaQmJycURmMys4V2ZUZnRQQUVJOFY0eEtDRmdSTnZaVHk2M2dM?=
 =?utf-8?B?eXA2Sy8rRlFTb09pSFZyWkpZMDBZUWo2OG93RHRBR1ZicmdXV3RibU43NU51?=
 =?utf-8?B?RXFpZzBheUdGWW1IYzBWUDFxWUZpcm1zbnA0d0I3NU1ZYnBmemhKcEFHc2sr?=
 =?utf-8?B?T0RrR3JkeHNQbmpEc1cyMWpkSVZ1T0RhZU1KMzFzS2VJblRDQnNTZHpEcE5K?=
 =?utf-8?B?VU9JWUJBMVpPa2VTTTZNWlcxRnZCdlZYcURBN1dObWpMWUFnRzJNR0lGcHpk?=
 =?utf-8?B?cnllUXh1ZWp3UytUTEJhRkx3VmZxTzBGaTZ6U2RzNVRGMlM5WUpEa1VRZ1Nn?=
 =?utf-8?B?NEtmbnkvYVpyaU9WT1pyZFlyYUN0RHNJRXlqVTRTTkEzQWJVeko0citwT2pM?=
 =?utf-8?B?QzQ5LzRqM0RObHV2YjQybHFXSXlOdUtNYzNOSkpIZ1V5WFhCZWhBOUFackp1?=
 =?utf-8?B?ank2aDNiMXAzUjJhVVVDdmVGYmxwNUw5NnNMU3c2eUlSMGRkbDRXL2ZMZGVV?=
 =?utf-8?B?NmowbmtGKzRPdDZqUmhTZ1JPTHZjQzZ4QkR2VTZPZjVmWGxyWjNJQktlTGdv?=
 =?utf-8?B?NjVqbnpHQ3ZTS2NEemh0dWRtK0FJNElvbTY5MkI2c3IvdUxWUmhSS2lGeGRh?=
 =?utf-8?B?emh1L2wvQXZ5K25lRmFjeWo2RGdGVHJ5b0pENlRiYUtYSzN2RmFIZlJEZHI4?=
 =?utf-8?B?QWpjUTk0M2txMC9kNFF0Qk5rWnFDeVVWWVNFYXVnNEcrR1N6UUduajdCVFJB?=
 =?utf-8?B?emVXa1lVekVvaWJrVHVFMVB4Mm9qaGtvNS92RDUvcmdYTWgza005OE9hZk5p?=
 =?utf-8?B?V1E4SnQxTGFEbkM0eWw2Zk1DdE9tZm16YkpNSnRZRlo5dEpKUzZybFRKS3Z4?=
 =?utf-8?B?TGFUajdYemxaQnMyV3NqZ01icnVPSzJsZ1dUR0JzTnlRSHBYN3EyTC9iZUhP?=
 =?utf-8?B?RlFkYmdZaGpqeEtMRmR3dnJHYkR5VzU3WG5ET2xJRERPUGFSc2JOZmIwbWk0?=
 =?utf-8?B?aml0MElnaEVWRWlhcXBWNTJmeEFCVHMxZGdLSWdwUHpFN043MDNrbVRkRlh3?=
 =?utf-8?B?MnJsa1kvZjNyUEN4ck5Za0tWT2ZiUjZISmMyQ2FIcWN6UzV0aTBrT1I5WFpX?=
 =?utf-8?B?SkxBM0RYZ2E5ZXlFS0xkNVltNXBFQ2cvMFE2STZkdVhBVyttL3cxU1N3YTg2?=
 =?utf-8?B?RGVNaGlkZUZEdGtMeUFha0pCNHpZa1hGdnZnQ1BTUUluRlg2aTB6cXRWNjdl?=
 =?utf-8?B?aEtjMS9BWTh1SGpOOVpKbnVLS1FPek12VHVYakxlcERKdTNIcHJCUHc0WWw0?=
 =?utf-8?B?US9UREdNdGpFaS82RnJEWkt2MDJMbG1DZUVsTUgzYlhDOUF4K254SU5ITUNt?=
 =?utf-8?B?WGt5TkM0QSt1Um5GUGZIUE1JY1VUY1AxYTRhbGJBN214S2hVb0pkMUl6K2x3?=
 =?utf-8?B?MThnQXJuL1EzZU1UTDByOXJOcVlsK2RxdDBJZUt0RENLYWE4bWczOVJWQU5i?=
 =?utf-8?B?WDdyTm94b2gwdmdiVGRybXFqN0VDNThBb1E0WVVlRFhKK1FQajZnaUhScUI3?=
 =?utf-8?B?SkR3ekpTK2NibEZFSEpNR1ZieExRTnlFbGcwWm4wRkgrRWh6T1Y0TEZoWDdQ?=
 =?utf-8?B?b2V6WXpxY3FOQjFBbk1ORnozdUZyRWtxMzlicmc1bVBOd0htb2RmUS9IcTNt?=
 =?utf-8?B?ckI2SjBYeGV1MmpuL2xJbk9nUU96dktSL2VoZ0d6UElmVFRzemFNMElDckt4?=
 =?utf-8?B?aHc2WFp6SjI2dXpJRlFZZkVSV2RxRTBGQk44akJEN05xV3V1YTBCSGpTaDBU?=
 =?utf-8?B?WnRJVHpDL2toNmdkUVdjOU16UklLVlZQSUs1VGtlSncvQVVEWi83ZnNpZlFm?=
 =?utf-8?B?dTJ2aEVqbVVpUjlWdWxhbDhVNi9nQ2dhdE91MWJZOEdrV0ZrWGFka1J0U3d0?=
 =?utf-8?B?MEsyMTJUOEFqS3VNKzluWUxrcEdQbE81R2Fzby91Y2VKUW9KVnRTS3BIWVJo?=
 =?utf-8?B?WFVmT1ZGNGFwU0tEelVmdDVQZnJvYjN1MHRSRDBZNFhNUzM2L0ErbS9BRXgx?=
 =?utf-8?Q?HgIQ=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <847A666388A22F429BF0846B6961BB5A@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: f0bc20a6-719d-4216-3472-08ddb5452245
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2025 06:37:48.8282
 (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: jHAbr/iYTRHJAKwoPSYhTpg7alUEaJlt0CwPy/34R5issKZym/xxv0iBCrvTd4wvKIWdwSVDC1kjU4bBx4qPaA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB6929

SGkgUm9nZXIsDQoNCk9uIDIwMjUvNi8yNCAxNTozNiwgSmFuIEJldWxpY2ggd3JvdGU6DQo+IE9u
IDI0LjA2LjIwMjUgMDk6MDEsIENoZW4sIEppcWlhbiB3cm90ZToNCj4+IE9uIDIwMjUvNi8yMCAx
NDoyOSwgSmFuIEJldWxpY2ggd3JvdGU6DQo+Pj4gT24gMTkuMDYuMjAyNSAwNDoyOSwgQ2hlbiwg
SmlxaWFuIHdyb3RlOg0KPj4+PiBPbiAyMDI1LzYvMTggMjE6NTIsIEphbiBCZXVsaWNoIHdyb3Rl
Og0KPj4+Pj4gT24gMTIuMDYuMjAyNSAxMToyOSwgSmlxaWFuIENoZW4gd3JvdGU6DQo+Pj4+Pj4g
LS0tIGEveGVuL2RyaXZlcnMvdnBjaS9oZWFkZXIuYw0KPj4+Pj4+ICsrKyBiL3hlbi9kcml2ZXJz
L3ZwY2kvaGVhZGVyLmMNCj4+Pj4+PiBAQCAtODM2LDYgKzgzNiw0MiBAQCBzdGF0aWMgaW50IHZw
Y2lfaW5pdF9jYXBhYmlsaXR5X2xpc3Qoc3RydWN0IHBjaV9kZXYgKnBkZXYpDQo+Pj4+Pj4gICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQQ0lfU1RBVFVTX1JTVkRaX01BU0spOw0K
Pj4+Pj4+ICB9DQo+Pj4+Pj4gIA0KPj4+Pj4+ICtzdGF0aWMgaW50IHZwY2lfaW5pdF9leHRfY2Fw
YWJpbGl0eV9saXN0KHN0cnVjdCBwY2lfZGV2ICpwZGV2KQ0KPj4+Pj4+ICt7DQo+Pj4+Pj4gKyAg
ICB1bnNpZ25lZCBpbnQgcG9zID0gUENJX0NGR19TUEFDRV9TSVpFOw0KPj4+Pj4+ICsNCj4+Pj4+
PiArICAgIGlmICggIWlzX2hhcmR3YXJlX2RvbWFpbihwZGV2LT5kb21haW4pICkNCj4+Pj4+PiAr
ICAgICAgICAvKiBFeHRlbmRlZCBjYXBhYmlsaXRpZXMgcmVhZCBhcyB6ZXJvLCB3cml0ZSBpZ25v
cmUgZm9yIGd1ZXN0ICovDQo+Pj4+Pg0KPj4+Pj4gcy9ndWVzdC9Eb21VLyA/DQo+Pj4+IFdpbGwg
ZG8uDQo+Pj4+DQo+Pj4+Pg0KPj4+Pj4+ICsgICAgICAgIHJldHVybiB2cGNpX2FkZF9yZWdpc3Rl
cihwZGV2LT52cGNpLCB2cGNpX3JlYWRfdmFsLCBOVUxMLA0KPj4+Pj4+ICsgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBwb3MsIDQsICh2b2lkICopMCk7DQo+Pj4+Pj4gKw0KPj4+Pj4+
ICsgICAgd2hpbGUgKCBwb3MgPj0gUENJX0NGR19TUEFDRV9TSVpFICkNCj4+Pj4+PiArICAgIHsN
Cj4+Pj4+PiArICAgICAgICB1aW50MzJfdCBoZWFkZXIgPSBwY2lfY29uZl9yZWFkMzIocGRldi0+
c2JkZiwgcG9zKTsNCj4+Pj4+PiArICAgICAgICBpbnQgcmM7DQo+Pj4+Pj4gKw0KPj4+Pj4+ICsg
ICAgICAgIGlmICggIWhlYWRlciApDQo+Pj4+Pj4gKyAgICAgICAgICAgIHJldHVybiAwOw0KPj4+
Pj4NCj4+Pj4+IElzIHRoaXMgYSB2YWxpZCBjaGVjayB0byBtYWtlIGZvciBhbnl0aGluZyBvdGhl
ciB0aGFuIHRoZSBmaXJzdCByZWFkPyBBbmQgZXZlbg0KPj4+Pj4gaWYgdmFsaWQgZm9yIHRoZSBm
aXJzdCBvbmUsIHNob3VsZG4ndCB0aGF0IGFsc28gZ28gdGhyb3VnaCAuLi4NCj4+Pj4+DQo+Pj4+
Pj4gKyAgICAgICAgcmMgPSB2cGNpX2FkZF9yZWdpc3RlcihwZGV2LT52cGNpLCB2cGNpX3JlYWRf
dmFsLCB2cGNpX2h3X3dyaXRlMzIsDQo+Pj4+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBwb3MsIDQsICh2b2lkICopKHVpbnRwdHJfdCloZWFkZXIpOw0KPj4+Pj4NCj4+Pj4+IC4u
LiBoZXJlPw0KPj4+PiBJZiBoZWFkZXIgb2YgZmlyc3QgaXMgemVyby4gVGhlcmUgaXMgbm8gbmVl
ZCB0byBhZGQgYSByZWdpc3RlciBJIHRoaW5rLCBzaW5jZSB0aGUgZG9tMCBjYW4gcmVhZC93cml0
ZSBkaXJlY3RseS4NCj4+Pg0KPj4+IFdlbGwsIG15IHJlbWFyayBvZiBjb3Vyc2UgZGlkIGdvIGFs
b25nIHdpdGggdGhhdCBmdXJ0aGVyIGRvd24uIFBsdXMgSSB3b25kZXINCj4+PiB3aHkgdGhlIGVu
dGlyZSBmaWVsZCBiZWluZyB6ZXJvIGlzIHNwZWNpYWwsIGJ1dCB0aGUgZmllbGQgaG9sZGluZywg
c2F5LA0KPj4+IDB4MDAwMTAwMDAgaXNuJ3QuIFllcywgdGhlIHNwZWMgY2FsbHMgb3V0IHplcm9l
cyBpbiBhbGwgZmllbGRzIHNwZWNpYWxseSwNCj4+PiB5ZXQgYXQgdGhlIHNhbWUgdGltZSBpdCBk
b2VzIHNheSBub3RoaW5nIGFib3V0IGNlcnRhaW4gb3RoZXIgc3BlY2lhbCB2YWx1ZXMuDQo+PiBJ
ZiB3YW50IHRvIGNvdmVyIHRoZXNlIHNwZWNpYWwgdmFsdWVzLg0KPj4gU2hvdWxkIEkgbmVlZCB0
byBjaGFuZ2UgdGhlIGNoZWNrIGZyb20gIiFoZWFkZXIiIHRvICIhIFBDSV9FWFRfQ0FQX0lEKGhl
YWRlcikiID8NCj4gDQo+IEFzIGluZGljYXRlZCAtIG15IHRha2UgaXMgdGhhdCB0aGUgY2hlY2sg
bWF5IGJlc3QgYmUgZHJvcHBlZC4gUm9nZXI/DQpNYXkgSSBnZXQgeW91ciBmZWVkYmFjaz8gU2lu
Y2Ugc29tZSBkaXNjdXNzaW9ucyBuZWVkIHlvdXIgaW5wdXQuDQpBbHNvIGRpc2N1c3Npb24gaW4g
cGF0Y2ggMiBhbmQgcGF0Y2ggNCBhcyBJIHJlbWVtYmVyZWQuDQoNCj4gDQo+IEphbg0KDQotLSAN
CkJlc3QgcmVnYXJkcywNCkppcWlhbiBDaGVuLg0K


From xen-devel-bounces@lists.xenproject.org Fri Jun 27 07:06:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 07:06:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027311.1402002 (Exim 4.92)
	(envelope-from )
	id 1uV3AF-0003St-FW; Fri, 27 Jun 2025 07:06:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027311.1402002; Fri, 27 Jun 2025 07:06: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 1uV3AF-0003Sm-Ca; Fri, 27 Jun 2025 07:06:23 +0000
Received: by outflank-mailman (input) for mailman id 1027311;
 Fri, 27 Jun 2025 07:06: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 1uV3AE-0003Sg-0B
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 07:06:22 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20625.outbound.protection.outlook.com
 [2a01:111:f403:2009::625])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 38e2699b-5325-11f0-b894-0df219b8e170;
 Fri, 27 Jun 2025 09:06:19 +0200 (CEST)
Received: from BYAPR03CA0031.namprd03.prod.outlook.com (2603:10b6:a02:a8::44)
 by MW4PR12MB7358.namprd12.prod.outlook.com (2603:10b6:303:22b::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8880.24; Fri, 27 Jun
 2025 07:06:14 +0000
Received: from SJ1PEPF000023CE.namprd02.prod.outlook.com
 (2603:10b6:a02:a8:cafe::b4) by BYAPR03CA0031.outlook.office365.com
 (2603:10b6:a02:a8::44) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8880.21 via Frontend Transport; Fri,
 27 Jun 2025 07:06:13 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ1PEPF000023CE.mail.protection.outlook.com (10.167.244.10) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8880.14 via Frontend Transport; Fri, 27 Jun 2025 07:06:13 +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, 27 Jun
 2025 02:06:12 -0500
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, 27 Jun 2025 02:06:11 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 38e2699b-5325-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=xq9BPlkHFyO7V9O3NBFUWJO0XsHLdRE8PENJIGGDEl0qAPyB+Caia8zH5kY/BeOHIssA2wRwqrUcWRTOUvJRuG8HXyi8dNIgL7p/whsIqNZyBMoA+FcMxASBNR0oUEPReQ1qwkn6DcdjFVXT1KsIh4c1DEy2iEetS1uArOpZsTWU05sl3c/jtOXvHCwpwabdmNAK2PhdMUQ2AOwHqb9GQCapmkQa22kgU7UBnxBk4iheiyTGKg18EE936NktaAe8Ir390G3rQY3OWJLrCM3Jk5J40lg0ExO8FErdRtb144IPOz18LQxEko99osHbLPNK4CtRbtL8RmXjtbU9L4VXew==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=uNfuWQNBrKEQi09oANPuBniM1En1eo376mdyGs8FzsU=;
 b=v5qJgpG2atsKDbq5dRfKEXIUpHfzXpnwGrl8HlMUoCsKWzU+wgzQIolwGRjlLN8bps5nFKWln/BiaK+Gc5y88ETgx57OlRI7gU7a6+c/hPJNOIw6reEsPv4WNBObiCNJqoF4WKxU0GAlGq48TJHQsdAIVTr86P7oHeMfAjIGqK+6HGjXn4b3SNtQ53/AGfpRxI9aUAqsklFHmoSrZEvoEgiaiKyDNe7X/NcVfFBUDlR5Mb3QgylYfxUq+MwdmChj5znFjYUpxn8KRAsyEc+FxBPuzgPQH1H20estnjdNEhAXoxgjmmBJBv1cX/fgD2htlJnodi/2bykcGk/2+NqAGA==
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=uNfuWQNBrKEQi09oANPuBniM1En1eo376mdyGs8FzsU=;
 b=k98GuFJGb2B6TK4lUqud8Qtp4igic7JH1gwXeKWfJFhWsRK4V219HGc74F2qtD7Isbqj3QlIBiZHba6Ih0Sl4QWQRvBmSekCHD3jm0g1FsEJKbLZRXkmMNuT8BzJZJ0+xR+3EDZ41jjFesIRImO639JCSm69iIWAx6awe5dKD78=
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 , Andrew Cooper
	, Anthony PERARD , "Jan
 Beulich" , Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Stefano
 Stabellini" 
Subject: [PATCH] docs: cmdline: Update serial_tx_buffer default value
Date: Fri, 27 Jun 2025 09:06:04 +0200
Message-ID: <20250627070604.6580-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: SJ1PEPF000023CE:EE_|MW4PR12MB7358:EE_
X-MS-Office365-Filtering-Correlation-Id: 46d3076c-8f87-4adf-b08d-08ddb5491a31
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?T4BKY3f3K8XdOlW6jGP8zMc8/US3KoOuVsg/cOrcyaz+jQQ9LVs2ZvwPlf4s?=
 =?us-ascii?Q?Ve74+TNc06tFGGIBeMHQSJj9tZW/sbsmFnsPR+aqQEhYI8/frEFUxo6BAks6?=
 =?us-ascii?Q?2Zb5EIVqqC8KLMPvrkQmKoCQIEwLZga+Wbo+vH/Gh4jNMSMGUIpAIMa6mRVm?=
 =?us-ascii?Q?GjjglCv1UuXqCGzEJy0KWbDJTTAzIE+19KkJPYpLM45QaXIr0ZpF8SP/b+jy?=
 =?us-ascii?Q?0TXw7QIOaEIwKc8PlMuSXJ3mfRHKsdaRZzVOhXkMwjHl0KZgkWk0mthR2SKC?=
 =?us-ascii?Q?Q161O5eJORWovu72z76mctPj4+msWsPfuatqPirwKwTwDuixuqqPRKbMTvSq?=
 =?us-ascii?Q?uC8NTa0mbl3Cp+SStka5tHVol0r/O4GYhyGe4+Wd3w6zgbr/r9ktsUF6+KAd?=
 =?us-ascii?Q?u1tE+UPMDX+O65GIIIjCrnhmJr3seXv7lMyXo6JrlROBsPfBngmuGfw1AkZJ?=
 =?us-ascii?Q?aB3f/aeO3Pfd264MtafVua6e7TSXoehZKxlKiagla9rNZ48h2Z9j6BYDIg4b?=
 =?us-ascii?Q?zH/+Z3J1vXBb919u4R7jDpuKr/PFC8+q/eH6YSC63/t7N97zV8SPgeRswnDt?=
 =?us-ascii?Q?OiVAewF0tSEbYlKiJtzR6xVQbReoEjsvR3Cnp900GJr4ocZQmWwaLYilmRef?=
 =?us-ascii?Q?HpbMeZDGxNEpMY23wrJsDoKAzodu+GPQbzjndFJ0WjIJw0hklR27xQT0zAkD?=
 =?us-ascii?Q?JNkxoA/vSKfJNBsWfu90RdbP7vNoaFmYSkYz/yCypgdUE7d2ZsH0YJo9h37G?=
 =?us-ascii?Q?mRc3F7r2c5QJOzqpefQh1PBbLIf30pEYttGDJOP8c4vZeQPt+a+FPvtKESvs?=
 =?us-ascii?Q?j3TXNmM87Sz8MRlF5z5GE6gn2ywNN3kVawlaBKulBDTMB7C6V6I9YdzZ89Ak?=
 =?us-ascii?Q?+DKRtnLpSvOzfQmnv6g+bp2E6bZ5mgff0joPpMA76vTxYpIXelUVF1ieZgRs?=
 =?us-ascii?Q?SkvBO5rzh9i3BCJSUj+ppNcgPbB8J+PNnyJpwOjWndK1o3G7DBP7qwtTDLe8?=
 =?us-ascii?Q?IpVnCxGyMjLkuTzrWSQVZq2F549DtLu/l1VhTQGafhryQ+Z+1L5Ee2yGTdha?=
 =?us-ascii?Q?+RMnWf6uJGHwtgrZ9J93reuAkyo/zrwOIbCMO2OBCZFONTNyQIaKG2zcyolz?=
 =?us-ascii?Q?acJE3bnmY4j8rq7olVuK/y7BLqkBOpEF6LezkgZsVu5VO1B5T1tppat9htN1?=
 =?us-ascii?Q?pNgL1sex4PvrPN9TwWxPn4nco2nxOMy9s8mq7O3PdtS9F3RwXy3nwAUc9Ot7?=
 =?us-ascii?Q?qBvRH86yz7p2gEO7eqtjl80D44hVWc3NLH9uOdN1SVCralBY++NcaWpPUqbx?=
 =?us-ascii?Q?nv3O0/igFd4NA6sjglG7p+5ws7UxoO3p4up6f+Peevw5DuJyxy2kYY82XL2k?=
 =?us-ascii?Q?An+uxkBeCKPhDCuqzjL2MyP2bmVTzwGkuj2ZfKUnqgqE8JmR+PkvVGvPKA2c?=
 =?us-ascii?Q?0B6a5CB0gBNWBLBS7H6CL2VFXE+MLUUsWgHcBVE81S40qb9dE5Zh7ESE+gy5?=
 =?us-ascii?Q?zGl3yPITG+4kH42YpND7XN7BVvox+DmwDhO/?=
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: 27 Jun 2025 07:06:13.1921
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 46d3076c-8f87-4adf-b08d-08ddb5491a31
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:
	SJ1PEPF000023CE.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB7358

After commit 4df2e99d7314 ("console/serial: set the default transmit
buffer size in Kconfig"), the default value is set by Kconfig option
CONFIG_SERIAL_TX_BUFSIZE. Moreover it was bumped to 32KB by commit
d09e44e5d8fd ("console/serial: bump buffer from 16K to 32K").

Signed-off-by: Michal Orzel 
---
 docs/misc/xen-command-line.pandoc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index b0eadd2c5d58..6865a61220ca 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -2370,7 +2370,7 @@ accidentally leaking secrets by releasing pages without proper sanitization.
 ### serial_tx_buffer
 > `= `
 
-> Default: `16kB`
+> Default: `CONFIG_SERIAL_TX_BUFSIZE`
 
 Set the serial transmit buffer size.
 
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Fri Jun 27 07:48:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 07:48:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027347.1402011 (Exim 4.92)
	(envelope-from )
	id 1uV3oc-00006d-Er; Fri, 27 Jun 2025 07:48:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027347.1402011; Fri, 27 Jun 2025 07: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 1uV3oc-00006W-Bw; Fri, 27 Jun 2025 07:48:06 +0000
Received: by outflank-mailman (input) for mailman id 1027347;
 Fri, 27 Jun 2025 07:48: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 1uV3ob-00006Q-0L
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 07:48:05 +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 0d797d51-532b-11f0-b894-0df219b8e170;
 Fri, 27 Jun 2025 09:48:02 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a51481a598so974627f8f.3
 for ; Fri, 27 Jun 2025 00:48:02 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-74af57dda03sm1627830b3a.147.2025.06.27.00.47.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 27 Jun 2025 00:48:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0d797d51-532b-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1751010482; x=1751615282; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=SvoiEDz3uqGSRFDvJoLdBNSj3wkXJ/6jRGTzHM5+WyM=;
        b=DrW/gM0QQ2xQcYyEXZCEXTOxDZ/HIV9wLMsiYjacAPHYfmUYsyqscs4ZZ+xTgHxFc2
         h8efy9T5w4iewqoJOU+q5bIxj9chkW/VO4uTdJ4kSJi5KVTqKf9itEmMjvefq71EB1oA
         q0M1OpEHvyvF3CPpZZZ9dCuPzQI+9MIUpmOVFyWSJcumFXeUEWcKkckFGI7rvCs3RnoS
         /gd3JsIdvS00mtjHJge+baF2afuvndap6GiKjwC6oL/hcJ1/UUjx0R4cn+9l0JQX2Kyb
         8BM2x4OiWW+CZgTmCe4u/2XEjCHKelt2SVWahbdb1tSu/piQ62RqoCZqScoH3eunjzw9
         n5iQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751010482; x=1751615282;
        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=SvoiEDz3uqGSRFDvJoLdBNSj3wkXJ/6jRGTzHM5+WyM=;
        b=NMZZ/DIxha/oQ/YGxrCZooeJPKNcEIr6K9s+yoAE28d3KIB4Au6gH24R46Kq9VA9y5
         h+MexpCS4v6eq0pijHGh6rbcPmeesBuUNL935gGbmYV1bH9oKcu0916oRG444l+i3Szx
         cYbTHmzTWpMbdF6yN3slVD8hn2NP/+z8W3fVMK5EtObkcgmFcaj20OsC9pEMvYSAQgLR
         H2mb7HndfZrM+yYc53dEh8a4e/3rTwHWyundpaBmYdoIUJNcrFLXg1ohaB5fp3nolpxr
         b+DGpVQfwwgoDMBRgUPQIV/qTHR1/WSg1rTKIwm6Nz5XlmzZK6usyru8looelWyPouFr
         368A==
X-Forwarded-Encrypted: i=1; AJvYcCUBi8XpAKZA7wIfRK+Lv8V5Kg3dHGTRhitv+nzPOb9r2MOBzOSwwtoJPdrjZrcezmg9udRuDtp2dL0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxvkxQYa0A0r3Jr1n9eIklXsb1+VoBZkDJKngYrRZwfDt7vWIB2
	QiN1oWilFe8NJoVzsmu7aDhVmfo7wrOXhaDygqnILicfz2Xf/tmbh2IlNpqZU1Fgag==
X-Gm-Gg: ASbGncsFL4hfLJDPtqG5oKZszjaOzOT5P/mkoJ2yZ0K+XeC6sD52IIpSmxejcFEftHX
	KKx+R3wC1a0PLqWT+ETjHWtftaBpe9igwHZeVj+0IMa3YiW7R1tIpDUaHP3oXAbwcDMXq9ej4zB
	+5PWSQsAV5w/vPtA+gdUcF4k3L1X9BPDKp4ZCf8K1olTKzfe7B05dA7kEMxiWPjA3xYYq48B84C
	14pHKiHlhQRufJhhVc/UsmFPiSgUH4VVVUMyTD/NVfhiefgqxwzvU7+VtTaZnxVQKqOtvM5wYlg
	FiuAavMA8rRpdLWGWr46cSodykMGYr6z3h2F2rz62LFG6QcyHPjqQFYgSvnDfGZmeKOUmmPofpo
	pbjwFyp8BtX2NN4egamW3DUMWACUrnN96KN5V8WLQ4Nphi3s=
X-Google-Smtp-Source: AGHT+IFucaUMleARgauCHPupf374+ojevGldWOs7MmA8d1IcaIK5cyoDSaiSkoxr5xoMC/zgdmJmRQ==
X-Received: by 2002:adf:ed83:0:b0:3a5:3a03:79c1 with SMTP id ffacd0b85a97d-3a9001a1778mr1547820f8f.48.1751010481800;
        Fri, 27 Jun 2025 00:48:01 -0700 (PDT)
Message-ID: <7c9d39b0-8bef-4535-b8a0-e548eda9365b@suse.com>
Date: Fri, 27 Jun 2025 09:47:51 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] docs: cmdline: Update serial_tx_buffer default value
To: Michal Orzel 
Cc: Andrew Cooper ,
 Anthony PERARD , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250627070604.6580-1-michal.orzel@amd.com>
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20250627070604.6580-1-michal.orzel@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.06.2025 09:06, Michal Orzel wrote:
> After commit 4df2e99d7314 ("console/serial: set the default transmit
> buffer size in Kconfig"), the default value is set by Kconfig option
> CONFIG_SERIAL_TX_BUFSIZE. Moreover it was bumped to 32KB by commit
> d09e44e5d8fd ("console/serial: bump buffer from 16K to 32K").
> 
> Signed-off-by: Michal Orzel 

Acked-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Fri Jun 27 08:17:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 08:17:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027371.1402022 (Exim 4.92)
	(envelope-from )
	id 1uV4Gg-0004Zo-MC; Fri, 27 Jun 2025 08:17:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027371.1402022; Fri, 27 Jun 2025 08:17: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 1uV4Gg-0004Zh-IM; Fri, 27 Jun 2025 08:17:06 +0000
Received: by outflank-mailman (input) for mailman id 1027371;
 Fri, 27 Jun 2025 08:17: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 1uV4Gf-0004Zb-8m
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 08:17:05 +0000
Received: from NAM02-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam02on20618.outbound.protection.outlook.com
 [2a01:111:f403:2405::618])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 18790c10-532f-11f0-b894-0df219b8e170;
 Fri, 27 Jun 2025 10:16:59 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by MW6PR12MB9018.namprd12.prod.outlook.com (2603:10b6:303:241::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8880.22; Fri, 27 Jun
 2025 08:16:56 +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.8835.027; Fri, 27 Jun 2025
 08:16: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: 18790c10-532f-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=sx1QJYCoEXA4GRqE1sBn/HhdBKhuR5UevIzFonLofMEN7BArl5nrM0HG99t8mxjc8AcKrCAoXtOkCy7204asuM5xihjTqzKRDPEAfEmM1aDLFvJdfbLsOqcoah8u3Tfrd+qsx23mOjza5ZgLpu9HvvXXDffA7iVORHlmEEZhOXKIFcWlI8BNW3aubXwk/4b/jeHpFU4VlnIs/I3v5Jn6tLR6heQL5GNBs8KuCSMYl0kx28NYvavp/4t2XgS6NCYpt9sqpWwDE8Fpnpj1V8UwnhunC1915O51J3aqHgLRnDPk4b67lG/fyulb0PYowlX8Ihz/wWK0OexlXtb3e99XEQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=OhursG92AhVjiFUsg1WjvyI4dMawgJC4uy8nKrFwTaw=;
 b=xs7jrE4VuHV81wcIcjcosw1SABb7cw8mZcWlefYs0LEBpJCfsBanW3qf7iee4wRakhIdpMdmouDNQPjgKGplbTOn0o0KYpEOPFVXSRfwS0JQhe5FPQ3Ctk9Y1P357oHWhxXceHF3bFNXE5uuVLWLvK4ditpyZYEJ30LVq4T8kXlwuxhIyLJfj68qDSfeas1ltBHCofkfIzLgi7TW4NITJLzJLnWy5O/Q9cNig7p3qct8CtdydTLqb0NMpOfuZCONLVsGrywVPcYD59kyOUmmrW8RBVklpMnRWHY5eGv0Am0DSwOLRaFctWkIVr8r2a6Rupa23GFJR2bJQM2mpaPmZA==
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=OhursG92AhVjiFUsg1WjvyI4dMawgJC4uy8nKrFwTaw=;
 b=DC7mh2wzlj9FHh7C0Nf78aHt7Dhs6yn0T8HO55LUt7DKchiuwr3iLdNyLpE9K0T35sOnYkSsw8w4vloWjmlEDXWk0uyaY6W8DuZyjNPZotnasK47Nklyd7yfw725WzcWLA+E++YN7WNdsEqApjiGRp7+EnTUiLuHXmwHVEgKTIA=
From: "Chen, Jiqian" 
To: Jan Beulich 
CC: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Andrew Cooper
	, Anthony PERARD ,
	"Orzel, Michal" , Julien Grall ,
	Stefano Stabellini , "xen-devel@lists.xenproject.org"
	, "Huang, Ray" , "Chen,
 Jiqian" 
Subject: Re: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
Thread-Topic: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
Thread-Index:
 AQHb23yakGdVC9XxvEWnYcnp8zrTt7QI/QAAgAGa9QCAAQzVgIAG5D6A//99hgCAAJwoAP//hioAgAHew4D//5oCgAASTfCA//+FrwCAAIi+gP//u5+AgAGwYID//8AMgIABfE8A//+xAYAAFS19AA==
Date: Fri, 27 Jun 2025 08:16:54 +0000
Message-ID:
 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 
 <5c4b186e-686e-4fc8-bcf1-854bc1f5ec8b@suse.com>
 
 <9d5d0e44-66c3-4e3f-8704-2c862c5f5aff@suse.com>
 
 <3638e73c-2a83-4164-9a84-839245245727@suse.com>
 
 <771cd5b7-2b89-49b1-9aba-8cd79319d3ce@suse.com>
 
 <7753470a-efef-478a-bbe5-ae48d008cfdb@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.8835.025)
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_|MW6PR12MB9018:EE_
x-ms-office365-filtering-correlation-id: 3d7bc48c-a59d-44cb-defd-08ddb552fa6e
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?UmdsSlFLSGVoT1QrbFcxT0IrSkpVb3lkemlRWXlyY29HNUwzdUdPNmlrRkp2?=
 =?utf-8?B?Q283WmVIU2hFeFRhRlNIMmRPK0RGRnZ5TGhIS3BKMitYeG9uVFBnUEZFdGEv?=
 =?utf-8?B?V3VnOEQycHZtWXlTRzl2NkdBVGxIRk1pV3lndnlYQWRMTnZKZHVCRWw4Y0gw?=
 =?utf-8?B?RVhWcnJCaldNazJOZHg0U2VmOENzc3cwSmZuMjllaFE1ZW5xVnJpa09hZlh4?=
 =?utf-8?B?RHdRbFRlcHZyQWozMjBoTDM1UjUxQmdNY1N3ZmNidm1hMFFNVytiQTlSaGg5?=
 =?utf-8?B?TEhTdnpPUWduMXZwRkx2V3R0UGd1cndyaDlsYWx1S01XRm5oblR2N3ZPaVFE?=
 =?utf-8?B?VmdIOTFVczNpNzNlL3habzZWTk5TMEVvZnJmNnJoWDNDU0R6YndYL0Ria1hy?=
 =?utf-8?B?My9FNlVDa2lvS3QrcXpTMnAya0xHRFV3cDc3WkU2SitZYzBHVDg3aFJwclhN?=
 =?utf-8?B?VTQxUFZyeDF6YVhQY3lxaEhHVVMvWEhYSXAzcWxkN1dURHl5Ym85dHF2YzJx?=
 =?utf-8?B?T294VW1JMlk4R0NiMHp4VmhqSVVGamN3ckhOeFVZUC92eGJnalZYQ1FCTnlK?=
 =?utf-8?B?UEt3YTFMUmNyb2g5cGtnUDdiWHBteCtwM1JtVGZQTEFiaFl3TFdVTUFuNjlO?=
 =?utf-8?B?ZVJzSnA0NnRkdW9wRzJBMmZSWC94ZzNjemRNdWdoSTVWMVduZ3RFM3lMRTBM?=
 =?utf-8?B?WUwyWmVnd3czOVI2VktTS1Z2amUxUlhYZjd4akc4M2owYUN2MnZUOEZlbXFQ?=
 =?utf-8?B?SGNtVmRRVUlrd0xEVGkxeno0MmVXbldjL1R0SStRT3NzQU44SmowZ0ZvL1RU?=
 =?utf-8?B?TUpSQXp6TjNkaVc5U0wxdHlvZHlaTDBxeGpuRU5wTmdmNE5vZUFhekZOaklO?=
 =?utf-8?B?Z21kYlZrUXo3ZTFsbjNZaW0wY3lBS0RpUmFYUFI5Rzg4Ukc4allveGgrTlVD?=
 =?utf-8?B?SWFkay93Z3F0N1JWeTlMUGg1VUFxbjBnVHdybFlybGFRRDliNFJROEJ5R2dy?=
 =?utf-8?B?OGNJU3hvTjBOSVdTaGRWaDlHd3JWRU43QmZaeGx0VWZ3SDJKZHJzWU1CdWt2?=
 =?utf-8?B?MGR0TDgyQzVWaDhvZlp6NTV0SnV3cFBIZ1RLT2c2L01ybGNCZ09CWXRtSGxQ?=
 =?utf-8?B?VUNYaVhGK085eWpZOXFjL096ZHZXUU5XcDVMQ0JXNUFFakk2cUNhdXJMUVll?=
 =?utf-8?B?dDcwdmpnNDhkbmhTU1Q3WTlrNzNTSVVDRndVVjN5ZHJwdEdWVEtUS21XdHFJ?=
 =?utf-8?B?U2lXbklRNXFnTG1VNmVuNnhRZjd5SnJZYVhnQU03VDlKRTZhOC9SRGIycXcz?=
 =?utf-8?B?V1pqVDRvRlVRT3U5SGs0dnFrdGFOUm5PS3p5WHl4R2pmOEUycFhydVJxVDlq?=
 =?utf-8?B?aVRLcCsxMnozTjl4aDUzSHFydnpiTUNGWEFLM1NOYWZVTi9vNEtOUGZSVlkz?=
 =?utf-8?B?MU5jLzVjZFRQYlU4VWxVcWNFQWhxbTVhUENtSThXdElLeTBveUYycG1xeXlE?=
 =?utf-8?B?WXBOMXVDQ0x2QTlEeE1SclNHazhjcElucnZCbThCeUs5U09neW9vRHZHdHk0?=
 =?utf-8?B?YWxaSk9nV1J3d2hzUDhHRkh3V0Q0UkdpcDdDRlMxaHQrSlF2NkM4anhIaHZw?=
 =?utf-8?B?UFpKR3lYZkNvdG5DWGtmdWxUYlFTQ05iRWpEcVFZN3hNdDlVQlEvOXRwWHJH?=
 =?utf-8?B?NWxkQVh6STlhREVLbjBZNUpmcndLeVRUVXIrMEVhaVJrdTMya1dtTTEvSlUr?=
 =?utf-8?B?VkkwU1NnVTlDSFZTSFFFbFN5UVdhL3hEeEU1SDdpU1puMDgxTGlOTURmOVEr?=
 =?utf-8?B?TGo1TjJoYTNYZU14UVI5RGtFdVdFVzRURGZzTUFsU2Fod3U1WGF6N0xSSHNM?=
 =?utf-8?B?R2l0ZGlUL2x3eGhLa216TnBDYWRubEtBc2ZLSVZnS1RqVkZkVndjYzlsNnlD?=
 =?utf-8?B?ZktJMGZ1TDBsZ0c2L241WDNLY0I4K1JVTk44N0lVOHMxU2hGWnEvbkFMNXRV?=
 =?utf-8?B?ZExPWW1qa0hnPT0=?=
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?U2pPZnhvK3FjTmsxZ3pCVjZqenN5cWtmeUI1Q2dibEZlK3NyZmtTZTFXbXY0?=
 =?utf-8?B?MkZ6TWx4NUVjMXVyVDdHcWJPMGpzbHFqcDlLd1d5aVlmeVFNa29xVzVMOVFh?=
 =?utf-8?B?alNHRHBXTU1DQjJVbUErWTVFNktpQmZ5ejJobmNPS1MyM3NuVEU2UmpyWldN?=
 =?utf-8?B?UjFTUjJYN0ptbkpwbU4zdVE2c1h4dkVFTC9JN2xLSm5Yb281ZUo3cVpxZ2x3?=
 =?utf-8?B?alRTWEtaS29UblZsLy9rS3NtSE9QWi9oUzM2bG00UDZ3ZGQ3Q21XdDBFWFdq?=
 =?utf-8?B?dXdpQnFCUEQ3VS9WbU4xUGlmY2RaaUMzTGRzSlF4N2hKMkhFTENSdjhKRWNI?=
 =?utf-8?B?QXRIcmlXZXg1NFpDQzdtWVlzSkhiZER0OER3V2R6dDRETGZMMjJnUWh6WlNY?=
 =?utf-8?B?ekhEYWlxKy85TVJWaDEzbUV3b2JZdnkxR1NVR21qUWhJbzZhcHhuNGtTRHFu?=
 =?utf-8?B?ekdSTVovVk80ejR3WXRoRE9sRlBFUHEzdldtMC9mc09jb0M2M0hTdnB2dSt2?=
 =?utf-8?B?NmhQTTUxOXZPSmZrcy9Qb1cza1ROY3IveGNYNG53WFBqL1c5MDVGTzB5NEt4?=
 =?utf-8?B?SGVsOU51eEt2ZlpKeVBPYjFPY2lva1RsNHc5ak1PK1E4d0diRTVGc2VpTk90?=
 =?utf-8?B?MjVsbDk0MUI1TWNNRmlxazRwQ0dld3E2UkQ0TGVZOTJFZ3lzZHZjUWprdjZs?=
 =?utf-8?B?NFNKandEZVV2N0h1enZtbmEvR0NyQ3J2RGp5UzRIQ3lzZ0JTcEdPNmpQcGJV?=
 =?utf-8?B?WEhTUjdNWkxOYUZ5UVhkMnErQ2pKTVpDSnNkUjZFZ1lCWTg0b1N4eTFPdWg4?=
 =?utf-8?B?bm1vM3dwYW9tZ1p1aE1FM3diQUhmaE1HenE4Mk9zY3VQcWd5VUd3VjR5VlFX?=
 =?utf-8?B?VC9JdVplWW9pRnRYb1ZoMXRMNUtQalZ4Z2ZYYTkyUlRIMHdsd1JWQkIyYW1o?=
 =?utf-8?B?VFBYZnZwMVp1ZzBIN1JTaFhCNHI5S0RjRGFEbkcxV0JyV21lbXNQeUN6alBH?=
 =?utf-8?B?bjhUR3JwNDVMcTZhbXUxenhaUXJhTldla2xUZjhpUldYdGg2c3ZDL01kdGhm?=
 =?utf-8?B?M1R0aC9hR0ROSXZyZlIvNERoUzZMLzFQRjZQMUt5VUd1VG50bkFWQ2xQTWtE?=
 =?utf-8?B?WXFadDRUYTcyaTEzVUhJZk1Wbk1WMk1Eb0RkUU0yQ1AweEFIMkVlU0xZdWxZ?=
 =?utf-8?B?aFpqMjNubGhPa2h2UUpmcERsVVdqNzRJRTlzNUxEdnp6c0ZlT1FyUW81UzA5?=
 =?utf-8?B?N1gzT0k5M0RHNVJDaVFwUmxEdWVsK0FCWjhvMFBxSW9JVkhnSjdPSU9HaWxO?=
 =?utf-8?B?T2pBT3k5UitmZWp1S01tK21sMHVjU1NzMlBtYmtianpwS2poWjVRdTJOVnNT?=
 =?utf-8?B?R2FoWGF4VnQyRjhzWHl4eitUUWlEY1hpVHBQTE1GMktmazFsSzFkbU5CQkdJ?=
 =?utf-8?B?NFU2eG9uWkxFT3JTb2FlZEk2emI0ZFgrTTRONTNoeUtQa1AxbmhRWmx4dG1n?=
 =?utf-8?B?U1BIUCtpZlFvbmNNTWZPREMvdjRZVWFwZ09hMzZRTjZRSW9haGd6c21zNUVl?=
 =?utf-8?B?UEdUN2Vxano3NjhRVXNYbjFaMVBaUU9naTRWc1RQUHNYRkY1MHR0UjBOMkdN?=
 =?utf-8?B?cndBYmhoWlIyN0ZlL2ZKb25rU0xZalVlejNWQmxhcUZYdVROK01hTCtBSS9k?=
 =?utf-8?B?QUhvT1kxRit4NXZ4MnpHTjVqdTJudWpGSEJlb3pQeTc0UlVJWEVpSEU0bEE2?=
 =?utf-8?B?clcxd1FzOGtOaFhLU3VtaGtJOGxJTWJxVFpnL1ZFWDRaaG9paWdIZW1yWkg2?=
 =?utf-8?B?VWpDaEkyaXlHZ0NHeXUwZmk3T25tT0hOUldjNjFKbWNaN3lkM3pXSFNudk5l?=
 =?utf-8?B?RmM3TzlPZGJqcnU5TDNLOTFIOGRKZUFjbGxDNkRJWWJhTUNLTW5pV0JLMi9G?=
 =?utf-8?B?Y3BiZVA4TklrS0FyaGlDZXVEWGxhVHg2eC9IU1p1dW1QQWhMSEJ1NXE1Wm04?=
 =?utf-8?B?d01Tb0lwVHpvQndhTHN5OGZKU2pYVUk0T0d4Z2J4ZzZiRGF3VGxvTnNuU0tm?=
 =?utf-8?B?M1VKT1MybWlzS3c3OEM0ODNTVU9VZCs1dUo4Vm9rSWtpbnhtU0FpYTBLYk1T?=
 =?utf-8?Q?5NwQ=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <3B619359734FAC4B8C74819D1CF62AB4@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: 3d7bc48c-a59d-44cb-defd-08ddb552fa6e
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2025 08:16:54.9392
 (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: b0qRwR4ijV3hyyXJqQDo9eEAo9mMCY11nVlSkX6s2XiDw6WV8FakKnLNTErUcexdBuGH+M24OPD12R0DWo2p3w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW6PR12MB9018

T24gMjAyNS82LzI3IDE0OjA1LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMjcuMDYuMjAyNSAw
NDo1OSwgQ2hlbiwgSmlxaWFuIHdyb3RlOg0KPj4gT24gMjAyNS82LzI2IDIwOjA2LCBKYW4gQmV1
bGljaCB3cm90ZToNCj4+PiBPbiAyNi4wNi4yMDI1IDEwOjAzLCBDaGVuLCBKaXFpYW4gd3JvdGU6
DQo+Pj4+IE9uIDIwMjUvNi8yNSAyMjowNywgSmFuIEJldWxpY2ggd3JvdGU6DQo+Pj4+PiBPbiAy
NS4wNi4yMDI1IDEyOjE2LCBDaGVuLCBKaXFpYW4gd3JvdGU6DQo+Pj4+Pj4gT24gMjAyNS82LzI1
IDE4OjAzLCBKYW4gQmV1bGljaCB3cm90ZToNCj4+Pj4+Pj4gQWxzbywgYXMgc2FpZCAtIHlvdSB3
aWxsIG5lZWQgdG8gY2hlY2sgd2hldGhlciBvdGhlciBhcmNoaXRlY3R1cmVzIGFyZQ0KPj4+Pj4+
PiBkaWZmZXJlbnQgZnJvbSB4ODYtNjQgaW4gdGhpcyByZWdhcmQuIFdlIGJldHRlciB3b3VsZG4n
dCBsZWF2ZSBhIHRyYXAgaGVyZSwNCj4+Pj4+Pj4gZm9yIHRoZW0gdG8gZmFsbCBpbnRvIHdoZW4g
dGhleSBlbmFibGUgdlBDSSBzdXBwb3J0LiBJLmUuIG15IHJlY29tbWVuZGF0aW9uDQo+Pj4+Pj4+
IHdvdWxkIGJlIHRoYXQgaWYgaW4gZG91YnQsIHdlIHB1dCB0aGUgX19hbGlnbmVkKCkgdGhlcmUg
dW5jb25kaXRpb25hbGx5Lg0KPj4+DQo+Pj4gTm90ZSBob3cgSSB1c2VkIF9fYWxpZ25lZCgpIGhl
cmUuIFdoeSB3b3VsZCB5b3UgLi4uDQo+Pj4NCj4+Pj4+PiBUaGF0J3MgZGlmZmljdWx0IGZvciBt
ZSB0byBjaGVjayBvbiBhbGwgZGlmZmVyZW50IHBsYXRmb3JtcyBzaW5jZSBJIGRvbid0IGhhdmUg
dGhlbSBhbGwuDQo+Pj4+Pg0KPj4+Pj4gWW91IGRvbid0IG5lZWQgdG8gaGF2ZSB0aGVtLiBZb3Un
ZCBuZWVkIHRvIGNhcmVmdWxseSBnbyB0aHJvdWdoIHRoZSByZXNwZWN0aXZlDQo+Pj4+PiBzZWN0
aW9uKHMpIG9mIHRoZWlyIHBzQUJJLXMuDQo+Pj4+Pg0KPj4+Pj4+IFNvIHlvdSBtZWFuIEkgc2hv
dWxkIHJlbW92ZSAiI2lmZGVmIENPTkZJR19YODYiPyBKdXN0IGxldCBfX2FsaWduZWQoMTYpIGZv
ciBhbGwgcGxhdGZvcm1zPw0KPj4+Pj4NCj4+Pj4+IFllcy4gQW5kLCBhcyBhbHNvIHNhaWQsIHdp
dGggYSBzdWl0YWJsZSBjb21tZW50IHBsZWFzZS4NCj4+Pj4gQWgsIG15IGNvbW1lbnQgZGVmaW5p
dGVseSBuZWVkcyB5b3VyIGNoYW5nZSBzdWdnZXN0aW9uLg0KPj4+PiBJIHdyb3RlIGEgZHJhZnQg
YXMgYmVsb3c6DQo+Pj4+DQo+Pj4+IC8qDQo+Pj4+ICAqIFNpemUgb2YgdnBjaV9jYXBhYmlsaXR5
IGlzIGxhZ2VyIHRoYW4gOCBieXRlcy4gV2hlbiBpdCBpcyB1c2VkIGFzIHRoZSBlbnRyeQ0KPj4+
PiAgKiBvZiBfX3N0YXJ0X3ZwY2lfYXJyYXkgaW4gc2VjdGlvbiwgaXQgaXMgMTYtYnl0ZSBhbGln
bmVkIGJ5IGFzc2VtYmxlciwgdGhhdA0KPj4+PiAgKiBjYXVzZXMgdGhlIGFycmF5IGxlbmd0aCAo
X19lbmRfdnBjaV9hcnJheSAtIF9fc3RhcnRfdnBjaV9hcnJheSkgd3JvbmcsIHNvDQo+Pj4+ICAq
IGZvcmNlIGl0cyBkZWZpbml0aW9uIHRvIHVzZSAxNi1ieXRlIGFsaWduZWQgaGVyZS4NCj4+Pj4g
ICovDQo+Pj4+IHN0cnVjdCB2cGNpX2NhcGFiaWxpdHkgew0KPj4+PiAgICAgdW5zaWduZWQgaW50
IGlkOw0KPj4+PiAgICAgYm9vbCBpc19leHQ7DQo+Pj4+ICAgICBpbnQgKCogaW5pdCkoY29uc3Qg
c3RydWN0IHBjaV9kZXYgKnBkZXYpOw0KPj4+PiAgICAgaW50ICgqIGNsZWFudXApKGNvbnN0IHN0
cnVjdCBwY2lfZGV2ICpwZGV2KTsNCj4+Pj4gfSBfX2F0dHJpYnV0ZV9fKChhbGlnbmVkKDE2KSkp
Ow0KPj4+DQo+Pj4gLi4uIG9wZW4tY29kZSB0aGF0IGhlcmU/DQo+PiBUaGF0IGJlY2F1c2Ugd2hl
biB1c2luZyBfX2FsaWduZWQoKSB3aXRob3V0IENPTkZJR19YODYsIEkgZ290IGNvbXBpbGUgZXJy
b3INCj4+IHZwY2kuaDoxODoxMzogZXJyb3I6IGV4cGVjdGVkIGRlY2xhcmF0aW9uIHNwZWNpZmll
cnMgb3Ig4oCYLi4u4oCZIGJlZm9yZSBudW1lcmljIGNvbnN0YW50DQo+PiAgICAxOCB8IH0gX19h
bGlnbmVkKDE2KTsNCj4+ICAgICAgIHwgICAgICAgICAgICAgXn4NCj4+IEkgdHJpZWQgc29tZSBt
ZXRob2RzLCBvbmx5IG9wZW4tY29kZSBjYW4gZml4IGl0Lg0KPiANCj4gV2VsbCwgdGhhdCdzIG9k
ZC4gSW4gZS5nLiB4ZW4vc2NoZWQuaCB3ZSBoYXZlDQpZZXMsIEkgc2VlLg0KVGhhdCdzIHNvIHN0
cmFuZ2UuDQpFdmVuIEkgZG8gYmVsb3cgYWxzbyBnZXQgdGhlIGVycm9yIG1lc3NhZ2UuIEJ1dCBp
ZiBvcGVuLWNvZGUsIGl0IHdvcmtzLg0KDQpkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUveGVuL3Zw
Y2kuaCBiL3hlbi9pbmNsdWRlL3hlbi92cGNpLmgNCmluZGV4IDUxNTczYmFhYmMuLjM1MGViNWYy
ODkgMTAwNjQ0DQotLS0gYS94ZW4vaW5jbHVkZS94ZW4vdnBjaS5oDQorKysgYi94ZW4vaW5jbHVk
ZS94ZW4vdnBjaS5oDQpAQCAtMTMsMTIgKzEzLDE3IEBAIHR5cGVkZWYgdWludDMyX3QgdnBjaV9y
ZWFkX3QoY29uc3Qgc3RydWN0IHBjaV9kZXYgKnBkZXYsIHVuc2lnbmVkIGludCByZWcsDQogdHlw
ZWRlZiB2b2lkIHZwY2lfd3JpdGVfdChjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldiwgdW5zaWdu
ZWQgaW50IHJlZywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IHZhbCwgdm9p
ZCAqZGF0YSk7DQoNCisjaWZkZWYgX19hbGlnbmVkDQorI3VuZGVmIF9fYWxpZ25lZA0KKyNkZWZp
bmUgX19hbGlnbmVkKGEpIF9fYXR0cmlidXRlX18oKF9fYWxpZ25lZF9fKGEpKSkNCisjZW5kaWYN
CisNCiBzdHJ1Y3QgdnBjaV9jYXBhYmlsaXR5IHsNCiAgICAgdW5zaWduZWQgaW50IGlkOw0KICAg
ICBib29sIGlzX2V4dDsNCiAgICAgaW50ICgqIGNvbnN0IGluaXQpKHN0cnVjdCBwY2lfZGV2ICpw
ZGV2KTsNCiAgICAgaW50ICgqIGNvbnN0IGNsZWFudXApKHN0cnVjdCBwY2lfZGV2ICpwZGV2KTsN
Cn0gX19hbGlnbmVkKDE2KTsNCg0KDQpBbnl3YXksIEkgd2lsbCB3YWl0IGZvciB5b3VyIHBhdGNo
IG1lcmdlZC4NCg0KPiANCj4gc3RydWN0IGRvbWFpbg0KPiB7DQo+ICAgICAuLi4NCj4gfSBfX2Fs
aWduZWQoUEFHRV9TSVpFKTsNCj4gDQo+IHdoaWNoIGNsZWFybHkgbXVzdCBiZSB3b3JraW5nIGZp
bmUuIFRoZSBlcnJvciBtZXNzYWdlIGZyb20gdGhlIGNvbXBpbGVyDQo+IGRvZXNuJ3Qgc2F5IHZl
cnkgbXVjaCBhbG9uZS4gRm9yIGluZm9ybWF0aW9uYWwgZGlhZ25vc3RpY3MgdGhlIGNvbXBpbGVy
DQo+IG5vcm1hbGx5IGFsc28gZW1pdHMgbWF5IGhlbHAsIG9yIGVsc2UgaXQgd291bGQgdGFrZSBs
b29raW5nIGF0IHRoZQ0KPiBwcmUtcHJvY2Vzc2VkIG91dHB1dCB0byB1bmRlcnN0YW5kIHdoYXQn
cyBnb2luZyBvbiBoZXJlLg0KPiANCj4+PiBBcyB0byB0aGUgY29tbWVudDogRmlyc3QsIGl0IHdh
bnRzIHRvIGJlIGFzIGNsb3NlIHRvIHdoYXQgaXMgYmVpbmcgY29tbWVudGVkIGFzDQo+Pj4gcG9z
c2libGUuIEhlbmNlDQo+Pj4NCj4+PiBzdHJ1Y3QgX19hbGlnbmVkKDE2KSB2cGNpX2NhcGFiaWxp
dHkgew0KPj4gVGhpcyBhbHNvIGdvdCB0aGUgY29tcGlsZSBlcnJvci4NCj4+Pg0KPj4+IGlzIGxp
a2VseSB0aGUgYmV0dGVyIHBsYWNlbWVudC4gU2Vjb25kLCB0aGVyZSdzIG5vdGhpbmcgaGVyZSB0
aGUgYXNzZW1ibGVyIGRvZXMNCj4+PiBvbiBpdHMgb3duLiBJdCdzIHRoZSBjb21waWxlciB3aGlj
aCBkb2VzIHNvbWV0aGluZyAoaW5zZXJ0IGFsaWdubWVudCBkaXJlY3RpdmVzKSwNCj4+PiBhbmQg
b25seSB0byBmb2xsb3cgY2VydGFpbiBydWxlcy4gKFNlZSAieDg2OiBkb24ndCBoYXZlIGdjYyBv
dmVyLWFsaWduIGRhdGEiDQo+Pj4gdGhhdCBJIENjLWVkIHlvdSBvbiBmb3Igc29tZSBvZiB0aGUg
cmVsZXZhbnQgYXNwZWN0cy4pIFRoYXQgaXMsIHlvdSBkb24ndCB3YW50DQo+Pj4gdG8gImJsYW1l
IiBhbnkgcGFydCBvZiB0aGUgdG9vbCBjaGFpbiwgYXQgbGVhc3Qgbm90IHdoZXJlIGl0J3MgdGhl
IHVuZGVybHlpbmcNCj4+PiBBQkkgdGhhdCBtYW5kYXRlcyBjZXJ0YWluIGJlaGF2aW9yLiBUaGVy
ZSdzIGFsc28gbm8gc3Ryb25nIG5lZWQgdG8gdGFsayBhYm91dA0KPj4+IHRoZSBzcGVjaWZpYyBl
ZmZlY3RzIHRoYXQgaXQgd291bGQgaGF2ZSBpZiB3ZSBkaWRuJ3QgYXJyYW5nZSB0aGluZ3MgcHJv
cGVybHkuDQo+Pj4gVGhhdCBpcywgdGFsa2luZyBhYm91dCB0aGUgZWZmZWN0IG9uIGFycmF5cyBp
biBnZW5lcmFsIGlzIGZpbmUgYW5kIGhlbHBmdWwuDQo+Pj4gVGFsa2luZyBhYm91dCBfX3tzdGFy
dCxlbmR9X3ZwY2lfYXJyYXkgaW1vIGlzIG5vdC4NCj4+Pg0KPj4+IFdoaWxlIGZ1cnRoZXIgcGxh
eWluZyB3aXRoIHRoZSBjb21waWxlciwgSSBub3RpY2VkIHRoYXQgYWRkaW5nIF9fYWxpZ25lZCgx
NikNCj4+PiBhY3R1YWxseSBoYXMgYSBuZWdhdGl2ZSBlZmZlY3QgYXMgbG9uZyBhcyB0aGF0IG90
aGVyIHBhdGNoIGlzbid0IGluIHVzZTogVGhlDQo+Pj4gc3RydWN0IGluc3RhbmNlcyB0aGVuIGFy
ZSBiZWluZyBhbGlnbmVkIHRvIGV2ZW4gMzItYnl0ZSBib3VuZGFyaWVzICh3aGljaCBtZWFucw0K
Pj4+IF9fc3RhcnRfdnBjaV9hcnJheSB3b3VsZCB0aGVuIGFsc28gbmVlZCBhbGlnbmluZyBhcyBt
dWNoKS4gV2hlbiB0aGF0IG90aGVyDQo+Pj4gcGF0Y2ggaXMgaW4gdXNlLCB0aGUgX19hbGlnbmVk
KCkgYmVjb21lcyB1bm5lY2Vzc2FyeS4gVGhlcmVmb3JlIEknbSBubyBsb25nZXINCj4+PiBjb252
aW5jZWQgdXNpbmcgX19hbGlnbmVkKCkgaXMgdGhlIGJlc3Qgc29sdXRpb24gaGVyZS4NCj4+IEVt
LCBjaGFuZ2luZyBfX3N0YXJ0X3ZwY2lfYXJyYXkgdG8gYmUgc3RydWN0IHZwY2lfY2FwYWJpbGl0
eSBhcnJheSBjYXVzZSB0aG9zZSBjb25jZXJucywgbWF5YmUga2VlcGluZyB1c2luZyBzdHJ1Y3Qg
cG9pbnRlciBpcyBhIGNvbXByb21pc2UgbWV0aG9kLg0KPiANCj4gSXQgd291bGQgYmUgYSBsYXN0
IHJlc29ydCwgeWVzLCBidXQgaW1vIChhKSB3ZSBvdWdodCB0byBzdHJpdmUgdG8gYXZvaWQNCj4g
dW5uZWNlc3NhcnkgaW5kaXJlY3Rpb24gYW5kIChiKSB0aGUgc2FtZSB1bmRlcmx5aW5nIGlzc3Vl
IGNvdWxkIGJlY29tZSBhDQo+IHByb2JsZW0gZWxzZXdoZXJlIGFzIHdlbGwuDQo+IA0KPiBKYW4N
Cg0KLS0gDQpCZXN0IHJlZ2FyZHMsDQpKaXFpYW4gQ2hlbi4NCg==


From xen-devel-bounces@lists.xenproject.org Fri Jun 27 08:21:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 08:21:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027381.1402031 (Exim 4.92)
	(envelope-from )
	id 1uV4LA-0006Fa-8c; Fri, 27 Jun 2025 08:21:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027381.1402031; Fri, 27 Jun 2025 08:21:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uV4LA-0006FT-5m; Fri, 27 Jun 2025 08:21:44 +0000
Received: by outflank-mailman (input) for mailman id 1027381;
 Fri, 27 Jun 2025 08:21: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 1uV4L8-0006FN-LG
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 08:21:42 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on2060e.outbound.protection.outlook.com
 [2a01:111:f403:2418::60e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bde09530-532f-11f0-b894-0df219b8e170;
 Fri, 27 Jun 2025 10:21:37 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by MW6PR12MB9018.namprd12.prod.outlook.com (2603:10b6:303:241::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8880.22; Fri, 27 Jun
 2025 08:21:32 +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.8835.027; Fri, 27 Jun 2025
 08:21: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: bde09530-532f-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=GEZwC4aW4c6SQ0scYVaVVgmHvA2HLMvOtVIXCe2r4IUrVjtRb3aDspCY6DiD47tAFw/M9nkwE8bp1ROGu4ZpY5PQ3t5wLG3L5AhRYypZaKTYCnoZz4G4XLtELvc1Q1XcOm5ChTjKpvyqmbL0dluPlBCOA2rDjZFgXN7FpacLU2ziQgtc3PQnlipkMEpcU93x8LSnEoIku377+AL83q83XusjIHmiEGQsvlaSb5M8ZLeBNzWursquLw0jj3X5RL61TqxHFDSKuDYB6fJK7htdrBtR3x5II7UU7ipCCD5y5Cuzc8KkgTF0FY4aRbMFB6ceYhI74Y4zw0T2EOfwTTypjg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=l5UVuIO3GysN4/UXKgvCjZjnkTdTUFeB0S5qGCTMhdk=;
 b=aPkGvGNpvRvsSCTgN5zOiB6FHGyg3OP8t53lQ1sjJv96S1k0fDizefUluYm1yDVwOI8KhSfTv/LyyOx7BewuUmE3A5TXiPuEuqIK1XpOb9PbE2Es/Qe7VfB5qrr3/28qIQTFvs7hN61XzG64CnTXeRteSAjBIf+6WA3ebvXfRgIeXEAzUbgzFjZOUDF07u+pmYUahbz7VEkeef7C8SasdL9sC6OKNKPbVCM17uE52XPEWP/WvLhC7b3lDknxafn1bTFQSwlf873HCK4GfVREIcYDRRG6Mk3jjhCQiUAI/HmGf4ha6UeNXnEJlMuhvYxfTVoAeWFhATsxChojZaC9WA==
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=l5UVuIO3GysN4/UXKgvCjZjnkTdTUFeB0S5qGCTMhdk=;
 b=VfB/Ci3thO1nKVBk0XSAEst0DYvAJTaPSFyZMk/exzicaIvsagqbEIwGtL/Alxfzu9gtNlSqvz5oFiZVGPeNULUDZ15FdzvowDAwsQXD7Vn12I5T72vijQ+2SbeOi9kcl/hJzQsqVLXSdTlgrwx0LJUYosJgglYJdsd+N2E97VM=
From: "Chen, Jiqian" 
To: Jan Beulich 
CC: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Andrew Cooper
	, Anthony PERARD ,
	"Orzel, Michal" , Julien Grall ,
	Stefano Stabellini , "xen-devel@lists.xenproject.org"
	, "Huang, Ray" , "Chen,
 Jiqian" 
Subject: Re: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
Thread-Topic: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
Thread-Index:
 AQHb23yakGdVC9XxvEWnYcnp8zrTt7QI/QAAgAGa9QCAAQzVgIAG5D6A//99hgCAAJwoAP//hioAgAHew4D//5oCgAASTfCA//+FrwCAAIi+gP//u5+AgAGwYID//8AMgIABfE8A//+xAYAAFS19AAAATX0A
Date: Fri, 27 Jun 2025 08:21:32 +0000
Message-ID:
 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <5c4b186e-686e-4fc8-bcf1-854bc1f5ec8b@suse.com>
 
 <9d5d0e44-66c3-4e3f-8704-2c862c5f5aff@suse.com>
 
 <3638e73c-2a83-4164-9a84-839245245727@suse.com>
 
 <771cd5b7-2b89-49b1-9aba-8cd79319d3ce@suse.com>
 
 <7753470a-efef-478a-bbe5-ae48d008cfdb@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.8835.025)
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_|MW6PR12MB9018:EE_
x-ms-office365-filtering-correlation-id: 52994dad-bcaf-40f9-ccd1-08ddb5539ff0
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?bG13amkwaUVWUUpTdWhGVTJOdFFnUU1SWERSbjBHNzE5QnFGU20vM2hwSWZx?=
 =?utf-8?B?alZkWUg0N0ppdndmRGU0ZHkwbkplNE9ORmFlZU5QUnpTQzlKTGZjV09mV0pT?=
 =?utf-8?B?SFJUWnVKa0MrVTZiaDJYb3lYNlpoSDZraDErSDVscENKeVRNOXRHbUVmUVBk?=
 =?utf-8?B?WEdCQ21PZEZYQXJEanJiMUkrZ2hRc2I1TjhySWVDbWZ0UFB6c3NWcitRSzhO?=
 =?utf-8?B?NVQzakJkUGIyYVljQ3QyT0RXSFJIVlRObFRuMS82VlhJSEdPWFBhZ0p1bXJ5?=
 =?utf-8?B?TUtsSkFuQkhJRk1MMVhSUUVlRXlJNWlGSEpiQTBra2RDbm45eXB6d3V1RTl2?=
 =?utf-8?B?ZkZiMk9hVjN0TlovYkNveHQ1RzRkZVdXR1BXWUFxajVVbmQ5dEZnRngvZXFk?=
 =?utf-8?B?TU1DKzVVcXFxRlVPcjNPNTYxWDZRUldGOVJmSTRGQ1dZSTJFbi82aHhWTktG?=
 =?utf-8?B?L2N5Q1dxZDRXbGJGa0NCNjB0Vk9wU3FvNWd1TFZNeHNObGhMQk1uWEk5TFlP?=
 =?utf-8?B?d1JZcVIrWDZzZEUwR1hnc21YZkI1TzJaSHlZMDJLK3ZBcTd6VzR6Y2g0dmF1?=
 =?utf-8?B?NUt5NXU5VC85SEUxbHdncGU1RGNaOXlpOFE5M1VoYzBGMUNLeHZXZnhBT2U4?=
 =?utf-8?B?d3lvV21CWVBrRG1wblE2UTRwUXFDVmxSQjRBMHhjbW54K2Y1OGlKMmViYzJk?=
 =?utf-8?B?ZmExSTExNGVEZ3VTbXpMVDZQbzRNN1JEVGZRdkFwYmVHR2RoSzNFODNYcmFw?=
 =?utf-8?B?Rlh5MFE4NGg1S2E3ZkEvbW9kd1FQSnk5RytRWUVNSjlSUmQxWVdsUFRwQlhn?=
 =?utf-8?B?Y2pEdHlKSXpnNTd5cFRwZTl6SERZb1pKcVNoNlBMNG9aUUR3SmN6NXFvM2lt?=
 =?utf-8?B?Tk42LzRnbms1YkZ4dzd1cnZ3V3Frd3VWRHpFYmJaOFF1VzZHNllueXo0WlE3?=
 =?utf-8?B?M0xGY1EzdHQ2V2VFRVVhNHJKckgvZjMzTGZRMFZDRmJlRGhscmhld29KUE1Z?=
 =?utf-8?B?TjJXZEMrcEtKQmVuSFpmQmVjMjNiYXl5Z05RaTF1UDFlOWxwT3B3RHd1R2J0?=
 =?utf-8?B?N1JIZ2xJaWZXK1ZJWGFKRWN3STRwQUI0QWJKOVNZQnB1amJZeDdKM3RxcnN1?=
 =?utf-8?B?MkFNdkQwRHVKM2RKaTlVOGtSYlkwRlZRZnVKbHhNM081MU90cDcxdFpmQ3NK?=
 =?utf-8?B?K29OcjU1NG9ST3ZBcWQvOGowMnFsbGJyc1VXaEppWWJiMHIxRm94NDk5WGtP?=
 =?utf-8?B?UlBPYVJIRjBRaHRBbkRuRVY4cHdCT09zZ1dCWGFqYzlpTm5nRFNNYlpTRmZS?=
 =?utf-8?B?NEhHQjkrQTJmUmsrSE1ndjA1NjExeVhhWkxGNnA5cFIxT1BMUUxlSlloSUZt?=
 =?utf-8?B?YVZXSnpNMGVWeC9xWFNUL2JWeFdYNGhRVHhwajJuTEJKVENrUGVvQzI2TjNR?=
 =?utf-8?B?YjBLOHJJckI4QmttNkszTmM1QkZJWTkxR2F0aExJbWVJb3FIZHdieDRCUkdy?=
 =?utf-8?B?bFNBVWlVNXh1VjEwVHVTMG0zL2EwOWNjT2ZaYW9Ga0k3MVErRVU2VGVGZEhP?=
 =?utf-8?B?ZE5vVWtLQVRwYjBvbzFMTzd1cnhlLzRBdjZQaVRWcTdZbVdVU3A5dEt5UFhL?=
 =?utf-8?B?VWhYNkgzSEVTWnRMT1o2MityTWp5MytmZ1o1V3RHQ0pCUng4V1dla25RNFJV?=
 =?utf-8?B?aDZoc2c2QVRWZSthNC9KcnNNVkUwd0o5eVNlbUJjdHMyTnJpRjNUeTdRbTll?=
 =?utf-8?B?V3gvdHQ0QUlXNlpvZExOR1YrbWNTcHEvUEZuelAxM1BMSTB4VnN1RSt4em94?=
 =?utf-8?B?UElMcWVIVVR3Zmt1NHVCU1NnMjNoaDdPU1RteG9sbC9QL212QXdrOXBsY3JG?=
 =?utf-8?B?a1JPUkZJZE4wVWIvNWMrOEx6dVQxV2J2Qm12bjMzZmlFY3YrZHJjNXpvVklY?=
 =?utf-8?B?NkZNVk1ROGtrSkxrV3AzZTZudWtKZTlSUDFjMStSRUNXdTl4d0ROMGNkRVhv?=
 =?utf-8?B?UXBLSVlJNFRRPT0=?=
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?MDAzWXU3d3lGK0xsTlZaQnRUTWlrbW9sdmVORXd4RmdJTlNOaEJnTVRIMDdF?=
 =?utf-8?B?YktwK3Y2ZjNSNFJTU2lERVhNMWJvdTRQM1BRM0hXci9TRmhHMFYyUVVUWTRE?=
 =?utf-8?B?L0JoUHZxdGhzVGhmc1QweHBmSnZTNEZoT2ZteTNUdUUySkZrcVBwYTh6eERH?=
 =?utf-8?B?d0xBWEVjcXhnQkttRUcweUlYS0E2UTlCTnBTV3lqWkw4dm9vNklOcERTOHJO?=
 =?utf-8?B?bjM4OE1ERkIyTmIzQlFrM25VS1NtZTYvb3Fucno2WENScTM2YllaaVZrZFhL?=
 =?utf-8?B?aUZsMU5hK21Kd3g0YUwyQnJXUzBaZDNHUEtrS2VPSzU1L0hqU2pwenZXVjVr?=
 =?utf-8?B?dld4d3dxVzJSdkZxVVM0bDBHK0J6R2hMZE5EZ2hhQzEzK2pVNlE2OEovc29Y?=
 =?utf-8?B?SEdFdkRaZ1BGa2h5YU5KSDdGKzdEZ2ZwcXNqeUpzRzE4cmhseWplQlJzb2Nl?=
 =?utf-8?B?bjl0ajErRC9YUFpGZW1nQ1pGaUZRQ09Vakc2UTIzbThHckJjNElES013MHFh?=
 =?utf-8?B?SitaV0xrWlZ0OVZ1UE0zeWxXWmlWbUEyWDk4VlpOZlp2d2piQkVNaGcxb1Rl?=
 =?utf-8?B?S1hKR3RQbUpNMTdyZ2hPd3BrV2txWEFLd2VaUXZ4bklXNVByWW16dFAveGFv?=
 =?utf-8?B?bngzV1JuQ1NUWXFsR285eDZSdlVmNXI2QnVpUUc2Zi95cmRRaDJ6U3hmT0lv?=
 =?utf-8?B?RFhvTFZyUS96eU02RUxMQS9yTzFKbEhSWlJmYVFteEk0U2I3YVJIZmw4aytY?=
 =?utf-8?B?a1M5akRvSWxpTzN6YVBmcGo2OGUvRDNTTXRMbS93bTVpNEdzdEwvR3pwN3Iy?=
 =?utf-8?B?MUR6ZFZkNFlWTnBseVN0N3Q4YjlzNU1PNVVZdzlvMUZVSGx3NGtIWFFLeDRC?=
 =?utf-8?B?T3d2bUtDb3hwVDFHVzAyVlowRVFoQ05hMVNUdWZmUGs5QWJKNWtNUGZaRVRx?=
 =?utf-8?B?M0RiMEVNcEU0VzB3aXdhY3ZJV0Y0MFg5dENuNXo5eFFQNG1COThmSEVkYVhn?=
 =?utf-8?B?SXAvUFhPeDNUcXR6UXROWFhEQTdabEJCWU1RQ1J0NlRJaWxoQWFxMDUrRjlL?=
 =?utf-8?B?RnlGOGdBM0M0S2VLenM1ZGdLc3l2Vy82Y1NkRUZoVUhwK0IzZDFiMTRvWUsv?=
 =?utf-8?B?N0RUVnVBdEFQdTE1T1R6SDZnSFFvK1FQZEw4UUFZcm1Pb3NlTldwdUttTGh0?=
 =?utf-8?B?QnFMcXBtRjhwbUpxcS94WG13RGQxQ3lTb3lsUDRVMSsxT2pNZ3JBNHhFa29n?=
 =?utf-8?B?dWpqTnllRVpENXRFVlhTVWhPdzNMbmphbTBJMXkxWjNQOXR4dlQ1V3FDbUtG?=
 =?utf-8?B?cHhHbmxmRytzcXk2QzUybUNwY1R3SWdGZWxjdDFJY0lITTVBb3VYalpsQTdP?=
 =?utf-8?B?Y1FtT25id0xZeTFYOUZJZWVIdCtoaWRDU0NzVFNVdUdkSDk3R1NOand2VVc4?=
 =?utf-8?B?bHF2bGMzMXNSYUE1elZtREpkK3NwWmtTUmtpTVRWakRSalJJT3czNE96Tm1q?=
 =?utf-8?B?TllsRTU1dXBJUDh5U0lJbW5HcmhoQkZoMUpqWUtobytJMzZiT1lzVyt3M212?=
 =?utf-8?B?eDNNTHZHYnFxWUpXQkovOERDaklHd0hWYkYzS2JxK3NvRStNZzdCTHMrcDRG?=
 =?utf-8?B?VzVXOXRyNlVFTXFWVFlPL25MYkNzTTZGeG9IY3VDQ0tYaGFpOThQLy9iYUZH?=
 =?utf-8?B?MzdkcXAwaU9pVjdHWG5WY2RPQnhBekt0czhPTUFab2FSSWliUjh3UGEyOXpL?=
 =?utf-8?B?TjRROE9zL2xmMnVYUEZRUjVPeWZZTThuN3ZlMWpaajBBMFltemQ0Z0U0ajdO?=
 =?utf-8?B?REpNcmYza29vRTlweFdFTHFNcTVkRjhMc1I2d05OL052SXM1eGJkb0dtZ0FO?=
 =?utf-8?B?MEpPNkVQUEtkby9xWHpxT0ptYmp6THFVNDdLU1RoRzVXK2ZSZGZqK3ppL2Y0?=
 =?utf-8?B?dnNBNEQ0TnZPVmJubjRFMXd5dUJLY0lUM3JmWFJZY1ZIYzUxRWxKdGVXNW1j?=
 =?utf-8?B?dEtZRDB2dnV5Ym5mQjVMdGNBY3RONTB3eFpBbG1ySHZWUlJLVWZsWkRqZzBI?=
 =?utf-8?B?TjBTeUE3Y09sekl0Nml0RDl4VjE0NjNabHRSc2ZXanpTUzl2UUtoVjlkVmNV?=
 =?utf-8?Q?USTU=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: 52994dad-bcaf-40f9-ccd1-08ddb5539ff0
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2025 08:21:32.6700
 (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: F5jmd/v0BgnzF0oMFWHp8A2/yfo1Db6SBLZHwJvtNDzQ1bT3J+QhOvyUrQ/e29c/F+Mbm9hbIW7ZDBkpSPd0xg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW6PR12MB9018

T24gMjAyNS82LzI3IDE2OjE2LCBDaGVuLCBKaXFpYW4gd3JvdGU6DQo+IE9uIDIwMjUvNi8yNyAx
NDowNSwgSmFuIEJldWxpY2ggd3JvdGU6DQo+PiBPbiAyNy4wNi4yMDI1IDA0OjU5LCBDaGVuLCBK
aXFpYW4gd3JvdGU6DQo+Pj4gT24gMjAyNS82LzI2IDIwOjA2LCBKYW4gQmV1bGljaCB3cm90ZToN
Cj4+Pj4gT24gMjYuMDYuMjAyNSAxMDowMywgQ2hlbiwgSmlxaWFuIHdyb3RlOg0KPj4+Pj4gT24g
MjAyNS82LzI1IDIyOjA3LCBKYW4gQmV1bGljaCB3cm90ZToNCj4+Pj4+PiBPbiAyNS4wNi4yMDI1
IDEyOjE2LCBDaGVuLCBKaXFpYW4gd3JvdGU6DQo+Pj4+Pj4+IE9uIDIwMjUvNi8yNSAxODowMywg
SmFuIEJldWxpY2ggd3JvdGU6DQo+Pj4+Pj4+PiBBbHNvLCBhcyBzYWlkIC0geW91IHdpbGwgbmVl
ZCB0byBjaGVjayB3aGV0aGVyIG90aGVyIGFyY2hpdGVjdHVyZXMgYXJlDQo+Pj4+Pj4+PiBkaWZm
ZXJlbnQgZnJvbSB4ODYtNjQgaW4gdGhpcyByZWdhcmQuIFdlIGJldHRlciB3b3VsZG4ndCBsZWF2
ZSBhIHRyYXAgaGVyZSwNCj4+Pj4+Pj4+IGZvciB0aGVtIHRvIGZhbGwgaW50byB3aGVuIHRoZXkg
ZW5hYmxlIHZQQ0kgc3VwcG9ydC4gSS5lLiBteSByZWNvbW1lbmRhdGlvbg0KPj4+Pj4+Pj4gd291
bGQgYmUgdGhhdCBpZiBpbiBkb3VidCwgd2UgcHV0IHRoZSBfX2FsaWduZWQoKSB0aGVyZSB1bmNv
bmRpdGlvbmFsbHkuDQo+Pj4+DQo+Pj4+IE5vdGUgaG93IEkgdXNlZCBfX2FsaWduZWQoKSBoZXJl
LiBXaHkgd291bGQgeW91IC4uLg0KPj4+Pg0KPj4+Pj4+PiBUaGF0J3MgZGlmZmljdWx0IGZvciBt
ZSB0byBjaGVjayBvbiBhbGwgZGlmZmVyZW50IHBsYXRmb3JtcyBzaW5jZSBJIGRvbid0IGhhdmUg
dGhlbSBhbGwuDQo+Pj4+Pj4NCj4+Pj4+PiBZb3UgZG9uJ3QgbmVlZCB0byBoYXZlIHRoZW0uIFlv
dSdkIG5lZWQgdG8gY2FyZWZ1bGx5IGdvIHRocm91Z2ggdGhlIHJlc3BlY3RpdmUNCj4+Pj4+PiBz
ZWN0aW9uKHMpIG9mIHRoZWlyIHBzQUJJLXMuDQo+Pj4+Pj4NCj4+Pj4+Pj4gU28geW91IG1lYW4g
SSBzaG91bGQgcmVtb3ZlICIjaWZkZWYgQ09ORklHX1g4NiI/IEp1c3QgbGV0IF9fYWxpZ25lZCgx
NikgZm9yIGFsbCBwbGF0Zm9ybXM/DQo+Pj4+Pj4NCj4+Pj4+PiBZZXMuIEFuZCwgYXMgYWxzbyBz
YWlkLCB3aXRoIGEgc3VpdGFibGUgY29tbWVudCBwbGVhc2UuDQo+Pj4+PiBBaCwgbXkgY29tbWVu
dCBkZWZpbml0ZWx5IG5lZWRzIHlvdXIgY2hhbmdlIHN1Z2dlc3Rpb24uDQo+Pj4+PiBJIHdyb3Rl
IGEgZHJhZnQgYXMgYmVsb3c6DQo+Pj4+Pg0KPj4+Pj4gLyoNCj4+Pj4+ICAqIFNpemUgb2YgdnBj
aV9jYXBhYmlsaXR5IGlzIGxhZ2VyIHRoYW4gOCBieXRlcy4gV2hlbiBpdCBpcyB1c2VkIGFzIHRo
ZSBlbnRyeQ0KPj4+Pj4gICogb2YgX19zdGFydF92cGNpX2FycmF5IGluIHNlY3Rpb24sIGl0IGlz
IDE2LWJ5dGUgYWxpZ25lZCBieSBhc3NlbWJsZXIsIHRoYXQNCj4+Pj4+ICAqIGNhdXNlcyB0aGUg
YXJyYXkgbGVuZ3RoIChfX2VuZF92cGNpX2FycmF5IC0gX19zdGFydF92cGNpX2FycmF5KSB3cm9u
Zywgc28NCj4+Pj4+ICAqIGZvcmNlIGl0cyBkZWZpbml0aW9uIHRvIHVzZSAxNi1ieXRlIGFsaWdu
ZWQgaGVyZS4NCj4+Pj4+ICAqLw0KPj4+Pj4gc3RydWN0IHZwY2lfY2FwYWJpbGl0eSB7DQo+Pj4+
PiAgICAgdW5zaWduZWQgaW50IGlkOw0KPj4+Pj4gICAgIGJvb2wgaXNfZXh0Ow0KPj4+Pj4gICAg
IGludCAoKiBpbml0KShjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldik7DQo+Pj4+PiAgICAgaW50
ICgqIGNsZWFudXApKGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZGV2KTsNCj4+Pj4+IH0gX19hdHRy
aWJ1dGVfXygoYWxpZ25lZCgxNikpKTsNCj4+Pj4NCj4+Pj4gLi4uIG9wZW4tY29kZSB0aGF0IGhl
cmU/DQo+Pj4gVGhhdCBiZWNhdXNlIHdoZW4gdXNpbmcgX19hbGlnbmVkKCkgd2l0aG91dCBDT05G
SUdfWDg2LCBJIGdvdCBjb21waWxlIGVycm9yDQo+Pj4gdnBjaS5oOjE4OjEzOiBlcnJvcjogZXhw
ZWN0ZWQgZGVjbGFyYXRpb24gc3BlY2lmaWVycyBvciDigJguLi7igJkgYmVmb3JlIG51bWVyaWMg
Y29uc3RhbnQNCj4+PiAgICAxOCB8IH0gX19hbGlnbmVkKDE2KTsNCj4+PiAgICAgICB8ICAgICAg
ICAgICAgIF5+DQo+Pj4gSSB0cmllZCBzb21lIG1ldGhvZHMsIG9ubHkgb3Blbi1jb2RlIGNhbiBm
aXggaXQuDQo+Pg0KPj4gV2VsbCwgdGhhdCdzIG9kZC4gSW4gZS5nLiB4ZW4vc2NoZWQuaCB3ZSBo
YXZlDQo+IFllcywgSSBzZWUuDQo+IFRoYXQncyBzbyBzdHJhbmdlLg0KPiBFdmVuIEkgZG8gYmVs
b3cgYWxzbyBnZXQgdGhlIGVycm9yIG1lc3NhZ2UuIEJ1dCBpZiBvcGVuLWNvZGUsIGl0IHdvcmtz
Lg0KPiANCj4gZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3hlbi92cGNpLmggYi94ZW4vaW5jbHVk
ZS94ZW4vdnBjaS5oDQo+IGluZGV4IDUxNTczYmFhYmMuLjM1MGViNWYyODkgMTAwNjQ0DQo+IC0t
LSBhL3hlbi9pbmNsdWRlL3hlbi92cGNpLmgNCj4gKysrIGIveGVuL2luY2x1ZGUveGVuL3ZwY2ku
aA0KPiBAQCAtMTMsMTIgKzEzLDE3IEBAIHR5cGVkZWYgdWludDMyX3QgdnBjaV9yZWFkX3QoY29u
c3Qgc3RydWN0IHBjaV9kZXYgKnBkZXYsIHVuc2lnbmVkIGludCByZWcsDQo+ICB0eXBlZGVmIHZv
aWQgdnBjaV93cml0ZV90KGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZGV2LCB1bnNpZ25lZCBpbnQg
cmVnLA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCB2YWwsIHZvaWQgKmRh
dGEpOw0KPiANCj4gKyNpZmRlZiBfX2FsaWduZWQNCj4gKyN1bmRlZiBfX2FsaWduZWQNCj4gKyNk
ZWZpbmUgX19hbGlnbmVkKGEpIF9fYXR0cmlidXRlX18oKF9fYWxpZ25lZF9fKGEpKSkNCj4gKyNl
bmRpZg0KU29ycnksIHRoaXMgc2hvdWxkIGJlIHVuZGVyIHRoZSBlbmQgb2YgdGhlIHN0cnVjdCwg
dGhlbiBpdCB3b3Jrcy4NCkl0IHNlZW1zIF9fYWxpZ25lZCBpcyBvdmVyLXdyaXRlPw0KDQo+ICsN
Cj4gIHN0cnVjdCB2cGNpX2NhcGFiaWxpdHkgew0KPiAgICAgIHVuc2lnbmVkIGludCBpZDsNCj4g
ICAgICBib29sIGlzX2V4dDsNCj4gICAgICBpbnQgKCogY29uc3QgaW5pdCkoc3RydWN0IHBjaV9k
ZXYgKnBkZXYpOw0KPiAgICAgIGludCAoKiBjb25zdCBjbGVhbnVwKShzdHJ1Y3QgcGNpX2RldiAq
cGRldik7DQo+IH0gX19hbGlnbmVkKDE2KTsNCj4gDQo+IA0KPiBBbnl3YXksIEkgd2lsbCB3YWl0
IGZvciB5b3VyIHBhdGNoIG1lcmdlZC4NCj4gDQo+Pg0KPj4gc3RydWN0IGRvbWFpbg0KPj4gew0K
Pj4gICAgIC4uLg0KPj4gfSBfX2FsaWduZWQoUEFHRV9TSVpFKTsNCj4+DQo+PiB3aGljaCBjbGVh
cmx5IG11c3QgYmUgd29ya2luZyBmaW5lLiBUaGUgZXJyb3IgbWVzc2FnZSBmcm9tIHRoZSBjb21w
aWxlcg0KPj4gZG9lc24ndCBzYXkgdmVyeSBtdWNoIGFsb25lLiBGb3IgaW5mb3JtYXRpb25hbCBk
aWFnbm9zdGljcyB0aGUgY29tcGlsZXINCj4+IG5vcm1hbGx5IGFsc28gZW1pdHMgbWF5IGhlbHAs
IG9yIGVsc2UgaXQgd291bGQgdGFrZSBsb29raW5nIGF0IHRoZQ0KPj4gcHJlLXByb2Nlc3NlZCBv
dXRwdXQgdG8gdW5kZXJzdGFuZCB3aGF0J3MgZ29pbmcgb24gaGVyZS4NCj4+DQo+Pj4+IEFzIHRv
IHRoZSBjb21tZW50OiBGaXJzdCwgaXQgd2FudHMgdG8gYmUgYXMgY2xvc2UgdG8gd2hhdCBpcyBi
ZWluZyBjb21tZW50ZWQgYXMNCj4+Pj4gcG9zc2libGUuIEhlbmNlDQo+Pj4+DQo+Pj4+IHN0cnVj
dCBfX2FsaWduZWQoMTYpIHZwY2lfY2FwYWJpbGl0eSB7DQo+Pj4gVGhpcyBhbHNvIGdvdCB0aGUg
Y29tcGlsZSBlcnJvci4NCj4+Pj4NCj4+Pj4gaXMgbGlrZWx5IHRoZSBiZXR0ZXIgcGxhY2VtZW50
LiBTZWNvbmQsIHRoZXJlJ3Mgbm90aGluZyBoZXJlIHRoZSBhc3NlbWJsZXIgZG9lcw0KPj4+PiBv
biBpdHMgb3duLiBJdCdzIHRoZSBjb21waWxlciB3aGljaCBkb2VzIHNvbWV0aGluZyAoaW5zZXJ0
IGFsaWdubWVudCBkaXJlY3RpdmVzKSwNCj4+Pj4gYW5kIG9ubHkgdG8gZm9sbG93IGNlcnRhaW4g
cnVsZXMuIChTZWUgIng4NjogZG9uJ3QgaGF2ZSBnY2Mgb3Zlci1hbGlnbiBkYXRhIg0KPj4+PiB0
aGF0IEkgQ2MtZWQgeW91IG9uIGZvciBzb21lIG9mIHRoZSByZWxldmFudCBhc3BlY3RzLikgVGhh
dCBpcywgeW91IGRvbid0IHdhbnQNCj4+Pj4gdG8gImJsYW1lIiBhbnkgcGFydCBvZiB0aGUgdG9v
bCBjaGFpbiwgYXQgbGVhc3Qgbm90IHdoZXJlIGl0J3MgdGhlIHVuZGVybHlpbmcNCj4+Pj4gQUJJ
IHRoYXQgbWFuZGF0ZXMgY2VydGFpbiBiZWhhdmlvci4gVGhlcmUncyBhbHNvIG5vIHN0cm9uZyBu
ZWVkIHRvIHRhbGsgYWJvdXQNCj4+Pj4gdGhlIHNwZWNpZmljIGVmZmVjdHMgdGhhdCBpdCB3b3Vs
ZCBoYXZlIGlmIHdlIGRpZG4ndCBhcnJhbmdlIHRoaW5ncyBwcm9wZXJseS4NCj4+Pj4gVGhhdCBp
cywgdGFsa2luZyBhYm91dCB0aGUgZWZmZWN0IG9uIGFycmF5cyBpbiBnZW5lcmFsIGlzIGZpbmUg
YW5kIGhlbHBmdWwuDQo+Pj4+IFRhbGtpbmcgYWJvdXQgX197c3RhcnQsZW5kfV92cGNpX2FycmF5
IGltbyBpcyBub3QuDQo+Pj4+DQo+Pj4+IFdoaWxlIGZ1cnRoZXIgcGxheWluZyB3aXRoIHRoZSBj
b21waWxlciwgSSBub3RpY2VkIHRoYXQgYWRkaW5nIF9fYWxpZ25lZCgxNikNCj4+Pj4gYWN0dWFs
bHkgaGFzIGEgbmVnYXRpdmUgZWZmZWN0IGFzIGxvbmcgYXMgdGhhdCBvdGhlciBwYXRjaCBpc24n
dCBpbiB1c2U6IFRoZQ0KPj4+PiBzdHJ1Y3QgaW5zdGFuY2VzIHRoZW4gYXJlIGJlaW5nIGFsaWdu
ZWQgdG8gZXZlbiAzMi1ieXRlIGJvdW5kYXJpZXMgKHdoaWNoIG1lYW5zDQo+Pj4+IF9fc3RhcnRf
dnBjaV9hcnJheSB3b3VsZCB0aGVuIGFsc28gbmVlZCBhbGlnbmluZyBhcyBtdWNoKS4gV2hlbiB0
aGF0IG90aGVyDQo+Pj4+IHBhdGNoIGlzIGluIHVzZSwgdGhlIF9fYWxpZ25lZCgpIGJlY29tZXMg
dW5uZWNlc3NhcnkuIFRoZXJlZm9yZSBJJ20gbm8gbG9uZ2VyDQo+Pj4+IGNvbnZpbmNlZCB1c2lu
ZyBfX2FsaWduZWQoKSBpcyB0aGUgYmVzdCBzb2x1dGlvbiBoZXJlLg0KPj4+IEVtLCBjaGFuZ2lu
ZyBfX3N0YXJ0X3ZwY2lfYXJyYXkgdG8gYmUgc3RydWN0IHZwY2lfY2FwYWJpbGl0eSBhcnJheSBj
YXVzZSB0aG9zZSBjb25jZXJucywgbWF5YmUga2VlcGluZyB1c2luZyBzdHJ1Y3QgcG9pbnRlciBp
cyBhIGNvbXByb21pc2UgbWV0aG9kLg0KPj4NCj4+IEl0IHdvdWxkIGJlIGEgbGFzdCByZXNvcnQs
IHllcywgYnV0IGltbyAoYSkgd2Ugb3VnaHQgdG8gc3RyaXZlIHRvIGF2b2lkDQo+PiB1bm5lY2Vz
c2FyeSBpbmRpcmVjdGlvbiBhbmQgKGIpIHRoZSBzYW1lIHVuZGVybHlpbmcgaXNzdWUgY291bGQg
YmVjb21lIGENCj4+IHByb2JsZW0gZWxzZXdoZXJlIGFzIHdlbGwuDQo+Pg0KPj4gSmFuDQo+IA0K
DQotLSANCkJlc3QgcmVnYXJkcywNCkppcWlhbiBDaGVuLg0K


From xen-devel-bounces@lists.xenproject.org Fri Jun 27 08:33:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 08:33:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027396.1402043 (Exim 4.92)
	(envelope-from )
	id 1uV4We-00080e-9M; Fri, 27 Jun 2025 08:33:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027396.1402043; Fri, 27 Jun 2025 08: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 1uV4We-00080X-5Z; Fri, 27 Jun 2025 08:33:36 +0000
Received: by outflank-mailman (input) for mailman id 1027396;
 Fri, 27 Jun 2025 08:33:34 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uV4Wc-00080R-LP
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 08:33:34 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uV4Wb-005DVi-1b;
 Fri, 27 Jun 2025 08:33:33 +0000
Received: from amontsouris-682-1-55-1.w90-87.abo.wanadoo.fr ([90.87.218.1]
 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 1uV4Wb-00BV3E-0j;
 Fri, 27 Jun 2025 08:33: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=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date;
	bh=uvB4j7qz4b7wodmHc7TWsWGSTc87d31RWz/TX52sAxk=; b=Xzt9dVcClovgvvH00CC4YTur20
	oadjOd74o+V9UK1dB+P/Vkkeoa5SqkBP9E8eJU3lutL+tWJuwYUilsISwfZvRYSHGN5YA4FRJS32Q
	WQ0Xnfaqu131UMiZlKtsfp+FoeJgb84X2mb8pUZAdU2TVUJ95rj36exAVXcUEUyxuDLY=;
Date: Fri, 27 Jun 2025 10:33:31 +0200
From: Anthony PERARD 
To: Jason Andryuk 
Cc: Juergen Gross , xen-devel@lists.xenproject.org
Subject: Re: [PATCH] tools/libxenguest: fix build in stubdom environment
Message-ID: 
References: <20250625103306.4599-1-jgross@suse.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 

On Wed, Jun 25, 2025 at 09:20:05AM -0400, Jason Andryuk wrote:
> On 2025-06-25 06:33, Juergen Gross wrote:
> > With introduction of the new byteswap infrastructure the build of
> > libxenguest for stubdoms was broken. Fix that again.
> > 
> > Fixes: 60dcff871e34 ("xen/decompressors: Remove use of *_to_cpup() helpers")
> > Signed-off-by: Juergen Gross 
> 
> Reviewed-by: Jason Andryuk 

Acked-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Fri Jun 27 08:39:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 08:39:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027401.1402052 (Exim 4.92)
	(envelope-from )
	id 1uV4cH-0000Aa-St; Fri, 27 Jun 2025 08:39:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027401.1402052; Fri, 27 Jun 2025 08:39: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 1uV4cH-0000AS-PK; Fri, 27 Jun 2025 08:39:25 +0000
Received: by outflank-mailman (input) for mailman id 1027401;
 Fri, 27 Jun 2025 08:39: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 1uV4cF-00009M-Op
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 08:39:24 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 38fadd11-5332-11f0-a30f-13f23c93f187;
 Fri, 27 Jun 2025 10:39:22 +0200 (CEST)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 (Authenticated sender: nicola)
 by support.bugseng.com (Postfix) with ESMTPA id 175704EE3C07;
 Fri, 27 Jun 2025 10:39:21 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 38fadd11-5332-11f0-a30f-13f23c93f187
Authentication-Results: bugseng.com; arc=none smtp.remote-ip=162.55.131.47
ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1751013561;
	b=TuTuTQiAKK2LL9sUUZoH9ZYakF7jB8jvyNtOIqYIYH03YfOq1uRwVmzsEnyGJWOofC07
	 8mYhklFbj875pb7+wE9kEDL29RoaZB9Yay+h/I1d3cYBsOwP6F3IqA1QnsxYLD9iDY/cz
	 48FP0v7bU6yFBDGEXOXC+nt1yvoKaKz2V2w8A7NqZfaTMNO8gvgYNeb0l4m0NhavDuENi
	 ZkZQZ5YeUZ3OHKKjbGz8SCZ8UDzZb6GDFY6Y3jGb7JmmjYWps6e+hHY/IjO6NBaNMcjBl
	 FCk25udUaJUcq/f+ZE9SLmlmSEqDQyMYydq3TML4aufw21u+zMRhyb8QVv7iuC42qu02L
	 +zhUp1IgQ584dGbEDy1aOLutTMQpFg1nofX4d+kigMjoYrkmm2mpUoSRxRwTdYqpucEq2
	 SEkM+OGUjrq9dSQOCY3zgCzlNK33LxRqaFfDV+nzzF53sLyB98fhVj5P8KJLlCxynICZ3
	 VSPS1IZnpkI3rfZNLwIWw80BQJc9nWmGWDaP+MPMp+HeEat0m0wnABFgLVltCUT6lWDeD
	 0jVdn3XUckRM+q0SWNKShVWerZqoFk8Shv2BFj51GaLWtCUCJgIhAgQs0Gh8MEGLo1els
	 Oad/lq/HC+2y/1fwpceDP8LNtvWLtAqV+vh9nXngqkqrDU0sraQuScOBmXAfjbc=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1751013561;
	h=DKIM-Signature:MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:
	 References:Message-ID:X-Sender:Organization:Content-Type:
	 Content-Transfer-Encoding;
	bh=wI/0k16mVXhg3mrG82T4Bp6Quxy12TNzePQpSccXxJY=;
	b=HqbaE4yJ2yLzveKfNqgeHOPtOUsaFmuYnqwtFxnzFqTNwG6lfJ0QRs4K55+V2au6U/k7
	 dTi9QaciVspxgeMBTpzTKINxwuvAdUxcVlKX1yN9u6S4DFGZc5euSBV1ai8IQYDN1jIyb
	 xaZOZJBN6j+Yow2XTZeGIkKBi76VgRQkxRWnf2gOHWvgulwgPiCz8IGs08/xVbZQo0EUj
	 bh6CEMkBA1DpaBs/Qz/lq9F/DP0+Cxz3KPtUMsuozd4GHPdgbVjv7aV0OqEeigyNbriqt
	 9RQm1u+3wrJeAn2RrJ0Jm4kD3gCt2BMxsUTvOLHG64PetEf8gMhxsHIvk37hs84sbtYpU
	 5e6uyZu2fKOTVbrzS6N6EXU0yq6RNxmVV+3umFNr5/NDpPMieEeiIEOq9DjuyFPYitejH
	 vRf3H00eQibfMOa5yUBHRA0GDerU9V1frnbwPYjff5CaG/2PmbRXlabM+ojn/uBZTFxGL
	 y4UVa4MGIVHO1xDbUuXll+pf79nY/vw0Bj0xwFtXw69uaVPpnbsqJrORYrduj9iM+0xCV
	 D6+p4j1C+GaD/BYzWtmAsbhT2AlsP6sGr7u0k6Xy4xQ21phWwC8ngDsRmjayVR2V/W3xp
	 m3zLmwQLcngL/yofzbc58/IxnUsj0IRPpTnbOz5kO41tuhPorSz4we4ihjnwVdw=
ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1751013561; bh=/+ZA6Es0JY2E3mj8mglZfQJ4zTTUDTFC0RoEe4l4Lrw=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=WiiC6Hb7zeo5MZrMQlWF5rAbUF5DzD1BaWQ/05s+G/JgwUoedj58P7ehMsg1oAFbB
	 O/HpIpNwWZvKBmmQrsf9b5qnJ3bCeopaGck0KTuFvlRL0l0Rvee0E97L5s5dfBolyr
	 2EQLHp/D/3BbrxX5FtAnyfA9KqpR0SdPnqiyP81z+EJ9Vv5wpF/GqKQhTZot5BEGBn
	 WKJwTGhREOUAIFyyQzX7sniy8o/jnb3ALZ7J7heycZtd1at/PDvotbGVKHc1k6yK8k
	 oFiSxZlKAs24pQZ9q3XUzaVq4j3/2MnmNQfAyDGyaYfDCDPYrJ/TS3JePQuKSy7Ft8
	 DKRm7bCRD1ovw==
MIME-Version: 1.0
Date: Fri, 27 Jun 2025 10:39:21 +0200
From: Nicola Vetrini 
To: Anthony PERARD 
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, Doug Goldstein , Alessandro
 Zucchelli 
Subject: Re: [XEN PATCH] automation/eclair: Make report browsing URL
 configurable.
In-Reply-To: 
References: <2c0003504925e6f62b0bb1a13711c206e40f9393.1750919773.git.nicola.vetrini@bugseng.com>
 
Message-ID: <194c24271abdadf062cab1b0f80a6fdc@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 2025-06-26 12:08, Anthony PERARD wrote:
> On Thu, Jun 26, 2025 at 08:38:18AM +0200, Nicola Vetrini wrote:
>> diff --git a/automation/eclair_analysis/ECLAIR/action.settings 
>> b/automation/eclair_analysis/ECLAIR/action.settings
>> index 1577368b613b..f822f0ea66d7 100644
>> --- a/automation/eclair_analysis/ECLAIR/action.settings
>> +++ b/automation/eclair_analysis/ECLAIR/action.settings
>> @@ -14,9 +14,6 @@ autoPRRepository="${AUTO_PR_REPOSITORY:-}"
>>  # Customized
>>  autoPRBranch="${AUTO_PR_BRANCH:-}"
>> 
>> -# Customized
>> -artifactsRoot=/var/local/eclair
>> -
>>  case "${ci}" in
>>  github)
>>      # To be customized
>> @@ -166,12 +163,34 @@ esac
>> 
>>  ECLAIR_BIN_DIR=/opt/bugseng/eclair/bin/
>> 
>> -artifactsDir="${artifactsRoot}/xen-project.ecdf/${repository}/ECLAIR_${ANALYSIS_KIND}"
>> +# Artifacts URL served by the eclair_report server
>> +if [ -z "${MACHINE_ARTIFACTS_ROOT}" ];
> 
> You don't need a ';' if you have `then` on the next line ;-)
> 
Hi Anthony,

yeah, missed that. Thanks

>> +then
>> +  echo "WARNING: No artifacts root supplied, using default"
>> +fi
>> +if [ -z "${MACHINE_ECDF_DIR}" ];
>> +then
>> +  echo "WARNING: No ecdf dir supplied, using default"
>> +fi
>> +artifactsRoot="${MACHINE_ARTIFACTS_ROOT:-/var/local/eclair}"
>> +artifactsEcdfDir="${MACHINE_ECDF_DIR:-xen-project.ecdf}"
> 
> Do we need to separate varables for these two? It might be a bit 
> simpler
> to have:
>     artifactsRoot=/var/local/eclair/xen-project.ecdf
> unless there's other path than *.ecdf. But in any case, two separate
> variables looks fine too.
> 

The main reason why I used two variables is that one may have 
differently-named .ecdf directories on different machines, but there is 
no strong reason have two variables

>> +artifactsDir="${artifactsRoot}/${artifactsEcdfDir}/${repository}/ECLAIR_${ANALYSIS_KIND}"
>>  subDir="${subDir}${variantSubDir}"
>>  jobHeadline="${jobHeadline}${variantHeadline}"
>> 
>> -# Customized
>> -eclairReportUrlPrefix=https://saas.eclairit.com:3787
>> +# Remote eclair_report hosting server
>> +if [ -z "${MACHINE_HOST}" ];
>> +then
>> +  echo "WARNING: No machine host supplied, using default"
>> +fi
>> +if [ -z "${MACHINE_PORT}" ];
>> +then
>> +  echo "WARNING: No machine port supplied, using default"
>> +fi
>> +
>> +eclairReportHost="${MACHINE_HOST:-saas.eclairit.com}"
>> +eclairReportPort="${MACHINE_PORT:-3787}"
>> +eclairReportUrlPrefix="https://${eclairReportHost}:${eclairReportPort}"
> 
> Please, don't make the port number mandatory. Can you merge both host
> and port in the same variable? This part seems to be called 
> "authority":
> 
>     https://en.wikipedia.org/wiki/URL#Syntax
> 
> Also, don't use `MACHINE` as prefix/namespace for these new variables,
> in a pipeline context, "machine" could be many things. Maybe
> "ECLAIR_REPORT_HOST" for this one? With the default been:
> 
>     ECLAIR_REPORT_HOST=saas.eclairit.com:3787
> 

I can merge host and port and change the variable prefix, but I think 
there is a misunderstanding. This address is used both as the base for 
report browsing and pushing the results. While we should alter the 
latter (e.g., ECLAIR_REPORT_PROXY_HOST) to point to the proxy so that 
the proxy is shown in the CI logs, the address where the results are 
pushed is fixed and set in the docker runner env. This is not ideal, but 
I didn't find a better way with GitLab CI to let the analysis push 
locally.

> I wonder if "https" should be configurable as well, but I guess there
> shouldn't be any need for it as we probably don't want to serve reports
> over http.
> 

Yeah, I don't think so

>> 
>>  jobDir="${artifactsDir}/${subDir}/${jobId}"
>>  updateLog="${analysisOutputDir}/update.log"
>> diff --git a/automation/eclair_analysis/ECLAIR/action_push.sh 
>> b/automation/eclair_analysis/ECLAIR/action_push.sh
>> index 45215fbf005b..5002b48522e2 100755
>> --- a/automation/eclair_analysis/ECLAIR/action_push.sh
>> +++ b/automation/eclair_analysis/ECLAIR/action_push.sh
>> @@ -1,6 +1,6 @@
>>  #!/bin/sh
>> 
>> -set -eu
>> +set -eux
> 
> Left over change from debugging?
> 

Yes

>> 
>>  usage() {
>>      echo "Usage: $0 WTOKEN ANALYSIS_OUTPUT_DIR" >&2
>> diff --git a/automation/gitlab-ci/analyze.yaml 
>> b/automation/gitlab-ci/analyze.yaml
>> index 5b00b9f25ca6..f027c6bc90b1 100644
>> --- a/automation/gitlab-ci/analyze.yaml
>> +++ b/automation/gitlab-ci/analyze.yaml
>> @@ -8,6 +8,8 @@
>>      ENABLE_ECLAIR_BOT: "n"
>>      AUTO_PR_BRANCH: "staging"
>>      AUTO_PR_REPOSITORY: "xen-project/xen"
>> +    MACHINE_ARTIFACTS_ROOT: "/space"
>> +    MACHINE_ECDF_DIR: "XEN.ecdf"
> 
> Is this the right place for these variables? Shouldn't they be set on
> gitlab (at project or repo scope) or even set by the runner itself.
> 

Well, it was easier to set them there for debugging. The idea was to 
potentially override them at the runner config level, if needed.

>>    script:
>>      - ./automation/scripts/eclair 2>&1 | tee "${LOGFILE}"
>>    artifacts:
>> diff --git a/automation/scripts/eclair b/automation/scripts/eclair
>> index 0a2353c20a92..7020eaa0982f 100755
>> --- a/automation/scripts/eclair
>> +++ b/automation/scripts/eclair
>> @@ -1,4 +1,15 @@
>> -#!/bin/sh -eu
>> +#!/bin/sh -eux
>> +
>> +# Runner-specific variables
>> +ex=0
>> +export "$(env | grep MACHINE_ARTIFACTS_ROOT)" || ex=$?
>> +[ "${ex}" = 0 ] || exit "${ex}"
> 
> That's a really complicated way to check a variable is set...
> Exporting a variable that's already in env isn't useful, and I think
> `ex` is only ever set to `0`. It seems that `dash` just exit if you do
> `export=""`.
> 
> You could simply do:
> 
>     : ${MACHINE_ARTIFACTS_ROOT:?Missing MACHINE_ARTIFACTS_ROOT 
> variable}
>     : ${MACHINE_ECDF_DIR:?Missing MACHINE_ECDF_DIR variable}
> 
> To check that the variables are set. Or nothing, if you add `set -u` to
> the script (instead of the one -u in the sheband which might be ignored
> if one run `sh ./eclair` instead of just `./eclair`.) Also the variable
> should come from the env, as nothing sets it, so no need to for that.
> 
> ( The `:` at the begining of the line is necessary, and behave the same
> way as `true` does. We need it because ${parm:?msg} is expanded.)
> 
> Or you could use `if [ -z "${param}" ]` if ${param:?msg} is too 
> obscure.
> We would just have "parameter not set" instead of a nicer message, due
> to `set -u`.
> 

I agree it is ugly and counterintuitive, but the core idea here is that 
the variable is set but not exported for some reason, so just `export 
VAR` does not behave in the same way as the incantation `export "$(env | 
grep MACHINE_ARTIFACTS_ROOT)"` iirc. I'll double check if there's a 
better way to achieve this (other than switching to bash in the 
shebang).

Thanks,

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253


From xen-devel-bounces@lists.xenproject.org Fri Jun 27 08:43:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 08:43:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027411.1402062 (Exim 4.92)
	(envelope-from )
	id 1uV4gX-0001p7-I3; Fri, 27 Jun 2025 08:43:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027411.1402062; Fri, 27 Jun 2025 08:43:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uV4gX-0001p0-Du; Fri, 27 Jun 2025 08:43:49 +0000
Received: by outflank-mailman (input) for mailman id 1027411;
 Fri, 27 Jun 2025 08:43: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 1uV4gW-0001ou-Co
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 08:43:48 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on2060f.outbound.protection.outlook.com
 [2a01:111:f403:2009::60f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d6e9f951-5332-11f0-a30f-13f23c93f187;
 Fri, 27 Jun 2025 10:43:46 +0200 (CEST)
Received: from SA0PR11CA0074.namprd11.prod.outlook.com (2603:10b6:806:d2::19)
 by SN7PR12MB7131.namprd12.prod.outlook.com (2603:10b6:806:2a3::9)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.19; Fri, 27 Jun
 2025 08:43:40 +0000
Received: from SA2PEPF00003AE9.namprd02.prod.outlook.com
 (2603:10b6:806:d2:cafe::d1) by SA0PR11CA0074.outlook.office365.com
 (2603:10b6:806:d2::19) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8880.21 via Frontend Transport; Fri,
 27 Jun 2025 08:43:40 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SA2PEPF00003AE9.mail.protection.outlook.com (10.167.248.9) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8880.14 via Frontend Transport; Fri, 27 Jun 2025 08:43:40 +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, 27 Jun
 2025 03:43:37 -0500
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, 27 Jun 2025 03:43:36 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d6e9f951-5332-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=hU2b6NNXLcwKbaDHf/jdMFm/MjGzQ49yQNJ8oDILkIqee8ZwmXUUf4Fr0I5OqWX1Ma31lII8mIf7XnyLwyfIpJy5TBS+nkgl5nbFJ0yt8aKzmtBl6uiD1NHh/RPWBOsKVbje3icf8g0yBmMA9+iQXwbKrYnId4BOrvk1Yj0rbIw+C5Zjl+DmDMujQeMfN1vjWEom3tQVEvgmazWQqUB0cNCdl0eT4z1mXwtTdxuT/dd4leK1Jvazlc9hFlOB9FrfFbOuGazCsjWcVrbNuG81j2ZrZyngch+1MgnRmACtgeRthQ+FvYMxT7XrL7JcyOcnXZyHOeXDJhF4K/oRYHOaQA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=HvzwjcgI+OoKbZkotdZvDHqSs82Pxp1+1cTFe6ddl2E=;
 b=D7SHMn6WF5bnZFlx4RzzFM7NV2ZOT7+vCIZvM723rqJ8UvVUuyd7rsqFuebWDdytO4FciSXgDrAvBiv+o4ocBHCzlbI72eXrASjm3h5P4ikqoIhZsc09B7daci9Zn5J6HiFX8eYlm2iWPBheACW6oSircYgyXfYUFIbOG2uW/hReJmY+7zSK970oSe81ojYZmmBoiU32fXGpGF8gzDoe9j96jQ6UobVVixGD2Zi5ZmgBm80XueQlqX2NKbUZFXnBAMpdCjjswdy0h5ERyF6I78zSzkxKwNAAYXKo4dwwtqevdi4tUExXRrYKpdedD6Oli4OVf+/HK79B1M/RPp15GQ==
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=HvzwjcgI+OoKbZkotdZvDHqSs82Pxp1+1cTFe6ddl2E=;
 b=ak+FnKhGNsJHE6Ik4yfnRXPecCAvFNG6lZf+dI+sSDpQYDoZeYneRguTgvEHuIl3WLlhTtZ+GvJHbHYfgQA/9UPX0MrpUAcLsjB39dAfw9m76n3qGgVWTR+jLY2oj7H6prG4qNdjsuVC+N+GmPKCe2Cq5qqrrqZHFefdl3Wbdp4=
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] xen/arm: Drop frametable_virt_end
Date: Fri, 27 Jun 2025 10:43:34 +0200
Message-ID: <20250627084334.45172-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: SA2PEPF00003AE9:EE_|SN7PR12MB7131:EE_
X-MS-Office365-Filtering-Correlation-Id: 7dcd90b8-b454-4b54-d2f7-08ddb556b74c
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?kO3wakRhwOojEnXAdMNdegWRAZmtIzjy2schbZrbkmXwqJfcEcIlKKTZb32y?=
 =?us-ascii?Q?j94GwOycapLPIZDvZaybH3H0fxLN3p2ryFzNWZVYwBsabPYE/EzHuepmKkOu?=
 =?us-ascii?Q?qWrbOUgRl6vWsp6FeQyZwArtM4MYZFu5pG+iGP6uWh4X6grWgd/WgFIYVZcF?=
 =?us-ascii?Q?ME5r/sPh0G78B81kHRa3p4OfpDYZaaC/emGJKjoThlTl9dXF8akGfHN+qiX4?=
 =?us-ascii?Q?I7qyu+Qb6krJrw8hA2ss/q9YBmroGoKD040tncuEaW8qEO/kBMPDI2zxsC3p?=
 =?us-ascii?Q?9AiPuHP++HrEFgJganV5IqCRgOpzl/qAWL37BDFzPuAXxb9phzguxQDXz3yT?=
 =?us-ascii?Q?+efaZbJoFSY9QSA9mHh3YCyQjLJfpgbBOdzjbAtL8dnzTxvflcr6z/fwf5Fe?=
 =?us-ascii?Q?SS0/9olPQygJcG8W3BE6DaR3EG4DHQYCtqLOKgPeUac1v3M4B/nh0gWqKXup?=
 =?us-ascii?Q?uwTael21ygD2cJsdbDpA4iGI0Uqg+3BdK7JYSYVJ+G8mnzzyeHJ5tmSo3z4d?=
 =?us-ascii?Q?0wzcftQD4QlS5Jm8nfbcdlncyjSqS69puLFsYRbiRV4h5+10aKBQx+Qwpx52?=
 =?us-ascii?Q?oSgN1vjucHOwXf/GiOTpVwftvWIf02YozDwcJBVy1Fr/856ygX5PrIHlH9oh?=
 =?us-ascii?Q?wGWvA6U1lkA6px9H1+LsbxZlHzsLhCoa6b/xR6a5eTx0O+4gzXwEcWnfBpFM?=
 =?us-ascii?Q?Dbnr9afMK6TFPNdO0c+hPjPWTARZMJY/pjqXNO6iEYewT7tAaeI9S5NAoFHy?=
 =?us-ascii?Q?Br8c2Dn+n775Zd5iSQi7meDky0YP2YxOckIYmXOKMocwwNZmqBMTlwnrPVEL?=
 =?us-ascii?Q?FUM1W1YUF0Kq0EStpy64G8JrMWhtncPVQU8JW9DHtaNJ8u2GGzboR+h6SHtn?=
 =?us-ascii?Q?YELOarp5WrvzoCb7OOyyjLdgcSeyGWdJRKGpzFOmEmmbrJwTLi2KhX7EyKYy?=
 =?us-ascii?Q?rUJPH1ddqouipUBvWA/5S7eUuSMOjqd474i358lSa6ks9lo3QwtyaKnHSj2+?=
 =?us-ascii?Q?D02ANbASblmr3dgjZ6k9sMXEvnR2a6H/FI1QtK7JwoVRWFu0K0YgNsvgiAsb?=
 =?us-ascii?Q?PB3YFzWwpIAidPCrrhYn7GNQxPAT/NQctzbVk8CAUHx6/gFsrlyXPesXXHL3?=
 =?us-ascii?Q?/2lQRT+c8bInWY0tXPg94IAVXxnGhLC0fE3nPOCzzATue0VYwkVbbJxiZOZq?=
 =?us-ascii?Q?25o+U0WZ4D68olIqUI2dkT5t3qUhpLVN9Swy+W7yv5pa81IVaoE9K3eerkN6?=
 =?us-ascii?Q?kiN4zRul2vawaCp6qU0uf5ZZ9CEkr4iA+YcUWpb/DNA9DQ5hP5+xTyGcseAn?=
 =?us-ascii?Q?e/Iro83T5xAQvJq4ewxb6XypFMJoU6MunbcVaIa72FfODvG8HXuFATkFxdUo?=
 =?us-ascii?Q?CzL+Lj4QiqTNQY1biY1Kru1m+OfBj7KWcvnpm6DpZ9pm9hbVOuQ72R02Xa9H?=
 =?us-ascii?Q?plxr8E5O+OyZPJ3CbRJSrN5u19jQbZnUD14SOBAYfRjwl12HCaQMwSwdSb6Q?=
 =?us-ascii?Q?hszJTdmZttPl/xrAAkadhDw2ZGf04fTZ4p7P?=
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: 27 Jun 2025 08:43:40.2803
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7dcd90b8-b454-4b54-d2f7-08ddb556b74c
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:
	SA2PEPF00003AE9.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7131

It has never been used since the introduction and is technically a dead
code violating MISRA C.

Signed-off-by: Michal Orzel 
---
 xen/arch/arm/include/asm/config.h | 4 ----
 xen/arch/arm/mmu/mm.c             | 5 -----
 2 files changed, 9 deletions(-)

diff --git a/xen/arch/arm/include/asm/config.h b/xen/arch/arm/include/asm/config.h
index 272e4565e592..f18825bc2d50 100644
--- a/xen/arch/arm/include/asm/config.h
+++ b/xen/arch/arm/include/asm/config.h
@@ -66,10 +66,6 @@
 #define STACK_ORDER 3
 #define STACK_SIZE  (PAGE_SIZE << STACK_ORDER)
 
-#ifndef __ASSEMBLY__
-extern unsigned long frametable_virt_end;
-#endif
-
 #define watchdog_disable() ((void)0)
 #define watchdog_enable()  ((void)0)
 
diff --git a/xen/arch/arm/mmu/mm.c b/xen/arch/arm/mmu/mm.c
index 9c50479c6373..6604f3bf4e6a 100644
--- a/xen/arch/arm/mmu/mm.c
+++ b/xen/arch/arm/mmu/mm.c
@@ -8,8 +8,6 @@
 #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)
 {
@@ -46,9 +44,6 @@ void __init setup_frametable_mappings(paddr_t ps, paddr_t pe)
     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));
 }
 
 /*
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Fri Jun 27 09:00:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 09:00:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027419.1402072 (Exim 4.92)
	(envelope-from )
	id 1uV4wQ-0004bY-QI; Fri, 27 Jun 2025 09:00:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027419.1402072; Fri, 27 Jun 2025 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 1uV4wQ-0004bR-Mr; Fri, 27 Jun 2025 09:00:14 +0000
Received: by outflank-mailman (input) for mailman id 1027419;
 Fri, 27 Jun 2025 09:00: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 1uV4wP-0004bL-R5
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 09:00:14 +0000
Received: from NAM04-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam04on2060a.outbound.protection.outlook.com
 [2a01:111:f403:240a::60a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 20c7dca8-5335-11f0-a30f-13f23c93f187;
 Fri, 27 Jun 2025 11:00:11 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by MN0PR12MB6173.namprd12.prod.outlook.com (2603:10b6:208:3c6::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8880.22; Fri, 27 Jun
 2025 09:00:07 +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.8835.027; Fri, 27 Jun 2025
 09:00: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: 20c7dca8-5335-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=VAXVazLpoxyN50AYlogPPvvxNjCmH1mS90Y9TUykKDcz9KiuENIXqoM2GK2/j1EYvQTEwRaTkmNmP5ROO+HNCp4H5r1f3jOxz2lL1rB/SQkcdf0EaA1Wc8AoqGvw8mBQ7vbLvkQtO5OkaQmdE7pX8v2D8NkhG65uUO/OtnGFxD87XfutjoONhsA3HeF3VYg2g6agGxVBt1ZwN1KsuDbcc/GSIehpo/YKhryLmDESPvMaBy0rIJo2U/7F05Lity8fDjNVtiXPRs7MyTQSFLJ3SVh1meQ4k32kIsu1ZdqRe2mlTbIC75K1s3J5EoFvZHHv2R+NOHgFO/3mc0NBLRHcyA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ng7bzFTycB91qXQHKOQ6Tum/xoMGMFl/6PBet7blNgg=;
 b=h1g8qld+MmX6/XNPX6X/CL+u/TklGk8f+gpsRcHjfwTu77LcP2PUtwmS8luQTAMcpnE78s6eO6gPLzpORo3Et8h4oU1bkOUGhOD3KydKFAWrQFNnepXU8Moyk+dtFG+AI36Lc5uEMMSm44q9SA+htZISX+UrHUuw1Bm6DC4o0hhVt/0ouQZ+Fm17j84tuIsEv3ndJnToNMk7nT0qtH8ofM2v7hEZGJFLueui2TtDiL056lWGq2Qz+QQcviF56ioBQLSxhP0DAcwo2MoNsvAsFHkPaaHuGJH+PooHP/33vUaMW7aVdYjrjcu3XZMY3lkHdSKGL7JVfLUc2bP/xTOLUg==
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=ng7bzFTycB91qXQHKOQ6Tum/xoMGMFl/6PBet7blNgg=;
 b=YJAG6HoiiaB6HjquJC/QltIdbYbBInik/z2hBdBSHPrCm5FDnco9r+Ms4lIo73rRfKKkLesAkklBdjNk7tkKyjSc0sq36NoPndK1AIXjF9A2+DmyMr/xzcUh4oya0CLmijwbMj9XPsIr4jB7I43TyDU9BOZMD0mnkHKlPkrSImA=
From: "Chen, Jiqian" 
To: Jan Beulich 
CC: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Andrew Cooper
	, Anthony PERARD ,
	"Orzel, Michal" , Julien Grall ,
	Stefano Stabellini , "xen-devel@lists.xenproject.org"
	, "Huang, Ray" , "Chen,
 Jiqian" 
Subject: Re: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
Thread-Topic: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
Thread-Index:
 AQHb23yakGdVC9XxvEWnYcnp8zrTt7QI/QAAgAGa9QCAAQzVgIAG5D6A//99hgCAAJwoAP//hioAgAHew4D//5oCgAASTfCA//+FrwCAAIi+gP//u5+AgAGwYID//8AMgIABfE8A//+xAYAAFslbAA==
Date: Fri, 27 Jun 2025 09:00:07 +0000
Message-ID:
 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 
 <5c4b186e-686e-4fc8-bcf1-854bc1f5ec8b@suse.com>
 
 <9d5d0e44-66c3-4e3f-8704-2c862c5f5aff@suse.com>
 
 <3638e73c-2a83-4164-9a84-839245245727@suse.com>
 
 <771cd5b7-2b89-49b1-9aba-8cd79319d3ce@suse.com>
 
 <7753470a-efef-478a-bbe5-ae48d008cfdb@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.8835.025)
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_|MN0PR12MB6173:EE_
x-ms-office365-filtering-correlation-id: 2345102d-7096-48f5-bedc-08ddb5590375
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?WGp0aE4wNUlZQVhuYldIbWtNcDNTL3NPRkM1dlhhZFdhaVVzbVJHMTFFdTA3?=
 =?utf-8?B?bUl4aTlQSmliZlNUWnp3dXluMENhYlRiTXVoazRvRjBNUC9ENUJ1c3VObXQ0?=
 =?utf-8?B?KzI4TWFGZG85c0ZrcGpJUTFZNWR5cTAwaGNqSCt0RjdDWXFNMWs5ZlVLellT?=
 =?utf-8?B?a0FJL2xLYUxiUWVaZ1BsMDRSQXJIU1FlRDc3bmsyWjJNSUZhR3loa3Z4ZlNt?=
 =?utf-8?B?bXJqWFNPVUtBeGRMTHVoSW1ENk9Lb1l1Q3RaL2F2NjJYcERvdWdaT3A4TDc2?=
 =?utf-8?B?SXdpbVVJMU5CNFdmQVhsNytqaVpQTHQ0bnBIcHJTSFd3UXE0Y2NaK0UwTTBm?=
 =?utf-8?B?WFZxbTJJMnBsckhMRmk0aVZNTFZYTHhJb05OdFllbmhzaVBpbEdZRXdUalc3?=
 =?utf-8?B?V3pmRHh1d1VvRjR5dmVPbVJPcDZWVEJyVTh4TEZFd215UjJ3RTlhamUxSHFL?=
 =?utf-8?B?RElqcEpiQWJhQzd2NHFFTTB1aUlhY3IyK2w2dkJQYXVWNlkrTGxWY1ZUOEVN?=
 =?utf-8?B?UXBJZElSUHdEMUhmOFcrTkN4MFI3T3lBQ3VxRDRSR2J4UlE5cGdVcjBsREls?=
 =?utf-8?B?Vkc3YUFoUFl0dHJjaDlFcHJMWVRQZ3d2S2dtVE93ZzdBeWRWNS9tZEtDVVAy?=
 =?utf-8?B?R1pkbjFJNGlQZTVBNUx5VlFlc0NhYjBZaEZweDdXUXJNa3VtOThleXcrRDFv?=
 =?utf-8?B?TGc1WmEvT1VYMHhxYVZNeDNESjVJdGN2Y1VrRW5wbTIwNWN5Q0c5Y2tmRjJz?=
 =?utf-8?B?VEplVGJoM2hyMXAzMVBrdnhQOTBoWnVaS3hSWTA3VnVLaVhESDR0djZwWUY5?=
 =?utf-8?B?WHpJVUgzR1ZGVHpad0tGQjNWN2RRQnNDNk51YVQvMllJL1I4VnFldzR4ZlZo?=
 =?utf-8?B?NWFqN3lERGVhZEpNelBFcHl1R1llaDRHMmpWeGJpWXZtaVlaU09pdmg2a2xq?=
 =?utf-8?B?OEZPMWRpWGRyMHF6SWlGWTV6UkdQdGsyQ3FKMW1aMS9xWW9oM2RJZ0grZ3p0?=
 =?utf-8?B?QURha0ZIUmRYR1lPYXM2dnMyRWpFN1ZzRVRXVWVBZy9tNVpUWEtrb3YveXp0?=
 =?utf-8?B?ZElKQVNydUtsVytzRHhHS3FRek95RXNmN3dTK0tEYVVMaUNZbFR4bmJEK0RT?=
 =?utf-8?B?Tis3d1ByUXN4Ri9TNkxpOWNEMXBTeHVGZFUzdGVJelNyZ01VdDU4Zk54aFU2?=
 =?utf-8?B?VXZGMC9rMkdndXR0S2ZEclRmcjdYeW54Y3hNNHdvZWZsVk05eW14dHE5WFBT?=
 =?utf-8?B?MkpvVzB3bHNkTUw3a3ByeTZRQVc3MG02cG0zcG9BRVY3OThjcHRsVDZTdmJ1?=
 =?utf-8?B?alFlbW1SOGpCWk04dnVHZmE4Y1lzYUdUZVJibE1oRkRGdnJEdm05aWRkbEtR?=
 =?utf-8?B?Y0xUUXBUdGFaV3gxZSs0NGtjUGJIdzR0WXpONFBNRnNZa3l6NDEycmpXU3kx?=
 =?utf-8?B?WDV0c2ZMRThtamhZRGNoSzRySHBZZE5TTWpaREFJNEtkbXdmOERTd1lET3ZG?=
 =?utf-8?B?TVpyUStIT0pRWndNOVFLUlVHZWJZVWJoRnpwOEZSM0xTZXE3WFZaRUxOaHlx?=
 =?utf-8?B?Y2JWdWlmUHNUQndmOTJ4WVdDd3BvVjg0RmZ5aGVBemhSeUg4TEdhTjNzRm4x?=
 =?utf-8?B?NU9ya2YrNEowcWtzWUhUNGxIS0w5azEvUWdKZTJmR3N5d3oxMUdQQUJRK1pj?=
 =?utf-8?B?cHhmekpGY05Mb3BQRHdNWnRKRjVWejl1WFpjTVBlVU1yTVdCT0NWekwrL1E4?=
 =?utf-8?B?MlVNb3d5VXUwVmduYWh3eUtsTFczek90UGZ3SCsreW1JblBZV21VTGVJZkpU?=
 =?utf-8?B?UW9WTmtWRFVlMTZTSGxkYnIxcUppM29Dd2FqREZOVU9rN2NaQVVheWRNbVRj?=
 =?utf-8?B?NXRSaHJQUk9xZ2tBaGdlYUN2S0tXMUVsQ2hlUTlMbUxhSmUyRVVXcm94c1JG?=
 =?utf-8?B?VXl1dXdPUHk2UXp6K3YrZ2duY3BvRmtlUFVxOG4zaE9JQmQyQTB2N0RkMGxs?=
 =?utf-8?B?cTV3NDE3MjV3PT0=?=
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?d0x2ZUFYZE55YXlkNDRmR0w4SXBqVnUwQkxZVXlOMk5MdXJDVnhkcEU1aDZ5?=
 =?utf-8?B?RlRmdE5WcExBenYwSWxpWDhjU3V5TTE3YTdINy9lR1BUSHU5SXUyZUMrQnh2?=
 =?utf-8?B?ZUhNMytsdGJjTkV4ZWdKdURvUU1ML0ZGRCt1dytkZ2ZTdVFaaVhQMFczTGhs?=
 =?utf-8?B?NkRBMHpLV0dYcWttc2RvZkVoZ3ZESUR4bFRNWmRIUXhPdlJ1VE9rT1VKck5H?=
 =?utf-8?B?SDFIMGlQSW1WQlVISGVBOE8wQVhyOUJrVDUwMmYyQUN1ZlFLNDJvUGpsTExp?=
 =?utf-8?B?aDA3VmpqTE8yWDlCL3pGMTMwaWdQWVlwQlBFSjJtRlpsbmVacC9GYWdOZGVS?=
 =?utf-8?B?RHRSUTdISThlWXBPWnMveldsZ3Q2TW1OS2I3eklYSnFZV3IxZHZkWU82Lzd3?=
 =?utf-8?B?N1pzWWpqT2Z0L1pjU293Z3VmQlh6dzd3N1NxZmZMUmhPNi9VWUVuMWZGWC92?=
 =?utf-8?B?Sm8zcEswU29IZ3pVQXNNcTNjUVcrWGxlTnhacWJIbWlycUhEWTJ2RUJwM1Zl?=
 =?utf-8?B?MzJUOE9WQ1ZLYWQzWjNoT3llYlZSVXhhMFBZdXdOWTAxY1VTYTRaUGRLQWVM?=
 =?utf-8?B?MVNLN24xRktqNkJLSStHREYweHdoUG0rU2FDSlR5ekVDYzREYXp5Q2xWSHF3?=
 =?utf-8?B?TUxXYmRUQ3hKaG9WWFdtNEZxajZoV3BzYXRyVlRSYXJsRUlkTzhNVC9WeHUy?=
 =?utf-8?B?QjRZNWt4N2xqalBlUThkRG1RR3pEekx5R0lDaHhkLzNUNjZGSmMwYkcrZWMw?=
 =?utf-8?B?US84TUZYK0dUTG1XWmdMczByNThoTkRJbFZaMk9Fb09BaldlNWVXODZEVlpq?=
 =?utf-8?B?OU5iTVVwS0lpOWZoQi93REovNjF0NngyRDJUU0hEQXU5Y2hVSlowM3U1ZFhI?=
 =?utf-8?B?ZmpPRkdpN1NWQmk3czNDcHJ2NGkxcTdkbjE3aU56MUQ0Mk9XZXpWaFAzczB5?=
 =?utf-8?B?RU5XbWpobjlmWTdvWlR4d05xcWZHcnFod2JZbDZOYVdNUUZWN0daSzRXdUZK?=
 =?utf-8?B?MTE3UWIwQXBwMWxRRERQZ3NlUVhPZk5jaUdqY0VDVU5XdkY3MnkxNXMyWng4?=
 =?utf-8?B?V3RPME5lMmh2WjkwVXMwWE5teVJZN2xhSmx2d0VSQlBDbHYxeVdqdVM5N1V6?=
 =?utf-8?B?VWxPNmJOVDU1S3FweUhIdWVKQUFoOVh0cWZGRUUwZDlOSmRKQkh5cDlocEZi?=
 =?utf-8?B?KzJGYXU2RzdoRDVlbTF4OXpzR2twcFRkRStuSUdPTmJWbTZ6YnVLY2NaZW5q?=
 =?utf-8?B?ZHpxV0R2dzV2dlVLRzZjRS9NcFdhWk9QalE5YlQwUC9uOTlyRWVCTWNQQzRn?=
 =?utf-8?B?MHZkM2FWeGdsM05BMkN1V0xYWTJaeWg2SVhtRnJsYS9mRUI5Qkt1bGRwY213?=
 =?utf-8?B?U2RnZVRTcDA3VzRTSUZFYzJ5cG42ZmNhclJwZ3QxSXh0MFNDUnBuWUdST0ZE?=
 =?utf-8?B?bXBEdTdpcFNtK1NycUJSejVmcmNVdzRxUkVDT3FhaVhsQWdVQk9iSFdJYlNo?=
 =?utf-8?B?c2lCdkdGb0o5dHVLVUJHcGo1b2p1OHI1THVuS1A2d1BvaTRsOWp0Z1YvemNv?=
 =?utf-8?B?eEw1dzdLN0J2WGR1cXE4aitSR1NZMkJIY05haVJyRWkyQXNlK1pVMXN4WDdj?=
 =?utf-8?B?bFAzUUJBdzNZSXlpdm1EekplZVdxOVd5UWEyUTE5NWYzcklYVExaa21TdDBK?=
 =?utf-8?B?enhabk9DQ25nL2syY3h0clFBSGhMVEtYd0Vpc0s2bGNObGFnQW5mQVNMcGdi?=
 =?utf-8?B?M3hjWlFqK3NnODFnM0VubEJYVWRVczNjMWRLdzlsMUZTdDc1dTQ1dnlDM3hN?=
 =?utf-8?B?djd4cmpyOTBXM3IyWjJMMmZmQ1dZcnU0eTZWalFMTFRwMkx6eEhFd2lPaHhv?=
 =?utf-8?B?TVBLRUUrajE3b2ZYQzJlTitnMXNwS2YwMU5PL0l5ZDVueDR1ZHlzRUtGaUw2?=
 =?utf-8?B?OUVQWmMrZ2JYdngxNUVRbXJzUkNYRXNZalQwNFh4Y29rQTQ1VFBUaFV5NWx0?=
 =?utf-8?B?QVpQdW5pMk1uNW44TzdjaUlaWlk2VHFBSWRpVzlXNGdndWlWRSthU1hoUm9z?=
 =?utf-8?B?ajVLQi9vVTMxMGpleDI2cklBUGFoeEl0WGlMMTdaMUhyNGFSVmJEc1hNR01t?=
 =?utf-8?Q?qw8k=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <3FBCA76945856F42B3EC9A1B369353D2@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: 2345102d-7096-48f5-bedc-08ddb5590375
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2025 09:00:07.0712
 (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: 3nfJvhcHLQv6AJ/b2mf9poOlvj1oAaKgyEEh5zoGogou81TICtTXZINjx8bj9AoswmWIbgVktzY3yuXs0g+W9w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6173

T24gMjAyNS82LzI3IDE0OjA1LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMjcuMDYuMjAyNSAw
NDo1OSwgQ2hlbiwgSmlxaWFuIHdyb3RlOg0KPj4gT24gMjAyNS82LzI2IDIwOjA2LCBKYW4gQmV1
bGljaCB3cm90ZToNCj4+PiBPbiAyNi4wNi4yMDI1IDEwOjAzLCBDaGVuLCBKaXFpYW4gd3JvdGU6
DQo+Pj4+IE9uIDIwMjUvNi8yNSAyMjowNywgSmFuIEJldWxpY2ggd3JvdGU6DQo+Pj4+PiBPbiAy
NS4wNi4yMDI1IDEyOjE2LCBDaGVuLCBKaXFpYW4gd3JvdGU6DQo+Pj4+Pj4gT24gMjAyNS82LzI1
IDE4OjAzLCBKYW4gQmV1bGljaCB3cm90ZToNCj4+Pj4+Pj4gQWxzbywgYXMgc2FpZCAtIHlvdSB3
aWxsIG5lZWQgdG8gY2hlY2sgd2hldGhlciBvdGhlciBhcmNoaXRlY3R1cmVzIGFyZQ0KPj4+Pj4+
PiBkaWZmZXJlbnQgZnJvbSB4ODYtNjQgaW4gdGhpcyByZWdhcmQuIFdlIGJldHRlciB3b3VsZG4n
dCBsZWF2ZSBhIHRyYXAgaGVyZSwNCj4+Pj4+Pj4gZm9yIHRoZW0gdG8gZmFsbCBpbnRvIHdoZW4g
dGhleSBlbmFibGUgdlBDSSBzdXBwb3J0LiBJLmUuIG15IHJlY29tbWVuZGF0aW9uDQo+Pj4+Pj4+
IHdvdWxkIGJlIHRoYXQgaWYgaW4gZG91YnQsIHdlIHB1dCB0aGUgX19hbGlnbmVkKCkgdGhlcmUg
dW5jb25kaXRpb25hbGx5Lg0KPj4+DQo+Pj4gTm90ZSBob3cgSSB1c2VkIF9fYWxpZ25lZCgpIGhl
cmUuIFdoeSB3b3VsZCB5b3UgLi4uDQo+Pj4NCj4+Pj4+PiBUaGF0J3MgZGlmZmljdWx0IGZvciBt
ZSB0byBjaGVjayBvbiBhbGwgZGlmZmVyZW50IHBsYXRmb3JtcyBzaW5jZSBJIGRvbid0IGhhdmUg
dGhlbSBhbGwuDQo+Pj4+Pg0KPj4+Pj4gWW91IGRvbid0IG5lZWQgdG8gaGF2ZSB0aGVtLiBZb3Un
ZCBuZWVkIHRvIGNhcmVmdWxseSBnbyB0aHJvdWdoIHRoZSByZXNwZWN0aXZlDQo+Pj4+PiBzZWN0
aW9uKHMpIG9mIHRoZWlyIHBzQUJJLXMuDQo+Pj4+Pg0KPj4+Pj4+IFNvIHlvdSBtZWFuIEkgc2hv
dWxkIHJlbW92ZSAiI2lmZGVmIENPTkZJR19YODYiPyBKdXN0IGxldCBfX2FsaWduZWQoMTYpIGZv
ciBhbGwgcGxhdGZvcm1zPw0KPj4+Pj4NCj4+Pj4+IFllcy4gQW5kLCBhcyBhbHNvIHNhaWQsIHdp
dGggYSBzdWl0YWJsZSBjb21tZW50IHBsZWFzZS4NCj4+Pj4gQWgsIG15IGNvbW1lbnQgZGVmaW5p
dGVseSBuZWVkcyB5b3VyIGNoYW5nZSBzdWdnZXN0aW9uLg0KPj4+PiBJIHdyb3RlIGEgZHJhZnQg
YXMgYmVsb3c6DQo+Pj4+DQo+Pj4+IC8qDQo+Pj4+ICAqIFNpemUgb2YgdnBjaV9jYXBhYmlsaXR5
IGlzIGxhZ2VyIHRoYW4gOCBieXRlcy4gV2hlbiBpdCBpcyB1c2VkIGFzIHRoZSBlbnRyeQ0KPj4+
PiAgKiBvZiBfX3N0YXJ0X3ZwY2lfYXJyYXkgaW4gc2VjdGlvbiwgaXQgaXMgMTYtYnl0ZSBhbGln
bmVkIGJ5IGFzc2VtYmxlciwgdGhhdA0KPj4+PiAgKiBjYXVzZXMgdGhlIGFycmF5IGxlbmd0aCAo
X19lbmRfdnBjaV9hcnJheSAtIF9fc3RhcnRfdnBjaV9hcnJheSkgd3JvbmcsIHNvDQo+Pj4+ICAq
IGZvcmNlIGl0cyBkZWZpbml0aW9uIHRvIHVzZSAxNi1ieXRlIGFsaWduZWQgaGVyZS4NCj4+Pj4g
ICovDQo+Pj4+IHN0cnVjdCB2cGNpX2NhcGFiaWxpdHkgew0KPj4+PiAgICAgdW5zaWduZWQgaW50
IGlkOw0KPj4+PiAgICAgYm9vbCBpc19leHQ7DQo+Pj4+ICAgICBpbnQgKCogaW5pdCkoY29uc3Qg
c3RydWN0IHBjaV9kZXYgKnBkZXYpOw0KPj4+PiAgICAgaW50ICgqIGNsZWFudXApKGNvbnN0IHN0
cnVjdCBwY2lfZGV2ICpwZGV2KTsNCj4+Pj4gfSBfX2F0dHJpYnV0ZV9fKChhbGlnbmVkKDE2KSkp
Ow0KPj4+DQo+Pj4gLi4uIG9wZW4tY29kZSB0aGF0IGhlcmU/DQo+PiBUaGF0IGJlY2F1c2Ugd2hl
biB1c2luZyBfX2FsaWduZWQoKSB3aXRob3V0IENPTkZJR19YODYsIEkgZ290IGNvbXBpbGUgZXJy
b3INCj4+IHZwY2kuaDoxODoxMzogZXJyb3I6IGV4cGVjdGVkIGRlY2xhcmF0aW9uIHNwZWNpZmll
cnMgb3Ig4oCYLi4u4oCZIGJlZm9yZSBudW1lcmljIGNvbnN0YW50DQo+PiAgICAxOCB8IH0gX19h
bGlnbmVkKDE2KTsNCj4+ICAgICAgIHwgICAgICAgICAgICAgXn4NCj4+IEkgdHJpZWQgc29tZSBt
ZXRob2RzLCBvbmx5IG9wZW4tY29kZSBjYW4gZml4IGl0Lg0KPiANCj4gV2VsbCwgdGhhdCdzIG9k
ZC4gSW4gZS5nLiB4ZW4vc2NoZWQuaCB3ZSBoYXZlDQo+IA0KPiBzdHJ1Y3QgZG9tYWluDQo+IHsN
Cj4gICAgIC4uLg0KPiB9IF9fYWxpZ25lZChQQUdFX1NJWkUpOw0KPiANCj4gd2hpY2ggY2xlYXJs
eSBtdXN0IGJlIHdvcmtpbmcgZmluZS4gVGhlIGVycm9yIG1lc3NhZ2UgZnJvbSB0aGUgY29tcGls
ZXINCj4gZG9lc24ndCBzYXkgdmVyeSBtdWNoIGFsb25lLiBGb3IgaW5mb3JtYXRpb25hbCBkaWFn
bm9zdGljcyB0aGUgY29tcGlsZXINCj4gbm9ybWFsbHkgYWxzbyBlbWl0cyBtYXkgaGVscCwgb3Ig
ZWxzZSBpdCB3b3VsZCB0YWtlIGxvb2tpbmcgYXQgdGhlDQo+IHByZS1wcm9jZXNzZWQgb3V0cHV0
IHRvIHVuZGVyc3RhbmQgd2hhdCdzIGdvaW5nIG9uIGhlcmUuDQoNCkkgYWRkIHNvbWUgY29kZXMg
dG8gcHJpbnQgdGhlIG1hY3JvIF9fYWxpZ24sIHRoZSBjb2RlcyBhcmU6DQoNCmRpZmYgLS1naXQg
YS94ZW4vaW5jbHVkZS94ZW4vdnBjaS5oIGIveGVuL2luY2x1ZGUveGVuL3ZwY2kuaA0KaW5kZXgg
NTE1NzNiYWFiYy4uOGY2YWYxYzgyMiAxMDA2NDQNCi0tLSBhL3hlbi9pbmNsdWRlL3hlbi92cGNp
LmgNCisrKyBiL3hlbi9pbmNsdWRlL3hlbi92cGNpLmgNCkBAIC0xMywxMiArMTMsMTYgQEAgdHlw
ZWRlZiB1aW50MzJfdCB2cGNpX3JlYWRfdChjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldiwgdW5z
aWduZWQgaW50IHJlZywNCiB0eXBlZGVmIHZvaWQgdnBjaV93cml0ZV90KGNvbnN0IHN0cnVjdCBw
Y2lfZGV2ICpwZGV2LCB1bnNpZ25lZCBpbnQgcmVnLA0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgdWludDMyX3QgdmFsLCB2b2lkICpkYXRhKTsNCg0KKyNkZWZpbmUgU1RSSU5HSUZZKHgpICN4
DQorI2RlZmluZSBUT1NUUklORyh4KSBTVFJJTkdJRlkoeCkNCisjcHJhZ21hIG1lc3NhZ2UoIl9f
YWxpZ25lZCgxNikgZXhwYW5kcyB0bzogIiBUT1NUUklORyhfX2FsaWduZWQoMTYpKSkNCisNCiBz
dHJ1Y3QgdnBjaV9jYXBhYmlsaXR5IHsNCiAgICAgdW5zaWduZWQgaW50IGlkOw0KICAgICBib29s
IGlzX2V4dDsNCiAgICAgaW50ICgqIGluaXQpKGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZGV2KTsN
CiAgICAgaW50ICgqIGNsZWFudXApKGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZGV2KTsNCn0gX19h
bGlnbmVkKDE2KTsNCg0KVGhlIHJlc3VsdCBhcmU6DQoNCkluIGZpbGUgaW5jbHVkZWQgZnJvbSAu
L2luY2x1ZGUveGVuL3NjaGVkLmg6MjUsDQogICAgICAgICAgICAgICAgIGZyb20gYXJjaC94ODYv
eDg2XzY0L2FzbS1vZmZzZXRzLmM6MTE6DQouL2luY2x1ZGUveGVuL3ZwY2kuaDoxODo5OiBub3Rl
OiDigJgjcHJhZ21hIG1lc3NhZ2U6IF9fYWxpZ25lZCgxNikgZXhwYW5kcyB0bzogX19hdHRyaWJ1
dGVfXygoX19hbGlnbmVkX18oMTYpKSnigJkNCiAgIDE4IHwgI3ByYWdtYSBtZXNzYWdlKCJfX2Fs
aWduZWQoMTYpIGV4cGFuZHMgdG86ICIgVE9TVFJJTkcoX19hbGlnbmVkKDE2KSkpDQogICAgICB8
ICAgICAgICAgXn5+fn5+fg0KSW4gZmlsZSBpbmNsdWRlZCBmcm9tIC4vaW5jbHVkZS94ZW4vc2No
ZWQuaDoyNSwNCiAgICAgICAgICAgICAgICAgZnJvbSBkcml2ZXJzL3ZwY2kvdnBjaS5jOjIwOg0K
Li9pbmNsdWRlL3hlbi92cGNpLmg6MTg6OTogbm90ZTog4oCYI3ByYWdtYSBtZXNzYWdlOiBfX2Fs
aWduZWQoMTYpIGV4cGFuZHMgdG86IF9fYXR0cmlidXRlX18oKF9fYWxpZ25lZF9fKDE2KSkp4oCZ
DQogICAxOCB8ICNwcmFnbWEgbWVzc2FnZSgiX19hbGlnbmVkKDE2KSBleHBhbmRzIHRvOiAiIFRP
U1RSSU5HKF9fYWxpZ25lZCgxNikpKQ0KICAgICAgfCAgICAgICAgIF5+fn5+fn4NCkluIGZpbGUg
aW5jbHVkZWQgZnJvbSBlbXVsLmg6ODgsDQogICAgICAgICAgICAgICAgIGZyb20gdnBjaS5jOjE4
Og0KdnBjaS5oOjE1Ojk6IG5vdGU6IOKAmCNwcmFnbWEgbWVzc2FnZTogX19hbGlnbmVkKDE2KSBl
eHBhbmRzIHRvOiBfX2FsaWduZWQoMTYp4oCZDQogICAxNSB8ICNwcmFnbWEgbWVzc2FnZSgiX19h
bGlnbmVkKDE2KSBleHBhbmRzIHRvOiAiIFRPU1RSSU5HKF9fYWxpZ25lZCgxNikpKQ0KICAgICAg
fCAgICAgICAgIF5+fn5+fn4NCnZwY2kuaDoyMjoxMzogZXJyb3I6IGV4cGVjdGVkIGRlY2xhcmF0
aW9uIHNwZWNpZmllcnMgb3Ig4oCYLi4u4oCZIGJlZm9yZSBudW1lcmljIGNvbnN0YW50DQogICAy
MiB8IH0gX19hbGlnbmVkKDE2KTsNCiAgICAgIHwgICAgICAgICAgICAgXn4NCkluIGZpbGUgaW5j
bHVkZWQgZnJvbSBlbXVsLmg6ODgsDQogICAgICAgICAgICAgICAgIGZyb20gbWFpbi5jOjE5Og0K
dnBjaS5oOjE1Ojk6IG5vdGU6IOKAmCNwcmFnbWEgbWVzc2FnZTogX19hbGlnbmVkKDE2KSBleHBh
bmRzIHRvOiBfX2FsaWduZWQoMTYp4oCZDQogICAxNSB8ICNwcmFnbWEgbWVzc2FnZSgiX19hbGln
bmVkKDE2KSBleHBhbmRzIHRvOiAiIFRPU1RSSU5HKF9fYWxpZ25lZCgxNikpKQ0KICAgICAgfCAg
ICAgICAgIF5+fn5+fn4NCnZwY2kuaDoyMjoxMzogZXJyb3I6IGV4cGVjdGVkIGRlY2xhcmF0aW9u
IHNwZWNpZmllcnMgb3Ig4oCYLi4u4oCZIGJlZm9yZSBudW1lcmljIGNvbnN0YW50DQogICAyMiB8
IH0gX19hbGlnbmVkKDE2KTsNCiAgICAgIHwgICAgICAgICAgICAgXn4NCm1ha2VbNl06ICoqKiBb
TWFrZWZpbGU6MTg6IHRlc3RfdnBjaV0gRXJyb3IgMQ0KbWFrZVs1XTogKioqIFsvaG9tZS9janEv
Y29kZS91cHN0cmVhbS94ZW4vdG9vbHMvdGVzdHMvLi4vLi4vdG9vbHMvUnVsZXMubWs6MTk0OiBz
dWJkaXItaW5zdGFsbC12cGNpXSBFcnJvciAyDQptYWtlWzRdOiAqKiogWy9ob21lL2NqcS9jb2Rl
L3Vwc3RyZWFtL3hlbi90b29scy90ZXN0cy8uLi8uLi90b29scy9SdWxlcy5tazoxODk6IHN1YmRp
cnMtaW5zdGFsbF0gRXJyb3IgMg0KbWFrZVszXTogKioqIFsvaG9tZS9janEvY29kZS91cHN0cmVh
bS94ZW4vdG9vbHMvLi4vdG9vbHMvUnVsZXMubWs6MTk0OiBzdWJkaXItaW5zdGFsbC10ZXN0c10g
RXJyb3IgMg0KbWFrZVsyXTogKioqIFsvaG9tZS9janEvY29kZS91cHN0cmVhbS94ZW4vdG9vbHMv
Li4vdG9vbHMvUnVsZXMubWs6MTg5OiBzdWJkaXJzLWluc3RhbGxdIEVycm9yIDINCm1ha2VbMV06
ICoqKiBbTWFrZWZpbGU6NjQ6IGluc3RhbGxdIEVycm9yIDINCm1ha2U6ICoqKiBbTWFrZWZpbGU6
MTQ3OiBpbnN0YWxsLXRvb2xzXSBFcnJvciAyDQptYWtlOiAqKiogV2FpdGluZyBmb3IgdW5maW5p
c2hlZCBqb2JzLi4uLg0KDQo+IA0KPj4+IEFzIHRvIHRoZSBjb21tZW50OiBGaXJzdCwgaXQgd2Fu
dHMgdG8gYmUgYXMgY2xvc2UgdG8gd2hhdCBpcyBiZWluZyBjb21tZW50ZWQgYXMNCj4+PiBwb3Nz
aWJsZS4gSGVuY2UNCj4+Pg0KPj4+IHN0cnVjdCBfX2FsaWduZWQoMTYpIHZwY2lfY2FwYWJpbGl0
eSB7DQo+PiBUaGlzIGFsc28gZ290IHRoZSBjb21waWxlIGVycm9yLg0KPj4+DQo+Pj4gaXMgbGlr
ZWx5IHRoZSBiZXR0ZXIgcGxhY2VtZW50LiBTZWNvbmQsIHRoZXJlJ3Mgbm90aGluZyBoZXJlIHRo
ZSBhc3NlbWJsZXIgZG9lcw0KPj4+IG9uIGl0cyBvd24uIEl0J3MgdGhlIGNvbXBpbGVyIHdoaWNo
IGRvZXMgc29tZXRoaW5nIChpbnNlcnQgYWxpZ25tZW50IGRpcmVjdGl2ZXMpLA0KPj4+IGFuZCBv
bmx5IHRvIGZvbGxvdyBjZXJ0YWluIHJ1bGVzLiAoU2VlICJ4ODY6IGRvbid0IGhhdmUgZ2NjIG92
ZXItYWxpZ24gZGF0YSINCj4+PiB0aGF0IEkgQ2MtZWQgeW91IG9uIGZvciBzb21lIG9mIHRoZSBy
ZWxldmFudCBhc3BlY3RzLikgVGhhdCBpcywgeW91IGRvbid0IHdhbnQNCj4+PiB0byAiYmxhbWUi
IGFueSBwYXJ0IG9mIHRoZSB0b29sIGNoYWluLCBhdCBsZWFzdCBub3Qgd2hlcmUgaXQncyB0aGUg
dW5kZXJseWluZw0KPj4+IEFCSSB0aGF0IG1hbmRhdGVzIGNlcnRhaW4gYmVoYXZpb3IuIFRoZXJl
J3MgYWxzbyBubyBzdHJvbmcgbmVlZCB0byB0YWxrIGFib3V0DQo+Pj4gdGhlIHNwZWNpZmljIGVm
ZmVjdHMgdGhhdCBpdCB3b3VsZCBoYXZlIGlmIHdlIGRpZG4ndCBhcnJhbmdlIHRoaW5ncyBwcm9w
ZXJseS4NCj4+PiBUaGF0IGlzLCB0YWxraW5nIGFib3V0IHRoZSBlZmZlY3Qgb24gYXJyYXlzIGlu
IGdlbmVyYWwgaXMgZmluZSBhbmQgaGVscGZ1bC4NCj4+PiBUYWxraW5nIGFib3V0IF9fe3N0YXJ0
LGVuZH1fdnBjaV9hcnJheSBpbW8gaXMgbm90Lg0KPj4+DQo+Pj4gV2hpbGUgZnVydGhlciBwbGF5
aW5nIHdpdGggdGhlIGNvbXBpbGVyLCBJIG5vdGljZWQgdGhhdCBhZGRpbmcgX19hbGlnbmVkKDE2
KQ0KPj4+IGFjdHVhbGx5IGhhcyBhIG5lZ2F0aXZlIGVmZmVjdCBhcyBsb25nIGFzIHRoYXQgb3Ro
ZXIgcGF0Y2ggaXNuJ3QgaW4gdXNlOiBUaGUNCj4+PiBzdHJ1Y3QgaW5zdGFuY2VzIHRoZW4gYXJl
IGJlaW5nIGFsaWduZWQgdG8gZXZlbiAzMi1ieXRlIGJvdW5kYXJpZXMgKHdoaWNoIG1lYW5zDQo+
Pj4gX19zdGFydF92cGNpX2FycmF5IHdvdWxkIHRoZW4gYWxzbyBuZWVkIGFsaWduaW5nIGFzIG11
Y2gpLiBXaGVuIHRoYXQgb3RoZXINCj4+PiBwYXRjaCBpcyBpbiB1c2UsIHRoZSBfX2FsaWduZWQo
KSBiZWNvbWVzIHVubmVjZXNzYXJ5LiBUaGVyZWZvcmUgSSdtIG5vIGxvbmdlcg0KPj4+IGNvbnZp
bmNlZCB1c2luZyBfX2FsaWduZWQoKSBpcyB0aGUgYmVzdCBzb2x1dGlvbiBoZXJlLg0KPj4gRW0s
IGNoYW5naW5nIF9fc3RhcnRfdnBjaV9hcnJheSB0byBiZSBzdHJ1Y3QgdnBjaV9jYXBhYmlsaXR5
IGFycmF5IGNhdXNlIHRob3NlIGNvbmNlcm5zLCBtYXliZSBrZWVwaW5nIHVzaW5nIHN0cnVjdCBw
b2ludGVyIGlzIGEgY29tcHJvbWlzZSBtZXRob2QuDQo+IA0KPiBJdCB3b3VsZCBiZSBhIGxhc3Qg
cmVzb3J0LCB5ZXMsIGJ1dCBpbW8gKGEpIHdlIG91Z2h0IHRvIHN0cml2ZSB0byBhdm9pZA0KPiB1
bm5lY2Vzc2FyeSBpbmRpcmVjdGlvbiBhbmQgKGIpIHRoZSBzYW1lIHVuZGVybHlpbmcgaXNzdWUg
Y291bGQgYmVjb21lIGENCj4gcHJvYmxlbSBlbHNld2hlcmUgYXMgd2VsbC4NCj4gDQo+IEphbg0K
DQotLSANCkJlc3QgcmVnYXJkcywNCkppcWlhbiBDaGVuLg0K


From xen-devel-bounces@lists.xenproject.org Fri Jun 27 09:25:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 09:25:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027431.1402081 (Exim 4.92)
	(envelope-from )
	id 1uV5KP-0007kq-P0; Fri, 27 Jun 2025 09:25:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027431.1402081; Fri, 27 Jun 2025 09:25: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 1uV5KP-0007kj-MG; Fri, 27 Jun 2025 09:25:01 +0000
Received: by outflank-mailman (input) for mailman id 1027431;
 Fri, 27 Jun 2025 09:25: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 1uV5KO-0007kN-9R
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 09:25:00 +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 975c4afc-5338-11f0-a30f-13f23c93f187;
 Fri, 27 Jun 2025 11:24:58 +0200 (CEST)
Received: from PH7PR12MB5854.namprd12.prod.outlook.com (2603:10b6:510:1d5::20)
 by DS7PR12MB6024.namprd12.prod.outlook.com (2603:10b6:8:84::17) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.29; Fri, 27 Jun
 2025 09:24:53 +0000
Received: from PH7PR12MB5854.namprd12.prod.outlook.com
 ([fe80::bd58:fa72:e622:dd76]) by PH7PR12MB5854.namprd12.prod.outlook.com
 ([fe80::bd58:fa72:e622:dd76%7]) with mapi id 15.20.8857.026; Fri, 27 Jun 2025
 09:24: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: 975c4afc-5338-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=bNECqHaQ45j0NZluSauqJRHMqJEa4hZgTTHsmbkQ7HH8QbqjmGZg0LpNYmyb0/mv/0QIK8y0K5DDoxrRRz6Q5bKnSQMLYwHh2IYbBNrQH0KeFKbPZVJ/GA6HZyRurNXwSkk1QaAjrJicbLybrpCBYhxzQnN+Us64MCEVEHY86Cqgrx0/1y7Xe1ImsrxYSPKC34PxP9ApV96g80BJ7Kq1foF90JOgHxRGHFh7744oNRQil4eFnelvkfdBXGTKtSQXyz2B/U5lvntYWVw+3ghuCzMe6DaCdrPVmpikFkHESYFTSOOSBGY0ay/XkLX8k2S+B3Gn3B8tpS1DNOEA6TGDfA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=TGVFcYw80RbpO+zg2GsPYGyW80QfANJgUVzAsCE5wI8=;
 b=Ye0hK2+rLjmFuhIZK6tJ8zfAuh/gsnPD1BUpB3Xy/q5Lv0r/FCW3MRgbiuny1zgFWVnbU1K7kLP8u7Hlo4QrMcdSL2oj9b7GkAAuVNW+JjemMOaqEqhyXkt8Q6YuTDhkZIWcpMZQbKSrw75N+CPgK0Z4Y2uMe7/KJ9vpQScjmjqPzmO/ytbYxZpYZkEloycNxoJzfIrjQkYdIbsa5fkJSst78kAGPQWh7FOiB6sWB/RuVW5ehvDEDbHAb45ZinmxAbSM7CEgLH+4KiGRXfzYeWgZQa2MxIqyFnT5zCyMw+TyCrQox3zUwbuRVUO1YrvuvP0gF9pwnUHtNhTN2EVvoA==
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=TGVFcYw80RbpO+zg2GsPYGyW80QfANJgUVzAsCE5wI8=;
 b=HvaN2MO54E6dFPH7eD9xW9XALYe9qqKKgFzmhlF/qYpK9h31UWD7OdbCwQEH0gNN+bAaNbJVskeOdWuvXQax/XVGvup2ElPrZ/OXcTUo2VMcS/hW2yBX4CCXswssKk8joMmHY0GEA1fssQQHkFEgOctFWpVusSuzAi80hmaaCj8=
From: "Chen, Jiqian" 
To: Jan Beulich 
CC: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Andrew Cooper
	, Anthony PERARD ,
	"Orzel, Michal" , Julien Grall ,
	Stefano Stabellini , "xen-devel@lists.xenproject.org"
	, "Huang, Ray" , "Chen,
 Jiqian" 
Subject: Re: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
Thread-Topic: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
Thread-Index:
 AQHb23yakGdVC9XxvEWnYcnp8zrTt7QI/QAAgAGa9QCAAQzVgIAG5D6A//99hgCAAJwoAP//hioAgAHew4D//5oCgAASTfCA//+FrwCAAIi+gP//u5+AgAGwYID//8AMgIABfE8A//+xAYAAFslbAAAA2zOA
Date: Fri, 27 Jun 2025 09:24:53 +0000
Message-ID:
 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <5c4b186e-686e-4fc8-bcf1-854bc1f5ec8b@suse.com>
 
 <9d5d0e44-66c3-4e3f-8704-2c862c5f5aff@suse.com>
 
 <3638e73c-2a83-4164-9a84-839245245727@suse.com>
 
 <771cd5b7-2b89-49b1-9aba-8cd79319d3ce@suse.com>
 
 <7753470a-efef-478a-bbe5-ae48d008cfdb@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: PH7PR12MB5854.namprd12.prod.outlook.com
 (15.20.8857.026)
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: PH7PR12MB5854:EE_|DS7PR12MB6024:EE_
x-ms-office365-filtering-correlation-id: 4e7b500b-33a2-4f27-d343-08ddb55c7942
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?TEpDWlUxN0JnTjhCQ0lDcWI2b0JhSW8vRlpEMzMvQVJwQlBNM0JmRUVnSkdi?=
 =?utf-8?B?VVkwR3VFeG1abU9pMXZmNXl2RFh4WFI5bHk2VndtY3EvZ050T0hBQ2k4SGkz?=
 =?utf-8?B?dXNZM20vQUtUY1lkaTBBNkpLNy9EaHFnYzJ3SDB0dmJGMFk2Mmt5YmllR3Za?=
 =?utf-8?B?RmhtcVQ3R3lUZUtzMnQ4WVFEOXI1amtKeEhnOC9lcmVtTGdMVXl3ZEc0UVhQ?=
 =?utf-8?B?TWxjd1lXMGpiYWZHNlg4dEVxK3AwU1J0azJ0em9BZ3BZek1rWnRTV2FSRVBT?=
 =?utf-8?B?ODljSm5ZM0x6NytNdUQyWnZrOXFydS9Mc1BZeGpOVkR2a3k1bEtwRFRQTW8r?=
 =?utf-8?B?YzFGazlTbzU5ZldVc1VmOEVkNW93aWtHdDZuOTRHcDNyWmFnK1I0T21Ock00?=
 =?utf-8?B?dnB1dU9Pa1pVVU9ZMk5ueDFsSGsxQ2FsZHkwV29HeGZxQTVNdG0zeUlmM0Vk?=
 =?utf-8?B?USs3YTAyb0VzSk1MUU1NekM4bUNsaDNZVXNPSU1abVA1b0plekx4TUdBamRO?=
 =?utf-8?B?NGRueHFRc21VVmovdmFtZHFsTTB5Q1ptZ2kyQllyS2xzSWZmcGk0ME5pMU5p?=
 =?utf-8?B?ZGJ1RWZUY01xelhSNlNlRXM1RUZ5UmlJOE9rV0pPaExyWElPbHVCNzJldnJo?=
 =?utf-8?B?eUFFODZRM25BNjk0RE1CZXVTN2lqRVczMzZlK3JUaHRuVnROY3B3emNJOXdm?=
 =?utf-8?B?YTRjdXF5ZmFDTGUzTGVqeXdzbUUvcEEySy83eFVNN0liakdOd0RKTlM3WFhP?=
 =?utf-8?B?aVpuNmVwUnVoMHJJTFVYcmtIL3hhNTArUHZCbE9pYVFRbHcrMnovZkZydFU0?=
 =?utf-8?B?ay82cEY3bmErMCtZRUFGNVJnNDRrT2xSYy8rdkNra1V4cFM1Um00YWhZcmRm?=
 =?utf-8?B?bkthQXRJQk9LTmhoMVhWZEY1NnB6RnBPbmcyOWVhWHhvcEpmaDN4MS9Ja1NG?=
 =?utf-8?B?aUltR1hYbGlvOXdpcVRhb2pZaFFUMm1EdEZXUGd0RWltdy9mMStDVWhIbytX?=
 =?utf-8?B?YUJGRkw2ZkloODM3Q3BPRjYvS3ZDUWJtRlBDYm13MmJWWmdNNEdZbDhvelNV?=
 =?utf-8?B?NmNIcEhNRFdzcmt4VDltSHlUcDFHc29TdWJpbmJnY2cvUEYvQlZWNm00RlJR?=
 =?utf-8?B?UjNyU3FUTHd3OTNYeDdmYjBTbjB0d0pBT3RBS2NTM3FhelVPUzNHQVVSYjU0?=
 =?utf-8?B?S3RtbUtNd2V1bnkrOUxCRGdwWkpsNjFpMDJleGpic29pTVFzOUNQSU14czRq?=
 =?utf-8?B?aGJwL3d0NGl5QnkyTU9uMUhtRW1wSk1HaUFmb21HbDlYVGo2Y0M5ZldSMlNB?=
 =?utf-8?B?d3BpVjRsN1FEMXdabUo1QnVIaG5iRWh1VWJuS2tqY3hra1dDRmdTNnZHVElQ?=
 =?utf-8?B?ZTExRTNDZGtKdDJrcGdDNjRkMThqQ2hjc1BpZGk5VGtzSFdsSVZIOVpFNTdF?=
 =?utf-8?B?LzFSMEhhekg5Y3BvbTlxZytVUHdRN1IxKzVtYXA0NzMwTU9SV3k2RnVENXB2?=
 =?utf-8?B?VnpJQ2E0dWprWGVmNGx6SmFrVVF3MlZ3ZE1lQ0h6alk5RnU5eGpzSzdEZllV?=
 =?utf-8?B?UXZCbTZROTgwYUNOUnpXYWZZR3lhcDFlYnV3UDF3aWlIY1R3cXZpeEJNNEtv?=
 =?utf-8?B?Q1pLYnphbi9EbFBHcGJoZmFaUHJCd0crMktrS2RjY1p4QnVVUkFyY3g5eFc4?=
 =?utf-8?B?Y01nUituSDlnTkpaRW1yMzdjckNPazhkeVQ1SHRJOGlzVjI2b1ZmdDJxeUZS?=
 =?utf-8?B?UnpmK3JVc3JEUTRySE9yM3BZVGpNQm52cHhzUHVNdE1KbzBXdEpmbVVTRVZT?=
 =?utf-8?B?cU95KzFxRHdWb0tDMXF0KzVjREJzdnBNdFpJWmRsakxwZ2JIWW1MUFE2dSs0?=
 =?utf-8?B?dytsd1FURHprU2hMcW5DYmRIUVl6UHB4RlFsS1BCdFdwaEpidEJlYUJpR1NO?=
 =?utf-8?B?NWNlM1FlK0RGZEpucXhPTUlRbW5uTEdiWE5Ebm1UaEpjWGVDS2orazB6TXl2?=
 =?utf-8?B?SnlJVTFtQ1RBPT0=?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH7PR12MB5854.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?RUZENjBlMnNiNk1YUk5HNkhnK3RwbWZseWw0N21Ba1dxc3FPQUZGUTlXWjRs?=
 =?utf-8?B?ZkVKbmJ5UURPUkVnN1h0ZkkyVnJ5NzhGbkZ0K0tPKzhNMVdFZ3F4WUN2WEg4?=
 =?utf-8?B?aGlWbm92SUpjcjA2dEM4cGJFWFRYbHpsMEdPYVZzSWFWd2ltVzdrbkhQQ0c2?=
 =?utf-8?B?cXFKN3dMZGowTkZPOUJXZ0J0VUU1VThnd0ZNZDJDRXZvN2tNZ0hXbjg2NXVG?=
 =?utf-8?B?V052L0REeEhBOThyVWE1S1lKOGJzcTFBWVpCVit6aldoejlXWXJ0cVVLYVl6?=
 =?utf-8?B?SkthdmVEZW9KbWNnMWpxS3hxdVFvWTZGcnlERU5IdzQ0SkpKbFlwVERuQkNn?=
 =?utf-8?B?ejhZWDhuSVByZ09rZHBtaTVocmlBZ2FZUmtodnZUVjNRVTc5VnVmMnFnSHR4?=
 =?utf-8?B?TEQ0TjB2ZmlaOHNreFFoYjhUR1JuYS9NeU1JeFcyS0dTWGRaRWdCT1BDdXlM?=
 =?utf-8?B?Z0xKQjhhZU1TSnJqbkhOa0pHeHVEUVlaUGFWYmtJSmFTbkV2ZHdTYVBwOXJi?=
 =?utf-8?B?WWFKWDJNQ0JoSCtId2dFMDJIa1hoWFNMbStxbU5ZSERDc2JGQmtiZi96K1RI?=
 =?utf-8?B?NUl5NVBkbUc5TmJnZDVZMmpXaU9FZG1Bd0hJREQxL0M2Q2V4bWlMaWFBZkhs?=
 =?utf-8?B?bTF0azQ0ZE5LMEJHOUNtOG16OG41dFptWjdReXduVVlhS2M3MXJYeXZpTWFL?=
 =?utf-8?B?dUZsOWkwbStOblNFZENNKzJnRldWRHV0Z0owVWFCMkYwMW1yOHNQSWxEODVL?=
 =?utf-8?B?WlNveDQ3c2k0YUFLUVVDWUJCd2ZGeEt3TEVVc05Fa3NyaHc1eXN0QVZ0TlRj?=
 =?utf-8?B?bE4zamxTZEpDbGJYWlB5bW53Umd1UzNCQktCMmJTenFxZ3IvdmgrT2hxa3B4?=
 =?utf-8?B?ajdmRDFVU096RnRWanhZYnlGTzNobGxvN0t0dms1WWdNQURZYTNSQ2JuMG1K?=
 =?utf-8?B?bjM0S3Y0NEF3elJyT09pbERWYVMxaDJxVW5Sb2NyVG9WUEp5R3AvUE5ZTlJJ?=
 =?utf-8?B?T3l4Q0tLZjN4YXErb09tMCtoK3EwcDhmb1U2cEN4UXJGbkVYaWFrMGJhSjJ3?=
 =?utf-8?B?WjhxSjV1RldpVGFsZm1Ld3dheXdubjZ4aDhUVFZXTEFtM3c0WVU4L2RGNmkz?=
 =?utf-8?B?MnJjT0I2N09FL0lQd1VsbGR4eXNETTNZakNlQ0VyN2Y2M2VyMmVVVm9ZNUph?=
 =?utf-8?B?WTY0MzRpc2s0dEVscCtyZHBjdllxYUxiRGxiYllJVzhKSmNiWnZUNU9Db2JV?=
 =?utf-8?B?MEVlVHFreEdFUTg0YjRnZWRUbFBCSmw3Yk0wWmZvZjdGWDF2R0FybElFZUpk?=
 =?utf-8?B?NWsrTzBBdmxabzdQaDJxSEx1ajRDWmtJYkdxL0haeU1DOUJGSm90Y2JZNUgy?=
 =?utf-8?B?UXFoSEs2VmdTWFhXUEU2b1FVZ0lQcS9xbTBOcFh5SG9BQnl2a3BDY1p5RFRa?=
 =?utf-8?B?TllSM0M2RGlxbFhvWDBCSzZVbUt3WVhDa2NoVW9aV2k4ZVVjNmRQY0J4bXNL?=
 =?utf-8?B?VGRiQXlrdGpwZjZkNTBTSGxwd204c2FOQUVLaXVHRHpvYThSbmtaV3cxbU9C?=
 =?utf-8?B?S2xsalhDZkFYWFdEQndHMnZjNGRmWXdCNUxaK0RtQ2lWSXJ0YklPNndMcFFZ?=
 =?utf-8?B?eVgva3pORytSZnU3cmo3SEh4YzhFWFdOUyszbkhQT01LakgvQVM2aUFqcFZr?=
 =?utf-8?B?Wm5HTzZKQ3h2TE93TlFuYjh3aHIwbDNMOXlYTUV5Z3NzU0FJSVZ5S0NJZ3ZY?=
 =?utf-8?B?SDhhNWp5ZkpxSGRrbWVIeEhUTmhhNk5vcUphcC9hUFNrbmwzQ2RlbU5SLzlt?=
 =?utf-8?B?UzUxY3puQlp1SjVDUzE4eUF3dlZ2MGtkNGRZUmY1YW5YVDlINnFGZHZyRVNC?=
 =?utf-8?B?R3V3QVZUeVR2STl5c0l2ajlTRXlmbVNiYkRXVlppS0JqOW5FbmVRM3oyOHA4?=
 =?utf-8?B?K3RHek1ONnkzQU5ueGdZb0lLc1lxTmVRVFBNWklXcUVVMWJYMDN2cVB4Qklw?=
 =?utf-8?B?bFFUYVVnYjBWVU9EaitjVVZHMGt1VmwrNHV3SVU0RWtWbjhOL2gvKzhNdFcy?=
 =?utf-8?B?VVhFTkp4OGJYemQ4Sk1yekE3TzlSMnF1eVliZVlEM09qZmpZU0tNdk8xV2pa?=
 =?utf-8?Q?QGB8=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: PH7PR12MB5854.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4e7b500b-33a2-4f27-d343-08ddb55c7942
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2025 09:24:53.2176
 (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: +8UgYxYcgNWVQfI91x2iWzwQ4xMviJMLV2lSFJoxMN5JwBx6qiY6HqXdrTjPn775m1a0IlfUicSesUbahpjmtQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB6024

T24gMjAyNS82LzI3IDE3OjAwLCBDaGVuLCBKaXFpYW4gd3JvdGU6DQo+IE9uIDIwMjUvNi8yNyAx
NDowNSwgSmFuIEJldWxpY2ggd3JvdGU6DQo+PiBPbiAyNy4wNi4yMDI1IDA0OjU5LCBDaGVuLCBK
aXFpYW4gd3JvdGU6DQo+Pj4gT24gMjAyNS82LzI2IDIwOjA2LCBKYW4gQmV1bGljaCB3cm90ZToN
Cj4+Pj4gT24gMjYuMDYuMjAyNSAxMDowMywgQ2hlbiwgSmlxaWFuIHdyb3RlOg0KPj4+Pj4gT24g
MjAyNS82LzI1IDIyOjA3LCBKYW4gQmV1bGljaCB3cm90ZToNCj4+Pj4+PiBPbiAyNS4wNi4yMDI1
IDEyOjE2LCBDaGVuLCBKaXFpYW4gd3JvdGU6DQo+Pj4+Pj4+IE9uIDIwMjUvNi8yNSAxODowMywg
SmFuIEJldWxpY2ggd3JvdGU6DQo+Pj4+Pj4+PiBBbHNvLCBhcyBzYWlkIC0geW91IHdpbGwgbmVl
ZCB0byBjaGVjayB3aGV0aGVyIG90aGVyIGFyY2hpdGVjdHVyZXMgYXJlDQo+Pj4+Pj4+PiBkaWZm
ZXJlbnQgZnJvbSB4ODYtNjQgaW4gdGhpcyByZWdhcmQuIFdlIGJldHRlciB3b3VsZG4ndCBsZWF2
ZSBhIHRyYXAgaGVyZSwNCj4+Pj4+Pj4+IGZvciB0aGVtIHRvIGZhbGwgaW50byB3aGVuIHRoZXkg
ZW5hYmxlIHZQQ0kgc3VwcG9ydC4gSS5lLiBteSByZWNvbW1lbmRhdGlvbg0KPj4+Pj4+Pj4gd291
bGQgYmUgdGhhdCBpZiBpbiBkb3VidCwgd2UgcHV0IHRoZSBfX2FsaWduZWQoKSB0aGVyZSB1bmNv
bmRpdGlvbmFsbHkuDQo+Pj4+DQo+Pj4+IE5vdGUgaG93IEkgdXNlZCBfX2FsaWduZWQoKSBoZXJl
LiBXaHkgd291bGQgeW91IC4uLg0KPj4+Pg0KPj4+Pj4+PiBUaGF0J3MgZGlmZmljdWx0IGZvciBt
ZSB0byBjaGVjayBvbiBhbGwgZGlmZmVyZW50IHBsYXRmb3JtcyBzaW5jZSBJIGRvbid0IGhhdmUg
dGhlbSBhbGwuDQo+Pj4+Pj4NCj4+Pj4+PiBZb3UgZG9uJ3QgbmVlZCB0byBoYXZlIHRoZW0uIFlv
dSdkIG5lZWQgdG8gY2FyZWZ1bGx5IGdvIHRocm91Z2ggdGhlIHJlc3BlY3RpdmUNCj4+Pj4+PiBz
ZWN0aW9uKHMpIG9mIHRoZWlyIHBzQUJJLXMuDQo+Pj4+Pj4NCj4+Pj4+Pj4gU28geW91IG1lYW4g
SSBzaG91bGQgcmVtb3ZlICIjaWZkZWYgQ09ORklHX1g4NiI/IEp1c3QgbGV0IF9fYWxpZ25lZCgx
NikgZm9yIGFsbCBwbGF0Zm9ybXM/DQo+Pj4+Pj4NCj4+Pj4+PiBZZXMuIEFuZCwgYXMgYWxzbyBz
YWlkLCB3aXRoIGEgc3VpdGFibGUgY29tbWVudCBwbGVhc2UuDQo+Pj4+PiBBaCwgbXkgY29tbWVu
dCBkZWZpbml0ZWx5IG5lZWRzIHlvdXIgY2hhbmdlIHN1Z2dlc3Rpb24uDQo+Pj4+PiBJIHdyb3Rl
IGEgZHJhZnQgYXMgYmVsb3c6DQo+Pj4+Pg0KPj4+Pj4gLyoNCj4+Pj4+ICAqIFNpemUgb2YgdnBj
aV9jYXBhYmlsaXR5IGlzIGxhZ2VyIHRoYW4gOCBieXRlcy4gV2hlbiBpdCBpcyB1c2VkIGFzIHRo
ZSBlbnRyeQ0KPj4+Pj4gICogb2YgX19zdGFydF92cGNpX2FycmF5IGluIHNlY3Rpb24sIGl0IGlz
IDE2LWJ5dGUgYWxpZ25lZCBieSBhc3NlbWJsZXIsIHRoYXQNCj4+Pj4+ICAqIGNhdXNlcyB0aGUg
YXJyYXkgbGVuZ3RoIChfX2VuZF92cGNpX2FycmF5IC0gX19zdGFydF92cGNpX2FycmF5KSB3cm9u
Zywgc28NCj4+Pj4+ICAqIGZvcmNlIGl0cyBkZWZpbml0aW9uIHRvIHVzZSAxNi1ieXRlIGFsaWdu
ZWQgaGVyZS4NCj4+Pj4+ICAqLw0KPj4+Pj4gc3RydWN0IHZwY2lfY2FwYWJpbGl0eSB7DQo+Pj4+
PiAgICAgdW5zaWduZWQgaW50IGlkOw0KPj4+Pj4gICAgIGJvb2wgaXNfZXh0Ow0KPj4+Pj4gICAg
IGludCAoKiBpbml0KShjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldik7DQo+Pj4+PiAgICAgaW50
ICgqIGNsZWFudXApKGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZGV2KTsNCj4+Pj4+IH0gX19hdHRy
aWJ1dGVfXygoYWxpZ25lZCgxNikpKTsNCj4+Pj4NCj4+Pj4gLi4uIG9wZW4tY29kZSB0aGF0IGhl
cmU/DQo+Pj4gVGhhdCBiZWNhdXNlIHdoZW4gdXNpbmcgX19hbGlnbmVkKCkgd2l0aG91dCBDT05G
SUdfWDg2LCBJIGdvdCBjb21waWxlIGVycm9yDQo+Pj4gdnBjaS5oOjE4OjEzOiBlcnJvcjogZXhw
ZWN0ZWQgZGVjbGFyYXRpb24gc3BlY2lmaWVycyBvciDigJguLi7igJkgYmVmb3JlIG51bWVyaWMg
Y29uc3RhbnQNCj4+PiAgICAxOCB8IH0gX19hbGlnbmVkKDE2KTsNCj4+PiAgICAgICB8ICAgICAg
ICAgICAgIF5+DQo+Pj4gSSB0cmllZCBzb21lIG1ldGhvZHMsIG9ubHkgb3Blbi1jb2RlIGNhbiBm
aXggaXQuDQo+Pg0KPj4gV2VsbCwgdGhhdCdzIG9kZC4gSW4gZS5nLiB4ZW4vc2NoZWQuaCB3ZSBo
YXZlDQo+Pg0KPj4gc3RydWN0IGRvbWFpbg0KPj4gew0KPj4gICAgIC4uLg0KPj4gfSBfX2FsaWdu
ZWQoUEFHRV9TSVpFKTsNCj4+DQo+PiB3aGljaCBjbGVhcmx5IG11c3QgYmUgd29ya2luZyBmaW5l
LiBUaGUgZXJyb3IgbWVzc2FnZSBmcm9tIHRoZSBjb21waWxlcg0KPj4gZG9lc24ndCBzYXkgdmVy
eSBtdWNoIGFsb25lLiBGb3IgaW5mb3JtYXRpb25hbCBkaWFnbm9zdGljcyB0aGUgY29tcGlsZXIN
Cj4+IG5vcm1hbGx5IGFsc28gZW1pdHMgbWF5IGhlbHAsIG9yIGVsc2UgaXQgd291bGQgdGFrZSBs
b29raW5nIGF0IHRoZQ0KPj4gcHJlLXByb2Nlc3NlZCBvdXRwdXQgdG8gdW5kZXJzdGFuZCB3aGF0
J3MgZ29pbmcgb24gaGVyZS4NCj4gDQo+IEkgYWRkIHNvbWUgY29kZXMgdG8gcHJpbnQgdGhlIG1h
Y3JvIF9fYWxpZ24sIHRoZSBjb2RlcyBhcmU6DQo+IA0KPiBkaWZmIC0tZ2l0IGEveGVuL2luY2x1
ZGUveGVuL3ZwY2kuaCBiL3hlbi9pbmNsdWRlL3hlbi92cGNpLmgNCj4gaW5kZXggNTE1NzNiYWFi
Yy4uOGY2YWYxYzgyMiAxMDA2NDQNCj4gLS0tIGEveGVuL2luY2x1ZGUveGVuL3ZwY2kuaA0KPiAr
KysgYi94ZW4vaW5jbHVkZS94ZW4vdnBjaS5oDQo+IEBAIC0xMywxMiArMTMsMTYgQEAgdHlwZWRl
ZiB1aW50MzJfdCB2cGNpX3JlYWRfdChjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldiwgdW5zaWdu
ZWQgaW50IHJlZywNCj4gIHR5cGVkZWYgdm9pZCB2cGNpX3dyaXRlX3QoY29uc3Qgc3RydWN0IHBj
aV9kZXYgKnBkZXYsIHVuc2lnbmVkIGludCByZWcsDQo+ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHVpbnQzMl90IHZhbCwgdm9pZCAqZGF0YSk7DQo+IA0KPiArI2RlZmluZSBTVFJJTkdJRlko
eCkgI3gNCj4gKyNkZWZpbmUgVE9TVFJJTkcoeCkgU1RSSU5HSUZZKHgpDQo+ICsjcHJhZ21hIG1l
c3NhZ2UoIl9fYWxpZ25lZCgxNikgZXhwYW5kcyB0bzogIiBUT1NUUklORyhfX2FsaWduZWQoMTYp
KSkNCj4gKw0KPiAgc3RydWN0IHZwY2lfY2FwYWJpbGl0eSB7DQo+ICAgICAgdW5zaWduZWQgaW50
IGlkOw0KPiAgICAgIGJvb2wgaXNfZXh0Ow0KPiAgICAgIGludCAoKiBpbml0KShjb25zdCBzdHJ1
Y3QgcGNpX2RldiAqcGRldik7DQo+ICAgICAgaW50ICgqIGNsZWFudXApKGNvbnN0IHN0cnVjdCBw
Y2lfZGV2ICpwZGV2KTsNCj4gfSBfX2FsaWduZWQoMTYpOw0KPiANCj4gVGhlIHJlc3VsdCBhcmU6
DQo+IA0KPiBJbiBmaWxlIGluY2x1ZGVkIGZyb20gLi9pbmNsdWRlL3hlbi9zY2hlZC5oOjI1LA0K
PiAgICAgICAgICAgICAgICAgIGZyb20gYXJjaC94ODYveDg2XzY0L2FzbS1vZmZzZXRzLmM6MTE6
DQo+IC4vaW5jbHVkZS94ZW4vdnBjaS5oOjE4Ojk6IG5vdGU6IOKAmCNwcmFnbWEgbWVzc2FnZTog
X19hbGlnbmVkKDE2KSBleHBhbmRzIHRvOiBfX2F0dHJpYnV0ZV9fKChfX2FsaWduZWRfXygxNikp
KeKAmQ0KPiAgICAxOCB8ICNwcmFnbWEgbWVzc2FnZSgiX19hbGlnbmVkKDE2KSBleHBhbmRzIHRv
OiAiIFRPU1RSSU5HKF9fYWxpZ25lZCgxNikpKQ0KPiAgICAgICB8ICAgICAgICAgXn5+fn5+fg0K
PiBJbiBmaWxlIGluY2x1ZGVkIGZyb20gLi9pbmNsdWRlL3hlbi9zY2hlZC5oOjI1LA0KPiAgICAg
ICAgICAgICAgICAgIGZyb20gZHJpdmVycy92cGNpL3ZwY2kuYzoyMDoNCj4gLi9pbmNsdWRlL3hl
bi92cGNpLmg6MTg6OTogbm90ZTog4oCYI3ByYWdtYSBtZXNzYWdlOiBfX2FsaWduZWQoMTYpIGV4
cGFuZHMgdG86IF9fYXR0cmlidXRlX18oKF9fYWxpZ25lZF9fKDE2KSkp4oCZDQo+ICAgIDE4IHwg
I3ByYWdtYSBtZXNzYWdlKCJfX2FsaWduZWQoMTYpIGV4cGFuZHMgdG86ICIgVE9TVFJJTkcoX19h
bGlnbmVkKDE2KSkpDQo+ICAgICAgIHwgICAgICAgICBefn5+fn5+DQo+IEluIGZpbGUgaW5jbHVk
ZWQgZnJvbSBlbXVsLmg6ODgsDQo+ICAgICAgICAgICAgICAgICAgZnJvbSB2cGNpLmM6MTg6DQo+
IHZwY2kuaDoxNTo5OiBub3RlOiDigJgjcHJhZ21hIG1lc3NhZ2U6IF9fYWxpZ25lZCgxNikgZXhw
YW5kcyB0bzogX19hbGlnbmVkKDE2KeKAmQ0KPiAgICAxNSB8ICNwcmFnbWEgbWVzc2FnZSgiX19h
bGlnbmVkKDE2KSBleHBhbmRzIHRvOiAiIFRPU1RSSU5HKF9fYWxpZ25lZCgxNikpKQ0KPiAgICAg
ICB8ICAgICAgICAgXn5+fn5+fg0KPiB2cGNpLmg6MjI6MTM6IGVycm9yOiBleHBlY3RlZCBkZWNs
YXJhdGlvbiBzcGVjaWZpZXJzIG9yIOKAmC4uLuKAmSBiZWZvcmUgbnVtZXJpYyBjb25zdGFudA0K
PiAgICAyMiB8IH0gX19hbGlnbmVkKDE2KTsNCj4gICAgICAgfCAgICAgICAgICAgICBefg0KPiBJ
biBmaWxlIGluY2x1ZGVkIGZyb20gZW11bC5oOjg4LA0KDQpBaCwgdGhlIHJvb3QgY2F1c2UgaXMg
dGhhdCBJIG5lZWQgdG8gYWRkIGNvbXBpbGVyLmggdG8gdGVzdHMgZGlyZWN0b3J5IHRvb2xzL3Rl
c3RzL3ZwY2kvDQpMaWtlIGJlbG93LCBidXQgd2Ugd2lsbCB1c2UgeW91ciBwYXRjaCwgc28gdGhp
cyBwcm9ibGVtIGlzIG5vdCBpbXBvcnRhbnQuDQpkaWZmIC0tZ2l0IGEvdG9vbHMvdGVzdHMvdnBj
aS9NYWtlZmlsZSBiL3Rvb2xzL3Rlc3RzL3ZwY2kvTWFrZWZpbGUNCmluZGV4IDk3MzU5ZmY2N2Yu
LjExZGUzNDFhYjkgMTAwNjQ0DQotLS0gYS90b29scy90ZXN0cy92cGNpL01ha2VmaWxlDQorKysg
Yi90b29scy90ZXN0cy92cGNpL01ha2VmaWxlDQpAQCAtMTQsMTIgKzE0LDEyIEBAIGVsc2UNCiAg
ICAgICAgJCh3YXJuaW5nIEhPU1RDQyAhPSBDQywgd2lsbCBub3QgcnVuIHRlc3QpDQogZW5kaWYN
Cg0KLSQoVEFSR0VUKTogdnBjaS5jIHZwY2kuaCBsaXN0LmggbWFpbi5jIGVtdWwuaA0KKyQoVEFS
R0VUKTogdnBjaS5jIHZwY2kuaCBsaXN0LmggbWFpbi5jIGVtdWwuaCBjb21waWxlci5oDQogICAg
ICAgICQoQ0MpICQoQ0ZMQUdTX3hlbmluY2x1ZGUpIC1nIC1vICRAIHZwY2kuYyBtYWluLmMNCg0K
IC5QSE9OWTogY2xlYW4NCiBjbGVhbjoNCi0gICAgICAgcm0gLXJmICQoVEFSR0VUKSAqLm8gKn4g
dnBjaS5oIHZwY2kuYyBsaXN0LmgNCisgICAgICAgcm0gLXJmICQoVEFSR0VUKSAqLm8gKn4gdnBj
aS5oIHZwY2kuYyBsaXN0LmggY29tcGlsZXIuaA0KDQogLlBIT05ZOiBkaXN0Y2xlYW4NCiBkaXN0
Y2xlYW46IGNsZWFuDQpAQCAtMzgsNiArMzgsNyBAQCB2cGNpLmM6ICQoWEVOX1JPT1QpL3hlbi9k
cml2ZXJzL3ZwY2kvdnBjaS5jDQogICAgICAgIHNlZCAtZSAnLyNpbmNsdWRlL2QnIC1lICcxcy9e
LyNpbmNsdWRlICJlbXVsLmgiLycgPCQ8ID4kQA0KDQogbGlzdC5oOiAkKFhFTl9ST09UKS94ZW4v
aW5jbHVkZS94ZW4vbGlzdC5oDQorY29tcGlsZXIuaDogJChYRU5fUk9PVCkveGVuL2luY2x1ZGUv
eGVuL2NvbXBpbGVyLmgNCiB2cGNpLmg6ICQoWEVOX1JPT1QpL3hlbi9pbmNsdWRlL3hlbi92cGNp
LmgNCi1saXN0LmggdnBjaS5oOg0KK2xpc3QuaCBjb21waWxlci5oIHZwY2kuaDoNCiAgICAgICAg
c2VkIC1lICcvI2luY2x1ZGUvZCcgPCQ8ID4kQA0KDQo+ICAgICAgICAgICAgICAgICAgZnJvbSBt
YWluLmM6MTk6DQo+IHZwY2kuaDoxNTo5OiBub3RlOiDigJgjcHJhZ21hIG1lc3NhZ2U6IF9fYWxp
Z25lZCgxNikgZXhwYW5kcyB0bzogX19hbGlnbmVkKDE2KeKAmQ0KPiAgICAxNSB8ICNwcmFnbWEg
bWVzc2FnZSgiX19hbGlnbmVkKDE2KSBleHBhbmRzIHRvOiAiIFRPU1RSSU5HKF9fYWxpZ25lZCgx
NikpKQ0KPiAgICAgICB8ICAgICAgICAgXn5+fn5+fg0KPiB2cGNpLmg6MjI6MTM6IGVycm9yOiBl
eHBlY3RlZCBkZWNsYXJhdGlvbiBzcGVjaWZpZXJzIG9yIOKAmC4uLuKAmSBiZWZvcmUgbnVtZXJp
YyBjb25zdGFudA0KPiAgICAyMiB8IH0gX19hbGlnbmVkKDE2KTsNCj4gICAgICAgfCAgICAgICAg
ICAgICBefg0KPiBtYWtlWzZdOiAqKiogW01ha2VmaWxlOjE4OiB0ZXN0X3ZwY2ldIEVycm9yIDEN
Cj4gbWFrZVs1XTogKioqIFsvaG9tZS9janEvY29kZS91cHN0cmVhbS94ZW4vdG9vbHMvdGVzdHMv
Li4vLi4vdG9vbHMvUnVsZXMubWs6MTk0OiBzdWJkaXItaW5zdGFsbC12cGNpXSBFcnJvciAyDQo+
IG1ha2VbNF06ICoqKiBbL2hvbWUvY2pxL2NvZGUvdXBzdHJlYW0veGVuL3Rvb2xzL3Rlc3RzLy4u
Ly4uL3Rvb2xzL1J1bGVzLm1rOjE4OTogc3ViZGlycy1pbnN0YWxsXSBFcnJvciAyDQo+IG1ha2Vb
M106ICoqKiBbL2hvbWUvY2pxL2NvZGUvdXBzdHJlYW0veGVuL3Rvb2xzLy4uL3Rvb2xzL1J1bGVz
Lm1rOjE5NDogc3ViZGlyLWluc3RhbGwtdGVzdHNdIEVycm9yIDINCj4gbWFrZVsyXTogKioqIFsv
aG9tZS9janEvY29kZS91cHN0cmVhbS94ZW4vdG9vbHMvLi4vdG9vbHMvUnVsZXMubWs6MTg5OiBz
dWJkaXJzLWluc3RhbGxdIEVycm9yIDINCj4gbWFrZVsxXTogKioqIFtNYWtlZmlsZTo2NDogaW5z
dGFsbF0gRXJyb3IgMg0KPiBtYWtlOiAqKiogW01ha2VmaWxlOjE0NzogaW5zdGFsbC10b29sc10g
RXJyb3IgMg0KPiBtYWtlOiAqKiogV2FpdGluZyBmb3IgdW5maW5pc2hlZCBqb2JzLi4uLg0KPiAN
Cj4+DQo+Pj4+IEFzIHRvIHRoZSBjb21tZW50OiBGaXJzdCwgaXQgd2FudHMgdG8gYmUgYXMgY2xv
c2UgdG8gd2hhdCBpcyBiZWluZyBjb21tZW50ZWQgYXMNCj4+Pj4gcG9zc2libGUuIEhlbmNlDQo+
Pj4+DQo+Pj4+IHN0cnVjdCBfX2FsaWduZWQoMTYpIHZwY2lfY2FwYWJpbGl0eSB7DQo+Pj4gVGhp
cyBhbHNvIGdvdCB0aGUgY29tcGlsZSBlcnJvci4NCj4+Pj4NCj4+Pj4gaXMgbGlrZWx5IHRoZSBi
ZXR0ZXIgcGxhY2VtZW50LiBTZWNvbmQsIHRoZXJlJ3Mgbm90aGluZyBoZXJlIHRoZSBhc3NlbWJs
ZXIgZG9lcw0KPj4+PiBvbiBpdHMgb3duLiBJdCdzIHRoZSBjb21waWxlciB3aGljaCBkb2VzIHNv
bWV0aGluZyAoaW5zZXJ0IGFsaWdubWVudCBkaXJlY3RpdmVzKSwNCj4+Pj4gYW5kIG9ubHkgdG8g
Zm9sbG93IGNlcnRhaW4gcnVsZXMuIChTZWUgIng4NjogZG9uJ3QgaGF2ZSBnY2Mgb3Zlci1hbGln
biBkYXRhIg0KPj4+PiB0aGF0IEkgQ2MtZWQgeW91IG9uIGZvciBzb21lIG9mIHRoZSByZWxldmFu
dCBhc3BlY3RzLikgVGhhdCBpcywgeW91IGRvbid0IHdhbnQNCj4+Pj4gdG8gImJsYW1lIiBhbnkg
cGFydCBvZiB0aGUgdG9vbCBjaGFpbiwgYXQgbGVhc3Qgbm90IHdoZXJlIGl0J3MgdGhlIHVuZGVy
bHlpbmcNCj4+Pj4gQUJJIHRoYXQgbWFuZGF0ZXMgY2VydGFpbiBiZWhhdmlvci4gVGhlcmUncyBh
bHNvIG5vIHN0cm9uZyBuZWVkIHRvIHRhbGsgYWJvdXQNCj4+Pj4gdGhlIHNwZWNpZmljIGVmZmVj
dHMgdGhhdCBpdCB3b3VsZCBoYXZlIGlmIHdlIGRpZG4ndCBhcnJhbmdlIHRoaW5ncyBwcm9wZXJs
eS4NCj4+Pj4gVGhhdCBpcywgdGFsa2luZyBhYm91dCB0aGUgZWZmZWN0IG9uIGFycmF5cyBpbiBn
ZW5lcmFsIGlzIGZpbmUgYW5kIGhlbHBmdWwuDQo+Pj4+IFRhbGtpbmcgYWJvdXQgX197c3RhcnQs
ZW5kfV92cGNpX2FycmF5IGltbyBpcyBub3QuDQo+Pj4+DQo+Pj4+IFdoaWxlIGZ1cnRoZXIgcGxh
eWluZyB3aXRoIHRoZSBjb21waWxlciwgSSBub3RpY2VkIHRoYXQgYWRkaW5nIF9fYWxpZ25lZCgx
NikNCj4+Pj4gYWN0dWFsbHkgaGFzIGEgbmVnYXRpdmUgZWZmZWN0IGFzIGxvbmcgYXMgdGhhdCBv
dGhlciBwYXRjaCBpc24ndCBpbiB1c2U6IFRoZQ0KPj4+PiBzdHJ1Y3QgaW5zdGFuY2VzIHRoZW4g
YXJlIGJlaW5nIGFsaWduZWQgdG8gZXZlbiAzMi1ieXRlIGJvdW5kYXJpZXMgKHdoaWNoIG1lYW5z
DQo+Pj4+IF9fc3RhcnRfdnBjaV9hcnJheSB3b3VsZCB0aGVuIGFsc28gbmVlZCBhbGlnbmluZyBh
cyBtdWNoKS4gV2hlbiB0aGF0IG90aGVyDQo+Pj4+IHBhdGNoIGlzIGluIHVzZSwgdGhlIF9fYWxp
Z25lZCgpIGJlY29tZXMgdW5uZWNlc3NhcnkuIFRoZXJlZm9yZSBJJ20gbm8gbG9uZ2VyDQo+Pj4+
IGNvbnZpbmNlZCB1c2luZyBfX2FsaWduZWQoKSBpcyB0aGUgYmVzdCBzb2x1dGlvbiBoZXJlLg0K
Pj4+IEVtLCBjaGFuZ2luZyBfX3N0YXJ0X3ZwY2lfYXJyYXkgdG8gYmUgc3RydWN0IHZwY2lfY2Fw
YWJpbGl0eSBhcnJheSBjYXVzZSB0aG9zZSBjb25jZXJucywgbWF5YmUga2VlcGluZyB1c2luZyBz
dHJ1Y3QgcG9pbnRlciBpcyBhIGNvbXByb21pc2UgbWV0aG9kLg0KPj4NCj4+IEl0IHdvdWxkIGJl
IGEgbGFzdCByZXNvcnQsIHllcywgYnV0IGltbyAoYSkgd2Ugb3VnaHQgdG8gc3RyaXZlIHRvIGF2
b2lkDQo+PiB1bm5lY2Vzc2FyeSBpbmRpcmVjdGlvbiBhbmQgKGIpIHRoZSBzYW1lIHVuZGVybHlp
bmcgaXNzdWUgY291bGQgYmVjb21lIGENCj4+IHByb2JsZW0gZWxzZXdoZXJlIGFzIHdlbGwuDQo+
Pg0KPj4gSmFuDQo+IA0KDQotLSANCkJlc3QgcmVnYXJkcywNCkppcWlhbiBDaGVuLg0K


From xen-devel-bounces@lists.xenproject.org Fri Jun 27 09:46:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 09:46:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027463.1402092 (Exim 4.92)
	(envelope-from )
	id 1uV5ec-00029S-Eo; Fri, 27 Jun 2025 09:45:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027463.1402092; Fri, 27 Jun 2025 09:45: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 1uV5ec-00029L-B0; Fri, 27 Jun 2025 09:45:54 +0000
Received: by outflank-mailman (input) for mailman id 1027463;
 Fri, 27 Jun 2025 09:45: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 1uV5ea-00029F-JQ
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 09:45:52 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on2062b.outbound.protection.outlook.com
 [2a01:111:f403:2414::62b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 81d1df37-533b-11f0-b894-0df219b8e170;
 Fri, 27 Jun 2025 11:45:50 +0200 (CEST)
Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
 by SA5PPF7F0CA3746.namprd12.prod.outlook.com
 (2603:10b6:80f:fc04::8d1) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.19; Fri, 27 Jun
 2025 09:45:47 +0000
Received: from PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264]) by PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264%4]) with mapi id 15.20.8880.021; Fri, 27 Jun 2025
 09:45: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: 81d1df37-533b-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ZtBlBujmc8Qj0843bEWBJcLbUSl28NJfLBiMBCpICEK+MjlT9pRpGC9iRntKQUG8ATtnnLtMO8lLvMMr0eWQIEsI1+y/aWOPjOU3H1MdtMVOAtgcMKZ5gVbuNFxcewZhpiBErh31wHVssBkMbiByAuZ4dyX7FO4s84iR0fYwEyxtIwSoCH8PRchAfDI9Om8GGi4wg3wTwiIl1IxjvXZX59t0koCwMVZktQYi2Hlkl+7EbXdGkVOPdhAhd2pxhPDOQHjjtwKNU7WlhcWjlaXLoaNm/staypVj3N+J/ca0NbgI+GiH9Xa3RoKiOYMSDm6XPmjoUngvX6oduxnqYLijKg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Zp1T56vdfDLeGsSCs4+c5SbFfzuggScv3Ukf+R6U4+4=;
 b=xvZlgkvrlEqANMe6Yks2keNg1JWFDqUJZ49ZxocC3Vt/4cGnD4Hhdy2J3iJngqoYUe4x5sduD3XHRa7Oqs7UWcTuVeAudOBROax3HQB8UQKtSvK1kO0gi1PoqsW7xZjMV8ja25tsR1MAYdfrd9tjm8a3NSDPvJMNFQdMLCmCsoWsB1i9MHt+Wpn4YrXeI2uPTsKvYU8PsCHXMb5SEGcGe2ZD6HiEY8EFlGERzpHfXtXPHkzoKXmyEmzzxJUsg+7dTljWWMITcLcVGTX14jI3n93oP8geZYFQ/X9CqpuJpHPnM+aYsEi/FN7hD2TgZcpY1ggxee23HZjI9u9jNjEX6Q==
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=Zp1T56vdfDLeGsSCs4+c5SbFfzuggScv3Ukf+R6U4+4=;
 b=bl1se0+DBZfjA+QNGzejCXU2UdY/pWGSaq1k7d4gWcUH2ysYUp1I966YhcOBtA56tg66kuF8FhHfrB5G059hPKQ8AW9puDBw+WuGRtSgfbqUuRhxx07TEdbwCvXAuwMfmbIn45BPwiMIRNKKTW/y0SmiVqG6NOB2mo9bH59NrrU=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Fri, 27 Jun 2025 10:45:43 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/arm: Drop frametable_virt_end
To: Michal Orzel , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250627084334.45172-1-michal.orzel@amd.com>
Content-Language: en-GB
From: Ayan Kumar Halder 
In-Reply-To: <20250627084334.45172-1-michal.orzel@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: DB8PR06CA0004.eurprd06.prod.outlook.com
 (2603:10a6:10:100::17) To PH8PR12MB7326.namprd12.prod.outlook.com
 (2603:10b6:510:216::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|SA5PPF7F0CA3746:EE_
X-MS-Office365-Filtering-Correlation-Id: 45dae592-7957-44a4-2cd7-08ddb55f6432
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?ZnlPMTJMMWhiUDNTL0hnaC9uRGh1TlR6QlFRSEJpamJ3QTg3bXNWN09vUzJT?=
 =?utf-8?B?K29NUUp6WDAwY21HcCt6Q2pCRy96aTZpY3pjbXUza3kzQUVuVjRNRytTbkJn?=
 =?utf-8?B?Qnh3a09nemFBN3F6SHB2cm5yem5rWk9qVzJhMGVzdE1aVEZkNjZDbjhWZWFo?=
 =?utf-8?B?cUJWdXlQVFF1TGppYnVEVlhaV0tQcUk1S05XNlQ4SWZWQjA4RzV3SmRoeWlo?=
 =?utf-8?B?a0JmK1ArRVJwQ29FRVlnMUt5dUZ6eHQ3R21ZemNBZkxEU2UvQUlMZEhsV21o?=
 =?utf-8?B?d3lVa0ZqZmV2d0FTTVdmei84NHBLZFgyY0Z5M1pUZXFlNGRhNXdRcHRiV2gy?=
 =?utf-8?B?SWtKYXJhSWVWMG9EVDZVZmZWQXM3UUp6bFBiRld6Q1R3bFpTVnJENVI1RWZ2?=
 =?utf-8?B?T2RhMk0vaFU2Y2NwVDg3UXZvWHRhL1lFYzh3RWdDTDBzM3ZnNlh1alFuU2xj?=
 =?utf-8?B?dVlSNjZ6Z1BmVjlNK3U3SUMvaVNib09scFdFVEU1dHc0R3MrYkx2aGFSZ1VB?=
 =?utf-8?B?bGpKZGFXWGN1Y0s0azI4bnF6YzgvZ2JwMEtWM081SU9INnJ1ZnBXSlk1b0hv?=
 =?utf-8?B?R2RVT1EzODZtTlZ1dWd4Z3ltVFMza1pscm5HZTUvWG5qSHdrYWpGZUZjVFBo?=
 =?utf-8?B?aWF6YVY3dysyTnhnblNIVXpnYjY3eGZ6ZXJGeFRQNnpBQldIN3NMSlcyMmdE?=
 =?utf-8?B?MDJjVjNhY3o1alBGbXkzaklPYkZrS0VOMURYY3hVc0F0ckg0ZXlxdHpxK0tv?=
 =?utf-8?B?NCtpS3F2eVJnYjN1MFhVU28rblluSzUwQ0hRZy9YSFRSZkQyNUdqZnpSdUMr?=
 =?utf-8?B?RHB1bUVQSFBxalk4UXhQa3BjNEpTbEx3Z3AvdTkxd3RNcmpsNlRWK1dsbExZ?=
 =?utf-8?B?bXBIQ1k1NnBMenkrZ0psalNUd3hYbG50ekx5TnlkTDgwZy9mTDZEYUJ3OXR4?=
 =?utf-8?B?cWxESlBPd3JTOHQzMmZ4VHN4bFQxRm5ieEJObTkvc0ZHS3dNTFF6RDgrSmJJ?=
 =?utf-8?B?SnAvNVFsNnNEUjhSc3ZXcmx2QlhDb3N2NGFydVVZS0xIVHN1Tk9wcDdSbkRn?=
 =?utf-8?B?TzYrYkphNXpFNHdVeW01Tm55NG5oSWZ0czFJSFZPbi9rSklyVHd6RU8wbTl1?=
 =?utf-8?B?dnZQeHhoL0ozU3NuU0dyM2dTeGdWc1RPbXdOd0l1djdGOGJobHEyTEsyQ1VC?=
 =?utf-8?B?ejUyWnVHOWVpV285OGhLL21vVUtYSmtNTVpGZG85cGRTRk5HcWR3aWdVQ3hO?=
 =?utf-8?B?SGJFOXFWU3IrZ094bE5nMmZBQ3E4aDc4QUh0QmlxbWxCZ3EzTTBYemxNTjdF?=
 =?utf-8?B?OGhNeC9zVStBOVMvdGgzOHBTVkRXL2dUdDA0d3FML1FhZ0ZEZS9EaW8xRjlH?=
 =?utf-8?B?R2k2UEdMTUw0UXRmbGhzQm5vVllxaE1tbmlzUEpGYU84aEZ4VUNGeHFHQWN2?=
 =?utf-8?B?dGhETHFmRGxRNUN5L3gwTTZiWVJ1TmdoS3VnRnN1TzQ3UXNOeSt3cGlwYWlO?=
 =?utf-8?B?eGJnVHI0M0hSaXJJY0s2SmhuTmdPanBsdWlaVThPYnlMb3A1RVNzSGs2eU9U?=
 =?utf-8?B?N0VCL1VpTkNxdDRjOFZDdy9pN2lYNFZVUGI1LzJXMGE4SExwYkRjUkhmbWNL?=
 =?utf-8?B?SlhFcW5NRGk2aDNVL0MwMzhQMmx2Vy9kWEtqRFVKMFk3WXMrMGNnQ0pVVFpy?=
 =?utf-8?B?SUx3Z1dGemFUWjIzdU9BS3JlS0k2WEI4NjAyOGthdS9NeXdDZ1BKekxhZWZl?=
 =?utf-8?B?YUxUb3NPWjVJV0pwelVpOHNlVVJYVm5lbGpFOExuS1Y3ZFhRYkQ4N3dTeU4x?=
 =?utf-8?B?VEJoZ1VsVzdzVVJ1YUtvaFYwVG42SjBqYXQ5eFlrM0dhdHllajcrcStsTXBZ?=
 =?utf-8?B?c042NFl6SWs4a2VvUTcvRDhidWMwNWJMQzRmY3NNLzY5OFVkVUIvR1BlMTZ4?=
 =?utf-8?Q?MOUKzS6fcLI=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)(1800799024)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?bkMvWkNubzl6SzhvT24vRDg3Z2Fkd1RUUHB2MWFrSXNteWd5ZHpYOU9tU1Iz?=
 =?utf-8?B?TU9EeXhqNm9Ud25xYXZZcVVyOTFUWnpCdzhUUnNQNzVVNndUR1E2N1I4L0du?=
 =?utf-8?B?emc4dlBEMVpTMkFUWFd3em9hN3BmT2M4SHNvQjBHaTIyTGhHNFVMcUg4Rll2?=
 =?utf-8?B?WEViMmtRQ0hJQXBPaDU4RHgrQUQxVldjQnJHZkdzQkJRbnRRMkxCcFFLN2Ns?=
 =?utf-8?B?UytlRXVxL3k1b0NKSVdBLy96MUQ5bVgwczdkU0cyOUpJZ2ovRGFHL3gyL2h5?=
 =?utf-8?B?OGRjbkx5b0FwbWtWNENRNWJacmNZWHZBL1hDbGQvVm5ibUc4cWhTVGMzUitX?=
 =?utf-8?B?UVNvWkwwa0JEOFVoRER2Nlk3VGxCM0xJbFRCZk5JUlRVVmJoUXZhK0I4SGE3?=
 =?utf-8?B?WHowNnM2MmJjU0FLOGE1UmRTSndSbm0rd3JPNVVBZ1NMZlp2cjZiYkZyeFhQ?=
 =?utf-8?B?Z0ZNa29nVEF0dkZvSGZodktXMFRmb3kvTXNYT1FSeHk1VVd6cHNHMWtRR3Uy?=
 =?utf-8?B?S1JVQjlLQXFkdnI1bi9HV3lOWW4ydjRMR2J3d2oyL0lLNTl3VDhMdHNzS0tI?=
 =?utf-8?B?dnVwUm10cVRVRHBKZGZoRmx6QXVONkx0R2NrNVhZcUdtbVRLdXRTazJRV3l3?=
 =?utf-8?B?blg3MlBuYzNxUFduUFVaOWFGSlc0WWNwa0xxY0dyWXJxcVZ2K0JGb0JFaTgw?=
 =?utf-8?B?UldmL1BUM0E1R3FFcW5kMXVJVm5ySmxTenZReTFqeXVjY3JidXplSERCZ0k2?=
 =?utf-8?B?b1dXMGxpVy81VElnOU8yZW9lSnhvY2NkY0diTVV5ZW9KSnpvWnphaWFHaXNZ?=
 =?utf-8?B?QWRSNSttYUQ2L3hGSlhQaEdYczJnTXo5cGI4YUY5ZnJybWlGaDIxdUEvUWJX?=
 =?utf-8?B?VXI0dmNkRndlZ09MS1ZlUEovQWw1RmZXdU0xcWNCOFpIYTRJdXJVaC96TWx5?=
 =?utf-8?B?ejJyNkhUcUE3TlRkQnQ0RktzclNSUnpvUnJvZndQbWxlSk9FM3VvbUtNK2JQ?=
 =?utf-8?B?VmNvNVRqVElhb05xdmswVEdMalU2TXB0SzhwdEZDTDZnNHRkNStBcnVESGlJ?=
 =?utf-8?B?Y0Z1SHdRZVlyeVZCOXF4bzdKaTVtUDV5NENrSkRyN1hWeDZuVE1BTFQ1ZXRM?=
 =?utf-8?B?bGRJTGxWREVxZmJsK1RyaFl5T2J6dGR4b2U0V2hLQTVOMjljcnAxVkRCTDQv?=
 =?utf-8?B?R2IyUW8wNDZkNUNTMGhLSFFXYVVWZFJEK0ZLc3NFSDZad0I4by8yRFZFY3d6?=
 =?utf-8?B?UnBsdnUxci83SktPM0JWOGlvMy9VWTNkZzdmRXc0b282RFBzNnVPNXh1N2hi?=
 =?utf-8?B?WThEelZLb2JrUzhSZTU4alcvM2xwc3JzUjdTWFBHSEtWWFBZZkNIRHVMeUZT?=
 =?utf-8?B?L005anpkUTZhUzFaeGJMdVd3VmJHWUxxR3lFWG15MGs4Q1VqZGREckxleEpM?=
 =?utf-8?B?NEJmblIrUVl2MlN2Ny9EYTh3eC90OHFQYjArS0ZQbUZTb3NXeUhyUkllUXNh?=
 =?utf-8?B?UjA0OEplRnZkTk5VNVlJakFkaUJvcTYvOE81NVF0eGZacit0OVJjcUJqc2k2?=
 =?utf-8?B?SFA0aCtFNG5pdmgrc01hUzVNdnFQV1l1RThsbVFhQU5mNjl3b2RmNTQrSk5m?=
 =?utf-8?B?MmRxVFNwWGpUNjEyN0JONXJRWEZJcmlaYk83cHlRWDJIRFZlUW5vZ1YzTm15?=
 =?utf-8?B?UzZuTCtBTlVDSEpYZDVTUTgxU2t2S2FEV3ZqZjJ2S29tVkZHSG5MZTByWmNu?=
 =?utf-8?B?N3RnaWs4RWU3VUtWbUJrTndsWm5PWkJiUjFUSVRacVphUFI5OUNjSXYrNFBQ?=
 =?utf-8?B?NWMyQkxNZjhEVFI4bXM1UTlVUFkrSE9rZVJKZmJQOUNLY3BJc3RlKzU0Slk1?=
 =?utf-8?B?amgyQkNkNjJqemNnYWJVVE1OQ1dhakF1SkNyR1dKVitkRnhYSnVRZ1FROERZ?=
 =?utf-8?B?b3U1eDdxbyttMUlobUpGNHZETElibWs4Mkh0aXArMk10djgvUFVoTFRLeE1r?=
 =?utf-8?B?aStsbTExY3FWZ1lKUzgxWFFPVEhRZzI5L3p0S1lrem9Oc1o3YUJKbEs0UlBM?=
 =?utf-8?B?eFRBd1lUa1gwclJZOG9EM3RHdzg5S0sxUnJxMkFsaG9zV0UzS3N3dnVqSS9R?=
 =?utf-8?Q?QUFMKM0//C7SwAcn6Bv6n5NLG?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 45dae592-7957-44a4-2cd7-08ddb55f6432
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jun 2025 09:45:46.5651
 (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: PKQQ8eSGYN8hlmKWrGtqxFO43MKqPrW/eaaf4nRpzHszgf2YuWB+V4Alb7/nlN80nqeuKMS1Sq6n42BiTk5PGA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA5PPF7F0CA3746

Hi Michal,

On 27/06/2025 09:43, Michal Orzel wrote:
> It has never been used since the introduction and is technically a dead
> code violating MISRA C.
>
> Signed-off-by: Michal Orzel 

Reviewed-by: Ayan Kumar Halder 

- Ayan


From xen-devel-bounces@lists.xenproject.org Fri Jun 27 10:42:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 10:42:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027498.1402101 (Exim 4.92)
	(envelope-from )
	id 1uV6XN-00015r-Ac; Fri, 27 Jun 2025 10:42:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027498.1402101; Fri, 27 Jun 2025 10:42: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 1uV6XN-00015k-7o; Fri, 27 Jun 2025 10:42:29 +0000
Received: by outflank-mailman (input) for mailman id 1027498;
 Fri, 27 Jun 2025 10:42: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 1uV6XL-00015e-AJ
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 10:42:27 +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 67af7993-5343-11f0-b894-0df219b8e170;
 Fri, 27 Jun 2025 12:42:21 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a57ae5cb17so1180964f8f.0
 for ; Fri, 27 Jun 2025 03:42:21 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-315f5384140sm6918745a91.7.2025.06.27.03.42.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 27 Jun 2025 03:42:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 67af7993-5343-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1751020941; x=1751625741; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=RAUu45byWCYVeJgWLJnBZx5xF7D8AMI7j46sDoUddT0=;
        b=GqunyKdgK0YAwDc/1bShdWcugAMh2SEmqoiPYad8RGI3mqNJS/KJgqU7ceSzoyXNpn
         EONSnaTDgIaj6CWrlWSvdqeIKnm8NpIvHuCChf11kK/PoYSuMEXJJ937Uuw/0XjMHD5j
         zAwPBLav81c/hYv53F88sG0IFWYoDr/0YIxhPia+wuAYSTW4rWedll7kLyGf/Z+YETvu
         ixFZAKdm6rQA7xpMHTiCyamT9OgqLwBbTbFdw/87UyAmcJEBmew5BwrB4cfQ2JeqKwCF
         nCeAvswdp9zQyhLzB7o6Jz68MvCmSqNr0TG8AogckldYG6Ao0Zz/PqXR3xA1tCWx+YzI
         0zCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751020941; x=1751625741;
        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=RAUu45byWCYVeJgWLJnBZx5xF7D8AMI7j46sDoUddT0=;
        b=AJ2MxHszeid/umYJIA3arPAdlShSAMLNxJq0UUOPGQdMbPKIvZe7N9L0VY8jaxC3l4
         Ffn6mkt8AVI+TFlhGjR0Lyfa3J/39iDVDcRuLZb6B7C4Hh76unz/Fj8mBPC7SFjXhh5k
         jN05yqX5/xdYhCrHsdmAr4uLSz2y8hzquVC2bqPiTAn7Mjnzt1DZeLMCa40WVSHctTKH
         9zc2eceP7f1jtw3VtFn0FA+aVJsRUl55UxshEHoM96fzflR8mn+BcNQuJh91WRNbHYfE
         eMUKWDQyDATOuNR80Y+YabfUTXQe2+/ziME3x18wo9sM50wnD0+97pAH/ZCly+IxbL2u
         mTNQ==
X-Forwarded-Encrypted: i=1; AJvYcCVOaqNJPA/rIjBpdWTYfsedNrWUjyHpjACV8d8B9fxFJQa9G0hB96L1yDkEUD7ZQyBUTE9rHjpHTzs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxnfRUK0v+xugVyZAIWGY+UZktHdIiKmMCRCI01NaPDkkcnRwoC
	rLHNUVVfyUzRtIxBS3v3rHpXXQ98QFmDJFuWnFrB9u9113vzo+BupFH/gzCwtPz7nQ==
X-Gm-Gg: ASbGncv9PhifZcMTqszakPNLFOmuTixVI6oAwKZd+lZ+O/6THchnCUBEk1dKv6PeYGX
	i+drPFapRgZQ7+bPZVr0XfCFbnhxeBh8izya8k/sU39OscLa2NieZMCUDIwyvBF8WZ5elw7AtFw
	nImkTXfpEYMYnkRIH8asWihss9aPadgC4gwSUXyIwSWYt4neDSF9xHsf8syr/fxxIbh0hJ0fn7f
	AeuN+wtjYLumKstwzugsiV9inUSiIBII0I6HIs/ZJUBl/Es+i7VWhjTr1vCaE7Q7svQFNO+Fk9n
	n9FGXtC6Cm/dd9hE5PBPlTHtQ2He6unBy+Qw2WAgMONDUfZVyvnNUvWNAbIOf+qnGFMnygLlu8G
	hNgQq1yzRb53rVMwBNVPD3Mum5z+e4Wwn7mSdM4ajf+tTIZnozSn0ESGZxA==
X-Google-Smtp-Source: AGHT+IHR+yv3mLG6i8nI1B0rD0RI5sUWDv80BQf0ZTLHMF8oMGVfPtBPSXLfMNt9Tp117nijRDoHtw==
X-Received: by 2002:a05:6000:2110:b0:3a4:ef30:a4c8 with SMTP id ffacd0b85a97d-3a8f4548f90mr2179683f8f.10.1751020940992;
        Fri, 27 Jun 2025 03:42:20 -0700 (PDT)
Message-ID: <7ea6964b-71e3-4a86-a2f0-7124264bda80@suse.com>
Date: Fri, 27 Jun 2025 12:42:10 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT
To: "Chen, Jiqian" 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Andrew Cooper ,
 Anthony PERARD ,
 "Orzel, Michal" , Julien Grall ,
 Stefano Stabellini ,
 "xen-devel@lists.xenproject.org" ,
 "Huang, Ray" 
References: <20250612092942.1450344-1-Jiqian.Chen@amd.com>
 <5c4b186e-686e-4fc8-bcf1-854bc1f5ec8b@suse.com>
 
 <9d5d0e44-66c3-4e3f-8704-2c862c5f5aff@suse.com>
 
 <3638e73c-2a83-4164-9a84-839245245727@suse.com>
 
 <771cd5b7-2b89-49b1-9aba-8cd79319d3ce@suse.com>
 
 <7753470a-efef-478a-bbe5-ae48d008cfdb@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 27.06.2025 11:00, Chen, Jiqian wrote:
> On 2025/6/27 14:05, Jan Beulich wrote:
>> On 27.06.2025 04:59, Chen, Jiqian wrote:
>>> On 2025/6/26 20:06, Jan Beulich wrote:
>>>> On 26.06.2025 10:03, Chen, Jiqian wrote:
>>>>> On 2025/6/25 22:07, Jan Beulich wrote:
>>>>>> On 25.06.2025 12:16, Chen, Jiqian wrote:
>>>>>>> On 2025/6/25 18:03, Jan Beulich wrote:
>>>>>>>> Also, as said - you will need to check whether other architectures are
>>>>>>>> different from x86-64 in this regard. We better wouldn't leave a trap here,
>>>>>>>> for them to fall into when they enable vPCI support. I.e. my recommendation
>>>>>>>> would be that if in doubt, we put the __aligned() there unconditionally.
>>>>
>>>> Note how I used __aligned() here. Why would you ...
>>>>
>>>>>>> That's difficult for me to check on all different platforms since I don't have them all.
>>>>>>
>>>>>> You don't need to have them. You'd need to carefully go through the respective
>>>>>> section(s) of their psABI-s.
>>>>>>
>>>>>>> So you mean I should remove "#ifdef CONFIG_X86"? Just let __aligned(16) for all platforms?
>>>>>>
>>>>>> Yes. And, as also said, with a suitable comment please.
>>>>> Ah, my comment definitely needs your change suggestion.
>>>>> I wrote a draft as below:
>>>>>
>>>>> /*
>>>>>  * Size of vpci_capability is lager than 8 bytes. When it is used as the entry
>>>>>  * of __start_vpci_array in section, it is 16-byte aligned by assembler, that
>>>>>  * causes the array length (__end_vpci_array - __start_vpci_array) wrong, so
>>>>>  * force its definition to use 16-byte aligned here.
>>>>>  */
>>>>> struct vpci_capability {
>>>>>     unsigned int id;
>>>>>     bool is_ext;
>>>>>     int (* init)(const struct pci_dev *pdev);
>>>>>     int (* cleanup)(const struct pci_dev *pdev);
>>>>> } __attribute__((aligned(16)));
>>>>
>>>> ... open-code that here?
>>> That because when using __aligned() without CONFIG_X86, I got compile error
>>> vpci.h:18:13: error: expected declaration specifiers or ‘...’ before numeric constant
>>>    18 | } __aligned(16);
>>>       |             ^~
>>> I tried some methods, only open-code can fix it.
>>
>> Well, that's odd. In e.g. xen/sched.h we have
>>
>> struct domain
>> {
>>     ...
>> } __aligned(PAGE_SIZE);
>>
>> which clearly must be working fine. The error message from the compiler
>> doesn't say very much alone. For informational diagnostics the compiler
>> normally also emits may help, or else it would take looking at the
>> pre-processed output to understand what's going on here.
> 
> I add some codes to print the macro __align, the codes are:
> 
> diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
> index 51573baabc..8f6af1c822 100644
> --- a/xen/include/xen/vpci.h
> +++ b/xen/include/xen/vpci.h
> @@ -13,12 +13,16 @@ typedef uint32_t vpci_read_t(const struct pci_dev *pdev, unsigned int reg,
>  typedef void vpci_write_t(const struct pci_dev *pdev, unsigned int reg,
>                            uint32_t val, void *data);
> 
> +#define STRINGIFY(x) #x
> +#define TOSTRING(x) STRINGIFY(x)
> +#pragma message("__aligned(16) expands to: " TOSTRING(__aligned(16)))
> +
>  struct vpci_capability {
>      unsigned int id;
>      bool is_ext;
>      int (* init)(const struct pci_dev *pdev);
>      int (* cleanup)(const struct pci_dev *pdev);
> } __aligned(16);
> 
> The result are:
> 
> In file included from ./include/xen/sched.h:25,
>                  from arch/x86/x86_64/asm-offsets.c:11:
> ./include/xen/vpci.h:18:9: note: ‘#pragma message: __aligned(16) expands to: __attribute__((__aligned__(16)))’
>    18 | #pragma message("__aligned(16) expands to: " TOSTRING(__aligned(16)))
>       |         ^~~~~~~
> In file included from ./include/xen/sched.h:25,
>                  from drivers/vpci/vpci.c:20:
> ./include/xen/vpci.h:18:9: note: ‘#pragma message: __aligned(16) expands to: __attribute__((__aligned__(16)))’
>    18 | #pragma message("__aligned(16) expands to: " TOSTRING(__aligned(16)))
>       |         ^~~~~~~
> In file included from emul.h:88,
>                  from vpci.c:18:
> vpci.h:15:9: note: ‘#pragma message: __aligned(16) expands to: __aligned(16)’
>    15 | #pragma message("__aligned(16) expands to: " TOSTRING(__aligned(16)))
>       |         ^~~~~~~
> vpci.h:22:13: error: expected declaration specifiers or ‘...’ before numeric constant
>    22 | } __aligned(16);
>       |             ^~
> In file included from emul.h:88,
>                  from main.c:19:
> vpci.h:15:9: note: ‘#pragma message: __aligned(16) expands to: __aligned(16)’
>    15 | #pragma message("__aligned(16) expands to: " TOSTRING(__aligned(16)))
>       |         ^~~~~~~
> vpci.h:22:13: error: expected declaration specifiers or ‘...’ before numeric constant
>    22 | } __aligned(16);
>       |             ^~
> make[6]: *** [Makefile:18: test_vpci] Error 1
> make[5]: *** [/home/cjq/code/upstream/xen/tools/tests/../../tools/Rules.mk:194: subdir-install-vpci] Error 2
> make[4]: *** [/home/cjq/code/upstream/xen/tools/tests/../../tools/Rules.mk:189: subdirs-install] Error 2
> make[3]: *** [/home/cjq/code/upstream/xen/tools/../tools/Rules.mk:194: subdir-install-tests] Error 2
> make[2]: *** [/home/cjq/code/upstream/xen/tools/../tools/Rules.mk:189: subdirs-install] Error 2
> make[1]: *** [Makefile:64: install] Error 2
> make: *** [Makefile:147: install-tools] Error 2
> make: *** Waiting for unfinished jobs....

Well, it would have helped a lot if you had said from the very beginning that it's
the test harness where you observe the build issue. These test harnesses are always
a little special, due to their intention to re-use the core source file(s). (And
no, pulling in compiler.h likely wouldn't be the right workaround.)

Jan


From xen-devel-bounces@lists.xenproject.org Fri Jun 27 10:51:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 10:51:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027505.1402112 (Exim 4.92)
	(envelope-from )
	id 1uV6gR-0002kP-50; Fri, 27 Jun 2025 10:51:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027505.1402112; Fri, 27 Jun 2025 10:51:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uV6gR-0002kI-1l; Fri, 27 Jun 2025 10:51:51 +0000
Received: by outflank-mailman (input) for mailman id 1027505;
 Fri, 27 Jun 2025 10:51: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 1uV6gP-0002k0-Sa
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 10:51:49 +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 b9d87d8a-5344-11f0-a30f-13f23c93f187;
 Fri, 27 Jun 2025 12:51:49 +0200 (CEST)
Received: by mail-lf1-x134.google.com with SMTP id
 2adb3069b0e04-553b6a349ccso2267871e87.0
 for ; Fri, 27 Jun 2025 03:51:49 -0700 (PDT)
Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-32cd2dea1c0sm5235831fa.3.2025.06.27.03.51.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 27 Jun 2025 03:51:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b9d87d8a-5344-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1751021508; x=1751626308; darn=lists.xenproject.org;
        h=content-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=zvxUHn81TzPOxrckXPxoHks4QhxS4ztnhXtdUUKJDg8=;
        b=GmA/6pSD+HhDckBRoZH094U0J2Aa8PNJj7bi0J6mvP4WfHuKf14gHjsKxuCIJKD8SZ
         ebE+3tpLQuuSAnmn2w4b51r9THFYXdDil1hD28gIZAGbJjhhB1SPdto36qj0CzkFOeMy
         ep7uwlG/IlSmTKPpEZW3ekTiR75cMrzsU6ohs3VZsK8HKQ3TtqWkDUpfy/3ynCny6jow
         iS8D2eEmfyCiXizz2lVNB81PonXkReecz5+ZKwDo/mjhkesgHyus/jdehxXxBBCrJoz1
         XsKnAg5DCqe+jLJsTTAgdbdISHQlfNRnW1SJWhdrRFu78M+vgZs6CNYkP1ZUX5jI+sPu
         GtSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751021508; x=1751626308;
        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=zvxUHn81TzPOxrckXPxoHks4QhxS4ztnhXtdUUKJDg8=;
        b=WHbEr+aQni4aY2EheqHbeNuZltehMmvNU0GiP++ufluo6ZE0gPxkC8TC7z8OGDKgq3
         kFVHNBtWBm204YRfmLV6CIHj+kgj5iITCpvdECbvNnPFyV3d8ZxEnzLi7ImWed6ZYmSz
         nw8xt1Xu6RVXpn7KxNIiOiUbS1tMC4DWjwPIL7pVB7Bsbeuob/+HuKvjqoIhOCqolX3e
         pDhUnGz3rjgbF1KJzCMtQXRTi7Bsso4llISvJ2wkuXGhMk3eZc0hlNVlKyG4jcTI+vEN
         F0XeR+sQOitwrXc0ZThT+LO9F8JAB9YSCi3+EgelOAhc60h5hPR8mKgYvUExM5AuLEPV
         3RKA==
X-Gm-Message-State: AOJu0Yx0Te6me/ZLhPECQm0HsDtUPMFXXQ5NdpDhjBL1IysQQ7nKZUID
	ewPO8+XO+fOx2MTmpb8+XP3Zuil/kVi3dv2wmbP+gSaY0haVkwAgB8yzDPyG2TGd
X-Gm-Gg: ASbGncvkRWJLM4h9Jf3a44nMWmo2D1L/OInY9QXKaRbXZQTeWAUOarbAY7E3CH5zG3f
	mARftQntsumuStPwCvyh1UMHq1lVigzAbHuJ8iLekcQ+h6ZckQazgERnRPx23AUP4M4+ePtnwtR
	oV0q4qPEY1ZJHIfWGoNaN7BDd3Svkgj5EdBYllCYWG86v/klkMHWpCqmsVQBt+KnMemlbkDrkFq
	lAD1ftJX1uC52RqsVrV11ImIdfgLkHLgyxyYjCZDGUIYC0+8P+EEYj43iWDVEjliCmkUQkcjCtg
	X8DCY1w10ZnTO3Zy8DhZVGxBnWtlTEHi6A54cvmNpZIQ8kkMBU/Fwebe7EAQnv0afX6zyP5toJy
	WfTRRoro/g5s1DMRhnNPMTe5Gbw==
X-Google-Smtp-Source: AGHT+IHTTZvhZxX4sgrLSTAzgt1vLxbnS78lDzcGMMd1uy2hTeYFtwgODAbp9VVAPNSP/UmMmWP0Rw==
X-Received: by 2002:a05:6512:32d4:b0:553:341f:12a3 with SMTP id 2adb3069b0e04-5550b8b053emr782425e87.39.1751021508126;
        Fri, 27 Jun 2025 03:51:48 -0700 (PDT)
From: Mykola Kvach 
To: xen-devel@lists.xenproject.org
Cc: Mykola Kvach ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v5 3/4] SUPPORT.md: Add entry for guest PSCI SYSTEM_SUSPEND support
Date: Fri, 27 Jun 2025 13:51:32 +0300
Message-ID: <401d3745a295812fef14a22b0c2a3c6017d588c1.1751020456.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.48.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Mykola Kvach 

Document support for the optional PSCI SYSTEM_SUSPEND function, exposed
via the virtual PSCI (vPSCI) interface to guests.

This allows non-hardware domain guests (domUs) to initiate system suspend
operations via PSCI calls. The feature is currently marked as Experimental.

Signed-off-by: Mykola Kvach 
---
Changes in v5:
- Dropped ARM/PSCI entry: this refers to internal use of PSCI SMC calls,
  which is not relevant for SUPPORT.md
- Added a dedicated entry for PSCI SYSTEM_SUSPEND instead of generic guest
  PSCI info; guest PSCI support was documented in a separate patch
---
 SUPPORT.md | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/SUPPORT.md b/SUPPORT.md
index f0b5718e84..659b9c3052 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -956,6 +956,13 @@ by hwdom. Some platforms use SCMI for access to system-level resources.
 
     Status: Supported
 
+### ARM: Guest PSCI SYSTEM_SUSPEND support
+
+Support for the optional PSCI SYSTEM_SUSPEND function exposed via vPSCI.
+Allows non-hardware domain guests to initiate a system suspend.
+
+    Status: Experimental
+
 ## Virtual Hardware, QEMU
 
 This section describes supported devices available in HVM mode using a
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Fri Jun 27 10:51:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 10:51:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027507.1402123 (Exim 4.92)
	(envelope-from )
	id 1uV6gR-0002tr-N4; Fri, 27 Jun 2025 10:51:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027507.1402123; Fri, 27 Jun 2025 10:51:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uV6gR-0002rw-Hj; Fri, 27 Jun 2025 10:51:51 +0000
Received: by outflank-mailman (input) for mailman id 1027507;
 Fri, 27 Jun 2025 10:51: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 1uV6gQ-0002k0-Nn
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 10:51:50 +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 ba91903d-5344-11f0-a30f-13f23c93f187;
 Fri, 27 Jun 2025 12:51:50 +0200 (CEST)
Received: by mail-lj1-x235.google.com with SMTP id
 38308e7fff4ca-32cd0dfbd66so15789881fa.3
 for ; Fri, 27 Jun 2025 03:51:50 -0700 (PDT)
Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-32cd2dea1c0sm5235831fa.3.2025.06.27.03.51.48
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 27 Jun 2025 03:51:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ba91903d-5344-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1751021510; x=1751626310; darn=lists.xenproject.org;
        h=content-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=Ua935WurpFjU8q1PTBY29dqBWcHnlgrzlb/sVrXtOkY=;
        b=dWNiCKvTMyhgIWmQtW2A7yCBL61UgFyMf3Lf/PqtzzTa3kKw4Zl4gnjMGySMiHoDCJ
         Lqhz0BzLApGUZCmEt8+GlPWgJTzyVkS5yB5pldk88jPA7dJAPIi0ULgur/PP8DifG+SB
         Z21WKrQBYsrjaXLqJ3D17bIKpgQW+T7rXooxIv0LWxC3xb2DC2kOC7/X3XFYz5Hm2kzP
         QGDRfvv/YS1EPXyojlmIJRZ9UEi45W/RLCtStyg7nvPTNyU+9bziK2PjipfuNpUKr+k/
         lMF2CA3OmxbqdID4k74alTOWjxxTezXtPjVTSu1N9TXVN24pSMUsqcNeFlulhHleZoqF
         VvTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751021510; x=1751626310;
        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=Ua935WurpFjU8q1PTBY29dqBWcHnlgrzlb/sVrXtOkY=;
        b=rn81Dh6Xb0I3vA5JatHkTQdeJqpu5RUvU0jQlXOqnk03Hpq+aRJ87xZvqWybdzcw17
         9tR5XpG/ht+hn8Cnp9uJpPrHaSUalvIntztCtaVsIQE+MoCLPxIcLOObjdVdg6SRe9zY
         FLuDIkkPVvXLZN/3PnbpOBsdRP9uMOAVMmaF7jlK6SYstIodyGdI5YJ1e5/UxNbCPdho
         5LQGMUx6Kq+bEiA0snZhBKXYMtMtII6UxLspxY0nUdV9i9+Y3mjK4KP43nX4aCf1VR1x
         elenl0BFEqNtPMTMkTDXeMP8+Hm9ZjRjthYcq+NBO5GDM8aKLtRX2R5OpPsA2EJS5aNx
         M5qQ==
X-Gm-Message-State: AOJu0Yy1152l1LYSAdgo2WDFSIbyguPg4ZfQCJro9PK7F/5xaoXV6Sla
	7xZlsq67YKAMi9eLisjfNowIv3XRim4MIfOf+XFDgJlpiuQbKcXcavGTLsxrgewP
X-Gm-Gg: ASbGnctjObi7X5m872tNCz2ABUgaMlnltDFkppKr1Fvl7zx3lMNbiOn6VNQU6ZQ4/73
	2WoVNGMIUH6BwcMCPeryGoXyuR/uCzTF1M81VucJH0cCg/6Idt2C9HmLvsFmNjSYEG4f5/5R6Kj
	Er95OBnnUCNBW1ujoWENsbhIPifaI84icrBlGPY1wrgAWP6a/VQ0aOzJ781uSibT7zHF7fdFsRr
	nztE7zucghLk76xSizFVFFggbuOLjWaCR08yV/gkJgYtMbtfucKm1cEF6IotOypC/a/Wav1oJKr
	3EpZVNeSCj9xyPznfgnWMVdJvzpg2OEr10wsCc4BBfcmnh4c51CW5Lkz6LXKWb76QXEVxEXC6TY
	UWQ/+Eh7Ba8O7k+1ZVNW47K2Ifw==
X-Google-Smtp-Source: AGHT+IHFzWIUYlNlURrIMGK10ZsPPhDfk4HecC4VKN8XchkntZcY1UnimoehDaDa5ihpFEQInWjhXw==
X-Received: by 2002:a05:651c:2041:b0:32a:6b23:d3cc with SMTP id 38308e7fff4ca-32cdc518517mr6690531fa.25.1751021509431;
        Fri, 27 Jun 2025 03:51:49 -0700 (PDT)
From: Mykola Kvach 
To: xen-devel@lists.xenproject.org
Cc: Mykola Kvach ,
	Oleksii Kurochko ,
	Community Manager 
Subject: [PATCH v5 4/4] CHANGELOG: Document guest suspend/resume to RAM support on Arm
Date: Fri, 27 Jun 2025 13:51:33 +0300
Message-ID: 
X-Mailer: git-send-email 2.48.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Mykola Kvach 

Mention the newly added support for guest suspend and resume to/from
RAM via vPSCI on Arm platforms (ARM32 and ARM64). This support is
limited to non-hardware domain guests.

Signed-off-by: Mykola Kvach 
---
Changes in v5:
- adjustments to the commit title and message
- expanded the changelog entry to include more context about
  suspend/resume support introduced in this patch series
---
 CHANGELOG.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 5f31ca08fe..1c155f7ff2 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -29,6 +29,8 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
 
  - On Arm:
     - Ability to enable stack protector
+    - Support for guest suspend and resume to/from RAM via vPSCI (for both ARM32
+      and ARM64). Applies only to non-hardware domain guests.
 
 ### Removed
  - On x86:
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Fri Jun 27 10:51:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 10:51:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027506.1402119 (Exim 4.92)
	(envelope-from )
	id 1uV6gR-0002nm-F7; Fri, 27 Jun 2025 10:51:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027506.1402119; Fri, 27 Jun 2025 10:51:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uV6gR-0002mb-9C; Fri, 27 Jun 2025 10:51:51 +0000
Received: by outflank-mailman (input) for mailman id 1027506;
 Fri, 27 Jun 2025 10:51: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 1uV6gQ-0002k5-AY
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 10:51:50 +0000
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com
 [2a00:1450:4864:20::236])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b980649a-5344-11f0-b894-0df219b8e170;
 Fri, 27 Jun 2025 12:51:48 +0200 (CEST)
Received: by mail-lj1-x236.google.com with SMTP id
 38308e7fff4ca-32adebb15c5so14914641fa.3
 for ; Fri, 27 Jun 2025 03:51:48 -0700 (PDT)
Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-32cd2dea1c0sm5235831fa.3.2025.06.27.03.51.46
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 27 Jun 2025 03:51:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b980649a-5344-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1751021508; x=1751626308; darn=lists.xenproject.org;
        h=content-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=DtDYb/sxb7EM69AJmP/RVzUWb9yGC1iN05GypUjWJS0=;
        b=OsdN+uqfzF0qafwjHnmQgOq5Xf0lDZyN219zQ3t70GNuH+MShRRj0SWc66S0hAP+hs
         8ViCuy0mWoC72AW1A5T88nfREpIClO8/F1zv6j2C1/AB15AziJrdMIgpQ8VEPnVN60NC
         oaCiEImSm41x1Jag+4KE4A+h3XhaT1LuGdzSrZme89G53/FNdNFcLNeENpKM/sPyIyc5
         uReG8N6/DPC6yoI5534lkJJDElb/5e3+dax5ORK4pDIxfVLVzwXmZnd+y27/5kwAaUxb
         fSlYZkfpd3TpCigIfWalf/DeoQuR2/RA1txzrM9/B0ScFghMdrjZPjVJrqNBifO68Oau
         jYnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751021508; x=1751626308;
        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=DtDYb/sxb7EM69AJmP/RVzUWb9yGC1iN05GypUjWJS0=;
        b=BTs7glbLtrVCSF1KAY0cPlgRUVt7BQ/V1nG0G73Q+fdEepQRKN5X+WQrmgzNJfWzTA
         uvy6zzCPxBgXQS0x4WfSBVINk1CRsVREn9D00myiu6XxhcMJIbpHvvcynDLp/weryRza
         VfaiZU6UfuhHShCz6ygZ/MJNViFMWOyDVpnN864faX3Bl/7PZI58sYLC2MooV2ywbQn/
         8dUlvNY1Vt56nEa9NaIVQrBKoZuyrBtDXWaC1nMTeI7JpffPdi4Y42/LPSx4sbxd/UXB
         g0zLtF10sF/nvROpBK4me+EOaUL4wdU2GEUhvynUtMVpKe/ugyXwhgHfFvKZmMDo72c8
         KqLA==
X-Gm-Message-State: AOJu0YxYwzOubZSUO0r0yAjHzWRpmj29cFjKba4dNshP4Xc4/80tgfJD
	85Knac4HLQ97reTcUu12z5oHQqS2tIHs6ePehiF/hRc1MwQwJNOB3jbPU9nXygLl
X-Gm-Gg: ASbGncs7TdUPL1yMJfqnTwaeWZXu4FWGQX2Fy6KL48j2J1M/WYft1I3UYypalV9+Q7M
	r+Hsn/dRTASN1fZQYRVX5qSQhRNBR1jbOdWSOetmdwiWUKyPS0UHeoTeOl7KjjRAjGMK+8pAEsJ
	gPsfuNxjIIvuMSrCaGFsNKKMzfLwDqQLY+udO3rCY2lhBomnvgr3ZbGaeo87PUZZWvaVgTyJ5WY
	IalF+nnSctb2bjHWCdTDtR6yaP96ZxhYn0ruCs2vC/UImU1GKOe7V4WGXpbeVWFbEOzApllu/Ro
	gffIJ7Te5/Avcf5mxm4Q35sCb2/IJgTPvMJEQGoy89IROdcMuy1jPdYhGRjaf7Q6fB3rJzSWRz5
	h79Sa5quwpJtTuacoLuBmHXNocQ==
X-Google-Smtp-Source: AGHT+IEkSp1AGDJtWZaTbK8GvkVKo++j2/3AogtoWI8j+NM2W8N1kPeEqWvYagulylssuiDC65QlxA==
X-Received: by 2002:a05:651c:304b:b0:32a:84f6:a862 with SMTP id 38308e7fff4ca-32cdc481409mr6328681fa.3.1751021507206;
        Fri, 27 Jun 2025 03:51:47 -0700 (PDT)
From: Mykola Kvach 
To: xen-devel@lists.xenproject.org
Cc: Mykola Kvach ,
	Anthony PERARD ,
	Juergen Gross 
Subject: [PATCH v5 2/4] tools/xl: allow resume command compilation for arm
Date: Fri, 27 Jun 2025 13:51:31 +0300
Message-ID: <00c495b471c09a84601156b2b74a1ba897f51755.1751020456.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.48.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Mykola Kvach 

The "xl resume" command was previously excluded from ARM builds because
system suspend/resume (e.g., `SYSTEM_SUSPEND`) via vPSCI was not
implemented. On x86, the command is used for ACPI S3 suspend/resume.

This change enables compilation of `xl resume` on ARM regardless of the
underlying implementation status, making the tool available for use in
testing or for future support. The libxl infrastructure and handler
functions are already present and usable.

Note: This does not imply full system suspend/resume support on ARM.
      "xl suspend" command still not work for arm platforms.

Signed-off-by: Mykola Kvach 
---
 tools/include/libxl.h   |  1 -
 tools/xl/xl.h           |  2 +-
 tools/xl/xl_cmdtable.c  |  2 +-
 tools/xl/xl_vmcontrol.c | 12 ++++++------
 4 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/tools/include/libxl.h b/tools/include/libxl.h
index a8704e0268..0fda8bb616 100644
--- a/tools/include/libxl.h
+++ b/tools/include/libxl.h
@@ -1134,7 +1134,6 @@ typedef struct libxl__ctx libxl_ctx;
  * restoring or migrating a domain. In this case the related functions
  * should be expected to return failure. That is:
  *  - libxl_domain_suspend
- *  - libxl_domain_resume
  *  - libxl_domain_remus_start
  */
 #if defined(__arm__) || defined(__aarch64__)
diff --git a/tools/xl/xl.h b/tools/xl/xl.h
index 45745f0dbb..5b0a481456 100644
--- a/tools/xl/xl.h
+++ b/tools/xl/xl.h
@@ -130,8 +130,8 @@ 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_resume(int argc, char **argv);
 int main_dump_core(int argc, char **argv);
 int main_pause(int argc, char **argv);
 int main_unpause(int argc, char **argv);
diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c
index 06a0039718..4f662a4189 100644
--- a/tools/xl/xl_cmdtable.c
+++ b/tools/xl/xl_cmdtable.c
@@ -198,12 +198,12 @@ const struct cmd_spec cmd_table[] = {
       "Suspend a domain to RAM",
       "",
     },
+#endif
     { "resume",
       &main_resume, 0, 1,
       "Resume a domain from RAM",
       "",
     },
-#endif
     { "dump-core",
       &main_dump_core, 0, 1,
       "Core dump a domain",
diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c
index c813732838..ebacde5482 100644
--- a/tools/xl/xl_vmcontrol.c
+++ b/tools/xl/xl_vmcontrol.c
@@ -38,11 +38,6 @@ 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;
@@ -55,6 +50,12 @@ int main_suspend(int argc, char **argv)
 
     return EXIT_SUCCESS;
 }
+#endif
+
+static void resume_domain(uint32_t domid)
+{
+    libxl_domain_resume(ctx, domid, 1, NULL);
+}
 
 int main_resume(int argc, char **argv)
 {
@@ -68,7 +69,6 @@ int main_resume(int argc, char **argv)
 
     return EXIT_SUCCESS;
 }
-#endif
 
 static void pause_domain(uint32_t domid)
 {
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Fri Jun 27 10:51:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 10:51:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027508.1402142 (Exim 4.92)
	(envelope-from )
	id 1uV6gV-0003Sw-3n; Fri, 27 Jun 2025 10:51:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027508.1402142; Fri, 27 Jun 2025 10: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 1uV6gV-0003Sp-0D; Fri, 27 Jun 2025 10:51:55 +0000
Received: by outflank-mailman (input) for mailman id 1027508;
 Fri, 27 Jun 2025 10:51: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 1uV6gT-0002k5-1M
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 10:51:53 +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 b88a0e31-5344-11f0-b894-0df219b8e170;
 Fri, 27 Jun 2025 12:51:46 +0200 (CEST)
Received: by mail-lf1-x130.google.com with SMTP id
 2adb3069b0e04-553bcf41440so2070138e87.3
 for ; Fri, 27 Jun 2025 03:51:46 -0700 (PDT)
Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-32cd2dea1c0sm5235831fa.3.2025.06.27.03.51.44
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 27 Jun 2025 03:51:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b88a0e31-5344-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1751021506; x=1751626306; 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=5Dr8iArT/LE1lmvmXj9BXJT3sgpq7t+Thr/P2BbYrfk=;
        b=jN9rgfwFBMU9uCdyc5t+Ji8+TCNzCgP/TuzOXwZ/2mkEHAtVfLFpJP4/XzswUv8Jmd
         n2d68chMn4s0VJKaDL1BvrQGhSsp3eMVegMRoGG7lHH2uHe19ry0aC6xW7NHhN3GHq0j
         bsEGqBerrHXsBaZ8BL0IlCz4hk96NejCpLbHhO665pUNou1B0glhRyxw1kvk0yoNMxY9
         gXsxbD5PphQNS4nZ/3fxquL3MYGyJgarn9DFAJ8ZQR54CqHWxHX95LBQ17Yw2he8McEK
         H2uQ2azCfVRbfJ021G/ItcBe23Q/lBYgbih4Mgg2xONm8gos6mpF3rGu75O82mxnVvTr
         ycIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751021506; x=1751626306;
        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=5Dr8iArT/LE1lmvmXj9BXJT3sgpq7t+Thr/P2BbYrfk=;
        b=tRMax5cNrTTxNjezu7YGksGtq5/1Pi5m84eunRb7XEZOVGZTYkw2BLUf72QlZKxVbU
         Y4A7GeiIVLYJyzP21KpQMhwhLISrFVNc6gnlQ78VIhqh/IBO7neIPTamPQhjXnZHrg38
         lyGd0Md8u52nT81RB80+TV+IjsIKZPERrUeb6TbZ+49y8vCOEjMWG0ReE8kLWQMLkrae
         PCyGKvOFJbIUmnHPS6DCM8aRp7NZ0wAoaiBKslQoG/KOmDS70fi2+JtqD1LrbIRGMxWU
         Z+vyz7KtP3wcCVnUxR2UtOkP/dkEZXOX/Q+FMETZ44V0EYpnahGfBwjlvOSrKt1brmr6
         +Fhg==
X-Gm-Message-State: AOJu0Yww2qUCD4HsrECDDNrdIOkWMC4KzahkCeqH0g6GoeQryBznDSyf
	HIfKcbostj+VTpaSm5nvC8FpgLM1h2GGlx5w7xHoz25eRmq1oA+3YgE1mwZRBFFk
X-Gm-Gg: ASbGncvTTujkgh4oXLw/QuTSlxpNEMYJBZVVhacYKs5S1uG4u5KfW9cZSnWygwYXfsf
	JQ2Vmtgj23Yf4YtZeox8IkEeyKIaVmbM1kNcq63TcuBc30yfkUhe4ThqEpYs5yfhZKzJ5WiECj9
	wzCBErv2vdcFL6Di0alchgKYFcoGYqob/P4o2I8sEfIgtXLJtkxI+Kc8FAEpHIvTQeZxe1Ly5aq
	AC9kx2QgblI7PiO42EV89QNYqb5uWQ+i6Zx4I0Vgz+txqIUz30MIl39cZWeS60F4p9bVuBWOO/M
	tovEA2iJJwLF/Vdnj4NrW0PpFSEMw3OU73s7F78nUKlgALWSeezKRZChkgJnyx1P+p+cMxFR4XL
	iAN9RncRmLo3Hu5T64drAmOAD8w==
X-Google-Smtp-Source: AGHT+IHqwxGUVrmU+ZOCc5tjPVo0FIfRGtWSbu0TTR0/cNaRr7kcWmT9ZPSqJS3cDCfNvEqr8zT3EQ==
X-Received: by 2002:a05:6512:b12:b0:554:f79d:ce59 with SMTP id 2adb3069b0e04-5550b9ee228mr913768e87.27.1751021505458;
        Fri, 27 Jun 2025 03:51:45 -0700 (PDT)
From: Mykola Kvach 
To: xen-devel@lists.xenproject.org
Cc: Mykola Kvach ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Anthony PERARD ,
	Juergen Gross ,
	Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Oleksii Kurochko ,
	Community Manager 
Subject: [PATCH v5 0/4] Enable guest suspend/resume support on ARM via vPSCI
Date: Fri, 27 Jun 2025 13:51:29 +0300
Message-ID: 
X-Mailer: git-send-email 2.48.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Mykola Kvach 

This patch series introduces the initial support for guest suspend
and resume on ARM platforms using the PSCI SYSTEM_SUSPEND interface. The main
goal is to allow ARM guests to request suspension using PSCI and be resumed
by the control domain (e.g., via "xl resume").

### Background

The PSCI SYSTEM_SUSPEND call is part of the PSCI v1.0+ specification and is
used by guests to enter the deepest possible power state. On Xen/ARM, we
emulate this interface in the virtual PSCI (vPSCI) layer for guests.

This series includes:

1. A new vPSCI implementation of the PSCI SYSTEM_SUSPEND function for guests
2. Documentation updates to SUPPORT.md to reflect PSCI and vPSCI support status
3. Enabling "xl resume" command compilation for ARM, which was previously disabled

### Usage

For Linux-based guests:
  - Suspend can be triggered using: "echo mem > /sys/power/state" or "systemctl suspend"
  - Resume can be performed from control domain using: "xl resume "

For more information, refer to the official Linux kernel documentation on power management.

Note that currently, SYSTEM_SUSPEND is supported only for guest domains (not for
the hardware domain).
---

TODO: enable "xl suspend" for ARM
---
Previous versions of this patch series:
  V1: https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg01093.html
  V2: https://marc.info/?l=xen-devel&m=166514782207736&w=2
  V3: https://lists.xenproject.org/archives/html/xen-devel/2025-03/msg00168.html


This is the first part of previous patch series and originally consist only
with necessary changes needed for guest domain suspend.


Main change in V5:
  - Reverted the logic related to suspending domains. Instead of the standby
    mode introduced in v4, domains now resume execution at the point provided
    during suspend

The rest of the minor changes are described in the changelog of each commit.


Mykola Kvach (4):
  xen/arm: Implement PSCI SYSTEM_SUSPEND call for guests
  tools/xl: allow resume command compilation for arm
  SUPPORT.md: Add entry for guest PSCI SYSTEM_SUSPEND support
  CHANGELOG: Document guest suspend/resume to RAM support on Arm

 CHANGELOG.md                          |  2 +
 SUPPORT.md                            |  7 ++
 tools/include/libxl.h                 |  1 -
 tools/xl/xl.h                         |  2 +-
 tools/xl/xl_cmdtable.c                |  2 +-
 tools/xl/xl_vmcontrol.c               | 12 ++--
 xen/arch/arm/include/asm/perfc_defn.h |  1 +
 xen/arch/arm/include/asm/psci.h       |  2 +
 xen/arch/arm/include/asm/vpsci.h      |  2 +-
 xen/arch/arm/mmu/p2m.c                |  6 +-
 xen/arch/arm/vpsci.c                  | 96 +++++++++++++++++++++++----
 11 files changed, 109 insertions(+), 24 deletions(-)

-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Fri Jun 27 10:51:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 10:51:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027509.1402147 (Exim 4.92)
	(envelope-from )
	id 1uV6gV-0003Vr-Ef; Fri, 27 Jun 2025 10:51:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027509.1402147; Fri, 27 Jun 2025 10: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 1uV6gV-0003VM-8n; Fri, 27 Jun 2025 10:51:55 +0000
Received: by outflank-mailman (input) for mailman id 1027509;
 Fri, 27 Jun 2025 10:51: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 1uV6gU-0002k5-1O
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 10:51:54 +0000
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com
 [2a00:1450:4864:20::231])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b900e327-5344-11f0-b894-0df219b8e170;
 Fri, 27 Jun 2025 12:51:47 +0200 (CEST)
Received: by mail-lj1-x231.google.com with SMTP id
 38308e7fff4ca-32b49ac6431so17205961fa.1
 for ; Fri, 27 Jun 2025 03:51:47 -0700 (PDT)
Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-32cd2dea1c0sm5235831fa.3.2025.06.27.03.51.45
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 27 Jun 2025 03:51:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b900e327-5344-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1751021507; x=1751626307; darn=lists.xenproject.org;
        h=content-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=lovaqz97Yz4C4ZS/M20yvmKKYHwyYhdSKNbqE+LHAXs=;
        b=aIdVh9Z8xCRfZPzxbVhXl2K/FhqpuyUOaWcJGm+nbmSxtn1mhLU4dymXDyRTP4LJ2t
         1Imt5bXaVH5I7EJ84B6YmUuOdBu+jI4udrI53jNvMN5ZiHFPULFBpxnbHtDGXDRK8RZi
         X9gzE79SwMnALUmxU/60qOn7LiFQfT0FDJld/nUzHr8/8UXlNzBAz94ZoZpjwxEIS7QL
         JCAri1Nt9ksI2bDGGg3zyy5Qehl2wqznCC0oJI5im24cacOGj2WC49mOHYOv8wxjkj/0
         gOHZ2ExlTaLPXhTbhUzyO798RY1RvxYobVWRbXPy1SHbDF3HTGIfQm8gJSh1+Nffihys
         eSgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751021507; x=1751626307;
        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=lovaqz97Yz4C4ZS/M20yvmKKYHwyYhdSKNbqE+LHAXs=;
        b=bNlSR2asW6HRVK2Ttbls7Zygf7SNT7cDiZFOb5uMhzHtrfq41NhwmqjnCRoBhrCMu7
         IPtTfyCMYms6VJG9YuHez/2Mxt4Jk8/L5cm/HWA1+9VBloEm8j4PgkVuT3V3YmYj04h9
         XJGcv6j9wP1Lb3jFS2hXQQqu6esV4tEgLSUPQJlNlOHteDp4fg900jQGF4YweGOfRtjt
         HAmCwj5b4+xbCIE+ysyocWO3mSfNbRH/eHe9Uc3cR7q+Pu7TUwIkgwtlfUV2oWPz9W/I
         /yq+jht/PtSv1GgXWw1cRpQPQHT1vph5IgzccoTpxqxINTqGSbNj3ttm77jrn+yT8fah
         Yyhg==
X-Gm-Message-State: AOJu0Yxi9wUb7AjFh807Rg4+1bBImXo0iLRm1ykP0iW57MPHteuoPDoA
	O8T0xebj80MObid1vlsC7W4/HUjH2j2+gwRkFB67a42C3YdekKByhm2BVMMeuM05
X-Gm-Gg: ASbGncvZHlNm5xx/KcFzFFUKLYPEnE+lGCwxOt36DO7dC0HglgIG8AIlZp2bXhudCLA
	ONVA1436zGf778V2s3M7z4JCRO3kUf9eeX7CypyHzioCilJ59oha5VsAG0RAKXmOLmNqGR+9E2/
	qgg0ak02mGE2lGuimKnLNgH0Inf4LfCHIDO0KiVITG97YJ/JcGWZdjPFlqVaa6CPbjoB00FSV1A
	JC4tqHaokybGetzwOgk1a5fPVjGETMaZuDH+p2spOOdiPuvFBFuRQFGy+U1oD80nxUE3Uqi16Fb
	6OAOKFMTPNlVb8LUaH66DCT5Y+PaZskh+zxfAV+Yz00YOWJwE0P4WwRrajKz+GNKvv3zg+6Mv7E
	GmTTntpUmxicEbBHemPW2/4lfZw==
X-Google-Smtp-Source: AGHT+IE+AWmr/h1Db222u088W/zHOH1XMPOY1hr6Gerf2Dgjl13Ny0bypbRnPn8rL5wufyNsQgk8Yg==
X-Received: by 2002:a05:651c:40d6:b0:32c:a097:41a8 with SMTP id 38308e7fff4ca-32cdc499336mr4607691fa.12.1751021506395;
        Fri, 27 Jun 2025 03:51:46 -0700 (PDT)
From: Mykola Kvach 
To: xen-devel@lists.xenproject.org
Cc: Mykola Kvach ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH v5 1/4] xen/arm: Implement PSCI SYSTEM_SUSPEND call for guests
Date: Fri, 27 Jun 2025 13:51:30 +0300
Message-ID: <072270e0940b6bcc2743d56a336363f4719ba60a.1751020456.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.48.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Mykola Kvach 

This patch adds support for the PSCI SYSTEM_SUSPEND function in the vPSCI
(virtual PSCI) interface, allowing guests to request suspend via the PSCI
v1.0 SYSTEM_SUSPEND call (both 32-bit and 64-bit variants).

The implementation:
- Adds SYSTEM_SUSPEND function IDs to PSCI definitions
- Implements trapping and handling of SYSTEM_SUSPEND in vPSCI
- Allows only non-hardware domains to invoke SYSTEM_SUSPEND; for the
  hardware domain, PSCI_NOT_SUPPORTED is returned to avoid halting the
  system in hwdom_shutdown() called from domain_shutdown
- Ensures all secondary VCPUs of the calling domain are offline before
  allowing suspend due to PSCI spec
- the domain is shut down with SHUTDOWN_suspend, and resumes execution at
  the address provided during suspend by guest

Usage:

For Linux-based guests, suspend can be initiated with:
    echo mem > /sys/power/state
or via:
    systemctl suspend

Resuming the guest is performed from control domain using:
      xl resume 

Signed-off-by: Mykola Kvach 
---
Changes in V5:
- don't use standby mode, restore execution in a provided by guest point
- move checking that all CPUs, except current one, are offline to after
  pausing the vCPUs
- provide ret status from arch_domain_shutdown and handle it in
  domain_shutdown
- adjust VPSCI_NR_FUNCS to reflect the number of newly added PSCI functions

Changes in V4:
Dropped all changes related to watchdog, domain is marked as shutting
down in domain_shutdown and watchdog timeout handler won't trigger
because of it.

Previous versions included code to manage Xen watchdog timers during suspend,
but this was removed. When a guest OS starts the Xen watchdog (either via the
kernel driver or xenwatchdogd), it is responsible for managing that state
across suspend/resume. On Linux, the Xen kernel driver properly stops the
watchdog during suspend. However, when xenwatchdogd is used instead, suspend
handling is incomplete, potentially leading to watchdog-triggered resets on
resume. Xen leaves watchdog handling to the guest OS and its services.

Dropped all changes related to VCPU context, because instead domain_shutdown
is used, so we don't need any extra changes for suspending domain.

Changes in V3:
Dropped all domain flags and related code (which touched common functions like
vcpu_unblock), keeping only the necessary changes for Xen suspend/resume, i.e.
suspend/resume is now fully supported only for the hardware domain.
Proper support for domU suspend/resume will be added in a future patch.
This patch does not yet include VCPU context reset or domain context
restoration in VCPU.
---
 xen/arch/arm/include/asm/perfc_defn.h |  1 +
 xen/arch/arm/include/asm/psci.h       |  2 +
 xen/arch/arm/include/asm/vpsci.h      |  2 +-
 xen/arch/arm/mmu/p2m.c                |  6 +-
 xen/arch/arm/vpsci.c                  | 96 +++++++++++++++++++++++----
 5 files changed, 92 insertions(+), 15 deletions(-)

diff --git a/xen/arch/arm/include/asm/perfc_defn.h b/xen/arch/arm/include/asm/perfc_defn.h
index effd25b69e..8dfcac7e3b 100644
--- a/xen/arch/arm/include/asm/perfc_defn.h
+++ b/xen/arch/arm/include/asm/perfc_defn.h
@@ -33,6 +33,7 @@ PERFCOUNTER(vpsci_system_reset,        "vpsci: system_reset")
 PERFCOUNTER(vpsci_cpu_suspend,         "vpsci: cpu_suspend")
 PERFCOUNTER(vpsci_cpu_affinity_info,   "vpsci: cpu_affinity_info")
 PERFCOUNTER(vpsci_features,            "vpsci: features")
+PERFCOUNTER(vpsci_system_suspend,      "vpsci: system_suspend")
 
 PERFCOUNTER(vcpu_kick,                 "vcpu: notify other vcpu")
 
diff --git a/xen/arch/arm/include/asm/psci.h b/xen/arch/arm/include/asm/psci.h
index 4780972621..48a93e6b79 100644
--- a/xen/arch/arm/include/asm/psci.h
+++ b/xen/arch/arm/include/asm/psci.h
@@ -47,10 +47,12 @@ void call_psci_system_reset(void);
 #define PSCI_0_2_FN32_SYSTEM_OFF          PSCI_0_2_FN32(8)
 #define PSCI_0_2_FN32_SYSTEM_RESET        PSCI_0_2_FN32(9)
 #define PSCI_1_0_FN32_PSCI_FEATURES       PSCI_0_2_FN32(10)
+#define PSCI_1_0_FN32_SYSTEM_SUSPEND      PSCI_0_2_FN32(14)
 
 #define PSCI_0_2_FN64_CPU_SUSPEND         PSCI_0_2_FN64(1)
 #define PSCI_0_2_FN64_CPU_ON              PSCI_0_2_FN64(3)
 #define PSCI_0_2_FN64_AFFINITY_INFO       PSCI_0_2_FN64(4)
+#define PSCI_1_0_FN64_SYSTEM_SUSPEND      PSCI_0_2_FN64(14)
 
 /* PSCI v0.2 affinity level state returned by AFFINITY_INFO */
 #define PSCI_0_2_AFFINITY_LEVEL_ON      0
diff --git a/xen/arch/arm/include/asm/vpsci.h b/xen/arch/arm/include/asm/vpsci.h
index 0cca5e6830..69d40f9d7f 100644
--- a/xen/arch/arm/include/asm/vpsci.h
+++ b/xen/arch/arm/include/asm/vpsci.h
@@ -23,7 +23,7 @@
 #include 
 
 /* Number of function implemented by virtual PSCI (only 0.2 or later) */
-#define VPSCI_NR_FUNCS  12
+#define VPSCI_NR_FUNCS  14
 
 /* Functions handle PSCI calls from the guests */
 bool do_vpsci_0_1_call(struct cpu_user_regs *regs, uint32_t fid);
diff --git a/xen/arch/arm/mmu/p2m.c b/xen/arch/arm/mmu/p2m.c
index 67296dabb5..f9c09a49e2 100644
--- a/xen/arch/arm/mmu/p2m.c
+++ b/xen/arch/arm/mmu/p2m.c
@@ -6,6 +6,8 @@
 #include 
 #include 
 
+#include 
+
 #include 
 #include 
 #include 
@@ -198,7 +200,9 @@ void dump_p2m_lookup(struct domain *d, paddr_t addr)
  */
 void p2m_save_state(struct vcpu *p)
 {
-    p->arch.sctlr = READ_SYSREG(SCTLR_EL1);
+    if ( !(p->domain->is_shutting_down &&
+           p->domain->shutdown_code == SHUTDOWN_suspend) )
+        p->arch.sctlr = READ_SYSREG(SCTLR_EL1);
 
     if ( cpus_have_const_cap(ARM64_WORKAROUND_AT_SPECULATE) )
     {
diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
index 7ba9ccd94b..c6b9ac1fc8 100644
--- a/xen/arch/arm/vpsci.c
+++ b/xen/arch/arm/vpsci.c
@@ -10,28 +10,18 @@
 
 #include 
 
-static int do_common_cpu_on(register_t target_cpu, register_t entry_point,
+static int do_setup_vcpu_ctx(struct vcpu *v, register_t entry_point,
                             register_t context_id)
 {
-    struct vcpu *v;
     struct domain *d = current->domain;
     struct vcpu_guest_context *ctxt;
     int rc;
     bool is_thumb = entry_point & 1;
-    register_t vcpuid;
-
-    vcpuid = vaffinity_to_vcpuid(target_cpu);
-
-    if ( (v = domain_vcpu(d, vcpuid)) == NULL )
-        return PSCI_INVALID_PARAMETERS;
 
     /* THUMB set is not allowed with 64-bit domain */
     if ( is_64bit_domain(d) && is_thumb )
         return PSCI_INVALID_ADDRESS;
 
-    if ( !test_bit(_VPF_down, &v->pause_flags) )
-        return PSCI_ALREADY_ON;
-
     if ( (ctxt = alloc_vcpu_guest_context()) == NULL )
         return PSCI_DENIED;
 
@@ -78,11 +68,32 @@ static int do_common_cpu_on(register_t target_cpu, register_t entry_point,
     if ( rc < 0 )
         return PSCI_DENIED;
 
-    vcpu_wake(v);
-
     return PSCI_SUCCESS;
 }
 
+static int do_common_cpu_on(register_t target_cpu, register_t entry_point,
+                            register_t context_id)
+{
+    int rc;
+    struct vcpu *v;
+    struct domain *d = current->domain;
+    register_t vcpuid;
+
+    vcpuid = vaffinity_to_vcpuid(target_cpu);
+
+    if ( (v = domain_vcpu(d, vcpuid)) == NULL )
+        return PSCI_INVALID_PARAMETERS;
+
+    if ( !test_bit(_VPF_down, &v->pause_flags) )
+        return PSCI_ALREADY_ON;
+
+    rc = do_setup_vcpu_ctx(v, entry_point, context_id);
+    if ( rc == PSCI_SUCCESS )
+        vcpu_wake(v);
+
+    return rc;
+}
+
 static int32_t do_psci_cpu_on(uint32_t vcpuid, register_t entry_point)
 {
     int32_t ret;
@@ -197,6 +208,52 @@ static void do_psci_0_2_system_reset(void)
     domain_shutdown(d,SHUTDOWN_reboot);
 }
 
+static void do_resume_on_error(struct domain *d)
+{
+    struct vcpu *v;
+
+    spin_lock(&d->shutdown_lock);
+
+    d->is_shutting_down = d->is_shut_down = 0;
+    d->shutdown_code = SHUTDOWN_CODE_INVALID;
+
+    for_each_vcpu ( d, v )
+    {
+        if ( v->paused_for_shutdown )
+            vcpu_unpause(v);
+        v->paused_for_shutdown = 0;
+    }
+
+    spin_unlock(&d->shutdown_lock);
+}
+
+static int32_t do_psci_1_0_system_suspend(register_t epoint, register_t cid)
+{
+    int ret;
+    struct vcpu *v;
+    struct domain *d = current->domain;
+
+    /* Drop this check once SYSTEM_SUSPEND is supported in hardware domain */
+    if ( is_hardware_domain(d) )
+        return PSCI_NOT_SUPPORTED;
+
+    domain_shutdown(d, SHUTDOWN_suspend);
+
+    /* Ensure that all CPUs other than the calling one are offline */
+    for_each_vcpu ( d, v )
+        if ( v != current && is_vcpu_online(v) )
+        {
+            do_resume_on_error(d);
+            return PSCI_DENIED;
+        }
+
+    ret = do_setup_vcpu_ctx(current, epoint, cid);
+    if ( ret != PSCI_SUCCESS )
+        do_resume_on_error(d);
+
+    return ret;
+}
+
 static int32_t do_psci_1_0_features(uint32_t psci_func_id)
 {
     /* /!\ Ordered by function ID and not name */
@@ -214,6 +271,8 @@ static int32_t do_psci_1_0_features(uint32_t psci_func_id)
     case PSCI_0_2_FN32_SYSTEM_OFF:
     case PSCI_0_2_FN32_SYSTEM_RESET:
     case PSCI_1_0_FN32_PSCI_FEATURES:
+    case PSCI_1_0_FN32_SYSTEM_SUSPEND:
+    case PSCI_1_0_FN64_SYSTEM_SUSPEND:
     case ARM_SMCCC_VERSION_FID:
         return 0;
     default:
@@ -344,6 +403,17 @@ bool do_vpsci_0_2_call(struct cpu_user_regs *regs, uint32_t fid)
         return true;
     }
 
+    case PSCI_1_0_FN32_SYSTEM_SUSPEND:
+    case PSCI_1_0_FN64_SYSTEM_SUSPEND:
+    {
+        register_t epoint = PSCI_ARG(regs,1);
+        register_t cid = PSCI_ARG(regs,2);
+
+        perfc_incr(vpsci_system_suspend);
+        PSCI_SET_RESULT(regs, do_psci_1_0_system_suspend(epoint, cid));
+        return true;
+    }
+
     default:
         return false;
     }
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Fri Jun 27 11:24:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 11:24:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027539.1402162 (Exim 4.92)
	(envelope-from )
	id 1uV7BQ-0000gk-Em; Fri, 27 Jun 2025 11:23:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027539.1402162; Fri, 27 Jun 2025 11:23:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uV7BQ-0000gd-Ak; Fri, 27 Jun 2025 11:23:52 +0000
Received: by outflank-mailman (input) for mailman id 1027539;
 Fri, 27 Jun 2025 11:23: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 1uV7BN-0000gX-TR
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 11:23:50 +0000
Received: from NAM02-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam02on2061d.outbound.protection.outlook.com
 [2a01:111:f403:2405::61d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2e25e031-5349-11f0-b894-0df219b8e170;
 Fri, 27 Jun 2025 13:23:43 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by DS2PR12MB9687.namprd12.prod.outlook.com (2603:10b6:8:27b::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8880.21; Fri, 27 Jun
 2025 11:23:40 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8857.026; Fri, 27 Jun 2025
 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: 2e25e031-5349-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=RKGNHJAuXKX0NI/yq/Gah7/WINvTaYQ/R0nAqdzilBSigibbCJT9gu1KPw89V4+8+QWsHG6XK/l+rfcKKccpQhnoHWeK704PCGOOi0B4eCpxAa9JNfVr9mDVa6y07m3ekq8mJZ38wI/VBGP1cuacIoFxlktkiozG/4NZfM2vAZ6AT5EW8Sn0xxhVSMF/pUADNI4sfcT8cu80//RneA92gGQT2hkvhlV5EXkcqer/pbKg+gyVE4Xkt4Qxx5hYIPxwDAo3snC08FtqyC4QqT5kbVxtskRLn5tqiVLlS54Am4fFkjwabiZ/zLiCh7Hoi0zm6EnitlAcZLimh6EeDKsyPA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=IWolXwCXDNgqHv5el06xfZsvUUmU6+9JZ7OoOgw+zyc=;
 b=wJ+qg0fe4K8tyz1qswAJzLgkXnRm1hOufZDGhUgb28qvzBF+d5tk//A17Mf6D4hgCIMvvCEH4NPYtXmLr7ViV3EBB37PKVBPa+w76uyXpKJxTP5b3gOWms4C3tIbrKGh/h8kNkI9Nz+eA1lRStsgKD6MypNeaWpsN5TNrvO6diBXaj/NCrbB4W1LbX92TJ1x878X4dMnSsbKFRU8VTdeB0cOXLV7DzAOnJtahMzDaCiannAPSLL6upY70zk9knIXedTPwYwOnAiYDZiuSP6ggSgO6NvYxpnW/MPYa9fosLLxyPFqvwSMru4bL6IjfA4DniHqocQcebwu6Duj8qy8KA==
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=IWolXwCXDNgqHv5el06xfZsvUUmU6+9JZ7OoOgw+zyc=;
 b=ajkBjV7thEeLJv4wNF5bhjpyhURkXTAIWdBOL1Cp48pg5WGePlg2fKebTcT8KTdMmfzNKuhLUUh3ksbjWRQxxhi3dhM4INFQjMeP+aK2WUe9uhFJ+Pu9TFvif41NVbEhihPY3ZGFSjhEeQnKsgT1T8/m0NgtgrXu+nF+whzfmGM=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Fri, 27 Jun 2025 13:23:36 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/6] arm/mpu: Find MPU region by range
To: Hari Limaye , xen-devel@lists.xenproject.org
Cc: luca.fancellu@arm.com, Stefano Stabellini ,
 Julien Grall , Bertrand Marquis ,
 Volodymyr Babchuk 
References: 
 
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR2P281CA0097.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:9c::12) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|DS2PR12MB9687:EE_
X-MS-Office365-Filtering-Correlation-Id: be3be1d3-1bd3-434d-2db4-08ddb56d10ac
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?c3lkbEdtWXBuWWp2QnNHeFVMdTNzdXg0cHVjYiszTk1uN3JUdVdQNS95a0Iz?=
 =?utf-8?B?NkhBeExWMmRTZ1hGYy9LNDZhcmlVNXlUWWUxWWk4dEpmMHFqbHRPeXR1WGV6?=
 =?utf-8?B?TU16RHJ2UG9FMExSSkZmVGs4NkcyMXRIVW12TU1HMGM5RWFqd093b1FmamRJ?=
 =?utf-8?B?V0wrL25wVitEL21IZVZzaHIwRDhvWHBrUVZ5MDBVRzRzdlBLMkNNa0tqWkE4?=
 =?utf-8?B?RWlqamtZQUZ0Ni9xbVVGR3l6M0wwcXdieGVrZmYyMVpqeEF5cmJJZTRrdFlZ?=
 =?utf-8?B?SGdFVldyWG9HeEYzWmVCQzJFWFZIZi94TFpnZWdHRFFhR0p3eFpHTllFc3Z0?=
 =?utf-8?B?Ris3YldUdit1bWY3cXJ1YlA4NzBheVAzYXJoTXlZQjFpeG5zOFVoY3hHVDcv?=
 =?utf-8?B?b1RuK3laeU5aZithSnA1WlF6a0Z0SXZDa3VFaTRMcmdJbFk0Tlcza0NWaE5z?=
 =?utf-8?B?cjhSL25BMXVKQnFJUklWL045bmZUTFhiQ2NDZHBhYkxUR0wrZ0x4bkNiN21Y?=
 =?utf-8?B?OGdJMVAwczVaTWhxajZkemtrWVNSbjFYOGxvV0t5TDhBUHU1Tnk3OCtZaGV4?=
 =?utf-8?B?SXJQSGR5RzF5RDJlaWhQTlJHVnNQV2R5cURsVEVnYnhwN2tNRWpGL29nVnJP?=
 =?utf-8?B?N3VKKzcxUTVRbmM5REIyUGF1UFdqanY2Z3FsWEhoUEJpVSt2eVgrTFFjSTF5?=
 =?utf-8?B?MlZ0S0tRSmx1WHJnYTAxYVpYaUNIOVh3WGRYR1pmc0FsUElNVHA2WExGZmJ0?=
 =?utf-8?B?NkpNME52dTNDeWtydExzdEdJTFFTMUYrMzUrK0dOeXFjcGNSaWczUlBLSlVi?=
 =?utf-8?B?NVB6VDJQSHpWNHlxaUprUy9oOWlBQUFzS1ZiYUJ6VEFMZHY3bEg3THJLTlMw?=
 =?utf-8?B?NmM3ck1vRGZUeUo0M3RjK1l3a2lMdFpFYkllMEJFRzJCUHV1dVd4TjdBbXl0?=
 =?utf-8?B?aVhnbU5RZ2JEdEREclpvdDk2YnA3OTBnQnlHV1IzVVhuOWJVcWRZOUVOcWVy?=
 =?utf-8?B?TUZ0OUMrM2FGOWxxNXMwckxRSFdPTlZZZWhtQjhYQ0pSREZNR2oyeHozclZG?=
 =?utf-8?B?NDNMMnZmUlVxbW54VThyVTZ0OTlrc25tbFdpN0d4aUpqSWRaeEJVbDZNSzNh?=
 =?utf-8?B?UWd6SytGK1hpYTNvNWdveWdpdS9QOG45R25RSjNidm1mNGhmd3Bpa3dUWDRu?=
 =?utf-8?B?OHJpUmZkVG04T0pUZUU2TVZTbXRDOVg2L0Z0Q0I0dXRpYzI3OGovb1haUU1C?=
 =?utf-8?B?b3pJS3oxM0t5cFBqS3I3ci9Qc2QrNWNURmhod1R2blJsNU5DYVRJVE5YWDFE?=
 =?utf-8?B?d1RkKzhiNEhlUEdUYVlndWhsSWpxbCs0QmhPUkh1cXFjNWhESzE5cGczYWJU?=
 =?utf-8?B?SXNjdWR6RnpxSGtmQ1FhWXlnNzBCdk9xQUdNUVVwRDBoRFZWNmw1Q1ZwVThr?=
 =?utf-8?B?OUJxT3c4WWVMeWRKK0EydXdWYm9hMFFCQXFYZ2xnZUh5L3hYeWwwb284eUN4?=
 =?utf-8?B?T1ZJeU4vazNSU3QyMDlxNnM4Z0NqL3hxaVJsS2lOWndXSFNnWUpTd3pSSHVC?=
 =?utf-8?B?cG80NmlBOVkzOTl4ZTlnOG1CTXhNYU1QV0YyVnp4Zm0vUE1BTzM1ZGRzcExV?=
 =?utf-8?B?SmRERnZjaTExZlk3YkZVaXJBTmFXWmhtNndlamxVcnhKSldJY1lEOUllOGxP?=
 =?utf-8?B?aVdvakowQlRUMkpOblJ2OFRVZnJSVno2Um41SUJGdWdOQ2lGR3R4WmhkOTlM?=
 =?utf-8?B?TjhYOU51WjhtSi9IRHNpNndIK3dYaVIydzJzaU5wMHI2cFp4S3ErQnFQMWwv?=
 =?utf-8?B?VzRrbEJMMXJMVG5yazRFUE96M094WTRtMEIzZkNBSWJUS1Iyd2hZa285WHRz?=
 =?utf-8?B?NXl2bmtwcVBZdmdWQmZzSG5wUGNHMTkvamJIRzNUdDFPRkRQK0hIK2Uray81?=
 =?utf-8?Q?1a+X+AnbATo=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?QWI5MEFjN1cvdXZ6c1Z1ZDA5TjIvWTZmQzF2ZjR0Y3JmZWNxV1RsTW1VTXdC?=
 =?utf-8?B?anB4WjFCTTNqZ3BxWWx2emQ4NkpVU2p1NTdUZ1N4YXdRSE8ra2k5SEdIdWJT?=
 =?utf-8?B?L2ErV1VJTXZMRktRbFFkZG5xMC84NENzdmpPeW5rYTU5ZWxIQ2dKL2dxRWRz?=
 =?utf-8?B?V3Q4cStyUWhwUWZNUnBJMVIyUzE4Wm0wYzVzME8veit6Ym5CQW9EVDFyazdZ?=
 =?utf-8?B?WEYvQ00rSk9ZejRjK2tGOHEzaU8ySEE0a2JtTjc1UlRJbFBMRnBvUFlrTGhq?=
 =?utf-8?B?bGpRUGc3TWYxMnRmVzE2cUl1V1pjMFRtdTNWMDRjSGdmL3VrRmFBS2F2SjMw?=
 =?utf-8?B?QVg0YVppRHdhU3JFbXRKTFdHNVh1ckUyMDF0RE5IRmZmVFVqYWxkcEJFK3g5?=
 =?utf-8?B?WWt5ckc0RXl3Mk5jcWJ6eVJ5cEdzWTBYNE9YaFl1Y3BBY0w0YnlDRks4M1kr?=
 =?utf-8?B?dTdXRE5DVWh4QzI3S2FSNUlBT0dDU3Yzdm94MlltRnBIV0dDMjdFQWpXZ3Nq?=
 =?utf-8?B?cHpyNGVRK3M2cnZuaHFZdzZlcmxjclBYVEpTWG1kUGhOdEVkSWRXamR1UjhB?=
 =?utf-8?B?dEczc1pKMnh3czhDQWpTQStvNmU2elJyNTd0MVRZcXdQWCtMTkQrNzRxaFNo?=
 =?utf-8?B?MUY4bytxSHU4TW5VeEg1VWt1Q3pFdy9teENUMGpBbzdrTkpWM2xEaVA3ZjFx?=
 =?utf-8?B?OW8wZ2dpSWttS3V1Qis1bFVqdzZkZGVReTJvK1pnb0dMSENtb3pGZ0NHK05o?=
 =?utf-8?B?anNJSkJxQ1dmNC91OUI0aGFkSHJpR0w0VzJjTlp2WHRpYXlrYkxhN0czUVJp?=
 =?utf-8?B?RVRBRkRDaGFNTjF5UmRXbnAvWldKRmkxUEpBMXBRRzFmVHJBbnhLcG5lWmxv?=
 =?utf-8?B?S3F1UHNTS2ErWWV3MDJyNkpsQlFuTVBlcHpBa0luRXZhNzBLSEJ1OTh6WjRR?=
 =?utf-8?B?RUlNamNYQzNEdWFRbU5ZRmREMUhJd3cvT3YwbXlPcWhwQjQ2Tlc5aHVXZk0v?=
 =?utf-8?B?TXcxWmVXNHkzMDVQRndnNGoxSHg3eWpob1o4VW1lN0ovZ0lUdkRnNUh1T0lU?=
 =?utf-8?B?aUVNWG00dWFXQ0FpWlNCNTE2a1UwNWsrcm5DOXRSSTRyeXFJNHptaG5xeVBQ?=
 =?utf-8?B?WTBvQldBRVcvWUFHRElNdWYyOWkzelEvaDVzUFE1L3BEV3hPTHFmYUJtSnBh?=
 =?utf-8?B?Z3FLN0N1QnF2bDJ4T25oYnBtMmdzTHNqN3JjRkMrMEZjdFhKKzA5Y2NDVkQ2?=
 =?utf-8?B?eVN1dFNnSDlIb2hnbkUwSWJrdFhjbkhQbE9NVWRnTm5ZNnU3aG9oak5CM3E2?=
 =?utf-8?B?T0JSc0NYVk1TR3F5aHJYbjk4YUVEZ3d0Q1YzWTZ6NGVqU3haWjBHSm5WZmxu?=
 =?utf-8?B?U3RVaUhLQU4wRW11c3BsSUVkK2grckx1cXRtSkxQaERKZHlNQk9UeGRaaVhn?=
 =?utf-8?B?cVlHL2NFSmlFdVVBWExtNlpGSUxWUHQzVTJmTjFHSTk4djJBNjNDdjZxZEJ3?=
 =?utf-8?B?K0dKYlFPZHcwQ0dzak5qUFlsVEE2SzZqemp3cGdtWWFTM29uZlU0QnZOdnVR?=
 =?utf-8?B?Q0hYSXdIZXNRWEErUFNHdjQ3amF5ZHB2aEVGamRhSi94aWllSkU0ZnpCWUZq?=
 =?utf-8?B?TTBoMUdjamk0blhrbGhkbEM1ZWtKM2M1WUdBdTBWaTJvUzlQSzYydFZkaFQw?=
 =?utf-8?B?aVpJMTY2YjcvU2s0eU1JWkg2bEhTbjlYVW1jTkdxU21yS0czUkgzaEw2ZWtm?=
 =?utf-8?B?eUd6aFpERkJwUW5hYU1RbXFyQXU3MWh4VjcvR25YSUwxSGxNR0hZMS9oMG5y?=
 =?utf-8?B?YVhSeVVnT09XL0lYSVYwOWZ4bzlSN2FvcWQ0MU1vNGJNOGN3bnY5V0lITko3?=
 =?utf-8?B?QldDQnlQbUMzMzg2em1Bb2J3eExPMlJ2R2o2RzdCVWlPZ0xYWVBhRFY1NGll?=
 =?utf-8?B?TzAvWVc2YTR2Zm9saVRpaGRGU3UxaGlSdUp4Y1BSL1ZDK2Zwa2dzL2Q0a1Uz?=
 =?utf-8?B?R2oyOENEM2tWSGNiNFJFeUJHcHh2KzZlK3FLZnUyS0xrS2U3cHBwSFdIMXk5?=
 =?utf-8?B?Ykwvb1dMdUF1Ynl0eFZsTVpzbTVac0VBbk4rM1dJUlk3V0RqM0FQY2NNY1l0?=
 =?utf-8?Q?U0pl7ACOfFr0/E6Ml0+spDw6o?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: be3be1d3-1bd3-434d-2db4-08ddb56d10ac
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jun 2025 11:23:39.4488
 (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: ZwytfK1Qe1IML4rDCPgTWyLzI1n3mDEUhRPiD84+ZgP0lDQXnCX6NQF/SKDc7PMh
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS2PR12MB9687



On 20/06/2025 11:49, Hari Limaye wrote:
> From: Luca Fancellu 
> 
> Implement a function to find the index of a MPU region
> in the xen_mpumap MPU region array.
The commit msg should also mention why a change is needed.

> 
> Signed-off-by: Luca Fancellu 
> Signed-off-by: Hari Limaye 
> ---
>  xen/arch/arm/include/asm/mpu/mm.h | 29 ++++++++++++++
>  xen/arch/arm/mpu/mm.c             | 66 +++++++++++++++++++++++++++++++
>  2 files changed, 95 insertions(+)
> 
> diff --git a/xen/arch/arm/include/asm/mpu/mm.h b/xen/arch/arm/include/asm/mpu/mm.h
> index a7f970b465..a0f0d86d4a 100644
> --- a/xen/arch/arm/include/asm/mpu/mm.h
> +++ b/xen/arch/arm/include/asm/mpu/mm.h
> @@ -10,6 +10,13 @@
>  #include 
>  #include 
>  
> +#define MPUMAP_REGION_OVERLAP      -1
> +#define MPUMAP_REGION_NOTFOUND      0
> +#define MPUMAP_REGION_FOUND         1
> +#define MPUMAP_REGION_INCLUSIVE     2
> +
> +#define INVALID_REGION_IDX     0xFFU
> +
>  extern struct page_info *frame_table;
>  
>  extern uint8_t max_mpu_regions;
> @@ -75,6 +82,28 @@ void write_protection_region(const pr_t *pr_write, uint8_t sel);
>   */
>  pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags);
>  
> +/*
> + * Checks whether a given memory range is present in the provided table of
> + * MPU protection regions.
> + *
> + * @param table         Array of pr_t protection regions.
> + * @param r_regions     Number of elements in `table`.
NIT: in other places you refer to already mentioned parameters using #param and
not `param`.

> + * @param base          Start of the memory region to be checked (inclusive).
> + * @param limit         End of the memory region to be checked (exclusive).
> + * @param index         Set to the index of the region if an exact or inclusive
> + *                      match is found, and INVALID_REGION otherwise.
> + * @return: Return code indicating the result of the search:
> + *          MPUMAP_REGION_NOTFOUND: no part of the range is present in #table
> + *          MPUMAP_REGION_FOUND: found an exact match in #table
> + *          MPUMAP_REGION_INCLUSIVE: found an inclusive match in #table
> + *          MPUMAP_REGION_OVERLAP: found an overlap with a mapping in #table
> + *
> + * Note: make sure that the range [#base, #limit) refers to the half-open
> + * interval inclusive of #base and exclusive of #limit.
What does half-open interval mean?

> + */
> +int mpumap_contain_region(pr_t *table, uint8_t nr_regions, paddr_t base,
NIT: mpumap is a table (singular), so it should be s/contain/contains

> +                          paddr_t limit, uint8_t *index);
> +
>  #endif /* __ARM_MPU_MM_H__ */
>  
>  /*
> diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
> index ccfb37a67b..15197339b1 100644
> --- a/xen/arch/arm/mpu/mm.c
> +++ b/xen/arch/arm/mpu/mm.c
> @@ -12,6 +12,18 @@
>  #include 
>  #include 
>  
> +#ifdef NDEBUG
> +static inline void __attribute__ ((__format__ (__printf__, 1, 2)))
> +region_printk(const char *fmt, ...) {}
> +#else /* !NDEBUG */
> +#define region_printk(fmt, args...)         \
> +    do                                      \
> +    {                                       \
> +        dprintk(XENLOG_ERR, fmt, ## args);  \
> +        WARN();                             \
> +    } while (0)
> +#endif /* NDEBUG */
> +
>  struct page_info *frame_table;
>  
>  /* Maximum number of supported MPU memory regions by the EL2 MPU. */
> @@ -110,6 +122,60 @@ pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags)
>      return region;
>  }
>  
> +int mpumap_contain_region(pr_t *table, uint8_t nr_regions, paddr_t base,
> +                          paddr_t limit, uint8_t *index)
> +{
> +    uint8_t i = 0, _index;
Why underscore? I don't know what MISRA thinks of this but looks similar to
reserve identifiers and I don't think there is a need to use it here.

> +
> +    /* Allow index to be NULL */
> +    index = index ? index : &_index;
If index argument is NULL, why bother setting this internal variable _index?

> +
> +    /* Inside mpumap_contain_region check for inclusive range */
What does this comment supposed to mean (we are already in this function)

> +    limit = limit - 1;
> +
> +    *index = INVALID_REGION_IDX;
> +
> +    if ( limit < base )
> +    {
> +        region_printk("Base address 0x%"PRIpaddr" must be smaller than limit address 0x%"PRIpaddr"\n",
Why not normal printk? I think it's important to see such message.

Also %# is preferred over 0x%

> +                      base, limit);
> +        return -EINVAL;
> +    }
> +
> +    for ( ; i < nr_regions; i++ )
> +    {
> +        paddr_t iter_base = pr_get_base(&table[i]);
> +        paddr_t iter_limit = pr_get_limit(&table[i]);
> +
> +        /* Found an exact valid match */
> +        if ( (iter_base == base) && (iter_limit == limit) &&
> +             region_is_valid(&table[i]) )
I think the check for valid region should be first. No need for other two if
region is invalid. Also, shouldn't we check for region being valid right at the
start of the loop?

> +        {
> +            *index = i;
> +            return MPUMAP_REGION_FOUND;
> +        }
> +
> +        /* No overlapping */
> +        if ( (iter_limit < base) || (iter_base > limit) )
> +            continue;
> +
> +        /* Inclusive and valid */
> +        if ( (base >= iter_base) && (limit <= iter_limit) &&
> +             region_is_valid(&table[i]) )
> +        {
> +            *index = i;
> +            return MPUMAP_REGION_INCLUSIVE;
> +        }
> +
> +        /* Overlap */
> +        region_printk("Range 0x%"PRIpaddr" - 0x%"PRIpaddr" overlaps with the existing region 0x%"PRIpaddr" - 0x%"PRIpaddr"\n",
> +                      base, limit + 1, iter_base, iter_limit + 1);
> +        return MPUMAP_REGION_OVERLAP;
> +    }
> +
> +    return MPUMAP_REGION_NOTFOUND;
> +}
> +
>  void __init setup_mm(void)
>  {
>      BUG_ON("unimplemented");

~Michal



From xen-devel-bounces@lists.xenproject.org Fri Jun 27 11:31:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 11:31:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027562.1402171 (Exim 4.92)
	(envelope-from )
	id 1uV7Ig-0002Qb-7Z; Fri, 27 Jun 2025 11:31:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027562.1402171; Fri, 27 Jun 2025 11:31: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 1uV7Ig-0002QU-53; Fri, 27 Jun 2025 11:31:22 +0000
Received: by outflank-mailman (input) for mailman id 1027562;
 Fri, 27 Jun 2025 11:31: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 1uV7If-0002QO-7d
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 11:31:21 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20631.outbound.protection.outlook.com
 [2a01:111:f403:2412::631])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3c4d5656-534a-11f0-a30f-13f23c93f187;
 Fri, 27 Jun 2025 13:31:17 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by DS2PR12MB9687.namprd12.prod.outlook.com (2603:10b6:8:27b::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8880.21; Fri, 27 Jun
 2025 11:31:13 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8857.026; Fri, 27 Jun 2025
 11:31: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: 3c4d5656-534a-11f0-a30f-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=vMYVL6zUxiwQ75lGmFF6XiuAqxumWRt4sDgjlYlL1L6RWJkRGTAL7aiLeT2mg+qOXSDmhJUEeJRwzIrKs1W2m9HS6LIa4J4Ym2ua1iSNbK0trq9gzvP5PzzNDyVRsfn7S7gGR5nksM1Dqt1CwALz8gd6nIrwOvqNxF9ENip5JUVVlsyQTt1wUr501rEMBELOHiCVnBLbG1ZRMR+pHSD9OjeBSLEaUNBz6yziF0wTEXLqL4gleETxNDs5Eamer2+Vou2QPA6gzNqY7Zh+youcCxehNUP/nK/jX3XGOjZ23ipKxBMM1fZgnAUg65TDUHc4VitzRw/E1C6TenOCaHjwpQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=SsEPaB386by8MqkeC4YIuTeuzHEcNVqvtb0Vf0KcAzg=;
 b=cj+XZBAAblgYiFpob7980e8bYviCccT+ClafsSGoxfZ+8Hj9EjCCHAMBRKRKxtQh49f9PYem/W4h3pF101qzQK4lYe0YydpnU0h+FCge2hoaulOg8bzTD4RiYSEacNWpzdMzlAr1gyPl6AX30Ym94YpHALc2GmLbVKA8o6XPBqpkO01EaB2tQ46yhzOwnDc1H3+7L1dh1QppGEiht8YqU+nKxBkG9hDeyAV/MobMhtMx69HfSGHsj0jDPO57hSzL5sgbGE+3bMEmrtGqfDR0SSA8ePOMZNXPlsLWCHzYNkizLj1FGUHqNY0AeE9S2EWOd0qmomI19WRf6/Thdua7qA==
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=SsEPaB386by8MqkeC4YIuTeuzHEcNVqvtb0Vf0KcAzg=;
 b=KefNA0oyMtO9aRvJb5iWrwh+nr9MFs76Lb/PpzmGav3mhxCGT5uzdCoiSvWxzRPHq+xz85uXXBM0Hbo+3hIycPbMoAhBI1qO3bXSsruR5/aC/8A+IkINHM1pDwFnPi0nKIr6zEUlYA07Tv4To22+kDNYOBJi+kEfcf4Gkez1WvI=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <24d213e6-27c8-46d2-89ec-2023b9f8fc56@amd.com>
Date: Fri, 27 Jun 2025 13:31:07 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/6] xen/arm: Introduce flags_has_rwx helper
To: Hari Limaye , xen-devel@lists.xenproject.org
Cc: luca.fancellu@arm.com, Stefano Stabellini ,
 Julien Grall , Bertrand Marquis ,
 Volodymyr Babchuk 
References: 
 
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR4P281CA0076.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:cd::20) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|DS2PR12MB9687:EE_
X-MS-Office365-Filtering-Correlation-Id: 06d8349f-6d42-490f-cea9-08ddb56e1d92
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?VWYyUzY4VWpjdHBLZEVQNUN3WkUzZ3RlTWtJM3crMWRWWnFva0w1RE0weUN4?=
 =?utf-8?B?MThNVmQ1K1RkbUFFb0tpL2E1WVdYbktEUnREYmtzNVJzeFBEbG0zMGxIYWV6?=
 =?utf-8?B?TDYxSWozQ1pLWDNlS3lMK01tU0VoRE9SZlBzSnljT0VBNEV0VWdENWFUbTdh?=
 =?utf-8?B?bmJLTzkzekozZ0NvMm9sOWtTaEd0dnJaUi90c0NxRzlUUzhFOFJHdGxpSmt6?=
 =?utf-8?B?ek9oUnlnS2lwbnRGbzNFMENLSkF1SGg0NjRhaDE0dG9aOGV5THk3Vk91WTM5?=
 =?utf-8?B?SG5ZMXlTaVFwRll5Kzg0U2Uyb20xVDBYRStMbER3ZHhpSFQzMGtyaVlnNGlv?=
 =?utf-8?B?TlRoSlVpa1JGc2IzWDBZVDZ0eWNwVUxuOTJPM0J2TEVnc0s3SVVOcS83WDlL?=
 =?utf-8?B?dXRBR1BZS0gvYzRFNlhIelBJY2pDaHIyc1dBSnZqaWJNcHByS0Q1RitFblQv?=
 =?utf-8?B?OElWbXluWjMyWWpKbVNqS3JLZUJScVpNdWVoNlVDQk9nMUl2cDdPVHNXWDV3?=
 =?utf-8?B?ZkxrYXo5Q3FQa2Z2QkFvR0M3eGVac0lZQk5hYjFpdTdwdUFUaFNrNVFJYUJQ?=
 =?utf-8?B?WHgybi9MbXF5L3BUTkNsalFVSmVpVzc3dDVnQ1hEMnFJcHFyUERqaFJqZytu?=
 =?utf-8?B?MFF4RlZPbWVQQVk1Nk1PTGhQT0hTUEtabExGQjBlMnFPTEJ5NGg1NmZjR2RS?=
 =?utf-8?B?VGJOaENWQ2JnRFM5WUVpV3UvZ0NCSG9FY3JxMzBtRm1YQVpDY3JnVmttTjJU?=
 =?utf-8?B?YnBXaU94QWpwc2ZHcVJnbEZkN1V5RjFCcmYxZ2hOenNnZXZQZ0RkV1ltd1ll?=
 =?utf-8?B?TS9iQ2RLMllkTW90MmhKdUY3dmEzdTBWcFdHMHZQY25nN3RsOSsvVG0vYTlM?=
 =?utf-8?B?QTNwZEFpNnRVeHFIOVpLNTJrR2NPR3lVQWpySXBISmxmbVZoa2xXRUNZUzR0?=
 =?utf-8?B?QmQwaFlIc28zcnpCUndLM0duMmJUV0RTQmZzNlpXUU9XbTFyZlFoamkxajBY?=
 =?utf-8?B?NkNrOGJDNEtlM01rVDA1WlA5TXZJSi9CbWNSdkY2YTAwSGsydFJXbTEwVlBj?=
 =?utf-8?B?TDJERm0rRThCRXhPKzFtbmtwQjljc3RxTVppd3gzUnRKQU14ZHNKem5MU0Ri?=
 =?utf-8?B?UUdRK3BXTlZRd2drdjhENHNISnBRSHp0YUtyMFYyNTZKWnFPNWpCZ3MvbmVV?=
 =?utf-8?B?QmlXRmRKbVNJU3hlN2xySXhvVEw4bnBiS0h3Z3NrVGZuSnJlZXRYMnBrU1ZR?=
 =?utf-8?B?dTB1NmtxNVZ5Y1kyQ3lWMU12TEozc3NnaXBJeU9vVFhxeFMxd1pYOHFxK2dS?=
 =?utf-8?B?blJITGtrVzVZSGwxTWhZL2lUd2d1ZTZodzJLQ3Y5bU41RE1DTlptZHJmUkxU?=
 =?utf-8?B?a3BVYXBYU0lmdmxMVCt0SmhjZVpndjF3MGhPMTh4aVA4d3luVktGSHBXUFJH?=
 =?utf-8?B?clpwTG1qdUZQTTVIa3k1YWF2NitpYjZhWm5rajlGdjg2cmNYTllCazgrVzMv?=
 =?utf-8?B?ZVg5eHd4KzE1R2R4dXJmR2VxMmwxZGR6U1RxbkVhRmNYZWpJRXUzd3o5WEZG?=
 =?utf-8?B?dGRLZ3VjWkZCMXd4SG51a0p4Rzg1T2J4MWRyTkpDcnhBOXNSRGo3YVNreDV3?=
 =?utf-8?B?WGI2N1g4SVZtRW1jNWx0YWZGTGtrTmNQaHUzMUFMWndOMDBIRTRwSmJiUklF?=
 =?utf-8?B?SnJlTVpsM0FmQXdnc1lEYWxETFY1czMySjg5cC8yTnB0RzhBa0dVL2tGS3V6?=
 =?utf-8?B?ejNYTnMvS2xHVDNZZ01NUjZ5Z3ZwNFYxVHNLaThIcFJnWUJZNzEwWGYxRXJG?=
 =?utf-8?B?NitOb2xjWUJEV3RRTHYweG0xWHMzZDhkRWdZU1VaUVJzUDV0cXc4S2t0TGN2?=
 =?utf-8?B?VHN4MFhyZzY3dHVFM2UzMnVPcGlJYVlEd2Nyd1dlR2lrb3JwY1VQNGRKc0Ez?=
 =?utf-8?Q?564r6m7Nm9M=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.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?YXhoenVDNGxDYmRCWWYyMTdlWnhEVkFZMGc2encwMVhFQ3hpQk1JN0FsOU90?=
 =?utf-8?B?L0dHSXBkek5WdWpKb0VuQ0NyNmZGcURTWGJKUGtCNTAvalJyekdsdTJRQVFn?=
 =?utf-8?B?NDdyMUZ2cWNGUE5sdFVEWlI3LzB1NWhPemRPMkJEMkx4bHZpQUg5emg1RURX?=
 =?utf-8?B?M29sMnZLQ2dBRlVrUW1Pc01vaFc3VHZoTHR3blllMGYvMnlzMEFRS25yUlVJ?=
 =?utf-8?B?enk4TXU4bHhXNHlaZkU4Q1FZWnRzYTNzVEMweEU2d3VqOEJmekp6d01ieFlR?=
 =?utf-8?B?NWR1cDY5TEdpUlY0Y2ZocmthWC9ZQkluengyZDhZaUEyV2tSMjZCVms4MnNZ?=
 =?utf-8?B?dzBhemc0bCtMVEY2Wm9tN1VuYit4c2tCQkh0VTE4YWxyOVZWd3liVStUY2kx?=
 =?utf-8?B?MTZmNkNTVFJOa0VJcGdwb0pUaWVxZmFqc05xSEYrZzZLYVplaHA3a2I3OFRC?=
 =?utf-8?B?U241eExQK2xLemVQMEw0SHRFVWMxZ0ViK2JvaEJ0aDlHY2RWVjJnWW45blY5?=
 =?utf-8?B?akljNHV0MVd0akx5bm1zQzZtN1FiZGY1QlczZ0VRRkRjaTlWS0RJeWFHZW82?=
 =?utf-8?B?L0I4VUlmSWVoZTdETVdQUkdTa0FjcEpaenVaRFB1NjNUUEZFOXVzQXNQRkFa?=
 =?utf-8?B?YlByUDVSeEkwYWhSRno2S2hvOTVyZjVxQVJQN3VtSm9lMTJkVnRmU2ZUS3VI?=
 =?utf-8?B?dGdFdG5MTW1maHRBWnBjQnZBMG90cCtjc3BzM3NBQWNIV2tmTDVnclI1dXVZ?=
 =?utf-8?B?eU5mVENMT2hENkZIOFowdVRLS2FGWVg1MWo1SktYUnVHNTZOU3IvUXJjSStI?=
 =?utf-8?B?SGhrbmQ1eWkycmcveEJNSHFpMkJwWDFzZ2xFTXlDVVVLQ1BXd2dHVGpHR2pD?=
 =?utf-8?B?THVadldKeUprRUgyQjQrZWwyYTNOb0FTUkxVVU5EWW5wVGczKzBIK2p1NnQr?=
 =?utf-8?B?dUhjTGpDY21TS1pRc3JDQURxNmRJcmg3OG8zVkZYTTlQOWV3QVZyMGNJNUZr?=
 =?utf-8?B?b29FWEFRVjBCbE5SdWNBNDBwVE8ybnVRcldnMGR0WFZNWi80REQ4QW9CR3U3?=
 =?utf-8?B?UHd4bjdrYUE3czVKRHQ4c0hMZTlWT0FKbGZveGRwZWl5NE9LU0hTL28remw0?=
 =?utf-8?B?Tm1yT0w1eWphbVQvb2licVVtMGVQTUw5WUxTcTd4RFNFc0JXN0habmRaR21I?=
 =?utf-8?B?RTFEbWNGejV1bFdTdEI0d2NscUhRN0pYallid3pnYy9sYjBvVHRJYmp3U0di?=
 =?utf-8?B?RmpXMEd0MzA3ZGk0bDE2R09iVGlEenpzdTQ3S0RRZDVnc2N1Rmd5MGI2eFJM?=
 =?utf-8?B?MzNBNGMzVm15YTc1ZWFqTVl5VDNlYWMwT3NZTkt6NVcxd25Gd0lIVzhZUUQv?=
 =?utf-8?B?Y2RIWldJSHhGYmJ2NzBKcnRoQmpsN3cyM1c5eEhDMmpFS2d1TG1mR1VWY05l?=
 =?utf-8?B?WUZNZlZvekpDRDVyNGZhZ2dJc3hXUTdSU2x2dmVjUXVDTWswTmNtOFgyeklo?=
 =?utf-8?B?WDBZa3RHVm1yU1lxcllONnNSVnYwOGhLYU00d2xkZm1Gc1hGaWVNdUtUZTh6?=
 =?utf-8?B?ZVAvakpqRUdQVGZpTmlIYng1OWduTExsbHhyVCt1VGo0UVhkd1lSa1IzN1lV?=
 =?utf-8?B?UGFIMHk5L1oxWjNGckFWTEtZVTdsVkxrOW1qRmNZd1R5YksrYm9kVmdvbGZY?=
 =?utf-8?B?d0NLWlcrWW8zZkIrK1A5T1hrOVZKSmFkTVFqM09qOVkxdHN1aDh4ZlF0Z3Z6?=
 =?utf-8?B?UjBFUFZKRG9uMTVCVXdhRVk0d2hjME5SRXNnSWNFMnZ5NnFrZXZEN2lhKzhw?=
 =?utf-8?B?V05JMDZWV0tUUEhhTk1Nbis2NGpMazNhTnNhdzVYTDJMenkvb3drTHgzM2dW?=
 =?utf-8?B?WkZyb09HNnU3T1I4WWpnVll1N3Y1Z0dINGRUQzRyb0wrUDluMVJET09rNm5I?=
 =?utf-8?B?M0lVYTA0UXVrL1phUWZNcUVRRFdxaS9HNGhjZkFTcy9mQkhWWmRZQkFuQVRU?=
 =?utf-8?B?S1lRbVBzQUZLMzZtOVgzZlJzY3VuWVVUQU1Jc21Fc1k3RTlPQ1RDSWlPUDVD?=
 =?utf-8?B?dmRxdUJQZjA4TjhiQTlNM1ROQnpZWDdiNjRvdFk4Rmg2RTVVb3ovYXFlSWNi?=
 =?utf-8?Q?N5uCE3KEPEhh+1VYaZVDopsSC?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 06d8349f-6d42-490f-cea9-08ddb56e1d92
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jun 2025 11:31:11.2611
 (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: JMqZQwVfBNSos5TLV1pgwDSV4YrPo5OLomOkV9aqsZKhTsG9ItH/kJzIMM4iy5JP
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS2PR12MB9687



On 20/06/2025 11:49, Hari Limaye wrote:
> From: Luca Fancellu 
> 
> Introduce flags_has_rwx() function that will check if a
> mapping is both writable and executable when modifying
> or update the mapping.
NIT: s/update/updating/

> 
> This check was already present in pt.c but since it will
> be used also for MPU system, it's wrapped into a function
> now.
> 
> Signed-off-by: Luca Fancellu 
Hari, your SOB is missing.

> ---
>  xen/arch/arm/include/asm/mm.h |  2 ++
>  xen/arch/arm/mm.c             | 15 +++++++++++++++
>  xen/arch/arm/mmu/pt.c         |  9 +--------
>  3 files changed, 18 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/mm.h
> index 011bc1fd30..9daaa96d93 100644
> --- a/xen/arch/arm/include/asm/mm.h
> +++ b/xen/arch/arm/include/asm/mm.h
> @@ -192,6 +192,8 @@ extern unsigned long frametable_base_pdx;
>  
>  /* Boot-time pagetable setup */
>  extern void setup_pagetables(void);
> +/* Check that the mapping flag has no W and X together */
> +extern bool flags_has_rwx(unsigned int flags);
Please, don't use extern for function prototypes. We don't use them anymore.

>  /* Map FDT in boot pagetable */
>  extern void *early_fdt_map(paddr_t fdt_paddr);
>  /* Remove early mappings */
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 0613c19169..c2da1e3a05 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -24,6 +24,21 @@
>  
>  unsigned long frametable_base_pdx __read_mostly;
>  
> +bool flags_has_rwx(unsigned int flags)
> +{
> +    /*
> +     * The hardware was configured to forbid mapping both writeable and
NIT: you can take opportunity to correct misspelling: s/writeable/writable/

Otherwise:
Reviewed-by: Michal Orzel 

~Michal



From xen-devel-bounces@lists.xenproject.org Fri Jun 27 12:30:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 12:30:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027605.1402182 (Exim 4.92)
	(envelope-from )
	id 1uV8DY-0001Ni-IC; Fri, 27 Jun 2025 12:30:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027605.1402182; Fri, 27 Jun 2025 12: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 1uV8DY-0001Nb-Fb; Fri, 27 Jun 2025 12:30:08 +0000
Received: by outflank-mailman (input) for mailman id 1027605;
 Fri, 27 Jun 2025 12: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 1uV8DW-0001Cb-GD
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 12:30:06 +0000
Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com
 [2607:f8b0:4864:20::230])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7185d1c6-5352-11f0-b894-0df219b8e170;
 Fri, 27 Jun 2025 14:30:01 +0200 (CEST)
Received: by mail-oi1-x230.google.com with SMTP id
 5614622812f47-40791b6969bso1484345b6e.3
 for ; Fri, 27 Jun 2025 05:30:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7185d1c6-5352-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1751027400; x=1751632200; 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=VFNI9mcf5R9yYVHmC36pUpSASD2VxUVrMsyFj8KJYSs=;
        b=MAwmfE3HDXaYpGNtgg3tQoH45BWl5C5HzE4iWd7xpGmPv6YJQczTmzL+Mlow1vhJ6Z
         0/yIkBRcwm79HZ9lbbBgix/vQOiWxvHp+XWjQ/AI/axRu95mtIfPiUzTEbCo+XuGEAay
         U9x+lt9TsjMedIDfiCfqQoVDKuJta9e9gxHRM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751027400; x=1751632200;
        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=VFNI9mcf5R9yYVHmC36pUpSASD2VxUVrMsyFj8KJYSs=;
        b=HgyH0OTnZHwF40E8aYIzCVbJ+zrivaAvPXazfWDbe0Nrr6JbziVXyP7w/sO+Rom5nn
         nojJ528AokkmSKlzQFKUo6wKzMiUbssNKG0fSIvxtTWKk8BPgE9x0Gwh3JJVF6QkZJNL
         u41yb2DGm5LrqOMxK08xdeUXmXOGgL/t08nwIVXqKRqKg0bfhPyuksu2g71+uzj3m0hM
         LKRXdHza3m2UmCqzGX7OFITW0/EkYRBefY2ZoClrQkcodZeMUbE++uAORlmXRXO66Skb
         0z04XrF5iQ0w5siuGlaX+nHKfL37E72td9uqbBscpjhTwTqO3ZtgKK7yiLDUYIhSXKQd
         gNnA==
X-Gm-Message-State: AOJu0Yx8SbIcLBzYSN3G2P9Freh93CbzgdrLXXH4YLXbQWp6OJgMJEyU
	7HDYDxSkORIk1jp5FTxcnz/uEWR8kvaESGfkWNBgBWGoTmMYqcetaZhm+dIXX22kdQgaiJGwn+k
	vC0/mmiNqXJKmHsmr/51CfcLiO5mlNxwTxtcb/RD9Rw==
X-Gm-Gg: ASbGnctMXfUObxHuATMhzP4FrobrqxhwArpNGidzMIxuL6LRsstmISLdzf9f98s1K7h
	fY51GS5ltV2iMwg7irFhet6z+wJJJky4xlc9ayqNCy6MeyQ44d7hA4dlkhBOUUgX7n2rQgl0Ggl
	hNig/3uM2WcOZevUqIx9LuJu4sC5mL2pFiXlOg2osN
X-Google-Smtp-Source: AGHT+IEmO7syVJy/FYA86P2lJnxOcAGPQTg3et5E0rV2HmZAeXfGK5ui0jg6L20pixIRRFSwLUYeiyBsZ8lxA5+t3rg=
X-Received: by 2002:a05:6870:ef0d:b0:2e9:8ed9:16fc with SMTP id
 586e51a60fabf-2efed4c2f78mr1568703fac.11.1751027399789; Fri, 27 Jun 2025
 05:29:59 -0700 (PDT)
MIME-Version: 1.0
References: <20250624083157.9334-1-frediano.ziglio@cloud.com>
 
  
 
In-Reply-To: 
From: Frediano Ziglio 
Date: Fri, 27 Jun 2025 13:29:48 +0100
X-Gm-Features: Ac12FXyt3PxgmOYwO6Q5hkN3S9cntzINkBmW4KXaS_fRql8tp27ICMjSYB2TL5A
Message-ID: 
Subject: Re: [PATCH 0/2] xen/efi: Make boot more flexible, especially with GRUB2
To: =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= 
Cc: xen-devel@lists.xenproject.org, 
	"Daniel P. Smith" , Jan Beulich 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 26, 2025 at 4:03=E2=80=AFPM Marek Marczykowski-G=C3=B3recki
 wrote:
>
> On Thu, Jun 26, 2025 at 09:12:53AM +0100, Frediano Ziglio wrote:
> > On Wed, Jun 25, 2025 at 9:26=E2=80=AFPM Marek Marczykowski-G=C3=B3recki
> >  wrote:
> > >
> > > On Tue, Jun 24, 2025 at 09:38:42AM +0100, Frediano Ziglio wrote:
> > > > On Tue, Jun 24, 2025 at 9:32=E2=80=AFAM Frediano Ziglio
> > > >  wrote:
> > > > >
> > > > > The combination of GRUB2, EFI and UKI allows potentially more fle=
xibility.
> > > > > For instance is possible to load xen.efi from a no ESP partition =
leaving
> > > > > a boot loader like GRUB2 taking care of the file loading.
> > > > > This however requires some changes in Xen to be less restrictive.
> > > > > Specifically for GRUB2 these changes allows the usage of "chainlo=
ader"
> > > > > command with UKI and reading xen.efi from no ESP (so no DeviceHan=
dle
> > > > > set) and usage of "linux" and "initrd" commands to load separatel=
y
> > > > > the kernel (embedding using UKI) and initrd (using LoadFile2 prot=
ocol).
> > > >
> > > > I was forgetting. If somebody wants to test "linux" and "initrd"
> > > > command with these changes be aware that GRUB currently has a probl=
em
> > > > passing arguments, I posted a patch, see
> > > > https://lists.gnu.org/archive/html/grub-devel/2025-06/msg00156.html=
.
> > > > I also have a workaround for this issue in xen but it would be bett=
er
> > > > to have a fix in GRUB.
> > >
> > > Can you tell more how to test this, especially the second variant? Wh=
en
> > > trying to use GRUB linux or linuxefi commands on xen.efi, I get "inva=
lid
> > > magic number" error.
> > >
> >
> > That's weird.
> >
> > Be the way. As usual I have a super complicated script that does everyt=
hing.
> >
> > But to simplify:
> > - I compile xen (plain upstream plus my patches) with "make -C
> > ~/work/xen/xen -j O=3Dnormal MAP"
>
> Is there any that would be related to the "invalid magic" error? IIUC
> without your patches options will be mangled, but I don't think I get
> this far.
>

I tried to do some changes and check the CI with your branch. Not hard
to reproduce and the test looks correct.
Looking at GRUB code I can see various "linux" command implementations
and it looks like yours is picking up i386-pc target and not
x86_64-efi one which is really odd to me.

> > - output xen.efi in "~/work/xen/xen/normal/xen.efi"
> > - add configuration and kernel with "./add_sections xen.efi
> > xen.unified.efi .config xen.cfg .kernel vmlinuz-xen"
> > - boot using patched Grub (or patched Xen, to handle command line, if
> > you don't care about command line you can use a stock one), the menu
> > entry is
> >
> > menuentry 'XenServer (Serial)' {
> >         search --label --set root EFI-BOOT
> >         linux /boot/xen.unified.efi -- com1=3D115200,8n1
> > console=3Dcom1,vga dom0_mem=3D1232M,max:1232M watchdog dom0_max_vcpus=
=3D1-4
> > crashkernel=3D256M,below=3D4G -- root=3DLABEL=3Droot-qjhppe ro nolvm
> > hpet=3Ddisable console=3Dtty0 console=3Dhvc0
> >         initrd /boot/initrd.img
> > }
>
> All looks quite similar. FWIW my setup is:
> https://gitlab.com/xen-project/people/marmarek/xen/-/blob/test-uki/automa=
tion/scripts/qemu-smoke-x86-64-efi-uki.sh?ref_type=3Dheads
>
> Booting such UKI from OVMF directly works, as well as with
> "chainloader" grub command:
>
> https://gitlab.com/xen-project/people/marmarek/xen/-/pipelines/1891308263
>
> CI uses Grub 2.06 from Debian, but I get the same result with 2.12 from
> Fedora too.
>
> >
> > xen.cfg file:
> > ----------
> > [global]
> > default=3Dxen
> >
> > [xen]
> > ----------
> >
> > add_sections file:
> > ----------
> > #!/usr/bin/env perl
> > use strict;
> >
> > die if $#ARGV < 1;
> > my $in =3D shift @ARGV;
> > my $out =3D shift @ARGV;
> >
> > my $max =3D 0;
> > open(IN, "objdump -h $in |") or die;
> > while () {
> >         next if !/^\s*\d+\s+\S+\s+([0-9a-f]+)\s+([0-9a-f]+)\s+/;
> >         my $val =3D hex($1) + hex($2);
> >         $max =3D $val if $val > $max;
> > }
> > close(IN);
> >
> > sub up($) {
> >         my $n =3D shift;
> >         return ($n + 4095) & -4096;
> > }
> >
> > my @args =3D ('objcopy');
> >
> > my $start =3D up($max);
> > while ($#ARGV >=3D 1) {
> >         my $name =3D shift;
> >         my $fn =3D shift;
> >         push @args, '--add-section', "$name=3D$fn";
> >         push @args, '--change-section-vma', sprintf("%s=3D%#x", $name, =
$start);
> >         $start +=3D -s $fn;
> >         $start =3D up($start);
> > }
> > push @args, $in, $out;
> > print "Executing @args\n";
> > system(@args) =3D=3D 0 || die "Error!";
> > ----------
> >
> > My script creates the initrd, builds a full disk for Qemu and launches
> > Qemu too with specific options.
> >
> > Frediano
>
> --
> Best Regards,
> Marek Marczykowski-G=C3=B3recki
> Invisible Things Lab


From xen-devel-bounces@lists.xenproject.org Fri Jun 27 12:37:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 12:37:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027619.1402191 (Exim 4.92)
	(envelope-from )
	id 1uV8Ky-0001zw-9D; Fri, 27 Jun 2025 12:37:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027619.1402191; Fri, 27 Jun 2025 12:37:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uV8Ky-0001zm-6b; Fri, 27 Jun 2025 12:37:48 +0000
Received: by outflank-mailman (input) for mailman id 1027619;
 Fri, 27 Jun 2025 12:37:46 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uV8Kw-0001zg-IT
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 12:37:46 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uV8Kw-005IEC-0v;
 Fri, 27 Jun 2025 12:37:46 +0000
Received: from amontsouris-682-1-55-1.w90-87.abo.wanadoo.fr ([90.87.218.1]
 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 1uV8Kv-00CYTE-2u;
 Fri, 27 Jun 2025 12:37: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=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding:
	Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date;
	bh=TASf9clBATY2H74jz8xYrKCe944e20UVSOkhfpa+7pA=; b=UNWI6OnNZk4QzsoAwxH3w4r7EK
	yG1XXXwoBUKUAnOyv7LVQGJu/NP7IBwJHv/Bx5yRQ8sJmverPNWE8ml9UGCi7JBmaMezjI/5NB0O+
	C59/XRjsHzPBDrXg1Mf47APdav8nVdD5PQtAbOfBDgMzLpXSOSS8Dd3aGSiJtgeJtyxA=;
Date: Fri, 27 Jun 2025 14:37:44 +0200
From: Anthony PERARD 
To: Mykola Kvach 
Cc: xen-devel@lists.xenproject.org, Mykola Kvach 
Subject: Re: [PATCH] systemd: Add hooks to stop/start xen-watchdog on
 suspend/resume
Message-ID: 
References: <20250626081246.1923956-1-xakep.amatop@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250626081246.1923956-1-xakep.amatop@gmail.com>

Hi Mykola,

First, since you used a different email account to send you patch, the
email should start with "From: Mykola ... <...@epam.com>" so that
`git am` can set the correct author for the commit. Often
`git send-email` managed to do that automatically, if it knows that the
author of the email is going to be different than the author of the
commit been sent.

On Thu, Jun 26, 2025 at 11:12:46AM +0300, Mykola Kvach wrote:
> This patch adds a systemd sleep hook script to stop the xen-watchdog
> service before system suspend and start it again after resume.
> 
> Stopping the watchdog before a system suspend operation may look unsafe.
> Let’s imagine the following situation: 'systemctl suspend' does not
> interact with the running service at all. In such a case, the Xen
> watchdog daemon freezes just before suspend. If this happens, for
> example, right before sending a ping, and Xen has not yet marked the
> domain as suspended (is_shutting_down), the Xen watchdog timer may
> trigger a false alert.
> 
> This is an almost impossible situation, because typically:
>     ping time = watchdog timeout / 2
> 
> and the watchdog timeout is usually set to a relatively large value
> (dozens of seconds).
> 
> Still, this is more likely with very short watchdog timeouts. It may
> happen in the following scenarios:
>     * Significant delays occur between freezing Linux tasks and
>       triggering the ACPI or PSCI sleep request or handler.
>     * Long delays happen inside Xen between the entrance to the sleep
>       trigger and the actual forwarding of the sleep request further.
> 
> A similar situation may occur on resume with short timeouts. During the
> resume operation, Xen restores timers and the domain context. The Xen
> watchdog timer also resumes. If it schedules the domain right before the
> watchdog timeout expires, and the daemon responsible for pinging is not
> yet running, a timeout might occur.

On resume from suspend, does Xen expect a ping from the guest? Or is the
watchdog only rearmed on the first ping from the guest after been
resumed?

> Both scenarios are rare and typically require very small watchdog
> timeouts combined with significant delays in Xen or the Linux kernel
> during suspend/resume flows.
> 
> Conceptually, however, if activating and pinging the Xen watchdog is the
> responsibility of the domain and its services, then the domain should
> also manage the watchdog service/daemon lifecycle. This is similar to
> what is already done by the Xen watchdog driver inside the Linux kernel.

So there's already watchdog driver in Linux, why not activate it with
systemd, since it knows how to do it? I almost want to to remove the
service file and redirect users to use systemd's watchdog instead, in
the documentation.

> Signed-off-by: Mykola Kvach 
> ---
>  tools/hotplug/Linux/systemd/Makefile          | 12 ++++-
>  .../Linux/systemd/xen-watchdog-sleep.sh       | 45 +++++++++++++++++++
>  2 files changed, 56 insertions(+), 1 deletion(-)
>  create mode 100644 tools/hotplug/Linux/systemd/xen-watchdog-sleep.sh
> 
> diff --git a/tools/hotplug/Linux/systemd/Makefile b/tools/hotplug/Linux/systemd/Makefile
> index e29889156d..98d325cc5d 100644
> --- a/tools/hotplug/Linux/systemd/Makefile
> +++ b/tools/hotplug/Linux/systemd/Makefile
> @@ -5,6 +5,9 @@ XEN_SYSTEMD_MODULES := xen.conf
>  
>  XEN_SYSTEMD_MOUNT := proc-xen.mount
>  
> +XEN_SYSTEMD_SLEEP_SCRIPTS := xen-watchdog-sleep.sh
> +XEN_SYSTEMD_SLEEP_DIR := $(XEN_SYSTEMD_DIR)/../system-sleep

This is the wrong directory, I have no idea what "$(XEN_SYSTEMD_DIR)/.."
could be, even if it's likely to be systemd's directory.
$(XEN_SYSTEMD_DIR) should only be used for system unit files, because
that's how it is defined.

Another comment, from `man 8 systemd-suspend.service`:

    Note that scripts or binaries dropped in /lib/systemd/system-sleep/ are
    intended for local use only and should be considered hacks. If
    applications want to react to system suspend/hibernation and resume,
    they should rather use the Inhibitor interface[1].

    [1] https://www.freedesktop.org/wiki/Software/systemd/inhibit

So is a script in system-sleep the right way?
We probably don't want to go the "inhibitor" way that the manual
suggest, as this would add many dependencies to the daemon (and it's
probably not needed).

How about enhancing xen-watchdog.service to deal with suspend?
It's possible to have "Conflicts=sleep.target" which mean stop this unit
when doing suspend. But restarting the unit on resume seems to need a
second service file which might be a bit more complicated to write,
something like:
    [Unit]
    After=sleep.target
    [Service]
    ExecStart=systemctl restart xen-watchdogd
    [Install]
    WantedBy=suspend.target
    WantedBy=hibernate.target
    WantedBy=hybrid-sleep.target
    WantedBy=suspend-then-hibernate.target
    ...
Actually, I'm not sure After=sleep.target is going to work... we should
be able to use systemd's watchdog capability instead :-) (which seems to
mean that a driver in Linux for xen's watchdog is needed); Never mind,
I've re-read the patch description and commented there.

Anyway, don't use XEN_SYSTEMD_DIR and introduce a new variable
in "systemd.m4".

> +
>  XEN_SYSTEMD_SERVICE := xenstored.service
>  XEN_SYSTEMD_SERVICE += xenconsoled.service
>  XEN_SYSTEMD_SERVICE += xen-qemu-dom0-disk-backend.service
> @@ -15,7 +18,8 @@ XEN_SYSTEMD_SERVICE += xendriverdomain.service
>  
>  ALL_XEN_SYSTEMD :=	$(XEN_SYSTEMD_MODULES)  \
>  			$(XEN_SYSTEMD_MOUNT)	\
> -			$(XEN_SYSTEMD_SERVICE)
> +			$(XEN_SYSTEMD_SERVICE)	\
> +			$(XEN_SYSTEMD_SLEEP_SCRIPTS)
>  
>  .PHONY: all
>  all:	$(ALL_XEN_SYSTEMD)
> @@ -31,15 +35,21 @@ distclean: clean
>  install: $(ALL_XEN_SYSTEMD)
>  	$(INSTALL_DIR) $(DESTDIR)$(XEN_SYSTEMD_DIR)
>  	$(INSTALL_DIR) $(DESTDIR)$(XEN_SYSTEMD_MODULES_LOAD)
> +	$(INSTALL_DIR) $(DESTDIR)$(XEN_SYSTEMD_SLEEP_DIR)
>  	$(INSTALL_DATA) *.service $(DESTDIR)$(XEN_SYSTEMD_DIR)
>  	$(INSTALL_DATA) *.mount $(DESTDIR)$(XEN_SYSTEMD_DIR)
>  	$(INSTALL_DATA) *.conf $(DESTDIR)$(XEN_SYSTEMD_MODULES_LOAD)
> +	set -e; for i in $(XEN_SYSTEMD_SLEEP_SCRIPTS); \
> +	    do \
> +	    $(INSTALL_PROG) $$i $(DESTDIR)$(XEN_SYSTEMD_SLEEP_DIR); \

I don't think you need a loop for that, `install` is perfectly capable
of installing multiple sources.

> +	done
>  
>  .PHONY: uninstall
>  uninstall:
>  	rm -f $(DESTDIR)$(XEN_SYSTEMD_MODULES_LOAD)/*.conf
>  	rm -f $(DESTDIR)$(XEN_SYSTEMD_DIR)/*.mount
>  	rm -f $(DESTDIR)$(XEN_SYSTEMD_DIR)/*.service
> +	rm -f $(addprefix $(DESTDIR)$(XEN_SYSTEMD_SLEEP_DIR)/, $(XEN_SYSTEMD_SLEEP_SCRIPTS))
>  
>  $(XEN_SYSTEMD_MODULES):
>  	rm -f $@.tmp
> diff --git a/tools/hotplug/Linux/systemd/xen-watchdog-sleep.sh b/tools/hotplug/Linux/systemd/xen-watchdog-sleep.sh
> new file mode 100644
> index 0000000000..2b2f0e16d8
> --- /dev/null
> +++ b/tools/hotplug/Linux/systemd/xen-watchdog-sleep.sh
> @@ -0,0 +1,45 @@
> +#!/bin/sh
> +
> +# The first argument ($1) is:
> +#     "pre" or "post"
> +# The second argument ($2) is:
> +#     "suspend", "hibernate", "hybrid-sleep", or "suspend-then-hibernate"
> +
> +. /etc/xen/scripts/hotplugpath.sh
> +
> +SERVICE_NAME="xen-watchdog.service"
> +STATE_FILE="/run/xen-watchdog-sleep-marker"

This should use $XEN_RUN_DIR

> +XEN_WATCHDOG_SLEEP_LOG="${XEN_LOG_DIR}/xen-watchdog-sleep.log"

Is this necessary? Use only `logger`, if `echo log` doesn't log anything.

> +log_watchdog() {
> +    echo "$1"
> +    echo "$(date): $1" >> "${XEN_WATCHDOG_SLEEP_LOG}"
> +}
> +
> +# Exit silently if Xen watchdog service is not present
> +if ! systemctl show "${SERVICE_NAME}" > /dev/null 2>&1; then

Is this necessary? It seems `systemctl is-active` works fine when the
unit doesn't exist.

> +    exit 0
> +fi
> +
> +case "$1" in
> +pre)
> +    if systemctl is-active --quiet "${SERVICE_NAME}"; then
> +        touch "${STATE_FILE}"
> +        log_watchdog "Stopping ${SERVICE_NAME} before $2."
> +        systemctl stop "${SERVICE_NAME}"
> +    fi
> +    ;;
> +post)
> +    if [ -f "${STATE_FILE}" ]; then

Would using `systemctl is-enabled` instead work? It seems to work for a
service on my machine.

> +        log_watchdog "Starting ${SERVICE_NAME} after $2."
> +        systemctl start "${SERVICE_NAME}"
> +        rm "${STATE_FILE}"
> +    fi
> +    ;;
> +*)
> +    log_watchdog "Script called with unknown action '$1'. Arguments: '$@'"
> +    exit 1
> +    ;;
> +esac
> +
> +exit 0
> -- 
> 2.48.1

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Fri Jun 27 13:08:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 13:08:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027626.1402201 (Exim 4.92)
	(envelope-from )
	id 1uV8oR-0005tS-HP; Fri, 27 Jun 2025 13:08:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027626.1402201; Fri, 27 Jun 2025 13:08: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 1uV8oR-0005tL-Eg; Fri, 27 Jun 2025 13:08:15 +0000
Received: by outflank-mailman (input) for mailman id 1027626;
 Fri, 27 Jun 2025 13:08: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 1uV8oQ-0005tF-Lb
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 13:08:14 +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 c7e97717-5357-11f0-a30f-13f23c93f187;
 Fri, 27 Jun 2025 15:08:14 +0200 (CEST)
Received: by mail-oa1-x36.google.com with SMTP id
 586e51a60fabf-2ea35edc691so533261fac.2
 for ; Fri, 27 Jun 2025 06:08:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c7e97717-5357-11f0-a30f-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1751029692; x=1751634492; 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=yeNb4NNp7U68SZvu2wdZ7aXGx7gqQBH0jROY08RE26Q=;
        b=kXWvUeH0B3LGz6SO2KgxxkcRT18Cslhg9+x22N+wT7A1Fjqhn4oZVJ7/xa4+80xjWR
         aV22Cj6rFk02qXoxexOSWBCOnCGLEZewg6p3pTGsTXRvqIc9vly0T0q1vbqC6XoCLaQa
         vPtNStfo0085fSQYWC8DMnpwoc4d/X1SsdqGM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751029692; x=1751634492;
        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=yeNb4NNp7U68SZvu2wdZ7aXGx7gqQBH0jROY08RE26Q=;
        b=o1UISrYDP2JdJx+NmrEyQE5Wcbza+MPaMGRFuPynSMMMopeRXReVeyrNa9bJJ3pLzA
         9qXJhgQuDj0VtYZ5MHKBrUAO04fo1he1sAaeWtLNwzsj0R6Bo3KxiFR8TuWuAWS0pH5e
         xVeWqoJgg+k2vK0jHgctAUSCSlxGb/MX6KDQ8uazlyj+l+RGNRe0Z9HFDkCrQLCgJ3DE
         IgfNhL9wsXCSzcTvuWj/bc4M8zn8e3yAJoMFKkDVwc4r7R8W5ZJcuE4D3buePwp6PqcW
         Z1K/txro57fxbHQKBjiFPvSlMXKdurRltNzQvXtk6RSDwRh+72dniDJNWPKtnPKihrBy
         1t4A==
X-Gm-Message-State: AOJu0YxbDzKoQ6GHyK1FYSOf5A3euo1iQXRInuAkKOUSp6vtbUXAu194
	9OYfhBstTm5dqS508f3+ByR4Gv7Ghcz7UG1qui7oEfdBp4aQxjFridWUA3IqD5DIVhLR1WVzXrW
	DsLgIntEgldLBSZar+DMId4i9sSBUd4DVnFKEiosD8D3wJNWCuex0iXM=
X-Gm-Gg: ASbGnct+gXe6SgRO3CoVkUNtCyJXV7hKD7/+ZnXeycnskZ7WK6GxGQ/ejvzw/5tJOdn
	TrgoHbCXtur9ZvED0IOYCTEMITi7zjAPp3KFNDBhDDtLC05Xo1CP4xJdlNfXKn54tri4nZ4Y8tk
	utsLRxSl1wwcoh2fEPnJiB5ISuAPqnzYJo2WdvkAei
X-Google-Smtp-Source: AGHT+IFyfEbDVimxbMJ4IJxpSYDSHZM66k37L9yazfgAzU5ak0wZJ+ytUC6UcJq5NgcGqEGv9B1F+VL1sKWsfuzDigI=
X-Received: by 2002:a05:6870:3118:b0:2d5:2955:aa6c with SMTP id
 586e51a60fabf-2efed72bbd1mr1822721fac.31.1751029692199; Fri, 27 Jun 2025
 06:08:12 -0700 (PDT)
MIME-Version: 1.0
References: <20250605111638.2869914-1-andrew.cooper3@citrix.com> <20250605111638.2869914-2-andrew.cooper3@citrix.com>
In-Reply-To: <20250605111638.2869914-2-andrew.cooper3@citrix.com>
From: Frediano Ziglio 
Date: Fri, 27 Jun 2025 14:08:00 +0100
X-Gm-Features: Ac12FXzr5y8X9sPKzzW7vKXQc_OdEvf8EB6BkHunW3nzLZG31PiC_Z6bBBQa2Uk
Message-ID: 
Subject: Re: [PATCH 1/3] x86/EFI: Fix detection of buildid
To: Andrew Cooper 
Cc: Xen-devel , 
	Ross Lagerwall , Jan Beulich , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	=?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= , 
	"Daniel P . Smith" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 5, 2025 at 12:17=E2=80=AFPM Andrew Cooper  wrote:
>
> The format of the buildid is a property of the binary, not a property of =
how
> it was loaded.  This fixes buildid recognition when starting xen.efi from=
 it's
> MB2 entrypoint.
>
> Suggested-by: Ross Lagerwall 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Roger Pau Monn=C3=A9 
> CC: Ross Lagerwall 
> CC: Marek Marczykowski-G=C3=B3recki 
> CC: Daniel P. Smith 
>
> I don't like this patch and tried hard to do it in a better way, but the =
EFI
> aspects of the build system are too intractable.
>
> While on x86 I can in principle pull the same common-stubs.o trick, split=
 on
> XEN_BUILD_PE rather than XEN_BUILD_EFI, that doesn't work on ARM which
> hand-codes it's PE-ness.  Also, it's really not EFI related, other than a=
s a
> consequence of that being the only reason we use PE32+ binaries.
>
> Binutils 2.25 is now the minimum, and the makefiles can be cleaned up
> somewhat, but I need to backport this patch, internally at least.
> ---
>  xen/common/version.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/xen/common/version.c b/xen/common/version.c
> index 5474b8e385be..56b51c81d2fc 100644
> --- a/xen/common/version.c
> +++ b/xen/common/version.c
> @@ -203,8 +203,11 @@ void __init xen_build_init(void)
>      rc =3D xen_build_id_check(n, sz, &build_id_p, &build_id_len);
>
>  #ifdef CONFIG_X86
> -    /* Alternatively we may have a CodeView record from an EFI build. */
> -    if ( rc && efi_enabled(EFI_LOADER) )
> +    /*
> +     * xen.efi built with a new enough toolchain will have a CodeView re=
cord,
> +     * not an ELF note.
> +     */
> +    if ( rc )
>      {
>          const struct pe_external_debug_directory *dir =3D (const void *)=
n;
>

Reviewed-by: Frediano Ziglio 

I cannot see a better proposal in the discussion, but I prefer this
fixed than keep it broken.

Frediano


From xen-devel-bounces@lists.xenproject.org Fri Jun 27 14:19:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 14:19:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027675.1402212 (Exim 4.92)
	(envelope-from )
	id 1uV9v9-0005qw-H3; Fri, 27 Jun 2025 14:19:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027675.1402212; Fri, 27 Jun 2025 14:19: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 1uV9v9-0005qp-EK; Fri, 27 Jun 2025 14:19:15 +0000
Received: by outflank-mailman (input) for mailman id 1027675;
 Fri, 27 Jun 2025 14:19: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 1uV9v8-0005qj-BN
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 14:19:14 +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 b2768dc0-5361-11f0-b894-0df219b8e170;
 Fri, 27 Jun 2025 16:19:12 +0200 (CEST)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-3a4e742dc97so2169192f8f.0
 for ; Fri, 27 Jun 2025 07:19:12 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a88c8013fesm2886469f8f.38.2025.06.27.07.19.09
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 27 Jun 2025 07:19:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b2768dc0-5361-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1751033951; x=1751638751; 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=OUW2+53hkCBMGIncRKiorGQM8v/WUAGZvghzhUrAIKc=;
        b=hu8Kaxpg57zgRv6phPOP0ui75vMeEGaHJ4pheCnvYPKxNy1tTUCKCXyaz2J1u545pP
         jTw3IxYyObtpSs+P3R5bt+DGX+gOaN+p/pzOscP50arZC4U9VjS7QxU4jt2sCUVdRZfH
         ZHLGpc6ybDmanxIRshLWYxCrbOl2Nh2pSSrrc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751033951; x=1751638751;
        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=OUW2+53hkCBMGIncRKiorGQM8v/WUAGZvghzhUrAIKc=;
        b=DedHTZsqBO4uw+P6OAqQyN0klbqRqXe8yROjB6nTGLVf58hhtpkTIUAwnYKRs+DZO0
         hMmkSaHAgz3f355rWOX7bz/zPnJrVApn0L/nzrVX0pOIHSjqo4QhmkQawrUHuLESxVOb
         iyXP/UhAPzcmHMKXHslZ5YuffYWi6HrRJwAHZfDG2Gl1rPnmJ1m8E7nbZ0ZdvA7YYo+E
         7oGrmTBhttN1vXGigb9V05YhE/Q4BbndCV13E7OsKVJE83qBiDpj/muzqHRTeOnkBOuM
         ShmEi3rVv14WYAUsoOAswHYaxt4t6jG8c9ih05a+lc4CeNEu3wpUjO5w5YoF8+JASwki
         +P3w==
X-Gm-Message-State: AOJu0YwR8mv/VIt0/l0e0f766VwGOhzsf98o7CdVeslCty0enZEP1wDi
	nHiigihkPjpIS72OncEym9AQn91ofTTuQmCOkw5+70To6/l2JhCiaz8/KsttNHuFDfuCy/4zTNM
	qVmTxG/Wsig==
X-Gm-Gg: ASbGncuCcdTzExEqyLCJvD5gcXg2JMXn8XsfBUFzCIES59ZlzqnLp6cK9ndjw2w4ZoF
	SyqRVHsp5h8TmhjksqewuCbaZmZjRpQSsv8K9wjxJjhknz/UmoyWV3/uLYWMgd7Bjc6U71DaH8U
	JozWYF3UKsqzRy1gnGXVktzJ171ZE/7YLhVxfvLgJfEliD2sKPmZozgPYxTflSssjtL/rBa8ulB
	XaVKRU3TqAUOiVcWComRc+y8vZI05x+1Lh4oAsFfBABqCP8Lb+JvGdopH2u18TK8Wwp29TWCJZb
	Wf9WUGnDS5SmpVC/6BGPmYOd+d5JPkWPKWLB2VoLFG1xu/ZI5Hdivb8lFyLoDWOkiwIq4PsGf/t
	oaTqNB0TX2lMd1yh3GjSYQu6aiUhIzgry/Xyl3aqMsRSw/A==
X-Google-Smtp-Source: AGHT+IHX3ex1CeOhTKIUmDYpxSI4IIDBk3oEinF/Aeh1q8ACqL+pO/HgcZHN6H/0WkAGOWw/nKJWoA==
X-Received: by 2002:a05:6000:40c8:b0:3a4:dfbe:2b14 with SMTP id ffacd0b85a97d-3a98b53f408mr3280793f8f.16.1751033951251;
        Fri, 27 Jun 2025 07:19:11 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH] x86/cpu-policy: Simplify logic in guest_common_default_feature_adjustments()
Date: Fri, 27 Jun 2025 15:19:07 +0100
Message-Id: <20250627141907.525027-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

For features which are unconditionally set in the max policies, making the
default policy to match the host can be done with a conditional clear.

This is simpler than the unconditional clear, conditional set currently
performed.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 

This isn't entirely no functional change.  There would be a change if such
features were annotated !a rather than !A.  However, !a is a nonsensical
annotation for a feature intended to be always-max.

Bloat-o-meter says this saves 69 bytes, so more than a cacheline, which is a
disappointing size, but there are not any opportunities for agregation.
---
 xen/arch/x86/cpu-policy.c | 25 ++++++++++---------------
 1 file changed, 10 insertions(+), 15 deletions(-)

diff --git a/xen/arch/x86/cpu-policy.c b/xen/arch/x86/cpu-policy.c
index 060b34d9132f..518f9c9e5409 100644
--- a/xen/arch/x86/cpu-policy.c
+++ b/xen/arch/x86/cpu-policy.c
@@ -515,17 +515,14 @@ static void __init guest_common_default_feature_adjustments(uint32_t *fs)
          * reasons, so reset the default policy back to the host values in
          * case we're unaffected.
          */
-        __clear_bit(X86_FEATURE_MD_CLEAR, fs);
-        if ( cpu_has_md_clear )
-            __set_bit(X86_FEATURE_MD_CLEAR, fs);
+        if ( !cpu_has_md_clear )
+            __clear_bit(X86_FEATURE_MD_CLEAR, fs);
 
-        __clear_bit(X86_FEATURE_FB_CLEAR, fs);
-        if ( cpu_has_fb_clear )
-            __set_bit(X86_FEATURE_FB_CLEAR, fs);
+        if ( !cpu_has_fb_clear )
+            __clear_bit(X86_FEATURE_FB_CLEAR, fs);
 
-        __clear_bit(X86_FEATURE_RFDS_CLEAR, fs);
-        if ( cpu_has_rfds_clear )
-            __set_bit(X86_FEATURE_RFDS_CLEAR, fs);
+        if ( !cpu_has_rfds_clear )
+            __clear_bit(X86_FEATURE_RFDS_CLEAR, fs);
 
         /*
          * The Gather Data Sampling microcode mitigation (August 2023) has an
@@ -545,13 +542,11 @@ static void __init guest_common_default_feature_adjustments(uint32_t *fs)
      * Topology information is at the toolstack's discretion so these are
      * unconditionally set in max, but pick a default which matches the host.
      */
-    __clear_bit(X86_FEATURE_HTT, fs);
-    if ( cpu_has_htt )
-        __set_bit(X86_FEATURE_HTT, fs);
+    if ( !cpu_has_htt )
+        __clear_bit(X86_FEATURE_HTT, fs);
 
-    __clear_bit(X86_FEATURE_CMP_LEGACY, fs);
-    if ( cpu_has_cmp_legacy )
-        __set_bit(X86_FEATURE_CMP_LEGACY, fs);
+    if ( !cpu_has_cmp_legacy )
+        __clear_bit(X86_FEATURE_CMP_LEGACY, fs);
 
     /*
      * On certain hardware, speculative or errata workarounds can result in
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Fri Jun 27 14:20:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 14:20:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027685.1402222 (Exim 4.92)
	(envelope-from )
	id 1uV9wH-0007La-UU; Fri, 27 Jun 2025 14:20:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027685.1402222; Fri, 27 Jun 2025 14:20:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uV9wH-0007LT-RU; Fri, 27 Jun 2025 14:20:25 +0000
Received: by outflank-mailman (input) for mailman id 1027685;
 Fri, 27 Jun 2025 14:20: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 1uV9wG-0007LJ-EB
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 14:20:24 +0000
Received: from fhigh-a7-smtp.messagingengine.com
 (fhigh-a7-smtp.messagingengine.com [103.168.172.158])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d9f997c5-5361-11f0-b894-0df219b8e170;
 Fri, 27 Jun 2025 16:20:19 +0200 (CEST)
Received: from phl-compute-03.internal (phl-compute-03.phl.internal
 [10.202.2.43])
 by mailfhigh.phl.internal (Postfix) with ESMTP id B58AA140018B;
 Fri, 27 Jun 2025 10:20:17 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-03.internal (MEProxy); Fri, 27 Jun 2025 10:20:17 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
 27 Jun 2025 10:20:16 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d9f997c5-5361-11f0-b894-0df219b8e170
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=1751034017;
	 x=1751120417; bh=dEqcBBehjo+Ag8AHZ3QYMxQ5bq0u4I+zI5hAXajTB78=; b=
	d9uc3EeWmc36oTHuiTJqWByrU/UB4pUAwBiYsN0MBIWF89yxyvjmX9Pkl+KfbaeT
	/JyDTQNUujFSgykmZG+TVoU/llMrGS0UHf22D6wW/nMRoYIgGbzD3D8hAO9sRitq
	TWYgNwY3m+CmLZZptU9LSJqW9vfY0hz5YPwfNp5VGYN4tv5mwdpYxog1H8yXd1zF
	z2NK6jetZthnLUEV7LNhOIiFKxPn/KO1Tp9qJfn8XsKTd3pl3Gz1YFsR3UPbMRjH
	xTEQUa7p+V9O6BXi1cGZPui5P1GvArKLZ8SzSSMqNMtthkfykHV5+OdIIR8mmKV0
	vpSxZmIZqhYxSQcAy3PYuw==
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=
	1751034017; x=1751120417; bh=dEqcBBehjo+Ag8AHZ3QYMxQ5bq0u4I+zI5h
	AXajTB78=; b=X1nN6YoPZqwSBPo6pcZXVqVcNbEwY0oX12yfqFBU48tOXIV8zUm
	PKwU+QYYl4xR+TSrHPn8nP+sIlmfYZh3+QaqP6kYY62F3ctXOxpW1i/LJRZeNfVQ
	Iw++6Ya6vA71QFYxp8doR2lLtDB9YISo/LgSMh9sjDWMUxHKmzrtQDSTqEtMFaJ8
	4kaUry8kEr9zMHSjEu8olF8VhnFnoun547nCWq1lE1KKk6JacqTLU/hjabOiw9FA
	Ck+L21ODf/wvS0Wo9twyKbNvwjcp7ltoKBwOD+jla7Q+lXbSvmpW4W5WfW08PF03
	tALLAO8hTNPDfBFSXYs2zp1GKYFf7JoWEUw==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdefvdelucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceurghi
    lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh
    epfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcuofgr
    rhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvihhsih
    gslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepieeluefgkefh
    geelveeuueeuhfevvdehtdevudevvdehieeiteffvdfhueduvdehnecuffhomhgrihhnpe
    hgnhhurdhorhhgpdhfvgguohhrrghprhhojhgvtghtrdhorhhgnecuvehluhhsthgvrhfu
    ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhvih
    hsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepgedpmhhouggv
    pehsmhhtphhouhhtpdhrtghpthhtohepfhhrvgguihgrnhhordiiihhglhhiohestghloh
    huugdrtghomhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhr
    ohhjvggtthdrohhrghdprhgtphhtthhopeguphhsmhhithhhsegrphgvrhhtuhhsshholh
    huthhiohhnshdrtghomhdprhgtphhtthhopehjsggvuhhlihgthhesshhushgvrdgtohhm
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Fri, 27 Jun 2025 16:20:14 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Frediano Ziglio 
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" ,
	Jan Beulich 
Subject: Re: [PATCH 0/2] xen/efi: Make boot more flexible, especially with
 GRUB2
Message-ID: 
References: <20250624083157.9334-1-frediano.ziglio@cloud.com>
 
 
 
 
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="N6yUUmzDxvx28B6F"
Content-Disposition: inline
In-Reply-To: 


--N6yUUmzDxvx28B6F
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Fri, 27 Jun 2025 16:20:14 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Frediano Ziglio 
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" ,
	Jan Beulich 
Subject: Re: [PATCH 0/2] xen/efi: Make boot more flexible, especially with
 GRUB2

On Fri, Jun 27, 2025 at 01:29:48PM +0100, Frediano Ziglio wrote:
> On Thu, Jun 26, 2025 at 4:03=E2=80=AFPM Marek Marczykowski-G=C3=B3recki
>  wrote:
> >
> > On Thu, Jun 26, 2025 at 09:12:53AM +0100, Frediano Ziglio wrote:
> > > On Wed, Jun 25, 2025 at 9:26=E2=80=AFPM Marek Marczykowski-G=C3=B3rec=
ki
> > >  wrote:
> > > >
> > > > On Tue, Jun 24, 2025 at 09:38:42AM +0100, Frediano Ziglio wrote:
> > > > > On Tue, Jun 24, 2025 at 9:32=E2=80=AFAM Frediano Ziglio
> > > > >  wrote:
> > > > > >
> > > > > > The combination of GRUB2, EFI and UKI allows potentially more f=
lexibility.
> > > > > > For instance is possible to load xen.efi from a no ESP partitio=
n leaving
> > > > > > a boot loader like GRUB2 taking care of the file loading.
> > > > > > This however requires some changes in Xen to be less restrictiv=
e.
> > > > > > Specifically for GRUB2 these changes allows the usage of "chain=
loader"
> > > > > > command with UKI and reading xen.efi from no ESP (so no DeviceH=
andle
> > > > > > set) and usage of "linux" and "initrd" commands to load separat=
ely
> > > > > > the kernel (embedding using UKI) and initrd (using LoadFile2 pr=
otocol).
> > > > >
> > > > > I was forgetting. If somebody wants to test "linux" and "initrd"
> > > > > command with these changes be aware that GRUB currently has a pro=
blem
> > > > > passing arguments, I posted a patch, see
> > > > > https://lists.gnu.org/archive/html/grub-devel/2025-06/msg00156.ht=
ml.
> > > > > I also have a workaround for this issue in xen but it would be be=
tter
> > > > > to have a fix in GRUB.
> > > >
> > > > Can you tell more how to test this, especially the second variant? =
When
> > > > trying to use GRUB linux or linuxefi commands on xen.efi, I get "in=
valid
> > > > magic number" error.
> > > >
> > >
> > > That's weird.
> > >
> > > Be the way. As usual I have a super complicated script that does ever=
ything.
> > >
> > > But to simplify:
> > > - I compile xen (plain upstream plus my patches) with "make -C
> > > ~/work/xen/xen -j O=3Dnormal MAP"
> >
> > Is there any that would be related to the "invalid magic" error? IIUC
> > without your patches options will be mangled, but I don't think I get
> > this far.
> >
>=20
> I tried to do some changes and check the CI with your branch. Not hard
> to reproduce and the test looks correct.
> Looking at GRUB code I can see various "linux" command implementations
> and it looks like yours is picking up i386-pc target and not
> x86_64-efi one which is really odd to me.

Indeed, very odd, I do pass -O x86_64-efi option explicitly...

But also, when I do the test locally with grub 2.12 from Fedora, I get the =
filename
prefix:

    error: ../../grub-core/loader/i386/efi/linux.c:387:invalid magic number.

which does look like the efi variant.

This is even more interesting, as this path does not exist in the
upstream repository. It appears as it's _yet another_ linux loader added
by Fedora package:
https://src.fedoraproject.org/rpms/grub2/blob/rawhide/f/0213-Add-support-fo=
r-Linux-EFI-stub-loading.patch
That code I think looks for some Linux-specific header with "EFI
handover" pointer?

I don't see exactly this patch in Debian package, but there are also
some messing with the 'linux' command, so I guess it may be similar
issue.

If I use upstream grub directly, then the "linux" command indeed doesn't
complain.

So, it looks like major distributions use a patched grub version that
changes behavior of "linux" command. IIUC many of those patches are
about hardening SecureBoot, and shim-review kinda suggest using patched
version (many of the submissions explicitly mention the at least patch
grub for NX). So, I think this needs figuring out how to make your
approach working with grub flavor that is actually used by SB-enabled
distributions...

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

--N6yUUmzDxvx28B6F
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmheqJ4ACgkQ24/THMrX
1yyVQQf9FLNcLfmZCSbPovI4nMC1h97V66jVsuV1pjqAwv7CzEIQtNDapkIcuyr1
o5yaTGsogl7wX9uctajK2Mo5hmholO1Lbx6F/TBLoTCMOdxsFPLYm+/QwYnVXWhi
Z/OqHoGwmonYIAcozDRGxHtBh184+cjHNU+ziCim13s3oria0pvMcG8u0JWRHsAx
pbiGsWbw0NSnhA5aejQBITmoU7TT/hQoXdOvFLWEtfsnf1tTGqA0B7tQbqJUcfjy
GXfD13A8KnYpu7LqMp3iKj8n7sosKirZTf2BCRmgZ95i0U9vxWFzg9WzGAAG9aVo
gDDGf9fBYWGkT87KQpPSdPGFfgAtkg==
=uDui
-----END PGP SIGNATURE-----

--N6yUUmzDxvx28B6F--


From xen-devel-bounces@lists.xenproject.org Fri Jun 27 14:52:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 14:52:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027709.1402231 (Exim 4.92)
	(envelope-from )
	id 1uVAQl-0002sx-8B; Fri, 27 Jun 2025 14:51:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027709.1402231; Fri, 27 Jun 2025 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 1uVAQl-0002sq-5T; Fri, 27 Jun 2025 14:51:55 +0000
Received: by outflank-mailman (input) for mailman id 1027709;
 Fri, 27 Jun 2025 14:51: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 1uVAQj-0002sk-M7
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 14:51:53 +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 40717f9e-5366-11f0-b894-0df219b8e170;
 Fri, 27 Jun 2025 16:51:48 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-4538bc1cffdso16408685e9.0
 for ; Fri, 27 Jun 2025 07:51:48 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-4538234b1b9sm81590595e9.11.2025.06.27.07.51.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 27 Jun 2025 07:51:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 40717f9e-5366-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1751035908; x=1751640708; 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+HfHUW1r/ios0M40imSCWazaGCOjQBYU3uC2JYY7LY=;
        b=VyC+gGciro+FgJBsKpKbGdOqfT76oPa9Z1VbBuRv3dFm1gcS+b9XOSkm50zZBUWKww
         7ZzHKB8nZjiJh0DEAWAp0zyHy4ca4cmq9NYyAUcMYTWJj9a2up/IDsjF2GLOzIOKFFzb
         SJNlg8Np4tzwiW2yZxXc3NzNQ05E2sER6IXqE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751035908; x=1751640708;
        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+HfHUW1r/ios0M40imSCWazaGCOjQBYU3uC2JYY7LY=;
        b=KDy7Kv5ZUubdVh7W0QnjWwqgrMgaK+ZLDYnC7S0FF+z1PiSonHsAyaZxMpr7zEX33F
         /5bYCBGpwAJxfdpxe0pYYWdjf6e5XJNspn9AWRca9E5oeo1nml+hocMfQ4eW+fK2J6e8
         tBpZBO3fKiwzFMc9LYt14Jd59u+i1+ENb4eYj4u3L8QSIYVro6XqT2N83P35esLD6xcO
         7WjfQ565M0I/n6DjF+7PH5kzZEDHtDJlUUeFIHD/wTzzEC5EuoAxC5Nl/xvM39s8KioM
         00YOSr2RtEexSw1AjaAe5dM75wjoSUsvOTbx9PcEqwrR+AuReuQ8/IEuGdC7tqek6V4b
         +S1Q==
X-Forwarded-Encrypted: i=1; AJvYcCVf6n1nsLlzZGYUaKpIMTuT5Iu/YwceUds0RovEgn6nioVjxS0fMkIJF8bUYbMWNKbgJ0sCIlBqdDc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxYGjLJ67aNy5q89S2SFCMLQsu4ivR8yZZU0CxqTaKhCn5MvClX
	x/9x+t0uCQC+jy/eG1apaoWLcs0TTitH2OpNzUMCnomJ2S/23yP+qwZLF9ZugevZXZg=
X-Gm-Gg: ASbGncsl6evz6GYxZN3EhnO8OzW3YtN7Skn7stQn+8l6lkA+JOZGaZsjrWiMHGurx9t
	cFIud8oaiovAR2PF6qHrjJr6Am6ZN06g/eulNYmQz9LxzRzwuFccazklq9HPt3VGAiJZm37uzLS
	hYqrfSwlNIn8uI8nsp67Z9zDV/bZMhNZ3RpW9GhPp5rq6yzeFoJYJDBgKWcZrLoEHVKdTvnmuSP
	XN/vAhSSptAuHerd9DrIyY9Lnh01SYMTqXeCJKuQqpQA29LqsBb8QPfW2UF6FBbBP+PBPN27uyk
	y8S6+bFo+7S5tWE3vSHGe790POS4kjl+hM2BPzrG9K3AlfUCjDpQy18hDMPCeVrBOFz1ufUk42l
	DGMJZO0dxW0mpwdU0q9hMILeMK4CDRfEO/a2pR7+I
X-Google-Smtp-Source: AGHT+IFDzaFfjDNEL88bQEqhIsL906og3ODCt0CCldX4/wiuBbREDwSwFWegQtVn9HcPvSuB067veg==
X-Received: by 2002:a05:600c:3e8e:b0:442:e9ec:4654 with SMTP id 5b1f17b1804b1-4538ee5ce0cmr38178955e9.8.1751035907632;
        Fri, 27 Jun 2025 07:51:47 -0700 (PDT)
Date: Fri, 27 Jun 2025 16:51:46 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Oleksii Kurochko ,
	Community Manager ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 8/8] pdx: introduce a new compression algorithm based
 on region offsets
Message-ID: 
References: <20250620111130.29057-1-roger.pau@citrix.com>
 <20250620111130.29057-9-roger.pau@citrix.com>
 
 
 <475fb02b-0b00-4aab-b73c-9604fe050074@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <475fb02b-0b00-4aab-b73c-9604fe050074@suse.com>

On Thu, Jun 26, 2025 at 09:35:04AM +0200, Jan Beulich wrote:
> On 25.06.2025 18:24, Roger Pau Monné wrote:
> > On Tue, Jun 24, 2025 at 06:16:15PM +0200, Jan Beulich wrote:
> >> On 20.06.2025 13:11, Roger Pau Monne wrote:
> >>> +bool pdx_is_region_compressible(paddr_t base, unsigned long npages)
> >>> +{
> >>> +    unsigned long pfn = PFN_DOWN(base);
> >>> +
> >>> +    return pdx_to_pfn(pfn_to_pdx(pfn) + npages - 1) == (pfn + npages - 1);
> >>
> >> Aiui for this to be correct, there need to be gaps between the ranges
> >> covered by individual lookup table slots. In the setup logic you have a
> >> check commented "Avoid compression if there's no gain", but that doesn't
> >> look to guarantee gaps everywhere (nor would pfn_offset_sanitize_ranges()
> >> appear to)?
> > 
> > But if there are no gaps, the full region is covered correctly, and
> > hence it's compressible?
> 
> If there's a guarantee that such ranges would be folded into a single one,
> all would be fine.
> 
> > Maybe I'm missing something, could you maybe provide an example that
> > would exhibit this issue?
> 
> My understanding is that when there's no gap between regions, and when
> [base, base + npages) crosses as region boundary, then the expression
> above will yield true when, because of crossing a region boundary, it
> ought to be false. Or did I simply misunderstand the purpose of the
> pdx_is_region_compressible() invocations?

If there's no gap between the regions it's IMO intended for
pdx_is_region_compressible() to return true, as the whole region is
continuous in both the PFN and PDX spaces, and hence compressible
(even if it spans multiple regions).

But maybe I'm not understanding your point correctly, could you maybe
provide an example if you disagree with my reply above?  Sorry if I'm
being dull, with this compression stuff it's sometimes hard for me to
visualize the case you are trying to make without a concrete
example.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Jun 27 15:18:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 15:18:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027744.1402257 (Exim 4.92)
	(envelope-from )
	id 1uVAqP-0005yC-Dx; Fri, 27 Jun 2025 15:18:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027744.1402257; Fri, 27 Jun 2025 15: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 1uVAqP-0005y5-BB; Fri, 27 Jun 2025 15:18:25 +0000
Received: by outflank-mailman (input) for mailman id 1027744;
 Fri, 27 Jun 2025 15:18:24 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uVAqO-0005xx-2J
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 15:18:24 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uVAqN-005LM2-0x;
 Fri, 27 Jun 2025 15:18:23 +0000
Received: from amontsouris-682-1-55-1.w90-87.abo.wanadoo.fr ([90.87.218.1]
 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 1uVAqM-00DMPi-34;
 Fri, 27 Jun 2025 15:18: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" 
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=XAIVYsToANYHv+QClJmtZ2ptOEbCFh6lWZcNRa3kXP8=; b=VVrY5tjottgWDDwLj5w4dt/8wy
	QZXSWrQgwntm3EayaJBgFXKwX/v7huB8J77y/rVgU3k/1K592xdThLl7Ip9IeUgCeF046GfgXBbrE
	/aY/6odeeE0FW0XfwlgHtbOkW1r8o27wvKXBA+arv7+ohMBnLjEm9pjj4bFyMsfh2nSU=;
Date: Fri, 27 Jun 2025 17:18:20 +0200
From: Anthony PERARD 
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,
	Doug Goldstein ,
	Alessandro Zucchelli 
Subject: Re: [XEN PATCH] automation/eclair: Make report browsing URL
 configurable.
Message-ID: 
References: <2c0003504925e6f62b0bb1a13711c206e40f9393.1750919773.git.nicola.vetrini@bugseng.com>
 
 <194c24271abdadf062cab1b0f80a6fdc@bugseng.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <194c24271abdadf062cab1b0f80a6fdc@bugseng.com>

On Fri, Jun 27, 2025 at 10:39:21AM +0200, Nicola Vetrini wrote:
> On 2025-06-26 12:08, Anthony PERARD wrote:
> > On Thu, Jun 26, 2025 at 08:38:18AM +0200, Nicola Vetrini wrote:
> > > +eclairReportHost="${MACHINE_HOST:-saas.eclairit.com}"
> > > +eclairReportPort="${MACHINE_PORT:-3787}"
> > > +eclairReportUrlPrefix="https://${eclairReportHost}:${eclairReportPort}"
> > 
> > Please, don't make the port number mandatory. Can you merge both host
> > and port in the same variable? This part seems to be called "authority":
> > 
> >     https://en.wikipedia.org/wiki/URL#Syntax
> > 
> > Also, don't use `MACHINE` as prefix/namespace for these new variables,
> > in a pipeline context, "machine" could be many things. Maybe
> > "ECLAIR_REPORT_HOST" for this one? With the default been:
> > 
> >     ECLAIR_REPORT_HOST=saas.eclairit.com:3787
> > 
> 
> I can merge host and port and change the variable prefix, but I think there
> is a misunderstanding. This address is used both as the base for report
> browsing and pushing the results.

Well, the patch is all about "report browsing URL" as stated in the
subject.

> While we should alter the latter (e.g.,
> ECLAIR_REPORT_PROXY_HOST) to point to the proxy so that the proxy is shown

"proxy"? That's implementation detail, there's no need to know that the
host used to browse the result is different than the host where the
result are stored. (I mean having "proxy" in the name of the variable
holding detail of how to access the reports, been a part of an url or
just the host)

> in the CI logs, the address where the results are pushed is fixed and set in
> the docker runner env. This is not ideal, but I didn't find a better way
> with GitLab CI to let the analysis push locally.

Having the configuration for where to push the result in the runner env
seems like the best option to me, if that report server is tied to the
eclair runner.

> > > diff --git a/automation/scripts/eclair b/automation/scripts/eclair
> > > index 0a2353c20a92..7020eaa0982f 100755
> > > --- a/automation/scripts/eclair
> > > +++ b/automation/scripts/eclair
> > > @@ -1,4 +1,15 @@
> > > -#!/bin/sh -eu
> > > +#!/bin/sh -eux
> > > +
> > > +# Runner-specific variables
> > > +ex=0
> > > +export "$(env | grep MACHINE_ARTIFACTS_ROOT)" || ex=$?
> > > +[ "${ex}" = 0 ] || exit "${ex}"
> > 
> > That's a really complicated way to check a variable is set...
> > Exporting a variable that's already in env isn't useful, and I think
> > `ex` is only ever set to `0`. It seems that `dash` just exit if you do
> > `export=""`.
> > 
> > You could simply do:
> > 
> >     : ${MACHINE_ARTIFACTS_ROOT:?Missing MACHINE_ARTIFACTS_ROOT variable}
> >     : ${MACHINE_ECDF_DIR:?Missing MACHINE_ECDF_DIR variable}
> > 
> > To check that the variables are set. Or nothing, if you add `set -u` to
> > the script (instead of the one -u in the sheband which might be ignored
> > if one run `sh ./eclair` instead of just `./eclair`.) Also the variable
> > should come from the env, as nothing sets it, so no need to for that.
> > 
> > ( The `:` at the begining of the line is necessary, and behave the same
> > way as `true` does. We need it because ${parm:?msg} is expanded.)
> > 
> > Or you could use `if [ -z "${param}" ]` if ${param:?msg} is too obscure.
> > We would just have "parameter not set" instead of a nicer message, due
> > to `set -u`.
> > 
> 
> I agree it is ugly and counterintuitive, but the core idea here is that the
> variable is set but not exported for some reason, so just `export VAR` does
> not behave in the same way as the incantation `export "$(env | grep
> MACHINE_ARTIFACTS_ROOT)"` iirc. I'll double check if there's a better way to
> achieve this (other than switching to bash in the shebang).

Isn't that script `./eclair` the beginning of the script? I can't find
anything that `source` this file so it must be. Which mean, if
MACHINE_ARTIFACTS_ROOT is set, it is exported, because nothing sets it
between the beginning of the script and this line. So there's no need to
check that the variable is exported (if it is not exported, it is a bug
in the shell).

The only thing left to do is to check that it is set and non-zero
length. But I still wonder why you do that here, since "action.settings"
also check the variable and use a default value.

There's no need to use bash for this. (They are plenty of reason to use
bash instead of posix shell, but that is just not one of them.)

Cheers,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Fri Jun 27 15:59:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 15:59:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027795.1402268 (Exim 4.92)
	(envelope-from )
	id 1uVBTe-0002dW-DT; Fri, 27 Jun 2025 15:58:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027795.1402268; Fri, 27 Jun 2025 15: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 1uVBTe-0002dP-9l; Fri, 27 Jun 2025 15:58:58 +0000
Received: by outflank-mailman (input) for mailman id 1027795;
 Fri, 27 Jun 2025 15:58: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 1uVBTd-0002dJ-BX
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 15:58:57 +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 a0e35821-536f-11f0-a310-13f23c93f187;
 Fri, 27 Jun 2025 17:58:56 +0200 (CEST)
Received: by mail-oa1-x2b.google.com with SMTP id
 586e51a60fabf-2eacb421554so11274fac.1
 for ; Fri, 27 Jun 2025 08:58:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a0e35821-536f-11f0-a310-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1751039935; x=1751644735; 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=bfhXgoSRbVGfllKxX873BxM5jQrG1yx9g1GhERgQaWc=;
        b=UCaIOy2zfdJaNXIlP5PzlP//DLiZlGC/3oY7K3VT/J/Gao9KwWYyEeIKEO9dnYbXxE
         f9OmpdIvrCYr9qrNqEnDvi/2JxjMD7OyzRSbC3F4X+9LrcoiI71YtIYJs4Cdu3k6nxFw
         3vKk1YmUPdBTsHuX5KAuenPBPNuhW9DBJvXYA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751039935; x=1751644735;
        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=bfhXgoSRbVGfllKxX873BxM5jQrG1yx9g1GhERgQaWc=;
        b=XhM0QCt21J5ozXuvOvvu6KXRdYw6qYYH1Fxn63z85bVhEQ6jS88Px9ydrny2zkP9Kd
         Q0npRFVXcykKV1dPcJtsSlUg/VW3yJnRChcj5414ZerJvAEWaM5pJyP2v19q487qDS9x
         G7Qf338xwZGrkrNw4QjNOI4W/4JEw/PVSHMfuIcH/pqS/Ru6NeV8HIVAoiaXklaceqdr
         nrJKcSwINGWimNJyZ7YJaOcAt3c29WuZvpWU0aEj3lY/N69ekTkY2UPo7p6rSA7GHCQ7
         PFONN8Kd7alGK+WxlQCkkoesLnSZoTf5r7q5cZ2U16kdZYPrL0smbz5LRwMy3zZm5n6l
         4Ffg==
X-Gm-Message-State: AOJu0YwPMNM6+VuXAFfBpJT7hajaGInHHpyYGlAzFTbOVIr5yyey1DCH
	3DqgoB7V2wD2DdO/Bio8fzj8jaCiGrMtcKL+7BZCL8IOf8VQoev4KjKzJUdtldlhNfHDpRbM6ws
	461b8sGl6fo8a5MqaLdx9y5Mjwk/TGGNLqsbbTjwLQA==
X-Gm-Gg: ASbGncvsL+ejGFF+rmipZKRtXp7DuT8FJBkbAVYdZ0lFwaJa8In55mrivaFoX/pYS0f
	BTzQPZ+o8BjpowVN+PTBig7NWOglScXYOXDyNi3ScPcJqGV2vHpH0RtiDSzvE28fNVFoYc1Ic2c
	D/K8ThNYkrQgB6koN+4YI2VLypOXwl7QPMwaqrraP4
X-Google-Smtp-Source: AGHT+IGgUjoXN+/3708UY+Ls768JIcOYLySGYaBbKEywbE4g2hWExn4laNX0/JHfqBXrgcTPhe0TCimZXNri84J21/w=
X-Received: by 2002:a05:6870:b291:b0:2e9:1e11:3183 with SMTP id
 586e51a60fabf-2efed453abfmr2221668fac.8.1751039934787; Fri, 27 Jun 2025
 08:58:54 -0700 (PDT)
MIME-Version: 1.0
References: <20250624083157.9334-1-frediano.ziglio@cloud.com>
 
  
  
 
In-Reply-To: 
From: Frediano Ziglio 
Date: Fri, 27 Jun 2025 16:58:43 +0100
X-Gm-Features: Ac12FXzak7oPGdewtWGyzrEKXVYaMKnYw6RoBdQr3Tg0wzl24EYksSfQvuxtDV0
Message-ID: 
Subject: Re: [PATCH 0/2] xen/efi: Make boot more flexible, especially with GRUB2
To: =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= 
Cc: xen-devel@lists.xenproject.org, 
	"Daniel P. Smith" , Jan Beulich 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 27, 2025 at 3:20=E2=80=AFPM Marek Marczykowski-G=C3=B3recki
 wrote:
>
> On Fri, Jun 27, 2025 at 01:29:48PM +0100, Frediano Ziglio wrote:
> > On Thu, Jun 26, 2025 at 4:03=E2=80=AFPM Marek Marczykowski-G=C3=B3recki
> >  wrote:
> > >
> > > On Thu, Jun 26, 2025 at 09:12:53AM +0100, Frediano Ziglio wrote:
> > > > On Wed, Jun 25, 2025 at 9:26=E2=80=AFPM Marek Marczykowski-G=C3=B3r=
ecki
> > > >  wrote:
> > > > >
> > > > > On Tue, Jun 24, 2025 at 09:38:42AM +0100, Frediano Ziglio wrote:
> > > > > > On Tue, Jun 24, 2025 at 9:32=E2=80=AFAM Frediano Ziglio
> > > > > >  wrote:
> > > > > > >
> > > > > > > The combination of GRUB2, EFI and UKI allows potentially more=
 flexibility.
> > > > > > > For instance is possible to load xen.efi from a no ESP partit=
ion leaving
> > > > > > > a boot loader like GRUB2 taking care of the file loading.
> > > > > > > This however requires some changes in Xen to be less restrict=
ive.
> > > > > > > Specifically for GRUB2 these changes allows the usage of "cha=
inloader"
> > > > > > > command with UKI and reading xen.efi from no ESP (so no Devic=
eHandle
> > > > > > > set) and usage of "linux" and "initrd" commands to load separ=
ately
> > > > > > > the kernel (embedding using UKI) and initrd (using LoadFile2 =
protocol).
> > > > > >
> > > > > > I was forgetting. If somebody wants to test "linux" and "initrd=
"
> > > > > > command with these changes be aware that GRUB currently has a p=
roblem
> > > > > > passing arguments, I posted a patch, see
> > > > > > https://lists.gnu.org/archive/html/grub-devel/2025-06/msg00156.=
html.
> > > > > > I also have a workaround for this issue in xen but it would be =
better
> > > > > > to have a fix in GRUB.
> > > > >
> > > > > Can you tell more how to test this, especially the second variant=
? When
> > > > > trying to use GRUB linux or linuxefi commands on xen.efi, I get "=
invalid
> > > > > magic number" error.
> > > > >
> > > >
> > > > That's weird.
> > > >
> > > > Be the way. As usual I have a super complicated script that does ev=
erything.
> > > >
> > > > But to simplify:
> > > > - I compile xen (plain upstream plus my patches) with "make -C
> > > > ~/work/xen/xen -j O=3Dnormal MAP"
> > >
> > > Is there any that would be related to the "invalid magic" error? IIUC
> > > without your patches options will be mangled, but I don't think I get
> > > this far.
> > >
> >
> > I tried to do some changes and check the CI with your branch. Not hard
> > to reproduce and the test looks correct.
> > Looking at GRUB code I can see various "linux" command implementations
> > and it looks like yours is picking up i386-pc target and not
> > x86_64-efi one which is really odd to me.
>
> Indeed, very odd, I do pass -O x86_64-efi option explicitly...
>
> But also, when I do the test locally with grub 2.12 from Fedora, I get th=
e filename
> prefix:
>
>     error: ../../grub-core/loader/i386/efi/linux.c:387:invalid magic numb=
er.
>
> which does look like the efi variant.
>
> This is even more interesting, as this path does not exist in the
> upstream repository. It appears as it's _yet another_ linux loader added
> by Fedora package:
> https://src.fedoraproject.org/rpms/grub2/blob/rawhide/f/0213-Add-support-=
for-Linux-EFI-stub-loading.patch
> That code I think looks for some Linux-specific header with "EFI
> handover" pointer?
>

So, yet another "linux" loader :-(
I found that a bit crazy... Why not have a single "linux"
implementation calling different architecture specific functions? I
mean, some parts like arguments parsing and handling are pretty
common, the syntax should be the same. And is not the Linux booting
format already complicated enough to add another entry point format?

> I don't see exactly this patch in Debian package, but there are also
> some messing with the 'linux' command, so I guess it may be similar
> issue.
>
> If I use upstream grub directly, then the "linux" command indeed doesn't
> complain.
>
> So, it looks like major distributions use a patched grub version that
> changes behavior of "linux" command. IIUC many of those patches are
> about hardening SecureBoot, and shim-review kinda suggest using patched
> version (many of the submissions explicitly mention the at least patch
> grub for NX). So, I think this needs figuring out how to make your
> approach working with grub flavor that is actually used by SB-enabled
> distributions...
>

We (xenserver) would like to provide booting using separate
hypervisor, kernel and initrd.
Using "linux" was an old discussed option which had a nice usage.
The merged patches allow to have a fully UKI file bundling kernel and
initrd loaded from no-ESP partition which is nice to have.
For the final solution I was thinking about using "xen_hypervisor" and
"xen_module" already present for ARM. From the user perspective is
surely less confusing than using "linux" to pass something which is
not Linux.

Frediano


From xen-devel-bounces@lists.xenproject.org Fri Jun 27 16:20:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 16:20:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027814.1402277 (Exim 4.92)
	(envelope-from )
	id 1uVBoJ-00073h-62; Fri, 27 Jun 2025 16:20:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027814.1402277; Fri, 27 Jun 2025 16:20:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uVBoJ-00073a-3P; Fri, 27 Jun 2025 16:20:19 +0000
Received: by outflank-mailman (input) for mailman id 1027814;
 Fri, 27 Jun 2025 16:20: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 1uVBoG-00073U-Sx
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 16:20:17 +0000
Received: from fout-a7-smtp.messagingengine.com
 (fout-a7-smtp.messagingengine.com [103.168.172.150])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 985ac14c-5372-11f0-b894-0df219b8e170;
 Fri, 27 Jun 2025 18:20:10 +0200 (CEST)
Received: from phl-compute-06.internal (phl-compute-06.phl.internal
 [10.202.2.46])
 by mailfout.phl.internal (Postfix) with ESMTP id 2A634EC0237;
 Fri, 27 Jun 2025 12:20:09 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-06.internal (MEProxy); Fri, 27 Jun 2025 12:20:09 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
 27 Jun 2025 12:20:02 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 985ac14c-5372-11f0-b894-0df219b8e170
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=1751041209;
	 x=1751127609; bh=ZZVBX7SqKAgFWWed/Qm/9P37J5UgF6jpOyUv6CjRlYU=; b=
	ckDgxDeBzCrBc0QgJX+5kbj2jhS7JVdXYw+2UZqx5103dBhdPrht0xkG7zbFR+mD
	OIP8LLq9S31F21qoUfccrL1uDCrpb4/noF1bQj+z7yY4Qfx52r8PSUXAl3iqpGXm
	tCTLhbMx0LtxFaDBwTfTG5EKYDueodI97O3Jc7VTJxQ2MpJ+6dnQkRFFx3f0GFX3
	VXDzenRpkiqpk3fJZjb7HKHyuJgra9+ivn0/7YC1cpx6E739PeZp1VWMk72LCuMu
	iQG6lXpj6DK8g8a4R4D/TCJQ8Pq6ZlQwZlkJQjKzcnST5TTokDgYCUkJT4mUN6oj
	v1k8kNVXPr+2AxUgLXWJlw==
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=
	1751041209; x=1751127609; bh=ZZVBX7SqKAgFWWed/Qm/9P37J5UgF6jpOyU
	v6CjRlYU=; b=oE4V5LF78diF3/s9ghvnPd+njq+D3ntdUpc+Et+1Cwm9nA4MCUo
	mNqGaaP2gK1pePCAgBpp4S9ZZtYqmhuXrgcIpPhDQbMzkS+rFqPay77eHTEE9E36
	Mc7OVT84cbi9om7Wf8ecQ6IUzcuWaz8oFQMpsUM7cmnmmdKHzSUnikd6vNnYQhra
	ff3Mw+eYyNHB29RWoHuGuDHR9FFMr/RX1II/sDrOwsd/wnXvYBZee7V6OmxYC/QD
	D2KkxWK1GLNJjQJxsXQp93FeRaS6xtGz1PVcenREZd270ZN5azoEkHmQy+ecT6pL
	yTzGa5ie0oWCFj+iDlSJFCNWZfsgJfNy7Zw==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdefheefucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceurghi
    lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh
    epfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcuofgr
    rhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvihhsih
    gslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfduleetfeev
    hfefheeiteeliefhjefhleduveetteekveettddvgeeuteefjedunecuvehluhhsthgvrh
    fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhv
    ihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepgedpmhhoug
    gvpehsmhhtphhouhhtpdhrtghpthhtohepfhhrvgguihgrnhhordiiihhglhhiohestghl
    ohhuugdrtghomhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnph
    hrohhjvggtthdrohhrghdprhgtphhtthhopeguphhsmhhithhhsegrphgvrhhtuhhsshho
    lhhuthhiohhnshdrtghomhdprhgtphhtthhopehjsggvuhhlihgthhesshhushgvrdgtoh
    hm
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Fri, 27 Jun 2025 18:19:58 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Frediano Ziglio 
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" ,
	Jan Beulich 
Subject: Re: [PATCH 0/2] xen/efi: Make boot more flexible, especially with
 GRUB2
Message-ID: 
References: <20250624083157.9334-1-frediano.ziglio@cloud.com>
 
 
 
 
 
 
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="NQ0ctA3HwDKAsDNG"
Content-Disposition: inline
In-Reply-To: 


--NQ0ctA3HwDKAsDNG
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Fri, 27 Jun 2025 18:19:58 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Frediano Ziglio 
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" ,
	Jan Beulich 
Subject: Re: [PATCH 0/2] xen/efi: Make boot more flexible, especially with
 GRUB2

On Fri, Jun 27, 2025 at 04:58:43PM +0100, Frediano Ziglio wrote:
> On Fri, Jun 27, 2025 at 3:20=E2=80=AFPM Marek Marczykowski-G=C3=B3recki
>  wrote:
> > So, it looks like major distributions use a patched grub version that
> > changes behavior of "linux" command. IIUC many of those patches are
> > about hardening SecureBoot, and shim-review kinda suggest using patched
> > version (many of the submissions explicitly mention the at least patch
> > grub for NX). So, I think this needs figuring out how to make your
> > approach working with grub flavor that is actually used by SB-enabled
> > distributions...
> >
>=20
> We (xenserver) would like to provide booting using separate
> hypervisor, kernel and initrd.
> Using "linux" was an old discussed option which had a nice usage.
> The merged patches allow to have a fully UKI file bundling kernel and
> initrd loaded from no-ESP partition which is nice to have.
> For the final solution I was thinking about using "xen_hypervisor" and
> "xen_module" already present for ARM. From the user perspective is
> surely less confusing than using "linux" to pass something which is
> not Linux.

In which case, loading initrd using Linux-specific grub part doesn't
make sense, no? Or is that xen_module going to use similar mechanism?

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

--NQ0ctA3HwDKAsDNG
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmhexLAACgkQ24/THMrX
1ywMOggAk29E3mJcF3bkb7YZQjihG672c4QzHADy+2pVCcJllaq3kSQuJxJWB+0z
yMkEPlaAfGaTRwVFSoIf7iIKBSO6Ay4PGnpUv5kM8sd9PTgT9EJqgUAMhBxpz2lZ
+FAIktmVogP3JzBxiAVB3/QPDmrsIMf6v3Dz/xf0mZ+G/KQKPmQEuQ6bvUMwZdpR
Ztfg53nJL6tyhTzAEexUZJdmfgPlbCpxQ9/VW4nklrAqAq8f2kmt0E713eZFzCc4
vBHc0qubmMRnSVvj9VaKF836K7IZ/Sw3maa2mcFmoWF69PQ0feptQSJObqxF+gV+
FnH7V56YOy0WEWgDoq7HNuFfGo/SLg==
=nrMT
-----END PGP SIGNATURE-----

--NQ0ctA3HwDKAsDNG--


From xen-devel-bounces@lists.xenproject.org Fri Jun 27 16:55:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 16:55:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027835.1402289 (Exim 4.92)
	(envelope-from )
	id 1uVCLn-0002eP-Q7; Fri, 27 Jun 2025 16:54:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027835.1402289; Fri, 27 Jun 2025 16:54: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 1uVCLn-0002eI-LI; Fri, 27 Jun 2025 16:54:55 +0000
Received: by outflank-mailman (input) for mailman id 1027835;
 Fri, 27 Jun 2025 16:54:54 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uVCLm-0002eC-Qx
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 16:54:54 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uVCLe-005NZ1-2C;
 Fri, 27 Jun 2025 16:54:46 +0000
Received: from [2a02:8012:3a1:0:e11a:3963:f51a:873d]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uVCLe-00Dmch-14;
 Fri, 27 Jun 2025 16:54: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=P8Whh5bb76iAe4fZ767BXfurQbS4qb59ahcZD15w1JE=; b=R8a8wMjyHeJGnLDSZ5gf8H9vNC
	V2pHwXy9IjynFvp5bIC1U2y+hTHtXMT5GiRfuExoWHoVwITDq3LHt5Eyyd3cmrvc9rD6WGD1lf3pO
	BNDRF8DXE4/Cw03bCo62U9zBKPyU0TCJZNpR912TKLp2+SQEV4HowFYWrs4T4MOt3pdE=;
Message-ID: 
Date: Fri, 27 Jun 2025 17:54:43 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/2] xen/console: unify printout behavior for UART
 emulators
To: Stefano Stabellini ,
 Jan Beulich 
Cc: dmkhn@proton.me, andrew.cooper3@citrix.com, anthony.perard@vates.tech,
 michal.orzel@amd.com, roger.pau@citrix.com, dmukhin@ford.com,
 xen-devel@lists.xenproject.org
References: <20250606201102.2414022-1-dmukhin@ford.com>
 <20250606201102.2414022-3-dmukhin@ford.com>
  
 
 
 
 
 <2f726960-4bdc-4996-b204-722c0253e2ab@suse.com>
 
Content-Language: en-US
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Stefano,

On 19/06/2025 01:45, Stefano Stabellini wrote:
> On Wed, 18 Jun 2025, Jan Beulich wrote:
>> On 18.06.2025 02:39, Stefano Stabellini wrote:
>>> On Thu, 12 Jun 2025, Jan Beulich wrote:
>>>> On 11.06.2025 21:07, Stefano Stabellini wrote:
>>>>> On Wed, 11 Jun 2025, Jan Beulich wrote:
>>>>>> On 11.06.2025 02:07, dmkhn@proton.me wrote:
>>>>>>> On Tue, Jun 10, 2025 at 10:21:40AM +0200, Jan Beulich wrote:
>>>>>>>> On 06.06.2025 22:11, dmkhn@proton.me wrote:
>>>>>>>>> From: Denis Mukhin 
>>> If I understood correctly I like your proposal. Let me rephrase it to
>>> make sure we are aligned. You are suggesting that:
>>>
>>> - domains without input focus will print with a (d) prefix
>>> - the domain with input focus will print without a (d) prefix
>>> - this applies to both DomUs and Dom0
>>
>> Except in the non-dom0less case, at least up and until there's at least
>> one other domain. I.e. I'd like to keep Dom0 boot output as it is today,
>> regardless of the presence of e.g. "conswitch=".
> 
> In the non-dom0less case, since dom0 has focus, it would naturally be
> without (d) prefix. Unless the user passes "conswitch=". Honestly, I
> wouldn't special-case conswitch= that way and would prefer keep things
> simple and consistent without corner cases. I don't think conswitch= is
> so widely used that it is worth the complexity to special-case it.

I am a bit confused with the wording. Before I can provide another 
opinion, I want to understand a bit more the concern.

 From my understanding the command line option "conswitch" is to allow 
the admin to change with key is used to switch between Dom0 and Xen. By 
default this is 'a'. So are you referring to the fact a trailing "x" (to 
not switch to dom0 console) can be added?

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Fri Jun 27 18:30:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 18:30:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027888.1402297 (Exim 4.92)
	(envelope-from )
	id 1uVDqY-0005th-Fi; Fri, 27 Jun 2025 18:30:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027888.1402297; Fri, 27 Jun 2025 18: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 1uVDqY-0005ta-D5; Fri, 27 Jun 2025 18:30:46 +0000
Received: by outflank-mailman (input) for mailman id 1027888;
 Fri, 27 Jun 2025 18:30: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 1uVDqW-0005tT-Ov
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 18:30:44 +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 d2e539ab-5384-11f0-b894-0df219b8e170;
 Fri, 27 Jun 2025 20:30:39 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id D3F525C5A24;
 Fri, 27 Jun 2025 18:30:37 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8C8A8C4CEE3;
 Fri, 27 Jun 2025 18:30: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: d2e539ab-5384-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1751049037;
	bh=Oaw2iCUaqoeLV7nVH29bJPzhAc/IGXNw4stc7aFDrvI=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=aLxzbNRNzEjh2wp5ELi3FgqwtTvwkPsCTUIRxy1Mzkmst46qnSooCQoc25r/4nXaE
	 JO4b50k/XpqPWui4Ny532NltP68VF2OTZ8f+4v5mzJwZdkmV0BATeSYy1cnnGTx0Al
	 aurqY5FdJkBZEnBOrNGaObHAIELXI8htUP+FTM+dPcLZ0+7aInEIkOYAK12fqcVVcx
	 PYTmcFhk2EYYdhYbFvRom5AKROEs/wlEfltW1yeyND3rvJU4CqMGXIiZVkxJjAqzN1
	 LnIwwsnXw1L1+z0Vf8xnJgoVoMXiRPKnnCUx0MTLVtDsEMlHizYu2G/ky9nrVb22Z/
	 bjV1HvWhABHQQ==
Date: Fri, 27 Jun 2025 11:30:35 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Michal Orzel 
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Volodymyr Babchuk 
Subject: Re: [PATCH] xen/arm: Drop frametable_virt_end
In-Reply-To: <20250627084334.45172-1-michal.orzel@amd.com>
Message-ID: 
References: <20250627084334.45172-1-michal.orzel@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 26 Jun 2025, Michal Orzel wrote:
> It has never been used since the introduction and is technically a dead
> code violating MISRA C.
> 
> Signed-off-by: Michal Orzel 

Reviewed-by: Stefano Stabellini 



From xen-devel-bounces@lists.xenproject.org Fri Jun 27 21:58:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jun 2025 21:58:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1027952.1402308 (Exim 4.92)
	(envelope-from )
	id 1uVH5j-0003Vh-7Z; Fri, 27 Jun 2025 21:58:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1027952.1402308; Fri, 27 Jun 2025 21:58:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uVH5j-0003Va-4z; Fri, 27 Jun 2025 21:58:39 +0000
Received: by outflank-mailman (input) for mailman id 1027952;
 Fri, 27 Jun 2025 21:58: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 1uVH5i-0003VT-AD
 for xen-devel@lists.xenproject.org; Fri, 27 Jun 2025 21:58:38 +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 dab482c8-53a1-11f0-b894-0df219b8e170;
 Fri, 27 Jun 2025 23:58:27 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id E2B8CA530E3;
 Fri, 27 Jun 2025 21:58:26 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5A547C4CEE3;
 Fri, 27 Jun 2025 21:58: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: dab482c8-53a1-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1751061506;
	bh=LILuPFdiV4NJH/A/Wo2jt/16/PE+mo8yo9PRRfSAC24=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=Z51bqiW3PwyPUZ0q2MGYuVlf8cfkVXeQaCCUFHcsZkmlzZq7+eqyoH2nwIFG0dvoC
	 Ca8JXJjeXdgaN/ozfBihEYDsBLMGthDd1tmlu5eqcHNxFGjhyudcDiM0jc4kR4+0Ta
	 UJxmnBLdT+u7Ko6D6trPCRETKSNzGsLeuJ4z+LRxcKgTRf2tnS0kraXY1crgFkhbfr
	 FayjfpSxRHvegl9rBjiuKJE+HVsUCkCx4OsQgKa6X5NIVNFHBUUHdF331ZlrwsHyfV
	 TEO227kRKdqx4xT+BjavhAKNSidWOCxgGolt7cPJxbbkER0k8S3JI4uIV9pAmhMKGG
	 ErW8CqPN5s4bw==
Date: Fri, 27 Jun 2025 14:58:24 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Julien Grall 
cc: Stefano Stabellini , 
    Jan Beulich , dmkhn@proton.me, 
    andrew.cooper3@citrix.com, anthony.perard@vates.tech, michal.orzel@amd.com, 
    roger.pau@citrix.com, dmukhin@ford.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 2/2] xen/console: unify printout behavior for UART
 emulators
In-Reply-To: 
Message-ID: 
References: <20250606201102.2414022-1-dmukhin@ford.com> <20250606201102.2414022-3-dmukhin@ford.com>   
    <2f726960-4bdc-4996-b204-722c0253e2ab@suse.com>
  
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 27 Jun 2025, Julien Grall wrote:
> Hi Stefano,
> 
> On 19/06/2025 01:45, Stefano Stabellini wrote:
> > On Wed, 18 Jun 2025, Jan Beulich wrote:
> > > On 18.06.2025 02:39, Stefano Stabellini wrote:
> > > > On Thu, 12 Jun 2025, Jan Beulich wrote:
> > > > > On 11.06.2025 21:07, Stefano Stabellini wrote:
> > > > > > On Wed, 11 Jun 2025, Jan Beulich wrote:
> > > > > > > On 11.06.2025 02:07, dmkhn@proton.me wrote:
> > > > > > > > On Tue, Jun 10, 2025 at 10:21:40AM +0200, Jan Beulich wrote:
> > > > > > > > > On 06.06.2025 22:11, dmkhn@proton.me wrote:
> > > > > > > > > > From: Denis Mukhin 
> > > > If I understood correctly I like your proposal. Let me rephrase it to
> > > > make sure we are aligned. You are suggesting that:
> > > > 
> > > > - domains without input focus will print with a (d) prefix
> > > > - the domain with input focus will print without a (d) prefix
> > > > - this applies to both DomUs and Dom0
> > > 
> > > Except in the non-dom0less case, at least up and until there's at least
> > > one other domain. I.e. I'd like to keep Dom0 boot output as it is today,
> > > regardless of the presence of e.g. "conswitch=".
> > 
> > In the non-dom0less case, since dom0 has focus, it would naturally be
> > without (d) prefix. Unless the user passes "conswitch=". Honestly, I
> > wouldn't special-case conswitch= that way and would prefer keep things
> > simple and consistent without corner cases. I don't think conswitch= is
> > so widely used that it is worth the complexity to special-case it.
> 
> I am a bit confused with the wording. Before I can provide another opinion, I
> want to understand a bit more the concern.
> 
> From my understanding the command line option "conswitch" is to allow the
> admin to change with key is used to switch between Dom0 and Xen. By default
> this is 'a'. So are you referring to the fact a trailing "x" (to not switch to
> dom0 console) can be added?

Yes, conswitch can also be used to ask Xen to keep the input focus to
itself, instead of giving it away to Dom0. I think this is the specific
feature Jan was referring to when he said he is using conswitch and the
proposal would change the way the output looks like for him, which is
true.

Today, dom0 would still print without any prefix.

Tomorrow with this proposal, dom0 would print with a "(d0)" prefix
because it doesn't have input focus.

The question is, with the new policy in place, whether this is worth the
trouble of having a special case to remove the "(d0)" prefix in the
conswitch=x case. I think it is not worth it, Jan thinks it is.


From xen-devel-bounces@lists.xenproject.org Sat Jun 28 02:08:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jun 2025 02:08:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1028059.1402318 (Exim 4.92)
	(envelope-from )
	id 1uVKzd-0006p9-Vk; Sat, 28 Jun 2025 02:08:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1028059.1402318; Sat, 28 Jun 2025 02: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 1uVKzd-0006p1-S6; Sat, 28 Jun 2025 02:08:37 +0000
Received: by outflank-mailman (input) for mailman id 1028059;
 Sat, 28 Jun 2025 02:08: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 1uVKzc-0006ov-Rr
 for xen-devel@lists.xenproject.org; Sat, 28 Jun 2025 02:08:36 +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 cafaa8f5-53c4-11f0-a310-13f23c93f187;
 Sat, 28 Jun 2025 04:08:33 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id D3972A45F97;
 Sat, 28 Jun 2025 02:08:32 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3CBECC4CEE3;
 Sat, 28 Jun 2025 02:08: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: cafaa8f5-53c4-11f0-a310-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1751076512;
	bh=mSpEq7rwbGmSwmxK6coN/ZhS7y7yVxYpe19dp62IYrk=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=LMBZOLUeSxlzHd7BAne8ddPrfdGZ7LiFvl64II1Clt0kuKl3K/vQ9wqHW1guYoIPf
	 s0KJeFsLKwNlMfhEeOQ43jB18lsPv4ntl/xTnMUttE3eWrRbgfqSZQytcIss2yxWwt
	 tSn2lM9bnh7mdT5Wb/dRRoynaw+vDBSMza/pwbUueZ/BAaEm04HXm2evbFEdk+SLN6
	 XbknH2F0g8tOsNwvuJ4uOO30lU4XcARNUNKz8CUh/O+IR1ZyV39FqAUSsh8/wR5iWF
	 TquYX/y630c5Pxrg0v5pf2egTupRiqNtFtkRnwIiF468zDvkie6LqO5fhd0X0pyeUg
	 e1WvwRkf2TesA==
Date: Fri, 27 Jun 2025 19:08:29 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Roger Pau Monne 
cc: xen-devel@lists.xenproject.org, Jan Beulich , 
    Andrew Cooper , 
    Anthony PERARD , 
    Michal Orzel , Julien Grall , 
    Stefano Stabellini , 
    Bertrand Marquis , 
    Volodymyr Babchuk , 
    Shawn Anastasio , 
    Alistair Francis , 
    Bob Eshleman , 
    Connor Davis , 
    Oleksii Kurochko , 
    Community Manager , 
    sstabellini@kernel.org
Subject: Re: [PATCH v2 0/8] pdx: introduce a new compression algorithm
In-Reply-To: <20250620111130.29057-1-roger.pau@citrix.com>
Message-ID: 
References: <20250620111130.29057-1-roger.pau@citrix.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

Hi Roger,

We have an ARM board with the following memory layout:

0x0-0x80000000, 0, 2G
0x800000000,0x880000000, 32GB, 2G
0x50000000000-0x50080000000 5T, 2GB 
0x60000000000-0x60080000000 6T, 2GB 
0x70000000000-0x70080000000 7T, 2GB 

It looks like your PDX series is exactly what we need.  However, I tried
to use it and it doesn't seem to be hooked properly on ARM yet. I spent
some time trying to fix it but I was unsuccessful.

As far as I can tell the following functions need to be adjusted but I
am not sure the list is comprehensive:

xen/arch/arm/include/asm/mmu/mm.h:maddr_to_virt
xen/arch/arm/mmu/mm.c:setup_frametable_mappings
xen/arch/arm/setup.c:init_pdx

Cheers,

Stefano

On Fri, 20 Jun 2025, Roger Pau Monne wrote:
> Hello,
> 
> This series implements a new PDX compression algorithm to cope with the
> spare memory maps found on the Intel Sapphire/Granite Rapids.
> 
> Patches 1 to 7 prepare the existing code to make it easier to introduce
> a new PDX compression, including generalizing the initialization and
> setup functions and adding a unit test for PDX compression.
> 
> Patch 8 introduce the new compression.  The new compression is only
> enabled by default on x86, other architectures are left with their
> previous defaults.
> 
> Thanks, Roger.
> 
> Roger Pau Monne (8):
>   x86/pdx: simplify calculation of domain struct allocation boundary
>   kconfig: turn PDX compression into a choice
>   pdx: provide a unified set of unit functions
>   pdx: introduce command line compression toggle
>   pdx: allow per-arch optimization of PDX conversion helpers
>   test/pdx: add PDX compression unit tests
>   pdx: move some helpers in preparation for new compression
>   pdx: introduce a new compression algorithm based on region offsets
> 
>  CHANGELOG.md                           |   3 +
>  docs/misc/xen-command-line.pandoc      |   9 +
>  tools/tests/Makefile                   |   1 +
>  tools/tests/pdx/.gitignore             |   3 +
>  tools/tests/pdx/Makefile               |  49 ++++
>  tools/tests/pdx/harness.h              |  99 +++++++
>  tools/tests/pdx/test-pdx.c             | 224 +++++++++++++++
>  xen/arch/arm/include/asm/Makefile      |   1 +
>  xen/arch/arm/setup.c                   |  34 +--
>  xen/arch/ppc/include/asm/Makefile      |   1 +
>  xen/arch/riscv/include/asm/Makefile    |   1 +
>  xen/arch/x86/domain.c                  |  40 +--
>  xen/arch/x86/include/asm/cpufeatures.h |   1 +
>  xen/arch/x86/include/asm/pdx.h         |  75 +++++
>  xen/arch/x86/srat.c                    |  30 +-
>  xen/common/Kconfig                     |  37 ++-
>  xen/common/pdx.c                       | 379 ++++++++++++++++++++++---
>  xen/include/asm-generic/pdx.h          |  24 ++
>  xen/include/xen/pdx.h                  | 201 +++++++++----
>  19 files changed, 1056 insertions(+), 156 deletions(-)
>  create mode 100644 tools/tests/pdx/.gitignore
>  create mode 100644 tools/tests/pdx/Makefile
>  create mode 100644 tools/tests/pdx/harness.h
>  create mode 100644 tools/tests/pdx/test-pdx.c
>  create mode 100644 xen/arch/x86/include/asm/pdx.h
>  create mode 100644 xen/include/asm-generic/pdx.h
> 
> -- 
> 2.49.0
> 


From xen-devel-bounces@lists.xenproject.org Sat Jun 28 06:46:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jun 2025 06:46:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1028173.1402328 (Exim 4.92)
	(envelope-from )
	id 1uVPKj-0005J2-Gm; Sat, 28 Jun 2025 06:46:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1028173.1402328; Sat, 28 Jun 2025 06:46: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 1uVPKj-0005Ik-Ad; Sat, 28 Jun 2025 06:46:41 +0000
Received: by outflank-mailman (input) for mailman id 1028173;
 Sat, 28 Jun 2025 06:46: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 1uVPKi-0005Ie-2v
 for xen-devel@lists.xenproject.org; Sat, 28 Jun 2025 06:46:40 +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 a1088e74-53eb-11f0-b894-0df219b8e170;
 Sat, 28 Jun 2025 08:46:34 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3a531fcaa05so217060f8f.3
 for ; Fri, 27 Jun 2025 23:46:33 -0700 (PDT)
Received: from localhost.localdomain (253.226.6.51.dyn.plus.net.
 [51.6.226.253]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a88c80b50bsm4506375f8f.42.2025.06.27.23.46.31
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 27 Jun 2025 23:46:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a1088e74-53eb-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1751093192; x=1751697992; 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=ow9uK6vnAdJJy0Mj/oldGRR5lyMmniaKiPz0dy9nDSI=;
        b=IRfLhTrEx6mw0pgIEQEpp8G/f7ehlHtcGJDwjCn3BnHmMCDyC0kd5UAMjg+h56Gq3b
         nbCTRY1uO9GWsbA7lR7RY9zbZ5TgRkAmx/4i08Ll2Dp4ExiaFMSeNk5EvuOx1FVQPyZG
         ftAuvk0Wb429h9XhOnH/eVkm2jBFQSlyBvgII=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751093193; x=1751697993;
        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=ow9uK6vnAdJJy0Mj/oldGRR5lyMmniaKiPz0dy9nDSI=;
        b=l2jyoF2YlPNUDUNlHcD7YPJiNnDYsmdhaRHZiTk/lPCSC6hJD4RgbOkRdZUmEiMcjZ
         ElizqvyOOI2mpkDxgd1PVuhBZltubTpelaLcjXGtWTb5otUpRp52d0RuWZmavymF/YyA
         NcXyismLZYrBS9+8YKHs8v5iwuURplWYc/FXsVcsWYWeuq64m1caePwQJSwPcVmUXGjS
         S81Bt7F4T2dltqGvBPojiASl7jZcqBQzpE2y1Tdcz1FygOOD/HZyScK5INu/gl+ujoKi
         2jK4qAkkFo/Ym/Jz1ChGhEG6j12A+ZDTpEfyM38w2R44G2zBE/VkchypKq6B1PLfdLi4
         IEHQ==
X-Gm-Message-State: AOJu0YxDtr0A3PX+0Uzb9f5AEpoGgYuYfSN62ZpGv2Xl3XqccpmpkPeQ
	qSTRMV3wNihST13UFYMH1P38/HPt8TQhBRgYusUA226iP1G5RzXFzYFEAV2Cr3VnFwc/xbxbUER
	Zj6XG2DY=
X-Gm-Gg: ASbGncsoWaHT4jFzs8jgNZLcPl6vnFf1kRtSjtjspnyMLsD4UiT+DSpnFUNfLCu8Auo
	sAygMikIkPXywSVIL1nmq8EqESBe4sriF6vIhFcBSPAv3Hs614j+LweJmLyTLFVjOBlDyp8WIbt
	zEq7Dwh3/ocRiy7/++rwY+Mppllf3u2btuv7NSWaRoFKgs+SFVjySp4Vkouxz8nlQYTqhoZGcJL
	ZJPDh0soWqkXinjZc4qcLJP57vmwMeZPk4vmLYD39nePbYgFVP/gTRCecwKFvW9BnHMeG55wLWw
	T/rTipMy3n8Boj2gFgirlAGXx5JnRocfRxTKd2SyYghg4ZrDyhhZ27IniUO/av2GnH35GA/OqYQ
	FIZN0i1Q5+U6Qv3y5uGmo00nzhA3skA==
X-Google-Smtp-Source: AGHT+IGsT4qU7r69IPWDvVCaRs1obowz3Sw1fw2t2kepVAmQpnEnqRrEfif3OhNQ8SuvkIwQb/qI0w==
X-Received: by 2002:a05:6000:250f:b0:3a4:f936:7882 with SMTP id ffacd0b85a97d-3a8ffcca8b2mr5864226f8f.55.1751093192582;
        Fri, 27 Jun 2025 23:46:32 -0700 (PDT)
From: Frediano Ziglio 
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio ,
	"Daniel P. Smith" ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Jan Beulich 
Subject: [PATCH v5] xen/efi: Update error flow for read_file function
Date: Sat, 28 Jun 2025 07:46:18 +0100
Message-ID: <20250628064630.2222323-1-frediano.ziglio@cloud.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Use more explicit goto statements to handle common error code
path instead of a lot of if/else.

Signed-off-by: Frediano Ziglio 
---
Change since v4:
- fixed label indentation.
---
 xen/common/efi/boot.c | 80 +++++++++++++++++++++++--------------------
 1 file changed, 43 insertions(+), 37 deletions(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 9306dc8953..1019de6950 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -792,6 +792,8 @@ static bool __init read_file(EFI_FILE_HANDLE dir_handle, CHAR16 *name,
 
     if ( !name )
         PrintErrMesg(L"No filename", EFI_OUT_OF_RESOURCES);
+
+    what = L"Open";
     if ( dir_handle )
         ret = dir_handle->Open(dir_handle, &FileHandle, name,
                                EFI_FILE_MODE_READ, 0);
@@ -800,54 +802,58 @@ static bool __init read_file(EFI_FILE_HANDLE dir_handle, CHAR16 *name,
     if ( file == &cfg && ret == EFI_NOT_FOUND )
         return false;
     if ( EFI_ERROR(ret) )
-        what = L"Open";
-    else
-        ret = FileHandle->SetPosition(FileHandle, -1);
+        goto fail;
+
+    what = L"Seek";
+    ret = FileHandle->SetPosition(FileHandle, -1);
     if ( EFI_ERROR(ret) )
-        what = what ?: L"Seek";
-    else
-        ret = FileHandle->GetPosition(FileHandle, &size);
+        goto fail;
+
+    what = L"Get size";
+    ret = FileHandle->GetPosition(FileHandle, &size);
     if ( EFI_ERROR(ret) )
-        what = what ?: L"Get size";
-    else
-        ret = FileHandle->SetPosition(FileHandle, 0);
+        goto fail;
+
+    what = L"Seek";
+    ret = FileHandle->SetPosition(FileHandle, 0);
     if ( EFI_ERROR(ret) )
-        what = what ?: L"Seek";
-    else
-    {
-        file->addr = min(1UL << (32 + PAGE_SHIFT),
-                         HYPERVISOR_VIRT_END - DIRECTMAP_VIRT_START);
-        ret = efi_bs->AllocatePages(AllocateMaxAddress, EfiLoaderData,
-                                    PFN_UP(size), &file->addr);
-    }
+        goto fail;
+
+    what = L"Allocation";
+    file->addr = min(1UL << (32 + PAGE_SHIFT),
+                     HYPERVISOR_VIRT_END - DIRECTMAP_VIRT_START);
+    ret = efi_bs->AllocatePages(AllocateMaxAddress, EfiLoaderData,
+                                PFN_UP(size), &file->addr);
     if ( EFI_ERROR(ret) )
-        what = what ?: L"Allocation";
-    else
-    {
-        file->need_to_free = true;
-        file->size = size;
-        handle_file_info(name, file, options);
+        goto fail;
 
-        ret = FileHandle->Read(FileHandle, &file->size, file->str);
-        if ( !EFI_ERROR(ret) && file->size != size )
-            ret = EFI_ABORTED;
-        if ( EFI_ERROR(ret) )
-            what = L"Read";
-    }
+    file->need_to_free = true;
+    file->size = size;
+    handle_file_info(name, file, options);
 
-    if ( FileHandle )
-        FileHandle->Close(FileHandle);
+    what = L"Read";
+    ret = FileHandle->Read(FileHandle, &file->size, file->str);
+    if ( !EFI_ERROR(ret) && file->size != size )
+        ret = EFI_ABORTED;
+    if ( EFI_ERROR(ret) )
+        goto fail;
 
-    if ( what )
-    {
-        PrintErr(what);
-        PrintErr(L" failed for ");
-        PrintErrMesg(name, ret);
-    }
+    FileHandle->Close(FileHandle);
 
     efi_arch_flush_dcache_area(file->ptr, file->size);
 
     return true;
+
+ fail:
+    if ( FileHandle )
+        FileHandle->Close(FileHandle);
+
+    PrintErr(what);
+    PrintErr(L" failed for ");
+    PrintErrMesg(name, ret);
+
+    /* not reached */
+    return false;
 }
 
 static bool __init read_section(const EFI_LOADED_IMAGE *image,
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Sat Jun 28 13:59:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jun 2025 13:59:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1028315.1402338 (Exim 4.92)
	(envelope-from )
	id 1uVW4z-0003BO-0E; Sat, 28 Jun 2025 13:58:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1028315.1402338; Sat, 28 Jun 2025 13: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 1uVW4y-0003BF-RW; Sat, 28 Jun 2025 13:58:52 +0000
Received: by outflank-mailman (input) for mailman id 1028315;
 Sat, 28 Jun 2025 13:58: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 1uVW4w-0003B9-Sk
 for xen-devel@lists.xenproject.org; Sat, 28 Jun 2025 13:58:51 +0000
Received: from TY3P286CU002.outbound.protection.outlook.com
 (mail-japaneastazlp170100001.outbound.protection.outlook.com
 [2a01:111:f403:c405::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 029eb6b4-5428-11f0-a310-13f23c93f187;
 Sat, 28 Jun 2025 15:58:47 +0200 (CEST)
Received: from OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:10d::7)
 by TYCP286MB3800.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:37b::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8901.13; Sat, 28 Jun
 2025 13:58:40 +0000
Received: from OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
 ([fe80::80f1:db56:4a11:3f7a]) by OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
 ([fe80::80f1:db56:4a11:3f7a%5]) with mapi id 15.20.8901.012; Sat, 28 Jun 2025
 13:58: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: 029eb6b4-5428-11f0-a310-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=clGb2SASBlSBqUaLuNbv7zKndzd741hiJUHFJ/ldJ5G0UCiyiBFlZlFa7fcJGl1KlSPwuU1MR21jfi/e4SVFBivCf4I8yOzen0RfVTIyZo7o14Z7WAFCGcbBMFB9fMAo/na/G66kOIrPHXxE1WypGqtPoRQ7by0Z0Btx79jO1d/ZQ3uSPcVOXkXDiznrWkI8MkcxLujE3/qZwCZXRqeyXaOO1KEeHrP22AxLCxTnmBTVFv4orJWyyWv4Ycdn3G/3PqsG3jvZKIh9Dlh8WMsMtvRALSwnL/RgNHynzu6imv8FBi+3eeCVGP9a5mPUbU1HFbPNW/T6nyfs7JykzsBUdw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=u/w82UJ/CGkxr4brX5JsZdPrGEpt4QFGjYiEd6ZryFM=;
 b=EZOFykZbm5z2SETIF1p4mGydLwm9VmVZSgi3qs7+5SGiraV4dKrXxVwxA4D173JsiK+uCGQJlTA/0+pGXd2eRkYaWtG2SSh+d3yf/OhUZbZI0qjrAQz0bgNd7QkWrCq1z9W1rfmaA63eNXnpFSb3wrPttPKfdM3X2xZ5k+wXqDAfV0HIK96zGvhBt6snIJGR/LoDAGXDxMZqjBziCs6cRqzQ87+SPKmejAMBb5j18I/SJiy4RA41DjgOo7PEah6kgmTHhNIU7FmoSfpN7QcTpB//lzw0pbPu8CF54T9kpckLfC0I/hUrsOGtZYZp9DiBrc1MxKlpJmItBZYRWo+Avw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=valinux.co.jp; dmarc=pass action=none
 header.from=valinux.co.jp; dkim=pass header.d=valinux.co.jp; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valinux.co.jp;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=u/w82UJ/CGkxr4brX5JsZdPrGEpt4QFGjYiEd6ZryFM=;
 b=GSIAvUgiBv6HosIyfEZ617aLNa+mCGjIPFCIH4KqFAZPIdY6T3mw1N3N6YJLa2Vv4Mfng4+hO8zvmSzWzNXjNWLIHvvQE/8g/35uxx+TDBNyiW/XLZN66CyUkxJq/uVUVxtRNFQ2eu2/2L8JCMalqP03oA8DOlXOVEmlBpULKKc=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=valinux.co.jp;
Date: Sat, 28 Jun 2025 22:58:37 +0900
From: Koichiro Den 
To: Julien Grall 
Cc: xen-devel@lists.xenproject.org, 
	Stefano Stabellini , Bertrand Marquis , 
	Michal Orzel , Volodymyr Babchuk , 
	Andrew Cooper , Anthony PERARD , 
	Jan Beulich , Roger Pau =?utf-8?B?TW9ubsOp?= 
Subject: Re: [RFC PATCH 4/4] xen/arm: Implement standard PV time interface as
 per ARM DEN 0057A
Message-ID: 
References: <20250621151201.896719-1-den@valinux.co.jp>
 <20250621151201.896719-5-den@valinux.co.jp>
 <21cbc79b-2209-42ef-8085-81c41e8e697b@xen.org>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <21cbc79b-2209-42ef-8085-81c41e8e697b@xen.org>
X-ClientProxiedBy: TYBP286CA0043.JPNP286.PROD.OUTLOOK.COM
 (2603:1096:404:10a::31) To OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
 (2603:1096:604:10d::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: OS3P286MB0979:EE_|TYCP286MB3800:EE_
X-MS-Office365-Filtering-Correlation-Id: 4919abce-dcfe-4b47-c718-08ddb64be26f
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|10070799003|366016|1800799024|7416014|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?S6zw9UJFLE1VEaiZUKDYrvXOvn0AGZ+iz9usXVX4EVHlUHiYRIf6K2KFzUK8?=
 =?us-ascii?Q?Zkk0kaXvVXfuyZREpCSqBuoQthbgI9T9QK86Q+ga7aa5vW1P+S9chFiSkkgo?=
 =?us-ascii?Q?2D3PvPpppi+0FolNelt+UumN4XfwB6Of0QlubjH7Wmf38t1+PhdBla06vmyF?=
 =?us-ascii?Q?tb7XUI74OdXjTuR6B/u5KZR0Ucd5IuWfxLuPEHTHs8pb+evANht8Hxe9lzzI?=
 =?us-ascii?Q?TrpLOfa+wMz60aXo5iuQxnCJZInSoqFSpNfQVjt2XkBE3+1XXSfslMIHAVtr?=
 =?us-ascii?Q?d/kpSyNeSKMJSFcDqB4LFywwRySCeUDIlTkSbOqUgWa+6kGJxF8j+jNQlc5t?=
 =?us-ascii?Q?sCbMYwFMnbVv44vkwXms2uvsJe5PsJvoXnWsn9P3u9yr4tR88RCfGCY9S5L7?=
 =?us-ascii?Q?7LuZ7U6FD4mbBBEoChafn44vg7hlals0O8geb3qYzu5EVP/fLJ6+qBfshZ3J?=
 =?us-ascii?Q?eiZ+zGiYjq1BPK9ZVL9u2ubsHafKsIjDQrgTCl5YHBQMbBONMeQyHDzkRY5r?=
 =?us-ascii?Q?2DWFMVSKxelIb7QRHJaO3AO8/SxWVqzQzDF4l7ZPXxRF787uSI5f+qqqQkhe?=
 =?us-ascii?Q?gQfx/30MR2Z0w3OgWYsP2fsYfxMMjbdaeqyDZc+0ARi+/by/hc5C4HnMNpYW?=
 =?us-ascii?Q?smvMwVd93FZvy24PI1rWdbBlpplH2Chgv+R92Y9CdlB0AfAVI07qkffKIRIj?=
 =?us-ascii?Q?3Ltj5MYdqj6URuOpUkBNQHOrQmxZbaQvb23A3ZvqvU73IpqaRbeoH2HhQXfL?=
 =?us-ascii?Q?ngIPyCQ6ChZks9OI5YycEA3KHPEomAlVMxpg3xs40kPoOmJ1bwH2U8GtaeIa?=
 =?us-ascii?Q?pxt2l4Dy/vwxkijz7umYKvz2EJZgKiIKc4U+ynpruKaVF/cWF5zaHEFaN/xu?=
 =?us-ascii?Q?10IhtZmnrEbz1/0aW3889N5QjeSNEtNXIAO1gfjZXMEpmLoXY7Vb0qQUIHtc?=
 =?us-ascii?Q?yw3uGKOS2l101pg6+FAaMvoqqLAO9HMIPabZoS2vrIJCdbRSc6naox2oHAdS?=
 =?us-ascii?Q?sOwfR0DuIOy4NJTK4x2mvy5CxGvz5zv9iZAwO5uesEd1jN215rcD/SMOLs3o?=
 =?us-ascii?Q?ItDLmMTronYq4K/fKD5w+r0QT2R1/hniPGD+9HVe+LiCDzNOZqFM/PkSRNGJ?=
 =?us-ascii?Q?2G5tlgvXbTJn557pqxSjrSXZj9E3bkyvzp8Qm/UW/Bb6vBC7VbsbDBQU5pNW?=
 =?us-ascii?Q?G7e32/8J2QgCHGhh7zfPUubWpjyUpzgAf/uFMGRrGkkfCBC6GJ1rQYqiF9MY?=
 =?us-ascii?Q?4e/0rlTGDe1n/u1EUCWVd0uq9gwp2SCGR3KjPJyx5W1AR9NriY1Q+90/Ap8V?=
 =?us-ascii?Q?mF8IXSmdVVF6MxZ2p6cvhhRaPyiEhNwOGXY9n0YM4kyUhmBNMsOhexMDnQqj?=
 =?us-ascii?Q?d/129rriXfqOH95BhHxROARPMPRCTB/0xayJeq1XGgZfkAyXWdFqxLywIjmH?=
 =?us-ascii?Q?I7fLc/p3OYU=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(10070799003)(366016)(1800799024)(7416014)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?HWL0mjviVKVw6GxGfIY0mfYxSM/LA22GuDe1JSthiC7+CVHvP4n2JGbQ7Tl1?=
 =?us-ascii?Q?tKMyUVVcCUCbS+PF0409tK9ZOkX3sd3CJm5y5TRGzUn5FW9nwErgNrdiXmWX?=
 =?us-ascii?Q?P8gdx9yVnAyXLjy4BKkXqnu49wgruHkVYCi1CGtGfAbPXne3oAGxhKzIkRzG?=
 =?us-ascii?Q?1ZMh/rLjqcWO4GkJGncSulZceGE4wGYtnCFvjMcIl/sWCaDKyNWjgJsuXFIZ?=
 =?us-ascii?Q?f7m29Vu94P3bEnl2OclZgU4KXVVS3id6KUFpJ/S/xN/OKSyDdlJs0uuTIlwf?=
 =?us-ascii?Q?Da7j4E8cR+Hu/gsfn83aVYnFQGHAXfpOzP0DU8c4d1U6Oh7LPqmatshfffne?=
 =?us-ascii?Q?pbTKQfo5ZpY4dPzagLE1+3jPh0OQ/YF8YOKJmozs3lG3uDFMii4uXXM14xlx?=
 =?us-ascii?Q?QGadqb9ZbTR+2urfQwkHCKMYA9QqueQcS+HkAkMxBL+rUngJvQihPQcnP08R?=
 =?us-ascii?Q?dxklCWWNz/pZa2FzMibfGNi/zwNQIXax0sUIVo10VTFXk5yJhdsmD7NDsv4n?=
 =?us-ascii?Q?UuxJCGOjnkgoTgvIHFkZK4zSg3lgzuzOL+4cX3Ph/lLiPhqq1fbp+UHKXHym?=
 =?us-ascii?Q?lw+6LEpR0oCS8pdkieAKJvPJnY+g05lG9h7g2XuJeOI2LGnwHABBRa6ZVNNX?=
 =?us-ascii?Q?6fnj0+O2jxJHqmBvZ5MtPs9hOloQqMwQRpzHoDACvaQjJSFH0BLD7DetLbGH?=
 =?us-ascii?Q?0SQzZUZjT5CgNWKpqdiSR0H8TB2hvoo+zI9T0T0d3662NY6pfkjn7KfOGFFI?=
 =?us-ascii?Q?V60XgBVwbpwJFrO46YTWsvvN6HLvxs30oeQ6rzenBrktssbdZjuZG5ct9rcq?=
 =?us-ascii?Q?cJVVCYwepwPOK9GwjgANu7d9DUNm0ixRL7WR/AHkWSVSM1KO7fbgsO07Z5/d?=
 =?us-ascii?Q?1wpUPqs3oNMz00XQ7U3GqxDR8hKb+8euO5oP3nqFZOO5pDS4ufMh9/zK+JKy?=
 =?us-ascii?Q?L3JfmDZQLclDVOXjHjppTnNEX1VU3Xsk0Qxk/U87KSx3jKeuZShX3lRqmBPN?=
 =?us-ascii?Q?5Y455bPQwMhf3+bswIztE0GT8En35rgzcCCe0lLwCGlJNB8jU/QP87Or5QJm?=
 =?us-ascii?Q?ZnyJEi+PZR0VAbMC/Wgjp2jNCu1AueMlwSW4q+OtuAHvCz/zipIaNRpjN3Ov?=
 =?us-ascii?Q?V+xRfT0I88W0XWTeeQ7pVhQ+ACorl7C23k/J6i063AXAk3eFFtJzM8YEoEiv?=
 =?us-ascii?Q?L3TMLr279lA4KTcLVa8YN3PI3D9eCfX6n46zaFAUmU/8KbGy+3NBJHAW0/Xi?=
 =?us-ascii?Q?tHdqoUvXv1Dr7ShRWmsQQ6Sx6NX+C5BTgl8ZIrD3BjctxmxUbCc+7g+s8qs8?=
 =?us-ascii?Q?Fks2x3FbfLLaZ7LzUf+nqv4w9aZDtE5jhlSBeY4YHd6qIpRvzI8ghVqzGeeI?=
 =?us-ascii?Q?o/zZxt1Abhy6vMbWICNbog1okdzW9/+TEMiQwzL/EziUoZFMGDqQcMsq0Cx0?=
 =?us-ascii?Q?HOw9HbqOytlgNB+exMiD9Yqei5E3YmgXUCDYWU3MTTRbC2P7BOzkAn/6/ep0?=
 =?us-ascii?Q?x80ntGrsNKoVFMsQwtXWIIbVvxxJOfI1NnpLEE9Zqx/iNh3l0GOOO+eUuqMr?=
 =?us-ascii?Q?s53B/2TJKCHtusWJ4z5xPYy9qhFoEz0Qg5bZSvcZTzB1IWJv2mw9PhPcW/Jd?=
 =?us-ascii?Q?C4csznaWJnqX/avBKouTDNE=3D?=
X-OriginatorOrg: valinux.co.jp
X-MS-Exchange-CrossTenant-Network-Message-Id: 4919abce-dcfe-4b47-c718-08ddb64be26f
X-MS-Exchange-CrossTenant-AuthSource: OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jun 2025 13:58:39.6820
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 7a57bee8-f73d-4c5f-a4f7-d72c91c8c111
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 25oWMTFkvfnNl06o3pp7koYbqUvm3PXwpmzzf5/6+D1vmXy6f3hyRMP0EIf5Z2EpQABb1Sbr3n/HWX4hxKVS/A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYCP286MB3800

On Mon, Jun 23, 2025 at 09:41:47AM +0100, Julien Grall wrote:
> Hi Koichiro,
> 
> I haven't checked all the details. I will mainly comment on the Xen
> internals.

Hi Julien,

Thank you for the review, and apologies for my late response.

> 
---(snip)---
> > @@ -707,6 +723,7 @@ int arch_domain_create(struct domain *d,
> >                          unsigned int flags)
> >   {
> >       unsigned int count = 0;
> > +    int order;
> >       int rc;
> >       BUILD_BUG_ON(GUEST_MAX_VCPUS < MAX_VIRT_CPUS);
> > @@ -791,6 +808,19 @@ int arch_domain_create(struct domain *d,
> >       d->arch.sve_vl = config->arch.sve_vl;
> >   #endif
> > +    /*
> > +     * Preallocate the stolen time shared memory regions for all the
> > +     * possible vCPUs.
> > +     */
> > +    order = get_order_from_bytes(d->max_vcpus * sizeof(struct pv_time_region));
> 
> As this is an order, we could end up to waste memory fairly quickly. So we
> should try to free the unused pages from the order. That said, the maximum
> number of virtual CPUs we currently support is 128. If I am not mistaken,
> this could fit in 2 4KB pages. So I would also be ok with a
> BUILD_BUG_ON(MAX_VIRT_CPUS <= 128) and we defer this work.

I'll go with the former in the next iteration. Thanks!

> 
> > +    d->arch.pv_time_regions_gfn = INVALID_GFN;
> 
> Does this mean PV time is optional? If so, shouldn't we allocate the memory
> conditionally?
> 
> Also, looking at the code below, you seem to cater domains created via
> dom0less but not from the toolstack. I think both should be supported for
> the PV time.

Yes, that was intentional. I should've mentioned that this RFC series only
caters the dom0less case. For domains created dynamically via xl create, the
only viable solution I've found so far is to reserve PFN range(s) large enough
to cover the maximum possible number of toolstack-created domains on boot,
which I think would be too wasteful. Do you have any recommendations how to
reliably and dynamically allocating the shared region PFN(s) when using xl?

In any case, I agree that conditional allocation would be preferable.

> 
> Lastly, you probably only want to allocate the memory for 64-bit domain as
> this is unusable for 32-bit domains.
> 
> > +    d->arch.pv_time_regions = alloc_xenheap_pages(order, 0);
> > +    if ( !d->arch.pv_time_regions ) {> +        rc = -ENOMEM;
> > +        goto fail;
> > +    }
> > +    memset(d->arch.pv_time_regions, 0, PAGE_SIZE << order);
> > +>       return 0;
> >   fail:
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index 85b6909e2b0e..1c51b53d9c6b 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -1561,8 +1561,80 @@ int __init make_chosen_node(const struct kernel_info *kinfo)
> >       return res;
> >   }
> > -int __init make_resv_memory_node(const struct kernel_info *kinfo, int addrcells,
> > -                                 int sizecells)
> > +int __init make_pv_time_resv_memory_node(struct domain *d,
> > +                                         const struct kernel_info *kinfo,
> > +                                         int addrcells, int sizecells)
> > +{
> > +    __be32 reg[GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS];
> > +    unsigned int len = (addrcells + sizecells) * sizeof(__be32);
> > +    struct p2m_domain *p2m = p2m_get_hostp2m(d);
> > +    struct membanks *unused_banks = NULL;
> > +    void *fdt = kinfo->fdt;
> > +    unsigned regions_len;
> > +    gfn_t pv_time_gfn;
> > +    mfn_t pv_time_mfn;
> > +    paddr_t aligned;
> > +    paddr_t avail;
> > +    __be32 *cells;
> > +    int res;
> > +    int i;
> > +
> > +    /* Find unused regions */
> > +    regions_len = PAGE_ALIGN(d->max_vcpus * 64);
> 
> I would be best to avoid hardcoding the size of the region and use the size
> of struct pv_time_region.

Thanks for catching it, I'll fix this in v2.

> 
> > +    unused_banks = membanks_xzalloc(NR_MEM_BANKS, MEMORY);
> > +    if ( !unused_banks )
> > +        return -ENOMEM;
> > +
> > +    res = find_unused_regions(d, kinfo, unused_banks);
> > +    if ( res ) {
> > +        printk(XENLOG_WARNING "%pd: failed to find unused regions\n", d);
> > +        goto fail;
> > +    }
> > +    for ( i = 0; i < unused_banks->nr_banks; i++ ) {
> > +        const struct membank *bank = &unused_banks->bank[i];
> > +        aligned = PAGE_ALIGN(bank->start);
> > +        avail = bank->size - (aligned - bank->start);
> > +        if ( avail >= regions_len )
> > +            break;
> > +    }
> > +    if ( i == unused_banks->nr_banks ) {
> > +        res = -ENOSPC;
> > +        goto fail;
> > +    }
> > +
> > +    /* Insert P2M entry */
> > +    pv_time_mfn = virt_to_mfn(d->arch.pv_time_regions);
> > +    pv_time_gfn = gaddr_to_gfn(aligned);
> > +    p2m_write_lock(p2m);
> > +    res = p2m_set_entry(p2m, pv_time_gfn, regions_len / PAGE_SIZE,
> > +                        pv_time_mfn, p2m_ram_rw, p2m_access_r);
> 
> p2m_access_* are used for restricting temporarily permission by memaccess.
> So on a data abort, we will call p2m_mem_access_check() which will then
> forward the fault to the memaccess agent.
> 
> If you want to restrict permission forever, then you need to use a different
> p2m_type_t. In this case, I am guessing you want p2m_ram_ro.

Thanks for pointing that out, I'll fix this in v2.

> 
> [...]
> 
> > diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/domain.h
> > index a3487ca71303..c231c45fe40f 100644
> > --- a/xen/arch/arm/include/asm/domain.h
> > +++ b/xen/arch/arm/include/asm/domain.h
> > @@ -59,6 +59,18 @@ struct paging_domain {
> >       unsigned long p2m_total_pages;
> >   };
> > +/* Stolen time shared memory region (ARM DEN 0057A.b) */
> > +struct pv_time_region {
> > +    /* This field must be 0 as per ARM DEN 0057A.b */
> > +    uint32_t revision;
> > +
> > +    /* This field must be 0 as per ARM DEN 0057A.b */
> > +    uint32_t attribute;
> > +
> > +    /* Total stolen time in nanoseconds */
> > +    uint64_t stolen_time;
> > +} __aligned(64);
> > +
> >   struct arch_domain
> >   {
> >   #ifdef CONFIG_ARM_64
> > @@ -121,6 +133,9 @@ struct arch_domain
> >       void *tee;
> >   #endif
> > +    struct pv_time_region *pv_time_regions;
> > +    gfn_t pv_time_regions_gfn;
> 
> Given the feature is 32-bit specific, shouldn't the field be protected with
> #define CONFIG_ARM_32?

Is this typo s/32/64/? Assuming so, I'll do so (=protect them with #ifdef
CONFIG_ARM_64) in the next iteration. Thanks!

> 
> Cheers,
> 
> -- 
> Julien Grall
> 


From xen-devel-bounces@lists.xenproject.org Sat Jun 28 14:05:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jun 2025 14:05:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1028321.1402348 (Exim 4.92)
	(envelope-from )
	id 1uVWB2-0004xl-J9; Sat, 28 Jun 2025 14:05:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1028321.1402348; Sat, 28 Jun 2025 14:05: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 1uVWB2-0004xe-FW; Sat, 28 Jun 2025 14:05:08 +0000
Received: by outflank-mailman (input) for mailman id 1028321;
 Sat, 28 Jun 2025 14:05: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 1uVWB0-0004xW-JH
 for xen-devel@lists.xenproject.org; Sat, 28 Jun 2025 14:05:07 +0000
Received: from TYVP286CU001.outbound.protection.outlook.com
 (mail-japaneastazlp170110002.outbound.protection.outlook.com
 [2a01:111:f403:c405::2])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e36b58e1-5428-11f0-a310-13f23c93f187;
 Sat, 28 Jun 2025 16:05:05 +0200 (CEST)
Received: from OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:10d::7)
 by TYCP286MB3800.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:37b::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8901.13; Sat, 28 Jun
 2025 14:04:59 +0000
Received: from OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
 ([fe80::80f1:db56:4a11:3f7a]) by OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
 ([fe80::80f1:db56:4a11:3f7a%5]) with mapi id 15.20.8901.012; Sat, 28 Jun 2025
 14:04: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: e36b58e1-5428-11f0-a310-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Ja7KSw81FiaqQrHV+V+nQwoB750oRusGVlpVfHgZ0V5Dp+Utmj2J/tTiRJGp5y9VSCZS1LQGR3KmqpdpoY1PA7rz7i5V1llL6Rotg2mOV+Zn/WwSeSWSEvwP/beseuD3MvmWDPsplZFZsEI/QIxUZd11DZFiiPDapvuT02WAyDoSZgoOhOFuZ5J4I7CdYsuSezo0CETweIT0J5uMog05pusZ4mk9S/Bra6iVAvzpoVK8Swi64lKIMWcQi3WB12OUD8eXJrfGmAW4k7rlLVFRbd+Rc5Aci1+Ed/+IyQWV8RzzKzRf0My9vKdFlNHnj66ZT3qme9guRgbJuYrXHHcEnA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=UQueM2AfpMJ51YOzXPCOaQjsYe47pS0bjfj4ttYAIYA=;
 b=eJdqyJTx6esGvpJGL9ugeU+iVP+VihAPW3yVtsvqi9P0uSOqJJFlf5Q2aUM2S8gy5fnfYm0Y/uxY9HmRfVBp634UZl8zRc5o3bq4waY8+p//Bh39PvHzqs5kIvO8u162j9SeStdYvb+D7iYkhcB/o8Nsm4Ba0ZfYJYwzhwFaBN3JSlgHhbHDmzSxpjdoCeA5ken9bcaqxWg8r4CT9CG0oGbIjGtzkH6uintv+r6GwaNY1W2s3OuCdRCq7Ro5zq4dIr3EweJnTlnU1kxYuX0Ga49yWHe4ja85X21zrPa8RTvDgsqYp5aCycSZBRJQCzPsiUw3/ZtHdO+NePHog5LjmQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=valinux.co.jp; dmarc=pass action=none
 header.from=valinux.co.jp; dkim=pass header.d=valinux.co.jp; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valinux.co.jp;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=UQueM2AfpMJ51YOzXPCOaQjsYe47pS0bjfj4ttYAIYA=;
 b=CDAGTOS+yTI9C4ey6m01Yn4AcYjFHHU9SBu+ooaGHp5sutKJDYFXQEMjYW7n5dH83V0fQF0YeEYvAH2CGgVZE+n+kiiM6xv2gpZbno4LOhOA21N7cLCIsEnRyDKuB7xOEn52+L8XGA5izVviDAUkrGlif1jbnOxkSJHntCB5ckQ=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=valinux.co.jp;
Date: Sat, 28 Jun 2025 23:04:58 +0900
From: Koichiro Den 
To: "Orzel, Michal" 
Cc: xen-devel@lists.xenproject.org, 
	Stefano Stabellini , Julien Grall , 
	Bertrand Marquis , Volodymyr Babchuk 
Subject: Re: [RFC PATCH 1/4] xen/arm: Add wrapper find_unused_regions
Message-ID: 
References: <20250621151201.896719-1-den@valinux.co.jp>
 <20250621151201.896719-2-den@valinux.co.jp>
 
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-ClientProxiedBy: TYCP286CA0278.JPNP286.PROD.OUTLOOK.COM
 (2603:1096:400:3c9::19) To OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
 (2603:1096:604:10d::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: OS3P286MB0979:EE_|TYCP286MB3800:EE_
X-MS-Office365-Filtering-Correlation-Id: 8230f3f0-d2ab-4234-77fd-08ddb64cc4f8
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|10070799003|366016|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?+4bYNgpkjcjTfjQfZpYIbKaoHCL1wUXM2xkm8/AYNHBrQismvDb7NU/Gd5GX?=
 =?us-ascii?Q?dJ8EJYyCXEIrimqxFTnPzizm+X+JyZpereCWVlLx6siiuhI2+Te1e3TnvrbS?=
 =?us-ascii?Q?ipEbnjBTs8/idtELCPn1X816ihtiJ5iMFxNdQfG4ov8pnTzvxvvVzHcUCfnW?=
 =?us-ascii?Q?VhJifOoGiZEhyFITXk1l5OhVcbZ+qJMNLGmXoIeySzSa/Txm+IqEPZYerIks?=
 =?us-ascii?Q?jMcx8PDfT/v2w2ICa91L/aK3H0vWLqf0YfPJ5iB89LknIi+4BWPp+ex8MH9L?=
 =?us-ascii?Q?Buh6v1CcxddEtxs7ttbkQC/UEuGufbHhRP1PqDV0vUrNAJ25GurxVe/hGafd?=
 =?us-ascii?Q?tvRQ301VesrXhTe6aSNNEMSoAtqZsJse3PPocpwW0bzEf502jfIQephtNEKK?=
 =?us-ascii?Q?/+x6l+9AxlbGKz0bLfhqEB/BfOa2RewGg2EQtNRk98LeT1G9rzvNqSR1Vh6n?=
 =?us-ascii?Q?vKbse8jBaFhlOitVic0Nd2iJ1m3a4ycSWpVLWwlRdtFZL8LiTR9DUWADc51B?=
 =?us-ascii?Q?MPhFJcPE503qt8TifcCU2Tbj8pak0KKfb5lpkqPezbCnjgKWUxBHy4rb5pl2?=
 =?us-ascii?Q?/qmV2wPm8Pc7SGFVma8HXKmEtRGkfbi8zyGp/i2UNEygLWGuVz2HD9PxMFAz?=
 =?us-ascii?Q?e4+BgvL3y0V5kpOJJji9+WRx7j2HTWjNO2UcwllFU7RlMChhDlnZS1aLFrHJ?=
 =?us-ascii?Q?BHu7pzC6XHhgAuh0WtLoZCssgNY/GwtHbSU78ZVPHzVGTbPmt2wni9UoQPMS?=
 =?us-ascii?Q?5zjxcTuLNen16uZF9uDe2U1nNsOXKbtzP8U6xEcWVJzfMqypQbtJp/DoYyG6?=
 =?us-ascii?Q?SHu51lvMiqjtMcDg+yEE6KLtrOvJn/ng9CbyxSfvvjMxtwMt8ZBzehwToIte?=
 =?us-ascii?Q?A3M9dHYZ2LbmDgPKvbNNNkDQNom5HpzYuh2SVCtqjJYehf4e94eOfROoPRou?=
 =?us-ascii?Q?FHDA9J1gfxdtqGlT9rnnHPwvZbGW/tFDiZ8rKyWCKQ3uUr/kmzJTw7qjETZj?=
 =?us-ascii?Q?pzNZidVlwlS8yBcHuvvPPcO1wIK8BVGSSJCPLgB67qyaDelwu57SKkZJoqNj?=
 =?us-ascii?Q?Ix4imxGofDAf7X3XQnNX2HESal3ck5ByT6kyhNRPmcH2J2USSRY4a7Z95tnz?=
 =?us-ascii?Q?snSJsKeZR9F4Wn2TL+wZ3K+2nVbJjg/14EiJufcSgZSrJwldMRH0IyGyDwwu?=
 =?us-ascii?Q?ZUNBg4pAxlVPMryGogUuNe3rSUysYW31EvGfC6uPzkPchELY6rTSJ7KuAEbX?=
 =?us-ascii?Q?youNToaL6h+7Yxdad8ZxnnFfEV3QoDTS7Pnq48GXBc/A82jyGRSSnhol1Nu6?=
 =?us-ascii?Q?Vveqv774LXWzqpyMIlhjnLNoFYvk+jqutJWHoUXUqRbeETvvaRH43d6rCFvY?=
 =?us-ascii?Q?G2vTGUFGE79G9aOkDPwkzpUuXRRQSsNEYA3enSTHu9Ghnnmd0TznGxpACvgP?=
 =?us-ascii?Q?bS7Te34/h0g=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(10070799003)(366016)(1800799024)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?3yuyJl679xoQAqLAmqTnRlpki/RgT6xSLF1h9XP++Wy26i6v91XaLSK5XJmP?=
 =?us-ascii?Q?Bh8n2S8BcpTAsJgFVXmHEqg3VlK7rzANxoNDePyhADhKk8oseGsTcnHzPlFl?=
 =?us-ascii?Q?o1zWWc8tvpQpZV1GSoWU3Yit/VYJCfTME+0UM0OOl0GMD0iZZQndApPJZsxa?=
 =?us-ascii?Q?GDXZvic6HvA148Y+k6gT1a+Svtjj/6MrQKHSgjGcpL/66VqjOTPRh0bU5LRu?=
 =?us-ascii?Q?ioP/zlR2c3tw9Szdm8VthAJtx3qj+YAV0gopWdRk+bHU9+PuhPL1YYrdWb0A?=
 =?us-ascii?Q?Oi2OZdsIvVONcu+X1qCEkCAWuL6gjAYOv1CVS02LnCic2KmWcwHJ+RTZWIv4?=
 =?us-ascii?Q?PGF4M0FHNrdcj5p0jPK3ohpcX8AXO9cgNTbv7vEdfBEtbjQSZWMunYALFR4u?=
 =?us-ascii?Q?xk8nYevRKI1kJqwBCp3Ru8q96ZplEu9uehmbEm9IgsNq+6JaScBw/uz0qZM7?=
 =?us-ascii?Q?TalC/bALjrlONSwDQtzOqPAoFoQIU9InxqxAQ8pL7s+XjIx81qZiaDUarWPa?=
 =?us-ascii?Q?9FOPuhZCFSPLBz+f+pY62jGiEpNdVDJMZnAxu9ur8KhgEGn7r36jZfmOh9Ig?=
 =?us-ascii?Q?c3zJsv+ln9sgl5rXeDcBpGY9H9eKI8Owrxy5hj45nmIKv4sGVOwDZOOPw9t2?=
 =?us-ascii?Q?7OMS3CyysyIoOljK2M8qr1FMUXm+TxmxIEFxoXwM5ruM0NQ/Dr7c6waxVoCu?=
 =?us-ascii?Q?XFsHLzO6oJBsZTU6bEfKvuMjQzSCof+gHFHG/p5ASsHw04yX6AnFyUO2diU6?=
 =?us-ascii?Q?Mt8VUoj87s7QSqT8rQw0n+qHYUWTl3a47DPj1XF6LE/ymVXLGh//tejr0P6U?=
 =?us-ascii?Q?b4ATOQG0+hgyVKloAd9hkXPiQ5g/IK/Mx/yi+0lqCv9IfZLixGt8DC7SnATg?=
 =?us-ascii?Q?yyriZJ9CaXCEKBrzUMwTyqVycB+A1G4ifmsokFHL1F0+Md1S5NfmGS5sgsBd?=
 =?us-ascii?Q?Uk7e7yk5h378KdWYZRlL13s1gqcSpsURu46GfLE8xHG15xsElVXrsht8qOz+?=
 =?us-ascii?Q?7nYM8AIestsLxYQGX58lxJ/FPd/2zj0GHuZzROBXbLRixbXAhjdvLxwkvOFv?=
 =?us-ascii?Q?ByU/HLCQ9mJCcCCG7CkbzepU059LWGEzGd6SW+oeCpbRCwIf+ENocWbVVucV?=
 =?us-ascii?Q?eHMGLk6QdbELoAeOsiDDXWiIKAhXo+Yfslpyr9RIWw0mWN6GSk56sF5AIpEE?=
 =?us-ascii?Q?9BNOXS4oZgZuu/NP4/0HERcq+D1G2E7BXp/WpW9FL83fyrfIoBqrzERerGIV?=
 =?us-ascii?Q?yxjWycPQmL1OCIDETpgKDt9eM3P9i+KwiY5wBKMGnHkcGOReoKfTb5Y3BHSE?=
 =?us-ascii?Q?WTICbCCK1iUq7Kw2yjby52uI9FBuFO5PfBDQbAuFf71NYzdxtpjRsr5hcNcn?=
 =?us-ascii?Q?jjEGZbgsHWuPy84iqiujb98RmGx5P3aLZ2IkbDZqXe1FtSov7kw27PU9Wksu?=
 =?us-ascii?Q?w2vkZk5jILg9pbrG6vkQBprY7kgWx1kCC9sej8iyq6BNt1yB62dNng0+OWPV?=
 =?us-ascii?Q?DHWyvZ+1iHAyHraS1CuRSR7lCr0H9YuWzMA9jqMvHM6j2U96dW+Vp5TG1vX3?=
 =?us-ascii?Q?15fmx1Yu6NsFYUI11XTvRsQcehB07dXRWOSFRObTP4wNBOEvW39Dl0+XrKbz?=
 =?us-ascii?Q?4hrtehY7WqNbGRsTSpjl75w=3D?=
X-OriginatorOrg: valinux.co.jp
X-MS-Exchange-CrossTenant-Network-Message-Id: 8230f3f0-d2ab-4234-77fd-08ddb64cc4f8
X-MS-Exchange-CrossTenant-AuthSource: OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jun 2025 14:04:59.5873
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 7a57bee8-f73d-4c5f-a4f7-d72c91c8c111
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 5eNZdSiZ1Fp0Ky/KitquTu/wmfWUbRnJThP5Joi/T8j4b9MYGLBkZdHaliANgmTwXvw7BS/NfB3kM+OADkOCaA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYCP286MB3800

On Mon, Jun 23, 2025 at 03:33:55PM +0200, Orzel, Michal wrote:
> 

Thank you for the review + apologies for my delayed response.

> 
> On 21/06/2025 17:11, Koichiro Den wrote:
> > This is preparatory work for the upcoming commits that implement the
> > standard PV time interface (ARM DEN 0057A).
> I personally don't find such messages useful. If at all, reasoning should be
> given first and then this message could appear.

Right, I'll rewrite the commit message.

> 
> > 
> > No functional changes intended.
> > 
> > Signed-off-by: Koichiro Den 
> > ---
> >  xen/arch/arm/domain_build.c | 29 ++++++++++++++++++-----------
> >  1 file changed, 18 insertions(+), 11 deletions(-)
> > 
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index 4ff161887ec3..9d44b6fa9470 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -1070,6 +1070,23 @@ static int __init find_host_extended_regions(const struct kernel_info *kinfo,
> >      return res;
> >  }
> >  
> > +static int __init find_unused_regions(struct domain *d,
> > +                                      const struct kernel_info *kinfo,
> Let's not propagate unjustified (IMO) behavior of passing both domain and kinfo
> pointers. The latter contains the domain member and therefore is sufficient as
> argument.

Thanks for pointing that out, I'll do so in the next take.

> 
> > +                                      struct membanks *ext_regions)
> > +{
> > +    if ( domain_use_host_layout(d) )
> > +    {
> > +        if ( !is_iommu_enabled(d) )
> > +            return find_host_extended_regions(kinfo, ext_regions);
> > +        else
> > +            return find_memory_holes(kinfo, ext_regions);
> > +    }
> > +    else
> > +    {
> You can take opportunity to drop unneeded braces

Will update this part in v2. Thank you!

> 
> Otherwise, LGTM.
> 
> ~Michal
> 


From xen-devel-bounces@lists.xenproject.org Sat Jun 28 14:06:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jun 2025 14:06:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1028326.1402359 (Exim 4.92)
	(envelope-from )
	id 1uVWC2-0005T6-SO; Sat, 28 Jun 2025 14:06:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1028326.1402359; Sat, 28 Jun 2025 14:06:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uVWC2-0005Sz-OE; Sat, 28 Jun 2025 14:06:10 +0000
Received: by outflank-mailman (input) for mailman id 1028326;
 Sat, 28 Jun 2025 14:06: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 1uVWC1-0005Sr-TW
 for xen-devel@lists.xenproject.org; Sat, 28 Jun 2025 14:06:09 +0000
Received: from TYVP286CU001.outbound.protection.outlook.com
 (mail-japaneastazlp170110002.outbound.protection.outlook.com
 [2a01:111:f403:c405::2])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 094132b1-5429-11f0-a310-13f23c93f187;
 Sat, 28 Jun 2025 16:06:09 +0200 (CEST)
Received: from OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:10d::7)
 by TYCP286MB3800.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:37b::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8901.13; Sat, 28 Jun
 2025 14:06:03 +0000
Received: from OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
 ([fe80::80f1:db56:4a11:3f7a]) by OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
 ([fe80::80f1:db56:4a11:3f7a%5]) with mapi id 15.20.8901.012; Sat, 28 Jun 2025
 14:06: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: 094132b1-5429-11f0-a310-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=CgfPfaI5wsQMCW7sOXmgoPIfnMBT4i/3GEeF4o1VmDRPClrI0zhGxvNlseVaCy44eO2CaAyyBtq1u59RzUKMkrei/0J5O04Oc0BzfOOOvkH/YkiuFaTGe3RypAh+I2AiTO49VoPiZ1Puvj9XxUKaT8EGjlqpETlErC2KfBZHrVx8qZC+JPx85avHqeNpZK+cTQmjZe/zKaMP21wOWyPcxlCWTm6BaC/HPpAKmDrDvz8G577r7sV5o5t4QvHnZEkzLCi1B7L96T1B/51sS1CeyO6UMtFRSqzUJOJGmb/Z+RVGpl69CrTUreQnwbImaP0/tK2Fmia+niyH1G4datXTfg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=wvD+z2i2BZKsgAXBEBtWFa+x4cjns8adHkY3wJDThPw=;
 b=XyZrIxrYvdErOXhLSf6lCoIvQCbLsahs7wwP7Wp0WPvV8wfaMMtQcyXjuRohdpWLwnRFjRTiKhQ82vLzfC4X4FeCLMAJRTj+FNrWGL9cqUtiX6pmVZ2X4Ac11ZWNGAPDOckrHrCxjIxjkf0qLZz7L2scZ+HoOhFYe+A3e38s7SegU1Uiex+ZmTIJFAv267DRLW0H2oH30A+21pztIM0epg1gKiPezI43i3arpXWvIg5k3DDPWwtkam7eCf44lovVbVC1AkqaMc3Yklv/rqAD3fBgf3gx0V9jgHDqzzUYEqBXbe3pinil40jxYCykCdfvuBQKHJfwjpQXUjhl1+2C6g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=valinux.co.jp; dmarc=pass action=none
 header.from=valinux.co.jp; dkim=pass header.d=valinux.co.jp; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valinux.co.jp;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=wvD+z2i2BZKsgAXBEBtWFa+x4cjns8adHkY3wJDThPw=;
 b=BgRpvmMcolRPUa2tE68pH8x5IpMOqohLPwoNAUtP5ISKmgNFEwcERfHjxt8DGrbAuJUQ6gqgHoTfOJ21uePoGhVZtLzZ1rbJhizW+HXrVwoucbFN9hTji/7ldgFocJJdvDgImzy5KEfUxIElNX6pe6IgpRVLVoO9/lpzkA8kMBw=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=valinux.co.jp;
Date: Sat, 28 Jun 2025 23:06:02 +0900
From: Koichiro Den 
To: "Orzel, Michal" 
Cc: xen-devel@lists.xenproject.org, 
	Stefano Stabellini , Julien Grall , 
	Bertrand Marquis , Volodymyr Babchuk 
Subject: Re: [RFC PATCH 2/4] xen/arm: Move make_hypervisor_node()
Message-ID: 
References: <20250621151201.896719-1-den@valinux.co.jp>
 <20250621151201.896719-3-den@valinux.co.jp>
 <8e6ed078-9ab9-4f6d-91f4-cbeb74f2c5fd@amd.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8e6ed078-9ab9-4f6d-91f4-cbeb74f2c5fd@amd.com>
X-ClientProxiedBy: TYCP301CA0077.JPNP301.PROD.OUTLOOK.COM
 (2603:1096:405:7b::19) To OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
 (2603:1096:604:10d::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: OS3P286MB0979:EE_|TYCP286MB3800:EE_
X-MS-Office365-Filtering-Correlation-Id: e53de166-c4f3-4088-fefc-08ddb64ceb35
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|10070799003|366016|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?iBlL84hjIm5jEhbbPUHq+WCEHob1ZRvqVbW+XSp0YDtul4mFs+uYA4TQzmuj?=
 =?us-ascii?Q?bgsOq+qa9OfKh5CvzF1nfUOZoXXKn/unyLJBXEr5Bspwre8lcTws+WzX1KKg?=
 =?us-ascii?Q?P86SM1gq3zQnGSPm484cpTnMMJ+kQtnlJOmb4keep9PnmrJh+s0tXUkwdEQR?=
 =?us-ascii?Q?QK9zuPhGlRcukYGGmASA6m8fcwYMhL2kXcxMHnLsGW8U6T4VZGR9G6kjmxkI?=
 =?us-ascii?Q?SQlZIl08e7zXijE77tjxIVljka7jyMu/Hy6ahK+m6tzgO987TV7GuQZ4gJDf?=
 =?us-ascii?Q?b2BnctAwx6YqH9sU/3JUPHibE5N2IQqf905bQl2eC8F5T2WM0/taBJ2szrAv?=
 =?us-ascii?Q?2TQ3Ntiz15xrR0IQt5O+TrFMe1CtY9CdwApLVTlWe3IUaEtflrLc0494vws3?=
 =?us-ascii?Q?LZbXsC2vF7VpSPjXs90NycHYjWEnl3AhgNYnE8vI+fY7EyWp6CVvX8J+gkGq?=
 =?us-ascii?Q?cZ4ULL3WnD6Ap+4g7r78rLpbzZyQX+PLXOxfxwa8ko3/ZKEkLa3owEKg94Oc?=
 =?us-ascii?Q?MGomfxpQLunnyL7no+B2RqG9X2hoB7nw+ZZJT537zOMjTtDfHcOLBHaeTC2u?=
 =?us-ascii?Q?o/o1gsD4dzw8bqyJBq1tYhUld7IotjygVt0sFgRkzu25iHDaVKWC7rZG3zBg?=
 =?us-ascii?Q?fMVUATVWf63PVJm48Pp0GI5E8unahqCkzX8Gqgwr+5IGaiBUmg69u/u8mGXe?=
 =?us-ascii?Q?jr0RaNT4C8BKM3JG/bb69lO3i5bgitEws89C0F1cfpcNKU83N/4gFBx9B+Yo?=
 =?us-ascii?Q?aPO49JFzbhvp9pzLAFHySpOV8UCBDC+IPbcfG1SbwtFnUVKG1QzsEOMAlrbW?=
 =?us-ascii?Q?x74GnfD1WAnvGyhX2DGXgPf0uzrM9gBZu+En9a5jSrV5qeUjMBlXZusrfmI3?=
 =?us-ascii?Q?zE6HCNQmyMcfWbNtyyeJXhR49AMitAYhvlX76SU14wxAzfTZ9oaMmWglz8en?=
 =?us-ascii?Q?d5kD/JYkKAWuvEE0a6cvlGBpGGBxtNMfPqgXmObLl1ZA4Qa5D/QJOvwxiHZ7?=
 =?us-ascii?Q?F9aDZ8cR7TqbDMu7n7kd8joW67H0ysIn8vIbuTdPHpH+PW21e5f/YgZKwwlm?=
 =?us-ascii?Q?QrZgE28GX274X25ATzXe9iIrXvtHh3wDYSSnZZoBX8svEVL3u1sheAEToDbT?=
 =?us-ascii?Q?cfNI1ZS1cmrhrZTCY6UMA5Q7fJuA0EP6hpwKbMV/1N8VemkBsn7YdVwOsqcb?=
 =?us-ascii?Q?+AILpTPgToFMoeGBltW3UqJhyqwk24vMGxl2gM/EKxVGVar16EnD1J9fNo8P?=
 =?us-ascii?Q?y9i3ZhTH++QXZbgtly/A4AVehAp+ZzzgqhWCdF3+sa8iOOxsV/UUoZoGXiJs?=
 =?us-ascii?Q?AYmEzLSmtDtflhFvlwvlVmXSlLzPWLz6uCjsuM7itbgpIeHKZQ6+Z6aq0HVx?=
 =?us-ascii?Q?b+cRrzh89l8yJNFRwVhn7KovLYXCiOtiK2UbIQFRGbKiIBLK/B0xjDpDE5vA?=
 =?us-ascii?Q?0+iYdQMwppw=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(10070799003)(366016)(1800799024)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?bOySTVGD89JZCq+bYjhwfMfXLeXHhwfQgobRow43Hxqsfx2wO4oGYTDLvHa4?=
 =?us-ascii?Q?sP/2ia2alIg4kPUJbL8JuI/rKSewismeRgYTJeBWp3nFJX4ixLCqLBoW+Cz9?=
 =?us-ascii?Q?NMJBgP3ULKlbRqlviSWVTefznhkiAzriA4az4lxXNAIi40ca9qDormJWeb26?=
 =?us-ascii?Q?M2Mu639wL0OiJAQkuS7VlYQuT2lUGy3dq/N1tT09IC73WHdqi9hPM3xDIGLE?=
 =?us-ascii?Q?IJYEyWkn1U5LUiG/eg1TUUgS/adrmUvBAZ+SweXPJU6iR7YuXpvYGWqWcYOM?=
 =?us-ascii?Q?dnhQ2POWo6/LgbTDuEtiWWIYZi0i68HB3GrbCaWCVAY3qN+9MD8qdA3HKVTC?=
 =?us-ascii?Q?Q481B0YwV4EukSCy1FEQTeExHEr2deSZJWjourVEqUPcISSdbSCx3d2oum9o?=
 =?us-ascii?Q?dZViRvYPytZGRRZnAul7qfo0xMdAG1/xx8Xy8udCbKsQHCWeQfDKD+uO99Vl?=
 =?us-ascii?Q?gs+3P1Js3uhXWz1H76HZTLdtKn7xfGyi/uv7M+5Z/tWBJyVEpWA82/0q49Il?=
 =?us-ascii?Q?sL0gjqbSLTirmgmcE4JhYAdxzGGTcb3ZIvceoFaxl7zqpTrSZNgeKWcN9cq1?=
 =?us-ascii?Q?LdauHvSxXj39NqEVZr8Sz34QMWnufim6EGj0yr+wl+VM8MbXuU46XD8QILNq?=
 =?us-ascii?Q?0TGS8UdwczEGki+4yW80F0GvdbnnEgkPiR8tf3nsn8r157co0B4kGQIygaCU?=
 =?us-ascii?Q?3pi+oVCCAKrCspfJSjXnXulPqJQFd/OeLEm1N4afDZDfqdjDCREjyZJwsOPT?=
 =?us-ascii?Q?MrAEIChKDmmXXgPbaExMqnO3fBpHOUh1Ep9xImBwcIGVklTv+x2G3vDyhNSO?=
 =?us-ascii?Q?kEoaRlFzq6IVZfXByYqoo09lu0AXqvxVHMWQLii24dYiCTnxVQw3Jryk8z2w?=
 =?us-ascii?Q?xJIp2lxyHF0wJGWsjpqW6Ujpd4ViSYfdlM2GkL+miEO/Ijzzulbv1bRkNAxS?=
 =?us-ascii?Q?VPPjyXgYzMIHcs1fJxwqFfzQurcO9Iznh6aMJ9T0bP568aor3hjeBedrxBof?=
 =?us-ascii?Q?EiJBNEvR4TFnsSqN8LcEIs9BZqqcIbc2h5ICq0qssI9FM/g6S4o+joDw86Zc?=
 =?us-ascii?Q?v09vm3A540AbWv87Qvzv/Eztq/DKwoM4AoyVinTaPuzWl3aQaKZBI6sBotLQ?=
 =?us-ascii?Q?JNnuG5K37g48pERCTnjTQakI9imKvTrV/qPEqsEnQF/CmkBsxJCheAeyu5qX?=
 =?us-ascii?Q?ZtH8aoJSq3kExEMTs4hwyRaQNHr8vN/gFfgmriVF1gfvAFMItuYH/LCZG3aU?=
 =?us-ascii?Q?KdS7B5q4sX9ty6QoeilDf0x9vjVsydcqSj9n/k1hF0VXu7NBxMorYARNEBa1?=
 =?us-ascii?Q?xDBT2erBZAveaf/osaiQevktLueuPZgsHp7eDmwpbeUDQAFWi+2jqlWDKyOg?=
 =?us-ascii?Q?avWCW8Um0fXaP8R3MKucXojLK5lI1kp+iLiHIGYasTG9STaLRpvOkMxTWQZY?=
 =?us-ascii?Q?JCwJFhbG2chEmju/Ad5NehR1ypzZtcs/nii67ac2hlTQMKPTRGKvu54Ks8oS?=
 =?us-ascii?Q?CAfFrHxBULZvHb2imtgBzGKlVVNymiYY5ro4cP5ROvGSHzLcR8X8BqwDQvlG?=
 =?us-ascii?Q?TJw0ft+kOCLMihZlX60qcrFu3eC/x56PlwkGXxPtdTq+Wt1EDKd6Ai+PRz50?=
 =?us-ascii?Q?LNCBV/u5oFB4k8hz94ZvV/g=3D?=
X-OriginatorOrg: valinux.co.jp
X-MS-Exchange-CrossTenant-Network-Message-Id: e53de166-c4f3-4088-fefc-08ddb64ceb35
X-MS-Exchange-CrossTenant-AuthSource: OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jun 2025 14:06:03.7430
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 7a57bee8-f73d-4c5f-a4f7-d72c91c8c111
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: IhTfdnyaW7nbHoKG0ROn8KdYNi5uizetGkmjwvYlqpFI7blbMtArpM+x5c4mEOMsuyWW2kH3h57NWQATMB0p6g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYCP286MB3800

On Mon, Jun 23, 2025 at 03:40:24PM +0200, Orzel, Michal wrote:
> 
> 
> On 21/06/2025 17:11, Koichiro Den wrote:
> > Even though make_hypervisor_node() does not rely on the /reserved-memory
> > instantiation when calling find_unused_regions() (the wrapper introduced
> > in the previous commit), the next but one commit will use it for PV time
> Unless for specific reasons, you should not rely on which commit gets committed
> first. Hypothetically there could be a different patch committed between this
> and the next one in your series. That's why it's not a good practice to mention
> order of commits in the commit message.

That makes sense. I'll rewrite the commit messages in v2.
Thank you for the review.

> 
> > shared regions, in addition to the existing extended regions.
> > 
> > Move it as a prerequisite for the commit after next.
> This one is particularly not useful.
> 
> > 
> > No functional changes intended.
> > 
> > Signed-off-by: Koichiro Den 
> 
> Other than that, LGTM.
> 
> ~Michal
> 


From xen-devel-bounces@lists.xenproject.org Sat Jun 28 14:07:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jun 2025 14:07:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1028334.1402368 (Exim 4.92)
	(envelope-from )
	id 1uVWDd-00065C-C5; Sat, 28 Jun 2025 14:07:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1028334.1402368; Sat, 28 Jun 2025 14:07:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uVWDd-000655-7a; Sat, 28 Jun 2025 14:07:49 +0000
Received: by outflank-mailman (input) for mailman id 1028334;
 Sat, 28 Jun 2025 14:07: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 1uVWDb-00064m-4y
 for xen-devel@lists.xenproject.org; Sat, 28 Jun 2025 14:07:47 +0000
Received: from TYVP286CU001.outbound.protection.outlook.com
 (mail-japaneastazlp170110002.outbound.protection.outlook.com
 [2a01:111:f403:c405::2])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4333a8cb-5429-11f0-a310-13f23c93f187;
 Sat, 28 Jun 2025 16:07:46 +0200 (CEST)
Received: from OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:10d::7)
 by OS3P286MB3243.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:211::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8880.21; Sat, 28 Jun
 2025 14:07:42 +0000
Received: from OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
 ([fe80::80f1:db56:4a11:3f7a]) by OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
 ([fe80::80f1:db56:4a11:3f7a%5]) with mapi id 15.20.8901.012; Sat, 28 Jun 2025
 14:07: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: 4333a8cb-5429-11f0-a310-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=v+LTDw3qjznyyj5Cyg2Y3KT6Kvo93gY0qynawumS/EdRc479XlxCNxhSYTl8W6LGmD7jFInZx3hJA5HZub5fyaSKaz0JMyIRUQsiy0ns9YYDEmKJfbOeK2utN6ahZpHadk+LhXtdW+zTuuyb9M1iLbuNhe0TSIdZxaQjO61w4F0Hb2cxhho0S9/DElbdkHnUmSURN5Oq3cMYVGyWSejrr8tXgzQXBfn3GPAegIXjQI2hupcssjYOgNogJe1odUHXV2T/7iq4pBGuP7dOgPSRtHevepRN3tnBGV7crNz3oz+NvA5REjTxlWke7HUt0CokpDMapx282hVjTQokM/t7bw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=zgl5PQvJZ4OV4myipiXt+4l9Si8lphWW4NdCwHuCHO0=;
 b=EeZifzyc7NWnkDDZCeYd/NlK0NnhuMI6ZPcqRr39myI1KNgbY8B2+Q8bWroZ5xX1RHprUb0oLRJF1ZaDHe4avIWN05VvcMjoVU5yxn0myYJ4OK6h38pji3jzXDAlxsan5aaPq/CKDLpLZBNo5wF7M63WsK9dF/CpPN/R+pX0Zd0oiI/Hr4MOCH5n9SuwZuJeoqkTxXBP2TxGX4jDa7FsAXahyF5RxbfbRKyClMM3re+0Ei5XwYoGASwboOQnPSCRqc8Xx9fWnZtos2vAXNqz3zQaQbWt74lzVO03jocCk9qtTFNXPkdDLH8RA7jscn91mRcarocYzU47kVcnQ5FFMA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=valinux.co.jp; dmarc=pass action=none
 header.from=valinux.co.jp; dkim=pass header.d=valinux.co.jp; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valinux.co.jp;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=zgl5PQvJZ4OV4myipiXt+4l9Si8lphWW4NdCwHuCHO0=;
 b=fV9vZ5BwmjwzTiUclU6wviZUP7W+G3DTvQHZR8NwXy0V75fJy2N3t+VZumgTWpXYD4C6/cooh4w0GUWeIVOzqCQF2CPlaM4W1VGQwTOETDUtr7qM7CjAxZzjY7rgqCjd/O/kK+VSctxnTLEikLGTYr+fPGKJ/x4lgderLT8rTD0=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=valinux.co.jp;
Date: Sat, 28 Jun 2025 23:07:41 +0900
From: Koichiro Den 
To: Stefano Stabellini 
Cc: xen-devel@lists.xenproject.org, Julien Grall , 
	Bertrand Marquis , Michal Orzel , 
	Volodymyr Babchuk , Andrew Cooper , 
	Anthony PERARD , Jan Beulich , 
	Roger Pau =?utf-8?B?TW9ubsOp?= 
Subject: Re: [RFC PATCH 3/4] xen/arm: Move make_resv_memory_node()
Message-ID: 
References: <20250621151201.896719-1-den@valinux.co.jp>
 <20250621151201.896719-4-den@valinux.co.jp>
 
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
X-ClientProxiedBy: TYWPR01CA0013.jpnprd01.prod.outlook.com
 (2603:1096:400:a9::18) To OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
 (2603:1096:604:10d::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: OS3P286MB0979:EE_|OS3P286MB3243:EE_
X-MS-Office365-Filtering-Correlation-Id: 9952eb25-dc73-4bf5-9045-08ddb64d25e4
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|10070799003|1800799024|7416014|376014|366016|27256017;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?MlQwOWpFK0orZk5vM2hMbFBDZ2Z3MXo1aDRnaHVBeG00bUFpUXA1a2Fwc1FM?=
 =?utf-8?B?LzhoUDMxNldkSlpvbjZ6VW9lTmxqU0FlQjY3WnZSRVZCd1hXamUzQ1ZJaXoy?=
 =?utf-8?B?eUxCdEtKUXdIdVlxNExjeDQrTlkwOGUxbnQrLzNNREdZSFNINXFXYTUybmVh?=
 =?utf-8?B?Q2ZtWU9kcXNYL0JCUkFVN21PVXZLYzFZZ0pWUHpsM3FUa3VsdGhZUThnQTlu?=
 =?utf-8?B?eVNVRjBCVWRKdSswanVQNGd1WmJzdUo4bHRQdXo2MFVRRzhWWnFyY29lM0wz?=
 =?utf-8?B?YW9KL1B0dEZFeDJYQ1hGQWl4ZHBZU0JNL1RsWXBKRFBibm1uWUxrdWsydGlh?=
 =?utf-8?B?aEhTRFdGMUcrai91UjRVVHpVZnd1RUpVbUVZQkVuQVRoSFRUMVZSTndVd1pz?=
 =?utf-8?B?UzBkWjFqTTk2bUw5VU1yYVkwTk9OS3hVSVZjc0o4M3NWK3VsdDlJck9tS2s0?=
 =?utf-8?B?VHByS2pIZzF3aWp0eWxjT3JPVkQ4S1U3QjRvd2NscjNyWDYxTHVDSno0VmN6?=
 =?utf-8?B?NzJNTFNZS2ZJcDhMRXEwSDI2MjNRTUZtSWdwYk9BN0Fsd0RGTjFoMitSbTRO?=
 =?utf-8?B?SlJRK2xpcGdZOU1Mc09scys3Y1ZVNTVsbHREZzlNSENXSVNiSmV6UGpjTkp4?=
 =?utf-8?B?Q28yNWFucmlXcHVWRlQ3bXJFZ1g3THlTK0VrZ3RLbEplOUMxa1FMbUtDYWV0?=
 =?utf-8?B?RTd1bS90YVJSQUFUVDNqcmJkQUwwZlBWcHRISzgyWEtPTjRPS0MrU0taay90?=
 =?utf-8?B?S1I1SXEwWVFaaFRPcGV0bFpsUzVPZUZuN2R1YlhYc2VWWEsvYmRzSXd2MXBn?=
 =?utf-8?B?ekU5UnQrajNwSUlIMHIzRmhSaTlaZm1mRWo4em9PdWlwcUlqcVNsRnBzUzdS?=
 =?utf-8?B?L1pLZE1QZnVnRnU3Z0dCNHMyREdWZUl2YXYycW84NEhJaDk3blhjWUhIVyti?=
 =?utf-8?B?MzUyTzZGM3UwNG80aGFVZ0o4aGNYSGJDT3pjdE1sTXBNMlJlRHM0TExOQUp6?=
 =?utf-8?B?ZlFhalV2RG4rSXlnQWkwbms5ZW05U2U3eGVyZ1dkSnZkOFN4ZGZHZmhzTWdm?=
 =?utf-8?B?bi9ZejNxVzQrekJvK2U3WWE3RXZnQ1ZrQ2pIYWthU3hZaGFvV1NXQjNRQ2dW?=
 =?utf-8?B?ZFpQQzJxM0VMbmpGMVZ4KzZjQ1ZlbGwzRVpacmE4TDdUSk5PWGc2emZOMVpW?=
 =?utf-8?B?ZUFtSTR5NWt2a295K2tDZUw3d29rV2FiTkdjamc0cFlJazV1WjBDdktOWVFC?=
 =?utf-8?B?RzRMdTBxajNJYThWWVRrcE9JVW4zNExBVStSMmxSNDlqaENhMmF2Qkc0QWhQ?=
 =?utf-8?B?ZWIrRC9JN3VUMERoOTVnWUkyMnIwSWJoclhpQ3NLYjFKVTA0eitEV09HbXh4?=
 =?utf-8?B?WWtZSjFrU0RNNFhFRDZzYU5kZUhXbU96dG42bUZFMGdxWVVlOWM4emhKcHdq?=
 =?utf-8?B?N2lPR0NCUnpVaFJjaUJqblRZdlU0Zk9UaXE1bEFHb1BzNjJ3UWI0ci9CaTNL?=
 =?utf-8?B?bmJoeXdveE93SVdQbDZVN3dOYzdkMHI1UHBsNXh4Wi9MZFhYNityRElWcVll?=
 =?utf-8?B?S1hQY1AzMDVnMDBhZFBGQ3pCaUU1ZDMyWGZSRU1nak5KczRNOXkvTEN3Tk4z?=
 =?utf-8?B?eG1ac2QweGZwR3AySVNydFNTV1FxVmRpZER4aisvZlF1UlEwdG94T0VXT0V4?=
 =?utf-8?B?VlNwNnpZS2ZJc29NV2NQZXQxa2U4VnNYeUxEWHZ4V2hKaGZidlVCQjR1Qkxt?=
 =?utf-8?B?MGRkUWJMcTZHMFU5UUlrT3FHZm81Q280azd2TSt3Y0JYMzU1d1B0c0U0em1j?=
 =?utf-8?B?TS9lZjBFUk5tcmx4aWtoUjZuYlkvZHNPc1VOYjNrVnQ4eTV6LzhEN3luYXln?=
 =?utf-8?B?QXVENGtDUXZQVzF2RkZEQmJGMWdtS1d2NGdPRlpOZ0NhMm5TcSsvb0swVHM4?=
 =?utf-8?B?ZzBkR3E1T2dFaDRVVE1rRGJMVHVXeEdTTWVqWExpVFN5Mng0VUxEZzIwZWxu?=
 =?utf-8?B?Y1lIK2JyVDhBPT0=?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(10070799003)(1800799024)(7416014)(376014)(366016)(27256017);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?b1hZeW5HQkV3QlVTVHdwc0lMb0x5MlRaaDNnYnJtKzB4TlQxN2tQNElkUnVl?=
 =?utf-8?B?Rm5xN3pJZzR4VHNMWFFyRzNFRXAvWk0vVEhRT0VlZlhnaHBVdi9yOE5Ldk5V?=
 =?utf-8?B?SmE4b3V0K2VFd08vOGl4YmtMZVp4K1gxM0dMNTlVV1pzTDBsVnRHU1NmdEUy?=
 =?utf-8?B?QXd5Qkt2d1NRUnJDQnA2VVJ4algwaWQ5ZzdsanUzc3N0ZjdXaW5EV1BCL1dZ?=
 =?utf-8?B?OHRPSENPSWFudDFvZnFZa2RBQ20xSnc0VEJHWGFEL01iVHNyYnltaW1SclR0?=
 =?utf-8?B?MVRWTFUwU0FMWS9ZclFYcUtqYWprSkpFTXZqclRQV0hzMVQ3UFFsdE9VRm52?=
 =?utf-8?B?VDVWY3EvczlHWVovRW9oZ1JOSDVHMzdvcG1HVThFMElKdkU4Mmp5MjlmZlVm?=
 =?utf-8?B?Vkdnby9VZi9QaDBXMktDZnMwVFVLc1QwT2t0cmUxOHpIelZPZXQ5alhtdjdh?=
 =?utf-8?B?RnBGMC9wOWM2QThlTHBPMHRJR01CZUNvUXRIU3NTTCtyZElKRVNWQzJHQ0pV?=
 =?utf-8?B?UEZ4NXBFd3VETWlOSHBRT3E3ZmJhczZIVFZTTzdrVE95M1U3bjJsVHN2Qkxj?=
 =?utf-8?B?WFYxV3ZXWkFKM2NDUnVKOHFXUThWVzRiK0FsM0ZRVVRlVW5OOTV2RHk3bWdS?=
 =?utf-8?B?YTZpaDFzNFovWU9hR3pzdTl6eDdoZkxxU2FnMERkUzJ3WXFHY2UxUGVQUDBl?=
 =?utf-8?B?MmI4NkNUQ24zdS9VOVdHd3lxZFRZVTgxdVdjUDJqTlFqQ3hHNEc0OE1XSk44?=
 =?utf-8?B?anFXZUlDVXVVam9mOVpuUFB1UDh2UmM0SFVnbHNoZ0pHZnRyYlVuTVkrRzFw?=
 =?utf-8?B?aUxCRGlFUEtWN0pmU2xvbEFTekd5OU9lOHo1a3AxTjF6T3I4aFVPb0ZYUlVu?=
 =?utf-8?B?NHAxSjlxT1dsektCQytOaGZ0WWh2alczejQ3UUgwaUNOK21Xdk9TbVQzalQx?=
 =?utf-8?B?MWtQMThFSVNGSXBYRGFTanVESFFjV3NtOUU3TGRzMnZJL29qS1B5K2hld3ZY?=
 =?utf-8?B?K2JMTHNGbnptUGhrM3NXbnVtN3N1WXJMSkJxYjJULzJ1MmVYT1ViNUVvZ3lt?=
 =?utf-8?B?ZWdhM2duNnNzaU9jQVRJYWxMb0dQOHp3UW5kRWE3WlBITmUvbVpUa3ZQSHBF?=
 =?utf-8?B?a2tvRXV4Q3ZmSUNwRGlsRHg0U3RyVHBRdzAwVWk0SVVaSzJmMVVmSExkbkQ3?=
 =?utf-8?B?VlIwbUl1NmdCR2NsbmE0WGZ1UWtUSDEyUy8ybUl1Sm1FRDRIZngxS1IrYlNY?=
 =?utf-8?B?ZTNkekY3dTVjbjNmOVdTQVZOeHpTZW1Lc0pRb3o0V0ZWZzBoeTlpMVh5K1pr?=
 =?utf-8?B?V2diYUQ4cnhVMGpPUzhqalJmbkViWnRaZHpMUFpkRHA0VXd6dnpOSjg1ZG03?=
 =?utf-8?B?OGlwRVVOZWNGUnhOdUFUbm9NbWdFZy9WVmFWZUpLYWhOM1B6NDU5YzUwUGJh?=
 =?utf-8?B?U002dFJxcW5ESEVmNEJBTTY4OTJTUHRyYVNOcUxHaHZmQkg5cFRhRUo3T0tv?=
 =?utf-8?B?dXZ1Snk4SjB5TWFKVWpqWHVTMnBycFRxa082Sm5Wb0Y2T2YxUnJQSEozazJs?=
 =?utf-8?B?a0loV2Y0TXdpU2hwRURGUjkwU0tOUDJueFMzb01UYmFvWXo2WEhibFFXV0Yz?=
 =?utf-8?B?WWc4L3VuR0NvRDhoSDRYM2lBUUJmQzBiK29pQUtUSFJKSzRKTmtMZUhHMXpr?=
 =?utf-8?B?SkxaTVBBRS9NMVdKVmt5STF0TjJKLzRrVjcvRGF5S3ZwRmhjUW1uV1d0dVBW?=
 =?utf-8?B?Q0svejVkaGpST1ROTUp2Yi9HV01CL0wzYllQWTFRRzBhWldQM1Q0SVg0anlY?=
 =?utf-8?B?WEFXZUcrbjFtQ0pFVUdNNTl3QlhKVVFPZmR5Uk5QWXBlTjNoaXAzZVY0ODZ4?=
 =?utf-8?B?T0NsdDBYbld6SHRQRDdtd1k2TExQWXlIdjRPUEpWeENhTDFTbmVrcUErMlli?=
 =?utf-8?B?UVEwV0ZyZDkyWXRYNlFmdGlvT1Z2b3BJZEVyZkFwRlVNNHQ2aVVXZXQ3ZUVL?=
 =?utf-8?B?UHZZS0t1b2Q4SDFrbVA5cDlPZVdrTUNodFJMM1dOMTBQLzdhd2RPd0JvYk91?=
 =?utf-8?B?b2RmM1l1VU1mNUw3R2hHSlgwc0s4VTBPN0pYUXJKUndURHM4WDBTam5scUQz?=
 =?utf-8?B?Q081azNqR2VYUmM4YnM3MkxteGdiY1BDT0ZmcE1jbVp3V1lGNDB3eTZWWnlU?=
 =?utf-8?Q?9B5wlNRb7EIgqD3VC0ylMyE=3D?=
X-OriginatorOrg: valinux.co.jp
X-MS-Exchange-CrossTenant-Network-Message-Id: 9952eb25-dc73-4bf5-9045-08ddb64d25e4
X-MS-Exchange-CrossTenant-AuthSource: OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jun 2025 14:07:42.1876
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 7a57bee8-f73d-4c5f-a4f7-d72c91c8c111
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: jYQ4euY2BLMzBcwKRlp1XU83TKzHHXgNJtILj6kczdGxp1ILAiC4kzsdlF7nJnbJFgN4rDefpD2gEKWAvkPOzQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS3P286MB3243

On Sun, Jun 22, 2025 at 04:12:15PM -0700, Stefano Stabellini wrote:
> On Sun, 22 Jun 2025, Koichiro Den wrote:
> > The /reserved-memory node is inherently not specific to static-shmem. In
> > the next commit, child nodes will be added under /reserved-memory for
> > the stolen time shared memory regions.
> > 
> > No functional changes intended.
> > 
> > Signed-off-by: Koichiro Den 
> 
> This causes a build failure when CONFIG_STATIC_SHM is missing.
> 
> arch/arm/domain_build.c: In function ‘make_resv_memory_node’:
> arch/arm/domain_build.c:1567:34: error: implicit declaration of function ‘kernel_info_get_shm_mem_const’; did you mean ‘kernel_info_get_mem_const’? [-Werror=implicit-function-declaration]
>  1567 |     const struct membanks *mem = kernel_info_get_shm_mem_const(kinfo);
>       |                                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>       |                                  kernel_info_get_mem_const
> arch/arm/domain_build.c:1567:34: error: nested extern declaration of ‘kernel_info_get_shm_mem_const’ [-Werror=nested-externs]
> arch/arm/domain_build.c:1567:34: error: initialization of ‘const struct membanks *’ from ‘int’ makes pointer from integer without a cast [-Werror=int-conversion]

Thank you for pointing that out, I'll address this in v2.
> 
---(snip)---



From xen-devel-bounces@lists.xenproject.org Sat Jun 28 17:26:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jun 2025 17:26:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1028390.1402377 (Exim 4.92)
	(envelope-from )
	id 1uVZJu-0004DM-Jt; Sat, 28 Jun 2025 17:26:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1028390.1402377; Sat, 28 Jun 2025 17: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 1uVZJu-0004DF-HD; Sat, 28 Jun 2025 17:26:30 +0000
Received: by outflank-mailman (input) for mailman id 1028390;
 Sat, 28 Jun 2025 17:26:29 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uVZJt-0004D4-1k
 for xen-devel@lists.xenproject.org; Sat, 28 Jun 2025 17:26:29 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uVZJf-0072fM-2l;
 Sat, 28 Jun 2025 17:26:15 +0000
Received: from [2a02:8012:3a1:0:d050:4cf0:af44:4b0]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uVZJf-002tUr-1X;
 Sat, 28 Jun 2025 17: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=ZzJJE6gQ3Zauq+OPNw6A0M1Le3qFdUevYHuIouIp+Ys=; b=o0uWu53NLieNso/eTpYwu7+3Ac
	rlFarHLik6FKFvwA6AaAl/JlxULSpsGCRggtyC6UINfn+0E2UN1EZKgmUHY7YgXgdrih2Y+jDTQqh
	FC1AF0elFg4zO4XVJ4HyuQTxW9xrlHfEdj/GxNn7Qm0bCtKW5bE0cMJGBy8A5vo2Lz/M=;
Message-ID: 
Date: Sat, 28 Jun 2025 18:26:12 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/2] xen/console: unify printout behavior for UART
 emulators
Content-Language: en-GB
To: Stefano Stabellini ,
 Jan Beulich 
Cc: dmkhn@proton.me, andrew.cooper3@citrix.com, anthony.perard@vates.tech,
 michal.orzel@amd.com, roger.pau@citrix.com, dmukhin@ford.com,
 xen-devel@lists.xenproject.org
References: <20250606201102.2414022-1-dmukhin@ford.com>
 <20250606201102.2414022-3-dmukhin@ford.com>
  
 
 
 
 
 <2f726960-4bdc-4996-b204-722c0253e2ab@suse.com>
 
 <15db8155-3d3d-41e9-92be-957067a34e5f@suse.com>
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Stefano,

On 21/06/2025 01:52, Stefano Stabellini wrote:
>> Widely used or not - _I_ use it all the time in debug configs where serial
>> is available.
> 
> Fair enough and your usage is really important for the project. At the
> same time you know exactly what's going on so you wouldn't be confused
> by the presence or absence of a (d0) prefix.
> 
> The main issue is when less familiar users try Xen, or less familiar
> developers go through the Xen source code to learn from it.
> 
> I would optimize this choice to make it simpler for users and to make
> the code simpler. Your use-case is really important as well, but I would
> trust you to understand what's going on either way, with or without the
> (d0) prefix.

Thanks for the clarification. I gave a try with and without the series 
to understand a bit more the difference. I think there are some 
imbalance in that setup because when the focus is on Xen, the logs are 
still prefixed with "(XEN)". So naturally the log with no prefix are the 
one for Dom0. So I have to agree with Jan here.

I haven't tried the behavior with dom0less. So I am not sure what would 
happen if the focus switch to Xen.

Also, when switching focus, I have noticed a very odd behavior with this 
patch. "(d0)" is printed multiple time per line:

"
(d0) [    1.344020] v(d0) gaarb: loaded
(d0) [    1.352808] c(d0) locksource: Swit(d0) ched to clocksou(d0) rce 
arch_sys_cou(d0) nter
(d0) [    1.367604] V(d0) FS: Disk quotas (d0) dquot_6.6.0
(d0) [    1.369369] V(d0) FS: Dquot-cache (d0) hash table entri(d0) es: 
512 (order 0(d0) , 4096 bytes)
(d0) [    1.376766] p(d0) np: PnP ACPI: di(d0) sabled
(d0) [    1.619730] N(d0) ET: Registered P(d0) F_INET protocol (d0) family
(d0) [    1.623635] I(d0) P idents hash ta(d0) ble entries: 163(d0) 84 
(order: 5, 13(d0) 1072 bytes, line(d0) ar)
(d0) [    1.636915] t(d0) cp_listen_portad(d0) dr_hash hash tab(d0) le 
entries: 512 (d0) (order: 3, 36864(d0)  bytes, linear)
(d0) [    1.638331] T(d0) able-perturb has(d0) h table entries:(d0) 
65536 (order: 6(d0) , 262144 bytes, (d0) linear)
(d0) [    1.639267] T(d0) CP established h(d0) ash table entrie(d0) s: 
8192 (order: (d0) 4, 65536 bytes, (d0) linear)
(d0) [    1.643457] T(d0) CP bind hash tab(d0) le entries: 8192(d0) 
(order: 8, 1179(d0) 648 bytes, linea(d0) r)
(d0) [    1.652078] T(d0) CP: Hash tables (d0) configured (esta(d0) 
blished 8192 bin(d0) d 8192)
(d0) [    1.655824] U(d0) DP hash table en(d0) tries: 512 (orde(d0) r: 
4, 81920 byte(d0) s, linear)
(d0) [    1.657807] U(d0) DP-Lite hash tab(d0) le entries: 512 (d0) 
(order: 4, 81920(d0)  bytes, linear)
(d0) [    1.661993] N(d0) ET: Registered P(d0) F_UNIX/PF_LOCAL (d0) 
protocol family
(d0) [    1.674980] R(d0) PC: Registered n(d0) amed UNIX socket(d0) 
transport modul(d0) e.
(d0) [    1.676034] R(d0) PC: Registered u(d0) dp transport mod(d0) ule.
(d0) [    1.677241] R(d0) PC: Registered t(d0) cp transport mod(d0) ule.
(d0) [    1.677964] R(d0) PC: Registered t(d0) cp-with-tls tran(d0) 
sport module.
(d0) [    1.678615] R(d0) PC: Registered t(d0) cp NFSv4.1 backc(d0) 
hannel transport(d0)  module.
"

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Sat Jun 28 17:28:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jun 2025 17:28:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1028396.1402387 (Exim 4.92)
	(envelope-from )
	id 1uVZLm-0004iL-Vd; Sat, 28 Jun 2025 17:28:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1028396.1402387; Sat, 28 Jun 2025 17: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 1uVZLm-0004iE-Sn; Sat, 28 Jun 2025 17:28:26 +0000
Received: by outflank-mailman (input) for mailman id 1028396;
 Sat, 28 Jun 2025 17:28:25 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uVZLl-0004i4-83
 for xen-devel@lists.xenproject.org; Sat, 28 Jun 2025 17:28:25 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uVZLc-0072gw-09;
 Sat, 28 Jun 2025 17:28:16 +0000
Received: from [2a02:8012:3a1:0:d050:4cf0:af44:4b0]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uVZLb-002tld-2e;
 Sat, 28 Jun 2025 17:28: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:
	References:Cc:To:From:Subject:MIME-Version:Date:Message-ID;
	bh=2v59vgr2YIpf81nIPfJll7O0maQkR3BOiTVV5F60cOk=; b=rkND4eX1ptjppY7x40cbEWfr9s
	D9/9sdzgOZwD9N8g/ukjlpk6U3nXbhIoojLSFQdylmPriRkS9u2e7JGtqzmuKCVAEW9lE9WURDZ49
	MW6BCrhuvaYBjfRDefTPegNiNzyOSlyqi/iVUH9MoYF/QIlgb0yh4ZIt8dVHLAVYMk7U=;
Message-ID: <5169c4ff-5cf2-4130-aa3d-facc1ca94bc5@xen.org>
Date: Sat, 28 Jun 2025 18:28:12 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/2] xen/console: unify printout behavior for UART
 emulators
Content-Language: en-GB
From: Julien Grall 
To: Stefano Stabellini ,
 Jan Beulich 
Cc: dmkhn@proton.me, andrew.cooper3@citrix.com, anthony.perard@vates.tech,
 michal.orzel@amd.com, roger.pau@citrix.com, dmukhin@ford.com,
 xen-devel@lists.xenproject.org
References: <20250606201102.2414022-1-dmukhin@ford.com>
 <20250606201102.2414022-3-dmukhin@ford.com>
  
 
 
 
 
 <2f726960-4bdc-4996-b204-722c0253e2ab@suse.com>
 
 <15db8155-3d3d-41e9-92be-957067a34e5f@suse.com>
 
 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 28/06/2025 18:26, Julien Grall wrote:
> Hi Stefano,
> 
> On 21/06/2025 01:52, Stefano Stabellini wrote:
>>> Widely used or not - _I_ use it all the time in debug configs where 
>>> serial
>>> is available.
>>
>> Fair enough and your usage is really important for the project. At the
>> same time you know exactly what's going on so you wouldn't be confused
>> by the presence or absence of a (d0) prefix.
>>
>> The main issue is when less familiar users try Xen, or less familiar
>> developers go through the Xen source code to learn from it.
>>
>> I would optimize this choice to make it simpler for users and to make
>> the code simpler. Your use-case is really important as well, but I would
>> trust you to understand what's going on either way, with or without the
>> (d0) prefix.
> 
> Thanks for the clarification. I gave a try with and without the series 
> to understand a bit more the difference. I think there are some 
> imbalance in that setup because when the focus is on Xen, the logs are 
> still prefixed with "(XEN)". So naturally the log with no prefix are the 
> one for Dom0. So I have to agree with Jan here.

I forgot to clarify, this is not an ask to remove (XEN) when the focus 
is on Xen. This is more we should keep the existing behavior.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Sat Jun 28 17:36:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jun 2025 17:36:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1028411.1402398 (Exim 4.92)
	(envelope-from )
	id 1uVZTE-0006Mt-Kd; Sat, 28 Jun 2025 17:36:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1028411.1402398; Sat, 28 Jun 2025 17:36: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 1uVZTE-0006Mm-HB; Sat, 28 Jun 2025 17:36:08 +0000
Received: by outflank-mailman (input) for mailman id 1028411;
 Sat, 28 Jun 2025 17:36:07 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uVZTD-0006Mg-D8
 for xen-devel@lists.xenproject.org; Sat, 28 Jun 2025 17:36:07 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uVZTC-0072r0-0N;
 Sat, 28 Jun 2025 17:36:06 +0000
Received: from [2a02:8012:3a1:0:d050:4cf0:af44:4b0]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uVZTB-002uqE-2z;
 Sat, 28 Jun 2025 17:36:06 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=ByFeS0RkIpsb7AF6Lw9JEwuiFql4pCQgpK/XJxQc1T0=; b=cdpoR4DR1CV8lqVZUrTLViduJK
	IXeuWV6EXfPFm6XaNA/q8KpeVpUvCeIWj1i+hhq/D1JDW0UuhaVCgGLqN1l0EX05WJIrwcy1Qt4Kg
	UFS0QIMfK8wVlLfx+WLq3daYjsgXjbof5TzepcOc4w80tmXrE0r/xtCNnxiEUDpEBBWs=;
Message-ID: 
Date: Sat, 28 Jun 2025 18:36:02 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH 4/4] xen/arm: Implement standard PV time interface as
 per ARM DEN 0057A
Content-Language: en-GB
To: Koichiro Den 
Cc: xen-devel@lists.xenproject.org,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20250621151201.896719-1-den@valinux.co.jp>
 <20250621151201.896719-5-den@valinux.co.jp>
 <21cbc79b-2209-42ef-8085-81c41e8e697b@xen.org>
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

On 28/06/2025 14:58, Koichiro Den wrote:
> On Mon, Jun 23, 2025 at 09:41:47AM +0100, Julien Grall wrote:
> ---(snip)---
>>> @@ -707,6 +723,7 @@ int arch_domain_create(struct domain *d,
>>>                           unsigned int flags)
>>>    {
>>>        unsigned int count = 0;
>>> +    int order;
>>>        int rc;
>>>        BUILD_BUG_ON(GUEST_MAX_VCPUS < MAX_VIRT_CPUS);
>>> @@ -791,6 +808,19 @@ int arch_domain_create(struct domain *d,
>>>        d->arch.sve_vl = config->arch.sve_vl;
>>>    #endif
>>> +    /*
>>> +     * Preallocate the stolen time shared memory regions for all the
>>> +     * possible vCPUs.
>>> +     */
>>> +    order = get_order_from_bytes(d->max_vcpus * sizeof(struct pv_time_region));
>>
>> As this is an order, we could end up to waste memory fairly quickly. So we
>> should try to free the unused pages from the order. That said, the maximum
>> number of virtual CPUs we currently support is 128. If I am not mistaken,
>> this could fit in 2 4KB pages. So I would also be ok with a
>> BUILD_BUG_ON(MAX_VIRT_CPUS <= 128) and we defer this work.
> 
> I'll go with the former in the next iteration. Thanks!
> 
>>
>>> +    d->arch.pv_time_regions_gfn = INVALID_GFN;
>>
>> Does this mean PV time is optional? If so, shouldn't we allocate the memory
>> conditionally?
>>
>> Also, looking at the code below, you seem to cater domains created via
>> dom0less but not from the toolstack. I think both should be supported for
>> the PV time.
> 
> Yes, that was intentional. I should've mentioned that this RFC series only
> caters the dom0less case. For domains created dynamically via xl create, the
> only viable solution I've found so far is to reserve PFN range(s) large enough
> to cover the maximum possible number of toolstack-created domains on boot,
> which I think would be too wasteful.

AFAICT, with current MAX_VIRT_CPUS (128), we would only need to reserve 
8KB in the guest address space. We still have plenty of space that we 
can afford reserve 8KB (the layout is described in 
xen/include/public/arch-arm.h). I would suggest to allocate the region 
just before the grant-table (see GUEST_GNTTAB_BASE).

> In any case, I agree that conditional allocation would be preferable.

For XL, I would suggest to introduce a field flags in 
xen_arch_domainconfig and use one bit for enabling the PV time 
interface. The other bits would be reserved for the future (so we would 
need to check they are zeroes). You can have a look how "flags" in 
xen_domctl_createdomain is handled.

[...]

>>> diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/domain.h
>>> index a3487ca71303..c231c45fe40f 100644
>>> --- a/xen/arch/arm/include/asm/domain.h
>>> +++ b/xen/arch/arm/include/asm/domain.h
>>> @@ -59,6 +59,18 @@ struct paging_domain {
>>>        unsigned long p2m_total_pages;
>>>    };
>>> +/* Stolen time shared memory region (ARM DEN 0057A.b) */
>>> +struct pv_time_region {
>>> +    /* This field must be 0 as per ARM DEN 0057A.b */
>>> +    uint32_t revision;
>>> +
>>> +    /* This field must be 0 as per ARM DEN 0057A.b */
>>> +    uint32_t attribute;
>>> +
>>> +    /* Total stolen time in nanoseconds */
>>> +    uint64_t stolen_time;
>>> +} __aligned(64);
>>> +
>>>    struct arch_domain
>>>    {
>>>    #ifdef CONFIG_ARM_64
>>> @@ -121,6 +133,9 @@ struct arch_domain
>>>        void *tee;
>>>    #endif
>>> +    struct pv_time_region *pv_time_regions;
>>> +    gfn_t pv_time_regions_gfn;
>>
>> Given the feature is 32-bit specific, shouldn't the field be protected with
>> #define CONFIG_ARM_32?
> 
> Is this typo s/32/64/? Assuming so, I'll do so (=protect them with #ifdef
> CONFIG_ARM_64) in the next iteration. Thanks!

Yes this is a typo.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Sat Jun 28 18:17:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jun 2025 18:17:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1028420.1402408 (Exim 4.92)
	(envelope-from )
	id 1uVa7A-0003At-KM; Sat, 28 Jun 2025 18:17:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1028420.1402408; Sat, 28 Jun 2025 18:17:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uVa7A-0003Am-HE; Sat, 28 Jun 2025 18:17:24 +0000
Received: by outflank-mailman (input) for mailman id 1028420;
 Sat, 28 Jun 2025 18:17:24 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uVa7A-0003Ag-2F
 for xen-devel@lists.xenproject.org; Sat, 28 Jun 2025 18:17:24 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uVa79-0073gT-1N;
 Sat, 28 Jun 2025 18:17:23 +0000
Received: from [2a02:8012:3a1:0:d050:4cf0:af44:4b0]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uVa79-0030pm-0L;
 Sat, 28 Jun 2025 18:17: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" 
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=jWXvREPJzPiKcGAiZdfLXeOSpatiJXJjdiIvtx+V4nQ=; b=yA9fvCh9Vuzvv58BQmPpv80SPM
	MAZ3iFIWn6uhB4j5g6QYEva/faI4pnFjXITduoy5QUZJUhQf+mUWlg8BO7rSMvcR3XBRebxSZnuJm
	TsULvpisaPBNmH+94XmToSvTUmOa2hajvU/nlViOBNc97wsIQLSV7v6Rfa0+hqticd0s=;
Message-ID: <066c6e93-a478-4c8f-b161-d109bd0e6bb4@xen.org>
Date: Sat, 28 Jun 2025 19:17:19 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 1/4] xen/arm: Implement PSCI SYSTEM_SUSPEND call for
 guests
Content-Language: en-GB
To: Mykola Kvach , xen-devel@lists.xenproject.org
Cc: Mykola Kvach ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Juergen Gross 
References: 
 <072270e0940b6bcc2743d56a336363f4719ba60a.1751020456.git.mykola_kvach@epam.com>
From: Julien Grall 
In-Reply-To: <072270e0940b6bcc2743d56a336363f4719ba60a.1751020456.git.mykola_kvach@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Mykola,

On 27/06/2025 11:51, Mykola Kvach wrote:
> diff --git a/xen/arch/arm/include/asm/perfc_defn.h b/xen/arch/arm/include/asm/perfc_defn.h
> index effd25b69e..8dfcac7e3b 100644
> --- a/xen/arch/arm/include/asm/perfc_defn.h
> +++ b/xen/arch/arm/include/asm/perfc_defn.h
> @@ -33,6 +33,7 @@ PERFCOUNTER(vpsci_system_reset,        "vpsci: system_reset")
>   PERFCOUNTER(vpsci_cpu_suspend,         "vpsci: cpu_suspend")
>   PERFCOUNTER(vpsci_cpu_affinity_info,   "vpsci: cpu_affinity_info")
>   PERFCOUNTER(vpsci_features,            "vpsci: features")
> +PERFCOUNTER(vpsci_system_suspend,      "vpsci: system_suspend")
>   
>   PERFCOUNTER(vcpu_kick,                 "vcpu: notify other vcpu")
>   
> diff --git a/xen/arch/arm/include/asm/psci.h b/xen/arch/arm/include/asm/psci.h
> index 4780972621..48a93e6b79 100644
> --- a/xen/arch/arm/include/asm/psci.h
> +++ b/xen/arch/arm/include/asm/psci.h
> @@ -47,10 +47,12 @@ void call_psci_system_reset(void);
>   #define PSCI_0_2_FN32_SYSTEM_OFF          PSCI_0_2_FN32(8)
>   #define PSCI_0_2_FN32_SYSTEM_RESET        PSCI_0_2_FN32(9)
>   #define PSCI_1_0_FN32_PSCI_FEATURES       PSCI_0_2_FN32(10)
> +#define PSCI_1_0_FN32_SYSTEM_SUSPEND      PSCI_0_2_FN32(14)
>   
>   #define PSCI_0_2_FN64_CPU_SUSPEND         PSCI_0_2_FN64(1)
>   #define PSCI_0_2_FN64_CPU_ON              PSCI_0_2_FN64(3)
>   #define PSCI_0_2_FN64_AFFINITY_INFO       PSCI_0_2_FN64(4)
> +#define PSCI_1_0_FN64_SYSTEM_SUSPEND      PSCI_0_2_FN64(14)
>   
>   /* PSCI v0.2 affinity level state returned by AFFINITY_INFO */
>   #define PSCI_0_2_AFFINITY_LEVEL_ON      0
> diff --git a/xen/arch/arm/include/asm/vpsci.h b/xen/arch/arm/include/asm/vpsci.h
> index 0cca5e6830..69d40f9d7f 100644
> --- a/xen/arch/arm/include/asm/vpsci.h
> +++ b/xen/arch/arm/include/asm/vpsci.h
> @@ -23,7 +23,7 @@
>   #include 
>   
>   /* Number of function implemented by virtual PSCI (only 0.2 or later) */
> -#define VPSCI_NR_FUNCS  12
> +#define VPSCI_NR_FUNCS  14
>   
>   /* Functions handle PSCI calls from the guests */
>   bool do_vpsci_0_1_call(struct cpu_user_regs *regs, uint32_t fid);
> diff --git a/xen/arch/arm/mmu/p2m.c b/xen/arch/arm/mmu/p2m.c
> index 67296dabb5..f9c09a49e2 100644
> --- a/xen/arch/arm/mmu/p2m.c
> +++ b/xen/arch/arm/mmu/p2m.c
> @@ -6,6 +6,8 @@
>   #include 
>   #include 
>   
> +#include 
> +
>   #include 
>   #include 
>   #include 
> @@ -198,7 +200,9 @@ void dump_p2m_lookup(struct domain *d, paddr_t addr)
>    */
>   void p2m_save_state(struct vcpu *p)
>   {
> -    p->arch.sctlr = READ_SYSREG(SCTLR_EL1);
> +    if ( !(p->domain->is_shutting_down &&
> +           p->domain->shutdown_code == SHUTDOWN_suspend) )

This is definitely not obvious why you need to change p2m_save_state(). 
AFAIU, you are doing this because when suspending the system, you will 
overwrite p->arch.sctlr. However, this is super fragile. For instance, 
you still seem to overwrite TTBR{0,1} and TTBCR.

TTBR{0,1} are technically unknown at boot. So it is fine to ignore them. 
  But for TTBCR, I am not 100% whether this is supposed to be unknown.

Anyway, adding more "if (...)" is not the right solution because in the 
future we may decide to reset more registers.

It would be better if we stash the value sand then update the registers. 
Another possibility would be to entirely skip the save path for CPUs 
that are turned off (after all this is a bit useless work...).

> +static int do_common_cpu_on(register_t target_cpu, register_t entry_point,
> +                            register_t context_id)
> +{
> +    int rc;
> +    struct vcpu *v;
> +    struct domain *d = current->domain;
> +    register_t vcpuid;
> +
> +    vcpuid = vaffinity_to_vcpuid(target_cpu);
> +
> +    if ( (v = domain_vcpu(d, vcpuid)) == NULL )
> +        return PSCI_INVALID_PARAMETERS;
> +
> +    if ( !test_bit(_VPF_down, &v->pause_flags) )
> +        return PSCI_ALREADY_ON;
> +
> +    rc = do_setup_vcpu_ctx(v, entry_point, context_id);
> +    if ( rc == PSCI_SUCCESS )
> +        vcpu_wake(v);
> +
> +    return rc;
> +}
> +
>   static int32_t do_psci_cpu_on(uint32_t vcpuid, register_t entry_point)
>   {
>       int32_t ret;
> @@ -197,6 +208,52 @@ static void do_psci_0_2_system_reset(void)
>       domain_shutdown(d,SHUTDOWN_reboot);
>   }
>   
> +static void do_resume_on_error(struct domain *d)

This looks like an open-coding version of domain_resume() without the 
domain_{,un}pause(). What worries me is there is a comment on top of
domain_pause() explaining why it is called. I understand, we can't call 
domain_pause() here (it doesn't work on the current domain). However, it 
feels to me there is an explanation necessary why this is fine to diverge.

I am not a scheduler expert, so I am CCing Juergen in the hope he could 
provide some inputs.

> +{
> +    struct vcpu *v;
> +
> +    spin_lock(&d->shutdown_lock);
> +
> +    d->is_shutting_down = d->is_shut_down = 0;
> +    d->shutdown_code = SHUTDOWN_CODE_INVALID;
> +
> +    for_each_vcpu ( d, v )
> +    {
> +        if ( v->paused_for_shutdown )
> +            vcpu_unpause(v);
> +        v->paused_for_shutdown = 0;
> +    }
> +
> +    spin_unlock(&d->shutdown_lock);
> +}
> +
> +static int32_t do_psci_1_0_system_suspend(register_t epoint, register_t cid)
> +{
> +    int ret;
> +    struct vcpu *v;
> +    struct domain *d = current->domain;
> +
> +    /* Drop this check once SYSTEM_SUSPEND is supported in hardware domain */
> +    if ( is_hardware_domain(d) )
> +        return PSCI_NOT_SUPPORTED;
> +
> +    domain_shutdown(d, SHUTDOWN_suspend);

It would be good to add a comment explaining why you need to call 
domain_shutdown() first. Otherwise, one could wonder whether we can get 
rid of the complexity when a vCPU is still online.

> +
> +    /* Ensure that all CPUs other than the calling one are offline */
> +    for_each_vcpu ( d, v )

NIT: Even if this is a single "statement" below, I think adding the 
brace would make the code clearer.

> +        if ( v != current && is_vcpu_online(v) )
> +        {
> +            do_resume_on_error(d);
> +            return PSCI_DENIED;
> +        }
> +
> +    ret = do_setup_vcpu_ctx(current, epoint, cid);
> +    if ( ret != PSCI_SUCCESS )
> +        do_resume_on_error(d);
> +
> +    return ret;
> +}
> +
>   static int32_t do_psci_1_0_features(uint32_t psci_func_id)
>   {
>       /* /!\ Ordered by function ID and not name */
> @@ -214,6 +271,8 @@ static int32_t do_psci_1_0_features(uint32_t psci_func_id)
>       case PSCI_0_2_FN32_SYSTEM_OFF:
>       case PSCI_0_2_FN32_SYSTEM_RESET:
>       case PSCI_1_0_FN32_PSCI_FEATURES:
> +    case PSCI_1_0_FN32_SYSTEM_SUSPEND:
> +    case PSCI_1_0_FN64_SYSTEM_SUSPEND:
>       case ARM_SMCCC_VERSION_FID:
>           return 0;
>       default:
> @@ -344,6 +403,17 @@ bool do_vpsci_0_2_call(struct cpu_user_regs *regs, uint32_t fid)
>           return true;
>       }
>   
> +    case PSCI_1_0_FN32_SYSTEM_SUSPEND:
> +    case PSCI_1_0_FN64_SYSTEM_SUSPEND:
> +    {
> +        register_t epoint = PSCI_ARG(regs,1);
> +        register_t cid = PSCI_ARG(regs,2);

Coding style: For the two lines above, there is a missing space after ",".

Also, if a 64-bit domain is calling the 32-bit version, then we also 
need to ignore the top 32-bits. AFAICT CPU_ON also have the same issue. 
I am not going to ask fixing CPU_ON (it would be good though), but I 
will at least ask we don't spread the mistake further.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Sat Jun 28 18:27:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jun 2025 18:27:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1028430.1402418 (Exim 4.92)
	(envelope-from )
	id 1uVaGy-0004rI-LS; Sat, 28 Jun 2025 18:27:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1028430.1402418; Sat, 28 Jun 2025 18:27: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 1uVaGy-0004rB-I3; Sat, 28 Jun 2025 18:27:32 +0000
Received: by outflank-mailman (input) for mailman id 1028430;
 Sat, 28 Jun 2025 18:27:31 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uVaGx-0004r5-SV
 for xen-devel@lists.xenproject.org; Sat, 28 Jun 2025 18:27:31 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uVaGx-0073rl-0q;
 Sat, 28 Jun 2025 18:27:31 +0000
Received: from [2a02:8012:3a1:0:d050:4cf0:af44:4b0]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uVaGw-00324E-37;
 Sat, 28 Jun 2025 18:27: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=rCCFWI4Wllo7Z6k3MB+gL4C72oQSgswDTgBN1PfOKIc=; b=ESm5n4kG1zZcnCLlCrNtKiN5rf
	dGh5UBVsLtUXo43VncafEuIWeM6O04PZfiJwifp9BRsbBpmyxzvLoEyOtBeDkIYzXt+eiF4z0N8U6
	sRqP810hsNhnniG1TOr6QKnukx6rMHjkCvYzA28Lz8PMn7itu9HbXbcftx7lDBB7m3G4=;
Message-ID: 
Date: Sat, 28 Jun 2025 19:27:27 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 3/4] SUPPORT.md: Add entry for guest PSCI
 SYSTEM_SUSPEND support
Content-Language: en-GB
To: Mykola Kvach , xen-devel@lists.xenproject.org
Cc: Mykola Kvach ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini 
References: 
 <401d3745a295812fef14a22b0c2a3c6017d588c1.1751020456.git.mykola_kvach@epam.com>
From: Julien Grall 
In-Reply-To: <401d3745a295812fef14a22b0c2a3c6017d588c1.1751020456.git.mykola_kvach@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Mykola,

On 27/06/2025 11:51, Mykola Kvach wrote:
> From: Mykola Kvach 
> 
> Document support for the optional PSCI SYSTEM_SUSPEND function, exposed
> via the virtual PSCI (vPSCI) interface to guests.
> 
> This allows non-hardware domain guests (domUs) to initiate system suspend
> operations via PSCI calls. The feature is currently marked as Experimental.
> 
> Signed-off-by: Mykola Kvach 
> ---
> Changes in v5:
> - Dropped ARM/PSCI entry: this refers to internal use of PSCI SMC calls,
>    which is not relevant for SUPPORT.md
> - Added a dedicated entry for PSCI SYSTEM_SUSPEND instead of generic guest
>    PSCI info; guest PSCI support was documented in a separate patch
> ---
>   SUPPORT.md | 7 +++++++
>   1 file changed, 7 insertions(+)
> 
> diff --git a/SUPPORT.md b/SUPPORT.md
> index f0b5718e84..659b9c3052 100644
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -956,6 +956,13 @@ by hwdom. Some platforms use SCMI for access to system-level resources.
>   
>       Status: Supported
>   
> +### ARM: Guest PSCI SYSTEM_SUSPEND support

You are already adding a Guest PSCI section in [1]. I would rather not 
another section just for SYSTEM_SUSPEND. This would make more difficult 
to know what part of PSCI is supported.

Instead, I would tweak the merge the two patches and tweak the wording 
to have something like:

   Status, Mandatory: Supported
   Status, MIGRATE_INFO_TYPE: Supported
   Status, SYSTEM_SUSPEND: Experimental

Also, I will comment directly here:

 > Emulated PSCI interface exposed to guests. Supports all mandatory 
functions from PSCI versions 0.2 and 1.0, as well as the optional 
MIGRATE_INFO_TYPE

Xen is supporting PSCI 1.1 which is backwards compatible up to 0.2. But 
effectively, we don't expose 0.2 nor 1.0.

So I would reword to:

Emulated PSCI interface exposed to guests. We support all mandatory 
functions of PSCI 1.1. See below for the list of optional PSCI call 
implemented and their status.

Cheers,

[1] 
https://lore.kernel.org/all/20250627053313.2233826-1-xakep.amatop@gmail.com/
-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Sun Jun 29 13:48:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Jun 2025 13:48:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1028636.1402428 (Exim 4.92)
	(envelope-from )
	id 1uVsNm-0007H6-Ko; Sun, 29 Jun 2025 13:47:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1028636.1402428; Sun, 29 Jun 2025 13:47: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 1uVsNm-0007Gx-Ev; Sun, 29 Jun 2025 13:47:46 +0000
Received: by outflank-mailman (input) for mailman id 1028636;
 Sun, 29 Jun 2025 13:47: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 1uVsNl-0007Gr-Mx
 for xen-devel@lists.xenproject.org; Sun, 29 Jun 2025 13:47:45 +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 a0e9399a-54ef-11f0-a311-13f23c93f187;
 Sun, 29 Jun 2025 15:47:42 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3a575a988f9so2253538f8f.0
 for ; Sun, 29 Jun 2025 06:47:42 -0700 (PDT)
Received: from ?IPV6:2003:ca:b711:f2ee:1da9:2a84:806b:ad68?
 (p200300cab711f2ee1da92a84806bad68.dip0.t-ipconnect.de.
 [2003:ca:b711:f2ee:1da9:2a84:806b:ad68])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45380705351sm114164475e9.0.2025.06.29.06.47.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 29 Jun 2025 06:47:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a0e9399a-54ef-11f0-a311-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1751204862; x=1751809662; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=s6Q61zuRf61D1alO3tt+0aoy+hlcumsezRb1wUXTQh8=;
        b=flbD3RTjwBXCgWRxkOcnY8/2oMVe/cQCNPRqWXuV/DpMu+2Vp3Gp2VkVT3JKCynqyB
         FQkLaYMaGNrESWFu2hEPq6SOIdigvVP90B+Q7xEf1rWNIeuvHozy6ow5n/72bfT6oXms
         xGBtr2s18sp7owrVGSYEec+6R3hQs6/FKs2XWSSWKRb13bo9uqJBGSJHmBfwCKRIKPfT
         Fgt6dNGKktONktNp00qe2H/XxYYx7xz6iKQ34kq6sU/3QLLfkfWWUwxBfEM6jLEjEocF
         GFsSf5GFIv5P1Pt59OKEZE/7VrAc1Sev4DbfgXOs7ZVbdv95C19Y20co1wg7D1eaS9mb
         0o1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751204862; x=1751809662;
        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=s6Q61zuRf61D1alO3tt+0aoy+hlcumsezRb1wUXTQh8=;
        b=L5Sx9+Nj18KogN5UEV2eq7ieQ53L2JGGRLRu0c19VitPw/6axgwV7ubZpuuud0AwAN
         h4+vWnaZgka1Cyu1at+ufwCB5/PEruA2I7Vo1B1mXKjSj3/zDnFs2ADQAfv2PW5M4tcD
         5Je67yVG2Ejf67fhf5CZXAe5dHvKHVAmEb8cdrrFnQphyc+C7ShjxHL1FB3dxFAggeL0
         eXLAC5aG1ebOqojfj+ZC5Goh3Y1/c0j6pP7tGEVTtSP0QwSoSpihZmscYWQFnsQg/l1v
         k+YXa2vODlUQsT+wpLvxHtokMGN4Ck54eoRaC3X5ec1eXqUqFbIFslk51sa1dUMADZ9g
         jpEg==
X-Forwarded-Encrypted: i=1; AJvYcCXGC7MIvyEEdRCLqDj4/EtLYrSzFE70PO6uoFg440Km6dlOvmVtEhEsYXomo8jRCJU2DhS43+RjYvM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzj2+TjSUyZq1sbIJrdW4p9wMdPrzwS/vvQGuAMpOYm875HpiNM
	Ede4NXIlTb4EIhKf4afJw2mvU55SSQWloYePi4TqfPDWTWmdyBUB8kNBk/x4mSRdEQ==
X-Gm-Gg: ASbGncsMmkQBSV46SpgcvMJVdJQW5ZqsSKtpAiRB10pFQUQBX1aUHuGTQnGcAJrL2LL
	eXpYkH8I/37Chp/Z5ZWEZK9e0nTBiqiSauiUIBeaolLwe0vuijYwMpRNgYv2V0f4cDJ9EkBrlIp
	q5wL3Qd3c7lA+XeLj9K3OLMU2u7/6I3GNtFEG8k6Fg3bs/IfRbSt2pAa5sBwA/J448Fx06a4t3E
	gNtoQ8uv173JYJnBRqzC8QPrTDcj5ruCEM2S1frK4//9GDxX+GN2xWeyJAcTc7evWcLSVQgK3ow
	pxBYsMksO3X0/Tpju302izCDQU+WYt2kbTI5GixALMGclchND14TYb2ElhuEwIUuaFf5tqBj8LJ
	/xIb0TxhKrLPW2qZgStPRSEj/buqr7jJRJC020AxQPn0z5Br2YEBhtr/piNM0RwKOd4huy2xjSK
	V9aHHpb5ft/Ls2owrLkhsK
X-Google-Smtp-Source: AGHT+IEOysRN1qEpAD1FP5Xvh4nPaPTenJWpcCzPnRX6vKG9jb4BJqjq9jLCjeg19Hxj91n54G732Q==
X-Received: by 2002:a05:6000:20c1:b0:3a6:d604:a017 with SMTP id ffacd0b85a97d-3a8fe891725mr6274267f8f.24.1751204861687;
        Sun, 29 Jun 2025 06:47:41 -0700 (PDT)
Message-ID: 
Date: Sun, 29 Jun 2025 15:47:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/2] xen/console: unify printout behavior for UART
 emulators
To: Stefano Stabellini 
Cc: dmkhn@proton.me, andrew.cooper3@citrix.com, anthony.perard@vates.tech,
 michal.orzel@amd.com, roger.pau@citrix.com, dmukhin@ford.com,
 xen-devel@lists.xenproject.org, Julien Grall 
References: <20250606201102.2414022-1-dmukhin@ford.com>
 <20250606201102.2414022-3-dmukhin@ford.com>
  
 
 
 
 
 <2f726960-4bdc-4996-b204-722c0253e2ab@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 27.06.2025 23:58, Stefano Stabellini wrote:
> On Fri, 27 Jun 2025, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 19/06/2025 01:45, Stefano Stabellini wrote:
>>> On Wed, 18 Jun 2025, Jan Beulich wrote:
>>>> On 18.06.2025 02:39, Stefano Stabellini wrote:
>>>>> On Thu, 12 Jun 2025, Jan Beulich wrote:
>>>>>> On 11.06.2025 21:07, Stefano Stabellini wrote:
>>>>>>> On Wed, 11 Jun 2025, Jan Beulich wrote:
>>>>>>>> On 11.06.2025 02:07, dmkhn@proton.me wrote:
>>>>>>>>> On Tue, Jun 10, 2025 at 10:21:40AM +0200, Jan Beulich wrote:
>>>>>>>>>> On 06.06.2025 22:11, dmkhn@proton.me wrote:
>>>>>>>>>>> From: Denis Mukhin 
>>>>> If I understood correctly I like your proposal. Let me rephrase it to
>>>>> make sure we are aligned. You are suggesting that:
>>>>>
>>>>> - domains without input focus will print with a (d) prefix
>>>>> - the domain with input focus will print without a (d) prefix
>>>>> - this applies to both DomUs and Dom0
>>>>
>>>> Except in the non-dom0less case, at least up and until there's at least
>>>> one other domain. I.e. I'd like to keep Dom0 boot output as it is today,
>>>> regardless of the presence of e.g. "conswitch=".
>>>
>>> In the non-dom0less case, since dom0 has focus, it would naturally be
>>> without (d) prefix. Unless the user passes "conswitch=". Honestly, I
>>> wouldn't special-case conswitch= that way and would prefer keep things
>>> simple and consistent without corner cases. I don't think conswitch= is
>>> so widely used that it is worth the complexity to special-case it.
>>
>> I am a bit confused with the wording. Before I can provide another opinion, I
>> want to understand a bit more the concern.
>>
>> From my understanding the command line option "conswitch" is to allow the
>> admin to change with key is used to switch between Dom0 and Xen. By default
>> this is 'a'. So are you referring to the fact a trailing "x" (to not switch to
>> dom0 console) can be added?
> 
> Yes, conswitch can also be used to ask Xen to keep the input focus to
> itself, instead of giving it away to Dom0. I think this is the specific
> feature Jan was referring to when he said he is using conswitch and the
> proposal would change the way the output looks like for him, which is
> true.
> 
> Today, dom0 would still print without any prefix.
> 
> Tomorrow with this proposal, dom0 would print with a "(d0)" prefix
> because it doesn't have input focus.
> 
> The question is, with the new policy in place, whether this is worth the
> trouble of having a special case to remove the "(d0)" prefix in the
> conswitch=x case. I think it is not worth it, Jan thinks it is.

Just to clarify: Along with this mode being entered by conswitch=, I also
expect the behavior to remain unaltered when booting (non-dom0less)
without that option, and later flipping focus between Xen and Dom0 by
using triple Ctrl-a. I'm saying this just to make sure that an eventual
change to the patch wouldn't be keyed to the use of the command line
option.

Jan


From xen-devel-bounces@lists.xenproject.org Sun Jun 29 13:58:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Jun 2025 13:58:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1028643.1402438 (Exim 4.92)
	(envelope-from )
	id 1uVsXj-0000Sn-GS; Sun, 29 Jun 2025 13:58:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1028643.1402438; Sun, 29 Jun 2025 13: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 1uVsXj-0000Sg-Cb; Sun, 29 Jun 2025 13:58:03 +0000
Received: by outflank-mailman (input) for mailman id 1028643;
 Sun, 29 Jun 2025 13: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 1uVsXi-0000Sa-Cq
 for xen-devel@lists.xenproject.org; Sun, 29 Jun 2025 13:58:02 +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 1192dcfd-54f1-11f0-a311-13f23c93f187;
 Sun, 29 Jun 2025 15:58:01 +0200 (CEST)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-4538bc1cffdso12824345e9.0
 for ; Sun, 29 Jun 2025 06:58:01 -0700 (PDT)
Received: from ?IPV6:2003:ca:b711:f2ee:1da9:2a84:806b:ad68?
 (p200300cab711f2ee1da92a84806bad68.dip0.t-ipconnect.de.
 [2003:ca:b711:f2ee:1da9:2a84:806b:ad68])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4538a390d11sm107564635e9.7.2025.06.29.06.57.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 29 Jun 2025 06:57:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1192dcfd-54f1-11f0-a311-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1751205480; x=1751810280; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=/OppVkuopOJMhjQLdxBUIEkfWKUc28pCbHwwQlPhVNg=;
        b=HmPlMZZYrDPvRcuUkTCwJSfBqc+QJqYol7h7ZHIUzhAVk03u9YjWuit3qxsZrc1Q9C
         5i+j98SwKVcGrky4kTKXzCzKHbzjsKvML20gDcqFKlxy3uE5QLTaheHxNLUeX+JZEoWi
         5LXWtnddn2U3MnSAxV3FApGJqGel4GwL20N/VQLOWq611S2k09VJ1Js9k8qM81MzAg8g
         hWL9J75yQSRqzy20kB8ACvN9VUSaibjnHkb/nckA8bzp31FVG/tmBABKQI57z70Hx7WN
         TWKQvGYDBdBNuOa1b0BAYC2vZDipya9LaN6hBUZ8ofH4m+QlwQg4E/lIw7SKJrPuUZ3R
         0Z+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751205480; x=1751810280;
        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=/OppVkuopOJMhjQLdxBUIEkfWKUc28pCbHwwQlPhVNg=;
        b=P+MuF7riuJLTqwqICZQ8S/JixEBL+rH2bAguaYiqiyNUFdPnvmfGTnXGGWjExOBSBY
         6eRu7aIO11t2QUpDunpg0ehLKoOJqAyKbp4Nx1xjPlwZ8w5XueD/EDmk68KzTGJjaYjG
         Y9J01AUQAPTZWA17zsegnvGOibEI6Zsoa/m2/madQWZESHY/vSod4tgH24ICqCB5bXl8
         0rMAoXoFwU3cm9bxvhMgIL9uO7YQ9mmQvfXus3GCmAIUaJnyrSRfSRmS8owPS71yz2Ss
         K/hmTxsXt9VxbHW4SmrK/6q3D3hNsPb5sWbFrfgfkpkwvRaaCjqvmYkymmBQ/YxKNfzR
         r8Qw==
X-Forwarded-Encrypted: i=1; AJvYcCW4qHj3KUw/aCHq5Q2ex9Zg3DhuZJRteLYeDcv0rY0QnIIQ0kicGgrKGzQIjTCksOKcHD2oPAr7kTY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxmQqMKxPGPz4lgbVpA9zqV385HZb9OFG1OMLZ4eQ/ogbTmJglX
	zb0/XKVSNFvf1/h7qcrNWNK9nX/ulB39rQoHyEnE/Wk76IhrlOBGuSnX8maE1w1RsFTrKfi41NS
	k3NM=
X-Gm-Gg: ASbGncsIP+bOA21W5F5TsrfbSekXjqlnyByTwKEhCyLJPPRYXpN10D0c1mKeK+iaWmo
	7aBs+zxUXnfs/KGf2Sox12UNPCu26g1Kc6PSMq20bZGY7lXaQFt4UtCI17E4jDI46UKC8lZcInj
	KV+BgBz2t3OFntIEexe0TFDgZhz65MPIzHT/KmS2E4vA/gM+wauJCDT1z54BD8401CbtcShqVq5
	HVID7NbaDd+IvuhtM1I0Ud9lBD8X876EwGcE2cxEdGe9NFUqg3pSDUaNI1uMn3RsdefcZG89np3
	0ufFMWehQYo53tJvJPZRfNOaH1TYTS7P/e/35Fiz4zKSspYwWC3aCH22BuiPi4lekn8zH5SbGNo
	dVCTSn0MMgTujt3WeVamwXh9cUwV0uRoAkMpzlVMz80G1ne2FljTK1jvI9t6KLawSp5KscV3hyQ
	fprPQQhEzzFGlHqT2nc36a
X-Google-Smtp-Source: AGHT+IH9xqoyaM/eypZYWH78msxTCuC3B7j6W2ZmQAEk/MKEHGkklfeo88gzpxlGT3GntjlpYkpTcg==
X-Received: by 2002:a05:600c:a41:b0:43c:eeee:b713 with SMTP id 5b1f17b1804b1-4538ee83b1amr82134805e9.20.1751205480224;
        Sun, 29 Jun 2025 06:58:00 -0700 (PDT)
Message-ID: 
Date: Sun, 29 Jun 2025 15:57:59 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/cpu-policy: Simplify logic in
 guest_common_default_feature_adjustments()
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20250627141907.525027-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: <20250627141907.525027-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27.06.2025 16:19, Andrew Cooper wrote:
> For features which are unconditionally set in the max policies, making the
> default policy to match the host can be done with a conditional clear.
> 
> This is simpler than the unconditional clear, conditional set currently
> performed.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Sun Jun 29 14:36:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Jun 2025 14:36:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1028654.1402447 (Exim 4.92)
	(envelope-from )
	id 1uVt92-0005Wj-65; Sun, 29 Jun 2025 14:36:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1028654.1402447; Sun, 29 Jun 2025 14:36:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uVt92-0005Wc-3W; Sun, 29 Jun 2025 14:36:36 +0000
Received: by outflank-mailman (input) for mailman id 1028654;
 Sun, 29 Jun 2025 14:36: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 1uVt90-0005WD-BI
 for xen-devel@lists.xenproject.org; Sun, 29 Jun 2025 14:36:34 +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 717e5a51-54f6-11f0-b894-0df219b8e170;
 Sun, 29 Jun 2025 16:36:29 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3a588da60dfso714703f8f.1
 for ; Sun, 29 Jun 2025 07:36:29 -0700 (PDT)
Received: from ?IPV6:2003:ca:b711:f2ee:1da9:2a84:806b:ad68?
 (p200300cab711f2ee1da92a84806bad68.dip0.t-ipconnect.de.
 [2003:ca:b711:f2ee:1da9:2a84:806b:ad68])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a88c80b50bsm7814157f8f.42.2025.06.29.07.36.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 29 Jun 2025 07:36:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 717e5a51-54f6-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1751207789; x=1751812589; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=d8BoEmLpfZ4wfOaxjizQSf77tH7NDGGE11mVzf6Xqgg=;
        b=PBQ7EHxUXcFc7AOZbwKJZwTBVZiQC3ig+AikzSLQYkt5N2F3+5Lr037Uho4auwbrQa
         mOiwsXCPrBC434VNzqP3DlaIZrUMzLXeYO1NzAzdg7bPMXYYrA5oIoC2WYsyLA7UKNIM
         vQM1Sq5PXC/4BGDs17W8k/WlNKcnNTmqIzgJ1DCJoSfScFkROsz7cEB7vr+Gm0zlpiIp
         yeRSW6/RMMkL1HrD2cVsBjowCM9doclBpwijbs4W9u2f6sKGog9j7HOy+MMB1y0kRGGU
         ZEFEY/o/Z6KzKP9xuDAR9j4s0ObAYs1raZ7vPX0yRk3Ip9v1+bjZ0AetQTuvKc0S1MM/
         hdqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751207789; x=1751812589;
        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=d8BoEmLpfZ4wfOaxjizQSf77tH7NDGGE11mVzf6Xqgg=;
        b=cgo1T6wjnvz8eucxbrVJwci7oWQKJkfR3tlUVQUwBQkzoiQhH+MBlfE2+tspRp4jep
         OVcLGtjpOgCzd40uW/Tvhw0Pp5k8mH+HaTTdIgTkOLd1zp8E6yRTeIxaBMNu9hx8inbE
         1BhfIhkKVjj2L3ciIA8vSqYfKH/SlFformLApleetgfbBzYBhFSbgI2OlrEKA5x7JxMO
         +TutdEwLuIAVoPcNuBIYsQs6KuEyRnovTVSYZktREDB7p5M66M3JSBAVl6CydoP3B3PI
         55fTwvisr+hhWMvIxJjEYbvmvxwxUe2wVO3CVBUHswUkrAkIq1/2xD/AIxGZziJei0BP
         b8VA==
X-Forwarded-Encrypted: i=1; AJvYcCUA+z7vnQHhVdvyUjaWLJVW6UcG1Rxkikt5R5DcteBfK9jhemxu0P0PdgnpsmNBoA1nJbi/lEsTkCE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwMQkbSO3uYymo5KrhnE5P/npHj4x4Cxp2k10N1qHQmM+IsvYPS
	zTxWKIlbJdp02tGWjNXuw/Cv4MlnpQBNWSv01Gv+5OGAkdiUhFKgqJnGgFO7FdjygA==
X-Gm-Gg: ASbGncvoQDueuQOMntNdXNs6WgGppuXOqg07vtMz82SGPfrObdQOXMlnsXNRXmvWnmT
	peGyXEByHtfUGe+2N1wpH+27qnbKYklWswPiR8XuglaEbl+cd9HPr9hmDjY/DiwECCrTrk68LbA
	MiewF+4cafINYDc5fb9quwIGPxpxc/WQMn2wYask5OMlUUrBcxOMLHjVVEUxBrtfHfPK6wJAdbI
	3GmfQDduXrRyXs4YSp79DR03KO6ie6wXIu7uOUCLTM6zFOuTKuFMI14SxZxQ2Qo082AsX/eMUWN
	lfd4cUcEpftPqNyg687fbknaaFctmhXKWp8vzphuXVTqUAU1onmW+vUVxb9qdpHt/MvjbbTAm6D
	J7WyBUC3Jvz/m2RXeJeajE4KHH8QEfOOGIk0ih/pGYqueNwcWV3RBAu7s7PEKcgu7WQe4RkjCP5
	TNtdIobE2ZTKyn9gfKiYca
X-Google-Smtp-Source: AGHT+IGaY8hqgS3R48GHPOWH+BcG26/77v9n8PFNhbVXp5DeSG7J+FDh/7r5m3k1AT0FzhPrjY7dPA==
X-Received: by 2002:adf:9c81:0:b0:3a8:6262:e78 with SMTP id ffacd0b85a97d-3a8fe5b1dd8mr5226464f8f.37.1751207788611;
        Sun, 29 Jun 2025 07:36:28 -0700 (PDT)
Message-ID: <48882150-ed23-4810-b773-74748b9b3cae@suse.com>
Date: Sun, 29 Jun 2025 16:36:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 8/8] pdx: introduce a new compression algorithm based
 on region offsets
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Oleksii Kurochko ,
 Community Manager ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250620111130.29057-1-roger.pau@citrix.com>
 <20250620111130.29057-9-roger.pau@citrix.com>
 
 
 <475fb02b-0b00-4aab-b73c-9604fe050074@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 27.06.2025 16:51, Roger Pau Monné wrote:
> On Thu, Jun 26, 2025 at 09:35:04AM +0200, Jan Beulich wrote:
>> On 25.06.2025 18:24, Roger Pau Monné wrote:
>>> On Tue, Jun 24, 2025 at 06:16:15PM +0200, Jan Beulich wrote:
>>>> On 20.06.2025 13:11, Roger Pau Monne wrote:
>>>>> +bool pdx_is_region_compressible(paddr_t base, unsigned long npages)
>>>>> +{
>>>>> +    unsigned long pfn = PFN_DOWN(base);
>>>>> +
>>>>> +    return pdx_to_pfn(pfn_to_pdx(pfn) + npages - 1) == (pfn + npages - 1);
>>>>
>>>> Aiui for this to be correct, there need to be gaps between the ranges
>>>> covered by individual lookup table slots. In the setup logic you have a
>>>> check commented "Avoid compression if there's no gain", but that doesn't
>>>> look to guarantee gaps everywhere (nor would pfn_offset_sanitize_ranges()
>>>> appear to)?
>>>
>>> But if there are no gaps, the full region is covered correctly, and
>>> hence it's compressible?
>>
>> If there's a guarantee that such ranges would be folded into a single one,
>> all would be fine.
>>
>>> Maybe I'm missing something, could you maybe provide an example that
>>> would exhibit this issue?
>>
>> My understanding is that when there's no gap between regions, and when
>> [base, base + npages) crosses as region boundary, then the expression
>> above will yield true when, because of crossing a region boundary, it
>> ought to be false. Or did I simply misunderstand the purpose of the
>> pdx_is_region_compressible() invocations?
> 
> If there's no gap between the regions it's IMO intended for
> pdx_is_region_compressible() to return true, as the whole region is
> continuous in both the PFN and PDX spaces, and hence compressible
> (even if it spans multiple regions).

My problem is that I can't make the connection between that function
returning true and regions getting concatenated. When the function is
invoked, concatenation (or not) has happened already, aiui.

> But maybe I'm not understanding your point correctly, could you maybe
> provide an example if you disagree with my reply above?  Sorry if I'm
> being dull, with this compression stuff it's sometimes hard for me to
> visualize the case you are trying to make without a concrete
> example.

What I think I didn't take into consideration is that from two pages
being contiguous in MFN space, it ought to follow they're also
contiguous in PDX space. Hence [base, base + npages) crossing a region
boundary (if, contrary to what you say, this was possible in the first
place) would still not be encountering a discontinuity. So overall not
an issue, irrespective of what pdx_is_region_compressible() means
towards (non-)contiguity.

Jan


From xen-devel-bounces@lists.xenproject.org Sun Jun 29 15:05:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Jun 2025 15:05:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1028684.1402457 (Exim 4.92)
	(envelope-from )
	id 1uVtaz-00011q-Aa; Sun, 29 Jun 2025 15:05:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1028684.1402457; Sun, 29 Jun 2025 15: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 1uVtaz-00011j-7r; Sun, 29 Jun 2025 15:05:29 +0000
Received: by outflank-mailman (input) for mailman id 1028684;
 Sun, 29 Jun 2025 15:05: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 1uVtay-00011d-EY
 for xen-devel@lists.xenproject.org; Sun, 29 Jun 2025 15:05:28 +0000
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com
 [2a00:1450:4864:20::32f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7cc36a36-54fa-11f0-b894-0df219b8e170;
 Sun, 29 Jun 2025 17:05:26 +0200 (CEST)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-45310223677so8784185e9.0
 for ; Sun, 29 Jun 2025 08:05:26 -0700 (PDT)
Received: from ?IPV6:2003:ca:b711:f2ee:1da9:2a84:806b:ad68?
 (p200300cab711f2ee1da92a84806bad68.dip0.t-ipconnect.de.
 [2003:ca:b711:f2ee:1da9:2a84:806b:ad68])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a88c7fa884sm7795933f8f.29.2025.06.29.08.05.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 29 Jun 2025 08:05:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7cc36a36-54fa-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1751209525; x=1751814325; 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=7+R4jycDgKuEiqOjobbAQ6hJXswPwBD05fVgtTyeiPM=;
        b=AJ7Bj8JNwKVsPsILJ5/MMj1+SJfo9yrmVpNpslQsdQAX24FDsNaay1McwX5cQHPHsq
         pmjd6uLr6WgYT1fEOyIXCJeguIya1tL81RbR6+IGszarLSA6hfr/18kCevU0RHjFXEgh
         szA9a3eVzTlX+D4KxIJuhYS/ESwkg5bjtBEygKt5S2xGOO+RD82qIom28Q+pW8H0G5gk
         4ese7Jgk6IwsLGH1ip34tz4FNXjcHhF19RnF84vIxk5diY4Qhfyv2eVHB7lAR7zgtNbA
         WPRaarWOSAzlHbS7B48zRsW/HvIsFh4wpfBMV3CGhhoQfZdqAQEY1rR9FSMPZ6GQR/Au
         ezsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751209525; x=1751814325;
        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=7+R4jycDgKuEiqOjobbAQ6hJXswPwBD05fVgtTyeiPM=;
        b=ZJjivwULMqvpHoFrRi6RDKbLGUEwMMTvCxnPQ00dUSN0ZipRw4hMPy5E+F2n5PMuXA
         uN4UgGDzGQFHS5f83ymUXNbAkzc3RCAcAb8x1UL+fDK/bdYkkX/LD/+O0iLAg7hPRzaS
         iSGkIWG1f0xwUzmixuqHjUHYNbt1GXsq+SsJVTTZkv6uQmIRDz7DYEAlLenYSLSBCklu
         qmsuH3shoikCk9tZxWcshJJy/mTKOzsYgEdpflOIitUG2Ug3qkx/GcCyRVTbthH7jSHM
         q24Wtbsoz4joVZeNgamIuhf4KUX8XV0UQZc4n8hQfRiToWguFmwi5HDBnSCQss2SKyy9
         7FfQ==
X-Forwarded-Encrypted: i=1; AJvYcCW6IXrh3iVKhF6ACqvlOvkRMfLjvwkzUHDvgtGd/uwtN3yG/cEhJtZENYBnzegYG6jCAspCbmFdieM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzhani0/XSerh885/cnfR7z6Srfty8t325sd4DRs3eBSfgsP8aI
	E9+/khU8XFOx/j3j4QRmQKXWVkag/s1ywcc4TbdSu/jJL2JAVCiG4/0x0f3FXH6LYg==
X-Gm-Gg: ASbGnctZC8IZahs2QP2OZoOZAyPm6XFjRlq2DFdcDsx7oouMYzzLqCMenLDkO9Z1zMX
	v8J2V2libitIxFoHsXzobaf9WCD0hG6crPUF3iSUTF2HzgUUc4C8b9aQv0DBYJDFedlvMpaK3Xw
	X+rLtt5QlIwFm2AJyO587Ucfrh62n7L9q+J+kLXQ892qf+Uqu+eeyULu9ueDUvITHlHBvHN36l1
	2FVRGWcpOYim7kGMC9Y8KcFEAt/FstcaTmzlzGXS58y2Pm9kgXd3R6J1DFuIHp5FTczUHJ010p8
	t/+r8pU6Ozs5hiMkeMdMXxvJn4p46p60EutFVCwCpGsH+2MW9vVgSqTcymKYzRoC6Yf9tFRUfR8
	ENTsiTmkBkqC2q/9el1RH9hNzyZhkGmfTxyEA9ICBqqXhQss3wbh5SGYMt21wzevYxUQpnB4rp5
	I/LUz84s8djfj2visBsVn9
X-Google-Smtp-Source: AGHT+IGMJDSrhfdeSWpJwfKU2eCvJPl9P9Z514ENvRVVtv37yxqYqXbIg59HwXxhjfYcIO91mAMjKg==
X-Received: by 2002:a05:6000:2a85:b0:3a5:2848:2445 with SMTP id ffacd0b85a97d-3a8f482bfebmr6658464f8f.16.1751209525456;
        Sun, 29 Jun 2025 08:05:25 -0700 (PDT)
Message-ID: <0e55fa4f-2460-4ea5-91bd-46c86d3136d5@suse.com>
Date: Sun, 29 Jun 2025 17:05:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 1/7] x86: suppress ERMS for internal use when
 MISC_ENABLE.FAST_STRING is clear
From: Jan Beulich 
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "xen-devel@lists.xenproject.org" 
References: 
 
 
 <634154c0-ecd7-4c24-bc52-91aeefe367f0@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: <634154c0-ecd7-4c24-bc52-91aeefe367f0@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 26.06.2025 17:45, Jan Beulich wrote:
> On 26.06.2025 17:31, Andrew Cooper wrote:
>> On 16/06/2025 1:59 pm, Jan Beulich wrote:
>>> +    if ( !raw_cpu_policy.feat.erms )
>>
>> This wants to be the host policy, not the raw policy.  That's why
>> `cpuid=no-erms` isn't working in the way you'd expect.
>>
>> cpuid=no-$foo means "Xen should behave as if $foo wasn't reported by
>> hardware", and that includes not giving it to guests by default.
> 
> Hmm, interesting. That's definitely not the meaning I give this. To me it
> means merely Xen shouldn't use the feature (with an impact on guests only
> when the feature in hardware is required to surface it to guests). I
> don't think we have the precise meaning of this option written down
> anywhere?

Then again I notice what you ask for is in line with uses of cpu_has_*
(where available) elsewhere (e.g. in your "x86/cpu-policy: Simplify logic
in guest_common_default_feature_adjustments()"), with
calculate_host_policy() simply copying boot_cpu_data.x86_capability into
the host policy. So yes, I guess I'll need to adjust.

Ftaod, this still leaves open what exact meaning "cpuid=no-..." ought to
have. While kind of an example in the opposite direction, consider e.g.
"cpuid=no-lm": This cannot sensibly have any effect on Xen itself. It
could plausibly mean to permit only 32-bit guests.

Jan


From xen-devel-bounces@lists.xenproject.org Sun Jun 29 15:17:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Jun 2025 15:17:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1028695.1402467 (Exim 4.92)
	(envelope-from )
	id 1uVtm7-0002l8-CQ; Sun, 29 Jun 2025 15:16:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1028695.1402467; Sun, 29 Jun 2025 15:16:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uVtm7-0002l1-9n; Sun, 29 Jun 2025 15:16:59 +0000
Received: by outflank-mailman (input) for mailman id 1028695;
 Sun, 29 Jun 2025 15:16: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 1uVtm5-0002kv-Ui
 for xen-devel@lists.xenproject.org; Sun, 29 Jun 2025 15:16:58 +0000
Received: from OS0P286CU010.outbound.protection.outlook.com
 (mail-japanwestazlp170110001.outbound.protection.outlook.com
 [2a01:111:f403:c407::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 15a9a446-54fc-11f0-a311-13f23c93f187;
 Sun, 29 Jun 2025 17:16:54 +0200 (CEST)
Received: from OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:10d::7)
 by OS9P286MB4989.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:2c1::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8880.15; Sun, 29 Jun
 2025 15:16:46 +0000
Received: from OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
 ([fe80::80f1:db56:4a11:3f7a]) by OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
 ([fe80::80f1:db56:4a11:3f7a%5]) with mapi id 15.20.8901.015; Sun, 29 Jun 2025
 15:16: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: 15a9a446-54fc-11f0-a311-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=uyRnaDH4ZrsIdcxrYEa+rrZrMRjBB4wp+P8610hoSG7jyZH0DeuC3LssehyTrz1gw8slOkenPnfNI2nXwTgkbKQWp2RVY897+GCrucERwzQck5ZX7+Ct455VLYQ/Mo00W6n3eXkQgQEv/y38BONFOFHDB7cGTwUquHp8VetffWYD8uho0pPC3MNSdtKAUlG9mj+jxV8dmY3oOHMtQcyRHOZlEjzbXwla09bPnkwUIzK98MBNKjUq4OcDfy5YEOdjWAV1NMpJfe0fOUsD+3s9DYA7sKcMe77KLGJ2ZqxAk7mdYVf/FFhGDDHdpWAXWskTcFb/qK83hyS4mEfqbvKJZA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=tCsUgSwtSB37D1Pg4exdlnTtaGZ/hiRsZz2RlFPIAC8=;
 b=yZNgbGPFTKHSknRdE7luXmKGOZiH0ftPaOkWQiVdtGt4tJkPnmc8v+22gRORlgXNhpOIwoDtxH5Ruxx89qseWEOlQZ6YYRWo+cmrZ3HVXQbN0QbuCkc/g00ctoQS6QNb//G+IkUsh2PfIY0TvTD3HJ5bTJ/rIlVBuEs7bwX7WhdaHqqYtOCEUxyjtym8k1kx2YUjDK4SUpe4czcWgEFm5EU1LcmkyY+oMeApv6cfeE3sq8h81ioBVgfY2PVGaCKi7wD+a5EZsAaNS+Jex+wsbr5u7Wj/eIFSrLP/4vSPnJsaq75lTHAK3Abs4PgVjGJxcHbjRJ/SNVPd5a3V2jrkkg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=valinux.co.jp; dmarc=pass action=none
 header.from=valinux.co.jp; dkim=pass header.d=valinux.co.jp; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valinux.co.jp;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=tCsUgSwtSB37D1Pg4exdlnTtaGZ/hiRsZz2RlFPIAC8=;
 b=fgtgVsjgqYGhv0QXWJYlZwLyGmruDvoV5tfCP8/RZo7DhNLH+syk+fOLFYaRZOiXpFb5QNNBYlPycy0l9Md2pXoqEsUgh8RdP49tzv0jDNjn9doK2uKbDvc8dLTQhauZg5KCI6rdDHs2UfUUVhp7X/dlZgarIK0nCMmxQ6HitNw=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=valinux.co.jp;
Date: Mon, 30 Jun 2025 00:16:42 +0900
From: Koichiro Den 
To: Julien Grall 
Cc: xen-devel@lists.xenproject.org, 
	Stefano Stabellini , Bertrand Marquis , 
	Michal Orzel , Volodymyr Babchuk , 
	Andrew Cooper , Anthony PERARD , 
	Jan Beulich , Roger Pau =?utf-8?B?TW9ubsOp?= 
Subject: Re: [RFC PATCH 4/4] xen/arm: Implement standard PV time interface as
 per ARM DEN 0057A
Message-ID: 
References: <20250621151201.896719-1-den@valinux.co.jp>
 <20250621151201.896719-5-den@valinux.co.jp>
 <21cbc79b-2209-42ef-8085-81c41e8e697b@xen.org>
 
 
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-ClientProxiedBy: TYCPR01CA0184.jpnprd01.prod.outlook.com
 (2603:1096:400:2b0::13) To OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
 (2603:1096:604:10d::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: OS3P286MB0979:EE_|OS9P286MB4989:EE_
X-MS-Office365-Filtering-Correlation-Id: 41ce54d5-9aad-44e2-0982-08ddb71ff59d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|7416014|366016|376014|10070799003|27256017;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?wB4EPKYBp9BrUH0FNpvpyiKZy0vN41dR2ztDL++C0PRnOpQNrZgkc4fIdREl?=
 =?us-ascii?Q?3TeLFwyj49NsCiAXsPmN7NZDMA8U4vwu/CzLdP5PEzOc+JZTBqvngv7k4KNE?=
 =?us-ascii?Q?HE+ptYgxBZESa0X4wIrdPP1noAVUfU+pd/kGzm/DNZzcc5ACo2bvy34Fqcwq?=
 =?us-ascii?Q?nkFIgWINKiNz4bK9j2B8ng+KVR9v3pKBjYLZvnjfLG4ynoqmI0HieZa8umYu?=
 =?us-ascii?Q?LxLvJes3xxZAYoWAebRuIeokqBVO9LuAgH9eK66Ps7lQW3you6Eo+O7jE+Oa?=
 =?us-ascii?Q?E6Pi1T+r7fnSlzZR+LoPRXV8dJJ2tzBzSnRqqqhPReSVMm+NEmqMLHdb2M15?=
 =?us-ascii?Q?jx3kHejssSed3fIYVMIj5zDys7XburJEFlh+7ZXuBb57B+t8PpDFwwplaLyi?=
 =?us-ascii?Q?mJQ7/fekZc1KYQZKwwAJQVWWknwn4M3QoQVAnaZdqKeTTqIJc+R4fjTpp8bY?=
 =?us-ascii?Q?tAlqgc5HGfdfGeFkXLRn5qKiCGtEjgNtW7n/1KX2RuEXndtSJ4+hvkKnTMLU?=
 =?us-ascii?Q?6a4faJO1sfeiwtxVNhMN3YEcxA/DNayqQ9NBKnV0Ky3nj6/tImsWDRJVetZ4?=
 =?us-ascii?Q?WN+n8ieOJO/uQ4WGkIGlZw27WiINACpwmfsdNKp8TYAToeEC/+KPzsq5I1Bm?=
 =?us-ascii?Q?FF/Cje2roX5J1w6JnyV/WMR/8I4YE6iRWI6LcpghqKaxmGsl8pXJaFUB0FYn?=
 =?us-ascii?Q?/+k8pyHkLKFr79/U5TDTx7lzxXnM+aIR13QVJG+gy1t5pJZHc1exZrulHgvm?=
 =?us-ascii?Q?1Q+Ym53woONrGiwnO6Vorb0hRtK2TGNu9c+nvwj1Ib6Cm6NMTAFSLJlDnamu?=
 =?us-ascii?Q?T299sqBjFquJUZjwjDGCgjUnxwvS7UbTeUZeTtIUoW2g8ejJCwEi1wQ6NCBO?=
 =?us-ascii?Q?HPl+aKQ+95sYtklqB+LJ/3/68Tk71QkUoXKV9sGZkV3g9IJScAo5h8l1Fvg0?=
 =?us-ascii?Q?0B7rMkN6KRNQ1N/++Ic5P33Em4f08LUgv3gJVZa922jfsTccZuKqHOMo1T/C?=
 =?us-ascii?Q?LtmkKDyf28H/z7rnS3DhsMGCTB9SPSqOgs2FX1IWBw5RdoNbHNTZIAs8tmoW?=
 =?us-ascii?Q?rm0WLqwm8Um++h5BPrgRJZCVvUbSHZ2rVwX7q8Zc9TSm+DigrVM0jH31riVc?=
 =?us-ascii?Q?gZwbunxg99yfgWcTrLQr1W3NFp6nlCujfkI7xVvt2UXmxQLCvMZTOkiO6p5k?=
 =?us-ascii?Q?nuolzXeuhGmr246LeKpQPuXW0Zf5tuGgELQSPTI7Yk2ID/mjrzEtuUTWLCrX?=
 =?us-ascii?Q?gSzJzAy4pVEZ9V+gTMpS8C45mynKdUm3vLaAr5vQAT8oKOH3GXdJlbaBK3Xw?=
 =?us-ascii?Q?9AjJY/2NWA3xXqRZHuVCNccADnE7h0QsvjPkICE9C4F6M5J1n3vGqou5nVUW?=
 =?us-ascii?Q?duD11FlOesjzNqsZ+lVGOxkplKeEHzKF6B1YnS9e256dEUaaXv2twZAyFUS/?=
 =?us-ascii?Q?g4xfUHrbgNziCx3UGl8fO0QXmRTt7iSU+aXSBYRE0/jKYca2fACf5w=3D=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(366016)(376014)(10070799003)(27256017);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?2l+EzraWwl3PmBPSxK5aUJX4BzotmacLmgv8PBQobqyxjbE/gf0ncn6TG/Gt?=
 =?us-ascii?Q?vY4C51hDM4yaINgG3bK+WM0D0idobpSMlu9vmyL41A7Z4lxQ0ixClgHPNwJp?=
 =?us-ascii?Q?VseAKtY4GawBJ56FgWStaAC+Ru6PfL7hWsCD2VMYpraNpxi6C19eB9EKVVSQ?=
 =?us-ascii?Q?OBBLWLAKQ5KCIaLaHRkurPdBBBixuaJrOSiw63uC7fviMRPXrh/YHGyGOgs7?=
 =?us-ascii?Q?3pGKjp/sb9DPLk1ipWD0LA+I/4DQJvZ3QlJ8180vl1B2MvN0u/soI/pzvhoQ?=
 =?us-ascii?Q?Wvj4wpQr88QbXx22vMirfTrFsYo5NcEzRBM74ZU/Ca/b+fH9d6qgpI7ZLywC?=
 =?us-ascii?Q?fkrQVkrLBLeErntZUv5EeA29yUjK3n1yXW3LN03JtpIm9Rkl+Sxa5cLS2COA?=
 =?us-ascii?Q?CklvoK9OigrZPnlvHPBUQylP/KEI7bk1CvwAK24fszC8pQIqYUEbOc6nnpT1?=
 =?us-ascii?Q?9vs+32QNYHmisbIfZXngYAeqZZG6GdG87eXeUNdJ+eqSEPrNViZSKIMZhLU6?=
 =?us-ascii?Q?CPxxAJGpFP8WOfgekcvCQ8VfuAMofUBq8SpPbME7qNfVqe6cUkRF9m60IWXN?=
 =?us-ascii?Q?lbpcUmegHN/EspJyc5V2qBNWwD24wDb1N/hLkoO6UYZlVnnG1P/op3ODF7rk?=
 =?us-ascii?Q?ngi0T3luDqHPMBCAH3tgreE0F3b2L9RCZx1eSBwYi0n/Oz/rmhBBNjdM8iGu?=
 =?us-ascii?Q?fY7Yi0HUEJeCBYtAWlqd9ITIFNEHpoJ0i4zybl9Y6sdYXM9MYVPXiKQwn6w7?=
 =?us-ascii?Q?gXMpktYGQnV5q8SUW/NFzvS+htpmqKRiyawE2hWZEUWojqwsM/nfAmH+OoIq?=
 =?us-ascii?Q?/GLMRzh56GaC9RMamY+9bTfDP9P9IxeXNo7ZYn+I4xPlNcGtYeWnEnWDZXZh?=
 =?us-ascii?Q?ouDpvdU2ApLsUYZe4Jdhf7U/M+ugGBuexfvUq4xYUACLjKg5YydGibSuRCVQ?=
 =?us-ascii?Q?wRjovU597sE2RkB8swMYWrFZyJTlMNkykmmnP6i0k+z7BW4dscrrGEUu6Y2p?=
 =?us-ascii?Q?ftbJ7nmcAMxMWIeEajJmPle3DnU1WxNn17/rIY7sKnthKLc7KzMWt7k+V7oW?=
 =?us-ascii?Q?VRwkNpb4e9V+Ss54SVLP3M/5phmpYxF8Z9ELstn77DeTnUxUx2WCZSTz0ycz?=
 =?us-ascii?Q?cWMkIEKbBrTBzxSNBo9jYg+V3vlwOJJsqIfs78OGfyMTnLLC0P3ldLeaWF9i?=
 =?us-ascii?Q?JW5CrdFUQ1yaIrGQ7IbOdFgH7Dsp5fwRjn73jnIv2BFiTZeIE/mDZgCtmWfN?=
 =?us-ascii?Q?zXR1uMi/6ce3GU11CFaiuFS9Zli7BYdfcMytWsDefBSwCvRhtXUQkd4lB6EY?=
 =?us-ascii?Q?EXbVrn/W24o4Eo6SVH/HUJIyjntnX2P8upDfk4cLuz0dM9H+uhE2gJfWt/Yd?=
 =?us-ascii?Q?9RP+1MlFY9fRqytPgNIKbmhEnJPaBe3ylRpzU+KsRnsiBKxfZpKmEXZu0Yeu?=
 =?us-ascii?Q?5ccryuE4CvckClQISG7WlGcLOQlsLUVz4f0VKgHFsX+gW21k1N45sIm0l92T?=
 =?us-ascii?Q?iRa9xjmelLqjf+kMxz1eL6ADdwTxkolpmRi0fviJY0dN+F9Ezar5eJYfP15r?=
 =?us-ascii?Q?kcfLiU9umwueeBY4khiRTfwNkTIYZOt+c+3n7C5ddaj5pY8ktV68T6zvZVSe?=
 =?us-ascii?Q?6GgC0jDbHildugv6FVXo/cE=3D?=
X-OriginatorOrg: valinux.co.jp
X-MS-Exchange-CrossTenant-Network-Message-Id: 41ce54d5-9aad-44e2-0982-08ddb71ff59d
X-MS-Exchange-CrossTenant-AuthSource: OS3P286MB0979.JPNP286.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jun 2025 15:16:45.1499
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 7a57bee8-f73d-4c5f-a4f7-d72c91c8c111
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: h9RXQOKHGjiseKtGTmqzhBO2d/A7xP8kN0IaMr0I7GYi5w8FWLWjbRTENVL7+4HRoHq6EK5MRZCtMXbMAALYmw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS9P286MB4989

On Sat, Jun 28, 2025 at 06:36:02PM +0100, Julien Grall wrote:
> Hi,
> 
> On 28/06/2025 14:58, Koichiro Den wrote:
> > On Mon, Jun 23, 2025 at 09:41:47AM +0100, Julien Grall wrote:
> > ---(snip)---
> > > > @@ -707,6 +723,7 @@ int arch_domain_create(struct domain *d,
> > > >                           unsigned int flags)
> > > >    {
> > > >        unsigned int count = 0;
> > > > +    int order;
> > > >        int rc;
> > > >        BUILD_BUG_ON(GUEST_MAX_VCPUS < MAX_VIRT_CPUS);
> > > > @@ -791,6 +808,19 @@ int arch_domain_create(struct domain *d,
> > > >        d->arch.sve_vl = config->arch.sve_vl;
> > > >    #endif
> > > > +    /*
> > > > +     * Preallocate the stolen time shared memory regions for all the
> > > > +     * possible vCPUs.
> > > > +     */
> > > > +    order = get_order_from_bytes(d->max_vcpus * sizeof(struct pv_time_region));
> > > 
> > > As this is an order, we could end up to waste memory fairly quickly. So we
> > > should try to free the unused pages from the order. That said, the maximum
> > > number of virtual CPUs we currently support is 128. If I am not mistaken,
> > > this could fit in 2 4KB pages. So I would also be ok with a
> > > BUILD_BUG_ON(MAX_VIRT_CPUS <= 128) and we defer this work.
> > 
> > I'll go with the former in the next iteration. Thanks!
> > 
> > > 
> > > > +    d->arch.pv_time_regions_gfn = INVALID_GFN;
> > > 
> > > Does this mean PV time is optional? If so, shouldn't we allocate the memory
> > > conditionally?
> > > 
> > > Also, looking at the code below, you seem to cater domains created via
> > > dom0less but not from the toolstack. I think both should be supported for
> > > the PV time.
> > 
> > Yes, that was intentional. I should've mentioned that this RFC series only
> > caters the dom0less case. For domains created dynamically via xl create, the
> > only viable solution I've found so far is to reserve PFN range(s) large enough
> > to cover the maximum possible number of toolstack-created domains on boot,
> > which I think would be too wasteful.
> 
> AFAICT, with current MAX_VIRT_CPUS (128), we would only need to reserve 8KB
> in the guest address space. We still have plenty of space that we can afford
> reserve 8KB (the layout is described in xen/include/public/arch-arm.h). I
> would suggest to allocate the region just before the grant-table (see
> GUEST_GNTTAB_BASE).

That makes sense. So I'm now thinking of adding XENMAPSPACE_pv_time and a
new call site of xc_domain_add_to_physmap() to kick MFN allocations + P2M
setup for PV time shared regions of dynamically created domains.
Thank you for the review.

Koichiro Den

> 
> > In any case, I agree that conditional allocation would be preferable.
> 
> For XL, I would suggest to introduce a field flags in xen_arch_domainconfig
> and use one bit for enabling the PV time interface. The other bits would be
> reserved for the future (so we would need to check they are zeroes). You can
> have a look how "flags" in xen_domctl_createdomain is handled.
> 
> [...]
> 
> > > > diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/domain.h
> > > > index a3487ca71303..c231c45fe40f 100644
> > > > --- a/xen/arch/arm/include/asm/domain.h
> > > > +++ b/xen/arch/arm/include/asm/domain.h
> > > > @@ -59,6 +59,18 @@ struct paging_domain {
> > > >        unsigned long p2m_total_pages;
> > > >    };
> > > > +/* Stolen time shared memory region (ARM DEN 0057A.b) */
> > > > +struct pv_time_region {
> > > > +    /* This field must be 0 as per ARM DEN 0057A.b */
> > > > +    uint32_t revision;
> > > > +
> > > > +    /* This field must be 0 as per ARM DEN 0057A.b */
> > > > +    uint32_t attribute;
> > > > +
> > > > +    /* Total stolen time in nanoseconds */
> > > > +    uint64_t stolen_time;
> > > > +} __aligned(64);
> > > > +
> > > >    struct arch_domain
> > > >    {
> > > >    #ifdef CONFIG_ARM_64
> > > > @@ -121,6 +133,9 @@ struct arch_domain
> > > >        void *tee;
> > > >    #endif
> > > > +    struct pv_time_region *pv_time_regions;
> > > > +    gfn_t pv_time_regions_gfn;
> > > 
> > > Given the feature is 32-bit specific, shouldn't the field be protected with
> > > #define CONFIG_ARM_32?
> > 
> > Is this typo s/32/64/? Assuming so, I'll do so (=protect them with #ifdef
> > CONFIG_ARM_64) in the next iteration. Thanks!
> 
> Yes this is a typo.
> 
> Cheers,
> 
> -- 
> Julien Grall
> 


From xen-devel-bounces@lists.xenproject.org Sun Jun 29 15:41:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Jun 2025 15:41:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1028702.1402479 (Exim 4.92)
	(envelope-from )
	id 1uVu9r-0006bg-8V; Sun, 29 Jun 2025 15:41:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1028702.1402479; Sun, 29 Jun 2025 15:41:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uVu9r-0006bZ-3Z; Sun, 29 Jun 2025 15:41:31 +0000
Received: by outflank-mailman (input) for mailman id 1028702;
 Sun, 29 Jun 2025 15:41: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 1uVu9p-0006bS-KN
 for xen-devel@lists.xenproject.org; Sun, 29 Jun 2025 15:41:29 +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 7d1d5609-54ff-11f0-b894-0df219b8e170;
 Sun, 29 Jun 2025 17:41:14 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by GVXPR03MB10550.eurprd03.prod.outlook.com (2603:10a6:150:15b::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8880.27; Sun, 29 Jun
 2025 15:41:08 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%4]) with mapi id 15.20.8880.026; Sun, 29 Jun 2025
 15:41: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: 7d1d5609-54ff-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=uk/NoM38z9dFXpHZky/UIzyu1NJBm2ocfcjJfc5w0wgC6Bz4tmqPKpcVXggsNWCkyd9hZGBYtHysLJXWJIy2ZVRpLrhv/cyWLhIWz43KAhlb5SS7m7gctBtXhc38KNM6edH5WPDPwFITlm5bBF++IhZh7MYEKnp4c9ypLQq+NgEKR1Eb1z0yDrG9r0kQWuwdeGNzXJuib1phVJU9w2E5QZkByTb0yCHXTd4ETOpLBXqDz4Tn/obMd6mV1nGLk0E/FjetMSthNBOlNATit/wxKdgQtrk/kpsJ8FSc11vILUSpAJtdUp8kiyPDnwR3RhOSnyqds5D24OTKJuMtAmQXdQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=SzmRxNYkkUHTLSJsSv/wwYxBunnIlwx7nUvAmRRbiu4=;
 b=cT2gQ780t+YvBmKV1vBEvXBy8yfWEHrjabgW3qiWCfrusbUj2FYJq2MBvxo3nw0+Uk5wXDN7rCVu9pJzMDUksQgHmj5FX2JMDf7jFeizRx0sK5zz45sW3p0KnrwRPLjRQL8pVw1vE1JKv/CCU2CFREB8n+Yu/kMEbBx6OWYE75LWWMsCcW+Dxsm02e5/Wi3a7b5HndzG34/HgK63HwdRGf3F7cAQmj75DllKjhhaU8ecJRWC4VU6lTK105zOUDcYeRWKlmL88JY7Mq0v6A+ikzb/KXZ/GHTVimA2B4th7YfPtVddgh+nj4HqKKd3EIUkmdC8pq5KKH/m8p7ESsEw3w==
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=SzmRxNYkkUHTLSJsSv/wwYxBunnIlwx7nUvAmRRbiu4=;
 b=ImRPz6G10PkxJYjhYYiDXTaFuBRdmJ+j7WJ8b2KSu6qFr5JmoTNo03sa4a9hOJkM66cXfp/js9gkSyfNGIhzga/2K+2XvrDcg7oMfisYitNZ9oYOHKPiYYsABOjyVvd7n+cOtZQtcnKb7HZEiIg/PpIwP8GUJgnyW0cInm3VLFZ4yxVgOwVtcaxvJqa8nAeva33a67Zw9n0yYVA16uL9jwv5CZl8OcVjqG15JcrBTmrosBcVyCPt/aYgOdBjzUN29RCgA7pgFF2qBtCvtmEcNu7JgfWok3zF44o33mG8nYR8/lSrq6laG1099xoAWG8n2AVuys42wcr9s4EoWB3u8w==
From: Oleksii Moisieiev 
To: Julien Grall , Stefano Stabellini 
CC: "xen-devel@lists.xenproject.org" , Andrew
 Cooper , Anthony PERARD
	, Bertrand Marquis , Jan
 Beulich , Juergen Gross , Michal Orzel
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Volodymyr Babchuk ,
	Grygorii Strashko 
Subject: Re: [RFC PATCH v4 8/8] docs: armproposa: l to add separate SCMI node
 for Xen agent
Thread-Topic: [RFC PATCH v4 8/8] docs: armproposa: l to add separate SCMI node
 for Xen agent
Thread-Index: AQHb4TVhOpwmaSC7dkC7oLLOKyrberQPvwGAgACpCACAA+mNgIAADJ6AgAX31oA=
Date: Sun, 29 Jun 2025 15:41:08 +0000
Message-ID: 
References: 
 <3f7e1e99f5d1018064f3c4825aff16bd487cf558.1747669845.git.oleksii_moisieiev@epam.com>
 
 
 
 
 
 <3468bb57-3178-460b-8fb2-3ce106475319@xen.org>
 
 
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: PAVPR03MB8946:EE_|GVXPR03MB10550:EE_
x-ms-office365-filtering-correlation-id: c4222ec9-4472-4827-a790-08ddb7235ddb
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|366016|376014|7416014|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?R25OeXVhM2p5Q3pXWUJXRGFtYXQyNU96VEgrYjlud1IvdDh1aWQrK2FoeFZU?=
 =?utf-8?B?Vk1sRnZseEg2elNRak5neGJxQm16aFZJdlVYRVZORnZMQTl3cGJ0NFo5a0xT?=
 =?utf-8?B?TzcvWEZVd2hDaFlDOGFQcC9JWWRsZEdCQWpTY0REWTVuOE5WSDRENVZSZUpI?=
 =?utf-8?B?ejI5bkoxdjVEVmhnT1NrZTE3S3JCdkdFVUs1LzczR0RMbjFET1VHYmlxcXlq?=
 =?utf-8?B?bHYzMXBlalIwK2ZzK2NtSkprQ0F2OWVQVlZrcHFkQzVpa2FBV1ZSdlZvT1Bx?=
 =?utf-8?B?N0tQcWV3Y3pwYzBKdzVlZnoxZWtoS2x0elF4NDJOZVdvTUtwNVk2K1hUaEgz?=
 =?utf-8?B?WkhYK3IvYWpmSXRpN1QxK3l5d1pyRS9BZnBMUmtyMmRiNnB2eGlsUlFjR29Q?=
 =?utf-8?B?STlqNjN1THNVbDBzQ1BiNjAvZFV2Uy9VZ01pbTMwZjI0K1Myc0sxV2dKcnoy?=
 =?utf-8?B?L2xNS2Q5WG9hY3VHNUFmbmJaaVlkUkc3cmVuN1FtS1lIcWNtOFlwclN3eitp?=
 =?utf-8?B?b3ZpZkZlNGpPMXkyaVlqQ3A2cjFXbHd5NmI5dWg3MDBKWHQwUjlsNnpLQlpB?=
 =?utf-8?B?R09IaWY0T29qSnowZWFXckZFVCtDRGVXaDRNWTExZmtTSHZnM2kyeGpDczBh?=
 =?utf-8?B?NnRnM2E4NkJrazYrWXlVZ1BpNzVzU0ZaSHQxdmNmQVBheEYrb045TU1obGVJ?=
 =?utf-8?B?TkgwWGtPdFAxN0x6bk5CS053aWFBcjFOZXoycGI0Qk84aEM5djhEa3Q1MmJq?=
 =?utf-8?B?UlpJcHZjaUcyelhyd2h6TVdvczRBU2NEK1lTZDFtQW1UTTJTM0t3RFYvVUFs?=
 =?utf-8?B?REpBS1RBSnpwaVJydmp3Qk5MS1VrZVVjdmxWMmp2a09pZjZlb3E3a3JudVp3?=
 =?utf-8?B?NHN4UVQ4QWVyU2pleHVKVmRZT0VleVg4Yzlhb3NRSmVwM1Bsa3grdXE4RW5v?=
 =?utf-8?B?NkwvdjRWblQ0N3c0VTV4YjZSQ2tpZmpxVkI4SHQ4aXU0ZHAvQk8reDU4emdt?=
 =?utf-8?B?UDM5ZkpYcENZVHI3L0JZSy9tcWpYeEF2Q3U4Z2tUc0cwQldJc2FUeWdTZnJM?=
 =?utf-8?B?REpVM2FQRG5DRFB2UUc2V1V1YXBSSGZOdkxYWUNLRVlvU3BXN1ZLelVKT1d6?=
 =?utf-8?B?SUlPWHNSeEY0c1NjTG5aRXJjR0tEanJUYjMxQzZnREFWYWhwK0dYNHMzLzVR?=
 =?utf-8?B?RlRtb0VIdXRjTUlpL1pBNENRTDl5eFY0ekpZSGpMZjhIYVBta3ZCYmRzVmFv?=
 =?utf-8?B?NVI1L2tTNStyZDkyZ2hMRlJxbGZoS1d0dFd0V1VpS3FNOS9OSEx5KzkyU1pi?=
 =?utf-8?B?bzhINHlDa09DNTRackJEMC9tRUJWc1F6enJJZERZNnR2WVNCNTN1N2I2bWdN?=
 =?utf-8?B?SzVsOTM1ek5XRitJMzVtQm1IMU5GdUdBRk4vRkZTZnd6aDhCMnRoZGN6bHBI?=
 =?utf-8?B?NUFYY2xwRHlCRjU4dkcxeVVuZEQrQm9QdjBXaEVwaFc1cThOMkoyTDVtNHpm?=
 =?utf-8?B?bmo0R3dVcVEvQXRoaGMrOU9SaW9JUmo0SnFBS2VBdVVyajlZYVBJcUtsWVBu?=
 =?utf-8?B?TDhzbjR0N2tHczhkcU5yTmtUR0dtRTNDb1QrUE5ScUVEbVM3VEVQa0JqWnll?=
 =?utf-8?B?bXpYQ3ZTeldWZUxDaFgwc2pRT0VudGRxcHJsVVZmREx4MG15VEJaQVhFZDgv?=
 =?utf-8?B?S1VVZHhQZE56SEdTRmsyWjhvUFRwT0RXMG1vWTM0QXNDcVZyUEZpbVVJWEoz?=
 =?utf-8?B?dXlCQXdVRzVibGhCVzhxR2VsTUVmZ0RnNk9oa3dlYkpmL2JUcE5pcHZXc2tD?=
 =?utf-8?B?aEllWU1iNnF0ZzFxQzNSVjEzdEhxM3FqYTNob2E2R0VhVzZkdjIzZzNWTUhk?=
 =?utf-8?B?Y3M4em5HNVI4MzdGOUJabVRmMTlMMTN0aWUyN3plVEpHUEZIaWVVWnhyaEls?=
 =?utf-8?Q?8d0b4gK7M8k=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(7416014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?VEh6ZWFEUFJiNnVIbVduMEt5cDlLSlNndXdhZUZLSUdPRmIrUGowWW5DRjNQ?=
 =?utf-8?B?aFpUV0M0QUE0d0x4OFdzejFFb2NCMVpwZ2RIZ0dLc3gzVXNnWkh3T2JMaHFU?=
 =?utf-8?B?Y0Qza3dzRW5LL3QrdWh3L0R4MXl3RkdidkJaQkkyOW5QS0ZGS3pYK1dLa1cx?=
 =?utf-8?B?dHc3cUJqT0RUb2VYTEl4YVJxdytKY3d6elhZUGYzdlN6dWJwQkFUbmt1MjIx?=
 =?utf-8?B?Vkc1YkdZQUFsZU5sNDBza1lDUktXbFpIVDVHSnNjOElOOHZmREtrRUtIcmFS?=
 =?utf-8?B?NVM1dDJ3WEo0QlBxRjRNSm5OanZ3ckUvTTZPem45ZnZpbGFqNlVudFkxQXcr?=
 =?utf-8?B?V0xyUVQ3L1ZRV3Mxak1reFd6TkdJOXNVNzY2ZHE0U0dvOHBYK0JqN0pHUmJZ?=
 =?utf-8?B?UUQzbG1NWFZaVGdpc3pTSmxWUzQydXNBNXRNcndzTTdFY2Jsb29JcTJIRzll?=
 =?utf-8?B?dlVqenFkc3JJb2JxS1BRRUZmTC9qV0NmZjNPL1l3TDZNMDB2MmxVVnBYbnJr?=
 =?utf-8?B?K2ZOSnRSekNBekxHVHFXVHVNRFppMmRqYVRzQ1FQc2MrR211MHJOd0NZQUNT?=
 =?utf-8?B?VVRzWTRqd1E3dGc2VWtKUDF2R1NRS0QrSS9JeEtPa3NQOW1iZ0xOa2NlM1cw?=
 =?utf-8?B?R1VBcCtLMGJGdTJUalJhWWdEeUQrRTFxQUVnT2JmekY4TnUxNVAwMXRQaGJE?=
 =?utf-8?B?TmRvcnpZRXhqeG5WdHp4cXhBdzI3aGN5VEZuajRJRVVIM1dQa2VpREIvcVhx?=
 =?utf-8?B?ZTZIYzJtdmJNenZtZ0tPSExJRWpSTkFxTFlSekN4ak5xRlc5UzUzRC9Kb1Ba?=
 =?utf-8?B?em12VE11dC9iUzR3UHJZL1Zhc1U5VEFjc2VTT3laYkFSODBQYWxybGJ6eGQy?=
 =?utf-8?B?aEppSDFYK3U5Tyt5ZXp3b3hYb2d4Uk9DWkdFb1BxWW9GalNvZVhJdjhqL3Zy?=
 =?utf-8?B?bUNuWFZROGFySUV2YlEyeWd1VWFFNE9KTlNZY1B2ckpvNG1FWVIra0JUUm5C?=
 =?utf-8?B?Z0E3UW9KSlJOZERldzRDcG90NXVja3hMdnRiY1kwSEpaeGxnanpzZ2d1Z1dT?=
 =?utf-8?B?RzBSZW95MUVTQm5RWmNmY0c3MkxVYUorck9Fb3FySWlHSWkvcjJxRlBiRSt6?=
 =?utf-8?B?RDF3K3RpVjF3b0NSVFRiZXFMN3ZtUUdnM1pRbjdjNmJZanJFbEJTQjQvUHdl?=
 =?utf-8?B?NXdmZGlNbXprQ3BqeEdpTDBQSHdPek5yR0s0Wm1zUjZwdTgxMGw1aTA2cWRI?=
 =?utf-8?B?NWZVUURYaHlMWnNkYkNTZUQ1a0x6dFhKMnE5SzBOTVVLb1Zicm5hZ29SNlBY?=
 =?utf-8?B?M21Oa3lhbnRoZFFZRmwxWmxrV1pKUTJ5RGN4cjJwUW9qTm8ycWpGS0czbXpp?=
 =?utf-8?B?a3hhaWZXWGlBbDVlS0hCSG5jK2Y2UUdmcVVxYnBOZGw5eXNFaU1ZYUJkMkh1?=
 =?utf-8?B?UllJSkNDYkZPcVV4R1lmem1GMkIrMnUwbHE3ZFp2WTJMQWlEejFBMHRoRHlH?=
 =?utf-8?B?TENMRko1R0FMOFl6Qk5KS2Nib1Zyc3FwdEdhaS9pSnlmUXFWZ0xoU1pzNnZJ?=
 =?utf-8?B?UlhIZXY5L0YvMk1UaGVaSjZXNDc0NHBPUmVjakJRRTN0bGFwTS9zZU5ZZWRj?=
 =?utf-8?B?elBWUll0cG1ENVdRSVRFK200YXNhV3lCRlVHQlBFTjc3QW9KdGJ0a1dqY1J4?=
 =?utf-8?B?TlkxeUdtRE5oZnBoaG4rYUIrMk1xY28rSnNNbW5vbzkyblh2OFNrKzVON1di?=
 =?utf-8?B?UnRtV2grM3dCYVdQM2VRQVdjeE9sM29tdkc1b0hSZFRVcyt5OVZYUEMvdFR4?=
 =?utf-8?B?L3N2blpYRllkTXBHY0NROXZibHZ1Uk5TZ0RhMnQ4ek5KYmJmblQ0TWNTVmxB?=
 =?utf-8?B?dEpkcHJHeFlsc0FWUjNZeFE0c1hzUjJZUHBzRkE2dkROR1ZFQS9UU011aWNr?=
 =?utf-8?B?QnF2cFVCaFEzaTZmQjIrVnF3VGFTQnRObnRyeTVRaUdiQ2VFWEdiSmcwV3M5?=
 =?utf-8?B?OW52QnQxbHYvbDlKNTdlbEE1cWUreHhkandEUUI4Uk1la3VDM3owd29yVXg4?=
 =?utf-8?B?bE9YZm4wdzQ5RlB0S0FyYXdIRHk2cjlDbERpYmtPN1l2OGJqcHoxRUM4Wk1P?=
 =?utf-8?B?SkNJZ2RleU5IV1BRcVdUU2FnUm9tSWlsdU93R0hRcEVYUGtKaW96QlhyTll3?=
 =?utf-8?B?amc9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c4222ec9-4472-4827-a790-08ddb7235ddb
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2025 15:41:08.2524
 (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: 2XTaJUfG/ecnuNT/RquPEJT+/x79jJbCU6tmo96JtYzEQxZysxtmkmVuUz43HJ8xU/AYFfjivNj1KspuCT7dLl9ZRroglTygk6UxSqIxvX8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR03MB10550

DQpPbiAyNS8wNi8yMDI1IDIzOjMyLCBKdWxpZW4gR3JhbGwgd3JvdGU6DQo+IEhpIE9sZWtzaWks
DQo+DQo+IE9uIDI1LzA2LzIwMjUgMjA6NDcsIE9sZWtzaWkgTW9pc2llaWV2IHdyb3RlOg0KPj4N
Cj4+IE9uIDIzLzA2LzIwMjUgMTE6MDIsIEp1bGllbiBHcmFsbCB3cm90ZToNCj4+PiBJIGFtIHBy
b2JhYmx5IG1pc3Npbmcgc29tZXRoaW5nLiBCdXQgaXQgbG9va3MgbGlrZSBURi1BIHJlcXVpcmVz
IHRvDQo+Pj4gc3Vwb3J0IG11bHRpLWFnZW50IHNvIFhlbiBjYW4gdXNlIGl0LiBBbSBJIGNvcnJl
Y3Q/DQo+Pj4NCj4+PiBGdXJ0aGVybW9yZSwgSSBjYW4ndCB0ZWxsIHdoeSB0aGUgbXVsdGktYWdl
bnQgc3VwcG9ydCBpcyBYZW4gc3BlY2lmaWMuDQo+Pj4gU3VyZWx5LCB5b3UgbWF5IHdhbnQgc29t
ZXRoaW5nIHNpbWlsYXIgd2l0aCBvdGhlciBoeXBlcnZpc29ycz8gSWYgbm90LA0KPj4+IHRoZW4g
bXkgbmV4dCBxdWVzdGlvbiBpcyB3aHkgZG9lcyBYZW4gbmVlZHMgdG8gZG8gdGhpbmdzIGRpZmZl
cmVudGx5Pw0KPj4+DQo+Pj4gQ2hlZXJzLA0KPj4+DQo+Pg0KPj4gWWVzLCBtdWx0aS1hZ2VudCBz
dXBwb3J0IGlzIHJlcXVpcmVkIGluIFRGLUEgZm9yIFhlbiwgYnV0IHRoaXMgaXMgbm90DQo+PiBz
cGVjaWZpYyB0byBYZW4uDQo+DQo+IEkgYW0gcmVhbGx5IGNvbmZ1c2VkLiBJZiB0aGUgc3VwcG9y
dCBpcyBub3QgWGVuIHNwZWNpZmljIHRoZW4gd2h5IGRvDQo+IHdlIGVuZCB1cCB0byBoYXZlIHhl
biBzcGVjaWZpYyBub2RlL3Byb3BlcnRpZXMgaW4geW91ciBwcm9wb3NhbCAoc2VlDQo+IFsxXSkg
c3VjaCBhcyB4ZW4sc2NtaS1zZWNvbmRhcnktYWdlbnRzLg0KPg0KU29ycnksIGZvciBjb25mdXNp
b24uIFNvbWUgYWRkaXRpb25hbCBleHBsYW5hdGlvbiBpcyBiZWxvdy4NCg0KQWxsIHRoaXMgaXMg
YWJvdXQgdGhlIGNhc2Ugd2hlbiBIb3N0IHBsYXRmb3JtIGRvZXNuJ3QgaGF2ZSBTQ1AgYW5kIFND
TUkNCmltcGxlbWVudGVkIGluIEVMMiBGaXJtd2FyZSAoVEYtQSkuDQoNClRoZSBTQ01JIHN0YW5k
YXJkIGRlZmluZXMgbXVsdGktYWdlbnQgc3VwcG9ydCAoYXMgbWFueSBvdGhlciBmZWF0dXJlcyks
DQpidXQgaXQgaXMgT3B0aW9uYWwuDQpBbHNvIFNDTUkgc3RhbmRhcmQgZG9lc24ndCBkZWZpbmUg
aG93IGl0cyBmZWF0dXJlcyBoYXMgdG8gYmUgaW1wbGVtZW50ZWQNCmludGVybmFsbHksIGp1c3Qg
ZGVmaW5lcyBzdGFuZGFyZCBpbnRlcmZhY2UgKEFQSS9IQUwpIHRvIGFjY2VzcyB0aGVtLg0KTW9y
ZSBvdmVyLCBldmVuICJzaGFyZWQtcmFtIiBUcmFuc3BvcnQgaW1wbGVtZW50YXRpb24gaXMgbm90
IHN0cmljdGx5DQpzdGFuZGFyZGl6ZWQsIGZvciBleGFtcGxlIGluIHRlcm1zIG9mDQoic2hhcmVk
LXJhbSIgYmFzZSBhZGRyZXNzIGFsaWdubWVudC4NCg0KSW4gbW9zdCBvZiB0aGUgY2FzZXMsIFNv
QyBWZW5kb3JzIChpZiB3ZSBhcmUgbHVja3kpIHByb3ZpZGUgQlNQIHdpdGggRUwyDQpTQ01JIEZX
IHdoaWNoIGltcGxlbWVudHMNCm9uZSBTQ01JIHRyYW5zcG9ydCBhbmQsIHNvIHN1cHBvcnRzIG9u
bHkgb25lIEFnZW50IHdoaWNoLCBpbiBnZW5lcmFsLA0KaGFzIGFjY2VzcyB0byBhbGwgcmVzb3Vy
Y2VzLg0KU3VjaCBFTDIgU0NNSSBGVyBpcyBOT1QgdmlydHVhbGl6YXRpb24gKFhlbikgYXdhcmUs
IHNvIG9ubHkgIlNpbXBsZSBTQ01JDQpvdmVyIFNNQy9IVkMgY2FsbHMgZm9yd2FyZGluZyBkcml2
ZXIgKEVMMykiIChDT05GSUdfU0NNSV9TTUMpDQpjYW4gYmUgdXNlZCBvdXQgb2YgdGhlIGJveCB0
byBlbmFibGUgU0NNSSBpbiBIYXJkd2FyZSBkb21haW4gKG9yLCB3aXRoDQpwYXRjaGVzIDEtMyBv
ZiB0aGlzIHNlcmllcywgaW4gRHJpdmVyIGRvbWFpbikuDQoNClNvLCB0byBoYXZlIFNDTUkgbXVs
dGktY2hhbm5lbCBmZWF0dXJlcyBlbmFibGVkIHdpdGggRUwyIFNDTUkgRlcgLSBpdA0KaGFzIHNv
bWUgU0NNSSBmZWF0dXJlcyB0byBiZSBpbXBsZW1lbnRlZA0KKHdoaWNoIG90aGVyd2lzZSBvcHRp
b25hbCksIGluY2x1ZGluZyBkZWZpbmluZyBhZGRpdGlvbmFsIFRyYW5zcG9ydA0KY2hhbm5lbHMg
KEFnZW50cyksIHNobWVtIGFsaWdubWVudCBvbiBYZW4gcGFnZSBib3VuZGFyeSwuLg0KVGhlIHJl
cXVpcmVtZW50cyBmb3IgRUwyIFNDTUkgRlcgaXMgZGVzY3JpYmVkIGluIFNDTUkgZG9jdW1lbnRh
dGlvbiBbMl0uDQpBbmQgZ2VuZXJpYyBhbnN3ZXIgb24geW91ciBxdWVzdGlvbiBhYm92ZSAiSSBh
bSBwcm9iYWJseSBtaXNzaW5nDQpzb21ldGhpbmcuIEJ1dCBpdCBsb29rcyBsaWtlIFRGLUEgcmVx
dWlyZXMgdG8NCnN1cG9ydCBtdWx0aS1hZ2VudCBzbyBYZW4gY2FuIHVzZSBpdC4gQW0gSSBjb3Jy
ZWN0PyIgd291bGQgYmUgWWVzLg0KDQpbMV0NCmh0dHBzOi8vZ2l0aHViLmNvbS9vbGVrc2lpbW9p
c2llaWV2L3hlbi9ibG9iL3NjbWlfdXBzdHJ2NS9kb2NzL2h5cGVydmlzb3ItZ3VpZGUvYXJtL2Zp
cm13YXJlL2FybS1zY21pLnJzdCNzaW1wbGUtc2NtaS1vdmVyLXNtY2h2Yy1jYWxscy1mb3J3YXJk
aW5nLWRyaXZlci1lbDMNCg0KWzJdDQpodHRwczovL2dpdGh1Yi5jb20vb2xla3NpaW1vaXNpZWll
di94ZW4vYmxvYi9zY21pX3Vwc3RydjUvZG9jcy9oeXBlcnZpc29yLWd1aWRlL2FybS9maXJtd2Fy
ZS9hcm0tc2NtaS5yc3Qjc2NtaS1zbWNodmMtbXVsdGktYWdlbnQtZHJpdmVyLWVsMw0KDQoNCg0K
DQotLS0tLQ0KU0NNSSBTQ1AgTm90ZS4gV2hlbiBIb3N0IHBsYXRmb3JtIHN1cHBvcnQgU0NQIHRo
ZSBtdWx0aS1hZ2VudCBzdXBwb3J0DQp3aWxsIGJlIGluIHBsYWNlLCBhcw0KaW4gc3VjaCBjYXNl
cyBzZXBhcmF0ZSBTQ01JIHRyYW5zcG9ydCBpcyBhbGxvY2F0ZWQgZm9yIGF0IGxlYXN0IGVhY2gN
CkFwcGxpY2F0aW9uIHByb2Nlc3NvciAoQVApIHdoaWNoIGlzIGRlZmluZWQgYXMgU0NNSSBBZ2Vu
dC4NCkZvciBleGFtcGxlLCBDb3JlLVIocykgKGxpa2UgQ29ydGV4LVIvTSksIERTUHMsIENvcmUt
QSAoQ29ydGV4LUEgLSBoZXJlDQp0aGUgWGVuIGlzIHVzdWFsbHkgcnVubmluZykuDQpObyBBZ2Vu
dHMgaW4gdGhlIHN5c3RlbSBrbm93cyBhYm91dCBlYWNoIG90aGVyLiBPbmx5IFNDUCBGVyBkb2Vz
Lg0KDQpBbmQgZXZlbiBpbiB0aGlzIGNhc2UsIHRoZSBCU1AgU0NQIEZXIG1pZ2h0IE5PVCBiZSB2
aXJ0dWFsaXphdGlvbiAoWGVuKQ0KYXdhcmUgYXMgb25seSBvbmUgVHJhbnNwb3J0IChBZ2VudCkN
CmlzIHByb3ZpZGVkIGZvciBDb3JlLUEgKGFjdHVhbGx5IHR3byAtIG9uZSBTZWN1cmUgZm9yIFBT
Q0ksIGFuZCBvbmUNCm5vbi1zZWN1cmUgLSBmb3IgT1NQTSkuDQotLS0NCg0KSW4gdGhlIFZpcnR1
YWxpemVkIHN5c3RlbToNCg0KLSBUaGUgWGVuIGlzIHJlYWwgT1NQTSB3aGljaCBtYW5hZ2VzIG90
aGVyIFZpcnR1YWwgT1NQTSBhbmQgaXQgbmVlZHMNCmRlZGljYXRlZCBTQ01JIG1hbmFnZW1lbnQg
Y2hhbm5lbCB0aHJvdWdoIHdoaWNoDQogIGl0IGNhbiBwZXJmb3JtIEhXIHJlc291cmNlcyBhc3Np
Z25tZW50IGZvciBWaXJ0dWFsIE9TUE0gYnkNCmNvbW11bmljYXRpbmcgd2l0aCBFTDIgU0NNSSBG
Vw0KICBkdXJpbmcgVmlydHVhbCBPU1BNIGNyZWF0aW9uIG9yIHJlbGVhc2UgSFcgcmVzb3VyY2Vz
IGR1cmluZyBWaXJ0dWFsDQpPU1BNIGRlc3RydWN0aW9uLg0KICBJbiB0aGUgZnV0dXJlIGl0IGFs
c28gcG9zc2libGUgdG8gZW5hYmxlIHN1Y2ggUE0gZmVhdHVyZSBhcyBTQ01JIGJhc2VkDQpDcHVG
cmVxIGluIFhlbi4NCg0KICBUaGUgU0NNSSBEVCBiaW5kaW5nIGZvciBYZW4gU0NNSSBBZ2VudCBl
eHBlY3RlZCB0byBiZSBleGFjdGx5IHRoZSBzYW1lDQphcyBmb3IgYW55IE9TUE0gKGxpa2UgTGlu
dXgpIGFzIGZyb20NCiAgU0NNSSBGVyBwb2ludCBvZiBmZXcgaXQgaXMganVzdCBPUyBydW5uaW5n
IG9uIEFwcGxpY2F0aW9uIENvcmUgKHdoaWNoDQpzdWJzdGl0dXRlcyByZWd1bGFyIE9TIC0gTGlu
dXgsIFJUT1MpLg0KICBTbyBubyBuZXcgU0NNSSBzcGVjaWZpYyBiaW5kaW5ncyAoaW5jbHVkaW5n
IGNvbXBhdGliaWxpdGllcykNCmludHJvZHVjZWQgbmVpdGhlciBpbiB0aGlzIHNlcmllcyBub3Ig
aW4gdGhpcyBwcm9wb3NhbC4NCg0KICBJbiBvdGhlciB3b3JkcywgWGVuIG5lZWRzIHR3byBEVCB0
byBib290LCBraW5kYToNCiAgLSBYZW4gRFQgKHdpdGggYm9vdGluZm8sIEFwcGxpY2F0aW9uIENv
cmUgaW5mbywgdWFydCkNCiAgLSBIb3N0IFBsYXRmb3JtIERUIChzb3VyY2UgaW5mb3JtYXRpb24g
dG8gY3JlYXRlIGRvbWFpbnMpDQogICBhbmQgaWYgdGhlcmUgd291bGQgYmUgdHdvIHNlcGFyYXRl
IERUcyAtIGVhY2ggd2lsbCBoYXZlIG93biBzdGFuZGFyZA0KKGJpbmRpbmdzKSBEVCBTQ01JIG5v
ZGUuDQpBY2NvcmRpbmcgdG8gdGhlIGN1cnJlbnQgZGVzaWduIFhlbiBhY2NlcHRzIERUIHdoaWNo
IGlzIEhvc3QgUGxhdGZvcm0gRFQNCndpdGggYWRkZWQgWGVuIGNvbmZpZ3VyYXRpb24gc28gWGVu
IFNDTUkgaW5mbyBpcyBhZGRlZCBpbiBYZW4NCmNvbmZpZ3VyYXRpb24gbm9kZSB1bmRlciAvY2hv
c2VuLCBhbmQgbm8gRG9tYWlucyBpcyBleHBlY3RlZCB0byBzZWUgaXQNCmV2ZXIuIEFmdGVyIFhl
biBpbml0aWFsaXphdGlvbiBEVCBub2RlcyBmcm9tIFhlbiBEVCBhcmUgY29waWVkIHRvIHRoZQ0K
RG9tMCBkZXZpY2UgdHJlZS4gT3VyIHByb3Bvc2FsIGlzIHRvIGtlZXAgU0NNSSBjb25maWd1cmF0
aW9uIGZyb20NClBsYXRmb3JtIEhvc3QgRFQgdGhlICBzYW1lIHNvIGl0IHdpbGwgYmUgY29waWVk
IHRvIHRoZSBEb20wIGRldmljZSB0cmVlLg0KDQoNCi0gdGhlIG51bWJlciBvZiBWaXJ0dWFsIE1h
Y2hpbmVzIG9yIFZpcnR1YWwgT1NQTXMgKGluIHRlcm1zIG9mIFNDTUkpDQpkZXBlbmRzIG9uIGh5
cGVydmlzb3IgKFhlbikgY29uZmlndXJhdGlvbi4NCiAgQW5kIFZpcnR1YWwgT1NQTSBpcyBkZWZp
bmVkIGFzIFZNIHdoaWNoIGhhcyBkaXJlY3QgYWNjZXNzIHRvIEhXDQoocGFzc3Rocm91Z2gpLCBz
byBuZWVkIGFjY2Vzcw0KICBTQ01JIHNlcnZpY2VzIHRvIGdldCBmaW5lLWdyYWluZWQgYW5kIHNh
ZmUgYWNjZXNzIHRvIHJlcXVpcmVkIFBsYXRmb3JtDQpIVyByZXNvdXJjZXMsIGFuZCBhdm9pZCBp
bnRlcmZlcmVuY2UuDQoNCiAgRXZlcnkgVmlydHVhbCBPU1BNIGlzIFNDTUkgYWdlbnQsIHdoaWNo
IHNlZXMgaXQncyBvd24gU0NNSSB0cmFuc3BvcnQsDQphbmQgZG9lc24ndCBrbm93IGFib3V0IG90
aGVyIGFnZW50cy4NCiAgSW4gdGhlIGNhc2Ugb2YgRFQgLSB0aGUgc3RhbmRhcmQgU0NNSSBiaW5k
aW5ncyBhcmUgdXNlZC4NCg0KLSBTbyB0aGUgWGVuIGlzIHRoZSBvbmx5IGVudGl0eSBpbiB0aGUg
cGxhdGZvcm0gd2hpY2ggbmVlZCB0byBrbm93IGFib3V0DQpvdGhlciBBZ2VudHMuDQogICBUaGVy
ZWZvcmUsIHRoaXMgWGVuIHNwZWNpZmljIGNvbmZpZ3VyYXRpb24gInhlbixzY21pLXNlY29uZGFy
eS1hZ2VudHMiLA0KICAgZm9yIHRoZSBjYXNlIG9mIHRoZSBFTDIgU0NNSSBGVywgaXMgaW50cm9k
dWNlZCBhbmQgYWRkZWQgdW5kZXIgdGhlDQovY2hvc2VuIG5vZGUgKG9yIHhlbi1jb25maWcpLg0K
ICAgVW5mb3J0dW5hdGVseSwgdGhlcmUgaXMgbm8gd2F5IHRvIGRpc2NvdmVyIEFnZW50J3MgY29u
ZmlndXJhdGlvbnMNCnVzaW5nIFNDTUkgcHJvdG9jb2wgKGJhc2UpLCBsaWtlICJmdW5jLWlkIg0K
ICAgYW5kIHNobWVtIHBhcmFtZXRlciAob25seSBjYW4gZ2V0IE51bWJlciBvZiBBZ2VudHMsIGFu
ZCBkaXNjb3ZlciBvd24NCkFnZW50IGlkKSwgc28gb25seSBvcHRpb24gaXMgdG8NCiAgIGRlZmlu
ZSB0aGlzIGluZm8gaW4gRFQgZm9yIFhlbi4gSG93ZXZlciwgWGVuIGNhbiB1c2Ugc2hhcmVkIG1l
bW9yeQ0KcmVnaW9ucyBhbmQgZnVuY19pZHMgb2YgdGhlIG90aGVyIEFnZW50cyB0byAgIGRldGVy
bWluZSBhZ2VudF9pZCB1c2luZw0KYmFzZSBwcm90b2NvbC4gVGhhdCdzIHdoeSBpdCB3YXMgZGVj
aWRlZCB0byBtYWtlIGFnZW50X2lkIGluDQoieGVtLHNjbWktc2Vjb25kYXJ5LWFnZW50cyIgb3B0
aW9uYWwuDQo+IEkgYWxzbyBxdWVzdGlvbiB0aGUgcGxhY2VtZW50IG9mIHRoZSBTTUNJIG11bHRp
LWFnZW50IGluIC9jaG9zZW4uIEZvcg0KPiBtZSAvY2hvc2VuIGlzIGZvciBjb25maWd1cmF0aW9u
IHJlbGF0ZWQgdG8gdGhlIGh5cGVydmlzb3IvT1MuIEJ1dA0KPiBoZXJlLCBpdCBzZWVtcyB0aGUg
bXVsdGktYWdlbnQgU01DSSBpcyByZWxhdGVkIHRvIHRoZSBwbGF0Zm9ybS4NCj4NCg0KIEZyb20g
U0NNSSBwb2ludCBvZiB2aWV3IHRoZSBYZW4gaXMgc2VwYXJhdGUgT1NQTSAoU0NNSSBBZ2VudCks
IHdoaWNoDQpoYXZlIG93biBib290IGNvbmZpZ3VyYXRpb24gZGF0YSwgaW4gY2FzZSBvZiBBUk0g
LSBEZXZpY2UtdHJlZS4NClRoZSBTQ01JIGRvZXNuJ3Qgc2VlIHRoZSBkaWZmZXJlbmNlIGJldHdl
ZW4gTGludXggb3IgWGVuIHJ1bm5pbmcgb24NCkFwcGxpY2F0aW9uIHByb2Nlc3Nvci4NClRoZXkg
YXJlIGJvdGggT1NQTSAoQWdlbnRzKSwgYnV0IHdpdGggZGlmZmVyZW50IHByaXZpbGVnZXMgYW5k
IHBlcm1pc3Npb25zLg0KDQpBcyB3YXMgc3RhdGVkIGJlZm9yZSBmcm9tIFhlbiBzdGFuZHBvaW50
IHRoZSBkZXZpY2UgdHJlZSBzaG91bGQgYmUgc2FtZQ0KYXMgSG9zdCBEVCB3aXRoIFhlbg0KY29u
ZmlndXJhdGlvbiBwbGFjZWQgdW5kZXIgL2Nob3NlbiBub2RlLiBTbyBhZ2VudF9pZCBkZWRpY2F0
ZWQgdG8gWGVuDQpzaG91bGQgYmUgaW4geGVuIGNvbmZpZ3VyYXRpb24gbm9kZS4NCg0KVGhlIEhv
c3QgcGxhdGZvcm0gKEJTUCkgd2lsbCBydW4gdXNpbmcgSG9zdCBEVCB3aXRoIFhlbiBEVCBkYXRh
IHJlbW92ZWQgYW5kDQpkb2Vzbid0IG5lZWQgdG8ga25vdyBhYm91dCBYZW4gU0NNSSBtYW5hZ2Vt
ZW50IGNoYW5uZWwgKGFnZW50KSBvciBhZ2VudHMNCmF2YWlsYWJsZSBmb3IgVmlydHVhbCBPU1BN
cyAoVk1zKS4NCg0KRm9yIFhlbiB0byBydW4gd2l0aCBTQ01JIG11bHRpLWNoYW5uZWwgc3VwcG9y
dCAtIFhlbiBzcGVjaWZpYyBEVCBkYXRhIGhhcw0KdG8gYmUgYWRkZWQgdW5kZXIgL2Nob3NlbiB3
aGljaCBpbmNsdWRlcyBYZW4gc3BlY2lmaWMgU0NNSSBkYXRhLg0KPiBTbyB3b3VsZG4ndCBpdCBi
ZSBiZXR0ZXIgdG8gY3JlYXRlIGEgbmV3IGNvbXBhdGlibGUgYXJtLHNtY2ktbXVsdGkNCj4gdGhh
dCB3aWxsIGluY2x1ZGUgdGhlIGluZm9ybWF0aW9uIGZvciBtdWx0aT8gQW4gYWx0ZXJuYXRpdmUg
d291bGQgYmUNCj4gdG8gZXh0ZW5kIHRoZSBleGlzdGluZyBTQ01JIG5vZGUgaW4gYSBiYWNrd2Fy
ZCBjb21wYXRpYmxlIHdheS4NCj4NCj4gTGFzdGx5LCBJIHNlZSBpZiB5b3UgcHV0IGEgbm9kZSB1
bmRlciAiL2Nob3NlbiIgd2l0aCAiYXJtLHNjbWktc21jIi4NCj4gSGF2ZSB5b3UgY2hlY2tlZCB0
aGlzIHdpbGwgbm90IGNvbmZ1c2VkIExpbnV4PyBJIHdhcyB1bmRlciB0aGUNCj4gaW1wcmVzc2lv
biBMaW51eCB3b3VsZCBsb29rIGZvciBhbnkgbm9kZSB3aXRoIHRoZSBjb21wYXRpYmxlIHdoZW4N
Cj4gaW5pdGlhbGl6aW5nIGEgZHJpdmVyLg0KPg0KWGVuIGNvbmZpZ3VyYXRpb24gdW5kZXIgL2No
b3NlbiB3aWxsIGJlIHJlbW92ZWQgd2hlbiBwYXNzaW5nIERUIHRvIHRoZQ0KRG9tYWlucy4NClNv
IExpbnV4IGRvbWFpbnMgd2lsbCBub3Qgc2VlIGFueSBYZW4gY29uZmlndXJhdGlvbiBkYXRhLg0K
DQpXaGVuIGJvb3RpbmcgQmFyZW1ldGFsIFhlbiBEVCBMaW51eCBrZXJuZWwgd2lsbCBub3QgcGFy
c2UgImFybSxzY21pLXNtYyINCm5vZGUgdW5kZXIgImNob3NlbiIgIGFzIExpbnV4IHVzZXMgMiBk
ZXB0aCBsZXZlbCBmb3IgcHJvYmluZy4NCkFuZCB0aGVyZSBpcyBubyBjb21wYXRpYmxlIGluIGNo
b3NlbjoNCg0Kew0KICAgIGNob3NlbiB7DQogICAgIC8vIG5vIGNvbXBhdGlibGUgLSBza2lwDQog
ICAgIHhlbi1jb25maWcgew0KICAgICAgICAgY29tcGF0ID0gInhlbixjb25maWciOyA8LSBubyBn
byBiZWxvdyBhcyBub3QgQnVzIGNvbXBhdA0KICAgICAgICAgc2NtaSB7DQogICAgICAgICAgICAg
PC1uZXZlciBnZXQgaGVyZQ0KICAgICAgICAgfQ0KICAgICB9DQogICAgfQ0KfQ0KDQo+IENoZWVy
cywNCj4NCj4gWzFdDQo+IGh0dHBzOi8vbGlzdHMueGVucHJvamVjdC5vcmcvYXJjaGl2ZXMvaHRt
bC94ZW4tZGV2ZWwvMjAyNS0wNi9tc2cwMTQyMS5odG1sDQo+DQo+DQo=


From xen-devel-bounces@lists.xenproject.org Sun Jun 29 18:35:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Jun 2025 18:35:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1028745.1402488 (Exim 4.92)
	(envelope-from )
	id 1uVwrW-0001Og-1E; Sun, 29 Jun 2025 18:34:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1028745.1402488; Sun, 29 Jun 2025 18: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 1uVwrV-0001OZ-Un; Sun, 29 Jun 2025 18:34:45 +0000
Received: by outflank-mailman (input) for mailman id 1028745;
 Sun, 29 Jun 2025 18:34:44 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uVwrU-0001OS-S1
 for xen-devel@lists.xenproject.org; Sun, 29 Jun 2025 18:34:44 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uVwrT-008jCP-2z;
 Sun, 29 Jun 2025 18:34:43 +0000
Received: from [2a02:8012:3a1:0:d050:4cf0:af44:4b0]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uVwrT-005gdx-1n;
 Sun, 29 Jun 2025 18:34: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" 
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=cJHHJpg3P2YjWBsr5KnOK6Po8+s5KsXgWgo/4gZ7VhY=; b=M4yV8Px1LL8kXqhztXX0RFVHFK
	AuO5OtX2JpzPSyE41G72m8iGVDvnRGjxW4IpY3vQpWlDbK2hk42bqtIbAG/BFKUPvRPIvluVom1ir
	259hdbPUDn25fyXkXBJ5Hsbpq5C7jDAw93+zC8otC1ixJ7JEeXNbwObUptsiY0GyS5VM=;
Message-ID: <41566d23-464b-4676-8e01-e2f27d377a94@xen.org>
Date: Sun, 29 Jun 2025 19:34:41 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v4 8/8] docs: armproposa: l to add separate SCMI node
 for Xen agent
Content-Language: en-GB
To: Oleksii Moisieiev ,
 Stefano Stabellini 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper ,
 Anthony PERARD ,
 Bertrand Marquis , Jan Beulich
 , Juergen Gross ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Volodymyr Babchuk ,
 Grygorii Strashko 
References: 
 <3f7e1e99f5d1018064f3c4825aff16bd487cf558.1747669845.git.oleksii_moisieiev@epam.com>
 
 
 
 
 
 <3468bb57-3178-460b-8fb2-3ce106475319@xen.org>
 
 
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Oleksii,

On 29/06/2025 16:41, Oleksii Moisieiev wrote:
 > --->
> In the Virtualized system:

Thanks for the long explanation. In this section, you mention Xen all 
over the place. But as you previously agreed the multi-agent SCMI is not 
Xen specific. To put it differently, aside the fact...

> 
 > - The Xen is real OSPM which manages other Virtual OSPM and it needs> 
dedicated SCMI management channel through which
>    it can perform HW resources assignment for Virtual OSPM by
> communicating with EL2 SCMI FW
>    during Virtual OSPM creation or release HW resources during Virtual
> OSPM destruction.
>    In the future it also possible to enable such PM feature as SCMI based
> CpuFreq in Xen.
> 
>    The SCMI DT binding for Xen SCMI Agent expected to be exactly the same
> as for any OSPM (like Linux) as from
>    SCMI FW point of few it is just OS running on Application Core (which
> substitutes regular OS - Linux, RTOS).
>    So no new SCMI specific bindings (including compatibilities)
> introduced neither in this series nor in this proposal.
> 
>    In other words, Xen needs two DT to boot, kinda:
>    - Xen DT (with bootinfo, Application Core info, uart)
>    - Host Platform DT (source information to create domains)
>     and if there would be two separate DTs - each will have own standard
> (bindings) DT SCMI node.
> According to the current design Xen accepts DT which is Host Platform DT
> with added Xen configuration so Xen SCMI info is added in Xen
> configuration node under /chosen, and no Domains is expected to see it
> ever. After Xen initialization DT nodes from Xen DT are copied to the
> Dom0 device tree. Our proposal is to keep SCMI configuration from
> Platform Host DT the  same so it will be copied to the Dom0 device tree.
> 
> 
> - the number of Virtual Machines or Virtual OSPMs (in terms of SCMI)
> depends on hypervisor (Xen) configuration.
>    And Virtual OSPM is defined as VM which has direct access to HW
> (passthrough), so need access
>    SCMI services to get fine-grained and safe access to required Platform
> HW resources, and avoid interference.
> 
>    Every Virtual OSPM is SCMI agent, which sees it's own SCMI transport,
> and doesn't know about other agents.
>    In the case of DT - the standard SCMI bindings are used.
> 
> - So the Xen is the only entity in the platform which need to know about
> other Agents.
>     Therefore, this Xen specific configuration "xen,scmi-secondary-agents",
>     for the case of the EL2 SCMI FW, is introduced and added under the
> /chosen node (or xen-config).
>     Unfortunately, there is no way to discover Agent's configurations
> using SCMI protocol (base), like "func-id"
>     and shmem parameter (only can get Number of Agents, and discover own
> Agent id), so only option is to
>     define this info in DT for Xen. However, Xen can use shared memory
> regions and func_ids of the other Agents to   determine agent_id using
> base protocol. That's why it was decided to make agent_id in
> "xem,scmi-secondary-agents" optional.


... the name of this property contains "xen", I still don't understand 
why the binding could not be used by other hypervisors. IOW, what if 
above you s/xen/KVM/ (or any other hypervisor you come up with)? Are 
they all going to create their own bindings? I would guess not given the 
single agent is already generic (if I am not mistaken, both Linux and 
Xen are using it)

I will not insist on moving the binding outside of /chosen if the other 
maintainers think this is the best. But I think this is shortsighted to 
add "xen" in all the name or put it in a Xen specific position.

Ultimately what I want to avoid is we have to support multiple bindings 
in Xen because someone else decided to create a new binding as we didn't 
even attempt to make ours generic...

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Mon Jun 30 03:09:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 03:09:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1028815.1402498 (Exim 4.92)
	(envelope-from )
	id 1uW4tX-0006wI-Do; Mon, 30 Jun 2025 03:09:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1028815.1402498; Mon, 30 Jun 2025 03:09:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uW4tX-0006wA-6f; Mon, 30 Jun 2025 03:09:23 +0000
Received: by outflank-mailman (input) for mailman id 1028815;
 Mon, 30 Jun 2025 03:09:21 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uW4tV-0006vH-Cf
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 03:09:21 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20600.outbound.protection.outlook.com
 [2a01:111:f403:2415::600])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9c77e34b-555f-11f0-a312-13f23c93f187;
 Mon, 30 Jun 2025 05:09:19 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 SA1PR12MB6894.namprd12.prod.outlook.com (2603:10b6:806:24d::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8880.27; Mon, 30 Jun
 2025 03:09:15 +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.8880.030; Mon, 30 Jun 2025
 03:09: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: 9c77e34b-555f-11f0-a312-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=U5uaPrT0C6oLiDedfc/vhHfJbmINuzz+eksGe2QEQ8n4ji34dLi+4uSV26uZapgfY7NVi5JBXw5z7oC7Pf2Y9UfCRHLPCwlNKTQsyWwlSgiI1CP2rVwbEfgNqwuWISi2TO9VjbjGhYXzDWoTN15RmQP8IozM0r3Sof5ZqtUER6tZbW2nujr7/4abdclCguAU6ruK3zwu+Wyg7oX3YW/NBLbjvFNy4EIFBpjqqM/ACN8IkVM8jq7b/4oBqdAyP5KRoQwq5Pzdw5iMWF7JpqONeNfGb9yBpLngJ2QdZIFW5vgEBtr0XFQS69WDG6ARDKndzPdwf6OQteYsVoLqwipWVQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=eyxTUt46OegQF9TSMWc5zsM2ga42KdNWQo/TuuOPKgw=;
 b=gXLfUVptOwWtUBda4GBz84w/5dTGhPLBxv0zc9YVk5suSa/WpWN+hGYDnsENuOTY8V5N6ROPvnVEOmUgUuuU9ryjgEl3rHq/5m0Kkcir+fTrl24zTcSngNRQL8jtfU+Gp6a+94oBodEaj4jwYAeggSQ+Vv3Jw52PkRYk2efhcxClPA6mQjiTKlzSnhGRiSBmoboE4Bhos4K1Hs70DghooVukRuVliithrUzdbPNoqgQUIl62nvdLR3mRNMuHQmykJJ2B+8M/hNYOsgho8OiEvPOfUi2aq4xRKQPx5oHg3mUsCqRVkK7QchiV0cFgunq6UUD0it0rjBYJtEDoHtkQ+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=eyxTUt46OegQF9TSMWc5zsM2ga42KdNWQo/TuuOPKgw=;
 b=IFAQbJwRK1LKv3dNz9AWKlCy0PkPSspTbcueQ7JUpb11jIaDLBv888x/36MyNUSE5B2Bm6f4RL2qrJ04FFBLEiEZIN6jufPPKc49PHHQKj4lsyOoxvehd/lCI1BAFuasEmJhYJmyz/qazRXAZESkFd9LivY8IQfR6n6fEPI/vUM=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Andrew Cooper
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Anthony PERARD , "Orzel,
 Michal" , Julien Grall , Stefano
 Stabellini , "Daniel P. Smith"
	, Dario Faggioli , Juergen
 Gross , George Dunlap , Nathan Studer
	, Stewart Hildebrand ,
	Bertrand Marquis , Volodymyr Babchuk
	, Alistair Francis ,
	Bob Eshleman , Connor Davis ,
	Oleksii Kurochko ,
	"xen-devel@lists.xenproject.org" ,
	"xen-devel@dornerworks.com" 
Subject: RE: [PATCH v5 00/18] xen: introduce CONFIG_SYSCTL
Thread-Topic: [PATCH v5 00/18] xen: introduce CONFIG_SYSCTL
Thread-Index: AQHb3onFdnXviGLMzkyWb5d6+OoXc7QVpzqAgAV0OGA=
Date: Mon, 30 Jun 2025 03:09:15 +0000
Message-ID:
 
References: <20250616064128.581164-1-Penny.Zheng@amd.com>
 <2e35ed6d-f9a5-48c7-8e81-6f5daa5c16d7@suse.com>
In-Reply-To: <2e35ed6d-f9a5-48c7-8e81-6f5daa5c16d7@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=True;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-06-30T03:08:43.0000000Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=3;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged
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_|SA1PR12MB6894:EE_
x-ms-office365-filtering-correlation-id: f561c940-eb19-46a6-1d16-08ddb7837ef2
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|366016|1800799024|7416014|376014|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?dWd4Y2VkbThxNVRRL1VIRXRRK29jajE1SitIN0dSS0ZFK2FCQUltcWZTVE5q?=
 =?utf-8?B?aEEzNUNiMlRKUWdrS2o3VGZOSGFCczFUMER2emRaMlV3SWxCTXRHYnkzSEZ4?=
 =?utf-8?B?c0pTVXEzdE5MZG1rL0VSV2NReGI5M0VuSUsxNHY1MWxiRHpKYUUreTVHRW0w?=
 =?utf-8?B?RW5zZVFRUXJyOEhZbXUzUTZJWWpuOXVuK3ZXRE1TNE1rdjRpQzJZeWZGcFRV?=
 =?utf-8?B?Y3d4TUptejU4UXkvMnMxMXZiajNGZGNQcnhiT0ZrcGpSVkM0NFZWSUZUY2RL?=
 =?utf-8?B?K3poTHhvNEFrZndiUTZQRGJPRiszNWlFU2VBc1E5UFJXSXZlRGRWdTNZNnA5?=
 =?utf-8?B?VDBnMlJ0MExNQi9LOUNuM0J0NVo4dURrV0hMQnlRelV5ekRDZmZnRXdrbWVK?=
 =?utf-8?B?bUhQeG1KMU5mR3pNMGV5VmcwWHNzN0lUajNwN0FhQXNNRWtRUGFoZ2RkV21D?=
 =?utf-8?B?MTB1OEkzWUVoQWlHcU9QREJ5NTdyQm5YYWRUd1Bxc0oveHJJbkJFdkdjZGd4?=
 =?utf-8?B?RzE5ekJNbXVPemVvUVpuUkwwZSttV3Jac01BbTJ1Yk14azQ2V2VWWkFlbTg4?=
 =?utf-8?B?RDUrKzNRSzRuR1h3Q0JMLzkyQ3F3a2NNamFPMGxNaXRIWFlmckdjdXljRFZO?=
 =?utf-8?B?NWV3RjJIRE9uVzRaVnJ2UFR0ZVlvaGhOS0RNOTJmaVFqWXY2cFZ0Zmtmdm0r?=
 =?utf-8?B?Y3NTblR1ZjBxQ0ZBaDMrR1VEVmxQaGtRRGtmbVRYOVlzdkhaVUhQNTJ0d0hy?=
 =?utf-8?B?ckNLUWVoaE5XOEJIUkxMR1liSmcxdVZ0RkpEWWdRNE1HZlBrR1NDRE5uUUdz?=
 =?utf-8?B?UEgwZFR3WW5uR2R3Sm9wVitGZHd4UzlBT0RQN2R5M2hrbHJzVkc4eWFFbEtR?=
 =?utf-8?B?OXNia0FlT29zU3NOUlBqNlk1MDloaE9KNmRTT29ZN3YvTGpKTktoVTcydVlv?=
 =?utf-8?B?NEVPRVFiSkw3K081bWd6YldFSlZEQWpudnFvVS9TUlRaeHR0ZDhFZ21LWnky?=
 =?utf-8?B?TDhmcWRIMHhkMUZRY1hZU0xES1MwMXFhSytiM282eXpjVEZLeHFMemcvUzF5?=
 =?utf-8?B?cGNadE9veVViNWxMekhieDg4SXVHQ2tNWE5rS05pTWdxYnpFZDArTmZjamIz?=
 =?utf-8?B?ZHBYUDdjcTJocS9KZEF0bm1wUndZWHJPZUNDSU54N3lOZDc0dzdGYzFzL3N5?=
 =?utf-8?B?WE0vVlYxNGVEc3Y3SXBtZDNIY3V2ODF6SXNCSjV0QXZ6c1grN0xkUm81MmRP?=
 =?utf-8?B?QVVNaFp0YTlWQjVhMlhueldhOUEvNXZCYWFOaW91STczWFZFU0x0aG5BV0VU?=
 =?utf-8?B?elJ2N3hUeFJzRXNpYmkrdGVWSGVYdUd3Qm5QTVJLTEs4cEJvNjQ1TnhKNVdw?=
 =?utf-8?B?K2U5QURLSzFhTmlzRU5IWlVNSkVhTmorOGxaelpyVlBmVE9KaEVGdlVwWHhw?=
 =?utf-8?B?UFRxcGNJcm1MVTYzTzRjSmFXY3IyQWNCTnF2a2tjbGdzNHExZjRVRnZ4UmRu?=
 =?utf-8?B?QUV5YVRoMTJXaTZBSkR3RW1TN2xNRG0zWlRyZ2pKOEJVd2hLcGVVS09vNDRr?=
 =?utf-8?B?clo3eGhCUXlaZ29yTXZPOGxkb0sydDI3M3RKblFaL0gydDM5aTFTb29yTXgw?=
 =?utf-8?B?SlFuWmxvVW9Uc3A4Rmhzak95ZXFpWVlDbTNsN0pMV0pXc1pzWnlSL2g0UnNM?=
 =?utf-8?B?REpqQWFBN1RGbW1Qb3Q5K2E4K3g1bklHejdvbXZCUzJQMUpHelNDNkQyUEJy?=
 =?utf-8?B?S2dJQjlXVzVoU3Z6TGVjOUdhS1ZNeWxMZGQxRkJjSnhUdXFBUXk2NkhoQ29r?=
 =?utf-8?B?eDk2YkJZSUdlQWlEU2p5a2ZKcW1QSjlEOTNoV29LNVdIVDNvV0tjUXoyeTZD?=
 =?utf-8?B?WXhzM0hoMDhMaW96d3BPd05tN2dhVENtQmdoRGdUU3dPcTZXQ2FwWjlVRnFY?=
 =?utf-8?B?RE1RK3VIcHZJZDhDUjdGc2lQSFI2TU1lZEFYNkh1ajNCY3FuRXVxMzlBVWdK?=
 =?utf-8?Q?r4ojxQY8iSpL4xpnTEumheSOOY3APk=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)(7416014)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?c2p4MXdNdjR2S014dmRkb1BkTmkzMFVuajJnMDk4MzMweWYzZ1YvMlZxYzF5?=
 =?utf-8?B?SEN6ZDhldXgyTWlCUTRxckdLSnh3VlR1clJQSnU0ZUdEaVFEc3dod0JUZ3A2?=
 =?utf-8?B?Mi9JR1RXczEvb1ZuNEFqV2xaQTZXdFpwaTl0N2U0RkkvMlhha1pZTzN2MEta?=
 =?utf-8?B?UXRzdkI5c3ZCb1hndXA2ZXErTERsUEN5U2dielVqMDUyWVJUQXRhbjBLbkgx?=
 =?utf-8?B?ZS9uUzBiWHpDbC9KVm5YUklzMkUza2Fta3A4K2RRdFQrZzloNmpOa0dObm5v?=
 =?utf-8?B?ZmlGSWZoZGlpOXBnZjB4eDVlcUhiVk9kY2JWVy92Sk16aDVRVWVFNk4xTUlz?=
 =?utf-8?B?OEpZZjQ1aXZxRkxXejV5MVQ0Z3BFRE9odEdLandpdExremQyM0VsdDcwNndU?=
 =?utf-8?B?UVpLeFFyZFVaUytIZ1VKVzh0VXdLTmtKUjBTRS9LckwranJrang3Z2J6Q2s0?=
 =?utf-8?B?WlVyZ3dlcTRGREFQMys1N3JGQ3QwTkVZOGczZzBYcGEwZjNuQWFXRHlpSjVl?=
 =?utf-8?B?bkZneHZ2WE5oQ09DNE9WQW9CTGp1cWtwMFZMbEZIenBVN3ZWRU9SMHVhK21M?=
 =?utf-8?B?UEcxMTFqcUZSMHowd1ZyOTZxdFA5d2FkK2plQmViUktvZ1VBOVF3eTl4Q0hE?=
 =?utf-8?B?djFvdVk5bGZndFBabjdaQ0o3TXIzY3FwSkcyNTExSUZDcE90TldBMEFHbEFO?=
 =?utf-8?B?aE12dlNrbExPb016cEFjN2J3V29DTGxZY0xKU1RiZkt0WlZWUWgwMWRMbkk5?=
 =?utf-8?B?UHhQRThZdkhGQnZobCtNeDZXNk9qaFk1OTlnTUtibTdUUGJxMnpPZnJqb0hJ?=
 =?utf-8?B?eWlQWU9WYlBJanNUQlEvWGIxZkV0TUczZzFOVTR6aGFCMTl3RlRhWjM5UWJq?=
 =?utf-8?B?VmoyT1NiV2F0UVJHOWIzZDhRMWZTUzhTY0JYYVN3ZUNQMndKVndMQ3A1bTd2?=
 =?utf-8?B?T3FOSGxPbTlyOUNEVW56RXAvYjhodm1ldEdET3ViWnpORDlxRHN1dFA3S1g1?=
 =?utf-8?B?MmVtY3VtbnJNODFhUWE5RlR3ekxKUlc4a0lBRDlPUWkvaDJCQVJjYTZPNGFR?=
 =?utf-8?B?bjFyTXZhSk1RT0tPWXFkMzV4Nys5TlNOeDYwY0Z3eTZtTUNYOFFlREJzLzRB?=
 =?utf-8?B?d0IzYkF2dDBmUmxtRWw4TGdnckVYcEwvb3F1V1BPb0RIQ2daWkk3MThtQ1Mz?=
 =?utf-8?B?RnlLQVc0UXdlQ1JueWZlWFF1QjlNSjQwM001bEt4STVjbENNbk9sQ0MweWlo?=
 =?utf-8?B?ZE5wSkQwL21oTkR4ak9WbHBUMzREbXNvVzNPVWhPd0tXNkhEMTZtUWcvRXdV?=
 =?utf-8?B?RDBHblBvTU51d1UvREhHRnMzSU9Cc0c3NkNOMHdwL0lWRGtRNy9WVHhEVVNy?=
 =?utf-8?B?ekF0M1lmUnd4ZXRXclN4RWxQa0pWSFNFM2NmQlBmU2Z0MmhVOFRIVmlMeDdt?=
 =?utf-8?B?L2QxUjgyU3Z5TlU2dU5JUzhCVHBHcjNkTDJJY0RCWmw5RkN5dGdUYWkzK0FQ?=
 =?utf-8?B?TzJ1Q1lKTEVjbkR2WFIwSExQdGxIWFU4cVpseFJTSjl3NEJjUXBlL3FKWDlu?=
 =?utf-8?B?VXVreW5PVWg1YmpSN1cwY0kvLzl4aDNKTmZYRXk0NWNtczBtVzBzV3JzNzlZ?=
 =?utf-8?B?UkRlVmwxSEN1L1FSaHpmT1JSQXpTMEZyTFhUTmM1aUpGYTFJcjBXVk1MdVpp?=
 =?utf-8?B?eisxMDdPTlRPQ0ZEUnlWNlU0SUxZUVVpdytVSTQyVytwb1hDb3pmd0JRQVJD?=
 =?utf-8?B?QjRLcFlhU0llZ2RDbzRLeW1aeDhFalFZZ1FzY2dpNWNLWUoweStNUE13UjZJ?=
 =?utf-8?B?U0xmclZBanJ5aU5hdlE2MkcrTjVGRURPa2YweEFFWTJWVHBCR05zQTZSbkxI?=
 =?utf-8?B?Q1dRd1BKZk5OS1NvR0VlWlhaS3hrdTgwVVgrN2ZPNHlIR0w3cHJzcEovTjhT?=
 =?utf-8?B?elJXTmtFTGJzenI5aDR2Wk5oUFZpTFc1NEN6VXZLRmQ0YXlqS2xYdi9udFlE?=
 =?utf-8?B?SS94YVdxUUxOTXZkbFJvK0IvK0FZY0tkaW9xRE1SdXdnTEw3ZkpJSnJxeVc3?=
 =?utf-8?B?OGw3OUZmd1Flbkp6TUNKdjU2MDBKYitHdTRqSWIrL0NlTHJhVHNSVGFZRjBw?=
 =?utf-8?Q?A27o=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: f561c940-eb19-46a6-1d16-08ddb7837ef2
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2025 03:09:15.4843
 (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: KjQDS11aSNRFM4DGlumfx77yIFhzERIqvxsXMz30XT2MtcJbA2N6CQhxCsvIpzzljebNb49v9B25q9XdyE5TkQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB6894

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDI2LCAyMDI1
IDExOjUxIFBNDQo+IFRvOiBQZW5ueSwgWmhlbmcgPHBlbm55LnpoZW5nQGFtZC5jb20+DQo+IENj
OiBIdWFuZywgUmF5IDxSYXkuSHVhbmdAYW1kLmNvbT47IEFuZHJldyBDb29wZXINCj4gPGFuZHJl
dy5jb29wZXIzQGNpdHJpeC5jb20+OyBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4
LmNvbT47DQo+IEFudGhvbnkgUEVSQVJEIDxhbnRob255LnBlcmFyZEB2YXRlcy50ZWNoPjsgT3J6
ZWwsIE1pY2hhbA0KPiA8TWljaGFsLk9yemVsQGFtZC5jb20+OyBKdWxpZW4gR3JhbGwgPGp1bGll
bkB4ZW4ub3JnPjsgU3RlZmFubyBTdGFiZWxsaW5pDQo+IDxzc3RhYmVsbGluaUBrZXJuZWwub3Jn
PjsgRGFuaWVsIFAuIFNtaXRoIDxkcHNtaXRoQGFwZXJ0dXNzb2x1dGlvbnMuY29tPjsgRGFyaW8N
Cj4gRmFnZ2lvbGkgPGRmYWdnaW9saUBzdXNlLmNvbT47IEp1ZXJnZW4gR3Jvc3MgPGpncm9zc0Bz
dXNlLmNvbT47IEdlb3JnZQ0KPiBEdW5sYXAgPGd3ZEB4ZW5wcm9qZWN0Lm9yZz47IE5hdGhhbiBT
dHVkZXIgPG5hdGhhbi5zdHVkZXJAZG9ybmVyd29ya3MuY29tPjsNCj4gU3Rld2FydCBIaWxkZWJy
YW5kIDxzdGV3YXJ0QHN0ZXcuZGs+OyBCZXJ0cmFuZCBNYXJxdWlzDQo+IDxiZXJ0cmFuZC5tYXJx
dWlzQGFybS5jb20+OyBWb2xvZHlteXIgQmFiY2h1aw0KPiA8Vm9sb2R5bXlyX0JhYmNodWtAZXBh
bS5jb20+OyBBbGlzdGFpciBGcmFuY2lzIDxhbGlzdGFpci5mcmFuY2lzQHdkYy5jb20+Ow0KPiBC
b2IgRXNobGVtYW4gPGJvYmJ5ZXNobGVtYW5AZ21haWwuY29tPjsgQ29ubm9yIERhdmlzDQo+IDxj
b25ub2pkYXZpc0BnbWFpbC5jb20+OyBPbGVrc2lpIEt1cm9jaGtvIDxvbGVrc2lpLmt1cm9jaGtv
QGdtYWlsLmNvbT47IHhlbi0NCj4gZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmc7IHhlbi1kZXZl
bEBkb3JuZXJ3b3Jrcy5jb20NCj4gU3ViamVjdDogUmU6IFtQQVRDSCB2NSAwMC8xOF0geGVuOiBp
bnRyb2R1Y2UgQ09ORklHX1NZU0NUTA0KPg0KPiBPbiAxNi4wNi4yMDI1IDA4OjQxLCBQZW5ueSBa
aGVuZyB3cm90ZToNCj4gPiBJdCBjYW4gYmUgYmVuZWZpY2lhbCBmb3Igc29tZSBkb20wbGVzcyBz
eXN0ZW1zIHRvIGZ1cnRoZXIgcmVkdWNlIFhlbg0KPiA+IGZvb3RwcmludCB2aWEgZGlzYWJsaW5n
IHNvbWUgaHlwZXJjYWxscyBoYW5kbGluZyBjb2RlLCB3aGljaCBtYXkgbm90DQo+ID4gdG8gYmUg
dXNlZCAmIHJlcXVpcmVkIGluIHN1Y2ggc3lzdGVtcy4gRWFjaCBoeXBlcmNhbGwgaGFzIGEgc2Vw
YXJhdGUNCj4gPiBvcHRpb24gdG8ga2VlcCBjb25maWd1cmF0aW9uIGZsZXhpYmxlLg0KPiA+DQo+
ID4gT3B0aW9ucyB0byBkaXNhYmxlIGh5cGVyY2FsbHM6DQo+ID4gLSBzeXNjdGwNCj4gPiAtIGRv
bWN0bA0KPiA+IC0gaHZtDQo+ID4gLSBwaHlzZGV2DQo+ID4gLSBwbGF0Zm9ybQ0KPiA+DQo+ID4g
VGhpcyBwYXRjaCBzZXJpZSBpcyBvbmx5IGZvY3VzaW5nIG9uIGludHJvZHVjaW5nIENPTkZJR19T
WVNDVEwuDQo+ID4gRGlmZmVyZW50IG9wdGlvbnMgd2lsbCBiZSBjb3ZlcmVkIGluIGRpZmZlcmVu
dCBwYXRjaCBzZXJpZS4NCj4gPg0KPiA+IEZlYXR1cmVzLCBsaWtlIExJVkVQQVRDSCwgT3Zlcmxh
eSBEVEIsIHdoaWNoIGZ1bGx5IHJlbHkgb24gc3lzY3RsIG9wLA0KPiA+IHdpbGwgYmUgd3JhcHBl
ZCB3aXRoIENPTkZJR19TWVNDVEwsIHRvIHJlZHVjZSBYZW4gZm9vdHByaW50IGFzIG11Y2ggYXMN
Cj4gcG9zc2libGUuDQo+ID4NCj4gPiBJdCBpcyBkZXJpdmVkIGZyb20gU3RlZmFubyBTdGFiZWxs
aW5pJ3MgY29tbWl0ICJ4ZW46IGludHJvZHVjZSBrY29uZmlnDQo+ID4gb3B0aW9ucyB0byBkaXNh
YmxlIGh5cGVyY2FsbHMiKA0KPiA+IGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZlbC8y
MDI0MTIxOTA5MjkxNy4zMDA2MTc0LTEtU2VyZ2l5X0tpYnINCj4gPiBpa0BlcGFtLmNvbSkNCj4g
Pg0KPiA+IFBlbm55IFpoZW5nICgxNik6DQo+ID4gICB4ZW4veDg2OiByZW1vdmUgImRlcGVuZHMg
b24gIVBWX1NISU1fRVhDTFVTSVZFIg0KPiA+ICAgeGVuL3hzbTogd3JhcCBhcm91bmQgeHNtX3N5
c2N0bCB3aXRoIENPTkZJR19TWVNDVEwNCj4gPiAgIHhlbi9zeXNjdGw6IHdyYXAgYXJvdW5kIFhF
Tl9TWVNDVExfcmVhZGNvbnNvbGUNCj4gPiAgIHhlbi9zeXNjdGw6IG1ha2UgQ09ORklHX1RSQUNF
QlVGRkVSIGRlcGVuZCBvbiBDT05GSUdfU1lTQ1RMDQo+ID4gICB4ZW4vc3lzY3RsOiB3cmFwIGFy
b3VuZCBYRU5fU1lTQ1RMX3NjaGVkX2lkDQo+ID4gICB4ZW4vc3lzY3RsOiB3cmFwIGFyb3VuZCBY
RU5fU1lTQ1RMX3BlcmZjX29wDQo+ID4gICB4ZW4vc3lzY3RsOiB3cmFwIGFyb3VuZCBYRU5fU1lT
Q1RMX2xvY2twcm9mX29wDQo+ID4gICB4ZW4vcG1zdGF0OiBpbnRyb2R1Y2UgQ09ORklHX1BNX09Q
DQo+ID4gICB4ZW4vc3lzY3RsOiBpbnRyb2R1Y2UgQ09ORklHX1BNX1NUQVRTDQo+ID4gICB4ZW4v
c3lzY3RsOiB3cmFwIGFyb3VuZCBYRU5fU1lTQ1RMX3BhZ2Vfb2ZmbGluZV9vcA0KPiA+ICAgeGVu
L3N5c2N0bDogd3JhcCBhcm91bmQgWEVOX1NZU0NUTF9jcHVwb29sX29wDQo+ID4gICB4ZW4vc3lz
Y3RsOiB3cmFwIGFyb3VuZCBYRU5fU1lTQ1RMX3NjaGVkdWxlcl9vcA0KPiA+ICAgeGVuL3N5c2N0
bDogd3JhcCBhcm91bmQgWEVOX1NZU0NUTF9waHlzaW5mbw0KPiA+ICAgeGVuL3N5c2N0bDogbWFr
ZSBDT05GSUdfQ09WRVJBR0UgZGVwZW5kIG9uIENPTkZJR19TWVNDVEwNCj4gPiAgIHhlbi9zeXNj
dGw6IG1ha2UgQ09ORklHX0xJVkVQQVRDSCBkZXBlbmQgb24gQ09ORklHX1NZU0NUTA0KPiA+ICAg
eGVuL3N5c2N0bDogd3JhcCBhcm91bmQgYXJjaC1zcGVjaWZpYyBhcmNoX2RvX3N5c2N0bA0KPg0K
PiBXaGVuIHRoaW5raW5nIGFib3V0IHdoZXRoZXIgdG8gY29tbWl0IHBhcnQgb2YgdGhlIHNlcmll
cywgaXQgb2NjdXJyZWQgdG8gbWUgdGhhdCB0bw0KPiBhdm9pZCB0cmFuc2llbnRseSByZWdyZXNz
aW5nIHNoaW0gKGluIHNpemUpLCBzaG91bGRuJ3QgdGhlIGN1cnJlbnRseSAxc3QgcGF0Y2ggYmUN
Cj4gbW92ZWQgdG8gYmUgMm5kIHRvIGxhc3QsIGFuZCB0aGVuIGJlIGNvbW1pdHRlZCB0b2dldGhl
ciB3aXRoIHRoZSBsYXN0IG9uZT8gSW4gYW55DQo+IGV2ZW50IHRoZSBwbGFuIHJpZ2h0IG5vdyBp
cyB0byBjb21taXQgc29tZSBwYXRjaGVzIGZyb20gdGhlIGJlZ2lubmluZyBvZiB0aGlzDQo+IHNl
cmllcywgYnV0IHNwZWNpZmljYWxseSB3aXRob3V0IHBhdGNoIDEuIFBsZWFzZSBzaG91dCBpZiB5
b3Ugc2VlIGFueSBwcm9ibGVtIHdpdGgNCj4gdGhpcy4NCg0KVW5kZXJzdG9vZCwgZmluZSB3aXRo
IG1lDQoNCj4NCj4gSmFuDQo=


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 04:51:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 04:51:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1028767.1402508 (Exim 4.92)
	(envelope-from )
	id 1uW6Tu-0002Yu-7g; Mon, 30 Jun 2025 04:51:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1028767.1402508; Mon, 30 Jun 2025 04:51:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uW6Tu-0002Yn-4a; Mon, 30 Jun 2025 04:51:02 +0000
Received: by outflank-mailman (input) for mailman id 1028767;
 Sun, 29 Jun 2025 20:42: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 1uVyrU-0007XF-Pc
 for xen-devel@lists.xenproject.org; Sun, 29 Jun 2025 20:42:52 +0000
Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com
 [2607:f8b0:4864:20::42e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9ea3c55f-5529-11f0-a312-13f23c93f187;
 Sun, 29 Jun 2025 22:42:50 +0200 (CEST)
Received: by mail-pf1-x42e.google.com with SMTP id
 d2e1a72fcca58-748feca4a61so832940b3a.3
 for ; Sun, 29 Jun 2025 13:42:50 -0700 (PDT)
Received: from avinash-INBOOK-Y2-PLUS..
 ([2401:4900:88e3:d68:d7d3:6fa0:fee9:8056])
 by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b34e301f704sm6348327a12.18.2025.06.29.13.42.45
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 29 Jun 2025 13:42:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9ea3c55f-5529-11f0-a312-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1751229769; x=1751834569; 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=DirJRH7MmziZYdVMjQqFRTAlkdP6s2rnfn3J0zzduXE=;
        b=kyo+W/dsCaQievwswDQ35wjiyYMzkfh0X5cZQZxYnZ5TxYChh1VQWFVtDk1x/eXnOm
         o7WEvjJlUVSydpBXFU/YZmEMj4uofVOvLKNx0JsSzq9tziTgQl3u7xd2PCMsiCrpVlHY
         gqaYXvvTHuw6k33jurafA7QWbAyvDGITpcE8+qVr3p9SnCnEtDxRaLG3cYP2IfSjC+ex
         QdMl8sPwMBoZ1xNoroplAeSv1U1ISJOlM6c6drFjAiTcEWdC82+jtDvh6wkCi9YLoAPT
         FAVrCOJDVk68lfGPvq9QlVVVeym/FX3W/ROhEAbVsxdexTk3PrhwJUx1LDNAePAF7G5b
         aLqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751229769; x=1751834569;
        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=DirJRH7MmziZYdVMjQqFRTAlkdP6s2rnfn3J0zzduXE=;
        b=DWlYnY2CwLhFMu3IcXBd9oNw0NBLb6yhXbJvwSAHocK3fJWDh/ttEJIxAPMdvTb5mz
         KGMUwbcYGXU5k6cKjLFoHuMlykOqaRieE+g4QhCYUub1jzF0KI9CpZz5HXtuzZMpYBpU
         g5vXForyJONFa4rte3dpCe9SwYwVlADLncq8DIoAZEAE6SG+sgDcIO0dnbUoELpLDPxD
         DWlKqj61zxQcfei0O1C50zVu6TW5ZAxhPYzsqSZSMzvfpk9LCF+9qLrCrKQma4pzaLIH
         Wz55bGOdOOzowrMp+b/8hsejot1n19ouVIFNwRmP13F78qSqR97r/Qy7Vhoy33jxHLKI
         n1Lw==
X-Forwarded-Encrypted: i=1; AJvYcCXlKzX2xpYcMj5Dam1EgBtjuaRIbJwFv68bRaGlNl5Txmy6bPV9oAKUvhNnMor8yvB927EnV89hVqg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyrPHdSTFNDEhjH/3355Xetlo/h8dBHTC6wyeMywug4jHhPGsGX
	o0yNP/dcwYFZMRuZOOUOJuLXv9K78fWNTlWSYnRC9NIvDfnuQW0MpBOJ
X-Gm-Gg: ASbGncsDACN3FLzplzecBycuPbLAl1G0VErBw5BGz6cGVM9G14wZ9+x3lbjbJ6o/ugc
	57b+EduLTan6b9/EDhvbdGHAp8/raPnPw9yYKaRoVxZL0pezdu1i89ZyuvkSlN3t2+qDp/dNPdn
	nHlGNNZWS/XhRyEN/us+6GUO8ZJwbdyLzLB7fazcNdjKAgFnS3mukHdh+Dk5BaqnMdiQ4SS7vBG
	yTPXkHalDhZxXQzSY1DS8LTHxtFYJiRU9zU8Bn0DAYrTnuJijYeQ2tO7sshdgJowonJaiP9zFYT
	YNQ5kslWJbDv7DxQANzVdSsoD25pFlfSj2aoayZoOrCms0UIcYSH0vL/qzMlsijfLSt0RWECDMW
	oKm6qJqJqVYC8NKMrd58=
X-Google-Smtp-Source: AGHT+IE4jl+a6y/SeKsfFaCxOplJiF004IBZL8OwquCVNHRD2+gPLNctbva44/6kHL7gLJq8LE+UVg==
X-Received: by 2002:a05:6a20:3d08:b0:218:9b3e:e8bd with SMTP id adf61e73a8af0-220a12a662fmr16637049637.10.1751229768632;
        Sun, 29 Jun 2025 13:42:48 -0700 (PDT)
From: Abinash Singh 
X-Google-Original-From: Abinash Singh 
To: jgross@suse.com,
	sstabellini@kernel.org
Cc: oleksandr_tyshchenko@epam.com,
	xen-devel@lists.xenproject.org,
	linux-kernel@vger.kernel.org,
	Abinash Singh 
Subject: [RFC PATCH] xen/gntdev: reduce stack usage by dynamically allocating gntdev_copy_batch
Date: Mon, 30 Jun 2025 02:12:15 +0530
Message-ID: <20250629204215.1651573-1-abinashsinghlalotra@gmail.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

While building the kernel with LLVM, a warning was reported due to
excessive stack usage in `gntdev_ioctl`:

	drivers/xen/gntdev.c:991: warning: stack frame size (1160) exceeds limit (1024) in function 'gntdev_ioctl'

Further analysis revealed that the large stack frame was caused by
`struct gntdev_copy_batch`, which was declared on the stack inside
`gntdev_ioctl_grant_copy()`. Since this function was inlined into
`gntdev_ioctl`, the stack usage was attributed to the latter.

This patch fixes the issue by dynamically allocating `gntdev_copy_batch`
using `kmalloc()`, which significantly reduces the stack footprint and
eliminates the warning.

This approach is consistent with similar fixes upstream, such as:

commit fa26198d30f3 ("iommu/io-pgtable-arm: dynamically allocate selftest device struct")

Fixes: a4cdb556cae0 ("xen/gntdev: add ioctl for grant copy")
Signed-off-by: Abinash Singh 
---
The stack usage was confirmed using the `-fstack-usage`  flag and mannual analysis, which showed:

  drivers/xen/gntdev.c:953: gntdev_ioctl_grant_copy.isra   1048 bytes
  drivers/xen/gntdev.c:826: gntdev_copy                     56 bytes

Since `gntdev_ioctl` was calling the inlined `gntdev_ioctl_grant_copy`, the total
frame size exceeded 1024 bytes, triggering the warning.

This patch addresses the warning and keeps stack usage within acceptable limits.
Is this patch fine or kmalloc may affect performance ?
---
 drivers/xen/gntdev.c | 24 +++++++++++++++---------
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 61faea1f0663..9811f3d7c87c 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -953,15 +953,19 @@ static int gntdev_grant_copy_seg(struct gntdev_copy_batch *batch,
 static long gntdev_ioctl_grant_copy(struct gntdev_priv *priv, void __user *u)
 {
 	struct ioctl_gntdev_grant_copy copy;
-	struct gntdev_copy_batch batch;
+	struct gntdev_copy_batch *batch;
 	unsigned int i;
 	int ret = 0;
 
 	if (copy_from_user(©, u, sizeof(copy)))
 		return -EFAULT;
-
-	batch.nr_ops = 0;
-	batch.nr_pages = 0;
+
+	batch = kmalloc(sizeof(*batch), GFP_KERNEL);
+	if (!batch)
+		return -ENOMEM;
+
+	batch->nr_ops = 0;
+	batch->nr_pages = 0;
 
 	for (i = 0; i < copy.count; i++) {
 		struct gntdev_grant_copy_segment seg;
@@ -971,18 +975,20 @@ static long gntdev_ioctl_grant_copy(struct gntdev_priv *priv, void __user *u)
 			goto out;
 		}
 
-		ret = gntdev_grant_copy_seg(&batch, &seg, ©.segments[i].status);
+		ret = gntdev_grant_copy_seg(batch, &seg, ©.segments[i].status);
 		if (ret < 0)
 			goto out;
 
 		cond_resched();
 	}
-	if (batch.nr_ops)
-		ret = gntdev_copy(&batch);
-	return ret;
+	if (batch->nr_ops)
+		ret = gntdev_copy(batch);
+	goto free_batch;
 
   out:
-	gntdev_put_pages(&batch);
+	gntdev_put_pages(batch);
+  free_batch:
+	kfree(batch);
 	return ret;
 }
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Jun 30 06:02:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 06:02:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1028849.1402518 (Exim 4.92)
	(envelope-from )
	id 1uW7ax-0002kd-CR; Mon, 30 Jun 2025 06:02:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1028849.1402518; Mon, 30 Jun 2025 06:02:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uW7ax-0002kW-96; Mon, 30 Jun 2025 06:02:23 +0000
Received: by outflank-mailman (input) for mailman id 1028849;
 Mon, 30 Jun 2025 06:02: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 1uW7aw-0002kQ-2q
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 06:02:22 +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 c86ebf74-5577-11f0-a312-13f23c93f187;
 Mon, 30 Jun 2025 08:02:20 +0200 (CEST)
Received: by mail-lf1-x12f.google.com with SMTP id
 2adb3069b0e04-553bcf41440so4073812e87.3
 for ; Sun, 29 Jun 2025 23:02:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c86ebf74-5577-11f0-a312-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1751263339; x=1751868139; 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=Gn/KyGyri6kzGvax5/vbwEA0eNlYQ1eBcq1jD4zRnNU=;
        b=UfZSf4uVCdSDDByA8FjSscYZZUO9gVRAZ2EDzsWCQ2KQJhE4rPN7cjdzvOHpDle279
         sJoRsOePZ7h9zveO4M6dM6ZZ72OPXEm9Zb2uO6AKXVZp7zf0uQI+0Qj5xIsBsbKx3hLG
         0o5+llMjkKFpF9NUogVM/16fil53jYDUvQXCWW2Jv6kWoJAKclGajCNqoigY8AihkeRL
         78v7A+MUPVSb0iaoNcNeUmvH5VgMOtVD6yJ/d88X6lxnO94VaL1rb+g0lNyv1PIGW7ZG
         fEcnImV4mniLoll41xkqORXBK3GcgSjUPpS9IEStH6+/DBfEPkODjhOLFgBo+EpkfTs/
         Q9vQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751263339; x=1751868139;
        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=Gn/KyGyri6kzGvax5/vbwEA0eNlYQ1eBcq1jD4zRnNU=;
        b=p5AqPXMul3bAxJe9Lzm56riYswOulCqdlXY+I0P4K6QSZvEPp4L0Bm7XHWog1jkVOU
         A4ywl8TE1pYyajeFKOIRY+9u3QCjvkPwbp+AgQ8CVqDUxTp0qZcfVbs55T6/7F+FDqv1
         GEhd02anZosbfvS7pRfqqzyOHduf2tTzA9gfqIbi3lJ8spTo7Ut4+PWkdpMBol3tsB98
         GixCD5ZAS+aQuN7OmLHBviUC4K3dzh+N3HYp/i0oESTxsrY46uW37/Lok3Tl2AjOvhzO
         J5bBdHpZT7kwb61UZgDIHgCBqwWgQmzeBJt/sALoCM1C3PWLxKsCMWZHe+WSXUJFHp9H
         gJwA==
X-Gm-Message-State: AOJu0Yzf6BEnncSPqTJ4mAx33UnyNk144Rgg/s6oEptabbniWcmf4NmO
	5nnmE14XoAiiaqiT5yP3NTInIUHC/Sl7Lh64BLHLnXnZqm45l5LsNWH8PXPLbadok1pXhR94ljy
	WrCZ3Yh9e4bmCxVCz7K//6g3SIPUDE7s=
X-Gm-Gg: ASbGncvLdwuy1PfWrstV2mOk/Kq0NOOimkeU72sbxydIx2fLn0niYTYhl0yQcs2Vt8N
	03sUCdVn1vJeBmAv9Cvr4s7yvEMLk0Mni7YGk+FHwz0aYADSWQ7Lx36/Vj+V0TyW61P0r1nudJ+
	Po8IPsyd6bpUnhro9lpZh0UiFGxy/UYIAYKnwjnYrgRwt1qDTSU+fU
X-Google-Smtp-Source: AGHT+IGR8KjOiHt6e0rM5kNk9vPKTlSXZufIwUvBD7gOVgJTmSawcpAGdvbDB1GehhZqPfKlh9i13iP9oOFs6m13zAs=
X-Received: by 2002:a05:6512:398e:b0:554:fa07:c56 with SMTP id
 2adb3069b0e04-5550b9efd5fmr3453739e87.26.1751263339182; Sun, 29 Jun 2025
 23:02:19 -0700 (PDT)
MIME-Version: 1.0
References:  <401d3745a295812fef14a22b0c2a3c6017d588c1.1751020456.git.mykola_kvach@epam.com>
 
In-Reply-To: 
From: Mykola Kvach 
Date: Mon, 30 Jun 2025 09:02:08 +0300
X-Gm-Features: Ac12FXy2KdPwV4sSQcQCA3ik-SQUxKPJhrOUHKibSAQO4XS0CponfUZ3Zz-Razw
Message-ID: 
Subject: Re: [PATCH v5 3/4] SUPPORT.md: Add entry for guest PSCI
 SYSTEM_SUSPEND support
To: Julien Grall 
Cc: xen-devel@lists.xenproject.org, Mykola Kvach , 
	Andrew Cooper , Anthony PERARD , 
	Michal Orzel , Jan Beulich , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Stefano Stabellini 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Julien,

On Sat, Jun 28, 2025 at 9:27=E2=80=AFPM Julien Grall  wrote=
:
>
> Hi Mykola,
>
> On 27/06/2025 11:51, Mykola Kvach wrote:
> > From: Mykola Kvach 
> >
> > Document support for the optional PSCI SYSTEM_SUSPEND function, exposed
> > via the virtual PSCI (vPSCI) interface to guests.
> >
> > This allows non-hardware domain guests (domUs) to initiate system suspe=
nd
> > operations via PSCI calls. The feature is currently marked as Experimen=
tal.
> >
> > Signed-off-by: Mykola Kvach 
> > ---
> > Changes in v5:
> > - Dropped ARM/PSCI entry: this refers to internal use of PSCI SMC calls=
,
> >    which is not relevant for SUPPORT.md
> > - Added a dedicated entry for PSCI SYSTEM_SUSPEND instead of generic gu=
est
> >    PSCI info; guest PSCI support was documented in a separate patch
> > ---
> >   SUPPORT.md | 7 +++++++
> >   1 file changed, 7 insertions(+)
> >
> > diff --git a/SUPPORT.md b/SUPPORT.md
> > index f0b5718e84..659b9c3052 100644
> > --- a/SUPPORT.md
> > +++ b/SUPPORT.md
> > @@ -956,6 +956,13 @@ by hwdom. Some platforms use SCMI for access to sy=
stem-level resources.
> >
> >       Status: Supported
> >
> > +### ARM: Guest PSCI SYSTEM_SUSPEND support
>
> You are already adding a Guest PSCI section in [1]. I would rather not
> another section just for SYSTEM_SUSPEND. This would make more difficult
> to know what part of PSCI is supported.
>
> Instead, I would tweak the merge the two patches and tweak the wording
> to have something like:
>
>    Status, Mandatory: Supported
>    Status, MIGRATE_INFO_TYPE: Supported
>    Status, SYSTEM_SUSPEND: Experimental

If you don't mind, I'd prefer to keep the two patches separate rather than
merging them. In my view, patch [1] is a generic and straightforward change
that can be merged easily, with the remarks you've proposed here.
The suspend-related part depends on logic introduced in this PR, which stil=
l
has some issues and may take more time to finalize and get reviewed.

>
> Also, I will comment directly here:
>
>  > Emulated PSCI interface exposed to guests. Supports all mandatory
> functions from PSCI versions 0.2 and 1.0, as well as the optional
> MIGRATE_INFO_TYPE
>
> Xen is supporting PSCI 1.1 which is backwards compatible up to 0.2. But
> effectively, we don't expose 0.2 nor 1.0.
>
> So I would reword to:
>
> Emulated PSCI interface exposed to guests. We support all mandatory
> functions of PSCI 1.1. See below for the list of optional PSCI call
> implemented and their status.

Sure, I'll rephrase it as suggested =E2=80=94 thank you for the clarificati=
on.

Best regards,
Mykola

>
> Cheers,
>
> [1]
> https://lore.kernel.org/all/20250627053313.2233826-1-xakep.amatop@gmail.c=
om/
> --
> Julien Grall
>


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 06:35:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 06:35:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1028857.1402527 (Exim 4.92)
	(envelope-from )
	id 1uW86c-0006ZU-LU; Mon, 30 Jun 2025 06:35:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1028857.1402527; Mon, 30 Jun 2025 06:35:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uW86c-0006ZN-Iv; Mon, 30 Jun 2025 06:35:06 +0000
Received: by outflank-mailman (input) for mailman id 1028857;
 Mon, 30 Jun 2025 06:35: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 1uW86a-0006ZG-Or
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 06:35: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 598ad93d-557c-11f0-b894-0df219b8e170;
 Mon, 30 Jun 2025 08:35:01 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a588da60dfso991627f8f.1
 for ; Sun, 29 Jun 2025 23:35:01 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23acb3b7915sm74513785ad.165.2025.06.29.23.34.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 29 Jun 2025 23:35:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 598ad93d-557c-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1751265301; x=1751870101; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=qKgqytZU9Ouq64bKq0GpYaNbg79w/3qqqRxlDsF+hAw=;
        b=FunpqAZFg/yRZku6q50ciIxyRVIti2xhiaSp9ZT3ZSanmEZIoOP/g+cl+XMYp67rQJ
         uFtH5VieuOfy5pvpf0aUj9LAGkATqAjgruVkm22P9bo3uvgOpl8+aDWr357QPhXAthAS
         CYcJL9OTGv892Ub8DsmHS0Fv/6sDn6OdzMcPQuW6QDFr1VoTot0Z4Xl8elg7YL9ur5tc
         G+2L3ZdtnEOj3u0aakhHw17U/UgorpJpZuMgtJeuyjD5k2EPkDl03Fv60Gr3sznncRK+
         dUvQG2lbXmV2Z7Vdj+rotSnuxlE0Bks03HVUdHtSweB6Ich1H1aO02OPHcj4zRUrykLQ
         +y3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751265301; x=1751870101;
        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=qKgqytZU9Ouq64bKq0GpYaNbg79w/3qqqRxlDsF+hAw=;
        b=W1VZEKz0ZLdEhvNkkFEolmc9zPZxnOyH5xsYeUsV71jwFD0D7IanTqcJQEk0ck5HM+
         rNlitJ3ejLgUvmR7BMLTpgXmUY8XUnB0DgvUgOvckNbTfAHGIvQJ1qo9s0upECTdRoHb
         BwLfItJVNpukBujtEyNwqKvOIGNhXb1wDWw7XSQP8ummbo9+fzhDU37jCG+fA3DtaUJ8
         ykP+8O8iLhIB5eiKw6mUrd9LbtRamf6/lygRWnl3EMYFNzGlI1dz3hyXu4V+nDXFS+ql
         7oLmADYy6YUIrZsd6YJTu6U6FkN8J6UGpU4frLWk3fhEMzAQ7TIJdXPLdJMXrQNk+nJD
         A0lw==
X-Forwarded-Encrypted: i=1; AJvYcCWAEYjFRlQRGhB1UioIC94FvSs2iIZKN3Xg4W+PfY5Dg7uyJpi8eTHZgCejpiWwdNLFo1iDBNcQLM4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxCK4IPy54ikyTeCCzfYJShrFm89JyzN6RX0h+m0RlxnbJkbKpH
	OLJocHzrRvYyt8dPH6x8CiCSG2rad5Vd/mS8Vez6bAg7M7bIndHvIKymtBax40PBKcFo+Gl2oIF
	9MZo=
X-Gm-Gg: ASbGncvrJpFSP/W1OnbMMlkAEUyUrx5IgP095ClrOV2IMumstJWhW2D8gN1tH6h5eFA
	zqyrcS1XkbP3lVMFTzQPRUkCFbP87bG7PYPbdssja3GL1aIg5ky2caT81JEYPB50cRYADYSj42z
	9bncfM76ze0k2y2bhi5WM20ta+j9wPHDrl+n+vvgCzI8AswPUjQaFRS5bk1DoFxo79VG4me0nHR
	RGsMqKNCaxWaR76aBSeHd/t2/PyV2JNn1uF9Cbanr5jpcrYnKM/oxKlNgC8Zl6KFXmt54R0YVcq
	Kw5R0AJl8psfCWUo/JTsF6NTKHIp85lbRFPnR6YTF8RsL22p1aEakG0DV/vgHrsiZa/nu98dDKC
	WZ5mgLbciOKBXDIayQ79Fdzi67wfDiiP2HoGrRg7lByWkTLI=
X-Google-Smtp-Source: AGHT+IF5caMpYQpxzEvd7sUoovMc0KqsjGipVASCHD0Vbs60TPPpsq9SdxrW19OVEhOw36xYjzpQmw==
X-Received: by 2002:adf:e00b:0:b0:3a4:ddde:13e4 with SMTP id ffacd0b85a97d-3a8ffeb43fbmr6490554f8f.58.1751265300999;
        Sun, 29 Jun 2025 23:35:00 -0700 (PDT)
Message-ID: 
Date: Mon, 30 Jun 2025 08:34:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 8/8] pdx: introduce a new compression algorithm based
 on region offsets
To: Roger Pau Monne 
Cc: Oleksii Kurochko ,
 Community Manager ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250620111130.29057-1-roger.pau@citrix.com>
 <20250620111130.29057-9-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: <20250620111130.29057-9-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 20.06.2025 13:11, Roger Pau Monne wrote:
> @@ -40,6 +41,8 @@ bool __mfn_valid(unsigned long mfn)
>  
>  #ifdef CONFIG_PDX_MASK_COMPRESSION
>      invalid |= mfn & pfn_hole_mask;
> +#elif defined(CONFIG_PDX_OFFSET_COMPRESSION)
> +    invalid |= mfn ^ pdx_to_pfn(pfn_to_pdx(mfn));
>  #endif
>  
>      if ( unlikely(evaluate_nospec(invalid)) )

In the chat you mentioned that you would add a check against max_pdx here. While
that feels sufficient, I couldn't quite convince myself of this formally. Hence
an alternative proposal for consideration, which imo is more clearly achieving
the effect of allowing for no false-positive results. In particular, how about
adding another array holding the PDX upper bounds for the respective region.
When naming the existing two arrays moffs[] and poffs[] for brevity, the new
one would be plimit[], but indexed by the MFN index. Then we'd end up with

	p = mfn - moffs[midx]; /* Open-coded pfn_to_pdx() */
	invalid |= p >= plimit[midx] || p < plimit[midx - 1];

Of course this would need massaging to deal with the midx == 0 case, perhaps by
making the array one slot larger and incrementing the indexes by 1. The
downside compared to the max_pdx variant is that while it's the same number of
memory accesses (and the same number of comparisons [or replacements thereof,
like the ^ in context above), cache locality is worse (simply because of the
fact that it's another array).

For the example in the description, i.e.

PFN compression using PFN lookup table shift 29 and PDX region size 0x10000000
 range 0 [0000000000000, 0x0000807ffff] PFN IDX  0 : 0000000000000
 range 1 [0x00063e80000, 0x0006be7ffff] PFN IDX  3 : 0x00053e80000
 range 2 [0x000c7e80000, 0x000cfe7ffff] PFN IDX  6 : 0x000a7e80000
 range 3 [0x0012be80000, 0x00133e7ffff] PFN IDX  9 : 0x000fbe80000

we'd end up with plimit[] holding

0, 0x10000000, 0x10000000, 0x10000000, 0x20000000, 0x20000000, 0x20000000,
0x30000000, 0x30000000, 0x30000000, 0x40000000, 0x40000000, 0x40000000.

For this example the 2nd of the comparisons could even be omitted afaict, but
I couldn't convince myself that this would hold for the general case.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 06:38:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 06:38:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1028864.1402537 (Exim 4.92)
	(envelope-from )
	id 1uW89d-00076C-2g; Mon, 30 Jun 2025 06:38:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1028864.1402537; Mon, 30 Jun 2025 06: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 1uW89c-000765-Vu; Mon, 30 Jun 2025 06:38:12 +0000
Received: by outflank-mailman (input) for mailman id 1028864;
 Mon, 30 Jun 2025 06:38: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 1uW89b-00075z-7n
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 06:38:11 +0000
Received: from TYVP286CU001.outbound.protection.outlook.com
 (mail-japaneastazlp170110002.outbound.protection.outlook.com
 [2a01:111:f403:c405::2])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c6e8c76c-557c-11f0-b894-0df219b8e170;
 Mon, 30 Jun 2025 08:38:06 +0200 (CEST)
Received: from OSOPR01MB12408.jpnprd01.prod.outlook.com (2603:1096:604:2d7::7)
 by TYCPR01MB11372.jpnprd01.prod.outlook.com (2603:1096:400:3c0::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8880.30; Mon, 30 Jun
 2025 06:38:00 +0000
Received: from OSOPR01MB12408.jpnprd01.prod.outlook.com
 ([fe80::7ff4:8a98:ccd4:daa1]) by OSOPR01MB12408.jpnprd01.prod.outlook.com
 ([fe80::7ff4:8a98:ccd4:daa1%4]) with mapi id 15.20.8880.030; Mon, 30 Jun 2025
 06:37: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: c6e8c76c-557c-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=QK6lIra9gFwOa8qsAtDW3onJrp1U6RVsY4WIbPhUIj0Re6FCMJ0mXDesLXTQlr1BEXVf9N8p+tlj5fH7FVmLD3hv1svyKIiRse2S+Cbjbb7wsNgC4qxr8dnxmDp5yRL+HKJb44Uv+dYl9hyoIrE7PccBSS50oQejdfr9ASkS0DVmWZOZsIZSvfQ76cQMPCLNUjIT81l3rU+JWISFUO5oDOrjurK/0BROU8wjqyEL4AK4vCGQB45ObWC/WSnlnlMcBZk6Ir3hFIZZPNyAQJuSz7S067BtwFMccbyDCgaDAxeVfzCtLbuPevK710ddc8Q6d6LZfjJYfDh638tr/e00kQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=RKTwIAMPZQYCMfAm2UpJV0s1Q9W/Ub2YeOqTbzmLcXM=;
 b=wHKAn/7yFbqGCjM9u4yNqoZ24kMoaqjmA+MiJ9DXHzBqhYaLEAYTlkWRdr0vCQlPKHrz+d8rkDlREpwNMB0mXSH8sotVYIbzHfiSzuKY1f4uoc5yH2YFDMfDFfy6nKR8n97PmnSWtBz7gqSCu3vHTCtWuLQRAgBHpXv5Lmsv5B2bPCOveUt34jQV0jV+iu3y3OeexPBt+ahBdpum9nMagQW7lWn0OcAA0mlWYnVjU3LkxmzLLhTnmNd4QQMQB171x5LGSpy6aVNZiR0FyoJ0uult5mzLi0JaI17Rc9yocSk6k0V+taI/oLaCpmRbNn+0gMrr0QzrpnS4AVbE1XCXJA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=renesas.com; dmarc=pass action=none header.from=renesas.com;
 dkim=pass header.d=renesas.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=renesas.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=RKTwIAMPZQYCMfAm2UpJV0s1Q9W/Ub2YeOqTbzmLcXM=;
 b=eHBjNlCeYvw4CxwbiFkWt0DVMSHpfus/d8W2lY0FUgvrRKAxABsa4ZjGVeRX7vU+P3hDh/k/1kbRxPg7y1U81kX+tfuXiTdL9d2iuSS1WynZ0Gq8V+1Fmidyi2XkhS9Yhw1uASIxIJc1Sf7Pij3cW/iq+616SeLImMmynZ2k3sA=
From: Jahan Murudi 
To: Julien Grall , "Orzel, Michal" ,
	"xen-devel@lists.xenproject.org" 
CC: Stefano Stabellini , Bertrand Marquis
	, Volodymyr Babchuk 
Subject: RE: [PATCH] xen/arm: Enhance IPMMU-VMSA driver robustness and debug
 output
Thread-Topic: [PATCH] xen/arm: Enhance IPMMU-VMSA driver robustness and debug
 output
Thread-Index: AQHb4c6ALl3IHvqkBEOgbLXzyjOhU7QQXHcAgANRIGCAABW5gIAHh3bA
Date: Mon, 30 Jun 2025 06:37:59 +0000
Message-ID:
 
References: <20250620103123.2174529-1-jahan.murudi.zg@renesas.com>
 <445c5594-a003-4cd8-aa46-8544c0543b1c@amd.com>
 
 <52b27bae-b182-488f-afcb-bdbfbc1a495e@xen.org>
In-Reply-To: <52b27bae-b182-488f-afcb-bdbfbc1a495e@xen.org>
Accept-Language: en-IN, kn-IN, 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=renesas.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: OSOPR01MB12408:EE_|TYCPR01MB11372:EE_
x-ms-office365-filtering-correlation-id: 273a8b68-0a54-4a57-f09e-08ddb7a0a81a
x-ld-processed: 53d82571-da19-47e4-9cb4-625a166a4a2a,ExtAddr
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?anNzM0pDYlpkN0x4RXlibnFHUFFCeCtsKzQ1QzlScFhqUkdDN1dhV1d4cnZp?=
 =?utf-8?B?YzFWQmJpSmt4UkN3NWZ4WmdlS0xaTnVpNkF5b1lkekN2ZFgzcWxnNzNxRUdT?=
 =?utf-8?B?L2ZIbWFPVm5OclUvWktDQ2cxZUlaa284d2llR0trS0ErSC9xK01GbHBmQ2Qw?=
 =?utf-8?B?aTAxSGZSaTZIeU1rbG55VlNDU2NVcXNYMk1UTWRIK3JzWDh5MS8yd2gzWllB?=
 =?utf-8?B?TjFra0VRUExGZko4Wm9HWW9SaG1QR3d2VTh4VGxhc2NyVTNtdmgybVFoQ05u?=
 =?utf-8?B?cVRKWDdEdVZZTFFlYVRqT3BXS09lVGZNb0wvdWZYdGtsQmFXYzM1LzNaeXFs?=
 =?utf-8?B?TmozZ2dPcGh1WVF4dTREZkFFM2hXbnRWbTFpYlNVQTBiWTcwRU9WS0RDUXdZ?=
 =?utf-8?B?TGx1VVpVL21FRjVZb3I3STN2QmdCcWlpTlZZTnR5bGxQTXdkaUZCd2xIL3RY?=
 =?utf-8?B?YzJLVCswNzd0Mm1MZ1RiR0JWeU1ERDhzb3ppc0FaQ2tHWmk4Y1hWbGZoenJV?=
 =?utf-8?B?WnFaek9SZy83VHc5SXVHbUhXcytJZmdhd1lSTVY0aU8vQU9DWTBrVHFWREh1?=
 =?utf-8?B?VldUNWNDTWt3T3NicFMzMlZSNXFTY2NSQThTUHoyYytoTDRBenZOWkNhWGc2?=
 =?utf-8?B?YWhWK3IrNDdrc0RTU09ScDhQR3AyL2dlRlFGeXFvUlFzMnVMSXUvaEt5OEVF?=
 =?utf-8?B?bFBHSlZSVzl2YUt3REhndjJaSHN3cVJzc2FmemVva3VRZTRzejdxVTd1Vm5C?=
 =?utf-8?B?Q3hGUzZFQTE3MU8rbzRCZkJRTXVrY2JuL3d0cnFQTGY3b0EyMCsySnF1anRk?=
 =?utf-8?B?SXRjSm5zRkJqSmpEQkpZZ3NnYmdiT3l0UkJGbkFOOXR4WE5wY2hIVmpVUWVl?=
 =?utf-8?B?NFo4bTZvYTJZVzc3U3JNWVl1TStlMW9wN1ZySEo5eWpOVUlrSXJzdmNXdFhk?=
 =?utf-8?B?SnhHSmRSWElueEhxWDk5ZDUwcTd5QjQwZk51MHVrMFBYUVVHU092WUcweTU0?=
 =?utf-8?B?OVh5RG1ndmUrTWVxZFpVUWpFSXc2WGp6VEVtS0dkcitLUmUzVzBocXBJbXpP?=
 =?utf-8?B?NFhuWnUyemJBbHdrRFhXOE1Uc3BRZlJiTDUrclplSmRsT1lSUVN4dTBYNmtG?=
 =?utf-8?B?dkRxN0QxeHlNaVgweForaHVZSnpNRUowVDBPb1BiUXJzaUN3OUl3TkMrOUxk?=
 =?utf-8?B?dERoc29kY0dBVGt0V1lyZ05ldGpIYkk3dTYrTmR0eW0wZW1rWjZVL0JpQStC?=
 =?utf-8?B?elhVVmNSczlOcjVraHU1VDViemtDZzhlckloTXQ4eXBIOU96ZGxWbEpTZ1Zj?=
 =?utf-8?B?eVZDdEFJUFk3WjAxTEhQL1MyQk41bjE2NkhMRi83N0x6SC9tVTFsSmZKNTZw?=
 =?utf-8?B?VjJEVklMQTVLbGYyMjNyUXNJS2NyZWQ1WDlENXg1aFpCSGtJaDc4c3dSUkxD?=
 =?utf-8?B?WTdvbndtbW5RaVRmRjhJL0lway9yVzBXRzhKTkluTm15U3dsb29kWTBLaDBZ?=
 =?utf-8?B?dkpadm9FQ3QvNkl5SVFTUmNYVDBjd1Y5S2Y1TzN4YkNESitDa3YxSGtqVUl0?=
 =?utf-8?B?a1dnNE5RS3ptMWp5QlVjSzNzczZQNEdzQkt4VzdYN2pJUFBiOEpwdStYQ0RJ?=
 =?utf-8?B?cHhPY2JXd3VWVE0rcm9TZnNSN1NYUUxUenhEWUR0cm1hQ3E1QWpJNU42bFVC?=
 =?utf-8?B?ZFN0NnBzd3FOK2ZTM2FUUUNYZWdrNTVyQTB0MGhiOXdUTjZ5UTJtQVExeG90?=
 =?utf-8?B?blBCejBaMDBFYnVocEJBRkJiNVNnK01xMmFGWGltUmloT3ZOSW44MjJ3RlRQ?=
 =?utf-8?B?MlkyOG11cmU1aG1nOXpJa0RtZDhXQS9kNHVESGZ0TmZrbStKajdsMmptdWhO?=
 =?utf-8?B?OFp0ZDlkbzFzeEFER09ZS1g5SGJTd1FITkFXNVk5blhqYVBNSjJYa3gwSFh5?=
 =?utf-8?B?V3gzejQ2YzNjU0RGdjlRV2xVVDhaZUE0Z1J3dXpJMHdZMHBDdG40MjA0anRu?=
 =?utf-8?B?eVV3V3JGYjNBPT0=?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:OSOPR01MB12408.jpnprd01.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?dmQwTDVOeW56VkxUMm83aUJ6Yi84MWwzMG5SYlRLVTNsNjNqd2RNQk5QVlUv?=
 =?utf-8?B?OFJkdnl6bmliUXVRTE5Tb1hwamEzSndPV2tENGhsaTNwSmdXb0NUb1BxbWZz?=
 =?utf-8?B?ZTBLeUszTHE5Z1hlQVRSTy92dUVDZW5YNHBTeCtCWk5OMS9vN3lPYU9IZjJn?=
 =?utf-8?B?ZHJPK1l2VkdrcjE4Y0wxN212ZWw0aWJBeFh6bnhvOS9hdGFGZHFCQ09SV09t?=
 =?utf-8?B?RE52YzJhV2F1d1pQSlhJaXhib0k3Q2dGWlBudDg0dk1jM2FVQWMwdHZUNFhC?=
 =?utf-8?B?cUhIZklmMXBRNUxHMkNFaXdRZFJiTlZJeTlXR2tCUURHdmRQQVh3V0NCbmg4?=
 =?utf-8?B?Zk9xSUpUdDNMbUxIK1NIcS9ZZ1M3SU4vOXdSeGtGMlJocEVFV08rZ0FJK1h4?=
 =?utf-8?B?R2Nub282cVpteTU0dDRZY2JTTnpUZHV1V3U4THFURERCbll0eG05VHRkRnRp?=
 =?utf-8?B?YUFXRERkRkxwWm9QQVMvNkVjcUZYVXJCY3g5dXB1M2xSeUxRaFVjNXRnR3pR?=
 =?utf-8?B?eC9vRnZOTW11Q0JBdUg2MVgvNmJ2V2Z5NnREMjQ0Mk5zWUd5K0xOZ1FIRGc2?=
 =?utf-8?B?Z2FOVTJ3MlUrMmUvcW5JdUQ4L000NmpNWW11T1lSK0RmcnhJK042STJrV0Fl?=
 =?utf-8?B?R3VyRzFYdVJQSTlFaTRlSHB4N0JyNWZ5aWhXRWlsK3J1anRXVk8yZTRnQjZV?=
 =?utf-8?B?MEZDZlo3WFhZaGJDSlBkVFlyQVZpMXR5Ni8wV000bU8vNXVuUkIycFFaSEt4?=
 =?utf-8?B?cytPQndTU0xmSnB1bGk0ZnlVL3lsMHF6WGtiZWx2aXdyaFZZYWdyQ3RDTjgy?=
 =?utf-8?B?ZDNTd2pYc1Y5eTVlS3dSQWpjQytaMFpWT0RqM1pjNzdzSXp1VCtWQ3hxWlcr?=
 =?utf-8?B?bEFZZHVIZGlCSzk1ZW9PenVkdksyRnh3NEZ6cmNSMTllSTJNZCtmMURYdFNa?=
 =?utf-8?B?aENGdDcvQ0MyeWVnY3dPRnFzTjNVU3Zud0h0T2VGNGNRRTBXcTd2Rm1Md0pU?=
 =?utf-8?B?blFZNXdRYXpMeEhLKzdrSTdsbUVWUVZhRGtsL2ovbnY5S3Q2QnlJUGxmTXRP?=
 =?utf-8?B?V1NmaVMwQUl4RVJMUW5LYlBQUVJ4elBpVjZ0VEIweHovbi9TVVFWZlRMYzgz?=
 =?utf-8?B?REtmd2dubnUxZDRGTHVpVVZCSVRQWTZvL3V6N21pTGxvT29KQW1pRkU1Y2ht?=
 =?utf-8?B?RHpqb1ZRUzdsbkJOb2ZlanpxL1BOLzY5alV4VkY1d0Ria2w0b0ZwdXRuaGFp?=
 =?utf-8?B?SWxCRi9UTGkxblZ4eGxsY3hFbk9LY3o1aXphVnRpNjQyc09YMkFOb0VMbzhY?=
 =?utf-8?B?RldsaFlzNGkwM3dyN1Mwd2c5L3huM3hDemZVS3krU2U0U3VYNDBocjZzUVMz?=
 =?utf-8?B?dENGZmNGaXgvQ1dLa0NzdU1NM0MxY05Maitjc3pLdGNhNXVWZkFSVXZuNDBl?=
 =?utf-8?B?MjVGNmxQRklFemxWVVNnU1R4akJGbVV3ZnBseFVycmdaZjh2Qm5Yb2s0ZWhv?=
 =?utf-8?B?STViSVNJVmJxTXJYWkRFS0FKVVJRLys0SDNkaUx3M05rNEorTmUrWkkxdGFB?=
 =?utf-8?B?UzZYaHlrbW5Dc3V0a3YzcFN0MHQ5RXJzTWlGeThlMW14WExIMHhNbVpFOW9m?=
 =?utf-8?B?aERNbVFsQm5pUFBYMlVkNFFPMzBJNWxtVUJJZER4V2VRaUM0RWhxYTdYaEJ2?=
 =?utf-8?B?UVRaRWN4bjR1bXgrcUhrZjVhanhSTVExVUgydWJCNFE5R2x2Y2VFYW02MXhp?=
 =?utf-8?B?YmJ2bWdoeGlUMVhSdlpJbHAxSFVmblZLbUk1TVlUc2dnZjFZTmR5SnM2MVZY?=
 =?utf-8?B?OGlOeUdNY0lQRVJJTis3ZCtLZGdLY05JbkNLM0dsOGFBVjE5bVlwQU5ZelJZ?=
 =?utf-8?B?QndLNXlyN0RhbVFiRm11SGsvM2JtUkRqWmpBaWRFeUtCM2hpbENscVR2R3Rj?=
 =?utf-8?B?MkMxeHc4ZHd5VktBcklxeDJhOCtiTTV4M3Q1TmpZb21ncGlvWmErbkQxRDV6?=
 =?utf-8?B?YUQybnRTcU9jZDJORjB2cXJOMmJ0ZE9HbGxvMXZBRzF5WUVyZGQ3MURDTHFy?=
 =?utf-8?B?N0NJanlEa1dQTXZnMHlkS1E4R1V0YjAwWGdBQ2ZvTktEODAzOXB2bXFqQTFs?=
 =?utf-8?B?dzd1TzcyY2I2UFlHTFNxeEdrcmtqaXcxdVZ6RHU2cGQwd2hRWFBvV0FDbTEv?=
 =?utf-8?B?Tnc9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: renesas.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: OSOPR01MB12408.jpnprd01.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 273a8b68-0a54-4a57-f09e-08ddb7a0a81a
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2025 06:37:59.9068
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 53d82571-da19-47e4-9cb4-625a166a4a2a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: VvG14ON+Sit8/AFsApr7d95gZUlfGMaL5naa4tmJhneCy28MFF6VYx6wLqb/qWDV/Oo23DpSREn/pNSoGlwGtHMrMnzlYK9ueohfdHjqEb4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYCPR01MB11372

SGkgSnVsaWVuLA0KDQpPbiAyNS8wNi8yMDI1IDE2OjUzLCBKdWxpZW4gR3JhbGwgd3JvdGU6DQoN
Cj5IaSBKYWhhbiwNCg0KPj4+PiArICAgIGRzYihzeSk7DQo+Pj4gQW55IGNsdWUgd2h5IExpbnV4
IChtYWlubGluZSkgZG9lcyBub3QgZG8gdGhhdD8NCg0KPiBPbmUgcHJvY2VzcyByZW1hcmssIHdl
IHR5cGljYWxseSBjb21tZW50IGlubGluZSByYXRoZXIgdGhhbiBwYXN0aW5nIGEgcXVvdGUgYW5k
IHJlcGx5aW5nIGF0IHRoZSB0b3Agb2YgdGhlIGUtbWFpbC4NCg0KIFRoYW5rcyBmb3IgdGhlIHN0
eWxlIG5vdGUgLSBJJ2xsIGZvbGxvdyB0aGUgaW5saW5lIGNvbW1lbnRpbmcgY29udmVudGlvbiBt
b3ZpbmcgZm9yd2FyZC4NCg0KPj4gVGhlIGltcGxlbWVudGF0aW9uIHdyaXRlbCgpIHdoaWNoIGNv
bnRhaW5zIGFuIGltcGxpY2l0IGRzYihzdCkgd2hpY2ggbGlrZWx5IHN1ZmZpY2llbnQgZm9yIExp
bnV4IGZvciBpdHMgU3RhZ2UtMSBJT01NVSB1c2FnZSB3aGVyZSBDUFUgYW5kIElPTU1VIGludGVy
YWN0aW9ucyBhcmUgY29oZXJlbnQuDQo+PiBIb3dldmVyLCBYZW4gdXNlcyB0aGUgSVBNTVUgYXMg
YSBTdGFnZS0yIElPTU1VIGZvciBub24tY29oZXJlbnQgRE1BIG9wZXJhdGlvbnMgKHN1Y2ggYXMg
UENJZSBwYXNzdGhyb3VnaCksIHJlcXVpcmluZyB0aGUgc3Ryb25nZXIgZHNiKHN5KSB0byBlbnN1
cmUgd3JpdGVzIGZ1bGx5IHByb3BhZ2F0ZSB0byB0aGUgSVBNTVUgPj5oYXJkd2FyZSBiZWZvcmUg
Y29udGludWluZy4NCg0KPiBJIGRvbid0IGZvbGxvdy4gQXJlIHlvdSBzYXlpbmcgdGhlIElQTU1V
IGRyaXZlciBpbiBMaW51eCBkb2Vzbid0IG5vbi1jb2hlcmVudCBETUEgb3BlcmF0aW9ucz8NCg0K
TGV0IG1lIGNsYXJpZnkgbXkgdW5kZXJzdGFuZGluZzogIEluIG5hdGl2ZSBMaW51eCwgdGhlIElP
TU1VIHdvcmtzIGF0IHN0YWdlLTEgKFZBIC0+IFBBKSBhbmQgdHlwaWNhbGx5IGFzc3VtZXMgY29o
ZXJlbmN5IGJldHdlZW4gQ1BVIGFuZCBJT01NVS4gVGhlIGltcGxpY2l0IGRzYihzdCkgaW4gd3Jp
dGVsKCkgaXMgZW5vdWdoIHRoZXJlLiBCdXQgaW4gWGVuLCB3ZSB1c2UgdGhpcyBhcyBzdGFnZS0y
IChHUEEgLT4gSFBBKSBmb3IgY2FzZXMgbGlrZSBQQ0kgcGFzc3Rocm91Z2ggd2hlcmUgZGV2aWNl
cyBtaWdodCBiZSBub24tY29oZXJlbnQuIFdlIG1pZ2h0IG5lZWQgc3Ryb25nZXIgYmFycmllciBk
c2Ioc3kpIGluIHhlbiBiZWNhdXNlOiAxKSBXZSBjYW4ndCBhc3N1bWUgdGhlIFRMQiB3YWxrZXIg
aXMgY29oZXJlbnQgZm9yIHN0YWdlIC0yIGFuZCB3ZSBtdXN0IGFsc28gcHJldmVudChtaW5pbWlz
ZSkgYW55IERNQSBvcGVyYXRpb25zIGR1cmluZyBUTEIgaW52YWxpZGF0aW9uKCBvYnNlcnZlZCBz
b21lIElQTU1VIGhhcmR3YXJlIGxpbWl0YXRpb25zIGluIHRoZSBkb2N1bWVudGF0aW9uKSAuDQoN
Cj4gQnV0IGV2ZW4gaWYgdGhhdCdzIHRoZSBjYXNlLCBJIHN0aWxsIGRvbid0IHNlZSB3aHkgbm9u
LWNvaGVyZW50IERNQSB3b3VsZCBtYXR0ZXIuIEZyb20gbXkgdW5kZXJzdGFuZGluZywgaGVyZSB3
ZSB3YW50IHRvIG1ha2Ugc3VyZSB0aGUgVExCIHdhbGtlciBzZWVzIHRoZSBjaGFuZ2UgYmVmb3Jl
IHRoZSBmbHVzaC4NCj4gU28gaWYgdGhlIFRMQiB3YWxrZXIgaXMgY29oZXJlbnQgd2l0aCB0aGUg
cmVzdCBvZiB0aGUgc3lzdGVtLiBUaGVuIGl0IHdvdWxkIGJlIHNpbWlsYXIgdG8gdGhlIENQVSBU
TEJzIHdoZXJlIHdlIG9ubHkgbmVlZCBhICJkc2Igc3QiICh3ZWxsIHdlIHVzZSAibnNoc3QiIGJl
Y2F1c2UgdGhlIFRMQiBpcyBpbiBub24tc2hhcmVhYmxlIGRvbWFpbikuDQo+IElmIHRoZSB3YWxr
ZXIgaXMgbm90IGNvaGVyZW50LCB0aGVuIHRoYXQncyBhIGRpZmZlcmVudCB0b3BpYy4NCg0KWW91
J3JlIGNvcnJlY3QgdGhhdCBkc2Ioc3QpIHdvdWxkIHN1ZmZpY2UgaW4gYW4gaWRlYWwgY29oZXJl
bnQgc3lzdGVtLiBIb3dldmVyLCB3aXRoIFBDSSBwYXNzdGhyb3VnaCB3ZSBtdXN0IGhhbmRsZSBu
b24tY29oZXJlbnQgZGV2aWNlcy4gV2hpbGUgZHNiKHN0KSBlbnN1cmVzIHdyaXRlcyBjb21wbGV0
ZSwgZHNiKHN5KSBwcm92aWRlcyB0aGUgc3Ryb25nZXIgc3lzdGVtLXdpZGUgdmlzaWJpbGl0eSB3
ZSBuZWVkIC0gZ3VhcmFudGVlaW5nIGFsbCBjb21wb25lbnRzIChpbmNsdWRpbmcgbm9uLWNvaGVy
ZW50IGRldmljZXMpIHNlZSB0aGUgY2hhbmdlcyBiZWZvcmUgcHJvY2VlZGluZy4NCg0KPiBBbnl3
YXksIEkgYW0gbm90IGFnYWluc3QgdXNpbmcgImRzYihzeSkiLiBJdCBpcyBzdHJvbmdlciB0aGFu
IG5lY2Vzc2FyeSBidXQgYWxzbyBwcm9iYWJseSBub3QgYSBtYXNzaXZlIGRlYWwgaW4gdGhlIFRM
QiBmbHVzaCBwYXRoLg0KDQpUaGFuayB5b3UuIEkgYWdyZWUgdGhlIHBlcmZvcm1hbmNlIGltcGFj
dCBpcyBuZWdsaWdpYmxlIGluIHRoZSBmbHVzaCBwYXRoLCBhbmQgaXQncyBiZXR0ZXIgdG8gYmUg
c2FmZSB3aGVuIGRlYWxpbmcgd2l0aCBwYXNzdGhyb3VnaCBkZXZpY2VzIGluIHhlbi4NCg0KUmVn
YXJkcywNCkphaGFuIE11cnVkaQ0K


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 07:38:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 07:38:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1028879.1402548 (Exim 4.92)
	(envelope-from )
	id 1uW95y-00060K-DP; Mon, 30 Jun 2025 07:38:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1028879.1402548; Mon, 30 Jun 2025 07:38:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uW95y-00060D-AT; Mon, 30 Jun 2025 07:38:30 +0000
Received: by outflank-mailman (input) for mailman id 1028879;
 Mon, 30 Jun 2025 07:38: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 1uW95x-000607-6l
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 07:38:29 +0000
Received: from OSPPR02CU001.outbound.protection.outlook.com
 (mail-norwayeastazlp170130007.outbound.protection.outlook.com
 [2a01:111:f403:c20f::7])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 35a6bd7e-5585-11f0-a312-13f23c93f187;
 Mon, 30 Jun 2025 09:38:27 +0200 (CEST)
Received: from DB8PR06CA0062.eurprd06.prod.outlook.com (2603:10a6:10:120::36)
 by AS2PR08MB9641.eurprd08.prod.outlook.com (2603:10a6:20b:60a::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8857.28; Mon, 30 Jun
 2025 07:38:22 +0000
Received: from DU2PEPF0001E9BF.eurprd03.prod.outlook.com
 (2603:10a6:10:120:cafe::79) by DB8PR06CA0062.outlook.office365.com
 (2603:10a6:10:120::36) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8880.30 via Frontend Transport; Mon,
 30 Jun 2025 07:38:22 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 DU2PEPF0001E9BF.mail.protection.outlook.com (10.167.8.68) with Microsoft SMTP
 Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8880.14 via
 Frontend Transport; Mon, 30 Jun 2025 07:38:21 +0000
Received: from DU2PR08MB7272.eurprd08.prod.outlook.com (2603:10a6:10:2d7::16)
 by AS2PR08MB9595.eurprd08.prod.outlook.com (2603:10a6:20b:609::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.22; Mon, 30 Jun
 2025 07:37:47 +0000
Received: from DU2PR08MB7272.eurprd08.prod.outlook.com
 ([fe80::ab1e:55db:9d8:afbc]) by DU2PR08MB7272.eurprd08.prod.outlook.com
 ([fe80::ab1e:55db:9d8:afbc%7]) with mapi id 15.20.8880.030; Mon, 30 Jun 2025
 07:37:47 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 35a6bd7e-5585-11f0-a312-13f23c93f187
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=E4qk3pESZtJMTpyTPBKewly0Gx0vAEGG734+al38ozisq41Q1hvtX86YiozqA/hPQXFIFavJFtcUBSGHlC+0g0PBNh55+2chPKKBX5nFMxNfevxQVh2G4feOsbJt6xVKjbiSh9LTrfODcj9XvnpBmo2hXp4wJfnoiyeAD26nPPI8zJZbil3kJijiz1oXe7dCaN4tJQQEq9EYaBVNDJ3RMfMJssyPiHljoVmhwQy/H5EzQwByuoFnQvdoQEV0NQJ2dUJMF5ZDL2V+4/sZdHrrfI6omc3e51MKXJmv2XtRFxa7jebEh1qotSvcLK2R11y2E9RV7UJEPB3v2X9CoKRUbA==
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=peA+UmPyEvP+3FcgYX5ahP2mIrSZxO78lzjDHiF/nqQ=;
 b=d53D2DKISqU47z9KaEeAXhHHq+qCb2sDCg7fSFD15JWGIgE5AYJL6y74SNI/hXqFtWSO4vwT9SG/95n1KErpwYGAVSvP/D+hhs37fhJrMbLYnnh8XvEVAV68IORyPAK5Mldqwppx7sNLEpdIbIoMk/Z4tgE5vlPe2b9WLBJ+tEE+YCkN8YsYLO75NzPPxF+jbWguIQf8uJdTbfNZy4vCuM5jfyyy7hWiJH1puvA+C6ZHzlmb9cOwDOPkN8URSCNOwsGnyRJt9sUhgLCgh2lmol3X4Oy8hfb2ZFT30is01t+mNtiZKdcZGS6PknmlmMgINcNZZy0mD6vtuBLk0fo6ig==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=amd.com smtp.mailfrom=arm.com; dmarc=pass
 (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
 (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=peA+UmPyEvP+3FcgYX5ahP2mIrSZxO78lzjDHiF/nqQ=;
 b=ji6FZxSQLzdCyemPagk5VtJH5dDBKExaEYVXdpS5qP3JZPkTY6IKmAh4FSgQKGxK9ZtC0DS5bxPaAqp15NKg81ehdAA7hHhl3sRdgR0vv3/wF0+b2ulQEvtv8UQbtajfI2dmb5OSicp0MH8/gVcYm3Z04Qpc8gVUSdzz+cXySWU=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=wBNLxhBlqsLcIO70KxOhP0EDi7XMerwNMFWNWM1NNLgnTrXMC4qkt/AVWC20owZl1KYrjEwWfqHMn8o0VQERhXvECSVMld/5BS5qSfG+pvsbaQ/7VbZb9MaytdMU0NcbXsIDR8Gbb0HlkyjClN3U2zZ2ihDotqMMxUKgUzAWsAmUfSHv9K+NQk+AnTX6PtGCmfHANqO6WHHqU2st/6SOrTVENfPcY5+9TYdTK82clgNf6OUsgHCEeQCqeWArW5A+HwFG+ISvjjR1Y5k/Ok9h6ehxYQMG894l1OoBWsjLT/2ZnyHgTKyMuMiNUmk0E9ZIrJlzpWgGCNLHqRXa8JGReg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=peA+UmPyEvP+3FcgYX5ahP2mIrSZxO78lzjDHiF/nqQ=;
 b=tScdID4/gsQPRt7dqUtx0aWnbs0aJNnmQYmkiVbqYFPpyVCMo+kEbbP/Gz+262XHjhUj/T+grbi8JpRh8YQgddsK4FkrJafXpfJxfcDZrZtKIMq0U1g1BWDPTAMOyD4P8HL4AWxDRyXLkbcZtN3Ecm43m5l8jg9V6wfQXhPKq9PCzgcGb2Zkiw7Yw5f2MnHicjEfNEMK8xKOrLuliUm1F03mvNMa65pYwwIdLeEdH2rYx+0KDoNrnOm97IHlR+8vQISXnjpf04pmQIxVKZcUhs7yo/vzG0HYqukf3g8jhMXOLTsizaoF65tGIS9hgTz7Eh11E3ZkQW6uA/5fp5i/Mw==
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=peA+UmPyEvP+3FcgYX5ahP2mIrSZxO78lzjDHiF/nqQ=;
 b=ji6FZxSQLzdCyemPagk5VtJH5dDBKExaEYVXdpS5qP3JZPkTY6IKmAh4FSgQKGxK9ZtC0DS5bxPaAqp15NKg81ehdAA7hHhl3sRdgR0vv3/wF0+b2ulQEvtv8UQbtajfI2dmb5OSicp0MH8/gVcYm3Z04Qpc8gVUSdzz+cXySWU=
From: Luca Fancellu 
To: Michal Orzel 
CC: "xen-devel@lists.xenproject.org" , Stefano
 Stabellini , Julien Grall , Bertrand
 Marquis , Volodymyr Babchuk
	
Subject: Re: [PATCH] xen/arm: Fix booting hwdom/1:1 domU with
 CONFIG_GRANT_TABLE=n
Thread-Topic: [PATCH] xen/arm: Fix booting hwdom/1:1 domU with
 CONFIG_GRANT_TABLE=n
Thread-Index: AQHb5bnKrH6hbt4bekO2oCqePGx44bQbWCiA
Date: Mon, 30 Jun 2025 07:37:47 +0000
Message-ID: <1EF5D001-222C-4FBF-BAC1-FA1A2D4BFCA7@arm.com>
References: <20250625101230.49653-1-michal.orzel@amd.com>
In-Reply-To: <20250625101230.49653-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.600.51.1.1)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DU2PR08MB7272:EE_|AS2PR08MB9595:EE_|DU2PEPF0001E9BF:EE_|AS2PR08MB9641:EE_
X-MS-Office365-Filtering-Correlation-Id: 1f72e087-ae4d-48b0-674e-08ddb7a916e6
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?OFRXVnlteCtTTG4wTmFlUHJITG5xQTVGVWRUNGYyblhyS3NpTUN4RnlPcytY?=
 =?utf-8?B?d0ZSblZDYXczU0JZQUxMdU1WemgvZXI3RFRiOVpmU2JrWTZwM2tHa0QrcTN0?=
 =?utf-8?B?UHU0TWM4ZWZyTFBZWkNkWEZWa29FVmRldGxBZ20raXBvUmRWWWJCZ0cvT1Bu?=
 =?utf-8?B?VFZYdnJWc3FsMkR1eDdiUHYyZEdJN3BLN3o4WjBZVTJLd01vVVRIWFZMb0VU?=
 =?utf-8?B?aGljNCtBSDcxaU1EUU1kYkJtTE16Q3ozWXJmOTZVcWkzeWRUdFhSRDBSSzRM?=
 =?utf-8?B?MTU2NG5zVHNmSkdIazgycVpxcmd0TEN6T0pINUEyWnRlMW5xUGFHOW5QRkNZ?=
 =?utf-8?B?YnVWZ2N2ek1vWHdocHBjUWljUjdFd0VDYlBYd2pFT3VhZ2w4NmNIeURhTlU5?=
 =?utf-8?B?ajdOUXVBUy9MQVMwcUQ2MTZlZUJVTVZWQmFhY3BoeW5iVlZpL3R5eFRuc2lV?=
 =?utf-8?B?KzZ0blpuVjF0QjgyQlBMaXRDVTZPTWZLU0M5YU9MV0JCUWZ2U2UxNFBIK3Ro?=
 =?utf-8?B?QXBrS3hrQlpXVE82NHp5a2hFSllTQ0xsbTZkMGtYZWpLWWxXelZveUpLcFZh?=
 =?utf-8?B?SVJDOHlySGVCY2wvRzJxQWZPQU9KVzc3T3prMVVRZWJ2VzFSc2VMOTgxMzZE?=
 =?utf-8?B?ME9OZmlpd2JCN2F5c3JNaVV6dGhzNW1IbHIyb1N3cFRtVCtvVEVPb0ptV29O?=
 =?utf-8?B?L0E2TVBrdzdSQXd3Nkx6NU96V1I3T1lMVEwzN1ppcS9MTlo1eGNIVXpqMmo1?=
 =?utf-8?B?NWJOZTVCbm45UTJoa3RUNnlzeFRqOTRHRTJaT3NqcFJremRPU0gzR0xJS1Mz?=
 =?utf-8?B?cjZkWi9oMzVQTUtkRzN5Nzl4TERyWWp5Y1RoTk5Sa1JuL2QrWlFzVmRqRjc0?=
 =?utf-8?B?eHdGaWh0NEVJRlpCWmY3ZHFsYW01SWNhVzhyUXR4dmNLbkVoUHFNVzFQNSt2?=
 =?utf-8?B?eEN5MEdyNU9oSStQQVUwY0UvZnZScWd5K1B5aXBuVmR6TmZBV2ZHa3phNmRy?=
 =?utf-8?B?dWd2MVprQytFNEtnNnhDMjEzQ25VTmRtcWczOUtlM0d1V1BxbHkwOEhsdWFa?=
 =?utf-8?B?dFlWTmM0QmgzbS9lNGRvNi9qZEpHT2RqMUNMZTdXTE9HWVhYZkFNTmt6U2Zi?=
 =?utf-8?B?V3pXejVrdDcyV3NnRFMxYXI0SlVKL2o1ZEowUEJqUytUT1BMRS9IVzExbGJJ?=
 =?utf-8?B?MDJuK1lRWHRXY2lFbEtFVTNPbUw1NVZzaGpJQmlTOEw3V25zREQvRUtBZFNm?=
 =?utf-8?B?Rmx4WHlGTzdnWEthOElNYk5SMzBXclZWeFlzZVQ5UkhRb280aytZOVBEQjVL?=
 =?utf-8?B?cHA2elNYc0gyMDhDMGJOSzQ3dGhpSW1EWjd1Q2IxK2VGOUJDYlF5WGVqZkY4?=
 =?utf-8?B?dnBpWDBzY05rOFdtM3o1RXl4QWprY3MwRlBpa2NsVlZOM2pzSXM0U1Z4bXor?=
 =?utf-8?B?QTVweGV3RDdia2RhUlZTZFVSSUE0RjNMNmJmc2xDa0l2QkhHeENYV2tIOHNN?=
 =?utf-8?B?dklOV3NycEZnSTVieDlyMUFZRlZQL1VnUi9EQnpvYVJSd0tyM240VmFyaXdm?=
 =?utf-8?B?VHBZQ1A4RDJrSzJMZjRIRU9ZcHpKdzVxY0NuVWNiZ0czUDMzUkdvVTVpem5q?=
 =?utf-8?B?Vis5eElIeCtJd20vQ2w2clRnNENySjRnWjFxeG1CMkF5Z2NFZlJuOUlCWGY1?=
 =?utf-8?B?VVRXdG55ZzhjR01wTkt3dmc0K0Z5UHRHY28xekNlOWpncGtOZTMvRTRJdG1D?=
 =?utf-8?B?TWVHV3pNaFo3K0lLaEx6b29HWWh3eU9BNGNhQ1dtdDc3QzRZY3ZmT0szTUM1?=
 =?utf-8?B?bWxjS3pMOW5zU3hUdlpEK2trT1o3MG5DMkhwMkRuWmVKTUJaTnI5TXBDNlY4?=
 =?utf-8?B?dDFPa0hTNXdSZWtxR3F6NTUvWlNvUDdDdWRqMFhiZWhLQWJPM3o3Q3h2SW0r?=
 =?utf-8?B?Q3hQVGRWVUpqRkVPSWVyYUNWWnVlRWRTTEpKZXZVZXdQcyt4S3dRSUtpOFM1?=
 =?utf-8?B?V1h3VzJpSjlnPT0=?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU2PR08MB7272.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: AS2PR08MB9595
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DU2PEPF0001E9BF.eurprd03.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	c97924ed-9276-4fc8-407c-08ddb7a90286
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|376014|35042699022|82310400026|14060799003|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?Z1F4V2ZmSUJFektRZXJIa25FL1J5SlBneUJTMGpFMVIweXZZemc4QnhIS2Nx?=
 =?utf-8?B?Z21XOVBqUFMvS1dERFlReWtyK3l6ZUF1UXpaL2JSZkNjRWtjZVZweU5ZZG5Q?=
 =?utf-8?B?M1hzeHZRQW80RXZEUDllVXhYaUtLV0k2bHpNbmNPcVVhVU12cm9ybGhGaVpE?=
 =?utf-8?B?K2M2NXRjQVJkbUg5U0dDYVhOZE5pTDFqcUE2WGFEbmVTWVNMVWNjbTQwME5J?=
 =?utf-8?B?cldpTit2ZmJQRHlvMVNTczE5ZU5SNkJoVFBqQWxMUzB1L1B3RTd2V1ovaVU5?=
 =?utf-8?B?cjNvWUhleDNZRFBZQ3dDMVIxUzA0WWpWSmxNSGNNL040TkZNeTYvNDJJYUpj?=
 =?utf-8?B?YUNVL05UZTdiYkJka1ZySVZlVmJtK0ovcXdqWWpBOHI4R0s4d2lCVUxZbmhK?=
 =?utf-8?B?ZndQWFkwY3dhY21CdFNRUnIwb2wwaE1QZE5lQmdnWFpxeTdXVGVzNHVjYkFv?=
 =?utf-8?B?dDRlN1JXWTF4b2RSV3lPME5acit5YjZSVlU5YTV0YnZ4ZWp3SU1JQkhPZTFB?=
 =?utf-8?B?L1BPMU9oZmhFNEtjN0tRc0xhcWlDdnExdnNqYmszdThadWYyd0dUeWZRVHdq?=
 =?utf-8?B?SzVhU0FmTWhrR2lNWjlScE1FRWNPdmZneUY1Y3NIcGtYYy83RzFNWGJHU1Z4?=
 =?utf-8?B?OEp2TU51ZGpxdmo2MU01Zkx2ZGFrSnpUYkRUM29FRG1TQ0xjd0pvTHI5VitO?=
 =?utf-8?B?c1JKMEJyU0E0dUNuWnJlM1dvTFR3a3VDMWk4NHRPL1kvN2lKMGw3QnNKZ3lS?=
 =?utf-8?B?cUYzYTJGdldZT3dlTG0xQjFBdmQveEszQWFpb0tpODNWTUE2OG52eHhhQ1ZV?=
 =?utf-8?B?TEJOR2x6aEM0NmppRWFkNnVKdGVwUUJmT0xXZkY0bCt6ZkhPTWJ4aW9xYnJB?=
 =?utf-8?B?bFRnL285YlhOMUN1Mzd1Z0JLL2VFelFjRVdyUjlMRGZhb05yTmVMd3o0ZHQx?=
 =?utf-8?B?c2hZWXh5NFhrMFFGY2dUVU5MdGtjeU1ESVFjSXdTSmNmaDR4cXlIZGdRdXJD?=
 =?utf-8?B?SDIwTEpVUVpzQ05ybmg2QnRsOU1iZzB5bjV6SjRoYTR1ajRQZWhveWMyS3B6?=
 =?utf-8?B?UnMxdnd1K0EyUTZJWHVkTytRMUh6eTdmeW9sRTdkaStNdmxUV1YyQ1RvOEp6?=
 =?utf-8?B?S1NWS2RqQ2tKcDY5NGE4NXB0azJXbzhvc2FaRU4vdG5rTFI2MFVnUktCY1k2?=
 =?utf-8?B?QSszVXNEQU9rL1U4TkpHOWxodVJmUmtkRC9wM1UrY2pGb2lNTEFWQXBzNi9w?=
 =?utf-8?B?dGlNaDl4Qy9wOEQzZnRURW9OakFCMXprbkhiVWoxNjQvbk9zY1U3ODZtRGVT?=
 =?utf-8?B?WkI3Z0pWYjRKamVXR0JRcVA4YzdKM24vL3VvZkQrV3JPWGJMRnJYRFQwMXpI?=
 =?utf-8?B?aDRpVk9EM3FYL0w3TWRjdlQ1dVIzZ2tIZmVWaDJnamtRbGNLb2EvRndxampY?=
 =?utf-8?B?eURlWmxsYnFac2pORmRQMWdqakVjeGF4end5cmN2Nm9vTkpxS3BBOVlweXNh?=
 =?utf-8?B?ajBnbXhqVkFITlcyK2pZVDFSUFRhTEhzRStkWHc3SmY2MUZIeHN5NlU3ZXd4?=
 =?utf-8?B?cU5RYzM3NDRNcEt3QzNjRzdHZmx5RDdON2VxNWFpVnBocDArVDVXeHB5d2JR?=
 =?utf-8?B?SnZzeldwUjVxeE9BODZpNmwzbVBLVGNQUlBkZ1JKSFVrWFcraUJZc0hMRXB4?=
 =?utf-8?B?UkJTMFBrZlY5NDB5cWxRRnJFQ1FZbzRuK2ROQmN2Mkhoa01mZDlHTTVGdDdD?=
 =?utf-8?B?Y0NYTTBYOHZVZFdlU0FxS1R2KzV5T3Q2WGY4Y0RnK1ZvaTEydEFzUHI2b3Vs?=
 =?utf-8?B?V0t1dHk3S2Z4U2Q3L3Vhb21Vd1Z3ZjVWeUdmK0VJQjM0ai9vbkRzbmtHQUF2?=
 =?utf-8?B?TU9yQlYvL0FhZFJoUWhZMVd2M3lQUnhoMzhnb1hDRS9ldUdNMDRnWW9CRm9J?=
 =?utf-8?B?NGtRRElRa3ZrTVpsL00wL1c1cHVTTTV5bkF2U3hzNXh5S2dPZlpJeXF0bW5t?=
 =?utf-8?B?R1BtTWVMc2poV201M0kzc01ZNjA5MDhZYzIybUVaVCtaZmJndzEvaHJjYmlW?=
 =?utf-8?Q?iY/cjt?=
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(376014)(35042699022)(82310400026)(14060799003)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jun 2025 07:38:21.6930
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1f72e087-ae4d-48b0-674e-08ddb7a916e6
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DU2PEPF0001E9BF.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR08MB9641

SGkgTWljaGFsLA0KDQo+IE9uIDI1IEp1biAyMDI1LCBhdCAxMToxMiwgTWljaGFsIE9yemVsIDxt
aWNoYWwub3J6ZWxAYW1kLmNvbT4gd3JvdGU6DQo+IA0KPiBBdCB0aGUgbW9tZW50LCB3ZSB1bmNv
bmRpdGlvbmFsbHkgYWxsb2NhdGUgc3BhY2UgZm9yIGdyYW50IHRhYmxlIHJlZ2lvbg0KPiBtZW1i
YW5rIGFuZCBhZGQgaXQgaW4gdGhlIG1lbWJhbmtzIGFycmF5IHRvIGZpbmRfdW5hbGxvY2F0ZWRf
bWVtb3J5KCkgdG8NCj4gZmluZCB1bnVzZWQgbWVtb3J5LiBJbiBjYXNlIG9mIENPTkZJR19HUkFO
VF9UQUJMRT1uLCB0aGUgc2l6ZSBvZiB0aGUNCj4gcmVnaW9uIGlzIGVtcHR5IGFuZCBhc3NlcnRp
b24gaW4gcmFuZ2VzZXRfcmVtb3ZlX3JhbmdlKCkgZmFpbHMgd2hlbg0KPiBib290aW5nIGh3ZG9t
IG9yIDE6MSBkb21VIHdpdGhvdXQgSU9NTVUuIEV4YW1wbGU6DQo+IA0KPiAoWEVOKSBBc3NlcnRp
b24gJ3MgPD0gZScgZmFpbGVkIGF0IGNvbW1vbi9yYW5nZXNldC5jOjE4OQ0KPiAuLi4NCj4gKFhF
TikgWGVuIGNhbGwgdHJhY2U6DQo+IChYRU4pICAgIFs8MDAwMDBhMDAwMDIxOGI1Yz5dIHJhbmdl
c2V0X3JlbW92ZV9yYW5nZSsweGJjLzB4MmQ0IChQQykNCj4gKFhFTikgICAgWzwwMDAwMGEwMDAw
MmI4MzcwPl0gZmluZF91bmFsbG9jYXRlZF9tZW1vcnkrMHgxNDAvMHgyMDggKExSKQ0KPiAoWEVO
KSAgICBbPDAwMDAwYTAwMDAyY2MyOGM+XSBtYWtlX2h5cGVydmlzb3Jfbm9kZSsweDMxMC8weDdl
MA0KPiAuLi4NCj4gDQo+IFNhbWUgaXNzdWUgd291bGQgb2NjdXIgd2hlbiBib290aW5nIGh3ZG9t
IHdpdGggTExDIGNvbG9yaW5nIGVuYWJsZWQuDQo+IEZpeCBpdCBieSBwZXJmb3JtaW5nIGNvbmRp
dGlvbmFsIGFsbG9jYXRpb24gYW5kIGNvbmZpZ3VyYXRpb24uDQo+IA0KPiBTaWduZWQtb2ZmLWJ5
OiBNaWNoYWwgT3J6ZWwgPG1pY2hhbC5vcnplbEBhbWQuY29tPg0KDQpUaGUgcGF0Y2ggbG9va3Mg
Z29vZCB0byBtZSwgSeKAmXZlIHJlcHJvZHVjZWQgbG9jYWxseSB0aGUgaXNzdWUgYW5kIHRlc3Rl
ZCB0aGF0IHRoaXMgcGF0Y2gNCnNvbHZlcyBpdCwgdXNpbmcgRlZQLg0KDQpSZXZpZXdlZC1ieTog
THVjYSBGYW5jZWxsdSA8bHVjYS5mYW5jZWxsdUBhcm0uY29tPg0KVGVzdGVkLWJ5OiBMdWNhIEZh
bmNlbGx1IDxsdWNhLmZhbmNlbGx1QGFybS5jb20+DQoNCg==


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 07:57:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 07:57:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1028887.1402558 (Exim 4.92)
	(envelope-from )
	id 1uW9Oh-0000GV-T8; Mon, 30 Jun 2025 07:57:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1028887.1402558; Mon, 30 Jun 2025 07:57: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 1uW9Oh-0000GO-Pz; Mon, 30 Jun 2025 07:57:51 +0000
Received: by outflank-mailman (input) for mailman id 1028887;
 Mon, 30 Jun 2025 07: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 1uW9Oh-0000GI-2c
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 07:57:51 +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 e5374c88-5587-11f0-b894-0df219b8e170;
 Mon, 30 Jun 2025 09:57:40 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a6d77b43c9so1577785f8f.3
 for ; Mon, 30 Jun 2025 00:57:40 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b34e3200fedsm7454481a12.73.2025.06.30.00.57.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 30 Jun 2025 00:57:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e5374c88-5587-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1751270260; x=1751875060; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=9uTUQF15Koei34hJ1I+xq/5U9YI/aWamKphGGc7rMdw=;
        b=CbZqUFSfsl5+hXWQzmoosc44wJxJjpEzwH+Um4VveMF3LkfRN7Dnq0yzxA0MkdNADh
         DGxc2n/QAChee0Jj6zMqudwalxga7u37haYFW1TiYvxiJfixR6qHghyDprMZvrXaYSYP
         KSKY64KW2VIVoTdrj1U2hy0E+P0EG+5PWouM7Kv2OVmC9htmtMqpOsbMbEIpSaLmLY0x
         WsC7ly7NuhRUepvY3fXApvjcwPGCBbwuksZgR1I739IJURk2azpSxFqMwxXs7izW242v
         LkdQ9dITnbZmbLfaOnRF0OcpzHJGwzTiRtirvH7zyWbrWBMReXFJYitDcE6GtU2wVB/y
         NOCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751270260; x=1751875060;
        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=9uTUQF15Koei34hJ1I+xq/5U9YI/aWamKphGGc7rMdw=;
        b=pZSRGZhDolvcWU0AQpQcmDWWLIVEkoRk4cR+qlyoIB/Le1iF5wgTmF7l/cgMMJ1bOj
         y+doFeu5+qIAr5aEvYBO9ApWw3usgMZl16sAAgRk8DIURz44XL+NZG/q9JTWkQllIMZ0
         mjMzIrWBhkrGWv4zHXeWup1cnxYgCoXpDwwYmWYp27YeGqvePp56NOJ129A59af5lYpG
         eO9Ga/TXaSpzIpBB8Sn3KXWo0hmWhcNDX/8JF+NZ8j7cY+lbKDGbVSk6ECqABE6I6c9D
         LWNc3//bLeLxi5Co94DV23gXvuv1q09W8/tKCvkOvLExKSuWvjowA+g6HR0gYmB6yfj/
         4p5Q==
X-Forwarded-Encrypted: i=1; AJvYcCWNrlorwWzQbfGZ/Pw4Xc4bQUHAe2sYQS6Y5OtiSrf84HyjMgmNBCb10DKxlcYFx5GZToxrW4y81w4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyNHdvtjkU5tCNR904jYDLQL7+eRtCWn6Mr/8HWv4M6fCt9we4L
	AcBmNPwnOGHiI5xiczsCYnPyC9Hh83v7X4SjjRUVfaQbMsJTX2gXyVwM9NlAD73mHQ==
X-Gm-Gg: ASbGnctLRLAAt+e7fHFPoHpg7jXUtDeZQ6kvNadLJdDJ/67qyJBiMX9bqWC5BPDe1Fo
	t77IIz7KV3DxKiOyYULqOL68OTSZ4NZL3qdVcvhQaTDrcvb1wycXk9QXABhKlB57/i2lHXgvVnv
	BBWaNE+ZmhLkSm/sZGcnmDZQ7kPwucc+Fde1OMVETZkYoeM9lvejK1GeNFoOyN9eteeENyfW1H1
	cgg+gbBnza/fuMphSIXnB9kednngzI6kJ7OAWN358BOHbQ6r8fnTL2bNDFEr6CiQ6zCWMoYU8+B
	azvgyjmJW57rLCubb7BgWXHIUEU2VUyiswc+VD88PpSGDZBoyMsSeStHrRA71ek+O6piRK5/n9r
	L6HTMbFrW00ESt1mvpinSkBJKqGhJ9lEKvMGq+rm8R0XGJUU=
X-Google-Smtp-Source: AGHT+IFFjr6hm53/vwRg2fpm9ukw4HF7RwOREfTxaPBjMHNYimMGsgkGqNiaa3eC3ha17YyV7ePXoA==
X-Received: by 2002:adf:9d91:0:b0:3a5:2cf3:d6ab with SMTP id ffacd0b85a97d-3a8ff51fd1dmr9550580f8f.39.1751270259789;
        Mon, 30 Jun 2025 00:57:39 -0700 (PDT)
Message-ID: <5a423869-d67f-4a98-9fa4-e854bc84e2c7@suse.com>
Date: Mon, 30 Jun 2025 09:57:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 0/3] stubdom/grub: avoid relying on start_info
 definition
To: Juergen Gross 
Cc: Samuel Thibault ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250626151344.6971-1-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: <20250626151344.6971-1-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 26.06.2025 17:13, Juergen Gross wrote:
> With the related change having been added to Mini-OS, the single V1
> patch can now be expanded to a 3 patch series, especially meant to
> untangle the close dependencies between grub-pv and Mini-OS internals.
> 
> Changes in V2:
> - add comment to patch 1
> - added patches 2+3
> 
> Juergen Gross (3):
>   stubdom/grub: avoid relying on start_info definition
>   Config: update Mini-OS commit id
>   stubdom/grub: swap start_info usage with start_info_ptr

As patches 1 and 3 are still waiting for a maintainer ack, is patch 2 okay
to put in ahead of patch 1?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 08:01:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 08:01:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1028894.1402567 (Exim 4.92)
	(envelope-from )
	id 1uW9Sa-0002MI-EF; Mon, 30 Jun 2025 08:01:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1028894.1402567; Mon, 30 Jun 2025 08: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 1uW9Sa-0002MB-BT; Mon, 30 Jun 2025 08:01:52 +0000
Received: by outflank-mailman (input) for mailman id 1028894;
 Mon, 30 Jun 2025 08:01: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 1uW9SZ-0002M5-0N
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 08:01:51 +0000
Received: from AS8PR03CU001.outbound.protection.outlook.com
 (mail-westeuropeazlp170120005.outbound.protection.outlook.com
 [2a01:111:f403:c201::5])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7999d9b8-5588-11f0-a312-13f23c93f187;
 Mon, 30 Jun 2025 10:01:49 +0200 (CEST)
Received: from PAVPR03MB10142.eurprd03.prod.outlook.com
 (2603:10a6:102:32a::16) by PA1PR03MB10724.eurprd03.prod.outlook.com
 (2603:10a6:102:488::6) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8880.21; Mon, 30 Jun
 2025 08:01:47 +0000
Received: from PAVPR03MB10142.eurprd03.prod.outlook.com
 ([fe80::61c8:1ce8:e4ea:c673]) by PAVPR03MB10142.eurprd03.prod.outlook.com
 ([fe80::61c8:1ce8:e4ea:c673%3]) with mapi id 15.20.8880.027; Mon, 30 Jun 2025
 08:01:47 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7999d9b8-5588-11f0-a312-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=wgyuNFZHREPKpFUPtmOzL6aypLo/4rnPLxtGMRL+nQRvQ7vOBqDwPKfTP3UFWiWzLuEvCWbyULnTICP/tPWMtGZPBnWMs8guFVJOB6vbfxqcF/kN//lrzihUlO2diHdOK1o0gb3wbhK9TZjHuap/lET3BTWBMkHAjzfJo0BZm4/lEzzKV1PlBTGVzR149H9gsuCpJyWwyy2m/MvQ56Q3W9DY5Q6miSMyFVWUm3+t3Cgeuwb25UoHLOkxuvFdd1O2gCPMPoqSLsP7261cD/R+gE4+dPUWwin8aXD7wGRp8e55jKUMhS2StM6KecmVTZ0HIqoFY70nfcSXcyua/+RaPA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=gvzU/Y6IR77BtCJ1BMIGK/zyLTtZdScEZ6txdRAwZ6Y=;
 b=ToPVMFDkQjN2MT/D+pTeczQ7HbZq3YzDXm1ywpDoOOK0+y1UJO8Gl3z7g1XPUTsXFf7tsBOtYl3oGO/4PTYyT3h+WSQgnqIULehbGxWGW98y5+54i3PeTs0syKNi/8Bpw+FYgXAhQO0s4+tAjursRGZbENNcjxKF2tB2qAUhXQJKgP6u27BV6V+Qx0cS/BhtVyK7HNS6qjuU9681HagppoavC0NM57cZh4PuhB0wUQNV6m7LNVjAAh9Ci7c8QcB6ZXtekmWP7df2aIIt+X8LAXYKAcbFmsFPu9TYHHDYt2Qpvd3XF/EuXpXC4EILHgpMDJcfB7Ts6aFWOLPdpIVckA==
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=gvzU/Y6IR77BtCJ1BMIGK/zyLTtZdScEZ6txdRAwZ6Y=;
 b=QIkU88M5ZFPYtiK3nydAhnkJr6LEEuqTFnhoizhRC3fVyNsmkfcBcfASiF/dMvRTo/Y0zisf0Y+sjSDWhs2c8ZcDC4uh7y0D+KRpPV6RWPH1ZSPwcWEfSIbSfMQiVxKKku58T4jAUg6SgrdfjSmOr+GlYZFaGVlIGvC7uB8TVLTWl00Cok5F9gVNYirGOGwKJVvgYcqRxAFv34ZlybUiuI4TUS4vfb6YjB0wtxWMGI9tSOH0uHW9it0qb5nZS6uYFoQist7iXXGHYtHmcnCdANxRdklwcN88PnvX87oL0Zy06GJ+Jma0YFjMOlLpuFOe4xvB5Z7Scs4FHt/EgEPJDg==
From: Dmytro Prokopchuk1 
To: "xen-devel@lists.xenproject.org" 
CC: Dmytro Prokopchuk1 , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , Julien
 Grall , =?iso-8859-1?Q?Roger_Pau_Monn=E9?=
	, Stefano Stabellini 
Subject: [XEN PATCH] scripts/add_maintainers.pl: set double dashes for long
 options
Thread-Topic: [XEN PATCH] scripts/add_maintainers.pl: set double dashes for
 long options
Thread-Index: AQHb6ZU5GqvLxUb1v0eVLL/RYoouyw==
Date: Mon, 30 Jun 2025 08:01:46 +0000
Message-ID:
 <7f66cbd47f45b2cc442c541cd264a208ea1f406c.1751269784.git.dmytro_prokopchuk1@epam.com>
Accept-Language: en-US, uk-UA, ru-RU
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: PAVPR03MB10142:EE_|PA1PR03MB10724:EE_
x-ms-office365-filtering-correlation-id: c7fc3595-9308-4399-cc9a-08ddb7ac5c88
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|42112799006|366016|1800799024|376014|7053199007|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?mQylP8IRtYXUBy5skhKIx5qGnkwYOHfIxyL0h//rVeTZ4SynzwAg79C3qO?=
 =?iso-8859-1?Q?MsCVImdMNk4O502YlM3GPEs4vM5AzS3t5DKZUUnMMWc98Lar5zu0547S4u?=
 =?iso-8859-1?Q?7z2thuqJvZhGb+fKP6H08VmXtwyqMMzAR4plzYXuhcUVt7SZ/MXVquhp0g?=
 =?iso-8859-1?Q?LnjH3tVysX1auwMAPm1YghAecuZS8e9UbOj5Cs+xysCMCE66uju5QYy/Oy?=
 =?iso-8859-1?Q?C8OkudfvjRcTuzKQf5AhDoKc78TZ8gmk37c5UIGsCpRjAn7uUAzcG3+Qw+?=
 =?iso-8859-1?Q?N/qUTHIkrjInMjl0RX4/nyFQzqo6hFVYopry61io9qmPwL+AgTWSdAM4jm?=
 =?iso-8859-1?Q?2HcixdpekW2ddls8nYWueQa0wAh5bK5GYG4SaVKj4+aSBUe6QL/rZib4T1?=
 =?iso-8859-1?Q?s3yuIEB2Ger8/dZ/sMbyJMshje8NFgO4kWW/n53CHWdO0jXjmDAUBLAAuF?=
 =?iso-8859-1?Q?llTO029mg7InlNQY0Fweq1FKPLlukQAuUG2YwJ4pcZXFwPCvgErQijhYP5?=
 =?iso-8859-1?Q?23CWf1oYMv+fHRJkoe+9AhR4OFkIJuaXezV3jSyT8zMxzuInK7H/BYOiFA?=
 =?iso-8859-1?Q?WeWrdqK77vzG3ipz/HEZfOBCxcnzVYpt9BYk9qy+N9KgaLFx6vK5wWUNiV?=
 =?iso-8859-1?Q?KC45ablckB3i1VIlbOU8wb1ebLrbO/EzLgudsmZQdZ0tXk4t0kD3b4qipf?=
 =?iso-8859-1?Q?n+wD8Nq8Tsl2zHKKNOJaBYtjYnWNi0aWzVTMKe7vLRDuAUmMUKKwuEHX6m?=
 =?iso-8859-1?Q?0A0OBFg+bbNvwktTSXWp4GbcppfPWNvptgdKPNvD+sC8+QRJI1hPuBln5X?=
 =?iso-8859-1?Q?8t1VI3Yxn7InpN29W+Qal/cLDpjxibtGKN/iwUX8m5WvAIh7CDRq/qtqCC?=
 =?iso-8859-1?Q?SCp7RDuuYFz5Js/rZNv4cYA5GK+2H8fPXCdQK8+1lMpXchjHL67aN4Ptg/?=
 =?iso-8859-1?Q?9TGzliQA6HLqUi8b0ZHzGe5opiBEs7jFRI7uBKX0fbyiP+gqFsu6b5oAcp?=
 =?iso-8859-1?Q?MdNFcD5JXpg7/PaA1MVg7NAFhg0mlOqNv4NK5y+QanZr9SckD3hR4dShVA?=
 =?iso-8859-1?Q?IWCCN6g/fLmElW4MDhCY5cgr00nIRsSm2z/Z05YvJ2SmsIperwV/smYCH6?=
 =?iso-8859-1?Q?DOrwE/xyVMV+W9xI6Zh9BaCSbYkcuhJlwmkOQz26z5+3oB/A+o7C4HSAx7?=
 =?iso-8859-1?Q?5BmGy+Vw6EXdgrEhbEgILW2r5QGRK9Q+HmycfE3o+KHYGc3EyVeM0fm3Rs?=
 =?iso-8859-1?Q?KuGpJfAjGmqJhrJ2mv+ihG7sYFv84Svhq5OSaKzuy7ANvoYNh9ZOtUf2pQ?=
 =?iso-8859-1?Q?UWKFwPhNDfpUlqaVR7pPKVlcrCxxONGmEwMMJ6FaAVZ/INAj9dAigHe5ba?=
 =?iso-8859-1?Q?Z1iQBhOK4/E9QbLnL+TjAmQwbYS1fiW1tcUOrNTeAZ+N/7Zb9fLv7p8CQP?=
 =?iso-8859-1?Q?TJyrbNNAeccmxYHsDtXgX5Xfl89l08K223+FZZhlQZQ6I5MSyI84eXNGcy?=
 =?iso-8859-1?Q?UNMBh3Iq6a9D655zf+k3FY0mQw69tn83T0rkXBL9T4uA=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10142.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(42112799006)(366016)(1800799024)(376014)(7053199007)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?sG/4UrIhVCz5xgFbObROG+KD5chSxVCF+umLGvs04N6RhEHxOMN37N+Q+z?=
 =?iso-8859-1?Q?iLadyxNycZZDtSkaIbKeGCqGJS5+1BXOu28RJEUFAz77+RtCsQmuANbsxQ?=
 =?iso-8859-1?Q?Uq9qUn88Ca7Zmxn1PsReVrZIV0oEYoy2mGu+I/GhZ5riHKVsVg0/iHcLlf?=
 =?iso-8859-1?Q?Joy3f2PVvDID96mKsXzF5j7IZNQ8nQ3twlkJqVKv2qi7qsSS0VtGXlYYcd?=
 =?iso-8859-1?Q?/6HwA85sUZxat0HAEWpEGhBTn4+Re4C348oTPMwaiA2nfN6diQJNzuM92T?=
 =?iso-8859-1?Q?7Jn5D4OA0QPWY1YiOJPD/eELD28zvP6Cfeeqpt/sWf38MdlEOaYOgfGFgz?=
 =?iso-8859-1?Q?TFKF7Tdp2VWpQA/QAvPm1hkKE0kODK4EhBwm29k8O176jNR8X24el9Z6Mh?=
 =?iso-8859-1?Q?/zcKvXmnOu0tpoaFKaBvh/B465mzKrmIb52Rx6TASZfUgrSwIxpyfMskJC?=
 =?iso-8859-1?Q?qFnMCrBb0GojaJS9F5Bjw/b/iX1ZAWZ7TNo2vqe+rRAdTZXNxqSz+hh1pj?=
 =?iso-8859-1?Q?sdwnjMCTqpd5BO8IETcYzLJAPchPokNlZNetjvMf6wIGJ3zLKzInizRXP0?=
 =?iso-8859-1?Q?NeoCzULLQKN6NjmpDlzEDPps6cCCxts6XpZ+Qva/6nrZR5r5sF2TU09poA?=
 =?iso-8859-1?Q?Ny8prxIaJqw2MRAh9IJ7rSHjM27YZDb6V+Y+77eNoYzT2iCjex3JKXrerH?=
 =?iso-8859-1?Q?Ccv0YfMK6hzrqqAT8wc1VV++4rOmDT8LTFemohjy8bPv2ElaDEd/GNvzBl?=
 =?iso-8859-1?Q?cnEjj5u4xBQHBXj4BJ89syNuAJWML01Vimp6M3Mzjjxv1JXo2n5sB3Ej17?=
 =?iso-8859-1?Q?qVWWGcHCddzDU4Q47BJk0A7wOR64Cc8hUlMZaoHMwjxtg2YODX3FvXEqco?=
 =?iso-8859-1?Q?XzeLzbLrxeBPyRe6j1Fb/9c2TWvbane8GvsU/Geov0scvnrLehl4PGSr0J?=
 =?iso-8859-1?Q?36y9/sm8ZFKUla4mVsu6WBgljG9hKSnUI5cgZ1y5v49KsZs2Hz4LsbFHOK?=
 =?iso-8859-1?Q?fE2/kOUnGwkZZjKb57n3a2ADdqCSlqQA/LflQY62BF3Z7HFauP4BR+56KW?=
 =?iso-8859-1?Q?OAxWpf0XvPQ3LrRQRV6n86TMeZvtcDkh4UH2qLzKkQqb8waE2ap2tuwJxL?=
 =?iso-8859-1?Q?FPKTT/DAkoc+F6UeknHRoXZ2xB62yb3649CxfNV7/0O73FKMVJG9DnolFO?=
 =?iso-8859-1?Q?rxqpJKyRf9FEzcY+9ahiIiF7NMw6bP2cpI05eTrdNKcFsxy3GVZjQtoU76?=
 =?iso-8859-1?Q?ATHMjJr/O+7srZn3i7FFkJFMMlBiviTWRBpr87MwjitqYTe3LBgWJ/egj6?=
 =?iso-8859-1?Q?0kD9aQfEsxNs3AiBROHVrv15kRYuAFj0VdgVm05HLAPcJNss1yzHpnVf9F?=
 =?iso-8859-1?Q?cZsS5fx+gHGtR+5++lOzeWhnMEtRw6O83xLuMSJM38trei4w6WMjogAkhN?=
 =?iso-8859-1?Q?xlWaxRTW1On/nQxizq1yJErk/5bE03733hiqnvrYjKcHKJbDW1yCjZUF6n?=
 =?iso-8859-1?Q?GABUZO4fA29Ed6aE68InCfRNA1bCRG8XcmfiCb2I877hVnjtxpr+igyGQz?=
 =?iso-8859-1?Q?I/Vak7085S+ypeUa5FH910PQA0tsrgPVOQK6TPfKP5i9uabKb5K5oouZfA?=
 =?iso-8859-1?Q?PIl54HN2dypYUSF9Oiveg1WC2Ldczl4OdbNrD2ExlKErfuby0vR7t7BQ?=
 =?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: PAVPR03MB10142.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c7fc3595-9308-4399-cc9a-08ddb7ac5c88
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2025 08:01:47.0486
 (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: 8+6FNVEkAgxa2wtWcaUbaqibUDVxIE8GXoqEpuO3Z++xhu7yi2grNrCZnkE3QDf5jbmsyBM5zc+tq0ac9AaiOTgzSbLjb2wcIniAPYyNaHc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA1PR03MB10724

Current script shows message:
 Don't forget to add the subject and message to ...
 Then perform:
 git send-email -to xen-devel@lists.xenproject.org ...
which has wrong option '-to'.
It may be confused for user.

Set double dashes for longer options to avoid that.

Signed-off-by: Dmytro Prokopchuk 
---
 scripts/add_maintainers.pl | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/scripts/add_maintainers.pl b/scripts/add_maintainers.pl
index 380e8da22a..5ad0869730 100755
--- a/scripts/add_maintainers.pl
+++ b/scripts/add_maintainers.pl
@@ -3,7 +3,7 @@
 #
 # Add maintainers to patches generated with git format-patch
 #
-# Usage: perl scripts/add_maintainers.pl [OPTIONS] -patchdir 
+# Usage: perl scripts/add_maintainers.pl [OPTIONS] --patchdir 
 #
 # Prerequisites: Execute
 #                git format-patch ... -o  ...
@@ -126,7 +126,7 @@ WORKFLOW:
   Step 1: git format-patch ... -o  ...
   Step 2: ./scripts/add_maintainers.pl -d 
           This overwrites *.patch files in  but makes a backup
-  Step 3: git send-email -to xen-devel\@lists.xenproject.org /*.=
patch
+  Step 3: git send-email --to xen-devel\@lists.xenproject.org /*=
.patch
 EOT
=20
 # Constants and functions related to LOCATIONS
@@ -371,7 +371,7 @@ if ($has_cover_letter) {
 }
=20
 print "Then perform:\n".
-      "git send-email -to xen-devel\@lists.xenproject.org ".
+      "git send-email --to xen-devel\@lists.xenproject.org ".
       $patch_dir.'/'.$patch_prefix."*.patch"."\n";
=20
 exit 0;
--=20
2.43.0


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 08:14:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 08:14:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1028912.1402617 (Exim 4.92)
	(envelope-from )
	id 1uW9el-0004TB-Vy; Mon, 30 Jun 2025 08:14:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1028912.1402617; Mon, 30 Jun 2025 08:14:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uW9el-0004T4-SL; Mon, 30 Jun 2025 08:14:27 +0000
Received: by outflank-mailman (input) for mailman id 1028912;
 Mon, 30 Jun 2025 08:14:26 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uW9ek-0004Sy-BD
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 08:14:26 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uW9ei-00AC6d-04;
 Mon, 30 Jun 2025 08:14:24 +0000
Received: from [2a02:8012:3a1:0:a1f7:3d35:dea1:a2b4]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uW9eh-00BYOJ-2n;
 Mon, 30 Jun 2025 08:14: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" 
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=jjn/JAuSlZR29TpVPgH097NnNH+kq+EAI60VCaGaPTM=; b=DalWJiTjKv9Z6XVFfz+qk7Rmpz
	+RQli6POk9XCcAyxHkkFZ60DODWjUqapUnT/CwlxAraP/cIG+CCrs1wJlJnP4UfS+Xk2KGVvmLy65
	2BWvYPt2/ArBd5EXW3sOIYWFPwZ3Ry40Y4SEN7NLkTPONtrAfcPW3RabspeLvr8+mzy8=;
Message-ID: <32bbe11b-a92b-484a-ad77-d0354f8e9339@xen.org>
Date: Mon, 30 Jun 2025 09:14:22 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/arm: Enhance IPMMU-VMSA driver robustness and debug
 output
To: Jahan Murudi ,
 "Orzel, Michal" ,
 "xen-devel@lists.xenproject.org" 
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250620103123.2174529-1-jahan.murudi.zg@renesas.com>
 <445c5594-a003-4cd8-aa46-8544c0543b1c@amd.com>
 
 <52b27bae-b182-488f-afcb-bdbfbc1a495e@xen.org>
 
Content-Language: en-US
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit



On 30/06/2025 07:37, Jahan Murudi wrote:
> Hi Julien,
> 
> On 25/06/2025 16:53, Julien Grall wrote:
> 
>> Hi Jahan,
> 
>>>>> +    dsb(sy);
>>>> Any clue why Linux (mainline) does not do that?
> 
>> One process remark, we typically comment inline rather than pasting a quote and replying at the top of the e-mail.
> 
>   Thanks for the style note - I'll follow the inline commenting convention moving forward.
> 
>>> The implementation writel() which contains an implicit dsb(st) which likely sufficient for Linux for its Stage-1 IOMMU usage where CPU and IOMMU interactions are coherent.
>>> However, Xen uses the IPMMU as a Stage-2 IOMMU for non-coherent DMA operations (such as PCIe passthrough), requiring the stronger dsb(sy) to ensure writes fully propagate to the IPMMU >>hardware before continuing.
> 
>> I don't follow. Are you saying the IPMMU driver in Linux doesn't non-coherent DMA operations?
> 
> Let me clarify my understanding:  In native Linux, the IOMMU works at stage-1 (VA -> PA) and typically assumes coherency between CPU and IOMMU. The implicit dsb(st) in writel() is enough there. But in Xen, we use this as stage-2 (GPA -> HPA) for cases like PCI passthrough where devices might be non-coherent. 


I understand for the PCI passthrough, Xen will be using stage-2, so in 
theory the stage-1 could be used by the guest OS. But ultimately, this 
is the same PCI device behind. So if it is not coherent, it should be 
for both stages. Do you have any pointer to the documentation that would 
state otherwise?

 > We might need stronger barrier dsb(sy) in xen because: 1) We can't 
assume the TLB walker is coherent for stage -2

Why would the TLB walker coherent for stage-2 but not stage-1? Any 
pointer to the documentation?

Note, I just noticed that IOMMU_FEAT_COHERENT_WALK is not set for the 
IPMMU. So the "dsb sy" is coherent. However, I find doubful an IOMMU 
would have a difference of coherency between two stages. So maybe we 
should set the flag either unconditionally or based on a register.

 > and we must also prevent(minimise) any DMA operations during TLB 
invalidation( observed some IPMMU hardware limitations in the 
documentation) .

I don't understand what you wrote in parentheses. But isn't it what you 
wrote all true for stage-1?

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Mon Jun 30 08:20:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 08:20:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1028921.1402629 (Exim 4.92)
	(envelope-from )
	id 1uW9kv-00061F-M6; Mon, 30 Jun 2025 08:20:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1028921.1402629; Mon, 30 Jun 2025 08:20: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 1uW9kv-000618-HI; Mon, 30 Jun 2025 08:20:49 +0000
Received: by outflank-mailman (input) for mailman id 1028921;
 Mon, 30 Jun 2025 08:20: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 1uW9ku-000612-G9
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 08:20:48 +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 1fc6182a-558b-11f0-a312-13f23c93f187;
 Mon, 30 Jun 2025 10:20:47 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3a50fc819f2so3024403f8f.2
 for ; Mon, 30 Jun 2025 01:20:47 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-74af57df2dcsm8557564b3a.124.2025.06.30.01.20.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 30 Jun 2025 01:20:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1fc6182a-558b-11f0-a312-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1751271646; x=1751876446; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=VViF0g5AkG0VPWOu0z60MTfuy012hLzV2MXAXc8Q7do=;
        b=XNM0tN9oS1JxvnCfkfLTDBWlloF/mBqk/P0e6mNyUGXW0NGQ24xUrlg0BdYxGIx2G4
         mUE60i5Qu0MNUNlBavMNArzF43j794lb1cvTuIO33b1VWt7W+imk/eeXMjBWqOE8ZZM0
         TfT4YANwIHY+2VNzzORpLvQnbDRtcEJR10DYLOCJix+WuLL5VBVqOZFyZqq4JCg8DDkk
         XJ+sx0+lfjaWugLdSylONAA8pxCTwhGxP6LgNkhGGKb3xpNjOn1c1fL9dlXojMY50UH0
         1EelFKcMCLGuph8Ex/6seQbJthzuCXAu1s6PWaM9t+b2vQqI7R8sSLEV/AgTkSG044eC
         dUow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751271646; x=1751876446;
        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=VViF0g5AkG0VPWOu0z60MTfuy012hLzV2MXAXc8Q7do=;
        b=uu58X53+1WCPBvHYosEMjO5c18MPCsqY1iLHHMkKoNxfNgGKg7Z4cgVx98W8ScXjbE
         NVO5fQyUzPU5To+lJJdQcdWQO2KEveWP5UNp1lODyFm8RPSoTNTUaSclRUWWCok97OWT
         Qsn0rQBW3naMxa+Y2LYIv41lx48a+kMyGkHm0wQ50r+zZCg6M5ZW3jMSse6YFPAsVMiJ
         WBeFIs1aNp2U3DOBnsgDNsRuEIEC9Fpr29y10omy83CkfCh7C4VFUIdWYQSHJQHdFNzy
         MYyR0iUhNHX3dsuWTbmYlsl0/UjI1LCWDfMY1qSRzydmg6cZyONn0LNYgpyC6R9Bnveu
         Iq5w==
X-Forwarded-Encrypted: i=1; AJvYcCVSupxDQwtqugmqwnmOVqZx+RPZJlqrWZZ2amIk0ZQngzosG0PDACcm7/CkTjwBucmRUVr2q9hztok=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwZwFD8AgDuXiTzqi0MqlUj5fkIP1yryvCnlGyY4hcMks5xuvt/
	c5NqnhPWamwL6HBwFYZhECU6c34ydlsiJvWFNYslbPDi3pG5TVhqOrB6GpSRqG/tIQ==
X-Gm-Gg: ASbGncsZMlZNr+Vmzi2fcTNXgNMsrKUXAMGHM9bdsA/b5H99K91I174G4eqLp2N4fYE
	yXWYQi0T0bqyJV0aEOesxSeRUiLXjNozIj2V0qlQ/H7+6n6ggQ/Wue00rPkQusWL8Jg7qDHb7GW
	LjcVGnQt6CrstfOBVkrPfsKJTeHthSNkyk7eIufRVzR/IBfClryLKB73TIenDiq1VSZ1HP7iz+d
	pi6WB3IvwCalYAtdkosfVtXT6xQ+GqE9gqYhcb/9jtRRlHntO1vjIT2K55cilItczs/+kHT2Uyo
	HBMMgOJYBOzBVewruzsUHS4Ojz1+SAgxcuudWWvVZ7TDGGB7A72lvmeDEtERQxEQWU5Ef4CmKwd
	V2+a2V8DDJQ9e25tXSahM5E9wGKzjp8Rm9JVvlovssJletIw=
X-Google-Smtp-Source: AGHT+IG31JsL1Bi5wTyquonzl8TZFavWYJ1Hh5fW6XP7kKPMtFH1LaJGb9fIpAEBX23WXWLKpY1p0g==
X-Received: by 2002:adf:c084:0:b0:3a4:f9e7:2796 with SMTP id ffacd0b85a97d-3a9176038c6mr7939395f8f.35.1751271646334;
        Mon, 30 Jun 2025 01:20:46 -0700 (PDT)
Message-ID: 
Date: Mon, 30 Jun 2025 10:20:36 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 01/18] xen/x86: remove "depends on !PV_SHIM_EXCLUSIVE"
To: Penny Zheng 
Cc: ray.huang@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250616064128.581164-1-Penny.Zheng@amd.com>
 <20250616064128.581164-2-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: <20250616064128.581164-2-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.06.2025 08:41, Penny Zheng wrote:
> Remove all "depends on !PV_SHIM_EXCLUSIVE" (also the functionally
> equivalent "if !...") in Kconfig file, since negative dependancy will badly
> affect allyesconfig.
> 
> Signed-off-by: Penny Zheng 
> Reviewed-by: Stefano Stabellini 
> ---
> v2 -> v3:
> - remove comment for PV_SHIM_EXCLUSIVE
> ---
> v3 -> v4:
> - explicitly state "CONFIG_xxx is not set" in "pvshim_defconfig"

Where did these changes go? Nothing is said about ...

> - Add "default y" for SHADOW_PAGING and TBOOT
> - refactor commit message
> ---
> v4 -> v5:
> - For not breaking allyesconfig, changes to defaults are actually not needed.
> So remove them all
> - Leave one blank lines

... their (complete) dropping here. Aiui overrides for anything where you
remove the dependency (and where the intended setting for the shim is different
from the general default) would still be needed here.

And then there's still a non-"depends on" change left ...

> --- a/xen/drivers/video/Kconfig
> +++ b/xen/drivers/video/Kconfig
> @@ -3,7 +3,7 @@ config VIDEO
>  	bool
>  
>  config VGA
> -	bool "VGA support" if !PV_SHIM_EXCLUSIVE
> +	bool "VGA support"
>  	select VIDEO
>  	depends on X86
>  	default y if !PV_SHIM_EXCLUSIVE

... here, which (as indicated before) imo doesn't belong here, but at the very
least would need covering in the description.

Also, just to repeat what I said in reply to the cover letter: Imo this change
needs to move 2nd to last in the series, and it then wants committing together
with the last patch (which you will want to put in as a remark to the eventual
committer).

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 08:24:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 08:24:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1028928.1402637 (Exim 4.92)
	(envelope-from )
	id 1uW9ok-0006dX-3L; Mon, 30 Jun 2025 08:24:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1028928.1402637; Mon, 30 Jun 2025 08:24: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 1uW9ok-0006dQ-0Y; Mon, 30 Jun 2025 08:24:46 +0000
Received: by outflank-mailman (input) for mailman id 1028928;
 Mon, 30 Jun 2025 08:24: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 1uW9oj-0006dK-2c
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 08:24:45 +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 acca3d59-558b-11f0-a312-13f23c93f187;
 Mon, 30 Jun 2025 10:24:44 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3a365a6804eso2121543f8f.3
 for ; Mon, 30 Jun 2025 01:24:44 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23acb3b7d97sm76252805ad.172.2025.06.30.01.24.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 30 Jun 2025 01:24:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: acca3d59-558b-11f0-a312-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1751271883; x=1751876683; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=X0BY9KYfXbvQrrOP5eezoSXtnhbg/TtP1duKZ9GbXus=;
        b=GR8OlixkBbjYr3tHM4sH8UnqSZ4GIsm5da7bCRFlVFiaJzLYJUkwxtKqaocfu9Ibox
         KKan7dE0anjIiCBD69pFFw3mxQSdMm6n6ZFw5+3xD1PglPQiNfysC2JmrtyohMhX0iQv
         RT6ZrbaYgkflu4RQ4QHU66y5cOzhfe+ucvuTZIRid8QXZcNuY4dJoyaFFyauYXmjHcqb
         rOAcAeYySG/2N5zUUOEHJFDT9jvjf46hZpGZxeyRjobCAZB1vjqJv0fHCtLygWO0d3Kt
         O4oGyA2OG0nk4PTUbtnmY2Bg1bQSDMMdxcgjLZd0rt6GWKxbk950aLymSFDKMpjxMp1M
         DgNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751271883; x=1751876683;
        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=X0BY9KYfXbvQrrOP5eezoSXtnhbg/TtP1duKZ9GbXus=;
        b=lj0O9WcjgHWmCHjJf9yWbUUvo+54Uae+Lek393Yz279R049jzKkQagNyrgHyQUb2Vq
         YFjARYyjbPjzAbS5uZ1JpxmenKOTfs9IyDi/aClNMM5q9jez7gQkbO1wWUib4DewNzb4
         RYxToa3zZazRuVPjUo7mq0SHzQUC7txP+NwF16rGu9JKBgLrNHY4vQohYHFXBR8RW8gO
         nA8T6L0nuczXPXMqMK65R26hWjDu2i2x3JqJgFBpgAepDp/UZbktJ6jlGANwjHZfY3N1
         SJK73B40w8hNJHZn72WHq61MgMLv2Dp1OE8xAbNqvc15Truia9al8LKUtfJBmVleurMk
         jeKw==
X-Forwarded-Encrypted: i=1; AJvYcCUUB30UGT+7UK8XSg5rDUKnrIO9rhYl9tMIMXzpJWLSNQTF8SH2rnFmrHgy2lrOxuVUJ1pL/hA7Mbg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwHXHLs2yFuoOHvKqPGhvo0r0w5Dw9dmEnfzowBcP2+WYCo2v6T
	UFEh4qokMSert6R088pkgzWG3JdzQJ3cYlDQr6QU/RBB0267PNUVfvNfkaEBRPis6A==
X-Gm-Gg: ASbGncsdPWk8mH5+h/2EcrwrKrYddAkp+yCoKdmoYrL+0+I+1dF+LBMVX5vUgZhbRyC
	sLmpI/Ut4cZxjRd5AMImvzfv8j4PEjOvbdxxWsR7P3C7t2zoCVj0Bo5/fxTdQ7z8dvyobC0nnKq
	JHpPIOxMGnv3Ms20h6QmQsZ8CzdoVGpFOyS0tXVKHyZSO/ulynEohaUwM3CJDXD2hvixwfirw40
	SNkxTcLDJP6vyR80yOWzTP4v4FW8Dm/QEcqX/bLAuF7t6/f7cfimqbKx0sAugML8gKWW4Eyg8A2
	lZuKSAhMSq6d/D2BGhqfefr+thsDqnylxN6EtLgy9rYMBTZ0ZjhfGYjqsNrpnJDPAT1UeIfjoQT
	xoLcmNAMAo3f6xtPRSzMmGGLCnBQh3XVe8YhPyM49b85S/10=
X-Google-Smtp-Source: AGHT+IHH6MTbV58ZPZXZC8dmUQw06rT88YuPOWvlWp2fH0EgJABv6CqD3zUTvjtIhCC4Y1IpgyybsQ==
X-Received: by 2002:a05:6000:646:b0:3a5:8600:7cff with SMTP id ffacd0b85a97d-3a8fdb2a82fmr11325890f8f.1.1751271883181;
        Mon, 30 Jun 2025 01:24:43 -0700 (PDT)
Message-ID: 
Date: Mon, 30 Jun 2025 10:24:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 09/18] xen/pmstat: introduce CONFIG_PM_OP
To: Penny Zheng 
Cc: ray.huang@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250616064128.581164-1-Penny.Zheng@amd.com>
 <20250616064128.581164-10-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: <20250616064128.581164-10-Penny.Zheng@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.06.2025 08:41, Penny Zheng wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -620,4 +620,12 @@ config SYSCTL
>  
>  endmenu
>  
> +config PM_OP
> +	bool "Enable Performance Management Operation"
> +	depends on ACPI && HAS_CPUFREQ && SYSCTL
> +	default y

Btw, doesn't this also require adding an override to pvshim_defconfig? And
the similarly for PM_STATS in the next patch?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 08:26:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 08:26:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1028935.1402648 (Exim 4.92)
	(envelope-from )
	id 1uW9qI-00078O-Cd; Mon, 30 Jun 2025 08:26:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1028935.1402648; Mon, 30 Jun 2025 08:26:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uW9qI-00078H-A7; Mon, 30 Jun 2025 08:26:22 +0000
Received: by outflank-mailman (input) for mailman id 1028935;
 Mon, 30 Jun 2025 08:26: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 1uW9qH-00078B-BO
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 08:26:21 +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 e5afa3be-558b-11f0-b894-0df219b8e170;
 Mon, 30 Jun 2025 10:26:19 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a52874d593so1517009f8f.0
 for ; Mon, 30 Jun 2025 01:26:19 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b3508116203sm2878542a12.36.2025.06.30.01.26.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 30 Jun 2025 01:26:17 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e5afa3be-558b-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1751271978; x=1751876778; 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=8Z0jirSpwuvYhmfU5z5hYP/f2F/uKbhsT4EYPkGtkQk=;
        b=G5+FUlK8KZCQn7VIvFfLiRdoJSDNM0iaFZ2UK2ctk5EtJH5q2WQu6mzcPykjPLfLjG
         4Ateex8x0qLm+QU/yNYL+yfjlNSMEik9Pke+UEoFQj3DngRz+BfH9bfWC8jf74X254+L
         fghZwVM0xhQGtII3JZiPFmEqSVVO0sUXaTNh5WH1cnMRgc+PNckecSNKQFuklY7gBFNZ
         KWqftqFwfRutZ26WXTmKqp0tMalwX5DHC1MYR+tV/1H2zvP2FMAI1vXJmPTGK3y5jB0x
         o8UqHvcSOSGlbEqqUShzvtKtEmUj1msw325JPjXbt4Dv5GZmFO1D0gANGVSfw/32QdTA
         OVlw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751271978; x=1751876778;
        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=8Z0jirSpwuvYhmfU5z5hYP/f2F/uKbhsT4EYPkGtkQk=;
        b=W7siiDh07LaHDYtO6JNL9PoCf0S9ScuMMFKL4pyNlJC//Kfm9v3isQSIFNN3ahgfhz
         +5A0NY1rcy8PzCec/Di+c01pPDv19Zq+0t6EpPJT8/HSWkkKPem4TwKl6nutef0WH9jh
         c1qfUkz+S7JTtvnQmKqJ446bZArkplHIA8UiTw+0nZ+e1NUNavEz4K4zv8jY+whcZni8
         8J1aoMwJ+kExJc/b+MSsI2j2z/uXzMWrCnFilVpPzW8tV4RrkJjPgFiG4Y2RVTPWPGiQ
         xWiVW+BKEXMlJP7od853uYeENi7hE+JzyFRxwIBwQScKQPiEW2UiY0i2IkJPWS4EBdBR
         3UZA==
X-Forwarded-Encrypted: i=1; AJvYcCVNwu9naei7HUYS2OJexK9O9Fj1giO/b2aVdWLlEGTVDPcvJtmhjNDEBGyNC+qFCyC8paKUAbk3Xoc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzwLpF+oY1mYEcz+zoPlv7Qai57ys5iAh9Ny266rcpz0yXw0wyE
	171EuS/gUS0gZUeDIGl3Oa4bZsxC1rvIUyL9a6j9cRxeo/wNbe+eb79ppJuKOm+AHEc5oCpRc1O
	57zo=
X-Gm-Gg: ASbGncsfLfcDz2qG20vZSWd/yiGrpa+Gipj+ImCS/tEQSqc6lR0SHoESePUBSTCh7rm
	4S7btvVTk0x0lnPphCcQeqYagX5hkSTabDUfSjdRAWaVzPRJPq16au/837A7uWScdkp2wZLmfYU
	ELlwdfvIpPiyHXjJc8ZSPOL+OXXCM2VGyb7wwS42gNcKjSieCBV2xnjmK23UAOhmqXweSSnRuA5
	lAVuZQSIdxg1D0o6rInbELFxjzNL91mfOtDQuuyuKI3iTOw21p8hJ5KL1Eacuxe3To470GwALjj
	W0CJFbE9ImOz7yaFjlbjPiUCcNaMMEpcdw6ObR31TRGX0dBCCOhEvasK5OEmC2OiMldfpCr0TIr
	s3DqjOWIG1L9QYgMa0OPUXZ1C2mv34JU8VYp336RVuok7Tryb7yAPO6bqiQ==
X-Google-Smtp-Source: AGHT+IF82ociMjkx29dVW+6NW3McarsU8OjBiUbpz8QoW4VGz/aBTQEA0trWBKtQtcfgPs+uzbFvRg==
X-Received: by 2002:adf:b19b:0:b0:3a3:6e85:a529 with SMTP id ffacd0b85a97d-3a8ffcc9ea5mr7625513f8f.51.1751271978485;
        Mon, 30 Jun 2025 01:26:18 -0700 (PDT)
Message-ID: <7e69e568-b426-49bf-958a-231e25936cbc@suse.com>
Date: Mon, 30 Jun 2025 10:26:09 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 09/18] xen/pmstat: introduce CONFIG_PM_OP
From: Jan Beulich 
To: Penny Zheng 
Cc: ray.huang@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250616064128.581164-1-Penny.Zheng@amd.com>
 <20250616064128.581164-10-Penny.Zheng@amd.com>
 
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 30.06.2025 10:24, Jan Beulich wrote:
> On 16.06.2025 08:41, Penny Zheng wrote:
>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
>> @@ -620,4 +620,12 @@ config SYSCTL
>>  
>>  endmenu
>>  
>> +config PM_OP
>> +	bool "Enable Performance Management Operation"
>> +	depends on ACPI && HAS_CPUFREQ && SYSCTL
>> +	default y
> 
> Btw, doesn't this also require adding an override to pvshim_defconfig? And
> the similarly for PM_STATS in the next patch?

Not sure though whether that needs doing here or in the !PV_SHIM_EXCLUSIVE,
once that was moved to near the end of the series.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 08:34:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 08:34:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1028941.1402657 (Exim 4.92)
	(envelope-from )
	id 1uW9yR-0000Qi-5R; Mon, 30 Jun 2025 08:34:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1028941.1402657; Mon, 30 Jun 2025 08: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 1uW9yR-0000Qb-2u; Mon, 30 Jun 2025 08:34:47 +0000
Received: by outflank-mailman (input) for mailman id 1028941;
 Mon, 30 Jun 2025 08:34: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 1uW9yP-0000QV-R3
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 08:34:45 +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 12c126dc-558d-11f0-a312-13f23c93f187;
 Mon, 30 Jun 2025 10:34:44 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3a53359dea5so963557f8f.0
 for ; Mon, 30 Jun 2025 01:34:44 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-315f54270a5sm13350180a91.25.2025.06.30.01.34.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 30 Jun 2025 01:34:43 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 12c126dc-558d-11f0-a312-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1751272484; x=1751877284; 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=HI94rqOfU2FBxtCCjds66wSfew/IaygCM0quHK7I2/c=;
        b=gKseVWkNVvlZjejP3knEAicm7yy3zOTGsXPn11+6UEqLwVgI2ePL4xAuk0qtaMbaWX
         HgGZX6vNG8pb2fAJ8dfHx8YJfRI7ZhIzOGPPJ3nQASfX5J2XiCWq6k2o5nCYYgyZtVom
         Be84A3CO6eTrjA1xbqVo0eacG9U3AiA9JRnDvOpkwkZE4svJFCE4VInFy9omYJploGOp
         cbr+Si13van09yI6DaKesU15EI3V0Gf8/29sYdstTqTSm6xtJ9mGbsfBxeqEh+UeDg3y
         u8TqgHqPQfatUlKxgz0AImHBFden0Ud7HlYmFlxT9HzJI1ayUBbB8HhPUhl03hUWR0t/
         1Z1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751272484; x=1751877284;
        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=HI94rqOfU2FBxtCCjds66wSfew/IaygCM0quHK7I2/c=;
        b=u4kRIqsLgnJB25Yfw5dxeAb4+5xXyhGHWf33+UlvI8RTBQBOMBxqFcJIKGcbFZuUVp
         Mum7XR5vFs1P2em1q8zC0R9J2Vi5Qs8k7ozH2RfWuWvzFCLw9JujYYdlY2soh96aTmLZ
         HoxZhu9422/Zz6SGzC0f4trMbI2mePUQFHr8m2pVt+qtkj61XhZ8j+aOd+6i/S2DQ1Sa
         wLX47KXVH0/XmxyO6WW3qglSa/wcXvZFUNBPTXArTSFOXLLZuipr6GP8EjaeuuuR/iYc
         huw0+S2mfhhRCYB8w9G/4Cwen3Zuu4IoSEaksZwtnLXSfHNjRto+YayIuyonsZK4eK0F
         OOeg==
X-Gm-Message-State: AOJu0YwxLZKzy/G2f/fz+64WP43IzCJEtctQ6OAr9Ii2Xp/ic2skc5cV
	LCbwyPKarQ4bsPZRV+YjhSX6eNvg2Jsh5uS8cct0KwocGc0Jxsvp7mSmnfq/7boF51vYnq/iyh5
	n128=
X-Gm-Gg: ASbGncv5RwLujfI8wyXVkqRSCOG1yCHevDvgKy8sYVNTCdSoaWrp7+iO9yIgvuwJDhN
	q0XdolJcHpH6SA4SUjwhckbE3THobdqaPSztFKT314STCTawnNZWO/Id2IOxmPLy5g+cKrCNyos
	96WMU6rQfQ1LRD3ad1RDeK/dNiJ+T1quvYg9u4Ly5nPIHsIrRPaKqNKKi6EgLG/3+lcOfiVaWRt
	B98q6DhgK5E+e+o8foOGJReeRDQuqrZxruXWyn4/cEObQdpoT7wuLK8xiEP8ZNTYRIM2zA5/ohh
	yR0D9r9x5kvH9XYpHSsMI6OsBefLQsJFjVp3MSrlym1WK4wuEXjU3cc8SexF0YACxWdRfDDtPXr
	iTUql/D5MHzx1LDm3Eg799Fqh6vas2iCIbRuBdXDEfNdRRn8=
X-Google-Smtp-Source: AGHT+IFmzFBienQcuGIyTVJTIE3Fpth/nQ3ma1P2ffLxHQatrk4j7mmlutETOgJp/QRXSDPCv4CH+g==
X-Received: by 2002:a05:6000:440d:b0:3a4:f6ba:51da with SMTP id ffacd0b85a97d-3a8fdb29f41mr6746140f8f.15.1751272483694;
        Mon, 30 Jun 2025 01:34:43 -0700 (PDT)
Message-ID: <9a780375-81a5-4b53-ba08-d4d53aa4a58c@suse.com>
Date: Mon, 30 Jun 2025 10:34:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 7/7] mm: allow page scrubbing routine(s) to be arch
 controlled
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini ,
 Anthony PERARD ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Bertrand Marquis ,
 Volodymyr Babchuk ,
 Oleksii Kurochko ,
 Shawn Anastasio 
References: 
 <0d2b44e3-bf6c-40ae-be4f-d0ad2845e925@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: <0d2b44e3-bf6c-40ae-be4f-d0ad2845e925@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.06.2025 15:02, Jan Beulich wrote:
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -58,6 +58,7 @@ obj-y += pci.o
>  obj-y += physdev.o
>  obj-$(CONFIG_COMPAT) += x86_64/physdev.o
>  obj-$(CONFIG_X86_PSR) += psr.o
> +obj-bin-$(CONFIG_DEBUG) += scrub_page.o

Spotted yet one more oversight: Wants to be scrub-page.o (obviously along with
the source file's name also changed).

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 08:56:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 08:56:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1028954.1402667 (Exim 4.92)
	(envelope-from )
	id 1uWAJF-0003S1-U4; Mon, 30 Jun 2025 08:56:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1028954.1402667; Mon, 30 Jun 2025 08:56:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uWAJF-0003Ru-RN; Mon, 30 Jun 2025 08:56:17 +0000
Received: by outflank-mailman (input) for mailman id 1028954;
 Mon, 30 Jun 2025 08:56: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 1uWAJE-0003Ro-OP
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 08:56:16 +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 0e79bdf3-5590-11f0-b894-0df219b8e170;
 Mon, 30 Jun 2025 10:56:06 +0200 (CEST)
Received: from phl-compute-09.internal (phl-compute-09.phl.internal
 [10.202.2.49])
 by mailfforwardh.stl.internal (Postfix) with ESMTP id 9B4DB8400E0;
 Mon, 30 Jun 2025 04:56:04 -0400 (EDT)
Received: from phl-frontend-02 ([10.202.2.161])
 by phl-compute-09.internal (MEProxy); Mon, 30 Jun 2025 04:56:04 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 30 Jun 2025 04:56:02 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0e79bdf3-5590-11f0-b894-0df219b8e170
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=
	1751273764; x=1751360164; bh=/DHgYG9ZyvfdKqKdCRbmzkrxhWwhBHN6qVw
	9SBZbsVg=; b=TeZgO9LIPmI6rG1ncsRZW7JBBArhk2kNRe0bQRI0f7L0AfaDtyX
	rebk1QNT4acQUtMfUX5L7haJgAPM9z9g2SvCbQ67YM7sFrqFgwkhdbj02ly2scNk
	JGRqS8sLctDEOAekLlGUS5SzaV37mHS4TEb8dlf63jGQmtm7EboyK7jErHgppW/t
	N/vuflLXDwmOPRDloyHGCcL4umY1cQeitTZZqyfdDwCFIDsqX2tuqHXmre2+86SW
	4sjotwXxbOueMSXp62bXgAjJhZhrfPqJ7+j6++lasLOcu09PnTMSoozJA/Pb11oL
	i4nKafnsTFbJVgUbVvxznCpw3nD3wPODKSg==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdduuddvjecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpefhvfevufffkffoggfgsedtkeertdertddtnecuhfhrohhmpefuvghrghhihicumfhi
    sghrihhkuceoufgvrhhgihihpgfmihgsrhhikhesvghprghmrdgtohhmqeenucggtffrrg
    htthgvrhhnpeffffdvieefieejhfehfeeuvdevtdehffejieevhefgteetvdegudejgfdu
    jeegvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe
    hsrghkihgssegurghrkhhsthgrrhdrshhithgvpdhnsggprhgtphhtthhopedutddpmhho
    uggvpehsmhhtphhouhhtpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgi
    gvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtohepshgvrhhgihihpghkihgsrhhikhes
    vghprghmrdgtohhmpdhrtghpthhtoheprghnughrvgifrdgtohhophgvrhefsegtihhtrh
    higidrtghomhdprhgtphhtthhopegrnhhthhhonhihrdhpvghrrghrugesvhgrthgvshdr
    thgvtghhpdhrtghpthhtohepmhhitghhrghlrdhorhiivghlsegrmhgurdgtohhmpdhrtg
    hpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtghomhdprhgtphhtthhopehjuhhlihgv
    nhesgigvnhdrohhrghdprhgtphhtthhopehrohhgvghrrdhprghusegtihhtrhhigidrtg
    homhdprhgtphhtthhopehsshhtrggsvghllhhinhhisehkvghrnhgvlhdrohhrgh
X-ME-Proxy: 
    
    
    
    
    
Feedback-ID: if663d99b: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/flask: estimate max sidtable size
Date: Mon, 30 Jun 2025 11:55:59 +0300
Message-Id: <20250630085559.554334-1-Sergiy_Kibrik@epam.com>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Currently Xen lacks a defined largest number of security IDs it can potentially
use. The number of SIDs are naturally limited by number of security contexts
provided by a given security policy, i.e. how many combination of user, role
and type there can be, and is dependant on the policy being used.
Thus in Xen the number of allocated entries in sidtable is hard-limited by UINT_MAX.
However in the embedded environment configured for safety it is desirable to
avoid guest-triggered dynamic memory allocations at runtime, or at least limit
them to some decent amounts. So we seek to estimate this limit.

This patch suggests one way to do it using Xen's flask policy.
List of users, roles and types is read from binary policy using setools utils,
then it is used to count the No. of combinations these values can give.
This No. of combinations then can be used in code as a practical replacement
of UINT_MAX limit. Also it can be used later to pre-allocate sidtable at boot
and avoid runtime entries allocation altogether.

Signed-off-by: Sergiy Kibrik 
---
This RFC presents a concept of estimating a max possible sidtable size.
Can we discuss how valid this concept is? Currently it yields 420 as max SID,
is it a reasonable number? Or perhaps something not being taken into account?
(it lacks MLS/MCS support, because it's currently disabled in Xen's policy
and I'm not sure if it's usable)

  -Sergiy
---
 .gitignore                      |  1 +
 xen/xsm/flask/Makefile          |  5 ++++-
 xen/xsm/flask/policy/mkselim.sh | 17 +++++++++++++++++
 xen/xsm/flask/ss/sidtab.c       |  3 ++-
 4 files changed, 24 insertions(+), 2 deletions(-)
 create mode 100755 xen/xsm/flask/policy/mkselim.sh

diff --git a/.gitignore b/.gitignore
index 53f5df0003..b03e63b7a0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -241,6 +241,7 @@ xen/xsm/flask/include/av_permissions.h
 xen/xsm/flask/include/class_to_string.h
 xen/xsm/flask/include/flask.h
 xen/xsm/flask/include/initial_sid_to_string.h
+xen/xsm/flask/include/se_limits.h
 xen/xsm/flask/policy.*
 xen/xsm/flask/xenpolicy-*
 tools/flask/policy/policy.conf
diff --git a/xen/xsm/flask/Makefile b/xen/xsm/flask/Makefile
index 3fdcf7727e..8acc5efcf1 100644
--- a/xen/xsm/flask/Makefile
+++ b/xen/xsm/flask/Makefile
@@ -14,7 +14,7 @@ AV_H_DEPEND := $(srcdir)/policy/access_vectors
 
 FLASK_H_FILES := flask.h class_to_string.h initial_sid_to_string.h
 AV_H_FILES := av_perm_to_string.h av_permissions.h
-ALL_H_FILES := $(addprefix include/,$(FLASK_H_FILES) $(AV_H_FILES))
+ALL_H_FILES := $(addprefix include/,$(FLASK_H_FILES) $(AV_H_FILES) se_limits.h)
 
 # Adding prerequisite to descending into ss/ folder only when not running
 # `make *clean`.
@@ -54,4 +54,7 @@ $(obj)/policy.bin: FORCE
 	        FLASK_BUILD_DIR=$(FLASK_BUILD_DIR) POLICY_FILENAME=$(POLICY_SRC)
 	cmp -s $(POLICY_SRC) $@ || cp $(POLICY_SRC) $@
 
+$(obj)/%/se_limits.h: $(obj)/policy.bin
+	$(srcdir)/policy/mkselim.sh $^ $@
+
 clean-files := policy.* $(POLICY_SRC)
diff --git a/xen/xsm/flask/policy/mkselim.sh b/xen/xsm/flask/policy/mkselim.sh
new file mode 100755
index 0000000000..bda99727fa
--- /dev/null
+++ b/xen/xsm/flask/policy/mkselim.sh
@@ -0,0 +1,17 @@
+#!/bin/sh
+
+policy=$1
+output_file=$2
+ntypes=$(seinfo --flat $policy -t | wc -l)
+nroles=$(seinfo --flat $policy -r | wc -l)
+nusers=$(seinfo --flat $policy -u | wc -l)
+cat > $output_file << EOF
+/* This file is automatically generated.  Do not edit. */
+#ifndef _SELINUX_LIMITS_H__
+#define _SELINUX_LIMITS_H__
+#define __SEPOL_USERS_MAX $nusers
+#define __SEPOL_ROLES_MAX $nroles
+#define __SEPOL_TYPES_MAX $ntypes
+#define SEPOL_SID_LIMIT ( __SEPOL_USERS_MAX * __SEPOL_ROLES_MAX * __SEPOL_TYPES_MAX )
+#endif
+EOF
diff --git a/xen/xsm/flask/ss/sidtab.c b/xen/xsm/flask/ss/sidtab.c
index 69fc3389b3..0dbadc8cd7 100644
--- a/xen/xsm/flask/ss/sidtab.c
+++ b/xen/xsm/flask/ss/sidtab.c
@@ -13,6 +13,7 @@
 #include "flask.h"
 #include "security.h"
 #include "sidtab.h"
+#include "se_limits.h"
 
 #define SIDTAB_HASH(sid) ((sid) & SIDTAB_HASH_MASK)
 
@@ -228,7 +229,7 @@ int sidtab_context_to_sid(struct sidtab *s, struct context *context,
         if ( sid )
             goto unlock_out;
         /* No SID exists for the context.  Allocate a new one. */
-        if ( s->next_sid == UINT_MAX || s->shutdown )
+        if ( s->next_sid == SEPOL_SID_LIMIT || s->shutdown )
         {
             ret = -ENOMEM;
             goto unlock_out;
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Mon Jun 30 08:59:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 08:59:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1028961.1402678 (Exim 4.92)
	(envelope-from )
	id 1uWAMf-00040n-CH; Mon, 30 Jun 2025 08:59:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1028961.1402678; Mon, 30 Jun 2025 08:59: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 1uWAMf-00040g-8d; Mon, 30 Jun 2025 08:59:49 +0000
Received: by outflank-mailman (input) for mailman id 1028961;
 Mon, 30 Jun 2025 08:59:48 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uWAMe-00040W-5n
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 08:59:48 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uWAMd-00ADBE-00;
 Mon, 30 Jun 2025 08:59:47 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (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 1uWAMc-00CDcY-1Y;
 Mon, 30 Jun 2025 08:59: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=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date;
	bh=EOKb6eGI6FM3HEr963iQFcoGEwbAcwyKibpGSREKjgE=; b=tX93RUrviwdR1gTDvGq3Aszw9W
	W56Hp0kpe9uPwIUR0dC1uepeJgmr6qOkQwCMn1xHUFHuFMo2VYc7dNEAJdKVVhb5/pIi1iCdhGZG7
	qY+UkrxDZcewVP6zO5xeOIVCyN+y9PHcW/OZxX1lXzjwsVZvf9o0IT2o0Xy4ZkRBdWYE=;
Date: Mon, 30 Jun 2025 10:59:44 +0200
From: Anthony PERARD 
To: Dmytro Prokopchuk1 
Cc: "xen-devel@lists.xenproject.org" ,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	Stefano Stabellini 
Subject: Re: [XEN PATCH] scripts/add_maintainers.pl: set double dashes for
 long options
Message-ID: 
References: <7f66cbd47f45b2cc442c541cd264a208ea1f406c.1751269784.git.dmytro_prokopchuk1@epam.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7f66cbd47f45b2cc442c541cd264a208ea1f406c.1751269784.git.dmytro_prokopchuk1@epam.com>

On Mon, Jun 30, 2025 at 08:01:46AM +0000, Dmytro Prokopchuk1 wrote:
> Current script shows message:
>  Don't forget to add the subject and message to ...
>  Then perform:
>  git send-email -to xen-devel@lists.xenproject.org ...
> which has wrong option '-to'.
> It may be confused for user.

For some reason, the git send-email still works as expected with the use
of single dash instead of two even if this isn't documented.

> 
> Set double dashes for longer options to avoid that.
> 

I would add:
Fixes: e1f912cbf717 ("scripts/add_maintainers.pl: New script")

> Signed-off-by: Dmytro Prokopchuk 

Reviewed-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 09:05:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 09:05:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1028967.1402688 (Exim 4.92)
	(envelope-from )
	id 1uWARb-0005kN-V4; Mon, 30 Jun 2025 09:04:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1028967.1402688; Mon, 30 Jun 2025 09:04: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 1uWARb-0005kG-Qs; Mon, 30 Jun 2025 09:04:55 +0000
Received: by outflank-mailman (input) for mailman id 1028967;
 Mon, 30 Jun 2025 09:04: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 1uWARa-0005k4-7b
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 09:04:54 +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 484f465e-5591-11f0-b894-0df219b8e170;
 Mon, 30 Jun 2025 11:04:52 +0200 (CEST)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-453749af004so21800275e9.1
 for ; Mon, 30 Jun 2025 02:04:52 -0700 (PDT)
Received: from ?IPV6:2003:e5:8746:1a00:ff67:e633:2aa8:93ba?
 (p200300e587461a00ff67e6332aa893ba.dip0.t-ipconnect.de.
 [2003:e5:8746:1a00:ff67:e633:2aa8:93ba])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a88c7e7098sm9659818f8f.4.2025.06.30.02.04.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 30 Jun 2025 02:04:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 484f465e-5591-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1751274291; x=1751879091; 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=YOzSyyJTbgmm5P7nXA1THL4s98W7foiluU3LTeCzaSs=;
        b=UfjJW0GgDO+AeJcIoCo271ZBKD1M6jtTBI6Lxbrio1hKm+m+qhGww+tUHaWAedy2c6
         3+Ge/lLmlYUgLJJ6iCDN0C0338BLW59sGHtY7EXSG4JzT3d0CY+BaSkGLGIo+W/ppOnp
         ErNxa9RE4hn5WGgg91yaTLcbMtnRRZ/C/BdTda7N7Momf9YLcuvZ4mf977/l0Ebjt8K7
         Ihg9J3vmNgew3QXNMbPG3o/n99DxX9ZGGJfLGq/qhHzpF9ejfRP72i6VqAath3HE8Yl2
         jAvbvVNBQ9782/USBTz+attdw/BWWvXB8q8AmsHJBuDC9er94ZHbu+T7sXno4yhN17rR
         efPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751274291; x=1751879091;
        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=YOzSyyJTbgmm5P7nXA1THL4s98W7foiluU3LTeCzaSs=;
        b=fxMGtI20pmqBb2VnooR0an1XG25CgmrJhdUC6RmHfdG6D6Y2J+tq8/TB9fVlkzE/65
         gjuy6U26xO/zQbhzTJppVGDpbSzio4X6ihzvS5Tx+ETNEQgtypoLKdpMgFB623h/mdLG
         +grf8xEXe+yLIdUoLx9oDSMLZgo77Nzcw7ATpKo2k/CnDjYZQek5hXWsoLc9y0kw+dgL
         yTwrtWj3DWN7txTD5fvZkCABij1GpJdAfjYfwGgW+5dPOMR1DZCjQO1O0z/VnVl0sJiz
         dK60zZF1pfgTc3/Uh6SPWCQdoanxHlVMDQPNL5IRf3jhVlu4OZSktS7i6PzuJA1o/aei
         txAg==
X-Forwarded-Encrypted: i=1; AJvYcCU1PfPqQzyBUwNOqNuJDQimiHMLZAhQyuUFMYz/D6t0ipADxFFd5/1iGpcpCV/WuvnO04YgM0x3e5E=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw4G0Q2sQxGWmebErTQIk1Jk6FiadmDJXLfIOmr4u9t6L7R697m
	RsMuSAUn74m08KSjOa83gMmOhTR8+oOAkmexEniinh8tpXG9QKH0lmf2cwCyNcOFdNQ=
X-Gm-Gg: ASbGncvxHV+ZaqjM6BdC4EXWHbeWospR9IOEnuCsjPee8y4EhaLYySaSO0kfdhZcbVO
	KCNtj5Y4BQeEPs4znxuEZgoJ5q9mRJrx8mfpG69fuU5TVRLGHjnBbkEiSGrjRiQE0AtotfDYf/O
	DKwB2NYDZhtu0dkwNLXKocTxIL7C9wmFfdn8GctG+HH5iAL2/7+iXvPmPBMnRcoLqt+QqPRnZ+k
	yAkqQjl9TwnhoMgZU/MFCkgGpW2JOIxJr/KJz9RGA8gf+h2AImRKjIBlUoKm2flIeSBzHl3J6UM
	l1vd5BuA9oF/1tMJJBJIpgnHU4o6tABeRY1d+6/UhjbxzjA2LWMR3B0CatHfDS+1x86rrzSsuJ5
	Z27addhSoRzEOwa5JUSyC/Spzs09LX/VV4lOmr3uo/AJN+MSqIYaUQ2/CdZMeo4uw3Lnoheq6ra
	DgS05j0o8RyLI=
X-Google-Smtp-Source: AGHT+IGCgAInLjL0CmkbDDrN6TkLYI6/KZFnHjmOdpAVPuLAlepbFzUcSq3kcxZkFi5r9ta15KB3RQ==
X-Received: by 2002:a5d:620d:0:b0:3a5:2ef8:34f9 with SMTP id ffacd0b85a97d-3a917603b17mr8190934f8f.27.1751274291416;
        Mon, 30 Jun 2025 02:04:51 -0700 (PDT)
Message-ID: <5165bb0e-db0a-4b03-acf9-9c6a65705370@suse.com>
Date: Mon, 30 Jun 2025 11:04:49 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 0/3] stubdom/grub: avoid relying on start_info
 definition
To: Jan Beulich 
Cc: Samuel Thibault ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250626151344.6971-1-jgross@suse.com>
 <5a423869-d67f-4a98-9fa4-e854bc84e2c7@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: <5a423869-d67f-4a98-9fa4-e854bc84e2c7@suse.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------TaagjCxVx8nzO01vKGtaJs08"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------TaagjCxVx8nzO01vKGtaJs08
Content-Type: multipart/mixed; boundary="------------IhqAUGGIltfvh48ZzGg09aAM";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Jan Beulich 
Cc: Samuel Thibault ,
 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: <5165bb0e-db0a-4b03-acf9-9c6a65705370@suse.com>
Subject: Re: [PATCH v2 0/3] stubdom/grub: avoid relying on start_info
 definition
References: <20250626151344.6971-1-jgross@suse.com>
 <5a423869-d67f-4a98-9fa4-e854bc84e2c7@suse.com>
In-Reply-To: <5a423869-d67f-4a98-9fa4-e854bc84e2c7@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=

--------------IhqAUGGIltfvh48ZzGg09aAM
Content-Type: multipart/mixed; boundary="------------I5dJ0An5Y7gmYbX006uoVDlb"

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

T24gMzAuMDYuMjUgMDk6NTcsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAyNi4wNi4yMDI1
IDE3OjEzLCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPj4gV2l0aCB0aGUgcmVsYXRlZCBjaGFu
Z2UgaGF2aW5nIGJlZW4gYWRkZWQgdG8gTWluaS1PUywgdGhlIHNpbmdsZSBWMQ0KPj4gcGF0
Y2ggY2FuIG5vdyBiZSBleHBhbmRlZCB0byBhIDMgcGF0Y2ggc2VyaWVzLCBlc3BlY2lhbGx5
IG1lYW50IHRvDQo+PiB1bnRhbmdsZSB0aGUgY2xvc2UgZGVwZW5kZW5jaWVzIGJldHdlZW4g
Z3J1Yi1wdiBhbmQgTWluaS1PUyBpbnRlcm5hbHMuDQo+Pg0KPj4gQ2hhbmdlcyBpbiBWMjoN
Cj4+IC0gYWRkIGNvbW1lbnQgdG8gcGF0Y2ggMQ0KPj4gLSBhZGRlZCBwYXRjaGVzIDIrMw0K
Pj4NCj4+IEp1ZXJnZW4gR3Jvc3MgKDMpOg0KPj4gICAgc3R1YmRvbS9ncnViOiBhdm9pZCBy
ZWx5aW5nIG9uIHN0YXJ0X2luZm8gZGVmaW5pdGlvbg0KPj4gICAgQ29uZmlnOiB1cGRhdGUg
TWluaS1PUyBjb21taXQgaWQNCj4+ICAgIHN0dWJkb20vZ3J1Yjogc3dhcCBzdGFydF9pbmZv
IHVzYWdlIHdpdGggc3RhcnRfaW5mb19wdHINCj4gDQo+IEFzIHBhdGNoZXMgMSBhbmQgMyBh
cmUgc3RpbGwgd2FpdGluZyBmb3IgYSBtYWludGFpbmVyIGFjaywgaXMgcGF0Y2ggMiBva2F5
DQo+IHRvIHB1dCBpbiBhaGVhZCBvZiBwYXRjaCAxPw0KDQpUaGF0IHdvdWxkIGJyZWFrIHRo
ZSBncnViLXB2IGJ1aWxkIGFnYWluLg0KDQoNCkp1ZXJnZW4NCg==
--------------I5dJ0An5Y7gmYbX006uoVDlb
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-----

--------------I5dJ0An5Y7gmYbX006uoVDlb--

--------------IhqAUGGIltfvh48ZzGg09aAM--

--------------TaagjCxVx8nzO01vKGtaJs08
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/Ey8FAmhiUzIFAwAAAAAACgkQsN6d1ii/Ey/7
oAf+NizqrvUUqIXLMIX2SuhjzADZ2FG8EMD9xMix4N2r6b2OVbdFtZs/OmPzBE7rDTPWYTAbE8s8
I1w8mXJTDT+AQJ8hUlnaEGfoOt2/bwLsL+hAbuXuHaIy/llGna54THE/T7oEJVckgYgbwYi5FT+G
oOGwbLpYqkHbuiJGgLt3Oy22DH0UItX35VI9AJ7In/WMupvoxcpGVnPDIECdQpmcBxLK+3UtppU8
Hwao2fsmJD0YobJAjrKs8f9xq1lglOU6hpzNbLC3MTIYGJTYiLoJDL90aVxIXog1PETYwWGrp5nU
QTIkP1AnZkT0QyY2QQFMuM3OQl5LVkcAZuQxBO/Jng==
=ngHH
-----END PGP SIGNATURE-----

--------------TaagjCxVx8nzO01vKGtaJs08--


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 10:35:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 10:35:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1029004.1402758 (Exim 4.92)
	(envelope-from )
	id 1uWBqq-0000DR-Jl; Mon, 30 Jun 2025 10:35:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1029004.1402758; Mon, 30 Jun 2025 10:35: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 1uWBqq-0000DK-H0; Mon, 30 Jun 2025 10:35:04 +0000
Received: by outflank-mailman (input) for mailman id 1029004;
 Mon, 30 Jun 2025 10:35:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uWBqp-0000DE-9b
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 10:35:03 +0000
Received: from mail187-29.suw11.mandrillapp.com
 (mail187-29.suw11.mandrillapp.com [198.2.187.29])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e0739d19-559d-11f0-a312-13f23c93f187;
 Mon, 30 Jun 2025 12:35:02 +0200 (CEST)
Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail187-29.suw11.mandrillapp.com (Mailchimp) with ESMTP id
 4bW2bm5NN7z7lmDFF
 for ; Mon, 30 Jun 2025 10:35:00 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 22c1748b0ecc401fbe2d41b116762df6; Mon, 30 Jun 2025 10:35: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: e0739d19-559d-11f0-a312-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1751279700; x=1751549700;
	bh=3W5WXPPkdn52aUe9Wy9HcVhwmubgY5+gcpH4c7xElaU=;
	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=tOEVEjgCJtlYZUjOgPiJb9tEkfGufchSqhTbIWCt84ZeXmVSu8Uo6hkm6txbUJQkT
	 TVdDEBO8CXOwL09waoiTIJrTlsqzIlx/yzTvg6V00Xpunj03iVKmA0J0PJ42VGlO3V
	 Ls0Ei57H/y2p45KDMTAUneOlLMablXAd4FZ/Uh77N0CZhYKwE3IOWGAkPzBZTZSZfF
	 Kbxu+dEuGx2PlyspDcOqDf80p/af+kpJrkcKE6LK0o1YVGHphSmMMQzI6/pGoN6G46
	 NA1PtiQDEne8iLt5P5P78N0pSs+8QVuUhoZJyX06rhfumFoEF4h/dSWO2sI9J8kOmx
	 TR8egOtfF4HQg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1751279700; x=1751540200; i=ngoc-tu.dinh@vates.tech;
	bh=3W5WXPPkdn52aUe9Wy9HcVhwmubgY5+gcpH4c7xElaU=;
	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=wXGlQIOIhIbfW6kLf/ynzX85XjL0d232aZ48D+2wdo+9jZM0YQ2FOahZIrSzmxMld
	 rhGTSHw//mQg+1luzlKOacrwRclk4XCMrGLzITGjlVwMpMje/cIcU5/uFdBPwYcpIL
	 GUzAb231FOaNhMarxeaAG1JpASfFgJ9W2SMN+kJtMx8UPoj1uEYTwGU1pmbou358/q
	 Hpvb5UtedRyx/sHxVBLV/c2k/RDlMqbMLi1WznzBEQWJHKectHCM5CVNUMrKEbQf43
	 AebppOwChVJrkyKPvzLLKBCrQJSgVC+5738yVJzI00LJZnZIUMkOZ1FArnh27oWplc
	 qIydqFk5pubkg==
From: "Tu Dinh" 
Subject: =?utf-8?Q?Re:=20[RFC=20PATCH]=20xen/gntdev:=20reduce=20stack=20usage=20by=20dynamically=20allocating=20gntdev=5Fcopy=5Fbatch?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1751279699533
Message-Id: <5e67d651-830a-4d99-af37-26f2d0efd640@vates.tech>
To: "Abinash Singh" , jgross@suse.com, sstabellini@kernel.org
Cc: oleksandr_tyshchenko@epam.com, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, "Abinash Singh" 
References: <20250629204215.1651573-1-abinashsinghlalotra@gmail.com>
In-Reply-To: <20250629204215.1651573-1-abinashsinghlalotra@gmail.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.22c1748b0ecc401fbe2d41b116762df6?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250630:md
Date: Mon, 30 Jun 2025 10:35:00 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Hi,

On 30/06/2025 06:54, Abinash Singh wrote:
> While building the kernel with LLVM, a warning was reported due to
> excessive stack usage in `gntdev_ioctl`:
> 
> 	drivers/xen/gntdev.c:991: warning: stack frame size (1160) exceeds limit (1024) in function 'gntdev_ioctl'
> 
> Further analysis revealed that the large stack frame was caused by
> `struct gntdev_copy_batch`, which was declared on the stack inside
> `gntdev_ioctl_grant_copy()`. Since this function was inlined into
> `gntdev_ioctl`, the stack usage was attributed to the latter.
> 
> This patch fixes the issue by dynamically allocating `gntdev_copy_batch`
> using `kmalloc()`, which significantly reduces the stack footprint and
> eliminates the warning.
> 
> This approach is consistent with similar fixes upstream, such as:
> 
> commit fa26198d30f3 ("iommu/io-pgtable-arm: dynamically allocate selftest device struct")
> 
> Fixes: a4cdb556cae0 ("xen/gntdev: add ioctl for grant copy")
> Signed-off-by: Abinash Singh 
> ---
> The stack usage was confirmed using the `-fstack-usage`  flag and mannual analysis, which showed:
> 
>    drivers/xen/gntdev.c:953: gntdev_ioctl_grant_copy.isra   1048 bytes
>    drivers/xen/gntdev.c:826: gntdev_copy                     56 bytes
> 
> Since `gntdev_ioctl` was calling the inlined `gntdev_ioctl_grant_copy`, the total
> frame size exceeded 1024 bytes, triggering the warning.
> 
> This patch addresses the warning and keeps stack usage within acceptable limits.
> Is this patch fine or kmalloc may affect performance ?
> ---

Have you measured the performance impact? gntdev_ioctl_grant_copy is 
called quite often especially by the backend. I'm afraid calling the 
allocator here may cause even more slowdown than there already is, 
especially when memory is tight.

>   drivers/xen/gntdev.c | 24 +++++++++++++++---------
>   1 file changed, 15 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> index 61faea1f0663..9811f3d7c87c 100644
> --- a/drivers/xen/gntdev.c
> +++ b/drivers/xen/gntdev.c
> @@ -953,15 +953,19 @@ static int gntdev_grant_copy_seg(struct gntdev_copy_batch *batch,
>   static long gntdev_ioctl_grant_copy(struct gntdev_priv *priv, void __user *u)
>   {
>   	struct ioctl_gntdev_grant_copy copy;
> -	struct gntdev_copy_batch batch;
> +	struct gntdev_copy_batch *batch;
>   	unsigned int i;
>   	int ret = 0;
>   
>   	if (copy_from_user(©, u, sizeof(copy)))
>   		return -EFAULT;
> -
> -	batch.nr_ops = 0;
> -	batch.nr_pages = 0;
> +
> +	batch = kmalloc(sizeof(*batch), GFP_KERNEL);
> +	if (!batch)
> +		return -ENOMEM;
> +
> +	batch->nr_ops = 0;
> +	batch->nr_pages = 0;
>   
>   	for (i = 0; i < copy.count; i++) {
>   		struct gntdev_grant_copy_segment seg;
> @@ -971,18 +975,20 @@ static long gntdev_ioctl_grant_copy(struct gntdev_priv *priv, void __user *u)
>   			goto out;
>   		}
>   
> -		ret = gntdev_grant_copy_seg(&batch, &seg, ©.segments[i].status);
> +		ret = gntdev_grant_copy_seg(batch, &seg, ©.segments[i].status);
>   		if (ret < 0)
>   			goto out;
>   
>   		cond_resched();
>   	}
> -	if (batch.nr_ops)
> -		ret = gntdev_copy(&batch);
> -	return ret;
> +	if (batch->nr_ops)
> +		ret = gntdev_copy(batch);
> +	goto free_batch;
>   
>     out:
> -	gntdev_put_pages(&batch);
> +	gntdev_put_pages(batch);
> +  free_batch:
> +	kfree(batch);
>   	return ret;
>   }
>   



Ngoc Tu Dinh | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Mon Jun 30 10:50:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 10:50:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1029025.1402772 (Exim 4.92)
	(envelope-from )
	id 1uWC5W-0002wL-2A; Mon, 30 Jun 2025 10:50:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1029025.1402772; Mon, 30 Jun 2025 10: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 1uWC5V-0002wE-UZ; Mon, 30 Jun 2025 10:50:13 +0000
Received: by outflank-mailman (input) for mailman id 1029025;
 Mon, 30 Jun 2025 10: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 1uWC5U-0002w8-Jn
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 10:50:12 +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 fdf08616-559f-11f0-b894-0df219b8e170;
 Mon, 30 Jun 2025 12:50:09 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3a522224582so2193595f8f.3
 for ; Mon, 30 Jun 2025 03:50:09 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a892e598d2sm10012305f8f.76.2025.06.30.03.50.08
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 30 Jun 2025 03:50:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fdf08616-559f-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1751280609; x=1751885409; 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=bkLwNmYLuKyQcclKDsE/w8VukAwLC8KPQfw31AtdgXc=;
        b=ZEqU3YNjUJ0DLL3mQ1f52hvywu74K1BIrR1EIQH7XHrm5NaZOzuRboJru6uAJBUPjG
         HRHAC8vGfkET+3412URXeu7XK2duvKqLhfMMOjDF3jr24MCh38m/nR9+wdfMaAMvHO0G
         WxVJ5WwGrlPQC0q4uJdli42ZVOU+0mDDzqAXk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751280609; x=1751885409;
        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=bkLwNmYLuKyQcclKDsE/w8VukAwLC8KPQfw31AtdgXc=;
        b=jTX1nHsELpMlE5vLpEh0/0fayYdKNqqeGoHQPZCEiJmvnIpfvh7xFHDb4MuFpIUVC8
         8KsTntkdsBietgGTd0uvmvHcxJTSeWFRMvVpXjEnQEwndLes0UNK5yShWjMAesQvmTwO
         7EauVtO2Iy8CXB6SEPGVDitE4ZPlitWm0ApbZoNaLUxIiqYPVm0yFC4MUpDoftmp7s5G
         UXIYyZGQ0XCjH/yMIIJhwN7Rk7c0JWs6Cx+OCaegn6txZUdVysUoKlNHfwU46sP+O0IL
         iaAu3Clh1LaoXpuEGglAfZFc3Z4m7Qq5qTdNV2zcIF5bzqk/19OA1fMY00XDzW94utBU
         GJIA==
X-Gm-Message-State: AOJu0YxTHahnnt/VlbJ4S2GLHBLoBv/1MRW85pXGZbBSp/Q1tbqNsDXr
	3kRjAJgg7tJ/53c6fZzzzgYzmGOvRL+UZA9dzNEgUB+rwSEUW4bDAclhm/6Rex9Sims=
X-Gm-Gg: ASbGnct/kYzf2bAtRfFud3tOO6uq0aTPRFYTkub0YcpS905bR9taPLeH0J0NxWZEwGK
	bR9B0td1GTPA+mTaw+3wg59aaGw/+zGZlempJr5dqdJBphnf88dhXoBqvqVxAWVs7fUhaQ7WVYt
	lxLdtXKw9WrNg0Uh95+DqE1qECst1ycgd+FlOBHKQBUn8eb3U0bhY0Na1h7s8LJ8x4hk/vDYwef
	oNtQOW1cVYF3Jh3sYqU7G0EvAaZbpUORJJXdcXPj8+Efd1tP0gBHYUZHjjl5/Am9goeQ+/wM8Sv
	6vq+1BeHl6t9rLicqsnrDhvcGSd5lG/u0G+Xbbjm1gq7Ikpa/2CF5dsn+88fzAlwVbztICMcBDN
	n7qXzrbCqZtLFCNFqfhgqaY13yUKZvw==
X-Google-Smtp-Source: AGHT+IEIY3Lr+Z/f+DlD7L6QGBJTAydGU9BalpBaz8gtwJIWtLVX2jHzIZ6Iux/cqCwC0tBHcjLOBw==
X-Received: by 2002:a05:6000:4408:b0:3a4:eecf:b8cb with SMTP id ffacd0b85a97d-3a8ffccac65mr8908416f8f.28.1751280609142;
        Mon, 30 Jun 2025 03:50:09 -0700 (PDT)
Date: Mon, 30 Jun 2025 12:50:07 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Andrew Cooper 
Cc: Xen-devel ,
	Ross Lagerwall ,
	Jan Beulich ,
	Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= ,
	"Daniel P . Smith" 
Subject: Re: [PATCH 1/3] x86/EFI: Fix detection of buildid
Message-ID: 
References: <20250605111638.2869914-1-andrew.cooper3@citrix.com>
 <20250605111638.2869914-2-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: <20250605111638.2869914-2-andrew.cooper3@citrix.com>

On Thu, Jun 05, 2025 at 12:16:36PM +0100, Andrew Cooper wrote:
> The format of the buildid is a property of the binary, not a property of how
> it was loaded.  This fixes buildid recognition when starting xen.efi from it's
> MB2 entrypoint.
> 
> Suggested-by: Ross Lagerwall 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Roger Pau Monné 

Some possibly useless rants below.

> ---
> CC: Jan Beulich 
> CC: Roger Pau Monné 
> CC: Ross Lagerwall 
> CC: Marek Marczykowski-Górecki 
> CC: Daniel P. Smith 
> 
> I don't like this patch and tried hard to do it in a better way, but the EFI
> aspects of the build system are too intractable.
> 
> While on x86 I can in principle pull the same common-stubs.o trick, split on
> XEN_BUILD_PE rather than XEN_BUILD_EFI, that doesn't work on ARM which
> hand-codes it's PE-ness.  Also, it's really not EFI related, other than as a
> consequence of that being the only reason we use PE32+ binaries.

Since this is already gated on CONFIG_X86 you could pass XEN_BUILD_PE
as a define in CFLAGS, and use it together with the CONFIG_X86 check?

That however would still put the code in the .gz binary, as the object
file would be the same for both builds.  Otherwise we would need to
compile this twice and use the different object files for the PE vs
ELF images, which seems extremely cumbersome for a little benefit, as
this is init-only code that would be gone once booted.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 11:42:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 11:42:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1029061.1402789 (Exim 4.92)
	(envelope-from )
	id 1uWCuI-0000qc-Sm; Mon, 30 Jun 2025 11:42:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1029061.1402789; Mon, 30 Jun 2025 11:42: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 1uWCuI-0000qV-QC; Mon, 30 Jun 2025 11:42:42 +0000
Received: by outflank-mailman (input) for mailman id 1029061;
 Mon, 30 Jun 2025 11:42: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 1uWCuH-0000qP-Ez
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 11:42:41 +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 531c11b8-55a7-11f0-b894-0df219b8e170;
 Mon, 30 Jun 2025 13:42:39 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3a588da60dfso1216770f8f.1
 for ; Mon, 30 Jun 2025 04:42:39 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-318c14e224csm9146641a91.32.2025.06.30.04.42.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 30 Jun 2025 04:42:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 531c11b8-55a7-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1751283758; x=1751888558; 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=/eVulYssM1kQlc6S6ZkCc8s3/n4KwIjd96GCkHhSpLc=;
        b=cR0u/w+JYT9MAIHnQobcNIurfP42eJZGORm6I9N+m7iepJgQjLwag+zU63DSY52Chz
         WFqjVsR/tTH/6fBUjKZK1k94jP4w9/T2nPzP6HT8p1K2CF5Y5P+X7XSshsWgOQMkGaAQ
         W7VWXjtOvNfFUoU6z6RsKKRfDRsDU3AoKiAnuZBnuzokfu9KURhdE4ew6U9k2to/GZL1
         7rgIgAJELYkCErqrO07erYcufqMR/8ZX34gkFnIylKi13KShGynkeiRIMnVX4H2oPPVz
         QYJl/wtNHGITy+wfZHWjBsSO1ocMINaqHNh88OWfk72xEY/bzH53DJ/fiPYOlDvODLYT
         R8GA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751283759; x=1751888559;
        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=/eVulYssM1kQlc6S6ZkCc8s3/n4KwIjd96GCkHhSpLc=;
        b=PjfHaTNZDCLEwtilgxm+mBepwo51dcgzetbycsXA8Akk29MvJw6glCgPn3pbBRxPBG
         Gn2ubiRiiZSW9mGQ02honv1f3WPGIjXP4nA4fhwpkPrnN55LKroyRx0g/oSZEM0iHYdg
         b5JHaxZwgEK6itnwpz3Fye0kZOFEiKVpeesJ66PetblevaJEWvg5AhNVWGaqNa5N6P2m
         9eDKPDU8QYhQhlQnKRxZPykvcBWc8oduITZN25HTMOJSV/hJ6r/t9rpSdelbBWJgdiU7
         G3dZ3r8Ah//VEAqFfSbkYRZ7IkN8D4PSJ1yl3pOKB9QqNzYlvEw6hURnX15B406vour+
         eo3Q==
X-Gm-Message-State: AOJu0YxHUCx85ocuuJGuqd56tSndyhoV/enghtIplAgY3tqt/LX7FpUR
	yjnM1Uw3qrzEA4s04il/WjRrxkwHJ+ArwuoN66BfJf0GIRPBJY/t931BU30UtEBH9EkXyqkPXtX
	zEPg=
X-Gm-Gg: ASbGnctykxmTSKde8MEY4WiA8PQOJym24ZOqPR8k0JZ3BpaQEoLUOh/eO1pYoW1cnuq
	7KwjXeTuNDSew//zRpcAhHxzvFsU1jSh5Orbwrs8tBtf1vC6/+Bh91fv6La0fi7PslWX5xkMYnu
	Gp6YP54Z5XBzNN7a7DeNsd21VgTKiTcraOhhHQMvmsqmLla/Lbx5Kz591rTcA87fxXXac0a4QaP
	0SSxGV9Im4AED7tRTdReEnPJrt0kRkjt7/ZA1IWtLFM4n1TpC6L/ep00lQPaLl8WHX8ibDWJhZe
	kHhGAXePG7hk7vh6Wumv9gi8w7SXMEurVZij85tnoo2W/j7VUDDHNq0mPFAF3Mge4CVCe6/rtzi
	DNkYYQRdxDb9tTzRrX5X8HnXpoJUUbM0llzPnoFpKjPwzHmM=
X-Google-Smtp-Source: AGHT+IHIY/GdcoG34snCr+E2mCNV++T094l+hnLEk6ccN0U7ZVqt122MCCdAMMfs/zMDNRS1rpQ4Gg==
X-Received: by 2002:a05:6000:710:b0:3aa:c9a8:a387 with SMTP id ffacd0b85a97d-3aac9a8a39cmr7320674f8f.0.1751283758561;
        Mon, 30 Jun 2025 04:42:38 -0700 (PDT)
Message-ID: <7fa05d3f-2f85-4a42-9549-b68a486e30ea@suse.com>
Date: Mon, 30 Jun 2025 13:42:31 +0200
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?= 
From: Jan Beulich 
Subject: [PATCH] x86/SMP: guard socket_cpumask[] access in cpu_smpboot_free()
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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

Before CPU identification has run (and it may not have run at all e.g.
when AP bringup failed altogether), cpu_data[].phys_proc_id (which is
what cpu_to_socket() resolves to) can't really be used. The use of
cpu_to_socket()'s result as an array index cpu_smpboot_free() therefore
needs guarding, as the function will also be invoked upon AP bringup
failure, in which case CPU identification may not have run.

Without "x86/CPU: re-work populating of cpu_data[]" [1] the issue is
less pronounced: The field starts out as zero, then has the BSP value
(likely again zero) copied into it, and it is properly invalidated only
in cpu_smpboot_free(). Still it is clearly wrong to use the BSP's socket
number here.

Making the guard work with and without the above patch applied turns out
interesting: Prior to that patch, the sole invalidation done is that in
cpu_smpboot_free(). Upon a later bringup attempt, the fields invalidated
are overwritten by the BSP values again, though. Hence compare APIC IDs,
as they cannot validly be the same once CPU identification has run.

[1] https://lists.xen.org/archives/html/xen-devel/2024-02/msg00727.html

Signed-off-by: Jan Beulich 
---
Sadly there was no feedback at all yet for the referenced patch.

--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -958,7 +958,13 @@ static void cpu_smpboot_free(unsigned in
     unsigned int socket = cpu_to_socket(cpu);
     struct cpuinfo_x86 *c = cpu_data;
 
-    if ( cpumask_empty(socket_cpumask[socket]) )
+    /*
+     * We may come here without the CPU having run through CPU identification.
+     * In that case the socket number cannot be relied upon, but the respective
+     * socket_cpumask[] slot also wouldn't have been set.
+     */
+    if ( c[cpu].apicid != boot_cpu_data.apicid &&
+         cpumask_empty(socket_cpumask[socket]) )
     {
         xfree(socket_cpumask[socket]);
         socket_cpumask[socket] = NULL;


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 11:45:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 11:45:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1029068.1402800 (Exim 4.92)
	(envelope-from )
	id 1uWCwy-0001Nk-8W; Mon, 30 Jun 2025 11:45:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1029068.1402800; Mon, 30 Jun 2025 11: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 1uWCwy-0001Nd-5w; Mon, 30 Jun 2025 11:45:28 +0000
Received: by outflank-mailman (input) for mailman id 1029068;
 Mon, 30 Jun 2025 11:45: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 1uWCww-0001NX-G5
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 11:45: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 b52b6712-55a7-11f0-b894-0df219b8e170;
 Mon, 30 Jun 2025 13:45:23 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a6f2c6715fso2237512f8f.1
 for ; Mon, 30 Jun 2025 04:45:23 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-74af55c5f38sm9141562b3a.108.2025.06.30.04.45.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 30 Jun 2025 04:45:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b52b6712-55a7-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1751283923; x=1751888723; 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=F7A6t9NWEWwY8Zy1mr641xlx/zKNYi4cn7Tits2bsB8=;
        b=KY8EnW87bYMlqJm7SFGEuGvxKans+CfHlp+A2QVM9h/QIGiQVUSMzFlQeyzMeao+fO
         CA61ATLlOxDmNEN4Dmzjs1unze25Cl1Os9gki0XGKdBwS4TeY7XfR0w7RgXybgu96a7Y
         PDRlYijHjG+a08qSKs+gJqCxELZ5lblwVLap0yEWVJbmCBUW3IyB2fG9mxkhNeG++JS3
         k7iFi7rpscGKogb5aIu1NA5AN1OpowSh0UjNxbnfy56JfuhldhgZp+qXgndLNgi/kvMi
         sRHh+hWfatNF/veUMf1UAvvIWJ5EPhc0WjFhiPbI67p0zmeTVZkN7Cj2byA4LGdaGa4T
         8OKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751283923; x=1751888723;
        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=F7A6t9NWEWwY8Zy1mr641xlx/zKNYi4cn7Tits2bsB8=;
        b=m4MajthP0xHqJrAn8wa5DAIXmsabuHy8RtJeQXI+83uc4+R0tstX4EihKFcG5ayoZ8
         UOKvJ2NMzfRJxGiThyctU0BrE6UTfXbqzzNawiTkNuc8ob+qB3/HNg8Ehc2x9sgnbChZ
         GY1gVF3W9VWK/bbt0fHuVbJl0ngI6XY4N5EYDWZlUQW/OQGKV5FfRe1lzVNOl8gqEMCj
         687sky4f4lH70FnAdTfIEHJZERfNae9jDIT5zjXxrwMYczycyz0+ze/B2idLkvt3e1L2
         rp9sGOD3CDp/6sqyH18Kkt5hdxJ16WbXkjiy6ZiRNu6Wl06EcS38p8YRykxsR7vi3Quh
         OJJQ==
X-Gm-Message-State: AOJu0YxD5EGLbBc88LE9xD3bz5nR9LznYNLU5afu4bmzxeaQnQnupPRo
	KV7a4SBMqwuaj5pD3ZTb/aljwmw4a19JFUY2o4yfOZz71UxnAQkVkiTqflGTmUkHDmN4ZP9QT/O
	E9+I=
X-Gm-Gg: ASbGnctS/fYLBWxtF+pzMrp0rjgFGDpqF8AyGjZs0qWTGk14jGWNzdBqc+aIZcP6IXX
	/PjSDohU3Ol2aU7dm76bHNVhpJrAAuj5mQN6O0QK93QwD40pDRW1elAMGb0ova5UZeG3r67vUIO
	0sZHRHNf4SfdpKo44U6qBPuRz84ICtypJVRpDZA3fv8a48oB27ht/EmPKsTW1Z6TEVjd77M58rZ
	0RBs+Zj7IhFchJoNOjTY/KpeA0Kz9+yzQD4/hEHKAYEDWoLJyn29S7t4lPH+mg/kAaxBmZk8dRZ
	kSmVT6o385K0gFKhrnWBvn8Vc1QpNfGdNamERzsuxoY/DdXJM+DUeEIuuPFcMd6U5Z+phAPA8dQ
	JGmTukPif6e5JLuUo9oIR/9vQhBYBC1Nv4Pp9zj8V2f8kANo=
X-Google-Smtp-Source: AGHT+IGADTwG1thslrgUpt7vUOpQDbrkuQkQ1lQPKJQbr3rsWxLg4V47bYZIdYKjHHpvVqMt/i674w==
X-Received: by 2002:a05:6000:2712:b0:3a3:4baa:3f3d with SMTP id ffacd0b85a97d-3a8f435de5fmr7367675f8f.6.1751283923074;
        Mon, 30 Jun 2025 04:45:23 -0700 (PDT)
Message-ID: <943ed2bf-07c8-4cd1-a745-1f8648bd0403@suse.com>
Date: Mon, 30 Jun 2025 13:45:16 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/SMP: guard socket_cpumask[] access in
 cpu_smpboot_free()
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <7fa05d3f-2f85-4a42-9549-b68a486e30ea@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: <7fa05d3f-2f85-4a42-9549-b68a486e30ea@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 30.06.2025 13:42, Jan Beulich wrote:
> Before CPU identification has run (and it may not have run at all e.g.
> when AP bringup failed altogether), cpu_data[].phys_proc_id (which is
> what cpu_to_socket() resolves to) can't really be used. The use of
> cpu_to_socket()'s result as an array index cpu_smpboot_free() therefore
> needs guarding, as the function will also be invoked upon AP bringup
> failure, in which case CPU identification may not have run.
> 
> Without "x86/CPU: re-work populating of cpu_data[]" [1] the issue is
> less pronounced: The field starts out as zero, then has the BSP value
> (likely again zero) copied into it, and it is properly invalidated only
> in cpu_smpboot_free(). Still it is clearly wrong to use the BSP's socket
> number here.
> 
> Making the guard work with and without the above patch applied turns out
> interesting: Prior to that patch, the sole invalidation done is that in
> cpu_smpboot_free(). Upon a later bringup attempt, the fields invalidated
> are overwritten by the BSP values again, though. Hence compare APIC IDs,
> as they cannot validly be the same once CPU identification has run.
> 
> [1] https://lists.xen.org/archives/html/xen-devel/2024-02/msg00727.html

Fixes: 4824bdfdabeb ("x86: add socket_cpumask")

> Signed-off-by: Jan Beulich 
> ---
> Sadly there was no feedback at all yet for the referenced patch.
> 
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -958,7 +958,13 @@ static void cpu_smpboot_free(unsigned in
>      unsigned int socket = cpu_to_socket(cpu);
>      struct cpuinfo_x86 *c = cpu_data;
>  
> -    if ( cpumask_empty(socket_cpumask[socket]) )
> +    /*
> +     * We may come here without the CPU having run through CPU identification.
> +     * In that case the socket number cannot be relied upon, but the respective
> +     * socket_cpumask[] slot also wouldn't have been set.
> +     */
> +    if ( c[cpu].apicid != boot_cpu_data.apicid &&
> +         cpumask_empty(socket_cpumask[socket]) )
>      {
>          xfree(socket_cpumask[socket]);
>          socket_cpumask[socket] = NULL;



From xen-devel-bounces@lists.xenproject.org Mon Jun 30 11:53:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 11:53:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1029071.1402809 (Exim 4.92)
	(envelope-from )
	id 1uWD4f-000316-Ut; Mon, 30 Jun 2025 11:53:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1029071.1402809; Mon, 30 Jun 2025 11: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 1uWD4f-00030z-S7; Mon, 30 Jun 2025 11:53:25 +0000
Received: by outflank-mailman (input) for mailman id 1029071;
 Mon, 30 Jun 2025 11:45: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 1uWCxJ-0001NX-59
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 11:45:49 +0000
Received: from AM0PR83CU005.outbound.protection.outlook.com
 (mail-westeuropeazlp170100001.outbound.protection.outlook.com
 [2a01:111:f403:c201::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c2bd5343-55a7-11f0-b894-0df219b8e170;
 Mon, 30 Jun 2025 13:45:46 +0200 (CEST)
Received: from AM0PR08CA0024.eurprd08.prod.outlook.com (2603:10a6:208:d2::37)
 by GVXPR08MB11036.eurprd08.prod.outlook.com (2603:10a6:150:1f6::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8880.31; Mon, 30 Jun
 2025 11:45:44 +0000
Received: from AM3PEPF00009B9D.eurprd04.prod.outlook.com
 (2603:10a6:208:d2:cafe::67) by AM0PR08CA0024.outlook.office365.com
 (2603:10a6:208:d2::37) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8880.30 via Frontend Transport; Mon,
 30 Jun 2025 11:45:43 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 AM3PEPF00009B9D.mail.protection.outlook.com (10.167.16.22) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8901.15
 via Frontend Transport; Mon, 30 Jun 2025 11:45:42 +0000
Received: from AS2PR08MB8745.eurprd08.prod.outlook.com (2603:10a6:20b:55d::22)
 by DB9PR08MB9756.eurprd08.prod.outlook.com (2603:10a6:10:45f::5) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8880.24; Mon, 30 Jun
 2025 11:45:08 +0000
Received: from AS2PR08MB8745.eurprd08.prod.outlook.com
 ([fe80::a4bd:fd62:e7f:76d5]) by AS2PR08MB8745.eurprd08.prod.outlook.com
 ([fe80::a4bd:fd62:e7f:76d5%4]) with mapi id 15.20.8857.026; Mon, 30 Jun 2025
 11:45: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: c2bd5343-55a7-11f0-b894-0df219b8e170
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=FmP8akNDuz6bZDwOqNVmlx3pyPz5u4/Kb3mEiW/7fETw/CqY71XL9JlnnmGcE/P9DZ3b7g9T4o5WCpnjE9AIh3V6b1oalsfFSDswxojDR05wBLZvhp+tt6P4xwZbxV3bByPlM0DSzYg3q8te+9RTfHKryHjp5SdCNb8Cj357IjN1dsmaW//1LMYZwocD5gi9ESAOk2oA0aUw3Fel9PAr2DvSqFgA4+fL8eJbZUjd9QLtY/gbdQzgzG6IGvvAOgzY5UJUc/TRODsN10/uUj7uhVlVVbSrkR8K4qQizIejpg55MUBH2bAna6K4EL/fCFRJ1VWs8f3xPz/2HrPcxElveA==
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=Xn2ZK+VqFiaGG5mPNYYMsu2lmvc7VsqR/hcsBw+qkpQ=;
 b=H/eIu8RDRwMYTpsqNQ/AmN++xzu/sG55eZxMoZqo97ouOIjkmN7+V6GhEFzvX2URxXUpq7o3ujDkr2DOxuYewmXEUh/sOoTyK6e6UQEiqc5OUBCh8wL0NXEG6PJI13UVtpAWmmW3VuSxfstviH0+7DTDrx0h8dAuNc8dOH6X+wxIbYeOcQTabpPLd3fk4/JWLTonYt2tm+K5bXUPufAqQOmunJcGPnIXzFX2sgtkZwzNtQMr8uPOF+dOl19Z/UpWLFTO6SahC/PIgwXiypV5/bdO1tXdsVInSjc91yTp+sZzGcEDI8fQmE+g7cVrW2Q3EhNnvtzgdqWwWWSFFmCS7g==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=amd.com smtp.mailfrom=arm.com; dmarc=pass
 (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
 (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Xn2ZK+VqFiaGG5mPNYYMsu2lmvc7VsqR/hcsBw+qkpQ=;
 b=k1Hmws9ZtEB2+7+7Cu18aqruh5Mqruybk5OPN2okzF+n/ZBPRXCsM21nvv2D90Bq04v/gH08Jg5tsCGwSSZtM6szkTNAVwvJj67jVhhhD0ITJjUr99Ww+IQw1pPtJ83c5wpy1Wb4GXrYFPnKYswnU7+XnPUMi++2fEpXsdy0j3I=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=PL/lUDKxqlZ0EqrEBjhF8IuQzEMMkbP+JMYCZwfo393EXYbp9BjcjD1vh+xu/unqjcwZF1YCFXJ3WHSjyEaH5ptm2SsiZZu94M10ddwSEj9dyljBq8t/wmIrKbzzJgi54ksPHH48/b4AAR9DiV5EenIikD0KfdnTxjNWfoBB/w9tcWRQtNV6rQR4we0rEWeECFulXiiEOXI4z7wbN/Bk221QnvstXK0GaljD2zDAfWMUvCGyyLCqyyQnFF91QQwU95HPYlGB1t5Ht0nBOv19awCIb9YNAlzN6OAJPgMCVHKSlC3YMNEcJy9VyVy8JZ3y5G8DbF6eNItmdCifk1ilXQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Xn2ZK+VqFiaGG5mPNYYMsu2lmvc7VsqR/hcsBw+qkpQ=;
 b=VP9yfUyjT6WubT/vB4109cn2iiDSEeTmyvsiMFkTyorMGYtQdYNZ4TfeEfLbDz2C8rj9yj45fXKUz+cmaiaR42JUohzZ7I58/jYsEsMVebOkmCA0yTKYX3B3gLdX/EaLhUde/J56UmGApmV3S36WJrP2XYY4xx6AsN/zcaK3vq01Zm5pasf2rr16j144YCqUVZprETLrYoDBCBCh8MhMFyg1vAxGBdExCOUWLxnioSliuTlFxuz5Ob7paA4adnY57aiQW7jZFCKPa7pWvZ9bJwRkkmN/s5FuKRl9I460bRaqt0E/sL5R8gmL5mUPqJBw74t+Szz+AdvqX9h4cS5ntA==
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=Xn2ZK+VqFiaGG5mPNYYMsu2lmvc7VsqR/hcsBw+qkpQ=;
 b=k1Hmws9ZtEB2+7+7Cu18aqruh5Mqruybk5OPN2okzF+n/ZBPRXCsM21nvv2D90Bq04v/gH08Jg5tsCGwSSZtM6szkTNAVwvJj67jVhhhD0ITJjUr99Ww+IQw1pPtJ83c5wpy1Wb4GXrYFPnKYswnU7+XnPUMi++2fEpXsdy0j3I=
From: Hari Limaye 
To: "Orzel, Michal" , "xen-devel@lists.xenproject.org"
	
CC: Luca Fancellu , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Volodymyr Babchuk 
Subject: Re: [PATCH 1/6] arm/mpu: Find MPU region by range
Thread-Topic: [PATCH 1/6] arm/mpu: Find MPU region by range
Thread-Index: AQHb4cjCVnITZP0lYkm5xkhDeTI89bQW6EcAgAS2Gww=
Date: Mon, 30 Jun 2025 11:45:07 +0000
Message-ID:
 
References: 
 
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	AS2PR08MB8745:EE_|DB9PR08MB9756:EE_|AM3PEPF00009B9D:EE_|GVXPR08MB11036:EE_
X-MS-Office365-Filtering-Correlation-Id: 1b2d4f07-29a7-40f2-2940-08ddb7cba4a4
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|8096899003|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?us-ascii?Q?/qnYdGZv2GUszyKpGAoZLSDLXXM7q8OJFGlLxQoaqkdi0H87GmaS1yizgaVK?=
 =?us-ascii?Q?U66GLFfvafQQb+hamKqIgg81TsVNTAYDTFOVBcXXy3qxbM8psjavDL+hmwE7?=
 =?us-ascii?Q?WlDU5DSPmFlIpclff8A+mmY8szH+j41eyH+HkUc09angjZUbyCnbQml1jrBE?=
 =?us-ascii?Q?XnMSrUX1cbThANpfcc0Q9r+HqnqIwPRxSXgycOo19iz6hDsG0s7/tNct+Wpa?=
 =?us-ascii?Q?b8FAaBQoEptSTO19yTaRTmmuLyNAyC4PTNWSsrhdKXIQ722/bLhWmFJpF19N?=
 =?us-ascii?Q?ekWu6NzX7Ret34X+uj1yNfT5BVb89alwfnDPC06WnYz2J0Y8aiPafL5YnHoC?=
 =?us-ascii?Q?Vi7KOydrPtda8t3W/ZchTIy3dgoX5yBFP2cryrh9kafiaQlASnyXiNS8j9gF?=
 =?us-ascii?Q?U8lAjr4YokIn9R4mwXMHjWsFLQBFCFU4XiAAPCQs5r/17Ylk460VFC0QYKRe?=
 =?us-ascii?Q?r6A99tTwEXtIJdIUlEkN71lFYDCIDYyuc5oFL0nx0KRDexkBIj0K1Gge2GmO?=
 =?us-ascii?Q?8gO2XtWkxnDhGUATf5hamY+MoLBnuGu2gP5ydtB5ngWGKw8JdnYcIIGhlKsf?=
 =?us-ascii?Q?PtrfOCk32VMoI2KW2u88qdByM7eKXSczcAW1/wboBTSVMMTItdHkSnkQZjQw?=
 =?us-ascii?Q?ZM+aP67gOdq6t+tTWfxjoc5XE7LvwIcJtaHyAm87WOcjhHsuC6Htida0gXgG?=
 =?us-ascii?Q?31DKF1oo2DY7ei6LFfHUYpqiosOb/Olh925AEYY5doxbXLLHPhxpfZkEUeBA?=
 =?us-ascii?Q?E7MTvrRf5r8qbSEr3MQ5ztLVYa1QtMsmISVIrZlO00yRwani8uUd4TqW7RER?=
 =?us-ascii?Q?xYaAtrOQs3X5pHrBvfu32fYS1NS6YUtwrIg2BbDhCS83NpCw2UYzFYb+eRot?=
 =?us-ascii?Q?pneAX0JDnXQ6Cu0g5fE0a5bWc2xhAWiMes8DCvyGrfmTLMwQ26tVCaXvY0Jb?=
 =?us-ascii?Q?+XzYIeF1ovS1QpFvJRoG5xt4x/J/ux+a/2Qx5qjAQJxIs3T1jKDsQ2V4XbFc?=
 =?us-ascii?Q?jXVm0uU1eMJOtJZyi+0scDTFo7jf293VhNndQuH/gNtLIm8aKYoIrc9Ytk+j?=
 =?us-ascii?Q?Fmp8RcCOpqVTPFsRInJESy6pDh13OlMwogTDMoL1WTDRsL6KChBvfGSwGwIm?=
 =?us-ascii?Q?WNp/F9F7uafLa37aay7pD9qr2w4fcuCXk5563DfC/wxq46F0FRjajpgh67S7?=
 =?us-ascii?Q?HEAJF5gNTkAL4n1yBrnlD1LcBeV74WAlpnGge29UIEaQtzcwuwuIUopx0lYc?=
 =?us-ascii?Q?LMMbSbihN4MDwIj5Ysk3li2+rXNBbkc+cglL9WU7iaikd6jmX2ZlWljW+dUR?=
 =?us-ascii?Q?30EUnHAdj2x3z2zDT1Zw1FOxFW7jZnVvfa4/aUUelCzGTan4HjBXuwCDHNts?=
 =?us-ascii?Q?ndlg8zETl1kuh7QgRQokR4bpdFJo5uutaj5QdVblR6I7m/GKnkEZNHXK+hCv?=
 =?us-ascii?Q?iyBP3FHZ9dBYNB8p/CuBJf5gIelu07VbbA1iSeJ8HrFv10NkfuyeWw=3D=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR08MB8745.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(8096899003)(38070700018);DIR:OUT;SFP:1101;
Content-Type: multipart/alternative;
	boundary="_000_AS2PR08MB87459E5BFB3D0CF492FF6E47E246AAS2PR08MB8745eurp_"
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB9756
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AM3PEPF00009B9D.eurprd04.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	474c81f2-d736-4697-2be0-08ddb7cb8fab
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|35042699022|82310400026|14060799003|36860700013|1800799024|8096899003;
X-Microsoft-Antispam-Message-Info:
	=?Windows-1252?Q?bMlNERPWZ1NFGGvp/Woe3rPND+eq1tJKdB7fhM5mG56FZKjmMqSiw0EX?=
 =?Windows-1252?Q?r++TH3qmDfWfHAkrCKnmkAi2FuN5B1v3PhYHnXRhLMdaJFshUBhCNmss?=
 =?Windows-1252?Q?QNQbPUSI6RCd5S2gu6hQEoEqeV6plR2bMoJ2EphCg/iskFHbkyxykn3U?=
 =?Windows-1252?Q?7PC78SjSiBWqGXnoxV+fHFmZrFi5RNbAotgN6EBW/0lVXsOyWoTezQ1Z?=
 =?Windows-1252?Q?WtmukMtHlJm4aI6wmt+E90xT+cJSygP5xfswL7F6awLr0drvDTVUJwNZ?=
 =?Windows-1252?Q?KPshM23RJVScn69QjbvLlg6wfOEFULX8lVYYEXZ1p+uSJFHa/3yUvinL?=
 =?Windows-1252?Q?WtA14t7EO3xP0vRLCt/tu6zFBKBrNyLqKAy/86Pfo/4gLWAPrNMENaL9?=
 =?Windows-1252?Q?5HhXou+9GHEq9j+f466gMcp+lNoIljVfw7egQOfkVJ30DmNNQhD+Gx13?=
 =?Windows-1252?Q?eJeZZ7q34aKbeAz3XyEw7O7GE+j8XHlykpTSmJx0+rxcDhmuatAtCEGI?=
 =?Windows-1252?Q?oGM+LZr8Mr4ug4zkkggIjNq2BOoSlp0yiJ+SvoPw7C0biplv775PPvjF?=
 =?Windows-1252?Q?QfFUeXob8oJxnspUB95iuhajtRVnWpQ48J7H6aPIhoYvrFbeWs7BQdun?=
 =?Windows-1252?Q?SGEy2njDnanLUxsl2oh9GkrF+2N3gt9w7uCosoqtIOUNgDZsao1HKTbO?=
 =?Windows-1252?Q?ltgjqy2WJgwLsfB1vXKaLwVFWjfoD6O1PMe2UmNOIS5StMHU66Hs08EQ?=
 =?Windows-1252?Q?1kNpfiPISJnwfnXIPyXlWeBCfHFtHKlHdxm1FYV/r9mk2HfMGoRzyCts?=
 =?Windows-1252?Q?HjwHQoqwrKRQK8F4+pOd4w0U543MLN3Qt7UjhHIpVKhHvFyWTVwoQK7Z?=
 =?Windows-1252?Q?VJLYWVhsCdNwZJ7FBEQhiJ2rCN+PbR6kMkN6QhOcVfHDbEn0yOBCqVfk?=
 =?Windows-1252?Q?Qf+dZAvAysO11w/MmypGBdRfQtXsTEUaiYAUKTwHP6TzzDfmcly1kqvJ?=
 =?Windows-1252?Q?zAa8xe6B8tUzvG770gaNy6mp++7pfQ5Z6PB65v4WKSivzVP9xlitcx6o?=
 =?Windows-1252?Q?my3alxvmd0uZbDx+2jVwrWM7+Sv7e6b2NI3IoqMcFH0e0FJBJAzHSfus?=
 =?Windows-1252?Q?nZH1GDECSJE+XiGA74N4cc9aoQHXgnlDgmX5DjvPHlqIDT8FTpSgfiHc?=
 =?Windows-1252?Q?EGwVcjSJlYmsGvUy69dscQdB4CjsDRtd7doGJ7RXCTRLk/mw5v8X2Cvk?=
 =?Windows-1252?Q?uKxBH2qHxrI0bafRK/pEX4FkEuk/tsf2jOmTfPpGDXsEfklQUUOFA6eA?=
 =?Windows-1252?Q?EZHj9ZLqfQD29MTkz1IYRbASOBkMnWLQJytsxyV0xkOSdcs4n/pmLIMv?=
 =?Windows-1252?Q?yoNJaVp7Hwzp9NjoNIfV8Am1Qj7AOavvllaP9u9Z1sQ4L4B6YqAGMJwH?=
 =?Windows-1252?Q?pc3BRWfpdFZH/bF98AL/L3aktivkCX77rWiV4VFdaNBmOCs0lyxVlIuD?=
 =?Windows-1252?Q?l4vPWAGEK8xY/k6+GMAphkYHaa2NJwUG/hrkm1IsrWSKPAo7GlgXRSd1?=
 =?Windows-1252?Q?aLp9q8dfe2dZshxdeEDByfS50CKmg6BXMCdsNEmU5/PCmSTjM7oSTSVg?=
 =?Windows-1252?Q?39q/czkzMyZKLd9jRfC0k1Hm?=
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(35042699022)(82310400026)(14060799003)(36860700013)(1800799024)(8096899003);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jun 2025 11:45:42.3744
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1b2d4f07-29a7-40f2-2940-08ddb7cba4a4
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com]
X-MS-Exchange-CrossTenant-AuthSource:
	AM3PEPF00009B9D.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR08MB11036

--_000_AS2PR08MB87459E5BFB3D0CF492FF6E47E246AAS2PR08MB8745eurp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Michal,

Thank you very much for the review.

I just had a small clarification regarding the following comment:
>> +
> +    /* Allow index to be NULL */
> +    index =3D index ? index : &_index;
>If index argument is NULL, why bother setting this internal variable _inde=
x?

This assignment is intended to support `index` as an optional output parame=
ter: callers can pass NULL if they only care about the return value. This a=
pproach avoids repeated `if (index)` checks by aliasing to a local dummy va=
riable upfront.
Would you be happy for me to retain this pattern, renaming the dummy variab=
le to make it clearer, e.g.:
```
uint8_t dummy_index;
index =3D index ? index : &dummy_index;
```
I would also update the documentation to clarify that index is optional.

Alternatively, if you=92d prefer to disallow NULL for index and require the=
 caller to always provide a valid pointer, I=92m happy to change it accordi=
ngly.

Many thanks,
Hari

--_000_AS2PR08MB87459E5BFB3D0CF492FF6E47E246AAS2PR08MB8745eurp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable









    

    Hi Michal,
    

     
    

    Thank you very much for the review.
    

     
    

    I just had a small clarification regarding the following comment:
    

    >> +
    

    > +    /* Allow index to be NULL */<=
/p>

    > +    index =3D index ? index : &_index;
    

    

    

    

    >If index argument is NULL, why bother setting this internal var=
iable _index?
    

     
    

    This assignment is intended to support `index` as an optional outpu=
t parameter: callers can pass NULL if they only care about the return value=
. This approach avoids repeated `if
 (index)` checks by aliasing to a local dummy variable upfront.<=
/span>
    

    Would you be happy for me to retain this pattern, renaming the dumm=
y variable to make it clearer, e.g.:
    

    ```
    

    uint8_t dummy_index;
    

    index =3D index ? index : &dummy_index;
    

    ```
    

    I would also update the documentation to clarify that index is opti=
onal.
    

     
    

    Alternatively, if you=92d prefer to disallow NULL for index and req=
uire the caller to always provide a valid pointer, I=92m happy to change it=
 accordingly.
    

     
    

    Many thanks,
    

    Hari
    

    

    

    

    



--_000_AS2PR08MB87459E5BFB3D0CF492FF6E47E246AAS2PR08MB8745eurp_--


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 11:57:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 11:57:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1029087.1402823 (Exim 4.92)
	(envelope-from )
	id 1uWD8N-0003gS-IN; Mon, 30 Jun 2025 11:57:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1029087.1402823; Mon, 30 Jun 2025 11:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uWD8N-0003gL-EN; Mon, 30 Jun 2025 11:57:15 +0000
Received: by outflank-mailman (input) for mailman id 1029087;
 Mon, 30 Jun 2025 11:57: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 1uWD8M-0003gF-MD
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 11:57:14 +0000
Received: from AS8PR04CU009.outbound.protection.outlook.com
 (mail-westeuropeazlp170110003.outbound.protection.outlook.com
 [2a01:111:f403:c201::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5c4cc2a6-55a9-11f0-a312-13f23c93f187;
 Mon, 30 Jun 2025 13:57:13 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by DB9PR03MB9638.eurprd03.prod.outlook.com (2603:10a6:10:458::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8880.25; Mon, 30 Jun
 2025 11:57:10 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%4]) with mapi id 15.20.8880.026; Mon, 30 Jun 2025
 11:57: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: 5c4cc2a6-55a9-11f0-a312-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=mAEHM5P8U4Q+5v8h7eHNJl1xyo3/06ftH0oynuD2fQfew17REJ3f5Dpv3OfPm+tcK8RO99NuF9WkED2b6W95BMgDyN/aSfE133irnHfpYFZYfi9+WTSyJ+CK2SPUVsp+pQ98eP6sTT4rqKieoNIMkoDm7rWjxw2f3j27famQGoghGRn47FnE2xw6oozaxxiIRVAzI7qNwWm/okBO+v+VEd6t9i3LgB/LHHjNVeHmjrjOLcCQso0zKhgoUCvyO/FYjYt6jUI7MEsxKs8CRpsS4T9ciI3C2LOef76HEqK3xhMmIDZPZ33U3WjHNOn/4j4/e2K5nrhZOhnQhvxv/X75HQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=iiXCFbfbSkJXhwT6a/rOMtUdu6laUsAoPsL1b+sE1tE=;
 b=bMtn9/IZqiODbmCD3vbDrG6oQH2gcQMB6o6s3baPuHVpflvqQANPtZFljow8/F8IGh7ar3dEeD65pKvCQRDmCrxb40apOnu03MUISsXPq0sGPrVGF86jVRvJ+hituJ0bb3AhBa7UCl/T0RiPoQQ4udpLexwulOHCecky9sU7Q94k1SY9FQQvFbuBpMIqYuL30mDokccIxRvkys5wNnH3REMVykwqrLCR60A4oSQ+QmCtggEyv97eBOoaYSMtudVTo9a7Vzz74zGGZhfhGolPZ8rF3nrghp0azJxn54oGylfwXPSPTNDnUSqcXQpnA57AfFdPQzdz9y8iWbwwpxoYuw==
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=iiXCFbfbSkJXhwT6a/rOMtUdu6laUsAoPsL1b+sE1tE=;
 b=gZUIJFJhdvZozXHqbsO8p0iqMCX8dPXCnvbHqdnl+Q0u3URDwm4e/GiStiBNa0QnFUsv/Js2ZJdYoPAABqPLRIG2Vn5QE7KXrgFsJVdCrY+Yokx8jKFyAQVCiT/9kFBNq/DxPA/7hru0kOVMFsbpjOHk8cYNBkgN5m4tKigUUE1NYLl101KOmxOvQSe865CepqM7thWiBEkxf1yDXLqXnxLxDMvQffgsHEk/DjXbbs74amf3Hr0rA3ONOAXyVF5cEV9PDHGRk/Gx0yC1sZ0mm+BNHAAKRt1XaW5ArYhwMMTi+WS22Htd1ZTUmjSTKOVyCzkZoGcJ8vrwURd00qkiNA==
From: Oleksii Moisieiev 
To: Julien Grall , Stefano Stabellini 
CC: "xen-devel@lists.xenproject.org" , Andrew
 Cooper , Anthony PERARD
	, Bertrand Marquis , Jan
 Beulich , Juergen Gross , Michal Orzel
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Volodymyr Babchuk ,
	Grygorii Strashko 
Subject: Re: [RFC PATCH v4 8/8] docs: armproposa: l to add separate SCMI node
 for Xen agent
Thread-Topic: [RFC PATCH v4 8/8] docs: armproposa: l to add separate SCMI node
 for Xen agent
Thread-Index:
 AQHb4TVhOpwmaSC7dkC7oLLOKyrberQPvwGAgACpCACAA+mNgIAADJ6AgAX31oCAADB+gIABI0OA
Date: Mon, 30 Jun 2025 11:57:10 +0000
Message-ID: <6689b22a-f85e-40ba-a89b-7935df1bdd28@epam.com>
References: 
 <3f7e1e99f5d1018064f3c4825aff16bd487cf558.1747669845.git.oleksii_moisieiev@epam.com>
 
 
 
 
 
 <3468bb57-3178-460b-8fb2-3ce106475319@xen.org>
 
 
 
 <41566d23-464b-4676-8e01-e2f27d377a94@xen.org>
In-Reply-To: <41566d23-464b-4676-8e01-e2f27d377a94@xen.org>
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: PAVPR03MB8946:EE_|DB9PR03MB9638:EE_
x-ms-office365-filtering-correlation-id: 4873f65e-2721-4ee3-af90-08ddb7cd3eb6
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|366016|1800799024|7416014|376014|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?V1AvRmZyNEZBOWN0TDZGZGZiZ0YyUkw2MTNQNjNkTysySUdrby80S2dPREha?=
 =?utf-8?B?ZHorZ2NDK1BWK1hvNFRqR3M5M3krY1hTczU1SzhZNjk3M2ZLaTU5OUVmdXJY?=
 =?utf-8?B?N3ZQaW9kdHdTYktCK0tteHRmUWMwR1JVTmhBeGxiQkxiVXlYdHZRNHlNWGZm?=
 =?utf-8?B?R0dKd3RMVlVyYlptQ3ljWkpaS00vendJcUliQkU0STloQ3RQTk1XMzZmYWt1?=
 =?utf-8?B?UXhLbFgwQkRPREF4YlFVMm5HMmp1VENUa3F1VkNPZXVCNE1RUEptZDRUbk9m?=
 =?utf-8?B?cWxKbnVQNUpVREVKNmdKektxN1Y0Ym1jcTR0allOanJITGpmdktlb3NWNmpJ?=
 =?utf-8?B?T3RWOGNwbUhKR0hvNkhpT3MvazFTdXNhYWFJWnlVKzhQRmQwTHQwMVNvUWI5?=
 =?utf-8?B?YVYrbERrb2RscENmYVdBZjZFS3AvVWQzSTg3dGpESGs1TnQ5aktRWUlnNmZz?=
 =?utf-8?B?KzJ0dE81aUREbWh4TzdFSFJ6ZTlHVlMrV0NndGNPbEwxYW1oZ0hlTWlIbjVv?=
 =?utf-8?B?SXh6Mks3U0VwdDYramtMSEtJMGxCTVMyc21HcmoyK1JZNkMwd0k3dXNJOGhY?=
 =?utf-8?B?WHN5N1k3Y1VqejBjTVptNUVvZEVRU1lQZkVBUjc4RDdRdmczaWdkcjREWExo?=
 =?utf-8?B?L1M0QisyVWhnOVFEZU5kbmpGbXdDZC9oSGRFZHRwM2phNW9OYlFtakdiM3Q0?=
 =?utf-8?B?S0ZQWm5HT0h2NEFUU0x2OXJxaHpyM0o5L09YMkU3cEhJUEtURHpWUjkrb24v?=
 =?utf-8?B?V0IwazNuTHNlZ2RCRnlSZmMzS2EzdTlPUTJrcG16TDBSZmU1aGlONkZMQk9H?=
 =?utf-8?B?QWZ1ZnBEdVROUWRydURpNUE3cW1hdlpsOUgrVXFoTFJNR2x3K3dSazZuZUdk?=
 =?utf-8?B?NWRnYmJONUNsQXFYa3ZnRUUzdTJRMXNoOUFZKzdrZm04WDhFWUNESk0zVzZB?=
 =?utf-8?B?VldmdWEwSjJiVnFiTFFuNVNya2c3Rjg3TFBsYm1KcG1qdDFvb0FnNHUyeDBS?=
 =?utf-8?B?Q0dzMHZ5SjdDai8yK1J5ajQ0UFNMbUxCQTJsL01IdG94eUljaDEyK3IzSjZK?=
 =?utf-8?B?SmtOVWNHRitaS0RIWlkrN1ZQTHcvV1pmTXhJN0ZrUXRIU3BGTWhzR0cvbmd6?=
 =?utf-8?B?UTNZWDU4YXlpditKSVhkYkE5MVJBdHpNRngrMnJDSlpWZ3pOc2k1MzhLekJS?=
 =?utf-8?B?MkdxclpLMHJSZkxXSWlnY0pBZDZvenI2WWNnTEtzWURzMmw4MkZPVWNjUjA2?=
 =?utf-8?B?UTdKTHVROElZVlNOZDhxU0ZBWWNUN3lMTjRFbStrdXdWTzR2YjJxT0RWVWFF?=
 =?utf-8?B?L3lCQUtMTTdmZDRDb3h1VmREZzRRL3RPZTd4aUdMbzNNWEU0NmNmT2piajNR?=
 =?utf-8?B?ajVNVEV1bWkyM2FlTmhhUTRhQkxxWmt5SjhhSGF4SklnRmZ2cDJTbmc5QVlz?=
 =?utf-8?B?Zzlxdi82VzZPUXRJLzQrNlA4YUZFSXFOQ3hHR05XOEVFSTdLUU9jT1JRWStp?=
 =?utf-8?B?M1BLejIwdlRWZVlReVdEVGdPcTJRYmw5dkI5TnRSMlhwZ2RJaU5uZUN0MHNC?=
 =?utf-8?B?bG1xbURSUGhtTkJaV2JVSzhQMVc0Q00vVmlRSmRVU0dPZmRKN2doNCtMWSsy?=
 =?utf-8?B?VmZSSjdyWkdWOUYrZXdLQVdVaCtvVVVLa2xxRFBRUG1qaFdQa2hYemRqTis0?=
 =?utf-8?B?aDlEOTJSN1EyUDRtT0hrUDNoM244a0l6NHpsZm9iQ1dsVHJiUXNTOEFRYUth?=
 =?utf-8?B?d090ZER3RDVReTBkQklLS2hzVTYyWjFFWGFUN0I4dW1mM0owTFZlRFRoMmky?=
 =?utf-8?B?RHhMQzRMZitjTkszNk1aSU1STEVjYU9vVHc2QTViNVQzcDB2Zi9JbVpUc2E5?=
 =?utf-8?B?NUUrZkg5elBkZk1NdnVRVnorcCsyMW0xNlNFbkY1WTBXZitGMlZrR080YXQ5?=
 =?utf-8?Q?y6SQWNry44k=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(7416014)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?bUxHa2llVmZISERldGZ0L1VtSGFFMGl5OEhIVklNSjIrZkJxeG5uODRtZTFX?=
 =?utf-8?B?U2hXTy9UYzUwT2tDSWg1WVU3OXRYejJqSG5UU0ZWMkxmVUt3SE05d2hub09z?=
 =?utf-8?B?NSsvS0RhYU4zMWUvSk9uUkcraEtjOVlYR2RtdkNFc0hDaGY5NlVPbXV5dGRK?=
 =?utf-8?B?eVVwVitlZzJBTmJ3UXFCM3NFclo0aEdWWThQcUNKc3c1T1N6T0RmeUNzRTEx?=
 =?utf-8?B?eG1zQU9FM2kvbFRrejdpTDdDeTlIWTZVMFIwOERydS94bDBrcGNGUTl0R1JY?=
 =?utf-8?B?aTlpVHQ3ZlZkeDJoVERFL2RTRCtlSDVmRFEwWmFLdjNzQmErampnYktQd0pI?=
 =?utf-8?B?NWNRNTJlYjl3OGNKUFZIUTJXd0lObTNNeVVOcTl2anYxeHlmYmRKNE9OMUx5?=
 =?utf-8?B?YXBsZTJCeTI0RGZmd3VsRXVXbkJZTlQvWmFsaklCTGY4cUtlZkU4UU5jNFBv?=
 =?utf-8?B?NmNnSXVCZzd2blMwMVFiNitCaUZXdW5FVSsxNTRUQ1c1M1JvbWhPeWZrL25Z?=
 =?utf-8?B?QlZWMm81TnNMUkhFd21RRlB0ZDEyT1FCeFBBLzl2eTlLQkFka1pUNDE3eEE1?=
 =?utf-8?B?WjRyTXFueWJWVU40Y3R4ek1pR010YW12SjNIbTI2RGgwOE1DZkxWcUpmU1NU?=
 =?utf-8?B?QlpLZFptWm9pdFNucWxyanIvcXBpR2ltN01yclN3eGdmQWNpSlo5Zi93U2c1?=
 =?utf-8?B?bnMwS1RHd2pMZVhJM3FqU0c5bVJvMkNtbW9BWm9uOUJFM0dBZlBkRGhhYzJ3?=
 =?utf-8?B?TWs4NW5MSi90SzZZR2gvclFLVnJGTjAybWZUbFJNcmlKdVp1dFdqMzJkOUJ6?=
 =?utf-8?B?ZVBnRnpMRFVCNnAxQ0dJS2p3RlBkU2ZZRGpnOTIxa3FmY29sVmgvdXBsOGJq?=
 =?utf-8?B?bC81cUhRMHNYM28waWZTanpJNEMySm5SelhQSnJuU2hmRDZ3bFVJQ21tS1FQ?=
 =?utf-8?B?NlZncGlEVHlSY3BZVmRMakRROG8vNTE1MG44TW5pc01BZFgrMzRuRU9aRk5q?=
 =?utf-8?B?eTZvM1NYV3RQdHpreEsxVGppUlhmVTVtOG9yNFJodTNBZU1TWnJXODZ3YzRS?=
 =?utf-8?B?bmZnOWZ4MjNKaFYrM3ppcjhFSUpjaG5TUXUrMWJwTDRlUzI1T2xkRTU4a3hw?=
 =?utf-8?B?ZGdWem9PMytyTkZQaUgwQ0hLZmJSN09hRWNwOHp6dXZOeXdIZUFlTDZOY2Ra?=
 =?utf-8?B?amVIL3JiZzJqZ2VPcWllY0NDTCt6VEhjRVBNRHNwZ1RZOThyVktPdTlIWWlt?=
 =?utf-8?B?SVB4cWU0TS84NkFqaTVvVUtBM2U4WVB2NEV2WVFVbG1udVlXdkZSOUcwSStV?=
 =?utf-8?B?MGMyTkFRZDdJYlJkWXNkOTlBZ0RkS2lIWkQ4MmpWU2RaM2hZZ3lmdGJBMnFj?=
 =?utf-8?B?V24zYVIxVDdBeTZ2em5TN3AzR1V6VEI5cXdNeHJHOFgwTUJxanNBRC83YVJj?=
 =?utf-8?B?ajVrTlZDbE1tdmJ5V3F4d3k2aGVtQXJtOFdGalphTGU2VmhtRWU4VHh3b1E1?=
 =?utf-8?B?NGpqZmY5OWJOc2hrU2c2N1RxcGN5bjgwN1l6UXphNVhiV1hSZmg4VmdoUUVI?=
 =?utf-8?B?VmgrZFp0dWd3VlMrWS9sZWpLT1ZqTzJ6ODlHT3dZU3U5bExzZmZVUGRET2Vu?=
 =?utf-8?B?MjRlN2F1OTJUaWdFVjdCZXpsMWV3ckZDZExjcmp4ZjFuZEtNSWlabHRkaVp2?=
 =?utf-8?B?d2V2UFhwVjZLUG5YTUk3SUxwNithMzdyb2NwNThBWFZ3eVhNRFAzU2FrQlNC?=
 =?utf-8?B?NEd2L01Pc2RTeHZ0a0gxQXE5cVJxT0JNQUdQR0RIcFE4RXp5K25VTGtLK1da?=
 =?utf-8?B?QXQ4endPdHlDY3FhQlFIdW9lUTY4cHN1Qkk3VWJIcDEzZ2VYek9qQmY1anB1?=
 =?utf-8?B?L2NoTURWK3R3VElxQmNOWUNuTENvbk9PSDJJYkc2NE9pbUQ4YnMvcTR1ZEFI?=
 =?utf-8?B?MC9IWE81bFhWclBuSGoxQ2dQR3dONFZjMVFDMUxhVUphMEtRWUJxOTNBK1JL?=
 =?utf-8?B?RWNPK2dXNWpWTUo1Wjh2K01TM3VWaWRja2VSYnp2QUJEdFA3MmRoSXlYaGlG?=
 =?utf-8?B?WVZSOCtHR29TS25RcEt6aU9FNmZUajdmYWhzVDhDT0NIVEFWYSs0ZG9uZ2tP?=
 =?utf-8?B?MGluQjdLU0VZSEk5WTdwZ3RaVVo4azVvcXpENU0wSGoyTjR5WUE1L3p5MnFJ?=
 =?utf-8?B?RXc9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <0D2B4D78E79E5A4C84591F027A25C1AD@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: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4873f65e-2721-4ee3-af90-08ddb7cd3eb6
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2025 11:57:10.4460
 (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: AqF5HHSRCjcP65BoVW2NdajSY1LJObOcK3KXdxAWqMuQuJ6CV9uhOB37PtVRWWAy1aqkv/5d+l/+heM7yjX5JvGd/rRohuSQUojLwzZKOVA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR03MB9638

DQoNCk9uIDI5LzA2LzIwMjUgMjE6MzQsIEp1bGllbiBHcmFsbCB3cm90ZToNCj4gSGkgT2xla3Np
aSwNCj4NCj4gT24gMjkvMDYvMjAyNSAxNjo0MSwgT2xla3NpaSBNb2lzaWVpZXYgd3JvdGU6DQo+
ID4gLS0tPg0KPj4gSW4gdGhlIFZpcnR1YWxpemVkIHN5c3RlbToNCj4NCj4gVGhhbmtzIGZvciB0
aGUgbG9uZyBleHBsYW5hdGlvbi4gSW4gdGhpcyBzZWN0aW9uLCB5b3UgbWVudGlvbiBYZW4gYWxs
IA0KPiBvdmVyIHRoZSBwbGFjZS4gQnV0IGFzIHlvdSBwcmV2aW91c2x5IGFncmVlZCB0aGUgbXVs
dGktYWdlbnQgU0NNSSBpcyANCj4gbm90IFhlbiBzcGVjaWZpYy4gVG8gcHV0IGl0IGRpZmZlcmVu
dGx5LCBhc2lkZSB0aGUgZmFjdC4uLg0KPg0KPj4NCj4gPiAtIFRoZSBYZW4gaXMgcmVhbCBPU1BN
IHdoaWNoIG1hbmFnZXMgb3RoZXIgVmlydHVhbCBPU1BNIGFuZCBpdCANCj4gbmVlZHM+IGRlZGlj
YXRlZCBTQ01JIG1hbmFnZW1lbnQgY2hhbm5lbCB0aHJvdWdoIHdoaWNoDQo+PiDCoMKgIGl0IGNh
biBwZXJmb3JtIEhXIHJlc291cmNlcyBhc3NpZ25tZW50IGZvciBWaXJ0dWFsIE9TUE0gYnkNCj4+
IGNvbW11bmljYXRpbmcgd2l0aCBFTDIgU0NNSSBGVw0KPj4gwqDCoCBkdXJpbmcgVmlydHVhbCBP
U1BNIGNyZWF0aW9uIG9yIHJlbGVhc2UgSFcgcmVzb3VyY2VzIGR1cmluZyBWaXJ0dWFsDQo+PiBP
U1BNIGRlc3RydWN0aW9uLg0KPj4gwqDCoCBJbiB0aGUgZnV0dXJlIGl0IGFsc28gcG9zc2libGUg
dG8gZW5hYmxlIHN1Y2ggUE0gZmVhdHVyZSBhcyBTQ01JIA0KPj4gYmFzZWQNCj4+IENwdUZyZXEg
aW4gWGVuLg0KPj4NCj4+IMKgwqAgVGhlIFNDTUkgRFQgYmluZGluZyBmb3IgWGVuIFNDTUkgQWdl
bnQgZXhwZWN0ZWQgdG8gYmUgZXhhY3RseSB0aGUgDQo+PiBzYW1lDQo+PiBhcyBmb3IgYW55IE9T
UE0gKGxpa2UgTGludXgpIGFzIGZyb20NCj4+IMKgwqAgU0NNSSBGVyBwb2ludCBvZiBmZXcgaXQg
aXMganVzdCBPUyBydW5uaW5nIG9uIEFwcGxpY2F0aW9uIENvcmUgKHdoaWNoDQo+PiBzdWJzdGl0
dXRlcyByZWd1bGFyIE9TIC0gTGludXgsIFJUT1MpLg0KPj4gwqDCoCBTbyBubyBuZXcgU0NNSSBz
cGVjaWZpYyBiaW5kaW5ncyAoaW5jbHVkaW5nIGNvbXBhdGliaWxpdGllcykNCj4+IGludHJvZHVj
ZWQgbmVpdGhlciBpbiB0aGlzIHNlcmllcyBub3IgaW4gdGhpcyBwcm9wb3NhbC4NCj4+DQo+PiDC
oMKgIEluIG90aGVyIHdvcmRzLCBYZW4gbmVlZHMgdHdvIERUIHRvIGJvb3QsIGtpbmRhOg0KPj4g
wqDCoCAtIFhlbiBEVCAod2l0aCBib290aW5mbywgQXBwbGljYXRpb24gQ29yZSBpbmZvLCB1YXJ0
KQ0KPj4gwqDCoCAtIEhvc3QgUGxhdGZvcm0gRFQgKHNvdXJjZSBpbmZvcm1hdGlvbiB0byBjcmVh
dGUgZG9tYWlucykNCj4+IMKgwqDCoCBhbmQgaWYgdGhlcmUgd291bGQgYmUgdHdvIHNlcGFyYXRl
IERUcyAtIGVhY2ggd2lsbCBoYXZlIG93biBzdGFuZGFyZA0KPj4gKGJpbmRpbmdzKSBEVCBTQ01J
IG5vZGUuDQo+PiBBY2NvcmRpbmcgdG8gdGhlIGN1cnJlbnQgZGVzaWduIFhlbiBhY2NlcHRzIERU
IHdoaWNoIGlzIEhvc3QgUGxhdGZvcm0gRFQNCj4+IHdpdGggYWRkZWQgWGVuIGNvbmZpZ3VyYXRp
b24gc28gWGVuIFNDTUkgaW5mbyBpcyBhZGRlZCBpbiBYZW4NCj4+IGNvbmZpZ3VyYXRpb24gbm9k
ZSB1bmRlciAvY2hvc2VuLCBhbmQgbm8gRG9tYWlucyBpcyBleHBlY3RlZCB0byBzZWUgaXQNCj4+
IGV2ZXIuIEFmdGVyIFhlbiBpbml0aWFsaXphdGlvbiBEVCBub2RlcyBmcm9tIFhlbiBEVCBhcmUg
Y29waWVkIHRvIHRoZQ0KPj4gRG9tMCBkZXZpY2UgdHJlZS4gT3VyIHByb3Bvc2FsIGlzIHRvIGtl
ZXAgU0NNSSBjb25maWd1cmF0aW9uIGZyb20NCj4+IFBsYXRmb3JtIEhvc3QgRFQgdGhlwqAgc2Ft
ZSBzbyBpdCB3aWxsIGJlIGNvcGllZCB0byB0aGUgRG9tMCBkZXZpY2UgdHJlZS4NCj4+DQo+Pg0K
Pj4gLSB0aGUgbnVtYmVyIG9mIFZpcnR1YWwgTWFjaGluZXMgb3IgVmlydHVhbCBPU1BNcyAoaW4g
dGVybXMgb2YgU0NNSSkNCj4+IGRlcGVuZHMgb24gaHlwZXJ2aXNvciAoWGVuKSBjb25maWd1cmF0
aW9uLg0KPj4gwqDCoCBBbmQgVmlydHVhbCBPU1BNIGlzIGRlZmluZWQgYXMgVk0gd2hpY2ggaGFz
IGRpcmVjdCBhY2Nlc3MgdG8gSFcNCj4+IChwYXNzdGhyb3VnaCksIHNvIG5lZWQgYWNjZXNzDQo+
PiDCoMKgIFNDTUkgc2VydmljZXMgdG8gZ2V0IGZpbmUtZ3JhaW5lZCBhbmQgc2FmZSBhY2Nlc3Mg
dG8gcmVxdWlyZWQgDQo+PiBQbGF0Zm9ybQ0KPj4gSFcgcmVzb3VyY2VzLCBhbmQgYXZvaWQgaW50
ZXJmZXJlbmNlLg0KPj4NCj4+IMKgwqAgRXZlcnkgVmlydHVhbCBPU1BNIGlzIFNDTUkgYWdlbnQs
IHdoaWNoIHNlZXMgaXQncyBvd24gU0NNSSB0cmFuc3BvcnQsDQo+PiBhbmQgZG9lc24ndCBrbm93
IGFib3V0IG90aGVyIGFnZW50cy4NCj4+IMKgwqAgSW4gdGhlIGNhc2Ugb2YgRFQgLSB0aGUgc3Rh
bmRhcmQgU0NNSSBiaW5kaW5ncyBhcmUgdXNlZC4NCj4+DQo+PiAtIFNvIHRoZSBYZW4gaXMgdGhl
IG9ubHkgZW50aXR5IGluIHRoZSBwbGF0Zm9ybSB3aGljaCBuZWVkIHRvIGtub3cgYWJvdXQNCj4+
IG90aGVyIEFnZW50cy4NCj4+IMKgwqDCoCBUaGVyZWZvcmUsIHRoaXMgWGVuIHNwZWNpZmljIGNv
bmZpZ3VyYXRpb24gDQo+PiAieGVuLHNjbWktc2Vjb25kYXJ5LWFnZW50cyIsDQo+PiDCoMKgwqAg
Zm9yIHRoZSBjYXNlIG9mIHRoZSBFTDIgU0NNSSBGVywgaXMgaW50cm9kdWNlZCBhbmQgYWRkZWQg
dW5kZXIgdGhlDQo+PiAvY2hvc2VuIG5vZGUgKG9yIHhlbi1jb25maWcpLg0KPj4gwqDCoMKgIFVu
Zm9ydHVuYXRlbHksIHRoZXJlIGlzIG5vIHdheSB0byBkaXNjb3ZlciBBZ2VudCdzIGNvbmZpZ3Vy
YXRpb25zDQo+PiB1c2luZyBTQ01JIHByb3RvY29sIChiYXNlKSwgbGlrZSAiZnVuYy1pZCINCj4+
IMKgwqDCoCBhbmQgc2htZW0gcGFyYW1ldGVyIChvbmx5IGNhbiBnZXQgTnVtYmVyIG9mIEFnZW50
cywgYW5kIGRpc2NvdmVyIG93bg0KPj4gQWdlbnQgaWQpLCBzbyBvbmx5IG9wdGlvbiBpcyB0bw0K
Pj4gwqDCoMKgIGRlZmluZSB0aGlzIGluZm8gaW4gRFQgZm9yIFhlbi4gSG93ZXZlciwgWGVuIGNh
biB1c2Ugc2hhcmVkIG1lbW9yeQ0KPj4gcmVnaW9ucyBhbmQgZnVuY19pZHMgb2YgdGhlIG90aGVy
IEFnZW50cyB0b8KgwqAgZGV0ZXJtaW5lIGFnZW50X2lkIHVzaW5nDQo+PiBiYXNlIHByb3RvY29s
LiBUaGF0J3Mgd2h5IGl0IHdhcyBkZWNpZGVkIHRvIG1ha2UgYWdlbnRfaWQgaW4NCj4+ICJ4ZW0s
c2NtaS1zZWNvbmRhcnktYWdlbnRzIiBvcHRpb25hbC4NCj4NCj4NCj4gLi4uIHRoZSBuYW1lIG9m
IHRoaXMgcHJvcGVydHkgY29udGFpbnMgInhlbiIsIEkgc3RpbGwgZG9uJ3QgdW5kZXJzdGFuZCAN
Cj4gd2h5IHRoZSBiaW5kaW5nIGNvdWxkIG5vdCBiZSB1c2VkIGJ5IG90aGVyIGh5cGVydmlzb3Jz
LiBJT1csIHdoYXQgaWYgDQo+IGFib3ZlIHlvdSBzL3hlbi9LVk0vIChvciBhbnkgb3RoZXIgaHlw
ZXJ2aXNvciB5b3UgY29tZSB1cCB3aXRoKT8gQXJlIA0KPiB0aGV5IGFsbCBnb2luZyB0byBjcmVh
dGUgdGhlaXIgb3duIGJpbmRpbmdzPyBJIHdvdWxkIGd1ZXNzIG5vdCBnaXZlbiANCj4gdGhlIHNp
bmdsZSBhZ2VudCBpcyBhbHJlYWR5IGdlbmVyaWMgKGlmIEkgYW0gbm90IG1pc3Rha2VuLCBib3Ro
IExpbnV4IA0KPiBhbmQgWGVuIGFyZSB1c2luZyBpdCkNCj4NCktWTSBbMV0gaXMgbm90IGFwcGxp
Y2FibGUgaGVyZSBhcyBpdCBzdGFydHMgdW5kZXIvaW5zaWRlIExpbnV4LCBzbyBpdCANCmRvZXNu
J3QgaGF2ZSBkaXJlY3QgYWNjZXNzIHRvIFNDTUksIHRoZSBMaW51eCBkb2VzLg0KQW5kIExpbnV4
IHdpbGwgc2VlIG9ubHkgb25lIFNDTUkgdHJhbnNwb3J0IChBZ2VudCkuDQpTZWVtcywgdGhlIG9u
bHkgb3B0aW9uIHBvc3NpYmxlIGlzIHZpcnRpby1zY21pIChxZW11KSAtIHRoZSB2aXJ0aW8tc2Nt
aSANCnBvdGVudGlhbGx5IGNhbiBzaW11bGF0ZSBtdWx0aS1jaGFubmVsLA0KYnV0IHRoaXMgaXMg
b3V0IGlmIHNjb3BlIG9mIHRoaXMgd29yay4NCg0KUU5YIFswXSByZWxpZXMgb24gY29uZmlndXJh
dGlvbiBmaWxlcyByYXRoZXIgdGhhbiB0aGUgRGV2aWNlIFRyZWUuDQoNClswXSANCmh0dHBzOi8v
d3d3LnFueC5jb20vZGV2ZWxvcGVycy9kb2NzLzguMC9jb20ucW54LmRvYy5oeXBlcnZpc29yLnVz
ZXIvdG9waWMvY29uZmlnL2h5cC5odG1sDQpbMV0gDQpodHRwczovL3RydWVjb25mLmNvbS9ibG9n
L2tub3dsZWRnZS1iYXNlL2NvbmZpZ3VyZS1rdm0taHlwZXJ2aXNvci11YnVudHUtc2VydmVyI0tW
TV9jb25maWd1cmF0aW9uDQoNCj4gSSB3aWxsIG5vdCBpbnNpc3Qgb24gbW92aW5nIHRoZSBiaW5k
aW5nIG91dHNpZGUgb2YgL2Nob3NlbiBpZiB0aGUgDQo+IG90aGVyIG1haW50YWluZXJzIHRoaW5r
IHRoaXMgaXMgdGhlIGJlc3QuIEJ1dCBJIHRoaW5rIHRoaXMgaXMgDQo+IHNob3J0c2lnaHRlZCB0
byBhZGQgInhlbiIgaW4gYWxsIHRoZSBuYW1lIG9yIHB1dCBpdCBpbiBhIFhlbiBzcGVjaWZpYyAN
Cj4gcG9zaXRpb24uDQo+DQo+IFVsdGltYXRlbHkgd2hhdCBJIHdhbnQgdG8gYXZvaWQgaXMgd2Ug
aGF2ZSB0byBzdXBwb3J0IG11bHRpcGxlIA0KPiBiaW5kaW5ncyBpbiBYZW4gYmVjYXVzZSBzb21l
b25lIGVsc2UgZGVjaWRlZCB0byBjcmVhdGUgYSBuZXcgYmluZGluZyANCj4gYXMgd2UgZGlkbid0
IGV2ZW4gYXR0ZW1wdCB0byBtYWtlIG91cnMgZ2VuZXJpYy4uLg0KPg0KDQpOb3QgYXdhcmUgb2Yg
YW55IHNpbWlsYXIgdGFzayBkb25lIG9yIGluIHByb2dyZXNzLg0KPiBDaGVlcnMsDQo+DQo=


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 12:10:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 12:10:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1029101.1402834 (Exim 4.92)
	(envelope-from )
	id 1uWDLD-0006Sv-Py; Mon, 30 Jun 2025 12:10:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1029101.1402834; Mon, 30 Jun 2025 12: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 1uWDLD-0006So-MG; Mon, 30 Jun 2025 12:10:31 +0000
Received: by outflank-mailman (input) for mailman id 1029101;
 Mon, 30 Jun 2025 12:10: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 1uWDLC-0006Si-0W
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 12:10:30 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20619.outbound.protection.outlook.com
 [2a01:111:f403:200a::619])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 347309b0-55ab-11f0-b894-0df219b8e170;
 Mon, 30 Jun 2025 14:10:27 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by DS5PPFF2923D4C1.namprd12.prod.outlook.com (2603:10b6:f:fc00::669)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.28; Mon, 30 Jun
 2025 12:10:23 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8857.026; Mon, 30 Jun 2025
 12:10: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: 347309b0-55ab-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=O+iMugCrjj/4pIzva11912GB3RgRgI3eWR1k7BQmmc8g4gvHHk2lx2EWUB9z61mceON7yX0h+9kRgmbmbbPdze/qhpP7KauJS+4akvxDuEx7wLAZOKws2lzY4dllSDZcCyYAIYS8H/gmv1Vn8O+Ny7ULNWqZMY6BdXjljL6gf0YSZflVUVo8uj04L1uKPA4b7HDhpj473PvtUP5Ew/LN3g5DYRJvN4VgltMhuFbSYUhL9ocQsF+T0cRyMCXaKXHasnGdC9Tkk0Li44vcRnPmV4RoKhMnJse4EqiLQDREGYCY2ZTc/dNJZDFRHkke0jEVuAnC6I9/7C2eLnxUTpwaqQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=IlzqaeUyAWy5W3cUW9IzyPn7WSKQaGXp3YwzvABgZjE=;
 b=DslfOJ2LdwD8AUC/hxK76uRH3maBUFtycCY0Ik2At5cpPtkERHykG/xhMAX2w9qmNsfVibRx9uQCK/afrMyx6T4sTtv04VFjbvzbpbMfm+SoDscSpKwlwPRGzegDlbKNwUI0pG1vRmuJjjMW3gAc0b/UtqKb0UEgIzKdCfVfNGyfp/GYjlTcJ5zM1JiAjaFFrqgQWDBqsdFJAbtQt83XnwBZdfH2G8vbZVmpi+Osbmhr9xiLYg+R1hDfTuWxfmA0U0aanoLgBxp/uNUUFbndvObxTLdcSK8pFmybaA3qRhfQMSlZ7WrfAZXusgj/XzRmdmKWXk1FBwe0z4ctjXxxFA==
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=IlzqaeUyAWy5W3cUW9IzyPn7WSKQaGXp3YwzvABgZjE=;
 b=HxdI2gwb0zmPo+o4pQh/4N/hc7y8aqrNSMjW2SpphnJaFNjmob+ZwxKGKly7nI+lslw23AIqTmvwquauAvgn5Xj1NjSS5PJFLcYjZRFsn/8raBx0jltxisskCGOzKNcATijL6QXUw/R5hdyFGDHnT8VJb/qn5Te8YiRKXd4a/Ro=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Mon, 30 Jun 2025 14:10:18 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/6] arm/mpu: Find MPU region by range
To: Hari Limaye ,
 "xen-devel@lists.xenproject.org" 
Cc: Luca Fancellu ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: 
 
 
 
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: FR4P281CA0216.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:e4::20) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|DS5PPFF2923D4C1:EE_
X-MS-Office365-Filtering-Correlation-Id: f3db176c-3915-40dc-3bc4-08ddb7cf16c4
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?VU1sbFp3L0dUbDNIcG05Nm5rc1VKUjVkT21IMkhVdTYwVXNGdUZ3VXg5enFT?=
 =?utf-8?B?SjdMT3dkdWRReFUrNE5QakVxUVl6SFdVa3dDa3poNkt4UkhsZWU4NHozK0pn?=
 =?utf-8?B?WkF4ZDV4RFl4aFgvVS9pSjYvRDdPUEJ0aWhWWmtSRlpXYlpqb09FMWRKMW9J?=
 =?utf-8?B?VFZpYmpEbzhLS0NoSUwvNUE3aHZ6SGNvUXlPcXFZRlB5QTRnNitoZmNYSFJy?=
 =?utf-8?B?bWQ0b0Y2OG1mVi9BRUFIaUFKRDhzcHVoVzR1UE4zVGxPSEdpNVJOLzMxRFdL?=
 =?utf-8?B?TWp0MlRiTkNac090cUxaZzFyTUppdWVTcEJJd1pmV2hKSzQyV3NDR2FpcGNv?=
 =?utf-8?B?Q2xkK3VyL1g5ZkVkMmhBT1N0c0pYWUhFMkVoVVBXVnFJUjhueWRkbEJ3TlRN?=
 =?utf-8?B?U010Wjh6dTRZb2RRVDBYSWdvKzVCZFFyZGVpTTJzYVVQSGRKdmpLaWdpQWpt?=
 =?utf-8?B?TUg1KzdRODV1cXk2UHRIcUFWeTlGc2VqQTM2bXUyYXpKUUlJNzdPMDAxRmI1?=
 =?utf-8?B?VkFNbFNuRFJBVS9wSnJPVEVsdnBCc3VPRDlMVHo2STVOREZmd1ZXQkg2dSth?=
 =?utf-8?B?VWhTRE5ZVTRlMHpiRHQ5NXNvUDVlQTJIdnBPcWNEU3hGVGpsZFBCTDROeFMw?=
 =?utf-8?B?OHlPYmxnUlJ4SlVIYlhHMytaTU5IcjhJZnNrck5zZFVUZXZrSTd6NFgzMnV5?=
 =?utf-8?B?ekdNazYzUDU4d1hSNTkraUVOSVB4b3BWMFgwbzRwZDdjRXMvbnh4U1VaWHFW?=
 =?utf-8?B?b21BSW1MNTFpV0lmRHd5dzd5Zm81RytFQ3V4bmZZeVNjamxzQTZKaUM4Ukln?=
 =?utf-8?B?MWlRZjNtOVJhMVk1dXA4eUN2Z3NpbWJ1alFNaFNpV000OHlNS2pTY28yWkhx?=
 =?utf-8?B?aXNlT3lZNFc5UjBQY0FxSW9HRVQ0dkYwM0ZzWURWVlJVa3U1MjVQckpsWmxX?=
 =?utf-8?B?US8rcG9oRlR3YlFPc0R4LzlKeDJza09BWERab0J6MXM2UDY1U0hkU05BQndH?=
 =?utf-8?B?cDZWZ2ZhcHNhSkd0a0hEeWxESG9zOENhNFl1N0lCK3psV0FzdkZQWWY4ZXBI?=
 =?utf-8?B?TGtIT08vVmNoM3ZlNWlwZTZ5bGc0NVRHVDJsY1JSd2VSbW04WXZsSEpxWkFk?=
 =?utf-8?B?QTYvY24wUERTTm1YeVZuYmhVSVZ2Y0tHMCs0aVFBdDVid3pZMTVtb1FsQUxJ?=
 =?utf-8?B?eWJtRFY1c2lsV01VZnhkVC9RVC9KdFkvUjltOEg0b3dLeEZ0a0wwU2NtQ0t5?=
 =?utf-8?B?VVNINzNsdkRuajlYTHV5Yjg2c1gvVjBNdHZETWozRWxqU3o2KzVESHdsTmlN?=
 =?utf-8?B?T2pCVmQzQnNjSjVVSzZwLzlRd2xCUlJLWUV0TkxrN1djWW5vTVBUcnREK3hn?=
 =?utf-8?B?WnFmZXVCbVdUZndtbG56ejl6NzJ1blgvQkNxeDRIUm9FcHhuaWkwTjRXc1Jl?=
 =?utf-8?B?eURxZUFaU1FSR1NsSE82K2k5Nm56SzdVT2llYk9yamFqTTVYQkcwa0l4Z0hi?=
 =?utf-8?B?dVd6TlhyMm43MWZobVZxQTNOQUF1LzlML25VYjA2cVpBM2w5cm5zS3ZkMGp2?=
 =?utf-8?B?eVZUdnp2akg4MGFDYU03STdQclIxWENJSE4xRnFXYThReE1wSnRscXR3Zzly?=
 =?utf-8?B?VFNmRmo3L1diVURkQlVSY3lyRjY5akE1YkJOOGJCR2w1dUJwckNMbUNzdWZL?=
 =?utf-8?B?OTJtR0RuUUdUbFBvUmozN0x6REIyL2JTcDRpNjRUbk1EMjZDVWdJSFhPLzMv?=
 =?utf-8?B?Q3lGa25ObFNOcXk2eUlsa2hKcENFa1B0WSttWnNmYy9PNUVkVzBTZ0x4ZEtx?=
 =?utf-8?B?eVZFdFY1VnVpa3M5clYzMHFZbGJsWDJjTXIwZHNLOTRKM0NqaTNVejdURVdt?=
 =?utf-8?B?azFuL2EveS90QU5ESStPWmZrQk1KMzA0QU9qckVtaVgyVXgyUlBCNWQwSk5l?=
 =?utf-8?Q?aSRudZG8y5Y=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.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?VVU1QVZOdFNXTVpPVkhVRkNYNUdsVG1jVlBHVEc0aG1jTVJwdWI1c3RGMmt1?=
 =?utf-8?B?N0ZlWE9hMnd3V28zREdENmkzVW5oRHFxWjBBdVlzL1NVMW5rZjdlWlR6TDRE?=
 =?utf-8?B?RmlPUjRndmY2eU1MRWw1NXNsenJ6dmlUZDVMY3NoNHdzMmlaU2xNOVBKQlhQ?=
 =?utf-8?B?Uk5DQmNoVGJETmVpZjMwN1BmTWlLbDM4VjFZWnJSQitSZTloU2VzSS9UdjhO?=
 =?utf-8?B?YWhzSTNPekNZdk5Fc0luRHVwSkZWa29rNmxXWDdiYjM1bm5tc3JuUGN5cTZ2?=
 =?utf-8?B?VldPdDJvUVh0elBpRnJRZFY1V3BmbFIrV1VqN0h3NGIxcTU4SHBMeDVWQmNq?=
 =?utf-8?B?aHZXYVhidVd3TTJBT0J5TEVxaDM4VWJURWJTSlBQVUNyTHc5elFSN0hiQVF6?=
 =?utf-8?B?bjFBWjM3NnY1cW1qU2VlcjhYZ0czMkZkR0hvbTJ5d1RiczFkQnYyeFFieWVR?=
 =?utf-8?B?QXNORTZRSzVUMXRJRDFmaTBmMTNBeUl2dTgrWEJ4amJDUzArSkw3Ympram44?=
 =?utf-8?B?bkM2RDg2MHdNR0Vpb1ZMbCsyNHIyQ3JlQ1BxVkU1enV4SlM0MTRhL2o2anRW?=
 =?utf-8?B?bmNLamlqYS9LQ0o0WEVpMVBqVEtwSFFIMHpRUDZPVDE1R1dxY1QrRDd6MnZ4?=
 =?utf-8?B?T3diUVhMWVNYeGRxWFhFNWVBbmo0bnVqL1h3a0QvTWUyYjN5SzY0bCt1eWhr?=
 =?utf-8?B?VkhyZlQ1VWcrd0cwN0lqYnQ0NHk3dm9LSUdlNTNRcEtjNUtrUGFpYTNlc29n?=
 =?utf-8?B?NW4yemt0eVFpRmJYaytMTld2Vng0TkYrK0lkRjIvcDI5bTA2QUQ4SllUczM4?=
 =?utf-8?B?bDJOcTd4UnljcWpXRzFHN1ZQc0ZyUThWUXo5S1VHUERGdGdSL3lTbEZISGo3?=
 =?utf-8?B?c0pBUUpaYUxuaHJtQ0ZHRXJuQk9kbXdVNlZDK3ZCYkV0MDRrdnFNT2tmZ3Bp?=
 =?utf-8?B?NnlvTGlKZGRsU1laTzlrYzNNcU9ocGFEOS9LbWMrVlkyeGN5aWc3aHgyZTdp?=
 =?utf-8?B?aXFWU0MvTjlhb3hmUk9rOElmS1Z2c0paV3pQVW16TlZqRUt4b0VNeCtlcGUw?=
 =?utf-8?B?clg2eXBxSUlTMlNrWVF6TElWbmIwVGtwdVlYaUVJODNYT0pWR0lXbG81Ymc5?=
 =?utf-8?B?cGlZN1JSbW1SZzY1MEN5M3o4eHArdXdvRXpYMFZacEJDdVk4R3hHM2tKTWo1?=
 =?utf-8?B?TUVmZVlyZEpYY2NNbFZnSFo2Z1NIam16T2ZmVFhoSEJvd1Y5bkVpVUx1RHVu?=
 =?utf-8?B?dmRwaTBDQ1QzRWZ0TUk4enJMc0dwU2JyaUJWck5QR3JxenpNM0JLdUFkS0lt?=
 =?utf-8?B?Q09JWUtNWjJVeGg3eTQ2V2JhcHBBdjVQRW02VWxwUm0vd1JnZzJ3MGphUXZ3?=
 =?utf-8?B?eW82bUpsQVkxeXZJUnJDU3dTRTEvWlM4MVJidTh0L0wwNmZGTENRM2NHVUJr?=
 =?utf-8?B?d1k1VDhTaURJNkdzYmJ2WlJnenFlUzlzTVR4YngvaGhsaGl4dFJzb3Z0dkVa?=
 =?utf-8?B?T1NoR1NOMTk2b1g4dEMrdFZzeVdjcjdZL1VmUG9RY1IrTitTMGgyTW94cGFp?=
 =?utf-8?B?Q1F6TzY4TEFHMmRmTzF1eVFWRi9tckJQRnlVdlRPNzJXNDFETi9OMnJ2bldh?=
 =?utf-8?B?RXVNeVFicXlBUjhjcWZlN1VQUFVhKzFnbjFLcGxyTVRwV3E3OHlNVEFmSzRn?=
 =?utf-8?B?aWxuT0FhaVhoVzBLNWQxNXpZeWRWZGdVaWlVaWtVdGhYbTlDdW1kTHZEWnlh?=
 =?utf-8?B?K3hPNkdJK1BqMytlTVRlTnJMQUhydlg4bURPNGZHRGY1eVRVTWpvTndIaE1l?=
 =?utf-8?B?OTY4Um5NcWhlTm52c0dmdjZXcnlpc0p1TS9nMnJtbitPRVlxZ1FNRGdYSXY0?=
 =?utf-8?B?Q25qMWJLT09sZUMwNjlEbmUrZTBJM1ZURDNKNk9qSm4xSW0rT2MwSEI2cTRP?=
 =?utf-8?B?RExsODRPd0JibVJVVFBkS1YrdkpsSUREYTlBOUVmMUNtTTV1aU51dytsRjJZ?=
 =?utf-8?B?elF6aElvejdCaHBnYlR2WEtXT2cvUkhjaEpKUk8rNHc4Um5uV3o1aXJxM2pu?=
 =?utf-8?B?TVhWaDlJVUpsL2R5dzB0MUg4N2lIdFhkdVRHMVFTMW1wYnBzeVZZQ29uUFhz?=
 =?utf-8?Q?dE8o=3D?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f3db176c-3915-40dc-3bc4-08ddb7cf16c4
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jun 2025 12:10:22.6058
 (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: 9RPOh2iC9MSSKkE50buv9kYcdILngSpKO60LzXwqVmhl53F1hyNGrCrTp0QxZTQu
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS5PPFF2923D4C1



On 30/06/2025 13:45, Hari Limaye wrote:
> Hi Michal,
> 
>  
> 
> Thank you very much for the review.
> 
>  
> 
> I just had a small clarification regarding the following comment:
> 
>>> +
> 
>> +    /* Allow index to be NULL */
> 
>> +    index = index ? index : &_index;
> 
>>If index argument is NULL, why bother setting this internal variable _index?
> 
>  
> 
> This assignment is intended to support `index` as an optional output parameter:
> callers can pass NULL if they only care about the return value. This approach
> avoids repeated `if (index)` checks by aliasing to a local dummy variable upfront.
You don't need multiple if ( index ). Just one at the end of a function by
modifying it to use goto e.g.:

rc = ;
goto out;

 out:
 if ( index )
	*index = i;

> 
> Would you be happy for me to retain this pattern, renaming the dummy variable to
> make it clearer, e.g.:
> 
> ```
> 
> uint8_t dummy_index;
> 
> index = index ? index : &dummy_index;
> 
> ```
> 
> I would also update the documentation to clarify that index is optional.
This does not address my point about having and setting a variable that may not
be used.
> 
>  
> 
> Alternatively, if you’d prefer to disallow NULL for index and require the caller
> to always provide a valid pointer, I’m happy to change it accordingly.
No, that's not what I had in mind. That said it's up to you to decide how you
want the caller to behave. If you think that obtaining index is not necessary in
all the scenarios, then you should retain your current functionality.

~Michal



From xen-devel-bounces@lists.xenproject.org Mon Jun 30 12:13:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 12:13:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1029107.1402843 (Exim 4.92)
	(envelope-from )
	id 1uWDNs-000765-6S; Mon, 30 Jun 2025 12:13:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1029107.1402843; Mon, 30 Jun 2025 12: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 1uWDNs-00075y-3X; Mon, 30 Jun 2025 12:13:16 +0000
Received: by outflank-mailman (input) for mailman id 1029107;
 Mon, 30 Jun 2025 12:13:14 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uWDNq-00075s-Ji
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 12:13:14 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uWDNp-00AGvf-2U;
 Mon, 30 Jun 2025 12:13:13 +0000
Received: from [2a02:8012:3a1:0:a1f7:3d35:dea1:a2b4]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uWDNp-00F6om-1N;
 Mon, 30 Jun 2025 12:13:13 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=QQ1WRMOpNU2NBRAXTEDFPiuLs+JzVHf1HANAaT0glPU=; b=HiSDNAvELHA7+LK1XJPAgeNKCk
	LDCK8Ym4RK91lxAJDqiaqqE1ZwehsY0CDkbJK5Xoh5aWVqMK4ZtnmlrMbhU2mIlVw1lz7EkySGZCR
	y542k4Qi2McXKHiWD4FKW7d6kMgR3/kSZ7AVq95ZNAIQLgsIc0T4XlnziET9ceagSNqA=;
Message-ID: <5992e6bf-e9ea-480f-bcd3-a6cf1c335190@xen.org>
Date: Mon, 30 Jun 2025 13:13:10 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v4 8/8] docs: armproposa: l to add separate SCMI node
 for Xen agent
To: Oleksii Moisieiev ,
 Stefano Stabellini 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper ,
 Anthony PERARD ,
 Bertrand Marquis , Jan Beulich
 , Juergen Gross ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Volodymyr Babchuk ,
 Grygorii Strashko 
References: 
 <3f7e1e99f5d1018064f3c4825aff16bd487cf558.1747669845.git.oleksii_moisieiev@epam.com>
 
 
 
 
 
 <3468bb57-3178-460b-8fb2-3ce106475319@xen.org>
 
 
 
 <41566d23-464b-4676-8e01-e2f27d377a94@xen.org>
 <6689b22a-f85e-40ba-a89b-7935df1bdd28@epam.com>
Content-Language: en-US
From: Julien Grall 
In-Reply-To: <6689b22a-f85e-40ba-a89b-7935df1bdd28@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

On 30/06/2025 12:57, Oleksii Moisieiev wrote:
> KVM [1] is not applicable here as it starts under/inside Linux, so it
> doesn't have direct access to SCMI, the Linux does.
> And Linux will see only one SCMI transport (Agent).
> Seems, the only option possible is virtio-scmi (qemu) - the virtio-scmi
> potentially can simulate multi-channel,
 > but this is out if scope of this work.
> QNX [0] relies on configuration files rather than the Device Tree.
To clarify, I didn't ask to implement anything in KVM or QNX. I asked to 
write the bindings in a way that they are not Xen specific to give a 
chance to for other to re-use them. Yes today KVM and QNX would not use 
them... But I also still don't see why we should actively prevent them 
to use the bindings you come up with...

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Mon Jun 30 12:14:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 12:14:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1029113.1402853 (Exim 4.92)
	(envelope-from )
	id 1uWDOl-0007ar-Dq; Mon, 30 Jun 2025 12:14:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1029113.1402853; Mon, 30 Jun 2025 12:14: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 1uWDOl-0007ak-BH; Mon, 30 Jun 2025 12:14:11 +0000
Received: by outflank-mailman (input) for mailman id 1029113;
 Mon, 30 Jun 2025 12:14: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 1uWDOk-0007ae-0S
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 12:14:10 +0000
Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com
 [2a00:1450:4864:20::342])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b9628a59-55ab-11f0-a312-13f23c93f187;
 Mon, 30 Jun 2025 14:14:08 +0200 (CEST)
Received: by mail-wm1-x342.google.com with SMTP id
 5b1f17b1804b1-453634d8609so30236085e9.3
 for ; Mon, 30 Jun 2025 05:14:08 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a87e947431sm10312089f8f.0.2025.06.30.05.14.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 30 Jun 2025 05:14:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b9628a59-55ab-11f0-a312-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1751285648; x=1751890448; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=5ihKzTcbo5RVMrh97KWV1e+2z1l30RUrT8RORTZOh/s=;
        b=lC5J/4IM/IbISJAzlqq7A02AmYgUcnUpTu1Jpe1BCcu8vRffOAnyUVehFP/o52PBaV
         ydNFb72KfenjUKApPcvAL6/UFymEeNlshCBSZ8wBtcubjkl01efZVIFAcby7/3kJgq+F
         hplQZhmk+UWV9DPMVAdAuaWDVFOfroF+S3uo0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751285648; x=1751890448;
        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=5ihKzTcbo5RVMrh97KWV1e+2z1l30RUrT8RORTZOh/s=;
        b=P4Ff5sqWOKHWVIy+jT/VVmQX/rsyEPl5RXNowKnS4sclvN9ifTUxuTXkGyplOPq5RY
         /SLvVXNOp8mxBI9+e733ZRm+OqhCKmAPYAQ2a30S5Txc+LzBxEl1/5HfZU64t8RYiIbT
         68/TOyeiz40wIw+kRELE8UOh6uNQ4iSYyX+ZPW1fT1Rk1yEur+AT5swDOrWdhrcfGslA
         rYpJGZstVPO+glZ7l7oYdKSq1U+SPaJHxE/IoDrURD11QvX/3+sRCw4Lo4HLfYGi7Qv2
         lz2Ke8r2Wlr9/GfpurJRq/V/D/UFb1L8J+ZylSV/EUMEt8u+oySTTXhdqS8jczbAAOMT
         a2yA==
X-Forwarded-Encrypted: i=1; AJvYcCXJ2nuYMMmyjOterR6zVYb/OiGEPRiCYYJNYs784gOQ5vse2wc+BIWm7AT9FCcakgGOTNwCXPTnKVg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyRPa3DVh4NlSGGk1Svi3sPGTcQbblN0h2kQSZu7Ax1I+gnds1+
	/PhWSWfJS2vNIaoGIuTXACDTI4K/Mvlulv5NiyHMttKkKvKy9CI5G6qnvjcHbSLBdGA=
X-Gm-Gg: ASbGncuRPPwXUc0kPbhTbt4+u9uz8s9ge0LAmN4fLi6TsIcuZQbtMcly7Q1rAN6FNlD
	+lwuHfZWfc5w2WO69Oy3bC2/u++MpA0eXPr0XHgtSdfDf0jNpVYlDygLY7oPvIGnVJ/xLvhTfbv
	efoju3+2JztnyrRC7o+8J+gsW8ZcEJbZYtXu6YNah40oj3cpTxKMB5J9q+lMThUeEcQU9AanINU
	VwY7aaIwHbL7RvaKUUbZEYCEcs/kWhE1sxmvWHFcbQ5z2zqhsiBQ7c749RtgmPEwXhiutB5YvOJ
	DjM5v11iruzhun6VYTNrWOcTiiul9OG0p0dYm7iME+ecaoZ/f1otKAReMkuBMc5iy+ZoL9iKArC
	C8q7Ohw9C88BZbktIApQMCr742GrqcNw7tclX8g==
X-Google-Smtp-Source: AGHT+IGC9WaZOgy0e4CwB0JAWGOZM/CD8Hfg7YfH9Lscncd/2y05Bz5vHw5/meD8ChB4DU3dJYPzgw==
X-Received: by 2002:a5d:5f49:0:b0:3a3:7ba5:9618 with SMTP id ffacd0b85a97d-3a8ffccac13mr11757313f8f.29.1751285647897;
        Mon, 30 Jun 2025 05:14:07 -0700 (PDT)
Message-ID: <2a2315c8-4903-4377-b879-c99b95404609@citrix.com>
Date: Mon, 30 Jun 2025 13:14:06 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/build: pass -fzero-init-padding-bits=all to gcc15
To: Jan Beulich ,
 "xen-devel@lists.xenproject.org" 
Cc: Julien Grall , Stefano Stabellini
 , Anthony PERARD ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 
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 18/06/2025 9:22 am, Jan Beulich wrote:
> See the respective bullet point in the Caveats section of
> https://gcc.gnu.org/gcc-15/changes.html.
>
> While I'm unaware of us currently relying on the pre-gcc15 behavior,
> let's still play safe and retain what unknowingly we may have been
> relying upon.
>
> According to my observations, on x86 generated code changes
> - somewhere deep in modify_bars(), presumably from the struct map_data
>   initializer in apply_map() (a new MOVQ),
> - in vpci_process_pending(), apparently again from the struct map_data
>   initializer (and again a new MOVQ),
> - near the top of find_cpio_data(), presumably from the struct cpio_data
>   initializer (a MOVW changing to a MOVQ).
>
> Requested-by: Andrew Cooper 
> Signed-off-by: Jan Beulich 

Acked-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 12:21:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 12:21:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1029119.1402864 (Exim 4.92)
	(envelope-from )
	id 1uWDWD-0000tu-6U; Mon, 30 Jun 2025 12:21:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1029119.1402864; Mon, 30 Jun 2025 12:21:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uWDWD-0000tn-3c; Mon, 30 Jun 2025 12:21:53 +0000
Received: by outflank-mailman (input) for mailman id 1029119;
 Mon, 30 Jun 2025 12:21: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 1uWDWB-0000th-PG
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 12:21:51 +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 cceace91-55ac-11f0-a312-13f23c93f187;
 Mon, 30 Jun 2025 14:21:51 +0200 (CEST)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-453647147c6so47842895e9.2
 for ; Mon, 30 Jun 2025 05:21:51 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4538233c4acsm161332475e9.1.2025.06.30.05.21.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 30 Jun 2025 05:21:50 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cceace91-55ac-11f0-a312-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1751286110; x=1751890910; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=z8f+hd9kPFk/vvLhPYl067xUnHuLLUSWmVD76ZBQOXU=;
        b=EYSNxViHyrCBHh7H+lEKYH+L1mH8NgpTXPaUhpmVxGD/ZcWizswrrZAPs1GbIPtNhL
         cGgo98Q/1UUN4NhndIpODvD56KR4UPsd7U6wgCDMN6aQnBUKghKTjtD3pgbGvcGGxyum
         NeJZBlD2d9BTtdpa+Ma6KnVMQT3UEaDoErdso=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751286110; x=1751890910;
        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=z8f+hd9kPFk/vvLhPYl067xUnHuLLUSWmVD76ZBQOXU=;
        b=BW/38BwYuFt60fe4x1OioEXIFLZ8OUjKfcG/EEvUEkvExVMsPT7p5llYDO8InThdnT
         7YVZwYOC9Op8Da0RwON+2VTEBNlYdIjrDvqhiBczZXJANJPxphKsaS8Hm+KcQyjndDlZ
         W1KXTzXLhonsma+WFluNAZlnYKiGvCD5iQGF+YKsBKueMXceSp2jKV3qRNX9m1s+s60A
         VfjID84Yxbyaz670KhxqPXDMxy4DKBifarvXup4EutACVPG3mwqnkp6qqiuIrtr79WIz
         NmC2Xas8SM8WntLC68W9dQbG741j6uywkfo1RVPJ9VmmSes8CZACnOe7ZA9DhfBDK+BV
         L3UQ==
X-Forwarded-Encrypted: i=1; AJvYcCVX7xMUR7ayrgpQlHPr/Y1+3KeMqU0TMbcT3TngmksOP2sqPhs/hD07zYq9bNXm/VH0+yldmvhPj7E=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwRZdATk6dbRXsEwLheXRwqhbb4ZylV6PNt/IhnRs5nnHQQ9DLx
	dmA5TnKCHoKM5x+9aGiHZ2sOBT8PSr/jh9tLOY5RLN+4uHeqJznA9iG4wbultTSO1+Q5i1lnrOT
	sBiSOUFPGhA==
X-Gm-Gg: ASbGnctJtUi1Wsk3vQldNLOWwWs04M053EZ42IGlo5s+/wVEER00W3cXTgqT515WHpQ
	0QnBH3lTIJ1fXctMTD1GBy1ItCQ+eK4VzgI9e+XDWjQ6K+Ohx41LAL3LydXi6SIilcQcCkHK2R4
	LWtlIHSTdNc1XHhmVcHhgtCd4CpqNJanD3SYFI9vH8Ufp4wlpLsc8A6oiPgGroF68M5vMwXSqZN
	hc6Dm8ghFxq2pVWuMZ9hYdVNBgGlVc0cg6R2c++4l7H4STYxFHzmXhUS5nZwwDYIPo1mEqoZCLC
	l7sb2emKKKWC89X0nAhzPgMYsfxqzP7Xhuh3CiOW4W/fVTUfYxNuGLUoyvYkGBJohOHS74dQBNP
	9ixL6cTswiPvo9YifkTjq25Rff7E=
X-Google-Smtp-Source: AGHT+IF4dmJYoN/fFm85UW+ys+1C3BJsj5B6zGKnsjaP+Cq2R0GqJcVMPEdUtaMA56oPFxAwtVa7IA==
X-Received: by 2002:a05:600c:4f13:b0:453:2433:1c5b with SMTP id 5b1f17b1804b1-4538ee15a9emr133309415e9.5.1751286110407;
        Mon, 30 Jun 2025 05:21:50 -0700 (PDT)
Message-ID: 
Date: Mon, 30 Jun 2025 13:21:49 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/EFI: restrict use of --dynamicbase
To: Jan Beulich ,
 "xen-devel@lists.xenproject.org" 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Marek Marczykowski ,
 Daniel Smith 
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 26/06/2025 1:45 pm, Jan Beulich wrote:
> At least GNU ld 2.35 takes this option to (also) mean what newer
> versions have controllable by --enable-reloc-section. From there being
> no relocations in check.efi (as we don't pass the option there) we infer
> that we need to involve mkreloc, we'd end up with two sets of
> relocations, which clearly isn't going to work. Furthermore the
> relocations ld emits in this case also aren't usable: For bsp_idt[] we
> end up with PE_BASE_RELOC_LOW ones, which efi_arch_relocate_image()
> (deliberately) doesn't know how to deal with. (Related to that is also
> why we check the number of relocations produced: The linker simply
> didn't get this right there, yet.)
>
> We also can't add the option to what we use when linking check.efi: That
> ld version then would produce relocations, but 4 of them (instead of the
> expected two). That would make us pass --disable-reloc-section, which
> however only ld 2.36 and newer understand.
>
> For such older binutils versions we therefore need to accept the slight
> inconsistency in DLL characteristics that the earlier commit meant to
> eliminate.
>
> Fixes: f2148773b8ac ("x86/EFI: sanitize DLL characteristics in binary")
> Signed-off-by: Jan Beulich 

Acked-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 14:28:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 14:28:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1029137.1402879 (Exim 4.92)
	(envelope-from )
	id 1uWFUN-0006VP-PC; Mon, 30 Jun 2025 14:28:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1029137.1402879; Mon, 30 Jun 2025 14:28: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 1uWFUN-0006VI-Kv; Mon, 30 Jun 2025 14:28:07 +0000
Received: by outflank-mailman (input) for mailman id 1029137;
 Mon, 30 Jun 2025 14:28: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 1uWFUM-0006VC-0C
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 14:28:06 +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 6e08a87f-55be-11f0-b894-0df219b8e170;
 Mon, 30 Jun 2025 16:28:02 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a507e88b0aso1691584f8f.1
 for ; Mon, 30 Jun 2025 07:28:02 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b34e300468esm8355889a12.7.2025.06.30.07.27.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 30 Jun 2025 07:28:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6e08a87f-55be-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1751293682; x=1751898482; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=tNAzRwSUmpb40GYW3sbkxbQ/2GJEtF2fvN/x6Jdlwwo=;
        b=JwmTqcQ6SHLiJD+1WOa+To8jaSpKh9QeMNzOPIHC+O1xFRZ2Yfbkq5n6iaTR4c1Rm0
         2tiQ1yHl/OE6jeqYPGNLSVN1e27D7861wXulNaNrr0n6hdwI/d0ddYcfemZ7f8dm/j7m
         DjbfttAnxsoprfUGhgYCcF1L0Du2vzpy+E9rHxkdDkP3DGo7CUn5ZMKOYhZMbzYIazS+
         7vZTx/A5Jrq4BKKkxEgHx0AVVjp9iES2imeupJjcC5UZ2FNvohGX4DUZJnUBPQ9dwyMO
         XaiaX32jpPE0v0TWI/hKfROc8B78GdyB7XTvvFvIf2md72qFj2aBsTbZv3zJH0NRVYui
         tSnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751293682; x=1751898482;
        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=tNAzRwSUmpb40GYW3sbkxbQ/2GJEtF2fvN/x6Jdlwwo=;
        b=oD1ClyDOjs2KXXo4J6UnSsXaKh5+uuCFOKAtL34Cqx1gHbhjdqaGiM3ecHCWnzg5JX
         LxwnoGs5h74gjUKHSqBD6KxYxN3yAe74+CSsLkrpNyzFwaNuGDZQlOWJQB3FrrtgKMcZ
         caFNiDeaSyVD+/jrM6AaDYls3JZD7UTdJGRY0l8pwkH9zgtw+q37ZPeTELcVcHzzoV9H
         4opIHP36ujZXKuRADW7kwhOJ5C/TQ+3CKDqdR/sAXKQ6wtVc7urITXU+eeKZZeJVfrWK
         yBU8+lFXgyNXeL1G1exBy64vEHfR634Vr9Tg3UktT12JfGHR/DfUYM5P25OF1KyzcfU2
         1LxQ==
X-Forwarded-Encrypted: i=1; AJvYcCWZK0AixFF31NAT7wpVKKR0gnhTht5RyeG9ViiAY+6fs12gEo4KD/8E+9kSkqS6S5Ti+yLIIW+R05o=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyhs51xCUz+vvBIKntgb4YEbl7WydWU4jQTv039MKlCRI8Wa6lf
	iRpN96CTu7EjO2YjQRno2bmv6/+XNyqzq95YeEHbo5SNBP9d9VNK6Ff0AHyq8m556g==
X-Gm-Gg: ASbGncuU3igsRd4CxzrpMj4RWKHrs49MaK1190FEcvgkhBq2LfzqiRJqrrbGjsrVVNX
	1/Gxfzu+KlZ+Jud/2gt5G9Ou2cFge1rHphgbsNjTUWPBJ0v9WWa63T8RhC03TVYhAz9d4718HLA
	6dmwiaP8owtSv77TFMwzreQEcrLcI2jtYv66SH0U9J/ZGD3eiagsWcI8que1wm/IQh3cfxKoumV
	SqEbtYJUcb8MQApfUORpnC7MBTFgWXVO6mwPaTsxqtXfn9qgvIxr3H6/1pV/QBYu0SU3c6d9A74
	WD9JpzPrTsaS6LtbJ4x8duvk/RiHnvmcFuod04/rszP79Gbm4llfiG+4TsuhtGYIwP0FmfUE2C+
	l/NvuzzHCfwOQIVLxxYrJHOIty9tU3u4TGsCyyYoV7lxqtdc=
X-Google-Smtp-Source: AGHT+IHHGfWC8YLezkbzCmhGV8Qs5Go3t/7edFFahQom+qMY9Xy30I8L1bLuvexpti0+fT1ZNxxLqg==
X-Received: by 2002:adf:9d8b:0:b0:3a5:2f23:3789 with SMTP id ffacd0b85a97d-3a8f4b0ab87mr9350179f8f.15.1751293681992;
        Mon, 30 Jun 2025 07:28:01 -0700 (PDT)
Message-ID: <2d06fcf9-0aa8-48d7-84bd-4dd700a22da8@suse.com>
Date: Mon, 30 Jun 2025 16:27:50 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 3/9] xen/riscv: imsic_init() implementation
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 ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <0b366c5b7c8d34a98c8ec4bedf1f00b070a6fae1.1749825782.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: <0b366c5b7c8d34a98c8ec4bedf1f00b070a6fae1.1749825782.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.06.2025 17:48, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/imsic.c
> @@ -0,0 +1,369 @@
> +/* SPDX-License-Identifier: MIT */
> +
> +/*
> + * xen/arch/riscv/imsic.c
> + *
> + * RISC-V Incoming MSI Controller support
> + *
> + * (c) Microchip Technology Inc.
> + * (c) Vates
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#define IMSIC_HART_SIZE(guest_bits) (BIT(guest_bits, U) * IMSIC_MMIO_PAGE_SZ)
> +
> +struct imsic_mmios {
> +    paddr_t base_addr;
> +    unsigned long size;
> +};
> +
> +static struct imsic_config imsic_cfg;
> +
> +/* Callers aren't intended to changed imsic_cfg so return const. */
> +const struct imsic_config *imsic_get_config(void)
> +{
> +    return &imsic_cfg;
> +}
> +
> +static int __init imsic_get_parent_hartid(const struct dt_device_node *node,
> +                                          unsigned int index,
> +                                          unsigned long *hartid)
> +{
> +    int res;
> +    struct dt_phandle_args args;
> +
> +    res = dt_parse_phandle_with_args(node, "interrupts-extended",
> +                                     "#interrupt-cells", index, &args);
> +    if ( !res )
> +        res = dt_processor_hartid(args.np->parent, hartid);
> +
> +    return res;
> +}
> +
> +/*
> + * Parses IMSIC DT node.
> + *
> + * Returns 0 if initialization is successful, a negative value on failure,
> + * or IRQ_M_EXT if the IMSIC node corresponds to a machine-mode IMSIC,
> + * which should be ignored by the hypervisor.
> + */
> +static int imsic_parse_node(const struct dt_device_node *node,
> +                            unsigned int *nr_parent_irqs,
> +                            unsigned int *nr_mmios)
> +{
> +    int rc;
> +    unsigned int tmp;
> +    paddr_t base_addr;
> +    uint32_t *irq_range;
> +
> +    *nr_parent_irqs = dt_number_of_irq(node);
> +    if ( !*nr_parent_irqs )
> +        panic("%s: irq_num can't be 0. Check %s node\n", __func__,
> +              dt_node_full_name(node));
> +
> +    irq_range = xvzalloc_array(uint32_t, *nr_parent_irqs * 2);
> +    if ( !irq_range )
> +        panic("%s: irq_range[] allocation failed\n", __func__);
> +
> +    if ( (rc = dt_property_read_u32_array(node, "interrupts-extended",
> +                                    irq_range, *nr_parent_irqs * 2)) )

Nit: Indentation.

> +        panic("%s: unable to find interrupt-extended in %s node: %d\n",
> +              __func__, dt_node_full_name(node), rc);
> +
> +    /* Check that interrupts-extended property is well-formed. */
> +    for ( unsigned int i = 2; i < (*nr_parent_irqs * 2); i += 2 )
> +    {
> +        if ( irq_range[i + 1] != irq_range[1] )
> +            panic("%s: mode[%u] != %u\n", __func__, i + 1, irq_range[1]);
> +    }
> +
> +    if ( irq_range[1] == IRQ_M_EXT )
> +    {
> +        /* Machine mode imsic node, ignore it. */
> +        xfree(irq_range);

xvfree()

> +        return IRQ_M_EXT;
> +    }
> +
> +    xfree(irq_range);

Again.

> +    if ( !dt_property_read_u32(node, "riscv,guest-index-bits",
> +                               &imsic_cfg.guest_index_bits) )
> +        imsic_cfg.guest_index_bits = 0;
> +    tmp = BITS_PER_LONG - IMSIC_MMIO_PAGE_SHIFT;
> +    if ( tmp < imsic_cfg.guest_index_bits )
> +    {
> +        printk(XENLOG_ERR "%s: guest index bits too big\n",
> +               dt_node_name(node));
> +        return -ENOENT;
> +    }
> +
> +    /* Find number of HART index bits */
> +    if ( !dt_property_read_u32(node, "riscv,hart-index-bits",
> +                               &imsic_cfg.hart_index_bits) )
> +        /* Assume default value */
> +        imsic_cfg.hart_index_bits = fls(*nr_parent_irqs - 1);
> +    tmp -= imsic_cfg.guest_index_bits;
> +    if ( tmp < imsic_cfg.hart_index_bits )
> +    {
> +        printk(XENLOG_ERR "%s: HART index bits too big\n",
> +               dt_node_name(node));
> +        return -ENOENT;
> +    }
> +
> +    /* Find number of group index bits */
> +    if ( !dt_property_read_u32(node, "riscv,group-index-bits",
> +                               &imsic_cfg.group_index_bits) )
> +        imsic_cfg.group_index_bits = 0;
> +    tmp -= imsic_cfg.hart_index_bits;
> +    if ( tmp < imsic_cfg.group_index_bits )
> +    {
> +        printk(XENLOG_ERR "%s: group index bits too big\n",
> +               dt_node_name(node));
> +        return -ENOENT;
> +    }
> +
> +    /* Find first bit position of group index */
> +    tmp = IMSIC_MMIO_PAGE_SHIFT * 2;
> +    if ( !dt_property_read_u32(node, "riscv,group-index-shift",
> +                               &imsic_cfg.group_index_shift) )
> +        imsic_cfg.group_index_shift = tmp;
> +    if ( imsic_cfg.group_index_shift < tmp )
> +    {
> +        printk(XENLOG_ERR "%s: group index shift too small\n",
> +               dt_node_name(node));
> +        return -ENOENT;
> +    }
> +    tmp = imsic_cfg.group_index_bits + imsic_cfg.group_index_shift - 1;
> +    if ( tmp >= BITS_PER_LONG )
> +    {
> +        printk(XENLOG_ERR "%s: group index shift too big\n",
> +               dt_node_name(node));
> +        return -ENOENT;
> +    }
> +
> +    /* Find number of interrupt identities */
> +    if ( !dt_property_read_u32(node, "riscv,num-ids", &imsic_cfg.nr_ids) )
> +    {
> +        printk(XENLOG_ERR "%s: number of interrupt identities not found\n",
> +               node->name);
> +        return -ENOENT;
> +    }
> +
> +    if ( (imsic_cfg.nr_ids < IMSIC_MIN_ID) ||
> +         (imsic_cfg.nr_ids > IMSIC_MAX_ID) )
> +    {
> +        printk(XENLOG_ERR "%s: invalid number of interrupt identities\n",
> +               node->name);
> +        return -ENOENT;
> +    }
> +
> +    /* Compute base address */
> +    *nr_mmios = 0;
> +    rc = dt_device_get_address(node, *nr_mmios, &base_addr, NULL);
> +    if ( rc )
> +    {
> +        printk(XENLOG_ERR "%s: first MMIO resource not found: %d\n",
> +               dt_node_name(node), rc);
> +        return rc;
> +    }
> +
> +    imsic_cfg.base_addr = base_addr;
> +    imsic_cfg.base_addr &= ~(BIT(imsic_cfg.guest_index_bits +
> +                                 imsic_cfg.hart_index_bits +
> +                                 IMSIC_MMIO_PAGE_SHIFT, UL) - 1);
> +    imsic_cfg.base_addr &= ~((BIT(imsic_cfg.group_index_bits, UL) - 1) <<
> +                             imsic_cfg.group_index_shift);
> +
> +    /* Find number of MMIO register sets */
> +    do {
> +        (*nr_mmios)++;

Just to mention, this can be had without the need for parentheses: ++*nr_mmios;

> +    } while ( !dt_device_get_address(node, *nr_mmios, &base_addr, NULL) );
> +
> +    return 0;
> +}
> +
> +/*
> + * Initialize the imsic_cfg structure based on the IMSIC DT node.
> + *
> + * Returns 0 if initialization is successful, a negative value on failure,
> + * or IRQ_M_EXT if the IMSIC node corresponds to a machine-mode IMSIC,
> + * which should be ignored by the hypervisor.
> + */
> +int __init imsic_init(const struct dt_device_node *node)
> +{
> +    int rc;
> +    unsigned long reloff, hartid;
> +    unsigned int nr_parent_irqs, index, nr_handlers = 0;
> +    paddr_t base_addr;
> +    unsigned int nr_mmios;
> +    struct imsic_mmios *mmios;
> +    struct imsic_msi *msi = NULL;
> +
> +    /* Parse IMSIC node */
> +    rc = imsic_parse_node(node, &nr_parent_irqs, &nr_mmios);
> +    /*
> +     * If machine mode imsic node => ignore it.
> +     * If rc < 0 => parsing of IMSIC DT node failed.
> +     */
> +    if ( (rc == IRQ_M_EXT) || (rc < 0) )
> +        return rc;
> +
> +    /* Allocate MMIO resource array */
> +    mmios = xvzalloc_array(struct imsic_mmios, nr_mmios);
> +    if ( !mmios )
> +    {
> +        rc = -ENOMEM;
> +        goto imsic_init_err;
> +    }
> +
> +    msi = xvzalloc_array(struct imsic_msi, nr_parent_irqs);
> +    if ( !msi )
> +    {
> +        rc = -ENOMEM;
> +        goto imsic_init_err;
> +    }
> +
> +    /* Check MMIO register sets */
> +    for ( unsigned int i = 0; i < nr_mmios; i++ )
> +    {
> +        unsigned int guest_bits = imsic_cfg.guest_index_bits;
> +        unsigned long expected_mmio_size =
> +            IMSIC_HART_SIZE(guest_bits) * nr_parent_irqs;
> +
> +        rc = dt_device_get_address(node, i, &mmios[i].base_addr,
> +                                   &mmios[i].size);
> +        if ( rc )
> +        {
> +            printk(XENLOG_ERR "%s: unable to parse MMIO regset %u\n",
> +                   node->name, i);
> +            goto imsic_init_err;
> +        }
> +
> +        base_addr = mmios[i].base_addr;
> +        base_addr &= ~(BIT(guest_bits +
> +                           imsic_cfg.hart_index_bits +
> +                           IMSIC_MMIO_PAGE_SHIFT, UL) - 1);
> +        base_addr &= ~((BIT(imsic_cfg.group_index_bits, UL) - 1) <<
> +                       imsic_cfg.group_index_shift);
> +        if ( base_addr != imsic_cfg.base_addr )
> +        {
> +            rc = -EINVAL;
> +            printk(XENLOG_ERR "%s: address mismatch for regset %u\n",
> +                   node->name, i);
> +            goto imsic_init_err;
> +        }
> +
> +        if ( mmios[i].size != expected_mmio_size )
> +        {
> +            rc = -EINVAL;
> +            printk(XENLOG_ERR "%s: IMSIC MMIO size is incorrect %ld, expected MMIO size: %ld\n",
> +                   node->name, mmios[i].size, expected_mmio_size);
> +            goto imsic_init_err;
> +        }
> +    }
> +
> +    /* Configure handlers for target CPUs */
> +    for ( unsigned int i = 0; i < nr_parent_irqs; i++ )
> +    {
> +        unsigned int cpu;
> +
> +        rc = imsic_get_parent_hartid(node, i, &hartid);
> +        if ( rc )
> +        {
> +            printk(XENLOG_WARNING "%s: cpu ID for parent irq%u not found\n",
> +                   node->name, i);
> +            continue;
> +        }
> +
> +        cpu = hartid_to_cpuid(hartid);
> +
> +        /*
> +         * If .base_addr is not 0, it indicates that the CPU has already been
> +         * found.
> +         * In this case, skip re-initialization to avoid duplicate setup.
> +         * Also, print a warning message to signal that the DTS should be
> +         * reviewed for possible duplication.
> +         */
> +        if ( msi[cpu].base_addr )
> +        {
> +            printk("%s: cpu%d is found twice in interrupts-extended prop\n",
> +                  node->name, cpu);

%u please for unsigned int arguments.

> +            continue;
> +        }
> +
> +        if ( cpu >= num_possible_cpus() )
> +        {
> +            printk(XENLOG_WARNING "%s: unsupported hart ID=%#lx for parent irq%u\n",
> +                   node->name, hartid, i);
> +            continue;
> +        }
> +
> +        /* Find MMIO location of MSI page */
> +        reloff = i * IMSIC_HART_SIZE(imsic_cfg.guest_index_bits);
> +        for ( index = 0; index < nr_mmios; index++ )
> +        {
> +            if ( reloff < mmios[index].size )
> +                break;
> +
> +            /*
> +             * MMIO region size may not be aligned to
> +             * IMSIC_HART_SIZE(guest_index_bits) if
> +             * holes are present.
> +             */
> +            reloff -= ROUNDUP(mmios[index].size,
> +                      IMSIC_HART_SIZE(imsic_cfg.guest_index_bits));

Nit: Indentation again.

> --- a/xen/arch/riscv/include/asm/smp.h
> +++ b/xen/arch/riscv/include/asm/smp.h
> @@ -3,6 +3,7 @@
>  #define ASM__RISCV__SMP_H
>  
>  #include 
> +#include 
>  #include 
>  
>  #include 
> @@ -18,6 +19,18 @@ static inline unsigned long cpuid_to_hartid(unsigned long cpuid)
>      return pcpu_info[cpuid].hart_id;
>  }
>  
> +static inline unsigned int hartid_to_cpuid(unsigned long hartid)
> +{
> +    for ( unsigned int cpuid = 0; cpuid < ARRAY_SIZE(pcpu_info); cpuid++ )

We had been there before, I think: Why "cpuid", not "cpu" (as we have it about
everywhere else)?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 14:33:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 14:33:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1029144.1402887 (Exim 4.92)
	(envelope-from )
	id 1uWFZS-00084p-8v; Mon, 30 Jun 2025 14:33:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1029144.1402887; Mon, 30 Jun 2025 14: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 1uWFZS-00084i-6L; Mon, 30 Jun 2025 14:33:22 +0000
Received: by outflank-mailman (input) for mailman id 1029144;
 Mon, 30 Jun 2025 14:33: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 1uWFZQ-00084c-Ri
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 14:33:20 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2a895047-55bf-11f0-b894-0df219b8e170;
 Mon, 30 Jun 2025 16:33:19 +0200 (CEST)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-60c93c23b08so4115636a12.3
 for ; Mon, 30 Jun 2025 07:33:19 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ae35365a00bsm671585366b.43.2025.06.30.07.33.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 30 Jun 2025 07:33:17 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2a895047-55bf-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1751293998; x=1751898798; 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=ArDgpdfYRcSK+x3VgTZdHw4Mxkly6eEcm7G1XIBFAYI=;
        b=baNTeit+paGZriXgjPt1+g9IF1mc1697xwc98W5W4eHZrOGKd/DnrqwamuxG2YX510
         nytVSya8e5u9txDD2WaJDXWiFKEE6AzjLLFABWDF+KzZI3EIW8mULgLVlGRkOueuaOyZ
         EGOpOEyVG52q0Q5KDzEO45hmtlQXFj29kLnUxLZr+CTC00MrXf8P5CTO4l4Jm115oetC
         RyF2ELFXVAcMpoF+R1NS83zq8ExjR003a9WWmIWmmm0lp6csIArt6gKwckOmlmLk4n+s
         UjyGNJgEwbUpTdI04/gFreCm9YQWQnLPO3+Opwco2AGotxMJL8Tq1U/Z5TQ4ZN2k0Me1
         VbyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751293998; x=1751898798;
        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=ArDgpdfYRcSK+x3VgTZdHw4Mxkly6eEcm7G1XIBFAYI=;
        b=FT98Gt3M+pdp7qznisF6oaMnNIsHnGwpX1tuIlP0Ba3+ZyZf8wkpIuQHrS7BHgyNWx
         vyQUsb6MYzU0aA1gFkWpcdVAXdtDsydHcbpFgxMm086miJ1Q6rI+4MvZR5y+3IIL6Jm0
         oxQ9+bDTNNun4Lc2DCBfPDTnyQxzEljqquCiPwuz1kRMvfz2dgu8e5yLLmYEp6MP0RSl
         8gH7Tp2zL43ct+3opqsuwh0kL5nRWlZiqjbu2Aads/Qxxk7BnM8d7rBYX8yWke3dxN1t
         V6uOzvU9ZGtpcga0Be/DhWEHv1jh42ACAXZSjxAhkl8LtU5zH5bvH0w4vKIebSByKJTg
         5NGQ==
X-Forwarded-Encrypted: i=1; AJvYcCVx/gDYtHBLIv+scjqWs4TqDdhXrhTw/q/9ftPHG57hQucXPdlxF15X1/XtaxRBw4wSNapMbNIdrho=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwPyzemeJJ3Uw9H7c9TlnWFTSFuLg3Bpy0mt2EpBQFH9m8f04sl
	1csYuhSbJu/zWb3R85PKXgHV0JR37Lnx3WzPmdy4gsnpp78TLa6C5Ppz
X-Gm-Gg: ASbGncuzkAZgBvSDuVuOMXe4PZ/8eL8r2CyET6YdYIyOReOeQB3ahPQg4QlNPT9lSDB
	+G3/TMwReni/rbmsaTrTm4AnlakJQGc/GUghOCHTFeZGVgm6RW5pWUJXnITsQuqftNVMjBoD8NH
	XZ98OeEgS6waF/GU4oWZN5YoXXkBXZ4FbTo5GdyBFS3M646UKmorUKi+7EHCx2srwccw+KmiCSk
	Y3Z5gENMdz1D/xuLnbhd9BMEAZjtpPDxS3HhakDtVk6TT8TT1CHQFbufUfa2llS3ys/eCfJB+Pl
	fOo+nKqAAQ6N+F9KOAwrrqcWgE07FC19TygD2eyv5/Grlz92hwVayi/UPYq8aQjXUXi0+bWCXJW
	GLDvkwwaKXrmgc6ZBeCca/G1HCe4QEiA00E0=
X-Google-Smtp-Source: AGHT+IEiWXre205oLlFE3NMVEWfRJXtuNSi3c/+zySYka1TvT6jayw2C4f7jhcNkyuU2XDx83sG9Rw==
X-Received: by 2002:a17:907:da0b:b0:ae3:4f80:ac4c with SMTP id a640c23a62f3a-ae34fd34584mr1134152566b.12.1751293997928;
        Mon, 30 Jun 2025 07:33:17 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------n1OeZGfRkjomcLYG4SFqHJ4E"
Message-ID: <13b80e15-9db9-427d-aaa2-c0389e4c248a@gmail.com>
Date: Mon, 30 Jun 2025 16:33:16 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 08/17] xen/riscv: add new p2m types and helper macros
 for type classification
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: 
 
 <8f45cffe-e2a2-46e3-8370-2b6b4c86dccf@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <8f45cffe-e2a2-46e3-8370-2b6b4c86dccf@suse.com>

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


On 6/26/25 4:59 PM, Jan Beulich wrote:
> On 10.06.2025 15:05, Oleksii Kurochko wrote:
>> --- a/xen/arch/riscv/include/asm/p2m.h
>> +++ b/xen/arch/riscv/include/asm/p2m.h
>> @@ -61,8 +61,28 @@ struct p2m_domain {
>>   typedef enum {
>>       p2m_invalid = 0,    /* Nothing mapped here */
>>       p2m_ram_rw,         /* Normal read/write domain RAM */
>> +    p2m_ram_ro,         /* Read-only; writes are silently dropped */
> As indicated before - this type should be added when the special handling that
> it requires is also introduced.

Perhaps, I missed that. I will drop this type for now.

>
>> +    p2m_mmio_direct_dev,/* Read/write mapping of genuine Device MMIO area */
> What's the _dev suffix indicating here?

It indicates that it is device memory, probably, it isn't so necessary in case of RISC-V as
spec doesn't use such terminology. In RISC-V there is only available IO, NC. And we are
|using PTE_PBMT_IO for |p2m_mmio_direct_dev.

Maybe it would be better just to rename s/p2m_mmio_direct_dev/p2m_mmio_direct_io.

~ Oleksii

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



  
    
  
  
    

    
    
    
    
    On 6/26/25 4:59 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 10.06.2025 15:05, Oleksii Kurochko wrote:

    
      
    
        
    --- a/xen/arch/riscv/include/asm/p2m.h
+++ b/xen/arch/riscv/include/asm/p2m.h
@@ -61,8 +61,28 @@ struct p2m_domain {
 typedef enum {
     p2m_invalid = 0,    /* Nothing mapped here */
     p2m_ram_rw,         /* Normal read/write domain RAM */
+    p2m_ram_ro,         /* Read-only; writes are silently dropped */

    
      
    
      
    As indicated before - this type should be added when the special handling that
it requires is also introduced.
    
    
    
    
    Perhaps, I missed that. I will drop this type for now.


    
    
    
      
    

    
      
    
        
    +    p2m_mmio_direct_dev,/* Read/write mapping of genuine Device MMIO area */

    
      
    
      
    What's the _dev suffix indicating here?
    
    
    
    
    It indicates that it is device memory, probably, it isn't so necessary in case of RISC-V as
spec doesn't use such terminology. In RISC-V there is only available IO, NC. And we are
using PTE_PBMT_IO for p2m_mmio_direct_dev.

Maybe it would be better just to rename s/p2m_mmio_direct_dev/p2m_mmio_direct_io.

~ Oleksii

    
  


--------------n1OeZGfRkjomcLYG4SFqHJ4E--


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 14:38:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 14:38:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1029151.1402898 (Exim 4.92)
	(envelope-from )
	id 1uWFeE-0000DA-Ql; Mon, 30 Jun 2025 14:38:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1029151.1402898; Mon, 30 Jun 2025 14:38: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 1uWFeE-0000D3-Nk; Mon, 30 Jun 2025 14:38:18 +0000
Received: by outflank-mailman (input) for mailman id 1029151;
 Mon, 30 Jun 2025 14:38: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 1uWFeD-0000Cu-HZ
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 14:38:17 +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 dab1c0fe-55bf-11f0-a312-13f23c93f187;
 Mon, 30 Jun 2025 16:38:14 +0200 (CEST)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-6088d856c6eso8533401a12.0
 for ; Mon, 30 Jun 2025 07:38:14 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ae35365a732sm691801866b.65.2025.06.30.07.38.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 30 Jun 2025 07:38:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: dab1c0fe-55bf-11f0-a312-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1751294294; x=1751899094; darn=lists.xenproject.org;
        h=in-reply-to:content-language:references:cc:to:from:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Kdi3iO9Hhrg5CZ/M4Mb+W+1knJL9sQGgZVt6/ZxFFpU=;
        b=JqfcfHWgApQaNh+9/G8ebxRN4EOMv81obJarW/F0E+gqokQKwegN/cRWs/bgyx6KRA
         cjCcLdMfJuBu2x2O7P0Z6/Uhd6bZT9pVue+iyFUKOy2t0UJ2zEGgB8XyxC4v4aZomril
         D+T40+2Iwzb2q++JRKxhsF0XpbeFQXwJzdgyLoS8VeCkp1ZdBR0AE4JlUHnJ3PRcWsYU
         KL1rKd0ETCep+RN7B0dTMVuexh+PPn3+G4RdgzxQHzwQJZ8YAKZ0AG0xmmEU2SlxfRoM
         v8+86HmvMyXQcXHtGOXpQN1hkC2TggiXLuSK1bPLagNGK1ID+LqAAhpgJ6n4/f/Em1on
         TJSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751294294; x=1751899094;
        h=in-reply-to: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=Kdi3iO9Hhrg5CZ/M4Mb+W+1knJL9sQGgZVt6/ZxFFpU=;
        b=txmKatKFWN2x9dtZqeKBjigU9AvN/RdHkirWhtvYIRWDqBU/MEG4Smd9Rc3Mve8Ges
         Dooe2OX60iKoB+BfH1U+GaMwAo3Dd2D2QCMtbSjp6dW2CPdPspQaLDrixNKdEOR+PiBy
         IFYKWkPcOjbhtT+UNAxUl8RSlLRQqgbXDVD3/4KJcT2SdkwaqD33z2xx1WroYi9C23qk
         T953mkKH/jVFMo2odVpgdwBWvCsLCV1tuD7Onl9KB2dI+BsD8hbMiGxvRXyv8qevgY6D
         Z/aA3AmUuLF80Y+Jlt9NDyvGkM0sxdhO+mLSTci7R8TEt8TjydtCL0KQFFmnnlfG7FDf
         /9Gw==
X-Forwarded-Encrypted: i=1; AJvYcCXIasEatkm+krTueWNeektDU+TqB7HfyxtMXHEjXvpWMXyH+1HIQV9iMaGug7IuL5k8dEFeO80ub00=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxZJd0GJnzgxERTBe0yEjYmKUPNA0YQQC7GGXZFX+8QzbizBlyV
	RdjjBbwXpvNPXCH84/tmjr2ppuKr4yBCM9Km+sv/xNNaO53N0mLr2cpU
X-Gm-Gg: ASbGncttcPZICLPsbbCE/ZztJI7Zy0TJ0WbY1DqSxkRuzYpkSLkIXLY7bEgIigVz0/1
	eb+tU9Ius+8VijYy8ud1yq+Xaid5XSChW+duxR66gr4lzKhzHfXAmdAr1n2pK06xQLnkUwfNYWG
	BdvFITJs2FYeK4LgYx+/btCQprX8X6VQRee+beVYSj57EM1rgIhMAX993HqMcksqHDsjsgu5hBz
	ayIL+bPn54o9uwdhFkT8iwrrlvCVj2z6DwlJVZhKQbS6mhtRoWo+t8XLcyY1ehOEKKEdusN7klj
	ilILxtLfNRR9x7ljhgqXl1IToz2CBcICkg9pxogqX03Hfhg48VlFY81NIzwVYPQ3mRJlNqcoPnm
	Gy6Gp8W5QfNxQUMXz6Ysd2B7+ps8R57o2xv0=
X-Google-Smtp-Source: AGHT+IEd5nB8VgRkFkw55I90KYrvv1ZHo/TlKndCPAPbX0gRPDBlgxqcelFKsQGHH0tVu3PTyWiZhg==
X-Received: by 2002:a17:907:96a5:b0:ade:902e:7b6b with SMTP id a640c23a62f3a-ae34fd3057cmr1329381466b.7.1751294293614;
        Mon, 30 Jun 2025 07:38:13 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------JNQ13cQHhSVgAzdZxVbg8j3M"
Message-ID: <6fafc0b4-cfea-4d67-bef6-4e40d1d3e743@gmail.com>
Date: Mon, 30 Jun 2025 16:38:12 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 08/17] xen/riscv: add new p2m types and helper macros
 for type classification
From: Oleksii Kurochko 
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: 
 
 <8f45cffe-e2a2-46e3-8370-2b6b4c86dccf@suse.com>
 <13b80e15-9db9-427d-aaa2-c0389e4c248a@gmail.com>
Content-Language: en-US
In-Reply-To: <13b80e15-9db9-427d-aaa2-c0389e4c248a@gmail.com>

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


On 6/30/25 4:33 PM, Oleksii Kurochko wrote:
>
>
> On 6/26/25 4:59 PM, Jan Beulich wrote:
>> On 10.06.2025 15:05, Oleksii Kurochko wrote:
>>> --- a/xen/arch/riscv/include/asm/p2m.h
>>> +++ b/xen/arch/riscv/include/asm/p2m.h
>>> @@ -61,8 +61,28 @@ struct p2m_domain {
>>>   typedef enum {
>>>       p2m_invalid = 0,    /* Nothing mapped here */
>>>       p2m_ram_rw,         /* Normal read/write domain RAM */
>>> +    p2m_ram_ro,         /* Read-only; writes are silently dropped */
>> As indicated before - this type should be added when the special handling that
>> it requires is also introduced.
> Perhaps, I missed that. I will drop this type for now.
>
>>> +    p2m_mmio_direct_dev,/* Read/write mapping of genuine Device MMIO area */
>> What's the _dev suffix indicating here?
> It indicates that it is device memory, probably, it isn't so necessary in case of RISC-V as
> spec doesn't use such terminology. In RISC-V there is only available IO, NC. And we are
> |using PTE_PBMT_IO for |p2m_mmio_direct_dev.
>
> Maybe it would be better just to rename s/p2m_mmio_direct_dev/p2m_mmio_direct_io.

I forgot that p2m_mmio_direct_dev is used by common code for dom0less code (handle_passthrough_prop())

~ Oleksii

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



  
    
  
  
    

    
    
    
    
    On 6/30/25 4:33 PM, Oleksii Kurochko
      wrote:
    
    
    
    
    
      
      

    
      
    
      
    On 6/26/25 4:59 PM, Jan Beulich
        wrote:
    
      
    
      
    
        
    On 10.06.2025 15:05, Oleksii Kurochko wrote:

    
        
    
          
    --- a/xen/arch/riscv/include/asm/p2m.h
+++ b/xen/arch/riscv/include/asm/p2m.h
@@ -61,8 +61,28 @@ struct p2m_domain {
 typedef enum {
     p2m_invalid = 0,    /* Nothing mapped here */
     p2m_ram_rw,         /* Normal read/write domain RAM */
+    p2m_ram_ro,         /* Read-only; writes are silently dropped */

    
        
    
        
    As indicated before - this type should be added when the special handling that
it requires is also introduced.
    
      
    
      
    Perhaps, I missed that. I will drop this type for now.


    
      
    
        
    
          
    +    p2m_mmio_direct_dev,/* Read/write mapping of genuine Device MMIO area */

    
        
    
        
    What's the _dev suffix indicating here?
    
      
    
      
    It indicates that it is device memory, probably, it isn't so necessary in case of RISC-V as
spec doesn't use such terminology. In RISC-V there is only available IO, NC. And we are
using PTE_PBMT_IO for p2m_mmio_direct_dev.

Maybe it would be better just to rename s/p2m_mmio_direct_dev/p2m_mmio_direct_io.
    
    
    
    
    I forgot that p2m_mmio_direct_dev is used by common code for dom0less code (handle_passthrough_prop())
    
    
    ~ Oleksii

    
  


--------------JNQ13cQHhSVgAzdZxVbg8j3M--


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 14:43:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 14:43:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1029160.1402908 (Exim 4.92)
	(envelope-from )
	id 1uWFio-0001tb-E9; Mon, 30 Jun 2025 14:43:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1029160.1402908; Mon, 30 Jun 2025 14:43: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 1uWFio-0001tU-BF; Mon, 30 Jun 2025 14:43:02 +0000
Received: by outflank-mailman (input) for mailman id 1029160;
 Mon, 30 Jun 2025 14:43: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 1uWFin-0001tO-In
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 14:43:01 +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 7fc41101-55c0-11f0-b894-0df219b8e170;
 Mon, 30 Jun 2025 16:42:51 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3a54690d369so2071596f8f.3
 for ; Mon, 30 Jun 2025 07:42:51 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23acb3c7041sm85215835ad.229.2025.06.30.07.42.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 30 Jun 2025 07:42:50 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7fc41101-55c0-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1751294571; x=1751899371; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=t2UUFMHYQFxRcKeaKAM8hKE0IDgedE7aosYybtaQ7vQ=;
        b=E9ns0rQTp7bKNDbhFboPzbZeKxIV1jd1MAgQElU+r31llSVC7GSz1HA/6aZPoGESdH
         dMNfC4cWKOktGRYapk4Sxu9SIw9+YFvQaesqfS+4JnqRyi0r965XD2Qgfpo/ZST9aiJE
         KhFAOgrvW6KhC0tauPXj1bcpdVfGYgYgzvsyxlsixxHhXM59RpyG7h7DAG41z5Zp2FMR
         kRQXMQiPJ2eG1LdBOYfKfmfw2ieYUujSF0phrfJ0qy3aSq3oixQa3n6KDGChU7R4jycM
         uVThxeqxMKbYfzul0N5W46QVR566zVDvBzy2Z/i8urylLZusOaMEedragb43NvaTbt9u
         HzKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751294571; x=1751899371;
        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=t2UUFMHYQFxRcKeaKAM8hKE0IDgedE7aosYybtaQ7vQ=;
        b=dPu+KNDFdnbXss8kzeM1HPv6ItRK7qzHl+vWLT8glOH7vbVR7tm2fjoGJIpu4xo/x5
         jPjbmokQKijTjMKxZciYYkvuVOy6bZBn4zcn4krmgwcZ6oXg4AH2pDNEZNSAYVv0nY7X
         2PFtrH3wI4cdfk3Irf0XjfPtZUb1Yvd189L2xhPPCWr8HLWQqzgH4owxHL0/lU5fKa6m
         5nahyl+DOxW02LXpUqMZeZkdkMv7tJ0MV8lO+AkKwVQK6QqazAHP75GLT4BMSDKu3DKq
         v+V0FNeCZeqB43Vwhln+TOhKY8hWPFx5O1nLJjGp6AQMxhYkw2q38SrpIGn8sokkf6yU
         Hfzw==
X-Forwarded-Encrypted: i=1; AJvYcCU3+wPuZyzYiknZQ27bwyJpTeN7yPyKMUDdHd4xFg8tb/A1Rv6uLLvTuSWH7phaNcK7Z003iWA8DcA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzNwTXsur3FJh2ZtJy5paVRTMimHvOn1Oztf8DGiCtia7KZzNep
	4dPOg/we6Pg63dmlufpJ6GIvYfPL2rwgfWtKsuYpvHgt2MqCK7PUe+HOwfb9zb0E+Q==
X-Gm-Gg: ASbGncs+wU2RbsE7tbxx3+CVRJks6iibaYa6V3AsGdozaaABN+bsUQt+1SvltxcU4kD
	0TUYNkLatVWnq07U7PUoVjn1g1MVZQYItyYKUpBZ5muyNGsjMuW59Q6WbX/2WnHl56dv255EvDB
	BcS6EWHfxDN49wM1uYB5DpFobXYTujAWunqneZFw3amYHRB6qKX2Qy62pgw5dW8IjipSLmH310L
	m1hcs1/rOyluYyc3HL5pSbGiuXrDWrWpqx8boy178DEo6TblbQXcuN2gqTVzdFR8e28IRaVkC1g
	U8vrWIFlrWGsqJ47DOINtG1OzFIIEOy5beCWOJCGkhwt8C4FLdwXssbA7pWd/fxzAY7IX1G0Pqg
	tKedtWPdooL+taAWLYNe4wnquefJKAwUpMgev0aqCpy+fwBg=
X-Google-Smtp-Source: AGHT+IHc/B2thAwTWJG3x9SJlU+DmjM1uxc06QqIRBX2qU6vjxrjGXbWKt61iSIyvo2sNFGwEAnSoA==
X-Received: by 2002:a05:6000:4182:b0:3a4:f6ba:51c8 with SMTP id ffacd0b85a97d-3a8f482bc72mr12244635f8f.14.1751294570821;
        Mon, 30 Jun 2025 07:42:50 -0700 (PDT)
Message-ID: <2ebfaa8c-e0bb-4c5b-89e1-48d309ee4989@suse.com>
Date: Mon, 30 Jun 2025 16:42:40 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 08/17] xen/riscv: add new p2m types and helper macros
 for type classification
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: 
 
 <8f45cffe-e2a2-46e3-8370-2b6b4c86dccf@suse.com>
 <13b80e15-9db9-427d-aaa2-c0389e4c248a@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: <13b80e15-9db9-427d-aaa2-c0389e4c248a@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 30.06.2025 16:33, Oleksii Kurochko wrote:
> On 6/26/25 4:59 PM, Jan Beulich wrote:
>> On 10.06.2025 15:05, Oleksii Kurochko wrote:
>>> --- a/xen/arch/riscv/include/asm/p2m.h
>>> +++ b/xen/arch/riscv/include/asm/p2m.h
>>> @@ -61,8 +61,28 @@ struct p2m_domain {
>>>   typedef enum {
>>>       p2m_invalid = 0,    /* Nothing mapped here */
>>>       p2m_ram_rw,         /* Normal read/write domain RAM */
>>> +    p2m_ram_ro,         /* Read-only; writes are silently dropped */
>> As indicated before - this type should be added when the special handling that
>> it requires is also introduced.
> 
> Perhaps, I missed that. I will drop this type for now.
> 
>>
>>> +    p2m_mmio_direct_dev,/* Read/write mapping of genuine Device MMIO area */
>> What's the _dev suffix indicating here?
> 
> It indicates that it is device memory, probably, it isn't so necessary in case of RISC-V as
> spec doesn't use such terminology. In RISC-V there is only available IO, NC. And we are
> |using PTE_PBMT_IO for |p2m_mmio_direct_dev.
> 
> Maybe it would be better just to rename s/p2m_mmio_direct_dev/p2m_mmio_direct_io.

And what would the _io suffix indicate, beyond what "mmio" already indicates?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 14:45:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 14:45:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1029168.1402917 (Exim 4.92)
	(envelope-from )
	id 1uWFlT-0002Rb-QR; Mon, 30 Jun 2025 14:45:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1029168.1402917; Mon, 30 Jun 2025 14: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 1uWFlT-0002RU-Nq; Mon, 30 Jun 2025 14:45:47 +0000
Received: by outflank-mailman (input) for mailman id 1029168;
 Mon, 30 Jun 2025 14: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 1uWFlS-0002RO-PT
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 14:45:46 +0000
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com
 [2a00:1450:4864:20::42e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e72ab568-55c0-11f0-b894-0df219b8e170;
 Mon, 30 Jun 2025 16:45:45 +0200 (CEST)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3a57c8e247cso1747893f8f.1
 for ; Mon, 30 Jun 2025 07:45:45 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-74af557441asm9820387b3a.95.2025.06.30.07.45.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 30 Jun 2025 07:45:43 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e72ab568-55c0-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1751294744; x=1751899544; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=CMzYDg/GwR8Fo0/1kMoNuv6cQYbt3N1U6xtipOr3aRY=;
        b=V5zD+1KL4AB2vaHghUQi66oRfEysfph8cbGBrKbD0nJmMAESafZXaa6VICMcWHklDm
         gtsuPsQVEB6prPc7pTQTQJF1OGnZbiqor6zqt6V1ksxoDvOb8RE5kb0qMe77V3h1Jrka
         Prqxux37Pn7tOT546YERlL1b6rgfsTWM+kw1+/o+4vIzzFOh8nL0mjNqaIdjMdv7Ags9
         tQ970Tbc+uZQO/RxjoMZklK11GFdhdWVoaer6j4G/p4xlT8kpzNz9qc4Mimn9EQWFFbS
         mprz2BML1CFTURuN05JP5iSOtc1iKanCb+mO3lrqnsXk7GVnsyMHCDww79Vs3xvd0iUa
         /9Dg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751294744; x=1751899544;
        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=CMzYDg/GwR8Fo0/1kMoNuv6cQYbt3N1U6xtipOr3aRY=;
        b=ZfhJrMq+mcA1tBiFP5v/ycp05ZUvvE1nOBgklfwqCjNLak16Y5jBUv/Iu58As0c/y0
         zZleakO1+vnqq2RXJ1mTHxEl+2fSyvSLng8xujV2Asl2Iy2NKrRFIEhDZGSypAn8u1e2
         SYXDFQpSZf9NSOca4grvRndQN5nP7dQA7OiTcSEgG6XjUYUOUFGA8YR7jx5bFjrI2WiI
         HeO5VIQzyW4Xi9VtgN1yeENybYLrJZ9tQmmgTnkhplx5BeEx2+/KVVFkMplt2N+QD94L
         3F7NfP7htYjRf/pWd47kT+n9FYwXaudjmgEUPbrmegIjzZzAgU9sdC+JlZ394a/hV0Zd
         bDSw==
X-Forwarded-Encrypted: i=1; AJvYcCXgO+lT41app+2OqYAaYsFWK5+zL78YuWbjYK61aD17tvDNUmPjirmJ5MILgbqi0JhBgkUveL01ylM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyu8ziB6LnACr7pCK7i6OQE0+pf3ayA43Gm4DU24PISkJBQoeUX
	U0Dy/5FmPLhT2ozNY2a67QQvpO2Cvb87imYLwtcCYDjTJYOXzHHzXnlF2M4eUYi4eQ==
X-Gm-Gg: ASbGncssl6zKm72GTZyWQa3MCenyGle8MfUyiPcA27EQqIoT7wvWE0s+Gq0PBNmKX6t
	igXy4Qx7apAcfo5yCJ2BSxxQ2FsbVvHGOueBml1ZQH4vN8ii60XPRMU0EpPNIlYmN5UdS8egnt3
	JKniQ/mKxAx1fCW3rvThO96Rq4XB0mTcooxaygLbrvoOwLw+wIvB06XkdPXShvL3+weypdXzIge
	2lfgFg6xzm00dTxxDWNYYYPZqHklfqSEhuKXl7UPk9IBs/wF5kj89sqWcFV7CBbEeOM+mpJJzvA
	2HpkWxKtd8LpyLcoo7GMaHj/nZdQoqR5rly5g1RTqxNmABLxyrgG+olUr52Zv0IAXyTReX/LcKf
	r4GBYcB/bvrTnognnbwlSfPLZ2iTwTe0RDD0aIlZZcyvTavM=
X-Google-Smtp-Source: AGHT+IH5tX10ut+T1ZGHfOKMgTfbEMD14QCR1zLfxiENwUnYgycWdukVDL0Qd4OCiWO/3jKCOhc3wQ==
X-Received: by 2002:a5d:5849:0:b0:3a5:8934:4940 with SMTP id ffacd0b85a97d-3a8feb70269mr11891547f8f.50.1751294744244;
        Mon, 30 Jun 2025 07:45:44 -0700 (PDT)
Message-ID: 
Date: Mon, 30 Jun 2025 16:45:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 08/17] xen/riscv: add new p2m types and helper macros
 for type classification
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: 
 
 <8f45cffe-e2a2-46e3-8370-2b6b4c86dccf@suse.com>
 <13b80e15-9db9-427d-aaa2-c0389e4c248a@gmail.com>
 <6fafc0b4-cfea-4d67-bef6-4e40d1d3e743@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: <6fafc0b4-cfea-4d67-bef6-4e40d1d3e743@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 30.06.2025 16:38, Oleksii Kurochko wrote:
> On 6/30/25 4:33 PM, Oleksii Kurochko wrote:
>> On 6/26/25 4:59 PM, Jan Beulich wrote:
>>> On 10.06.2025 15:05, Oleksii Kurochko wrote:
>>>> --- a/xen/arch/riscv/include/asm/p2m.h
>>>> +++ b/xen/arch/riscv/include/asm/p2m.h
>>>> @@ -61,8 +61,28 @@ struct p2m_domain {
>>>>   typedef enum {
>>>>       p2m_invalid = 0,    /* Nothing mapped here */
>>>>       p2m_ram_rw,         /* Normal read/write domain RAM */
>>>> +    p2m_ram_ro,         /* Read-only; writes are silently dropped */
>>> As indicated before - this type should be added when the special handling that
>>> it requires is also introduced.
>> Perhaps, I missed that. I will drop this type for now.
>>
>>>> +    p2m_mmio_direct_dev,/* Read/write mapping of genuine Device MMIO area */
>>> What's the _dev suffix indicating here?
>> It indicates that it is device memory, probably, it isn't so necessary in case of RISC-V as
>> spec doesn't use such terminology. In RISC-V there is only available IO, NC. And we are
>> |using PTE_PBMT_IO for |p2m_mmio_direct_dev.
>>
>> Maybe it would be better just to rename s/p2m_mmio_direct_dev/p2m_mmio_direct_io.
> 
> I forgot that p2m_mmio_direct_dev is used by common code for dom0less code (handle_passthrough_prop())

That'll want abstracting out, I think. I don't view it as helpful to clutter
RISC-V (and later perhaps also PPC) with Arm-specific terminology.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 14:57:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 14:57:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1029177.1402928 (Exim 4.92)
	(envelope-from )
	id 1uWFwn-0004DN-Qi; Mon, 30 Jun 2025 14:57:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1029177.1402928; Mon, 30 Jun 2025 14: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 1uWFwn-0004DG-Mn; Mon, 30 Jun 2025 14:57:29 +0000
Received: by outflank-mailman (input) for mailman id 1029177;
 Mon, 30 Jun 2025 14: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 1uWFwm-0004DA-En
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 14:57:28 +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 89b5a7a3-55c2-11f0-a312-13f23c93f187;
 Mon, 30 Jun 2025 16:57:27 +0200 (CEST)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-4537fdec39fso6594355e9.0
 for ; Mon, 30 Jun 2025 07:57:27 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-74af55c8437sm9005737b3a.115.2025.06.30.07.57.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 30 Jun 2025 07:57:25 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 89b5a7a3-55c2-11f0-a312-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1751295446; x=1751900246; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=g8B+hmkltaIYtUZVBdXOxpt3b/8p2vdivHKfkTrc1Lc=;
        b=JMnHEFAM3DLFNMUHPmCQ+I1b/EqB6JPDt7r4oxz+GArI9r9rfbbXB5N+qItLd4OZGj
         evMb4EMfU4L+8l/ItsBF/VwNSRUkkcmslRzP/Q81Hs5MNFBp+fBHx8UqcmBpleSchwvx
         DkzYaCzSOUjacXiPaMsVC8YZVwdrmu1KzJHeKUW1q63fssp3+BQ8+fy+T4ogRtZzj5mX
         PMU94nRw5wyvI8beAj8iER/E0ZLAxYc+oih5/R4DaCDEVC6PjrI4kM4NRTlsVJDCsR8Q
         xv7W3bJ/oonZuQt0kBdpHCocvpJoRD9CcOUl5NUTxlv/nvdrbu/bhK1Y1OMX3d/4iMLB
         ePQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751295446; x=1751900246;
        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=g8B+hmkltaIYtUZVBdXOxpt3b/8p2vdivHKfkTrc1Lc=;
        b=suJTB9sjLQEa0lGsw7DEfMWK+gl+cOVWwkmoLfGsISWqLXiOVgYAEJ7g+x/D0HkYif
         +MVJdltcdFUBE3lRiNX+uurAZcWkoYXDOAuSifZJcrQIElXA47qj74yokPqLiwt1dPfo
         w8M5P+oj7fYyiO6JMvAdkW0OmA9L/fjJZeuyKLlJR0GDNwN+SHN1NZtamFLnOic9cRTj
         sJA4MZDpPHx2n/m+/fV9O7VqCbuaUPY+RgdTrSYZ/tKqO2gabblA87Kyhc/c+h7RYWsu
         /QJ6N4aHtf6bHD9ruDuoWOGNAjcmHPJWyaGVc9JU/KcOGoVt8NbyGiL3FAbzU6Qziyk6
         aumg==
X-Forwarded-Encrypted: i=1; AJvYcCV6+OOM5Ajs39IWfPZb3YmdMCgjvtXG6Bmv2ZxKRM0y5ngkopJy37Mj2IUEp2wV6vXbEA5XoRkAdEo=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz7e1PGDijSZ6SaOHYNQ3ifB+iqIuilhD1KGIkE8w0P85dOzLd6
	6zW+eChbmcOWYrC12CP6mznb2kBsMybdf6hoHmbVig20jiB7/BVYiXTf+Cj1Br0YVg==
X-Gm-Gg: ASbGncupiLI5dbD8ygiP8m7q1Y8VbRwclZ+zS6ojkWDHdTr5PylIMEIktps+JjJcdHv
	6BQAitMynYf1ajINJpOz9ae3qHZGz1ESVOA1/kyTt9aghP/1ZKkzmgV4oIqjPL+tDmTW+ML52Fb
	AUFknNhnwiBhfwRTPqBsDrfO2c1PSAvXSksHicJrVRNy/fYjYjEPbz71rbedeCCADOzNxXIYYIQ
	gKNpvgyhIW7c8wx64EDJRtq54QeuEqL8mEACR2qBUN3SBbW1ul4vURilCdhMj/y4IntyjSvzaa7
	OORk5bTWyZM/TQIRSfefK7TsfLEVeHNizTRpaclE3ndpHu2CgFBsRLkr+ApM4V7J9SCIhNE9dbe
	77c1EPp9SOL8fxtOSLUUKxrDlFeJxlindAnPKjkGYK8RHo6E=
X-Google-Smtp-Source: AGHT+IFqzqRQj6opO1qF3Q1TxzishyDuC4br6VjYS7F6eGp9/XwAOEbU5r2gJioxa8qqVjvuvJo2rQ==
X-Received: by 2002:a05:6000:21c7:b0:3a5:88cf:479c with SMTP id ffacd0b85a97d-3a8fe5b1d58mr7623353f8f.30.1751295446406;
        Mon, 30 Jun 2025 07:57:26 -0700 (PDT)
Message-ID: <51d7c5ac-cd02-4b5c-a2ac-0a673df38f56@suse.com>
Date: Mon, 30 Jun 2025 16:57:15 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 4/9] xen/riscv: aplic_init() implementation
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 ,
 Romain Caritey , 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 13.06.2025 17:48, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/aplic-priv.h
> @@ -0,0 +1,34 @@
> +/* SPDX-License-Identifier: MIT */
> +
> +/*
> + * xen/arch/riscv/aplic-priv.h
> + *
> + * Private part of aplic.h header.
> + *
> + * RISC-V Advanced Platform-Level Interrupt Controller support
> + *
> + * Copyright (c) Microchip.
> + * Copyright (c) Vates.
> + */
> +
> +#ifndef ASM_RISCV_PRIV_APLIC_H
> +#define ASM_RISCV_PRIV_APLIC_H
> +
> +#include 
> +
> +#include 
> +#include 
> +
> +struct aplic_priv {
> +    /* base physical address and size */

I'm sure I did ask for this before, and such a request really is meant to apply
globally: Please can you abide by the comment style set forth in ./CODING_STYLE.

> +static int __init cf_check aplic_init(void)
> +{
> +    dt_phandle imsic_phandle;
> +    const __be32 *prop;
> +    uint64_t size, paddr;
> +    const struct dt_device_node *imsic_node;
> +    const struct dt_device_node *node = aplic_info.node;
> +    int rc;
> +
> +    /* Check for associated imsic node */
> +    if ( !dt_property_read_u32(node, "msi-parent", &imsic_phandle) )
> +        panic("%s: IDC mode not supported\n", node->full_name);
> +
> +    imsic_node = dt_find_node_by_phandle(imsic_phandle);
> +    if ( !imsic_node )
> +        panic("%s: unable to find IMSIC node\n", node->full_name);
> +
> +    rc = imsic_init(imsic_node);
> +    if ( rc == IRQ_M_EXT )
> +        /* Machine mode imsic node, ignore this aplic node */
> +        return 0;
> +
> +    if ( rc )
> +        panic("%s: Failed to initialize IMSIC\n", node->full_name);
> +
> +    /* Find out number of interrupt sources */
> +    if ( !dt_property_read_u32(node, "riscv,num-sources",
> +                               &aplic_info.num_irqs) )
> +        panic("%s: failed to get number of interrupt sources\n",
> +              node->full_name);
> +
> +    if ( aplic_info.num_irqs > ARRAY_SIZE(aplic.regs->sourcecfg) )
> +        aplic_info.num_irqs = ARRAY_SIZE(aplic.regs->sourcecfg);
> +
> +    prop = dt_get_property(node, "reg", NULL);
> +    dt_get_range(&prop, node, &paddr, &size);
> +    if ( !paddr )
> +        panic("%s: first MMIO resource not found\n", node->full_name);
> +
> +    if ( !IS_ALIGNED(paddr, KB(4)) )
> +        panic("%s: paddr of memory-mapped control region should be 4Kb aligned:%#lx\n",
> +              __func__, paddr);
> +
> +    if ( !IS_ALIGNED(size, KB(4)) || (size < KB(16)) )
> +        panic("%s: memory-mapped control region should be a multiple of 4 KiB in size and the smallest valid control is 16Kb: %#lx\n",

The line having grown so long should have served as an indication to abbreviate the
text somewhat.

Also note the consmetic difference between this and the earlier message, as to a
blank (or not) after the latter colon. Please try to be consistent at least within
a patch / function / whatever other unit.

> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/aplic.h
> @@ -0,0 +1,64 @@
> +/* SPDX-License-Identifier: MIT */
> +
> +/*
> + * xen/arch/riscv/asm/include/aplic.h
> + *
> + * RISC-V Advanced Platform-Level Interrupt Controller support
> + *
> + * Copyright (c) Microchip.
> + */
> +
> +#ifndef ASM_RISCV_APLIC_H
> +#define ASM_RISCV_APLIC_H
> +
> +#include 
> +
> +#include 
> +
> +#define APLIC_DOMAINCFG_IE      BIT(8, U)
> +#define APLIC_DOMAINCFG_DM      BIT(2, U)
> +
> +struct aplic_regs {
> +    uint32_t domaincfg;
> +    uint32_t sourcecfg[1023];
> +    uint8_t _reserved1[3008];
> +
> +    uint32_t mmsiaddrcfg;
> +    uint32_t mmsiaddrcfgh;
> +    uint32_t smsiaddrcfg;
> +    uint32_t smsiaddrcfgh;
> +    uint8_t _reserved2[48];
> +
> +    uint32_t setip[32];
> +    uint8_t _reserved3[92];
> +
> +    uint32_t setipnum;
> +    uint8_t _reserved4[32];
> +
> +    uint32_t in_clrip[32];
> +    uint8_t _reserved5[92];
> +
> +    uint32_t clripnum;
> +    uint8_t _reserved6[32];
> +
> +    uint32_t setie[32];
> +    uint8_t _reserved7[92];
> +
> +    uint32_t setienum;
> +    uint8_t _reserved8[32];
> +
> +    uint32_t clrie[32];
> +    uint8_t _reserved9[92];
> +
> +    uint32_t clrienum;
> +    uint8_t _reserved10[32];
> +
> +    uint32_t setipnum_le;
> +    uint32_t setipnum_be;
> +    uint8_t _reserved11[4088];
> +
> +    uint32_t genmsi;
> +    uint32_t target[1023];
> +};

Each time I see this I wonder whether it wouldn't be helpful if, at least for
the non-reserved fields, there would be comments clarifying their hex offset.
That way it would be easier to (a) compare with the spec and (b) cross-check
the array dimensions used.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 14:59:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 14:59:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1029184.1402938 (Exim 4.92)
	(envelope-from )
	id 1uWFyv-0004lM-5K; Mon, 30 Jun 2025 14:59:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1029184.1402938; Mon, 30 Jun 2025 14:59: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 1uWFyv-0004lF-1o; Mon, 30 Jun 2025 14:59:41 +0000
Received: by outflank-mailman (input) for mailman id 1029184;
 Mon, 30 Jun 2025 14:59: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 1uWFyt-0004l9-AL
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 14:59:39 +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 d756a36c-55c2-11f0-b894-0df219b8e170;
 Mon, 30 Jun 2025 16:59:37 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a548a73ff2so4080851f8f.0
 for ; Mon, 30 Jun 2025 07:59:37 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-74af57f2770sm9520962b3a.167.2025.06.30.07.59.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 30 Jun 2025 07:59:36 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d756a36c-55c2-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1751295577; x=1751900377; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=oykwCydEbwnc4wF+hPt542csUxV4rVAvezWt5mUYJ1g=;
        b=TjMRluc8d1qRvkd+H2F2GcxCYLhTPYQrlhDaT/OcB4yoUccHUzuDzRtHRZoIw5/HUb
         OXASSZdOq2gFxCxrTdjfx5sZ3NqC9Zxgo46JguafC7+4CUC+iV9YMTRbxvrDKC6AtgSL
         gWdj/hgIfAOr4IkRvES+WpQoAeaMb/HvDN/eSFSo5Ds66yHrQ6J1eeAZwxEssVXiXFZ7
         kH6VaQKxXvByEl/x7mRBySSfNFXf7GK5FFSw9i2D2wDqkgjEEvTsdYzkbLlyQhFUVRNa
         OMbtROWeeQXd9xSnlfcXeCHWq0/FEfgSz1rMvzTO0uIyUAp5U55mGJMtaDlpO24B4a3l
         qAmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751295577; x=1751900377;
        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=oykwCydEbwnc4wF+hPt542csUxV4rVAvezWt5mUYJ1g=;
        b=LRztYyy5jtWJuFqfQeETM7CfmB9BhzuVgBMpVSd/Au3jeBp6JyIbRDd/glc+cb6klF
         6gcP/nEJ3btyKDMIFN8pRyVX5lk3Jq+MkuO8ztQOodzFhdXgB0DFGIuUTSo9GKznceSK
         kFXzLaZrlK1T4P5jlnb2NgEn9ELuXRrAb6Nqr3w6hOev5lzy/Z8wcL61B3fLkRty8wpM
         QLo+R/YN2Wpd3bazCP28lw5V8wNTDVQL/CBB1Z80gD0BA+Th6BUXYXJdZQ5v9INAIdOJ
         9KAQqXcD/7Kk/KoWeOWnQaCXn9nVPTqxtHqWxWIsBF7MwOnE3JrZQirA/ncEaMiXLrGG
         i2WA==
X-Forwarded-Encrypted: i=1; AJvYcCW17osamQ7xuyyCoEWlz4wssckgwEfstQAoxjxxwmpqQSTl34mZ0eR0uRZ3Bx2OOipZYxIuo7MYRns=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxb5FJ9VO4XvgQgkN0Fjq/kh/3Way7MKHShcLBO04SD6h2EC24A
	y9sD1157aNqSOQ60TByUhaE1OZYia6/FBLPuZobE9PsH2zKNrDop3VPPi7ioft9s5A==
X-Gm-Gg: ASbGncvAeACwg94wpfjGNFZpuOv4JTUIVk0ATVwxn6F8TFaZKA4EC+uZWUiCIEmUU5N
	hOHmThhJgoSXX+CETNNKsEWh+snd5iz4hdhY/yvRYb4Su5+Plx1sBh8uNR5NL5TlmWV3pzmdfKH
	Z58xYii6gdz0thoKjMPUVFI7wBnKCEXT5Mnw064ulcfmId9x1luQilvuR8EBFj6AyIqqHswBpNa
	bdv71ZOsFVMn9ePMx6P3Xm1U2R7EMPqfMvtOWAZx4be7CC49OB5sFrwiFmGFBiyzCB0ymUq9ejh
	KkjytLsVYxmB/ToxCM/Rjn4dJCLX7npQf0wgpisWqvrXpv8EBoeJwrsNq+VVGBhpuSrZm4cO5Zk
	afbf16vqGeYUkj9W+VDPcaeUmt5g57auHT1vTSuH4uW69OLE=
X-Google-Smtp-Source: AGHT+IE5ZkWvG9JfWkqjyGK6DaFEKYkVG4Zkjo+WVgEOS6/p8cuRYHgfDTgDusYkFhtr0fWYzkSu9g==
X-Received: by 2002:a05:6000:dc5:b0:3a4:ea9a:1656 with SMTP id ffacd0b85a97d-3a90d0d6d1cmr9164228f8f.10.1751295576642;
        Mon, 30 Jun 2025 07:59:36 -0700 (PDT)
Message-ID: 
Date: Mon, 30 Jun 2025 16:59:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 6/9] xen/riscv: implementation of aplic and imsic
 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 ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <47ca7a83e6320547378bb8bc690f5309a6eaf53c.1749825782.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: <47ca7a83e6320547378bb8bc690f5309a6eaf53c.1749825782.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.06.2025 17:48, Oleksii Kurochko wrote:
> Introduce interrupt controller descriptor for host APLIC to describe
> the low-lovel hardare. It includes implementation of the following functions:
>  - aplic_irq_startup()
>  - aplic_irq_enable()
>  - aplic_irq_disable()
>  - aplic_set_irq_affinity()
> 
> As APLIC is used in MSI mode it requires to enable/disable interrupts not
> only for APLIC but also for IMSIC. Thereby for the purpose of
> aplic_irq_{enable,disable}() it is introduced imsic_irq_{enable,disable)().
> 
> For the purpose of aplic_set_irq_affinity() aplic_get_cpu_from_mask() is
> introduced to get hart id.
> 
> Also, introduce additional interrupt controller h/w operations and
> host_irq_type for APLIC:
>  - aplic_host_irq_type
> 
> Patch is based on the code from [1].
> 
> [1] https://gitlab.com/xen-project/people/olkur/xen/-/commit/7390e2365828b83e27ead56b03114a56e3699dd5
> 
> Co-developed-by: Romain Caritey 
> Signed-off-by: Oleksii Kurochko 
> Acked-by: Jan Beulich 

Just to mention, irrespective of this tag there's at least one instance of
comment style to still correct here (along the lines of what I just said
in reply to one of the earlier patches).

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 15:02:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 15:02:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1029192.1402947 (Exim 4.92)
	(envelope-from )
	id 1uWG1p-0006Vm-LG; Mon, 30 Jun 2025 15:02:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1029192.1402947; Mon, 30 Jun 2025 15: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 1uWG1p-0006Vf-I9; Mon, 30 Jun 2025 15:02:41 +0000
Received: by outflank-mailman (input) for mailman id 1029192;
 Mon, 30 Jun 2025 15: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 1uWG1p-0006VZ-4F
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 15:02:41 +0000
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com
 [2a00:1450:4864:20::133])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4426c90e-55c3-11f0-a312-13f23c93f187;
 Mon, 30 Jun 2025 17:02:39 +0200 (CEST)
Received: by mail-lf1-x133.google.com with SMTP id
 2adb3069b0e04-553e5df44f8so1860368e87.3
 for ; Mon, 30 Jun 2025 08:02:39 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-453823c3a96sm167963555e9.35.2025.06.30.08.02.37
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 30 Jun 2025 08:02:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4426c90e-55c3-11f0-a312-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1751295759; x=1751900559; 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=k7YoGUf03nNHc23pGqIpN0E8oGD/61oc/rFi2yceFM4=;
        b=vWIETvTvB6WlWeuG+WNZ5AaReAoTQVY/zV/IcSHyzCCaVowj+mDO61sj9oqCccm3a2
         Bljrpn5Nbzj2ZZ0Swr2JAdaM8X8oc8FrhLbbNYCEjsWMThE+TuRLE+9KtG1kVRrpzY8e
         paMrT92TzmICO/z1FnB0SAH5DzEUqNALT+HSo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751295759; x=1751900559;
        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=k7YoGUf03nNHc23pGqIpN0E8oGD/61oc/rFi2yceFM4=;
        b=XjNGelE0yyn3jTMpkJsz97zevv7FNo5HldnVPe2+cgwF4YUTrM2Magt+K6IZIcZfLx
         aXZDsuUWFVe90Jqmui0r69HU4tsyXbYU1jw5CvHhw3au2R/Zi+lLzvUCXWLF3Z5avqLH
         59/jskirbe+Q9LUbfn5au+FnyvPJQBmkWQ+XFrPDrChuF+JEgORxxitVeaa40yySYq/N
         nVYQ/5fdCIuEW4AoHm3IvtJOOACUsihVcP+AcT9RGflbvsIxyKCnrgE87p/XQNxBhq7D
         05wEuCV6+fUZOuHzD2dVcsjC2uCL6ZeoNFAHRJZUJogFuMuYNwKTtorJAID8Vc644l56
         xDow==
X-Gm-Message-State: AOJu0YyU/wJh7nYyv6NJcUsJwg7Dm8By/VsE0qTROPEqw8qaZqt50ZDZ
	9AWmzCCKWZtimqFgfL6QXm8DjqrOyl5kAZBpgBXalvEYG+arn0BLnF9yKOwjdw6+VZk=
X-Gm-Gg: ASbGnctXq6ggyqZ1LdVs2ipU6MxHQf6NDgRl6ha20n3OGOwGiM9SymR4b1DP0RiUrh+
	qBC44MuR7NqFZ5SWDLWsiHO0M3ilHYvKX91PxKgcYd8/VxwoyCuwmbERTYPLmQXP182ktQrLEhH
	58d/W+i639541oa9tTNplnjJ+Z7j7CLUWMv1trWhhSG7cwnLLSnaFvPe2dJdfGY/g5pOYq2crhL
	MEejkI6aWpeVtFIeohrDncQP7vtLCoIZEAO7W6GQMboFUnxG5mgFNPaa5E+222Ygg4G4WkLtsBZ
	SiqAoWNe/KSkSHTxlaloSnbW2SeWv2QcABZJadIH4Ogbnfu6I3tamMgsY0lCBwSe5mGnWvxymkD
	HeBa5GjT1Vs98tc+VXl/UDcAGwZceyA==
X-Google-Smtp-Source: AGHT+IE6PyEu0Gpdyx7EYWpT7BLmEUCICztHujwP+jgLOIL2s9BPdMnpmd1HQR6jANUNchcOgiQ+EA==
X-Received: by 2002:a05:6512:ba1:b0:553:3028:75bd with SMTP id 2adb3069b0e04-5550b8d01edmr4031983e87.49.1751295758256;
        Mon, 30 Jun 2025 08:02:38 -0700 (PDT)
Date: Mon, 30 Jun 2025 17:02:36 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Stefano Stabellini 
Cc: xen-devel@lists.xenproject.org, Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Bertrand Marquis ,
	Volodymyr Babchuk ,
	Shawn Anastasio ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Oleksii Kurochko ,
	Community Manager 
Subject: Re: [PATCH v2 0/8] pdx: introduce a new compression algorithm
Message-ID: 
References: <20250620111130.29057-1-roger.pau@citrix.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 

On Fri, Jun 27, 2025 at 07:08:29PM -0700, Stefano Stabellini wrote:
> Hi Roger,
> 
> We have an ARM board with the following memory layout:
> 
> 0x0-0x80000000, 0, 2G
> 0x800000000,0x880000000, 32GB, 2G
> 0x50000000000-0x50080000000 5T, 2GB 
> 0x60000000000-0x60080000000 6T, 2GB 
> 0x70000000000-0x70080000000 7T, 2GB 

With the current PDX mask compression you could compress 4bits AFAICT.

> It looks like your PDX series is exactly what we need.  However, I tried
> to use it and it doesn't seem to be hooked properly on ARM yet. I spent
> some time trying to fix it but I was unsuccessful.

Hm, weird.  It shouldn't need any special hooking, unless assumptions
about the existing PDX mask compression have leaked into ARM code.

> As far as I can tell the following functions need to be adjusted but I
> am not sure the list is comprehensive:
> 
> xen/arch/arm/include/asm/mmu/mm.h:maddr_to_virt

At least for CONFIG_ARM_64 this seems to be implemented correctly, as
it's using maddr_to_directmapoff() which should have the correct
translation between paddr -> directmap virt.

Also given the memory map above the adjustments done in ARM to remove
any initial memory map offset should be no-ops, since I expect
base_mfn == 0 in setup_directmap_mappings() in that particular case,
and then directmap_mfn_start = directmap_base_pdx = 0 and
directmap_virt_start = DIRECTMAP_VIRT_START.  FWIW, if ARM uses offset
compression the special casing about removing the initial gap can be
removed, as the compression should already take care of that.

> xen/arch/arm/mmu/mm.c:setup_frametable_mappings
> xen/arch/arm/setup.c:init_pdx

I've attempted to adjust init_pdx() myself so it works with the new
generic PDX compression setup, it seemed to work fine on the CI, but I
don't have any real ARM machines to test myself.

Is there a way I could reproduce the issue(s) you are seeing with
QEMU?

I'm already working on v3, as this version implementation of
mfn_valid() is buggy.  Maybe that's what you are hitting?

Regards, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 15:14:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 15:14:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1029199.1402959 (Exim 4.92)
	(envelope-from )
	id 1uWGCn-0008If-Ki; Mon, 30 Jun 2025 15:14:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1029199.1402959; Mon, 30 Jun 2025 15: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 1uWGCn-0008IY-GE; Mon, 30 Jun 2025 15:14:01 +0000
Received: by outflank-mailman (input) for mailman id 1029199;
 Mon, 30 Jun 2025 15: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 1uWGCm-0008IS-Cv
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 15:14:00 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d31ba59a-55c4-11f0-b894-0df219b8e170;
 Mon, 30 Jun 2025 17:13:49 +0200 (CEST)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-60c9d8a16e5so4939426a12.0
 for ; Mon, 30 Jun 2025 08:13:49 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-60c82908297sm5923452a12.26.2025.06.30.08.13.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 30 Jun 2025 08:13:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d31ba59a-55c4-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1751296429; x=1751901229; 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=URZGSaU+VVA5WNhzpeNfLfLA+JWWZpuqgmWNLBiC51I=;
        b=G3B1ZTheQHsG1LWovi/zwq686j5XZly274R37sFAwVOko2mH3qkdAHe5n5QrpyKaZ9
         NC6PFTzNw2i5b/8+qeAZRHBYSx73kBs3wBgTV/LytXteewR8QRqqfS2tfLS9oR3zDLjN
         6GggrkxRdj+7YjbPhq+dKAadpUMoNLNrieyFSJfV6yiok4QVmBJcP91RPfZxCpKuh0ee
         RbE2QFHwt0TB5o3fG23k5Y6KifRhu6oxnQn8ZvVc7CT+jLq3GHXiI+E+kNOl6LwFepYy
         KZaq3cq7txoMWY+BrFacg4Y1f9j2hCBMpsoi59AR5Y+b8PaAecVzgmiY8c5LrDqBpgyB
         U9Xw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751296429; x=1751901229;
        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=URZGSaU+VVA5WNhzpeNfLfLA+JWWZpuqgmWNLBiC51I=;
        b=eLrvsi8gJgfCnL3rH+zQp9D0kYbkFe1YtWdEhClljz8eKwLP1G+0jsRPcY3kPA0sIh
         7bPuARoyKWSaBkq1GRqde/fSWV64FAP2DD4tgSwHvLvYBX3EJkyYfQbc+zhqqcpZtKtE
         lf3HTY0o+xmSDTHTBsLIXZUePJPDo+jLPfnwQVsbI5XANpNCL98cQJi8WQYwZLXucYMP
         smc3kIr9JY4lOpA1ksjNWN9PXX05QgKYjHeV5P7PnPH6BPs9AzjHQYZ1ea61RaraJGb1
         VBvC2+Fquo+iZWQOjcxNo2udR+iSNC/rBV8MmybL/hidtn5iVzDx6xNe1S50xzz9D1yx
         51Bw==
X-Forwarded-Encrypted: i=1; AJvYcCVk4F1OVcbapF4jEHNpYznHgw2mb5k445nlJliX4XU79dPyHJ0o+vksi92iwgHytjzfYVQNHuA/gy4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxFpWxBTNqjb4F79/cbI1p+x5YvXU/Hkhx6nyyX7d+ulGu7iC8d
	u3kX3wjeljQ269QST/9YQ8djXbpgv8ME/pwYLI/tzyNLzy4riOoZe94G
X-Gm-Gg: ASbGncsy2ULSep5mWuyMLhOnTEpHaHcB4/lOJF/vQclGzjeoKILvHAtgeOK6Mv+vsqf
	YoOHvijcfWGQquMyIivu9frGZm+YekRhL35hxeuHVHHtp9HSOCQLXV7VknnHSsLneLi7v5AtOlC
	5TCoUIMZSpOgDOTt4jsoNkVa1BbHUre2YdDXxsN6OhZ7LgZRoIHhELpWWLZM/iC4Te4k+DY9bkA
	oAUQZnt/uMaOC/OHH2swzWQLP96XHiQ2bj8IhnboqnhTLFoDvY5u1zLYP8vKsNx8z5tgnWuONHi
	MyRoTC/0dxiM56gknmVGpRjOhYRK/oqvs3CWR6BzTiojPD4W8XCeaaZzLjiL1iFSJUViQrbh7oE
	2UZLSxZenhjwlyjPLtCxFkTlRHhuQHRXrmE0=
X-Google-Smtp-Source: AGHT+IHMoZcQ/FeV4aJt3J88B1Iv5+49GOtX0BJm+1eKjCSYz8NPnNG39ywUdPpPKZ0TvwFpTDQapw==
X-Received: by 2002:a05:6402:2801:b0:609:d685:e831 with SMTP id 4fb4d7f45d1cf-60c88b1fbacmr11762180a12.12.1751296428323;
        Mon, 30 Jun 2025 08:13:48 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------wh6BblbLqUIZWDnFi0rf3BvZ"
Message-ID: <4b5c2a81-947b-4e2f-bb89-a4e776548e52@gmail.com>
Date: Mon, 30 Jun 2025 17:13:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 08/17] xen/riscv: add new p2m types and helper macros
 for type classification
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: 
 
 <8f45cffe-e2a2-46e3-8370-2b6b4c86dccf@suse.com>
 <13b80e15-9db9-427d-aaa2-c0389e4c248a@gmail.com>
 <2ebfaa8c-e0bb-4c5b-89e1-48d309ee4989@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <2ebfaa8c-e0bb-4c5b-89e1-48d309ee4989@suse.com>

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


On 6/30/25 4:42 PM, Jan Beulich wrote:
> On 30.06.2025 16:33, Oleksii Kurochko wrote:
>> On 6/26/25 4:59 PM, Jan Beulich wrote:
>>> On 10.06.2025 15:05, Oleksii Kurochko wrote:
>>>> --- a/xen/arch/riscv/include/asm/p2m.h
>>>> +++ b/xen/arch/riscv/include/asm/p2m.h
>>>> @@ -61,8 +61,28 @@ struct p2m_domain {
>>>>    typedef enum {
>>>>        p2m_invalid = 0,    /* Nothing mapped here */
>>>>        p2m_ram_rw,         /* Normal read/write domain RAM */
>>>> +    p2m_ram_ro,         /* Read-only; writes are silently dropped */
>>> As indicated before - this type should be added when the special handling that
>>> it requires is also introduced.
>> Perhaps, I missed that. I will drop this type for now.
>>
>>>> +    p2m_mmio_direct_dev,/* Read/write mapping of genuine Device MMIO area */
>>> What's the _dev suffix indicating here?
>> It indicates that it is device memory, probably, it isn't so necessary in case of RISC-V as
>> spec doesn't use such terminology. In RISC-V there is only available IO, NC. And we are
>> |using PTE_PBMT_IO for |p2m_mmio_direct_dev.
>>
>> Maybe it would be better just to rename s/p2m_mmio_direct_dev/p2m_mmio_direct_io.
> And what would the _io suffix indicate, beyond what "mmio" already indicates?

Just that PBMT_IO will be used for device memory and not PBMT_NC.

~ Oleksii

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



  
    
  
  
    

    
    
    
    
    On 6/30/25 4:42 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 30.06.2025 16:33, Oleksii Kurochko wrote:

    
      
    
        
    On 6/26/25 4:59 PM, Jan Beulich wrote:

    
        
    
          
    On 10.06.2025 15:05, Oleksii Kurochko wrote:

    
          
    
            
    --- a/xen/arch/riscv/include/asm/p2m.h
+++ b/xen/arch/riscv/include/asm/p2m.h
@@ -61,8 +61,28 @@ struct p2m_domain {
  typedef enum {
      p2m_invalid = 0,    /* Nothing mapped here */
      p2m_ram_rw,         /* Normal read/write domain RAM */
+    p2m_ram_ro,         /* Read-only; writes are silently dropped */

    
          
    
          
    As indicated before - this type should be added when the special handling that
it requires is also introduced.

    
        
    
        
    Perhaps, I missed that. I will drop this type for now.


    
        
    
          
    
          
    
            
    +    p2m_mmio_direct_dev,/* Read/write mapping of genuine Device MMIO area */

    
          
    
          
    What's the _dev suffix indicating here?

    
        
    
        
    It indicates that it is device memory, probably, it isn't so necessary in case of RISC-V as
spec doesn't use such terminology. In RISC-V there is only available IO, NC. And we are
|using PTE_PBMT_IO for |p2m_mmio_direct_dev.

Maybe it would be better just to rename s/p2m_mmio_direct_dev/p2m_mmio_direct_io.

    
      
    
      
    And what would the _io suffix indicate, beyond what "mmio" already indicates?
    
    
    
    
    Just that PBMT_IO will be used for device memory and not PBMT_NC.

~ Oleksii

    
  


--------------wh6BblbLqUIZWDnFi0rf3BvZ--


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 15:22:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 15:22:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1029205.1402967 (Exim 4.92)
	(envelope-from )
	id 1uWGLI-0001ds-Cs; Mon, 30 Jun 2025 15:22:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1029205.1402967; Mon, 30 Jun 2025 15:22:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uWGLI-0001dl-AN; Mon, 30 Jun 2025 15:22:48 +0000
Received: by outflank-mailman (input) for mailman id 1029205;
 Mon, 30 Jun 2025 15:22: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 1uWGLH-0001da-La
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 15:22:47 +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 123d95fa-55c6-11f0-b894-0df219b8e170;
 Mon, 30 Jun 2025 17:22:44 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3a522224582so2385890f8f.3
 for ; Mon, 30 Jun 2025 08:22:44 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b34e31bea22sm8333249a12.38.2025.06.30.08.22.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 30 Jun 2025 08:22:43 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 123d95fa-55c6-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1751296964; x=1751901764; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=uaj4gs5EI0MgSknyxhjQiJCxQkzkS215TkkNr7OAfZs=;
        b=WA3LR+2G4rw2sHCYVEAyt++ApXPHb24fCAclOpMyZ/dWklOi31HZZf4UibGazrGQUH
         Fe5gRfmrM9d17tiJpa0egWzvPfEsVImZQduM+mVgk8qhgsLZJQAC5GQqJLnp7llSjaYi
         U0FhL+DA8HRdzwM1KCbVpI/P6kda3InewhGLsBFC/47Sg0bzqeRzJPeTsQaxIzh01vOr
         exJmv9uDfCYxsfkfjswFwleR6e37X2yBpnzLw2Pjo9HsycDs44qtBYFspuPOQ2mL3mT3
         JP5vxewEN/JMHsX39FXC3EJFBGkK24YjgCWTMK2R6wTQ7hIMCkmbMOCNs3M9iTGsS2Wv
         0zhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751296964; x=1751901764;
        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=uaj4gs5EI0MgSknyxhjQiJCxQkzkS215TkkNr7OAfZs=;
        b=Il2UHwT9h7mvuKXm6N7F9ea7VO2ZPKoVtx6bOLHenNv4MoIQY9eV4EPQCedqZgRRgQ
         Nifr+uVKl/pEkzz2tdNudPUh9dS8I7tx0qf/SMO3VvfynmIsmbQxu4C1F0d6TFZtJVey
         vRTSFt6kdoVtR2rGXjb3eUJVS/HWqksqo1npbITs1aGIzGtKs9L45ZZvTf60K9xi82GY
         HUP59s8QLy/gRJsMyMbMb1f4P0qt1jhX1mq3QbShHxWbO1MrTwL9LpGWXoISxHjpb9+C
         FyX/7a4p+8nJfoizvJiw9J8kJFW9NGKjVnbeBbCBsPuklv4TxBsiryNfKeIrMQPRgkRQ
         mVVg==
X-Forwarded-Encrypted: i=1; AJvYcCUSYJmVKu9eLp+yzsvjd/I8XEUjEmhjR8UDPcUSA4hnyJZsp1R/MxipK3jM9UGCUboL1bktWGWpQ9Y=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwFX/HxOargkTuUPlsQ7Ngh42UU5mDcpYPS64/0cddetcjEInzJ
	tDrI7v+LdKM7MmQ6MEL7Uc25iRszarx4P+mFSeMFZHW/aepLMz+IFgNxum/r3LGKQg==
X-Gm-Gg: ASbGncsgNKSYj6Wl2+UCFENZs7gCyu9ca01R7qDRtazsOXgmok9Z15+IfVioFCTT3pN
	1gMQEVEk/WwYtoU5ng4+3+2by9N8IuoAVzoceIIcLnWpkLEd9PBEEcjW1IU4t7Zp8Pmmqhr0foP
	JDkzgRoT0MH6LY7Jj86n9EzbOvhwH3IBz7vOzKM5twnTPjUcqolJtkyjomLyvlcKj+J1bzImzre
	w+aQeNmOTlzOYl+UdO108dFxSs1y+zqR6ryTdL+3WuDa6EVyH2LyGr0lYgxx/ic2nijj4VOEDN3
	L3l+mIYgcDnsy+Ifc+btiQoowfiXqddyrycJj4kpKMzVKexUFEYaBh6nWIjgHLRF5N2af2ONCIM
	DZq/o/+frtnAh/7VgUE7T9Wb7c3IrIaubhiys1a5faTB/XwM=
X-Google-Smtp-Source: AGHT+IHquY/zmuNVnI+mXBxHnpIHynLW/wDtxwghqFNPerrsyxIucaOq69ZKBEgSLmA0DYgKZYReCQ==
X-Received: by 2002:adf:b649:0:b0:3a0:7d27:f076 with SMTP id ffacd0b85a97d-3a8fdb29f1emr11754843f8f.2.1751296963902;
        Mon, 30 Jun 2025 08:22:43 -0700 (PDT)
Message-ID: <9c89ead3-7577-46f2-acc2-6dd8d793ab89@suse.com>
Date: Mon, 30 Jun 2025 17:22:32 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 06/17] xen/riscv: add root page table allocation
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: 
 <76675ddb7517e4cceb63472c94944046b255da01.1749555949.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: <76675ddb7517e4cceb63472c94944046b255da01.1749555949.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.06.2025 15:05, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/include/asm/p2m.h
> +++ b/xen/arch/riscv/include/asm/p2m.h
> @@ -26,6 +26,12 @@ struct p2m_domain {
>      /* Pages used to construct the p2m */
>      struct page_list_head pages;
>  
> +    /* The root of the p2m tree. May be concatenated */
> +    struct page_info *root;
> +
> +    /* Address Translation Table for the p2m */
> +    paddr_t hgatp;

Does this really need holding in a struct field? Can't is be re-created at
any time from "root" above? And such re-creation is apparently infrequent,
if happening at all after initial allocation. (But of course I don't know
what future patches of yours will bring.) This is even more so if ...

> --- a/xen/arch/riscv/include/asm/riscv_encoding.h
> +++ b/xen/arch/riscv/include/asm/riscv_encoding.h
> @@ -133,11 +133,13 @@
>  #define HGATP_MODE_SV48X4		_UL(9)
>  
>  #define HGATP32_MODE_SHIFT		31
> +#define HGATP32_MODE_MASK		_UL(0x80000000)
>  #define HGATP32_VMID_SHIFT		22
>  #define HGATP32_VMID_MASK		_UL(0x1FC00000)
>  #define HGATP32_PPN			_UL(0x003FFFFF)
>  
>  #define HGATP64_MODE_SHIFT		60
> +#define HGATP64_MODE_MASK		_ULL(0xF000000000000000)
>  #define HGATP64_VMID_SHIFT		44
>  #define HGATP64_VMID_MASK		_ULL(0x03FFF00000000000)

... VMID management is going to change as previously discussed, at which
point the value to put in hgatp will need (partly) re-calculating at certain
points anyway.

> --- a/xen/arch/riscv/p2m.c
> +++ b/xen/arch/riscv/p2m.c
> @@ -41,6 +41,91 @@ void p2m_write_unlock(struct p2m_domain *p2m)
>      write_unlock(&p2m->lock);
>  }
>  
> +static void clear_and_clean_page(struct page_info *page)
> +{
> +    clean_dcache_va_range(page, PAGE_SIZE);
> +    clear_domain_page(page_to_mfn(page));
> +}

A function of this name can, imo, only clear and then clean. Question is why
it's the other way around, and what the underlying requirement is for the
cleaning part to be there in the first place. Maybe that's obvious for a
RISC-V person, but it's entirely non-obvious to me (Arm being different in
this regard because of running with caches disabled at certain points in
time).

> +static struct page_info *p2m_allocate_root(struct domain *d)
> +{
> +    struct page_info *page;
> +    unsigned int order = get_order_from_bytes(KB(16));

While better than a hard-coded order of 2, this still is lacking. Is there
a reason there can't be a suitable manifest constant in the header?

> +    unsigned int nr_pages = _AC(1,U) << order;

Nit (style): Missing blank after comma.

> +    /* Return back nr_pages necessary for p2m root table. */
> +
> +    if ( ACCESS_ONCE(d->arch.paging.p2m_total_pages) < nr_pages )
> +        panic("Specify more xen,domain-p2m-mem-mb\n");

You shouldn't panic() in anything involved in domain creation. You want to
return NULL in this case.

Further, to me the use of "more" looks misleading here. Do you perhaps mean
"larger" or "bigger"?

This also looks to be happening without any lock held. If that's intentional,
I think the "why" wants clarifying in a code comment.

> +    for ( unsigned int i = 0; i < nr_pages; i++ )
> +    {
> +        /* Return memory to domheap. */
> +        page = page_list_remove_head(&d->arch.paging.p2m_freelist);
> +        if( page )
> +        {
> +            ACCESS_ONCE(d->arch.paging.p2m_total_pages)--;
> +            free_domheap_page(page);
> +        }
> +        else
> +        {
> +            printk(XENLOG_ERR
> +                   "Failed to free P2M pages, P2M freelist is empty.\n");
> +            return NULL;
> +        }
> +    }

The reason for doing this may also want to be put in a comment.

> +    /* Allocate memory for p2m root table. */
> +
> +    /*
> +     * As mentioned in the Priviliged Architecture Spec (version 20240411)
> +     * As explained in Section 18.5.1, for the paged virtual-memory schemes

The first sentence didn't finish when the 2nd starts. Is there a piece missing?
Do the two sentences want to be joined together?

> +static unsigned long hgatp_from_page(struct p2m_domain *p2m)

Function name and parameter type/name don't fit together.

> +{
> +    struct page_info *p2m_root_page = p2m->root;

As always: pointer-to-const wherever possible, please. But: Is this local
variable really useful to have?

> +    unsigned long ppn;
> +    unsigned long hgatp_mode;
> +
> +    ppn = PFN_DOWN(page_to_maddr(p2m_root_page)) & HGATP_PPN;
> +
> +#if RV_STAGE1_MODE == SATP_MODE_SV39
> +    hgatp_mode = HGATP_MODE_SV39X4;
> +#elif RV_STAGE1_MODE == SATP_MODE_SV48
> +    hgatp_mode = HGATP_MODE_SV48X4;
> +#else
> +#   error "add HGATP_MODE"
> +#endif
> +
> +    return ppn | MASK_INSR(p2m->vmid, HGATP_VMID_MASK) |
> +           MASK_INSR(hgatp_mode, HGATP_MODE_MASK);
> +}
> +
> +static int p2m_alloc_root_table(struct domain *d)

As indicated earlier, in a wider context - this is a good candidate where
the caller rather wants to pass struct p2m_domain *. Once you get variations
on P2Ms (like x86'es altp2m or nestedp2m, the domain won't be meaningful
here to know which P2M to allocate the root for.

> +{
> +    struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +
> +    p2m->root = p2m_allocate_root(d);
> +    if ( !p2m->root )
> +        return -ENOMEM;
> +
> +    p2m->hgatp = hgatp_from_page(p2m);
> +
> +    return 0;
> +}
> +
>  static spinlock_t vmid_alloc_lock = SPIN_LOCK_UNLOCKED;
>  
>  /*
> @@ -228,5 +313,14 @@ int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
>          }
>      }
>  
> +    /*
> +    * First, wait for the p2m pool to be initialized. Then allocate the root

Why "wait"? There's waiting here.

> +    * table so that the necessary pages can be returned from the p2m pool,
> +    * since the root table must be allocated using alloc_domheap_pages(...)
> +    * to meet its specific requirements.
> +    */
> +    if ( !d->arch.p2m.root )

Aren't you open-coding p2m_get_hostp2m() here?

Jan

> +        p2m_alloc_root_table(d);
> +
>      return 0;
>  }



From xen-devel-bounces@lists.xenproject.org Mon Jun 30 15:27:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 15:27:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1029211.1402977 (Exim 4.92)
	(envelope-from )
	id 1uWGQ0-0002Cr-UB; Mon, 30 Jun 2025 15:27:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1029211.1402977; Mon, 30 Jun 2025 15:27: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 1uWGQ0-0002Ck-RY; Mon, 30 Jun 2025 15:27:40 +0000
Received: by outflank-mailman (input) for mailman id 1029211;
 Mon, 30 Jun 2025 15:27: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 1uWGPz-0002Ce-UM
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 15:27:39 +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 c0df0f64-55c6-11f0-b894-0df219b8e170;
 Mon, 30 Jun 2025 17:27:37 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3a536ecbf6fso2656930f8f.2
 for ; Mon, 30 Jun 2025 08:27:37 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23acb3c5a8csm84911635ad.223.2025.06.30.08.27.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 30 Jun 2025 08:27:36 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c0df0f64-55c6-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1751297257; x=1751902057; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=gdgBz53yUVWzqac2JXg0IjomNn13uCYwlDTXx52QPGw=;
        b=IWK1LhkZe1eAMil2n+5fRDb/p3ooBlgWNa+iHU9FpGPtlMQFZw9wreDexb/XQ0+Gki
         UqUG2boXme4YiV/KunsVne8TBPAHKiNdgFlAx+2/LTWXUZnFEsUaziMjuPgfxvC5cTqu
         XapmlHM9r5GVMwAxeTCaq8B+rsINrG8Pu3ixqm8n0ig34PLk5kytzc3vJt9gBbC+Z3Dc
         OZvUiG2/nGP+njgBxYI6ScrZuLdqc2FvF1q4KVfAwU939H8NUkcflDixYKuwRw8iSOSf
         M/O6mWvm4GozzyhXBijDP2iCFbFKrnHjCttLpI1BtPuCSTbyu7vgBQHv5xeX1AETEZOj
         0QCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751297257; x=1751902057;
        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=gdgBz53yUVWzqac2JXg0IjomNn13uCYwlDTXx52QPGw=;
        b=su127IUWRiZGAfNj+ENsLanFkk8gkK8QUjnjkcQzNMqoJ3fyAVT/x2Rway2URIBaw3
         Ef/N9+xWQVLbP8CbnPmh2dFnd7CGWjk+hn/Z0ARwCq7PHO6UZIdJ/Nszpa7kBrsQ8J6m
         7MZ9anvyXktTxpjEY7ko4stVGsGcaE5vNWqKQYUSjBl1b3EQEMKct5DHSVJvpyEpG1n1
         dXHquuiehaH3gIHkZMGZpSMFGNRhgLKqkXYM48h/cfXJchcFAH3nv5mrs7KnbJyRpV65
         /y0yxrzQSOCGq4gDYFT/DNlJx7NJb7BsIUSRQSyIxbAbUfurr5qVRXjhJzzKG2GMIWhp
         ry5w==
X-Forwarded-Encrypted: i=1; AJvYcCXwtNWe1q88LAIRNcXccifHtiQe0Tgwabt1YssEzAcGD3WQ26LwHg935s319QYb9ISosa9F5Nt5h2M=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz9OFaLe/lAZ3gmQTO5wokRvYGtTrHtlztSuHjm27jj6HsJrQMV
	LMkJompUQM0aU12BnxuQtR+GrtmI/mZIJoDwV4qnM/rsSTzUb5+oDCPD/FSrxT/6Lw==
X-Gm-Gg: ASbGncvDuQYd1tov16VbijLRJzMENbLGKRvuT0WXw+r5rBp1w3F1oSTA3yuDOC+qGXk
	bjqulm+wnYx7NUnzPANYvxhirdL+ENsGr/jYPhc6zmh/BxSirYNdhBY+gUcX9RmAxlDy8nBl0NT
	90xP+PQjPlOMcbT4OgTIXe9S1sGhEoLxE5S495UPbUpOGdxQr1RHZif3w4sx2bHL5G55cB8xyza
	A1SmeqscT7okWPQCy5cjc5sRchrvCOdX+vHrFe4+2tixKFf8bJORiU0jH8A/Oq1S8sY0cuIyjFT
	AJOi0OfF5NxuQA2bYcberXIs/mAqhaYuCcyk0s5vt78RE20XbdyM2CAiKtVKfzLTGLhTlPoKPnR
	Ct4Eou4RP3mk20mwmF4sKMPGJxft2SBcahdKFYW/ZTct/zh4=
X-Google-Smtp-Source: AGHT+IFsAiP1LwtgkrP4RJr/BDuSUrK0BPvKy64Iaqj6Q4um07Si0S3P6coeWWORXSY/crKvIkLKZA==
X-Received: by 2002:a05:6000:652:b0:3a5:85cb:e9f3 with SMTP id ffacd0b85a97d-3a8fdb2a73amr10286830f8f.12.1751297257046;
        Mon, 30 Jun 2025 08:27:37 -0700 (PDT)
Message-ID: <929e69d4-0377-4ecb-aaff-bff61f1a798b@suse.com>
Date: Mon, 30 Jun 2025 17:27:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 08/17] xen/riscv: add new p2m types and helper macros
 for type classification
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: 
 
 <8f45cffe-e2a2-46e3-8370-2b6b4c86dccf@suse.com>
 <13b80e15-9db9-427d-aaa2-c0389e4c248a@gmail.com>
 <2ebfaa8c-e0bb-4c5b-89e1-48d309ee4989@suse.com>
 <4b5c2a81-947b-4e2f-bb89-a4e776548e52@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: <4b5c2a81-947b-4e2f-bb89-a4e776548e52@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 30.06.2025 17:13, Oleksii Kurochko wrote:
> 
> On 6/30/25 4:42 PM, Jan Beulich wrote:
>> On 30.06.2025 16:33, Oleksii Kurochko wrote:
>>> On 6/26/25 4:59 PM, Jan Beulich wrote:
>>>> On 10.06.2025 15:05, Oleksii Kurochko wrote:
>>>>> --- a/xen/arch/riscv/include/asm/p2m.h
>>>>> +++ b/xen/arch/riscv/include/asm/p2m.h
>>>>> @@ -61,8 +61,28 @@ struct p2m_domain {
>>>>>    typedef enum {
>>>>>        p2m_invalid = 0,    /* Nothing mapped here */
>>>>>        p2m_ram_rw,         /* Normal read/write domain RAM */
>>>>> +    p2m_ram_ro,         /* Read-only; writes are silently dropped */
>>>> As indicated before - this type should be added when the special handling that
>>>> it requires is also introduced.
>>> Perhaps, I missed that. I will drop this type for now.
>>>
>>>>> +    p2m_mmio_direct_dev,/* Read/write mapping of genuine Device MMIO area */
>>>> What's the _dev suffix indicating here?
>>> It indicates that it is device memory, probably, it isn't so necessary in case of RISC-V as
>>> spec doesn't use such terminology. In RISC-V there is only available IO, NC. And we are
>>> |using PTE_PBMT_IO for |p2m_mmio_direct_dev.
>>>
>>> Maybe it would be better just to rename s/p2m_mmio_direct_dev/p2m_mmio_direct_io.
>> And what would the _io suffix indicate, beyond what "mmio" already indicates?
> 
> Just that PBMT_IO will be used for device memory and not PBMT_NC.

And will there (later) also be a p2m_mmio_direct_nc type? If so, I can see the point
of the suffix.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 15:28:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 15:28:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1029214.1402988 (Exim 4.92)
	(envelope-from )
	id 1uWGQK-0002bn-7t; Mon, 30 Jun 2025 15:28:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1029214.1402988; Mon, 30 Jun 2025 15: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 1uWGQK-0002be-4z; Mon, 30 Jun 2025 15:28:00 +0000
Received: by outflank-mailman (input) for mailman id 1029214;
 Mon, 30 Jun 2025 15: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 1uWGQJ-0002Ce-1a
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 15:27:59 +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 ccb571bd-55c6-11f0-b894-0df219b8e170;
 Mon, 30 Jun 2025 17:27:57 +0200 (CEST)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-ae0dffaa8b2so776545466b.0
 for ; Mon, 30 Jun 2025 08:27:57 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ae35363b025sm687751166b.27.2025.06.30.08.27.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 30 Jun 2025 08:27:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ccb571bd-55c6-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1751297277; x=1751902077; 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=mpTggWq72lTg/K9oDiJVOavzt+z0po3flW4vNvE7io8=;
        b=hmCJDYWsdpY/z8Z85pkxA3kYlimUgkCJLh5L9K821ekAbKptNHZz50tu8TBt1DPJOa
         QGkCFQuNdCoVd+cGglf/4Q6XSy9/MHHdw6ACtsn3JOShGUkZnl3Bu9T3ipVDghHZOA5t
         DasePvKiZKFRSPVzopas4yOwfnGfCmWbFolyo3Ge21d1bUXvvVYkiiNiUpR0aziRzvvv
         3ov5DirAzSfpcCDrJEIxnP0s8FJjRumWec8Hnx9w0QWmyPYUc1PfZkyp4fukssSs7Stn
         VFXLiVHECb3Agu0yrUfdjLsvo6xv1/E2PUdIyVZkWR2WwkTYlS2XPQdedL0PL1o3k9zM
         9jog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751297277; x=1751902077;
        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=mpTggWq72lTg/K9oDiJVOavzt+z0po3flW4vNvE7io8=;
        b=n+PaTscafwFVmUhl6aski2LT3WPILqduz6YnmCXjBhxAPj23nrQ6RkKDhnAdZeW1ui
         rQOZlZsELuuium4UL7cr+QH+YHmtzy//Czi3tv4UxXJ3jopVCuATXSz3KJy9RnKKZLok
         4Mi5W0vXtHh3c2ipxtmEp84C06AWKAMvt4ur82zWuxLFzmhdijfvDRWmsgDt+wBV9o9D
         3bXSPX6L2I/mhc6xBrdYEDUHy5ngV8jmCc2qC04ACpmvabXDjeWumfnbbGTYEBkDR43l
         daL+9CpMP7C/8uGAi+HGGCj3Qvm/R1nwetFjGA/vz34BfNmBhxuOssEABaRIp8VryXJR
         KNIw==
X-Forwarded-Encrypted: i=1; AJvYcCXzWPSkAROaJfF+PfsJit029A0F9OA2VK3T7ulYcvDddDMSgJQZB5zJNMRlhwWVzFld29d/dwyANC8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwnGsDsRR4JAxgbBwO4It11hMBp6LfeFtu5ui1A4BXa0AsQIonw
	9wtcwKg/tRZtUK4ZvJYwNGq0hBLaXddCVjWQZqZkFIIKgJG6U2JN4+XM
X-Gm-Gg: ASbGncvFGLDogXvKcz5EtqjvdX4L1tmapKJdYma3Dfv+dGjv2EEV529oRoJ9exq/5na
	oXwSBwKhQJAPxbOZgXGQkSKoDEzU9GCL9DBbN6+KUDib8EcvqBdbmW7T49AJAb4GWJKjtAYrSg+
	PeiZkhjD8aFb0slyWoQWxFQAragdij5l9OgM9kb352NWkV0Oif5wP3kEN9yw2O0yp7Hz6vbNjIh
	Cvbj7N7G6g97ygRTwNjJmictY2fnJ3sXSjwStAd4NfP1b87sFA4CXrqtjzm0FNFPxx6T0uzncAJ
	ABxFlQ+o0L79JFQe6y378hkK2MAQF0I+w4PdhlAQPXGV/CwjYG+i9ypTI/v+uFwp1ngyrKrJJSq
	Ig/sRjGUIYjQbXaWZLVQPyL8KBDMoD55AgbA=
X-Google-Smtp-Source: AGHT+IHIKkNB+6yNZ8CuMhzFveSqZctw068YytflysZ0wtsYzQ4XAyTlOF0aP0grlcI+XBq819LxeA==
X-Received: by 2002:a17:907:3c8f:b0:ad5:55db:e413 with SMTP id a640c23a62f3a-ae34fdded62mr1260171166b.26.1751297276554;
        Mon, 30 Jun 2025 08:27:56 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------Yp3guJ52GRuZDVPNSwm5N7pD"
Message-ID: 
Date: Mon, 30 Jun 2025 17:27:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 08/17] xen/riscv: add new p2m types and helper macros
 for type classification
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: 
 
 <8f45cffe-e2a2-46e3-8370-2b6b4c86dccf@suse.com>
 <13b80e15-9db9-427d-aaa2-c0389e4c248a@gmail.com>
 <6fafc0b4-cfea-4d67-bef6-4e40d1d3e743@gmail.com>
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

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


On 6/30/25 4:45 PM, Jan Beulich wrote:
> On 30.06.2025 16:38, Oleksii Kurochko wrote:
>> On 6/30/25 4:33 PM, Oleksii Kurochko wrote:
>>> On 6/26/25 4:59 PM, Jan Beulich wrote:
>>>> On 10.06.2025 15:05, Oleksii Kurochko wrote:
>>>>> --- a/xen/arch/riscv/include/asm/p2m.h
>>>>> +++ b/xen/arch/riscv/include/asm/p2m.h
>>>>> @@ -61,8 +61,28 @@ struct p2m_domain {
>>>>>    typedef enum {
>>>>>        p2m_invalid = 0,    /* Nothing mapped here */
>>>>>        p2m_ram_rw,         /* Normal read/write domain RAM */
>>>>> +    p2m_ram_ro,         /* Read-only; writes are silently dropped */
>>>> As indicated before - this type should be added when the special handling that
>>>> it requires is also introduced.
>>> Perhaps, I missed that. I will drop this type for now.
>>>
>>>>> +    p2m_mmio_direct_dev,/* Read/write mapping of genuine Device MMIO area */
>>>> What's the _dev suffix indicating here?
>>> It indicates that it is device memory, probably, it isn't so necessary in case of RISC-V as
>>> spec doesn't use such terminology. In RISC-V there is only available IO, NC. And we are
>>> |using PTE_PBMT_IO for |p2m_mmio_direct_dev.
>>>
>>> Maybe it would be better just to rename s/p2m_mmio_direct_dev/p2m_mmio_direct_io.
>> I forgot that p2m_mmio_direct_dev is used by common code for dom0less code (handle_passthrough_prop())
> That'll want abstracting out, I think. I don't view it as helpful to clutter
> RISC-V (and later perhaps also PPC) with Arm-specific terminology.

Would it be better then just rename it to p2m_device? Then it won't clear for Arm which type of MMIO p2m's
types is used as Arm has there MMIO types: *_dev, *_nc, *_c.

As an option (which I don't really like) it could be "#define p2m_mmio_direct_dev ARCH_specific_name" in
asm/p2m.h to not touch common code.

~ Oleksii

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



  
    
  
  
    

    
    
    
    
    On 6/30/25 4:45 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 30.06.2025 16:38, Oleksii Kurochko wrote:

    
      
    
        
    On 6/30/25 4:33 PM, Oleksii Kurochko wrote:

    
        
    
          
    On 6/26/25 4:59 PM, Jan Beulich wrote:

    
          
    
            
    On 10.06.2025 15:05, Oleksii Kurochko wrote:

    
            
    
              
    --- a/xen/arch/riscv/include/asm/p2m.h
+++ b/xen/arch/riscv/include/asm/p2m.h
@@ -61,8 +61,28 @@ struct p2m_domain {
  typedef enum {
      p2m_invalid = 0,    /* Nothing mapped here */
      p2m_ram_rw,         /* Normal read/write domain RAM */
+    p2m_ram_ro,         /* Read-only; writes are silently dropped */

    
            
    
            
    As indicated before - this type should be added when the special handling that
it requires is also introduced.

    
          
    
          
    Perhaps, I missed that. I will drop this type for now.


    
          
    
            
    
              
    +    p2m_mmio_direct_dev,/* Read/write mapping of genuine Device MMIO area */

    
            
    
            
    What's the _dev suffix indicating here?

    
          
    
          
    It indicates that it is device memory, probably, it isn't so necessary in case of RISC-V as
spec doesn't use such terminology. In RISC-V there is only available IO, NC. And we are
|using PTE_PBMT_IO for |p2m_mmio_direct_dev.

Maybe it would be better just to rename s/p2m_mmio_direct_dev/p2m_mmio_direct_io.

    
        
    
        
    I forgot that p2m_mmio_direct_dev is used by common code for dom0less code (handle_passthrough_prop())

    
      
    
      
    That'll want abstracting out, I think. I don't view it as helpful to clutter
RISC-V (and later perhaps also PPC) with Arm-specific terminology.
    
    
    
    
    Would it be better then just rename it to p2m_device? Then it won't clear for Arm which type of MMIO p2m's
types is used as Arm has there MMIO types: *_dev, *_nc, *_c.

As an option (which I don't really like) it could be "#define p2m_mmio_direct_dev ARCH_specific_name" in
asm/p2m.h to not touch common code.

~ Oleksii

    
  


--------------Yp3guJ52GRuZDVPNSwm5N7pD--


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 15:48:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 15:48:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1029232.1403001 (Exim 4.92)
	(envelope-from )
	id 1uWGk8-0005wR-QK; Mon, 30 Jun 2025 15:48:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1029232.1403001; Mon, 30 Jun 2025 15: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 1uWGk8-0005wK-Ng; Mon, 30 Jun 2025 15:48:28 +0000
Received: by outflank-mailman (input) for mailman id 1029232;
 Mon, 30 Jun 2025 15:48: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 1uWGk7-0005wE-On
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 15:48:27 +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 a3fa46c9-55c9-11f0-b894-0df219b8e170;
 Mon, 30 Jun 2025 17:48:17 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3a6e2d85705so2594412f8f.0
 for ; Mon, 30 Jun 2025 08:48:17 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-b34e31da5fdsm7480783a12.59.2025.06.30.08.48.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 30 Jun 2025 08:48:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a3fa46c9-55c9-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1751298497; x=1751903297; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=SO5ZkYq1SHhBddypoKqOAIP98UT5iKIrEFeM/tOKYIs=;
        b=Cir/w+nu8qCxkvet21rxjjL1XwKUajR6TxonFfmW9HTF+FahGLzsW23PkHobzy4rU/
         ihqCyASQ6g8AQuYo9wh0H+8Qtu4W/vwuUUArfmXsYvcDP3fVFPYQKAdasGRa+Y0EMAJo
         jv3xcMDFVTNrufmjQbYDLpWIzY4TQV+hO3ps2e8BhldWHn4GEZiVawoSnf3jEqCCUDG5
         PTxiJZddBxjYdNMW3n1vZQrBJzeR6IYXL8ucB31wtsTPqoTq18GjoiAzaBN32VsLknCF
         6F+asLW4OTEJFdLM+m4o8ifASUmN4wndgCgH48Wr2krIaJas84NL7/SdL/hmy4YQdgLw
         e9gQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751298497; x=1751903297;
        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=SO5ZkYq1SHhBddypoKqOAIP98UT5iKIrEFeM/tOKYIs=;
        b=EyEKNMNhRJKNAE9Bsh9qkIM7IiHoGsdRTxQ7CQ0GtbGwotxdmL9cZXBHEywc/cUI2t
         EcDTbZwJxPtuG18AzwkPHJYV/J4OHlqr2zI5Kzji1bn1ueRqxu/WQPEjJd9pMfYCb63b
         bCXsQxiJlyl2zWQqslehoNWa2pcpIKR+g4WAsFDrLiCQurX+OZz5nQIytpvD4OdwALiC
         isu+vlM5gQ0WsyTGCoYzA33EqanIfez2DMdGbucne9HD+Kk/1HFXm2jQYJ0wJ6DIbsiZ
         vG6A/IJ0IYC1Bcfehn4O4y8bpdPV2Bbo2Pn5zG4ZQZ1PplhNcn3Aks+JslwmE+nDbDCz
         H8xw==
X-Forwarded-Encrypted: i=1; AJvYcCX7Oh5tW2TlXLGDWqWLJdJje2Dm6UqpAvmaksTRb8fZwMeGhStZuy3Al89CfzwGoWZP0eXjht8WsRo=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxf9OEf/83LxOnjNggXztqAJDwEQarkXkvxwHydiUWLzVvuyP0l
	gfGPXG9yiv0RLJt+7l/21ghxzguFmKPT1UlzwmfcJVFaK5U5HBMkbTz5fxZEqqpxkQ==
X-Gm-Gg: ASbGncvMwjQ2UIaKyuq01d/pbb16FfJesdOgJJLctm/MPPeojbH5PDqYMh2xlO2SNSQ
	FDFfGOCP19nJNf5I64GijlymwlnDHr5SYqI6TpsQbryp66WePKMH3h16rlSFwjlk2V5eZzwDPGA
	crFBKzDSGkeqXG5NLoUmlJLMomD2rmQgMVIcmU4AYyLGbdCarw7q4wp36WUb/5ajds2AZ/sSW1V
	Ts93VwGpjEoozcW3ecF6q6ic2W+xhNxFD+POu9dhQLDG3H2T1oTz8x4tonpXIx7gi6tAWJgWFUA
	ud+ltyIUV7s9kmkmWLcMLRJW9tbRKmNyVqybgKIsKsdOKnpCssPh2whvyB5w0xRc84vCiZEg0sD
	c6IJ6Qkfklsl+TB5SRHUAhft5PhqB7LbadubV0syiTyKBjEU=
X-Google-Smtp-Source: AGHT+IFn4Pryq0BPKrnvk5mfvtMKvkKnUx+y5EqFQNjSa9FQZso6HtIcCuAtttpHipf18zxfiErB1Q==
X-Received: by 2002:adf:a150:0:b0:3a6:f2da:7fe5 with SMTP id ffacd0b85a97d-3a90b6df1c7mr9291157f8f.55.1751298497042;
        Mon, 30 Jun 2025 08:48:17 -0700 (PDT)
Message-ID: 
Date: Mon, 30 Jun 2025 17:48:06 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 09/17] xen/riscv: introduce page_set_xenheap_gfn()
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: 
 <186e4a778a6dfab205428dfb4d0c59584a162a9f.1749555949.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: <186e4a778a6dfab205428dfb4d0c59584a162a9f.1749555949.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.06.2025 15:05, Oleksii Kurochko wrote:
> Introduce page_set_xenheap_gfn() helper to encode the GFN associated with
> a Xen heap page directly into the type_info field of struct page_info.
> 
> Introduce a GFN field in the type_info of a Xen heap page by reserving 10
> bits (sufficient for both Sv32 and Sv39+ modes), and define PGT_gfn_mask
> and PGT_gfn_width accordingly.

This reads as if you wanted to encode the GFN in 10 bits.

What would also help is if you said why you actually need this. x86, after
all, gets away without anything like this. (But I understand you're more
Arm-like here.)

> @@ -229,9 +230,21 @@ static inline bool arch_mfns_in_directmap(unsigned long mfn, unsigned long nr)
>  #define PGT_writable_page PG_mask(1, 1)  /* has writable mappings?         */
>  #define PGT_type_mask     PG_mask(1, 1)  /* Bits 31 or 63.                 */
>  
> -/* Count of uses of this frame as its current type. */
> -#define PGT_count_width   PG_shift(2)
> -#define PGT_count_mask    ((1UL << PGT_count_width) - 1)
> + /* 9-bit count of uses of this frame as its current type. */
> +#define PGT_count_mask    PG_mask(0x3FF, 10)
> +
> +/*
> + * Sv32 has 22-bit GFN. Sv{39, 48, 57} have 44-bit GFN.
> + * Thereby we can use for `type_info` 10 bits for all modes, having the same
> + * amount of bits for `type_info` for all MMU modes let us avoid introducing
> + * an extra #ifdef to that header:
> + *   if we go with maximum possible bits for count on each configuration
> + *   we would need to have a set of PGT_count_* and PGT_gfn_*).
> + */
> +#define PGT_gfn_width     PG_shift(10)
> +#define PGT_gfn_mask      (BIT(PGT_gfn_width, UL) - 1)
> +
> +#define PGT_INVALID_XENHEAP_GFN   _gfn(PGT_gfn_mask)

Commentary here would imo be preferable to be much closer to Arm's. I don't
see the point of the extra verbosity (part of which may be fine to have in
the description, except you already say something along these lines there).
While in turn the comment talks of fewer bits than are actually being used
in the RV64 case.

> @@ -283,6 +296,19 @@ static inline bool arch_mfns_in_directmap(unsigned long mfn, unsigned long nr)
>  
>  #define PFN_ORDER(pg) ((pg)->v.free.order)
>  
> +static inline void page_set_xenheap_gfn(struct page_info *p, gfn_t gfn)
> +{
> +    gfn_t gfn_ = gfn_eq(gfn, INVALID_GFN) ? PGT_INVALID_XENHEAP_GFN : gfn;
> +    unsigned long x, nx, y = p->u.inuse.type_info;
> +
> +    ASSERT(is_xen_heap_page(p));
> +
> +    do {
> +        x = y;
> +        nx = (x & ~PGT_gfn_mask) | gfn_x(gfn_);
> +    } while ( (y = cmpxchg(&p->u.inuse.type_info, x, nx)) != x );
> +}
> +
>  extern unsigned char cpu0_boot_stack[];
>  
>  void setup_initial_pagetables(void);

What about the "get" counterpart?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 15:50:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 15:50:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1029239.1403011 (Exim 4.92)
	(envelope-from )
	id 1uWGmY-0007WD-5e; Mon, 30 Jun 2025 15:50:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1029239.1403011; Mon, 30 Jun 2025 15:50: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 1uWGmY-0007W6-2p; Mon, 30 Jun 2025 15:50:58 +0000
Received: by outflank-mailman (input) for mailman id 1029239;
 Mon, 30 Jun 2025 15:50: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 1uWGmX-0007Vy-IZ
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 15:50:57 +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 01db0200-55ca-11f0-b894-0df219b8e170;
 Mon, 30 Jun 2025 17:50:55 +0200 (CEST)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-453608ed113so23715785e9.0
 for ; Mon, 30 Jun 2025 08:50:55 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-23acb2e2493sm88805155ad.48.2025.06.30.08.50.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 30 Jun 2025 08:50:53 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 01db0200-55ca-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1751298654; x=1751903454; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=XHRqmBzRfJ5cd6lN8Yd5F/h8vJDkOBgYffL/BDrwugw=;
        b=WFUGTQZj5vIqcD//txSgAXThqq06wu6yr2ArnkuCRmdnWFfn8CMkECl45K2Z/31NZu
         TkbhMAWBFaFOqRWL2I7e4rhsUDPO2dgFPJqC5HzPyuJ05AJMrgofp1f2UsMzu9HjE73o
         GW320kF3GqwQrr/x1a8Gx9lrGh+81/GqePyNOt/C2JvrCWnMJxDP6w5QC++41hsqLRic
         I0rWqtUHNH1Kz9kLdVgZazgoI2z5AStp1gD0VB1GfMZYObUFNKcqjbtVNb2JszJxEgre
         8/9pOmyZqPPQUo/LCwiQOxHdHJNqBmxNDQe1UJmEoIbymgSZ3++Wd1aVLPxXGoV2sGAA
         VAuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751298654; x=1751903454;
        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=XHRqmBzRfJ5cd6lN8Yd5F/h8vJDkOBgYffL/BDrwugw=;
        b=BQGmnMkUUPPgwHehR8F6y/0692p2sFiJx8YfmGYmA5NBKjDpqGZTeaYezQ/O1v40Z7
         lcOPT18cR513AhIMX2h7sg1BY5uNhJ9ooGxVZqLg1nZd53WLJrm0xs3v3gqJdenJyZVh
         0iYyPh4xXTFomF7EGidbIY7xEnVH7CKgkgfGPD43gMSQQDg/hTKdGU7z4h15OnxLpRai
         i1ImNp4ESrXEb59K3pS/fXrlLXsf5O1xoBPEaOB4Drn/+iM+bApY6bhR4Lz79RJ3JFDi
         A+Vy1Z637tcFZ1IFX4/bQlRpN/GeJ5sU5tzyRHxIMmh+VEBNB+meyoL9KOyuoshlhPhj
         CIDw==
X-Forwarded-Encrypted: i=1; AJvYcCWaNxUWmQb2pX0fgHFVBD3PbtjFdrsfgYXuYS0Kgb2pYJ+yc83+Oi92L/kuYbFkKLiHAovNKkUO6Ts=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyqS1CzDQmnjiTq3JJWTe3AO4GFvDeN8QTjLTzipRonA5zsRWdA
	N3xvdkJU5i84pWO5UTTRm3YBcKeU63tEfj4OjFVjaORlSkJDnz4IUK9A+hna8Uenvg==
X-Gm-Gg: ASbGnctBJ8BvDF6Q+0Pcm2QgfdvALbAHYo2RgsMPxaMW5qa3sbpb2vK17fXAeh1CysS
	ODKJCNmPlrHoLwwP2vmlhcrK2NMnewsK26vB3nlNWVthjQIqYYa+ucyz1BugBH20TpLKz/k6Mnj
	4G0XQFbCbKqAXJCO3NkgmaiA+pvo9TImQfMury9OZlVP81Hht/Ga/GLR6PTVS7vTWD4ldWtqTDp
	AFRoILBXMYsYmlaXvXg6z3ew0OU3ZbMSr6XpptMiraDDnWwcH7d0xma4LGP2h79YrtVKiViGQCZ
	EY1yXi9hqDRdIGavHn4yQTQoeRS5kf5umu5iFUgojZ45EJVHbqvFjLgdEqlqOmkBcklK80pmgHr
	mMfuOF2cJN0n6iAKKikhKGgI0UVvqlMhBkcpCNu6o+PVieqw=
X-Google-Smtp-Source: AGHT+IEdoq2wXVKqp8ST8Hi1/5chVZpBVUrimSxKz0ZRQHz+BGLJOSZtm3ZAS3/Eh/MgEjsiXTb6sg==
X-Received: by 2002:adf:b19b:0:b0:3a3:6e85:a529 with SMTP id ffacd0b85a97d-3a8ffcc9ea5mr8819115f8f.51.1751298654427;
        Mon, 30 Jun 2025 08:50:54 -0700 (PDT)
Message-ID: <2a7515a4-0e86-428f-8239-ae97b976f3f2@suse.com>
Date: Mon, 30 Jun 2025 17:50:43 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 08/17] xen/riscv: add new p2m types and helper macros
 for type classification
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: 
 
 <8f45cffe-e2a2-46e3-8370-2b6b4c86dccf@suse.com>
 <13b80e15-9db9-427d-aaa2-c0389e4c248a@gmail.com>
 <6fafc0b4-cfea-4d67-bef6-4e40d1d3e743@gmail.com>
 
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 30.06.2025 17:27, Oleksii Kurochko wrote:
> 
> On 6/30/25 4:45 PM, Jan Beulich wrote:
>> On 30.06.2025 16:38, Oleksii Kurochko wrote:
>>> On 6/30/25 4:33 PM, Oleksii Kurochko wrote:
>>>> On 6/26/25 4:59 PM, Jan Beulich wrote:
>>>>> On 10.06.2025 15:05, Oleksii Kurochko wrote:
>>>>>> --- a/xen/arch/riscv/include/asm/p2m.h
>>>>>> +++ b/xen/arch/riscv/include/asm/p2m.h
>>>>>> @@ -61,8 +61,28 @@ struct p2m_domain {
>>>>>>    typedef enum {
>>>>>>        p2m_invalid = 0,    /* Nothing mapped here */
>>>>>>        p2m_ram_rw,         /* Normal read/write domain RAM */
>>>>>> +    p2m_ram_ro,         /* Read-only; writes are silently dropped */
>>>>> As indicated before - this type should be added when the special handling that
>>>>> it requires is also introduced.
>>>> Perhaps, I missed that. I will drop this type for now.
>>>>
>>>>>> +    p2m_mmio_direct_dev,/* Read/write mapping of genuine Device MMIO area */
>>>>> What's the _dev suffix indicating here?
>>>> It indicates that it is device memory, probably, it isn't so necessary in case of RISC-V as
>>>> spec doesn't use such terminology. In RISC-V there is only available IO, NC. And we are
>>>> |using PTE_PBMT_IO for |p2m_mmio_direct_dev.
>>>>
>>>> Maybe it would be better just to rename s/p2m_mmio_direct_dev/p2m_mmio_direct_io.
>>> I forgot that p2m_mmio_direct_dev is used by common code for dom0less code (handle_passthrough_prop())
>> That'll want abstracting out, I think. I don't view it as helpful to clutter
>> RISC-V (and later perhaps also PPC) with Arm-specific terminology.
> 
> Would it be better then just rename it to p2m_device? Then it won't clear for Arm which type of MMIO p2m's
> types is used as Arm has there MMIO types: *_dev, *_nc, *_c.

I don't understand why Arm matters here. P2M types want naming in a way that makes
sense for RISC-V.

> As an option (which I don't really like) it could be "#define p2m_mmio_direct_dev ARCH_specific_name" in
> asm/p2m.h to not touch common code.

A #define may be needed, but not one to _still_ introduce Arm naming into non-Arm
code.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 15:59:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 15:59:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1029246.1403020 (Exim 4.92)
	(envelope-from )
	id 1uWGus-0008HD-Te; Mon, 30 Jun 2025 15:59:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1029246.1403020; Mon, 30 Jun 2025 15: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 1uWGus-0008H6-Qo; Mon, 30 Jun 2025 15:59:34 +0000
Received: by outflank-mailman (input) for mailman id 1029246;
 Mon, 30 Jun 2025 15:59: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 1uWGus-0008H0-7U
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 15:59:34 +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 36851e82-55cb-11f0-a312-13f23c93f187;
 Mon, 30 Jun 2025 17:59:33 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3a6f2c6715fso2534786f8f.1
 for ; Mon, 30 Jun 2025 08:59:33 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-74af557460fsm9980405b3a.93.2025.06.30.08.59.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 30 Jun 2025 08:59:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 36851e82-55cb-11f0-a312-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1751299172; x=1751903972; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=7ZffqJRME8x4UkcvSMYkkB4E+0MQZzh9SBrRhhrlkeM=;
        b=D9c2w/RlzUzy3E+4DnbQK8Byx9a/TvxGdrOjjRTJO330tdlMtr5un4hFzCagHx81Ai
         apw5D/FyLLxE0sMP/LjC1i8jAG/dEwZ5C2D4AKeJAtpLgGO6qibPA2CWLa/cz0E09hom
         skujzWKvUMhdmozXsDOHb1levPl0qO0J4xDQMOU5//DYOwznaaztYZ8yuO5remJGugCP
         Xdx8WMOCM1IdDvn1FxLmVNIWwsNEzlC3CuLCw/nMilOtuqY74GuI0n9FuDzXzgGpVxZh
         mAW1DbGSCv+na8JYRMloHWA0j1QD2E1nRhGh9dXDrIy0CmOx37JuRPbyTcLqTSKoIQFL
         qAIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751299172; x=1751903972;
        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=7ZffqJRME8x4UkcvSMYkkB4E+0MQZzh9SBrRhhrlkeM=;
        b=t3uy3NCFH3PuaRvj2HG5p98poF/HU23xG7Yb0xeqP8QEcjdBY17POj3eMTTBmWrDHV
         uThK+VTLJWL9awGqTyDVIiuov5n0Ggh/qVmnG/LeS0O+7C1l1QHONa77Srq3lXgalicm
         xIalkYiThy6/cULwIiHzek5KH4R3w53m7GD5TXxJs5FOMudSDqD5axKNYYvsX75l36vu
         Tw+etNQe+UHqwe+ydfdRR/5XnSJIeR1E4Nof2fe+mydYf8HP1FKXp71uC8L/Y1Bugv87
         YJoml6x3qJ9H6M0yE4AgooBNQ856qF61AYZeVJ53oDEZ2uhq7poAEeXbtdqUXe6F0vzw
         lA5g==
X-Forwarded-Encrypted: i=1; AJvYcCW1ZIV3wzum5CAgJ/x7x3+WLbG8+0GElrMFjlsrGiivsPG/M5UMlU64oBbQVZIUmLPtt7VnJiK7NfI=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx1Ub1bjqm+dJePFL+rJomCIaHZKtox+yh4i1hYJxIC996VAxVI
	wvh6d2dU4Myf1Bf08UrPmFCHdliLWrbhFuL/6tX4MYwDl8SHTx+7pYSXD7vHkEp3BQ==
X-Gm-Gg: ASbGncsCPQgXdo/117LRjH+nXlHf49s+lrsa7limPeHwQFI+JYzcKZODyszgRbe0htE
	0tL65tJ5hjCUo+SKVZd8DQQuw3U80ky/8FUHwYGGImemiKygQtZlhXe5SqQ2yijC6pjeGb5dygR
	HRNqsTQhIbEwCi2n0olMQOM+q2an5XGnpRXD8qx+p64kXkKHAxltHBJ3IRRlXCUa0a/IrIy/OjO
	JdtT3CCDJICdLUbLc12uI2+Z7HizVlY8Ggk1ah0/naxv4l7yY7Khu6Rk9ngPn03WnEBPA/k/6i4
	WpNnqqgw/b44RQbkN1pOVe6AgX/8cUxaie9b18auqYYnfaavhTwt6ig4LIFlf2KCo43DUXdlpQz
	H2Bpog/UuH5xi6sDD5pIMmUJpAxAPZHV8XG8PkI+qVeQ+CTw=
X-Google-Smtp-Source: AGHT+IG5ucJoKG1vBGA+waDwFYrmJxnAuc+PmtW9uHGIahqq9pYnUWtAtMeHQcURj4SUVuWbMv9Gsg==
X-Received: by 2002:adf:9d91:0:b0:3a6:da76:38b0 with SMTP id ffacd0b85a97d-3a8f50cb692mr9963875f8f.25.1751299172491;
        Mon, 30 Jun 2025 08:59:32 -0700 (PDT)
Message-ID: 
Date: Mon, 30 Jun 2025 17:59:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 10/17] xen/riscv: implement guest_physmap_add_entry()
 for mapping GFNs to MFNs
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: 
 <0b1f7ead7eb1b7c8687d388cca50b46eefb8e408.1749555949.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: <0b1f7ead7eb1b7c8687d388cca50b46eefb8e408.1749555949.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.06.2025 15:05, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/p2m.c
> +++ b/xen/arch/riscv/p2m.c
> @@ -324,3 +324,44 @@ int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
>  
>      return 0;
>  }
> +
> +static int p2m_set_entry(struct p2m_domain *p2m,
> +                         gfn_t sgfn,
> +                         unsigned long nr,
> +                         mfn_t smfn,
> +                         p2m_type_t t,
> +                         p2m_access_t a)
> +{
> +    return -EOPNOTSUPP;
> +}
> +
> +static int p2m_insert_mapping(struct domain *d, gfn_t start_gfn,

This likely again wants to be struct p2m_domain *.

> +                              unsigned long nr, mfn_t mfn, p2m_type_t t)
> +{
> +    struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +    int rc;
> +
> +    p2m_write_lock(p2m);
> +    rc = p2m_set_entry(p2m, start_gfn, nr, mfn, t, p2m->default_access);
> +    p2m_write_unlock(p2m);
> +
> +    return rc;
> +}
> +
> +int map_regions_p2mt(struct domain *d,
> +                     gfn_t gfn,
> +                     unsigned long nr,
> +                     mfn_t mfn,
> +                     p2m_type_t p2mt)
> +{
> +    return p2m_insert_mapping(d, gfn, nr, mfn, p2mt);
> +}

What is this function doing here? The description says "for generic mapping
purposes", which really may mean anything. Plus, if and when you need it, it
wants to come with a name that fits with e.g. ...

> +int guest_physmap_add_entry(struct domain *d,
> +                            gfn_t gfn,
> +                            mfn_t mfn,
> +                            unsigned long page_order,
> +                            p2m_type_t t)

... this one, to understand their relationship / difference.

> +{
> +    return p2m_insert_mapping(d, gfn, (1 << page_order), mfn, t);

1UL please, while at the same time the parentheses could be omitted.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 16:18:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 16:18:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1029258.1403030 (Exim 4.92)
	(envelope-from )
	id 1uWHCu-0003Ut-Gf; Mon, 30 Jun 2025 16:18:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1029258.1403030; Mon, 30 Jun 2025 16:18: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 1uWHCu-0003Um-DM; Mon, 30 Jun 2025 16:18:12 +0000
Received: by outflank-mailman (input) for mailman id 1029258;
 Mon, 30 Jun 2025 16:18: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 1uWHCs-0003Ug-NZ
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 16:18:10 +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 cd6555e7-55cd-11f0-b894-0df219b8e170;
 Mon, 30 Jun 2025 18:18:05 +0200 (CEST)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-ae35c447234so654164866b.1
 for ; Mon, 30 Jun 2025 09:18:05 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ae35363aecdsm705640166b.16.2025.06.30.09.18.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 30 Jun 2025 09:18:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cd6555e7-55cd-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1751300284; x=1751905084; 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=CDm1mQqcyBUZokPVAMRm4victrDQ+kORMVXoQtNWF4Q=;
        b=Hx29C7rD4YO3lO/x5kduqIK5K6/FxvcgrN7SgZAiadzacHk0lelRrIwzcqdCNg88bf
         5EWqFC4vnze1ZWaeevrVdYLUA3SZVEzCFjR0XM4HBEbwIkvGZinB1H7Qi5v7qZZWTXNI
         0HdI1npN5rIMgq43fVIeq2if+Q5D4LS9nfDb7VkolUvewGka4ZEIaEZLy8z/lyCRWueZ
         ysUmPVynk7fCU4/jGKo/5DKdxoSHe6Rs9ZVPihxkar2H/6kEERmhZddHHsSCA2IBb/Na
         kHFvfCPJstmSyxEutw/BwwQcrWXXuHHeF1WU1SOylIL0FcWiSKD7q9K5/GNxtn0z2/1w
         Rkdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751300285; x=1751905085;
        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=CDm1mQqcyBUZokPVAMRm4victrDQ+kORMVXoQtNWF4Q=;
        b=smC0+97V8aeDhFItmFmY2k4oxxWk/fYog3KJYRBinl4WCpimPaj9bf1oI50/rhzk1P
         d5OPmdD3bus0DYmCRDzO6ukD+o9SDSKdQX/mJTCvGRNpjzWZPDZ3hzRLNbZXm6Bf/fvZ
         6/+7Qc08VRA57tATgbJlQWFswDGiEV73ZgPfTDK41DiYAb0ueQ5EmX/FwrqIj875F/Il
         A8HcSDQRC+WR83U9bRNXojhumqLBdtnb1EPKctcJqaQAVyQoIeqlVcPVQtAR+4XmQrnn
         RgV/+bMcVRQ2JZnWklEnGjbl71sD3eh9OPnpr5s0+yQA0Lz9RWCOMwcXlcBekKM+/VNy
         7Gsg==
X-Forwarded-Encrypted: i=1; AJvYcCVjI1g6rh21QWVuOHXjwOqwV2jghYua0cNa1yBu13xQP+xGUbMHSUBET7asX16iGBmozgNwZpdvER4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxNEQIwc7ZFPO9Yr7TZq/JsWAvMmCs1Zj7QfQMDFRB1QBpBP9Bw
	ZY6J16Jh+ggHsYYggdFaIz3cfN3MeXKhjcJ5SDysPxCrMG1XdP2lCAHx
X-Gm-Gg: ASbGncvW8ZW2lo9LqAA8ogUfRSjeQ5KvzfzMe7AMMWtnPAT6DXZBdk6+OGlShwZ5sG1
	Z1d65PgI2wWQv5E5Z2E+BspWq/Z1qsqZySOvIMBnUqV0FC0qPnAJiaU/HBgCBbP6B4JkSFVy6fm
	H4a0PSVbewc+zE2WLobz0zzvwsKdsMcMdwIOQNrP4de8pS09J7zQ5krbvhiSb+mxdIrh285zEOF
	e+33faj0VlXDo3L0qFhrQeR8TjPZ9Divt/Nub4RtODYH3l+GMRhDy+0MYh4zc5YkHe/P/98sGH+
	UAaNr35WGDp30SfuK244oygaqdI6M0m+XXGGU9RJ0aPH4NmIIY8/nCpt0KkdAKuN98bA1DOI6Ff
	Jv8eCk3pjuLPEduWunj8NQ1sZvk1HGpTSpzE=
X-Google-Smtp-Source: AGHT+IHQj3JjTcUwTZ+LnUcHvB4bjjSs89yS9p85V8i579qXl5fQpwz/zPvMyvOVt0/hGSnc27hwxg==
X-Received: by 2002:a17:907:c25:b0:ae3:6e5c:1c05 with SMTP id a640c23a62f3a-ae3aa365f57mr16828466b.30.1751300284110;
        Mon, 30 Jun 2025 09:18:04 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------2FTHIQhiOa3ZrNfgfpkwc2a0"
Message-ID: 
Date: Mon, 30 Jun 2025 18:18:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 06/17] xen/riscv: add root page table allocation
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: 
 <76675ddb7517e4cceb63472c94944046b255da01.1749555949.git.oleksii.kurochko@gmail.com>
 <9c89ead3-7577-46f2-acc2-6dd8d793ab89@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <9c89ead3-7577-46f2-acc2-6dd8d793ab89@suse.com>

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


On 6/30/25 5:22 PM, Jan Beulich wrote:
> On 10.06.2025 15:05, Oleksii Kurochko wrote:
>> --- a/xen/arch/riscv/include/asm/p2m.h
>> +++ b/xen/arch/riscv/include/asm/p2m.h
>> @@ -26,6 +26,12 @@ struct p2m_domain {
>>       /* Pages used to construct the p2m */
>>       struct page_list_head pages;
>>   
>> +    /* The root of the p2m tree. May be concatenated */
>> +    struct page_info *root;
>> +
>> +    /* Address Translation Table for the p2m */
>> +    paddr_t hgatp;
> Does this really need holding in a struct field? Can't is be re-created at
> any time from "root" above?

Yes, with the current one implementation, I agree it would be enough only
root. But as you noticed below...

> And such re-creation is apparently infrequent,
> if happening at all after initial allocation. (But of course I don't know
> what future patches of yours will bring.) This is even more so if ...
>
>> --- a/xen/arch/riscv/include/asm/riscv_encoding.h
>> +++ b/xen/arch/riscv/include/asm/riscv_encoding.h
>> @@ -133,11 +133,13 @@
>>   #define HGATP_MODE_SV48X4		_UL(9)
>>   
>>   #define HGATP32_MODE_SHIFT		31
>> +#define HGATP32_MODE_MASK		_UL(0x80000000)
>>   #define HGATP32_VMID_SHIFT		22
>>   #define HGATP32_VMID_MASK		_UL(0x1FC00000)
>>   #define HGATP32_PPN			_UL(0x003FFFFF)
>>   
>>   #define HGATP64_MODE_SHIFT		60
>> +#define HGATP64_MODE_MASK		_ULL(0xF000000000000000)
>>   #define HGATP64_VMID_SHIFT		44
>>   #define HGATP64_VMID_MASK		_ULL(0x03FFF00000000000)
> ... VMID management is going to change as previously discussed, at which
> point the value to put in hgatp will need (partly) re-calculating at certain
> points anyway.

... after VMID management will changed to per-CPU base then it will be needed
to update re-calculate hgatp each time vCPU on pCPU is changed.
In this case I prefer to have partially calculated 'hgatp'.

>> --- a/xen/arch/riscv/p2m.c
>> +++ b/xen/arch/riscv/p2m.c
>> @@ -41,6 +41,91 @@ void p2m_write_unlock(struct p2m_domain *p2m)
>>       write_unlock(&p2m->lock);
>>   }
>>   
>> +static void clear_and_clean_page(struct page_info *page)
>> +{
>> +    clean_dcache_va_range(page, PAGE_SIZE);
>> +    clear_domain_page(page_to_mfn(page));
>> +}
> A function of this name can, imo, only clear and then clean. Question is why
> it's the other way around, and what the underlying requirement is for the
> cleaning part to be there in the first place. Maybe that's obvious for a
> RISC-V person, but it's entirely non-obvious to me (Arm being different in
> this regard because of running with caches disabled at certain points in
> time).

You're right, the current name|clear_and_clean_page()| implies that clearing
should come before cleaning, which contradicts the current implementation.
The intent here is to ensure that the page contents are consistent in RAM
(not just in cache) before use by other entities (guests or devices).

The clean must follow the clear — so yes, the order needs to be reversed.

>
>> +static struct page_info *p2m_allocate_root(struct domain *d)
>> +{
>> +    struct page_info *page;
>> +    unsigned int order = get_order_from_bytes(KB(16));
> While better than a hard-coded order of 2, this still is lacking. Is there
> a reason there can't be a suitable manifest constant in the header?

No any specific reason, I just decided not to introduce new definition as
it is going to be used only inside this function.

I think it will make sense to have in p2m.c:
  #define P2M_ROOT_PT_SIZE KB(16)
If it isn't the best one option, then what about to move this defintion
to config.h or asm/p2m.h.

>
>> +    unsigned int nr_pages = _AC(1,U) << order;
> Nit (style): Missing blank after comma.

I've changed that to BIT(order, U)

>
>> +    /* Return back nr_pages necessary for p2m root table. */
>> +
>> +    if ( ACCESS_ONCE(d->arch.paging.p2m_total_pages) < nr_pages )
>> +        panic("Specify more xen,domain-p2m-mem-mb\n");
> You shouldn't panic() in anything involved in domain creation. You want to
> return NULL in this case.

It makes sense in this case just to return NULL.

>
> Further, to me the use of "more" looks misleading here. Do you perhaps mean
> "larger" or "bigger"?
>
> This also looks to be happening without any lock held. If that's intentional,
> I think the "why" wants clarifying in a code comment.

Agree, returning back pages necessary for p2m root table should be done under
spin_lock(&d->arch.paging.lock).

>
>> +    for ( unsigned int i = 0; i < nr_pages; i++ )
>> +    {
>> +        /* Return memory to domheap. */
>> +        page = page_list_remove_head(&d->arch.paging.p2m_freelist);
>> +        if( page )
>> +        {
>> +            ACCESS_ONCE(d->arch.paging.p2m_total_pages)--;
>> +            free_domheap_page(page);
>> +        }
>> +        else
>> +        {
>> +            printk(XENLOG_ERR
>> +                   "Failed to free P2M pages, P2M freelist is empty.\n");
>> +            return NULL;
>> +        }
>> +    }
> The reason for doing this may also want to be put in a comment.

I thought it would be enough the comment above: /* Return back nr_pages necessary for p2m root table. */

>
>> +    /* Allocate memory for p2m root table. */
>> +
>> +    /*
>> +     * As mentioned in the Priviliged Architecture Spec (version 20240411)
>> +     * As explained in Section 18.5.1, for the paged virtual-memory schemes
> The first sentence didn't finish when the 2nd starts. Is there a piece missing?
> Do the two sentences want to be joined together?

Nothing is missed, just bad wording. I will update to:
   As mentioned in the Priviliged Architecture Spec (version 20240411) in Section 18.5.1, ...

>
>> +static unsigned long hgatp_from_page(struct p2m_domain *p2m)
> Function name and parameter type/name don't fit together.

I'll update an argument to struct page_info *root.

>
>> +{
>> +    struct page_info *p2m_root_page = p2m->root;
> As always: pointer-to-const wherever possible, please. But: Is this local
> variable really useful to have?

No, it will be just passed as an argument.

>
>> +    unsigned long ppn;
>> +    unsigned long hgatp_mode;
>> +
>> +    ppn = PFN_DOWN(page_to_maddr(p2m_root_page)) & HGATP_PPN;
>> +
>> +#if RV_STAGE1_MODE == SATP_MODE_SV39
>> +    hgatp_mode = HGATP_MODE_SV39X4;
>> +#elif RV_STAGE1_MODE == SATP_MODE_SV48
>> +    hgatp_mode = HGATP_MODE_SV48X4;
>> +#else
>> +#   error "add HGATP_MODE"
>> +#endif
>> +
>> +    return ppn | MASK_INSR(p2m->vmid, HGATP_VMID_MASK) |
>> +           MASK_INSR(hgatp_mode, HGATP_MODE_MASK);
>> +}
>> +
>> +static int p2m_alloc_root_table(struct domain *d)
> As indicated earlier, in a wider context - this is a good candidate where
> the caller rather wants to pass struct p2m_domain *. Once you get variations
> on P2Ms (like x86'es altp2m or nestedp2m, the domain won't be meaningful
> here to know which P2M to allocate the root for.

Good point. I will re-work that.

>
>> +{
>> +    struct p2m_domain *p2m = p2m_get_hostp2m(d);
>> +
>> +    p2m->root = p2m_allocate_root(d);
>> +    if ( !p2m->root )
>> +        return -ENOMEM;
>> +
>> +    p2m->hgatp = hgatp_from_page(p2m);
>> +
>> +    return 0;
>> +}
>> +
>>   static spinlock_t vmid_alloc_lock = SPIN_LOCK_UNLOCKED;
>>   
>>   /*
>> @@ -228,5 +313,14 @@ int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
>>           }
>>       }
>>   
>> +    /*
>> +    * First, wait for the p2m pool to be initialized. Then allocate the root
> Why "wait"? There's waiting here.

I am not really get your question.

"wait" here is about the initialization of the pool which happens above this comment.

>
>> +    * table so that the necessary pages can be returned from the p2m pool,
>> +    * since the root table must be allocated using alloc_domheap_pages(...)
>> +    * to meet its specific requirements.
>> +    */
>> +    if ( !d->arch.p2m.root )
> Aren't you open-coding p2m_get_hostp2m() here?

Yes, p2m_get_hostp2m()  should be used here.

~ Oleksii

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



  
    
  
  
    

    
    
    
    
    On 6/30/25 5:22 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 10.06.2025 15:05, Oleksii Kurochko wrote:

    
      
    
        
    --- a/xen/arch/riscv/include/asm/p2m.h
+++ b/xen/arch/riscv/include/asm/p2m.h
@@ -26,6 +26,12 @@ struct p2m_domain {
     /* Pages used to construct the p2m */
     struct page_list_head pages;
 
+    /* The root of the p2m tree. May be concatenated */
+    struct page_info *root;
+
+    /* Address Translation Table for the p2m */
+    paddr_t hgatp;

    
      
    
      
    Does this really need holding in a struct field? Can't is be re-created at
any time from "root" above? 
    
    
    
    
    Yes, with the current one implementation, I agree it would be enough only
root. But as you noticed below...

    
    
    
      
    And such re-creation is apparently infrequent,
if happening at all after initial allocation. (But of course I don't know
what future patches of yours will bring.) This is even more so if ...


    
      
    
        
    --- a/xen/arch/riscv/include/asm/riscv_encoding.h
+++ b/xen/arch/riscv/include/asm/riscv_encoding.h
@@ -133,11 +133,13 @@
 #define HGATP_MODE_SV48X4		_UL(9)
 
 #define HGATP32_MODE_SHIFT		31
+#define HGATP32_MODE_MASK		_UL(0x80000000)
 #define HGATP32_VMID_SHIFT		22
 #define HGATP32_VMID_MASK		_UL(0x1FC00000)
 #define HGATP32_PPN			_UL(0x003FFFFF)
 
 #define HGATP64_MODE_SHIFT		60
+#define HGATP64_MODE_MASK		_ULL(0xF000000000000000)
 #define HGATP64_VMID_SHIFT		44
 #define HGATP64_VMID_MASK		_ULL(0x03FFF00000000000)

    
      
    
      
    ... VMID management is going to change as previously discussed, at which
point the value to put in hgatp will need (partly) re-calculating at certain
points anyway.

    
    
    
    
    ... after VMID management will changed to per-CPU base then it will be needed
to update re-calculate hgatp each time vCPU on pCPU is changed.
In this case I prefer to have partially calculated 'hgatp'.


    
    
    
      
    
      
    
        
    --- a/xen/arch/riscv/p2m.c
+++ b/xen/arch/riscv/p2m.c
@@ -41,6 +41,91 @@ void p2m_write_unlock(struct p2m_domain *p2m)
     write_unlock(&p2m->lock);
 }
 
+static void clear_and_clean_page(struct page_info *page)
+{
+    clean_dcache_va_range(page, PAGE_SIZE);
+    clear_domain_page(page_to_mfn(page));
+}

    
      
    
      
    A function of this name can, imo, only clear and then clean. Question is why
it's the other way around, and what the underlying requirement is for the
cleaning part to be there in the first place. Maybe that's obvious for a
RISC-V person, but it's entirely non-obvious to me (Arm being different in
this regard because of running with caches disabled at certain points in
time).
    
    
    
    
    You're right, the current name clear_and_clean_page() implies that clearing
should come before cleaning, which contradicts the current implementation.
The intent here is to ensure that the page contents are consistent in RAM
(not just in cache) before use by other entities (guests or devices).

    
    
    The clean must follow the clear — so yes, the order needs to be reversed.


    
    
    
      
    

    
      
    
        
    +static struct page_info *p2m_allocate_root(struct domain *d)
+{
+    struct page_info *page;
+    unsigned int order = get_order_from_bytes(KB(16));

    
      
    
      
    While better than a hard-coded order of 2, this still is lacking. Is there
a reason there can't be a suitable manifest constant in the header?
    
    
    
    
    No any specific reason, I just decided not to introduce new definition as
it is going to be used only inside this function.

I think it will make sense to have in p2m.c:
 #define P2M_ROOT_PT_SIZE KB(16)
If it isn't the best one option, then what about to move this defintion
to config.h or asm/p2m.h.


    
    
    
      
    

    
      
    
        
    +    unsigned int nr_pages = _AC(1,U) << order;

    
      
    
      
    Nit (style): Missing blank after comma.
    
    
    
    
    I've changed that to BIT(order, U)

    
    
    
      
    

    
      
    
        
    +    /* Return back nr_pages necessary for p2m root table. */
+
+    if ( ACCESS_ONCE(d->arch.paging.p2m_total_pages) < nr_pages )
+        panic("Specify more xen,domain-p2m-mem-mb\n");

    
      
    
      
    You shouldn't panic() in anything involved in domain creation. You want to
return NULL in this case.
    
    
    
    
    It makes sense in this case just to return NULL.


    
    
    
      
    
Further, to me the use of "more" looks misleading here. Do you perhaps mean
"larger" or "bigger"?

This also looks to be happening without any lock held. If that's intentional,
I think the "why" wants clarifying in a code comment.
    
    
    
    
    Agree, returning back pages necessary for p2m root table should be done under
spin_lock(&d->arch.paging.lock).

    
    
    
    
    
      
    

    
      
    
        
    +    for ( unsigned int i = 0; i < nr_pages; i++ )
+    {
+        /* Return memory to domheap. */
+        page = page_list_remove_head(&d->arch.paging.p2m_freelist);
+        if( page )
+        {
+            ACCESS_ONCE(d->arch.paging.p2m_total_pages)--;
+            free_domheap_page(page);
+        }
+        else
+        {
+            printk(XENLOG_ERR
+                   "Failed to free P2M pages, P2M freelist is empty.\n");
+            return NULL;
+        }
+    }

    
      
    
      
    The reason for doing this may also want to be put in a comment.
    
    
    
    
    I thought it would be enough the comment above: /* Return back nr_pages necessary for p2m root table. */

    
    
    
      
    

    
      
    
        
    +    /* Allocate memory for p2m root table. */
+
+    /*
+     * As mentioned in the Priviliged Architecture Spec (version 20240411)
+     * As explained in Section 18.5.1, for the paged virtual-memory schemes

    
      
    
      
    The first sentence didn't finish when the 2nd starts. Is there a piece missing?
Do the two sentences want to be joined together?
    
    
    
    
    Nothing is missed, just bad wording. I will update to:
  As mentioned in the Priviliged Architecture Spec (version 20240411) in Section 18.5.1, ...


    
    
    
      
    

    
      
    
        
    +static unsigned long hgatp_from_page(struct p2m_domain *p2m)

    
      
    
      
    Function name and parameter type/name don't fit together.
    
    
    
    
    I'll update an argument to struct page_info *root.


    
    
    
      
    

    
      
    
        
    +{
+    struct page_info *p2m_root_page = p2m->root;

    
      
    
      
    As always: pointer-to-const wherever possible, please. But: Is this local
variable really useful to have?
    
    
    
    
    No, it will be just passed as an argument.


    
    
    
      
    

    
      
    
        
    +    unsigned long ppn;
+    unsigned long hgatp_mode;
+
+    ppn = PFN_DOWN(page_to_maddr(p2m_root_page)) & HGATP_PPN;
+
+#if RV_STAGE1_MODE == SATP_MODE_SV39
+    hgatp_mode = HGATP_MODE_SV39X4;
+#elif RV_STAGE1_MODE == SATP_MODE_SV48
+    hgatp_mode = HGATP_MODE_SV48X4;
+#else
+#   error "add HGATP_MODE"
+#endif
+
+    return ppn | MASK_INSR(p2m->vmid, HGATP_VMID_MASK) |
+           MASK_INSR(hgatp_mode, HGATP_MODE_MASK);
+}
+
+static int p2m_alloc_root_table(struct domain *d)

    
      
    
      
    As indicated earlier, in a wider context - this is a good candidate where
the caller rather wants to pass struct p2m_domain *. Once you get variations
on P2Ms (like x86'es altp2m or nestedp2m, the domain won't be meaningful
here to know which P2M to allocate the root for.
    
    
    
    
    Good point. I will re-work that.


    
    
    
      
    

    
      
    
        
    +{
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+    p2m->root = p2m_allocate_root(d);
+    if ( !p2m->root )
+        return -ENOMEM;
+
+    p2m->hgatp = hgatp_from_page(p2m);
+
+    return 0;
+}
+
 static spinlock_t vmid_alloc_lock = SPIN_LOCK_UNLOCKED;
 
 /*
@@ -228,5 +313,14 @@ int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
         }
     }
 
+    /*
+    * First, wait for the p2m pool to be initialized. Then allocate the root

    
      
    
      
    Why "wait"? There's waiting here.
    
    
    
    
    I am not really get your question.

"wait" here is about the initialization of the pool which happens above this comment.

    
    
    
      
    

    
      
    
        
    +    * table so that the necessary pages can be returned from the p2m pool,
+    * since the root table must be allocated using alloc_domheap_pages(...)
+    * to meet its specific requirements.
+    */
+    if ( !d->arch.p2m.root )

    
      
    
      
    Aren't you open-coding p2m_get_hostp2m() here?
    
    
    
    
    Yes, p2m_get_hostp2m()  should be used here.

~ Oleksii
    
  


--------------2FTHIQhiOa3ZrNfgfpkwc2a0--


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 22:22:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 22:22:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1029294.1403047 (Exim 4.92)
	(envelope-from )
	id 1uWMtL-0001uk-HU; Mon, 30 Jun 2025 22:22:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1029294.1403047; Mon, 30 Jun 2025 22:22:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uWMtL-0001uc-Cv; Mon, 30 Jun 2025 22:22:23 +0000
Received: by outflank-mailman (input) for mailman id 1029294;
 Mon, 30 Jun 2025 22:22: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 1uWMtK-0001uW-GO
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 22:22:22 +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 b046e220-5600-11f0-a313-13f23c93f187;
 Tue, 01 Jul 2025 00:22:21 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 1B794A5364E;
 Mon, 30 Jun 2025 22:22:20 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8A289C4CEE3;
 Mon, 30 Jun 2025 22:22: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: b046e220-5600-11f0-a313-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1751322139;
	bh=GUOpKpNRKZTtL43Cnzg1ANJM6L6bh0FcsiA8KMgfogY=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=lBykvmj+LaVzDLISv3NX6pyqT5GeTI6MWzg3W4F4FTZ1rxXliSKVYpbFm1b4vIt+G
	 92vwKz6lMWOPLlNx7TecjJlQGlQuzeEcFdjBAMj0do7fTrLVlyDYA6ZZol3zoGPDza
	 1QRpN+yF54VSVMbtnPpL/srq0KPszgD1Lc0rH0kA4sQ2D3EuRQ4F+Q/ygrFeKWLWoG
	 fTwvR0VfocE97xIP+bnBoGdlkAkRx6FCRDoEcpChQ/3a15dHtVEzOejSiwdZe5V9Q0
	 ZIerKyuRp2wGtspRPXBojclo+V8IM/kDsrRMfx5Qu/w8RHwXJSsNdQu1uqFE5Yg8Ad
	 Soh6uudE9Vjjw==
Date: Mon, 30 Jun 2025 15:22:17 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Stefano Stabellini , dmkhn@proton.me, 
    andrew.cooper3@citrix.com, anthony.perard@vates.tech, michal.orzel@amd.com, 
    roger.pau@citrix.com, dmukhin@ford.com, xen-devel@lists.xenproject.org, 
    Julien Grall 
Subject: Re: [PATCH v3 2/2] xen/console: unify printout behavior for UART
 emulators
In-Reply-To: 
Message-ID: 
References: <20250606201102.2414022-1-dmukhin@ford.com> <20250606201102.2414022-3-dmukhin@ford.com>   
    <2f726960-4bdc-4996-b204-722c0253e2ab@suse.com>
    
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Sun, 28 Jun 2025, Jan Beulich wrote:
> On 27.06.2025 23:58, Stefano Stabellini wrote:
> > On Fri, 27 Jun 2025, Julien Grall wrote:
> >> Hi Stefano,
> >>
> >> On 19/06/2025 01:45, Stefano Stabellini wrote:
> >>> On Wed, 18 Jun 2025, Jan Beulich wrote:
> >>>> On 18.06.2025 02:39, Stefano Stabellini wrote:
> >>>>> On Thu, 12 Jun 2025, Jan Beulich wrote:
> >>>>>> On 11.06.2025 21:07, Stefano Stabellini wrote:
> >>>>>>> On Wed, 11 Jun 2025, Jan Beulich wrote:
> >>>>>>>> On 11.06.2025 02:07, dmkhn@proton.me wrote:
> >>>>>>>>> On Tue, Jun 10, 2025 at 10:21:40AM +0200, Jan Beulich wrote:
> >>>>>>>>>> On 06.06.2025 22:11, dmkhn@proton.me wrote:
> >>>>>>>>>>> From: Denis Mukhin 
> >>>>> If I understood correctly I like your proposal. Let me rephrase it to
> >>>>> make sure we are aligned. You are suggesting that:
> >>>>>
> >>>>> - domains without input focus will print with a (d) prefix
> >>>>> - the domain with input focus will print without a (d) prefix
> >>>>> - this applies to both DomUs and Dom0
> >>>>
> >>>> Except in the non-dom0less case, at least up and until there's at least
> >>>> one other domain. I.e. I'd like to keep Dom0 boot output as it is today,
> >>>> regardless of the presence of e.g. "conswitch=".
> >>>
> >>> In the non-dom0less case, since dom0 has focus, it would naturally be
> >>> without (d) prefix. Unless the user passes "conswitch=". Honestly, I
> >>> wouldn't special-case conswitch= that way and would prefer keep things
> >>> simple and consistent without corner cases. I don't think conswitch= is
> >>> so widely used that it is worth the complexity to special-case it.
> >>
> >> I am a bit confused with the wording. Before I can provide another opinion, I
> >> want to understand a bit more the concern.
> >>
> >> From my understanding the command line option "conswitch" is to allow the
> >> admin to change with key is used to switch between Dom0 and Xen. By default
> >> this is 'a'. So are you referring to the fact a trailing "x" (to not switch to
> >> dom0 console) can be added?
> > 
> > Yes, conswitch can also be used to ask Xen to keep the input focus to
> > itself, instead of giving it away to Dom0. I think this is the specific
> > feature Jan was referring to when he said he is using conswitch and the
> > proposal would change the way the output looks like for him, which is
> > true.
> > 
> > Today, dom0 would still print without any prefix.
> > 
> > Tomorrow with this proposal, dom0 would print with a "(d0)" prefix
> > because it doesn't have input focus.
> > 
> > The question is, with the new policy in place, whether this is worth the
> > trouble of having a special case to remove the "(d0)" prefix in the
> > conswitch=x case. I think it is not worth it, Jan thinks it is.
> 
> Just to clarify: Along with this mode being entered by conswitch=, I also
> expect the behavior to remain unaltered when booting (non-dom0less)
> without that option, and later flipping focus between Xen and Dom0 by
> using triple Ctrl-a. I'm saying this just to make sure that an eventual
> change to the patch wouldn't be keyed to the use of the command line
> option.

Oh, I see now where the difference of opinion lies. This is the policy
as written above:

- domains without input focus will print with a (d) prefix
- the domain with input focus will print without a (d) prefix
- this applies to both DomUs and Dom0

Which means that when you move around with Ctrl-AAA or conswitch, no
matter if it is dom0less or not, Dom0 would end up printing the prefix
(d0).

Jan, and now also Julien are saying that prefer to retain the old
behavior. I defer to the will of the majority. So then the policy would
be:

Dom0less:
- domains without input focus will print with a (d) prefix
- the domain with input focus will print without a (d) prefix
- this applies to both DomUs and Dom0

Dom0:
- same as today
- the domain with input focus will print without a (d) prefix


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 22:27:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 22:27:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1029304.1403057 (Exim 4.92)
	(envelope-from )
	id 1uWMyS-0002XZ-6d; Mon, 30 Jun 2025 22:27:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1029304.1403057; Mon, 30 Jun 2025 22:27: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 1uWMyS-0002XS-2x; Mon, 30 Jun 2025 22:27:40 +0000
Received: by outflank-mailman (input) for mailman id 1029304;
 Mon, 30 Jun 2025 22:27: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 1uWMyR-0002XM-2T
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 22:27:39 +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 6c859592-5601-11f0-b894-0df219b8e170;
 Tue, 01 Jul 2025 00:27:37 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id DA407A5364A;
 Mon, 30 Jun 2025 22:27:35 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 62242C4CEE3;
 Mon, 30 Jun 2025 22:27: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: 6c859592-5601-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1751322455;
	bh=G6Sy/gWzRh6VbK8nybuPa7Y/dmT2xzfgSUhBHoN8pfM=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=ht7FTGbF5ysFBgipI9NlC60ltAYTn9x59n6oPLctwwYJrWXRlGEXpDZ/wyGnlCoHF
	 yairhHFj1Rw5y8lkvhGGWznTIr106ojvULpn9vypnG2WqXXqWE/Wk/cKMVoFbdw2W0
	 JWjwCz2f+pkvhlBU5bLiy/tfUDpXSbqwc+MuAEUxcf7kHovxVG7aHW6Qt27y3ECZTC
	 979ljT7BSphTTS/aG87HismlHCnPkz/YnjC7qWqRD5QWrxRmQICFzKytDHyZESFY0O
	 Cx9XwrG4c+xjRT2YOayxVN2yPQK7mNKUTbAThBnhr06/hnpKeVcP3n7ER3YfdnzUCH
	 2H66e77jLd1hQ==
Date: Mon, 30 Jun 2025 15:27:32 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Stefano Stabellini 
cc: Jan Beulich , dmkhn@proton.me, 
    andrew.cooper3@citrix.com, anthony.perard@vates.tech, michal.orzel@amd.com, 
    roger.pau@citrix.com, dmukhin@ford.com, xen-devel@lists.xenproject.org, 
    Julien Grall 
Subject: Re: [PATCH v3 2/2] xen/console: unify printout behavior for UART
 emulators
In-Reply-To: 
Message-ID: 
References: <20250606201102.2414022-1-dmukhin@ford.com> <20250606201102.2414022-3-dmukhin@ford.com>   
    <2f726960-4bdc-4996-b204-722c0253e2ab@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, 30 Jun 2025, Stefano Stabellini wrote:
> On Sun, 28 Jun 2025, Jan Beulich wrote:
> > On 27.06.2025 23:58, Stefano Stabellini wrote:
> > > On Fri, 27 Jun 2025, Julien Grall wrote:
> > >> Hi Stefano,
> > >>
> > >> On 19/06/2025 01:45, Stefano Stabellini wrote:
> > >>> On Wed, 18 Jun 2025, Jan Beulich wrote:
> > >>>> On 18.06.2025 02:39, Stefano Stabellini wrote:
> > >>>>> On Thu, 12 Jun 2025, Jan Beulich wrote:
> > >>>>>> On 11.06.2025 21:07, Stefano Stabellini wrote:
> > >>>>>>> On Wed, 11 Jun 2025, Jan Beulich wrote:
> > >>>>>>>> On 11.06.2025 02:07, dmkhn@proton.me wrote:
> > >>>>>>>>> On Tue, Jun 10, 2025 at 10:21:40AM +0200, Jan Beulich wrote:
> > >>>>>>>>>> On 06.06.2025 22:11, dmkhn@proton.me wrote:
> > >>>>>>>>>>> From: Denis Mukhin 
> > >>>>> If I understood correctly I like your proposal. Let me rephrase it to
> > >>>>> make sure we are aligned. You are suggesting that:
> > >>>>>
> > >>>>> - domains without input focus will print with a (d) prefix
> > >>>>> - the domain with input focus will print without a (d) prefix
> > >>>>> - this applies to both DomUs and Dom0
> > >>>>
> > >>>> Except in the non-dom0less case, at least up and until there's at least
> > >>>> one other domain. I.e. I'd like to keep Dom0 boot output as it is today,
> > >>>> regardless of the presence of e.g. "conswitch=".
> > >>>
> > >>> In the non-dom0less case, since dom0 has focus, it would naturally be
> > >>> without (d) prefix. Unless the user passes "conswitch=". Honestly, I
> > >>> wouldn't special-case conswitch= that way and would prefer keep things
> > >>> simple and consistent without corner cases. I don't think conswitch= is
> > >>> so widely used that it is worth the complexity to special-case it.
> > >>
> > >> I am a bit confused with the wording. Before I can provide another opinion, I
> > >> want to understand a bit more the concern.
> > >>
> > >> From my understanding the command line option "conswitch" is to allow the
> > >> admin to change with key is used to switch between Dom0 and Xen. By default
> > >> this is 'a'. So are you referring to the fact a trailing "x" (to not switch to
> > >> dom0 console) can be added?
> > > 
> > > Yes, conswitch can also be used to ask Xen to keep the input focus to
> > > itself, instead of giving it away to Dom0. I think this is the specific
> > > feature Jan was referring to when he said he is using conswitch and the
> > > proposal would change the way the output looks like for him, which is
> > > true.
> > > 
> > > Today, dom0 would still print without any prefix.
> > > 
> > > Tomorrow with this proposal, dom0 would print with a "(d0)" prefix
> > > because it doesn't have input focus.
> > > 
> > > The question is, with the new policy in place, whether this is worth the
> > > trouble of having a special case to remove the "(d0)" prefix in the
> > > conswitch=x case. I think it is not worth it, Jan thinks it is.
> > 
> > Just to clarify: Along with this mode being entered by conswitch=, I also
> > expect the behavior to remain unaltered when booting (non-dom0less)
> > without that option, and later flipping focus between Xen and Dom0 by
> > using triple Ctrl-a. I'm saying this just to make sure that an eventual
> > change to the patch wouldn't be keyed to the use of the command line
> > option.
> 
> Oh, I see now where the difference of opinion lies. This is the policy
> as written above:
> 
> - domains without input focus will print with a (d) prefix
> - the domain with input focus will print without a (d) prefix
> - this applies to both DomUs and Dom0
> 
> Which means that when you move around with Ctrl-AAA or conswitch, no
> matter if it is dom0less or not, Dom0 would end up printing the prefix
> (d0).
> 
> Jan, and now also Julien are saying that prefer to retain the old
> behavior. I defer to the will of the majority. So then the policy would
> be:
> 
> Dom0less:
> - domains without input focus will print with a (d) prefix
> - the domain with input focus will print without a (d) prefix
> - this applies to both DomUs and Dom0
> 
> Dom0:
> - same as today
> - the domain with input focus will print without a (d) prefix

Sorry this last line was an editing error. I'll write it again for
clarity.

Dom0less:
- domains without input focus will print with a (d) prefix
- the domain with input focus will print without a (d) prefix
- this applies to both DomUs and Dom0

Dom0:
- same as today (with or without conswitch)


From xen-devel-bounces@lists.xenproject.org Mon Jun 30 22:33:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jun 2025 22:33:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1029311.1403066 (Exim 4.92)
	(envelope-from )
	id 1uWN4N-00047g-Q1; Mon, 30 Jun 2025 22:33:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1029311.1403066; Mon, 30 Jun 2025 22:33:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uWN4N-00047Z-N5; Mon, 30 Jun 2025 22:33:47 +0000
Received: by outflank-mailman (input) for mailman id 1029311;
 Mon, 30 Jun 2025 22:33:45 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uWN4L-00047T-Rr
 for xen-devel@lists.xenproject.org; Mon, 30 Jun 2025 22:33: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 450c2bb5-5602-11f0-b894-0df219b8e170;
 Tue, 01 Jul 2025 00:33:40 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 055E55C4AF7;
 Mon, 30 Jun 2025 22:33:39 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 18FE9C4CEE3;
 Mon, 30 Jun 2025 22:33: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: 450c2bb5-5602-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1751322818;
	bh=vkuoGTmfjS9ph8yoPPL9os/Cf8RjuXqnbO56e9M2Ats=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=aOyEbEam6smZjrZgmIa/rIDL7d02MET7TsaKrcsfaH9pLy6Ug3Z2EicmSNqb9X3Op
	 1SyeT5xbGljGvhaeerpGSMYjSi908tpW4LpNcCBhL4B11QWBviQNC505SPGwVJAIhP
	 cMyBYnaHtED+5LMvD2KCR/bwZCm7raP3xtoUiFiCXz2qi7cg7eRJwpBi22UT4PzFOO
	 RPEsVZHOUHclg1OeMG0P1TH99Sx8JHjhXr/5qvwyFaQeNKqTXqEaWt+5J3QqhPTbhl
	 hhZ3jr2oAwcPI1XW9Os+p/i6VKgJ9RUCqN9lfHGPDJejEOa7NmuvOD4Felp4y1zpFv
	 OXNSILTHz0bdQ==
Date: Mon, 30 Jun 2025 15:33:36 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Julien Grall 
cc: Oleksii Moisieiev , 
    Stefano Stabellini , 
    "xen-devel@lists.xenproject.org" , 
    Andrew Cooper , 
    Anthony PERARD , 
    Bertrand Marquis , 
    Jan Beulich , Juergen Gross , 
    Michal Orzel , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Volodymyr Babchuk , 
    Grygorii Strashko 
Subject: Re: [RFC PATCH v4 8/8] docs: armproposa: l to add separate SCMI node
 for Xen agent
In-Reply-To: <5992e6bf-e9ea-480f-bcd3-a6cf1c335190@xen.org>
Message-ID: 
References:  <3f7e1e99f5d1018064f3c4825aff16bd487cf558.1747669845.git.oleksii_moisieiev@epam.com>  
    <3468bb57-3178-460b-8fb2-3ce106475319@xen.org>
    <41566d23-464b-4676-8e01-e2f27d377a94@xen.org> <6689b22a-f85e-40ba-a89b-7935df1bdd28@epam.com>
 <5992e6bf-e9ea-480f-bcd3-a6cf1c335190@xen.org>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 30 Jun 2025, Julien Grall wrote:
> Hi,
> 
> On 30/06/2025 12:57, Oleksii Moisieiev wrote:
> > KVM [1] is not applicable here as it starts under/inside Linux, so it
> > doesn't have direct access to SCMI, the Linux does.
> > And Linux will see only one SCMI transport (Agent).
> > Seems, the only option possible is virtio-scmi (qemu) - the virtio-scmi
> > potentially can simulate multi-channel,
> > but this is out if scope of this work.
> > QNX [0] relies on configuration files rather than the Device Tree.
> To clarify, I didn't ask to implement anything in KVM or QNX. I asked to write
> the bindings in a way that they are not Xen specific to give a chance to for
> other to re-use them. Yes today KVM and QNX would not use them... But I also
> still don't see why we should actively prevent them to use the bindings you
> come up with...

I agree with Julien. We can still have the property or node under
/chosen to avoid conflicts and confusion while still making the node
more generic so at least in theory it could be reused by other
hypervisors -- remove the "xen," prefix from
"xen,scmi-secondary-agents".